Entire 公开了：前 GitHub CEO 要把代码评审从读 diff 改成审证据

一句话：评审的对象变了

2026 年 10 月 26 日，前 GitHub 首席执行官 Thomas Dohmke 创立的 Entire 正式公开了它的答案：第一个为 agent 与人协作而建的 Git forge。它要取代的不是 GitHub 的某一个按钮，而是整个 Pull Request 模式——以后每一次 push，不再等一个人逐行读 diff，而是由多个 agent 在沙箱里打分，只有当质量、安全与 slop（低质 AI 生成内容）等评估全部过关，代码才能合并；团队还可以把人工签核或 CI 通过设为放行条件（Gate）。人仍然可以最后点头，但不再需要把每一行 diff 都读完才敢点头。

这句话值得认真对待，也值得保持警惕。认真对待，是因为它命中的是真实瓶颈：agent 写代码的速度已经远远超过人读代码的速度，评审环节正在成为整条流水线最窄的地方。保持警惕，是因为 Entire 官宣里最亮眼的数字——push 比 GitHub 快 89 倍、代码库图谱省 token 至多 71%——都明确标注为厂商自测，尚未经过独立复测。本文会把官宣事实与厂商说法分开标，把能验证的留下，把没验证的点出来，最后给出一份小团队今天就能用的采用清单。

发生了什么：一次官宣，三个新原语

Entire 在 2026 年 10 月 26 日的官宣中说，这款产品从当天起向所有开发者开放。它建立在三个“全新原语”之上。第一是 Trail，即取代 Pull Request 的评审单元；第二是分布式 Git 托管，即与 Git 兼容的新一代源代码控制服务器；第三是 Continuous Memory，即把会话同步进仓库、让 agent 随时可查的记忆系统。与此同时，Entire 宣布与 Buildkite、Depot 集成，让构建与测试跟得上 agent 出货的速度。

背景同样值得一笔。Entire 在 2026 年 2 月完成了 6000 万美元种子轮融资，官宣称这是开发者工具史上最大的种子轮；团队现已扩张到 50 人，成员背景横跨 GitHub、微软、Atlassian、DigitalOcean 等公司。在此之前，Entire 先后发布了镜像功能与 Entire CLI（用于追踪 agent 会话），为这次官宣打下了基础。路线图上写着自托管 Git 节点、公开仓库、直播会话以及更多合作伙伴集成——也就是说，今天开放的还只是一个起点，公开仓库等许多开发者最关心的能力仍在“即将到来”一栏里。

Trail 到底是什么：从“看 diff”到“看证据”

经典 Pull Request 的逻辑是：开发者 fork 仓库、改代码、把 diff 发给维护者，维护者读 diff、提意见、等作者改完再合并。Dohmke 在官宣中的原话点出了这个模式的断裂点：Pull Request 曾经把“在邮件列表里发 diff 和补丁”变成了“fork 后把改动发回给维护者”，是一次革命；但今天 agent 写出了几乎全部代码，而且写得更快、更复杂，旧的评审方式已经跟不上。

Trail 把这个流程倒了过来。每一次 push 之后，多个 agent 会在沙箱中对这次改动进行评分，评估维度包括代码质量、安全性与 slop。官宣把 Trail 比作飞行员的平视显示器：开发者看到的不再是一大段原始 diff，而是一组结构化的评估结果。所有数据不仅能在 Entire 的网页界面上看到，也能通过开源的 Entire CLI 获取，于是 coding agent 可以针对评估发现的问题自己循环修复，而人类开发者只需要在旁边验证进展。当所有评估都满足条件时，代码就可以合并——按 Entire 的说法，甚至不需要再看代码本身。

这里有三个设计选择值得拆开看。第一，评审从“一次性人工判断”变成了“持续的、可循环的评估”：agent 发现问题、agent 自己改、再评估，形成闭环，人在环中验证而不是在环中逐行劳动。第二，评审的原材料变了：Entire 明确说，它把开发者的想法、agent 的执行轨迹（trace）和会话结果都当作与代码并列的一等评审材料。这意味着评审对象不再只是“最后这段代码对不对”，还包括“这个 agent 是怎么想的、走了哪些弯路、有没有被纠正”。第三，放行条件是可配置的：团队可以要求人工签核，也可以要求 CI 通过，把“合并”从一个人的拍板变成一组条件的集合。

我的判断是：Trail 真正的赌注不是“agent 会不会审代码”，而是“评估本身可不可信”。如果评估写得好，Trail 能把评审从体力活变成判断活；如果评估写得差，Trail 只是把“没看懂就合并”包装得更体面。接下来任何团队在试用时，都应该先问四个问题：评估是谁写的、用什么标准、能不能被团队自己改写，以及当评估与人的直觉冲突时，以谁为准。官宣没有展开这些细节，这正是试用阶段最需要实测的部分。

分布式 Git 托管：“89 倍”先当厂商说法读

