在 Entire 上走一遍 Trail：agent 在哪几步介入，人在哪几步拍板

10 月 26 日，前 GitHub CEO Thomas Dohmke 创办的 Entire 推出了自己的 Git 托管平台，定位是给人和 agent 一起写代码用。它有三块：叫 Trail 的评审方式、分布在多个地区的 Git 托管、把 agent 会话存进仓库的 Continuous Memory。¹新闻标题里最显眼的是“推送速度是 GitHub 的 89 倍”，但对每天合代码的人来说，更该看懂的是 Trail：它把 PR 换成了什么，一次改动要经过哪几步，agent 在哪一步动手，人在哪一步拍板。

一次改动在 Trail 上走七步

博客没有给出一条按顺序排好的流程，下面这七步是我对照博客和官方文档拼出来的。¹²

① 开一个 Trail。 Trail 可以从一个 bug 报告或需求开始，也可以由 agent 在动手前后直接开；一个 Trail 可以跨多个仓库。¹命令行是 entire trail create --title "..."，刚开的 Trail 处在“Planning”阶段，还没挂任何分支；之后用 entire trail link 把已经推到远端的分支挂上去，每个分支算一个“改动”。²

② 编码 agent 写代码、推送。 提交时，Entire 会问要不要把这次提交和 agent 的会话关联起来。³关联后，会话和提示词随代码一起存进仓库，Continuous Memory 让以后的 agent 能搜到当时为什么这么改。¹

③ 评审 agent 打分。 这是 Trail 和 PR 最大的不同。每次推送都会触发项目里配置好的评审 agent，每个 agent 在自己的云沙箱里独立跑，交回一个分数和理由，并列出问题（finding），带严重程度和修复建议。¹预设的评审有代码质量、安全和“slop”（agent 写出的敷衍代码）三类，也可以自定义。分数每次推送重算，页面上显示当前一次和之前五次。²

②↔③ 分数低就再改再推。 分数不好，开发者可以让编码 agent 接着改、接着推，直到分数上来；博客也承认要来回好几轮才稳定。¹推送之后，旧的问题可能变成“过期”，但过期不等于解决，要有人或 agent 明确解决或忽略。²

④ 人看结果。 人在 Trail 上看分数、理由和问题，可以自己补评论和问题，也可以解决或忽略 agent 提的问题，再给出批准。¹

⑤ CI 构建。 每次推送在 Buildkite、Depot 或自己的机器上构建，结果作为检查项显示在 Trail 上，构建失败会拦住合并。¹

⑥ 闸门。 每个仓库在 Settings → Gates 里定合并条件，可以要求分支是最新的、有人批准、问题清零、CI 通过。²

⑦ 合并。 改动满足条件后，人点 Merge。每个改动单独合并，合了一个不会顺带合掉同一 Trail 里的其他改动。²

agent 管写和审，人管开票、批准和合并

按上面七步数一下，agent 介入的是三个节点：写代码并推送（②）、评审打分（③）、按评审意见修改（②↔③ 的循环）。它还可以通过 Buildkite 的 API、命令行或 MCP 去驱动 CI。¹人拍板的也是三个节点：开票定目标（①，agent 也能开）、处理问题并批准（④）、点合并（⑦）。中间的 CI 和闸门由平台按规则执行。

这和传统 PR 的分工差别在评审对象上。PR 让人逐行看 diff；Trail 先让多个 agent 把 diff 看一遍、折算成分数和问题清单，人看的是这份清单和分数的走势。人的工作量从“读每一行”变成“判断哪些问题必须修、哪些可以放过”。本地的 entire review 也是这样：几个评审 agent 加一个裁判 agent 给出汇总结论，人来定哪些是阻塞项。³

两点要留意。第一，人工批准只在闸门要求时才必需，没设这道闸门，就不需要人批准。²要让人拍板，团队得自己把这道闸门配上。第二，仓库仍放在 GitHub、只把 Entire 当镜像时，合并和 CI 由关联的 GitHub PR 负责；Entire 的批准和 GitHub 的批准互不承认，Entire 的闸门过了，GitHub 的分支规则照样可以拦住合并。²

89 倍和 71% 先当厂商数字看

89 倍来自 Entire 自己的表：每秒推送次数 Entire 418 次，GitHub 4.7 次，比值约 89。¹测试工具 forgemark 开源了，它的做法是很多个模拟 agent 各自往自己的引用上反复推送小提交（默认每次 1 到 10 个文件、每个 2KB），测的是高并发下的推送吞吐。⁵仓库页面没有附结果，也没写测试地区和次数。这个数说明 Entire 能扛住大量 agent 同时推送，不代表一个人日常推代码会快 89 倍。

开源的代码图谱插件 entire-graph 称最多能省 71% 的 token，仓库自己写着“视场景而定”；同一页面还报告，把图谱结果注入首个提示词时 token 基本持平（+0.7%）。⁶Tech Times 的报道则提醒，公开仓库、自托管和企业版都还没上线，这些数字也还没有第三方复现。⁴

数据团队可以先借走“推送就评分”这一步

PR 门禁等于“agent 评分加人工批准加 CI”，这套做法不必等迁到 Entire 才能用。dbt 项目和数据管道的仓库，今天就可以在每次推送时跑一组评审 agent，让它们输出分数和问题清单，再把“问题清零”写进合并条件。我在 Snowflake 管道修复 agent 那篇里说过，agent 的终点应该是一个可以审、可以撤的 PR；Trail 把这一步往前推了一格，连“审”也先交给 agent 做一遍。代价要先算清：每次推送都跑一轮评审，第一个月记下每次评审的花费和被人忽略的问题比例。