自驱动代码库治理：Agent PR 的准入、验收与回滚

核心结论

**自驱动代码库（Self-Driving Codebase）**不是一个可以脱离监督、安全地修改自己的仓库，而是一套受治理的软件交付系统：AI Agent 接收边界明确的任务，在受限环境中工作，提交可验证证据，再由风险策略、责任人和回滚机制决定变更能否产生真实影响。

真正需要回答的问题不是“Agent 能创建多少 PR”，而是：

哪类改动允许 Agent 尝试，它必须返回什么证据，谁有权批准实际影响，团队如何发现并撤销错误结果？

这套系统应坚持四条原则：

• 先准入，再谈自治：先判断任务是否适合委派，再决定 Agent 可以独立做到哪一步。
• 先证据，再谈信任：看似合理的 Diff、截图或演示视频都不等于正确性证明。
• 先评审容量，再扩并发：生成速度超过验证速度，只会制造更大的风险队列。
• 先证明恢复，再扩大权限：取消、回滚和责任归属没有验证前，不增加新的副作用权限。

“自驱动”应当指什么

工程上的“自驱动”应当描述一个闭环、受控的流程，而不是不受限制的模型权限。生产链路包含：

Agent 可以承担闭环中间的大量执行工作，但组织仍然拥有任务定义、权限、验收策略、合并权、发布边界和最终责任。

这种定义能避免两个常见错误：

1. 把能力较强的编程模型当成授权系统；
2. 把 Pull Request 当作任务终点，而不是对生产影响的一项提案。

如果希望进一步理解模型之外的运行时，可以阅读 Agent Harness 评测指南。

如何正确理解 Agent PR 数据

厂商披露证明 Agent 已经能够交付真实变更，但不能由此推导出通用生产率或质量结论。

Cursor 的 2026 年 2 月 24 日产品公告表示，**内部已合并 PR 中超过 30%**由云端沙箱内自主运行的 Agent 创建。Michael Truell 在 2 月 26 日的文章中给出的数字是 35%。两者都描述 Cursor 自己的团队，不能外推为全行业比例。

产品公告还介绍了隔离虚拟机，以及视频、截图和日志等验证产出物。这些一手自报材料没有提供可比的人类基线、任务分布、评审成本明细、缺陷率或独立审计。它们说明厂商报告的采用程度，不能证明生产率提升幅度。

独立研究提供了更多视角，但同样需要保留样本边界：

这些结论并不冲突：一个 PR 可以达到可合并状态，同时仍需人工修改；某类任务的吞吐可能提高，另一些任务的评审与维护成本却可能上升。外部数字应当用于提出本地验证假设，而不是设定采用率 KPI。

启动 Agent 前先做任务分类

任务准入是第一道安全边界。实用分类应同时考虑爆炸半径、可观测性、可逆性与规格清晰度。

任务名称不能永久决定风险等级。依赖升级在一个离线小工具中可能风险较低，在鉴权网关中却可能影响全站；文档修改如果包含内部信息，同样可能造成泄露。团队应判断真实副作用，而不是只看 Ticket 标签。

出现以下任一情况时，不应把端到端执行交给 Agent：

• 预期行为无法表达为可观测的验收条件；
• Agent 需要长期生产凭证或不受限制的网络访问；
• 改动跨越未文档化的服务、Schema 或租户边界；
• 回滚具有破坏性、未经过验证，或恢复速度不满足业务要求；
• CI 过于不稳定，单次通过无法区分补丁效果和随机噪声；
• 代码所有权、许可证、隐私或合规责任尚未解决。

用自治阶梯代替“开或关”

自治能力应按仓库与风险类型分别推进，而不是全局一次开启。

第五级不是所有任务的终点。一套成熟系统完全可以让生成文档进入第四级，同时把安全敏感代码长期限制在第一级。正确等级是：已有代表性证据和可靠恢复能力支持的最高等级。

Human-in-the-loop 也不等于为所有操作添加一个“确认”按钮。审批必须绑定到精确 Commit、参数、证据包和副作用；Commit 变化后，旧审批不能继续生效。

编写可执行的验收契约

交给 Agent 的任务应有一份明确成功条件与禁止行为的契约：

目标结果：
基线与复现方法：
允许修改的文件、服务和命令：
非目标与禁止改动：
功能验收与负向测试：
安全、隐私、性能和兼容性不变量：
必须提交的证据：
预算与停止条件：
回滚方法：
责任人与审批要求：

好的验收标准描述可观察行为。“优化鉴权模块”无法验证；“过期 Token 必须在不查询 Profile 服务的情况下被拒绝，同时保持公开错误 Schema 不变并通过重放 Fixture”则可以验证。

验收契约还应与实现建议分离，否则 Agent 可能完整实现了建议方法，却没有解决用户真正的问题。

用 Go 实现策略门禁

下面的独立 Go 程序演示如何把已验证的风险和证据转换为确定性决策。保存为 main.go 后执行 go run main.go。即使自动门禁全部通过，中风险改动仍必须由责任人评审。

