AI 编程来了，我决定一个人做一款游戏（05）

我没有让Sol模型包办一切而是给 Codex 搭一套子代理路由不是为了多开几个 AI而是让不同复杂度的任务进入不同处理路径。在用 Codex 开发《Riftkeeper》的过程中我慢慢发现一个问题如果每次都让同一个代理负责需求分析、查代码、修改文件、运行测试和最终验收虽然流程简单但并不一定合理。一个只有明确入口、修改两三个文件的小功能可能根本不需要很强的推理能力而协议、架构或者跨模块问题如果直接交给执行型代理修改又容易在没有看清影响范围之前动手。更麻烦的是随着终端日志、搜索结果和测试输出不断进入主对话真正重要的需求边界反而可能被淹没。所以我开始给 Codex 增加一层“子代理路由”。这套路由想解决的不是“谁最强”而是让不同复杂度和风险的任务进入不同处理路径把需求、范围和最终判断留在主线程把边界清楚的执行工作交给合适的子代理。01. 子代理不是越多越好官方文档提到子代理可以把代码搜索、日志分析和测试等工作移出主线程最后只把整理后的结果返回给主代理。这样可以减轻主对话中的“上下文污染”。但子代理并不是免费的并发能力。每个子代理都需要独立完成模型推理和工具调用多代理任务通常会消耗更多 Token。因此路由的目标不是“遇到任务就多开几个代理”也不能简单理解成“开启子代理就能省钱”。我真正想解决的是三个问题● 简单任务不要占用过高的推理资源● 高风险任务不要在分析清楚之前直接修改● 主代理保留需求、边界和最终决策减少被中间日志淹没。换句话说子代理路由更像是一次资源分配而不是一个并发开关。02. 先判断阶段再选择模型我最初容易忽略的一点是上来就根据“任务难不难”选择模型。但同一个问题在不同阶段需要的能力并不一样。例如一个跨模块 Bug 在定位阶段可能需要较强的推理能力当入口、原因和影响范围都确认以后真正的代码修改可能只有一两个文件。需求确认↓调查定位 → 方案设计 → 代码实现↓审查验证如果整个过程一直使用最高档模型未必必要如果一开始就交给执行型代理又可能因为根因没有确定而发生返工。所以我现在先判断任务阶段再判断复杂度和风险。03. 我现在使用的四级路由目前我在本机启用了子代理功能并把同时运行的子代理线程限制为三个。除此之外我定义了四个自定义角色。需要说明的是Luna、Terra、Sol 这套分层是我的本地策略不是 Codex 官方规定的固定工作流。主代理 / Terra Medium适合需求沟通、配置说明、明确入口的小修改、最终验收。边界保留范围、用户决策和最终验证。Luna Worker适合边界清晰的实现、修复和重构通常影响一至三个文件。边界不修改公共协议、架构、安全边界和发布流程。Terra Worker适合根因不明确、跨模块、UI 与运行时交互、复杂调试。边界先找到真实执行路径再进行最小修改。Sol Expert / Sol Deep适合协议、架构、安全、支付、数据丢失风险等高影响问题。边界默认只读调查先给出证据和实施边界不直接写代码。风险优先级高于文件数量哪怕只修改一行代码只要涉及登录、支付、公共协议或数据结构就不能因为“只改一行”而进入最低档执行路线。04. 升级之后还要允许降级这套路由并不是任务一旦进入 Sol就由 Sol 完成全部工作。我的处理方式是高风险或高歧义问题先交给 Sol 做只读调查当入口、影响范围和不可破坏的约束都确认以后再把具体实现交还给 Luna 或 Terra Worker。高阶模型把问题想清楚↓执行模型完成边界明确的修改↓主代理统一审查和验证我只会在出现真实证据时升级例如发现问题跨越多个模块、原先的入口判断错误或者修改会影响公共协议。“感觉这个问题可能很难”不是升级理由。05. 并行最容易被误用子代理最吸引人的地方是并行但并不是所有工作都适合并行。代码搜索、测试检查、日志分析和文档核对可以拆给不同的只读代理因为它们不会争抢同一份修改结果。多个代理同时修改相关文件就危险得多。● 优先只启用一个边界明确的实现代理● 只并行互相独立的只读任务● 不把重叠文件交给多个代理同时修改● 所有结果必须回到主代理统一审查● 用户决策、发布和破坏性操作不交给子代理。本机配置中的 max_concurrent_threads_per_session 3 只是限制同时打开的子代理线程上限并不代表每次都要用满三个。06. 我遇到的真实问题配置存在不等于路由可用之前我尝试把 Luna Worker 的配置复制到另一台电脑上。当时很容易产生一个错误判断代理配置文件已经放进指定目录就等于这套路由已经生效。但实际上我没有获得足够的验证证据。另一台电脑是否识别了自定义代理、是否提供对应模型、是否真的把任务委派给了 Luna这些都没有被完整确认。尤其是模型可用性配置文件中写了某个模型名称不代表当前账号和设备一定能调用它。迁移后的四步验证1. 确认当前环境能够看到目标模型2. 确认 Codex 已加载自定义代理3. 用一个小而明确的任务进行显式委派4. 检查子代理结果、实际改动和验证输出。配置成功、任务执行成功和结果验证成功是三件不同的事。07. 一份可以复用的路由提示词如果不想一开始就编写复杂规则可以先把下面这段提示词交给 Codex先判断当前任务处于需求确认、调查、实现、审查还是验证阶段。选择能够安全完成任务的最低级别路由1. 入口明确、范围清晰的小任务由主代理直接处理2. 一至三个文件的边界明确实现交给 Luna Worker3. 根因不明确、跨模块或涉及运行时交互交给 Terra Worker4. 协议、架构、安全、支付或数据风险问题先由 Sol 只读调查。只有出现真实的复杂度或风险证据时才能升级。调查明确后将具体实现降级交给 Luna 或 Terra。不要让多个代理同时修改重叠文件。主代理负责需求边界、最终审查和验证。真正有用的子代理系统并不是拥有多少模型而是能否回答三个问题这个任务现在需要什么能力哪个代理拥有修改权什么证据能够证明任务完成我的路由目前仍然在调整也没有足够数据证明它一定降低了多少成本。但至少它让我开始把“让 AI 写代码”变成“让不同能力的 AI 在明确边界里协作”。下一步下一步我准备继续记录这套路由在真实游戏开发任务中的表现哪些任务被正确分配哪些任务发生了误判以及升级到更强模型以后问题是否真的得到解决。路由规则本身并不是结果。只有把任务分配、实际修改和验证证据放在一起它才真正有价值。你会怎样给不同模型分工欢迎在留言区交流你的做法和踩坑。如果你想继续关注这套路由在真实开发中的效果也欢迎关注后续记录。这篇文章最想留下的结论不要默认让最强模型完成所有步骤也不要为了使用子代理而强行并行。先判断阶段和风险再选择能够安全完成任务的最低级别路由。参考Codex 官方文档《Subagents》learn.chatgpt.com/docs/agent-configuration/subagents