1. 先搞清楚Multi-Agent系统的可观测性到底难在哪做个假设你现在负责一个由五六个Agent协作完成复杂业务任务的系统它们有的负责拆解用户意图有的负责检索知识库有的负责调外部API有的负责汇总结果。某天下午系统对用户的普通提问突然返回了一个莫名其妙的答案代码层面没有任何报错日志里全是正常级别的信息模型也没有超时或触发限流。你打开监控大盘所有指标看起来都正常但结果就是不对。这种状况我经历过不止一次坦白说它比服务宕机还让人抓狂——因为宕机至少有一个明确的排查起点。先说结论Multi-Agent系统的可观测性难题本质上是分布式的复杂性问题和大模型的不确定性问题叠加在了一起。传统监控工具不是没用而是远远不够用。1.1 分布式系统的老问题在Agent场景里被放大了凡是做过微服务的人都知道排查一个跨服务调用的问题需要trace ID贯穿整条调用链。Multi-Agent系统本质上也是一个分布式系统多个Agent各自运行彼此通过消息通信共享某些状态或工具。但相比微服务它有几个特别麻烦的地方。第一调用关系是动态的。微服务之间的调用路径是代码写死的A调BB调C链路固定。而Agent系统里Agent A可能根据上下文决定是直接调用Agent B还是先自己处理一部分再让Agent B接手甚至可能同时协调Agent B和C并行工作。调用关系本身是模型想出来的不是代码预先定义的。所以日志里常见的服务名接口名维度在Agent场景下根本没法提前打标。第二状态是共享且分散的。多个Agent经常会读写同一个共享状态比如一个业务上下文或者一个工具的执行结果缓存。微服务虽然也有共享存储但状态变更逻辑是确定的。Agent系统里每个Agent都可能根据自己对上下文的理解去修改状态改完还不一定记录为什么改。这就像几个人同时在一张白纸上写字谁写了自己的部分白纸最后长什么样很难追溯。第三失败是软性的。微服务超时、报错至少有个明确的失败信号。Agent系统里最常见的失败是模型没崩但理解错了它执行了正确的流程却跑在错误的前提上。这种失败没有任何异常堆栈只有结果偏离预期而偏离预期这个判断本身又需要结合业务语义不是简单的状态码能表达的。1.2 Agent系统的黑盒部分恰恰是最需要被观测的这也是我最想强调的一点。在传统系统里链路追踪覆盖的是代码执行路径每一条分支都是开发者写出来的可观测性要解决的是搞清楚走了哪条分支、为什么走这条分支。但在Agent系统里很大一部分决策逻辑不在代码里而在模型的权重里。模型为什么决定先调用工具A再调用工具B为什么突然换了策略为什么某个Agent放弃了当前任务转去处理别的这些决策过程只有模型自己知道。所以Multi-Agent系统的可观测性观测对象不再仅仅是系统的行为还包括模型的思考过程。这不是说要把模型输出的所有token都记录下来——Token级别的内容绝大多数都没有长期存储价值。真正需要记录的是模型接收到了怎样的上下文做出了怎样的决策调用了什么工具、传入了什么参数工具返回了什么结果模型基于这个结果又如何调整下一步计划。这一层层嵌套的信息才构成了一个Agent的思维轨迹。我还想纠正一个常见的误区就是把Agent的所有输入输出都打日志就是可观测性。如果只是机械地记录排障时你还是得面对几百条毫无关联的日志靠肉眼去拼凑发生了什么。可观测性的核心价值是还原因果不是为了存数据而存数据。所以设计这套体系的时候脑子里要时刻想着一个问题如果明天线上出了诡异问题我需要哪些信息才能推演出完整的因果链1.3 传统监控工具链的适配性和缺口这么说吧Metrics指标、Logging日志、Tracing链路追踪这套经典的可观测性三支柱在Multi-Agent系统里都是必要的但单独拿出来又都不够。Metrics能告诉你系统整体健康度QPS、延迟、Token消耗、错误率。但它回答不了为什么它只能告诉你出问题了。而且Agent系统的很多问题不会体现在这些常规指标上——比如某个Agent在逻辑上绕了远路多调了十几个工具但整体延迟依然在阈值内表面上看一切正常实际效率已经严重退化。Logging是排障的基础但Agent系统的日志有两个天然短板。一是日志量大每个Agent的每次思考、每个工具调用、每轮消息如果全量记录存储和查询成本都很高。二是日志之间的关联性差如果没有统一的链路ID贯穿几条日志谁先谁后都说不清楚。Tracing是最接近需求的手段分布式追踪的模型——trace、span、event——天然适合描述Agent的多层嵌套调用。但问题在于开源的Tracing方案大多是为RPC调用设计的span的语义是一次远程调用而Agent的一次推理和一次工具调用之间不是简单的父子调用关系更像是一个循环里的多次决策步骤。直接套用现成模型你会发现在页面上看到的是乱七八糟的span树很难还原出Agent真正的思考过程。所以我的看法是构建Multi-Agent系统的可观测性不能指望某一个现成工具全搞定而是需要一套从数据模型到采集方案都经过重新设计的体系把传统手段作为基础设施在它上面叠加Agent特有的观测维度。下一节就聊聊我是怎么拆解这个问题的。2. 分层可观测从消息链路到思维过程一个都不能少在传统分布式系统的可观测性设计里我们习惯按基础设施、应用、业务三层去做。但Agent系统的观测对象多了一个模型决策层而且这层往往还是最关键的。我实践下来比较有效的做法是把它拆成四个层面每个层面解决一类问题四个层面拼在一起才能还原完整的因果链。2.1 消息层Agent之间通信的确定性追踪最底层的是消息层。无论Agent之间是通过消息队列、事件总线还是直接函数调用每一次通信都需要有一个全局唯一的message ID并且在日志里天然带上发送方、接收方、消息类型、时间戳。这一层解决的问题是谁在什么时候给谁发了什么内容。这里我踩过一个比较深的坑。早期我们把消息内容直接序列化成JSON打进日志结果线上一个Agent每轮对话要和另一个Agent交换十几次信息一次完整任务下来光消息日志就有上百条每条还都很大。排障的时候想找某个业务会话中Agent C第一次接到的是什么消息光靠日志检索就得折腾半天。后来改成消息落库时拆成meta和payloadmeta单独建立索引payload按需存储。链路追踪只需要metapayload在需要回溯具体内容时才去查询。这样既保证了可观测性又控制了存储成本。另外消息层的观测必须带上语义摘要。一条消息原文可能几千个token但在链路追踪里我们只需要看它的摘要比如Agent A向Agent B传递了用户关于订单状态的查询意图附带订单号ORD-20241001。这个摘要可以由发送方Agent在发送时通过一次LLM调用生成也可以由规则提取关键字生成。实际操作中规则提取效果往往不稳定但胜在便宜LLM摘要质量高但会增加成本和延迟。我的建议是核心链路用LLM摘要边缘消息用规则截取。不要试图对所有消息都做高质量摘要成本会失控。2.2 状态层每个Agent的内部快照和上下文变化Agent系统的bug很大比例出在状态管理上。某个Agent维护了一段内部上下文在处理过程中逐步更新但某个分支下它忘记更新了或者更新错了后续它所有的决策都会基于一个过期的上下文展开这种问题只有在状态层才能被发现。状态层要记录的是每个Agent在某一个时刻持有哪些关键状态。这里说的状态不是模型参数而是Agent运行时的业务状态比如当前任务列表、已完成步骤、引用文档列表、临时变量、对外部工具的缓存结果等。记录方式应该是一个个状态快照在Agent每次状态发生变更时打一个快照并关联到当前的trace ID和message ID。比较反直觉的是快照不一定要全量存储。很多状态对象很大全量存储不现实。我用的方案是正常运行时每N步打一个全量快照其他变更只记diff。这样排障时先用diff把变更路径找出来定位到某一步之后再去看那一步的全量快照。这有点像Git的commit机制storage开销可控而且能够支持回到某个时间点查看现场。状态层还有一个容易遗漏的观测维度Agent之间的共享状态。如果多个Agent都在读写同一个上下文比如一个共享的工作记忆区那这个共享状态本身也需要被观测记录每次读写的Agent、时间和变更内容。这个以后在调试案例里会提到多Agent互相覆盖状态几乎是最难排查的问题之一。2.3 过程层模型每一步推理的可视化呈现如果说状态层解决的是Agent看到了什么过程层解决的就是Agent基于这些信息做了什么决策。这层在技术上没有统一标准我的做法是在Agent的推理循环reasoning loop里注入观测回调把每个循环步骤的数据都导出。具体记录的数据包括模型输入即当前Prompt的内容、模型输出的决策选了哪个工具、传了什么参数、还是决定直接返回、工具的执行结果、以及模型的下一步计划。每一条记录都关联到当前trace ID并且在trace的UI里按时间轴展开。这样你就能看到类似这样的过程Agent A读了用户提问判断需要查订单系统调用get_order工具工具返回了一个订单状态Agent A根据这个结果决定要不要让Agent B介入……整个过程一目了然。在这个过程中有一件只可意会的事如何记录模型的想法。目前大部分Agent框架在调用LLM时会返回reasoning_content之类的字段不同模型叫法不同这就是模型的推理过程。这个内容非常有价值但体量也大。我的建议是开发环境全量保存生产环境保存一份摘要和关键阶段的完整推理其他阶段只保存结论。如果生产环境出了问题先用摘要判断哪个阶段可疑再回到开发环境或采样环境去复现完整推理这个思路比全量记录所有推理要实际得多。2.4 可观测数据模型围绕Agent场景重新设计trace和span的语义最后聊数据模型。现在很多团队直接用OpenTelemetry的trace模型去套Agent系统结果发现不对劲。问题在于OpenTelemetry的span假设是一个树状调用结构而Agent的行为更像是一个带循环和条件跳转的流程图甚至是一个多Agent协作的有向图。我最终采用的模型是对OpenTelemetry做了一层扩展概念传统语义微服务Agent场景拓展Trace一次用户请求的完整调用链一次Agent任务从发起目标到全部完成的完整执行轨迹Span一次RPC调用或方法执行一次Agent决策周期、一次工具调用、一次子任务委派Event日志事件异常、信息Agent的关键状态变化、人工干预、重试原因Attribute请求元数据URL、状态码Agent角色、模型名称、Token消耗、上下文长度、温度参数等Link跨Trace关联Agent之间的消息引用、共享状态变更关联不要小看这个语义映射它决定了后面所有观测数据怎么组织和查询。比如你接入了一个现成的Tracing UI按span的类型去过滤时你能轻松筛选出所有调用过工具get_order的Agent决策或者所有把任务委派给Agent C的决策这些筛选能力是排障的基础。如果只是把Agent的每一步都埋成一个普通的span不做类型区分那UI上的数据就是一锅粥。数据模型定了监控和告警才有的放矢。下一节说说指标体系和告警策略这决定了你能不能在中段就发现问题而不是等用户反馈。3. 监控指标体系哪些指标真正值得盯告警怎么设才不吵很多人一开始搭Agent系统监控第一反应是看模型的调用量、延迟和费用。这些当然要看但只看这些你会错过大问题。我在生产环境跑了一段时间之后总结了一套更贴合Agent特性的指标维度按重要程度排了个序。3.1 基础健康指标不可缺失的地基所有AI系统都该看的指标这里快速过一遍请求量QPS按Agent类型和工具类型拆分看清每个Agent的负载。延迟分布不要只看平均值重点看P50、P95、P99。Agent系统的延迟分布经常是长尾的P99可能比P50高出好几倍这种长尾往往是Agent在个别场景下进入低效循环的信号。Token消耗按模型、按Agent、按会话拆分。Token用量异常上升通常意味着某个Agent的Prompt在不断膨胀或者陷入了自我循环。错误率和重试率包括模型调用失败、工具调用失败、Agent内部异常。注意Agent系统里重试不一定由框架拉起模型经常自己决定刚才工具没成功我再试一次这种重试同样要监控。这一层是整个监控体系的地基任何一层的观测数据都可以关联到这些指标。光有这些不够下面这些才是Agent系统特有的。3.2 Agent系统特有的指标没有这些你等于没监控第一组指标我管它们叫决策质量指标。包括单任务平均决策步数一个完整任务里Agent总共做了多少次决策、单决策平均工具调用数、上下文重写频率Agent被中断或任务切换时上下文被重新构建的次数。这些指标直接反映Agent的效率。案例某次我们发现订单查询类任务的平均决策步数从5涨到了11排查后发现是因为某个Agent在Prompt模板里多加了一段历史对话的拼接逻辑导致模型每次都要先花几步理解那段历史才进入真正的查询流程。第二组指标是循环与停滞指标。这是Agent系统最容易出问题、也最不容易被传统监控捕捉的地方。包括单个Agent连续执行步骤数超过阈值比如超过10步没产出外部可见结果、同一个工具被连续调用N次且返回结果都一样、Agent把任务在多方之间来回传递超过K次。这些指标本质上是在做行为模式识别传统Metrics很难直接表达需要写一些自定义 exporter从消息层的日志数据里实时统计。实现上不复杂Kafka Streams或Flink都能做关键是阈值需要根据业务调参没有一劳永逸的默认值。第三组指标是上下文与状态健康度指标。包括上下文窗口占用率当前会话的Prompt Token数占模型最大上下文的比例、共享状态冲突次数两个Agent在同一窗口期改写了同一份状态、状态过期读取次数Agent读取的某些缓存数据已经超过时效。这几项要结合业务逻辑来定义但它们往往是Agent系统行为怪异的根本原因。3.3 告警策略阈值告警会把你淹没行为告警才救命刚开始做告警的时候我们按常规套路给每个指标都设了固定阈值然后就被告警淹没了。原因是Agent系统天然有高方差同一个任务因为用户表达方式不同决策步数可以从3跳到15同一个Agent下午高峰期的延迟可能是凌晨的5倍。固定阈值要么太松问题曝光时已经晚了要么太紧每天成百上千条告警根本看不过来。后来我们调整了策略核心就一句话别只盯绝对值要看变化趋势和分布偏移。具体做法是对决策步数、工具调用数这类指标用最近7天同时段的数据做基线告警条件设为当前值超过基线P95的1.5倍而不是决策步数10。对Agent之间消息传递次数设一个硬上限告警超过就触发这个属于无论业务怎么变都不该出现的强异常。延迟、Token消耗这类指标同时监控P95而不是平均值。平均值被少数慢请求拉高时你可能已经在损失用户体验了P95更敏感。告警消息必须带上trace ID和会话ID写着决策步数异常tracexxxxx当前15步基线P95是6步。没有上下文的告警就是噪音运维同学收到告警还得自己去找日志来回一折腾处置效率就下来了。3.4 监控大盘怎么设计一张图能讲到什么程度最后是关于面板设计的一些经验。给团队看的核心大盘不要搞太多图我建议控制在6-8个核心面板每个面板都能回答一个核心问题当前在线Agent数量和任务吞吐量——一眼看清系统整体是否健康。各类Agent的平均决策步数和工具调用数趋势——效率退化能第一时间体现。Token消耗按模型和Agent拆分——成本与异常信号。工具调用成功率热力图——哪个工具开始不稳定。Agent之间消息传递网络图——看清楚协作拓扑是否正常有没有消息风暴。共享状态冲突的Top列表——谁在频繁改同一块状态。另外一定要有一个全部trace检索的入口这是排障专用的不等于监控大盘但要在面板上放一个直达链接。排障时最讨厌的就是从一个指标页跳到另一个指标页跳来跳去就忘了最初那条线索。一张可检索的trace总览页比10张花里胡哨的大盘更有用。4. 调试实战从表现异常到揪出真凶的完整链路监控体系搭好之后真正考验它的是排障场景。这一节我用三个实际踩过的案例把完整的排查链路走一遍。这几个案例基本涵盖了Multi-Agent系统里最高频的几类疑难杂症。4.1 案例一Agent陷入了自我对话式死循环现象某个Agent在处理用户咨询时系统整体延迟飙升但CPU和内存都不高模型调用量却异常大。排查过程第一步打开监控大盘看趋势。决策步数指标当场暴露了问题某个会话的决策步数在10分钟内飙升到200多步而正常情况应该不超过8步。点进对应的trace看到一条超长的span链条。第二步在trace里按时间轴回放该Agent的过程层日志。发现在第6步之后Agent A开始重复调用Agent B得到一份回复然后把这份回复原样抛给Agent BAgent B又原样回复两者都不认为任务已经完成但也没有推进任何实质进展。消息内容摘要显示两个Agent仿佛在互相说根据你的回复我认为还需要进一步处理然后对方又回复同样的内容。第三步查状态层快照。发现两个Agent的共享工作记忆里有一份用户问题澄清的状态在反复被写入但写入的内容完全一样。也就是说Agent A认为没有澄清清楚反复触发澄清流程Agent B每次响应后又把状态恢复原样形成循环。根因Agent的停止条件设计不严谨。在框架代码里Agent的循环终止条件是模型主动决定结束但模型在某个上下文下倾向于不结束——因为它判断还有未澄清的信息。修复方案分两步一是给循环加硬性上限超过N步强制终止并返回当前结果这在生产环境必须存在属于最后一道保险二是修正Prompt中对澄清的判断标准明确只有在某个具体字段缺失时才需要澄清而现状是共享状态里那个字段永远不可能被写满等于给了模型一个永远不会满足的终止条件。4.2 案例二工具调用的参数错乱模型自己说服了自己现象用户查询订单状态系统返回了一个状态完全不符的结果。模型没报错工具也执行成功工具返回值在日志里也正常但最终给用户的答案是错的。排查过程第一步先从tracing里找到这次会话的trace定位到调用order查询工具的那条span。展开工具调用的输入参数发现模型传给工具的订单号是ORD-20241003但用户实际问的是ORD-20241005。这个错位不是网络问题是模型自己传错了参数。第二步往前追溯看模型是基于什么信息做出了这个传参决策。过程层日志显示模型在处理用户问题时先从会话历史里提取了订单号但历史里包含了两个订单号模型提取时抓取了第一个而没有验证它与用户当前提到的订单是否一致。第三步查看共享状态。发现另一个Agent在处理同一会话时把共享上下文里的当前订单号覆盖成了ORD-20241003。也就是说模型读到的压根不是用户最新提到的那个订单号而是另一个Agent留下的残留状态。根因这个问题的本质不是模型传参能力不行而是多个Agent操作同一个上下文时缺少字段级所有权的约束。Agent A有权限写当前订单号这个字段但它不知道这个字段已经被Agent B定义成了另一个语义。修复措施一是在共享状态层引入字段归属机制每个字段只允许特定Agent写入其他Agent只能读二是在Agent的Prompt里强化使用上下文中的数据前先确认数据来源模型在收到指令后会倾向于重新确认。这不能根除但能大幅降低发生概率。4.3 案例三Agent之间互相覆盖状态最终结果张冠李戴现象有两个Agent一个负责收集用户信息Collector一个负责填写业务订单Filler。某个会话中用户先是查了一笔旧订单然后在同一会话里又发起一个新的下单请求结果Filler把查旧订单的信息填进了新订单里。排查过程第一步从trace的共享状态事件里搜索冲突记录。很快看到Collector和Filler在同一个5秒窗口内先后写入了订单备注字段Collector写的是用户对旧订单的询问Filler写的是新订单的备注由于没有锁或版本控制后写的数据覆盖了先写的。第二步查看两个Agent各自的状态快照。Collector认为自己存储的用户近期订单数据是最新的它也会把这个数据作为会话上下文传给Filler。Filler读取共享状态时拿到了刚被覆盖的数据把新单和旧单信息搅在了一起。第三步看消息层的通信日志发现这两个Agent从来没有就直接沟通它们是并行执行的完全通过共享状态交互。问题就出在先读后写没有原子性保障。根因在Agent系统的架构设计里很多时候我们为了让Agent解耦让它们都通过共享状态交互。但共享状态没有做并发控制时并行Agent就会互相踩脚。修复措施比较复杂我当时的做法是给共享状态的每个写操作增加一个基于版本号的乐观锁Agent在写之前必须先读版本号写入时如果版本号不匹配就重试同时在业务层面做了一次调整——新下单和查旧单这两个动作从并行改为串行用一条简单的流程编排规则控制。共享状态并发控制之后这类互相覆盖的问题基本绝迹。4.4 断点调试与回放机制让Agent的意识流变成可回放的录像最后说一个效率提升最明显的工具时间旅行调试也就是回放机制。Agent系统的调试困境在于你很难让它在生产环境按你的节奏走一步停一步。但如果你把过程层的每一步记录完整——模型输入、输出、工具入参、工具出参、状态变更——你就可以在事后把任意一次执行完整回放出来。回放时你可以做到在当前这一步暂停查看这之前的全部上下文和Agent的决策依据甚至可以修改某一步的工具返回结果看看Agent会不会走另一条路。这就是所谓的时间旅行调试。实现上这套能力比想象中简单。只要过程层日志里记录了每次工具调用前后Agent内部的上下文、模型输入和输出就能在本地开发环境用相同的Prompt序列重新跑一遍模型。注意要记录的是Prompt的实际内容而不是Prompt模板ID因为模板渲染之后的内容才是模型真正看到的东西。很多团队用Playground式的界面来做回放线上trace一键导入本地断点跑效率提升非常明显。5. 工具链选型与落地经验开源方案和自研方案怎么选聊完监控和排障再说说工具链。这两年Agent可观测性的开源工具冒出来很多每个都号称自己支持Agent场景但实际用起来差距不小。我按使用场景把它们粗分成了三类给出我的选型建议。5.1 开源方案横向对比LangFuse、LangSmith、Phoenix等先看市面上主流的几个方案都是可以直接拿来用的工具定位优点局限LangFuseLLM可观测性与trace支持跟踪LLM调用、Prompt版本、反馈打分成本低Agent协作的复杂链路可视化相对弱对自定义事件支持一般LangSmithLLM应用调试与评估和LangChain深度整合回放对比能力强支持数据集评估不开源SaaS服务数据要出域很多团队过不了安全审计Arize PhoenixLLM trace与评估开源可自托管支持OpenTelemetry协议社区活跃生态较新部分功能不够成熟OpenTelemetry 自研扩展一切可观测性的地基标准统一、不被厂商锁定前后端通用只提供数据采集标准Agent语义映射要自己设计我对这几款的真实感受是如果团队刚起步、需要快速看到效果LangFuse是最低门槛的选择装个Docker就能跑基本的LLM调用追踪都可以覆盖。如果对数据安全要求高必须走自托管路线那Phoenix值得花精力研究因为它支持OpenTelemetry标准后续迁移的沉没成本低。LangSmith我一般推荐在开发调试阶段用生产环境因为数据合规问题很少长期依赖。但不管选哪个工具都要有心理准备Agent系统的可观测性不可能100%靠现成工具解决。原因前面也说过Agent特有的多层嵌套、动态拓扑、共享状态冲突现成工具很难全部覆盖。工具解决的是采集和展示的问题数据模型的Agent语义化设计必须自己动手。所以我们最终的架构是采集层用OpenTelemetry全家桶中间加一层自己的Agent事件模型展示层接了LangFuse和Grafana排障时两个界面配合用。5.2 自研轻量方案什么时候该自己动手自研不一定是坏事也不一定很重。如果你的场景只是内部工具Agent数量不多业务逻辑相对固定那完全可以用结构化日志 事件总线的轻量方案省去一堆重依赖。做法是这样的Agent框架里定义好统一的日志结构每次决策、每次工具调用、每次消息收发都输出一行JSON格式的结构化日志字段包括trace_id、agent_id、step_index、type、summary、payload_ref。所有日志发到Kafka或直接写对象存储查询按trace_id聚合。展示层可以做得极简——一个网页输入trace_id按时间轴展开每一行日志即可。这种方案的好处是一是完全没有厂商锁定所有数据都在自己手里二是模型简单团队成员理解成本低三是配合日志检索系统比如ELK或Loki可以直接做关键字搜索排障效率很高。缺点是缺少开箱即用的可视化能力需要自己写一点前端而且高级的回放、评估功能要自己造轮子。我个人的经验标准是当你的Agent系统每天任务量超过10万次或者有多个Agent长期并行协作且需要精细排障时自研的精力和成本已经超过引入成熟工具了。反之如果你还在POC阶段或日任务量很小先自研轻量方案跑通业务再逐步引入开源工具不要一上来就上一套大而全的监控平台。5.3 数据量与采样策略全量采集是个陷阱这是个非常容易踩的坑。一开始我们都想全量采集最保险结果半个月后存储成本直接爆炸。以一个中等规模系统为例每天10万次任务每次任务平均10个决策步每个决策步需要记录模型输入输出摘要、工具参数、状态快照一天的数据量在几十GB到上百GB之间索引之后成本还要翻几倍。我的建议是分层采样策略全量采集轻量信息每个trace的meta信息trace_id、时间、Agent类型、最终状态、决策步数、Token用量这些量小全量保存。按比例采集详细过程状态快照、工具入参出参、模型输出的详细日志按5%~10%比例采样。为了保证覆盖度可以按会话ID哈希做一致性采样——同一个会话的所有步骤要么全采要么全不采这样采样不会破坏单个会话的完整性。按需全采异常样本任何指标触发告警的trace或最终状态为失败的trace必须全量保留详细过程。这些是最有价值的排障素材不能省。在线数据 离线归档热数据保留7天用于日常排障7天以后压缩归档到廉价存储保留30~90天用于趋势分析。这套策略落地后我们每天的存储量降到全量方案的20%左右而且排障时几乎没有遇到过找不到数据的情况。核心诀窍就一条节省成本要省在不太可能出问题的正常样本上绝不能省在异常样本上。5.4 团队落地时容易被忽视的环节最后说两个团队协作层面的经验。一是Agent开发同学的本地开发环境也接上这套可观测性体系。很多团队只做了生产环境的埋点本地跑Agent时完全没有trace导致本地复现不了、线上拍瞎猜的恶性循环。正确做法是本地开发时把trace导出到一个共享的Dev环境开发同学可以互相查看对方的Agent执行轨迹。Agent的bug经常依赖具体数据和Prompt上下文本地自己跑一遍往往复现不了能在线查看同事的trace协作效率会好很多。二是排障流程的文档化。我强烈建议把排过的疑难问题整理成一个内部Wiki按现象、trace链接、根因、修复方式、如何防范的结构记录。Agent系统里同一类问题会反复出现因为模型版本一升级、Prompt一改之前修过的问题可能又冒出来。有一个历史问题库每次排障都可以先检索一遍很多问题其实是有成熟方案的不用每次都从零开始。6. 刻意为之的边界设计避免可观测性本身成为系统的性能陷阱最后这部分聊一个很多人搭完监控后才发现的问题可观测性本身也是有成本的不加约束的打点会让系统变慢、变贵甚至影响原本要观测的行为。6.1 打点对Agent决策性能的实际影响Agent系统的执行链路比传统后端应用长得多。一次任务可能涉及多次LLM调用、多次工具调用每次都要检查是否需要记录、记录什么内容、写到哪里。如果这些操作是同步的Agent每走一步都要等日志写完才能继续P95延迟会肉眼可见地变差。我最早遇到过一次加完详细日志后Agent单次任务耗时增加了将近40%。一开始还以为是模型变慢了查了半天最后发现是同步日志写入阻塞了推理循环。从那之后我们定了一条铁律Agent推理关键路径上可观测性数据采集绝不能同步阻塞。日志一律异步上报宁可丢几条日志也不能让打点拖慢主流程。具体做法是Agent内部只做内存缓冲区写入缓冲区满了或者到时间窗口就批量上报上报走单独的线程池或直接发到消息队列不影响主线程。因为可观测性数据的实时性要求通常不高秒级或毫秒级延迟完全可以接受。6.2 打点会改变Agent行为还真会这个现象不是我们团队先碰到的但确实很值得警惕。大模型对Prompt非常敏感如果你把一大段本次决策内容摘要当前状态快照等观测数据拼进下一轮的Prompt里模型可能会因为上下文内容的变化而做出完全不同的决策。特别是有的Agent框架在注入观测数据时会把Debug信息挂在系统提示词里不经意间改变了模型的注意力分布。所以我的建议是观测数据的采集、清洗、存储都必须与模型输入严格分离。采集是在模型调用之外的旁路操作绝不允许为了方便调试就把调试信息拼进模型输入。如果确实需要在Prompt里加一些辅助信息也要设计成显式的、稳定的格式并且变量名、描述都要谨慎设置不要简单地印上JSON dump的结果。6.3 可观测性数据的生命周期管理最后说下数据的清理和归档。Agent系统的trace数据非常专一——只有新出问题的trace才有高频访问价值时间一长绝大多数trace都不会再被访问。所以我建议在数据生命周期管理上采取主动策略热数据7天内全量保留支持秒级查询。温数据7~45天按事件摘要保留支持trace_id检索但明细需要延迟加载。冷数据45~90天只保留统计聚合值和异常样本详情正常样本的明细删除或归档到冷存储。不要舍不得删。保留一堆永远不会被查的明细数据消耗的是存储成本和查询性能。我见过有团队把一年的全量Agent trace全存着查询一个trace要十秒以上监控面板一卡就是半分钟这种体验下没人愿意用体系自然就荒废了。可观测性是一个活系统不是一次性搭完就结束的它需要定期维护、调整采样率、清理数据才能长期发挥价值。从架构设计到工具选型再到排障实战和成本控制整个可观测性体系的建设我最大的体会是它不是一个单纯的技术问题而是需要围绕如何更快定位Agent系统的异常这个核心目标持续调整和迭代的工程实践。不要把自己困在某一套工具或某个框架里真正值钱的是你对自己系统的理解有多深以及你把这种理解转化成监控和排查手段的能力。