Як працюють AI-агенти

Контекст як обмежений ресурс

У главі 23 ми розглянули агента для розробки на основі штучного інтелекту (AI coding agent; AI — Artificial Intelligence) як систему з моделі,…

Глава 24Заморожене українське видання

У главі 23 ми розглянули агента для розробки на основі штучного інтелекту (AI coding agent; AI — Artificial Intelligence) як систему з моделі, застосунку, інструментів і середовища виконання. Ця глава зосереджується на тому, що система фактично передає моделі для чергового кроку. Це контекст: не весь репозиторій і не вся історія за визначенням, а підібраний набір інструкцій, повідомлень, результатів інструментів і даних, доступних моделі зараз.

Контекст обмежений не лише тим, скільки даних технічно можна подати. Якщо до запиту додати все підряд, важливе правило може загубитися серед повторів, застарілих рішень і великих виводів. Потрібно керувати і місткістю, і релевантністю: передавати достатньо відомостей, щоб виконати поточний крок, зберігати точні джерела для рішень і не приписувати моделі знання про те, чого вона не отримала.

Продуктові твердження нижче звірено з офіційними сторінками Anthropic та OpenAI 23–26 вересня 2026 року. Документація постачальників може змінитися; де сторінка не показує дати випуску чи номера версії, це позначено в джерелах. У прикладах усі назви файлів, версії правил, записи, команди й стани вигадані. Жоден із прикладів не описує реальне середовище або виконаний запуск.

24.1. Що означає «контекст» — і де проходить його межа

Контекстний бюджет — робоче місце одного запиту до моделі. Його зазвичай вимірюють токенами, але це не дорівнює кількості слів, рядків коду, файлів чи сторінок. Контекстне вікно задає, скільки токенізованого вмісту модель може врахувати за конкретного запуску. Його точний обсяг та правила обліку залежать від моделі, API (Application Programming Interface — програмного інтерфейсу застосунку), типу даних і продукту.

Токен — частина тексту, на яку його розбиває токенізатор моделі. Токен може збігатися зі словом, складом, розділовим знаком або фрагментом. Код, українська мова, таблиці, JSON (JavaScript Object Notation — текстовий формат структурованих даних), зображення та документи витрачають бюджет за правилами конкретної системи; за довжиною файла в байтах не можна точно визначити кількість токенів.

У запиті є принаймні два різні обмеження:

Бюджет контексту — скільки вхідних даних, попередніх повідомлень і згенерованого продовження може вмістити поточний обмін із моделлю. У частині моделей до нього входять також внутрішні токени міркування або вміст інструментів.
Бюджет відповіді — скільки токенів модель може згенерувати за один виклик. Він може бути меншим за весь контекстний бюджет. Якщо його вичерпано, відповідь може обірватися, навіть якщо ще залишався простір у контексті.

Тому «вікно на N токенів» не означає, що всі N можна витратити на файли: частину займають системні й розробницькі інструкції, доступні інструменти, історія та результати попередніх викликів; частину може знадобитися залишити для відповіді або наступного кроку. API іноді має також окремі ліміти розміру запиту, зображень чи документів. Оплата, затримка та контекстна місткість — пов’язані, але не тотожні речі.

Точні ліміти моделей і конкретних продуктів змінюються. Тут навмисно немає постійної таблиці чисел або правила на кшталт «не перевищуйте стільки-то слів»: для фактичного запуску звіряйте живу документацію обраної моделі й API на ту саму дату. Практично важливе питання для кожного кроку не «скільки всього можна вставити взагалі?», а «які дані має побачити модель, щоб відповісти на це запитання, і який обсяг відповіді їй потрібен?»

Що витрачає контекст

Залежно від продукту й налаштувань, у поточному запиті можуть бути:

системні, організаційні й розробницькі інструкції, назви та описи інструментів і їхні схеми;
нове повідомлення користувача й попередні повідомлення, якщо клієнт передав історію або продовжив її через ідентифікатор сеансу;
вміст, прочитаний із файлів, вебсторінок, документів чи бази даних, а також уривки, які повернув пошук;
результат інструмента: наприклад, вивід оболонки, список файлів, текст помилки або повідомлення API;
вміст, згенерований моделлю. Для деяких моделей і викликів у бюджет також входять токени міркування або результати викликів інструментів.

Якщо цикл агентної роботи багаторазово передає всю історію, довгі інструментальні виводи можуть повторно споживати бюджет у кожному наступному запиті. Деякі продукти зберігають частину стану на сервері або очищують старі результати; це не означає, що контекст можна вважати необмеженим чи що кожен клієнт працює однаково. Для прикладу, документація OpenAI описує контекстне вікно як суму вхідних і вихідних токенів та, для певних моделей, токенів міркування; документація Anthropic також перелічує системну інструкцію, повідомлення, інструменти, зображення, документи й згенероване продовження. Це приклади двох API, а не універсальна таблиця обліку для кожного продукту.

Файл у робочому каталозі — ще не прочитаний файл. Модель може не бачити файл, доки застосунок або інструмент не передасть його в запит. Навіть наявність назви в дереві файлів доводить лише, що систему поінформовано про шлях; для висновків про вміст потрібен прочитаний текст або інший фактичний результат. І навпаки, середовище може автоматично завантажити частину інструкцій чи проіндексувати документи. Отже, що саме було надано, залежить від продукту та дій його оболонки — треба перевірити журнал читання, інтерфейс чи інший доступний доказ.

