Зауставите подстицање, започнете инжењерство: 15 принципа за испоруку вашег АИ агента у производњу

Introduction

У почетку, само покушајте да комуницирате са ЦхатГПТ преко АПИ-а, баците у неколико редова контекста, и осећате се запањено да уопште реагује.

Tako se rodio agent.

Ако сте прошле године провели заједно агенте из сценарија и омотача, експериментишући и тинкер, а још увек тражите чистији, одрживији начин да их изградите - овај чланак је за вас.

Размислите о томе као о практичном цхеат листу - збирку инжењерских принципа који помажу водити агента од пешчане кутије до производње: од једноставног АПИ омотача до стабилног, контролисаног и скалабилног система.

Disclaimer

уOvaj članak(Изградња ефикасних агената), Антхропиц дефинише агента као систем у којем ЛЛМс динамички усмеравају своје процесе и употребу алата, одржавајући контролу над начином на који обављају задатке. Системи у којима су ЛЛМс и алати оркестрирани кроз унапред дефинисане кодове које називају радним токовима.

U ovom tekstu, Agent = Agent sistem, gde ću se zbog stabilnosti i kontrole češće oslanjati na tokove posla. Nadam se da će u bliskoj budućnosti biti još 1-2 okreta evolucije i pravi Agenti će biti svuda, ali za sada to nije slučaj

1. Design the Foundation

Ране верзије агената обично долазе брзо: неколико функција, неколико позива - и хеј, то функционише.

Ране верзије агената обично долазе брзо: неколико функција, неколико позива - и хеј, то функционише.

“If it works, why make it complicated?”

Na početku, sveizgledaAgenat reaguje, izvršava kod, ponaša se razumno, ali kada promenite model, ponovo pokrenete sistem ili uključite novi interfejs – odjednom postaje nestabilan, nepredvidljiv, teško ga je debugirati.

И често, коренски узрок није у логици или препорукама, већ много раније: сломљено управљање меморијом, хардцодирано особље, нема начина да се настави сесије, или једна ригидна улазна тачка.

Овај одељак пролази кроз четири кључна принципа која ће вам помоћи да изградите солидну основу - ону на којој све друго може безбедно расти.

1. Keep State Outside

Problem:

1. Ako se agent prekine (crash, timeout, šta god da je), trebalo bi da bude u stanju da pokupi tačno gde je prestao.
2. Потребан вам је начин да прецизно репродукујете оно што се догодило - за тестирање, дебугирање и друга таква задовољства.

Ово није строго проблем, али ипак:

3. Раније или касније ћете желети да паралелизују логику агента. Можда је потребно да упореди више опција усред дијалога (“Који од ових је бољи?”).

(Меморија је потпуно посебан проблем - доћи ћемо до тога ускоро)

Solution:Преместите државуoutsideагент - у базу података, кеш, слој складиштења - чак и ЈСОН датотека ће учинити.

Checklist:

• Агент се може покренути из било ког корака, имајући само session_id - идентификатор сесије - и спољашње стање (на пример, сачуване кораке у бази података или ЈСОН датотеци).У било којој фази, можете прекинути рад агента, поново га покренути (чак и након што промените нешто испод капуљаче), и то ће радити као да се ништа није догодило
• Тест случај: прекинути агент не губи контекст, након поновног покретања резултат је исти
• Стање серијализује у било ком тренутку без губитка функционалности
• Možete da hranite stanje u više istorija paralelno usred dijaloga

2. Make Knowledge External

Problem: ЛЛМ се не сећа. Чак иу једној сесији, модел може заборавити оно што сте већ објаснили, мијешати фазе, изгубити нит разговора, или почети "попуњавати" детаље који нису били тамо. И чини се да време пролази, контекстни прозор расте све већи и већи, одушевљавајући нас новим могућностима. ЛинкедИн је пун постова где људи упоређују коју књигу или колико сати ИоуТубе-овог видеа сада се уклапа у нову верзију модела.

Нарочито ако:

• Дијалог је дуг
• Документи су велики
• Инструкције су сложене
• i tokeni još uvek nisu beskonačni

Чак и са повећањем контекстних прозора (8к, 16к, 128к...), проблеми остају:

• "Изгубљен у средини" - модел обраћа више пажње на почетак и крај (и може ослободити детаље из средине)
• Трошкови - више токова = више новца;
• И још увек се не уклапа. што значи да ће бити губитка, изобличења или халуцинација. Све док трансформатори раде на самопоуздању са квадратном комплексношћу (О(н2)), ово ограничење ће бити са нама.

