Shell, Skills и Compaction: советы для долгоиграющих агентов

Практические паттерны для работы со skills, hosted shell и server-side compaction в Responses API — всё, что нужно для создания агентов, выполняющих реальную работу.

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

Shell, Skills и Compaction: советы для долгоиграющих агентов

Shell + Skills + Compaction: Tips for long-running agents that do real work Автор: Charlie Guo Оригинальный текст:

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

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

• Skills (навыки, совместимые с открытым стандартом Agent Skills): переиспользуемые версионированные инструкции, которые можно подключать к контейнерам, чтобы агенты выполняли задачи надёжнее.
• Улучшенный инструмент shell: контейнер OpenAI с контролируемым доступом в интернет, где агент может устанавливать зависимости, запускать скрипты и сохранять результаты (например, отчёты и артефакты).
• Server-side compaction (серверное сжатие контекста): простой способ автоматически сжимать длинные агентные сессии, чтобы никогда не упираться в лимиты контекстного окна.

Документация и API reference описывают каждый элемент отдельно. Этот пост фокусируется на неочевидных советах и паттернах, которые мы видели работающими — как в нашей работе в OpenAI, так и в продакшене у Glean, одного из первых пользователей skills.

Краткая ментальная модель

Skills: «процедуры», которые модель загружает по требованию

Skill — это набор файлов плюс манифест SKILL.md с метаданными и инструкциями. Считайте это версионированным руководством, к которому модель обращается, когда приходит время выполнять реальную работу.

Когда skills доступны, платформа показывает модели name, description и path каждого skill. Модель использует эти метаданные, чтобы решить, вызывать ли skill. Если вызывает — читает SKILL.md для получения полного workflow.

Shell tool: «исполнение» для агентов

Shell tool позволяет моделям работать внутри реального терминального окружения:

• Hosted-контейнеры под управлением OpenAI.
• Локальный shell runtime, который вы запускаете сами (та же семантика инструмента, но машина под вашим контролем).

Hosted shell работает через Responses API, а значит ваши запросы получают stateful-работу, tool calls, многораундовое продолжение и артефакты.

Compaction: поддерживаем длинные сессии в движении

По мере удлинения workflow они упираются в лимиты context window (контекстного окна). Server-side compaction поддерживает длинные сессии, управляя контекстным окном и автоматически сжимая историю разговора.

Compaction в Responses API даёт два способа справиться с этим:

• Server-side compaction (новинка): когда контекст пересекает порог, compaction запускается автоматически прямо в потоке — никакого отдельного вызова.
• Отдельный compact endpoint: используйте /responses/compact, когда хотите явно контролировать момент сжатия.

Почему они лучше работают вместе

• Skills уменьшают «промпт-спагетти», вынося стабильные процедуры и примеры в переиспользуемый пакет.
• Shell обеспечивает полноценное окружение исполнения: установка кода, запуск скриптов, запись результатов.
• Compaction сохраняет непрерывность на длинных сессиях, позволяя одному workflow продолжать выполнение без ручной «хирургии контекста».
• Вместе вы получаете воспроизводимые workflow с реальным исполнением — без превращения системного промпта в хрупкий мегадокумент.

Советы и приёмы

1) Пишите описания skills как логику роутинга (а не маркетинговый текст)

Описание вашего skill — фактически граница принятия решений для модели. Оно должно отвечать на вопросы:

• Когда мне использовать это?
• Когда НЕ использовать?
• Какие выходы и критерии успеха?

Практичный паттерн — включать короткий блок «Использовать когда vs. не использовать когда» прямо в описание и делать его конкретным (входы, задействованные инструменты, ожидаемые артефакты).

2) Добавляйте негативные примеры и граничные случаи для уменьшения ложных срабатываний

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

На практике это означает написание нескольких явных кейсов «Не вызывай этот skill когда…» (и что делать вместо этого). Это помогает модели роутить чище, особенно когда у вас несколько skills, которые выглядят похоже на первый взгляд.

Glean увидели это напрямую: роутинг на основе skills изначально снизил срабатывание примерно на 20% в целевых eval'ах, а затем восстановился после добавления негативных примеров и покрытия граничных случаев в описаниях.

3) Помещайте шаблоны и примеры внутрь skill (они практически бесплатны, когда не используются)

Если вы впихивали шаблоны в системный промпт — прекратите.

Шаблоны и проработанные примеры внутри skills имеют два преимущества:

• Они доступны именно тогда, когда нужны (при вызове skill).
• Они не раздувают токены для несвязанных запросов.

Это особенно эффективно для outputs интеллектуальной работы:

• Структурированные отчёты.
• Сводки по эскалационным триажам.
• Планы по аккаунтам.
• Аналитические отчёты по данным.

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

4) Проектируйте для длинных сессий заранее, используя повторное использование контейнеров и compaction

Долгогоризонтные агенты редко успешны как one-shot промпты. Планируйте непрерывность с самого начала:

• Переиспользуйте тот же контейнер между шагами, когда хотите стабильных зависимостей, кэшированных файлов и промежуточных результатов.
• Передавайте previous_response_id, чтобы модель могла продолжить работу в том же треде.
• Используйте compaction как дефолтный примитив для длинных сессий, а не аварийный fallback.

Эта комбинация уменьшает поведение перезапуска и сохраняет когерентность многошаговых задач по мере роста треда.

5) Когда нужен детерминизм — явно скажите модели использовать skill

Поведение по умолчанию: модель сама решает, когда использовать skill. Часто это именно то, что вам нужно.

