Entire 发布面向智能体与人类协作的 Git 平台

经过一年多的反复打磨，我们很高兴推出首个专为智能体与人类协作而构建的 Git 代码托管平台。Entire 建立在三大基础能力之上：

1. Trail。与经典的拉取请求模式（通过 diff 审查代码变更）不同，Trails 为开发者提供类似 airline pilot 的平视显示器，并配有可自定义的自动化评估，每次代码推送时由智能体进行评分。
2. 分布式 Git 托管。Entire 构建在兼容 Git 的全新源代码控制服务器之上，推送速度最高可达 GitHub 的 89 倍、Cursor Origin 的 6 倍。你可以在全球多个区域托管并复制仓库，为智能体流量提供数据驻留和规模扩展能力。
3. 持续记忆，这是一种面向智能体和开发者团队的新方法，将会话和提示同步到 Git 仓库中，并使这些数据对编码智能体持续可用且可搜索。

此外，我们正在构建开放生态，让开发者可以为任务挑选最佳工具。初期，我们与 Buildkite 和 Depot 合作提供持续集成（CI），让你的构建和测试流水线跟上智能体的交付速度。

Entire 今天已面向所有开发者开放，并特别针对 AI 原生团队及其智能体进行了优化。让我们跃入新的多元宇宙。

使用 Trails 进行审查

在拉取请求（PR）中，开发者在线性时间线中发表评论，持续集成（CI）在底部提供状态，随后是合并按钮。如今，编码和代码审查正用冗长的描述刷屏这条时间线。开发者要求其编码智能体处理代码审查智能体的反馈，然后再进行一次审查。拉取请求已变成只有智能体阅读的审计日志。它无法为开发者提供信息，以决定是否可以放心合并。

Trail 改变了这一点。它将相关信息以评估分数的形式带到页面顶部，这些分数在每次推送时计算。目标很简单：提供你所需的所有信息，以判断编码智能体与审查智能体之间是否已进行足够多的循环，达到稳定状态。或者没有，需要再进行一次迭代。只有当置信度高、风险低且所有发现的问题都已清除时，才应进行合并。

以下是 Trail 生命周期三步工作方式：

1. 启动 Trail

Trail 可以在 Entire 上通过提交缺陷报告或功能请求来启动。或者，你也可以直接从智能体启动 Trail，无论实现是否已开始，就像你准备好推送代码时打开 PR 一样。一个 Trail 可以跨越多个仓库，因此属于一起的变更会被分组在一起。

2. 使用评估为 Trail 评分

当代码被推送到 Trail 时，Entire 会触发评审代理来审查该提交。可以把它想象成评审团为一场花样滑冰表演打分。每个代理都在云沙箱中独立运行，并提交分数和理由。例如，在 Entire 的许多仓库中，我们使用 Security、Slop 和 Human Review Required 这几项评估。如果 Slop 分数为橙色，你可以指示你的代理根据该数据继续修正并推送，直到分数变为绿色。每项评估都会显示最近 5 次运行和当前运行的结果。我们认为这一点至关重要，因为一次性循环往往会遗漏关键问题。重复循环并稳定分数对于代理式编码的成功至关重要。

Entire 上的每个项目都自带针对代码质量、安全性和 slop 的预定义代理，可按仓库启用。你可以通过 Entire 用户界面，或在仓库中以 .json 配置的方式配置自己的代理。在底层，Entire 使用最新模型的 Claude Code 和 Codex，运行在由 Daytona 和 E2B 提供的隔离云沙箱上。

3. 关闭所有发现项，然后合并

每次推送时，代理还可以返回具体发现项和带有不同严重级别的修复建议。未解决的发现项始终在 Trail 中可见，而已解决的发现项会被隐藏，但可以通过菜单检索。这样，你始终能对仍未解决的问题保持警觉。发现项可以由代理或人类开发者处理或驳回——你猜对了。你也可以像在拉取请求中一样发布发现项和评论。

为确保在未处理代理发现项的情况下不会发生合并，可以按仓库启用 Gates 来定义批准前所需的条件。这些条件还包括人工批准和通过 CI 检查。

使用 Buildkite 和 Depot 的 CI

持续集成最早由 Grady Booch 于 1991 年提出。它对现代软件开发生命周期的成功至关重要，使团队能够每天部署数百次。如今既然由智能体编写所有代码，将 CI 作为保障就更加重要，这样智能体就不会改动提示词并未意图修改的内容。因此，我们很高兴将领先 CI 提供商的一流集成引入 Trails，今天先从 Buildkite 和 Depot 开始。

Buildkite

在 Entire 上，CI 在项目级别配置，因为一个项目中的多个仓库通常使用相同的基础设施。连接 Buildkite 后，每次推送都会在 Buildkite 或你自己的基础设施上构建。就像在 PR 上一样，结果会作为检查项显示在你的 Trail 上，构建失败将阻止合并。当然，代理可以通过 Buildkite 的 API、CLI 或 MCP 自行自动化整个循环。

如果你是 GitHub Actions 用户，可以运行 bk pipeline convert 来迁移工作流，而无需重写。

Depot

Depot 为开发者和编码代理提供快速、可靠的软件交付基础设施，并兼容 GitHub Actions。Depot CI 无需 GitHub 介入即可运行现有工作流。

团队只需点击几下即可从 Entire 连接 Depot，并在同一流程中创建 Depot 账户。随后 depot ci migrate 会发现你的 GitHub Actions 工作流，将其升级为 Depot CI 工作流，并标记出任何需要审查的内容。配套命令支持导入密钥和变量，因此迁移后的工作流可在几分钟内运行。团队保留他们已构建的工作流，并从首次运行起就获得快速可靠的 CI，按秒计费，因此更快的任务成本更低。