Solution:Одвојите "радни меморију" од "складиштења" - као у класичним рачунарским системима. Агент треба да буде у стању да ради са спољашњом меморијом: чува, преузима, сумира и ажурира знање изван модела.

Approaches

Memory Buffer

Prodajem poslednjekПогледајте видео за брзо прототипирање.

+jednostavno, brzo, dovoljno za kratke zadatke

-губи важне информације, не скалира, не сећа се "јуче"

Summarization Memory

Компресирајте историју да би се више уклапало.

+Токен штедње, проширење меморије

-деформације, губитак нијанси, грешке у вишестепеној компресији

RAG (Retrieval-Augmented Generation)

Povlači znanje iz spoljnih baza podataka. Većinu vremena ćete biti ovde.

+скалабилна, свежа, проверива

-сложена подешавања, осетљива на квалитет опоравка, латенција

Knowledge Graphs

Uvek elegantno, seksi i tvrdo, na kraju ćete raditi RAG u svakom slučaju.

+логика, објашњивост, стабилност

-висока баријера за улазак, сложеност ЛЛМ интеграције

Checklist:

• Сва историја разговора је доступна на једном месту (изузев поруке)
• Извори знања су регистровани и могу се поново користити
• Историјске скале без ризика да се превазиђе прозор контекста

3. Model as a Config

Problem:ЛЛМ-ови се брзо развијају; Гоогле, Антхропиц, ОпенАИ, итд. стално ослобађају ажурирања, тркајући једни против других преко различитих бенчмаркова. Ово је забава за нас као инжењера, и желимо да извучемо максимум.

Solution:

1. Implementirajte model_id konfiguraciju: Koristite model_id parametar u konfiguracionim datotekama ili promenljivim okruženjima da biste odredili model koji se koristi.
2. Користите апстрактне интерфејсе: Креирајте интерфејсе или класе омотача који комуницирају са моделима кроз јединствени АПИ.
3. Примените решења средњег софтвера (пажљиво - мало касније ћемо говорити о оквирима)

Checklist:

• Замена модела не утиче на остатак кода и не утиче на функционалност агента, оркестрацију, меморију или алате
• Додавање новог модела захтева само конфигурацију и, опционално, адаптер (једноставан слој који доводи нови модел на потребан интерфејс)
• Можете лако и брзо пребацити моделе. Идеално - било који модели, барем - пребацивање унутар породице модела

4. One Agent, Many Interfaces: Be Where the Users Are

Problem:Чак и ако је у почетку агент намењен да има само један комуникациони интерфејс (на пример, УИ), на крају ћете желети да корисницима дате више флексибилности и погодности додавањем интеракције преко Слацк-а, ВхатсАпп-а или, усуђујем се да то кажем, СМС-а - шта год да је то.

Solution: Creating a unified input contractРазвијте АПИ или други механизам који ће служити као универзални интерфејс за све канале.

Checklist:

• Agent is callable from CLI, API, UI

• All input goes through a single endpoint/parser/schema

• All interfaces use the same input format

• No channel contains business logic

• Adding a new channel = only an adapter, no changes to core

  
  

  

  
  

II. Дефинише понашање агента

Иако постоји само један задатак, све је једноставно, као у постовима ИИ еванђелиста.Али чим додате алате, логику доношења одлука и више фаза, агент се претвара у неред.

Иако постоји само један задатак, све је једноставно, као у постовима ИИ еванђелиста.Али чим додате алате, логику доношења одлука и више фаза, агент се претвара у неред.

Губи траг, не зна шта да ради са грешкама, заборавља да позове праву алатку - и опет сте остали сами са дневницима где "добро, све изгледа да је написано тамо."

Да би се то избегло, агенту је потребан јасанbehavioral modelШта ради, који алати има, ко доноси одлуке, како људи интервенишу и шта да раде када нешто пође наопако.

Овај одељак покрива принципе који ће вам помоћи да свом агенту дате кохерентну стратегију акције уместо да се надате да ће "модел то некако схватити".

5. Design for Tool Use

Problem:Ова тачка може изгледати очигледно, али и даље се сусрећете са агентима изграђеним на "Плаин Промптинг + сирови ЛЛМ излаз анализирања." То је као да покушавају да контролишу сложен механизам повлачењем случајних нити и надајући се најбоље.

• Крхкост: Најмања промена у формулацији одговора ЛЛМ-а (једна реч је додана, ред фразе је промењен) може прекинути целокупно анализирање.
• Недвосмисленост: Природни језик је инхерентно недвосмислен. Оно што човеку изгледа очигледно може бити загонетка за аналитичара. „Позови Џона Смита“ – који је од три Џона Смита у вашој бази података?
• Комплексност одржавања: Парсинг код расте, постаје збуњен и тешко дебугирати.Сваки нови агент "вештина" захтева писање нових правила парсинга.
• Limited capabilities: It's hard to make the model reliably call multiple tools or pass complex data structures through simple text output.

