我是怎么把 OpenClaw 配成一套多 Agent 工作流的：从单助手到“本地 AI 小团队”

如果你已经在自己的电脑上装好了 OpenClaw，但目前还停留在“能聊天、能回复消息”的阶段，那你大概率已经走到了下一步的门口：怎么把它从一个助手，升级成一套真正能协作的多 Agent 工作流？

这篇文章，我不打算讲空泛概念，而是直接基于一套真实在跑的 OpenClaw 配置，拆解我是怎么把它搭成一个“小团队”的。

这套工作流里，一共有 4 个 agent：

• main：总协调 / 主入口
• Robin：开发工程师
• Pierre：测试与审查工程师
• Pannie：创意与总结负责人

它们不是“一个模型扮演四种人格”，而是四个相对独立的运行单元：有自己的目录、有自己的会话、有自己的模型偏好，也有自己的任务边界。整个系统跑起来之后，工作方式会很像一个小型协作团队：有人接任务、有人做实现、有人做质量把关、有人做总结交付。

如果你也想在自己电脑上把 OpenClaw 配到接近这种状态，这篇文章可以直接拿来参考。

一、OpenClaw 在这套工作流里，到底扮演什么角色？

很多人刚装好 OpenClaw 的时候，会把它理解成“一个统一接消息的 AI 外壳”。

这个理解不算错，但如果你开始认真做多 agent 配置，就会发现 OpenClaw 真正有价值的地方，其实不只是聊天，而是它能成为一个本地的 AI 协作运行时。

在我这套工作流里，OpenClaw 主要承担了下面几层角色。

1. 它是统一消息入口

无论是 Telegram 还是 WebChat，用户最终看到的，都是一个可对话的入口。

但在 OpenClaw 内部，不同消息其实可以被路由到不同 agent 的会话里。也就是说，表面上你是在“和某个机器人说话”，实际上是 OpenClaw 在背后帮你完成：

• 消息接入
• 会话归属
• agent 路由
• 状态维持

这一步是所有多 agent 工作流成立的前提。

2. 它是多 agent 的会话和状态管理器

每个 agent 都有自己独立的：

• agent/ 配置目录
• sessions/ 会话记录
• workspace/ 工作区

这意味着它们不是在同一个大脑里“临时换角色”，而是有自己的工作记忆和工作边界。

这点非常重要。

如果没有独立会话和独立工作区，多 agent 很容易最后退化成一句话：

只是同一个 AI 在不同窗口里聊天而已。

而 OpenClaw 的这套结构，至少让它有机会变成真正的“协作系统”。

3. 它是任务编排器

一旦 agent 不止一个，工作流就会自然变成多阶段：

• 接收需求
• 分发任务
• 产出中间结果
• 做审查
• 做总结
• 最终交付
• 巡检系统状态

OpenClaw 的价值就在于：它不只让 agent 存在，还让这些 agent 之间的任务流转有地方落地。

4. 它是文件驱动的本地工作系统

在当前这套实际工作流里，很多结果不是停留在聊天框里的，而是直接落在各自 workspace 里。

比如：

• Robin 的工作区里有真实项目目录 tourism-app/
• Pierre 的工作区里有正式审查报告 reviews/tourism-app-review-2026-03-18.md
• Pannie 的工作区里有总结文档 travel-app-summary-report.md

这一点特别关键。

因为对多 agent 来说，对话只是过程，文件才是交付物。

5. 它还能承担“半主动系统”的角色

当前这套工作流里，我还配置了一个实际在跑的 cron 巡检任务。它会定时检查：

• 各 agent 是否可响应
• 系统状态是否正常
• Gateway 是否在线
• 有没有明显异常

这意味着 OpenClaw 不只是“等你来找它”，还可以在一定程度上自己守着这套系统。

所以如果你问我一句最简洁的话：

在这套工作流里，OpenClaw 不是一个 bot，而是一个本地 AI 团队的运行框架。

二、为什么要拆成 main / Robin / Pierre / Pannie 这四个 agent？

多 agent 配置最容易犯的错误，就是把每个 agent 都做成“全能选手”。

那样看起来很灵活，实际上很快就会变成：

