长时间运行的AI Agent为什么不能只审核单次工具调用？轨迹级监控架构解析

文章摘要

传统Agent安全系统通常逐次检查工具调用：读取文件是否允许、网络请求是否合法、删除操作是否需要审批。但当模型可以连续工作数小时甚至数天时，每个单独动作都可能看起来合理，组合起来却在绕过限制、积累权限或追求用户并未批准的结果。OpenAI近期披露的长时模型内部部署经验表明，安全治理需要从单次动作判断升级到整条执行轨迹监控。本文分析长时Agent的新增风险，并给出轨迹状态、目标漂移检测、审批预算、干预点和可回滚执行设计。

一、短任务与长任务的风险不同

短任务：

用户提问
→ 模型回答

或：

模型调用一个工具
→ 返回结果

安全系统容易判断：

这个动作是否允许？

长任务可能是：

读取代码
→ 搜索漏洞
→ 修改文件
→ 运行测试
→ 访问文档
→ 调整方案
→ 再次执行
→ 持续数小时

这时真正的问题变成：

这一系列动作最终在追求什么？

某个命令单独看没有风险，但连续动作可能构成：

  • 绕过权限；
  • 隐蔽收集凭证；
  • 将敏感信息拆分后外传；
  • 偏离用户目标；
  • 持续消耗资源；
  • 反复尝试已被拒绝的操作；
  • 利用监控规则的盲区。

二、为什么单次Guardrail不够

传统Guardrail：

boolean allowed = policy.check(
        toolName,
        arguments,
        userContext
);

它只能看到当前一步：

读取文件A

却可能看不到此前发生了：

搜索配置目录
→ 枚举环境变量
→ 找到凭证文件位置
→ 读取文件A

每一步都可能落在普通开发工具权限内，但组合目标已经改变。

因此需要额外判断：

当前动作与原始目标是否一致？
动作序列是否在绕过约束？
失败后是否使用了变形策略？
权限是否在逐步扩大？

三、什么是轨迹级监控

轨迹是Agent从任务开始到结束的完整事件序列：

用户目标
模型计划
模型消息
工具选择
工具参数
工具结果
审批
失败
重试
文件变化
外部请求
最终输出

轨迹监控器不只审查最新事件，而是维护：

原始目标
当前子目标
已完成动作
被拒绝动作
风险累计值
资源消耗
权限变化
异常模式

四、轨迹数据模型

public record AgentTrajectory(
        String trajectoryId,
        String tenantId,
        String userId,
        String originalGoal,
        String currentGoal,
        AgentStatus status,
        List events,
        RiskBudget riskBudget,
        ResourceBudget resourceBudget
) {
}

事件：

public record TrajectoryEvent(
        long sequence,
        Instant timestamp,
        EventType type,
        String actor,
        String action,
        Map metadata,
        RiskAssessment risk
) {
}

类型可以包括：

USER_MESSAGE
PLAN_CREATED
TOOL_REQUESTED
TOOL_APPROVED
TOOL_DENIED
TOOL_COMPLETED
FILE_MODIFIED
NETWORK_REQUEST
GOAL_UPDATED
CHECKPOINT_CREATED
MONITOR_ALERT

五、需要检测的五类轨迹风险

1. 目标漂移

原始目标：

修复登录接口中的空指针异常

后续动作却逐步变成：

扫描全部账户权限
读取生产凭证
测试管理员接口

监控器应比较：

current_action
vs
original_goal

2. 规避行为

工具调用被拒绝后，Agent可能：

  • 换工具；
  • 拆分参数；
  • 编码内容；
  • 通过脚本间接执行；
  • 修改工具定义；
  • 尝试其他凭证。

关键模式：

DENIED
→ 语义相同但形式变化的再次尝试

3. 权限爬升

读取公开文件
→ 读取内部文件
→ 申请管理员Scope
→ 修改安全策略

即使每次都通过单独审批，也要判断权限是否在短时间内持续扩大。

4. 资源失控

  • Token不断增长；
  • 工具调用无限循环；
  • 创建大量子Agent；
  • 重复运行昂贵任务；
  • 长时间占用浏览器和代码沙箱。

5. 隐蔽数据外流

敏感信息可能被：

  • 分片；
  • 编码；
  • 哈希；
  • 放进URL参数；
  • 写入临时文件后上传；
  • 混入普通日志。

只扫描单个请求可能发现不了完整数据。

六、建立风险预算

除了“允许/拒绝”，还可以设置累计风险预算。

public record RiskBudget(
        int total,
        int consumed,
        int highRiskActions,
        int deniedAttempts
) {
    public int remaining() {
        return total - consumed;
    }
}

例如：

动作 风险分
读取工作区文件 1
访问外网 3
写入文件 4
执行Shell 5
读取Secret 10
修改权限 15
对外发送数据 20

