OpenClaw 多 Agent 实战:从＂一个人扛＂到＂团队协作＂

凌晨一点。我的客服 Agent 又卡死了。

事情是这样的：一个用户在 Telegram 上连续发了三条消息——”帮我看看这段代码为什么报错””顺便查一下这周的天气””对了，你们团队还招人吗”。

同一个 Agent ，同一个 prompt ，同一个模型。结果呢？代码看了半截就开始聊招聘，天气还没查就跑去改代码。回复出来一团浆糊，用户直接打了个”？”。

我坐在屏幕前，突然意识到一个问题：我让一个人干了三个人的活。

这不应该。代码审查、天气查询、招聘咨询——明明是三个完全不同的场景，为什么要塞给同一个 Agent ？

上一篇我们把 prompt 调好了、插件写完了、监控搭上了。但所有这些，都是在一个 Agent 的框架里折腾。今天我们要往前走一步：多 Agent 协作。

一个 Agent 的极限：不是你 prompt 写得不够好

先说清楚一件事。多 Agent 不是为了炫技，是因为单 Agent 真的有天花板。

我总结过三条单 Agent 的瓶颈：

第一，上下文污染。 一个 Agent 既要写代码又要聊天又要查数据， system prompt 里塞了十条规则，模型根本抓不住重点。就像你跟一个人说”你既是医生又是律师又是厨师”——他每件事都懂一点，每件事都不精。

第二，工具权限混乱。 你给客服 Agent 开了查数据库的插件，又开了跑代码的插件，还开了发邮件的插件。用户一句”帮我看看”， Agent 可能同时触发三个插件，结果互相打架。

第三，没有回退机制。 单 Agent 一旦走错一步，后面全崩。没有一个” supervisor “角色来审校、来纠偏、来决定”这条路不对，换一条”。

所以问题不是 prompt 不够长，是架构本身需要升级。

图 1 ：同一个 Agent 被迫同时处理代码、天气、招聘三件事——上下文互相污染，输出质量断崖式下跌

多 Agent 协作的三种模式

不是随便堆几个 Agent 就叫协作。我观察下来，真正有用的多 Agent 架构有三种：

模式一：分工型（各司其职）

最简单也最有效。每个 Agent 只干一件事， OpenClaw 的路由层根据用户意图分发。

我的实际配置大概这样：

用户问”天气”→ InfoAgent 。问”这段代码”→ CodeAgent 。问”招人吗”→ BizAgent 。

OpenClaw 的 Route 配置里加一条 intent 规则就能实现：

routes:-channel:telegram_botagent:InfoAgentcondition:"intent=='query'"-channel:telegram_botagent:CodeAgentcondition:"intent=='code'"

这种模式最稳。每个 Agent 的 prompt 可以很聚焦，模型出错概率直接腰斩。

模式二：评审型（一人干活，一人把关）

适合对质量要求高的场景。比如让 Agent A 生成内容， Agent B 审核。

我在内部文档梳理的场景里用了这个模式：

Writer 写完发给 Reviewer ， Reviewer 要么通过，要么打回修改意见。两轮下来，文档质量比单 Agent 直接输出高一个档次。

关键是——两个 Agent 用不同的模型。 Writer 用 GPT-4o （生成能力强）， Reviewer 用 Claude 3.5 （逻辑审查更严谨）。模型之间的”视角差”就是评审的价值。

模式三：链式型（流水线）

最复杂，但也最有潜力。任务被自动拆成多个步骤，每个步骤由一个 Agent 完成，输出作为下一步的输入。

举个例子：用户说”帮我分析一下竞品”，链式流程可能是：

三个 Agent 串成一条流水线，中间用共享的临时存储（比如 Redis ）传递数据。

这种模式就是上一篇我说过的”真正有趣的事情”。它不再是”回答一个问题”，而是完成一个任务。

图 2 ：三种协作模式的分工逻辑——分工型是”各管一段”，评审型是”双人复核”，链式型是”流水线作业”

OpenClaw 里的多 Agent 路由实战

上面说的三种模式， OpenClaw 都能支持。关键是 Route 配置怎么写。

