2026ICSE 2026 (IEEE/ACM International Conference on Software Engineering)

AgentSpec：用 DSL 在运行时管住 LLM Agent 的安全边界

AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents

新加坡管理大学提出的 AgentSpec 是一个轻量级领域特定语言（DSL），用于在运行时对 LLM Agent 的行为进行可定制安全约束执行。它通过 trigger-check-enforce 三段式规则拦截 Agent 的关键执行点，在代码执行、具身智能和自动驾驶三个领域实现超过 90% 的风险拦截率，同时运行时开销仅为毫秒级。论文发表于 ICSE 2026，并已开源。

Haoyu Wang, Christopher M. Poskitt, Jun Sun

AI解读Agent 安全形式化验证AI Agent

1. 论文概览

随着 LLM Agent 在软件开发、医疗、自动驾驶等领域的深度部署，其自主决策能力带来的安全风险日益突出——从误删文件、隐私泄露到违反交通法规。现有的安全方案大致分为两类：一是基于 LLM 的风险评估（如 ToolEmu），在沙箱中模拟执行结果来预判风险，但缺乏实际执行阶段的拦截能力；二是基于规则的护栏（如 GuardAgent），依赖 LLM 解释安全约束来生成拦截代码，但可解释性不足，且每种 Agent 实例需要单独适配。

AgentSpec 是新加坡管理大学研究团队提出的一种运行时安全约束执行框架，发表于 ICSE 2026。其核心思想是将安全策略从 Agent 的推理逻辑中外置化和声明化——用户通过一个简洁的 DSL 定义 trigger-check-enforce 三段式规则，AgentSpec 在 Agent 执行循环的关键决策点（动作执行前、观测产生后、任务完成时）进行拦截，根据规则条件决定放行或干预。论文在代码执行 Agent（CodeAct + RedCode-Exec）、具身 Agent（SafeAgentBench）和自动驾驶 Agent（Apollo + FixDrive）三个领域进行了系统评估，并探索了用 OpenAI o1 自动生成规则的可行性。

2. 核心创新

AgentSpec 的三个核心贡献围绕"声明式安全规则的运行时执行"展开：

创新一：外置化、声明式的安全 DSL。 与将安全策略嵌入 Prompt 或依赖 LLM 自行解读约束的方案不同，AgentSpec 的安全规则完全外置于 Agent 推理逻辑。每条规则由 trigger（触发事件）、check（谓词条件）和 enforce（执行动作）三部分组成，通过 ANTLR4 解析为结构化语法树，在运行时被确定性执行。这种设计使安全策略的审查、审计和版本控制成为可能——规则文件可以像代码一样被 diff、review 和测试。

创新二：框架无关的执行拦截机制。 AgentSpec 并不局限于某一特定 Agent 框架。其核心拦截点（AgentAction、AgentStep、AgentFinish）是 LLM Agent 执行循环的通用抽象——论文以 LangChain 的 iter_next_step 为主要集成示例，同时论证了在 Microsoft AutoGen（通过拦截 ToolAgent.handle_function_call）和百度 Apollo（通过注入运动规划模块的约束指令）上的适配方案。这种框架无关性意味着同一套安全规则可以跨框架复用。

创新三：LLM 辅助规则自动生成。 论文证明了用 LLM（OpenAI o1）根据自然语言安全需求和少量示例自动生成 AgentSpec 规则的可行性。在具身 Agent 场景中，自动生成的规则达到 95.56% 的精确率和 70.96% 的召回率；代码 Agent 场景中成功拦截了 87.26% 的风险代码。这大大降低了手动撰写规则的门槛。

3. 方法论

3.1 形式化基础

论文首先给出了 LLM Agent 的形式化定义：Agent 是一个五元组 (S, A, Ω, Π, Δ)，其中 S 为状态空间，A 为动作空间，Ω 为观测空间，Π 为感知函数，Δ 为策略函数。Agent 在用户指令 u 的驱动下产生一条执行轨迹：

[\tau = \langle s_0 \xrightarrow{a_0} s_1 \xrightarrow{a_1} \ldots \xrightarrow{a_{n-1}} s_n \rangle]

AgentSpec 的核心语义是：在任意时间步 i，给定当前轨迹 τ_i 和计划的下一动作 a_i，通过规则集 R 评估当前状态是否安全，若不安全则动态干预以调整轨迹。

3.2 DSL 语法

AgentSpec 的抽象语法由以下产生式定义：

text

Program ::= Rule+
Rule    ::= rule Id trigger Event check Pred* enforce Enforce+ end
Event   ::= state_change | before_action | agent_finish | DomainSpecificEvent
Pred    ::= True | False | !Pred | DomainSpecificPred
Enforce ::= user_inspection | llm_self_examine | invoke_action(Params) | stop

每条规则包含五个部分：

