Harness如何设计团队架构：Phase 2的3个关键子步骤详解-开发者社区

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 末尾的产出检查清单，确认"执行模式已明确、智能体不重复、每个调用都标注模型"等要点，再进入实现阶段。