让模型在运行中进化：从基础反思到基于 MCTS 的 Test-Time Compute 搜索

引子：为什么模型需要“想一想再回答”？

当你问一个人“234 乘以 456 等于多少”时，如果他脱口而出，大概率是错的。但他如果拿出一张草稿纸进行演算，给出正确答案的概率就会极大幅度提升。

对于早期的 LLM 而言，所有的推断都被压缩在下一个 Token 的生成概率中（One-pass generation）。无论问题多么复杂，它都倾向于“脱口而出”。 自我反思（Reflection）与自我纠错（Self-Correction）机制的出现，本质上就是给模型发了一张“计算草稿纸”，通过增加推理期的计算消耗（Test-Time Compute），换取任务胜率的非线性提升。

进阶一：解耦与监督，Actor-Critic 架构设计

最基础的让模型输出 Let's think step by step 只是浅层的 Prompt 引导。真正的自我纠错系统需要对职能进行严格的解耦：隔离生成（Actor）与批评（Critic）。

为什么不能让同一个模型实例“自产自销”？

如果让 Actor 直接反思自己的错误，很容易陷入“确认偏误”（Confirmation Bias）或者极端的“阿谀奉承”（顺着哪怕是错误的逻辑往下编）。

硬核 Critic 设计要点：

1. 独立上下文：Critic 的 Prompt 必须与 Actor 隔离，不继承 Actor 犹豫不决的中间推理步骤，而是直接对比“Actor 最终输出”与“Ground Truth 约束”。
2. 外部环境锚点 (Environment Grounding)：高阶的 Critic 决不能做纯文字的哲学反思。对于代码 Agent，Critic 的输入必须包含：沙盒执行报错栈 (Traceback) + AST 静态扫描警告。对于检索 Agent，输入必须包含 文档重排 (Rerank) 得分。关于安全沙箱与工具返回状态的规范捕获，可参考 做 AI Agent 的 7 条运行时实践。
3. 结构化惩罚 (Structured Critique)：要求 Critic 输出 JSON 格式的具体修改指令（如："bug_location": "line 42", "fix_action": "replace append with extend"），而不是模糊的“好像不对”。

深度突围二：将反思升级为搜索算法 (MCTS 落地)

当你把 Actor-Critic 循环执行了 3 次，你发现模型在两种错误的代码写法之间反复横跳——这就是常规状态机反思的死胡同。关于如何摆脱简单 ReAct 模式的震荡与死循环，可参阅 从 Prompt 到 Loop 工程架构演进。

在 2026 年的前沿研究中，我们将 Agent 的生成过程映射为一个状态空间搜索问题。 既然模型无法一次走通，我们就引入蒙特卡洛树搜索（MCTS, Monte Carlo Tree Search），让模型在推理期“预演”多条时间线。

1. 状态树与动作价值 (State Valuation)

在执行复杂编程任务时，我们将代码的每一个增量函数视为树上的一个节点：

• 选择 (Selection) 与扩展 (Expansion)：Actor 在当前节点同时生成 3 种不同的实现方案作为子节点。
• 模拟 (Simulation) 与验证：对每一个子节点，在独立的沙盒中运行单元测试，或者由 Critic 给出基于启发式规则的奖励分数（Reward Modeling）。

2. 置信区间上界算法 (UCB) 驱动节点选择

在多次反思循环中，系统如何决定是“继续深挖当前可能有错的代码”，还是“退回上一步尝试另一条路”？这正是 UCB（Upper Confidence Bound）算法要解决的探索与利用（Exploration vs. Exploitation）困境。

• $Q(v_i)$ 是 Critic 对节点累计给出的奖励值。
• $N(v_i)$ 是该分支被探索的次数。
• $c$ 是探索常数。

通过计算 UCB，编排系统能够智能地在代码的局部报错堆栈中“修修补补”，一旦发现某条路径的修补成功率暴跌，系统会自动回溯（Backtrack）到树的较浅层，尝试使用截然不同的算法思路重新生成。

结语：从 System 1 到 System 2

基于 Actor-Critic 的基础反思，赋予了模型发现局部错漏的眼睛；而基于 MCTS 的 Test-Time 搜索，则赋予了模型规划全局最优解的大脑。

这一切都标志着 AI 正在从依赖直觉的快思考（System 1），真正跨入需要算力深思熟虑的慢思考（System 2）时代。不要再盲目抱怨你的模型不够聪明，先问问你的系统设计是否给了它足够的“思考时间”与正确的“搜索方向”。

常见问题 (FAQ)

Q1: 为什么简单的“请检查上述回答并指出错误”往往会导致模型盲目反思甚至把对的改错？

缺乏外部物理真值（Grounded Truth）时，强行要求单一模型自省容易诱发谄媚效应（Sycophancy）与假阳性幻觉。反思必须建立在确定性的外部反馈之上（如编译器 Exit Code、单元测试通过率、Schema 校验器），并采用独立的 Critic 角色进行上下文物理隔离。更多控制回路与防震荡设计可参考 从 Prompt 到 Loop 工程架构演进。

Q2: 在生产系统引入 MCTS 搜索算法会带来巨大的推理延迟和 Token 消耗，如何做工程裁剪？

工业界通常采用“剪枝型 MCTS”：设定严苛的最大搜索深度与分支数（如单节点仅扩展 2~3 个候选），并在首轮单元测试未通过时立即剪除劣质分支。此外，结合 做 AI Agent 的 7 条运行时实践 中的 Guardrails 机制，当单次任务消耗的 Token 数量或时间触碰阈值时，自动触发早停熔断并回退至已知最优局部解。

Q3: Actor 与 Critic 模型在工程落地时如何选型最具性价比？

业界成熟方案通常采用“小模型生成 (Actor) + 大模型裁决 (Critic)”的非对称组合：使用吞吐高、成本低的轻量模型负责代码初稿生成与局部修补，仅在节点终验和关键分支评估时唤醒大参数模型担任 Critic；或者在离线阶段用大模型蒸馏出专用的轻量级验证器，兼顾搜索广度与计算成本。