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

随着大语言模型能力边界的持续拓展，AI Agent 已从概念验证阶段迈入大规模工程落地。然而，Agent 内部复杂的任务规划、工具调用与记忆检索机制，使得传统的应用观测手段在面临这类非确定性系统时显得力不从心。本文整理自火山引擎应用观测技术负责人钱世俊在 QCon 全球软件开发大会 2026 北京站的分享《给 Agent 做“CT”：大规模 Agent 的可观测与质量保障体系》。

钱世俊系统性地阐述了团队在 Agent 可观测性领域的工程实践，分享了如何从零构建一套覆盖基础设施到业务语义的统一观测底座，并以此为基础实现 Agent 内部链路的白盒化透视、根因可解释性以及持续优化的工程闭环。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

1

 背景与挑战：Agent 的“黑盒”困境

从去年开始，Agent 的能力逐渐进入我们的视野并持续增强。与早期大模型简单的一问一答模式不同，现代 Agent 能够自主进行任务规划，调用种类繁多的外部第三方工具，并利用记忆与知识库来沉淀上下文，从而完成更为复杂的业务目标。然而，这种能力的跃升也带来了全新的观测挑战。当系统运行正常时，智能体的表现令人满意，但它不可避免地会在线上遭遇各类异常——响应变慢、反馈报错，或者出现与输入毫不相关的自言自语。每当遇到这类问题，传统的排查手段往往难以定位具体成因，因为我们无法洞悉 Agent 内部每一步的决策逻辑。

我们可以用一个形象的类比来说明：这就像医学领域的诊断需求。在没有 CT 等深度成像技术之前，医生面对复杂症状只能依赖外部观察与经验推断。而我们要做的，就是为 Agent 构建一套类似的“CT 系统”，让研发者能够看清其内部一步步的判断与决策轨迹，从而回答三个核心问题：第一是可见性，即从用户输入到最终输出的全过程中，Agent 究竟发生了什么；第二是可解释性，任何变慢、报错或成本飙升的具体原因是什么；第三是可行动性，如何从观测数据中提炼出优化 Agent、提升其整体性能的可执行方案，形成可闭环的改进路径。

我们经过系统性梳理，将 Agent 时代观测困难的原因归结为三个维度。首先，Agent 与传统微服务应用存在本质差异。传统应用由确定性代码逻辑驱动，输入与输出之间的因果关系清晰。而 Agent 会自行规划任务、调用外部工具、沉淀记忆与知识库，任何一次请求在其内部都涉及大量复杂的工作流，并非简单的单次大模型调用，整体复杂性呈指数级增长。其次，在运行过程中，我们很难分析其内部决策过程。若沿用传统的日志查看方式，几乎无法还原它的思考机制、规划逻辑以及执行链路，这直接导致问题出现后排障极为困难。最后，Agent 时代还引入了一个特殊而棘手的问题——成本管控。在传统微服务场景里，研发团队通过性能压测与线上流量监控，可以相对精准地规划服务资源需求，成本是可控的。但在 Agent 场景中，由于内部编排响应的不确定性，一旦出现逻辑偏差，可能在极短时间内触发巨量的大模型调用，导致 Token 消耗呈指数级激增，使成本陷入危险境地。

这些黑盒困境落到工程层面，就表现为一个横跨多层的监控断层问题。如果我们把整个 Agent 系统自上而下分为四个层次，最上层是业务应用层，承载各类 Agent 实体，如财务 Agent、投资分析 Agent 等；其下是 Agent 框架层，市面上涌现的各类 Agent 框架在此处负责思考编排与工具调用调度；再往下是大模型推理服务层，提供实际的模型推理能力；最底层则是云基础设施层，提供 GPU、网络、容器等一系列算力资源。

这四个层次的观测数据和观测对象分散在不同的系统中，且关注点各不相同。业务系统层关心 DAU、用户反馈、端到端延迟与成功率等宏观指标；Agent 框架层关注整体规划延迟、端到端工具调用的成功率，以及 Memory 或知识库的召回成功率；大模型服务层聚焦模型推理性能，如 TTFT（首 Token 延迟）、TPOT（Token 间延迟）、Token 使用量等；云基础设施层则关注 GPU 使用率、网络吞吐量等硬件指标。正是这种分层架构导致观测出现三个断层。第一是链路断，不同层次的观测采集方式各异，经常出现链路断裂，且业务上下文在不同层级透传时容易丢失。第二是语义断，不同供应商之间存在链路孤岛，其内部链路标准的语义不对齐，为后续整体排障制造了巨大困难。第三是因果断，最底层硬件核心指标与上层推理逻辑之间存在脱节——举个例子，如何将一次大模型推理异常与底层 GPU 的瞬时波动关联起来，就是一个极具难点的工程问题。

