AI Agent 规划系统深度解析：OpenClaw、Claude Code、Hermes Agent 三种任务编排哲学

前言：Agent会规划吗？——一个被低估的核心能力

你有没有遇到过这样的情况：给AI助手一个复杂任务，比如"帮我整理这个项目的代码结构，然后生成文档，再部署到测试环境"，它要么一上来就执行第一个步骤，做到一半才发现后面需要的东西还没准备；要么把所有步骤都列出来，但第二步依赖第一步的结果，它却试图并行执行；要么执行到某一步失败了，它就卡在那里，不知道怎么办？

这不是模型不够聪明，而是触及了一个比记忆系统更根本的架构问题：规划系统。

语言模型擅长"下一步做什么"，但不擅长"全局应该怎么做"。让一个LLM在每一步都做决策，就像让一个没有地图的司机开车去一个陌生的城市——每到一个路口才想该左转还是右转，大概率会迷路。

在上一篇文章中，我们深入分析了三个主流框架的记忆系统设计。今天，我们继续这个系列，聚焦规划系统——Agent如何分解任务、处理依赖、应对变化。

同样，我们以OpenClaw、Claude Code和Hermes Agent为案例，看三种不同的规划哲学。

---

第一部分：规划系统的三个核心问题

在拆解具体框架之前，我们先建立一个分析框架。任何一个Agent的规划系统，都必须回答三个根本问题：

1. 任务如何分解？

用户输入"帮我做一个数据分析报告"，这是一个高层次目标。Agent需要把它拆解成可执行的子任务：

• 数据清洗 → 统计分析 → 可视化 → 撰写报告

问题在于：拆多细？ 拆得太粗，每个子任务太复杂，模型处理不了；拆得太细，步骤太多，上下文窗口撑爆，执行开销也大。

2. 依赖如何处理？

子任务之间不是孤立的。统计分析依赖数据清洗的结果，可视化依赖统计分析的结果。这就是任务依赖图（DAG）。

规划系统需要识别这些依赖，决定执行顺序——哪些可以并行，哪些必须串行。错误的依赖处理会导致：执行到某一步发现前置结果还没准备好，或者任务被错误地阻塞。

3. 变化如何应对？

现实世界不按计划运行。工具调用可能失败，API可能超时，用户可能在执行过程中改变需求。

规划系统需要具备鲁棒性：如何检测失败？如何从失败中恢复？是重新规划整个任务，还是只修复受影响的子任务？

这三个问题构成了我们分析规划系统的框架。下面来看三个框架给出的不同答案。

---

第二部分：OpenClaw——静默规划，文件驱动

设计哲学：规划是LLM的一次静默调用

OpenClaw的规划架构建立在一个极简的约束上：规划本身也是一次LLM调用，但不带任何工具——纯粹的"思考"。

在一个不到200行的参考实现中，规划被实现为一个独立的plan工具：

python

{
    "name": "plan",
    "description": "Break down complex task into 3-5 executable steps",
    "parameters": {
        "type": "object",
        "properties": {
            "steps": {
                "type": "array",
                "items": {"type": "string"},
                "description": "List of steps to execute"
            }
        }
    }
}

system prompt要求LLM把任务拆解为3-5个可执行的步骤，以JSON格式返回。为什么是3-5个？这是一个经验性的设计——太少了粒度不够，太多了LLM的注意力会分散，执行时也容易超出上下文窗口。

规划与执行的分离

OpenClaw把规划和执行分成两个独立的阶段：

text

用户请求
    ↓
规划阶段（纯LLM推理，无工具）
    ↓
生成步骤列表（写入文件）
    ↓
执行阶段（逐步执行，每步可调用工具）
    ↓
步骤完成后，更新状态，继续下一步

这个设计借鉴了Plan-and-Solve模式的思想。在规划阶段，模型专注于问题分析和任务分解，不必同时考虑具体计算；在执行阶段，模型专注于按部就班地解决问题，不必再分心于整体规划。

这种分离带来了几个好处：

1. 规划可以复用：生成的计划可以存入文件，后续类似任务可以直接参考

2. 规划可审计：用户可以查看计划文件，确认Agent的理解是否正确

3. 规划可修改：用户可以在执行前手动调整计划

三层记忆支撑规划

OpenClaw把记忆分成三层来支撑规划能力：

• 短期记忆：管当前任务，上下文信息全在这

• 中期记忆：管任务历史，包括之前做过什么、哪里失败了、为什么失败

• 长期记忆：管用户偏好和组织知识

