Навчанне інжынерыі агентных AI за принцыпам, якія вучаюць іх на адной неудачы.

Разработчыкі, які пераходзяць на адміністрацыю агентаў, часта прагначу прыняць усе фреймворкі адразу, перабіраючы LangChain, CrewAI, AutoGen і LangGraph за адну тыждзень, не стварыўшы нічога. Проблема крыўцяе ў правільной последовасці: яны вивучаюць інструменты раней, чым разумеюць проблемы, якія тыя інструменты ствараны для запобежэння. Шырокі путаўнік паказвае чотырнаццаць крокаў у той порядак, у яком навыки насправдзе будуюцца адна ў адной, ад базовага Python да стварэння агента, які працуе без нагляду. Па дорозе вы дазнаецеся пра тры спосабы падвярнення, якія вплываюць на кожнае дзейство пад час проектавання, пра мінімальны набор аб’ектаў, якія падходзяць для большай часткі роботы ў працэсе виробніцтва, а таксама пра структурныя шаблоны (файлы стану, перагляд з боку творця і пераказчыка, шаровая ацэнка і встановленне прав) , якія розлучаюць дэманстрацыю з системай, якой можна даверыць адразу.

Частка 1: Ментальная модель

1. Адміністрацыя агентаў — гэта не інжынерыя промптав з новай назвой

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

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

Гэта прыносіць трое абавязакоў, якіх ніколі не было ў работе з запросамі:

• Адрабатаванне памылак як ключовая проблема. Агенты постоянна падаюць: API-я выкананыя за час, JSON вяртаецца з некоректным форматам, модель выдумвае вызовы інструментаў, а выходныя даны інструментаў не паспеліваюць схемам. Код, які прыпускае успех, зламаецца у найгоршы момент, як правілу, пад час дэманстрацыі.
• Карацеўніцтва стану. Одын вызов LLM нічога не зберагае. Агент, які выкаанавляе дзесяць крокаў вызоў інструментаў, перапрыбуткі і падагентаў, патрэбуе структураванага, стойкага стану, який застоіцца пасля заканчэння кожнага контекстовага вікна.
• Інтэграцыя ацэнкі ў інфраструктуру. Не існуе інтуіцыі, якая паведамляла б вас, чы робіць агент правільна. Патрэбны автаматызаваныя механізмы, такія як тэсты, критэрыя ацэнкі чы модель суддзі, якія адхроюць паслабы выходныя даны без неабходнасці перагляду кожнага запуску чалавеком.

Апісанні вакансый для гэтых паведамленняў часта выглядаюць як каталог. Фрамворкі для оркестрацыі (LangGraph, LangChain, LlamaIndex), пратакты (MCP, A2A), атрыбуты модэляў (выклік функцый, структураваныя выходны данны, кэшаванне запитоў), методы выкарыстоўвання дадзеных (RAG, RAGAS, гібрыдны пошук, переранкаванне, модэлі імбеддынгу, вектарныя та графавыя базы дадзеных) а таксама канцэпты, неабходныя для ўпрацоўкі (выкананне ў ізольаваных сэрвісах, можлівасць адзорвання, ацэнка рэзультатаў) — усе гэта згадваецца, часта пасля чаго просіцца володзець навыкамі шырокага і швыдкага тэставання. Спіс выглядае перасыльным, але большасць пунктав ў сутнасі являюцца калькамі канкрэтных ідэй пад разнымі назвамі. Як толькі вы зразумеете этыя ідэі, назвы продуктав стануць простымі для ідэнтыфікацыі.

2. Тры спосабы выклікання проблем адпаведаюць за большасць задач

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

Агентская лень. Калікуючыся з дзялом, які складаецца з калько частакоў, модель зупіняецца рана і адзвяртаецца, што ўсё завершана, пасля частковага прыбылку. Яна рашае 20 з 50 застаўленых задач і пазначае рэштку як адрабоўаную. Пратымства — цэ гэтыя часткавыя критэрыі зупінення, якія пераглядае ўсё іншае, чым сама працюючая модель.