它是决策函数，不是证据验证器。输入必须由可信服务从对应提交的 CI 结果和已认证评审记录中组装；不能让 Agent 自行填写风险等级、通过标志或审批数量。

package main

import (
	"fmt"
	"strings"
)

type Proposal struct {
	Risk               string
	BaselineCaptured   bool
	TestsPassed        bool
	SecurityPassed     bool
	RollbackVerified   bool
	ProvenanceComplete bool
	HumanApprovals     int
}

type Decision struct {
	Action  string
	Reasons []string
}

func evaluate(proposal Proposal) Decision {
	reasons := make([]string, 0)
	if !proposal.BaselineCaptured {
		reasons = append(reasons, "baseline is missing")
	}
	if !proposal.TestsPassed {
		reasons = append(reasons, "required tests failed")
	}
	if !proposal.SecurityPassed {
		reasons = append(reasons, "security gate failed")
	}
	if !proposal.RollbackVerified {
		reasons = append(reasons, "rollback is unverified")
	}
	if !proposal.ProvenanceComplete {
		reasons = append(reasons, "provenance is incomplete")
	}
	if len(reasons) > 0 {
		return Decision{Action: "block", Reasons: reasons}
	}

	switch proposal.Risk {
	case "low":
		return Decision{Action: "eligible-for-policy-merge"}
	case "medium":
		if proposal.HumanApprovals < 1 {
			return Decision{
				Action:  "require-human-review",
				Reasons: []string{"medium-risk change needs an accountable owner"},
			}
		}
		return Decision{Action: "merge-after-owner-approval"}
	default:
		return Decision{
			Action:  "require-specialist-review",
			Reasons: []string{"high or unknown risk cannot auto-merge"},
		}
	}
}

func main() {
	decision := evaluate(Proposal{
		Risk:               "medium",
		BaselineCaptured:   true,
		TestsPassed:        true,
		SecurityPassed:     true,
		RollbackVerified:   true,
		ProvenanceComplete: true,
	})
	fmt.Printf("%s: %s\n", decision.Action, strings.Join(decision.Reasons, "; "))
	// Output: require-human-review: medium-risk change needs an accountable owner
}

真实策略必须把决策绑定到 Commit SHA、仓库、执行身份、策略版本、测试产物哈希和审批有效期。只计入不同的授权评审者，排除已撤销或过期审批，并在受保护的合并入口强制执行。返回一个动作字符串，本身并没有执行或授权合并。

要求 PR 携带可审计证据

可信的 Agent PR 应说明“哪些结论已被证明”，而不只是罗列“Agent 做过哪些步骤”。

证据包至少应包含：

• 任务身份：Issue、验收契约版本、目标分支和精确 Commit；
• 基线：复现步骤或已知正确的对照结果；
• 变更地图：受影响的接口、Schema、依赖、Feature Flag 与 Owner；
• 验证信息：命令、环境、退出状态、相关日志和产物 Hash；
• 负向证据：失败路径、授权检查、异常输入与回滚测试；
• 残余不确定性：未执行检查、假设、Flaky 结果与未覆盖环境；
• 发布方案：灰度范围、观察信号、终止条件和回滚责任人。

截图和视频适合证明视觉路径，但无法证明授权、并发安全、数据完整性或不存在隐蔽回归。由同一 Agent 同时生成实现与测试时，测试也可能复用相同的错误假设，因此不能天然视为独立证据。

审计记录应保留工具调用、命令、被修改资源、策略决策、审批与结果。不要要求或保存隐藏思维链；可复核的操作证据比不可验证的内部推理叙述更适合审计，也更少暴露敏感信息。

保护人的评审容量

并行 Agent 会先提高“提案吞吐”，不一定同步提高“已验证交付”。当评审才是瓶颈时，增加 Agent 会拉长队列、诱导浅层评审，并制造更多相互冲突的改动。

可以通过以下机制控制在制品：

• 限制每位 Owner 名下尚未评审的 Agent PR 数量；
• 限制单个变更规模，广泛 Diff 必须拆分；
• 自动关闭或刷新陈旧提案；
• 根据受影响接口把 PR 路由给真实 Owner；
• 检测重复任务与文件范围重叠；
• 按风险等级定义评审服务目标；
• 回滚、缺陷或队列超过阈值时提供全局暂停开关。

工程经济单位不应是“创建了一个 PR”。更有价值的是 Accepted Goodput（被接受的有效吞吐）：改动经过评审、合并并完成观察期，没有立即回滚或返修，再除以受约束的人力与系统资源。

按任务和风险衡量结果

自驱动代码库需要一份带版本的评分卡。全局平均值会掩盖哪些工作真正安全、有效。

每条观测都应记录模型、Harness、策略、仓库和测试集版本；只比较相似任务并报告不确定性。AI 编程 ROI 评估指南进一步解释了为什么不能把活动指标直接改写为生产率。

把安全控制放进执行环境

能够读取仓库、运行命令、访问网络、安装依赖并创建 PR 的 Agent，本质上是一个高权限软件主体。控制应由技术机制保证，而不能只依赖 Prompt：

