Planning、Reflection 与 Verifier:规划、自我修正与验证闭环
本文是 精英 Agent 工程师学习路线:从范式理解到生产级落地 阶段 7 的配套学习笔记。 核心结论:规划不是生成一段待办文本,反思不是让模型说“我再想想”,验证也不是让同一个模型给自己打分。生产闭环必须以结构化计划、真实 Observation、独立成功条件、可归因修复和安全重试为基础。
0. 学习目标与范围
学完本文后,你应该能够:
- 判断固定 Workflow、局部 Planner、滚动规划和开放式规划的适用边界;
- 把 Plan 建模为带依赖、前置条件、成功条件、失败路由和预算的数据;
- 在执行前做 Capability、Policy、Data Dependency 和可达性验证;
- 根据环境 Observation 更新计划,而不是让模型假装动作已成功;
- 区分 Reflection、Critic、Verifier、Reward、Retry 与 Human Review;
- 避免同源自评偏差,把确定性检查、外部环境和独立模型组合起来;
- 设计 plan repair,复用已完成工作并对外部副作用做对账;
- 对可重试错误、安全重试、补偿和人工接管建立明确矩阵;
- 分层评估计划有效性、轨迹效率、修复收益和验证器错误;
- 为
OrderFlow-Agent实现失败后可恢复的退款计划。
本文不要求所有任务都启用 Planner/Reflection。低延迟 FAQ、确定性 CRUD 和高并发简单分类通常不值得为多轮自修正付出额外成本。
1. 六个机制,六种职责
| 机制 | 输入 | 输出 | 核心问题 |
|---|---|---|---|
| Planner | goal + state + capabilities | plan/next step | 应该怎么做 |
| Executor | validated step | observation | 实际发生了什么 |
| Reflection | trace + failure/evidence | diagnosis/lessons | 为什么偏离 |
| Critic | artifact/trajectory + rubric | critique | 哪里可能不好 |
| Verifier | claim/action + evidence | pass/fail/unknown | 是否满足可判定标准 |
| Retry Policy | error + side effect + budget | retry/repair/stop | 是否安全再试 |
错误组合:
同一个模型: 生成计划 假装执行 自己评价 宣布成功正确闭环:
Goal-> Planner proposes-> Validator constrains-> Executor acts-> Environment observes-> Verifier checks-> Repair/Continue/HITL/StopReAct、Plan-and-Solve、Reflexion、Self-Refine 分别探索了行动反馈、先规划、语言式经验和迭代反馈。[P1] [P2] [P3] [P4] Harness 需要把这些思想放入统一的状态、预算与安全边界。
2. 先判断是否需要规划
2.1 任务维度
步骤数量依赖关系环境不确定性工具动态性失败成本可逆性延迟预算是否有明确验证器2.2 选择矩阵
| 场景 | 推荐控制方式 |
|---|---|
| 单次分类/抽取 | 直接模型 + Schema |
| 稳定退款流程 | 固定状态机 + 局部路由 |
| 已知步骤但输入变化 | Workflow + 条件分支 |
| 多步骤研究 | 滚动 Planner + 检索 Verifier |
| 代码修复 | Planner + Sandbox Executor + Tests |
| GUI/网页操作 | 局部规划 + 状态观察 + 强预算 |
| 高风险金融动作 | Workflow + Policy + HITL,不开放自治 |
Anthropic 的公开工程文章建议先从简单组合开始,并把 sequential workflow、routing、parallelization、orchestrator-workers、evaluator-optimizer 视作可组合模式。[S1]
2.3 自治预算
Autonomy = allowed action set + max steps/time/cost + side-effect ceiling + data access scope + human escalation rule“使用 Planner”不代表开放所有能力。
3. Plan 是可验证数据结构
3.1 Step Schema
from typing import Literalfrom pydantic import BaseModel, Field
class PlanStep(BaseModel): step_id: str objective: str capability: str dependencies: list[str] required_facts: list[str] preconditions: list[str] success_conditions: list[str] failure_routes: dict[str, str] side_effect: Literal["none", "read", "write", "external"] reversible: bool max_attempts: int = Field(ge=1, le=3) timeout_seconds: float estimated_cost: float | None
class Plan(BaseModel): plan_id: str goal: str assumptions: list[str] steps: list[PlanStep] terminal_conditions: list[str] replan_conditions: list[str] plan_version: int3.2 好计划的性质
Complete:覆盖目标必要条件Grounded:只引用可用能力和已知事实Ordered:依赖与副作用顺序正确Minimal:无无关步骤Verifiable:每步有外部成功条件Recoverable:失败有明确路由Budgeted:时间/成本/次数有限Policy-compliant:计划本身不包含越权动作3.3 不保存隐藏推理
Plan 记录可执行结构、假设和证据要求,不需要保存长篇隐藏 Chain-of-Thought。需要诊断时保存:
decision codeselected capabilityassumptionsevidence refsrejected alternatives(简短结构化)4. 规划策略
4.1 Plan-and-Execute
先生成整体计划-> 按顺序执行-> 每步更新状态-> 必要时重规划适合目标和步骤较清楚的长任务;风险是初始计划在新 Observation 后过时。
4.2 Rolling Horizon
只详细规划接下来 1-3 步远期步骤保持粗粒度新事实到达后继续展开适合动态环境,降低过早承诺。
4.3 Hierarchical Planning
Goal-> Milestones-> Subtasks-> Executable Actions上层计划稳定,下层根据工具与环境动态化。
4.4 DAG Planning
独立子任务并行:
query_order ───┐ ├-> decide_eligibilityquery_logistics┘search_policy ─┘但并行读可能观察到不同业务版本,合并前需检查版本/时间一致性。
4.5 ReWOO
ReWOO 将 reasoning/planning 与工具 observation 的逐步依赖部分解耦,先生成含变量引用的计划,再执行工具并汇总。[P5] 它可减少重复模型调用,但对动态环境和条件分支需增加修复机制。
4.6 Search-based Planning
Tree of Thoughts、LATS 等工作把多个候选状态、评价与搜索结合。[P6] [P7] 适合高价值、可验证、分支有限的任务;不适合低延迟请求或高副作用真实环境中无界探索。
5. Grounding:计划必须落在真实世界
5.1 Capability Grounding
计划引用的工具是否存在?当前主体是否可用?参数能否从已有/可获取事实得到?工具是否支持当前地域/租户?5.2 State Grounding
订单当前 version 是多少?前置步骤是否真的完成?人工确认是否仍有效?业务状态是否在等待期间变化?5.3 World Model 的边界
LLM 对工具和业务的语言理解只是近似 World Model。高风险步骤要从工具 Schema、Policy 和业务真相源验证。
LLM+P 等工作尝试把语言模型与经典规划器结合,提示我们可以让模型做语义翻译,让确定性规划/验证器处理形式约束。[P8]
5.4 Assumption Ledger
class Assumption(BaseModel): assumption_id: str statement: str source: Literal["user", "tool", "policy", "model"] evidence_refs: list[str] status: Literal["unverified", "verified", "invalidated"] invalidates_steps: list[str]新 Observation 推翻假设时,Runtime 知道哪些 Step 需要失效。
6. 执行前 Plan Validation
6.1 结构检查
step_id 唯一依赖存在DAG 无意外环至少一个终止路径所有失败码有路由6.2 能力检查
capability 在当前 Registry Snapshot输入字段有来源副作用与计划声明一致timeout/max_attempts 合法6.3 安全检查
主体/资源权限高风险动作前有确认/HITL不可逆动作在必要读取之后敏感数据不流向未授权工具6.4 可达性检查
class PlanValidation(BaseModel): valid: bool errors: list[str] warnings: list[str] unreachable_steps: list[str] missing_verifiers: list[str] policy_version: str6.5 计划不是授权
即使 Plan Validation 通过,每次执行前仍需基于最新状态授权。计划可能等待数分钟,期间权限、规则或资源状态会变。
7. Observation 驱动执行
7.1 Step Attempt
class StepAttempt(BaseModel): attempt_id: str step_id: str plan_version: int started_at: str input_fact_refs: list[str] capability_snapshot: str status: Literal[ "running", "succeeded", "failed_retryable", "failed_terminal", "outcome_unknown", "cancelled", ] observation_refs: list[str] error_code: str | None7.2 Observation 分类
Expected SuccessExpected Business RejectionTransient Technical FailurePermanent Technical FailureUnexpected StateOutcome UnknownSecurity/Policy Denial不同分类走不同修复,不交给一句通用“try again”。
7.3 Progress Metric
每步应减少未完成目标或增加必要事实:
new verified factsnew satisfied preconditionscompleted milestonereduced uncertaintyexternal state transition连续多步无进展触发 stop/repair。
7.4 Execution Ledger
{ "step_id": "query_logistics", "attempt": 2, "input_versions": {"order": 8}, "observation": "logistics://ORD-A1B2C3D4?version=3", "progress": ["fact.logistics_status"], "cost_usd": 0.002, "latency_ms": 184}8. Plan Repair:修局部,不从头开始
8.1 Replan Trigger
前置假设被推翻工具不可用/权限改变业务状态冲突新必需事实出现Verifier 拒绝结果计划超预算用户改变目标8.2 Repair Input
class PlanRepairRequest(BaseModel): goal: str current_plan: Plan completed_steps: list[str] durable_fact_refs: list[str] external_effect_refs: list[str] failed_step: str failure_code: str invalidated_assumptions: list[str] remaining_budget: dict8.3 Repair Output
KEEP 已完成且仍有效INVALIDATE 依赖错误假设REPLACE 失败步骤INSERT 新查询/确认/补偿REORDER 尚未执行步骤STOP 转人工或终止8.4 副作用保护
已经执行的退款、发信、工单不能因重规划被当作“未完成”。Repair 前先对账:
外部 operation_id幂等记录业务最终状态可补偿性8.5 Plan Version
plan v1: steps A B C Dstep A/B completestep C failureplan v2: KEEP A/B, REPLACE C with C1/C2, KEEP D dependency updatedTrace 必须关联每次 Attempt 使用的 plan version。
8.6 Goal Change 不是普通 Replan
用户从“查询能否退款”改为“不要退款,只催发货”,目标已经变化:
暂停调度旧计划新 Step-> 标记未执行步骤 cancelled_by_goal_change-> 对已执行副作用列出状态/补偿可能-> 重新确认新目标和约束-> 生成新 goal_id + plan_id-> 保留两者因果关联不能只修改 Plan 的最后一步,因为原计划可能已经创建工单、发送通知或预留额度。
class GoalRevision(BaseModel): previous_goal_id: str new_goal_id: str user_message_ref: str kept_effects: list[str] compensation_candidates: list[str] cancelled_step_ids: list[str] confirmed_at: str8.7 Plan Diff
{ "from_version": 1, "to_version": 2, "kept": ["S1"], "invalidated": ["S2"], "replaced": {"S2": ["S2a", "S2b"]}, "inserted": ["S2c"], "reason_refs": ["error://logistics_record_not_found"], "external_effects_preserved": []}Plan Diff 既用于审计,也用于评估 Repair 是否最小化修改。
9. Reflection:诊断,不直接掌权
9.1 Reflection 类型
| 类型 | 问题 | 输出 |
|---|---|---|
| Outcome | 最终为何失败 | failure hypothesis |
| Process | 哪一步偏离 | step attribution |
| Tool | 工具选择/参数/观察有何问题 | tool lesson |
| Context | 缺了/多了什么信息 | context adjustment |
| Policy | 是否违反约束 | escalation,不自改策略 |
9.2 结构化 Reflection
class ReflectionResult(BaseModel): failure_category: str failed_step_ids: list[str] evidence_refs: list[str] root_cause_hypotheses: list[str] confidence: float proposed_repairs: list[str] reusable_lesson_candidate: str | None requires_human_review: bool9.3 反思要看外部证据
输入应包含:
计划实际 Observation工具错误码Verifier 结果状态 diff预算不推荐只把最终错误答案丢给模型让它自由复盘。
9.4 反思与 Memory
Reflection 产出只是 Memory Candidate:
候选经验-> 多 Case 验证-> 人工/离线评估-> 作用域与有效期-> 才能提升为 procedural memory/skill change单次失败教训可能是偶然噪声,不能自动修改全局 Prompt 或 Skill。
9.5 成本门槛
Reflection 适合:
代码/报告等高价值产物有明确 verifier失败可修复剩余预算充足不适合:
简单 FAQ已明确权限拒绝不可逆动作之后的盲重试无新证据的重复自评10. Critic 与 Verifier:建议和判定分开
10.1 Critic
Critic 输出可能问题和改进意见,适合主观、多维质量:
报告结构代码可读性解释是否清楚遗漏风险10.2 Verifier
Verifier 对明确命题做判定:
Schema 是否合法测试是否通过数据库状态是否变为 refunded金额是否不超过上限每个 claim 是否有证据支持10.3 Verifier 层级
L0 Static / SchemaL1 Deterministic RuleL2 Environment / Tool CheckL3 Model-based JudgeL4 Human Review优先使用更低层、可重复的验证器。
10.4 Verifier Contract
class VerificationResult(BaseModel): verdict: Literal["pass", "fail", "unknown"] check_id: str verifier_version: str claim: str evidence_refs: list[str] failed_constraints: list[str] confidence: float | None repairable: bool recommended_route: str10.5 unknown 必须存在
证据不足时强迫二元 pass/fail 会制造假确定性。unknown 可以触发补充事实、另一个 Verifier 或人工。
10.6 同源自评偏差
同一个模型、同一上下文、同一 Prompt 家族可能共享错误。降低相关性:
确定性检查优先Verifier 只看必要证据,不看生成者自辩使用不同 rubric/prompt/model(按风险)对 Judge 做人工校准环境状态优先于语言评价Let’s Verify Step by Step 讨论过程监督;CriticGPT 相关工作探索模型 Critic 帮助人类发现错误。[P9] [P10] 它们不能证明 LLM Judge 在所有领域都可靠。
10.7 Verifier 校准集
每个 model-based Verifier 都需要人工 Gold:
明确 pass明确 fail证据不足 unknown表面合理但引用不支持最终答案对但轨迹越权措辞不同但语义正确对抗性自辩/奖励劫持混淆矩阵:
Gold Pass Gold Fail Gold UnknownPred PassPred FailPred Unknown高风险动作关注 False Pass / Gold Fail;内容润色可能更关注 False Fail 带来的成本。
10.8 阈值与路由
class VerifierPolicy(BaseModel): verifier_id: str version: str pass_threshold: float human_review_band: tuple[float, float] max_rechecks: int fail_open: bool = Falsefail_open=False 不能只写在配置里;超时、解析错误、模型拒绝和证据缺失都必须映射到 unknown/human,不能静默 pass。
10.9 Verifier 版本也是发布变量
Planner/Model 不变,仅升级 Verifier 也会改变成功率、重试数和人工量。因此发布时同时报告:
old/new confusion matrixverdict distribution shiftfalse-pass regressionrepair/human traffic deltacost and latency delta11. Retry Policy:重试是一项业务决策
11.1 决策输入
class RetryContext(BaseModel): error_code: str attempt: int max_attempts: int side_effect: str outcome_known: bool idempotency_supported: bool remaining_time_seconds: float remaining_cost_usd: float11.2 矩阵
| 错误 | 动作 |
|---|---|
| 模型 429/暂时 5xx | 退避后重试或路由 fallback |
| 格式错误 | 最多一次结构修复 |
| 只读工具超时 | 条件重试 |
| 写工具发送后超时 | 对账,不直接重试 |
| 权限/策略拒绝 | 停止或人工,不重试 |
| 参数业务冲突 | 刷新事实并 repair |
| Verifier fail | 修复相关 Step,不重跑全部 |
| 无进展循环 | 停止/人工 |
11.3 Backoff
delay = min(cap, base * 2^attempt) + random_jitter还需遵守总 deadline 和 Retry-After。
11.4 Compensation
对于已发生但可逆的副作用:
原动作补偿动作补偿前置条件补偿权限补偿失败路由Compensation 不是数据库 rollback;它是新的显式业务动作,也需要审计与验证。
12. HITL:把不确定性移交给合适的人
12.1 触发条件
高风险不可逆动作规则/证据冲突Verifier unknown超过自动金额阈值多次 repair 失败用户明确要求人工12.2 Review Package
{ "run_id": "run_01J...", "goal": "处理未发货退款", "plan_version": 2, "completed_steps": ["query_order", "query_logistics", "search_policy"], "verified_facts": ["order://...@v8", "logistics://...@v3"], "evidence_bundle": "evb://...", "proposed_action": "refund 12900 cents", "verifier_result": "unknown: conflicting presale metadata", "allowed_decisions": ["approve", "reject", "request_more_info"], "expires_at": "2026-07-15T11:00:00Z"}12.3 Resume 前
验证 review token检查决定未过期刷新外部业务状态重新运行必要 Policy/Verifier确认参数与批准内容一致LangGraph interrupt/durable execution、Google ADK workflow agents 等公开方案提供暂停/工作流组合能力。[S2] [S3] 业务 Review Package 和重新校验仍需应用设计。
13. OrderFlow-Agent 完整实例
13.1 初始计划
{ "goal": "判断并处理订单退款", "steps": [ {"id": "S1", "capability": "query_order", "depends_on": []}, {"id": "S2", "capability": "query_logistics", "depends_on": ["S1"]}, {"id": "S3", "capability": "search_policy", "depends_on": ["S1", "S2"]}, {"id": "S4", "capability": "verify_eligibility", "depends_on": ["S3"]}, {"id": "S5", "capability": "request_confirmation", "depends_on": ["S4"]}, {"id": "S6", "capability": "create_refund", "depends_on": ["S5"]}, {"id": "S7", "capability": "verify_final_state", "depends_on": ["S6"]} ]}13.2 失败
S2 返回:
{ "status": "failed_terminal", "code": "logistics_record_not_found", "order_version": 8}13.3 Reflection
{ "failure_category": "missing_external_record", "failed_step_ids": ["S2"], "root_cause_hypotheses": [ "订单尚未生成物流单,not-found 可能等价于 not-shipped" ], "proposed_repairs": [ "查询订单 fulfillment_type 和 promised_ship_at", "使用 no-logistics-record 规则分支" ]}13.4 Plan Repair
KEEP S1REPLACE S2 with: S2a query_fulfillment_details S2b classify_no_logistics_recordUPDATE S3 required factsKEEP S4-S7 with dependencies updated13.5 Verifier
{ "verdict": "pass", "check_id": "refund_eligibility_v4", "evidence_refs": [ "order://ORD-A1B2C3D4?version=8", "policy://refund/v18#R001" ], "failed_constraints": [], "repairable": false, "recommended_route": "request_confirmation"}13.6 写后验证
create_refund -> accepted(operation_id=OP-88)query_refund(OP-88) -> completed(refund_id=RF-77)query_order -> status=refunded, version=9只有此时才生成“退款已完成”。
14. Runtime 伪代码
async def run_planned_task(state: AgentState) -> AgentState: plan = await planner.create_or_load(state) validation = await plan_validator.validate(plan, state) if not validation.valid: return await escalate_invalid_plan(state, validation)
while not terminal(state): enforce_budget(state) step = select_ready_step(plan, state)
action = await prepare_validated_action(step, state) observation = await executor.execute(action) state = await commit_observation(state, step, observation)
verification = await verifier.verify(step, state, observation) state = await commit_verification(state, verification)
if verification.verdict == "pass": state = mark_step_complete(state, step) continue
retry = retry_policy.decide(step, observation, verification, state) if retry.action == "retry": state = schedule_retry(state, step, retry) elif retry.action == "repair": reflection = await reflector.diagnose(plan, state) plan = await repairer.repair(plan, state, reflection) plan = await persist_new_plan_version(plan) elif retry.action == "human": return await pause_for_human(state, plan, verification) else: return fail_with_evidence(state, verification)
return state15. 大厂与框架公开方案对照
| 方案 | 公开模式 | 可借鉴 | 仍需自建 |
|---|---|---|---|
| Anthropic Effective Agents | orchestrator-workers、evaluator-optimizer | 从简单模式组合 | 状态/事务/审计 |
| OpenAI Agents SDK | Runner loop、agents-as-tools、handoff、guardrail | 执行 Hook 与委派 | 领域 Plan/Verifier |
| Google ADK | sequential/parallel/loop workflow agents | 确定性流程与 Agent 组合 | 业务重试/补偿 |
| LangGraph | StateGraph、interrupt、checkpoint、time travel | durable plan/repair | 成功条件建模 |
| Microsoft AutoGen/Magentic-One | orchestrator ledger、多 Agent 协作 | ledger 与重新规划 | 高风险动作约束 |
| Temporal | workflow/activity/retry/signal | 长任务恢复与 Timer | 模型/Context/Eval |
官方资料见 [S1] 到 [S5]。公开抽象不能代替具体业务的 Plan Schema 与 Verifier。
16. 前沿论文的工程启发
| 工作 | 思想 | 工程落点 | 风险 |
|---|---|---|---|
| ReAct [P1] | reasoning/action/observation 交替 | Observation 驱动状态 | 无界循环 |
| Plan-and-Solve [P2] | 先规划再求解 | 显式 Plan | 计划未 grounding |
| Reflexion [P3] | verbal feedback + episodic memory | Reflection Candidate | 固化自我错误 |
| Self-Refine [P4] | feedback-refine 迭代 | Artifact 修订 | 同源自评偏差 |
| ReWOO [P5] | 计划与 Observation 部分解耦 | 减少模型调用 | 动态性较弱 |
| ToT [P6] | 多思路搜索与评价 | 高价值分支搜索 | 成本爆炸 |
| LATS [P7] | language agent tree search | 有 verifier 的探索 | 真实副作用不可乱试 |
| LLM+P [P8] | LLM 与经典规划结合 | 语义翻译 + 形式校验 | 世界模型转换错误 |
| Process Supervision [P9] | 对中间步骤提供监督 | Step Verifier/Eval | 领域迁移 |
| CriticGPT [P10] | 模型 Critic 辅助人类 | Review augmentation | Critic 也会漏错 |
| SWE-agent [P11] | ACI + 环境测试 | Tests 作为 Verifier | 仅适合可执行环境 |
| Magentic-One [P12] | ledger-based orchestration | progress/task ledger | 多 Agent 成本与协调 |
17. Evaluation:证明循环带来净收益
17.1 Planning
Plan ValidityCapability Grounding AccuracyDependency AccuracyRequired-step RecallUnnecessary-step RatePrecondition CoverageExpected Cost/Time Error17.2 Execution/Repair
Step Success RateProgress per StepNo-progress Loop RateRepair Success RateCompleted-work Reuse RateDuplicate Side-effect RateReplan Count per Success17.3 Reflection
Failure Attribution AccuracyUseful Repair Suggestion RateReflection-induced Regression RateCost/Latency DeltaNet Task Success Lift17.4 Verifier
Verifier Precision/RecallFalse-pass RateFalse-fail RateUnknown CalibrationEvidence CompletenessInter-rater Agreement高风险系统优先控制 False Pass。
17.5 端到端消融
A fixed workflow baselineB planner onlyC planner + repairD planner + repair + verifierE D + reflectionF E + human gate同时比较:
Verified Task SuccessUnsafe Action RateLatencyCost per Verified SuccessHuman Escalation如果 Reflection 只增加成本而不提高验证通过率,应关闭。
17.6 Trace 与可复现性
{ "run_id": "run_01J...", "goal_id": "goal_v1", "plan_versions": [1, 2], "planner": "planner@6", "capability_snapshot": "tools@42", "observations": ["obs://S1-A1", "obs://S2-A1"], "plan_diffs": ["diff://plan-1-2"], "reflections": ["reflection://R1"], "verifiers": ["refund-rule@4", "final-state@3"], "terminal_verdict": "pass", "verified_outcome_ref": "refund://RF-77"}复现不要求保存隐藏推理,但必须固定 Planner/Prompt/Model、Capability、Policy、Verifier 和外部 Observation 引用。
17.7 Repair 最小性
指标:
Kept Valid Step RatioUnnecessarily Invalidated Step RateRepeated External Call RatePlan Edit DistanceNew Failure Introduced RateRepair Success 不只看最后成功,还要看是否无必要地重做昂贵或有副作用步骤。
18. 测试与故障注入
18.1 Plan Validation
未知工具缺依赖循环依赖写操作早于确认无终止条件预算超限不可逆动作无 verifier18.2 Execution
只读工具瞬时失败写工具 outcome_unknown业务版本冲突计划中途权限撤销用户改变目标并行 Observation 版本不一致18.3 Verifier
正确结果/错误结果证据不足冲突证据对抗性自辩文本相同模型偏差Verifier 超时18.4 Recovery
Reflection 前进程死亡新 Plan 保存后旧 Worker 继续执行人工批准同时计划被修复补偿动作失败旧计划 Step 被重复投递19. Failure Taxonomy
| 编号 | 失败 | 示例 | 首要层 |
|---|---|---|---|
| P01 | Unnecessary Planning | FAQ 生成十步计划 | Router |
| P02 | Ungrounded Plan | 引用不存在工具 | Planner/Validator |
| P03 | Missing Dependency | 未查订单先退款 | Plan Validator |
| P04 | Stale Plan | 新状态到达仍按旧步骤 | Runtime |
| P05 | No Progress | 重复搜索相同内容 | Progress Detector |
| P06 | Wrong Observation | 模型编造工具成功 | Executor |
| P07 | Bad Attribution | 反思错怪检索 | Reflector |
| P08 | Over-repair | 从头重跑已完成动作 | Repairer |
| P09 | Unsafe Retry | 重复写副作用 | Retry Policy |
| P10 | False Pass | Verifier 放过错误结果 | Verifier |
| P11 | False Fail | 正确结果反复修订 | Verifier |
| P12 | Self-confirmation | 同模型重复认可自己 | Evaluation Design |
| P13 | HITL Staleness | 批准后状态已变化 | Resume Validator |
| P14 | Budget Explosion | 搜索/反思无界 | Runtime |
20. 常见反模式
20.1 计划是自然语言清单
没有依赖、成功条件、失败路由,无法自动验证与修复。
20.2 Planner 控制高风险动作
Planner 只能提出,Policy/Workflow/HITL 决定是否可执行。
20.3 工具失败就重做整个任务
浪费已完成读取,并可能重复副作用。
20.4 Reflection 自动写长期记忆
一次错误归因会污染未来所有任务。
20.5 Verifier 只读最终答案
看不到错误工具、越权数据、状态和引用。
20.6 只有 pass/fail
证据不足被迫变成错误确定性。
20.7 更多循环就是更聪明
没有新证据和独立验证时,只是重复采样。
20.8 人工批准永久有效
确认必须绑定参数、资源版本和有效期。
21. 项目目录与实践任务
app/ planning/ schema.py planner.py validator.py grounding.py progress.py repair.py reflection/ schema.py reflector.py lessons.py verification/ protocol.py schema_verifier.py rule_verifier.py environment_verifier.py model_judge.py runtime/ executor.py retry_policy.py compensation.py budgets.py hitl/ review_package.py resume_validator.pytests/ planning/ repair/ verification/ retry/ recovery/ scenarios/data/ planning_eval.jsonldocs/ planning_strategy.md verifier_rubrics.md retry_matrix.md实践顺序:
1. 先做固定 Workflow baseline2. 定义 Plan/Step/Assumption Schema3. 加确定性 Plan Validator4. 只在一个复杂分支启用 Planner5. 用真实 Observation 驱动 Step 完成6. 加 Progress/Stop/Budget7. 加局部 Plan Repair8. 先建 deterministic/environment Verifier9. 再试 Reflection 与 model-based Critic10. 做消融,证明净收益后上线22. 达标检查清单
Planning
- 能说明为何当前任务需要/不需要 Planner;
- Plan 有依赖、前置、成功、失败、预算和副作用;
- 计划在执行前做结构/能力/Policy 验证;
- 假设有来源和失效传播;
- 每次 Attempt 固定 plan version。
Execution/Repair
- Step 完成由真实 Observation 判定;
- 有 no-progress detector;
- Repair 保留已完成且有效工作;
- 外部副作用先对账再修复;
- Retry 按错误与副作用语义决策。
Reflection/Verifier/HITL
- Reflection 输出结构化归因与证据;
- 单次 Reflection 不自动写长期记忆;
- 优先使用 deterministic/environment Verifier;
- Verifier 支持 pass/fail/unknown;
- 人工确认绑定资源、参数、版本与有效期;
- Resume 前重新验证业务状态。
Evaluation
- 有 fixed workflow baseline;
- 分别测 plan、repair、reflection、verifier;
- 统计 false pass 与 unsafe retry;
- 比较 cost per verified success;
- 无净收益时能关闭复杂循环。
23. 面试与架构评审问题
- Workflow 与 Planner 的边界是什么?
- 为什么 Plan 必须有成功条件和失败路由?
- Rolling Horizon 相比一次性长计划有什么优势?
- 计划通过验证为什么执行时还要再次授权?
- Plan Repair 如何避免重复副作用?
- Reflection 与 Verifier 有何区别?
- 为什么同模型自评容易产生相关错误?
- Verifier 为什么需要
unknown? - 哪些错误可以 Retry,哪些必须 Reconcile?
- 如何证明 Reflection 带来净收益?
- 人工批准后为什么要刷新状态?
- 什么时候应该回退为固定 Workflow?
24. 参考资料与延伸阅读
以下资料用于核对公开模式与论文原始思想。论文在特定任务上的改进不能直接外推到高风险业务;真实系统必须以环境结果、成本和安全指标复验。
官方与工程方案
[S1] Anthropic Effective Agents
[S2] LangGraph
[S3] Google ADK
[S4] OpenAI Agents SDK
[S5] Microsoft 与 Temporal
- Microsoft AutoGen Magentic-One;
- Temporal Workflow Execution。
论文与研究
[P1] ReAct
- Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023。
[P2] Plan-and-Solve
- Wang et al., Plan-and-Solve Prompting, ACL 2023。
[P3] Reflexion
- Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS 2023。
[P4] Self-Refine
- Madaan et al., Self-Refine: Iterative Refinement with Self-Feedback, NeurIPS 2023。
[P5] ReWOO
[P6] Tree of Thoughts
- Yao et al., Tree of Thoughts: Deliberate Problem Solving with Large Language Models, NeurIPS 2023。
[P7] LATS
- Zhou et al., Language Agent Tree Search Unifies Reasoning, Acting, and Planning in Language Models, ICML 2024。
[P8] LLM+P
- Liu et al., LLM+P: Empowering Large Language Models with Optimal Planning Proficiency, 2023。
[P9] Process Supervision
- Lightman et al., Let’s Verify Step by Step, ICLR 2024。
[P10] CriticGPT
- McAleese et al., LLM Critics Help Catch LLM Bugs, 2024。
[P11] SWE-agent
- Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, NeurIPS 2024。
[P12] Magentic-One
- Fourney et al., Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks, 2024。
25. 阶段总结
一个可靠的自我修正闭环不是“多问模型几次”,而是:
计划是带约束的数据;动作由受控 Executor 执行;环境 Observation 更新真实状态;Verifier 用独立证据判定;Reflection 只诊断和提出候选修复;Repair 保留有效工作并处理副作用;Retry 受错误语义、幂等和预算控制;高风险与不确定性进入 HITL。成熟工程判断不是“是否能加入 Reflection”,而是:
这个任务是否值得规划?失败是否可修复?是否存在可靠 Verifier?新一轮能否获得新证据?成本和延迟是否可接受?副作用是否能安全处理?只有答案同时成立,Planning/Reflection 才是可靠性机制;否则它只是更昂贵、更难调试的生成循环。