
MCP(Model Context Protocol)ແລະ A2A(Agent-to-Agent Protocol)ແມ່ນໂປຣໂຕຄໍການສື່ສານສຳລັບ AI Agent ເພື່ອເຊື່ອມຕໍ່ກັບເຄື່ອງມືຕ່າງໆ ແລະ Agent ອື່ນໆ.
ໃນລະບົບ Multi-agent ນັ້ນ, Agent ຫຼາຍຕົວຈະແບ່ງໜ້າທີ່ກັນເພື່ອຈັດການກັບວຽກງານທີ່ສັບສົນ. ສຳລັບສິ່ງນີ້, "ພາສາກາງ" ລະຫວ່າງ Agent ຖືວ່າຂາດບໍ່ໄດ້, ແຕ່ຍັງມີແຫຼ່ງຂໍ້ມູນທີ່ອະທິບາຍກົນໄກດັ່ງກ່າວຢ່າງເປັນລະບົບໜ້ອຍຢູ່, ແລະ Engineer ຫຼາຍຄົນຍັງລັງເລໃນການຕັດສິນໃຈໃນຂັ້ນຕອນການອອກແບບ.
ບົດຄວາມນີ້ຈະຈັດລຽງບົດບາດ, Architecture, ແລະເກນການຕັດສິນໃຈໃນການເລືອກໃຊ້ MCP ແລະ A2A ຕາມລຳດັບ. ພວກເຮົາຈະອະທິບາຍພ້ອມກັບໂຄງສ້າງທີ່ເປັນຮູບປະທຳ ສຳລັບ Engineer ທີ່ກຳລັງພິຈາລະນາການອອກແບບລະບົບ Multi-agent, ຫຼືຜູ້ທີ່ຕ້ອງການທຳຄວາມເຂົ້າໃຈພື້ນຖານຂອງການເຊື່ອມຕໍ່ AI Agent.
ຈາກຍຸກທີ່ AI Agent ເຮັດວຽກຢ່າງດຽວດາຍ, ໄດ້ກ້າວຜ່ານໄປສູ່ຍຸກທີ່ຮອງຮັບທັງການເອີ້ນໃຊ້ເຄື່ອງມືແລະການມອບໝາຍວຽກໃຫ້ Agent ອື່ນໆ. "ຂໍ້ຕົກລົງຮ່ວມ" ທີ່ເຮັດໃຫ້ການເຊື່ອມໂຍງທີ່ຊັບຊ້ອນນີ້ເກີດຂຶ້ນໄດ້ ຄືໂປຣໂຕຄໍ AI Agent, ໂດຍຕົວຢ່າງທີ່ເດັ່ນຊັດໄດ້ແກ່ MCP (Model Context Protocol) ແລະ A2A (Agent-to-Agent Protocol).
ໃນອະດີດ, ການນຳໃຊ້ AI ຢ່າງແຜ່ຫຼາຍແມ່ນຮູບແບບ "ການຖາມ-ຕອບກັບໂມເດລດຽວ". ແຕ່ເມື່ອວຽກງານມີຄວາມສັບສົນຫຼາຍຂຶ້ນ, ຈຶ່ງເກີດຄວາມຕ້ອງການໃນການປະມວນຜົນຕໍ່ເນື່ອງທີ່ລວມເອົາການອ່ານໄຟລ໌, ການເອີ້ນໃຊ້ API ພາຍນອກ, ແລະ ການອ້າງອີງການຄົ້ນຫາເຂົ້າດ້ວຍກັນ.
ການທີ່ແຕ່ລະເຄື່ອງມືມີ Interface ເປັນຂອງຕົນເອງ ໄດ້ກໍ່ໃຫ້ເກີດສິ່ງທ້າທາຍດັ່ງຕໍ່ໄປນີ້:
ຍິ່ງໄປກວ່ານັ້ນ, ການທີ່ລະບົບ Multi-agent ທີ່ AI Agent ສາມາດເອີ້ນໃຊ້ເຄື່ອງມືຫຼາຍອັນຢ່າງອັດຕະໂນມັດ ຫຼື ມອບໝາຍວຽກໃຫ້ Agent ອື່ນ ໄດ້ກາຍເປັນທາງເລືອກທີ່ເປັນຈິງ, ຈຶ່ງໄດ້ປ່ຽນແປງມິຕິຂອງບັນຫາໄປ. ບໍ່ແມ່ນພຽງແຕ່ "ຄວາມແຕກຕ່າງໃນວິທີການເອີ້ນໃຊ້ API" ອີກຕໍ່ໄປ, ແຕ່ໄດ້ກາຍເປັນຄວາມຈຳເປັນທີ່ຕ້ອງມີຂໍ້ຕົກລົງໃນລະດັບເລິກກວ່ານັ້ນ ກ່ຽວກັບວິທີທີ່ Agent ແຕ່ລະຕົວແບ່ງປັນຈຸດປະສົງ ແລະ ສະຖານະຂອງວຽກງານລະຫວ່າງກັນ. ຈາກພື້ນຖານດັ່ງກ່າວ, ການເຄື່ອນໄຫວເພື່ອກຳນົດ ມາດຕະຖານ ຫຼື Specification ຮ່ວມກັນຈຶ່ງໄດ້ເລັ່ງໄວຂຶ້ນໃນລະດັບອຸດສາຫະກຳທັງໝົດ.
«ການເອີ້ນໃຊ້ເຄື່ອງມື (Function Calling)» ແລະ «ການສື່ສານລະຫວ່າງ Agent» ມັກຖືກສັບສົນກັນ, ແຕ່ທັງສອງມີບົດບາດທີ່ແຕກຕ່າງກັນໂດຍສິ້ນເຊີງ. ການເລືອກໃຊ້ MCP ແລະ A2A ໃຫ້ຖືກຕ້ອງນັ້ນ, ອີງໃສ່ຄວາມເຂົ້າໃຈໃນຄວາມແຕກຕ່າງນີ້ເປັນພື້ນຖານ.
ການເອີ້ນໃຊ້ເຄື່ອງມື ແມ່ນການດຳເນີນງານທີ່ Agent ຮ້ອງຂໍໃຫ້ຟັງຊັນພາຍນອກປະມວນຜົນໃຫ້. ຕົວຢ່າງທີ່ພົບເຫັນທົ່ວໄປ ໄດ້ແກ່ ການຄົ້ນຫາເວັບ, ການອ້າງອີງຖານຂໍ້ມູນ, ແລະ ການລົງທະບຽນໃນປະຕິທິນ — ໂດຍທີ່ຝ່າຍເຄື່ອງມືຈະບໍ່ຕັດສິນໃຈໃດໆ, ພຽງແຕ່ສົ່ງຄືນຜົນລັບຕາມທີ່ກຳນົດໄວ້ເທົ່ານັ້ນ.
ການສື່ສານລະຫວ່າງ Agent ແມ່ນການຕິດຕໍ່ກັບຄູ່ສົນທະນາທີ່ສາມາດໃຊ້ເຫດຜົນ, ຕັດສິນໃຈ, ແລະ ວາງແຜນໄດ້ເຊັ່ນກັນ. ຈຶ່ງເກີດການໂຕ້ຕອບສອງທາງ ເຊັ່ນ: ການມອບໝາຍວຽກງານ, ການລາຍງານຄວາມຄືບໜ້າ, ແລະ ການໃຫ້ Feedback ລະຫວ່າງທາງ.
ຄວາມແຕກຕ່າງຫຼັກຂອງທັງສອງ ມີດັ່ງນີ້:
ຄວາມແຕກຕ່າງນີ້ ເຊື່ອມໂຍງໂດຍກົງກັບການແບ່ງໜ້າທີ່ຂອງ MCP ແລະ A2A ທີ່ຈະໄດ້ອະທິບາຍໃນພາກຕໍ່ໄປ.

