分解不是一项安全属性

63.97%，在一场仿真山火里

2026 年 9 月 10 日，Zhengran Ji、Jonathan Hyun 与 Boyuan Chen 贴出了近期支持「用许多窄角色而不是一个大角色来搭建智能体系统」的最强论据。ORCH（arXiv 2609.11737v1，预印本）报告：在 CREW-Wildfire 环境的 25 项仿真山火响应任务中，最多 50 个异构智能体、八个大语言模型，人工设计的组织相比此前四套具身多智能体框架，最终得分高出 63.97%，执行效率高出 74.29%。比较沿四条轴：任务结果、执行效率、探索，以及计算资源用量。由模型给自己设计的组织，做到 43.63% 与 52.53%。

起作用的机制是一种结构，不是一个模型：ORCH 为每项任务构建专属的层级组织，"by combining pooled interdependence for work that can proceed concurrently with sequential interdependence for work governed by prerequisite relationships"，即把可以并行推进的工作按池式相依来组织，把受前置关系约束的工作按顺序相依来组织。给正在核算模型预算的人再补一句："Notably, collective performance was not monotonically determined by model scale."，即值得注意，集体表现并不由模型规模单调决定。

有一个词一直在承担重量。CREW-Wildfire 是一个仿真器：火情 "evolves dynamically through a cellular-automata process"，即经由元胞自动机过程动态演化；四类智能体是仿真车辆——消防员、推土机、无人机与直升机；作者贡献声明写的是 "Z.J. and J.H. designed simulations and performed experiments"，即 Z.J. 与 J.H. 设计仿真并执行实验。在论文渲染出的 HTML 里，physical robot、real robot 与 hardware 这几个字符串一处也没有出现 [推断——计数是我们做的，缺席是论文自己的]。标题里的 "Embodied"，指的是仿真的具身。63.97% 是一个关于组织的真实结果。它不是一个关于机器人的结果。

本文的论点如下。窄角色买到两样值得付钱的东西：能力，ORCH 测的就是它；以及可归因——出了事，你能点名是哪个智能体做的。它们买不到安全。说它们能买到安全的已发表证据，介于稀薄与没有之间；证据真正支持的是另一个名词：外置（externality）——一项行动者自己写不了的检查，坐在被检查对象之外。凡是有效的安全结果，改变的都是这个变量，而不是图上方框的数量。我们自己的 Crew 页面直到 2026 年 9 月 11 日还挂着那个较弱的版本；最后一节讲的就是改了什么。

这里的四篇论文，三篇不是楼里的机器人，第四篇根本不是机器人——ORCH 是山火仿真器，CoCoBench 是家居仿真器，MAST 是七套软件智能体框架，ChannelGuard 是一条没有任何具身的大语言模型流水线——而且每一篇都是预印本。它们共有的是被测的拓扑：一个规划器、若干工作者、一个校验器，以及它们之间的跳。没有人在楼里的一台机器上做过这个实验，我们也没有。

每一跳都是一条通道

ChannelGuard（arXiv 2607.19430，2026 年 7 月 20 日首发，本文引用 2026 年 8 月 10 日的 v2，预印本），作者 Hossain、Nipu、Faria、Ornee 与 Sheikh，摘要开头的那句话就是本文的组织轴线：

"Multi-agent LLM applications chain a planner, worker agents, a verifier, and a synthesizer, and every hop between agents is an unmonitored channel through which an adversary can smuggle instructions."（多智能体大语言模型应用把规划器、工作智能体、校验器与合成器串成一条链，而智能体之间的每一跳都是一条无人监视的通道，对手可以借它夹带指令。）

剩下的意思由标题补齐：Safe Models Do Not Compose into Safe Multi-Agent Systems，安全的模型组合不出安全的多智能体系统。分解不会消除攻击面；它制造攻击面，一道边界一道边界地制造。把「规划器加工作者」的图画出来，数一数箭头。每一支箭都是一个接口：有一种格式、一个信任假定，没有观察者。

这篇论文自己的防御，恰好说明给一条通道加关口买到了什么、买不到什么。在一次 2,100 条轨迹的评测里——八类攻击、五种防御、三个模型后端：Azure GPT-5、Anthropic Sonnet 4.5 与 Anthropic Haiku 4.5——ChannelGuard 的工具输出关口在应用层把工具投毒挡下 30 次中的 30 次，三个后端结果一致；把提示注入的攻击成功率从 0.333 减半到 0.167；GSM8K 准确率保持在 0.867，一点没动。然后，同一段摘要里："White-box adaptive paraphrase evades every embedding gate, where a perturb-and-vote baseline does better."，即白盒自适应改写躲过了每一个嵌入关口，而一个扰动投票的基线反倒做得更好。后半句是作者在报告：面对那种攻击，自己的防御不是最好的。这就是本文其余部分必须达到的标准。

