AI Agent 仿真门禁：迭代快 4.8 倍，不等于证过

一家数字银行的信用卡客服线上，同一个智能体从第一版走到第四版花了 212 天，平均 21.2 天一个版本。拖住它的不是写代码，而是验证：想知道一处改动是好是坏，只能等真实客户再来一次同样的对话，而真实客户不可预约、不可复现，也不允许你拿他们试错。

到第二条第产品线时，这家银行把验证换成了一道上线前的仿真门禁：五个版本在 22 天里走完，平均 4.4 天。同一批人、同一类任务，版本速度差了 4.8 倍。

这组数字出自 2026 年 9 月 24 日提交的论文《Screen Before You Serve》，作者是被部署方 Nubank 与模拟器厂商 Snowglobe（Guardrails AI）。也就是说，它属于双方联合自报，没有第三方审计：可以写「Nubank 公布」，不能写「经独立验证」，更不能当行业基准转述。下面拆的是这套做法能证明什么、不能证明什么。

一、改一版要 21 天，时间花在验证而不在开发

智能体的验收标准只有一个来源，就是生产。但生产有两个特性，让它没法当日常测试台：第一，真实对话的分布不受你控制，今天是账单查询，明天可能全是退款争议，同一批用例复现不出来；第二，试错的成本由客户承担，一次错误的改派或一句错误的答复，代价不是一条失败日志，而是一次真实的服务事故。

这两个特性叠加，团队的默认行为就变成了攒着。多个改动合并成一次上线，减少曝光次数；出了故障整体回滚，回归定位变成考古。于是版本粒度越来越粗，责任边界越来越模糊，能做的实验越来越少。21.2 天一个版本不是工程能力问题，是验证供给不足的必然结果。

这里要区分两种时间。一种是从写代码到能上线的时间，可以通过重构、CI、更好的工具缩短；另一种是从有改动到敢上线的时间，它由「我能多快知道这次改动是好是坏」决定。前者是工程效率，后者是信息效率。大量团队把资源投在前者，卡住的却在后者。

这种供给不足会在报表上留下痕迹。它表现出来是一组反直觉的分布：上线次数不多，单次上线包很大；每次上线之后的观察期很长，因为没人敢在观察期里叠加新的改动；事故复盘里最常见的一句话是「这个改动是两个月前写的」。验证供给不足的组织，工程效率的提升会被验证瓶颈吃掉——CI 从十分钟压到三分钟，不会让版本周期从 21 天变成 14 天，因为真正在等的还是下一批真实流量。

还有一层组织后果。当验证只能落在生产上，测试就变成了上线之后的动作，质量责任从工程团队平移到运维和客户成功。谁负责发现回归，谁就在事实上承担了质量问题，而这个隐形的责任转移比周期数字更难在组织内部讲清楚，也更难被写进路线图。

二、工具边界仿真：把生产后端换成合成结果

做法本身不复杂。系统让合成的客户与真实的智能体进行多轮对话，但智能体的每一次工具调用都被拦截下来，返回一个场景化的合成结果，不触达生产后端。模拟器需要知道的只有两样东西：智能体的描述，以及它有哪些工具。团队另外拿了 8,000 条真实对话，均分开发集与测试集，用来刻画仿真并验证它的保真度。

关键的设计选择是拦截点放在工具边界，而不是模型输出。这个位置决定了它能测什么：多轮决策、工具选择、参数构造、改派逻辑，这些都发生在工具调用周围，仿真可以完整覆盖。它也决定了它测不到什么，这一点下文单说。

速度上的差别是数量级的。100 条轨迹不到 10 分钟跑完，而等真实流量回放同样的样本，需要按小时甚至按天计。评测器在仿真里抓到过工具调用失败，也抓到一个缺 tool-call parser 的服务端配置错误——后者是典型的「上线之后才炸、炸了归因困难」的类别。

保真度有可量化的证据：仿真轨迹与真实对话之间的最低余弦距离是 0.035；四个已经部署到生产的版本，其仿真得分与生产二值比分之间高度相关。这两句话说的是「可比」，不是「等价」——它们是让仿真结果值得被相信的理由，也是判断它什么时候失效的边界。

要让仿真值得被相信，有三个设计选择绕不开。第一是场景覆盖：合成客户必须覆盖真实的意图分布，而不是覆盖团队最熟悉的那几类，否则门禁会在边缘分布上放行错误。第二是工具返回的多样性：合成结果不能总是顺从的，工具报错、字段缺失、返回值迟到这类情形如果不在仿真里出现，上线后第一次遇到就会直接变成事故。第三是保真度的定期复检：论文用最低余弦距离与已部署版本的得分相关性来验证仿真与生产的一致性，这两个指标应当在业务分布明显变化后重算，而不是上线时测一次就封存。

三、live A/B 的数字，以及每个数字的分母

这套流程改变上线结果的说法，有线上 A/B 背书。从信用卡配送线换到卡片管理线之后，自助解决率（SSR）提升了 4.90 个百分点，置信区间 4.08 到 5.71，样本 n=27,800；交易型净推荐值提升 36.69 个百分点，区间 32.81 到 40.57，样本 n=2,000。两组都是 Nubank 方公布的实测结果。

另有一步是模型选型。团队用 16,000 多条仿真对话筛开放权重模型，最后选中 Qwen3.5 系列的 122B 模型并打开推理模式；随后线上 A/B 得到自助解决率提升 8.82 个百分点（区间 7.95 到 9.69，n=8,400），p95 延迟下降 25%，而交易型净推荐值变化为 −1.21（区间 −3.97 到 1.55），统计上不显著。

