agent最基本的就是ReAct范式，其中最关键的就是agent plan，我们主要探讨的是单agent的plan和多agent不同范式如何plan的更好。

单agent

单agent plan指的是同一个agent在一个 loop 里：规划 → 执行（工具调用）→ 观察 → 反思/重规划 → … → 完成。

典型是 ReAct/Plan-Execute-in-loop 一类，不一定显式拆planner/executor，可能只是在 prompt 里让它先列计划再逐步做。

啥时候用单agent

满足下面多数条件时，我会优先单 agent loop：

步骤数不算长：大致几十步以内、且每步信息量不爆炸（不会无限上下文膨胀）。
工具域单一或很少：例如只有 web search + 总结，或只有代码编辑 + 单测（tools use数量少）。
有硬验收：测试/校验能自动判断对错，允许循环修复。
低风险副作用：不涉及高危工具，或所有工具都是只读/无副作用。
不强依赖并行：串行也能接受。

如何做好一个单agent plan呢

很多朋友刚开始做单agent有一个误区，就是一定第一个plan出一个事无巨细的计划，但这是不太可能的。

单agent plan的核心是动态计划 + 每步重规划，通过维护一个plan schema来保证一致性：

plan schema：

Goal（最终目标）
Constraints（预算/时间/范围/禁止事项）
Resources（可用工具/数据源）
Steps[]：每步含 Intent / Input / Tool(s) / Expected Artifact / Done Criteria / Risk
Stop Criteria（什么时候可以停）
Backtracking Policy（失败如何处理）

执行策略：

先出一个粗 plan（5–12 步），不要把细节写爆。
每执行一步：
1. 写出“本步要产出的 artifact（文件/表/结论/证据）”
2. 调工具
3. 用 Done Criteria 判定完成与否
4. 更新 plan（删/改/加）
如果连续 2–3 步没有进展：触发“反思/重规划”分支。

这类planner+executor的逻辑分离在研究上很常见：

Plan-and-Act 明确提出 Planner 生成结构化高层计划、Executor 翻译成环境动作，并在 WebArena-Lite 等长程任务上取得较高成功率。

使用单 agent，也可以把“Planner 输出”当成结构化中间态来做强约束，这里必须要说到OpenAI Agents SDK 。它设计哲学很值得参考：

用很少的原语表达复杂关系，比如 Agent、handoff（agents as tools）、guardrails、sessions（memory）、tracing。

你自己写框架时也建议对齐这种思路，把抽象控制在 5–7 个核心对象：

Tool：函数工具 / MCP 工具（必须有 schema、校验、side-effect 标记）
Agent：instructions + toolset + model settings
Task/Node：输入/输出 schema + 依赖 + 验收
RunContext：会话状态、预算、权限、trace id
Memory：working set + long-term（可选层级记忆）
Guardrail：输入输出校验、策略检查、注入检测
Trace/EventLog：每一步、每个工具调用都可回放

多agent

多agent常见范式是Plan agent + worker subagent，其中Planner 负责“全局目标、分解、依赖关系、验收标准”，Worker 负责“局部执行/产物交付”，再由集成/审阅节点收敛。

要不要从单agent升级到多agent呢？

我认为核心指标有三条：

parse 1：任务跨度与全局约束

如果任务需要跨很多步骤，还要满足全局约束（预算、时间窗、多个选择的组合最优），单 agent 更容易“走着走着忘了全局最优”，或者局部最优导致全局失败。
真实长程规划需要主动信息搜集 + 局部细约束 + 全局约束优化，只要能写出一个清晰的“全局约束/目标函数”而且需要多轮信息获取/比较，那建议还是多agent

parse 2：可并行的子问题和差异化环境

如果子任务能并行（例如：同时查 8 个来源、同时对 3 个方案做成本/风险评估），多 worker 能显著降低 wall-clock 时间并降低单线程上下文拥挤。
工具越多（网页搜索、代码修改、跑测试、数据库查询、写文档…），单 agent 更容易在上下文里混乱。GoalAct 的思路是把执行分解成“高层技能”（searching/coding/writing…）以降低规划复杂度，并在 LegalAgentBench 上提升成功率。
OWASP 的 Agentic Security Initiative 也在强调 agentic 系统的威胁建模与缓解（如提示注入、工具滥用、数据泄露等），权限隔离几乎必须走Planner→Executor 或 Planner→Workers。

