Read the book: «Полевой гид по архитектуре современного AI-агента»

Введение

Эта книга о том, почему один и тот же искусственный интеллект в руках одной команды работает, а в руках другой нет. Не потому что одна команда покупает более дорогую модель. Не потому что у нее лучше промпт-инженеры. И уж точно не потому, что она знает секретные слова, которые заставляют нейросеть «стараться сильнее».

Дело в обвязке.

Обвязка - это все, что окружает языковую модель в работающей системе: системный промпт, набор инструментов, способ хранения контекста между сессиями, цикл обратной связи, в котором модель проверяет собственные ответы и пересобирает стратегию. Модель - это мозг. Обвязка это руки, инструменты, память и рабочий стол. И, как показывают свежие исследования, разница между «способной моделью с плохой обвязкой» и «средней моделью с хорошей» в 2026 году огромна.

Эту книгу я писал для тех, кто внедряет AI-агентов в реальные продукты. Для инженеров, которые видят, что агент «вроде работает», но жжёт бюджет и проваливает простые задачи. Для продакт-менеджеров, которые не понимают, почему замена модели на более дорогую не дала прироста. Для основателей небольших студий, которые хотят разговаривать с разработчиками на одном языке, когда речь идет об архитектуре агентской системы.

Здесь нет кода, который нельзя запустить, и нет формул, которые нельзя объяснить. Здесь есть десять исследований, отобранных по одному критерию: применимо ли это завтра в вашем продукте. Каждое из них опубликовано на arXiv в июле или августе 2026 года, и каждое меняет что-то в том, как нужно строить агентов.

Что вы получите

Книга состоит из трех частей.

В первой части мы разберемся, почему обвязка важнее модели, и увидим два конкретных способа, которыми плохая обвязка буквально сжигает деньги. Это главы о JSON-вызовах инструментов, которые проигрывают Python-стабам, и о промптах, которые заставляют агента работать в семь раз больше, чем нужно.

Во второй части перейдем к архитектуре. Научим агента понимать, насколько задача сложная, и не читать весь репозиторий ради однострочной правки. Построим память, которая помнит нужное и не забывает лишнее. Защитимся от ситуации, когда старая история диалога ломает агента, и научимся делать retrieval так, чтобы контекст не раздувался.

В третьей части поговорим о циклах, которые улучшают сами себя. Агент, который переписывает собственную обвязку в рантайме. Система из нескольких агентов, которые эволюционируют общую обвязку на своих данных и делятся находками. И, наконец, метрики, по которым вообще можно понять, что обвязка стала лучше, а не просто «вроде работает».

Как читать эту книгу

Книгу можно читать последовательно, от введения до заключения. Главы выстроены так, что каждая опирается на предыдущую и готовит следующую. Но если вы опытный инженер и вам нужна конкретная тема, можно начать с нее каждая глава самодостаточна, и в конце есть мостик к следующей, чтобы вы не потерялись.

Если вы читаете книгу, чтобы внедрить что-то конкретное в понедельник утром, в каждой главе есть блок «Что сделать прямо сейчас» с конкретными шагами. Если вы читаете, чтобы понять, как устроено современное AI-внедрение, эти блоки можно пропустить.

В конце книги есть заключение, которое называется «Что делать в понедельник утром». В нем собран один список из десяти шагов, ранжированных по приоритету. Если у вас есть пятнадцать минут и работающий AI-агент, начните оттуда.

Чего в этой книге нет

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

Здесь есть трезвая инженерная работа. Архитектура. Метрики. Циклы обратной связи. Экономика токенов. И десять конкретных исследований, каждое из которых улучшит вашу систему, если вы внедрите его результаты.

Давайте начнем.

Глава 1. Горький урок 2026 модель это тридцать процентов, обвязка семьдесят

В августе 2026 года исследователи из Scale AI опубликовали работу под названием HarnessOpt-Bench.

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

А если дать одинаковую модель, но разные обвязки, кто выиграет тогда?

Ответ оказался таким обвязка важнее.

В эксперименте участвовали пять frontier-моделей: Claude Opus 5, Claude Sonnet 5, Kimi K3, GPT-5.6-Sol и GPT-5.6-Terra. Все они решали четыре разные задачи GAIA (многошаговое исследование с веб-инструментами), OfficeQA Pro (корпоративное рассуждение над документами), BrowseComp-Plus (глубокий web-research) и Terminal-Bench 2.0 (задачи command-line).

Каждая модель работала в двух режимах: под общей coding-обвязкой и под своей нативной обвязкой. Сто одиннадцать зачетных прогонов. И результат, который стоит запомнить.

Когда меняли модель, эффект на качество был огромным.

Claude Opus 5 стабильно превосходил остальных. Когда меняли обвязку, эффект тоже был, но меньше. Но и это критическая оговорка оптимизация обвязки, выполненная правильно, давала прирост, сопоставимый с разницей между лучшей и худшей моделью.

Переведем на человеческий. Если у вас есть средняя модель и хорошая обвязка, вы обгоняете тех, у кого топовая модель и плохая обвязка. Если у вас топовая модель и плохая обвязка, вы проигрываете.

Почему это важно

Последние пять лет мы жили в парадигме «купить более умную модель». Бенчмарки росли, новости выходили, маркетологи продавали. Но между «модель хорошо решает задачу в лаборатории» и «агент хорошо решает задачу в продакшне» — пропасть. Эта пропасть и заполняется обвязкой.

Обвязка делает три вещи, которые модель сама по себе делать не умеет.

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

Во-вторых, обвязка ограничивает то, что модель может сломать. Модель умеет генерировать SQL. Но чтобы SQL не угробил базу клиента, нужны белый список таблиц, проверка синтаксиса, тестовый прогон на копии, откат при ошибке. Все это обвязка.

В-третьих, обвязка создает экономику. Модель стоит одинаково на любом запросе. Но архитектура вызова может сделать этот запрос в десять раз дешевле или в десять раз дороже. И выбрать дешевый способ — это инженерное решение, а не магия модели.