多智能体上线两周，成本涨了 6 倍 十一月份我们把合同审查从单 Agent 改成了多智能体——一个主管 Agent 负责任务分解，下面挂了四个专职 Agent（条款抽取、风险识别、合规比对、历史案例检索）。理由是单 Agent 的表现遇到瓶颈：一份 40 页的合同要塞进一次上下文，模型经常顾此失彼，
把工作流改成 Agent 三个月后，我们又改回去了一部分 去年我们的运维平台是一套硬编码的工作流：告警触发 → 按告警类型走固定的排查步骤 → 生成结论 → 通知。今年八月我们把它改造成了自主 Agent，让它自己决定调用什么工具、走几步。 跑了三个月，结论比较复杂：有些场景效果好得出乎意料，有些场
同事问：MCP 不就是 Function Calling 换了个名字吗 上个月内部分享会，我讲完 MCP 之后有同事问了这个问题。当时我答得不太好，说了些「更标准化」「生态更好」之类的空话。后来我认真想了想，也去读了规范原文，这篇算是个正经的回答。 结论是：不是换名字，是两个层次的东西。Functi
新项目选了 LangChain4j，而不是继续用 Spring AI 我们团队的运维 Agent 一直是 Spring AI 写的，跑了半年挺稳。上个月开新项目——一个面向业务部门的合同审查 Agent，我评估了一圈，最后选了 LangChain4j。 这个决定在组内有争议，有人认为「统一技术栈」更
客服转来一条投诉：AI 给用户编了个退款政策 十月底，客服同学转来一条用户投诉，附了聊天截图： 用户：我这个订单上周下的，还能退吗？ 机器人：可以的，我们支持 15 天内无理由退款，您直接在订单页面点击申请退款即可。 用户：我看到页面上写的是 7 天？ 机器人：抱歉造成困扰，7 天是普通商品的标准，
两个同事为「提示词改版有没有用」吵了一周 九月份我们改了一版运维 Agent 的系统提示词，主要变化是加了「先确认信息是否充分，再决定调用工具」这一段。改完之后团队内部炸了： 小王说「明显变准了，我测的几个问题都对」；老李说「变差了，现在它老是不干活，一直问我问题」。两人各举了三四个例子，都很有说服
同一个问题跑五次，得到三种不同的结果 九月初用户反馈我们的运维 Agent 有时会给出错误的重启建议——明明是磁盘满了，它建议重启服务。我们拿到 session ID 去复现，同一个问题、同一份上下文，跑了五次： 次数 结论 步数 耗时 token 1 磁盘满，建议清理日志（正确） 4 18s 21
给公司内部的 CMDB 写了个 MCP Server 八月份我们决定把内部 CMDB、发布系统、监控平台接进 Agent。一开始想的是直接写 Function Calling，写了两周发现每个 Agent 框架（我们内部有 Spring AI 和 LangChain4j 两套）都要实现一遍，工具定义
半年过去了，我们团队到底提效了多少 2024 年 10 月我们组 11 个人开始全面用 AI 编码助手，到今年三月底正好半年。这半年里我在各种场合听到的说法从"提效 50%"到"就是个高级补全"都有，差距大到不像在说同一个东西。所以我们拉了数据自己看了一遍，顺便把踩过的坑和定下的规矩记下来。 数据是
工单：「你们的 Agent 是不是失忆了」 六月份客服转过来一批工单，其中有条写得挺扎心：「你们的运维助手，我上周三让它排查过一次订单服务超时，昨天又超时了，它从零开始问我要服务名、要时间范围，像完全没见过我一样。是不是失忆了？」 我看了下那两个 session，确实是两套完全独立的对话。我们当时只
