什么是循环工程Loop Engineering | Coding Agent | 子Agent | MCP协议 | 提示词工程 | AI开发效率 | 软件研发 | Addy Osmani

最佳拍档 · 2026-06-16 · 18м 32с · 31 193 просмотров · YouTube ↗

Топики: ai-loop-engineering

🎧 Аудио

📝 Summary

model=deepseek-v4-flash · prompt=summary-v7 · 5 028→3 207 tokens · 2026-07-20 11:47:02

🎯 Главная суть

Loop Engineering (циклическая инженерия) — это новый подход к работе с AI-агентами для разработки, при котором человек перестаёт вручную писать промпты каждому агенту и вместо этого проектирует автоматическую систему, которая сама запускает, проверяет и перезапускает агентов, пока не будет достигнут заданный результат. Основные coding agent-инструменты (Claude Code, OpenAI Codex) уже содержат все необходимые модули для построения таких циклов.

От ручного промптинга к автоматическим циклам

Последние два года стандартная практика выглядела так: разработчик писал подробный промпт, давал контекст проекта, ждал ответа агента, оценивал результат и отправлял следующую команду. Агент был инструментом, каждое действие требовало ручного триггера. Сейчас этот подход меняется. Питер Стайнберг из OpenCodex сформулировал: «Вы не должны вручную промптировать coding agent — вы должны спроектировать цикл, в котором агент работает автоматически». Борис Черни, руководитель Claude Code в Anthropic, подтвердил, что сам уже не пишет промпты вручную: «у меня работают десятки циклов, которые сами решают, что делать дальше, моя работа — писать эти циклы». Андрей Карпатый в проекте AutoResearch также заложил принцип полного исключения человека из цикла, чтобы система могла расходовать токены максимально интенсивно.

Пять модулей цикла: Automation

Сердце цикла — автоматизация. Она позволяет задать расписание запуска (например, ежедневно) и тип триггера. В Codex есть вкладка Automation: можно создать задачу, привязать проект, промпт, частоту (локально или в фоновом worktree). Если проблема найдена — результат попадает в инбокс, если нет — тихо архивируется. OpenAI использует это для рутинных задач: классификация новых тикетов, отчёты по сбоям интеграций, еженедельные дайджесты багов. Аналогично в Claude Code реализованы шедулеры и хуки: --loop для повторения с фиксированным интервалом, --go для непрерывного выполнения до достижения условия остановки (проверяет отдельная малая модель, не та, что пишет код). В Codex такая же команда называется Go-Go — работает через несколько диалоговых раундов, пока не выполнено верифицируемое условие.

Worktree: изоляция параллельных изменений

При одновременной работе нескольких агентов возникает классическая проблема — они могут редактировать один файл. Worktree решает это созданием независимой рабочей директории на отдельной ветке, но в рамках того же репозитория. Физически изменения разных агентов не пересекаются. В Codex worktree встроен в продукт, в Claude Code используется параметр --worktree для изоляции сессии или в конфигурации sub-agent’ов. Ограничение: «налог на проверку» (человек не может ревьювить бесконечно много кода за день) остаётся узким местом, независимо от числа потоков.

Skills: накопление проектных знаний

Каждый раз при запуске нового диалога приходится заново объяснять агенту структуру проекта, правила форматирования, способы сборки. Skills (навыки) решают эту проблему. В обоих инструментах навык — это папка с markdown-файлом, содержащим инструкцию и метаданные, плюс опциональные скрипты и ссылки. Система автоматически подбирает навык по совпадению описания с задачей. Это предотвращает «intent debt» (долг намерений): каждый раз, когда агент запускается без навыка, он вынужден додумывать, что часто не совпадает с реальными требованиями проекта. Навыки — формат контента, а плагины — способ распространения; можно упаковать несколько навыков в плагин и поделиться ими между репозиториями.

Connectors и Sub-agents

