Что такое обвязка агента: исследования, проекты с открытым исходным кодом и отраслевые практики

Два агента могут использовать одну и ту же модель, но получать кардинально разные результаты на одном бенчмарке. OpenAI измерила это напрямую: на SWE-bench Lite GPT-4 набрала 2,7% с одной обвязкой и 28,3% с другой — десятикратная разница, полностью обусловленная обвязкой. По мере того как отрасль смещалась от вопроса «какая модель умнее» к вопросу «какой агент действительно выполняет задачу», обвязка агента стала уровнем, на котором достигается или теряется надежность. Читайте далее, чтобы узнать, что такое обвязка агента, что говорят о ее проектировании новейшие статьи и бенчмарки, какие обвязки с открытым исходным кодом заслуживают внимания и как ведущие лаборатории ИИ разрабатывают собственные решения, включая Kimi K3.1 Pro — модель с открытыми весами, которую Moonshot AI использует в паре со своими обвязками.

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

Термин пришел из мира оценки: «тестовая обвязка» — это система, которая запускает систему в контролируемых условиях. В агентном ИИ эта идея распространилась и на производственное использование: обвязка служит как для измерения агента (например, в SWE-bench или Terminal-Bench), так и для его запуска (например, в SWE-agent, OpenHands или Claude Code).

Исследование Anthropic по SWE-bench формулирует это прямо: бенчмарк «оценивает не только ИИ-модель в изоляции, а целую систему “агент”», где агент — это «сочетание ИИ-модели и программного каркаса вокруг нее». Улучшенная Claude 3.5 Sonnet достигла 49% на SWE-bench Verified не со сложным фреймворком, а с минимальной обвязкой из одного промпта и двух универсальных инструментов: Bash и Edit.

Годами рост показателей в рейтингах связывали с масштабом моделей. Недавние исследования опровергли это предположение с двух сторон.

Во-первых, результат «меньше значит больше»: в июле 2025 года команда SWE-bench выпустила mini-SWE-agent — обвязку примерно из 100 строк Python без инструментов, кроме bash, с полностью линейной историей сообщений и выполнением каждого действия как отдельного вызова subprocess.run. Она достигла результатов бенчмарка, сопоставимых с гораздо более сложными фреймворками (подробнее об этом — в разделе исследований ниже). Вывод оказался провокационным: если модель достаточно сильна, крайне простая и предсказуемая обвязка может превзойти тяжеловесную. Ее уже используют в качестве базового уровня Meta, NVIDIA, IBM, Princeton и Stanford.

Во-вторых, результат «больше значит меньше»: плохая обвязка — с шумными выводами инструментов, неограниченными циклами и плохим восстановлением после ошибок — может заставить передовую модель выглядеть посредственно. OpenAI обнаружила, что очистка дефектных задач SWE-bench (подробно рассмотренная в разделе об OpenAI ниже) более чем вдвое повысила измеряемую производительность модели.

Именно поэтому разработка обвязок стала самостоятельной дисциплиной. Обвязка определяет:

• Что видит модель: структуру промпта, схемы инструментов, объем состояния среды и истории, включаемый в контекстное окно.

• Что может делать модель: какие инструменты доступны (оболочка, редактор файлов, браузер, поиск) и как действия разбираются и проверяются перед выполнением.

• Как обрабатываются сбои: повторные попытки, тайм-ауты, сжатие контекста при заполнении окна и корректное завершение.

• Как измеряется работа: журналирование траекторий, оценка и учет стоимости — без них невозможны ни оценка, ни цикл улучшений.

Будь то среда исследовательского бенчмарка или производственный помощник для программирования, почти каждая обвязка агента реализует один и тот же основной цикл:

1. Получение задачи: прочитать задачу, инструкцию или цель и запустить изолированную среду (обычно контейнер Docker или снимок VM).

2. Формирование промпта: объединить системный промпт, определения инструментов, описание задачи и накапливаемую историю действий и наблюдений.

3. Разбор действий: преобразовать вывод модели в конкретный вызов инструмента — команду bash, изменение файла, API-запрос — и отклонять некорректно сформированные действия.

4. Выполнение и наблюдение: выполнить действие в среде, получить stdout/stderr или состояние интерфейса и сократить результат так, чтобы он уложился в контекстный бюджет.

5. Управление ходом работы: задавать ограничения на число шагов, затраты и условия остановки; определять, когда обратиться к человеку или завершить эпизод.

6. Запись и оценка: сохранять полную траекторию и оценивать итоговое состояние — например, запуская набор тестов репозитория в SWE-bench.

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

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

