工具评测怎样保持独立：环境重置、随机性与轨迹重放

一道题不只是用户的一句话#

“查询 A17，需求 3 件，优先杭州，不足再查苏州”，只是用户看见的请求。一次完整的评测实例还包括：两个仓库的库存、接口版本、最大调用次数、允许的重试、故障安排以及判定规则。

如果模型 A 查询时苏州有 5 件，模型 B 查询时已被其他订单买到只剩 1 件，它们面对的不是同一个实例。即便用户文本完全相同，也不能把差异全部归给模型。

在本卷的初始实验里，我们采用固定快照。每个实例明确指定库存，并在整个回合内保持不变。这降低了真实性，却方便定位问题。之后若研究动态库存，就新增环境版本，说明什么时候变动、谁能观察到，以及预订如何执行。

固定环境不是最终目标。它的价值是先提供一个能检查的基准，让我们知道错误究竟发生在哪里。

只读工具也可能留下状态#

查询本身不修改库存，但查询程序可能缓存结果。设任务 A 的杭州库存为 2，任务 B 的杭州库存为 4。

如果缓存只用 (商品, 仓库) 作为键，并在任务切换时没有清空，那么执行顺序会改变 B 的结果：先执行 A，缓存记住 2；再执行 B，程序可能直接返回 2，而不是 B 快照中的 4。

这就是跨任务污染。模型没有读到上一题的聊天记录，仍然可能通过工具层受到上一题影响。聊天窗口“新开了”不代表环境干净。

一种修复是每个回合使用独立缓存；另一种是让缓存键包含不可混淆的快照版本，并有正确的失效规则。本文教学环境选择前者。若缓存本来就是待评估系统的一部分，也可以保留，但要把冷缓存与暖缓存条件明确分开，而不是任由测试顺序决定。

reset 应该重置什么#

环境重置至少要覆盖会影响本回合行为的可变状态。对于当前只读例子，包括缓存、调用计数、故障序列位置、工具日志和结束标志。后续若加入预订，还要恢复库存占用、事务与幂等记录。

Gymnasium 的环境接口将 reset 与 step 分开，并区分任务终止和外部截断；它还提醒环境返回新的观察对象，避免后续修改悄悄改变已保存的历史。环境接口文档

我们借用的是这些边界，不是要求所有工具系统都必须改成 Gymnasium。一个普通服务也需要说清楚：什么时候开始新回合、什么状态归属于这个回合、什么时候不再接受后续动作。

不要只看 reset 的函数名。做两个具体检查更可靠：完成一个回合后重新开始，第一次查询是否与干净进程一致？修改调用方拿到的返回字典，环境下一次返回是否跟着被篡改？后一种问题通常来自共享可变对象，可能连审计日志都一起改掉。

把环境随机性和模型随机性分开#

评测里至少可能有三种随机源：题目或库存的生成、工具故障、模型生成。把它们都混进一个全局随机数发生器，会让调试变困难。

例如多做一次日志采样，就可能消耗一个随机数，导致后面本来不该超时的调用超时。于是“只改了日志”的版本，实际上换了环境。

因此可以给这些来源分别记录种子与生成规则。更直接的教学方法是提前固定故障表，例如第一次杭州查询超时、第二次杭州查询成功，并随实例保存。这样可以复查实际故障，而不只依赖一个种子数字。

种子也不是复现承诺的全部。还需要生成器实现、版本、调用次序和初始状态。Gymnasium 文档特别说明，已有生成器时 reset(seed=None) 不会重新播种；不能把它理解为“每次恢复相同随机序列”。本文没有安装或运行 Gymnasium，仅核对接口语义。

相同种子不一定给不同策略相同的故障#

假设共享序列是“超时、成功”。策略 A 先查杭州，策略 B 先做一个无关调用。如果按全局调用编号消耗故障，超时会落到不同操作上。

这未必是实现错误：它可能就是你选择的环境定义。但它不能被描述为“两个策略在同一语义操作上遭遇了相同故障”。

