research-blog/content/posts/agent-first-git-platforms.md at bf356eaf5aebf80d36a1f3d64ae7f975a3269fea

wuyang/research-blog

Fork 0

Files

T

wuyang6 bf356eaf5a feat: publish agent-first git platform research

2026-08-14 11:32:41 +08:00

39 KiB

Raw Blame History

title, summary, date, updated, topic, tags, kind, status, visibility, canonicalUrl, sourceRepo, preview

title

summary

date

updated

topic

执行摘要

截至证据截止日，没有一家被公开证据证明已经达到完整的 L3“受治理的 Agent 工作流”，更没有 L4“Agent-first 控制面”。GitHub.com、GitLab.com / Self-Managed 与 Bitbucket Cloud 可以保守归入 L2“Agent 已进入官方开发路径，但闭环仍有断点”；其余所查变体是 L1“可扩展 Git 基座”。这里的 Level 表示同一条 任务 → 运行 → Git 变更 → 当前提交验证 → 语义审查 → 独立授权 → 失败恢复 控制链的证据强度；它既非厂商评级，也不按功能数量计分。

三条最重要的结论是：

GitHub.com 的 Agent 体验与公开可观察性最完整，但治理闭环没有随之自动成立。 Copilot cloud agent 能接任务、在隔离环境工作、提交 PR、接受 Review 并继续修复；GitHub 也有 Rulesets、CODEOWNERS、required checks 与 merge queue。不过 Copilot code review 只产生 COMMENT，不等于批准，也不能阻止合并。公开参考 PR 没有证明独立 human approval 或 required policy 真正约束了该次合并，因此止于 L2。
GitLab 的优势是把 Agent 放进更完整的 DevSecOps 与自托管治理面。 它的公开 MR 工件能连起 Duo 身份、失败 pipeline、新 revision、merged result（目标分支与当前 source head 临时合成的候选 revision）、独立批准、merge train（排队并对候选合并 revision 重跑检查）和合并，治理证据比 GitHub 参考链更强；但规则 revision 收据、sandbox fail-open、runner flow 不受统一 tool governance 覆盖、停止后不能恢复以及 AI audit 默认不完整，使 GitLab.com 19.2 与 Self-Managed 19.2 同样只能保守记为 L2。
内置 AI 与强治理是两条轴。 Bitbucket Cloud 的 Agent 能力分散在 Jira Coding Agent、Agentic Pipelines beta、Rovo Dev 与 Premium merge checks；Azure Repos 的 Boards Coding Agent 实际把代码写到 GitHub；Gitea / Forgejo 没有同等内置 Coding Agent，却能提供 current-head checks、受保护分支与独立审批的强骨架。选择平台时，应先问“哪些硬门由服务器强制”，再问“Agent 能做多少”。

给不同团队的条件式建议：

云优先：以 GitHub.com 与 GitLab.com 做双候选试点。重视 Agent UX、生态和异步编码入口，优先验证 GitHub；重视一体化 CI/安全/审批与更清晰的人机复合身份，优先验证 GitLab。Atlassian 深度用户可把 Bitbucket Cloud 纳入试点，但要接受多产品、多个生命周期和 Premium 治理的拼接成本。
企业治理 / 自托管：GitLab Self-Managed 是目前最接近“Agent + Git + CI + 治理同平台”的候选，但不是开箱即闭环；采购前必须用目标 tier、runner、AI Gateway/Workflow Service、网络和审计配置实测。Bitbucket Data Center、Azure DevOps Server、GitHub Enterprise Server（GHES）是治理基座，不应把各自 SaaS Agent 能力继承过来。
开放自管：Gitea 1.27.2 + 官方 Gitea MCP + Runner 2.0 是本次证据最完整的开放组装骨架；Forgejo 16.0.1 也有扎实的 Git 硬门与 Actions，但 Agent 工具面与完整审计需要更多自建。两者都需要外部任务调度、Agent runtime、不可变审计和恢复演练。

