过去三年，能把 Agent 项目从 Demo 做到全量上线的团队屈指可数。多数项目死于三种典型情形：演示很惊艳、一接真实流量就扛不住的"停在 Demo"；小范围试用尚可、一放量问题集中爆发的"卡在扩量"；模型换了几轮、Prompt 改了几十版，却拿不出证据证明变好的"说不清价值"。这三种死法表面不同，根子都是同一件事——团队缺一套可靠的判断机制，不知道当前版本行不行、问题出在哪一层、改完是真进步还是把坑挪个地方。

评测（Evaluation）就是用来补这个洞的机制：一套能持续回答"Agent 好不好、哪里好、哪里不好"的系统化方法与工程设施。本文是《Agent 评测白皮书》系列的第一篇，目标是把评测体系的全貌讲清楚，作为后续三篇的地图。

技术背景与演进

两条趋势正在同时发生，共同把"搭 Agent"的门槛往下压。一是基座模型能力持续进化：长上下文、原生工具调用（Tool Use）、更强的指令遵循和多步推理，把早期需要靠 Prompt 反复打磨、靠工程兜底才能做到的稳定输出和正确路由，越来越多地交给模型本身承担。二是 Agent 框架和协议层的成熟：规划（Planning）、记忆、工具注册、状态管理，从早期需要手写，变成了框架里可以直接拼装的标准组件。两条曲线叠加的直接后果是 Agent 落地场景越来越多、越来越发散，但掌握评测方法论的人却没有跟上——这是一个供给侧和认知侧的错配。

《Agent 评测漫谈》讲清楚了"评测是什么、为什么这么做"，但收到最多的反馈是"方法论理解了，落到自己项目上还是不知道从哪下手"。这正是本系列要解决的问题：给出可落地的步骤、每一步的产出物形态、达标的判断标准，以及常见的坑。

行业内对评测相关概念的划分目前并不统一，这也是初学者容易卡住的地方：

平台/产品　对"在线评测"与"监控"的划分　对 Trace 采集与分析的归属
Arize AI　二者部分合并讨论　Trace 采集归入 Observability
LangFuse　区分 Evaluation 与 Monitoring　Trace 分析部分归入 Evaluation
Braintrust　强调 Eval 作为独立一等公民 Trace 更多服务于调试而非评测

#howto入门codex #AI反常识howto #howto用好AI #多模态人工智能 #大模型 #人工智能发展 #开发者选项