Інженер Google: Loop Engineering із п’ятьма кубиками дозволяє ШІ автоматично створювати prompt-агента

Loop Engineering定義

Інженер-програміст Google Addy Osmani 7 червня опублікував допис, у якому визначив «Loop Engineering» як підхід до проєктування AI-агентів, що замінює ручне створення Prompt інженерами автоматизованими системами, і складається з п’яти блоків: Automations, Worktrees, Skills, Plugins/Connectors та Sub-agents.

П’ять блоків: визначення та функції

Відповідно до фреймворку Addy Osmani:

Automations(автоматизація): завдання, що спрацьовують за розкладом, і відповідають за автоматичне виконання «виявлення» (Discovery) та «тріажу» (Triage). Osmani пояснює, що Automations — це ключовий механізм, який перетворює цикл на справді циклічний процес, а не «одноразове виконання». Codex app використовує Automations на рівні розділів і пропонує команду /goal (запуск до виконання умови); Claude Code реалізує ту саму функціональність через заплановані задачі, cron, /loop, /goal і GitHub Actions.

Worktrees(робочі дерева): використовує механізм git worktree для створення окремих робочих каталогів для паралельного виконання агентів, щоб запобігти конфліктам, коли кілька агентів одночасно змінюють той самий файл. Codex app має вбудовані worktree для кожного thread; Claude Code забезпечує таку саму ізоляцію через git worktree та прапорець --worktree.

Skills(навички): у форматі SKILL.md записують у зовнішні файли знання проєкту, сталі практики й кроки збирання, тож агент щоразу під час виконання не змушений заново відтворювати контекст проєкту. Обидва інструменти використовують однаковий формат SKILL.md, а Osmani підкреслює, що точний опис кращий за розмиті формулювання.

Plugins / Connectors(плагіни та конектори): побудовані на MCP (Model Context Protocol), щоб агент міг отримувати доступ до зовнішніх систем, зокрема Issue Tracker, баз даних, API-ендпойнтів і інструментів зв’язку. Codex app і Claude Code обидва підтримують MCP; Osmani підтверджує, що один і той самий connector зазвичай можна безпосередньо використовувати в обох інструментах.

Sub-agents(сабагенти): розділяє «агентів виконання» та «агентів верифікації» на окремі ролі, які працюють за різними інструкціями навіть або різними моделями, щоб запобігти надто поблажливій самооцінці одного й того самого агента. У Codex app визначення подано у .codex/agents/ у форматі TOML; у Claude Code визначаються Task subagents і agent teams у .claude/agents/.

Зовнішня пам’ять (State): визначення та роль шостого компонента

Osmani визначає зовнішню пам’ять як «будь-що, що існує поза однією розмовою та використовується для фіксації того, що було зроблено, і що є наступним кроком», наприклад Markdown-файли або дошку Linear. Причина необхідності така: великі мовні моделі не зберігають пам’ять між запусками, тому прогрес потрібно зберігати зовні, а не в контекстному вікні самої моделі.

Обидва інструменти підтримують цей механізм: Codex app через зв’язки Markdown або Connector під’єднує Linear; Claude Code через AGENTS.md, файл прогресу або MCP-зв’язок також під’єднує Linear.

Поширені запитання

У чому полягає ключова різниця між Loop Engineering та традиційним Prompt Engineering?

Згідно з фреймворком Addy Osmani, традиційне Prompt Engineering передбачає ручне написання Prompt інженером і поетапну взаємодію агента з ним; Loop Engineering натомість проєктує цілісну систему, де Automations автоматично запускають процес, Worktrees ізолюють паралельне виконання, Skills надають знання, Connectors під’єднують інструменти, а Sub-agents розділяють виконання та верифікацію, тож роль інженера зміщується з «прямого керування агентом» у «проєктування системи для запуску агентів».

Які блоки наразі підтримують Codex app і Claude Code?

Відповідно до порівняльного аналізу Osmani, на момент публікації статті обидва інструменти вже повністю підтримують п’ять блоків і механізм зовнішньої пам’яті; основні відмінності — у назвах і конкретних шляхах: у Automations функціональність має відповідники, Worktrees побудовані на git worktree, Skills використовують формат SKILL.md, Plugins/Connectors базуються на MCP, а Sub-agents використовують конфігурації в .agents/ каталозі.

Як реалізується «розділення виконання і верифікації» в Sub-agents?

Згідно з поясненням Osmani, в дизайні Sub-agents роль «агента, який пише код» відділяється від ролі «агента, який перевіряє код» як дві незалежні ролі, які можуть використовувати різні інструкції або навіть різні моделі. У Claude Code команда /goal працює на тому самому принципі: нова модель вирішує, чи завдання виконано, а не модель, що виконувала задачу, самостійно оцінює результат; Osmani називає це застосуванням «тих, хто робить, vs тих, хто перевіряє» для самих умов зупинки.

Застереження: інформація на цій сторінці може походити зі сторонніх джерел і надається виключно для ознайомлення. Вона не відображає позицію чи думку Gate і не є фінансовою, інвестиційною чи юридичною консультацією. Торгівля віртуальними активами пов’язана з високим ризиком. Будь ласка, не покладайтеся лише на інформацію з цієї сторінки під час прийняття рішень. Детальніше дивіться у Застереженні.
Прокоментувати
0/400
Немає коментарів