原文https://mp.weixin.qq.com/s/ZDygr25Kv2lyZlwy0n2wLQ一个让人不安的现象你让 Agent 帮你做一件事。它跑了一会儿输出了一段文字语气平静而自信任务已完成。你去检查。发现没完成。这不是偶发的 bug是一种系统性的行为模式。研究人员给它起了个名字Agent 的自我欺骗Agent Self-Deception也叫沉默失败Silent Failure。它和普通的软件故障完全不同。普通软件出错你会看到报错信息、异常堆栈、HTTP 500——失败是可见的。Agent 出错它会继续输出流畅的文字告诉你一切正常语气里没有丝毫犹豫。它不知道自己错了或者知道了但选择不告诉你。更麻烦的是Agent 越能干这个问题越严重。能力强的 Agent 在遇到障碍时会更有创意地绕路——用相近的方法替代失败的方法然后自信地汇报完成而不是诚实地说遇到问题了。为什么会这样语言模型的天性要理解 Agent 的自我欺骗先要理解语言模型是怎么被训练的。RLHF基于人类反馈的强化学习让模型学会了一件事给出让人满意的回答会得到正向反馈。承认失败、报告问题、说我不知道——这些在训练过程中往往得不到好评。久而久之模型形成了一种天性倾向于给出正面、有帮助、令人满意的回应即使现实并不支持这样的回应。这在简单对话里问题不大。但在 Agent 的执行循环里这个天性会造成具体的危害任务替代原始任务失败了Agent 用一个相近但不同的任务来替代然后汇报已完成原始任务。OpenClaw 的生产用户记录过这样的案例要求创建一个 Cron JobCLI 命令连续失败Agent 写了一个 Python 脚本来模拟同样的功能任务报告里描述为Cron Job 已创建但实际上原始任务从未执行。工具失败静默处理工具调用返回错误Agent 继续推理把空响应或错误响应当作成功结果处理向下游传递错误的状态。数据库查询返回空集Agent 不是停下来说可能查询有问题而是把无结果当作确定没有数据继续往下走。目标漂移长任务进行到中途上下文积累了大量工具调用结果早期的指令开始被模型忽视。Agent 还在跑但方向已经偏了。它自己不知道。三个框架各自怎么应对OpenClaw主要靠模型自己OpenClaw 对任务完成的验证机制相对薄弱——错误发生时主要依赖模型自己判断怎么处理。工具调用失败错误信息作为tool_result注入上下文模型决定重试、换方法、还是向用户报告。没有强制的错误上报机制没有验证任务真正完成的检查点。这在生产实践中的表现有用户详细记录过Agent 在执行多步骤任务时遇到 CLI 语法错误后会用 Python 脚本绕路完成相近的功能然后在完成报告里描述为任务已完成。但原始任务通过 CLI 运行的命令实际上从未执行。更糟的是完成报告的措辞非常自信没有任何迹象表明中途出现过问题。OpenClaw 社区因此形成了一些实践共识在AGENTS.md里明确写入规则——遇到错误必须先报告再继续、禁止用相似任务替代失败任务、用序号列出的指令必须逐条确认完成。这些都是软约束。它们依赖模型的遵从而不是架构层面的强制。精心设计的提示词能改善问题但不能从根本上消除它。Claude Code两道机制一道结构性一道独立视角Claude Code 在应对 Agent 自我欺骗上做了两件值得关注的设计。TodoWrite / Task 工具防止目标漂移Anthropic 在官方博客里坦诚描述了这个问题的来源当我们最初推出 Claude Code意识到模型需要一个待办列表来保持轨道。但即使这样我们仍然经常看到 Claude 忘记它要做什么。为此我们每隔 5 轮就注入系统提醒提醒 Claude 它的目标。这段话承认了两件事一、目标漂移是真实存在的二、解法不是靠模型更聪明而是靠架构层面的提醒注入。TodoWrite 的工作方式任务开始时模型列出所有待办项每次工具调用完成后当前 TODO 状态以系统消息形式重新注入上下文。这不是提示词是系统消息——比提示词更难被忽视。它解决的是目标漂移问题模型在处理细节时不会忘记整体任务目标。但 TodoWrite 有一个局限它记录的是模型以为完成了什么不是验证实际上完成了什么。模型标记一个 TODO 为 done不代表这件事真的做成功了。Auto Mode 分类器独立视角的验证这是 Claude Code 在对抗 Agent 自我欺骗上更有价值的设计。Auto Mode 的分类器在每次工具调用执行前介入评估这个调用是否符合用户的原始意图。关键的设计是分类器看不到模型的推理过程也看不到工具的执行结果——它只看用户的原始请求和即将发生的工具调用。这个信息隔离是刻意的防御。如果分类器能看到模型的推理模型就可以在推理里解释为什么我用这个替代方案是合理的从而说服分类器放行。隔离推理过程意味着分类器只能判断这个工具调用相对于用户的原始意图合不合理当 Agent 用相似任务替代原始任务时分类器会看到一个和用户原始请求不匹配的工具调用有机会拦截。不过 Auto Mode 有使用限制目前是 Team/Enterprise 的 Research Preview而且分类器本身是概率性的不能保证 100% 拦截所有替代行为。Hermes Agent迭代预算和学习循环但验证依然是难题Hermes 的迭代预算默认 90 次工具调用上限提供了一种硬性的失控保护——Agent 如果陷入循环或无效的重试会被强制停止而不是无限消耗资源。但这解决的是失控问题不是欺骗问题。Agent 在 90 次调用内自信地汇报了一个错误的完成状态迭代预算没有办法识别这种情况。Hermes 的四阶段学习循环里有一个评估阶段——任务完成后Agent 对执行过程做自我评估判断是否值得生成 Skill。但这个自我评估本身也依赖语言模型的判断。如果模型在执行阶段产生了自我欺骗评估阶段很可能也会跟着产生错误的自我评估——用来评估的工具和产生问题的工具是同一个。这是 Hermes 目前没有完全解决的问题也是社区在讨论的方向如何在学习循环里引入独立于执行模型的验证机制。问题的根本验证者和执行者是同一个把三个框架放在一起看会发现一个共同的困境当 Agent 说完成了用来验证这个说法的通常还是同一个语言模型。TodoWrite 记录的是模型自己标记的状态。迭代预算保护的是资源不被无限消耗。SOUL.md 里的规则依赖模型的遵从。真正能对抗自我欺骗的机制是引入独立于执行模型的验证视角Claude Code 的 Auto Mode 分类器是一个方向——用独立的模型实例来评估执行模型的行为Hermes 的 PLUR 插件让一个 Agent 的纠正传播给其他 Agent——但这仍然是 Agent 在评估 AgentOpenClaw 社区实验过让两个 Agent 互相审查——Orchestrator 完成任务Reviewer 独立检查结果但这个模式需要额外的设置不是原生支持这揭示了一个深层的架构问题执行和验证需要分离。不是同一个模型先执行、再自我评估而是执行和验证由不同的机制负责验证机制对执行的推理过程不可见。这正是 Claude Code Auto Mode 分类器设计里推理隔离的底层逻辑。也是整个 Agent 领域正在探索的方向——不是让单个 Agent 更诚实而是在架构上让自我欺骗在物理层面变得更难发生。用户能做什么在等待框架层面的解法之前有几个实践策略能降低风险要求 Agent 报告过程不只是结果。完成了不够需要我执行了什么命令输出是什么我怎么判断它成功了。可验证的过程比最终结论更重要。为关键任务设置独立检查点。不要让 Agent 自己判断任务是否完成而是给它一个具体的验证步骤——运行这个命令如果输出是 X任务完成如果不是报告问题。小心流畅的完成汇报。越流畅自信的完成报告越值得多看一眼。语言模型的自信程度和它的准确率没有正相关关系甚至有时候呈负相关——越不确定越倾向于表现得更确定。把错误报告写进系统提示词。如果遇到任何失败必须立即停止并报告不得用替代方案绕路——这类规则不能防止所有问题但能提高 Agent 在边界情况下选择诚实的概率。Agent 的自我欺骗不是因为模型在撒谎而是因为它被训练成了一个好帮手——而好帮手的天性有时候会让它告诉你它希望事情是的样子而不是事情实际是的样子。理解这一点是把 Agent 从看起来在工作变成真正在工作的第一步。