AI Agent ຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງຫຼາຍຂຶ້ນເທົ່າໃດ, ຕົ້ນທຶນໃນການອອກແບບ "ຈຸດເຊື່ອມຕໍ່" ລະຫວ່າງເຄື່ອງມືຕ່າງໆ ກໍ່ຍິ່ງກາຍເປັນສິ່ງທ້າທາຍທີ່ຊັດເຈນຂຶ້ນເທົ່ານັ້ນ. ເຖິງແມ່ນວ່າ Agent ແຕ່ລະໂຕຈະມີປະສິດທິພາບສູງ, ຖ້າກົນໄກການເຊື່ອມໂຍງຍັງຄົງກະຈັດກະຈາຍ, ຜະລິດຕະພາບຂອງລະບົບໂດຍລວມກໍ່ຈະຍັງຄົງຊັກຊ້າ. ນີ້ຄືເຫດຜົນທີ່ການມາດຕະຖານ ຫຼື Specification ໄດ້ຮັບຄວາມສົນໃຈ ແລະ ຖືກໃຫ້ຄວາມສຳຄັນ.
ການນຳໃຊ້ເຄື່ອງມື AI ຫຼາຍຕົວພ້ອມກັນ ຈະເຮັດໃຫ້ຕ້ອງຂຽນ glue code ສະເພາະທຸກຄັ້ງທີ່ມີການເຊື່ອມຕໍ່ກັນ. ສາເຫດມາຈາກການທີ່ແຕ່ລະເຄື່ອງມືມີ API schema, ວິທີການຢືນຢັນຕົວຕົນ, ແລະຮູບແບບຂໍ້ມູນເປັນຂອງຕົນເອງ — ນີ້ຄືສິ່ງທີ່ເອີ້ນວ່າ "ການ silo ຂອງເຄື່ອງມື AI".
ບັນຫາຫຼັກທີ່ເກີດຈາກການ silo ມີ 3 ຂໍ້ ດັ່ງນີ້:
ວິທີ "ການຈັດການສ່ວນຕົວ" ທີ່ຍັງຮັບໄດ້ໃນຍຸກທີ່ໃຊ້ເຄື່ອງມືດຽວ ໄດ້ກາຍເປັນໜີ້ສິນທາງດ້ານເຕັກນິກທີ່ສະສົມຂຶ້ນໃນລະບົບ multi-agent. ການຖົກຖຽງກ່ຽວກັບການສ້າງມາດຕະຖານ ຫຼື Specification ຂອງ protocol ໄດ້ເກີດຂຶ້ນຈາກຄວາມເຈັບປວດໃນພາກສະໜາມດັ່ງກ່າວ.
ເມື່ອ Protocolມາດຕະຖານຖືກກຳນົດຂຶ້ນຢ່າງຄົບຖ້ວນ, ຈະເກີດຜົນປະໂຫຍດທີ່ວ່າ "ການເຊື່ອມຕໍ່ທີ່ສ້າງຂຶ້ນຄັ້ງດຽວສາມາດນຳໃຊ້ຄືນໄດ້ທຸກທີ່". ຄືກັບທີ່ການລວມເປັນໜຶ່ງຂອງມາດຕະຖານ USB ນຳມາເຊິ່ງສະຖານະ "ສຽບແລ້ວໃຊ້ງານໄດ້ທັນທີ", ການປ່ຽນແປງໃນລັກສະນະດຽວກັນກຳລັງດຳເນີນໄປໃນໂລກຂອງ AI Agent ເຊັ່ນກັນ.
ຜົນປະໂຫຍດຫຼັກມີ 3 ຂໍ້ດັ່ງນີ້:
ຢ່າງໃດກໍ່ຕາມ, ເພື່ອໃຫ້ໄດ້ຮັບຜົນປະໂຫຍດຈາກ Interoperability ນັ້ນ, ມີເງື່ອນໄຂທີ່ວ່າ "ຕ້ອງຮັກສາ Implementation ທີ່ສອດຄ່ອງກັບ Protocol ໄວ້ຢ່າງຕໍ່ເນື່ອງ". ຄວນຮັບຮູ້ໄວ້ວ່າ ການຕິດຕາມການອັບເດດເວີຊັນ Specification ແລະ ການຮັບມືດ້ານຄວາມປອດໄພ ຍັງຄົງເປັນສິ່ງທີ່ຕ້ອງດຳເນີນຢ່າງຕໍ່ເນື່ອງແມ້ຫຼັງຈາກການກຳນົດມາດຕະຖານແລ້ວກໍ່ຕາມ.

