智能体还停在流水线的数据面：CI/CD 里的权限转移

本文是论文 From Assistance to Agency: Rethinking Autonomy and Control in CI/CD Pipelines（arXiv:2605.07062，2026-05-08）正文第 1 节至第 6 节的中文译文，由智测团队翻译。作者是多伦多大学的 Marcus Emmanuel Barnes、Trent 大学的 Taher A. Ghaleb，以及多伦多大学的 Safwat Hassan。参考文献未逐条展开。这是愿景与综合论文，不是新实验，文中没有新测出来的通过率或耗时。工业产品说明可能不完整，也可能带有营销色彩。作者因此优先写可观察的行为，不转述厂商的性能宣称。

摘要

人工智能智能体正在持续集成与持续部署（CI/CD）工作流里承担主动角色。研究社区却还没有一套共享词汇，用来说明：什么样的 CI/CD 才算是智能体式的，多少决策权被交出去了，控制应该留在哪里。本文提出一种智能体式 CI/CD 的看法。中心问题不是把修流水线的任务做得更好，而是设计权限转移：在写明的约束和追索机制之下，把操作决策从人控制的流水线交给智能体系统。

为把这个论点组织起来，作者区分数据面权限和控制面权限。数据面是局部干预，例如生成补丁、重跑测试。控制面是修改流水线配置、部署策略和批准关口。综合研究原型和工业平台之后，作者认为当前系统主要在数据面上、以有界自主的方式运转。安全来自外围的治理基础设施，而不是智能体自身的内在保证。反复出现的模式有三条：受约束的自主是主导设计；外部治理是主要安全机制；部署势头和评测方法之间的缺口在变宽。研究议程里，控制面的安全与治理机制是最紧迫的开放问题，其后是自主边界的形式化、评测框架，以及人与智能体的协调。

关键词：CI/CD 流水线；DevOps 自动化；智能体系统；自主软件系统；人工智能辅助的软件工程。

1 引言

持续集成与持续部署是现代软件交付的中心（Shahin 等，2017；Fitzgerald 和 Stol，2017）。人工智能技术早已支持失败诊断和运行监控这类任务（Mishra 和 Otaiwi，2020；Notaro 等，2021），通常作为嵌在某个流水线阶段里的预测或建议组件。在这些系统里，决策权仍在人，或在固定的流水线逻辑。

基于大语言模型的系统和软件工程智能体（Hou 等，2024；Liu 等，2024；Wang 等，2025）引入了能做规划、用工具、执行动作的组件。工业平台现在描述的智能体，会观察流水线状态，生成补丁或配置变更，再通过仓库工作流提交修改（GitHub，2026b；GitLab，2026；Amazon Web Services，2026；Google GitHub Actions，2026；Nx，2025）。采用很快，研究社区却缺少共享词汇，说不清这些系统有多自主、决策权在哪里。于是很难比较那些都叫「智能体式」、但人的否决和治理机制根本不同的系统。

作者主张：智能体式 CI/CD 的中心挑战，不是提高修复表现，而是设计权限转移。权限转移是指：在写明的约束和追索机制之下，把操作决策从人控制的流水线交给智能体系统。为组织这个问题，作者区分数据面权限和控制面权限。数据面权限是一次流水线执行内部的局部干预，例如生成补丁、重跑测试。控制面权限是对流水线配置、部署策略和批准关口的修改。把控制面权限交出去，会改组织的风险边界。当前系统却压倒性地把智能体限制在数据面。

综合研究原型和工业平台，作者把现状刻画为有界自主（Huebscher 和 McCann，2008）：智能体在受约束的动作范围内操作，决策权仍由人的批准工作流这类治理机制居中调节。三条反复出现的模式是：第一，受约束的自主占主导，智能体在预先划定的动作空间里工作，集成由人批准来居中。第二，安全主要靠外围治理基础设施（例如拉取请求和策略关口）实现，而不是靠智能体的内在保证。第三，部署势头跑在评测方法前面，这个领域缺少适合决策型智能体的基准。

