Entire 发布首个 Agent-Human 协作 Git 平台

DashboardSign in

Thomas Dohmke，Entire 联合创始人兼首席执行官

经过一年多的精心打磨，我们很高兴推出首个专为“人机协作”打造的 Git 代码托管平台（Git forge）。Entire 基于三大核心原语构建：

1. Trail（轨迹）。不同于传统的 Pull Request 模式——即通过 diff 审查代码变更，Trail 为开发者提供类似民航飞行员驾驶舱的抬头显示体验，并配备可自动定制、由 Agent 在每次代码推送时进行评分的评估机制（evals）。
2. 分布式 Git 托管。Entire 基于一个全新的、兼容 Git 的源代码控制服务器构建，其推送速度比 GitHub 快高达 89 倍，比 Cursor Origin 快 6 倍。你可以托管自己的仓库，并将其复制到全球多个区域，从而为 Agent 流量提供数据驻留支持和规模化能力。
3. Continuous Memory（持续记忆）。这是一种面向 Agent 和开发团队的新方法，它将会话和提示词同步到 Git 仓库中，并使这些数据对编码 Agent 始终可用且可搜索。

此外，我们正在构建一个开放生态系统，让开发者可以选择最适合工作的工具。起步阶段，我们与 Buildkite 和 Depot 合作提供持续集成（CI）服务，确保你的构建和测试流水线能够跟上 Agent 快速交付的节奏。

Entire 今日即可供任何开发者使用，并特别针对 AI 原生团队及其 Agent 进行了优化。让我们一同进入这个新的多元宇宙。

通过 Trail 进行审查

在 Pull Request (PR) 中，开发者按线性时间轴发表评论，持续集成（CI）在底部提供状态信息，随后是合并按钮。如今，编码和代码审查正用冗长的描述刷屏这一时间轴。开发者要求他们的编码 Agent 处理来自审查 Agent 的反馈，然后再次进行审查。Pull Request 已变成只有 Agent 才会阅读的审计日志。它无法为开发者提供足够的信息，以自信地决定是否可以进行合并。

Trail 改变了这一现状。它将相关信息以评估分数（eval scores）的形式呈现在页面顶部，这些分数在每次推送时计算得出。目标很简单：提供所有必要信息，以便你判断编码 Agent 与审查 Agent 之间的循环是否已达到稳定状态。如果没有，则需要另一轮迭代。只有当置信度高、风险低且所有发现的问题都已解决时，才应执行合并操作。

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

1. 启动 Trail

在 Entire 平台上，你可以通过提交 Bug 报告或功能请求来开启一个 Trail。或者，你也可以直接从你的 Agent 发起 Trail——无论实现工作是否已经开始，就像准备好推送代码时打开一个 PR 一样。一个 Trail 可以跨越多个仓库，因此将相关的变更归组在一起。

2. 通过 Evals 对 Trail 进行评分

当代码推送到 Trail 时，Entire 会触发审查 Agent 来检查该 commit。你可以将其想象成评委为花样滑冰表演打分。每个 Agent 都在独立的云沙箱中运行，并提交分数和理由。例如，在 Entire 的许多仓库中，我们使用 Security（安全性）、Slop（低质代码）和 Human Review Required（需人工审查）等 evals。如果 Slop 分数显示为橙色，你可以指示你的 Agent 根据这些数据继续修正并推送代码，直到分数变为绿色。系统会显示每次 eval 的最后 5 次运行结果以及当前运行结果。我们认为这一点至关重要，因为一次性循环往往遗漏关键问题。重复循环并使分数稳定对于 Agentic Coding 的成功至关重要。

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

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

在每次推送时，Agent 还可以返回具体的发现项和建议修复方案，并标注不同的严重级别。未解决的发现项始终在 Trail 中可见，而已解决的发现项则被隐藏，但可通过菜单检索。这样，你始终能清楚哪些事项仍未解决。发现项可以由 Agent 或人类开发人员处理或忽略——正如你所料。你还可以像在处理 Pull Request 时那样发布发现项和评论。

为了确保在未处理 Agent 发现项的情况下不会发生合并，可以按仓库启用 Gates（门禁），以定义批准前必须满足的条件。这些条件还包括人工审批和通过 CI 检查。

使用 Buildkite 和 Depot 进行 CI

持续集成（Continuous Integration）最早由 Grady Booch 在 1991 年提出。它对现代软件开发生命周期的成功至关重要，使团队能够每天部署数百次。如今，既然由 Agent 编写所有代码，将 CI 作为安全护栏就显得更加重要，以确保 Agent 不会修改 Prompt 未意图更改的内容。因此，我们很高兴为 Trails 提供主流 CI 提供商的一流集成，今日率先支持 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，按秒计费，因此更快的任务成本更低。

0 / 0

在你的区域托管仓库

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

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

创建新仓库

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

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