Если цикл может работать только с локальной файловой системой, его полезность ограничена. Connectors на базе MCP-протокола подключают агента к трекерам задач, базам данных, тестовым стендам, мессенджерам. Поскольку и Codex, и Claude Code поддерживают MCP, коннекторы часто взаимозаменяемы. Sub-agents — ключевая архитектура: генерацию кода и его проверку выполняют разные агенты. Один агент часто не замечает собственных ошибок; второй с другими инструкциями (или даже другой моделью) находит их. В Codex sub-agents настраиваются в конфигурационном файле: можно задать имя, описание, модель, уровень reasoning (например, для security review — мощная модель с высоким reasoning, для exploratory browsing — лёгкая модель с readonly). Claude Code позволяет собирать команды агентов, где задачи переходят от одного к другому (исследование → реализация → верификация). Это же механизм лежит в основе --go: агент, проверяющий условие остановки, — отдельный sub-agent.

Внешняя память и пример рабочего сценария

Все языковые модели «забывают» контекст между запусками. Поэтому циклу необходим внешний носитель состояния — markdown-файл, доска задач или любой другой объект, сохраняющийся между сессиями. Без него агент будет каждый раз начинать с нуля. Сборка всех модулей даёт картину: утром автоматический триггер запускает задачу на репозитории. Промпт использует навык классификации, читает логи CI, нерешённые тикеты, последние коммиты — результаты записываются в файл состояния или доску. Для каждой найденной проблемы создаётся изолированный worktree, запускается sub-agent для исправления, затем второй sub-agent проверяет правку по правилам проекта и тестам. Connector создаёт merge request, обновляет тикеты. Если цикл не может решить проблему — запись попадает в инбокс для человека. Всё это работает без единого ручного промпта. Логика идентична для Codex и Claude Code, поскольку модули у них одинаковы.

Три риска автоматизации

Верификация — цикл может «заявить», что задача выполнена, но эту декларацию нельзя принимать на веру. Человек остаётся единственным, кто отвечает за доставку работающего кода.
Понимание кода — чем быстрее цикл генерирует код, тем больше разрыв между написанным и осмысленным разработчиком. Растёт «долг понимания» (understanding debt). Единственный способ — регулярно читать весь сгенерированный код.
Когнитивная капитуляция — самое незаметное: когда цикл работает надёжно, человек перестаёт думать критически и просто принимает все результаты. Это ускоряет деградацию навыков. Разработчик должен проектировать цикл как инженер, а не как оператор «запуска». Разница в том, что происходит с вашим пониманием системы: один и тот же цикл может быть и ускорителем, и ускорителем деградации.

📜 Transcript

zh · 24 слов · 39 сегментов · clean

Показать текст транскрипта