本文的贡献，是把智能体式 CI/CD 重新表述成权限转移问题，并引入数据面与控制面的区分，作为讨论自主和治理的词汇。这对系统设计和评测都有含义。

结尾给出研究议程。优先顺序是：控制面的安全与治理机制，然后是自主边界的形式化、评测框架，以及人与智能体的协调。把权限转移当成一等设计问题，才能更精确地讨论 CI/CD 流水线里的智能体行为。

2 实践中的智能体式 CI/CD：研究与工业里的例子

讨论落在研究和工业文档上。许多进展来自商业平台，两类材料都有助于看清：智能体能力在实践里如何被表述、又如何被约束。目标不是穷尽覆盖，而是一组按能力挑选的范例，用来支撑后面的观察和研究议程。本文不是系统文献综述，而是对有代表性的研究原型和公开记录的工业系统所做的综合。

2.1 研究原型

CI/CD 里较早的智能体式行为出现在自动修复系统。Repairnator 持续监视持续集成失败，合成候选补丁，再提交拉取请求供人评审（Monperrus 等，2019；Urli 等，2018）。R-HERO 把持续学习加进补丁生成，扩展了这个模式（Baudry 等，2021）。但集成权仍由拉取请求工作流居中，自主因此有限。

更近的、基于大模型的修复系统，智能体味道更重。RepairAgent（Bouzenia 等，2025）通过调用工具、收集诊断信息、在候选补丁上迭代，自主规划和执行多步修复策略。ChatRepair（Xia 和 Zhang，2024）用对话式大模型交互，靠与测试反馈的反复对话修缺陷。这些系统展示了更丰富的规划和工具使用，但合并与否仍由人的评审者说了算。BuildSheriff（Zhang 等，2022）处理一个互补问题：把持续集成测试失败分诊到根因。它说明诊断智能可以走在修复智能体前面，并给后者提供支持。

LogSage 在工业环境里分析 CI/CD 日志，检测失败并支持修复动作（Xu 等，2025）。相邻的 DevSecOps 研究，例如 AutoGuard，把自愈表述成一层主动控制：用强化学习改编流水线的响应（Anugula 等，2025）。Bouzenia 和 Pradel（2025）给出一个大模型智能体，能为任意项目自主搭建并执行测试套件。这说明智能体能力正在超出补丁生成，伸向更宽的构建与测试自动化。论文标题是 You Name It, I Run It。

开发层和交付层之间有一道值得注意的缺口。Li 等人提出 AIDev，对 GitHub 仓库上人工智能智能体活动做大规模研究，可以分析智能体撰写的拉取请求，以及它们与人类贡献者的交互模式（Li 等，2026）。这项工作为理解智能体如何贡献代码提供了经验基础，但没有处理 CI/CD 流水线里的集成、部署或控制面权限。缺口是实质的：代码贡献已有经验证据，发布治理还没有。

2.2 工业系统

工业平台越来越多地用面向智能体的语言描述 CI/CD 功能，各厂商的模式一致。主要平台（例如 GitHub、GitLab、Amazon Q 和 Google）现在集成了智能体式 CI/CD 能力，同时保留由人居中的合并权（GitHub，2026b；GitHub，2026a；GitLab，2026；Amazon Web Services，2026；Google GitHub Actions，2026）。

Nx 的 Self-Healing CI、Datadog 的 Bits AI Dev Agent，以及 Gitar 的自主构建修复引擎，都监视流水线结果、生成修复动作，再把提议的变更送进拉取请求机制（Nx，2025；Datadog，2026；Gitar，2026）。Dagger 发表了架构蓝图，说明如何在容器化的持续集成环境里用人工智能智能体构造自愈流水线（Dagger，2025）。

这些系统表现出与能动性相关的性质：感知流水线信号，在候选动作上做决策，并通过生成制品来执行。但用数据面和控制面的区分来看，所有公开记录的系统都把智能体行为集中在数据面。持续交付研究强调发布治理和部署纪律的重要性（Shahin 等，2017；Fitzgerald 和 Stol，2017；Humble 和 Farley，2010）。作者考察过的系统里，没有任何一个在没有人批准的情况下，把控制面权限交出去。控制面权限包括：修改部署策略、批准关口、回滚阈值或工作流定义。这与近期经验证据一致：智能体与 CI/CD 配置的交互，频率仍然有限，成功率也不一（Ghaleb，2026）。

