OMC - 08 在多 Agent 时代，如何优雅地「分工协作」：oh-my-claudecode 委托分类体系深度解读

Pre

OMC - 01 用 19 个 Agent 打造你的 Claude Code“工程团队”：oh-my-claudecode 深度解析与实战指南

OMC - 02 五分钟起步，走向多智能体协作：深入解析 oh-my-claudecode 快速开始与架构设计

OMC - 03 从 0 到高效：Oh My ClaudeCode 安装与实践全指南

OMC - 04 用好 Oh-My-ClaudeCode 的 30 个会话技能：从“帮我写点代码”到端到端自动交付

OMC - 05 从单人到多 Agent：Oh-my-claudecode 的插件架构解析

OMC - 06 从“大模型管家”到“十九人专家团队”：oh-my-claudecode 的多 Agent 工程实践

OMC - 07 把「选模型」当成一门工程学：oh-my-claudecode 的三层模型路由实践

概述

大模型应用已经从「单一聊天助手」走向「多 Agent 协作系统」。如何在一个系统里管理十几个甚至几十个专用 Agent，让它们在合适的时机、以合适的成本、用合适的模型出手，是现在做 AI 编排的开发者绕不开的问题。

oh-my-claudecode 给出了一套相对完整的答案：用功能类别 + 成本层级对 Agent 建模，用触发规则驱动委派，用中间件强制模型路由，从而把「谁来做」「用什么算」「什么时候出手」这三个问题系统化。

这篇文章尝试用工程视角，把这一套委托分类体系拆开讲清楚，并结合一些实战思路，帮你在自己的多 Agent 系统里落地类似的设计。

一、问题背景：为什么需要「委托分类」？

在多 Agent 编排场景中，常见的几个痛点：

• 职责混乱：所有请求都丢给一个“大而全”的 Agent，提示词越来越肥，行为越来越不可控。
• 成本失控：本来一个简单搜索任务，结果动不动就拉起最贵的模型，按 token 付费的同学看着账单直冒冷汗。
• 路由玄学：到底什么时候该交给规划 Agent？什么时候该找专家 Agent？往往靠「感觉」写 if-else，很难维护。
• 行为漂移：明明只想让某个 Agent 做只读分析，它却顺手把代码改了，还不一定改对。

oh-my-claudecode 的委托分类体系，核心就是把这些“玄学路由”和“隐性约定”全部显性化，用类型系统和中间件来约束。

它围绕三个关键问题展开设计：

1. 角色划分：一个 Agent 在系统中的工作本质是什么？
2. 预算控制：调用它贵不贵？可以被调用多少次？
3. 路由规则：在什么场景下应该把任务交给它？在哪些情况下必须避开它？

接下来我们从这三个维度往下拆。

二、两个核心轴：功能类别与成本层级

在 oh-my-claudecode 中，每个 Agent 都有两条「标签」：功能类别（AgentCategory）和成本层级（AgentCost）。

2.1 功能类别：Agent 在团队中的职能

功能类别定义了 Agent 在「开发生命周期」中的角色，而不是技术实现细节。 简化后，你可以理解为下面这张表：

这种划分有两个好处：

• 一眼看出「这是一个什么性格的 Agent」：是负责造轮子的，还是负责挑毛病的。
• 方便在路由和提示词中做统一约束：比如所有 reviewer 都明确「不写代码，只看问题」。

2.2 成本层级：给调度器的预算信号

第二个轴是成本层级（AgentCost），本质上是给编排器看的预算提示：

• FREE：几乎不计成本的调用（通常是内置逻辑，或者非 LLM 部分）
• CHEAP：低成本、高吞吐量的 Agent，适合高频调用
• EXPENSIVE：推理质量高但昂贵的 Agent，适合关键决策节点

系统中会根据这个层级，配合模型层级（haiku / sonnet / opus）来做默认路由：例如 CHEAP 多半对应 haiku 或 sonnet，EXPENSIVE 则往 opus 靠。

这里有一个非常实用的设计：成本层级是“信号”，不是绑定。
比如 executor 既是 specialist，又标记为 CHEAP，但它默认模型选择的是 sonnet——说明在当前系统里，sonnet 也被视作可接受的低成本选项。