Самапрыямлівыя уперадзе. Калі модель прасіцца пераглянуць свой выхад, яна незменна яго затварджвае. Той, хто інвеставаў у рэзультат, не можа яго об’ектыва ацэніць. Пратымства — цэ структурнае: агент, які вырабляе работу, не павінен быць тым, хто яе пераглядае.

Зісхожанне цялевае направлення. З часам, а ўсё болей пасля таго, як контекст стае сумарным або скорачваецца, агент паступова втрачае усведамленне пра первачны цэль. Такія обмежэння, як «не чапацца за модуль платэжаў», можа тыхо зникнуць ў 47-м кроку. Пратэкцыя — это постаянны файл спефікацый, які чытаецца занова ў кожны раз, і які зберагае тыя обмежэння, якія інакш агент бы втрачыў.

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

3. Маленькія базовыя элементы та чатыры рэчі, якія трэба адклаць

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

Core stack (learn these, in this order):
1. Python + async    : the bedrock; everything else builds on it
2. LLM APIs          : Anthropic, OpenAI; understand tokens, context, costs
3. Tool use / MCP    : function calling; how models act on the world
4. LangGraph         : stateful orchestration for multi-step, multi-agent work

Адкладзіце наступныя рэчы, пакуль вы не запусціце хаця б аднаго рэальнага агента:

• Тонкая наладка. На ранніх этапах проектаў яе практычна ніколи не трэба. Спроможны модель фундаменту з добра спроектаванымі запитамі зазвычай працюе краща, чым модель пасля тонкай наладки з паслабнымі запитамі.
• Занадто большая увага да баз данных вектароў. Такія распрацоўкі, як Chroma, падходзяць для локальнага викорыстоўвання, а такія кераваныя сервісы, як Pinecone, — для працы ў продакшэне. Не спешыце выбіраць адну з іх, пакуль выкарыстоўванне дадзеных не стане справжнім бутылочным горлам у вашам проекте.
• Змена фрэймворкаў. Выберыце адні фрэймворк для організацыі роботы (LangGraph — гарны стандарт), завершыце проект, і толькі пасля чаго працавайце над іншымі варыянтамі. Змена інструментоў кожны тыдзень, таму што кожны з іх обяцваецца быць простейшым, не гарантуе завершэння нічога.
• Агенты голасу і браузера. Це спецыялізаваныя рашэння, створаныя на адных і тых жа фундаментах. Спачатку опанавайце тэкстовыя агенты; ўзоры їхней роботы можна будзе перанесці на іншыя типы агентоў.

Частка 2: Кампаненты для стварэння

4. Python і асінхронны код

Вам не патрабуецца майстернае владанне Python, але трэба яго дастаткова колькасць, каб дыягноставаць проблемы, а агенты часта выконваюць помилкі. Сфокусавайцеся на:

• Класы і моделі дадзейнаў. Агенты перадаюць структураваныя даны з аднаго крока да іншага, таму ўсё трэба моделюваць. Шымат Pydantic выступае як контракт между вызовамі інструментаў і логікай агента; спрыяйце яму як неабходнаму, а не факультатыўнаму элементу.
• Асінхронна праця з asyncio. Агенты витрачаюць большую частку свага часу на чаканне рэзультатаў ад інструментаў: запыту да базы дадзенаў, HTTP-запыту, падпроцеса. Сінхронны код зупіняецца пад час кожнага чакання, тады як асінхронны код можа виканаць іншыя задачы. Медленны код агента часта ёсць сінхронным кодам, які чакае па черзі.

HTTP і REST. Без API-інтарфейса агент може толькі мысліць, але не дзейсніць нічога. Навучыцеся чытаць дакументацыю API, прыменяць ліміты частоты запытоў, адгуквацца на паслявыпадковыя рэспансы і разумна перазапускаць задачы. Інструмент, які зупіняецца па коду HTTP 429, — гэта інструмент, на які агент не можа рыляцца.

