结论：外层自主循环本身符合 Agent 赛道的锁定原则，但当前两份草案还不宜直接启用全权限无人值守模式。 主要问题是写入、同步、重试、提交和污染传播的边界尚未闭合；统计规则也不足以证明改动有效。

已只读审阅指定文档、decisions.tsv 最后 40 行及相关实现，并核对官网规则和时间线。没有改文件，也没有连接 Spark 执行操作。

以下简称：

• D：19_outer_loop_autonomy.md
• S：outer-loop/SKILL.md

官网允许锁前改 harness、提示、模型和预算；允许根据已完成 run 选择提交，也允许试参数、看分、再试参数。禁止的是锁后依据中间结果干预，以及从返回分数反解目标属性、再构造预测。因此，自动改进后用新锁启动下一 run 可以属于 Agent Team；不需要把整个开发历史说成“没有人参与”。 官网 §9–10

建议如实描述为：“人制定初始任务、开发并审阅基础设施，在锁前提供约束；VM 上的 Claude Code 根据已结束 run 自主分析和开发下一版本；每个提交对应的锁定 run 自主开发、评估并选择最终预测。人负责账户、合规例外和 P3 提交授权。”人的邮件回复应标明适用的下一锁；不能据此改变当前 run 或替它挑中间节点。P3 人批是本项目授权策略，不是官网要求所有提交必须人工选择。

P0-1：直接同步绕过已有隔离检查，存在锁后改变执行环境的路径。

S §1 写“commit 后在 Spark git pull”，没有运行中 run 的兼容检查。已有 search v8 run 确实封存代码和输入，不能笼统认定所有同步都会破坏锁；但旧 run 和 agent 模式不能自动假定具有同等隔离。现有 scripts/sync_spark.sh 已检查未隔离 run，直接 pull 绕过它。共享 venv、CLI、中继模型路由也不能靠代码 commit 哈希证明固定。

最小修改：D §5、§7 和 S §1、§7 增加部署前门禁：枚举全部运行模式，确认不会读取被更新的共享内容；未隔离 run 存在时延后部署。代码同步使用受保护流程，核对 VM、Spark、测试快照和启动快照的版本一致。禁止 SYNC_FORCE、--allow-dirty、--allow-changed 用于自动正式 run。把依赖安装和模型路由更新也纳入检查。明确顺序为“改动验证→commit→同步核对→新锁→启动”，不能只在最后汇报时 commit。

P0-2：PAUSE 不是两个写者之间的互斥协议，自动 stash 可能收走别人的工作。

D §8 的“交互会话写 PAUSE，外层见到即退出”没有等待确认；S 只在开场检查，外层可能已经在写，Sonnet 子进程也可能继续执行。外层 flock 仅限制外层会话，交互会话没有取得同一把锁。D §9、S §1 的 stash 还可能混合人工改动和自动生成报告。

此外，S §0 所称“只读事项”包含总结、记分；这些会写文件。agent.meta all 更会应用提案、写下一环配置并重建教训表。

最小修改：D §8–9、S §0 规定所有仓库写者取得同一个写锁；交互会话必须等外层及其子进程释放锁后再编辑。外层开发使用独立 worktree，主树脏时不自动 stash。冲突路径只允许读取和分析；报告写入会话独立目录，记分及其他共享写入延后。S §2 将 meta all 拆成 facts/analyze 和显式 apply，后者进入统一写入阶段。

P0-3：整事件重试会重复提交、启动和应用提案。

D §3 规定失败后事件不标完成、下次重试，但 S 在最后才更新状态。若上传成功后记账失败，下一次可能再次上传；若启动成功后邮件失败，可能再开一个 run。已有 G44“同一个 META 不应用两次”不能保证重新分析同一事件后不再次生成、应用提案。submit_browser.py 也没有把服务器提交 ID 与台账更新作为可靠事务。

最小修改：D §3、S §2/§6/§7 定义持久化分步状态，而不是只设 handled：分析、应用、验证、部署、上传意图、服务器确认、记账、启动确认、通知分别记进度。上传前持久化预测哈希和候选 ID；返回不明时先查账户页对账，禁止盲目重交。启动使用持久化请求 ID，重试先查 run/unit。状态原子写入；邮件失败只重发邮件。实施验收必须覆盖“副作用成功、回执写入失败”的故障注入。