2.3 架构含义

当前系统里观察到的有界自主，有架构上的后果。CI/CD 流水线传统上是确定性的执行图，由明确的批准关口和有纪律的部署策略治理（Fitzgerald 和 Stol，2017；Shahin 等，2017）。引入智能体组件，是把自适应的决策环嵌进这些结构。

这些结构像自主系统研究里的反馈环架构，尤其是 MAPE-K 参考模型：在共享知识之上做监视、分析、规划、执行（Kephart 和 Chess，2003；White 等，2004）。但这个类比在重要方面是有限的。MAPE-K 假设只有一个被管元素，以及一份定义清楚的适应策略；控制环通常由系统架构师设计，并对反馈机制拥有全部权限（Cheng 等，2009；Huebscher 和 McCann，2008）。在 CI/CD 流水线里，权限是被社会过程居中调节的：多个人类干系人（开发者、评审者、发布经理）分担治理责任，「被管元素」跨越的是组织过程，而不只是技术基础设施。一个修改部署阈值的智能体，不是在单纯执行控制环，而是在介入一套社会技术治理结构。数据面与控制面的区分抓住了这个差别：数据面动作像是有界执行上下文里的经典 MAPE-K 适应；控制面动作改变的是治理结构本身，MAPE-K 并不覆盖这一点。能力扩展时，流水线架构应把权限边界写明，区分建议角色、半自主角色和控制面角色。

一个重要的开放问题是自主升级。智能体从数据面干预走到控制面修改时，权限的小幅扩张可能随时间复合。例如，起初只允许生成补丁的智能体，后来可能被允许修改工作流定义或部署阈值。每一次增量扩展在局部看起来都有道理，合在一起却可能把有效的发布治理，从以人为中心的评审，推向由智能体居中的控制。理解这种升级如何发生，以及如何在不取消有用自动化的前提下把它框住，是关键的设计与政策挑战。

进一步的担心是对抗稳健性。生成工作流配置或修改流水线制品的智能体，给供应链妥协开了一块新的攻击面。一项通过了持续集成检查、却引入隐蔽漏洞的智能体提议，可能比常规的恶意提交更难发现，因为评审者可能对智能体生成的制品给予没有根据的信任（Mittal 和 Venkatesan，2025）。同样，提示注入，或对智能体所观察信号的操纵（例如精心构造的日志或错误输出），可能把修复行为引到意料之外的方向。这些风险在控制面上被放大：被攻破的修改可以在组织层面影响发布治理。智能体式 CI/CD 的安全含义，因此超出单个制品的机密性和完整性，延伸到交付过程本身是否可信。

2.4 小结

在作者考察的系统里，主导模式是：半自主智能体嵌在人治理的工作流里，权限有界，动作空间受约束。下面把这些模式写成明确的观察。

3 核心观察

对研究原型和工业系统的分析，露出三条一致的模式。作者把它们呈现为概念主张。主张以观察到的系统行为为根据，用来刻画智能体式 CI/CD 的现状。

3.1 观察 1：受约束的自主占主导

许多系统被描述成智能体式的，但多数在收得很紧的有界自主下运转。从 Repairnator 到 RepairAgent 和 ChatRepair 的研究原型会生成补丁，但把集成决策留给人类评审者（Monperrus 等，2019；Baudry 等，2021；Bouzenia 等，2025；Xia 和 Zhang，2024）。多个厂商的工业工具同样把生成的变更送进拉取请求或合并请求工作流（GitHub，2026b；GitLab，2026；Nx，2025）。