采购的停止条件很明确：S4 变更身份、S5 当前 revision 的确定性证据、S7 独立授权 中任何一项不能在目标配置的试点中关死，就不要把它命名为 Agent-first 生产闭环。图 1 展示了这三个硬门在完整控制链中的位置。

图 1｜Agent-first 开发控制链：Agent 可以执行，但当前提交证据与独立授权必须由确定性规则和独立主体闭合。

一、比较对象：从 AI 功能转向控制权

“Agent-first”容易被误解成 Copilot、Duo、Rovo 或 MCP（Model Context Protocol，模型上下文协议，让 Agent 用统一接口调用外部工具）的功能清单。变化发生在责任边界：Agent 不再只在 IDE 里给出建议，而是开始接收异步任务、操作工具、修改多文件、运行测试、提交分支与 PR，并在失败后继续工作。此时 Git 平台从代码仓库升级成了变更身份、确定性证据和授权策略的交汇点。

OpenAI 的 Harness Engineering 实践把仓库可读性、规则、反馈循环与工程环境视为 Agent 有效工作的前提；公开的 Symphony 规范与源码进一步把 Issue tracker 作为任务控制面、每个 Issue 的 workspace 作为执行单元、GitHub PR 作为变更交付面。它也提醒我们：任务控制面可以在 Git 平台之外，Git 平台却仍必须对变更和授权负责。

本研究因此把一次 Agent 开发拆成八个阶段：

阶段	必须留下的工件	主要风险
S1 任务进入	task ID、触发者、验收条件、目标仓库	任务只存在于不可追踪的聊天
S2 上下文与规则	仓库版本、指令版本、权限与依赖边界	不知道 Agent 读了哪一版规则
S3 隔离执行	workspace/sandbox、网络、secret、运行日志	与其他任务共享状态或权限过大
S4 Git 变更身份	branch、commit、PR/MR、human/agent actor	变更不能归属到唯一 Git 对象
S5 确定性证据	当前 head 的测试、构建、安全检查与 artifact	旧绿灯掩盖新提交失败
S6 语义审查与修复	Review、finding、修复 commit、未解决项	Agent 自审自批或 Review 不跟新提交
S7 独立授权	approval、CODEOWNERS/policy、queue/train	Agent 能绕过规则或自批自并
S8 反馈、审计与恢复	retry、trace、成本、发布/回滚、最终状态	失败后重新开会话，证据链断开

其中 S4、S5、S7 是硬门，不能靠其他功能平均抵消。SLSA v1.2 provenance强调结果必须能关联到生成它的输入和过程；同理，PR 页面上“有绿色检查”比“规则要求针对当前 revision 的检查通过”弱得多。OpenAI 的 Codex 安全实践也把 sandbox、权限批准、网络控制、身份与可观察性拆成独立控制，而不是用一个安全开关代替。

本研究怎样定级

L1 可扩展 Git 基座：有 Git/API/runner/保护规则，但 Agent task/runtime 或某个硬门要靠客户自建。
L2 Agent 已进入官方路径：至少任务、上下文、执行、Git 变更有官方连续路径，但 current-head、独立授权或恢复仍有明确断点。
L3 受治理的 Agent 工作流：S1–S7 都有可追踪工件，关键硬门无缺口，同一任务的变更、检查、Review 和授权连续。
L4 Agent-first 控制面：S1–S8 全部闭合，并有同一任务从失败到恢复、再到独立授权的直接复现证据。

我们把产品页/公告记为 E1，把官方规范、文档、源码记为 E2，把公开 PR/MR、pipeline、checks 与 API 工件记为 E3；只有本次受控运行才是 E4。本文没有 E4，因此不会把“公开可核对”写成“已复现”。

二、总体判断：三家到 L2，没有一家被证明到 L3