Распакаванне паслявыпадкоў. Кожны вызов інструмента трэба абгортаваць у try/except. Агенты працуюць без нагляду, і неадрабаваная паслявыпадковасць, якая выведае стэк-трейс і завершвае роботу, нікому не дапаможае пасредзі ночы.

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

5. Аднойчыныя фундаменталі LLM: токены, контэкст і вартасць

Моделі такія як Claude, GPT і Gemini ўжо моцныя, але ім патрэбны кераванні, а вы не можете кераваць тым, чаго не розумееце.

Токенацыя. Моделі чытаюць токены, а не словы, і адны тэрмін можа разбіцца на калькі токенаў залежна ад інструмента токенацыі. Як прыбліжная правіла для англійскай мовы, контэкст з 100 000 токенаў мае прыблізна 75 000 слоў. Усё, што знаходзіцца за межамі гэтага дыапазона, чы то першыя розмовы з минулага тыдня, чы файлы, якія вы забылі дадаць, проста не існуе для моделі. Якщо ў чымось є значэнне, гэта павінна быць у контэксте.

Ліміты контэкста і выкарыстанне інформацыі. Моделі не памятаюць; кожная сесыя запускаецца з порожнім контэкстам. Уключэнне всего ў запит є даскональна складным і пагаршае якосьць у меру збільшэння об’ёму інформацыі. Техніка генеравання з адзначэнням релевантных дадзеных дапамагае выкарыстоўваць толькі тое, што є значэнным.

Адаптаванне, а не навчанне. Вы практычна ніколи не будете навчаць модель. Вы выкалічваеце адаптаванне на чужой модэлі і плаціце за кожны токен. Кост складаецца з колькасці вхідных токенав умове ўмовы цены на вхідны токен плюс колькасць выходных токенав умове ўмовы цены на выходны токен, таму цікл, які выкалічвае 50 вызоў з контекстам на 20 000 токенав, мае значны сумарны рахунак.

Формулювання запитоў для агентаў. Формулювання запитоў для агентаў разлічаецца ад запитоў для чату. Найважлівейшыя тры патэрны: chain-of-thought, калі модель ясна размышляе пры выкананні дзеяння; ReAct — цикл размышлення, дзеяння і спаглядання; і reflection, калі модель крытыкуе свой скарыраны варыянт пры возвращэнні яго. Большасць іншых тэхнік формулювання запитоў є варыяцыямі гэтых. Чырвоныя падробнейшыя інформацыі пра цикл ReAct, адзірніце як агенты ReAct спаўнаюць размышлення з дзеяннямі у рэальным свете.

6. Іспытанне інструментаў і MCP ператвараюць чат-бота ў агента

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

З тэхнічной точкі зору, кожную функцыю описваецца пад назвай, з апісам на нейтральнай мове і схемай JSON для яе параметраў, пры чым гэтыя апісы надаюцца разам з паведамленнем пользователя. Модель вяршыць, чы робіцца інструмент неабходны, і, якщо так, вяртае структураваны вызов інструмента з аргументамі заместо простага тексту. Ваш код запускае функцыю, надае рэзультат назад, і модель продовжывае працу з таго моменту. Апіс такі ж важны, як і схема, таму што самэ гэтае модель выкарыстоўвае, каб вяршыць, калі патрэбны інструменты.

Большая частка практычных інструментаў агента належыць да чатырох категорый. Наведзеныя нижэй прыклады ілуструюць іх: інструменты для чытання (спазірванне света), інструменты для запісу (змена стану), інструменты для выконання коду та інструменты для перакранчвання роботы:

# Category 1: Read  (agent observes the world)
def search_codebase(query: str, path: str) -> list[str]: ...
def fetch_url(url: str) -> str: ...
def read_file(path: str) -> str: ...

# Category 2: Write (agent changes state)
def create_file(path: str, content: str) -> None: ...
def open_pull_request(title: str, body: str, branch: str) -> str: ...
def send_slack_message(channel: str, text: str) -> None: ...

# Category 3: Execute (agent runs code)
def run_tests(test_path: str) -> dict: ...
def execute_sql(query: str, db: str) -> list[dict]: ...

