Agentic Development Cycle：以Agent为中心的开发周期
- 本文基于 Sonar 提出的 AC/DC 框架进行技术探讨，文中提及的产品名称仅为说明具体实现而引用，框架思想本身不绑定于特定厂商。
2026 年 3 月，Sonar 在年度峰会上正式提出了一个名为 AC/DC 的新框架。首字母缩写指向的不是摇滚乐，而是 Agent Centric Development Cycle——以Agent为中心的开发周期。它的核心主张是：传统 CI 模型在设计时没有预见到 AI Agent 的工作方式，软件开发需要一个能容纳 Agent 的新周期模型。
这不是危言耸听。Carnegie Mellon 大学对 807 个使用 AI 编码Agent的开源项目做了跟踪研究，结论很直接：Agent确实带来了短期的速度提升，但这种提升在第三个月就消失了；与此同时，代码分析告警持续增加 30% ，代码复杂度持续增加 41% 。速度上去了，债务也积累下来了。
这个数据揭示的矛盾并不复杂：AI 生成代码的速度远远超过了人类验证代码的能力。当一个 PR 从 300 行膨胀到 3000 行，当代码有 42% 来自 AI Agent（Sonar 2026 年开发者调查数据），靠人肉 review 来兜底质量，已经不是”累不累”的问题，而是”兜不兜得住”的问题。
AC/DC 的核心思路很直接：把验证从代码写完之后前移到代码生成的同时，让 Agent 边写边验、边验边修，形成一个自纠正的闭环。
AC/DC：以 Agent 为中心的开发周期
Guide 引导上下文注入 · 规则定义Generate 生成沙盒产出 · 方案先行Verify 验证Agent 自检 · 系统兜底Solve 修复自动修复 · 经验反馈内环 · 边写边验外环 · 经验反哺 Guide双层循环架构内环（微观 · 速度优先）Agent 每一步推理中自检：生成代码→ 调用分析工具验证 → 发现问题即修正外环（宏观 · 安全兜底）沙盒完成后确定性全面扫描 → 修复Agent 处理问题 → 验证修复 → 反馈 Guide人类工程师角色重定义约束定义者架构边界 · 编码规范 · 安全策略质量审核者关键节点审核 · 确认方案方向架构决策者系统演化 · 模块划分 · 债务优先级
一、传统 CI 在设计上就没考虑过Agent
Section titled “一、传统 CI 在设计上就没考虑过Agent”持续集成（CI）诞生于人类开发者协作的时代，它的基础假设是：代码由人编写，每次提交量可控，review 由人完成，质量门禁在 CI 管道中按顺序执行。但 Agent 的工作方式完全不同——它们异步工作、批量产出，单次 PR 可能跨越多个文件甚至多个模块，提交不是”写完一段提交一次”而是”生成完一批再统一提交”。CI 管道在这个场景下变成了被动等待的瓶颈：代码已经写完了，质量检查才刚刚开始。
Sonar 的 VP Jeremy Katz 在 RSAC 2026 上的表述更直接：“当前最大的安全缺口不在 CI 之后，而在 CI 之前。开发者和 AI Agent以极高速度生成代码——如果没有前置验证，漏洞会持续累积。”
换句话说，问题不是 CI 做得不够好，而是它的位置不对。当 Agent 可以在几分钟内生成几千行代码时，把质量检查放在代码写完之后的 CI 管道里，等于让消防队在大火烧完后再去检查火源。AC/DC 正是为解决这一结构性错位而设计的：它不需要推翻 CI，而是把验证从 CI 管道末端前移到 Agent 生成代码的当下，同时补上 CI 最缺的两块能力——生成前的上下文注入和生成后的自动修复。
二、AC/DC 四阶段：一个自我改进的闭环
Section titled “二、AC/DC 四阶段：一个自我改进的闭环”AC/DC 把软件开发重新组织为四个阶段，每个阶段都围绕Agent的能力和局限来设计，而不是把人类的工作流硬套给机器。
AC/DC 四阶段闭环
| Guide |
| 引导 | 向Agent注入项目上下文：架构边界、编码标准、安全策略。Agent在动笔之前就知道”游戏规则”。 |
|---|---|
| Generate | |
| 生成 | LLM 在正确上下文中生成代码。代码在沙盒环境中产生，不直接触碰主分支。 |
| Verify | |
| 验证 | Agent自行检查代码是否达到可靠性、可维护性、安全性标准。确定性规则引擎 + 跨文件上下文分析。 |
| Solve | |
| 修复 | 验证发现的问题自动反馈给修复Agent，修复后重新验证。修复经验反馈回 Guide 阶段，持续优化下次引导。 |
注意这个闭环的最后一环：Solve 阶段的经验会反哺 Guide。这不是一次性流水线，而是一个越跑越精准的学习循环。
Guide：不让Agent”盲飞”
Section titled “Guide：不让Agent”盲飞””Guide 阶段解决的是Agent最根本的短板：它不了解你的项目。一个通用大模型可以写出语法正确的代码，但它不知道你的团队用什么架构模式、遵循什么安全规范、有哪些历史踩坑教训。
Sonar 为此提供了 Context Augmentation（上下文增强） ——通过 MCP（Model Context Protocol，模型上下文协议，一种让外部工具向大模型实时注入信息的标准协议）向Agent工作流中注入项目特定的上下文洞察，比如当前任务相关的编码规则、类型层次、引用关系和架构蓝图。这也是 AC/DC 框架中 Guide 环节的典型实现方式。
关键设计是”按需注入”而非”全量灌输”。不是把整个规则库塞进 prompt，而是只提供当前文件、当前任务所对应的那部分上下文。早期基准测试显示：构建通过率和测试通过率显著提升，代码重复率和认知复杂度明显下降，token 消耗量也降低了。
Generate：在沙盒中产出
Section titled “Generate：在沙盒中产出”生成阶段本身并不复杂——Agent在隔离沙盒中生成代码，使用任何编码工具（Claude Code、Cursor、Copilot、Codex 等）。
但 AC/DC 对生成阶段有一个不同于常规实践的取向：它提倡Agent先产出方案说明，经确认后再实现。 这不是为了增加流程负担，而是让人类在架构层面保留决策权——Agent提出”怎么实现”，人确认”方向对不对”，然后再让Agent落地编码。这种”先方案后实现”的模式，本质上是在生成阶段内置了一道人类审核点。
Verify：Agent要能自证清白
Section titled “Verify：Agent要能自证清白”这是 AC/DC 最核心的创新。传统流程中，验证发生在 CI 管道里——代码提交、PR 创建、CI 运行、质量门禁检查。如果失败了，开发者回来修，再提交，再跑 CI。Agent在这个模型中只是一个”代码生产者”，验证是别人的事。
AC/DC 把验证变成了Agent自己的责任。在具体实现中，Agent在生成代码的同时调用静态分析工具，让确定性规则引擎实时检查它的工作。这和普通 linter 有本质区别：这类分析工具做的是跨文件上下文分析，能发现单文件 linter 看不到的问题——比如一个函数修改了共享状态但没有更新所有调用方。
验证分为两层：
内环验证 ：Agent在每次推理步骤中自我检查——代码刚写完就立即验证，发现问题当场修正。这是”边写边验”。
外环验证 ：Agent完成全部工作后，进行全面的、跨文件的确定性分析，确保没有任何遗漏。这是”写完再验一遍”。
两层验证之间有一个关键差异：内环依赖Agent的”自觉”——它调用分析工具、读取结果、自行修复。外环则是确定性的——无论Agent是否主动验证，外环都会执行完整扫描。这构成了安全网：Agent可以漏，但外环不会漏。
这两层验证实际上构成了 AC/DC 最关键的工程结构——双层嵌套循环 。内环追求速度，Agent 在每一步推理中边写边验；外环保证安全，在沙盒工作完成后执行确定性全面扫描。两层之间不是”先松后严”，而是”Agent 自检 + 系统兜底”，这正是 AC/DC 区别于传统 CI 流水线的核心。
Solve：修复不该是人的专属工作
Section titled “Solve：修复不该是人的专属工作”验证发现的问题，交给 修复Agent（如 SonarQube Remediation Agent） 处理。它有两种典型工作模式：针对新 PR 中标记的问题即时生成修复；以及系统性地清理主分支上累积的历史技术债务，每个问题一个独立 PR，开发者可以逐个审查和合并。
每个修复都会被确定性规则引擎重新扫描确认。修了不代表修好了——验证再次介入，确保不会引入新问题。
三、传统 CI 与 AC/DC 的结构性对比
Section titled “三、传统 CI 与 AC/DC 的结构性对比”两者的差异不是”CI 做得不够好，AC/DC 做得更好”，而是根本的设计理念不同。
| 对比维度 | 传统 CI | AC/DC |
|---|---|---|
| 设计原点 | 以人类开发者为中心 | 以 AI Agent为中心 |
| 验证时机 | 代码提交后，CI 管道中 | 代码生成时，实时验证 |
| 质量责任 | 人类开发者 + CI 门禁 | Agent自检 + 确定性系统兜底 |
| 上下文注入 | 开发者凭经验和文档理解 | MCP 实时注入项目特定规则 |
| 缺陷修复 | 人工返回修改 | 修复Agent自动修复 + 人工审核 |
| 学习机制 | 事后复盘，人工沉淀 | Solve 经验自动反馈到 Guide |
四、人类角色的重新定义
Section titled “四、人类角色的重新定义”当验证和修复都由Agent闭环完成，一个自然的问题浮现：人类工程师的位置在哪里？
AC/DC 给出的答案不是”人被替代”，而是角色重新分工。人类工程师从三个传统职责中退出，同时获得了三个新的核心职责：
工程师角色的再分工
| 退出的传统职责 | 获得的核心职责 |
|---|---|
| 逐行编写实现代码 | 约束定义者：定义Agent必须遵守的架构边界、编码规范和安全策略 |
| 逐行 review AI 生成的代码 | 质量审核者：在关键节点审核Agent的输出，确认方案方向，而非检查每一行代码 |
| 手动修复 CI 报出的问题 | 架构决策者：决定系统如何演化、模块如何划分、技术债务的优先级排序 |
这个转变是把”执行”从人类的工作中剥离出去，同时把”判断”保留在人类手中。Agent负责落地，人负责定义什么是”好”的落地。
Anthropic 2026 年趋势报告中的表述与此呼应：程序中约 60% 的工作使用了 AI 辅助，但只有 0-20% 的任务可以”完全委托”给Agent。 人类判断力仍然不可替代——它只是从编码层面提升到了架构和约束层面。
这反过来对工程师提出了新的能力要求：不仅要会写代码，更要会”写约束”——能把团队的工程标准转化为Agent可以理解的规则、规范和质量定义。写代码的能力变成了定义代码质量标准的能力。
五、落地路线图：从何处开始
Section titled “五、落地路线图：从何处开始”AC/DC 不是一夜之间替换 CI 的方案。框架的配套工具（Context Augmentation、Agentic Analysis、Remediation Agent）目前均处于公开 Beta 阶段，以 SonarQube Cloud 的 Teams 和 Enterprise 用户为例可免费使用。
从现有的工程实践出发，过渡到 AC/DC 大致可以分三步走：
AC/DC 落地三步走
1. 先在低风险场景中引入 Guide 机制 ：为Agent配置项目级 AGENTS.md 或 Conductor 文件，至少让Agent知道你的编码标准和架构约束，再让它动手写代码。
2. 在已有代码分析平台的团队中启用 Agentic Analysis ：让Agent能在生成代码时调用分析工具自我验证。先跑通内环，验证通过率和修复率稳定后再开启外环。
3. 在质量门禁稳定的项目中试点 Remediation Agent ：让修复Agent处理低风险、高置信度的质量问题，人工审核修复结果，积累信任后再扩大自动化范围。
4. 闭环反馈：收集 Solve 阶段的修复模式和频率数据，反向优化 Guide 阶段的上下文注入策略——让Agent下次少犯同类错误。
关键原则：不要一开始就追求全自动。先让Agent做好”自检”，再逐步扩展”自修”的范围。信任是一步步建立起来的，不是配置一开就能到位的。
不得不说：
AC/DC 框架虽然看上去完整，但有几个关键问题目前还没有明确的答案：
评估标准的缺失 ：如何衡量Agent自验证的有效性？Agent”自认为修好了”和”真的修好了”之间的差距有多大？目前缺乏系统性的评估方法。
治理粒度 ：Agent的自主权可以开到什么程度？哪些质量门禁必须由人类确认？这个边界在不同团队、不同项目中差异巨大，目前没有共识。
人机注意力的经济学 ：当Agent产出速度提升 10 倍，人类的审核带宽没有同步提升。哪些环节必须投入人类注意力，哪些可以委托给系统？这个分配问题还没有成熟的答案。
技术债务的代际转移 ：Agent生成代码 → Agent修复问题 → Agent继续生成更多代码，这个循环如果缺乏人类的架构审视，可能会导致技术债务以更隐蔽的方式积累。
叹一声：AI的工程化任重道远，还需要摸着石头过河！！！