Использование инструментов искусственного интеллекта в разработке программного обеспечения больше не ограничивается написанием одного запроса и ожиданием ответа. Разработчики всё чаще говорят о повторяющихся циклах выполнения, мультиагентных системах и системах, окружающих модель и направляющих её работу. GitHub Blog пытается систематизировать эти понятия в руководстве, опубликованном Cassidy Williams 2 сентября 2026 года на основе обсуждения в GitHub Podcast, в котором участвовали Marlene Mhangami и GPS.
Некоторые из этих терминов описывают новые практические подходы, другие дают современные названия уже существующим идеям, а значение третьих всё ещё формируется. Поэтому руководство представляет эти слова не как окончательные стандарты, а как способ понять дискуссию, которая идёт среди команд разработчиков программного обеспечения.
От отдельного запроса к инженерии циклов
Инженерия циклов означает проектирование повторяемых систем вокруг агентов вместо того, чтобы вручную поручать агенту выполнение отдельной задачи каждый раз. В качестве примера приводится создание запланированного процесса, который получает новые задачи проекта, передаёт их агенту для составления резюме и предложения исправлений, затем проверяет результат и направляет застрявшие случаи в другой процесс.
В этом смысле цикл похож на настроенный для искусственного интеллекта процесс cron, но требует большего, чем одно планирование. Руководство указывает на конкретные навыки, мониторинг поведения, проверку результатов, маршрутизацию задач и точки остановки, в которых можно вмешаться или провести проверку.
Циклы Ralph — это более простое и прямое применение идеи цикла: агенту дают подробное описание задачи, обычно исходя из требований или спецификации, и он продолжает работу, пока не сочтёт задачу выполненной. Такой подход может помочь разделить работу на повторяющиеся циклы планирования, выполнения и проверки, однако он может оказаться затратным и неэффективным, если каждый цикл потребляет всё больше токенов, контекста и вычислительных ресурсов.
Различие между командами, флотами и операционными оболочками
Squads и fleets описывают способы распределения работы между несколькими агентами. Команда — это группа агентов с разными ролями: один планирует, другой проверяет план, третий выполняет работу, четвёртый тестирует, а пятый проверяет результат. Флот означает агентов, которые параллельно работают над задачами одновременно. Полную команду можно запускать в составе параллельного флота или организовывать её роли последовательно.
Практическая идея заключается в специализации и параллельной работе вместо поручения всего одному агенту. Однако наличие нескольких агентов автоматически не гарантирует более высокого качества: сам материал связывает пользу с умением команды распределять роли, управлять ими и проверять результаты.
Операционная оболочка, или harness, — это всё, что окружает модель и делает её пригодной для использования внутри рабочего процесса: инструменты, разрешения, память, контекст и координация между задачами. В руководстве GitHub Copilot приводится как пример системы, связывающей модели с репозиториями кода, редакторами, запросами на слияние и терминалом. А инженерия операционной оболочки — это проектирование и улучшение этой системы, окружающей модель.
Улучшение с помощью обратной связи
Термин hill climbing используется для описания постепенного улучшения агентов и операционных оболочек на основе обратной связи. Команда может начать с измерения производительности агента с помощью оценочных тестов, а затем изменить инструменты, контекст или механизм маршрутизации, когда результаты оказываются недостаточно точными.
Например, при проверке запросов на слияние измеряется не только способность агента оставить комментарий, но и то, находит ли он значимые ошибки и предлагает ли полезные рекомендации. Практический вывод заключается в том, что внедрение агента в рабочий процесс — не конечная точка; после этого начинается непрерывный цикл измерений и корректировок.
Термины, связанные с ролями и моделями
Полевой инженер — это роль, существовавшая ещё до волны искусственного интеллекта, например инженер-программист, непосредственно работающий с клиентами, инженер по продажам или инженер по решениям. В контексте искусственного интеллекта эта роль помогает командам адаптировать инструменты и рабочие процессы, настраивать агентов и интегрировать их в существующие системы.
Закрытые модели предоставляются через API или размещённый продукт, без предоставления пользователю весов, данных обучения или метода обучения. Модели с открытыми весами позволяют загружать веса и запускать их локально или на инфраструктуре пользователя, однако это не обязательно означает доступность данных и метода обучения. В моделях с открытым исходным кодом уровень доступности ещё выше: для проверки, повторного использования и изменения предоставляются модель, код, данные и процесс обучения.
Почему это руководство важно?
Реальные изменения заключаются не только в появлении нового словаря, но и в переходе от вопроса «Что может сгенерировать модель?» к вопросу «Как построить вокруг неё повторяемую и измеримую систему?». Это важно для команд разработчиков, которые рассматривают возможность запуска агентов в своих процессах, поскольку выбор термина не заменяет определения разрешений, механизмов проверки, точек вмешательства человека и стоимости повторений.
При этом источник признаёт, что терминология нестабильна: некоторые термины могут закрепиться, а другие — исчезнуть или быть заменены более точными выражениями. Поэтому наиболее важными остаются практические вопросы: можно ли надёжно повторять рабочий процесс? Как проверяются результаты? Когда вмешивается человек? И насколько допустима зависимость от модели? Согласно материалу, эти вопросы важнее, чем попытки успеть за каждым модным словом.