1. 从单 Agent 到多 Agent为什么本地部署会卡在协作这一步openclaw 最新版本部署多 agent本质上是把「一个助手干所有活」升级成「一组有分工的助手互相配合」。单 agent 跑起来很爽你问它答任务简单时完全够用。但一旦任务变长——比如先调研、再写稿、最后审校——单个 agent 的上下文会被塞满模型容易前后矛盾而且你没法针对不同环节换更合适的模型。多 agent 协作解决的正是这个问题manager 负责拆解任务和调度writer 负责产出内容main 负责对外接待和兜底每个角色独立工作区、独立模型、独立消息渠道。这套方案适合谁适合已经在本机或内网服务器上跑通过 openclaw 单 agent、想进一步做任务流水线的开发者也适合想把不同国产模型按能力分配到不同环节、控制成本的人。我这次用的环境是 Ubuntu 26.04、Node v22.22.1、8GB 内存网络能正常访问各家模型 API。整套架构是单节点多 Agent所有 agent 跑在同一台机器上通过 OpenClaw Gateway 统一对外消息渠道接飞书用 不同机器人来触发不同角色。需要提前说清楚一个概念openclaw 里的 agent 不是进程级隔离的独立服务而是共享一个 Gateway、各自持有独立 workspace 和 agentDir 的逻辑单元。理解这一点很关键后面配置目录结构、排查「为什么消息发错人」都靠它。下面从创建 agent 开始一步步把 manager、writer 和 main 三个角色搭起来最后放进同一个群聊验证协作。2. TaoToken 前置准备给多 Agent 集群配一个统一模型入口多 agent 部署最容易忽略的前置环节是模型接入。三个 agent 如果各自去配不同厂商的 key、不同 baseUrl配置文件会变得又长又难维护换模型时还要逐个改。更稳的做法是先准备一个统一的模型入口让 openclaw 的 provider 配置指向同一个地址再在 agent 层面用 model 字段区分具体模型。我这边用 TaoToken 作为统一入口它的 API 地址是 https://taotoken.net/api兼容 OpenAI 的 completions 协议openclaw 里api字段填openai-completions就能对接。先去控制台创建 API Key地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmultiagent_console 创建后复制保存后面写进配置或 auth profiles。如果你还没决定用哪些模型可以先到模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmultiagent_chat 试几个确认哪个模型在拆解任务、长文写作上更顺手再决定 manager 和 writer 分别用哪个。这里有个实操建议manager 这种要做任务规划和推理的角色选 reasoning 能力强的模型writer 这种偏内容生成、调用频繁的角色选性价比高的轻量模型。openclaw 的 agents.defaults.models 里可以给每个模型起 alias后面 agent 的 model 字段直接引用模型 id 即可。把 key 和模型选型定下来再进入配置环节能少走很多回头路。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmultiagent_doc 遇到字段对不上时对着查。3. 可复制配置openclaw.json 里定义 Agents、Providers 与飞书渠道这一节是整篇的核心配置写对了多 agent 基本就成了。openclaw 的主配置文件在/root/.openclaw/openclaw.json下面按 agents、models、channels、bindings 四块拆开讲每块都给可直接复制的片段。先看 agents 定义。defaults 里设全局工作区和可用模型别名list 里逐个声明 agent。注意每个 agent 的 workspace 和 agentDir 要独立否则多个 agent 会互相覆盖数据agents: { defaults: { workspace: /root/.openclaw/workspace, models: { deepseek/deepseek-v4-flash: { alias: DeepSeek }, zai/glm-4.5-air: { alias: GLM }, sensenova/sensenova-6.7-flash-lite: { alias: SenseNova } }, model: { primary: deepseek/deepseek-v4-flash } }, list: [ { id: main, model: sensenova/sensenova-6.7-flash-lite }, { id: manager, name: manager, workspace: /root/.openclaw/workspace/manager, agentDir: /root/.openclaw/agents/manager/agent, model: deepseek/deepseek-v4-flash }, { id: writer, name: writer, workspace: /root/.openclaw/workspace/writer, agentDir: /root/.openclaw/agents/writer/agent, model: zai/glm-4.5-air } ] }创建 agent 用命令行更省事流程和 onboard 基本一致工作目录默认以 agent 名称命名# 添加 manager agent openclaw agents add manager # 按提示确认工作目录、选择默认模型、选择消息渠道这里选飞书 # 添加 writer agent openclaw agents add writer # 删除某个 agent openclaw agents delete manager配置好后的目录结构长这样workspace 存运行数据agents 存配置/root/.openclaw/ ├── openclaw.json # 主配置文件 ├── workspace/ # 全局工作区 │ ├── manager/ # manager agent 数据 │ └── writer/ # writer agent 数据 ├── agents/ │ ├── manager/agent/ # manager agent 配置 │ └── writer/agent/ # writer agent 配置再看 models providers。mode 设为 merge 表示在默认 provider 基础上合并自定义项。这里配了三个供应商注意 SenseNova 的 apiKey 直接写在配置文件里DeepSeek 和 ZAI 的 key 放在 auth profiles 中两种方式都行但生产环境建议统一走 auth profiles 便于轮换models: { mode: merge, providers: { deepseek: { baseUrl: https://api.deepseek.com, api: openai-completions, models: [ { id: deepseek-v4-flash, name: DeepSeek V4 Flash, reasoning: true, input: [text], contextWindow: 1000000, maxTokens: 384000, compat: { supportsReasoningEffort: true, supportsUsageInStreaming: true, maxTokensField: max_tokens }, api: openai-completions } ] }, zai: { baseUrl: https://open.bigmodel.cn/api/paas/v4, api: openai-completions, models: [ { id: glm-4.5-air, name: GLM-4.5 Air, reasoning: true, input: [text], contextWindow: 131072, maxTokens: 98304 } ] }, sensenova: { baseUrl: https://token.sensenova.cn/v1, apiKey: sk-你的key, api: openai-completions, models: [ { id: sensenova-6.7-flash-lite, name: SenseNova V6.7 Flash-Lite, reasoning: true, input: [text, image], contextWindow: 128000, maxTokens: 32000 } ] } } }如果你想让所有 agent 都走 TaoToken 统一入口把 provider 的 baseUrl 改成https://taotoken.net/api、apiKey 填 TaoToken 的 key 即可模型 id 按平台文档填。这样换模型只改一处不用动每个 agent。最后是飞书渠道和 bindings。channels.feishu 下每个 account 对应一个机器人bindings 把 accountId 和 agentId 绑起来这是「 谁触发谁」的关键channels: { feishu: { enabled: true, defaultAccount: main, accounts: { main: { appId: cli_你的main_appid, appSecret: 你的main_secret, name: Primary bot }, manager: { appId: cli_你的manager_appid, appSecret: 你的manager_secret, name: Manager bot }, writer: { appId: cli_你的writer_appid, appSecret: 你的writer_secret, name: Writer bot } }, domain: feishu, dmPolicy: allowlist, allowFrom: [ ou_你的用户openid1, ou_你的用户openid2 ], groupPolicy: open, requireMention: true } }, bindings: [ { agentId: main, match: { channel: feishu, accountId: main } }, { agentId: manager, match: { channel: feishu, accountId: manager } }, { agentId: writer, match: { channel: feishu, accountId: writer } } ]dmPolicy 设 allowlist 时只有 allowFrom 里的 openid 能私聊触发群聊 groupPolicy 设 open 并开 requireMention表示群里必须 机器人才响应。这套配置下来三个角色各管各的机器人互不串台。4. 验证请求启动 Gateway 并检查多 Agent 运行状态配置写完别急着上群聊先在本地验证 Gateway 能不能正常拉起、agent 有没有被正确加载。启动命令openclaw gateway start # 或者前台运行看日志 openclaw gateway run --verbose启动后重点看日志里有没有每个 agent 的注册信息正常会打印类似agent registered: main / manager / writer的行。如果某个 agent 没出现多半是 openclaw.json 里 list 的 id 和 bindings 的 agentId 对不上或者 agentDir 路径不存在。接着验证模型连通性。openclaw 一般提供健康检查或直接发一条测试消息# 查看当前加载的 agents openclaw agents list # 查看 gateway 状态 openclaw gateway statusopenclaw agents list应该输出三个 agent 及其绑定的模型。如果只看到一个检查 agents.list 的 JSON 有没有语法错误——openclaw.json 是严格 JSON多一个逗号都会导致整段被忽略这是最常见的坑。然后做一次端到端验证在飞书里私聊 main 机器人发一句「你好」看是否回复再在群里 manager 发「帮我拆解一个选题」writer 发「写一段 200 字的产品介绍」。三个机器人分别响应、内容风格符合各自模型特征就说明 bindings 和渠道都通了。实测下来manager 用 DeepSeek 拆解任务时结构更清晰writer 用 GLM 出稿速度更快分工效果比单 agent 明显。验证阶段还要确认 workspace 隔离生效。分别往 manager 和 writer 的 workspace 目录里看应该有各自独立的会话数据文件没有互相写入。如果发现两个 agent 数据混在一起回去检查 agents.list 里每个 agent 的 workspace 字段是不是写成了同一个路径。5. 本篇常见错排查401、local proxy failed、reading choices 与 OAuth 报错多 agent 部署的报错集中在模型接入和渠道绑定两块下面按真实遇到的顺序列。401 Unauthorized最常见。先确认 provider 的 apiKey 是否正确、有没有多余空格。如果 key 放在 auth profiles 里检查 profile 名称和 agent 引用的模型是否匹配。走 TaoToken 统一入口时确认 baseUrl 是https://taotoken.net/api而不是带路径的地址key 用控制台新建的那把。401 还有一种情况是 key 权限范围不对去控制台确认这把 key 允许调用你配置的模型。local proxy failed这个报错通常出现在 Gateway 转发请求到模型服务时。先看本机能不能直接 curl 通 provider 的 baseUrl排除网络问题再检查 openclaw.json 里 provider 的 baseUrl 有没有写错协议或端口。如果用了本地代理类工具确认它监听正常。注意不要配置任何绕过网络合规要求的工具保持直连即可。reading choices 相关报错一般是模型返回结构不符合预期openclaw 解析choices字段失败。常见原因是 provider 的api字段填错比如把openai-completions写成了别的协议名导致请求体格式和响应解析对不上。对照第 3 节的 provider 片段逐字段核对尤其是api和compat.maxTokensField。OAuth 报错如果某个 provider 走 OAuth 授权token 过期会报授权失败。重新走一遍授权流程或改用 API Key 方式接入。多 agent 场景下每个 agent 可能引用不同 provider建议把每个 provider 的鉴权方式在配置里写清楚避免混用。消息发错 agent不是报错但很常见。检查 bindings 里 match 的 accountId 是否和 channels.accounts 的 key 一致飞书机器人的 appId 有没有填串。三个机器人如果用了同一个 appId消息会全部落到 defaultAccount 上。agent 启动即退出看日志里有没有 workspace 权限问题。8GB 内存的机器跑三个 agent 没问题但如果 workspace 目录属主不对agent 写数据失败会直接退出。用ls -l /root/.openclaw/workspace确认权限。6. 把三个 Agent 放进群聊分工协作的落地方式配置和验证都过了最后一步是把 main、manager、writer 三个机器人拉进同一个飞书群用 分配任务。群聊策略是 open requireMention所以每条指令都要 对应机器人。典型用法是manager 发「拆解这个需求输出任务清单」manager 用 DeepSeek 做规划拿到清单后 writer 发「按清单第二项写初稿」writer 用 GLM 产出需要对外回复或兜底时 main。这套协作模式的价值在于每个环节可以用最合适的模型而且上下文互不污染。manager 的规划过程不会挤占 writer 的写作上下文writer 的长文也不会拖慢 main 的响应。如果你后续要加审校角色照第 3 节再openclaw agents add reviewer配一个独立 workspace 和模型在 bindings 里加一条映射就行扩展成本很低。长期跑编码类或 Agent 类任务的话可以考虑用 Coding Plan 把调用额度固定下来地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmultiagent_codingplan 比按量计费更可控。需要新建或轮换 key 时去 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmultiagent_apikeys 。整套部署到这里就闭环了配置文件可复制、启动脚本可执行、验证步骤可复现剩下的就是按你的业务往角色里填 prompt 和工具。