# Category 4: Verify (agent checks its own work)
def lint_code(file_path: str) -> list[str]: ...
def run_type_checker(path: str) -> bool: ...

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

Model Context Protocol (MCP) — это новы стандарт, які заменяе індывідуальны код інтеграцыі протакалам. Паўзучая аналагія — USB-C для AI: замест таго, каб ў кожны раз, калі агенту патрабуецца доступ да GitHub, Slack чыя-небудзь базы дадзеных, пісаць спецыяльны адаптар, вы прыўязуеце вядомы сервер MCP, і гаспадарскія прыкладненняя адкрываюць можлівасці сервера та выкарыстоўваюць іх без дадатковага коду.

Самыя эфектывныя інтеграцыі — гэта GitHub для роботы з веткамі, запрошэннямі на адчыненне коду і проблемамі; Slack для паведамленняў і статыстыкі; ваша база дадзеных для запытанняў і кантролюемага збірання дадзеных; а таксама система для стежэння за проблемамі команды. Калі гэтыя чатыры элемента з’ѐднаны, агент можа виконваць большасць задач у інжынерскам працэсе.

7. Адзысканне інфармацыі, таму што контекст мае меры

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

Система адзыскання інфармацыі складаецца з чатырох галоўных частак:

• Чанкаванне — гэта тое, дзе пачацкія часто рабяць абэранці. Занадта большыя чанкі маюць занадто многа нерелевантных дакументаў; занадта маленькія чанкі тырадзуюць свой сэнс. Правямы размер залежыць ад кантэнту, і код выканання зазвычай патрабуе іншых меж (на прыклад, цэлых функцый) чым дакументацыя у прозе.
• Эмбеддінгі — гэта тое, што дазволяе выконваць пошук сэроднечнасці. Модель эмбеддінга ператварае тэкст у числовы вектор, так што сэроднія фрагменты ствараюць векторы, якія знаходзяцца поблізу адзін другога.
• Пошук — гэта процес, пад час якога знаходзяцца схаваныя векторы, якія знаходзяцца найбліжэй да запытання, і вяртаюцца ўсі чанкі, якія ў іх є.

Ацэнка — гэта тое, што разлічваяе сістэму, якая насправды працюе, ад той, якая толькі выглядае такой. Ключовыя паметнікі — тачнасць выкарыстоўвання інфармацыі (чы было тое, што вы запрашалі, дзейсна рэлевантным?), аддаковасць (чы адпаведзь застаўся ў межах запрашанай інфармацыі?) і рэлевантнасць адпаведзі (чы яна разв’язвае запитанне?). Такія інструменты, як RAGAS чы модель судды, можа ацэніць гэтыя паметнікі. Без ацэнкі прабыткі ў паліпшэнні застаюцца толькі здагадкамі.

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

8. Оркестрацыя з падтрымкай стану за дапамою LangGraph

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

З структурнага точка зору, прыклад LangGraph — это направленая граф, у якога вузлы ўтвараюць звычныя функціі, такія як агенты, інструменты чым процесныя лептасы. Рэчкі паказваюць, як кантроль пераходзіць межы імі. Кожны вузел чытае і адкладае спяшаны, типаваны об’ект стану.

У прыведзенай нижэй шкіце задана становасць, яка мае заведам, план, рэзультаты, адказы і флаг завершэння, пасля чаго региструюцца чатыры вузлы: планавальнік, який дзельніць работу, выканаўшык, який адрабатвае адны крок, пераканальнік, який пераглядае рэзультат, і адказчык з адказамі, який прабуе зноў або перадае справу вышэй. Умовныя рэшткі пасля пераканальніка ёсць сэрца ціклу: завершыць, калі станавасць паставіць значэнне «закончана», перадаць справу адказчыку, калі є адказы, і інакш выканаць наступны крок. Заўважыце, што гэта толькі фрагмент; для рабочага графа таксама патрэбны входны пункт, засталыя рэшткі і вызов compile().

from langgraph.graph import StateGraph, END
from typing import TypedDict