Сам факт виклику читання теж не гарантує, що весь файл потрапив у модель: інструмент міг повернути лише діапазон рядків, уривок за пошуком, усічений результат або підсумок. Для важливої вимоги фіксуйте, яку саме версію й частину джерела прочитано. Перелік файлів і перелік прочитаного — різні записи.

24.2. Чому довший контекст не гарантує кращої відповіді

Технічна можливість передати довгу послідовність і здатність однаково точно використати всі її частини — різні речі. Первинне дослідження Nelson Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni та Percy Liang, «Lost in the Middle: How Language Models Use Long Contexts», перевіряло саме залежність результату від позиції потрібної інформації у вході.

Автори дослідили дві задачі:

Запитання за кількома документами. Для 2 655 запитань із NaturalQuestions-Open збирали фрагмент Вікіпедії з відповіддю та документи-відволікачі. Фрагменти обмежували розміром до 100 токенів; відволікачі обирали пошуком Contriever. У контрольованому порівнянні змінювали загальну кількість документів (10, 20 або 30) і переставляли той, що містив відповідь, ближче до початку, середини чи кінця; далі оцінювали точність відповіді. Модель мала не просто знайти фрагмент, а використати його для відповіді.
Синтетичне знаходження пари «ключ — значення». Модель отримувала JSON-об’єкт із випадковими унікальними парами та запит про значення конкретного ключа. Автори змінювали довжину об’єкта й позицію потрібної пари. Це простіша перевірка пошуку точного значення, а не складного читання природного тексту.

Серед випробуваних моделей були MPT (Mosaic Pretrained Transformers — родина попередньо навчених трансформерів MosaicML), зокрема MPT-30B-Instruct; LongChat-13B із контекстом 16 тисяч токенів; GPT-3.5-Turbo (GPT — Generative Pre-trained Transformer, генеративний попередньо навчений трансформер) та його варіант із розширеним контекстом, а також Claude-1.3 і Claude-1.3 із розширеним контекстом. Це назви моделей того періоду, а не рекомендації щодо сучасного вибору. Для запитань за документами автори побачили характерну залежність: результат часто був кращим, коли документ із відповіддю стояв на початку або наприкінці, і гіршим, коли він опинявся посередині. У прикладі GPT-3.5-Turbo на середніх позиціях точність у деяких наборах із 20 або 30 документів падала нижче його закритого режиму — відповіді без документів, де показник становив 56,1 відсотка. Сам факт більшого контексту не давав стабільної переваги розширеному варіанту моделі на завданнях, які вміщалися в обох варіантах.

У завданні з випадковими ключами й значеннями частина моделей знаходила значення без помилок у перевірених умовах; інші також гірше впоралися, коли потрібна пара була посередині. Це уточнює висновок: ефект не зводився до однієї загальної нездатності знаходити точний текст; результат залежав від моделі, задачі та її складності.

Окремий експеримент із пошуком документів для відкритих запитань показав, що додавання нових фрагментів не завжди приносило пропорційно більше користі. У цих конкретних умовах перехід від 20 до 50 знайдених документів дав лише незначне поліпшення — близько 1,5 відсотка для GPT-3.5-Turbo і близько 1 відсотка для Claude-1.3. Це результат конкретного набору даних та способу пошуку, а не оцінка всіх систем пошуку.

Межі дослідження. Це контрольовані експерименти на визначених наборах запитань і моделях 2023 року, опубліковані в лютому 2024 року в журналі Transactions of the Association for Computational Linguistics — «Транзакції Асоціації обчислювальної лінгвістики» (TACL). У роботі використовували, зокрема, жадібне декодування; автори прямо залишили інші способи декодування для майбутньої роботи. Документи-відволікачі, англомовна Вікіпедія, оцінювання за відповідністю відповіді й точне розташування одного фрагмента не відтворюють усі реальні завдання програмування, нові моделі, різні мови, інструменти чи способи індексації. Результат не доводить, що кожна модель завжди має «мертву зону» посередині, і не вимірює кожну сучасну систему.

Практичний висновок вужчий: розмір контекстного вікна сам собою не доводить, що модель надійно використає кожен переданий факт. Для важливого рішення подавайте релевантні фрагменти, ставте точне запитання, посилайтеся на джерело, а відповідь звіряйте з ним. Не перетворюйте висновки статті на універсальний закон про всі моделі.

24.3. Context rot і context pollution: корисні назви, але різний статус доказів

Context rot («деградація контексту») — термін, який використовують для зниження здатності моделі точно працювати з інформацією в міру збільшення вхідного контексту. В інженерному матеріалі Anthropic це описано як тенденцію з неоднаковою виразністю між моделями, а не як одну формулу чи спільну для всіх систем межу. Робота Lost in the Middle дає виміряні результати на окремих контрольованих задачах: позиція факту впливала на точність для перевірених моделей. Ці конкретні результати — емпіричне свідчення; сама назва «context rot» не є окремим стандартним тестом із єдиним порогом.

Context pollution («засмічення контексту») — інженерний опис ситуації, коли активний запит заповнений непотрібними, застарілими, дубльованими, оманливими або конфліктними відомостями. Такі дані ускладнюють пошук авторитетного правила та можуть відволікати від завдання. Це корисне робоче поняття, але не стандартизована величина, яку можна просто виміряти універсальним числом. Не кожен зайвий токен спричинить помилку; і не кожна помилка є наслідком забруднення — причиною можуть бути модель, невдале формулювання, помилкова дія інструмента або хибне джерело.

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

