Пояснения функций 01: Движок оркестрации

От первого задания до проверенного патча

Agent Argo состоит не из одной отдельной модели, которая работает над задачей как можно дольше. Это система, которая преобразует работу с программным обеспечением в понятные шаги: планирование, разбиение, выполнение, проверка, исправление и только затем представление для принятия.

Этим материалом открывается серия «Пояснения функций». Она делает центральные механизмы Agent Argo понятными — не как маркетинговые обещания, а на основе их реального применения. Начинает серию движок оркестрации: процесс, который превращает требование в контролируемый рабочий процесс.

1. Перед стартом: определить качество, затраты и автономность

Прежде чем Argo приступает к задаче, важны два решения. Они намеренно отделены друг от друга:

1. Как Argo должен соотносить затраты и качество результата?
2. Насколько самостоятельно Argo может действовать в проекте?

Это предотвращает типичный конфликт целей: тщательный прогон не должен автоматически получать больше прав на запись. И автономный прогон не должен автоматически выбирать дорогие модели.

Три уровня для затрат и качества

Маршрутизатор моделей знает три понятных режима. Они меняют то, насколько сильно цена и уровень модели влияют на выбор; требуемый навык остаётся всегда центральным.

Уровень	Режим маршрутизатора	Подходит для
Бережливый	economy	Рутинные задачи, извлечение данных, чётко ограниченные изменения. Затраты имеют большой вес.
Сбалансированный	balanced	Стандарт для большинства прогонов: соответствие навыку, затраты и уровень качества остаются в равновесии.
Требовательный	expert	Архитектура, исследования, сложный анализ и требовательные ревью. Уровень модели весит заметно сильнее, затраты — меньше.

Операционные профили Быстро и дёшево, Сбалансированный и Тщательно объединяют этот режим маршрутизатора с дополнительными решениями: например, наблюдается ли общее мышление только или активно выполняется, является ли верификация обязательной и может ли Argo при неудачной попытке эскалировать сильнее.

Три уровня автономности

Автономность регулирует не то, что Argo считает правильным, а когда для этого нужен человек.

Уровень	Поведение
Безопасный	Argo анализирует и планирует. Изменения остаются на проверку; перед записывающими или рискованными действиями спрашивается.
Сбалансированный	Обычные изменения могут возникать в изолированном рабочем состоянии. При удалении, командах, загрузках, сетевом доступе или защищённых путях Argo продолжает спрашивать.
Полностью автономный	Прогон работает без обычных уточнений. Жёсткие границы безопасности, политики и бюджета продолжают действовать.

В коде эти правила реализованы точнее как readonly, confirm_write, auto_write и bypass. Три уровня делают их удобными в использовании; однако политика проекта всегда остаётся последней инстанцией. Она может, например, исключить облачных провайдеров, разрешить только локальные модели, заблокировать сетевой доступ, ограничить команды, защитить секреты или установить лимит затрат.

2. Уровень CEO превращает задание в план

Пользователь сначала описывает цель обычным языком. Уровень CEO Argo получает для этого ограниченный обзор проекта, доступный каталог моделей и релевантную информацию о проекте. При открытых вопросах он может сначала уточнить их или создать план.

План содержит не только список дел. Каждая задача получает роль, описание, зависимости и требуемые способности — например coding, planning, qa_review или context_comprehension. Для трудных задач может быть отмечена и более высокая сложность. При этом уровень CEO не называет жёстко модель: он описывает работу, а маршрутизатор позже решает для каждой задачи подходящую модель.

Таким образом план остаётся читаемой человеком договорённостью о намерении, в то время как выполнение может оставаться адаптивным.

3. Из плана получается граф задач

После утверждения плана Argo превращает задачи в граф задач. Узел может запуститься только тогда, когда его зависимости успешно завершены. Независимые задачи могут выполняться параллельно.

Планировщик сортирует готовые узлы по понятной эвристике полезности: ожидаемое качество минус штраф за затраты, время и риск. Если узел находится на критическом пути, он при равенстве получает приоритет, поскольку определяет общую длительность прогона.

При высокой неопределённости или высоком риске Argo может перед обработкой выбрать общий режим мышления: несколько перспектив разрабатывают подходы, критикуют друг друга и предоставляют обоснованный рабочий подход для исполнителя. Записывается ли это только в протокол или действительно выполняется, решает выбранный перед прогоном операционный профиль.

4. Перед каждой задачей: подходящий контекст, подходящие навыки, подходящая модель

Перед тем как работник начинает, Argo строит контекст, адаптированный под роль и задачу. Сюда относятся релевантные файлы, результаты зависимостей и — если активировано — компактный пакет памяти, а также подходящие инструкции навыков. При этом Argo не переносит слепо всё знание проекта в подсказку. Память и навыки выбираются по релевантности, происхождению, актуальности, затратам и статусу безопасности.

Затем маршрутизатор моделей выбирает модель. Сначала исключаются кандидаты, которые недоступны, не имеют достаточного окна контекста, исчерпали квоту или нарушают активную политику. Из оставшихся моделей Argo оценивает четыре фактора:

• Соответствие навыку: насколько хорошо модель оценена для требуемых навыков? При нескольких навыках рассматривается среднее значение.
• Затраты: насколько дорог запрос — или при активной маршрутизации по затратам вероятный успешный результат?
• Уровень модели: трудные, критичные для безопасности, архитектурные задачи и ревью могут предпочитать флагманский уровень.
• Опытные значения: после достаточного количества реальных результатов учитываются последний показатель успеха и повторов комбинации модель/навык.

