从推理证明到评测修补，重新理解“通过”

这次本地尝试让权重分析的一项具体能力可以被单独讨论。独立作者在本地较小模型上得到三个正确判断，削弱了“只能由少数最强闭源模型完成”的笼统说法；但复现的是固定结构的四个游戏网络识别，不能顺带给参数编辑和通用自我改进背书。把三个主张分别列出，反而更容易看出新能力确实落在哪里。

这种任务中，权重并不是完全没有结构的数字。网络的输入通道、空间位置和输出动作都已知，参数之间的模式可以与游戏中的空间特征对应。能利用这些线索仍然有意思：它让模型参与模型诊断成为可以尝试的方法。接下来应查的是，当游戏种类、结构或初始化改变时，判断还能不能成立，而不是只换一个更响亮的“理解”标签。

中文讨论提出了另一条值得保留的验证方向：从已知故障修复走向未知问题发现。让强模型在指定领域诊断一个没有预先公布缺陷的小模型，再与等预算的工具搜索或人工诊断比较，能更直接地区分发现能力与已知修复方案的应用。这是后续建议，本期没有执行。对现有结果的合理态度，是保留这一方法的潜力，同时把昂贵的推理时间、失败案例和反馈条件写进能力描述。

这里可迁移的做法，是把训练对象固定为真实工具循环，而不只是最终答案字符串。工具错误、文件状态和后续决策共同构成轨迹；如果训练时换成简化工具，优化的可能是另一个任务。代理保存实际采样的 token，也能减少重新编码或重建对话造成的偏差。但复用SDK不自动等于完整复制生产环境，例如此处终端调用会保留当前目录，但环境变量和后台进程不跨调用保留；依赖持续进程的生产任务需另查兼容性。

最需要在动手前检查的是评估入口。README 中评估默认不开启，评估任务路径又默认继承训练路径；使用者必须主动指定独立任务并启用评估，才能把“训练奖励上升”与“未见任务变好”分开。图中的25步训练曲线只能说明优化过程，32题评估结果是另一项有限自测，本期未独立检查其与训练任务的重叠，也没有跨代码库、跨任务普遍改善的证据。

这使它很适合作为流程学习材料：先选一个有确定测试的窄任务，确认空操作得不到奖励、参考解确实能过，再检查失败到底来自模型还是环境。仓库把基础设施错误轨迹排除出训练损失，避免将环境坏掉误当成模型能力差；实际比较时还应单独报告这种排除有多少。我们核对了文档，未启动训练。

这里有两种方向相反的误差。含糊接口和过窄判分会压低本来完成任务的成绩；访问泄露答案则会抬高并非靠目标能力得到的成绩。只问分数是不是更高，会把这两种问题混在一起。实际审计可以先按失败轨迹分类：参数猜错、业务状态错误、表达等价却判错，还是读取了不应取得的答案。不同类别需要不同修复。

修正自然语言说明也不只是换一种格式。仓库还补了时钟约定、动作返回的标识一致性，以及任务要求与检查位置的对应关系。例如要求把销售策略存到机会记录，却只在备注里检查，便可能惩罚合理实现。对于自己的评测，先检查“题目允许怎样完成”和“测试接受怎样完成”是否一致，比直接加一个更强的总评模型更能定位问题。

作者在专家级知识与推理评测HLE-Diamond的运行中还观察到，监控器逐次过滤工具输出仍可能被跨多次调用的策略绕过，过滤结果本身也可能成为线索。这是具体轨迹提供的风险，不等于所有联网评测都失效。相应的改进应把整个任务的历史纳入检查，并统计正常求解被误挡的比例。私有评测可以减少公开答案泄露，却不会自动修好含糊任务、坏测试和偏置裁判。