AgentOps ແມ່ນກອບວຽກຂອງ "ການອອກແບບອົງກອນ + ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure" ເພື່ອເຮັດໃຫ້ AI Agent ສາມາດເຮັດວຽກໄດ້ຢ່າງໝັ້ນຄົງ.

ໃນຂະນະທີ່ DevOps ແມ່ນ "ການດຳເນີນງານເພື່ອປ່ອຍໂຄ້ດຢ່າງປອດໄພ" ແລະ MLOps ແມ່ນ "ກົນໄກການດຳເນີນງານແບບຈຳລອງຢ່າງໝັ້ນຄົງ", AgentOps ຈະຈັດການກັບ "ອົງກອນ ແລະ ກົນໄກທີ່ດຳເນີນງານຫຼາຍ Agent ທີ່ເຮັດວຽກແບບອັດຕະໂນມັດຢ່າງຕໍ່ເນື່ອງ ໂດຍອີງໃສ່ 3 ແກນຫຼັກ ຄື: ຄຸນນະພາບ, ຕົ້ນທຶນ ແລະ ການປະຕິບັດຕາມກົດລະບຽບ". ເບິ່ງຄືວ່າເປັນພຽງການຕໍ່ຍອດຈາກ LLMOps ທີ່ເກີດຂຶ້ນພ້ອມກັບການມາເຖິງຂອງ LLM, ແຕ່ທັນທີທີ່ມີເງື່ອນໄຂເພີ່ມເຂົ້າມາວ່າ Agent "ສາມາດເອີ້ນໃຊ້ເຄື່ອງມືໄດ້ດ້ວຍຕົນເອງ", ເປົ້າໝາຍຂອງການອອກແບບການດຳເນີນງານກໍຈະປ່ຽນຈາກຂະບວນການ ຫຼື Pipeline ການອະນຸມານ ໄປສູ່ "ຂະບວນການເຮັດວຽກຕົວຈິງ".

ຄູ່ມືສະບັບນີ້ມີຈຸດປະສົງເພື່ອໃຫ້ຜູ້ຮັບຜິດຊອບດ້ານ DX / ລະບົບຂໍ້ມູນຂ່າວສານຂອງບໍລິສັດຂະໜາດກາງ ໄດ້ຈັດລະບຽບອົງປະກອບຂອງ AgentOps, ການເຊື່ອມໂຍງກັບການດຳເນີນງານທີ່ມີຢູ່ ແລະ ຂັ້ນຕອນການນຳໃຊ້. ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດສ້າງຕາຕະລາງບົດບາດວ່າ "ໃຜ, ເຮັດຫຍັງ, ດ້ວຍ SLI/SLO ແນວໃດ" ພາຍໃນບໍລິສັດຂອງທ່ານ ແລະ ສາມາດຕັດສິນໃຈລຳດັບຄວາມສຳຄັນເພື່ອຍົກລະດັບ Agent ໃນຂັ້ນຕອນທົດລອງໄປສູ່ການນຳໃຊ້ຈິງໄດ້.

AgentOps ແມ່ນແນວຄວາມຄິດ ແລະ ພື້ນຖານໃນການຈັດການ AI Agent ຫຼາຍຕົວໃຫ້ເປັນ "Workload ການດຳເນີນງານທີ່ເປັນທາງການຂອງອົງກອນ". ມັນບໍ່ແມ່ນພຽງແຕ່ການນຳໃຊ້ເຄື່ອງມືເທົ່ານັ້ນ, ແຕ່ເປັນການເນັ້ນໃສ່ການປັບປຸງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງອົງກອນ ໂດຍການປະສົມປະສານການອອກແບບດ້ານຄວາມເປັນເຈົ້າຂອງ (Ownership), ຕົວຊີ້ວັດການສັງເກດການ (Observability), ແລະ ການແຊກແຊງຂອງມະນຸດ (Human-in-the-loop).

ໃນພາກນີ້, ພວກເຮົາຈະສະຫຼຸບຄວາມແຕກຕ່າງລະຫວ່າງ Ops ແບບເດີມ (DevOps / MLOps / LLMOps) ແລະ ເຫດຜົນທີ່ການດຳເນີນງານຂອງ Agent ເຮັດໃຫ້ເກີດສິ່ງທ້າທາຍໃໝ່ໆ. ການເຮັດໃຫ້ມີຄວາມຊັດເຈນວ່າ "ຄວນເພີ່ມຫຍັງເຂົ້າໃນການດຳເນີນງານທີ່ມີຢູ່ແລ້ວ" ຈະເປັນຈຸດເລີ່ມຕົ້ນໃນການວາງແຜນການນຳໃຊ້.

ຈັດລຽງຂອບເຂດຄວາມສົນໃຈຂອງ Ops ແບບດັ້ງເດີມ ແລະ AgentOps ໄວ້ຄຽງຄູ່ກັນດັ່ງນີ້:

ສິ່ງທີ່ໃໝ່ສຳລັບ AgentOps ຄືການເພີ່ມເງື່ອນໄຂທີ່ວ່າ "LLM ສາມາດເອີ້ນໃຊ້ເຄື່ອງມືໄດ້ຢ່າງອັດຕະໂນມັດ". ສຳລັບ LLMOps ທີ່ຜ່ານມາ "ຄຸນນະພາບ ແລະ ຄວາມໄວໃນການສ້າງຂໍ້ຄວາມ" ແມ່ນຄວາມສົນໃຈຫຼັກ, ແຕ່ສຳລັບເອເຈນແລ້ວ ມັນສາມາດຂຽນຂໍ້ມູນລົງໃນຖານຂໍ້ມູນຂອງບໍລິສັດ, ໂອນເງິນຜ່ານ API ພາຍນອກ ຫຼື ລຶບໄຟລ໌ຕ່າງໆໄດ້. ເນື່ອງຈາກການກະທຳທີ່ມີຜົນກະທົບຂ້າງຄຽງເກີດຂຶ້ນເປັນປະຈຳ, ການດຳເນີນງານຫຼັງຈາກການ Deploy ຈຶ່ງບໍ່ສາມາດພຽງແຕ່ຕິດຕາມກວດກາຄ່າ Latency ໄດ້ອີກຕໍ່ໄປ.

ສິ່ງທີ່ສັງເກດເຫັນວ່າເປັນຕົວຊີ້ບອກເຖິງການປ່ຽນຜ່ານມີ 3 ຢ່າງຄື: (1) ເມື່ອເອເຈນເລີ່ມສົ່ງຄຳສັ່ງທີ່ມີຜົນກະທົບຂ້າງຄຽງໄປຍັງ API ພາຍນອກ, (2) ເມື່ອມີໂຄງສ້າງທີ່ເອເຈນຫຼາຍຕົວເຂົ້າເຖິງຂໍ້ມູນດຽວກັນພ້ອມກັນ, ແລະ (3) ເມື່ອມີ "Prompt ທີ່ມາຈາກແຫຼ່ງຂໍ້ມູນ" ເຂົ້າມາແທນທີ່ການປ້ອນຂໍ້ມູນຈາກຜູ້ໃຊ້. ເມື່ອເງື່ອນໄຂເຫຼົ່ານີ້ຄົບຖ້ວນ, ການດຳເນີນງານໂດຍໃຊ້ພຽງແຕ່ LLMOps ຈະເລີ່ມປະສົບກັບຄວາມລົ້ມເຫຼວ.

