多模型 Agent 编排实战：一次提示词背后的 50 次 AI 协作

当我坐在终端前，输入那行提示词的时候，我并没有意识到自己正在启动一个小型的“软件工厂”。

“实现 Headless API，支持异步任务队列、SSE 流式状态推送，并集成结构化数据提取功能。”

回车键落下的瞬间，屏幕背后开始了一场极其复杂的协作。这并不是某种魔法，而是一套经过严密编排的多模型 Agent 系统在高速运转。最终，在不到十分钟的时间里，系统自动完成了 3 次代码提交，新增了 25 个文件，产出了 4,142 行代码，并编写了 191 个测试用例，所有自动化检查（Auto Gate）全部绿灯通过。

通过监控后台的 Trace 记录，我看到了惊人的数字：这一句简单的指令，触发了 35 到 50 次大模型推理调用，执行了 100 到 150 次工具调用（包括文件读写、搜索、测试运行）。这不再是简单的“对话式编程”，而是真正的 Agent 编排工程化实践。

项目背景

这次实战的载体是我一直在维护的文档提取工具 Extractor。它的核心技术栈非常现代：Next.js 16, TypeScript, Drizzle ORM, 数据库运行在 MySQL/TDSQL 上。

Extractor 的初衷是利用多模态大模型将 PDF、图片或 DOCX 文件转换为高质量的 Markdown 格式。随着项目演进，我需要为它增加一套 Headless API，让外部系统能通过 API 提交任务。这涉及到一套完整的异步处理流程：用户上传文件，系统将其放入任务队列，通过服务端发送事件（SSE）实时推送处理进度，最后通过 Webhook 回调结果。

我使用的开发工具是 OpenCode 配合 oh-my-opencode 插件。这套系统的核心在于它不依赖单一模型，而是根据任务的性质，动态地在 Claude、GPT 和 Gemini 家族之间调度最合适的模型。

多模型分工的设计哲学

这套 Agent 系统遵循了四个核心设计原则。这些原则决定了系统如何处理那 50 次 AI 协作。

原则一：能力匹配

不同的模型在特定领域表现各异，每个环节选择了最强的模型。

原则二：交叉审查

这是系统的核心安全机制，有执行者（sisyphus）和审查者（momus）。

执行者由 Claude Opus 担任，而审查者则必须来自不同的模型家族，这里选择了 GPT-5.4 xhigh。

同一家族的模型往往具有相似的思维盲点。如果执行者写错了一个边界条件，同家族的审查者很大概率也会漏掉这个错误。跨家族的交叉审查能提供真正独立的第二意见，避免系统陷入自我证明的陷阱。

原则三：成本梯度

由于不能在所有任务上都挥霍最贵的模型，系统建立了一套成本阶梯：

昂贵 ←──────────────────────────→ 廉价
Opus max    GPT-5.4 xhigh    Sonnet    Gemini Pro    Mini/Haiku/Flash
(sisyphus)  (momus/oracle)  (librarian) (visual)     (explore/quick/writing)

高频、低智能要求的任务（如代码库搜索、文档读取）使用廉价模型；低频、高智力要求的任务（如架构决策、核心逻辑实现）使用最顶尖的模型。

原则四：Variant 控制推理深度

即便是同一个模型，也可以通过 Variant 参数控制其思考的深度。

Agent 全景配置表

最后，在 oh-my-opencode.json 中，具体的配置如下：

此外，系统还定义了特定的任务类别（Category）：

一个令人不安的发现：这些几乎都是默认值

写完上面那些关于”设计哲学”和”精心配置”的段落后，我做了一件在复盘时才想起来的事情——把自己的配置和 oh-my-opencode 的内置默认值进行了逐项比对。

结果让我沉默了很久。

默认值对照表

以下是 oh-my-opencode v3.11.2 内置的 AGENT_MODEL_REQUIREMENTS 和 CATEGORY_MODEL_REQUIREMENTS 与我实际配置的对比：

Agent 配置对比：

Category 配置对比：