2

破局之道：构建统一观测基座

要应对上述分层断层问题，我们进行观测建设的第一步，就是构建一个统一的观测基座。这个基座的核心目标，首先是融合多维度的观测数据。这不仅包括传统的 Metrics、Traces、Logs 三驾马车，还必须涵盖 AI 场景特有的观测数据，如用户 Prompt、模型返回内容、Token 消耗等。只有把这些异构数据统一融合，我们才能具备完整根因定位的数据基础。在融合数据之上，我们需要协同五大支柱能力来构建端到端的监控链路：统一的数据采集与集成、统一的数据加工处理、统一的数据展示门户、统一的看板分析，以及统一的告警触达机制。

第一个支柱是全栈观测门户。由于历史沿革，火山引擎提供了多种不同的观测产品，例如面向云产品的云监控、面向托管 Prometheus 的产品、提供客户端与服务端开箱即用监控的应用观测产品，以及云拨测、日志分析等。这些产品过去各自为战，用户需要在不同的控制台间来回切换。当需要分析 Agent 四个层次的问题时，研发人员必须在多个观测系统间反复跳转，体验极为割裂。我们的第一步工作，就是将所有观测产品汇聚到一个统一门户中，并在此基础上构建了丰富的聚合能力与场景化分析能力，其中就包括今天要重点讨论的 AI 观测功能。

第二个支柱是统一集成中心。我们期望对异构、海量的数据实现统一接入，这需要做到三点。首先是极强的兼容性：无论用户用什么技术栈开发 Agent，用什么云厂商的基础设施，用什么框架或模型供应商，我们都希望通过统一的方式采集数据。这个采集方式的基石就是拥抱 OpenTelemetry 这一完整标准生态，它提供了优秀的扩展性与跨系统互操作性。在此之上，我们构建了大量零代码的观测数据埋点方案和轻量的观测配置能力。最后，我们打造了一个统一的采集器——OneAgent，它是我们可观测团队提供的新一代数据采集与加工处理管道。从内部实践看，我们有各种不同的业务与采集方式，包括自研 SDK、OpenTelemetry SDK、Prometheus、日志等。通过 OneAgent，所有数据能够被统一采集、加工和预聚合，最终存入不同的观测产品中，打通整个采集链路。

可能有人会问，社区已有诸如 OTel Collector 这样的开源方案，为什么还要自研 Agent？从我们的经验出发，火山引擎内部承载了大量重载场景，我们需要将采集器的性能极限推向更高水位，以确保在极端压力下采集器不会成为瓶颈，关键数据不丢失。为此我们在性能优化上投入了大量精力。

第一，我们实现了发送并发度的自适应调整。系统会根据后端实时压力，如通过 RTT 指标，自动调节向后端发送的并发度。当后端状态良好、RTT 偏低时，自动调高并发度以充分利用带宽，减少数据在 Agent 层的积压；当后端性能下降、RTT 升高时，则自动调低并发度，利用本地队列缓存数据，避免对后端造成雪崩式压力。

第二，我们做了预排序增强。之前指标标签使用的是 Protocol Buffers 标准的 map 字段存储，但后来发现很多后端处理需要标签可排序，而运行时对 map 做动态排序操作极为消耗资源。我们将整个数据模型调整为基于 sortable slice 标准库的实现，标签遍历、插入、合并等操作的效率由此大幅提升，编码器因内部无需再做排序，效率提升了百分之三十以上。一些高频核心方法的性能提升甚至达到了一个数量级。

除此之外，我们还深入代码细节，包括预分配大块内存以减少动态分配次数、尽可能使用栈内存减少对象逃逸到堆上、利用对象池和引用计数复用临时对象，以及优化日志打印减少不必要的字符串拼接和函数开销。最终我们在 200K QPS 的条件下，将 OneAgent 与 OTel Collector 进行了性能对比，前者的数据吞吐量高出一倍左右。在实际线上重载节点上的压测显示，OneAgent 的整体负载降低了百分之五十以上，在部分极端场景节点上，性能提升近三倍。有了这些性能优化，我们才有底气在大规模 Agent 的实战中，安全高效地完成海量数据采集。

