Галоўная / Артыкулы

Інжынерыя промпту, кантэксту, абвязкі і цыкла: чатыры ўзроўні AI-агента

Промпт- і кантэкст-інжынерыя пакрываюць два з чатырох узроўняў. Што кантралююць інжынерыя абвязкі і цыкла, прыклад сартавання ў GitHub і парадак пабудовы.

Выдавец: REACTAPP.TOP12 хв чытання2707 слоў

Крыніцы: Prompt, context, harness, loop: the four layers of engineering an AI agent

У серэдзіні 2025 года гэнеральны дырэктар Shopify Тобі Лютке напісаў, што справжняя навык у рабоце з LLM-амі зовсім не ў складзе запросаў, а ў тым, каб запропанаваць достатню кантэкстную інфармацыю, якая дазволіла б задачу рашыць правдападобна. Андрэй Карпаты пагадаўся, назваўшы гэта мастактвам, якое заключаецца у тым, каб точна падаць правяльную інфармацыю ў вікно кантэксту для таго, калі мадэль будзе далей працаваць. Нечытаўсця пасля гэтага «інжынерыя кантэксту» заменіла «інжынерыя запросаў» у большасці серйозных дыскусый пра развіцце тэхналогій на базе LLM-аў.

Пасля года команды, які ствараюць автонамных агентаў для кодавання, ботаў для аналізу проблем і сістэм для самовылікованага запуску, продавжаюць сталквацца з тым самым працоўным прыемлівам. Адзін з аспектаў чатырхслойнай проблемы аказаўся інжыніерыяю кантэксту. З самага вузкага да самага шырокага слоі ўтвараюцься прапт, кантэкст, інструментарый і цыкл, пры чым кожны з іх абгружае слой, які знаходзіцца ўнутры. Два зовнішніх слоі — інжыніерыя інструментарыя і інжыніерыя цыкла — атрымоўваюць наіменшу увагу, што ўзяточна, адколі саме тут зараз знаходзіцца большая частка рэальных выгод.

Можна спакульваць гэта як чатыры пытанні. Як сформульавана просьба? Цэе і ёсць прапт. Чы што мадэль ведае ўжо з самага пачатку? Цэе і ёсць кантэкст. Чы што ёна можа робіць пасля запуску? Цэе і ёсць інструментарый. А калі і як часта хтось яе вызывае? Цэе і ёсць цыкл. Сэрцам рэальных выгод сёньня ёсць цыкл, слой, які ўжо год назад ледзь меў сваё назва.