这三层记忆在规划中的作用是不同的。短期记忆帮助Agent在当前任务中保持状态连贯；中期记忆让Agent能从历史失败中学习——"上次我用方案A失败了，这次试试方案B"；长期记忆则让Agent能根据用户偏好调整规划策略——"这个用户喜欢先用简单方案快速验证，再做精细化"。

多智能体调度：三层架构

在更复杂的场景中，OpenClaw支持多智能体调度，采用"组织层-协调层-执行层"三层架构：

• 组织层：定义智能体的角色分工与组织关系，类似企业组织架构

• 协调层：负责任务分解、资源分配与冲突解决，相当于项目管理中心

• 执行层：由各类专业智能体组成，负责具体任务执行

这种架构下，任务调度的核心是合同网协议+黑板模型的混合机制。协调层发布任务需求，专业智能体根据自身能力投标，协调层选择最优投标者；中间结果写入共享黑板，其他智能体可读取并基于此进行后续处理。

依赖处理：从隐式到显式

OpenClaw对任务依赖的处理有一个演进过程。基础的实现中，依赖是隐式的——Agent通过记忆系统记住前面步骤的结果，后续步骤从中读取。这种方法简单但脆弱：一旦记忆被压缩或Agent"忘记"了某个中间结果，依赖链就断裂了。

更成熟的实现中，OpenClaw开始支持显式DAG。通过任务调度引擎，基于强化学习算法实现任务的最优分配。任务依赖被编码为一个有向无环图，调度器根据依赖关系决定执行顺序。

一个有趣的细节是自愈能力：某个工具出问题了，系统可以自动切换到备用路径；某个环节失败了，可以从断点继续，而不是从头再来。这得益于OpenClaw将控制平面和执行平面分离的设计——控制平面负责调度和决策，执行平面负责真正调用工具，两者通过WebSocket实时同步状态，但各自独立演进。

应对变化：从被动到主动

OpenClaw应对变化的策略是被动适应。它不预测失败，而是在失败发生时尝试恢复。恢复机制包括：

1. 工具调用重试：对于临时性失败（如网络超时），自动重试

2. 备用路径切换：某个工具不可用时，尝试替代方案

3. 断点续传：从失败点继续，不从头开始

但恢复的成功率依赖一个前提：Agent有足够的上下文理解为什么失败了。这就需要中期记忆系统提供"之前做过什么、哪里失败了、为什么失败"的信息。

OpenClaw规划系统的适用场景

OpenClaw的规划设计最适合需要人类监督和介入的场景。计划的透明性（可读、可编辑）让用户能够理解和修正Agent的规划逻辑。多智能体调度适合企业级的复杂任务流程。

代价是：规划的智能化程度有限。依赖关系需要用户或开发者手动编码，自动恢复能力依赖记忆系统的质量。

---

第三部分：Claude Code——Sub-agent模式，并行分解

设计哲学：分而治之，专业分工

Claude Code的规划架构核心是Sub-agent模式——把单一智能体拆解为多个专业化子代理，构建起模块化的协作网络。

这个设计哲学与微服务架构如出一辙：将单体系统拆分为多个职责单一、可独立部署的服务，通过明确定义的接口进行通信。

Sub-agent模式解决的核心问题有三个：

1. 任务解耦：将复杂任务分解为可并行处理的子任务

2. 动态资源调度：根据任务需求动态激活特定子代理，避免全局模型重复加载带来的资源浪费

3. 容错与可维护性：单个子代理故障不影响整体系统运行

四层架构

Claude Code的Sub-agent系统由四层架构构成：

1. 任务解析层：通过LLM解析用户请求，生成任务依赖图谱

2. 代理调度层：基于强化学习的调度器动态分配子代理资源

3. 执行单元层：包含15+专业子代理，每个代理专注特定领域（代码生成、数据验证等）

4. 结果整合层：采用注意力机制融合各子代理输出

技术参数上，子代理间通信延迟控制在150ms以内（通过gRPC协议），最大并发子代理数支持64个，动态加载时间小于3秒。

任务分解：从LLM到DAG

Claude Code的任务分解是一个两阶段过程：

第一阶段：解析用户请求，生成任务依赖图谱

LLM分析用户输入，识别出可以独立执行的子任务，以及它们之间的依赖关系。例如，对于"重构这个React组件并更新相关测试"的任务，依赖图可能是：

text

分析组件依赖 → 识别影响范围 → [重构组件, 更新文档] → 更新测试

其中"重构组件"和"更新文档"没有相互依赖，可以并行执行。

第二阶段：调度器分配资源

