Anthropic: Ефективна побудва контексту для AI агентів

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

1. Вступ

Оригінальна назва секції: (без заголовка, вступний блок)
Переклад: «Ефективний інжиніринг контексту для AI-агентів»

Суть блоку:

  • Контекст = усі токени, які модель бачить під час інференсу (системні інструкції, історія повідомлень, дані з інструментів, зовнішні файли тощо).
  • Класичний фокус на «prompt engineering» зміщується: зараз питання звучить як«Яка конфігурація контексту найімовірніше дасть бажану поведінку моделі?».
  • Інженерна задача: максимізувати корисність кожного токена з урахуванням того, що:
    • контекст обмежений по довжині;
    • увага моделі (attention) — теж обмежений ресурс.
  • Вони вводять термін context engineering — як природне продовження prompt engineering: тепер важливо не тільки, що написано в промпті, а й що взагалі потрапляє в контекстове вікно в кожен момент часу.

2. «Context engineering vs. prompt engineering»

Оригінальна назва: Context engineering vs. prompt engineering
Переклад: «Інжиніринг контексту проти інжинірингу промптів»

Суть блоку:

  • Prompt engineering — це про те, як написати інструкцію, організувати system prompt, приклади, щоб модель видавала потрібні відповіді в рамках однієї задачі / короткої сесії.
  • Context engineering — це про керування всім станом контексту:
    • системні інструкції,
    • tools / API-виклики,
    • Model Context Protocol (MCP),
    • зовнішні дані,
    • історія повідомлень,
    • проміжні результати.
  • З появою агентів, які працюють:
    • багатоходово (багато кроків),
    • довго (хвилини, години),
      стає критично важливо циклічно відбирати, що саме потрапить у наступний контекст.
  • Вони формулюють context engineering як «art and science of curation» — мистецтво і наука відбору релевантних токенів перед кожним викликом моделі.

3. «Why context engineering is important to building capable agents»

Оригінальна назва: Why context engineering is important to building capable agents
Переклад: «Чому інжиніринг контексту критично важливий для побудови здатних агентів»

Суть блоку:

  • У всіх LLM проявляється явище context rot — коли з ростом кількості токенів у контексті якість точного відтворення потрібної інформації падає.
  • Як у людини є обмежена робоча пам’ять, так у моделі є обмежений attention budget:
    • кожен новий токен з’їдає частину цього бюджету;
    • чим більше «шуму», тим важче моделі зосередитись на важливому.
  • Через архітектуру трансформера кожен токен може «дивитись» на кожен інший (O(n²) уваги). На довгих послідовностях це розмиває фокус.
  • Моделі, як правило, тренуються більше на коротших послідовностях, тому для дуже довгих контекстів у них менше «досвіду».
  • Висновок блоку: контекст — це скінченний ресурс із зменшуваною віддачею, тому без грамотного відбору токенів агенти неминуче деградують на довгих задачах.

4. «The anatomy of effective context»

Оригінальна назва: The anatomy of effective context
Переклад: «Анатомія ефективного контексту»

У цьому блоці вони розкладають, з чого складається «хороший» контекст.

4.1. System prompts

  • System prompt має бути:
    • дуже чітким;
    • простою, прямою мовою;
    • на «правильній висоті абстракції» («Goldilocks zone» — не занадто низько, не занадто високо).
  • Два типові фейли:
    1. Надто деталізований, «if-else-лайк» промпт:
      • важко підтримувати,
      • ламкий,
      • моделі легше дати автономію, ніж зашивати логіку в текст.
    2. Надто загальний промпт:
      • багато красивих слів, мало конкретики,
      • припускає «спільний контекст», якого насправді немає.
  • Рекомендації:
    • ділити промпт на секції типу:
      <background_information>, <instructions>, ## Tool guidance, ## Output description тощо;
    • використовувати XML-теги або Markdown-хедери;
    • шукати мінімальний набір інформації, який повністю визначає очікувану поведінку (мінімальний ≠ короткий).

4.2. Tools (інструменти агента)

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

4.3. Examples (few-shot) і edge cases

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

4.4. Загальне правило для всіх компонентів контексту

  • Для system prompt, tools, examples, message history діє один принцип:
    → контекст має бути інформативним, але «щільним» (tight).
  • Зайвий текст, дублювання інформації, довгі сирі логи — все це з’їдає attention budget і знижує якість.

5. «Context retrieval and agentic search»

Оригінальна назва: Context retrieval and agentic search
Переклад: «Витяг контексту та агентний пошук»