ຄຸນລັກສະນະທີ່ "ຕົວແທນ (Agent) ຕັດສິນໃຈດ້ວຍຕົນເອງ" ນັ້ນ ນຳມາເຊິ່ງສິ່ງທ້າທາຍໃໝ່ 3 ປະການໃນດ້ານການປະຕິບັດງານ:

• ຄວາມບໍ່ແນ່ນອນທີ່ກາຍເປັນເລື່ອງປົກກະຕິ (Non-determinism): ເຖິງແມ່ນວ່າຈະມີການປ້ອນຂໍ້ມູນເຂົ້າແບບດຽວກັນ ແຕ່ລຳດັບການເອີ້ນໃຊ້ເຄື່ອງມື ຫຼື ການເລືອກໃຊ້ເຄື່ອງມືອາດປ່ຽນແປງໄປ ເຮັດໃຫ້ຄວາມສາມາດໃນການເຮັດຊ້ຳ (Reproducibility) ຫຼຸດລົງ. ການແກ້ໄຂບັກ (Bug) ຈະເຮັດໄດ້ຍາກຂຶ້ນ ແລະ ຈຳເປັນຕ້ອງໃຊ້ວິທີການ "ສັ່ງປະມວນຜົນຊ້ຳ N ຄັ້ງດ້ວຍຂໍ້ມູນເຂົ້າຊຸດດຽວກັນ" ເພື່ອແຍກແຍະສາເຫດ.
• ຄວາມຍາກໃນການຄາດຄະເນການປ່ຽນແປງຂອງຕົ້ນທຶນ: ການບໍລິໂພກ Token ຕໍ່ໜຶ່ງໜ້າວຽກຈະມີການປ່ຽນແປງຢ່າງຫຼວງຫຼາຍ ຂຶ້ນຢູ່ກັບວ່າ "ຕົວແທນໃຊ້ຂັ້ນຕອນການຄິດຫຼາຍປານໃດ". ເຖິງແມ່ນວ່າຈະເປັນຟັງຊັນດຽວກັນ ແຕ່ຕົ້ນທຶນອາດຈະເພີ່ມຂຶ້ນຫຼາຍເທົ່າຕົວຂຶ້ນຢູ່ກັບຂໍ້ມູນທີ່ຜູ້ໃຊ້ປ້ອນເຂົ້າ ດັ່ງນັ້ນການບໍລິຫານງົບປະມານໂດຍເບິ່ງພຽງແຕ່ "ຄ່າສະເລ່ຍ" ຈຶ່ງມີໂອກາດລົ້ມເຫຼວໄດ້ງ່າຍ.
• ຄວາມບໍ່ຊັດເຈນຂອງຂອບເຂດຄວາມຮັບຜິດຊອບ: ໃນກໍລະນີທີ່ການຕັດສິນໃຈຂອງຕົວແທນຜິດພາດ ຖ້າບໍ່ມີການກຳນົດຢ່າງຊັດເຈນວ່າໃຜຈະເປັນຜູ້ຮັບຜິດຊອບ (ທີມຜູ້ພັດທະນາ / ພະແນກທີ່ນຳໃຊ້ / ພະແນກບໍລິຫານຈັດການ) ຈະເຮັດໃຫ້ການແກ້ໄຂບັນຫາຢຸດສະງັກ. ເຖິງແມ່ນແຕ່ຂັ້ນຕອນການລາຍງານອຸບັດຕິເຫດ ກໍຈະຕ້ອງເລີ່ມຕົ້ນດ້ວຍການຖົກຖຽງກັນວ່າ "ທີມໃດຈະເປັນຜູ້ອອກໃບແຈ້ງເຫດ".

ບັນຫາເຫຼົ່ານີ້ບໍ່ສາມາດແກ້ໄຂໄດ້ດ້ວຍເຄື່ອງມືພຽງຢ່າງດຽວ ແຕ່ຈຳເປັນຕ້ອງ ແກ້ໄຂດ້ວຍກົດລະບຽບ ແລະ ການແບ່ງບົດບາດພາຍໃນອົງກອນ. ນີ້ຄືເຫດຜົນທີ່ AgentOps ຕ້ອງກວມເອົາເຖິງ "ການອອກແບບອົງກອນ". ຖ້າຫາກບັນຫາໃດໜຶ່ງໃນ 3 ປະການນີ້ປາກົດຂຶ້ນໃນໜ້າວຽກຕົວຈິງ ການຈັດຕັ້ງເສັ້ນທາງການແຈ້ງບັນຫາ (Escalation path) ແລະ ການກຳນົດເຈົ້າຂອງຄວາມຮັບຜິດຊອບ (Owner) ໃຫ້ຊັດເຈນກ່ອນການເລືອກໃຊ້ເຄື່ອງມື ຈະສົ່ງຜົນໃຫ້ການແກ້ໄຂບັນຫາສຳເລັດໄດ້ໄວຂຶ້ນ.

ໃນຂະນະທີ່ຍັງດຳເນີນການດ້ວຍ Agent 1 ຕົວ ຕໍ່ 1 ຈຸດປະສົງ, ການດຳເນີນງານກໍຍັງຖືວ່າເປັນເລື່ອງນ້ອຍໆ, ແຕ່ທັນທີທີ່ຈຳນວນເພີ່ມຂຶ້ນ ພາລະໃນການດຳເນີນງານກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ສຽງສະທ້ອນຈາກໜ້າວຽກທີ່ວ່າ "Pilot ປະສົບຜົນສຳເລັດ ແຕ່ໄປຕິດຂັດໃນຂັ້ນຕອນການຂະຫຍາຍ" ແມ່ນສິ່ງທີ່ຊຸກຍູ້ໃຫ້ຄວາມສົນໃຈທີ່ມີຕໍ່ AgentOps ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ໃນບົດນີ້, ພວກເຮົາຈະມາແຍກແຍະເນື້ອໃນຂອງປະກົດການ "ຕິດຂັດໃນຂັ້ນຕອນການຂະຫຍາຍ" ແລະ ຈັດລະບຽບວ່າເປັນຫຍັງມັນຈຶ່ງບໍ່ສາມາດຮອງຮັບໄດ້ດ້ວຍການອອກແບບການດຳເນີນງານແບບດັ້ງເດີມ.

ວົງຈອນ "ການຄິດ → ການຮຽກໃຊ້ເຄື່ອງມື → ຜົນລັດ" ທີ່ສາມາດຕິດຕາມໄດ້ໃນຕົວແທນ (Agent) ດຽວ, ເມື່ອມີຕົວແທນຫຼາຍຕົວເຮັດວຽກຮ່ວມກັນ, ຈະເກີດບັນຫາການດຳເນີນງານທີ່ເປັນເອກະລັກຂອງ Multi-agent ຂຶ້ນມາ ເຊັ່ນ:

• ຕົວແທນໃດ, ຕາມລຳດັບໃດ, ໄດ້ຮຽກໃຊ້ເຄື່ອງມືໃດ
• ເມື່ອເກີດຄວາມຜິດພາດໃນລະຫວ່າງທາງ, ຈະເລີ່ມປະຕິບັດໃໝ່ຈາກຈຸດໃດຈຶ່ງຈະປອດໄພ
• ຄວາມຂັດແຍ່ງທີ່ເກີດຂຶ້ນໃນການປະຕິບັດງານພ້ອມກັນ (ເຊັ່ນ: ຕົວແທນ 2 ຕົວອັບເດດບັນທຶກດຽວກັນ)
• ບໍລິບົດ (Context) ຕົກຫຼົ່ນໃນລະຫວ່າງການສົ່ງຕໍ່ລະຫວ່າງຕົວແທນຫຼືບໍ່

