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 是按场景选择性调用：输入类型不同，处理路径就不同。官方对它的定位是——"输入类型决定处理路径，只调用需要的专家"，因此不需要常驻团队，用轻量级的子 Agent（Sub-agent）调用即可。模式详解见 agent-design-patterns.md。

6种团队架构模式速览：什么时候该选Expert Pool

Harness 在设计团队架构时提供 6 种可选模式（完整清单见 SKILL.md），一张表帮你快速定位：

🎯选型口诀：2 个以上 Agent 且需要互相沟通 → 默认用 Agent 团队模式；只需要"调谁谁到、干完汇报"→ 选 Expert Pool。官方决策树认为：专家池场景下子 Agent 调用更合适，因为"不需要常驻团队"。

5分钟上手：安装Harness并启用Agent Teams

跟着 docs/quickstart.md 只需 4 步：

1. 添加插件市场并安装：在 Claude Code 中执行claude plugin marketplace add revfactory/harness，再执行claude plugin install harness@harness
2. 启用实验开关：export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1（多 Agent 协作依赖该开关，原因见 docs/experimental-dependency.md）
3. 一句话生成团队：例如输入build a harness for comprehensive code review，Harness 会自动生成 3~5 个专家 Agent 定义和技能文件
4. 验证产物：确认.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 提供了可直接复制的提示词）：

1. 用户提交"审查数据库模块最近一周的改动"
2. 路由器判断：涉及 SQL 变更 → 唤醒性能专家+安全专家，架构专家这次不上岗
3. 专家以子 Agent 形式并行执行，结果写入_workspace/目录，命名遵循{阶段}_{专家}_{产物}.ext（如01_analyst_requirements.md），中间产物保留用于事后审计
4. 编排器读取各专家产物，合并为一份统一报告

本仓库的 _workspace/ 里就是真实的中间产物示范，比如 01_auditor_repo_audit.md 就是一份审计阶段的专家产出。错误处理也有明确方针：单专家失败重试一次，仍失败则不带该结果继续，并在报告中标注缺失；冲突数据不删除、并记来源。

编排器与Agent文件：配套资料清单

Expert Pool 的骨架由编排器（Orchestrator）串联，仓库内提供全套配套参考：

• 编排器模板（含错误处理与 Phase 设计）：orchestrator-template.md
• 5 个真实团队配置示例：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 中的"应触发/不应触发"用例做验证。

常见问题

Q1：Expert Pool 和"扇出/扇入"有什么区别？扇出是"所有专家同时开工再汇总"；专家池是"先分类，只开需要的专家"。任务边界明确时用专家池更省，需要多视角交叉验证时用扇出。

Q2：一位专家可以兼任多个领域吗？不建议。Harness 的原则是"一个 Agent 专注一个角色"，角色叠加会导致复用率下降、路由混乱；确实重叠时应拆分或合并，并记录在 CLAUDE.md 的变更历史里。

Q3：团队建成后怎么维护？Harness 把团队视为"进化中的系统"：每次执行后收集反馈，同类反馈出现 2 次以上就主动调整专家或路由规则，并在 CLAUDE.md 变更历史表中留痕（见 SKILL.md 的 Phase 7）。

总结

✅ 用三句话回顾 Harness Expert Pool 模式：

1. 一个路由器判断场景，按需唤醒3~5 位专家 Agent
2. 成败关键在于description 里的路由关键词写具体、写主动
3. 产物落在.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