Agent Basic / 04
为什么很多 Agent Demo 一落地就不稳定
很多人第一次做 Agent，都会经历这个阶段：
- 本地演示能跑
- 看起来也会调用工具
- 甚至在几个样例上效果不错
于是你会觉得系统已经差不多成了。
但真正进入业务场景后，问题马上出现：
- 任务变复杂就乱跑
- 结果不稳定
- 调用工具成本很高
- 运行时间不可控
- 一出错就不知道卡在哪
这不是因为你太菜，而是因为 Demo 和真实系统关注的问题完全不同。
Demo 关注的是“能不能动”
一个 Demo 通常只需要证明：
- 模型能理解任务
- 工具链能接通
- 系统能完成一个示例流程
所以 Demo 天然会偏向：
- 乐观输入
- 短链路
- 少量工具
- 单次成功样例
这没有问题，但它只能证明“有可能可行”，不能证明“长期可用”。
真实系统关注的是“会不会坏”
一旦进入真实场景，你关注的问题马上变成：
- 用户输入是否稳定
- 外部数据是否可靠
- 工具是否会失败
- 系统是否会重复做无效动作
- 出错后能不能恢复
- 成本和延迟是否可接受
也就是说，真实系统不是在追求“最聪明的一次”，而是在追求“多数情况下都别坏”。
常见断层 1：目标定义太模糊
很多 Demo 的目标写得很宽：
帮我完成任务
自动分析市场风险
自主研究并给出结论
这种说法在演示里没问题，但在系统里太危险。
因为目标不清晰会导致：
- 系统不知道什么时候结束
- 探索范围不断膨胀
- 输出标准不稳定
所以从 Demo 到生产，第一步通常不是“换更强模型”，而是“把目标写窄”。
常见断层 2：状态没有设计
很多 Demo 只是把所有信息塞进 Prompt，然后不断续写。
短任务时还能跑，长任务时问题就来了：
- 中间结果没有结构化保存
- 系统会忘记已经做过什么
- 同一个工具被重复调用
- 执行中断后无法恢复
这也是为什么状态管理会成为真实 Agent 系统的核心问题。
常见断层 3：工具调用被过度乐观地看待
在 Demo 里，工具通常默认：
- 一定可用
- 返回格式稳定
- 延迟可接受
- 没有权限问题
但真实情况往往是：
- API 会超时
- 数据格式会变
- 权限会失败
- 返回结果会为空或部分缺失
如果系统没有重试、降级、兜底和错误处理，Agent 就会很脆弱。
常见断层 4：把“会思考”误当成“会执行”
模型很擅长生成看起来合理的解释，但这不等于它真的完成了任务。
常见表现是：
- 说自己分析了，其实没真正调用工具
- 说证据充分，实际上信息不足
- 说已经完成，实际上没满足业务标准
所以生产系统不能只看最终文本，要看：
- 它实际执行了什么
- 用了哪些数据
- 每步结果是否可验证
常见断层 5：没有结束条件和预算控制
Agent 一旦进入循环，如果没有明确约束，就可能不断尝试：
- 再查一个数据源
- 再补一次搜索
- 再换一种问法
- 再试一次工具
这在 Demo 里看起来像“努力”，在真实系统里就是：
- 成本失控
- 延迟失控
- 用户体验崩掉
所以一个可用 Agent 必须有预算和边界，例如：
- 最多调用多少次工具
- 最多运行多少轮
- 超过多长时间必须退出
- 证据不足时是否直接转人工
常见断层 6：没有可观测性
如果系统出错了，但你只能看到最终一句“任务失败”，那几乎没法维护。
至少应该能看到：
- 每一轮状态
- 每一步决定
- 每次工具调用
- 错误原因
- 最终退出条件
这也是为什么很多 Agent 框架后面都会补 tracing、logging、checkpoint 这些能力。
一个更现实的做法
如果你想把 Demo 往真实系统推进，顺序最好是：
- 先把目标缩窄
- 明确状态结构
- 给工具调用加异常处理
- 定义结束条件和预算上限
- 增加日志、追踪和人工接管点
而不是：
- 先换更强模型
- 再堆更多 Prompt
- 然后希望系统自己变稳定
后者通常没有用。
小结
Demo 和真实系统的差别，不在于“规模更大”，而在于“约束更多”。
一个 Agent 真正难的部分，往往不是让它第一次成功，而是让它在复杂输入、工具波动、预算限制和失败情况下仍然可控。
这也是为什么学习 Agent 时，不能只学“怎么搭出来”，还要学“为什么它会坏”。
接下来你可以继续进入：
因为当你开始关心状态、分支、恢复和执行流时，LangGraph 这类框架的价值才会真正变得清楚。