多智能体系统跑顺了之后，一种隐蔽的故障开始浮现：系统没报错、任务也「完成」了，但复盘时发现活没人好好干，或者干错了没人认。研究者给这类现象起了个形象的名字——角色坍塌。它指的是子智能体在协作过程中，职责边界慢慢糊掉。
三种典型症状
其一是抢活：两个子智能体都觉得某一步该自己负责，于是对同一块工作重复投入，结果要么打架、要么双写。其二是越界：某个智能体伸手碰了本不属于自己职责域的数据或工具，比如读了别的角色的私有状态、调了越权的接口。其三是甩锅：任务一旦失败，各方都「以为对方兜底」，责任找不到主，复盘会上集体沉默。三种症状常常同时出现，因为根子是同一个人。
根子常在于职责契约太模糊。很多系统只分了「角色名」——你做规划、我做执行、他做校验——却没写清每个角色的输入输出边界、可调用工具清单、以及绝对不能碰的东西。角色重叠区越大，坍塌越容易发生，因为那里既是人人可进的红利区，也是出事后的无人区。当系统规模从几个智能体涨到几十个，靠默契维持的边界会迅速失效。
怎么治
治法是把契约显式化：谁负责什么、产出什么格式、能碰什么、不能碰什么，都写成协议而非靠默契。再配一个中心或共识式的冲突仲裁，当两个角色同时伸手时由它裁判归属。把「谁该兜底」写进协议，甩锅就失去了土壤。有意思的是，它和拍卖式协调能天然配合——中标契约本身就规定了中标者的职责边界，反而是防止坍塌的一道现成护栏。冲突仲裁的判定依据，也可以直接复用出价与履约记录。
为什么值得单列成一类故障
角色坍塌和「协调成本高」是两码事。成本高是可优化的指标，加机器、调路由都能缓解；坍塌是正确性问题，一个能跑但责任无主的团队，比慢一点但责任清晰的团队更危险，因为错误无法定位、无法归责、也无法在下次避开。把角色坍塌当作一类独立的故障模式来测、来防，是多智能体走向生产的必修课，而不是锦上添花。测它的方式也不复杂：在协作任务里埋入职责冲突点，看系统能否识别并交给正确角色，而不是让两个角色在重叠区里空转或互踩。
值得提醒的是，角色坍塌和「智能体变笨」是两件事，不能混为一谈。模型单步答得再对，只要职责边界模糊，协作照样会塌。所以诊断时要把「能力问题」和「契约问题」分开：前者靠换模型或加训练，后者靠改协议与仲裁。把两类故障混在一起治，往往两头都不讨好。先分诊，再开方。
从组织视角看，角色坍塌还暴露了一个管理误判：很多人以为「多派几个智能体」等于「更稳」，于是无脑堆角色。事实恰恰相反，角色越多、边界越没写清，坍塌概率越高。与其加角色，不如先把现有角色的职责契约钉死，再谈扩编。协作系统的可靠性，常常不来自数量，而来自边界的清晰度。