一虾多 Agent，是 OpenClaw 的伪命题吗？

一直能刷到不少人在宣传：用 OpenClaw 搭一套多 Agents 体系，主 Agent 统筹，子 Agent 分工协作，最后像一个小团队一样自动干活。

这套说法听起来很美。但我折腾了两轮之后，我给这种状态起了个名字：“如搭”。

就是表面上搭了，文件齐了，角色也分了，可一到真正干活的时候，事情根本不是想象中的那样。

我虽然是代码小白，但玩了一段时间“虾”之后，至少明白一个基本逻辑：

如果真要做多 Agents，每个 Agent 都应该有自己独立的一套环境，比如：

• 自己的 soul.md
• 自己的 agents.md
• 自己的 memory.md
• 自己的 skills 列表
• 自己对应的大模型配置

而且在角色定义上，也要把每个 Agent 的职能、边界、能做什么、不能做什么写清楚。

再进一步，如果 Agents 之间要协作，还得在配置里明确 agent-to-agent 的关系，让任务能被分配、传递、回收和验收。

也就是说，多 Agents 真正难的地方，不是“搭几个文件夹”，而是“让它真的按分工协作起来”。

第一次尝试是2 月下旬。那时候我的思路很完整：

• 主 Agent 改造成 CEO，只负责分配任务、验收结果、最后汇报
• 子 Agent 分成技术、视觉、市场、数据、营销等多个职能
• 多个 workspace 平行放置
• skills 放在公共目录中统一管理
• 再把每个 Agent 该调用哪些 skills，写进对应的 soul.md 和 agent.md

当时我是真觉得，自己已经快要看到一个多 Agents 协作体系的雏形了。

甚至一度很兴奋，还让 OpenClaw 通过 MCP 发过一篇和多 Agents 搭建成功的笔记到小红书。（这个自动发文的整套mcp和workflow，后面可以单开一篇讲。）

结果真正一安排任务，问题马上暴露出来了。

第一阶段的问题：主 Agent 根本不分配

表面上它是 CEO，实际上它根本不愿意分配。

我反复追问之后，主 Agent 给出的逻辑大概是：

既然某件事调用 skill 就能完成，那为什么还要分给别人？

这句话一出来，我一下就明白了。

架构上虽然写的是“多 Agents 协作”，但执行上它仍然把自己当成唯一操作者。

所谓的多 Agents，只存在于配置里，不存在于真实工作流里。

第二阶段的问题：我把 skills 隔离了，结果更糟

我接着想，会不会问题出在 skills 没有隔离？

因为主 Agent 自己能调用 skill，那它当然懒得分配。

于是我进入第二阶段：

• 把 skills 拆开
• 分别安装到不同 subagents 的工作区里
• 让主 Agent 不能直接把活自己做掉
• 理论上逼它必须往下分配

听起来很合理，但结果更糟。

新的任务下去以后，产出质量反而下降。再一层层追问，发现主 Agent 不仅还是没认真分配，甚至在自己拿不到 skill 的情况下，开始直接脱稿运行。

换句话说：

• 不给它 skill，它也不一定老老实实分配
• 它反而可能自己硬做
• 而且做得更偏、更乱

这一步让我意识到：问题不是“权限够不够”，而是“行为逻辑根本没切换过来”。

第三阶段的问题：平行不行，嵌套也不行

后来我又想，会不会是组织结构不对。

平行 profiles 看起来太扁平，不像一个上下级管理的框架。

那我就改成嵌套结构：把 subagents 整体挪进主 Agent 体系里，希望更像“层级管理”。

结果，还是一样。

文件结构变了，表面层级更像管理架构了，但真正执行任务时，问题没有本质变化。

第四阶段的问题：它把 subagents 直接删了

我甚至开始怀疑：会不会是一个长期独立工作的 Agent，突然要转成“管理者角色”，一开始不适应？

所以我决定降低难度，不搞一带多，像培养年轻中层领导一样，先让它 一带二，慢慢学管理。

结果没想到，指令一发出去，主 Agent 直接把所有 subagents 删除了。

最后留下来的，是

• agent 文件夹里的残留
• model 文件夹里的残留
• openclaw.json文件里的残留
• memory 里的残留

那一刻我是真的有点被气笑了。