Прежде чем перейти к статьям, кратко разберёмся в основах. Бенчмарк — это фиксированный набор задач с правилом оценки, созданный для сравнения разных систем в одинаковых условиях. В оценке агентов у бенчмарка есть три изменяемые части: набор задач (реальные задачи GitHub, команды терминала, веб-задачи), среда выполнения (контейнер Docker, браузер, терминал) и проверяющий модуль (набор тестов, проверка состояния, экспертная оценка). Обвязка находится между моделью и всеми тремя частями — именно она определяет, отразятся ли способности модели в оценке.

То, как именно измеряются результаты, важнее итоговой цифры в заголовке. В SWE-bench агент создаёт патч кода, после чего бенчмарк запускает два набора тестов: FAIL_TO_PASS (тесты, которые не проходили до исправления и теперь должны проходить) и PASS_TO_PASS (тесты, которые работали до исправления и не должны сломаться). Задача считается решённой, только если проходят оба набора. Поэтому такие возможности обвязки, как запуск тестов и создание diff, — не факультативные дополнения: именно здесь набираются или теряются баллы.

Три правила чтения результатов любого бенчмарка:

1. Спрашивайте, что скрывает результат. Модель, обученная на открытых данных GitHub, могла уже видеть задачи, на которых её тестируют, — загрязнение данных может завышать результаты без реального роста способностей. Противоядие — воспроизводимые среды и отложенные наборы задач.

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

3. Проверяйте обвязку, а не только модель. Как показывает остальная часть этого раздела, одна и та же модель может получить 2,7% или 28,3% в зависимости от обвязки. Результат без указанной обвязки — это анекдот, а не измерение.

Оригинальная статья о SWE-bench ("Могут ли языковые модели решать реальные задачи GitHub?") представила ставшую канонической оценку: модели дают реальную задачу GitHub и полный репозиторий, а затем проверяют, заставляет ли её патч проходить неудачные тесты. Её наиболее цитируемый результат часто неверно понимают: лучшая на тот момент модель, Claude 2, решила лишь 1,96% задач. Сами авторы отмечали, что бенчмарк проверяет «сложное рассуждение, которое выходит далеко за рамки традиционной генерации кода», однако последующие работы показали: значительная часть разрыва была связана не со способностью рассуждать, а с отсутствием обвязки, способной ориентироваться в репозитории, запускать тесты и выполнять итерации. Иными словами, SWE-bench не просто измерял модели: он показал, что недостающим элементом была обвязка вокруг них.

Статья о SWE-agent ("Интерфейсы агент—компьютер позволяют автоматизировать разработку ПО") — основополагающая работа в области проектирования обвязок. Её главный тезис: дизайн интерфейса — ключевой фактор. Авторы ввели термин Agent-Computer Interface (ACI) и показали, что специализированный интерфейс — редактор файлов с проверкой линтером, краткая обратная связь от оболочки, защита от некорректных команд — повысил pass@1 в SWE-bench с нескольких процентов до 12,5%, что на тот момент было лучшим результатом. Долговечный вклад статьи — аргумент о том, что «агенты языковых моделей представляют новую категорию конечных пользователей», которым нужно ПО, созданное специально для них, так же как людям нужны IDE. На этот результат ссылается каждая последующая статья об обвязках.

Две статьи 2024 года распространили исследования обвязок с репозиториев кода на работу с компьютером целиком. OSWorld создал первую масштабируемую среду с реальными компьютерами на Ubuntu, Windows и macOS, включающую 369 задач для веб- и настольных приложений. Его ключевой результат — люди выполняют 72,36% задач, а лучшая модель — 12,24% — выявил привязку к GUI (преобразование вывода модели в правильные клики и нажатия клавиш) как основной режим отказа: это проблема обвязки, а не знаний. WebArena рассмотрел другой подход: самостоятельно развёрнутую, полностью воспроизводимую веб-среду (электронная коммерция, форумы, GitLab, CMS), где GPT-4 достиг лишь 14,41% успешных выполнений от начала до конца против 78,24% у людей. Обе статьи установили, что оценка обвязки должна быть основана на выполнении — то есть проверять итоговое состояние среды, а не сопоставлять с шаблонами выводы модели.

τ-bench от Sierra ("Бенчмарк взаимодействия инструмент—агент—пользователь в реальных предметных областях") сделал более тонкое наблюдение: в продакшене обвязка не просто окружает модель и среду — она также опосредует пользователя. Бенчмарк моделирует динамические диалоги между пользователем на базе языковой модели и агентом, располагающим предметными API и политиками, а затем оценивает итоговое состояние базы данных. Его ключевая метрика, pass^k (успех в k независимых испытаниях), показала, насколько непоследовательны агенты: GPT-4o решил менее 50% задач даже один раз, а pass^8 в розничной торговле опустился ниже 25%. Вывод для разработчиков обвязок: надёжность — это свойство распределения, а не одного запуска; обвязка, которая сработала один раз, ещё не является работающей обвязкой.

