企业级 AI 架构 · 番外：评测生产化（把"要测"变成"每天在测"）

企业级 AI 架构 · 番外：评测生产化（把"要测"变成"每天在测"）

系列番外篇。05 那篇"怎么知道 Agent 干得好不好"其实只讲了一半，它立住了"要评测"，没讲"怎么把评测变成每天在发生的事"。这一篇补上那半截，专门把"评测生产化"拆成四件你今天就能动手的事。照旧三方对照，并用付费包 harness-demo 里真实跑通的双 eval 作活标本。

呼应 00 总览的中央论点：把评测从"一次性考试"变成"每天在跑的工程"，是控制平面"验收机制"的常态化——验收标准始终写在模型之外，且可被 CI 反复执行。

---

开篇：为什么 05 篇没说完

05 篇结束时我们说过一句话："怎么知道 Agent 干得好不好？"——那是把评测第一次摆上台面。但如果你真把一个 Agent 推到生产环境，会发现 05 篇只回答了"要测"，没回答"怎么把测变成每天在发生的事"。

我们自己在付费包 harness-demo 里做的那步，恰好是这道鸿沟的缩影：Pi 侧和 DSH 侧各写了一组测试，断言"5 份样本 = 15 处命中"，都跑通了。它能证明规则引擎没错，却证明不了一件事——

当明天你改了三条规则、换了个模型、加了个新合同类型，你有没有一道闸门，能在合并代码的瞬间告诉你"质量退步了"？

这一篇，就讲这道闸门怎么造。它不追新模型，也不空谈 MLOps，而是把"评测生产化"拆成四件事：把样本养成为数据集、把断言升级为度量、把手动跑变成 CI 门禁、把"跑通"换成"业务可信度"。

---

本篇与付费包的已知局限（诚实清单）：① DSH 侧为 developer preview（v0.1.7-alpha.2），接口会破坏性变更，文中架构对照未做逐行复验；② 付费包 harness-demo 的「15 命中」仅证明规则引擎确定性逻辑，不证明 Agent 真帮用户审出了风险（呼应本篇 §五）；③ 评测集当前为 5 份正例 + 6 条反例（反例已于 2026-09-09 补齐，逐条断言零命中，构成"0 误报"门禁，呼应本篇 §二 ④ 点名的缺口），但样本量仍小、统计显著性尚未做（呼应本篇「统计显著性边界」）。以上不构成否定，而是把"我们验证了什么、没验证什么"摆清楚。

图：单测 → 集成 → 系统 → 生产，底层稳上层才可信。

一、WorkBuddy 的权威主张：评测是"持续工程"，不是"一次性考试"

Harness 五层里有一层叫反馈层（Feedback），解决"执行后怎么知道错了"；再往上是 Loop 层的传感器 / 评测（Evals）/ 停止条件 / 预算。WorkBuddy 把评测从"事后翻记录"提到了"运行时机制"，这个立场本身就指向一句话：

评测是持续工程，不是一次性考试。

证据在两层：

第一层，科研评测（Bench）。 WorkBuddy 团队联合发的论文（arXiv:2607.20911v1）做了个 260 题跨域基准，覆盖 Code / Web / Office / Security 四域。它最有价值的结论不是"谁分高"，而是三个反直觉发现——Harness 不是中性外壳（同模型换 Harness 排名可能对调）、没有全能王模型、Token 多 ≠ 分高。更关键的是它的评测对象变了：从"补丁 / 聊天答案"转向"最终可验证的工作区"，看交付物能不能用、能不能验证，而不是看它说了什么。

第二层，企业托管（Enterprise「评估测评」）。 在 Enterprise 里，评测被做成一项托管能力：量化 Agent 能力、结果可进 Admin 观测。也就是说，在 WB 的蓝图里，评测不是你本地跑个脚本，而是组织内一项可管理、可审计、可回溯的服务。（此属企业平台层：本地架构层经 WorkBuddy 5.3.13 文件级实证，企业平台层依腾讯云官方产品文档与企业版公告，性质不同，引用时请区分）

把这两层合起来，就能给"评测生产化"下一个可操作的定义，三特征缺一不可：

1. 数据集版本化——测什么，得是一份钉死版本的资产，不是口头说的"那几个例子"；
2. 跑在 CI / 流水线——评测是合并即触发的回归，不是"我本地跑过"；
3. 结果可追溯、可对比——这次 82 分、上次 85 分，差在哪、谁引入的，要能翻出来。