三、从架构泳道看多 Agent 协作「流水线」

功能类别是「纵向」的角色标签，而在架构层面，oh-my-claudecode 还把 Agent 按照开发流程分成了四条「泳道」：

• Coordination Lane：负责整体协调和编排（比如 critic）
• Review Lane：负责各种形式的审查与质量关卡
• Build/Analysis Lane：负责具体实现和分析（explore、analyst、planner、executor 等）
• Domain Lane：负责特定领域的专家能力，比如 designer、security-reviewer、test-engineer 等

3.1 典型流水线：从探索到验证

在这一架构下，一个典型的端到端 Agent 工作流大致是：

explore → analyst → planner → critic → executor → verifier

拆开看一下每个环节的职责：

1. explore：在代码库和项目结构中摸底，找到相关文件、模块和调用关系。
2. analyst：在执行前做「问题分析」，补齐隐形需求、边界条件和风险点。
3. planner：根据分析结果拆分任务，形成可执行计划与步骤列表。
4. critic：站在质量视角审查计划——是否漏情况、是否有明显坑。
5. executor：按计划逐步改代码、写测试、跑命令，真正「动手」。
6. verifier：验证变更结果，比如跑测试、检查 diff 合理性。

这一条流水线的好处在于：每个环节只做一个类型的决策或动作。
如果你自己要设计多 Agent 系统，可以直接沿用这条主干，再根据业务加减领域 Agent。

3.2 领域 Agent：按需并入流程

当任务涉及特定领域时，流程会「支路」调用相应专家 Agent：

• UI 或交互相关：叫上 designer。
• 测试策略与用例设计：找 test-engineer，或者 qa-tester。
• 安全与合规：拉 security-reviewer 参与审查。
• 文档与说明书：交给 document-specialist 或 writer。

这些领域 Agent 通常挂在 Domain Lane，由协调层或 planner 决定是否「插入」流水线。

四、触发器与路由：Agent 不是随便上的

有了角色和泳道，还需要回答一个关键问题：什么时候该委派给谁？
在 oh-my-claudecode 里，这部分由一套「触发器 + 指南」体系来驱动。

4.1 Agent 触发器：triggers + useWhen + avoidWhen

每个 Agent 的元数据中，都包含一组触发定义：{ domain, trigger }，同时配套useWhen和avoidWhen说明。

举几个代表性的例子（非原文照搬，按含义重新整理）：

在此基础上：

• useWhen用清单式语言说明「特别适合」的场景，例如“多文件重构”“系统性调优”。
• avoidWhen则反过来列出「应该避免」的场景，例如 explore 的 avoidWhen 中明确写到：
  • 外部文档搜索应该交给 document-specialist
  • 复杂架构问题应交给 architect
  • 已知文件路径的简单查找不需要任何委派，直接做就行

这个组合让路由逻辑可以从硬编码 if-else，转化成一份可维护的「配置式规则」。

4.2 自动构建「委派参考表」

为了让编排 Agent 在运行时可以使用这些规则，系统提供了一些工具函数：

• buildDelegationTable()：把所有 Agent 的 trigger 信息汇总成一张 Markdown 表，注入到编排器的系统提示中，让协同 Agent 对「谁擅长什么」有一张一目了然的导航图。
• buildKeyTriggersSection()：构建一个关键词到 Agent 的映射参考，方便通过模式匹配为任务选择候选 Agent。

换句话说，编排器在做决策时，有一个「知识库」：
——哪些场景适合哪个 Agent，上面已经通过配置提前写好了。

五、成本感知：在质量与账单之间求平衡

在实践中，很多系统刚上线的时候对模型成本没多大感觉，一旦接入真实用户、长会话、多轮协作以后，账单的增长速度就会开始提醒你：需要一个成本感知的委派策略。

5.1 AgentCost：谁可以被频繁调用？

前面提到，AgentCost 大致分为 CHEAP 和 EXPENSIVE（还有 FREE）。在 oh-my-claudecode 中，不同 Agent 被标记在不同的成本层级，下表是一个简化示意：

这套标记给了调度器两个能力：

