04 多 Agent 协作范式与发布流程

04 多 Agent 协作范式与发布流程

本节摘要:这是全书最后一节正文。OpenWork 项目自身用 AI Agent 开发(用自己开发自己,即 dogfooding),形成了一套多 Agent 协作范式——编排者只思考不写码、执行者只写码、深度执行者处理硬骨头。本节讲清这套协作范式,以及项目的发布流程。这展示了「AI 开发 AI 产品」的真实实践。

一、OpenWork 用自己开发自己(dogfooding)

先点出一个有意思的事实:OpenWork 项目用自己的 Agent 配置开发自己。它的项目目录里有 .opencode/agents/ 等(OpenCode 教程第 11 章),定义了项目开发用的 Agent。这意味着 OpenWork 团队日常开发就是用 OpenCode 的 Agent——既是「用」,也是「测」。

这种「用自己的产品开发自己的产品」叫 dogfooding(吃自己的狗粮)。它让团队第一时间发现产品问题,保持对产品的真实感知。

二、多 Agent 协作范式

OpenWork 的开发用了一套精细的多 Agent 协作——不止一个 Agent 干所有事,而是分工:

任务到来
   │
   ▼ orchestrator 思考、分解
   │
   ▼ 委派给 executor(经 Task 工具)
   │
   ├─ executor 干完,回报
   │
   ▼ orchestrator 验证
   │
   ├─ 通过 ──► 完成
   └─ 失败 ──► 同 task 续命(给失败输出+精确修复指令)
        │
        ▼ 两轮还失败 ──► 升级 executor-deep
​

三、orchestrator:只思考不写码

这是这套范式最关键的设计。orchestrator 只负责思考与验证,不写代码:

• 思考:分解任务、规划方案、写 brief(给 executor 的任务说明)
• 验证:executor 交付后,验证是否达标(用 fraimz 等)
• 委派:通过 Task 工具把编码委派给 executor

它不亲自编码——所有编码都委派。这让 orchestrator 专注「想对」和「验对」,不被「写码」分心。

brief 格式

orchestrator 给 executor 的 brief 有固定格式:

brief = {
   Goal: 目标,
   Files: 涉及文件(path:line),
   Constraints: 约束,
   Acceptance: 验收标准,
   Verify: 验证方式
}
​

这种结构化 brief 让 executor 清楚「要干什么、改哪、约束、怎么算完成」。

四、修复循环:防 ping-pong

orchestrator 的修复循环有个上限:同 task 续命最多两轮,两轮还失败就升级 executor-deep,不无限 ping-pong:

executor 失败
   │
   ▼ 第1轮续命:给失败输出+精确修复指令
   │
   ├─ 成功 ──► 完成
   └─ 失败
        │
        ▼ 第2轮续命
        │
        ├─ 成功 ──► 完成
        └─ 失败 ──► 升级 executor-deep(不继续 ping-pong)
​

这防止了「orchestrator 和 executor 无限来回踢皮球」——两轮搞不定就升级,换更强的执行者。

五、验证阶梯

orchestrator 验证 executor 交付时,有个验证阶梯——不同类型的改动用不同方式验证:

• runtime-observable 改动:用 fraimz(第 03 节)证明(实际跑+截图)。
• docs/types/.opencode config:跳过 fraimz(这些不适合帧证明),直接看。

orchestrator 不会对「docs」也强求 fraimz——它知道什么该帧证明、什么该跳过,明说。

六、executor 与 executor-deep 的分工

• executor:routine 任务。收到具体 brief 后精确实现,不扩 scope(不加没要求的东西)。用最窄 fast check 验证。回报简短(≤30 行:改了哪些文件 path:line + 命令 + exit codes + 跳过/假设)。
• executor-deep:处理硬骨头——多文件特性、重构、棘手调试,或 executor 两轮失败后升级。用更强的模型变体(xhigh),能处理更复杂的。

这种「routine 给快模型、硬骨头给强模型」的分工,既高效(executor 快又省)又可靠(deep 兜底硬的)。

七、发布流程

OpenWork 的发布大致流程:

1. review(评审):代码评审 + fraimz 证据
2. prepare(准备):版本号 bump、changelog、构建产物
3. ship(发布):发布到各渠道(GitHub release、Docker、Helm、AUR)
​

发布脚本(scripts/release/ 下)编排这三步。版本号有 bump 脚本(patch/minor/major)。桌面应用发布到 GitHub(供自动更新拉取)。

八、第 13 章收尾:工程方法论的全貌

读完第 13 章四节,你掌握了 OpenWork 的工程方法论全貌:

核心认知:OpenWork 不仅是个产品,还是一套「AI 开发 AI 产品」的工程实践——多 Agent 分工协作、fraimz 帧帧证明、多渠道分发。这套方法论可迁移到其他 AI 项目。

九、全书正文结束

读完第 13 章,你走完了 OpenWork 教程的全部十三章正文。从第 1 章「跑起来」,到第 2 章「三进程模型」,到第 38 章「服务端与能力体系」,到第 911 章「桌面前端连接」,到第 12~13 章「企业与交付」——你掌握了 OpenWork 从「能用」到「懂原理」到「能交付」的完整图景。

附录 A 是检索型参考,随时查阅术语、命令、报错。若你想深入底层引擎(OpenCode)本身,可参阅引擎教程——二者互补,合起来是「AI Coding Agent 引擎 + 平台」的完整知识体系。

本节要点回顾

1. dogfooding:OpenWork 用自己的 Agent 开发自己,既是用也是测。
2. 多 Agent 分工:orchestrator(只思考验证)/ executor(routine 编码)/ executor-deep(硬骨头)/ triage(分流)。
3. orchestrator 不写码:专注想+验,编码全委派——结构化 brief 指导 executor。
4. 修复循环上限:同 task 两轮失败升级 deep,不 ping-pong。
5. 验证阶梯:runtime 改动用 fraimz,docs/config 跳过——知道什么该帧证明。
6. executor vs deep:routine 给快模型(省),硬骨头给强模型(兜底)。
7. 发布流程:review → prepare → ship,多渠道发布。
8. 第 13 章结束:工程方法论全貌——多 Agent + fraimz + 多渠道,可迁移。
9. 全书正文结束:十三章走完「能用→懂原理→能交付」。

全书十三章正文到此结束。下面是附录 A 的检索内容。