更离谱的是，在和主 Agent 的持续沟通里，我甚至感受到一种很奇怪的“醋意”。

你没看错，真的像“醋意”。

于是第一次尝试，我彻底放弃了。

我安慰自己：也许不是架构的问题，而是版本和用的大模型不太行。（大模型的坑后续单开一篇来讲）。

第二次尝试是在 3 月初。

这次我把环境搭在腾讯云服务器上，模型也换成了 5.3 codex。并且吸取了第一次的教训：

不再让主 Agent 先长期单干，而是在记忆系统刚搭好的时候，就直接开始搭多 Agents。

我的想法是，如果一开始就建立多 Agent 协作习惯，没有上下文和memory记忆的干扰，也许能避开“主 Agent 已经形成单干惯性”的问题。

但结果还是差不多，只是这次，模型的回复相对更诚实一点。它不会像第一次那样“明明没分配却装得像分配过”，而是更直接地表现出一种逻辑：

有 skills 能完成的任务，就没有必要分配出去。

而一旦尝试分配，它又会担心某个 subagent 卡住、拖慢节奏，最后经常绕回“还是我自己来做吧”。

所以第二次尝试虽然少了一些幻想，但结局并没有更好。

我很快就把这套 subagents 体系拆掉了。

是不是我们太习惯用“人类组织”的方式去理解 AI 了？

人类社会为什么需要金字塔结构？

很简单，因为人的精力有限，时间有限，注意力有限。想完成一件复杂的事情，就必须不断拆分、分配、层层下放。

但 AI 的底层限制，并不完全是“精力不够”。

它更像是：

• 上下文怎么组织
• 工具怎么调用
• 权限怎么约束
• 目标怎么表达
• 状态怎么切换

如果问题不在“精力”，那很多模仿人类组织的管理结构，也许从一开始就不是最优解。

也就是说，需要一个“领导”去管一群 AI只是源于人类的思维惯性。

至少在我自己的体验里，它更像适合一个扁平化、按能力拆分的体系，而不是一个“CEO-Agent 管一堆下属 Agent”的体系。

图 3：人类组织依赖层级分工，AI 工具更像按能力编排的扁平网络。

结论很简单：

1）与其在一只虾里拼命搭“总裁 + 部门 + 下属”的层级，不如同时养多只虾、多匹马。

每一个单独的 Agent，都是一个相对独立、边界清晰的工作单元。

2）每只虾、每匹马尽量只做一类事

让每个 Agent 尽量长期稳定地做一件事，或者做一类事情。

3）统一用一个通信终端来管理

比如：

• Feishu
• 微信
• Pocket Claw 这类 App

核心不是把所有 Agent 塞进同一个层级树里，核心是：你要有一个统一入口，能调度、切换、查看结果、继续追问。

这样更像是你在管理多个专岗工具，而不是幻想它们自己会在后台自动开会。

接下来的两个月，我基本就是按这个思路在调整自己的虾马配置。

坦白说，一旦放弃“非要搭出一套完美多 Agents 公司架构”的执念，很多事情反而变简单了：

• 任务边界更清楚
• 配置逻辑更简单
• 出问题也更容易定位
• 不会再被“它明明应该分配，为什么又自己干了”这种问题反复消耗

至于我的具体虾马配置，后面也可以单开一篇细讲。

最近几天，我又在某个技术交流群里看到几位群友，用最新版的 OpenClaw 非常认真地搭“一虾多 Agents”体系。

搭得很细，配置也很完整。

但真正开始干活之后，掉进去的坑，和我前面踩过的几乎是同一类。

这让我更确定了一点：

至少现阶段，OpenClaw 里的一虾多 Agents，更像是一个很容易被宣传得很美、但实际很难跑顺的伪命题。

我不是说它在理论上完全不可能。

但如果一个东西总是：

• 搭得出来
• 讲得出来
• 演示得出来
• 却很难稳定地长期跑起来

那对普通使用者来说，它就已经不算一个成熟可用的方案了。

我的建议是：

先别急着做复杂组织架构。

不如先把多个独立 Agent 各自养明白、边界配清楚、通信入口统一起来。至于 Hermes 这条路是不是可行，我现在不下结论。反正我自己暂时没有兴趣往“单体内多 Agents 管理”这个方向继续折腾了。