目录一、演示与生产之间隔着六处环境差异一为什么「演示顺利」不能说明任何问题二验收要回答的那一个问题三本文使用的参考场景二、六个验收维度一维度总览与它们的关系二维度一功能正确性的三层口径1、结果正确2、过程正确3、副作用正确4、三层缺一不可三维度二质量的四个可计算口径1、为什么把「无依据回答率」单列2、人工改判率的特殊地位3、不要把这些当质量口径四维度三时延1、时延预算要拆到组件2、失败路径的时延必须单独统计3、时延门槛怎么定五维度四成本1、两个最常见的漏算2、方差比要单列3、成本要能归到三个维度六维度五安全一票否决1、为什么不设达标率2、剩余风险必须写进报告七维度六可恢复性另一个一票否决1、怎么演练2、要看的三个数字3、取消语义是一条常被忽略的验收项三、验收数据集一四层样本各有各的用处二规模、版本与三个常见错误三基线没有基线的指标不构成验收依据1、基线本身也要被验收四、阈值、造假与门禁一阈值从哪来二指标造假的八种方式三硬门、软门与 Go / No-Go五、流程、分级与报告一分级上线三个阶段三套标准1、灰度阶段最容易出的三个问题2、每个阶段都要准备回退二一次完整验收的两周流程1、为什么第一步是冻结版本2、哪些环节可以压缩三验收报告模板九节六、验收不能回答什么七、上线验收检查清单八、结论与延伸一本文结论二与专栏其他文章的衔接参考资料干货分享感谢您的阅读演示环境会系统性地筛掉所有可能暴露问题的输入所以「演示顺利」不提供任何关于生产行为的信息。这次我们给出一套可执行的验收框架六个维度功能正确性、质量、时延、成本、安全、可恢复性的可计算口径、四层验收数据集的构成、三条基线的选法、阈值的四种定法、指标造假的八种方式、硬门与软门的 Go/No-Go 决策表、分级上线的三套标准、九节验收报告模板以及一份二十六项的检查清单。本节作为读者你将获得什么六个验收维度的可计算口径——每一项都写清楚定义、怎么算、常见陷阱而不是「准确率要高」这类无法执行的表述。一套四层验收数据集的构成比例与建设方法包括最容易被忽略的「信息不足样本」与「间接注入样本」。阈值从哪来的四种定法以及为什么「拍脑袋定的阈值到争论时一定守不住」。指标造假的八种方式与三条防造假的流程设计。硬门与软门的 Go / No-Go 决策表、分级上线的三套标准、九节验收报告模板、二十六项检查清单。关于数据的说明本文的业务场景、指标数值与阈值建议均为示例场景与示例值用于说明口径与量级关系不是任何真实系统的实测结果也不构成普适基准。每个团队的阈值必须按本文第六章的方法自行推导。还有设计的代码入如果写的有问题的请您在评论区留言提醒感谢一、演示与生产之间隔着六处环境差异一为什么「演示顺利」不能说明任何问题演示环境与生产环境的差异可以整理成六条输入演示用的是精心挑选的十几条生产是用户真实输入含错别字、缺关键信息、一句话混两件事。被掩盖的问题是意图误判与「槽位缺失被静默填了默认值」。并发演示一次一条、串行生产峰值几十上百并发且与其他业务共享下游配额。被掩盖的是限流、排队与雪崩。依赖演示时下游全部正常生产里每天都有某个下游在抖。被掩盖的是超时、部分成功与重复写。时间跨度演示几十秒内跑完生产的长任务跨天中间要重启发版。被掩盖的是状态丢失与任务失联。恶意演示时没有人想搞你生产里总有输入试图让它做不该做的事。被掩盖的是注入、越权与数据外泄。成本演示跑几十次没人看账单生产每天几万次月底要对账。被掩盖的是方差失控与预算超支。这里有一个容易被误解的因果。很多人把上线翻车归因于「演示时没测够」这不完全对。真正的原因是演示的目的是展示可能性所以它天然会挑选那些能展示可能性的输入——这不是疏忽是定义。所以解法不是「演示时更认真一点」而是在演示之外另建一套过程它的目的与演示相反找出它在哪里会坏。这两件事不可能由同一个流程同时完成。二验收要回答的那一个问题验收要回答的不是「它能不能做对」而是在真实输入分布、真实并发、真实依赖抖动、真实时间跨度、存在恶意输入、且有成本上限的条件下它做错的比例是多少做错时会发生什么以及我们能不能在出事之后说清楚发生了什么。这个问题有六个分量对应本文的六个验收维度。三本文使用的参考场景全文以企业任务执行 Agent 为样本员工用自然语言提任务系统跨知识库、权限系统、工单系统把事办完涉及只读查询、写操作、人工审批、长任务与多租户。选它是因为它的六个维度都有实质内容——只读问询有质量问题写操作有安全与恢复问题长任务有时延与成本问题。二、六个验收维度一维度总览与它们的关系六个维度分别是功能正确性它有没有做对该做的事、质量做对之外做得好不好、时延用户等多久、成本每做一次花多少、安全会不会做不该做的事、可恢复性坏了能不能救回来。有三件事需要先说清楚。六个维度不是并列的。安全与可恢复性是一票否决项它们不达标其余四项再好也不能上。功能正确性与质量之间有先后先保证「做对该做的事」再谈「做得好不好」。六个维度会互相拉扯。提高质量通常意味着更多模型调用于是时延与成本上升压低成本通常意味着换小模型于是质量下降加强安全通常意味着更多校验与审批于是时延上升、完成率下降。所以验收标准必须一次性定全六项。只定一项的后果很严重。如果只定「准确率不低于 90%」这一条团队会用近乎无限的时延与成本去换它并且在安全上留下缺口。这不是团队不负责——没有被约束的维度一定会被牺牲这是所有指标体系的共同规律。二维度一功能正确性的三层口径「做对了」这三个字至少要拆成三层才能被测量。1、结果正确任务的最终产出与黄金答案一致。比如该开通的权限开通了、该拒绝的请求拒绝了。测法是准备带黄金答案的样本集逐条比对关键字段。注意是比对字段而不是比对整段文本——比对文本会把措辞差异当成错误。局限它看不见「结果对但过程错」比如碰巧蒙对或者多做了一步无关的操作。2、过程正确工具调用序列符合预期。比如开通之前必须先查是否已有写操作之前必须先鉴权。测法是把期望序列写成三类约束——必含、禁含、先后关系——然后对轨迹做集合与顺序断言。例如必含query_permission禁含任何未注册工具query_permission必须早于grant_permission。局限约束过严会误杀合理的替代路径。所以「必含」类约束要少而精「禁含」类可以严格。3、副作用正确外部世界的状态变化符合预期只产生一条权限记录不多不少失败时无残留。测法有两步跑完之后查下游状态把同一样本重复跑两次确认第二次不产生新的副作用。第二步是幂等性的端到端验证比读代码可靠得多。局限需要一个可回滚的测试环境。这项投入经常被省掉然后幂等性就只能靠代码评审来保证。4、三层缺一不可只测结果正确会放过「蒙对」的样本——一个只会说「已为您开通」而从不真的调用工具的系统在结果比对上可能拿到不低的分数因为它的措辞总是对的。只测过程正确会放过「步骤都对但参数错」的样本。只测副作用则测不了只读任务而只读任务通常占多数。门禁建议按「全部通过」而不是「加权平均」判定结果正确率不低于目标值禁含类过程约束违反数为零重复执行产生的额外副作用数为零。加权平均的问题在于它允许用一项的高分掩盖另一项的零分而副作用这类项目一次出错的代价远高于多次答对的收益。三维度二质量的四个可计算口径「回答得好」不能作为验收项。下面四个可以。答复准确率与黄金答案在关键事实上一致的比例。陷阱是只看措辞不看事实。引用可核验率答复中每条事实都能追溯到来源且来源确实支持该事实。陷阱是只校验引用 ID 存在不校验内容是否支持——这是一个很常见的偷懒它会让一个「引用格式完美但内容对不上」的系统拿到满分。无依据回答率在检索无结果或信息不足时仍然给出确定性答复的比例。测法是构造一批「知识库里没有答案」的样本看它是否拒答或澄清。陷阱是评测集里全是有答案的样本。人工改判率人工复核时推翻系统处置的比例。陷阱是只统计被明确驳回的不统计被人默默改掉的。1、为什么把「无依据回答率」单列因为它是唯一一个「样本越难、指标越重要」的口径。一个在有答案的样本上表现很好的系统在没答案的样本上可能表现极差——它会把「我不知道」变成一段看起来很专业的编造。而线上恰恰有相当比例的请求知识库里本来就没有答案。2、人工改判率的特殊地位它是唯一一个不需要额外标注、由线上流程自然产生的质量指标也是唯一一个业务方真正相信的指标——因为它就是业务方自己的动作。代价是它有滞后性只有在人工审批环节存在时才有数据并且它反映的是「人觉得不对」不一定等于「客观上不对」。3、不要把这些当质量口径用户满意度评分样本偏差极大只有强烈不满的人才会评分、模型自评分与真实质量相关性弱且随提示词变化而漂移、平均回答长度或关键词覆盖数与质量无关且极易被优化、单条样本的主观观感适合发现问题不适合做门禁。四维度三时延只报一个平均值的时延报告等于没报。验收口径要写清六件事1. 测的是首响应还是端到端流式场景两个都要2. 分位数取哪几个建议 p50 / p95 / p99不要只报均值3. 分通道还是混在一起不同通道的时延差一个数量级混在一起的数字既不能用来定 SLO 也不能用来定容量4. 包不包含排队时间用户感知的是包含的5. 在什么并发下测的单并发的数字不能外推6. 缓存是冷是热冷热两套数字都要给。这六件事任何一件没写清两份时延报告就无法对比。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」的判定方法见《先别急着做 AgentChatbot、Workflow 与 Agent 的边界》本文六个维度各自落在系统的哪一层见《用一个业务场景画出生产级 Agent 的全景架构》本文「过程正确」这一层所依赖的结构化轨迹如何实现见《不依赖框架实现最小 Agent模型、工具、观察与终止》验收不达标时对应的具体工程缺口见《Agent Demo 上线为何频繁翻车12 类隐性工程缺口》自研与框架方案在可验收性上的差异见《Agent 框架怎么选自研、编排框架、工作流引擎与托管平台》。参考资料验收、SLO 与发布Site Reliability EngineeringGoogle在线全文 —— SLI / SLO / 错误预算的定义方法本文时延与成本阈值的推导与之同源。The Site Reliability WorkbookGoogle在线全文 —— SLO 落地、告警设计与发布工程的实践章节。Accelerate / DORA 研究 —— 变更失败率、恢复时间等交付指标的定义与测量方法。Release It!Michael Nygard —— 稳定性模式与失败演练。评测与测试方法A practical guide to building agentsOpenAI —— 护栏与评测的落地建议。Building effective agentsAnthropic 工程博客 —— 编排模式与评估的取舍。Datasheets for DatasetsarXiv —— 数据集文档化的标准格式可直接用于评测集版本管理。Model Cards for Model ReportingarXiv —— 报告模板设计的参考尤其是「适用范围与局限」一节。Holistic Evaluation of Language ModelsStanford CRFM —— 多维度评测框架可借鉴其维度划分方式。混沌工程与恢复演练Principles of Chaos Engineering —— 故障注入的原则与方法论。Chaos EngineeringBasiri 等arXiv —— 故障注入实验的设计原则与安全边界。安全与合规OWASP Top 10 for LLM Applications —— 提示注入、过度代理权限等风险的标准分类本文安全验收项与之对应。OWASP GenAI Red Teaming Guide —— 红队测试的组织方法与用例设计。MITRE ATLAS —— 针对 AI 系统的攻击技战术知识库可用于扩充对抗样本。NIST AI Risk Management Framework —— 风险治理框架可用于映射本文的剩余风险一节。可观测性OpenTelemetryGenerative AI 语义约定 —— 成本与时延归因所需的标准化字段。