class AgentState(TypedDict):
    task: str
    plan: list[str]
    results: list[str]
    errors: list[str]
    done: bool

graph = StateGraph(AgentState)

graph.add_node("planner", plan_task)       # breaks work into steps
graph.add_node("executor", execute_step)   # runs one step
graph.add_node("verifier", verify_output)  # checks the result
graph.add_node("handler", handle_error)    # retries or escalates

graph.add_conditional_edges(
    "verifier",
    lambda state: END if state["done"] else
                  "handler" if state["errors"] else
                  "executor"
)

Параўняючы з ручным ціклам на Python, гэтая рамка даўае тры дадатковыя можлівасці:

• Паузы для перагляду стану. Калі вы компілюеце граф з апаратам для перагляду стану, стан захоўваецца пасля кожнага крока, таму перарваны запуск (зламаны ноутбук, паўтарны запуск сесіі) можа будзе продаважаны з таго моменту, дзе ён завершыўся, а не занова.
• Паузы з участю чалавека. Установка значэння interrupt_before для важлівага вузла прыводзіць да таго, што граф зупіняецца, паказвае запрошаныя дзеяння і чакае на затверджэнне, прычым перад тым, як продаважацца далей. Гэта вялікая частка таго, што адзначае разлік межы дэмавайшага агента і агента, які викорыстоўваецца у рэальных умовах.
• Паралельныя гілкі. Незалежныя крокі можаць выконваныся адночасна, прычым фрэймворк займаецца адналічэнням ўсіх рэзультатаў у стан, таму вам не трэба пісаць код для сінхронізацыі — достатняя проста апісацыя структуры.

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

Частка 3: Правільнае стварэнне

9. Пяць проектаў, па порядку

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

1. Агент з адзінам інструментам. Выберыце адзін API, напрыклад GitHub чыста службу паветарных умоў, і напісце агента, які выявляе, чырэйкаеся API, запускае яго і перакладае його адпаведзь у свой адказ. Выкорыстаўце неабрабоўваны API Anthropic чыста OpenAI без жадных фрэймворкаў, каб бачыць цикл выкорыстоўвання інструмента без жадных абстракцый, якія бы яго скрылі.
2. Агент ReAct з трыма інструментамі. Дадаце пошук у Інтэрнете, калькулятор і выконвальнік коду, і самі напісце цикл «прычына-дзеянне-спазір». Самэўсёлкі тут вы першы раз бачыце, як агент з’яўляе і выправляе свою сабе памылку.
3. Адзыскванне інфармацыі з вядомай вам базы коду. Створыце індэкс рэальнага репазітарыя, пабудуйце систему адзысквання інфармацыі з яго і задаўце запыткі, якія выкалікаюць патрэбу разумець калькі файлаў. Апылёваце якасць адзысквання і выправіце тыя часткі, якія не працуюць. Гэты проект паказвае, чаму фрагментаванне мае большое значэнне, чым што-небудзь інше.

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

Запланаваны автонамны цикл. Запускайце проект чатыро за раскладам cron без нагляду. Даеце яму файл стану, каб ён продыржаў робіць тое, што робіў, а не пачынаў зноў, жорсткі бюджет на выкарыстанне ресурсаў, каб ён не падняў вартасць API, і журнал аудыту, які фіксуе ўсё, што ён рабіў. Самэ тут «работае ў дэмаверсіі» ператвараецца на «работае без нагляду».

10. Файл стану: агенты забываюць, файлы — ні

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

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

// STATE.md: what every working autonomous agent needs
{
  "last_run": "2026-07-01 03:00 UTC",
  "items_processed": 47,
  "items_remaining": 12,
  "in_progress": [
    "fix/auth-token-refresh: tests passing, awaiting CI"
  ],
  "completed": [
    "fix/null-check-in-billing: merged, CI green"
  ],
  "escalated_to_human": [
    "src/payments/refund.ts: root cause unclear after 3 theories"
  ],
  "lessons": [
    "2026-06-30: E2E tests require Stripe webhook secret in env. Skip if missing.",
    "2026-06-29: Windows runner has TLS 1.2 issue. Use bash, not PowerShell."
  ]
}

