02 Multi Agent - Cygnus Tech Blog

第08章为什么你需要一个多智能体框架 —— 单智能体的困境

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

你是否有过这样的经历：

用大模型帮你处理一个比较复杂的任务，一开始进展顺利，但是随着任务推进，模型开始"健忘"——前面已经讨论清楚的设计决策，后面又忘了，需要你反复提醒；改完了 A 部分，又把 B 部分改错了；想让它同时处理需求分析、代码编写、测试用例，结果每个部分都写得马马虎虎。

如果你用过 Claude Code 或者其他 AI 编程助手，你一定深有体会。

单智能体的困境

当我们用大模型处理复杂任务时，我们默认都是"单智能体模式"——一个对话窗口，一个模型，从头到尾处理整个任务。这种方式在任务简单的时候工作得很好，但是当任务变得复杂，问题就来了：

第09章 sessions_spawn —— 多智能体协作的核心原语

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

OpenClaw 的多智能体协作不是靠“偷偷起一个线程”实现的，而是靠一个明确的会话工具：sessions_spawn。

当前源码里，它的职责很单纯：

在隔离会话里启动一个子智能体运行，并在完成后把结果 announce 回请求方聊天渠道。

它到底生成了什么

普通 sub-agent 的会话键长这样：

第10章协作架构模式 —— 从 Master-Worker 到 Hub-and-Spoke

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

有了 sessions_spawn 这个核心原语，我们就可以构建不同的多智能体协作架构。OpenClaw 并不强制你用某种特定模式，你可以根据任务特点选择最合适的模式。

本文介绍四种常见的协作模式，我们会分析每种模式的优缺点，以及什么时候该用它。

四种常见协作模式

1. Master-Worker 模式

%%{init: {'theme':'base','themeVariables': {'primaryColor':'#f1f5f9','primaryBorderColor':'#0f4c81','primaryTextColor':'#0f172a','secondaryColor':'#f1f5f9','secondaryBorderColor':'#0f4c81','secondaryTextColor':'#0f172a','tertiaryColor':'#fbbf24','tertiaryBorderColor':'#fbbf24','tertiaryTextColor':'#0f172a','background':'#f8fafc','fontFamily':'Inter, system-ui, sans-serif','fontSize':'14px','textColor':'#0f172a','lineColor':'#334155','edgeLabelBackground':'#ffffff','actorBorderColor':'#0f4c81','actorTextColor':'#0f172a','actorFill':'#f1f5f9'}}}%%
graph TD
 M[Master<br/>Coordinator] --> W1[Worker 1]
 M --> W2[Worker 2]
 M --> W3[Worker 3]
 W1 --> M
 W2 --> M
 W3 --> M

结构：一个协调者（Master）把任务分解给多个工人（Workers），工人完成后把结果返回给协调者，协调者汇总结果。

第11章隔离设计 —— 为什么每个子智能体需要独立会话

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

很多人第一次接触 sessions_spawn 会有疑问：不就是让另一个 AI 干活吗，为什么非要搞个独立会话？直接在当前上下文调用不行吗？

答案很简单：隔离带来健壮性。没有隔离，多智能体协作很容易变成一团乱麻。

什么是隔离

OpenClaw 中，每次 sessions_spawn 都会创建一个全新的独立会话：

第12章嵌套协作 —— 如何实现 Orchestrator-Worker 模式

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

前面我们说到，OpenClaw 默认 maxSpawnDepth: 1，也就是主智能体可以 spawn 子智能体，但子智能体不能再 spawn 子子智能体。

但是如果你打开 maxSpawnDepth: 2，就可以支持两层嵌套：

Depth 0: Main Hub (orchestrator)
 ↳ spawn Depth 1: Team Coordinator
 ↳ spawn Depth 2: Worker

这就是 Orchestrator-Worker 模式（或者叫两层编排模式）。什么时候需要这个？本文来讲清楚。

什么场景需要嵌套

你有一个比较大的任务，比如：调研 10 篇论文，总结它们的核心贡献。

第13章实践案例 —— 从零构建一个代码评审团队

ruohuyang@163.com (Cygnus Yang) — Sat, 23 May 2026 00:00:00 +0800

前面五章我们讲完了理论：为什么需要多智能体、核心原语 sessions_spawn、协作架构模式、隔离设计、嵌套协作。

本章我们来做一个完整的实践案例：用 OpenClaw 构建一个自动化代码评审团队。看完这个案例，你就可以照着做，构建自己的多智能体协作系统。

需求分析

我们想要一个这样的代码评审系统：

02 Multi Agent - Cygnus Tech Blog

第08章 为什么你需要一个多智能体框架 —— 单智能体的困境

单智能体的困境

第09章 sessions_spawn —— 多智能体协作的核心原语

它到底生成了什么

第10章 协作架构模式 —— 从 Master-Worker 到 Hub-and-Spoke

四种常见协作模式

1. Master-Worker 模式

第11章 隔离设计 —— 为什么每个子智能体需要独立会话

什么是隔离

第12章 嵌套协作 —— 如何实现 Orchestrator-Worker 模式

什么场景需要嵌套

第13章 实践案例 —— 从零构建一个代码评审团队

需求分析

第08章为什么你需要一个多智能体框架 —— 单智能体的困境

第10章协作架构模式 —— 从 Master-Worker 到 Hub-and-Spoke

第11章隔离设计 —— 为什么每个子智能体需要独立会话

第12章嵌套协作 —— 如何实现 Orchestrator-Worker 模式

第13章实践案例 —— 从零构建一个代码评审团队