各个部件，列一次，然后放到一边规划器 · 校验关口 · 指定人员 · 视觉语言动作策略 · 控制器 · 执行器 · 机器人自身的安全功能，一条任何模型输出都触及不到的确定性链路，也是真正承担物理安全的东西 · 受治理的现场记忆，核心与短期 · 位于 Open-RMF 或 RoMi-H 机群适配器之后的其他厂商机器人 · 作为工具调用的现场自有系统 · 审计日志。

经过关口的跳

规划器 → 校验关口：一个提议的动作五项已公布的检查，归另一篇文章所有，本文不描述。被驳回时不下发任何指令，机器人保持其安全状态，驳回连同未通过的那项检查一起返回。

校验关口 → 指定人员：任何有后果的动作由一个系统里谁也写不出来的人批准，否则不放行。

机器人 → 核心记忆：一项提议的修改机器人提议，指定人员批准。核心记忆没有别的改法。

校验关口 → 视觉语言动作策略与控制器：下发任何东西抵达执行器的唯一路径，也是这道关口值得存在的全部理由。

四跳。每一跳都由一个没有写出被检查内容的东西来检查。

什么都不经过的跳

现场系统 → 规划器：工具输出码头操作系统、仓储管理系统、医院信息系统，作为工具被调用。这正是 ChannelGuard 的工具输出关口所要覆盖的那条通道。

机器人 → 短期记忆：语义观测流带位姿与时间的观测，由机器人写入。在下一个规划器读取之前，没有任何东西检查这次写入。

短期记忆 → 规划器：现场的当前状态一台机器人写下的堵塞，下一台机器人据此规划。读取不经校验；被校验的只是规划器在那之后提出的东西。

第三方机器人 → Crew：位姿、状态、行程、失败原因码另一家厂商的软件，经 Open-RMF 或 RoMi-H，断言自己在哪里、在做什么。调度建立在这些断言之上。

Crew → 第三方机器人：一项下发的任务对方厂商的技术栈拿它做什么，按构造就在我们的关口之外。

机器人 → 机器人：经共享记忆中介的跨本体交接一个料箱在电梯厅从一种本体交到另一种本体手上。这件事的两半都已由其他团队发表；交集从未被任何人计过时，我们也没有。

六跳，就在我们自己公布的设计上。

• 发送方之外有东西在检查的跳——校验器，或指定人员
• 一条裸跳：一个接口，有一种格式、一个信任假定，没有观察者
• 各个部件，本图有意只当作记账

边界产生什么

《Why Do Multi-Agent LLM Systems Fail?》（arXiv 2503.13657，v1 2025 年 3 月 17 日，v3 2025 年 10 月 26 日，预印本）是这个领域的故障清单。加州大学伯克利分校的 Cemri、Pan、Yang、Ion Stoica 及同事以这个前提开篇："Despite enthusiasm for Multi-Agent LLM Systems (MAS), their performance gains on popular benchmarks are often minimal."，即尽管人们对多智能体大语言模型系统热情很高，它们在常用基准上的性能增益往往微乎其微。他们的分类法 MAST 给出 3 个类别下的 14 种模式，从 150 条轨迹提炼而来，标注者间一致性 κ 为 0.88，随后应用于来自七个开源框架——MetaGPT、ChatDev、HyperAgent 与 AppWorld 在其中——的 1642 条标注执行轨迹，任务覆盖编程、数学与通用智能体任务。这七个框架的失效率从 41% 到 86.7%。

三个类别之一，FC2 智能体间失调（Inter-Agent Misalignment），占了十四种模式里的六种。论文的定义是："Failures arise from a breakdown in critical information flow from inter-agent interaction and coordination during execution."，即失效源于执行过程中智能体间交互与协同的关键信息流的中断。只有一个智能体的系统没有智能体间交互。这个类别在多于一个智能体之前不可能存在，而它的六种模式合计占标注失效的 32.35% [推断——我们对论文自己逐模式数字的加总]。