基于强化学习的调度器根据每个子代理的能力向量和当前负载，动态分配任务。调度算法使用ε-greedy策略，在探索（尝试新的分配方式）和利用（使用已知最优分配）之间平衡。

并行执行：效率的核心

Claude Code的Sub-agent模式最显著的优势是并行执行。

传统的Agent Loop中，每一步都是串行的：思考 → 行动 → 观察 → 思考 → 行动... 这个过程就像一个单线程程序，一个步骤卡住，整个任务就卡住。

Sub-agent模式改变了这一点。任务被分解为DAG后，调度器可以识别出哪些子任务没有依赖关系，将它们分配到不同的子代理上并行执行。这就像把一个单线程程序改写成了多线程版本。

性能数据显示，在金融风控场景中采用Sub-agent架构后，系统吞吐量提升3.2倍，单任务处理延迟降低57%。

子代理的3C原则

Claude Code的设计者提出了构建子代理的"3C原则"：

1. Clear Boundary：明确的输入输出契约。每个子代理的接口必须精确定义，不能有模糊地带

2. Context Isolation：每个子代理维护独立上下文。不共享状态，避免副作用污染

3. Composability：支持与其他代理的无缝集成。子代理应该像乐高积木一样可以自由组合

这个原则确保了子代理的可复用性和可测试性。一个符合3C原则的子代理，可以在不同任务中被重复使用，也可以被单独测试和优化。

应对变化：基于强化学习的动态调度

Claude Code应对变化的方式不是"修复"，而是动态重新调度。

当某个子代理执行失败时，调度器会：

1. 评估失败的影响范围

2. 检查是否有其他子代理可以完成相同任务

3. 如果有，重新分配；如果没有，标记任务失败并向上汇报

这种设计依赖一个前提：子代理的能力向量是标准化描述的。调度器能够理解"子代理A能做任务X，子代理B也能做任务X"，才能实现动态切换。

Claude Code规划系统的适用场景

Claude Code的Sub-agent模式最适合可并行化的工程任务。代码生成、测试、文档更新这类任务天然可以拆分并行。

代价是：系统复杂度高。需要维护15+个子代理的定义、能力描述和通信协议，调试分布式系统的行为比调试单体系统困难得多。

---

第四部分：Hermes Agent——分层规划，自进化执行

设计哲学：规划者、执行者、审核者三位一体

Hermes的规划架构建立在角色分离的理念上。在复杂任务处理场景中，系统可部署三类智能体：

• 规划者（Planner） ：分解任务目标，生成执行计划

• 执行者（Executor） ：调用具体技能完成任务

• 审核者（Verifier） ：验证执行结果，触发修正流程

这个设计的核心洞察是：规划、执行、验证是三种不同的认知负荷，不应该由同一个LLM承担。

• 规划需要全局视角和战略思维

• 执行需要细节操作和工具使用

• 验证需要批判性思维和错误检测

让同一个模型同时做这三件事，就像让一个人同时做CEO、工程师和质检员——不是做不到，但效率很低，质量也难以保证。

声明式DSL：用配置定义任务流

Hermes在任务分解上有一个独特的创新：声明式DSL（领域特定语言） 。

开发者可以用类似YAML的配置文件描述复杂业务流程：

yaml

workflow:
  name: "订单处理管道"
  steps:
    - extract:
        source: "email_inbox"
        pattern: "PO-\d{6}"
    - transform:
        type: "xlsx_to_json"
        schema: "order_schema.json"
    - load:
        endpoint: "erp_api"
        auth: "oauth2"

这种设计的优势是：非专业开发者也能快速构建自动化流程。测试数据显示，在复杂业务场景中，开发效率提升达60%。

更重要的是，声明式DSL将任务分解从"运行时动态生成"变成了"编译时静态定义"。这让任务流可以版本控制、代码审查、自动化测试，把Agent的行为纳入了成熟的软件工程实践。

技能系统：从经验中学习规划

Hermes规划系统最独特的设计是技能系统（Skills） ——它和我们在记忆系统文章中分析的情景记忆是同一套机制，但它的作用远不止记忆。

技能系统在规划中的作用是：存储最优执行路径。

每当Agent完成一个复杂任务（通常是五次以上工具调用），系统会评估这次执行过程是否值得保留为Skill。如果值得，Agent自动把执行步骤、使用的工具、遇到的问题、解决方法，结构化写入一份Markdown文件。

下次遇到类似任务时，Agent可以直接加载这个Skill作为规划的基础，而不需要从零开始分解。

这种设计回答了一个关键问题：Agent如何从自己的执行历史里学习如何规划？ 传统的Agent每次任务都是全新开始，Hermes的Agent会越用越聪明。

