AI Agent 自我纠错能力实测：自动修复有效吗

前两天有个典型的 Agent 翻车案例。用户要求整理报销单，指令是“按金额降序排列，超标项加标注”。

第一轮，Agent 读取表格、提取字段、完成排序，一切正常。第二轮，它开始调用工具，却将金额列误判为“申请时间”。第三轮，系统让它“复核上一步结果是否合理”，它看了一眼，直接回复“没问题”，随后把错误结果提交出去。

很多初次搭建 Agent 的开发者，都会在这里卡壳。大家误以为“反思”是模型突然拥有了自我审查能力——其实不然。工程意义上的反思机制，本质是一套闭环：先执行，再校验结果，发现偏差后修正。听起来简单，但真正的难点在于：如何让系统识别自身错误、定位错因、自主修复，并在达到上限时及时终止。

先说结论

Agent 具备自我修正能力，但条件非常严格。它能自行修复的通常是以下类型：输出格式错误、工具参数偏差、检索未命中需重试、计划步骤不完整需重规划、输出不满足约束需重写。它难以自行修复的通常是：事实性幻觉、用户意图模糊、工具已执行不可逆操作、权限不足、外部环境变化过快而无法推断。因此，不要把“反思”视为模型突然开悟。更准确的定位是：反思不是为了提升模型智商，而是让系统运行更稳健。

反思到底在反什么

很多人把 reflection、critique、self-check、retry、replan 混为一谈。实际上它们有本质区别。最基础的 Agent 流程如下：

def run(task):
    plan = planner(task)
    result = executor(plan)
    return result

这叫执行。如果加上“检查自身是否正确”，流程变为：

def run(task):
    plan = planner(task)
    result = executor(plan)
    verdict = critic(task, plan, result)
    if verdict["ok"]:
        return result
    return executor(verdict["new_plan"])

这就是最基础的反思闭环。请注意，核心不在于“模型是否会思考”，而在于系统多了一个判断层。这个判断层要回答三个问题：结果是否满足任务目标？结果是否违反约束？若不满足，下一步是重试、重写，还是直接宣告失败？

反思机制通常怎么做

1. 先把过程记录下来

没有过程记录，就没有反思依据。Agent 每一步都必须留下 trace：用户原始任务、中间计划、工具调用参数、工具返回结果、最终输出、失败原因。否则你连“它为什么做错”都无从知晓。这一步类似于线上故障排查——日志不是给机器看的，是给后续判断层使用的。

2. 单独做一个 critic

很多系统将“执行模型”与“审查模型”分离。执行模型负责干活，审查模型负责挑刺。审查提示词通常类似如下：

你是审查员。请检查以下结果是否满足：
1. 是否完成用户任务
2. 是否遵守格式要求
3. 是否存在事实错误
4. 是否调用了不该调用的工具
只输出 JSON：{"ok": true/false, "reason": "...", "fix": "..."}

这类设计的核心价值，是把“主观感觉不对劲”转化为“可执行的判定”。否则反思会沦为一句空话：“我觉得还可以再优化一下。”

3. 给它一个可重试的边界

反思不能无限循环。真正上线的系统都会设定上限：最多重试几次、哪些错误可重试、哪些必须中断、哪些需回问用户。例如：网络超时可以重试，JSON 解析失败可以重写，检索结果太少可以换 query，权限不足不能硬改只能报错。这个边界至关重要——因为 Agent 一旦出错还不停自我修正，很容易把错误越滚越大。

它为什么有时候能自己改

能自我修正，靠的不是神秘能力，而是错误可见。只要系统能检测到偏差，就有机会修正。最常见的可修正问题有四类。

第一类，格式问题

例如要求输出 JSON，结果多了一句无关文本。这类最好修。系统只需加一个校验器：

def validate_output(text):
    try:
        json.loads(text)
        return True
    except:
        return False

校验失败后，将错误信息反馈给模型，让它重写。此类修正成功率通常很高，因为错误明确。

第二类，工具调用问题

例如参数字段写错，或漏传必填项。这类也能修，因为工具通常会返回明确的错误信息：参数非法、字段缺失、资源不存在、调用超时。Agent 拿到这个错误后，就能更新自身下一步动作。

第三类，计划问题

例如初始只规划了三个步骤，执行到第二步才发现缺少信息。此时不是修补，而是重规划。典型流程是：回看当前状态，识别缺口，重新生成后续计划。这也是 ReAct、Plan-and-Execute、Reflexion 等方案的核心。

第四类，检索问题

例如知识库未查准，或查到的文档相关度不足。此时 Agent 可以调整 query 再搜一次。这种“自我修正”本质上不是改答案，而是改输入。这个区别很重要。

它为什么经常改不了

因为很多错误根本不可判定，或者已经不可逆。

1. 它不知道自己错了

这是最常见的问题。模型会一本正经地给出看似合理的答案，但答案与事实不符。没有外部校验，Agent 很难自行发现。因此很多系统必须接入规则校验、结构校验、业务校验、人工审核——单靠模型自省远远不够。

2. 它拿不到真实世界反馈

例如用户让 Agent 修改数据库。Agent 可以说“已经改了”。但如果没有事务、返回码、审计日志和最终落库结果，它根本不知道操作是否成功。这就是 Agent 与纯文本生成的最大区别：文本错了可以重写，动作错了可能已经执行出去了。

3. 它的错误不是局部错误

有些问题不是某一步出错，而是最初的目标理解就偏了。比如用户说“帮我整理一下这个方案”，Agent 却理解成“帮我生成一个汇报模板”。后续再怎么反思，都只是在错误方向上优化。所以反思机制救不了根因错误，只能尽量减少错误被放大。

一个更像样的工程实现

放到线上环境，通常不是单个模型单打独斗，而是多层协同：

Task -> Planner -> Executor -> Observer -> Critic -> Retry/Replan

其中：Planner 负责拆解任务，Executor 负责调用工具，Observer 负责收集结果，Critic 负责判断对错，Retry/Replan 负责修正路径。再往前推，最好还能加上：预算控制、失败上限、权限控制、幂等保护、审计日志。因为一旦 Agent 学会反思，它就不仅是“会说话”，而是在“会行动”。会行动就必须受控。

真正有用的反思，不是复读

很多人把反思做成了另一种 prompt 续写。第一轮说错了，第二轮让模型“请认真检查一下”——结果依然错。原因很简单：没有提供新信息，也没有施加新约束，它凭什么突然修对？因此真正有效的反思，至少需要一个新的变量：新的工具反馈、新的校验规则、新的状态信息、新的失败原因。缺少这些，反思就只是情绪，不是机制。

最后怎么回答这个问题

如果面试官问你：“Agent 的反思机制是怎么实现的？它做错了能自己改吗？”你可以直接这么答：反思机制本质上是一个执行后校验的闭环。系统先让 Agent 完成任务，再通过 critic、规则校验、工具返回和状态观测判断结果是否正确；如果可修正，就触发重试、重写或重规划。它能自己改，但只能改可检测、可逆、局部的问题。比如格式错误、参数错误、检索错误、计划不完整，这些通常能靠反馈闭环修回来。但如果是事实幻觉、意图理解错了、权限不足或者动作已经不可逆，那就不能指望它自己“反省一下”就修好。说白了，Agent 的反思不是玄学，是工程控制。它不是在思考人生，它是在尽量别把错一路放大。

来源：互联网