第 3 章规划、反思与搜索

3.1 用依赖关系把愿望变成计划

本章目标：能写有输入、产物和验收的计划；能根据失败修改计划，并分清重试、反思与候选搜索。

“先分析，再修复，最后测试”只是流程标签。运费任务的有效计划应包含：读取需求得到条件表；运行初始测试得到失败集合；读取实现形成缺陷假设；修改代码得到补丁；重新测试取得当前版本证据。每个步骤都应产生下一步可以使用的东西。

Plan-and-Solve [导读] 研究先分解再求解如何减少遗漏步骤。落到 Agent 工程中，还要添加执行状态与依赖。比如“验证修改”必须依赖补丁已应用，“最终报告”必须依赖验证完成，不能因为报告节点先生成了文字就视为任务结束。

从需求到候选、验证与计划修订

状态不能只用一个布尔量。pending 表示尚未开始，running 表示执行中，blocked 表示等待必要条件，done 表示达到该节点验收。全局任务和子任务也可能不同：代码写入节点 done，但全局仍在等待测试。

如果测试暴露新的调用者约束，例如现有接口必须返回整数，计划应增加“检查返回类型”节点。更新计划时保留已验证事实，并使受到新修改影响的旧验收失效。每轮完全重写计划会浪费上下文，也容易遗忘先前限制。

Reflexion [导读] 将任务反馈写成文字经验，在后续尝试中使用。有效反思不是“我应该更仔细”，而是指出原假设、反例、原因和下一轮变化。

原假设：只把 > 改为 >= 就解决全部需求。
反例：member=True、total=20 仍返回 10。
原因：只定位了边界缺陷，遗漏会员规则。
下一步：增加会员条件，并检查它与负数拒绝的先后顺序。
验收：普通、边界、会员、负数四类需求均有独立检查。

反思仍可能错误。例如“负数用 abs 转成正数”看似让代码不报错，却违反用户明确的拒绝要求。应该把反思内容作为待验证假设，直到新试验通过相关检查；未经验证的泛化经验不宜直接存成长期技能。

注意 Reflexion 主要改变下一轮上下文和记忆，不更新模型权重；第 11 章的 Agentic RL 涉及训练参数，是另一种改进路径。

运费修复可以形成三个候选：A 只改 >=；B 增加会员条件但先判断免运费；C 先拒绝负数，再判断会员或阈值。若评价器只检查金额 100，三个候选都可能通过；若加上负数会员输入，B 会暴露错误。

Tree of Thoughts [导读] 将中间思路组织成可评估、扩展和回溯的搜索节点。工程里的候选补丁搜索借鉴这一思路，但不意味着完整复现原论文方法。候选要在相同初态或独立工作区评估，避免前一个补丁污染后一个候选。

生成 A/B/C → 逐个应用到同一初始快照的副本
          → 运行相同验收 → 记录通过规则与改动范围
          → 选择合格且改动合理的候选 → 最终独立检查

多候选增加的是探索机会，不是正确性保证。验收器漏掉的需求可能被所有候选一起漏掉；多次尝试还会增加时间、token 和工具成本。先完善反馈，再决定是否扩展搜索。

连续两次 run_tests 不一定空转：第一次超时，第二次取得结果，是合理重试；写补丁后再次测试，是必要验证。真正可疑的是环境、参数、观察和假设都没有变化，却重复同一动作并期待不同结果。

可记录动作签名、源码版本、结果摘要和进展标记。触发重复检测后，要求改变证据来源、修订假设或停止，而不是只把“别循环”加入提示。检测也应允许幂等查询和有限重试，避免阻止合法恢复。

对一次失败先判断：是执行未取得结果，还是取得结果但验证不合格？前者可能重试，后者需要新假设。把两者混淆，是 Agent 空转的常见来源。

手写 A/B/C 三个候选，分别检查 20/False、100/False、20/True、-1/False、-1/True，填写“预期值、实际值、是否通过”。最后一项比实验基础五项多一个交互条件，检验你是否真正理解规则优先级。

参考结论：A 缺会员与负数校验；B 若先判断 member or total >= 100，会接受负数会员；C 符合以上全部规则。再讨论：如果需求改成“负数会员也免运费”，哪个检查要调整？答案应依据新需求，而不是固守原补丁。

本章交付物：有依赖和验收的计划、一份具体失败反思、一张候选对照表。测量真实模型时再记录成功率与调用费用；这里的手工候选不能当成模型实验成绩。