OpenClaw 是当前最受关注的开源个人 AI 智能体框架，GitHub 星标数高达约 19.6 万，由奥地利开发者 Peter Steinberger 于 2025 年 11 月创建。它以”配置优先”（Configuration-first）理念取代传统的”代码优先”模式，通过 Markdown 文件定义智能体人格与行为。与 AutoGen、CrewAI 等开发者库不同，OpenClaw 是一个即开即用的完整智能体运行时，内置 15+ 消息平台接入、子智能体编排、主动行为调度，以及 5700+ 社区技能生态。2026 年 2 月 14 日（也就是前两天），创始人宣布加入 OpenAI，项目将移交至开源基金会继续维护。

之前我们在持续的对该项目进行研究，请参考我之前的文章：

• 谈谈最近爆火的Agent项目Moltbot（原 Clawdbot）
• OpenClaw 记忆系统架构深度解析：从 Markdown 到混合检索
• 深入研究OpenClaw - 系统提示词解析
• 深入解析 OpenClaw 的 Skills 扩展系统：AI Agent 如何学会”自我进化”

今天我们看看它的多Agent协同的设计和思路，从主动行为机制、子智能体协作、与主流框架对比、以及其他多智能体特性四个维度进行深度技术剖析。

OpenClaw 最独特的设计之一是它的智能体不只是被动等待用户指令，而是能通过多种机制自主发起行动。这种”主动性”建立在四个核心支柱之上：心跳系统（Heartbeat）、定时任务（Cron）、事件驱动触发（Webhooks/Gmail Pub/Sub）、以及基于上下文的自主决策。

心跳系统是 OpenClaw 主动行为的基础。 网关守护进程每隔 30 分钟（默认值，可配置）唤醒智能体执行一轮完整的推理。唤醒时，智能体读取工作区中的 HEARTBEAT.md 文件——一份用 Markdown 编写的”检查清单”，定义了每次心跳应关注的事项。智能体据此决定是否需要采取行动：如果一切正常，返回 HEARTBEAT_OK（网关静默丢弃此响应）；如果发现需要用户关注的事项，则主动通过 Telegram、WhatsApp、Slack 等配置好的消息通道向用户发送提醒。心跳系统支持精细配置：可设定活跃时段（activeHours，避免深夜打扰），可为心跳指定更便宜的模型以控制成本，还可按通道控制消息可见性。

定时任务（Cron）则提供更精确的时间控制能力。OpenClaw 网关内置调度器，支持三种调度模式：一次性定时（ISO 8601 时间戳）、固定间隔（毫秒）、以及标准五字段 cron 表达式配合 IANA 时区。每个定时任务可选择在主会话中执行（共享对话上下文，但依赖心跳启用）或在隔离会话中独立运行（无历史上下文污染）。任务完成后可将结果自动推送到指定消息通道。任务配置持久化在 /.openclaw/cron/jobs.json，能够跨重启保留状态。

事件驱动机制进一步扩展了主动触发的场景。网关暴露 HTTP Webhook 端点（/hooks/wake 和 /hooks/agent），任何外部系统——Sentry 错误监控、CI/CD 流水线、自定义脚本——都可以通过 POST 请求触发智能体行动。Gmail Pub/Sub 集成尤为典型：通过 gog gmail watch serve 建立 Gmail → Pub/Sub → OpenClaw Webhook 的完整管道，智能体可以在收到新邮件时自动唤醒、分析邮件内容并决定是否需要提醒用户。社区中已有用户报告智能体自行通过 Twilio API 获取电话号码并拨打语音电话的案例。

这些机制协同工作的核心是 OpenClaw 的“情境式代理”（Situated Agency）架构：每次唤醒时，运行时会动态组装上下文——SOUL.md（人格）、IDENTITY.md（目的）、MEMORY.md（长期记忆）、HEARTBEAT.md（主动行为清单）、近期对话历史、以及可用工具列表——然后由 LLM 推理决定下一步行动。七层权限策略栈（全局 → 智能体 → 群聊 → 子智能体）确保自主行为不越界。

OpenClaw 的子智能体系统（Sub-agent System）实现了真正的并行任务执行能力，其设计围绕隔离性、非阻塞、可配置深度三个核心原则构建。

GPT plus 代充 只需 145

