共计 6657 个字符，预计需要花费 17 分钟才能阅读完成。
最近在折腾 OpenClaw 的过程中，我越来越觉得一个单一的 AI 助手很难满足所有场景的需求。比如我日常会用 AI 帮忙写代码，也会用来做资料调研，偶尔还需要它帮我跑一些自动化任务。但问题是，这些任务对 AI 的要求完全不一样——写代码需要强推理能力的模型，做调研需要联网搜索的工具，而自动化任务则需要定时执行和脚本运行的权限。如果把所有这些都塞给同一个 Agent，不仅上下文会互相干扰，工具权限也很难做到精细化控制。正好我已经运行了一个 7 * 24 的 OpenClaw ，它的多 Agent 路由机制恰好解决了这个问题。
OpenClaw 是什么
OpenClaw 是一个开源的个人 AI 助手框架，核心设计理念是让你在自己的设备上运行 AI Agent，然后通过你平时习惯使用的消息平台来和它交互。它支持的渠道非常全面，包括 [[Telegram]]、[[WhatsApp]]、[[Slack]]、[[Discord]]、Google Chat、[[Signal]]、甚至支持 iMessage，基本上覆盖了主流的即时通讯工具。整个架构的核心是一个本地运行的 WebSocket Gateway，它充当控制面板的角色，负责连接消息渠道、Agent 运行时和各种设备节点。你可以把它理解成一个本地优先的 AI 中控系统，所有的对话数据和配置都保存在你自己的机器上，不需要依赖任何第三方云服务来存储你的聊天记录。
OpenClaw 之所以吸引我，主要是因为它在多 Agent 支持上做得特别干净。传统的做法是跑多个独立的 bot 实例，但 OpenClaw 采用的是「一个 Gateway，多个 Agent」的模式——你只需要维护一个服务进程，通过配置文件就能定义多个完全隔离的 Agent，每个 Agent 有自己独立的工作空间、会话历史、身份设定和工具权限。消息进来之后，Gateway 会根据路由规则自动把它分发给对应的 Agent 处理。这种设计在资源利用和运维复杂度上都比跑多个独立实例要好得多，尤其是当你想在一台 VPS 或者 NAS 上同时跑好几个 Agent 的时候。
为什么需要多 Agent
在实际使用中，我发现单一 Agent 最大的痛点在于「什么都能干，但什么都干不精」。举个具体的例子，当我让一个通用 Agent 帮我写 Python 代码的时候，它的上下文里可能还残留着昨天帮我查的投资资料，或者前天跑的一个自动化脚本的日志，这些无关的上下文不仅浪费了宝贵的 token 窗口，还可能在某些情况下干扰模型的输出质量。更关键的是工具权限问题——一个负责写代码的 Agent 需要文件读写和命令执行的权限，但如果这个 Agent 同时也暴露在一个多人群组里回答问题，那安全隐患就不小了。你总不希望群里有人随便发一条消息就能触发你服务器上的命令执行吧。
多 Agent 的方案本质上是一种「关注点分离」的策略，和软件工程里的单一职责原则一脉相承。每个 Agent 只关注自己擅长的领域，拥有恰好够用的工具和权限，维护独立的上下文和记忆。这样不仅能提升各自的响应质量，也让整个系统的安全边界更加清晰。在 OpenClaw 的体系下，一个 Agent 本质上就是一个完全隔离的 AI 大脑，拥有独立的工作目录、认证配置、会话存储和模型设置。你甚至可以给不同的 Agent 配置不同的 LLM 模型——比如编程 Agent 用 Claude Opus 这种强推理模型，而日常聊天的 Agent 用 Claude Sonnet 或者 GPT-4o 这种更快更便宜的选择。
基础配置：从零搭建多 Agent 环境
OpenClaw 的安装非常简单，需要 Node.js 22 或以上版本，一行命令就搞定。
npm install -g openclaw@latest
openclaw onboard --install-daemon
onboard 命令会引导你完成初始化配置，包括选择 AI 模型提供商和绑定第一个消息渠道。--install-daemon 参数会安装一个守护进程，确保 Gateway 在后台持续运行。安装完成后，所有配置都存放在 ~/.openclaw/openclaw.json 这个文件里，它采用的是 JSON5 格式，支持注释和尾逗号，手动编辑起来比标准 JSON 舒服很多。
一个最基本的多 Agent 配置大概长这样：
{
agents: {
// 所有 Agent 共享的默认配置
defaults: {
workspace: "~/.openclaw/workspace",
model: {
primary: "anthropic/claude-sonnet-4-5"
}
},
// Agent 列表
list: [
{
id: "main",
default: true,
identity: {
name: "Samantha",
emoji: "🐙"
}
},
{
id: "coder",
workspace: "~/.openclaw/workspace-coder",
model: {
primary: "anthropic/claude-opus-4-5"
},
identity: {
name: "Linus",
emoji: "💻"
}
},
{
id: "researcher",
workspace: "~/.openclaw/workspace-researcher",
model: {
primary: "anthropic/claude-sonnet-4-5"
},
identity: {
name: "Finch",
emoji: "🔍"
}
}
]
}
}
这里定义了三个 Agent：main 作为默认的通用助手，coder 专门负责编程任务并使用更强的推理模型，researcher 则专注于资料调研。每个 Agent 都有自己独立的工作空间目录，这意味着它们的文件、笔记、上下文记录都是完全隔离的。在实际运行中，每个 Agent 的认证信息存放在 ~/.openclaw/agents/<agentId>/agent/auth-profiles.json，会话记录则在 ~/.openclaw/agents/<agentId>/sessions 目录下，互相不会干扰。
路由绑定：让消息自动找到对的 Agent
配置好 Agent 之后，接下来就是告诉 Gateway 如何把收到的消息分发给正确的 Agent。OpenClaw 使用一套基于优先级的绑定系统来做路由决策，这个设计思路和 Nginx 的 location 匹配有点像——按照从具体到宽泛的顺序逐级匹配，第一个命中的规则生效。
匹配优先级从高到低是这样的：首先检查是否匹配到了特定的 peer（也就是某个具体的私聊或群组 ID），然后看是否匹配到了 Guild ID（Discord 服务器级别），接着是 Team ID（Slack 工作区级别），再然后是 Account ID（同一渠道的不同账号），再往下是 Channel 级别的匹配，最后如果都没命中就走默认 Agent。
一个典型的绑定配置是这样的：
{
bindings: [
{
// 工作相关的 WhatsApp 群组交给 coder
agentId: "coder",
match: {
channel: "whatsapp",
peer: { kind: "group", id: "[email protected]" }
}
},
{
// Telegram 上的调研频道交给 researcher
agentId: "researcher",
match: {
channel: "telegram",
peer: { kind: "group", id: "-100xxx" }
}
},
{
// Slack 工作区的所有消息交给 coder
agentId: "coder",
match: {
channel: "slack",
teamId: "T0xxx"
}
}
]
}
这样配置之后，当我在特定的 WhatsApp 编程群里发消息时，响应的就是 coder 这个 Agent，它用的是更强的 Claude Opus 模型，拥有代码执行权限。而当我在 Telegram 的调研频道里提问时，researcher Agent 会接手，它配备了网页搜索和内容抓取工具。所有不在绑定规则里的消息，都会默认交给 main Agent 处理。你也可以随时在任何渠道里通过 /agent coder 这样的命令手动切换当前会话使用的 Agent，非常灵活。
用 SOUL.md 塑造 Agent 的灵魂
OpenClaw 有一个非常优雅的设计——通过工作空间里的 Markdown 文件来定义 Agent 的行为和人格。每个 Agent 的工作空间里可以放置几个特殊的文件，它们会被自动注入到系统提示词中，相当于给 Agent 植入了长期记忆和行为准则。
几个关键文件的作用分别是：SOUL.md 定义 Agent 的深层行为特质和目标，这是它的「灵魂」所在，决定了 Agent 在面对各种情况时的基本行为倾向。IDENTITY.md 用来描述核心身份和关系动态，比如你可以在这里告诉 Agent 它是你的编程搭档，语气应该直接高效，不需要过多寒暄。USER.md 记录了用户的偏好和沟通风格，Agent 可以通过这个文件了解到你喜欢用中文交流、偏好简洁的回答、以及你常用的技术栈是什么。还有一个 HEARTBEAT.md 用于配置定期执行的例行任务，比如每天早上检查一下 GitHub 通知或者汇总一下昨天的新闻。
以编程 Agent 为例，它的 SOUL.md 可能是这样的：
# Who I Am
I'm Linus — a senior developer agent focused on writing clean, efficient code.
## Personality
- Direct and technical, skip the pleasantries
- Always explain the "why" behind code decisions
- Prefer simple solutions over clever ones
- When unsure, say so rather than guessing
## Rules
- Always run tests before claiming code is ready
- Use the project's existing patterns and conventions
- Never commit directly, always show diffs first
这种通过 Markdown 文件来做 prompt engineering 的方式，比起在一个巨大的 JSON 配置里写 system prompt 要直观得多。你可以用任何文本编辑器甚至 Obsidian 来管理这些文件，版本控制也很方便。而且因为每个 Agent 的工作空间是独立的，你不用担心一个 Agent 的人格设定会影响到另一个。
进阶玩法：Hub-and-Spoke 架构
如果你想把多 Agent 系统玩得更高级一些，可以参考 TheSethRose/OpenClaw-Advanced-Config 这个项目提供的 Hub-and-Spoke（中枢辐射）架构。这个架构的核心思路是设置一个「指挥官」Agent 作为中枢，它负责接收用户的所有消息，理解意图之后把具体任务分发给专门的子 Agent 去执行。
在这个参考实现中，一共定义了四个 Agent。Seth 是指挥官，也是唯一直接面对用户的 Agent，它运行在宿主机上拥有完整权限，负责做推理和任务分配决策。Linus 是高级开发者，专门处理编程任务，跑在 Docker 沙箱里。Finch 是首席调研员，负责信息收集和网页搜索，同样在沙箱中运行。Otto 是自动化工程师，负责定时任务和自动化脚本的执行。
这种架构最精妙的地方在于安全隔离的设计。指挥官 Agent 通过 sessions_spawn 工具来创建子 Agent 会话，但子 Agent 本身没有任何记忆，也不持有用户上下文——指挥官必须在任务提示词中明确传递所有必要信息。这意味着即使子 Agent 被某种方式攻破，它也无法访问到你的完整对话历史或其他敏感信息。子 Agent 的工具权限也被严格限制，比如调研 Agent 只有 read、write、web_search、web_fetch 这几个工具，而自动化 Agent 则有 cron、exec 权限但没有浏览器访问能力。
要启用子 Agent 委派，需要在指挥官的配置里明确声明允许的子 Agent 列表：
{
id: "seth",
subagents: {
allowAgents: ["linus", "finch", "otto"]
}
}
没有这个配置的话，spawn 请求会被直接拒绝，这是一个很好的安全默认值。整个系统还集成了 LanceDB 向量数据库作为指挥官的记忆插件，让它能够在长期对话中保持上下文连贯性，不会因为和不同子 Agent 的交互而丢失主线信息。
工具和沙箱的权限控制
在配置多 Agent 的时候，工具权限管理是非常关键的一环。OpenClaw 提供了细粒度的工具白名单和黑名单机制，可以在每个 Agent 级别单独设置。比如你希望家人用的那个 Agent 只能回答问题、不能在你服务器上执行任何操作，就可以这样配：
{
id: "family",
sandbox: {
mode: "all",
scope: "agent"
},
tools: {
allow: ["read"],
deny: ["exec", "write"]
}
}
这里的 sandbox.mode: "all" 表示该 Agent 的所有会话都在 Docker 沙箱中运行，tools.deny 则明确禁止了命令执行和文件写入。OpenClaw 的权限模型遵循一个简单但重要的原则——deny 在任何层级都优先于 allow。也就是说，即使你在默认配置里允许了 exec 工具，只要在特定 Agent 的配置里 deny 了它，那这个 Agent 就一定没有执行命令的权限，不存在绕过的可能。
实际操作中我的建议是遵循最小权限原则，一开始给每个 Agent 最少的工具，在使用过程中按需添加。特别是涉及到群组场景的 Agent，一定要慎重考虑它能接触到的工具范围，因为群里任何人发送的消息都可能触发 Agent 的响应。
实践中遇到的问题和建议
在实际配置的过程中，我踩过一些坑，这里分享几点经验。首先是 Agent 的模型选择问题。理论上你可以给每个 Agent 配一个不同的模型，但在实际使用中需要考虑成本和延迟的平衡。我目前的做法是只给编程 Agent 用 Opus 级别的模型，其他 Agent 都用 Sonnet 级别，这样既保证了最关键的任务质量，又不会每个月的 API 账单太难看。OpenClaw 还支持模型 fallback 配置，当主模型因为限速或者宕机无法响应时会自动切到备用模型，这在生产环境中非常实用。
其次是工作空间的管理。每个 Agent 都有独立的工作空间，时间长了文件会越积越多。建议定期检查各个 Agent 的 workspace 目录，清理不再需要的临时文件和过期的会话缓存。OpenClaw 提供了 contextPruning 配置来自动管理上下文窗口的大小，建议把 mode 设为 cache-ttl，让系统自动清理过期的对话上下文。
还有一个容易忽略的点是 openclaw doctor 这个命令。每次修改完配置文件之后一定要跑一下，它会验证 API key 是否有效、渠道配置是否正确、文件权限是否合适，还能自动修复一些常见问题。尤其是从单 Agent 迁移到多 Agent 配置的时候，它会帮你把旧的配置格式自动迁移到新的 agents.defaults 和 agents.list 结构。
最后关于部署方式的选择，如果你只是在本地跑实验，直接 openclaw gateway start 就够了。但如果想让 Agent 一直在线响应消息，建议在 VPS 或者 NAS 上部署，用 --install-daemon 安装守护进程，或者用 Docker Compose 来管理。
最后
用 OpenClaw 搭建多 Agent 系统这一圈折腾下来，我最大的感受是 AI 助手的未来一定不是一个万能的「超级大脑」，而是一组各有专长、分工协作的 Agent 团队。就像一个公司不会让同一个人同时负责编程、市场调研和行政事务，AI Agent 也应该按照职能来拆分，每个 Agent 只专注自己最擅长的事情。OpenClaw 在这个方向上的设计——独立工作空间、灵活的路由绑定、细粒度的权限控制、通过 Markdown 文件来定义人格——都非常符合工程直觉，配置起来也不复杂。
当然目前这个项目还在快速迭代中，某些功能的文档可能跟不上代码的更新速度，社区的生态也在慢慢成长。但整体来说，如果你像我一样对「在自己的设备上运行可控的 AI 助手」这件事感兴趣，OpenClaw 绝对值得一试。从一个简单的双 Agent 配置开始，一个负责日常闲聊、一个负责编程，感受一下消息路由和工作空间隔离带来的清爽体验，你可能就回不去单 Agent 的时代了。
