游戏 Agent 演进之道
游戏 Agent 的目标是把用户需求转换成一个可以运行的游戏。这个过程包含需求分析、素材生成、代码修改、测试和发布，需要模型与业务系统共同完成。
本文记录我们在实现这条链路时做过的几次调整，依次介绍 Prompt、多 Agent 分工、Skills、工具接口和任务恢复。每一部分说明原来的实现、遇到的问题，以及后续采用的处理方式。原生引擎的接入状态以本文最初整理时为准。
1. 通过 Prompt 组织开发流程
1.1. 初始实现
第一版使用 Python 实现。我们在一份较长的 Prompt 中描述游戏开发过程，包括理解需求、整理策划、准备素材、制作地图、编写玩法、测试和部署。
Prompt 同时提供工程约定：使用什么技术栈，地图采用什么格式，素材怎样加载，最后需要交付什么。模型根据这些信息调用工具，把每一步的结果交给后续步骤。
这套实现的主要作用，是把业务知识和开发步骤放到一个明确的位置，使整条链路能够开始运行。后续增加的规则，则需要区分它究竟在解决哪一类问题。
1.2. 规则对应的问题
例如，模型不知道地图文件的格式，可以补充格式说明；模型启动命令后拿不到剩余输出，需要补充命令会话接口；素材已经生成，恢复任务时却找不到，需要保存素材任务与结果的关联。
这三类问题都可能表现为“游戏没有完成”，但修改位置不同。只有第一类可以直接通过补充知识解决。工具或业务状态没有接好时，增加文字提醒仍然缺少实际的执行依据。
因此，Prompt 中的内容需要能够追溯到具体问题。项目约定和素材能力属于持续需要的业务信息；为了绕开某个模型弱点而加入的固定步骤，则需要在模型更新后重新验证。
2. 多 Agent 分工
2.1. 角色划分
游戏任务变复杂后，我们开始按照能力拆分 Agent：主 Agent 组织任务，开发 Agent 修改代码，配置 Agent 处理地图和音频，素材相关 Agent 生成资源。角色、动画、封面等工作也有各自的入口。
每个 Agent 有自己的 Prompt 和工具集合，能够单独调整。适合独立完成的素材任务，也可以并行执行。
但子 Agent 拥有自己的执行过程，主 Agent 已经知道的信息，需要通过输入显式传过去。任务完成后，结果还要传回主 Agent，才能继续后续工作。
2.2. 上下文交接
以“给角色增加二段跳”为例，开发 Agent 需要读取角色移动代码、跳跃状态、动画和音效的使用方式。如果用户同时要求“保持原来的移动手感”，这条限制也要进入子任务输入。
一次交接至少涉及：
- 本次需要完成的修改；
- 必须保留的行为和用户限制；
- 使用哪个工程与工作区；
- 已经完成的相关工作；
- 返回什么结果，后续由谁接着处理。
我们后来还去掉过主 Agent 的 Bash 入口，把编码进一步交给开发 Agent。这样工具权限更加集中，但主 Agent 需要通过子任务才能检查工程或完成一次小修改。
代码、地图配置和素材接入虽然属于不同专业，却经常共同完成同一个需求。拆开以后，各个 Agent 都需要重新理解相关部分，主 Agent 再整合局部结果。交接遗漏约束、结果不足以判断是否完成，都是需要处理的问题。
因此，角色名称只能说明知识分工，还不足以确定执行边界。是否能够并行、是否需要隔离权限、结果是否容易交接，都需要结合实际任务判断。
3. 主 Agent 与 Skills
第二版将编码能力放回主 Agent，同时通过 Skills 按需提供专业方法。
这里的 Skill 是完成某类工作需要的方法、说明和辅助资源。加载 Skill 后，相关知识进入当前工作上下文；启动子 Agent 则会建立一段独立执行。两者有不同的用途。
处理地图时加载地图格式与操作方法，接入素材时加载对应的资源使用说明。仍然由主 Agent 理解需求、读取工程、修改文件，再检查修改结果。
这样，配置修改和代码修改可以在同一上下文里连续完成。用户刚确认的限制也保留在原会话中，减少了重复组织子任务输入的工作。
独立素材生产、封面制作等任务仍然保留自己的执行入口。这类工作有相对明确的输入和输出，外部执行结束后，可以通过任务编号与产物引用交回主流程。
调整后的分工可以归纳为：专业知识通过 Skill 提供，需要独立权限、生命周期或并行执行的工作，再使用独立任务。这一划分仍然要通过任务完成情况验证。
4. 工具接口与模型上下文
4.1. 工具集的适配
模型接入后，需要同时提供它能够使用的工具。工具的名称、参数、执行行为和结果格式，共同组成调用协议。
我们逐步对齐了 Codex 和 Claude Code 两类基础工具，并按所选模型装配相应工具集。
这里仍由自研 Runtime 组织模型循环。采用 Codex 风格的工具接口，并不表示已经由原生 Codex 执行任务。
以命令工具为例，启动测试以后可能出现三种结果：
- 命令已结束，返回输出与退出码；
- 命令仍在运行，返回执行会话编号，之后继续读取输出；
- 执行出错，返回能够定位原因的信息。
后续还需要通过原会话发送输入、中断命令，以及在 Runtime 重启后重新查询。若命令仍在运行，工具却只返回一段文本，模型就无法判断是等待、重试还是继续修改。
文件工具也一样。读取范围、补丁格式和修改失败的反馈，需要与实际工作方式对应。对齐工具名称之后，还需要逐项检查这些行为。
4.2. 上下文组织
每次模型请求包含本轮指令、工具定义、历史消息，以及新的工具结果。运行时间增长后，需要压缩较早的历史，并保留后续执行所需的信息。
模型切换时，还要重新核对推理参数、工具调用与结果的对应关系，以及缓存条件。例如，把已有历史作为稳定前缀继续追加，和每轮重新排列同一批内容，可能有不同的缓存效果；实际命中情况仍以服务端返回的使用信息为准。
这些内容通常归入 Harness，也就是模型外层组织工具、上下文和执行环境的部分。模型能力变化后，Prompt、工具协议和上下文组织需要一起检查，不能只修改模型名称。
5. 验证与修复流程
5.1. 固定检查流程
我们曾增加一套较完整的质量流程，将用户意图、素材、运行证据、检查和发布串起来。对于“玩法保持不变，场景改成雪地”这类需求，流程需要一直保留修改目标与不变条件。
其中还包含固定检查多个视口，以及开始、胜利、失败、重试等场景。检查得到问题后，再触发修复和重新部署。
问题出在检查范围与当前需求不一定一致。用户只要求手机竖屏时，其他方向的检查可能触发额外修改；每次修改又需要重新运行和部署。实际案例中出现过消耗和等待增加，以及围绕检查结果反复修补的情况。这里是个案观察，不据此给出整体效率结论。
5.2. 按任务确定验证范围
调整后，我们把素材使用、工程接入和预算安排提前到部署前处理。验证仍然保留，但检查范围根据当前需求确定，修复也结合问题影响与剩余预算决定。
以手机竖屏游戏为例，本轮优先检查竖屏的核心游玩路径。其他视口的问题可以记录，但是否必须在本轮修复，需要根据交付范围判断。
这样调整之后，需要保留的记录包括：本轮验收条件、执行过的检查、检查结果，以及决定继续修改或结束的依据。减少固定步骤之后，仍然能够说明最终交付经过了哪些验证。
6. 异步任务与恢复
6.1. 几种不同的执行状态
游戏能力接入 Go 后端以后，会话、执行记录和费用由运行时及业务服务管理。一次游戏生成又包含多个异步过程，不能用单一状态概括。
模型结束一轮输出时，素材可能仍在生成。素材完成以后，需要接入工程；游戏发布完成以后，客户端还需要收到版本信息。系统应当保存这些状态及其所属任务，再组合成用户看到的进度。
否则，模型的一次结束可能被误用为整个任务成功，外部任务已经完成也可能因为消息丢失而一直显示等待。
6.2. 恢复记录
恢复一项工作时，需要读取它所对应的持久记录。
上下文检查点保存整理过的历史和覆盖位置，用于继续模型执行。素材任务记录保存外部任务编号与产物引用，用于查询原操作。事件 Outbox 保存待发送事件，用于失败后补发。用户轮次与运行记录关联，使恢复的结果仍然属于原来的请求。
素材是否成功、费用是否发生、版本是否创建，由对应业务记录确认。模型摘要可以帮助继续理解任务，但不能作为这些操作已经发生的唯一依据。
事件补发也不应重新执行一次素材生成或发布。接收方按事件编号去重，业务操作则使用自己的任务编号或幂等编号，两者分别处理。
7. 原生执行引擎的接入
自研 Runtime 要持续维护模型循环、工具协议和上下文组织。另一种选择是复用原生编码引擎，把业务工具接到已有的执行环境中。
Codex 提供程序化接入方式，Claude Agent SDK 也提供相应的执行能力。Codex SDK、Claude Agent SDK 文档。
我们在这一阶段开始尝试把原生 Codex 接入新的 Runtime，通过适配层连接现有业务服务。
引擎负责读取工程、调用基础工具、修改代码和执行验证。平台继续保存项目、会话和运行关系；素材、费用、版本与交付结果仍由业务服务负责。
适配层需要处理事件转换、取消、继续会话，以及产物接入。即使引擎已经在文件系统中生成了一张图片或构建了一份游戏，平台仍需要登记产物、关联项目和版本，才能进入产品的交付流程。
本文最初整理时，原生引擎接入仍在开发验证阶段。部分原生执行和素材任务完成了限定范围的开发环境验收，项目交互、完整交付和恢复仍在推进。这些结果只能说明已验证的范围，不能作为整套迁移完成的依据。
8. 模型与流程的对照验证
上面的调整同时涉及模型、Prompt、工具和编排。若把它们一起修改，只能观察到最终结果变化，很难确定是哪一部分起了作用。
后续可以固定一组游戏需求和验收条件，分步骤比较：
先保存现有模型与流程的结果，再接入兼容的新模型；之后调整工具和上下文；最后每次简化一部分编排。比较旧环境时，应先满足新模型的接口与工具兼容要求。
各组使用相同的记录项：需求完成情况、核心玩法验证、交付版本、总费用、等待时间，以及失败后的恢复结果。把重复素材任务、无效部署和额外修复计入成本，才能判断一次有效交付实际消耗多少资源。
多 Agent、固定检查和独立评估都可以放进这套比较中。某一步删除后，若结果在约定范围内保持稳定，同时费用与等待下降，才有依据继续简化；出现质量下降，则需要检查该步骤在当前任务中承担了什么作用。