AI Agent 团队怎么设计？Harness 六种协作模式教程

搭 AI Agent 团队的时候，别急着先凑角色。先想清楚一个更关键的问题：这件事是要按顺序接力干、多线并行收信息、找专家拍板、来回审稿修改、有人统一调度，还是得拆成多层级来做？Harness 在 agent-design-patterns 里把常见的协作方式整理成了六种模式。

模式选择表

Pipeline：适合顺序清楚的任务

比如迁移旧模块的时候：先摸清楚接口情况，再写实现代码，接着补测试用例，最后更新文档。Pipeline 模式的好处是责任链条清清楚楚，坏处也很明显：前一步要是质量拉胯，后面所有 agent 都得受拖累。

设计的时候要给每一步定好退出标准。研究员要交什么材料，实现者要接什么文件，测试者要验证哪些行为，都得明明白白说清楚。

Fan-out/Fan-in：适合并行看问题

要是一个问题有好几条互不干扰的线索，用 Fan-out/Fan-in 模式就特别顺手。安全、性能、兼容性、用户体验这些方向可以同时分头分析，最后由整合的人把所有结论拼到一起。

这种模式更适合 Agent Teams，因为成员之间可能需要对齐结论。要避开的坑是：每个专家都写一大份长报告，最后没人拍板做取舍。

Expert Pool：适合问题不固定的项目

有些项目用不着每次都拉齐整个团队。比如偶尔查个数据库性能、偶尔过一遍文案、偶尔做次安全审计，这种情况用 Expert Pool 就合适——核心是根据具体输入挑对应的专家，不是所有人都凑上来。

这种模式很多时候用 subagent 会更轻量。只要不需要专家之间来回讨论，主对话调用一次专家就行。

Producer-Reviewer：适合质量敏感输出

像代码、文档、合规说明、教程这类内容，都适合让一个 agent 负责产出，另一个 agent 专门复核。注意这里的 reviewer 不能只是客气地点评两句，得真能指出漏洞、要求返工、重新验证才行。

要是只让 reviewer 说句“整体不错”，这个模式就等于白搭。复核的标准得提前写进 skill 或者 agent 的定义里。

Supervisor：适合任务会变化的现场

Supervisor 模式里，有个中心 agent 当调度员。它盯着整个任务列表、排好优先级，把不同的子任务分给合适的成员，最后再把结果收上来。

适合复杂修复、发布准备、资料整理这类过程没法完全预判的任务。但它也有代价：要是这个 supervisor 写得不好，反而会变成新的瓶颈。

Hierarchical Delegation：适合大问题，但要扁平化

层级委派听起来最像咱们平时见的公司组织架构，但 Claude Code 的 Agent Teams 不支持嵌套 team。Harness 文档里给的解决思路是要么做扁平化处理，要么让第一层的 team 搭配第二层的 subagents 来用。

实际做设计的时候，别总想着画复杂的层级图，先把每个环节的交付边界写清楚。团队结构叠得越深，就越要把中间产物放进 `_workspace/`，不然上下文很快就会失控。

最后的判断

能单个 agent 一次性搞定的事，就没必要组队；真的需要多方沟通、碰撞意见、反复复核的，再用 Agent Teams 也不迟。Harness 总结这六种模式，不是为了让你把团队越搞越大，而是帮你找到最合适的组织形式，去匹配对应的问题。