从 Plan 到可执行 Graph

1. 为什么这组知识要一起学

理解任务如何从自然语言目标变成结构化 Plan、Graph 和可执行调度，同时控制 Replanning 与 Multi-Agent 复杂度。

这几个知识点处在同一条工程链上。如果只记单个名词，很容易在真实系统里把责任放错层：例如让模型管理程序事实、让数据库 transaction 承担外部 API 原子性，或把一个 provider SDK 的行为误认为 Agent 的通用规律。

2. Mental Model

Planning 的价值是把开放任务转成可检查的结构；Orchestration 决定这个结构由代码还是模型控制。

Task → Decompose/Route → Structured Plan → Validate → Execute → Observe → Evaluate → Continue/Replan

3. 核心机制

Planner → Graph Compilation

Graph Compiler 是 deterministic translation/validation 层，隔离 Planner 的非确定性输出与 Scheduler 的执行数据结构。

Code Orchestration vs LLM Orchestration

代码编排适合确定依赖与事务；LLM 编排适合语义路由与开放探索。Hybrid 把结构约束留给代码，模型决定局部路径。

Evaluator / Optimizer

Evaluator 给出结构化 rubric/verdict，Optimizer 根据反馈改进；必须有 max iterations 和“何时足够好”标准，否则形成无界循环。

4. 最小实现 / 伪代码

下面代码只表达边界和生命周期，不要求照抄到项目中：

@dataclass
class PlanNode:
    id: str
    objective: str
    dependencies: tuple[str, ...]
    completion_criteria: str

plan = validator.validate(await planner.plan(task))

真正实现时应把 I/O、状态持久化、错误翻译和策略注入拆成可测试组件，而不是把示例扩成一个巨型函数。

5. 在 Shadow Harness 中怎么落地

Planner 只输出声明式 StructuredPlan；PlanValidator 与 GraphCompiler 把它变成可执行结构，Scheduler 仍保持确定性。

建议为本章涉及的行为留下明确的 domain object、interface 和 trace event；只要一个关键行为只能通过读日志猜测，就说明 Runtime contract 仍不够清晰。

6. Production Engineering 检查项

• 只有需要探索时才增加 agentic planning
• plan 必须带 completion criteria
• 失败只重规划剩余部分
• multi-agent 要计算上下文与协调成本

7. Failure Modes

7.1 一次计划永远不更新

当出现「一次计划永远不更新」时，比较 plan 与真实环境状态，检查 completion criteria、依赖和 replanning trigger 是否明确。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

7.2 Planner 输出直接执行

当出现「Planner 输出直接执行」时，比较 plan 与真实环境状态，检查 completion criteria、依赖和 replanning trigger 是否明确。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

7.3 critic/evaluator 无限循环

当出现「critic/evaluator 无限循环」时，比较 plan 与真实环境状态，检查 completion criteria、依赖和 replanning trigger 是否明确。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

7.4 多 Agent 共享全部 context 导致污染

当出现「多 Agent 共享全部 context 导致污染」时，比较 plan 与真实环境状态，检查 completion criteria、依赖和 replanning trigger 是否明确。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

8. Trade-offs

ReAct 自适应但轮次多；Plan-and-Execute 易并行但会 stale；Replanning 折中但实现更复杂。

设计记录最好明确：当前约束是什么、备选方案有哪些、为什么现在选这个、未来什么条件出现时需要重构。 这样 ADR 才能随着模型和基础设施变化被重新审视。

9. Experiment / Evaluation

用同一开放任务比较 ReAct、Plan-and-Execute、Replanning：成功率、模型调用数、并行度、计划废弃率。

实验应固定数据集、版本和环境，至少记录 success、latency、token/cost、attempt/step 数以及失败类型；涉及随机模型时需要重复运行而不是只看一次结果。

10. 常见问题

基础：Planner → Graph Compilation 最容易被误解的点是什么？

Graph Compiler 是 deterministic translation/validation 层，隔离 Planner 的非确定性输出与 Scheduler 的执行数据结构。

机制：这些能力在一次 Run 的哪个生命周期阶段生效？

沿着 Task → Decompose/Route → Structured Plan → Validate → Execute → Observe → Evaluate → Continue/Replan 找位置，并明确它的输入、输出、持久化事实和失败传播。

工程：如果这一层失败，应该由谁恢复？

先区分 transient failure、invalid input、permission、semantic failure 与 irreversible side effect。恢复策略属于拥有该状态与副作用的 Runtime/adapter，而不是交给模型自由决定。

设计：规模扩大 10 倍后，哪个假设最先失效？

优先检查 context/token、并发/连接池、catalog 大小、持久化吞吐、trace 体积、身份与租户隔离。不要默认“多加机器”能解决语义和一致性问题。

11. Sources

• Anthropic — Building effective agents
• OpenAI Agents SDK — Agent orchestration
• OpenAI Agents SDK — Handoffs

12. 本文结论

掌握本文的标准不是能背定义，而是能画出数据流、写出最小 contract、解释失败恢复，并用测试或 benchmark 证明设计没有只停留在概念层。