erxes AI Agents — Mastra-д суурилсан агент платформыг CRM дотор 12 хоногт бүтээсэн нь

Юуны учир ийм зүйл хэрэгтэй болов? (энгийн хэлээр)

Танд жижиг бизнес байна гэж төсөөлье. Харилцагчдын мэдээлэл, борлуулалтын гэрээ, хийх ажлууд, чатын яриа — бүгд CRM дотор хадгалагдаж байна. Гэвч ямар нэг зүйл мэдэхийн тулд та арав хорин цонх дамжин товшиж, шүүлтүүр тохируулж, тайлан нэгтгэх хэрэгтэй болдог. Техникийн мэдлэггүй жирийн ажилтны хувьд энэ нь цаг их зарцуулдаг, заримдаа бүр боломжгүй ажил.

Миний бүтээсэн зүйл үүнийг өөрчилнө: та зүгээр л чат нээгээд, хүнтэй ярьж байгаа юм шиг асууна.

• "Энэ сард хэдэн шинэ харилцагч нэмэгдсэн бэ?" — агент тоолж хариулна.
• "Бат гэдэг харилцагчийн мэдээллийг гаргаад өгөөч" — агент олж ирнэ.
• "Шинэ гэрээ үүсгэ" — агент үүсгэнэ.
• "Долоо хоног бүр шинэ борлуулалтын хураангуйг надад илгээж бай" — агент өөрөө хийж эхэлнэ.

Хамгийн чухал нь: агент таны үзэх эрхгүй мэдээллийг хэзээ ч харуулахгүй. Хэрэв тухайн өгөгдлийг та системд орж үзэх эрхгүй бол агент ч мөн үзүүлэхгүй — яг л итгэмжит хүн туслахтай адил, гэхдээ хэзээ ч ядардаггүй, шөнө ч ажилладаг.

Энэ бол энгийн хэрэглэгчийн хувьд "юу" болохын тухай. Одоо доороос нь "хэрхэн" болохыг — техникийн нарийн ширийнийг алхам алхмаар задалж үзье.

1. erxes гэж юу болох, агент платформ яагаад түүнд багтах учиртай вэ

Агентын талаарх ажил утга учиртай болохын тулд эхлээд тэр нь юуны дотор оршдгийг — тэрхүү зүйлийн ерөнхий бүтцийг мэдэх хэрэгтэй.

Энэхүү plugin архитектур бол энэ бүхэл кейс судалгааны хамгийн чухал ганц баримт. Яг үүний ачаар би байгаа plugin-уудын алийг нь ч өөрчлөхгүйгээр erxes-д цоо шинэ "AI Agents" бүтээгдэхүүн нэмж чадсан — мөн цаашид үзэх болно, агентыг бусад бүх plugin-тай автоматаар харилцах боломжийг ч энэ архитектур олгосон юм.

Миний тавьсан зорилго хэлэхэд амар, хийхэд хэцүү байлаа:

Техникийн бус энгийн бизнесийн хэрэглэгч чат нээж, AI агенттай ярианы хэлээр харилцаж, тэр агент нь өөрийнх нь erxes дотор бодитоор үйлдэл хийдэг — харилцагчийг хайх, deal үүсгэх, компанийн өгөгдлөөс хариулт өгөх, эсвэл давтагдах үйл явцыг автоматжуулах — гэхдээ хэзээ ч үзэх эрхгүй өгөгдлийг нь харуулахгүй байх.

2. Ажлын явц: хаягдах прототипээс эхлээд үйлдвэрлэл хүртэл

Би үүнийг ганц үсрэлтээр бүтээгээгүй. Түүхэн явц нь энэ хэрхэн төлөвшин боловсорсон тухай өгүүлнэ:

