多 Agent 不是让更多模型参与对话,而是把大模型推理能力微服务化
把 OpenClaw 想象成一个数字生命体,每个组件都是这个生命体的器官,协同工作完成复杂任务:
OpenClaw 多 Agent 架构:顶部串行决策 (Router→Planner→Scheduler) → 中部并行执行 (多 Agent Workspaces) → 底部统一汇总 (Aggregator)
意图识别,决定谁来接任务。像大脑的感觉皮层,接收外部刺激并分类。
任务拆解,把大目标分解成可执行的子任务。像大脑的执行功能中心。
节奏协调,决定谁先跑、谁并行。像心脏泵血,维持系统节律。
并行执行,每个 Agent 是独立的"手臂",可以同时做不同的事。
真正干活的能力,像人使用工具完成具体操作。
汇总合成,像脊柱整合神经信号,形成完整输出。
| 问题 | 表现 | 后果 |
|---|---|---|
| 角色混乱 | 同一个 Agent 又写代码、又分析数据、又回复客户 | 上下文混乱,两件事都没做好 |
| 上下文爆炸 | 多步骤任务,每一步的输入输出都往 context 里塞 | 跑到第五步,模型开始"遗忘" |
| 成本失控 | 每次推理都带着一整条对话历史 | token 用量指数增长,API 费用爆炸 |
| 不可控 | 任何一步失败,整个链条断掉 | 没有重试、降级、追踪,黑盒崩掉 |
设计原则: 上层决策,下层执行,层与层之间只通过接口通信,不共享内部状态。
类比: Router 是公司前台,Planner 是项目经理,Scheduler 是排班系统,Agent 是员工,Skill 是员工手里的专业工具,Aggregator 是最后的汇报会。
| 隔离层 | 实现方式 | 作用 |
|---|---|---|
| 身份隔离 | 每个 Agent 有自己的模型配置和 API 密钥 | 一个用 GPT-4,另一个用 Claude,互不影响 |
| 状态隔离 | 对话历史完全隔离 | 防止 Context Pollution(上下文污染) |
| 工作隔离 | 独立的文件系统区域和记忆存储 | 长期记忆物理隔离 |
这是 OpenClaw 并发能力的核心——父 Agent 可以非阻塞地派生子 Agent,实现真正的并行执行。
async def spawn_agent(self, task: Task) -> AgentResult:
child_id = f"{self.id}_child_{uuid4().hex[:8]}"
child = Agent(child_id, config=self.config)
# 非阻塞,父 Agent 不等待
asyncio.create_task(child.run())
result = await self.bus.request(
f"task/{child_id}",
TaskMessage(task),
timeout=30.0
)
return result
Scheduler 的 DAG 调度实现——在满足依赖约束的前提下,最大化并发度:
async def execute_dag(self, dag: TaskDAG) -> dict:
completed = {}
pending = set(dag.get_ready_nodes()) # 入度为 0 的节点
in_flight: dict[str, asyncio.Task] = {}
while pending or in_flight:
# 同时 dispatch 所有 ready 节点
for node_id in pending:
task = dag.nodes[node_id]
agent = self._select_agent(task)
coro = self.bus.request(
f"task/{agent.id}",
TaskMessage(task, context=completed)
)
in_flight[node_id] = asyncio.create_task(coro)
pending.clear()
# 等待任意一个完成,立刻处理
done, _ = await asyncio.wait(
in_flight.values(),
return_when=asyncio.FIRST_COMPLETED
)
for fut in done:
node_id = _find_key(in_flight, fut)
completed[node_id] = fut.result()
in_flight.pop(node_id)
# 解锁下游
pending |= dag.unlock_downstream(node_id, completed)
return completed
| 层级 | 内容 | 持久性 | 用途 |
|---|---|---|---|
| Working Memory | 当前任务上下文 | 任务结束清空 | 短期工作内存 |
| Episodic Memory | 会话内历史轨迹 | Redis 持久化 | 同一会话多轮交互 |
| Semantic Memory | soul.md 长期知识 | Vector DB 检索 | 跨会话知识库 |
用户输入: "帮我分析这个 GitHub 项目,生成一份完整的技术评估报告"
总时间: ②③④并行,远比串行短
容错: 某个子任务失败 → WatchDog 捕获 → 重试或降级(标注"数据不可用")
OpenClaw 不是一个聊天工具的升级版,它更像一个操作系统:
| OpenClaw | 操作系统 |
|---|---|
| Agent | 进程 |
| Skill | 系统调用 |
| Scheduler | CPU 调度器 |
| MessageBus | 进程间通信(IPC) |
| Memory | 分级存储(寄存器/内存/磁盘) |
| Router | 系统入口(syscall 表) |
先跑通"1 个 Orchestrator + 2 个 Worker"的最小系统,理解消息流转再扩展。
不是按功能过度拆分。"写代码的 Agent"比"什么都干的通用 Agent"好。
Agent 之间信息传递尽量通过消息,减少写冲突。
Agent 决策质量取决于 LLM,Skill 可靠性取决于你的代码。