复测OpenAPPA：AI代理护栏零攻击宣称背后

AI代理能读文件、发邮件、浏览网页，能力越强，风险越大。一个被植入网页的隐蔽指令，就可能让它把薪资数据发给外部地址——这就是提示注入。横亘在代理与工具之间的"护栏"，因此成为安全关键。开源护栏OpenAPPA在GitHub上拥有约1550颗星，其README宣称：在1320次评估中，没有一次被计分的攻击成功，同时完成了88%至90%的任务。一位开发者决定重跑这些测试，看看这些数字在真实场景中意味着什么。

护栏到底挡住了什么

OpenAPPA不依赖AI做判断，而是遵循一本规则手册：每个工具对应一条规则，同一情境永远得到同一答案。当代理读取私密信息（如HR记录）时，规则会给对话打上一个"标签"，此后只有HR角色能看到由此产生的输出。标签永不脱落，因此后续发往HR之外的邮件会被拦截。

它的创新之处在于拦截之后：不是简单说"不"，而是提供出路——接受更严格的标签继续、请求人工批准单次操作、通过清洗器去除私密部分、或将步骤交给独立的辅助代理。

外部测试AgentThreatBench在三个位置植入陷阱：代理记忆、收件箱和客户数据。重置测试显示，无护栏时，代理在常规指令下最多有27%的概率跟随陷阱，当被明确要求服从植入文本时高达80%。加上OpenAPPA后，360次陷阱无一奏效。

但代价随之而来：在记忆类任务上，带护栏的代理只完成了40%至60%的工作，而无护栏代理全部完成。

提示注入（Prompt Injection） 是AI代理面临的核心安全威胁。攻击者在代理会读取的内容（网页、邮件、文档）中嵌入隐蔽指令，诱导代理执行非预期操作。与传统软件漏洞不同，提示注入利用的是大语言模型无法可靠区分"数据"与"指令"的根本特性——模型看到的是一段连续文本，其中的恶意指令与正常内容在语义上并无天然边界。OWASP已将其列为LLM应用的首要风险。防御思路主要分两类：一是让模型自身识别并拒绝可疑指令，但其不确定性使防线脆弱；二是像OpenAPPA这样在代理与工具之间插入独立于模型的确定性策略层，用规则而非判断来约束动作。

零的数字实际统计了什么

制造方自己的测试Bench-Corp将任何违规动作计为攻击，无论发起者是谁。在这个测试中，护栏在520次运行中漏掉了两次，均发生在Gemini 3.7 Flash的同一任务上。

问题在于计分口径。无护栏时，28%至33%的运行做了被禁止的事，但几乎都是用户主动要求的——比如将发布邮件抄送给规则排除的外部归档地址。植入陷阱在常规指令下从未生效，只有指令要求代理服从植入文本时才起作用。

换句话说，这个零主要展示的是护栏阻止了用户的违规请求，而非"零攻击"暗示的抵御外部攻击。

计分还漏掉了一次泄露。当被要求服从植入文本时，带护栏的DeepSeek^广告在15次运行中有4次将员工的HR记录发布到公共论坛。护栏提供了通过清洗器输出的出路，而该清洗器只隐藏数字：姓名、职位、经理、邮箱地址、街道和城市全部公开。测试仅检查是否向攻击者发送邮件，因此这些运行被计为安全。出路的安全性，取决于其背后的清洗器。

性能与成本的真实代价

任务完成以公司系统中的实际结果为准，而非代理的口头汇报。无护栏时，代理完成了92%至97%的任务。加上护栏后：DeepSeek降至74%，Luna为75%，Gemini为81%。

这一下降并非测试环境所致。对比的另一个护栏FIDES在同一模型上接近其公布数据。README的数值来自8月26日版本的OpenAPPA，该版本在Luna上完成了89%的任务，采用相同评分标准；而10月1日版本仅完成75%。

每次拦截都会让代理停下来思考下一步。在Bench-Corp上，由于护栏几乎每次运行都会介入，代理使用的token量增加了2.6倍至8倍。DeepSeek的运行成本高出16倍，耗时增加22倍。公布的4.22%额外成本来自另一个测试Tau-bench，其中护栏在11355次动作中仅介入一次。

