Harness如何设计团队架构:Phase 2的3个关键子步骤详解
【免费下载链接】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
Harness 是一款面向 Claude Code 的智能体团队架构工厂(Team-Architecture Factory):你只需一句话描述业务领域,它就能自动设计出智能体团队并生成配套技能。而整个 6 阶段工作流中最核心、最考验设计功力的,正是Phase 2:团队架构设计——它决定了你的智能体团队"怎么协作、用什么阵型、拆成几个人"。
🧭 一分钟了解:Harness 的 6 阶段工作流
Harness 的主流程定义在 skills/harness/SKILL.md 中,完整工作流如下:
Phase 1: 领域分析 ↓ Phase 2: 团队架构设计(Agent Teams vs Subagents)← 本文重点 ↓ Phase 3: 智能体定义生成(.claude/agents/) ↓ Phase 4: 技能生成(.claude/skills/) ↓ Phase 5: 集成与编排 ↓ Phase 6: 验证与测试Phase 1 搞清楚"要做什么",Phase 3 及以后负责"落地实现",而 Phase 2 则回答最关键的架构问题:用团队还是子代理?选哪种协作阵型?每个智能体负责什么?这三个问题分别对应 Phase 2 的 3 个子步骤:
| 子步骤 | 解决的问题 | 详细出处 |
|---|---|---|
| 2-1 执行模式选择 | 团队、子代理还是混合? | SKILL.md#L46-L61 |
| 2-2 架构模式选择 | 6 种阵型选哪种? | SKILL.md#L63-L72 |
| 2-3 智能体分离标准 | 拆成几个智能体? | SKILL.md#L74-L76 |
⚙️ 子步骤2-1:如何快速选择执行模式(团队 vs 子代理)
这是新手最常纠结的一步。Harness 给出的原则很明确:智能体团队是默认首选。2 个及以上智能体需要协作时,优先使用团队模式,因为团队成员之间可以直接通信(SendMessage)、共享任务列表(TaskCreate),能互相分享发现、挑战结论、补全遗漏,从而显著提升产出质量。
三种模式怎么选?看这张决策表:
| 模式 | 什么时候用 | 特点 |
|---|---|---|
| 智能体团队(默认) | 2 人以上协作、需要实时调度和反馈交换、中间产出需要互相引用 | 用TeamCreate+SendMessage+TaskCreate自行协调 |
| 子代理(备选) | 单智能体任务、结果只需返回给主流程、团队通信开销过大 | 直接用Agent工具调用,可run_in_background并行 |
| 混合 | 不同阶段特性差异大,例如"并行收集(子代理)→ 协商式整合(团队)" | 按阶段混合团队/子代理,并在编排器中逐阶段注明 |
推荐的决策顺序(新手照做即可):
- 先问自己:"2 个以上智能体能用团队模式设计吗?"——能就选团队,这是默认值;
- 只有当智能体之间结构性地不需要通信(只传结果)、且团队开销大于收益时,才选择子代理;
- 各阶段特性明显不同时考虑混合模式,并记得在编排器里写明每个阶段用哪种模式。
完整的对比表和决策树可以参考 skills/harness/references/agent-design-patterns.md,其中的"模式选择决策树"用三问就能帮你定下模式。
🏗️ 子步骤2-2:6 大架构模式,哪种阵型最适合你的任务
定好执行模式后,第二件事是从 6 种预定义的团队架构模式(agent-design-patterns.md)中挑选最贴合任务特性的阵型:
| 架构模式 | 一句话理解 | 典型场景 | 新手避坑提示 |
|---|---|---|---|
| 流水线 Pipeline | 上一步的输出是下一步的输入 | 小说创作:世界观→角色→剧情→写作→编辑 | 瓶颈会拖慢整条线,尽量让环节独立 |
| 扇出/扇入 Fan-out/Fan-in | 并行处理后汇总 | 深度研究:多角度同时调查→合并报告 | 汇总阶段的质量决定整体质量 |
| 专家池 Expert Pool | 按情况选择性地调用专家 | 代码审查:只调安全/性能/架构中需要的专家 | 路由分类的准确性是核心 |
| 生产者-审查者 Producer-Reviewer | 生成后由审查者质检,不合格打回 | 内容创作→审校→返工 | 必须设最大重试次数(2~3 次),防止死循环 |
| 监督者 Supervisor | 中央智能体动态分派任务 | 大规模代码迁移:按文件清单动态派活 | 监督者别变成瓶颈,委派单元要足够大 |
| 层级委托 Hierarchical Delegation | 自上而下递归委派 | 全栈开发:总负责人→前端负责人→(UI/逻辑/测试) | 建议不超过 2 层,过深会损失上下文 |
💡两个实用技巧:
- 实际项目更常用"复合模式":例如"扇出 + 生产者-审查者"(4 种语言并行翻译→各自母语审校)、"流水线 + 扇出"(分析串行→实现并行→集成测试串行),可参考 复合模式对照表;
- 扇出/扇入模式建议必须用智能体团队:调查者之间实时分享发现、互相挑战,质量远高于各自为战。
✂️ 子步骤2-3:用 4 条标准决定"要不要拆分智能体"
阵型确定后,最后要回答:这个团队到底需要几个智能体?Harness 在 SKILL.md#L74-L76 中给出了 4 轴判断法,对照 分离标准表 逐项打分即可:
| 判断维度 | 倾向拆分 | 倾向合并 |
|---|---|---|
| 专业性 | 负责领域不同 | 领域高度重叠 |
| 并行性 | 可以独立并行执行 | 强顺序依赖 |
| 上下文 | 上下文负担很重 | 轻量快速 |
| 可复用性 | 其他团队也会用到 | 只在本团队使用 |
原则:一个智能体专注一个角色,复用性最高、重复最少。如果一个智能体身兼两职,先考虑能不能拆开。
举个例子:做"深度研究"团队时,"网络搜索"和"学术检索"领域不同、可并行、上下文各自独立——按 4 条标准都指向拆分;而"引用核对"只是报告撰写流程中的一小步、领域重叠——按标准应该合并进报告智能体。
🚀 Phase 2 完成之后:设计蓝图如何落地
Phase 2 的产出是一张"团队架构蓝图",它直接驱动后续阶段:
- Phase 3:按蓝图把每个智能体写成定义文件(agent-design-patterns.md 中的定义结构模板),包含核心角色、工作原则、输入/输出协议和团队通信协议;
- Phase 4:为每个智能体生成配套技能(SKILL.md + references/);
- Phase 5:用编排器把"谁在什么顺序上协作"串成完整工作流,模板见 orchestrator-template.md;
- Phase 6:验证团队规模、通信路径与触发条件是否符合预期。
📌 新手建议:设计完成后对照 SKILL.md 末尾的产出检查清单,确认"执行模式已明确、智能体不重复、每个调用都标注模型"等要点,再进入实现阶段。
📚 延伸阅读:核心文件速查
想动手体验或深挖细节,从这几份资料入手:
- 📖 skills/harness/SKILL.md:6 阶段主工作流的完整定义,Phase 2 三个子步骤的权威出处
- 📐 skills/harness/references/agent-design-patterns.md:执行模式对比、决策树、6 大架构模式与智能体分离标准
- 🌍 skills/harness/references/team-examples.md:5 个真实团队配置示例
- 🚀 docs/quickstart.md:5 分钟上手指南,从安装到跑通第一个团队
- 📝 README.md:项目总览、架构模式总表与使用场景提示词
掌握 Phase 2 的这 3 个子步骤——选对执行模式、挑对架构阵型、拆对智能体——你就掌握了 Harness 团队架构设计的核心方法论。下一篇文章,我们继续拆解 Phase 3 的智能体定义生成细节。
【免费下载链接】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),仅供参考