Multi-Agent, A2A систем: CTO нарын заавал мэдэх ёстой архитектур

Хиймэл оюун ухааны хөгжил дан ганц LLM-тай харилцахаас давж, тусгай үүрэг бүхий олон агентууд хоорондоо харилцаж, бие даан шийдвэр гаргах түвшинд хүрлээ. Үүнийг технологийн салбарт Agent-to-Agent буюу Multi-Agent систем гэж нэрлэж байна.

CTO болон технологийн удирдлагуудын хувьд энэ нь зөвхөн шинэ тренд биш, харин системийн архитектур, өгөгдлийн урсгал, үйл ажиллагааны автоматжуулалтыг дахин тодорхойлох суурь өөрчлөлт юм. Нэг том загварт бүх даалгаврыг өгөх нь алдаа гаргах, төөрөгдөл үүсгэх эрсдэлтэй байдаг бол олон агентын систем нь үүрэг хариуцлагын заагийг бий болгож, илүү найдвартай ажиллагааг хангадаг.

Энэхүү нийтлэлийг уншсанаар та Multi-Agent систем түүний ашиглаж буй Agent-to-Agent протокол хэрхэн ажилладаг, ямар архитектурын загварууд байдаг, өөрийн байгууллагад нэвтрүүлэхэд ямар эрсдэл болон давуу талууд үүсэх, мөн уламжлалт системээс юугаараа ялгаатай болохыг техникийн болон бизнесийн үнэ цэнийн үүднээс гүнзгий ойлгох болно.

1. Агентууд хэрхэн хоорондоо харилцдаг вэ?

Агент хоорондын систем нь зүгээр л олон API дуудалтуудын цуглуулга биш юм. Агент бүр өөрийн гэсэн зорилго, санах ой, ашиглах боломжтой багаж хэрэгсэл буюу tools, мөн бусад агентуудтай мэдээлэл солилцох Агент-Агент (A2A) протоколтой байдаг. Практик хэрэгжилтэд эдгээр системүүд дараах үндсэн механизмууд дээр тогтдог:

• Төлөвийн удирдлага (State Management): Агентуудын харилцан яриа болон ажлын явц нь дундын санах ойд хадгалагддаг. Энэ нь ихэвчлэн Redis эсвэл PostgreSQL зэрэг өгөгдлийн санд graph бүтцээр эсвэл цуваа байдлаар хадгалагддаг бөгөөд шаардлагатай үед өмнөх алхам руу буцах боломжийг олгодог.
• Мэдээлэл дамжуулах (Message Passing): Агентууд нэг нэгэн рүүгээ бүтэцлэгдсэн өгөгдөл (ихэвчлэн JSON форматтай) эсвэл тохируулсан харилцааны хэлээр мессеж илгээдэг. Энэхүү мессеж нь дараагийн агентын хувьд оролт (prompt) болж хувирна.
• Багаж хэрэгслийн дуудалт (Tool Calling): Агент зөвхөн текст боловсруулаад зогсохгүй, гадны системтэй (жишээ нь: мэдээллийн сан руу SQL query бичих, вэбээс мэдээлэл татах, API дуудах) шууд харилцдаг. Агент бүрт зөвхөн өөрийнх нь үүрэгт тохирсон хязгаарлагдмал эрх бүхий багажуудыг өгөх нь аюулгүй байдлын хувьд чухал.

Эдгээр механизмыг удирдахын тулд LangGraph олон агентын архитектур эсвэл AutoGen зэрэг фреймворкүүдийг өргөнөөр ашиглаж байна.

2. Архитектурын загварууд ба тэдгээрийн хэрэглээ

Бүх олон агентын систем ижил бүтэцтэй байдаггүй. Таны шийдэж буй асуудлын мөн чанараас хамааран доорх архитектурын загваруудаас сонгох шаардлагатай.

Менежер-Ажилтан (Hierarchical / Supervisor)

Энэ загварт нэг Удирдагч агент (Supervisor) байх бөгөөд тэрээр хэрэглэгчээс ирсэн даалгаврыг жижиг хэсгүүдэд хувааж, тусгай чиглэлийн агентуудад хуваарилдаг.

• Хэзээ ашиглах вэ: Тодорхой шат дамжлага бүхий, нарийн төвөгтэй даалгавруудыг удирдахад тохиромжтой.
• Давуу тал: Хяналт тавихад хялбар, ажлын урсгал нь ойлгомжтой.
• Сул тал: Удирдагч агент дээр хэт их ачаалал ирэх эсвэл тэр алдаа гаргавал бүх систем гацна (Single point of failure).

Зэрэгцээ болон Мэтгэлцэх (Peer-to-Peer / Debate)

