拟人化税：为什么把 Agent 当同事对待会搞坏生产系统

一支工程团队构建了一个处理客户请求的 Agent。演示效果非常好。他们将其部署上线。三周后，这个 Agent 悄无声息地以十足的自信向用户传达错误信息，在上下文变长时跳过步骤，还会在模糊输入上偶尔陷入死循环。事后复盘发现，团队从未构建重试逻辑，从未验证输出，也从未定义 Agent 在不确定时该怎么做。当被问及原因，答案耐人寻味："我们以为它会自己处理那些边缘情况。"

"我们以为它会自己处理那些边缘情况"——这句话将拟人化税表露无遗。团队设计这个系统的方式，就像管理一名初级开发者：简要说明任务，信任其判断，等它举手求助时再纠正。但 LLM Agent 不会举手。它们只是生成下一个 token。

拟人化的真实代价

让 Agent 易于解释的直觉，恰恰也是让它难以可靠构建的原因：它们听起来像在思考。它们使用第一人称语言，用措辞委婉地表达不确定性，用坚定的断言表达自信，用自然语言总结自己正在做的事。把一个说出"我已成功完成任务"的东西，理解为一个概率性文本函数——其输出可能与世界的真实状态毫无关系——在认知上是极其困难的。

ELIZA 效应——得名于 1966 年一个将用户语言反射回去、内部没有任何推理的模式匹配聊天机器人——描述的正是这种偏差。专业知识提供的免疫力十分有限。即便是理解 Transformer 数学原理的硅谷工程师，在设计 Agent 时仍然沿用管理聪明实习生的方式。由此产生的系统设计选择是可以预见的：

• 没有重试逻辑，因为"它自己会想办法重试"
• 没有输出验证，因为"输出看起来没问题"
• 没有迭代次数上限，因为"它知道何时停止"
• 没有上报路径，因为"它困惑时会来问我们"
• 没有故障模式文档，因为"我们会随时处理异常"

这些假设在机制上都不成立。而它们全都会导致生产故障。

复合数学的破坏力尤为惊人。一个拥有 10 个步骤、每步成功率 85% 的 Agent 流水线，端到端成功率仅为 20%。即使每步成功率提升至 90%，10 步下来端到端成功率仍只有 35%——意味着近三分之二的运行会产生错误或不完整的结果。一位研究 Claude 在长时间任务中表现的研究者发现，其"半衰期"约为 59 分钟：一小时任务成功一半，两小时任务仅成功四分之一。这些数字与 Agent 在每一步"听起来"多么自信无关。

具体的故障模式

缺失错误处理。 一个多 Agent 客户支持系统运行了 11 天，两个 Agent 在无人察觉的情况下陷入死循环对话。成本从每周 127 美元飙升至四周 47,000 美元。两个 Agent 都没有检测或打破循环的逻辑。设计假设是 Agent 会意识到无效并停止。这是核心的拟人化错误：Agent 不会建模"无效"的概念；它们只是生成与继续任务模式匹配的下一个 token。

置信度盲目上报。 一家航空公司客服聊天机器人的 AI 助手，以十足的语言自信杜撰了一项并不存在的丧亲折扣政策，并将其告知了一位悲痛的旅客。当公司被提交仲裁时，他们辩称聊天机器人实际上是一个不受其控制的独立实体。仲裁庭不予认可。失败的根源不是模型产生幻觉——这是概率系统的已知属性——而是缺少任何针对真实政策数据的验证层、任何用于向人工上报的置信度阈值，以及任何区分事实检索与合理捏造的机制。

上下文压力下的目标漂移。 Salesforce 的客户端 Agent 部署发现，当给 LLM 超过八条指令时，它开始省略系统提示中的某些指令。其生产数据显示，单轮交互成功率为 58%，多轮交互降至 35%。Agent 并非像心不在焉的人类那样"遗忘"——它在上下文长度相对于训练信号密度增加时经历了指令稀释。设计失败在于假设 Agent 能像一个专注工作的人类那样保持专注。

无边界的工具调用。 一个代码 Agent 在 4.6 小时内调用了 300 多次 npm install，消耗 2700 万个 token 后才被外部强制停止。设计中不存在最大迭代次数。隐含的假设是 Agent 会意识到自己卡住了。但 Agent 无法在任何有意义的层面上"卡住"——无论某个动作之前是否已执行了 300 次，它都以相同的概率处理上下文并生成下一个动作。

不加验证地信任输出。 生产中的 Agent 会定期生成语法上有效但语义上错误的响应：幻觉出来的 API 方法名、返回似是而非但错误结果的 SQL 查询、调用不存在端点的工具调用。针对精心策划的评估集进行测试能捕捉模型错误，却无法捕捉 15–40% 包含缺失字段、格式不一致或模型未被设计处理的数据形状的生产输入。像信任同事答案那样信任 Agent 输出的团队，永远不会构建捕捉这些问题的验证层。

机械化思维模型

对抗拟人化的方法不是对 LLM 抱持愤世嫉俗的态度——而是精确理解它们是什么。LLM Agent 的一次调用，是对一个概率性服务的不可靠 RPC。与任何不可靠的外部依赖一样，它需要工程师在应对不稳定第三方 API 时所采用的同一套基础设施模式：