产品变体	截止日判断	已证实的最强部分	阻止升级的主要断点
GitHub.com / Enterprise Cloud	L2	原生 Agent 任务→隔离运行→签名 commit→PR；Actions、Rulesets、CODEOWNERS、merge queue	公开 Agent 链未证明独立 approval / required policy；S8 无部署回滚连续证据
GitLab.com 19.2	L2	Duo→MR；composite identity；merged results、approval、merge train；公开失败恢复工件	规则 revision 不可见；sandbox 可 fail-open；runner flow 治理与 AI audit 连续性不足
GitLab Self-Managed 19.2	L2 能力上限	与 SaaS 相近的 Agent/CI/治理面，可 online/hybrid/offline 组装	runner、AI 服务、网络、许可、模型与审计都转为 operator 责任；无目标实例收据
Bitbucket Cloud	L2	Jira Coding Agent、Agentic Pipelines、Rovo Review、Premium enforced checks	多产品/多订阅/多生命周期拼接；Agentic Pipelines 为 beta；审计与数据边界有缺口
Azure DevOps Services / Azure Repos	L1	MCP、Pipelines、branch policies、Copilot Review preview	Boards Coding Agent 明确只写 GitHub；Azure Repos 原生 task→Agent runtime 未证实
GitHub Enterprise Server 3.21	L1	Rulesets、required checks、CODEOWNERS、merge queue、Actions、审计	Copilot cloud agent / Agentic Workflows 同构路径未证实；runner 与 MCP 自建
Bitbucket Data Center 10.4.2	L1	service account、latest-head build、approval、merge-result queue、审计	Coding Agent / Rovo Cloud 不继承；Agent 与语义修复外置；管理员 queue bypass 默认需关闭
Azure DevOps Server	L1	REST/hooks、Pipelines、build/status/reviewer policies	官方 MCP 不支持 on-prem；Agent runtime、隔离与统一审计自建
Gitea OSS 1.27.2	L1	官方 MCP、ephemeral runner、required scoped workflows、current-head approval gate	task orchestrator、LLM runtime、完整 audit/recovery 外置；无同链 E3/E4
Forgejo 16.0.1	L1	Actions、current-head required status、approval/stale-review gate、开放 API	官方 Coding Agent/MCP 未证实；S1/S6/S8 主要自建；无同链 E3/E4

这些限定条件比排名更重要：GitHub 与 GitLab 的 S5/S7 能力在正确配置下可以很强，但“平台支持”不等于“目标仓库已经这样配置”。Bitbucket Cloud 的强制 merge checks 依赖 Premium；GitLab 的 required approval/merged results/merge train 依赖 Premium/Ultimate 及严格配置；自托管平台的隔离和审计则取决于 operator 实际部署。

生命周期按全部产品变体统一列示；GA（General Availability，正式可用）、Preview/Beta、稳定版本和“未核验”不能相互继承：

产品变体	截止日生命周期 / 边界
GitHub.com / Enterprise Cloud	Copilot cloud agent 核心 GA，code review 核心 GA、部分增强仍为 preview；Agentic Workflows 为 public preview
GitLab.com 19.2	Agent Platform、Developer Flow、Code Review 与 Fix Pipeline 主链 GA；Breaking Change Flow 和 AI audit report 为 Beta
GitLab Self-Managed 19.2	与上行沿用同一产品生命周期标签，但可用性还受 tier、entitlement、runner 与 AI 部署配置约束；本次未核验任何目标实例
Bitbucket Cloud	Jira Coding Agent 有正式文档，本次未找到独立 lifecycle 标签；Agentic Pipelines 为 open beta，Rovo Dev Code Reviewer 已 GA
Azure DevOps Services / Azure Repos	Boards→GitHub coding agent 集成已 GA，但不支持 Azure Repos；Azure DevOps MCP 为本地 GA、remote public preview，Azure Repos Copilot Review 为 limited public preview
GitHub Enterprise Server 3.21	3.21 是本文版本基线；GitHub-hosted runners 不可用，cloud agent 同构链未核验，官方 remote MCP 不支持 GHES，因此官方 Agent 链生命周期记为未核验
Bitbucket Data Center 10.4.2	10.4.2 是截止日当前 GA 版本；Cloud 的 Coding Agent、Agentic Pipelines 与 Rovo 不继承，Data Center 原生 Agent 生命周期未核验
Azure DevOps Server	当前产品线与 Patch 7作为版本基线；Services MCP 明确不支持 on-prem，官方 Agent runtime 生命周期记为未核验
Gitea OSS 1.27.2	1.27.2 为截止日签名稳定版本，官方独立 Gitea MCP 1.6.0 已发布；core 内建 MCP 仍是开放 proposal，官方 Coding Agent 未核验
Forgejo 16.0.1	本文 tag-bound 治理源码样本为 16.0.1；截止日当前 stable patch 为 16.0.2、LTS patch 为 15.0.6；官方 Coding Agent / MCP 截止日未核验

