Agent 落地的四个工程约束

这是一篇观点文章。我们做过自主规划路线的 Agent，也把它重构掉了。以下是这个过程中撞到的、我们认为绕不开的约束。

---

约束一：可预测性比自主性更值钱

自主规划型 Agent 的卖点是"你给它目标，它自己想办法"。演示效果确实好。

生产环境的问题是：同一个输入，两次执行路径可能不同。

对用户来说，这意味着"这个 AI 时好时坏"——而不稳定比稳定地差更让人无法接受。用户可以适应一个能力有限但行为固定的工具，无法适应一个时灵时不灵的黑盒。

对开发者来说，这意味着 bug 难以复现。用户说"刚才它答得不对"，你重跑一遍，它答对了。

一个实际场景

我们把一个文件处理流程做成了自主规划 Agent。用户上传一份 PDF，Agent 自己决定：先 OCR 识别、再提取表格、然后做结构转换、最后生成摘要。

在内部测试里，10 次运行有 8 次完美、1 次小瑕疵、1 次完全跑偏。8:2 的正确率在演示场景里是可以接受的甚至令人惊喜的。

上线后问题来了：那 2 次错误的 20% 流量里，用户拿到的输出是完全不一样的——有时候是表格提取漏了一列，有时候是 OCR 识别了错误区域，有时候是多做了一步导致整体延迟翻倍。客服收到的反馈是："你们的产品有时能用有时不能用"，"上传同样的文件为什么结果不一样"。

不确定性比确定性差更消耗用户信任。 一个每次都在第三步报错的系统，用户能在第三步做心理准备。一个随机错在不同步骤的系统，用户对每一步都没有信心。

我们的应对

把任务类型显式化：统计真实请求，发现前几类任务能覆盖绝大多数流量，于是为每类任务定好固定的处理路径。牺牲了理论上的通用性，换来行为可预测、问题可定位、成本可估算。

判断标准：如果你的前五类任务覆盖 80% 以上流量，固定路径几乎一定比自主规划划算。

但不是所有场景都应该做固定路径。如果你面对的是长尾任务（没有哪类占比超过 10%），自主规划的价值就会反超。关键是先看数据，再看架构，而不是先定架构。

---

---

约束二：错误会沿链路放大

一个五步的任务，每步 95% 正确，整体正确率是 77%。十步就是 60%。

而 Agent 有个更麻烦的特性：它不知道自己错了，会带着错误继续往下走，而且后面的步骤会为错误的中间结果生成看起来很合理的解释。

错误放大的三种典型形态

形态一：幻觉级联 第一步检索返回了不相关的片段（检索错误），第二步模型基于错误片段生成了看似合理的摘要（生成错误不必然出现但概率被抬高），第三步输出被标注为"基于原文"——原文确实存在，只是跟问题不相关。整个链路看起来每一步都有记录，但答案方向从一开始就偏了。

形态二：格式破坏 第一步输出格式不完全符合第二步的输入要求。第二步解析出错但吐出了一个兜底值继续往下走。到第四步才发现最终结果和预期不符，但中间两步的输出已经不可用了。回退三步重来，代价是四条调用和大量延迟。

形态三：过度自信 模型在某个中间步骤生成模糊输出时，倾向于选择一个最可能的解释并继续，而不是标记不确定性让上游重新确认。这种"先往前走再说"的行为在小任务里是合理的效率策略，在多步骤 Agent 里是风险的放大器。

三条实际有用的应对

• 缩短链路。 能三步做完的不要拆成六步。每增加一步，不只是多了一次出错概率，还多了一次错误被下游"合理化"的机会。
• 每步都有结构化的输出约束。 输出格式错了能立刻发现，比语义错误好抓得多。JSON Schema 校验、必要字段非空检查、枚举值范围检查——这些机械的校验比让模型自己判断"我的输出对不对"靠谱得多。
• 关键节点插人工确认。 尤其是链路后半段——错误在这里被发现，前面的工作还能救。越晚发现，沉没成本越高。

---

约束三：工具调用是最脆弱的一环

