币须知道据 动察 Beating 监测，CrewAI、MetaGPT 等框架推广了一种多 Agent 设计：让不同 Agent 扮演产品经理、架构师、测试工程师，像公司部门一样传文档、跑流水线。SagaSu 发了一篇万字分析，把这种模式叫「三省六部幻觉」，翻遍 Anthropic、OpenAI、谷歌三家的工程文档后发现，没有一家这么干。
文章指出两个根本问题。第一是假边界：人类需要分工是因为一个人干不了所有事，但 LLM 能写需求文档也能写代码，不存在「专业壁垒」。贴了角色标签的 Agent 不会因此变专业，反而在遇到角色外的问题时直接跳过，而最有价值的推理往往发生在边界上。第二是信息在流转中死亡。Agent A 产出一份文档传给 B，传的是结论不是推理过程，B 要重建上下文，隐含假设逐层丢失，链条越长越容易「每个节点都对，整体已经歪了」。
有人反驳：三家厂商用的 progress.txt、spec 文件不也是传文件？文章认为区别在于，角色间的文档是单向交接，A 写完传给 B 就不管了，信息被压缩成结论；而状态文件是同一个任务的增量日志，写和读的是同一个角色在不同时间点，信息是连续积累的，推理链能跨会话保持连贯。
三家的具体做法：
– Anthropic 把每个新会话比作「轮班工程师」，用 progress.txt 当交班记录，第一个会话由专门的 Initializer Agent 搭环境、写操作手册，后续会话读取后接着干。多 Agent 采用 orchestrator-worker 模式，一个主 Agent 拆任务，多个子 Agent 并行探索不同方向，结果回流汇总，不是流水线接力
– OpenAI 在任务启动时用 spec 文件锁死目标（防 Agent「做出很厉害但方向错了的东西」），runbook 同时充当操作手册和审计日志，还引入 Skills（可复用的版本化指令集，本质是工具和操作规程，不是角色）。GPT-5.3-Codex 用这套机制跑了约 25 小时不间断，完成了一个完整设计工具，全程保持连贯
– 谷歌用 1M token 长上下文硬扩窗口，同时把项目意图写进代码库的持久化 Markdown 文件，不依赖聊天记录。Gemini 3 还加了 Thought Signatures，在长会话里保存推理链关键节点，防止前后逻辑自相矛盾
从三家实践中可以提炼几条共同原则。多 Agent 的价值是并行覆盖搜索空间，不是模拟分工。Anthropic Research 系统的数据表明，token 用量解释了 80% 的性能差异：多派几个 Agent 效果更好，本质上是花了更多算力同时探索不同方向，跟怎么分工没关系。如果要加验证环节，让验证 Agent 专门挑毛病，不是接棒继续做。给 Agent 配什么工具决定了它能做什么，角色标签只决定它愿意做什么。
文章最后提醒，模型能力在快速迭代，今天写进系统里的补丁六个月后可能变成死代码。Anthropic 已经踩过这个坑：Sonnet 4.5 快到上下文上限时会提前收尾，团队专门加了 context reset 机制，结果换成 Opus 4.5 后这个行为消失了，reset 随即成了无用代码。保持架构可演化，比选一个「完美架构」更重要。
