当 Agent 开始验收 Agent
DORA SSR开源 · 轻巧 · 面向个人创作者的游戏引擎Codex 负责提需求和试玩Dora Agent 负责创作几十款实验后来变成了引擎本身的训练场。DORA NOTE · 01这一次我请 Codex 去当用户最近我做了一件看起来有点绕的事。我让 Codex 扮演一名使用 Dora SSR 的游戏创作者通过 Web IDE 给 Dora Agent 提需求。Dora Agent 负责设计、写代码、构建和修正Codex 则像用户一样继续追问、启动游戏、观察画面、使用键鼠操作再把发现的问题发回下一轮会话。一个 Agent 做游戏另一个 Agent 坐在旁边验收。听上去像两台机器开会甚至有一点“你们 AI 自己商量好再叫我”的味道。但它并不是一个完全脱离人的自动训练系统。做什么实验、怎样才算可玩、哪些问题值得继续追仍然来自我的目标和判断。Codex 承担的是一位耐心用户、产品负责人和测试者的角色把这些要求持续落实到每一轮交互里。这项工作最后在AgentArcade里留下了八十多个项目目录。其中有同一游戏的v2、v3也有不同完成度的实验。归一化以后依然覆盖了几十个不同游戏概念以及大量创作、试玩和返工记录。这些记录让我越来越确信当模型的 coding 能力跨过临界点以后最难的问题已经不只是让它写出代码。更难的是怎样让它知道自己做出来的东西到底对不对。Codex 扮演用户提出需求、Dora Agent 开发游戏再由结果反向改进 Agent 的循环DORA NOTE · 02它看不见画面却给自己做了一双像素眼睛在这些实验里有一个瞬间让我觉得很神奇。当时 Dora Agent 正在修复一款叫《棱镜秘库》的光路解谜游戏。它使用的是 GLM-5.2并不具备视觉多模态能力。换句话说它可以写渲染代码却不能像人一样看一眼截图说出画面是黑的、白的还是少了一个红色的锁。按照通常的产品边界故事似乎应该停在一句很礼貌的说明我无法查看画面请用户进行视觉确认。但它没有停下来。它先调用 Dora 的截图接口把游戏画面保存成 TGA 文件。随后又发现截图落在引擎工作目录里项目内容系统读不到于是它把文件复制到项目可读取的区域再用 Lua 读取二进制数据。TGA 是一种结构相对直接的图像格式。文件开头记录图片类型、宽度、高度、每个像素占多少位以及像素从哪个方向排列后面跟着一串蓝、绿、红和透明度数据。人看到的是一张图程序看到的是一个文件头和几百万个数字。GLM-5.2 就从这些数字开始给自己搭了一种有限的视觉。它解析出截图是 1172×814、32 位未压缩真彩色图像然后统计全白、暗色、蓝紫和红色区域的比例。为了确认画面里不只是“有颜色”它还把游戏的 6×6 棋盘坐标换算成截图坐标去抽样光源、锁、背景和棋盘中心的具体像素。最后得到的结果包括背景角是 R14、G18、B48 的深蓝紫色红色锁是 R255、G40、B40光源中心带有白色高光全白像素占比为 0%。它甚至继续分阶段截图检查放下一块镜子以后光线是否抵达锁锁是否点亮游戏又是否进入下一关。这段过程也不是一次顺滑的表演。它先后遇到了截图路径不可读、异步复制还没完成就读到空文件以及像素循环变量写错等小问题再根据真实结果一项项修正。它最终完成的不是“假装看见”而是为一个自己无法直接感知的问题临时制造了一套可以被数据反驳的检查方法。我很喜欢这样理解这个瞬间它看不见画面却把一张截图变成了一份自己能够批改的像素考卷。没有视觉多模态的 Agent 读取 TGA 截图像素检查棋盘、光源与锁的关键区域当然这双“像素眼睛”仍然有明确边界。它能判断是不是黑屏、关键颜色是否缺失、某个元素是否出现在预计区域却很难回答构图是否舒服、文字是否好读、动画是否自然、操作有没有手感。所以它没有让人的视觉验收变得多余。它真正改变的是在把作品交给人以前一个没有视觉能力的 Agent 也可以主动排除更多确定性的画面错误。DORA NOTE · 03它说游戏正在运行我却只看见了背景有一款打砖块游戏很能说明问题。Dora Agent 已经写完代码逻辑测试通过真实入口也显示runningtrue。从工程状态看一路绿灯似乎已经可以收工。但把游戏真正打开以后画面中看不到砖块、挡板和球只剩下 HUD。原因并不神秘负责绘制深色背景的节点被放在了游戏图形上面于是它兢兢业业地把所有东西都盖住了。程序确实在运行球也可能正在背景后面努力工作只是玩家什么都看不见。《棱镜秘库》真实游戏画面接口与运行状态最终都要落到可见、可检查的作品结果这次失败把三个经常被混在一起的结果拆开了代码能够构建说明程序符合语言和类型规则。入口能够运行说明引擎成功加载了它没有立刻报错退出。游戏能够玩画面看得见输入有效目标、失败和重新开始组成了实际体验。前两项可以由工具快速检查第三项却不会因为状态栏亮起一个绿色标记就自动成立。这也解释了为什么我后来不满足于让 Dora Agent 自己报告“任务完成”而要安排另一个角色真正打开作品像用户一样看一眼、按一下、玩一会儿。不过这个故事的起点还要再往前倒一点。DORA NOTE · 04第一次请 Agent 来是让它进积木工厂我第一次认真把 Agent 放进 Dora不是让它做游戏而是请它进 Blockly 的“积木工厂”。我先手写一个 Dora 专用积木作为模板Cursor Agent 再按同一规则扩展大约三天补出了 5000 多行 API 定义。重点不在代码量而在分工人理解问题、建立范式Agent 把可检查的规则快速铺开。它最初帮我们制造的是做游戏的工具。后来有人追问既然 AI 能造积木能不能让它自己搭我们让模型生成带类型约束的 TypeScript再经编译检查转换为 Blockly于是形成一条小闭环理解需求 → 生成程序 → 编译检查 → 根据错误修正 → 保存为积木这证明了清晰表达加编译反馈可以让 Agent 自我修正。不过编译器只能判断程序是否合法不能告诉它砖块有没有被背景盖住。要继续往前Agent 必须从积木工厂走进真实项目。DORA NOTE · 05从一棵积木树走进完整游戏项目Dora Coding Agent 后来能够成立是三个条件逐渐汇合的结果。Blockly Coder 让我们验证了结构化表达和编译反馈。Dora Web IDE 已经把项目文件、代码编辑、构建、日志和真实引擎放在同一个工作现场。再往后大模型的 coding 能力跨过临界点长程地阅读项目、调用工具和根据错误继续修正才开始真正值得做成产品。问题也随之发生变化。以前我们问“AI 能不能写出这段代码”现在更重要的问题是“它能不能在这个项目里把事情做完并拿出可信的结果”要做到这件事一个 Agent 至少需要三种互相连接的能力。第一是理解现场。它要知道项目里有哪些文件使用什么 Dora API资源放在哪里现有代码采用怎样的结构。没有这些信息再聪明的模型也像第一天上班却没人告诉它仓库在哪的新同事。第二是使用工具。它要能读写文件、构建、运行、检查错误并在方向不对时恢复。工具把“我认为应该这样做”变成“我已经在项目里这样做了”。第三是接受真实结果的反驳。构建器可以驳回错误代码引擎可以暴露运行异常而画面、输入和玩法还会继续追问程序虽然跑了作品真的成立了吗缺少任何一段Agent 都很容易把自己的陈述误当成交付。构建、运行生命周期、视觉与操作三层证据分别能够证明什么DORA NOTE · 06几十款游戏不是一面作品墙最初我也希望随着 Dora Agent 不断改进做下一款游戏需要的轮次会自然减少。真实数据没有这么讨人喜欢。在一批 24 款游戏的历史记录中Codex 共向 Dora Agent 发起 112 次任务产生 1855 次 LLM 轮次。后八款的单次任务略有缩短但每款游戏需要的返工任务反而更多端到端成本并没有呈现清楚的下降趋势。一部分原因是验收标准变严格了。早期容易把“构建通过”当作一个漂亮的终点后来我们会继续启动真实入口、观察画面、尝试键盘、触摸和手柄输入再根据问题发起下一轮。质量要求提高当然会增加返工。但记录也揭示出真正的瓶颈Agent 常常能很快做出第一版却不能在第一轮里完成从实现到试玩的完整闭环。打砖块的图层遮挡只是其中一个例子。还有一款贪吃蛇入口显示正在运行纯逻辑测试也通过蛇却一直停在原地。原因是同一个节点调用了两次schedule()。在 Dora 中第二次调度会替换第一次负责重绘的回调把负责游戏推进的回调挤掉了。它不是崩溃而是一本正经地静止。输入问题也反复出现过键盘短按被帧轮询漏掉代码声称支持手柄实际却从错误位置读取控制器触摸按钮在小窗口里缩到四十多个像素全屏以后 HUD 小得像写给蚂蚁看的说明书。这些问题很难只靠阅读源码统一发现。它们要求验收者真的看见画面、按下按键并把“哪里不对劲”重新翻译成下一轮明确反馈。所以这几十款游戏对我而言不只是一面等待展示的作品墙更像一组不断把 Agent 打回来的实验。四款真实运行样本及其分别达到的构建、生命周期、视觉和操作证据层级DORA NOTE · 07游戏在改Agent 也在改当同一种失败重复出现继续给每个游戏补一句更长的提示词并不是最有价值的做法。我们会追问这是不是 Dora Agent 本身缺了一项能力或者缺了一条来自引擎的反馈例如Agent 写完代码却不断搜索 API、不肯先构建我们就让空项目减少无意义探测并形成“小批编辑—构建—按错误修正”的节奏。上下文压缩后它忘记已经做到了哪一步又从头读取文件我们就在摘要中保留当前错误、已改文件和精确的下一动作。runningtrue容易制造假象我们把构建、运行和人工/视觉验收拆成不同结果并补充真实入口的加载、状态查询和停止清理。坐标、图层、schedule、HUD 和输入反复出错我们把这些 Dora 特有知识写进 Agent 真正会读取的 Skill而不是希望模型每次临场猜对。还有一类问题看起来更像程序员的代码习惯我却把它们当成了运行规则。Dora Agent 写的是 TypeScript交给引擎运行的却是转换后的 Lua。两种语言很像一对能聊得来的同事但在一些小地方会突然互相误会any会让类型检查提前放弃追问裸null不适合直接表示 Lua 里的“没有”Lua 数组也留不住由undefined或null形成的空位。更隐蔽的是JavaScript 里的数字0可以被当成假Lua 里却只有false和nil才是假。于是我没有只把这些经验塞进 Agent 的提示词里而是直接修改了 Dora 内置的 TSTL 编译器。显式使用any编译器会报错并停止转译写下裸null它会明确告诉 AgentLua 没有对应的null请使用undefined。对于if、循环以及、||里的条件它也会检查代码是否误用了 JavaScript 的真假值习惯要求把“有没有”和“是不是”写成显式比较。Skill 仍然会提前告诉 Agent 正确写法具体项目的记忆也会记录怎样修正但编译器是最后那道不会忘记的门。它们不是代码风格洁癖而是两种语言之间的交通规则更重要的是这些规则一旦进入编译器就不只服务于某一次 Agent 会话而会保护以后所有使用 Dora TypeScript 的创作。有一次Dora Agent 执行的测试还让引擎内存一路增长到约 30 GB我只能强制退出。于是工具能力的另一面也变得很具体Agent 不只需要更多权限还需要超时、取消、对象数量监控和可靠清理。否则一位过分勤奋的新同事也可能在几秒钟内把仓库塞满。这套过程不是传统意义上的模型训练。我们没有用这些游戏去更新大模型权重。被持续训练的是围绕模型工作的整个系统工具怎样反馈Skill 提供什么知识长任务如何保存进度什么情况允许继续什么证据才配得上“完成”。DORA NOTE · 08当 Loop 本身也成为工程对象Agent 原本就依靠 loop 工作读懂任务采取行动接收结果再决定下一步。但做完几十款游戏以后我开始把视线从“这一轮能不能写对”移到了 loop 本身。在内层循环里Dora Agent 围绕一款游戏反复编辑、构建、运行和修正。在它外面还有一层更长的循环Codex 连续扮演用户创造试验样本、试玩验收、归纳共同失败再去修改 Dora Agent 的工具、Skill、编译器和安全机制最后交给下一批游戏复测。我更愿意把这件事称作Loop 工程。它不是让模型关在房间里无限思考而是把目标、反馈、状态保存、评估标准、调用预算和安全边界都做成可设计、可观察、可改进的工程系统。Agent 循环工程流程图图中的回路有两个出口。某款游戏自己的问题会回到 Dora Agent 继续修正如果同一种问题跨作品反复出现测试 Agent 就把它提升为系统问题推动 Agent 的工具、知识、编译器或安全机制发生变化再发起下一轮测试。这样一来交给 Agent 的就不再只有某项软件功能。连“怎样把这类功能越做越好”的一部分工作也可以交给 Agent 长时间运行制造样本、发现问题、修改系统再用新样本检验自己。第一次意识到这一点时我确实觉得我们已经半步踏进未来了。当然这里的“自我演进”不是模型偷偷改写自己的权重更不是让它脱离人的目标无限运行。人仍然决定往哪里走、开放哪些权限、愿意花多少成本以及什么证据才能通过验收。变化在于人不再需要亲手推动循环里的每一个动作Agent 已经可以参与改进承载自己的那套软件系统。DORA NOTE · 09改进有效吗有迹象但还没有魔法为了避免只拿越来越复杂的不同游戏互相比较我们还做过一组小规模对照固定同一个普通用户需求、模型、验收标准和十分钟上限不把技术实现与测试步骤偷偷写进提示词。在 DeepSeek 的三轮小样本中改进版相对 baseline 把 LLM 请求从 218 次降到 137 次。按我实际试玩的结果能玩的样本从 1 个增加到 2 个。这个结果令人鼓舞但三对三远远不够写成稳定成功率。它只能说明在那组条件下我们同时看到了 loop 减少和可玩产出增加改进版依然有失败作品质量也并不一致。截至 2026 年 8 月以我在 Dora Agent 中的使用体验DeepSeek V4 Pro 已经可以作为跑通主流程的可用基线GLM-5.2 及更强模型在长程理解、工具调用和连续推进上表现得更强、更省心。这也不是一份永久的模型排行榜。型号会变化同一个模型面对不同项目也会有很大差异。真正比较稳定的判断是模型越强Agent 能够主导的工作范围确实会扩大而它能否把能力落到游戏里仍然取决于工具、反馈、时间和调用预算。DORA NOTE · 10Agent 可以主导但“完成”不能由它自己宣布我并不认为 Dora Agent 永远只能做一个等待逐行指令的助手。如果给它更强的模型、足够的时间和合理的调用预算它已经有能力主导玩法细化、工程实现、构建和多轮修正。人可以深度参与每个产品选择也可以只提供创作目标、资源边界和验收标准把大部分中间过程交给 Agent。这不是“辅助或取代”的二选一而是一条会随条件移动的刻度。不过Agent 主导得越多真实反馈越重要。模型可以大量完成代码甚至参与设计但游戏是否可见、可控、可理解、可重新开始仍要由运行中的作品回答。回头看Dora Agent 的路线很像一次逐渐扩大的实习。一开始它按照模板帮我们造积木后来它学会用结构化文本自己搭积木再后来我们把完整项目、构建工具和真实引擎交给它让它开始为结果负责。而这一次我们又安排另一个 Agent 坐到了用户的位置上。它不只是鼓掌也会打开游戏按下按键然后认真地说“等一下球呢”这句有点扫兴的反馈可能正是一个会写代码的 Agent 走向一个会完成作品的 Agent中间最重要的一步。而当它还能把这次失败变成下一轮的工具、规则和编译器改进时改变的就不只是一款游戏而是制造下一款游戏的循环本身。资料来源Dora SSR x Blockly—这种感觉我从未拥有Dora SSR x AI x Blockly 低科技和高科技的碰撞DeepSeek API 更新日志DeepSeek V4 Pro 发布说明GLM-5.2 官方文档Dora SSR让游戏创作更轻一点也让新的尝试更容易发生。