Работа METR "Измерение способности ИИ выполнять длительные задачи по разработке ПО" ввела понятие горизонта времени выполнения задач с вероятностью 50%: это длительность задачи, измеренная временем её выполнения человеком, которую модель завершает с надёжностью 50%. За период с 2019 по 2025 год передовые модели перешли от минут к примерно часу, удваивая этот показатель примерно каждые семь месяцев. Для инженерии обвязок это наиболее значимый вывод десятилетия: обвязка, ограничивающая модель 2024 года, для модели 2026 года становится лишним грузом. По формулировке Anthropic, каждый компонент обвязки содержит предположение о том, чего модель не умеет, — и эти предположения устаревают по мере улучшения моделей.

Исходный бенчмарк вырос в экосистему, воплощающую эти уроки на практике:

• SWE-bench Verified (совместно с OpenAI, 2024): подмножество из 500 задач, отобранных людьми; из него исключили недостаточно определённые задачи или задачи с несправедливой оценкой. Из исходного набора отфильтровали 68,3%, что более чем вдвое повысило измеряемые результаты и сделало его стандартной таблицей лидеров.

• SWE-smith (2025): конвейер для создания синтетических обучающих задач, позволяющий обучать модели работе с агентными обвязками, а не только оценивать их на них.

• mini-SWE-agent (2025): обвязка примерно на 100 строк, которая теперь превышает 74% на SWE-bench Verified. Она показывает, что при достаточно сильной модели достаточно минимального цикла только с bash и линейной историей, и становится стандартным базовым решением сообщества.

• Terminal-Bench (Stanford × Laude, 2025): оценка задач в терминале, построенная на фреймворке Harbor и выводящая обвязки за пределы редактирования кода — в системное администрирование.

• CodeClash (2025) и ProgramBench (2026): создание ПО, ориентированное на цели и с нуля, расширяющее применение обвязок от исправления отдельных задач до разработки с открытым кругом задач.

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

Именно с open-source обвязок начинает большинство команд. Представленные ниже проекты сочетают крупные сообщества на GitHub — у лидеров десятки тысяч звёзд — и активную поддержку:

При выборе между ними сообщество придерживается такого правила: используйте минимальную обвязку, которая позволяет выразить вашу задачу (философия mini-SWE-agent), и усложняйте её, только когда это требуется из-за измеримого сбоя. DeepSeek Harness находится на противоположном конце спектра — это полностью управляемая плагинами платформа для команд, которым нужна заменяемость каждого слоя, — однако оба подхода объединяет одна дисциплина: надёжный журнал сессии, работающий только на добавление, как единственный источник истины о том, что видела модель.

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

Anthropic опубликовала наиболее полное публичное описание разработки обвязок, а её архитектуру, подробно изложенную в Building Effective Agents (2024), материале об обвязке SWE-bench (2024) и Managed Agents (2026), можно рассматривать как три концентрических слоя.

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

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

Уровень оркестрации — то, что Anthropic называет «мета-обвязкой», — разделяет «мозг» (модель и её цикл) и «руки» (песочницы и инструменты) через явные интерфейсы. Поскольку мозг больше не находится внутри контейнера выполнения, песочницы можно выделять по требованию, а учётные данные — хранить в хранилище, к которому песочница никогда не обращается. По их данным, результат носит структурный, а не косметический характер: p50 времени до первого токена сократилось примерно на 60%, а p95 — более чем на 90%, поскольку сессии больше не ждут контейнеры, которые могут им вовсе не понадобиться.

Эту эволюцию прослеживают три документа: Building Effective Agents (2024), материал об обвязке SWE-bench (2024) и Managed Agents (2026).

OpenAI сотрудничала с командой SWE-bench при создании проверенного людьми раздела Verified именно потому, что обвязкам нужны качественные задачи: их кампания по разметке (93 разработчика, 1 699 образцов) показала, что 68,3% задач исходного бенчмарка были проблемными, а их удаление более чем удвоило измеренную производительность. В той же публикации отмечается, что один лишь выбор обвязки изменил результат GPT-4 на SWE-bench Lite с 2,7% до 28,3% — этот разброс приводится в обоснование того, что при оценках необходимо учитывать прогресс в обвязках, созданных сообществом.

