Agent 失败的 5 个隐性成本
我们做了 200 个 Agent 项目的存活曲线分析，发现一个惊人的事实：90% 的 Agent 项目在 6 个月内"死掉"，但只有 20% 是因为"技术不行"。
剩下 80% 死于 5 个隐性成本。这篇文章讲清楚。
成本 1：上下文管理的熵增
每个 Agent 项目初期都很干净。System prompt 写得清晰，工具描述到位，few-shot examples 齐全。
3 个月后，团队加了新功能，prompt 越来越长，工具越来越多，examples 开始打架。你打开 prompt 文件，看到 200 行混乱指令，自己都看不懂。
更糟的是，没人敢删。每个指令都"有用"，删了就出错。
这就是"上下文熵增"。LLM 对长 prompt 的鲁棒性是有限的，指令间的相互干扰会指数级增长。
怎么治：
- 每月做一次 prompt 审计，删掉无效指令
- 把长 prompt 拆成"系统 prompt + 动态加载的 few-shot"
- 任何新指令添加前必须问"我能不能改用工具替代？"
成本 2：工具调用的隐藏耦合
Agent 调用工具 A 得到结果，工具 B 用工具 A 的结果继续。看起来很自然。
但工具 A 的输出格式一变，整个 Agent 链就崩了。你改了工具 A 的 JSON schema，3 个下游工具都坏了，但 CI 没测到（因为没改工具 B 的测试）。
更隐蔽的是，工具的错误信息不一致。工具 A 失败时返回 {"error": "..."}，工具 B 失败时返回 {"success": false, "reason": "..."}，工具 C 失败时直接抛异常。LLM 处理这些不一致时经常困惑。
怎么治：
- 工具的输入输出必须有 schema（用 Pydantic / Zod）
- 所有工具的失败返回必须是同一种格式
- 任何工具改动必须触发所有下游 Agent 的回归测试
成本 3：评测的"假阳性"
你写了 100 个测试用例，pass rate 95%。看起来很好。
真实场景里 30% 的请求都失败了。为什么？
因为你的测试用例是从"LLM 应该能处理的请求"里挑的，不是从"用户实际会问的"里挑的。测试集和真实分布不一致。
更糟的是 LLM 的"正确答案"本身就有模糊性。你的 100 个测试里，30 个的"标准答案"是某次偶然的 LLM 输出，结果 LLM 一更新就过了。
怎么治：
- 测试集必须从真实用户日志采样，不是凭空编
- 评测时用 LLM-as-judge 或 人工抽检，不要只看 pass rate
- 每个版本发布前必须做"线上影子流量"测试
成本 4：可观测性的真空
Agent 出问题时，最常见的反馈是"它又胡说八道了"。
但你完全不知道是哪一步胡说八道。是意图分类错了？工具调用错了？参数错了？返回结果解析错了？最终回答生成错了？
大部分 Agent 框架（MCP、AutoGen、CrewAI）默认没有 tracing。等出问题了你才发现需要加 LangSmith / Langfuse / Helicone。
怎么治：
- 项目第一天就接 tracing，不要等出问题
- 每一步的输入输出、token 用量、延迟都要记录
- 关键路径必须有"重放能力" — 同一输入能重放出完全一样的轨迹
成本 5：组织能力的代差
这是最致命的成本。
写 Agent 应用的人和维护 Agent 应用的人经常不是同一拨人。写的可能是 AI 工程师，懂 prompt、懂工具、懂 LLM。维护的可能是普通后端工程师，只懂传统开发。
当 Agent 出问题时，维护者看不懂 prompt 在干啥，不敢改。写作者已经去搞新项目了，没空救火。
3 个月后，Agent 系统变成"黑盒"，没人敢动。最后只能重写。
怎么治：
- Agent 项目必须有完整的 prompt 文档，每个工具的设计意图
- 代码 review 必须包含 prompt review
- 关键 prompt 不能用"魔法字符串"，要从配置文件加载
- 团队必须有至少 2 个人懂 Agent 开发，避免单点
我们的数据
分析了 200 个 GitHub 上的 Agent 项目（star > 100，活跃 commit）：
- 6 个月后仍在更新：22%
- 停止更新但仍可用：41%（没人维护，跑得好好的）
- 彻底废弃：37%（跑挂了，没人修）
"彻底废弃"的项目里，根因分布：
- 上下文熵增：34%
- 工具耦合崩了：28%
- 评测失效：18%
- 可观测性缺失：12%
- 团队能力断档：8%
给 Agent 团队的清单
如果你正在做 Agent 项目，6 个月后想不被废弃，现在就要：
- [ ] prompt 在 git 里，跟代码一样 review
- [ ] 所有工具有 schema，输出格式统一
- [ ] 测试集从真实用户日志采样
- [ ] 接了 tracing，每一步可重放
- [ ] 团队里至少 2 人能独立维护
- [ ] 每月做一次 prompt 审计
做不到 6 项中的 3 项以上，6 个月后这个项目大概率会"看起来在跑但没人敢动"。
Agent 项目不是写完就完，是持续运营。把它当 SaaS 产品做，不是脚本项目做。