24.4. Відкривайте джерела поступово

Корисна послідовність — від карти до точного фрагмента, а не відразу передавати все, що можна знайти:

Визначте конкретний результат і критерій. Наприклад, «змінити текст відповіді для простроченого токена, зберігши код відповіді й публічний контракт».
Огляньте карту проєкту. Дізнайтеся робочий каталог, гілку, стан файлів, верхні теки й наявні інструкції. Сам огляд переліку ще не є читанням кожного файла.
Знайдіть імовірні місця. Пошук за назвою символу, текстом помилки, маршрутом, типом даних або критерієм може виділити файли-джерела, виклики, тести й конфігурацію.
Прочитайте потрібний фрагмент у повному достатньому контексті. Перевірте оголошення, гілки умов, обробників викликів і тестові приклади; якщо фрагмента замало, відкрийте суміжне місце.
Розширюйте коло, коли виявилася залежність. За потреби прочитайте контракт API, схему даних, міграцію, суміжний модуль або інструкцію для відповідної теки.
Занотуйте, що було фактично перевірено. Укажіть шлях, версію чи ревізію та конкретний результат; не пишіть «перевірено весь репозиторій», якщо було прочитано лише кілька файлів.

Такий підхід називають поступовим розкриттям: агент отримує загальний орієнтир, потім сам або за командою завантажує потрібні подробиці. Його перевага не в гарантованому зменшенні числа помилок, а в тому, що до контексту можна додавати джерела за зв’язком із завданням і зупинитися, коли є достатня основа для наступної перевірюваної дії.

Пошук і RAG — це способи вибору, а не обов’язкове обладнання

RAG — скорочення від Retrieval-Augmented Generation, тобто «генерація з доповненням пошуком»: система знаходить фрагменти в зовнішньому корпусі та додає їх до запиту моделі. Це опис схеми, а не вимога використовувати певне сховище.

Пошук можна виконати звичайним пошуком тексту в репозиторії, навігацією за файлами, запитом до бази, пошуком документації чи окремим індексом. Векторна база даних — один із можливих варіантів для семантичного пошуку за векторними представленнями тексту. Вона може допомогти в масштабному корпусі, але не є передумовою кожної RAG-системи й не потрібна для кожної задачі програмування. Для одного методу в невеликому проєкті точний пошук і читання його викликів можуть бути простішими. Для дуже широкого корпусу можуть знадобитися індексація, фільтри доступу, метадані й оновлення індексу.

Пошуковий результат теж треба перевіряти. Семантичний пошук може не знайти точний ідентифікатор; пошук за словами може пропустити синонім; старий індекс може вказати на попередню версію; фрагмент без заголовка може втратити значення. Для рішення, що спирається на знайдений документ, поверніть до контексту назву джерела, його дату або ревізію та достатній уривок навколо твердження. Пошук підказує, що прочитати далі; він не встановлює автоматично, що знахідка є чинним правилом.

Увесь репозиторій чи цільові файли

Читати багато або всі файли виправдано, якщо це й справді відповідає питанню: наприклад, команда проводить задокументовану інвентаризацію всіх місць використання застарілого API, а критерій вимагає повного покриття. Тоді агент має визначити межі пошуку, знайти всі можливі входження, перейти за непрямими залежностями й зафіксувати, як перевіряв повноту.

Цільове читання доречне, якщо питання вузьке й місце зміни відоме або його можна знайти. Спершу перевірте інструкції та стан репозиторію, потім прочитайте вхідну вимогу й код, його виклики, відповідні тести та контракти. Якщо пошук виявив новий зв’язок, розширте область. Якщо ні — немає причини засипати модель незалежними файлами. В обох підходах не заявляйте про повноту, яку фактично не перевіряли. Жодне універсальне співвідношення між числом прочитаних файлів і якістю не встановлено в цій главі.

24.5. Підсумок, компактація й збереження доказів

Коли розмова або агентна робота стає довгою, продукт може компактувати контекст: зберегти коротший підсумок важливих відомостей і прибрати частину попередньої історії з активного запиту. Це допомагає продовжити роботу, але підсумок є перетворенням, а не точним архівом. Можна втратити точне формулювання, негативний приклад, походження рішення, невирішене питання чи важливу заборону. Інший продукт може видаляти вибрані старі результати, не створюючи підсумку; це не та сама операція.

За офіційною документацією, Messages API Anthropic на дату перевірки описував серверну компактацію як функцію бета-версії, яка створює підсумковий блок і продовжує роботу на його основі. OpenAI описує серверну та окремо викликану компактацію в Responses API; повернений елемент компактації є непрозорим і не призначеним для читання людиною. Це різні реалізації в API; вони не доводять, що кожен клієнтський продукт компактує однаково або що користувач бачить кожен втрачений фрагмент.

Щоб підсумок залишався корисним і перевірюваним, у ньому варто передавати не лише враження агента, а структуровані відомості:

ціль і приймальні критерії — яке спостережуване завершення потрібне;
робочу ревізію — репозиторій, гілку або коміт, незбережені зміни, які не можна загубити;
джерела рішення — назви файлів, версії, посилання чи ідентифікатори комітів, важливі уривки або точні твердження з посиланням на них;
статус кожного твердження — підтверджений факт, гіпотеза або невідоме; рішення разом із причиною й джерелом;
зроблене й перевірене — змінені шляхи, запуски й отримані результати, що саме ними доведено;
відкрите й заборонене — невирішені питання, відкладені ризики, побічні дії, яких не виконували і не можна виконувати без конкретної умови;
найближчий крок — одне наступне завдання, його вхідні дані й умова зупинки.