图 2 将“Agent 集成深度”和“Git 治理强度”拆成两条轴，避免把内置 AI 多直接等同于治理闭环强。

图 2｜平台定位：横轴表示 Agent 集成深度，纵轴表示当前提交验证与独立授权等治理能力。

三、GitHub：Agent 体验领先，授权证据没有自动跟上

一条接近参考任务的公开链

GitHub 官方组织的公开仓库给出了一条很接近“升级依赖 + 适配行为 + 测试”的真实链：

Agentic Workflow 的 go-fan.md 定义 schedule / manual trigger、只读工具、网络 allowlist、safe output 与 timeout，并编译为标准 Actions workflow。
它创建 Issue #10970，要求将 OpenTelemetry 从 v1.44.0 升级到 v1.45.0，处理 semantic-convention 与 SDK lockstep 风险并运行测试。
Copilot 创建 PR #11060，以连续 commits 逐步完成 plan、implementation、verification 与 review feedback fix。
Copilot code review 给出一个具体 finding；维护者用 @copilot address review feedback 要求修复，Agent 推送新 commit。
最终 head 上可见 unit、race、integration、lint、CodeQL 等检查成功，随后由人合并。

这条 E3 公共工件链证明 GitHub 已经能把 Issue、Agent 身份、PR、Review、repair 与新 head checks 连起来，也展示了 Copilot cloud agent 的隔离开发环境与 PR 工作方式。Agentic Workflows 还把自然语言 workflow 编译为可审查的 Actions 配置，将写操作拆到 safe-output job，是“prompt-as-code + least privilege”的有价值方向。

但它没有证明三件事：

没有 deterministic test failure → Agent 修复 → 重跑通过；实际观察到的是 AI Review finding → 修复。
公开 reviews API 只看到 Copilot COMMENTED，没有人类 APPROVED。
有 checks 不等于 checks 被 required status checks / rulesets 强制，也没有 merge queue 收据。

因此它是很强的 E3 “公共制品审计”，却不是 E4 复现，更不是 L3 闭环。

最强反例：Review 完成前，PR 已经合并

在 GitHub 官方 github/gh-aw 仓库的 PR #52196 中，PR 在 Copilot reviewer check 启动约 30 秒后已经合并，而 Copilot COMMENTED review 五分钟后才完成。这个时间序列不证明 GitHub 有缺陷，却直接否定“开启 Copilot Review 就获得 merge gate”。GitHub 官方文档也明确说明 Copilot code review 只提交 Comment，不会 Approve 或 Request changes，所以它不能满足 required approval。

GitHub 原生的 CODEOWNERS、strict required checks、dismiss stale approvals、last-push approval、no-bypass ruleset 与 merge queue 足以构造强 S5/S7；问题是必须由仓库策略明确强制，并保留该 PR 被规则约束的收据。AI Review 适合 S6，不能兼任 S7。

云与 GHES 不能混写

GitHub Enterprise Server 3.21 具备坚实的 Git 治理与 Actions 基座，但不支持 GitHub-hosted runners，GitHub 官方托管的 remote MCP server 也不支持 GHES，只能由客户部署本地 server。截止日没有一手证据证明 Copilot cloud agent、Agentic Workflows 与 cloud agentic review runtime 在 GHES 3.21 构成同构官方链。因此 GHES 单列 L1；把 GitHub.com 的 Agent 能力写进 GHES 采购材料会高估现状。

四、GitLab：治理链更完整，但运行和审计仍有断点

公开 MR 把失败、当前 revision、审批和 train 连起来