Алхам	PR	Юу нэмсэн
Прототип	#7799	Хаягдах agent-assistant plugin — зөвхөн "agent" өгөгдлийн entity болон CRUD UI-тай, plugin-ы суурь бүтэц (scaffolding) ажиллаж байгааг батлах зорилготой. DON'T MERGE гэж тусгайлан тэмдэглэсэн.
Суурь	#7985	Жинхэнэ хувилбар: erxes-agent plugin — агентууд, streaming чат, санах ой, RAG, workflow-ууд. +31,277 мөр / 201 файл. Merge хийгдсэн.
Цэвэрлэгээ	#7990	Статик шинжилгээний (static-analysis) илрүүлсэн 42 файлын асуудлыг шийдсэн — бүх any-г арилгаж, хэт төвөгтэй функцуудыг задалсан.
Тохиргоо	#7997	Агент тус бүрээр тохируулж болох temperature (бодит модель нийцлийн алдааг засаж).
Автоматжуулалт	#8004	Хуваарьт агент ажиллагаа — давтагдах cron дээр асдаг агентууд. +2,395 мөр / 34 файл.
Нэвтрүүлэх	#8006, #8007, #8008	Dockerfile, CI image build, release matrix болон CDN publishing — plugin-ыг үйлдвэрлэлийн серверүүд дээр бодитоор гарч ирэхэд хүргэдэг суурь дэд бүтэц (plumbing).

3. Архитектур — нэг зурагт

Энэ plugin нь бусад бүх erxes plugin-тай яг адил хоёр хагастай:

• erxes-agent_api — backend хэсэг, 3312 порт дээр ажилладаг Node үйлчилгээ. Агентууд, tool-ууд, санах ой, workflow-ууд эндээ оршдог.
• erxes-agent_ui — frontend хэсэг, ажиллах үед erxes хяналтын самбарт (dashboard) Module Federation remote болон ачаалагддаг.

Backend нь өөрөө тодорхой модулиудад хуваагдсан — agent, provider, tool, session, settings, schedule, memory, learning, workflow — бөгөөд тус бүр нь өөрийн өгөгдлийн модель, GraphQL schema-тай. Жинхэнэ оюун ухаан нь mastra/ давхаргад оршдог бөгөөд tools, memory, knowledge, workflows, schedules, files гэсэн дэд системүүдтэй.

4. Тулгуур 1 — Олон provider дэмжсэн агентууд ба streaming чат

Энэ plugin-ы цөм нь Mastra дээр бүтээгдсэн.

Хэрэглэгч агент (нэр, систем заавар, сонгосон модель) үүсгэж, чат эхлүүлж болно. Үүнийг бүтээхэд юу хийх шаардлагатай байсан бэ:

• Олон модель provider, ганц интерфейс. Vercel AI SDK-аар дамжуулан агентууд Anthropic (Claude), OpenAI, Google, Groq, Mistral, Cohere, эсвэл OpenAI-тэй нийцтэй дурын endpoint дээр — түүний дотор Kimi / K2 дээр ажиллах боломжтой. Provider болон тэдгээрийн бодит модель жагсаалтыг ажиллах үед татаж авдаг тул код өөрчлөхгүйгээр шинэ моделиуд гарч ирдэг.
• Хадгалагддаг яриа. Чат session болон түүний эргэлт бүрийг MongoDB-д хадгалдаг тул хуудас сэргээх юм уу сервер дахин асахад ч яриа алдагдалгүй хадгалагдана.
• Бүтээгдэхүүнийг гүйцэд мэт мэдрүүлэх нэмэлт жижиг зүйлс: LLM-ээр үүсгэсэн thread гарчиг, эргэлт бүрийн он цагийн дарааллын мөр (trace), мөн агент яг одоо юу хийж байгааг харуулсан нэг мөр шууд хураангуй.
• Файл хавсаргах. Хэрэглэгч чат руу PDF, Word баримт, эсвэл spreadsheet чирж оруулж болно; backend нь түүний текстийг (pdf-parse, mammoth, exceljs-ээр) задлан гаргадаг тул агент үнэхээр уншиж чаддаг.

5. Тулгуур 2 — Дэвшилтэт санах ой (агент таныг санаж байхын тулд)

Анхдагчаар агент нь төлөвгүй (stateless) — эргэлт бүр зөвхөн ойрын мессежийн түүхийг л хардаг. Энэ нь аюулгүй бөгөөд энгийн боловч агент session хооронд бүх зүйлийг мартдаг гэсэн үг. Тиймээс би ганц орчны флагаар (environment flag) асаадаг, сонголтоор идэвхждэг (opt-in) дэвшилтэт санах ойн давхарга нэмсэн.

Энэ нь хоёр хэсгээс бүрдэнэ:

