当 AI 编程任务逐渐变得复杂，单人通用助手往往被迫同时扮演产品分析师、架构师、实现者、测试工程师、审查者以及文档作者等多重角色。在短期简单任务中这种模式尚可应对，但一旦任务跨越模块、涉及多个领域并需要持续多轮沟通，单一 Agent 的上下文窗口和判断力就会明显不足。revfactory/harness 的解决思路相当直接：不要试图让一个 Agent 包揽全部工作，而是先为项目设计一支领域化的 Agent 团队。
它将自己定位成 Claude Code 的“团队架构工厂”。你只需描述项目所在的领域，或者表达诸如 “build a harness for this project” 这样的意图，它就能自动生成适合该项目的 agents 和 skills，并从预设的架构模式中挑选出最匹配的团队组织方式。换句话说，Harness 并非直接帮你编写某个功能代码，而是帮你搭建一支“更适合完成这个项目的 AI 团队”。
它为什么不是普通插件
普通 AI 编程插件通常只提供一组固定的命令：写代码、查 bug、做 review、生成测试等等。Harness 的抽象层级更高——它试图根据你的项目类型生成一套完整的团队结构，然后将团队成员及其技能写入 .claude/agents/ 和 .claude/skills/ 目录。简单来说，它不是一个具体的技能，而是“生成技能以及装技能的容器”。
README 将其放在 L3 Meta-Factory 层，虽然表述有些抽象，但核心意图很实在：L1 可能是具体工具，L2 是跨工具流程，而 L3 则是生成流程和团队架构的系统。Harness 关注的重点是“如何为某个领域构造 Agent 团队”，而非“如何解决某一个固定任务”。
六种团队架构模式
那么，具体有哪些团队模式可供选择？项目提到了六种预设架构，深入理解它们才能真正看懂 Harness。
Pipeline 适用于顺序明确的任务，好比一条流水线：需求分析 → 设计 → 实现 → 测试 → 文档，每个阶段清晰，输出逐步传递。
Fan-out/Fan-in 适用于并行探索场景，让多个 Agent 各自研究不同方案，最后汇总择优，能有效避免单一思维路径。
Expert Pool 适用于领域复杂的项目，比如金融系统需要安全、数据、后端、合规、前端等不同领域的专家协同工作。
Producer-Reviewer 适用于强调质量的任务，一个 Agent 负责产出，另一个 Agent 负责审查，从而减少自我确认偏差。
Supervisor 适用于需要统一协调的任务，监督者负责拆解任务、分配工作、检查进度以及处理异常情况。
Hierarchical Delegation 则更适合大规模任务，将复杂目标逐级拆解成子任务，让不同层级的 Agent 承担不同粒度的判断责任。
工作流：从领域描述到团队落地
工作流程大致分为六个阶段，每个阶段都有明确的用意。
第一阶段：领域分析。系统需要摸清项目背景、任务复杂程度、常见风险点以及需要哪些专业角色。
第二阶段：团队架构设计。它会判断该采用何种团队模式，或者如何组合多种模式。例如，前端重构任务可能更适合 Producer-Reviewer，而研究型任务则可能更匹配 Fan-out/Fan-in。
第三阶段：生成 Agent 定义。将“安全审查者”“后端实现者”“测试策略师”等角色转化为 Claude Code 可识别的 agent 文件。
第四阶段：生成 Skills。只有角色还不够，Agent 还需明确何时触发、如何工作、读取哪些上下文以及输出什么格式。
第五阶段：编排。多个 Agent 之间要能够传递数据、处理错误、合并结果，否则团队只会是一堆孤立角色。
第六阶段：验证。项目强调要进行 dry-run、触发验证，以及 with-skill 与 without-skill 的对比测试。这一步相当关键，因为生成的团队必须证明自己确实比默认方式表现更优。
适合的使用场景
Harness 适用于任务复杂、角色分工自然存在的项目，例如：
- 大型代码库重构。
- 多模块产品开发。
- 安全审计与修复计划。
- 数据平台或后端系统设计。
- 游戏、前端、移动端等需要多角色协作的项目。
- 需要将团队经验沉淀为 Claude Code agents 和 skills 的长期项目。
如果你的团队已经习惯反复对 AI 说“先让架构师看一下，再让实现者写，再让 reviewer 检查”，那么 Harness 的概念就非常自然——它正是要把这种分工固化下来。
不适合的场景
如果只是修改一个小 bug、编写一个简单脚本、或者补一段文案，那么 Harness 可能显得过于笨重。因为团队架构本身是有成本的：需要生成、理解、维护，还要确保触发正确。
另外，它明显围绕 Claude Code 生态设计。如果你的主要工作环境不是它，就需要先评估兼容性，或者寻找类似概念的移植方案。README 中也提到了它与 Archon、ECC、meta-harness 等邻近项目的关系，这说明它处于一个快速演进的 AI 编程工具生态之中。
安装与使用路线
README 提供了市场（marketplace）安装方式，也支持直接作为全局 skill 安装。最佳上手方式不是直接扔进生产项目，而是找一个中等复杂度的试验项目运行一次，让它生成 agents 和 skills，然后仔细审查输出内容。
建议上手步骤：
- 选择一个你熟悉的小型或中型项目。
- 运行 Harness 生成团队。
- 查看生成的
.claude/agents/和.claude/skills/目录。 - 让默认的 Claude Code 与 Harness 团队分别处理同类任务。
- 比较任务分解、输出质量、审查深度以及上下文使用情况。
如果生成结果过于复杂，就收窄团队；如果角色过于泛化，就补充领域描述；如果触发不稳定，就调整 skill 描述。
二次开发可以看哪里
仓库本身不大，README、docs/quickstart.md、docs/experimental-dependency.md 是理解项目的入口。真正值得研究的是它生成的 agent 和 skill 结构，以及六种架构模式如何映射到不同任务。
如果你想把这个思路迁移到其他 AI 编程环境，重点不是复制文件，而是复制方法论：领域分析、团队模式选择、角色定义、技能生成、编排协议、验证对比。
读完后的判断
Harness 代表了 AI 编程的一个明显趋势：从“一个大模型助手”走向“可配置的 AI 工程组织”。任务简单时，单个助手最快；任务复杂时，结构本身就是一种能力。Harness 值得仔细阅读，正因为它将这种结构显式化了。
来源
- 仓库：github.com/revfactory/…
