商业产业 Product Hunt 2026-08-06T07:56 正文 ok 439 words

HAR:面向多 Agent 编码工作流的开源运行框架

英文标题:HAR

HAR 是一个开源的 CLI 与 MCP 服务器,旨在为多 Agent 并行编码工作流提供隔离、验证和可观测性能力。它兼容 Claude Code、Cursor、Codex 及任何支持 MCP 的 Agent,并通过独立 git worktree、分支、端口和数据库避免多个 Agent 在同一仓库中相互冲突。HAR 还以确定性验证流水线、与代码绑定的验证结果及可审计日志和产物,降低人工复核 Agent 输出的负担。其核心配置以提交到仓库中的统一契约形式存在,避免 README、CLAUDE.md、编辑器规则和 CI 配置彼此漂移。
打开原文相关 6.3 · 机会 4
media2.0 KB media14.2 KB media8.6 KB media8.7 KB media9.5 KB media10.1 KB media781 B media932 B media603 B media1.1 KB media2.6 KB media2.1 KB media655 B media787 B

中文

嘿,PH!

我是 Antoine。过去一年里,当我尝试在公司扩展 Agent 编码工作流和软件工厂时,反复遇到同一组问题。因此,我构建了 HAR 来解决这些问题,并在今天将它开源。

让单个编码 Agent 在一个仓库中工作很容易。但要扩展到真正的多 Agent 工作流——多个运行实例同时执行,而且你依然能够信任输出——问题就开始显现了。以下几件事会同时出错:

  1. 没有标准方式来运行或验证一个仓库。相关知识分散在 README、CLAUDE.md、编辑器规则和 CI 配置中;它们彼此之间,以及与实际代码之间,都会逐渐失去同步。

  2. 同一仓库中的 Agent 会发生冲突。共享开发服务器、共享数据库、共享端口,以及相互冲突的 git 状态。

  3. 信任一次改动意味着你还得亲自重新验证它。这就违背了运行一支 Agent 集群的初衷。

  4. 厂商沙箱会造成锁定。如果配置存在于某个托管仪表盘中,之后想更换 Agent,就意味着必须从头重建整套配置。

HAR 的功能

HAR 是一个 CLI 和 MCP 服务器。它可与 Claude Code、Cursor、Codex 或任何 MCP Agent 协同工作,并弥补上述每一个缺口:

  1. 隔离。每个 Agent 都拥有自己的 git worktree、分支、端口和数据库。没有任何内容会与主检出目录或其他 Agent 的槽位共享,因此一支 Agent 集群可以并行运行,而不会在开发服务器、数据库或端口上发生冲突。

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

  3. 可验证的证据。每次运行都会留下日志、产物,以及与被检查的准确代码关联的已验证代码树哈希。审阅者检查这些证据,而不是相信 Agent 的自我报告。

  4. 全面可观测性。Mission Control 是一个本地仪表盘,可在一处展示每个仓库、worktree、运行任务和验证状态,让你能够观察整支 Agent 集群的工作过程。

所有这些内容都存在于一个提交到你的仓库中的统一契约里,每个 Agent 都会以相同方式读取它。它取代了常见但相互分散的 README、CLAUDE.md、编辑器规则和 CI 配置,避免它们逐渐偏离。你可以从符合自身技术栈的配置档案开始,由 Agent 将其适配到真实仓库;还可以通过插件(例如 Playwright)或任何已经在运行的命令来扩展验证能力。

欢迎试用,并告诉我你的想法 :)

我真诚地期待反馈,尤其是来自已经尝试并行运行多个 Agent 的朋友。

English / 原文

Hey PH!

I’m Antoine, and over the past year, as I tried to scale our agentic coding workflows and software factories at my company, I kept hitting the same set of problems. So I built HAR to solve them, and I'm open sourcing it today.

Getting a single coding agent to work in a repo is easy. Scaling to a real multi-agent workflow, where several runs at once and you still trust the output, is where it breaks down. A few things go wrong at the same time:

  1. No standard way to run or verify a repo. That knowledge is scattered across a README, a CLAUDE.md, editor rules, and CI config, all drifting out of sync with each other and the actual code.

  2. Agents on one repo collide. Shared dev server, shared database, shared ports, conflicting git state.

  3. Trusting a change means re-verifying it yoursel f. Which defeats the point of running a fleet.

  4. Vendor sandboxes lock you in. If the setup lives in someone's hosted dashboard, switching agents later means rebuilding the whole thing.

What HAR does

HAR is a CLI and an MCP server. It works with Claude Code, Cursor, Codex, or any MCP agent, and it closes each of those gaps:

  1. Isolation. Each agent gets its own git worktree, branch, ports, and database. Nothing is shared with the main checkout or another agent's slot, so a fleet runs in parallel without colliding on a dev server, DB, or ports.

  2. Deterministic validation gates. HAR runs your project's real checks through a fixed pipeline, same result every time. The result is bound to the exact code that passed and enforced at commit time, so an unverified tree cannot land.

  3. Verifiable proof. Every run leaves logs, artifacts, and a validated tree hash tied to the exact code checked. A reviewer inspects the evidence instead of trusting the agent's self-report.

  4. Full observability. Mission Control is a local dashboard showing every repo, worktree, run, and validation in one place, so you can watch a whole fleet as it works.

All of this lives in one contract committed to your repo, which every agent reads the same way. It replaces the usual scatter of a README, a CLAUDE.md, editor rules, and CI config that drift apart. You start from a profile that matches your stack, your agent adapts it to the real repo, and you extend verification with plugins (like Playwright) or with any command you already run.

Give it a try and let me know what you think :)

I'd genuinely love feedback, especially from anyone already trying to run multiple agents in parallel.