Multi-AI Agent ແມ່ນລະບົບທີ່ປະກອບດ້ວຍຫຼາຍ Agent ທີ່ມີຄວາມຊ່ຽວຊານແຕກຕ່າງກັນມາແບ່ງໜ້າທີ່ ແລະ ຮ່ວມມືກັນເພື່ອເຮັດວຽກໜຶ່ງໃຫ້ສຳເລັດ. ສຳລັບ Workflow ທີ່ມີຄວາມຊັບຊ້ອນເກີນກວ່າທີ່ Agent ຕົວດຽວຈະຮັບມືໄດ້ ຫຼື ວຽກງານທີ່ມີຄວາມຍາວເກີນກວ່າຂີດຈຳກັດຂອງ Context length, ການອອກແບບໂດຍໃຊ້ຮູບແບບການແບ່ງງານ (Division of labor), ການສົ່ງຕໍ່ວຽກ (Handoff) ແລະ ການປະມວນຜົນແບບຂະໜານ (Parallel execution) ຖືເປັນວິທີແກ້ໄຂທີ່ມີປະສິດທິພາບ.

ບົດຄວາມນີ້ມີຈຸດປະສົງສຳລັບວິສະວະກອນ ແລະ ສະຖາປະນິກທີ່ກຳລັງພິຈາລະນາການອອກແບບ ແລະ ການຈັດຕັ້ງປະຕິບັດລະບົບ Multi-agent. ບົດຄວາມນີ້ຈະສະຫຼຸບມຸມມອງດ້ານການຈັດຕັ້ງປະຕິບັດ ໂດຍເລີ່ມຈາກການເລືອກໃຊ້ຮູບແບບ Orchestrator, Handoff ແລະ Parallel worker, ການສົ່ງຕໍ່ສະຖານະລະຫວ່າງ Agent, ການອອກແບບເພື່ອຮອງຮັບຄວາມຜິດພາດ, ໄປຈົນເຖິງຂັ້ນຕອນການປ່ຽນຜ່ານຈາກ Agent ຕົວດຽວໄປສູ່ລະບົບຫຼາຍ Agent ຢ່າງເປັນຂັ້ນຕອນ. ການເຂົ້າໃຈເຫດຜົນໃນການຕັດສິນໃຈອອກແບບຈະຊ່ວຍໃຫ້ທ່ານສາມາດເລືອກ Architecture ທີ່ເໝາະສົມກັບ Use case ຂອງອົງກອນທ່ານໄດ້.

AI ເອເຈນແບບດ່ຽວຈະໃຊ້ພຽງ 1 ໂມເດວໃນການປະມວນຜົນທຸກວຽກງານ, ແຕ່ລະບົບຫຼາຍເອເຈນ (Multi-agent) ຈະມີເອເຈນຫຼາຍຕົວມາແບ່ງໜ້າທີ່ກັນເຮັດວຽກຢ່າງປະສານງານ. ເມື່ອຂະໜາດ ແລະ ຄວາມຊັບຊ້ອນເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ, ມັນກໍຈະມີສະຖານະການທີ່ໂຄງສ້າງແບບດ່ຽວບໍ່ສາມາດຮອງຮັບໄດ້. ບົດຄວາມນີ້ຈະສະຫຼຸບໃຫ້ເຫັນວ່າຂີດຈຳກັດຈະມາເຖິງໃນຈຸດໃດ ແລະ ການແບ່ງງານກັນເຮັດຈະເຮັດໃຫ້ເກີດການປ່ຽນແປງແນວໃດ.

ຫຼາຍຄົນມັກຄິດວ່າການຂະຫຍາຍ Single Agent ຕໍ່ໄປເລື້ອຍໆຈະສາມາດແກ້ໄຂບັນຫາໄດ້, ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ເມື່ອຮອດຈຸດໜຶ່ງ ການເພີ່ມຄວາມຍາວຂອງ Prompt ຈະເຮັດໃຫ້ຄວາມແມ່ນຍຳຫຼຸດລົງ ແລະ ການເພີ່ມຈຳນວນ Tool ຈະເຮັດໃຫ້ເກີດການເອີ້ນໃຊ້ງານຜິດພາດຫຼາຍຂຶ້ນ ເຊິ່ງເປັນຜົນກະທົບທາງລົບ. ຫາກມີສັນຍານ 3 ຢ່າງຕໍ່ໄປນີ້ເກີດຂຶ້ນພ້ອມກັນ, ນັ້ນຄືເວລາທີ່ຄວນພິຈາລະນາປັບປຸງການອອກແບບໃໝ່:

① Context Window ຢູ່ໃນສະພາວະຕຶງຄຽດຢູ່ຕະຫຼອດເວລາ

ເມື່ອ System Prompt, ຄຳນິຍາມຂອງ Tool, ປະຫວັດການສົນທະນາ ແລະ ຜົນລວມຊົ່ວຄາວສະສົມກັນ ຈົນເຮັດໃຫ້ປະລິມານຂໍ້ມູນທີ່ Model ສາມາດຮັບໄດ້ໃກ້ຈະຮອດຂີດຈຳກັດຢູ່ຕະຫຼອດເວລາ, ມັນຈະເພີ່ມຄວາມສ່ຽງທີ່ຄຳສັ່ງສຳຄັນຈະຖືກ "ດັນອອກ" ແລະ ຖືກລະເລີຍ. ການທີ່ຄຳນິຍາມຂອງ Tool ພຽງຢ່າງດຽວໃຊ້ Token ຫຼາຍພັນ Token ນັ້ນບໍ່ແມ່ນເລື່ອງແປກ ເຊິ່ງມັນຈະໄປກົດດັນ Context ທີ່ຄວນຈະໃຊ້ໃນການວິເຄາະຕົວຈິງ.

② ເກີດຄວາມຜິດພາດໃນການເອີ້ນໃຊ້ Tool ຫຼື ລຳດັບຜິດພາດເລື້ອຍໆ

ຫາກໃຫ້ Agent ຕົວດຽວຖື Tool ຫຼາຍກວ່າ 10 ຢ່າງ, Model ມັກຈະສັບສົນກັບຟັງຊັນທີ່ມີລັກສະນະຄ້າຍຄືກັນ ຫຼື ມີທ່າອ່ຽງທີ່ຈະປະຕິບັດຕາມຂັ້ນຕອນທີ່ມີຄວາມສຳພັນກັນແບບປີ້ນກັບ. ເຖິງແມ່ນວ່າຈະປັບປຸງ Prompt ທຸກຄັ້ງທີ່ມີການ Debug, ແຕ່ກໍມັກຈະຕົກຢູ່ໃນວົງຈອນທີ່ບັນຫາຄ້າຍຄືກັນນີ້ກັບມາເກີດຂຶ້ນຊ້ຳອີກກັບ Tool ອື່ນ.