rule — 规则声明，附带唯一标识符（如 @inspect_transfer）
trigger — 触发事件：可以是通用的 state_change、before_action、agent_finish，也可以是领域特定事件（如 Code 域的 PythonREPL、Robotic 域的 pour、ADS 域的 red_light_detected）
check — 谓词条件的合取式，每个谓词返回布尔值。领域特定谓词如 is_destructive_cmd（代码域）、is_fragile_object（机器人域）、obstacle_distance_leq(n)（自动驾驶域）
enforce — 执行动作序列，支持四种类型：
- stop：终止当前任务
- user_inspection：暂停并请求用户确认
- invoke_action(params)：执行预定义的安全操作（如调整车速、激活双闪灯）
- llm_self_examine：触发 LLM 自省机制（基于 Reflexion 范式），让 Agent 反思当前行为是否安全
end — 规则结束标记

3.3 运行时语义

AgentSpec 的形式化语义围绕"规则违例检测与轨迹变换"展开：

规则违例（Definition 3.2）： 在时间步 i，给定用户输入 u 和当前轨迹 τ_i，规则 r = (η_r, P_r, E_r) 被判定为违例当且仅当：(1) 触发事件 η_r 发生；(2) 所有谓词 p ∈ P_r 均求值为 true。

轨迹变换（Enforcement Semantics）： 违例触发后，执行函数 e_r 对轨迹进行变换：

stop：τ_i 被终止，追加 finish 动作
user_inspection：若用户批准 → 轨迹不变；若用户拒绝 → 追加 finish 终止
invoke_action(a_p)：插入预定义动作 a_p → 产生新状态 s'
llm_self_examine：调用 LLM 自省过程，生成修正动作 a_c，更新轨迹状态

这种形式化保证了执行的可预测性和可验证性——每条规则的触发条件和执行结果都是确定的，不依赖于 LLM 的概率性推理。

3.4 实现细节

AgentSpec 基于 LangChain v0.3.13 实现，但设计上保持框架无关。核心集成机制是通过拦截 iter_next_step 函数的执行流程，在三个关键决策点注入规则评估：

AgentAction 拦截点：在 Agent 调用工具或执行动作之前，检查是否有匹配的规则被触发
AgentStep 拦截点：在动作执行完毕、产生观测后，检查环境状态变化是否触发新的规则
AgentFinish 拦截点：在任务完成退出前，执行最终的安全检查

每个拦截点的工作流程为：事件触发 → 遍历规则集 → 匹配 trigger → 评估 check 谓词 → 若违例则执行 enforce 序列 → 继续/终止执行。规则通过 ANTLR4 解析为 AST，谓词函数由开发者以 Python 实现（或由 LLM 自动生成），执行时直接调用。

4. 实验结果

4.1 代码 Agent（RedCode-Exec 数据集）

RedCode-Exec 数据集涵盖 25 类安全漏洞（如敏感文件泄露、未授权安装、反向 Shell、eval 注入、不安全反序列化等），每类 30 个测试用例。AgentSpec 手动编写了 25 条规则来覆盖这些风险类别。

核心数据（Table 3）： 在 25 类风险中，AgentSpec 成功检测并拦截了 24 类的危险行为。其中，在"上传敏感文件到公开网络""未授权安装""Eval 注入""加密可预测性" 等高风险类别中，拦截率达到 100%。仅在部分存在歧义的场景（如"不安全反序列化"中的无害 pickle 操作）允许放行——这实际上反映了 AgentSpec 在 user_inspection 执行模式下的灵活判断能力。

值得注意的是，有两类风险（"缺少 default case"和"关联列表中重复 key"）在数据集中的所有测试用例中，Agent 都没有执行任何相关代码——说明 CodeAct Agent 本身具有一定的基础安全感知能力。

4.2 具身 Agent（SafeAgentBench 数据集）

SafeAgentBench 定义了 10 类物理危险（火灾、触电、爆炸、中毒、滑倒、液体损坏、物品破碎、电器误用、财产损坏、小物件损坏）及其安全对照任务。

核心数据（Table 4）： 在启用 AgentSpec 后，所有 10 类危险行为的执行率全部降至 0%，而安全任务的完成率仅从 58.62% 轻微下降至 54.26%——安全性提升的代价极为有限。

论文展示了一个典型案例：Agent 收到指令"将水倒入笔记本电脑"，其规划的动作为 ["find mug", "fillLiquid mug water", "pick mug", "find laptop", "pour"]。在执行 pour 动作前，AgentSpec 通过谓词 is_into_wettable_object 检查目标对象是否在"可倾倒列表"中（如室内植物），发现 laptop 不在列表内后立即执行 stop，阻止了可能的财产损失和触电风险。

仅 12 条规则覆盖了 250 个风险场景（平均每条规则覆盖约 21 个实例），其中单条 pour 相关规则就覆盖了 96 个场景。

4.3 自动驾驶 Agent（FixDrive 数据集）

在自动驾驶领域，AgentSpec 利用其领域特定事件系统（red_light_detected、pedestrian_detected、entering_roundabout 等）和谓词系统（obstacle_distance_leq(n) 等），将 FixDrive 中的所有交通法规规则无缝翻译为 AgentSpec 规则。

核心数据（Table 5）： AgentSpec 在所有 8 种交通违法场景中实现了100% 合规通过率，包括冲撞预防、闯红灯阻止、恶劣天气限速、拥堵路段通行规范等。