第三个支柱是统一数据加工。数据采集进来后，我们有一套加工逻辑以更低成本、更高效率的方式将其存储起来。在数据清洗与过滤环节，由于 Agent 场景中用户的 Prompt 和 Input 常包含敏感信息，我们首先要进行数据脱敏。同时建立了黑白名单过滤机制，自动过滤掉无用的探针心跳、压测或调试数据，减少整体数据量。在数据富化环节，我们自动对所有观测数据补齐统一的上下文标签，如集群、地域、租户等，并实现错误码到明确业务语义的动态映射，方便后续排查。我们还提供了降维与转换能力，尤其是从日志和链路中提取关键字段生成持续 Metrics 指标。这一能力至关重要，因为大量数据在采集侧并不容易直接转换为 Metrics，而转换为指标后又能够极大便利后续的聚合查询与问题定位。此外，面对指标采集中常见的高基数、高密度原始数据问题，我们也做了预聚合处理，以加快查询速度。最后，我们实施了动态分流与冷热存储策略，将需要高频告警和短期业务分析的热数据存入高性能存储，将海量全量明细数据存入冷存储，以降低整体资源开销。

第四个支柱是统一看板，我们的目标不仅是发现问题，更是帮助研发者更快地定位问题。这个统一看板首先要提供跨类型数据的联动能力：当看到一个 Metrics 异常时，用户能在同一界面快速唤起日志和 Tracing 分析，无需来回跳转。看板还支持在同一视图内对不同类型数据进行统一混绘，指标、Trace、日志乃至拓扑图可以共处一个 Dashboard。考虑到大量业务方此前积累了许多 Grafana 看板资产，我们提供了完全兼容 Grafana 模型定义的能力，支持海量存量 Dashboard 的快速导入与导出。最后，我们将自身在 Agent 和大模型领域的行业最佳实践沉淀为开箱即用的预置看板，用户可通过一键克隆或多个看板的按需拼装，快速组装出符合自身需求的观测看板。

第五个支柱是统一告警。我们主要做了三件事，第一是智能告警降噪。基于规则收敛、去重和依赖抑制，我们将海量告警风暴收敛为一条核心告警，推送给相关运维同学，极大减轻了他们的认知负担。第二是统一告警配置管理。此前不同观测产品需要用户在不同位置重复配置通知策略、通知人和告警规则，现在用户只需在一个地方完成配置，即可对所有观测产品统一生效。第三是告警规则的开箱即用。我们将 TTFT、TPOT 的突增、Token 成本暴涨、工具调用大规模失败等典型场景，预置为告警规则，用户无需去理解和关心阈值如何设定，这些都是团队的经验沉淀。

总结起来，统一观测底座是我们构建 Agent 深度观测的前置依赖条件。通过 OTel 标准与 OneAgent，我们实现了全栈数据的完整接入，保证链路不断。通过统一数据加工，涵盖清洗、脱敏、派生，我们实现了数据的高效存储与计算，并控制了长期存储成本。通过统一观测门户和看板，我们达成了跨 Metrics、链路、日志的一体联动排查能力。通过统一告警，能够及时发现异常并触达相关责任人。所有这些能力，最终都是为了支撑 Agent 时代必须实现的三个目标：链路的白盒化可见性，对“慢在哪、错在哪、成本消耗在哪”的根因可解释性，以及从观测数据回流到评测优化、最终线上验证的业务闭环。

3

深水区探索：AI 与 Agentkit 深度观测

在统一观测底座的基础上，我们深入 AI 与 Agent 场景进行了专项探索。

首先是 AI 通用观测能力的建设。我们打通了从底层模型推理层到最终基础设施层的完整调用闭环，这背后完成了三件事。第一，我们制定了 AI 语义规范。在 OpenTelemetry 标准体系的基础上，我们大幅拓展了面向大模型的专属语义字段，这为后续的埋点与数据串联提供了基础规范。第二，我们对不同框架和不同模型供应商，基于这套 AI 标准语义做了统一的数据规划，并将其纳入管控系统。这意味着，无论用户用什么框架开发 Agent、调用什么后端的模型供应商，都能获得一致的观测体验。第三，我们将上层 Prompt、Response 的内容分析，与底层 GPU 利用率、网络吞吐等指标做了完整关联，实现了真正的全栈穿透透视能力。

