一句话：多智能体把任务做对了，却可能悄悄把「共享状态」搞脏了
9 月底，一篇发表在 arXiv cs.CL 的评估框架戳中了一个被长期忽视的盲区：多智能体系统常常能把眼前的任务答对，却在同一过程中留下被污染的共享状态，而下游智能体正依赖这个状态做后续决策。研究者用 GPT、Gemini、Qwen 在医疗与灾害响应两类场景里测试，结果是——任务准确率能到 65%，但证据核验只有 14%、状态重建只有 43%。换句话说，答案看着对，可支撑它的信息轨迹已经不可信。这对高 stakes 领域是个警讯：我们一直在评「答得对不对」，却很少评「留下的状态干不干净」。
这个失败模式和「答错」不是一回事
过去我们担心智能体「答错」，但这篇框架指出的是另一种更隐蔽的失效：模型产出了正确的即时输出，却把共享状态悄悄污染了。比如一个智能体在医疗场景里更新了某条记录，下游另一个智能体读到的是被改过的、不一致的状态，于是基于错误前提继续推进；灾害响应里，某个 agent 记下的资源状态与真实情况对不上，后续调度就建在沙子上。它不表现为「明显答错」，而表现为「看着没问题，其实地基已经歪了」——这种错误会在连续决策里复利放大，越往后越难察觉。
它和「Lost with a Map」是同一类病根
同一时期另一项研究「Lost with a Map」发现，大模型在任务导向对话里会把 slot 值散落在上下文各处、而不是整合起来，结构上解释了模型为何管不好状态。那篇讲的是「为什么管不住」，这篇框架衡量的是「管不住会带来什么后果」——当多个智能体依赖一份被污染的状态，错误会如何传导。两篇合起来说明：状态管理不是工程细节，而是多智能体系统可靠性的核心。更早的「False Frontiers」还观察到内部信号与外部校验不一致，这里模型过了即时任务检查却没过证据核验，是类似的「表面通过、内部失准」动态。
为什么现有协作 benchmark 会漏掉它
多数多智能体评测聚焦「最终任务有没有完成」，相当于只看了链路末端。但这篇框架指出的是中段与后段的失效：即便末端看起来成了，中间留下的状态可能已经脏了，而后续决策正吃这份状态。只评末端的 benchmark，天然看不见这种会在连续决策里复利的失败模式。也就说，我们用「单步答对率」当健康指标，实际上该补上「状态可信度」这一维——证据能不能核验、状态能不能重建，才是高 stakes 部署真正该盯的数字。
辩证看：样本有限，但方向值得记
应当如实标注：这篇测试只覆盖 GPT、Gemini、Qwen 三个模型，场景集中在医疗与灾害响应，是否泛化到更开放的协作任务，仍需更多证据。它也没有给出一套现成的修复方案。但价值恰恰在「把问题命名出来」——一旦业界意识到「任务答对 ≠ 状态干净」，评测、日志与恢复机制就会朝「可验证的信息轨迹」补位。对做多智能体产品的团队，这提示一个务实动作：给每个 agent 的产出加证据链与状态校验，而不是只信最终输出。
增量认知：评测重心要从「单步答对」转向「状态可信」
这篇框架给多智能体赛道补了一块拼图：可靠性不只看单个 agent 聪不聪明，更看整条链路留下的状态干不干净。对医疗、应急、金融这类错一步就牵动真事的领域，下游决策依赖的是可靠的信息轨迹，而非只是漂亮的答案。把「状态可信度」纳入评测与线上监控，会是接下来多智能体从演示走向生产必须补的一课。
结语
多智能体让人兴奋的是「一群 agent 协作能把大事拆了做」，但协作的前提是大家读的是同一份没被污染的状态。这篇框架提醒我们：别被单步的高准确率骗了，真正该盯的，是链路留下的状态到底干不干净。