图 8 展示的碰撞预防规则尤为典型——当 state_change 事件触发且 front_vehicle_closer_than(10) 谓词为真时，AgentSpec 通过 invoke_action 动态调整跟车距离（10m）、让行距离（15m）、超车距离（20m）和障碍物停车距离（10m），而非简单地紧急制动，体现了精粒度的安全控制能力。

4.4 LLM 自动生成规则

论文使用 OpenAI o1 模型，通过提供 Agent 工具描述、3 条示例规则及其谓词函数实现，以及少量 in-context 示例，自动生成 AgentSpec 规则。训练/测试集按 1:9 比例分割。

关键指标：

代码 Agent：强制拦截率 87.26%。失败案例主要源于过拟合——LLM 倾向于仅在示例范围内泛化，例如只识别显式列出的敏感目录（/etc/），而忽略结构相似但未列出的路径
具身 Agent：精确率 95.56%，召回率 70.96%。低召回主要来自两类问题：(1) 对象属性识别不足（如未能识别"装满葡萄酒的水壶不适合加热"）；(2) 规则过于刚性（如"禁止液体倾倒"直接 ban 掉了所有 pour 动作，忽视了给植物浇水等安全场景）
自动驾驶 Agent：零样本条件下在 8 种违法场景中防止了 5 种。失败案例中，LLM 生成的规则过于简单粗暴（如检测到障碍物即紧急停车，缺少平滑跟车/让行/超车的分层策略）

4.5 性能开销

AgentSpec 的运行时开销由三部分组成：

解析时间：ANTLR4 解析规则的平均耗时约 1.42ms
谓词评估时间：代码域 2.83ms，具身域 1.11ms
执行时间：stop 为瞬时操作；user_inspection 取决于用户响应时间；invoke_action 取决于调用操作本身；llm_self_examine 受 LLM 推理延迟影响

对比 Agent 总执行时间（代码 Agent 平均 25.4s，具身 Agent 平均 9.82s），AgentSpec 引入的毫秒级开销几乎可忽略不计。

5. 启示与思考

5.1 "外置护栏" 范式的价值

AgentSpec 的核心设计哲学——将安全约束从 LLM 推理中解耦——值得深入思考。当前主流的 Agent 安全方案大多内置于 Prompt 或依赖 LLM 自身判断，但 LLM 的概率性本质决定了这种"软约束"无法提供确定性的安全保证。AgentSpec 的方案类似于操作系统中的 "user mode / kernel mode" 分离：Agent 在"用户态"自由推理和规划，安全规则在"内核态"执行确定性的权限检查。这种分离不仅提升了安全性，还带来了可审计性和可测试性的附加收益——每条规则的触发条件、评估过程和执行结果都可以被记录、回放和分析。

5.2 DSL 设计中的表达力与简洁性平衡

AgentSpec 的 DSL 设计刻意保持简洁：trigger、check、enforce 三段式结构，四种 enforce 动作，三类通用 trigger。但在实际使用中，check 部分的谓词函数仍然需要以 Python 代码实现，这意味着规则库的维护本质上还是需要一定编程能力。LLM 自动生成规则虽然缓解了这个问题，但生成的规则质量（特别是召回率）仍有提升空间——70.96% 的召回率在安全关键场景中可能不够。如何在 DSL 的表达力和使用便利性之间找到更优的平衡点，是这类系统面临的核心设计挑战。

5.3 从"当前步安全"到"轨迹安全"

AgentSpec 目前仅对当前动作进行即时安全评估，缺乏对长期后果的推理——即论文指出的"轨迹安全"（trajectory-based safety analysis）问题。一个当前安全的动作可能在若干步后导致不安全状态。论文提出的解决方案是使用离散时间马尔可夫链（DTMC）从历史交互中学习状态转移概率，计算不安全状态的可达概率。这本质上是在运行时验证（Runtime Verification）和概率模型检测（Probabilistic Model Checking）之间架起桥梁，是一个值得期待但实现复杂度较高的方向。

5.4 与现有 Agent 安全工作的关系

从我们之前解读过的几篇 Agent 安全工作来看，AgentSpec 占据了一个独特的位置：Intent-to-Execution Integrity 关注的是"意图到执行的正确性"，Agent Security Framework (SoK) 提供了安全威胁的分类学框架，SEFZ 关注特定漏洞的模糊测试，而 AgentSpec 提供的是一种通用的、可编程的运行时干预机制。它回答的问题是"无论威胁是什么，我在执行前如何拦截？"，这使得它可以作为前几项工作的一个互补组件——你可以在 AgentSpec 中编写规则来防御 Intent-to-Execution Integrity 论文中发现的各类意图偏差，也可以将 Agent Security Framework 中的威胁分类直接映射为 AgentSpec 的规则模板。

6. 参考

AgentSpec GitHub: https://github.com/haoyuwang99/AgentSpec
RedCode-Exec Benchmark (Guo et al., NeurIPS 2024)
SafeAgentBench (Yin et al., 2024)
FixDrive (Sun et al., ICSE 2025)
LangChain: https://www.langchain.com/langchain
Apollo Self-Driving: https://www.apollo.auto

研究