三级容错体系

Hermes应对变化的策略是最系统化的——它实现了三级容错体系：

1. 基础层：自动重试+指数退避算法。对于网络波动、临时性失败，自动重试，且重试间隔逐渐增加，避免对后端造成压力

2. 业务层：基于状态机的补偿交易机制。当某个步骤失败时，执行预设的补偿操作——比如扣款失败时，自动执行退款

3. 数据层：分布式事务日志回滚。将任务状态持久化，失败时可以回滚到最近的一致状态

这种分层设计的效果很显著：在金融行业压力测试中，长流程任务的完成率从72%提升至99.3%，同时保持亚秒级响应延迟。

依赖驱动的DAG执行

Hermes的依赖处理借鉴了学术界的D3X（Dependency-Driven, Decentralised eXecution）协议思想：

• 将用户请求编译为子任务的有向无环图（DAG）

• 控制由轻量级Operations Manager事件驱动，父节点完成后立即激活子节点

• 执行在各worker间去中心化，每个worker只接收依赖范围内的上下文

• 当新信息出现时，Subtask Refiner只编辑受影响子图，其他地方进度保持不变

这种设计的效率优势是：总提示负载从平方级降至近线性，墙钟时间接近关键路径长度。评估数据显示，平均加速比达4.00倍，输入token减少最多83%。

Hermes规划系统的适用场景

Hermes的规划设计最适合长期运行、需要积累经验的企业级流程。订单处理、财务审批、客户服务这类业务流程，任务类型相对固定，但每次执行的细节不同，非常适合用技能系统积累经验。

代价是：系统复杂度高，需要时间积累才能看到效果。刚开始使用时，技能系统是空的，Agent的规划能力并不比简单Agent更好。

---

第五部分：规划模式的学术谱系

在深入三个框架之前，有必要了解一下Agent规划的学术背景。理解这些模式，能更好地理解三个框架的设计取舍。

ReAct：思考-行动-观察循环

ReAct（Reasoning + Acting）是最基础的Agent模式。Agent在一个循环中运行：生成思考（Chain-of-Thought推理），基于思考采取行动（调用工具），观察结果，然后重复。

这个模式简单直观，适合动态、交互性强的任务。但缺点也很明显：每一步都需要完整的LLM调用，Token消耗大，延迟高。研究表明，ReAct在处理多工具任务时Token消耗可达ReWOO的约5倍。

ReWOO：计划-执行-求解

ReWOO（Reasoning Without Observation）采用三阶段架构：Planner分解任务为带占位符的子任务，Worker并行执行计划，Solver汇总结果。

这种设计的核心优势是：规划只做一次，工具调用可以并行。在HotpotQA基准测试中，ReWOO实现了约5倍的Token效率提升，准确率也有小幅提升。

但ReWOO有一个致命弱点：计划是固定的，无法根据中间结果调整。如果某个工具调用返回了意外结果，后续步骤可能全部失效。

Plan-and-Solve：先计划后执行

Plan-and-Solve模式将问题解决分为两个明确的阶段：规划阶段分析问题并设计求解路径，执行阶段按规划逐步求解。

OpenClaw的静默规划模式，本质上是Plan-and-Solve的一种实现。

ADaPT：按需分解

ADaPT（As-Needed Decomposition and Planning）是一种递归算法，只在必要时分解任务。当执行器无法完成某个子任务时，规划器介入，将该子任务进一步分解。

这种设计的优势是灵活性：不会一开始就生成一个可能错误的大计划，而是根据执行情况动态调整。代价是需要更多的LLM调用。

Tree of Thoughts：树状搜索

ToT（Tree of Thoughts）将问题解决过程建模为对思维树的搜索。Agent在每一步生成多个候选思路，评估每个思路的质量，然后扩展最有希望的路径。

这种设计适合需要探索多条路径的复杂问题（如逻辑谜题、创意写作）。但计算成本很高——每一步都需要评估多个候选。

模式对比总结

模式	适用场景	Token消耗	适应性	并行能力
ReAct	交互式任务、目标不明确	高	强	弱
ReWOO	多工具、结构化任务	低	弱	强
Plan-and-Solve	顺序多步推理	中	中	弱
ADaPT	复杂度不确定的任务	中	强	弱
Tree of Thoughts	需要探索的任务	高	强	中

---

第六部分：三种规划哲学的本质差异

把三个框架放在一起，可以看出三种根本不同的规划哲学：

