出问题时，最后一句回答不够用

Agent 做演示时，大家最关心它能不能把任务做完。Agent 进生产后，第一个现实问题会变成：如果它做错了，怎么查。

只看最终回答没有意义。一个答案可能看起来正确，过程里却用了过期文档、绕过了审批、把敏感字段发给了不该调用的工具。一个答案也可能是错的，但错误重点是检索拿错了版本、工具返回超时、下游 API 给了半截数据，或者前一个 Agent handoff 时丢了上下文。

这就是 trace 变重要的原因。它是在生产系统里的证据链。企业需要知道的是：这次任务从哪里开始，模型看到了什么，调用了哪些工具，工具参数是什么，数据从哪里来，哪一步触发了 guardrail，谁批准了高风险动作，最后结果受到了哪些中间事实影响。

没有这条链，Agent 越能干，越难放心放权。

这不是单纯的工程洁癖。EU AI Act 的 record-keeping 条款要求高风险 AI 系统具备自动记录能力，用于追踪系统运行、识别风险、支持上市后监测。NIST SP 800-53 的审计控制也长期要求 audit record 能说明事件类型、时间、来源、结果和相关主体。Agent 如果要进入高风险或强监管流程，就必须把这些传统审计要求翻译成自己的执行语言。

Agent trace 和普通日志不是一回事

传统服务日志通常围绕请求、接口、错误码和延迟展开。Agent 也需要这些，但远远不够。

一个 Agent run 里，模型调用只是其中一段。它可能先检索知识库，再让模型生成计划，接着调用内部 API，遇到权限问题后改走另一个工具，再把任务交给另一个 Agent，最后生成一段报告。每一步都有输入、输出、状态、成本、延迟和失败可能。

OpenAI Agents SDK 的 tracing 文档把这一点讲得很直接：trace 会记录 Agent 运行期间的事件，包括 LLM 生成、工具调用、handoff、guardrail 和自定义事件。它还专门提供敏感数据是否纳入 trace 的配置。平台方已经把 trace 当成 Agent runtime 的一部分，而不是事后补的 debug 开关。

Microsoft Foundry 的 tracing 文档也把方向讲得很清楚：它支持服务端 trace 和 OpenTelemetry 集成，Conversation 视图可以查看 ordered actions、run steps、tool calls 以及用户和 Agent 的输入输出，同时提醒 trace 会捕获敏感信息。云厂商在把它放进 Agent 会话、工具、隐私和保留策略的交叉点。

这些产品和文档指向同一个变化：Agent 可观测性把一条任务轨迹拆成可检索、可聚合、可复盘的结构化事件。

OpenTelemetry 会把私有 trace 格式拉向公共语言

Agent trace 不能长期只停留在各家平台自己的面板里。企业已经有 APM、日志系统、SIEM、数据治理和审计流程。Agent 如果要进生产，它的轨迹迟早要进入这些已有系统。

OpenTelemetry 的 GenAI agent semantic conventions 值得关注。它已经把 agent、workflow 和 tool execution 放进 span 语义约定里。它的意义在于行业开始用同一种遥测语言描述 Agent 行为。

这会带来两个后果。

第一，Agent trace 会从「产品功能」变成「基础设施接口」。团队可以把 Agent span 发到现有 collector，再进入 Grafana、Tempo、Datadog、Elastic、Honeycomb 或内部审计系统。不同应用、不同框架、不同供应商之间，至少有机会共享同一套事件骨架。

第二，可观测性会更容易和治理连接。传统 trace 关心延迟和错误。Agent trace 还要关心工具权限、数据来源、审批路径、成本归因和策略命中。如果这些字段能进入标准 span，企业就能用已有的监控和审计方式问更具体的问题：某个工具过去 24 小时被哪些 Agent 调过，哪些调用带了客户数据，哪些调用绕过了人工确认，哪些异常集中发生在同一个知识库版本。

这才是 trace 的价值。它把「我感觉 Agent 不稳定」变成可查询事实。

OWASP Agent Observability Standard 进一步把 trace 定义为从触发到结果的完整追踪，并强调 reasoning chain、tool execution、knowledge retrieval、多 Agent 协作和 decision context。即使具体实现会因为隐私和商业策略做裁剪，这个标准化方向本身已经说明：Agent trace 重点是 Agent 安全、可靠性和审计的共同接口。

审批本身也必须进入 trace

很多 Agent 系统会说自己支持 human-in-the-loop，但如果审批没有进入 trace，它就只是交互体验，不是责任链。

Microsoft Agent Framework 的 tool approval 文档提供了一个很实际的例子：工具函数可以声明需要人工审批，Agent 在执行前返回 approval request，里面包含函数名和参数，调用方再传入 approve 或 reject 结果。审批不应该只存在于 UI 弹窗里。它应该成为执行链上的一条记录：谁看到请求，看到什么参数，批准还是拒绝，何时发生，批准后实际执行的工具参数有没有变化。

这件事在企业里很关键。Agent 的高风险动作往往是「模型建议调用工具，系统识别为高风险，人批准，工具网关执行，外部系统状态改变」。只记录最后一个 API call，会丢掉责任链前半段；只记录审批弹窗，又无法证明实际执行的是同一个动作。