③ ເມື່ອບາງສ່ວນຂອງ Task ລົ້ມເຫຼວ ຈຳເປັນຕ້ອງເລີ່ມໃໝ່ທັງໝົດ

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

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

ການນຳໃຊ້ລະບົບຫຼາຍຕົວແທນ (Multi-agent) ຈະມີປະສິດທິຜົນໃນກໍລະນີທີ່ວຽກງານສາມາດແບ່ງອອກໄດ້ຢ່າງຊັດເຈນ ແລະ ແຕ່ລະຕົວແທນສາມາດດຳເນີນການໄດ້ຢ່າງອິດສະຫຼະ. ໃນທາງກົງກັນຂ້າມ, ມັນບໍ່ແມ່ນວິທີແກ້ໄຂທີ່ໃຊ້ໄດ້ກັບທຸກຢ່າງ ແລະ ມີຂອບເຂດຈຳກັດທີ່ຊັດເຈນໃນການນຳໄປໃຊ້ກັບວຽກງານຕ່າງໆ.

ສິ່ງທີ່ສາມາດແກ້ໄຂໄດ້

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

ສິ່ງທີ່ບໍ່ສາມາດແກ້ໄຂໄດ້ ແລະ ພື້ນທີ່ທີ່ຕ້ອງລະມັດລະວັງ

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

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

ຍິ່ງໄປກວ່ານັ້ນ, ເມື່ອຈຳນວນຕົວແທນເພີ່ມຂຶ້ນ ຄວາມຍາກໃນການ Debug ແລະ ການຕິດຕາມກວດກາກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

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

ເມື່ອເພີ່ມວຽກງານໃສ່ໃນ Single Agent ຢ່າງຕໍ່ເນື່ອງ, ໃນທີ່ສຸດທັງ Context Window ແລະລາຍການເຄື່ອງມື (Tool list) ຈະໃກ້ຮອດຂີດຈຳກັດ. ສະພາບການນີ້ກໍຄືກັບການມອບຄູ່ມືການເຮັດວຽກທັງໝົດ ແລະ ສິດທິໃນການເຂົ້າເຖິງລະບົບຂອງບໍລິສັດໃຫ້ກັບພະນັກງານພຽງຄົນດຽວໃນເວລາດຽວກັນ, ເຊິ່ງເປັນສະພາບທີ່ "ຄວາມຫຍຸ້ງຍາກໃນການຊອກຫາເຄື່ອງມືທີ່ຈະໃຊ້" ຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຫຼາຍກວ່າຄວາມຖືກຕ້ອງໃນການປະມວນຜົນ.

ຄວາມຖືກຕ້ອງໃນການເລືອກເຄື່ອງມືຂອງ LLM ມີແນວໂນ້ມທີ່ຈະຫຼຸດລົງເມື່ອຈຳນວນເຄື່ອງມືທີ່ລົງທະບຽນໄວ້ເພີ່ມຂຶ້ນ. ໃນຂັ້ນຕອນທີ່ມີເຄື່ອງມືໜ້ອຍ, ເຮົາສາມາດຄາດຫວັງການເລືອກທີ່ເໝາະສົມໄດ້, ແຕ່ມີລາຍງານວ່າເມື່ອຈຳນວນເຄື່ອງມືເພີ່ມຂຶ້ນ ກໍຈະເກີດການເລືອກຜິດພາດ ຫຼື ການຮຽກໃຊ້ເຄື່ອງມືທີ່ບໍ່ຈຳເປັນເພີ່ມຂຶ້ນ. ເຊັ່ນດຽວກັນກັບຄວາມຍາວຂອງ Context, ເມື່ອປະຫວັດການສົນທະນາ, System Prompt, ຄຳນິຍາມຂອງເຄື່ອງມື ແລະ ຜົນລວມລະຫວ່າງທາງທັງໝົດຖືກສະສົມໄວ້ໃນ Window ດຽວກັນ, ຈະເກີດປະກົດການທີ່ Model ມອງຂ້າມຄຳສັ່ງໃນຕອນທ້າຍ ຫຼື ເຮັດໃຫ້ການອ້າງອີງເຖິງບໍລິບົດໃນຕອນຕົ້ນເຮັດໄດ້ຍາກຂຶ້ນ.

ການປ່ຽນໄປໃຊ້ Multi-agent ຈະແກ້ໄຂບັນຫານີ້ດ້ວຍການ "ແບ່ງສ່ວນ". ໂດຍສະເພາະ 2 ຈຸດຕໍ່ໄປນີ້ແມ່ນມີປະສິດທິພາບ:

• ການເຮັດໃຫ້ເຄື່ອງມືເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ (Tool Localization): ມອບໝາຍພຽງແຕ່ເຄື່ອງມືທີ່ຈຳເປັນຂັ້ນຕ່ຳໃຫ້ກັບແຕ່ລະ Agent. ຕົວຢ່າງເຊັ່ນ: "Search Agent" ຈະໄດ້ຮັບພຽງແຕ່ການຄົ້ນຫາ Web ແລະ ການດຶງຂໍ້ມູນ RAG ເທົ່ານັ້ນ, ສ່ວນ "Code Generation Agent" ຈະໄດ້ຮັບພຽງແຕ່ສະພາບແວດລ້ອມການປະມວນຜົນ Code ເທົ່ານັ້ນ.
• ການແບ່ງແຍກ Context: ໂດຍການຈຳກັດຂໍ້ມູນທີ່ສົ່ງຕໍ່ລະຫວ່າງ Agent ໃຫ້ເປັນພຽງ "ຂໍ້ຄວາມສົ່ງຕໍ່ທີ່ສະຫຼຸບແລ້ວ" ແທນທີ່ຈະເປັນປະຫວັດທັງໝົດ, ຈະຊ່ວຍໃຫ້ Window ຂອງແຕ່ລະ Agent ຢູ່ໃນສະພາບທີ່ສະອາດຢູ່ສະເໝີ.

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

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

ການປັບໃຫ້ເໝາະສົມຕາມບົດບາດໜ້າທີ່ ສາມາດພິຈາລະນາໄດ້ຈາກ 3 ແກນຫຼັກ ດັ່ງນີ້:

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

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

ການມອບໝາຍຮູບແບບບໍ່ແມ່ນສິ່ງທີ່ຕາຍຕົວ, ແຕ່ຈຸດແຂງຂອງໂຄງສ້າງຫຼາຍຕົວແທນ (Multi-agent) ຄື ສາມາດປ່ຽນແທນໄດ້ຕາມການປ່ຽນແປງຂອງປະລິມານວຽກ ແລະ ງົບປະມານ.

