1. 为什么要在 OpenClaw 里做「主 Agent 调度子 Agent」
先说清楚这套东西是什么、能做什么、适合谁。OpenClaw 是一个本地优先的 Agent 运行框架，你可以把它理解成一个「指挥台」：它本身不产出智能，而是负责把不同模型、不同工具、不同角色编排成一条工作流。主 Agent 调度子 Agent，指的是让一个能力更强、更擅长决策的模型（这里用 Codex）当「包工头」，把信息收集、草稿生成、批量执行这类重复性活儿派给一个成本更低、跑得更快的模型（这里用 Qwen），最后再由主 Agent 验收、汇总、给出最终结论。
适合谁？适合已经在用 OpenClaw 跑日常任务、但发现「一个模型干所有事」既贵又慢的人。比如你要做一份 A/B 产品对比，主 Agent 负责拆解维度、判断哪些结论站得住脚，子 Agent 负责去抓参数、整理体验反馈、写初稿。这种分工下来，token 成本能压下去一大截，主模型的上下文也不会被一堆原始素材塞爆。
我试过最直接的对比：同一个「对比两款机械键盘」的任务，单模型跑要一次性把搜索、整理、成文全做完，主模型上下文很快到几万 token；拆成主从之后，Qwen 那边吃掉大部分原始素材，Codex 只拿到结构化摘要，最终回答质量反而更稳。核心原因不是模型变强了，而是职责边界清楚了——决策的归决策，执行的归执行。
这套架构的交付链路是：用户 → Codex（拆解+派发）→ Qwen（执行+返回）→ Codex（验收+汇总）→ 用户。听起来简单，但真正落地要解决三件事：子模型怎么配成可调用、协作协议怎么固化、调用链路怎么验真。下面一步步来。
2. TaoToken 前置：统一 Key 接入 Codex 与 Qwen
在配 OpenClaw 之前，先把模型接入这层理顺。OpenClaw 支持通过兼容 OpenAI 协议的中转来调用模型，TaoToken 就是干这个的——它把 Codex、Qwen 这类模型的调用统一到一个 Base URL 和一把 Key 上，省得你为每个 provider 单独维护凭证。官网在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 入口是 https://taotoken.net/api （这个地址不加 UTM 参数，配置里直接写它）。
你需要先拿到 Key。登录后进控制台，在 API Keys 页面创建一个，复制出来。这个 Key 后面会同时喂给 Codex 和 Qwen 两个 provider，因为它们走的是同一个网关。如果你还没建过，直接去 https://taotoken.net/console/api-keys 建一个就行。
拿到 Key 之后，OpenClaw 这边的接入分两步：先登录 Qwen provider，再把主模型切回 Codex。注意顺序，先登 Qwen 是因为登录命令会改默认模型，登完再切回来。
openclaw models auth login --provider qwen-portal --set-default执行这条命令时，OpenClaw 会提示你填 Base URL 和 API Key。Base URL 填https://taotoken.net/api，Key 填刚才复制的那串。填完它会把这个 provider 存进本地配置。
接着把主模型切回 Codex，同时给 Qwen 起一个短别名，方便在 AGENTS.md 里引用：
cmd /c openclaw config set agents.defaults.model.primary relay/gpt-5.3-codex cmd /c openclaw config set agents.defaults.models.qwen-portal/coder-model.alias qwen这里relay/gpt-5.3-codex是主模型的标识，qwen-portal/coder-model是子模型的标识，别名qwen是你在协议里写delegate to qwen时用的名字。别名这步别省，否则后面 AGENTS.md 里要写一长串路径，容易写错。
校验一下配置有没有落盘：
cmd /c openclaw config get agents.defaults.model.primary cmd /c openclaw config get agents.defaults.models.qwen-portal/coder-model.alias期望输出是relay/gpt-5.3-codex和qwen。如果 primary 显示的还是 qwen-portal，说明登录那步的--set-default把默认改了，重跑一次切回命令即可。
注意：Base URL 一定写
https://taotoken.net/api，不要带末尾斜杠，也不要带 UTM 参数。带斜杠有些客户端会拼出双斜杠导致 404。
这一步做完，两个模型就都挂在同一把 Key 下了。接下来才是真正的编排逻辑。
3. 可复制配置：AGENTS.md 固化主从协作协议
OpenClaw 的行为很大程度上由 AGENTS.md 决定。这个文件放在项目根目录，框架启动时会读它，把里面的规则注入到主 Agent 的系统提示里。换句话说，你在这里写什么，主 Agent 就按什么行事。这一步决定了它到底是「一个助手」还是「一个调度器」。
下面是我实测下来最稳的一份配置，你可以直接复制，按需改任务类型：
# Orchestration Contract 1. You are the orchestrator (codex), not a single-run responder. 2. For info-heavy, repetitive, or broad web tasks, delegate to subagent `qwen`. 3. Delegation protocol: - Send qwen a clear subtask with required output format. - Wait for qwen result. - Validate result quality and gaps. - Produce final answer yourself. 4. Never end with a planning placeholder. 5. Only use STATUS: DONE when final deliverable is already returned. 6. If subagent fails, retry once with narrower scope, then fallback to self-completion.逐条解释一下为什么这么写。第 1 条是身份锚定，明确告诉模型「你是调度器」，不是「回答器」。很多模型默认行为是收到任务直接开写，不写这条它根本不会想到去派发。第 2 条划定派发边界——信息密集、重复、宽泛的网页任务才派给 qwen，避免它把简单问题也绕一圈。第 3 条是协议核心，四个动作缺一不可：发子任务、等结果、验收、自己出最终答案。第 4、5 条是防偷懒的，模型很容易回一句「已安排 qwen 处理」就停住，这两条强制它必须拿到结果并交付。第 6 条是容错，子 Agent 挂了不能整个流程卡死。
如果你用的是 Cline MCP 或者 Codex 的 auth.json 方式接入，配置结构会略有不同，但三件套是一样的：Base URL、Key、Model ID。以 Codex 的 auth.json 为例：
{ "base_url": "https://taotoken.net/api", "api_key": "sk-你的Key", "model": "relay/gpt-5.3-codex" }Cline MCP 的 settings 片段则是：
{ "mcpServers": { "openclaw": { "command": "openclaw", "args": ["mcp", "serve"], "env": { "OPENCLAW_BASE_URL": "https://taotoken.net/api", "OPENCLAW_API_KEY": "sk-你的Key", "OPENCLAW_MODEL": "relay/gpt-5.3-codex" } } } }不管哪种方式，Base URL、Key、Model ID 这三样必须齐全，缺一个就连不上。CC Switch 用户同理，在切换配置里把这三项填对即可。
AGENTS.md 写完之后，建议再补一个「委派模板」，放在文件末尾，方便你日常下命令时直接套：
## Delegation Template 你是主 agent codex。请调用 qwen 完成资料收集与初稿，你负责验收和最终结论。 任务：<具体任务> 要求：必须给出最终结论，不要只回"已安排"。这个模板的作用是给用户一个稳定的输入句式。你每次下命令都按这个结构来，主 Agent 的派发行为会稳定很多，不会因为措辞变化而时灵时不灵。
4. 验证请求：跑一次完整调度链路并查日志
配置写完不算完，得验证它真的调到了 Qwen，而不是主 Agent 嘴上说「已安排」实际自己干了。这一步是整个实战里最容易被跳过、也最关键的。
先跑一个真实任务。用上面的委派模板，下这么一条命令：
你是主 agent codex。请调用 qwen 完成资料收集与初稿，你负责验收和最终结论。 任务：对比两款 75% 配列机械键盘（Keychron Q1 与 NuPhy Air75）的参数、手感、购买建议。 要求：必须给出最终结论，不要只回"已安排"。跑完之后，去日志里查证。OpenClaw 默认把日志写在C:\tmp\openclaw\下，文件名带时间戳。用 PowerShell 过滤：
Select-String -Path C:\tmp\openclaw\openclaw-*.log -Pattern "provider=qwen-portal model=coder-model"如果出现类似这样的行：
[2025-xx-xx] dispatch subtask provider=qwen-portal model=coder-model task_id=xxx [2025-xx-xx] subagent result received task_id=xxx tokens=1842那就说明真实调用了 Qwen，链路是通的。如果只看到主模型的调用记录，没有 qwen-portal 的行，说明派发没生效，回去检查 AGENTS.md 有没有被正确加载。
再进一步，你可以看主 Agent 的最终输出里有没有「验收」的痕迹。真正走了主从流程的回答，通常会先给一段结构化摘要（来自 Qwen），然后有一段主 Agent 自己的判断和结论。如果回答是一口气写到底、没有分层，多半是主 Agent 自己包圆了。
验证通过之后，建议把这次成功的日志片段存一份，作为基线。以后升级 OpenClaw 或者改配置，拿新日志跟基线对比，能快速发现行为退化。
5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth
配这套东西踩坑是常态，下面几个报错我基本都遇到过，按现象对号入座。
401 Unauthorized。最常见的原因是 Key 没填对或者 Base URL 写错。检查两点：一是 Key 有没有多余空格，复制时容易带上；二是 Base URL 是不是https://taotoken.net/api，写成https://taotoken.net/api/带斜杠有些客户端会 401。如果 Key 是对的还报 401，去控制台确认这个 Key 有没有被禁用或者额度耗尽。
local proxy failed。这个报错通常出现在 OpenClaw 启动阶段，意思是本地代理层没起来。先确认 OpenClaw 进程在跑，端口没被占用。如果是 Cline MCP 方式接入，检查 settings 里的 command 路径对不对，openclaw是不是在 PATH 里。Windows 下建议写全路径，比如C:\\Program Files\\openclaw\\openclaw.exe。
reading choices 相关报错。这类错误一般是响应体解析失败，根源多半在模型返回格式跟客户端预期不一致。检查你配的 Model ID 是不是真实存在的，relay/gpt-5.3-codex和qwen-portal/coder-model这两个标识要跟 TaoToken 那边支持的模型列表对上。Model ID 写错，网关返回的是错误 JSON，客户端去读choices字段自然读不到。
OAuth 相关报错。如果你之前用 OAuth 方式登录过某个 provider，配置里可能残留了旧的凭证，跟新的 Key 冲突。解决办法是清掉旧的 auth 缓存，重新用 Key 登录。OpenClaw 的凭证一般存在用户目录下的.openclaw文件夹里，找到对应 provider 的条目删掉再重登。
还有一个高频坑：主 Agent 只说「已安排 qwen」然后停住。这不是报错，是行为问题。根源在 AGENTS.md 第 4、5 条没写或者没生效。确认文件在项目根目录、文件名大小写正确（AGENTS.md不是agents.md），然后重启 OpenClaw 让它重新加载。
最后一个：明明调了 qwen 但检索质量差。这通常不是 qwen 的问题，而是搜索工具没配。qwen 如果只能web_fetch加推断，拿到的素材质量有限。检查 Perplexity 或 OpenRouter 的搜索 key 有没有配上，配了之后子 Agent 的素材质量会明显提升。
6. 长期编码与 Agent 场景的 CTA
如果你只是偶尔跑一次对比任务，上面这套配置够用了。但如果你打算把 OpenClaw 当成日常的编码助手或者长期跑的 Agent 平台，建议走 Coding Plan，它在调用配额和并发上更适合持续性的工作负载，不用每次任务都担心额度。入口在 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite 。
接入过程中如果卡在配置或者报错排查上，直接翻接入文档最省时间：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite 。文档里有各客户端的完整配置示例，比对着改比瞎试快得多。
想先验证模型通不通、不急着配 OpenClaw 的话，用模型对话页面发一条测试请求就行：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite 。确认 Base URL 和 Key 没问题，再回来配主从调度，能少走很多弯路。
最后补一句实操经验：这套主从架构的关键从来不是「多配一个模型」，而是把 Codex 明确设成调度器、把委派协议固化进 AGENTS.md、再用日志验真调用链路。三件事缺一件，它就会退化成「一个模型假装在调度」。配置改完之后，养成跑一次日志过滤的习惯，比什么都管用。
