目标很清楚：用户说一个想法，最后拿到一个能玩的游戏。但对于模型，我们还没有建立起足够清楚的判断。它能独立完成多长的一段工作？什么时候需要拆开？做不好，是模型能力的问题，还是我们给它的信息和工具有问题？

我们先写长 Prompt，再补各种工具，后来按开发、配置、美术拆 Agent，又把一部分能力放回主 Agent。这中间最值得复盘的，是我们对这些问题的理解怎么变了。

现在回头看，我觉得早期有几类问题被混在了一起：模型暂时做不到的、模型缺少游戏知识的，以及系统本身没有处理好的。于是解决办法也容易混在一起，最后都变成更多的提示、角色和流程。

模型往前走以后，这种做法就需要重新考虑了。我们逐渐学会先判断模型已经能够承担什么，再决定自己还需要补什么。 这也是我理解的 follow 模型的发展方向。

1. 最早的问题，是不知道应该相信模型到什么程度

我们的第一版 Python 原型，用一个比较长的 Prompt 串起游戏开发流程：理解需求、整理策划、找素材、做地图、写玩法、测试、部署。技术栈、地图格式、素材用法，都尽量写清楚。

这种做法的好处很直接。目标拆成了具体步骤，缺少的知识也有地方补进去。我们先靠它把从需求到游戏的路径做出来。

但这里有一个容易忽略的问题：一条规则到底在补什么？

比如，模型不知道某种地图格式，给它一份正确说明就有帮助。命令执行到一半拿不到后续输出，需要修的是工具。素材已经生成成功，恢复后却找不到，应该补的是任务记录。

如果这些问题最后都变成“再提醒模型一下”，Prompt 就会越来越长，却很难知道哪些内容真正有用。

那时的 Claude Sonnet 4 和 GPT-5 已经在持续增强编码、工具使用和多步任务能力。我们需要摸清的，是这些能力在自己的游戏任务里能走到哪里。Claude 4 官方介绍、GPT-5 开发者介绍。

所以我现在会把早期的长 Prompt 看成一组需要验证的假设：我们认为模型在这里需要帮助，就先补上；如果后来的模型已经能稳定完成，这条规则也应该有机会被拿掉。

有些知识依然要提供，比如业务里的素材能力、项目约定和交付要求。它们能让模型更了解当前任务。至于为了绕开旧模型某个弱点而加的步骤，就需要随着模型升级继续检查。

2. 拆 Agent 之前，要先想清楚我们在拆什么

游戏开发变复杂以后，我们开始按专业能力拆 Agent。主 Agent 组织任务，开发 Agent 写代码，配置 Agent 管地图和音频，素材相关 Agent 处理资源，还有角色、动画、封面等入口。

这个结构很容易让人觉得合理，因为它和一个游戏团队的分工很像。每个角色有自己的 Prompt 和工具，单独维护起来也更清楚。

但人的分工方式，放到 Agent 上，需要把上下文的成本重新算一遍。

拿“增加二段跳”来说。开发 Agent 需要知道当前角色怎么移动、跳跃状态怎么重置、动画和音效在哪里接。如果主 Agent 刚刚和用户确认过“保留原来的手感”，这个约束也需要一起交过去。

我们后来还去掉过主 Agent 的 Bash 入口，进一步把编码交给开发 Agent。从职责上看更清楚了，对工程细节的理解和修改却需要经过更多交接。

这让我开始怀疑一个假设：工作内容不同，就一定值得交给另一个 Agent 吗？

配置、代码和素材用法，经常需要同时理解。它们虽然是不同专业的问题，却可能属于同一个修改动作。把它们切成几段，会让每一段都重新解释需求，再把局部结果交给下一段。

第二版游戏 Agent 把编码能力放回主 Agent，同时通过 Skills 按需加载专业方法。这次调整里，我觉得有价值的是把“补知识”和“开一段独立执行”分开了。

处理地图时加载地图知识，做素材接入时加载对应方法，仍然由同一个 Agent 理解需求、修改工程、检查结果。独立素材生产、封面制作等任务，则继续保留自己的执行入口。