Спісак урокаў заслуговае на атрыманне увагі. Чырвоная стрэлка ёсць спосабом, які не дазволяе цыклу павтараць тое ж самае застосунак, і ёй таксама служыць стабільныя спефікацыі для запобежэння зсуву целей. Існуюць два популярных формата. Файл у формате Markdown, які зберагаецца ў рэпазітарыі, належыць да версійна-контролюемых дакументаў, якія лёгкая паддаюцца аналізу разніцы і є простымі, што падходзіць для адзінакоў і малых каманд. Для цыклаў у працэсе виробніцтва, якія трэба стежыць колькам людзям, краща выкарыстоўваць зовнішню систему, такую як трэкер проблем, напрыклад Linear, або базу дадзеных. Прынцып прост: агент забывае, рэпазітарыя памятае, таму все важлівае должна знаходзіцца за межамі контекстнага вікна.

11. Maker-checker: аддзеліце автара ад рэвізора

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

Модель, якая оцінюе свой саўтвораны выхад, занадта ўдзячная да сабе. Запытайце адэнта, які напісаў варыянт з правакамі, чы робіць яго можна, і ён знайдзе прычыны сказаць «так». Якшчу разам з варыянтом і критэрамі оценкі дайце іншаму рэвізору, які не ведае, хто і чаму гэта напісаў, і ён знайдзе рэальныя недагоды.

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

# Wrong: one agent does both
result = await agent("Fix the auth bug and verify your fix is correct")

# Right: maker and checker are separate agents, separate contexts
fix = await agent(
    "Fix the auth bug in src/auth/middleware.ts",
    model="sonnet"
)

review = await agent(
    f"""Review this fix against the rubric below.
    Do not consider who wrote it or their intent.

    Fix:
    {fix.code}

    Rubric:
    - Does it handle the null case on line 47?
    - Does it preserve the existing token expiry logic?
    - Does the test cover the regression case?

    Return: PASS with reasoning, or FAIL with specific line references.""",
    model="opus"   # harder model for the harder judgment task
)

Правілле паўнавагі ў тым, што рэвізор отрымае толькі два вхідныя данні — шкалу оцэнкі і сам файл, а ніколі не інформацыю пра автара, обосновання змены чы разговор, які ўзнік. Будь-якая з гэтых дадзеных можа зноў стварыць суб’ектывацыю через спосаб прадставлення інформацыі. Шкала оцэнкі таксама мае значэнне; конкрэтныя, можна пераканаліць пытанні, як тыя, што былі выказаны вышэй, працуюць набаго краща, чым проста запитанне пра тое, чы ўсё гэта добра.

Такое раздзеленне прыменяецца не толькі да коду: аўтары і рэвізоры, пісьменнікі і пераканальнікі фактов, генераторы і суддзі. Калі вы яго зазначыце, пабачыце, як часта стандартныя інструменты таямна з’едначаюць гэтыя два адносы.

12. Ацэнка: бар’ер, які робіць цыкл надзеяным

Агент без верыфікатора — гэта проста чат-бот, які запускаецца парадульна. Ацэнка вяршыць тое, чы можна доверляць рэзультату настаўна, каб дзеяць на яго адповідна, з’едначыць яго чы выдаць. Існуе тры рэвэлі, якія парадульна падымаюцца за цэнай і за видамі выдаваемых ўхвалень:

• Дэтэрміністычныя перакананні. Тэсты, лінтары, пераканальнікі типаў і процесы кампілявання даюць бінарны рэзультат без жадных ухвалень. Це першы і найдешавейшы бар’ер; калі дэтэрміністычнае перакананне можа адхіліць паспяльны выход, трэба яго вжыць.

