文章总结： 本文揭示多智能体系统中第三方Agent描述文本成为新攻击面，攻击者可在注册阶段注入恶意载荷影响Planner决策，无需调用该Agent即可生效，任务成功率从84.31%跌至37.25%。研究提出三类八种攻击策略，验证攻击跨模型框架普适。防御核心是接口约束而非恶意检测，建议企业将描述文本纳入审查范围并监控规划异常模式。 综合评分： 85 文章分类： AI安全,漏洞分析,安全建设

当 Agent 描述沦为注入通道：一份恶意简历如何污染多智能体任务

原创

蜜罐先生 蜜罐先生

大模型安全研究

2026年9月25日 20:30 江西

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

今天介绍一个智能体新的风险点：那个第三方 Agent 的描述文本上。

一篇来自 arXiv 的论文《Misleading the Planner through Deceptive Resumes: Registration-Time Injection in Centralized Multi-Agent Systems》系统性地揭示了这个新攻击面。研究团队发现，在集中式多智能体系统（MAS）中，一个精心构造的第三方 Agent 描述文本可以在注册阶段向 Planner 注入攻击载荷，且该 Agent 永远不需要被调用，攻击就已经生效。最严重的情况下，任务成功率从 84.31% 跌至 37.25%，Token 消耗最多增加 111.93%，执行时间最多增加 111.98%。

这项研究的意义在于：它揭示了多智能体系统中一个被长期忽视的信任边界。攻击载荷不来自用户输入，不来自检索内容，不来自工具输出。它来自一个看似无害的 Agent 描述，在系统运行的任何业务逻辑启动之前就已经埋下。

为什么这项研究值得关注

集中式多智能体系统已经成为 LLM 应用的主流架构之一。AutoGen、Magentic-One、OWL 等框架都采用 Planner + Workers 的组织方式：一个专门的 Planner 负责理解用户请求、分解任务、分配执行者，多个 Worker 各自负责执行具体的子任务。

这个架构的核心信任假设是：Planner 读取的 Worker 描述文本是可信的。Planner 需要知道每个 Worker 能做什么、接受什么输入、产出什么输出，才能做出合理的任务分解和分配决策。这些信息以自然语言描述的形式进入 Planner 的上下文，不经任何清洗和隔离。

但问题在于，第三方 Worker 的描述文本是在系统外部编写的，却在系统内部被当作可信的规划输入来消费。Google Cloud Marketplace 和 AWS Marketplace 已经开始大规模分发这类 Agent，A2A 协议用所谓的 “Agent Card” 来承载名称、描述、服务端点和技能。平台会审查 Agent 的实现和合规性，但没有任何审查标准能够排除一个宣称”覆盖广泛”或”高度可靠”的描述文本。

这和传统提示注入的根本区别在于四点。第一，攻击载荷在任何用户指令到达之前就已植入，一次注册影响所有后续请求。第二，攻击目标不是某个 Worker，而是所有 Worker 都依赖的 Planner。第三，影响通过生成的 Plan 传播到良性 Worker，在第一次通信发生之前攻击就已经完成。第四，这个通道位于隔离、沙箱、权限调解、运行时监控等所有现有安全机制的上游。

研究团队还分析了三个主流 Agent 市场（GPT Store、Coze、百度文心）的 32,000 条描述，发现了一个更令人不安的事实：至少 89.73% 的描述缺少输入规范，至少 94.61% 缺少使用约束，而至少 23.35% 包含不属于接口定义的内容。这意味着恶意描述在真实市场中并不会显得突兀。攻击者的精心构造可以完美融入市场的主流风格。

核心发现

发现一：攻击者不需要让自己的 Agent 被调用

这是论文最具冲击力的结论。在几乎所有攻击实验中，PostgresManager（注入源）根本没有出现在任何生成的计划中。攻击载荷存在于其描述文本中，但 Planner 读取之后，影响完全体现在其他 Worker 的任务分配和规范上。