比如一个采购 Agent 生成了供应商建议并发起下单，审计要问：

  • 它引用了哪几份价格表和合同版本。
  • 哪个工具返回了候选供应商。
  • 是否读取了受限客户数据。
  • 哪一步由模型判断，哪一步由规则判断。
  • 哪个经理批准了最终下单。
  • 审批时看到的参数，和实际提交给供应商系统的参数是否一致。
  • 事故发生后，能不能重放同样输入和同样工具返回。

如果系统回答不了这些问题，Agent 就只能停在辅助层。生产责任不会交给一段无法复盘的自动化。

工具网关和云审计日志要并进来

Agent trace 不能只在 Agent 框架里完整流程。动作往往发生在工具网关、云服务、IAM、数据库和业务 API 里。

AWS Bedrock AgentCore Gateway 集成 CloudTrail 这一点很有代表性。CloudTrail 记录 Gateway API 调用，可以追溯请求内容、调用者、时间和更多细节。企业不会只相信 Agent 自己说「我调用了什么」。它还需要从 API 网关、身份系统和云审计日志里确认：谁真正调用了哪个服务，用了哪个身份，外部系统是否接受并执行。

这会把 Agent 审计分成两层。

第一层是 Agent 内部 trace：模型调用、工具选择、检索、审批、guardrail、handoff、失败重试。它解释「为什么会发生」。

第二层是基础设施审计：IAM、API gateway、CloudTrail、数据库日志、业务系统审计表。它证明「实际发生了什么」。

只有两层能关联，企业才有完整证据链。否则，Agent 平台里看起来一切正常，业务系统里却可能出现另一条事实；或者云审计里只看到 API 调用，却不知道是哪条 Agent 推理链触发了它。

trace 本身也会制造风险

trace 不是越全越好。Agent trace 天然容易包含敏感内容：用户原始输入、内部文档片段、工具参数、API 返回、数据库字段、凭证片段、错误栈、审批意见，甚至模型中间推理材料。

OpenAI Agents SDK 对是否包含敏感数据提供配置，Microsoft Foundry 也提醒 trace 会捕获敏感信息，本质上都在说明：trace 是安全边界的一部分。企业如果只想着「先全量记录，出事再说」，很快会把 observability 变成新的数据泄露面。

所以生产级 Agent trace 至少要有四条约束。

第一，敏感字段要能脱敏或不采集。工具参数、检索内容、客户标识和凭证类字段不能默认原样入库。

第二，trace 权限要独立管理。能看业务系统的人，不一定应该看所有 Agent trace；能调试模型的人，也不一定应该看到客户原文。

第三，保留期限要按风险分层。调试用的详细 trace 可以短保留，审计用的摘要和签名可以长保留。不是所有 token 级材料都应该永久保存。

第四，抽样不能破坏审计链。普通请求可以采样，高风险动作、生产写入、外部发送和审批路径必须完整留痕。

没有这些约束，trace 越强，风险越大。

好的 Agent 平台要能回答七个问题

判断一个 Agent 平台的可观测性，不要只看面板好不好看。更直接的办法，是问它能不能稳定回答七个问题。

  • 这次任务的完整执行树是什么。
  • 每次模型调用看到了哪些上下文来源。
  • 每次工具调用的参数、返回、延迟和错误是什么。
  • 哪些外部数据或记忆影响了最后输出。
  • 哪些 guardrail、权限规则或人工审批被触发。
  • 哪些字段因为敏感策略被脱敏或拒绝记录。
  • 同类失败能不能聚合成可修复的模式，而不是只给单次回放。

前六个问题解决复盘，第七个问题解决改进。只有 trace，没有聚合，团队会陷入逐条看录像的低效调试。只有指标，没有 trace，又很难知道哪一步真的出了错。Agent 的生产可观测性需要两者结合：trace 负责证据，指标负责模式。

这也会改变工程团队的工作方式。过去排查服务问题，常见路径是看错误率、看日志、看调用链。未来排查 Agent 问题，还要看检索命中、工具选择、上下文膨胀、审批等待、模型重试、成本异常和策略误杀。它更像应用性能、数据治理和安全审计的混合体。

可审计执行会成为企业 Agent 的底座

Agent 如果只是写草稿、做摘要、整理公开资料，trace 可以偏调试。Agent 一旦开始写数据库、发邮件、下订单、改代码、提交 PR、处理客户资料，trace 就会变成责任系统。

这也是为什么可观测性不该被放在最后补。很多团队会先把 Agent 做出来，等出问题再加日志。这个顺序在生产里很危险。因为你能不能放权，取决于出错后能不能收回、解释、追责和修复。没有证据链，就没有可靠授权。

未来的 Agent 平台会把 trace、provenance、权限、审批和评测绑在一起。一次任务不只是生成一个结果，还会生成一份执行档案：谁发起，谁代理，访问了什么，依据是什么，在哪里被拦截，谁批准，成本多少，失败是否可重放。

这听起来像合规要求，也是产品能力。越复杂的任务，越需要让用户看见过程；越重要的场景，越需要让组织相信过程。Agent 的下一步重点是更能留下可信的工作记录。