06 · 规划与反思

🎯 难度：中级⏱ 预计：45 分钟# 规划# 验证# 终止

简单任务使用工具循环就够了。复杂任务需要明确目标、拆解步骤、检查产物，避免「一直忙，但没有完成」。

三种常见模式

ReAct：边做边决定

适合路径不确定、需要根据工具返回调整方向的任务。缺点是可能绕路，所以需要预算和进度检查。

Plan-and-Execute：先计划再执行

先生成有限步骤，再逐步执行，最后汇总。计划是可修订的数据，不是必须盲目遵循的真理。

from typing import Literal
from pydantic import BaseModel, Field

class Step(BaseModel):
    id: int
    action: str = Field(min_length=1)
    status: Literal["pending", "done", "blocked"] = "pending"

class Plan(BaseModel):
    goal: str
    steps: list[Step] = Field(min_length=1, max_length=5)

这只是数据结构。想让它可执行，还要在程序中规定工具范围、前置条件、成功判断、修改计划的规则。

固定 Workflow + 局部 Agent

例如研究报告：程序规定「最多搜索 3 次 → 汇总引用 → 写报告」；搜索词由模型决定。确定性框架里加入局部灵活性，通常比无限自主循环更容易稳定。

反思要基于证据

「再认真检查一遍」有时有效，但同一个模型可能重复相同错误。更可靠的反思来源：

• 代码任务：单元测试、编译错误、实际 diff。
• 计算任务：确定性计算工具。
• 研究任务：打开来源、核对事实和日期。
• RAG：检查引用是否来自真实命中块。

反思并不要求输出隐藏思维链。我们需要的是检查结论、依据和可执行修正。

防止无限修复

最多 2 次修正
每次修正后运行同一个验收器
通过 → 返回结果
未通过 → 明确失败原因和下一步，不声称完成

还要检测连续重复调用、重复计划、工具失败没有改变参数等无进展信号。更多 Token 不一定解决缺少权限或缺少数据的问题。

人在回路（Human-in-the-loop）

让模型生成邮件草稿，与允许它发送邮件是两个权限等级。确认界面应展示具体收件人、内容、金额等动作细节，确认不能跨任务无限复用。真正执行前由程序验证批准状态。

练习

设计「修复一个前端 bug」的流程：哪些节点让模型自由决定，哪些必须程序确定执行，哪些要用户确认？

参考：读取限定项目 → 建议修复 → 用户确认修改 → 应用补丁 → 固定测试 → 最多两次修正。不能因为测试失败就允许模型随意修改测试以宣称成功。