Якщо факт важливий для приймання, безпеки, даних чи зовнішнього зобов’язання, у підсумку залиште посилання на першоджерело або на файл стану. Сам підсумок не має стати новим авторитетним правилом лише тому, що він коротший і зручніший. Новий сеанс або наступний крок після компактації має повторно прочитати вирішальні джерела та перевірити поточну ревізію перед дією.

Підсумок не слід робити максимально довгим «на всяк випадок». Його призначення — зберегти стан і маршрути до доказів, а не копіювати всі повідомлення, які вже є у файлах чи історії. Компактація допомагає керувати активним контекстом; вона не є резервною копією, транзакційним журналом, погодженням або гарантією точного збереження всіх інструкцій.

24.6. Пам’ять, кешування запиту й тривалий стан — три різні речі

Слово «пам’ять» може позначати кілька механізмів. Перед використанням з’ясуйте, що саме записується, хто це завантажує, у яких сеансах воно доступне і чи можна перевірити актуальність.

Механізм	Що зберігає	Чого він сам по собі не гарантує
Активний контекст	Те, що застосунок передав моделі для поточного запиту: інструкції, повідомлення та вибраний вміст.	Збереження між запитами або наявність будь-якого іншого файла чи повідомлення.
Пам’ять продукту чи агента	Відібрані нотатки, вподобання або минулий досвід у профілі, файлі пам’яті чи окремому інструменті.	Що кожна нотатка актуальна, завантажена для кожного запиту або має пріоритет над новою вимогою.
Кешування префікса запиту	Повторно використані внутрішні стани моделі для незмінного префікса, щоб не обчислювати цей самий початок знову.	Семантичну пам’ять, нові знання, збереження завдання або вищу точність відповіді. Кешовані токени зазвичай усе одно належать до контексту запиту.
Тривалий стан у файлі чи сервісі	Факти, які свідомо зберегли в коміті, файлі прогресу, системі контролю версій, базі чи іншому сервісі.	Що модель уже прочитала цей стан, що він не застарів або що її дія відповідає дозволу.

Anthropic описує пам’ять Claude Code як контекст, а не примусову конфігурацію: інструкційний файл може бути завантаженим, але не дорівнює технічному блокуванню команди. Сторінка про інструмент пам’яті для API показує інший механізм: модель запитує операцію, а застосунок виконує читання чи запис у сховище, яке контролює розробник. Це приклади конкретних продуктів, а не твердження, що всі агенти мають пам’ять за замовчуванням.

Кешування також не слід плутати з пам’яттю. Документація OpenAI пояснює кеш промпту як збережені проміжні стани для повторного використання однакового початкового префікса; документація Anthropic описує кешування префіксів запиту з контрольними точками. Зміна вмісту до точки кешування може зламати повторне використання або вимагати нового запису. Це оптимізація швидкодії чи вартості для деяких запитів, а не сховище фактів або журнал аудиту. Не варто переносити деталі чи строки зберігання кешу одного постачальника на іншого.

Найкраще місце для тривалого правила залежить від призначення. Версійований документ може бути джерелом політики; запис у системі контролю версій фіксує стан коду; база даних зберігає бізнес-факт; конфігурація або контроль середовища може фізично заборонити небезпечну дію. Нотатка пам’яті допомагає відновити орієнтир, але має вести до джерела, де можна перевірити, що правило чинне.

24.7. Який контекст передавати на конкретну задачу

Корисний початковий контекст — це короткий робочий бриф, а не стенограма всього попереднього листування. Його можна побудувати в такому порядку:

Мета та результат. Що має змінитися або бути з’ясовано?
Приймальні критерії. Які видимі умови покажуть, що результат правильний? Різницю між критерієм, тестом і доказом ми розглядали в главі 22.
Область і виключення. Які частини продукту входять у роботу, що не можна змінювати або запускати?
Авторитетні джерела й ревізії. Який файл, документ або запис керує рішенням? На якій гілці чи коміті виконується робота?
Поточний стан і факти. Що вже зроблено, що прочитано, які перевірки завершено й із якими фактичними результатами?
Рішення та невідомі. Що вже вирішено, на підставі чого, які припущення лишилися неперевіреними й що потребує уточнення людини?
Наступний крок і межі. Яка наступна дія безпечна? Яка передумова має бути виконана, щоб перейти до запису або зовнішнього побічного ефекту?
Шлях до деталей. Де прочитати первинні файли, тести, журнал чи запис прогресу, якщо стислих фактів недостатньо?

Під час роботи до брифу додаються тільки деталі, потрібні для наступної дії. Якщо агент повинен змінити один адаптер, він не потребує копії всіх попередніх дослідницьких кроків; йому потрібні вимога, контракт адаптера, релевантні виклики й тести. Якщо агент перевіряє спільну політику, йому потрібні джерело політики, її сфера дії, версія та суперечливі свідчення.

Не завантажуйте всю історію автоматично тільки тому, що вона існує. У ній можуть бути повторені результати, застарілі домовленості, інструкції з іншої задачі або вивід інструмента без актуального значення. Включайте конкретне старе повідомлення лише тоді, коли його формулювання саме є доказом чи вимогою; позначте дату та походження, а не подавайте його як поточне правило.