ໂຄງສ້າງຂອງ Multi-agent ສາມາດແບ່ງອອກໄດ້ເປັນ 3 ຮູບແບບຫຼັກໆ ຄື: ຮູບແບບ Orchestrator ທີ່ມີເອເຈນທີ່ເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຄອຍອອກຄຳສັ່ງ, ຮູບແບບ Handoff ທີ່ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ກັນຕາມລຳດັບ, ແລະ ຮູບແບບ Parallel Worker ທີ່ຫຼາຍເອເຈນເຮັດວຽກຂະໜານກັນ. ແຕ່ລະຮູບແບບມີລະດັບການຄວບຄຸມ ແລະ ຂະບວນການ ຫຼື Pipeline ຂອງການປະມວນຜົນທີ່ແຕກຕ່າງກັນ.

ເມື່ອທ່ານຮູ້ສຶກວ່າ "ການສັ່ງງານດ້ວຍ Prompt ທຸກຄັ້ງວ່າຄວນຂໍໃຫ້ Agent ຕົວໃດເຮັດຫຍັງນັ້ນ ມີຂີດຈຳກັດ", ຮູບແບບ Orchestrator ຈະກາຍເປັນທາງເລືອກທີ່ໜ້າສົນໃຈ.

ໃນຮູບແບບນີ້, Agent ທີ່ເຮັດໜ້າທີ່ຄວບຄຸມໂດຍສະເພາະ ເຊິ່ງເອີ້ນວ່າ Orchestrator ຈະເປັນຜູ້ຮັບໜ້າວຽກທັງໝົດ, ຮັບຜິດຊອບໃນການມອບໝາຍວຽກໃຫ້ Sub-agent, ກຳນົດລຳດັບການປະຕິບັດງານ ແລະ ລວມຜົນລັອກທັງໝົດ. Sub-agent ຈະຕອບສະໜອງຕໍ່ຄຳສັ່ງຂອງ Orchestrator ເທົ່ານັ້ນ ແລະ ຈະບໍ່ສື່ສານໂດຍກົງລະຫວ່າງກັນ.

ລັກສະນະທາງໂຄງສ້າງສາມາດສະຫຼຸບໄດ້ດັ່ງນີ້:

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

ຮູບແບບ Sequential ແລະ Concurrent ຂອງ Microsoft Agent Framework ລ້ວນແລ້ວແຕ່ເປັນການປັບປ່ຽນມາຈາກຮູບແບບ Orchestrator ນີ້, ເຊິ່ງແຕກຕ່າງກັນພຽງແຕ່ການກຳນົດລຳດັບການເຮັດວຽກວ່າຈະເປັນແບບອະນຸກົມ (Serial) ຫຼື ແບບຂະໜານ (Parallel).

ຂໍ້ຄວນລະວັງຄື Orchestrator ມັກຈະກາຍເປັນຄໍຂວດ (Bottleneck) ໄດ້ງ່າຍ. ເນື່ອງຈາກການສື່ສານທັງໝົດຕ້ອງຜ່ານຈຸດນີ້, ຖ້າການອອກແບບ Prompt ຂອງ Orchestrator ບໍ່ລະອຽດພໍ ກໍຈະສົ່ງຜົນໃຫ້ຄຳສັ່ງທີ່ສົ່ງໄປຍັງ Sub-agent ຜິດພາດໄດ້.

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

ໃນ OpenAI Agents SDK, Handoff ຖືກນຳມາໃຊ້ງານເປັນເຄື່ອງມື (ຟັງຊັນ), ເຊິ່ງໃນທັນທີທີ່ຖືກຮຽກໃຊ້ ການປະມວນຜົນຈະປ່ຽນໄປຍັງຕົວແທນປາຍທາງ ແລະ ສະຖານະການສົນທະນາຫຼ້າສຸດຈະຖືກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ທັນທີ. ກ່າວຄື, ຕົວແທນຕໍ່ໄປຈະເລີ່ມເຮັດວຽກໂດຍສືບຕໍ່ຈາກບໍລິບົດທີ່ຕົວແທນກ່ອນໜ້າໄດ້ສ້າງໄວ້, ເຮັດໃຫ້ບໍ່ຈຳເປັນຕ້ອງປ້ອນຂໍ້ມູນໃໝ່ ຫຼື ຕີຄວາມໝາຍໃໝ່.

ຕົວຢ່າງການນຳໃຊ້ທີ່ເຫັນໄດ້ຊັດເຈນຄື ເວີກໂຟລ (Workflow) ທີ່ມີຂັ້ນຕອນການຈັດລຳດັບຢ່າງຊັດເຈນ:

• ການຕອບຮັບຄຳຖາມ: ຕົວແທນຄັດກອງ (Triage agent) ຈຳແນກຈຸດປະສົງ → ຕົວແທນຜູ້ຊ່ຽວຊານສ້າງຄຳຕອບ → ຕົວແທນກວດສອບຄຸນນະພາບກວດສອບຂັ້ນສຸດທ້າຍ
• ການປະມວນຜົນເອກະສານ: ຕົວແທນສະກັດຂໍ້ມູນຈັດໂຄງສ້າງຂໍ້ມູນ → ຕົວແທນກວດສອບປຽບທຽບກັບກົດລະບຽບ → ຕົວແທນແຈ້ງເຕືອນສົ່ງຂໍ້ມູນ

ວິທີນີ້ມີປະສິດທິພາບໂດຍສະເພາະໃນກໍລະນີທີ່ຜົນລັດຂອງແຕ່ລະຂັ້ນຕອນເຊື່ອມໂຍງໂດຍກົງກັບການປ້ອນຂໍ້ມູນຂອງຂັ້ນຕອນຕໍ່ໄປ ແລະ ມີຊ່ອງວ່າງໃນການເຮັດວຽກແບບຂະໜານໜ້ອຍ.

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

ຮູບແບບ Parallel Worker ແມ່ນຮູບແບບທີ່ດຳເນີນການຫຼາຍໆ Subtask ທີ່ສາມາດເຮັດວຽກໄດ້ຢ່າງອິດສະຫຼະພ້ອມໆກັນ, ແລ້ວຈຶ່ງລວມຜົນລັອກໃນຕອນທ້າຍ. ໃນຕອນທຳອິດ ເຮົາມັກຈະຄິດວ່າ "ການປະມວນຜົນຕາມລຳດັບຈະມີຄວາມແນ່ນອນກວ່າ", ແຕ່ການຈັດລຽງ Task ທີ່ບໍ່ມີຄວາມສຳພັນຕໍ່ກັນໄວ້ໃນແນວຕັ້ງ ຫຼື Vertical ຈະເຮັດໃຫ້ເວລາລໍຖ້າສະສົມເພີ່ມຂຶ້ນ ແລະ ເຮັດໃຫ້ Latency ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ໂດຍບໍ່ຈຳເປັນ. ການກຳນົດຈຸດທີ່ສາມາດເຮັດວຽກຂະໜານກັນໄດ້ແລ້ວແຈກຢາຍວຽກອອກໄປ ຈະສາມາດປັບປຸງ Throughput ໂດຍລວມໄດ້ດີກວ່າຫຼາຍ.