在你的区域托管仓库

在分布式版本控制成为主流之前，仓库及其历史记录存放在 Subversion 等系统上。Git 改变了这一点。开发者可以在本地创建提交和分支、合并，甚至重写历史，然后在需要时再进行协调。Git 协议支持分布式甚至去中心化，但代码托管平台从未真正兑现这一点。Git 将仓库分发到客户端，而各种代码托管平台一次又一次地将服务器端集中化。我们认为这种集中式模型不适合未来，因为它缺乏可扩展性、韧性，以及对我们代码存储位置的控制。

从今天起，你可以在 Entire 上创建并原生托管仓库，或从 GitHub 镜像一个仓库。Entire 由全新的源代码控制服务器驱动，通过分布式对象存储和与 Git 保持兼容的事务性 ref 数据库进行扩展。得益于这一架构，Entire 是当今生产环境中速度最快的 Git 代码托管平台。根据我们的开源基准测试，推送速度最高比 GitHub 快 89 倍，比 Cursor Origin 快 6 倍。用户和组织可以跨多个区域复制其项目和仓库，或将其保留在所在区域，例如为了满足数据驻留要求。我们目前在美国、欧盟、澳大利亚和印度上线。

创建新仓库

要开始使用，你可以通过我们的网页界面或使用 Entire CLI 从你的 agent 在 Entire 上创建新仓库。仓库位于属于组织或个人账户的项目中。创建项目时，你选择一个主区域，然后在一个或多个区域中复制你的仓库。

镜像你的仓库（保留 GitHub 作为事实来源）

如果你希望 GitHub 继续作为事实来源，没问题。为 Entire 授权 GitHub App，然后在 Entire 上选择仓库和区域，即可镜像你的仓库。你甚至可以在拉取请求之上使用 Trails，就像使用原生托管在 Entire 上的仓库一样。镜像时，推送流量会经由 GitHub 路由。如果服务出现中断，Entire 将继续从你的区域镜像提供克隆和拉取服务，你的 agent 可以继续推送到 Entire 原生分支（任何以 entire/unmirrored/ 为前缀的分支），直到 GitHub 恢复。

迁移你的仓库

如果你想把仓库从 GitHub 迁移过来，有两种方式可选。在美国进行镜像时，你可以打开仓库设置，点击 Detach from GitHub，然后选择要迁移到的项目来解除镜像。或者，如果你想直接从 GitHub 迁移而不做镜像，可以使用 entire-migrate 插件来完成整个过程。当然，你也可以随时在本地机器上或作为 CI/CD 工作流的一部分，从 GitHub 拉取并推送到 Entire。

将会话转化为持续记忆

每天，开发者和智能体在构建功能、修复缺陷的过程中做出决策、发现约束、尝试新方法，并总结出哪些做法有效。但这些知识大多在会话结束时消失。当你开启新会话时，智能体会打开新的上下文窗口，不得不重新学习一切——这不仅慢，而且昂贵。

今天，我们推出一个全新的概念，我们称之为持续记忆。可以这样理解：CI 把代码汇聚在一起，CD 将其交付，而持续记忆则把理解传递下去。仓库应该是你的智能体唯一需要的记忆。

Entire CLI 中的两个新命令让持续记忆成为可能：entire-graph，它映射你的代码如何组合在一起，在我们的测试中最多节省了 71% 的 token；以及 entire-brain，它索引你的智能体会话并将其附加到图谱上，创建智能体可以比在代码库中 grep 更快检索的持久记忆。两个插件都是开源且本地优先的，并且设计为协同工作：entire-brain 构建在 entire-graph 的代码地图之上。

你的代码库地图

entire-graph 为你的智能体提供一张预先计算好的 Git 仓库地图：排序后的代码搜索，加上定义、调用方、类型、路由和变更影响，每一项都带有 file:line 位置。内置分析器使用 tree-sitter 在本地解析仓库，不发起网络请求、模型调用或 API 密钥查询。

多智能体记忆系统

entire-brain 为你的仓库创建持久记忆层。这让智能体始终能在正确的时间获得正确的上下文，也就是“变更内容”背后的“原因”。在底层，entire-brain 索引 entire-graph 的代码地图，并将其与通过 Entire CLI 记录在 Git 历史中的过往智能体会话绑定。

例如，如果你正在修复一个导致计费系统出现不匹配错误的舍入缺陷，entire-graph 会追踪发票计算经过的每个调用方和测试，而 entire-brain 则让你的智能体了解当前逻辑背后的意图、已经发布的修复及其原因，或者上次有人修改它时哪些测试失败了。

entire-brain 还可以连接到 Entire 后端，让你团队的智能体记忆存在于一个共享空间，而不是各自的机器上。这样每个 Trail 都会显示智能体创建的记忆，让审查者看到开发者做了哪些决策、智能体学到了哪些事实。要开始使用，请在你的仓库中设置 entire-graph 和 entire-brain。

加入这场变革

在我们起步一年之后，我们对 Entire 已经取得的成就以及我们的智能体接下来正在推进的工作感到无比兴奋。但构建一个新的开发者平台只能与社区协作完成。所以我们希望倾听你的声音、向你学习，并与你一起改进产品。试一试吧。通过 Discord 告诉我们你喜欢什么或希望改进什么，让我们一起设计未来的锻造厂。

趁热打铁。欢迎加入这场反叛。