https://t.co/COWVOjkOrw
TL;DR · AI 摘要
循环工程通过代理与人类协作重构软件开发流程，实现从触发到交付的全链路自动化。
核心要点
- 团队级循环工程需设计代理系统与人类判断点的协同机制
- 代理可执行代码修改、测试运行等中段SDLC任务
- 与传统自动化相比，代理承担80%执行工作且人类介入点可设计
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- 循环工程
- 定义
- 代理+人类协同系统
- SDLC全链路覆盖
- 核心差异
- 执行主体：代理主导
- 人类角色：设计介入点
- 实施层级
- 个人级循环
- 团队级生产系统
金句 / Highlights
值得收藏与分享的关键句。
代理现在能执行代码修改、测试运行和结果审查等中段SDLC任务
团队级循环工程是将触发到交付的全链路设计为持续运行的系统
与传统自动化不同，代理承担80%执行工作且人类介入是系统设计的一部分
Augment Code 在 X 上的动态：https://t.co/COWVOjkOrw / X
[](https://x.com/)
*
 Augment Code @augmentcode
什么是循环工程？领先软件工程团队如何应用它？
“循环工程”目前正处于风口浪尖。
Boris Cherny 提到他现在不再提示 Claude，而是编写循环。Peter Steinberger 发布了月度提醒，建议停止提示代理，转而设计能提示代理的循环。另一方面，有人指出围绕大语言模型（LLM）调用的循环本质上仍然是一个 while 循环，而我们在拥有代理之前就已经有了定时任务（cron jobs）和 Webhook。
我认为这种批评忽略了正在发生的重要转变：循环内部的工作内容发生了变化。现在，代理可以以相当高的质量进行调查、修改代码、运行测试并审查结果。软件开发生命周期（SDLC）的中段——过去人类花费大量时间处理重复任务的环节——现在可以设计为代理与人类协同工作的自主系统的一部分。
目前的讨论大多集中在单个循环上：一个开发者使用代理推进任务。但我认为，更重要的是团队层面的模式正在浮现。
最优秀的工程团队开始在生产环境中运行代理式 SDLC 循环：始终在线的系统，能够跨整个软件开发生命周期从触发到验证结果完成工作，并在需要判断的关键环节引入人类。
那么，什么是循环工程？
在团队层面，循环工程是指设计一个系统，让代理团队朝着某个目标协作，仅在需要判断的关键环节引入人类。工程的难点在于选择合适的系统设计、为每个任务选择合适的模型，并知道何时引入人类，以确保循环产出更高质量的结果。
团队层面的循环将触发器、代理、人类检查点和交付结果连接成一个可重复的系统。
循环工程与自动化有何不同？
- 代理承担了大部分执行工作
在人工智能出现之前的软件自动化中，系统可以路由、通知并连接其他系统，但无法分析堆栈跟踪、编写修复代码并重新运行测试套件。过去需要人工参与的工作流程中段，现在可以完全由代理完成。这代表了一种全新的工作类型，需要重新思考哪些任务可以转化为循环。
- 人类按设计参与循环，而非作为失败模式
在传统的 DevOps 风格自动化中，人类的介入通常意味着系统出现了问题。而在代理循环中，人类检查点是最高价值判断发生的环节。它将高质量结果与持续运行并消耗资源的循环区分开来。
- 每次运行都能优化循环
定时任务每天以相同方式运行。而智能循环则可以利用之前运行产生的记忆和轨迹，随着时间推移不断改进。
每次运行都会产生轨迹：哪些操作成功了，哪些失败了，以及人类在何时介入并修正方向。这些轨迹可以反馈到系统中，用于提升整体质量：优化提示语、测试用例、验收标准、工具或升级规则。
关键转变：从个人到团队级智能 SDLC 循环
最具前瞻性的团队正在超越个人循环，构建面向团队的循环：建立持续运行的标准化工作流，让智能体在软件开发生命周期中处理重复性工作，而人类只在真正需要的时候参与。
我们开始将这些称为智能 SDLC 循环，其结构呈现出惊人的一致性。
智能 SDLC 循环的外层结构
触发：拉取请求打开、警报触发或工单到达。
执行：智能体执行核心流程：调查、复现问题、起草修复方案并运行测试。
验证：智能体和自动化系统执行可用的检查，当需要判断、审批或额外上下文时人类介入。部分循环每次都需要人类参与，而其他循环则可根据风险动态判断是否需要人类介入。
注意：验证和执行之间还存在一个微型循环。智能体会持续执行和验证，直到满足验收标准或需要升级时为止。
结果：当结果通过验证且满足验收标准时循环完成。
优化：团队利用运行轨迹来改进循环：找出哪些环节出错、哪些需要人类介入、以及下次如何更高效运行。
这些阶段描述了智能 SDLC 循环的外层结构，而非某个智能体必须依次完成五个步骤。在生产环境中，执行和验证阶段通常包含多个专业智能体，每个智能体都有自己的目标、工具和验收标准。
智能 SDLC 循环从触发到执行、验证、结果、优化依次推进。
最终，这个循环不仅产生输出，更推动实现具体结果——合并修复、分类事件、关闭漏洞。
关于循环最重要的部分是：一个没有人实际交付输出的循环不是成功的循环。真正能持续运行并带来最高投资回报率的循环，是那些真正完成某件事情的循环。
当前团队运行的循环
以下是我们目前在生产环境中最常见的智能 SDLC 循环。
代码审查循环
PR 打开（触发）→ 智能体分析风险、进行深度审查、发现问题并修复（执行）→ 人类审查意图而非逐行对比（验证）→ 批准并合并高质量代码（结果）
该循环演示了一个多代理SDLC循环。关键不在于代理数量，而在于目标的分离。一个系统评估风险，另一个执行工作，另一个尝试发现其中的缺陷，而人类仅在风险或歧义出现时才提供判断。
我们在Augment运行的代码审查循环。
当设计良好时，上述代码审查循环已证明其能以比传统代码审查机器人（仅对PR进行评论并等待人类反复关闭漏洞）更低的成本产出质量更高的PR。
Ticket-to-PR循环
Ticket到达（触发）→ 代理调查并起草代码，执行端到端测试（执行）→ 人类审查变更（验证）→ 可合并的PR（结果）
漏洞修复循环
CVE发布（触发）→ 代理识别受影响服务并起草补丁（执行）→ 人类批准（验证）→ 修复后的服务（结果）
事件响应循环
警报触发（触发）→ 代理提取日志，识别可能变更，起草时间线（执行）→ 值班工程师在完整上下文中加入并决定升级（验证）→ 已分类或缓解的事件（结果）
有趣的是，这些都不是新颖的工程循环。它们是SDLC中不那么光鲜、重复的中间阶段，这正是大多数工程时间真正消耗的地方。
将循环连接起来构建软件工厂
每个代理SDLC循环本身都能带来生产力的显著提升，但当循环开始相互连接时，真正的复利效应才开始显现。Ticket-to-PR循环触发代码审查循环。分类循环的发现成为Ticket循环的触发点。事件后分析会催生修复工作。
连接足够多的循环后，你不再需要逐个管理代理。你运行的是一个能够产出结果、自我衡量并持续改进的系统：一个软件工厂。
连接的代理SDLC循环复合成软件工厂。
我知道“工厂”这个词可能会让一些工程师感到不适，让我澄清一下。工厂与产量无关，更与低质量无关。它关乎可测量、可重复、质量门控的生产：以结果衡量吞吐量，通过流程捕获问题，让专业人员专注于最有价值的判断决策。
当设计循环本身成为团队优化的目标时，情况就发生了变化。人类检查点应设置在何处，我们是否仍然需要它们？我们如何改进验证系统？我们消耗的token是否真正产生了价值？你希望按每美元产出的结果来衡量循环，而不是按每美元产出的代码量。这是一个与“每个工程师与代理的生产力如何”完全不同的问题。
这种模式将超越术语本身
虽然“循环工程”这一特定术语可能不会长期存在（很多术语都是如此），但这种模式正在定义软件工程的未来：代理处理重复的中间工作，人类在判断时刻做出决策，而循环每次运行都能变得更好。
构建循环的团队并不是在追逐趋势或流行语，而是在创建一个系统。而那些能弄清楚如何让这些循环产生复利效应的团队，不仅会加快交付速度，还会运营一种完全不同的工程组织形式。
如果你已准备好开始构建智能SDLC循环，立即体验Cosmos。如果你想了解如何为团队构建这些智能SDLC循环的最佳实践，联系我们的团队。
关于循环的进一步阅读
3
4
11
19
-  Moez Zhioua @MoezZhioua 7月23日 我认为真正的优势在于将SDLC中重复的中间环节转化为可重复的循环，并使其自身反馈追踪信息。这种反馈机制能让代理持续优化，同时让工程师专注于高价值决策。通过实际交付成果而非原始token数量来衡量循环效果。显示更多 [](https://x.com/MoezZhioua/status/2080315153254334866/quotes)14
-  Mykhailo Sorochuk @sir4K_zen 7月23日 非常有见地，让代理处理中间环节确实能让工程师专注于高价值决策 [](https://x.com/sir4K_zen/status/2080259741926727962/quotes)16
- # 参与讨论