parse 3：时延/成本预算

多agent = 多次模型调用 + 协调开销，不一定更省。
由于多agent拿到的上下文不一定是完整的，可能是切割出来的部分上下文 + 相对固定的prompt，结果可能不如完整上下文的单agent plan。

如何设计好一个多agent呢

现有的多agent系统基本上都是DAG系统，由plan agent去规划一个执行图，然后对每个节点分配不同特性的subagent。

DAG系统最核心的观点就是把复杂任务变成可并行、可验收、可重试的工作流。这里给出一个例子：

Planner：输出DAG
每个节点包含：

task_id
owner_role（哪个 worker 做）
inputs（依赖哪些上游 artifact）
deliverable（必须交付什么）
acceptance_tests（怎么验收）
risk_level（是否涉及副作用）
fallback（失败时的备选路线）

Worker：输出结构化

deliverable（产物）
evidence（引用/日志/实验结果）
open_issues（未解决点）
next_suggestions（对 planner 的反馈）

集成/复核层（可用一个 Integrator agent）

合并 deliverables
检查冲突
运行验收（如果可自动化）
触发局部重试（只重跑失败节点，不重跑全局）

要想做好一个多agent系统，最基本的就是把 workflow 当“可执行代码”（workflow-as-code）

先定义一套 operator / node library（Search、Extract、Write、CodeEdit、RunTests、Verify…）
Planner 输出的 plan 是一个 DAG：节点是 operator，边是数据依赖
执行引擎负责：调度、并行、重试、缓存、trace、回放

LangGraph 的 Plan-and-Execute 示例就是这个方向：把计划-执行组织成图，做 step-by-step 执行并支持 revisiting/modify plan。

我们来看四种样例：

GoalAct

GoalAct的架构是把Plan 写成“高层技能序列”，并且每步都可更新。它的核心非常“教科书式”清晰：它维护一个持续更新的全局计划 G，并把计划写成 (plan step, action) 的序列：

G_t=\pi(Q\mid T\mid S_t)

Q为用户问题，T为可用工具集合，S_t为历史记录（包含过去的计划-动作-观测）：

S_t=(P_1A_1O_1,\ldots,P_{t-1}A_{t-1}O_{t-1})

全局计划只需要指定“用哪个技能 + 目标是什么”，不要塞具体的低层细节，这样更可执行、更稳定，也更容易扩展技能包。

这点和它对 Plan-and-Execute 类方法的批评形成呼应：仅有“先计划再执行”不够，如果 plan 里没有可落地的可执行动作/技能约束，计划容易超出 agent 动作空间。

GoalAct 的实验场景是法律任务：LegalAgentBench，强调要用多种工具并完成多类型法律任务，并报告平均成功率提升。所以它很适合：

法律/合规/投研/审计等“检索 + 结构化处理 + 写作”的链条型任务：计划用“技能”表达会比用“网页点击序列”稳得多。
企业知识工作流：当你能清晰定义 skill（检索、SQL、代码分析、写报告、生成表格）并有可控的工具接口时，GoalAct 这类“技能级全局计划”很容易工程化。

Plan-and-Act

典型 Planner/Executor 架构，Planner 产出结构化高层计划，Executor 把计划翻译成环境动作，明确把系统分成两部分：

Planner：根据用户 query 输出结构化的高层步骤（roadmap）；
Executor：结合计划与当前页面状态（HTML 等）执行具体交互动作。

文章指出静态计划容易被动态环境打爆，因此引入每执行一步就更新计划的 replanning：

Planner 在每轮基于“当前状态 + 过去 plans/actions”生成新 plan，并把新信息写进 plan（例如执行后才知道“top contributor”是谁，然后把它写入剩余计划）。

其实这也意味着plan 本身在携带关键上下文，某种程度替代了显式 memory 模块。Plan-and-Act 的观点很“现实”：LLM 天生没被训练成 Planner，所以规划准确性是瓶颈。它提出一个合成数据管线：

