Appearance
Plan 如何进入 Runtime：Graph Compilation 与 Code / LLM Orchestration
前置：计划如何被验证并修正：Replanning、Structured Plan、Validation 与 Evaluator
核心问题：一个语义 Plan 怎样变成 Runtime 能确定性调度的 Graph，编译阶段必须拒绝哪些非法依赖？
自然语言 Plan 不能直接交给 Scheduler。Planner 先产出结构化节点和依赖，GraphCompiler 把它翻译成 deterministic graph；明确循环、fan-out、聚合等控制流优先由代码表达。执行结果回来后，如果需要质量判断，再由 Evaluator 产生结构化反馈并决定是否进入受限的优化/重规划循环。这样形成 Plan → Compile → Execute → Evaluate，而不是把四个阶段都交给一个 Prompt。
Mental Model
把 Planner 当作“提出执行结构”的非确定性组件，把依赖合法性、权限、资源和节点状态交给确定性 Runtime。
Planner → Graph Compilation
Planner 输出的是“我建议这样做”，Graph Compiler 把它变成 Runtime 能安全调度的数据结构。
text
StructuredPlan
→ resolve tool/capability
→ normalize node ids/dependencies
→ reject cycle / missing dependency
→ attach execution metadata
→ ExecutableGraph例如 Planner 写出一个未知 Tool，Compiler 应直接报计划不可执行，而不是让 Scheduler 跑到该节点时才失败。这个确定性边界把模型的非确定性结构与 Runtime 的状态机隔开。
Code Orchestration vs LLM Orchestration
依赖、循环、聚合、排序、事务和容错规则明确时，用代码表达；需要语义路由、信息是否充分或下一步探索方向时，才让模型参与。成熟系统通常让模型回答“下一步做什么”，让 GraphCompiler/Runtime 决定“这个结构是否可执行、怎么执行”。这就是 Hybrid orchestration，而不是在代码编排和 LLM 编排之间二选一。
从“语义计划”到“Runtime 能跑的 Graph”
Planner 可能输出：
text
1. 找到 token refresh 的实现
2. 阅读相关配置
3. 修改校验逻辑
4. 运行测试这还不是可调度 Graph。Graph Compiler 需要给步骤稳定 identity，并把数据依赖显式化：
text
search_auth ──→ read_auth ──→ patch_auth ──→ test_auth
│
read_config ────────┘其中 read_config 可以和 search_auth 并行，但 patch_auth 必须等到两个上游都完成。Compiler 还要拒绝类似下面的计划：
text
A depends on C
B depends on A
C depends on B因为这是结构错误，不应该交给 Scheduler 跑到一半才发现“没有 ready node”。因此 Planner 与 Graph Compiler 的职责要分开：Planner 负责开放语义上的“应该做什么”，Compiler 把它收敛成可以被确定性验证和调度的执行结构。
Failure Modes
Execution Graph 接受悬空依赖或 Cycle
症状： Planner 生成 A→B→A，或节点引用不存在 dependency。
为什么危险： Ready queue 无法收敛，或节点在前置事实不存在时被执行。
处理： GraphCompiler 在运行前做 ID 唯一、依赖存在、cycle 和 capability validation。
如何验证
| Case | 断言 |
|---|---|
| Execution Graph 接受悬空依赖或 Cycle | 输入循环/悬空依赖，compile 阶段失败且 Executor 调用为 0。 |
自测
- 为什么 Plan 里的自然语言步骤不能直接丢给 Scheduler？GraphCompiler 至少要补齐哪些可执行信息？
- 一个节点同时声明依赖 A、B，但 A/B 形成环。cycle detection 应在什么时候发生，避免什么运行时后果？