MCP (Model Context Protocol) ແມ່ນມາດຕະຖານ ຫຼື Specification ການເຊື່ອມຕໍ່ລະຫວ່າງ AI Model ແລະ ເຄື່ອງມືພາຍນອກ ຫຼື ແຫຼ່ງຂໍ້ມູນ ທີ່ Anthropic ໄດ້ປ່ອຍອອກມາເປັນ Open Source. ບົດຄວາມນີ້ຈະອະທິບາຍຕາມລຳດັບຂັ້ນຕອນ ຕັ້ງແຕ່ໂຄງສ້າງຂອງ Architecture ໄປຈົນເຖິງຕົວຢ່າງການເຊື່ອມໂຍງທີ່ໃຊ້ງານຈິງ.
MCP ປະກອບດ້ວຍ 3 ຊັ້ນ ຄື "Host", "Client" ແລະ "Server" ໂດຍມີລັກສະນະການອອກແບບທີ່ແຍກໜ້າທີ່ອອກຈາກກັນຢ່າງຊັດເຈນ.
ສິ່ງສຳຄັນຄື Server ບໍ່ຈຳເປັນຕ້ອງຮູ້ຂໍ້ມູນພາຍໃນຂອງ Host ທີ່ເອີ້ນໃຊ້ງານ. ພຽງແຕ່ສົ່ງຄືນ Response ຕາມມາດຕະຖານ ຫຼື Specification ຂອງ MCP ກໍສາມາດຮອງຮັບການເອີ້ນໃຊ້ງານຈາກ Host ໃດກໍໄດ້.
ຂັ້ນຕອນການສື່ສານດຳເນີນໄປຕາມລຳດັບດັ່ງນີ້: Host ຮັບ Task, Client ສົ່ງຄຳຂໍລາຍການເຄື່ອງມືໄປຍັງ Server, LLM ຕັດສິນໃຈວ່າຈະໃຊ້ເຄື່ອງມືໃດ, Client ສົ່ງຄຳສັ່ງເອີ້ນໃຊ້ງານ ແລະ Server ສົ່ງຜົນລັບຄືນ. ການແລກປ່ຽນ Capability ໃນຕອນເລີ່ມຕົ້ນຊ່ວຍໃຫ້ Host ສາມາດຮັບຮູ້ການຕັ້ງຄ່າເຄື່ອງມືຂອງ Server ທີ່ເຊື່ອມຕໍ່ຢູ່ໄດ້ແບບ Dynamic.
ການເຂົ້າໃຈຂອບເຂດທີ່ MCP ສາມາດຮອງຮັບໄດ້ ຈະຊ່ວຍຫຼຸດຄວາມຄາດເຄື່ອນໃນການອອກແບບໄດ້ຢ່າງມີປະສິດທິພາບ.
ສິ່ງທີ່ MCP ສາມາດເຮັດໄດ້
ສິ່ງທີ່ MCP ບໍ່ສາມາດເຮັດໄດ້
MCP ເປັນ Protocol ທີ່ສະເພາະສຳລັບ "ການສື່ສານແນວຕັ້ງ ຫຼື Vertical" ທີ່ເຊື່ອມຕໍ່ Model ກັບ Tool ແລະ Resource. ມັນບໍ່ຮອງຮັບ "ການສື່ສານແນວນອນ ຫຼື Horizontal" ທີ່ AI Agent ຫຼາຍຕົວມອບໝາຍວຽກໃຫ້ກັນ.
ການຈັດການ Session ແລະ ການຮັກສາສະຖານະຂອງ Long-term Task ກໍ່ບໍ່ແມ່ນໜ້າທີ່ຂອງ MCP ເຊັ່ນກັນ ຈຶ່ງຕ້ອງອອກແບບເພີ່ມເຕີມໃນຝັ່ງ Application ຕ່າງຫາກ. ການກຳນົດຕຳແໜ່ງຂອງ MCP ໃຫ້ເປັນ "ມາດຕະຖານ Interface ສຳລັບການເຊື່ອມຕໍ່ Tool ຫຼື Specification" ຖືວ່າເໝາະສົມທີ່ສຸດ.
Claude Code ແມ່ນ AI Agent ທີ່ເນັ້ນດ້ານການຂຽນໂຄດ ສະໜອງໂດຍ Anthropic. ໂດຍການເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນກັບເຄື່ອງມືພາຍນອກຜ່ານ MCP, ສາມາດເອີ້ນໃຊ້ການອ່ານ-ຂຽນ Filesystem, ການລັນຄຳສັ່ງ Shell, ການຈັດການ Git Repository ແລະອື່ນໆ ໄດ້ໂດຍກົງຈາກ Agent.
ຕົວຢ່າງການເຮັດວຽກຕົວຈິງມີດັ່ງນີ້:
OpenClaw ແມ່ນໜຶ່ງໃນການ Implement ແບບ Open Source ຂອງ MCP, ອອກແບບມາເພື່ອລົດຄວາມຊັບຊ້ອນໃນການສ້າງ ແລະ ຈັດການ MCP Server. ສາມາດ Wrap API Endpoint ທີ່ມີຢູ່ແລ້ວໃຫ້ກາຍເປັນ MCP Tool ແລະ ປ່ຽນໃຫ້ຢູ່ໃນຮູບແບບທີ່ສາມາດເອີ້ນໃຊ້ໄດ້ຈາກ Client ທີ່ຮອງຮັບ ລວມທັງ Claude Code.
ສິ່ງທີ່ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການເຊື່ອມໂຍງທັງສອງຮູບແບບ ຄືຄວາມຖືກຕ້ອງຂອງ Tool Definition. ຫາກຊື່ Tool, Parameter ແລະ ຄຳອະທິບາຍບໍ່ຊັດເຈນ, ກໍ່ມີແນວໂນ້ມທີ່ Agent ຈະດຳເນີນການເອີ້ນໃຊ້ຜິດພາດ. ການຂຽນ Schema ຢ່າງລະອຽດຮອບຄອບ ຈຶ່ງເປັນທາງລັດທີ່ຈະດຶງການເຮັດວຽກອອກມາໄດ້ຕາມທີ່ຕ້ອງການ.

