多Agent协作实战：主Agent调度Codex与Claude Code

市面上AI产品百花齐放，有的擅长Coding，有的UI审美在线，有的调研能力一绝。这些能力分散在不同产品里，能不能用一个主Agent把它们调度起来？这就是多Agent协作要解决的问题。B站UP主小山的「从零实现自己的agent」系列第十一期，展示了一个主Agent（Ampere Agent）调度Codex和Claude Code完成复杂任务的完整方案。

多Agent协作的核心思路：能力复用而非拼装

UP主强调，多Agent协作不是在一个AI产品内部重复启用，而是不同AI产品之间的调度。有人可能会问：一个Agent缺什么能力，外接Skill或MCP不就行了？UP主的观点是——外部Skill确实能补，但官方原生的执行效果往往更好。

他举了Codex的深图能力为例：外部当然有类似的Skill，但不可能比官方原生Codex执行得更好。所以更合理的做法是：主Agent把任务分工给最合适的Agent执行，最后统一收集结果并交付。

这种「能力复用」的思路，比把所有能力硬塞进一个Agent里更清晰。UP主用了一个生动的比喻：看似拔高了AI的上限，其实把它糊成了一坨。

主Agent调度界面

MCP（Model Context Protocol） 是由 Anthropic 提出并开源的标准化协议，旨在让 AI 应用以统一方式连接外部工具、数据源和服务。它类似于 AI 领域的「USB-C 接口」：开发者只需实现一次 MCP Server，就能被任何支持该协议的 Agent（如 Claude Code、Codex 等）调用，无需为每个产品单独适配。MCP 解决了工具集成碎片化的问题，使 Agent 能动态扩展能力边界。然而，正如文中 UP 主所指出的，MCP 或外部 Skill 提供的是通用能力接口，其执行效果受限于协议抽象层，往往不如产品官方原生集成的深度优化能力（例如 Codex 的深图）。因此，多 Agent 协作并非否定 MCP 的价值，而是在关键任务上优先选用原生能力更强的专用 Agent，通过调度实现优势互补。

两个执行Agent的定位：Codex与Claude Code

在UP主的项目中，集成了两个外部Agent，分工明确：

Codex：深图、调研与代码修改

Codex最受UP主青睐的是深图能力。项目里需要的插图、背景图、界面素材都可以用它生成；甚至在开发App之前，可以用深图技能为各个页面生成参考图，先确定UI效果，再对接后续Coding。

除了深图，Codex还承担联网调研任务——检索资料、比较信息真伪、核对来源。在控制方面，它也能修改代码、运行测试、排查实际错误。

Claude Code：编码与UI落地

Claude Code的定位更聚焦：核心Coding和UI落地。UP主称其为「编码天花板、UI审美大魔王」，自从Opus 5.5之后，把一个任务中的核心编码和界面实现交给它，基本没有问题。

Claude Code执行界面

任务分发机制：主Agent如何派活

分发任务前，主Agent需要先了解各个执行Agent的状态——模型、能力、真伪信息。然后结合任务需求和用户的选择要求，决定派发给谁。

派发时，工具需要向目标Agent说明：任务要做什么、怎样才算完成、工作区在哪里、是否显式指定了模型选择。把这些信息填入工具后，通过委派服务正式派发。

任务派发流程

适配器模式（Adapter Pattern） 是一种软件设计模式，用于将某个类的接口转换成客户端期望的另一个接口，使原本因接口不兼容而无法协作的类能够一起工作。在多 Agent 系统中，适配器层充当主 Agent 与各执行 Agent 之间的翻译官：它屏蔽不同 Agent 在通信协议、会话管理、事件格式上的差异，对外提供统一的调用接口。例如，文中主 Agent 通过适配器启动 Codex 的 App Server，将其本地控制入口封装成标准操作；对于 Claude Code，则通过 SDK 适配。适配器还负责将执行 Agent 产生的多样化输出（文本、工具状态、文件）归一化为统一事件，供主 Agent 消费。这种设计使得新增一个执行 Agent 时，只需编写对应的适配器，而无需修改主 Agent 的核心调度逻辑，极大提升了系统的可扩展性和可维护性。

