Я протестував дві архітектури AI-контексту: Context Discovery vs Prompt Engine. Ось що з цього вийшло

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Останні кілька місяців я розробляю власний AI-фреймворк для розробки ПЗ. Він містить інструкції для різних інженерних задач: реалізації функціональності, рефакторингу, написання тестів, дебагінгу, роботи з API, code review та багатьох дрібніших активностей. Коли фреймворк виріс до понад 100 000 символів інструкцій, одне питання стало особливо актуальним: як передати AI-агенту саме ті інструкції, які йому потрібні, не завантажуючи весь фреймворк у його контекст?

Працюючи над цією проблемою, я протестував дві різні архітектури: Agent-Driven Context Discovery та Prompt Engine with Context Compilation. Обидві дозволяють зберігати інструкції модульними та завантажувати лише те, що стосується поточної задачі. Ключова різниця між ними — у тому, хто відповідає за формування цього контексту.

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

Prompt Engine with Context Compilation переносить більшу частину цієї роботи в детермінований код. Агент усе ще визначає тип задачі, над якою збирається працювати, але після цього Prompt Engine детерміновано знаходить необхідні інструкції та компілює їх у готовий контекст. Агенту більше не потрібно самостійно шукати й завантажувати кожну інструкцію.

Спільна основа: Intent Router / Playbook

Обом архітектурам потрібен механізм, який пов’язує конкретну задачу з відповідними інструкціями. Я називаю його playbook.

По суті, playbook — це intent router. Він описує типи активностей, які підтримує фреймворк, і пов’язує їх із необхідними наборами інструкцій. Реалізація фіч, рефакторинг, написання тестів, дебаг і code review — приклади активностей, для яких можуть бути потрібні різні набори інструкцій.

У Context Discovery цей роутинг може бути частиною самого графа інструкцій. Базова інструкція говорить агенту, куди рухатися далі, а агент сам проходить відповідним шляхом.

У моєму Prompt Engine для цього використовується MCP-тулза getInstructions. Вона приймає типізовані задачі та програмно визначає, які саме інструкції потрібно скомпілювати. Таким чином, агент приймає одне високорівневе рішення — «Що я зараз збираюся робити?», — а детермінований код відповідає на низькорівневе питання — «Які саме інструкції потрібні для цієї активності?»

Підхід 1: Agent-Driven Context Discovery

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

Концептуально це виглядало приблизно так:

Task → Base Instructions → Agent → Referenced Instructions → More Instructions → Work

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

Однак після певного часу використання цієї архітектури я почав помічати відразу декілька проблем.

Проблема 1: зайве когнітивне навантаження

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

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

Проблема 2: недостатня надійність

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

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

Проблема 3: використання тулзів

Читання кожного файлу з інструкціями потребує окремого виклику тулзи. Коли понад 100 000 символів інструкцій розподілені між багатьма файлами, агент може зробити несподівано велику кількість викликів лише для того, щоб підготуватися до виконання основної задачі.

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

Проблема 4: неефективне використання контексту

Ще одна проблема полягає в тому, що роутинг-інструкції залишаються в контексті агента значно довше, ніж вони реально потрібні. Інструкції на кшталт «прочитай цей файл», «для цієї активності також прочитай той файл» або «якщо виконується ця умова, завантаж додаткові інструкції» корисні під час Context Discovery, але майже не мають цінності після того, як агент почав виконувати саму задачу. Від цього моменту вони просто займають місце у контексті.

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

Інакше кажучи, чим більше зусиль ви витрачаєте на те, щоб зробити Agent-Driven Context Discovery надійним, тим більше контексту можете витрачати на інструкції, які стають непотрібними одразу після завершення discovery.

Підхід 2: Prompt Engine with Context Compilation

У другій реалізації я виніс формування інструкцій з агента в код.

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

Архітектура тепер виглядає приблизно так:

Task → Activity → Prompt Engine → Compiled Context → Agent → Work

