AI Agent 的「Demo 魔咒」：为什么你的 Agent 演示时惊艳，上线后翻车
AI Agent 的「Demo 魔咒」：为什么你的 Agent 演示时惊艳，上线后翻车
GitHub 上最火的几个 Agent 框架——AutoGen（5.8万星）、CrewAI（5.2万星）、LangGraph（3.3万星）、OpenAI Agents SDK（2.7万星）——加起来超过 17 万颗星。但一个尴尬的事实是：大部分 Star 来自"我先 clone 下来跑个 demo"，真正跑在生产环境的 Agent 少之又少。
Anthropic 在 2024 年底的工程博客里写过一句大实话："最成功的实现都没用复杂框架，而是在用简单、可组合的模式。"
Demo 和 Prod 之间隔着一条巨大的鸿沟。本文拆解七个致命断层。
本文提纲
- 断层一：确定性的幻觉
- 断层二：上下文窗口的残酷算术
- 断层三：Evaluation 的真空
- 断层四：成本的不归路
- 断层五：状态管理的深渊
- 断层六：错误恢复的"俄罗斯轮盘"
- 断层七：可观测性的黑洞
断层一：确定性的幻觉
Demo 里 Agent 跑得很顺：三步规划、两次工具调用、完美输出。你觉得它"理解"了任务。
但 LLM 本质是一个概率模型。同一个 prompt 跑 100 次，你可能得到 100 种不同的规划路径。在 Demo 里你只展示了其中最顺的一次。
Prod 里这意味着什么：
Agent 可能决定用一种你从没见过的方式调用工具——参数格式偏了、跳过了某个必要步骤、或者陷入了死循环。你没法写 if-else 来覆盖所有分支，因为分支是模型自己生成的。
一个真实的场景：你做了一个"自动发邮件"的 Agent。Demo 里它乖乖地读邮件、草拟回复、等你确认。Prod 里它某天突然直接点了"发送"——因为你从来没想过要测试"模型会不会跳过确认步骤"这个 case。
怎么缓解：
- 把 Agent 的自主度限制在窄域里。能硬编码的路径就硬编码，别什么都让模型决定
- Anthropic 的建议很对：先试 workflow（预定义路径），再上 agent（自主路径）
- 每个工具调用前加 programmable gate——不是让模型"自觉"遵守，是代码层面强制检查
断层二：上下文窗口的残酷算术
Demo 时你喂给 Agent 的上下文很干净：一个精心准备的 prompt + 几条示例数据。一切运行良好。
Prod 里 Agent 要面对的上下文是：
- 系统提示（2000+ tokens）
- 工具定义（每个 200-500 tokens，10 个工具就是 2000-5000 tokens）
- 对话历史（每轮 500-2000 tokens，20 轮对话就 10000-40000 tokens）
- RAG 检索结果（3000-10000 tokens）
- 之前步骤的中间结果（不可控）
加起来轻松超过 5 万 tokens。而上下文越长，模型越容易"遗忘"早期的指令。你的 Agent 开始忽略工具使用规范、忘记输出格式、甚至重复之前已经做过的步骤。
更残酷的是：上下文里塞的信息越多，每一条信息的边际效用越低。Demo 里每条信息都精准有用；Prod 里大量上下文是噪声。
怎么缓解：
- 对话历史做摘要，不要原样累积。LangGraph 的
MemorySaver就是在干这事 - 工具定义精简到最小，去掉模型不需要知道的参数说明
- 用 RAG 替代"把所有信息塞进 prompt"——但 RAG 本身也是另一个 Prod 难题
- 设置上下文预算，硬性截断
断层三：Evaluation 的真空
传统软件测试的核心是断言：输入 X，断言输出 Y。Agent 的输出是非确定性的，你怎么写断言？
Demo 阶段没人关心 eval。你手工跑了几个 case，觉得不错，就上线了。Prod 里你需要的 eval 体系是：
- 功能正确性：Agent 是否完成了任务？（不是"输出看起来合理"，而是可验证的完成）
- 工具使用准确率：Agent 是否选择了正确的工具？参数是否正确？
- 规划合理性：Agent 的步骤序列是否高效？有没有冗余步骤？
- 边界情况覆盖：当输入异常时，Agent 是优雅降级还是崩溃？
- 回归测试：每次模型更新后，之前能跑的 case 是否还能跑？
现实是：大多数团队根本没有 Agent eval 体系。他们靠人工看日志，靠用户投诉发现问题。这在 Prod 环境是不可接受的。
怎么缓解：
- 建立 golden dataset：50-100 个典型场景 + 预期结果，跑自动化 eval
- 用 LLM-as-judge 做初步筛选，但最终必须有确定性断言
- 工具调用做结构化验证（JSON schema 校验）
- 设置"Agent 置信度"阈值——低于阈值就回退到人工
- LangSmith、LangFuse 这类工具专门解决 Agent 可观测性和 eval
断层四：成本的不归路
Demo 时你跑 10 次请求，花了 $0.50，觉得很便宜。Prod 里你的 Agent 每天跑 1000 次，每次 5-20 轮 LLM 调用，每轮消耗 2000-10000 tokens：
1000 请求/天 × 10 轮/请求 × 5000 tokens/轮 = 5000 万 tokens/天按 Claude Sonnet 的价格（$3/M input, $15/M output），每天光 token 费用就是几百到几千美元。如果用 Opus，再乘 5-10 倍。
更隐蔽的是隐性成本：
- Agent 重试（失败后自动重跑）：每次重试 = 原始成本 × 重试次数
- 死循环检测和超时：Agent 卡住了，你白白烧了 token
- 上下文累积：对话越长，每轮成本越高
- 工具调用失败后的恢复：重试 + 补偿逻辑
怎么缓解：
- 设硬性 token 预算：每个任务、每轮对话都设上限
- 简单任务用小模型（Haiku、GPT-4o-mini），复杂任务才上大模型
- Anthropic 的 routing 模式：先用小模型分类，再路由到合适的模型
- 缓存结果：相似请求直接复用，不重新跑 Agent
- 成本监控必须从第一天就建好——不要等账单来了才惊讶
断层五：状态管理的深渊
Demo 里 Agent 跑完就结束了。Prod 里 Agent 需要处理：
- 长时间运行的任务：一个 Agent 跑了 30 分钟，中间服务重启了，状态怎么办？
- 多人协作：两个用户同时触发 Agent 操作同一个资源
- 跨会话状态：用户的任务昨天开始了，今天要继续
- 部分失败：Agent 完成了 5 步中的 3 步，第 4 步失败了，前 3 步的结果怎么处理？
LangGraph 之所以强调 "Build resilient agents"（构建弹性 Agent），就是因为状态管理是 Prod 的头号难题。它用 checkpoint 机制做状态持久化——每一步的结果都存下来，失败了可以从断点恢复而不是从头开始。
没有 checkpoint 的 Agent 就像一个没有保存按钮的游戏——崩溃了就得重来。
怎么缓解：
- 选择支持 checkpoint 的框架（LangGraph、Temporal + Agent）
- 每个 tool call 的结果做持久化，不只在内存里
- 设计幂等操作——重试不会产生副作用
- 设置合理的超时和降级策略
断层六：错误恢复的"俄罗斯轮盘"
Demo 里出错了？重新跑一遍就行，反正是演示。Prod 里错误是常态，不是例外。
Agent 可能遇到的错误类型：
| 错误类型 | Demo 中 | Prod 中 | 后果 |
|---|---|---|---|
| LLM 输出格式错误 | 手动重跑 | 解析崩溃 | 整条链路失败 |
| 工具 API 超时 | 换个网络重试 | 用户等着 | SLA 违规 |
| LLM 幻觉 | "嗯，下次注意" | 数据污染 | 业务逻辑错误 |
| 工具返回意外值 | 跳过这个 case | Agent 卡死 | 死循环或崩溃 |
| Token 超限 | 删点上下文 | 任务中断 | 用户体验断裂 |
最危险的是复合错误：第一步的小偏差传到第二步放大，第三步再放大，到第五步已经完全偏离了预期。Demo 里你只跑了"正常路径"，Prod 里正常路径可能只占 60%。
怎么缓解：
- 每个步骤的输出做结构化验证，不合格就重试或降级
- 设置"最大步数"硬上限，防止无限循环
- 关键操作做人类确认（Human-in-the-loop）
- 优雅降级：Agent 失败了要有兜底方案（回退到简单规则、转人工）
断层七：可观测性的黑洞
Demo 时你盯着终端看 Agent 的每一步输出。Prod 里你没有终端可盯。
你需要回答这些问题，但通常回答不了：
- Agent 刚才为什么选了这个工具而不是那个？
- 第三步的中间结果是什么？
- 这次运行花了多少 tokens？多少时间？
- 失败的请求，失败在哪一步？
- 过去 24 小时的成功率是多少？
没有可观测性的 Agent 在 Prod 环境就像一个黑盒——出了问题你只能猜。
怎么缓解：
- 结构化日志：每一步都记录输入、输出、token 用量、耗时
- 分布式追踪：给每次 Agent 运行一个 trace ID，贯穿所有步骤
- Dashboard：成功率、延迟分布、token 消耗趋势、错误类型分布
- 工具：LangSmith、LangFuse、Helicone、Braintrust 都在做 Agent 可观测性
从 Demo 到 Prod 的检查清单
如果你的 Agent 准备上 Prod，先过一遍这张清单：
- 错误恢复：LLM 输出格式错误时，是崩溃还是有 fallback？
- Token 预算：单次请求的 token 上限是多少？超了怎么办？
- 状态持久化：Agent 跑到一半服务重启，能从断点恢复吗？
- Eval 体系：有自动化测试覆盖核心场景吗？有回归机制吗？
- 成本监控：知道每天花多少钱吗？有预算告警吗？
- 可观测性：Agent 失败了，能 5 分钟内定位到失败原因吗？
- 降级策略：Agent 整体不可用时，有兜底方案吗？
- 人工兜底：高风险操作有 human-in-the-loop 吗？
一个残酷的真相：如果你的 Agent 在 Demo 里需要精心准备 prompt 才能跑通，那它在 Prod 里大概率跑不通。
真正能在 Prod 活下来的 Agent，不是最聪明的那个，是最抗揍的那个。
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
