大家好，我是玄姐。

PS：

Harness 工程干货直播，欢迎点击预约，直播见。

CI/CD 正在经历一次本质性升级：从“可编排的自动化流程”，演进为“具备上下文理解能力的自治系统”。

传统流水线解决的是执行问题：如何稳定、快速、可重复地完成构建与发布；

而 Agent 引入后，开始触及判断问题：如何理解失败原因、评估变更风险、选择最优动作。

关键变化不在于用 AI 替换现有工具（如 Jenkins、GitHub Actions、GitLab CI 或 Kubernetes），而是在其之上叠加一层具备感知、规划与执行能力的协同系统。

Agent 让交付流程从：

• “按步骤完成任务”

→ 转变为

• “围绕目标完成交付”

  

但这种“智能自治”必须受到工程约束：权限最小化、行为可审计、过程可追溯、人类可介入，缺一不可。

一、范式迁移：交付瓶颈从执行转向认知

过去十年，CI/CD 的核心路径非常清晰：

脚本化 → 流水线化 → 云原生化

我们成功解决了：

• 自动执行

• 稳定复现

• 快速回滚

但新的瓶颈不再是“跑不动”，而是：

系统不会判断

典型场景：

• 构建失败 → 人看日志

• 覆盖率下降 → 人补用例

• 发布风险上升 → 人做决策

流水线能执行，但无法理解：

• 为什么失败？

• 应该怎么修？

• 风险是否可接受？

Agent 改变了什么？

Agent 将分散信息重组为可推理上下文：

• 日志（Logs）

• 指标（Metrics）

• 代码差异（Diff）

• 历史记录（History）

使流水线具备一种新的能力：

从执行引擎 → 判断系统

二、角色重构：人从操作流程转向设计边界

在传统模式中，工程师承担两类工作：

• 设计流程（写 Pipeline）

• 弥补流程（处理异常）

随着复杂度提升，第2类工作不断膨胀。

Agent 引入后的分工变化：

角色	职责
人	定义目标、约束、边界
Agent	在边界内执行与决策

本质变化：

人不再“操作系统”，而是“设计系统如何自动操作”

这直接带来一个管理上的转向：

• 从“人是否高效”

→ 转向

• “系统是否可靠”

三、能力架构：感知 → 规划 → 执行 → 记忆

Agent 化 CI/CD 本质是一个四层系统：

1. 感知层（Perception）

输入来源：

• Git 事件（PR / Commit）

• 构建日志

• 监控系统（如 Prometheus）

• 调用链与告警

核心能力：

将“噪声数据”转化为“问题上下文”

输出示例：

• 错误摘要

• 关联指标

• 疑似根因

2. 规划层（Planning）

核心能力：

在执行前生成“可解释的行动路径”

例如：

• 先验证告警范围

• 再对比版本差异

• 决定回滚 or 扩容

关键价值：

• 避免“直接操作”

• 支持审计与复盘

3. 执行层（Action）

通过工具调用落地：

• 构建 / 测试 / 部署

• 创建 PR

• 调用 CLI / API

• 操作集群（kubectl）

但必须分级：

操作类型	策略
只读	自动
低风险写	限制自动
高风险	必须审批

4. 记忆层（Memory）

区别于传统脚本：

Agent 能“记住项目”

包括：

• 常见失败模式

• 依赖约束

• 团队偏好

• 发布策略

但必须治理：

• 是否可跨项目？

• 是否含敏感信息？

• 生命周期多久？

四、集成路径：从工具接入到混合流水线

1. 标准接口：MCP 类协议

问题：

DevOps 工具链高度碎片化

Agent 需要统一接入方式：

• 仓库

• 集群

• 监控

• IaC（如 Terraform）

MCP 的价值：

把工具能力“标准化暴露”给 Agent

2. 能力封装：Skills 模式

将复杂操作封装为稳定能力：

• 代码审查

• 镜像构建

• 发布策略

• 安全扫描

优势：

• 降低风险

• 提高复用

• 易于审计

3. 现实路径：混合流水线（最关键）

不要一上来“全 Agent 化”。

更合理路径：

传统 Pipeline + Agent Step

典型插入点：

• PR 审查

• 测试失败诊断

• 发布前风险评估

• 告警分析

演进路径：

• 只读分析

• 给建议

• 生成变更（PR）

• 小范围自动执行

五、落地场景：优先攻克“高认知成本环节”

1. 代码审查

从规则检查 → 上下文理解

Agent 能：

• 结合 PR + 历史

• 识别潜在风险

• 自动生成补丁

但必须：

不直接 merge

2. 测试生成与维护

从“补用例” → “维护测试资产”

能力包括：

• 自动生成测试

• 识别失效用例

• 发现覆盖盲区

3. 构建失败诊断

从：

“自己看日志”

变成：

“直接给根因 + 建议”

这是 ROI 极高的切入点。

4. 发布与运维（最强但最危险）

Agent 可：

• 发布前风险评估

• 生产异常分析

• 自动扩容 / 回滚

但必须严格分级：

风险等级	是否自动
低	是
中	半自动
高	否

六、治理体系：智能必须被工程化约束

1. 权限治理（零信任）

Agent 必须拆分身份：

• 审查 Agent（只读）

• 测试 Agent（可写但不可合并）

• 部署 Agent（限定环境）

• 运维 Agent（强审计）

2. 可观测性（核心基础设施）

必须记录：

• 输入上下文

• 推理过程

• 工具调用

• 最终动作

否则：

Agent = 黑盒

3. 成本治理

策略：

• 简单任务 → 脚本

• 复杂任务 → Agent

• 高风险 → Agent + 人

衡量指标：

• MTTR 是否下降

• 交付周期是否缩短

• 人工负担是否减少

4. 组织治理

管理对象发生变化：

从“人” → “人 + Agent 系统”

关键问题：

• 哪些任务允许自动？

• 哪些必须人工？

• 何时降级？

七、趋势判断：从流水线到“Agent协作网络”

未来 CI/CD 可能演变为：

多个 Agent 协作：

• 需求 Agent

• 开发 Agent

• 测试 Agent

• 发布 Agent

• 运维 Agent

形成：

交付系统的“多智能体网络”

但关键结论是：

智能自治 ≠ 无人系统

而是：

把不确定的 AI，纳入确定的工程边界

八、结语

真正成熟的 Agent 驱动 CI/CD，不是让机器替代工程判断，而是：

让工程判断，被更早、更稳定、更系统地嵌入交付流程之中。

PS：

Harness 工程干货直播，欢迎点击预约，直播见。

好了，这就是我今天想分享的内容。如果你对构建企业级 AI 原生应用新架构设计和落地实践感兴趣，别忘了点赞、关注噢~

—1—

加我微信

扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇

加星标★，不错过每一次更新！

⬇戳”阅读原文“，立即预约！