ຖ້າ MCP ແມ່ນການເຊື່ອມຕໍ່ "ແນວຕັ້ງ ຫຼື Vertical" ລະຫວ່າງ AI ແລະ ເຄື່ອງມືຕ່າງໆ, ແລ້ວ A2A (Agent-to-Agent Protocol) ກໍຄືການເຊື່ອມຕໍ່ "ແນວນອນ ຫຼື Horizontal" ລະຫວ່າງ Agent ດ້ວຍກັນເອງ. ພາກສ່ວນຕໍ່ໄປນີ້ຈະອະທິບາຍກົນໄກການມອບໝາຍໜ້າທີ່, ການປະຕິບັດງານ, ແລະ ການລາຍງານຜົນລະຫວ່າງ Framework ທີ່ແຕກຕ່າງກັນ.
A2A(Agent-to-Agent Protocol)ແມ່ນມາດຕະຖານ ຫຼື Specification ແບບເປີດທີ່ Google ສະເໜີຂຶ້ນ ໂດຍມີແນວຄິດພື້ນຖານວ່າ "ສ້າງພາສາກາງທີ່ຊ່ວຍໃຫ້ Agent ສາມາດສື່ສານກັນໄດ້ຢ່າງເທົ່າທຽມ". ໃນຂະນະທີ່ MCP ເຊື່ອມຕໍ່ AI ກັບເຄື່ອງມືຕ່າງໆ, A2A ມີຈຸດເດັ່ນຕ່າງກັນຄືການຈັດການໃຫ້ Agent ເອງເປັນຕົວຫຼັກໃນການສື່ສານ.
ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກຂອງການອອກແບບຄືເມຕາດາຕາຮູບແບບ JSON ທີ່ເອີ້ນວ່າ Agent Card ໂດຍມີຂໍ້ມູນດັ່ງຕໍ່ໄປນີ້:
ຝ່າຍທີ່ເປັນຜູ້ເອີ້ນໃຊ້ຈະດຶງ Agent Card ກ່ອນ, ກວດສອບຄວາມສາມາດຂອງຄູ່ສື່ສານ ແລ້ວຈຶ່ງຕັດສິນໃຈມອບໝາຍວຽກ. ນີ້ຄືຂະບວນການ ຫຼື Pipeline ທີ່ຄ້າຍກັບ "ແລກປ່ຽນນາມບັດແນະນຳຕົວກ່ອນ ແລ້ວຈຶ່ງຂໍໃຫ້ຊ່ວຍເຮັດວຽກ".
ການມອບໝາຍວຽກເລີ່ມຕົ້ນດ້ວຍການສົ່ງ Task Object ຜ່ານ HTTP ແລະ ຫາກການປະມວນຜົນໃຊ້ເວລານານ ກໍຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ແບບ Streaming ຜ່ານ Server-Sent Events ຫຼື WebSocket. ນອກຈາກນີ້ຍັງຮອງຮັບ Multipart Message ທີ່ປະສົມທັງຂໍ້ຄວາມ, ໄຟລ໌ ແລະ ຂໍ້ມູນທີ່ມີໂຄງສ້າງໄດ້ອີກດ້ວຍ.
ເນື່ອງຈາກມາດຕະຖານ ຫຼື Specification ນີ້ຍັງໃໝ່ຢູ່, ຈຶ່ງແນະນຳໃຫ້ກວດສອບຄວາມຄືບໜ້າການອັບເດດລ່າສຸດໃນເອກະສານທາງການກ່ອນນຳໄປໃຊ້ງານ.
ການຈັດການ Agent Orchestration ແມ່ນກົນໄກທີ່ມອບໝາຍ Sub-task ໃຫ້ກັບ AI Agent ຫຼາຍໂຕ, ແລ້ວລວມຜົນລັບທີ່ໄດ້ເຂົ້າກັນເພື່ອບັນລຸເປົ້າໝາຍລວມ. A2A ເຮັດໜ້າທີ່ກຳນົດມາດຕະຖານໃຫ້ກັບຂັ້ນຕອນ "ການມອບໝາຍ ແລະ ການຕອບສະໜອງ" ນີ້.
ໜ້າທີ່ຫຼັກທີ່ A2A ຮັບຜິດຊອບໃນ Orchestration ມີດັ່ງນີ້:
submitted → working → completedຈຸດແຂງທີ່ໂດດເດັ່ນຄື Agent ແຕ່ລະໂຕບໍ່ຈຳເປັນຕ້ອງຮູ້ການ Implementation ພາຍໃນຂອງກັນ ແລະ ກັນ, ຈຶ່ງສາມາດເຊື່ອມໂຍງ Agent ທີ່ສ້າງດ້ວຍ Framework ຫຼື ພາສາທີ່ແຕກຕ່າງກັນໄດ້.
ໃນທາງກົງກັນຂ້າມ, ຫາກ Task ມີຄວາມລະອຽດຫຍາບຫຼາຍເກີນໄປ, Overhead ຂອງການມອບໝາຍຈະສະສົມຂຶ້ນ ແລະ ມີແນວໂນ້ມທຳໃຫ້ການປະມວນຜົນຊ້າລົງ. ການອອກແບບຂອບເຂດວ່າ Agent ໜຶ່ງໂຕຈະຮັບຜິດຊອບໄດ້ຫຼາຍສໍ່າໃດ ແລະ ຈຸດໃດຄວນເລີ່ມມອບໝາຍຕໍ່, ຈະເປັນຕົວກຳນົດທັງ Performance ແລະ ຄວາມສາມາດໃນການບຳລຸງຮັກສາລະບົບ.