实践里，这些系统是在预先划定的动作空间里行使被委托的权限，而不是独立控制流水线编排或部署策略。如前所述，没有任何公开记录的系统在没有人批准的情况下委托控制面权限。主导模式是嵌在既有治理结构里的半自主协助。这与更早一次转变相似：从手工发布工程转到自动化的 CI/CD 工作流时，自动化加快了执行，却没有立刻取代人的发布权（Shahin 等，2017；Adams 和 McIntosh，2016）。智能体式 CI/CD 看起来走的是类似的增量轨迹。这暗示当前的有界自主均衡不是偶然的，而是组织把自动化吸收进对治理敏感的过程时反复出现的模式。

3.2 观察 2：安全负担由治理承担

当前智能体式 CI/CD 系统里的安全与问责，主要靠外部治理机制实现，例如拉取请求批准工作流、仓库权限和策略关口，而不是靠智能体的内在保证。所评系统里，没有一个使用对智能体行为的形式验证，也没有独立于外围基础设施的内建安全约束。

依赖外部治理有一条关键含义：当智能体能力扩到更宽的规划和制品修改（Hou 等，2024；Liu 等，2024），安全模型就完全取决于外围控制的强度和覆盖。对权限边界和升级路径的显式推理，在当前研究和工业文档里大体缺席。治理层因此成为一个未被审视的单一信任点。

这种治理优先的安全模型，呼应 DevSecOps 集成里见过的模式：安全自动化通常嵌在受策略约束的工作流里，而不是被授予不受约束的权限（Anugula 等，2025；Mishra 和 Otaiwi，2020）。把类似约束延伸到智能体式 CI/CD，说明自主的扩张很可能继续由合规和风险管理要求来居中调节。

3.3 观察 3：评测落后于部署

许多工业平台现在提供智能体式 CI/CD 功能（GitHub，2026b），对这些系统的系统化评测方法仍然不发达。先前综述强调的传统 CI/CD 指标，例如构建时长、部署频率和失败率（Mishra 和 Otaiwi，2020；Shahin 等，2017；Fitzgerald 和 Stol，2017），是为确定性自动化设计的。它们抓不住决策质量、对约束的遵守、升级行为，或长期的治理影响。已有的 AIOps 和 DevOps 评测框架，主要评估异常检测准确率和运行性能增益（Notaro 等，2021；Mishra 和 Otaiwi，2020）。近期经验工作则指出，生成式人工智能系统缺少清楚的正确性标准，也难以用确定性方式评测（AlMulla 等，2025）。这些做法因此不适合那种会自主生成并在仓库制品或部署上执行动作的智能体系统。

评测必须超出任务级正确性，走向系统级评估。一个智能体可以成功修好一次失败的构建，同时加重评审者负担、触发不稳定的回滚级联，或微妙地重塑治理实践。这类社会技术效应，常规的 CI/CD 基准方法抓不住，目前也没有评测框架以标准化方式把它们算进去。

三条观察汇到同一个结论。受约束的自主之所以持续（观察 1），是因为安全负担由治理机制承担（观察 2）；而缺少评测框架（观察 3），又使替代设计无法被系统验证。合在一起，这些约束说明：智能体式 CI/CD 首先不是模型能力问题，而是社会技术交付系统内部决策权的再分配。弄清权限如何被框住、被评测、被协调，因此是中心的研究挑战。

4 研究议程

作者列出四个研究方向，按紧迫程度排序。控制面安全最紧迫，因为它对准的是能力扩张里风险最高的前沿。其余方向提供概念、经验和组织上的基础，用来支撑安全的委托。

4.1 控制面安全与治理机制

如前所述，当前系统回避控制面委托。扩进控制面修改会引入不同的风险，因为这类变更影响的是治理，而不是单个制品。对抗风险在控制面上尤其关键：一次被攻破的修改可以影响后续发布。

需要针对 CI/CD 的安全机制研究，包括感知策略的智能体、受约束的动作合成，以及带形式保证的自动回滚策略。MAPE-K 模型为反馈环设计提供基础（Kephart 和 Chess，2003；Cheng 等，2009），但必须扩展，以计入 CI/CD 流水线里被社会过程居中调节的权限，以及多方干系人的治理。

4.2 把自主边界形式化

