Open-source среда выполнения, созданная для сложных инженерных задач. Nac координирует параллельных агентов-исполнителей и сохраняет состояние на протяжении длительных процессов.
При реализации функции агент может потратить десятки тысяч токенов на чтение кода, редактирование, отладку и дальнейшие правки, прежде чем наконец предоставит решение. К этому моменту он уже теряет из виду мелкие детали, которые пользователь мог обсуждать на ранних этапах беседы. В крайних случаях это может привести к тому, что агент выполнит задачу не так, как изначально задумывал пользователь, поскольку важный контекст сообщений пользователя размывается по мере продолжения сессии.
Большинство агентных систем не различают разные этапы работы. Исследование, вывод инструментов, неудачные попытки, развивающийся план и состояние всей задачи — всё это накапливается в одном транскрипте. И это накопление может быть даже вредным: производительность модели снижается при выполнении длительных задач — этот режим отказа теперь известен как «деградация контекста» (context rot).[1] В задачах с длинным горизонтом планирования, где работа проходит через множество последовательных этапов, контекст агента становится ограничением, и когда он заполняется, операции сжатия могут привести к потере важных деталей.
Мы считаем, что это объединяет две вещи, которые должны быть разделены:
- временный контекст, необходимый для выполнения действия; и
- постоянное состояние, необходимое для продолжения рабочего потока.
Nac — это open-source агентная обвязка, которую мы создали для себя, опираясь на это разделение. Она доступна по лицензии Apache-2.0 по адресу https://github.com/arcee-ai/nac. В этом блоге объясняется реализация, идеи, на которых она основана, и то, почему агентные обвязки становятся новым типом среды выполнения для вывода (inference runtime).
Сессии Nac могут длиться много часов, иногда даже дни, что не подходит для видео в реальном времени. Ниже представлен таймлапс части сессии Nac, в которой велась работа по созданию и записи моушн-графики пользовательского интерфейса для нашего видео о запуске.
Ваш браузер не поддерживает тег video.
А вот готовое видео:
Ваш браузер не поддерживает тег video.
Nac — это open-source агентная обвязка, которую мы создали для себя для более длительных и амбициозных задач. Мы используем её внутри компании для множества различных задач: проведения экспериментов, контроля процессов обучения, работы с инфраструктурой и быстрого прототипирования новых идей. Многие из этих задач глубоко переплетены — вы можете захотеть создать прототип идеи, оценить его, интегрировать в другую систему, масштабировать, использовать полученную обратную связь для уточнения идеи и продолжать итерации.
Nac построен на основе архитектуры «потоков и эпизодов» (thread-and-episode) из отчета Slate от Random Labs [2]: центральный оркестратор планирует и декомпозирует работу, а потоки направляются для выполнения отдельной рабочей единицы. Потоки возвращают эпизоды в виде структурированных сводок выполненной работы, полезных файлов, результатов и т. д. Важно отметить, что единственное действие оркестратора — это запуск потоков; он не может самостоятельно выполнять команды или редактировать файлы. Nac делает эту архитектуру конкретной с помощью набора специфических решений по реализации.
Давайте разберем это, начиная с первого потока, который создает оркестратор. В рамках диспетчеризации оркестратор определяет конкретную задачу и назначает её новому потоку. Оркестратору дается указание ограничивать задачу, но её объем не принудительно контролируется средой выполнения. Затем диспетчеризация запускает исполнителя (worker), который представляет собой свежий процесс и контекст модели с системным промптом исполнителя, запрошенным действием, его инструментами и любыми применимыми инструкциями по проекту или навыкам. Отдельного этапа суммаризации нет: системный промпт исполнителя вместо этого указывает, что финальный ответ модели должен быть кратким резюме для будущей работы, называемым эпизодом. Исполнитель делает вызовы модели и использует инструменты до тех пор, пока модель не вернет ответ без вызовов инструментов, который и рассматривается как эпизод.
В этот момент контекст выполнения исполнителя отбрасывается и больше никогда не используется системой в качестве контекста модели. Его изменения в среде сохраняются, но эпизод становится постоянным представлением работы. Он хранится в потоке, который представляет собой просто именованную упорядоченную коллекцию эпизодов.
В следующий раз, когда оркестратор назначает этому потоку новую задачу, Nac создает нового исполнителя со свежим контекстом. Этот исполнитель получает системный промпт, запрошенное действие и все эпизоды, уже сохраненные в потоке. Более того, оркестратор может предоставлять эпизоды из других потоков в качестве контекста — идея, которую Slate описывает как часть «плетения потоков» (thread weaving). Nac реализует это путем разрешения каждого именованного исходного потока в его последний сохраненный эпизод. Эти исходные эпизоды используются в качестве контекста для данного действия, но не становятся частью целевого потока; только эпизод, созданный новым исполнителем, добавляется после завершения работы исполнителя.
Затем Nac переходит к серии чередующихся шагов между планированием оркестратора и выполнением потока. Во время планирования оркестратор может в любое время запрашивать имена потоков и сохраненные эпизоды. Когда он решает распределить работу, он завершает свой ход выводом пакета вызовов потоков, каждый из которых имеет следующую спецификацию:
- name — целевой поток. NAC создает его, если он новый, или повторно использует его историю сохраненных эпизодов, если он уже существует.
- action — инструкция в свободной форме для исполнителя, предназначенная для описания одного ограниченного действия.
- threads (необязательно) — исходные потоки, чьи последние сохраненные эпизоды должны быть предоставлены исполнителю. Исходный поток в том же пакете создает ребро зависимости.
- skills (необязательно) — навыки, которые нужно предварительно загрузить в контекст исполнителя.
- timeout (необязательно) — ограничение по времени на выполнение работы исполнителем.
Подразумевается, что это определяет граф вызовов потоков в текущем пакете. Исходный поток, распределенный в этом пакете, должен выполнить назначенную ему работу до указанного целевого потока; ранее завершенный источник только предоставляет контекст. Nac отклоняет дублирующиеся цели и проверяет, является ли граф ациклическим перед началом выполнения. Если это не так, Nac отклоняет пакет и возвращает ошибку оркестратору.
Затем начинается выполнение потоков с использованием параллелизма, разрешенного DAG. Независимые рабочие процессы могут выполняться одновременно, но оркестратор ожидает завершения пакета перед планированием следующего шага. Это дает каждому этапу планирования четкую точку синхронизации и избавляет оркестратор от необходимости опрашивать фоновые задачи. Когда пакет завершается, эпизоды из успешно выполненных потоков и ошибки из неудачных потоков передаются оркестратору (дополнительный запрос не требуется); вызовы зависимых потоков, источники которых в том же пакете завершились с ошибкой, пропускаются. Сбои рабочих процессов не являются транзакционными: если рабочий процесс изменяет среду, а затем завершается до фиксации своего окончательного ответа, эти изменения могут остаться без нового эпизода, поэтому возвращенная ошибка означает, что среда могла уйти вперед относительно постоянной истории. Этот цикл продолжается до тех пор, пока оркестратор не решит вернуть ответ пользователю, а не создавать новый пакет потоков. Наконец, если пользователь отправляет инструкцию по управлению во время активного выполнения, nac ставит ее в очередь для следующего вызова модели оркестратором. Это не прерывает уже выполняющийся вызов модели или пакет рабочих процессов. После завершения выполнения пользователь может отправить еще один запрос, чтобы продолжить сеанс с сохранением состояния.
Специализация оркестратора и потоков в Nac позволяет оркестратору сосредоточиться на интерпретации запроса пользователя, декомпозиции работы и принятии решений о том, что должно произойти дальше. Он не может воздействовать на среду напрямую; выполнение должно быть делегировано потокам.
В качестве конкретного примера предположим, что пользователь хочет оптимизировать производительность определенной части веб-приложения. Одиночный агент сначала должен был бы изучить репозиторий, настроить среду и найти конкретный «горячий» путь, прочитав при этом множество файлов. Только после этого он мог бы начать профилирование «горячего» пути и поиск вариантов — и все это при удержании в памяти исходного намерения пользователя, высказанного много сообщений назад.
Оркестратор Nac может вместо этого распределять потоки для исследования различных частей кодовой базы параллельно, пока другой поток настраивает среду, выполняя все это за один цикл контекста оркестратора. Их эпизоды предоставляют оркестратору важную информацию, необходимую для следующего шага, не включая каждую деталь выполнения, такую как повторные попытки менеджера пакетов или тайм-ауты, которые не повлияли на результат. Затем оркестратор может назначить профилирование другому потоку и получить необходимые показатели производительности и варианты, не выполняя процесс профилирования самостоятельно.
Инструментарии для агентов развивались по двум взаимосвязанным осям: обогащение контекста, чтобы каждый вызов модели получал более высокую плотность полезной информации, и расширение пространства действий модели, чтобы она могла инициировать более эффективные операции.[3]
Использование инструментов позволило модели в первую очередь совершать действия и внедрять информацию о среде в контекст модели.[4][5][6] Дальнейшие системы выполнения программ и кода передали операции обработки данных — циклы, фильтрацию, агрегацию и точное выполнение — обычным средам выполнения, позволив модели еще больше обогатить получаемую информацию и расширить пространство своих действий.[7][8] Системы памяти сделали хранение и извлечение явными обязанностями окружающей системы, действуя как системы управления и обогащения контекста.[9][10][11] Поиск и многоагентные методы расширили это еще больше и поставили вопрос о том, на что следует тратить вычислительные ресурсы вывода для получения наилучших результатов.[12][13][14][15]
Рекурсивные языковые модели делают эту тенденцию особенно ясной: длинный промпт живет во внешней среде, которую модель может искать, разделять и преобразовывать программно, в том числе путем вызова дополнительных вызовов модели для выбранных фрагментов.[16][17] Другие системы идут другим путем, вызывая множество новых сеансов в ходе выполнения. Долгоживущие инструментарии Anthropic[18][19], цикл Ralph[20] и Engram[21] переносят прогресс через файлы и другие внешние системы, а не через один непрерывный контекст. Агенты кодирования делают нечто подобное всякий раз, когда они сохраняют прогресс путем редактирования самой кодовой базы. Cursor предоставляет яркий пример: его система планировщика-исполнителя координировала сотни агентов в долгосрочных проектах, включая создание функционального браузера.[22]
В отличие от систем, которые переносят вычисления или постоянное состояние за пределы непрерывного контекста, сжатие и субагенты в первую очередь снимают нагрузку внутри него.
Сжатие напрямую направлено на рост контекста: оно сокращает длинную траекторию, чтобы занимать меньший объем окна контекста путем перезаписи истории. Обычно оно запускается из-за нехватки токенов, а не из-за структуры задачи, и поэтому может чрезмерно сжимать или отбрасывать важные фрагменты информации.
Субагенты нацелены на раздувание контекста: они удерживают избыточные детали выполнения вне основного контекста, выполняя работу в отдельном контексте и возвращая окончательный результат. Это также эффективно увеличивает пространство действий основной модели, поскольку она может предпринимать обычные действия или более масштабное действие через субагента.
Архитектура Slate продвигает эти тенденции в определенном ключе, который мы сочли привлекательным. Маршрутизируемые эпизоды обогащают контекст каждого рабочего процесса состоянием, которое стоит сохранить, в то время как диспетчеризация потоков дает оркестратору узкое, но высокоэффективное пространство действий. Мы создали nac таким образом, чтобы прогресс мог накапливаться в ходе длительной работы, не пропуская всю историю через один растущий транскрипт.
С этой точки зрения инструментарии становятся средами выполнения вывода: системами, которые превращают вызовы моделей, инструменты и внешнее состояние в более крупные вычисления с сохранением состояния.
Это отличается от движка вывода для обслуживания моделей, который выполняет и оптимизирует генерацию токенов. Это также более специфично, чем общий движок рабочих процессов, шаги и переходы которого обычно определяются заранее.
Этот взгляд является частью более широкой конвергенции вокруг рассмотрения инструментариев как самостоятельных систем выполнения.[23][24][25]
Среда выполнения агентного вывода конструирует контекст, планирует вывод, выполняет эффекты, сохраняет состояние, обеспечивает возможности и определяет, как работа синхронизируется, завершается с ошибкой, возобновляется и останавливается. Тонкий инструментарий выполняет цикл «модель-инструмент». Среда выполнения обладает семантикой, которая в противном случае существовала бы только неявно в ее транскрипте.
В nac это отображение конкретно:
Модель остается гибким интеллектом, который решает, какая работа полезна. Среда выполнения решает, как эти решения становятся выполнимым вычислением. Разделение с самого начала, доведенное до конца: суждение остается в токенах, инварианты живут в среде выполнения.
Разные среды выполнения делают разный выбор в отношении того, как представляется управление и какое состояние сохраняется. Onyx переносит управление иначе, чем nac: поток управления оркестрацией становится постоянными типизированными программами, перенося часть самой декомпозиции с токенов в код.[26] LongHorizon-Harness отличается в подходе к состоянию: он продвигает одну глобальную, независимо проверяемую запись задачи через раунды последовательного менеджера, исполнителя и аудитора, вместо того чтобы поддерживать несколько постоянных потоков работы.[27]
Как только обвязка (harness) определяет, где выполняется логический вывод, какое состояние он получает, что сохраняется, как синхронизируется работа и когда выполнение завершается, термин «обвязка» начинает преуменьшать значение объекта. Он становится средой выполнения.
Nac создана для работы, которая слишком велика для одного сеанса, но достаточно структурирована, чтобы продвигаться через явные передачи управления. Для одного сфокусированного изменения, которое помещается в один сеанс агента кодирования, прямой подход проще и зачастую быстрее. Это добавляет накладные расходы, поскольку оркестратор не может выполнить задачу самостоятельно; ему все равно приходится делегировать ее потоку. Nac оправдывает эти накладные расходы, когда работу можно разделить на постоянные потоки задач.
Хорошо подходит сложная, но разложимая задача с четко разделенными частями и конкретными критериями приемки. В целом, хорошими индикаторами являются следующие:
- значимая высокоуровневая цель
- жесткие границы и ограничения безопасности, заявленные заранее
- конкретное определение завершенности и критерии приемки, по которым можно проверить работу
- достаточный объем независимой работы для оправдания параллелизма
- свобода для nac самостоятельно определять внутреннюю декомпозицию
Примеры включают воспроизведение статьи по машинному обучению для достижения заданных результатов или перенос большой кодовой базы между языками с сохранением ее поведения.
Nac полезна и в менее структурированных шаблонах:
- Список изолированных изменений. Nac не нужно удерживать все детали сразу или обрабатывать изменения последовательно, поэтому она может управлять их реализацией и независимой проверкой.
- Несколько длительных процессов с взаимодействием пользователя между этапами — например, внедрение функций в кодовую базу машинного обучения, проведение экспериментов и оценка результатов. Поскольку каждый процесс сохраняет свою историю эпизодов, мы можем переключаться между другими задачами и позже вернуться к первой, не восстанавливая ее историю из остальной части сеанса.
- Проверка кода. Nac может декомпозировать проверку на более мелкие, более целенаправленные проверки, синтезировать их результаты и даже использовать шаблон «лучший из N» для проверки одного и того же кода несколько раз.
- Крупные параллельные задания по изменению кода, для которых мы предоставляем nac выделенную ветку и рабочее дерево, чтобы у ее изменений было изолированное место для фиксации.
Эти шаблоны объединяет не только длительность: каждый из них выигрывает от явных границ между типами работы при сохранении непрерывности между ними.
Nac поставляется с MCP-сервером, который позволяет агенту, такому как Claude Code или Codex, отправлять, отслеживать и направлять задания nac так же, как и любой другой инструмент. Это создает шаблон, похожий на модель взаимодействия Thinking Machines: быстрый цикл, который остается с человеком, и медленный цикл, который выполняет более тяжелую работу асинхронно.[28]
Шаблон, который мы находим наиболее полезным, — сделать интерактивного агента мета-оркестратором. Он работает с вами в обычном сеансе, и мы даем ему указание следить за теми же сигналами, что и мы: работа, которая поддается декомпозиции, имеет конкретное определение завершенности и разветвляется на достаточно независимых частей, чтобы оправдать параллелизм. Когда он видит такую структуру, он сам пишет описание задания с конкретной целью и ограничениями и передает задание в nac. Задание выполняется в фоновом режиме, пока сеанс, ориентированный на человека, продолжается.
То, что может наблюдать мета-оркестратор, намеренно сформировано так же, как то, что пользователь может наблюдать через nac. Он может просматривать чат оркестратора, извлекать эпизоды потоков и недавние события потоков, а также направлять оркестратор или конкретные потоки. Он может даже выбирать разные модели для разных сеансов. Через интерфейс MCP nac мета-оркестратор по-прежнему не может видеть отброшенный контекст выполнения рабочего или базовую среду напрямую; MCP-сервер не предоставляет собственных инструментов для работы с файлами или оболочкой. Внешний интерактивный агент, конечно, может иметь свою собственную независимую среду и инструменты. Состояние сеанса должно запрашиваться; оно не добавляется автоматически в контекст мета-оркестратора.
Этот шаблон отражает наш долгосрочный взгляд на управляемых агентов: не вечно работающие чаты, а текущие вычисления, развернутые и управляемые как рабочие нагрузки в продакшене, которые люди могут проверять, регулировать и корректировать.
Nac доступна по лицензии Apache-2.0 по адресу http://github.com/arcee-ai/nac
Установите текущую edge-сборку:
- Прочитайте о нашей бета-версии Open Model API, доступной прямо сейчас: arcee.ai/blog/open-model-api-beta
[1] Келли Хонг, Антон Тройников и Джефф Хубер, , Технический отчет Chroma, июль 2025 г.
[2] Random Labs, , март 2026 г.
[3] Чэньюй Чжоу и др., , 2026 г.
[4] Эхуд Карпас и др., , 2022 г.
[5] Шуньюй Яо и др., , ICLR 2023 г.
[6] Тимо Шик и др., , NeurIPS 2023 г.
[7] Лую Гао и др., , ICML 2023 г.
[8] Синъяо Ван и др., «Исполняемые действия с кодом вызывают лучшие LLM-агенты», ICML 2024 г.
[9] Ноа Шинн и др., , NeurIPS 2023 г.
[10] Гуаньчжи Ван и др., , TMLR 2024 г.
[11] Чарльз Пэкер и др., , 2023 г.
[12] Шуньюй Яо и др., , NeurIPS 2023 г.
[13] Цинъюнь Ву и др., , 2023 г.
[14] Сехун Ким и др., «Компилятор LLM для параллельного вызова функций», ICML 2024 г.
[15] Адам Форни и др., , 2024 г.
[16] Алекс Л. Чжан, Тим Краска и Омар Хаттаб, «Рекурсивные языковые модели», 2025 г., пересмотрено в 2026 г.
[17] Сет Картен, Алекс Л. Чжан, Кевин Томас, Себастьян Мюллер и команда Prime Intellect, , август 2026 г.
[18] Джастин Янг, «Эффективные обвязки для долгоживущих агентов», Anthropic, ноябрь 2025 г.
[19] Притви Раджасекаран, «Проектирование обвязки для разработки долгоживущих приложений», март 2026 г.
[20] Джеффри Хантли, «Ральф Виггам как «инженер-программист»», июль 2025 г.
[21] Пантеа Карими и др., , 2026 г.
[22] Уилсон Лин, «Масштабирование долгоживущего автономного кодирования», Cursor, январь 2026 г.
[23] Лилиан Венг, «Инженерия обвязки для самосовершенствования», июль 2026 г.
[24] Кай Мэй и др., , COLM 2025 г.
[25] Хайлинь Чжун и Шэнсинь Чжу, , 2026 г.
[26] Random Labs, «Проектирование программируемой среды выполнения для оркестрации агентов», июль 2026 г.
[27] Цзыюй Ма и др., , август 2026 г.
[28] Thinking Machines Lab, , май 2026 г.