ການທີ່ເຟຣມເວີກຢ່າງ Mastra ຫຼື LangGraph ກ້າວໄປໃນທິດທາງຂອງ "ການອະທິບາຍສະຖານະຂອງຕົວແທນເປັນ Workflow" ກໍເປັນການເຄື່ອນໄຫວເພື່ອເອົາຄວາມສາມາດໃນການຕິດຕາມກວດສອບກັບຄືນມາ. ເພື່ອປ້ອງກັນສະຖານະ "ບໍ່ຮູ້ວ່າເກີດຫຍັງຂຶ້ນ", ຈຳເປັນຕ້ອງບັນທຶກ Input/Output ແລະ ເຫດຜົນໃນການຕັດສິນໃຈຂອງຕົວແທນແຕ່ລະຕົວໄວ້ໃນ Log ທີ່ມີໂຄງສ້າງ ແລະ ຮັກສາສະຖານະທີ່ສາມາດ Replay ໄດ້ໃນລະດັບ Workflow.

ການປະຕິບັດງານແບບອັດຕະໂນມັດໂດຍອີງໃສ່ MCP ທີ່ໄດ້ກ່າວເຖິງໃນ ຄູ່ມືການປະຕິບັດງານ AI Agent ພາສາລາວ ກໍຈະປະເຊີນກັບບັນຫາການດຳເນີນງານດຽວກັນໃນຂັ້ນຕອນການນຳໃຊ້ຈິງ. ເຖິງແມ່ນວ່າຮູບແບບການປະຕິບັດງານຈະຄົບຖ້ວນ, ແຕ່ຖ້າ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໃນການດຳເນີນງານຕາມບໍ່ທັນ ກໍຈະຕົກຢູ່ໃນສະຖານະ "ເຮັດວຽກໄດ້ ແຕ່ຢຸດບໍ່ໄດ້".

ຈັດລະບຽບ 3 ຟັງຊັນທີ່ຈຳເປັນໃນການດຳເນີນງານຂອງ Agent.

ທັງ 3 ຟັງຊັນນີ້ສາມາດນຳໄປປະຕິບັດແບບແຍກສ່ວນກັນໄດ້ ແຕ່ການອອກແບບໃຫ້ ອ້າງອີງເຊິ່ງກັນແລະກັນ ຈະຊ່ວຍຫຼຸດພາລະໃນການດຳເນີນງານໄດ້. ຕົວຢ່າງເຊັ່ນ: ການຕັດສິນໃຈວ່າຕ້ອງການ HITL ຫຼືບໍ່ໂດຍອີງຈາກບັນທຶກການກວດສອບ, ການບັງຄັບໃຊ້ HITL ເມື່ອຕົ້ນທຶນເກີນກຳນົດ, ຫຼືການລວມ ຫຼື Merge ບັນທຶກການອະນຸມັດ HITL ເຂົ້າກັບບັນທຶກການກວດສອບ ເປັນຕົ້ນ.

ໂດຍສະເພາະການຈັດການຕົ້ນທຶນ, ມັນບໍ່ແມ່ນເລື່ອງແປກທີ່ ຕົວເລກຂະໜາດນ້ອຍທີ່ເຫັນໃນຂັ້ນຕອນ Pilot ຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ເມື່ອເປີດຕົວ ຫຼື Launch ສູ່ການນຳໃຊ້ຈິງ. ສາເຫດສາມາດສະຫຼຸບໄດ້ເປັນ 3 ປະການຄື: (a) ຈຳນວນຜູ້ໃຊ້ເພີ່ມຂຶ້ນ, (b) ຈຳນວນຂັ້ນຕອນການຄາດຄະເນ (Inference steps) ຕໍ່ໜຶ່ງວຽກເພີ່ມຂຶ້ນ, ແລະ (c) Prompt ມີຂະໜາດໃຫຍ່ຂຶ້ນຍ້ອນການໃຊ້ Long-context RAG. ກ່ອນທີ່ຈະນຳເຄື່ອງມືມາໃຊ້, ຈຳເປັນຕ້ອງກຳນົດຫົວໜ່ວຍການວັດແທກຕົ້ນທຶນ ແລະ ເກນການແຈ້ງເຕືອນ (Threshold) ໄວ້ລ່ວງໜ້າ. ການຕົກລົງກ່ຽວກັບນະໂຍບາຍການດຳເນີນງານໄວ້ກ່ອນວ່າ ເມື່ອເກີນເກນທີ່ກຳນົດໄວ້ ຈະໃຫ້ຢຸດການເຮັດວຽກຂອງ Agent ໂດຍອັດຕະໂນມັດ ຫຼື ປ່ຽນໄປໃຊ້ການອະນຸມັດແບບ HITL ຈະຊ່ວຍໃຫ້ການຕັດສິນໃຈໃນໜ້າວຽກຕົວຈິງມີຄວາມວ່ອງໄວຂຶ້ນ.

AgentOps ປະກອບດ້ວຍ 5 ອົງປະກອບຄື: (1) Agent Registry, (2) ການສັງເກດການ (SLI/SLO/ຕົ້ນທຶນ), (3) HITL ແລະ ການຍົກລະດັບ, (4) ວົງຈອນການປະເມີນຜົນ, ແລະ (5) ນະໂຍບາຍການກຳກັບດູແລ. ໃນພາກນີ້, ພວກເຮົາຈະເຈາະເລິກ 3 ອົງປະກອບທຳອິດທີ່ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ.

ວົງຈອນການປະເມີນຜົນໝາຍເຖິງ "ກົນໄກໃນການວັດແທກຄຸນນະພາບຂອງ Agent ຢ່າງຕໍ່ເນື່ອງ", ສ່ວນນະໂຍບາຍການກຳກັບດູແລໝາຍເຖິງກົດລະບຽບທີ່ວ່າ "ຂໍ້ມູນໃດທີ່ Agent ຕົວໃດສາມາດນຳໄປໃຊ້ໄດ້". ການເລີ່ມຕົ້ນສິ່ງເຫຼົ່ານີ້ຫຼັງຈາກທີ່ 3 ອົງປະກອບທຳອິດມີຄວາມພ້ອມແລ້ວຈະມີປະສິດທິພາບຫຼາຍກວ່າ, ຖ້າຫາກພະຍາຍາມເຮັດໃຫ້ຄົບທັງ 5 ອົງປະກອບຕັ້ງແຕ່ຕົ້ນ ອາດຈະເຮັດໃຫ້ໂຄງການທົດລອງສິ້ນສຸດລົງໂດຍທີ່ພື້ນຖານຍັງບໍ່ທັນໝັ້ນຄົງ.

ເມື່ອຈຳນວນ Agent ເກີນ 5 ຕົວ, ຄຳຖາມທີ່ວ່າ "Agent ຕົວໃດຢູ່ໃສ ແລະ ໃຜເປັນຜູ້ຮັບຜິດຊອບ" ຈະເລີ່ມບໍ່ຊັດເຈນ. Registry ຄວນມີຂໍ້ມູນຂັ້ນຕໍ່າດັ່ງນີ້:

