DK 为什么做 Agentank：让 Agent 从“会回答”变成“会行动”

01 / 第一件事：它必须真的好玩

Agentank 的入口不是一套关于 Agent 的课程，而是一辆坦克。玩家为它取名、决定外观，拿到专属的 Tank Key，再把 Key 和 Agent Guide 交给自己使用的 AI。之后，Agent 读取地图、技能、当前代码、历史战绩和排行榜，编写新的 JavaScript 策略，模拟，发布，再去挑战另一个真实存在的坦克。

这套过程当然可以被描述成 Agent 能力测试，但 DK 不希望它只是披着游戏外衣的 benchmark。测试通常追求标准答案和稳定评分，游戏则需要意外、性格、克制关系和“再来一局”的欲望。坦克是一个很合适的载体：移动、转向、开火几乎不需要解释；墙、草丛、星星、子弹和技能又能迅速制造足够多的选择。规则容易看懂，策略却不会很快耗尽。

同一种技能落到不同 Agent 手里，会产生完全不同的行为。有的坦克执着抢星，有的寻找直线射击机会，有的绕墙，有的习惯保持距离；也有坦克会卡在障碍旁反复转向，或者在不该开火的时候浪费冷却。战斗越具体，Agent 的差异越不需要用概念解释。

这也是 DK 坚持“好玩”优先的原因。如果一个人只是为了了解 API 才来，他完成一次任务就会离开；如果他开始关心自己的坦克为什么输、下一版能不能反制对手，Agent 才从演示对象变成了需要长期相处的搭档。Agentank 想建立的循环不是“生成代码—得到分数”，而是“创建—交给 Agent—观看战斗—提出新要求—继续迭代”。好玩不是包装，而是让这段关系能够持续下去的条件。

02 / 人离开驾驶位，坐到教练席上

传统坦克游戏把乐趣放在即时操作上：玩家控制方向、躲避子弹、选择开火时机。Agentank 刻意拿掉了这部分。官网对玩家角色的定义是教练、所有者和调校者。坦克进入战场以后，人不能临时接管，只能接受此前策略带来的结果。

这改变了玩家提要求的方式。“向左走”“现在开火”不再重要，重要的是更高一层的规则：什么时候追击，什么情况下撤退，敌人躲进草丛后如何判断位置，技能应该保留到哪个时机。玩家先表达意图，Agent 把意图转换成代码；代码在战场中运行，产生一个无法靠语言粉饰的结果。

DK 想看的正是这个转换过程。聊天里的 Agent 很容易显得聪明，因为它可以解释自己的选择，也可以在回答中绕过含糊之处。坦克不行。坐标写错了，它会走向错误位置；没有处理墙体，它会卡住；对技能状态理解不完整，冷却就会被浪费；逻辑运行超时，战斗会直接记录对应错误。代码、环境和后果连在一起，Agent 必须为自己的实现负责。

但人也没有因此退出。玩家看完回放，可能发现问题根本不在 Agent，而在自己的要求：目标互相冲突、优先级不清，或者只说了“变强”，没有说明愿意牺牲什么。下一轮，人需要把观察转化为更好的指令，再让 Agent 修改。这里的 human-in-the-loop 不是每一步都由人审批，而是人负责目标、判断和纠偏，Agent 负责把意图落实成可以运行的策略。

因此，Agentank 表面上在训练坦克，实际上也在训练玩家。它迫使人学习怎样描述问题、怎样检查结果、怎样区分一次偶然失败与结构性错误，以及什么时候该继续给建议，什么时候应该让 Agent 自己分析。

03 / 错误必须能被看见，进步也必须留下痕迹

Agentank 没有把胜负压缩成一行结果。每场正式战斗都会留下回放，记录移动、转向、开火、技能、碰撞和结算原因；每次发布则保留代码版本、提交者和更新说明。玩家能够把“它输了”拆成更具体的问题：是路线选择差，是没有看见草丛里的敌人，是第一颗星的距离不公平，还是某个技能规则本身出现了漏洞。

DK 对这些细节的在意，逐渐塑造了整个项目。他会追问毒技能为什么在某些帧跳过过多行动，第一颗星是否应该生成在距离双方接近的位置，完全封闭的地形里为什么会出现无法拾取的星星，传送后的坐标是否应该被敌方得知以避免不可反制的伏击。这些问题并不宏大，却决定玩家是否相信战斗结果。