当前系统以临时方式实现有界自主，通常靠拉取请求工作流和仓库权限来约束智能体行为。需要一套有原则的框架，用来规定并核验 CI/CD 流水线里的自主边界。这样的框架可以建立在访问控制、策略规定和运行时监控之上（Huebscher 和 McCann，2008），并把这些想法扩到分级的委托权限，而不是二元的允许或拒绝。近期关于大模型智能体可观测性的工作（Dong 等，2024）表明，对智能体决策做运行时监控是可行的，并可能用来执行形式化的边界。

一个实践方向，是在流水线架构里显式建模决策权、动作范围和升级路径。这样的模型会把自主当成可配置的设计参数，而不是涌现出来的副作用。作者提出的数据面与控制面区分，为这类规定提供一套起始词汇。

4.3 智能体式 CI/CD 的评测框架

已有 CI/CD 指标忽略决策质量、对约束的遵守和治理影响。这个领域也缺少用来比较自主水平和权衡的基准。SWE-bench（Jimenez 等，2024）这类近期基准，用补丁生成评测基于大模型的智能体如何解决 Issue，主要抓住的是数据面能力。它们不抓住控制面方面，例如策略约束、批准工作流或治理决策。这促使人们去做 CI/CD 专用的评测框架。

未来工作应开发能抓住真实流水线工作流、批准过程和失败场景的评测环境。相邻领域已有相关努力：AIOpsLab 在云运维里评测人工智能智能体（Chen 等，2025）；ITBench 为智能体评测提供多样的真实信息技术自动化任务（Jha 等，2025）；AIDev 分析开发工作流里由智能体撰写的拉取请求（Li 等，2026）。但还没有可比的、标准化的 CI/CD 流水线环境，能同时抓住批准关口、策略约束、控制面变更和人的否决。

评测标准应包括稳定性、透明度、人的否决频率和长期效应。一个可下手的入口，是一份最小协议，把修复有效性和治理成本、稳定性成本分开。它借鉴 CI/CD 与 DevOps 的视角（Shahin 等，2017；Mishra 和 Otaiwi，2020），以及 AIOps 对失败管理的关切（Notaro 等，2021）。智能体式 CI/CD 的基准套件应报告四类内容：

这样报告，才能比较不同的有界自主设计，而不把完全自主当成目标结果。

4.4 人与智能体的协调模型

当前系统严重依赖人在回路里的批准，但很少有研究考察开发者如何理解或否决这些决策。

事故响应时，智能体和值班工程师之间权限含糊，可能拖延缓解，或产生互相冲突的动作。需要交互模型方面的研究，把责任边界说清，并防止这类情形里的权限含糊。AIDev（Li 等，2026）这类经验数据集，为研究智能体与开发者的交互提供了基础，但 CI/CD 专用的数据集仍然缺失。

推进智能体式 CI/CD，需要四个方向都有进展，而控制面安全是使能的前提。若没有能框住控制面权限的治理机制，更宽的自主委托就可能损害 CI/CD 当初要落实的发布纪律（Fitzgerald 和 Stol，2017；Humble 和 Farley，2010）。

5 局限

讨论部分依赖公开的工业文档。这些文档可能不完整，也可能受营销影响，所以作者优先写可观察的性质，而不是性能宣称。这个领域变化很快，关于结果的公开证据仍然有限，因此作者强调权限和治理，而不是长期有效性。

6 结论

智能体式 CI/CD 最好被刻画为有界自主：智能体在人治理的批准结构里操作，而不是行使独立控制。跨系统可见三条模式：受约束的自主，由外部治理来落实的安全，以及部署与评测之间的缺口。数据面与控制面的区分把利害说清楚了：当前系统之所以还安全，是因为把智能体限制在数据面；这条边界会越来越受到考验。权限转移是中心挑战。眼前的优先事项是控制面安全与治理，其后是自主边界、评测框架，以及人与智能体的协调。把权限转移当成一等设计问题，对安全、可问责的智能体式 CI/CD 系统是必要的。

致谢。作者感谢加拿大自然科学与工程研究理事会（NSERC）的支持，资助号 RGPIN-2021-03969。