HAR

一句话定位

给"多个编码 agent 同时在一个仓库干活"用的开源框架：每个 agent 独立工作区、确定性验证闸门、可核验证据，替代散落在各处的 README、CLAUDE.md、CI 配置。

做这个东西的人

Antoine Frau（在自家公司规模化 agentic coding 工作流一年，踩坑后开源自建方案）和 Karim Traiaia，团队是 os-factory。它既是一个 npm 包（CLI + MCP server），也提供 Mission Control 本地看板。

判断：作者是从真实生产场景里被"多 agent 并发不可信"逼出来的，问题清单（没有统一验证标准、agent 互相冲突、不信任就要自己复核、平台锁定）每一条都具体。

它到底能做哪几件事

• 单一仓库契约 → 用仓库里一个 .har/ 机器可读契约，替换 README、CLAUDE.md、Cursor rules、CI 配置的"四处漂移"状态；Claude Code、Cursor、Codex、任意 MCP agent 读到的是同一份
• 隔离 → 每个任务一个 git worktree，加独立分支、端口、数据库；不碰主检出，也不碰别的 agent 的槽位
• 确定性验证闸门 → 用项目真实的检查跑固定流水线，结果绑定到通过检查的那份精确代码，未验证的树不能落地
• 可核验证据 → 每次运行留下日志、产物、验证过的树哈希，审查者检查证据而不是相信 agent 自述
• Mission Control → 本地看板，一个页面看所有仓库、工作区、运行、验证
• 漂移检测 → har env maintain 对比模板与当前配置，在漂移造成静默失败前报警
• 插件 → Playwright 等验证插件，或任何你已有的命令

它在替代什么旧行为

多 agent 并发编程以前长这样：每个 agent 各自起 dev server（撞端口、撞数据库）、验证方式靠"它自己说测过了"、你切换平台（比如从 Claude Code 换到 Cursor）要重建整套验证环境。

HAR 把三件事标准化了："这个仓库怎么跑、怎么验证"从分散文档变成一份契约；并发运行从互相踩踏变成隔离槽位；信任从 agent 自述变成可复核证据。 它替代的不是某个工具，而是"多 agent 协作里人肉调度那一段"。

商业模式

未披露。 开源，核心 CLI/MCP 免费。os-factory 是公司实体，大概率靠托管版或企业支持变现，但当前没有任何收费信息。

判断：这个品类（agent harness/编排）正在快速变热——就在它发布的同一周，DeepSeek 也开源了 Harness v0.1（MIT，"一切皆插件"，Model+Harness=Agent，由崔添翼带队）。两者不是一回事：HAR 管的是"编码 agent 的并发与验证"，DeepSeek Harness 是"agent 运行时的插件化底座"。但名字撞了，且都在抢"harness"这个心智。

硬数字

• GitHub（os-factory/har）：65 star / 8 fork，2026-06-28 建
• PH 页面：1 条 5.0 分评论
• npm 包：@osfactory/har，npm install -g 安装
• 团队规模：两人项目（据 PH 互动）
• 用户数、ARR：未披露

四维评估

判断

它抓的是多 agent 时代最贵的那个问题：信任。 单 agent 出错你能自己看；一个 fleet 同时跑，你不可能逐个复核，只能相信证据系统。HAR 的"确定性验证 + 树哈希 + 证据链"是把软件工程的"可复现构建"哲学搬到 agent 编排上，这个方向是对的。

它最大的风险不是做不好，是赛道被碾过。 就在它发布的同周，DeepSeek Harness v0.1 开源并自带团队运营；加上 Claude Code 本身的 hooks/subagents、各家 agent 平台都在做编排层，"harness"正在变成一个拥挤的词。HAR 的护城河是"agent-agnostic + 仓库内契约"——如果你的验证基础设施活在某个厂商的云端，切换就是重建；HAR 把契约放在仓库里，这一点是它对抗平台锁定和平台吞噬的唯一论据。

它现在缺的是真实采用证据：65 star、1 条评论，还没有公开的"某公司用它在跑真实 fleet"的案例。工具的合理性它已经讲清了，接下来要证明的是有人用它扛过真项目。

下一步看什么

① star 三个月内能否过 500，以及是否出现企业公开采用案例 ② 在 DeepSeek Harness 等大厂方案铺开后，它是否仍被讨论，还是被挤出心智 ③ Mission Control 和插件的活跃度，是否有人在为它写第三方插件

可借鉴的做法

产品逻辑：设计 agent 编排或自动化时，"信任机制"要作为第一等公民：验证结果必须绑定到精确的输入（代码、数据）哈希，而不是 agent 的自我报告。这条原则可以平移到任何"让 AI 自主干活但人类要担责"的场景。

工程实践：用"仓库内契约"对抗平台锁定——把配置、验证、标准放进代码库本身，而不是放进某个厂商的仪表盘。这既是技术选择，也是商业护城河。

结论

值得关注，但有待观察。 问题选得准、方向正确、时机绝佳，但采用证据为零，且赛道正在被大厂涌入。它赢的机会在于"仓库内契约 + 厂商无关"这个没有被大厂占住的位置。三个月后拿上面三条验证。