MCP ແລະ A2A ມີ "ລະດັບຄວາມລະອຽດຂອງການສື່ສານ" ທີ່ແຕກຕ່າງກັນຢ່າງພື້ນຖານ. ການຕັດສິນໃຈດ້ານການອອກແບບວ່າຈະເອີ້ນໃຊ້ເຄື່ອງມື (Tool) ຫຼື ມອບໝາຍວຽກງານໃຫ້ Agent ນັ້ນ ຈະເປັນຈຸດແບ່ງແຍກວ່າຄວນເລືອກໃຊ້ອັນໃດ.
ຈຸດເລີ່ມຕົ້ນຂອງການຕັດສິນໃຈຄືການພິຈາລະນາວ່າ "ຜູ້ດຳເນີນການປ່ຽນໄປຫຼືບໍ່".
ກໍລະນີທີ່ຄວນເລືອກ MCP:
ກໍລະນີທີ່ຄວນເລືອກ A2A:
ທັງສອງຢ່າງບໍ່ໄດ້ຂັດແຍ່ງກັນ. ໂຄງສ້າງລຳດັບຊັ້ນທີ່ Sub-agent ທີ່ຮັບການມອບໝາຍຜ່ານ A2A ໃຊ້ MCP ເພື່ອເອີ້ນໃຊ້ Tool ສຳລັບການດຳເນີນ Task ຂອງຕົນເອງ ແມ່ນເກີດຂຶ້ນໄດ້ຢ່າງເປັນທຳມະຊາດ. ແນວຄິດທີ່ວ່າ "ແບ່ງໜ້າທີ່ດ້ວຍ A2A ແລ້ວເສີມຄວາມສາມາດດ້ວຍ MCP" ຊ່ວຍໃຫ້ເຫັນພາບລວມຂອງການອອກແບບໄດ້ຊັດເຈນຂຶ້ນ.
ພວກເຮົາຈະຈັດລຽງຮູບແບບການອອກແບບທີ່ເປັນຕົວແທນຂອງລະບົບ Multi-agent ແລະ ຄວາມສຳພັນລະຫວ່າງ MCP ແລະ A2A.
ແບບ Orchestrator / Worker ເປັນໂຄງສ້າງທີ່ Agent ກາງຈັດສັນວຽກໃຫ້ Worker ຫຼາຍຕົວ. ໂຄງສ້າງສອງຊັ້ນທີ່ໃຊ້ A2A ສຳລັບການສັ່ງງານຈາກ Orchestrator ໄປຫາ Worker ແລະ ໃຊ້ MCP ເມື່ອ Worker ແຕ່ລະຕົວເຂົ້າໃຊ້ເຄື່ອງມືພາຍນອກ ນັ້ນເຂົ້າກັນໄດ້ດີຢ່າງເປັນທຳມະຊາດ. ມີແນວໂນ້ມທີ່ຈະແຍກໜ້າທີ່ຮັບຜິດຊອບໄດ້ຢ່າງຊັດເຈນ ແລະ ງ່າຍຕໍ່ການໃຊ້ເປັນຈຸດເລີ່ມຕົ້ນໃນການນຳໃຊ້.
ແບບ ຂະບວນການ ຫຼື Pipeline ໃຊ້ A2A ສຳລັບການສົ່ງຕໍ່ລະຫວ່າງ Agent ໃນຂະນະທີ່ MCP ເສີມການເຂົ້າເຖິງຂໍ້ມູນພາຍນອກໃນແຕ່ລະຂັ້ນຕອນ. ຫາກການປະມວນຜົນເປັນພຽງການປ່ຽນແປງຂໍ້ມູນທີ່ງ່າຍດາຍ ກໍ່ອາດມີກໍລະນີທີ່ MCP ພຽງຢ່າງດຽວສາມາດຮອງຮັບໄດ້ຄົບຖ້ວນ.
ແບບ Flat Collaboration ເປັນຮູບແບບທີ່ສອດຄ່ອງກັບແນວຄິດການອອກແບບຂອງ A2A ຫຼາຍທີ່ສຸດ. Agent ທີ່ເທົ່າທຽມກັນຈະອ້າງອີງ Agent Card ໃນຂະນະທີ່ມອບໝາຍວຽກໃຫ້ກັນແລະກັນຢ່າງເໝາະສົມ ໂດຍ MCP ຮັບຜິດຊອບການເຂົ້າເຖິງເຄື່ອງມືສ່ວນຕົວ. ມີຄວາມຍືດຫຍຸ່ນສູງ ແຕ່ໃນທາງກົງກັນຂ້າມ ຕ້ອງລະວັງໃນຈຸດທີ່ຕິດຕາມໄດ້ຍາກວ່າ Agent ໃດເປັນຜູ້ຕັດສິນໃຈໃດ.

ໃນການນຳ MCP ແລະ A2A ມາໃຊ້ງານຕົວຈິງ, ການອອກແບບດ້ານຄວາມປອດໄພແມ່ນມີຄວາມຈຳເປັນເທົ່າທຽມກັນກັບການອອກແບບດ້ານຟັງຊັນ. ເສັ້ນທາງການເອີ້ນໃຊ້ເຄື່ອງມືພາຍນອກ ແລະ ການມອບໝາຍວຽກງານລະຫວ່າງ Agent ນັ້ນ ອາດກາຍເປັນ Attack Surface ໄດ້ໂດຍກົງ, ດັ່ງນັ້ນຈຶ່ງຕ້ອງມີມາດຕະການທີ່ເໝາະສົມ.
ໃນການເຊື່ອມຕໍ່ພາຍນອກຜ່ານ MCP ແລະ A2A, Prompt Injection ຖືເປັນໄພຂົ່ມຂູ່ທີ່ເກີດຂຶ້ນໄດ້ຈິງ. ນີ້ແມ່ນວິທີການໂຈມຕີທີ່ຂໍ້ຄວາມທີ່ເປັນອັນຕະລາຍຊ່ອນຕົວຢູ່ໃນຜົນລັບຂອງເຄື່ອງມື ແລ້ວດັດແກ້ພຶດຕິກຳຂອງ LLM, ໂດຍໃນໂຄງສ້າງ Multi-agent ນັ້ນ ຕ້ອງລະວັງໂດຍສະເພາະວ່າ ຜົນລັບທີ່ຖືກປົນເປື້ອນສາມາດສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Agent ຕໍ່ໄປໄດ້ຢ່າງຕໍ່ເນື່ອງ.
ພື້ນຖານຂອງການຮັບມືຄືການອອກແບບ AI Guardrails ເປັນສອງຊັ້ນທາງດ້ານ Input ແລະ Output.
ນອກຈາກນີ້, ຫຼັກການສິດທິ໌ຂັ້ນຕ່ຳສຸດ (Principle of Least Privilege) ກໍ່ມີຄວາມສຳຄັນເຊັ່ນກັນ. ການບໍ່ມອບສິດທິ໌ຂຽນໃຫ້ກັບ Task ທີ່ອ່ານຢ່າງດຽວ, ລວມທັງການຈຳກັດລະດັບສິດທິ໌ຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບ Scope ຂອງ MCP Server ແລະ ການກຳນົດ Agent Skills, ຈະຊ່ວຍເພີ່ມປະສິດທິຜົນຂອງ Guardrails ໄດ້.
ໃນສະພາບແວດລ້ອມ Multi-agent, ການອອກແບບລະບົບການຢືນຢັນຕົວຕົນ ແລະ ການອະນຸຍາດ ມັກຈະຖືກເລື່ອນໄປເຮັດທີຫຼັງ. ຢ່າງໃດກໍຕາມ, ຫາກປ່ອຍໃຫ້ "ໃຜ · ເຂົ້າເຖິງຊັບພະຍາກອນໃດ · ດ້ວຍສິດທິ໌ຫຍັງ" ຍັງບໍ່ຊັດເຈນ, ກໍຈະມີຄວາມສ່ຽງທີ່ຈະເກີດການຍົກລະດັບສິດທິ໌ ຫຼື ການເອີ້ນໃຊ້ເຄື່ອງມືໂດຍບໍ່ໄດ້ຕັ້ງໃຈ.
ໃນ A2A Specification, ການໃຊ້ OIDC Token ຖືກວາງແຜນໄວ້ເປັນວິທີການຢືນຢັນຕົວຕົນລະຫວ່າງ Agent. ເມື່ອ Orchestrator ມອບໝາຍ Task ໃຫ້ Sub-agent, ການຕິດ JWT-based Token ໄວ້ໃນ Request Header ຈະຊ່ວຍໃຫ້ຝ່າຍຮັບສາມາດກວດສອບຄວາມຖືກຕ້ອງຂອງຜູ້ເອີ້ນໄດ້. ວິທີການດຽວກັນນີ້ກໍໃຊ້ໄດ້ຜົນດີສຳລັບການຄວບຄຸມການເຂົ້າເຖິງ MCP Server ເຊັ່ນກັນ.
ຈຸດທີ່ມັກຖືກມອງຂ້າມໃນຂັ້ນຕອນການ Implement ມີ 3 ຂໍ້ ດັ່ງນີ້:
ຫາກວາງແຜນການອອກແບບສິດທິ໌ແບບ Role-based ໃຫ້ຊັດເຈນຕັ້ງແຕ່ຕົ້ນ, ກໍຈະຊ່ວຍຫຼຸດຜ່ອນການຍ້ອນກັບໄປແກ້ໄຂໃນພາຍຫຼັງໄດ້ຢ່າງຫຼວງຫຼາຍ.

