规划型 Agent 技术栈

这个 pack 里有什么

这个栈是你跑完第一条 30 步的 ReAct trajectory、在第 14 步开始飘、然后意识到 Agent 从来没真正有过计划——它只是有惯性——之后会去搭的栈。

每一件资产都瞄准做 plan-then-execute Agent 的开发者：Agent 先写计划，再按计划执行，再修订。这就是 ReAct 家族（reason+act 交错）、ReWOO（一次性把整套计划写完，规划期不看 observation）、Plan-and-Solve（先拆再逐步解）。要让这三种模式真正落地，下面这四层必须先到位：

1. 模式素养 — 不读完模式表你没法在 LangGraph 和 AutoGen 之间选。
2. 编排框架 — 把计划从一步带到下一步的状态机或对话图。
3. 拆解 + 持久化 — 把目标拆成子任务，把计划写到 Agent 崩溃后还能再读到的地方。
4. 评审 / 世界模型 / 评测 — 让 demo 级别的计划变成可以放进 CI 的计划。

这个 pack 故意不与 TokRepo 上已有的 multi-agent-frameworks 重叠。那个 pack 讲的是多个 Agent 之间怎么协作（CAMEL、LangGraph 作为编排器、DeepAgents、GPT Researcher）；这个 pack 讲的是单个 Agent——或者一个 Agent 群里的 planner——到底怎么规划。零个重复 workflow ID。两个 pack 配对很顺：先装这个给 planner，再装 multi-agent 给 executor 团队。

按顺序装（读 → 编排 → 拆解 → 持久化 → 执行 → 评审 → 评测）

1. AI Agent Design Patterns — Architecture Guide 2026 — 从这里开始。写第一行 LangGraph 之前，先认清三种规划家族：ReAct 把 Reason → Act → Observe 交错（便宜、皮实、但长程会飘）；ReWOO 一次性把所有工具调用规划完再执行（省 token、但首版计划错就全错）；Plan-and-Solve 先拆再逐步解（长程默认）。这条是架构地图。
2. Awesome Agentic Patterns — Practical Blueprints — 知道了模式还得有菜谱。这份目录集中收纳了规划、工具使用、reflection、recovery 等蓝图。设计时遇到问题查一查，几乎都能找到已命名的对应模式。
3. LangGraph — Build Stateful AI Agent Workflows — 多数 plan-execute Agent 最终落地的编排框架。计划是一个节点，执行器是一个节点，修订步骤是一个节点，LangGraph 在它们之间承载状态 + checkpoint。30 步计划在第 17 步崩溃？从 checkpoint 续跑。这条选的是 workflow 取向的入口，与 multi-agent pack 里的编排取向条目刻意区分。
4. AutoGen — Multi-Agent Conversation Framework — 当规划本身就是一场对话（planner + critic + executor），AutoGen 的 GroupChat 是最干净的抽象。声明 Agent 列表 + 说话者选择策略，框架就会让对话一直跑到目标达成。专门用在『以对话进行规划』这一类；图状的计划用 LangGraph。
5. Claude Code Agent: Task Decomposition — 真正做拆解那一步的子 Agent。丢进 .claude/agents/，给它一个目标，它输出按依赖排序、去重过的子任务清单。生产级 planner 多数会把这一步交给专家子 Agent，而不是让 planner LLM 在大 prompt 里顺手拆。
6. Planning with Files — Manus 风格持久化规划技能 — Manus 的招牌动作是把计划写进一个 Agent 每一回合都重读的文件。这条把这种模式打包：plan.md、progress.md、append-only 日志。是这个 pack 里最便宜的一次健壮性升级——Agent 根本丢不掉计划，因为它从磁盘读，不靠记忆。
7. Plandex — Terminal AI for Large Codebases — 你可以读源码学的 plan-execute 参考实现。Plandex 跑完整闭环：拆解编码任务、写计划、逐步执行、在 checkpoint 处请求评审。拿自己仓库跑一次看 trajectory，是理解『生产级 planner 长什么样』的最便宜方式。
8. Plannotator — Visual Plan & Diff Review for Agents — 当 Agent 有了计划和 diff，需要人（或 critic Agent）并排评审。Plannotator 给你一个可视面板：一边是计划步骤、一边是每一步产生的 diff，可逐行标注。塞到 execute → merge 之间。
9. Agentic World Modeling — Research Directory — 规划型 Agent 的前沿方向是显式维护世界模型（库里有什么、文件存在什么、用户已经说过什么），让计划落在状态上而不是幻觉上。这份精选研究目录——论文、benchmark、代码库——在你决定要不要外挂状态存储之前先读一遍。
10. Agent Evaluation — Test Virtual Agents in CI — 闭环收口。没有 plan 评测，每一次 prompt 改动都是凭感觉。这套 harness 在三个维度给 trajectory 打分：计划质量（计划本身是不是最优？）、执行保真度（Agent 真按计划走了吗？）、最终结果（目标达成没？）。每个 PR 都跑。它输出的数字是唯一能告诉你『v2 的 planner 真比 v1 好』的信号。

它们怎么拼起来（plan-then-execute 闭环）