子智能体通过 sessions_spawn 工具创建，这是一个非阻塞调用——发出后立即返回 { status: “accepted”, runId, childSessionKey }，无需等待子智能体完成。核心参数包括 task（必填，任务描述）、model（可选，覆盖模型选择）、thinking（思维深度：off/low/medium/high）、runTimeoutSeconds（超时限制）和 cleanup（完成后是否归档）。每个子智能体运行在完全隔离的会话中，会话键格式为 agent:<agentId>:subagent:<uuid>，拥有独立的上下文窗口、对话历史和 JSONL 转录文件。

通信采用”完成后通告”（Announce）模式。 子智能体完成任务后，runSubagentAnnounceFlow() 函数构建一条结构化消息，包含任务结果、运行时长、Token 用量和估算成本等统计信息。通告消息被投递到发起者的聊天通道，并保持线程路由（Slack 线程、Telegram 话题等）。子智能体可以返回 ANNOUNCE_SKIP 来静默完成内部任务。用户还可以通过 /subagents send <id> <message> 向运行中的子智能体发送消息（等待最多 30 秒获取回复），实现运行期间的交互式通信。

在并发控制方面，默认最大并发数为 8，通过 agents.defaults.subagents.maxConcurrent 配置。子智能体使用专用的队列通道（subagent Lane），与主智能体的 main Lane 分离，确保子智能体运行不会阻塞用户交互。每个智能体会话还受 maxChildrenPerAgent（默认 5）限制，防止单一编排者产生失控的扇出。

嵌套深度是该系统近期才实现的重要特性。最初子智能体被硬编码为禁止嵌套生成，但通过 PR #14447 引入了可配置的 maxSpawnDepth 参数。默认值为 1（子智能体不能再创建子智能体）；设为 2 时启用编排者模式（Orchestrator Pattern）：主智能体 → 编排子智能体 → 工作子智能体。Depth 2 是目前的最大限制——第二层工作智能体永远不能再生成子智能体。不同深度的工具访问权限严格分层：深度 0 拥有全部工具，深度 1 编排者仅获得 sessions_spawn、subagents、sessions_list 等会话管理工具，深度 2 工作者则完全没有会话工具。

模型路由策略是子智能体系统的成本优化关键。解析优先级为：sessions_spawn 调用中的显式 model 参数 → 单智能体配置 agents.list[].subagents.model → 全局默认 agents.defaults.subagents.model → 目标智能体的常规模型解析。典型模式是主智能体使用 Claude Sonnet 等前沿模型，而子智能体使用 MiniMax-M2.1 等更经济的模型，显著降低并行任务的总成本。

跨智能体生成（Cross-agent Spawning）允许一个智能体在另一个智能体的上下文中创建子智能体，需通过 allowAgents 白名单显式授权。子智能体将在目标智能体的工作区、认证配置和工具集下运行，同时继承发起者的认证配置作为后备。子智能体管理通过 /subagents 命令实现，支持 list（列出所有子智能体）、stop（停止运行）、log（查看转录）、info（详细元数据）、send（发送消息）五个子命令。完成的子智能体在 60 分钟（默认）后自动归档，转录文件保留但会话被标记为已删除。

OpenClaw 在多智能体领域占据了一个独特定位：它不是一个开发者工具库，而是一个即用型智能体产品。这一根本定位差异决定了它与 AutoGen、CrewAI、LangGraph 等框架在几乎每个维度上的不同取向。

与 微软的AutoGen相比，核心分歧在于”对话式协作”与”任务式委派”。AutoGen 围绕 ConversableAgent 构建，支持灵活的多智能体对话模式——双智能体对话、群聊、层级结构——智能体通过结构化对话轮次协商解决问题。OpenClaw 的多智能体则更像一个带分工的工作队列：主智能体通过 sessions_spawn 分发任务，子智能体完成后通告结果。AutoGen 在复杂推理和协商场景中更强大，但需要 Python 编码；OpenClaw 零代码即可运行，且内置 15+ 消息平台集成。

与 CrewAI 的对比最为直观。CrewAI 提供三种流程模式（顺序、层级、自定义），任务通过 context 参数声明显式依赖关系，层级模式中管理者智能体可动态委派任务给专家。OpenClaw 的多智能体编排相对简单——以 @mention 路由和子智能体生成为主。CrewAI 通过 LiteLLM 支持数十个模型提供商，有企业级云平台（Oracle、Deloitte、Accenture 等 Fortune 500 公司采用），但需要 Python 开发。OpenClaw 的优势在于配置即部署——SOUL.md 文件定义智能体人格，ClawHub 技能即插即用，5 分钟内可建立多智能体工作流。