• Agent ID ແລະ ຈຸດປະສົງ (ບໍລິການລູກຄ້າ / ຈັດການບັນຊີ / ສະໜັບສະໜູນການຂາຍ …)
• ເຈົ້າຂອງ (ເຈົ້າຂອງພາກສ່ວນທຸລະກິດ) ແລະ ຜູ້ຮັບຜິດຊອບດ້ານເຕັກນິກ (ນັກພັດທະນາ)
• ລາຍການ MCP / ເຄື່ອງມືທີ່ນຳໃຊ້
• ໝວດໝູ່ຂໍ້ມູນທີ່ສາມາດເຂົ້າເຖິງໄດ້ ແລະ ການຈັດປະເພດ PII
• ເວີຊັນ ແລະ ປະຫວັດການປ່ຽນແປງ
• ວັນທີກຳນົດຍົກເລີກ (ຖ້າມີ)

ສາມາດໃຊ້ Wiki ພາຍໃນບໍລິສັດ ຫຼື Notion ກໍໄດ້, ແຕ່ຖ້າກົດລະບຽບການດຳເນີນງານທີ່ວ່າ "ຫາກມີການປ່ຽນແປງ ຕ້ອງອັບເດດບ່ອນນີ້ສະເໝີ" ບໍ່ສາມາດປະຕິບັດໄດ້, ກໍຈະເກີດສະຖານະການທີ່ພົບເຫັນ Agent ທີ່ບໍ່ມີຕົວຕົນແທ້ຈິງໃນເວລາທີ່ກວດສອບ. ເນື່ອງຈາກພາລະໃນການດຳເນີນງານເພື່ອ "ຮັກສາສະຖານະໃຫ້ຖືກຕ້ອງ" ສຳລັບ Registry ແມ່ນບໍ່ສາມາດລະເລີຍໄດ້, ການສ້າງກົນໄກທີ່ອັບເດດໂດຍອັດຕະໂນມັດຈາກຂະບວນການ ຫຼື Pipeline ການ Deploy (ເມື່ອອັບເດດຜ່ານ CI ແລ້ວໃຫ້ສະທ້ອນຜົນຜ່ານ PR) ຕັ້ງແຕ່ຕົ້ນ ຈະຊ່ວຍປ້ອງກັນບໍ່ໃຫ້ມັນກາຍເປັນພຽງຮູບແບບທີ່ບໍ່ມີປະສິດທິຜົນໄດ້ງ່າຍຂຶ້ນ.

SLI (Service Level Indicator) ຂອງ AgentOps ຈຳເປັນຕ້ອງມີມຸມມອງທີ່ແຕກຕ່າງຈາກ Latency ແລະ ອັດຕາຄວາມຜິດພາດຂອງ Web Service. ຕໍ່ໄປນີ້ແມ່ນ 4 ຕົວຊີ້ວັດຫຼັກທີ່ຄວນພິຈາລະນາເປັນຢ່າງໜ້ອຍ:

• ອັດຕາຄວາມສຳເລັດຂອງວຽກ (Task Success Rate): ອັດຕາສ່ວນທີ່ວຽກງານຖືກເຮັດສຳເລັດໂດຍບໍ່ມີການແຊກແຊງຈາກ HITL.
• ຈຳນວນການເອີ້ນໃຊ້ເຄື່ອງມືສະເລ່ຍ (Average Tool Calls): ຈຳນວນຄັ້ງທີ່ມີການເອີ້ນໃຊ້ເຄື່ອງມືຕໍ່ 1 ວຽກ (ການເພີ່ມຂຶ້ນແມ່ນສັນຍານຂອງການຫຼົງທາງໃນການຄິດ).
• ຕົ້ນທຶນ Token ຕໍ່ວຽກ (Token Cost / Task): ຜົນລວມຂອງ Input + Output + ການໃຊ້ງານ Cache.
• ອັດຕາການຍົກລະດັບ (Escalation Rate): ອັດຕາສ່ວນທີ່ຖືກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ HITL.

SLO (ຄ່າເປົ້າໝາຍ) ບໍ່ຄວນຕັ້ງໄວ້ສູງເກີນໄປຕັ້ງແຕ່ຕົ້ນ, ຄວນກຳນົດຫຼັງຈາກໄດ້ວັດແທກຜົນຕົວຈິງໃນໄລຍະ Pilot. ຕົວຢ່າງ: ຖ້າຕັ້ງເປົ້າໝາຍ "ອັດຕາຄວາມສຳເລັດຂອງວຽກ 90% ຂຶ້ນໄປ" ຕັ້ງແຕ່ເລີ່ມຕົ້ນ, ຝ່າຍປະຕິບັດງານມັກຈະມີທ່າອ່ຽງໃນການປັບແຕ່ງຜົນງານໃຫ້ເບິ່ງດີ ເຮັດໃຫ້ຈຸດທີ່ຄວນປັບປຸງແທ້ໆຖືກມອງຂ້າມ. ຖ້າໃນໄລຍະ Pilot ມີອັດຕາຄວາມສຳເລັດປະມານ 70%, ການເລີ່ມຕົ້ນ SLO ທີ່ 75% ແລ້ວຄ່ອຍໆປັບຂຶ້ນເທື່ອລະຂັ້ນ ຈະຊ່ວຍໃຫ້ອົງກອນສາມາດສ້າງວົງຈອນການປັບປຸງທີ່ເປັນຈິງໄດ້ຫຼາຍກວ່າ.

ສິ່ງທີ່ຄວນຫຼີກເວັ້ນໃນຖານະ Anti-pattern ຄືການອອກແບບໂດຍໃຊ້ "ອັດຕາຄວາມຜິດພາດເປັນ SLI ພຽງຢ່າງດຽວ". ເຖິງແມ່ນວ່າ Agent ຈະບໍ່ເຮັດວຽກຜິດພາດ ແຕ່ກໍມີຮູບແບບຄວາມລົ້ມເຫຼວຫຼາຍຢ່າງທີ່ອັດຕາຄວາມຜິດພາດບໍ່ສາມາດກວດຈັບໄດ້ ເຊັ່ນ: "ການໃຊ້ຕົ້ນທຶນໄປກັບວົງຈອນການຄິດທີ່ໄຮ້ປະໂຫຍດ" ຫຼື "ການເຮັດວຽກຖືກຕ້ອງແຕ່ຜົນລັອກບໍ່ຕົງກັບຄວາມຄາດຫວັງຂອງຜູ້ໃຊ້". ການນຳເອົາອັດຕາຄວາມສຳເລັດຂອງວຽກ ແລະ ຈຳນວນການເອີ້ນໃຊ້ເຄື່ອງມືສະເລ່ຍມາລວມກັນ ຈະຊ່ວຍໃຫ້ສາມາດກວດຈັບສັນຍານເຕືອນໄພເຖິງຄຸນນະພາບທີ່ຫຼຸດລົງໄດ້ໄວຂຶ້ນ.

ການອອກແບບ HITL ແມ່ນວຽກງານໃນການຊອກຫາຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ລະຫວ່າງ "ການໃຫ້ມະນຸດມີສ່ວນຮ່ວມໃນທຸກຄຳຮ້ອງຂໍ" ແລະ "ການປ່ອຍໃຫ້ເປັນໜ້າທີ່ຂອງ Agent". ໂດຍໃຫ້ແບ່ງການໃຊ້ງານອອກເປັນ 3 ຮູບແບບດັ່ງນີ້:

