拓冰网站定制 
1. AI 可观测性为什么成了企业客户的必问题过去一年我参与过不下二十场企业客户的技术交流从金融、制造到零售、物流几乎每一家在聊到 AI 落地的时候最后都会绕到同一个话题上这东西上线之后我们怎么知道它到底行不行这个问题听起来朴素但它背后牵扯的东西一点都不简单。企业客户问的“AI 可观测性”表面上是在问监控、日志、告警这些传统运维词汇实际上他们真正焦虑的是一个基于大模型或者智能体Agent构建的系统它的行为是不确定的、输出是概率性的、链路是动态编排的传统的 APM 工具根本抓不住它的脉搏。你没法像监控一个 REST API 那样用固定的 QPS、延迟、错误率去框住一个会“思考”的系统。这就是为什么“AI 可观测性”从一个技术圈的小众话题迅速变成了企业采购 AI 方案时的必答题。不管你是做智能体客服、销售智能体、还是基于 Coze 或者 Python 搭建的 Agent 项目客户在 POC 阶段就会追问你的可观测性方案是什么你怎么追踪一次对话里模型调用了哪些工具你怎么发现智能体在某类问题上反复绕圈你怎么证明它没有在偷偷产生不合规的输出这篇文章我想把这件事掰开揉碎讲清楚。我会从企业客户最常见的五种问法入手说明它们为什么本质上在问同一件事然后展开讲 AI 可观测性的核心设计思路、关键实现细节、实操落地步骤以及我在真实项目里踩过的坑和总结出来的排查技巧。不管你是刚接触 Agent 开发的工程师还是正在给客户做方案的技术负责人这些内容应该都能直接拿去用。2. 五种问法背后的同一个核心诉求2.1 问法一“你们的 AI 系统怎么监控”这是最直白的一种问法通常来自客户的运维团队或者技术负责人。他们脑子里有一套成熟的监控体系主机监控、容器监控、中间件监控、业务监控每一层都有对应的工具和指标。现在突然多了一个 AI 系统他们第一反应就是把它塞进现有的监控框架里。但问题在于传统监控关注的是“系统是否正常”而 AI 可观测性关注的是“系统是否在做正确的事”。一个智能体服务CPU 使用率 30%、内存占用正常、接口响应 200ms从传统监控角度看一切健康。可实际上它可能正在给用户输出完全错误的答案或者在一个死循环里反复调用同一个工具烧掉了大量 token 却什么都没解决。所以当客户问“怎么监控”的时候我通常会先反问一句你关心的是系统层面的健康还是业务层面的效果这两个问题的答案会导向完全不同的方案设计。系统层面可以复用现有的 Prometheus Grafana 体系但业务层面需要专门为 AI 链路设计追踪和评估机制。2.2 问法二“出了问题怎么定位”这是运维和客服团队最关心的问题。一个用户投诉说“你们的 AI 客服答非所问”你需要能够快速还原这次对话的完整链路用户输入了什么、系统检索了哪些知识库内容、模型被传入了什么 prompt、模型返回了什么、有没有触发工具调用、工具返回了什么、最终输出是什么。如果这些信息没有完整记录你面对的就是一个黑盒。你只能看到用户输入和最终输出中间发生了什么完全不知道。这就好比一个微服务架构没有链路追踪出了故障只能靠猜。我在一个智能体客服项目里就遇到过这种情况。客户反馈某类退款问题总是回答错误我们一开始以为是知识库没覆盖后来通过完整的链路追踪才发现是意图识别环节把“退款”错误分类成了“换货”导致后续检索的知识库和调用的工具全都是错的。如果没有可观测性数据这个 bug 可能要在线上跑很久才能被发现。2.3 问法三“怎么保证输出是可控的”这个问题通常来自合规部门、法务部门或者业务负责人。他们不关心技术实现他们关心的是风险。一个 AI 系统如果输出了不当内容、泄露了敏感信息、或者给出了错误的业务建议责任谁来承担要回答这个问题可观测性方案里必须包含输出审核和内容过滤的追踪能力。你需要能够记录每一次输出的完整上下文包括模型版本、prompt 版本、温度参数、以及是否经过了后置过滤。当出现问题时你要能快速定位是模型本身的问题、prompt 设计的问题、还是知识库内容的问题。更重要的是可观测性数据本身就是合规审计的证据。当监管方或者内部审计问“你们怎么确保 AI 输出合规”的时候你能拿出一套完整的追踪记录和审核日志这比任何口头承诺都有说服力。2.4 问法四“怎么衡量 AI 的效果”这是业务部门最关心的问题。他们投入了预算做 AI 项目需要看到回报。但 AI 的效果不像传统软件那样容易衡量你不能简单地说“系统可用率 99.9%”就完事了。AI 的效果衡量需要一套完整的指标体系包括任务完成率、用户满意度、平均对话轮次、工具调用成功率、知识库命中率等等。而这些指标的计算全都依赖于可观测性系统采集的原始数据。没有可观测性你就没有数据没有数据你就没法衡量效果没法衡量效果你就没法向业务部门证明价值。我在给一个销售智能体项目做咨询的时候客户一开始只关注“每天处理了多少条线索”后来我们帮他们搭建了完整的可观测性体系才发现真正有价值的指标是“从线索到有效商机的转化率”和“平均每个商机的对话轮次”。这些洞察直接改变了他们的运营策略。2.5 问法五“你们和竞品比可观测性有什么优势”这是采购决策阶段的终极问题。客户已经了解了基本概念现在要对比不同方案。这个时候可观测性的深度和广度就成了关键的差异化因素。一个成熟的可观测性方案应该能够覆盖从数据采集、链路追踪、指标计算、异常检测到可视化展示的完整闭环。而且它需要适配不同的 Agent 框架和部署方式不管客户用的是 Coze 这样的平台化方案还是基于 Python、Rust 自研的 Agent 架构都能接入。这五种问法表面上角度不同但核心诉求是一致的企业客户需要对他们部署的 AI 系统拥有完整的可见性和控制力。他们需要知道系统在做什么、为什么这么做、做得怎么样、出了问题怎么办。这就是 AI 可观测性要解决的根本问题。3. AI 可观测性的核心架构与关键设计3.1 为什么传统可观测性方案不够用传统可观测性建立在三个支柱上日志Logging、指标Metrics、追踪Tracing。这套体系是为确定性系统设计的一个请求进来经过固定的处理流程产生固定的输出。你可以很容易地定义什么是“正常”什么是“异常”。但 AI 系统尤其是基于大模型和智能体的系统有几个根本性的不同。第一输出是不确定的同样的输入可能产生不同的输出你没法用固定的阈值来判断对错。第二链路是动态的智能体可能根据中间结果决定调用哪个工具、走哪条分支每次执行的路径可能都不一样。第三语义是核心传统监控看的是数值AI 可观测性需要理解文本的语义判断一个回答是否相关、是否准确、是否合规。这就意味着AI 可观测性需要在传统三支柱的基础上增加两个关键能力语义追踪和效果评估。语义追踪要能够记录和理解 AI 链路中的自然语言内容效果评估要能够自动或半自动地判断 AI 输出的质量。3.2 数据采集层的设计要点数据采集是可观测性的地基。在 AI 系统里需要采集的数据类型比传统系统丰富得多。我通常会把它们分为四类第一类是请求级数据包括用户输入、会话 ID、时间戳、渠道来源等。这些数据用于还原每一次交互的完整上下文。第二类是模型调用数据包括模型名称、版本、输入 prompt、输出内容、token 消耗、延迟、温度参数等。这些数据用于分析模型的行为和成本。第三类是工具调用数据包括工具名称、输入参数、输出结果、调用耗时、成功与否等。这些数据用于追踪智能体的决策路径。第四类是评估数据包括人工标注、自动评估分数、用户反馈等。这些数据用于衡量 AI 系统的实际效果。采集这些数据的时候有几个关键的设计决策。首先是采样策略全量采集的成本很高尤其是 token 消耗大的场景需要根据业务重要性设计分层采样。其次是脱敏处理用户输入和模型输出可能包含敏感信息采集时必须做脱敏。最后是异步写入采集动作不能阻塞主流程否则会影响用户体验。3.3 链路追踪在 Agent 场景下的特殊挑战链路追踪在微服务架构里已经很成熟了核心思路是给每个请求分配一个唯一的 Trace ID然后在各个服务之间传递最终把所有相关的 Span 串联起来。这个思路在 Agent 场景下依然适用但有几个特殊挑战。第一个挑战是动态编排。传统微服务的调用链路是相对固定的A 服务调用 B 服务B 服务调用 C 服务拓扑结构基本不变。但 Agent 的调用链路是动态的它可能根据用户的输入决定调用哪些工具、以什么顺序调用、调用多少次。这就要求追踪系统能够动态地记录和展示这些变化。第二个挑战是嵌套调用。一个 Agent 可能调用另一个 Agent形成多层嵌套。每一层都有自己的上下文和决策逻辑追踪系统需要能够清晰地展示这种层级关系。第三个挑战是流式输出。很多 AI 应用采用流式输出token 是一个一个生成的。追踪系统需要能够记录完整的流式过程包括首 token 延迟、生成速度、以及最终完整输出。我在实际项目中采用的方案是在 Agent 框架层面做统一的埋点每个关键节点意图识别、知识检索、工具调用、模型生成都生成一个 Span并通过上下文管理器传递 Trace ID。这样不管 Agent 的编排逻辑怎么变追踪数据都是完整的。3.4 指标体系的搭建思路AI 可观测性的指标体系需要分层设计。最底层是系统指标包括 CPU、内存、网络、GPU 利用率等这些可以复用现有的监控体系。中间层是服务指标包括请求量、延迟、错误率、token 消耗速率等这些需要专门为 AI 服务设计。最上层是业务指标包括任务完成率、用户满意度、转化率等这些直接对应业务价值。在搭建指标体系的时候我建议遵循“少即是多”的原则。不要一上来就定义几十个指标而是先聚焦最核心的几个。比如对于一个智能体客服最核心的指标可能就是首次响应时间、问题解决率、平均对话轮次、用户满意度。先把这几个指标做准做稳再逐步扩展。另外指标的维度设计很重要。同一个指标按不同的维度拆解能发现完全不同的问题。比如“问题解决率”这个指标按渠道拆解可能发现某个渠道的效果特别差按问题类型拆解可能发现某类问题总是解决不了按时间段拆解可能发现某个时间点之后效果突然下降。这些洞察是优化系统的关键依据。3.5 评估与反馈闭环的设计可观测性不只是“看”还要能“评”。AI 系统的输出质量需要持续评估而评估的方式通常有三种自动评估、人工评估、用户反馈。自动评估可以用规则引擎也可以用另一个模型来做裁判。规则引擎适合判断一些硬性条件比如输出是否包含敏感词、是否超过长度限制、是否包含特定格式。模型裁判适合判断一些软性条件比如回答是否相关、是否有帮助、是否准确。人工评估是最可靠的但成本也最高。通常的做法是抽样评估每天或每周抽取一定比例的对话进行人工标注用标注结果来校准自动评估的准确性。用户反馈是最直接的信号但覆盖率通常很低。需要设计低摩擦的反馈入口比如点赞点踩按钮、简单的满意度评分同时要能够把反馈数据和具体的对话链路关联起来。这三种评估方式的数据最终要汇总到一个统一的评估看板上形成“采集-评估-分析-优化”的闭环。这个闭环跑通了AI 系统才能持续迭代和改进。4. 实操落地从零搭建一套 AI 可观测性体系4.1 技术选型与工具链搭建搭建 AI 可观测性体系第一步是选型。市面上的工具很多我根据实际项目经验给出一套比较务实的组合方案。对于追踪和存储如果团队已经有微服务可观测性基础可以复用现有的链路追踪系统比如 Jaeger 或者 Zipkin只需要在 Agent 框架里做适配埋点。如果是从零开始我建议考虑专门为 LLM 应用设计的可观测性平台这类平台通常内置了对 prompt、token、工具调用的支持接入成本更低。对于指标计算和展示Prometheus Grafana 依然是性价比最高的组合。Prometheus 负责指标采集和存储Grafana 负责可视化。AI 相关的指标可以通过自定义 exporter 暴露出来。对于日志存储和检索Elasticsearch 或者 Loki 都是不错的选择。关键是日志的结构化设计要把 Trace ID、会话 ID、模型版本等关键字段作为索引方便后续检索和关联。对于评估和标注如果预算允许可以考虑专门的标注平台。如果预算有限用简单的表格工具加上脚本也能跑起来关键是流程要规范。下面是一个典型的部署架构示意我用文字描述Agent 服务在运行时通过 SDK 采集追踪数据异步发送到采集网关采集网关做脱敏和格式化后分别写入追踪存储、指标系统和日志系统评估模块定期从存储中拉取数据运行自动评估并把结果写回Grafana 看板从各个数据源读取数据统一展示。4.2 埋点方案设计与代码实现埋点是可观测性体系的核心。埋点的质量直接决定了后续分析的深度。在 Agent 场景下我通常会在以下几个关键节点做埋点第一个节点是请求入口。记录用户输入、会话 ID、渠道、时间戳生成 Trace ID。第二个节点是意图识别。记录识别出的意图、置信度、候选意图列表。第三个节点是知识检索。记录检索 query、检索到的文档 ID 和分数、最终选用的文档。第四个节点是模型调用。记录模型名称、prompt 内容、输出内容、token 消耗、延迟。第五个节点是工具调用。记录工具名称、输入参数、输出结果、耗时、成功与否。第六个节点是输出返回。记录最终输出、是否经过过滤、过滤原因。下面是一个简化的 Python 埋点示例展示如何在 Agent 执行过程中记录关键节点import time import uuid from contextlib import contextmanager class TraceContext: def __init__(self, trace_idNone): self.trace_id trace_id or str(uuid.uuid4()) self.spans [] contextmanager def span(self, name, **attributes): span { trace_id: self.trace_id, span_id: str(uuid.uuid4()), name: name, start_time: time.time(), attributes: attributes } try: yield span finally: span[end_time] time.time() span[duration_ms] (span[end_time] - span[start_time]) * 1000 self.spans.append(span) self._report(span) def _report(self, span): # 异步上报到采集网关实际项目中应使用消息队列 print(f[TRACE] {span[name]} duration{span[duration_ms]:.2f}ms) # 使用示例 def handle_user_query(query, session_id): ctx TraceContext() with ctx.span(request_entry, queryquery, session_idsession_id): intent recognize_intent(query, ctx) docs retrieve_knowledge(query, intent, ctx) response generate_response(query, docs, ctx) return response def recognize_intent(query, ctx): with ctx.span(intent_recognition, queryquery): # 调用意图识别模型 intent refund_query return intent def retrieve_knowledge(query, intent, ctx): with ctx.span(knowledge_retrieval, queryquery, intentintent): docs [doc_1, doc_2] return docs def generate_response(query, docs, ctx): with ctx.span(model_generation, modelgpt-4, doc_countlen(docs)): response 这是生成的回答 return response这个示例展示了最基本的埋点模式。在实际项目中还需要考虑异步上报、批量发送、失败重试、采样控制等工程细节。4.3 关键指标的计算与可视化埋点数据采集上来之后需要计算成指标才能用于监控和分析。下面这张表列出了我常用的核心指标及其计算方式指标名称计算方式用途首次响应时间从请求入口到首个 token 输出的时间衡量用户体验端到端延迟从请求入口到完整输出返回的时间衡量系统性能Token 消耗速率单位时间内消耗的 token 总数成本监控工具调用成功率成功调用次数 / 总调用次数衡量工具稳定性知识库命中率检索到有效文档的请求数 / 总请求数衡量知识库覆盖度意图识别准确率正确识别意图数 / 总请求数衡量意图识别效果平均对话轮次总对话轮次 / 总会话数衡量问题解决效率用户满意度好评数 / 总评价数衡量整体效果这些指标在 Grafana 上可以做成多个看板。我通常会把看板分为三层实时监控看板展示当前的核心指标和告警状态趋势分析看板展示指标随时间的变化趋势下钻分析看板支持按维度拆解和查看明细。4.4 告警策略与异常检测告警是可观测性体系的价值出口。没有告警采集再多数据也只是躺在数据库里。但 AI 系统的告警策略和传统系统很不一样不能简单地设一个阈值就完事。我通常会把告警分为三类。第一类是硬性告警比如服务不可用、接口错误率超过阈值、token 消耗异常飙升这些可以用传统阈值告警。第二类是趋势告警比如问题解决率连续下降、平均对话轮次持续上升这些需要用趋势检测算法。第三类是语义告警比如出现了特定类型的负面反馈、检测到敏感内容输出这些需要结合语义分析。告警的收敛和降噪也很重要。AI 系统的波动性比传统系统大如果告警太敏感运维团队会被淹没。我通常会用告警分组、告警抑制、告警升级等策略来控制告警噪音。4.5 与现有运维体系的集成企业客户通常已经有成熟的运维体系AI 可观测性不能是一个孤岛需要和现有体系集成。集成的关键点有几个统一身份认证可观测性平台的登录和权限要接入企业现有的 SSO 体系。统一告警通道AI 相关的告警要能够发送到企业现有的告警平台比如钉钉、企业微信、PagerDuty 等。统一数据标准Trace ID、会话 ID 等关键标识要和企业现有标准对齐方便跨系统关联分析。统一看板入口如果企业有统一的运维门户AI 可观测性看板应该能够嵌入进去。这些集成工作看起来琐碎但直接影响可观测性体系的落地效果。我见过不少项目技术方案做得很好但因为没做好集成运维团队不愿意用最后沦为摆设。5. 常见问题与排查技巧实录5.1 数据采集不完整怎么办这是最常见的问题。表现是追踪链路断断续续有些请求有完整数据有些请求只有部分数据。排查思路通常是这样的先检查埋点覆盖度确认所有关键节点都有埋点。我遇到过一种情况开发同学只在主流程做了埋点异常分支和重试逻辑没有埋点导致出问题时反而没有数据。再检查上下文传递确认 Trace ID 在异步调用、线程切换、跨服务调用时没有丢失。Python 的 asyncio、Java 的线程池都是容易丢上下文的地方。最后检查上报链路确认采集 SDK 到采集网关的网络是通的没有因为超时或限流导致数据丢失。可以在 SDK 里加上本地缓冲和重试机制。5.2 追踪链路断裂怎么排查链路断裂和数据采集不完整不太一样。数据采集不完整是某些节点没数据链路断裂是节点之间有断点Trace ID 传不下去了。排查的时候我会先看断点出现在哪个环节。如果是跨服务调用断裂检查 HTTP header 或者消息队列的 message header 里有没有正确传递 Trace ID。如果是异步任务断裂检查任务提交时有没有把上下文序列化进去。如果是第三方服务断裂那就需要在调用第三方服务的边界做手动埋点把 Trace ID 记录下来。注意很多第三方 SDK 不会自动传递 Trace ID需要在集成时手动处理。这是我在多个项目里反复踩过的坑。5.3 指标异常波动的归因方法指标异常波动是运维团队最常面对的问题。比如问题解决率突然下降了 10%你需要快速找到原因。我的归因方法通常是逐层下钻。先按时间维度看是哪个时间段开始下降的。再按渠道维度看是所有渠道都下降还是特定渠道下降。再按问题类型看是哪类问题解决率下降了。再按模型版本看是不是最近发布了新版本。通过这样逐层下钻通常能在几分钟内定位到根因。如果逐层下钻还找不到原因那就需要看明细数据。抽取一些失败的对话人工分析链路看看是意图识别错了、知识检索没命中、还是模型生成有问题。5.4 高并发场景下的可观测性挑战Agent 项目在高并发场景下可观测性本身也会成为瓶颈。采集数据量太大存储扛不住埋点逻辑太重影响主流程性能看板查询太慢影响排查效率。应对策略有几个。采样是最直接的手段可以按比例采样也可以按重要性采样比如错误请求全量采集正常请求采样采集。异步化是必须的所有采集和上报动作都要异步不能阻塞主流程。分级存储也很重要热数据存近期数据支持快速查询冷数据存历史数据用低成本存储。我在一个高并发的智能体客服项目里采用了“错误全采、正常采样 10%、关键会话全采”的策略既保证了问题排查的数据需求又把存储成本控制在了可接受范围内。5.5 常见问题速查表问题现象可能原因排查方向解决建议追踪数据缺失埋点未覆盖异常分支检查异常处理逻辑补充异常分支埋点Trace ID 丢失异步调用未传递上下文检查线程池/协程上下文使用上下文管理器传递指标计算偏差采样导致数据不准确检查采样策略关键指标全量采集告警风暴阈值设置过敏感分析告警历史调整阈值告警收敛看板查询慢数据量过大未索引检查存储索引设计优化索引分级存储评估结果不准自动评估模型偏差对比人工标注校准评估模型5.6 几个容易忽略的实操心得第一个心得是埋点要趁早。不要等系统上线了再补埋点那时候代码已经复杂了补埋点的成本和风险都很高。最好在架构设计阶段就把可观测性作为一等公民考虑进去。第二个心得是数据质量比数据量重要。我见过一些项目采集了海量数据但字段缺失、格式混乱、时间戳不准根本没法用。宁可少采集一些也要保证采集的数据是准确、完整、一致的。第三个心得是可观测性要服务于业务。不要为了技术而技术采集什么数据、计算什么指标、设置什么告警都要从业务需求出发。业务不关心的指标采集了也是浪费。第四个心得是定期回顾和优化。可观测性体系不是建好就完事了需要定期回顾哪些指标没用上可以删掉哪些告警太频繁需要调整哪些看板没人看可以下线。保持体系的精简和有效。6. 不同 Agent 架构下的可观测性适配6.1 平台化智能体与自研智能体的差异企业客户经常问的一个问题是用 Coze 这类平台搭建的智能体和用 Python 自研的智能体可观测性方案有什么不同平台化智能体的优势是开箱即用平台通常自带基础的可观测性能力比如对话记录、调用统计、简单的效果分析。但劣势是深度不够你没法自定义埋点没法获取底层的模型调用细节没法做深度的链路追踪。自研智能体的优势是完全可控你可以在任何地方埋点可以采集任何你需要的数据可以按照自己的需求设计指标体系。但劣势是工作量大需要自己搭建整套可观测性基础设施。我的建议是如果业务对可观测性要求不高用平台自带的能力就够了。如果业务对可观测性有深度需求比如需要做精细化的效果分析、需要满足合规审计要求那就需要考虑自研或者混合方案。6.2 多智能体协作场景的追踪难点多智能体协作是现在很热的方向但它的可观测性难度比单智能体高一个量级。多个智能体之间互相调用、传递消息、协同完成任务追踪链路会变得非常复杂。核心难点在于上下文的传递和合并。Agent A 调用 Agent BAgent B 又调用 Agent C每个 Agent 都有自己的上下文。追踪系统需要能够把这些上下文串联起来同时又要保持每个 Agent 的独立性。我的做法是在多智能体协作的编排层做统一的 Trace 管理。编排层负责生成根 Trace ID并在调用各个 Agent 时传递下去。每个 Agent 内部可以有自己的子 Span但都要关联到根 Trace ID。这样既能看全局又能看局部。6.3 不同框架的埋点适配策略现在 Agent 框架很多LangChain、LlamaIndex、AutoGPT、还有各种自研框架。不同框架的埋点方式不一样需要做适配。对于 LangChain 这类有成熟回调机制的框架可以直接用它的 Callback 系统做埋点接入成本很低。对于没有回调机制的框架可能需要在关键函数上做装饰器或者 Monkey Patch。对于完全自研的框架最好在设计阶段就把埋点接口预留出来。我通常会封装一个统一的埋点 SDK对上提供简单的 API对下适配不同的框架。这样不管底层用什么框架上层的埋点代码都是一样的迁移成本很低。7. 可观测性数据的价值延伸7.1 从可观测性到持续优化可观测性数据的价值不只是“看”更重要的是“用”。采集上来的数据可以用于多个方面的优化。Prompt 优化是最直接的。通过分析模型输入输出数据可以发现哪些 prompt 效果好哪些效果差从而迭代优化 prompt 设计。知识库优化也很重要。通过分析知识检索的命中率和相关性可以发现知识库的覆盖盲区补充缺失的内容。工具优化同样关键。通过分析工具调用的成功率和耗时可以发现不稳定的工具进行修复或替换。流程优化是更高层次的。通过分析完整的对话链路可以发现流程设计的不合理之处比如冗余的步骤、不必要的模型调用等。7.2 数据驱动的 Agent 迭代闭环把上面这些优化点串起来就形成了一个数据驱动的迭代闭环采集数据 - 分析问题 - 提出假设 - 实施优化 - 验证效果 - 采集数据。这个闭环跑得越快Agent 的迭代速度就越快。我见过一些团队把这个闭环做到了周级别每周都能基于数据发现几个优化点快速迭代上线效果提升非常明显。关键是要把闭环的每个环节都工具化、自动化。数据采集自动化、问题分析半自动化、效果验证自动化。人工只需要做决策和审核不需要做重复的数据处理工作。7.3 可观测性作为企业 AI 治理的基础从更高的视角看可观测性是企业 AI 治理的基础设施。企业要管理好 AI 系统首先要知道 AI 系统在做什么。没有可观测性治理就无从谈起。AI 治理涉及多个方面合规治理需要追踪输出内容确保符合法规要求风险治理需要监控异常行为及时发现和处置风险成本治理需要追踪资源消耗控制 AI 使用成本效果治理需要评估业务价值确保投入产出比。这些治理需求全都建立在可观测性数据之上。所以我在给企业客户做方案的时候通常会把可观测性定位为“AI 治理的第一步”先把这个基础打好后续的治理工作才能顺利开展。8. 我在实际项目中的几点体会做 AI 可观测性这件事技术方案固然重要但更关键的是意识和流程。我见过太多团队技术能力很强工具也选得很好但因为没有形成“用数据说话”的习惯可观测性体系建好之后没人用最后荒废了。我的经验是可观测性体系上线之后一定要配套建立数据驱动的运营流程。比如每天开一次数据晨会看核心指标的变化每周做一次深度分析找优化机会每月做一次效果复盘评估整体进展。把这些流程固化下来可观测性才能真正发挥价值。另外可观测性不是越重越好。我刚开始做的时候总想把所有能采集的数据都采集了把所有能算的指标都算了结果系统很重维护成本很高实际用到的却很少。后来我学会了做减法只采集真正需要的只计算真正有用的保持体系的轻量和灵活。还有一个体会是可观测性要和业务深度绑定。纯技术的可观测性看板业务方看不懂也不关心。要把技术指标翻译成业务语言比如“首次响应时间”翻译成“用户等待时间”“工具调用成功率”翻译成“服务可靠性”。这样业务方才能理解可观测性的价值才会主动使用和反馈。最后分享一个小技巧在项目初期可以先从一个核心场景入手把可观测性做深做透形成样板。然后再逐步扩展到其他场景。这样既能快速见效又能积累经验避免一开始就铺得太大导致失控。 AI可观测性实战：企业级智能体监控与链路追踪落地指南
1. AI 可观测性为什么成了企业客户的必问题过去一年我参与过不下二十场企业客户的技术交流从金融、制造到零售、物流几乎每一家在聊到 AI 落地的时候最后都会绕到同一个话题上这东西上线之后我们怎么知道它到底行不行这个问题听起来朴素但它背后牵扯的东西一点都不简单。企业客户问的“AI 可观测性”表面上是在问监控、日志、告警这些传统运维词汇实际上他们真正焦虑的是一个基于大模型或者智能体Agent构建的系统它的行为是不确定的、输出是概率性的、链路是动态编排的传统的 APM 工具根本抓不住它的脉搏。你没法像监控一个 REST API 那样用固定的 QPS、延迟、错误率去框住一个会“思考”的系统。这就是为什么“AI 可观测性”从一个技术圈的小众话题迅速变成了企业采购 AI 方案时的必答题。不管你是做智能体客服、销售智能体、还是基于 Coze 或者 Python 搭建的 Agent 项目客户在 POC 阶段就会追问你的可观测性方案是什么你怎么追踪一次对话里模型调用了哪些工具你怎么发现智能体在某类问题上反复绕圈你怎么证明它没有在偷偷产生不合规的输出这篇文章我想把这件事掰开揉碎讲清楚。我会从企业客户最常见的五种问法入手说明它们为什么本质上在问同一件事然后展开讲 AI 可观测性的核心设计思路、关键实现细节、实操落地步骤以及我在真实项目里踩过的坑和总结出来的排查技巧。不管你是刚接触 Agent 开发的工程师还是正在给客户做方案的技术负责人这些内容应该都能直接拿去用。2. 五种问法背后的同一个核心诉求2.1 问法一“你们的 AI 系统怎么监控”这是最直白的一种问法通常来自客户的运维团队或者技术负责人。他们脑子里有一套成熟的监控体系主机监控、容器监控、中间件监控、业务监控每一层都有对应的工具和指标。现在突然多了一个 AI 系统他们第一反应就是把它塞进现有的监控框架里。但问题在于传统监控关注的是“系统是否正常”而 AI 可观测性关注的是“系统是否在做正确的事”。一个智能体服务CPU 使用率 30%、内存占用正常、接口响应 200ms从传统监控角度看一切健康。可实际上它可能正在给用户输出完全错误的答案或者在一个死循环里反复调用同一个工具烧掉了大量 token 却什么都没解决。所以当客户问“怎么监控”的时候我通常会先反问一句你关心的是系统层面的健康还是业务层面的效果这两个问题的答案会导向完全不同的方案设计。系统层面可以复用现有的 Prometheus Grafana 体系但业务层面需要专门为 AI 链路设计追踪和评估机制。2.2 问法二“出了问题怎么定位”这是运维和客服团队最关心的问题。一个用户投诉说“你们的 AI 客服答非所问”你需要能够快速还原这次对话的完整链路用户输入了什么、系统检索了哪些知识库内容、模型被传入了什么 prompt、模型返回了什么、有没有触发工具调用、工具返回了什么、最终输出是什么。如果这些信息没有完整记录你面对的就是一个黑盒。你只能看到用户输入和最终输出中间发生了什么完全不知道。这就好比一个微服务架构没有链路追踪出了故障只能靠猜。我在一个智能体客服项目里就遇到过这种情况。客户反馈某类退款问题总是回答错误我们一开始以为是知识库没覆盖后来通过完整的链路追踪才发现是意图识别环节把“退款”错误分类成了“换货”导致后续检索的知识库和调用的工具全都是错的。如果没有可观测性数据这个 bug 可能要在线上跑很久才能被发现。2.3 问法三“怎么保证输出是可控的”这个问题通常来自合规部门、法务部门或者业务负责人。他们不关心技术实现他们关心的是风险。一个 AI 系统如果输出了不当内容、泄露了敏感信息、或者给出了错误的业务建议责任谁来承担要回答这个问题可观测性方案里必须包含输出审核和内容过滤的追踪能力。你需要能够记录每一次输出的完整上下文包括模型版本、prompt 版本、温度参数、以及是否经过了后置过滤。当出现问题时你要能快速定位是模型本身的问题、prompt 设计的问题、还是知识库内容的问题。更重要的是可观测性数据本身就是合规审计的证据。当监管方或者内部审计问“你们怎么确保 AI 输出合规”的时候你能拿出一套完整的追踪记录和审核日志这比任何口头承诺都有说服力。2.4 问法四“怎么衡量 AI 的效果”这是业务部门最关心的问题。他们投入了预算做 AI 项目需要看到回报。但 AI 的效果不像传统软件那样容易衡量你不能简单地说“系统可用率 99.9%”就完事了。AI 的效果衡量需要一套完整的指标体系包括任务完成率、用户满意度、平均对话轮次、工具调用成功率、知识库命中率等等。而这些指标的计算全都依赖于可观测性系统采集的原始数据。没有可观测性你就没有数据没有数据你就没法衡量效果没法衡量效果你就没法向业务部门证明价值。我在给一个销售智能体项目做咨询的时候客户一开始只关注“每天处理了多少条线索”后来我们帮他们搭建了完整的可观测性体系才发现真正有价值的指标是“从线索到有效商机的转化率”和“平均每个商机的对话轮次”。这些洞察直接改变了他们的运营策略。2.5 问法五“你们和竞品比可观测性有什么优势”这是采购决策阶段的终极问题。客户已经了解了基本概念现在要对比不同方案。这个时候可观测性的深度和广度就成了关键的差异化因素。一个成熟的可观测性方案应该能够覆盖从数据采集、链路追踪、指标计算、异常检测到可视化展示的完整闭环。而且它需要适配不同的 Agent 框架和部署方式不管客户用的是 Coze 这样的平台化方案还是基于 Python、Rust 自研的 Agent 架构都能接入。这五种问法表面上角度不同但核心诉求是一致的企业客户需要对他们部署的 AI 系统拥有完整的可见性和控制力。他们需要知道系统在做什么、为什么这么做、做得怎么样、出了问题怎么办。这就是 AI 可观测性要解决的根本问题。3. AI 可观测性的核心架构与关键设计3.1 为什么传统可观测性方案不够用传统可观测性建立在三个支柱上日志Logging、指标Metrics、追踪Tracing。这套体系是为确定性系统设计的一个请求进来经过固定的处理流程产生固定的输出。你可以很容易地定义什么是“正常”什么是“异常”。但 AI 系统尤其是基于大模型和智能体的系统有几个根本性的不同。第一输出是不确定的同样的输入可能产生不同的输出你没法用固定的阈值来判断对错。第二链路是动态的智能体可能根据中间结果决定调用哪个工具、走哪条分支每次执行的路径可能都不一样。第三语义是核心传统监控看的是数值AI 可观测性需要理解文本的语义判断一个回答是否相关、是否准确、是否合规。这就意味着AI 可观测性需要在传统三支柱的基础上增加两个关键能力语义追踪和效果评估。语义追踪要能够记录和理解 AI 链路中的自然语言内容效果评估要能够自动或半自动地判断 AI 输出的质量。3.2 数据采集层的设计要点数据采集是可观测性的地基。在 AI 系统里需要采集的数据类型比传统系统丰富得多。我通常会把它们分为四类第一类是请求级数据包括用户输入、会话 ID、时间戳、渠道来源等。这些数据用于还原每一次交互的完整上下文。第二类是模型调用数据包括模型名称、版本、输入 prompt、输出内容、token 消耗、延迟、温度参数等。这些数据用于分析模型的行为和成本。第三类是工具调用数据包括工具名称、输入参数、输出结果、调用耗时、成功与否等。这些数据用于追踪智能体的决策路径。第四类是评估数据包括人工标注、自动评估分数、用户反馈等。这些数据用于衡量 AI 系统的实际效果。采集这些数据的时候有几个关键的设计决策。首先是采样策略全量采集的成本很高尤其是 token 消耗大的场景需要根据业务重要性设计分层采样。其次是脱敏处理用户输入和模型输出可能包含敏感信息采集时必须做脱敏。最后是异步写入采集动作不能阻塞主流程否则会影响用户体验。3.3 链路追踪在 Agent 场景下的特殊挑战链路追踪在微服务架构里已经很成熟了核心思路是给每个请求分配一个唯一的 Trace ID然后在各个服务之间传递最终把所有相关的 Span 串联起来。这个思路在 Agent 场景下依然适用但有几个特殊挑战。第一个挑战是动态编排。传统微服务的调用链路是相对固定的A 服务调用 B 服务B 服务调用 C 服务拓扑结构基本不变。但 Agent 的调用链路是动态的它可能根据用户的输入决定调用哪些工具、以什么顺序调用、调用多少次。这就要求追踪系统能够动态地记录和展示这些变化。第二个挑战是嵌套调用。一个 Agent 可能调用另一个 Agent形成多层嵌套。每一层都有自己的上下文和决策逻辑追踪系统需要能够清晰地展示这种层级关系。第三个挑战是流式输出。很多 AI 应用采用流式输出token 是一个一个生成的。追踪系统需要能够记录完整的流式过程包括首 token 延迟、生成速度、以及最终完整输出。我在实际项目中采用的方案是在 Agent 框架层面做统一的埋点每个关键节点意图识别、知识检索、工具调用、模型生成都生成一个 Span并通过上下文管理器传递 Trace ID。这样不管 Agent 的编排逻辑怎么变追踪数据都是完整的。3.4 指标体系的搭建思路AI 可观测性的指标体系需要分层设计。最底层是系统指标包括 CPU、内存、网络、GPU 利用率等这些可以复用现有的监控体系。中间层是服务指标包括请求量、延迟、错误率、token 消耗速率等这些需要专门为 AI 服务设计。最上层是业务指标包括任务完成率、用户满意度、转化率等这些直接对应业务价值。在搭建指标体系的时候我建议遵循“少即是多”的原则。不要一上来就定义几十个指标而是先聚焦最核心的几个。比如对于一个智能体客服最核心的指标可能就是首次响应时间、问题解决率、平均对话轮次、用户满意度。先把这几个指标做准做稳再逐步扩展。另外指标的维度设计很重要。同一个指标按不同的维度拆解能发现完全不同的问题。比如“问题解决率”这个指标按渠道拆解可能发现某个渠道的效果特别差按问题类型拆解可能发现某类问题总是解决不了按时间段拆解可能发现某个时间点之后效果突然下降。这些洞察是优化系统的关键依据。3.5 评估与反馈闭环的设计可观测性不只是“看”还要能“评”。AI 系统的输出质量需要持续评估而评估的方式通常有三种自动评估、人工评估、用户反馈。自动评估可以用规则引擎也可以用另一个模型来做裁判。规则引擎适合判断一些硬性条件比如输出是否包含敏感词、是否超过长度限制、是否包含特定格式。模型裁判适合判断一些软性条件比如回答是否相关、是否有帮助、是否准确。人工评估是最可靠的但成本也最高。通常的做法是抽样评估每天或每周抽取一定比例的对话进行人工标注用标注结果来校准自动评估的准确性。用户反馈是最直接的信号但覆盖率通常很低。需要设计低摩擦的反馈入口比如点赞点踩按钮、简单的满意度评分同时要能够把反馈数据和具体的对话链路关联起来。这三种评估方式的数据最终要汇总到一个统一的评估看板上形成“采集-评估-分析-优化”的闭环。这个闭环跑通了AI 系统才能持续迭代和改进。4. 实操落地从零搭建一套 AI 可观测性体系4.1 技术选型与工具链搭建搭建 AI 可观测性体系第一步是选型。市面上的工具很多我根据实际项目经验给出一套比较务实的组合方案。对于追踪和存储如果团队已经有微服务可观测性基础可以复用现有的链路追踪系统比如 Jaeger 或者 Zipkin只需要在 Agent 框架里做适配埋点。如果是从零开始我建议考虑专门为 LLM 应用设计的可观测性平台这类平台通常内置了对 prompt、token、工具调用的支持接入成本更低。对于指标计算和展示Prometheus Grafana 依然是性价比最高的组合。Prometheus 负责指标采集和存储Grafana 负责可视化。AI 相关的指标可以通过自定义 exporter 暴露出来。对于日志存储和检索Elasticsearch 或者 Loki 都是不错的选择。关键是日志的结构化设计要把 Trace ID、会话 ID、模型版本等关键字段作为索引方便后续检索和关联。对于评估和标注如果预算允许可以考虑专门的标注平台。如果预算有限用简单的表格工具加上脚本也能跑起来关键是流程要规范。下面是一个典型的部署架构示意我用文字描述Agent 服务在运行时通过 SDK 采集追踪数据异步发送到采集网关采集网关做脱敏和格式化后分别写入追踪存储、指标系统和日志系统评估模块定期从存储中拉取数据运行自动评估并把结果写回Grafana 看板从各个数据源读取数据统一展示。4.2 埋点方案设计与代码实现埋点是可观测性体系的核心。埋点的质量直接决定了后续分析的深度。在 Agent 场景下我通常会在以下几个关键节点做埋点第一个节点是请求入口。记录用户输入、会话 ID、渠道、时间戳生成 Trace ID。第二个节点是意图识别。记录识别出的意图、置信度、候选意图列表。第三个节点是知识检索。记录检索 query、检索到的文档 ID 和分数、最终选用的文档。第四个节点是模型调用。记录模型名称、prompt 内容、输出内容、token 消耗、延迟。第五个节点是工具调用。记录工具名称、输入参数、输出结果、耗时、成功与否。第六个节点是输出返回。记录最终输出、是否经过过滤、过滤原因。下面是一个简化的 Python 埋点示例展示如何在 Agent 执行过程中记录关键节点import time import uuid from contextlib import contextmanager class TraceContext: def __init__(self, trace_idNone): self.trace_id trace_id or str(uuid.uuid4()) self.spans [] contextmanager def span(self, name, **attributes): span { trace_id: self.trace_id, span_id: str(uuid.uuid4()), name: name, start_time: time.time(), attributes: attributes } try: yield span finally: span[end_time] time.time() span[duration_ms] (span[end_time] - span[start_time]) * 1000 self.spans.append(span) self._report(span) def _report(self, span): # 异步上报到采集网关实际项目中应使用消息队列 print(f[TRACE] {span[name]} duration{span[duration_ms]:.2f}ms) # 使用示例 def handle_user_query(query, session_id): ctx TraceContext() with ctx.span(request_entry, queryquery, session_idsession_id): intent recognize_intent(query, ctx) docs retrieve_knowledge(query, intent, ctx) response generate_response(query, docs, ctx) return response def recognize_intent(query, ctx): with ctx.span(intent_recognition, queryquery): # 调用意图识别模型 intent refund_query return intent def retrieve_knowledge(query, intent, ctx): with ctx.span(knowledge_retrieval, queryquery, intentintent): docs [doc_1, doc_2] return docs def generate_response(query, docs, ctx): with ctx.span(model_generation, modelgpt-4, doc_countlen(docs)): response 这是生成的回答 return response这个示例展示了最基本的埋点模式。在实际项目中还需要考虑异步上报、批量发送、失败重试、采样控制等工程细节。4.3 关键指标的计算与可视化埋点数据采集上来之后需要计算成指标才能用于监控和分析。下面这张表列出了我常用的核心指标及其计算方式指标名称计算方式用途首次响应时间从请求入口到首个 token 输出的时间衡量用户体验端到端延迟从请求入口到完整输出返回的时间衡量系统性能Token 消耗速率单位时间内消耗的 token 总数成本监控工具调用成功率成功调用次数 / 总调用次数衡量工具稳定性知识库命中率检索到有效文档的请求数 / 总请求数衡量知识库覆盖度意图识别准确率正确识别意图数 / 总请求数衡量意图识别效果平均对话轮次总对话轮次 / 总会话数衡量问题解决效率用户满意度好评数 / 总评价数衡量整体效果这些指标在 Grafana 上可以做成多个看板。我通常会把看板分为三层实时监控看板展示当前的核心指标和告警状态趋势分析看板展示指标随时间的变化趋势下钻分析看板支持按维度拆解和查看明细。4.4 告警策略与异常检测告警是可观测性体系的价值出口。没有告警采集再多数据也只是躺在数据库里。但 AI 系统的告警策略和传统系统很不一样不能简单地设一个阈值就完事。我通常会把告警分为三类。第一类是硬性告警比如服务不可用、接口错误率超过阈值、token 消耗异常飙升这些可以用传统阈值告警。第二类是趋势告警比如问题解决率连续下降、平均对话轮次持续上升这些需要用趋势检测算法。第三类是语义告警比如出现了特定类型的负面反馈、检测到敏感内容输出这些需要结合语义分析。告警的收敛和降噪也很重要。AI 系统的波动性比传统系统大如果告警太敏感运维团队会被淹没。我通常会用告警分组、告警抑制、告警升级等策略来控制告警噪音。4.5 与现有运维体系的集成企业客户通常已经有成熟的运维体系AI 可观测性不能是一个孤岛需要和现有体系集成。集成的关键点有几个统一身份认证可观测性平台的登录和权限要接入企业现有的 SSO 体系。统一告警通道AI 相关的告警要能够发送到企业现有的告警平台比如钉钉、企业微信、PagerDuty 等。统一数据标准Trace ID、会话 ID 等关键标识要和企业现有标准对齐方便跨系统关联分析。统一看板入口如果企业有统一的运维门户AI 可观测性看板应该能够嵌入进去。这些集成工作看起来琐碎但直接影响可观测性体系的落地效果。我见过不少项目技术方案做得很好但因为没做好集成运维团队不愿意用最后沦为摆设。5. 常见问题与排查技巧实录5.1 数据采集不完整怎么办这是最常见的问题。表现是追踪链路断断续续有些请求有完整数据有些请求只有部分数据。排查思路通常是这样的先检查埋点覆盖度确认所有关键节点都有埋点。我遇到过一种情况开发同学只在主流程做了埋点异常分支和重试逻辑没有埋点导致出问题时反而没有数据。再检查上下文传递确认 Trace ID 在异步调用、线程切换、跨服务调用时没有丢失。Python 的 asyncio、Java 的线程池都是容易丢上下文的地方。最后检查上报链路确认采集 SDK 到采集网关的网络是通的没有因为超时或限流导致数据丢失。可以在 SDK 里加上本地缓冲和重试机制。5.2 追踪链路断裂怎么排查链路断裂和数据采集不完整不太一样。数据采集不完整是某些节点没数据链路断裂是节点之间有断点Trace ID 传不下去了。排查的时候我会先看断点出现在哪个环节。如果是跨服务调用断裂检查 HTTP header 或者消息队列的 message header 里有没有正确传递 Trace ID。如果是异步任务断裂检查任务提交时有没有把上下文序列化进去。如果是第三方服务断裂那就需要在调用第三方服务的边界做手动埋点把 Trace ID 记录下来。注意很多第三方 SDK 不会自动传递 Trace ID需要在集成时手动处理。这是我在多个项目里反复踩过的坑。5.3 指标异常波动的归因方法指标异常波动是运维团队最常面对的问题。比如问题解决率突然下降了 10%你需要快速找到原因。我的归因方法通常是逐层下钻。先按时间维度看是哪个时间段开始下降的。再按渠道维度看是所有渠道都下降还是特定渠道下降。再按问题类型看是哪类问题解决率下降了。再按模型版本看是不是最近发布了新版本。通过这样逐层下钻通常能在几分钟内定位到根因。如果逐层下钻还找不到原因那就需要看明细数据。抽取一些失败的对话人工分析链路看看是意图识别错了、知识检索没命中、还是模型生成有问题。5.4 高并发场景下的可观测性挑战Agent 项目在高并发场景下可观测性本身也会成为瓶颈。采集数据量太大存储扛不住埋点逻辑太重影响主流程性能看板查询太慢影响排查效率。应对策略有几个。采样是最直接的手段可以按比例采样也可以按重要性采样比如错误请求全量采集正常请求采样采集。异步化是必须的所有采集和上报动作都要异步不能阻塞主流程。分级存储也很重要热数据存近期数据支持快速查询冷数据存历史数据用低成本存储。我在一个高并发的智能体客服项目里采用了“错误全采、正常采样 10%、关键会话全采”的策略既保证了问题排查的数据需求又把存储成本控制在了可接受范围内。5.5 常见问题速查表问题现象可能原因排查方向解决建议追踪数据缺失埋点未覆盖异常分支检查异常处理逻辑补充异常分支埋点Trace ID 丢失异步调用未传递上下文检查线程池/协程上下文使用上下文管理器传递指标计算偏差采样导致数据不准确检查采样策略关键指标全量采集告警风暴阈值设置过敏感分析告警历史调整阈值告警收敛看板查询慢数据量过大未索引检查存储索引设计优化索引分级存储评估结果不准自动评估模型偏差对比人工标注校准评估模型5.6 几个容易忽略的实操心得第一个心得是埋点要趁早。不要等系统上线了再补埋点那时候代码已经复杂了补埋点的成本和风险都很高。最好在架构设计阶段就把可观测性作为一等公民考虑进去。第二个心得是数据质量比数据量重要。我见过一些项目采集了海量数据但字段缺失、格式混乱、时间戳不准根本没法用。宁可少采集一些也要保证采集的数据是准确、完整、一致的。第三个心得是可观测性要服务于业务。不要为了技术而技术采集什么数据、计算什么指标、设置什么告警都要从业务需求出发。业务不关心的指标采集了也是浪费。第四个心得是定期回顾和优化。可观测性体系不是建好就完事了需要定期回顾哪些指标没用上可以删掉哪些告警太频繁需要调整哪些看板没人看可以下线。保持体系的精简和有效。6. 不同 Agent 架构下的可观测性适配6.1 平台化智能体与自研智能体的差异企业客户经常问的一个问题是用 Coze 这类平台搭建的智能体和用 Python 自研的智能体可观测性方案有什么不同平台化智能体的优势是开箱即用平台通常自带基础的可观测性能力比如对话记录、调用统计、简单的效果分析。但劣势是深度不够你没法自定义埋点没法获取底层的模型调用细节没法做深度的链路追踪。自研智能体的优势是完全可控你可以在任何地方埋点可以采集任何你需要的数据可以按照自己的需求设计指标体系。但劣势是工作量大需要自己搭建整套可观测性基础设施。我的建议是如果业务对可观测性要求不高用平台自带的能力就够了。如果业务对可观测性有深度需求比如需要做精细化的效果分析、需要满足合规审计要求那就需要考虑自研或者混合方案。6.2 多智能体协作场景的追踪难点多智能体协作是现在很热的方向但它的可观测性难度比单智能体高一个量级。多个智能体之间互相调用、传递消息、协同完成任务追踪链路会变得非常复杂。核心难点在于上下文的传递和合并。Agent A 调用 Agent BAgent B 又调用 Agent C每个 Agent 都有自己的上下文。追踪系统需要能够把这些上下文串联起来同时又要保持每个 Agent 的独立性。我的做法是在多智能体协作的编排层做统一的 Trace 管理。编排层负责生成根 Trace ID并在调用各个 Agent 时传递下去。每个 Agent 内部可以有自己的子 Span但都要关联到根 Trace ID。这样既能看全局又能看局部。6.3 不同框架的埋点适配策略现在 Agent 框架很多LangChain、LlamaIndex、AutoGPT、还有各种自研框架。不同框架的埋点方式不一样需要做适配。对于 LangChain 这类有成熟回调机制的框架可以直接用它的 Callback 系统做埋点接入成本很低。对于没有回调机制的框架可能需要在关键函数上做装饰器或者 Monkey Patch。对于完全自研的框架最好在设计阶段就把埋点接口预留出来。我通常会封装一个统一的埋点 SDK对上提供简单的 API对下适配不同的框架。这样不管底层用什么框架上层的埋点代码都是一样的迁移成本很低。7. 可观测性数据的价值延伸7.1 从可观测性到持续优化可观测性数据的价值不只是“看”更重要的是“用”。采集上来的数据可以用于多个方面的优化。Prompt 优化是最直接的。通过分析模型输入输出数据可以发现哪些 prompt 效果好哪些效果差从而迭代优化 prompt 设计。知识库优化也很重要。通过分析知识检索的命中率和相关性可以发现知识库的覆盖盲区补充缺失的内容。工具优化同样关键。通过分析工具调用的成功率和耗时可以发现不稳定的工具进行修复或替换。流程优化是更高层次的。通过分析完整的对话链路可以发现流程设计的不合理之处比如冗余的步骤、不必要的模型调用等。7.2 数据驱动的 Agent 迭代闭环把上面这些优化点串起来就形成了一个数据驱动的迭代闭环采集数据 - 分析问题 - 提出假设 - 实施优化 - 验证效果 - 采集数据。这个闭环跑得越快Agent 的迭代速度就越快。我见过一些团队把这个闭环做到了周级别每周都能基于数据发现几个优化点快速迭代上线效果提升非常明显。关键是要把闭环的每个环节都工具化、自动化。数据采集自动化、问题分析半自动化、效果验证自动化。人工只需要做决策和审核不需要做重复的数据处理工作。7.3 可观测性作为企业 AI 治理的基础从更高的视角看可观测性是企业 AI 治理的基础设施。企业要管理好 AI 系统首先要知道 AI 系统在做什么。没有可观测性治理就无从谈起。AI 治理涉及多个方面合规治理需要追踪输出内容确保符合法规要求风险治理需要监控异常行为及时发现和处置风险成本治理需要追踪资源消耗控制 AI 使用成本效果治理需要评估业务价值确保投入产出比。这些治理需求全都建立在可观测性数据之上。所以我在给企业客户做方案的时候通常会把可观测性定位为“AI 治理的第一步”先把这个基础打好后续的治理工作才能顺利开展。8. 我在实际项目中的几点体会做 AI 可观测性这件事技术方案固然重要但更关键的是意识和流程。我见过太多团队技术能力很强工具也选得很好但因为没有形成“用数据说话”的习惯可观测性体系建好之后没人用最后荒废了。我的经验是可观测性体系上线之后一定要配套建立数据驱动的运营流程。比如每天开一次数据晨会看核心指标的变化每周做一次深度分析找优化机会每月做一次效果复盘评估整体进展。把这些流程固化下来可观测性才能真正发挥价值。另外可观测性不是越重越好。我刚开始做的时候总想把所有能采集的数据都采集了把所有能算的指标都算了结果系统很重维护成本很高实际用到的却很少。后来我学会了做减法只采集真正需要的只计算真正有用的保持体系的轻量和灵活。还有一个体会是可观测性要和业务深度绑定。纯技术的可观测性看板业务方看不懂也不关心。要把技术指标翻译成业务语言比如“首次响应时间”翻译成“用户等待时间”“工具调用成功率”翻译成“服务可靠性”。这样业务方才能理解可观测性的价值才会主动使用和反馈。最后分享一个小技巧在项目初期可以先从一个核心场景入手把可观测性做深做透形成样板。然后再逐步扩展到其他场景。这样既能快速见效又能积累经验避免一开始就铺得太大导致失控。