P0-4：P2 提交额度单位写错，P3 授权没有绑定具体候选。

D §6、S §6 写“每榜每天 8 次”；官网实际是 P1/P2 每队、每任务、每 UTC 日限额，T2 各榜共同计入任务额度。三个 T2 榜各自动交 3 份即可超过 P2 的 8 份。P3 才是每榜整个阶段两次；还存在独立上传上限。官网 §11

prepare_submission.py 已按任务显示额度，但这是提示文字，不能替代上传前的硬门禁。

最小修改：更正 D/S §6；保留“每榜自动最多 3 份”的内部限制，同时增加任务级总额度检查，计入人工提交、待评分、证据待补和结果不明的上传，并与官网账户对账。所有提交共享锁和额度预留。P3 授权绑定榜、候选预测哈希、锁哈希及第几次正式提交，不能用一封泛泛的“同意”授权后续任意候选。

P0-5：A/B/C/D 范围重叠，自动改动可能改掉自己的护栏。

D/S 把“提示措辞、已有参数”概括为 A，但改变方法、终选阈值或 seed 选择不是措辞修订。C 的“搜索策略、评分组合、锁与证据格式”又与 D 的 ERA 核心、评分器，以及旧决策的锁、账本、提交流程禁区重叠。现有 agent/meta/policy.py 明确保护 Compliance、Reviewer 和评分规则提示；新手册的泛化白名单没有延续这种精度。

最小修改：D/S §5 给出路径、配置键和语义范围表，明确 D 优先。区分“锁前正常追加记录”与“修改账本格式或提交门实现”。合规检查器、审计门、提交授权、权限政策、外层自身手册和控制器不得由被它们约束的普通改动流程自行放宽。新增设计明确替代哪些旧政策，同步 17 号文和 policy.py；不能让不同入口各解释一套权限。

P0-6：审计失败后的数据与教训传播没有闭合，终态也不等于可审计。

D §4、S §2 在审计 fail 后仍顺序写着 meta all、启动下一 run；S §9 才说停止该榜。失败 run 的内容可能因此进入教训表、提示和下一环。现有教训构建读取完成的 archive，没有审计资格过滤。

同时，crashed/stopped 不保证已经完成收尾、回收所有写者、打包证据。流程缺少显式的“封存→verify→package→审计→提交包核验”。

最小修改：D §4、S §2 在 fail/TAINTED 时立即分支：只做诊断和汇报，禁止 apply、教训生成、carryover 和提交；review 的可疑内容同样不得自动进入新输入。对后代和共享来源记录污染关系。可提交路径必须核验收尾、最终输出、证据及哈希；封存后任何变化都使相关审计失效。

官网要求轨迹加至少另一类证据，奖项要求轨迹、提示、harness 三类；每文件 200 MB、全队合计 600 MB。提交还须填写实际框架和模型。官网 §9、§14 S §6 应明确执行并验证这些要求，而非仅调用上传脚本。模型说明还应从调用轨迹补齐 by_op 和实际 fallback，不能只报配置中的主模型。原始记录应在执行时保留，不能事后重建成另一条轨迹。

P0-7：统一流程无法处理当前 T3 agent 模式，可能连续失败后永久停止。

当前 agent.meta.trajectory_facts 明确只处理 search run；没有 archive.sqlite 就退出。教训自动重建只处理 T1/T2。S §7 默认 --continue-from，而 harness 明确拒绝 agent 配置使用该参数。最后 40 行决策却规定 T3 使用 agent 模式。

最小修改：D §4、§7 和 S §2、§7 按 mode 分流：search 使用 archive/G44/carryover；agent 使用会话轨迹、工作区产物、终选和模型调用记录生成报告，重新启动时不用 search 专属续做参数。未支持的模式明确暂停并报告能力缺口，不能把它计作可自动运行的榜。D §10 还应纳入末行决策要求的 G45 缺陷关闭及三环回归前置条件。

