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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_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/apiKey 填刚才复制的那串。填完它会把这个 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 providerqwen-portal modelcoder-model如果出现类似这样的行[2025-xx-xx] dispatch subtask providerqwen-portal modelcoder-model task_idxxx [2025-xx-xx] subagent result received task_idxxx tokens1842那就说明真实调用了 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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。接入过程中如果卡在配置或者报错排查上直接翻接入文档最省时间https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。文档里有各客户端的完整配置示例比对着改比瞎试快得多。想先验证模型通不通、不急着配 OpenClaw 的话用模型对话页面发一条测试请求就行https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。确认 Base URL 和 Key 没问题再回来配主从调度能少走很多弯路。最后补一句实操经验这套主从架构的关键从来不是「多配一个模型」而是把 Codex 明确设成调度器、把委派协议固化进 AGENTS.md、再用日志验真调用链路。三件事缺一件它就会退化成「一个模型假装在调度」。配置改完之后养成跑一次日志过滤的习惯比什么都管用。