视角提醒（详见 00 总览 §六）：WorkBuddy 是单一厂商，以上评测主张请当作方法论之尺，而非跨厂商标准答案；落地请以你自家的多源验证为准。另，WB 评测的托管能力（Bench 260 题跨域基准、Enterprise「评估测评」）已有公开论文与官方文档佐证；文中凡涉及更深处（数据集公开格式、回归门禁具体机制），公开资料有限，均以 Enterprise 最新官方文档核对为准。

---

二、从 5 样本到评测数据集：Pi 侧怎么把 eval 做厚

光有定义不够。我们用 harness-demo 里真实存在的代码，演示"玩具样本 → 生产数据集"的演进。

现状长这样。规则引擎是一份纯函数（这是 04 篇"计算型优先"的范本，也是 03 篇"程序性知识"的落地）：

// harness-demo/pi/skills/contract-review/rules/engine.js
// 纯函数 · 单一事实源：Pi 扩展与 DSH 插件共用同一份引擎
export function loadRules(dir = resolve(__dirname, ".")) {
  // 用 __dirname 自定位规则目录，彻底摆脱对 process.cwd() 的依赖
  // （原实现依赖 cwd，cd 到别的目录即崩；现改为引擎自定位）
  ...
}
export function reviewClause(rules, params) {
  // 按 contract_type + clause_type 过滤，逐条 checkRule，返回命中数组
}

夹具里 5 份样本、各自带 expected，总数钉死为 15：

// harness-demo/pi/skills/contract-review/rules/fixtures.js
export const sampleCases = [
  { sample: "labor_contract_001.txt",       contract_type: "labor",       expected: 2, cases: [...] },
  { sample: "construction_contract_001.txt", contract_type: "construction", expected: 2, cases: [...] },
  { sample: "procurement_contract_001.txt",  contract_type: "procurement",  expected: 5, cases: [...] },
  { sample: "lease_contract_001.txt",        contract_type: "lease",        expected: 3, cases: [...] },
  { sample: "nda_001.txt",                   contract_type: "nda",          expected: 3, cases: [...] },
];
export const expectedTotal = 15; // 2+2+5+3+3

这步已经不弱：引擎确定、期望明确、Pi 与 DSH 两极同证同一份期望（这就是"eval 同证"——见 05 篇"把答案换成可验证工作区"）。但从"演示"到"生产"，还差四件事：

① 样本要覆盖边界，而不只是 happy path。 现在的 5 份都是"字段齐全、能命中"的正例。生产数据集必须补：缺字段的畸形条款、跨合同类型的混淆（把租赁条款喂给劳动规则看会不会误报）、以及"模型抽错了条款"这种输入噪声。

② 每条带 expected + 严重度标签。 现在只有"命中几条"。生产里你得知道命中的是 MUST（红线）还是 SHOULD（建议），漏报一条 MUST 和漏报一条 SHOULD，严重性天差地别。

③ 数据集单独 version，且与规则同版本钉死。 规则改了，期望就得跟着改，二者必须同一份版本号锁死——否则"15 命中"会变成没有意义的移动靶。

④ 加"不应命中"的反例（false-positive guard）。 这是最容易被漏的一步：只断言"该报的报了"，不断言"不该报的没报"。生产事故往往是误报淹没人——你得一列 expected: 0 的样本，专门守"别乱叫"。

断言本身也要升级：从"total === 15"这一个总数，变成逐条分别计数 命中 / 漏报 / 误报，并区分 MUST / SHOULD / 软约束。一句话：从"跑通了"变成"知道错在哪一类"。

---

图：15 命中（绿·防漏报）+ 0 误报（绿·防误报），任一红即阻断合并。

图：评测不是终点——上线门禁 / 回归基线 / 告警看板 / 产品决策，没有下游 = 一次性考试。

三、从手动跑到质量闸门：Pi 侧 CI 化

数据集养厚之后，下一步是让它"自己跑、且会拦人"。

harness-demo 的 Pi 测试现在是这样跑的：

// harness-demo/pi/test/contract-review.test.mjs
import assert from "node:assert/strict";
import { reviewClause, loadRules } from "../skills/contract-review/rules/engine.js";
import { sampleCases, expectedTotal } from "../skills/contract-review/rules/fixtures.js";

const rules = loadRules();
let total = 0;
for (const s of sampleCases) {
  let hits = 0;
  for (const c of s.cases) {
    hits += reviewClause(rules, { contract_type: s.contract_type, ...c }).length;
  }
  assert.equal(hits, s.expected, `${s.sample} 期望 ${s.expected} 命中，实际 ${hits}`);
  total += hits;
}
assert.equal(total, expectedTotal, `总命中期望 ${expectedTotal}，实际 ${total}`);

