Entire：前 GitHub CEO 想用 Trails 取代 PR
前 GitHub CEO Thomas Dohmke 的 Entire 推出独立 Git 托管平台，用 Trails 取代 PR，另有 Continuous Memory；速度和省 token 的数字都是官方自报的上限。
10 月 26 日，一家叫做 Entire 的公司，发布了一个新的 Git 托管平台。
它的 CEO 是托马斯·多姆克（Thomas Dohmke），以前是 GitHub 的 CEO。
前 GitHub CEO 出来做一个 GitHub 的竞争对手，这件事本身就很有看点。（GeekWire 的标题就是这么写的。）
不过，我更感兴趣的不是人，而是它想换掉的那样东西----Pull Request（简称 PR）。
大家猜猜看，一个做了多年代码托管的人，为什么觉得 PR 不行了？
PR 的前提
用过 GitHub 的人，应该都提交过 PR。
它的流程很简单：你改了代码，提交一个合并请求，同事看一遍代码差异（diff），觉得没问题，就合并进主干。
这套流程有一个隐含的前提：代码是人写的。
人写代码不快，人看代码也不快，两边的速度差不多，所以能配合起来。
但是，现在情况变了。
越来越多的代码是 coding agent 写的。agent 写代码的速度，远远超过人看代码的速度。
结果就是，写代码不再是瓶颈，看代码变成了瓶颈。
多姆克在 X 上说过一句话，经济时报转引了：
Agents reinvented how we produce code... It's time for the other half to catch up.
大意是，agent 已经改造了生产代码的方式，现在轮到另一半跟上了。
所谓"另一半"，就是代码写完以后的那些事：评审、测试、合并、托管。
Entire 这次发布的三样东西，正好对应这几件事。
Trail：评审对象变了
第一样东西叫做 Trail，用来替代 PR。
官方把它比作飞行员的平视显示器（heads-up display），也就是一个驾驶舱。
它和 PR 的区别，可以这样理解。
PR 让人看 diff，逐行判断改得对不对。
Trail 让 agent 按照团队自定义的 eval（评测）给每次 push 打分，人看的是分数和进度。
按照官方新闻稿的描述，流程大致是这样的：
1、coding agent 写完代码，push 上去。
2、agent 按照自定义的 eval，给这次改动打分。
3、打分数据可以通过开源的 Entire CLI 读取。
4、coding agent 读到没通过的项，接着修改，再 push，再打分，形成一个循环。
5、人只负责验证进度。eval 全部通过，就可以合并，不必逐行看 diff。
另外，据投资方 Madrona 的文章，一个 Trail 可以跨多个仓库。
Entire 的说法是，把"意图、agent 轨迹、结果"当作一等公民来评审。
翻译成大白话就是：评审的对象，从代码本身，变成了这次改动想达到什么、agent 是怎么做的、最后做成了没有。
我觉得，这是整件事里最核心的变化。
托管为什么也要重做
如果只是换掉 PR，似乎不需要自己再做一个 Git 服务器。
但是 Entire 做了。
官方称，它自研了一个兼容 Git 的服务端，push 比 GitHub 快至多 89 倍，比 Cursor Origin 快 6 倍。
为什么要这么快？
道理不难想。人 push 代码，一天也没几次，慢一点无所谓。agent 不一样，它可能不停地 push、拉取、再 push，每一次都要等，等待就会累积起来。
Madrona 的文章还引用了 Entire 的开源基准 ForgeMark：单个仓库约 57 万次 clone/小时、586 次 push/秒。
这里需要提醒一下。
这些数字全部来自 Entire 自己和它的投资方，我没有看到第三方的独立测试。"至多 89 倍"里的"至多"两个字也值得留意----它说的是最好的情况，不是平均情况。
另一个实用的细节是数据放在哪里。官方说，私有仓库可以放在美国、欧盟、印度、澳大利亚。经济时报那篇报道的标题，突出的就是印度数据托管。
对于有数据合规要求的公司来说，这一点可能比速度更重要。
Continuous Memory：别让 agent 重复犯错
第三样东西叫做 Continuous Memory（持续记忆）。
它把 agent 的 session 和 prompt 同步进 Git 仓库，变成仓库的一部分。
上面有两个组件。
一个是代码库图谱（entire-graph），官方称最多可以省 71% 的 token。
另一个是 agentic brain（entire-brain），把历史会话变成可以查询的记忆，避免 agent 重复犯同样的错。
这个思路，我觉得是对的。
现在的 coding agent，每开一个新会话，基本都是从零开始。上一次踩过的坑，这一次可能再踩一遍。
把会话记录放进仓库，就好比给项目配了一本工作日志。新来的人（或者新来的 agent）先翻一翻日志，就不用把老问题再问一遍。
当然，71% 同样是官方自报的上限，具体能省多少，要看项目本身。
CI 和迁移
代码 push 得快了，构建和测试也得跟上。
官方新闻稿点名的 CI 合作伙伴是 Buildkite 和 Depot（Madrona 的文章里还多提了 CircleCI）。原来的 GitHub Actions 工作流，官方说可以用 Buildkite 的 bk pipeline convert 转换，或者交给 Depot CI。
如果你的代码现在放在 GitHub，可以先镜像（这是 7 月那次发布就有的功能），也可以这次直接整个迁过来。
官方列出的后续计划包括：自托管 Git 节点、公开仓库、会话直播，以及更多集成。
既然公开仓库还在路线图上，我的理解是，它眼下主要面向私有仓库，开源项目暂时还用不上。
融资和团队
顺便说一下钱的事。官方新闻页的背景介绍只写了两句：Entire 今年 2 月融了 6000 万美元，称是开发者工具史上最大的种子轮；团队有 50 人。
网上流传的估值和投资方名单，官方页面没有写，这里不转述。Madrona 在自己的文章里说，它是第一家确认投资的机构。
几个疑问
读完这些资料，我有几个疑问，暂时没有答案。
（1）eval 是整个 Trail 的地基。如果 eval 写得不好，"全部通过"就没有多大意义。那么，eval 本身由谁来把关？
（2）"不必逐行看 diff"，对于普通的业务代码也许可行。但是，涉及安全和权限的改动，大概还是需要有人逐行看。在我读到的官方材料里，没有看到怎么区分这两种情况。
（3）开发者已经习惯了 GitHub 的整套生态。换一个平台，团队的迁移成本有多大？
这些问题，可能要等更多团队真正用起来，才能知道答案。
小结
Entire 押注的是一个很简单的判断：当代码主要由 agent 来写，评审的方式也必须跟着变。
PR 诞生的时候，代码是人一行一行敲出来的。现在不全是了。
它能不能成功，现在下结论还太早。但是，这个问题提得很对。
如果你的团队已经大量使用 coding agent，PR 积压成了日常，不妨关注一下它。
（完）
来源：Entire 官方新闻；Madrona 文章。89 倍、6 倍、最多 71% 为官方自报；ForgeMark 数据据 Madrona 引用；融资只写官方新闻页提到的 2 月 6000 万美元种子轮与 50 人团队，网传估值与投资方名单未见官方确认，不采用；“眼下主要面向私有仓库”为作者推断。