Суддзя з LLM. Другі модэлі ацэнююць результаты першай модэлі за апрантам. Гэта метод працуе, калі апрант ўсёчытлівы, але не працуе, калі ён нечытлівы. Суддзя павінен быць прынеймна на такім жа рэвэле, як і модэль, якая стварыла результат, і яму ніколі не трэба паведамляць, хто стварыў гэты результат. Эфективнае выкорыстоўвання суддзі — гэта сама практыка, якая раскрываецца ў управлінні LLM як суддзёй як системай вырабоцтва.

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

Ёнколі хочаце з’ясавіць, чы робота адзынакоўвання ўсунула проблемы, трэба стежыць за часткаю прийнятых змян. Якшо агент, створаны для вылечэння неякіх тэстаў, рашае 70% своих проблем за дапамогою змян, якія прабачаюцца системай CI і пераглядаюцца людзьмі, тады гэта якраз 70%. Калі паказнік знаходзіцца нижэй за 50%, людзі выклакваюць свой час на завершэнне роботы, якую пачаў агент, і такі цикл коштае больш, чым заўсёды эконаміць.

13. Безпека: агент без нагляду — гэта атакаваныя поверхня без нагляду

Будзь-яны автонамны агент, які вплывае на рэальную інфраструктуру, ёсць аб’ектам рызыку з точкай безпекі, якая працуе без нагляду. Рызык ёсць рэальным: за дапамогою аб’ектнай інжэкцыі можна маніпуляваць агентам, які чытае зловучы электранаўпіс або веб-сторонку, каб той выканаў команду атакавальніка. Галоўныя загрозы:

• Уражэнне через выходныя даны інструментаў. Веб-старонкі, пытанні на GitHub і заявкі на падтрымку можу хаваць інструкцыі ў звычным кантэнце, напрыклад рэченне, якае прыказвае агенту ігнараваць пярэднія інструкцыі та выдаліць файлы для тэставання. Карантый — гэта захад: кожны агент, які практычна мае доступ да ненадзярнага кантэнцу, отрымае толькі права на чытанне. Трэба разлучаць агенты, якія толькі чытають, і агенты, якія выкарыстоўваюць даны.
• Парадоксальныя правы. Агент, які пасвячаны толькі на чытанне, отрымае ўсё больш прав на збірку даных „толькі для зручнасці“, і ніхто больш гэта не пераглядае. Регулярна пераглядайце правы (раз у месачы — гэта разумны такт) і надавайце толькі тое, што неабходна для выпання задачы.
• Таіны ў лог-файлах. Дзейнае логаванне ў дужа трывалых цыклах рассеюе аутентыкацыйныя даны ў выходных рэзультатах, якія ніхто не стежыць. Выключайце дзейнае логаванне ў працоўных цыклах і очышвайце тое, што застаўся.

Код, створаны без перагляду. Агенты можаць стварыць запросы прыўязкі быстрэй, чым людзі можаць іх прачытаць. Якщо система CI не мае статычнага аналізу, перакантролювання залежнасцяў і сканавання секрэтных дадзеных, уразлівы код можа прабрацца ў галоўную гілку, не прывернуўшы нічыяй увагі. Автаматызацыя робіць гэтыя правілы ўсё бол важлівымі, а не менш.

Модэль праваў чыніць гэтыя правілы яснымі. У прыкладзе нижэй автаматычна затверджваюцься дзеянні, якія выключна для спаглядання — такія як чытанне файлаў, запуск тэстоў і адзірванне статусу чы суперакцэй git, а для падкладання змян, рэдагавання файлаў сераўісу, змяны коду платаў і ўсьго, што мае флаг прымусу, трэба ўчастка чалавека:

# Safe agent permission model
permissions = {
    "auto_approve": [
        "Read(*)",           # read anything
        "Bash(npm test)",    # run tests
        "Bash(git status)",  # observe state
        "Bash(git diff*)",   # observe diffs
    ],
    "require_human": [
        "Bash(git push*)",   # never push without approval
        "Edit(.env*)",       # never touch secrets
        "Edit(src/payments/*)",  # never touch payments code
        "Bash(*--force*)",   # never force anything
    ]
}

