5865 字
29 分钟

Planning、Reflection 与 Verifier:规划、自我修正与验证闭环

本文是 精英 Agent 工程师学习路线:从范式理解到生产级落地 阶段 7 的配套学习笔记。 核心结论:规划不是生成一段待办文本,反思不是让模型说“我再想想”,验证也不是让同一个模型给自己打分。生产闭环必须以结构化计划、真实 Observation、独立成功条件、可归因修复和安全重试为基础。


0. 学习目标与范围#

学完本文后,你应该能够:

  1. 判断固定 Workflow、局部 Planner、滚动规划和开放式规划的适用边界;
  2. 把 Plan 建模为带依赖、前置条件、成功条件、失败路由和预算的数据;
  3. 在执行前做 Capability、Policy、Data Dependency 和可达性验证;
  4. 根据环境 Observation 更新计划,而不是让模型假装动作已成功;
  5. 区分 Reflection、Critic、Verifier、Reward、Retry 与 Human Review;
  6. 避免同源自评偏差,把确定性检查、外部环境和独立模型组合起来;
  7. 设计 plan repair,复用已完成工作并对外部副作用做对账;
  8. 对可重试错误、安全重试、补偿和人工接管建立明确矩阵;
  9. 分层评估计划有效性、轨迹效率、修复收益和验证器错误;
  10. OrderFlow-Agent 实现失败后可恢复的退款计划。

本文不要求所有任务都启用 Planner/Reflection。低延迟 FAQ、确定性 CRUD 和高并发简单分类通常不值得为多轮自修正付出额外成本。


1. 六个机制,六种职责#

机制输入输出核心问题
Plannergoal + state + capabilitiesplan/next step应该怎么做
Executorvalidated stepobservation实际发生了什么
Reflectiontrace + failure/evidencediagnosis/lessons为什么偏离
Criticartifact/trajectory + rubriccritique哪里可能不好
Verifierclaim/action + evidencepass/fail/unknown是否满足可判定标准
Retry Policyerror + side effect + budgetretry/repair/stop是否安全再试

错误组合:

同一个模型:
生成计划
假装执行
自己评价
宣布成功

正确闭环:

Goal
-> Planner proposes
-> Validator constrains
-> Executor acts
-> Environment observes
-> Verifier checks
-> Repair/Continue/HITL/Stop

ReAct、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 Literal
from 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: int

3.2 好计划的性质#

Complete:覆盖目标必要条件
Grounded:只引用可用能力和已知事实
Ordered:依赖与副作用顺序正确
Minimal:无无关步骤
Verifiable:每步有外部成功条件
Recoverable:失败有明确路由
Budgeted:时间/成本/次数有限
Policy-compliant:计划本身不包含越权动作

3.3 不保存隐藏推理#

Plan 记录可执行结构、假设和证据要求,不需要保存长篇隐藏 Chain-of-Thought。需要诊断时保存:

decision code
selected capability
assumptions
evidence refs
rejected 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_eligibility
query_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: str

6.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 | None

7.2 Observation 分类#

Expected Success
Expected Business Rejection
Transient Technical Failure
Permanent Technical Failure
Unexpected State
Outcome Unknown
Security/Policy Denial

不同分类走不同修复,不交给一句通用“try again”。

7.3 Progress Metric#

每步应减少未完成目标或增加必要事实:

new verified facts
new satisfied preconditions
completed milestone
reduced uncertainty
external 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: dict

8.3 Repair Output#

KEEP 已完成且仍有效
INVALIDATE 依赖错误假设
REPLACE 失败步骤
INSERT 新查询/确认/补偿
REORDER 尚未执行步骤
STOP 转人工或终止

8.4 副作用保护#

已经执行的退款、发信、工单不能因重规划被当作“未完成”。Repair 前先对账:

外部 operation_id
幂等记录
业务最终状态
可补偿性

8.5 Plan Version#

plan v1: steps A B C D
step A/B complete
step C failure
plan v2: KEEP A/B, REPLACE C with C1/C2, KEEP D dependency updated