我的判断是，Agent 的边界应该沿着工作的独立性来划。 是否需要单独的权限和生命周期，能不能并行，结果能不能清楚交接，这些比角色名称更有用。

这也解释了为什么更强的模型出现后，我们需要重新看一遍原来的拆分。模型能够在更大范围里连续理解和修改，原来为了让每个步骤简单一点而设置的边界，就可能变成额外成本。

3. 跟着模型走，要跟上它的能力，也要跟上它的工作方式

把 OpenAI 和 Claude 这两条线放在一起看，我比较关注下面几类变化。这里讨论的是模型及其编码环境的能力方向，并不意味着每次发布都直接触发了我们的某次改版。

这几类变化放在一起，对我们的要求就超过了“把模型名换一下”。

同样是执行命令，第一次返回什么，命令没结束时怎样继续取输出，用户停止时怎样收尾，都会影响模型下一步的判断。修改文件也是一样，读取、补丁和失败反馈需要接得起来。

我们因此逐步对齐了 Codex 和 Claude Code 两类基础工具，根据模型装配对应的工具集。

还有一些变化发生在上下文里。为 GPT-5.6 调整缓存处理时，我们需要让新追加的消息和工具结果继续成为后续请求的缓存前缀。接入 Astra 时，也要重新核对推理参数、工具结果续传和缓存行为。

这些工作让我更明确地意识到：一个模型在产品里能发挥多少能力，取决于我们给它的整个工作环境。 模型能连续处理工具任务，我们的命令工具就要支持连续执行；模型能利用历史继续推理，上下文组织就要把需要的信息交给它。

OpenAI 对 GPT-5.6 的工程说明也把模型、推理服务和 Harness 放在一起讨论。Harness 就是模型外面组织工具、上下文和执行环境的那一层；减少上下文膨胀和重复处理，是整套系统效率的一部分。GPT-5.6 工程说明。

所以 follow 模型，在我这里逐渐变成一个具体动作：先弄清楚它适合怎样工作，再检查我们的环境有没有支持这种工作方式。

4. 流程变完整以后，还要警惕它制造的“确定性”

我们做过一轮比较重的质量流程。它把用户意图、素材、运行证据、检查和发布连接起来，希望每个环节都有明确结果。

其中一些东西很有价值。比如用户说“玩法别动，把场景换成雪地”，系统就需要一直保留“玩法不变”和“场景改变”这两个要求。越是长任务，这种明确的目标越重要。

问题出在另一部分：固定检查多个视口，固定走开始、胜利、失败、重试等场景，再让检查结果触发修复和重新部署。

这套流程很容易给人一种踏实感，好像检查项越全，交付就越可靠。但实际案例让我们看到，它也会放大模型消耗和部署等待，甚至把执行带进围绕检查结果反复修补的过程。

我觉得这里混淆了两件事：发现一个问题，和决定现在必须修这个问题。

比如用户这轮明确做手机竖屏，先把竖屏的游玩路径做好。其他方向有没有问题、影响多大、是否值得在这一轮继续处理，要结合用户要求和剩余预算判断。一个检查结果，可以成为决策依据；它本身并不知道用户这次最在意什么。

调整以后，我们把更多工作放到部署前：素材怎么用、代码怎么接、预算够不够，先一起规划。完成接入后交付一个尽可能好的版本，再根据真实运行结果决定后续修复。

这次变化让我更愿意把流程理解成帮助模型完成任务的方法，而不是必须走完的固定步骤。用户意图、费用限制和可见交付仍然明确保留，具体实现过程则需要有判断空间。

Anthropic 也记录过类似的调整：从 Sonnet 4.5 到 Opus 4.5、4.6，他们逐步移除了部分上下文重置和固定开发分段，同时保留仍然有帮助的规划与评估。Anthropic Harness 设计实践。

这件事给我的启发是，每多加一层流程，都应该知道它在弥补什么。到了新模型上，再验证一次这个问题是否仍然存在。这样，流程才有机会随着模型一起变好，而不是一直累加。

5. 模型可以承担更多判断，系统必须守住自己的事实

