1. 核心结论

在 Agent 设计中，Plan、Agent loop 和 Harness 是三个不同层级的概念：

• Plan：描述为了完成目标要做什么、按什么顺序做、依赖是什么、何时算完成。
• Agent loop：负责不断执行“观察 → 决策 → 行动”，直到完成、失败、重规划或请求人工介入。
• Harness：承载并约束 Agent 的运行时系统，包括 loop、工具路由、状态、上下文、权限、重试、评估、日志和恢复机制。

一句话概括：

Plan 负责路线，Agent loop 负责推进，Harness 负责让整个过程安全、可持续、可恢复、可观测。

2. Plan 与 Harness 的区别

维度	Harness	Plan
关注点	Agent 如何运行	Agent 要做什么
类型	系统 / 运行时	策略 / 数据 / 状态
作用范围	可覆盖整个 Agent 生命周期	通常针对一个具体任务
是否必须显式存在	Harness 必须存在	Plan 可以是隐式的
是否负责执行	负责调用模型和工具	通常不直接执行
是否管理权限	是	通常不是
是否管理上下文	是	只提供需要保留的任务状态
是否管理异常	是	可以包含重试或替代路径，但不负责真正调度

最小 Agent loop 可以表示为：

3. 常用 Plan 模式总览

模式	核心机制	适合场景	主要代价或风险
直接调用 / 无显式 Plan	模型直接决定下一步	单次查询、简单工具调用、低风险任务	复杂任务容易遗漏步骤
ReAct	思考 → 行动 → 观察 → 再思考	工具结果会改变后续路径的任务	容易循环，调用次数和成本不可控
Plan-and-Execute	先生成完整计划，再执行	目标明确、步骤较多、流程相对稳定	初始计划错误可能传播到后续步骤
动态重规划	执行中根据结果修改计划	浏览器、代码调试、开放式研究	需要可靠的状态和终止控制
Prompt Chaining	固定的多阶段 LLM 流水线	抽取 → 校验 → 生成、提纲 → 写作	灵活性有限
Routing	先分类，再选择专用流程或模型	客服分流、领域路由、模型路由	分类错误会导致整条路径偏离
Parallelization / DAG	独立子任务并行，最后汇总	多来源搜索、多文件分析、多项检查	必须正确识别任务依赖
Orchestrator-Workers	主 Agent 动态拆分并分派子任务	代码库修改、深度研究、复杂分析	编排器可能成为瓶颈
Evaluator-Optimizer	生成 → 评估 → 修改，循环迭代	代码、报告、文案、结构化输出	评审标准不可靠时容易空转
Tree of Thoughts / 搜索式规划	探索多个候选路径并评估、回溯	博弈、复杂推理、方案比较	推理成本很高
Human-in-the-loop	在关键节点暂停并请求人工确认	付款、删除、生产变更、正式发布	自动化程度降低，但风险显著下降
State Machine / Workflow	用代码定义状态和转移	审批、合规、生产流程、高风险业务	可控性高，但开放性较弱

4. 经典 Plan 模式及 Mermaid 流程

4.1 直接调用 / 无显式 Plan

适合简单、低风险、单步或少量工具调用。这里并不是完全没有规划，而是规划通常隐含在模型当前上下文中，没有单独落盘。

适用例子：查询订单状态、获取天气、简单数据库查询。

4.2 ReAct

ReAct 将推理和行动交错执行，适合环境反馈会改变后续路径的问题。

适用例子：网页操作、API 排错、代码调试、信息检索。

优点：灵活、能根据环境反馈调整。

风险：可能反复调用工具、陷入循环、忘记长期目标。因此 Harness 需要设置最大步数、超时、预算和终止条件。

4.3 Plan-and-Execute

先生成一个显式计划，再由执行器逐步完成。

适用例子：制定研究方案、生成报告、分阶段修改代码、跨多个上下文窗口的长任务。

注意：完整计划不应该包含过多不确定的实现细节。更合理的是规划目标、交付物、依赖和验收条件，把局部路径留给执行阶段决定。

4.4 动态重规划

这是 Plan-and-Execute 的增强版本：计划不是一次性固定，而是随着状态持续更新。

适用例子：浏览器自动化、复杂代码修复、开放式研究、外部系统状态不稳定的任务。

4.5 Prompt Chaining

流程由固定步骤组成，每一步的输出进入下一步。

适用例子：

• 文档抽取 → 字段校验 → 数据入库
• 生成提纲 → 检查提纲 → 生成正文
• 代码生成 → 单元测试 → 修复代码

如果步骤路径明确，优先用这种模式，而不是让 Agent 自主决定全部流程。

4.6 Routing

先判断任务类别，再选择专用模型、Prompt、工具或 Workflow。

