Agent 智能体工程落地：为什么复杂链路反而不稳定

刚接触 Agent 的时候，我也有个错觉：工具挂得越多、推理链路越长、自主决策权限给得越大，这个 Agent 就越"聪明"。后来真在项目里做了几个，被现实狠狠教育了一顿——复杂度跟稳定性，往往是反着来的。

为什么复杂度反而带来不稳定

原因其实不复杂。大模型做推理本质上是有随机性的，它每次生成都带概率，不是确定性程序。你把它放进一条很长的链路里，一环出错，错误就会像滚雪球一样往下传：第一步参数解析错了，后面的每一步都基于错误继续跑，最后整个流程报废。而且模型推理是个黑盒，出了问题你想定位是哪一步的 bug，难度非常大。

这里有个概率上的残酷事实：假设每一步的失败率只有 1%，一条 20 步的链路，整体失败率就会逼近 18%。步骤越多，出错率不是线性叠加，而是指数累积。所以"链路越复杂越不稳定"不是玄学，是数学。这也是为什么业界对 Agent 的态度越来越谨慎——"看起来聪明"和"真正可靠"之间，隔着一整条工程线。

还有成本问题。多轮推理、多工具嵌套调用，上下文会不断累加，Token 消耗呈指数级往上涨，推理延迟也越来越高。一个商业系统如果跑这么一条链路，光是 Token 费用和响应超时就能把你愁死。我见过一个 Agent 任务，跑了 30 多轮工具调用，单次任务 Token 成本就顶得上普通用户一个月的量。

四类最常见的失控场景

我在落地过程中总结了四类最常见的失控场景，写下来供你对照排查：

第一，链式错误传导。模型第一次解析工具参数就错了，后续所有步骤都基于错参数执行，一路错到底。这种错最坑的地方在于——它不会立刻暴露，而是等到最后一步才报错，你根本不知道问题出在源头。

第二，上下文溢出。对话轮数太多，超过模型上下文上限，后面的步骤直接"失忆"，不再参考前面的信息。很多模型有上下文长度限制，Agent 一旦跑长了，前面的关键信息就被挤掉了。这个问题的解法是"上下文管理"——把早期对话压缩成摘要，只保留关键状态。

第三，死循环。工具调用失败后，模型反复用同样的参数重试，直到触发轮次上限才停下。这个既烧钱又卡流程。常见于"工具返回了错误，模型没看懂，又原样重试"的场景，本质上还是工具描述写得不清楚。

第四，高危操作失控。Agent 握着删除、修改这类高权限工具，误操作了数据，等发现的时候已经晚了。这是最严重的一种，因为它不只是"任务失败"，而是"事故"。

核心原则：Workflow 优先，Agent 兜底

所以我的核心原则就一句话：Workflow 优先，Agent 兜底。

步骤固定、逻辑明确、流程标准化的业务，一律用静态工作流（Workflow）把流程固化死——它 100% 可控、低延迟、零偏差，完全不需要模型的"智能"掺和。只有当任务真的步骤不确定、需要自主探索、需要动态决策的时候，才启用 Agent。

这背后的判断标准是"任务的可确定性"：如果任务的步骤在写代码的时候就能列清楚，那就用 Workflow；如果步骤要等运行时才知道，才考虑 Agent。大多数业务其实是"看似不确定，其实可以结构化"的——把它们切成固定步骤，能省掉 90% 的 Agent 问题。

就算要用 Agent，也必须给它套上缰绳：轮次上限、工具职责单一化、高危操作人工鉴权、全链路降级容错。这几点我在另一篇文章《Agent 工具调用工程规范》里详细展开过。

可观测性和测试不能省

最后补两个工程细节。一个是可观测性：Agent 的每次推理、每步工具调用，都要记录入参、出参、中间推理，方便出问题时复盘定位。另一个是测试：要专门构造失败场景——工具返回异常、参数边界、用户中途取消、并发调用、权限不足——每个场景都要有明确的兜底行为。没有这些测试，你的 Agent 只能算演示，不能算可上线。

评估一个 AI 系统的好坏，看的是稳定性、可控性、可复盘性，而不是它演示的时候有多"聪明"。先把成功路径固化下来，再谈开放动态路径，这是我踩坑换来的经验。记住一句话：Agent 的价值不在"能自主"，而在"自主的同时可控"。