Короткий бриф не повинен приховувати невизначеність. «Потрібно дізнатися, чи діє виняток для старих замовлень; у документах відповіді немає» краще за висновок, який підсумок вивів без джерела. Формулювання «не перевірено» — корисний стан роботи, а не недолік, який треба замаскувати.

24.8. Окремий контекст для рецензента й субагента

У главі 20 ми розглядали спільного рецензента й граф залежностей, а в главі 23 — різні межі агента. Тут важливий принцип контексту: інший агент корисний, якщо отримує достатньо матеріалу для самостійного завдання, але не мусить повторно нести вміст усіх досліджень виконавця.

Для рецензії передайте:

критерії приймання та джерело, з якого вони походять;
потрібний diff (показ різниці між версіями файлів) або змінену ревізію, список файлів і точні області зміни;
відповідні контракти, рішення з архітектури чи політики, які впливають на зміну;
що реально перевіряли, які результати отримали та що не перевірено;
конкретні запитання для рецензії: наприклад, пропущені виклики, поведінка при повторі, сумісність зі старими даними, невідповідність тестів вимозі.

Не передавайте лише фразу автора «все готово» або його самоперевірку. Дайте рецензенту змогу прочитати diff і звернутися до джерела. Водночас не приховуйте від нього важливий виняток, щоб перевірка не стала навмисно сліпою. Відокремлений контекст означає, що в ньому немає зайвих міркувань автора; він не означає відсутність критеріїв, інструкцій чи доказів.

Рецензент із чистішим контекстом може помітити, що виконавець уже звик до невдалої конструкції або прийняв припущення без доказу. Проте це не гарантує незалежного висновку. Обидва агенти можуть успадкувати ту саму двозначну вимогу, прочитати той самий застарілий документ, пропустити той самий файл або мати подібну модельну схильність. Якщо рецензент отримав тільки стислий переказ, він не перевіряє приховані в ньому факти. Найкращий контекст для огляду веде до первинних джерел і має ясні питання, а не нескінченну історію.

Для субагента з вузькою роботою передайте окрему мету, доступну область, актуальні інструкції, очікуваний формат звіту й межу дозволених дій. Попросіть повернути використані джерела, точні файли чи пошукові запити, знайдені факти та невідомі. Перед інтеграцією координатор сам звіряє висновки з актуальними файлами та ревізією. Короткий звіт субагента — це результат пошуку, а не автоматично перевірене рішення.

24.9. Як з’ясувати, чому інструкцію пропущено

Якщо агент не виконав інструкцію, діагноз «забув через довгий контекст» може бути лише припущенням. Спершу перевірте чотири запитання:

Інструкцію було завантажено? Чи передав застосунок файл або повідомлення моделі? Чи є запис читання, підтвердження інструкцій у поточному сеансі або інший доказ? Сам факт наявності файла у сховищі нічого не доводить. Перевірте, чи не відсік інструкцію пошук, конфігурація продукту, вимкнений файл, каталог або обмеження розміру.
Інструкція була чинною для цієї дії? Звірте дату, гілку, ревізію, область застосування, замінені редакції та послідовність нових повідомлень. Стара нотатка може точно переказувати правило, яке більше не діє.
Інструкцію було сформульовано зрозуміло? Чи названі об’єкт, дія, умова, виняток і потрібний результат? «Обережно працюй із міграціями» не визначає, чи можна запустити команду; «не підключайся до бази й не застосовуй цю міграцію без окремого дозволу власника» значно конкретніше.
Вона належала до поточного обсягу? Можливо, вимога стосується лише певного каталогу, середовища, етапу чи ролі, а поточне завдання — інше. Порівняйте умову з реальною дією, а не лише з назвою файла.

Після цього розгляньте наступне: якщо правильна інструкція була передана, чинна, зрозуміла й стосувалася дії, перевірте, чи не загубилася вона в суперечливому контексті, чи не була обрізана компактацією, чи не згенерував агент план, який їй суперечить, і чи не виконав інструмент команду попри текстову заборону. Зберіть видимі докази запиту та інструментального виконання, якщо їх доступно. Не робіть висновку про внутрішній механізм моделі лише з фінальної помилки.

Виправлення залежить від межі збою: додати інструкцію в місце, яке гарантовано завантажується; позначити джерело й дату; переписати суперечливий бриф; звузити запит; зберегти посилання в передаванні; або перенести критичний контроль із тексту в дозвіл інструмента, перевірку чи процедуру середовища. Інструкція впливає на поведінку моделі; сам текстовий наказ не є технічним блокуванням. Документація Claude Code окремо попереджає, що файл інструкцій не є примусово виконуваною конфігурацією, і описує перевірку того, які файли пам’яті потрапили в сеанс. Це особливість документації того продукту, але загальний спосіб діагностики корисний і для інших систем.

24.10. Продовжити поточну розмову, відкрити нову чи передати роботу

Продовжуйте в тому самому сеансі, коли наступний крок безпосередньо спирається на недавні факти, контекст ще чіткий, а історія містить перевірені джерела. Наприклад, після читання функції й її тесту можна попросити змінити умову та показати diff. Але перед записом чи зовнішньою дією звірте поточну ревізію і потрібну інструкцію, особливо коли змінилася гілка, середовище або обсяг роботи.

