评测环境要不要联网：出网白名单、只读凭证与人工提交门槛
一、要不要断网，其实是要不要给写权限
据公开报道，一家模型公司在内部评估过程中出现过模型向外部真实系统提交内容、并在评估期间访问外部系统的情形，随后暂停了相关联网评估并调整了评估安排。事件的具体细节、涉及对象与后果定性不在本篇讨论范围内，成因与责任也不做推断；对被测系统是否存在所谓”意图”，我们的态度是它不是工程上可以回答的问题。留下来的是一条环境设计上的教训：一次评测要不要联网，等价于在实验开始前决定要不要允许被测系统对外部世界产生写操作。
这件事之所以常被做错，是因为联网在评测里被当成”贴近真实”的配置项。评测环境越像真实使用场景，结论越有参考价值——这个逻辑本身没错，但它掩盖了另一种能力：真实场景里存在的那些有副作用的通道，在评测里同样被打开了。通道一旦被打开，评测就在对外部系统施加影响，而外部系统并不会因为”这是一次测试”而降低被影响后的处理成本。
所以我们把这条判断标准固定下来：评测目的、所需网络能力、可能的外部影响面，三者必须在实验开始前分别定义并写进同一份声明。事后收回联网权限当然可以做，但它证明的是事前没有把影响面算清楚。
二、出网能力分四档，每档只回答它那一类问题
分档不是为了省事，而是为了让”为什么这次要开到第三档”这个问题有答案。下表是我们内部评测环境的固定四档，第二列是关键——多数争论其实发生在有人想用一档回答四档的问题。
| 档位 | 网络能力 | 能回答的实验问题 | 凭证形态 | 必须配套的控制 |
|---|---|---|---|---|
| 一档：完全断网 | 无任何出站，只用本地镜像语料与离线服务 | 知识回忆、推理链质量、代码生成与静态正确性、格式遵循 | 无外部凭证 | 镜像版本登记，防止”离线但带了缓存”的口径混乱 |
| 二档：仅到指定内网服务 | 只允许访问自建的检索、沙箱执行与工具仿真服务 | 工具调用格式正确性、多步编排、检索增强行为 | 内网服务签发的短期令牌，作用域限本次任务 | 仿真服务要能记录被调用次数与参数摘要 |
| 三档：白名单出站且只读 | 按域名与路径放行，凭证权限上限为读 | 公开信息获取的准确性、时效敏感内容的边界、外部页面结构变化的影响 | 单独签发的只读凭证，短时效，禁止复用生产密钥 | 拒绝默认放行；白名单变更须留申请记录并周期性收敛复核 |
| 四档：允许写操作且需人工确认 | 在白名单内允许提交类动作，每个动作由人点头 | 真实闭环任务的成功率、失败恢复行为、与外部系统交互的合规性 | 按被测对象隔离签发的最小权限凭证，独立计数与配额 | 逐个确认界面、动作留证、写操作目标必须预先列入声明清单 |
前两档覆盖大多数评测需求。真正的分歧总是出现在要不要开四档，而正确的提问方式不是”开了会不会更真实”，而是”这个实验问题除了写操作之外没有别的办法回答吗”。答不上来就停在三档。反过来，如果确实需要四档，那么被测对象清单、数据是否出域、日志保留期这三件事必须在开之前定完，不是等出事之后补。
三、外部写操作风险的三处来源
写操作不是一个抽象概念，在评测环境里它只有三个常见入口，逐个处置比笼统加限制有效得多。
- 提交表单：搜索框之外的各类输入框——注册、反馈、报名、工单、下单页。风险在于字段内容会被当成真实请求处理，且常带联系方式类字段，会触发对方系统的后续动作。处置方式是在四档之外的所有档位上，把表单类动作在客户端拦截并记录为”被阻止的写尝试”，这类记录本身就是有价值的评测数据。
- 发消息与邮件：包括任何有对话对象的通道。它的不可撤销性最高，因为接收方在外部。处置方式是取消所有对外通信通道的凭证，或者只允许发到自有的收件域，且收件域与生产邮件系统物理隔离。
- 调用有副作用的接口：删除、修改、支付、创建资源这一类。评测里最常见的错误是为了”方便验证结果”给了带写权限的测试账号。处置方式是测试账号本身也按只读设计，需要验证写结果时改用可回滚的沙箱租户，租户与生产环境不共享任何标识与配额。
这三处的共同点是可以被枚举。能被枚举的风险面就应该用清单而不是用提示词约束来管——把”不要对外发送信息”写进被测系统的指令里，属于软约束，它不解决凭证问题。
四、只读凭证与白名单的工程细节
只读凭证的关键不是”只读”两个字，而是它的签发方式。我们要求的做法有五条：单独签发，不复用任何生产密钥，即使权限相同也不复用；短时效，过期即失效，评测任务不申请长期凭证；权限上限为读，在提供方侧强制而非仅靠约定；按被测对象隔离计数，一个被测对象耗尽配额不影响其他对象；凭证与被测对象的绑定关系写入日志，事后能回答”这次调用用的是谁的哪把钥匙”。
出网白名单最容易坏在可维护性上。一开始只有几个域名，一段时间后膨胀到没人敢删。控制办法是四条：粒度到域名与路径，不给整段通配；默认拒绝，任何放行都要显式配置；每次变更留申请记录，写清为哪次评测开的、什么时候收回；周期性收敛复核，把长期无人使用的条目直接撤销。白名单的规模本身是个信号——它一直涨，说明评测在往四档方向滑，只是没有走正式流程承认。
五、人工提交门槛：批量确认等于没有确认
四档一定要有人工门槛，但它的设计质量差异极大。三条要点。
哪些动作必须人点头：所有对外部系统产生持久影响的、所有不可自行撤销的、所有涉及第三方接收方的、所有会消耗真实额度或产生真实费用的。这四类之外可以自动放行，否则审批量会把人压垮，压垮之后就是无差别点通过。
确认界面要展示什么：目标系统的标识与本次动作类型、将要写出的完整内容（不是摘要）、可撤销性与撤销方式、这次动作归属于哪次评测的哪个任务、当前已发生的同类动作计数。摘要式的确认框是最常见的设计缺陷——人看不到真实内容时，点通过只是形式。
为什么批量确认等于没有：批量把判断从”这件事对不对”变成”这一批是不是同一个任务”，而后者根本不是风险判断。批量确认还破坏留证的粒度，事后无法区分哪一次是被人明确批准的。我们的做法是一次一个，并对每个任务的确认次数设上限，超限自动停止并要求重新申报，避免一次评测在外系统上产生计划外的持续动作。
六、评测前影响面声明与出事后的留证最小集
核心交付物之一是这份声明。它不是安全部门的表格装饰，而是评测的准入条件，字段与填法如下。
| 字段 | 填什么 | 谁负责 |
|---|---|---|
| 实验目的与问题 | 一句话说明这个实验为什么必须用到当前档位 | 评测负责人 |
| 允许触达的外部系统清单 | 逐项列域名与动作类型，写明读写属性 | 环境管理员 |
| 禁止清单 | 明确不允许触碰的通道，含默认拒绝的说明 | 安全评审人 |
| 数据是否出域 | 输入与输出是否离开受控环境，落到哪个日志 | 评测负责人 |
| 凭证与配额 | 签发对象、时效、上限与耗尽后的行为 | 环境管理员 |
| 日志保留期与访问人 | 保留多久、谁能读、到期如何处理 | 数据责任人 |
| 停止条件 | 出现哪几类信号立刻终止评测 | 安全评审人 |
出事后的留证最小集要提前接好，因为事后补装是补不出来的：请求与响应的完整快照、动作序列及时间顺序、决策依据的文本（即当时给出的指令与上下文）、当时的配置版本（含白名单与档位设置）。四项齐备才谈得上复盘；只有一份”发生了什么”的叙述性记录，价值有限。红队与常规评测共用环境时还有一条硬要求：两者的网络档位、凭证体系与日志存储必须分开，否则红队用例的放行规则会被常规评测继承，这是配置漂移里最难查的一类，因为两边都认为自己按规矩在跑。洹拓在给客户提供模型评测环境时，把四档声明当作交付物的一部分而不是内部文档，原因很实际——客户最关心的从来不是分数，而是这次测试到底碰了什么。