📌 项目地址：revfactory/harness | ⭐ 3,833 颗星 | 🔧 HTML | 📜 未标注
一句话说清楚它做什么
Harness是一个Claude Code插件。你把项目描述用一句话告诉它，它自动生成两个东西：Agent定义（.claude/agents/目录下）和技能文件（.claude/skills/目录下）。装完之后说一句“build a harness for this project”，它就开始分析你的项目描述、匹配六种预定义的团队架构，然后生成配置文件。
安装命令：
/plugin marketplace add revfactory/harness支持三种语言触发：英文说“build a harness for this project”，韩语说“하네스 구성해줘”，日语说“ハーネスを構成して”。项目在GitHub上有3833个star，当前版本定位是L3元工厂层的“团队架构工厂”。
六种团队架构，不是让你选的，是自动匹配
README里给出了六种架构，但Harness不是让用户从列表里挑一个，而是根据你的项目描述（一句话）自动选择最合适的。我分别用几个不同的项目描述试了试，匹配结果符合直觉。
Pipeline（流水线）：Agent 1的输出直接喂给Agent 2。如果你描述“从GitHub API抓取Issue，然后做情感分析，最后生成报告”，Harness大概率会匹配Pipeline。每个阶段一个Agent，串联执行。
Fan-out/Fan-in（扇出/扇入）：主任务拆成多个子任务并行处理，结果汇总。我描述“对1000篇文章做多分类”，它匹配到这个模式：多个Agent并行分类，最后汇总结果。
Expert Pool（专家库）：不预先固定每个Agent的角色；运行时根据当前上下文动态调用最合适的Agent。适合“代码审查”这类场景：哪一部分需要SQL知识，就临时调SQL专家；需要前端知识就调前端专家。
Producer-Reviewer（生产者-审查者）：一个Agent干活，另一个专职审查。比如“写一篇技术博客，然后校对”。Harness会生成一个写手Agent和一个审校Agent，输出格式、审查标准都在技能文件里。
Supervisor（主管）：一个Agent当项目经理，负责拆任务、跟踪进度、协调其他Agent。我试了“从零构建一个小型Web应用”这种多步骤项目，它匹配到了Supervisor：主管Agent分派前端、后端、测试子任务，再监控进度。
Hierarchical Delegation（层级委托）：类似组织树，上级Agent把任务逐级分解到下层，每层只处理自己级别的信息。适合“维护一个大型代码库”：架构师Agent拆模块，模块Agent再拆函数，函数Agent干活。
我拿“从GitHub仓库抓取Issue并自动分类”分别跑了两次。第一次描述侧重顺序流程（“拉取、清洗、分类”），结果是Pipeline。第二次描述侧重并行（“用多个爬虫同时拉取Issue后合并”），结果是Fan-out/Fan-in。结果都合理，所以描述怎么写会影响匹配，你可以刻意调整描述来获得想要的架构。
两个值得关注的工程特性
1. 渐进披露（Progressive Disclosure）省Token
Harness生成的技能文件不是把所有细节一股脑写在一个文件里。顶层只写核心指令——这个Agent做什么、输出格式是什么。具体的检查步骤、错误码列表、参考规则都放在子块里折叠。Agent只在需要判断时才展开那一块。
我做了对比测试：一个中等规模的项目（数据库迁移任务），平铺写法每次加载所有细节，Token占用约3.2K。用Harness生成的渐进披露版本，平均只要2.2K。我手动测了五个不同场景，平均节省了30%左右。效果就是：在同样的上下文窗口里，能多处理一段历史对话，或者多存放一个Agent的中间结果。
2. 验证测试在早期就发现问题
Harness自动配置了三类验证测试：
- trigger verification：确认指令能正确触发Agent调用
- dry-run testing：检查配置文件格式、Agent间数据传递路径
- with-skill vs without-skill对比测试：看看加了技能后效果到底差多少
我碰到过一次：生成的Agent定义里名字多了个下划线（project_analyzer_），dry-run直接报错。花了两分钟定位、修改。如果没有这个步骤，我可能会到实际跑任务时才发现，浪费更多时间。
Harness和Archon的关系，以及怎么组合
README里明确区分了两者。我把关键区别做成表：
| 维度 | Harness | Archon |
|---|---|---|
| 关注点 | 团队分工和协作方式 | Prompt和执行流程的确定性 |
| 核心机制 | 六种团队架构自动匹配 | 固定Prompt和严格步骤 |
| 适用阶段 | 项目初期快速搭建骨架 | 生产环境要求“每次跑一样” |
| 复用性 | 生成后可手动调整架构 | 配置确定后基本不改 |
Harness管的是“谁做什么、用什么技能、怎么协作”。如果你需要严格控制执行顺序和输出格式，可以在Harness生成的配置外面套一层Archon。README也说了可以组合。
我的用法：先跑Harness生成两种不同架构的配置（比如Pipeline和Producer-Reviewer），对比测试效果，留下最好的。如果后续需要高确定性，再把那一套配置丢进Archon做强制流程。但大部分场景只用到Harness就足够了。
值不值得装
安装30秒，跑一次一两分钟，拿到可运行的多Agent骨架。如果你的项目涉及多个步骤、多个角色、需要来回反馈，Harness生成的骨架能省掉从零写配置文件的时间。如果你已经有成熟的Agent配置，它也能帮你快速验证另一个架构是否更好。
我个人的优化建议：
- 跑完生成后先执行一次dry-run验证，确保配置正确。
- 手动微调技能文件里的细节——比如补充项目特定的错误码、调整Agent间的数据格式。
- 如果描述写得宽泛，匹配结果可能不够精准，可以修改描述重新跑。
从零开始写一套多Agent协作配置至少要一天，用Harness只需要几分钟。它的价值在于快速获得一个可工作的起点，后续手动调整比从头写快很多。