发出去以后收到了110条评论，345K的阅读量超出预期。认真读完之后，有几条评论让我重新审视了文章里表述不够准确的地方，也有几条把论点说得比我更清楚。这篇文章是对这些评论的正面回应——承认哪里说得不够好，坚守哪里不动摇，以及讨论延伸出来的新问题。
一、我承认说得不够准确的地方
文章的反对对象定义得太宽了
@Luke（@luke_bit）指出了一个真实的逻辑漏洞：
"'角色扮演制造了假边界' 那不用系统提示词了？'信息在流转中死亡' 单agent上下文不用压缩了？最后给的该怎么做还是多 agent，那你实际反对的可能是单 agent 就一个系统提示词'你是 PM'，这种做法，用写这么多吗"
这个批评是对的。文章里把"角色扮演"和"三省六部"混在一起批评，但这两件事不是同一个问题。
@BinaryHB/DaDalus 在评论里把这个区分说得比我更清楚：
"感觉要反对的不是'多agent'或'角色'本身，是role-as-cosplay加串行压缩接棒这个组合。"
这是准确的。文章真正的反对对象应该是：给agent贴职能标签，同时让信息在agent之间以压缩摘要的形式单向流转。这两个条件同时成立才是问题，缺一个都要重新评估。
只有角色标签、没有压缩接棒——比如同一个agent在不同阶段以不同视角审视同一份原始文档——这不是文章批评的模式。
只有多agent、没有角色cosplay——比如Anthropic Research系统里的并行subagent——这也不是文章批评的模式。
我应该在文章里把这个区分说清楚，没有做到。
二、评论里有人把论点说得比我更好
"信息维度拆分 vs 角色拆分"
@万物燃烧 给出了全评论区最干净的概括：
"如果任务能在单个context window内完成→单Agent最优；如果超出→必须拆分，关键是按信息维度拆分（代码/设计/测试），不是按角色拆分（PM/Dev/QA）；拆分后的信息流转要回流合并，不是流水线接力。"
这比文章里的表述更精确。"信息维度"是拆分的正确维度，角色是错误的维度。前者以"这段信息是否可以独立处理"为边界，后者以"这个工作该谁负责"为边界——一个是信息属性，一个是人类组织习惯。
"传原文 vs 传摘要"才是核心判断标准
@BinaryHB/DaDalus 给了一个极好的具体例子：
"同样设一个'Developer agent'，A方案是给它product-spec.md v3.2这个路径让它自己读，B方案是给它一段主agent改写过的需求描述。这两个在架构图上长得一模一样，但做出来的效果完全不同。"
这个例子直接把文章里"传结论不传推理"的抽象表述落地了。判断一个多agent系统是否有问题，不是看它有没有角色标签，而是看下一个agent拿到的是原始材料还是转述版本。
"上下文污染"是多agent的合理用途之一
@Tetsu（@tetsu76）说：
"多agent应该是防止任务打岔、上下文'污染'。而不是解决劳什子的'分工'。即便口头上分了工，依然是为了独立性。"
这个观点文章里完全没提，是一个真实的遗漏。多agent在某些场景下的价值不是"更多token覆盖更大搜索空间"，而是隔离不同任务的信息，防止互相干扰。比如同时跑10个并行的feature开发，每个session的上下文独立，不是因为分工，是因为隔离。这是三省六部之外多agent的另一个合理用途，文章没有讨论到。
三、关于gstack的质疑
@章鱼哥（@ockevin331）直接点名：
"gstack不就是三省六部制么"
这个质疑值得正面回答，因为我自己在用gstack。
gstack的角色命名确实是三省六部式的——CEO、Eng Manager、Designer、QA Lead，标签非常明显，@章鱼哥的观察没有错。
但我拉了gstack的提示词来看，执行机制和三省六部有关键差异：
信息流转走的是原文，不是摘要。 plan-ceo-review的提示词明确要求直接读取/office-hours产出的设计文档原文，用它作为"source of truth"，而不是由上一个skill转述给下一个skill。
大多数skill在同一个Claude Code实例内顺序执行。 是同一个执行者在不同阶段加载不同的专业视角，角色标签是当前视角的切换，不是不同agent之间的工作交接。有两个已知例外：/autoplan会通过codex exec调用独立的Codex CLI进程做review，/pair-agent支持跨agent协调——但这两个场景传递给外部进程的仍然是原始文件，不是摘要。
共享状态存在文件系统里，不在agent之间传递。 ~/.gstack/projects/是所有skill共享的持久状态，每个skill直接读取，没有中间转述层。
所以gstack的问题更多是命名误导了架构意图——CEO/QA这些标签让人以为是三省六部，但底层机制绕过了压缩接棒。这反而验证了文章的一个论点：命名比架构更容易误导人，给agent贴角色标签本身就会产生错误的心智模型。
不过我要承认：gstack有没有其他层面的问题，比如skill之间的信息传递是否足够干净，还需要更多实际使用后的数据才能判断。现在不能说它完全没问题，只能说它没有犯文章批评的那个具体错误。
四、我不打算让步的地方
"三省六部有管理/审计价值"
@一介书生说（@Jacky_Zhang01）：
"三省六部制是管理的需要，不是效率的需要，是关键核心控制。"
@xiaojing（@flystar32）也说：
"在比较复杂的企业级后端应用系统，给每个Agent配置不同的权限策略，这个还是需要一个类似于PM、RD、QA这样的role与权限与之对应的。"
这个说法成立，但它在论证另一件事：如果你的目标是管理可控性和可解释性，三省六部有它的价值。但这和"三省六部在工程上是否产生最优结果"是两个问题。你可以用它，只要对自己诚实——这是管理决策，不是架构优化，接受它带来的推理链断裂作为代价。
"三省六部在任务复杂度足够高时会有优势"
@Yuting（@zhangyutingzyt）说：
"当下agent接触的任务复杂度还是太低了，而且特别局限在coding，因此人类还没意识到分工的优势而已"
这是一个我无法用现有数据反驳的观点，但我也没有理由接受它。目前三家厂商面对最复杂的工程任务（SWE-bench Pro、25小时不间断coding），没有一家选择了职能性分工来解决上下文问题。这不是证明分工一定错，但它是一个反向信号。如果分工在高复杂度下有优势，应该能看到实验数据，目前没有。
"这几家不用三省六部是因为太复杂，不是因为不对"
@L.W（@LW_1001）：
"这几家没有采用三省六部，不是因为这个不好，而是太复杂。起码在当前阶段太复杂，所以不适合。当前的主要任务还是先做好核心。"
这个降维反驳很聪明，但"太复杂到无法稳定实现"本身就是反对它的理由。如果一个架构在当前工程能力下无法可靠落地，选择它的成本已经超过了它的潜在收益。
五、一个被评论区推进的新问题
@backfire（@studyouwei）分享了一个真实案例：
"我之前做一个智能留学规划，里面按角色分成了不同的子智能体，结果主智能体在任务分发的时候失败率得有50%，子智能体的协作也根本跑不起来。最后我简化成只有一个智能体，其余的都配成工具，一下子就可以丝滑跑起来了。"
这个案例里有一个值得独立讨论的设计原则：能用工具解决的，不要用agent解决。子任务如果是确定性的、可以封装的，把它变成工具比把它变成agent在几乎所有维度上都更优：更快、更稳定、更容易调试、上下文消耗更少。
多agent的使用场景应该被严格限制在：任务边界无法在执行前确定、需要模型自主决策下一步的情况。其他情况，工具是更好的答案。
写在最后
真正的问题不是"有没有角色标签"，而是"信息在流转时传的是原文还是摘要"。前者是表象，后者是机制。只要保证下一个执行节点读的是原始信息而不是上一个节点的理解版本，角色标签本身不是问题。
感谢所有认真回复的人，尤其是 @BinaryHB、@万物燃烧、@Tetsu、@backfire、@luke_bit——这几条评论推进了我的思考，不只是确认了我的观点。
这篇回应文章同步发布于 sagasu.art