Агентныя AI: ад мовных модэляў да автонамных агентаў
Структураваныя інструкціі па том, як LLM-ы перетвараюцца на агентныя системы за дапамою інструментаў, памяці, планавання, архітектураў з калькольнікаямі агентамі та інтеграцыі MCP.
Моделі большых языков прынеслі значныя змены у спосаб нашай роботы з програмнамом.
Уместо таго, каб выдаты комп’ютеру строгія последовасць інструкцый, тепер можна сформулюваць запит так:
"Разберыце, чаму вырасіла рахунак гэтаго кліента, пераканайцеся ў деталях контракту і способу викорыстоўвання, а як выявіцца, што плата некоректная, ачыніце заявку."
Традыцыйныя прыкладнікі для адработкі кожнага з гэтых крокаў вымагалі жорсткая заданая схема роботы.
У працоўніку-агенте, на адміну, ён сам можа выявіць, якія даныя йому трэба, якія інструменты выкарыстоўваць, які крок будзе следующы і калі заданне будзе завершана.
Гэта паднімае естэзныя запытанні:
Як мы перайшлі ад модэля большага языка, які проста стварае тэкст, да системы, здатной выканаць рэальныя задачы?
Розумеўце агентных AI значыць выявляць гэты працэс па кроках.
Ад модэля большага языка да агента
Эты працэс развіваецца на кальколька адзінаковых стадзіяў.
LLM
User → Prompt → LLM → Response
У сваій основны момент модель стварае выходны тэкст галоўная чынюючая — контекст, які ёй даўця.
Разглядзім такі запит:
"Паспяшыце, што такое трансфармер."
LLM можа адпаведзець без проблем, каліколька неабходныя знанні вучыцца ў яе параметрах, якія былі адучаны, разам з даўным контекстам.
Тепер разглядзім іншы запит:
"Какія ў настаўчы час пагодны стан у Бангалоре?"
У гэтым случае моделі трэбуецца актуальная інфармацыя, якая практычна нават не ўключаецца ў яе даныя для адучання. Гэты прынт вядзе да наступной стадзіі.
RAG
User → Retrieve Knowledge → LLM → Response
Метод Retrieval-Augmented Generation дазваляе модэлю абярацься з зовнішняй інфармацыёю — дакументамі компаніі, інструкцыямі, базамі дадзеных — пры стварэнні адказу.
Напрыклад:
"Какая у нашай компаніі політка вярнення грошаў?"
Сістэма запрашвае адпаведны текст політкі і падае яго ў LLM як частку запиту.
RAG спрацоўвае з празьмой у ведамасці.
Аднак застаецца ўсё ж адна лімітацыя:
Што будзе, калі сістэме патрэбна будзе выконаць дзеянне, а не проста адпавесці на запыт?
LLM, які выкарыстоўвае інструменты
User → LLM → Tool → Result → LLM → Response
На гэтым этапе модэль атрымае можлівасць взаімадзейства з зовнішнімі сістэмамі.
Возьмемо ChatGPT як прыклад: калі вы запытваеце
"Якая сёння парада паветра?"
Ён можа выклікваць інструмент для аналізу пагоды, каб запрашваць актуальныя даны, замест таго каб паважаць выключна ведомасці, якія ўжо ўбудованы ў модель.
Інструменты практычна адкрываюць дзвері з LLM у зовнішній свет.
Протыма, тут ёсць важлівая нюанса, якую трэба згадаць.
Якщо разработчык явна закодавае алгоритм виконання, напрыклад:
Question → Weather API → Response
парад порадзей застаецца фіксаваным заздалегідь.
Агент развивае гэю ідею даўжэй.
Агент
Goal
↓
Reason
↓
Choose Action
↓
Use Tool
↓
Observe Result
↓
Decide Next Action
↓
Repeat
↓
Complete Goal
Ключовая разліка крыўцяцца ў дынамічным прыняттыі рашэнняў. Рабочы процес следуе маршруту, які разработчык запланаваў заздалегідь. Агент жа можа сам выбіраць свой маршрут на адной з аснов таго, што ён вывучае па дорозе.
Гэя здатнасць дынамічна выбіраць наступны крок і є сутніснае выклекванне агентскага паведання.
Што такое AI-агент?
Ось працоўная вялічына:
Агент AI — это система, якая выкорыстоўвае LLM, і якая дасягае меты шляхом дынамічнага выбору дзеянняў, якія трэба выконваць, апытваючыся інструментамі та контекстам, стачыраючы рэзультаты гэтых дзеянняў і павтараючы гэты цыкл пакуль мета не будзе дасягнутая або не запрацюе якаясь умова зупінкі.
Зазвычай агент з’еднае:
LLM + Instructions + Tools + State + Memory + Context + Orchestration + Guardrails
LLM адпавядае за разумоўванне та прыняцце рашэнняў.
Інструменты з’являюць конкрэтныя можлівасці.
Стан фіксуе тое, што зараз выканаўцца.
Памяць забезпечвае працэсаванне ў часе.
Нормы встановліваюць меры для паведання.
Оркестрацыя з’ўязвае ўсі гэтыя элементы разам.
Ключовая мысль такая:
Агент не проста стварае адпаведзь. Ён можа прыняць рашэнне па дзеянні і яго выканаць.
Чаму нам патрэбны агенты?
Калі у вас ўжо є чыткая дэфініцыя агента, выклікаецца прыродны вопыт:
Чаму трэба викорыстоўваць усю гэтую дапаможную структуру?
Праўда такая, што не кожная задача выклікае патрэбу ў агенте.
Калі рабочы процес выконваецца па фіксаванай, прыемлівай последовасці:
Receive request
↓
Validate
↓
Call API
↓
Return result
Простая детерміністычная схема зазвычай будзе простейшая і надзяйнейшая.
Тепер паўпоручыце гэта з такім запитам:
"З'ясаваць, чаму нашы витраты на хмарныя сервісы вырослі ў гэты месяц."
Тут няма аднаго заздалегідь вядомага шляху. Системе можа знадобіцца працаваць па такой схеме:
Check billing
↓
Find Azure costs increased
↓
Check deployments
↓
Find new service
↓
Check service usage
↓
Find abnormal traffic
↓
Investigate logs
↓
Generate explanation
Зверніце ўвагу на тое, што вядзеца: агент не можа знайсці, што патрэбна 5-я ступень, пакуль ён не завершыў 2-ю ступень. Рэзультат кожнай дзеяння вплывае на тое, што будзе далей.
Гэта самэйш тая ситуацыя, дзе падход з агентамі робіць свою складнасць неабяжнай.
Простая правіла
Выкорыстоўвайце рабочыя практыкі, калі порядак дзеянняў вядомы заздалегідь. Абрацоўвайце агентаў, калі наступны правильны крок сэрьозна залежыць ад таго, што будзе адкрывацца па дарозе.
Цыкл агента
Калі вы даеце агенту мету, што на самай працы выканаецца пад капотам?
У цэнтры кожнага агента знаходзіцца цыкл агента.
┌─────────────┐
│ Goal │
└──────┬──────┘
↓
┌─────────────┐
│ Reason │
└──────┬──────┘
↓
┌─────────────┐
│ Choose Tool │
└──────┬──────┘
↓
┌─────────────┐
│ Execute │
└──────┬──────┘
↓
┌─────────────┐
│ Observe │
└──────┬──────┘
↓
Goal done?
/ \
No Yes
↓ ↓
Reason Finish
Яго основны патэрн сводзіцца да:
Разумеў → Дзеянне → Абсцэрвацыя → Павтарэнне
Як ілюстрацыя:
User:
"Investigate this invoice."
Agent:
"I need invoice details." ↓get_invoice() ↓Tool returns invoice information. ↓Agent:
"The amount looks unusual. I need the contract." ↓get_contract() ↓Contract returned. ↓Agent:
"Now I can compare the two."
Усю час падчас гэтага абмены агент постаўляе і пераканваецца ў своему уявленні пра ситуацыю, калі з яго арэны надходзяць новыя меркаванні.
У рэальных системах адгуквенцыяў прымаюць у сабе логіку павторных спроб, перакананне данных, кантроль памяці, перагляд прав, можлівасць абзору стану системы і правіла ўжо калі трэба зупніцца — але гэты цыкл являе сабою основную структуру, якая лежыць пад усім гэтым.
Інструменты: даўанне агентам можлівасці дзеяць
Гэты цыкл негайна паднімае наступны вопыт:
Як агент на самай працы можа зв’язацца і паўнічаць на рэальны свет?
LLM сама по сабе не мае прымытай можлівасці прайсці да систем вашай компаніі.
Інструменты і ўжо даюць яму такую можлівасць.
Напрыклад:
get_customer()
get_invoice()
search_policy()
query_database()
create_ticket()
send_email()
Калі інструменты ўжо є, тады прайсход задачі выглядае так:
Agent
↓
"I need the invoice"
↓
get_invoice()
↓
Invoice data
↓
Agent
↓
"I need the contract"
↓
get_contract()
↓
Contract data
Інструменты ачынаюць можлівасць для агента падключыцца да шматароў зовнішняях систем, такіх як:
- Web API
- Реляцыйныя або NoSQL базы дадзеных
- Сервісы пошуку
- Локальныя або хмарныя сховішчы файлаў
- Хосты выхаднага коду, такія як GitHub
Наявнасць такога розмаху зменяе тое, што фундаментальна робіць LLM. Ён больш не проста стварае тэкст.
У замен ён функцыонуе як працавнік, який прыме рашэнні за дапамою набору можлівасцей.
Але што должен памятаць агент?
Калі агент пачынае спаўнюваць кальчу з несколькіх крокаў, з’являецца новая задача.
Уявіце сабе агента, які вже праходзіў гэтую последовасць:
Retrieved the invoice
Checked the contract
Queried usage
Found an anomaly
Ён должен ведаць гэтыя рызультаты, каб з’ясаваць наступны крок.
А якшо той самы корыстнік вернёцца наступнага дня, агенту таксама можа знадобіцца контэкст з паканальнай розмовы.
Самэ гэтае месца, дзе стан і памяць стаюць важлівымі.
Памяць: забезпечэнне працёздатнасці агента
Кожны агент, які працуе пад час калькольных взаімадзейнасцяў, патрабуе якога-небудзь системы памяці.
Прыдатна разделіць памяць на два категорыі:
Короткатэрмінная памяць
Ёй належыць вся інфармацыя, якая патрэбна для выканання текущага заведамства.
User request + Conversation + Current plan + Tool results
Напрыклад, пад час расследавання проблемы з расчытамі агент можа зберагчы такія деталі, як:
Invoice = $14,000
Contract = $10,000
Usage = Normal
Гэтыя даныя актуальны толькі для текущага запуску.
Дзяўнатэрмінная памяць
Ў ёй зберагчыцца інфармацыя, якая можа стаць корыстной пад час будучых взаімадзейнасцяў.
Напрыклад:
User prefers concise reports.
Customer uses Enterprise contract.
Previous incident was resolved using procedure X.
У гэтым сэнсе памяць даёт агенту працёздатнасць між разнымі заведамствамі, замест таго, каб ён зноў вучыўся всьому з нуля кожны раз.
Базовая версія такой архітектуры выглядае так:
Agent
↓
Memory Manager
/ | \
↓ ↓ ↓
Working Episodic Semantic
Memory Memory Memory
Але памяць не должна значыць можлівасць зберагчаць усё на несканчатлівы час.
Установка прыемнага рэвэру зазвычай патрэбуе:
Store
↓
Index
↓
Retrieve
↓
Rank
↓
Inject relevant memory
Мета не ў тым, каб максымізаваць колькасць запамятованага.
Мета — падтрымваць актуальнасць памяці.
Планаванне: Адліквідацыя, што робіць далей
На гэтым этапе агент можа выклікаць інструменты і прыгадваць пакульшні контэкст. Але задачы з багатым наборам элементаў застаюцца вызваннем.
Сярод такіх ситуацый і выклікаецца ўжо адна спэцыяльнасць:
Планаванне.
Возьмімо гэты запит як прыклад:
"Аналізаваць прычыны падвышэння нашых рахункоў і падготавіць адчытку.
Агент можа разбіць яго на:
1. Retrieve current billing
2. Retrieve historical billing
3. Compare services
4. Identify anomalies
5. Investigate causes
6. Verify against policy
7. Generate report
Планаванне можа выкліквачыцца у явнай форме:
{
"steps": [
"fetch_billing",
"compare_history",
"investigate_anomaly",
"generate_report"
]
}
Альбо гэта можа быць неявным, калі модель выбирае свой наступны крок сразу пасля таго, як бачыць рэзультат кожнага інструмента.
Напрыклад:
Get billing
↓
Observe increase
↓
Investigate service
↓
Observe anomaly
↓
Check logs
↓
Generate conclusion
Гэта мае значэнне, таму што планаванне не павінна выконвалівацца толькі спецыяльным агентам планавання.
Адзін агент часта можа як планаваць, так і сам выконваліваць работу.
З аднаго агента да разных архітектураў
На гэты момент основныя элементы вже ўсталяны:
LLM
+
Tools
+
State
+
Memory
+
Planning
Але што будзе, калі задача стане занадта большай, чым можа адарожыць адзін агент?
Адзін агент не завжды є правым выборам.
Самэ гэта прыводзіць да розных архітектурных патэранаў, якія викорыстоўваюцца для стварэння агентных систем.
A. Адзін агент
Agent
/ | \
↓ ↓ ↓
DB API Search
Адзін агент адначасова керуе калькама інструментаў.
Возьмем сцэнарыю падтрымкі кляўэнтаў: адны агент можа ў той жа час працаваць з дакументамі кляўэнтаў, данымі па рахунку, дакументамі правіл і системай выдачы заявок.
Зазвычай логічна пачынаць з гэтага, адколі так выкааноўваецца простыя і зрозумелыя загальныя прынцыпы проектавання.
B. Парадный алгорытм работы
Research
↓
Analysis
↓
Generation
↓
Validation
Гэты шаблон падходзіць для ситуацый, калі порядак дзеянняў ведом заздалегідь.
Напрыклад, процес обробкі дакументаў завжды можа праходзіць через тыя жэны этапы:
Extract
↓
Analyze
↓
Generate
↓
Validate
Строга кажучы, гэта больш супамінае фіксаваны алгорытм работы, чым абсалютна автонамны агент, хоця LLM-ы все ж можа выканаць задачы на кожным з окремых этапаў.
C. Оркестрайтар-рабочы
Orchestrator
/ | \
↓ ↓ ↓
Market Research Risk Investment
tool tool tool
У гэтым случае оркестрайтар на месцы выбірае, якія самэўрабочыя агенты насправды патрэбны.
Разглянем такі запит, напрыклад:
"Інвеставацыя майго 1000 Rs у рынак акцый ="
Організатор можа запусціць:
Financial Research Worker
Market Research Worker
Risk Analysis Worker
Тое, які працоўнікі будуць створаны, залежыць абсалютна ад таго, кары то патрабаванне.
D. Адмаценнік-оптымізатор
Іноды найэфектывейшы спосаб падняць якасць рэзультата агента — це перадаць яго на окольны крок адмацэння.
Generator
↓
Output
↓
Evaluator
↓
Pass ─────→ Done
│
↓
Feedback
↓
Generator
Напрыклад:
Generate SQL
↓
Execute SQL
↓
Error
↓
Analyze error
↓
Correct SQL
↓
Execute again
У такой схеме адзывы прыходзяць безпосередна з арэны, у якой працуе агент.
Гэты падход ўзьміцца ў выдатнасці ў тых сферах, дзе можна об’ектыўна пераканацца ў правільнасці — напрыклад, у створаным кодзе, запитах SQL, структураваных данных аб автаматызаваных тэстах.
E. Калькольнік з калькольнікамі
Калі сфера становіцца дастаткова складной, можа быць карыстны раздзеліць абавескі между калькольнікамі з разнымі спецыялізаціямі.
Supervisor
/ | \
↓ ↓ ↓
Market Research Risk Investment
Agent Agent Agent
Кожны агент можа разлічвацца за такімі параметрамі:
- Інструкцыі
- Інструменты
- Знаёмства
- Абавянення
- Крэтары ацэнкі
Аднак дадзенне большай колькіцтва агентоў не завжды прыводзіць да павышэння якосці.
Збільшэнне колькіцтва агентоў таксама прыносіць:
- Павышанне затрымкі
- Вышэйшыя витраты
- Больша колькасць комунікацый межа агентамі
- Складнэе кераванне станамі
- Больша колькасць момантов, калі можа выйсці злойчын
- Складнэйшая діагностика
Корыстныя рэкамендаціі:
Пачніце з адного агента, і толькі пасля таго, калі спецыялізацыя чынна павышыць эфектыўнасць, перайдзіце на калькі агентоў.
З’яеднанне агентоў з міром: MCP
Калі можлівасці агента расширваюцца, яго спіс неабходных інструментоў можа быстра зростаць.
Уявіце сабе корпаратыўнага агента, якому трэба дасягнуць:
GitHub
Slack
Jira
PostgreSQL
Snowflake
Google Drive
AWS
Azure
Datadog
Якщо кожны аплікэнт AI павінен сам ствараць свою інтеграцыю для кожной з гэтых систем, цэлы экасистема становіцца трыбам для тыямоўкі.
Самэ гэтае прасцяжыню заполняе Model Context Protocol (MCP).
Што такое MCP?
Model Context Protocol (MCP) — это адкрыты протакол, створаны для стандартизаціі способу, яким аплікэнты AI вярбуюцца з зовнішнімі інструментамі, рэсурсамі та запросамі.
Простаю мовай:
MCP выступае як стандартны інтэрфейс між аплікэнтамі AI і зовнішнімі можлівасцямі.
Без спакульнага стандарту вы атрымваете:
Agent
├── Custom GitHub integration
├── Custom Slack integration
├── Custom Database integration
└── Custom Jira integration
З MCP ў практыцы все выглядае так:
AI Application
↓
MCP Client
↓
┌─────────┼─────────┐
↓ ↓ ↓
GitHub Jira DB
MCP Server MCP Server MCP Server
MCP працоўвае на архітэктуры хост-кліент-сервер, а таксама задае стандартызаваныя елементы — а самэ інструменты, рэсурсы та запросы.
Інструменты MCP
Это дзеянні, якія модэль можа выканаць:
create_issue()
search_repository()
execute_query()
Рэсурсы MCP
Это даныя контексту, якія можна перадаць модэлю:
database schema
repository files
documents
configuration
Запросы MCP
Это шаблоны, якія можна викорыстоўваць знову для частых абменаў:
review_code()
generate_report()
debug_error()
Усё, што трэба памятаць:
MCP не стварае агента.
Ён дае можлівасць агенту чы ўсёй AI-практыкі падключацца да зовнішняях можлівасцей. MCP ёсьць шар з’яўлення; сам агент застаецца шаром прыняткі рашэнняў.
Тепер агент можа дзеяць — але чы можа ён падбірацца?
На гэтым этапе агент можа:
Understand
↓
Plan
↓
Use tools
↓
Retrieve knowledge
↓
Remember information
↓
Take actions
Але система пры вырабоцце паднімае ўсё новыя запитанні:
Што выходзіць, калі агент чыніць якуюсь памылку?
Сказаўмо, ён продовжае выбіраць неправы інструмент для виканання задачы.
User:
Investigate invoice.
Agent:
Calls get_customer_profile()User:
Wrong tool. You should check invoice_details().
Чы гэтакія проста трэба негайна паскорыць запрошэнне?
Верагатна, ні.
Адзинкія, якія дае корыстнік, можаць самыя быць неправымі, злонамернымі, непূরнамі або актуальнымі толькі для адного конкрэтнага случая. Гэтае ўсё прычына ціклавага навучэння.
Ціклавае навучэння
Пашчутнае нерозумеўце выглядае так:
"Якщо я даю агенту адзінкія, базаваны LLM автаматычна навучаецца."
У практыцы гэта зазвычай не так.
Навучэнне відбываецца на разных роўнях.
Роўень 1 — Адзінкія ў контэксте
Agent:
I'll create a P2 ticket.
User:
No, this should be P1.Agent:
Understood. P1.
Тут агент налагоджвае сваю дзейнасць толькі для чынную розмову.
Вагі базаванага модэлю не змінююцца.
Рэгламент 2 — Памяць
Этую настройку таксама можна захаваць:
User preference:
Incident priority should default to P1 for this category.
У будучых сесіях можна зноў выкарыстаць гэтую захаваную настройку. Модель яшчэ не зменілася — у агента проста є больш контексту для выкарыстання.
Рэгламент 3 — Падборкі системы
Тепер падумайце пра законаміпенняяя частых пакрытчын.
Production
↓
Trace
↓
Evaluation
↓
Failure detected
↓
Improve prompt/tool/model
↓
Deploy new version
Выправлення на гэтым рэгламенте могло б адразу паўзіць калькольнія часткі працэсу:
- Формулюванне запыткаў
- Спосаб апісання інструментаў
- Логіка направлення, якая выбирае шлях
- Этап выкарыстання дадзеных
- Прыклады, якія паказваюцца агенту
- Тонкай настройкі модэлі
- Заменаўка іншай модэлі
Гэты скуп чынбенняў ёсць набліжэйшы да таго, што людзі на самай працэ падразумеваюць пад цыклам навучання агента.
Вывад такі:
Адказ працоўнікаў часта павінен спрыяць ацэнкі та паслабленню системы, а не стацыянарна включвацца ў яе працэсы.
Абмежнення та безпека
Калі працоўнік пачынае выкананне дзейсносцяў, з’являецца новая проблема:
Што запячатуе, каб ён не зрабіў чагосьць шкодлівага?
Працоўнік можа быть з’яডнаны з базамі дадзенаў, інфраструктурой вырабніцтва, фінансавымі системамі або дадзеннямі кляўэнтав.
Это значыць, што архітектура павінна встановіць меры абмежэння ў там, што можа робіць працоўнік.
User
↓
Input Guardrail
↓
Agent
↓
Authorization
↓
Tool
↓
External System
↓
Output Validation
Абмежнення ўжытковыя для выяўлення такіх проблем, як:
- Вставка запытанняў
- Небезпечныя запыты
- Чутлівая інформацыя
- Некоректныя аргументы інструментаў
- Палягання на правілах
Протыма, самае абмежнення недастатковыя.
Уявіце, калі працоўнік прабуе выдаты:
DELETE production_database
Вы не хачаце, каб система павяралася на модель для выконання логічных раследаванняў:
"Гэта звучыць апасно."
У замен логіка автарызаціі должна дэтерміністычна блакаваць гэта кожны раз.
Основная прынцып тут такі:
LLM ніколі не павінна быць фінальным бар’ерам безпекі.
Рэальная аутентыкація, автарызація, кантроль даступу, верыфікацыя вхідных дадзеных і стандартныя практыкі безпекі прыемоў трэба застосавляць навакол агента.
Вставка запитаў у системы з агентамі
Вставка запитаў становіцься ўсё бол крытычной, калі агент можа запрашваць контэнт з за межаў системы.
Разглядзім такі сцэнарый:
Agent
↓
Search document
↓
Document contains malicious instruction
↓
Agent interprets it as an instruction
↓
Tool call
↓
Potentially harmful action
Ключовая разліка, яку трэба памятаць, такая:
Instructions
≠
Retrieved Data
Веб-сторанка, электранацый, заявка на падпармінанне, прыблэма на GitHub чы ўсё інша дасведчанне можу мець тэкст, уфарматаваны так, каб выглядаў як інструкцыя. Агент не павінен спрыймать все, што ён атрымае, як автаматычна надзяйны чы авторытэтны матэрыял. Самэ гэта і ўскладнівае сістэмы-агенты, выклікаючы патрэбу ў строгей безпецы, чым у простых інструментаў для адпаведзення на запытанні.
Ацэнка: Не ацэнюйце толькі фінальную адпаведзь
Калі агент вжываецца, існуе ключовая запытанне, на якое трэба стало адпавядаць:
Чы агент дэйсна добра выкананае свою роботу?
У звычнам програмнам аплыцэнні загальнае запытанне ёсьць:
"Чы быў выход правільным?"
У разе агентоў таксама трэба запытацца:
"Чы агент выбраў правільны пацёк, каб дасягнуць рэзультата?"
Напрыклад:
Request
↓
Wrong Tool
↓
Wrong Tool
↓
Correct Tool
↓
Correct Answer
Фінальны адказ можа быць правым нават тады, калі агент змарнав зусілля, ўпынуўшы да яго.
Самэльчына прычына — трэба ацэніць усю траекторыю, а не толькі рэзультат:
Input
↓
Plan
↓
Tool Selection
↓
Arguments
↓
Tool Result
↓
Next Decision
↓
Final Answer
Калі вы налажываеце ацэнку, зверніце увагу на такія показнікі, як тое, чыры заданне было завершана, чыры был выбран правы інструмент, чыры аргументы былі заполнены правильна, насколькі хорашым быў атрыбутаваны контэкст, насколькі прямым быў шлях да адказу, сколькі часоў цэе зайняло, каліко цэа коштаў, чыры былы нараблены правіла безпекі, і як часта патрэбна была участка чалавека.
Траекторыя паказвае вам як агент дасягнуў рэзультату, што мае такое ж значэнне, як і сам рэзультат.
Візуабельнасць
Ацэнка паведамляе вас, чыры всё працуе. Візуабельнасць паведамляе вас чыры ў чым была проблема.
Корыстны траг можа выглядаць так:
Trace: 12345
User Request
↓
LLM Call #1
↓
search_customer()
↓
Result
↓
LLM Call #2
↓
get_invoice()
↓
Result
↓
LLM Call #3
↓
Final Answer
Логі зяўляецца неабходны, каб фіксаваць кожную вызову модэлі, кожны вызов інструмента ўключаючы яго аргументы та рэзультаты, час, які прабіўся на выпаненне задачі, выкарыстоўвання токенаў, будзь-якія памылкі чы перапрыбуткі, сігналы пра абмежэнняя і канечны рэзультат.
Без такога рагулю ўскладнення діагностикі прыменэння агента стае практычна немагчымым.
Напрыклад, калі агент вяртае некоректны адпаведзенне, хорашы лог памагае з’ясавіць, чым была прычына:
Wrong retrieval?
↓
Wrong tool?
↓
Wrong tool arguments?
↓
Incorrect reasoning?
↓
Bad final generation?
Гэта робіць можлівасць спостерагання ключовай часткай інжынернай структуры системы, а не чымсь дадатковым, якое прыўязваецца пазней для манітарынгу.
Аб’еднаванне всього: архітектура прыменэння
Шаг за шагам мы дадаўалі новыя можлівасці на базе первіснага LLM:
LLM
↓
RAG
↓
Tools
↓
Agent Loop
↓
Memory
↓
Planning
↓
MCP
↓
Learning & Evaluation
↓
Security & Guardrails
Рэальная система прыменэння спаявае ўсі эты элементы разам:
USER
│
↓
API / Application
│
↓
Authentication
│
↓
┌─────────────┐
│ Agent │
│ Runtime │
└──────┬──────┘
│
┌────────────┼────────────┐
↓ ↓ ↓
Context Memory Tools
Manager │ │
│ ↓ ↓
↓ Vector DB MCP / APIs
RAG │
│ ┌──────────┼──────────┐
↓ ↓ ↓ ↓
Knowledge GitHub DB SaaS
│
↓
Tool Results
│
↓
Agent
│
┌──────┴──────┐
↓ ↓
Response Action
│
↓
External
System
І ўсё гэта абгортваецца:
Security
Guardrails
Observability
Evaluation
Human Approval
Cost Monitoring
Гэты абагульны шарж якраз і ператварае моцны пратотып у агента, які можна рэальна запускаць у працоўнай суперактуальнасі.
Большая карцінка
Якща адмаўляцца назад, паходжанне было з простага LLM:
User → Prompt → LLM → Response
Потым пачаліся проблемы.
Модель не мела доступу да знанняў званіва.
Тады на сцэну выйшаў RAG.
Йому была патрэбна можлівасць взаімадзеяння з зовнішнімі системамі.
Таму мы далі яму Інструменты.
Йому было неабходна выбіраць, які крок мае сэнс у кожны момент.
Тады быў запровадзены Цыкл агента.
Йому было неабходна зберагаць паканальны контэкст.
Таму мы дадалі яму Памяць.
Складнейшыя задачы вымагалі разбівання роботы на менейшыя крокі.
Таду ж з’явілася Планаванне.
Коордынацыя калькольных спецыялізаваных навыкаў вымагала кращай структуры.
Таму мы представілі разныя архітектуры агентаў, а там, дзе гэта было прыемна, — цэлыя мнагаагентныя системы.
Калі колькасць інтеграцый зросла, з’явілася новая проблема.
Сюды і вступаюць стандартызаваныя протаколы, такія як MCP, якія забезпечваюць адносова стабільны шар з’ўязку.
А калі система пачала сама прымець значныя рашэнні, ёй стала патрэбна:
Безпека → Ацэнка → Спостерагальнасць → Адзвечанне → Пастаяшэнне ў розвіце
У гэты момент тое, што у нас є, вучынілася не проста LLM, якая працуе на адпаведны запрос.
Це стала цэлая агентная система.
Ментальны модэль агентнай AI
У сваім ядре модэль можа быць спраўжаная да:
GOAL
↓
REASON
↓
PLAN
↓
ACT
↓
OBSERVE
↓
EVALUATE
↓
REMEMBER
│
└────────→ REASON
Навакол гэтага цыклу знаходзіцца:
Security
+
Guardrails
+
Authorization
+
Observability
+
Human Oversight
Які фіксуе следуючыя эвалюцыі:
LLM
↓
LLM + RAG
↓
LLM + Tools
↓
Agent
↓
Agent + Memory
↓
Agent + MCP
↓
Multi-Agent / Agentic Systems
↓
Continuous Evaluation & Improvement
Але мета не ў тым, каб як можно больш распрацаваць автаномію.
Метай павінна быць надзеяна автаномія.
Вывык
Агентныя ШІ часта спраўляюцца да простай формулы:
LLM + Артыкулы
Аднак гэта толькі пачаткова точка.
Агент высокага стандарта аб’еднвае:
- Разумовыя процесы, якія падтрымваюцца LLM
- Знання, якія надаюцца за дапамой RAG
- Прынадзорнасць, якая падтрымвается за дапамой памяці
- Дзеяння, якія выкананы за дапамой артыкулаў
- З’яўленне ў сеті, якое можліва за дапамой пратаколаў, такіх як MCP
- Планаванне, для багатоэтапных задач
- Адзывы, для павышэння якосці
Основны архітэктурны правілы можна сформулюваць проста:
Полагайцеся на дэтэрміністычны код там, дзе правильнае выкананне є безальтернатыўным, а разумаванне на базе LLM застаўляйце там, дзе гнучкасць і суджэнне практычна дадаюць цяніноў.
Наймоцнейшыя агентныя системы не визначаюцца колькімі можлівасцямі яны маюць.
Яны выдзеляюцца тым, што ведаюць, што трэба зрабіць, выбіраюць правыя інструменты, трываюць у правам контэксте, пераканальваюць сваю работу, пашанаваюць сваія меры і разумеюць, калі трэба зупініцца або перадаць справу чалавеку.
Гэтая і ўсё справжняе змены, якія прыносіць агентны ІІ:
Пераход ад систем, які проста даюць адказы, да систем, якія розумеюць цілі, дзейнуюць на ўсходзе з іх, вучыцца на тым, што выходзіць, і саавтарстваюць з людźмі, каб выконваць рэальную работу.
Спадневана літэратура
- ReAct Explained: Як агенты ІІ спаўнаюць разумаванне з дзеяннямі у рэальным свете — Дазнаёцеся, як фрэймворк ReAct спаўнае разумаванне і выкарыстоўванне інструментаў для падтрымкі агентоў ІІ, і як ён разлічаецца ад модэляў Chain-of-Thought, RL і разумавання.