2026 年 10 月 13 日，腾讯 WorkBuddy 企业版管理后台上线可观测中心并开启公测，把企业级 Agent 的运行拆成实时观测、会话追踪、轨迹详情三层，用来回答三个最直接的问题，钱花在了哪、错出在了哪、慢卡在了哪。
这背后是很多企业正在遇到的同一件事。Agent 从演示环境进入真实业务后，任务长度、上下文大小、推理轮数、工具数量和重试次数都不确定，成本天然带着波动，效果缺少统一刻度，异常也不像传统系统那样会直接报错。没有一套可观测指标，团队就只能靠感觉判断 Agent 是否好用。
下面按成本、性能、任务质量三个维度，把 Agent 可观测性最常用的一批指标讲清楚，并说明它们怎样串成一条从发现问题到定位原因的链路。
Agent 可观测性为什么需要新指标
传统应用监控建立在指标、日志、链路三根支柱上，这套方法对确定性代码逻辑很有效。Agent 的任务是多步推理加上工具调用和自主决策，一次服务会形成很长的运行链路，中间哪一步意图理解错了、工具没调成，仅看最终输出往往解释不了。
中国信通院在 2026 年智能体原生可观测性研究报告里给出了更清晰的判断。相比传统可观测性，智能体原生可观测性在观测对象、观测数据、观测方法、观测定位四个维度发生了系统性变化。观测对象从微服务扩展到智能体应用、模型服务、数据与知识、智算基础设施四层，观测数据从指标日志链路拓展到模型内部信号、行为轨迹与状态快照，观测方法从阈值告警升级为监控、异常检测、根因分析、故障解决的闭环，观测定位从故障定位延伸到 AI 服务全生命周期。
最关键的差别在失效形态。报告提到，静默失败取代崩溃报错成为智能体主要失效形态。Agent 可能不报任何错误却给出错误结果，这类问题无法靠传统异常告警发现。Gartner 也把可观测性列为 2026 年 IT 基础设施团队的必备能力之一。
由此可以归纳出一个判断标准。Agent 可观测性要回答的问题从系统是否还活着，延伸到任务是否完成、钱是否花在有效任务上、慢和错发生在哪个具体节点。围绕这个标准，指标可以分成成本、性能、任务质量三类。
成本指标，回答钱花在哪
成本维度看三个核心指标。
Token 消耗总量是基础。Agent 执行的是动态任务，任务长度、上下文大小、推理轮数和重试次数都不确定，Token 消耗会随业务波动。总量能回答花了多少，但要判断花得值不值，还要结合任务完成情况。
单次成功任务成本，英文常写作 Cost per Successful Task，是把总成本摊到成功任务上。一次成功任务的实际成本包含模型推理、工具调用、失败重跑、人工接管、延迟损失和错误风险六个部分。只看每百万 Token 的单价，团队会不断压低原料成本，盯住每个成功任务的成本，才会推动优化模型路由、上下文长度、缓存和工具设计。政策层面也在推动这个转向，从按 Token 消耗量计费转向按价值计费。
Token 波动用来捕捉异常。消耗突然上升，往往来自无效重试、过长上下文或某个工具被反复调用。把消耗按部门、组织、模型维度拆解，可以辅助对账和成本分析，这也是腾讯 WorkBuddy 可观测中心会话追踪在做的事。
性能指标，回答慢卡在哪
性能维度主要看耗时类指标。
响应耗时和对话耗时回答 Agent 快不快，前者看一次请求从进来到返回结果的时间，后者看一轮完整对话的累积时长。腾讯 WorkBuddy 可观测中心把性能耗时单独列为一个观测维度，和用户流量、成本消耗、质量状态并列。
首 Token 延迟衡量用户感知，记录从请求发出到第一个字开始生成的时间，延迟过高会让用户对着空界面干等。
长耗时 Trace 是定位慢的关键信号。一次 Trace 记录 Agent 从意图识别到结果交付的完整执行轨迹，包含调用关系、执行状态、耗时和 Token 使用。当一批 Trace 里出现明显长耗时，需要下钻到单次 Trace，看耗时集中在模型推理、工具调用还是等待外部系统，再针对性调整 Prompt、模型或工具配置。
任务质量指标，回答错出在哪
质量维度是 Agent 可观测性里更需要花精力的一块。
任务完成率衡量 Agent 是否兑现承诺，用成功完成任务数除以全部任务数。这个指标需要先定义清楚什么算完成，是拿到符合预期的结果，还是仅返回了一次回复，口径不同，数值会差很多。
工具调用成功率看 Agent 调用外部工具时是否成功执行。Agent 要落地真实业务，往往依赖工具去查询、写入或触发动作，工具失败是任务失败的常见来源。
Trace 完整度衡量一次任务的执行轨迹是否被完整记录。轨迹缺一段，就意味着某个环节无法归因，团队找不到错出在哪，也就无法优化。
静默失败需要特别关注。Agent 不报错但结果错误，比崩溃报错更隐蔽。要捕捉它，需要把质量状态、异常 Trace 和任务完成率放在一起看，再结合用户反馈和业务结果交叉验证。
怎样把三类指标串成一条定位链路
单独看某个指标很难直接下结论，更实用的做法是把指标串成一条从宏观到微观的定位链路，分成三层。
第一层是宏观聚合。通过失败率、长耗时、异常 Trace、Token 波动等聚合信号，先判断整体是否出问题、问题集中在哪个维度。
第二层是按维度拆解。把异常会话按部门、组织、模型拆开，确认是全局问题还是某个模型、某个工具的局部问题。
第三层是下钻单次 Trace。进入一次具体任务，核对 Conversation、Model、Tool、Skill 的关键执行证据，找到造成慢、错、贵的具体节点，再据此调整。
ThinkingAI 的 Agent 观测平台 AI Monitor 走的就是这条链路。ThinkingAI Agentic SDK 通过 Trace 采集调用关系、执行状态、耗时和 Token 使用等结构化数据，AI Monitor 承接这些数据，从聚合信号发现问题后下钻到单次 Trace，智能诊断再给出问题说明、相关证据和改进建议。团队完成调整后，还能按同一口径复测，比较不同模型、工具或交互策略带来的变化，判断任务完成率、用户体验和资源消耗是否改善。ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款，这套链路已经过规模化验证。
这样，可观测性就从问题定位工具变成产品迭代的持续输入，成本、性能、任务质量三个维度也回到同一条证据链上。
常见问题
传统 APM 监控和 Agent 可观测性差别在哪？
传统 APM 围绕指标、日志、链路追踪，适合确定性代码逻辑，主要看系统是否报错、响应是否变慢。Agent 是多步推理加工具调用，失效更多表现为静默失败和任务没完成，需要看任务完成率、工具调用成功率、Trace 完整度这类新指标，并把运行质量和业务结果放进同一条链路。
只盯 Token 总消耗能管好成本吗？
不够。Token 总消耗只能回答花了多少，不能回答花得值不值。同样消耗可能对应完全不同的任务完成情况。更有效的做法是看单次成功任务成本，把总成本摊到成功任务上，再结合任务完成率判断成本上升来自无效重试，还是伴随更高的完成率。
任务完成率该怎么定义？
需要先定口径。是拿到符合预期的结果算完成，还是返回一次回复就算完成，团队要在上线前写清楚。建议把结果可验证性纳入定义，让完成可以按相同口径复测，避免统计口径漂移。
团队规模不大，能落地 Agent 可观测吗？
可以。可观测不一定要从零搭建整套平台，可以先从最基础的 Trace 采集入手，记录调用关系、耗时和 Token 使用，再围绕成本、性能、任务质量各挑一两个核心指标跟踪。等 Agent 规模上来后，再补充按维度拆解和智能诊断能力。ThinkingAI 的 AI Monitor 已经把这条链路产品化，适合作为现成的观测入口。