由此，我们形成了三项核心观测能力。第一是精细的时延拆解能力，能够精确捕捉 TTFT 和 TPOT 的数据抖动。根据这些数据，我们可以准确判断是模型思考变慢了，还是模型吐字速度变慢了。第二是详细的 Token 消耗监控。我们按业务、用户、模型等不同维度对 Prompt 和 Response 的 Token 消耗做了聚合分析透视，能够快速揪出成本消耗的大头。第三是针对多轮会话的会话分析管理。我们将所有上下文、Prompt 和 Response 内容在经过脱敏处理后进行保存，这些数据未来可用于问题排障、效果评估以及安全审计。

以上是通用能力，接下来以我们在火山引擎上提供的 Agent 研发平台——AgentKit 为例，介绍深度集成实践。AgentKit 是一个为方便开发者构建、部署和运行 Agent 而提供的全方位支撑平台。除了模型服务本身，它内置了一整套工具集，包括记忆、知识库、监控、评测等基础设施。我们的观测团队与 AgentKit 团队密切合作，在 Agent 的完整生命周期中进行了深度埋点与观测、看板和告警的集成，帮助用户达到开箱即用的观测体验。所有在 AgentKit 上开发 Agent 的用户，无需编写任何一行观测代码，就能获得一致的专业观测能力。

我们为 AgentKit 提供了一个全局运行时洞察看板。看板最上层展示核心环境指标，如模型 Token 消耗、调用成功率、调用次数和延迟等的变化趋势。用户还可以下钻到模型用量、所用工具以及这些工具的调用量和耗时等详细数据，在一个统一视角中快速定位劣化指标的源头。

发现问题之后，如何定位呢？我们设计了一个白盒化调用链分析体系，分为两层。第一层是完善的会话诊断分析。我们将多轮会话的每个 Trace 汇聚到一个视图中，展示其整体耗时、输入输出等概要信息。当用户锁定某个存在异常的对话 Trace 时，再进入第二层调用链分析。这一层清晰地展示规划耗时、各种工具的执行状态、与大模型交互的状态，甚至支持多模态分析能力，完整还原整体链路。有了完整链路，就能进行边界定界：通过对比 Trace 中不同 Span 的耗时与状态，我们可以判定问题究竟出在模型生成慢、外部 API 调用响应慢，还是数据处理环节存在瓶颈，从而快速完成责任定界。

除了模型和工具调用外，Agent 的记忆以及它对外部知识库的依赖，同样深刻影响最终响应效果，而且这些问题往往更加隐蔽。因此，我们对记忆和知识库也做了详细监控。我们监测所有 Memory 加载耗时、RAG 过程中的检索索引性能以及 Embedding 耗时。除此之外，对 Memory 和 RAG 相关的 Trace 也做了深度埋点，能够在 Trace 中详细透出 RAG 的召回结果、相关性得分以及使用的 Chunk 内容。这些信息帮助开发者快速评估知识库的召回效果，高效定位可能的质量问题。

4

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

拥有了上述 Agent 观测能力之后，我们面临的下一个问题是如何帮助 Agent 持续迭代和优化，最终达到更好的效果，实现一个工程化的闭环。我们提炼了一条四点闭环路径：首先拥有观测数据，然后把观测数据回流形成评测集，再回到评测系统中进行系统化评估，最后根据评估结果持续迭代循环。

在线上运行过程中，Agent 观测能力会沉淀出海量的 Trace 数据。第一步是定位高价值的 Trace 目标。怎样的 Trace 具备高价值呢？例如，调用失败的异常场景，以及高频使用的典型链路场景。我们需要通过特定能力将这些高价值 Trace 回流到评测系统，形成一个能够覆盖主流场景的高价值评测集。有了评测集之后，我们进行两类评测。一类是离线评测，即在每个 Agent 版本上线前，针对新旧两个版本，利用回流的数据做详细的对比与回归测试，用客观指标说话，避免线上翻车。另一类是在线评测，在线上生产环境中持续监控 Agent 的效果与异常，一旦发现质量退化迹象，比如误答率上升、Token 消耗异常波动，第一时间采集数据进行在线评测和定位。