ໃນຂະນະທີ່ຄວາມສົນໃຈໃນ MCP ແລະ A2A ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ, ກໍຍັງມີຄວາມເຂົ້າໃຈຜິດທີ່ຫ່າງໄກຈາກຄວາມເປັນຈິງປາກົດໃຫ້ເຫັນໃນພາກສະໜາມ. ຂໍ້ເຂົ້າໃຈຜິດທົ່ວໄປ 2 ຂໍ້ທີ່ໄດ້ຍິນເລື້ອຍໆ, ຂໍຈັດລະບຽບໃຫ້ຊັດເຈນໃນທີ່ນີ້.
MCP ບໍ່ແມ່ນ "ການທົດແທນ" REST API ຫຼື GraphQL ແຕ່ຢ່າງໃດ ເພາະບົດບາດຂອງມັນແຕກຕ່າງກັນໂດຍພື້ນຖານ.
API ທີ່ມີຢູ່ແລ້ວແມ່ນ Interface ທົ່ວໄປທີ່ຮັບຜິດຊອບການແລກປ່ຽນຂໍ້ມູນລະຫວ່າງແອັບພລິເຄຊັນ. ສ່ວນ MCP ນັ້ນ ໄດ້ຖືກອອກແບບມາໂດຍສະເພາະເພື່ອອະທິບາຍ ແລະ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ AI Agent ໃນຮູບແບບທີ່ LLM ສາມາດຕີຄວາມໄດ້ວ່າ "ສາມາດໃຊ້ເຄື່ອງມືໃດໄດ້ແດ່" ແລະ "ວິທີການເອີ້ນໃຊ້ແນວໃດ".
ເມື່ອຈັດລຽງຄວາມສຳພັນໃນດ້ານການ Implementation ແລ້ວ ຈະໄດ້ດັ່ງນີ້:
ຍົກຕົວຢ່າງ ໃນກໍລະນີທີ່ນຳໃຊ້ GitHub API ນັ້ນ ວຽກຫຼັກບໍ່ແມ່ນການຂຽນ API ໃໝ່ທັງໝົດ ແຕ່ແມ່ນການຂຽນ Tool Definition ສຳລັບການດຳເນີນການຕ່າງໆ ເຊັ່ນ "ຄົ້ນຫາ Repository" ຫຼື "ສ້າງ PR" ໃໝ່ໃຫ້ຢູ່ໃນຮູບແບບທີ່ Agent ສາມາດຕີຄວາມໄດ້ງ່າຍຂຶ້ນ.
ຫາກປ່ອຍໃຫ້ຄວາມເຂົ້າໃຈຜິດນີ້ຄົງຢູ່ ກໍ່ມີແນວໂນ້ມທີ່ຈະເກີດຄ່າໃຊ້ຈ່າຍທີ່ສິ້ນເປືອງຈາກການຈັດການ MCP ແລະ API ແຍກກັນສອງສ່ວນ. ການກຳນົດໃຫ້ MCP ເປັນຊັ້ນ ອາແດັບເຕີ ຫຼື ສ່ວນເສີມ ທີ່ເສີມ API ນັ້ນ ຖືເປັນວິທີການ Deployment ທີ່ສົມເຫດສົມຜົນໃນທາງປະຕິບັດ.
«A2A ແມ່ນ Specification ທີ່ຜູກຕິດກັບ LLM ຫຼື Framework ສະເພາະໃດໜຶ່ງ» ແມ່ນຄວາມເຂົ້າໃຈຜິດທີ່ພົບເຫັນໄດ້ທົ່ວໄປ.
A2A ໃຊ້ການອອກແບບທີ່ການສື່ສານສຳເລັດດ້ວຍ JSON Message ບົນພື້ນຖານ HTTP ໂດຍບໍ່ຂຶ້ນກັບປະເພດຂອງ LLM ທີ່ເຮັດວຽກຢູ່ພາຍໃນ. ຈຸດສຳຄັນຫຼັກໆ ມີດັ່ງນີ້:
ຢ່າງໃດກໍ່ຕາມ «ບໍ່ຂຶ້ນກັບ Model» ກັບ «ເຮັດວຽກໄດ້ທັນທີໃນທຸກສະພາບແວດລ້ອມ» ແມ່ນສອງສິ່ງທີ່ແຕກຕ່າງກັນ. ຄວາມສຳເລັດ ຫຼື ຄວາມລົ້ມເຫຼວຂອງການມອບໝາຍ Task ຂຶ້ນຢູ່ກັບຄວາມຖືກຕ້ອງຂອງການອະທິບາຍໃນ Agent Card ແລະຄຸນນະພາບຂອງການ Implement ຂອງ Agent ແຕ່ລະຕົວ. Protocol ສະໜອງພາສາກາງໃຫ້, ແຕ່ການນຳໃຊ້ຢ່າງຖືກຕ້ອງນັ້ນແມ່ນຄວາມຮັບຜິດຊອບຂອງຝ່າຍ Implement.

