给 Agent 做"CT"：大规模 Agent 的可观测与质量保障体系

作者：钱世俊，火山引擎应用观测技术负责人。本文整理自 QCon 全球软件开发大会 2026 北京站演讲实录。

1. 背景：Agent 的"黑盒"困境

Agent 从概念验证进入大规模工程落地，但其自主任务规划、工具调用、记忆检索的内部机制，让传统应用观测手段力不从心。线上出现响应变慢、报错、自言自语等异常时，传统日志排查几乎无法还原 Agent 内部决策链路。

类比医学诊断：没有 CT 之前，医生只能靠外部观察和经验推断。团队要做的，就是为 Agent 构建一套"CT 系统"，回答三个核心问题：

• 可见性：从用户输入到最终输出，Agent 究竟发生了什么
• 可解释性：变慢、报错、成本飙升的具体原因是什么
• 可行动性：如何从观测数据提炼出可执行的优化方案

观测困难归结为三个维度：Agent 与传统微服务的本质差异（非确定性 vs 确定性代码）、内部决策过程难以分析、以及 Agent 特有的成本失控风险（逻辑偏差可能触发指数级 Token 消耗）。

工程层面表现为多层监控断层。Agent 系统自上而下分为四层——业务应用层、Agent 框架层、大模型推理服务层、云基础设施层——各层观测数据分散在不同系统中：

三个断层：链路断（采集方式各异、上下文透传丢失）、语义断（供应商间链路孤岛、语义不对齐）、因果断（硬件指标与推理逻辑脱节）。

2. 破局：构建统一观测基座

统一观测基座融合传统 Metrics/Traces/Logs 与 AI 特有数据（Prompt、Response、Token 消耗），协同五大支柱能力：

支柱一：全栈观测门户。将火山引擎多个各自为战的观测产品（云监控、Prometheus、应用观测、日志分析等）汇聚到统一门户，消除研发在多个控制台间反复跳转的割裂体验。

支柱二：统一集成中心。基于 OpenTelemetry 标准生态实现跨技术栈、跨云厂商、跨框架的统一数据采集。自研采集器 OneAgent 在 200K QPS 下数据吞吐量比 OTel Collector 高出一倍，整体负载降低 50% 以上。关键优化包括：

• 发送并发度自适应调整（基于 RTT 动态调节）
• 预排序增强（从 Protobuf map 切换到 sortable slice，核心方法性能提升一个数量级）
• 内存管理优化（预分配大块内存、栈内存优先、对象池复用）

支柱三：统一数据加工。数据脱敏（Prompt 常含敏感信息）、黑白名单过滤、上下文标签富化、错误码到业务语义的动态映射、日志/链路降维为持续 Metrics、热冷分流存储。

支柱四：统一看板。跨类型数据联动（Metrics 异常 → 一键唤起 Logs/Tracing）、Grafana 模型兼容导入导出、Agent 领域预置看板一键克隆。

支柱五：统一告警。智能降噪收敛告警风暴、统一配置管理（一处配置全产品生效）、开箱即用规则（TTFT/TPOT 突增、Token 成本暴涨、工具调用大规模失败）。

3. 深水区：AI 与 AgentKit 深度观测

在统一基座之上，团队建设了 AI 通用观测能力：

• AI 语义规范：在 OpenTelemetry 基础上拓展面向大模型的专属语义字段
• 跨框架统一：无论用什么框架或模型供应商，获得一致的观测体验
• 全栈穿透：上层 Prompt/Response 内容分析与底层 GPU 利用率、网络吞吐完整关联

三项核心能力：精细时延拆解（TTFT/TPOT 捕捉）、多维度 Token 消耗监控、多轮会话分析管理（脱敏保存，支持排障/评估/审计）。

以火山引擎 Agent 研发平台 AgentKit 为例，观测团队在 Agent 完整生命周期中深度埋点，用户零行观测代码即可获得专业能力。白盒化调用链分析分为两层：

