9 月 29 日提交的论文 PANDA: A Decentralized Architecture with Flexible Orchestration for Scalable, Fault-Tolerant Multi-Agent Systems（arXiv 2609.38482）直指多智能体系统工程里最不起眼也最要命的一层：当智能体数量涨到上千、任务并发且随时会掉线，现有架构往往既扩不动、也扛不住故障。PANDA 给出的答案是一套去中心化架构——让大量异构、各自管理的智能体互相发现、按任务自组小队，并在故障出现时动态重规划。
背景：多智能体系统的扩展性天花板
近一两年，多智能体推理框架层出不穷，但多数停在「几个模型协作解一道题」的规模。真要把智能体铺到生产，面对的是另一番景象：成百上千个归属不同团队的智能体、并发的异构任务、随时发生的网络与编排故障，还要在它们之间管住交互边界。现有架构在这几件事上普遍吃力——既难支撑大量智能体与并发任务，也难在失败时恢复，更别说在去中心的前提下做治理。PANDA 把这些问题当成设计起点。
架构：集体通信与团队通信解耦
PANDA 的核心设计是把集体通信与团队通信分开。集体层让大量异构智能体互相发现能力、自组织成小队；团队层才是具体任务里的协作。一个智能体可以同时参加多支小队，任务在集体间负载均衡，每支小队内部再按需求选择星型、链式或网状三种编排模式之一。关键的是，架构与编排策略分离——换任务结构不必改底层。治理上它用信任网模型约束交互，避免为了可管而塞一个中心服务进来，从而保住去中心带来的扩展性与韧性。
实测：规模、速度与容错一起给
在 HotPotQA 上，PANDA 能扩到上千个智能体、毫秒级拉起一支小队，在保持精度的同时拿到最高 8 倍效率；当基础设施与编排同时出故障，它通过动态重规划维持 100 的任务完成率，而对比系统在同一故障下直接失败。这组数据指向的恰恰是生产里最怕的两种情况：规模一上来就慢、一个环节挂了就全崩。PANDA 把这两道坎都尝试用架构手段接住。
为什么值得写：韧性是被忽略的基础设施
把这篇和智能体落地主线连起来看，它的增量不在又提出一个协作花活，而在把「韧性」当成一等公民。多数框架把注意力放在怎么让 agent 更会推理，PANDA 提醒我们：当智能体进入长时间、跨系统、多归属的生产环境，恢复、状态一致与可观测，会比单点聪明更决定成败。尤其是信任网治理那条线，给「去中心也不失控」提供了一个可落地的思路，对跨组织、跨团队的智能体协作尤其有意义。
边界：基准是问答任务，生产另有现实
需要冷静看待的是，论文验证集中在 HotPotQA 这类问答基准，故障也是受控注入，不等于真实企业里那些非结构化、长链路、带人工审批的工作流。把一个智能体掉线、一个 API 限流、一次权限变更都考虑进来，工程细节会复杂得多。对选型方更实在的建议是：把 PANDA 当作「去中心化容错」这一方向的参考实现，重点借它的分层与重规划思路，而不是直接期待一套能套进手头系统的成品。值得记下的一个取舍是：去中心换来扩展与韧性，也换来治理与可观测性的新负担——信任网虽免去中心服务，却要把「谁可信」这件事显式建模进系统，这对跨组织协作尤其关键。
结语
PANDA 给多智能体系统的提示，不在于又多了一种编排花样，而在于它把扩展性与容错从「出了事再补」提前成了架构约束。当智能体的数量与自治程度同步上升，谁能把故障当成常态而非意外，谁的系统才可能在生产里真正立住。