• HITL ທີ່ຈຳເປັນຕ້ອງມີຕະຫຼອດເວລາ: ການໂອນເງິນ, ການເຮັດສັນຍາ, ການຕັດສິນທາງກົດໝາຍ, ການເປີດຕົວ ຫຼື Launch ຕໍ່ສາທາລະນະ (ຂົງເຂດທີ່ຜົນກະທົບຈາກການຕັດສິນຜິດພາດບໍ່ສາມາດແກ້ໄຂໄດ້).
• HITL ໂດຍອີງໃສ່ຄ່າ Threshold: ຄະແນນຄວາມເຊື່ອໝັ້ນ < N, ຈຳນວນເງິນ > N ເຢນ, ຈຳນວນໄຟລ໌ທີ່ຖືກລຶບ > N ໄຟລ໌.
• HITL ໂດຍການສຸ່ມ (Sampling): ອະນຸມັດແບບອັດຕະໂນມັດ ແຕ່ມີການສຸ່ມກວດສອບໂດຍມະນຸດໃນອັດຕາສ່ວນທີ່ກຳນົດ (ເພື່ອຕິດຕາມກວດກາຄຸນນະພາບຢ່າງຕໍ່ເນື່ອງ).

ການນຳໃຊ້ທັງ 3 ຮູບແບບຮ່ວມກັນໃນ Agent ດຽວກັນຖືວ່າເປັນເລື່ອງທີ່ເປັນໄປໄດ້ໃນທາງປະຕິບັດ. ຕົວຢ່າງ: ຖ້າເປັນ "Agent ຈັດການຄ່າໃຊ້ຈ່າຍ", ການອອກແບບຈະເປັນ: ການດຳເນີນການທີ່ເກີນ 100,000 ເຢນ ຕ້ອງມີ HITL ຕະຫຼອດເວລາ, 10,000 ເຢນລົງມາແມ່ນອັດຕະໂນມັດ, ແລະ ໃນສ່ວນທີ່ຢູ່ລະຫວ່າງນັ້ນໃຫ້ສຸ່ມກວດສອບໂດຍມະນຸດ 5%.

ການກຳນົດປາຍທາງໃນການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (Escalation) ຄວນມີ 3 ສາຍຄື: "ທີມງານຜູ້ກວດສອບສະເພາະທາງ", "ເຈົ້າຂອງພາກສ່ວນທຸລະກິດ", ແລະ "ທີມງານຮັກສາຄວາມປອດໄພ" ເພື່ອໃຫ້ສາມາດສົ່ງຕໍ່ວຽກໄປຍັງບຸກຄົນທີ່ເໝາະສົມໃນແຕ່ລະຂົງເຂດໄດ້. ນອກຈາກນີ້, ການກຳນົດ SLA ດ້ານເວລາຕອບສະໜອງຂອງຜູ້ກວດສອບ ຈະຊ່ວຍບໍ່ໃຫ້ການລໍຖ້າ HITL ກາຍເປັນຄໍຂວດຂອງຂະບວນການ ຫຼື Pipeline ທັງໝົດ ແລະ ຍັງຊ່ວຍໃຫ້ການອອກແບບ Timeout ຂອງຝ່າຍ Agent ເຮັດໄດ້ງ່າຍຂຶ້ນ.

ຄວາມເຂົ້າໃຈຜິດທີ່ພົບເຫັນຫຼາຍທີ່ສຸດຄືການເບິ່ງວ່າ AgentOps "ສາມາດນຳໄປປະຕິບັດໄດ້ພຽງແຕ່ຊື້ເຄື່ອງມືສະເພາະມາໃຊ້". ໃນຄວາມເປັນຈິງແລ້ວ, ບົດບາດຂອງອົງກອນ ແລະ ການຕັດສິນໃຈແມ່ນມີຄວາມສຳຄັນຫຼາຍກວ່າ, ສ່ວນເຄື່ອງມືນັ້ນເປັນພຽງອົງປະກອບໜຶ່ງທີ່ຊ່ວຍສະໜັບສະໜູນເທົ່ານັ້ນ.

ໃນທີ່ນີ້, ພວກເຮົາຈະຍົກເອົາ 2 ຄວາມເຂົ້າໃຈຜິດທີ່ພົບເຫັນຫຼາຍທີ່ສຸດມາອະທິບາຍ ແລະ ວິເຄາະໃຫ້ເຫັນຢ່າງລະອຽດວ່າ ເປັນຫຍັງສິ່ງເຫຼົ່ານັ້ນຈຶ່ງເຮັດໃຫ້ການເຄື່ອນໄຫວຂອງອົງກອນຢຸດສະງັກ.

ການທີ່ SaaS ຂອງ AgentOps ປະກົດຕົວຂຶ້ນຢ່າງຕໍ່ເນື່ອງ ສົ່ງຜົນໃຫ້ເກີດຄວາມເຂົ້າໃຈທີ່ວ່າ "ພຽງແຕ່ຕິດຕັ້ງເຄື່ອງມືສັງເກດການ (Observability tools) ກໍຈະສາມາດສ້າງ AgentOps ຂຶ້ນມາໄດ້". ເຄື່ອງມືສັງເກດການນັ້ນມີປະໂຫຍດແທ້ ແຕ່ພຽງເທົ່ານັ້ນບໍ່ສາມາດແກ້ໄຂບັນຫາໃນ ສ່ວນທີ່ຕ້ອງການການຕັດສິນໃຈຂອງມະນຸດ ເຊັ່ນ:

• ຈະຕັດສິນວ່າ SLI ໃດຢູ່ໃນ "ລະດັບທີ່ຍອມຮັບບໍ່ໄດ້"
• ໃຜຈະເປັນຜູ້ຈັດການວຽກທີ່ຖືກສົ່ງຕໍ່ໄປຍັງ HITL (Human-in-the-loop)
• ເມື່ອມີການແຈ້ງເຕືອນເລື່ອງຄ່າໃຊ້ຈ່າຍເກີນງົບ ໃຜຈະເປັນຜູ້ເພີ່ມຂີດຈຳກັດງົບປະມານ
• ເມື່ອເກີດເຫດການບໍ່ຄາດຝັນ ໃຜມີສິດອຳນາດໃນການຢຸດການເຮັດວຽກຂອງ Agent

ການທີ່ເຫັນແຕ່ການແຈ້ງເຕືອນສີແດງເຕັມໜ້າຈໍ Dashboard ແຕ່ບໍ່ສາມາດແກ້ໄຂບັນຫາໄດ້ນັ້ນ ເປັນຄວາມລົ້ມເຫຼວແບບປົກກະຕິຂອງການເນັ້ນໃຊ້ເຄື່ອງມືສັງເກດການນຳໜ້າ. ສິ່ງທີ່ຄວນເຮັດກ່ອນແມ່ນການຈັດຕັ້ງເສັ້ນທາງການແຈ້ງເຕືອນ (Escalation path) ແລະ ຕາຕະລາງສິດອຳນາດໃນການຕັດສິນໃຈໄປພ້ອມໆກັບການນຳໃຊ້ເຄື່ອງມື. ຢ່າງໜ້ອຍທີ່ສຸດ ການສະຫຼຸບວ່າ "ໃຜ, ເບິ່ງຫຍັງ, ຢູ່ທີ່ຂີດຈຳກັດ (Threshold) ໃດ, ແລະ ຈະຕິດຕໍ່ໃຜ" ໄວ້ໃນໜ້າດຽວ ແລ້ວໃຫ້ພາກສ່ວນທີ່ກ່ຽວຂ້ອງຕົກລົງເຫັນດີນຳກັນກ່ອນທີ່ຈະສັ່ງຊື້ເຄື່ອງມືສັງເກດການນັ້ນ ຈະເປັນເສັ້ນທາງທີ່ສັ້ນທີ່ສຸດໃນການບັນລຸຜົນສຳເລັດ.

