AI 需要收据而非承诺
AI Signals & Reality Checks（2026 年 2 月 23 日）
信号
*智能体走向下一阶段的采用时，“能力”不再是主要的采购决策点。真正的差异化会变成：凭证（receipts）。*
当智能体进入那些“出错代价很高”的场景（财务运营、医疗行政、合规、采购、IT 变更等），买方开始用另一种方式提问：
“给我看它做了什么、触碰了什么、依赖了什么证据、谁批准了它。”
听起来像是官僚主义，但这其实是现实世界的产品市场匹配（PMF）。
在落地中，最强的智能体产品正在收敛到一个非常朴素的模式：审计轨迹（audit trail）不是事后补丁，而是一等公民的产品界面。
它不是一段“运行总结”就完事，而是一条结构化、可查询的轨迹，能够回答这些问题：
- **输入：**用到了哪些文档、工单、邮件、数据库行、或 API 请求/响应？
- **转换：**经历了哪些步骤（抽取 → 规范化 → 决策 → 写入）？
- **证据：**每个关键结论/动作对应的引用与工件是什么？
- **控制：**通过了哪些策略检查（隐私脱敏、权限范围、职责分离）？
- **决策：**在哪些节点发生分支？有哪些备选方案？
- **审批：**哪些步骤需要人工签核？由谁批准？
- **输出：**外部系统到底改了什么（前后差异 diff）？
这也是为什么“智能体 UX”正在悄悄变大：它不再只是一个聊天框 + 一个“成功”提示，而越来越像：
- 工具调用与检查的时间线，
- 面向写入操作的 diff 查看器，
- 策略台账/账本（“此动作通过规则 X，未通过规则 Y，于是升级处理”），
- 以及可以交给审计/复核团队的可检索运行历史。
这个变化的核心在于：信任正在变成一种“可运营”的系统属性，而不是品牌属性。
两个产品可能使用同一个基础模型；在企业与受监管场景里，提供更好“凭证”的那个会赢。
现实校验
“有日志”不等于“有凭证”。凭证需要被设计出来，而且会带来艰难的权衡。
当团队试图“先把审计日志加上去再说”时，通常会立刻遇到三个现实问题：
- 如果不可复核（reviewable），就不会带来信任 原始的工具调用 dump 在规模化之后根本读不动。人需要的是“渐进式展开”（progressive disclosure）：
- 先给一段高层摘要（“改了什么、为什么改”），
- 再能展开证据（“给我看源片段/请求 payload”），
- 并且明确标记风险（“此步骤低置信/越界/重试过”）。
可以把它当作生产系统可观测性的同构：日志（原始）、指标（聚合）、链路追踪（结构化叙事）。真正的“凭证”更多存在于“追踪/trace”这一层。
- 凭证必须“最小化”且“隐私友好” 最天真的做法是“先把一切都存下来，以防万一”。这通常会直接触发合规风险。
更好的默认策略是：
- 能不复制就不复制，用 hash/引用 来证明完整性与可追溯性，
- 对敏感字段做脱敏或令牌化（PII、PHI、密钥等），
- 并且按工作流设置保留周期与边界。
关键的微妙点在于：**审计轨迹本身也是敏感数据集。**一旦你构建了它，就必须像保护生产数据一样保护它。
- 最难的是把“凭证”连接到“强制执行（enforcement）” 很多产品可以事后解释“发生了什么”。但能在当下阻止错误发生的要少得多。
真正的护城河，是把轨迹与控制打通：
- 没有通过校验的 diff 就不允许写入，
- 没有策略闸门就不能安排付款，
- 没有证据附件就不能关闭工单，
- 任何模棱两可的情况自动进入人工队列。
凭证的力量在于，它不仅是叙事（“发生了什么”），更是契约（“允许什么、并证明没有越界”）。
**结论：**当智能体扩散到各类流程，优势会从“我们的模型更聪明”转向“我们的系统能产出可核验的工作”。在高风险环境里，凭证胜过承诺。