• 谁都能干
• 谁都不够专
• 谁都在抢上下文
• 谁都可能越界

所以我更倾向于用一种更朴素、也更稳定的方式：按工作角色来拆。

这也是当前这套工作流采用的思路。

1. main：总协调 / 主入口 / 调度者

main 的角色不是“最专业的人”，而是“最知道全局的人”。

它负责的事情主要包括：

• 接收用户任务
• 判断任务属于哪一类
• 把任务分给合适的 agent
• 收集各阶段结果
• 对外统一交付
• 承担巡检与总控工作

它更像项目经理 + 总控台，而不是具体执行者。

如果你只有一个最主要的对话入口，那这个入口最适合给 main。

2. Robin：开发工程师

Robin 的定位很明确，就是开发执行位。

在当前实际工作区里，Robin 已经承担过真实项目开发，workspace 里存在一个项目目录：

• tourism-app/

也就是说，它不是概念上的“程序员 agent”，而是真的负责把需求变成代码的人。

适合交给 Robin 的任务包括：

• 做页面
• 写功能
• 搭 demo
• 处理技术实现
• 完成工程化落地

如果你希望多 agent 真正带来生产力提升，那开发 agent 往往是第一个值得配置的角色。

3. Pierre：测试与审查工程师

Pierre 的定位是质量关口。

它负责：

• 代码审查
• 功能完整性检查
• 问题清单整理
• 风险提示
• 结构化 review 报告

当前实际工作区里，Pierre 已经产出过一份完整审查报告：

• reviews/tourism-app-review-2026-03-18.md

而且不是一句“代码不错”，而是从架构、Vue 最佳实践、UI、功能、性能、问题优先级多个维度做系统性审查。

这说明测试 agent 的价值不是“再找一个人看看”，而是给多 agent 工作流补上质量环节。

4. Pannie：创意与总结负责人

Pannie 的定位是创意和表达。

它负责：

• 项目总结
• 报告撰写
• 文档整理
• 对外表达
• 文章与论坛发布稿

当前实际记录里，Pannie 已经输出过项目总结文档，也就是典型的“把过程变成能交付的内容”。

很多技术型工作流最大的问题，不是做不出来，而是做完以后没人把结果讲清楚。

Pannie 的价值就在这儿：

它让“完成任务”变成“完成交付”。

三、这套工作流是怎么串起来的？

角色分清楚以后，下一步要解决的是：它们到底怎么协作？

我更倾向于把这套工作流理解成一个流水线，而不是四个 agent 同时胡乱开工。

当前比较自然的一条链路是这样的：

第一步：main 接住任务

用户一般先找 main。

因为对用户来说，最自然的方式是：

• 不用先判断谁该干什么
• 直接把需求说出来
• 由系统内部去做分派

所以 main 是最合适的默认入口。

第二步：main 判断任务类型并分发

比如一个“做个旅游首页 Demo”的任务，main 会判断这更适合走开发链，而不是直接让文档 agent 开始写总结。

于是顺序就会变成：

• main 识别需求
• 把开发工作交给 Robin

这一步的核心不是“转发消息”，而是裁剪任务。

给每个 agent 的任务说明，最好都是按它的角色压缩过的，而不是原始需求全文照抄给四个人。

第三步：Robin 产出代码或项目目录

开发阶段由 Robin 执行。

当前真实工作区里，Robin 已经留下了项目目录 tourism-app/，这说明开发结果是有文件落地的。

这一点很重要。

如果没有工作区里的真实产物，多 agent 很容易变成“聊得很热闹，结果什么都没留下”。

第四步：Pierre 做审查和质量把关

项目初步完成后，Pierre 接手做 review。

当前已经有一份实际报告显示，它会检查：

• 交互是否真的实现
• 分类切换是不是有效
• 样式是否响应式
• store 职责是否合理
• 有没有残留脚手架内容
• 是否缺 loading / empty / error 状态

这一步让工作流不只是“能跑”，而是开始往“能交付”推进。

第五步：Pannie 做总结、包装和对外表达

当代码和审查结果都有了，Pannie 就可以接手做：

• 总结报告
• 说明文档
• 面向论坛的文章
• 项目复盘稿