Агентууд тэгш эрхтэйгээр хоорондоо харилцаж, нэгнийхээ гаргасан үр дүнг шалгаж, шүүмжилж, сайжруулдаг.

• Хэзээ ашиглах вэ: Бүтээлч шийдэл шаардсан, эсвэл өндөр нарийвчлал шаардсан аналитик ажлуудад (жишээ нь: кодын аюулгүй байдлыг шалгах).
• Давуу тал: Хиймэл төөрөгдлийг (hallucination) маш сайн бууруулдаг. Нэг нь алдаатай код бичихэд нөгөөх нь шалгаж буцаадаг.
• Сул тал: Токен (token) ашиглалт маш өндөр гарна. Хугацаа их шаардана.

Дараалсан дамжлага (Sequential Pipeline)

Үйлдвэрийн дамжлагатай ижил. Агент А нь мэдээлэл цуглуулж, Агент Б нь түүнийг боловсруулж, Агент В нь тайлан бичнэ.

• Хэзээ ашиглах вэ: Урьдчилан таамаглах боломжтой, тогтмол дараалалтай өгөгдөл боловсруулах процессуудад.
• Давуу тал: Найдвартай, зардал багатай, дибаг хийхэд хамгийн амар.

3. Хэрэглээний жишээнүүд

Технологийн багууд Multi Agent системийг дараах чиглэлүүдэд илүүтэй нэвтрүүлж, хэмжигдэхүйц сайжруулалт хийж байна.

Програм хангамж хөгжүүлэлтийн автоматжуулалт

Хэрэглэгчийн шаардлагыг хүлээн авч бүтээгдэхүүний менежер агент (Product Manager Agent) техникийн даалгавар бичнэ. Уг даалгаврыг хөгжүүлэгч агент (Coder Agent) уншиж код бичих бөгөөд тестийн агент (QA Agent) кодыг ажиллуулж үзээд алдаа гарвал буцааж хөгжүүлэгч рүү илгээдэг. Энэхүү мөчлөг нь хүний оролцоогүйгээр хэд хэдэн удаа давтагдаж, бэлэн болсон кодыг хөгжүүлэгчдэд хүлээлгэн өгдөг.

Нарийн төвөгтэй хэрэглэгчийн үйлчилгээ

Хэрэглэгчээс ирсэн гомдлыг нэг агент хүлээн авч үнэлээд, хэрэв техникийн асуудал байвал мэдээллийн сангаас хайлт хийдэг "Техникч" агент руу, харин төлбөр тооцооны асуудал байвал ERP системтэй холбогддог "Санхүүгийн" агент руу шилжүүлдэг. Ингэснээр хэрэглэгч рүү өгөх хариу илүү хурдан бөгөөд оновчтой болно. Google Cloud AI Agents үнэ цэнийн жишээ зэргээс томоохон байгууллагуудын туршлагыг харж болно.

Өгөгдлийн гүнзгий шинжилгээ ба тайлагнал

Байгууллагын дотоод олон эх сурвалжаас өгөгдөл цуглуулах, түүнийгээ цэвэрлэх, тренд тодорхойлох, эцэст нь удирдлагын түвшний уншихад хялбар тайлан болгон нэгтгэх ажлыг 3-4 тусгай агентын гинжин хэлхээгээр шийдвэрлэх.

4. Эрсдэл, хязгаарлалт ба давуу/сул талуудын харьцуулалт

Олон агентын систем нь хүчирхэг боловч төгс биш юм. CTO нарын зайлшгүй анхаарах ёстой эрсдэлүүд бий.

• Хязгааргүй давталт: Хоёр агент хоорондоо санал нийлэхгүй үед (жишээ нь, хөгжүүлэгч агент алдаагаа засаж чадахгүй байх, шалгагч агент түүнийг нь дахин дахин буцаах) хязгааргүй давталт үүсэх эрсдэлтэй.
  
  Шийдэл: Архитектурын түвшинд дээд тал нь харилцах тоог (max iterations) үргэлж хатуу зааж өгөх хэрэгтэй.
• Зардал болон хурдны өсөлт: Нэг агент дунджаар 2-3 удаа LLM дууддаг. Хэрэв системд 5 агент байгаа бөгөөд тэд хоорондоо 4 удаа солилцвол нийт 50-60 LLM дуудалт хийгдэх бөгөөд энэ нь хариу өгөх хугацааг хэдэн минутаар сунгаж, API зардлыг огцом өсгөдөг.
• Алдааг хянах төвөгтэй байдал: Систем нь детерминистик биш (non-deterministic) буюу ижил оролт өгөхөд яг ижил замаар ажиллах албагүй байдаг тул хаана алдаа гарсныг хянахад хэцүү. Хянах боломж (observability)-ийг эхнээс нь зөв төлөвлөхгүй бол хяналтаас гарна.
• Аюулгүй байдал: Хэрэв нэг интернетээс мэдээлэл хайдаг агент хортой код (prompt injection) агуулсан сайт уншвал, тэрхүү хортой зааварчилгааг дотоод өгөгдлийн сантай харилцдаг өөр агент руу дамжуулах магадлалтай.