统计结果：17 个配置项中，8 个完全一致，5 个仅是 Preview 变体差异（功能等价），只有 4 个是我真正自定义的。

也就是说，那篇洋洋洒洒写了四条”设计原则”的章节——能力匹配、交叉审查、成本梯度、Variant 控制——这些并不是我的发明，它们早已被 oh-my-opencode 的作者编码进了默认配置中。

我所做的”定制”，不过是：把 librarian 从 Flash 换成了 Sonnet（因为我希望文档搜索更精准），把 explore 换成了 GPT-5-mini（纯粹个人偏好），以及把 unspecified-high 从 GPT-5.4 降到了 Sonnet（为了省钱）。这些修改对系统整体架构没有任何本质影响。

换句话说：前文所描述的那套精密编排系统——Opus 做执行与规划、GPT-5.4 做跨家族审查、Gemini 做视觉与创意、Haiku/Flash 做廉价苦力——全部是默认行为。

这意味着什么？

任何一个安装了 oh-my-opencode 的开发者，在没有修改任何配置的情况下，就已经拥有了几乎相同的多模型编排能力，这些”精心设计”的原则，不过是在事后对默认值做了一次合理化叙事。

一句提示词的完整生命周期

以本次的需求为例，当提示词进入系统后，它经历了一个从串行到大规模并行的演变过程。

阶段 0：意图识别与复杂性分级

主编排器 sisyphus (Claude Opus max) 首先评估任务。它识别出这涉及到多个文件的创建和复杂的系统集成（API、队列、SSE、测试），于是将其标记为“复杂实现任务”。

阶段 1：大规模并行探索（Fan-out）

系统并没有立刻写代码，而是启动了后台任务：

1. 3 个 explore 代理 (GPT-5-mini) 异步启动：它们并行检索项目中现有的 Drizzle Schema、API 路由模式和 SSE 的实现样例。
2. 5 个 librarian 代理 (Claude Sonnet) 同时向外搜索：查询 Next.js 16 下 SSE 的最佳实践、docx 到 markdown 的转换库、以及 OpenAI 结构化输出（JSON Mode）的最新规范。

在这些代理在后台搜集情报的同时，sisyphus 正在利用 metis 的反馈制定详细的 todo 任务列表。

阶段 2：任务委派与原子化实现

这是协作最频繁的阶段。sisyphus 将任务拆解后进行委派：

• 8 个 Sisyphus-Junior 任务 通过 quick 类别 (Claude Haiku) 派发。Haiku 负责编写 4 个 Service 基础文件（job-store, webhook-handler 等）以及对应的 4 个单元测试文件。这些任务是独立的，可以并行完成。
• 主逻辑实现 由 sisyphus (Claude Opus) 亲自操刀。它负责编写 3 个核心 API 路由文件和 2 个复杂的集成测试。

阶段 3：自动化验证循环（Auto Gate）

代码写完并不意味着结束。系统进入了三轮 Auto Gate 循环：

1. 静态检查：运行 Biome 进行 lint 和格式化。
2. 类型安全：运行 pnpm typecheck 确保 TypeScript 类型推导无误。
3. 功能验证：运行 pnpm test。

在这一过程中，sisyphus 自身负责定位和修复测试失败，通过 lsp_diagnostics 和错误日志精准定位了 2 处路径引用错误并完成修复。

协作拓扑图

            用户的一条提示词
                 │
          ┌──────┴──────┐
          │  sisyphus    │  ← Claude Opus max (总编排)
          └──────┬──────┘
     ┌───────┬───┼───┬────────┐
     │       │   │   │        │
  explore  lib  lib  Jr.     Jr.     ← 并行扇出
  (mini)  (son) (son)(haiku) (haiku)
     │       │   │   │        │
   检索    搜索  fetch 代码    代码    ← 各 Agent 调用工具
   代码    文档  参考  实现    实现
                      测试    测试

实际产出与数据

经过这一轮密集的协作，最终的成果远超手动编写的效率：