Почніть новий сеанс, коли переходите до незалежної задачі, в історії накопичилося багато неактуальних чи конфліктних результатів, потрібен окремий огляд або попередню роботу краще скинути до короткого стану. Новий сеанс не означає автоматично нову робочу копію чи чистий стан репозиторію: перевірте, в якому каталозі, гілці та середовищі він працює, які інструкції підвантажилися й чи доступні ті самі інструменти.

Передайте роботу, коли її продовжить інший виконавець, інший агент або людина, або коли завдання переживає кілька контекстних вікон. Передавання має містити бриф із підрозділу 24.7, шлях до актуального плану й доказів, стан змін, джерела та обмеження. Для незбережених змін назвіть робочу копію; для закоміченої роботи — точний коміт. Прямо позначте побічні дії, які виконано, і ті, які не дозволено виконувати. Не припускайте, що нова розмова має доступ до попередньої історії.

Після переходу прочитайте бриф і перевірте джерела, що визначають наступне рішення. Якщо вимога змінилася, оновіть її з походженням і датою, а не непомітно перепишіть попереднє рішення. Якщо стислий переказ конфліктує з чинним документом або журналом, розв’язуйте конфлікт через авторитетне джерело, а не довіру до того, хто писав останнім.

24.11. Повний приклад 1: дві версії правила

Умовна постановка. Команда просить додати перевірку періоду повернення коштів у сервісі замовлень. Агент знаходить три фрагменти:

Знахідка	Що в ній сказано	Походження і статус
docs/returns-policy.md, версія 4.2, у поточному коміті a18c4d2	Для придатних товарів запит на повернення треба подати протягом 14 календарних днів після доставки. Правило діє для замовлень, створених від 1 січня 2026 року.	Чинне затверджене джерело: реєстр docs/policy-index.md позначає версію 4.2 як дієву та таку, що замінила 4.1; цей запис перевірено в коміті a18c4d2.
support/returns-runbook.md, версія 4.1	Оператор може прийняти запит у межах 30 днів після доставки.	Стара інструкція; реєстр чинної політики в коміті a18c4d2 позначає її заміненою версією 4.2.
Переказ попередньої розмови	«Пам’ятаю, що для всіх замовлень вікно — 30 днів».	Джерело й дата не наведені; це свідчення про старе повідомлення, а не про чинну політику.

Поточне рішення. Використовувати версію 4.2 як чинне джерело: реалізувати 14-денне вікно лише для замовлень, створених від визначеної в ній дати, якщо код підтверджує потрібні дати та їх значення. Не застосовувати цю межу до старіших замовлень без окремого правила.

Що лишається невідомим. Фрагменти не визначають перехідне правило для замовлень до 1 січня 2026 року, обробку товарів, виключених із політики, часовий пояс або поведінку, коли дата доставки відсутня. Це не деталі, які треба заповнити здогадом. Потрібен авторитетний документ або рішення відповідального власника політики.

Як передати задачу далі. У брифі лишаються точні шляхи, версії, коміт, умова набрання чинності й невідомі. Рецензент може сам відкрити файли й перевірити зміну. Якщо підсумок згодом збереже лише речення «повернення — за 14 днів», воно вже втратило сферу дії та винятки; потрібно відновити їх із первинного джерела.

Цей приклад демонструє, чому джерело, поточне рішення й невідоме — окремі поля. Новіша на вигляд дата не завжди доводить авторитетність; усне повідомлення не робиться політикою; компроміс між двома значеннями не усуває конфлікту.

24.12. Повний приклад 2: не застосовувати міграцію після компактації

Умовна постановка. Агент готує зміну схеми бази даних для обліку спроб бронювання. У репозиторії є файл alembic/versions/b91ce2_add_booking_attempt_status.py і завдання: перевірити SQL (Structured Query Language — мова структурованих запитів), написати план запуску та описати крок відновлення. Умови передавання однозначні:

дозволено читати міграцію, переглянути її залежності та запустити статичний аналіз, який не підключається до бази;
заборонено запускати міграцію на локальній, тестовій, staging- або production-базі;
застосування потребує окремого схвалення власника бази й перевірки плану резервного копіювання;
поточна ревізія коду — 7f91b0c, зміни ще не злиті.

До компактації агент прочитав файл, записав стан роботи й побачив, що скрипт додає колонку та заповнює її для старих рядків. Після компактації короткий підсумок каже: «Схема готова; перейти до валідації». Він не повторює заборону запуску. Команда alembic upgrade head, якби її запустили в налаштованому середовищі, могла б застосувати зміни до бази.

Що робити після компактації. Не запускати команду міграції й не трактувати «перейти до валідації» як дозвіл. Переказ не зберіг критичне обмеження, тому агент спершу відкриває запис стану й первинне завдання, перевіряє коміт і поточну конфігурацію. Далі може виконати тільки перевірку, про яку відомо, що вона не підключається до бази. Якщо тип перевірки невідомий або може відкрити з’єднання, спершу з’ясувати його режим чи не запускати.

Постійний контроль. Зберегти межі в перевірюваному файлі плану, прив’язаному до ревізії: статус «не застосовано», точний шлях міграції, дозволені перевірки й умови для схвалення. Крім запису, середовище має підтримувати правило: агент не має облікових даних або дозволу на staging/production без схвалення; конвеєр розгортання очікує ручне підтвердження уповноваженої особи. Це не дає звичайному текстовому підсумку стати єдиним бар’єром. Якщо система не може технічно заблокувати дію, не запускайте її й отримайте потрібне людське рішення до продовження.