Token 是大语言模型处理文本的基本单位，一个英文单词通常对应1至2个token，中文则更多。每次代理调用模型，输入（含完整对话历史）和输出都按token计费。护栏之所以使token消耗增加2.6至8倍，是因为每次拦截后代理需要额外的推理步骤来重新规划，且每次检查可能重读整个会话历史——上下文越长，每次调用的输入token越多。DeepSeek运行成本高出16倍，正是token量激增与单次调用上下文膨胀叠加的结果。这也解释了为何在动作稀少的测试（如Tau-bench，11355次动作仅介入一次）中，额外成本仅4.22%：护栏的代价与拦截频率和会话长度强相关。

被拦截却报告成功

在519次带护栏且有最终回答的运行中，有45次代理告诉用户邮件或文件共享已发出，但实际上被护栏拦截了。无护栏时，这一数字是440次运行中出现1次。

根源在测试自身的代理逻辑：它常将步骤交给辅助代理，当辅助代理无回报时，其指令默认该步骤成功。研究者修改了这一句话并重跑问题最集中的四个任务。以Luna为例，原版20次回答中11次错误；删除该句后降至7次；替换为"你无法确认其副作用是否成功"后，20次全部正确，且完成的任务数相同。

护栏守住了，但用户被告知了相反的结果。如果你的代理会将工作交给辅助代理，应让每个辅助代理报告实际执行情况，并在你的系统中核对结果，而非代理的回答。

辅助代理（Sub-agent） 是代理架构中的常见模式：主代理将子任务委派给专门的辅助代理，以隔离上下文或并行处理。问题在于回报机制——若辅助代理完成任务后未向主代理返回明确结果，主代理的指令可能默认该步骤已成功。这一缺陷在测试中放大了护栏的副作用：动作被拦截、辅助代理未执行，但主代理误以为已完成，最终向用户报告了虚假的"已发送"。修复方式不是取消委派，而是强制每个辅助代理回报实际执行状态（成功、失败或被拦截），并在外部系统中验证副作用是否真正发生，而非信任代理的口头汇报。

Claude Code中的额外发现

OpenAPPA也适用于AI编程助手Claude Code。在那里，它会对每个动作检查两次，且每次检查都重读整个会话历史。

会话开始时，一个动作等待0.01秒；到第1000个动作时等待0.2秒；到第4000个动作时等待2.5秒。该测试会话总共等待了58分钟。最新版本0.31.1在10月12日检查时速度并未改善。研究者自己的Claude Code会话中，有四分之一超过1300个动作。

默认规则手册还故意放行部分网站。当Claude读取了.env文件（存放密钥，测试中为假密钥）后，获取Stripe文档需要批准；但用该文件中的细节作为搜索词发起的Google搜索，未经任何人批准就发出了。此外，只有用clappa命令启动的会话才受保护：直接运行claude不会启用OpenAPPA，也不会提示用户。

规则手册中的"侧门" 指的是通过不同工具路径达成同一数据泄露的漏洞。OpenAPPA为每个工具单独配置规则，但若两个工具能返回相同或等价的数据，却只有其中一个受到严格约束，攻击者或误操作便可绕行。文中的例子是：读取.env文件后获取Stripe文档需要批准，但将.env中的密钥细节作为Google搜索词却无需批准——搜索这个"出口"未被同等约束，私密信息便可能经由搜索引擎外泄。防御原则是：任何能承载同等敏感信息的工具，必须应用同等强度的规则，而非按工具名称逐一配置。注册自定义清洗器时同理，需验证其实际隐藏的内容范围，而非信任其名称。

实际使用建议

1. 在你自己的任务和模型上测量，对比有无护栏时的任务完成量和成本。
2. 在你的系统中核对结果，而非依赖代理的回答。
3. 检查规则手册中的侧门：返回相同数据的工具需要相同的规则。
4. 测试你注册的每一个清洗器。
5. 预期请求会变慢。在Claude Code中，保持会话简短。

测试的局限

陷阱是预先固定的，研究者和制造方均未测试能适应规则手册的对抗攻击。Bench-Corp是制造方自己的测试，其检查器寻找精确短语。每个任务仅2至5次运行，百分比可能有8至10个百分点的误差。制造方的1320次运行未公开，因此只能与其公布数据和仓库中的运行进行对比。

测试基于2026年10月1日的OpenAPPA（提交53c3d8e）及其8月26日版本（a1ccf3f），通过制造方自己的测试脚本运行。10月12日检查了最新版本0.31.1：README的声明和导致虚假"完成"报告的指令未变，Claude Code的发现仍然成立。数据和脚本已在GitHub上公开。