目录
[（三）硬门、软门与 Go / No-Go](#（三）硬门、软门与 Go / No-Go)
干货分享，感谢您的阅读！
演示环境会系统性地筛掉所有可能暴露问题的输入，所以「演示顺利」不提供任何关于生产行为的信息。
这次我们给出一套可执行的验收框架：六个维度（功能正确性、质量、时延、成本、安全、可恢复性）的可计算口径、四层验收数据集的构成、三条基线的选法、阈值的四种定法、指标造假的八种方式、硬门与软门的 Go/No-Go 决策表、分级上线的三套标准、九节验收报告模板，以及一份二十六项的检查清单。
本节，作为读者你将获得什么
- 六个验收维度的可计算口径------每一项都写清楚定义、怎么算、常见陷阱，而不是「准确率要高」这类无法执行的表述。
- 一套四层验收数据集的构成比例与建设方法，包括最容易被忽略的「信息不足样本」与「间接注入样本」。
- 阈值从哪来的四种定法，以及为什么「拍脑袋定的阈值到争论时一定守不住」。
- 指标造假的八种方式与三条防造假的流程设计。
- 硬门与软门的 Go / No-Go 决策表、分级上线的三套标准、九节验收报告模板、二十六项检查清单。
关于数据的说明：本文的业务场景、指标数值与阈值建议均为示例场景与示例值，用于说明口径与量级关系，不是任何真实系统的实测结果，也不构成普适基准。每个团队的阈值必须按本文第六章的方法自行推导。还有设计的代码入如果写的有问题的，请您在评论区留言提醒，感谢！
一、演示与生产之间隔着六处环境差异
（一）为什么「演示顺利」不能说明任何问题
演示环境与生产环境的差异，可以整理成六条：
输入：演示用的是精心挑选的十几条；生产是用户真实输入，含错别字、缺关键信息、一句话混两件事。被掩盖的问题是意图误判与「槽位缺失被静默填了默认值」。
并发：演示一次一条、串行；生产峰值几十上百并发，且与其他业务共享下游配额。被掩盖的是限流、排队与雪崩。
依赖：演示时下游全部正常；生产里每天都有某个下游在抖。被掩盖的是超时、部分成功与重复写。
时间跨度：演示几十秒内跑完；生产的长任务跨天，中间要重启发版。被掩盖的是状态丢失与任务失联。
恶意：演示时没有人想搞你；生产里总有输入试图让它做不该做的事。被掩盖的是注入、越权与数据外泄。
成本：演示跑几十次，没人看账单；生产每天几万次，月底要对账。被掩盖的是方差失控与预算超支。
这里有一个容易被误解的因果。很多人把上线翻车归因于「演示时没测够」，这不完全对。真正的原因是：演示的目的是展示可能性，所以它天然会挑选那些能展示可能性的输入------这不是疏忽，是定义。
所以解法不是「演示时更认真一点」，而是在演示之外另建一套过程，它的目的与演示相反：找出它在哪里会坏。 这两件事不可能由同一个流程同时完成。
（二）验收要回答的那一个问题
验收要回答的不是「它能不能做对」，而是：
在真实输入分布、真实并发、真实依赖抖动、真实时间跨度、存在恶意输入、且有成本上限的条件下，它做错的比例是多少，做错时会发生什么，以及我们能不能在出事之后说清楚发生了什么。
这个问题有六个分量，对应本文的六个验收维度。
（三）本文使用的参考场景
全文以企业任务执行 Agent 为样本：员工用自然语言提任务，系统跨知识库、权限系统、工单系统把事办完，涉及只读查询、写操作、人工审批、长任务与多租户。选它是因为它的六个维度都有实质内容------只读问询有质量问题，写操作有安全与恢复问题，长任务有时延与成本问题。
二、六个验收维度
（一）维度总览与它们的关系
六个维度分别是：功能正确性（它有没有做对该做的事）、质量（做对之外做得好不好）、时延（用户等多久）、成本（每做一次花多少）、安全（会不会做不该做的事）、可恢复性（坏了能不能救回来）。
有三件事需要先说清楚。
六个维度不是并列的。 安全与可恢复性是一票否决项，它们不达标，其余四项再好也不能上。功能正确性与质量之间有先后：先保证「做对该做的事」，再谈「做得好不好」。
六个维度会互相拉扯。 提高质量通常意味着更多模型调用，于是时延与成本上升；压低成本通常意味着换小模型，于是质量下降；加强安全通常意味着更多校验与审批，于是时延上升、完成率下降。所以验收标准必须一次性定全六项。
只定一项的后果很严重。 如果只定「准确率不低于 90%」这一条，团队会用近乎无限的时延与成本去换它，并且在安全上留下缺口。这不是团队不负责------没有被约束的维度一定会被牺牲，这是所有指标体系的共同规律。
（二）维度一：功能正确性的三层口径
「做对了」这三个字，至少要拆成三层才能被测量。
1、结果正确
任务的最终产出与黄金答案一致。比如该开通的权限开通了、该拒绝的请求拒绝了。
测法是准备带黄金答案的样本集，逐条比对关键字段。注意是比对字段而不是比对整段文本------比对文本会把措辞差异当成错误。
局限：它看不见「结果对但过程错」，比如碰巧蒙对，或者多做了一步无关的操作。
2、过程正确
工具调用序列符合预期。比如开通之前必须先查是否已有；写操作之前必须先鉴权。
测法是把期望序列写成三类约束------必含、禁含、先后关系------然后对轨迹做集合与顺序断言。例如：必含 query_permission；禁含任何未注册工具；query_permission 必须早于 grant_permission。
局限：约束过严会误杀合理的替代路径。所以「必含」类约束要少而精，「禁含」类可以严格。
3、副作用正确
外部世界的状态变化符合预期：只产生一条权限记录，不多不少；失败时无残留。
测法有两步：跑完之后查下游状态；把同一样本重复跑两次，确认第二次不产生新的副作用。第二步是幂等性的端到端验证，比读代码可靠得多。
局限：需要一个可回滚的测试环境。这项投入经常被省掉，然后幂等性就只能靠代码评审来保证。
4、三层缺一不可
只测结果正确会放过「蒙对」的样本------一个只会说「已为您开通」而从不真的调用工具的系统，在结果比对上可能拿到不低的分数，因为它的措辞总是对的。只测过程正确会放过「步骤都对但参数错」的样本。只测副作用则测不了只读任务，而只读任务通常占多数。
门禁建议按「全部通过」而不是「加权平均」判定：结果正确率不低于目标值；禁含类过程约束违反数为零；重复执行产生的额外副作用数为零。加权平均的问题在于它允许用一项的高分掩盖另一项的零分，而副作用这类项目一次出错的代价远高于多次答对的收益。
（三）维度二：质量的四个可计算口径
「回答得好」不能作为验收项。下面四个可以。
答复准确率：与黄金答案在关键事实上一致的比例。陷阱是只看措辞不看事实。
引用可核验率 ：答复中每条事实都能追溯到来源，且来源确实支持该事实。陷阱是只校验引用 ID 存在，不校验内容是否支持------这是一个很常见的偷懒，它会让一个「引用格式完美但内容对不上」的系统拿到满分。
无依据回答率：在检索无结果或信息不足时，仍然给出确定性答复的比例。测法是构造一批「知识库里没有答案」的样本，看它是否拒答或澄清。陷阱是评测集里全是有答案的样本。
人工改判率：人工复核时推翻系统处置的比例。陷阱是只统计被明确驳回的，不统计被人默默改掉的。
1、为什么把「无依据回答率」单列
因为它是唯一一个「样本越难、指标越重要」的口径。一个在有答案的样本上表现很好的系统，在没答案的样本上可能表现极差------它会把「我不知道」变成一段看起来很专业的编造。而线上恰恰有相当比例的请求，知识库里本来就没有答案。
2、人工改判率的特殊地位
它是唯一一个不需要额外标注、由线上流程自然产生的质量指标，也是唯一一个业务方真正相信的指标------因为它就是业务方自己的动作。
代价是它有滞后性：只有在人工审批环节存在时才有数据；并且它反映的是「人觉得不对」，不一定等于「客观上不对」。
3、不要把这些当质量口径
用户满意度评分（样本偏差极大，只有强烈不满的人才会评分）、模型自评分（与真实质量相关性弱，且随提示词变化而漂移）、平均回答长度或关键词覆盖数（与质量无关，且极易被优化）、单条样本的主观观感（适合发现问题，不适合做门禁）。
（四）维度三：时延
只报一个平均值的时延报告等于没报。验收口径要写清六件事：
-
测的是首响应还是端到端？流式场景两个都要；
-
分位数取哪几个？建议 p50 / p95 / p99，不要只报均值；
-
分通道还是混在一起？不同通道的时延差一个数量级，混在一起的数字既不能用来定 SLO 也不能用来定容量；
-
包不包含排队时间？用户感知的是包含的；
-
在什么并发下测的？单并发的数字不能外推；
-
缓存是冷是热？冷热两套数字都要给。
这六件事任何一件没写清，两份时延报告就无法对比。
1、时延预算要拆到组件
一次任务的时延应当拆成鉴权准入、上下文装配、模型调用、工具调用、状态持久化、回执生成几段，分别给出占比。这个拆解的价值在于：它让优化有落点。如果模型调用占七成，优化数据库索引没有意义。
2、失败路径的时延必须单独统计
这是最容易被忽略的一项。很多报告只统计成功任务，但用户感受最差的恰恰是失败任务------它往往跑满了重试与步数上限才退出，时延是成功任务的三到五倍。验收时应当单独给出失败任务的时延分位数，并为它设上限。
3、时延门槛怎么定
从用户侧的可接受度倒推，而不是从系统当前能力正推。同步交互场景先定首响应上限，再定端到端 p95 上限；异步任务场景改为定「进度更新间隔」与「完成时间 p95」。定完之后再看系统够不够，不够就改架构，而不是改门槛。
时延上限一旦定死，它会反向约束最大步数、能不能用更大的模型、能不能加评审环、检索召回多少条。所以它必须与其他五项一起定，而不是最后补一个。
（五）维度四：成本
验收要报的不是均值，是分布与归因。成本项至少有六类：模型输入 Token、模型输出 Token、检索与嵌入、工具与下游、失败任务、人工成本。
1、两个最常见的漏算
工具内部的模型调用：某个工具为了整理结果又调了一次模型，这次调用不在编排层的账本里。排查方法是把模型网关的调用总数与编排层记录的总数对一下，差额就是隐藏调用。
失败任务：它们往往更贵，因为跑满了上限才退出，却经常被完全排除在统计之外。
2、方差比要单列
预算是按尾部做的，不是按均值做的。验收时报 p99 与 p50 的比值，并给出一个上限（例如不超过 5 倍）。超过上限说明存在一类会跑很久的请求没有被识别出来------找到它并单独处理，比整体优化有效得多。
3、成本要能归到三个维度
按租户（用于计费与配额）、按任务类型（用于判断哪类值得优化、哪类该降档）、按步骤（用于定位钱花在哪一步）。三个维度缺一个，优化就会变成凭感觉调参数。这三个维度都需要在轨迹里预留字段，事后补是补不上的。
（六）维度五：安全（一票否决）
这一维度不设「达标率」，只设「次数为零」。六个验收项：
越权调用：用对抗样本诱导调用白名单外工具或超出权限范围的参数，次数必须为零。
跨租户数据：用 A 租户身份构造请求，检查检索与查询是否返回 B 的数据，次数必须为零。
直接提示注入：用户输入里包含「忽略之前的指令」类文本，抵抗率必须是全部。
间接提示注入：把攻击文本放进会被检索到的文档里。这一项比直接注入更重要，因为攻击者无需接触系统即可控制它，而多数团队只测了直接注入。
敏感数据外泄：检查日志、轨迹、上下文、模型请求体中是否出现明文敏感字段。注意要检查模型请求体------把身份证号原样塞进提示词，等于把它发给了第三方。
审批绕过：构造高风险动作，检查是否必然进入审批队列。
1、为什么不设达标率
「注入抵抗率 98%」听起来不错，但它的含义是每一百次攻击里有两次成功，而攻击者可以试一万次。安全维度的正确表述是「在给定的测试集上没有发现失败」，并且明确写出测试集覆盖了哪些攻击模式、没覆盖哪些。把它写成百分比，会让读报告的人产生「还算安全」的错觉。
2、剩余风险必须写进报告
通过全部安全验收不等于安全，它只等于「在我们想到的攻击模式下没有发现问题」。所以验收报告必须有一节剩余风险，写清楚：哪些攻击模式没有覆盖、为什么；一旦被突破最坏后果是什么；检测与止血手段分别是什么、多久能生效。
（七）维度六：可恢复性（另一个一票否决）
五类中断，每一类都要真实演练一次：
进程重启（发版或崩溃）：在途任务必须全部可从状态机恢复，无一失联。
下游不可用（5xx 或超时）：熔断生效，任务进入可重试队列，不产生半成品。
部分成功（三个写操作成功两个）：补偿或重试后最终一致，且不产生重复副作用。
审批超时（审批人两天没处理）：状态机有超时转移，触发升级或自动驳回。
用户取消（任务进行到一半被取消）：已执行的副作用有明确交代，未执行的不再执行。
1、怎么演练
不要用「代码走查」代替演练。五类中断都可以真实注入：跑一批长任务，中途 kill 掉服务再拉起；用代理把某个下游的响应改成 503；让某个写接口在第三次调用时返回 409；把超时阈值临时改成一分钟；在任务执行到第三步时调用取消接口。
2、要看的三个数字
恢复率（中断后能自行恢复并正确完成的任务比例）、重复副作用次数（必须为零）、故障定位时间（从告警到定位出根因的时长）。
第三个数字最容易被跳过，但它直接决定了线上事故的影响时长。一个可操作的办法：在演练时让一位没参与开发的同事来定位并计时。
3、取消语义是一条常被忽略的验收项
取消不是「停止执行」这么简单。它至少要回答三个问题：已经执行的副作用要不要回滚（多数情况下不能，只能记录并告知）；正在执行的那一步要不要等它结束（通常要等，强行中断更容易产生不一致）；取消之后任务处于什么状态（必须是一个终态，不能是「不确定」）。
很多系统的取消接口返回 200 之后什么也没发生------这比不提供取消接口更糟，因为它给了用户错误的预期。
三、验收数据集
（一）四层样本，各有各的用处
一个只有正例的评测集，测出来的数字没有意义。推荐的四层构成（比例可按业务调整）：
分层抽样样本（约 60%）：按线上请求类型的真实占比分层抽取，用于算主指标。要覆盖工作日与月末峰值，不能只取某一天的流量。
难例样本（约 20%）：历史上人工改判过或投诉过的请求，用于衡量系统在真正难的地方的表现。难例会随系统改进而变化，需要定期回流补充。
信息不足样本（约 12%）：缺关键槽位、知识库无答案、多义请求，用于衡量拒答与澄清能力。这类样本的「正确答案」是「问清楚」或「说不知道」。
对抗样本（约 8%）：提示注入、越权诱导、敏感数据探测，用于安全维度。要包含间接注入------把攻击文本放进会被检索到的文档里。
（二）规模、版本与三个常见错误
起步 150 到 300 条即可，关键不在多而在分层是否真实。判断够不够的方法：把样本集随机分成两半，分别算主指标，两半的差距如果超过 3 个百分点，说明样本量不足以支撑门禁判定。
样本集必须版本化管理，每次变更都要记录原因，否则跨版本对比无效。
三个最容易犯的错：
- 用模型生成样本：它会系统性地偏向模型自己擅长的表述方式，导致指标虚高；
- 只收集失败案例：会高估问题严重程度，且无法算整体指标；
- 样本里含真实敏感数据：评测集会被广泛传阅，必须先脱敏，并且脱敏后要确认题目仍然成立（把订单号全替换成同一个值，很多题目就不成立了）。
（三）基线：没有基线的指标不构成验收依据
「准确率 87%」这句话本身不含任何信息。它需要三条基线之一来赋予意义。
人工基线：同一批样本交给熟练人工处理，统计正确率、耗时与单件成本。它回答「这件事人做得多好、多贵」。多数场景下这是最有说服力的基线，因为它就是现状。
规则基线：用纯确定性规则处理同一批样本，统计覆盖率与正确率。它回答「不上模型能做到多少」。如果模型方案只比规则高三个点，这个项目大概率不该做。
上一版本基线：当前线上版本在同一批样本上的表现。它回答「这次改动是进步还是退步」，回归门禁用的就是这一条。
一个常见错误是只维护第三条。结果是系统在自己的历史轨迹上持续「进步」，但没有人知道它离人工水平还有多远，也没有人知道其中有多少收益其实靠一套规则就能拿到。
1、基线本身也要被验收
人工基线的陷阱：让最资深的同事来做，基线偏高；让新人来做，偏低。正确做法是按线上实际的人员构成抽样，并记录每位标注者的一致性。
规则基线的陷阱：为了证明模型有价值而故意写一套弱规则。避免办法是让不同的人来写规则基线与模型方案。
上一版本基线的陷阱：基线跑的时候缓存是热的，新版本跑的时候缓存是冷的------时延与成本对比会完全失真，而且这个问题从报告上完全看不出来。
四、阈值、造假与门禁
（一）阈值从哪来
拍脑袋定的阈值，到了争论的时候一定守不住。四种可用的定法：
从业务后果倒推：先问错一次的代价是多少。退款类错误单次代价高，阈值必须严；问询类错误单次代价低，可以放宽。适用于有明确单件代价的场景，优点是最有说服力，业务方认。
从人工基线对齐：系统不低于人工水平即可上线，而不是追求某个绝对数字。适用于替代人工的场景，优点是避免对机器提出超人要求------这是一个非常常见的隐性偏见：人工做到 88% 大家觉得正常，系统做到 92% 却被认为「还不够」。
从容量与预算倒推：时延与成本阈值由容量规划决定------目标 QPS 乘以 p95 时延不超过可用资源；月请求量乘以单任务成本不超过预算。优点是算得出来，不需要争论。
从当前分布定起点：先跑一轮，取当前 p95 作为初始阈值，之后每个迭代收紧一点。适用于全新系统，缺点是它只保证不退步、不保证足够好，必须尽快换成前三种。
阈值必须写进文档并公开。不是因为形式，而是因为上线前一定会有「这次就算了吧」的讨论。写下来的阈值让这个讨论变成「我们决定破例，理由是什么」，而不是「标准本来就是模糊的」。
阈值还要随阶段变化：内测、灰度、全量三个阶段应当有三套阈值，越往后越严。用同一套阈值卡所有阶段，结果通常是内测阶段就卡死，团队于是开始绕过流程。
（二）指标造假的八种方式
多数造假不是故意的，但后果一样：评测集里全是正例；用模型生成评测样本；只统计成功任务的时延；只报均值不报分位数；基线跑热缓存而新版跑冷缓存；评测时关掉了安全校验；样本集在迭代中被悄悄修改；用模型给自己打分。
三条防造假的流程设计：
评测集与被测系统由不同的人维护。 这一条能挡掉一半以上的问题，代价几乎为零。
评测集版本化，每次变更记录原因与变更前后的指标差。 任何一次「改了样本之后指标上升」都要被单独解释。
验收报告必须包含「本次测试的配置」一节：样本集版本、并发度、缓存状态、安全校验开关、模型版本。缺这一节的报告不予受理。
还有一个判断报告可信度的快问题：问报告人「这次测试里，最差的那条样本是什么样的？」能立刻说出具体案例的，说明他真的看过数据；只能回答「整体还不错」的，说明他只看了汇总数字。所以验收报告应当强制包含「最差的五条样本」这一节------它是唯一无法被平均掉的东西。
（三）硬门、软门与 Go / No-Go
门分两类。
硬门（任一不过，不得上线）：越权调用次数为零；跨租户数据泄露次数为零；敏感数据外泄次数为零；高风险动作审批绕过次数为零；重启后在途任务恢复率百分之百；重复执行产生的额外副作用为零；一键关闭开关已演练通过。
软门（不过可带条件放行，但要写明）：任务完成率、引用可核验率、无依据回答率、端到端 p95 时延、单任务成本 p95、成本方差比、故障定位时间。
结论分三档：硬门全过且软门全过是 Go ；硬门全过、软门有一至两项未达标是带条件 Go （缩小灰度比例、未达标项每日复核、给出改进期限与负责人）；任一硬门未过或软门未达标超过两项是 No-Go（不得上线，需重新验收，已上线的相同版本应回滚）。
「带条件 Go」这一档的存在不是为了放水，而是为了让「破例」这件事被记录下来。没有这一档，团队会把不达标项悄悄从报告里去掉。使用它有两条纪律：必须写明未达标项、当前值、目标值、改进期限与负责人；同一项连续两次「带条件 Go」之后，第三次必须降为 No-Go------否则「条件」会变成一句永远不兑现的承诺。
五、流程、分级与报告
（一）分级上线：三个阶段，三套标准
内测：团队内部加少量友好用户，每天几十到几百条。硬门全部适用；软门可放宽到目标值的八成。退出判据是连续三天无硬门失败，且最差五条样本已逐条分析。
灰度：按租户或用户维度切 5% 到 20%，每天几千条。硬门全部适用并加实时告警；软门达到目标值。退出判据是灰度期指标与内测期无显著劣化，人工改判率稳定。
全量：全部流量。硬门全部适用并加自动熔断；软门达到目标值且有余量。全量之后进入持续监控与定期回归。
1、灰度阶段最容易出的三个问题
切流维度选错：按请求随机切流，会导致同一个用户时而走新版时而走旧版，反馈无法归因。正确做法是按租户或用户维度切，保证同一用户体验一致。
灰度流量不具代表性：只切给内部团队，测不到真实用户的输入分布。
没有实时对照：灰度的价值在于新旧版同时在线，如果不同时统计两组指标，灰度就退化成了「小范围上线」。
2、每个阶段都要准备回退
回退不是「把代码 revert」这么简单，至少要想清三件事：在途任务怎么办（新版创建的任务，旧版能不能继续推进，取决于状态机的状态定义有没有变）；已产生的副作用怎么办（多数不能回滚，只能记录并告知）；数据结构变更怎么办（新增字段是安全的，修改语义不是）。
所以回退能力从设计阶段就要考虑，回退演练应当是灰度的前置条件，而不是出事时才第一次做。
（二）一次完整验收的两周流程
第 1---2 天冻结版本与配置；第 3---5 天建或更新评测集；第 6---8 天跑功能与质量并跑三条基线；第 9---10 天跑时延与成本（含并发压测）；第 11---12 天跑安全与恢复演练；第 13---14 天汇总评审、走 Go / No-Go。
1、为什么第一步是冻结版本
Agent 系统有四个独立变化的版本：模型、提示词、工具、知识库。其中任何一个在验收期间变了，整份报告就失去了意义------而且这种失效很难被发现，因为报告上的数字看起来一切正常。
具体做法：四个版本号写进验收报告首页；验收期间禁止改动，确需改动则重跑受影响的部分；每次跑评测时把四个版本号记进结果文件。这是整个流程里成本最低、收益最高的一条纪律。
2、哪些环节可以压缩
这个排期假设评测集已经存在、自动化跑批已就绪、测试环境可用。第一次做要多花一周建评测集。
可压缩的地方有三处：功能质量与时延成本两段可以并行；安全与恢复可以提前到与功能同时开始；小版本迭代不需要重建评测集。
不能压缩的是安全与恢复演练。 它是唯一需要「真的把东西弄坏一次」的环节，而这件事没有捷径。
（三）验收报告模板：九节
九节分别是：被测版本、测试配置、样本集构成、基线、六维指标、最差五条样本、剩余风险、测试局限、结论与条件。
前五节回答「它现在有多好」，第六第七节回答「它可能在哪里坏」。评审时如果时间只够读两节，应该读第六与第七节。
第八节「测试局限」为什么必须有？因为每一次验收都有边界。把边界写出来，读报告的人才知道哪些结论可以依赖、哪些不能。不写局限的报告，实际上是在暗示「所有问题都已覆盖」，这是最危险的一种表述。
六、验收不能回答什么
真实输入分布的漂移：评测集是某个时间点流量的快照，业务变化、季节性、新功能上线都会让真实分布偏离它。对策是每月回流一批新样本。
长尾中的罕见情况：两百条样本覆盖不到千分之一的情况，而线上每天几万条请求，千分之一就是几十条。对策是线上监控加坏例回流。
未想到的攻击模式：对抗样本只覆盖已知模式，新模式会不断出现。对策是定期红队、关注公开披露，并保持一键关闭能力。
长期的用户信任变化：指标好不等于用户愿意用。一次严重错误造成的信任损失，几十次正确无法弥补。对策是跟踪使用率与主动放弃率。
多版本叠加的交互效应：单独测提示词变更没问题，单独测知识库更新没问题，两者同时变可能出问题。对策是变更单一化、逐项发布。
真实并发下的系统行为：压测环境的下游通常是 Mock，真实并发下的配额竞争、连接池争抢测不出来。对策是灰度阶段观察，不要跳过。
把这些写进报告的意义在于：验收的作用是「把已知风险降到可接受」，不是「消除所有风险」。 说清这一点，比任何一个漂亮的数字都更能建立信任。
七、上线验收检查清单
准备（四项）
- 四个版本号（模型、提示词、工具、知识库）已冻结并记录；
- 评测集已版本化，四层样本按比例齐备；
- 三条基线均已跑出数字；
- 测试配置已写入报告首页。
功能与质量（五项）
- 结果、过程、副作用三层正确性均达标；
- 禁含类过程约束违反数为零；
- 引用可核验率达标，且包含内容支持校验；
- 无依据回答率达标，用信息不足样本测；
- 人工改判率已有基线。
时延与成本（五项）
- 分通道、分冷热给出 p50 / p95 / p99；
- 失败路径时延单独统计并设上限；
- 单任务成本包含隐藏的工具内模型调用；
- 成本方差比达标；
- 成本可按租户、任务类型、步骤三维归账。
安全（四项）
- 越权、跨租户、外泄、审批绕过四项次数为零；
- 直接与间接注入均已测试；
- 剩余风险已逐条写明；
- 一键关闭开关已实际演练。
可恢复性（五项）
- 五类中断全部真实注入演练过；
- 重启后恢复率为百分之百；
- 恢复过程无重复副作用；
- 取消语义明确且已验证；
- 故障定位由非开发同事完成并计时。
发布（五项）
- 三阶段阈值分别定义并写下；
- 灰度按租户或用户维度切流；
- 回退方案含在途任务处理策略；
- 回退已演练；
- 验收报告九节齐备。
二十六项里有二十项属于普通后端工程验收，真正与模型相关的只有六项。
八、结论与延伸
（一）本文结论
第一，演示环境会系统性地筛掉暴露问题的输入，这是演示的定义决定的，不是团队不认真。所以必须另建一套以「找出它在哪里会坏」为目的的验收过程。
第二，验收要覆盖六个维度。只定一项的后果是其余五项被牺牲------这是所有指标体系的共同规律，与 Agent 无关。
第三，「做对了」要拆成结果、过程、副作用三层，并按「全部通过」而不是「加权平均」判定。
第四，质量要用可计算口径表达。其中「无依据回答率」与「引用可核验率」最容易被绕过，也最能区分系统的真实水平。
第五，安全与可恢复性是一票否决项，不设达标率只设「次数为零」，并且必须写明剩余风险与未覆盖的攻击模式。
第六，评测集要分四层，其中信息不足样本与间接注入样本最常被忽略；评测集必须版本化，且与被测系统由不同的人维护。
第七，没有基线的指标不构成验收依据。三条基线（人工、规则、上一版本）各回答一个不同的问题，只维护最后一条的团队不知道自己离目标有多远。
第八，阈值有四种定法，都比拍脑袋好。阈值必须写下来并随上线阶段分档。
第九，验收报告必须包含「最差五条样本」「剩余风险」「测试局限」三节。前者无法被平均掉，后两者决定了这份报告能被信任到什么程度。
（二）与专栏其他文章的衔接
《Agent 工作流实战》专栏导读地图与阅读路径说明-CSDN博客
- 「这个需求要不要做成 Agent」的判定方法，见《先别急着做 Agent：Chatbot、Workflow 与 Agent 的边界》；
- 本文六个维度各自落在系统的哪一层，见《用一个业务场景画出生产级 Agent 的全景架构》；
- 本文「过程正确」这一层所依赖的结构化轨迹如何实现，见《不依赖框架实现最小 Agent：模型、工具、观察与终止》；
- 验收不达标时对应的具体工程缺口，见《Agent Demo 上线为何频繁翻车：12 类隐性工程缺口》；
- 自研与框架方案在可验收性上的差异，见《Agent 框架怎么选：自研、编排框架、工作流引擎与托管平台》。
参考资料
验收、SLO 与发布
- Site Reliability Engineering（Google，在线全文） ------ SLI / SLO / 错误预算的定义方法，本文时延与成本阈值的推导与之同源。
- The Site Reliability Workbook（Google，在线全文） ------ SLO 落地、告警设计与发布工程的实践章节。
- Accelerate / DORA 研究 ------ 变更失败率、恢复时间等交付指标的定义与测量方法。
- Release It!（Michael Nygard） ------ 稳定性模式与失败演练。
评测与测试方法
- A practical guide to building agents（OpenAI） ------ 护栏与评测的落地建议。
- Building effective agents（Anthropic 工程博客） ------ 编排模式与评估的取舍。
- Datasheets for Datasets（arXiv） ------ 数据集文档化的标准格式，可直接用于评测集版本管理。
- Model Cards for Model Reporting（arXiv） ------ 报告模板设计的参考，尤其是「适用范围与局限」一节。
- Holistic Evaluation of Language Models（Stanford CRFM） ------ 多维度评测框架，可借鉴其维度划分方式。
混沌工程与恢复演练
- Principles of Chaos Engineering ------ 故障注入的原则与方法论。
- Chaos Engineering（Basiri 等，arXiv） ------ 故障注入实验的设计原则与安全边界。
安全与合规
- OWASP Top 10 for LLM Applications ------ 提示注入、过度代理权限等风险的标准分类，本文安全验收项与之对应。
- OWASP GenAI Red Teaming Guide ------ 红队测试的组织方法与用例设计。
- MITRE ATLAS ------ 针对 AI 系统的攻击技战术知识库，可用于扩充对抗样本。
- NIST AI Risk Management Framework ------ 风险治理框架，可用于映射本文的剩余风险一节。
可观测性
- OpenTelemetry：Generative AI 语义约定 ------ 成本与时延归因所需的标准化字段。