1. 为什么要把 OmO 的多 Agent 协同搬进 Claude Code如果你已经在用 Claude Code 写代码大概率遇到过这种别扭一个复杂任务丢进去它既想帮你搜代码、又想帮你改架构、还想顺手把文档写了结果每件事都做得不深。oh-my-opencode下面简称 OmO火起来的原因就是它把「一个全能 Agent」拆成了「一个协调者 一群专业 Agent」的团队模式——Sisyphus 负责拆任务和汇总explore 负责快速搜代码oracle 负责架构审查develop 负责落地实现frontend-ui-ux-engineer 管界面document-writer 管文档。问题在于OmO 原本跑在 codeagent-wrapper 那套体系里要装 codex、opencode、gemini 一堆 CLI配置散在~/.codeagent/models.json。而 Claude Code 的生态是settings.jsonskills/目录 斜杠命令两者不是一回事。我试过直接把 OmO 的 models.json 拷过去Claude Code 根本不认因为它读的是自己的配置结构。这篇要解决的就是这个移植问题把 OmO 的「协调者 专业 Agent 团队」骨架翻译成 Claude Code 能识别的settings.json和skills/目录结构再通过 TaoToken 的统一 Key 和 API 通道让这些 Agent 各自调用合适的模型。适合已经在用 Claude Code、想复用 OmO 协同编排思路的开发者。读完你能拿到一份可复制的配置骨架跑通一次多 Agent 协同任务并知道出错时先查哪里。2. TaoToken 前置统一 Key 与 API 通道移植的第一个卡点是模型接入。OmO 原版里每个 Agent 背后是不同的 backendclaude、opencode、codex、gemini你得分别配四套 API key。搬到 Claude Code 后如果还按这个思路走配置会碎成一地。更省事的做法是让所有 Agent 走同一个 API 通道用统一 Key 管理模型差异只在请求参数里体现。TaoToken 在这里扮演的就是这个统一通道的角色。它的 API 地址是https://taotoken.net/api兼容 OpenAI 风格的调用方式Claude Code 侧通过环境变量把 base_url 指过去即可。这样 Sisyphus、oracle、explore 这些 Agent 不需要各自维护一套凭证换模型只改配置里的 model 字段。你需要先拿到一个 Key。登录后在控制台创建控制台入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsoleAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys创建完把 Key 存到环境变量里别硬编码进settings.json否则提交到 git 就泄露了。Linux/macOS 下写进~/.zshrc或~/.bashrcexport TAOTOKEN_API_KEYsk-你的key export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEY$TAOTOKEN_API_KEYWindows PowerShell 用$env:TAOTOKEN_API_KEYsk-你的key $env:ANTHROPIC_BASE_URLhttps://taotoken.net/api $env:ANTHROPIC_API_KEY$env:TAOTOKEN_API_KEY注意Claude Code 读的是ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY这两个变量名别写成OPENAI_*否则它不会走你指定的通道。改完环境变量记得重开终端或者source ~/.zshrc让它生效。如果你还想在浏览器里先验证模型通不通可以用模型对话页面发一条测试消息确认 Key 有效再往下配模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat3. 可复制的 settings.json 与 skills 目录骨架Claude Code 的配置分两层全局的~/.claude/settings.json管模型、权限、环境项目或全局的~/.claude/skills/目录管技能定义。我们要做的就是把 OmO 的 Agent 团队映射成「一个协调 skill 若干专业 skill」。先看目录骨架建议放在~/.claude/skills/omo/下~/.claude/skills/omo/ ├── SKILL.md # 协调者 Sisyphus 的主入口 ├── agents/ │ ├── explore.md # 代码探索 │ ├── oracle.md # 架构审查 │ ├── develop.md # 实现落地 │ ├── frontend.md # UI/UX │ └── writer.md # 文档生成 └── models.json # Agent 到模型的映射SKILL.md是协调者的定义Claude Code 通过它识别/omo命令。核心内容是告诉它收到任务后先判断类型再决定委派给哪些 agent、是并行还是串行。写法上不用太复杂把 OmO 的 Intent Gate 思路用自然语言描述清楚即可--- name: omo description: 多 Agent 协同协调器按任务类型委派给专业 Agent --- # OmO 协调器 收到任务后先做意图判断 1. 任务涉及哪些领域搜索/架构/实现/UI/文档 2. 哪些 Agent 可以并行哪些必须串行 3. 汇总各 Agent 结果后返回 委派时读取 agents/ 下对应的定义按 models.json 里的映射选择模型。models.json是移植的关键它对应 OmO 原版的~/.codeagent/models.json但字段要改成 Claude Code 能读的形式{ default_model: claude-sonnet-4-20250514, agents: { sisyphus: { model: claude-sonnet-4-20250514, role: coordinator }, explore: { model: grok-code, role: search }, oracle: { model: claude-opus-4-5-20251101, role: review }, develop: { model: gpt-5.2, role: implement }, frontend: { model: gemini-3-pro-preview, role: ui }, writer: { model: gemini-3-flash-preview, role: doc } } }然后是全局~/.claude/settings.json把模型通道和权限配好{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的key }, model: claude-sonnet-4-20250514, permissions: { allow: [ Read, Write, Bash(git:*), Bash(npm:*) ] } }提示permissions.allow里别一上来就放Bash(*)多 Agent 并行执行时权限过宽容易误操作。先按需放开跑顺了再逐步加。每个 agent 的.md文件写清楚它的职责和输出格式比如agents/explore.md--- name: explore model: grok-code --- # Explore Agent 职责快速搜索代码库定位相关文件和函数。 输出文件路径列表 每个文件的作用一句话说明。 不要修改任何文件。agents/oracle.md则强调只做审查不改代码--- name: oracle model: claude-opus-4-5-20251101 --- # Oracle Agent 职责审查架构设计指出耦合、扩展性、性能问题。 输出问题列表 每个问题的严重程度 修改建议。 只读不写文件。这套骨架的好处是模型映射集中在models.json职责定义分散在各 agent 文件里改一个不影响其他。相比 OmO 原版把 backend 和 model 混在一个大 JSON 里维护起来清爽不少。4. 验证一次多 Agent 协同任务配置写完得跑一次真实任务验证。选一个能触发多 Agent 的场景比如「重构认证模块」。这个任务天然需要explore 搜代码、oracle 审架构、develop 改实现正好覆盖三个 Agent。在 Claude Code 里输入/omo 重构 src/auth 下的认证模块把 session 逻辑抽成独立服务预期执行流程是这样的第一步Sisyphus 分析任务判断需要 explore oracle develop 三个 Agent。它会先委派 explore 搜索src/auth下所有相关文件。explore 用轻量模型grok-code快速返回文件列表比如session.ts、login.ts、middleware.ts。第二步Sisyphus 把 explore 的结果交给 oracle让 oracle 审查现有架构。oracle 用较强模型claude-opus分析后返回问题清单比如「session 和 login 耦合过紧」「middleware 直接操作 session 对象」。第三步Sisyphus 把 oracle 的建议交给 developdevelop 用 gpt-5.2 执行重构抽出session-service.ts修改login.ts和middleware.ts的调用。验证成功的标志有三个一是 Claude Code 输出里能看到明确的 Agent 切换记录比如[explore] searching...、[oracle] reviewing...、[develop] implementing...二是最终 diff 里session-service.ts被创建原文件调用被替换三是没有出现「Agent 未找到」或「model not available」的报错。如果任务更偏全栈比如「给支付页加后端 API」Sisyphus 会并行启动 frontend 和 develop前者用 gemini-3-pro 设计界面后者用 gpt-5.2 写接口最后协调两者的接口对接。这种并行是 OmO 效率优势的来源实测复杂任务能省 40% 到 50% 的时间。跑通之后你可以把常用任务固化成斜杠命令比如/omo-refactor、/omo-feature省得每次手打长描述。5. 本篇常见错排查移植过程中最容易踩的坑集中在配置读取和模型映射两块按出现频率排一下。报错一Skill omo not found说明 Claude Code 没扫到你的 skill 目录。先确认路径是~/.claude/skills/omo/SKILL.md注意SKILL.md大小写敏感必须是全大写。再检查 frontmatter 里的name字段和目录名是否一致不一致时以name为准。改完重启 Claude Code。报错二model not available或请求 404多半是models.json里的模型名和 TaoToken 通道支持的名称对不上。先去模型对话页面确认你要用的模型标识再回填。另外检查ANTHROPIC_BASE_URL有没有写成https://taotoken.net/api/末尾多斜杠有时会导致路径拼接错误标准写法不带末尾斜杠。报错三Agent 之间结果传丢表现为 explore 搜到了文件但 oracle 说「没有收到上下文」。这是协调者 prompt 没写清楚传递规则。在SKILL.md里补一句「委派下一个 Agent 时必须把上一个 Agent 的完整输出作为上下文传入」Claude Code 会按这个约束组织调用。报错四并行执行时权限冲突两个 Agent 同时写同一个文件导致内容互相覆盖。解决办法是在settings.json的 permissions 里限制写权限或者在 agent 定义里明确「develop 负责写frontend 只输出建议不写文件」。OmO 原版靠 yolo 开关控制移植后靠权限和职责划分控制。报错五Key 泄露到日志如果你把 Key 直接写进settings.json而不是环境变量Claude Code 的调试日志可能把它打出来。养成用环境变量的习惯settings.json里只引用变量名。排查顺序建议先看 Claude Code 启动时有没有加载 skill 的日志再看环境变量是否生效echo $ANTHROPIC_BASE_URL最后看models.json的模型名。三步走完九成问题能定位。6. 继续把协同跑顺配置骨架搭好只是起点真正让多 Agent 协同发挥价值的是任务拆分和模型选择的匹配。我的经验是explore 这类搜索任务用便宜快速的模型完全够oracle 这种审查任务值得上强模型develop 看代码复杂度灵活选。别所有 Agent 都堆同一个贵模型那样成本优势就没了。如果你打算长期用这套协同模式跑编码和 Agent 任务可以看下 Coding Plan它按编码场景做了额度优化比单次调用更划算Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan接入细节和参数说明都在文档里遇到配置问题先翻文档再排查接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc最后留一个实用技巧把models.json纳入版本管理但 Key 走环境变量这样团队里每个人拉下来改改环境变量就能用同一套 Agent 编排。跑顺之后你会发现真正省时间的不是某个模型多强而是任务被拆对了、派给了对的 Agent。
OmO skills 实战：把 oh-my-opencode 多 Agent 协同搬进 Claude Code 的配置骨架
1. 为什么要把 OmO 的多 Agent 协同搬进 Claude Code如果你已经在用 Claude Code 写代码大概率遇到过这种别扭一个复杂任务丢进去它既想帮你搜代码、又想帮你改架构、还想顺手把文档写了结果每件事都做得不深。oh-my-opencode下面简称 OmO火起来的原因就是它把「一个全能 Agent」拆成了「一个协调者 一群专业 Agent」的团队模式——Sisyphus 负责拆任务和汇总explore 负责快速搜代码oracle 负责架构审查develop 负责落地实现frontend-ui-ux-engineer 管界面document-writer 管文档。问题在于OmO 原本跑在 codeagent-wrapper 那套体系里要装 codex、opencode、gemini 一堆 CLI配置散在~/.codeagent/models.json。而 Claude Code 的生态是settings.jsonskills/目录 斜杠命令两者不是一回事。我试过直接把 OmO 的 models.json 拷过去Claude Code 根本不认因为它读的是自己的配置结构。这篇要解决的就是这个移植问题把 OmO 的「协调者 专业 Agent 团队」骨架翻译成 Claude Code 能识别的settings.json和skills/目录结构再通过 TaoToken 的统一 Key 和 API 通道让这些 Agent 各自调用合适的模型。适合已经在用 Claude Code、想复用 OmO 协同编排思路的开发者。读完你能拿到一份可复制的配置骨架跑通一次多 Agent 协同任务并知道出错时先查哪里。2. TaoToken 前置统一 Key 与 API 通道移植的第一个卡点是模型接入。OmO 原版里每个 Agent 背后是不同的 backendclaude、opencode、codex、gemini你得分别配四套 API key。搬到 Claude Code 后如果还按这个思路走配置会碎成一地。更省事的做法是让所有 Agent 走同一个 API 通道用统一 Key 管理模型差异只在请求参数里体现。TaoToken 在这里扮演的就是这个统一通道的角色。它的 API 地址是https://taotoken.net/api兼容 OpenAI 风格的调用方式Claude Code 侧通过环境变量把 base_url 指过去即可。这样 Sisyphus、oracle、explore 这些 Agent 不需要各自维护一套凭证换模型只改配置里的 model 字段。你需要先拿到一个 Key。登录后在控制台创建控制台入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsoleAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys创建完把 Key 存到环境变量里别硬编码进settings.json否则提交到 git 就泄露了。Linux/macOS 下写进~/.zshrc或~/.bashrcexport TAOTOKEN_API_KEYsk-你的key export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEY$TAOTOKEN_API_KEYWindows PowerShell 用$env:TAOTOKEN_API_KEYsk-你的key $env:ANTHROPIC_BASE_URLhttps://taotoken.net/api $env:ANTHROPIC_API_KEY$env:TAOTOKEN_API_KEY注意Claude Code 读的是ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY这两个变量名别写成OPENAI_*否则它不会走你指定的通道。改完环境变量记得重开终端或者source ~/.zshrc让它生效。如果你还想在浏览器里先验证模型通不通可以用模型对话页面发一条测试消息确认 Key 有效再往下配模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat3. 可复制的 settings.json 与 skills 目录骨架Claude Code 的配置分两层全局的~/.claude/settings.json管模型、权限、环境项目或全局的~/.claude/skills/目录管技能定义。我们要做的就是把 OmO 的 Agent 团队映射成「一个协调 skill 若干专业 skill」。先看目录骨架建议放在~/.claude/skills/omo/下~/.claude/skills/omo/ ├── SKILL.md # 协调者 Sisyphus 的主入口 ├── agents/ │ ├── explore.md # 代码探索 │ ├── oracle.md # 架构审查 │ ├── develop.md # 实现落地 │ ├── frontend.md # UI/UX │ └── writer.md # 文档生成 └── models.json # Agent 到模型的映射SKILL.md是协调者的定义Claude Code 通过它识别/omo命令。核心内容是告诉它收到任务后先判断类型再决定委派给哪些 agent、是并行还是串行。写法上不用太复杂把 OmO 的 Intent Gate 思路用自然语言描述清楚即可--- name: omo description: 多 Agent 协同协调器按任务类型委派给专业 Agent --- # OmO 协调器 收到任务后先做意图判断 1. 任务涉及哪些领域搜索/架构/实现/UI/文档 2. 哪些 Agent 可以并行哪些必须串行 3. 汇总各 Agent 结果后返回 委派时读取 agents/ 下对应的定义按 models.json 里的映射选择模型。models.json是移植的关键它对应 OmO 原版的~/.codeagent/models.json但字段要改成 Claude Code 能读的形式{ default_model: claude-sonnet-4-20250514, agents: { sisyphus: { model: claude-sonnet-4-20250514, role: coordinator }, explore: { model: grok-code, role: search }, oracle: { model: claude-opus-4-5-20251101, role: review }, develop: { model: gpt-5.2, role: implement }, frontend: { model: gemini-3-pro-preview, role: ui }, writer: { model: gemini-3-flash-preview, role: doc } } }然后是全局~/.claude/settings.json把模型通道和权限配好{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的key }, model: claude-sonnet-4-20250514, permissions: { allow: [ Read, Write, Bash(git:*), Bash(npm:*) ] } }提示permissions.allow里别一上来就放Bash(*)多 Agent 并行执行时权限过宽容易误操作。先按需放开跑顺了再逐步加。每个 agent 的.md文件写清楚它的职责和输出格式比如agents/explore.md--- name: explore model: grok-code --- # Explore Agent 职责快速搜索代码库定位相关文件和函数。 输出文件路径列表 每个文件的作用一句话说明。 不要修改任何文件。agents/oracle.md则强调只做审查不改代码--- name: oracle model: claude-opus-4-5-20251101 --- # Oracle Agent 职责审查架构设计指出耦合、扩展性、性能问题。 输出问题列表 每个问题的严重程度 修改建议。 只读不写文件。这套骨架的好处是模型映射集中在models.json职责定义分散在各 agent 文件里改一个不影响其他。相比 OmO 原版把 backend 和 model 混在一个大 JSON 里维护起来清爽不少。4. 验证一次多 Agent 协同任务配置写完得跑一次真实任务验证。选一个能触发多 Agent 的场景比如「重构认证模块」。这个任务天然需要explore 搜代码、oracle 审架构、develop 改实现正好覆盖三个 Agent。在 Claude Code 里输入/omo 重构 src/auth 下的认证模块把 session 逻辑抽成独立服务预期执行流程是这样的第一步Sisyphus 分析任务判断需要 explore oracle develop 三个 Agent。它会先委派 explore 搜索src/auth下所有相关文件。explore 用轻量模型grok-code快速返回文件列表比如session.ts、login.ts、middleware.ts。第二步Sisyphus 把 explore 的结果交给 oracle让 oracle 审查现有架构。oracle 用较强模型claude-opus分析后返回问题清单比如「session 和 login 耦合过紧」「middleware 直接操作 session 对象」。第三步Sisyphus 把 oracle 的建议交给 developdevelop 用 gpt-5.2 执行重构抽出session-service.ts修改login.ts和middleware.ts的调用。验证成功的标志有三个一是 Claude Code 输出里能看到明确的 Agent 切换记录比如[explore] searching...、[oracle] reviewing...、[develop] implementing...二是最终 diff 里session-service.ts被创建原文件调用被替换三是没有出现「Agent 未找到」或「model not available」的报错。如果任务更偏全栈比如「给支付页加后端 API」Sisyphus 会并行启动 frontend 和 develop前者用 gemini-3-pro 设计界面后者用 gpt-5.2 写接口最后协调两者的接口对接。这种并行是 OmO 效率优势的来源实测复杂任务能省 40% 到 50% 的时间。跑通之后你可以把常用任务固化成斜杠命令比如/omo-refactor、/omo-feature省得每次手打长描述。5. 本篇常见错排查移植过程中最容易踩的坑集中在配置读取和模型映射两块按出现频率排一下。报错一Skill omo not found说明 Claude Code 没扫到你的 skill 目录。先确认路径是~/.claude/skills/omo/SKILL.md注意SKILL.md大小写敏感必须是全大写。再检查 frontmatter 里的name字段和目录名是否一致不一致时以name为准。改完重启 Claude Code。报错二model not available或请求 404多半是models.json里的模型名和 TaoToken 通道支持的名称对不上。先去模型对话页面确认你要用的模型标识再回填。另外检查ANTHROPIC_BASE_URL有没有写成https://taotoken.net/api/末尾多斜杠有时会导致路径拼接错误标准写法不带末尾斜杠。报错三Agent 之间结果传丢表现为 explore 搜到了文件但 oracle 说「没有收到上下文」。这是协调者 prompt 没写清楚传递规则。在SKILL.md里补一句「委派下一个 Agent 时必须把上一个 Agent 的完整输出作为上下文传入」Claude Code 会按这个约束组织调用。报错四并行执行时权限冲突两个 Agent 同时写同一个文件导致内容互相覆盖。解决办法是在settings.json的 permissions 里限制写权限或者在 agent 定义里明确「develop 负责写frontend 只输出建议不写文件」。OmO 原版靠 yolo 开关控制移植后靠权限和职责划分控制。报错五Key 泄露到日志如果你把 Key 直接写进settings.json而不是环境变量Claude Code 的调试日志可能把它打出来。养成用环境变量的习惯settings.json里只引用变量名。排查顺序建议先看 Claude Code 启动时有没有加载 skill 的日志再看环境变量是否生效echo $ANTHROPIC_BASE_URL最后看models.json的模型名。三步走完九成问题能定位。6. 继续把协同跑顺配置骨架搭好只是起点真正让多 Agent 协同发挥价值的是任务拆分和模型选择的匹配。我的经验是explore 这类搜索任务用便宜快速的模型完全够oracle 这种审查任务值得上强模型develop 看代码复杂度灵活选。别所有 Agent 都堆同一个贵模型那样成本优势就没了。如果你打算长期用这套协同模式跑编码和 Agent 任务可以看下 Coding Plan它按编码场景做了额度优化比单次调用更划算Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan接入细节和参数说明都在文档里遇到配置问题先翻文档再排查接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc最后留一个实用技巧把models.json纳入版本管理但 Key 走环境变量这样团队里每个人拉下来改改环境变量就能用同一套 Agent 编排。跑顺之后你会发现真正省时间的不是某个模型多强而是任务被拆对了、派给了对的 Agent。
