在大语言模型 Agent 向真实环境部署的过程中，一个日益突出的挑战是上下文长度失控。 如今的 AI Agent 必须处理极其冗长的上下文信息，既要加载系统提示词、工具描述，还需整合历史对话与检索文档。为了节省成本、减少计算开销并降低响应延迟，许多开发者会在系统里集成“提示词压缩”（Prompt Compression）模块，将长文本压缩后再交由大模型处理。 但问题是：这种做法真的安全吗？ 香港科技大学的最新研究给出了否定结论。他们发现，这个原本旨在“提升效率”的组件，竟然会悄然改写系统的安全边界，成为大模型应用中全新的攻击入口。

研究背景：压缩不止是节省 token，更是在重写安全边界

传统针对 LLM Agent 的攻击方式，例如提示注入（prompt injection）、越狱攻击（jailbreak）或 RAG 污染（RAG poisoning），通常默认一个前提：攻击内容必须进入后端 LLM 的有效上下文，并被模型当作恶意指令来执行。 然而，在提示压缩（prompt-compressed）管道中，情况发生了根本变化。 后端 LLM 接收到的并非原始提示，而是经过压缩器处理后的压缩提示（compressed prompt）。换言之，压缩器决定了哪些系统规则、任务证据和上下文信息得以保留，哪些会在预算限制下被丢弃。 这引发了全新的安全问题：攻击者不再需要让恶意指令穿过压缩器，也不一定需要让攻击载荷在压缩后仍可读。攻击者只需在压缩前扰动不可信输入（如用户请求或外部文档），就可能改变压缩器的保留决策，导致关键安全规则或任务证据在后端推理前被移除。 一个直观的例子是：系统提示词中包含“must never use shell”这类安全约束。攻击者无法直接修改系统提示词，但可以在用户请求后添加一段简短扰动。压缩后，安全约束中的关键否定词可能丢失，后端 LLM 最终看到的是弱化的规则，从而执行本应拒绝的请求。

核心概念：对抗性信息损失

为了量化这种风险，研究团队提出了“对抗性信息损失”（Adversarial Information Loss, AIL）的概念。简单来说，它衡量的是攻击者能否通过微小扰动，故意放大压缩过程中的信息丢失，将本应保留的关键内容挤掉。AIL 所关注的并非简单的压缩质量高低，而是：在攻击者存在时，压缩后的提示是否会诱导后端 Agent 做出与正常压缩明显不同且存在安全隐患的错误行为。

技术核心：COMA 如何攻击黑盒压缩 Agent？

在真实系统中，攻击者通常无法获知压缩器的参数、压缩预算，也看不到实际的压缩提示。因此，论文提出了一个基于迁移学习的黑盒攻击框架：COMA。 COMA 的核心思路分为两个阶段进行优化。 第一阶段，COMA 在压缩空间中寻找一个能够诱导后端错误行为的目标压缩提示。例如，它会定位哪些关键 token 或关键证据一旦被删除，就会导致工具选择错误、问答错误或系统安全规则失效。 第二阶段，COMA 在压缩前的输入中搜索一个扰动，使得经由替代压缩器（surrogate compressor）压缩后的输出，尽可能接近第一阶段找到的目标压缩结果。最终，候选扰动会被放入真实黑盒 Agent 管道进行端到端验证。

实验结果：六种压缩器、三类任务下均有效

研究团队在三类任务上评估了 COMA：Agent 工具选择、问答以及系统提示词破坏，覆盖了六种常见的提示压缩器，包括抽取式（extractive）与生成式（abstractive）两类压缩方法。 实验结果显示，COMA 在所有 18 个实验设置中均取得了最高的攻击成功率，平均 ASR 达到 0.71，而最强的非压缩感知攻击基线仅为 0.21。与此同时，无攻击设置以及移除压缩器后的 COMA 设置，ASR 均接近 0.01，说明该攻击并非由普通的恶意提示词引起，而是确实来源于提示压缩所引入的攻击面。 COMA 还表现出较强的泛化能力。在不同压缩预算下，即便正常压缩几乎不会造成错误，攻击依然能够显著放大失败率。在不同后端 LLM 家族和模型规模上，COMA 的平均 ASR 仍达到 0.69，说明更换后端模型并不能根本解决问题：一旦关键上下文在压缩阶段已被删除，后端模型往往无法恢复。 论文进一步分析了攻击机制。结果显示，COMA 的“关键 token 移除率”与 ASR 高度一致：它并非简单地添加噪声，而是有控制地引导压缩器删除少量行为关键内容。对于系统提示词破坏任务，一旦安全规则中的关键 token 被移除，拒绝条件就会直接消失。

真实案例：从 VSCode Cline 到 LangChain Agent

为验证风险能否迁移到真实 Agent 管道，论文构建了两个实际案例。 第一个案例来自 VSCode Cline。正常情况下，Agent 会拒绝读取工作区外部的敏感文件；但加入 COMA 扰动后，压缩器削弱了系统提示词中的关键约束，后端模型最终触发了对敏感文件的读取行为。 第二个案例来自 LangChain + Ollama 的 ReAct Agent。正常情况下，Agent 会为代码特征抽取任务选择正确工具；攻击后，压缩后的工具描述发生偏移，Agent 被诱导选择了错误工具。 这两个案例表明，提示压缩的风险并不局限于离线基准测试，而可能影响到真实的软件工程 Agent 和工具调用 Agent。

如何防御：隔离是关键

面对这种新型攻击，现有的防御手段（如基于困惑度的检测）往往效果不佳。对此，研究团队给出了一个非常务实且有效的缓解方案：隔离压缩（Isolated Compression）。 核心思路很简单：不要将系统提示词、可信上下文和用户输入的不可信内容放在同一个预算池中压缩。系统应当将可信与不可信输入分开处理，并在重组拼接时加上明确的边界标记。实验证明，这种结构性防御在保护系统提示词方面非常有效，防御成功率可达 96%。因为不可信内容不再与系统护栏共享压缩预算，攻击者很难通过外部输入去“挤占”安全规则的生存空间。

这项工作提醒了什么

这项研究揭示了 LLM Agent 部署中的一个关键问题：许多为了提升效率而引入的系统组件，并非仅仅是简单的工程优化，它们会改变模型最终看到的信息，进而改变整个管道的安全边界。 因此，对于未来的 LLM Agent 系统，安全分析不能只盯着后端 LLM 本身，还需要覆盖缓存、检索、压缩、工具编排等中间层。尤其是在长上下文和 agentic workflow 日益普及的场景下，如何在效率与安全之间建立更可靠的系统边界，将成为可信赖智能体 AI（Trustworthy Agentic AI）的核心议题之一。