Зміна може здатися невеликою, але на практиці результат виявився суттєвим. Щойно агент обирає інструкцію, решта процесу стає детермінованою. Якщо для задачі X потрібні інструкції A, B, C і D, Prompt Engine гарантовано передасть усі чотири. Більше немає проміжного кроку, на якому агент може забути відкрити C або вирішити, що D йому не потрібна.

Формування контексту також стало значно швидшим. Замість послідовності запусків тулзів, читання файлів один за одним і роздумів щодо того, що потрібно завантажити далі, агент робить один запит. Prompt Engine програмно проходить граф інструкцій і повертає скомпільований контекст за одну операцію. Це прибирає як затримки від послідовних викликів тулзів, так і rзайве когнітивне навантаження, пов’язане із навігацією структурою інструкцій.

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

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

Але все має свою ціну, і цей підхід — не виняток. Разом із перевагами Prompt Engine приносить додаткову складність і кілька нових проблем, які доводиться вирішувати.

Проблема 1: Prompt Engine перетворюється на мініпродукт

Перший недолік — додаткова інфраструктура. У моєму випадку Prompt Engine потребує власного MCP-сервера, який надає агенту тулзи для отримання інструкцій. Щойно ви додаєте цей шар, у вашому репозиторії фактично з’являється ще один невеликий програмний продукт.

Як і будь-який інший софт, його потрібно підтримувати. Треба стежити за якістю реалізації, обробляти едж кейси і, в ідеалі, покрити критичну поведінку автоматизованими тестами. У міру розвитку системи інструкцій разом із нею має розвиватися й Prompt Engine.

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

Проблема 2: можна випадково створити два джерела істини

Ще одна складність — представлення інструкцій. Формат, зручний для програмної обробки, не обов’язково буде зручним для людини. Наприклад, Prompt Engine може бути зручніше працювати зі структурованим JSON, тоді як я волів би читати, писати, рев’ювати та підтримувати ті самі інструкції у Markdown.

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

Краща архітектура повинна мати одне канонічне джерело та детермінований спосіб генерувати з нього інше представлення. В ідеалі обидва формати також мають залишатися структурно достатньо схожими, щоб ви могли дебажити JSON, який отримує агент, читаючи зручний для людини Markdown. Інакше зручність двох представлень швидко перетвориться на ще одну проблему з підтримкою.

Проблема 3: скомпільовані інструкції можуть забруднювати контекст

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

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

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

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

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

Важливий нюанс: один недетермінований крок усе ще залишається

Ця архітектура не робить абсолютно все детермінованим. Агент усе ще має правильно вибрати тип задачі під час виклику getInstructions, а цей вибір уже є рішенням LLM.

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

Я також рекомендую уважно спостерігати за роутингом після впровадження такої системи. Дивіться, які активності агент обирає для реальних задач, і коригуйте плейбук, коли знаходите неоднозначні випадки. У моєму фреймворку, за суб’єктивною оцінкою, неправильний вибір активностей трапляється менш ніж у 1% випадків, а можливо, навіть менш ніж у 0,5%, тому на практиці це не стало для мене суттєвою проблемою.

Висновок

Після роботи з обома архітектурами для мене Prompt Engine with Context Compilation перемагає з великим відривом.

Насправді різниця тут не стільки в промптах чи файлах.

Головне питання:

Які обов’язки варто залишити LLM, а які краще передати традиційному софту?

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

• Context Discovery змушує LLM займатися і тим, і іншим.
• Prompt Engine дозволяє провести межу між цими зонами відповідальності значно чіткіше.

Цей експеримент зрештою став одним із джерел ширшого принципу, який я зараз використовую у своєму Semi-Automatic AI-Native Flow with a Human in the Loop: якщо щось можна надійно виконати детермінованим кодом, я намагаюся винести це за межі відповідальності агента.

Для мене це стає одним із найцікавіших питань AI-native розробки.

Ми багато говоримо про те, скільки ще відповідальності можна передати AI-агентам.

Можливо, не менш важливе питання — скільки відповідальності ми можемо в них забрати?