Контекст - это не топливо, которого чем больше, тем лучше. Через упоминания можно прикрепить файлы и папки, вывод терминала, git diff, прошлые чаты и состояние браузера; открытые файлы и выделение тоже могут попасть в запрос. Внимание модели - конечный ресурс, и он делится между всем приложенным: каждый лишний блок конкурирует за окно контекста и смещает фокус. Поэтому набор контекста - это решение, а не рефлекс.
Наивная тактика понятна: приложить побольше, чтобы агент точно всё видел. Она даёт обратный эффект. Половина приложенного оказывается нерелевантной, модель тратит внимание на неё, а нужная деталь тонет среди похожих. Хуже всего работают почти одинаковые файлы: два варианта одного модуля рядом заставляют выбирать наугад. К этому добавляется прямая стоимость - большой контекст дороже и медленнее, а на длинной сессии он ещё и вытесняет то, что действительно понадобится дальше.
Правильная модель - контекст как набор доказательств. В него входит ровно то, что нужно для решения: наблюдаемый сбой, релевантный контракт, текущая реализация и проверяемый ожидаемый результат. Четыре элемента, и каждый отвечает на свой вопрос: что сломано, как должно быть по договорённости, как написано сейчас и по чему мы поймём, что готово. Всё остальное - шум, который дорого стоит и мешает. Если вы не можете объяснить, зачем в запросе конкретный файл, скорее всего, его там быть не должно.
Полезно один раз свести виды контекста в таблицу: когда прикреплять и чем рискуете. Ниже такая карта - от файла и папки до вывода терминала, git diff, прошлого чата и браузера. У каждого источника свой характерный риск, и знать его полезнее, чем помнить синтаксис упоминания: устаревшая копия вместо канонического источника, слишком большой нерелевантный объём, секреты в выводе терминала, старые предположения из прошлого разговора.
| Контекст | Когда прикреплять | Риск |
|---|---|---|
| Файл | Есть конкретная реализация или контракт | Устаревшая копия вместо канонического источника |
| Папка | Нужно увидеть локальную архитектуру | Слишком большой нерелевантный объём |
| Терминал | Ошибка, стек вызовов, результат теста |
| Секреты и шум в выводе |
| Git diff | Обзор или объяснение изменения | Пропуск неотслеживаемых и сгенерированных файлов |
|---|
| Прошлый чат | Нужно продолжить принятое решение | Старые предположения тянутся дальше |
|---|
| Браузер | Проверка состояния интерфейса | Сессии и чувствительные данные страницы |
|---|
Два источника заслуживают отдельной осторожности. Вывод терминала часто содержит переменные окружения, токены и внутренние адреса - прикладывая его целиком, вы отдаёте это модели и в транскрипт. Браузерный контекст несёт состояние сессии: открытая страница может быть авторизованной, и вместе с разметкой в запрос попадёт то, что вы не собирались показывать. В обоих случаях безопаснее приложить фрагмент, а не всё: для разбора ошибки нужен стек и сообщение, а не вся история вывода.
Для масштабного поиска есть более дешёвый путь, чем прикладывать полрепозитория. Отдельный исследовательский субагент работает в своём окне контекста и возвращает сводку, не засоряя основной разговор сырыми результатами. А точный символ или строку ошибки агент и так находит быстрым поиском по репозиторию. Это разделение труда: широкий обзор - отдельному контексту, точное попадание - поиску, а в основной разговор попадает уже вывод.
Минимальный набор не значит скудный. Если из доказательств выпадает канонический источник - интерфейс, схема, контракт, - агент не остановится, а восстановит его по косвенным признакам и напишет код под собственную реконструкцию. Признак этой ошибки узнаваем: в diff появляется заново придуманное имя поля, свой формат ошибки или дубль уже существующей функции. Лечится это не увеличением объёма, а заменой: вместо десяти соседних файлов приложить один правильный.
Кроме упоминаний есть ещё два канала ввода. Изображение можно перетащить в поле ввода или вставить из буфера - так в запрос попадает макет, снимок интерфейса или экран с ошибкой, который иначе пришлось бы переписывать руками. Запрос можно надиктовать голосом, нажав микрофон в том же поле; расшифровку стоит перечитать до отправки, потому что имена файлов и функций она разбирает хуже всего. Оба канала расходуют то же окно, что и файлы. Сколько его занято, показывает кольцо рядом с полем ввода, а по клику открывается разбор по категориям. Когда окно близко к заполнению, старая часть разговора сжимается в сводку: место освобождается, но подробности прежних шагов остаются только в пересказе.
Отдельная статья расхода - длина разговора. Контекст накапливается сам: каждый ответ, каждый приложенный фрагмент и каждая отвергнутая гипотеза остаются в истории и продолжают влиять на следующий шаг. К середине большой задачи заметная часть окна занята тем, что уже неверно, и агент честно опирается на это наравне со свежим. Дешевле открыть новый разговор и собрать доказательства заново, чем объяснять, какие из прежних выводов больше не действуют.
Инженерный вывод короткий: прикрепляйте минимальный набор, достаточный для решения. Такой набор проще собрать, чем кажется, если задавать себе один вопрос: что именно докажет, что задача решена. Ответ на него почти всегда называет два-три конкретных источника - и это и есть нужный контекст.
Типичные провалы работы с контекстом предсказуемы. Приложить весь репозиторий на всякий случай и получить размытое внимание и лишний счёт. Прикрепить устаревшую копию файла вместо канонического источника. Отдать в запрос вывод терминала с секретами. И продолжать длинный разговор со старыми предположениями вместо нового с чистым набором доказательств.