NAME
context-engineering-agents — Контекстна інженерія: робота до підказки
SYNOPSIS
cat context-engineering-agents.md
DESCRIPTION
У маленькому світі агентів штучного інтелекту актуальною є інженерія контексту.
Здається, ще один лейбл, придуманий для продажу того, що ми вже зробили. Частково так і є. Однак, як це часто буває, ярлик приживається, бо дає назву справжньому болю.
Біль ось у чому: моделі не зазнають невдач лише тому, що вони «не думають». Вони часто виходять з ладу, тому що ми відправляємо їх на роботу не з тим приміщенням.
Ми даємо їм старі інструкції. Ми приховуємо від нього важливі файли. Ми передаємо їм надто довгі документи, в яких не йдеться про важливе. Ми показуємо їм журнали без пріоритету. Ми даємо їм десять інструментів, не пояснюючи, коли їх використовувати. Потім ми дивуємося, якщо агент рухається, як людина, яка прокинулася в незнайомій квартирі.
Підказка - це фраза, яку ви їй говорите. Контекст — це світ, який ви готуєте навколо нього.
Від швидкої інженерії до контекстної інженерії
Швидку інженерію часто вважали письмом. Доберіть правильні слова, запитайте правильно, додайте приклади, укажіть формат.
Контекстна інженерія ближча до архітектури.
Ви не просто запитуєте «як сформулювати запит?». Він запитує:
- яка інформація дійсно потрібна?
- що таке шуми?
- що потрібно відновити на ходу?
- що треба пам'ятати?
- які інструменти необхідно виставити?
- які інструкції є стабільними, а які залежать від завдання?
- як змусити агента зрозуміти, що є авторитетним?
Це незначна, але величезна зміна. Тому що коли ви працюєте з агентами, контекст не є статичним блоком. Змінюється на кожному кроці.
Агент відкриває файл, дізнається щось, запускає тест, отримує повідомлення про помилку, оновлює план, викликає інструмент, виявляє залежність. З кожним колом він повинен вирішити, що взяти з собою, а що залишити.
Це інженерія.
Контекст не звалище
Шаблони з великими контекстними вікнами викликали у нас спокусу: давайте кинемо все.
Це зрозуміло. Якщо я маю мільйон токенів, чому я маю вибрати?
Тому що навіть коли ви можете вкласти все, це не означає, що все допомагає. Дійсно, шум має ціну. Це коштує жетонів, уваги, затримки, якості. Модель може загубитися в нерелевантних деталях, як і ми, коли ми відкриваємо двадцять вкладок і більше не пам’ятаємо, чому.
Хороший контекст має ієрархію:
- системні інструкції та політики;
- конкретна мета;
- поточний стан;
- відповідні дані;
- обмеження;
- наявні інструменти;
- відслідковувати вже прийняті рішення.
Немає необхідності ставитися до всього на одному рівні. Команда користувача коштує більше, ніж стара нотатка. Невдалий іспит тепер коштує більше, ніж естетичні уподобання тримісячної давності. Політика безпеки коштує більше, ніж робочий ярлик.
Контекстна інженерія також означає надання вагових коефіцієнтів, а не лише даних.
Пам'ять: пам'ятайте менше, запам'ятовуйте краще
Пам'ять в агентів - одна з найбільш слизьких тем.
Як користувач, ви хочете, щоб агент знав вас. Ви хочете, щоб він пам’ятав тон, план, умовності, речі, які вже вирішено. Як інженер, ви знаєте, що кожна постійна пам’ять також є ризиком: вона може бути помилковою, старою, надто особистою, надто загальною, неможливою перевірити.
Корисна пам'ять повинна мати принаймні три якості:
- походження: звідки ця інформація?
- дата: коли це було правдою?
- призначення: для якого типу завдання його слід використовувати?
Без цих трьох речей пам’ять стає марновірством.
Мені подобається думати про агентську пам’ять як про робочий зошит, а не як про магічний розум. Є тимчасові примітки, підтверджені рішення, стильові переваги, технічні обмеження, посилання на джерела. Деякі речі закінчуються. Деякі потрібно переписати. Деякі з них повинні бути усунені, тому що агент неправильно їх визнав.
Хороша система повинна зробити це обслуговування нормальним. Не героїчно.
Пошук та інструменти – це не одне й те саме
Коли ми говоримо про контекст, ми часто відразу потрапляємо на RAG. Вбудовування, векторна база даних, фрагментація, переранжування.
Все корисне. Але пошук — це лише один із способів передачі інформації в модель. Він не один такий.
Агент може отримати контекст, читаючи файли, запитуючи API, викликаючи сервер MCP, відкриваючи браузер, запускаючи тести, шукаючи в Slack, дивлячись на інформаційну панель, запитуючи людину.
Найцікавішим є вибір маршруту та коли.
Якщо агенту потрібно відповісти на історичне запитання, можливо, достатньо простого пошуку. Якщо йому потрібно виправити помилку, він повинен прочитати справжній код. Якщо йому потрібно зрозуміти, чому розгортання не вдається, йому потрібно переглянути нові журнали. Якщо вам потрібно написати клієнту, вам потрібно отримати тональний сигнал, історію та статус квитка. Якщо він повинен працювати на виробництві, він повинен запитати дозволу.
Контекст не є базою даних. Це робочий процес.
Хороший агент також вміє ігнорувати
Ознакою зрілості в агентів буде вміння сказати: мені ця інформація не потрібна.
Це здається дріб'язковим, але це дуже важко. Накопичується багато агентних систем. Кожен виклик інструмента додає текст. Кожна помилка залишається в буфері. Кожне прочитане файл додає до стека. Зрештою, модель має дуже довгу історію і не має карти.
Потрібна компресія. Потрібен проміжний синтез. Його потрібно структурувати.
Не «це все, що сталося», а:
- ціль все ще актуальна;
- актуальна гіпотеза;
- файли вже перевірені;
- прийняті рішення;
- відкриті ризики;
- наступна дія.
Це робить агента менш театральним і більш корисним. Не тому, що він здається розумнішим, а тому, що він працює з охайним столом.
Розробка контексту для команд, а не для виконавців підказок
Ця тема мене цікавить тому, що вона перекладає відповідальність з особи на систему.
У швидкому проектуванні часто виграє той, хто найкраще може говорити з моделлю. У розробці контексту виграє команда, яка найкраще організує свою роботу: документація, угоди, проблеми, журнали, тести, право власності, іменування, джерела.
Чисте сховище стає кращим контекстом. Добре написане питання стає кращим паливом. Оновлений Runbook заощаджує жетони та занепокоєння. Чіткий журнал змін зменшує галюцинації.
Це гарна і дещо неприємна новина. Красиво, тому що винагороджує хороші практики. Незручно, бо розумною підказкою все не вирішиш.
Агенти посилюють гігієну системи, яку вони знаходять.
Як би я застосував це завтра
Якби я запроваджував контекстну інженерію в реальний проект, я б почав із дрібниць:
- короткий і підтримуваний файл інструкцій проекту;
- хороші приклади очікуваного результату;
- перелік доступних інструментів і випадків їх використання;
- архітектурні рішення, виписані у цитабельній манері;
- проблема з мінімальним обов'язковим контекстом;
- легке отримання журналів і тестів;
- постійна пам'ять, яку може змінювати людина.
Тоді я б виміряв просту річ: скільки разів агент повинен запитувати роз’яснення або їде в неправильному напрямку?
Якщо це трапляється часто, я б не став відразу додавати більшу модель. Я б дивився на контекст.
Моє читання
Контекстна інженерія – це трохи роздуте слово, так. Але концепція здорова.
Це нагадує нам, що інтелект агента полягає не лише в моделі. Вона полягає в тому середовищі, яке ми для нього готуємо: що він бачить, що він пам'ятає, що він може робити, що йому заборонено робити, які джерела він визнає правдивими.
Людська частина полягає в наступному: добре підготувати контекст є формою турботи. Це говорить агенту, а також команді: «Я не хочу, щоб ви здогадувалися, я хочу, щоб ви мали те, що вам потрібно».
Менше магії. Чистіша кімната. Агентам це потрібно так само, як і нам.
Джерела
METADATA
- date: 2026-06-30
- reading: 6 min
- author: Filippo Spinella
- tags: AI, Agents, Prompting, Developer Tools