AI 编程团队的核心矛盾：上下文管理与 agent 架构选择
当一个 AI 团队开始"失忆"，它的问题不是算力不够，而是信息没有好好传递。
真实场景：团队大了，反而记不住了
一个使用 AI agent 协助开发的小团队，最常遇到的问题是这样的：
第一天，agent 把项目架构搭好了。 第二天，换了个新会话，agent 问："这个项目用什么框架？" 第三天，agent 改了一个 bug，同时引出了两个新 bug，因为它不记得第二天改了什么。
这不是 AI 不够聪明。是上下文没有管理好。
多 agent 架构的诱惑与陷阱
当单 agent 开始显得"能力不够用"时，最直觉的反应是把任务拆分，给每个 agent 专人来处理：
- 一个 agent 负责写代码
- 一个 agent 负责代码审查
- 一个 agent 负责测试
- 一个 agent 负责部署
看起来分工明确，但现实是：每个 agent 都在自己的独立 session 里运行，它们之间没有共享的记忆。
结果变成了这样：
- 写代码的 agent 认为需求已经确认了
- 审查的 agent 认为需求还没定
- 两个 agent 吵了一下午，发现分歧来源是一份它们都没读到过的需求文档
这就是"记忆断裂"问题：信息在 agent 之间传递时，要么丢失，要么变形，要么根本没传过去。
两种主流解决思路
方案一：共享记忆层（Shared Memory）
让所有 agent 读写同一个记忆存储。每完成一个步骤，写入共享上下文；每次启动新任务，先从共享记忆里读取背景信息。
优点：信息可以累积，不依赖单次对话长度 缺点：记忆的写入时机和格式很难标准化；错误的记忆会像滚雪球一样越滚越大；多 agent 并发写入时还有竞争问题
代表项目：部分 OpenClaw 配置方案
方案二：主管中转模式（Human-in-the-middle Orchestrator）
不再让 agent 直接协作，而是引入一个"主管"角色。所有任务先发给主管，主管负责分解、派发、汇总结果，最后交给人确认。
agent 本身变成"临时工"——任务来了就执行，执行完就结束，不保留会话状态。真正的上下文由主管在人这一层管理。
优点：人的确认环节天然解决了记忆问题；主管可以看到全局，不会出现 agent 各说各话的情况 缺点：人变成了瓶颈，整个流程的速度受限于主管的响应速度；主管自己也需要维护上下文
代表方案：本文讨论的背景——Hermes 主管中转 + subagent 临时任务架构
为什么最后往往回到"单 agent + 人盯"
实际运行一段时间后发现，在很多中小型团队的场景下，最稳定的方案其实是：
一个能力足够强的 AI 助手 + 人做最终确认。
原因很简单：
- 单 agent 不存在信息传递损失——所有上下文都在一次对话里，不存在"我以为你知道了"的问题
- 人的确认比 agent 协作更可靠——当 agent 之间出现分歧，最终需要一个人来仲裁，这个仲裁者本来就不应该缺席
- 架构越简单，bug 越少——多 agent 之间的通信协议、记忆格式、错误处理，每一层都是潜在的故障点
上下文管理的本质
回过头来看，AI agent 系统的上下文管理，本质上是一个信息可靠传递的问题。
不管用什么架构，都要回答这几个问题：
- 信息存在哪里？
- 谁负责写入？
- 谁负责读取？
- 写入的格式是什么，能被准确解析吗？
- 出错了谁来发现和修正？
当团队规模小、任务简单时，单 agent + 人工确认几乎总是最优解。 当任务足够复杂、需要并发处理时，才值得引入多 agent + 共享记忆的方案——但此时你要付出的工程代价也相应更高。
结论
不要因为"多 agent 听起来更厉害"就上多 agent。 也不要因为"单 agent 好像能力不够"就急着拆分。
先问自己：这个场景下，上下文管理的真正瓶颈在哪里？ 答案会告诉你该选什么。
本文是关于 AI 工作流设计的一系列实践思考的第二篇。