• 带退避的重试逻辑，用于处理瞬态故障和工具错误
• 输出 Schema 验证，在下游处理前对每个响应进行验证
• 超时和迭代次数限制，用于每个循环和多步骤工作流
• 上报路径，用于失败状态、置信度低于阈值和任务歧义
• 熔断器，用于反复失败的工具

这一重构改变了工程问题的提法。不再是"Agent 聪明到足以处理这个吗？"，而是"当这一步返回意外值时会发生什么？"第一个问题有一个产生脆弱系统的乐观答案。第二个问题有一个产生工程工作的确定性答案。

Google Cloud 2025 年工程回顾直接总结了这一点："可靠性负担应当从概率性 LLM 转移到确定性系统设计——这才是它应该归属的地方。"LLM 处理语言。基础设施处理可靠性。

一个让许多团队感到惊讶的生产洞察：给 Agent 更多工具会降低其性能。多个生产部署通过实证发现了这一点——选项越多，错误选择的采样空间越大，而在宽泛任务上训练的模型在狭窄任务上的置信度-准确率相关性更低。拟人化直觉（"给他们更多资源"）产生了错误的结果。机械化直觉（"将采样空间约束在相关工具集内"）产生了更好的结果。

多 Agent 系统放大了这笔税

拟人化税在多 Agent 架构中成倍叠加。设计多 Agent 系统的团队往往将其建模为组织架构图——协调者"委派"给专家，专家"移交"结果，再由裁判 Agent"审核"。这种框架将人类组织概念（问责、同伴信任、角色清晰）引入了一个这些属性默认并不存在的系统。

协调成本呈非线性增长：两个 Agent 产生一个交互点；十个 Agent 产生 45 个。每个交互都是一个有其自身故障模式的概率步骤。将这些系统设计为扁平组织结构的团队，低估了协调成本是指数级而非线性增长的事实。

信任问题更为微妙。一个常见模式是 Agent A 产生输出供 Agent B 使用。拟人化设计让 Agent B 不验证 Agent A 的输出——为什么需要验证同伴移交的内容？机械化设计以对待任何外部来源同等的怀疑态度处理 Agent B 从 Agent A 收到的输入。当 Agent A 产生幻觉数据结构时，没有这种怀疑态度构建的 Agent B 会将其作为有效数据处理，并将错误传播至下游。没有 Agent 间输出验证的多 Agent 架构，会将局部幻觉转变为系统级的状态污染。

从多个生产框架的 1,600 多条标注轨迹中收集的多 Agent 系统故障分类，识别出 14 种不同的故障模式。其中大多数源于单 Agent 设计缺陷，而非协调失败。在 Agent 层面修正拟人化，比围绕带有错误假设的 Agent 构建协调基础设施更为有效。

实践转变

转变一：先写失败用例。 在编写成功路径之前，先定义失败运行的样子。输出可能有哪些 Schema？工具超时后会发生什么？如果任务无法完成，退出条件是什么？这类文档的缺失是拟人化思维模型的直接产物——你不会为同事编写失败文档，因为同事可以口头表达失败。

转变二：验证每一个输出。 每个 Agent 响应都是不可信的输入。在将任何输出用于下游之前，运行 Schema 验证、范围检查和语义合理性检查。这是外部 API 响应的标准实践；它也应该成为 LLM 响应的标准实践。

转变三：对复合效应进行仪表化。 单步准确率指标掩盖了端到端流水线的故障。如果你的 Agent 有 8 个步骤，每步报告 90% 准确率，那么你的流水线端到端成功率约为 43%。对端到端任务完成率进行仪表化，而不仅仅是单步成功率。

转变四：对确定性需求使用确定性逻辑。 如果一条业务规则是精确的——"在第 3 步后发送确认邮件"、"未经明确批准永不删除记录"、"将所有超过 500 美元的请求上报给人工"——用确定性代码实现它，而不是作为提示指令。提示指令是概率性的；代码是确定性的。各用其所长。

转变五：将"我已完成任务"视为未经验证的说法。 Agent 的成功措辞不是真实的自我报告；它是与完成语言模式匹配的 token 预测。在任务完成时构建显式验证：预期的状态变化是否发生了？预期的产物是否出现了？工具调用响应是否在预期 Schema 范围内？Agent 的完成语言是假设；外部验证才是证据。

认知工作

拟人化税归根结底是一个认知开销问题。对一个以自然语言沟通的系统保持机械化思维模型，需要持续的刻意努力。把 Agent 想成聪明的合作者，比把它想成包裹在工程基础设施中的概率函数要容易得多。

那些持续交付可靠 Agent 的团队，通常内化了一个具体习惯：他们在向彼此解释 Agent 的行为时，不使用心理状态语言。不说"Agent 决定重试"，而说"重试条件评估为真"。不说"Agent 搞混了"，而说"上下文窗口超过了指令遵从度开始下降的临界点"。语言上的转变很小；它所强制执行的设计纪律却是实质性的。

88% 未能投入生产的 AI Agent 项目，大多数失败的原因不是模型出了问题，而是周边系统在设计时仿佛不需要工程化。基准测试差距——精心策划的基准测试上 79% 的准确率对比真实生产任务上 23% 的准确率——不是模型问题。它是为了给人留下印象而设计的系统与为了可靠而设计的系统之间的差距。这个差距就是拟人化税，而它在生产环境中被一笔笔支付着。