AI, который не просто болтает, а делает
Когда-то мы мечтали, чтобы нейросеть могла сама исправить кривой конфиг или перезапустить упавший докер-контейнер. Потом пришли ChatGPT с плагинами, Open Interpreter и куча агентов на Python — но все они требовали либо денег, либо танцев с бубном. А теперь в llama.cpp появилось нечто, от чего у разрабов зачесались руки: exec_shell, edit_file и компания. Прямо из коробки. Без обёрток. Без внешних сервисов.
Разработчики llama.cpp, видимо, устали смотреть, как народ колхозит костыли для запуска скриптов через API. И в начале 2026 года (в версии b5XXX, если быть точным) в сервер вшили набор инструментов, которые дают модели доступ к файловой системе и шеллу. Звучит как безумие? Только если забыть, что это локально — всё на вашей машине, без утечек. Но давайте по порядку.
Что под капотом: джентльменский набор
В новом API сервера появилось несколько эндпоинтов, которые завязаны на MCP-подобный протокол (Model Context Protocol). Вот основные:
exec_shell— выполняет произвольную команду в shell (с таймаутом, потоковым выводом).edit_file— применяет diff или замену в указанном файле (с откатом по флагу).read_file— читает содержимое файла в контекст.list_dir— возвращает список файлов в директории.search_files— grep-подобный поиск по проекту.
Все они вызываются через POST-запросы, а модель может сама решать, когда их юзать, если в промпте разрешить использование инструментов. Теперь LLM способна не только сгенерировать команду, но и сразу её выполнить — классический цикл «agentic workflow».
Ключевое отличие от Open Interpreter: всё работает через один сервер llama.cpp, не нужен отдельный раннер, не нужен Python-враппер. Просто дергаешь API и получаешь результат. А модель может быть любой, от Llama 3.2 до Qwen 2.5.
Как это ломает привычный сценарий
Раньше, чтобы заставить LLM редактировать файлы, вы писали обвязку на Python: парсили ответ, вычленяли код, применяли патч, проверяли ошибки. Теперь модель сама решает, что ей сделать: открыть файл, изменить 15-ю строчку, снова прочитать и проверить. Это уровень агента, который раньше давали только дорогие облачные сервисы.
Вот минимальный пример: вы просите модель «исправить баг в парсере JSON в файле parse.rs». Модель через read_file читает файл, находит ошибку, через edit_file применяет исправление, затем через exec_shell запускает cargo test. Всё это — за один запрос с последовательными вызовами инструментов. Результат — готовое исправление.
--allowed-paths для ограничения зоны действия инструментов.Сравнение с альтернативами: не прогадал ли автор?
Давайте честно: утилита Open Interpreter делала то же самое, но с двумя недостатками. Во-первых, она требовала отдельного демона и часто ломалась на интерпретации вывода. Во-вторых, она гоняла код через системный Python — что открывало дыры (об этом мы писали в статье Критическая дыра в llama.cpp).
Другой вариант — агенты на LangChain с инструментами. Но там надо настраивать раннер, модель, промпты — и всё равно под капотом часто тоже llama.cpp. Зачем лишняя прослойка?
Прямой конкурент — Function Calling в OpenRouter или Ollama. У Ollama с недавнего времени тоже появились встроенные инструменты, но они ещё сырые (не поддерживают потоковое выполнение shell-команд). llama.cpp здесь выигрывает по зрелости: редактирование файлов с диффами, ограниченные права, отмена по таймауту — всё уже оттестировано.
| Инструмент | llama.cpp tools | Open Interpreter | Ollama tools |
|---|---|---|---|
| Установка | Один бинарник | pip install + настройка | Бинарник + мод |
| Безопасный изоляция | allowed-paths + таймауты | Только через Docker | нет |
| Поддержка потокового вывода | Да | Да | Нет |
| Редактирование файлов | Нативно (diff) | Через exec | Через exec |
Живой пример: исправление ошибки в веб-приложении
Допустим, вы хотите автоматизировать правку бага в проекте на Node.js. Раньше надо было писать CI-пайплайн. Теперь достаточно сделать POST-запрос к вашему локальному серверу llama.cpp с таким телом:
{
"messages": [
{"role": "system", "content": "У тебя есть инструменты: exec_shell, read_file, edit_file. Используй их для исправления ошибки."},
{"role": "user", "content": "В файле /app/routes/users.js на строке 42 происходит TypeError при чтении undefined name. Исправь."}
],
"tools": ["exec_shell", "edit_file"],
"allowed_paths": ["/app"]
}Модель автоматически прочитает файл (read_file), найдет баг, создаст патч и применит его через edit_file, затем запустит тесты через exec_shell. Всё это — в одном сеансе. Ну как вам, а?
Обратная сторона медали: безопасность
Здесь есть очевидный риск: дать LLM доступ к shell — это как доверить коту открывать холодильник. Разработчики это предусмотрели. Во-первых, все инструменты требуют явного списка разрешённых директорий (флаг --allowed-paths). Во-вторых, exec_shell запускается в sandbox-окружении с таймаутом по умолчанию 30 секунд. В-третьих, команды можно дополнительно фильтровать через чёрный список.
Тем не менее, рекомендую прочитать нашу статью Как заблокировать нежелательные фразы в llama.cpp — там скрипт для валидации вывода. Лишним не будет.
Кому это нужно и кто будет плакать
Инструменты идеально подходят:
- Разработчикам, уставшим писать CI/CD вручную — модель сама накатит фиксы.
- DevOps-инженерам, которые хотят автоматизировать администрирование через голосовой интерфейс.
- Исследователям AI-агентов — теперь не нужно делать прослойку, всё в одном binary.
Но есть и те, кто расстроится: авторам обёрток вроде Hexllama и многочисленных GUI-инструментов — их скрипты для работы с файлами теперь избыточны. Впрочем, Hexllama как раз и упрощает запуск сервера с нужными флагами — там появился переключатель для включения tools.
Будущее: от чат-бота к цифровому ассистенту
Сейчас exec_shell и edit_file — это первые ласточки. Уже в бета-версиях засветились fork_repo и run_docker. Если так пойдёт, к концу 2026 года локальный llama.cpp сможет заменить целый отдел разработки. Конечно, с оговорками: не все модели хорошо следуют инструментам. Qwen2.5-7B справляется отлично, а вот некоторые мелкие модели могут начать творить дичь.
Совет: начинайте с модели Llama 3.1 8B или Qwen2.5 7B, включите инструменты, дайте задачу «починить тесты в проекте» — и смотрите. Вероятно, вы удивитесь. А если нет — всегда можно откатить изменения через git checkout ..
