上下文不是不够用，是没管好 我们的客服 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 万。 半年前上线的时候，我在周报里写「技术方案已验证，
「为什么 Agent 调我们的接口总是调错」 去年 12 月，业务方提了个需求：让客服 Agent 能直接查订单、查物流、发起退款。我当时的反应是「这不简单吗，把现有的订单服务接口包一层给 Agent 调就行了」。 两周后我收回这句话。Agent 调用我们接口的失败率是 37%，其中大部分不是超时或
多智能体上线两周，成本涨了 6 倍 十一月份我们把合同审查从单 Agent 改成了多智能体——一个主管 Agent 负责任务分解，下面挂了四个专职 Agent（条款抽取、风险识别、合规比对、历史案例检索）。理由是单 Agent 的表现遇到瓶颈：一份 40 页的合同要塞进一次上下文，模型经常顾此失彼，
把工作流改成 Agent 三个月后，我们又改回去了一部分 去年我们的运维平台是一套硬编码的工作流：告警触发 → 按告警类型走固定的排查步骤 → 生成结论 → 通知。今年八月我们把它改造成了自主 Agent，让它自己决定调用什么工具、走几步。 跑了三个月，结论比较复杂：有些场景效果好得出乎意料，有些场
同事问：MCP 不就是 Function Calling 换了个名字吗 上个月内部分享会，我讲完 MCP 之后有同事问了这个问题。当时我答得不太好，说了些「更标准化」「生态更好」之类的空话。后来我认真想了想，也去读了规范原文，这篇算是个正经的回答。 结论是：不是换名字，是两个层次的东西。Functi
