Arbiter: Detecting Interference in LLM Agent System Prompts

本文提出了名为 Arbiter 的框架，通过结合形式化评估规则与多模型扫描技术，成功检测出 Claude Code、Codex CLI 和 Gemini CLI 等主流 LLM 编码代理系统提示词中的干扰模式，并揭示了提示架构与故障类别的关联性及多模型评估在发现独特漏洞方面的优势。

要点

这篇论文讲述了一个关于**"AI 程序员”如何被自己的“操作手册”搞晕**的故事，以及作者发明的一套新工具来找出这些手册里的漏洞。

我们可以把这篇论文想象成一次**“给 AI 操作手册做全面体检”**的行动。

1. 核心问题：AI 的“宪法”里全是矛盾

想象一下，你雇佣了一个超级聪明的 AI 程序员（比如 Claude Code、Codex 或 Gemini CLI）。为了让它好好工作，人类给它写了一份长长的**“操作手册”**（也就是论文里说的 System Prompt）。这份手册告诉 AI：

• “你要用这个工具！”
• “你永远不要用那个工具！”
• “你要先写代码，再检查！”
• “别写代码，直接检查！”

问题出在哪？
在传统的软件里，如果代码写错了，编译器会报错。但在 AI 的世界里，这份“操作手册”没有检查员。当 AI 读到互相矛盾的指令时，它不会报错，而是会**“凭感觉”**（也就是它的训练数据里的直觉）选一个执行。

• 比喻：就像你给一个司机同时下了两个命令：“全程必须开红灯”和“遇到红灯必须停车”。司机不会报警，他会凭心情决定是闯红灯还是停车。结果就是，有时候他开得对，有时候他撞车了，但你根本不知道他为什么这么做。

2. 解决方案：Arbiter（仲裁者）

作者 Tony Mason 发明了一个叫 Arbiter 的工具，专门用来给这些“操作手册”挑刺。它用了两种方法，就像侦探破案一样：

方法一：定向考古（Directed Evaluation）

• 怎么做：像法医一样，把操作手册切成一块一块的，然后拿着“规则清单”去比对。
• 例子：规则是“如果 A 说‘必须做’，B 说‘禁止做’，那就是矛盾”。
• 效果：这能找出所有明面上的矛盾。比如在 Claude Code 的手册里，它发现“必须频繁使用 TodoWrite 工具”和“提交代码时禁止使用 TodoWrite"这两条指令直接打架。

方法二：无定向扫荡（Undirected Scouring）

• 怎么做：这是最精彩的部分。作者没有给 AI 定死规则，而是把操作手册扔给10 个不同的 AI 模型，对它们说：“你仔细读读，觉得哪里奇怪或者有趣就告诉我。”
• 为什么要用 10 个？ 因为不同的 AI 就像不同专业背景的侦探。
  • 有的 AI 像会计师，专门看哪里会浪费钱（比如无限生成 Token）。
  • 有的 AI 像安全专家，专门看哪里会被黑客利用。
  • 有的 AI 像逻辑学家，专门看哪里前后矛盾。
• 效果：这种“盲扫”发现了定向检查发现不了的问题。比如，Google 的 Gemini CLI 有一个隐藏的大坑：当你保存了用户的偏好设置，系统为了节省空间压缩历史记录时，会把用户的偏好设置直接删掉。这个逻辑漏洞，只有那个像“数据完整性侦探”的 AI 模型才发现了。

3. 三大发现：手册写得越乱，AI 越容易疯

作者分析了三家大公司的 AI 手册，发现它们的结构决定了故障的类型：

1. 独裁式（Monolithic）：像一块巨大的披萨

   • 代表：Claude Code（1490 行，巨长）。
   • 问题：因为太长，不同部门的人各写各的，最后拼在一起。就像把“必须吃素”和“必须吃肉”写在同一张纸上。
   • 后果：在模块交界处（比如写代码和提交代码的切换点）经常打架。

2. 扁平式（Flat）：像一张简单的清单

   • 代表：Codex CLI（298 行，很短）。
   • 问题：太简单了，功能少，矛盾也少。
   • 后果：虽然不容易打架，但能力也有限，而且有时候会漏掉一些重要的身份说明（比如它到底是谁）。

