论文链接：https://arxiv.org/abs/2503.18666v3
论文主旨#
ICSE 2026，主要研究Agent运行时的安全约束，设计跨领域、易插拔的模块化框架用于规范Agent行为并降低风险。
Agent不同于大模型，它能够感知环境、并调用工具影响外界环境。这意味着Agent的错误不同于LLM，它会切实地造成现实中的严重后果，需要严格地规范和审查。
该论文认为不同的使用场景对Agent行为的风险容忍度不同，不能只依赖一套通用的安全策略，现实中需要的是可定制的运行时安全边界。然而，现有的方法还存在较大缺陷：
- 在动作执行前让另一模型来评估风险。然而交予大模型进行判断的质量不稳定，且可解释性弱，还可能受到提示词的影响。
- 只做风险评估，并没有真正拦截，无法在运行时生效。
因此，该论文提出了一个适用于Agent运行时生效、可自定义的规则语言：AgentSpec。不只是在动作执行前进行预测，而是在运行时进行检查，并调用对应的处理逻辑。主要将Agent的安全问题抽象成“事件-谓词-执行”的统一处理逻辑，将一条规则抽象成“trigger-check-enforce”，即当Agent在处理对应事件时，如果满足对应条件，则执行对应的干预命令。
出发点#
单纯的LLM更多是生成文本回答问题，无法感知现实世界并与外界环境进行交互。而Agent不一样，能够自主使用工具感知环境和影响环境，如Code Agent能够使用文件IO感知本地代码，修改或执行本地代码、联网检索资源等。故Agent在运行时的错误带来的风险和影响远大于LLM，需要规范Agent在运行时的行为。
此外，同样的行为在不同的场景可能需要不同的约束规则。如自动转账可以在内部测试环境里自行执行，但在现实生产环境中必须有人工授权或确认。
故该论文旨在设计一套泛用的、可无缝接入Agent的框架，拦截关键执行阶段以执行用户定义的约束。
创新点#
传统的减少Agent运行风险的方法有两种，但各有优劣：
- 基于LLM的风险评估虽然有效，但缺乏可解释性，且没有设计安全执行机制；
- 基于规则的防护提供了可审查、可解释的替代方案，但目前的实现要么太死板僵硬，要么缺乏跨Agent架构的通用性。
而AgentSpec则基于Neural-Symbolic思想，将LLM的泛化能力与硬规则的确定性逻辑有机结合，构建了一个可插拔且泛Agent的运行时安全框架。
方法流程#
论文中选用LangChain框架作为AgentSpec嵌入载体，通过拦截LangChain的Agent迭代循环中的关键决策点(动作执行前、观察产生后，任务完成时)来插入规则执行。其整体流程图如下：
LangChain核心循环是“接受输入->生成计划->执行动作->获取observation->进入下一步”，而AgentSpec则在其基础上增量添加了额外步骤。
常规Agent流程#
UserInput: 用户输入，最初始任务和上下文数据来源
Agent-Plan：根据上下文和轨迹，基于LLM生成计划动作，若已完成任务则输出。
Agent-Execute：根据计划，调用工具执行动作，得到执行后的Observation
Agent-Update：根据新的Observation更新Agent状态，并记录新的轨迹，继续返回Agent-Plan进行循环迭代
AgentSpec流程#
离线流程#
收集系统需要遵守的外部约束来源，并拆解成一系列“行为-条件-处理”的候选规则单元
确定每个规则单元的Trigger(before_action, state_change, agent_finish …)，将外部约束绑定至一类可监控的运行时切点
设计规则单元的Check，将自然语言描述的风险条件转变为可求值逻辑条件
为每个规则单元确定Enforcement，并最终整理成DSL规则，创建形式化规则模板
在线流程#
在Agent执行的关键节点(AgentAction, AgentStep, AgentFinish)拦截，获取当前状态、动作和轨迹等信息，并以此来匹配Trigger于此对应的规则，若无对应规则则放行
根据上下文信息，对Check求值，不成立则放行
根据对应规则，调用对应的处理逻辑，并根据处理结果更新轨迹，改写Agent运行轨迹
局限#
只能在遭遇特定事件、满足特定条件时才能触发安全机制，无法做到提前预测
AgentSpec的最终能力与predicate的质量强相关，而LLM自动生成的能力还不够稳定，无法做到开箱即用，需要人工预先定义