---
{
  "title": "Git 平台离 Agent-first 还有多远？",
  "summary": "用同一条任务、Git 变更、当前提交验证、语义审查、独立授权与失败恢复链，对比 GitHub、GitLab、Bitbucket、Azure DevOps、Gitea 与 Forgejo 的 Agent-first 支持程度。",
  "date": "2026-08-14",
  "updated": "2026-08-14",
  "topic": "agent-systems",
  "tags": ["agent-first", "github", "gitlab", "bitbucket", "azure-devops", "gitea", "forgejo"],
  "kind": "article",
  "status": "published",
  "visibility": "public",
  "canonicalUrl": "https://blog.k1412.top/articles/agent-first-git-platforms/",
  "sourceRepo": "https://git.k1412.top/wuyang/research-blog",
  "preview": "/articles/agent-first-git-platforms/agent-first-control-chain.svg"
}
---

> GitHub、GitLab、Azure DevOps、Bitbucket、Forgejo 与 Gitea 的控制链比较

**证据截止：2026-08-14｜阅读时间：约 22 分钟｜结论性质：公开资料与公开工件审计，未做厂商环境 E4（本次受控运行）复现**

**证据级别：E1 厂商声明｜E2 官方文档或源码｜E3 公开 PR/MR、pipeline 与 API 工件｜E4 本次受控运行**

## 执行摘要

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

三条最重要的结论是：

1. **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。

2. **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。

3. **内置 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 展示了这三个硬门在完整控制链中的位置。

![Agent-first 开发控制链](/articles/agent-first-git-platforms/agent-first-control-chain.svg)

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

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

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