Суть блоку:

  • Вони приймають просте визначення агента:«LLM, який автономно використовує інструменти в циклі».
  • Багато застосунків сьогодні роблять pre-inference retrieval:
    • за embedding’ами шукають релевантні документи;
    • підкладають їх у контекст перед викликом моделі.
  • З переходом до справжніх агентів з’являється “just-in-time контекст”:
    • агент не тягне все одразу;
    • він тримає легкі ідентифікатори (шляхи до файлів, URL, збережені запити);
    • і підвантажує дані в контекст тільки тоді, коли це потрібно, через інструменти.
  • Приклад: Claude Code:
    • пише SQL / Bash команди;
    • тягне тільки фрагменти великих файлів (через head, tail, grep, glob);
    • ніколи не вантажить «цілі бази» в контекст.
  • Метадані (шляхи, імена файлів, структура папок, timestamps) дають агенту сильні сигнали, як інтерпретувати дані:
    • tests/test_utils.py ≠ src/core_logic/test_utils.py.
  • Плюси «just-in-time»:
    • менше токенів у контексті;
    • зменшується «context rot»;
    • агент будує розуміння «шар за шаром».
  • Мінуси:
    • повільніше, ніж один великий pre-fetch;
    • вимагає акуратного проєктування інструментів і стратегій навігації, інакше агент буде «блукати» і марнувати контекст.
  • Вони радять гібридний підхід:
    • частину контексту витягати наперед (особливо статичні речі);
    • решту — довантажувати агенту «на вимогу».

6. «Context engineering for long-horizon tasks»

Оригінальна назва: Context engineering for long-horizon tasks
Переклад: «Інжиніринг контексту для довгих (long-horizon) задач»

Цей блок — найбільш практичний. Вони розглядають три техніки:

6.1. Compaction (стискання контексту)

  • Compaction = коли довга сесія підходить до ліміту контексту,
    агент підсумовує / стискає історію й починає нове вікно контексту зі стисненим описом.
  • Ідея:
    • залишити архітектурні рішення,
    • незакриті баги / задачі,
    • важливі деталі імплементації;
    • викинути дубльовані логи інструментів, шум, дрібниці.
  • У Claude Code:
    • береться message history;
    • модель робить high-fidelity summary;
    • агент продовжує роботу з цим summary + кілька останніх файлів у повному вигляді.
  • Важливий момент:
    • надто агресивне стискання = втрата «слабких сигналів», які можуть стати критичними пізніше;
    • тому вони радять спочатку налаштовувати compaction «на максимум recall», а потім поступово чистити зайве.

6.2. Structured note-taking (структуровані нотатки / пам’ять агента)

  • Ідея: агент регулярно пише нотатки в зовнішнє сховище (файли, memory tool).
  • Ці нотатки:
    • живуть поза контекстом;
    • за потреби витягуються назад у контекст.
  • Приклади:
    • NOTES.md з to-do для проєкту;
    • список рішень/архітектурних домовленостей;
    • прогрес-лог по довгій задачі.
  • Вони показують приклад із Claude, що грає в Pokémon:
    • агент веде статистику на тисячах кроків,
    • пам’ятає, де вже був, що зловив, які стратегії бою працюють;
    • після «context reset» просто читає власні нотатки й продовжує.
  • У рамках запуску Sonnet 4.5 Anthropic додали memory tool на платформі, щоб спростити зберігання знань поза контекстом і подальший доступ до них.

6.3. Sub-agent architectures (архітектури з під-агентами)

  • Замість одного гігантського агента, який пам’ятає «все про все», вони пропонують підхід «головний агент + спеціалізовані під-агенти».
  • Під-агенти:
    • працюють у своїх «чистих» вікнах контексту;
    • можуть «спалити» десятки тисяч токенів на дослідження вузької задачі;
    • у підсумку повертають стиснений підсумок (1–2k токенів).
  • Головний агент:
    • тримає в голові загальний план;
    • збирає результати під-агентів;
    • синтезує остаточне рішення.
  • Це дає:
    • чіткий поділ відповідальностей;
    • локалізацію «context rot» всередині під-агентів;
    • кращу масштабованість на складних дослідницьких / аналітичних задачах.

В кінці секції вони порівнюють, для чого краще підходить кожен підхід:

  • Compaction — коли потрібен живий діалог зі збереженням історії.
  • Note-taking — для ітеративної роботи з віхами (development, research, long-term projects).
  • Multi-agent — для складних досліджень, де паралельна робота під-агентів дає виграш.

7. «Conclusion»

Оригінальна назва: Conclusion
Переклад: «Висновок»

Суть фінального блоку:

  • Context engineering — це зміна парадигми:
    • важливо вже не тільки «як сформулювати промпт»;
    • а й що саме, у якій формі й у який момент потрапляє в контекст.
  • Головний принцип:шукати найменший можливий набір високосигнальних токенів, який максимізує ймовірність бажаного результату.
  • Приклади застосування:
    • написання токен-ефективних tools;
    • впровадження compaction для довгих задач;
    • структурована пам’ять поза контекстом;
    • гібридний контекст-retrieval (частково наперед, частково just-in-time).
  • Вони підкреслюють:
    чим розумнішими стають моделі, тим менше треба «мікроменеджити» їхні промпти, але ставитись до контексту як до дефіцитного ресурсу доведеться завжди.

Published by

Serhii Kholin

CEO at Onix-Systems.com