Представьте себе ситуацию: вы просите нейросеть написать скрипт для анализа данных, но не просто выдать вам текст кода, а реально запустить его, проверить ошибки, исправить и вернуть готовый результат. Раньше для этого требовалась сложная инфраструктура, собственные серверы и тонны кода для оркестрации. Сегодня OpenRouter меняет правила игры, предоставляя разработчикам доступ к полноценному терминалу Linux прямо внутри API-вызовов. Это не просто еще одна функция, это фундаментальный сдвиг в том, как мы взаимодействуем с искусственным интеллектом: от генерации текста к выполнению действий.
Новый инструмент, названный openrouter:shell, в сочетании с Files API, позволяет любой модели, поддерживающей вызовы инструментов (tool calling), работать в изолированной среде. Это означает, что вы можете использовать модели от DeepSeek, Anthropic или OpenAI, но запускать их «мозги» в безопасном, контролируемом Linux-окружении. Для разработчиков из России и стран СНГ это особенно актуально, так как позволяет обходить некоторые ограничения локальных сред и использовать мощные облачные ресурсы для тяжелых вычислений, не беспокоясь о безопасности своей основной машины.
В этой статье мы подробно разберем, как устроена эта система, какие возможности она дает, как настроить сетевые политики для безопасности и как интегрировать это в свои проекты. Мы пройдем путь от базовых концепций до продвинутых сценариев использования, где AI выступает не как собеседник, а как полноценный инженер-исполнитель.
01Как работает Shell Tool: От текста к исполнению
В основе новой функциональности лежит концепция «серверных инструментов» (server tools). Ранее AI мог только генерировать текст. Теперь, добавив openrouter:shell в массив инструментов вашего запроса, вы даете модели доступ к виртуальному терминалу. Модель сама решает, когда ей нужно выполнить команду, и вызывает этот инструмент.
Процесс выглядит следующим образом: вы отправляете запрос через API, указывая модель и инструмент. Например, вы можете попросить модель проверить версию Python, написать скрипт для поиска простых чисел и запустить его. Модель генерирует команды, они выполняются в контейнере, и результаты (stdout, stderr и код выхода) возвращаются обратно в модель. Это позволяет ИИ видеть ошибки в реальном времени и исправлять их. Если скрипт упал с ошибкой, модель видит сообщение об ошибке в stderr и может переписать код, прежде чем дать вам финальный ответ.
Это создает цикл обратной связи, который ранее был возможен только при ручном запуске кода разработчиком. Теперь агент может самостоятельно отлаживать сложные пайплайны обработки данных, генерации отчетов или автоматизации задач.
Два стандарта: OpenAI Shell и Anthropic Bash
OpenRouter понимает, что экосистема AI неоднородна, поэтому реализовал поддержку двух основных спецификаций. Это критически важно для совместимости с существующими фреймворками, такими как LangChain, LlamaIndex или прямые вызовы к API.
- openrouter:shell: Совместим со спецификацией OpenAI. Работает как с Responses API, так и с Messages API. По умолчанию команды выполняются в песочнице OpenRouter.
- openrouter:bash: Совместим со спецификацией Anthropic. Работает с Messages API. Изначально этот инструмент предназначен для локального запуска команд в приложении пользователя, но на OpenRouter вы можете переопределить это поведение, указав параметр
engine: "openrouter".
Ключевой момент: добавление "engine": "openrouter" в параметры любого из этих инструментов гарантирует, что команда будет выполнена на серверах OpenRouter, а не на вашем локальном компьютере. Это обеспечивает безопасность и масштабируемость.
02Контейнеры: Изолированная среда выполнения
Каждый запуск Shell Tool происходит внутри изолированного Linux-контейнера. Это не просто виртуальная машина, а легковесная среда, созданная специально для выполнения кода. Контейнеры привязаны к вашему рабочему пространству (workspace) и имеют свои настройки безопасности и хранения данных.
Сетевая безопасность: Контроль доступа
По умолчанию outbound-доступ (исходящие соединения) из контейнера отключен. Это сделано для безопасности: модель не сможет случайно отправить ваши данные на сторонние серверы или выполнить вредоносные действия в интернете. Однако, если вам нужно установить пакеты через pip или скачать данные, вы можете настроить network_policy.
Вы можете задать список разрешенных доменов (allowlist). Например, для установки библиотек Python:
{
"type": "allowlist",
"allowed_domains": ["pypi.org", "files.pythonhosted.org"]
}Или, если вам нужен полный доступ к интернету (что требует осторожности):
{
"type": "allowlist",
"allowed_domains": ["*"]
}Разрешенные хосты доступны на портах 80 и 443. Запросы к доменам, не входящим в список, будут блокироваться. Важно помнить: политика сети не может быть изменена после того, как контейнер уже запущен. Поэтому настраивайте её правильно с первого раза.
Жизненный цикл контейнера
Контейнеры умны в управлении ресурсами. По умолчанию каждый новый разговор или запрос получает свежий контейнер. Однако, если вы передаете session_id или ссылку на предыдущий результат shell, контейнер будет переиспользован. Это позволяет сохранять состояние между запросами. Например, вы можете установить библиотеки в первом запросе, а во втором использовать их.
Если контейнер простаивает некоторое время, он «засыпает». Это время помогает оптимизировать затраты. Если вы активно работаете с контейнером, он остается активным.
Files API: Работа с файлами внутри и вне контейнер
Источник: OpenRouter ↗