3. 模块化（Modular）：像乐高积木

   • 代表：Gemini CLI（由代码动态组装）。
   • 问题：每一块积木单独看都没问题，但拼在一起的时候，接口没对上。
   • 后果：就像你拼了一个乐高房子，结果发现“窗户”和“墙壁”的接口不匹配，导致房子漏风（比如刚才说的保存偏好被删除的问题）。

4. 惊人的结论：只要 27 美分

这篇论文最让人震惊的不是发现了多少漏洞，而是成本。

• 作者跑完这一整套针对三家大公司的分析，总共只花了 0.27 美元（不到 3 元人民币）。
• 比喻：这比你在美国买一杯咖啡便宜得多，甚至不够付一个保安 3 分钟的小时工资。
• 意义：这意味着，检查 AI 操作手册是否安全、是否矛盾，不需要大公司的巨额预算，任何有 API 权限的开发者都能做。但问题是，现在几乎没人做。

5. 总结：给 AI 立规矩，得用“外脑”

这篇论文告诉我们：

• AI 不能自己检查自己：就像人很难发现自己写的文章里有逻辑漏洞一样，AI 也会“糊弄”过矛盾。
• 需要“外脑”：必须用不同的 AI 模型互相挑刺，才能发现真正的隐患。
• 手册就是代码：操作手册不是随便写的几句话，它是软件。如果软件没有测试、没有检查，那它迟早会出大事故。

一句话总结：
现在的 AI 程序员手里拿着一本充满矛盾、没人检查的“操作手册”在干活，作者发明了一个只要花 27 美分就能帮我们把这本手册里的坑全挖出来的工具，并警告大家：如果不检查，AI 迟早会把自己搞崩溃。

技术摘要

论文技术总结：Arbiter —— 检测 LLM 智能体系统提示中的干扰

1. 研究背景与问题定义

核心问题：基于大语言模型（LLM）的编程智能体（如 Claude Code, Codex CLI, Gemini CLI）完全由**系统提示（System Prompts）**驱动。这些提示本质上是控制智能体行为的软件工件，包含行为规范、优先级层级、工具契约和状态管理。然而，与常规软件不同，这些“智能体宪法”缺乏类型检查器、代码检查器（Linter）或测试套件。

主要痛点：

• 静默冲突：当系统提示中存在矛盾指令（例如一处要求“始终使用 TodoWrite"，另一处禁止“使用 TodoWrite"）时，执行中的 LLM 会通过其训练得到的启发式方法“平滑”掉这些不一致，而不会报错或记录警告。
• 自我审计失效：执行冲突提示的 LLM 无法检测冲突，因为使其能够处理模糊性的“判断”机制，正是使其无法识别矛盾的原因。
• 缺乏基础设施：目前缺乏针对系统提示内部一致性和结构缺陷的正式评估框架。

2. 方法论：Arbiter 框架

作者提出了 Arbiter，一个结合形式化评估规则与多模型 LLM 扫描的混合评估框架，包含两个互补阶段：

2.1 定向评估（Directed Evaluation）：提示考古学

• 流程：
  1. 分解：将系统提示分解为分类块（按层级、类别、模态和范围分类）。
  2. 规则应用：应用预定义的形式化规则检测特定类型的干扰（如“指令与禁令冲突”、“范围重叠冗余”、“优先级标记模糊”等）。
  3. 预过滤：通过范围重叠和模态约束减少搜索空间。
• 特点：在定义好的搜索范围内是穷举的。如果存在规则，它保证能发现所有实例。
• 局限性：只能发现规则已定义的漏洞类别，无法发现未知的漏洞类型。

2.2 非定向扫描（Undirected Scouring）：多模型扫描

• 流程：
  1. 模糊指令：向多个不同的 LLM 发送提示，要求它们“仔细阅读并记录有趣的内容”，不预设规则。
  2. 多轮迭代：每一轮扫描都会接收之前所有轮次的发现，并被要求探索前人未涉及的领域。
  3. 多模型执行：使用训练数据不同的多种 LLM（如 Claude, Gemini, DeepSeek, Llama 等），利用不同模型的认知偏差来发现互补的漏洞。
  4. 收敛终止：当连续三个模型表示“没有新发现”时，停止扫描。
• 特点：能够发现规则范围之外的未知漏洞类别（如安全架构缺口、经济剥削向量等）。

2.3 结构分析（AST 解析）