最后这一条不该被忽略。它说明延迟改善并没有转化成满意度，模型换了、指标动了，客户感受没动。把它从叙事里删掉，剩下的就是一张漂亮的成绩单；留着它，才看得出这套流程真正改变的是迭代速度，而不是产品体验的全部。选型阶段用仿真（便宜、可重复），验收阶段用生产（昂贵、有限），两者的分工就体现在这类数字的对照里。

口径上还有一处必须切开。外部转述里出现过「快 20 倍」的说法，那个数字没有公开定义。论文里的 4.8 倍是版本迭代天数的比值，两者不是同一个指标，不能混用，也不能取大的那个当宣传口径。

三组数字的分母各不相同，这意味着它们在汇报里最容易被抹平。样本量 27,800 的那组是自助解决率，2,000 的那组是满意度，8,400 的那组是换模型之后的复测。把它们并列成一句「指标全面提升」，听的人会以为它们来自同一次实验；分开写，才看得出哪条结论强、哪条只是方向。

四、仿真层证明的是资格，不是行为

我们的判断是：仿真门禁的产出是一张资格证明——证明这个候选够不够格接触真实客户。它不产出任何关于上线之后实际发生了什么的事实。

证据来自论文自己列的不覆盖清单：后端行为、真实延迟、持久状态、副作用。这四项恰好是生产事故最常见的来源。一个在仿真里表现完美的智能体，可能因为下游接口的限流而超时，可能因为状态在会话之间没有正确落地而重复执行，也可能因为重试策略在副作用上叠加而产生第二笔操作。这些都不会在合成结果里出现，因为合成结果本来就是被设计成「顺从」的。

买方最容易犯的错误，是把筛过当成证过。门禁回答的是能不能上；上了之后做了什么，需要另外一条链路来回答——智能体之外的任务级记录：任务是什么、花了多少钱、结果是什么、谁验证过。少了这一条，第二年续投时手上仍然只有一份上线前的仿真报告，而预算流程问的是上线之后的问题。

还有一条工程接缝容易在方案里漏掉。论文指出，如果仿真轨迹与生产的 schema、标识、遥测不一致，导出与对账会吃掉迭代收益。翻成大白话：你在版本周期上省下的时间，会以对账工时的形式还回去。可操作的硬要求只有一句——仿真环境沿用线上的 MCP schema。这条要求看着是细节，代价却是整套方法的经济性。

适用边界也要说清。这套方法在高话量、以对话为主、工具边界清晰的场景里最有效：客服、工单、订单查询都属于这一类。到了副作用密集、状态长期驻留的场景——资金划转、库存扣减、跨系统的长事务——仿真能覆盖的部分会小得多，因为最难的部分恰恰是它不测的那四项。把结论直接搬过去，等于把门禁当成生产台账用。

这四项的分布本身也有规律：它们大多不是模型推理错误，而是系统集成错误。超时的下游、没有落地的状态、被重试放大的副作用，都属于智能体之外的系统行为。这也是为什么仿真层再准也补不上这块——它的合成结果被设计成友好的，而集成错误恰恰来自不友好的那一侧。

五、先动推理设置，再纠结核位

论文附录的对照实验里，有一条与当下主流的成本优化直觉相反的结论。把模型量化到 nvfp4、fp8 或 bf16 三种格式，评测分差分别是 2.2 分、0.8 分、4.1 分；而固定配置重复跑六次，标准差本身就有 2.2 分。也就是说，格式之间的差异落在噪声范围内，你花在量化调参上的时间，很可能只是在测随机数。

真正移动分数的是推理设置，差别约 11 分。机制不是更聪明的采样，而是检索：智能体取到「任务所需的公司记录」的比例，从 16% 升到 94%。

也就是说，工程排序应该是先确认智能体拿没拿到它该拿的记录——检索命中率、上下文装配、工具返回值的结构；这些都对了，再谈压缩、量化与核位。反过来做，就是在给一个没拿到资料的智能体省电费，顺便把质量差异记到噪声账上。

这个读法有可检验的形式。如果机制真的在检索，那么在任何一次成本与质量的权衡里，单看检索命中率这个指标，就应该能预测大部分质量位移。16% 到 94% 与 11 分，是同一件事的两个侧面，不是两条独立经验。

六、买方该向团队要的三样东西

我们建议向团队要的第一样东西，是门禁的存在性与它的拦截记录。过去 30 天里，有几次改动在仿真阶段被拦下，原因分布是什么。一道从来没有拦下过任何东西的门禁，等于没有门禁，它只是流程图上多出来的一个方框。

第二样是仿真与生产的接缝清单：schema、标识、遥测三处是否同源，对账由谁负责，多久对一次。这份清单的价值在于它把「省下的时间去哪了」变成可追踪的问题。

第三样是上线之后的第二份记录：任务级台账，含任务、成本、结果、验证方，能导出、能逐条核对。门禁与台账合起来，才构成完整证据链——上线前筛过，上线后记过。只有前者，你能证明自己筛得勤；只有后者，你能证明花得值；两者都有，才谈得上把验证变成资产。

如果眼下只能加一项，我们建议先加第二份记录。门禁证明的是候选够不够格，而第二年预算批不批，问的是它上线之后到底做了什么。

来源

论文《Screen Before You Serve: Simulation for Production Customer Experience AI Agents at 140M Scale》: arxiv.org/abs/2609.30137（2026-09-24 提交，Nubank × Snowglobe 联合产出，属自报口径）。

联合演讲页（第三方转述，不构成独立验证）: ai.engineer/speakers/shreya-rajpal；模拟器厂商产品页: guardrailsai.com/snowglobe。