P1-1：现有验证与回退规则不足以防止过拟合和噪声驱动改动。

一个 C 加若干 A/B 仍然无法归因：提示、seed、族配额、数据、模型和续做起点都影响结果。子环比父环多搜索了时间，即使完全不改也可能提高；冻结权重下的多 seed 护栏也不是独立训练或独立 run 的证据。18 号文已明确承认，多环用同一真值的适应性偏差不会因更换 seed 消失。

最小修改：在 D §5、§9、S §2 第 6 步及 §5 增加以下最小规则：

• 按影响计数：一个验证批次最多一个会影响结果的改动；A/B/C 都算。纯日志修复可单独验证。
• 预登记：写明假设、主指标、实际有意义的最小增益、允许退化、预算、验证截止和判定条件；看结果后不得改标准。
• 配对对照：旧版与新版从同一封存起点出发，匹配数据、预算和运行条件。不得仅拿下一环与上一环比较。
• 区分独立性：新搜索 run、训练重启、生成 seed、评分 seed 分开记录。最低做两组独立配对，最好三组；样本少只能称初筛，不能宣称统计证明。
• 允许不确定：状态至少有 provisional/kept/rejected/inconclusive。单次小幅跌分不自动回退；确定的正确性或合规退化立即撤销。
• 保留未用于开发的检验：反复被外层查看和据此决策的 B 半、X4/X5 已经是验证集。按批次保留一次性未暴露检验或新的合法数据划分；新 seed 不等于新数据。
• 官网分作探索证据：不重交同一文件测噪声。噪声主要来自产生不同候选的搜索、训练和采样；官网单个赢家分数不足以证明 harness 的平均收益。

基础设施修复主要用正确性、故障率、耗时和资源指标验证，无须强迫每个修复都消耗一次官网提交。

P1-2：“方法族级相对差”是项目策略，不是分数用途的充分合规条件。

把官网信息仅给 Researcher、不直接给 Engineer，仍可能通过 PLAN 进入预测。关键是信息用途：普通候选、参数选择允许；反解目标性质禁止。方法族级信息同样可能被错误解释为目标比例或尺度。

最小修改：D §6、S §3 及 agent/meta/meta_spec.md 明确禁止从返回分数推算目标统计量，并要求数据相关数值或公式注明来源。教训中的官网结论仅支持选择和资源分配，不可充当目标属性的测量证据。台账保留完整分数用于追溯；教训保留样本数、阶段、固定参照 ID 和不确定性，避免动态中位数参照导致历史“相对差”漂移。不要把所有看分后试参、合法文献知识或混合数据隔离下载都误写成官网禁令。

P1-3：金丝雀会把慢启动或服务故障误判为代码退化，并形成无限循环。

S §7 一遇基础设施错误就“停→回退最近改动→重启”。网络、额度、GPU 排队不会因回退代码解决。15 分钟也可能短于合法冷启动训练。would_hang 在 18 号文中仍是观测信号，不应自动升级为终止依据。

最小修改：D §7、S §7 定义分模式的里程碑和错误分类。金丝雀先检查快照、服务就绪、进程活动和数据可读，首个分数另设基于实测的期限。只有证据指向该改动才回退；网络、额度、排队走等待和熔断。每个候选版本最多一次自动修复重试，失败后暂停；失败提案记录指纹和原因，无新证据不再提出。金丝雀改配置后必须开新 ID、新锁；配置不变的崩溃恢复才使用同一 run。

P1-4：资源与额度控制过于粗糙，控制循环可能与 run 内调用同时失去服务。

“四个搜索 run、负载 40、内存 20 GB”没有计入 T3 agent run、回归、数据下载、审计和终选。负载也不代表 GPU 可用。一天 12 个外层会话不能控制昂贵子任务；额度耗尽后依然靠 Opus 处理告警并不可靠。