Solution:Модел враћа ЈСОН (или други структурирани формат) – систем извршава.

Кључна идеја овде је оставити одговорност заинтерпретацијекорисничка намера иИзборалате за ЛЛМ, док и даље додељујеизвршењаOd te namere doСистемпреко јасно дефинисаног интерфејса.

Срећом, практично сви провајдери (ОпенАИ, Гоогле, Антхропиц, или ко год желите) подржавају такозване"function calling"или могућност генерисања излаза у строго дефинисаном ЈСОН формату.

Samo da osvežimo kako to funkcioniše:

1. Опис алата: Дефинишете функције (алата) као ЈСОН Сцхема са именом, описом, параметрима.Опис је критично важан - модел се ослања на њега.
2. Прелазак на ЛЛМ: На сваком позиву, модел прима шеме алата заједно са позивом.
3. Model output: Instead of text, the model returns JSON with:
   • name of the function to call
   • arguments—parameters according to schema
4. Извођење: Код потврђује ЈСОН и позива одговарајућу функцију са параметрима.
5. Модел одговор (опционо): Резултат извршења се враћа у ЛЛМ за коначну генерацију одговора.

Important:Описи алата су такође позиви. Нејасан опис = погрешан избор функције.

What to do without function calling?

Ако модел не подржава позиве алата или желите да их избегнете из неког разлога:

• Замолите модел да врати ЈСОН у позив. Будите сигурни да наведете формат; можете додати примере.
• Analizirajte odgovor i potvrdite ga sa nečim kao što je Pydantic.

Checklist:

• Response is strictly formalized (e.g., JSON)
• Користе се шеме (ЈСОН Сцхема или Пидантик)
• Валидација се примењује пре позива функција
• Generation errors don't cause breakage (format error handling exists)
• ЛЛМ = избор функције, извршење = код

6. Own the Control Flow

Problem:Обично агенти раде као "дијалози" - прво корисник говори, а затим агент реагује.То је као играње пинг-понга: хит-реакција.

Such an agent cannot:

• Uradite nešto sami bez zahteva
• Извршите акције паралелно
• Planirajte korake unapred
• Napravite nekoliko koraka u redosledu
• Proverite napredak i vratite se na neuspešne korake

Уместо тога, агент треба да управља сопственим "протоком извршења" - одлучује шта да ради следеће и како да то уради.

This means the agent:

• odlučuje kada da uradi nešto sam
• Možete napraviti korake jedan za drugim
• can retry failed steps
• Možeš da menjaš zadatke
• Može da radi čak i bez direktnih zahteva

Solution:Уместо да дозволимо да ЛЛМ контролише сву логику, извлачимоcontrol flowу код. модел помаже само у корацима или предлаже следећи. Ово је промјена од "писања порука" наengineering a systemса контролисаним понашањем.

Погледајмо три популарна приступа:

1. FSM (Finite State Machines)

• Шта је то: Задатак подељен на државе и јасне транзиције.
• ЛЛМ: Одређује следећи корак или делује унутар државе.
• Предности: Једноставност, предвидљивост, добро за линеарне сценарије.
• Алати: СтатеФлоу, YAML конфигурације, Стате Паттерн.

2. DAG (Directed Graphs)

• Шта је то: Нелинеарни или паралелни задаци као графикон: чворови су акције, ивице су зависности.
• ЛЛМ: Може бити чвор или помоћ у изградњи плана.
• Предности: Флексибилност, паралелност, визуелизација
• Алати: Лангграпх, Треллис, ЛЛМЦомпилер, прилагођени ДАГ дијаграми.

3. Planner + Executor

• Шта је то: ЛЛМ гради план, код или други агенти га извршавају.
• ЛЛМ: "велики" један планови, "мали" они извршавају.
• Предности: одвајање брига, контрола трошкова, скалабилност.
• Алати: ЛангЦхаин План-анд-Екецуте

Why this matters:

• Повећава контролу, поузданост, скалабилност.
• Омогућава комбиновање различитих модела и убрзање извршења.
• Tok zadataka postaje vizuelizovan i testiran.

Checklist:

• Користи ФСМ, ДАГ или сценарио са експлицитним транзицијама
• Модел одлучује шта да ради, али не контролише ток
• Понашање се може визуализовати и тестирати
• Управљање грешкама је уграђено у ток

7. Include the Human in the Loop