LangGraph 代表了另一个极端。它将智能体建模为有向图中的节点，支持循环图、分支决策、人类审批检查点和持久化状态——本质上是一个智能体状态机引擎。对于需要精细控制推理流程的企业级应用，LangGraph 几乎是无可替代的。但它也意味着陡峭的学习曲线和大量的工程投入。OpenClaw 的目标用户则无需理解”状态机思维”，通过自然语言和 Markdown 配置即可实现实用的自动化。

MetaGPT 采用了独特的”SOP（标准操作流程）驱动”路径，将软件开发流程（需求 → 设计 → 编码 → 测试）编码为预定义角色的流水线，通过发布-订阅消息池实现智能体间通信。在 HumanEval 基准上达到 85.9% Pass@1，但应用场景高度集中在软件开发自动化。OpenClaw 则是通用的个人助手，不限于特定领域。

OpenAI Swarm 是最轻量的参照物——一个实验性教育库，无状态设计，无持久记忆，仅支持 OpenAI API，OpenAI 明确建议不用于生产环境。OpenClaw 在几乎所有维度上都更成熟：持久化记忆、多模型支持、消息平台集成、生产级守护进程。Swarm 的价值在于用最简代码演示多智能体概念。

总体而言，OpenClaw 的核心优势在于零代码门槛、消息平台原生集成（这是唯一内置 Telegram/WhatsApp/Discord 等通道的框架）、本地优先的持久化记忆、以及主动行为调度。劣势在于编排灵活性有限（无图结构、无 SOP 流水线）、安全性问题突出（430K+ 行代码、CVE-2026-25253、第三方技能数据外泄风险——Snyk 研究发现 ClawHub 技能中 7.1% 存在关键安全漏洞）、以及缺少企业级产品支持。

OpenClaw 的多智能体系统能够稳定运行，依赖于几个关键的底层基础设施组件。

Lane Queue（通道队列）系统是保证多智能体协调可靠性的核心层。设计哲学是”默认串行，显式并行”：所有 LLM 调用是昂贵的操作，多条消息近乎同时到达时需要防止竞争条件。队列实现为纯 TypeScript + Promises 的进程内队列（无外部依赖），按命名通道分流：main 通道（默认并发 4）处理用户消息和主心跳，subagent 通道（默认并发 8）处理子智能体运行，cron 通道处理定时任务。每个会话键还有专属通道，保证同一会话内严格串行——防止转录文件损坏和状态冲突。这一设计确保子智能体运行和定时后台任务永远不会阻塞用户的实时对话。

记忆系统采用文件优先 + SQLite 混合架构。持久记忆以纯 Markdown 文件存储在磁盘上（MEMORY.md、每日日志 memory/YYYY-MM-DD.md、工作状态 WORKING.md 等），这些文件是唯一数据源，可用 Git 版本控制并手动编辑。索引层使用 SQLite（存储在 /.openclaw/memory/{agentId}.sqlite），结合 sqlite-vec 扩展实现向量搜索和 FTS5 实现关键词搜索。检索时采用混合搜索策略：向量相似度（默认 70% 权重）+ BM25 关键词排名（30% 权重），公式为 finalScore = vectorWeight × vectorScore + textWeight × textScore。每个智能体的记忆完全隔离——独立工作区、独立 agentDir、独立会话存储。多智能体间的信息共享通过共享文件系统目录或外部工具（Notion、Airtable）实现。

错误恢复机制分两个阶段。首先是同一提供商内的认证配置轮换：当某个 API 配置失败时，标记为冷却状态并应用指数退避（1 分钟 → 5 分钟 → 25 分钟 → 1 小时封顶），然后轮换到下一个可用配置（优先 OAuth，按最久未使用排序）。如果所有配置都失败，进入模型降级——按 agents.defaults.model.fallbacks 链依次尝试备选模型。上下文溢出时自动触发压缩而非直接报错；压缩失败则降级思维深度（从 on 切换为 off 节省 Token）；最终手段是会话重置。

OpenClaw 的多智能体系统代表了一种与 AutoGen、LangGraph 等框架截然不同的设计哲学：不追求编排灵活性的极致，而追求实用性的极致。心跳系统让智能体在无人值守时仍能持续工作，子智能体的非阻塞生成与通告模式让并行任务执行变得简单，配置优先的理念让非开发者也能搭建多智能体工作流。但这种取向也意味着明确的局限——无法构建复杂的图结构工作流、缺乏结构化的 SOP 执行保障、安全模型仍在快速迭代中。随着项目移交开源基金会并获得 OpenAI 的支持，OpenClaw 的多智能体能力是否会向更复杂的编排方向演进，将是 2026 年值得持续关注的技术趋势。