Trace 必须关联每次 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: str

8.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: bool

9.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 / Schema
L1 Deterministic Rule
L2 Environment / Tool Check
L3 Model-based Judge
L4 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: str

10.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 Unknown
Pred Pass
Pred Fail
Pred 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 = False

fail_open=False 不能只写在配置里;超时、解析错误、模型拒绝和证据缺失都必须映射到 unknown/human,不能静默 pass。

10.9 Verifier 版本也是发布变量#

Planner/Model 不变,仅升级 Verifier 也会改变成功率、重试数和人工量。因此发布时同时报告:

old/new confusion matrix
verdict distribution shift
false-pass regression
repair/human traffic delta
cost and latency delta

11. 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: float

11.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 S1
REPLACE S2 with:
S2a query_fulfillment_details
S2b classify_no_logistics_record
UPDATE S3 required facts
KEEP S4-S7 with dependencies updated

13.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 state

15. 大厂与框架公开方案对照#

方案公开模式可借鉴仍需自建
Anthropic Effective Agentsorchestrator-workers、evaluator-optimizer从简单模式组合状态/事务/审计
OpenAI Agents SDKRunner loop、agents-as-tools、handoff、guardrail执行 Hook 与委派领域 Plan/Verifier
Google ADKsequential/parallel/loop workflow agents确定性流程与 Agent 组合业务重试/补偿
LangGraphStateGraph、interrupt、checkpoint、time traveldurable plan/repair成功条件建模
Microsoft AutoGen/Magentic-Oneorchestrator ledger、多 Agent 协作ledger 与重新规划高风险动作约束
Temporalworkflow/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 memoryReflection 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 augmentationCritic 也会漏错
SWE-agent [P11]ACI + 环境测试Tests 作为 Verifier仅适合可执行环境
Magentic-One [P12]ledger-based orchestrationprogress/task ledger多 Agent 成本与协调

17. Evaluation:证明循环带来净收益#

17.1 Planning#

Plan Validity
Capability Grounding Accuracy
Dependency Accuracy
Required-step Recall
Unnecessary-step Rate
Precondition Coverage
Expected Cost/Time Error

17.2 Execution/Repair#

Step Success Rate
Progress per Step
No-progress Loop Rate
Repair Success Rate
Completed-work Reuse Rate
Duplicate Side-effect Rate
Replan Count per Success

17.3 Reflection#

Failure Attribution Accuracy
Useful Repair Suggestion Rate
Reflection-induced Regression Rate
Cost/Latency Delta
Net Task Success Lift

17.4 Verifier#

Verifier Precision/Recall
False-pass Rate
False-fail Rate
Unknown Calibration
Evidence Completeness
Inter-rater Agreement

高风险系统优先控制 False Pass。

17.5 端到端消融#

A fixed workflow baseline
B planner only
C planner + repair
D planner + repair + verifier
E D + reflection
F E + human gate

同时比较:

Verified Task Success
Unsafe Action Rate
Latency
Cost per Verified Success
Human 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 Ratio
Unnecessarily Invalidated Step Rate
Repeated External Call Rate
Plan Edit Distance
New Failure Introduced Rate

Repair Success 不只看最后成功,还要看是否无必要地重做昂贵或有副作用步骤。


18. 测试与故障注入#

18.1 Plan Validation#

未知工具
缺依赖
循环依赖
写操作早于确认
无终止条件
预算超限
不可逆动作无 verifier

18.2 Execution#

只读工具瞬时失败
写工具 outcome_unknown
业务版本冲突
计划中途权限撤销
用户改变目标
并行 Observation 版本不一致

18.3 Verifier#

正确结果/错误结果
证据不足
冲突证据
对抗性自辩文本
相同模型偏差
Verifier 超时

18.4 Recovery#

Reflection 前进程死亡
新 Plan 保存后旧 Worker 继续执行
人工批准同时计划被修复
补偿动作失败
旧计划 Step 被重复投递

19. Failure Taxonomy#