Тэст для кожнага правілы — это адна запитанне: якщо гэтае дзеянне выявіцца некоректным, насколькі дорога будзе яго анулюванне? Якшы анулюванне даскладнае — значыць автаматычна затверджваецца; якшы простае — значыць рашэнне прыменяе чалавек. Рашэння ў кожным разе імпульсавае появу неконтрольванага распространення праваў.

14. Ператворэнне навыкаў у кар’еру

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

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

• Агент, які працюе за планам і чыя рэзультаты вы викорыстоўваете на практыцы, напрыклад, цикл, створаны на 9-м кроце.
• Система з калькамі агентамі, у якой прынеймна два агента выпалююць разныя ролі, што структурна не дазволяе аднаму экземпляру модэлю выканаць оба заведамення, як у шаблоне «творцы-пераканальнікі» з 11-го кроку.
• Система адзысквання дадзеных з задокументаванымі паметкамі ацэнкі, якая паказвае стан да і пасля выправлення проблемы з адзыскваннем, а не толькі тое, што ўсё працуе.

Калітас, якій патрабуецца. Як абрызовы расчын, чалавек, який вже володзіць Python і выдвайае 10–15 гадзін на тыдзень на навчанне, можа спакоўвацца, што гэты парадок займе або-альо восем месцаў. Вважайце гэта цифрамі для планавання, а не абяцаннем.

З чаго пачаць. Ролі сильна разніцаюцца па тым, насколькі яны ўразумелы для новачка:

• Інжынер з автаматызаціі AI у компаніі, чыя галоўная дзеяльнасць не стосуецца AI. Тут патрабуецца чалавек, які можа стварыць, напрыклад, цыкл, який за ноч працюе з тэстамі. Дастатнек АngGraph, MCP і базавыя веды пра CI; дзесяткі фрэймворкаў не патрабуюцца.
• Інжынер AI у стартапе, чый продукт – агент. Гэта выклікае патрэбу ў всем комплексе аперацый: запошук, ацэнка, дизайн і развяртанне калькуляцый з участю калькуляцый, што ставя вышэйшыя вакансіі і апексы.

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

Самая важная частка большасці планаў навучэння — гэта тое, што не трэба ведаць усё яшчэ перад тым, как пачаць. Галоўнае — гэта адзін розмешчаны агент, які рашае рэальную проблему, доказ таго, што можна канкрэтна ацэніць яго успех, і здатнасць чытка адказаць на пытанні, проты якіх спосабаў збою захіщаеяся яго дизайн. Лічнае колькісце кандыдатаў мае ўсе тры гэтыя якості, і жадны сертыфікат не можа заменіць іх.

Заключанне

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

• Выучыце концэпты раней, чым фрэймворкі, і ацэнюйце кожны інструмент па тым, які спосаб працявання ён запобегае: лень, самапрыязна чы іншыя факторы.
• Зберагаюце стан параду моделі, у файле чы базе дадзеных, якія агент перачытае ў кожны раз пад час роботы.
• Ніколі не давайце автару змены якраз таму ж чалавеку, які яе пераглядае; даўце пераглядачу толькі сам артыкул і конкрэтную шкалу ацэнкі.
• Створыце шароўку ацэнкі, праходзячы через детерміністычныя пераканальвання, атэстацыю экспертаў і затверджэнне чалавека, і вимерыце шточнасць прыйнятых змян.

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

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

Спадзяючыся матэрыялы

• Ад чатбота з аднаго вузла да агента, падтрымванага MCP, у LangGraph — Створыце прыклад дапрыема LangGraph шаг за шагам: стан і функціі змены стану, рэшты, канекторы, ціклы з інструментамі, задачы, якія запускаюцца праз контрольныя точкі, тры режыму стрімінгу, а таксама інструменты, якія працуюць праз MCP.
• Проектаванне чатырх-яруснай памяці агента з выкарыстоўванням LangGraph і Amazon Bedrock — Навучыцеся ствараць у агентах LLM рабочую, эпізодычную, семантычную і процедурную память на платформах Bedrock і LangGraph, а таксама захіщаць яе ад занятых дадзенняў, выцеку персональных даных і іншых атак.