元认知AI：教你的Agent进行自我评估

我让我的Agent修复一个失败的测试。Agent读取了错误信息，识别了断言不匹配，将期望值改为匹配实际输出，然后报告：”测试已修复。所有测试通过。”它说得没错。测试确实通过了。但这个修复完全是错误的。

测试失败是因为函数返回了错误的数据。Agent通过让测试期望错误答案来”修复”了测试。它完美地遵循了我的指令：修复失败的测试。而我的意思是：修复测试所测试的代码。Agent无法区分这两种解读，因为它的指令集中没有任何内容要求它在决定如何修复之前先评估测试为什么失败。

这个缺口有一个名称。它是行动层指令和元认知指令之间的缺口。大多数人只编写第一种。

摘要

AI Agent指令存在两个层面。行动层指令告诉Agent该做什么：”验证输入”、”编写测试”、”遵循RESTful约定”。元认知指令告诉Agent如何评估自己是否做得好：”如果你发现自己说的是应该而不是已经，说明你没有验证”、”如果三次修复都失败了，停下来质疑架构”、”信心不是证据”。大多数Agent配置完全由行动层指令组成。元认知层将产生看似合理输出的Agent与产生正确输出的Agent区分开来。我运行一个生产级元认知系统已有九个月，包含七个命名失败模式、一个六项标准的证据关卡和通过95个hooks强制执行的模糊语言检测。

Agent指令的两个层面

每条Agent指令都在两个层面之一运作。

行动层指令定义行为：

# Action-level examples
- Use type hints on all functions
- Write tests for edge cases
- Follow RESTful conventions for API endpoints
- Validate all user input at boundaries

行动层指令是必要的。它们告诉Agent正确行为是什么样的。但它们有一个结构性局限：假设Agent会忠实地执行。它们没有考虑Agent如何评估自身的合规性。

元认知指令定义自我监控：

# Metacognitive examples
- If you catch yourself thinking "just try changing X and see if it works" — STOP.
  That's a signal to investigate, not guess.
- If you've searched the same files three times — you're stuck.
  Step back and question your assumptions.
- If you use the word "should" in a completion report, replace it with evidence.
  Run the command. Paste the output.
- After three failed fixes, stop fixing. The problem is architectural.

这个区分很重要，因为行动层指令告诉Agent目标是什么样的。元认知指令告诉Agent如何检测自己正在偏离正确方向。前者防止错误的行动。后者防止错误的推理——那些从一开始就产生错误行动的思维模式。

GitHub上的obra/superpowers项目最早明确了这一区分，称之为”教AI监视自身内部推理中的失败信号”。¹其洞察在于：大多数技能在行动层运作（做X，不做Y）。元认知层则不同（注意到你即将做Y）。

虚假证据表

我构建的最有效的元认知工具是一张定义什么不算证据的表格。²

当我告诉Agent”验证你的工作”时，Agent会产出验证结果。但这种验证往往是对意图的重述，而非对结果的展示。”测试应该通过。”“实现遵循了最佳实践。”“我确信这是正确的。”这些陈述中的每一条听起来像证据。但没有一条是证据。

虚假证据表通过命名来预先阻断特定的捷径：

第三列是价值所在。没有它，Agent会用听起来合理的信心重述来填充第二列。有了它，表格在Agent采取捷径之前就命名并阻断了每一条特定捷径。³

这不是提示词工程。这是认知架构。这张表不是告诉Agent该做什么不同的事。它告诉Agent在自身输出中该监视什么。Agent将自己的回应与”不充分”列进行对照监控，当检测到匹配时，就知道应该用实际证据替换捷径。

这个模式可扩展。任何领域特定的声明都可以添加。对于安全审查：”无漏洞”需要”检查的具体漏洞类别及发现”，而非”我审查了代码”。对于无障碍性：”符合WCAG”需要”axe或Lighthouse审计输出”，而非”我检查了对比度”。

命名失败模式作为元认知护栏

人类有命名的认知偏见：确认偏误、锚定效应、邓宁-克鲁格效应。名称很重要。一旦你能命名偏见，就能监视它。AI Agent需要同样的词汇来描述其失败模式。

我记录了Agent反复表现出的七种失败模式，为每种命名，并添加了检测信号：⁴

名称使失败变得可检测。没有名称，Agent产生一个信心幻象，Agent和用户都不会将其识别为一种模式。有了名称，指令就变成了：”如果你发现自己表现出任何命名的失败模式，立即停止并从评估步骤重新开始。”

