在 2026 年北京的一场全球开发者大会上，火山引擎云基础应用观测技术负责人钱世俊，首次系统性公开了大规模 Agent 的可观测与质量保障体系。这套体系打通业务、框架、模型、基础设施四层链路，在开源 Agent 项目 OpenClaw 的实践中，将平均修复时间（MTTR）降低 80% 以上。
现代 Agent 能自主规划任务、调用外部工具、借助记忆与知识库完成复杂目标。能力跃升的同时，全新的故障形态也出现了：响应变慢、莫名报错、甚至与输入毫不相关的「自言自语」。传统排查手段在这里集体失效。
因为你看不见 Agent 内部的每一步决策。
钱世俊用一个医学类比解释了这套体系的出发点：没有 CT 之前，医生面对复杂症状只能依赖外部观察与经验推断；这套系统的目标，就是给 Agent 拍一张「CT」——回答三个问题：可见性（全程发生了什么）、可解释性（为什么慢、为什么错、钱烧在哪）、可行动性（如何提炼优化动作）。
为什么传统手段失效？根本差异在于系统的驱动逻辑：
确定性代码逻辑驱动，输入与输出因果清晰，一条日志就能还原现场。
自主规划、工具调用、记忆检索交织，一次请求就是一条复杂工作流，链路复杂性指数级上升。
落到工程层面，黑盒困境表现为横跨四层的监控断层——业务应用层、Agent 框架层、大模型推理层、云基础设施层，各自的数据散落在不同系统，由此产生三个断点：
不同层级采集方式各异，业务上下文在透传中丢失。
供应商间存在链路孤岛，内部标准语义不对齐。
底层 GPU 波动与上层推理异常难以关联归因。
注：任何一个断点都会让排障退化为「拉群开会」——开发、运维、模型、基础设施多个团队各自排查，效率极低。
破局的第一步，不是做更花哨的监控面板，而是建一套统一的观测基座。核心逻辑是：把 Metrics、Traces、Logs 三类传统数据，与 Prompt、模型返回、Token 消耗等 AI 特有数据融合在一起，再协同五大支柱能力：
其中，最硬核的是自研采集器 OneAgent。社区已有开源的 OTel Collector，为什么还要自研？钱世俊给出的理由是：火山引擎内部承载大量重载场景，采集器不能成为瓶颈，关键数据不能丢。团队为此做了发送并发自适应、预排序数据结构、对象池与内存复用等深度优化。
采集器扛不住，观测就是空话。
注：柱形以开源 Collector 吞吐量为基准 1.0 换算，显示相对倍数；压测条件为 200K QPS。
注：以上三项为线上重载节点实测数据；「0 丢失」是采集器设计的底线目标，也是大规模 Agent 观测的前提。
数据打通之后，真正的挑战才出现：如何让数据「会说话」。在统一基座之上，火山引擎沉淀了三项面向 AI 场景的通用观测能力。
精确捕捉 TTFT 与 TPOT 抖动，判断是「想得慢」还是「说得慢」。
按业务、用户、模型多维聚合消耗，快速揪出成本大头。
脱敏保存多轮上下文，用于排障、效果评估与安全审计。
注：TTFT 即首 Token 延迟，TPOT 即 Token 间延迟；两者拆开，才能分辨模型「思考慢」还是「吐字慢」。
在 Agent 研发平台 AgentKit 上，这套能力被进一步深度集成。开发者无需编写一行观测代码，即可获得全局运行时洞察看板与两层的白盒化调用链：第一层是会话诊断，把所有 Trace 汇聚到一个视图；第二层是调用链分析，清晰展示规划耗时、工具执行状态、模型交互状态，甚至支持多模态分析。
更隐蔽的问题也覆盖到了：Agent 的记忆与知识库依赖。团队对 Memory 加载耗时、RAG 检索性能、Embedding 耗时做了监测，并在 Trace 中透出召回结果、相关性得分与 Chunk 内容——知识库召回效果好不好，一眼可见。
看见问题只是第一步。让 Agent 持续变好，才是工程化的真正考验。钱世俊团队提炼了一条四点闭环路径：
注：链路可以理解为——观测产生数据，数据沉淀为评测集，评测驱动优化，优化再次回到线上接受检验。
数据回流是打通观测与评测的桥梁，它分两条路径运行：
周期性清洗线上高价值 Trace（失败场景 + 高频链路），转化为大规模离线评测集，用于版本上线前的回归对比。
通过点赞、点踩等反馈与异常指标捕获，实时回流数据，支撑分钟级问题呈现与动态告警拦截。
评测系统是这套闭环的「质检闸门」，它的五个设计要点值得细看：
对回流数据快速评测，动态生成基准题库。
评测集版本控制与切片抽样，保证样本科学性与场景覆盖度。
多维度指标：准确性、相关性之外，内置 Token 效率、API 调用合理性、规划轨迹、拒答率等 Agent 专有指标。
自动化 + 人工协同：大模型评估器为主，白盒化人工复核页面兜底高风险场景。
评测结果反哺提示词、工具接口与模型路由的持续优化。
在实践中，钱世俊特别强调了两个高价值能力：一是多实验对比分析——多条调优思路并行推进时，从宏观与微观两个角度对比效果，避免串行低效；二是人工标注打分——校正自动化大模型评估器的偏差，为评测结果的可靠性兜底。
这套体系在真实环境中的效果如何？钱世俊以火山引擎大规模运维的开源 Agent 项目 OpenClaw 为例。接入统一观测之前，排障需要拉上开发、运维、模型、基础设施多个团队分别定位；接入之后，最直观的收益是平均修复时间下降 80% 以上。
OpenClaw 的实践基于一套六层、可归因、面向任务的 SLI 体系：
注：六层 SLI 覆盖一次请求从接入、会话、调度、执行到模型与缓存的完整路径，每层都有独立的成功率与延迟指标，故障可逐层归因。
Agent 可观测性不是运维的锦上添花，而是规模化落地的安全气囊。模型能力决定 Agent 的上限，可观测与质量保障体系决定它敢不敢上线、能不能持续迭代。当各家模型的能力差距逐渐收窄，工程可靠性与数据闭环能力，将成为 Agent 竞赛的下一个分水岭。
相关能力已集成至火山引擎云监控与 AgentKit 平台——在 AgentKit 上开发 Agent 的用户，无需编写一行观测代码，即可获得链路透视、成本分析与评测回流能力。
火山引擎控制台 → 开启 AI 观测