ບາງຄັ້ງອາດມີການປະກາດທັງພາຍໃນ ແລະ ພາຍນອກບໍລິສັດວ່າ "ໄດ້ເປີດຕົວ ຫຼື Launch ຕົວ AI Agent ຈຳນວນ 50 ຕົວແລ້ວ", ແຕ່ ຈຳນວນດັ່ງກ່າວບໍ່ໄດ້ເຮັດໜ້າທີ່ເປັນຕົວຊີ້ວັດມູນຄ່າທີ່ດີພໍ. ໃນບາງກໍລະນີ 10 ຕົວອາດພຽງພໍແລ້ວ ຫຼື ໃນບາງກໍລະນີທີ່ໃຊ້ພຽງແຕ່ 3 ຕົວເທົ່ານັ້ນກໍບໍ່ແມ່ນເລື່ອງແປກ. ປະກົດການທີ່ພົບເຫັນເລື້ອຍໆຄື ໃນຈຳນວນ 50 ຕົວທີ່ເປີດຕົວໄປນັ້ນ ມີພຽງບໍ່ຮອດ 10 ຕົວທີ່ມີການເຄື່ອນໄຫວຕໍ່ເດືອນ.

ສິ່ງທີ່ສາມາດໃຊ້ເປັນຕົວຊີ້ວັດມູນຄ່າທີ່ມີປະສິດທິພາບໄດ້ແກ່:

• ການຫຼຸດຜ່ອນເວລາເຮັດວຽກຕົວຈິງ (ແບ່ງຕາມພະແນກ)
• ທ່າອ່ຽງຂອງຈຳນວນ HITL (ຖ້າຫຼຸດລົງໝາຍເຖິງຄວາມຊຳນານ, ຖ້າເພີ່ມຂຶ້ນໝາຍເຖິງການຄົ້ນພົບກໍລະນີການໃຊ້ງານໃໝ່ໆ)
• ຄວາມເພິ່ງພໍໃຈຂອງຜູ້ໃຊ້ (NPS ຫຼື ອັດຕາການນຳໃຊ້ຢ່າງຕໍ່ເນື່ອງ)
• ROI (ເວລາທີ່ຫຼຸດລົງ × ຄ່າແຮງງານ − ຄ່າໃຊ້ຈ່າຍໃນການດຳເນີນງານ)

ຈຳນວນ Agent ອາດມີຄວາມໝາຍໃນດ້ານການຈັດສັນງົບປະມານ ແລະ ການວາງແຜນບຸກຄະລາກອນ ແຕ່ຖ້າ ນຳມາໃຊ້ເປັນ KPI ໂດຍກົງ ຈະຕົກຢູ່ໃນກັບດັກທີ່ວ່າ "ການເພີ່ມຈຳນວນກາຍເປັນຈຸດປະສົງຫຼັກເສຍເອງ". ຄວນເລືອກໃຊ້ໃຫ້ເໝາະສົມໃນເອກະສານສະເໜີພາຍໃນ. ການຈັດໂຄງສ້າງເອກະສານລາຍງານຕໍ່ຝ່າຍບໍລິຫານໂດຍເນັ້ນໄປທີ່ "ການຫຼຸດຜ່ອນເວລາເຮັດວຽກ" ເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ແລະ ໃຊ້ຈຳນວນ Agent ເປັນພຽງຄ່າອ້າງອີງໃນລາຍລະອຽດຍ່ອຍ ຈະຊ່ວຍປ້ອງກັນການເຂົ້າໃຈຈຸດປະສົງຜິດພາດໄດ້ດີກວ່າ.

ການນຳໃຊ້ AgentOps ທີ່ເປັນໄປໄດ້ຫຼາຍທີ່ສຸດຄື "ການມອບໝາຍໃຫ້ທີມ SRE / DevOps ທີ່ມີຢູ່ແລ້ວ 1 ຄົນ → ແລ້ວຄ່ອຍໆແຍກບົດບາດອອກມາເປັນຂັ້ນຕອນ". ສ່ວນວິທີການສ້າງໜ່ວຍງານສະເພາະຂຶ້ນມາໃໝ່ເລີຍນັ້ນ ມັກຈະລົ້ມເຫຼວໃນຫຼາຍກໍລະນີ ເນື່ອງຈາກບັນຫາການຈັດຫາບຸກຄະລາກອນ ແລະ ການຂັດແຍ່ງກັບທີມງານທີ່ມີຢູ່ເດີມ.

ໃນທີ່ນີ້, ໂດຍສົມມຸດວ່າເປັນບໍລິສັດຂະໜາດກາງ (ມີພະນັກງານໄອທີ 5-30 ຄົນ), ພວກເຮົາຈະຈັດລະບຽບຂັ້ນຕອນການນຳໃຊ້ທີ່ເປັນໄປໄດ້ໂດຍແບ່ງອອກເປັນ 2 ມຸມມອງ.

ທີມ SRE / DevOps ທີ່ມີຢູ່ແລ້ວມີໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ານການສັງເກດການ, ຂະບວນການຮັບມືກັບເຫດການສຸກເສີນ ແລະ ການໝູນວຽນເວນຍາມ (On-call rotation) ຢູ່ແລ້ວ. ການຂະຫຍາຍສິ່ງເຫຼົ່ານີ້ໄປສູ່ AI agent ແມ່ນເສັ້ນທາງທີ່ສັ້ນທີ່ສຸດ. ໂດຍສະເພາະແມ່ນ:

