Appearance
开放任务怎么拆：Task Decomposition、ReAct 与 Plan-and-Execute
前置：Agent Runtime State Machine；可执行的 Tool Contract
核心问题：面对一个开放任务，什么时候应该边观察边行动，什么时候应该先形成计划再执行，任务应拆到什么粒度？
“修复登录失败”可拆为复现→定位→修改→测试→验证；每步有可观察产物，而不是“思考一下→再思考一下”。Agent 先 grep 错误名，看到结果后决定读具体文件，再基于代码调用测试；每次 Observation 都来自真实 tool result。
Mental Model
text
Goal + Context → Planner → Structured Plan → validation → graph/orchestration → observations → optional replanPlanning 只产生可检验的任务结构；模型生成的计划只是候选控制结构，真正执行前仍要经过 PlanValidator、GraphCompiler 与 Runtime。Observation 变化时生成新 plan version，而不是悄悄改旧计划。
Task Decomposition
分解不是“步骤越多越好”，而是把开放目标拆成可以独立验证、能表达依赖的子目标。每个节点最好能回答：输入是什么、产物是什么、什么事实证明它完成。
例如“修复登录失败”拆成 复现 → 定位 → 修改 → 测试 有明确证据链；若继续拆成“思考原因 → 再思考 → 检查一下”，只是增加模型轮次。反过来只保留一个“修复登录”节点，又很难恢复、并行或定位失败。
ReAct-like Loop
ReAct-like loop 每轮根据 observation 选择 action，适合未知环境探索；风险是循环、token/latency 高和难预测。Runtime 仍要控制预算与终止。
工程上应把可执行 Action 结构化，并由 Runtime 控制终止与工具权限。
Plan-and-Execute
Plan-and-Execute 先生成较完整计划，再由执行器逐步推进，适合依赖结构相对稳定、需要审查/并行/持久化的长任务。它的主要风险是 plan stale：环境和 Observation 已变化，初始计划却还在被机械执行。
因此 Plan 应是可验证、可版本化的数据结构；新事实推翻旧假设时进入 replanning，而不是静默修改旧计划或把它当不可变脚本。
最小实现 / 数据结构
python
@dataclass
class PlanNode:
id: str
objective: str
dependencies: tuple[str, ...]
completion_criteria: str
plan = validator.validate(await planner.plan(task))Failure Modes
Planner 输出未经验证就直接执行
症状： 模型生成步骤后不做 schema/dependency/capability validation。
为什么危险： 缺失依赖、危险 Tool、循环或无效节点直接进入执行面。
处理： Plan 先结构化并经过 PlanValidator/GraphCompiler；模型负责提出，程序负责证明可执行。
如何验证
| Case | 断言 |
|---|---|
| Planner 输出未经验证就直接执行 | ScriptedPlanner 产出缺失 dependency/未知 Tool，断言 graph 不进入 Scheduler。 |
自测
- 任务高度不确定且每一步都会暴露新信息时，为什么一开始生成 30 步完整计划往往不如 ReAct 式推进？
- Planner 产出一个引用不存在 Tool 的步骤。这个错误应该在 Graph/Scheduler 哪一层被挡住，为什么不能边执行边“看看”？