GitLab 的最佳公开证据是一条强治理工件链，而非精确的依赖升级任务：Work item #586981 关联 MR !219673，MR 由 duo-developer-gitlab-org service account 创建。链路中可以核对：

初始 merged-results pipeline 失败，随后新 commit / pipeline 成功；
后续又出现 RSpec 失败，新 revision 后 recovered merged-result pipeline 成功；
成功 merged-result commit 的 parents 同时包含 target 与最终 source head，排除了“结果属于无关旧提交”的解释；
Approvals API 显示一个独立人类批准，批准后进入 final merge train，最后由人合并。

这条 E3 链证明 GitLab 的 Agent/service identity、MR、pipeline、current revision、approval、train 与 failure recovery primitives 可以在同一 MR 中连续出现。与 GitHub 参考链相比，它对 S5/S7 的公开授权证据更强；但它不是依赖升级任务，修复过程中也有人类提交，所以不能改写成“Duo 自主完成了统一参考任务”。

GitLab 19.2 语义上最贴近参考任务的能力是 Agentic Breaking Change Resolution Flow，能够在依赖升级导致 pipeline 失败后分析变更并继续修复。然而它属于 Ultimate / Beta，相关 feature flags 在 19.2 默认启用但项目仍须显式开启该能力，也没有公开同任务的 session→MR→failure→repair→approval 全链。它是重要方向，不是正式可用现状的收据。

容易被产品名称掩盖的边界

第一，sandbox 不是 fail-closed。 GitLab Environment sandbox 文档说明 Secure Runtime Technology 不可用时，flow 可以发出警告后继续直接执行；setup_script 还在 sandbox 之外运行并可看到 flow variables，执行配置也把它列为预运行步骤。自托管部署若使用 privileged runner，还必须单独治理宿主机风险。正确说法是“可部署专用 ephemeral runner + 受审 setup + SRT + 网络限制”，而不是“打开 Agent 就天然隔离”。

第二，统一工具治理没有覆盖主运行路径。 GitLab 的 Agent tool governance 支持 Always allow / Ask / Deny，但官方 known issue 说明它不适用于在 CI/CD runner 上执行的 flows，包括 Duo Developer 和 Code Review。于是界面上存在治理入口，不等于远程 coding flow 已经被同一策略面完整约束。

第三，绿色 pipeline 也可能过期。 GitLab 的 Auto-merge 文档记录，旧的成功 MR pipeline 可能与新的失败 branch pipeline 并存。要形成 S5，必须约束 workflow、使用 merged results / merge train、核对 source SHA 与 merged-result parents；Ultimate 还可用 current-head external status。只打开 “Pipelines must succeed” 不够。

第四，session 与完整审计都不是无限连续。 GitLab Sessions 文档明确写明：取消后状态变为 Stopped，不能 resume 或 restart，session 还会在最后一次活动 30 天后自动删除。AI audit report 在 19.2 仍为 Beta；页面入口虽然默认启用，详细事件存储却默认关闭，必须显式开启后才写入数据库或 ClickHouse。因此“能查看 session”和“默认保留完整、可恢复的 Agent 审计链”是两种状态。

GitLab.com 与 Self-Managed 的差别是责任转移

GitLab.com 19.2 与 Self-Managed 19.2 的功能包络都可记 L2；自托管并不会自动把 L2 变成 L3。Self-Managed 可以选择 online、hybrid 或 fully self-hosted/offline Agent flow，但 operator 同时接手 runner 隔离、AI Gateway / Workflow Service、模型、镜像供应链、网络出口、entitlement、AI audit storage 与升级节奏。公开 GitLab.com MR 也不能证明任何目标实例已正确部署。

对治理型组织而言，这仍是 GitLab 最大的差异化：Agent、CI、merged results、approval、CODEOWNERS、protected branches、merge trains 与 deployment primitives 能在一个 DevSecOps 产品面中组合；但组合能力必须由目标 tier 和实例收据来证实。

五、替代路线：为何“AI 少”有时反而更容易治理

Bitbucket Cloud：可到 L2，但它是一条跨产品链