如果你希望 GitHub 继续作为事实来源（Source of Truth），完全没问题。通过授权 Entire 的 GitHub App，然后选择要在 Entire 上使用的仓库及区域，即可镜像你的仓库。你甚至可以在拉取请求（Pull Requests）之上使用 Trails 功能，就像在 Entire 上原生托管的仓库一样。在镜像模式下，推送流量会经由 GitHub 路由。如果服务出现中断，Entire 将继续从其区域镜像中提供克隆和 fetch 操作，并且你的智能体可以继续向 Entire 原生分支（任何以 entire/unmirrored/ 为前缀的分支）推送代码，直到 GitHub 恢复服务。

迁移你的仓库

如果你想将仓库从 GitHub 迁移过来，你有两个选择。如果在美国进行镜像同步，你可以打开仓库设置，点击 Detach from GitHub（与 GitHub 分离），然后选择要移入的项目来解除镜像关联。或者，如果你希望直接从 GitHub 迁移而不经过镜像步骤，可以使用 entire-migrate 插件来处理整个流程。当然，你也可以始终在本地机器上或作为 CI/CD 工作流的一部分，直接从 GitHub fetch 并 push 到 Entire。

将会话转化为持续记忆

每天，开发者和智能体（agents）都在构建功能、修复 bug 的过程中做出决策、发现约束条件、尝试新方法并学习哪些方案有效。但大部分知识会在会话结束时消失。当你开启新会话时，你的智能体会打开一个新的上下文窗口，不得不重新学习所有内容——这不仅缓慢，而且成本高昂。

今天，我们推出一个名为 Continuous Memory（持续记忆）的新概念。可以这样理解：CI 整合代码，CD 交付代码，而 Continuous Memory 则将认知传承下去。仓库应该是你的智能体唯一需要的记忆载体。

Entire CLI 中的两个新命令使 Continuous Memory 成为可能：entire-graph，它映射你的代码如何相互关联，在我们的测试中节省了高达 71% 的 token；以及 entire-brain，它索引你的智能体会话并将其附加到图谱上，创建持久化记忆，使智能体能够比通过 grep 搜索代码库更快地检索信息。这两个插件都是开源且本地优先的，并且旨在协同工作：entire-brain 基于 entire-graph 生成的代码地图构建。

你的代码库地图

entire-graph 为你的智能体提供一份预计算的 Git 仓库地图：包括排名的代码搜索、定义、调用者、类型、路由和变更影响分析，每项都附带 file:line 位置信息。内置分析器使用 tree-sitter 在本地解析仓库，不发起任何网络请求、模型调用或 API-key 查询。

entire-brain

entire-brain 为你的代码仓库创建一个持久化的记忆层。这使得 AI Agent 始终能在正确的时机获取正确的上下文，即理解 “变更内容” 背后的 “原因”。在底层，entire-brain 会对 entire-graph 生成的代码图谱进行索引，并将其与通过 Entire CLI 记录在 Git 历史中的过往 Agent 会话绑定在一起。

例如，如果你正在修复一个导致计费系统出现不匹配错误的舍入 bug，entire-graph 会追踪发票计算在所有调用方和测试用例中的路径，而 entire-brain 则向你的 Agent 提供当前逻辑背后的意图、已发布的修复方案及其原因，或者上次有人修改该逻辑时哪些测试失败了。

entire-brain 还可以连接到 Entire 后端，使团队的 Agent 记忆存在于一个共享空间中，而非分散在各个独立机器上。随后，每个 Trail（轨迹）都会展示 Agent 创建的记忆，以便审查者了解开发者做出的决策以及 Agent 学到的事实。要开始使用，请在你的代码仓库中设置 entire-graph 和 entire-brain。

0 / 0

加入这场革命

在我们起步一年后，对于 Entire 已经取得的成就以及我们的 Agent 接下来要处理的任务，我们感到无比兴奋。但构建一个新的开发者平台离不开与社区的协作。因此，我们希望听取你们的意见，向你们学习，并与你们共同改进产品。试用一下，并通过 Discord 告诉我们你喜欢什么或希望改进什么，让我们共同设计未来的锻造炉。

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

[OCTOBER 16, 2026 · Lizzie Siegle

Entire CLI 现已集成 Grok

使用 Entire 的外部 Agent 插件保存你的 Grok Build 会话，从而让每次提交背后的提示词、响应和工具调用都保留在你的 Git 历史中。

Changelog](https://entire.com/blog/the-entire-cli-is-now-integrated-with-grok)[OCTOBER 08, 2026 · Marvin

使用 Google 账户登录 Entire

无需 GitHub 即可创建 Entire 账户，此外还包括针对镜像仓库、会话发现、Codex hooks、插件帮助和仓库 URL 的 CLI 修复。

Changelog](https://entire.com/blog/entire-dispatch-0x001f)[OCTOBER 06, 2026 · Haimantika Mitra

分享会话是新的社交编程

我如何使用 Entire 会话来编写我们的文档，并与团队成员分享每次更改背后的上下文。

Engineering