这个说法在类别层面成立，往下就不成立了。诚实的版本要点出那个反着切的模式。FM-2.6 推理与行动不一致，是 FC2 里最大的一种，占标注失效的 13.2%，而论文对它的定义完整地落在单个智能体之内："discrepancy between the logical reasoning process and the actual actions taken by the agent"，即智能体的逻辑推理过程与实际采取的行动之间的不一致。FM-2.1 对话重置与 FM-2.2 未能请求澄清，一个智能体对着一个人也能表现出来。十四条模式定义里，正文点名另一个智能体的恰好三条——FM-1.2、FM-2.4 与 FM-2.5 [推断——我们对论文附录 A 的读法]。「分解制造了多少种失效模式」没有一个诚实的计数。谁被递上一个数，都该问是哪几种，然后去读它们的定义。

CoCoBench（arXiv 2608.28266v1，2026 年 8 月 28 日，预印本）之所以存在，正是因为头条数字会把这类故障藏起来：897 个经 oracle 校验的可执行家居任务实例，围绕四种协同构件——任务分配、顺序次序、互斥与交接协同——在 11 个多模态大模型上测。作者写道，多数基准 "summarize multi-agent behavior with overall task success rates, which can obscure coordination failures such as duplicated work, violations of ordering constraints, resource contention, and desynchronized handoffs"，即用总体任务成功率来概括多智能体行为，而这会掩盖重复劳动、次序约束违规、资源争用与失步交接之类的协同失效；他们还发现 "strong overall performance does not imply balanced competence across different coordination types"，即总体表现强，并不意味着在不同协同类型上能力均衡。这几类故障都有物理形态——重复劳动是两台机器伸手去拿同一个料箱，失步的交接是东西还没有被接住就已经松手 [推断——该基准是家居仿真器，走廊上的读法是我们的]——而一支机群按周平均出来的成功率，把它们与一个糟糕的日子一个也分不开。

这些都不能把 MAST 读成对这种模式的控诉，论文自己也小心地说明了这一点："MAS failure is not merely a function of challenges in the underlying model; a well-designed MAS can result in performance gain when using the same underlying model"，即多智能体系统的失效不只是底层模型难题的函数；在同一个底层模型上，设计良好的多智能体系统可以带来性能增益——仅靠改进智能体的角色规范，ChatDev 的成功率就提升了 +9.4%。结构值得下功夫做。它不是一项安全论证。

• FM-1.1 违背任务规范 — 11.8 % — FC1 系统设计，5 种模式
• FM-1.2 违背角色规范 — 1.5 % — 定义中点名另一个智能体
• FM-1.3 步骤重复 — 15.7 %
• FM-1.4 丢失对话历史 — 2.8 %
• FM-1.5 不知终止条件 — 12.4 %
• FM-2.1 对话重置 — 2.2 % — FC2 智能体间失调，6 种模式
• FM-2.2 未能请求澄清 — 6.8 %
• FM-2.3 任务偏离 — 7.4 %
• FM-2.4 隐瞒信息 — 0.85 % — 定义中点名另一个智能体
• FM-2.5 忽视其他智能体的输入 — 1.9 % — 定义中点名另一个智能体
• FM-2.6 推理与行动不一致 — 13.2 % — FC2 中最大的一种，定义在单个智能体之内
• FM-3.1 过早终止 — 6.2 % — FC3 任务校验，3 种模式
• FM-3.2 无校验或校验不完整 — 8.2 %
• FM-3.3 校验错误 — 9.1 %
• FC2：由智能体间交互定义
• FC2 中最大的一种，且是单智能体的
• FC1 与 FC3：不需要第二个智能体

没有人定价的成本

对这件事的成本，我们找到的唯一一家公布数字的厂商是 Anthropic，在一篇 2025 年 6 月 13 日的工程文章里 [单一来源——厂商工程博客报告厂商自家的内部评测，对象是一个研究助手，未经同行评审，也不是机器人]。以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，在那次评测中比单智能体的 Claude Opus 4 高出 90.2%。账单："agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats"，即智能体通常比聊天交互多用约 4 倍的 token，多智能体系统比聊天多用约 15 倍。在 BrowseComp 上，仅 token 用量一项就解释了 80% 的性能方差——它是合计解释 95% 的三个因素之一，每当那个 80% 单独出行时，都该带着这个框架。

