日志全绿，答案照样能编出来
客服 Agent 刚上线，很多人第一件事是接监控。延迟、状态码、token、调了哪个工具，面板上很快排满绿灯。麻烦在后面。绿灯还亮着的时候，Agent 仍可能给退货问题编一套格式工整、口气很稳、内容全错的说明。用户先发现，日志后发现。
我把 LangChain 2026 年 6 月 12 日发布的《State of Agent Engineering》翻了一遍。问卷从 2025 年 11 月 18 日收到 12 月 2 日，共 1340 份。 可观测性 已经铺到 89%。离线评测只有 52.4%，在线评测 37.3%，还有约三成团队什么评测都没做。装监控的人很多，给答案打分的人少得多。
两家团队，三个月后差在哪
下面这对情形是压缩过的对比，方便把差别摊开。数字来自公开调研，人物是为了把流程讲清楚。
小李那组动作快。他们用 OpenTelemetry 给 Agent 打点，Trace 里能看见每次模型调用花了 340 毫秒，状态码 200，token 花了多少，调了哪个工具。庆功会都开了，觉得 AI 监控这件事算完了。
小王那组慢了整整一个月。他们先攒了几百条标准答案测试集，行业里叫 golden dataset。每条都写好怎么打分，比如答案有没有贴着检索到的资料，工具调用顺序对不对。代码一改就跑分，分数不够就不许上线。
三个月后，小李那边被投诉炸了。Agent 给一个退货问题写了一套听起来极其自信的答案，完全是错的。日志里延迟正常，状态码全是 200，没有任何报错。系统显示一切健康，直到真人用户看出来不对。
可观测性 告诉你 Agent 做了什么。 评测 告诉你它做得对不对。多数团队只做了前一半。
体检机器和坐诊医生
体检中心的机器很忠诚。你抽血、拍片、做心电图，它把每一项数值原原本本打出来。这就是可观测性。落到技术上，它对应一条 OpenTelemetry span，记下这次调用花了多少钱、多长时间、传了什么参数、调了哪个工具。
Harness 开源的 harness-sdk 走的就是这条路。一条命令 harness-instrument python app.py，再加环境变量，就能给 OpenAI、Anthropic、LiteLLM 的调用打上 span，业务代码不用改。输出走标准 OTLP，接到 Langfuse、Arize Phoenix、LangSmith 都能用。我在 PyPI 上核对过，这个包还在，协议是 Apache 2.0。
报告打出来，机器自己不会说你健康还是有病。坐诊医生看着同一堆数字给结论，这就是评测。医生靠判断标准，评测靠量化指标。答案有没有贴着检索资料，有没有幻觉，任务有没有做完，有没有安全风险，这些都要写成能打的分。
Harness 自己的产品叫 AI Evals，把它做成 CI 里的发布门禁。官方博文里写的是五十多项现成指标，也能自己用自然语言写评分标准。分数过线就放行，不过就挡住。体检机器给数据，医生给结论。
为什么机器装得快，医生请得慢
埋点几乎开箱即用
给 Agent 接 OTel 埋点，接近拿来即用。统一的语义约定已经写好工具调用、模型调用、用户消息该记在哪个字段。评测标准没有这种现成模板。你得自己定义「回答得好」到底指什么。是要忠实于检索资料，还是工具顺序要对，还是语气要专业。这些因业务而异，只能写成测试集，或者用自然语言写评分说明。慢是必然的。
监控立刻能给老板看
Trace 面板一打开，汇报材料就好看。评测拦住的却是差点上线的坏版本。这种没发生的事故，天然不容易被看见。
Harness QPE 工程师 Chetan Sinha 后来把这段经历讲得很具体。
第一轮手工测试每个发布周期要花一到两周。现在我把 AI Evals 接成发布门禁，每次部署都先看有没有把东西搞坏。原来要几天的活，现在几分钟搞完。签字不再靠有人打开一张五百条的表格，看的是通过率。分数过线就发，不过线就不发。
这是评测省下来的时间。没上线之前，谁也看不见这份成本。
日志里常常找不到病灶
传统软件出错会崩溃、报异常、留堆栈。那本身就是报警信号。Agent 不一样。它给出一个自信、格式完美、听起来合理的错误答案，状态码照样是 200，延迟照样正常，日志干干净净。
更别扭的是，一次绕了十四圈才给出答案的低效执行，和一次干净利落的执行，在延迟和状态码上看起来可以完全一样。传统 tracing 认的是请求和响应。Agent 真正的执行单元是一次 run 里所有的模型调用和工具调用，以及一次用户会话里的所有 run。这两个概念在老监控体系里根本不存在，病灶自然也看不出来。
LangChain 后来把这套东西讲得更细。一次模型调用是 run，一次完整执行是 trace，多轮对话是 thread。OTel 里的 span，大致对应这里的 run。你只盯延迟和状态码，等于只看见最外面那一层壳。
只看绿灯会付出什么
只做可观测性、不做评测，最直接的后果是你能看见 Agent 做了什么，看不出它做得对不对，直到真实用户报错。
Digital Applied 2026 年那份企业数据汇编里，转述了 Forrester 面板的一组对比。没有自动化评测的 Agent，过去一年回滚率高达 47%。做了全面评测覆盖的，回滚率只有 9%。我没有直接读到 Forrester 原文，只核对了这篇汇编。按它的口径，评测这一步省不省，会明显改变 Agent 被拉下线重做的频率。
Agent 的问题还会反复冒出来。模型悄悄升了版本，提示词改了一行，上下文窗口变了，今天测出来正常的东西，明天可能就不正常。同一个提示跑两次，结果都可以不一样。你没法像传统单测那样写一个 assertEqual。没有持续评测，等于拿着一份很快过期的体检报告在跑。
三步把打分接进发布
先去翻你们自己的记录
现在就打开手上任何一个 tracing 后台，Langfuse、LangSmith、Arize Phoenix，或者自建的 OTel 后端都行。搜最近一周有没有一条 trace 被打上低分或不合格。如果一条都没有，先别当成全对。更常见的情况是压根没有打分这一步。这才是最该先补的缺口。
把真实翻车写进测试集
好用的做法很土。工程师从真实报错定位到出问题的那一次执行，把这次的输入、输出和检索到的上下文收成一条评测用例，塞进测试集。下次发布前 CI 自动重跑，不达标就挂，拦住上线。
LangSmith 支持把生产 trace 加进数据集。Harness 的 AI Evals 也走同一条路，生产里翻过的车，下次发布前还要再跑一遍。合成题有用，可它很少能复现第一次翻车时的上下文。
埋点这一层，开源 SDK 就能接。评测这一层，不一定非绑某一家平台。你可以用现成的评测产品，也可以自己写打分脚本。关键是分数要进 CI，要能挡住发布。
评测自己挂了，流量仍要走
给评测系统留一个失效时放行的设计。评测服务挂了，流量直接过，只在记录上打个标记。不要因为打分系统本身出故障，再搞出一次可用性事故。评测是质量门禁，不该反过来变成新的故障源。
先去翻最近一周的 trace
现在就去翻你们最近一周的 trace。如果找不到一条被标成不合格的执行，先别庆祝。先问团队，上线前有没有一条明确的分数线，达不到就挡。
文中主要来源
- LangChain《State of Agent Engineering》（2026 年 6 月 12 日）打开报告
- Harness 介绍 AI Evals 的博文，其中引用了 Chetan Sinha 打开博文
- Digital Applied 对 2026 企业 Agent 数据的汇编，其中转述 Forrester 面板回滚率 打开汇编
觉得有帮助，欢迎点赞、在看、转发。还没关注的朋友，点下方名片关注一下，后面继续拆 Agent 和工具怎么真正落地。