1. Семантик дурсамж (semantic recall) — мессеж бүрийг embedding болгон хувиргаж, vector өгөгдлийн санд хадгалдаг. Шинэ эргэлт бүрд систем хамгийн хамааралтай өнгөрсөн хэсгүүдийг олж, чимээгүйхэн контекст рүү нэмдэг. Яг үүний ачаар агент таны гурван session-ы өмнө хэлсэн зүйлийг "санаж" чаддаг.
2. Ажлын санах ой (working memory) — таны болон даалгаврын тухай агентын өөрөө хөтөлдөг богино профайл ("англиар харилцахыг илүүд үздэг", "Flint төсөл дээр ажилладаг") бөгөөд MongoDB-д хадгалагдаж, эргэлт бүрийн дараа шинэчлэгддэг.

6. Тулгуур 3 — Компанийн мэдлэгийн RAG (хэцүү бөгөөд чухал хэсэг)

Энэ бол миний хамгийн их бахархдаг боломж. Зорилго нь: агентыг компанийн бүхий л үйл ажиллагааны өгөгдлийн сангаас — харилцагч, компани, deal, даалгавар, яриа, мэдлэгийн сангийн нийтлэлээс — асуултад хариулж чаддаг болгох, өгөгдөл өөрчлөгдөхөд шинэлэг хэвээр байлгах, бөгөөд хэрэглэгчийн үзэх эрхгүй бичлэгийг хэзээ ч задлахгүй байх.

Гол асуудал нь энд байна, бас нэлээд нарийн:

Бичлэг вектор болсон тэр агшинд л эрхээ алддаг. Vector өгөгдлийн сан хэн асууж байгааг огт мэддэггүй. Тиймээс хандалтын хяналтыг (access control) татаж авах яг тэр мөчид дахин босгох ёстой.

Би үүнийг хэдхэн бат тогтсон дүрмээр шийдсэн:

1. Векторт хэрэглэгчийн биш, бичлэгийн эрхийн шинж чанарыг хадгал. Вектор бүр тухайн бичлэгийг үзэхэд шаардагдах зүйлсийг агуулна — tenant (subdomain), контентын төрөл, эзэмшигч, салбар/хэлтэс, нийтэд нээлттэй эсэх. Энэ нь "X хэрэглэгч үүнийг үзэж болно" гэдгийг хэзээ ч шингээж хадгалдаггүй, учир нь хожим X-ийн эрхийг хүчингүй болговол вектор хэвээрээ "тийм" гэж хэлсээр байх болно — энэ бол өгөгдөл алдагдах эрсдэл.
2. Асууж буй хэрэглэгчийн одоогийн эрхийг хайлт хийх үед тодорхойл. Ингэснээр эрх хүчингүй болгох нь шууд хүчинтэй болно.
3. Хоёр удаа шүү — эхлээд бүдүүн, дараа нь эцсийн (эрлийз pre/post шүүлтүүр). Эхлээд vector хайлтын дотор ажилладаг хурдан pre-filter нь боломжит бичлэгүүдийн ~99%-ийг tenant болон төрлөөр нь хасна. Дараа нь post-filter үлдсэн бичлэгүүдийг erxes-ийн өөрийн resolver-уудаар дамжуулан, асууж буй хэрэглэгчийн нэрийн өмнөөс, бодит цагт дахин татаж авдаг — ингэснээр erxes-ийн жинхэнэ эрхийн логик эцсийн шийдвэр гаргагч болно. Юу ч дахин хэрэгжүүлээгүй; хэрэв erxes таниас UI дээр нуудаг бол агентаас ч мөн нуугдана.

Эдгээр бичлэгийн зарим төрөл нь хувийн мэдээлэл агуулдаг тул тэдгээрийг embed хийх нь төрөл тус бүрээр тусгайлан зөвшөөрөгддөг (opt-in) — энэ нь анхдагч тохиргоо биш, өгөгдлийн засаглалын (data governance) ухамсартай шийдвэр юм.

7. Тулгуур 4 — Бодит цагийн үйлдлийн бүртгэл (plugin бүрд зориулсан холбоос код тэг)

Зөвхөн ярьж чаддаг агент бол тоглоом. Түүнийг үйлдэл хийдэг болгохын тулд tool хэрэгтэй. Энгийн (гэнэн) арга нь erxes plugin тус бүрд зориулж нэгтгэлийг гараар бичих байх байсан ("deal-ийг ингэж үүсгэдэг, харилцагчийг ингэж олдог…") — тэдгээр нь хэдэн зуугаараа, мөнхөд хоцрогдсон байх болно.