Но когда вы запускаете продакшн-workflow с чётким контрактом (и предпочитаете детерминизм изяществу) — просто скажите:

«Используй skill <имя skill>».

Это простейший рычаг надёжности. Он превращает размытый роутинг в явный контракт.

6) Относитесь к skills + сеть как к высокорисковой комбинации (проектируйте для изоляции)

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

Комбинация skills с открытым сетевым доступом создаёт высокорисковый путь для эксфильтрации данных. Если используете сеть — держите network allowlists строгими, считайте tool output недоверенным и избегайте открытого интернета плюс мощных процедур в consumer-facing потоках, где пользователи ожидают надёжного подтверждения.

Надёжная дефолтная позиция:

• Skills: разрешены
• Shell: разрешён
• Network: включён только с минимальным allowlist, per request, для узко ограниченных задач

7) Сделайте /mnt/data границей передачи артефактов

Для hosted shell workflow'ов относитесь к /mnt/data как к стандартному месту для записи outputs, которые вы будете забирать, ревьюить или передавать в последующие шаги. Примеры: отчёты, очищенные датасеты, готовые таблицы.

Хорошая ментальная модель: инструменты пишут на диск, модели рассуждают над диском, разработчики забирают с диска.

8) Понимайте allowlists как двухуровневую систему (org-level и request-level)

Сеть контролируется в двух местах:

• Org-level allowlist (настраивается админом), устанавливающий максимально разрешённые направления.
• Request-level network_policy, который должен быть подмножеством org allowlist.

Две практические импликации:

1. Держите org allowlist маленьким и стабильным (набор «одобренных направлений, которым вы доверяете»).
2. Держите request allowlists ещё меньше (набор «направлений, нужных для этой одной задачи»).

Если запрос включает домены за пределами org allowlist — будет ошибка.

9) Используйте domain_secrets для аутентифицированных вызовов (избегайте утечки credentials)

Если разрешённому домену нужны auth headers — используйте domain_secrets, чтобы модель никогда не видела сырые credentials.

Во время выполнения модель видит плейсхолдеры (например, $API_KEY), а sidecar инжектит реальные значения только для одобренных направлений. Это надёжный дефолт каждый раз, когда ваш агент должен вызвать защищённый API изнутри контейнера.

10) Используйте одни и те же API в облаке и локально

Вы можете использовать оба примитива, не привязываясь к хостингу всего:

• Skills работают как с hosted shell, так и с local shell mode.
• Shell имеет локальный режим исполнения, где вы сами выполняете shell_call и возвращаете shell_call_output модели.
• Если используете Agents SDK — можете также подключить свой собственный shell executor.

Практичный dev loop выглядит так:

1. Начинайте локально (быстрая итерация, доступ к внутренним инструментам, лёгкая отладка).
2. Переходите на hosted-контейнеры, когда хотите воспроизводимости, изоляции и consistency развёртывания.
3. Сохраняйте skills одинаковыми в обоих режимах (workflow остаётся стабильным, даже когда исполнение переезжает).

Три паттерна сборки

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

Паттерн A: Install → fetch → write artifact

Самый простой способ извлечь пользу из hosted shell: агент устанавливает зависимости, получает внешние данные и создаёт конкретный deliverable.

Например:

• Установить пару библиотек.
• Сделать scrape или вызвать API.
• Записать отчёт в /mnt/data/report.md.

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

Паттерн B: Skills + shell для воспроизводимых workflow

Как только вы построите один-два успешных shell workflow, вы заметите следующую проблему: это работает, но надёжность деградирует, когда промпты дрейфуют.

Вот где вступают skills. Вот устойчивая структура для следования:

1. Закодируйте workflow (шаги, guardrails, шаблоны) в skill.
2. Подключите skill к вашему shell-окружению.
3. Пусть агент следует skill для детерминированного создания артефактов.

Это особенно эффективно для workflow типа:

• Анализ или редактирование таблиц.
• Очистка датасетов плюс генерация summary.
• Стандартизированная генерация отчётов для повторяющихся бизнес-процессов.

Паттерн C (продвинутый): Skills как носители корпоративных workflow

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

Конкретный пример от Glean:

• Skill, ориентированный на Salesforce, повысил точность eval'ов с 73% до 85% и уменьшил time-to-first-token на 18.1%.
• Практические тактики включали тщательный роутинг, негативные примеры и встраивание шаблонов/примеров внутрь skill.
• Glean также использует skills для кодирования повторяющихся задач в корпоративных workflow: планирование аккаунтов, триаж эскалаций, генерация контента в соответствии с брендом.

Вот форма того, где всё становится мощным. Skills становятся живыми SOP (стандартными операционными процедурами): обновляются по мере эволюции вашей организации и исполняются агентами консистентно.

Собрал один раз — запускай где угодно

Долгоиграющие агенты становятся драматически полезнее, когда могут и следовать процедурам, и выполнять реальную работу на компьютере. Skills, hosted shell и compaction создают эту основу. Резюмируем:

• Используйте skills для кодирования «как» (процедуры, шаблоны, guardrails).
• Используйте shell для исполнения «делай» (install, run, write artifacts).
• Используйте compaction для сохранения когерентности длинных сессий (без ручного управления контекстом).
• Начинайте локально, когда быстро итерируете.
• Переходите на hosted-контейнеры, когда хотите воспроизводимого, изолированного исполнения.
• Держите сеть заблокированной с org-level и request-level allowlists и используйте domain secrets для аутентифицированных вызовов.

Начните строить в своём собственном приложении. Смотрите документацию по skills, документацию по shell и документацию по compaction, чтобы узнать как.

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

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