它不依赖 Pi 运行时、不需要 API key——node pi/test/contract-review.test.mjs 直接过。这已经满足"能回归"。生产化只差把它接进流水线：

• 每次 PR 必跑：命中数下降、或误报数上升，门禁直接红。改规则的人当场看见代价，而不是三个月后线上暴雷。
• Golden set 冻结 + 浮动集：核心案例（那 5 份 + 关键反例）钉死不可删；新样本先进"实验集"观察几轮，稳定了再晋升 Golden。这样数据集能长大，又不会被一次手滑冲掉地基。
• 报告可视化：别只 print("PASS")。把命中率 / 漏报率 / 误报率按版本画成趋势线，回归发生在哪一版、谁引入的，一眼可见。

实操边界：本仓库尚未建 GitHub 库，CI 配置先在你本机验证（本地跑即等价于一次手动回归）；建库后把上面这段接进 GitHub Actions 即可，无需改测试代码。

延伸：把"同证"做成双极对照
05 篇和本篇一直讲"eval 同证"——Pi 工具与 DSH 插件共用同一份 engine.js 与同一份 fixtures.js 期望（15 命中）。我们在付费包里把它显式做成了双极对照：直调确定性引擎 / DSH 插件入口（两者进程内共用同一引擎）各跑一遍，断言命中数一致（test/cross-harness.eval.mjs）；Pi 侧与 DSH 侧各自的 pi/test、dsh/test 再分别断言 15 命中 + 0 误报。这同时证明两件事：单一事实源真的跨框架成立，以及"评测即持续工程"不是空话，而是一道每次合并都替你跑的回归门禁。

---

四、DSH 侧怎么做：插件化的评测与 mock 闭环

Pi 侧是"共享引擎 + 直接调函数"。DSH 侧因为插件跑在 Cordis 运行时里，走的是另一条路——但同一份期望、同一份引擎，保证两极同证。

现状（写作时 DSH 为 developer preview / v0.1.7-alpha.2，仍为预发布）：

// harness-demo/dsh/test/contract-review.test.mjs
import { buildToolDefinition } from "../contract-review/index.js";
import { sampleCases, expectedTotal } from "../../pi/skills/contract-review/rules/fixtures.js";

const tool = buildToolDefinition();
// 直接调用插件的 execute，即"mock 工具返回"——
// 验证插件代码路径（除 LLM 外）与 Pi 侧同证同一份期望。
for (const s of sampleCases) {
  let hits = 0;
  for (const c of s.cases) {
    const out = await tool.execute({ contract_type: s.contract_type, ...c });
    const parsed = out.startsWith("[") ? JSON.parse(out) : [];
    hits += Array.isArray(parsed) ? parsed.length : 0;
  }
  assert.equal(hits, s.expected, `${s.sample} 期望 ${s.expected} 命中，实际 ${hits}`);
}
assert.equal(total, expectedTotal, `总命中期望 ${expectedTotal}，实际 ${total}`);

它不依赖 DSH 运行时、不需要 API key——把 LLM 的部分用 execute 直接 mock，断言的还是那 15 命中。这就形成了一个干净的开发闭环：你改插件代码，本地一跑就知道有没有破坏断言，不必每次都烧 token 调模型。

但 mock 只是开发态。要把它推到生产态，DSH 的插件机制恰好能挂"评测工具"：

• mock → record-replay：第一次用真实 LLM 跑，把工具调用轨迹落盘；之后回归用落盘的轨迹回放，既快又确定，还能捕获"模型这次抽条款抽歪了"这类输入漂移。
• eval 工具进 session：通过 cordis.patch.yml 把 eval 工具插进 session（写法见 harness-demo/dsh/contract-review/make-patch.mjs，工具插入行用本机绝对路径，model / session / sandbox 三处为模板占位，需 dsh --profile web --dump-config 查真实 id 替换）。

版本提醒：DSH 目前是 developer preview（写作时 v0.1.7-alpha.2，非 GA），接口会破坏性变更；真跑用 npx @deepseek-ai/dsh web 起本地 Web UI（CLI 语法以当天 --help/官方文档为准），并配 key。v0.1.2-rc.1 起 DSH 还接入了多模态模型 DeepSeek-V4-Flash-Vision-Exp（该模型已在 v0.1.6-alpha.2 移出默认模型列表，V4.1 Flash 仍在），模型阵容随版本演进、以官方为准。本文描述的是架构对照，不承诺逐行跟跑——这也是 00 总览已声明的时效点。