先生成/收集成功 action trajectories；
再用 Teacher LLM 把轨迹标注成“grounded plans”（每个高层步骤对应轨迹动作索引）；
再做 plan expansion、targeted augmentation 等扩展。

也正因如此，它适用于这些领域：

在 web navigation 上给出 SOTA：WebArena-Lite 57.58%，WebVoyager（text-only）81.36%。
适合 可大规模采样轨迹、可离线训练/微调 的任务（网页、APP、RPA、客服流程），因为它把“规划”当成可学习的技能来补齐，而不是只靠 prompt。
代价是：动态 replanning 每步调用 Planner 会更慢，论文也提到这点并给出未来方向（由 Executor 决定何时 replan、或者委派给子 agent）。

HiPlan

总的来说，HiPlan是用“里程碑（milestones）”做全局路线图，用“step-wise hints”做局部纠偏，并把经验复用做到“中等粒度”。

HiPlan 明确把长时序任务写成 POMDP，并提出双层引导信号：

全局引导：里程碑行动指南（milestone action guide），是一串自然语言子目标\{m_{1},\ldots,m_{K}\}；
局部引导：每一步的 step-wise hinth_t，用于对齐当前观测与当前里程碑目标。

HiPlan 的亮点是它对“经验复用粒度”的选择：既不是整条任务轨迹（太噪），也不是原子动作（太依赖具体上下文），而是“里程碑级片段”。它在 offline 阶段把专家示范轨迹切成若干 milestone 片段，并存入库中（含 task embedding、milestone embedding、对应轨迹片段等）。

在线执行时：

用 task instruction 的 embedding 去检索相似任务条目，生成“里程碑指南”；
再用当前 milestone 的 embedding 去检索相似 milestone 及其完成该 milestone 的轨迹片段，用于生成 step-wise hints；
最终策略把“全局里程碑 + 当前 hint”融合起来产生动作（论文给出 integrated policy 的形式化表达）。

它还给出了实现细节：里程碑切分用 GPT-4o，检索 embedding 用 SentenceTransformers（all-mpnet-base-v2）等。在全局目标+局部微调这一块，我觉得这很像梯度下降，也是非常成熟的一种运作方式，所以他也合适具有长程的任务：

有“成功轨迹/日志/操作记录”的垂类：电商导购、客服工单处理、企业流程自动化（如报销/采购），你能用历史成功流程构建 milestone 库。
环境动态且可观测不完全的交互任务：局部 hint 的价值更高。

ReAcTree

ReAcTree把“计划”从线性序列升级成“带控制流的 Agent Tree”，用子目标隔离来阻断错误传播。它的关键创新是：把动作空间扩展成三类（论文用形式化描述）：

执行环境技能（skills）
语言推理（thought）
Expand：生成子目标并附带控制流类型（sequence / fallback / parallel）

当 agent node 选择 expand 时，会创建一个 control flow node（行为树风格）和若干子 agent node（每个绑定一个 subgoal），由控制流节点来协调执行与回传 success/failure。也因此有以下俩优势：

子目标隔离：每个 agent node 只携带局部上下文，减少“单一长轨迹”的幻觉与逻辑串扰。
显式控制流：失败重试/备选路径天然可表达，且可解释、可调试。

控制流语义非常清晰：

Sequence：子节点依次执行，全部成功才成功；任一失败则失败；
Fallback：依次尝试，任一成功则成功；全部失败才失败；
Parallel：执行所有子节点并聚合结果，论文用 majority voting。

同样的，ReAcTree 引入两套互补记忆：

Episodic memory：存“子目标级经验”，并用 goal embedding 的 cosine similarity 检索 top-k 作为 in-context examples（论文给出检索公式）。
Working memory：共享黑板，记录环境特定事实（论文重点做“可移动物体位置”），实现上是 Python 字典，并提供 recall location 这类“工具化动作”。

由此获益，适用于以下场景：

具身智能 / 家庭机器人 / 仓储拣选 / 多物体操作：天然需要子任务分解、并发/顺序/回退控制流。
不可回滚、动作不可逆的真实环境：相比“搜索行动树（MCTS/A*）”那类假设可回滚的工作，ReAcTree 更贴近现实约束（论文也强调很多 tree-search 方法依赖可回滚模拟器）。