生产环境里的 AI Agent，不能只看日志：真正该盯的是对话

一句话总结：Agent 上线后最重要的不是“它崩没崩”，而是“它到底怎么想的、怎么回话的”。

---

内容概览

• 主题：AI Agent、生产监控、对话评估、LangSmith、LLM Evals
• 适合人群：做 AI 产品、搭 Agent、管线上系统、关心评测和可观测性的工程师与创业者

---

核心观点

1. 传统软件监控，管的是代码路径；Agent 监控，盯的是对话过程 普通应用的用户行为基本可预测，出错后看 stack trace 和日志就够了。Agent 不一样，输入是自然语言，问题空间几乎无限，不能只靠 uptime 和 error rate 判断好坏。

2. 生产环境里，单靠人工审查根本不够 开发时你可以一条条看，但到了生产环境，交互量可能是成千上万甚至上百万，必须把人工审查做得更高效，同时让模型自动帮你筛一遍。

3. 最实用的监控方式，是“人 + LLM”一起上 让人做复杂判断、让 LLM 做规模化自动评估，再把结果接到报表、仪表盘和告警里，才能从一条对话追到真正的失败模式。

---

深度解读

Agent 上线后，最先失灵的不是代码，而是你的“确定性幻觉”

传统软件最讨人喜欢的一点，是它有边界。

按钮就那么几个，表单就那么几项，流程基本都被产品经理和工程师提前画在图上。用户点进来，大概率会走你预设好的路径。哪怕系统出了问题，你也还能顺着日志、错误栈、接口响应，比较清楚地定位它到底卡在哪。

Agent 不是这个玩法。

它接收到的是自然语言。自然语言的麻烦就在于，它看起来像“随便说说”，实际上却是无限分叉的输入空间。同一句话，换个措辞、加个条件、改个顺序，模型可能就会给你完全不同的回答。更别说 Agent 还会做多步推理、调用工具、拉上下文、自己决定下一步怎么走。

这意味着什么？

意味着你没法再把它当成一个“固定函数”。

对传统软件来说，你监控的是“有没有跑起来”；
对 Agent 来说，你得监控“它是怎么一路走过来的”。

这差别非常大。前者像看发动机转不转，后者像看司机在高速上到底走了哪条路、为什么临时变道、有没有差点开进沟里。

如果你只盯着系统是否在线、接口是否响应、延迟是否正常，那你会很快得到一种危险的错觉：一切都挺好。可用户可能已经在对话里被它绕晕了、误导了、激怒了，甚至让它做了不该做的事。

Agent 的问题，往往不是“它死了”，而是“它活着，但活得不对”。

---

APM 很强，但它看不见 Agent 最关键的那层东西

传统软件有一套成熟的监控体系，叫 APM。Latency、error rate、throughput，这些指标非常有用。它们能告诉你服务快不快、稳不稳、扛不扛得住流量。

但 Agent 的核心质量，不在这些指标里。

真正重要的，是这几个问题：

• 用户原话是什么？
• 这个对话经历了几轮？
• Agent 在每一轮做了什么判断？
• 它调用了哪些工具？
• 它为什么得出了这个结果？
• 最后这个交互到底算不算“成功”？

这些信息，不在传统监控面板里。它们藏在对话轨迹里。

这就是为什么这类系统的监控重点，不能只放在代码层。你要看的不是“服务有没有挂”，而是“这一段对话有没有走偏”。

比如同样是“帮我订一张下周去旧金山的机票”，一个 Agent 可能老老实实查航班、确认日期、给出选项；另一个可能误解时区、把回程当去程、甚至调用错工具。对于 APM 来说，这些交互都可能只是一次成功的请求。可对用户来说，体验完全不是一回事。

Agent 评估还会碰到一个更棘手的问题：很多好坏是需要人判断的。

输出有没有帮助？语气是否自然？是否越权？是否遗漏关键约束？是否在危险场景下表现得足够谨慎？

这些都不是单靠几个固定指标就能完全判断的。你需要看上下文，需要理解意图，需要结合业务规则。换句话说，Agent 监控不是纯技术问题，它很大一部分是判断题。

---

生产环境的数据量一上来，人工审查立刻变成瓶颈

开发阶段还好。你可以自己看 trace，一条一条过，像做代码 review 一样审对话。

但一旦进入生产环境，局面就变了。

可能是几千条交互，也可能是几百万条。你根本不可能靠人手把每一条都看完。就算能看完，也看不过来。等你把问题找出来，用户可能已经跑了，线上已经被你“教育”过一轮了。