ໂຄງສ້າງທົ່ວໄປມີດັ່ງນີ້:

• Dispatcher: ຮັບ Input, ແບ່ງອອກເປັນ Subtask ແລະ ມອບໝາຍໃຫ້ Worker Agent ແຕ່ລະຕົວ
• ກຸ່ມ Worker Agent: ແຕ່ລະຕົວຈະດຳເນີນການປະມວນຜົນທີ່ເປັນອິດສະຫຼະ (ການຄົ້ນຫາ, ການສະຫຼຸບ, ການຈັດໝວດໝູ່ ແລະ ອື່ນໆ) ໄປພ້ອມໆກັນ
• Aggregator: ຮັບ Output ຈາກທຸກ Worker, ເຮັດການລວມ ຫຼື Merge ແລະ ຈັດຮູບແບບເພື່ອສົ່ງຜົນລັອກສຸດທ້າຍ

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

ຢ່າງໃດກໍຕາມ, ການເຮັດວຽກຂະໜານມີເງື່ອນໄຂເບື້ອງຕົ້ນຄື: ຜົນການປະມວນຜົນຂອງ Worker ແຕ່ລະຕົວຕ້ອງເປັນອິດສະຫຼະຕໍ່ກັນ, ແລະ ໃນຂັ້ນຕອນການລວມຜົນລັອກ ຕ້ອງສາມາດຈັດການກັບລຳດັບ ຫຼື ຂໍ້ມູນທີ່ຂາດຫາຍໄປໄດ້ຢ່າງເໝາະສົມ. ຖ້າມີຄວາມສຳພັນທີ່ Output ຂອງ Worker ຕົວໜຶ່ງກາຍເປັນ Input ຂອງອີກຕົວໜຶ່ງ, ຄວນເລືອກໃຊ້ຮູບແບບ Handoff ຫຼື Orchestrator ແທນຮູບແບບ Parallel Worker.

ການອອກແບບ Logic ໃນການລວມຜົນລັອກກໍມີຄວາມສຳຄັນເຊັ່ນກັນ. ບໍ່ພຽງແຕ່ການເຊື່ອມຕໍ່ແບບງ່າຍໆເທົ່ານັ້ນ, ແຕ່ການພິຈາລະນາເຖິງການໄກ່ເກ່ຍ Output ທີ່ຂັດແຍ່ງກັນ ຫຼື ການຈັດການກັບຜົນລັອກບາງສ່ວນໃນກໍລະນີທີ່ Worker ບາງຕົວເຮັດວຽກລົ້ມເຫຼວ ຈະຊ່ວຍເພີ່ມຄວາມສະຖຽນໃນສະພາບແວດລ້ອມການໃຊ້ງານຈິງໄດ້ຫຼາຍຂຶ້ນ.

ທັງ 3 ຮູບແບບມີຄວາມຖະໜັດໃນສະຖານະການທີ່ແຕກຕ່າງກັນ, ດັ່ງນັ້ນການເລືອກໃຫ້ເໝາະສົມກັບລັກສະນະຂອງວຽກງານຈຶ່ງມີຄວາມສຳຄັນຫຼາຍ. ເກນໃນການຕັດສິນໃຈມີ 2 ຢ່າງຄື: "ຄວາມສາມາດໃນການແຍກວຽກງານ ແລະ ຄວາມສຳພັນທີ່ເພິ່ງພາອາໄສກັນ" ແລະ "ການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງ Latency, ຕົ້ນທຶນ ແລະ ຄວາມສາມາດໃນການເຮັດຊ້ຳ".

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

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

ຕໍ່ມາແມ່ນການກວດສອບ ທິດທາງຂອງຄວາມສຳພັນທີ່ຕ້ອງເພິ່ງພາອາໄສກັນ (Dependency). ຖ້າຄວາມສຳພັນນັ້ນເຊື່ອມຕໍ່ກັນໄປໃນທິດທາງດຽວ, ຮູບແບບ Handoff ຈະເໝາະສົມທີ່ສຸດ ເຊິ່ງເປັນການໄຫຼຂອງວຽກແບບເສັ້ນຊື່ ເຊັ່ນ: ຂັ້ນຕອນ A ສົ່ງຜົນລັດໃຫ້ຂັ້ນຕອນ B ແລະ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຂັ້ນຕອນ C. ໃນທາງກົງກັນຂ້າມ, ຖ້າວິທີການປະສົມປະສານວຽກຍ່ອຍບໍ່ສາມາດກຳນົດໄດ້ຈົນກວ່າຈະຮອດເວລາປະຕິບັດງານ, ຫຼື ຕົວແທນ (Agent) ທີ່ຖືກຮຽກໃຊ້ຈະປ່ຽນແປງໄປຕາມເງື່ອນໄຂ, ຮູບແບບ Orchestrator ຈະເໝາະສົມກວ່າ ເພາະ Orchestrator ທີ່ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ສາມາດຕັດສິນສະຖານະການ ແລະ ກຳນົດຜູ້ຮັບຜິດຊອບວຽກງານໄດ້ຢ່າງຄ່ອງຕົວ.

ສະຫຼຸບມາດຕະຖານໃນການຕັດສິນໃຈໄດ້ດັ່ງນີ້:

ຂໍ້ຄວນລະວັງຄື: ໃນກໍລະນີທີ່ຄວາມສຳພັນມີຄວາມຊັບຊ້ອນຫຼາຍ, ບໍ່ຄວນຝືນໃຊ້ຮູບແບບໃດໜຶ່ງພຽງຮູບແບບດຽວ, ແຕ່ຄວນພິຈາລະນາການອອກແບບແບບ Hybrid ທີ່ Orchestrator ເປັນຜູ້ຄວບຄຸມ Parallel Worker ໄປພ້ອມກັນ.

