Агентын гүйцэтгэлийг сайжруулахыг зорьж буй ихэнх AI баг ижил арга хэрэглэдэг: том контекстийн цонх, олон баримт бичиг, илүү ухаалаг өгөгдөл. Энэ нийтлэл үүнийг бүхэлдээ буруу зөн совин гэж үзэж байна. Дутуу байгаа зүйл нь илүү их мэдээлэл биш. Хяналт юм. Зөв зохиосон хяналтын давхарга л туршилтын үзүүлэн дээр ажилладаг агентыг үйлдвэрлэлийн орчинд ажилладаг агентаас ялгадаг.
AI агентдаа том санах ой, олон баримт бичиг эсвэл урт контекстийн цонх өгөх нь түүнийг ухаалаг болгохгүй, зөвхөн удаан, өндөр зардалтай болгоно. Жинхэнэ ахиц нь бүхнийг нэг дор хэрэглэх бус, хэрэгтэй зүйлээ хэрэгтэй үед нь сонгохыг агентад сургахад бий.
Найдвартай байдал загвараас бус, давталтаас үүддэг. Үзүүлэн дээр сэтгэгдэл төрүүлдэг агент, үйлдвэрлэлийн орчинд найдвартай ажилладаг агент хоёрын ялгаа нь AI-ийн чанарт бус, систем өөрийн ажлыг шалгадаг эсэхэд оршино. Алхам бүрд төлөвлөж, үйлдэж, ажиглаж, баталгаажуулдаг агентууд итгэлтэйгээр буруу хийхийн оронд алдаагаа өөрсдөө илрүүлдэг.
Өнөөгийн ихэнх AI агент үндсэндээ нэмэлт алхамтай чатбот бөгөөд зөв явж буй эсэх, хэзээ зогсох, хэзээ өөр арга туршихаа мэдэх механизмгүй. Амжилтын тодорхой шалгуур, бүтэцтэй төлөв, баталгаажуулах шалгалт бүхий зөв хяналтын давхарга л агент маягийн объектыг үнэхээр итгэж болох зүйл болгоно.
Өчигдөр өдрийн хоолондоо юу идсэн бэ?
Та «өчигдөр + өдрийн хоол»-д хүрэх хүртлээ бүх дурсамжаа эхнээс нь сэргээгүй байх. Харин эдгээр ойлголт хадгалагддаг туршлагынхаа хэсэг рүү шууд очсон. Энэ бол агент бүтээхэд тустай сэтгэлгээний загвар:
Асар том контекстийн цонх бол санах ой биш.
Татаж авсан овоолсон баримт бичиг бол ойлголт биш.
Урт бодлын хэлхээ бол найдвартай байдал биш.
Эдгээр нь орц төдий. Харин агент-ыг жинхэнэ агент мэт болгодог зүйл нь тархи амьдралынхаа бүх түүхийг хүчээр нэгждэггүйтэй адилхан: хяналт.
Саяхны Agentic Reasoning for Large Language Models судалгаа бидний бүтээх явцдаа мэдэрч ирсэн өөрчлөлтийг тун сайн нэгтгэн нэрлэсэн: загварын дотор сэтгэн бодохоос харилцан үйлчлэлээр дамжин сэтгэн бодох руу шилжиж байна. Энэ нийтлэл уг судалгааны хураангуй биш. Харин уг өөрчлөлтийг системийн практик загварт буулгах оролдлого юм:
Агентыг хэрэгсэлтэй чатбот шиг бүтээвэл чатботын алдаанууд үргэлжилнэ, зөвхөн алдаа нь илүү өндөр өртөгтэй болно.
Хэсэг хугацаанд «загварыг ухаалаг болгох» үндсэн арга маань илүү сайн өгөгдөл, бодлын хэлхээ, өөртэйгөө нийцэх байдал / түүвэрлэлтэд суурилсан сайжруулалт, магадгүй бага зэрэг хайлт байлаа.
ReAct нь «бодол → үйлдэл → ажиглалт»-ыг жам ёсны мэт болгосон эргэлтийн цэг байв. Гэхдээ далд хязгаарлалтыг анзаараарай: үүний ихэнх нь «илүү олон токентой нэг оролдлогын дүгнэлт» болж дуусдаг. Судалгааны тайлбар илүү оновчтой: агентлаг сэтгэн бодох нь туршилтын үеийн харилцан үйлчлэлийг өргөжүүлж, дүгнэлтийг загвар, санах ой, орчин бүгд давталтад оролцдог давтагдах үйл явц болгоход төвлөрдөг.
Үзүүлэн дээр гайхалтай ч бодит ажлын урсгалд хэврэг агент бүтээж (эсвэл ашиглаж) байсан бол энэ танд зориулагдсан.
Байнга тааралддаг (өөрөө ч хэд хэдэн хувилбарыг нь бүтээсэн) нэг загварыг тайлбарлая:
Сайн чат загвар авна
Хэдэн хэрэгсэл нэмнэ (хайлт, DB хүсэлт, магадгүй код ажиллуулах)
RAG нэмнэ
«you are an autonomous agent» гэсэн системийн өгөгдөл нэмнэ
Зогсох эсвэл хугацаа дуусах хүртэл бүгдийг while давталтад орооно
Баяр хүргэе, та агент маягийн объекттой боллоо. Гэхдээ энэ нь урьдчилан таамаглаж болох байдлаар бүтэлгүйтдэг:
Контекст хэт тэлэх: ажиглалт бүрийг залгаж нэмсээр өгөгдөл нь археологийн үе давхарга шиг болно.
Хэрэгслээ таамгаар ашиглах: «буруу хэрэгслийг итгэлтэй ашиглах» нь үндсэн алдааны горим болно.
Зогсох нөхцөлгүй: зогсох ёстой эсэхээс үл хамааран үргэлжлүүлэх боломжтой учраас л цаашилна.
Үндэслэлийн дэггүй: хүчээр шалгуулахгүй бол буруу байгаагаа анзаарахгүй.
Санах ой = чатын түүх: үндсэндээ лог бичээд үүнийгээ суралцаж байна гэж нэрлэдэг.
Иймээс «агентууд» үзүүлэн дээр ид шидийн мэт боловч үйлдвэрлэлийн орчинд замбараагүй санагддаг. Агентлаг системийг үйлдвэрлэлд нэвтрүүлсэн бидний туршлага ч үүнийг батална: загвар бус системийг үнэлж эхлэхэд алдааны горимд чиглүүлэлт, хэрэгслийн зөв хэрэглээ, контекст танах, үнэлгээний загвар зэрэг багтана. Өөрөөр хэлбэл зөвхөн «загвар зөв хариулсан уу» гэдгээр хязгаарлагдахгүй.
Тэгвэл зориулалтын агент гэж юу вэ?
Үүнийг илүү ойлгомжтой болгохын тулд ихэнх хүний төсөөлж чадах энгийн ажлын урсгалыг харъя: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Түгээмэл «агент маягийн» хэрэгжүүлэлт ийм байдаг:
Одоохондоо хэрэггүй байсан ч агаарын тээврийн компани / аяллын бодлогын олон баримт бичгийг шууд татна.
Хайлтын хэрэгсэл дуудаж, үр дүнгийн урт жагсаалтыг өгөгдөлд хуулан оруулаад «нэгийг нь сонгоно».
Хязгаарлалтуудыг (ирэх цаг / тээш / суудал / бодлого) шалгалгүйгээр яаран захиална.
Бүтэлгүйтвэл арай өөрөөр дахин оролдох ч юу өөрчлөгдсөн, юу сурснаа тодорхой мэдэхгүй.
Асуудал нь загвар сэтгэн бодож чадахгүйдээ биш, систем ажлын урсгалыг хянадаггүйд оршино.
Илүү агентлаг хувилбар нь даалгаврыг ил тод төлөв, шалгалт бүхий харилцан үйлчлэлт үйл явц гэж үзнэ:
ТӨЛӨВЛӨХ: хязгаарлалтуудыг давтан тодорхойлоод дутуу мэдээллийг жагсаах (жишээ нь, “which airport preference?” / “is 1 stop ok?”).
ҮЙЛДЭХ: бүтэцтэй хүсэлтээр нислэг хайх (огнооны хүрээ, ирэх цагийн хязгаар, төсөв).
АЖИГЛАХ: үр дүнг бүхэлд нь хуулсан асар том бөөгнөрөл бус, авсаархан төлөвийн объектод хадгалах (үнэ/ирэх цаг/дамжин нислэг бүхий шилдэг 5 сонголт).
ШИНЭЧЛЭХ: хязгаарлалтууд хангагдахгүй бол хүсэлтийг нарийвчлах (жишээ нь, “arrival before 6pm is too strict—widen time window or raise budget?”).
БАТАЛГААЖУУЛАХ: баталгаажуулагч ажиллуулах (“arrival < 18:00,” “price ≤ £900,” “policy compliant,” “seat selection available”).
ЗОГСОХ: зөвхөн захиалгын API баталгаажуулалт буцааж, бүх баталгаажуулагчийн шалгалтыг давсны дараа.
Өөрчлөлт нь үл анзаарагдам мэт боловч шийдвэрлэх ач холбогдолтой. Мэдээлэл таталт нөхцөлтэй (рефлекс биш), контекстийг удирддаг (төлөвийг хуримтлуулах бус, бүтэцчилдэг), баталгаажуулалт давталтад багтдаг (хэрэглэгчид даатгадаггүй). «Нислэг захиалах»-ыг «худалдан авах захиалга үүсгэх», «буцаан олголт хийх», «үйлдвэрлэлийн тохиргоо өөрчлөх» эсвэл «PR хүргэх»-ээр солиод ч мөн адил: агент үйлдэх чадвартай болмогц давталт нь өгөгдлөөс илүү чухал болдог.
Дээр дурдсан судалгаанд агентлаг сэтгэн бодохыг суурь (төлөвлөлт/хэрэгсэл ашиглалт/хайлт), өөрөө хөгжих (санал хүсэлт + санах ой), хамтын (олон агентын зохицуулалт) гэсэн гурван түвшинд ангилжээ.
Гэхдээ гол санаа нь: сэтгэн бодох чадвар нь үнэмшилтэй бодлын хэлхээ үүсгэх төдий бус, төлөвлөлт, шийдвэр гаргалт, баталгаажуулалтыг зохион байгуулах үндсэн зарчим болдог. Үүнийг архитектурын өөрчлөлттэй холбож үзэх хүртэл хийсвэр сонсогдоно. Санах ёстой гурван гол зүйл бий:
Сайн агент мэдээлэл татахыг «үргэлж хийдэг зүйл» гэж үзэх ёсгүй. Мэдээлэл татах нь рефлекс бус, шийдвэр юм.
Хэрэгжүүлэхэд хялбар нэг баримжаа:
Хэрэв систем тань алхам бүрд мэдээлэл татдаг бол та таталтын систем бус, контекстийн татвар бүтээжээ.
Энэ нь бодит ажил дээр байнга тохиолддог. Үйлдвэрлэлийн орчны доголдлыг оношлохдоо бүх логийг контекст рүү асгахгүй; одоогийн таамагтаа үндэслэн дараа нь аль хэмжүүр, логийг татахаа шийддэг. Үүнийг «агентлаг мэдээлэл таталт» гэнэ. Илүү тодорхой загвар нь:
Мэдээлэл татах шаардлагатай эсэхийг шийдэх
Тийм бол: хүсэлт боловсруулах, татах, гүйлгэн үзэх, хэрэгтэйг ялгах
Нотолгоо зөрчилдвөл: дахин татах
Зөвхөн дараа нь нэгтгэн дүгнэх
Эндээс «агентлаг RAG» уламжлалт RAG-аас ялгарч эхэлнэ: мэдээлэл татах нь өгөгдмөл дамжлагын үе шат биш, зориудын сэтгэн бодох алхам болдог.
«Загвар»-ыг биш, «систем»-ийг үнэлж эхлэх тэр мөчөөс төлөвийг хянах, үйл явцыг мөрдөх нь чухал болдог.
Салбарынхан агентын ажлын урсгалын ажиглагдах байдлын талаар одоо илүү тодорхой ярьдаг болсон. Жишээлбэл, OpenAI-ийн Agents SDK нь суурилагдсан мөрдөлт болон агентын ажилласан үйл явцыг (үүсгэлт, хэрэгсэл дуудалт, шилжүүлэлт, хамгаалалтын хязгаарлалт, тусгай үйл явдал) бүртгэдэг Traces хяналтын самбартай. Ингэснээр юу болсныг алхам бүрээр нь оношилж, аудит хийх боломжтой.
Энэ бол «байвал зүгээр» боломж биш. Оношилж болдог систем, зөвхөн өнгөц мэдрэмжээр шалгаж болдог систем хоёрын ялгаа нь энэ.
Миний бодлоор уг судалгааны хамгийн хэрэгжүүлэхэд хялбар хэсэг нь санал хүсэлтийн талаар маш шулуухан өгүүлсэн явдал. Санал хүсэлтийг эргэцүүлсэн санал хүсэлт (үүсгэх → шүүмжлэх → засах), параметрийн дасан зохицол (нарийн тохируулга / RL-ээр суралцах), баталгаажуулагчид тулгуурласан санал хүсэлт (баталгаажуулагчийн шалгалтыг давах хүртэл дахин оролдох) гэсэн гурван горимд хуваажээ.
Ихэнх баг баталгаажуулагчид тулгуурласан санал хүсэлтээс эхлэх хэрэгтэй. Энэ нь сонирхол татахгүй ч үр дүнтэй. Хэрэв та нэгжийн тест ажиллуулдаг, схем шалгадаг, бизнесийн дүрэм / хязгаарлалт тогтоодог («X-ээс дээш үнийн дүнг шат ахиулалгүй буцаан олгохгүй»), эсвэл баримтын үнэн зөвийг нягталдаг («эшлэл заавал шаардлагатай») ямар нэгэн баталгаажуулагч бичиж чадвал тодорхой бус загварын гаралтыг үнэхээр итгэж болох зүйл болгож чадна.
Эндэхийн «мэдэхгүйгээ ч мэдэхгүй» нэг өөрчлөлт энгийн: агентын ертөнцөд найдвартай байдал нь ихэнхдээ загвараас бус, давталтаас үүддэг.
Сургалтгүйгээр зан төлөвийг найдвартай сайжруулдаг миний олсон хамгийн энгийн давталтын дэг ийм:
Алхмаар ажилла: Төлөвлөх → Үйлдэх → Ажиглах → Шинэчлэх,
Үйлдэл бүрийн дараа ажиглалтаа 1–3 зүйлээр хураангуйл,
Амжилтын шалгуур хангагдах эсвэл төсвийн хязгаарт хүрэхэд зогс; тухайн үеийн хамгийн сайн үр дүн болон үлдсэн тодорхойгүй зүйлсийг буцаа.
Энэ нь загварыг нуршуу болгох тухай биш. Харин системийг ойлгомжтой болгож, алхам бүрд «бодит байдалтай тулгах» тухай юм. Инженерүүдэд тун ойлгомжтой жишээ бол CI маягийн хаалттай давталттай үндэслэл юм:
Төлөвлөх: өөрчлөлтийн жагсаалт санал болгох
Үйлдэх: тест / lint ажиллуулах
Ажиглах: алдаануудыг задлан унших
Шинэчлэх: засварлаад дахин оролдох
Санамсаргүйгээр агент маягийн загвар хийснийг илчилдэг хэдэн асуулт:
«Миний агент юу татаж авахаа өөрөө сонгодог уу, эсвэл би үргэлж татдаг уу?»
Мэдээлэл татах үйлдэл нөхцөлгүй бол хариуны саатал, зардал, контекстийн сарнилт нэмэгдэж, муу оролтоос муу гаралт үүсэх эрсдэл өснө.
«Миний агент буруу байгаагаа анзаарч чадах уу?»
Хэрэв агентын тань цорын ганц санал хүсэлт «хэрэглэгч бухимдах» бол та хүнийг зовоож байж RL хийж байна гэсэн үг. Баталгаажуулагчид тулгуурласан дахин оролдох давталт нь бодит байдалтай тулгах хамгийн цэгцтэй арга.
«Санах ойд бичиж болдог уу, мөн энэ нь цаг хугацааны явцад сайжирдаг уу?»
Хэрэв таны «санах ой» зөвхөн чатын түүхийг залгаж бичдэг бол та үндсэндээ лог хөтөлж байна. Судалгаанд санах ойг тайлбарласан нь чухал: санах ой бол зүгээр нэг ярианы бичлэг биш, агентуудын цаг хугацааны явцад сайжруулдаг, динамикаар тэлэх контекст юм.
Лог юу болсныг хэлдэг бол санах ой дараагийн удаа юу хийхийг хэлдэг. Чатын түүх бол ярианы бичлэг. Санах ой бол юуг цааш хадгалах нь зүйтэйг шийддэг, байнга хувьсах бодлого юм.
Эхлэхэд тохиромжтой хувилбар бол даалгаврын төрөл, хэрэгсэл, алдааны горимоор түлхүүрлэж, юу үр дүнтэй байсан болон юунаас зайлсхийхийг утга болгон хадгалсан жижигхэн «сургамж» хүснэгт юм. Зорилго нь төгс мэдлэгийн граф байгуулах биш. Зорилго нь үр нөлөө нь хуримтлагдах зан төлөв бий болгох: санах ой + санал хүсэлт нь агентуудыг «төлөвгүй туслах»-аас цаг хугацааны явцад сайжирдаг систем болгон хувиргана.
Асуудалд улам олон агент дайчлах сонирхол төрдөг ч энэ нь зохицуулалтын нэмэлт ачааллыг ихэвчлэн үржүүлдэг. «Ажиллах боломжтой хамгийн жижиг баг»-ийн сайн загвар:
Зохицуулагч: задлах + хуваарилах
Гүйцэтгэгч: хэрэгсэл дуудах / өөрчлөлт хийх
Шүүмжлэгч/үнэлэгч: зөв эсэх/эрсдэлийг шалгах
Санах ой хариуцагч: сургамж бичих/эмхлэх
Агент бүр юу хариуцахыг тайлбарлаж чадахгүй бол танд одоохондоо олон агент хэрэггүй байх.
Хэрэв бид энэхүү парадигмын өөрчлөлтийг үнэхээр хүлээн зөвшөөрвөл бүхнийг өгөгдөлд чихэх, бүтэлгүй оролдлогыг эцсийн гаралт гэж үзэх, агентыг чатбот шиг үнэлэхээ болино. Харин агентыг байгаагаар нь буюу хэл нь хяналтын хавтгай болдог програм хангамжийн систем гэж үзэж эхэлнэ. Найдвартай байдал нь давталтаас үүддэг.
Өөр загвар нэмэхээсээ өмнө өөр үнэлгээний давталт нэм. Бүхнийг татахаасаа өмнө уг үйлдлийг нөхцөлтэй болго. Арвыг нэвтрүүлэхээсээ өмнө нэг баталгаажуулагч нэвтрүүл. Санах ойг өгөгдлийн сан бус, бодлогын шийдвэр гэж үз. Олон агент руу шилжихдээ хорин агентаас бус, хоёроос эхэл. Эдгээр нь дүрэм биш, үйлдвэрлэлийн орчны шалгуурыг давсан загварууд юм.