Problem:Чак и ако агент користи структуриране алате и има јасан проток контроле, пуна аутономија ЛЛМ агента у стварном свету је и даље више од сна (или ноћне мора, у зависности од контекста). ЛЛМс немају право разумевање и нису одговорни за ништа.

Main risks of full autonomy:

• Трајне грешке: Агент може извршити акције са озбиљним последицама (избрисати податке, послати погрешну поруку важном клијенту, започети побуну робота).
• Compliance violations: The agent might accidentally violate internal regulations, legal requirements, or hurt user feelings (if that wasn't the plan, ignore this point).
• Недостатак здравог разума и етике: ЛЛМ-ови могу пропустити друштвене нијансе или деловати против "обичног разума".
• Губитак поверења корисника: Ако агент прави честе грешке, корисници ће престати да му верују.
• Комплексност ревизије и одговорности: Ко је крив када аутономни агент "укрцава"?

Solution: Стратешко позивање облика живота заснованих на угљеникуИнтегрисати људе у процес доношења одлука у кључним фазама.

HITL Implementation Options

1. Approval Flow

• Када: акција је критична, скупа, неповратна
• Како: агент формулише предлог и чека потврду

2. Confidence-aware Routing

• Када: модел је несигуран
• How:
  • self-assessment (logits, LLM-as-a-judge, P(IK))
  • escalation when confidence falls below threshold

3. Human-as-a-Tool

• When: insufficient data or unclear request formulation
• Како: агент тражи разјашњење (нпр. HumanTool у CrewAI)

4. Fallback Escalation

• Када: поновљена грешка или нерешена ситуација
• Како: задатак се преноси оператору са контекстом

5. RLHF (Human Feedback)

• Када: за побољшање модела
• Kako: čovek procenjuje odgovore, oni ulaze u obuku

Checklist:

• Акције које захтевају одобрење су дефинисане
• Постоји механизам за процену поверења
• Agent može postavljati ljudska pitanja
• Критичне акције захтевају потврду
• There's an interface for inputting responses

8. Compact Errors into Context

Problem:Стандардно понашање многих система када се деси грешка је или да се "сруши" или једноставно пријавите грешку и зауставите. за агента који би требао аутономно решити задатке, ово није управо најбољи модел понашања.

What we'll face:

• Крхкост: Сваки неуспех у спољашњем алату или неочекивани одговор ЛЛМ-а може зауставити цео процес или га преварити.
• Inefficiency: Constant restarts and manual intervention eat up time and resources.
• Немогућност учења (у широком смислу): Ако агент не "види" своје грешке у контексту, не може покушати да их поправи или прилагоди своје понашање.
• Халуцинације – опет

Solution:Грешке су укључене у позив или меморију. Идеја је да покушате да имплементирате неку врсту "само-лечења".

Груби ток :

• Разумевање грешке
• Self-correction:
  • Self-correction mechanisms: Error Detection, Reflection, Retry Logic, Retry with changes (Agent can modify request parameters, rephrase the task, or try a different tool)
  • Impact of reflection type: More detailed error information (instructions, explanations) usually leads to better self-correction results. Even simple knowledge of previous errors improves performance.
  • Internal Self-Correction: Training LLMs for self-correction by introducing errors and their fixes into training data.
• Захтевајте људску помоћ: Ако само-корекција не успије, агент ескалира проблем на човека (види Принцип 7).

Checklist:

• Грешка у претходном кораку је сачувана у контексту
• Повратак логике постоји
• Фалбацк / људска ескалација се користи за поновљене неуспјехе

9. Break Complexity into Agents

Problem:Вратимо се кључном ограничењу ЛЛМ-а (то је контекстна ствар), али погледајмо овај проблем из другог угла. Што је задатак већи и сложенији, то ће више корака трајати, што значи дужи контекстни прозор. Како контекст расте, ЛЛМ-и су вероватније да се изгубе или изгубе фокус. Фокусирањем агента на специфичне домене са 3-10, можда максимално 20 корака, одржавамо управљачке контекстне прозоре и високе перформансе ЛЛМ-а.

Solution:Користите мање агенте усмерене на специфичне задатке. један агент = један задатак; оркестрација одозго.

Benefits of small, focused agents:

• Управни контекст: Мањи контекстни прозори значе боље перформансе ЛЛМ-а
• Јасне одговорности: Сваки агент има добро дефинисан обим и сврху
• Bolja pouzdanost: manja šansa da se izgubite u složenim tokovima posla
• Једноставније тестирање: лакше тестирање и валидација специфичних функционалности
• Побољшано дебугирање: лакше је идентификовати и поправити проблеме када се појаве

Нажалост, не постоји јасна хеуристика за разумевање када је комад логике већ довољно велики да се подели на више агената. Ја сам прилично сигуран да док читате овај текст, ЛЛМ-ови су постали паметнији негде у лабораторијама. И они настављају да постају бољи и бољи, тако да је сваки покушај да се формализује ова граница осуђен од почетка. Да, што је мањи задатак, што је једноставнији, али што је већи, боље се реализује потенцијал.

Checklist:

• Scenario is built from microservice calls

• Agents can be restarted and tested separately

• Agent = minimal autonomous logic. You can explain what it does in 1-2 sentences.

  
  

  

  
  

III. Контролни модел интеракције

Модел се бави генерацијом.Све остало је на вама.

Модел се бави генерацијом.Све остало је на вама.

Како сте формулисали захтев, шта сте прошли у контексту, које инструкције сте дали - све то одређује да ли ће резултат бити кохерентан или "креативан".

ЛЛМ не читају умове, они читају токене.

То значи да се свака улазна грешка претвори у излазну грешку – једноставно не одмах приметну.

Овај одељак је о томе да не дозволите све да се креће: позиви = код, експлицитно управљање контекстом, ограничавање модела у границама.

10. Treat Prompts as Code

Problem:Врло уобичајени образац, посебно међу људима без МЛ или СЕ позадине, је складиштење позива директно у код.

This approach leads to several maintenance and scaling difficulties:

• Navigation, understanding, and modification become complicated as project complexity and number of prompts grow.
• Без експлицитног верзионисања, веома је тешко пратити брзу еволуцију, разлоге за промене и вратити се на претходне стабилне верзије у случају погоршања перформанси.
• Неефикасан процес побољшања и дебугирања: Брза оптимизација без објективних показатеља и тестирања постаје субјективни и интензиван процес са нестабилним резултатима.
• Перцепција од стране других чланова тима постаје компликована, укључујући (и нарочито) будућу вас.

Solution:Prompti u ovom kontekstu se ne razlikuju mnogo od koda i na njih treba primeniti iste osnovne inženjerske prakse.

This implies:

• Чувајте одвојено и систематски, користећи специјализоване датотеке (као што су .ткт, .мд, .иамл, .јсон) или чак системе за управљање шаблонима (нпр.
• Можете чак и да урадите А / Б тестове са различитим верзијама након тога.
• Testing. You heard that right.
  • This could be something like unit tests, where you compare LLM responses to specific inputs against reference answers or expected characteristics depending on the prompt
  • Evaluation datasets
  • Format compliance checks and presence/absence of key elements - For example, if a prompt should return JSON, the test can validate its structure
  • Even LLM-as-a-judge if your project and design justify it.

О тестирању ћемо говорити детаљније у принципу 14.

Checklist:

• Промптс се чувају у одвојеним датотекама, одвојено од пословне логике
• Постоји дифф и промена историје
• Тестови се користе (ако је потребно)
• (Неопходно) Шта је са брзим прегледом као део прегледа кода?

11.Контекст инжењеринг

Problem:Већ смо разговарали о "заборављивости" ЛЛМ-а, делимично решавајући ово отклањањем историје у спољашњу меморију и коришћењем различитих агената за различите задатке. али то није све. предлажем да размотримо и експлицитно управљање контекстним прозором (а овде не говорим само о компресирању историје како би се уклопила оптимална величина или укључивање грешака из претходних корака у контекст).

Standard formats aren't always optimal:Једноставна листа порука у "роле-контенту" (system/user/assistant) формат је база, али може бити тежак, недовољно информативан или лош у преносу сложеног стања вашег агента.

Већина ЛЛМ клијената користи стандардни формат поруке (листа објеката саrole: „систем“, „корисник“, „асистент“,contenta ponekad itool_callsу пољима )

Иако ово "ради одлично за већину случајева", да би се постиглоmaximum efficiency(у смислу и токена и пажње модела), можемо креативније приступити формирању контекста.

Solution:Да бисте третирали стварање целог информационог пакета који је предат на ЛЛМ као"Context Engineering."To znači:

1. Пуна контрола: Узимање пуног власништва за које информације улазе у контекстни прозор ЛЛМ-а, у којем облику, запремини и редоследу.
2. Креирање прилагођених формата: Не ограничавајући се на стандардне листе порука. Развијање наших сопствених, оптимизованих начина представљања контекста. На пример, можете размотрити коришћење структуре сличне КСМЛ-у да густо спакујете различите врсте информација (поруке, позиве на алате, њихове резултате, грешке итд.) у једну или више порука.
3. Холистички приступ: Видети контекст не само као историју дијалога, већ као збир свега што можда треба модел: непосредни позив, инструкције, подаци из РАГ система, историја позива алата, стање агента, меморија из других интеракција, па чак и инструкције о жељеном излазном формату.

(Instead of a checklist) How do you know when this makes sense?

Ako ste zainteresovani za bilo koji od sledećih:

• Информациона густина: Максимално значење са минималним буком.
• Смањење броја токена где можемо добити упоредиви квалитет по нижој цени.
• Побољшано погрешно понашање.
• Управљање укључивањем осетљивих информација, контролом, филтрирањем, и завршавајући све тако што ћете добити класичан одговор "Извините, ја сам само мали мали велики модел језика".

12. Constrain the Chaos: Secure Inputs, Guarded Actions, and Grounded Outputs

Problem:Већ смо много урадили у име стабилности, али ништа није сребрна лопта.То значи да вреди размотрити најкритичније потенцијалне проблеме одвојено и експлицитно узети мало "осигурања".

У овом принципу размишљамо о:

• Moguća prompt injekcija. Ako vaš agent komunicira direktno sa korisnikom, morate da kontrolišete šta se hrani kao unos. U zavisnosti od vrste korisnika, možda ćete dobiti nekoga ko želi da prekine vaš tok i prisili agenta da ignoriše svoje početne ciljeve, pruži pogrešne informacije, izvrši štetne akcije ili generira zlonamerni sadržaj.
• Из горе наведеног разлога, или под вођством "гласова у глави", агент може открити важне информације, као што су лични подаци корисника, корпоративне тајне итд.
• Генерација токсичног или злонамерног садржаја. Ако је то по дизајну, игноришите ову тачку.
• Стварање ствари када је информација одсутна.Вечна бол.
• Подизање машина, запамтите? Али озбиљно, у процесу размишљања, агент може доћи до врло не-тривијалних решења, од којих сви неће бити у опсегу нормалног понашања.

Безбедност и уземљење агента ЛЛМ није једна мера, већ вишеслојни систем заштите ("одбрана у дубини") који покрива цео животни циклус интеракције. Пријетње су разноврсне, а ниједан метод заштите није панацеја.

Solution:Морамо се обавезати на вишеслојни одбрамбени систем, размишљати и експлицитно се бавити свим угаоним случајевима и потенцијалним сценаријама, и имати јасан одговор спреман за шта год да се деси.

У основној конфигурацији, требало би да узмете у обзир:

1. Secure Inputs.

   1. Check for known attack-indicator phrases (e.g., "ignore all previous instructions"). It sometimes makes sense to combat potential obfuscation.
   2. Try to determine the user's intent separately. You can use another LLM for this, to analyze the input for the current one.
   3. Control input from external sources, even if they are your own tools.

2. Guarded Actions. Control the privileges of both the agent and its tools (granting the minimum necessary), clearly define and limit the list of available tools, validate parameters at the input to tools, and enable Principle #7 (Human in the Loop).

3. Output Moderation. Design a system of checks for what the model outputs, especially if it goes directly to the user. These can be checks for relevance (ensuring the model uses what's in the RAG and doesn't just make things up) as well as checks for general appropriateness. There are also ready-made solutions (e.g., the OpenAI Moderation API).

Konačni sistem, međutim, zavisi od vaših zadataka i procene rizika.U kontrolnoj listi ćemo pokušati da skiciramo neke opcije.

Checklist:

• User input validation is in place.

• For tasks requiring factual information, the data within the RAG is used.

• The prompt for the LLM in a RAG system explicitly instructs the model to base its answer on the retrieved context.

• LLM output filtering is implemented to prevent PII (Personally Identifiable Information) leakage.

• The response includes a link or reference to the source.

• LLM output moderation for undesirable content is implemented.

• The agent and its tools operate following the principle of least privilege.

• The agent's actions are monitored, with HITL (Human-in-the-Loop) for critical operations.

  
  

  

  
  

IV. Keep It Alive

Агент који "кинда ради" је грешка са одложеним ефектом.

Агент који "кинда ради" је грешка са одложеним ефектом.

У проду, не све прекида одједном. и не сазнате о томе одмах. Понекад, не сазнате уопште.

Овај део се односи на инжењерске навикеseeing what's happeningиchecking that everything is still workingЛогови, праћење, тестови - све што чини понашање агента транспарентним и поузданим, чак и када спавате или развијате свог следећег агента.

13. Trace Everything

Problem:На један или други начин, стално ћете се суочити са ситуацијама у којима агент не ради као што сте очекивали. Током развоја, тестирања, промјена, или током нормалног рада. Ово је неизбежно, и у овом тренутку, то је нормално у некој мери. То значи да сте осуђени да проведете сате и дане дебаггирања, покушавајући да разумете шта је погрешно, репродукује проблем, и поправи га. Волео бих да мислим да сте до овог тренутка већ имплементирали Принцип #1 (Држите државу ван) и #8 (Компактне грешке у контекст). У већини случајева, то ће бити довољно да ваш живот много једноставније. Неки други принципи ће такође индиректно помоћи овде.

Чак и тако (посебно ако сте одлучили да се не бавите њима за сада), има много смисла размишљати о дебугирању унапред и уштедети време и нерве у будућности придржавајући се овог принципа.

Solution:Лог цео пут од захтева до акције. Чак и ако већ имате логове за појединачне компоненте, праћење целог ланца може бити проблем. Чак и ако сте велики љубитељ слагалица или Лего, у неком тренутку, то ће престати да буде забавно.

Why it's needed:

• Debugging - Brzo pronađite gde su stvari pogrešile.To je razlog zašto ovaj princip postoji.
• Аналитика - Погледајте где су препреке и како се побољшати.
• Процена квалитета – види како промене утичу на понашање.
• Reproduktivnost – možete precizno rekonstruisati korake.
• Auditing — A log of all agent decisions and actions.

Основни "џентлменски сет" изгледа овако:

• Input: The initial user request, parameters received from the previous step.
• Стање агента: кључне променљиве стања агента пре извршења корака.
• Промпт: Пуни текст промпта послат ЛЛМ-у, укључујући системске инструкције, историју дијалога, преузети контекст РАГ-а, описе алата итд.
• ЛЛМ Извод: Потпуни, сирови одговор из ЛЛМ-а, пре било каквог анализирања или обраде.
• Позивање алата: Ако је ЛЛМ одлучио да позове алат - име алата и тачне параметре са којима је позвана (према структурираном излазу).
• Резултат алата: Одговор који је алат вратио, укључујући и успешне резултате и поруке о грешци.
• Одлука агента: Коју одлуку је агент донео на основу одговора ЛЛМ-а или резултата алата (нпр. који следећи корак да изврши, који одговор да да кориснику).
• Метаподаци: време извршења корака, модел ЛЛМ који се користи, трошак позива (ако је доступан), верзија кода / препоруке.

Note:Погледајте постојеће алате за праћење; под одређеним условима, они ће вам учинити живот много лакшим. ЛангСмитх, на пример, пружа детаљну визуализацију позивних ланца, позива, одговора и употребе алата. Такође можете прилагодити алате као што су Аризе, Ваге & Биасес, ОпенТелеметрија, итд. за ваше потребе.

Checklist:

• Сви кораци агента су забележени (ваша верзија "џентлменског сета").
• Кораци су повезани са сесијом_ид и кораком_ид.
• Постоји интерфејс за преглед целог ланца.
• Позив послат на ЛЛМ може се репродуковати у било којој фази.

14. Test Before You Ship

Problem:До овог тренутка, највероватније имате неку врсту практично готовог решења. Ради, можда чак и на начин на који сте желели.keepsфункционише? Чак и након следећег малог ажурирања? Да, водим нас на тему тестирања.

Очигледно, ажурирања у ЛЛМ системима, као иу било којој другој - било да се ради о променама у апликационом коду, ажурирању набора података за фино подешавање или РАГ, новој верзији основног ЛЛМ-а, или чак мањим прилагођавањама - често доводе до ненамерних прекида у постојећој логици и неочекиваног, понекад деградирајућег понашања агента.Традиционални приступи тестирања софтвера нису довољни за свеобухватну контролу квалитета ЛЛМ система.

• Можда је провајдер ажурирао свој модел, можда се природа улазних података променила (датни дрифт) - оно што је радило јуче можда ће престати да ради данас.
• Чак и мала промена у упутству може прекинути успостављену логику и искривити излаз.
• Недетерминизам ЛЛМ-а: Као што знате, многи ЛЛМ-и су не-детерминистички (посебно са температуром > 0), што значи да ће генерисати различите одговоре на исти улаз на сваком позиву.
• Биће вам лакше ако сте имплементирали први принцип, али репродукција одређене грешке за дебугирање може бити тешка чак и са фиксним подацима и стањима.
• У сложеним системима, ажурирање једног елемента (као што је модел или позив) може да се каскадира кроз ланац АПИ-ја, база података, алата итд., И довести до промене у понашању на другом месту.
• са халуцинацијама

Али већ разумемо да традиционални тестови, фокусирани на верификацију експлицитне логике кода, нису у потпуности способни да покрију ова питања.

Solution:Мораћемо да осмислимо сложен, свеобухватан приступ који покрива многе ствари, комбинујући класична и доменска решења.

• Вишестепено тестирање: Комбинација различитих типова тестирања који циљају различите аспекте система: од ниског нивоа јединичних тестова за појединачне функције и позиве до сложених сценарија који потврђују ток рада агента од краја до краја и интеракцију корисника.
• Фокус на понашање и квалитет ЛЛМ: Тестирање треба да процени не само функционалну коректност, већ и квалитативне карактеристике одговора ЛЛМ-а, као што су релевантност, тачност, кохеренција, одсуство штетних или пристрасних садржаја, и поштовање упутстава и одређеног стила.
• Тестови регресије и квалитета који укључују "златне сетове података" који садрже различите примере уноса и референтне (или прихватљиве опсеге) излаза.
• Аутоматизација и интеграција у ЦИ / ЦД.
• Евалуација човека у току: Специфичне фазе ЛЛМ-евалуације треба да укључују човека за калибрацију метрике и преглед сложених или критичних случајева.
• Итеративни приступ брзом развоју и тестирању: Промпт инжењеринг треба третирати као итеративни процес у којем се свака верзија промпта темељито тестира и процењује пре имплементације.
• Testing at different levels of abstraction:
  • Component testing: Individual modules (parsers, validators, API calls) and their integration.
  • Prompt testing: Isolated testing of prompts on various inputs.
  • Chain/Agent testing: Verifying the logic and interaction of components within an agent.
  • End-to-end system testing: Evaluating the completion of full user tasks.

Checklist:

• Logic is broken down into modules: functions, prompts, APIs—everything is tested separately and in combination.

• Response quality is checked against benchmark data, evaluating meaning, style, and correctness.

• Scenarios cover typical and edge cases: from normal dialogues to failures and provocative inputs.

• The agent must not fail due to noise, erroneous input, or prompt injections—all of this is tested.

• Any updates are run through CI and monitored in prod—the agent's behavior must not change unnoticed.

  

Principle 15: Own the Execution Path

Ово је мета-принцип; ради кроз све горе наведене.

Fortunately, today we have dozens of tools and frameworks for any task. This is great, it's convenient, and it's a trap.

Скоро увек, избор готовог решења значиtrade-off: you get speed and an easy start, but you lose flexibility, control, and, potentially, security.

Ово је посебно важно у развоју агенса, где је важно управљати:

• непредвидивост ЛЛМс,
• сложена логика за транзиције и само-корекцију,
• бити спреман за прилагођавање и еволуцију система, чак и ако његови основни задаци остају непромењени.

Рамкови доносеinversion of control: они одлучују за вас како агент треба да ради.То може поједноставити прототип, али компликује његов дугорочни развој.

Многи од горе описаних принципа могу се имплементирати помоћу решења изван полице – и то је често оправдано.explicit implementation of the core logic takes a comparable amount of timeи даје неспоредљиво вишеtransparency, manageability, and adaptability.

Постоји и супротна екстрема -over-engineering, жеља да се све напише од нуле.То је такође грешка.

This is why the key is balance.Инжењер бира за себе: где је разумно ослањати се на оквир, и где је важно одржавати контролу.

Морате запамтити: индустрија још увек узима облик. Многи алати су креирани пре него што су се појавили актуелни стандарди. Сутра, они могу постати застарели - али ограничења која се пеку у вашој архитектури данас ће остати.

Conclusion

У реду, прешли смо 15 принципа који, показује искуство, помажу да се почетно узбуђење "то је живо!" претвори у поверење да ће ваш ЛЛМ агент радити на стабилан, предвидљив и користан начин под реалним условима.

Trebalo bi da razmotrite svaku od njih da biste videli da li ima smisla da je primenite na vaš projekat.

Key takeaways to carry with you:

1. Инжењерски приступ је кључ: Не ослањајте се на "магију" ЛЛМ. Структура, предвидљивост, управљања и тестирање су ваши најбољи пријатељи.
2. ЛЛМ је моћна компонента, али ипак само компонента: Третирајте ЛЛМ као веома паметан, али ипак, јединствену компоненту вашег система.
3. Итерација и повратне информације су кључ успеха: Ретко је креирати савршеног агента на првом покушају. Будите спремни за експерименте, мерења, анализу грешака и континуирано побољшање - и самог агента и ваших развојних процеса.
4. Заједница и отвореност: Поље ЛЛМ агента се брзо развија. Држите поглед на нова истраживања, алате и најбоље праксе, и поделите своја искуства.

Надам се да сте овде пронашли нешто ново и корисно, а можда ћете чак и желети да се вратите на ово док дизајнирате свог следећег агента.