我把 5 个 AI Agent 砍到 3 个，系统终于没那么乱了

我花了一个月，给自己组了一支“三人团队”。

这三位都是 AI Agent。我叫这套系统“小龙虾”。

最开始我以为 Agent 越多越强。真正跑起来之后，五个 Agent 挤在一起，最常见的是抢资源、丢状态和互相等消息。

最后我把队伍砍到三个，给每个角色清楚的职责和不同的模型，系统反而安静了。

为什么叫“小龙虾”

OpenClaw 项目经历过几次改名。社区把龙虾脱壳的意象保留下来，中文用户也很自然地叫它“小龙虾”。

这个名字对我来说挺贴切。Agent 系统不是装好就成熟，它会不断换配置、改角色、丢掉不合适的壳，再长出下一版。

让我觉得有用的，是它开始接工具

以前用聊天机器人，主要是问一句、答一句。OpenClaw 这类系统让我第一次把模型、工具和任务调度放在一起：一个 Agent 可以写代码，另一个整理内容，另一个负责检查结果。

只要能接住任务、调用工具、返回可验证的结果，它就已经和普通聊天框很不一样。

后来真正卡住我的，是怎么让多个 Agent 在同一台机器上稳定工作。

我是怎么把系统越搭越复杂的

先放在 NAS 上跑

我最先把 OpenClaw 放进 NAS 的 Docker。安装方便，但权限、文件访问和网络配置很快成了限制。想改一个系统级配置，常常要绕好几层。

再搬到云服务器

服务器权限自由了，新的麻烦也来了：代理、端口、安全和日常维护。本来想让 AI 帮我省事，结果一半时间花在照顾服务器。

Mac mini 上开多个 Gateway

我给每个 Agent 单独开一个 Gateway，希望它们互不干扰。

资源倒是隔开了，协作也被隔开了。消息散在不同会话里，状态无法顺畅传递，硬件资源还被重复占用。

单 Gateway 塞五个 Agent

我又把它们合到一个 Gateway。表面上统一了，实际出现了更严重的并发竞争。

五个 Agent 同时调用同一模型 API，请求会排队、触发速率限制，最后超时。有时一个任务没人接，有时五个同时响应。最难受的是状态不透明：你不知道它是在处理、卡住，还是做完后忘了回消息。

最后只留三个角色

最后我把团队缩成三个：

• Mike 负责统筹和拆任务，使用响应快、成本低的模型；
• May 负责内容和运营，使用更适合中文表达的模型；
• Bob 负责代码和资料，必要时再调用 Claude Code 与 Codex 做实现和审查。

具体模型会换，角色边界更重要。谁负责派活、谁能写文件、谁来审查、失败后交给谁，这些规则一清楚，系统才开始像团队。

现在这三个 Agent 能做什么

它们能帮我整理文档、生成文章初稿、调用代码工具、管理部分文件和自动化脚本，也能把长资料压缩成可用摘要。

听起来很多，但我不会给所有 Agent 同样的权限。能读不代表能写，能写不代表能发布，能执行命令也不代表能碰凭据和生产环境。

Agent 真正进入电脑之后，权限边界比“能力展示”重要。

真正反复出现的问题

上下文越聊越大

聊天记录不断累积，成本会涨，模型也更容易被旧信息干扰。后来我开始把长期知识、当前任务和临时日志分开保存，而不是让所有内容永远留在同一段上下文里。

模型选得太统一

让所有角色都调用同一个最强模型，既贵，也容易触发并发限制。按任务选择模型，比按“谁最强”选择模型更稳。

做完了，却没返回

Agent 有时已经执行完任务，消息链路却没把结果送回来。用户看到的就是“已读不回”。

这类问题不能靠多催几次解决，需要明确的任务状态、超时、重试和最终回执。

多 Agent 抢同一个资源

除了模型 API，它们还会争文件、终端和状态记录。没有锁、队列或独立工作区，多 Agent 只是把单人混乱放大了。

砍掉两个角色之后，我看到的变化

角色少了以后，同时抢模型 API 的请求变少，谁负责返回结果也更清楚。以前一个任务可能五个都回应，也可能谁都不接；现在至少能先找到负责人，再看它卡在哪一步。

这还不能证明系统已经长期稳定。我没有完整的 uptime 或失败率数据，只能说它不再像之前那样频繁互相打架，我也愿意把它放进日常工作里继续用。

我现在很少先问“还能再加几个 Agent”，而是先看这个步骤是否真的需要一个新角色。目标、权限、交接和验收没有说清楚，多加一个 Agent 只会多一条需要管理的消息链。

---

本文来自「维天说」，全平台同名。
我会持续分享普通人能用上的 AI 工具、内容工作流和真实实践，欢迎联系我，一起交流 AI。