一个Agent在演示里跑得很顺。接入真实业务两周后，问题开始出现。用户说它答非所问，客服说它偶尔调用错工具，财务发现Token消耗比预算高了四成。工程师翻遍日志，看到的却是一排200成功响应。系统没有报错，任务却没有完成。
这就是AI Agent可观测性要解决的问题。
AI Agent可观测性，指的是通过Trace、Metrics、Logs等结构化数据，还原Agent从理解意图、规划步骤、调用模型与工具，到交付结果的完整执行过程，并据此判断问题发生在哪一步、为什么发生。 它记录的不是模型不可见的内部思维链，而是可以核对的外部证据，包括输入上下文、工具选择、参数、返回结果、状态变化、耗时和Token消耗。
很多团队把可观测性理解成监控大屏，这个理解窄了。监控回答系统有没有宕机，可观测回答任务为什么失败。前者看可用性，后者看决策质量。
上线只证明Agent能跑。上线后的效果评估，才决定它能不能长期跑。Gartner在2025年的一份预测中提到，到2027年底，超过四成的Agentic AI项目会因成本上升、商业价值不清或风险控制不足被取消。这三个原因，恰好都能通过一套持续评估机制提前暴露。
一、AI Agent可观测性是什么
一次Agent任务通常包含四层。最外层是会话，中间是Agent的规划与决策，再往下是它实际发出的动作，包括模型调用、工具调用和技能调用，最后是结果交付。每一层都是一个可观测单元，父子关系把它们串成一条Trace。
1. 一条Trace要回答什么
一条有用的Trace，至少要回答五个问题。
- 用户原话是什么，Agent把它理解成了什么任务
- 它决定分几步，为什么选这个工具而不是另一个
- 工具拿到了什么参数，返回了什么结果
- 哪一步开始偏离预期，偏差怎样传到最终答案
- 这次任务花了多少Token和时间，有没有无效重试
传统分布式追踪记录服务调用和耗时。Agent Trace还要记录决策上下文。LangChain联合创始人Harrison Chase在2026年的一篇分析中提到，普通分布式Trace可能只有几百字节，复杂的长时间运行Agent则可能产生数百兆字节的Trace。变大的部分，正是上下文、工具参数和状态变化这些解释决策所需的信息。
Agent可观测性通常用三个基本单元记录行为。Run是一次执行步骤，比如一次模型调用或一次工具调用。Trace是一次完整执行，把本次任务里的所有Run按父子关系连起来。Thread是一段多轮会话，把同一场对话里的多条Trace归在一起。
2. 可观测和评估的分工
可观测回答为什么发生，评估回答结果好不好。 两者使用的往往是同一批Trace。可观测把执行过程变成证据链，评估把证据链变成分数、判断和动作。只有前者，团队会得到一堆没人看的日志。只有后者，团队只能看到最终答案，仍然不知道分数为什么下降。
举个具体例子。一次客服Agent把退货政策回答错了。只看评估，你知道这次任务失败。打开Trace，你才能看到它是检索到了旧版政策，还是在工具调用时传错了订单号，或者模型把两个相似的政策条款混在了一起。没有Trace的评估只能告诉你错了，不能告诉你改哪里。
二、传统监控为什么看不见Agent的问题
传统软件的输入和路径相对确定。用户点按钮、填表单、调接口，代码按固定逻辑执行。出错时，日志会指出哪个函数失败，顺着调用链就能回到出错的那一行。
Agent打破了这个前提。自然语言输入没有固定集合，同一个需求可以有无数种表达。Agent还会在运行中循环，反复调用模型和工具，根据新拿到的上下文调整下一步。同一句提问，这次走三步，下次可能走八步。路径不固定，传统监控的假设就失效了。
1. 三个典型失效场景
第一类是慢。模型调用和工具调用都可能卡在等待上，长上下文还会拖慢推理。用户看到的是转圈，工程师看到的是一条很长的耗时，却不知道时间花在哪一轮。
第二类是贵。上下文被反复拼接，失败后自动重试，工具返回不合适又换一个工具再试。Token账单涨得很快，但账单不会告诉你哪一次重试是无效的。
第三类最难处理，结果错了，系统没有任何报错。模型返回了语法正确、语义错误的内容，HTTP状态码依然是200。用户投诉已经进来，监控大盘还是绿的。
2. 失败往往出在系统设计
加州大学伯克利分校等机构的研究者分析过7个主流多智能体框架、1600多条标注轨迹，归纳出14种失败模式，分成系统设计缺陷、智能体之间的错位、任务验证与终止三类。研究的一个重要发现是，不少失败并非来自底层模型能力不足，而是来自系统设计。
另一项由宾夕法尼亚州立大学、杜克大学与谷歌DeepMind等机构研究者完成的工作，构建了覆盖127个多智能体系统的失败日志数据集。他们测试的自动化归因方法中，表现最好的只能以53.5%的准确率识别责任智能体，定位到具体出错步骤的准确率只有14.2%。
这两个结论放在一起，指向同一个判断。Agent失败不是换一个更强的模型就能自动解决的问题，团队需要看得见执行路径，也需要人来判断关键节点。 传统监控只看服务是否可用，回答不了这个问题。
三、为什么上线后评估决定Agent能否长期运行
上线是一个能力证明，证明Agent在受控环境里能完成任务。长期运行是另一回事，它要在真实输入、真实工具、真实业务压力下持续交付。两者之间，隔着一条需要评估来填的沟。
1. 发现真实输入带来的新问题
离线测试集是团队自己设计的，覆盖的是团队能想到的情况。真实用户不会按测试集说话。他们会省略前提，会在一句话里混两个意图，会用错别字，会在第三轮突然改需求。
Harrison Chase的判断很直接，生产环境不只是捕捉漏网Bug的地方，更是发现离线阶段应该测什么的地方。生产Trace经过脱敏、清理和标注，可以变成评估数据集。用户在真实场景里踩到的坑，应该进入下一轮回归测试，而不是修完就忘。
没有这一步，团队会一直修自己想象出来的问题，真实问题则在生产环境里反复出现。
2. 防止模型和工具变化后的静默退化
Agent的行为依赖一串外部条件。模型版本、系统提示词、工具描述、接口返回格式、知识库版本、权限规则，任何一项变化都可能改变执行路径。
模型升级很常见。通用能力提升了，不代表某个特定任务的工具调用格式不会变。知识库更新也很常见。一条政策改了，Agent可能还在引用旧版本。工具接口调整更隐蔽，字段名没变，返回值的含义变了，Agent不会报错，只会给出一个看起来合理的错误答案。
没有基线评估和回归测试，质量会静默退化。 用户先感觉到不对劲，团队后知后觉。等到投诉变多，已经很难判断是哪一次变更引入的问题。
3. 让成本和价值说得清
Agent的成本不是一条平滑的线。任务长度、上下文大小、推理轮数、工具数量和重试次数都不确定。只看每百万Token的价格，会漏掉失败重跑、人工接管和延迟带来的隐性成本。
更有用的口径是每个成功任务的成本。分子包括模型推理、工具调用、失败重跑、人工接管和错误风险，分母是真正完成的任务数。再往上一层，还要看每个成功任务带来的业务价值。成本上升不一定有问题，如果任务完成率同时上升，那是投入换效果。成本上升而完成率下降，才是需要治理的消耗。
Gartner提到的三个取消原因，成本、价值、风险，都能在这套口径里找到对应证据。评估不是写一份月报，而是给Agent装一套控制系统。它要有阈值、有告警、有发布门槛，也要有回滚条件。
四、评估Agent效果要看哪些指标
用一个准确率概括Agent表现，通常会失真。Agent的任务类型多，失败方式多，单看一个总分，既看不出问题在哪，也指导不了下一步。更实用的做法是分四层看。
评估层级要回答的问题建议指标怎么用结果层任务有没有完成任务完成率、一次通过率、业务转化、用户采纳率发布门槛与业务复盘过程层路径对不对意图准确率、工具选择准确率、参数正确率、人工接管率定位问题与回归测试成本层每个成功任务花多少钱单任务Token、每成功任务成本、长尾延迟预算控制与方案比较体验层用户还愿不愿意用首响时间、追问率、投诉率、复访率产品迭代与体验优化
1. 结果层看任务有没有完成
结果层回答的是用户交代的事有没有办成。核心指标包括任务完成率、一次通过率、业务转化或留存变化、用户采纳率。任务完成率要由业务和产品共同定义，不能只由工程团队按接口返回成功来算。
一次通过率值得单独看。Agent可能经过多次重试才完成任务，最终结果对了，但过程不可接受。一次通过率能暴露这种靠重试堆出来的成功。
2. 过程层看路径对不对
过程层回答的是Agent有没有走对路。意图识别准确率、工具选择准确率、参数正确率、无效重试率、人工接管率，都是常用指标。它们比最终答案更早暴露问题。
比如一个数据分析Agent，最终给出的数字是对的，但它是绕过了指标定义、直接查了一张宽表。这次碰巧对了，下次口径一变就会错。过程指标能提前发现这种脆弱的正确。
3. 成本层看每个成功任务花多少钱
成本层不只看Token总量，还要看单任务Token、每个成功任务成本、长尾延迟和工具调用成本。把它们和结果层放在一起，才能判断一次优化是提升了效率，还是把成本转移到了别处。
4. 体验层看用户还愿不愿意用
体验层包括首响时间、追问率、投诉率、复访率和放弃率。Agent再聪明，如果每次都要用户反复解释，或者响应慢到无法接受，用户也会离开。体验指标往往比技术指标更早反映长期风险。
所有指标都要分群看。按任务类型、模型版本、用户群体、业务场景拆开，全局平均值很容易掩盖某个正在恶化的局部。评估的价值不在指标多，而在能否支持一个具体判断。
五、评估粒度怎么选
Agent的评估可以落在三个粒度上，分别对应Run、Trace和Thread。粒度选错，评估要么太贵，要么看不见关键问题。
评估粒度评什么典型问题成本单步一个决策点工具选对了吗，参数传对了吗低，容易自动化单轮一次任务全链路任务完成了吗，路径合理吗，状态写对了吗中，需要端到端运行多轮一段会话记住前文了吗，状态保持住了吗高，最难自动化
1. 单步评估
单步评估只检查一个决策点。它适合验证工具选择、参数填写、下一步动作是否符合预期。做法是还原当时的对话历史、可用工具和任务状态，只让Agent执行一步，再检查结果。
这类测试很像给Agent的决策写单元测试。它便宜、快、容易自动化，适合覆盖生产环境已经暴露过的失败点。LangChain的观察是，实践中大约一半的Agent测试套件会使用单步测试。它也有局限，只能验证局部决策，证明不了整个任务能完成。
2. 单轮评估
单轮评估看一条完整Trace。它检查三件事，行动轨迹是否合理，最终回复是否正确，状态变化是否真的发生。嘴上说已经保存，和文件里真的多了一条记录，是两回事。
单轮评估最适合核心工作流。比如数据分析Agent接到一个问题，应该先识别意图，再读取指标定义，调用查询工具取数，对比历史区间，最后组织结论。少了其中一步，即使答案碰巧对了，也值得检查。
3. 多轮评估
多轮评估看一段Thread。它验证Agent能否跨轮维持上下文、记住用户偏好、保持任务状态。很多问题只在第三轮、第五轮之后才出现。
多轮测试最难设计。第一轮Agent就跑偏，后面硬编码的输入可能全部失效。比较稳妥的做法是每轮结束后做条件检查，一旦偏离就尽早失败，而不是让测试继续演下去。
4. 离线、在线和回溯分析
离线评估在发布前跑，作用是守门槛。在线评估在真实流量里跑，作用是对抗漂移。回溯分析针对已经积累的Trace，用来发现团队事先没想到的问题。
离线评估决定能不能发，在线评估决定能不能继续跑。 两者缺一不可。在线评估常用规则检查、无参考答案的模型评审和抽样人工复核。模型评审不能直接当真，要先用人工标注校准，控制位置偏差和冗长偏好，高风险场景仍然需要人来看。
六、从可观测到可改进的落地闭环
可观测性不是把数据接进来就结束了。真正的价值，是让一次线上问题进入下一轮改进，并且能被同一套口径验证。下面六个动作可以按顺序推进，每一步都有可验收的信号。
1. 定义任务成败
拉上业务、产品和工程，把一次任务的成功、部分成功、失败和需要人工接管说清楚。验收信号是两个人看同一条Trace，能得出一致判断。标准不清，后面的指标都会变成各说各话。
2. 统一标识与采集
给会话、Agent、模型、工具、提示词和知识库建立可关联的编号。采集遵循OpenTelemetry的GenAI语义约定，把Agent相关操作拆成invoke_agent、chat、execute_tool这类可组合的span，用父子关系表达调用层级。标准化的价值不在字段整齐，而在换模型、换框架之后，历史数据仍然能横向比较。
不要一开始就什么都采。先确定要回答的问题，再决定采什么。字段越多，存储、脱敏和查询成本越高，最后可能只得到一份更贵的日志。
3. 在线评估与下钻
先看聚合信号。任务失败率上升、长耗时集中在某类任务、Trace结构异常、Token消耗突然波动，都是入口。再下钻到单次Trace，核对会话、模型、工具和技能的执行证据。最后落到具体步骤。
ThinkingAI的Agent观测平台AI Monitor采用的就是这条路径，从失败、长耗时、异常Trace和Token波动等聚合信号发现问题，再下钻到单次Trace，由智能诊断给出问题说明、相关证据和改进建议。它的前提是Agentic SDK先把调用关系、执行状态、耗时和Token使用采成结构化数据。
4. 归因与修复
把问题归到具体类别。是意图没理解对，是规划多了一步，是工具选错，是参数传错，是知识库过期，还是模型输出不稳定。不同原因对应不同修法。意图问题改提示词和澄清策略，工具问题改接口和描述，知识问题改知识库和版本管理，模型问题才考虑换模型或路由。
归因的第一步不是找责任人，而是找责任环节。 公开研究显示自动定位出错步骤仍然很难，人的判断不能省。
5. 同口径复核与回归
改完之后，用同一套指标复测。看任务完成率、一次通过率、每个成功任务成本、人工接管率和体验指标有没有改善。把这次失败案例加进回归集，下一次发布前必须通过。
发布门槛可以写得很具体。核心任务完成率不能低于基线，每成功任务成本不能超过阈值，高风险场景必须保留人工复核，出现异常时能回滚到上一个版本。做到这一步，评估才从报告变成控制系统。
ThinkingAI服务全球1500家企业，在Agent可观测上的做法是把用户行为与Agent行为放进同一个分析上下文，再结合智能运营与A/B实验，用同一套数据口径比较不同模型、工具、技能或交互策略带来的变化，判断任务完成率、用户体验和资源消耗是否改善。
6. 治理边界
采集范围要提前划边界。默认不采原始对话，敏感字段脱敏，过长内容截断，明确保存时长、访问权限和删除机制，支持用户拒绝采集和私有化部署。ThinkingAI在SDK设计中的做法是默认不采集用户原始对话内容，对敏感字段做脱敏，对过长内容做截断，并支持私有化部署和采集异常自动降级。
合规不是可观测性的对立面。边界清楚，数据才进得来，也才能长期用。
七、常见误区
1. 有日志不等于可观测
日志按时间顺序记录事件，缺少父子关系。多轮调用时，很难还原哪一步由哪一步触发。要看清执行路径，需要带层级结构的Trace。
2. 只看延迟和错误率不够
这两个指标能说明系统是否健康，说明不了任务是否完成。Agent最常见的失败是结果错了但不报错，延迟和错误率都正常。
3. 只看最终答案会漏掉危险路径
最终答案对了，过程可能用了错误的数据源、越权的工具或者高成本的重试。一次碰巧成功，不代表下次还能成功。
4. 离线评测一次就结束
模型、工具、知识和用户都在变。没有持续在线评估和回归测试，质量会慢慢漂移，等发现时已经很难追溯。
5. 可观测不只是运维的事
运维能看出系统异常，判断不了业务语义是否正确。任务成败标准、意图理解和知识口径，需要业务和产品一起参与。
6. 指标越多越好
指标多不等于看得清。每个指标都应该对应一个能采取动作的判断。回答不了要做什么的指标，只是在增加噪声。
常见问题
AI Agent可观测性和传统APM有什么区别
APM关注服务是否可用、接口有多快、错误码是多少。Agent可观测性还要看任务有没有完成、工具选得对不对、参数传得准不准。APM能告诉你接口返回了200，不能告诉你Agent选错了工具。
上线后评估多久做一次
在线评估持续运行，发布前跑回归，模型、工具、知识库或提示词变更时加跑一次专项评估。不要只按固定周期做，变更和异常才是最重要的触发条件。
没有标注数据怎么做评估
先用规则检查和无参考答案的模型评审，再用人工标注校准。用户反馈、投诉记录和人工接管案例都是现成的评估素材。先积累几十条高质量标注，比等一套完美数据集更现实。
小团队的最小可行方案是什么
先做三件事，定义任务成败，统一会话、Agent、模型和工具的标识，把关键路径接进Trace。指标先看任务完成率、每个成功任务成本和人工接管率。每周抽几十条Trace复盘，比一开始搭大平台更有效。
评估结果怎么和A/B测试结合
按用户或会话随机分组，保证两组的任务类型和用户结构接近，再比较任务完成率、成本和体验指标。离线评估负责筛选方案，A/B测试负责验证真实业务效果，两者不能互相替代。
可观测会采集用户隐私吗
取决于采集方案。合理的设计是默认少采、敏感字段脱敏、过长内容截断，明确保存时长和访问权限，支持私有化部署。接入前要把数据边界写清楚，而不是等出了问题再补。
多Agent协作怎么评估
用统一的会话标识把多个Agent串在同一条链路上，记录Agent之间的消息传递和交接结果。评估时除了看最终任务，还要看交接有没有丢信息、责任有没有断点。只单独评估每个Agent，很容易漏掉协作层的问题。