1. ແຕ່ງຕັ້ງ "ຜູ້ຮັບຜິດຊອບ AI workload" 1 ຄົນພາຍໃນທີມ SRE / DevOps ແລະ ກໍານົດຂອບເຂດຄວາມຮັບຜິດຊອບໃນການດໍາເນີນງານຂອງ agent ໃຫ້ຊັດເຈນ.
2. ນໍາເອົາບັນທຶກ MCP / agent ເຂົ້າສູ່ SIEM / ເຄື່ອງມືສັງເກດການທີ່ມີຢູ່ (ຮູບແບບ JSON Lines ແມ່ນຈັດການໄດ້ງ່າຍ).
3. ເພີ່ມບົດ "ຄວາມຜິດປົກກະຕິຂອງ AI" ເຂົ້າໃນ Runbook ການຮັບມືກັບເຫດການສຸກເສີນທີ່ມີຢູ່, ພ້ອມທັງລະບຸຂັ້ນຕອນການຢຸດ, ການຣີສະຕາດ ແລະ ການຍ້ອນກັບ (Rollback) ໃຫ້ຊັດເຈນ.
4. ລວມເຂົ້າໃນການໝູນວຽນເວນຍາມ (On-call) ທີ່ມີຢູ່ (ແຕ່ໃນຊ່ວງສອງສາມເດືອນທໍາອິດ ໃຫ້ເອີ້ນສະເພາະຜູ້ຮັບຜິດຊອບ AI ເທົ່ານັ້ນ, ແລະ ເມື່ອມີຄວາມຮູ້ສະສົມພຽງພໍແລ້ວ ຈຶ່ງຂະຫຍາຍໄປຫາສະມາຊິກຄົນອື່ນ).
5. ແບ່ງປັນອັດຕາສ່ວນການຄອບຄອງຂອງ AI workload ແລະ ຈໍານວນກໍລະນີທີ່ເກີດບັນຫາໃນກອງປະຊຸມ SRE ທັງໝົດ ທຸກໆເຄິ່ງປີ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຄືການບໍ່ສ້າງ "ພະແນກທີ່ຮັບຜິດຊອບ AI ໂດຍສະເພາະ" ຂຶ້ນມາໃໝ່. ໂດຍໃຊ້ແນວຄິດດຽວກັນກັບ ການນໍາໃຊ້ຜູ້ຊ່ວຍ AI ພາຍໃນອົງກອນ, ເພື່ອຂະຫຍາຍຂອບເຂດໄປພ້ອມກັບການຮັກສາຄວາມຕໍ່ເນື່ອງໃນການດໍາເນີນງານ. ການຕັ້ງພະແນກສະເພາະຄວນພິຈາລະນາກໍຕໍ່ເມື່ອອົງກອນມີຂະໜາດໃຫຍ່ຂຶ້ນ ແລະ AI workload ມີອັດຕາສ່ວນເກີນ 30% ຂອງ SRE ທັງໝົດ ເຊິ່ງຈະເປັນການເໝາະສົມໃນແງ່ຂອງຊັບພະຍາກອນບຸກຄົນ.

ບົດບາດທີ່ຈຳເປັນສຳລັບວິສາຫະກິດຂະໜາດກາງສາມາດສະຫຼຸບໄດ້ຢ່າງໜ້ອຍ 3 ຢ່າງດັ່ງນີ້:

ສາມາດເລີ່ມຕົ້ນໂດຍການໃຫ້ບຸກຄົນດຽວຮັບຜິດຊອບຫຼາຍບົດບາດໄດ້, ແຕ່ຄວນຫຼີກລ່ຽງໂຄງສ້າງທີ່ "ເຈົ້າຂອງຮັບຜິດຊອບດ້ານການດຳເນີນງານໄປພ້ອມກັນ". ເມື່ອມຸມມອງດ້ານທຸລະກິດ ແລະ ມຸມມອງດ້ານການດຳເນີນງານທາງເຕັກນິກມາລວມຢູ່ທີ່ບຸກຄົນດຽວ, ມັກຈະເຮັດໃຫ້ເກີດຄວາມບໍ່ສົມດຸນລະຫວ່າງ KPI ແລະ ການແຈ້ງເຕືອນ (Alert). ໂດຍສະເພາະ, ມັກຈະເກີດປະກົດການທີ່ຝ່າຍທຸລະກິດຍອມຜ່ອນຜັນການດຳເນີນງານຕາມ SLO ເພື່ອໃຫ້ໄດ້ຜົນງານ, ຫຼື ຕັດສິນວ່າການໃຊ້ຈ່າຍເກີນງົບປະມານນັ້ນເປັນ "ສິ່ງທີ່ຈຳເປັນຕໍ່ທຸລະກິດ" ຈຶ່ງປ່ອຍຜ່ານໄປ. ການແບ່ງບົດບາດເພື່ອໃຫ້ມີໂຄງສ້າງທີ່ສາມາດກວດສອບເຊິ່ງກັນ ແລະ ກັນໄດ້ ຈະຊ່ວຍໃຫ້ການດຳເນີນງານມີຄວາມໝັ້ນຄົງໃນໄລຍະຍາວ.

---

ໃນບັນດາຄຳຖາມທີ່ພົບເລື້ອຍທີ່ສຸດຈາກໜ້າວຽກຕົວຈິງກ່ຽວກັບການນຳໃຊ້ AgentOps, ຂ້າພະເຈົ້າຈະຍົກເອົາຫົວຂໍ້ສຳຄັນໜຶ່ງທີ່ບໍ່ໄດ້ລະບຸໄວ້ຢ່າງລະອຽດໃນຄູ່ມືນີ້ມາອະທິບາຍ. ໂດຍຈະເນັ້ນໄປທີ່ຮູບແບບການລົ້ມເຫຼວທີ່ມັກພົບເລື້ອຍໃນເວລາເປີດຕົວ ຫຼື Launch ລະບົບສູ່ການໃຊ້ງານຈິງ.

Q. ເປັນຫຍັງການດຳເນີນງານຂອງ Agent ທີ່ໄປໄດ້ສວຍໃນໄລຍະທົດລອງ (Pilot) ຈຶ່ງລົ້ມເຫຼວເມື່ອເປີດຕົວ ຫຼື Launch ສູ່ການໃຊ້ງານຈິງ?

ຮູບແບບການລົ້ມເຫຼວສາມາດແບ່ງອອກໄດ້ເປັນ 3 ປະການໃຫຍ່ໆ:

• ຄວາມລົ້ມເຫຼວດ້ານຕົ້ນທຶນ (Cost): ຕົ້ນທຶນທີ່ຄິດໄລ່ຈາກປະລິມານການໃຊ້ງານໃນໄລຍະທົດລອງ ຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ເມື່ອພົບກັບພາລະງານໃນການໃຊ້ງານຈິງ. ບໍ່ພຽງແຕ່ຈຳນວນຜູ້ໃຊ້ທີ່ເພີ່ມຂຶ້ນເທົ່ານັ້ນ, ແຕ່ຈຳນວນຂັ້ນຕອນການຄິດໄລ່ຕໍ່ 1 ວຽກງານກໍມີແນວໂນ້ມເພີ່ມຂຶ້ນນຳ (ເນື່ອງຈາກຜູ້ໃຊ້ເລີ່ມມອບໝາຍກໍລະນີທີ່ຊັບຊ້ອນໃຫ້ Agent ເຮັດວຽກແທນ). ກ່ອນການເປີດຕົວ ຫຼື Launch ຕ້ອງມີການຄາດຄະເນຕົ້ນທຶນໃນຊ່ວງເວລາທີ່ມີການໃຊ້ງານສູງສຸດ (Peak) ແລະ ກຳນົດຄ່າ Threshold ຂອງການແຈ້ງເຕືອນໄວ້ສະເໝີ, ລວມທັງອອກແບບລະບົບໃຫ້ຢຸດການເຮັດວຽກອັດຕະໂນມັດ ຫຼື ສະຫຼັບໄປໃຊ້ HITL ເມື່ອເກີນງົບປະມານທີ່ກຳນົດ.
• ຄວາມລົ້ມເຫຼວດ້ານການກວດສອບ (Audit): ບັນທຶກການກວດສອບ (Audit log) ທີ່ບໍ່ໄດ້ເກັບໃນໄລຍະທົດລອງ ອາດກາຍເປັນສິ່ງທີ່ຈຳເປັນຕ້ອງມີຕາມຂໍ້ກຳນົດ PDPA ຫຼື ການຄວບຄຸມພາຍໃນເມື່ອເປີດຕົວ ຫຼື Launch. ການມາເພີ່ມລະບົບເກັບ Log ພາຍຫຼັງຈະເຮັດໃຫ້ຂໍ້ມູນໃນອະດີດສູນເສຍໄປ, ດັ່ງນັ້ນຈຶ່ງຕ້ອງຄາດຄະເນຄວາມຕ້ອງການດ້ານການກວດສອບຕັ້ງແຕ່ຕົ້ນ ແລະ ວາງໂຄງສ້າງການອອກແບບ Log ໃຫ້ຮອງຮັບ. ໂດຍສະເພາະການສົນທະນາທີ່ມີຂໍ້ມູນ PII ຕ້ອງມີການກຳນົດກົດລະບຽບການປິດບັງຂໍ້ມູນ (Masking) ໄວ້ລ່ວງໜ້າ.
• ຄວາມລົ້ມເຫຼວດ້ານ HITL (Human-in-the-loop): ສິ່ງທີ່ຜູ້ດູແລລະບົບເຄີຍອະນຸມັດເປັນລາຍກໍລະນີໃນໄລຍະທົດລອງ ອາດກາຍເປັນຈຳນວນມະຫາສານໃນການໃຊ້ງານຈິງ ຈົນຜູ້ກວດສອບ (Reviewer) ຮັບມືບໍ່ທັນ. ຕ້ອງອອກແບບຄ່າ Threshold ແລະ ອັດຕາການສຸ່ມກວດ (Sampling rate) ຂອງ HITL ຄືນໃໝ່ໃຫ້ສອດຄ່ອງກັບການໃຊ້ງານຈິງ, ພ້ອມທັງປະເມີນ SLA ແລະ ຈຳນວນຜູ້ກວດສອບທີ່ຈຳເປັນ. ການຂາດແຄນຜູ້ກວດສອບເປັນສາເຫດຂອງຄວາມລົ້ມເຫຼວທີ່ພົບຫຼາຍທີ່ສຸດ, ສະນັ້ນຄວນເລີ່ມວາງແຜນດ້ານບຸກຄະລາກອນໄວ້ແຕ່ເນิ่นໆ.

