这篇解决的问题是：Agent 项目每次改提示词、换模型都像开盲盒，团队只能靠手点几个案例来判断变好还是变坏。
最值得拿走的是七步建设流程中的两个判断：用例要从真实流量和客户验收场景里收，而不是工程师凭想象造；指标要跟着分层走，每个分层只看少量说得清的指标。最容易出现误用是把基线建设当成一次性大工程，憋三个月憋一个几百条的「完美标注集」——正确做法是先用三五十条粗糙样本把回归跑起来，再逐步加厚。
相比站内评测方法类文章讲「为什么要有评测」，这篇的增量在「从零到一怎么落地」，尤其是基线报告的写法与回归节奏的设计。国内语境要叠加的是：客户现场数据往往不能出域，标注与回归要提前确认数据边界。
读完后的第一件事：从最近一周的真实请求里抽三十条，按第四步的分层原则粗分一层，本周先把最小回归跑起来。
—— FDEChina编辑部 · 架构师视角
Agent 项目最危险的时刻不是上线第一天，而是第一次大改版：换模型、重构提示词、调整工具调用逻辑。改完之后团队围在屏幕前点十几个案例，有人说好了有人说坏了，最后靠嗓门大的人拍板。问题不在人，在于没有基线——没有一组固定的用例、一套说清口径的指标、一份记录当前水平的报告。这篇按七个编号步骤给出基线建设的完整做法，每步包含做什么、产出物和常见坑，从架构视角设计，默认资源有限、客户数据敏感、团队没有专职评测工程师。它承接项目生命周期中的验证阶段，也是 PoC 验收清单中「回归可执行」一项的前置条件。
步骤一：用例收集——从真实流量里来，不从想象里来
做什么：从三个来源收用例：真实流量（脱敏后的请求日志里按频率和失败率抽样）、客户验收场景（合同或验收文档里点名要支持的操作）、专家经验（客户方老师傅口中的「新手最容易搞错的情况」）。每条用例记录输入、期望输出或期望行为、来源、出现的频率估计。目标是先攒三十到五十条，不要贪多。
产出物：一张用例登记表，字段至少含编号、输入、期望行为、来源、频率、难度标记。
常见坑：用例全由工程师手造——看起来干净整齐，全是「标准 Happy Path」，恰恰覆盖不到线上会坏的地方。另一个坑是只收集失败案例，导致基线全是难题，正常路径的质量反而看不见。
步骤二：分层——不同难度的用例不能混在一个池子里算分
做什么：把用例分成至少三层。第一层核心路径：高频、确定性高、失败代价大的操作，例如一次标准查询或一份标准文档生成；第二层边界场景：输入不规范、多轮追问、需要澄清意图的情况；第三层已知难点：当前方案明确做不好、但客户同意暂时人工兜底的场景。分层标准由团队和客户共同确认，写进文档。
产出物：标注好层级的用例集，以及一页分层定义说明。
常见坑：不分层直接算总分——改动后总分上升，可能是核心路径变好，也可能是难题偶然蒙对，而核心路径悄悄变坏了。混池算分是 Agent 评测里最隐蔽的坑。第三层要设上限，难题占比过高会让团队对整体质量产生悲观错觉。分层也不是一次定死：每月评审时允许用例在层间迁移，但每次迁移要留记录，否则历史数字之间就失去了可比性。
步骤三：标注——先定「对的判定标准」，再打标签
做什么：对每条用例，先和客户或业务专家确认「什么算对」：有唯一标准答案的记录答案；开放性输出写成三到五条可接受的判定要点，例如「必须包含 X 结论、不得出现 Y 事实、语气符合 Z 要求」。标注由两人独立进行，不一致的条目拿出来讨论裁决。涉密的客户数据在本环节就要确定脱敏方案，确认哪些能进评测集、哪些只能 onsite 用。
产出物：标注规范一页（判定标准、示例、争议裁决记录）+ 双人标注后的用例集。
常见坑：跳过判定标准直接标注，两周后没人记得当时为什么判这条对；用自动指标（比如字符串相似度）替代人工判定开放性输出——数字好看，和业务上的「对」没关系。
步骤四：指标选择——每个分层只挑两三个说得清的指标
做什么：核心路径看任务成功率（端到端完成且结果判定为对的比例）、平均延迟、单次成本三项；边界场景看澄清率（该澄清时是否主动澄清）与幻觉率（编造不存在事实的比例）；已知难点只记录通过率做趋势观察，不设达标线。所有指标在文档里写清计算口径：分母是什么、边界情况算对还是算错。
产出物：指标定义表（指标名、口径、分母、适用分层、采集方式），这张表比指标本身更重要。
常见坑：指标越多越好是错觉——一个十项指标的仪表盘没人看，复盘时大家只吵口径。宁可五个口径清楚的指标，不要二十个口径含糊的。还要警惕把 LLM-as-judge 的分数当客观真理，judge 本身也需要抽检校准。
步骤五：基线报告——把「当前水平」钉在纸上
做什么：在系统尚未开始频繁改动时跑一轮完整评测，把结果写成基线报告，内容含：用例集版本号与数量分布、各分层各指标的数字、十个左右有代表性的通过与失败案例（附输入输出摘录）、已知短板清单。报告控制在三页以内，让没参与的人十五分钟能读懂。基线报告要发给客户方关键人确认，避免后续对「什么算正常水平」产生分歧。
产出物：三页以内的基线报告 + 冻结的评测集 v1 + 可一键执行的评测脚本。
常见坑：用最强的模型、最调优的提示词跑基线——基线虚高，之后的每个改动看起来都是退步。基线应该记录的是「当前交付版本的真实水平」，平庸一点没关系，它是用来对比的，不是用来炫耀的。
步骤六：回归节奏——什么改动必须跑，跑完和谁比
做什么：定三条铁律：改动提示词、换模型版本、调整工具或检索逻辑，三者任一发生必须跑全量回归；日常迭代每日或每两日跑核心路径一层，快速反馈；每个迭代分支合并前跑一次，结果贴在合并请求里。所有回归结果与基线报告对比，写入带时间戳的结果存档，形成可回溯的历史序列。回归耗时建议控制在一杯咖啡之内（十五到二十分钟）：超过半小时的回归几乎必然被跳过，所以评测集规模要与运行时间一起规划，宁可核心层小而精，不要全量大而慢。
产出物：书面的回归规则 + 按时间排列的回归结果序列。
常见坑：小改动不跑回归—— Agent 系统里不存在「就改了一个词」的改动，一个形容词能让边界场景成功率掉十几个点。另一个坑是只在出事之后补跑回归，事后跑出来的数字无法回答「是不是这次改动弄坏的」。
步骤七：告警——让退化在客户发现之前被你发现
做什么：给核心路径的任务成功率设一条底线（例如低于基线报告数字减去五个百分点即触发告警），配合线上抽检：每天从真实流量抽固定条数自动跑一遍评测集判定。告警触发后的动作要预先写好：谁负责、先查哪几处改动、多久内给结论。线上指标与离线评测数字出现方向性背离时（离线变好、线上变差），一律按线上为准并回头检查评测集是否过时。
产出物：告警规则文档（阈值、责任人、响应动作）+ 每日线上抽检的例行结果。
常见坑：告警阈值设得太敏感，天天狼来了，团队学会无视告警；或者只告警不定义响应动作，告警邮件躺在收件箱里和没有告警一样。评测集本身也要维护：线上新出现的失败模式，每月评审一次，该进评测集的收进来，升版本号。
小结与下一步
基线建设的本质是花一次功夫，把团队从「每次改动都吵架」变成「每次改动都看数字」。七步里最不该省的是第二步分层与第四步的指标口径表——它们决定了数字是否可信；最常被高估的是标注集规模，三五十条分层清晰的用例远胜三百条混池的样本。基线报告既是团队内部的改动依据，也是与客户对齐「正常水平」的锚点，直接支撑交付质量度量中的任务成功率与成本指标。从 Agent 系统的设计原理出发理解为什么这些环节会坏，可延伸阅读Agent 专题；实践层文档的组织方式参见FDE 知识指南。