• 构建了一个两层解析器，将提示转换为抽象语法树（AST），分析文档的物理结构（标题、列表、代码块）和语义角色（身份、策略、工具使用等），用于检测版本间的结构差异和克隆检测。

3. 实验对象与数据

研究分析了三大主流编程智能体的系统提示：

1. Claude Code (Anthropic)：1,490 行，单一大文档（单体架构）。
2. Codex CLI (OpenAI)：298 行，简单结构（扁平架构）。
3. Gemini CLI (Google)：245 行，由 TypeScript 渲染函数在运行时动态组装（模块化架构）。

4. 关键发现与结果

4.1 架构与故障模式的强相关性

研究发现提示的架构风格直接决定了故障的类型：

• 单体架构 (Monolithic, 如 Claude Code)：
  • 故障特征：在子系统的边界处产生增长型错误。
  • 案例：通用子系统（如 TodoWrite 任务管理）的通用指令与特定工作流（如提交代码、PR 创建）的禁令直接冲突。由于缺乏跨团队的集成测试，这些矛盾被保留。
• 扁平架构 (Flat, 如 Codex CLI)：
  • 故障特征：以能力换取一致性。
  • 案例：由于功能较少，矛盾较少。主要发现是结构性的观察（如身份混淆、空标题），而非严重的操作性错误。
• 模块化架构 (Modular, 如 Gemini CLI)：
  • 故障特征：在模块组合接缝处产生设计级错误。
  • 案例：每个模块单独工作正常，但模块间的契约缺失。
  • 关键发现：Gemini CLI 的“历史压缩”模块定义了严格的 XML 模式，但未包含“保存记忆”工具的字段。这导致用户保存的全局偏好会在压缩过程中被结构性地删除。Google 后来修复了压缩死循环的症状，但未修复导致数据丢失的底层 Schema 问题。

4.2 多模型评估的互补性

• 发现不同类别的漏洞：不同模型发现的漏洞类别截然不同，而非仅仅是数量更多。
  • 例如：Kimi K2.5 专注于“经济剥削和资源耗尽”，而 Claude Opus 专注于“结构矛盾和安全表面”。
  • 结论：多模型评估是发现类别性不同脆弱性的必要条件，而非可选增强。

4.3 定量统计

• 发现数量：在三个提示中，非定向扫描发现了 152 个发现，定向分析在 Claude Code 中发现了 21 个手标干扰模式。
• 严重性分布：
  • Claude Code（最大）：发现分布均匀，包含 12 个“令人震惊（Alarming）”的发现。
  • Codex/Gemini：主要集中在“值得注意（Notable）”级别。
• 成本：完成所有三个厂商的跨厂商分析，总 API 成本仅为 0.27 美元（少于 3 分钟的美国最低工资劳动）。

5. 主要贡献

1. 基于实证的故障模式分类法：建立了基于跨厂商证据的系统提示故障模式分类（单体、扁平、模块化及其对应的故障类型）。
2. 混合分析方法论：提出了一种结合“定向规则”与“非定向多模型扫描”的系统性提示分析方法。
3. 多模型互补性证据：证明了多模型评估能发现单模型分析无法触及的漏洞类别。
4. 外部验证：扫描器发现的 Gemini CLI 设计缺陷（内存数据丢失）被厂商独立确认并报告，尽管厂商仅修复了表面症状而未解决根本的 Schema 问题。
5. 低成本可行性：证明了深度提示分析的经济可行性（0.27 美元），使其对普通开发者开放。

6. 意义与启示

• 提示即软件：系统提示应被视为真正的软件工件，需要像传统软件一样拥有 Linter、测试套件和 CI/CD 流程。
• 康威定律的体现：提示的结构反映了创建它的团队结构。单体提示中的矛盾往往源于不同团队在缺乏集成测试的情况下独立添加功能。
• 观察者悖论：执行冲突的智能体无法检测冲突，必须引入外部评估视角。
• 行业现状：目前这些关键软件工件缺乏任何静态分析或跨团队审查，存在巨大的质量与安全隐患。Arbiter 框架为填补这一空白提供了原型工具。

总结：该论文揭示了 LLM 智能体系统提示中普遍存在的结构性缺陷，并证明通过结合形式化规则和多模型互补扫描，可以以极低的成本高效发现这些缺陷。研究强调了将软件工程最佳实践引入提示工程（Prompt Engineering）的紧迫性。