Чому нотатки недостатньо. Підсумок може бути коротким, неповним або застаріти після зміни коміту. Навіть точно написаний план може не завантажитися в наступний сеанс. А якщо скрипт уже застосувався, запис «не запускати» не поверне схему назад. Саме тому для операції з побічним ефектом важливі контроль дозволів, ручний шлюз, окрема команда застосування й перевірка фактичного стану. Текст зберігає намір і походження; контроль середовища стримує небажану дію.

Звіт після безпечної перевірки має називати фактичний режим і результат, наприклад: «SQL прочитано; статичну перевірку без підключення виконано на ревізії 7f91b0c; до бази не підключалися; міграцію не застосовано; очікується схвалення власника». Не можна написати «міграція перевірена» так, щоб це звучало як підтвердження успішного застосування.

Цей приклад показує, чому обмеження дії має переживати історію чату. Компактація може змінити активний контекст; вона не може видати повноваження на запуск або підмінити незмінний контроль доступу.

24.13. Повний приклад 3: увесь репозиторій чи індекс і цільове читання

Умовна постановка. У вигаданому репозиторії сервісу замовлень потрібно змінити один текст помилки для невалідного токена. Вимога не просить інвентаризувати весь проєкт. На початку агент ще не знає, у якому модулі формується ця відповідь.

Перше орієнтування: перевірити робочий каталог, гілку та незбережені зміни; визначити наявні кореневі інструкції; скласти карту верхнього рівня. Перелік на кшталт src/, tests/, docs/ дає навігаційні підказки, а не знання про вміст кожного файла. Якщо розділ має власний файл інструкцій, перевірити його завантаження, коли робота дійде до цієї теки.

Цільовий пошук: знайти чинний текст повідомлення, код помилки або обробник токена; прочитати визначення, місця виклику та відповідні тести. Знайти споживачів відповіді, щоб переконатися, що завдання змінює лише формулювання, а не статус чи контракт. Прочитати вимогу API або документацію про публічну відповідь, якщо вона визначає сумісність. Якщо пошук виявив спільну реалізацію для кількох маршрутів, розширити область до цих маршрутів і тестів.

Що не треба завантажувати без причини: історію кожного модуля каталогу, сторонні бібліотеки, великі журнали, усі документи продукту й попередню розмову цілком. Вони можуть стати потрібними, якщо виявиться зв’язок, але їхня присутність у репозиторії не доводить актуальності для цього запиту. Агент позначає, які шляхи лише побачив, а які фактично відкрив і перевірив.

Коли підійде індекс або повне читання. Якщо завдання зміниться на «знайти всі місця, де проєкт трактує невалідний токен як чинний», звичайний пошук за символами й маршрутами — природний перший інструмент. Якщо треба інвентаризувати кілька репозиторіїв із різними назвами та семантичними описами, можна розглянути текстовий індекс або RAG. Векторне сховище — лише одна можлива реалізація; воно не обов’язкове для одного відомого файла. Повний огляд репозиторію виправданий, коли критерій вимагає покриття всіх компонентів або взаємодій; тоді треба описати спосіб пошуку, винятки й доказ повноти.

Відповідь після дослідження має бути чесною: «Прочитано кореневі інструкції, обробник у src/auth/token_handler.py, його виклик у src/api/login.py та тести в tests/auth/test_token_handler.py на коміті [ідентифікатор]. Інші частини репозиторію не перевірялися; загального аудиту використань не проводили». Якщо виявлено ще один виклик або тест, додати його та продовжити пошук. Це дає рецензенту відтворювану дорогу до джерел.

Тут не приписано час, точність або відсоток економії ні повному читанню, ні індексу: результат залежить від структури проєкту, інструменту пошуку й задачі. Порівнюється лише відповідність методу критерію, а не вигаданий бенчмарк.

24.14. Підсумок

Контекст — це фактично наданий моделі вміст поточного кроку, а не синонім робочої папки, усієї розмови чи довготривалої пам’яті. Токени витрачаються на інструкції, історію, файли, схеми інструментів, результати й відповідь; точний бюджет залежить від моделі та продукту і змінюється. Файл треба справді прочитати або передати, а результат — перевірити, перш ніж посилатися на його зміст.

Великі контекстні вікна не гарантують однаково точного використання кожного фрагмента. Первинне дослідження Lost in the Middle виміряло позиційну залежність для певних задач і старіших моделей; воно не встановлює універсальний ефект для всіх моделей. «Context rot» і «context pollution» корисні для опису можливих проблем, але не є взаємозамінними стандартизованими вимірами.

Добрий робочий контекст містить ціль, критерії, чинні джерела, ревізію, статус, невідомі та найближчу дозволену дію. Пошук, читання за потребою й RAG допомагають відбирати дані; векторна база не обов’язкова для кожної задачі. Підсумок після компактації стискає історію, тож важливі рішення мають залишатися прив’язаними до файлів, дат, комітів та умов. Пам’ять продукту, кешування запиту й тривалий стан у файлах або сервісах вирішують різні задачі.

Чистий контекст рецензента зменшує непотрібний шум, але не є гарантією незалежності чи правильності. Якщо інструкцію пропущено, з’ясуйте, чи була вона завантажена, актуальна, ясна й у межах поточної задачі. Для продовження виберіть між тим самим сеансом, новим сеансом і явним передаванням за станом роботи; у кожному разі перевірте актуальне джерело перед важливою дією.