同一篇文章点出了不适合大范围扇出的工作形态："some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For instance, most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time."，即有些领域要求所有智能体共享同一份上下文，或者智能体之间存在大量依赖，今天并不适合多智能体系统；比如大多数编程任务里真正可并行的部分比研究少，而大语言模型智能体在实时协调与委派其他智能体这件事上还不擅长。一趟病房配送与一轮卫生间清洁都是这种形态：一张地图、一份现场状态、一幅病人在哪里的图景，以及取、走、交、记之间的严格次序 [推断]。按厂商自己的标准，这是不适合一支宽团队的形态，是适合一支固定的小团队站在单一校验器之后的形态。Anthropic 从未对机器人说过任何话；标准是他们的，走廊是我们的。

安全论证究竟落在哪里

五项结果从五个互不相关的方向汇聚到一处。没有一项是关于你有几个智能体的论证。

ChannelGuard 把关口放在智能体之间的通道上，而不是任何一个智能体的内部。MAST 的第三条洞见标题是 Multi-Level Verification is Needed（需要多层级校验），它的框架是检查的阶段与层级，不是角色的编排："Current verifier implementations are often insufficient; sole reliance on final-stage, low-level checks is inadequate."，即当前的校验器实现往往不够；只依赖最后阶段、低层次的检查是不充分的。把它读成一项关于「检查相对行动者坐在哪里」的结果，是我们的读法 [推断]，也是这里五项汇聚中最弱的一项。

第三项是细心的读者会拿来反驳本文的那一项，也是这个领域里最好的结果。SafetyALFRED（arXiv 2604.19638v1，2026 年 4 月 21 日，也是本文中唯一一项通过了评审的结果——其 arXiv 备注记录它被 ACL 2026 Findings 接收），作者 Torres-Fonseca、Deng、Dai、Storks、Zhang、Mihalcea、Kennington 与 Chai，在 §6 提出 "a multi-agent framework that decouples hazard recognition from mitigation, offloading safety reasoning to a dedicated judge that feeds safety insights to the embodied agent"，即一个把危害识别与危害处置解耦的多智能体框架，把安全推理卸载给一个专门的裁判，由它向具身智能体提供安全提示；并报告 "Qwen 3 VL 32b's accuracy in mitigating appliance misuse hazards jumps from 0.7% to 71.1% when provided the safety judge's response"，即得到安全裁判的回复后，Qwen 3 VL 32b 处置家电误用危害的准确率从 0.7% 跳到 71.1%。这是一次分解在具身基准上改善了安全指标，任何诚实版本的本文论证都必须给它留位置。

有五件事跟它一起走。环境是 ALFRED 家居仿真器。作者自己的摘要说这个框架 "slightly improving performance but not entirely resolving this misalignment"，即略微改善了表现，但没有完全解决这种失调。多数危害在裁判之下仍然存活——"many hazards remain unmitigated even when the judge provides a correctly identified hazard"，即即便裁判给出了正确识别的危害，许多危害仍未被处置；有元数据时，同一个模型识别危害的准确率是 57.2%，处置掉的是 32.5%。还有 §7："Even in our controlled and significantly simplified simulated environment, there is a huge performance gap between QA tasks and mitigation tasks."，即即使在我们受控且大幅简化的仿真环境里，问答任务与处置任务之间也存在巨大的性能差距。而且裁判并非处处有帮助：论文表 3 里，加上裁判之后，同一个模型对火灾危害的处置率从 71.2% 降到 43.7%，对不卫生危害的处置率从 24.3% 降到 8.1%，两者都在 p < 0.01 的水平上显著，而平均值从 19.7% 升到 32.5%。

盯着变量读，它就不再是反例。两个实验臂之间变的不是智能体的数量，而是安全推理者坐在行动者之内还是之外。作者自己的假说是任务干扰——"the model's focus on completing the goal potentially diminishes the attention allocated to environmental monitoring"，即模型对完成目标的专注，可能削弱了分配给环境监视的注意力。一个为完成而优化的规划器会停止观察，而一个在它之外的裁判，把同一个模型本来就知道的东西找回来了一部分。

