Что мы узнали о создании агентных ИИ-инструментов?

В середине 2025 года агентный кодинг наконец-то стал реальностью: сначала с выпуском Claude Sonnet 4, первой агентной модели, которая была «достаточно умной, чтобы быть полезной», а затем с GPT-5-Codex от OpenAI, которая, на мой взгляд, является лучшей в своем классе агентной моделью. «Режим агента» теперь является основным способом взаимодействия с вашим предпочтительным инструментом для ИИ-кодинга (будь то Claude Code, Codex, Copilot или Cursor)¹.

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

В качестве интересной капсулы времени вы можете прочитать мой пост 2023 года «Создание агентов на базе LLM» (Building LLM-driven agents), где я писал о своих попытках построить систему агентного кодинга на базе GPT-3 (!). Это было до того, как появились вызовы инструментов (tool calls) — мне приходилось просить модель включать структурированный контент вызова инструмента в свой вывод, а затем парсить его. Оглядываясь назад, я был прав в нескольких важных вещах:

• Агентный кодинг с помощью LLM действительно может работать.
• Если вы создадите хороший инструмент для агентного кодинга, он станет только полезнее с выходом лучших моделей.
• Вы должны настраивать свой инструмент под конкретную модель, вместо того чтобы ожидать, что один инструмент будет хорошо работать со всеми моделями.
• Самое главное, создание инструмента для агентного кодинга — это обычная программная инженерия: вы можете сделать его более полезным, вложив больше времени в его полировку и улучшение.

Итак, что мы узнали о создании инструментов для агентного кодинга с тех пор?

Агенты должны планировать, затем действовать. Вместо того чтобы просто сказать «вот твои инструменты, иди решай эту проблему», вы должны настроить свой инструмент для кодинга (через комбинацию специфических инструментов и промптинга) так, чтобы он начинал с составления четкого плана. На самом деле, ваш инструмент должен отмечать пункты плана по мере выполнения. Это очень помогает поддерживать связность и предотвращает уход цепочки рассуждений (chain-of-thought) в сторону. Часто хорошей идеей является использование более мощной модели для составления плана, а затем более дешевой, но быстрой модели для выполнения.

Пользователи должны иметь возможность подключать свои собственные инструменты. Канонической версией этого является MCP, но подойдет любой маркетплейс инструментов или система плагинов. Суть в том, что есть большая польза в том, чтобы позволить пользователям подключать, скажем, их экземпляр Slack или Jira к вашему кодинг-агенту. Однако:

Не давайте агенту слишком много инструментов. Агенты работают лучше всего, когда у них есть короткий, но ёмкий набор инструментов для работы. Слишком большое количество инструментов может использовать слишком много контекстного окна и в конечном итоге запутать модель. На самом деле, текущий тренд — это крайний минимализм, с чем-то вроде инструмента «выполнить команду оболочки» и инструмента «внести патч-правку в файл»². Любая сильная LLM уже может использовать командную строку для листинга и чтения файлов, выполнения HTTP-запросов и так далее — если это есть в обучающих данных, вам не нужно занимать этим ценное пространство контекста.

Используйте вложенные файлы правил для каждого чата. Одним из преимуществ агентных инструментов является то, что они чрезвычайно настраиваемы с помощью инструкций на естественном языке. Все текущие инструменты ИИ-кодинга используют это преимущество, будь то через файл CLAUDE.md или более общий AGENTS.md. Фактически, инструменты теперь поддерживают вложенность этих файлов, так что вы можете иметь глобальный AGENTS.md в вашей домашней директории с общими правилами, и один в вашем репозитории с правилами, специфичными для репозитория, и один в папке /auth с правилами, которые касаются только вашего кода аутентификации, и так далее. Инструмент автоматически справится с загрузкой правильной комбинации этих файлов в контекст по мере того, как агент перемещается между папками.

Сделайте так, чтобы пользователю было легко управлять агентом в процессе. Если ваш агент работает, и вы видите, что он делает что-то неправильное или неожиданное, у пользователя должен быть способ прервать его и направить в новое русло. Claude Code делает это автоматически, когда вы отправляете сообщение, в то время как Codex заставляет вас сначала нажать escape, чтобы приостановить цепочку мыслей агента. Я думаю, что любой способ работает нормально — суть в том, что агентам нужен какой-то способ оправиться от поворота не туда³.

Сделайте возможным для пользователя ставить новые команды в очередь. Codex делает это, когда вы отправляете новые сообщения. Claude Code не позволяет вам этого делать, и я считаю, что это большая ошибка. Агенты теперь достаточно хороши, чтобы им можно было доверять небольшие изменения, поэтому пользователи должны иметь возможность сказать «когда закончишь, сделай эту поправку» столько раз, сколько они захотят. Команды в очереди также полезны, когда вы хотите заставить агента работать долгое время. Например, когда я пробовал Codex в своем челлендже «пятиминутная LLM», иногда я просто ставил в очередь десять сообщений «Хорошо, пожалуйста, продолжай», если мне нужно было отойти на час⁴.

Поддержка слэш-команд. Пользователи будут взаимодействовать с вашим инструментом агентного кодинга путем ввода текста: сначала описание того, что они хотят сделать, а затем различные сообщения типа «нет, сделай это так» или «да, продолжай». Агентные инструменты, следовательно, должны предоставлять дополнительную функциональность в виде слэш-команд, которые пользователь может вводить (например, чтобы переключить модель, или отправить PR, или что угодно еще).

Используйте обычные инструменты поиска, а не RAG. В ранние дни агентов казалось, что RAG — разбиение кодовой базы на части (chunking) и генерация векторного представления (embedding) для каждой части, а затем использование какого-то вида численного сходства для идентификации релевантных частей кодовой базы — будет лучшим решением для навигации по большим кодовым базам⁵. Но это оказалось совершенно неверным. Текущие инструменты ИИ-кодинга просто позволяют LLM выполнять строковый поиск, что намного эффективнее (и намного проще для пользователя, так как это не требует медленного этапа «встраивания всей кодовой базы», прежде чем агент сможет начать работу).

Мы все еще находимся на очень раннем этапе в мире агентного ИИ-софта. Почти наверняка есть другие базовые элементы дизайна, которые еще предстоит открыть. Возможно, мы закончим специализированными моделями для поиска по кодовой базе, такими как SWE-grep от Windsurf. Сейчас существует довольно равномерное разделение между инструментами внутри редактора и инструментами CLI, но в конечном итоге один из них может победить. Я думаю, что субагенты — это в основном мишура, но я могу ошибаться. Лучшие модели все еще могут изменить игру (например, сделав запуск агентного потока без присмотра более привлекательным). Лично мне не хватает рабочего процесса «сбрось свою текущую цель и контекст в промпт, который я затем могу вставить в другой инструмент».

Какие еще очевидные задним числом идеи мы упускаем?