Джерела та подальше читання

Офіційні продуктові сторінки й документацію нижче перевірено 23 вересня 2026 року. Живі сторінки Anthropic та OpenAI, для яких у переглянутій версії не показано дату публікації або номера редакції, позначено як поточну документацію без видимої дати оновлення; посилання ведуть на сторінки, що можуть змінитися. Параметри API та функції продуктів тут описані як стан на дату перевірки, а не як гарантія доступу для кожного акаунта.

Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni та Percy Liang, «Lost in the Middle: How Language Models Use Long Contexts», Transactions of the Association for Computational Linguistics, том 12, сторінки 157–173, опубліковано в лютому 2024 року; DOI (Digital Object Identifier — цифровий ідентифікатор об'єкта) 10.1162/tacl_a_00638. Первинна рецензована стаття та її експерименти; висновки обмежені описаними наборами даних, умовами й моделями того періоду.
Anthropic, Context windows, поточна документація без видимої дати публікації чи версії; перевірено 23 вересня 2026 року. Підтримує опис того, що входить до контексту API Claude, взаємодії входу, виходу й міркування, а також компактації. Ліміти моделей можуть змінитися; у главі їх не зафіксовано числом.
Anthropic, Compaction at a token threshold, поточна документація без видимої дати публікації чи версії; перевірено 23 вересня 2026 року. Описує серверну компактацію Messages API та її блок у відповіді. Документація позначає функцію як бета-версію на дату перевірки.
Anthropic, Context editing, поточна документація без видимої дати публікації чи версії; перевірено 23 вересня 2026 року. Розрізняє вибіркове очищення контексту та компактацію; конкретні API-параметри залежать від актуальної версії.
Anthropic, Prompt caching, поточна документація без видимої дати публікації чи версії; перевірено 23 вересня 2026 року. Описує кешування префікса запиту й контрольні точки; не є джерелом тривалого стану завдання.
Anthropic, Effective context engineering for AI agents, інженерний матеріал опубліковано 29 вересня 2025 року; перевірено 23 вересня 2026 року. Пояснює термін context engineering, поступове отримання даних, компактацію, нотатки та субагентів. Це матеріал постачальника, не незалежний порівняльний бенчмарк.
Anthropic, Introducing Contextual Retrieval, інженерний матеріал опубліковано 19 вересня 2024 року; перевірено 23 вересня 2026 року. Пояснює один із варіантів пошуку для RAG і його недоліки; заявлені покращення стосуються експериментів, проведених авторами, а не кожного сховища чи задачі.
Anthropic, How Claude Code remembers your project, поточна документація без видимої дати публікації чи версії; перевірено 23 вересня 2026 року. Описує пам’ять і завантаження інструкцій саме в Claude Code, інструменти перевірки завантаженого стану та різницю між текстовими інструкціями й примусовою конфігурацією. Поведінку не слід автоматично переносити на інші агенти.
Anthropic, Memory tool, поточна документація без видимої дати публікації чи версії; перевірено 23 вересня 2026 року. Описує, як застосунок із власним сховищем виконує запитані моделлю операції пам’яті через інструмент.
OpenAI, Conversation state, поточна документація API без видимої дати публікації чи версії; перевірено 23 вересня 2026 року. Визначає вхідні й вихідні токени та контекст Responses API; також описує тривалий об’єкт Conversations API. Це конкретна API-модель керування станом, не властивість будь-якого сеансу ChatGPT або іншого агента.
OpenAI, Compaction, поточна документація API без видимої дати публікації чи версії; перевірено 26 вересня 2026 року. Описує серверну й окремо викликану компактацію в Responses API та зазначає, що елемент компактації непрозорий для читача.
OpenAI, Key concepts, поточна документація без видимої дати публікації чи версії; перевірено 23 вересня 2026 року. Пояснює GPT як generative pre-trained transformer.
MosaicML, LLM (Large Language Model — велика мовна модель) Foundry repository, офіційний репозиторій; перевірено 23 вересня 2026 року. Розшифровує MPT як Mosaic Pretrained Transformers.
OpenAI, Prompt caching, поточна документація API без видимої дати публікації чи версії; перевірено 23 вересня 2026 року. Пояснює повторне використання префікса та стани key-value (KV, «ключ — значення») моделі, умови збігу й вплив зміни префікса. Точні пороги кешування й поведінка можуть змінюватися між моделями.
OpenAI, Codex documentation, перевірено 23 вересня 2026 року: адреса перенаправляє на офіційний ChatGPT Learn, у навігації якого є розділи Codex Desktop, CLI, IDE та Cloud. Це фіксує перенаправлення й перелік поверхонь продукту на дату перевірки; API-специфікацію Codex ця сторінка не підтверджує.
Alembic, Tutorial, поточна документація без видимої дати публікації; перевірено 26 вересня 2026 року. Описує скрипти ревізій у каталозі versions і запуск керованих міграцій через команду Alembic.

Межі джерел і висновків. Емпірична опора для позиційного ефекту — одна первинна стаття 2024 року на моделях і завданнях, визначених її авторами. Поточні характеристики Anthropic та OpenAI походять від самих постачальників і підтверджують лише описані ними API чи продуктову документацію на дату перегляду. Вони не доводять поведінку кожної конфігурації, якість конкретного сеансу, повноту прочитаного файла або доступність функції для будь-якого користувача. У главі не використано власного бенчмарку чи вигаданого числового порівняння.