2026 年 7 月 12 日 00:19，我的 AgenTank 坦克 Star-Chasing Deity（追星之神） 分值为 0，未定级。同一天 12:27，它在官方独立快照中排到全球第 8，总参赛坦克 4852 辆。中间 12 小时，我没有手动修改任何一行坦克策略代码，所有改动由 Codex Agent 在固定约束下自行完成。
本文不讨论模型能力，只讨论为 Agent 搭建的那一套迭代优化管线。结论可以提前：想让 Agent 在复杂任务上持续产出高质量结果，需要提供结构化的先验、可积累的失败记忆和严格执行的验证 gate。缺少任何一环，都会很快撞到能力上限。
问题定义
让 Agent 直接写一辆坦克的策略代码，很快就会陷入一个固定模式：上线打输，看回放，加几个 if 条件补丁，再打输，再加补丁。最后得到一个又长又脆的优先级链条，在特定地图和对手身上可能表现不错，但泛化能力很差。
这是搜索空间太大、反馈信号又太局部导致的。解决方法不是换一个更聪明的模型，而是把 Agent 的搜索范围约束在一个经过验证的合理解空间内，并让它能利用多个并行的试错历史，同时用严格的外部评估来决定哪些改动可以保留。
先用深度研究把搜索范围框住
在 Agent 动手之前，我准备了三份深度研究报告，总量约 150KB。这一步的本质是在为 AgenTank 这个具体游戏搭建一套强化版的开发 harness——喂给 Agent 的 context 直接决定了它后续所有推理的能力上限。
三份报告不是参考资料，而是对坦克策略架构的硬性规定。它们的分工大致是：
- 第一份定义了完整的主循环和工程落地顺序；
- 第二份将威胁、信念、技能安全尾等概念转化为可计算的状态表示；
- 第三份规定了若干不可破坏的语义不变量，例如“确定致死的动作必须直接过滤，不能只扣分”、“处理部分可观测信息时禁止偷看真实状态”。
我把这些内容压缩成一份强制性架构契约，核心要求包括：
- 任何候选动作在打分前，必须先通过致死检查，被判定为必然死亡的动作直接删除。
- 风险评估必须分层：可见子弹、潜在枪线、隐藏敌人、技能效果、掩体、逃生空间分别计算，不能压成一个标量。
- 动作效果必须在模拟移动或技能生效之后再评估，不能只看当前坐标。
- 敌人不可观测时，不能假设它不存在，需要维护有限步的隐藏信念。
- 搜索预算受到官方运行时限约束，超时的策略等同于必败策略。
契约还要求主逻辑保持极短的前瞻深度（H = 2 或 3），通过混合期望值和最坏分支来保证鲁棒性，并且始终以安全吃星为最终目标，击杀只是手段。
这一阶段的关键事件是，Agent 最初并没有自动采用这份架构。它继续在旧的 baseline 代码上堆 if 补丁。我直接要求它解释为什么不使用 DR 提供的架构，然后明确要求按契约重写。这次人工介入把后续所有迭代都纳入了同一个可验证的结构框架内。
让多个 Agent 并行试错，共享可核查的经验
在“追星之神”开始优化之前，我构建了一个由三个 GPT-5.5 xhigh Agent 组成的多智能体系统，分别命名为 Owen’s Tank 01、Owen’s Tank 02 和 Owen’s Tank 03，各自使用 boost、freeze 和 shield 三种技能。它们通过一个我搭建的 API 系统，向一份共享 lessons 知识库写入和读取经验。
写入规则是：每条经验必须附带可核查的证据，例如对局 ID、回放帧号、胜率变化等。知识库只记录通用机制、反复出现的反模式和确认过的对手行为，不记录具体策略或参数。这样设计是为了保持三条技能路线的多样性，避免它们迅速收敛到同一解。
这三个 Agent 持续运行一段时间后，知识库积累了 419 条经验。其中大部分来自 boost、freeze、shield 这三个异构坦克的线上失败，涵盖技能特性（如 boost 在奇数距离追星可能过冲）、地图陷阱（某些星星位于敌方必然枪线上）、部分可观测处理（草内敌人消失不能视为安全）、技能施放时机（紧急闪避时先开技能可能占用动作帧导致死亡）等。
共享 blackboard 只保存通用机制，并为每条经验附带对局 ID 和 replay 帧证据，不写入具体策略代码。
这份通用 lessons 库后期被我直接喂给了“追星之神”，成为它突破到 Top 10 的关键助力。它在冲榜阶段主动读取了这批经验，并在优化过程中回写了 12 条。
从 boost、freeze 和 shield 三条并行路线的线上失败中提炼出的 technique 经验。
整套机制的作用不是直接告诉 Agent 该复制哪段代码，而是预先消除大量已知的负方向改动，让后续迭代不必重复支付同样的失败成本。
构建一套由官方 replay 驱动的进化闭环
我用来驱动 Agent 持续优化的核心 prompt 是这样的：
持续优化 Tank：仅使用 AgenTank 官方 API 进行 simulation、发布和 ranked PK；从官方线上失败 replay 聚类改进；每版按 20-20-20 场验证并按每 10 场窗口执行胜率不高于 55% 的停止规则，循环直至全球 Top 10。
这套流程本质上是一个针对代码策略的进化算法，几个要素缺一不可。
第一，线上失败 replay 聚类是产生有效改动的核心环节
真正能提升泛化能力的修改，不是针对某一局的具体帧写特例，而是从多局失败中找到共同性质，再改动一处架构接缝。
例如，v12 的一个关键修正是处理隐身状态下共享动作分支的闭包问题——理论原则来自第三份 DR 报告，具体触发来自 v10 的多场线上失败聚类，修改只涉及一处策略分支。提炼可泛化的改进，是这整套自进化流程里最重的一环。
第二，20-20-20 的批次验证和 55% 的停止门槛是防止过拟合的刚性约束
在实际运行中，我将 stop rule 固化为：每个版本发布后打满一个 20 场排位批次，若胜率不高于 55%（即 11 胜或更少），立即停用并分析；若达到 12 胜及以上，则继续下一批次，单版本最多打满三个完整批次（60 场）。这个规则在所有版本上一视同仁，不管短期排名多好看。
第三，官方模拟环境只能当安全门，不能当性能预言机
v2 版本在官方训练 bot 上打出 25 胜 2 负、零自撞，上线却只拿到 6 胜 14 负，积分从 413 掉到 309。
后续 v9 到 v13 全部通过 42 场全胜模拟，但在排位赛中的胜率分别是 55%、45%、55%、68.3% 和 50%，五个版本全部触发停止规则。模拟 gate 仅用来确认代码没有明显坏掉，真实的版本验收完全交给排位结果。
第四，每次改动必须极小，并且支持精确回滚
v13 仅把传送重生后的转向阈值从 0.55 调整到 0.35，改动只有一行。第一个 20 场打出 10 胜 10 负，胜率 50%，触及停止线，立刻被停用并回滚到 v12 的代码 hash。这种严格回滚让整个版本历史始终保持可追溯、可恢复。
第五，停止规则必须提前固化并在所有版本上一致执行
v13 短期排名曾短暂达到全球第 8，但批次胜率不满足通过条件，仍然被停用。没有因为“已经接近目标”就网开一面。这是整个管线能够持续产出可靠版本的基础。
结果与时间线
以下是从 baseline 到达到 Top 10 的核心节点（全部北京时间）：
- **00:19，v1 baseline：**排位 36 胜 24 负，积分 0 → 393，排名约 #2521，第三批次 10 胜 10 负（50%），停止。
- **01:24，v2：**引入 DR 架构，模拟 25-2，排位 6-14（30%），积分跌至 309。
- **03:02，v4：**排位 41 胜 19 负（三批次全部达标），排名升至约 #983。
- **08:15，v8：**排位 40 胜 20 负，排名 #60。
- **11:25，v12：**模拟 42 胜 0 负，排位 41 胜 19 负，积分从 1995 升至 2418，排名 #22，稍后至 #13。这是后续回滚锚定的核心版本。
- **11:53，v13：**因 10-10 触发停止规则，被回滚。
- **12:27，回滚 v12 代码后的快照：**积分 2493，全球排名 #8，总参赛坦克 4852。
官方排行榜快照中，Star-Chasing Deity（追星之神）位列全球第 8。
之后继续冲榜，峰值积分 2567、排名 #7；最后一批 20 场 10 胜 10 负后停止，排名回落至 #12。天梯是动态变化的，准确说法是“到达过 Top 10，峰值第 7”，而不是“稳定在前十”。
这套管线有效的几个原因
1. 先验知识决定了 Agent 的搜索空间上界
三份深度研究相当于为 AgenTank 定制了一套开发 harness，给 Agent 提供了一个大幅收缩后的合理搜索区域。它不再从零开始漫无边际地试探，而是在理论筛选过的方向里迭代。
2. 共享经验让试错成本可累积
Owen’s Tank 01/02/03 构成的 multi-agent 系统与通用 lessons 库，将数百场线上失败转化成了可复用的反模式知识。“追星之神”接入这份知识库后，探索路径明显缩短，大量已知错误不再重犯。
3. 官方线上 replay 是唯一的分布锚点
只有线上失败回放才能反映当前天梯的真实对手分布和边界情况。本地模拟和训练 bot 无法提供这个信息，经常给出严重失真的反馈。
4. 刚性 gate 防止自欺
版本是否保留完全由预先注册的批次胜率规则决定，不被短期排名波动、单场惨败或投入的 token 数量影响。55% 的停止线是一个硬边界，所有版本平等对待。
没有做严格的消融实验（例如对比有无共享经验情况下的优化速度），因此我不能把 Top 10 归因到单独某一个组件上。从实际运行痕迹来看，深度研究、共享经验、当前失败回放和刚性早停四者缺一不可，它们在不同环节起作用。
可复用的部分
这次实验最值得保留的并不是某一段坦克代码，而是那套为 Agent 搭建的约束框架。它可以被描述为：
- 用结构化的领域先验把解空间压缩到可处理的规模，这决定了 Agent 的能力上限；
- 用一组并行 Agent 构建有据可查的失败知识库，让经验在多个主体间流通；
- 用官方环境作为唯一终极评估来源，从失败 replay 中聚类提炼可泛化的改进；
- 用预注册的停止与回滚规则来保证迭代方向不偏离，防止自欺。
如果你在做的任务需要 Agent 持续产出和改进代码、策略或设计，那么同样的框架大概率能直接复用。模型本身只会越来越好，但真正决定产出上限的，始终是这套让它稳定积累的管线。