小白提问：如何让Codex主Agent用GPT，子Agent用GLM实现最优配置？

最近搞 AI 开发的朋友都在聊 Codex，听说这玩意儿不仅能跑单模型，还能玩出“混合双打”的花活儿。不少小白（包括我）很好奇：能不能主 Agent 用 GPT 这种强模型做统筹，子 Agent 用 GLM 这种性价比模型干具体的活，从而实现成本和效果的最优解？

毕竟，大家看 config.toml 里的配置，似乎只能填一个模型名字，这到底是怎么实现的？今天咱们就来扒一扒背后的逻辑和实现思路。

初级误区：Config 里的那个模型是谁？

很多人卡在第一步，以为 config.toml 里的模型配置就是全局唯一的。其实不然，那个配置往往是指定了默认模型或者主控 Agent 的“大脑”。

如果你想让子 Agent 换个脑子，光改默认配置是没用的，得在代码层面或者高级配置里动点手脚。

核心思路：主从模型的分工

要实现“主 Agent 用 GPT，子 Agent 用 GLM”，核心逻辑在于任务分发层面的模型指定。

主从式 Agent 架构：主控模型负责规划，子模型负责执行

1. 主 Agent (The Brain)： 负责理解意图、拆解任务、规划步骤。这一步需要强大的逻辑推理能力，所以调用 GPT-4 或 Claude 3.5 这种“聪明”模型比较稳。
2. 子 Agent (The Hands)： 负责执行具体的、重复性的或者代码生成类的任务。这时候如果还用 GPT 那就太烧钱了，完全可以下放给 GLM-4、Qwen 甚至其他开源小模型来做。

实操方法：怎么改？

既然 config.toml 只能设一个默认值，那子 Agent 的模型切换通常有两种常见的实现路径（取决于你用的 Codex 版本或二次开发的封装）：

方法一：动态模型调用（代码级魔改）

如果你是在自己的代码里集成 Codex 的逻辑，不要硬编码模型名。在实例化子 Agent 的时候，显式传入 model 参数。

举个伪代码的思路：

• 主 Agent 初始化时读取配置文件中的默认模型（GPT）。
• 当主 Agent 决定“我需要调用一个写代码的 Agent”时，不是简单地 new Agent()，而是 new Agent(model='glm-4')。

这就要求你在 Agent 类的初始化方法里，保留覆盖默认配置的接口。

方法二：利用 Agent 工厂模式或配置覆盖

有些版本的 Codex 或者类似的 Agent 框架，支持在定义 Agent 能力时绑定特定的模型。

比如你可以定义一个 CoderAgent，并在它的独立配置块里指定 model = "glm-4"。主 Agent 在调度时，是通过角色名称（Role）来调用子 Agent，而不是直接生成实例。这样，框架就会自动去读这个子 Agent 专属的配置。

为什么这样搞才是“最优”？

1. 省钱（羊毛薅到爽）： GPT 跑一次主控，可能也就几美分，但如果让 GPT 把所有的细枝末节都处理了，Token 费用蹭蹭往上涨。把 80% 的具体工作交给 GLM 或其他国产大模型，成本能直接降低一个数量级。
2. 速度更快： 同样是上下文处理，有些轻量级模型的响应速度比 GPT 快得多，子任务并行处理时，延迟显著降低。
3. 互补性： 现在国产模型（如 GLM）在中文语境和特定代码生成上表现不俗，让它们干擅长的活，主 GPT 只做把关，其实效果更好。

总结

所以，config.toml 不能选两个模型是个表象问题。想玩转多模型架构，关键在于理解 Agent 的生命周期：主控是老大，负责定调子（用 GPT）；干活的兄弟是小弟，负责搬砖（用 GLM）。

下次看到别人炫耀 Codex 的多模型配置，别再只盯着配置文件看了，去翻翻他的 Agent 工厂类或者调度逻辑吧！