Agent 评测是 Agent 工程化落地中最容易被低估的一环。很多团队能快速搭出一个能跑的 Agent却很难回答三个基础问题新版提示词真的比旧版好吗同一个任务连续运行二十次成功率是多少失败的回合到底是模型理解错了、工具调用错了还是任务定义本身有歧义。Agent Review Studio 这类 local-first agent evaluation workbench解决的就是这件事把评测集组织、运行轨迹记录、指标计算和结果审查整合到一个本地工作台中让 Agent 的行为变化可复现、可对比、可人工核查。这篇文章不假定你已经拥有完整的评测平台也不绑定某个具体 Agent 框架。我会从评测工作台解决的底层问题开始再给出一个可以在本地跑通的最小实现内容包括评测集定义、运行器、轨迹存储、指标计算和结果审查。读完以后你可以把同一套思路迁移到自己的 Agent 项目里底层不管是自研模型调用、LangChain 这类编排框架还是企业内部封装好的 SDK都只影响适配层不影响工作台的整体设计。1. Agent 评测为什么不能只靠普通测试脚本1.1 Agent 行为和普通函数测试有本质差别传统单元测试有一个隐含前提相同的输入会产生稳定输出。对一个纯函数来说入参确定、执行环境确定返回值就可以被精确断言。Agent 不具备这个特性。Agent 的输入是自然语言任务执行过程是模型推理、工具调用、结果观察的循环最后的输出既受模型版本和温度参数影响也受上下文长度、工具返回内容、网络延迟甚至并发顺序影响。同样是帮我查一下本月订单金额并生成汇总模型第一次可能直接调用查询工具第二次可能先问用户要具体日期范围第三次可能选择了错误的时间字段。三个回合的最终结果可能完全不同但每个回合内部都有完整推理链路。只用断言结果正确与否的测试脚本无法回答为什么会失败失败在哪一步是不是工具返回格式变了这类问题。所以 Agent 评测的核心对象不是单个输出值而是执行过程本身。评测工作台必须能记录每一轮推理、每一次工具调用、每一个中间观察结果把黑盒输出变成可审查的白盒轨迹。轨迹回放能力是评测工作台和普通测试脚本最本质的区别。1.2 local-first 解决的是数据主权和可复现问题local-first 这个词在 Agent 评测场景下有两层含义。第一层是数据不出本机。Agent 运行轨迹里通常包含用户问题、业务字段、工具返回的原始数据这些内容很可能涉及敏感信息。如果评测平台是云端 SaaS轨迹上传意味着业务数据离开本地网络很多团队在合规上无法接受。本地优先的工作台把 SQLite 文件、轨迹目录和评测报告都放在本机评测数据的所有权和使用权都留在团队自己手里。第二层是环境可控。云端评测平台往往黑盒管理模型版本、参数和依赖版本出现问题后很难回溯。本地工作台可以把模型版本、提示词版本、工具定义版本、依赖锁文件一起记录成一次评测快照。出问题时按快照重建环境就能复现不需要猜测线上环境发生了什么变化。需要说明的是local-first 不等于完全离线。评测运行器仍然需要调用模型 API只是评测框架本身、存储、审查界面都在本地运行。文章后面说的架构也是这种形态框架本地化模型远端调用。1.3 评测工作台的五个能力层次从功能角度看一个可用的 Agent 评测工作台至少包含五层能力评测集管理组织和版本化用例集合支持分类、标签、预期结果描述。运行器批量执行评测任务统一注入环境变量、模型参数和工具配置。轨迹存储把一次运行的所有步骤按时间顺序落盘形成可回放证据。指标计算在轨迹基础上计算成功率、工具调用有效率、延迟、Token 消耗等。审查与对比把多次运行结果放在一起比较定位差异和回归。这五层缺了任何一层评测都会退回成跑一遍看日志。下面各部分会按这个层次顺序展开实现。2. 先理解评测工作台的核心概念2.1 评测集Suite和用例Case评测集是若干评测用例的集合。一个用例代表一个要验证的任务场景包含任务输入、任务描述、预期行为、标签和可选的环境配置。id: case-001 name: 查询订单状态并回复用户 description: 用户想知道订单 20240315001 当前处于什么状态 input: message: 我的订单 20240315001 现在到哪一步了 expected: type: contains values: - 已发货 - 运输中 - 已完成 tags: - order - retrieval difficulty: easy这里的expected不是硬编码最终答案而是描述什么结果可以接受。常见判断方式有四类判断方式适用场景说明exact match结构化输出、JSON 字段输出必须精确相等适合工具返回校验contains / regex自然语言回复判断关键信息是否出现JSON Schema 校验工具参数、结构化结果校验字段类型和必填项不关心具体值LLM-as-judge / 人工审查开放性任务由模型或人判断结果质量需要额外控制偏差在最小实现里可以先支持前三种把 fourth 种留到后面扩展。2.2 轨迹Trace是评测的第一手证据轨迹是一次评测运行从开始到结束的完整事件序列。一个最小轨迹应该包含以下字段{ runId: run-20250315-001, caseId: case-001, startedAt: 2025-03-15T10:00:00.000Z, finishedAt: 2025-03-15T10:02:31.000Z, status: completed, steps: [ { seq: 1, type: model, input: 我的订单 20240315001 现在到哪一步了, output: 我需要查询订单状态先调用订单查询工具。, model: gpt-4o-mini, temperature: 0, tokensIn: 120, tokensOut: 45, durationMs: 800 }, { seq: 2, type: tool_call, name: query_order, arguments: {\orderId\: \20240315001\}, result: {\status\: \shipped\, \updated\: \2025-03-15T08:30:00Z\}, durationMs: 210 } ] }轨迹的价值在于事后审查。当最终结果失败时审查者需要知道模型在哪一步产生了错误判断工具返回了什么引起误解后续步骤是否基于错误信息继续执行。没有轨迹指标就是没有根据的数字有了轨迹指标才能被追责和复盘。2.3 指标分为结果指标和过程指标指标不能只看最终成功率。一个 Agent 可能最后输出了正确答案但中间调用了八次工具、绕了很多弯路也可能最终失败但失败原因是外部 API 超时而非 Agent 逻辑错误。所以要把指标分成两类指标类别指标名称计算方法说明结果指标Success Rate成功用例数 / 总用例数最直观的总体质量指标结果指标Task Score按完成度打分 0-100适合部分完成也算分的情况过程指标Tool Success Rate工具成功调用数 / 总调用数反映工具使用能力过程指标Avg Steps总步骤数 / 运行次数步骤多不一定差但可以反映绕路过程指标Avg Latency总耗时 / 运行次数和成本一起决定可用性过程指标Token Usage总 Token 数或单次平均直接对应 API 成本过程指标Abort Rate超时或异常终止数 / 总运行数反映稳定性真实项目里结果指标决定功能是否达标过程指标决定 Agent 是否值得上线。一个步骤少、延迟低、成本可控的 Agent即使成功率略低也往往更容易被用户接受。2.4 回归对比把单次运行变成趋势Agent 评测最大的陷阱是拿一次运行结果下结论。同样的提示词温度为零时也可能因为非确定性采样产生不同输出工具服务波动也会影响结果。正确做法是对同一套评测集反复运行多次把结果当成分布来看。回归对比指两件事一是同一个 Agent 版本在多次运行之间的稳定性对比二是新旧版本在相同评测集上的效果差异。工作台应该把两次运行的用例结果对齐逐条显示这个用例旧版成功、新版失败或新旧都成功但新版多用了两步。这种差异视图是决定是否发布新版本的主要依据。3. 环境准备搭建一个本地可跑通的脚手架3.1 技术栈选择与版本要求下面示例用于说明思路实际项目可以按团队熟悉程度替换。核心原则是运行器用你熟悉的后端语言存储用本地文件或 SQLite审查界面用最简单的方式呈现。推荐一个低成本的组合组件推荐选择备选方案选择理由运行器Node.js TypeScriptPython FastAPI类型约束对轨迹数据结构很有帮助存储SQLitebetter-sqlite3JSON Lines 文件单文件、零运维、适合本地评测集定义YAMLJSON可读性好适合写注释审查界面本地 Express 服务 静态 HTMLReact/Vue最小实现避免构建复杂度命令行入口Commander直接 npm script方便在本地和 CI 复用环境要求很简单Node.js 18 以上npm 或 pnpm一台能访问模型 API 的开发机。不需要部署数据库不需要申请额外的评测平台账号。注意如果你要接不同模型 API请先确认项目使用模型的版本、baseURL 和鉴权方式。模型版本不固定评测结果的可复现性会大打折扣。3.2 目录结构设计一个最小项目可以按功能拆分目录agent-review-studio/ ├── package.json ├── tsconfig.json ├── data/ │ └── eval.db # SQLite 数据库本地自动生成 ├── suites/ │ ├── order-basic.yaml # 评测集定义 │ └── order-edge.yaml ├── src/ │ ├── cli.ts # 命令行入口 │ ├── types.ts # 轨迹、用例、指标类型 │ ├── runner.ts # 评测运行器 │ ├── store.ts # SQLite 持久化 │ ├── metrics.ts # 指标计算 │ ├── adapter.ts # Agent 适配层隔离不同框架 │ └── server.ts # 本地审查服务 └── reports/ # 生成的报告目录这里的adapter.ts是关键。评测工作台不应该关心 Agent 内部是 LangChain 还是自研实现它只要求适配层暴露一个统一方法接收消息和历史上下文返回本轮输出、工具调用列表和 token 消耗。评测集、指标、存储全部建立在统一接口之上替换底层框架只需要重写适配层。3.3 SQLite 表结构设计评测数据核心是四张表用例、运行、步骤、指标。CREATE TABLE cases ( id TEXT PRIMARY KEY, suite TEXT NOT NULL, name TEXT NOT NULL, input TEXT NOT NULL, expected TEXT NOT NULL, tags TEXT DEFAULT [], created_at TEXT DEFAULT (datetime(now)) ); CREATE TABLE runs ( id TEXT PRIMARY KEY, case_id TEXT NOT NULL, status TEXT NOT NULL, -- running / completed / failed / aborted model TEXT, prompt_version TEXT, started_at TEXT, finished_at TEXT, error TEXT ); CREATE TABLE steps ( id INTEGER PRIMARY KEY AUTOINCREMENT, run_id TEXT NOT NULL, seq INTEGER NOT NULL, type TEXT NOT NULL, -- model / tool_call / tool_result / error name TEXT, input TEXT, output TEXT, duration_ms INTEGER, tokens_in INTEGER, tokens_out INTEGER, created_at TEXT DEFAULT (datetime(now)) ); CREATE TABLE metrics ( run_id TEXT PRIMARY KEY, success INTEGER, task_score REAL, tool_success_rate REAL, avg_latency_ms REAL, total_tokens INTEGER, steps INTEGER );表结构的设计要点是把运行的原始轨迹和计算出的指标分开存储。轨迹是证据指标是结论。证据不能因为之后改了算法而丢失所以任何指标计算都应该是从轨迹重新推导而不是在轨迹上原地修改。这样后面优化指标算法时历史运行记录还能重新计算不需要重跑评测。4. 实现一个最小评测闭环4.1 定义评测任务和预期结果在suites/order-basic.yaml中定义两个用例一个验证正常查询一个验证无效订单处理suite: order-basic description: 订单查询基础能力评测 cases: - id: order-001 name: 查询已发货订单 input: message: 我的订单 20240315001 现在到哪一步了 expected: type: contains values: [已发货, 运输中, 已完成] tags: [order, happy-path] - id: order-002 name: 查询不存在的订单 input: message: 查一下订单 999999 的物流状态 expected: type: contains values: [不存在, 没有找到, 无效] tags: [order, edge-case]这里隐藏了一个 Agent 评测的常见误区预期结果描述的是用户可接受的信息而不是模型逐字输出。如果写死values: [已发货]当模型回复您的订单已经发出正在运输途中时正确信息因为措辞不同被判失败。评测集要站在用户价值角度设计而不是站在字符串匹配角度设计。4.2 实现评测运行器运行器负责读取评测集、逐条调用 Agent 适配层、收集轨迹。下面是一个最小实现// src/runner.ts import { readFile } from fs/promises; import yaml from yaml; import { RunResult, Step, Suite } from ./types; import { runAgent, AgentAdapterOptions } from ./adapter; export async function runSuite(filePath: string, adapter: AgentAdapterOptions) { const raw await readFile(filePath, utf-8); const suite yaml.parse(raw) as Suite; const results: RunResult[] []; for (const testCase of suite.cases) { const steps: Step[] []; const startedAt new Date().toISOString(); let status: RunResult[status] completed; let error: string | undefined; try { // 调用适配层执行 Agent接收逐步回调以记录轨迹 await runAgent( { message: testCase.input.message, suite: suite.suite, caseId: testCase.id, }, adapter, (step) steps.push(step) ); } catch (e) { status failed; error e instanceof Error ? e.message : String(e); } results.push({ runId: ${testCase.id}-${Date.now()}, caseId: testCase.id, status, startedAt, finishedAt: new Date().toISOString(), steps, error, }); } return results; }这段代码的关键在于runAgent的第三步回调。很多初版评测框架只会收集最终输出丢掉了中间步骤。正确的做法是让适配层在每个事件发生时就上报一次运行器只负责按顺序追加。这样轨迹的完整性由运行器保证不属于自定义 Agent 逻辑的一部分。4.3 保存轨迹和计算结果运行完成后需要把轨迹写入 SQLite并计算指标。写入顺序很重要先写运行主记录再写步骤再写指标。任何一步失败都应该让整次运行标记为 failed避免出现有指标没轨迹的残缺数据。import Database from better-sqlite3; export function persistRun(db: Database, result: RunResult) { const insertRun db.prepare( INSERT INTO runs (id, case_id, status, error, started_at, finished_at) VALUES (?, ?, ?, ?, ?, ?) ); const insertStep db.prepare( INSERT INTO steps (run_id, seq, type, name, input, output, duration_ms, tokens_in, tokens_out) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?) ); const insertMetric db.prepare( INSERT INTO metrics (run_id, success, task_score, tool_success_rate, avg_latency_ms, total_tokens, steps) VALUES (?, ?, ?, ?, ?, ?, ?) ); const tx db.transaction(() { insertRun.run( result.runId, result.caseId, result.status, result.error ?? null, result.startedAt, result.finishedAt ); for (const step of result.steps) { insertStep.run( result.runId, step.seq, step.type, step.name ?? null, step.input ?? null, step.output ?? null, step.durationMs ?? null, step.tokensIn ?? null, step.tokensOut ?? null ); } const metrics computeMetrics(result); insertMetric.run( result.runId, metrics.success ? 1 : 0, metrics.taskScore, metrics.toolSuccessRate, metrics.avgLatencyMs, metrics.totalTokens, metrics.steps ); }); tx(); }使用db.transaction的目的是保证一批数据要么全部写入要么全部不写入。否则一旦运行到第三步失败数据库里就会留存一条没有步骤记录的 runs 数据后续统计时会污染成功率。4.4 生成审查报告本地工作台的最小审查形态可以是一份静态 HTML 报告或者一个本地 Web 服务。最简单方式是让 CLI 在执行完评测后输出一个reports/report.html里面按用例列出每次运行的成功状态和轨迹摘要。!-- 生成报告的简化模板实际由代码动态渲染 -- ul li strongorder-001/strongcompleted details summary查看轨迹/summary p第 1 步模型调用输入用户消息输出我需要查询订单。/p p第 2 步工具调用 query_order参数 {orderId:20240315001}。/p p第 3 步工具返回 {status:shipped}。/p /details /li /ul报告不是给机器看的是给人审查的。所以每一条用例都要有展开轨迹的入口并且标记该用例使用的预期判断方式。这个阶段的报告可以很粗糙但它必须让审查者能回答为什么判定成功或为什么判定失败。5. 关键模块设计指标计算、轨迹审查和回归对比5.1 指标计算模块指标计算不应该散落在插入数据的逻辑里而应该独立成一个纯函数模块。这样历史轨迹可以重新计算指标不同指标算法可以并行比较。// src/metrics.ts import { RunResult, Metrics } from ./types; export function computeMetrics(result: RunResult): Metrics { const steps result.steps; const toolCalls steps.filter((s) s.type tool_call); const toolSuccess toolCalls.filter((s) s.output !s.output.startsWith(ERROR)); let totalTokens 0; let totalLatency 0; for (const step of steps) { totalTokens (step.tokensIn ?? 0) (step.tokensOut ?? 0); totalLatency step.durationMs ?? 0; } return { success: result.status completed, taskScore: result.status completed ? 100 : 0, toolSuccessRate: toolCalls.length ? toolSuccess.length / toolCalls.length : 1, avgLatencyMs: steps.length ? totalLatency / steps.length : 0, totalTokens, steps: steps.length, }; }现在computeMetrics里的 success 只判断状态没有做预期结果的匹配。真实实现里应该在运行器判断完 expected 之后把匹配结果传进来。这一步留给你的实际项目扩展关键是保持轨迹数据不随指标变化的原则。5.2 轨迹审查页面轨迹审查页面至少有三种视图列表视图按套件和用例列出所有运行记录绿绿红红一眼看出失败集中在哪个用例。时间线视图单个运行记录的步骤按时间展开模型推理、工具调用、工具结果依次排列任何一步耗时异常都容易发现。对比视图同一用例的新旧两次运行并排展示高亮模型推理差异、工具参数差异和结果差异。时间线视图最容易暴露问题。例如一个 Agent 在工具调用失败后反复重试时间线会连续出现五次相同的tool_call这比任何指标都直观。如果工具报错是 401说明权限配置有问题如果是参数校验失败说明 Agent 对参数理解有误。审查页面应该让这些信息第一眼可见而不是藏在日志里。5.3 回归对比和门禁判断回归对比的核心是找出从好变坏的用例。工作台可以把新旧两次运行的数据按case_id对齐生成一张差异表case_id旧版结果新版结果旧版步骤数新版步骤数差异判断order-001successsuccess34步骤增加可接受order-002successfailed2-回归必须修复order-003failedsuccess-3修复项确认有效性这里的门禁可以简单到一句话如果存在任何success - failed的用例且该用例标签不在豁免列表中则本次评测不通过。这个规则应该写进 CI 脚本防止新版 Agent 或者新提示词在修复 A 场景时弄坏 B 场景。6. 运行验证从命令行到本地 Web 工作台6.1 启动流程按以下顺序操作可以跑通最小闭环# 1. 初始化项目并安装依赖 npm install # 2. 初始化数据库 npm run init-db # 3. 将模型 API 密钥写入本地环境变量 export MODEL_API_KEYyour_key_here # 4. 运行评测集 npm run eval -- --suite suites/order-basic.yaml # 5. 启动本地审查服务 npm run review这里要特别提醒API 密钥不要写进评测集 YAML也不要提交到 git 仓库。评测集是团队共享的版本化文件密钥应该通过环境变量或本地的.env.local注入并且这个文件必须加入.gitignore。6.2 预期结果和验证方式第一次运行结束后你应该能看到类似下面的输出suite: order-basic cases: 2 passed: 1 failed: 1 success rate: 50.0% tool success rate: 100.0% avg latency: 820ms total tokens: 1840 report: reports/report.html但这只是第一步。要确认评测真的有效至少还需要验证三件事失败的用例点击轨迹后能看到具体的失败步骤而不是只看到一个 failed 状态。把同一个用例故意改成错误预期运行结果应该从成功变失败证明预期判断逻辑有效。连续运行三次同一评测集观察成功率波动范围。如果波动超过 20 个百分点说明用例设计或评测环境本身不稳定需要先解决稳定性问题。6.3 学习环境和生产环境的区别上面这套流程适合在本地快速验证想法。进入团队协作或生产环境后需要额外补上几块项目学习环境生产环境存储本地 SQLite 文件SQLite 文件加入版本管理或备份机制评测集手工编辑 YAML评测集变更走 MR 流程记录版本运行结果本地命令行在 CI 中运行结果上传为构建产物模型配置环境变量手动指定固定模型版本、采样参数写入配置快照人工审查本地 HTML 报告审查结果可注释、可标记、可追踪数据备份不必须定期备份数据库设置保留策略生产环境最关键的差异化动作是可追溯。一次发布对应的评测结果必须能关联到具体的代码版本、评测集版本、模型版本和运行时间。缺失任何一个出现线上问题时都无法回查。7. 常见问题与排查链路7.1 评测任务大面积失败现象同一个评测集大部分用例都返回 failed。排查顺序先看错误信息。如果所有失败都报 401、403通常是 API Key 无效或没有对应模型权限。再看超时配置。如果失败集中在某个工具调用步骤且每条轨迹都在同一工具处中断优先怀疑工具本身报错或网络不通。然后看预期判断方式。如果失败用例的轨迹正常完成但被判定失败检查expected.type是否和实际输出匹配。例如模型回复您的订单已发出而预期写死了已发货就会误判。最后检查评测集本身。如果用例输入格式和 Agent 训练数据差异过大失败是正常的需要调整用例设计。对应处理建议问题现象常见原因检查方式处理建议全部用例 401API Key 无效或无权限查看运行器日志的第一个错误重新配置环境变量并确认模型白名单全部用例超时模型或工具响应过慢查看轨迹中耗时最长的步骤增加单步超时时间或排查工具性能完成但判失败expected 写得太死打印实际输出对比预期配置改用 contains 或人工审查判断结果时好时坏采样参数或环境不稳定连续运行 5 次统计分布固定温度记录模型版本扩大样本量7.2 轨迹丢失或结果对不上现象metrics 表里有运行记录但 steps 表为空或者审查页面显示的成功数和 CLI 输出不一致。排查链路检查写入顺序。如果insertMetric不在insertRun和insertStep的同一个事务里先写指标后写步骤就容易出现只有指标没有轨迹的半截数据。检查异常处理。运行器 catch 到异常后是否仍然执行了持久化逻辑。如果异常发生在步骤还没有回调时直接跳到失败分支轨迹为空是正常的但如果你期望保留异常发生前已经记录的部分步骤需要在 catch 里显式维护steps数组。检查统计口径。CLI 输出的 success rate 是基于 runs 表统计还是基于 metrics 表统计。两个来源结果不一致时说明代码中有第二个统计入口应统一成一个函数。7.3 指标偏高或偏低的可信度问题现象本地跑成功率 90%但线上表现明显更差。原因通常不在评测代码而在评测设计评测集和调优数据重叠。如果评测用例来自 Agent 调优时见过的数据结果虚高属于数据泄漏。样本量太小。10 个用例只跑一次成功率 90% 意味着只有一个 fail置信度非常低。评测集难度失衡。大量简单用例撑高整体成功率掩盖了困难场景的问题。处理方式是分层看指标按 tag 统计成功率单独筛出edge-case类用例的结果而不是只看总体成功率。同时在报告中展示每个用例的单次结果不合并成一个数字。7.4 本地环境与 CI 结果不一致现象本地运行全部通过CI 里同一评测集大量失败。这是 Agent 评测最常见的环境问题之一。排查顺序对比模型版本。CI 里是否用了不同的 model 名称或 default 版本导致推理行为不一致。对比环境变量。CI 里是否缺少MODEL_API_KEY或使用了不同 key 导致速率限制。对比网络和依赖。CI 是否能访问模型 APIpackage-lock.json是否提交依赖版本是否已锁定。对比并发设置。本地顺序执行和 CI 并发执行可能触发速率限制或超时失败位置通常分布在tool_call步骤。预防做法是在评测配置中记录环境指纹模型版本、温度、top_p、依赖版本、Node 版本、关键环境变量的 hash。评测报告第一页就展示这些信息本地和 CI 不一致时先比对指纹。8. 评测工作台的最佳实践和扩展方向8.1 设计评测集的检查清单一个评测集在合并进工程之前应该逐条确认每个用例是否描述了一个完整用户场景而不是一个孤立的模型指令。预期结果是否站在用户可接受信息的角度描述而不是模型逐字输出。是否覆盖 happy path、edge case、异常输入、权限不足、工具失败五类基础场景。用例输入中是否包含真实业务敏感数据如果是是否做了脱敏。每个用例是否有明确的维护人需求变更时由谁更新评测集。评测集是否在独立目录下版本化管理和代码变更同步提交。8.2 发布前评测检查清单Agent 版本发布前建议依次确认评测集版本已固定和本次发布意图匹配。在固定模型版本和采样参数下完成至少三轮完整评测。新旧版本回归对比中不存在非豁免的success - failed用例。失败的用例都有轨迹可供人工审查且每一条失败原因已经被归类。指标统计同时包含结果指标和过程指标避免只汇报成功率。评测数据已备份报告已归档对应代码 commit 可追溯。8.3 扩展方向从最小工作台继续往下走有三个值得投入的方向。第一个是引入更丰富的判断方式。除了字符串匹配可以增加 LLM-as-judge让一个独立模型按评分标准判断结果质量并将评判断模型的结果也作为一条轨迹保存方便进一步审查。第二个是支持评测集和数据集的版本化。用 Git 管理 YAML 评测集是第一步第二步是给每个用例增加expected的变更历史让为什么这个用例被改弱了有据可查。第三个是把评测工作台接入日常开发流。本地运行只是调试手段真正能防止 Agent 退化的机制是 CI 门禁每次提示词变更或 Agent 逻辑变更都自动触发一轮回归评测把差别结果直接贴到 MR 里。做到这一步评测工作台就不再是一个辅助工具而是 Agent 工程化质量体系的一部分。Agent 评测的本质是给看起来智能的系统建立可验证的行为边界。Agent Review Studio 这类 local-first 工作台提供了一个正确的方向让评测数据留在本地让轨迹成为证据让差异可以被看见。先把最小闭环跑起来再用指标、轨迹和回归对比慢慢逼近真实业务的质量要求这才是评测体系能长期运转的方式。