这也是为什么我觉得创意/总结型 agent 很值得有。

技术链路如果没有人负责包装，最后很容易卡在：

• 做完了
• 但不好发
• 不好汇报
• 不好沉淀

第六步：main 汇总并完成最终交付

最后仍然回到 main。

由 main 来统一对用户回复，体验会更像你在和一个“团队入口”打交道，而不是自己管理四个 bot。

第七步：cron 定时巡检系统运行状态

除了任务链，当前工作流还有一个后台链：巡检。

现在已经存在一个每 4 小时执行一次的巡检任务，用来检查：

• agent 连接状态
• 会话活跃情况
• Gateway 状态
• 系统资源与异常

这让整个系统从“对话工具”进一步变成“持续运行的工作系统”。

四、目录结构怎么设计，才适合长期跑？

如果你也要自己搭，我建议别一开始就纠结特别复杂的架构，先把边界搭清楚。

一个比较实用的目录结构可以像这样：

.openclaw/
└─ agents/
   ├─ main/
   │  ├─ agent/
   │  ├─ sessions/
   │  └─ workspace/
   ├─ robin/
   │  ├─ agent/
   │  ├─ sessions/
   │  └─ workspace/
   │     ├─ projects/
   │     ├─ docs/
   │     └─ memory/
   ├─ pierre/
   │  ├─ agent/
   │  ├─ sessions/
   │  └─ workspace/
   │     ├─ reviews/
   │     ├─ checklists/
   │     └─ memory/
   └─ pannie/
      ├─ agent/
      ├─ sessions/
      └─ workspace/
         ├─ docs/
         ├─ reports/
         └─ memory/

当前实际工作流里，各 agent 目录本身就已经有类似结构：

• agent/：放模型和认证相关配置
• sessions/：放会话记录
• workspace/：放长期工作资产

我对目录设计的建议

main

建议放：

• 总控文档
• 运行说明
• 巡检输出
• SOP
• 团队协作规范

Robin

建议放：

• 项目目录
• demo
• 技术草稿
• 实现文件

Pierre

建议放：

• review 报告
• 测试 checklist
• 质量基线文档
• 风险清单

Pannie

建议放：

• 总结报告
• 论坛文章
• 对外文稿
• 项目说明文档

一条很现实的建议

不要一上来就给每个 agent 建十几个文件夹。

真正有用的是：

• Robin 有项目目录
• Pierre 有 review 目录
• Pannie 有 docs / reports 目录
• main 有 ops / docs 目录

先能用，再慢慢长结构。

五、agent 配置应该怎么想？

多 agent 配置的关键，不是数量，而是边界。

我建议每个 agent 至少配置清楚 4 件事：

1. 名字

名字最好直观、好记、好在聊天里引用。

像当前这套：

• main
• Robin
• Pierre
• Pannie

就明显比 agent1 / agent2 / agent3 更适合长期使用。

2. 身份

每个 agent 要有清晰身份：

• 开发工程师
• 测试工程师
• 创意负责人
• 总协调

身份越稳定，行为越稳定。

3. 任务边界

你要明确告诉每个 agent：

• 该做什么
• 不该做什么
• 它默认产出的是什么

比如：

• Robin 的默认产物是代码和项目目录
• Pierre 的默认产物是 review 报告
• Pannie 的默认产物是文档、总结、文章
• main 的默认产物是调度、汇总、状态反馈

这比写一堆花哨提示词更有用。

4. 工作区

每个 agent 最好有自己的 workspace，而不是大家共用一个目录。

因为一旦长期运行，共用工作区很容易带来：

• 文件混乱
• 记忆串台
• 输出边界模糊

多 agent 的价值之一，就是把上下文分仓。

六、为什么不同 agent 适合不同模型？

这一点很多人第一次做多 agent 时会忽略。

但从当前这套实际运行状态来看，不同角色确实适合不同模型策略。

目前实际环境里出现过这些模型使用情况：

• main 使用过 gpt-5.4
• 巡检 cron 使用过 deepseek-chat
• Pierre 使用过 claude-opus-4-6
• Pannie 使用过 claude-sonnet-4-6
• Robin 也运行在偏综合/执行型模型体系下