评测之后，我们要把评测结果持续沉淀为优化动作。这可能包括提示词调整、检索策略优化、模型路由策略切换等，最终形成持续迭代的效果。

在上述闭环中，数据回流是打通观测与评测的桥梁。我们提供了两类回流机制。第一类是离线回流，即针对线上高价值 Trace，按照一定规则周期性进行清洗、提取，然后转化为评测集，以满足大规模离线评测的需求。第二类是在线回流。线上运行过程中，我们提供了多种机制让用户对 Agent 返回进行反馈，如点赞、点踩；同时持续关注核心异常或典型链路，比如模型返回异常导致的指标波动。这些数据能够被实时回流，支撑分钟级的问题呈现与动态告警拦截。在回流过程中，我们还提供了自动化标注能力，将离散的观测点位对齐为结构化的评测数据集，方便评测系统使用。

基于回流数据，我们构建了评测系统。这个系统为 Agent 划定能力基准线，是保障最终结果质量与过程可控的命脉。它有五个值得详述的要点。第一，我们需要对回流数据进行快速评测，动态生成评测基准题库。第二，基于从各种数据源涌入的评测集，我们建立了灵活的管理模式，包括版本控制、切片抽样等策略，以保证评测集的样本科学性与场景覆盖度。第三，我们构建了多维度的评测指标体系，不仅关心答案的准确性与相关性，还内置了 Agent 专有的深度评测指标，包括 Token 效率、API 调用的合理性、规划轨迹分析以及拒答率统计等。第四点尤为关键，即自动化与人工协同的能力。目前大规模自动化评测基本依赖大模型作为评估器，但评估结果有时会偏离预期。因此，我们提供了白盒化的人工复核页面，针对高价值、高风险的场景，引入人工标注的对齐能力。第五，基于评测结果，我们最终能够反哺模型与提示词的持续优化、工具接口调整，为 Agent 整体思考方式的进化提供理论基础。

在构建评测系统的后续实践中，我们发现了两个非常有价值的点。第一是多实验对比分析能力，在评测和调优过程中，我们常常会有多条并行推进的调优思路。如果串行调优和评测，整体效率会非常低。例如，我们可能同时调整提示词、切换模型、调整 RAG 设计、增加工具等等，这意味着有大量实验在并行执行。多实验对比分析让我们能从宏观角度对比不同实验对最终结果的提升效果，也能从微观角度分析每个评测数据在不同实验中的表现，清晰识别哪些数据在优化、哪些在劣化。第二就是刚才提到的人工标注打分能力，通过人工标注，我们可以校正自动化大模型评估器的实际效果，为评测结果的可靠性提供保障。

5

落地为王：OpenClaw 观测实践

在讲述了评测与优化的闭环逻辑之后，我将以具体的 OpenClaw 落地场景为例，分享我们完整的实践过程。

如果大家真正在大规模运维 OpenClaw，就会发现它会出现各种各样奇怪的问题。因为 OpenClaw 内部包含大量配置文件、众多插件以及版本自身的迭代更新，任何一次操作都有可能导致配置文件异常，致使龙虾无法启动或者反馈出现异常，此时我们就需要去排查定位。在接入我们统一观测实践之前，整体排障极为困难。如同我前面提到的四层结构，我们需要拉上 OpenClaw 开发团队、运维团队、模型团队、基础设施团队等多个不同团队分别定位问题。接入统一观测底座之后，我们获得了显著的业务收益——最明显的就是平均修复时间整体降低了百分之八十以上，极大提升了工程师的幸福感。

我们具体是怎么做的？核心思路是：以服务等级指标度量先行的标准，用数字驱动的能力去建设全链路可观测性。在传统系统里，SLI 比较简单，主要关心成功率和延迟情况。但在 OpenClaw 中则大不相同。一个请求从进入系统到最终响应返回，中间涉及了多步推理、多次工具调用，以及内部大量状态的持续更新，最终才给出一个结果。

为了能够排查出这么多层次的问题，我们构建了一套多层可归因且面向任务的 SLI 体系。这套体系采用六层架构：Channel 接入层，我们关心连接成功率和端到端成功率和耗时，这是最核心的北极星指标，也是用户体感最明显的；其下是 Message 与 Session 层，我们关心 Session 初始化成功率和 Session 卡顿恢复成功率；再往下是调度层，包括出入队列与延迟指标；接着是执行层、大模型工具层、缓存命中层；最后是定时任务的创建成功率和执行成功率。