Би эсрэгээр нь хийсэн. Би бодит цагийн үйлдлийн бүртгэл (live operation registry) бүтээсэн: ажиллах үед энэ нь erxes-ийн GraphQL gateway-г дотроос нь шинжилж (introspect), идэвхжсэн plugin бүрийн үйлдэл бүрийг илрүүлдэг. Агент тэрхүү бүртгэл дээр суурилсан "чадвар хайх" гэсэн ерөнхий tool, мөн "энэ үйлдлийг ажиллуул" гэсэн tool-той болдог.

Агент мөн багц суурин (built-in) tool-уудтай: вэб хайлт (DuckDuckGo-оор), URL татах, тооцоолуур, график зурагч (chart renderer), 6-р хэсэгт дурдсан companyKnowledge татах tool, мөн workflow-уудыг унших, ажиллуулах tool-ууд (дараагийн хэсэг).

8. Тулгуур 5 — Workflow-ууд (талсжсан агентын зан төлөв)

Чат хүчирхэг боловч түр зуурынх — агент зөвхөн хэн нэгэн бичиж байх зуур л үйлдэл хийдэг. Бизнест өөрөө бие даан, цаг, бүр өдрөөр ажилладаг процесс хэрэгтэй. Тиймээс би workflow цөм (kernel) зохион бүтээсэн.

Дизайныг цэвэрхэн болгосон ухаарал нь: ямар ч салбарын аливаа бизнес процесс ердөө таван үндсэн бүрдэл хэсэг (primitive) болж задардаг.

Бүрдэл хэсэг	Утга	Юугаар хэрэгждэг
Үйл явдал (Events)	ямар нэг зүйл болсон	триггерүүд (аль ч plugin-ы үйл явдал, цаг хугацаа, webhook, гараар дарах)
Чадвар (Capabilities)	ямар нэг зүйл хийж болно	7-р хэсгийн бодит цагийн үйлдлийн бүртгэл
Дүгнэлт (Judgment)	шийдвэрт оюун ухаан хэрэгтэй	агентын алхам (бүтэцлэгдсэн шийдвэр гаргадаг LLM)
Цаг хугацаа (Time)	процесс цаг, бүр долоо хоногоор үргэлжилдэг	тогтвортой ажиллагаа (durable runs), хүлээлт, хуваарь
Хүн (Humans)	зарим шийдвэр хүмүүст хамаатай	зөвшөөрлийн алхам (түр зогсох → хүнд мэдэгдэх → үргэлжлүүлэх)

Workflow гэдэг нь зүгээр л тэр таван хэсгийг угсардаг өгөгдөл. Харилцагчийн дэмжлэг, lead тордох, нэхэмжлэл нэхэх, onboarding — эдгээрийн бүгдийг цөмд ганц ч ойлголт нэмэлгүйгээр илэрхийлж болно. Би Mastra-гийн workflow хөдөлгүүр дээр суурилуулан жижиг DSL (тодорхойлох хэл), компайлер, тогтвортой runtime-ыг салаалалт, зэрэгцээ алхам болон аюулгүй нөхцөлийн хэлтэйгээр бүтээсэн.

Workflow бол талсжсан агентын зан төлөв юм. Процесс эхэндээ агентад түшсэн — "энэ үйл явдалд юу хийхээ ол" — байж болох бөгөөд урьдчилан таамаглах боломжтой шийдвэрүүд нь детерминист алхмуудаар солигдох тусам цаг хугацааны явцад бат бөх болдог: хямд, хурдан, аудит хийх боломжтой.

Үүний үр шим нь агент өөрөө workflow зохиож, ажиллуулж чаддагт оршино. Та процессоо чат дээр тайлбарлана; агент workflow-г бичнэ. Энэ нь бүтэн давталтыг — бүтээх → ажиллуулах → ажиглах → сайжруулах — бүгдийг яриагаар хаадаг. UI нь үүнийг index, дэлгэрэнгүй, форм хуудсууд болон workflow-гийн бодит цагийн график урьдчилсан харагдацаар бүрэн төгс болгодог.

