Do ≠ See：当 Agent 看见成功，却仍然不该行动

我们研究的不是“AI Agent 会不会犯错”这样宽泛的问题，而是一个更具体、更危险的瞬间：

Agent 刚刚执行了一个动作，工具返回成功，但受保护目标可能已经失效。仅凭这条成功回执，Agent 是否会继续批准一个不可逆操作？

这就是 Do ≠ See 的核心命题：

执行成功，不等于目标仍然成立；看见成功，也不等于获得授权。

从一个直觉开始

在工具型 Agent 中，常见的工作流是：

1. Agent 调用工具执行动作；
2. 工具返回成功；
3. Agent 根据成功回执判断任务已经完成；
4. Agent 继续执行提交、发布、删除或其他不可逆操作。

这种流程在正常情况下非常自然。但问题在于，工具返回的成功通常只说明：

某个局部动作成功发生了。

它未必说明：

• 保护条件仍然成立；
• 目标对象没有变化；
• 当前结果仍然满足任务要求；
• 下一步操作已经获得授权。

因此，我们将“动作成功回执”视为一种局部代理信号，并把它与真正需要保护的目标状态分开。

第一阶段：先观察自然发生的机会

最初的研究路线是观察普通任务中是否自然出现这种错位。

P11-B 对四类 software-workspace 任务进行了普通前缀普查，覆盖三种模型配置，共计 144 个前缀。我们记录了 Agent 的候选动作、实际可执行的变更，以及局部成功代理信号与受保护目标之间的关系。

公开聚合结果如下：

| 指标 | 数值 | | --- | ---: | | 普通任务前缀 | 144 | | 模型配置 | 3 | | 任务族 | 4 | | 候选动作审计 | 1,475 | | 合格变更 | 880 | | 代理信号为真、目标为真 | 434 | | 代理信号为真、目标为假 | 0 | | 代理信号为假、目标为假 | 446 |

最关键的结果是：

在 144 个普通前缀中，没有观察到“局部成功代理信号为真，但受保护目标已经为假”的自然动作。

这意味着普通任务中的自然机会不足以估计我们真正关心的错误授权行为。

零不是安全证明

这个结果很容易被误读。

“代理信号为真、目标为假”的数量为零，并不等于 Agent 已经被证明安全，也不等于错误授权概率为零。

它只说明：

在这批普通任务中，没有自然出现足以测量该错误模式的条件。

因此，以下问题仍然无法从 P11-B 得到答案：

• Agent 是否能够识别因果来源；
• Agent 是否会在成功回执后错误批准行动；
• 自然故障发生率是多少；
• 这种行为是否普遍存在于生产环境；
• Agent 是否整体安全。

P11-B 的价值在于，它帮助我们准确定位了自然机会研究的边界： 如果目标状态不会自然失效，就无法仅靠普通任务观察错误授权。

第二阶段：把缺失条件引入实验

在此基础上，我们设计了 P12。

P12 不再等待故障自然发生，而是在严格控制的条件下，将一个可信的局部失败注入到：

成功动作回执之后、授权证据出现之前。

这样可以保持同一个前缀、同一个动作和同一个即时回执，只改变 Agent 在最终决策前能够看到的证据。

设计包含六个匹配的证据分支，用于比较：

• 只看到局部成功回执；
• 看到成功回执和目标状态；
• 看到可信失败；
• 看到不同来源的授权证据；
• 暂缓决策；
• 最终提交。

这种设计的目的不是制造一个更复杂的任务，而是隔离一个具体因果问题：

当成功回执仍然可见，但目标已经失效时，什么证据会改变 Agent 的授权判断？

P12 的首个四前缀试验被排除在确认性估计之外。当前公开版本只包含 P12 的冻结设计和 provider-free 预检，不宣称任何 P12 在线行为结果。

基础设施本身也是研究条件

在后续准备过程中，我们遇到了多类服务与执行器问题：

• 模型 ID 与实际注册名称不一致；
• provider 工具调用参数和路径兼容性问题；
• 工具循环没有正确注入候选模型；
• AppWorld 解释器选择错误；
• HTTP 500、502、503、504 等服务端错误；
• 请求重试、并发配额和账户排他锁问题；
• 失败运行产生了不完整 transcript。

这些问题不能被当作 Agent 行为结果。

因此，所有相关阶段都采用了 fail-closed 原则：

• 身份不匹配，停止；
• 运行时不匹配，停止；
• 请求无法完整结束，停止；
• 结果封装不完整，停止；
• 不把部分运行结果并入正式分析；
• 不读取或分析不完整行为轨迹。

这让研究变慢了，却保留了结果的可解释性。 如果一次实验无法确认模型、工具、运行时和请求边界，那么它就不能承担行为结论。

我们目前真正知道什么

目前可以支持的结论是：

1. 在 P11-B 的普通任务普查中，Agent 经常提出有效变更；
2. 但没有自然出现“局部成功代理信号与受保护目标分离”的条件；
3. 因此，普通任务普查无法估计错误授权；
4. P12 提供了一个用于研究该条件的冻结实验设计；
5. 所有基础设施失败和不完整运行均未纳入行为结论。

目前不能声称：

• Agent 已经被证明安全；
• 错误授权概率为零；
• Agent 能够正确识别因果来源；
• 该现象在所有模型、任务或生产环境中普遍存在；
• P12 已经产生了在线确认性结果。

公开研究版本

我们已经公开了经过清理的研究仓库：

Do ≠ See：fault-conditioned authorization in tool-using agents

公开仓库包含：

• P11-B 聚合结果；
• P12 实验设计；
• provider-free 零调用预检；
• 确定性测试；
• 结果分类和边界说明；
• GPT-image 生成的研究插图。

原始凭据、Ollama 请求与响应正文、行为 transcript、私有运行目录和未审计历史结果均未公开。

Do ≠ See 研究概念图

P11-B 普查结果

P12 故障条件授权设计

另外，我们也公开了一个用于记录 Agent 事实、测试、决策和失败路径的本地证据账本插件：

dsh-evidence-ledger

下一步

这项研究接下来只需要回答一个核心问题：

当 Agent 看见自己的动作成功，但同时获得可信证据表明受保护目标已经失效时，它是否仍然会批准不可逆行动？

P11-B 说明，普通任务很难自然产生这个条件。 P12 则把这个条件明确构造出来，并将授权判断拆成可比较的证据分支。

这也是 Do ≠ See 最重要的转变：

研究重点从“Agent 会不会犯错”，转向“什么证据让错误授权发生，什么证据能够阻止它”。