文章目录Pre概述一、问题背景为什么需要「委托分类」二、两个核心轴功能类别与成本层级2.1 功能类别Agent 在团队中的职能2.2 成本层级给调度器的预算信号三、从架构泳道看多 Agent 协作「流水线」3.1 典型流水线从探索到验证3.2 领域 Agent按需并入流程四、触发器与路由Agent 不是随便上的4.1 Agent 触发器triggers useWhen avoidWhen4.2 自动构建「委派参考表」五、成本感知在质量与账单之间求平衡5.1 AgentCost谁可以被频繁调用5.2 -low / -high 模型变体工程上非常好用的「档位开关」六、委派强制器别再让模型选择变成「意外之喜」6.1 pre-tool-use Hook模型注入的「中间检查站」6.2 实战意义从「运气」变成「制度」七、角色边界与「委派纪律」7.1 关键角色边界示意7.2 为什么这些边界重要八、什么时候该委派什么时候直接做8.1 建议委派的场景8.2 适合直接处理的场景九、运行时可配置AgentOverrideConfig 的设计价值9.1 可覆盖字段一览9.2 实战建议十、从设计到实践如何把这套思路用在自己的系统里PreOMC - 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 从单人到多 AgentOh-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 的委托分类体系核心就是把这些“玄学路由”和“隐性约定”全部显性化用类型系统和中间件来约束。它围绕三个关键问题展开设计角色划分一个 Agent 在系统中的工作本质是什么预算控制调用它贵不贵可以被调用多少次路由规则在什么场景下应该把任务交给它在哪些情况下必须避开它接下来我们从这三个维度往下拆。二、两个核心轴功能类别与成本层级在 oh-my-claudecode 中每个 Agent 都有两条「标签」功能类别AgentCategory和成本层级AgentCost。2.1 功能类别Agent 在团队中的职能功能类别定义了 Agent 在「开发生命周期」中的角色而不是技术实现细节。 简化后你可以理解为下面这张表类别核心作用默认模型典型 Agent设计感受exploration代码搜索、结构摸底haikuexplore快速扫街specialist具体实现、专精执行sonnetexecutor、designer 等干活的人advisor只读咨询、架构分析opusarchitect首席顾问utility通用写作、轻量辅助haikuwriter打下手的orchestration协调多 Agent、驱动流水线sonnet编排器类 Agent调度中心planner战略规划、任务拆解opusplanner、analyst项目经理reviewer质量关卡、审查与验证opuscritic、code-reviewer 等质检员这种划分有两个好处一眼看出「这是一个什么性格的 Agent」是负责造轮子的还是负责挑毛病的。方便在路由和提示词中做统一约束比如所有 reviewer 都明确「不写代码只看问题」。2.2 成本层级给调度器的预算信号第二个轴是成本层级AgentCost本质上是给编排器看的预算提示FREE几乎不计成本的调用通常是内置逻辑或者非 LLM 部分CHEAP低成本、高吞吐量的 Agent适合高频调用EXPENSIVE推理质量高但昂贵的 Agent适合关键决策节点系统中会根据这个层级配合模型层级haiku / sonnet / opus来做默认路由例如 CHEAP 多半对应 haiku 或 sonnetEXPENSIVE 则往 opus 靠。这里有一个非常实用的设计成本层级是“信号”不是绑定。比如 executor 既是 specialist又标记为 CHEAP但它默认模型选择的是 sonnet——说明在当前系统里sonnet 也被视作可接受的低成本选项。三、从架构泳道看多 Agent 协作「流水线」功能类别是「纵向」的角色标签而在架构层面oh-my-claudecode 还把 Agent 按照开发流程分成了四条「泳道」Coordination Lane负责整体协调和编排比如 criticReview Lane负责各种形式的审查与质量关卡Build/Analysis Lane负责具体实现和分析explore、analyst、planner、executor 等Domain Lane负责特定领域的专家能力比如 designer、security-reviewer、test-engineer 等3.1 典型流水线从探索到验证在这一架构下一个典型的端到端 Agent 工作流大致是explore → analyst → planner → critic → executor → verifier拆开看一下每个环节的职责explore在代码库和项目结构中摸底找到相关文件、模块和调用关系。analyst在执行前做「问题分析」补齐隐形需求、边界条件和风险点。planner根据分析结果拆分任务形成可执行计划与步骤列表。critic站在质量视角审查计划——是否漏情况、是否有明显坑。executor按计划逐步改代码、写测试、跑命令真正「动手」。verifier验证变更结果比如跑测试、检查 diff 合理性。这一条流水线的好处在于每个环节只做一个类型的决策或动作。如果你自己要设计多 Agent 系统可以直接沿用这条主干再根据业务加减领域 Agent。3.2 领域 Agent按需并入流程当任务涉及特定领域时流程会「支路」调用相应专家 AgentUI 或交互相关叫上 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说明。举几个代表性的例子非原文照搬按含义重新整理Agent领域触发条件示例备注explore代码库搜索查找实现、模式、文件位置优先用于「找东西」executor直接实现单文件范围、需求明确的改动不做规划与委派architect架构决策/调试跨系统权衡、多次失败的疑难 Bug高成本顾问planner任务规划大型变更、跨模块重构、长任务生成计划analyst需求与风险分析问题背景不清晰、有明显隐性约束计划前分析critic计划审查在执行前对计划质量进行评估质量关卡在此基础上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 被标记在不同的成本层级下表是一个简化示意成本层级含义典型模型Agent 示例CHEAP低成本、高调用频率haiku / sonnetexplore、executor、designer、writer 等EXPENSIVE高质量推理、慎重调用opusarchitect、planner、analyst、critic 等这套标记给了调度器两个能力在长会话中限制 EXPENSIVE Agent 的调用次数或总 Token。在开关「成本敏感模式」时优先使用 CHEAP 阵容处理更多任务实在不行才升级。5.2-low/-high模型变体工程上非常好用的「档位开关」为了在不修改 Agent 定义的情况下调节成本系统引入了一个很工程化的小约定在 Agent 类型后加-low或-high后缀代表显式降级或升级模型层级。例如对 executor默认executor→ sonnet低成本版本executor-low→ haiku高质量版本executor-high→ opus类似的architect 默认是 opusarchitect-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大致流程是拦截每一个 Task / Agent 工具调用。判断这次调用是不是针对一个 OMC 的 Agent通过subagent_type字段。如果调用里没有显式model字段根据 Agent 的定义和前面提到的getModelForAgent()解析出应该用的模型含-low/-high。把model注入到这次调用的输入中。如果调用显式写了model则原样保留不做任何修改。这个过程有几个关键点只对 OMC Agent 生效通过isAgentCall()约束只拦截带subagent_type的调用不会污染其他工具生态。显式优先于隐式开发者手动指定的模型永远优先强制器只给「没写」的人兜底。6.2 实战意义从「运气」变成「制度」有了这个强制器系统可以保证executor 一定用它应该用的默认模型除非明确要调档位。explore 这类高频调用 Agent永远不会意外跑在 opus 上。所有的模型路由行为是可推理、可追踪和可控的而不是“这次怎么感觉它突然变聪明了”。在自己的系统里如果你也有很多子 Agent 调用强烈建议做类似的「模型注入中间件」不要完全依赖框架默认行为。七、角色边界与「委派纪律」再强的路由与成本控制如果每个 Agent 都「没大没小」整个系统迟早变成一锅粥。oh-my-claudecode 通过角色边界和提示词纪律给关键 Agent 画得很清楚。7.1 关键角色边界示意下表是几个核心 Agent 的职责边界按含义重新整理Agent类别负责做什么明确不做什么architectadvisor代码分析、架构决策、调试建议不做需求收集、不做任务规划analystplanner发现需求缺口、风险与边界不直接分析代码、不做详细规划plannerplanner生成任务计划和执行步骤不做需求分析、不审查自己的计划criticreviewer审查计划质量、挑问题不做需求与代码分析executorspecialist按计划直接实现和改代码不再委派、不生成子 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 行为而不必找你改代码、重新部署。十、从设计到实践如何把这套思路用在自己的系统里整套委托分类体系其实可以抽象为一个通用框架你不一定要使用同样的命名但可以借鉴以下做法给所有 Agent 打上两类标签功能类别 成本层级统一收敛到一份配置里。基于业务流程设计「泳道」和「流水线」明确你的系统从「问题输入」到「结果输出」要经过哪些角色。为每个 Agent 写清楚职责边界包括「必须做」「可以做」和「绝对不做」。这些内容要落到提示词里而不是写在 README 里给人看。用触发器表达委派规则用结构化的triggers useWhen avoidWhen来替代 if-else方便迭代和扩展。实现一个委派强制器中间件在所有子 Agent 调用前检查并注入模型避免隐式继承带来的成本黑洞。预留运行时覆盖能力通过配置而不是改代码去调试和运营你的 Agent 阵列适应不同项目的需求。如果你把这些元素组合起来你会发现多 Agent 系统不再是一个「一堆提示词拼出来的黑盒」而是一套有角色分工、有流程、有预算控制、有治理手段的工程系统。在多模型、多 Agent 成为默认形态的今天这样的「委托分类」体系会越来越重要。它不仅降低成本更重要的是让系统的行为变得可设计、可预测、可演进。