Agent SDK（软件开发工具包） 是 AI 产品官方提供的编程接口集合，允许开发者在自己的应用程序中集成该 Agent 的完整能力。以 Claude Agent SDK 为例，它封装了与 Claude Code 交互的底层细节，包括会话创建、消息传递、工具调用、文件操作等，开发者只需调用高层 API 即可驱动 Claude Code 执行编码任务。SDK 通常还提供身份认证、错误处理、流式响应等机制，降低集成复杂度。与适配器模式不同，SDK 是官方预设的集成路径，稳定性和功能完整性更有保障；而适配器则用于封装那些没有提供标准 SDK 或需要特殊控制方式的 Agent（如通过本地 App Server 控制的 Codex）。两者结合，使主 Agent 能以灵活多样的方式调度异构执行体。

执行与回传：两条链路的设计

任务派发后，两个Agent的接收方式不同：

Codex：主Agent通过适配器启动本机Codex的App Server，把它理解成Codex提供的本地化控制入口。主Agent通过它创建或续接会话，开始一轮工作。
Claude Code：主Agent通过Claude Agent的SDK调用本机安装的Claude Code，把工作目录和模型选择传进去。

任务传入后，后续都由各自Agent的会话继续执行。执行结果和进度如何回馈主进程？UP主设计了两条返回路径：

过程进度：外部Agent产生的公开文本、工具状态、工具活动、状态，由适配器整理成统一事件，让主Agent更新任务记录和会话界面，用户可以跟进进度。
结束通知：任务结束时，服务收集结果并发出结束通知。主进程取回结果后，决定是补充要求续接原会话，还是直接交付给用户。

进度让用户看到「正在做什么」，结束通知才带回最终结果，由主进程决定下一步。

完整调度流程与实测效果

一个完整的调度流程是这样的：

用户派发任务给主进程
主进程明确目标和最终交付物，拆解出工作包（任务输入、产出、约束）
根据能力选择最合适的执行者，准备好任务并派发
执行者（Codex或Claude Code）执行完成，返回文本或文件成果
主进程检查结果是否达标，不达标则返回第3步，补充要求、续接原任务
检查通过，交付结果，任务结束

UP主实际演示了一个任务：让Ampere Agent使用Codex调研特斯拉斜坡飞车的视频并提取关键流程图片，再用Claude Code构建一个特斯拉3D飞车的演示复现视频，要求建模真实、动效符合原视频。

Ampere Agent先总结了一份复现计划文档：阶段A由Codex调研，阶段B由Claude Code构建复现。批准执行后，Codex成功启动并返回调研信息。主建设核实后认为调研质量很高，还纠正了原本的错误，随后启动Claude Code进行建模。

任务跑了几个小时，最后还做了精简。成片效果如何？UP主在视频中展示了预览图和成片：悬停、倒退、翻转动作、打开车门展示、飞跃卡车、喷气动画都有。UP主评价「跟视频里的效果几乎是一模一样」，车辆的建模和视频动作的还原度「百分百复现」，效果非常震撼。

当然也有瑕疵，比如翻转动作略显僵硬、喷气效果有点差劲、某个动作做错了。但整体上，通过简单的提示词就生成了这种质量的产品，体现了多Agent协作的价值。

主Agent工作界面

下一期方向：群聊式自主调度

UP主预告，下一期会在此基础上继续释放多Agent协作能力——让多个Agent像群聊一样在一个群组中不停对话反馈，实现自主调度，展现形式类似GrooveBot。

对于想自己动手实现的开发者，这个项目的价值在于：它给出了一套可落地的架构——适配器层、委派服务、双通道回传、检查-补发-续接的闭环。这套思路不依赖某一个特定产品，可以迁移到其他Agent的组合中。