专为 AI Agent 与人类协作打造的 Git 代码托管平台：Entire 正式发布
英文标题：🔶 The Git Forge for Agent-Human Collaboration
前 GitHub CEO Thomas Dohmke 联合创办的全新 Git 代码托管平台 Entire 正式亮相，旨在颠覆以传统 Pull Request 为中心的协作模式。平台基于三大核心基石构建：以类似飞机座舱平视显示器（HUD）形式呈现自动化 Agent 评估分数的「Trail」代码评审流、Push 速度最高比 GitHub 快 89 倍且支持多区域复制的分布式 Git 托管服务，以及能将 Agent 会话与上下文同步至仓库的「持续记忆（Continuous Memory）」机制。该平台全面适配 AI 原生团队的高吞吐研发流，首发与 Buildkite 和 Depot 达成 CI 合作，有望深刻重塑 Agent 时代的软件工程基础设施与协同范式。
97.2 KB
中文
Thomas Dohmke，Entire 联合创始人兼 CEO
经过一年多的精雕细琢，我们非常激动地向大家推介首个专为 Agent 与人类协作打造的 Git 代码托管平台（Git forge）。Entire 建立在三大基石之上：
- Trail（轨迹）。与传统通过 diff 审查代码变更的 Pull Request 模式不同，Trails 为开发者提供了类似飞机驾驶员平视显示器（HUD）的界面，每次代码推送（push）都会由 Agent 进行自动化且可定制的评测（evals）打分。
- 分布式 Git 托管。Entire 基于一个兼容 Git 的全新版本控制服务器构建，其推送速度比 GitHub 快高达 89 倍，比 Cursor Origin 快 6 倍。你可以托管自己的代码仓库并将其复制到全球多个区域，为 Agent 流量提供数据驻留与高扩展性支持。
- 持续记忆（Continuous Memory）。这是一种面向 Agent 和开发团队的全新方式，可将交互会话（sessions）和提示词（prompts）同步至 Git 仓库中，使这些数据可被编码 Agent 随时调用和搜索。
此外，我们正在构建一个开放的生态系统，让开发者能够自由挑选最适合任务的工具。在初期，我们与 Buildkite 和 Depot 在持续集成（CI）领域展开合作，确保你的构建和测试流水线能够跟上 Agent 的极速交付步伐。
Entire 即日起面向所有开发者开放，并特别针对 AI 原生团队及其 Agent 进行了优化。让我们一起跨入这个全新的多元宇宙。
用 Trails 替代传统 Review
在 Pull Request（PR）中，开发者按照线性时间线发表评论，持续集成（CI）则在底部展示状态，最后是 Merge 按钮。如今，编码 Agent 与审查 Agent 产生的大篇幅描述正在刷屏这个时间线。开发者要求编码 Agent 解决审查 Agent 的反馈，随后再次进行审查。PR 逐渐沦为只有 Agent 才会阅读的审计日志，无法为开发者提供足够的信息来判断是否可以安心合并。
Trail 改变了这一现状。它将关键信息以 eval（评估）分数的形态置于页面顶端，并在每次 push 时重新计算。目标非常简单：为你提供所需的全部信息，帮助你判断编码 Agent 与审查 Agent 之间是否已经完成了足够多的闭环迭代以达到稳定状态；或者是否还需要进一步迭代。只有当置信度高、风险低且所有排查项（findings）均已解决时，才应该执行合并。
以下是 Trail 生命周期的 3 个阶段：
1. 启动一条 Trail
你可以在 Entire 上通过提交 bug 报告或功能需求来开启一条 Trail。或者，你也可以直接从 Agent 启动 Trail，无论是在实现开始之前还是之后，就像准备推送代码时发起 PR 一样。一条 Trail 可以横跨多个仓库，从而将本就相关的多处变更聚合在一起。
2. 通过 Eval 为 Trail 打分
当代码推送到 Trail 时，Entire 会触发审查 Agent 对 commit 进行评审。你可以将其想象成给花样滑冰比赛打分的裁判团。每个 Agent 都在独立的云端沙箱中运行，并提交评分和评估依据。例如，在 Entire 内部的许多仓库中，我们使用了“安全性（Security）”、“低质代码（Slop）”和“需要人工介入（Human Review Required）”等评估项。如果 Slop 分数呈现橙色，你可以指示 Agent 根据该数据继续修正并推送，直到分数变为绿色。每个 eval 都会显示最近 5 次运行以及当前运行的结果。我们认为这至关重要，因为单次执行往往容易遗漏关键问题；重复迭代循环并使评分趋于稳定，对于 Agent 编码的成功至关重要。
Entire 上的每个项目都预置了用于代码质量、安全性和低质代码检测的 Agent，并可以在单个仓库级别启用。你可以通过 Entire 的用户界面或仓库中的 .json 配置文件来自定义你自己的 Agent。在底层架构上，Entire 运用了搭载最新模型的 Claude Code 和 Codex，并运行在由 Daytona 和 E2B 提供的隔离云端沙箱中。
3. 解决所有发现项，随后合并
在每次 push 时，Agent 还可以返回具备不同严重等级的具体发现项（findings）和修复建议。未解决的问题在 Trail 中始终可见，已解决的则会被折叠隐藏，但仍可通过菜单调出。这样能确保你时刻关注尚未解决的事项。与你预想的一样，发现项可以由 Agent 或人类开发者来处理或忽略。你也可以像在 PR 中一样发表发现项和评论。
为了确保在 Agent 发现的问题未解决前不会发生合并，每个仓库都可以开启 Gates（关卡门禁），以定义获得 Approval 之前必须达成的条件。这些条件同样包括人工审批以及通过 CI 检查。
携手 Buildkite 和 Depot 推进 CI
持续集成（Continuous Integration）最早由 Grady Booch 于 1991 年提出。它对现代软件开发生命周期的成功起到了基石般的作用，使得团队每天能够部署数百次。如今，当大量代码由 Agent 编写时，CI 作为安全护栏的重要性愈发凸显，能够防止 Agent 做出超出 prompt 预期之外的改动。因此，我们非常高兴地在 Trails 中推出领先 CI 供应商的一级集成支持，首批包括 Buildkite 和 Depot。
Buildkite
在 Entire 上，CI 是在项目（project）级别配置的，因为一个项目内的多个代码仓库通常共享相同的底层设施。连接 Buildkite 后，每次 push 都可以在 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 工作流，并标记出任何需要人工复核的内容。配套命令还支持导入 Secrets 和变量，让迁移后的工作流在几分钟内即可投入运行。团队不仅能保留既有的工作流资产，还能从初次运行起就享受快速且可靠的 CI 服务，按秒计费，运行越快成本越低。
在本地所在区域托管代码仓库
在分布式版本控制普及之前，代码仓库及其历史记录都驻留在像 Subversion 这样的系统中。Git 改变了这一点——开发者可以在本地创建 commit、创建分支、合并，乃至重写历史，并在需要时再进行对齐。Git 协议天然支持分布式乃至去中心化，但各家代码托管平台（forges）却从未真正实现这一点。Git 把仓库分发到了客户端，各大托管平台却一次又一次地把服务端重新中心化。我们坚信，这种中心化模型已无法适应当下与未来，它在扩展性、容灾韧性以及数据存储自主权方面都存在缺陷。
从今天起，你可以在 Entire 上原生创建并托管仓库，或者从 GitHub 进行镜像。Entire 基于全新的源码控制服务器构建，依托分布式对象存储和事务型引用数据库（transactional ref database）进行水平扩展，同时完全兼容 Git 规范。 得益于这一架构，Entire 是目前生产环境中运行速度最快的 Git 平台。根据我们的开源基准测试，其 push 速度最高比 GitHub 快 89 倍，比 Cursor Origin 快 6 倍。个人用户和企业组织可以将项目与仓库跨多个区域进行多活复制，或将其保留在特定所在区域内，以满足数据驻留合规要求。我们目前已在美国、欧盟、澳大利亚和印度上线服务。
创建新仓库
你可以通过我们的 Web 界面或直接从 Agent 使用 Entire CLI 在 Entire 上创建新仓库。仓库隶属于组织或个人账号下的项目。创建项目时，你可以选择主区域，随后将仓库同步复制到一个或多个其他区域。
镜像仓库（保留 GitHub 作为单一事实来源）
如果你希望继续将 GitHub 作为单一事实来源（Source of Truth），完全没问题。通过为 Entire 授权 GitHub App，并选择相应的仓库和区域，即可开启仓库镜像。你甚至可以直接在 PR 之上使用 Trails 功能，体验与 Entire 原生托管仓库毫无二致。在镜像模式下，push 流量会回路由至 GitHub。如果不幸发生服务故障，Entire 将继续通过你的区域镜像节点提供 clone 和 fetch 服务，同时你的 Agent 依然可以持续向 Entire 原生分支（任何带有 entire/unmirrored/ 前缀的分支）推送代码，直到 GitHub 恢复正常。
迁移代码仓库
如果你想从 GitHub 迁移仓库，我们提供了两种方案。在美国区域进行镜像时，你可以进入仓库设置页点击 Detach from GitHub，并选择目标项目即可完成解绑脱离。另外，如果你想直接从 GitHub 迁移而不经过镜像，可以使用 entire-migrate 插件全自动完成迁移。当然，你也可以随时在本地设备或 CI/CD 流水线中，直接从 GitHub fetch 并 push 到 Entire。
将会话沉淀为持续记忆（Continuous Memory）
每一天，开发者和 Agent 在构建功能、排查 bug 的过程中，都会做出无数决策、摸清边界条件、尝试新路径并积累最佳实践。然而，绝大多数知识随着 Session 结束便烟消云散。每当你开启一个新会话，Agent 都会新建一个上下文窗口，不得不重新摸索所有事情——这不仅缓慢，而且成本高昂。
今天，我们正式推出一个全新的概念：持续记忆（Continuous Memory）。你可以这样理解：CI 汇聚代码，CD 交付代码，而持续记忆则让对系统的理解世代传承。代码仓库，理应成为你的 Agent 唯一需要的外部记忆体。
Entire CLI 中的两个全新命令让持续记忆成为现实：一个是 entire-graph，它能够精准测绘代码的组织结构，在我们的测试中最高节省了 71% 的 Token 消耗；另一个是 entire-brain，它能够对 Agent 会话进行索引，并将其挂载到图谱上，构建出持久化记忆，让 Agent 检索知识的速度远超直接在代码库中盲目 grep。这两个插件均完全开源且遵循本地优先（Local-First）原则，并且专为协同设计：entire-brain 构建于 entire-graph 对代码的拓扑映射之上。
代码库拓扑地图
entire-graph 为你的 Agent 呈现一份预先计算好的 Git 仓库全景图：包含排序后的代码检索，以及精确到 file:line 行号级别的定义、调用方、类型、路由和变更影响面分析。内置的分析引擎使用 tree-sitter 在本地解析代码仓库，完全无需发起网络请求、模型调用或 API Key 检索。
多 Agent 记忆系统
entire-brain 为你的代码仓库构建了一层持久化记忆层。这让 Agent 总能在对的时间获得对的上下文，换言之，就是理解“变更背后的深层原因（why）”，而不仅仅是“改了什么（what changed）”。在底层，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。
加入这场软件工程的变革（Join the Rebellion）
从项目启动一年多以来，我们对 Entire 当前取得的进展以及 Agent 接下来的研发方向感到无比振奋。但打造全新的开发者平台绝不可能闭门造车，唯有与社区紧密合作才能实现。我们迫切希望倾听你们的声音、向你们学习，并与大家携手打磨产品。欢迎亲自上手试用，并通过 Discord 告诉我们你所喜爱的亮点或期待改进的方向，让我们一起构建未来的 Git 代码托管平台。
趁热打铁，正当其时。欢迎加入这场变革！
English / 原文
Thomas Dohmke, co-founder and CEO of Entire
After more than a year of hammering the iron, we’re excited to introduce the first Git forge built specifically for agent-human collaboration. Entire is built on three primitives:
- The Trail. Unlike the classic pull request model of reviewing code changes with a diff, Trails offers developers a heads-up display similar to an airline pilot, with automated customizable evals that are scored by agents on every code push.
- Distributed Git hosting. Entire is built on a new source control server compatible with Git, which pushes up to 89x faster than GitHub and 6x faster than Cursor Origin. You can host your repo and replicate it in multiple regions around the world, offering data residency and scale for agentic traffic.
- Continuous Memory , a new approach for agents and developer teams that sync sessions and prompts into the Git repository, and makes that data constantly available and searchable to coding agents.
Plus, we are building an open ecosystem, so developers can pick the best tools for the job. At the start, we are partnering with Buildkite and Depot for Continuous Integration (CI), so your build and test pipelines keep up with how fast agents ship.
Entire is available for any developer today, and especially optimized for AI-native teams and their agents. Let’s jump into the new multiverse.
Review with Trails
In a pull request (PR), developers post their comments in a linear timeline, and continuous integration (CI) provides a status at the bottom followed by the merge button. Now coding and code review are spamming this timeline with long descriptions. Developers request their coding agent to address the code review agents’ feedback and then do another review. The pull request has become an audit log that only the agent reads. It does not provide the information for the developer to decide whether they can merge with confidence.
The Trail changes this. It brings the relevant information to the top of the page as eval scores, which are calculated on every push. The goal is simple: Give all the information you need to decide whether enough loops between your coding agent and the review agents have happened to achieve a stable state. Or not, and another iteration is needed. Only when the confidence is high, risk is low, and all findings are cleared, the merge should happen.
Here’s how the Trail lifecycle works in 3 steps:
1. Spinning Up a Trail
A Trail can begin on Entire by filing a bug report or a feature request. Or you can start a Trail straight from your agent, before or after the implementation has started, like you would open a PR when you are ready to push code. A Trail can span multiple repositories, so changes that belong together are grouped together.
2. Scoring the Trail with Evals
When code is pushed to a Trail, Entire triggers review agents to review the commit. Think about it like a jury judging an ice skating performance. Each agent runs independently in a cloud sandbox and submits a score and a rationale. For example, across many of our repositories at Entire, we use Security, Slop, and Human Review Required evals. If the Slop score is orange, you can instruct your agent to continue correcting and pushing based on that data until the score turns green. The last 5 runs and the current run are shown for each eval. We believe this is crucial as one-shot loops are often missing a critical issue. Repeating the loops and stabilizing the scores is crucial for the success of agentic coding.
Each project on Entire comes with pre-defined agents for code quality, security, and slop that can be enabled on a per-repo basis. You can configure your own agents via the Entire user interface or as .json config in the repo. Under the hood, Entire utilizes Claude Code and Codex with the latest models, running on isolated cloud sandboxes provided by Daytona and E2B.
3. Close All Findings, Then Merge
On every push, agents can also return specific findings and suggested fixes with different severity levels. Open findings are always visible in the Trail, while resolved findings are hidden, but can be retrieved via the menu. This way, you always stay alert on what is still open. A finding can be addressed or dismissed, you guessed it, by agents or human developers. You can also post findings and comments, just like in a pull request.
To make sure the merge doesn’t happen without addressing the agent findings, Gates can be enabled per repo to define what is required before approval. These also include human approvals and passing CI checks.
CI with Buildkite and Depot
Continuous Integration was first proposed by Grady Booch all the way back in 1991. It has been crucial to the success of the modern software development lifecycle, enabling teams to deploy hundreds of times per day. Now that agents write all the code, it’s even more important to have CI as a safeguard, so the agent isn’t changing what the prompt didn’t intend. As such, we are excited to offer first-class integrations of leading CI providers into Trails, starting with Buildkite and Depot today.
Buildkite
On Entire, CI is configured at the project level as often multiple repositories within a project use the same infrastructure. Once Buildkite is connected, every push builds on either Buildkite’s or your own infrastructure. Like it would on a PR, the result shows up as a check on your Trail, and a failing build will block merging. Of course, agents can automate the entire loop on their own, via Buildkite’s API, CLI, or MCP.
If you are a GitHub Actions user, you can migrate your workflow by running bk pipeline convert without rewriting.
Depot
Depot provides fast, reliable software delivery infrastructure for developers and coding agents, compatible with GitHub Actions. Depot CI runs existing workflows without GitHub in the middle.
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.
Host Repos in Your Region
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.
Starting today, you can create and natively host a repository on Entire, or mirror one from 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. Due to this architecture, Entire is the fastest Git forge in production today. According to our open-source benchmarks, pushes are up to 89x faster than GitHub and 6x faster than Cursor Origin. Users and orgs can replicate their projects and repositories across multiple regions, or keep it in the region they reside in, for example for data residency requirements. We are live today in the US, EU, Australia, and India.
Create a New Repository
To get started, you can create a new repository on Entire from our web interface or from your agent using the Entire CLI. Repositories live inside projects belonging to an organization or a personal account. When you create a project, you pick a primary region and then replicate your repository across one or more regions.
Mirror Your Repository (Keep GitHub as Source of Truth)
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.
Migrate Your Repository
If you’d like to migrate your repository from GitHub, there are two options available to you. When mirroring in the United States, you can detach your mirror by opening the repository’s settings, then clicking Detach from GitHub , and choosing the project to move it into. Or, if you’d like to migrate directly from GitHub without mirroring, you can use the entire-migrate plug-in which takes care of the process. And, of course, you can always just fetch from GitHub and push to Entire, on your local machine or as part of your CI/CD workflow.
Turn Sessions Into Continuous Memory
Every day, developers and agents make decisions, discover constraints, try new approaches, and learn what works while building features and squashing bugs. But most of that knowledge disappears when the session ends. When you start a new session, your agent opens a new context window and has to re-learn everything which is not only slow but also expensive.
Today, we are introducing a new concept that we are calling Continuous Memory. Think about it this way: CI brings code together. CD ships it. Continuous Memory carries the understanding forward. The repository is the only memory your agent should need.
Two new commands in the Entire CLI make Continuous Memory possible: entire-graph, which maps how your code fits together and in our testing saved up to 71% on tokens, and entire-brain, which indexes your agent sessions and attaches them to the graph to create durable memories that the agent can retrieve faster than grepping through the codebase. Both plugins are open source and local first, and they’re designed to work together: entire-brain builds on entire-graph’s map of your code.
A Map of Your Codebase
entire-graph hands your agent a precomputed map of your Git repository: ranked code search plus definitions, callers, types, routes, and change impact, each with file:line locations. The built-in analyzer parses the repository locally with tree-sitter and makes no network requests, model calls, or API-key lookups.
A Multi-Agent Memory System
entire-brain creates a durable memory layer for your repository. This allows agents to always have the right context at the right time, aka the “why” behind the “what changed.” Under the hood, entire-brain indexes entire-graph’s map of your code and binds it with past agent sessions that are recorded in your Git history via the Entire CLI.
For example, if you were fixing a rounding bug that created a mismatch error in your billing system, entire-graph traces the invoice calculation through every caller and test, while entire-brain gives your agent the intent behind the current logic, the fixes already shipped and why, or what tests broke the last time someone changed it.
entire-brain can also be connected to the Entire backend, enabling your team’s agent memories to live in one shared space instead of individual machines. Every Trail then shows the memories that the agent created, so reviewers see what decisions the developer made and what facts the agent learned. To get started, set up entire-graph and entire-brain in your repository.
Join the Rebellion
A year after we started, we couldn’t be more excited about what Entire has already become and what our agents are working on next. But building a new developer platform can only be done in collaboration with the community. So we want to hear from you, learn from you, and improve the product with you. Try it out. Tell us what you love or want improved via Discord so we can design the forge of the future, together.
Let’s strike while the iron is hot. Welcome to the rebellion.