模型生成文本的能力已经很强，但调用工具的准确性明显更弱：调错工具、参数格式不对、该调的没调、不该调的反复调。

为什么工具调用这么难

文本生成是模型的"母语"，它在预训练阶段看了几万亿 token 的文本。工具调用是一套"外语"——什么样的表达应该触发一个函数调用、参数怎么填、返回值怎么解读——这些能力主要来自后训练阶段的指令微调，数据量和多样性远不如预训练语料。

还有一个常被忽略的因素：工具调用的反馈链路比文本生成长得多。 文本写错了，下一个词就能修正。工具参数写错了，结果可能要到完整执行完才知道——路径上有网络延迟、服务端处理、结果返回。当反馈到来时，模型已经不知道是哪里导致的问题了。

我们的经验

• 工具描述要写得像给新同事的说明书。 含糊的描述必然导致乱调。好的工具描述应该包含：这个工具做什么、什么情况下用、什么情况下不要用、每个参数的含义和格式、返回值结构、典型错误和应对方式。
• 错误信息要让模型看得懂。 500 Internal Error 对模型毫无帮助；参数 date 格式应为 YYYY-MM-DD，当前值 2026/07/15 无效 能让它自己纠正。我们把错误信息分了两层：用户看到的简洁提示，和模型看到的详细诊断——它才是需要理解错误的那一方。
• 设超时和重试上限。 一个卡住的调用会拖垮整条链路。
• 重依赖的工具隔离运行。 别让一个 PDF 解析崩溃带走整个服务。工具沙箱的隔离不仅是安全需求，也是可靠性需求。
• 工具参数做前端校验。 有些参数错误可以在调用前拦截——比如必填项为空、格式不匹配——一次前端的参数校验比一次失败的远程调用便宜得多。

---

约束四：成本不可控是隐形杀手

自主规划意味着调用次数不确定。一个用户感受不到差别的复杂问题，可能触发十几次模型调用。

上线初期流量小，这个问题不明显。等到用户量上来，账单会给你一个惊喜。

成本的构成拆解

很多人把成本等同于"一次调用花多少钱"，但 Agent 的成本有三个维度：

• 显性成本：模型调用的 token 费用。自主规划 Agent 的调用次数通常 3-10 倍于固定路径方案。
• 延迟成本：多步调用累积的等待时间。用户能忍受等待的前提是"它在做有意义的事"，而不是"它正在走弯路"。
• 机会成本：一次错误的自主探索消耗的额度，本可以用来服务另一个用户的正常请求。

必须做的两件事

把运行过程落成结构化数据。 每一次运行、每一步、每一次工具调用分别记录，包括耗时和消耗。没有这些数据，成本优化就是瞎猜。

我们记录了每条请求的完整链路：从路由分类到每一步的输入输出、token 消耗、实际耗时、工具调用结果、最终质量得分。一个月跑下来，哪些路径是高消耗低价值的，一目了然。

给单次运行设上限。 步数上限、调用次数上限、超时上限。触顶就降级返回，而不是无限循环下去。

降级策略也很重要：不是随机返回一个兜底答案，而是返回"在已完成的步骤中能提供的最好结果"。让用户知道"我能做到这一步，再往下需要更多时间"，比超时后返回一个无关的兜底要好。

---

那么"AI 员工"还成立吗

我们的看法：方向成立，但时间点被大幅提前宣传了。

现在能可靠工作的是这样一类系统：任务边界清晰、步骤有限、关键节点有人确认、出错能被快速发现。它确实能承担相当一部分重复劳动，价值很实在。

而"给它一个模糊目标，它自己搞定一切"——在有真实后果的业务场景里，我们还没见过靠谱的。

这不妨碍它现在就有用。一个把 4 小时工作压缩到 40 分钟（其中 30 分钟是人工审核）的系统，价值已经足够大了，不需要非得追求那最后 30 分钟。

急着把人从环里拿掉，通常是风险的开始。

---

一句总结

Agent 工程的核心不是"让 AI 更自主"，是在自主性和可控性之间找到适合当前业务的那个点。这个点在不同场景里位置不同，但它绝不在"完全自主"那一端。