Как работают Missions

Архитектура Missions: почему контекст агента определяет каждое решение в дизайне, как разделение ответственности и test-driven development на двух уровнях обеспечивают надёжную автономную работу на протяжении нескольких дней, и как эта система реально функционирует.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Как работают Missions

How Missions Work Автор: Theo Luan Оригинальный текст

Agent sessions хорошо справляются с узко очерченными задачами, но большинство реальных проектов слишком широки и сложны, чтобы уместиться в одно контекстное окно. Одиночный агент рано или поздно сталкивается с проблемой: чем больше он видит, тем менее сфокусированным и надёжным становится.

Missions — наша система для решения этой проблемы. Она разбивает крупную работу на сфокусированные единицы, которые обрабатываются свежими агентами с узко заданными целями, общим состоянием и явной валидацией.

Обоснование

Большая часть архитектуры вытекает из одного ключевого наблюдения: агенты крайне реактивны к своему контексту.

1. Траектория агента append-only, поэтому рассуждения модели в любой момент — это функция от каждой прошлой мысли, наблюдения и действия.
2. Модели стремятся к когерентности: они интегрируют всё, что есть в контексте, в единую картину мира и рассуждают, отталкиваясь от неё.
3. Поэтому они показывают лучшие результаты, когда каждый предыдущий шаг траектории подталкивает их к следующему оптимальному шагу.
4. Когда контекстное окно накапливает информацию, которая нерелевантна текущей цели — или активно работает против неё — производительность падает.

Из этого вытекают два режима отказа:

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

Следствия

Недостаточно просто разбить работу на части. Цель каждого агента должна быть сфокусированной, а его траектория — направленно непротиворечивой. В каждом запуске мы должны избегать накопления контекста, который:

• не полезен текущей задаче агента
• не согласован со стимулами агента или с нашим идеальным исходом этого запуска

Принципы дизайна

Разделение ответственности и стимулов

У каждой роли есть единственная цель, и система устроена так, чтобы ничего в траектории агента не уводило его от этой цели.

• Оркестратор планирует и декомпозирует подход к цели пользователя и направляет исполнение к завершению, проходя все гейты валидации. Он избегает накопления чрезмерно гранулярного контекста, делегируя всё исследование и реализацию субагентам и воркерам. Он не управляет валидацией напрямую — система сама подставляет валидаторов на контрольных точках, чтобы выявлять пробелы.
• Воркеры (Workers) реализуют чётко специфицированные фичи с ясными критериями успеха. Они итерируют, пока не сочтут работу корректной, и затем передают её дальше. Но окончательное решение о корректности — не за ними. Его принимает независимый валидатор.
• Валидаторы (Validators) оценивают готовую работу на корректность и полноту, выявляя баги и пробелы. Они не устраняют их сами — они поднимают проблемы оркестратору, который создаёт fix-фичи, реализуемые будущими воркерами.

Test-driven development на двух уровнях

Один и тот же принцип работает на двух масштабах.

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

Этот порядок важен. Создавая validation contract, оркестратор опирается на своё понимание требований. Если бы он сначала создал фичи, контракт был бы испорчен уже запланированной реализацией.

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

Вынесенное состояние (Externalized state)

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

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

Специализация моделей

У разных моделей — разные сильные стороны: reasoning, дисциплина, креативность, тщательность, скорость, стоимость. Ни одна модель не является лучшей во всём.

Как только роли чётко разделены, выбор модели становится локальным для каждой роли: широкое планирование и суждение — для оркестратора, надёжное исполнение и экономичность — для воркеров, тщательность и скептицизм — для валидаторов.

Система

Опираясь на эти принципы, вот как миссия на самом деле выполняется.

Пользователь описывает, что он хочет построить. Оркестратор исследует и задаёт уточняющие вопросы, пока требования не становятся однозначными.

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

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

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

### VAL-AUTH-001: Successful login
A user with valid credentials submits the login form
and is redirected to the dashboard.
Tool: agent-browser
Evidence: screenshot, network(POST /api/auth/login -> 200)

### VAL-CROSS-001: Auth gates pricing
A guest user sees "Sign in for pricing" on the catalog.
After logging in, real prices are shown.
Tool: agent-browser
Evidence: screenshot(guest-view), screenshot(authed-view)
...

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

Как только все фичи внутри milestone завершены, runner запускает валидацию свежими агентами.

• Scrutiny-валидаторы разбирают реализацию и траекторию каждого воркера на предмет качества и корректности и кодируют релевантные обновления знаний в общее состояние.
• User-testing-валидаторы работают с системой как с чёрным ящиком — так, как это делал бы реальный пользователь, — и проверяют поведение относительно validation contract.

После валидации оркестратор разбирает то, на что указали воркеры и валидаторы. Он создаёт fix-фичи, нацеленные на устранимые пробелы, которые выполняются до повторной валидации milestone. Этот цикл повторяется, пока milestone не пройдёт валидацию.

Если реализация или валидация заблокированы, оркестратор останавливает миссию и возвращает управление пользователю.

Разбор реальной миссии

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

Эта миссия продвигалась через устойчивый ритм «реализация — валидация» на шести milestones, причём валидация заняла 37,2% общего времени работы.

Она сгенерировала 38,8k строк кода (52,5% из них — тесты) при 89,25% покрытии операторов.

Каждый milestone сходился за 2–4 раунда валидации. Это давало устойчивый корректирующий цикл: валидаторы выявили 81 проблему, а оркестратор сгенерировал 21 целевую fix-фичу (34,4% от работы по реализации), чтобы их закрыть.

Траектории также оставались ограниченными на протяжении всего исполнения: медианная длина запуска — 51 ход ассистента для реализации и 30 для валидации.

Взгляд в будущее

Missions — наша первая версия системы, замыкающей цикл разработки софта.

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

Missions доступен уже сегодня. Запустите /missions в любой Droid-сессии, чтобы начать.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot