一个 Agent 负责研究，一个负责写作，一个负责运营，一个负责发布，彼此还能互相转消息、共享信息、自动接力，看起来非常像一支真正的数字团队。

但李岳这篇 OpenClaw 多 Agent 实操，最有价值的地方恰恰在于它没有先鼓吹协同，而是先强调了一件更现实的事：

对于大多数个人用户来说，多 Agent 的第一步不是协同，而是隔离。

这句话非常重要。

因为很多人一开始觉得 Agent 越像“团队”越高级，结果一上来就想打通消息通道、共享上下文、让几个子 Agent 彼此配合。最后得到的往往不是效率，而是混乱：记忆串台、角色重叠、上下文污染、Token 消耗暴涨，而且一旦出错很难排查。

李岳自己的触发点也非常典型。一个 Agent 对话越来越多之后，即便装了记忆插件，仍然会因为长期积累的内容太杂、太长而变得“脑子发糊”。这其实是很多人用 Agent 到一定阶段都会撞上的问题：不是模型突然变笨，而是同一个上下文里承载了太多不同职责。

所以他做的不是继续给一个主 Agent 堆更多规则，而是把日常自媒体工作拆开，让 OpenClaw 帮他拆成多个子 Agent。每个 Agent 只负责一块明确工作，互不干扰。

这个思路我非常认同。

因为在 Agent 系统里，隔离本身就是生产力。

隔离会话，意味着不同任务不会互相污染；
隔离记忆，意味着每个 Agent 只背自己该背的经验；
隔离角色，意味着输出风格更稳定；
隔离职责，意味着你更容易发现哪个环节出了问题。

协同当然有价值，但协同是第二阶段的问题。第一阶段真正决定系统能不能跑起来的，往往是隔离做没做好。

李岳这篇文章给出的落地方式，也很符合这种思路。

他用飞书机器人作为每个子 Agent 的独立入口：一个飞书应用对应一个 Agent。这样用户在飞书侧看见的是不同“员工”，在 OpenClaw 侧则是不同 workspace 和不同绑定关系。哪怕所有 Agent 背后都挂在同一台电脑、同一个 gateway 上，外部交互面也已经被拆开了。

这一步听起来只是通讯渠道配置，但本质上它是在做一个更重要的事：

把“多 Agent”从概念，变成真正可操作的多会话、多身份、多工作区系统。

文章里整个流程其实很清楚：

先建飞书应用，
再配 OpenClaw 渠道，
再给每个 Agent 建独立子工作区，
再做绑定，
最后再定义身份和人格。

这套顺序非常对。

很多人会先沉迷于 prompt 和人设，想着先把角色写得多生动；但如果会话和工作区本身没拆清楚，再漂亮的人设最后也会被混乱的上下文拖垮。

所以在我看来，这篇文章真正想解决的问题不是“如何拥有 4 个机器人”，而是“如何让 4 个机器人真的各干各的，而不是表面分身、内里串台”。

这也是为什么他不建议新手一开始就让子 Agent 协同办公。

原因非常现实：

第一，配置复杂度会明显上升。你要额外处理消息通道、通信关系、事件回调等问题。

第二，成本会显著上升。Agent 一旦协作，就不只是记住自己的事，还要长期记住对方的状态、任务和交接内容。Token 消耗自然会比隔离运行高很多。

这一点特别值得单独强调。

很多人低估多 Agent 协同的成本，不只是低估计算成本，也低估了系统复杂度成本。一个单独 Agent 出错，你只需要看一条链路；两个 Agent 协同出错，你就要搞清楚：是发送方错了，接收方错了，还是中间交接格式错了。

对个人用户来说，如果隔离运行已经能解决 80% 的问题，那先把这 80% 跑稳，远比提前追求“高级协同”更重要。

文章后半段关于角色定义也很值得看。它把多 Agent 的人格层拆成三个文件：IDENTITY.md、USER.md、SOUL.md。

这种拆法的价值，不只是“让 AI 更有个性”，而是让每个 Agent 的身份、用户理解和价值倾向都能被单独调教。这样一来，你不是在使用一堆同质化分身，而是在使用几套不同的判断框架。

从系统设计上看，这其实和组织管理很像。

一个团队之所以能拆分，不只是因为工位分开了，还因为每个人知道自己是谁、服务谁、遇到模糊选择时按什么原则判断。把这些东西写成文件，本质上是在给 Agent 建岗位说明书和行为手册。

这也是为什么我觉得这篇文章对 Kenny 很有现实参考价值。

因为你现在本身就在朝这个方向走：

抓取内容、筛选信息、整理成文、发布到网站、沉淀成任务，这已经是一条多阶段工作流。下一步如果真要走向多 Agent，不一定先追求“互相协作的员工军团”，更合理的做法反而是：

先把每个子 Agent 彻底隔离清楚。

比如：

选题 Agent 只负责找素材；
写作 Agent 只负责产出文章；
审稿 Agent 只负责判断是否适合发站；
发布 Agent 只负责落库和发布；
跟进 Agent 只负责把值得继续研究的内容写进 TODO。

只要每个环节都隔离得足够干净，后面要不要协作、在哪里协作、怎么协作，才有可能逐步加进去。

所以如果要用一句话总结这篇文章，我会这样说：

多 Agent 系统真正的成熟，不是你能不能让它们彼此聊天，
而是你有没有先学会让它们各自安静地做好自己的工作。

对个人用户来说，先隔离，再协同，几乎永远是更稳的路线。