• 第一层：会话诊断——多轮会话 Trace 汇聚视图，展示整体耗时和输入输出概要
• 第二层：调用链分析——规划耗时、工具执行状态、大模型交互状态完整还原，支持边界定界（模型生成慢 vs API 响应慢 vs 数据处理瓶颈）

对 Memory 和 RAG 也做了深度监控：Memory 加载耗时、检索索引性能、Embedding 耗时，以及 Trace 中透出 RAG 召回结果、相关性得分、Chunk 内容。

4. 工程化闭环：从可观测到可迭代

四点闭环路径：观测数据 → 高价值 Trace 回流 → 评测集 → 系统化评估 → 持续迭代。

数据回流分两类：离线回流（周期性清洗提取高价值 Trace 转化为评测集）和在线回流（用户点赞/点踩实时反馈、异常指标分钟级采集）。

评测系统五个要点：

• 动态生成评测基准题库
• 评测集版本控制与切片抽样
• 多维指标体系（准确性、Token 效率、API 调用合理性、规划轨迹分析、拒答率）
• 自动化 + 人工协同（白盒化人工复核页面校正大模型评估器偏差）
• 多实验对比分析（并行调优思路的宏观/微观对比）

5. 落地实践：OpenClaw 观测

以 OpenClaw 大规模运维为例，接入统一观测后平均修复时间降低 80% 以上。

构建了六层面向任务的 SLI 体系：Channel 接入层 → Message/Session 层 → 调度层 → 执行层 → 大模型工具层 → 缓存层。通过 Hook 机制在关键时间点采集信号，自研插件实现可归因、可迭代的观测数据采集。

三个排障案例：

案例一：API 超时导致响应缓慢。火焰图显示 get_weather_api Span 占请求耗时 90% 且返回网络超时。根因：天气 API 供应商网络抖动。修复：增加超时重试 + 降级处理。

案例二：Token 成本爆炸。generate_summary 工具被调用数十次，Prompt 对记忆内容反复摘要形成无限循环，上下文雪球式放大。根因：Prompt 缺少终止指令。修复：重做 Prompt 增加终止指令 + Agent 层最大迭代限制 + Token 预算早停机制 + 加入回归测试集。

案例三：长对话模型幻觉。多轮对话后期 Agent 自言自语。Trace 分析发现两个问题：RAG 检索相似度极低（口语化表达与知识库标准术语不匹配）、Memory 加载 Span 耗时长且上下文被截断丢失早期关键信息。修复：引入查询重写 + 调整分块策略 + 长对话摘要机制 + 轨迹评测保障召回率阈值。

6. 总结与展望

核心成果：统一观测基座降低多产品维护成本、Agent 生命周期深度观测（耗时/Token/链路）、白盒化 Trace 还原复杂编排、观测→评测→优化完整数据链路。

未来方向——从"Agent 体检"迈向"自动驾驶"：

• 更智能的排障（自动根因定位与诊断推送）
• 从被动可见性到主动治愈（API 动态降级、Token 暴涨自动拦截、智能路由切换）
• 开放生态（标准化 API 对外提供 Agent 观测能力）

My take：这篇文章的核心洞察是——Agent 可观测的本质不是"加日志"，而是打通四层架构的因果链。传统前端监控的 Error Boundary + Performance API 思路在 Agent 时代完全失效，因为问题不在"哪行代码崩了"，而在"Agent 为什么做了这个决策"。OneAgent 的性能优化细节（sortable slice 替换 map、栈内存优先、对象池复用）对有构建工具/SDK 经验的工程师特别有参考价值——这是真正的性能工程，不是 PPT 数字。三个排障案例尤其精彩：Token 爆炸的无限循环和长对话幻觉的 RAG 失效，都是 Agent 生产环境中的高频陷阱，值得作为 checklist 纳入 Agent 上线评审。