Entire 的第二个原语是分布式 Git 托管。它自称建立在与 Git 兼容的新源代码控制服务器之上，push 速度比 GitHub 快 89 倍、比 Cursor Origin 快 6 倍，并因此自称“当今生产环境中最快的 Git forge”。开发者可以在自己选择的区域创建、迁移和原生托管私有仓库，首批区域包括美国、欧盟、印度和澳大利亚，未来还会继续扩展。

这里必须把话说清楚：89 倍和 6 倍都是 Entire 自己的说法，官宣没有公布测试方法、仓库规模、网络条件或对比基线。在没有独立复测之前，任何负责任的报道都只能把它写成“厂商自测”，不能写成既定事实。但即便把数字打个折，方向本身仍然成立：当 agent 每分钟都在 push，Git 托管与 CI 的延迟就不再是边角成本，而是直接决定 agent 循环能转多快的基础设施。Entire 把“快”当作 forge 的核心卖点，而不是附加特性，这个优先级排序本身就是对 agent 时代的回应。

对实际使用者来说，更值得关注的其实是另外两点：区域选择与迁移路径。区域托管对有数据合规要求的团队是实打实的价值；而“可以从现有平台迁移私有仓库”则决定了试用成本有多低。一个新 forge 最难的从来不是功能列表，而是让团队敢把真实仓库放上去——迁移越顺滑，试用的门槛就越低。

Continuous Memory：记忆从聊天记录变成仓库资产

第三个原语 Continuous Memory 可能是三者中最容易被低估的一个。它的想法是：把 agent 会话同步进 Git 仓库，让这些数据持续可被 coding agent 搜索和使用。它由两个组件驱动：一是代码库图谱，帮助 agent 更快找到答案，官宣称最多可节省 71% 的 token（同样是厂商说法）；二是 agentic brain，把过往的 agent 会话与提示词变成一套持久的记忆系统，agent 可以查询并从中学习，从而不再重复犯同样的错误。

这个设计回应了一个每个用 agent 写过代码的人都遇到过的痛：换一个会话，agent 就忘了上次踩过的坑、忘了这个项目特有的约定、忘了为什么某段代码要那样写，只能重新试错。把记忆放进仓库，等于把“项目经验”从某个人的聊天记录里解放出来，变成团队共享的资产。对 vibe coding 的独立开发者尤其如此：你一个人就是整个团队，记忆系统就是你的“第二大脑”，它记得越多，你重复交的学费就越少。

但记忆一旦变成资产，也就变成了责任。第一，记忆会过期：三个月前的“正确做法”可能在今天已经是反模式，记忆系统有没有遗忘与纠错机制，官宣没有细说。第二，记忆会泄露：会话里可能包含密钥、内部接口、客户信息，把会话同步进仓库之前，哪些内容会被清洗、哪些权限能读到这些记忆，是必须先搞清楚的安全问题。第三，记忆会固化偏见：agent 从历史会话里“学习”到的也可能包括历史错误，所谓“不再重复犯错”与“把旧错误制度化”之间，只差一套好的纠错机制。试用时，别只测它记得多快，更要测它忘得多干净、错得多透明。

CI 集成：瓶颈已经从写代码移到了写代码之后

Entire 与 Buildkite、Depot 的集成值得单独一提，因为它点出了整件事的另一半。Depot 首席执行官 Kyle Galbraith 在官宣中的说法很直白：瓶颈已经从写代码转移到了写代码之后的一切环节。Buildkite 的首席执行官 Kevin Gounden 也强调，每一次改动在发布前仍然必须经过构建与测试，而今年整个行业都感受到了这种吞吐量呈指数级增长的压力。

具体做法是：开发者可以用 Buildkite 的 bk pipeline convert 转换已有的工作流，或者直接用 Depot CI，然后在 Entire 里订阅仓库；此后每次 push 都会触发构建，结果直接落进 Trail 里。也就是说，CI 不再是 Trail 之外的一个外部检查，而变成了 Trail 内部的一块证据。这对用户体验的影响很实际：评审时不用在两个系统之间来回跳转，构建失败与评估失败出现在同一个视图里，agent 修复的循环也因此更短。

对还在用 GitHub Actions 的团队来说，这个集成的意义是“迁移成本被摊薄了”：工作流可以转换，而不是重写。但同样要提醒一句：转换工具能覆盖多少复杂工作流、转换后有多少需要手工修补，只有在真实仓库上跑过才知道。官宣的承诺是方向，实测的结果才是依据。

对 vibe coder 与小团队意味着什么

先说一个可能反直觉的判断：Entire 这类产品，最先受益的可能不是大公司，而是小团队与独立开发者。大公司的评审流程里有合规、审计、权限分层等一整套既有制度，换 forge 是一次组织变革；而小团队的评审流程往往就是“作者自己再看一遍”，恰恰是 agent 产出过载最严重的地方。对小团队来说，一个能自动评分、能设 Gate、能把 agent 轨迹留档的 Trail，等于请了一个不知疲倦的初审员。