这恰好说明：

多 agent 的分工，不只是任务分工，也包括模型分工。

1. main：优先综合能力与稳定性

main 最重要的是：

• 理解复杂任务
• 能调度工具
• 能维持长会话
• 能稳定做总控

所以它更适合用一个整体能力比较均衡的模型。

2. Robin：更看重代码执行与工程落地

开发 agent 更关心：

• 代码理解
• 文件组织
• 技术实现
• 工程性表达

因此 Robin 应该优先选对代码友好的模型，而不是单纯文笔好的模型。

3. Pierre：更看重分析能力与长文审查能力

测试 / 审查型 agent 需要：

• 阅读大量上下文
• 找问题
• 做结构化判断
• 输出有条理的 review

所以 Pierre 更适合分析能力更强的模型。

但现实问题是：高能力模型不一定高可用。

当前真实运行里，Pierre 就遇到过 claude-opus-4-6 负载上限错误。这一点非常值得诚实说出来。

如果你照搬配置，最好不要只给审查 agent 配一个高端模型，而不给 fallback。

4. Pannie：更看重长文组织和表达自然度

Pannie 这种创意 / 总结型 agent，更在意的是：

• 长文稳定性
• 结构能力
• 语言自然度
• 面向读者的表达能力

它不一定非要最强模型，但一定要是一个写长文不容易散架的模型。

5. 巡检 cron：优先低成本、稳定、够用

巡检任务最不需要用贵模型。

因为它做的是：

• 检查状态
• 汇总异常
• 输出短摘要

这种任务更适合：

• 成本低
• 响应稳定
• 允许高频执行

当前实际工作流里，用 deepseek-chat 跑巡检，就是一个很现实、也很合理的思路。

一条我很推荐的模型配置原则

你可以直接照这个思路走：

• main：综合主力模型
• Robin：代码友好模型
• Pierre：分析/审查模型 + 备胎
• Pannie：长文/表达模型
• cron：便宜稳定模型

不要执着于“全员同款”。

七、为什么要配 cron / 巡检？

如果你只用单 agent，可能很久都意识不到巡检的重要性。

但一旦变成多 agent，问题就会变多：

• 某个 agent 不回了
• 某个模型限流了
• Telegram 通道偶发异常
• Gateway 状态不对
• 会话太长开始变钝

这时候如果没有巡检，你只能靠“出问题以后再发现”。

当前这套工作流里的巡检做了什么？

现在已经有一个每 4 小时执行一次的 cron，主要检查：

• 各 agent 最近是否正常活跃
• 系统健康状态
• Gateway 状态
• 异常信息摘要

这其实已经足够实用了。

我建议你怎么配第一版巡检？

如果你准备自己搭，不要一开始就搞复杂：

• 每 4 小时做一次轻巡检
• 只输出 2 到 4 句摘要
• 有异常才提醒
• 无异常就保持安静

heartbeat 和 cron 怎么分工？

当前实际状态里：

• main heartbeat 开启
• Robin / Pierre / Pannie heartbeat 关闭

这套思路我觉得挺合理：

• main 负责主动留意系统状态
• 专业 agent 按需唤起，不主动刷屏

对于个人用户来说，这样更不吵，也更像一个有分工的系统。

八、Telegram + 多 agent 协作，实际怎么用才不乱？

这一部分非常关键。

因为很多人不是不会配 agent，而是配完以后发现：

• 入口太多
• 不知道该找谁
• 信息来回复制
• 用起来比单 agent 还乱

我的建议是：

1. 永远保留一个“主入口”

也就是 main。

日常大部分任务都先找它。

这样你只需要记住一个入口，而不是每次都思考：

• 这次该找谁？
• 先找开发还是先找总结？
• 要不要同时找三个？

2. 专业 agent 保留“直连通道”

保留直聊不是没用，反而很实用。

比如：

• 想让 Robin 直接做页面 → 直接找 Robin
• 想让 Pierre 单独审一版代码 → 直接找 Pierre
• 想让 Pannie 单独整理成论坛文章 → 直接找 Pannie

所以更好的理解是：

