Agent Gateway接入Cloud Trace预览：智能体请求链路开始贯通
2026年9月30日，Google Cloud宣布Agent Gateway与Cloud Trace的集成进入预览。新能力面向经过网关的智能体工作负载，将请求在智能体、Google Cloud服务、其他智能体、工具及MCP服务器之间的流转关联起来。对于一次回答要调用多个外部能力的应用，调查重点可以从“总共花了多久”进一步下沉到“时间花在哪一跳”。
配图为AI生成的概念插图，表现请求经过网关并分流到工具的追踪过程，不是真实产品界面。
同一个请求，可以带着关联信息穿过服务边界
官方文档说明，这项集成基于OpenTelemetry与W3C TraceContext标准，并通过trace_id关联链路片段、网关日志和指标。支持父级采样决策，可以在上游已经发起追踪时，继续保留这次请求的关联关系。当前仍为Pre-GA功能，支持与服务条件应按预览阶段理解。
这对排查智能体“看起来一直在思考”很有用。用户感知到的等待，可能来自模型、授权检查、工具响应或连续重试。把所有耗时归给模型会误导优化方向；先建立各环节的时间证据，才能判断该调整提示、工具服务还是网络与网关配置。
但链路关联本身不解释业务正确性。一次调用速度很快，也可能取错对象；所有span都成功，也不能证明最终回答采用了正确资料。追踪更适合回答运行路径与耗时问题，业务评测仍需要自己的输入、预期结果和人工复核。
写入权限与查看权限必须分别准备
官方把配置策略、查看追踪和写入span区分为不同权限。除了相应管理角色与Cloud Trace查看角色，还需要给相关服务代理赋予写入追踪的权限。如果发起请求的智能体会导出父级span，其工作负载服务账号也必须能写入，否则可能只看到网关子片段，缺少请求的上游起点。
这说明“控制台出现一条记录”只能验证部分接入。更有信息量的试点，是选择一个已知会经过网关并调用工具的测试请求，对照预期路径检查父子关系、时间线和对应日志。若每一段都独立成为根追踪，应检查传播机制和权限，而不是把多条孤立记录当成完整链路。
权限部署也值得采用最小范围。配置人员、排障人员和运行身份各自需要什么，应分别列出。测试结束后保留必要的运行与查看能力，避免为了让演示成功而长期授予不相关的管理权限。
采样决定看见多少，也影响摄入规模
启用方式是创建可观测性策略并用gcloud导入，策略可以关联多个网关。文档中的采样率取值从0到1，并对高流量环境建议以1%或0.1%等较低比例平衡可见性与摄入成本。对上游已标为采样的请求，还可以单独配置父级采样比例。
这两个比例不应随意混为一个数字。日常基础采样回答的是常规流量覆盖问题，父级决策则关系到被上游选中的链路是否继续完整。低流量试验暂时看不到记录，不一定代表配置失败；官方建议必要时短暂提高到全量验证，再恢复生产比例。
从治理角度看，还应检查哪些请求属性进入span或日志，谁能查看，以及保存期限是否符合团队要求。排查需要的通常是足以定位问题的标识和状态，不必把完整业务内容都塞进追踪字段。新增观测入口值得与现有数据访问规则一起审核。
把追踪接入验收写成一条具体用户路径
本文建议，首个验收场景同时覆盖正常工具调用、权限拒绝和工具故障，分别保留请求标识、链路图、网关日志与用户得到的结果。正常请求用于检查关联，拒绝与失败场景用于验证错误发生的位置是否明确。
随后再拿一段真实延迟峰值对比span分解，确认观察结果能指导行动。如果只能看到漂亮的连线，却无法确定哪个环节需要改进，接入还没有充分发挥价值。此次预览补充了智能体基础设施的运行证据，团队接下来要完成的，是把这些证据接进自己的故障响应流程。