В сфере открытого ПО Codex CLI поставляется как полноценная эталонная обвязка. Её архитектура разделена на слои подобно другим системам этого раздела: основной цикл агента занимается планированием и вызовами инструментов; слой песочницы изолирует выполнение с настраиваемой политикой для каждой задачи; слой сессии сохраняет диалоги, чтобы их можно было возобновлять, разветвлять или сжимать; а слой инструментов предоставляет доступ как к локальной оболочке, так и к внешним инструментам на основе MCP. Вместо жёсткой привязки к одному интерфейсу тот же движок представлен в трёх вариантах: терминальный UI для интерактивной работы, JSON-RPC сервер приложений для полнофункциональных клиентов, таких как VS Code, и удалённый сервис выполнения кода для облачных песочниц. Поэтому обвязка может работать локально или управляться программно. В её проектировании учтены те же компромиссы, которые рекомендует исследовательская литература: минимальный цикл, надёжная песочница, явное управление контекстом и чёткая граница между моделью и внешним миром.

С Agent Development Kit (ADK) и протоколом Agent2Agent (A2A) — запущенным в апреле 2025 года при участии более 50 технологических партнеров, включая Atlassian, Salesforce, SAP и ServiceNow, — Google превращает слой обвязки в продукт. A2A стандартизирует то, как агенты заявляют о своих возможностях (через JSON «карточки агентов»), управляют долгими задачами, обмениваются артефактами и согласуют форматы UI, благодаря чему обвязки становятся совместимой инфраструктурой, а не самописным связующим кодом. Он специально разработан как дополнение к Model Context Protocol (MCP) от Anthropic, который стандартизирует инструменты в обвязке.

AutoGen и Magentic-One от Microsoft поставляются с обвязками, в которых агент-оркестратор ведет журнал фактов и хода работы — это опубликованное решение для предотвращения бесконечных циклов, свойственных наивным обвязкам. GAIA от Meta и Hugging Face создала бенчмарк универсальных помощников, чья обвязка оценивает ответы на реальные вопросы, требующие навигации в интернете и работы с файлами; Open Agent Leaderboard от Hugging Face продолжает развивать сопоставимые рейтинги с учетом обвязки.

DeepSeek Harness (dsh) развивает идею метаобвязки и делает ее компонуемой. Его архитектура построена на фреймворке Cordis, а главный принцип состоит в том, что каждая часть обвязки заменяема плагином — включая адаптер модели, реестр инструментов, журнал сессии и сам цикл агента.

В основе проекта лежат три примитива. Во-первых, долговечный журнал сессии — единый источник достоверных данных о том, что видела модель; всё, что поступает в модель, должно быть восстановимо из журнала, и это обеспечивается как инвариант времени выполнения. Во-вторых, границы возможностей: заменяемый интерфейс провайдера между агентом и внешним миром, благодаря которому при переключении провайдеров файловой системы и подпроцессов на удаленную песочницу вместе с ними переносятся доступ к Bash, терминалу и языковому серверу — без ответвления обвязки. В-третьих, явный жизненный цикл хода/шага с именованными событиями расширений (agent/pre-step, tools/execute, agent/turn-stopping), которые позволяют плагинам перехватывать или переписывать цикл без изменения основного кода.

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

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

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

Но описанная выше траектория исследований ведет в другом направлении. τ-bench поместил пользователя внутрь обвязки. METR показал, что агенты берут на себя работу, растягивающуюся на дни, а не минуты. OSWorld и WebArena перенесли среду из чистого репозитория в беспорядочный реальный мир. Направление остается неизменным: когда агенты переходят от инструментов для программирования к полноценным рабочим помощникам, средой, в которой им нужно ориентироваться, становится не только кремний — это люди. Пользователи с ожиданиями, команды с общей историей, организации с правами доступа и накопленными знаниями.

Этот сдвиг прежде всего затрагивает одну подсистему обвязки: управление контекстом. У терминальной сессии один оператор и ограниченная история; у длительного взаимодействия — десять заинтересованных сторон, месяцы принятых решений и постоянно растущий репозиторий. Файловая система пассивна; рабочие отношения — это поток неявных обязательств, незавершенных мыслей и случайно принятых решений. Прежде чем всё это попадет в модель, его нужно суммировать, сжимать или отбрасывать, и в каждом таком решении агент теряет что-то необходимое для задачи.

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

Портфель обвязок Moonshot AI переносит анатомию, описанную ранее в этой статье, в единый управляемый стек. Для задачи «Агент × Компьютер» эти обвязки расширяют стандартный цикл: Kimi Browser Extension управляет реальной браузерной сессией через Chrome DevTools Protocol, а не стерильной песочницей; граница Ask-before-acting обеспечивает согласие на уровне файловой системы; а Agent Swarm масштабирует оркестрацию до 300 подагентов для долгосрочных задач.

