影子测试：让 agent 试跑，但不准它动手

影子测试最经典的翻车，不是测出 bug，而是给同一个用户发了两封邮件。

一、发生了什么

10 月 24 日，一位在差旅公司 Navan 任职的工程师在 HackerNoon 发表长文，讲 agent 上线前的「影子测试」该怎么做。思路是：把生产流量同时喂给线上的旧版本和候选新版本，对比两者的决策，但控制权始终留在旧版本手里。文章点出一个容易踩的坑：如果把整个应用原样跑两遍，候选 agent 也会执行发邮件、写库这类真实动作——用户的一次请求变成两条真实外发，「安全的实验」直接变成生产事故。正确原则是把观察和决策复制一份，权限和效果只留一份。

作者给出一套具体拆法：把 agent 分成「提案、策略、执行」几段，候选版本只产出提案和简短理由码；影子环境里不发放任何可写的凭证，工具表只保留名字和参数格式、不挂执行方法；用策略引擎的非权威模式模拟「这个提案会不会被放行」，并记录策略版本号；比较的是结构化决策差异而不是文字相似度——最值得盯的分歧是旧版本保持沉默、新版本却要写入这种。

二、跟你有什么关系

做 agent 产品的：影子测试是发布前最后一道保险，但前提是影子根本「够不着」真实开关，而不是靠一个试运行开关。团队负责人：实验报告的可信度取决于影子看到了哪些流量，只挑简单请求跑出来的数据没有意义。普通用户：这条原则落到产品上，就是你批准过一次的事，不会被某个还在测试的版本重复执行一遍。

三、怎么用

1. 拆权限而不是加开关：给工具加一个「试运行」参数太脆，重构时漏掉一处就失效。更硬的做法是影子身份本来就没有生产写入权限——凭据缺失是关死的门。
2. 收窄影子能看的上下文：把生产提示词整份抄进实验会带出隐私数据，先做字段投影和隐私审查。
3. 分层统计再下结论：按动作类型、风险等级、账户分层报告差异，警惕「总体一致率 99%」掩盖了高风险那一小撮。
4. 发布走台阶：静态检查、离线回放、重复评估测方差、影子、小范围灰度，影子只是其中一级，不是发布策略本身。

四、三个别信的说法

「影子分数高就能上线。」 影子比的是「和旧版本一致」，可旧版本本身可能是错的。有意义的分歧应该送人工标注，而不是默认旧版本对。另外模型输出有随机性，单次对比说明不了方差，要固定配置跑多轮。

「实验跑了没出事就是安全。」 「没观察到写入」弱于「影子不可能写入」。这篇文章给出的底线是三条可自动校验的不变量：影子运行期间，真实写入为零、权威审批为零、生产消息外发为零；用于验证的监控缺失，实验就该暂停。

「选几条简单流量跑跑就够了。」 只让低风险请求进入实验叫选择偏差——报表上一切正常，是因为最危险的流量从没进过考场。纳入规则要写清楚，排除原因要留痕。

五、一句话结论

影子测试复制的应该是「脑子」，不是「手」——让候选 agent 把决定做全，但让它永远够不着真实的开关。

信息来源

• HackerNoon：如何在不让 agent 动手两次的前提下做影子测试 2026-10-24

功能与价格以官方公告为准。本文写于 2026 年 10 月 25 日。