┌─────────────────────────────────────────────────────────────┐
│  先读                                                       │
│   AI Agent Design Patterns  ──►  ReAct / ReWOO / Plan-Solve │
│   Awesome Agentic Patterns  ──►  命名蓝图查表                │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  编排                                                       │
│   LangGraph（图式计划）   或   AutoGen（对话式计划）          │
│        │                                                    │
│        ▼                                                    │
│  拆解                                                       │
│   Task Decomposition 子 Agent  ──►  有序子任务清单           │
│        │                                                    │
│        ▼                                                    │
│  持久化                                                     │
│   Planning with Files          ──►  plan.md / progress.md   │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  执行                                                       │
│   Plandex 风格闭环  ──►  step → tool → diff                  │
│        │                                                    │
│        ▼                                                    │
│   Plannotator       ──►  人/critic 评审 diff                 │
│        │                                                    │
│        ▼                                                    │
│   Agentic World Modeling  ──►  更新状态，偏了就重规划         │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  评测                                                       │
│   Agent Evaluation  ◄── 计划质量 + 保真度 + 结果              │
│                          （每个 PR 在 CI 里跑）              │
└─────────────────────────────────────────────────────────────┘

这个分层是刻意的。读是一次性的；编排 / 拆解 / 持久化是 setup，每个 Agent 只做一次；执行 / 评审 / 世界模型是每个任务都跑的热路径；评测包裹一切，是唯一能穿越 prompt 漂移、模型更换、库升级仍然有效的反馈信号。

你会撞到的取舍

• ReAct vs ReWOO vs Plan-and-Solve。 ReAct 是简单默认——每步后看 observation——但长程烧 token，因为每步都要重读 trajectory。ReWOO 把整套计划塞到一个调用里（便宜快），但首条 observation 一翻盘计划就全废。Plan-and-Solve 是中间路线，Manus / Plandex / 多数生产级 planner 都用：拆一次，执行时轻度修订。没有特殊理由就从 Plan-and-Solve 开始。
• 规划用 LangGraph 还是 AutoGen。 LangGraph 把计划当图——你画状态机、Agent 在上面走、checkpoint 白送。AutoGen 把计划当对话——planner、executor、critic 互相讲话直到共识。LangGraph 适合确定性 pipeline 和需要 resume 的长程任务；AutoGen 适合『规划本身就是产出』（头脑风暴、设计评审）。成熟方案常见组合：LangGraph 当外层图，在某个 planner 节点内部嵌入 AutoGen GroupChat。
• prompt 里的计划 vs 磁盘上的计划。 计划留在 LLM context 里快但每次重启都丢、第 10 步后还会撑爆 context。Manus 风格把 plan.md / progress.md 写盘，每回合多一次工具调用，但 resume、审计、人工接管都变得 trivial。任何跑 10 分钟以上的 Agent 默认就该把计划落盘。
• 单个 planner LLM vs 拆解专用子 Agent。 让同一个模型同时拆、做、改一步省一跳，但子任务多就掉链子——模型会本能地少拆装高效。专用拆解子 Agent（独立 system prompt、更低 temperature）能输出更平、更可并行的清单。日常任务超过 ~5 个子任务就该上专用子 Agent。
• plan 评测 vs 只看结果的评测。 只看最终结果会漏掉一种情况：Agent 计划糟透了但歪打正着——下个月一定回归。只看计划而不看结果，又会漏掉那种『写得很漂亮然后完全没照做』的 Agent。两个都打分，分开打。这个 pack 里的 CI harness 两件都做。

常见踩坑

• 没有重规划触发条件。 t=0 写的计划到第 12 步必然过期，因为世界变了。要显式建一个 replan trigger——常见条件是 if last_step_failed or world_state_diff > threshold then revise_plan。没有这个，Agent 会沿着死路一直跑到预算耗光。
• 拆解失控。 朴素拆解器会把一个任务拆成 40 个子任务、每个再拆 40 个。一定要限制递归深度、限制子任务总数、在拆解器 system prompt 里明写『顶层优先 3–7 个子任务』。
• 没有计划持久化。 跑到一半崩不是稀有事件。计划只活在 LLM context 里 = 一切从头开始。从第一分钟就把计划写盘。这个 pack 里的 Manus 风格 skill 只有 60 行，第一次 OOM 就回本。
• plan 和 execute 用同一模型还没 critic。 Planner 会偏向 executor 容易做的计划，executor 会偏向无脑执行 planner 说的话。加一个独立 critic Agent（不同 system prompt、最好不同模型）专门负责在执行前指出坏计划。AutoGen 的 GroupChat 让这一步几乎免费。
• 评测 LLM 而不是评测 trajectory。 容易陷入只测『LLM 输出的计划文本看着像不像样』，漏掉 Agent 根本没照做。要评测 trajectory：执行动作有没有和计划对上？偏离时是不是有合理原因？这个 pack 选的 Agent Evaluation 算的是 trajectory 保真度，不是计划散文。
• 把规划当多 Agent 用。 很多团队动不动就上多 Agent 群，其实只需要一个带好拆解器的单 planner Agent。先用一个模型试 plan-then-execute；只有当你能给第二个 Agent 起一个明确角色名（critic、世界模型管家、工具专家）时才加。

这个 pack 不够用的时候

规划型 Agent 在长程、多步、可恢复的任务上发光：重构、研究、跨文件编辑——任何 trajectory 至少 5 步、重跑成本不便宜的活。它在以下场景吃亏：

• 延迟敏感的短任务 — 整个交互不到 30 秒，规划开销吃完预算。直接 ReAct。
• 没有清晰成功标准的任务 — 写不出评测就说不清规划好不好。先花一周建评测集再调 planner。
• 执行器本身是一个 Agent 群 — 那还需要 multi-agent-frameworks pack。planner 在这边、群在那边。

落地建议：读完模式手册，用 LangGraph + 文件持久化搭最小 plan-execute 闭环，在真实仓库上跑一遍 Plandex 看看『好』长什么样，再调 prompt 之前先把评测 harness 接上。