1. 短期身份：使用任务级、短生命周期凭证；工作区不得出现可复用生产 Secret。
2. 沙箱与出口策略：隔离文件系统、进程、网络和云权限，只允许访问任务必需的目标。
3. 保护真实副作用：Branch Protection、CODEOWNERS、部署审批和数据库控制必须位于 Agent 权限之外。
4. 供应链治理：锁定并校验依赖，扫描许可证和漏洞，显式评审 Lockfile 变化。
5. 不可信输入处理：Issue、源码、网页、日志和工具输出都可能包含 Prompt Injection，应按数据而非指令处理。
6. 来源追踪：保留发起身份、Agent 与模型版本、策略版本、Commit、工具事件和使用的外部资源。
7. 权威回读：发生任何允许的写操作后，重新查询目标系统，不能只相信工具返回“成功”。

AI Agent 工具安全指南进一步讨论了授权边界与提示注入威胁模型。

按证据推进，而不是按日历推进

采用过程应经过可逆阶段：

1. 建立基线：记录目标任务当前的流转、评审、缺陷与恢复数据。
2. 影子运行：Agent 可以分析但不修改共享状态，把建议与真实结果对比。
3. 沙箱 PR：允许编辑和验证，但合并、发布继续由人负责。
4. 条件自动化：只有经过代表性评测的明确低风险任务类型才进入自动化。
5. 受控副作用：团队实际演练过失败与恢复后，才增加灰度发布和自动回滚。

扩权与暂停条件应事先声明。文档任务试点成功不能自动授权依赖升级；新模型不能继承旧模型的评测结论；Harness、策略、测试集或仓库发生变化时，已有证据也可能失效。

常见失败模式

追求 Agent PR 占比

更高占比可能只说明任务被重新分类、PR 变小，或门禁被放宽。真正应优化的是被接受结果和用户价值。

让同一个 Agent 定义、实现并评判任务

当需求、代码和测试都由同一系统生成时，共享误解可能通过所有本地检查。保留独立 Fixture、策略或评审者。

把产出物当成充分证明

视频只能展示一条路径，无法证明租户隔离、竞态安全、迁移完整性或可访问性。

先扩生成，后补评审

十个并发 Agent 可能制造十条不确定工作队列。容量规划必须包含专家评审与集成成本。

为方便而授予宽泛凭证

长期 Token 和无限网络出口会放大仓库恶意指令或受污染依赖造成的事故。

用隐藏推理替代操作证据

内部推理既不是可靠审计轨迹，也不是问责所必需。应记录输入、操作、策略、产物和结果。

常见问题

自驱动代码库等同于自主发布吗？

不等同。Agent 编写代码、自动合并和自动发布到生产是三种不同能力，需要不同的证据与风险门槛。

Agent PR 是否应该接受比人工 PR 更严格的门禁？

门禁应匹配风险和失败模式。Agent 改动可以增加来源追踪、依赖扫描与独立测试，但人工改动也不能绕过必要的安全和质量控制。

最适合开始试点的是哪类任务？

应选择边界清楚、可逆、有明确 Owner 和确定性检查的任务通道。具体候选取决于仓库，不存在对所有团队都安全的 Ticket 清单。

高合并率能否证明代码质量高？

不能。合并率受样本筛选、仓库习惯、任务类型和人工修改影响，必须与评审投入、合并后缺陷、回滚、可维护性和安全结果一起观察。

何时可以开启自动合并？

只有明确的任务类别经过代表性评测，质量与恢复满足预设门槛，并具备绑定 Commit 的证据、受保护分支、策略暂停开关和责任人时，才应考虑自动合并。

一手资料

• Cursor：Agent 可以控制自己的电脑：隔离环境、验证产出物，以及“超过 30%”内部 PR 的厂商一手披露
• Cursor：AI 软件开发的第三个时代：Michael Truell 在 2026 年 2 月 26 日披露内部已合并 PR 的 35% 由 Agent 创建
• Cursor：扩展长时间自主编程：研究原型、协作失败、Planner-Worker 设计与评审边界
• Watanabe 等：On the Use of Agentic Coding：157 个开源项目中的 567 个 Claude Code PR
• Agarwal 等：AI IDEs or Autonomous Agents?：纵向匹配仓库研究与可维护性信号
• METR：调整开发者生产率实验设计：选择偏差与并行 Agent 工时口径限制
• NIST Secure Software Development Framework：安全开发实践和组织控制
• OWASP Agentic Applications Top 10：Agent 授权、工具与不可信输入风险

总结

可信的自驱动代码库必须能够说“不”、证明发生过什么、保留可问责评审，并在失败后恢复。长期优势不在于 Agent 写了多少代码，而在于每次变更周围是否存在高质量的准入规则、验收契约、证据、权限、评审系统与回滚控制。

本文是 AI Agent 开发实战 专栏第 14 篇。可继续阅读 从程序员到 Agent 编排者理解人的责任边界，或阅读 Harness Engineering 实战了解执行层设计。