Інженерія запиту, контексту, керування та циклу: чотири шари штучного інтелекту-агента
Інжиніринг запитів та інжиніринг контексту охоплюють два з чотирьох рівнів. Що контролюють інжиніринг керування та інжиніринг циклів, приклад триажу в GitHub та порядок збірки.
Джерела: Prompt, context, harness, loop: the four layers of engineering an AI agent
У середині 2025 року генеральний директор Shopify Тобі Лютке написав, що справжнім навиком у роботі з ШІ на основі тексту зовсім не є інжиніринг запитів, а надання достатньої кількості контексту, щоб завдання можна було розумно вирішити. Андрей Карпаті погодився з цим, назвавши це мистецтвом, яке полягає у точному включенні потрібної інформації у вікно контексту для подальших дій моделі. Невдовзі після цього термін «інжиніринг контексту» замінив «інжиніринг запитів» у більшості серйозних обговорень щодо розробки продуктів на основі ШІ на основі тексту.
Через рік команди, які розробляють автономних агентів для кодування, ботів для класифікації проблем та системи самовідновлення пайплайнів, продовжують стикатися з тією самою перешкодою. Виявилося, що інженерія контексту — це лише один із елементів чотиришарової проблеми. Від найвужчого до найширшого ці шари — це підказка, контекст, інструментарій та цикл, причому кожен з них охоплює шар, що знаходиться всередині нього. Два зовнішніх шари — інженерія інструментарію та інженерія циклу — отримують найменше уваги, що дивно, адже саме тут зараз знаходиться більша частина користі.
Уявіть собі це як чотири запитання. Як сформульовано запит? Це підказка. Що модель вже знає на початку роботи? Це контекст. Що вона насправді може робити під час роботи? Це інструментарій. А коли та як часто хтось її викликає? Це цикл. Сьогодні більша частина справжньої користі знаходиться у циклі — шарі, який рік тому ледве мав назву.
Далі наведена робоча схема для розрізнення різних шарів, а також порядок їх створення. Вона передбачає, що ви вже виконували виклики інструментів чи функцій через API LLM. Якщо ні, почніть саме з цього.
На практиці спостерігається певна закономірність, яка пояснює корисність цієї схеми. Коли результат роботи агента є незадовільним, проблема майже ніколи не полягає у запиті; вона завжди знаходиться на рівень вище.
Шар 1: запит, або те, що ви кажете
Інженерія запитів — це найвужчий шар, який стосується лише однієї речі: того, як сформульовано інструкцію для моделі.
Приклади: як сформульовано системний запит, як оформлено зразок для кількох спроб, чи просите ви поетапного міркування чи ретельного аналізу, а також чи має відповідь надходити у форматі JSON чи у вигляді вільного тексту. Це мистецтво написання одного повідомлення, яке змусить модель виконати бажане на наступному кроці.
Робота є реальною. Точність виконання однакового завдання може суттєво відрізнятися між розпливчастою та чіткою інструкцією. Візьмемо агента для триажу в проекті GitHub як приклад. Слабкий запит виглядає ось так:
Look at this GitHub issue and label it.
І точний варіант:
You are a triage agent for project X. For each issue, output JSON with:
component (one of the values in the taxonomy provided in context)
severity (critical | high | medium | low)
team (the owning team from the on-call table provided in context)
Base severity only on user-facing impact stated in the issue, not on your
own guess about difficulty. If the component is ambiguous, set
"component": "unknown" rather than guessing.
Модель, інструменти та все інше залишаються ідентичними, проте другий запит дає структурований, обґрунтований результат. Однак варто звернути увагу на те, що вважається само собою зрозумілим. Він виконується протягом одного кроку одного виклику. Він передбачає, що таксономія та таблиця доступних інструментів вже завантажені, що інструменти існують, та що щось інше вирішує, коли модель буде запущена.
Більшість навчальних матеріалів закінчуються на цьому етапі. Більшість систем продакшн-агентів лише починають працювати на цьому рівні.
Рівень 2: контекст, або те, що знає модель
Інженерія контексту охоплює все, що потрапляє до „вікна“ перед тим, як модель аналізує ваш запит. Вона знаходиться на етапі, що передує обробці запиту. Навіть ідеальний запит дасть некоректний результат, якщо контекст неправильний.
Це включає визначення того, які документи, файли коду чи записи бази даних отримуються та вводяться, які схеми інструментів завантажуються, а які залишаються для збереження токенів, скільки історії розмови зберігається порівняно з тим, що її узагальнюють чи видаляють, а також що говорять інструкції системи про роль та обмеження моделі.
У 2025 році Дрю Бройніг описав способи збою контексту. Токсичність контексту виникає, коли галюцинація потрапляє до області розгляду та постійно посилається на неї. Відволікання контексту відбувається, коли надто довга область розгляду змушує модель покладатися на неї та ігнорувати те, що вона навчилась під час навчання. Плутанина контексту виникає, коли нерелевантний матеріал погіршує якість результату. Конфлікт контексту виникає, коли ново додані інструменти чи факти суперечать існуючим інструкціям.
Контекст також коштує грошей, і його кодування впливає на суму рахунку. TOON – це компактне кодування моделі даних JSON; за даними на середину 2026 року, у власних тестах цей формат використовує приблизно на 42,6% менше токенів, ніж JSON, при цьому точність пошуку становить близько 72,2% проти 71,4%. Економія залежить від форми даних: для плоских табличних даних вона сягає майже 59%, для змішаних вкладених даних – близько 33%, а звичайний CSV може перевершити обидва формати, коли дані є суто плоскими. Це дані самого проекту, тож перевірте їх на власних даних. Висновок полягає у тому, що одні й ті самі дані, представлені у трьох форматах, відрізняються за ціною та ступенем надійності їх обробки. Інженерія контексту означає не лише вибір того, що включати, а й способу його кодування.
Коротка ілюстрація показує, як це може піти не так. Уявіть агента для створення статей, який постійно генерує універсальний контент. Два дні витрачаються на переписування запиту, додавання прикладів та обмежень, а також на уточнення визначення ролі, але нічого не змінюється. Проблема ніколи не була у самому запиті. Заздалегідь завантажується тридцять схем інструментів, які заглушають відповідні інструкції. Перехід на ліниве завантаження, коли визначення з’являється лише тоді, коли агент його запитує, покращує якість без зміни жодного слова у запиті. Два дні були витрачені на неправильний рівень.
Якщо інженерія запитів стосується вибору слів, то інженерія контексту — вибору того, що модель може побачити ще до того, як ви щось скажете.
Рівень 3: середовище виконання, або те, що може робити модель
Середовище виконання — це середовище навколо моделі, у якому вона може працювати: все, до чого вона може дістатися, та все, що впливає на неї.
Відомі рекомендації Anthropic щодо створення ефективних агентів ввели ідею інтерфейсу агента та комп’ютера, навмисно схожого на інтерфейс людини та комп’ютера. Автори стверджують, що слід докладати стільки ж зусиль до проектування способу, яким агент працює з інструментами, скільки індустрія докладає зусиль до того, як люди працюють із програмним забезпеченням.
Ось спрощене визначення інструменту з прикладу триажу:
{
"name": "apply_label",
"description": "Apply a label to a GitHub issue. Only use after reading the issue body and checking the component taxonomy.",
"parameters": {
"type": "object",
"properties": {
"issue_number": { "type": "integer" },
"labels": { "type": "array", "items": { "type": "string" } }
},
"required": ["issue_number", "labels"]
}
}
Поле description виконує функції, пов’язані з контекстом. Воно визначає, коли модель має використати інструмент, а не лише які аргументи вона передає. Проте схема є лише половиною всієї структури.
Інша половина знаходиться в оркестраторі, який оточує інструмент елементами, які модель ніколи не бачить. Механізм схвалення вирішує, чи має apply_label запрацювати автоматично, чи потрібно передати завдання людині. Обмеження швидкості, наприклад 60 записів міток на годину, запобігають неконтрольованому циклу, який може заспамувати репозиторій. Межі пісочниці обмежують те, до чого може дістатися інструмент. Такі обгортки формують поведінку без жодних змін у системному запиті.
Структура також включає:
- Файлову систему. Файли, які модель може відкривати, редагувати, створювати чи видаляти.
- Пам’ять. Спосіб зберігання та отримання інформації протягом різних етапів роботи, такий як журнали корекцій, попередні рішення та стандарти проекту.
Якщо надати звичайному запиту хороші інструменти, він зазвичай буде працювати краще, ніж блискучий запит без інструментів. Агент, який не може відкрити необхідний файл, не отримає жодної користі від кращої формулювання. Спочатку забезпечте необхідні інструменти.
Рівень 4: цикл, або що робить агента автономним
Інженерія циклів — це механізм, який робить агента автономним. Він діє, спостерігає за результатом, вирішує, що робити далі, і продовжує це робити, поки не буде досягнуто мети або не спрацює умова зупинки, без будь-яких вказівок з боку людини на кожному кроці. Цей рівень перетворює чат-бота, який використовує інструменти, на систему, здатну самостійно вирішувати проблеми.
Ось та сама ідея у псевдокоді. Це ілюстративний приклад, який не можна запустити: допоміжні функції на кшталт model.decide та execute не включені.
def agent_loop(goal, max_iterations=10):
context = gather_initial_context(goal)
consecutive_errors = 0
for i in range(max_iterations):
action = model.decide(context, goal)
if action.type == "done":
return action.result
result = execute(action)
if result.error:
consecutive_errors += 1
if consecutive_errors >= 3:
# stuck: same approach keeps failing, decompose differently
context.add("Previous approach failed 3 times. Try a different strategy.")
consecutive_errors = 0
else:
consecutive_errors = 0
context.add(result)
return escalate_to_human(context)
Кілька рядків містять вирішальні рекомендації: коли зупинитися, коли змінити підхід, коли здатися. У квітні 2026 року OpenAI вбудував цю схему у продукт, додавши команду /goal до Codex CLI. Ви встановлюєте мету, а система продовжує працювати, поки не вирішить, що мета досягнута, або не вичерпає бюджет токенів.
Примітивний цикл продовжує спроби, поки щось не спрацює. Добре спроєктований цикл помічає, що застряг, розбиває проблему по-іншому, звертається за допомогою до людини або відмовляється від невдалих підходів. Дизайнер Метт Вебб у березні 2026 року зазначив, що агент, якому дано проблему та цикл while, зрештою її вирішить. Саме слово „зрештою“ визначає рівень інженерної реалізації: ліміти на спроби, затримки після повторних невдач та стратегії розбирання проблеми у випадку, коли одна спроба не дає результату.
Саме тому цей шар є найбільшою зміною у розподілі повноважень. За допомогою інженерії запитів людина пише кожну інструкцію. За допомогою інженерії контексту людина вирішує, що бачить модель під час кожного виклику. За допомогою інженерії інструментів людина створює інструменти один раз, а модель використовує їх необмежено. Інженерія циклів відрізняється за своєю суттю: людина розробляє систему, яка формулює запити до моделі, оцінює результат та знову її викликає, причому в кімнаті нікого немає. Контроль переміщується від того, хто формулює запити до агента, до того, хто розробив систему, яка їх формулює.
У середині 2026 року Джон Уделл запропонував формулювання, яке варто запам’ятати: йому не подобається вираз „людина в циклі“, тому що він надає владу машинам, хоча насправді це все ще наш цикл, і ми тепер залучаємо агентів до команди.
Усі чотири шари в одному агенті: сортування запитів у GitHub
Уявіть агента, який обробляє нові проблеми у GitHub для проекту з відкритим кодом середнього розміру: він називає компонент тегом, оцінює ступінь серйозності та надсилає кожну проблему відповідній команді.
- Інструкція. Системна інструкція просить його знайти постраждалий компонент, оцінити ступінь серйозності від критичної до низької, призначити відповідну команду та надати відповідь у форматі структурованого JSON.
- Контекст. Для кожного рішення система надає заголовок та текст, п’ять останніх коментарів, таксономію компонентів (файл YAML, який оновлюється щокварталу), попередні схожі проблеми з їхніми мітками (отримані за допомогою векторного пошуку як приклади) та інформацію про того, хто зараз на зв’язку.
Кожні 100 випусків система порівнює свою точність із результатами роботи людини та коригує свої порогові значення. У схожій системі, за повідомленнями, порогове значення довіри мусило починатися з 0,85, а не з припусканих 0,7, оскільки неправильні позначки створювали більше роботи для людини, ніж пропущені. Такий тип калібрування є частиною інженерії циклів: його можна виявити лише шляхом запуску системи та спостереження за її помилками з часом.
Якщо видалити будь-який з елементів, система буде працювати інакше. Без вказівок формат вихідних даних залишається припущенням. Без контексту імена компонентів вигадуються. Без необхідних інструментів система може з’ясувати, що робити, але не може позначати чи шукати. Без циклів у вас залишається асистент, який діє лише тоді, коли хтось вводить у вікно чату фразу „розглянути цю проблему“, по одній за раз.
Звідки береться словниковий запас
Термін „інженерія запитів“ з’явився у 2022 році. У 2023 році Райлі Гудсайд запропонував розділити його на інженерію контексту та програмування запитів, але цей термін набув поширення лише після того, як у червні 2025 року Лютке та Карпаті використали термін „інженерія контексту“, а Саймон Віллісон пояснив, чому він краще підходить.
Терміни „використання“ та „конструкційні елементи“ увійшли до стандартного вжитку завдяки роботі Anthropic над ефективними агентами, яка сформалізувала інтерфейс агента та комп’ютера та розглядала проектування інструментів як інженерну задачу першого класу.
Інженерія циклів є наймолодшою з чотирьох та не була створена ніким конкретним. Вона виникла внаслідок поєднання кількох підходів: цілеспрямованих циклів у Codex від OpenAI, розділення на робочі процеси (фіксовані шляхи) та агентів (цикли, керовані моделлю) від Anthropic, еволюції LangChain від маршрутизатора до машини станів до автономного агента, а також поширеної практики, коли людина проектує цикл та не втручається під час його окремих етапів.
Це чотирирівневе розділення є синтезом цих поєднаних підходів, а не стандартом галузі. Проте найменування рівнів прискорює діагностику. Запитання про те, чи проблема пов’язана з запитом, контекстом, інструментарієм чи циклом, негайно звужує коло пошуку.
Де інвестувати спочатку
Рівні перелічені від найвужчого до найширшого, але їх будують спочатку у найширшому вигляді, а точніше — спочатку інструментарій. Для першого автономного агента для програмування порядок є наступним.
- Інструментарій. Має забезпечувати можливість читання та запису файлів, доступ до шелу, спосіб виконання тестів та команд git. Агент, який не програмує, отримує замість цього API-запити, запити до бази даних чи можливості обміну повідомленнями; ідея залишається такою ж.
- Цикл. Навіть примітивний цикл допомагає: виконати дії, перевірити, чи пройшли тести, у разі невдачі повернути помилку, а після трьох спроб чи при успіху завершити роботу. Вже це саме по собі забезпечує більшу частину переваг автономності.
- Контекст. Спостерігаючи за роботою агента у його циклі, ви зрозумієте, чого йому бракує — чи то коду, попередніх помилок чи стандартів проекту. Здогадування заздалегідь здебільшого марнує час.
- Запити. За наявності функціонального інструментарію та циклу запити, які потрібні, зазвичай є короткими та простими. Складна інженерна робота вже виконана раніше.
Є один виняток. Якщо агенту потрібно створювати вихідні дані у точно визначеному форматі, наприклад структурований JSON для API чи дотримання певних конвенцій Markdown, робота з запитами має бути проведена на ранніх етапах, адже дотримання формату важко виправити під час виконання циклу. Це особливий випадок, а не стандартна ситуація.
Початківці зазвичай змінюють порядок дій: тижні витрачаються на складні запити до системи, тоді як у агента ще немає інструментів, циклу та неправильні файли в його контексті.
Перехід від роботи з запитами до проектування контексту означає визнання того, що матеріал, наданий моделі, має більше значення, ніж формулювання запиту. Перехід до розробки інструментів та циклів означає ще більше поступок: той, хто створює систему навколо моделі, має більше влади, ніж той, хто з нею спілкується.
Пов’язана література
- Інженерія контексту агента: Покроковий посібник для інженерів машинного навчання: Як спроєктувати те, що бачить агент LLM на кожному кроці: отримання інформації, структурований контекст, пам’ять, стиснення та оцінка, з прикладом агента для виправлення помилок у машинному навчанні.
- Від zero-shot до самоконсистентності: Практична ієрархія технік формулювання запитів: Як вибирати між методами zero-shot, few-shot, декомпозиції, циклами критики та запитами для міркувань, з прикладом бота підтримки, та коли краще використати звичайний код.