• 在长会话中限制 EXPENSIVE Agent 的调用次数或总 Token。
• 在开关「成本敏感模式」时，优先使用 CHEAP 阵容处理更多任务，实在不行才升级。

5.2-low/-high模型变体：工程上非常好用的「档位开关」

为了在不修改 Agent 定义的情况下调节成本，系统引入了一个很工程化的小约定：
在 Agent 类型后加-low或-high后缀，代表显式降级或升级模型层级。

例如对 executor：

• 默认：executor→ sonnet
• 低成本版本：executor-low→ haiku
• 高质量版本：executor-high→ opus

类似的：architect 默认是 opus，architect-low则会被解析为 sonnet，用更便宜的模型来做架构分析。

这一逻辑由getModelForAgent()解析完成：例如getModelForAgent('executor-high')返回 opus。
好处是：

• 调度层可以根据上下文和预算，动态选择xxx-low还是xxx。
• 不需要复制一份 Agent 定义，也不需要在提示词里写“现在请你稍微笨一点”。

在你自己的系统中，也可以考虑用类似的命名约定，把「成本档位」做成在线可调的开关。

六、委派强制器：别再让模型选择变成「意外之喜」

很多基于 SDK 的 Agent 系统都有一个共同的坑：
如果你在调用 Task 时没显式指定 model，系统就会悄悄继承父 Agent 的模型。

看似方便，实际非常危险——你以为子 Agent 在用 haiku 快速扫一眼，结果它继承了父级的 opus，把一个小任务算成了大戏。

6.1 pre-tool-use Hook：模型注入的「中间检查站」

为了解决这个问题，oh-my-claudecode 在 Agent 调用前加了一个「委派强制器」作为 pre-tool-use hook：

大致流程是：

1. 拦截每一个 Task / Agent 工具调用。
2. 判断这次调用是不是针对一个 OMC 的 Agent（通过subagent_type字段）。
3. 如果调用里没有显式model字段：
   • 根据 Agent 的定义和前面提到的getModelForAgent()解析出应该用的模型（含-low/-high）。
   • 把model注入到这次调用的输入中。
4. 如果调用显式写了model，则原样保留，不做任何修改。

这个过程有几个关键点：

• 只对 OMC Agent 生效：通过isAgentCall()约束，只拦截带subagent_type的调用，不会污染其他工具生态。
• 显式优先于隐式：开发者手动指定的模型永远优先，强制器只给「没写」的人兜底。

6.2 实战意义：从「运气」变成「制度」

有了这个强制器，系统可以保证：

• executor 一定用它应该用的默认模型，除非明确要调档位。
• explore 这类高频调用 Agent，永远不会意外跑在 opus 上。
• 所有的模型路由行为是可推理、可追踪和可控的，而不是“这次怎么感觉它突然变聪明了”。

在自己的系统里，如果你也有很多子 Agent 调用，强烈建议做类似的「模型注入中间件」，不要完全依赖框架默认行为。

七、角色边界与「委派纪律」

再强的路由与成本控制，如果每个 Agent 都「没大没小」，整个系统迟早变成一锅粥。
oh-my-claudecode 通过角色边界和提示词纪律，给关键 Agent 画得很清楚。

7.1 关键角色边界示意

下表是几个核心 Agent 的职责边界（按含义重新整理）：

尤其是 executor，有一句非常关键的系统提示：
「Execute tasks directly. NEVER delegate or spawn other agents」——意思是你只负责干活，别再搞分包分包再分包。

architect 也一样，被明确为只读顾问：只分析、只建议，从不直接改代码。

7.2 为什么这些边界重要？

• 限制递归深度：禁止 executor 再委派，可以防止 agent 树无限扩张。
• 提升可解释性：当系统出了问题，你知道问题出在「分析」「规划」还是「执行」。
• 降低提示词耦合：每个 Agent 的提示可以围绕一个单一职责来设计，而不是“万能大助手”。

在你自己设计 Agent 时，可以参考这种方式，给每个角色写清楚「你做什么」「你绝对不做什么」，然后在编排层用规则保证这些边界被遵守。

八、什么时候该委派？什么时候直接做？