• main 是默认入口
• 其他 agent 是专业通道

3. 不要把同一段超长上下文反复发给所有 agent

这是多 agent 使用中的常见低效操作。

如果你把一整段巨长需求分别发给 4 个 agent：

• token 消耗高
• 理解不一定更准
• 最后各自输出还可能互相打架

更好的做法是：

• 先让 main 做任务拆分
• 再给每个 agent 发裁剪后的子任务
• 尽量用文件而不是长对话做交接

4. 用文件交接，比用聊天交接更稳

多 agent 真的想长期跑，最稳的协作中介永远还是文件。

比如：

• Robin 产出项目目录
• Pierre 读取项目并产出 review
• Pannie 读取项目背景 + review，产出总结文档
• main 汇总最终交付

这比纯聊天接力稳定得多，也更方便复盘。

九、常见问题、排错与现实坑点

我很想把这一节写得诚实一点。因为多 agent 工作流最怕的不是“不高级”，而是“看起来高级，实际上并不稳”。

1. 某个 agent 不回消息了，不一定是配置错了

当前实际运行里，已经出现过：

• Pierre 遇到高阶模型负载上限
• 某些会话出现可用性波动
• 记忆检索出现 embedding quota 问题

这说明：

• agent 不回消息，不一定是 agent 本身坏了
• 很多时候是模型层出了问题

所以排查顺序应该是：

1. 模型是否限流 / 出错
2. 会话是否还正常
3. Gateway 是否在线
4. 通道是否异常
5. 再去看 agent 配置

2. Telegram 能用，但偶尔不稳，是正常会发生的

历史记录里实际就出现过 Telegram 网络请求失败。

这类问题通常先查：

• token 是否正确
• Gateway 是否正常
• 网络是否波动
• 最近是否有发送失败 / fetch 错误

3. 高端模型并不等于更适合长期跑

这是当前工作流里一个很真实的教训。

高能力模型当然好，但如果：

• 容易限流
• 高峰期经常不可用
• 成本高
• 稳定性差

那它未必适合作为关键链路唯一选择。

建议： 关键 agent 一定要有 fallback。

4. 会话越跑越长，系统会越来越钝

这是长期使用一定会遇到的问题。

比较实用的处理方式是：

• 用文件沉淀阶段结果
• 用 main 做摘要压缩
• 专业 agent 的长会话必要时重置
• 不要把每轮所有细节都靠聊天历史硬扛

5. 多 agent 工作区会越来越乱

解决办法不复杂，但一定要尽早做：

• 项目归项目
• review 归 review
• 文档归文档
• memory 归 memory

如果目录失控，三天后你自己都不想翻这套系统。

十、安全边界：哪些建议做，哪些不建议急着做？

多 agent 一旦跑顺，很容易让人产生一种冲动：

既然都能协作了，不如再给它们更多权限，让它们自己去外面做事。

我的建议是：先别急。

1. 不要一开始就给所有 agent 外发权限

例如：

• 自动发消息
• 自动发邮件
• 自动发布内容
• 自动操作外部账号

这些当然可以做，但不应该是第一步。

更稳妥的做法是：

• 先让 agent 在本地工作区内工作
• 对外动作尽量由 main 统一确认
• 公开发布保持人工确认

2. 不要默认所有 agent 都能读取全部私密信息

多 agent 有记忆系统是好事，但不意味着每个 agent 都应该知道同样多。

更安全的做法是：

• 专业 agent 只知道完成任务所需的信息
• 总控层掌握更多全局信息
• 私密长期记忆不要默认全员共享

3. 不要默认所有 agent 都有相同权限

开发 agent 需要更强文件操作能力，不代表文档 agent 也必须同等开放。

按角色开权限，才是长期可维护的方案。

4. 不建议把个人型工作流直接拿去做多人共享系统

当前实际状态里，也出现过关于潜在多用户共享风险的提醒。

这说明如果未来你让多个不完全互信的人共用同一套 gateway、同一组 agent、同一套本地权限，复杂度和风险会一下子上来。

更稳妥的方式是：

• 按用户拆分
• 按信任边界拆分
• 甚至按系统环境拆分

别把个人工作流直接硬扩成多人平台。

