搭完第一只 Agent 后，我很快又加了几个角色。想象中是一支 AI 小队，现实先给了我五份配置、五个进程，以及一台不断进入 swap 的 Mac mini。
最后我只留下 3 个 Agent，也把多个 Gateway 合成了一个。系统没有因为“人少了”变弱，反而更容易维护。
单 Agent 能用，但角色容易打架
我一开始让一个 Agent 同时写代码、做内容、查资料和盯运维。很快就遇到两个问题。
第一是角色冲突。写代码时我希望它谨慎、少发挥；写内容时又希望它有观点。一套身份和行为规则同时服务这两种任务，越改越别扭。
第二是会话膨胀。所有任务都混在同一个 session 里，旧上下文不断被带入新任务。一次故障时，我当时的界面记录显示 session 已接近 28 万 token，单次回复等了半个多小时。原始运行日志没有随文章归档，所以这组数字只保留为当时的个人记录，不是可复现 benchmark。
多 Agent 对我真正有用的地方，是把角色和工作区分开。Mike 负责统筹，Bob 做代码，May 做内容。每个角色有独立的 SOUL.md、MEMORY.md 和任务记录，出了问题也更容易判断发生在哪一边。
真正该合并的是 Gateway
早期方案是每个 Agent 启一个 Gateway。五个角色就有五个独立进程，配置、日志和重启方式全都分开。
我当时记录的粗略占用是：多个 Gateway 合计约 2.5GB，合并成一个后约 500MB。它们来自同一台 16GB Mac mini、同一阶段的个人观察，不是严格控制变量的测试。
合并后，Telegram 和飞书的消息先进入同一个 Gateway，再按绑定关系交给不同 Agent。角色仍然独立，只是入口、进程和配置集中管理。
这个方案也有代价：Gateway 一旦挂掉，三个角色都会受影响。但对我这种单人、单机环境来说，少维护四个进程比进程级隔离更重要。
三次翻车，改变了我的架构选择
会话太长，监控却说正常
Watchdog 当时只看日志尾部。最后几行经常是没有 usage 字段的工具结果，于是它把空值当成了正常状态。界面看着没报警，实际会话已经大到很难响应。
这个问题后来让我改了判断方式：监控不能只看“有没有报错”，还要确认它读到的指标是不是目标指标。
并发增加后，API 错误明显变多
五个进程同时工作时，我频繁遇到 rate limit、重试和长时间无响应。由于当时没有保存供应商侧的并发和重试明细，我不能证明“五个进程”就是唯一原因。
我能确认的是，减少同时运行的角色、错开定时任务，并给不同角色设置备用模型后，现象明显缓解。所以我把它当成一次并发管理问题，而不是一条普遍结论。
swap 让整台机器一起变慢
在我的 16GB Mac mini 上，五个 Gateway 加上浏览器和其他服务一起运行时，系统开始频繁 swap，交互明显变慢。我没有再设一个“超过多少 GB 就一定危险”的通用阈值，而是看持续增长、响应延迟和机器是否影响正常工作。
我最后保留的四条规则
- 每个 Agent 使用独立工作区，不混用身份、记忆和 session。
- 同一台个人机器优先共用一个 Gateway，除非确实需要进程隔离。
- 定时任务错开执行，并记录实际的限流和重试信息。
- 监控要验证数据来源，不能把空值当成正常。
我从 5 个角色减到 3 个，不是因为多 Agent 没用，而是角色数量已经超过了我能稳定维护的范围。对一个人的系统来说，能持续运行比组织图看起来热闹更重要。
本文来自「维天说」，全平台同名。
我会持续分享普通人能用上的 AI 工具、内容工作流和真实实践，欢迎联系我，一起交流 AI。
