Thomas Dohmke，Entire 的联合创始人兼 CEO
经过一年多的打磨，我们很高兴推出首个专为智能体与人类协作而构建的 Git forge。Entire 建立在三个基础原语之上：
- Trail。与经典的通过 diff 审查代码变更的拉取请求模式不同，Trails 为开发者提供类似 airline pilot 的平视显示器，并带有可自定义的自动化评估，每次代码推送时由智能体进行评分。
- 分布式 Git 托管。Entire 构建在一个与 Git 兼容的新源代码控制服务器上，推送速度比 GitHub 快 89 倍，比 Cursor Origin 快 6 倍。你可以在全球多个区域托管和复制你的仓库，为智能体流量提供数据驻留和规模扩展能力。
- 持续记忆，这是一种面向智能体和开发者团队的新方法，将会话和提示同步到 Git 仓库中，并使这些数据对编码智能体持续可用且可搜索。
此外，我们正在构建一个开放生态系统，让开发者可以为任务挑选最佳工具。一开始，我们与 Buildkite 和 Depot 合作提供持续集成（CI），让你的构建和测试流水线跟上智能体交付的速度。
Entire 今天已面向所有开发者开放，并特别针对 AI 原生团队及其智能体进行了优化。让我们跳进这个新的多元宇宙。
用 Trails 进行审查
在拉取请求（PR）中，开发者在线性时间线上发表评论，持续集成（CI）在底部提供状态，随后是合并按钮。现在编码和代码审查正用冗长的描述刷屏这条时间线。开发者要求其编码智能体处理代码审查智能体的反馈，然后再进行一次审查。拉取请求已经变成了只有智能体才会阅读的审计日志。它没有提供开发者判断能否放心合并所需的信息。
The Trail 改变了这一点。它把相关信息以评估分数的形式带到页面顶部，这些分数在每次推送时计算。目标很简单：提供你所需的所有信息，以判断你的编码智能体与审查智能体之间是否已经进行了足够多的循环，从而达到稳定状态。或者没有，需要再进行一次迭代。只有当置信度高、风险低且所有发现项都已清除时，才应该进行合并。
以下是 Trail 生命周期的 3 个步骤：
1. 启动一个 Trail
Trail 可以在 Entire 上通过提交 bug 报告或功能请求来开始。或者你也可以直接从你的智能体启动一个 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 倍。用户和组织可以跨多个区域复制其项目和仓库，或将其保留在所在区域，例如为了满足数据驻留要求。我们目前在美国、欧盟、澳大利亚和印度上线。
每秒推送次数最高89倍更快
Entire418
Cursor65
Pierre15
GitLab10
GitHub4.7
创建新仓库
要开始使用，你可以创建在 Entire 上通过我们的网页界面或通过智能体使用 Entire CLI 创建一个新仓库。仓库位于属于组织或个人账户的项目内。创建项目时，你选择一个主区域，然后跨一个或多个区域复制你的仓库。
镜像你的仓库（保留 GitHub 作为唯一可信来源）
如果你希望 GitHub 继续作为唯一可信来源，没问题。镜像你的仓库，方法是授权 Entire 的 GitHub App，然后在 Entire 上选择仓库和区域。你甚至可以在拉取请求之上使用 Trails，就像使用原生托管在 Entire 上的仓库一样。镜像时，推送流量会路由回 GitHub。如果服务出现中断，Entire 会继续从你的区域镜像提供克隆和拉取，你的智能体可以继续推送到 Entire 原生分支（任何以entire/unmirrored/为前缀的分支），直到 GitHub 恢复。
迁移你的仓库
如果你想迁移你的仓库从 GitHub 迁移过来，有两种可选方案。在美国进行镜像时，你可以通过打开仓库设置，然后点击从 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 key。
多智能体记忆系统
entire-brain为你的仓库创建一个持久化的记忆层。这让智能体始终能在恰当的时间获得恰当的上下文，也就是“为什么”背后的“什么发生了变化。”在底层，entire-brain 会索引 entire-graph 为你代码生成的地图，并将其与通过 Entire CLI 记录在你 Git 历史中的过往智能体会话绑定在一起。
例如，如果你正在修复一个导致计费系统出现不匹配错误的舍入 bug，entire-graph 会沿着每一个调用方和测试追踪发票计算过程，而 entire-brain 则会让你的智能体了解当前逻辑背后的意图、已经上线的修复及其原因，或者上一次有人改动它时哪些测试失败了。
entire-brain 还可以连接到 Entire 后端，让你团队的智能体记忆存放在一个共享空间中，而不是分散在各台机器上。这样每个 Trail 都会展示智能体创建的记忆，让审查者看到开发者做了哪些决策、智能体学到了哪些事实。要开始使用，请在仓库中配置entire-graph和entire-brain。
加入这场反叛
在我们起步一年之后，对于 Entire 已经取得的成果以及我们的智能体接下来要做的事，我们无比兴奋。但构建一个新的开发者平台，只能与社区协作完成。所以我们想倾听你的声音、向你学习，并与你一起改进产品。试一试吧。通过Discord告诉我们你喜欢什么、希望改进什么，这样我们就能一起设计未来的锻造厂。
让我们趁热打铁。欢迎加入这场反叛。