线上Agent突然开始“抽风”——在完全没有改动代码的情况下同一个问题昨天还正常今天它却连续调用了四次错误工具最后甩给用户一段看似礼貌、实则答非所问的回复。翻了半天日志只看到一堆结构化的JSON记录了“调用了什么模型、消耗了多少Token”但关于“为什么这次它决定走这条路”“中间那步检索到底返回了什么”完全一片空白。我相信任何把Agent推到过生产环境的人都经历过这种从头到脚的无力感。这就是AI Agent可观测性要解决的核心矛盾多步推理过程的“黑盒化”。当模型不再是单次“输入-输出”而是需要自己规划步骤、选择工具、消化中间结果、再决定下一步时真正需要观测的东西已经从“模型返回的文本”变成了“一条完整推理链上的每一个节点与每一次转向”。这篇文章不是理论科普。我会结合自己落地Agent观测体系的实战经历拆清楚四件事黑盒到底“黑”在哪里、可观测矩阵的四个维度怎么搭、LangChain/LlamaIndex这类框架里最实用的埋点姿势是什么、以及拿到观测数据之后如何真正反哺Agent效果。面向的读者是那些已经不再满足于“调API、看返回”的Agent开发者——你发现调试越来越吃力、评估全靠肉眼、线上问题无法复现这篇文章就是写给你的。1. 黑盒到底“黑”在哪里被隐藏的四类关键信息很多人有个误区觉得“Agent不就是多个LLM调用串起来吗那我记录一下每次调用的输入输出不就行了”。真这么干过的人都知道这个想法天真在哪——Agent的问题从来不在单次调用的质量而在多次调用之间的状态流转。1.1 单步日志无法回答的“为什么”我见过太多团队的第一版观测方案就是把每次LLM调用包括Prompt和Response打进日志再配个简单的Web界面按时间戳查看。这套方案在单轮ChatBot时代是够用的但放到Agent场景下你面对的核心疑问根本不是“模型这次回复了什么”而是这次Agent为什么选择了调用A工具而不是B工具它在第2步得到的检索结果对第3步的决策产生了多大影响那一次“看似多余”的重复调用到底是Agent的自主判断还是上下文里某个脏数据诱导的整条链路最终失败的时候从哪一步开始偏离了预期轨道这些问题单条日志给不了答案。因为每条日志都是孤立的快照而Agent的运行本质是一条动态决策链。快照只能告诉你“某时刻系统处于什么状态”链路才能告诉你“这个状态是怎么一步步演变过来的”。1.2 被常规监控体系完全遗漏的决策链信息我梳理过自己在调试Agent时真正缺的信息最后归纳为四类常规监控体系几乎完全不覆盖第一类完整推理轨迹Trace。从用户Query进入系统开始到最终答案返回中间经历了哪些步骤每一步之间的父子关系是什么哪一步耗时异常哪一步是整条链路上最先出现偏差的“元凶”这类信息需要的是Call Tree式的结构化追踪而不是平铺的时间戳日志。第二类决策依据与中间输出Intermediate States。LLM在每一步“想”了什么比如ReAct模式里的Thought内容、Action Input、Observation结果这些中间产物经常比最终答案更有分析价值。很多时候Agent走偏不是从最后一步才偏的而是中间某一次Thought被误导了。不记录这些你根本不知道偏在哪。第三类状态与上下文变化Context / State。Agent是有状态的Memory里积累了哪些信息、上下文窗口里塞了什么历史、Tool返回的结果被如何处理后放进了上下文……这些状态变化是很多诡异问题的根源。举个例子一次Agent“失忆”很可能就是因为某个工具返回了超长文本把前面几轮的关键信息挤出了上下文窗口——这类问题只有跟踪状态变化才能发现。第四类性能与成本分布Cost Performance。一次完整的Agent任务可能包含10次模型调用和多次工具调用总延迟和总成本是每一步的累积。常规监控只告诉你“这次请求用了3秒、花了0.5美元”但不告诉你哪一步贡献了2.5秒、哪一步烧掉了80%的Token。1.3 “不确定性叠加”让黑盒问题几何级放大为什么Agent的黑盒问题比传统应用严重得多因为传统应用是确定性系统输入相同代码路径就相同日志也几乎相同。而Agent的底层是概率模型同样的输入每一次运行的路径都可能不同。这意味着一个残酷的现实生产环境里复现不了的问题往往就是因为那次运行的路径已经无法再复现了。你今天怀疑“是不是检索环节出了问题”但那个Agent已经不再按昨天的链路运行了。没有完整的链路记录排查工作就变成了一场毫无线索的盲猜。我在之前的项目里统计过上线观测体系之前排查Agent问题的平均耗时大概是5到8小时超过一半的时间花在“推测中间步骤到底发生了什么”上。所以做Agent可观测性的本质不是“多打几条日志”而是把一条不可复现的随机决策链变成一个可以完整回放的确定性记录。2. 可观测矩阵怎么搭面向多步推理的四个维度和五层埋点明确了缺失的信息类型下一步就是设计观测体系。我搭建的方案参考了传统可观测性的“三支柱”模型Log、Trace、Metric但针对Agent场景做了调整和扩展。2.1 四个采集维度Trace、Log、Metric、State我的采集矩阵最终落在四个维度每个维度解决一类特定问题维度核心对象解决什么问题典型载体Trace链路一次完整请求的步骤调用树链路从哪里开始、在哪里变慢、在哪里失败、各步骤依赖关系Span / Trace树Log事件单次关键节点的事件详情每步的输入输出、Thought内容、工具返回、错误堆栈结构化日志Metric指标聚合后的数值统计成功率、平均耗时、Token消耗、工具调用频次、成本分布时序指标State状态上下文与内存的变更历史状态如何累积、何时被改写、何时溢出上下文窗口快照 / 状态Diff四者之间不是孤立的。我通常用Trace作为骨架把Log和State挂载到具体的Span上Metric则通过聚合Span的数据得出。这样四类信息就形成了一个有机整体从指标上发现问题从Trace上定位链路从Log/Span里看细节从State上理解状态演变。2.2 五个埋点层级从外到内逐步逼近推理过程光有维度还不够还得明确在系统的哪些位置埋点。我按照从外到内的顺序把Agent系统分成五个埋点层级。这比直接去改Agent框架内部的代码要稳妥得多也更容易在现有系统上渐进落地。应用接入层在API入口和出口埋点记录完整请求、用户信息、最终响应。这一层最容易被忽略但它提供了一个关键参照系——后面所有内部步骤都要归一到这个总请求上。Agent编排层这是最核心的埋点层。Agent的每一次思考Thought、每一步行动Action、每一个观察Observation都要记录。这一层能够完整还原模型的决策链。不同框架的钩子位置不同但基本都提供了回调机制LangChain中有CallbackHandlerLlamaIndex中有CallbackManager。在这一层埋点的产出是整条推理链路的主干。LLM调用层记录每次模型请求的完整Prompt、Response、Token消耗、延迟。注意这里记录的是“进入模型请求体的真实内容”而不是“开发者以为的内容”——因为Agent框架会自动拼接历史对话、注入System Prompt、填充工具定义开发者写的原始Prompt跟模型实际看到的可能完全不同。工具执行层记录每个工具调用的入参、出参、耗时、错误信息。工具调用是Agent“接触真实世界”的窗口也是脏数据和异常输入的主要入口。我见过太多所谓“模型判断错误”最后查下来其实是工具返回了格式损坏的JSON导致解析失败后模型做出了错误反应。基础设施层CPU、内存、网络延迟等系统指标。这一层在Agent场景下通常是次要的但涉及外部API调用时比如访问第三方知识库网络问题会被Agent理解为“工具返回错误”并在推理链上产生连锁反应。所以基础设施指标也值得保留但不需要单独建系统——用现成的Prometheus即可关键在于把Trace关联起来。2.3 采集策略什么该全量、什么该采样Agent场景的观测数据量非常可观。一次复杂任务可能产生几百个Span包含的Token数据动辄几万。对于这种量级的数据必须明确采集策略。我的经验是分三类处理必采全量的数据所有“决策关键点”的信息。包括每个Thought的文本、每次工具调用的输入输出、每次模型请求的输入输出。这类数据直接关系到你能不能“回放”推理过程一旦缺失整条链路就不完整了回放价值大打折扣。可以采样的数据系统类指标、非关键节点的性能数据、低频错误的堆栈等。例如如果Agent在正常运行时每轮会做3次RRF重排序这类操作不需要每次都记录完整细节。必须脱敏再存的数据用户隐私信息、内部系统凭据、敏感的检索文档内容。这里不仅是合规问题更是成本问题——原始Prompt/Response存得越多后续治理的成本越高。我在落地方案里统一通过一个脱敏层处理后再入库。还需要额外说一点写入观测系统本身不能成为Agent链路上的性能瓶颈。我见过有人直接把观测数据通过同步调用写入数据库结果Agent延迟直接翻倍。正确做法是应用端先把观测事件写进本地队列由后台Worker异步批量写入或者直接通过OpenTelemetry的Exporter异步导出。3. 从回调钩子到统一事件模型一套可直接落地的埋点实践理论架构说完了接下来是大家最关心的代码层面到底怎么埋。我不打算完整贴一个框架的源码而是把思路和最小可用代码写出来你在自己的项目里照着改装就行。3.1 实操起点常规模块的插桩位置先看最基础的做法。在LangChain这类框架里最快的起步方式是继承对应的回调处理类。以一个最小化的实现为例from langchain_core.callbacks import BaseCallbackHandler from langchain_core.agents import AgentAction, AgentFinish class ObservabilityCallbackHandler(BaseCallbackHandler): def on_agent_action(self, action: AgentAction, **kwargs): # 记录Agent的每一步决策动作 emit_event(agent.action, { tool: action.tool, tool_input: action.tool_input, thought: action.log, # 这个log里通常包含Thought内容 trace_id: get_current_trace_id(), step_index: kwargs.get(step), timestamp: now(), }) def on_agent_finish(self, finish: AgentFinish, **kwargs): emit_event(agent.finish, { output: finish.return_values.get(output), trace_id: get_current_trace_id(), }) def on_llm_start(self, serialized, prompts, **kwargs): emit_event(llm.start, { prompts: prompts, trace_id: get_current_trace_id(), }) def on_llm_end(self, response, **kwargs): llm_output response.llm_output or {} emit_event(llm.end, { generations: [g.text for g in response.generations[0]], token_usage: llm_output.get(token_usage), trace_id: get_current_trace_id(), }) def on_tool_start(self, serialized, input_str, **kwargs): emit_event(tool.start, { tool_name: serialized.get(name), input: input_str, trace_id: get_current_trace_id(), }) def on_tool_end(self, output, **kwargs): emit_event(tool.end, { output: str(output), trace_id: get_current_trace_id(), })这个回调类里面没有一行是复杂的但它已经覆盖了Agent场景最常见的四类事件模型调用、决策动作、工具执行、链路结束。把这类回调注入LangChain的AgentExecutor之后所有关键节点的信息就都能拿到了。如果用的是自研Agent框架比如拿LangGraph做复杂编排、甚至在纯代码里手写ReAct循环思路也是一样的——在“调用模型之前”“拿到模型结果之后”“调用工具之前”“拿到工具结果之后”这四个固定位置埋上事件即可关键是不要漏掉“拿到模型结果之后”和“调用工具之前”之间的决策逻辑。3.2 标准化数据模型让Trace可聚合、可回放事件采集出来后如果每条事件的结构各写各的后续根本没法做统一分析和比图。为了保证数据的可消费性我定义了一套精简事件模型所有事件统一走这个结构。{ schema_version: 1.0, event_id: evt_01J2XYZ..., trace_id: trace_a1b2c3..., parent_span_id: span_xyz..., span_id: span_abc..., event_type: llm.end, timestamp: 2026-03-21T12:34:56.789Z, duration_ms: 431.2, agent_session_id: as_001, attributes: { model_name: gpt-4o, token_usage: {prompt: 1234, completion: 567}, content: ... }, tags: [prod, customer-service, paywall] }这里有几个字段我要特别解释一下因为它们在实际排障中价值极高但很多人会忽略agent_session_id区别于trace_id的会话级标识一个用户的一次完整交互可能产生多条链路比如多轮对话中每轮推理各有一条tracesession_id方便你把多轮链路串起来看整体行为。event_type统一枚举值比如llm.start、llm.end、tool.start、tool.end、agent.action、agent.finish、memory.update、error。枚举值统一之后后续做分析查询就非常方便。tags这次不是可选的。把环境prod/test、业务线支付/客服、Agent版本号打进tag里是事后做回归分析的基础条件。没有tag你根本无法区分“这次版本升级到底有没有改善问题”。3.3 传输直接基于OpenTelemetry但GenAI语义约定做好取舍传输层我的选择是直接走OpenTelemetryOTel。原因很实际它自带上下文传播机制traceparent headter那样在异步任务里传trace_id不传断链、有各种语言的SDK、生态里已有持续演进的生成式AI语义约定。目前的OTel GenAI语义约定SemConv覆盖了LLM调用、向量搜索等场景的基础属性比如gen_ai.request.model、gen_ai.usage.input_tokens这些。但说实话Agent编排层的语义约定还没有完全稳定很多字段还在演进中。所以我的实践策略是LLM调用层和基础设施层尽可能遵循OTel标准语义约定未来升级组件时替换成本最低。Agent编排层仅借用OTel的Span和事件机制自定义Agent专属属性名比如agent.thought、agent.tool_chain并且保证这些属性在事件模型里都有明确归属。用OTel的Span来表示一次Agent的完整链路时结构大致是这样一个根Span对应整次请求或者整轮对话子Span分别对应Agent规划步骤、单次LLM调用、单个工具执行。如果Agent内部还有嵌套的子Agent就再加一层子Span。这样生产出来的Trace树能非常直观看出“哪个子Agent的内部决策拖慢了整个任务”。有人可能会问为什么不用LangSmith、Langfuse这类现成的Agent观测平台非要自己搭Langfuse这类平台我实际用过它的强项在于“开箱即用”——特别是深度集成LangChain的那套装好SDK填个API Key就能看到Trace的UI。但它的短板也很明显数据存在对方的SaaS环境里自定义事件类型和检索维度受平台约束。对于处在探索期、数据规模还不大的团队直接用这类平台是完全正确的选择能省下整整一个后端团队的工作量但如果你需要在私有化环境部署、需要把观测数据跟自己的业务数据打通做深度分析自建更合适。我自己是从Langfuse起手的后面业务量大了才逐步迁移到自建Pipeline起步阶段完全没必要一上来就造轮子。3.4 离线回放把不可复现的Bug变成“可暂停的录像”整套埋点体系上线之后我获得的最宝贵能力不是实时的Dashboard而是离线回放Replay。回放的实现思路不复杂把上一步采集到的、按时间序排列的事件流存储下来再做一个简单的可视化前端支持按trace_id加载一条完整链路、按时间轴逐步播放。播放时能看到每个步骤的模型输出、工具返回、决策依据甚至能看到某个中间步骤改写Memory的完整前后对比。回放解决的是Agent开发里最痛苦的那个问题“这个Bug当前复现不了”。有了一次运行的完整记录所有讨论都基于同一份“录像”展开不再靠印象和推测。我在团队里推行了一个机制线上出现任何Agent的异常行为第一件事就是把这个trace_id的回放链接发到群里——这比截图一百行JSON日志有效得多。4. 沿着一次“智能客服排障Agent”的真实链路走一遍走查理论、架构、代码都聊了不少下面用一个我实际做过的场景把整套体系串起来看效果。这个场景是一个智能客服排障Agent它接入了知识库检索和系统指标查询工具负责回答用户关于线上服务的问题。4.1 场景设计一次看似普通却暗藏危机的请求假设用户提问“我的服务最近经常出现503帮我看看是什么原因”这条请求的完整处理逻辑设计如下Agent先对用户输入做意图识别判断这属于“故障排查”类请求。调用知识库检索工具获取与“503错误”相关的历史故障文档。调用系统指标查询工具获取该服务最近1小时的错误率、延迟等指标。结合检索结果和指标数据通过LLM生成排查结论。返回给用户并给出后续建议。这条请求看似简单但在真实运行中任何一个环节错位都可能让最终答案从“专业排障结论”歪成“一本正经的胡说八道”。4.2 通过Trace回放定位一次“完美失败”的排障过程在一次线上走查中这个Agent给出了一个让我和团队所有人都愣住的答复——它一本正经地向用户解释“503错误通常是运营商网络问题导致的建议您检查本地网络。”这个结论当然是错的但更诡异的是它语气非常自信完全看不出“犹豫”或“知道自己在瞎猜”。如果只看最终输出你很容易归结为“模型幻觉”甚至怀疑是主模型能力不行然后陷入不断换模型的低效循环里。但通过Trace回放根因在30秒内就暴露了。下面表格展示的是这次请求的Traces树精简版Span顺序节点类型关键内容摘要耗时1Agent.Start意图识别→分诊判定0.4s2Tool.Call知识库检索query“503错误 排查”top_k31.2s3Tool.Result返回3条结果其中第1条标题含“网络”“网关”—4LLM.Call结合检索结果生成排查计划2.8s5Tool.Call系统指标查询service“order-svc”, range1h1.5s6Tool.Result返回数据status200, 错误率为0%, P99120ms—7LLM.Call生成最终答复3.2s看到第6行的数据。查询结果明显显示这项服务当前的错误率是0%根本没有503但Agent在第7步生成答复时却仍然顺着“知识库检索到的内容”在编结论完全没有参考第6步的指标数据。问题的根源就清楚了Agent在第4步的计划里已经把“这条检索结果”当成了事实依据后续步骤只是沿着这个预期“找补”理由。它甚至可能都没真正“读取”第6步返回的数据因为指标数据是零相关性的而检索结果强烈相关但标题误导两者冲突时模型选择了“符合直觉”的信息——这是多步推理里非常经典的“锚定效应”。这种问题不看Trace几乎无解。因为单看日志每一步的调用都是“正常”的检索有返回、指标有数据、模型有输出可最终的答案就是错的。只有把中间状态串起来看才发现问题的源头在第3步的检索结果与第4步的规划决策之间。这就是Trace对比单条日志的绝对优势。4.3 从案例反推观测体系真正该捕获的关键信号这次的故障排查过程让我给整套观测体系补了两个之前完全没设计的关键信号第一个信号是“检索结果置信度”。不是看检索工具返回了什么而是看这些结果跟用户问题的相关性打分。在第3步如果置信度信号被记录就能在回放时立刻发现Agent当时其实拿到了一个低置信度但标题高度相关的文档而模型把“看起来相关”当成了“实质可信”。这种置信度信息现在被我的检索调用事件完整记录用于后续的分析和告警。第二个信号是“上下文冲突检测”。当第5步的指标查询结果明确显示无异常与第4步生成的规划基于误导性检索结果已经预判有网络问题产生冲突时观测系统没有对这个冲突做任何标记。如果能在冲突发生时打上一个“上下文冲突”标签甚至直接触发告警这类幻觉问题就能在发生当下被发现而不是等用户投诉了才回头看日志。现在我的实现是在事件模型里加了一个conflict_flag字段由后续分析任务做冲突检测时填充。这个案例还引出一个更重要的观察Agent链路里最大的风险不在单点能力而在决策之间的信息一致性。观测体系要抓的不只是“某一步出错了”更包括“这一步没有用上应该用上的信息”。5. 评估闭环与常见坑观测数据怎么反哺Agent效果观测体系的价值终点不是“能看见了”而是“看见之后能改善”。很多团队搭建观测体系时很兴奋可一旦数据真正流动起来就发现不知道怎么用这些数据来反哺模型效果。这一节专门讲评估闭环的构建和我在实践里踩过的坑。5.1 从观测数据里生成回归评估集传统评估Agent效果的方式是用固定评估集离线跑一遍看准确率。这种方式的问题在于评估集是人为构造的覆盖不到线上的真实分布。线上Agent遇到的用户提问、工具反馈、上下文组合千奇百怪固定评估集“考”的内容和真实“战场”可能高度不匹配。我在实践中采用的方式是从观测系统里持续挖掘真实的失败样本纳入回归评估集。操作路径是给观测系统里所有Agent执行结果打上质量标签通过用户反馈、后续行为追踪、人工抽检等方式。定期从带“失败”“质量差”标签的链路中提取输入、附带上下文和当时的中间状态。把成功样本与失败样本混合构造成准线上评估集。每次调整Agent的Prompt、工具、模型或编排逻辑都在这个评估集上回归一遍。这套机制跑起来之后最显著的变化是每次改动后我们不再靠“感觉变好了”来做判断而是能明确说出成功率从多少变成多少哪些类型的失败被修复了哪些类型的失败是本次改动新引入的。关键的是需要把Agent的中间运行时状态比如某步的检索结果作为运行时数据一并保存这样当Prompt升级后还能用“相同输入、相同上下文”条件做对比这是传统LLM评估集不具备的能力。5.2 我踩过的六个可观测性相关坑以下坑我全部真实踩过逐个列出来省得你再走一遍。坑一异步任务里trace_id丢失。Agent里大量并发调用并行工具执行、异步检索、后台任务如果做context propagation时漏了向异步子任务传递trace_id就会出现“链路在中途断开”的情况跑到一半的Span变成了孤儿节点后续没法跟主干关联。解决方式是坚决用规范的context管理而不是手写参数传来传去——Python里用contextvarsJava里用ThreadLocal 显式传递每个异步入口都要做trace_id的注入。坑二上下文窗口截断导致状态失真。Agent的Memory是有限的。当历史消息或中间结果超出窗口时框架或开发者会做“截断”或“摘要”——但很多观测方案完全不记录这个环节导致回放时看到的行为跟真实推理时损失完全对不上。我在观测里专门记录每次LLM调用前的实际消息列表长度、窗口截断动作、被丢弃或摘要化的信息摘要。没有这些你在回放时会以为模型“忘记”了某些事是Bug实际上只是因为上下文被截断了这是设计的限制而非异常。坑三Prompt模板变化导致的历史对比失效。观测系统上线后很快会有人调整Prompt模板比如加了一段few-shot示例。如果不在事件属性里打上“Prompt版本号”就会出现一个经典惨案对比两组Trace时发现效果差异巨大研究了大半天最后发现只是内部Prompt模板版本不同所致。从第一天起就把Prompt版本号作为必需属性记录。坑四工具超时与重试机制掩盖真实延迟。工具的自动重试机制会让某次工具调用的实际耗时远大于感知上的“一次调用耗时”。如果你观测的是Agent框架层面的tool.start和tool.end中间的自动重试会被吞掉延迟分析完全失真。解决方式是在工具执行层额外记录“实际网络请求数”和“累计重试次数”而不是只记录一次wrapper的起止。坑五把观测系统变成同步依赖。之前提过这里再强调一次。如果做Agent的可观测性用的是同步方式写入那么观测系统一旦卡顿整个Agent的延迟就被卡住。有一次我们的Agent忽然集体变慢排查到最后发现是观测平台的写入队列堵了。后来我强制规定观测事件必须通过异步批量导出且应用侧不能依赖观测系统的写入成功或失败。坑六解决“无标签样本”始终是评估闭环的核心瓶颈。技术问题解决了组织协同问题马上就来了观测数据量很大但没有足够的“人工标注”来分辨哪些是真正好的、哪些是真正坏的。粗标签比如“用户点了还是”噪声大细标签人工评分成本高。我用的折中方案是“分层采样”对明显失败的链路——比如运行时报错、工具返回异常——全量留存对“结果正确但可能不是最优路径”的样本——表现正常但步骤效率低——做低比例采样对明显的成功案例——用户明确确认解决也做低比例采样。既控制标注成本又保证回归集里对失败样本有足够覆盖。5.3 从“能观测”到“可治理”从小处起步的建议最后给出起步建议。每次我分享这套体系总会有人问“这也太多了从哪里开始”。我的建议非常明确第一步先解决“完整链路记录”。哪怕不建Dashboard、不做评估集、不定义事件模型标准先保证每一次运行的Trace能被完整保存下来。排查问题时能回放就解决了一大半效率问题。第二步给关键节点打上标签。从trace_id开始把session_id、Agent版本号、环境、业务线这些tag先打上。有了这个基础后面做任何统计和归因都有依据。第三步再解决自动评估和告警。当链路记录稳定运行一段时间之后积累了足够多的“正常样本”你就可以开始设定基线给异常行为设置告警规则——比如某类工具连续失败、某条链路出现了冲突标记、某类问题反复出现置信度突变。这一步做得越晚前期的自定义需求就越少越容易在现有系统上持续建设。我在实际项目中见过不少团队第一步还没夯实就冲去搞自动评估结果评估跑了两周发现Trace数据根本不足以下结论又回头补埋点。顺序对了这套体系才能真正长在一个团队里而不是变成一个用完就扔的平台项目。回到最开始那个“Agent突然抽风”的场景。这几年Agent技术变化很快模型能力越来越强框架也越来越成熟但有一件事没有变你永远需要知道它为什么这么做。可观测性就是那面镜子——如果说单次LLM调用是为Agent提供“大脑”那么完整链路记录就是为开发团队提供“复盘回放”它不会替你做决策但能让你在每一处决定性环节面前看清全貌。
算法详解：原理、距离度量与工程实践)
