fix: keep article figures within viewport

content/posts/agent-first-git-platforms.md

@@ -1,6 +1,6 @@
 ---
 {
-  "title": "Git 平台离 Agent-first 还有多远？",
+  "title": "主流 Git 平台尚未形成 Agent 开发治理闭环",
   "summary": "用同一条任务、Git 变更、当前提交验证、语义审查、独立授权与失败恢复链，对比 GitHub、GitLab、Bitbucket、Azure DevOps、Gitea 与 Forgejo 的 Agent-first 支持程度。",
   "date": "2026-08-14",
   "updated": "2026-08-14",
@@ -15,13 +15,13 @@
 }
 ---
 
-> GitHub、GitLab、Azure DevOps、Bitbucket、Forgejo 与 Gitea 的控制链比较
+> 本文以同一条控制链比较 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 变更 → 当前提交验证 → 语义审查 → 独立授权 → 失败恢复` 控制链的证据强度；它既非厂商评级，也不按功能数量计分。
 
@@ -31,21 +31,21 @@
 
 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 能做多少”。
+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 能力继承过来。
+- **企业治理 / 自托管**：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 展示了这三个硬门在完整控制链中的位置。
+采购的停止条件很明确：**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 开发要求 Git 平台承担完整控制链
 
 “Agent-first”容易被误解成 Copilot、Duo、Rovo 或 MCP（Model Context Protocol，模型上下文协议，让 Agent 用统一接口调用外部工具）的功能清单。变化发生在责任边界：Agent 不再只在 IDE 里给出建议，而是开始接收异步任务、操作工具、修改多文件、运行测试、提交分支与 PR，并在失败后继续工作。此时 Git 平台从代码仓库升级成了变更身份、确定性证据和授权策略的交汇点。
 
@@ -66,7 +66,7 @@ _图 1｜Agent-first 开发控制链：Agent 可以执行，但当前提交证
 
 其中 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、独立授权或恢复仍有明确断点。
@@ -75,7 +75,7 @@ _图 1｜Agent-first 开发控制链：Agent 可以执行，但当前提交证
 
 我们把产品页/公告记为 E1，把官方规范、文档、源码记为 E2，把公开 PR/MR、pipeline、checks 与 API 工件记为 E3；只有本次受控运行才是 E4。本文没有 E4，因此不会把“公开可核对”写成“已复现”。
 
-## 二、总体判断：三家到 L2，没有一家被证明到 L3
+## 二、公开证据尚未支持任何平台达到 L3
 
 | 产品变体 | 截止日判断 | 已证实的最强部分 | 阻止升级的主要断点 |
 |---|---:|---|---|
@@ -107,15 +107,15 @@ _图 1｜Agent-first 开发控制链：Agent 可以执行，但当前提交证
 | 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 多直接等同于治理闭环强。
+图 2 将“Agent 集成深度”和“Git 治理强度”拆成两条轴，避免把内置 AI 功能数量直接等同于治理闭环强度。
 
 ![Git 平台 Agent 集成与治理定位](/articles/agent-first-git-platforms/platform-positioning.svg)
 
 _图 2｜平台定位：横轴表示 Agent 集成深度，纵轴表示当前提交验证与独立授权等治理能力。_
 
-## 三、GitHub：Agent 体验领先，授权证据没有自动跟上
+## 三、GitHub 的 Agent 体验领先，独立授权证据仍不完整
 
-### 一条接近参考任务的公开链
+### 公开工件已形成任务到修复的连续链
 
 GitHub 官方组织的公开仓库给出了一条很接近“升级依赖 + 适配行为 + 测试”的真实链：
 
@@ -135,19 +135,19 @@ GitHub 官方组织的公开仓库给出了一条很接近“升级依赖 + 适
 
 因此它是很强的 E3 “公共制品审计”，却不是 E4 复现，更不是 L3 闭环。
 
-### 最强反例：Review 完成前，PR 已经合并
+### 公开反例表明 AI Review 不能代替合并门禁
 
 在 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.com 的 Agent 能力不能直接推导至 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：治理链更完整，但运行和审计仍有断点
+## 四、GitLab 的治理链更完整，运行与审计仍有断点
 
-### 公开 MR 把失败、当前 revision、审批和 train 连起来
+### 公开 MR 已连接失败、当前 revision、审批与 merge 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 创建。链路中可以核对：
 
@@ -160,7 +160,7 @@ GitLab 的最佳公开证据是一条强治理工件链，而非精确的依赖
 
 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 就天然隔离”。
 
@@ -170,33 +170,33 @@ GitLab 19.2 语义上最贴近参考任务的能力是 [Agentic Breaking Change
 
 **第四，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 的差别是责任转移
+### 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 少”有时反而更容易治理
+## 五、替代平台进一步说明 AI 集成与 Git 治理相互独立
 
-### Bitbucket Cloud：可到 L2，但它是一条跨产品链
+### 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 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 提供强治理基座，但不继承云端 Agent 能力
 
 [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 与 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 处理。
 
@@ -208,9 +208,9 @@ Gitea OSS 1.27.2 是本次开放自管样本中证据最完整的组装候选：
 
 平台 API 或 MCP 即使暴露 merge 工具，也只能作为 defense-in-depth 的工具过滤；真正的 S7 必须由服务器权限和保护策略拒绝 Agent 自批、自并或改规则。开放自管节省的可能是 license，新增的则是 task reconcile、sandbox、网络/secret、审计、备份一致性和恢复演练的长期责任。
 
-## 六、按组织约束选，而不是宣布一个总冠军
+## 六、组织约束决定平台选择
 
-### 场景 A：云优先团队
+### 云优先团队应在 GitHub.com 与 GitLab.com 之间实测
 
 **候选：GitHub.com 与 GitLab.com；Atlassian 深度用户再加 Bitbucket Cloud。**
 
@@ -218,7 +218,7 @@ GitHub 更适合把 Agent 直接放进 Issue/PR/Actions 生态、重视开发者
 
 采购前要做同一项试点，不接受演示脚本替代：制造一次依赖升级失败，让 Agent 修复；验证每个 commit 的 actor、当前 head required checks、Review 的复审行为、独立批准、queue/train、失败后会话关联与审计导出。如果目标 tier 不能强制 S5/S7，就停止“生产闭环”结论。
 
-### 场景 B：企业治理 / 自托管
+### 企业治理团队应优先验证 GitLab Self-Managed
 
 **候选：先试 GitLab Self-Managed；已有平台重资产则评估“保留 Git 基座 + 外置 Agent control plane”。**
 
@@ -226,17 +226,17 @@ GitLab Self-Managed 的优势是功能面最集中，但只有在专用 runner
 
 这类组织还必须输入本文无法从公共资料获得的参数：现有 CI/Issue/权限数据迁移量、SSO/机器身份约束、数据驻留、模型出网政策、审计保留期、恢复时间目标（RTO）/恢复点目标（RPO）、许可折扣、算力与运维人力。没有这些输入，只能形成候选集，不能生成可信的总体拥有成本（TCO）排名。
 
-### 场景 C：开放自管
+### 开放自管团队应优先验证 Gitea 组装骨架
 
 **候选骨架：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 关联起来，并通过一次恢复演练。
+Gitea 的官方 MCP 与 scoped workflow 让 Agent 工具面和中央 checks 更容易落地；Forgejo 的优势在开放治理、API/Actions 与保护规则。除非外部任务控制面能够把 task ID、rules digest、workspace、commit、check、approval、retry 与 audit event 关联起来，并通过一次恢复演练，否则两者均不应被认定为 L2。
 
 当以下任一条件成立，应停止自建并重新考虑托管平台：维护 Agent control plane 与安全隔离的人力超过组织可持续上限；无法构造不可变审计；runner/secret/network 无法 fail closed；恢复演练不能在目标 RTO/RPO 内完成；社区升级节奏与安全响应不满足要求。
 
-## 七、把“试点”设计成一次可否证的验收
+## 七、有效试点必须验证失败恢复与独立授权
 
-平台 Demo 常常只展示成功路径。真正有区分度的概念验证（PoC）应故意制造失败，并用同一套收据判定：
+平台演示通常只展示成功路径。具备判别力的概念验证（PoC）应主动制造失败，并用同一套收据判定：
 
 1. 在受保护公开样例仓库创建依赖升级 Issue，写明行为变化和测试验收。
 
@@ -256,7 +256,7 @@ Gitea 的官方 MCP 与 scoped workflow 让 Agent 工具面和中央 checks 更
 
 试点结果不是“Agent 完成了任务”这一句话，而应是一张 `task ID → rules digest → run ID → commit SHA → check SHA → review → approval SHA → merge revision → release/rollback` 关系表。缺一项就保留为 `unverified`。
 
-## 八、未来 12–24 个月，真正值得观察什么
+## 八、未来竞争将集中在可验证的控制面
 
 下一轮竞争不只会发生在模型代码能力，更会发生在控制面协议：
 
@@ -269,13 +269,13 @@ Gitea 的官方 MCP 与 scoped workflow 让 Agent 工具面和中央 checks 更
 
 MCP 会降低 Agent 接入 Git 平台的工具成本，却不会自动提供身份、隔离、current-head checks 或独立授权。未来能率先把这些责任绑定在同一份可验证收据上的平台，才有资格从 L2 跨到 L3。
 
-## 结论
+## 结论：生产级 Agent-first 仍需要同一条治理证据链
 
-Agent-first 开发的关键，是让 Agent 在更少、可证明的权限里持续工作，而非一味增加写权限。GitHub.com 当前提供最顺滑、最可观察的云 Agent 开发体验；GitLab 当前提供最接近一体化 DevSecOps 和自托管治理的产品包络；Bitbucket Cloud 对 Atlassian 工作流有独特入口；Azure DevOps、Bitbucket Data Center、Gitea 与 Forgejo 则说明强 Git 治理可以独立于内置 AI 存在。
+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”的跨越。
+平台的 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 只证明厂商声称或未来方向。
@@ -283,7 +283,7 @@ Agent-first 开发的关键，是让 Agent 在更少、可证明的权限里持
 - 未核验具体组织的价格、折扣、迁移量、合规和人力，因此本文不给伪精确成本排名；所有推荐都是带停止条件的候选建议。
 - 截止日后的 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/)

src/styles/global.css

@@ -160,6 +160,16 @@ button, input { font: inherit; }
 .prose th { color: var(--rust); font-size: 10px; letter-spacing: .08em; text-transform: uppercase; }
 .prose img, .prose svg { width: min(1100px, calc(100vw - 48px)); max-width: none; margin: 2.6em 0 2.6em 50%; transform: translateX(-50%); }
 
+@media (max-width: 1180px) {
+  .article-grid { grid-template-columns: 1fr; }
+  .article-outline { position: static; }
+  .article-outline ol { display: grid; grid-template-columns: repeat(2, 1fr); }
+}
+
+@media (min-width: 1181px) and (max-width: 1439px) {
+  .prose img, .prose svg { width: 100%; max-width: 100%; margin-left: 0; transform: none; }
+}
+
 @media (max-width: 980px) {
   .hero { grid-template-columns: 1fr; min-height: auto; }
   .hero-copy { padding-bottom: 0; }