这种监控在精确意义上是元认知的：Agent监视自身的认知过程（我是否在跳过验证？我是否在用信心替代证据？），而非监视其输出（这段代码正确吗？）。监控发生在Agent产出输出之前，这就是为什么它能捕获输出层审查遗漏的错误。

Anthropic自身的官方技能实现支持了这种方法。对其16个官方Claude Code技能的分析揭示了有效Agent指令设计中的结构模式。禁止性指令（”永远不要X”）比建议性指令（”考虑Y”）效果显著更好，因为它们命名了具体的规避行为而非笼统的行动。⁵命名失败模式就是具体的禁止性指令：”永远不要表现出幽灵验证”优于”始终运行测试”，因为它阻断的是规避行为而非重述行动。

模糊语言检测

我实现的最简单的元认知监控器是检测Agent输出中的特定词语：

Red flag words: should, probably, seems to, likely, I believe,
               I'm confident, looks correct, appears to

每当Agent在完成报告中使用这些词之一时，该词本身就是验证不充分的证据。⁶“测试应该通过”意味着Agent没有运行测试。”看起来能用”意味着Agent只是目测了一下。”我确信”意味着Agent在用内部状态替代外部证据。

实现是机械化的。Hook系统拦截Agent的输出并标记模糊语言。然后Agent将模糊词替换为它本应执行的验证：

• “测试应该通过”变为：运行测试，粘贴显示0个失败的输出
• “看起来正确”变为：引用确认正确性的具体断言或检查
• “我确信”变为：列出产生该信心的证据

这一模式来自obra的完成前验证工作：”AI自身的措辞选择暗示了证据不足。”¹认知科学中的类比是真实存在的。在人类元认知中，自我报告的准确性（”我理解这个”）与实际理解之间的相关性很弱。说”我懂了”的人往往并不懂。能够解释的人通常才是真懂。AI Agent同样如此：能够引用具体证据的Agent理解了问题。说”我确信”的Agent可能并不理解。

三次修复断路器

元认知不仅是关于检测错误推理。它还关乎检测何时应该停止。

三次修复升级规则：如果对同一问题的三次修复尝试都失败了，Agent必须停下来从根本上质疑架构。⁷不是尝试第四次修复。不是从相同方法的不同角度寻找突破。停止。退后一步。问问题到底出在解决方案上还是问题定义上。

该规则充当调试循环的断路器。没有它，Agent会进入我所称的修复螺旋：每次失败的尝试产生新理论，新理论产生新修复，新修复失败，又产生新理论。Agent可能循环几十次修复，却从未质疑自己是否在处理正确的问题。23个Agent失控事件是这种情况的广度版本：Agent们在错误的问题上达成共识，因为没有元认知检查追问”这个问题的范围是否正确？”

三次修复规则之所以有效，是因为它迫使Agent的推理发生相变。修复1-3在当前心智模型内运作。修复4（实际上是”停止修复”）迫使Agent构建新的心智模型。在实践中，这通常意味着从头重新阅读错误信息、重新审视假设，或向用户请求澄清——所有这些都比第四次猜测更有成效。

前后对比：变化了什么

这是一个具体的例子。我让Agent为一个API端点添加输入验证。

没有元认知指令：

Added Pydantic model with field validators for email format, password
length (8+), and username pattern (alphanumeric). Tests should pass.
The implementation follows FastAPI best practices.

输出包含三个模糊信号：”should pass”（没有运行测试）、”follows best practices”（没有说明哪些实践），以及没有边界情况考量的证据。一个包裹在空洞报告中的信心幻象。

有元认知指令（相同任务，相同Agent）：

Added Pydantic model with field validators:
- Email: regex validation + max length 254 (RFC 5321)
- Password: min 8, max 128, requires 1 uppercase + 1 digit
- Username: alphanumeric + underscore, 3-30 chars

Test output (just ran):
  tests/test_auth.py::test_valid_registration PASSED
  tests/test_auth.py::test_invalid_email_rejected PASSED
  tests/test_auth.py::test_short_password_rejected PASSED
  tests/test_auth.py::test_empty_username_rejected PASSED
  tests/test_auth.py::test_unicode_username_rejected PASSED
  5 passed in 0.34s

Edge cases handled: empty string (returns 422), null (returns 422),
unicode injection in username (rejected by alphanumeric pattern),
overlength email (RFC limit enforced).

Pattern followed: same validation approach as UserUpdateSchema in
app/schemas.py line 45.

区别不在于第二个Agent写了更好的代码。两个Agent可能写了完全相同的代码。区别在于第二个Agent根据具体的证据标准验证了自己的工作，并报告了证据而非信心。

