Harness Expert Pool模式按场景调用专家Agent的完整教程【免费下载链接】harnessA meta-skill that designs domain-specific agent teams, defines specialized agents, and generates the skills they use.项目地址: https://gitcode.com/GitHub_Trending/harness/harness在多Agent协作里来一个任务就全员出动是最大的浪费。Harness Expert Pool模式专家池Expert Pool是开源元技能 Harness 内置的 6 种团队架构模式之一由一个路由器判断任务属于哪种场景再按需唤醒对应的专家 Agent不相关的专家全程不参与。本教程从安装、设计到落地一个代码审查专家团队带你完整走一遍 Expert Pool 的搭建过程无需任何代码基础。什么是Expert Pool只调用该叫的人Expert Pool 的结构非常简单[路由器/编排器] → { 专家A | 专家B | 专家C }路由器编排器接收任务先做分类再决定唤醒哪一位专家专家 Agent每个专家只负责一个领域如安全、性能、架构平时不运行结果汇总被唤醒的专家各自产出结果由编排器合并成一份报告与常驻团队不同Expert Pool 是按场景选择性调用输入类型不同处理路径就不同。官方对它的定位是——输入类型决定处理路径只调用需要的专家因此不需要常驻团队用轻量级的子 AgentSub-agent调用即可。模式详解见 agent-design-patterns.md。6种团队架构模式速览什么时候该选Expert PoolHarness 在设计团队架构时提供 6 种可选模式完整清单见 SKILL.md一张表帮你快速定位模式适用场景典型例子流水线 Pipeline前后步骤强依赖小说写作世界观→角色→情节→成稿扇出/扇入 Fan-out同一任务并行多路调研综合调研官方/媒体/社区同时查专家池 Expert Pool输入类型不同按需选专家代码审查安全/性能/架构按需唤醒生成-验证 Producer-Reviewer生成后必须质检漫画画师产出→审校退回重画监督者 Supervisor任务量不定动态分派大规模代码迁移层级委托 Hierarchical问题可逐层拆解全栈开发总负责人→前端组长→UI选型口诀2 个以上 Agent 且需要互相沟通 → 默认用 Agent 团队模式只需要调谁谁到、干完汇报→ 选 Expert Pool。官方决策树认为专家池场景下子 Agent 调用更合适因为不需要常驻团队。5分钟上手安装Harness并启用Agent Teams跟着 docs/quickstart.md 只需 4 步添加插件市场并安装在 Claude Code 中执行claude plugin marketplace add revfactory/harness再执行claude plugin install harnessharness启用实验开关export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS1多 Agent 协作依赖该开关原因见 docs/experimental-dependency.md一句话生成团队例如输入build a harness for comprehensive code reviewHarness 会自动生成 3~5 个专家 Agent 定义和技能文件验证产物确认.claude/agents/专家定义与.claude/skills/专家技能已生成核心设计路由的准头决定Expert Pool的成败官方给 Expert Pool 标注的注意点只有一条却至关重要路由器的分类准确度是核心。落地时抓好三点专家定义写成文件每位专家落在.claude/agents/{name}.md包含name、description角色说明触发关键词、核心角色、输入/输出协议、错误处理。写成文件才能在后续会话中复用这是 Harness 的硬性要求路由规则写进 description把什么场景唤醒哪位专家写进编排器的描述中例如涉及鉴权、注入、越权 → 安全专家涉及慢查询、索引 → 性能专家。Harness 对 description 的要求是主动式写法——写清楚触发场景而不是含糊的一句话专家数量克制参考 Harness 的组队指南5~10 个任务配 2~3 人见 SKILL.md专家池一般 3~5 位即可专家越多路由越容易误判实战演练代码审查只唤醒相关领域的专家以 Harness 官方示例场景为例README.md 提供了可直接复制的提示词用户提交审查数据库模块最近一周的改动路由器判断涉及 SQL 变更 → 唤醒性能专家安全专家架构专家这次不上岗专家以子 Agent 形式并行执行结果写入_workspace/目录命名遵循{阶段}_{专家}_{产物}.ext如01_analyst_requirements.md中间产物保留用于事后审计编排器读取各专家产物合并为一份统一报告本仓库的 _workspace/ 里就是真实的中间产物示范比如 01_auditor_repo_audit.md 就是一份审计阶段的专家产出。错误处理也有明确方针单专家失败重试一次仍失败则不带该结果继续并在报告中标注缺失冲突数据不删除、并记来源。编排器与Agent文件配套资料清单Expert Pool 的骨架由编排器Orchestrator串联仓库内提供全套配套参考编排器模板含错误处理与 Phase 设计orchestrator-template.md5 个真实团队配置示例team-examples.md技能编写规范description 怎么写才好触发skill-writing-guide.md技能测试方法含有技能 vs 无技能对比验证skill-testing-guide.md需要质检环节时再加一位 QA 专家qa-agent-guide.md成本与效率为什么Expert Pool是省Token之选⚡ 对比常驻团队Expert Pool 的成本优势来自三点只唤醒需要的专家未命中的专家零消耗而常驻 Agent 团队Token 成本高是其已知约束子 Agent 结果以摘要返回不会把大段中间过程塞进主上下文无需团队通信开销专家之间不互相发消息省掉协调成本但要记住另一面路由误判等于白烧调用所以 description 里的场景关键词要写具体并用 skill-testing-guide.md 中的应触发/不应触发用例做验证。常见问题Q1Expert Pool 和扇出/扇入有什么区别扇出是所有专家同时开工再汇总专家池是先分类只开需要的专家。任务边界明确时用专家池更省需要多视角交叉验证时用扇出。Q2一位专家可以兼任多个领域吗不建议。Harness 的原则是一个 Agent 专注一个角色角色叠加会导致复用率下降、路由混乱确实重叠时应拆分或合并并记录在 CLAUDE.md 的变更历史里。Q3团队建成后怎么维护Harness 把团队视为进化中的系统每次执行后收集反馈同类反馈出现 2 次以上就主动调整专家或路由规则并在 CLAUDE.md 变更历史表中留痕见 SKILL.md 的 Phase 7。总结✅ 用三句话回顾 Harness Expert Pool 模式一个路由器判断场景按需唤醒3~5 位专家 Agent成败关键在于description 里的路由关键词写具体、写主动产物落在.claude/agents/与.claude/skills/中间产物保留在_workspace/便于审计按本文 5 分钟上手章节装好 Harness再对照实战演练一节描述你的领域场景你就能拥有自己的按场景调用式专家团队。【免费下载链接】harnessA meta-skill that designs domain-specific agent teams, defines specialized agents, and generates the skills they use.项目地址: https://gitcode.com/GitHub_Trending/harness/harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Harness Expert Pool模式：按场景调用专家Agent的完整教程
Harness Expert Pool模式按场景调用专家Agent的完整教程【免费下载链接】harnessA meta-skill that designs domain-specific agent teams, defines specialized agents, and generates the skills they use.项目地址: https://gitcode.com/GitHub_Trending/harness/harness在多Agent协作里来一个任务就全员出动是最大的浪费。Harness Expert Pool模式专家池Expert Pool是开源元技能 Harness 内置的 6 种团队架构模式之一由一个路由器判断任务属于哪种场景再按需唤醒对应的专家 Agent不相关的专家全程不参与。本教程从安装、设计到落地一个代码审查专家团队带你完整走一遍 Expert Pool 的搭建过程无需任何代码基础。什么是Expert Pool只调用该叫的人Expert Pool 的结构非常简单[路由器/编排器] → { 专家A | 专家B | 专家C }路由器编排器接收任务先做分类再决定唤醒哪一位专家专家 Agent每个专家只负责一个领域如安全、性能、架构平时不运行结果汇总被唤醒的专家各自产出结果由编排器合并成一份报告与常驻团队不同Expert Pool 是按场景选择性调用输入类型不同处理路径就不同。官方对它的定位是——输入类型决定处理路径只调用需要的专家因此不需要常驻团队用轻量级的子 AgentSub-agent调用即可。模式详解见 agent-design-patterns.md。6种团队架构模式速览什么时候该选Expert PoolHarness 在设计团队架构时提供 6 种可选模式完整清单见 SKILL.md一张表帮你快速定位模式适用场景典型例子流水线 Pipeline前后步骤强依赖小说写作世界观→角色→情节→成稿扇出/扇入 Fan-out同一任务并行多路调研综合调研官方/媒体/社区同时查专家池 Expert Pool输入类型不同按需选专家代码审查安全/性能/架构按需唤醒生成-验证 Producer-Reviewer生成后必须质检漫画画师产出→审校退回重画监督者 Supervisor任务量不定动态分派大规模代码迁移层级委托 Hierarchical问题可逐层拆解全栈开发总负责人→前端组长→UI选型口诀2 个以上 Agent 且需要互相沟通 → 默认用 Agent 团队模式只需要调谁谁到、干完汇报→ 选 Expert Pool。官方决策树认为专家池场景下子 Agent 调用更合适因为不需要常驻团队。5分钟上手安装Harness并启用Agent Teams跟着 docs/quickstart.md 只需 4 步添加插件市场并安装在 Claude Code 中执行claude plugin marketplace add revfactory/harness再执行claude plugin install harnessharness启用实验开关export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS1多 Agent 协作依赖该开关原因见 docs/experimental-dependency.md一句话生成团队例如输入build a harness for comprehensive code reviewHarness 会自动生成 3~5 个专家 Agent 定义和技能文件验证产物确认.claude/agents/专家定义与.claude/skills/专家技能已生成核心设计路由的准头决定Expert Pool的成败官方给 Expert Pool 标注的注意点只有一条却至关重要路由器的分类准确度是核心。落地时抓好三点专家定义写成文件每位专家落在.claude/agents/{name}.md包含name、description角色说明触发关键词、核心角色、输入/输出协议、错误处理。写成文件才能在后续会话中复用这是 Harness 的硬性要求路由规则写进 description把什么场景唤醒哪位专家写进编排器的描述中例如涉及鉴权、注入、越权 → 安全专家涉及慢查询、索引 → 性能专家。Harness 对 description 的要求是主动式写法——写清楚触发场景而不是含糊的一句话专家数量克制参考 Harness 的组队指南5~10 个任务配 2~3 人见 SKILL.md专家池一般 3~5 位即可专家越多路由越容易误判实战演练代码审查只唤醒相关领域的专家以 Harness 官方示例场景为例README.md 提供了可直接复制的提示词用户提交审查数据库模块最近一周的改动路由器判断涉及 SQL 变更 → 唤醒性能专家安全专家架构专家这次不上岗专家以子 Agent 形式并行执行结果写入_workspace/目录命名遵循{阶段}_{专家}_{产物}.ext如01_analyst_requirements.md中间产物保留用于事后审计编排器读取各专家产物合并为一份统一报告本仓库的 _workspace/ 里就是真实的中间产物示范比如 01_auditor_repo_audit.md 就是一份审计阶段的专家产出。错误处理也有明确方针单专家失败重试一次仍失败则不带该结果继续并在报告中标注缺失冲突数据不删除、并记来源。编排器与Agent文件配套资料清单Expert Pool 的骨架由编排器Orchestrator串联仓库内提供全套配套参考编排器模板含错误处理与 Phase 设计orchestrator-template.md5 个真实团队配置示例team-examples.md技能编写规范description 怎么写才好触发skill-writing-guide.md技能测试方法含有技能 vs 无技能对比验证skill-testing-guide.md需要质检环节时再加一位 QA 专家qa-agent-guide.md成本与效率为什么Expert Pool是省Token之选⚡ 对比常驻团队Expert Pool 的成本优势来自三点只唤醒需要的专家未命中的专家零消耗而常驻 Agent 团队Token 成本高是其已知约束子 Agent 结果以摘要返回不会把大段中间过程塞进主上下文无需团队通信开销专家之间不互相发消息省掉协调成本但要记住另一面路由误判等于白烧调用所以 description 里的场景关键词要写具体并用 skill-testing-guide.md 中的应触发/不应触发用例做验证。常见问题Q1Expert Pool 和扇出/扇入有什么区别扇出是所有专家同时开工再汇总专家池是先分类只开需要的专家。任务边界明确时用专家池更省需要多视角交叉验证时用扇出。Q2一位专家可以兼任多个领域吗不建议。Harness 的原则是一个 Agent 专注一个角色角色叠加会导致复用率下降、路由混乱确实重叠时应拆分或合并并记录在 CLAUDE.md 的变更历史里。Q3团队建成后怎么维护Harness 把团队视为进化中的系统每次执行后收集反馈同类反馈出现 2 次以上就主动调整专家或路由规则并在 CLAUDE.md 变更历史表中留痕见 SKILL.md 的 Phase 7。总结✅ 用三句话回顾 Harness Expert Pool 模式一个路由器判断场景按需唤醒3~5 位专家 Agent成败关键在于description 里的路由关键词写具体、写主动产物落在.claude/agents/与.claude/skills/中间产物保留在_workspace/便于审计按本文 5 分钟上手章节装好 Harness再对照实战演练一节描述你的领域场景你就能拥有自己的按场景调用式专家团队。【免费下载链接】harnessA meta-skill that designs domain-specific agent teams, defines specialized agents, and generates the skills they use.项目地址: https://gitcode.com/GitHub_Trending/harness/harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考