当 AI Agent 声称它完成了一项任务时，保持怀疑是唯一理智的反应。一条显示“任务于 14:32 完成”的日志条目仅仅是一串文本。Agent 可能在静默状态下崩溃、提交了空白表单、在空的搜索结果中陷入死循环，或者幻觉出了整个工作流。如果你的架构涉及在不同机器、云区域或 IP 地址上运行的多个 Agent，问题会迅速恶化。除非 Agent A 能展示其工作过程，否则 Agent B 没有理由相信 Agent A 的报告。

每个可信的验证系统都建立在三个层级之上。证据 (Evidence) 是原始产物——如截图、API 响应或 HTML 转储。证明 (Attestation) 是经过签名或加密的声明，将该证据与特定的 Agent 和特定的任务 ID 绑定在一起。验证 (Verification) 是确认证据确实满足了原始目标的过程，而不仅仅是确认文件存在。没有证明的证据可以从一个任务重用到另一个任务中。没有验证的证明只能告诉你数据是真实的，但不能告诉你它是否回答了你提出的问题。

视觉证明：截图与 OCR

当 Agent 驱动浏览器或与图形界面交互时，最简单的证明就是一张图片。Agent 在操作完成后捕获全屏截图，运行 OCR 以提取可见文本，并将图像和提取的字符串作为证据提交。

这种模式适用于社交媒体帖子、表单提交或结账流程。想象一下，一个 Agent 被指派在公司的 LinkedIn 页面上发布每周更新。截图显示了实时发布的帖子，其中包含服务器渲染的时间戳，且 URL 中嵌入了帖子 ID。OCR 可以确认准确的标题和正文内容与这些平台特定的标记一起出现在页面上。

风险显而易见：截图可以造假。一个被攻破的 Agent 可以在本地渲染一个虚假网页，对其进行截图，然后宣布成功。为了提高门槛，需要引入难以预测的动态文本标记。平台颁发的确认 ID、来自服务器的时间戳，或者验证器附加到任务指令中的唯一随机数 (nonce)，都可以作为锚点。如果 OCR 输出不包含与该特定任务绑定的预期确认 ID，则证明失败。

不过，截图非常“重”。它们消耗带宽和存储空间，并且当平台重新设计布局时，它们会失效。仅在 UI 是唯一可用界面时使用它们，但应将其视为基准，而非堡垒。

签名 API 收据

当 Agent 通过后端 API 工作时，跳过图像，要求提供签名收据。

在自动发布或数据抓取之后，平台通常会返回一个结构化负载 (payload)。该 JSON 包含 ID、时间戳、状态字段，有时还包含速率限制 (rate-limit) 请求头。Agent 使用私钥对整个负载进行签名，将任务 ID 包含在签名的二进制大对象 (blob) 中，然后提交该数据包。验证器根据 Agent 的公钥检查签名，并检查收据以确认操作成功。

这里的弱点在于密钥托管。如果 Agent 在运行的同一台机器上持有自己的私钥，那么提示词注入 (prompt injection)、恶意软件爆发或容器逃逸可能会提取该密钥，并为从未发生过的任务伪造收据。不要将长期有效的密钥硬编码到 Agent 的环境中。相反，应使用能够发放短期、任务范围凭证的密钥管理系统。为每个任务轮换密钥。如果 Agent 必须从安全飞地 (secure enclave) 或 KMS 请求一个仅限五分钟窗口的签名密钥，那么即使发生泄露，其爆炸半径 (blast radius) 也会保持在很小的范围内。

这种模式最适用于高吞吐量的无头自动化 (headless automation)：同步广告支出报告、通过社交媒体 API 发布内容，或抓取返回结构化 JSON 的端点。它比截图更轻量，且通过程序进行验证要容易得多。

用于持续工作的证明链

某些任务无法被纳入单个