有了这套 SLI 体系后，我们着手解决数据采集问题。我们并不满足于通用日志信息的抓取，而是深入整个 OpenClaw 运行时，通过 Hook 机制，在会话开始、模型推理、工具调用、任务分配等关键时间点进行相关信号采集。我们构建了一个自研的、基于 OpenClaw 的插件，来保证数据采集的完整性和实时性，从源头上真正抓住了最真实的执行现场。我们做过对比，将官方的 OpenClaw 观测插件、一些基础的日志采集方案，与我们的自研插件，从多轮对话场景支持、工具调用覆盖、采集原理、信息丰富度、归因分析能力、跨端和接入复杂度等不同维度进行了详细分析。最终我们实现的效果是，真正做到了可归因、可迭代的观测数据采集，并且接入相对简单。

在整体数据链路中，数据采集不仅包括插件中 Trace 数据的采集，还涵盖通过 OneAgent 在宿主机上采集容器日志（主要是结构化的诊断日志），以及采集宿主机的运行指标，如 CPU、内存等。这些指标能够帮助我们更好地了解龙虾在执行过程中后端云服务器的状态——比如 ECS 的 CPU 消耗增长可能导致龙虾响应变慢，内存增长可能导致龙虾出现 OOM 异常报错。我们还对其定时任务的数量及运行状态进行了主动采集与周期上报。所有这些数据汇总到后端，经过统一数据加工，包括提炼、中间数据清洗，以及将 Trace、Log 转换为一系列 Metrics 指标，最终构建出统一的 SLI 稳定大盘。

这个面向用户视角的大盘包含了关键黄金指标，例如对话成功率，反映请求是否得到了有效回应；响应时间，是否在可接受范围内反馈给了用户；以及定界指标，Agent 内部出错还是其他环节出错的区分能力，以及系统能否快速及时响应的能力。基于这些 SLI，我们构建了开箱即用的 SLI 大盘，也提供了开箱即用的 SLI 告警模板。

接下来，我想以几个具体的排障场景为例来说明这套体系的实际效果。第一个问题非常常见：某些下游 API 可能导致 Agent 响应异常缓慢。这类问题的定界相对直接。比如，用户反馈了某个实例异常，我们拿到实例的用户 ID，找到对应的实例，然后检索对应 Trace 查看其火焰图。在一个具体场景中，我们发现火焰图里一个调用 get_weather_api 的 Span 耗时极长，占据了整个请求耗时的百分之九十，而且最终返回的结果还不是成功，而是一个网络超时错误。我们因此清晰地界定了根因：天气查询 API 供应商发生了网络抖动，导致了整体异常。基于此，我们给出的修复建议是：增加超时机制与重试机制，并对该获取天气的工具进行降级处理。

第二个问题是 Token 成本爆炸。这也是 Agent 运维中的高频痛点。有时我们会接到客户或者财务部门发出的预警，称 Agent 在某些时间段内的 Token 消耗出现了爆炸性增长，需要立即排查。我们怎么排查？利用前面构建的成本看板，从异常的消耗高点出发，迅速定位到具体的 Agent 和异常时间段。然后筛选出这段时间内的异常 Trace，在 Trace 内部进行深入分析。在一个典型案例中，我们发现一个 generate_summary 工具被频繁调用了数十次。进一步查看这个 Span 内的 Prompt，发现 Prompt 在不停地对 Agent 记忆中的内容进行摘要、再摘要，形成了一个无限循环，导致上下文被雪球式放大，Token 用量也被指数级提升。分析下来，根因很清晰：我们的 Prompt 设计出现了缺陷，没有明确指示 Agent 在生成摘要之后需要停止。我们据此总结出几条修复建议：一是重做 Prompt，增加明确的终止指令；二是在 Agent 层面设置围栏，增加最大迭代循环次数，超出限制后强制跳出循环；三是增加预算与早停机制，为每个任务设定 Token 消耗预算，超支后终止任务；最后，我们将这个失败案例加入回归测试集，以防止未来再次出现类似的 Token 消耗异常问题。