所以核心问题不是“要不要人工审查”，而是：

怎么把人类判断用在最值钱的地方？

这篇视频里提到的思路很直接，也很实用：两条路一起走。

第一条，尽量把人工审查做得高效。

第二条，让 LLM 帮你自动审查一部分。

这俩不是二选一，而是互补。

很多团队一开始会犯一个很常见的错误：要么完全靠人，看不过来；要么完全靠模型，觉得省事，结果评估标准越来越飘。真正能落地的方案，往往是把人的判断力和模型的规模化能力拼在一起。

比如你不一定要随机翻所有 trace。你可以把特定类型的请求单独拎出来：高风险对话、失败率高的路径、投诉集中的场景、涉及支付或权限的交互。这样人工审查不再是大海捞针，而是有目标地看最该看的东西。

这就是 annotation queues 的意义。它让 trace 不再只是冷冰冰的日志，而是可以被分流、打标、协作审查的对象。

这个设计很关键，因为它把“看日志”升级成了“看对话、看决策、看问题模式”。

---

真正好用的监控，不是报表好看，而是能从指标一路钻回具体对话

视频里提到 LangSmith 的另一半思路，是用 LLM 自动做评估，也就是 evals 和 insights。

这部分特别值得拆开说。

传统监控里，指标通常是结果导向的。比如错误率升了，延迟高了，吞吐掉了。你知道“有问题”，但未必马上知道“问题长什么样”。

Agent 监控要更进一步。它不仅要告诉你出了问题，还要告诉你问题属于哪一类：

• 输出质量差
• 安全性不够
• 合规风险
• 用户情绪变差
• 某种工具经常调用失败
• 某类请求总是被误解

LLM 在这里的价值，是可以自动对生产 trace 做结构化判断。你可以配置它检查某些维度，然后把结果汇总成趋势、报表、仪表盘，甚至报警。

这和很多人想象中的“AI 自动打分”不太一样。不是说让模型拍脑袋给个总分，然后你就完事了。更好的方式是把它当成一个自动化审查员，去筛查和标记那些你最关心的维度。

真正厉害的是后半句：
你不只是看到一个高层指标，还能钻回具体对话。

这件事非常重要。

因为如果你只看“成功率 92%”，你会以为系统还行。可一旦你点进某一类失败样本，就会发现根本不是随机波动，而是某个工具在特定上下文下经常选错，或者某种问法会系统性地触发误判。

这时候你能做的就不只是“优化一下模型”，而是去改：

• 提示词
• 工具调用逻辑
• 路由规则
• 评估标准
• 数据采样策略
• 人工复核流程

这才叫真的监控。不是看一张漂亮图表，而是能把图表一路追溯回真实世界里的那句用户原话。

---

生产环境不是终点，它其实是 Agent 变聪明的开始

最后这段话很有意思：

“Capture the right data, combine human and automated review, and let every production interaction make your agent better.”

翻成大白话就是：别把上线当成交卷，把它当成开始收集真题。

很多团队做 Agent，会把大部分精力花在 demo 阶段。前台看起来很惊艳，几轮对话很顺，工具也都能调用，整个产品像是“差不多能用了”。

可一旦真正上线，才会发现最麻烦的问题都不是演示里能暴露出来的：

• 用户会用完全意料之外的方式提问
• 同一句需求，不同人说法差很多
• 模型对措辞很敏感
• 某些边界场景会反复触发错误决策
• 有些问题只有在真实流量里才会出现

所以生产环境不是“验收”，而是一个巨大的反馈场。

如果你能把每次交互都记录下来，按质量、安全、满意度、失败模式分层处理，再把这些数据反哺到开发流程里，Agent 才有可能真的变强。

这也是 Agent 和传统软件最不同的地方之一。传统软件上线后，功能通常比较稳定，迭代更多是修 bug 和加需求。Agent 则更像一个会在真实使用中暴露性格的系统。它会被用户“训练”，也会被错误“塑形”。

你监控得越好，迭代就越快。

你看得越细，修得越准。

你越是愿意把生产对话当作一手材料，而不是噪音，Agent 才越有机会从“能跑”变成“靠谱”。

---

值得记住的话

You don't know what your agent will do until it's in production.

The signal you want to track isn't in the code. It's in the conversations themselves.

Capture the right data, combine human and automated review, and let every production interaction make your agent better.

---

标签

AI 产品 工具 方法论 技术