Agent 防错机制：从错误记录到规则硬化

痛点：你的 Agent 犯了个错误。你纠正了它。它道歉说"明白了，我会记住"。一周后它又犯了同样的错误——只是换了个面孔。你不断治疗症状，问题却从未真正解决。

你将学到：

为什么"下次要留意"是 Agent 开发中最大的谎言——以及为什么 LLM 内存永远无法替代系统级规则

五步纠正沉淀循环：错误发生 → 记录 → 提取根因 → 嵌入规则 → 永不重复

一个具体的 FailureRecord schema 和一个 SCENE_CONFIG 示例，可以物理化加固你的 Agent

如何将规则"物理化"为验证脚本、门禁检查、工具白名单和 SOP 注入

为什么纠正沉淀对生产系统的效果超过"更强的模型"——以及两者如何互补

1. 问题所在："下次要留意"是最大的谎言

当 LLM Agent 犯错时，最常见的处理方式是这样的：

Developer: This is wrong. Next time, pay attention.
Agent: Got it. I'll remember. Next time I'll be careful.
(One week later)
Agent: Made the same mistake again — just in a different disguise.

为什么"下次要留意"永远不起作用？

因为 LLM 的"内存"是一个软约束。它在多轮对话中会忘记。它在长上下文中的注意力会偏移。在压力下，它会退回到"最舒适的"生成模式。当你让它"记住"时，它只是在当下同意——它没有能力在系统层面"嵌入"规则。

这就是实验室原型和商业系统之间的分水岭：

实验室原型：改进依赖于 LLM 的"内存"（软约束——它会遗忘）

商业系统：改进依赖于工程级的"嵌入"（硬约束——它永不遗忘）

💡 核心洞察：每一个人工纠正都是一个规则嵌入的机会——不要告诉 LLM"下次要留意"；直接修改验证脚本或添加门禁检查，使系统永久阻止这类错误。

纠正沉淀是一个五步的闭合循环——每一个失败都给下一次纠正提供养分。

2. 核心机制：五步闭合循环

纠正沉淀是一个完整的五步循环：

① Error occurs → ② Record → ③ Extract root cause → ④ Embed rule → ⑤ Never repeat

第 1 步：错误发生

Agent 产生不符合要求的输出。它被某个门禁拦截，或者开发者/用户手动发现它。

第 2 步：记录

将其记录到失败存储中——不仅仅是错误信息，还包括：场景、工具调用链、上下文摘要和错误类型。

failure_capture.py --record \
  --scene email \
  --tool-calls '["fetch_inbox", "send_email"]' \
  --error "user asked to forward the email to sunny, but the agent queried shipping costs"

第 3 步：提取根因

分析错误并找到真正的原因——不是表面描述"Agent 使用了错误的工具"，而是"邮件场景的工具白名单中缺少 smtp_send"。

第 4 步：嵌入规则

将根因转化为可执行的规则：

• 修改验证脚本
• 更新场景的工具白名单

# Before hardening
SCENE_CONFIG = {
    "email": {
        "tools": ["imap_fetch", "contact_lookup"],  # smtp_send is missing
    },
}

# After hardening
SCENE_CONFIG = {
    "email": {
        "tools": ["imap_fetch", "smtp_send", "contact_lookup"],  # smtp_send added
        "gates": ["check_forward_intent"],  # new gate added
    },
}

第 5 步：永不重复

一旦规则被嵌入，系统会自动阻止该错误——没有人需要"留意"，错误变得不可能发生。

3. 技术实现

3.1 失败记录格式

每一个纠正都需要一个结构化的位置。这是失败存储使用的 schema：

from dataclasses import dataclass

@dataclass
class FailureRecord:
    """A record of one failure/correction"""
    timestamp: str
    scene_id: str
    error_type: str      # tool_misuse / format_error / missing_step
    description: str     # human description
    root_cause: str      # root-cause analysis
    fix_rule: str        # the embedded rule
    status: str          # pending / embedded

3.2 规则物理化

这里是让整个机制运作的规则：每一个被嵌入的规则都必须被"物理化"到系统层——不是写进 prompt，而是写进脚本。

失败存储坐在门禁和四个嵌入目标之间——规则存在脚本中，不在 prompt 中。

嵌入不是一次性的动作。规则会衰减，场景会改变，新的错误类型会出现——所以循环需要定期的审查节奏：

# every Monday, auto-scan corrections that have not been embedded yet
scan_corrections.py --unembedded
# output: 3 new corrections this week, 2 embedded, 1 pending analysis

每一个未嵌入的纠正都要再次经过根因分析。每一个被嵌入的规则都必须通过回归测试套件后才能被信任：

回归验证关闭了循环——每一条规则在被信任前都被证明了。

4. 为什么这比一个更强的模型更重要

许多人认为 Agent 犯错是因为模型不够聪明，转换到一个更强的模型会解决一切问题。

这是一个误解。

一个更强的模型确实会降低错误率——但它永远不会达到 100%。而纠正沉淀则相反，它将任何已发现的错误转化为"不可能再发生"，无论模型有多强或多弱。

两者是互补的：

更强的模型 → 降低未知错误的发生率

纠正沉淀 → 消除已知错误的重复率

商业系统不追求"永远不犯错"。它们追求"在犯错后自动改进"。纠正沉淀是那种自动改进的底层机制。

5. 你现在的位置

现在，你不再是那个无助的开发者，每次 Agent 犯错后都告诉它"下次要留意"。你正在成为一个工程师，能够将每一个错误转化为系统的进化燃料。

每一个人工纠正都不是浪费的努力——它在为系统的一次进化供应养分。错误 → 记录 → 根因 → 嵌入规则 → 永不重复同样的错误。日复一日，系统变得更稳定，你的维护成本不断下降。

下一篇文章：最后一个安全支柱——工具隔离和最小权限原则，完全锁定 Agent 的行为边界。

关于作者：无记（Wu Ji）——专注于 Agent 工程、Loop Engineering 和数字化转型的 AI 与数字化从业者。实践性的手把手教程——跟着做就能成。

---