在本文的教学对照中，我们把故障绑定到 (实例, 工具, 参数, 该参数的尝试次数)。于是同一实例里第一次查询杭州的结果固定，不会被一次苏州查询挤走。配套脚本用两个调用顺序检查这一点。

这种事件键控也有边界。如果真实服务故障随时间持续，按参数独立安排故障就不符合实际。如果模型动作会改变系统负载，环境还需要表现这种反馈。必须先选择研究的问题，再决定怎样耦合随机性；不存在一种种子技巧能自动保证所有比较公平。

故障表属于评测侧信息，不应放进模型提示。否则模型可能提前知道哪次会超时。可以让训练和测试遵循相同故障分布，但使用不同的实例安排，并保留故障切片的结果。

重放日志和重新运行，是两种证据#

日志重放是拿已有调用及对应结果，检查解析、评分与可视化是否稳定。它适合复核“这条记录为什么得分”，也适合检查新版评分器是否改变口径。

重新执行则从相同初始条件出发，让模型再次选择动作，再由环境处理。它可以暴露模型行为变化，但若模型采样不同，轨迹也可能不同。

不能让新模型发出任意调用，然后按位置喂回旧日志的下一个结果。旧调用是杭州，新调用是苏州时，这会把杭州库存伪装成苏州结果。真正的重放要检查请求是否匹配；遇到未记录的请求，应明确报告无法重放，而不是编一个返回值。

对交互模型，还可以做固定历史的下一步测试，但那只是局部决策检查。它不证明模型能从任务起点走到那段历史，也不能替代闭环评测。

环境独立，也不代表数据独立#

即使每次 reset 都正确，训练集和测试集仍可能共享几乎一样的轨迹。把 A17 改为 A18、把“有没有库存”改为“库存够不够”，并不会自动形成新的问题家族。

至少分别考虑用户措辞、商品实体、库存组合、工具定义和故障模式。按研究问题选择哪些维度留出：如果只想检查已知接口上的新库存组合，就不要把结果宣传成学会了陌生工具。

划分应在扩写与合成之前完成，保留原始任务家族标识，防止同一模板生成的近重复跨集合。多次尝试同一任务也不应当作很多个独立任务来计算置信程度。

评分器的隐藏答案更不能混进观察。例如调试信息里保存了 expected_warehouse=SZ，如果把整个调试对象序列化给模型，它可能绕过查询。审计字段与模型可见字段要由实际数据流分开，而不只是命名不同。

用四个反例验收一个小环境#

本文的本地检查做了四件事。

首先，故意实现未清缓存的版本，复现 A 后 B 返回旧库存 2 的错误；修复后 B 返回 4，并交换任务顺序确认每个实例结果不变。

其次，修改外部拿到的返回对象，再次查询，确认环境与缓存没有被一起修改。

再次，在两个不同调用顺序中查询杭州，确认同一参数的第一次超时、第二次成功保持一致；重新开始回合后，尝试计数归零。

最后，重放只接受匹配的请求，错误参数和越过日志末尾都会被拒绝。这验证了一个很小的协议，不是完整业务环境的认证，也没有测出任何模型成功率。

真实项目还要针对并发、异步任务、数据库连接和写操作补充隔离检查。本文的串行内存环境不覆盖这些问题；不能因为它通过，就声称生产系统不存在状态污染。

留下能够重建实例的材料#

建议每次评测保存实例标识与家族、初始快照、工具与评分规则版本、预算、随机安排、模型与解码配置，以及执行侧的调用和结果。大文件可以保存可靠引用和内容校验，但一个哈希只能帮助识别内容，不能代替被删除的文件。

记录每次停止的原因：正常完成、预算用尽、工具故障、执行器错误。不要把异常样本默默丢掉，也不要在看到成绩后才改变排除规则。

下一次看到两个模型的分数差异，先尝试重建它们面对的实例。如果库存、缓存、故障、预算或可见信息已经不同，优先报告这些差异。只有环境条件与数据边界说明白，后面的能力比较才有可信的起点。