9. Тулгуур 6 — Хуваарьт агент ажиллагаа (#8004)

Сүүлчийн боломж: агентыг давтагдах cron дээр prompt ажиллуулдаг болгох — "Даваа гараг бүрийн өглөөний 9 цагт өнгөрсөн долоо хоногийн шинэ deal-уудыг хураангуйл."

Энд сонирхолтой инженерчлэл нь дараалал (Redis) хэдийд ч цэвэрлэгдэж болох системд үүнийг найдвартай болгоход оршино:

• Идэвхжсэн хуваарь бүр BullMQ job scheduler болдог.
• 5 минут тутамд тулгах (reconcile) ажил ажиллаж, бодит дараалал болон MongoDB-д хадгалагдсан хуваарийг харьцуулан, тохирох болгохын тулд ажлуудыг нэмж эсвэл хасдаг.
• MongoDB бол үнэний ганц эх сурвалж. Тиймээс Redis цэвэрлэгдвэл дараагийн тулгалт хуваарь бүрийг автоматаар дахин босгодог — систем өөрийгөө эдгээдэг.
• Энэ нь multi-tenant-ыг ойлгодог (hosted SaaS горимд байгууллага тус бүрд нэг багц хуваарь), мөн эвдэрсэн cron илэрхийлэлтэй нэг хуваарийг тусгаарласнаар тэр нь бусдыг эвдэж чадахгүй.

10. Үйлдвэрлэлд гаргах нь — гялалзуулдаггүй сүүлчийн миль

Merge хийгдсэн PR гэдэг нь deploy хийгдсэн боломж биш. Гурван дараагийн PR plugin-ыг үйлдвэрлэлийн серверүүд дээр бодитоор байршуулсан суурь ажлыг хийсэн:

• #8006 — Dockerfile + CI image build. Хоёр шатлалт node:22-alpine image (build, дараа нь нимгэн runtime) болон түүнийг Intel, ARM хоёуланд нь нийтэлдэг GitHub Actions workflow. Энд илэрсэн нэг урхи: monorepo hoisting-ийн ачаар санамсаргүйгээр шийдэгдэж байсан нэг dependency-г тусгайлан зарлах шаардлагатай болсон, эс бөгөөс контейнер ачаалах үедээ унадаг байв.
• #8007 — release matrix. Шинэ API image-ийг release-tagging pipeline-д нэмснээр энэ нь хувилбар бүрийн хамт нийлүүлэгддэг болсон.
• #8008 — CDN publishing + Module Federation-ийн нэг урхи. Frontend remote нь CDN bucket-тэй синк хийгддэг тул dashboard түүнийг ачаалж чаддаг. 3-р хэсгийн "remote"-ыг санаж байна уу? Plugin-ы фолдер нь erxes-agent_ui (зураастай) боловч Module Federation-ийн контейнерийн нэр зураас агуулж болдоггүй — тиймээс loadRemote түүнийг хэзээ ч олж чадахгүй байв. Засвар нь зураастай фолдерийн замыг хэвээр үлдээж, runtime дахь remote нэрийг доогуур зураас (underscore) болгон хэвийн болгодог. Бүхэл UI-г үйлдвэрлэл дээр үл үзэгдэх болгодог нэг тэмдэгтийн төрлийн алдаа.

11. Кодыг шударга байлгах нь — чанар ба аюулгүй байдал

Гучин мянган мөр гэдэг бол асар их хэмжээний гадаргуу тул би чанарыг хойч санаа гэхээсээ илүү боломжийн нэг хэсэг гэж үзсэн:

• Статик шинжилгээний цэвэрлэгээ (#7990). DeepSource ажиллуулахад шинэ кодыг тэмдэглэсэн; би 42 файлын асуудлыг цэвэрлэсэн — бодит type-уудыг нэвтрүүлснээр any-ийн ойролцоогоор 390 хэрэглээг арилгаж, хэт төвөгтэй болсон хоёр функцийг (31 болон 28 онооны нарийн төвөгтэй байдлын үнэлгээтэй) зан төлөвийг нь өөрчлөхгүйгээр зорилтот туслах функцууд болгон задалсан.
• Чухал газарт нь тест. Unit болон integration тестүүд нь activity tracker, thread titler, файл задлалт, санах ойн гурван зан төлөв, workflow компайлер ба tool-ууд, мөн алдааны цэвэрлэгээ (sanitization)-г хамардаг — нэмээд workflow-гийн smoke-test скрипт.
• Аюулгүй байдлыг шингээсэн. Thread болон мессеж бүр дээр эзэмшлийн шалгалт (та зөвхөн өөрийнхөө зүйлд л хүрч болно), gateway дуудлагууд Bearer-ээр баталгаажсан, мөн бүтэцлэгдсэн tool алдаа — ингэснээр алдаа гаргасан tool нь stack trace задруулах юм уу хэрэглэгчийг гацаахын оронд агентад цэвэрхэн мессеж буцаадаг.

12. Ирээдүйн мөрөөдөл — энэ зам хаашаа хөгжиж болох вэ

12 хоног бол зөвхөн эхлэл. Одоо тавигдсан суурин дээр төсөөлж болох хөгжлийн замууд:

• Дуу хоолойгоор ярьдаг агент. Бичихийн оронд утсаа аваад "өнөөдрийн борлуулалт ямар байна?" гэж асуухад агент хариулдаг болох. Multimodal загварууд үүнийг аль хэдийн боломжтой болгож байна.
• Идэвхтэй (proactive) агент. Зөвхөн асуухад хариулдаг биш, өөрөө анзаарч санал болгодог: "Таны 5 гэрээний хугацаа дуусах гэж байна — сануулга илгээх үү?" Энэ нь learning модулийн суурин дээр ургаж болно.
• Агентын дэлгүүр (marketplace). Борлуулалт, дэмжлэг, санхүү гэх салбар бүрт зориулсан бэлэн агент, workflow-г хэн ч татаж аваад тэр дороо хэрэглэдэг болох. Workflow бол зүгээр л өгөгдөл учраас хуваалцахад хялбар.
• Олон агентын баг. Нэг агентын оронд тус бүр өөр мэргэжилтэй хэд хэдэн агент хоорондоо зөвлөлдөж, нэг том даалгаврыг хамтран биелүүлдэг болох — яг л жинхэнэ баг шиг.
• Харилцагч руу шууд. Одоогоор агент дотоод ажилтанд тусалж байна. Дараа нь дэмжлэгийн inbox дээр харилцагчтай шууд, аюулгүйгээр ярьдаг болж болно.
• Бүрэн локал, бүрэн нууцлал. embedding-ийг локал загвараар хийсэн шигээ цаашид бүх логикийг компанийн өөрийн сервер дээр ажиллуулж, өгөгдөл хаа ч гарахгүй болгох.
• Монгол хэлний агент. Дотоодын бизнесүүдэд зориулж монголоор төгс ойлгож, хариулдаг агент — энэ бол надад хувьд хамгийн их сэтгэл хөдөлгөдөг чиглэл.

Эдгээрийн алийг нь ч шинээр суурь архитектур бичихгүйгээр нэмж болно — учир нь үндсэн таван бүрдэл хэсэг, бодит цагийн үйлдлийн бүртгэл, permission-first RAG аль хэдийн бэлэн. Хамгийн хэцүү хэсэг нь хийгдсэн; цаашид зүгээр л мөрөөдлөө залгах л үлдлээ.

13. Үүнээс таныг юу авч үлдээсэй гэж би хүсэх вэ

• Аль хэдийн байгаа архитектураа түшиглэ. Хамгийн том үржүүлэгч нь erxes-ийн plugin + GraphQL-gateway дизайн байлаа. Бодит цагийн үйлдлийн бүртгэл нь "агентыг N plugin-тай нэгтгэх"-ийг "мөнхөд тэгтэй нэгтгэх" болгон хувиргасан. Хөшүүргийн цэгээ олж, түүн дээрээ бүтээ.
• Үндсэн бүрдэл хэсгүүдээс эхлэн зохион бүтээ. Аливаа боломжит бизнес процессыг таван үндсэн бүрдэл хэсэг болгон багасгасан нь workflow цөмийг жижиг байлгаж, нэг салбарын онцлог содон зүйлс цөмийг бохирдуулах боломжгүй болгосон.
• Эрхийг хадгалах үеийн биш, татаж авах үеийн асуудал гэж үз. Энэ бол demo, мөн бодит компанийн өгөгдлийг хийж болох зүйл хоёрын ялгаа юм.
• Сүүлчийн миль бол жинхэнэ миль. Docker, CI, CDN, мөн нэрэн дэх нэг зураас нь дээрх ухаалаг шийдлүүдийн алинаас нь нэг ч бодит хэрэглэгчид харагдах эсэхийг шийдсэн.