Jira Coding Agent 可以从 work item 在 secure cloud sandbox 中工作并创建 draft PR；Agentic Pipelines open beta 又允许 Rovo Dev、Claude 或 Codex 在 Pipelines container 内使用 scoped OAuth / MCP，针对 PR comment、failed build 或 schedule 执行；Rovo Dev code review 提供语义 Review。最后需要 Bitbucket Premium enforced merge checks 把 latest-commit builds、approvals 与 custom checks 变成硬门。

这使 Bitbucket Cloud 达到 L2，但并非一条单产品、单订阅、单生命周期的闭环。Atlassian 官方还明确不建议把 Agentic Pipeline 的 AI result 当 release gate；它必须与独立 deterministic step 分开。Bitbucket Cloud audit 事件说明显示默认 workspace audit 只有有限保留，且不记录细粒度 commit/repository changes；代码、Agent、Jira 与 Rovo 日志的统一关联也未被证明。对 Atlassian 重度用户，它的优势是工作项和知识上下文；代价是集成与治理面碎片化。

Azure DevOps：企业政策很强，Azure Repos 的 Agent 入口却断在最前面

Azure Boards 的 GitHub Copilot coding agent 已能从 work item 创建代码，但官方明确写明它连接 GitHub repository，不支持 Azure Repos。Azure DevOps Services 有 GA 的本地 MCP、preview 的 remote MCP、Microsoft-hosted Pipelines、service principal 与强 branch policies；Azure Repos Copilot Review 也进入 limited preview，但它只发表评论，不能 approve/request changes、不能满足 required reviewer，也不会因新 commit 自动复审。

因此 Azure Repos 的可行链仍是 work item/webhook → 外部 Agent → MCP/REST → PR → Pipelines → branch policy → human merge，Agent runtime 与统一 trace 在平台外，记 L1。Azure DevOps Server 还不能继承 Services 的 MCP——官方 FAQ明确说 on-prem 不支持且没有计划——所以也是 L1 自建路线。

Bitbucket Data Center：治理强于 AI 的典型反例

Bitbucket Data Center 10.1 service accounts、10.4 original creator safeguard、latest-commit merge checks 与 merge-result queue 组成了可核对的治理骨架。正确配置后，它在 S4/S5/S7 可以很强；但 Cloud 上的 Coding Agent、Agentic Pipelines 和 Rovo 不能继承，Agent/task/runtime 都需外置。同一份 merge queue 文档还说明 repo admin 默认可以 bypass，必须由 system admin 关闭，才能把它当成无例外硬门；审计还需按实例保留和导出策略单独核验。

这条路线提醒我们：L1 描述的是 Agent 与治理之间尚无官方连续链，不代表 Git 治理本身弱。 对已有 Data Center 投资和严格数据边界的组织，补外部 Agent control plane 可能比迁移全部 Git/CI/权限数据更可控。

Gitea 与 Forgejo：开放、可控，但运维责任完整落到自己手里

Gitea OSS 1.27.2 是本次开放自管样本中证据最完整的组装候选：官方 Gitea MCP 1.6.0 提供 repo、issue、PR、review、Actions run/log/artifact 等工具；Runner 2.0 可用 ephemeral job；1.27 scoped workflows 可由 owner/instance 强制 must-present-and-pass；protected branches 又能按当前 PR head 要求 status、approval 与 stale-review 处理。

本文对 Forgejo 采用 16.0.1 的 tag-bound 治理源码样本；截止日当前稳定补丁已经是 16.0.2。没有找到已证实的官方 Coding Agent / MCP，但 Actions 安全边界、webhook/OpenAPI、tag-bound current-head status 源码与 branch protection 能组成相似骨架。

两者的正确架构不是让 Agent 直接拿一个管理员 token：

Issue webhook → 外部 task orchestrator → 专用 Agent 身份 / scoped MCP → 单任务隔离 runner → branch/PR → 受中央控制的 deterministic workflows → current-head required status → fresh human approval → merge → 外部不可变 audit → backup/restore drill

