本文目录
Agent 写代码的速度，往往超过团队决定「能不能合」的速度。有用的问题不是「某家 forge 会不会一夜取代 GitHub」，而是：谁决定 merge——AI 审查分数、CI 门槛、人工批准，还是三者组合。2026 年 10 月 26 日，Entire（CEO／联合创始人 Thomas Dohmke）据此打开一座独立 Git forge。官方称 今天起对所有开发者可用。下文按 截至 2026-10-27 的发布新闻与工作流博客整理；本站未对 GitHub、GitLab 或 Cursor Origin 做对照实测。
站内 AI 审查费用近文：CodeRabbit：至 11 月 8 日组织 Deep Scan 用量最高覆盖 $5,000（总额 $1M）。
Trails 和 PR：页面上到底换了什么
经典 Pull Request 以 diff 为中心：评论沿时间线堆叠，CI 状态靠近合并按钮，人（以及越来越多的审查机器人）在线程里争论。Entire 博客的论点是：当 Agent 写了大部分改动，这条时间线更像给 Agent 回读的审计日志，却仍难给开发者一个清晰的「够稳可以合了吗？」信号。
Trail 是 Entire 的替代 HUD。官方材料把它写成把需求、会话痕迹、代码变更与审查放在一起——更像飞行员仪表板，而不是线性评论流。工作流博客里的三步：
- 开 Trail。 可在 Entire 上从缺陷／需求起，也可从 Agent 在实现前或实现后起——精神上类似「准备推代码时开 PR」。一条 Trail 可跨多个仓库，把相关改动收在一起。
- 每次推送打分。 审查 Agent 跑可定制 evals，各自给出分数与理由（Entire 用花样滑冰评委作比）。Entire 称自家许多仓库启用 Security、Slop、Human Review Required 等 eval；展示最近 5 次＋当前，便于看出单次噪声。
- 清 findings，再合并。 Agent 可返回带严重级别与建议修复的 findings。未解决项始终可见；已解决可隐藏但可找回。Agent 或人都可以处理或 dismiss。人仍可像在 PR 里一样发 findings／评论。
开源 Entire CLI 参与闭环：编码 Agent 可按 findings 改完再推，人验证进度。这是产品口径摘要，不是「从此可以永远不看高风险 diff」。
博客写明审查 Agent 底层可用 Claude Code、Codex 等，并在 Daytona／E2B 一类隔离沙箱中跑。下文只记为 Entire 官方说明的审查栈，不写成站内对这两款工具的评测背书。二者价格与用量对照见：Claude Code 和 Codex 该选哪个？价格和用量限制比一比。
Gates：分数、测试、人工批准各管什么
Gates 是合并策略层。Entire 称可按仓库启用，并可要求（举例）：
| 控制项 | 通常回答什么 | 单独回答不了什么 |
|---|---|---|
| AI 评测分数／findings | 审查 Agent 是否标了 Slop、Security、「需要人看」？未解决 findings 是否已清或 dismiss？ | 是否符合团队威胁模型？分数是信号，≠安全保证。 |
| CI（Buildkite／Depot） | 这次推送的构建与测试是否通过？ | 测试是否覆盖关心的失败模式？绿灯 CI ≠ 证明正确。 |
| 人工批准 | 是否有具名的人接受剩余风险？ | 批准人是否真读了高风险路径？批准是问责，不是全知。 |
说白了：分数看 Agent 审查回路是否趋稳；CI看自动化构建／测试是否仍过；人工批准是「有人拥有这次合并」的开关。Entire 的说法是：信心够、风险低、findings 清完再合——而不是要求人把 Agent 写的每一行 diff 再读一遍。这套策略是否适合受监管或高风险仓库，只能团队自己定。
这也解释了为何不写恐吓标题。给 Agent 产出打分并设合并门槛，回答的是流程问题——人读不过来每一笔 Agent 提交时，怎么继续发版。它既不是「现有托管已经过时」的证明，也不是在弄清 Buildkite／Depot 转换是否适配 secrets 与 runner 舰队之前，就拆掉 GitHub Actions 的理由。
GitHub 侧权限与合并相关近文：GitHub Copilot Assisted Permissions 正式 GA。
Buildkite 与 Depot：CI 如何进 Trail
Entire 与 Buildkite、Depot 合作，让构建／测试跟上 Agent 推送节奏。官方工作流要点：
- Buildkite： CI 配在项目级（常跨多仓共用）。接通后每次推送在 Buildkite 或自有基建上构建；结果作为 Trail 上的 check；失败可挡合并。Agent 可通过 Buildkite API／CLI／MCP 闭环。GitHub Actions 用户可用
bk pipeline convert转换工作流，无需整份重写。 - Depot： Depot CI 定位为跑兼容 GitHub Actions 的工作流、中间不必经过 GitHub。从 Entire 接通后，
depot ci migrate发现 Actions 工作流并提升为 Depot CI，标出需人工复核项；配套命令可导入 secrets／变量。
两条路径都是「CI 作为与 Agent findings 并列的门槛」，不是「CI 取代人的判断」。本站暂时还没有测试 Entire 的 CI 延迟或迁移成本。
托管边界：今天私有仓，公共仓与自托管在后
按读到的发布材料：
- 可在 Entire 上创建、迁移并原生托管私有仓库。
- 现网区域：美国、欧盟、印度、澳大利亚（官方称还将扩展）。
- 可从 GitHub 镜像并保留 GitHub 为真相源，或 迁移（美国镜像场景可 Detach；或
entire-migrate插件；或本地 fetch／push）。 - 公共仓库与自托管 Git 节点写在后续／Road Ahead——不按发布日已全面可用处理。
对开源维护者与需要本地 Git 节点的企业：这次发布明确是私有仓优先。不要只凭这两页就规划公共 forge 切流。
若先试用又不想立刻搬家，镜像值得细读。Entire 描述：授权 GitHub App、选仓与区域，甚至可在保留 GitHub 为真相源的同时，在 PR 之上使用 Trails。博客称服务中断时 Entire 仍可从区域镜像提供 clone／fetch，Agent 可向带 entire/unmirrored/ 前缀的 Entire 原生分支推送，直到 GitHub 恢复。这是 Entire 的运维说明，不是本站做过的可用性实测——但足以分清「试用 Trails」和「离开 GitHub」不是同一决定。
厂商速度与记忆宣传
新闻与博客推广两组下文 不会写成站内测速／审计结论的数字：
- 推送速度： 最高约比 GitHub 快 89×、比 Cursor Origin 快约 6×，并附开源基准表（Entire 418 pushes/sec vs GitHub 4.7、Cursor 65 等）。这是厂商自报／厂商开源基准。
- Continuous Memory： 由 entire-graph（代码图谱）与 entire-brain（会话记忆绑到图谱）支撑。Entire 称 graph 在其测试中最多约节省 71% token。同样：厂商宣传，不是本站做过的 token 审计。
Continuous Memory 作为产品思路值得理解——会话与提示同步进仓库，减少 Agent 每次新开上下文窗口的重复学习——但 71% 须标成 Entire 自测。两篇主源也还没有核到套餐价、席位费或 CI 按秒计费总额。本文不做购买、迁移或离开 GitHub 的建议。
选型合并流程时，怎么读 Trails
若痛点是「Agent 开 PR 比审查人跟得上还快」，Trails 对准的是那个瓶颈：评测分趋稳、findings 清完、CI 绿灯，再由人批准。若痛点是公共开源贡献、自托管合规，或要一张带价的迁移表，发布页把这些问题留白——本站也不会编造答案。
即使尚未采用 Entire，也能先跑的清单：
- 拆开三项合并控制。 写下组织已要求：自动审查 findings、CI 绿灯、具名人工批准；今天哪些失败会挡合并。
- 先定义「分数」含义。 若启用 Agent eval（在 Entire 或其他处），约定橙色 Slop 是「Agent 继续改」还是「人必须看」。没有门槛策略的分数只是仪表盘，不是安全。
- 别把安全审查只交给分数。 把 Security eval 当分流；高风险路径、密钥、鉴权仍需人或专项审查。AI 审查分数 ≠ 代码安全保证。
- 托管要匹配仓库形态。 私有多区域可能合适；公共开源与自托管节点现阶段可能还不行。
- 推送加速与省 token 幻灯片先当营销。 若数字影响预算，用自己的推送与 token 基线测。
对于 Entire 的推送延迟、Continuous Memory 的 token 节省、CI 迁移成本，以及日常 Trail 审查质量，本站暂时还没有测试；反馈可通过网站底部的站长联系方式提交。