Entire 推出专为人机协同打造的首个 Git 代码托管平台

经过一年多的锤炼，我们很高兴推出首个专门为智能体与人类协作构建的 Git 代码托管平台。Entire 基于三个核心要素构建：

1. The Trail（轨迹）。与通过代码差异（diff）审查代码变更的经典拉取请求模型不同，Trails 为开发者提供了一个类似于飞机驾驶员的平视显示器，带有由智能体在每次代码推送时进行评分的自动化可定制评估功能。
2. 分布式 Git 托管。Entire 基于一个与 Git 兼容的新型源码控制服务器构建，其推送速度比 GitHub 快高达 89 倍，比 Cursor Origin 快 6 倍。您可以托管自己的仓库并在全球多个区域进行复制，从而为智能体流量提供数据驻留和扩展能力。
3. 持续内存（Continuous Memory），这是一种针对智能体和开发团队的新方法，可将会话和提示词同步到 Git 仓库中，并使这些数据对编码智能体持续可用且可搜索。

此外，我们正在构建一个开放的生态系统，以便开发者能够选择最适合工作的工具。在初期，我们正与 Buildkite 和 Depot 合作进行持续集成（CI），以便您的构建和测试流水线能够跟上智能体发布的惊人速度。

Entire 从今天起向所有开发者开放，并且针对 AI 原生团队及其智能体进行了专门优化。让我们一起跨入这个全新的多元宇宙。

使用 Trails 进行审查

在一个拉取请求（PR）中，开发者按线性时间线发布评论，持续集成（CI）在底部提供状态，随后是合并按钮。现在，编写代码和代码审查正用冗长的描述充斥这条时间线。开发者请求他们的编码智能体处理代码审查智能体的反馈，然后进行另一次审查。拉取请求已变成一个只有智能体才会阅读的审计日志。它无法提供足够的信息让开发者决定是否可以放心地合并。

Trail 改变了这一点。它将相关信息作为评估分数显示在页面顶部，这些分数是在每次推送时计算出来的。目标很简单：提供你所需的所有信息，以决定你的编码智能体与审查智能体之间是否已经进行了足够的循环以达到稳定状态。或者尚未达到，需要进行另一次迭代。只有在置信度高、风险低且所有问题都已解决时，才应该进行合并。

以下是 Trail 生命周期的 3 个步骤：

1. 启动 Trail

可以在 Entire 上通过提交错误报告或功能请求来开始一个 Trail。或者，你可以在实现开始之前或之后，直接从你的智能体启动一个 Trail，就像准备推送代码时打开 PR 一样。一个 Trail 可以跨越多个仓库，因此属于同一整体的更改会被组合在一起。

2. 使用 Evals 对 Trail 进行评分

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

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

3. 关闭所有发现的问题，然后合并

每次推送时，代理还可以返回带有不同严重级别的特定发现和建议修复。未关闭的发现始终在 Trail 中可见，而已解决的发现会被隐藏，但可以通过菜单检索。通过这种方式，你始终能关注哪些问题尚未解决。正如你所料，发现问题可以由代理或人类开发者来处理或忽略。你还可以发布发现和评论，就像在拉取请求（PR）中一样。

为了确保在未处理代理发现的情况下不会进行合并，可以在每个仓库中启用门禁（Gates），以定义批准前所需的内容。这些还包括人工批准和通过 CI 检查。

通过 Buildkite 和 Depot 实现 CI

持续集成最早是由格雷迪·布奇（Grady Booch）于 1991 年提出的。它对现代软件开发生命周期的成功至关重要，使团队能够每天部署数百次。现在所有代码都由代理编写，将 CI 作为安全网甚至更加重要，这样代理就不会改变提示词未预期的内容。因此，我们很高兴为 Trails 提供领先 CI 提供商的 一流集成，今天从 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 即可运行现有工作流。

Teams can connect Depot from Entire in a few clicks and create a Depot account in the same flow. Then depot ci migrate discovers your GitHub Actions workflows, promotes them to Depot CI workflows, and flags anything that needs review. Companion commands support importing secrets and variables, so migrated workflows run within minutes. Teams keep the workflows they’ve built and get fast and reliable CI from the first run, billed by the second, so faster jobs cost less.

在您的区域托管仓库

Before distributed version control went mainstream, the repository and its history lived on systems like Subversion. Git changed that. Developers could create commits and branches, merge, or even rewrite history, all locally, and reconcile later when needed. The Git protocol supported distribution and even decentralization, but forges never lived up to it. Git distributed the repository to the client, and various forges centralized the server side, again and again. We believe this centralized model is not fit for the future as it lacks scalability, resilience, and control where to store our code.

从今天起，您可以在 Entire 上创建并原生托管仓库，或从 GitHub 镜像一个。 Entire is powered by a new source control server, scaled with a distributed object store and a transactional ref database that remains compatible with Git. 由于这种架构，Entire 是当今生产环境中最快的 Git 代码托管平台。 根据我们的 开源基准测试，推送（push）速度比 GitHub 快高达 89 倍，比 Cursor Origin 快 6 倍。 用户和组织可以在多个区域之间复制其项目和仓库，或将其保留在其扅在的区域（渚如用于数揥居留要求）。 我们今天已在美国、欧盟、澳大利亚和印度上线。

创建新仓库

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

镜像您的仓库（保留 GitHub 为单一真实源）

If you’d like GitHub to remain the source of truth, no problem. Mirror your repository by authorizing the GitHub App for Entire, then picking the repo and the regions on Entire. You can even use Trails on top of pull requests, just as you would with a repository natively hosted on Entire. When mirroring, push traffic routes back through GitHub. If there is a disruption in service, Entire will keep serving clones and fetches from your regional mirror, and your agents can keep pushing to Entire-native branches (any branch prefixed entire/unmirrored/) until GitHub is back.

迁移您的仓库

如果你想从 GitHub 迁移你的仓库，有两个选项可供选择。在美国进行镜像时，你可以打开仓库设置，然后点击从 GitHub 断开连接（Detach from GitHub），并选择要将项目移动到的目标，以此来解除镜像。或者，如果你想在不使用镜像的情况下直接从 GitHub 迁移，可以使用负责处理该流程的 entire-migrate 插件。当然，你随时可以从 GitHub 获取并推送到 Entire，无论是在本地机器上还是作为 CI/CD 工作流的一部分。

将对话转化为持续记忆

每天，开发者和代理（agents）在构建功能和修复漏洞的过程中，都会做出决策、发现限制、尝试新方法并了解什么可行。但绝大多数这类知识都会在对话结束时消失。当你开启新对话时，你的代理会打开一个新的上下文窗口，必须重新学习一切，这不仅速度慢而且成本高昂。

今天，我们引入了一个名为持续记忆（Continuous Memory）的新概念。可以这样理解：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-brain 对 entire-graph 的代码地图进行索引，并将其与通过 Entire CLI 记录在 Git 历史记录中的过去代理对话进行绑定。

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

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

加入叛军

在我们开始一年后，Entire 已经取得了这样的成就，以及我们的代理接下来正在开发的内容，这让我们感到无比兴奋。但构建一个新的开发者平台，只能通过与社区合作来实现。因此，我们想要倾听您的声音、向您学习，并与您一起改进产品。快来试用吧。通过 Discord 告诉我们您喜欢什么或希望改进什么，以便我们共同设计未来的开发中心。

趁热打铁。欢迎加入这场变革。