ເມື່ອເຂົ້າໃຈແນວຄິດຂອງ MCP ແລ້ວ, ການລົງມືປະຕິບັດຕົວຈິງຄືທາງລັດທີ່ດີທີ່ສຸດໃນການເຂົ້າໃຈຢ່າງເລິກເຊິ່ງ. ພວກເຮົາຈະອະທິບາຍຂັ້ນຕອນການເປີດໃຊ້ງານ Server ໃນສະພາບແວດລ້ອມ Local ແລະ ວິທີການກຳນົດ ແລະ ທົດສອບ Agent Skills ຕາມລຳດັບ.
ຖ້າຕ້ອງການທົດລອງ MCP ໃນເຄື່ອງ Local, ການຕັ້ງຄ່າຂັ້ນຕ່ຳໂດຍໃຊ້ Python SDK ຖືວ່າເປັນຈຸດເລີ່ມຕົ້ນທີ່ເໝາະສົມ.
ຂັ້ນຕອນຈົນເຖິງການເປີດໃຊ້ງານ
pip install mcp@mcp.tool() ໄວ້, ຈະຖືກລົງທະບຽນເປັນ Tool ໂດຍອັດຕະໂນມັດpython server.py. Transport ເລີ່ມຕົ້ນຄື stdio (Standard Input/Output)ເຄັດລັບການກວດສອບການທຳງານ
ຫຼັງຈາກເປີດໃຊ້ງານແລ້ວ, ຖ້າໃຊ້ CLI Tool ທາງການຢ່າງ MCP Inspector ຈະສາມາດກວດສອບລາຍການ Tool ແລະ ເອີ້ນໃຊ້ດ້ວຍຕົນເອງຜ່ານ Browser ໄດ້. ນີ້ມີປະສິດທິພາບໃນການແຍກແຍະບັນຫາເບື້ອງຕົ້ນ ເຊັ່ນ "ການຕັ້ງຄ່ານ່າຈະຖືກຕ້ອງແລ້ວ ແຕ່ບໍ່ມີການຕອບສະໜອງ".
ການເຊື່ອມຕໍ່ກັບ Host App
ສຳລັບການເຊື່ອມຕໍ່ກັບ Host App ເຊັ່ນ Claude Desktop, ພຽງແຕ່ຂຽນຄຳສັ່ງເປີດໃຊ້ງານ ແລະ Path ລົງໃນ Configuration File ກໍ່ຈະຖືກຮັບຮູ້ໄດ້. ວິທີທີ່ເໝາະສົມໃນທາງປະຕິບັດ ຈາກມຸມມອງຂອງການລະບຸບັນຫາໄດ້ງ່າຍ ຄື ກວດສອບການເຊື່ອມຕໍ່ດ້ວຍ stdio ກ່ອນ, ຈາກນັ້ນຈຶ່ງຍ້າຍໄປໃຊ້ວິທີ HTTP+SSE ຕາມຄວາມຈຳເປັນ.
ເມື່ອ MCP Server ເລີ່ມຕົ້ນແລ້ວ, ໃຫ້ດຳເນີນການກຳນົດ Agent Skills ຕໍ່ໄປ. Skills ແມ່ນໜ່ວຍຂອງຟັງຊັນທີ່ Agent ສາມາດເອີ້ນໃຊ້ຈາກພາຍນອກໄດ້, ໂດຍປະກອບດ້ວຍ 3 ອົງປະກອບດັ່ງນີ້:
ຫາກຂຽນຄຳອະທິບາຍໃຫ້ຄອບຄຸມທັງ "ສາມາດເຮັດຫຍັງໄດ້" ແລະ "ຄວນໃຊ້ໃນສະຖານະການໃດ", ຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງໃນການເລືອກຂອງ Orchestrator ໄດ້. ຫາກຄຳອະທິບາຍຍັງບໍ່ຊັດເຈນ, ມີແນວໂນ້ມທີ່ຈະເຮັດໃຫ້ເກີດການເລືອກ Task ທີ່ຜິດພາດໄດ້.
ການທົດສອບຈະຈັດລະບຽບໄດ້ງ່າຍຂຶ້ນ ຫາກດຳເນີນການເປັນ 2 ຂັ້ນຕອນ:
curl ຫຼື httpx ຂອງ Python, ແລ້ວກວດສອບປະເພດຂອງ Response ແລະການຈັດການ Errorເມື່ອຈຳນວນ Skills ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ, ການກວດທານຄຳອະທິບາຍເປັນໄລຍະໆວ່າຄ້າຍຄືກັນເກີນໄປຫຼືບໍ່ ກໍ່ເປັນສິ່ງສຳຄັນເຊັ່ນກັນ. ຄຳອະທິບາຍທີ່ຄ້າຍຄືກັນຈະກາຍເປັນຕົ້ນເຫດຂອງການເລືອກຜິດພາດໄດ້.

MCP ແລະ A2A ໃນລະຫວ່າງການຮຽນຮູ້, ຄຳຖາມທີ່ວ່າ "ແຕກຕ່າງຈາກກົນໄກທີ່ມີຢູ່ແລ້ວແນວໃດ?" ເປັນສິ່ງທີ່ເກີດຂຶ້ນຕາມທຳມະຊາດ. ຂໍສະຫຼຸບໂດຍສຸມໃສ່ 2 ຄຳຖາມທີ່ມັກຖືກຍົກຂຶ້ນໃນການປະຕິບັດງານຈິງ.
ການເອີ້ນໃຊ້ເຄື່ອງມື (Function Calling) ແມ່ນກົນໄກທີ່ LLM ສ້າງຜົນລັບໃນຮູບແບບ JSON ເພື່ອສະແດງເຈດຕະນາວ່າ "ຕ້ອງການໃຫ້ດຳເນີນການຟັງຊັນນີ້" ແລ້ວຝ່າຍແອັບພລິເຄຊັນຈະເປັນຜູ້ຈັດການຕໍ່. ເນື່ອງຈາກແຕ່ລະ LLM Provider ຈະ Implement ດ້ວຍຕົນເອງ, ດັ່ງນັ້ນ ມາດຕະຖານ ຫຼື Specification ຂອງການກຳນົດ Schema ແລະ ການຈັດການຂໍ້ຜິດພາດຈຶ່ງແຕກຕ່າງກັນໄປຕາມແຕ່ລະ Provider.
ຄວາມແຕກຕ່າງຫຼັກລະຫວ່າງ MCP ສາມາດສະຫຼຸບໄດ້ເປັນ 3 ຂໍ້ດັ່ງນີ້:
ທັງສອງບໍ່ໄດ້ຂັດແຍ່ງກັນ. ມີຫຼາຍກໍລະນີທີ່ MCP Host ໃຊ້ Function Calling ພາຍໃນເພື່ອສ້າງການເອີ້ນໃຊ້ໄປຫາ MCP Server, ດັ່ງນັ້ນໃນຄວາມເປັນຈິງແລ້ວທັງສອງຈຶ່ງມີຄວາມສຳພັນທີ່ເສີມເຕີມກັນ. ຖ້າຈະອະທິບາຍໃຫ້ເຂົ້າໃຈງ່າຍ: Function Calling ຄື "ວິທີທີ່ LLM ບອກວ່າຈະເອີ້ນໃຊ້ຫຍັງ", ສ່ວນ MCP ຄື "ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ເປັນມາດຕະຖານກາງສຳລັບການສະໜອງ ແລະ ຈັດການເຄື່ອງມື".
ການຕັດສິນໃຈທີ່ເໝາະສົມຄວນອີງໃສ່ "ຕ້ອງການໃຫ້ເຮັດຫຍັງ" ຫຼາຍກວ່າຂະໜາດຂອງທີມ. A2A ຈະສະແດງສັກກະຍະພາບຢ່າງເຕັມທີ່ກໍ່ຕໍ່ເມື່ອ Agent ຜູ້ຊ່ຽວຊານຫຼາຍຕົວທຳງານແບບຂະໜານ ຫຼື ຕໍ່ເນື່ອງກັນເທົ່ານັ້ນ.
ກໍລະນີທີ່ຄວນພິຈາລະນາໃຊ້ A2A
ກໍລະນີທີ່ MCP ພຽງພໍ
ການນຳ A2A ມາໃຊ້ມີແນວໂນ້ມເຮັດໃຫ້ຄວາມຊັບຊ້ອນໃນການດຳເນີນງານເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ທັງໃນດ້ານການກຳນົດ Agent Skills ແລະ ການຈັດການສະຖານະຂອງ Task. ມີລາຍງານວ່າສຳລັບທີມຂະໜາດນ້ອຍ ຄ່າໃຊ້ຈ່າຍໃນການບຳລຸງຮັກສາອາດບໍ່ຄຸ້ມຄ່າ. ຫາກຕອບ "ແມ່ນ" ຕໍ່ຫຼັກການຕັດສິນໃຈຂ້າງເທິງໃນຂໍ້ໃດຂໍ້ໜຶ່ງ ກໍ່ຄວນພິຈາລະນາອອກແບບໄວ້, ຖ້າບໍ່ດັ່ງນັ້ນ ການໃຫ້ຄວາມສຳຄັນກັບຄວາມໝັ້ນຄົງຂອງສະພາບແວດລ້ອມ MCP ກ່ອນ ແລ້ວຄ່ອຍເກັບ A2A ໄວ້ເປັນທາງເລືອກສຳລັບການຂະຫຍາຍໃນອະນາຄົດ ຖືວ່າເປັນການເລືອກທີ່ສົມເຫດສົມຜົນໃນທາງປະຕິບັດ.

