Від інженерії запитів до інженерії контексту: писати, вибирати, стискувати, ізолювати
Курс з інженерії контексту для штучних інтелектуальних агентів: чому інженерія запитів є недостатньою, як заповнюється вікно контексту, чотири стратегії, RAG для інструментів, Claude Code.
Будь-хто, хто створював агента, ймовірно, бачив таку саму схему. Протягом перших кількох кроків він поводиться добре: обирає доцільні інструменти, чітко міркує та дотримується завдання. Близько 15-го чи 20-го кроку він починає допускати помилки. Він забуває, що було запитано, використовує інструменти, які не підходять для завдання, або починає отримувати слабкі результати.
Зазвичай першою підозрою є сама модель. Але частіше причиною є те, що показується моделі. Вирішення питання про те, що буде показано моделі, у якій формі та у який момент, називається інжинірингом контексту, і для тих, хто створює агентів, це стає однією з найцінніших навичок.
У наступних розділах розглядається, що таке інжиніринг контексту та чому агентам він потрібен, чотири стратегії, які організовують майже кожну техніку, чотири способи, якими може піти не так із контекстом, конкретні поради щодо запитів до системи та визначень інструментів, поетапний процес роботи, який поєднує ці стратегії, а також те, як Claude Code, Manus, ChatGPT Agent та Google’s Agent Development Kit вирішують цю проблему.
Від інжинірингу запитів до інжинірингу контексту у вікні контексту
Інжиніринг запитів — це мистецтво написання хороших інструкцій для мовної моделі: чітке формулювання, надання прикладів, призначення ролі. Для розмови з одним запитанням та відповіддю цього часто достатньо.
Агенти змінюють ситуацію. Агент не відповідає одразу — він переглядає інформацію, викликає API, пише код та виконує команди крок за кроком, іноді десятками кроків, без участі людини. Кожен крок створює результат, і всі вони потрапляють у контекст моделі, який має фіксований розмір.
Тому інженерія контексту — це проектування всієї інформаційної системи навколо моделі. Це охоплює системні запити, визначення інструментів, результати попередніх викликів інструментів, історію розмов та багато іншого на кожному кроці. Інженерна команда Anthropic описує контекст як набір токенів, які включаються під час отримання даних від моделі, а інженерію контексту — як оптимізацію корисності цих токенів для досягнення бажаного результату. Простіше кажучи, агент має бачити правильну інформацію у правильному форматі у правильний час.
Anthropic також розглядає це як природний наступний етап після інженерії запитів. Усе, що було важливим у формулюванні запитів, залишається актуальним (чіткі інструкції, гарні приклади, структуроване форматування), але додається ще один рівень: інструменти, зовнішні дані, історія повідомлень, пам’ять та динамічний стан. Інженерія запитів стає її підмножиною.
Час має значення. Gartner прогнозує, що до кінця 2026 року 40% корпоративних додатків будуть включати ШІ-агентів, призначених для виконання конкретних завдань, що є підвищенням порівняно з менш ніж 5% у 2025 році. Ці агенти замінюють статичні запити та фіксовані механізми отримання інформації на динамічну систему, у якій кожен виклик інструменту, отриманий документ та прийняте рішення потрапляють у вікно, яке заповнюється матеріалом, про який користувач ніколи прямо не просив. Команди, які навчаються керувати цим, зазвичай створюють агентів, які залишаються надійними, адже вони перестають звинувачувати модель у проблемах, що походять від її вхідних даних.
Вікно контексту як робоча пам’ять
LangChain пропонує зручну аналогію. Розглядайте LLM як новий тип операційної системи: модель — це процесор, який виконує обчислення, а вікно контексту — це оперативна пам’ять, яка зберігає все, що модель може бачити у цей момент. Так само, як комп’ютер уповільнює роботу, коли оперативна пам’ять заповнюється, так і здатність агента до міркувань погіршується, коли його вікно контексту заповнюється.
Цей ефект має назву — розкладання контексту. Chroma протестувала вісімнадцять передових моделей, серед них GPT-4.1, Claude 4, Gemini 2.5 та Qwen3, і виявила, що кожна з них показує гіршу продуктивність зі збільшенням довжини вхідних даних, навіть значно нижче оголошеного ліміту. Модель із вікном на 200K токенів може демонструвати суттєве погіршення продуктивності вже при 50K токенах. Не існує раптового спаду, лише поступове погіршення. Власні технічні матеріали компанії Anthropic дійшли до тієї ж висновку та розглядають це погіршення як поступову зміну.
Причина криється у принципі роботи трансформерів. Кожен токен звертає увагу на кожен інший токен, що створює n-квадратний чисельний ряд парних взаємозв’язків. У міру збільшення розміру вікна здатність моделі відстежувати всі ці взаємозв’язки зменшується, що схоже на ситуацію, коли від когось вимагають пам’ятати все більшу кількість елементів у своїй голові. У певний момент деякі з них просто залишаються непоміченими.
Ще один добре вивчений ефект — це „втрата інформації посередині“. Дослідницька група під керівництвом Лю виявила, що механізм уваги має форму літери U. Інформація, розташована ближче до початку контексту, запам’ятовується добре, інформація ближче до кінця також запам’ятовується добре, тоді як інформація посередині залишається непоміченою; точність обробки знижується більш ніж на тридцять відсоткових пунктів, коли відповідний фрагмент переміщується з початку в середину. Уявіть собі агента, чиї початкові інструкції знаходяться під п’ятдесятьма тисячами токенів результатів роботи інструментів — ці інструкції фактично зникають.
Фахівці розробили певні орієнтовні правила. Користувачі Claude Code повідомляють, що якість результату починає погіршуватися приблизно на рівні 40–60 відсотків часу роботи, задовго до досягнення будь-якого жорсткого ліміту.
Що конкурує за простір
Сім видів інформації борються за місце в контексті агента:
- Системний запит – це ідентичність агента: правила поведінки, логіка керування та вказівки щодо різних типів завдань. Для агента це значно більше, ніж просто рядок „корисний асистент“, і може визначати спосіб функціонування всієї системи.
- Визначення інструментів. Кожен інструмент, який може використовувати агент, потребує схеми, яка описує його функції, параметри, які він приймає, та ситуації, коли його слід використовувати.
- Результати роботи інструментів. Кожен виклик додає свій результат. Завантажена веб-сторінка може містити від п’яти до десяти тисяч токенів, і з читанням файлів ситуація схожа.
Чотири основні стратегії з прикладами RAG та Claude Code
З обмеженим та поступово зменшуваним проміжком часу виникають питання про те, що потрапляє всередину, що залишається зовні та що змушене пройти процес стиснення. Широко використовувана фреймворк LangChain класифікує кожну техніку роботи з контекстом на чотири категорії: запис, вибір, стиснення та ізоляція. Як тільки ви ознайомитеся з ними, майже будь-яка техніка, з якою ви зіткнетеся, буде віднесена до однієї з цих категорій.
Запис
Агенти забувають. Коли повний контекст стискається, інформація зникає, і якщо агент не зберіг її в іншому місці, вона втрачається. Запис означає надання агенту способів зберігати інформацію поза межами цього проміжку часу. Це може відбуватися трьома поширеними способами.
Scratchpads — це інструмент для запису нотаток, який агент може використовувати під час виконання завдання для фіксації тимчасових результатів, рішень та інформації, яка знадобиться пізніше. Anthropic створив інструмент „think“, який надає Claude спеціальне місце для розгляду проблеми, і за допомогою тесту tau-bench він покращив продуктивність на 54% у деяких завданнях.
Файли правил виконують функцію постійної процедурної пам’яті. Користувачі Claude Code знають файл CLAUDE.md. Ці файли завантажуються на початку кожної сесії як постійні інструкції, які описують архітектуру проекту, правила, способи виконання тестів та моменти, на які потрібно звернути увагу, щоб основи ніколи не забувалися.
Вилучення пам’яті дозволяє агенту зберігати факти, уподобання та навчені шаблони у файловій системі та звертатися до них у наступних сесіях, повністю поза межами поточного вікна.
Вибір
Примітки є корисними лише тоді, коли правильні з них надходять у правильний момент. Вибір означає надання агенту того, що йому потрібно на цьому етапі, а не всього, що він міг би використати. Агент із десятками інструментів, великою базою знань та кількома історичними сеансами не може одночасно обробити все це, тому хтось має вирішувати, що є релевантним, і справжнє питання полягає у тому, хто саме це вирішує.
У класичному RAG рішення приймає система: надходить запит, знаходяться документи та вставляються у запрошення до моделі, причому модель не має права голосу. У агентному RAG сам агент вибирає, що шукати, які інструменти використовувати, як удосконалювати запити та коли у нього вже достатньо інформації. Процес пошуку стає ітеративним, що є доцільним, адже релевантність змінюється на кожному кроці довгого завдання, і лише агент знає, що йому потрібно далі.
Як LangChain, так і Pinecone розрізняють три види пам’яті, з яких можна черпати інформацію. Епізодична пам’ять — це приклади того, як раніше вирішувалися схожі ситуації. Семантична пам’ять — це сховище фактів, які агент дізнався або йому повідомили. Процедурна пам’ять — це постійні інструкції щодо поведінки, такі як наведені вище файли з правилами. Добре створений агент використовує всі три види пам’яті залежно від кроку виконання завдання.
Інструменти створюють найбільші проблеми з вибором. За наявності понад сорока інструментів у контексті може знаходитися близько десяти тисяч токенів визначень ще до початку роботи. Як показано у розділі про проблеми нижче, занадто багато інструментів не лише марнує простір, але й активно ускладнює роботу моделі.
Рішенням є застосування RAG до самого опису інструментів шляхом проведення семантичного пошуку, який видає лише ті кілька інструментів, які можуть бути використані на поточному етапі. У статті під назвою RAG-MCP це було перевірено, і точність вибору інструментів зросла з приблизно 14% до 43%, тобто більш ніж утричі, тоді як кількість токенів запиту зменшилася приблизно наполовину.
Загальна порада від Anthropic — це гібридний підхід. Заздалегідь завантажуйте невелику кількість необхідних матеріалів для прискорення роботи, наприклад файл CLAUDE.md, а решту даних нехай агент отримує у потрібний момент. На практиці це означає, що агент зберігає легкі посилання, такі як шляхи до файлів, запити та посилання, а важкий контент відкриває лише тоді, коли це необхідно на певному етапі. Попереднє завантаження основних даних та отримання решти за потребою дозволяє зберігати легкість роботи агента, не залишаючи його без інформації.
Стиснення
Навіть при хорошому виборі вікно продовжує заповнюватися. Уявіть агента, який отримав двадцять запитів до інструментів. Він несе вісімдесят тисяч токенів результатів, історії та слідів міркувань, більшість з яких він вже обробив. Цей старий матеріал все ще займає простір, відволікає увагу та підвищує витрати та затримки. Це знову проблема зі зношенням контексту, а стиснення вирішує її шляхом скорочення кількості токенів, зберігаючи при цьому важливу інформацію. Це можна зробити у трьох моментах.
Перед тим, як інформація потрапить у контекст. Розділення на частини дозволяє розбити великі документи на менші, послідовні фрагменти, а переурочування рангів забезпечує потрапляння до вікна лише найкращих фрагментів. Результати роботи інструментів також можна урізноманітнювати на льоту, ще до того, як вони приєднаються до основного контексту.
Поки агент працює. Загальноприйнятою технікою є узагальнення розмови: постійний огляд, оновлюваний після кожної зміни, зберігає компактний запис усього, що відбулося до цього моменту. Популярний гібридний підхід зберігає останні десять повідомлень слово в слово, оскільки іноді все ще можуть знадобитися точні деталі, а все старіше узагальнюється. Іншим варіантом є просте скорочення за жорстко встановленими правилами — видалення старих повідомлень, коли досягається певний поріг обсягу. Claude Code має вбудовану функцію автоматичного скорочення, яка узагальнює всю історію розмови, коли обсяг досягає 95%. Це своєрідна запобіжна міра. Ідеально, якби стиснення відбувалося заздалегідь, а не при аварійному сигналі.
Після того, як агент щось використав. Простим рішенням є очищення результатів роботи інструменту. Якщо інструмент виконав п’ятнадцять кроків назад, а агент вже взяв заходи щодо отриманого результату, первинний текст можна видалити. Повну веб-сторінку, завантажену давно, можна замінити однорядковим резюме або повністю видалити.
Ізоляція
Саме ізоляція робить багатоагентні системи придатними до використання. Припустимо, один агент виконує завдання з дослідження, планування, програмування, тестування та виправлення помилок протягом однієї довгої розмови. Його контекст буде заповнюватися, але ще більшою проблемою є забруднення. Пошуки файлів з фази дослідження залишаються у системі під час початку реалізації, і ці старі дані стають шумом, який відволікає модель саме тоді, коли їй потрібно писати чистий код.
Рішенням є надання окремим частинам роботи окремих вікон контексту.
Очевидним способом є використання підагентів. Батьківський агент доручає конкретне завдання, наприклад пошук усіх файлів, пов’язаних з автентифікацією, підагенту, який працює у власному окремому вікні. Після виконання він повертає лише стислий огляд, а вся складна процедура пошуку залишається всередині підагента, не завдаючи проблем батьківському агенту.
Іншим варіантом є ізоляція схеми стану, як це реалізовано в LangGraph. Стан агента спроєктований так, щоб різні поля містили різні види контексту, і модель бачить лише ті поля, які є актуальними для поточного кроку. Результати роботи інструментів можуть знаходитися у полях, недоступних для моделі, поки щось навмисно не виведе їх на поверхню. Це дозволяє здійснювати дрібнокроковий контроль без необхідності створення додаткових агентів.
Коротко кажучи, стратегії полягають у запису, вибору, стисненні та ізоляції, і все, що йде далі, використовує одну або кілька з них.
Як агенти зазнають невдач
Способи збою навчають, чого слід уникати. У середині 2025 року Дрю Бройніг написав впливову двочастинну серію, у якій описав чотири окремі способи, якими агенти втрачають функціональність у міру збільшення обсягу їхнього контексту.
Отруєння контекстом. Галюцинація чи помилка потрапляє до контексту та потім постійно згадується. Можливо, інструмент повернув некоректні дані, або агент зробив хибний висновок п’ять кроків тому. Тепер ця помилка залишається в контексті, і агент продовжує працювати з нею, а оскільки агенти ітерують над власними результатами, кожен неправильний крок посилює проблему. Рішенням є прунінг: активне видалення застарілої чи суперечливої інформації з появою нових деталей, перевірка результатів інструментів (особливо з зовнішніх джерел) перед їх включенням до контексту, а також стиснення невдалих спроб після того, як агент подолає помилку, щоб десять кроків безрезультатної налагодки не залишалися, коли важлива лише резолюція. Якщо їх залишити, ці невдалі спроби продовжуватимуть спонукати модель до використання підходів, які вже зазнали невдачі.
Відволікання через довгий контекст. При дуже довгому контексті модель починає занадто сильно покладатися на нещодавню історію та занадто мало — на те, що вона навчилася під час навчання. Вона припиняє створювати щось нове та повторює шаблони, які нещодавно бачила, знову використовуючи минулі дії замість того, щоб сформувати новий план. Рішення полягає у тому самому загальному пораді: робіть узагальнення та рішуче скорочуйте інформацію, навіть якщо обсяг даних величезний.
Плутанина з контекстом. Модель сприймає зайвий контент, що погіршує якість відповіді. Класичним прикладом є плутанина з інструментами. У дослідженні на основі тесту GeoEngine використовувався квантований модель Llama 3.1 8B. Незважаючи на те, що обсяг контексту був у межах допустимого, модель зазнала невдачі при наявності всіх сорока шести доступних інструментів, але працювала коректно при використанні лише дев’ятнадцяти. Інструменти поміщалися в межі можливостей моделі, але їх кількість була занадто великою, щоб модель могла чітко їх обробити. Рішенням є динамічне управління інструментами: слід обмежити їх кількість тими, які відповідають поточному етапу роботи агента, причому засіб пошуку у стилі RAG-MCP має вибирати відповідні інструменти для кожного кроку.
Конфлікт контексту. Нова інформація, отримана під час виконання завдання, суперечить чомусь, що вже є в контексті. У системному запиті може бути сказано одне, тоді як у отриманому документі — інше. Агент не може примирити ці дані та поводиться непослідовно: іноді слідує за одним джерелом, іноді — за іншим, а іноді робить щось, що не відповідає жодному з них. Рішенням є чітке розташування джерел авторитетності: системний запит має перевагу над отриманими фактами, а отримані факти — над історією розмови. Перед введенням нової інформації необхідно перевірити її відповідність тому, що вже є, а також використовувати структуровані елементи, такі як XML-теги чи чіткі заголовки, щоб модель могла зрозуміти, звідки походить кожен елемент та наскільки йому можна довіряти.
Хороша новина полягає у тому, що визначення причини невдачі зазвичай вказує на відповідну стратегію. Проблему отруєння даних вирішують за допомогою стиснення та видалення зайвого, проблему відволікання — стисненням, проблему плутанини — відбором, а проблему конфліктів — структурованим формулюванням та відбором. Усе зводиться до процесів написання, відбору, стиснення та ізоляції.
Запити системи для агентів
Формулювання запитів для агента суттєво відрізняється від формулювання запитів для чат-бота. Запит до чат-бота переважно визначає тон: бути дружелюбним, триматися коротко. Запит до агента визначає його архітектуру. Він описує логіку керування, тобто як обробляти різні типи завдань, які інструменти підходять для певних ситуацій, що робити після помилки та які обмеження безпеки діють. Це більше схоже на опис посади автономного працівника.
Anthropic говорить про необхідність написання інструкцій на належній „висоті“, тобто існує так звана зона Goldilocks. Надмірна конкретність робить систему крихкою. Уявіть правило, яке зобов’язує використовувати інструмент X щоразу, коли користувач згадує оплату, просить повернення грошей та сума перевищує сто доларів. Це правило не спрацює у кожному непередбаченому випадку. Надмірна нечіткість також є проблемою. Фраза „Будьте корисними та використовуйте відповідні інструменти“ нічого не дає агенту, адже він не знає, які інструменти підходять для чого, та не може приймати рішення без конкретних сигналів. Ідеальний варіант — це настільки конкретні інструкції, щоб вони керували автономною поведінкою, але водночас настільки неформальні, щоб модель могла застосовувати здоровий глузд у нових ситуаціях. Краще використовувати сильні евристики, а не жорсткі правила.
Кілька практичних звичок допомагають:
- Надайте структуру запиту за допомогою XML-тегів або заголовків Markdown, які розділяють контекст, інструкції та рекомендації щодо інструментів.
- Почніть з мінімуму та поступово виправляйте проблеми. Запустіть агента на реальних завданнях, визначте, де він зазнає помилок, та додайте інструкції, спрямовані саме на ці проблеми, замість того, щоб намагатися заздалегідь передбачити кожен крайній випадок.
- Мінімум — це не те саме, що короткість. Запит для складної робочої процедури може складатися з тисяч токенів, і це нормально, за умови, що кожен токен має своє значення.
- Використовуйте приклади з кількома варіантами виконання. Показ найрізноманітніших типових випадків правильного вибору інструменту, обґрунтованих міркувань та належного багатоетапного виконання краще, ніж опис кожного правила словами.
Визначення інструментів
Кожен інструмент, який можна викликати, потребує схеми, яка описує його призначення, параметри та ситуації, коли його слід використовувати. Хороше визначення є самодостатнім, стійким до помилок та чітко формулює інструкції; його вартістю є простір контексту.
У продакшені інструменти все частіше підключаються через MCP – Model Context Protocol, стандартний спосіб для агентів отримувати доступ до зовнішніх інструментів та даних. Один сервер MCP для GitHub, інший – для бази даних, ще один – для файлової системи; усі вони надають інструменти через єдиний інтерфейс. Проблема полягає у тому, що підключення інструментів стає настільки простим, що люди перестають контролювати кількість підключених інструментів. При підключенні чотирьох-п’яти серверів визначення можуть включати тисячі токенів ще до виконання першого кроку.
Загальноприйнятою порадою є створення мінімального набору необхідних інструментів. Коли агенту справді потрібно багато інструментів, ефективними виявляються два підходи.
Перший приклад походить від Manus — платформи для агентів. Вони радять не додавати та не видаляти інструменти посеред розмови з певної причини, про яку багато розробників не знають: це KV-кеш. Коли токени надходять до LLM, модель обчислює для кожного з них представлення у вигляді ключа-значення, що є дорогим процесом, тому постачальники зберігають їх у кеші. Якщо початок контексту (префікс) залишається ідентичним між викликами, постачальник використовує вже збережені дані та обробляє лише нові токени в кінці, що є швидшим та дешевшим.
Якщо змінити порядок або відредагувати початкову частину контексту між викликами, кеш стає недійсним, тож усе доводиться обчислювати заново. З Claude Sonnet вартість збережених токенів вхідних даних становить тридцять центів за мільйон, тоді як для незбережених — три долари за мільйон, що є різницею в десять разів. Агент, який виконує тридцять-сорок викликів на завдання, швидко це відчуває.
Тому Manus віддає перевагу маскуванню інструментів перед їх видаленням. Кожне визначення залишається на своєму місці в кешованому префіксі, але певні інструменти позначаються як недоступні для поточної фази. Визначення зберігаються для стабільності кешу, оскільки агент знає, що не повинен ними користуватися, а послідовні префікси імен допомагають йому класифікувати інструменти.
Другий підхід — це вибір на основі RAG, про який йшлося раніше: отримувати лише ті інструменти, які є актуальними для поточного кроку, що, як показали дослідження RAG-MCP, підвищило точність більш ніж у три рази та скоротило використання токенів удвічі. Ці два методи доповнюють один одного: маскування підходить для помірної кількості інструментів, а отримання інформації — для дуже великої кількості.
Під усім цим лежить один основний принцип. Стабільний контент розташовується у верхній частині контексту: системний запит, визначення інструментів та все, що не змінюється між етапами. Динамічний контент (історія, поточний крок, стан агента) знаходиться у нижній частині.
Етапний процес роботи, який поєднує все
Ці принципи справедливі як для готових асистентів з програмування, так і для спеціально створених агентів. Єдина різниця полягає у тому, чи ви самі структуруєте процес роботи, чи створюєте агента для цього.
Генеральний директор HumanLayer Декс Хорті виступив на конференції AI Engineer Code Summit, де описав метод, який чітко ілюструє все це. За повідомленнями, його команда використала його, щоб за одну семигодинну сесію додати близько тридцяти п’яти тисяч рядків коду до великої бази коду на мові Rust. Він називає цей метод Frequent Intentional Compaction. Робота навмисно розділена на фази; кожна фаза створює компактний результат — наприклад, структурований огляд у форматі markdown — а кожна нова фаза починається у новому вікні, яке містить лише цей результат. Це дозволяє навмисно тримати обсяг інформації приблизно в межах 40–60 відсотків від загального обсягу вікна.
Перша фаза – дослідження. Перш ніж бути написаний будь-який код, агент досліджує базу коду: читає файли, відстежує потоки даних та картує архітектуру, яка є релевантною для завдання. Підагенти виконують первинний пошук та аналіз, тож усі результати grep та вміст файлів залишаються у їхніх вікнах та ніколи не потрапляють у вікно батьківського агента. Це і є ізоляція. Результатом цієї фази є дослідницький файл – компактний документ у форматі markdown із адресами файлів, сигнатурами функцій, існуючими шаблонами та потенційними проблемами. Це вже процес запису, оскільки результати досліджень зберігаються поза вікном. Потім контекст скидається. Первинне дослідження могло займати від 60 до 80 відсотків простору вікна, тоді як готовий результат скорочує цей обсяг до приблизно 15–20 відсотків. Це і є стиснення.
Друга фаза – планування. Відкривається абсолютно нове вікно, яке містить лише файл досліджень та опис проблеми, і агент використовує цю чисту основу для складання детального плану реалізації. Це також найкраще місце для людського перегляду. Логічні помилки, виявлені тут, легко виправити, тому кожен, хто створює власного агента, повинен встановити контрольний етап з участю людини саме на цьому етапі.
Третя фаза – реалізація. Ще одне нове вікно містить лише план, і агент виконує його крок за кроком. Для завдань, які потребують кількох циклів компактування, файл progress.md фіксує, що вже виконано та що залишилося, що є ще одним кроком запису інформації.
Якась версія цього процесу використовується у більшості продакшн-систем.
Як справжні продукти обробляють контекст
Claude Code. Агент для програмування через командний рядок від Anthropic є одним із найкраще задокументованих прикладів. Він використовує гібридний підхід до пошуку інформації: файли CLAUDE.md завантажуються заздалегідь на початку кожної сесії для отримання базового контексту, тоді як інструменти на кшталт glob та grep забезпечують миттєвий пошук у кодовій базі. Він не створює попередній індекс усього контенту, а досліджує його за потребою. Функція автоматичного компактування активується при 95% використання ресурсів та зберігає архітектурні рішення разом із п’ятьма найнещодавніше відкритими файлами. Він може створювати підагентів із «чистими» вікнами для виконання складних підзавдань, а інструмент пам’яті зберігає інформацію між сесіями. Керівною філософією є виконання найпростішого способу, який працює, довіра до того, що модель сама зрозуміє, що їй потрібно, та надання їй інструментів для пошуку цього.
Manus. Це підхід, який більше орієнтований на інфраструктуру, і він має сенс для універсального агента, який обслуговує сотні тисяч користувачів, де важлива ефективність у масштабах. Його ключовою особливістю є порядок обробки даних з урахуванням KV-кешу, що забезпечує стабільність префіксів між етапами для максимального повторного використання кешу, а також використання інструментів у прихованому режимі замість їх видалення. Канал стиснення даних обробляє кожен результат роботи інструменту ще до того, як він потрапить у контекст агента. Постійний список завдань відстежує стан системи, а файлова система виконує функцію додаткової пам’яті для зберігання видалених даних контексту.
ChatGPT Agent. Агент OpenAI, який виник з Operator, архітектурно відрізняється від обох. Він базується на моделі Computer-Using Agent та обирає підхід, орієнтований на графічний інтерфейс. Замість викликів інструментів у текстовому форматі він керує візуальним браузером, а скріншоти потрапляють у контекст як знімки, над якими модель аналізує інформацію разом із історією попередніх скріншотів та дій. Це змінює характер завдань. Візуальні токени є дорогими, тому агент мусить ретельно обирати, скільки скріншотів зберігати. OpenAI використовує метод посилення навчання для знаходження ефективних стратегій використання інструментів, тренуючись на тисячах віртуальних машин, замість того щоб жорстко прописувати, коли використовувати той чи інший інструмент. Deep Research та Operator діляться станом, що дозволяє плавно переходити між переглядом, аналізом тексту та виконанням коду. Порівняно з орієнтованим на код, заснованим на інструментах для обробки тексту та маючим великі вікна Claude Code, цей інструмент є візуальним та універсальним. Обидва вимагають створення контексту, але мають різні проблеми та способи їх вирішення.
Кіт розробки агентів від Google. ADK займає найбільш принципову архітектурну позицію, передбачаючи три принципи проектування контексту для агентів. Розділяйте зберігання та відображення, оскільки стабільний стан не є тим самим, що відображається під час певного виклику API. Використовуйте чіткі трансформації, тобто іменовані, впорядковані процесори, які перетворюють контекст у тестованих, комбінованих кроках, замість спонтанного об’єднання рядків. За замовчуванням обмежуйте обсяг контексту, щоб кожен виклик моделі бачив лише мінімум необхідної інформації, і щоб ніщо не потрапляло до контексту, якщо це не було прямо включено. У результаті обробка контексту розглядається як конвеєр із чіткими етапами, а не як запит, до якого постійно додають новий текст.
Загальний конвеєр контексту
Якщо подивитися на ці платформи, на кожному кроці агента проявляється однакова структура:
- Збір кандидатів: дані від користувача, історія, результати інструментів, отримані документи та стан агента.
- Вибір того, що є релевантним для цього кроку, в межах залишкового бюджету токенів.
- Стиснення шляхом узагальнення, обрізання або переструктурування вибраного матеріалу для відповідності обмеженням.
- Впорядкування всього для повторного використання в KV-пам’яті, починаючи з постійного контенту та закінчуючи динамічним.
- Складання кінцевого контексту та виконання відповідного запиту.
Ця галузь розвивається дуже швидко, і ще є багато чого, що потрібно дізнатися, тому найкращий спосіб покращити свої навички — це експериментувати: створювати щось нове, спостерігати, де виникають проблеми, та вносити корективи.
Пов’язана література
- Інженерія контексту для додатків на основі LLM: структуровані результати, інструменти та обмеження агентів: Як свідомо формувати вхідні дані для моделі: вибір контексту, шаблони запитів, схеми JSON, обмежений декодування, виклик інструментів, цикли агентів та обмежена автономія.
- Стратегії чанкінгу для продакшн-рішень RAG: фіксований розмір, семантичний підхід та модель «батько-дитина»: Практичний огляд процесу чанкінгу в RAG від фіксованого розміру та рекурсивного розділення до моделі «батько-дитина», пропозицій, пізнього чанкінгу, технології RAPTOR, таблиць, коду та оцінки ефективності.