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 产品做，不是脚本项目做。