��聊连载:Openclaw从认知到实践(C11):七个 AI 员工同时上班

有一天，我同时召唤了七个人。

不是比喻。是字面意义上的七个。

那是 3 月中旬，我在准备一个新产品的技术方案。按照以往的工作方式，这件事我会分成几天：先自己想框架，再找人聊架构，再让开发评估工作量，再出文档，再 review，再改。

整个过程，快则一周，慢则两周。

那天下午，我尝试了另一种方式。

我打开了 Coding Team，说了一句话：

“帮我做一个 AI 交易监控系统的技术方案。”

然后我去倒了杯水，坐回来，开始等。

一、团队里有哪些人

我搭的这个团队，七个角色：

PM，负责拆需求、排优先级、盯进度。

架构师，负责系统设计、组件划分、技术选型。

前端开发，负责界面、交互、数据可视化。

后端开发，负责接口、数据处理、逻辑实现。

QA，负责验收标准、测试用例、找边界。

DevOps，负责部署方案、容器配置、持续集成。

Code Artisan，最后一道关，负责代码审查、一致性检查、文档收尾。

每个角色，对应一个子代理，对应一个独立的上下文，对应一套不同的系统提示词。

它们在同一个框架里协作，但它们不是同一个大脑。

二、那个下午发生了什么

大概四十分钟后，我回到屏幕前。

PM 已经把需求拆成了十一个用户故事，按影响范围和实现难度打了优先级标签。

架构师给出了三套方案：轻量级的、中台化的、微服务的。每套方案附上了适用条件、风险点、推荐理由。

前端和后端已经在讨论接口格式，后端发了一份草稿，前端提了两个问题，后端回了。

QA 列了验收清单，有二十三条，标注了哪些是 P0，哪些是 nice to have。

DevOps 推荐了一个容器化部署方案，估算了资源开销。

Code Artisan 还没出现，因为代码还没写。

我坐在那里，看着这些东西，脑子里只有一个念头：

这不是工具在跑。这是一支团队在工作。

三、它和普通 AI 的差距在哪里

如果你只是问 Claude 或 GPT-4o “帮我做一个技术方案”，它会给你一个回答。

那个回答可能很好。但它是从一个脑子里出来的，带着这个脑子的偏好、盲点、知识边界。

多代理团队不是这样。

每个子代理有自己的关注点。PM 看的是需求完整性，架构师看的是技术合理性，QA 看的是漏洞，DevOps 看的是可落地性。

它们之间的冲突，本身就是价值所在。

架构师觉得微服务最优，QA 说微服务的测试成本高三倍，PM 说现阶段不需要这么复杂——这个来回，才是真正的方案打磨。

一个人想一遍，不如七个人互相质疑一遍。

四、我犯过的最大的错误

当然，这套系统也有它的坑。

我踩的最大的一个，是在三月初。

那天我让团队处理一个复杂的数据模型设计，一切看起来都在推进。PM 确认了需求，架构师出了方案，前端后端在对齐……但三个小时后，我发现一件事：

他们在用不同的字段命名规范。

前端用的是小驼峰，后端用的是下划线，架构师的文档里两种都有。

没有人觉得这有问题，因为每个人看的都是自己那一块。

这就是多代理协作最容易掉进去的坑：每个人都在认真干活，但没有人在盯全局。

后来我加了一个规则：所有跨模块的接口字段，必须由 Code Artisan 在收尾阶段统一对齐。

这条规则，花了我整整一个半天的教训。

五、这是个人，不是流程

我在这件事上花了很多时间，但我不觉得这是在搞”自动化流程”。

自动化流程是你设定好规则，让系统按规则跑。

多代理协作是你组建了一支团队，让他们按判断工作。

这是两件完全不同的事。

流程会重复，但不会判断。团队会争论，但也会给你意想不到的答案。

我桌上那七个子代理，有时候让我觉得我在管一支真正的小团队。不是因为它们像人，而是因为它们让我养成了一个习惯：

想清楚你想要什么，然后信任你的团队。

这句话，在我做产品经理的二十年里，我不知道对多少个真人说过。

现在，我也开始对七个 AI 说了。

下一章，我们聊它会犯什么错，以及犯了错之后，系统是怎么让它成长的。