ສະຫຼຸບເນື້ອຫາທີ່ຜ່ານມາເປັນ 3 ຈຸດສຳຄັນ.
ຈຸດສຳຄັນທີ 1: MCP ຄື "ພາສາກາງສຳລັບເຊື່ອມຕໍ່ Agent ກັບ Tool"
ສິ່ງທີ່ MCP ແກ້ໄຂຄືຕົ້ນທຶນການເຊື່ອມຕໍ່ເມື່ອ AI Agent ເອີ້ນໃຊ້ເຄື່ອງມືພາຍນອກ ຫຼື ແຫຼ່ງຂໍ້ມູນ. ເມື່ອ Implement MCP Server ຄັ້ງດຽວ, ກໍ່ສາມາດນຳ Tool ນັ້ນກັບມາໃຊ້ຊ້ຳໄດ້ຈາກທຸກ Agent ທີ່ຮອງຮັບ.
ຈຸດສຳຄັນທີ 2: A2A ຄື "ວິທີການປະສານງານລະຫວ່າງ Agent ດ້ວຍກັນ"
ຖ້າ MCP ຮັບຜິດຊອບການເຊື່ອມຕໍ່ແນວຕັ້ງ ຫຼື Vertical ໃນການເອີ້ນໃຊ້ Tool, A2A ກໍ່ຊ່ວຍໃຫ້ການເຊື່ອມຕໍ່ແນວນອນ ຫຼື Horizontal ລະຫວ່າງ Agent ເປັນໄປໄດ້. ແນວຄິດໃນການອອກແບບທີ່ບໍ່ຜູກຕິດກັບ LLM ສະເພາະໃດໜຶ່ງ ຫຼື ສະພາບແວດລ້ອມການ Execute ສະໜັບສະໜູນການ Scale Up ທີ່ຍືດຫຍຸ່ນຂອງລະບົບ Multi-Agent.
ຈຸດສຳຄັນທີ 3: ຄວາມປອດໄພ ແລະ ການອອກແບບລະບົບ ບໍ່ສາມາດຖ້າໄວ້ທີຫຼັງໄດ້
ຍິ່ງນຳ Protocol ເຂົ້າມາໃຊ້ຫຼາຍ, ພື້ນທີ່ໂຈມຕີຂອງລະບົບກໍ່ຍິ່ງຂະຫຍາຍກວ້າງຂຶ້ນ. ການຄວບຄຸມການເຂົ້າເຖິງດ້ວຍ OIDC Token ແລະ ການຕັ້ງຄ່າ AI Guardrail ແມ່ນສິ່ງທີ່ຄວນພິຈາລະນາໃນລະດັບດຽວກັນ ຫຼື ກ່ອນໜ້າ Performance Tuning.
ມາດຕະຖານ ຫຼື Specification ຍັງຢູ່ໃນຂັ້ນຕອນການພັດທະນາຕໍ່ໄປ. ການລອງ Run MCP Server ໜຶ່ງຕົວໃນສະພາບແວດລ້ອມ Local ກ່ອນ ຖືເປັນທາງລັດທີ່ດີທີ່ສຸດໃນການປ່ຽນແນວຄິດທີ່ເປັນ Abstract ໃຫ້ກາຍເປັນຄວາມເຂົ້າໃຈທີ່ຊັດເຈນ.

Yusuke Ishihara
ເລີ່ມຂຽນໂປຣແກຣມຕັ້ງແຕ່ອາຍຸ 13 ປີ ດ້ວຍ MSX. ຫຼັງຈົບການສຶກສາຈາກມະຫາວິທະຍາໄລ Musashi, ໄດ້ເຮັດວຽກໃນການພັດທະນາລະບົບຂະໜາດໃຫຍ່ ລວມທັງລະບົບຫຼັກຂອງສາຍການບິນ ແລະ ໂຄງສ້າງ Windows Server Hosting/VPS ທຳອິດຂອງຍີ່ປຸ່ນ. ຮ່ວມກໍ່ຕັ້ງ Site Engine Inc. ໃນປີ 2008. ກໍ່ຕັ້ງ Unimon Inc. ໃນປີ 2010 ແລະ Enison Inc. ໃນປີ 2025, ນຳພາການພັດທະນາລະບົບທຸລະກິດ, NLP ແລະ ແພລດຟອມ. ປັດຈຸບັນສຸມໃສ່ການພັດທະນາຜະลິດຕະພັນ ແລະ ການສົ່ງເສີມ AI/DX ໂດຍນຳໃຊ້ generative AI ແລະ LLM.