ໃນການເລືອກ 3 ຮູບແບບ, ນອກຈາກຄວາມສາມາດໃນການແຍກວຽກງານ (Task decomposition) ແລະ ຄວາມສຳພັນທີ່ເພິ່ງພາອາໄສກັນແລ້ວ, ຍັງມີປັດໄຈໃນການຕັດສິນໃຈຈາກ 3 ແກນຫຼັກ ຄື: Latency, Cost, ແລະ Reproducibility ເຊິ່ງເປັນການແລກປ່ຽນ ຫຼື Trade-off ທີ່ສຳຄັນ.

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

ໃນດ້ານ Reproducibility, ຮູບແບບ Orchestrator ມີແນວໂນ້ມທີ່ຈະມີຄວາມສະຖຽນຫຼາຍທີ່ສຸດ ເນື່ອງຈາກເຫດຜົນການຄວບຄຸມ (Control logic) ລວມຢູ່ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກຈຸດດຽວ ເຮັດໃຫ້ການ Debug ແລະ ການເກັບ Audit log ເຮັດໄດ້ງ່າຍ. ໃນທາງກົງກັນຂ້າມ, ຮູບແບບ Handoff ຜົນລັອບຂອງ Agent ທີ່ຕາມມາຈະຂຶ້ນກັບຄຸນນະພາບຂອງຂໍ້ຄວາມທີ່ສົ່ງຕໍ່, ດັ່ງນັ້ນຄວາມແມ່ນຍຳໃນການອອກແບບ Prompt ຈຶ່ງມີຜົນໂດຍກົງຕໍ່ Reproducibility.

ເພື່ອເປັນແນວທາງໃນການຕັດສິນໃຈ, ສາມາດອ້າງອີງຈາກເງື່ອນໄຂການແຍກສາຂາ (Conditional branching) ຕໍ່ໄປນີ້:

ການສົ່ງຕໍ່ສະຖານະລະຫວ່າງ Agent ເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກທີ່ສົ່ງຜົນຕໍ່ຄວາມໜ້າເຊື່ອຖືຂອງການອອກແບບ Multi-agent. ວິທີການໃຊ້ໜ່ວຍຄວາມຈຳຮ່ວມ (Shared memory) ແລະ ວິທີການສົ່ງຂໍ້ຄວາມເພື່ອສົ່ງຕໍ່ຂໍ້ມູນຢ່າງຈະແຈ້ງ ແມ່ນສອງທາງເລືອກຫຼັກ ເຊິ່ງແຕ່ລະວິທີກໍມີສະຖານະການທີ່ເໝາະສົມກັບມັນ.

ວິທີການສົ່ງຕໍ່ສະຖານະລະຫວ່າງ Agent ສາມາດແບ່ງອອກເປັນ 2 ປະເພດໃຫຍ່ໆ ຄື: "Shared Memory" ແລະ "Explicit Handoff Message".

Shared Memory ແມ່ນວິທີການຂຽນສະຖານະລົງໃນ External Store (ເຊັ່ນ: Redis ຫຼື Vector DB) ທີ່ Agent ທຸກຕົວສາມາດອ້າງອີງໄດ້. ເນື່ອງຈາກ Agent ທຸກຕົວສາມາດອ່ານບໍລິບົດຫຼ້າສຸດໄດ້ຢ່າງອິດສະຫຼະ, ວິທີນີ້ຈຶ່ງເໝາະສົມກັບໂຄງສ້າງທີ່ຫຼາຍ Agent ເຮັດວຽກພ້ອມກັນແບບ Parallel Worker. ໃນທາງກົງກັນຂ້າມ, ຫາກເວລາໃນການຂຽນຂໍ້ມູນຊ້ຳກັນ ກໍງ່າຍທີ່ຈະເກີດການຂັດແຍ່ງ (Conflict) ແລະ ຫາກບໍ່ມີການຈັດການຢ່າງຊັດເຈນວ່າ Agent ໃດເປັນຜູ້ຖືສະຖານະທີ່ "ຖືກຕ້ອງ", ກໍມີຄວາມສ່ຽງທີ່ຄວາມສອດຄ່ອງຂອງຂໍ້ມູນຈະເສຍໄປ.

Explicit Handoff Message ແມ່ນວິທີທີ່ Agent ຕົວທຳອິດສ້າງຂໍ້ຄວາມທີ່ລວມເອົາຜົນການປະມວນຜົນ ແລະ ຄຳສັ່ງສຳລັບ Agent ຕົວຖັດໄປ ແລ້ວສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Agent ຕົວຕໍ່ໄປ. Handoff ໃນ OpenAI Agents SDK ແມ່ນມີແນວຄິດໃກ້ຄຽງກັບວິທີນີ້, ໂດຍຈະສົ່ງຕໍ່ສະຖານະການສົນທະນາຫຼ້າສຸດໃນເວລາທີ່ເອີ້ນໃຊ້ງານໄປໂດຍກົງ. Agent ທີ່ໄດ້ຮັບຂໍ້ມູນຈະສາມາດເຂົ້າໃຈໄດ້ຢ່າງຊັດເຈນວ່າ "ສິ່ງໃດສຳເລັດແລ້ວ ແລະ ສິ່ງໃດທີ່ຍັງຄ້າງຄາຢູ່", ຈຶ່ງເໝາະສົມກັບ Handoff Type ທີ່ມີການປະມວນຜົນແບບລຳດັບ.

ຫຼັກການພື້ນຖານໃນການນຳໄປໃຊ້ງານຄື: ຫາກ Task ມີຄວາມຂຶ້ນຕໍ່ກັນສູງ ແລະ ມີລຳດັບທີ່ແນ່ນອນ ໃຫ້ໃຊ້ Handoff Message, ແຕ່ຫາກ Agent ເຮັດວຽກຢ່າງເປັນອິດສະຫຼະແບບຂະໜານກັນ ໃຫ້ໃຊ້ Shared Memory.

ໃນການອອກແບບ Handoff Message, ຫາກຈຳກັດຂໍ້ມູນທີ່ຈະສົ່ງຕໍ່ໃຫ້ເຫຼືອພຽງ 3 ອົງປະກອບ ຄື: "ຜົນງານທີ່ສຳເລັດແລ້ວ", "ບັນຫາທີ່ຍັງບໍ່ທັນແກ້ໄຂ" ແລະ "ເງື່ອນໄຂບັງຄັບສຳລັບ Agent ຕົວຖັດໄປ" ຈະຊ່ວຍໃຫ້ Prompt ຂອງຝ່າຍທີ່ຮັບຂໍ້ມູນບໍ່ມີຂະໜາດໃຫຍ່ຈົນເກີນໄປ. ໃນກໍລະນີທີ່ໃຊ້ Shared Memory, ສາມາດຫຼຸດຜ່ອນການຂັດແຍ່ງໄດ້ໂດຍການຈຳກັດສິດໃນການຂຽນຂໍ້ມູນໃຫ້ມີພຽງ Agent ດຽວ ຫຼື ຕັ້ງກົນໄກ Optimistic Locking ໄວ້.