以论文中的一个案例为例：一个 GAIA 任务要求计算两个编码器的层数差异。基线计划分配给 WebSurfer 两个检索子任务，将最终比较交给 Reasoner。在 Agent 排除攻击下，WebSurfer 完全消失，检索和计算全部被推给 Reasoner。在过度碎片化攻击下，3 个子任务被拆成 7 个，包含外部验证、证据核对、数值检查等冗余步骤。而 PostgresManager 在所有这些攻击后的计划中都不存在。

这个模式解释了为什么传统安全机制无法拦截此类攻击：攻击载荷从未到达任何执行环境，它只在 Planner 的上下文中发挥了一次作用，然后通过 Plan 的结构性偏差传导到无辜的 Worker 身上。

发现二：三类八种攻击策略的系统性影响

论文将攻击按影响的规划决策维度分为三类，每类包含若干具体策略，总计八种。

任务结构化攻击瞄准 Planner 对任务的分解方式。其中：

• 过度碎片化将平均子任务数从 2.00 推到 6.30，执行时间增加 111.98%，但 Token 消耗仅增加 2.90%。执行时间暴涨而 Token 消耗几乎不变，说明额外成本主要来自更长的执行链和协调开销，并非子任务内部更重的计算。

• 欠分解将子任务数砍半到 1.00，Token 消耗和时间分别下降 32.05% 和 29.30%，但通过率也从 84.31% 跌到 72.55%。省了资源，坏了结果。

• 依赖破坏最为恶劣：AST 增至 3.89，验证任务比例从 4.72% 飙升至 48.54%（超过基线十倍），Token 消耗增加 111.93%，通过率跌至 56.86%。这是三种策略中通过率最低、Token 消耗最高的一个。

能力锚定攻击瞄准 Planner 将子任务分配给哪个 Worker 的决策。过度分配攻击让 TerminalManager 的参与率从 1.89% 升至 13.21%，同时错配率从 0% 升至 57.14%，意味着超过一半分配给它的子任务超出了其能力范围。Agent 排除攻击则把 WebSurfer 的参与率从 60.38% 压到 3.77%，导致通过率跌至 37.25% 的低谷，Token 消耗下降 87.28%。注意，这个下降不是效率提升，而是系统直接省略了必要的工作。

子任务规范攻击瞄准 Planner 附加到每个子任务上的具体执行指令。过度工作策略使 EER 从 39.62% 升至 54.40%，Token 消耗增加 34.57%，执行时间增加 38.86%，但通过率反而下降 17.64%。中间输出抑制策略使 MIRR 从 19.61% 跳升至 55.56%，相当于切断了依赖子任务之间传递文件路径等关键信息的能力。Planner 先验误导策略在降低 Token 消耗 15.17% 的同时，仍然把通过率从 84.31% 拉低到 74.51%，说明这种攻击让系统”看似更省”却在产出更差的结果。

发现三：攻击的普适性远超单点实验

论文用三组转移实验验证了攻击的稳健性。

在六个不同的 Planner LLM（含 DeepSeek-V3.2、GPT-5、GPT-5-mini、Kimi-K2.5、Qwen3-Max 等）上，所有攻击的方向性变化保持一致：过度碎片化增加 AST，Agent 排除压降 WebSurfer 参与率，过度工作推高 EER。不同模型对攻击的敏感度存在差异，GPT-5 在过度碎片化下 AST 增幅最大，但方向无一例外。

使用四个不同的 LLM 评估器重新评估规划指标，所有评估器都识别出了 DVTR、VIR、EER、MIRR、VCR 的正向攻击变化。估算幅度有所不同，但方向一致。这说明研究结论不依赖于特定的评估器选择。

更重要的是，当把手工编写的 Worker 描述替换为从真实市场收集的描述时，三类代表性攻击仍然有效。在 OWL 框架（基于 CAMEL 的独立 MAS 实现）上重复实验，攻击同样成功，Agent 排除攻击使通过率从 68.60% 跌至 46.00%。攻击不局限于某个框架、某个模型或某批人工构造的描述。

发现四：防御的出路是接口约束，不是恶意检测

论文提出了一个关键的防御理念转变：不要试图检测恶意文本，而要定义描述应该包含什么。

