别让你的Agent在生产环境里裸奔

Agent上线了。监控面板一片绿。但你敢说它的回答质量在变好吗？

这个问题正在成为2026年所有做Agent团队的心病。The New Stack近期一篇关于AI Agent评测闭环的文章，点破了一个行业共同的尴尬：我们为Agent建了网关、接了模型、上了生产，却没人能回答"它是不是在变聪明"。

核心判断只有一句话：Agent的下一轮竞争，不在模型端，而在反馈闭环端。谁能把生产轨迹（traces）、策展数据（curated data）和评测体系连成一条流水线，谁就掌握了迭代速度。

📉 服务健康，不等于答案变好

先讲一个几乎所有团队都踩过的坑。

一个客服Agent上线三个月，可用性99.9%，延迟稳定，错误率几乎为零。老板问：Agent干得怎么样？团队打开监控面板——全是基础设施指标。至于"用户是不是真的被解决了"，没人说得清。唯一的证据，是某天运营群里有人抱怨了一句"这个机器人答非所问"。

这就是当下Agent工程的集体现状：传统可观测性管的是系统，Agent需要被观测的是"对不对"。

The New Stack那篇文章开篇就戳中了这一点："你的Agent已经上线。服务是健康的。但它的回答在变好吗？"这句话之所以扎心，是因为它指向一个事实——延迟、错误率、QPS这些老三样，对评测Agent几乎无用。一个Agent可以每条请求都"成功返回"，但成功率只有60%。

据多位接近头部大模型应用团队的人士透露，不少团队上线后的第一版"评测"，就是让实习生每周抽看几十条会话记录。这种做法的问题显而易见：样本小、主观、滞后，且完全无法回答趋势问题。

产业逻辑很清晰：当软件的核心产物从"函数返回值"变成"概率性的回答"，质量工程必须重造一套方法论。这套方法论的入口，就是Agent可观测性（Agent Observability）。

🔄 评测闭环：让生产数据飞起来

那套正确的方法论长什么样？The New Stack给出的答案是一个闭环：把生产轨迹连上策展数据，再把策展数据喂回评测，评测驱动迭代，迭代重新上线。

画成图是这样的：

这个闭环的精髓在于：生产环境不是终点，而是数据采集的起点。

具体拆开看，每一环都有讲究。

第一环是轨迹采集。Agent的每一步——调了哪个工具、检索了什么上下文、模型思考了什么、最终输出了什么——都应该被结构化记录。这里已经有事实标准可循：OpenTelemetry正在推进GenAI语义约定，Langfuse、LangSmith、Arize Phoenix这类工具都在围绕"trace优先"的思路构建。轨迹不是日志，它是一棵带因果关系的调用树。

第二环是策展数据集。这是最容易被忽视、也最值钱的一环。生产轨迹里埋着黄金：那些用户明确纠正过的回答、那些触发人工接管的会话、那些失败案例的典型模式——把它们清洗、打标、结构化，就变成了评测数据集。文章标题里的"curated data"，指的就是这个动作。

一位做过RAG产品落地架构师的私下评价很传神："上线前我们高估了模型的智能，上线后我们低估了评测数据的价值。"

第三环是评测本身。评测分两层：在线评测，用用户反馈、任务完成率等信号实时感知；离线评测，在策展数据集上做回归测试，确保每次改提示词、换模型版本、调工具逻辑，不会把原来能做对的事改坏。

这三环连起来，就形成了一个可以被度量的飞轮。

🏗️ LLMOps的时间线：从可观测到可进化

把这个趋势放进产业演进的时间轴上看，脉络会更清楚：

（时间线为产业脉络的示意性梳理。）

注意2025年之后发生了什么质变：单轮RAG时代，答错了顶多损失一次问答；Agent时代，一个多步任务可能在第三步才开始累积错误，到第七步全面崩盘。多步放大了错误，也让"事后归因"的难度指数级上升。这就是为什么评测闭环从"锦上添花"变成了"生死线"。

来看一下Agent可观测和传统Apm的差别，很多团队转型时在这里吃亏：

这张表解释了一个反直觉现象：为什么很多大厂已有的监控体系，在Agent面前"突然失效了"。不是工具不行，是问题变了。

产业判断是：Agent评测闭环正在从LLMOps里独立出来，成为一条新的基础设施赛道。它的终局形态，大概率是"数据基础设施+CI/CD"的合体——评测集就是测试用例，生产轨迹就是缺陷报告，策展流程就是测试资产的持续维护。

💰 落地路径：别一步到位，先建最小闭环

对工程团队来说，最关心的是怎么落地。以笔者的架构经验，给出的判断是：不要追求完美的评测体系，先跑通最小闭环，再逐步加密。

一个务实的分阶段路线：

阶段一，接轨迹。选一个支持trace结构的可观测工具，把Agent的每一步调用、上下文、token成本记下来。这一步的价值立竿见影：出问题时能归因到具体某一步的检索或工具调用。

阶段二，建评测集。别从零开始标注，直接从生产失败案例里捞。前100条可以人工标注，重点覆盖你业务里的高频场景和致命场景。评测集不求大，求"代表性"——宁可100条覆盖核心路径，不要1000条长尾噪声。

阶段三，上回归测试。把评测嵌进CI/CD：任何提示词修改、模型版本切换、检索策略调整，先跑一遍评测集再上线。这一步之后，团队才真正获得了"快速迭代"的资格——没有回归保护的快速迭代，只是在赌运气。

阶段四，持续策展。建立从生产到评测集的固定通道：每周从轨迹里筛选失败样本和新出现的长尾场景，人工复核后入库。评测集是活的资产，不是一次性交付物。

成本上要提醒一句：评测并非免费。大量团队的教训是——评测用的强模型按次调用，成本可能超过生产推理本身。务实的做法是分层：低成本信号（用户反馈、规则断言）全量跑，强模型评分只抽样，人工标注只留给高价值样本。评测体系也要讲单位经济学，否则闭环本身就会变成成本黑洞。

另外据多位接近头部Agent创业团队的人士透露，团队内部对"谁来负责评测"一直有路线之争：算法团队认为是模型问题，平台团队认为是数据问题。最后普遍的结论是——评测闭环必须有人专职持有，它是一个产品职能，不是一个顺手兼职。

🚀 真正的壁垒：数据在飞轮里转了几圈

回到开头的问题：Agent上线后，答案有没有在变好？

过去一年行业用真金白银验证了一个事实：模型能力在收敛，各家头部模型的能力差距在缩小，应用团队的护城河越来越不在"用了哪个模型"，而在"迭代得多快、迭代得多准"。

而迭代速度的上限，由反馈闭环决定。生产轨迹是你的独家原料——这是任何竞争对手都拿不到的数据；策展流程决定原料的纯度；评测体系决定每轮迭代是前进还是震荡。三者缺一，飞轮就空转。

（构成为笔者基于工程经验的示意判断，非统计数字。）

前瞻地看，Agent评测闭环这条赛道会有几个确定性方向：评测与部署流水线的深度融合（评测不过，不给上线）；用户反馈信号的自动化采集与融合；以及评测数据集本身的治理——版本化、去重、防止数据泄露进训练。当Agent规模铺开后，"评测资产的治理"会成为下一个被提上日程的问题，就像十年前数据治理从数仓里长出来一样。

一句话收束：模型可以买，轨迹和数据飞轮买不来。Agent时代真正的复利，藏在每一次失败案例被策展进评测集的那个瞬间。别再让你的Agent裸奔了——先把闭环搭起来，再谈规模化。