Этот цикл работает на Kimi K3.1 Pro — первой модели серии K3.1 и самой мощной на сегодня открытой модели Moonshot AI класса 3T с контекстным окном в 1 048 576 токенов. Три ее свойства напрямую влияют на проектирование обвязки:

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

• Интенсивность рассуждений как настройка обвязки. K3.1 Pro всегда рассуждает, а reasoning_effort принимает значения low, high или max, причем по умолчанию используется max. Это превращает стоимость рассуждений модели в бюджет на конкретную задачу, который задает обвязка, а не в фиксированную цену доступа.

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

Moonshot приводит результаты обвязки вместе с моделью — именно за такую практику выступает эта статья. В Terminal-Bench 4.0, который оценивает агентов для программирования на реалистичных терминальных задачах с ограниченными ресурсами и строгими тестами для каждой задачи, K3.1 Pro набирает 65,7%: выше GPT-6 Astra (58,2%) и лишь немного ниже Claude Opus 5.5 (66,4%). В Kimi Code Bench 3.0 Long-horizon, внутреннем бенчмарке многошагового выполнения, использования инструментов и сквозного решения задач, модель получает 61,2% против 55,95% у K3. Документация столь же четко описывает и обратную зависимость: параметры сэмплирования, такие как temperature и top_p, зафиксированы и не должны включаться в запросы, а полное сообщение ассистента необходимо без изменений возвращать между ходами — обвязка, переписывающая сообщение, теряет рассуждения, от которых зависит следующий вызов инструмента.

Одна и та же модель работает на всей платформе. Управляемую веб-версию можно попробовать через Kimi Agent, запустить полную локальную обвязку с Kimi Work, работать в терминале с Kimi Code или напрямую вызывать kimi-k3.1-pro через Kimi API. Вариант kimi-k3.1-pro-highspeed предлагает скорость вывода в два-три раза выше примерно за двойную цену токенов.

Оцениваете ли вы модели или выпускаете продукт, подходит один и тот же контрольный список:

1. Начинайте с задачи, а не с фреймворка. Если ваши агенты редактируют код, подойдет проверенная обвязка Bash плюс редактор, такая как ACI от SWE-agent. Если они управляют GUI или работающим вебом, вам нужны наблюдения из реальных сессий и действия на уровне кликов.

2. Делайте среды воспроизводимыми. Docker-образы, закрепленные зависимости и начальные данные с фиксированным зерном — вот что отличает бенчмарк от единичного случая.

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

4. Устанавливайте жесткие лимиты. Ограничения на число шагов, тайм-ауты по реальному времени и бюджет в долларах на эпизод обеспечивают безопасность агентов и сопоставимость оценок.

5. С первого дня записывайте полные траектории. Каждому серьезному циклу улучшений — проверке людьми, кластеризации сбоев, дообучению — нужны данные траекторий. Managed Agents от Anthropic и DeepSeek Harness идут еще дальше: они хранят журнал сессии вне цикла обвязки в виде потока событий, доступного только для добавления, поэтому сама обвязка может быть заменяемой, а контекст модели всегда можно восстановить.

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

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

Обвязка агента незаметно стала важнейшим слоем агентного стека. Исследования SWE-bench, mini-SWE-agent, Terminal-Bench и METR показывают, что влияние проектирования обвязки может быть сопоставимо с обновлением модели; проекты с открытым исходным кодом, такие как DeepSeek Harness, OpenHands, SWE-agent и Aider, делают обвязки промышленного уровня доступными каждому; а Anthropic, OpenAI, Google, Microsoft и Moonshot AI теперь считают инженерную работу над обвязками первоклассной задачей.

Но более глубокий сдвиг носит концептуальный характер. Первое поколение обвязок решало задачу «Агент × Компьютер»: давало модели надежные руки для работы с терминалом, браузером и файловой системой. Следующее поколение решает проблему контекста, создаваемую этими средами: работу, растягивающуюся на дни, заинтересованных сторон и репозитории, которую ни один суммаризатор не сожмет без потерь. Обвязка превращается из вспомогательной конструкции в рабочую среду, а граница между тем, чем должна управлять обвязка, и тем, что модель способна просто удерживать в памяти, продолжает смещаться. Контекстное окно Kimi K3.1 Pro в миллион токенов — самый наглядный текущий пример: изменение модели устраняет работу, которую раньше приходилось выполнять обвязке.

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