ໃນການພັດທະນາລະບົບ Multi-agent, ເປັນເລື່ອງປົກກະຕິທີ່ເຮົາຈະມາຮູ້ສຶກຕົວໃນພາຍຫຼັງວ່າ "ເປັນຫຍັງຈຶ່ງມອບເຄື່ອງມືເຫຼົ່ານີ້ໃຫ້ກັບ Agent ຕົວນີ້?"

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

ນະໂຍບາຍພື້ນຖານໃນການອອກແບບສິດທິມີດັ່ງນີ້:

ການຈຳກັດການມອບໝາຍເຄື່ອງມືຍັງມີຂໍ້ດີໃນດ້ານຄວາມປອດໄພອີກດ້ວຍ ເພາະຈະເຮັດໃຫ້ Agent ທີ່ຖືກໂຈມຕີດ້ວຍ Prompt Injection ບໍ່ສາມາດດຳເນີນການທີ່ຢູ່ນອກເໜືອສິດທິຂອງຕົນໄດ້. ການນຳຫຼັກການ "Principle of Least Privilege" ມາໃຊ້ໃນການອອກແບບ Agent ຈະຊ່ວຍຈຳກັດຂອບເຂດຄວາມເສຍຫາຍໃຫ້ຢູ່ໃນລະດັບບົດບາດນັ້ນໆ.

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

ເມື່ອມີ Agent ເພີ່ມຂຶ້ນຫຼາຍເທົ່າໃດ, ຂອບເຂດຜົນກະທົບເມື່ອເກີດຄວາມຜິດພາດໃນຈຸດໃດໜຶ່ງກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ການກຳນົດໄວ້ລ່ວງໜ້າວ່າຈະຮອງຮັບຄວາມຜິດພາດບາງສ່ວນໄວ້ທີ່ໃດ ແລະ ຈະອະນຸຍາດໃຫ້ມີການລອງໃໝ່ (Retry) ໄດ້ເຖິງຂັ້ນໃດນັ້ນ, ແມ່ນຈະສົ່ງຜົນໃຫ້ລະບົບໂດຍລວມມີສະຖຽນລະພາບໃນການເຮັດວຽກ.

ໃນລະບົບ Multi-agent, ການຕັດສິນໃຈວ່າ "ຄວນຈະຣີທຣາຍ (Retry) ທັງໝົດ ຫຼື ຄວນຈະຣີທຣາຍສະເພາະເອເຈນນັ້ນ" ຖືເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການອອກແບບ.

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

ມາດຕະຖານໃນການຕັດສິນໃຈແມ່ນອີງໃສ່ 2 ແກນຫຼັກ ຄື: "Idempotency" (ຄວາມເປັນອິດສະຫຼະຂອງຜົນລັອກ) ແລະ "Dependency" (ການເພິ່ງພາອາໄສກັນ).

• ຂັ້ນຕອນທີ່ມີ Idempotency: ເນື່ອງຈາກການໃຫ້ Input ແບບດຽວກັນຈະໄດ້ຜົນລັອກແບບດຽວກັນ, ການຣີທຣາຍແບບດ່ຽວຈຶ່ງມີຄວາມປອດໄພ. ຕົວຢ່າງເຊັ່ນ: ການສອບຖາມ (Query) ຜ່ານ External API ຫຼື ການດຶງຂໍ້ມູນແບບ Static.
• ຂັ້ນຕອນທີ່ມີ Side effect: ການສົ່ງອີເມວ ຫຼື ການຂຽນຂໍ້ມູນລົງໃນຖານຂໍ້ມູນ ເນື່ອງຈາກການປະມວນຜົນຊ້ຳຈະກາຍເປັນບັນຫາ, ຈຶ່ງຈຳເປັນຕ້ອງມີການກວດສອບ Idempotency ເພື່ອຢືນຢັນວ່າ "ໄດ້ດຳເນີນການໄປແລ້ວຫຼືບໍ່" ກ່ອນທີ່ຈະຣີທຣາຍ.
• ຂັ້ນຕອນທີ່ມີການເພິ່ງພາອາໄສກັນໃນລະບົບລຸ່ມ (Downstream dependency): ໃນກໍລະນີທີ່ Output ຂອງເອເຈນໜຶ່ງກາຍເປັນ Input ຂອງເອເຈນຖັດໄປ, ຄວາມຜິດພາດຂອງລະບົບເທິງຈະສົ່ງຜົນໃຫ້ເກີດການຣີທຣາຍທັງໝົດໃນລະບົບລຸ່ມ. ເພື່ອຕັດວົງຈອນນີ້, ການບັນທຶກ Output ລະຫວ່າງທາງໄວ້ເປັນ Checkpoint ຈະມີປະສິດທິຜົນຫຼາຍ.

ກະລຸນາກຳນົດຂີດຈຳກັດຂອງຈຳນວນຄັ້ງໃນການຣີທຣາຍໃຫ້ຊັດເຈນ. ການຣີທຣາຍໂດຍບໍ່ມີຂີດຈຳກັດຈະກາຍເປັນຕົ້ນເຫດຂອງການເກີດ Loop ທີ່ຄວບຄຸມບໍ່ໄດ້ (ຈຸດນີ້ຈະອະທິບາຍຢ່າງລະອຽດໃນພາກຕໍ່ໄປ). ໂດຍທົ່ວໄປແລ້ວ, ສຳລັບບັນຫາເຄືອຂ່າຍຊົ່ວຄາວ, ການຣີທຣາຍປະມານ 3 ຄັ້ງ ພ້ອມກັບ Exponential Backoff ແມ່ນເໝາະສົມ, ສ່ວນຄວາມຜິດພາດທີ່ເກີດຈາກຄຸນນະພາບຂອງ Output ຈາກ Model ຄວນຈັດການເປັນ "Fallback" ໂດຍການທົດລອງຍຸດທະສາດ Prompt ແບບອື່ນຈະເໝາະສົມກວ່າ.

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