5. Шийдвэр гаргах шалгуурууд

Технологийн удирдлагуудын хувьд шинэ асуудал гарч ирэх бүрд олон агентын систем рүү шууд орох нь буруу юм. Дараах шалгуураар шийдвэр гаргахыг зөвлөж байна.

1. Уламжлалт код / Загварчилсан ажлын урсгал: Асуудал нь тодорхой дүрмээр шийдэгдэх боломжтой, алхам бүр нь урьдчилан таамаглагдах бол LLM болон Агент ашиглах хэрэггүй. Уламжлалт код хамгийн хурдан бөгөөд найдвартай.
2. Нэг агентын систем: Даалгавар нь тодорхой боловч гадны системээс мэдээлэл татах, хайх шаардлагатай, үр дүнг нэгтгэх хэрэгтэй үед (жишээ нь, энгийн RAG систем). Хэрэгжүүлэхэд хялбар, зардал бага.
3. Олон агентын систем: Даалгавар нь олон өөр төрлийн мэдлэг (domain expertise) шаарддаг, шийдвэрлэхэд олон өнцгөөс дүгнэх хэрэгтэй, эсвэл алдааг бие даан засах зайлшгүй шаардлагатай үед.

6. Түгээмэл гардаг алдаанууд ба түүнээс сэргийлэх нь

Практик хэрэгжилтийн үед инженерийн багуудын гаргадаг хамгийн нийтлэг алдаанууд:

• Хэт ерөнхий дүрийн тодорхойлолт: Агентын промпт дотор "Чи бол ухаалаг туслах" гэх мэт ерөнхий зүйл бичих нь агентуудын дунд үүрэг хариуцлагын давхардал үүсгэдэг. Агент бүрийн промпт нь маш тодорхой, "юуг хийхгүй байх" тухай хатуу хязгаартай байх ёстой.
• Хүний хяналтыг (Human-in-the-loop) орхих: Системийг 100% бие даан ажиллах түвшинд шууд хүргэх гэж оролдох нь эрсдэлтэй. Ялангуяа мөнгөн гүйлгээ хийх, үйлдвэрийн систем рүү тохиргоо илгээх зэрэг чухал алхмууд дээр заавал хүний баталгаажуулалт хүлээдэг (approval node) архитектур турших хэрэгтэй.
• Хэт олон багаж өгөх: Нэг агентэд 10-20 өөр багаж (tools) ашиглах эрх өгөхөд загвар аль багажийг дуудахаа мэдэхгүй төөрөх үзэгдэл их гардаг. Үүний оронд 3-4 багажтай хэд хэдэн жижиг агентууд үүсгээд хооронд нь холбох нь илүү үр дүнтэй.

7. Гол дүгнэлтүүд

• Архитектурыг энгийнээс эхэл: Шууд 10 агент хоорондоо мэтгэлцдэг систем бүү угсар. Нэг удирдагч, хоёр ажилтан агент бүхий энгийн урсгалаас эхэлж, систем хэрхэн ажиллаж байгааг ажигла.
• Хяналт ба Хэмжилт: Агентуудын харилцан яриа болон алхам бүрийг OpenTelemetry эсвэл ижил төстэй системээр бүрэн бүртгэж авах ёстой. Эс бөгөөс алдааг илрүүлэх боломжгүй болно.
• Зардлын удирдлага: Бүх агентад хамгийн том, үнэтэй загварыг (жишээлбэл GPT-4 эсвэл Claude 3.5 Sonnet) ашиглах шаардлагагүй. Чиглүүлэгч (router) болон хялбар боловсруулалт хийдэг агентуудад жижиг, хурдан загваруудыг (GPT-4o-mini эсвэл Llama 3) хослуулан ашиглах нь зардлыг эрс бууруулна.
• Үнэ цэнийн баталгаажуулалт: Олон агентын систем нь хөгжүүлэлтийн хувьд нүсэр байдаг. Тиймээс эхлээд бизнесийн гол урсгалын нэг жижиг хэсгийг л автоматжуулж, үр дүнг хэмжсэний дараа цар хүрээгээ тэлэх нь зүйтэй.