适用例子：客服分流、模型分级、不同业务线使用不同工具。

4.7 Parallelization / DAG

把没有依赖关系的子任务并行执行，再统一汇总。

适用例子：多个来源搜索、多个文件分析、不同维度的代码审查。

如果存在依赖关系，应使用 DAG，而不是简单的完全并行：

4.8 Orchestrator-Workers

主 Agent 根据任务动态决定需要哪些 Worker 以及每个 Worker 的工作内容。

适用例子：代码库级修改、深度研究、复杂多领域分析。

它和 Parallelization 的区别是：Parallelization 的子任务通常预先定义；Orchestrator-Workers 的子任务由主 Agent 根据输入动态决定。

4.9 Evaluator-Optimizer

生成器先产出结果，评估器根据明确标准检查，并将反馈交给生成器继续修改。

适用例子：代码测试、报告质量控制、格式校验、文案润色。

关键前提是评估标准必须可操作，例如测试是否通过、字段是否齐全、引用是否存在，而不是只有“看起来不错”。

4.10 Tree of Thoughts / 搜索式规划

生成多个候选路径，分别评估，在必要时回溯。

适用例子：复杂规划、博弈、方案比较、存在明显错误回溯需求的问题。

不建议把它作为普通业务 Agent 的默认模式，因为它会显著增加模型调用次数和推理成本。

4.11 Human-in-the-loop

在高风险动作前设置人工确认点。

适用例子：付款、删除数据、生产环境变更、正式发布、法律或医疗相关决策。

4.12 State Machine / Workflow

由程序定义状态和转移，模型只在需要判断或生成内容的节点参与。

适用例子：审批、合规、生产流程、需要稳定性和可审计性的业务。

5. 如何选择 Plan 模式

可以先回答四个问题：

5.1 任务步骤是否固定？

• 固定：Prompt Chaining、Workflow、State Machine
• 不固定：ReAct、Plan-and-Execute、Orchestrator-Workers

5.2 工具结果是否会改变路径？

• 不会：先规划再执行
• 会：ReAct 或动态重规划

5.3 子任务是否可以并行？

• 可以：Parallelization / DAG
• 不可以：串行计划或 ReAct

5.4 错一步的代价是否很高？

• 低风险：允许 Agent 自主循环
• 高风险：State Machine + Validator + Human Approval

6. 场景到架构的推荐映射

场景	推荐架构
简单查询或单次工具调用	直接调用或轻量 ReAct
固定业务流程	Workflow / State Machine
多步骤但目标明确	Plan-and-Execute + Evaluator
浏览器操作、代码调试	ReAct + 动态重规划
多来源研究	Orchestrator-Workers + Parallelization + Evaluator
复杂方案搜索	Tree of Thoughts 或候选方案 + Evaluator
付款、删除、生产变更	State Machine + 人工确认
跨多个上下文窗口的长期任务	显式 Plan + 外部状态 + Harness 恢复机制

7. 模型角色如何分配

不建议把 Planner、Executor、Evaluator 默认绑定到同一个最大模型。可以按能力拆分：

建议：

• Planner：负责任务拆解、依赖判断和重规划。
• Executor：负责工具调用、参数填充和局部动作。
• Router：负责分类和模型选择，可以使用小模型或传统分类器。
• Evaluator：优先使用确定性规则、测试和独立评审；不要只依赖生成模型自评。
• Loop Controller：尽量由代码控制步数、权限、超时和终止条件。

一个常见的生产策略是：

复杂规划 → 强模型
简单执行 → 快速模型
高频分类 → 小模型或规则
关键验证 → 测试、规则或独立评审

8. 推荐的落地顺序

1. 先实现最小 Harness：模型调用、工具执行、状态记录、最大步数和超时。
2. 先用隐式规划或轻量 ReAct 验证任务是否可行。
3. 当出现“忘记步骤、无法跨上下文继续、进度不可见”时，引入显式 Plan。
4. 当出现“计划经常过时”时，引入动态重规划。
5. 当出现“子任务独立且耗时高”时，引入并行或 DAG。
6. 当出现“结果质量不稳定”时，引入 Evaluator、测试或规则校验。
7. 当出现“错误副作用风险高”时，把关键路径收回 Workflow / State Machine，并加入人工确认。

核心原则：

把模型自由度限制在真正需要自由度的地方；把流程、权限、校验、恢复和副作用控制交给 Harness 与程序。

9. 参考资料

• Anthropic：Building effective agents
• Anthropic：Demystifying evals for AI agents
• Anthropic：Effective harnesses for long-running agents
• Anthropic：Harness design for long-running application development
• OpenAI：Unrolling the Codex agent loop
• ReAct 论文
• Tree of Thoughts 论文
• LLMCompiler 论文