企业官网建设流程全解析

我没有让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 Worker；

3. 根因不明确、跨模块或涉及运行时交互，交给 Terra Worker；

4. 协议、架构、安全、支付或数据风险问题，先由 Sol 只读调查。

只有出现真实的复杂度或风险证据时才能升级。

调查明确后，将具体实现降级交给 Luna 或 Terra。

不要让多个代理同时修改重叠文件。

主代理负责需求边界、最终审查和验证。

真正有用的子代理系统，并不是拥有多少模型，而是能否回答三个问题：

这个任务现在需要什么能力？

哪个代理拥有修改权？

什么证据能够证明任务完成？

我的路由目前仍然在调整，也没有足够数据证明它一定降低了多少成本。但至少它让我开始把“让 AI 写代码”，变成“让不同能力的 AI 在明确边界里协作”。

下一步

下一步，我准备继续记录这套路由在真实游戏开发任务中的表现：哪些任务被正确分配，哪些任务发生了误判，以及升级到更强模型以后，问题是否真的得到解决。

路由规则本身并不是结果。只有把任务分配、实际修改和验证证据放在一起，它才真正有价值。

你会怎样给不同模型分工？欢迎在留言区交流你的做法和踩坑。如果你想继续关注这套路由在真实开发中的效果，也欢迎关注后续记录。

这篇文章最想留下的结论

不要默认让最强模型完成所有步骤，也不要为了使用子代理而强行并行。先判断阶段和风险，再选择能够安全完成任务的最低级别路由。

参考：Codex 官方文档《Subagents》
learn.chatgpt.com/docs/agent-configuration/subagents