Что такое обвязка вокруг агентов
Откройте ChatGPT и напишите: «Собери мне телеграм-бота». В ответ вы получите код — может быть, даже рабочий. Но это просто текст на экране. ChatGPT не создаст файл, не установит библиотеки, не запустит бота и не проверит, работает ли он.
А теперь откройте Claude Code в папке проекта и напишите то же самое. Claude Code создаст файлы, установит зависимости, запустит бота, проверит, что тот отвечает, и если что-то сломается — попробует починить. Та же самая модель Claude, но ведёт себя совершенно иначе.
Разница — не в модели. Модель в обоих случаях делает одно и то же: принимает текст и генерирует текст. Разница в том, что находится вокруг модели. В ChatGPT вокруг неё — только поле ввода и поле вывода. В Claude Code вокруг неё — программа, которая умеет читать файлы, запускать команды, запоминать контекст проекта, проверять результат и решать, что делать дальше.
Все нейросети
в одном флаконе
ChatGPT, Claude, Gemini
и другие — в агрегаторе Нейроцеха
Всё, что окружает модель и превращает её из генератора текста в автономного агента, разработчики называют обвязкой (agent harness). Модель — это мозг. Обвязка — это всё остальное: глаза, руки, память, чувство самосохранения.
Зачем вам это знать? Вы уже работаете с агентами — в Cursor, в Claude Code, возможно, в Codex. Иногда агент справляется блестяще, иногда тупит на ровном месте, иногда ломает то, что только что починил. Чаще всего причина не в том, что модель глупая, а в том, как устроена обвязка: какие инструменты ей доступны, сколько контекста она видит, проверяет ли она свою работу. Понимая это, вы сможете не просто пользоваться агентами, а управлять тем, как они работают. Писать промпты точнее, структурировать проект удобнее для агента, замечать, где проблема в модели, а где — в настройках вокруг неё.
Недавно компания LangChain провела эксперимент. Они взяли свою систему, которая не попадала даже в тридцатку лучших на публичном бенчмарке, и не стали менять модель. Вместо этого переписали обвязку — логику вызова инструментов, управление контекстом, обработку ошибок. Результат: система поднялась на пятое место. Та же модель, другая обвязка, радикально другой результат.
Это и есть главная идея статьи, которую мы сейчас разберём: модель — важная, но не главная часть агента. Главная часть — всё, что вокруг неё.
Блок первый. Мозг — как агент думает
Когда вы даёте задачу агенту, он не выполняет её одним махом. Он работает циклами. Получает задачу, думает, что нужно сделать первым шагом, делает этот шаг, смотрит на результат и решает, что делать дальше. Потом снова делает шаг, снова смотрит на результат — и так до тех пор, пока задача не будет решена или пока он не поймёт, что застрял и нужна ваша помощь.
Это похоже на то, как работает повар с незнакомым рецептом. Он не запоминает весь рецепт сразу и не готовит блюдо вслепую от начала до конца. Он читает первый шаг — «нарежьте лук» — делает его, смотрит, что получилось, читает следующий шаг и двигается дальше. Если на каком-то этапе что-то пошло не так, он возвращается и корректирует.
Разработчики называют этот цикл «Мысль — Действие — Наблюдение». Агент сначала формулирует мысль: «Мне нужно посмотреть, какие файлы есть в проекте». Потом выполняет действие — вызывает команду, которая показывает список файлов. Потом наблюдает за результатом — получает список и анализирует его. На основе этого наблюдения рождается следующая мысль: «Вижу файл bot.py, надо прочитать его, чтобы понять структуру». И цикл повторяется.
Вы могли видеть это своими глазами, если работали в Claude Code или Cursor в режиме агента. Агент не выдаёт готовый ответ мгновенно — он пишет «Thinking…», потом выполняет одно действие, показывает промежуточный результат и переходит к следующему. Каждый такой шаг — один оборот цикла.
Но чтобы этот цикл вообще мог работать, нужно перед каждым обращением к модели собрать для неё правильный контекст. Модель не помнит, что было на прошлом шаге — она каждый раз получает текст заново. Поэтому перед каждым оборотом цикла обвязка собирает «пакет» из нескольких частей: системная инструкция (кто ты, как себя вести), описания доступных инструментов (что ты умеешь делать), история предыдущих шагов (что ты уже сделал) и результат последнего действия (что получилось). Всё это склеивается в один текст и отправляется модели, а она на основании этого текста решает, что делать дальше.
Именно поэтому длинные сессии с агентом работают хуже коротких. С каждым шагом «пакет» растёт, в него добавляется всё больше истории, и в какой-то момент модель начинает терять из виду важные детали, утонувшие в потоке информации. Это не баг конкретного инструмента — это фундаментальное свойство того, как устроен цикл. Дальше мы разберём, как обвязка с этим борется.
Цикл заканчивается, когда выполняется одно из нескольких условий: агент дал финальный ответ без вызова инструментов, достиг установленного лимита шагов, исчерпал бюджет токенов или сработало ограничение безопасности. В хорошо спроектированной обвязке агент всегда имеет условие остановки, иначе он может зациклиться и выполнять бессмысленные действия бесконечно.
Блок второй. Руки — как агент действует в реальном мире
Модель умеет только одно — принимать текст и генерировать текст. Она не может открыть файл, запустить программу, зайти на сайт или выполнить команду в терминале. Всё это за неё делает обвязка, а точнее — инструменты, которые в неё встроены.
Инструменты — это, по сути, руки агента. Когда Claude Code «читает файл», происходит следующее: модель генерирует текстовую команду «прочитай файл bot.py», обвязка перехватывает эту команду, выполняет её на вашем компьютере, получает содержимое файла и передаёт его обратно модели как текст. Модель никогда не видит файл напрямую — она видит только текст, который вернул инструмент. То же самое с запуском команд в терминале, с поиском по проекту, с созданием новых файлов. Каждое взаимодействие с реальным миром проходит через инструмент.
У каждого инструмента есть описание — что он делает, какие параметры принимает, что возвращает. Модель читает эти описания и на их основе решает, какой инструмент вызвать в каждый момент. Это важный нюанс: модель не выполняет инструмент, а выбирает его. Она пишет что-то вроде «вызови инструмент read_file с параметром path=bot.py», а обвязка уже занимается исполнением.
И здесь возникает неочевидная вещь. Казалось бы, чем больше инструментов доступно агенту, тем лучше — больше возможностей, больше гибкости. На практике всё ровно наоборот. Компания Vercel при разработке своего AI-агента провела эксперимент: убрала 80% доступных инструментов, оставив только самые необходимые. Результат улучшился. Агент стал работать точнее и реже ошибался.
Причина в том, что описания всех доступных инструментов попадают в тот самый «пакет», который обвязка собирает перед каждым обращением к модели. Чем больше инструментов, тем больше текста модель должна прочитать и осмыслить, прежде чем принять решение. Это как дать человеку ящик с тремя отвёртками или ящик с двумя сотнями разных насадок — во втором случае он потратит больше времени на выбор и чаще возьмёт не ту.
Поэтому хорошая обвязка не просто даёт агенту набор инструментов, а управляет тем, какие из них доступны в каждый конкретный момент. Claude Code, например, использует ленивую подгрузку: в начале сессии агент видит только базовый набор инструментов, а остальные подключаются по мере необходимости, когда контекст задачи становится понятнее. По данным Anthropic, такой подход сокращает объём контекста на старте на 95%. Модель не тратит внимание на инструменты, которые ей прямо сейчас не нужны, и точнее работает с теми, которые нужны.
Ещё один важный момент — песочница. Когда агент выполняет команду на вашем компьютере, обвязка решает, насколько ему можно доверять. В Claude Code перед каждым потенциально опасным действием агент спрашивает разрешения. В Codex от OpenAI подход другой: агент работает в изолированной среде, где он физически не может навредить вашей основной системе, даже если захочет. Оба подхода решают одну и ту же задачу — не дать инструментам натворить бед, — но решают её по-разному. Мы подробнее вернёмся к этому в блоке про защиту.
Блок третий. Память — как агент помнит и забывает
У языковой модели нет памяти в привычном смысле. Она не помнит, что вы обсуждали пять минут назад, не помнит, какие файлы уже редактировала, и не помнит, что вы просили её «всегда писать комментарии на русском». Всё, что модель знает в каждый момент — это тот текст, который ей передали прямо сейчас. Этот текст называется контекстным окном, и у него есть жёсткий предел: определённое количество токенов, за которое модель не может выйти.
Представьте себе рабочий стол. Вы можете разложить на нём документы, заметки, распечатки — но площадь стола ограничена. Когда свободное место заканчивается, чтобы положить новый документ, приходится убирать один из старых. Контекстное окно работает точно так же. Вся история ваших запросов, все результаты вызванных инструментов, все описания доступных функций — всё это лежит на одном «столе». И чем дольше идёт сессия, тем теснее становится.
Это объясняет то, с чем вы наверняка сталкивались: в начале разговора агент работает чётко и по делу, а через полчаса начинает забывать контекст, повторять ошибки или делать то, что вы уже просили не делать. Он не «устал» и не «поглупел» — просто ранние инструкции оказались вытеснены с рабочего стола более поздней информацией.
Обвязка решает эту проблему, выстраивая вокруг модели многоуровневую систему хранения — нечто вроде перехода от одного рабочего стола к полноценному офису с архивом. На первом уровне — рабочий стол, то самое контекстное окно, куда попадает только то, что нужно прямо сейчас. На втором уровне — ящик стола: файлы проекта, Claude.md, документация, которую агент может открыть и прочитать по необходимости, но которая не занимает место на столе, пока не понадобится. На третьем уровне — архив: полная история всех действий, логи, предыдущие сессии. Агент не держит это в голове, но обвязка может достать нужный фрагмент, если потребуется.
Claude Code использует именно такой подход. Когда вы открываете новую сессию в папке проекта, агент не загружает в контекст все файлы сразу. Он читает только CLAUDE.md и структуру каталогов — легковесный «оглавление» проекта. Когда по ходу работы ему нужен конкретный файл, он подгружает его отдельным инструментом, извлекает нужную информацию и продолжает работу. Файл при этом не остаётся в контексте целиком — агент берёт из него то, что нужно, и двигается дальше. Это та самая подгрузка по запросу, благодаря которой Claude Code может работать с большими проектами, не захлёбываясь в собственном контексте.
Но даже с такой системой контекст постепенно заполняется результатами предыдущих шагов. Обвязка борется с этим несколькими способами. Первый — сжатие: вместо полного вывода длинной команды агент сохраняет в контексте только краткую выжимку. Второй — маскировка наблюдений: результаты ранних шагов, которые уже не влияют на текущую задачу, скрываются, освобождая место для свежей информации. Третий — делегирование: если задача слишком велика для одного контекстного окна, агент передаёт часть работы субагенту, у которого собственное чистое контекстное окно. Мы подробнее поговорим об этом в разделе про делегирование.
Есть ещё одна тонкость, которую обнаружили исследователи. Важные детали, оказавшиеся в середине длинного контекста, модель обрабатывает хуже, чем те, что находятся в начале или в конце. Это называют эффектом «потерянной середины»: если критически важная инструкция попала в центр большого текста, модель может её проигнорировать, причём не из-за лимита токенов, а просто потому, что внимание распределяется неравномерно. По данным исследований, производительность модели может упасть более чем на 30%, когда ключевая информация оказывается в середине контекста. Именно поэтому хорошая обвязка размещает системные инструкции в самом начале, а результат последнего действия — в самом конце, оставляя середину для менее критичной истории.
Для вас как пользователя из этого следует простая практика: если агент начал терять нить разговора, не пытайтесь «напоминать» ему всё заново в той же сессии — лучше начните новую. Чистое контекстное окно работает лучше, чем переполненное, в которое вы дописываете уточнения. А если вы хотите, чтобы агент всегда помнил какие-то правила, запишите их в CLAUDE.md — этот файл загружается в самое начало контекста каждой новой сессии и находится в той зоне, на которую модель обращает максимум внимания.
Блок четвёртый. Защита и проверка — как агент не ломает то, что уже работает
Допустим, агент получил задачу: добавить в бота новую команду. Он открыл файл, дописал код, запустил бота — и бот перестал работать вообще. Не потому что новая команда написана плохо, а потому что агент случайно задел соседнюю функцию при редактировании. Или, скажем, агент выполняет команду в терминале, которая удаляет папку, потому что неправильно понял ваш запрос.
Это не гипотетические ситуации. Модель генерирует текст вероятностно — она не «понимает» код в том смысле, в котором его понимает программист. Она может уверенно написать команду, которая выглядит правильно, но делает совсем не то. И чем больше шагов агент выполняет подряд без проверки, тем выше вероятность, что ошибка на раннем этапе превратится в катастрофу на позднем. Математика здесь простая и неприятная: если каждый отдельный шаг агент выполняет с точностью 99%, то цепочка из десяти шагов будет полностью успешной только в 90% случаев. При точности 95% на шаг — десять шагов дают меньше 60% успеха. Ошибки не просто складываются, они умножаются.
Поэтому хорошая обвязка никогда не доверяет агенту безоговорочно. Она выстраивает вокруг него несколько уровней защиты, и каждый из них решает свою задачу.
Первый уровень — контроль доступа. Агент не должен мочь сделать всё, что захочет, даже если модель решила, что это необходимо. Вы уже сталкивались с этим в Claude Code: когда агент собирается выполнить команду, которая может что-то изменить на вашем компьютере, он сначала спрашивает разрешения. Это не вежливость — это механизм обвязки, который перехватывает вызов инструмента и решает, можно ли его выполнять без подтверждения пользователя. В Codex от OpenAI подход радикальнее: агент работает внутри изолированной виртуальной среды и физически не имеет доступа к вашим файлам, даже если очень постарается. Оба варианта — это решения на уровне обвязки, а не на уровне модели. Модель в обоих случаях одинаково готова выполнить опасную команду; разница в том, позволит ли ей это сделать окружающая инфраструктура.
Второй уровень — проверка результата. После каждого действия хорошая обвязка не просто передаёт результат модели и двигается дальше, а сначала проверяет, не сломалось ли что-нибудь. Самый надёжный способ — автоматические тесты: агент внёс изменение, обвязка запустила тесты, тесты прошли — значит, можно продолжать. Тесты не прошли — агент получает сообщение об ошибке и пытается исправить. Это те самые проверки, которые в уроке про CI/CD мы настраивали через GitHub Actions. Но тесты покрывают не всё. Иногда проверить результат может только другая модель — например, обвязка отправляет сгенерированный код второй модели с вопросом «Этот код делает то, что просил пользователь?» и получает независимую оценку. Этот приём называется «модель-как-судья», и по данным исследований он может улучшить качество финального результата в два-три раза по сравнению с отсутствием проверки.
Третий уровень — возможность откатиться. Если агент всё-таки натворил дел, нужна возможность вернуться к рабочему состоянию. Это как автосохранение в игре: перед сложным боссом вы сохраняетесь, и если что-то пошло не так, загружаете сохранение и пробуете снова. В случае с агентами роль автосохранения выполняют коммиты в Git. Хорошая обвязка делает коммит перед каждым значимым изменением, чтобы в случае провала можно было откатить проект к предыдущему рабочему состоянию. Именно поэтому в наших уроках мы настраивали Git в самом начале — не потому что это модный инструмент, а потому что без него работа с агентом превращается в хождение по канату без страховки.
Все три уровня работают вместе и усиливают друг друга. Контроль доступа предотвращает грубые ошибки до их совершения. Проверка результата ловит тонкие ошибки сразу после того, как они произошли. Откат позволяет восстановиться, если первые два уровня не справились. Ни один из этих уровней не является частью модели — это целиком заслуга обвязки. И когда вы слышите, что один агент «надёжнее» другого, чаще всего это означает не то, что у него модель умнее, а то, что вокруг этой модели выстроена более продуманная система защиты.
Субагенты — как агент делегирует работу
Иногда задача слишком велика для одного агента. Не потому что модель недостаточно умна, а потому что контекстное окно не резиновое. Если агент одновременно пытается держать в голове архитектуру проекта, править код в трёх файлах, следить за результатами тестов и помнить ваши предыдущие инструкции — он неизбежно начнёт терять детали. Мы разбирали это в блоке про память: чем больше информации на рабочем столе, тем хуже модель работает с каждой отдельной частью.
Решение, к которому пришли разработчики обвязок, напоминает то, как устроена работа в любой команде. Руководитель не пытается сделать всё сам. Он разбивает большую задачу на части, передаёт каждую часть отдельному исполнителю и собирает результаты. Исполнителю не нужно знать контекст всего проекта — ему достаточно понимать свой фрагмент.
В мире агентов роль исполнителей выполняют субагенты. Это отдельные экземпляры модели, каждый со своим чистым контекстным окном. Главный агент формулирует для субагента узкую задачу — например, «найди в проекте все файлы, где используется функция send_message, и перечисли их» — и получает обратно только результат. Вся промежуточная работа субагента, все его мысли и вызовы инструментов остаются в его собственном контексте и не засоряют контекст главного агента. Это принципиально важно: главный агент получает чистый, компактный ответ вместо длинной истории действий.
Вы могли наблюдать это в Claude Code, даже не осознавая, что видите субагентов. Когда вы просите агента найти что-то в большом проекте, он иногда запускает отдельный поиск, результаты которого приходят в сжатом виде. Это и есть субагент, который получил узкую задачу, выполнил её в своём контексте и вернул только итог.
У Cursor похожий механизм работает через фоновые процессы. Когда вы работаете с кодом в редакторе, Cursor параллельно индексирует файлы, анализирует зависимости, готовит подсказки. Всё это происходит в отдельных процессах, которые не мешают основному агенту, с которым вы общаетесь в чате. Именно поэтому в уроке про VPS мы рекомендовали выделять больше оперативной памяти — эти фоновые процессы потребляют ресурсы, даже когда вы их не видите.
Подходы к делегированию у разных обвязок различаются. Некоторые создают субагентов на лету, под конкретную подзадачу, и уничтожают их после получения результата. Другие держат несколько агентов постоянно, распределяя между ними роли: один отвечает за написание кода, другой — за тестирование, третий — за ревью. Есть обвязки, которые позволяют субагентам работать параллельно, каждому в своей ветке Git, чтобы изменения одного не мешали другому.
Какой бы подход ни использовался, суть одна: делегирование решает проблему ограниченного контекста не за счёт увеличения контекстного окна, а за счёт его умного распределения. Один агент с контекстом в 200 тысяч токенов справится хуже, чем главный агент с контекстом в 50 тысяч, который делегирует части задачи трём субагентам, каждый из которых тоже имеет 50 тысяч. Общий объём доступного контекста тот же, но каждый участник работает с чистым, сфокусированным набором информации вместо одной переполненной свалки.
Для вас как пользователя из этого следует практический вывод: если агент начинает путаться в большой задаче, не пытайтесь впихнуть всё в один запрос. Разбейте задачу на части и давайте их по очереди, начиная каждую в чистом контексте. По сути, вы при этом вручную делаете то, что хорошая обвязка делает автоматически — распределяете работу между несколькими «чистыми» сессиями вместо того, чтобы тащить всё в одной переполненной.
Как это устроено у разных компаний
Всё, что мы разобрали выше — цикл мышления, инструменты, память, защита, делегирование — каждая компания собирает по-своему. Модель может быть одна и та же, но обвязка вокруг неё приводит к совершенно разному поведению агента. Это похоже на то, как один и тот же двигатель ведёт себя по-разному в легковом автомобиле и в грузовике — потому что вокруг него разная конструкция.
Мы не будем разбирать каждую реализацию в деталях, но посмотрим на три принципиально разных подхода, чтобы вы почувствовали, насколько сильно обвязка влияет на конечный результат.
Claude Code от Anthropic построен вокруг идеи минимального контекста. Агент начинает сессию почти пустым — загружает только файл CLAUDE.md и структуру папок. Всё остальное подтягивается по мере необходимости: нужен файл — агент его прочитает, нужен результат команды — выполнит и получит. Инструменты тоже подгружаются не все сразу, а по мере того, как агент понимает, что именно нужно для текущей задачи. Благодаря этому контекст в начале сессии остаётся почти свободным и заполняется только тем, что действительно относится к делу. Безопасность реализована через подтверждения: перед каждым потенциально опасным действием агент останавливается и спрашивает вашего разрешения. Субагенты создаются на лету для конкретных подзадач вроде поиска по проекту и уничтожаются после получения результата.
Codex от OpenAI исповедует противоположную философию. Каждая задача запускается в изолированной виртуальной среде — песочнице, которая содержит полную копию проекта. Агент может делать внутри этой песочницы что угодно, потому что она полностью отрезана от вашей основной системы. Даже если агент выполнит команду, которая удалит все файлы, пострадает только копия в песочнице, а ваш проект останется нетронутым. Такой подход снимает необходимость спрашивать разрешение перед каждым действием — агент работает свободнее и быстрее, но ценой того, что при запуске ему нужно скопировать проект целиком, что занимает время и ресурсы.
LangGraph — это не готовый агент, а конструктор, из которого разработчики собирают собственную обвязку. Если Claude Code и Codex — это автомобили, которые вы покупаете готовыми и ездите, то LangGraph — это набор деталей, из которых можно собрать именно тот автомобиль, который вам нужен. Хотите агента, который всегда согласовывает план с пользователем перед выполнением — можно настроить. Хотите трёх агентов, работающих параллельно, каждый со своей ролью — тоже можно. Именно команда LangGraph продемонстрировала тот самый скачок с позиции за пределами тридцатки до пятого места в бенчмарке, просто пересобрав обвязку вокруг той же модели. Но гибкость имеет цену: чтобы пользоваться LangGraph, нужно быть разработчиком и понимать, что именно вы собираете.
Эти три подхода иллюстрируют спектр, на котором существуют все агентские системы. На одном конце — максимальный контроль и минимальное потребление контекста, как у Claude Code. На другом — максимальная свобода агента в изолированной среде, как у Codex. Посередине — конструкторы вроде LangGraph, где разработчик сам выбирает баланс. Ни один из подходов не является объективно лучшим — каждый оптимален для своих задач. Claude Code хорош для работы с существующими проектами, где важно не навредить. Codex удобен для изолированных задач, где агенту нужна полная свобода действий. LangGraph подходит тем, кто строит что-то уникальное и готов инвестировать время в настройку.
Понимание этих различий помогает не только выбрать инструмент, но и правильно с ним работать. Если вы знаете, что Claude Code экономит контекст, вы будете писать CLAUDE.md компактнее и разбивать задачи на части. Если вы знаете, что Codex работает в песочнице, вы не будете удивляться, что он не видит изменения, которые вы только что внесли вне его среды. Обвязка определяет правила игры, и чем лучше вы их понимаете, тем эффективнее играете.
Что это значит для вас
Всё, что мы разобрали выше, может показаться теоретическим — циклы, контексты, субагенты. Но из этой теории вырастают очень конкретные вещи, которые вы можете сделать прямо сейчас, чтобы ваши агенты работали лучше.
Первое и самое важное — держите CLAUDE.md компактным. Этот файл загружается в самое начало контекста каждой новой сессии. Всё, что в нём написано, модель прочитает с максимальным вниманием, потому что начало контекста — зона наибольшего фокуса. Но если вы превратите CLAUDE.md в огромный документ со всеми правилами, всеми описаниями и полной историей решений, он сам начнёт вытеснять полезное пространство. Пишите в него только то, что агент должен помнить в каждой сессии без исключения: структуру проекта, ключевые правила, способ подключения к серверу. Всё остальное лучше разнести по отдельным файлам, до которых агент доберётся сам, когда ему понадобится.
Второе — разбивайте проект на модули. Мы говорили об этом в уроке про архитектуру файлов, но теперь вы понимаете, почему это важно не только для порядка, а для самой механики работы агента. Когда проект состоит из одного большого файла, агент вынужден загружать его целиком каждый раз, даже если меняет одну строку. Когда проект разбит на модули, агент подгружает только тот файл, который ему нужен, и контекст остаётся свободным для самой работы. Это та самая подгрузка по запросу, которую мы разбирали в блоке про память, только инициируете её вы — своей архитектурой проекта.
Третье — не бойтесь начинать новые сессии. Интуитивно кажется, что длинная сессия лучше, потому что агент «уже в курсе» и не нужно объяснять заново. На практике всё наоборот. Длинная сессия — это переполненный рабочий стол, на котором важные инструкции тонут среди результатов старых команд. Новая сессия — это чистый стол, на котором агент снова видит CLAUDE.md в полном фокусе и работает с вашей задачей без балласта. Если задача большая, разбейте её на части и выполняйте каждую в отдельной сессии. Результаты предыдущей части уже сохранены в файлах проекта, и агент найдёт их, когда они понадобятся.
Четвёртое — формулируйте задачи так, чтобы агенту было проще их проверить. Запрос «сделай красиво» агент не сможет проверить никак — у него нет критерия, по которому можно отличить «красиво» от «некрасиво». Запрос «добавь кнопку, которая при нажатии отправляет сообщение, и убедись, что бот на неё отвечает» агент может проверить сам, запустив бота и нажав кнопку. Чем конкретнее задача, тем эффективнее работает цикл «мысль — действие — наблюдение», потому что у агента появляется понятное условие завершения: он знает, когда задача решена.
Пятое — если агент начал делать ерунду, остановитесь и подумайте, в чём проблема — в модели или в обвязке. Если агент не видит нужный файл, это скорее всего вопрос архитектуры проекта и настройки инструментов, а не интеллекта модели. Если агент забывает ваши инструкции, это вопрос контекста, а не его «памяти». Если агент ломает рабочий код, это вопрос отсутствия тестов и проверок, а не его злого умысла. Почти всегда, когда кажется, что «модель тупая», проблема лежит в обвязке — и это хорошая новость, потому что обвязку вы можете менять, а модель нет.
Все эти рекомендации сводятся к одной мысли. Вы не просто пользователь, который пишет запросы и ждёт результата. Вы — часть обвязки. Ваш CLAUDE.md, ваша архитектура проекта, ваш способ формулировать задачи, ваше решение начать новую сессию — всё это компоненты системы, которая окружает модель. И чем осознаннее вы эти компоненты настраиваете, тем лучше работает весь агент целиком.