ການປ່ຽນຜ່ານຈາກໄລຍະທົດລອງໄປສູ່ການໃຊ້ງານຈິງ ຄວນຖືວ່າເປັນ "ຂັ້ນຕອນການອອກແບບໃໝ່ເພື່ອຮອງຮັບພາລະງານໃນການໃຊ້ງານຈິງ" ບໍ່ແມ່ນ "ການຂະຫຍາຍສິ່ງທີ່ມີຢູ່ໃຫ້ໃຫຍ່ຂຶ້ນ". ການແບ່ງໜ້າທີ່ລະຫວ່າງຄົນກັບ AI ທີ່ໄດ້ສົນທະນາໃນ ຄູ່ມື Hybrid BPO ກໍຈຳເປັນຕ້ອງໄດ້ທົບທວນຄືນເມື່ອຂະໜາດຂອງງານປ່ຽນແປງ. ໂດຍສະເພາະແລ້ວ, ສ່ວນແບ່ງງານທີ່ໃນໄລຍະທົດລອງແມ່ນ "AI 80% ແລະ ຄົນ 20%" ມັກຈະປ່ຽນເປັນ "AI 60% ແລະ ຄົນ 40%" ເມື່ອເປີດຕົວ ຫຼື Launch. ນີ້ບໍ່ແມ່ນບັນຫາດ້ານຄຸນນະພາບ ແຕ່ຄວນເບິ່ງວ່າເປັນປະກົດການທີ່ຂອບເຂດການເຂົ້າແຊກແຊງຂອງມະນຸດ (ລວມເຖິງ HITL) ໄດ້ຂະຫຍາຍຕົວຂຶ້ນນັ້ນເອງ.

AgentOps ແມ່ນກອບການເຮັດວຽກເພື່ອຈັດການກັບ AI agent ບໍ່ແມ່ນໃນຖານະ "ການນຳໃຊ້ເຄື່ອງມື" ແຕ່ເປັນ "ວຽກງານການດຳເນີນງານປົກກະຕິຂອງອົງກອນ".

ລຳດັບຄວາມສຳຄັນໃນການນຳໃຊ້ມີ 3 ຂັ້ນຕອນດັ່ງນີ້:

• Step 1: ການສຳຫຼວດສະຖານະປັດຈຸບັນ ແລະ ການລະບຸຄວາມເປັນເຈົ້າຂອງຢ່າງຊັດເຈນດ້ວຍ Agent Registry
• Step 2: ກຳນົດຕົວຊີ້ວັດ SLI / SLO ແລະ ຕົ້ນທຶນຢ່າງໜ້ອຍ 4 ຢ່າງ, ພ້ອມທັງລວມການຕິດຕາມກວດກາເຂົ້າກັບທີມ SRE / DevOps ທີ່ມີຢູ່
• Step 3: ຕົກລົງເຫັນດີກ່ຽວກັບເກນມາດຕະຖານຂອງ HITL ແລະ ເສັ້ນທາງການແຈ້ງເຕືອນ (Escalation Path) ກັບເຈົ້າຂອງພາກສ່ວນທຸລະກິດ

ການຈັດຕັ້ງ ບົດບາດ ແລະ ອຳນາດການຕັດສິນໃຈ ຄວນມາກ່ອນການຈັດຫາໜ່ວຍງານສະເພາະ ຫຼື ເຄື່ອງມືສະເພາະທາງ. ນີ້ແມ່ນສ່ວນທີ່ຈຳເປັນຄືກັນໃນການເຮັດໃຫ້ການດຳເນີນງານຈິງສຳເລັດຜົນ ບໍ່ວ່າຈະເປັນ ການນຳໃຊ້ AI ຜູ້ຊ່ວຍພາຍໃນອົງກອນ ຫຼື ການຈັດຕັ້ງປະຕິບັດ AI agent ພາສາລາວ. ການເບິ່ງ AgentOps ໃນຖານະທິດສະດີການກຳກັບດູແລການດຳເນີນງານໃນຍຸກ AI ຈະຊ່ວຍໃຫ້ການສ້າງຄວາມເຫັນດີເຫັນພ້ອມໃນໜ້າວຽກຈິງໄດ້ງ່າຍກວ່າການເບິ່ງເປັນພຽງທິດສະດີທາງເຕັກນິກ.

ສຳລັບຄູ່ມືທີ່ກ່ຽວຂ້ອງ, ການອ່ານ AI ຜູ້ຊ່ວຍພາຍໃນອົງກອນ, ຄູ່ມື Hybrid BPO ແລະ ແນະນຳໂປຣໂຕຄອນ MCP ຄວບຄູ່ກັນໄປ ຈະຊ່ວຍໃຫ້ເຫັນຈຸດເຊື່ອມຕໍ່ລະຫວ່າງ AgentOps ແລະ ການດຳເນີນງານທີ່ມີຢູ່ໄດ້ຢ່າງຊັດເຈນ. ກ້າວຕໍ່ໄປທີ່ແນະນຳຄື "ການເລືອກ AI agent ຂອງບໍລິສັດຕົນເອງມາ 1 ຕົວ ແລະ ລອງສ້າງໃບສຳຫຼວດຕາມອົງປະກອບທັງ 5 ຂອງຄູ່ມືນີ້" ເຊິ່ງຈະເປັນຈຸດເລີ່ມຕົ້ນທີ່ເປັນຮູບປະທຳເພື່ອບໍ່ໃຫ້ຢຸດຢູ່ພຽງແຕ່ທິດສະດີນາມມະທຳ.