当传统可观测性完全失效时监控、评估和调试 LLM agents 的完整指南那是一个周二我们的一位客户提交了一张支持工单。处理订单查询的 AI agent 已经上线一个月了。指标看起来很干净 99.2% 的正常运行时间平均延迟低于 2 秒错误率接近于零。仪表盘本应告诉你的所有东西看起来都没问题。但这个 agent 已经连续十二天错误地分类退款资格了。它没有崩溃。没有报错。它以自信但错误的方式在规模化地回答付费客户。我们的 Datadog 在整个期间都毫无声响。这个 bug 存在于输出的_质量_中而不是系统中。这正是每个构建 AI agents 的团队都会掉进去的陷阱。 你像 2015 年那样监控服务器而你的 agent 却在幻觉、循环、错误路由 tool calls并悄悄退化。你是从客户那里发现问题的而不是从自己的系统里发现。本文将介绍真正需要观测什么如何在不烧光预算的情况下进行规模化评估以及在真实生产部署中有效的具体技术。相信我这是构建生产就绪 AI Agents 的一项关键技能。为什么你现有的监控完全没有抓住重点传统监控是为一种类型的系统设计的确定性的系统。点击一个按钮触发一个函数得到一个可预测的响应。你枚举失败模式为它们编写测试然后设置告警。AI agents 在两个维度上完全不同而这两个维度会彻底打破这种模型。无限输入空间。 一个客户退货。在传统应用中他们会点击一个固定流程。在 agent 中他们可能会说I want to return my orderCan you help me get my money back for the shoes I bought last week?order #12345 refund please同一个意图。完全不同的表达方式。你无法编写一个测试来覆盖人类表达“我想退款”的 10,000 种方式。你只能在生产环境中发现它们。非确定性。 LLMs 使用概率采样。同一个 prompt 在不同运行中会产生不同输出。一个通过了所有 staging 测试的 prompt会在你从未见过的边缘场景中失败。一个在评估中有效的 tool-calling 模式会在生产中遇到细微不同的查询时偶尔失误。这里的转变是停止监控系统。开始监控行为。1.2 秒内返回 200 OK 状态码并不能告诉你 agent 是否给出了正确、有帮助且安全的答案。你需要的信号在对话本身中而不在承载它的容器里。“传统软件会大声地崩坏。AI agents 会安静地、带着自信、规模化地失败。”Photo by author你真正需要捕获的四件事大多数团队只捕获一件事响应时间。下面才是真正重要的内容。1. 完整的 prompt-response 对不是“发生了一次请求”。而是用户发送的完整文本、system prompt、任何检索到的上下文以及完整的模型响应。质量信号就存在于这里。没有它你就是在阅读信封而里面的信本身是错的。2. Agent trajectory每一步而不只是最终答案Agents 会推理、调用工具、检索上下文、再次推理、调用更多工具、综合生成结果。每一步都是一个失败点。只监控最终输出能告诉你_有_事情出错了。trajectory 会告诉你_哪里_出错了。“它是否检索了错误的文档调用了错误的工具不必要地循环了如果没有 step-level visibility你无法回答这些问题。”3. 每个 session 的 token 和成本拆分一个陷入推理循环的 agent可能在超时前进行 50 次 LLM calls。按 GPT-4o 的定价这会让一个 session 从 $0.08 变成 $4。乘以数千名用户这些异常到月底就会变成预算危机。在 span 级别跟踪成本。知道具体是哪一步消耗了 80% 的 tokens。4. Tool call 行为Agent 调用了哪些工具使用了什么参数它是否不必要地调用同一个工具三次它是否静默失败并编造了结果Tool call 监控体现的是“agent 给出了一个糟糕答案”和“agent 给出了一个糟糕答案因为它用错误的 query 调用了 search API没有拿到结果然后没有升级处理而是产生了幻觉”之间的区别。这里的一切都取决于具体性。没有人愿意诚实谈论的评估问题这里有一个令人不适的事实。人工评审是判断输出质量的黄金标准。这个响应有帮助吗Agent 理解了意图吗信息准确吗人类能够正确回答这些问题。但在每天 1,000 个请求的规模下完整人工评审需要 10 到 20 小时的专注时间。每天如此。这无法扩展。句号。两种方法可以弥合这一差距Photo by author方法 1Annotation Queues用于真正重要的 Traces与其让评审人员在原始生产日志中大海捞针不如用 annotation queue 按预定义 rubric 将特定 traces 提供给他们评审。只路由真正重要的内容收到负面用户反馈的 sessions高成本离群值潜在推理循环来自最重要客户层级的 queries被自动化检查标记的任何内容评审人员处理的是一个聚焦的队列而不是日志海洋。他们的 annotations 会成为你构建下一个 evaluator 的训练数据。这是一个很小的输入但会随着时间复利增长。诚实的提醒annotation queues 需要专门的评审时间。它们不是免费的。但如果聚焦在正确的 traces 上它们对于捕捉自动化系统遗漏的细微失败是不可替代的。方法 2LLMs as Evaluators用于规模化LLM-as-judge 是让持续评估成为可能的技术。你可以配置在生产流量上运行的自动化 evaluators评估那些不需要 ground truth answer 的质量维度。自动化 evaluators 能够可靠评估的内容语气和连贯性响应是否结构良好并符合语域安全性和 policy compliance是否存在违规或敏感内容格式校验输出是否遵循要求的结构主题分类用户实际上想做什么幻觉检测Agent 是否与其自身检索到的上下文相矛盾每天 1,000 个请求自动化 evaluators 可以覆盖所有请求。人工评审则覆盖最重要的 50 个由 evaluators 暴露出的信号来引导。“自动化 evaluators 告诉你该看哪里。人工评审告诉你这意味着什么。”三个诚实的限制Evaluators 会增加 1 到 3 秒延迟。请异步运行它们或在采样流量上运行。开箱即用的 evaluators 衡量的是通用质量。你需要与自身领域对齐的自定义 evaluators并且在信任它们之前需要用人工标签进行验证。对大多数团队而言采样 10% 到 20% 的流量是成本与覆盖率之间的最佳平衡点。真正能改进 Agents 的开发循环Photo by author捕获 traces 不是目标。利用它们进行改进才是目标。下面是会产生复利的循环Production trace → reveals failure or edge case ↓ Annotation queue → human reviews and labels it ↓ Dataset → example joins your evaluation set ↓ Playground → reproduce the failure, test a fix ↓ Experiment → A/B test old behavior vs new ↓ Online evals → validate fix in production ↓ Next production trace → cycle continues大多数团队会从第一步直接跳到第六步。他们靠直觉修复而不是靠证据。他们部署时希望修复有效两周后又发现一个新的边缘场景然后这个循环重复发生却没有任何复利式改进。“发布由证据支撑的修复而不是由希望支撑的修复。这是 agent 质量随时间复利提升的唯一方式。”每一步都会供给下一步。生产失败变成评估数据。评估数据验证修复。修复提升基线。每次迭代都会让这个循环更快、更可靠。实践30 分钟内实现生产可观测性下面是最小可行栈。我会使用 LangSmith 作为示例因为它是采用最广泛的工具但这些概念同样适用于 Langfuse、AgentOps 或任何结构化 tracing 平台。Step 1: Instrument Your Agent (2 Minutes)import os # Set these three environment variables and LangChain tracing is automatic. # Every agent run, tool call, and LLM call is captured from this point forward. os.environ[LANGCHAIN_TRACING_V2] true os.environ[LANGCHAIN_API_KEY] os.getenv(LANGSMITH_API_KEY) os.environ[LANGCHAIN_PROJECT] production-support-agent # If you are NOT using LangChain, wrap your functions with traceable instead: from langsmith import traceable traceable( nameclassify_support_ticket, run_typechain # classifies the span type in the dashboard ) def classify_ticket(ticket_text: str) - dict: # Everything inside is now captured: inputs, outputs, latency, exceptions. # Without traceable, this function runs but nothing is recorded. result llm_client.chat.completions.create( modelgpt-4o, messages[{role: user, content: fClassify: {ticket_text}}] ) return {category: result.choices[0].message.content}traceable 是关键 decorator。没有它你的函数会运行但保持不可见。有了它每次调用都会在你的 dashboard 中创建一个带有 timing、inputs 和 outputs 的已标记 span。Step 2: Add Metadata to Every Trace (5 Minutes)没有上下文的原始 traces 毫无用处。Metadata 让它们可以被查询。traceable( namehandle_customer_query, run_typechain, tags[production, support-v2], metadata{ customer_tier: enterprise, # filter by tier in dashboard channel: email, # filter by channel agent_version: 2.4.1 # compare versions over time } ) def handle_query(customer_id: str, query: str) - str: return response没有 metadata你只能在成千上万条无法区分的 traces 中翻找。有了它你就能回答“给我展示 enterprise customers 在 version 2.3.0 与 2.4.1 上的所有 failed traces。”这个 query 在 dashboard 中只需要 10 秒而不是花一个周末调查。Step 3: Set Up an Automated Evaluator (20 Minutes)from langsmith.evaluation import evaluate, LangChainStringEvaluator # cot_qa: chain-of-thought QA evaluator. # It checks if the agents answer is grounded in the retrieved context. # Use a different model than your agent to avoid self-evaluation bias. correctness_evaluator LangChainStringEvaluator( cot_qa, cnotallow{llm: your_evaluation_llm} ) results evaluate( lambda inputs: run_agent(inputs[question]), dataproduction-failures-golden-set, # your curated test dataset evaluators[correctness_evaluator], experiment_prefixhotfix-v2.4.2 # tag for side-by-side comparison )experiment_prefix tag 至关重要。每次 evaluation run 都会被标记这样你就可以在完全相同的 traces 上比较“修复前”和“修复后”并准确看到哪些 cases 改进了哪些回退了哪些保持不变。Step 4: Configure Online Evaluation on Production Traffic在你的 LangSmith dashboard 中Online Evaluations → New Rule配置{ name: production_quality_monitor, sampled_fraction: 0.15, evaluators: [ hallucination_check, policy_compliance, tool_selection_accuracy ], alert_threshold: { hallucination_check: 0.05, policy_compliance: 0.01 } }15% 的采样足以检测系统性问题同时不会让你的推理成本翻倍。告警会在质量退化时触发而不是等用户投诉后才触发。这就是 reactive 和 proactive 之间的运维差异。真正告诉你它是否有效的指标标准的 uptime 和 error rate 告诉你系统是否还活着。下面这层指标告诉你它是否真的在_工作_。Metric 它告诉你的内容 Task completion rate Agent 是否真正解决了用户的问题Tool selection accuracy 它是否为每种情况选择了正确工具Trajectory efficiency 每个任务有多少步骤并且是否一致Retrieval hit rate 它检索到的内容中有多少被实际使用Cost per successful completion 不是每个 session 的成本而是每个_有效_ session 的成本最后一个值得更仔细地看一看。一个每个 session 成本 $0.05、失败率 40% 的 agent每次成功成本为 $0.083。一个每个 session 成本 $0.10、成功率 95% 的 agent每次成功成本为 $0.105。在汇总 dashboard 中它们看起来很相似直到你真正查看这些数字。而且那个 40% 的失败率每天都在侵蚀用户信任只是你还没有检测到。“跟踪每次成功完成的成本而不是每个 session 的成本。它们讲述的是完全不同的故事。”为什么通用工具无法填补这个空白你可能会问我能用 Datadog 做这些吗对于基础设施指标可以。对于真正重要的东西不行。这些差距是结构性的。差距 1自然语言 payloads。 传统 APM 存储结构化日志和数值指标。你需要对对话进行 semantic search而不是对结构化数据做关键字匹配。找到“所有 agent 误解 return 与 exchange 意图的 sessions”不是一个 SQL query。差距 2开发反馈循环。 传统监控给你展示一个 dashboard。Agent observability 需要把生产失败转移到 evaluation datasets 中用这些 examples 测试修复比较版本然后在生产中验证。这完全是另一种产品。差距 3跨职能用户。 传统 APM 是为 SREs 构建的。Agent observability 被 AI engineers 用来调试 prompts被 product managers 用来分析使用模式被 domain experts 用来评审准确性被 data scientists 用来构建 evaluations。界面需要适用于所有这些人而不仅仅是会读 stack traces 的人。当这些差距存在时你最终会看到 engineers 在 Datadog 里product managers 在 Google Sheet 里而双方都没有关于 agent 实际行为的完整上下文。2025 年这个领域的真实状态进展是真实存在的。LangSmith、Langfuse、AgentOps、Arize、Maxim 和 Braintrust 都在用专门的平台解决这些问题。OpenTelemetry 正在发布 GenAI semantic conventions以标准化跨 frameworks 的 telemetry这对于避免 vendor lock-in 很重要。但挑战仍然存在我想对此坦诚。基于 LLM 的 evaluators 在定义良好的标准上与人工判断大约有 80% 到 90% 的一致性。这足以用于趋势检测。但对于单个高风险决策还不够可靠。你仍然需要人类处理最重要的边缘场景。全面监控很昂贵。 在规模化场景下评估所有生产流量会增加真实的推理成本。10% 到 20% 的采样范围是现实中的最佳平衡点但你并没有看到所有内容。隐私确实很难。 捕获完整的 prompt-response pairs 意味着捕获用户发送的一切个人信息、敏感业务数据、潜在受监管内容。Retention policies 和 redaction pipelines 需要成为架构决策而不是事后补丁。没有完美方案。 目标是在可接受的成本和风险下获得最有用的信号。随着你了解系统真正需要什么你会不断调整这种平衡。现在该从哪里开始本周 添加基础 tracing。根据你的 stack 选择一个工具LangChain 用 LangSmithopen-source 用 Langfuse需要广泛 framework coverage 用 AgentOps并给关键函数添加 traceable。捕获完整的 prompt-response pairs 和 trajectories。半天工作立即获得可见性。接下来的两周 构建 golden dataset。浏览生产 traces找到 25 到 30 个有代表性的 cases包括已知 edge cases并用预期行为对它们打标签。这就是你的 regression test suite 和 evaluation baseline。下个月 设置 15% 的 online evaluation sampling。将 tool selection accuracy 和 task completion rate 与基础设施指标一起跟踪。把告警接入你的 incident management system。之后 运行完整的开发循环。每个生产失败都会变成一个 test case每个修复在部署前都会针对该 test case 进行验证每次部署都是一次可以比较的测量。改变一切的那句话你可以构建一个技术上有能力的 AI agent。大多数团队都可以。更难的是围绕它构建一个系统让你在用户发现之前就知道它什么时候停止工作。传统软件会大声地崩坏。AI agents 会安静地、带着自信、规模化地失败。Observability 不是你监控 AI agent 的方式。它是你证明它正在工作的方式。每一条 trace 都是证据。每一次 evaluation 都是测量。每一个 annotation 都是变得更好的承诺。构建一个同时捕获这三者的层你就会从希望 agent 正常工作转变为真正知道它在正常工作。“Agent 不是产品。Agent 加上 observability layer 才是产品。”二者缺一都是一个等待变成支持工单的 demo。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。