物界前沿智能体的每一步都要留证据
如果一个 agent 说它已经查过订单、改过配置、通知过下游，你凭什么信它。
这个问题最近被反复提起。微软那篇讲 agentic AI 验证框架，核心一句话很硬：只信你能验证的东西。它接在更早一篇文章后面，意思不是给模型再贴一层安全标签，而是把智能体从“会说话的程序”逼成“可审计的执行体”。我觉得方向对。但方向对不等于能直接抄。做编译器的人看这类话题，总会先拆一层：它到底在验证什么，验证的代价落在哪。
传统软件验证有抓手。函数输入输出有类型，模块边界有接口，状态变化有事务日志。哪怕再复杂的图执行，IR 里也能找到节点、依赖、shape、dtype、内存生命周期。agent 麻烦在中间那一大段推理。它不是普通函数，输入是自然语言和上下文，输出也是自然语言，工具调用夹在中间，还带副作用。你只拿最后结果做验收，等于只看一张图跑完后的 loss 曲线，不看每个算子有没有越界访存，有没有把不该读的张量读了。结果看起来合理，过程可能全是缝补。
我上周写过一篇把 agent 放进 Durable Object 的感想。当时觉得那有点像把算子融合：把状态和执行拉到一个局部，少跨网络搬运上下文。但后来越想越清楚，状态少搬不等于少验证。agent 把文件、数据库、API、子任务串起来，表面是工作流，底层是动态计算图。这个图今天能跑通，明天模型版本一换、提示词模板一调、工具权限一松，路径可能就变了。你要信它，不能只信它这次成功。你得让每一步都留下可重放的证据：谁发起了任务，用了哪个模型版本，调了哪个工具，工具参数是什么，返回了哪些字段，哪些权限被使用，哪些数据被写出，结果签名是否一致。
这就是验证框架里真正值钱的部分。零信任那套思路放到 agent 上，不是一句“不要信任模型”，而是把每个动作当成需要证明的边。身份要证明，意图要证明，工具调用要证明，结果要证明。Visa 和 Mastercard 都在推 agent 协议和可验证意图，底层依赖 FIDO、EMVCo、IETF、W3C 这些现成规范。听起来很热闹。但工程上有个老问题：证据链越完整，运行时越重。每加一次签名、日志、权限检查、回放校验，都会吃掉延迟和吞吐。就像算子融合没做好，数据在 HBM、SRAM、寄存器之间来回搬，算力再强也会被内存带宽卡住。agent 验证如果做歪了，也会变成新的带宽瓶颈：不是搬张量，是搬状态、搬日志、搬信任凭证。
我最近在昇腾910B上跑过一阵子推理相关的工作，也用过 DeepSeek、Qwen 这些模型做接口测试。体感很直接，端到端耗时里，模型生成只是一部分，工具等待、上下文组装、状态持久化、权限校验都能把尾延迟拉得很花。验证框架如果只在网关外面看 HTTP 状态码，意义有限。
真正要做，得下沉到运行时。给 agent 的执行轨迹建立一套 IR：任务计划是图，工具调用是算子，权限是属性，证据是 metadata，失败是异常边。这样你才能知道哪些步骤可以合并，哪些步骤必须串行，哪些结果可以被缓存，哪些副作用必须写前确认。说白了，不是给 agent 加一个安全仪表盘，而是把它当成一个可编译、可分析、可重放的系统。
当然，我也担心这事被说得太简单。有些讨论喜欢把验证写成合规清单：接个身份认证，签个请求，留个日志，就叫可信任 agent。这不够。清单只能证明你按流程走，不能证明模型没有胡说。LLM 的输出天然有随机性，上下文窗口又有限，长任务里早期约束会被后面的对话稀释。你让它自己写验收报告，它很容易写出一份漂亮但没根据的总结。这个毛病我在提示词模板里见过太多次。模板越花，越容易把“看起来像证据”当成“可验证证据”。边界没画好，工具越强越危险。
所以我的判断偏保守。agentic AI 要大规模进企业，最先跑通验证框架的一定不是开放式聊天，而是有明确副作用、明确责任边界、明确回滚机制的场景。支付、采购、审批、基础设施变更、客户工单处理，这些动作本来就要审计，验证框架有现成收益。反过来，那种一句话让 agent 去“研究一下市场并写个方案”的场景，短期内很难靠协议解决。你可以验证它访问了哪些网页，用了哪些数据源，但你很难自动验证结论是否可靠。真值验证的成本太高，最后还是人兜底。
往后看，我倾向于认为智能体竞争会从“谁的模型更会说”转到“谁的执行轨迹更可证明”。短期是各家推协议，中期会下沉到框架和运行时，长期可能变成一种新的编译器问题：把自然语言意图编译成带权限、带证据、带不变量的可重放执行图。这个算子融合了吗，现在还没。但方向已经露出来了，别急着画饼，先把边界画清楚。
📌 本文编译自 Hacker News，原文：https://devblogs.microsoft.com/all-things-azure/only-believe-what-you-can-validate/
版权归原作者所有，本文为基于公开报道的编译与独立分析。