[OpenAI 的 Harness Engineering 实践](https://openai.com/index/harness-engineering/)把仓库可读性、规则、反馈循环与工程环境视为 Agent 有效工作的前提；公开的 [Symphony 规范与源码](https://github.com/openai/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](https://slsa.dev/spec/v1.2/provenance)强调结果必须能关联到生成它的输入和过程；同理，PR 页面上“有绿色检查”比“规则要求针对当前 revision 的检查通过”弱得多。[OpenAI 的 Codex 安全实践](https://openai.com/index/running-codex-safely/)也把 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](https://github.blog/changelog/2025-09-25-copilot-coding-agent-is-now-generally-available/)，code review [核心 GA、部分增强仍为 preview](https://docs.github.com/en/enterprise-cloud@latest/copilot/concepts/agents/code-review)；Agentic Workflows 为 [public preview](https://github.blog/changelog/2026-06-11-github-agentic-workflows-is-now-in-public-preview/) |
| **GitLab.com 19.2** | [Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/)、[Developer Flow](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/developer/)、[Code Review](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/code_review/) 与 [Fix Pipeline](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/fix_pipeline/) 主链 GA；[Breaking Change Flow](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/agentic-breaking-change-resolution/) 和 [AI audit report](https://docs.gitlab.com/user/duo_agent_platform/ai-audit-events/) 为 Beta |
| **GitLab Self-Managed 19.2** | 与上行沿用同一产品生命周期标签，但可用性还受 tier、entitlement、runner 与 AI 部署配置约束；本次未核验任何目标实例 |
| **Bitbucket Cloud** | [Jira Coding Agent](https://support.atlassian.com/jira-software-cloud/docs/generate-code-from-a-work-item-in-jira/) 有正式文档，本次未找到独立 lifecycle 标签；Agentic Pipelines 为 [open beta](https://www.atlassian.com/blog/bitbucket/introducing-agentic-pipelines-ai-automation)，Rovo Dev Code Reviewer 已 [GA](https://www.atlassian.com/blog/artificial-intelligence/developer-productivity-improved-with-rovo-dev) |
| Azure DevOps Services / Azure Repos | Boards→GitHub coding agent 集成已 [GA](https://devblogs.microsoft.com/devops/github-copilot-for-azure-boards/)，但[不支持 Azure Repos](https://learn.microsoft.com/en-us/azure/devops/boards/github/work-item-integration-github-copilot?view=azure-devops)；Azure DevOps MCP 为[本地 GA、remote public preview](https://learn.microsoft.com/en-us/azure/devops/mcp-server/mcp-server-overview?view=azure-devops)，Azure Repos Copilot Review 为 [limited public preview](https://learn.microsoft.com/en-us/azure/devops/repos/git/copilot-code-reviews?view=azure-devops) |
| GitHub Enterprise Server 3.21 | 3.21 是本文版本基线；[GitHub-hosted runners 不可用](https://docs.github.com/en/enterprise-server@3.21/actions/concepts/runners/github-hosted-runners)，cloud agent 同构链未核验，[官方 remote MCP 不支持 GHES](https://github.com/github/github-mcp-server)，因此官方 Agent 链生命周期记为未核验 |
| Bitbucket Data Center 10.4.2 | [10.4.2 是截止日当前 GA 版本](https://confluence.atlassian.com/bitbucketserver/bitbucket-data-center-10-4-release-notes-1822720695.html)；[Cloud 的 Coding Agent、Agentic Pipelines 与 Rovo 不继承](https://www.atlassian.com/migration/assess/compare-cloud-data-center/bitbucket)，Data Center 原生 Agent 生命周期未核验 |
| Azure DevOps Server | [当前产品线与 Patch 7](https://learn.microsoft.com/en-us/azure/devops/server/release-notes/azuredevopsserver?view=azure-devops)作为版本基线；[Services MCP 明确不支持 on-prem](https://github.com/microsoft/azure-devops-mcp/blob/main/docs/FAQ.md)，官方 Agent runtime 生命周期记为未核验 |
| Gitea OSS 1.27.2 | [1.27.2 为截止日签名稳定版本](https://github.com/go-gitea/gitea/releases/tag/v1.27.2)，官方独立 [Gitea MCP 1.6.0](https://gitea.com/gitea/gitea-mcp/src/tag/v1.6.0/README.md) 已发布；core 内建 MCP 仍是[开放 proposal](https://github.com/go-gitea/gitea/issues/35506)，官方 Coding Agent 未核验 |
| Forgejo 16.0.1 | 本文 tag-bound 治理源码样本为 16.0.1；[截止日当前 stable patch 为 16.0.2、LTS patch 为 15.0.6](https://forgejo.org/releases/)；官方 Coding Agent / MCP 截止日未核验 |

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

![Git 平台 Agent 集成与治理定位](/articles/agent-first-git-platforms/platform-positioning.svg)

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

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

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

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

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

这条 E3 公共工件链证明 GitHub 已经能把 Issue、Agent 身份、PR、Review、repair 与新 head checks 连起来，也展示了 [Copilot cloud agent 的隔离开发环境与 PR 工作方式](https://docs.github.com/en/copilot/concepts/coding-agent/coding-agent)。[Agentic Workflows](https://github.com/github/gh-aw) 还把自然语言 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](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) / [rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets) 强制，也没有 merge queue 收据。

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

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

在 GitHub 官方 `github/gh-aw` 仓库的 [PR #52196](https://github.com/github/gh-aw/pull/52196) 中，PR 在 Copilot reviewer check 启动约 30 秒后已经合并，而 Copilot `COMMENTED` review 五分钟后才完成。这个时间序列不证明 GitHub 有缺陷，却直接否定“开启 Copilot Review 就获得 merge gate”。GitHub 官方文档也明确说明 [Copilot code review 只提交 Comment，不会 Approve 或 Request changes](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review?tool=webui)，所以它不能满足 required approval。

GitHub 原生的 [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)、strict required checks、dismiss stale approvals、last-push approval、no-bypass ruleset 与 [merge queue](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue) 足以构造强 S5/S7；问题是必须由仓库策略明确强制，并保留该 PR 被规则约束的收据。AI Review 适合 S6，不能兼任 S7。

### 云与 GHES 不能混写

GitHub Enterprise Server 3.21 具备坚实的 Git 治理与 Actions 基座，但[不支持 GitHub-hosted runners](https://docs.github.com/en/enterprise-server@3.21/actions/concepts/runners/github-hosted-runners)，[GitHub 官方托管的 remote MCP server](https://github.com/github/github-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](https://gitlab.com/gitlab-org/gitlab/-/work_items/586981) 关联 [MR !219673](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/219673)，MR 由 `duo-developer-gitlab-org` service account 创建。链路中可以核对：

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

这条 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](https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/agentic-breaking-change-resolution/)，能够在依赖升级导致 pipeline 失败后分析变更并继续修复。然而它属于 Ultimate / Beta，相关 feature flags 在 19.2 默认启用但项目仍须显式开启该能力，也没有公开同任务的 session→MR→failure→repair→approval 全链。它是重要方向，不是正式可用现状的收据。

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

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

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

**第三，绿色 pipeline 也可能过期。** GitLab 的 [Auto-merge 文档](https://docs.gitlab.com/user/project/merge_requests/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 文档](https://docs.gitlab.com/user/duo_agent_platform/sessions/)明确写明：取消后状态变为 Stopped，不能 resume 或 restart，session 还会在最后一次活动 30 天后自动删除。[AI audit report](https://docs.gitlab.com/user/duo_agent_platform/ai-audit-events/) 在 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](https://support.atlassian.com/jira-software-cloud/docs/generate-code-from-a-work-item-in-jira/) 可以从 work item 在 secure cloud sandbox 中工作并创建 draft PR；[Agentic Pipelines](https://support.atlassian.com/bitbucket-cloud/docs/agentic-pipelines/) open beta 又允许 Rovo Dev、Claude 或 Codex 在 Pipelines container 内使用 scoped OAuth / MCP，针对 PR comment、failed build 或 schedule 执行；[Rovo Dev code review](https://support.atlassian.com/rovo/docs/enable-code-reviews/) 提供语义 Review。最后需要 [Bitbucket Premium enforced merge checks](https://support.atlassian.com/bitbucket-cloud/docs/suggest-or-require-checks-before-a-merge/) 把 latest-commit builds、approvals 与 custom checks 变成硬门。

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

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

[Azure Boards 的 GitHub Copilot coding agent](https://learn.microsoft.com/en-us/azure/devops/boards/github/work-item-integration-github-copilot?view=azure-devops) 已能从 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](https://github.com/microsoft/azure-devops-mcp/blob/main/docs/FAQ.md)明确说 on-prem 不支持且没有计划——所以也是 L1 自建路线。

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

[Bitbucket Data Center 10.1 service accounts](https://confluence.atlassian.com/bitbucketserver/bitbucket-data-center-10-1-release-notes-1671462965.html)、[10.4 original creator safeguard](https://confluence.atlassian.com/bitbucketserver/bitbucket-data-center-10-4-release-notes-1822720695.html)、[latest-commit merge checks](https://confluence.atlassian.com/bitbucketserver/checks-for-merging-pull-requests-776640039.html) 与 [merge-result queue](https://confluence.atlassian.com/bitbucketserver/manage-pull-requests-with-merge-queues-1721012227.html) 组成了可核对的治理骨架。正确配置后，它在 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](https://gitea.com/gitea/gitea-mcp/src/tag/v1.6.0/README.md) 提供 repo、issue、PR、review、Actions run/log/artifact 等工具；[Runner 2.0](https://blog.gitea.com/release-of-runner-2.0.0/) 可用 ephemeral job；[1.27 scoped workflows](https://docs.gitea.com/usage/actions/scoped-workflows) 可由 owner/instance 强制 must-present-and-pass；[protected branches](https://docs.gitea.com/usage/access-control/protected-branches) 又能按当前 PR head 要求 status、approval 与 stale-review 处理。

本文对 Forgejo 采用 16.0.1 的 tag-bound 治理源码样本；截止日当前稳定补丁已经是 16.0.2。没有找到已证实的官方 Coding Agent / MCP，但 [Actions 安全边界](https://forgejo.org/docs/latest/user/actions/security/)、webhook/OpenAPI、tag-bound current-head status 源码与 [branch protection](https://forgejo.org/docs/latest/user/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）应故意制造失败，并用同一套收据判定：

1. 在受保护公开样例仓库创建依赖升级 Issue，写明行为变化和测试验收。

2. 固定 Agent 使用的 repository rule commit / digest，记录模型、工具、身份、网络和 secret policy。

3. 让 Agent 在单任务隔离环境提交 branch、signed commit 与 PR/MR；Agent 身份不能拥有 policy admin、approval 或 bypass 权限。

4. 首次运行必须由 deterministic test 失败，失败结果绑定 source head；修复后形成新 commit，新检查必须替代旧结果。

5. AI Review 给出建议但不能授权；新 commit 后必须按策略复审。独立 human / ratified policy 对当前 head 授权。

6. 通过 merge queue / train 对 merge-result revision 重验；若目标平台无此能力，明确记录 race 与补偿机制。

7. 人为中断 session、runner 或部署，检查 task、workspace、commit、logs、retry、rollback 与最终状态是否仍能关联。

8. 导出一份跨任务面、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](https://docs.github.com/en/copilot/concepts/coding-agent/coding-agent)、[Copilot code review](https://docs.github.com/en/copilot/concepts/code-review/code-review)、[Rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)、[Merge queue](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue)、[Agentic Workflows](https://github.com/github/gh-aw)
- GitLab：[Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/)、[Merge request approvals](https://docs.gitlab.com/user/project/merge_requests/approvals/)、[Merged results pipelines](https://docs.gitlab.com/ci/pipelines/merged_results_pipelines/)、[Merge trains](https://docs.gitlab.com/ci/pipelines/merge_trains/)
- Microsoft：[Azure DevOps MCP](https://learn.microsoft.com/en-us/azure/devops/mcp-server/mcp-server-overview?view=azure-devops)、[Azure Boards coding agent](https://learn.microsoft.com/en-us/azure/devops/boards/github/work-item-integration-github-copilot?view=azure-devops)、[Branch policies](https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops)
- Atlassian：[Jira Coding Agent](https://support.atlassian.com/jira-software-cloud/docs/generate-code-from-a-work-item-in-jira/)、[Agentic Pipelines](https://support.atlassian.com/bitbucket-cloud/docs/agentic-pipelines/)、[Bitbucket merge checks](https://support.atlassian.com/bitbucket-cloud/docs/suggest-or-require-checks-before-a-merge/)
- Gitea / Forgejo：[Gitea MCP](https://gitea.com/gitea/gitea-mcp/src/tag/v1.6.0/README.md)、[Gitea scoped workflows](https://docs.gitea.com/usage/actions/scoped-workflows)、[Forgejo Actions security](https://forgejo.org/docs/latest/user/actions/security/)、[Forgejo branch protection](https://forgejo.org/docs/latest/user/protection/)