平台 API 或 MCP 即使暴露 merge 工具，也只能作为 defense-in-depth 的工具过滤；真正的 S7 必须由服务器权限和保护策略拒绝 Agent 自批、自并或改规则。开放自管节省的可能是 license，新增的则是 task reconcile、sandbox、网络/secret、审计、备份一致性和恢复演练的长期责任。

六、按组织约束选，而不是宣布一个总冠军

场景 A：云优先团队

候选：GitHub.com 与 GitLab.com；Atlassian 深度用户再加 Bitbucket Cloud。

GitHub 更适合把 Agent 直接放进 Issue/PR/Actions 生态、重视开发者采用速度和多 Agent 接入的团队；GitLab 更适合希望 Agent、CI、安全、审批与部署在同一产品面治理的团队。Bitbucket Cloud 只有在 Jira/Confluence 上下文价值足以抵消多产品拼接时才进入首选集。

采购前要做同一项试点，不接受演示脚本替代：制造一次依赖升级失败，让 Agent 修复；验证每个 commit 的 actor、当前 head required checks、Review 的复审行为、独立批准、queue/train、失败后会话关联与审计导出。如果目标 tier 不能强制 S5/S7，就停止“生产闭环”结论。

场景 B：企业治理 / 自托管

候选：先试 GitLab Self-Managed；已有平台重资产则评估“保留 Git 基座 + 外置 Agent control plane”。

GitLab Self-Managed 的优势是功能面最集中，但只有在专用 runner、fail-closed 网络/secret 边界、目标 AI 部署方式、required approvals、merged results/train、AI audit retention 和升级计划同时核验后才成立。GHES、Azure DevOps Server、Bitbucket Data Center 都可以继续担当强 Git 授权面，但各自云端 Agent 能力不能自动带回本地。

这类组织还必须输入本文无法从公共资料获得的参数：现有 CI/Issue/权限数据迁移量、SSO/机器身份约束、数据驻留、模型出网政策、审计保留期、恢复时间目标（RTO）/恢复点目标（RPO）、许可折扣、算力与运维人力。没有这些输入，只能形成候选集，不能生成可信的总体拥有成本（TCO）排名。

场景 C：开放自管

候选骨架：Gitea 1.27.2 优先验证，Forgejo 16.0.1 作为社区治理与兼容性替代。

Gitea 的官方 MCP 与 scoped workflow 让 Agent 工具面和中央 checks 更容易落地；Forgejo 的优势在开放治理、API/Actions 与保护规则。两者都不要自称 L2，除非外部任务控制面能够把 task ID、rules digest、workspace、commit、check、approval、retry 与 audit event 关联起来，并通过一次恢复演练。

当以下任一条件成立，应停止自建并重新考虑托管平台：维护 Agent control plane 与安全隔离的人力超过组织可持续上限；无法构造不可变审计；runner/secret/network 无法 fail closed；恢复演练不能在目标 RTO/RPO 内完成；社区升级节奏与安全响应不满足要求。

七、把“试点”设计成一次可否证的验收

平台 Demo 常常只展示成功路径。真正有区分度的概念验证（PoC）应故意制造失败，并用同一套收据判定：

在受保护公开样例仓库创建依赖升级 Issue，写明行为变化和测试验收。
固定 Agent 使用的 repository rule commit / digest，记录模型、工具、身份、网络和 secret policy。
让 Agent 在单任务隔离环境提交 branch、signed commit 与 PR/MR；Agent 身份不能拥有 policy admin、approval 或 bypass 权限。
首次运行必须由 deterministic test 失败，失败结果绑定 source head；修复后形成新 commit，新检查必须替代旧结果。
AI Review 给出建议但不能授权；新 commit 后必须按策略复审。独立 human / ratified policy 对当前 head 授权。
通过 merge queue / train 对 merge-result revision 重验；若目标平台无此能力，明确记录 race 与补偿机制。
人为中断 session、runner 或部署，检查 task、workspace、commit、logs、retry、rollback 与最终状态是否仍能关联。
导出一份跨任务面、Agent runtime、Git、CI 与授权面的审计包，验证保留期限和恢复方法。

