Planning & Execution：从下一步行动到完整任务Planning Agent: Decompose, Execute and Replan

No.17 的 ReAct 循环每次只回答一个局部问题：在当前 state 和 Observation 下，下一步应该调用哪个工具。复杂任务却还有另一组无法靠单步贪心自然解决的问题：哪些结果必须先拿到、哪些步骤可以同时进行、什么时候算真正完成、失败后哪些产物仍然有效，以及剩余预算是否足够继续。

No.18 的对象不是更长的聊天记录，而是一份可执行、可验证、可修改的任务计划。Planner 把 Goal 变成 DAG；Executor 只运行 ready steps；Runtime 维护状态、预算、取消和证据；Replanner 只在当前计划结构已不再可行时替换未完成子图。

“研究一下”“处理代码”“看看是否正常”看似是步骤，实际没有清晰的输入边界和结束条件。一个可调度步骤至少要回答四件事：消费什么、产生什么、由什么证据证明成功、失败会影响哪些后继。下面继续使用 G-TODO-CSV，不再切换任务。

分解粒度也不能无限变小。把每一行代码拆成 step 会让规划、状态更新和验证开销超过执行收益。经验规则是：当产物能被独立验证、依赖、重试、取消或并行时，才值得成为单独步骤。

S7 不只是显示序号。完整引用坐标是 plan_id / version / step_id / attempt，例如 P1 / v1 / S2 / #1。Trace、日志、预算、依赖边、验收条件和取消事件都通过它指向同一次逻辑执行；Step ID 在一个 plan version 内必须唯一，并且一旦产生可消费输出就不能被静默复用。

输出契约还应说明结构、版本、来源和完整性。例如 test_report@v2 不只是“测试通过”四个字，而是包含 suite、exit code、AC1–AC4 predicate 结果、artifact hash 与生成它的 plan version。

在有向无环图中，边 S2 → S4 表示 S4 必须等待 S2 的 csv_rules；它不表示二者属于不同 Agent，也不表示 Runtime 一定拥有足够资源。并行首先由依赖允许，然后还要通过资源锁、预算预留、并发上限和副作用冲突检查。

S1 检查项目结构与待办数据
├─ S2 检索 CSV 规则 ─────┐
└─ S3 检查交互与页面风格 ─┴→ S4 设计 CSV 导出契约
                               ├─ S5 实现 CSV 逻辑 ─┐
                               └─ S6 接入导出按钮 ──┴→ S7 测试 → S8 验收

1. Plan：从 Goal Contract 生成 versioned DAG 与每步输出契约。
2. Validate：检查 ID、依赖、环、契约、验收覆盖和预算可行性；INVALID 时禁止执行。
3. Schedule：从 Ready Set 中选择不冲突的步骤，先预留预算，再并行 dispatch。
4. Observe：只接受真实工具或代码运行产生的 output artifact；写入 append-only Ledger。
5. Update：把 succeeded / failed / cancelled 传播到后继，重新计算 ready、blocked 和剩余预算。
6. Accept：没有 ready steps 不等于成功；还必须逐条验证 Goal Acceptance。

No.17 的行动循环可以嵌入第 3–4 步，用于完成某个复杂 step；No.18 的 Scheduler 不替代工具选择，而是为每次局部行动提供全局依赖、预算和完成语境。

pending → ready → running → succeeded
                         ├→ failed
                         └→ cancelled

blocked = pending AND any(dependency ∈ {failed, cancelled})

blocked 不应覆盖成一个不可逆的主状态：Replan 可能替换失败依赖，使原本 blocked 的目标重新可达。真正的 Ledger 需要记录事件序列，而不是只保存每步最后一个字符串。

对有副作用的步骤还需要幂等键、提交边界和补偿策略。取消一个“尚未分派”的步骤很安全；取消一个已经写入外部系统的步骤，可能只能停止后续工作并执行补偿，而不能假装它从未发生。

Replan 不是“再想一次”的同义词。如果新计划没有可见 diff，没有说明哪些成功产物被保留、哪些旧后继被淘汰、预算怎样重新分配，那么它只是一次不可审计的重试。

默认契约漂移场景中，S7 发现 export_ui 与 csv_exporter 的输入契约不一致，因而没有产生可信 test_report；S8@v1 已经失去可用输入。Runtime 先把它标记为 cancelled，随后 Plan v2 插入 R1 定位边界、R2 生成增量 contract_fix、R3 只重跑受影响测试，最后创建 S8@v2。

Plan v1: S5 csv_exporter + S6 export_ui → S7 failed → S8 blocked
                                               │
                                               └─ cancel S8@v1

Plan v2: preserve S1…S6 → R1 diagnose → R2 repair → R3 test → S8@v2

三种策略继续共享实验一的同一个 G-TODO-CSV：检查项目与待办数据，并行获得 CSV 规则和页面风格，设计导出契约，并行实现 csv_exporter 与 export_ui，运行测试，最后按 AC1–AC4 验收。从 Goal 到核心实验始终只有这一项任务。

唯一自变量是控制策略：ReAct only 逐步选择局部动作且没有显式全局 Plan；Plan → Execute 先生成并验证固定 DAG；Plan → Execute → Replan 允许在结构性失败后取消旧分支并提交有效 Plan v2。

1. ReAct only：能局部恢复，但全局冗余吞掉最终验收预算

A3 在 csv_rules 与 csv_export_contract 尚未齐备时提前接入按钮，形成一次 blocked 冗余步骤；S7 发现 export_ui / csv_exporter 契约漂移后，它又重新检查已经看过的项目与数据。它最终修复并重跑测试，却已经花完 40 units；分派需要 1 unit 的 S8 时触发预算 guard。失败原因不是模型完全不会修，而是没有全局依赖和恢复预算。

2. Plan → Execute：调度高效，但固定 DAG 不能消化结构性新事实

S2/S3 与 S5/S6 两组并行，使执行贴近 Critical Path；S7 failed 后 S8 因缺少 test_report 正确 blocked。它没有越权改图或伪造成功，因此 Plan Completion 为 75%。这是一种正确失败：系统知道 P1 v1 已经不够，却没有 Replanner 能力。

3. Plan → Execute → Replan：先取消旧下游，再最小替换失败子图

Runtime 保留 S1–S6，取消 S8@v1，插入 R1/R2/R3，并用 S8@v2 重新验收。总成本 39 小于预算 40；没有重新检索 CSV 规则或重复检查页面风格。Replan Recovery 为 100%，但只有在 contract drift 场景才有定义。

当前实现是一个确定性、单进程、单 Agent 的教学 Runtime。它没有持久化跨会话记忆，不会把工作委派给其他 Agent，也不模拟分布式队列、租约、跨机器补偿事务或生产级权限系统。这些都不是缺失的“隐藏功能”，而是明确的 scope boundary。