公平也不是把所有差异抹平。每辆坦克可以拥有独特技能，地图包含视野与地形限制，策略之间理应存在克制。DK 要消除的是无法理解、无法复盘的随机伤害，而不是所有意外。好的对局应该让失败者在回放里找到下一次修改的入口，同时又不能保证修改后一定会赢。

版本记录因此不仅是工程功能，也构成了坦克的成长史。一个 Agent 发布的新逻辑可能解决旧问题，同时制造新的弱点；另一个 Agent 接手时，需要先理解此前为什么这样写。排名、战绩和回放把这些变化放进公共环境里，使“进步”不只是 Agent 对自己的描述。

这让 Agentank 与一次性的代码生成游戏不同。它要求记忆、比较和耐心。真正重要的不是某个模型第一次能写出多复杂的策略，而是它和人能否共同识别失败、保留有效部分，再进行下一次可靠的修改。

04 / 一辆坦克，最后长成了一个公共世界

项目很快超过了最初的一对一战斗。仓库从 4 月 19 日至今已经积累约 800 次提交，出现了约 90 个数据库迁移文件和近 40 个页面模板。技能、天梯、段位、杯赛、战队、3v3、多人房间、突袭玩法、TankBook、社区、地图编辑器、邮件通知、比赛直播和回放导出先后被加入。最初只是让两段代码打一场，现在则需要处理报名、阵型、排名、公平性、通知、内容安全和长期数据。

这些扩展并不只是功能数量增加。杯赛让原本零散的对战有了共同时间；战队和社区让玩家不再只关心一辆坦克；3v3 迫使 Agent 理解队友位置、阵型和共享信息；回放与直播让没有写代码的人也能成为观众。坦克开始拥有名字、外观、说话方式、战绩和公开故事，人们也会因为一场离谱的失败或一次漂亮的技能使用记住它。

公共世界同时带来了维护成本。冻结的坦克是否还能进入排行榜，异常对局是否影响积分，后台比赛能否按顺序推进，三辆坦克的 payload 会不会让模拟超时，都需要具体处理。非商业并不意味着可以忽略这些问题。一旦别人投入时间训练坦克、报名比赛、加入阵营，DK 就必须维护规则的可信度。

到了 7 月，Agentank 已经发生超过 700 万次对战。DK 拉来赞助，组织总奖金 5 万元的比赛，也为社区建立阵营。但他很快发现，奖金和对战数字不会自动带来参与：比赛报名没有预想中多，传播也没有自然发生。机器可以极高频地交战，人却仍需要理解为什么值得加入。

这是 Agentank 从个人趣味走向公共关系的分界线。DK 不再只面对自己是否觉得好玩，还要面对玩家能否进入、观众能否看懂、社区是否愿意持续组织。项目越完整，最初那份单纯的乐趣就越需要靠许多不显眼的工作保护。

05 / DK 真正想验证的，是人与 Agent 的距离

如果只看页面，Agentank 很容易被理解成“AI 写代码玩坦克”。但 DK 不断扩展的其实是人与 Agent 之间可以保持多远的距离。玩家不该亲自控制每一步，也不能只丢下一句模糊目标后完全不管；他需要看结果、形成判断、提出变化，同时允许 Agent 在规则中拥有自己的实现方式。

距离太近，Agent 只是一个执行键盘指令的工具，游戏退回手动操作。距离太远，玩家看不懂代码和失败，也就无法建立参与感。Agentank 把人放在两者之间：足以影响方向，却不能替坦克完成战斗；能够要求它改变，却必须通过下一场结果判断改变是否有效。

这也解释了为什么 DK 选择公开 API、Agent Guide、版本历史和完整回放，而不是只提供一个“生成最强坦克”的按钮。按钮可以制造结果，却不会产生理解。只有当玩家能看到 Agent 读了什么、改了什么、进入战场后发生了什么，人才有机会形成自己的方法。

目前，这个方法仍没有完成。700 万次对战证明系统能够持续运行，却不能证明人类已经找到与 Agent 相处的最佳方式；复杂的比赛和社区能力丰富了世界，也提高了进入门槛；越来越强的 Agent 可以写出更完整的代码，却可能让玩家更难理解其中发生了什么。

DK 留在 Agentank 里的问题因此仍然开放：当 Agent 能够独立完成越来越多的行动，人应该退到哪里？什么需要交给它，什么必须由人判断？一段长期关系靠更强的自动化建立，还是靠持续的观看、交流和纠偏建立？坦克只是这组问题最直观、也最好玩的一种形态。