不过，简化编排也有边界。游戏能力接入团队已有的 Go 后端时，会话、执行记录和费用就已经由运行时处理，这部分职责一直延续下来。

模型能够连续工作更久以后，产品需要处理的等待、重启和续聊也更多了。一轮游戏制作里，模型、素材任务、版本交付和用户界面各有自己的进度。

模型结束回答时，图片可能还没有生成完。图片生成成功以后，还需要接进游戏。游戏已经部署，前端也可能尚未收到结果。

这里我觉得需要划一条很清楚的线：模型对当前工作的理解，可以整理和压缩；业务已经发生的事实，需要准确记录。

素材有没有成功、费用有没有发生、版本有没有创建，都不能只留在模型的一段总结里。恢复时也不能让模型凭印象重新判断。

所以我们持续补任务记录、事件 Outbox、上下文检查点和轮次关联。它们让 Agent 能找回正在等待的工作，让事件可以重试，让页面能够补上结果。

这部分工作和模型能力增强是相互配合的。模型能处理更复杂的任务，我们就需要把任务所依赖的状态提供得更准确。

我现在会把两类设计分开看：一类是在帮助模型判断下一步怎么做，可以随模型能力调整；另一类是在记录系统实际上发生了什么，需要由业务系统明确负责。

6. 复用原生引擎，是把这条边界继续往前推

如果工具、上下文和执行循环都在跟着模型快速演进，我们还要自己维护到多深？

这也是原生编码引擎值得考虑的原因。Claude 通过 Agent SDK 开放了支撑 Claude Code 的执行基础设施，Codex 也在持续完善配套环境。模型之外，已经有更多成熟能力可以复用。Claude Agent SDK 介绍。

Astra 的更新里就有一个具体例子：Codex 开始提供实验性的跨上下文笔记和历史检索，帮助执行找回此前的要求与结果。这是一项模型与环境配合的能力，我们接入同名模型后，还要处理相应的环境衔接。Astra 官方介绍。

顺着这个思路，我们开始尝试把原生 Codex 接进新的 Runtime，让它组织编码执行，通过适配层连接已有业务能力。

引擎负责理解工程、调用工具、修改和验证。我们继续负责项目与任务关系、素材产物、费用、版本和交付结果。

这并不会让所有衔接工作消失。不同引擎如何表达事件、如何取消、怎样继续执行，都需要明确适配。原生引擎生成了产物，也仍然需要接入我们的素材和版本体系。

本文整理时，这条新路线还没有合入主分支。部分原生执行和素材任务完成了限定范围的开发环境验收，项目交互、交付和恢复仍在推进。

我更看重的是这个方向带来的分工变化：把持续演进的通用编码执行交给更合适的基础设施，我们集中处理游戏产品真正需要自己负责的部分。

7. Follow 模型，需要一种能推翻自己旧设计的方法

走到这里，问题已经从“要不要跟着模型走”，变成了“怎么知道我们真的跟上了”。

如果换了模型、重写了 Prompt、改了工具，又删掉一批流程，最后游戏变好了，我们其实还不太清楚是哪一部分起了作用。下次模型再升级，仍然可能重新陷入猜测。

所以接下来，我更希望把验证做得有区分度。

先固定一组典型游戏需求，保留现有模型与流程作为参照。换上新模型，看看能力本身改变了什么；再调整配套工具和上下文；最后每次只简化一部分原来的编排。

每一步都看同样的结果：游戏是否符合用户意图，核心玩法能不能走通，用户有没有拿到版本，总费用和等待时间是多少。

如果拿掉某个步骤以后，质量没有明显下降，费用和等待却减少了，就有理由继续简化。如果质量变差，就说明这一步在当前任务里仍然有用。多 Agent、独立评估、固定检查，都应该接受这样的验证。

这也是我现在理解的 follow 模型：持续检查自己的设计，能补的补，能复用的复用，已经不需要的也愿意拿掉。

最初的迷茫，让我们试着为每一步安排一个办法。后来慢慢有了判断，才开始分清哪些是临时帮助模型的，哪些是产品长期需要的。

以后再看一段复杂流程，我会先问：我们保留它，是因为当前模型和任务确实需要，还是只是因为以前需要？