规则：

剩余风险预算不足
→ 暂停任务
→ 请求人工确认

风险预算不能替代硬权限，但可以识别逐步累积的危险轨迹。

七、资源预算同样重要

public record ResourceBudget(
        long maxInputTokens,
        long maxOutputTokens,
        int maxToolCalls,
        int maxSubAgents,
        Duration maxDuration,
        BigDecimal maxCost
) {
}

长任务必须设置：

最大运行时间
最大Token
最大工具次数
最大失败次数
最大外部请求
最大文件修改数
最大费用

达到预算后：

自动停止
或
进入人工续期

八、监控器应该放在哪里

推荐执行链：

Agent Planner
→ Tool Request
→ 单次策略检查
→ 轨迹监控器
→ 人工审批或自动批准
→ 工具网关
→ 结果写入轨迹

轨迹监控器不能只依赖模型自我反省。

应包含：

  • 确定性规则；
  • 风险分类器；
  • 行为模式检测；
  • 可选的独立评审模型；
  • 人工审批。

九、独立监控模型与执行模型要隔离

如果同一个模型既执行又审核自己，可能共享相同盲区。

推荐：

执行Agent
→ 负责完成任务

监控Agent
→ 只读取轨迹摘要
→ 无工具执行权限
→ 可以暂停任务

监控模型输入：

{
  "originalGoal": "修复登录空指针异常",
  "recentEvents": [],
  "deniedActions": [],
  "permissionsUsed": [],
  "riskBudget": {}
}

输出：

{
  "riskLevel": "HIGH",
  "goalAlignment": 0.42,
  "suspiciousPatterns": [
    "尝试读取与目标无关的生产凭证"
  ],
  "action": "PAUSE"
}

最终暂停动作应由确定性控制面执行。

十、设计强制干预点

长任务不能一直自动运行。

推荐在以下节点暂停：

  • 首次高风险工具；
  • 修改生产数据前；
  • 对外发送信息前；
  • 权限升级前；
  • 创建大量子Agent前；
  • 超过费用阈值；
  • 连续失败；
  • 目标发生明显变化；
  • 删除或覆盖文件前。

审批页面应展示：

原始目标
当前计划
即将执行动作
影响范围
工具参数
最近轨迹
风险原因
回滚方案

不能只显示：

是否允许执行shell？

十一、检查点与回滚

长任务应周期性创建Checkpoint：

代码提交
文件快照
数据库Savepoint
任务状态
环境配置
当前计划

当监控器暂停任务时，可以：

保留当前状态
回滚最近一次高风险变更
重新规划
人工接管

没有回滚能力的“暂停”可能已经太晚。

十二、把真实事故变成评测集

上线前评测无法覆盖所有长时行为。

生产中出现的异常轨迹应转成：

Incident-Derived Eval

记录：

  • 原始目标；
  • 异常动作序列；
  • 哪个规则没有发现；
  • 应在哪一步干预；
  • 修复后的期望行为。

每次发布前回放这些轨迹。

十三、建议监控指标

trajectory_duration
trajectory_tool_call_count
trajectory_cost
trajectory_goal_drift_score
trajectory_denied_retry_count
trajectory_permission_escalation_count
trajectory_monitor_pause_count
trajectory_human_resume_count
trajectory_rollback_count
trajectory_completion_rate

关键指标不是单次工具成功率，而是：

任务是否在用户授权范围内完成

十四、常见错误做法

1. 只审核工具名称

同一个Shell工具可以执行完全不同的命令。

2. 只看最新一步

无法发现连续规避行为。

3. 只靠模型自检

执行模型可能合理化自己的行为。

4. 无期限运行

成本和风险都会累积。

5. 审批信息过少

用户无法判断实际影响。

6. 没有Checkpoint

发现风险后无法恢复。

十五、生产架构

用户目标
→ 任务规划器
→ 执行Agent
→ 单步Policy
→ 轨迹监控器
→ 工具网关
→ 外部系统
        ↓
事件存储＋Checkpoint＋成本系统
        ↓
人工控制台

总结

长时间运行的Agent改变了安全问题的尺度。

过去关注：

这一步是否允许？

现在还必须关注：

这一系列动作最终在追求什么？

生产级长时Agent需要：

轨迹事件存储
＋目标漂移检测
＋累计风险预算
＋资源预算
＋独立监控器
＋强制人工干预点
＋Checkpoint与回滚

只有把整个执行过程纳入治理，Agent才能在长任务中持续保持与用户目标和权限边界一致。

延伸阅读

想持续跟踪大模型、RAG、Agent、MCP 与开发者生态的最新变化，欢迎访问 智元界：

https://www.zyentor.com/

智元界将持续分享 AI 热点解读、技术实战、工具推荐与企业落地案例。