ໃນໂຄງສ້າງທີ່ Agent ສາມາດເອີ້ນໃຊ້ເຄື່ອງມືໄດ້ຢ່າງອິດສະຫຼະນັ້ນ, ການເກີດ Loop ຫຼື ການເຮັດວຽກທີ່ຜິດປົກກະຕິ (Runaway) ບໍ່ແມ່ນ "ບັນຫາທີ່ອາດຈະເກີດຂຶ້ນ" ແຕ່ເປັນ "ບັນຫາທີ່ຈະຕ້ອງເກີດຂຶ້ນຢ່າງແນ່ນອນຫາກບໍ່ໄດ້ປ້ອງກັນໄວ້ໃນການອອກແບບ". ເງື່ອນໄຂການຢຸດການເຮັດວຽກ (Stop conditions) ຈະຕ້ອງບໍ່ແມ່ນສິ່ງທີ່ເພີ່ມເຂົ້າມາພາຍຫຼັງ, ແຕ່ຕ້ອງຖືກລວມເຂົ້າໃນຂັ້ນຕອນເລີ່ມຕົ້ນຂອງການອອກແບບ.

ເງື່ອນໄຂການຢຸດການເຮັດວຽກສາມາດແບ່ງອອກເປັນ 3 ປະເພດໃຫຍ່ໆໃນການອອກແບບ:

• ຂີດຈຳກັດຈຳນວນຂັ້ນຕອນ (Step limit): ກຳນົດຂີດຈຳກັດໃຫ້ກັບຈຳນວນຄັ້ງທີ່ Agent ສາມາດເອີ້ນໃຊ້ເຄື່ອງມື ຫຼື ການປະມວນຜົນ LLM. ໃນກໍລະນີທີ່ວຽກງານມີຄວາມງ່າຍດາຍ ໃຫ້ຕັ້ງໄວ້ທີ່ 10-20 ຂັ້ນຕອນ, ແລະສຳລັບວຽກງານປະເພດການຄົ້ນຄວ້າທີ່ຊັບຊ້ອນ ໃຫ້ຕັ້ງໄວ້ທີ່ 50-100 ຂັ້ນຕອນເປັນມາດຕະຖານ, ຫາກເກີນກຳນົດໃຫ້ຢຸດການເຮັດວຽກທັນທີ.
• ຂີດຈຳກັດດ້ານເວລາ (Timeout): ເພື່ອຮອງຮັບກໍລະນີທີ່ຕ້ອງລໍຖ້າການຕອບສະໜອງຈາກ External API ຫຼື ກໍລະນີທີ່ເກີດ Infinite loop. ການຕັ້ງຄ່າ Timeout ສອງຊັ້ນ ຄື: ເວລາລວມຂອງວຽກງານທັງໝົດ (Wall-clock time) ແລະ ເວລາຂອງການເອີ້ນໃຊ້ເຄື່ອງມືແຕ່ລະຄັ້ງ ຈະມີຄວາມປອດໄພກວ່າ.
• ການກວດຈັບການເຮັດວຽກຊ້ຳ (Repetition detection): ຫາກມີການເອີ້ນໃຊ້ເຄື່ອງມືດຽວກັນພ້ອມກັບ Argument ຊຸດດຽວກັນເກີດຂຶ້ນຢ່າງຕໍ່ເນື່ອງ, ນັ້ນຄືສັນຍານທີ່ບົ່ງບອກວ່າ Agent ກຳລັງກັບຄືນສູ່ສະຖານະເດີມ. ໃຫ້ປຽບທຽບປະຫວັດການເຮັດວຽກໃນ N ຂັ້ນຕອນຫຼ້າສຸດ, ຫາກກວດພົບຄວາມຊ້ຳຊ້ອນໃຫ້ຢຸດການເຮັດວຽກທັນທີ.

ການຈັດການຫຼັງຈາກຢຸດການເຮັດວຽກນັ້ນ ໃຫ້ແບ່ງຕາມລັກສະນະຂອງວຽກງານ: ຫາກເປັນຂະບວນການເຮັດວຽກທີ່ຕ້ອງການການກວດສອບຈາກມະນຸດ ໃຫ້ຢຸດການເຮັດວຽກແລ້ວແຈ້ງເຕືອນຜູ້ຮັບຜິດຊອບ, ສ່ວນວຽກງານປະເພດ Asynchronous ເຊັ່ນ Batch processing ໃຫ້ບັນທຶກ Error log ແລ້ວສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Job ຖັດໄປ ເຊິ່ງເປັນວິທີທີ່ເໝາະສົມໃນທາງປະຕິບັດ.

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

ການປ່ຽນຈາກຕົວແທນ (Agent) ດ່ຽວໄປສູ່ລະບົບຫຼາຍຕົວແທນໃນທັນທີ ມັກຈະເຮັດໃຫ້ການດີບັກ (Debug) ມີຄວາມຊັບຊ້ອນ. ວິທີການທີ່ໄດ້ຜົນດີແມ່ນການເລີ່ມຈາກການໃຫ້ຕົວແທນດ່ຽວທີ່ມີຢູ່ເຮັດວຽກໄປກ່ອນ, ຈາກນັ້ນຈຶ່ງຄ່ອຍໆລະບຸບົດບາດທີ່ສາມາດແຍກອອກມາໄດ້ເທື່ອລະຢ່າງ.

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

ເງື່ອນໄຂຂອງບົດບາດທີ່ເໝາະສົມໃນການແຍກອອກມາ ສາມາດພິຈາລະນາໄດ້ຈາກ 3 ຂໍ້ດັ່ງນີ້:

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

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

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

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

Q1. ຕົວແທນຫຼາຍຕົວ (Multi-agent) ດີກວ່າຕົວແທນດຽວ (Single-agent) ສະເໝີໄປບໍ?

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

Q2. ຄວນເລີ່ມຕົ້ນຈາກຮູບແບບ Orchestrator, Handoff, ຫຼື Parallel Worker ດີ?

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

Q3. ຈະປ້ອງກັນບໍ່ໃຫ້ຂໍ້ມູນຕົກຫຼົ່ນໃນຂະນະທີ່ສົ່ງຕໍ່ບໍລິບົດລະຫວ່າງຕົວແທນໄດ້ແນວໃດ?

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

Q4. ມີວິທີປ້ອງກັນບໍ່ໃຫ້ຕົວແທນຕົກຢູ່ໃນວົງຈອນບໍ່ສິ້ນສຸດ (Infinite loop) ບໍ?

ການປ້ອງກັນ Loop ພື້ນຖານແມ່ນການຕັ້ງຄ່າຂີດຈຳກັດຂອງຈຳນວນຂັ້ນຕອນ (ຈຳນວນ Turn ສູງສຸດ) ແລະ ການຕັ້ງຄ່າ Time-out ຕາມເວລາທີ່ຜ່ານໄປ. ນອກຈາກນີ້, ການຕິດຕາມຈຳນວນການເອີ້ນໃຊ້ເຄື່ອງມືດຽວກັນຊ້ຳໆ ແລະ ການໃສ່ລະບົບ Guard ເພື່ອຢຸດການເຮັດວຽກແບບບັງຄັບເມື່ອເກີນຄ່າ Threshold ກໍມີປະສິດທິຜົນ. ເງື່ອນໄຂການຢຸດເຮັດວຽກບໍ່ຄວນປ່ອຍໃຫ້ເປັນການຕັດສິນໃຈຂອງຕົວແທນເອງ, ແຕ່ຄວນອອກແບບໃຫ້ສາມາດຄວບຄຸມຈາກພາຍນອກໂດຍຝັ່ງ Orchestrator ຫຼື ຝັ່ງ Runtime ເພື່ອຈຳກັດຂອບເຂດຜົນກະທົບເມື່ອເກີດການເຮັດວຽກທີ່ຜິດປົກກະຕິ.

