面向 Agent-人类协作的 Git Forge（11 分钟阅读）

# 面向 Agent 与人类协作的 Git Forge 来源：https://entire.com/blog/the-git-forge-for-agent-human-collaboration Entire 联合创始人兼 CEO Thomas Dohmke 经过一年多的潜心打磨，我们很高兴地推出首个专为 agent 与人类协作而构建的 Git forge。Entire 基于三大原语构建： 1. **Trail（轨迹）**。不同于传统的 pull request 模型——使用 diff 来审查代码变更，Trail 为开发者提供类似航空飞行员平视显示器的界面，每次代码推送都会触发可自定义的自动化 eval，并由 agent 进行评分。 2. **分布式 Git 托管**。Entire 构建在一个全新的、兼容 Git 的源代码管理服务器之上，推送速度比 GitHub 快高达 89 倍，比 Cursor Origin 快 6 倍。你可以托管自己的仓库，并将其复制到全球多个区域，为 agent 流量提供数据驻留和扩展能力。 3. **持续记忆（Continuous Memory）**，这是一种面向 agent 和开发团队的新方法，将会话和提示词同步到 Git 仓库中，并让这些数据随时可供编码 agent 访问和检索。 此外，我们正在构建一个开放的生态系统，让开发者可以选择最适合当前任务的工具。目前，我们正在与 Buildkite 和 Depot 合作提供持续集成（CI），确保你的构建和测试流水线能够跟上 agent 的交付速度。 Entire 今天起对所有开发者开放，并针对 AI 原生团队及其 agent 进行了专门优化。让我们一起进入这个新的多元宇宙。 ## 使用 Trails 进行审查 在 pull request（PR）中，开发者按时间顺序线性地发布评论，持续集成（CI）在底部显示状态，然后是合并按钮。如今，编码和代码审查在这个时间线上不断刷屏，充斥着冗长的描述。开发者要求自己的编码 agent 处理代码审查 agent 的反馈，然后再进行一轮审查。Pull request 已经变成了一个只有 agent 才会阅读的审计日志，无法为开发者提供足够信息来判断是否可以放心合并。 Trail 改变了这一切。它将相关信息——以 eval 评分的形式——提升到页面顶部，每次推送都会重新计算。目标很简单：为你提供所有必要的信息，让你判断编码 agent 与审查 agent 之间是否已经进行了足够的循环迭代，以达到稳定状态。如果没有，则需要再迭代一轮。只有在信心充足、风险较低且所有问题都已解决时，才应该执行合并操作。 以下是 Trail 生命周期的 3 个步骤： ### 1. 创建 Trail 你可以在 Entire 上通过提交 bug 报告或功能请求来开启一个 Trail。也可以直接从你的 agent 发起一个 Trail，无论实现已经开始还是尚未开始，就像在准备好推送代码时打开一个 PR 一样。一个 Trail 可以跨多个仓库，让属于同一变更的内容聚合在一起。 ### 2. 使用 Eval 为 Trail 评分 当代码被推送到 Trail 时，Entire 会触发审查 agent 对提交进行审查。可以把它想象成一个陪审团在评判花样滑冰表演。每个 agent 在云端沙箱中独立运行，并提交分数和理由。例如，在 Entire 的许多仓库中，我们使用 Security（安全性）、Slop（代码质量）和 Human Review Required（需人工审查）等 eval。如果 Slop 分数显示为橙色，你可以指示 agent 根据这些数据继续修正和推送，直到分数变为绿色。每个 eval 会展示最近 5 次运行和当前运行的结果。我们认为这一点至关重要，因为一次性循环往往会遗漏关键问题。反复迭代循环、让分数趋于稳定，是 agent 编码成功的关键。 Entire 上的每个项目都自带代码质量、安全性和 Slop 的预定义 agent，可以按仓库逐个启用。你可以通过 Entire 用户界面进行配置，也可以在仓库中以 `.json` 配置文件的形式定义。在底层，Entire 使用搭载最新模型的 Claude Code 和 Codex，运行在由 [Daytona](https://www.daytona.io/) 和 [E2B](https://e2b.dev/) 提供的隔离云端沙箱中。 ### 3. 解决所有问题，然后合并 每次推送时，agent 还可以返回具体的问题发现和修复建议，并带有不同的严重级别。未解决的问题在 Trail 中始终可见，已解决的问题会被隐藏，但可以通过菜单找回。这样你始终清楚还有哪些问题悬而未决。问题可以被处理或忽略——你猜对了——由 agent 或人类开发者来完成。你也可以像在 PR 中一样发布问题和评论。 为确保未经处理 agent 发现的问题就无法合并，可以按仓库启用 Gates（合并门禁），定义批准前必须满足的条件。这些条件也包括人工批准和 CI 检查通过。 ## 与 Buildkite 和 Depot 的 CI 集成 持续集成最早由 Grady Booch 于 1991 年提出。它对现代软件开发生命周期的成功至关重要，使团队能够每天部署数百次。如今 agent 编写了所有代码，拥有 CI 作为安全保障变得更加重要，以防止 agent 做出超出提示词意图的更改。因此，我们很高兴在今天率先提供对领先 CI 供应商的一流集成，将其接入 Trails，首先支持 Buildkite 和 Depot。 ### Buildkite 在 Entire 上，CI 是在项目级别配置的，因为一个项目中的多个仓库通常使用相同的基础设施。连接 Buildkite 之后，每次推送都会在 Buildkite 或你自己的基础设施上进行构建。就像在 PR 上一样，构建结果会作为检查项显示在 Trail 上，构建失败将阻止合并。当然，agent 可以通过 Buildkite 的 API、CLI 或 MCP 自动化整个流程。 如果你是 GitHub Actions 用户，可以通过运行 `bk pipeline convert` 迁移工作流，无需重写。 ### Depot Depot 为开发者和编码 agent 提供快速、可靠的软件交付基础设施，兼容 GitHub Actions。Depot CI 无需经过 GitHub 即可运行现有工作流。 团队只需在 Entire 上点击几下即可连接 Depot，并在同一操作流程中创建 Depot 账户。然后 `depot ci migrate` 会发现你的 GitHub Actions 工作流，将其提升为 Depot CI 工作流，并标记需要审查的部分。配套命令支持导入密钥和变量，使迁移后的工作流在几分钟内即可运行。团队保留了他们构建的工作流，并从第一次运行起就获得快速可靠的 CI，按秒计费，因此运行更快的任务成本更低。 ## 在你所在的区域托管仓库 在分布式版本控制普及之前，仓库及其历史记录存储在 Subversion 这样的系统上。Git 改变了这一切。开发者可以在本地创建提交和分支、合并、甚至重写历史，之后再按需进行协调。Git 协议支持分布式甚至去中心化，但各个 forge 从未真正做到。Git 将仓库分发到了客户端，而各种 forge 则一次又一次地将服务器端集中化。我们认为这种集中式模型不适合未来，因为它缺乏可扩展性、弹性，也无法控制代码的存储位置。 从今天起，你可以在 Entire 上创建并原生托管一个仓库，或者从 GitHub 镜像一个仓库。**Entire 由一个全新的源代码管理服务器驱动，采用分布式对象存储和事务性 ref 数据库进行扩展，同时保持与 Git 的完全兼容。**得益于这种架构，Entire 是目前生产环境中最快的 Git forge。根据我们的[开源基准测试](https://github.com/entireio/forgemark)，推送速度比 GitHub 快高达 89 倍，比 Cursor Origin 快 6 倍。用户和组织可以将项目和仓库复制到多个区域，或保留在其所在的区域，例如满足数据驻留要求。我们目前已在美国、欧盟、澳大利亚和印度上线。 每秒推送数 高达 89 倍 | 平台 | 速度对比 | |------|----------| | Entire | 418 | | Cursor | 65 | | Pierre | 15 | | GitLab | 10 | | GitHub | 4.7 | ### 创建新仓库 要开始使用，你可以通过我们的[网页界面](https://entire.com/)在 Entire 上创建一个[新仓库](https://docs.entire.com/guides/repositories/entire-native-repositories#create-an-entire-repository)，也可以使用 Entire CLI 从你的 agent 端创建。仓库位于属于组织或个人账户的项目之下。创建项目时，你可以选择一个主区域，然后将仓库复制到一个或多个区域。 ### 镜像你的仓库（保留 GitHub 作为真实来源） 如果你希望 GitHub 继续作为真实来源（source of truth），没问题。只需为 Entire 授权 GitHub App，然后在 Entire 上选择仓库和区域即可[镜像](https://docs.entire.com/guides/repositories/mirrors#mirrors)你的仓库。你甚至可以在 pull request 之上使用 Trails，就像使用原生托管在 Entire 上的仓库一样。镜像模式下，推送流量会回经 GitHub。如果服务出现中断，Entire 将继续从你的区域镜像提供 clone 和 fetch 服务，你的 agent 可以继续推送到 Entire 原生分支（任何以 `entire/unmirrored/` 为前缀的分支），直到 GitHub 恢复正常。 ### 迁移你的仓库 如果你希望将仓库从 GitHub[迁移](https://docs.entire.com/migration/migrate-from-github#migrate-from-github)过来，有两种选择可用。如果你已经在美国区域进行镜像，可以打开仓库设置，点击 *Detach from GitHub*，然后选择要迁入的项目来分离镜像。或者，如果你想不经过镜像直接从 GitHub 迁移，可以使用 [entire-migrate](https://docs.entire.com/migration/migrate-from-github#cli) 插件来完成整个过程。当然，你也可以直接在本地机器或 CI/CD 流水线中从 GitHub fetch 并推送到 Entire。 ## 将会话转化为持续记忆 每天，开发者和 agent 都在做出决策、发现约束条件、尝试新方法，并在构建功能和修复 bug 的过程中总结什么方案可行。但这些知识中的大部分在会话结束时就消失了。当你开启新会话时，你的 agent 会打开一个新的上下文窗口，不得不重新学习所有内容，这不仅缓慢而且昂贵。 今天，我们引入了一个新概念，我们称之为**持续记忆（Continuous Memory）**。可以这样理解：CI 将代码汇集在一起，CD 将代码交付出去，而持续记忆则将理解延续下去。仓库应该是你的 agent 所需的唯一记忆。 Entire CLI 中的两个新命令使持续记忆成为可能：[entire-graph](https://github.com/entireio/entire-graph)，它映射你的代码如何组织在一起，在我们的测试中节省了高达 71% 的 token；以及 [entire-brain](https://github.com/entireio/entire-brain)，它索引你的 agent 会话并将其附加到代码图上，创建持久的记忆，agent 检索这些记忆的速度比在代码库中 grep 更快。两个插件都是开源且本地优先的，它们被设计为协同工作：entire-brain 基于 entire-graph 构建的代码地图。 ### 你的代码库地图 [entire-graph](https://github.com/entireio/entire-graph) 为你的 agent 提供一个预先计算好的 Git 仓库地图：排名代码搜索，以及定义、调用方、类型、路由和变更影响，每项都带有 `file:line` 位置信息。内置分析器使用 tree-sitter 在本地解析仓库，不会发出任何网络请求、模型调用或 API 密钥查询。 ### 多 Agent 记忆系统 [entire-brain](https://github.com/entireio/entire-brain) 为你的仓库创建一个持久的记忆层。这使 agent 能够始终在正确的时间获得正确的上下文，也就是*"变更了什么"*背后的*"为什么"*。在底层，entire-brain 索引 entire-graph 构建的代码地图，并将其与通过 Entire CLI 记录在 Git 历史中的过往 agent 会话绑定在一起。 例如，如果你正在修复一个导致计费系统出现舍入误差的 bug，entire-graph 会沿着每一个调用方和测试追踪发票计算过程，而 entire-brain 则为你的 agent 提供当前逻辑背后的意图、已经发布过的修复及其原因，或者上次有人修改它时哪些测试出现了故障。 entire-brain 也可以连接到 Entire 后端，使团队的 agent 记忆存放在一个共享空间中，而不是分散在各个个人机器上。这样每个 Trail 都会展示 agent 创建的记忆，审查者可以清楚地看到开发者做了哪些决策、agent 学到了哪些事实。