Agent 做错了，真能自己改吗？

前两天有个很典型的 Agent 翻车场景。

用户让它去整理一份报销单，要求是“按金额从高到低排序，顺手把超标的标出来”。

第一轮，Agent 读表、抽字段、排序，一切正常。

第二轮，它开始调用工具，结果把金额列当成了“申请时间”。

第三轮，系统又让它“检查一下自己刚才的结果是不是合理”。

它看了一眼，居然回了一句：

★“结果看起来符合任务目标，继续执行。”

然后就把错误结果提交出去了。

很多人第一次做 Agent，都会卡在这里。

大家以为“反思”是模型脑子里突然有了自省能力。其实不是。

工程里所谓的反思机制，本质上就是一套闭环：

1. 先做
2. 再看结果
3. 发现不对
4. 再修正

听起来很朴素，但真正难的是，怎么让系统知道自己错了，错在哪，能不能改，改到什么程度就该停。

先说结论

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. 结果是否满足任务目标
2. 结果是否违反约束
3. 如果不满足，接下来是重试、重写，还是直接失败

反思机制通常怎么做

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 拿到这个错误，就能更新自己的下一步动作。

第三类，计划问题

比如一开始只想了三步，执行到第二步发现缺信息。

这时候就不是修补，而是重规划。

典型流程是：

1. 先回看当前状态
2. 找出缺口
3. 重新生成后续计划

这也是很多 ReAct、Plan-and-Execute、Reflexion 类方案的核心。

第四类，检索问题

比如知识库没查准，或者查到的文档不够相关。

这时候 Agent 可以改 query，再搜一次。

这类“自我修正”本质上是：

不是改答案，而是改输入。

这个区别很重要。

它为什么经常改不了

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

1. 它不知道自己错了

这是最常见的问题。

模型会一本正经地给出一个看似合理的答案，但这个答案和事实不一致。

如果没有外部校验，Agent 很难自己发现。

所以你会看到很多系统都要接：

• 规则校验
• 结构校验
• 业务校验
• 人工审核

光靠模型自省不够。

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

比如用户让它帮忙改数据库。

它可以说“我已经改了”。

但如果没有事务、返回码、审计日志和最终落库结果，它根本不知道这次操作到底有没有成功。

这就是 Agent 和纯文本生成最大的差别。

文本错了可以重写，动作错了可能已经执行出去了。

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

有些问题不是某一步错了，而是最开始的目标理解就错了。

比如用户说“帮我整理一下这个方案”，Agent 却理解成“帮我生成一个汇报模板”。

这种错误后面再怎么反思，都只是在错误方向上优化。

所以反思机制救不了根因错误，只能尽量减少继续放大。

一个更像样的工程实现

如果把它放到线上，通常不是一个模型单打独斗，而是这几层一起配合：

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

其中：

• Planner 负责拆任务
• Executor 负责调用工具
• Observer 负责收集结果
• Critic 负责判断对错
• Retry/Replan 负责修正路径

再往前一点，最好还有：

• 预算控制
• 失败上限
• 权限控制
• 幂等保护
• 审计日志

因为一旦 Agent 会反思，它就不只是“会说话”，而是在“会行动”。

会行动，就必须受控。

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

很多人把反思做成了另一种 prompt 续写。

第一轮说错了，第二轮让模型“请认真检查一下”。

结果还是错。

原因很简单。

你没有给它新的信息，也没有给它新的约束，它凭什么突然修对？

所以真正有效的反思，至少要有一个变化：

• 新的工具反馈
• 新的校验规则
• 新的状态信息
• 新的失败原因

没有这些，反思就只是情绪，不是机制。

最后怎么回答这个问题

如果面试官问你：

“Agent 的反思机制是怎么实现的？它做错了能自己改吗？”

你可以直接这么答：

反思机制本质上是一个执行后校验的闭环。 系统先让 Agent 完成任务，再通过 critic、规则校验、工具返回和状态观测判断结果是否正确；如果可修正，就触发重试、重写或重规划。

它能自己改，但只能改可检测、可逆、局部的问题。 比如格式错误、参数错误、检索错误、计划不完整，这些通常能靠反馈闭环修回来。 但如果是事实幻觉、意图理解错了、权限不足或者动作已经不可逆，那就不能指望它自己“反省一下”就修好。

说白了，Agent 的反思不是玄学，是工程控制。

它不是在思考人生。

它是在尽量别把错一路放大。