编号失败示例首要层
P01Unnecessary PlanningFAQ 生成十步计划Router
P02Ungrounded Plan引用不存在工具Planner/Validator
P03Missing Dependency未查订单先退款Plan Validator
P04Stale Plan新状态到达仍按旧步骤Runtime
P05No Progress重复搜索相同内容Progress Detector
P06Wrong Observation模型编造工具成功Executor
P07Bad Attribution反思错怪检索Reflector
P08Over-repair从头重跑已完成动作Repairer
P09Unsafe Retry重复写副作用Retry Policy
P10False PassVerifier 放过错误结果Verifier
P11False Fail正确结果反复修订Verifier
P12Self-confirmation同模型重复认可自己Evaluation Design
P13HITL Staleness批准后状态已变化Resume Validator
P14Budget 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.py
tests/
planning/
repair/
verification/
retry/
recovery/
scenarios/
data/
planning_eval.jsonl
docs/
planning_strategy.md
verifier_rubrics.md
retry_matrix.md

实践顺序:

1. 先做固定 Workflow baseline
2. 定义 Plan/Step/Assumption Schema
3. 加确定性 Plan Validator
4. 只在一个复杂分支启用 Planner
5. 用真实 Observation 驱动 Step 完成
6. 加 Progress/Stop/Budget
7. 加局部 Plan Repair
8. 先建 deterministic/environment Verifier
9. 再试 Reflection 与 model-based Critic
10. 做消融,证明净收益后上线

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. 面试与架构评审问题#

  1. Workflow 与 Planner 的边界是什么?
  2. 为什么 Plan 必须有成功条件和失败路由?
  3. Rolling Horizon 相比一次性长计划有什么优势?
  4. 计划通过验证为什么执行时还要再次授权?
  5. Plan Repair 如何避免重复副作用?
  6. Reflection 与 Verifier 有何区别?
  7. 为什么同模型自评容易产生相关错误?
  8. Verifier 为什么需要 unknown
  9. 哪些错误可以 Retry,哪些必须 Reconcile?
  10. 如何证明 Reflection 带来净收益?
  11. 人工批准后为什么要刷新状态?
  12. 什么时候应该回退为固定 Workflow?

24. 参考资料与延伸阅读#

以下资料用于核对公开模式与论文原始思想。论文在特定任务上的改进不能直接外推到高风险业务;真实系统必须以环境结果、成本和安全指标复验。

官方与工程方案#

[S1] Anthropic Effective Agents#

[S2] LangGraph#

[S3] Google ADK#

[S4] OpenAI Agents SDK#

[S5] Microsoft 与 Temporal#

论文与研究#

[P1] ReAct#

[P2] Plan-and-Solve#

[P3] Reflexion#

[P4] Self-Refine#

[P5] ReWOO#

[P6] Tree of Thoughts#

[P7] LATS#

[P8] LLM+P#

[P9] Process Supervision#

[P10] CriticGPT#

[P11] SWE-agent#

[P12] Magentic-One#


25. 阶段总结#

一个可靠的自我修正闭环不是“多问模型几次”,而是:

计划是带约束的数据;
动作由受控 Executor 执行;
环境 Observation 更新真实状态;
Verifier 用独立证据判定;
Reflection 只诊断和提出候选修复;
Repair 保留有效工作并处理副作用;
Retry 受错误语义、幂等和预算控制;
高风险与不确定性进入 HITL。

成熟工程判断不是“是否能加入 Reflection”,而是:

这个任务是否值得规划?
失败是否可修复?
是否存在可靠 Verifier?
新一轮能否获得新证据?
成本和延迟是否可接受?
副作用是否能安全处理?

只有答案同时成立,Planning/Reflection 才是可靠性机制;否则它只是更昂贵、更难调试的生成循环。

Planning、Reflection 与 Verifier:规划、自我修正与验证闭环
https://jupiter-ws.cn/posts/agent/agent-planning-reflection-verifier/
作者
Jupiter
发布于
2026-04-15
许可协议
CC BY-NC-SA 4.0