但“最先受益”不等于“立刻全量迁移”。我的建议是分四步走。第一步，先用镜像或非关键仓库试水：把真实项目镜像过去，让 Trail 在旁边跑，先看评估质量，再决定放行权。第二步，只读观察两周：记录评估误报与漏报各有多少，尤其关注安全类评估——误报可以忍，漏报不能忍。第三步，给 Trail 定 Gate：至少保留“CI 通过 + 人工签核”这一档，放在关键分支上，别一上来就开“评估全过即自动合并”。第四步，再谈记忆：先搞清楚会话同步的清洗规则与权限范围，再开 Continuous Memory，别让记忆先于治理上线。

还有一个更长远的判断。Entire 的出现标志着 Git 托管的竞争维度变了：过去比的是界面、集成与生态，现在比的是“谁更懂 agent 的工作方式”。GitHub、GitLab 不会坐视这个维度被重新定义，类似的评估式评审、记忆系统迟早会出现在各家产品里。Entire 的先发优势不在于某一个功能，而在于它从第一天起就是为 agent 与人协作而设计的——没有历史包袱，也没有“先兼容旧模式”的妥协。但先发优势能不能变成持久优势，取决于它能不能在公开仓库、自托管节点这些仍在路线图上的能力落地之前，先把评估可信度这件事做实。

还没回答的问题

官宣留下了至少五个值得追问的问题。第一，定价：官宣没有公布价格，免费额度与团队价格会直接决定小团队能不能长期用下去。第二，公开仓库与自托管节点的上线时间：没有公开仓库，Entire 目前还不能承接开源协作场景；没有自托管，对合规敏感的团队也还差一格。第三，评估的可定制性：团队能不能自己写评估、能不能接入自己的安全规则、评估结果能不能被审计。第四，slop 的定义权：谁来定义什么是低质 AI 内容，误判的申诉路径是什么。第五，厂商性能数字的独立验证：89 倍、6 倍与 71% 都需要第三方在公开条件下复测。

这些问题没有一个是否定 Entire 的理由，但每一个都决定了它适合谁、先用在哪。真正值得兴奋的不是“Pull Request 已死”这类口号，而是评审正在从“人读 diff”变成“人审证据”。如果这个转变成立，未来的代码评审会越来越像飞行员看仪表：你不一定需要亲手摸过每一个零件，但你必须确信仪表本身是准的。Entire 的 Trail 就是往这个方向迈出的第一步，而仪表准不准，需要接下来几个月里每一个试用者的实测来回答。

补背景：从 Checkpoints 到 Git Forge

Entire 不是凭空出现的名字。今年 2 月，它先推出了开源工具 Checkpoints：把 AI 编码 agent 的提示词、决策与会话历史连同代码改动一起记录下来，让“agent 当时为什么这么改”有据可查。同月披露的种子轮是 6000 万美元、估值 3 亿美元，微软风投 M12 亦在投资方之列——这解释了为什么一家尚未公开完整产品的公司，能在 10 月 26 日直接以“GitHub 的替代品”姿态登场。托管层面，Entire 目前提供美国、印度、澳大利亚与欧盟四个区域的仓库托管，公开仓库与自托管节点仍在路线图上，这是它现阶段最明显的短板：开源协作场景与合规敏感团队都还得再等等。还有一个值得放在语境里的数字：GeekWire 在官宣报道中提到，GitHub 仅 2026 年 9 月一个月就产生了 73.8 亿次提交——agent 带来的写入洪峰，正是 Entire 拿“分布式 Git 托管”做文章的现实背景。但背景不等于证据：89 倍、6 倍与 71% 这三个数字，至今仍是 Entire 自己的说法，在第三方公开复测之前，都应该被当作“待验证的厂商数字”来引用，而不是既定事实。

再补一笔：为什么是现在

Entire 选在 10 月 26 日公开，还有一层时间上的讲究：两天之后就是 GitHub 的年度 Universe 大会（10 月 28 日至 29 日），而整个 2026 年，agent 带来的负载已经让 GitHub 几次出状况——GeekWire 提到其中一次 8 月的故障持续了近 8 小时，IncidentHub 的统计则称 GitHub 在 2025 年 5 月至 2026 年 4 月间共记录了 257 起事故。Entire 并不是第一个想重做代码托管的挑战者：Cursor 早在 8 月就推出了自己的代码托管服务 Origin，Entire 官宣里“比 Cursor Origin 快 6 倍”的说法，正是对着这个直接对手去的。把这些放在一起看，Entire 的真正赌注就清楚了：它赌的不是某一个功能更强，而是 agent 写代码的速度会继续快下去，以至于“人逐行读 diff”这个模式本身必须被换掉。如果这个判断是对的，评审工具的竞争才刚刚开始；如果判断错了，Entire 也不过是又一个在 GitHub 阴影下讲新故事的挑战者。接下来几个月，看它能不能拿出公开仓库、自托管节点与第三方复测的性能数字，比看它今天的口号更有用。