# PROBE 论文导读：检查 Agent 的行动，而不只看最终回答

从近期政策审计研究出发，建立工具轨迹、规则覆盖和确定性复核清单。

Foxmu · 更新日期: 2026-10-19

论文原文: [PROBE: Learning to Audit Policy Compliance in Tool-Using LLM Agents](https://arxiv.org/abs/2610.22124) · 论文提交日期: 2026-10-15 · v1

## 研究对象与阅读范围

PROBE 研究使用工具的 Agent 如何接受政策合规审计。本文阅读的是 2026-10-15 提交的 arXiv v1，实验覆盖两个环境，工具使用以搜索操作为主。

以下内容是 Foxmu 编辑提出的工程检查建议，不是论文复现实验，也不代表 Foxmu 已通过该基准。阅读研究时，应先核对版本、评估对象和判定方式，再决定哪些思路值得迁移到自己的应用中。

## 工程建议：把政策写成可检查的规则

一条规则应包含操作、触发条件和预期决定。例如，客服 Agent 可以读取当前客户的工单，但即使提示词提供了另一个租户的工单编号，也不能访问该工单。规则需要关联负责人和风险等级，便于失败后判断处理优先级。

将可由可信代码检查的要求，与需要人工判断的要求分开。“谨慎处理”“保证安全”过于笼统，无法形成重复执行的验收用例。测试应说明允许什么、拒绝什么，以及具体在哪个环节阻止。

## 检查完整行动轨迹

用最少事件元数据关联请求、工具提议、授权决定、执行结果和最终回答。使用稳定标识串联事件，而不是把敏感参数复制到通用日志。检查范围同时包含被拒绝的提议与真正执行的操作。

最终回答看起来无害，并不能排除之前曾尝试越权；相反，正确拒绝危险操作可能是成功的政策结果，即使用户最初的任务没有完成。将任务完成情况与规则遵守情况分开记录，才能解释这两类结果。

## 衡量覆盖面，并复核判定

建立规则与正常、边界、对抗样例的矩阵，区分触达了多少条规则和某一种失败出现了多少次。反复触发同一个容易发现的违规，并不能说明其他规则已经接受测试。对未触达的规则应明确标记，不能算作通过。

资源归属、审批状态、次数限制和业务状态变化优先使用确定性校验。模型评审发现问题后，回到原始事件与预期规则复核，再确认是否违规。评审器自身也可能产生误报，应保留人工审核过的对照样例。

## 局限与可执行的下一步

论文的环境范围有限，搜索操作占比较高，因此结论不能直接覆盖所有生产工具。只测搜索，无法证明删除、财务操作或权限不断变化的长工作流同样可靠；语义判断也不可能完全由简单规则替代。

可以从一个只读集成和一小组经过评审的规则开始，再为状态修改动作补充专用数据、审批检查及回滚预期。发布时列出测试版本和未覆盖项，并结合[工具调用与 MCP 清单](/learn/tool-calling-mcp)完成协议与业务执行验收。

## 参考与接入指南

- [Foxmu 文档中心](https://foxmu.ai/docs)
- [PROBE — arXiv record](https://arxiv.org/abs/2610.22124)
- [PROBE — v1 full text](https://arxiv.org/html/2610.22124v1)