把 OpenClaw 从“能跑”打磨成“能协同”:一套内容型 AI 团队的多 Agent 落地实践

把 OpenClaw 从“能跑”打磨成“能协同”：一套内容型 AI 团队的多 Agent 落地实践

最近这段时间，我一直在折腾一件事：

怎么把 OpenClaw 真正落地成一个“能干活”的 AI 团队，而不是几个会聊天的 Agent。

这套系统部署在远程 Linux 虚拟机上，接入飞书，跑的是多 Agent 协同。我的目标也很明确，不是做研究演示，而是服务一条真实的内容生产链路：

• 每日 AI 资讯整理

• 热点筛选与成稿

• 根据方向 / idea / 初稿增强成稿

• 日常问题与工作事项处理

一开始，系统看起来已经挺完整：

• 有多 Agent

• 有 workspace

• 有 skills

• 有飞书入口

• 也能跑起来

但越往后用，越发现一个问题：

“能跑”不等于“能协同”，更不等于“能稳定干活”。

真正决定多 Agent 系统上限的，往往不是模型有多强，而是下面这几件事有没有想清楚：

• 主控是不是单一

• 分工是不是清楚

• 任务有没有共享留痕

• worker 回传是不是结构化

• skills 有没有分层治理

经过一周多的反复打磨，终于呈现相对不错的效果。

接下来分享我的实践，后面会分几讲具体阐述如何一步步实现。

这次实践里，我最核心的收获就是一句话：

OpenClaw 多 Agent 的关键，不在于 Agent 多不多，而在于它像不像一个真正的小团队。

一、别一上来就追求“很多 Agent”

很多人做多 Agent 的第一反应是：多加几个角色，分工看起来就更专业。

但真正跑起来后会发现，Agent 一多，如果没有制度，系统只会变成：

• 看起来很热闹

• 实际很混乱

• 谁都能说一点

• 但没有一个人真正负责闭环

对我这种内容型 AI 团队场景，真正合适的并不是很多 Agent，而是少而清晰。

最后沉淀下来的最优结构，其实只有四个：

1）main

唯一正式入口，负责：

• 理解需求

• 判断是直接答，还是派工

• 调度内部 Agent

• 验收结果

• 统一对外表达

• 主动推进任务

2）self-media

内容研究与成稿负责人，负责：

• AI 资讯采集

• 热点筛选

• 公开资料研究

• 成稿增强

• 标题、摘要、标签、封面 brief

3）head-of-operations

平台适配与发布准备负责人，负责：

• 平台台内容适配

• 审核清单

• review notes

• 待人工确认项整理

• 最终草稿包

4）software-development-engineer

工程保障与能力沉淀负责人，负责：

• 路径、文件、shared、自动化链路问题

• 工程性 BLOCKED 的排查与修复

• Skill 的开发、迭代与产品化

这四个角色一旦清楚了，整个系统一下就稳了很多。

二、最关键的不是 Agent 数量，而是“主控是否单一”

最开始很容易走入一种思路：既然有多个 Agent，那是不是都可以直接面对飞书群，谁会谁上？

但真正用下来，这样会带来很多问题：

• 外部口径不统一

• 用户要理解内部结构

• 谁说的算不清楚

• 出问题很难定位

• 排障成本越来越高

所以最后我定下来的原则是：

飞书群只绑定 main，main 是唯一正式入口。

也就是说：

• 用户只和 main 打交道

• 内部怎么拆，用户不需要知道

• worker 只负责把事做好

• main 负责整合、验收、统一发声

这个变化非常关键。因为它让整个系统从“多个角色同时开麦”变成了“一个总控 + 多个执行单元”。

三、协作一定要有“双主线”

很多人做多 Agent，会过度依赖“会话”本身，觉得只要 Agent 之间能互相发消息，就算协作了。

但当任务越来越复杂时，你会发现，只靠聊天记录是远远不够的。

所以我最后把协作抽象成了两条主线：

第一条：session tool，是通讯主线

解决的是：

• 谁给谁派工

• 谁向谁回传

• 当前任务状态怎么流转

• 遇到阻塞怎么反馈

第二条：shared 目录，是共享主线

解决的是：

• 任务目标放哪

• 中间结果放哪

• 最终结果放哪

• 状态怎么留痕

• 后续怎么复用

• 将来怎么工程化

真正正确的闭环应该是：

用户需求 ↓main 判断：直答 or 派工 ↓worker 执行 ↓写 shared 产物 ↓worker 回传 main ↓main 验收 ↓main 对外统一汇报

只有这样，多 Agent 系统才真正开始像一个团队。

四、main 的价值，不是“什么都做”，而是“让任务往前走”

在多 Agent 系统里，main 最容易被误解。

一开始我也很容易让它什么都干一点，结果反而变成：

• 调度不稳

• worker 没有价值

• 任务边界越来越乱

后来我给 main 下了一个特别重要的定义：

main 不是万能执行器，而是秘书型总控。

它真正应该做的，是这几件事：

1）能直接高质量回答的，不派工

比如：

• 简单问答

• 状态查询