大家好,这里是最佳拍档,我是大飞最近硅谷的AI技术圈又出现了一个全新的概念叫做循环工程,loop engineering不少一线从业者和技术负责人都提出程序员以后的核心工作可能不再是写提示词去调用coding agent了而是去设计一套能够自动驱动agent运转的循环系统甚至Cloud Code的负责人也公开表示自己现在已经很少直接给Cloud写提示词了大部分工作都交给自动运行的循环去完成那这个概念到底是什么意思呢它真的会改变程序员和AI协作的底层模式呢今天我们就结合谷歌云AI总监艾迪·奥斯曼尼的一篇深度分析把这个新的趋势给彻底讲清楚我们先从这件事情的背景说起过去大概两年的时间里我们和Coding Agent协作的方式非常直接你写一段清晰的提示词给足项目的上下文然后等AI输出结果你看完之后再输出下一段指令一轮接一轮的推进工作在这个模式里Agent更像一个你全程握持的工具每一步动作都需要人来触发和引导但是现在有越来越多的业内人士认为这个模式正在发生变化提出这个讨论的核心人物之一是OpenCloud的开发者彼得·斯坦伯格他的观点很明确你不应该再去手动提示Coding Agent了你应该设计让Agent自动运行的循环而Anthrobic旗下Cloud Code的负责人鲍里斯切尔尼也表达了几乎一致的看法他说自己现在已经不手动提示Cloud了而是有很多循环在后台运行他们负责提示Cloud判断下一步该做什么自己的核心工作就是编写这些循环甚至连安德烈卡巴西提出的Auto Research项目核心思路也是把人从循环里抽离出来让系统自主运行尽可能提升Token的吞吐量让人不再成为整个流程的瓶颈那所谓的循环工程到底是什么呢简单来说它就是用你设计的系统来替代你自己去完成对agent的提示和调度这里的循环可以理解成一个地规的目标你只需要定义最终的目的AI就会反复迭代执行直到目标完成一套完整的循环系统大概有五个基本的构建模块组成现在Cloud Code和OpenEd Codex这两款主流Coding Agent都已经完整具备了这五个模块的能力当然了我们也要客观的来说这个方向目前还处在非常早期的阶段很多问题还没有得到很好的解决最现实的问题就是Token的成本不同的使用模式下Token的消耗量差异非常大如果你的预算有限就必须非常谨慎的去规划循环的运行逻辑除此之外代码质量的下滑也是很多人担心的问题关于AI生成的代码质量越来越粗糙的担忧并不是空穴来风在无人职守的循环里这个问题会变得更加突出但是即便有这些争议这个方向依然值得我们深入了解因为它很可能就是未来我们和Coding Agent协作的雏形顺着这个方向往下看我们可以先理清楚几个相近概念之间的关系之前行业里有两个相关的概念一个叫Agent Harness Engineering也就是为单个Agent搭建运行的环境框架另一个叫做工厂模型也就是一整套构建软件的系统而循环工程的位置就在Agent Harness Engineering的上一层它相当于一个跑在计时器上的运行环境能够自主生成辅助用的子agent并且可以自我驱动持续运转有意思的是这件事情已经不再是需要开发者自己从零搭建的工具了就在一年以前如果你想跑一个自动循环还得自己写一大堆batch脚本然后长期维护这套脚本而且这套东西通常只能够你自己用很难迁移但现在这些核心能力已经直接内置到了主流的coding agent的产品里斯坦布哥总结的循环组成清单和codex的产品功能几乎一一对应和Cloud Code的功能也高度重合当你意识到不同工具的底层架构是完全一致的时候你就不会再纠结到底选哪款工具了只需要设计一套通用的循环逻辑不管用哪款工具都能够正常运行接下来我们就来拆解一套完整的循环系统到底有哪些部分组成一套能够稳定运行的循环需要五个核心的功能模块再加上一个独立的记载体我们一个一个来说第一个模块也就是整个循环的心跳叫做自动化自动化是让循环成为真正的循环而不是一次性手动运行的关键简单来说就是你可以给任务设定一个运行的周期让系统到点自动触发不需要你手动启动在Codex这款产品里你可以在专门的自动化标签页里创建任务选择对应的项目要运行的提示词执行的频率还可以选择是在本地代码的副本上运行还是在后台的工作树里运行每次运行之后如果发现了需要处理的问题结果就会进入分类收件箱如果什么问题都没有发现这次运行就会自动归档不会产生冗余的信息OpenAI内部就是用这套能力处理了很多重复性的日常工作比如说每天自动分类新提交的e-suit汇汇总持语集成失败的信息生成提交记录的简报或者排查上周新引入的bug而且自动化任务还可以直接调用skill这样你就不用把一大堆指令都粘贴到定时任务里只需要调用对应的Skill名称就行了后续维护起来也方便很多Cloud Code实现同样的能力用的是调度和钩子的方式你可以用-hook指令让一个提示词或者命令按照固定的间隔重复运行也可以设置定时任务按照自定义的周期执行还可以通过钩子功能在Agent生命周期的特定节点触发Share命令如果你想让任务在关掉电脑之后还能够继续运行也可以把整套流程推送到GitHub Actions上执行虽然实现的路径不一样但是核心的逻辑是完全相同的那就是定义一个自主运行的任务给它设定运行的节奏有结果会主动反馈给你你不用主动去四处检查进度除了后台定时运行的自动化还有一个绘画内的基础功能值得了解它也更贴近于循环工程的核心刚才我们提到的-loop是按照固定的节奏重复运行而还有一个-go指令则会持续运行直到你设定的条件真正达成每一轮执行结束之后会有一个独立的小模型来检查目标是否完成也就是说写代码的agent和判断有没有写完的agent不是同一个你只需要给出类似于保证认证模块的所有测试全部通过并且代码格式检查没有问题这样的停止条件就可以不用盯着进程让它自己运行了Codex里也有完全一样的功能名字也叫做GunGo它可以跨多轮对话持续工作直到可验证的停止条件成立同时支持暂停恢复和清除任务同样的技术能力两款主流工具都已经实现了这其实也能够看出整个行业的发展方向是高度一致的自动化模块的作用是把潜在的工作任务主动的发掘出来而循环剩下的模块就是用来处理这些任务的第二个模块叫做工作术这个模块要解决的是多个agent并行运行时的文件冲突问题只要你同时运行超过一个agent就会容易出现多个agent修改同一个文件的情况最后代码撞在一起整个任务就失败了这和两个工程师在没有沟通的情况下同时修改同一行代码带来的麻烦是完全一样的而Git的工作术功能就是解决这个问题的方案它可以创建一个独立的工作目录运行在单独的分支上但共享同一个代码仓库的历史记录这样一来一个agent的修改从物理层面就碰不到另一个agent的工作目录从根源上避免了文件冲突Codex直接把工作术的支持内置到了产品里多个执行县程可以同时访问同一个代码仓库互相之间不会产生干扰Cloudcode也提供了同样的隔离能力支持原生的Git工作术功能可以通过-worktree参数在独立的代码副本里开启绘画也可以给自agent设置工作术隔离的配置让每个辅助agent都有一个全新的工作目录任务结束之后还会自动清理不过这里也要提到一个很现实的限制工作术解决的只是机械层面的文件冲突但是整个流程的瓶颈依然是人本身你一天能够认真审核多少份代码产出才是你实际能够运行多少个agent的上限而不是工具能够同时跑多个线程这个问题也被叫做编排税工具能够帮你提升执行端的效率但是审核和判断的工作量最终还是要落到人身上第三个模块叫做技能Skills这个模块解决的是每次开启新的绘画都要重新解释一遍项目背景的问题用过Coding Agent的人应该都有体会每次开心的对话都要把项目的结构规范构建方式重新说一遍非常麻烦而Skills就是用来解决这个问题的两款工具的Skill都采用了相同的格式一个文件夹里放一份说明文档包含对应的指令和原数据还可以附带可选的脚本参考资料和资源文件在Codex里你可以用符号或者是指令主动调用Skill当你的任务描述和Scale的描述匹配时系统也会自动触发对应的Scale这也是为什么Scale的描述要写的简洁明确而不是追求花哨的表达准确的匹配比花哨的文案有用的多Cloud Code的Scale机制也是完全一样的逻辑Scale更深层的价值是避免意图成本的重复消耗行业里边有一个概念叫做意图债务意思是Agent每次开启新绘画的时候都是从零开始的如果你没有把要求说清楚他就会用自己的猜测来填补空白而这些猜测网友和项目的实际要求有偏差Skill就是把这些项目的规则、约定、构建步骤甚至是过往采购的坑都正式记录下来写一次Agent每次运行的时候都能够读到如果没有Skill循环每运行一次都要从零开始重新理解你的项目规则有了Skill之后这些知识就可以不断的积累产生复利效应这里还要理清一对概念Skill是内容的编写格式而插件Plugins是内容的分发方式如果你想把一个skill共享给多个代码仓库使用或者把好几个相关的skill打包到一起就可以把它们封装成一个插件这个规则在Codex和Cloudcode里都是通用的第四个模块是插件和连接器Connectors如果一个循环只能够操作本地的文件系统那它能做的事情其实非常有限而连接器的作用就是把agent接入你日常正在使用的各种工具里这些连接器大多是基于MCP协议来构建的有了它Agent就可以读取你的需求跟踪器查询数据库调用测试环境的接口甚至在及时通讯工具里发送消息因为Codex和Cloud Code都支持MCP协议所以你为其中一款工具写的连接器通常在另一款里也能够直接使用而插件的作用就是把连接器和Skill打包到一起你的同事只需要安装一次就能够用上整套配置不用再靠记忆一步一步重新搭建了这也是普通Agent和完整循环的核心区别普通的Agent只能够告诉你这里有个修复方案而完整的循环可以自己创建合并请求关联对应的需求工单等持续集成通过之后自动在沟通频道里通知相关的人员有了连接器循环才能够真正融入你现有的工作环境而不是只停留在给出建议的层面第五个模块叫做子Agent这可以说是整个循环里最有价值的结构设计它的核心逻辑就是把写代码的角色和检查代码的角色拆分开让写代码的模型自己评审自己的代码往往会出现判断宽松的问题很难发现自己的逻辑漏洞而第二个拥有不同指令甚至是不同模型的agent就能够发现第一个agent忽略掉或者是主动回避的问题在Codex里只有当你主动要求的时候系统才会生成子agent多个子agent可以同时运行最后把结果合并成一个统一的答案你可以在专门的配置目录里用配置文件来定义自己的agent每个agent可以设置名称描述指令还可以选择不同的模型和推理强度比如说负责安全审查的agent可以用能力更强的模型开启更高的推理强度而负责浏览文件的探索性agent就可以用速度更快的轻量模型只开启止读权限Cloudcode也有完全对应的机制支持在配置目录中定义此agent还可以组建agent团队让任务在不同角色的agent之间流转两款工具里最常见的分工模式都是一样的一个agent负责探索需求一个负责实现代码还有一个负责对照需求规格来做验证这个设计在循环里之所以特别重要是因为循环很多时候是在你没有盯着的情况下运行的只有拥有一个你信得过的验证环节你才能放心的让它自己运行当然了子agent也会消耗更多的token因为每个agent都要独立完成模型调用和工具使用所以这项能力不需要到处都用只在需要二次把关的关键场景开启才划算其实刚才提到的杠购指令底层用的也是这个逻辑判断循环有没有完成的是一个全新的模型而不是执行任务的那个模型相当于把生成和校验分离的逻辑用到了停止条件的判断上讲完这五个模块还要补充一个非常重要的组成部分也就是整个循环的记忆系统它可以是一个普通的Markdown文件也可以是一个项目看板任何能够存在于单次绘画之外用来记录已经完成什么接下来要做什么的载体都可以听起来好像很简单甚至有点不起眼但这是所有长时间运行的agent都必须依赖的机制大波形有一个很本质的特点每次运行之间它不会记住之前的内容所以内容不能够只存在对话的上下文理必须落到持久化的存储上比如说磁盘里的文件Agent会忘记任务进度但代码仓库和状态文件不会这就是外部记忆的价值把这些模块全部都拼到一起一个完整的循环就从单次的任务执行变成了一个小型的自主工作系统我们可以用一个很常见的场景来看一套实际运行的循环是什么样的每天早上一个自动化任务会在代码仓库上自动运行它的提示词会定用一个分类skill读取前一天的持余集成失败记录未解决的E是我以及最近的代码提交然后把发现的问题整理好写入到八个档文件或者是项目看板里对于每一个值得处理的问题循环都会创建一个隔离的工作术派出一个子agent去起草修复方案再派出第二个子agent按照项目的技能规范和已有的测试用力审查这份修复草案之后连接器会让循环自动创建合并请求更新对应的需求工单所有循环处理不了的复杂问题就会进入分类收件箱等待人工处理而整个循环的核心支柱是状态文件它会记录哪些方案已经尝试过哪些验证通过了哪些问题还在处理中这样第二天早上的自动化任务就可以从今天停下的地方继续推进而不是每次都从头开始你会发现在这套流程里你只需要设计一次循环的规则之后不需要手动提示任何一个步骤这就是斯坦伯格那个观点的现实体现而且这套循环逻辑不管是放在codex里还是Cloud Code里都能够跑通因为底层的模块都是一样的讲到这里可能有人会觉得那是不是以后程序员就没事干了只要搭好循环等着出结果就行呢其实完全不是这样的循环改变的是工作的形态它并没有把人从工作里剔除出去甚至有三个问题会随着循环的能力越来越强变得更加突出而不是更加容易解决第一个问题代码的验证责任最终还是在你身上的一个无人职守运行的循环同时也是一个无人指手犯错的循环我们把验证的子agent和生成代码的agent分开只是为了让循环给出的完成结论更有参考性但即便如此完成也只是一个声明而不是经过严格验证的结论说到底你的工作依然是交付你亲自确认过可以正常运行的代码这一点不会因为有了循环就改变第二个问题如果你放任不管你对代码库的理解会不断退化循环产出代码的速度越快你没有亲手写过的代码就会积累的越多实际存在的代码和你真正理解的内容之间的差距就会越来越大这就是所谓的理解债运行越顺畅的循环只会让这个债务增长的越快唯一的解决办法就是你依然要认真去读循环生成的每一份代码保持自己对于代码库的掌控力第三个问题也是最容易被忽略的问题最舒服的状态往往也是最危险的状态当循环可以自己运行的时候人很容易就不再主动思考和判断直接接受循环给出的所有结果这种状态可以叫做认知投降设计循环这件事情既可以是提升效率的解药也可以是让你能力退化的加速剂如果你带着判断力去设计它用它来帮你处理重复的劳动它就是解药如果你只是为了逃避思考把所有的事情都丢给循环它就会加速你的能力退化同样的动作带来的是完全相反的结果最后我们来总结一下这个趋势我认为循环工程确实是我们和AI协作方式演进的一个方向但它还处在非常早期的阶段如果完全依赖自动化循环来修复问题自己不做审核那么产品的质量大概率会下滑甚至陷入越修问题越多的恶性循环所以我们完全可以去尝试搭建自己的循环但是也不用否定直接提示agent的价值找到两者之间的平衡才是最重要的而且循环最终能够产生什么样的结果完全取决于使用它的人两个人搭建出完全一样的循环可能会得到截然相反的结果一个人用它来在自己深度理解的工作上提升效率另一个人用它来逃避对于工作内容的理解循环本身分辨不出这两者的区别但是你自己可以这也是为什么设计循环比写提示词更难而不是更简单鲍利斯切尔尼的那个观点并不是说程序员的工作变简单了而是说工作的杠杆点发生了转移以前你的杠杆来自于写好提示词现在你的杠杆来自于设计好一套能够持续运行的系统简而言之你可以去搭建你的循环但是要以一个工程师的身份去搭建而不是做一个只会按下启动键的人感谢收看本期视频我们下期再见

⚙️ Pipeline jobs

Stage	Status	Att.	Updated
download	done	1/3	2026-07-20 11:46:09
transcribe	done	1/3	2026-07-20 11:46:25
summarize	done	1/3	2026-07-20 11:47:02
embed	done	1/3	2026-07-20 11:47:04

📄 Описание YouTube

Показать

本期围绕硅谷新兴技术概念循环工程展开，结合谷歌云AI总监的专业分析，详解循环工程的核心定义、五大组成模块与外部记忆体系，对比Claude Code与Codex两款工具的对应实现方式，还原完整循环的实际运行流程，同时客观分析其技术局限性，探讨AI时代工程师的角色定位与能力演进方向。
https://x.com/addyosmani/status/2064127981161959567