最简单的是基于关键词的分发。在 config.yaml 里：

agents:-name:code-agentsystemPrompt:"你是一个资深工程师..."provider:openaimodel:gpt-4o-name:info-agentsystemPrompt:"你是一个信息查询助手..."provider:openaimodel:gpt-4o-miniroutes:-channel:telegram_mainagent:code-agenttrigger:"message.contains('代码')ormessage.contains('bug')"-channel:telegram_mainagent:info-agenttrigger:"message.contains('天气')ormessage.contains('股价')"

更高级一点的是基于意图识别。 OpenClaw 支持让一个小模型（比如 GPT-4o-mini ）先做意图分类，再把消息路由给对应的 Agent 。这样比关键词匹配准得多。

我自己现在用的是混合策略：先过一层意图分类，如果是明确的技术问题走 CodeAgent ，模糊的问题先走一个”调度 Agent”，由它判断该转给谁。

这个”调度 Agent”的 prompt 很短：

systemPrompt:|你是调度员。用户的消息可能涉及多个领域。你的任务只有一个：判断这条消息应该交给谁处理。可选目标：CodeAgent（技术）、InfoAgent（查询）、BizAgent（商务）。不要回答用户的问题，只输出目标 Agent 的名称。

专门干一件事，反而比让大模型全能干得更准。

图 3 ：调度 Agent 做第一层分发，专业 Agent 做第二层执行——OpenClaw 的路由配置就是这个架构的落地

自主规划：让 Agent 自己决定怎么拆任务

多 Agent 协作的终极形态，不是人写死流程，而是Agent 自己决定需要什么、找谁帮忙、按什么顺序执行。

这就是现在热门的”Agentic Planning”——代理自主规划。

简单实现的话，可以在 OpenClaw 里加一个 Planner Agent。它的工作流大概这样：

Planner Agent 本身不干活，只负责”排班”。它的 prompt 核心就一句：”你是一个项目经理，你的任务是拆解任务并分配资源。”

这个模式在 OpenClaw 里实现需要写一点调度逻辑（目前官方没有内置的 planner ），但思路是通的。我自己搭了一个简化版，用 Redis 做中间状态存储，效果已经够用了。

但要注意一个坑： 自主规划不是让 Agent 无限递归。一定要设最大步数（比如最多 10 步）和超时（比如 2 分钟），否则它可能在一个任务里绕来绕去，账单先炸了。

图 4 ：自主规划的本质——让 Agent 当项目经理，而不是当苦力。 Planner 拆解，专家执行，结果汇总

写到这，四篇文章的脉络清晰了

第一篇：选框架。第二篇：搭起来。第三篇：调好单 Agent 。第四篇：多 Agent 协作。

四篇看完，你手里有的不只是一个聊天机器人，而是一个可以调度多个专家、可以自主规划任务、可以流水线协作的 Agent 团队。

但这还不是终点。

下一个真正让人兴奋的层次是长期记忆——Agent 能记住用户是谁、上次聊了什么、偏好是什么。不是每次对话都从零开始，而是像跟一个真的助手一样，越用越顺手。

这个我还还在摸索。等跑通了，再来填坑。

先把手里的多 Agent 团队搭起来吧。

一个人扛，总有极限。团队协作，才是出路。

💡温馨说明： 本文内容由「青城源码」团队结合 AI 辅助创作与人工校对整理而成，所有核心观点与实操步骤均经过人工验证。

如果你也对 AI 自动化内容生成、 AI Agent 框架搭建、技术落地实操感兴趣，或是有相关项目开发、学习交流的需求，欢迎在后台私信咨询，我们会为你提供专属的技术交流与学习建议。

摘要： 单 Agent 有天花板，多 Agent 协作才是出路。分工、评审、链式三种模式， OpenClaw 路由实战配置，以及自主规划的简化实现。

标签： #OpenClaw #AI Agent #多智能体 #Agent 协作 #自主规划

关键词： 多 Agent 协作、 AI Agent 团队、 OpenClaw 路由、智能体编排、 Agentic Planning