• 轻总结

• 轻润色

• 对已有候选项做简要判断

2）需要执行、落盘、协作、平台动作的，直接派工

比如：

• 要生成正式产物

• 要写 shared

• 要多 Agent 协同

• 要做平台适配

• 要工程修复

3）默认主动推进，例外情况才确认

只有在下面几种情况，main 才需要先确认：

• 关键信息缺失

• 动作不可逆或有外部影响

• 涉及费用、额度、敏感资源

除此之外，只要能继续推进，就应该继续推进。

用户真正想要的，不是一个一直问“要不要”的助手，而是一个真正能把事情往前推的系统。

五、worker 的价值，不是“像人”，而是“稳定完成任务”

一开始，我也花了不少精力去塑造 worker 的“人格”，写很多 IDENTITY、SOUL、风格描述。

但真正影响执行效果的，并不是“它像不像一个角色”，而是：

• 职责清不清楚

• 工具该怎么用

• 完成后怎么回传

所以后来我把重点放在两个文件上：

• AGENTS.md

• TOOLS.md

因为真正执行时，worker 最需要的是职责和制度，不是表演感。

self-media

专注：

• 研究

• 热点判断

• 正文产出

• 辅助物料

head-of-operations

专注：

• 平台适配

• 审核准备

• 草稿包整理

sde

专注：

• 工程排障

• 链路修复

• shared 修复

• Skill 产品化

这一步特别重要：

worker 不需要太像“一个人”，但一定要像“一个岗位”。

六、shared 目录不是附件，而是“共享面”

很多系统都会有个 shared 目录，但更多时候它像一个“资料堆放区”，而不是协作系统的一部分。

真正有效的 shared，不是随便建几个目录，而是要有最小制度。

最小结构参考如下（当然还可以更小，越复杂，模型在生成处理时不确定性越高）：

shared/├── tasks/│ └── <task_id>/│ ├── request.md│ ├── result.md│ └── status.json├── templates/ ├── request.template.md ├── result.template.md └── status.template.json

这三件套一旦建立，整个系统会明显变得更稳：

• 任务不再只存在聊天记录里

• worker 结果能复用

• main 验收更有依据

• sde 后续做 Skill 更容易产品化

七、skills 最大的问题，不是少，而是“乱”

很多时候系统不好用，不是因为 Skill 不够，而是因为 Skill 太多、太乱、没有分层。

后来我把 Skill 结构重构成了两层：

1）共享正式版：`~/.openclaw/skills`

放跨 Agent 共用、逻辑相对稳定的能力

2）Agent 专属版：`<workspace>/skills`

放某个 Agent 专用、实验中的、或需要覆盖共享版的能力

这样一来，Skill 治理就清楚多了：

• 通用能力统一维护

• 实验能力不污染全局

• 正式版和试验版分层

• 后续迁移和回滚都更容易

八、openclaw.json 不要一开始就追求“最严”，先把结构理顺

配置这一块，一开始很容易觉得应该马上把权限切得很细、策略配得很严。

但实际做下来发现，如果系统还没跑顺，过早收权限，往往会让调试成本暴增。

所以我最后采取的是两阶段思路：

第一阶段：先跑通

重点是：

• main 设为默认 Agent

• Feishu 只绑定 main

• heartbeat 只给 main

• worker 作为内部执行目标

• tools 权限先不急着收紧

第二阶段：再收紧

等主流程稳定后，再逐步处理：

• per-agent 工具边界

• 平台主链固化

• sandbox / exec / allow/deny

• 高风险能力收口

这个顺序非常关键。因为流程没跑顺前，最重要的是把协作关系理顺，而不是先把门锁得很死。

九、heartbeat 最容易做错：不要把它做成“刷存在感”

一开始我也有个误区：既然要主动，那 heartbeat 就应该不断提醒、不断同步、不断输出存在感。

后来发现，这样特别容易变成噪音。

真正合理的 heartbeat 应该是：

先判断能不能推进，能推进就推进；不能推进才提醒。

所以我最后给 main 的 heartbeat 定义了几个重点检查项：

• 今日 AI 资讯是否已生成

• 是否已有热点候选但未成稿

• 是否已有成稿但未平台适配

• 是否有任务长时间 BLOCKED

• 是否有草稿完成但未进入审核提醒

• 是否有高频重复动作值得转给 sde 做 Skill

它的价值不是“告诉用户我在跟进”，而是“真正把事情往前推”。

十、最后总结：让 OpenClaw 真正像一个小团队

如果让我用一句话总结这次实践，我会说：

多 Agent 不是把很多角色拼在一起，而是把“主控、分工、共享、回传、治理”这几件事真正做对。

对内容型 AI 团队来说，最有效的做法不是一味追求复杂，而是把系统稳定在这样一个状态：

• main 统一入口

• worker 明确分工

• session 作为通讯主线

• shared 作为共享主线

• worker 结构化回传

• skills 分层治理

• heartbeat 做主动推进

• sde 负责能力沉淀

到了这一步，OpenClaw 才会从“能跑”真正进化成：

像一个真正的小团队在协同工作。