• Commit 1: Headless API 基础架构。涵盖了 Service 层、Drizzle 存储逻辑和 Webhook 机制。共修改/新增 17 个文件，增加 2,119 行代码。
• Commit 2: 集成测试套件。编写了完整的端到端测试，模拟从上传到 SSE 获取进度的全过程。共 2 个大文件，1,008 行代码。
• Commit 3: 结构化数据提取。集成了 OpenAI 的 JSON Schema 强制校验，确保提取结果符合预期。修改 6 个文件，1,015 行代码。

总计：25 个文件，4,142 行代码，191 个测试用例，所有自动化检查全部绿灯。

经验总结

这次实践让我对 AI 驱动的软件工程有了全新的认识。其中一些是技术层面的，另一些则触及更深层的问题。

默认值即最佳实践——你以为的”定制”可能只是默认行为。 这是本文最重要的结论。oh-my-opencode 的作者已经将多模型编排的核心策略（能力匹配、交叉审查、成本梯度、Variant 控制）编码进了默认配置。我所做的 4 项调整，没有一项触及系统的核心架构。这意味着这些编排原则已经从”专家经验”变成了”基础设施”——你不需要理解它们为什么这样设计，也能直接享受到它们的红利。

模型多样性是实力，而不是混乱。 不要试图寻找一个”万能模型”。让 Claude 做架构和实现，让 GPT 做逻辑审计，让 Gemini 做多模态分析——这种分工不是人为制造的复杂性，而是在模型能力高度分化的时代，唯一能持续压榨出最大质量的方式。

交叉审查比同家族审查有效得多。 让 GPT-5 审查 Claude Opus 的代码，它能敏锐地发现 Claude 在处理某些边界情况时的惯性思维。这种跨家族的竞争关系显著提高了代码的稳健性。

成本优化是工程化的必经之路。 如果不加限制地使用最强模型，这 50 次调用的成本将非常惊人。通过合理划分 quick、explore 和 writing 类别，成本可以压缩到原本的 1/5，而质量不会下降。这个成本梯度——同样是默认配置的一部分。

并行是效率的关键。 当系统在后台通过 8 个并发代理预研和编写基础文件时，主 Agent 的思考并没有被打断。这种类似 CPU 超线程的开发模式，是单对话界面永远无法实现的。

那么，人类还需要做什么？

这才是那个让我真正要思考的问题。

回顾整个过程：我输入了一句话，系统默认配置已经足够优秀，50 次 AI 协作自动完成，191 个测试全部通过，4,142 行代码，10 分钟交付。从投入产出比来看，我的”贡献”似乎只是按了一下回车键。

一个不可回避的趋势

两年前，AI 还不能可靠地生成超过 100 行的代码。一年前，它开始能写出带测试的完整模块。今天，它已经能在 10 分钟内交付一个经过验证的完整子系统。

按照这个速度，之前我所认为的”人类独有的能力”——意图定义、品味判断、质量兜底、伦理把关、元认知——它们会永远是人类独有的吗？

在 2026 年的今天，这套系统的绝大部分编排智慧已经被沉淀为默认配置。开发者不需要理解多模型分工的原理，就能获得接近最优的协作效果。这件事本身就意味着——工具正在把专家知识民主化，而专家需要重新定义自己的价值。

结语

回到文章开头的那个场景。

我坐在终端前，输入一句话，按下回车。10 分钟后，4,142 行代码、191 个测试、3 次提交。

而我事后才意识到，驱动这一切的编排系统——那些关于模型选择、成本控制、交叉审查的精密设计——80% 都不是我做的。它们是默认值。

这让我想到一个类比。汽车刚发明时，驾驶是一项需要深厚机械知识的专业技能。你需要手动调节点火时机、手摇启动引擎、理解齿轮啮合原理。今天，你只需要转动钥匙。那些曾经属于”驾驶专家”的知识，早已沉淀进了发动机的默认设计里。

软件开发正在经历同样的转变。多模型编排的”四大原则”——能力匹配、交叉审查、成本梯度、推理深度控制——终将像自动变速箱一样，成为你不需要理解就能使用的基础设施。

到那时，人类开发者的价值不在于会开车，而在于知道该去哪里。