---

五、度量什么：从"命中数"到"业务可信度"

到此我们解决了"能回归、能拦人"。但有个更深的坑要提醒：eval 跑通 ≠ 质量好。

"15 命中"证明的是规则引擎的确定性逻辑没错，不是 Agent 真帮用户审出了风险。要把评测推进到生产级，度量对象得换：

• 任务成功率，不是 token 命中数——用户的目标是"这份合同有没有坑"，不是"规则触发了几条"；
• 事实一致性 / 幻觉率——引用的条款、法条、金额，是否真在原文里；
• 安全违规率——有没有泄露、越权、产出违规内容；
• 单任务成本与延迟——呼应 06 路由、08 性能，评测必须带成本维度（这也正是 09 新补的 FinOps 视角）；
• 人工抽检一致率——自动评和人工评差多少，是评测本身可信度的校准。

还要分双轨：

• 离线（批量回放）：拿历史 / 构造数据集跑，快、可回归，适合门禁；
• 在线（影子 / A-B / 生产轨迹回收）：拿真实流量的一小部分跑，测的是"真实分布下的表现"，是离线永远测不到的。

最后是一个评测飞轮：生产 trace → 提炼成新 case → 数据集长大 → 门禁更严 → 又捕获更多边界。评测不是一次性建好的塔，而是跟着生产一起转的轮子。这恰恰呼应 WB 那句「持续工程」。

统计显著性边界：单次回归的分差，要先看是否超出置信区间（或做配对 bootstrap / McNemar 检验），再决定是否回滚或切换模型。新 73% 对旧 70% 这种量级的差，通常不足以作为切换依据；建议每个配置跑 3–5 个随机种子、多重比较时收紧阈值。这与前面「eval 跑通 ≠ 质量好」是同一工程伦理的两面：一个防假阳性（误把噪声当退化），一个防假阴性（误把跑通当质量）。

---

六、三方对照 + 下篇预告

把四件事并排，WB / Pi / DSH 在"评测生产化"上的分工就清楚了：

维度	WorkBuddy（方法论之尺）	Pi（harness-demo 示范）	DSH（dev preview 示范）
数据集	Bench（科研）+ Enterprise 托管	你自建 fixtures.js（本篇示范演进）	插件化 eval 工具
回归门禁	Enterprise「评估测评」	纯函数测试 + CI（本篇示范）	mock / record-replay + patch
断言粒度	任务级能力量化	命中 / 漏报 / 误报 分计	同左（共用同一引擎）
在线评测	Admin 观测 + 评估	需自建（趋势报告）	需自建（session 轨迹）
溯源	全程留痕	测试报告	插件轨迹 + append-only log

速记一句话：评测生产化的本质，是把"我觉得它行"变成"有一道门禁在每次合并时替我说不"。WorkBuddy 用托管能力把它产品化，Pi 用纯函数 + CI 把它做轻，DSH 用插件机制把它嵌进运行时——三者殊途同归，都在把"评测 Agent"从玄学变成工程。

下篇预告：生产化深度——可用性 / 故障 / 审计 / 数据治理。这是"企业级"四短板里最后一块（四短板＝单一厂商透镜〔已在 00 总览 §六 处理〕＋ FinOps〔已在 09 企业级落地 §二 处理〕＋ 评测生产化〔本篇〕＋ 生产化深度〔下篇〕），留作第二季或后续番外的素材。

---

相关阅读（系列互链）

本篇是【企业级 AI 架构】技术深轨，与公众号《AI思想的东方注脚》哲学引子、本体智能 / FDE 系列同源联动——同一观点不重复讲，按兴趣深潜：

• 《可观测与评测：怎么知道 Agent 干得好不好》（企业级 AI 架构·篇5）——番外是它的工程化延伸，建议先读主体
• 《四大行业已算出 ROI：本体智能的 4 个真金白银场景》（本体智能·篇6）——评测指标最终要对得上 ROI

---

AI评测 #评测生产化 #CI门禁 #企业级AI

配套付费包：「最小可运行双框架工程 harness-demo」已做成付费交付物。Pi 侧可本机无 key 完整跑通；DSH 侧以一手文档核对 + mock 测试同证，真跑需自备 DSH 运行时与 key。DSH 插件与 Pi 共用同一份规则引擎与规则，内置「5 正例 + 6 反例」双向门禁评测（15 命中 + 0 误报）。获取方式见公众号菜单。

关注公众号「农夫三拳有点癫」，第一时间读到本系列更新。