最小修改：D §3、§7、§9 和 S §4/§7/§9 增加统一资源登记和排队：计入全部模式、测试、下载及终选，预留终选资源，记录 CPU、内存、GPU 和磁盘需求。默认 active board 清单落实“不再开 T2 心脏插值”等现行决策。暂停、告警、对账和恢复探针由不依赖 LLM 的 watcher 执行；已锁定 run 只能使用锁内回退链。对外层设置优先级、并发和故障退避；新增用量限制若采用，应明确是项目政策，并处理它与“用量只统计不设限”旧决策的关系。

P1-5：缺少 run 内模型选择流程；固定外层 Opus 不能替代模型实验。

S 只规定外层及 Sonnet/Codex 分工，没有决定下一 run 各角色、各算子模型的方法。现有 G44 只允许调整 fallback 顺序，不能选择新主模型。

最小修改：D §7、S §7 增加锁前模型计划：从预先认可的模型及客户端配置中选择角色映射、by_op、参数和回退链。更换模型作为独立实验，观察机制完成率、有效节点吞吐、故障、耗时和候选质量，不能只比最好分。新能力或权限组合先小试；模型、客户端和权限均进入新锁，执行时记录实际调用。

P1-6：Data agent 的结果进入下一 run 的手续不完整，同步还可能删除 Spark 新下载的数据。

15 号文已有自动挂载机制，但 D/S 没有数据摄取检查点。17 号文还列出 catalog_auto.yaml 披露核对的缺口。若采用完整 sync_spark.sh，其 data/external --delete 可能删除只存在于 Spark 的自动入库目录和目录表。

最小修改：D §4、§7 和 S §1、§7 增加数据检查点：对本轮新增来源核对许可证、任务适用范围、过滤记录、文件哈希、披露及与本地测试集的重叠；验证下一 run 的实际 manifest。明确 Spark 自动库的权威位置和备份同步方向，禁止 VM 镜像删除这些成果。运行中的 run 只可经锁内既定 Data 流程接纳数据；外层 Scout 结果进入下一锁，不能直接挂入已有 run。

P1-7：P3 缺少阶段切换执行流程，仅禁止自动提交还不够。

默认续做可能在 10-20 后继续 P2 配置、指纹和榜 key。当前浏览器脚本也只有现有验证榜映射。P3 规程要求数据 ready、尺子校准、数据分配及训练/测试用途核对，这些没有接入外层状态机。

最小修改：D §3、§7、S §0/§4/§7 增加 phase_transition：暂停旧阶段的新启动，完成官方数据校验、P3 配置与提交映射、数据分配确认和独立重复 run 计划，再恢复。禁止跨 P2/P3 延续评分指纹。规则或时间线变化进入待核对状态，不能由外层自行解释。阶段判断应依据明确版本和时间，不依赖 Opus 从文档猜日期。

P2-1：dev board 的降级方案仍然依赖人，不能兑现无人值守。

S §8 写“不可用时下一次交互会话补”，用户以后可能不再开交互会话。

最小修改：D §2、S §8 定义可由 headless 会话更新的持久化接口；ArtifactData 只作展示。保存待同步队列和失败时间，由后续外层会话重试。看板至少显示版本、验证状态、资源队列、剩余额度、待授权事项及暂停原因。

P2-2：根因立项过于机械，报告缺少实验身份和历史限制。

“同一 run 两次就立项修”容易把两个节点的同一上游故障算两次，也会把 data/rules 类问题推进修复阶段。“程序 bug 只进教训表”则可能漏掉跨 run 重复的提示或工具缺陷。

最小修改：D §4、S §2 增加根因置信度、共同上游、最小复现、责任层和行动状态；程序 bug 不修改已完成预测，但重复模式可推动下一锁的提示或工具修复。报告模板补齐改动 ID、锁/数据/模型指纹、独立 run 数、未完成验证及对照限制。

P2-3：作业手册还需一次命令和政策一致性校验。

例如 D §4 的审计命令缺少 run 子命令；S 的教训构建示例没有明确榜或 run roots；新白名单、自动提交授权与 17 号文及旧决策仍有冲突。

最小修改：D §10 增加静态命令核对和两种模式的离线演练，把政策替代关系写清。一天 dry-run 只能验证事件发现；启用验收还须验证中途崩溃、上传结果不明、写者交接、额度耗尽和回退后禁止再次尝试同一失败方案。