试点结果不是“Agent 完成了任务”这一句话，而应是一张 task ID → rules digest → run ID → commit SHA → check SHA → review → approval SHA → merge revision → release/rollback 关系表。缺一项就保留为 unverified。

八、未来 12–24 个月，真正值得观察什么

下一轮竞争不只会发生在模型代码能力，更会发生在控制面协议：

revision receipt：Agent session 是否能声明读取了哪一版规则、代码、tool policy 和模型配置，而不只是展示聊天日志；
current-head by construction：CI、AI Review、approval 和 merge queue 是否默认围绕同一 revision，而不是靠管理员拼装；
独立身份与授权：human intent、Agent service actor、commit author、reviewer 与 policy owner 是否能分开，同时保持可追溯；
跨系统 trace：MCP、OpenTelemetry、webhook delivery 与 Git audit 是否能形成统一 task/run/change lineage；
fail-closed runtime：sandbox、network、secret 与 tool governance 是否覆盖真正执行 coding flow 的 runner，而不是只覆盖 Chat；
可恢复自治：停止、超时、base 更新、check failure、queue eviction 与 deployment failure 是否进入同一个 reconcile 状态机。

MCP 会降低 Agent 接入 Git 平台的工具成本，却不会自动提供身份、隔离、current-head checks 或独立授权。未来能率先把这些责任绑定在同一份可验证收据上的平台，才有资格从 L2 跨到 L3。

结论

Agent-first 开发的关键，是让 Agent 在更少、可证明的权限里持续工作，而非一味增加写权限。GitHub.com 当前提供最顺滑、最可观察的云 Agent 开发体验；GitLab 当前提供最接近一体化 DevSecOps 和自托管治理的产品包络；Bitbucket Cloud 对 Atlassian 工作流有独特入口；Azure DevOps、Bitbucket Data Center、Gitea 与 Forgejo 则说明强 Git 治理可以独立于内置 AI 存在。

平台的 Agent 能力排名不能替代治理链评估。适配度取决于同一项任务的身份、隔离、Git 变更、当前提交证据、语义审查、独立授权和失败恢复能否连续。截止 2026-08-14，所有候选都还需要目标配置 PoC；率先用同一 revision、同一审计链把这八步关死的平台，才完成从“Agent integrated”到“Agent governed”的跨越。

研究边界与来源说明

本文覆盖 GitHub.com / GHES 3.21、GitLab.com / Self-Managed 19.2、Azure DevOps Services / Server、Bitbucket Cloud / Data Center 10.4.2、Forgejo 16.0.1 tag-bound 治理样本与 Gitea OSS 1.27.2；云版与自托管版不互相继承能力。Forgejo 截止日当前补丁为 stable 16.0.2 / LTS 15.0.6，未把样本版本冒充当前版本。
证据优先级为官方版本化文档、官方源码/API、公开 PR/MR/pipeline；产品页和 roadmap 只证明厂商声称或未来方向。
GitHub 与 GitLab 两条主链均为公开工件审计 E3，不是本次复现 E4。GitHub 链更接近参考任务；GitLab 链对失败、current revision、独立批准和 train 的证据更强，但任务类型不同。
未核验具体组织的价格、折扣、迁移量、合规和人力，因此本文不给伪精确成本排名；所有推荐都是带停止条件的候选建议。
截止日后的 GA、Preview、版本、tier 与默认配置变化，需要重新审计，不应从本文静态继承。

主要一手来源入口

GitHub：Copilot coding agent、Copilot code review、Rulesets、Merge queue、Agentic Workflows
GitLab：Duo Agent Platform、Merge request approvals、Merged results pipelines、Merge trains
Microsoft：Azure DevOps MCP、Azure Boards coding agent、Branch policies
Atlassian：Jira Coding Agent、Agentic Pipelines、Bitbucket merge checks
Gitea / Forgejo：Gitea MCP、Gitea scoped workflows、Forgejo Actions security、Forgejo branch protection

39 KiB Raw Blame History Unescape Escape