委派本身是有成本的：
创建子 Agent、装填上下文、做模型路由、合并结果，这些都要时间和 token。
所以并不是所有事情都值得走一遍完整流水线。

8.1 建议委派的场景

在以下情况，可以考虑交给专门的 Agent：

• 需要修改多个文件，甚至多个模块、多个语言。
• 需要做结构性重构，而不是简单补丁。
• 涉及复杂调试或根因定位，可能要多轮试验。
• 需要正式的代码审查、安全审查、性能审查。
• 需要完整的规划或研究，比如「把这个单体拆成微服务」。

这些事情的共同特点是：
——一次性思考成本高，而且错误代价大，值得为此付出额外的推理成本。

8.2 适合直接处理的场景

在下面这些小任务中，直接由当前编排层处理就足够了：

• 查一个文件的位置或简单搜索。
• 回答一段小范围的代码问题，比如「这个函数的返回值是什么」。
• 执行一条简单命令，比如跑一次已有的测试脚本。

在 oh-my-claudecode 里，这一逻辑被形式化进「触发器系统 + useWhen/avoidWhen」中，帮系统自己做「什么时候值得走流水线」的权衡。

你在自己的系统里，也可以把这套经验写成策略：

• 任务涉及多文件/多模块/架构层变化 → 走规划/审查流水线。
• 一次性小问题 → 直接在当前上下文里解决，不要动大炮。

九、运行时可配置：AgentOverrideConfig 的设计价值

在真实环境中，你很难一开始就把所有 Agent 的模型、温度、提示词调到最优。
oh-my-claudecode 提供了一套运行时覆盖机制，让系统可以在不改源码的情况下调优 Agent 行为。

9.1 可覆盖字段一览

通过AgentOverrideConfig，可以对任意 Agent 做以下覆盖：

• model：指定固定模型，比如把 architect 从 opus 换成 haiku，让它更快但稍微粗糙一点。
• enabled：直接禁用某个 Agent，例如临时下线 critic，减少审查环节。
• prompt_append：在系统提示后追加项目特定的指令或约束，比如「本项目所有日志必须使用统一格式」。
• temperature：单独调整某个 Agent 的创造性程度，比如让 writer 更有想象力，让 critic 更严谨。

mergeAgentConfig()会在启动时或运行时把这些覆盖合并到基础定义上，为系统运维与 A/B 实验提供空间。

9.2 实战建议

如果你也在维护一个多 Agent 系统，可以考虑：

• 为每个 Agent 预留一段「运营配置」，不要把所有行为写死在代码里。
• 把模型、温度、开关做成可配置项，通过环境变量或控制台实时调整。
• 给运营或平台团队一个面板，让他们可以按项目或按工作区覆盖不同 Agent 行为，而不必找你改代码、重新部署。

十、从设计到实践：如何把这套思路用在自己的系统里？

整套委托分类体系其实可以抽象为一个通用框架，你不一定要使用同样的命名，但可以借鉴以下做法：

1. 给所有 Agent 打上两类标签：功能类别 + 成本层级，统一收敛到一份配置里。
2. 基于业务流程设计「泳道」和「流水线」：明确你的系统从「问题输入」到「结果输出」要经过哪些角色。
3. 为每个 Agent 写清楚职责边界：包括「必须做」「可以做」和「绝对不做」。这些内容要落到提示词里，而不是写在 README 里给人看。
4. 用触发器表达委派规则：用结构化的triggers + useWhen + avoidWhen来替代 if-else，方便迭代和扩展。
5. 实现一个委派强制器中间件：在所有子 Agent 调用前检查并注入模型，避免隐式继承带来的成本黑洞。
6. 预留运行时覆盖能力：通过配置而不是改代码，去调试和运营你的 Agent 阵列，适应不同项目的需求。

如果你把这些元素组合起来，你会发现：
多 Agent 系统不再是一个「一堆提示词拼出来的黑盒」，而是一套有角色分工、有流程、有预算控制、有治理手段的工程系统。

在多模型、多 Agent 成为默认形态的今天，这样的「委托分类」体系会越来越重要。它不仅降低成本，更重要的是让系统的行为变得可设计、可预测、可演进。