Гэтая частка паказвае рабочую структуру для разгранічэння разных слоёў, а таксама парадак ўтварэння. У яй прыпускаецца, што вы вялікі час вжо выканалі вызывы інструментаў або функцый у 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)
    

    Калькі лініі маюць важлівыя рашэнні: калі зупініцца, калі змяніць тактыку, калі здацца. Компанія OpenAI увеліла гэты прыем у продукт, дадавшы команду /goal у Codex CLI у красаві 2026 года. Вы задаеце мету, а сістэма продовжае працаваць, пакуль не вырашыць, што мета досягнута, або пакуль не скончыцца бюджэт токенав.

    Проста петля працуе, пакуль ўсё не запрацюе. Якша спраектаваная петля разгледзіць, што застрагла, іншым способам раскладзе проблэму, перадае ёю адпаведальнасць чалавеку або абандонуе яе. Дызайнер Мэтт Вэбб у красаві 2026 года зазначыў, што агент, якому даюць проблэму і петлю while, зрэшты яе рашыць. Слова "зрэшты" паказваюць, дзе заключаецца інжынерная частка: ліміты павторных спроб, адкладэнне дзеяння пасля паўтараючыхся няудач і стратэгіі раскладання проблэмы, калі адна спроба застрагае.

    Осё гэта прычына, чырвоны шырокія змяны ў распадзеле влады. У разе інжыніерыі запросаў чалавек піша кожную інструкцыю. У разе інжыніерыі кантэкста чалавек адлучвае, што бачыць мадэль праз кожны вызов. У разе інжыніерыі інструментаў чалавек стварае інструменты аднойчы, а мадэль вялікі час іх воспаловае. Інжыніерыя цыклаў разлічнае па характары. Чалавек праектуе сістэму, якая даўае запросы модэлі, ацэнюе рэзультат і зноў яе вызывае без жаднага чалавека ў кімнаце. Контроль пераходзіць ад таго, хто даўае запросы агенту, да таго, хто праектаваў сістэму, якая іх дае.

    Джон Удэл у серэдзіне 2026 года запропанаваў формулівацыю, якая варта запамятаць: ёму не падабаецца фраза "чалавек у цыкле" , бо яна перадае адпаведальнасць машынам, хоця на самай працы цыкл застаецца нашым, і мы цяпер запрошаемі агентаў прыўяжыцца да команды.

    Усе чатыры слоі ў аднам агенце: сортаванне пытанняў у GitHub

    Уявіце агента, які рашуе новыя проблемы на GitHub для праекта з адзёрнай ліквіднасцю: ён прызначае тэгі компаненту, ацэнюе ступень сер’ёзнасці і надае кожную з іх правам камандам.

    • Інструкцыя. Інструкцыя сістэмы паведамляе яму знайсці паражнуты компанент, ацэніць ступень сер’ёзнасці ад крытычнай да нізкай, прызначыць правую каманду і адпаведзець у фармаце структураванага JSON.
    • Кантэкст. Для кожнага рашэння сістэма надае заглавле і тэкст, пяць найсвежэйшых каментароў, таксанамію компаненту (файл у фармаце YAML, які пераглядаецца кожны квартал), ранейшыя падобныя проблемы з ўсіма ўпісамі (знайдзеныя за дапамогою вектарнага пошуку як прыклады) і таго, хто зараз працуе.
  • Апранак. Агент можа чытаць проблему праз API GitHub, шукаць у базе коду, каб парадактуваць, які компаненты ўчаствуюць, запытваць вектарную базу дадзей пра пакульныя рашэнні па класыфікацыі, прызначаць атрыбуты, падставляць каментары, якія пояснююць яго падход, і назначаць члена команды. Ён таксама зберагае інформацыю пра саве рашэнні, якія пазней былі змененыя людзьмі, тады як можа выучыцца на гэтых парадактуваннях.
  • Цыкл. За кожнай новай проблеме запускаецца webhook, і оркестратор пачынае працэс класыфікацыі. Агент чытае проблему, збірае неабходную інфармацыю, прыме рашэнні і яго аплікуе. Калі рэвальянс рашэнні падыходзіць ніжэй за заданы порог, проблема фіксуецца на перагляд чалавеком, і агент не прызначае атрыбуты автаматычна.
  • Кожныя 100 выпускаў сістэма парабягае свою точнасць з ручнымі корэктаваннямі і налаштоввае сваі порогі. У падобной сістэме, як ствараецца, порог абданосці павінен быў пачынацца з 0,85, а не з прыпускаемых 0,7, таму што некарэктныя атрыбуты стваралі больш працы для людзяў, чым тыя, якія былі працягнуты. Такая калібрацыя — цэла праца з цыкламі: яе можна знайсці толькі прабаваючы працаваць з сістэмай і стэжычы за ўсімі яе памылкамі з часам.

    Як толькі аднаковы слой знікне, сістэма будзе выконваць задачы інакш. Без паведамлення фармат выходных даных застаецца прыпушчэннем. Без кантэксту імена складовых ствараюцца наспрачатку. Без спецыяльных інструментаў сістэма можа з’ясаваць, што робіць, але не можа атрыбутаваць чы шукаць. Без цыкла застаецца толькі асістэнт, які дзейнае толькі тады, калі хтось у вікні чату запішае „працаваць з гэтым пытаннем“, і то адна за адной.

    Звыклівкі, з якіх выходзіць слоўнік

    Тэрмін „prompt engineering“ пачаў іспользовацца у 2022 годзе. У 2023 годзе Райлі Гудсайд запропанаваў раздзеліць яго на „context engineering“ і „prompt programming“, але гэты тэрмін стаў популярным толькі пасля таго, як у чэрвені 2025 годзе Лютке і Карпаты вывучылі тэрмін „context engineering“, а Саймон Віллісон поясніў, чаму ён болей падходзіць.

    Тэрміны „Harness“ і „scaffolding“ сталі стандартнымі заўдовжка работы Anthropic над эфектывнымі агентамі, якія формалізавалі інтэрфейс агента і камп’ютара і расследжвалі дызайн інструментаў як важлівую частку інжынернай працы.

    Інжынерыя ціклаў ёсць наймоладшай з чатырох, і ніхто яе не створыў. Яна выклікана саюзам калькі спроб: мета-орыѐентаваны цікл OpenAI у Codex, раздзелленне Anthropic между рабочымі практыкамі (фіксаваныя шляхі) і агентамі (цікламі, кія керуе мадэль), розвіцце LangChain ад рутэра да машыны станоў да автонамнага агента, а таксама практыка, калі чалавек праектуе цікл і не втручаецца ў кожны з яго крокаў.

    Чатырох-шаровы раздзел тут ёсць сынтэзам гэтага саюзнага выкарыстання, а не стандартам промышленасці. Тым не менш, называнне шароў прышвырчвае дыягназу. Запытанне, чыі гэты проблема — з прапантаў, кантэксту, інструментаў або цікла, негайна скарочывае пошук.

    Дзе інвеставаць перш

    Шары былі пераказаны з найвужэйшага да найшырэйшага, але яны будуюцца спачатку шырэйшымі, а точней — спачатку інструментамі. Для першага автонамнага агента для кодавання парадак выглядае так.

    1. Інструментарыя. Неабяжна можлівасць чытання і запісу файлоў, доступу да шэлу, спосабу запуску тэстаў і каманд git. Агент, які не кодуе, заместа гэтага выкананыя API-запыты, запыты да базы дадзеных або перадача паведамленняў; ідэя застаецца тая ж.
    2. Цыкл. Нават просты цыкл дапамагае: запусціць, паказаць, чы рэалізаваліся тэсты, адразу вернуць памылку, калі не рэалізаваліся, і завершыць працу пасля трох гаспрабаванняў або пасля успеху. Ужо сама гэта дае большую частку прынадзей автонаміі.
    3. Кантэкст. Пасля таго, як вы пазіралі, як агент працуе ў сваім цыкле, вы пазнаеце, чаго ў яго не хапяе — чы то коду, пакульшых памылак або стандартаў праекту. Згадкі загадзя зазвычай толькі вядуць час.
    4. Запыты. Калі інструментарыя і цыкл працуюць, запыты, якія патрэбны, зазвычай ўсунутыя і простыя. Складная інжынерная частка ўжо была адварыта ў іншым месцы.

    Ёсць адзін выключэнне. Калі агенту трэба стварыць выход з точна сформатаваным тэкстам, напрыклад структураваны JSON для API або па спецыяльным стандартам Markdown, ранній етап працы з запітамі мае важлівэе значэнне, адколі дапамога ў дапамозе са стыкамі фармата ёсць складной у момент выканання цыклу. Цэта спецыяльны случай, а не стандартна сітуацыя.

    Новачкі часта пераставляюць парадак дзеяння. Недзелі вітрачаюцца на стварэнне выразных запітоў для сістэмы, пакуль у агента ўсё ўсё ж няма інструментаў, цыклу, а ў яго кантэксце знаходзяцца некарэктныя файлы.

    Пераход з працы з запітамі на праектаванне кантэкста означае прызнанне таго, што матэрыял, які падаецца модэлю, мае большое значэнне, чым формулюванне запіту. Пераход да праектавання інструментаў і цыклаў паставляе ўсё большых прывілеяў: той, хто стварае сістэму, якая абрамляе модэль, мае большую владу, чым той, хто з яй паводзіцца перамовы.

    Супаўзялыя матэрыялы

  • Prompt, Context, Harness, Loop: Чатыры слоі, якія стояць за AI-агентамі: Разлагальная адпаведная інструкцыя пра тое, як працуюць агенты: што дадаюць прампты, як выбіраецца кантэкст, што ўключаецца ў „харнес“ і якія ёсць ціклы, і чаму кожны слой неабходны, калі попераднія недастатковы.
  • Інжынерыя „харнеса“: Сераўак, які робіць AI-агенты надзеянымі: Што такое інжынерыя „харнеса“, яе шасць складовых і тры основы, як гэты тэрмін з’явіўся у 2026 годзе, і дзевяць прынцыпаў дызайну для прыменных агентаў.
  • Распрацоўка абмежаных вікнаў кантэксту ў агентах AI: 7 практычных стратэгій: Сэм спробаваных спосабоў для таго, каб агенты AI, якія працуюць дзялейна, заставаліся ў своім вікні кантэксту: стысненне, адсечка даных, пераказваўка задач у інструменты, настройкі сістэмы, спецыяльныя механізмы керування, стыснуты выход і вікна з рухомымі межамі.
  • Інжынерыя кантэксту для агентаў AI для кодавання: чаму большыя вікна не дапамагаюць: Чаму вікно на мільйон токенаў не рашаіць проблему агентаў для кодавання, і як бюджэты токенаў, графы рэпазітарыяў і шаравая памяць даўаюць ім правільны кантэкст уместа большай колькасці інфармацыі.
  • Дзесяць галоўных памылак у інжынерыі запросаў, якія дзеяна распрацоўшчыкамі, і способы іх выправлення: Дзесяць распашчацыхся памылак у формулюванні запросаў — ад нечыста сформульаваных просьб і відсутнасці кантэксту да слепай доверы да рэзультатаў; кожная з іх супакоўвана конкрэтным прыкладам запроса ў фармаце «до/пасля», які можна перыскорыць.