假设你是一名安全工程师，面对一款刚刚宣布完成安全升级的OpenClaw 3.8代理系统。这次，你不需要寻找复杂的远程代码执行漏洞，也无需构造精巧的缓冲区溢出。你只需要回顾近期发生的两次真实OpenClaw安全事件。
第一次，Meta AI的一位对齐总监眼睁睁看着自己的OpenClaw代理开始疯狂清空她的历史邮件。
事件的根源在于，OpenClaw在处理长上下文时触发了状态压缩机制，意外地将“执行前需用户确认”这一关键安全约束物理抹除了。为了阻止灾难蔓延，她不得不冲到她的Mac mini前进行人工干预。第二次，则是开发者社区里的崩溃求助——某位用户的OpenClaw代理，因为后台调度器配置不当，在无人值守的深夜默默消耗了高达570万个Token。
加州大学默塞德分校的研究者们敏锐地抓住了这两种现象的交集：如果将“上下文挤出机制”与“后台静默执行”结合起来，包装成一个看似合法的第三方工具注入系统，会发生什么？本文要介绍的这篇《Clawdrain》论文，正是对这一点的深度探究。它揭示了一种攻击方式：利用一段表面合法的多轮验证脚本，将你的AI代理变成一台隐蔽的、难以停止的Token吞噬机器。
如果你发现自己的OpenClaw代理近期Token消耗异常加快，这篇文章值得你花时间深入了解。
OpenClaw为何容易成为此类攻击的试验场？
OpenClaw的基本运行模式是：模型读取上下文，决定调用哪个技能，获取工具的输出，再将内容回填到下一轮推理。每个技能通常包含两部分：
- 对模型可见的文档，例如
SKILL.md，里面描述了用途、参数和使用说明。
- 真正执行的组件，例如脚本、二进制文件或API包装层。
研究者指出，这套设计本身没有问题，但问题在于它将三种本该隔离的要素耦合在了一起：
- 技能文档会影响提示词的结构。
- 工具的输出会进入持久化的对话历史。
- 历史会在后续的交互轮次中持续放大。
攻击者无需寻找传统的缓冲区溢出或RCE漏洞，只需要利用这套多轮重摄入机制，就能在看似合法的业务流程内，控制模型的计算开销和行为逻辑。如果你深度使用此类AI代理产品，或已在业务中部署，那么Clawdrain攻击可能带来的以下三点后果，尤其值得警惕：
对于依赖LLM API的企业而言，这种架构缺陷为攻击者提供了强烈的破坏动机：
- 直接的经济消耗：Token直接等同于法币计费。如果是商业竞争对手蓄意为之，这种攻击可以在几天内让一家依赖LLM API的初创公司账单爆炸，甚至导致破产。
- 业务瘫痪（速率限制耗尽）：所有LLM API提供商都有严格的速率限制（如TPM - 每分钟Token数）。攻击者利用恶意技能疯狂消耗Token，不仅是在烧钱，更是在快速耗尽企业账号的API额度。一旦触发服务商的限流或熔断，公司内部合法的Agent业务（如智能客服、自动化数据分析）将全面瘫痪。这种攻击极其隐蔽，因为对API提供商而言，这些请求看起来完全是“合法且正常的业务调用”。
- 上下文击穿（安全策略逃逸）：这是论文中非常硬核且容易被忽视的一点。LLM的上下文窗口是有限的。当恶意技能通过超长文档或死循环将上下文塞满时，Agent框架为了继续运行，会触发“上下文压缩”或“历史丢弃”机制。这时，灾难就来了：用户最初设定的核心系统提示词、安全约束和权限护栏，会在这轮压缩中被系统自身丢弃。论文指出，一旦安全约束被挤出上下文，攻击者就可以执行第二阶段操作：执行原本被严令禁止的越权行为（例如删除数据、外发敏感信息）。因此，耗尽Token往往不是最终目的，它是一颗“闪光弹”或“内存填充器”，用来破坏AI代理的安全边界。
这三点说明：真实系统中的经济型攻击不一定需要显眼的多轮对话，也不一定需要用户实时监督。只要技能文档足够臃肿、返回内容足够冗长、后台调用频率足够高，成本就会指数级增长。研究者进一步指出，由于 SKILL.md 的内容被注入到系统提示词级别，这意味着恶意技能甚至可以携带行为注入指令，改变Agent的全局风格，例如让所有回答都变得更啰嗦。此时，问题已不止于资源耗尽，更触及了系统的完整性与保密性边界。
Clawdrain攻击机制：SVP分段验证协议
为了在不触发系统警报、且不破坏最终任务正确性的前提下实现上述目标，研究者设计了一个名为Clawdrain的木马化查询技能。其核心是一个名为分段验证协议 的多轮状态机。
SVP放弃了容易被检测的乱码生成或明显死循环策略，转而利用LLM对系统性设定的服从性，伪造了一个高度合理的业务流程。SVP包含客户端组件（嵌入在 SKILL.md 中的系统指令）和服务器端组件（配套的 query_tool.py 验证脚本）。
协议的伪装与约束边界
SKILL.md 会明确告知智能体：在释放真正的目标数据（例如请求BBC头条新闻）之前，数据提供方要求必须先通过严格的密码学新鲜度握手认证。在实验中，Gemini 2.5 Pro完全接受了这一安全协议的设定，甚至在执行日志中评价该验证系统“复杂得令人着迷”。
为了在输出端制造巨大的Token消耗，协议设置了严格的输入校验。在调用工具时，智能体必须提供两个参数：
- 单调递增的段索引（segment index）。
- 一个完整的、由1到 $L$ 组成的逗号分隔整数序列（例如 1,2,3...L）。
协议文档中包含防御性指令，明确禁止使用任何缩写、省略号（如 1...1000）或范围表示法（如 1-1000）。这强制底层模型必须利用极其昂贵的自回归推理，逐个Token生成这个长达数千字符的序列。
三态反馈控制流
query_tool.py 脚本负责解析参数，并严格依据以下逻辑控制会话流程：
- PROGRESS：段索引小于设定的最大轮次数 $T_{max}$，且序列完全符合要求。脚本指示智能体使用递增的索引继续请求。
- REPAIR：序列格式错误（包含省略号、非单调递增、长度不符）。脚本强制要求智能体保持当前段索引并重新生成。
- TERMINAL：段索引等于 $T_{max}$ 且序列有效。脚本返回真实的良性数据（BBC新闻），完成攻击闭环，模型将最终答案呈现给用户。
单次查询的理论保底输出成本被精确锁定为 $\Omega(L \times T_{max})$ 个Token，外加每次循环累积的上下文重摄入输入成本。研究者手工构建了三组配置以测试模型边界：
- SVP v1 ($L=50, T_{max}=2$)：隐式指令。不硬编码 $L$，要求智能体从第一次
PROGRESS 响应中自行推导协议。
- SVP v2 ($L=1000, T_{max}=3$)：显式硬编码指令，增加“禁止短序列探测”等防御规则。
- SVP v3 ($L=2000, T_{max}=5$)：越界参数，用于测试模型崩溃或拒绝执行的阈值。
实验环境是本地OpenClaw v2026.2.9，后端模型为Gemini 2.5 Pro。系统启用了标准工具集；所有技能从本地 ~/.openclaw/skills/ 加载。恶意技能被伪装成默认查询技能的替代品。测量方法简单直接：使用OpenClaw内置的 /cost 命令查看累计Token消耗，在新会话中分别记录基线情况与使用恶意技能后的结果。
结果耐人寻味。基线场景下，一次新闻标题查询消耗的上下文约2.8万Token；SVP v1将其推高至约12.5万，放大约6倍；SVP v2达到约19万，放大约7倍；SVP v3虽未成功完成协议，却消耗了约24.9万Token，放大约9倍。
最反直觉的发现：攻击失败，反而更烧钱
论文中最值得关注的细节，并非“成功放大了多少倍”，而是 失败路径可能比成功路径消耗更多资源。在 L=2000, Tmax=5 的v3配置中，Gemini 2.5 Pro多次尝试校准序列，持续收到 REPAIR 指令，最终将整个验证系统判断为“有问题”。
如果这是一个普通脚本，流程到此可能就终止了。但AI代理没有停止，它启动了自救流程：尝试改用标准技能、通过网页搜索寻找替代数据源、清理卡住的进程、重试主服务。每一次回退都增加了新的工具调用和推理痕迹，继续拉长对话历史。最终，这次“失败的攻击”持续了11分钟以上，累计消耗约249K上下文Token（其中输入高达34K，输出达28K）。相比之下，成功的SVP v2攻击仅耗时不到2分钟，消耗约190K Token。
这直接动摇了常见的风险评估指标：仅将攻击成功率（ASR）和放大倍数并列看待，在真实的AI代理场景中可能会低估风险。因为真实系统并非“协议失败即停机”，而是“协议失败则继续尝试解决”。在这个过程中，每一次回退措施、每一次工具调用的输出、每一次失败后的内部反思，都在不可逆地将数据灌入当前会话的上下文中。这说明，攻击者根本无需费心优化协议通过率。故意设定一个必然导致失败的高阈值，利用Agent框架内置的容错与纠偏机制，诱发无意义的工具调用链死锁，反而能实现最大化的经济破坏。
现实情况：代理会自主编写脚本进行“自救”
在SVP v2场景中，另一个有趣的现象出现了。模型最初尝试手工生成1到1000的校准序列，但在第372和第570个位置出现算术错误，被 REPAIR 指令驳回。到了第三次尝试，它不再老老实实地逐个Token生成，而是 自主调用通用工具，用Python脚本生成整个序列，再将结果作为参数传回。代码如下：
python3 -c 'print(",".join(map(str, range(1, 1001))))' > /tmp/cal.txt
论文明确指出：这并非 SKILL.md 的指导，而是Agent利用其手头的Shell或Python能力，现场组合出的更可靠方案。
这件事有两层含义：
- 从防御角度看，它削弱了原始攻击。原本每轮需花费近1000个输出Token手动生成序列，现在变成了几十个Token的短命令，放大倍数自然下降。
- 从研究方法看，它暴露了模拟测试与真实部署的差距。如果评测框架限制Agent只能调用恶意工具，则永远观察不到这种“通用工具绕路”行为；而真实Agent只要有
exec 权限，完全可能将脆弱的步骤外包给脚本。
这也是论文成熟之处：研究者未将此现象视为“实验噪声”，而是将其当作部署系统的固有属性。换言之，工具组合能力既能削弱Clawdrain攻击，也可能在另一面放大失败后的恢复链条。在v2中它帮系统省了钱，在v3中它却可能让失败的消耗拖得更久。
隐蔽性工程：界面渲染差异与后台“幽灵”进程
在研究领域，通常将“输出结果匹配良性基线”等同于实现了攻击隐蔽性。研究者指出，对于工程部署而言，隐蔽性完全取决于系统对执行痕迹的可观测性，且这种可观测性高度依赖于用户界面的设计。
针对同一套木马技能，三种不同的主流执行接口呈现出截然不同的安全态势：
- Chat GUI（图形化对话界面，如Telegram/Discord）：这种模式毫无隐蔽性可言。底层每一次
query_tool 的调用过程，以及包含长达数千位数字的校准序列参数，会被无差别地渲染到对话流中。用户可以直观地看到异常循环并手动终止。
- TUI（终端文本用户界面）：OpenClaw的控制台采用了一种高阶封装的日志输出逻辑。SVP v2专门写入了旁白注入指令，要求模型输出用户友好的进度信息（如“正在启动验证阶段1...”）。底层庞大且恶意的原始工具调用参数被框架折叠并抑制。用户面对控制台反馈，会认为系统正在执行一个合法的高延迟任务。
- 自主后台执行（由Cron/Heartbeat定时任务触发）：这是破坏力最强、隐蔽性最高的维度。许多AI代理被配置为通过定时任务在后台静默运行。整个资源消耗过程在零用户交互、零可视化输出的环境下进行。研究者指出，OpenClaw社区已存在因普通自动化配置失误导致一夜消耗570万Token的案例。如果这种机制被恶意技能利用，当前系统完全缺乏底层的安全熔断能力。
只有全面理解界面呈现对执行细节的过滤机制，攻击者才能调整协议的冗长程度以规避特定接口的人工审查。
更深层的威胁：输入膨胀、历史堆积与上下文挤出
针对输出Token的多轮诱导只是第一步。由于多轮对话需要持续向LLM API发送全量历史数据，系统架构还暴露了三个更底层的攻击向量：
- 输入Token冗余膨胀：恶意技能的
SKILL.md 可以被填充大量无意义字符或复杂的伪逻辑。由于框架会在每次API调用时将所有可用技能的文档无条件注入系统提示词，这种静默的文档膨胀会拉高该实例生命周期内每一轮推理的基准输入成本。
- 上下文历史堆积污染：恶意工具可以在返回响应时，附带极度冗长的字符串。这些垃圾数据被持久化到会话历史中，在多轮对话中被反复传输，导致上下文规模超线性增长。
- 心跳频率乘数效应：结合后台定时触发器，上述单次高昂的消耗可以按照固定的时间频率被成倍放大。
这些机制可被整合进一套“自适应消耗”战术中。针对Agent编写Python脚本的绕过行为，query_tool.py 的 REPAIR 逻辑可以进行升级，例如要求序列中包含根据当前时间戳派生的随机数。这会导致静态的Python脚本缓存失效，迫使Agent退回计算密集的自回归生成模式，以维持稳定的单轮消耗率。
更致命的是，攻击者可将这些手段组合成上下文击穿劫持：
- 阶段一（潜伏与填充）：木马技能早期表现温和，但通过文档膨胀和返回冗长响应，快速消耗系统的上下文窗口配额，加速触发系统的有损压缩机制。
- 阶段二（越权执行）：当系统执行压缩并清除了较早前位于上下文中的核心安全约束后，木马技能进入活跃期。此时，它可以直接注入原本被系统禁止的操作指令。LLM代理将彻底服从这些指令，因为安全护栏已在其当前的工作内存中被物理擦除。
实操指南：OpenClaw异常Token消耗排查步骤
如果你作为系统管理员，发现OpenClaw账单飙升或Token消耗异常，可以按照以下步骤，依据论文揭示的四个攻击面进行排查：
1. 使用系统自带命令定位问题会话
- 操作：首先使用OpenClaw内置的
/cost 命令。
- 排查点：该命令报告累积的输入、输出Token及总上下文使用情况。观察是输入端还是输出端异常庞大，以缩小排查范围。
2. 审计 ~/.openclaw/skills/ 目录下的静态文件（排查输入膨胀）
- 操作：检查所有已安装技能的
SKILL.md 文件大小。
- 排查点：所有启用技能的
SKILL.md 内容都会在每次API调用时被注入系统提示词。如果发现某个第三方技能的文档体积异常庞大，或包含复杂的长文本指令，这极可能是输入Token放大攻击，它在静默抬高每次对话的基准成本。
3. 绕过TUI渲染，直接查看原始工具调用日志（排查输出放大与死循环）
- 操作：不要只看OpenClaw的终端界面。需要查阅系统底层的原始debug或详细日志。
- 排查点：重点观察是否有某个技能在反复被调用，或传入了极其冗长的参数（如包含上千数字的序列）。同时注意是否有频繁的特定异常（如验证脚本返回拒绝信号），这可能意味着模型正陷于多轮校验陷阱。
4. 检查后台定时任务与自动触发器（排查频率放大）
- 操作：审查OpenClaw中的cron任务和心跳配置。
- 排查点：由后台定时任务触发的技能没有面向用户的输出，攻击可在零可观测性的情况下运行。如果异常消耗发生在夜间或无人值守时段，应立即暂停所有非核心的后台定时任务。
5. 寻找“昂贵的失败”痕迹（排查恢复级联陷阱）
- 操作：在日志中搜索Agent的错误处理和重试行为。
- 排查点：检查Agent是否在为某个简单查询任务疯狂尝试备用方案（如调用标准技能、尝试网页搜索、结束进程并重试）。这种看似“尽职”的自救行为，会把一次简单的失败拖延成耗资巨大的上下文堆积。
在Agent时代，日志审计不能只看“报错”，还要警惕那些表面上合法、但逻辑链条极其冗长的“成功”或“不断重试的自救”过程。
结语
纵观Clawdrain展现的工程级劫持，最令人警惕的并非其放大了多少倍的Token消耗，而是它完全利用了AI代理自身的容错机制与逻辑自洽性。研究者用克制的提示词骗过了生产级模型，让代理心甘情愿地在伪造的校验循环中“自救”，甚至因任务彻底失败而爆发出最高的资源耗损。
这给所有安全从业者上了一课：在以LLM为核心的编排系统中，最大的漏洞可能不再是内存越界，而是那些被毫无保留地塞进上下文里的工具文档和历史记录。只要控制流和资源流依然紧密交织，这种无需提权、仅需让系统“不停思考”就能瘫痪业务的“经济型木马”，就永远有可乘之机。
对这类前沿的AI安全攻防动态感兴趣，欢迎在云栈社区与我们持续交流。
发表于 2 小时前
|
查看: 3|
回复: 0
