AI智能体最难的不是造一个，是管五个

大多数AI智能体的演示视频都在优化第一次成功运行。真正投入生产的团队，关心的是第十次失败运行。当你拥有不止一个智能体时，难题就变了：哪个智能体碰过这个文件？哪个工具调用生成了这个产物？当时哪个MCP服务器可用？哪个模型和提示词版本做出了决策？是人类批准了操作，还是自动放行？上次正常运行和这次出错之间发生了什么？能不能暂停、重放、修复或回滚这次运行？

这就是为什么我认为每个严肃的智能体系统都需要一份智能体运行记录。

什么是智能体运行记录？它是一份紧凑、可检查的记录，记载智能体运行期间发生了什么。不是庞大的日志转储，不只是追踪数据，也不是聊天记录。一份有用的运行记录应该回答：给定这个结果，到底发生了什么、在什么配置下、用了哪些工具、我们有什么证据？

对于编程、浏览器或基于MCP的智能体，我至少想要这些信息：runId（完整的智能体或工作流运行标识）、turnId（触发工作的用户回合）、agentId（负责的智能体或子智能体）、model（提供商、模型ID和配置）、promptVersion（模板或指令哈希）、toolRegistry（哪些工具或MCP服务器可用）、toolCallId（每次工具调用的稳定标识）、sideEffect（读取、写入、执行、网络、部署、支付等）、approvalState（无需批准、已请求、已批准、已拒绝、已过期）、inputRefs（引用输入但不永久存储敏感载荷）、outputRefs（产物、文件、PR、浏览器操作或生成的数据）、retryState（重试、超时、备用模型路由）、finalStatus（成功、失败、暂停、升级、已回滚）。

这听起来很无聊，直到智能体做出令人惊讶的事。然后它就变成了所有人唯一想要的东西。

追踪数据是不够的。OpenTelemetry风格的追踪很有用，它们帮助处理延迟、错误、重试和服务边界。但智能体操作者往往需要一个不同的对象。追踪能告诉你哪个跨度很慢，运行记录应该告诉你：智能体认为自己在做什么、它被允许使用哪些工具、哪些操作有副作用、适用哪条策略或批准状态、产生了什么产物、这次运行与已知正常运行的差异。换句话说：追踪解释执行，运行记录解释责任。两者都需要。

MCP让这件事更重要。MCP很棒，因为它给智能体提供了访问工具和上下文的通用方式。这也意味着智能体突然能与更多系统交互：数据库、浏览器、代码仓库、云API、内部工具、本地文件、长期运行的服务。这让工具边界成为运营边界。如果模型调用了MCP工具，我想知道：哪个主机/客户端发起了调用、哪个MCP服务器执行了它、当时哪个确切的工具模式处于活跃状态、传递了哪些参数、调用是只读的还是带有副作用、是否需要批准。