第三个问题是更隐蔽也更棘手的模型幻觉。比如，用户反馈在一个非常长的多轮对话中，Agent 在后期开始出现自言自语或胡说八道的情况，它已经完全不记得用户之前提供的关键信息，出现了严重的幻觉。然而，大前提是这个模型自身在标准评测集上的表现一切正常。那么该如何定位？我们检查了这个会话的完整 Trace，重点关注了两类数据：一类是与搜索增强生成相关的 Span，另一类是规划历史与记忆加载相关的环节。结果发现了两个问题。第一，在搜索增强生成的检索 Span 里，当对话进入后期时，召回出来的相似度得分极低，查看具体召回的文档片段，发现它们与用户当前的提问几乎毫无关系。第二，我们看到 Trace 初始化阶段有一个加载记忆的 Span，它的耗时很长，透出的上下文在多轮迭代后已被截断，丢失了用户早期输入的关键信息。

这两个发现共同构成了根因：一方面，用户在后期对话中习惯使用口语化表达，导致其查询语句与知识库中的标准术语相似度很低，搜索增强生成实质上失效了；另一方面，长对话过程中总 Token 消耗超出了上限，系统发生了自动截断，对整体效果产生了严重影响，模型和 Agent 由此开始自由发挥。我们提出的修复建议包括：优化搜索增强生成，引入查询重写能力以应对口语化输入，并调整分块策略与嵌入模型；优化记忆管理能力，对长周期对话形成摘要机制，确保早期输入能够结构化、专业化地持久保存，避免关键信息丢失；最后建立专门的轨迹评测，确保在长对话场景下，关键信息的召回率不低于某一预设阈值。

6

 总结与展望

在这次整体实践中，我们完成了多项 Agent 基础设施的建设工作。首先，我们建设了一个全站统一的 Agent 观测基座，融合了集成、加工、看板和告警能力，有效降低了多个观测产品各自为战带来的认知与维护成本。其次，我们深入 Agent 的生命周期内部，提供了覆盖耗时、Token 消耗等的深度观测能力。第三，我们白盒化了整个链路的观测能力，通过 Trace 重建深刻还原了从规划、工具调用到大模型交互之间的复杂编排，极大便利了瓶颈定位。最后，我们打通了从观测数据回流到评测优化的完整数据链路，保障大规模 Agent 从被动的故障排查，走向数据驱动的持续演进。

最终我们实现了三个核心效果：可见——能够清晰看到大模型过程中每一步是如何具体执行的；可解释——通过白盒化的诊断与因果边界定界定位，包括成本归因分析，能够解释常见的为什么慢、为什么错以及成本究竟消耗在哪里；可行动——通过告警联动、数据回流与优化闭环，能够持续对 Agent 进行迭代更新优化。

关于未来的展望，如果用一句话来概括，我们希望能从当前全面的 Agent 体检，迈向某种程度的自动驾驶。这包含三个方向。第一，我们希望能拥有更智能的排障能力，基于可观测数据实现自动的根因定位、分析和诊断结果推送，让用户无需盯着大盘看，而是自动收到某个 Agent 性能劣化或效果不佳的具体案例。第二，在拿到这些数据与分析结果之后，我们希望能从被动的可见性向主动治愈的能力演进。我们将推动观测系统与业务编排框架进行联动，实现如 API 主动动态降级、Token 暴涨的自动化拦截、智能路由切换等一系列主动治愈能力。第三，我们希望能构建一个更开放的生态，将 Agent 观测能力通过标准化 API 对外提供，与第三方工具和平台无缝集成，最终帮助更多业务方实现 Agent 能力的平稳、高效运行。

作者介绍

钱世俊，字节跳动火山引擎云基础应用观测技术负责人，曾就职于蚂蚁、eBay 等企业，长期投入云计算与可观测等领域的架构设计与落地实践，并积极投身各项基础设施开源项目的维护工作，曾多次在 Open Source Summit、KubeCon 等会议进行主题分享。

会议推荐

QCon 全球软件开发大会·2026（上海站）现已正式启动。本届大会聚焦 Harness AI 时代的工程实践，从「构建 AI」到「驾驭 AI」，围绕 AI Native 架构、Agent Runtime、AI Infra、Agent 安全与可观测、Loop Engineering、具身智能与世界模型 等热门技术方向，邀请全球技术社区与产业一线实践者，共同分享 AI Native 时代最具价值的工程经验。

文章来自于"InfoQ"，作者 "钱世俊"。