智能体时代，审计轨迹正在变成产品基础设施
智能体的价值不只是替人执行动作，更在于留下可复核的证据链：为什么执行、依据是什么，以及责任最终落在哪里。
重要的不是智能体能执行更多动作，而是每个动作都需要留下持久、可复核的解释。因为一旦动作出错或被质疑，代价就会从模型本身转移到组织的运行记录上。
工具调用型智能体正在普及，Model Context Protocol 这样的开放协议也在让模型更容易读取上下文、调用工具、把任务交给其他系统。但当这条链路进入客户数据、权限体系和业务流程后，“模型给出了答案”已经不是足够的记录。真正有价值的产品，是动作本身加上一份简洁的记录：它依据了什么证据，拥有什么权限，责任在哪个边界上被接住。
这是一类藏在智能体功能里的基础设施机会。
动作链条如何制造证据债务
传统软件的轨迹相对清楚：用户点击，接口接收请求，数据库记录变化。智能体软件在这些事件之间加入了概率性判断。它可能决定读哪些文件、调用哪个工具、传递什么参数，以及出错后是否重试。
把所有 token 都保存下来并不能解决问题。对操作人员来说，逐字转录太嘈杂；对事后调查来说，它也未必能回答关键问题。真正应该持久化的是决策记录：任务是什么、成功条件是什么、哪些证据影响了这一步、哪条政策或权限允许它执行、工具返回了什么，以及谁或哪个系统接住了后果。
这就是证据债务。智能体还是演示时，团队可以把它往后推；一旦客户追问某个账户为何被修改，审查人员需要复现结果，或工程师必须定位长链条里的第一处错误，就再也推不动了。
市场容易误读的地方
一种常见判断是：智能体基础设施最终属于规划循环最强的平台。规划当然重要，但它只是采用门槛的一部分。在高风险业务里，买方可能更愿意选择少做几个动作、但能留下清晰轨迹的智能体，而不是执行更多动作却无法解释的系统。
另一个看似稳妥的办法，是保存完整 prompt，把它当作可观测性。问题是，完整留存会带来隐私、存储和审阅成本，却仍然未必能回答：究竟是哪份资料影响了动作？当时使用的权限是什么？智能体依据的是不是过期信息？执行前结果有没有被人修改？
真正的取舍不是“完全透明”对“完全保密”，而是选择性溯源对无法使用的数据堆积。
产品应该设计成可回放的责任链
开发团队应把智能体的动作记录做成一等对象，至少保留：
- 任务进入系统时对目标和成功条件的理解；
- 实质影响该步骤的来源或工具结果；
- 授权动作的权限、政策或用户确认；
- 外部系统实际发生了什么，并区分建议与执行；
- 人或下游系统在哪个节点接手了责任。
这份记录还应该按结果搜索，而不只是按 session ID 搜索。运营人员应能找到所有失败的供应商更新、所有使用过期数据的动作，或所有绕过必需确认的批准。这样的查询面，往往比一张漂亮的 trace 瀑布图更有价值。
这也延续了站内关于智能体交易证据账本和领域知识如何约束 AI 编程的讨论：领域知识只有在规定可接受证据和升级条件时，才真正进入运行机制，而不只是被放进 prompt。
接下来观察什么
观察智能体平台是否提供可迁移的决策记录，而不是把可观测性锁在自己的后台里。值得追踪的指标包括：回放成功率、定位错误动作所需时间、带有明确授权的动作比例，以及只保留决策相关证据的成本。
有人会反驳，更强的模型会让这些记录变得不必要。更强的模型确实可能降低错误率，但可靠性提高后，组织也会愿意把更多动作交给智能体。委托范围扩大，争议和过期上下文的后果只会更大。
智能体竞赛表面上是在争夺自主性，生产环境里真正的竞争，可能是在争夺“可负责的记忆”：系统能否说明自己当时知道什么、被允许做什么，以及最后是谁对结果负责。
来源：Model Context Protocol 规范；NIST《AI 风险管理框架》。