Q5. ສາມາດປະຕິບັດງານໂດຍບໍ່ຕ້ອງໃຊ້ Framework ເຊັ່ນ LangChain ຫຼື AutoGen ໄດ້ບໍ?

ການປະຕິບັດງານດ້ວຍຕົນເອງແມ່ນສາມາດເຮັດໄດ້. ຖ້າອອກແບບການສື່ສານລະຫວ່າງຕົວແທນດ້ວຍ Queue ຫຼື Message bus ແລະ ຈັດການສະຖານະດ້ວຍຖານຂໍ້ມູນ ຫຼື Shared store, ກໍສາມາດສ້າງໂຄງສ້າງທີ່ທຽບເທົ່າກັນໄດ້ໂດຍບໍ່ຕ້ອງໃຊ້ Framework. ຢ່າງໃດກໍຕາມ, ຕົ້ນທຶນໃນການພັດທະນາຟັງຊັນທີ່ຈຳເປັນຕໍ່ການດຳເນີນງານດ້ວຍຕົນເອງ ເຊັ່ນ: ການ Retry, Time-out, ແລະ ການເກັບ Log ແມ່ນບໍ່ໜ້ອຍເລີຍ. AutoGen ໄດ້ເປີດຕົວເວີຊັນ 0.4 ໃນເດືອນມັງກອນ 2025 ແລະ ມີການເກັບສະສົມ Star ຫຼາຍກວ່າ 37,000 ໃນ GitHub ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າລະບົບນິເວດ (Ecosystem) ກຳລັງເຕີບໂຕເຕັມທີ່. ຖ້າເປັນການເຮັດ PoC ຂະໜາດນ້ອຍ, ການເລີ່ມຕົ້ນຈາກການພັດທະນາເອງ ແລະ ພິຈາລະນານຳໃຊ້ Framework ໃນຂັ້ນຕອນການນຳໃຊ້ຈິງ (Production) ຖືເປັນທາງເລືອກທີ່ເປັນໄປໄດ້ຫຼາຍທີ່ສຸດ.

ການອອກແບບ Multi AI Agent ຄວນເລີ່ມຕົ້ນດ້ວຍການຕັ້ງຄຳຖາມວ່າ "ເປັນຫຍັງຕ້ອງແບ່ງ" ກ່ອນທີ່ຈະຖາມວ່າ "ຈະແບ່ງແນວໃດ".

ສະຫຼຸບປະເດັນສຳຄັນທີ່ໄດ້ຮວບຮວມໄວ້ໃນບົດຄວາມນີ້ມີດັ່ງນີ້:

• ຂໍ້ຈຳກັດຂອງ Agent ດ່ຽວ: ການຂະຫຍາຍຕົວຂອງ Context length, ຈຳນວນ Tool ທີ່ເພີ່ມຂຶ້ນ ແລະ ຄວາມບໍ່ມີປະສິດທິພາບຂອງຕົ້ນທຶນ Model ແມ່ນແຮງຈູງໃຈຫຼັກໃນການແບ່ງສ່ວນ.
• 3 ຮູບແບບການອອກແບບ: ແບບ Orchestrator ທີ່ມີການຄວບຄຸມເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ, ແບບ Handoff ທີ່ມີການມອບໝາຍຕໍ່ກັນເປັນລຳດັບ, ແລະ ແບບ Parallel Worker ທີ່ມີການປະຕິບັດງານແບບກະຈາຍ. ໃຫ້ເລືອກໂດຍອີງໃສ່ຄວາມສຳພັນຂອງ Task ແລະ ຄວາມຕ້ອງການດ້ານການນຳກັບມາໃຊ້ໃໝ່ (Reproducibility).
• ຫຼັກການໃນການເລືອກຮູບແບບ: ຖ້າ Task ມີຄວາມສຳພັນກັນສູງແລະສາມາດຍອມຮັບ Latency ໄດ້ ໃຫ້ເລືອກແບບ Orchestrator, ຖ້າຂັ້ນຕອນມີການເຊື່ອມຕໍ່ກັນຢ່າງຊັດເຈນ ໃຫ້ເລືອກແບບ Handoff, ແລະ ຖ້າມີ Subtask ທີ່ເປັນອິດສະຫຼະຫຼາຍ ໃຫ້ເລືອກແບບ Parallel Worker.
• ການສົ່ງຕໍ່ສະຖານະ: ໃຫ້ເລືອກໃຊ້ລະຫວ່າງ Shared memory ແລະ ຂໍ້ຄວາມສົ່ງຕໍ່ທີ່ຊັດເຈນ, ພ້ອມທັງກຳນົດຂອບເຂດສິດທິ ແລະ Tool ຂອງ Agent ແຕ່ລະຕົວໃຫ້ຊັດເຈນ.
• ການອອກແບບເມື່ອເກີດຂໍ້ຜິດພາດ: ຕ້ອງກຳນົດຂອບເຂດຂອງການລົ້ມເຫຼວບາງສ່ວນ ແລະ ການ Retry ໄວ້ລ່ວງໜ້າ, ລວມທັງຕ້ອງກຳນົດເງື່ອນໄຂການຢຸດເຮັດວຽກເພື່ອປ້ອງກັນການເກີດ Loop ຫຼື ການເຮັດວຽກທີ່ຄວບຄຸມບໍ່ໄດ້.

ການເລີ່ມຕົ້ນດ້ວຍ Agent ດ່ຽວ ແລະ ຄ່ອຍໆແຍກສ່ວນອອກມາຕາມບົດບາດທີ່ພົບວ່າເປັນຄໍຂວດ (Bottleneck) ແມ່ນວິທີການທີ່ເປັນໄປໄດ້ຫຼາຍທີ່ສຸດ. ການຕັ້ງເປົ້າໝາຍສ້າງໂຄງສ້າງ Multi-agent ທີ່ຊັບຊ້ອນຕັ້ງແຕ່ຕົ້ນ ມັກຈະເຮັດໃຫ້ຕົ້ນທຶນໃນການ Debug ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.