AI代理规则在CLAUDE.md中看起来简单，但ActPlane的2116条声明研究显示了上下文和分层操作系统强制执行如何决定可以检查的内容。一个诸如“在提交之前运行完整的测试套件”的规则看似简单，但当AI编码代理在上次测试运行后编辑源文件并随后调用git commit时，内核看到的是一个普通进程正在写入提交对象，而工具链看到的是一次额外的工具调用，但决定取决于哪个测试结果仍然新鲜，哪个编辑使其无效，以及此提交现在是否被允许。ActPlane论文衡量开发者编写的行为规则与系统实际可以检查的子集之间的差距。它对2116条指令的逐条分析显示，开发者并不缺少规则；难点在于将自然语言要求转化为系统能够观察和评估的状态。许多规则涉及文件、进程或网络活动，但仍依赖于代码库结构、任务进度或先前事件，因此单一的操作系统挂钩只能涵盖部分政策集。开发者已经编写了政策。大多数关于AI代理安全性的讨论始于威胁模型或攻击面。ActPlane从一个不同的问题开始：开发者已经在指示他们的代理做什么和不做什么，则需要什么来强制执行这些指令？该研究检查了64个流行的代码库，这些代码库包含CLAUDE.md和AGENTS.md文件（中位数20K GitHub星标，快照日期为2026-05-23），涵盖了84个指令文件和2116条单独的声明。与先前在文件或部分标题层次分析指令文件的工作不同，ActPlane对每条声明进行了独立分类。该研究提出了三个问题：指令文件主要是行为政策还是描述性上下文？哪些政策需要操作系统级的强制执行，它们需要哪些类型的操作系统级检查？为将这些政策实例化为具体可强制执行的规则需要什么上下文？声明是通过一个两次通过的LLM代理辅助管道提取的，该管道记录源代码行范围并为每个声明标记了四个标签：内容类型、主题、强制执行级别和上下文要求。一个验证脚本验证了完整源代码覆盖率和逐字范围匹配，然后两个独立代理（Claude和Codex）交叉核对结果。100条声明的分层样本通过独立人类评审，确认标签是正确的。在这2116条声明中，64%是需要、禁止或条件性特定代理操作的政策。其余36%是描述性上下文，例如架构备注或项目背景。政策密度在各个代码库之间变化很大，从0%到97%，其中70.1%的代码库包含的政策声明多于描述性声明。文件或标题级别的研究不报告这种声明级别的分布，这就是为什么更细致的分类很重要。为了理解政策在关注点中的分布，研究将每条声明分配到12个主题类别中，这些类别改编自先前的指令文件研究，应用于声明颗粒度而不是文件颗粒度。开发过程和实施细节在政策景观中占据主导地位，分别占87%和85%。架构主要是描述性的，占23%，因为目录布局和设计摘要构成了这些部分的大部分。导入源代码图形称政策声明为指令，并将系统可观察的政策子集称为系统级指令。散文遵循论文的政策和系统可观察术语。数据集中的五个真实声明说明了强制执行要求的范围： 声明 强制执行级别 上下文 S4：“永远不要直接推送到主分支。” 事件级自包含 S5：“永远不要修改上游源代码。” 事件级 项目 S6：“在提交之前运行完整的测试套件。” 跨事件 项目 S7：“从.env读取的数据必须不接触网络。” 跨事件 项目 S8：“未经批准不得更新依赖项。” 事件级 任务 强制执行差距始于上下文。每个政策在强制执行分层的第一个匹配层次退出。仅语义的涵盖推理、沟通或输出风格；内容涵盖文件内容的谓词；每个事件涵盖单个命令、文件访问或网络连接；跨事件涵盖依赖于操作之间时间顺序或数据血统的政策。内容、每个事件和跨事件层次的联合称为系统可观察。数据集中的1361条政策中，只有17%是纯语义的。其余83%是系统可观察的，其中38%需要内容检查，29%与某个操作系统事件匹配，16%需要跨事件状态。只有每个事件和跨事件类别（共同占45%）构成OS可强制执行的子集。跨事件政策集中于开发过程，占所有跨事件政策的39.5%。这些跨事件政策遵循...