先说个场景。你的Agent跑起来了，Demo效果不错，三个月前还接了LangSmith的追踪，控制台里每天都有日志。直到某天用户说"这周它已经答错三次了"，老板问"怎么感觉比上周笨了"——你打开Trace看了半天：延迟正常、没报错、HTTP全是200。
但答案就是错了。
一组数据：几乎人人都装了"行车记录仪"，但没人做年检
LangChain做过一份覆盖1300多名从业者的《智能体工程现状》调查，几个数字值得看两遍：57%的受访者，Agent已经在生产环境跑着；接近89%已经给Agent部署了可观测性。但问到评测，只有52.4%在做离线评测、37.3%做在线评测，还有29.5%——接近三分之一——完全没做过任何评测。同时，32%的人把"质量问题"列为Agent部署到生产环境的最大障碍。知乎
一句话总结：大家都给Agent装了行车记录仪，但三分之一的车从来没做过年检。
这不是小圈子问题。Business Research Company的估算显示，LLM可观测性平台市场2026年规模26.9亿美元，比2025年的19.7亿美元又涨了一截，预计2030年到92.6亿美元，年复合增长率36.2%；Gartner的预测更直白：到2028年，LLM可观测性投入将覆盖50%的生成式AI部署，而2026年初这个比例还只有15%。知乎
赛道在狂飙，但"观测"和"评测"这两件事的落差，被大多数人忽略了。
监控防不了"变笨"：Tracing和Evals各管一半
原因其实不复杂。Tracing记录的是"发生了什么"：每一次提示词、每一次工具调用、每一个token、每一毫秒延迟。它回答不了另一个问题——“做得好不好”：答案对不对、检索相不相关、Agent的轨迹有没有在同一个工具上死循环。
传统监控抓得住服务宕机，但LLM的失败大多是"语义层面"的：同一个提示词，模型这次和上次给的答案不一样；检索步骤返回了错误的文档，可后续每一步状态都是绿的；一个Agent连续调了14次工具、烧掉几千token，最后自信满满地给出错误答案。HTTP 200，一切正常。
所以LangSmith把能力拆成了两半：Tracing、Playground这一半，大多数人接上了；Datasets、Evaluators、实验对比这一半，大多数人没碰过。很多人对LangSmith的认知停在"看Trace的网页"，实际上只用了一半。另一半才是防"悄悄变笨"的：离线评测在你改提示词、换模型、动检索索引之后跑一遍数据集，及时发现回归；在线评测对生产流量抽样打分，盯住忠实性、相关性这些传统指标完全看不到的维度。
一个"看起来对"的答案能错多少：36个百分点
讲个社区里的真实例子。一个开源的企业级RAG Agent项目，测试集里有这么一题：“中芯国际2024年营业收入相比2023年增长了多少？”
Agent的回答：2024年营收578亿元，2023年630亿元，同比下降8.25%，评测打分correctness只有0.2。正确答案是：2024年577.96亿元，2023年452.50亿元，同比增长27.7%。知乎一个说降，一个实际涨27.7%，差出36个百分点。
复盘下来，没有一步报错：向量库里中芯国际的年报只有1份（人民币列报），研报有7份（部分美元列报）；检索"2024营业收入"时研报数量占优，把年报淹没了；模型从研报里拿2024年的数、又从另一份研报拿2023年的数，跨币种、跨来源混算出一个增长率。
最后的修复是加了两条Prompt规则——“首检只有研报时必须补检索年报"和"对比类指标必须同源同币种”。但作者说了句很清醒的话：这类问题的根治在检索层，比如给文档打tags、检索时加权，而不是继续堆Prompt规则。知乎这句话值得划重点：评测的价值是帮你定位病灶在哪一层，而不是让你无脑加规则。
更大的坑：AI套娃
还有个更隐蔽的坑，一位社区开发者自己踩出来的：他做评测时，测试数据是AI写的，参考答案是AI定的，最后LLM-as-a-Judge打分——结果全部通过。他回过味来：这是"AI踢球，AI裁判，AI守门"，整个评测闭环里根本没有人，通过是必然的。小红书他复盘出的最小正确姿势值得抄：换真实脱敏数据，让AI先标注、人来纠正，再沉淀成可信测试集。一条可信的评测样本，长这样——真实输入，加上人工校对过的参考答案：
LLM-as-a-Judge不是不能用，但它的打分要拿人工偏好去校准。LangSmith的标注队列（Annotation Queue）就是干这个的：让领域专家审输出，审过的结论再反过来校准评估器。知乎评测器本身也要"被评测"，这件事很多团队压根没想过。
最小可行评测：四步，一个周末
如果你现在只接了Tracing，建议按这个顺序把另一半补上：
第一步，攒一个黄金集。不用多，30条就够，但必须是真实案例：用户反馈里来的、线上bad case、你已知的易错边界。坐在那儿凭空编300条，不如真实攒30条。在LangSmith里就是一个Dataset，每条是"输入+参考答案"：
第二步，评估器先硬后软。格式要求、必备字段、引用单位、有没有注明来源，这类硬规则用代码评估器判，便宜、稳定、可复现；语义层面的正确性、相关性再交给LLM-as-a-Judge。别一上来就把所有判断都丢给大模型。
第三步，让"重跑评测"成为每次改动后的固定动作。改了Prompt、换了模型、动了检索索引，就把黄金集重跑一遍，用实验视图对比新旧两组结果——哪个评估器分数掉了、哪条用例回归了，一眼看到。分数不达标就拦住，别上线。这才是"回归测试"在LLM应用里的真实含义：它防的不是功能坏掉，而是悄悄变笨。
第四步，把线上bad case回流成数据集。这是Tracing真正的复利时刻：线上失败的Trace，动动手就变成未来的回归用例。评测体系只有转起来才会生长，否则就是一张静态快照。
两个容易踩的坑：采样率和免费额度
生产环境的坑，社区已经替你踩过一个：Trace采样率别拉满。一个热门实战教程的评论区里有人总结，线上并发一高，采样率设太高会拖慢主流程，后来改成动态采样——只抓error和slow query——才把可观测性和性能平衡住。哔哩哔哩
另一个是钱的问题。LangSmith的Developer档免费：0美元/席位/月，含每月5000条基础traces，1个席位，超出按量付费；团队用的Plus档39美元/席位/月，含1万条基础traces，能解锁Deployment、Engine这些；企业档支持自托管和混合部署。LangChain官网个人学习和小项目，免费额度基本够起步；真跑到额度耗尽，社区也有成熟解法——在代码里包一层薄适配，换个环境变量就能切换可观测后端，业务代码零改动。小红书顺带说一句，2026年选型时，OpenTelemetry GenAI语义约定正在变成硬指标，早点对齐这个标准，后面换后端才不疼。知乎
谁现在就该动手
对号入座：
个人学习者——免费档先把Tracing和Playground用熟，看清楚一次调用是怎么分层的；项目还没跑稳，先别急着上评测体系，性价比不高。
小团队MVP——30条黄金案例加两三个评估器就够了，别过度设计。这个阶段评测防的是"改坏"，不是"完美"。
已经上线对客——离线回归、在线抽样评测、标注队列，三样都该有。现在Agent方向的面试里，"你如何评测你开发的Agent"已经是高频问题，答不出闭环，简历上的项目经验都要打折。<#&!53#&!>知乎
最后说下方向
这个领域接下来会发生什么，有两个信号值得盯：一是LangChain自己在把评测循环自动化——今年4月公测的LangSmithEngine，本质是个"给Agent看病的Agent"：持续扫描生产Trace，把反复出现的失败模式聚成issue，自动生成评估器和回归用例，甚至能提修复PR等人审。官方很克制，明确说现阶段不允许无人审直接合并，但方向已经很清楚了。知乎
二是评测正在和护栏、AgentOps融合，工具清单越拉越长，Braintrust、Promptfoo、Arize都在抢这块地。微博但工具再多，逻辑不变：Tracing是眼睛，Eval是尺子，真正值钱的是把看到的、量到的，变成下一步动作。
如果你的Agent已经上线，今天就可以把评测补起来。成本是一个周末，收益是下次有人问"它是不是变笨了"的时候，你能甩出一张对比图，而不是一个茫然的表情。
