PROBE 论文导读：检查 Agent 的行动，而不只看最终回答
从近期政策审计研究出发，建立工具轨迹、规则覆盖和确定性复核清单。
Foxmu · 更新日期: 2026-10-19
论文原文: PROBE: Learning to Audit Policy Compliance in Tool-Using LLM Agents · 论文提交日期: 2026-10-15 · v1
研究对象与阅读范围
PROBE 研究使用工具的 Agent 如何接受政策合规审计。本文阅读的是 2026-10-15 提交的 arXiv v1，实验覆盖两个环境，工具使用以搜索操作为主。
以下内容是 Foxmu 编辑提出的工程检查建议，不是论文复现实验，也不代表 Foxmu 已通过该基准。阅读研究时，应先核对版本、评估对象和判定方式，再决定哪些思路值得迁移到自己的应用中。
工程建议：把政策写成可检查的规则
一条规则应包含操作、触发条件和预期决定。例如，客服 Agent 可以读取当前客户的工单，但即使提示词提供了另一个租户的工单编号，也不能访问该工单。规则需要关联负责人和风险等级，便于失败后判断处理优先级。
将可由可信代码检查的要求，与需要人工判断的要求分开。“谨慎处理”“保证安全”过于笼统，无法形成重复执行的验收用例。测试应说明允许什么、拒绝什么，以及具体在哪个环节阻止。
检查完整行动轨迹
用最少事件元数据关联请求、工具提议、授权决定、执行结果和最终回答。使用稳定标识串联事件，而不是把敏感参数复制到通用日志。检查范围同时包含被拒绝的提议与真正执行的操作。
最终回答看起来无害，并不能排除之前曾尝试越权；相反，正确拒绝危险操作可能是成功的政策结果，即使用户最初的任务没有完成。将任务完成情况与规则遵守情况分开记录，才能解释这两类结果。
衡量覆盖面，并复核判定
建立规则与正常、边界、对抗样例的矩阵，区分触达了多少条规则和某一种失败出现了多少次。反复触发同一个容易发现的违规，并不能说明其他规则已经接受测试。对未触达的规则应明确标记，不能算作通过。
资源归属、审批状态、次数限制和业务状态变化优先使用确定性校验。模型评审发现问题后，回到原始事件与预期规则复核，再确认是否违规。评审器自身也可能产生误报，应保留人工审核过的对照样例。
局限与可执行的下一步
论文的环境范围有限，搜索操作占比较高，因此结论不能直接覆盖所有生产工具。只测搜索，无法证明删除、财务操作或权限不断变化的长工作流同样可靠；语义判断也不可能完全由简单规则替代。
可以从一个只读集成和一小组经过评审的规则开始，再为状态修改动作补充专用数据、审批检查及回滚预期。发布时列出测试版本和未覆盖项，并结合工具调用与 MCP 清单完成协议与业务执行验收。