北京
智能体的“黑盒”困境
大语言模型能力边界持续拓展，AI 智能体已从概念验证阶段迈入大规模工程落地。但智能体内部复杂的任务规划、工具调用与记忆检索机制，让传统应用观测手段在非确定性系统面前力不从心。本文整理自火山引擎应用观测技术负责人钱世俊在 QCon 全球软件开发大会 2026 北京站的分享《给智能体做“CT”：大规模智能体的可观测与质量保障体系》。
钱世俊系统阐述了团队在智能体可观测性领域的工程实践，分享如何从零构建一套覆盖基础设施到业务语义的统一观测底座，并以此实现智能体内部链路的白盒化透视、根因可解释性以及持续优化的工程闭环。
现代智能体能够自主进行任务规划，调用种类繁多的外部第三方工具，并利用记忆与知识库沉淀上下文，完成更复杂的业务目标。但这种能力跃升也带来全新观测挑战。系统运行正常时，智能体表现令人满意；一旦线上遭遇响应变慢、反馈报错，或出现与输入毫不相关的自言自语，传统排查手段往往难以定位具体成因，因为无法洞悉智能体内部每一步的决策逻辑。
钱世俊用医学诊断作类比：没有 CT 等深度成像技术之前，医生面对复杂症状只能依赖外部观察与经验推断。团队要做的，就是为智能体构建一套类似的“CT 系统”，让研发者看清内部一步步的判断与决策轨迹，从而回答三个核心问题：可见性，即从用户输入到最终输出的全过程发生了什么；可解释性，任何变慢、报错或成本飙升的具体原因是什么；可行动性，如何从观测数据中提炼出优化智能体、提升整体性能的可执行方案，形成可闭环的改进路径。
三个维度导致观测困难
团队经过系统性梳理，将智能体时代观测困难的原因归结为三个维度。首先，智能体与传统微服务应用存在本质差异。传统应用由确定性代码逻辑驱动，输入与输出之间的因果关系清晰；而智能体会自行规划任务、调用外部工具、沉淀记忆与知识库，任何一次请求内部都涉及大量复杂工作流，并非简单的单次大模型调用，整体复杂性呈指数级增长。
其次，运行过程中很难分析其内部决策过程。若沿用传统日志查看方式，几乎无法还原它的思考机制、规划逻辑以及执行链路，直接导致问题出现后排障极为困难。最后，智能体时代还引入一个特殊而棘手的问题——成本管控。传统微服务场景里，研发团队通过性能压测与线上流量监控，可以相对精准地规划服务资源需求，成本可控。但在智能体场景中，由于内部编排响应的不确定性，一旦出现逻辑偏差，可能在极短时间内触发巨量的大模型调用，导致 Token 消耗呈指数级激增，使成本陷入危险境地。
这些黑盒困境落到工程层面，表现为一个横跨多层的监控断层问题。如果把整个智能体系统自上而下分为四个层次：最上层是业务应用层，承载财务智能体、投资分析智能体等各类智能体实体；其下是智能体框架层，负责思考编排与工具调用调度；再往下是大模型推理服务层，提供实际模型推理能力；最底层是云基础设施层，提供 GPU、网络、容器等算力资源。
四个层次的观测数据和观测对象分散在不同系统中，关注点各不相同。业务系统层关心 DAU、用户反馈、端到端延迟与成功率等宏观指标；智能体框架层关注整体规划延迟、端到端工具调用成功率，以及 Memory 或知识库的召回成功率；大模型服务层聚焦模型推理性能，如 TTFT（首 Token 延迟）、TPOT（Token 间延迟）、Token 使用量等；云基础设施层则关注 GPU 使用率、网络吞吐量等硬件指标。
分层架构带来三个断层
正是这种分层架构导致观测出现三个断层。第一是链路断，不同层次的观测采集方式各异，经常出现链路断裂，且业务上下文在不同层级透传时容易丢失。第二是语义断，不同供应商之间存在链路孤岛，其内部链路标准的语义不对齐，为后续整体排障制造了巨大困难。
第三是因果断，最底层硬件核心指标与上层推理逻辑之间存在脱节——例如，如何将一次大模型推理异常与底层 GPU 的瞬时波动关联起来，就是一个极具难点的工程问题。
要应对上述分层断层问题，观测建设的第一步就是构建一个统一的观测基座。这个基座的核心目标，首先是融合多维度的观测数据。这不仅包括传统的 Metrics、Traces、Logs 三驾马车，还必须涵盖 AI 场景特有的观测数据，如用户 Prompt、模型返回内容、Token 消耗等。只有把这些异构数据统一融合，才能具备完整根因定位的数据基础。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