Для расчёта затрат Argo может использовать Expected Cost of Success: прямая цена, ожидаемые повторы, усилия по верификации, возможная доработка и небольшой штраф за задержку. Поэтому дешёвый отдельный вызов не является автоматически самым дешёвым решением, если он чаще терпит неудачу или вызывает доработку.

Явная рекомендация модели принимается только если она доступна, разрешена политикой и достаточно велика для контекста. Планирование, делегирование и понимание контекста уровня CEO используют в свою очередь сильную модель, выбранную специально для этих трёх способностей.

5. Работник выполняет задачу маленькими, проверяемыми шагами

Работник не работает с одним единственным ответом. Он проходит ограниченный цикл ReAct:

1. Модель предлагает структурированные действия — например, читать файлы, искать, выполнять тесты или записывать изменения.
2. Исполнитель проверяет разрешение, путь, риск команды и активную политику.
3. Argo выполняет только разрешённые действия.
4. Результаты, diff и сообщения об ошибках возвращаются как наблюдение модели.
5. На этой основе работник корректирует свой следующий шаг или завершает задачу.

Так агент может, например, сначала прочитать затронутый код, затем внести изменение, выполнить тест и учесть результат теста в следующем решении. Полный ход остаётся видимым в журнале прогона.

Сам вывод тоже проверяется. Если модель выдаёт недопустимый JSON действия, Argo может запросить ограниченный цикл исправления. В строгом режиме постоянно ошибочный вывод контролируемо отклоняется, вместо того чтобы интерпретировать неясный текст как действие.

6. При ошибках: целенаправленно исправлять, а не слепо повторять

Не каждая неудавшаяся задача означает, что весь прогон провалился. Движок оркестрации различает причины ошибок и реагирует контролируемо:

• Временную ошибку можно в пределах фиксированных границ повторить.
• Твёрдое заключение верификации даёт своё конкретное замечание как задание для следующей попытки.
• При активированном каскадировании следующая попытка перенимает выводы предыдущей, вместо того чтобы начинать с нуля.
• После неудачной попытки Argo может отдать предпочтение более сильной модели.
• Если бюджет исчерпан, не запускается дорогая слепая попытка: узел завершается задокументированным промежуточным результатом или видимо эскалируется.

Стратегия узла в итоге решает, может ли задача быть пропущена, контролируемо провалиться или требует решения пользователя. Зависимые задачи получают исключительно подтверждённые промежуточные результаты. Так из локальной ошибки не получается тихая ошибка, которая продолжается через остальной план.

7. После реализации: ревью, верификация и возможный дальнейший цикл

Когда запланированные задачи обработаны, Argo проверяет интегрированное состояние с нескольких точек зрения:

• QA-агент может читать файлы и выполнять тестовые команды.
• Архитектурный агент проверяет структуру только чтением и сознательно остаётся без прав записи.
• Детерминированные верификаторы могут выполнять тесты, проверку типов или линтинг как объективные оракулы.
• На основе модели и детерминированные заключения объединяются в общее суждение.

Если QA, архитектура или обязательный верификатор находят проблемы, Argo относит заключения к затронутым задачам. Только эти задачи повторно обрабатываются с конкретной обратной связью. Затем снова следуют ревью и верификация. Без режима консенсуса эта петля ограничена; в явно выбранном режиме консенсуса она продолжается, пока пользователь не остановит или проверяющие не согласятся.

Верификатор в режиме наблюдения документирует заключения, но не блокирует. В обязательном режиме твёрдое заключение может помешать тому, чтобы результат считался успешным. Так строгость можно выбрать под каждый операционный профиль, не отказываясь от прослеживаемости.

8. Только когда состояние проверено: документация и резюме CEO

После завершённого рабочего и проверочного цикла агент документации может зафиксировать изменения. Затем уровень CEO создаёт резюме для пользователя: что было выполнено? Что осталось открытым? Какие проверки прошли? Какие файлы или решения затронуты?

Результат — больше чем текст чата. Прогон ведёт общий идентификатор для плана, выбора модели, затрат, действий, верификационных суждений, прерываний пользователем и последующих решений о патче. Благодаря этому можно проследить, как Argo пришёл к результату.

9. В конце человек решает по настоящему рабочему пространству

По умолчанию Argo работает в изолированном worktree. Изменения лежат там как патч, а не тихо в реальном проекте. В зависимости от уровня автономности происходит одно из трёх:

• Патч остаётся готовым к принятию, частичному переносу, редактированию или отклонению.
• Успешный патч принимается автоматически.
• При конфликтах с изменёнными за это время файлами Argo видимо останавливается; он не перезаписывает чужие изменения.

Неудавшийся прогон не применяется автоматически. Даже очень автономная конфигурация не отменяет политику: защита секретов, правила команд, границы провайдеров, лимиты бюджета и необходимые ворота человека остаются действующими.

Что делает движок оркестрации

Движок оркестрации решает не только то, какая модель ответит следующей. Он связывает намерение пользователя, настройки, планирование, параллелизацию, выбор модели, использование инструментов, исправление ошибок, обеспечение качества и безопасное принятие в единый процесс.

Мерило — не «как можно больше агентов». Дополнительная работа возникает только там, где она обоснована: более сильная модель для трудного архитектурного решения, второй мыслительный подход при неопределённости, целенаправленный повтор после замечания верификатора или человеческое разрешение перед рискованным эффектом.

Курс тем самым задан.