第四项看起来最像硬件结果，也是对本文任何草率版本最有力的反驳。《Managed Autonomy at Runtime》（arXiv 2607.00334v1，2026 年 7 月 1 日，预印本）报告 99.6% 的异常检测率，对单智能体基线的 2.1%，在一个仿真的三智能体 UR5 装配单元上跑了 10,000 个蒙特卡洛回合：好 47.7 倍。它自己的结果表说清了这是一个关于什么的结果：物理碰撞率，基线 0.0%，受治理的运行时 0.0%。改善的是异常检测，以及检测时延，从 43.1 个 epoch 降到 12.2；受治理的那一臂买到的，是急停率从 0.0% 升到 9.8%。这个对照也不是分解对单体。它是一个坐在智能体之下的治理运行时，对没有治理运行时。引 99.6% 而不引碰撞那一行，正是本文反对的选择性阅读——而作者也不许这一行往另一个方向被草率地读："Equal collision rates do not imply equal safety guarantees"，即相等的碰撞率不意味着相等的安全保证，因为在基线之下 "zero collisions is an artefact of the UR5 telemetry architecture: encoder control is unaffected by camera drift"，即零碰撞是 UR5 遥测架构的一个人为产物：编码器控制不受相机漂移影响。

第五项是唯一有一条真实机械臂在里面的，而它是一道护栏，不是一个团队。RoboSafe（arXiv 2512.21220，v1 2025 年 12 月 24 日，本文引用 2025 年 12 月 26 日的 v2，预印本）把一个可执行谓词的安全运行时放在单个视觉语言模型驱动的智能体之外——护栏 "treats the embodied agent as a black-box system"，即把具身智能体当作黑箱来对待——并报告在三个仿真具身智能体工作流上，相比领先基线，危险动作减少 36.8%。它的 §6 物理世界部分，是在一台由 GPT-4o 控制的六自由度 myCobot 280-Pi 上做的两项任务案例研究：机械臂拿起刀或木块之后停住了后续动作；硬件上没有任何比较性的安全数字。一个智能体，一项在它之外的检查：变的仍然是外置，智能体的数量没有动。

于是，那个否定句，连同它的边界，一口气说完。截至 2026 年 9 月 11 日，以六种查询表述在 arXiv API 的摘要与全文字段检索，外加一次网络搜索，我们没有找到任何已发表的结果报告「把一套智能体系统分解为窄智能体，减少了真实机器人硬件上的物理安全事故」；每一个返回的候选都读了摘要，最接近的两篇读了正文。没有检索的：IEEE Xplore、ACM Digital Library、Scopus、Web of Science、Google Scholar、PubMed、未镜像到 arXiv 的会议论文集、非英语文献、制造商的内部安全报告，以及标准机构的技术报告。arXiv 加一次网络搜索，就是语料库，也就是这个说法的边界。六种查询表述并不穷尽 arXiv：2026 年 9 月 12 日的第二遍检索，两次网络搜索，找到了那六种表述漏掉的另外三篇 arXiv 候选——上文的 RoboSafe、2606.31339 与 2604.20193——没有一篇报告了那个结果。

一个在相反答案上有利害关系的团队，把同一件事说得更有用。AEROS（arXiv 2604.07039，v1 2026 年 4 月 8 日，本文引用 2026 年 5 月 25 日的 v3，已投稿期刊的预印本）主张单智能体架构，却仍然承认："A rigorous empirical comparison between single-agent and multi-agent architectures on the same task remains an important open question."，即在同一任务上对单智能体与多智能体架构做严格的实证比较，仍是一个重要的未决问题。没有人在证据上赢下这一局，包括想赢的人。

这就回到了我们自己的页面。直到 2026 年 9 月 11 日，「一个智能体，一项窄任务。一个团队，一个结果。一个人，一次最终批准。」还挂在 Crew 页面一个写着安全设计的标题之下。它现在位于团队如何编排之下，紧随其后的那一段把它归入能力，然后下一段才开口：「这不是一项安全论证，我们也不该把它当作安全论证来讲。」安全设计现在换了开头——「承担安全论证的不是团队的编排形态，而是那条边界。」同一页上的 ORCH 引用，一天之后，9 月 12 日，才补上它的仿真限定。Crew 仍在开发中，用页面自己的话说，「没有在任何现场运行」：我们没有在任何一台机器上测过任何东西，本文里没有一个数字是我们的。

给正在被递上这类图的人：团队的形态回答的是一个能力问题，在其他任何地方它都是一张组织架构图。能触到安全论证的问题是：哪些检查是行动者自己写不了的，每一项检查相对被检查对象坐在哪里，以及中间那些跳有什么在看着。在我们自己的设计上，最外层的检查根本不是校验器，而是机器人自身的安全功能——Crew 页把它留在机器人上，在一条任何模型输出都触及不到的链路里；承担物理安全的是那条链路，校验器坐在它之内。我们公布的那些检查，以及它们所依赖的前提，是另一篇文章的论证，在这里。本文讲的是箭头。