Codex 子代理调试实录：主代理+Luna+DeepSeek 的分工与验收

在 Codex 中搭建多代理协作，核心诉求往往不止一个：既想省 token，也想让多个独立任务并行推进，缩短整体交付周期。本文整理了一次真实的子代理调试记录，涵盖角色分工、调用链路验证、任务切分原则，以及过程中踩过的几个典型坑。

为什么要上子代理

调试子代理的初衷很直接——省 token，同时让独立任务并行推进。单一主代理虽然能跑完整流程，但输出速度偏慢，一旦任务串行堆叠，等待成本就会被放大。

多代理方案的价值在于把「决策」和「执行」拆开：让主代理专注做规划和把关，把具体的实现、调查工作下放给成本更低、更专注的子代理。这样既能控制高价模型的调用频次，也能让互不依赖的任务同时推进。

从成本结构来看，多代理方案的经济性来自「模型分级调用」。主代理使用高能力、高单价的模型（如 GPT-4o、Claude Opus），但调用次数被压缩到规划和验收环节；子代理则使用成本更低的模型处理大量重复性执行任务。以 DeepSeek^广告 Flash 为例，其 API 定价通常仅为顶级模型的 1/10 至 1/20，用于代码审查和调查性任务时，在质量损失可接受的前提下能显著降低整体费用。并行推进带来的时间收益同样不可忽视：若两个独立子任务各需 5 分钟，串行执行需 10 分钟，并行则只需 5 分钟。但这一收益的前提是任务真正独立——任何隐性依赖都会把并行退化回串行，甚至因协调开销更慢。

三类角色的明确分工

这次调试采用了三层角色结构，职责切得很清楚：

• 主代理：由主模型担任，负责定方案、拆任务和最终验收。它是整条流程的大脑，不直接写大量代码，而是决定「做什么」和「做得对不对」。
• Luna（实现与修复）：承接明确定义的实现和修复任务，属于执行层。任务越清晰，它的产出质量越稳定。
• DeepSeek Flash High（调查与审查）：通过 API 介入，负责调查和独立审查。把审查交给一个独立模型，可以避免「自己写自己审」的盲区。

这种分工的逻辑是：主代理掌控全局和质量门槛，执行类任务交给 Luna，调查和交叉验证交给 DeepSeek，三者各司其职。

调用链路怎么验证

多代理最容易出问题的地方不是「能不能跑」，而是「跑的是不是你以为的那个模型和通道」。这次调试的重点就落在链路验证上，具体要确认三件事：

1. 主代理能不能真正创建子代理；
2. 子代理实际使用的模型和推理强度对不对；
3. 子代理能不能真正调用工具。

验证方法很务实：让子代理读取指定文件、返回结果、再关闭，然后核对运行记录里的模型标识和实际请求通道。只有这条链路完整走通，才把该子代理标记为「可用」。换句话说，不靠感觉判断，而是用可复核的运行记录来确认。

「模型标识正确」与「请求真正到达目标模型」是两件不同的事，这在多代理框架中尤其容易混淆。代码里写的模型名称（如 deepseek-chat）是应用层配置，但底层 HTTP 请求实际发往哪个 Base URL、携带哪个 API Key，取决于 Provider 路由规则。OpenCodex 等工具支持按模型名前缀或提供商标识做分流，但配置稍有偏差就会出现「名字是 DeepSeek，请求走的是 OpenAI 端点」的静默错误——不报错，但账单和响应质量都不对。验证链路时，最可靠的方式是直接检查网络日志或框架的请求记录，确认 endpoint、model 字段与预期完全吻合，而不是依赖返回结果的表面形态来推断。

任务切分的三条原则

并行能不能真正提速，取决于任务切得够不够干净。记录里总结出几条很实用的原则：

• 每次交付一个能独立验收的结果：任务边界清晰，产出可被单独检查。
• 任务之间互不依赖：避免 A 等 B、B 等 A 的串行死锁，才能真正并行。
• 修改的文件不重叠：这是并行的硬约束，文件冲突会直接毁掉并行收益。

还有两条「不派出去」的经验：小事由主代理自己做，派发子代理本身也有开销；只读类任务也不必全部外派。多代理不是越多越好，派发成本和收益要算清楚。

踩过的几个坑

实际落地过程中，环境和配置层面的问题比逻辑层面的更磨人。

DeepSeek 请求走错通道：DeepSeek 的请求一度被路由到了 OpenAI 通道，后来通过 OpenCodex 做分流才解决。这正好印证了前面「核对实际请求通道」的必要性——模型名对，不代表请求真的走对了路。

Provider 配置出错导致无法启动：Provider 配置的错误一度让 Codex 直接起不来，最后只能转到网页端用聊天模型来排查 Config。配置文件是整条链路的地基，一旦写错，影响面比单个任务失败大得多。

Provider 配置错误之所以影响面极大，是因为它通常作用于全局初始化阶段而非单次请求。在 Codex 及类似框架中，Provider 配置文件（如 ~/.codex/config.yaml 或环境变量组合）在进程启动时被一次性解析，任何 YAML 语法错误、字段名拼写错误或 API Key 格式异常都可能导致整个运行时初始化失败，而非仅影响某一个子代理。这类错误的调试难点在于：Codex CLI 本身出不来，无法通过正常交互流程排查，只能退回到更原始的手段——直接编辑配置文件、查看启动日志，或如文中所述切换到网页端聊天模式借助外部模型来定位问题。因此在首次配置多 Provider 环境时，建议逐项增量验证，而不是一次性写完再启动。

小结

这次调试的核心经验可以浓缩成一句话：多代理的价值在于分工清晰、链路可验证、任务可独立验收。主代理负责规划和把关，Luna 负责执行，DeepSeek 负责独立审查，三方协作省 token 又能并行。而真正拉开成败差距的，往往是通道路由和 Provider 配置这些底层细节——跑通之前，先用运行记录把每一环都核对一遍。