归档

上下文不是不够用，是没管好 我们的客服 Agent 用的是 128K 上下文的模型。上线初期大家的判断是「128K 够用了，不用操心上下文管理」。 三个月后我们把单次对话的平均 token 从 3,200 涨到了 26,000——不是因为业务变复杂，是因为我们没有做任何管理，历史消息无脑全带上。到第

Rod Johnson 又回来了，这次做的是 Agent 框架 看到 Embabel 的时候我愣了一下。作者是 Rod Johnson，Spring 的创始人。他 2025 年开始做这个框架，2026 年初发布了 1.0。 我花了一个月读源码、写了两个 POC。这篇记录我对它的理解，重点是 GOAP

「能不能不装 Python」 起因是运维同事的一个要求。我们的一个内部 Agent 需要在客户机房部署，而客户的环境管控很严：不能装 Python，不能连外网，只能给一个 JAR 包和一个 JDK 21。 我第一反应是这个需求没法满足——跑模型怎么可能不用 Python。然后我想起去年在技术雷达里标

我们内部有 34 个 Agent，每家一套工具定义 今年年初做资产盘点，我发现一件事：公司里跑着 34 个 Agent（客服、运营、数据分析、运维助手……），它们调用的工具加起来有 210 多个，其中功能重叠的大概 60 个。 最典型的是「查订单」。客服 Agent 有一份实现，运营 Agent 有

「我们的知识库问答准确率只有 71%，要不要做微调」 去年 11 月，业务方拿着一份评测报告来找我：客服问答准确率 71%，离可用的 85% 差得远。他们的结论是「做微调，把行业知识训进模型」。 我说先别急，让我把两条路都跑一遍再决定。这篇是三个月实测的结果，包括所有成本数字。结论先放：我们最后选了

半年 470 万次调用，10 个坑 我们的客服 Agent 是 2025 年 9 月上线的，到今天跑了半年多一点。数据：累计 470 万次对话，日均 2.6 万次，峰值 4.1 万次/天，P99 延迟 3.2 秒，月均 token 成本 7.8 万。 半年前上线的时候，我在周报里写「技术方案已验证，

「Spring 是不是被 AI 时代落下了」 上个月团队里一个工作两年的同学问我：现在大家都在聊 LangChain、LlamaIndex、各种 Agent 框架，Spring 在这些话题里几乎不出现，是不是已经过时了？ 这个问题我这两年听过很多次。我当时没直接回答，让他去看看 spring-ai

入行第八年，我把这八年做过的选型列了张表 2026 年 3 月，我入行整八年。过年期间我把这些年参与过的重大技术选型整理了一遍，一共 34 项，标上当时的决策理由、实际结果、以及现在的回头看评价。 结果有点难堪：34 项里，现在看是正确决策的 19 项，过早的 6 项，过晚的 5 项，纯错的 4 项

给 AI 服务调 JVM，我原来的经验全部失效了 我做 JVM 调优大概六年，给订单、支付、库存这些服务调过不下三十次，形成了一套肌肉记忆：Young 区给 1/3，MaxGCPauseMillis 设 100，开字符串去重，老年代增长超过 50 MB/min 就要警惕。 2025 年下半年开始接

凌晨两点的告警：Old 区 12 分钟涨满 2 月 18 号凌晨 2 点 07 分，值班电话响了。监控看板上，我们的智能问答服务实例 qa-svc-7d9f 的老年代曲线是一条近乎垂直的直线：从 1.2 GB 到 5.8 GB 用了 12 分钟，然后 Full GC，STW 4.7 秒，接着又是一条