上一章讲并行化，解决的是“同时干多件事”。这一章讲反思，解决的是“干完以后怎么知道对不对”。

反思不是玄学。它就是给 Agent 加一套质量闭环：先生成，再评审，再修正，最后达标交付。

1. 反思到底是什么？

一句话：Agent 先给出结果，再按标准检查结果，然后根据反馈修正结果。

普通链路只有“生成”。反思链路多了“评审”和“修正”。这一步很关键。因为大模型第一次输出经常看起来顺，其实细节不稳。

它可能漏掉约束，可能没看全工具结果，可能格式不符合要求，也可能把不确定的内容说得很肯定。

2. 为什么需要反思？

因为 Agent 不是只会聊天。它会查数据、调工具、写代码、做决策。能力越强，错误成本越高。

没有反思，系统会把第一版结果直接交付。出了错，用户看到的是最终错误。

有了反思，系统会先做一次内部质检。能在交付前发现问题，就不要把问题丢给用户发现。

3. 反思的标准闭环

反思模式通常分四步。

第一步，Worker Agent 生成初版结果。

第二步，Critic、规则引擎或测试工具进行评审。

第三步，把评审意见变成明确的修改项。

第四步，判断是否达标。达标就停止，不达标就进入下一轮。

重点不是循环次数越多越好。重点是每一轮都要有明确反馈。没有反馈的循环，只是在重复消耗模型调用。

4. 三种落地方式

反思可以轻，也可以重。不要一上来就做复杂多智能体。

轻量场景，可以让同一个模型自查。

质量要求高，可以拆成 Worker 和 Critic。Worker 负责做事，Critic 负责挑错。

工程可靠性要求高，最好引入外部验证。代码用单元测试，SQL 用 EXPLAIN，业务动作用规则和权限校验。

5. 一个案例：代码修复 Agent

用户说：登录接口偶发空指针，帮我修一下。

如果没有反思，Agent 可能直接改一段代码，然后交付。问题是：它可能没覆盖边界场景，也可能影响正常登录链路。

更稳的做法是：Agent 修改代码后，先跑单元测试。测试失败，就把失败日志交给 Critic。Critic 不凭感觉评价，而是结合 diff、测试日志、边界条件给出修改建议。Worker 再按建议修正。直到测试通过，才交付最终结果。

6. 源码级逻辑怎么理解？

不要先看框架。先看运行时状态。

一个反思循环至少要维护 5 类状态：task、draft、feedback、score、iteration。

task 是原始任务。draft 是当前结果。feedback 是上一轮评审意见。score 是质量分。iteration 是当前第几轮。

框架只是帮你编排这些状态。真正的核心，是每一轮都能读取上一轮反馈，并判断是否应该继续。

7. 什么时候该用？什么时候别用？

适合用反思的场景：质量比速度更重要；错误成本高；有明确验收标准；能引入工具或规则验证。

不适合用反思的场景：闲聊、低价值问答、极低延迟场景、没有评估标准的主观任务。

反思会增加模型调用次数，也会增加延迟。它不是默认开启的万能开关，而是给关键链路加的质量保险。

8. 工程落地清单

上线前，先检查这几个点。

9. 总结

反思模式解决的不是“能不能生成”，而是“生成后能不能自我纠错”。

它的本质是质量闭环。

Worker 负责完成任务。Critic 负责发现问题。工具和规则负责提供外部证据。终止条件负责控制成本。

真正工程化的反思，不是让模型说一句“我再想想”，而是把每一轮生成、评审、修正和停止都做成可追踪、可验证、可控制的系统流程。