维度	OpenClaw	Claude Code	Hermes Agent
规划模式	Plan-and-Solve	Sub-agent并行	Planner-Executor-Verifier
任务分解方式	静默LLM调用生成步骤列表	生成DAG，分配给专业子代理	声明式DSL + 技能系统
依赖处理	隐式依赖→显式DAG（演进中）	基于依赖图谱的并行调度	依赖驱动的DAG执行
并行能力	弱（主要串行）	强（最多64并发子代理）	中（DAG事件驱动）
容错机制	断点续传+备用路径	动态重新调度	三级容错（重试+补偿+回滚）
学习能力	中期记忆记录失败历史	无（每次独立）	技能系统积累执行经验
规划透明度	高（计划写入文件）	中（依赖图谱可查看）	中（DSL可版本控制）

OpenClaw的规划哲学：透明可控，演进中

OpenClaw的设计师相信：规划应该是可审计、可修改的。把计划写入文件，让用户能看见、能改、能追踪变化历史。同时，中期记忆记录失败历史，让Agent能从中学习——下次遇到类似任务，知道"上次这条路走不通"。

这个哲学适合需要人类监督和信任的场景。但规划的自动化程度有限，依赖用户介入。

Claude Code的规划哲学：分而治之，效率至上

Claude Code的设计师相信：复杂任务必须并行，专业分工是关键。通过Sub-agent模式，把任务分解为可并行执行的子任务，由专业子代理各司其职。调度器基于强化学习动态分配资源。

这个哲学适合可并行化的工程任务。但系统复杂度高，且没有学习能力——每次任务都是全新开始。

Hermes的规划哲学：角色分离，经验积累

Hermes的设计师相信：规划、执行、验证应该由不同角色承担，且经验应该被沉淀。规划者负责战略，执行者负责战术，审核者负责质量控制。完成的任务被提炼为技能，下次遇到类似任务可以直接复用。

这个哲学适合长期运行的企业级流程。但系统复杂，需要时间积累才能体现价值。

---

第七部分：如何选择？——一个决策框架

基于以上分析，我建议从三个问题出发做决策：

问题1：任务是串行还是可并行？

如果任务是高度串行的（如数据分析：清洗→统计→可视化），OpenClaw的Plan-and-Solve模式足够。如果任务天然可并行（如代码重构+文档更新+测试），Claude Code的Sub-agent模式优势巨大。

问题2：容错要求多高？

如果任务不允许失败（如金融交易、医疗诊断），Hermes的三级容错体系是最成熟的选择。如果任务允许人工介入，OpenClaw的断点续传和透明计划就够了。如果任务容错要求不高，Claude Code的动态重新调度也够用。

问题3：任务是否重复出现？

如果任务是一次性的（如探索性编程），Claude Code的效率优势明显。如果任务是重复出现的（如日常报表生成），Hermes的技能系统会越用越顺手。如果任务是介于两者之间，OpenClaw的中期记忆提供的"从失败中学习"能力可能是平衡的选择。

混合策略：现实项目的选择

在实际项目中，你可能需要混合策略。一个常见的模式是：

• 用Hermes的Planner-Executor-Verifier架构做顶层设计

• 用Claude Code的Sub-agent模式做底层并行执行

• 用OpenClaw的文件透明性做调试和审计

这不是"选一个"的问题，而是理解每种设计的核心思想，在自己的系统里组合使用。

---

结语：规划是Agent的"大脑"

如果说记忆系统是Agent的"硬盘"——存储事实和经验，那么规划系统就是Agent的"大脑"——决定怎么用这些知识去完成任务。

没有记忆，Agent是健忘的。没有规划，Agent是盲目的。

在本文中，我们看到了三种不同的规划哲学：OpenClaw的透明可控、Claude Code的效率优先、Hermes的积累进化。没有绝对的好坏，只有是否匹配你的场景。

在下一篇文章中，我们将继续这个系列，深入分析工具使用和MCP（模型上下文协议） ——Agent如何安全、可靠地与外部世界交互。敬请期待。

---

思考题

读完这篇文章，我想留给你三个问题：

1. 你的任务场景中，规划的主要瓶颈是什么？ 是分解的准确性，还是执行的效率，还是容错的可靠性？

2. 你的Agent需要从经验中学习规划吗？ 还是每次任务都是全新的？

3. 你愿意为规划系统付出多少复杂度？ 是一个简单的step-by-step列表，还是一个完整的DAG + 多智能体调度？

欢迎在评论区分享你的思考。如果你对某个框架的实现细节感兴趣，也可以告诉我。

---

本文是"AI Agent架构设计"系列的第二篇。第三篇将聚焦工具使用和MCP协议，欢迎关注。