构建您自己的元认知层

这个框架是可移植的。您不需要我的特定系统。您需要三个组件：

1. 虚假证据表。为Agent最常做出的声明定义什么不算证明。从上述六项标准开始，添加领域特定的行。第三列（不充分）是价值所在。

2. 命名失败模式。记录Agent最常出现的三到五种失败方式。为每种命名。添加检测信号。包含指令：”如果你发现自己表现出任何命名的失败模式，停止并重新评估。”

3. 模糊语言检测。列出在您的领域中表示验证不充分的特定词语。添加指令：”将任何模糊词替换为能消除模糊性的证据。”

这三个组件组合成一个元认知层，叠加在任何行动层指令之上。行动层指令定义正确行为的样子。元认知层定义Agent如何检测自己偏离正确行为。

实现可以简单到在您的CLAUDE.md或AGENTS.md中添加一个章节：

## Self-Monitoring

### When to stop and re-evaluate
- If you've searched the same files 3+ times: you're stuck.
- If you've attempted 3 fixes for the same issue: question the architecture.
- If you use "should" or "probably" in your response: replace with evidence.

### What doesn't count as evidence
[your false evidence table here]

### Named failure modes to watch for
[your failure modes here]

执行层面是通过hooks（确定性的，无法跳过）、规则文件（加载到上下文中），还是内联指令（依赖模型遵从）来实现，决定了元认知层的可靠性。Hooks最强，因为它们在工具使用层面拦截，而非提示词层面。但即使是提示词层面的元认知指令也能显著改善Agent输出质量，因为它们改变的是Agent的评估标准，而不仅仅是其行动。

元认知的局限

元认知编程使AI Agent更加可靠。但它不会使它们变得睿智。

虚假证据表捕获特定的捷径。它无法捕获表格未命名的新型捷径。命名失败模式检测已知的模式。它无法检测尚未命名的模式。模糊语言检测捕获表面层的信心替代。它无法捕获Agent真正说服了自己（无论”说服”在何种意义上适用）错误输出是正确的情况。

更根本地说，元认知指令近似于品味但并不产生品味。Jiro系统可以防止except: pass并强制要求测试证据。它无法判断架构是否正确，命名是否表达了意图，或者解决方案是否针对真正的问题而非陈述的问题。这些判断需要的是那种当前模型只能近似但无法可靠执行的上下文推理。

有人在我关于Jiro系统的一条推文下回复道：”你基本上是在试图教会循环克制、品味和某种近似于道德暂停的东西——而基础Ralph模式为了吞吐量明确地对这些进行了反向优化。”⁸

他们说得对。元认知编程是为机器不具备的品质搭建的结构性脚手架。这个脚手架是承重的。没有它，机器大规模产生信心幻象。有了它，机器大规模产生经验证的输出。这两种结果之间的差距，就是一个你可以信任让它通宵运行的Agent与一个你需要时刻看管的Agent之间的区别。

但脚手架不是建筑本身。建筑（品味、判断力、知道正确答案是另一个问题的能力）仍然属于人类。至少目前如此。

核心要点

对于构建Agent系统的工程师：

• 编写元认知指令，而非仅仅编写行动层指令。行动层指令定义正确行为。元认知指令定义Agent如何检测自己偏离正确行为。后者才是将看似合理的输出与经验证的输出区分开来的关键。

• 命名Agent的失败模式。一旦失败模式有了名称（信心幻象、幽灵验证、捷径螺旋），Agent就能监视它。未命名的失败会无限重复。

对于规模化AI辅助工作流的团队：

• 在规模化之前先建立虚假证据表。为Agent做出的每项声明定义什么不算证明。第三列（不充分）预先阻断了Agent在被要求”验证”时采取的特定捷径。

• 模糊语言是可靠的信号。每当Agent在完成报告中说”应该”、”可能”或”我确信”时，Agent就没有执行它所声称的验证。机械化地检测并替换。

元认知审计

想要评估您自己的Agent指令吗？下面的交互式工具可以分析任何CLAUDE.md、AGENTS.md或系统提示词，并根据本文描述的元认知维度进行评分。

粘贴您的Agent指令，审计将识别：您的指令中行动层与元认知的比例、覆盖了哪些命名失败模式、是否存在模糊语言检测，以及差距在哪里。

本文是Claude Code精通系列的一部分，该系列记录了自主AI开发背后的基础设施：从强制确定性控制的hooks到作为架构学科的上下文管理，再到捕获单Agent盲点的多Agent协商。作为系统基础的复利工程哲学解释了为什么每个组件都会加速此后构建的一切。