借鉴软件工程中组件接口的思想，研究团队定义了 Worker 描述应提供的四个字段：功能性（能做什么）、输入规范（接受什么输入）、输出规范（产出什么结果）、使用约束（使用条件）。对 32,000 条市场描述的分析显示，大多数描述只声明了功能性，其他三个字段大面积缺失。

但论文强调了一个不对称性：缺失的字段只是让 Planner 信息不足，而接口之外的多余内容才是攻击者的立足点。因此防御的目标是删除接口之外的内容，而不是填补缺失的信息。

基于这个理念，DescGuard 采用三阶段流水线：强调中性化（去除大小写强调、Markdown 标记等表面特征），接口字段提取（仅保留描述注册 Worker 自身的四个字段内容），Worker 范围重述（重写后只为自己发声，去除对 Planner 和其他 Worker 的指令性内容）。每阶段都有独立的 LLM 验证器，并将不可信文本包裹在随机分隔符中以防止边界伪造。

企业与从业者的行动指南

这项研究对正在部署多智能体系统的团队有直接的指导价值。以下建议全部基于论文的发现和 DescGuard 的设计原则推导。

接入第三方 Agent 时，把描述文本纳入审查范围。 当前的审查流程集中在代码和权限配置上，但论文显示描述文本本身就是一个独立的攻击面。审查时至少检查四个维度：描述是否声明了功能边界？是否说明了输入形式？是否定义了输出格式？是否标注了使用条件？如果一个 Agent 的描述只谈能力不谈约束，或者包含明显超出自身范畴的指令性内容，就应该高度警惕。

在注册环节增加描述内容的接口约束或过滤层。 DescGuard 的核心思路可以直接借鉴：在描述进入 Planner 上下文之前，做一次”范围清理”，删除任何不描述该 Worker 自身行为的内容。这个操作不需要修改 Worker 实现、Planner 模型或编排逻辑，可以作为独立的一层接入现有的注册流程。

监控规划结果中的异常模式。 论文中识别出的攻击在规划层面有明显特征：子任务数量异常膨胀或收缩、某个 Worker 的参与率骤降、验证任务比例异常偏高、过度工作指令增多、中间输出要求缺失。企业可以在规划阶段设置统计基线，当这些指标偏离基线超过阈值时触发告警。论文使用的具体指标（AST、APR、EER、MIRR 等）可以直接移植为监控维度。

将注册时防御与运行时安全机制叠加使用。 论文明确指出，DescGuard 与现有的隔离、权限控制、运行时监控机制是互补关系，而非替代关系。注册时防御解决的是”描述说了什么”的问题，运行时安全解决的是”Worker 实际做了什么”的问题。两者的结合才能覆盖从规划到执行的完整链路。

趋势判断与开放问题

这项研究揭示了一个更深层的趋势：随着多智能体系统从实验走向生产，信任边界需要被重新审视。在单 Agent 时代，安全关注点集中在用户输入、检索内容和工具输出。当系统由多个 Agent 协作时，Agent 之间的元数据（描述、配置、能力声明）成为了新的攻击面，而这个攻击面至今缺乏系统和成熟的防护手段。

Agent 市场的快速发展放大了这个问题。当企业从公开市场引入第三方 Agent 时，他们同时引入了那个 Agent 的描述文本，而这份描述文本的作者可能从来就没有考虑过 Planner 会怎样解读它。攻击者已经从”我要让 Agent 执行恶意代码”进化到”我要让 Planner 做出错误的决策”。

留给从业者的开放问题包括：当 Agent 描述的管理权在第三方手中时，企业如何在接入效率和安全控制之间取得平衡？一个经过 DescGuard 清洗的描述是否会失去对复杂能力的精确表达？当 Planner 本身也来自第三方时，这个链条上的信任又该如何建立？

原文标题：Misleading the Planner through Deceptive Resumes: Registration-Time Injection in Centralized Multi-Agent Systems

原文链接：https://arxiv.org/abs/2609.15516v1

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：大模型安全研究 蜜罐先生 蜜罐先生《当 Agent 描述沦为注入通道：一份恶意简历如何污染多智能体任务》