十一、哪些地方其实不适合照搬？

这一节我觉得必须单独说。

因为当前这套工作流虽然已经能用，但它绝不是“拿来即完美”的模板。

1. 模型可用性并不稳定

这是最明显的一点。

现实里已经出现过：

• 高阶模型负载上限
• 某些 agent 响应失败
• 记忆检索额度问题

所以千万不要照搬成“关键角色只绑一个昂贵模型”。

2. 服务化程度还不够完整

当前实际系统状态里，Gateway service / Node service 并没有完全做成成熟守护服务形态。

这在实验阶段无所谓，但如果你要长期在线、低干预运行，就不够稳。

3. main 的总控资产还需要更集中

从现在的结构看，专业 agent 的工作区产物比较清晰，但 main 更适合进一步补一个明确的总控 workspace，用来沉淀：

• 巡检结果
• 总控 SOP
• 任务流说明
• 协作规范

4. 当前编排更像“半自动团队”，不是全自动流水线

这一点反而是优点，但也容易被误解。

这套工作流真正可用的原因，恰恰是它没有过度追求“完全自动”。

很多时候还是：

• main 做判断
• 文件做交接
• 专业 agent 各司其职

这比强行把所有东西固化成自动编排，现实得多，也稳得多。

十二、如果你也想从零搭起来，我建议按这个顺序做

这是我觉得最实用的一节。

如果你已经装好了 OpenClaw，别一开始就想着四个 agent 一起起飞。最稳妥的顺序应该是这样的。

第 1 步：先把单 agent 跑稳

至少确认这些没问题：

• OpenClaw 正常启动
• Telegram / WebChat 能正常通信
• workspace 可以正常读写文件
• 会话能正常保存
• openclaw status 能看见系统状态

第 2 步：先建立 main

把 main 配成默认入口。

先让它做到：

• 能接任务
• 能读写文件
• 能看状态
• 能承担总协调角色

第 3 步：先增加一个开发 agent（Robin）

因为开发 agent 最容易让你感受到“多一个角色真的有用”。

先跑通一条最小协作链：

• 你找 main
• main 把任务交给 Robin
• Robin 在 workspace 里产出代码或项目
• main 回来给你结果

第 4 步：再加测试 / 审查 agent（Pierre）

当开发链跑通后，再补质量环节。

让工作流升级成：

• main 接任务
• Robin 实现
• Pierre 审查
• main 汇总

第 5 步：最后加总结 / 内容型 agent（Pannie）

这一步会明显提升“可交付感”。

因为它开始帮你把完成的事情变成：

• 报告
• 文档
• 帖子
• 项目总结

第 6 步：最后再加巡检

等工作流稳定以后，再配 cron。

我建议先从最轻版开始：

• 每 4 小时巡检一次
• 只输出摘要
• 有异常再提醒

第 7 步：慢慢补目录规范和 SOP

等你真的开始长期使用后，再逐步固化：

• review 模板
• 总结模板
• 项目目录规范
• 巡检规则
• 常见问题 SOP

不要反过来：先搞一堆制度，结果系统根本没跑起来。

结尾：先把 OpenClaw 配成一个团队，再考虑把它配成平台

如果你问我，当前这套多 agent 工作流最值得参考的地方是什么，我会说，不是它“复杂”，而是它已经具备了一个团队最关键的几个环节：

• 有总入口
• 有专业分工
• 有文件交接
• 有质量关口
• 有总结与交付
• 有基本巡检

main + Robin + Pierre + Pannie 这套组合之所以好用，不是因为它听起来高级，而是因为它已经足够像一个真实的小团队。

对于已经装好 OpenClaw、正准备继续往前走的人来说，我的建议很简单：

1. 先有主入口，再谈多入口
2. 先有分工，再谈自动化
3. 先有文件产物，再谈“智能协作”
4. 先有稳定性，再谈最强模型
5. 先跑通一个闭环，再扩更多 agent

你不需要一开始就把 OpenClaw 配成一个复杂平台。

你只需要先把它配成一个你真的愿意每天使用的“小团队”。

当这一点成立以后，多 agent 工作流才算真正开始工作。