可靠与生产：评测、监控、成本 · 里程碑长文：20 个问题，把你的 Agent 从 demo 变成产品

日期：2026年10月19日 · 路径：Agent 专业开发人员 · 阶段 s5

这个里程碑要做什么

给你第四阶段完成的 MCP Agent 建一套最小但完整的评测体系，三件交付物：

• 20 例黄金评测集：20 条真实用户会问的指令，每条标注期望行为——该调哪个工具、答案必须包含或禁止包含什么、该拒绝还是该执行；
• 全量 trace：接入 Langfuse，记录每一次会话的完整轨迹——模型输入输出、工具调用、token 消耗、延迟；
• 首份评测报告：跑完 20 例，输出通过率、失败分类（选错工具 / 参数错误 / 该拒未拒 / 答非所问）、成本与延迟分布。

为什么是它（设计意图）

「没有评测就没有迭代」不是格言，是字面意思：没有这 20 例，你每次改提示词都是在掷骰子——改好了 A 场景、改坏了 B 场景，你根本不知道。

20 例是刻意的小数字：小到你能手写、能手审，大到足以暴露主要失败模式。评测集是资产，会随系统一起长大。LLM-as-judge 能提效但引入偏差——让模型评模型，它有自己的偏好，所以关键场景必须人工抽检，这个纪律要在第一次评测就建立。trace 是生产系统的黑匣子：没有轨迹记录，线上出问题你只能对着聊天记录猜。最后，这份报告会第一次告诉你「这个 Agent 一次会话多少钱」——这是一切成本优化（模型分级、缓存、上下文裁剪）的基线。

配套资源怎么用

• 方法论底座：Stanford CS329S（Machine Learning Systems Design）的评测与监控部分，回答元问题——「一套评测体系应该怎么设计」。
• 精读章节：Chip Huyen《AI Engineering》的 Evaluations 章节，公开资料里把 LLM 评测讲得最透的之一，重点看评估器设计与 LLM-as-judge 偏差的讨论。
• 工具接入：Langfuse 官方文档完成 trace 接入；LangSmith 文档（数据集、评估器、trace 三件套）概念互通——选一个作主工具，另一个了解概念即可。
• 框架视角：OpenAI Evals（GitHub）——不必照抄结构，但要看懂一个评测框架如何组织「数据集—任务—评估器—报告」，理解它的设计取舍。
• 第五遍读《Building Effective Agents》：带着「简单模式可评测、复杂编排难观测」的体感，你会真正读懂它为什么反复强调简单。

常见翻车点

• 评测集全是开心路径：20 例里必须有边界情况——模糊指令、该拒绝的敏感操作、工具会失败的场景。全是正常用法的评测集只能证明 demo 没坏。
• 期望答案写死成字符串匹配：合法回答有一万种措辞，判分标准要落在行为上（调了哪个工具、包含哪些关键信息），不是逐字比对。
• 盲信 LLM-as-judge：不抽检就采信评分。第一版至少人工复核全部 20 例的判定，摸清 judge 的偏差方向后再谈自动化比例。
• trace 只记成功：失败会话的 trace 才是宝藏——重试链、超时、异常分支都要能回放。
• 报告只有通过率一个数字：「通过率 75%」没用，「75%，其中 3 例选错工具、2 例参数格式错」才能指导迭代。
• 忘记算成本：评测集本身就是成本，每次全量跑都烧 token——把「评测一次多少钱」也记进报告。
• 四道防线留到上线前：输入过滤 → 工具白名单 → 输出校验 → 人工兜底，现在就该对照检查你的 MCP Agent 有哪几道、缺哪几道。

验收清单

• 20 例评测集入库：每例含输入、期望行为、判定标准，覆盖正常与边界场景
• Langfuse 接入生效：任意一次会话能回放完整 trace（模型 I/O、工具调用、token、延迟）
• 首份评测报告产出：通过率 + 失败分类 + 成本/延迟分布，三项齐全
• LLM-as-judge 的判定经人工抽检，抽检结果与偏差结论写进报告
• 四道防线对照检查完成，缺失项有明确结论（补，或明确不补）
• 评测可重复执行：改一行提示词后 10 分钟内能重跑并对比前后报告

延伸建议

把评测接进你的改动流程：以后每改提示词、每换模型、每改工具描述，先跑 20 例再决定是否合并——这就是 CI 的雏形。评测集按月扩容，把真实使用中答错的案例补进来，失败驱动的评测集最有生命力。用报告里的成本数据练手「三板斧」：简单路由换小模型（模型分级）、重复系统提示做缓存、裁剪塞进上下文的检索内容——每改一项，重跑评测证明质量没塌。