Агенту нужны какие базовые инструменты

Вижу, что все обсуждают вопрос набора инструментов для агента — достаточно ли просто предоставить shell, чтобы всё работало? После работы с holon понял, что всё не так просто.
Читаю: почему отказались от Read/Glob и полностью перешли на shell
Набор инструментов holon менялся несколько раз, в итоге отказались от таких специализированных инструментов, как Read (чтение файла), Glob (поиск по шаблону), предоставляемых Claude Code, и все операции чтения и поиска выполняются через shell. Это совпадает с подходом Codex — ExecCommand — команда `cat` для чтения файла, `rg` для поиска кода, больше не выделяют отдельные инструменты для каждого "чтения".
Причина такого подхода очень проста: shell — это наиболее знакомый LLM "язык программирования". Вместо того чтобы учить модель смыслам параметров определённых инструментов Read, проще дать ей писать уже обученные миллиардами команд shell. Каждый дополнительный специализированный инструмент увеличивает когнитивную нагрузку модели; а интерфейс shell модель уже достаточно освоил.
Но есть цена у полного перехода на shell: ограничение вывода. Чтобы избежать слишком длинных ответов, которые могут переполнить контекст, для каждой команды устанавливается лимит по выводу. Например, Agent использует `cat` для чтения большого файла, и может получить только его первую часть, остальное — в файле artifact, и чтобы прочитать всё, нужно повторно `cat`ить, иногда несколько раз. Read инструмент Claude Code имеет гораздо более высокий порог сжатия, позволяя читать большие файлы за один раз, избегая лишних итераций. По сути, это компромисс: меньше определённых инструментов — меньшая когнитивная нагрузка, но специализированные инструменты в определённых сценариях работают эффективнее.
Пишем: от `sed` до `ApplyPatch` и сложности с инструментом free grammar
Но операции записи полностью через shell реализовать нельзя.
Если заставить агента полностью использовать `sed` для редактирования, столкнёмся с трудностями при сложных многострочных совпадениях — перенос строк, экранирование, отступы — любые ошибки могут привести к сбою редактирования. Поэтому многие системы предоставляют такие инструменты, как Replace String, позволяющие агенту передать большой блок старой строки для точного совпадения и замены на новую. Хотя это менее удобно, чем `sed`, зато гораздо стабильнее.
Codex пошёл дальше, создав собственный инструмент `ApplyPatch`, позволяющий агенту напрямую генерировать патчи для массового редактирования. holon тоже использует этот подход.
Но при внедрении возникла проблема: Codex использует собственный упрощённый формат патча, а также специальный механизм — free grammar tool — для передачи формата.
Зачем нужна новая механика? Потому что стандартные определения инструментов для LLM — `tool(args)` — используют JSON параметры. Передача патча как JSON-строки вызывает множество проблем с экранированием — переносы строк, кавычки, отступы — всё это усложняет передачу. При написании патча модель уже склонна к ошибкам, а добавление JSON-экранирования увеличивает вероятность ошибок вдвое. Идея free grammar tool — передавать исходный текст патча прямо как входные данные инструмента, без JSON-кодирования, что позволяет модели писать что угодно без ошибок. Это значительно снижает вероятность ошибок при генерации патча.
На данный момент эта механика поддерживается только интерфейсом OpenAI Codex. holon стремится быть совместимым с разными поставщиками моделей, поэтому полагаться только на это нельзя.
Поэтому holon реализует разные определения `ApplyPatch` в зависимости от модели. Для моделей, поддерживающих free grammar, используется оригинальный формат патча; для остальных — стандартный формат `git diff`. Я считаю, что после обучения на миллиардах diff-операций на GitHub модели хорошо знакомы с форматом `git diff`. На практике это работает — хотя иногда возникают ошибки, в большинстве случаев исправление происходит правильно, и с накоплением данных эта способность только улучшается. Всё же я советую всем производителям моделей поддерживать free grammar tool, ведь для сценариев написания кода агентом это действительно необходимо.
Оркестрация: долгие команды и абстракции задач
Третий вопрос — команды shell, выполняемые агентом, могут не завершаться быстро: запуск dev-сервера, тесты, сборка проекта — всё это может идти долго или вообще не завершаться. В ранних версиях фреймворка агент работал очень грубо: либо синхронно блокировал себя, либо запускал все команды в фоне, из-за чего агент мог многократно выполнять одну и ту же команду.
Теперь в индустрии постепенно сформировался базовый консенсус: не стоит давать агенту выбор "передний/фоновый" режим — это слишком сложно для агента. Лучше установить тайм-аут, после которого команда автоматически переводится в фоновый режим, и агенту это полностью не видно. Агент не должен сам решать, стоит ли запускать команду в фоне — всё делает рантайм.
Но автоматический перевод в фон — только первый шаг. После этого возникают реальные инженерные проблемы — и пока в индустрии нет единого решения.
Во-первых, как читать вывод. Фоновые задачи могут всё ещё выполняться или уже завершиться, вывод может быть очень большим. Но API у разных систем разный — кто-то использует опрос, кто-то — push-уведомления.
Во-вторых, как останавливать задачу. Есть механизмы отмены, но — убивать сразу или аккуратно завершать, сохранять ли уже полученный вывод?
И, наконец, кто должен "разбудить" агента. После отправки задачи в фон агент засыпает, а когда задача завершится — кто его разбудит? Это требует глубокой интеграции рантайма и планировщика агента, и не решается простыми инструментами.
Эти три аспекта — чтение вывода, остановка задачи, пробуждение агента — вместе образуют полный цикл управления фоновыми задачами. Все реализуют возможность запускать в фоне, но стандартных решений по управлению пока нет — это, вероятно, следующий важный этап развития инструментов агента.
Пока не стоит слепо использовать готовую модель
Возвращаясь к началу: shell решает 80%, но оставшиеся 20% — точность редактирования, формат патча и возможности модели — определяют, сможет ли агент перейти от демонстрации к полноценной системе.
Выбор инструментов — это не просто "обернуть shell", и ещё не время бездумно применять готовые шаблоны. Именно поэтому Codex и Claude Code дают разные ответы на эти базовые вопросы, а holon подстраивается под свои сценарии. В этом много пространства для исследований и улучшений.