HAR

嗨，PH！

我是 Antoine，过去一年里，我在公司尝试扩展我们的智能体编码工作流和软件工厂时，反复遇到同一系列问题。因此我构建了 HAR 来解决这些问题，今天我将它开源。

让单个编码智能体在一个代码仓库中工作很容易。但要扩展到真正的多智能体工作流——多个任务同时运行，而你仍然信任输出结果——才是容易出问题的地方。几个问题会同时出现：

• 没有运行或验证代码仓库的标准方式。相关知识分散在 README、CLAUDE.md、编辑器规则和 CI 配置中，所有这些都相互之间以及与实际代码逐渐失去同步。

• 同一代码仓库上的智能体会相互冲突。共享的开发服务器、共享的数据库、共享的端口、冲突的 git 状态。

• 信任一次变更意味着要自己重新验证它。这违背了运行智能体集群的意义。

• 供应商的沙箱会锁定你。如果设置存在于某个托管的仪表板中，以后切换智能体就意味着重建所有东西。

HAR 的功能

HAR 是一个 CLI 和 MCP 服务器。它可以与 Claude Code、Cursor、Codex 或任何 MCP 智能体协同工作，并弥补上述每一个缺陷：

• 隔离性。每个智能体都拥有自己的 git worktree、分支、端口和数据库。与主检出或其他智能体的槽位之间没有任何共享，因此智能体集群可以并行运行而不会在开发服务器、数据库或端口上发生冲突。

• 确定性验证关卡。HAR 通过固定的流水线运行项目的真实检查，每次结果都相同。结果与通过验证的确切代码绑定，并在提交时强制执行，因此未经验证的代码树无法合入。

• 可验证的证据。每次运行都会留下日志、产物和与所检查的确切代码绑定的已验证代码树哈希。审查者检查证据，而不是相信智能体的自报结果。

• 完整的可观测性。Mission Control 是一个本地仪表板，在一个界面中显示每个代码仓库、worktree、运行和验证，因此你可以观察整个智能体集群的工作过程。

所有这些都集中在一个提交到代码仓库的契约中，每个智能体都以相同的方式读取。它取代了通常分散的、容易逐渐脱节的 README、CLAUDE.md、编辑器规则和 CI 配置。你从与你的技术栈匹配的配置文件开始，智能体会将其适配到真实的代码仓库，然后你可以通过插件（如 Playwright）或任何你已经在运行的命令来扩展验证。

试试看，告诉我你的想法 :)

我真诚地希望得到反馈，特别是来自那些已经在尝试并行运行多个智能体的人的反馈。