คู่มือของสถาปนิกเกี่ยวกับการทำงานร่วมกันระหว่างระบบ Agentforce

เรียบเรียงโดย: ทีม Agentforce ผลิตภัณฑ์ (Pragya Anand , Moe Basi , Shiv Ramanna , Kyle Bransky )

อ่านต่อเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการกำหนดแนวทางการทำงานร่วมกันระหว่างระบบของคุณ
จากนั้นดาวน์โหลดส่วนที่ 2 เพื่อใช้เป็นคู่มืออ้างอิงขณะสร้างระบบของคุณ

ก่อนการออกแบบ ระบบตัวแทนหลายตัว สิ่งสำคัญคือต้องทำความเข้าใจว่าตัวแทนเดี่ยวทำงานอย่างไร ตัวแทน Agentforce ประกอบด้วย ตัวแทนย่อย ซึ่งเดิมเรียกว่า Topics โดยเป็นองค์ประกอบแบบโมดูลาร์ที่กำหนดขอบเขตสำหรับโดเมนเฉพาะ แต่ละองค์ประกอบมีการดำเนินการที่กำหนดไว้ เช่น โฟลว์, Apex และพร้อมท์

ตัวแทน Agentforce แต่ละตัวทำงานด้วยลูปการให้เหตุผลของ LLM ของตนเอง โดยประสานการมอบหมายงานระหว่างตัวแทนย่อยและการจัดทำคำตอบจนกว่าจะบรรลุเป้าหมาย กลไกการประมวลผลโดยการใช้ตรรกะและกฎเกณฑ์ ของ Agentforce ขยายลูปนี้ด้วยความแน่นอนตาม สคริปต์ของตัวแทน โดยเพิ่มการเปลี่ยนผ่านและลำดับขั้นที่ชัดเจนระหว่างตัวแทนย่อยเพื่อให้มั่นใจว่าการทำงานมีพฤติกรรมที่คาดการณ์และควบคุมได้ แทนที่จะพึ่งพาการตัดสินใจของ LLM เพียงอย่างเดียว การผสานการให้เหตุผลของ LLM และการเขียนสคริปต์แบบกำหนดแน่นอนนี้คือสิ่งที่ช่วยให้เวิร์กโฟลว์ทางธุรกิจทำงานได้ ตัวแทนเพียงตัวเดียวสามารถจัดการงานได้มาก แต่เมื่อความซับซ้อนเพิ่มขึ้น ก็จะพบกับข้อจำกัดเหล่านี้:

• ข้อจำกัดด้านขอบเขตข้อมูล: ข้อมูล เวิร์กโฟลว์ และสิทธิ์ที่อยู่ใน Salesforce Org หรือระบบต่างๆ จะไม่สามารถเข้าถึงได้ นี่คือข้อจำกัดด้านสถาปัตยกรรมที่การออกแบบแบบตัวแทนเดี่ยวไม่สามารถก้าวข้ามได้
• บริบทมากเกินไป: บริบทของกลไกการประมวลผลโดยการใช้ตรรกะและกฎเกณฑ์ของ LLM เต็มไปด้วยคำสั่ง ผลลัพธ์จากการดำเนินการ และประวัติการสนทนา จนเริ่มละเลยกฎหลักหรือทำให้หัวข้อต่างๆ ปะปนกัน
• การล่มสลายของความเชี่ยวชาญเฉพาะด้าน: ตัวแทนที่พยายามเป็นผู้เชี่ยวชาญในทุกด้านอาจใช้ตรรกะที่ไม่ถูกต้องในการเรียกใช้ตัวแทนย่อยเฉพาะด้าน ยิ่งบล็อกคำสั่งมีขนาดใหญ่ ความแม่นยำก็ยิ่งลดลง

กรอบการตัดสินใจ: ใช้ตัวแทนเดี่ยวเมื่อกระบวนการทางธุรกิจของคุณค่อนข้างตรงไปตรงมา ทำงานอยู่ภายในโดเมนเดียว และต้องการชุดการเข้าถึงข้อมูลที่เป็นหนึ่งเดียวสำหรับตัวแทนย่อยของตน

การควบคุมและจัดการตัวแทน SOMA (Single-Org, Multi-Agent) ช่วยให้ตัวแทน Agentforce เฉพาะทางหลายรายการทำงานร่วมกันภายใน Salesforce org เดียวได้อย่างราบรื่น แทนที่จะบังคับให้ผู้ใช้จัดการการสนทนากับตัวแทนต่าง ๆ แยกกัน SOMA มีตัวแทนหน้าประตูการสนทนาแบบรวมเป็นหนึ่งเดียว เบื้องหลัง “Superagent” หรือ “โปรแกรมสร้างสรรค์” จะประสานงานและมอบหมายงานไปยังตัวแทนเฉพาะทางอย่างชาญฉลาด เพื่อให้มั่นใจว่าแต่ละงานได้รับการจัดการโดยตัวแทนที่มีความพร้อมเหมาะสมที่สุดสำหรับงานนั้น

กรอบการตัดสินใจ: ใช้ SOMA เมื่อลูกค้าต้องการประสบการณ์ “หน้าประตู” แบบรวมเป็นหนึ่งเดียวสำหรับตัวแทนเฉพาะทางที่ทำงานภายในสภาพแวดล้อม Salesforce (องค์กร) เดียวกัน

• ข้อดี: ทำให้ประสบการณ์ของผู้ใช้ง่ายขึ้นด้วยการมีจุดเริ่มต้นการสนทนาเพียงจุดเดียวสำหรับตัวแทนเฉพาะทางหลายรายการ
• ข้อเสีย: จำกัดอยู่ที่ข้อมูลและเวิร์กโฟลว์ที่มีอยู่ภายในองค์กร Salesforce เดียว

การควบคุมและจัดการตัวแทนหลายรายการ MOMA (Multi-Org Multi-Agent) ซึ่งเป็นวิวัฒนาการเชิงตรรกะของโมเดลแบบองค์กรเดียว (SOMA) ช่วยให้องค์กร Salesforce หลายแห่งมอบประสบการณ์ตัวแทนแบบรวมเป็นหนึ่งเดียวได้ โดยไม่จำเป็นต้องรวมข้อมูลที่ซับซ้อน สถาปัตยกรรมนี้สร้างขึ้นบนแนวคิดของการมอบหมายงานอย่างมีเจตนาแทนเครือข่ายแบบเปิด และบังคับใช้ข้อจำกัดแบบเจาะลึกหนึ่งระดับอย่างมีเจตนา (ตัวแทน A>ตัวแทน B ไม่ใช่ตัวแทน A->B->C) เพื่อป้องกันการเชื่อมโยงที่คาดเดาไม่ได้ รักษาความปลอดภัยผ่านการดำเนินการที่รับรู้ถึงตัวตนของผู้ใช้และการทำงานภายในขอบเขตความน่าเชื่อถือของ Data 360 One (DC1)

กรอบการตัดสินใจ: ใช้ MOMA เมื่อเครือข่าย Agentforce แบบเนทีฟของคุณต้องการมอบหมายงานอย่างปลอดภัยข้ามองค์กร Salesforce ที่แตกต่างกันโดยไม่ต้องรวมโมเดลข้อมูลเข้าไว้ด้วยกัน

• ข้อดี: มอบประสบการณ์ตัวแทนแบบรวมเป็นหนึ่งเดียวทั่วทั้งระบบองค์กรที่ซับซ้อน พร้อมรักษาข้อกำหนดด้านถิ่นที่อยู่ของข้อมูลอย่างเข้มงวด
• ข้อเสีย: การแมปตัวตนของผู้ใช้ข้ามหลายองค์กรและการแชร์บริบทระหว่างองค์กรอาจเป็นเรื่องท้าทาย

ไคลเอนต์โปรโตคอลบริบทของโมเดล (MCP) ช่วยให้ผู้ดูแลระบบ Agentforce ลงทะเบียน MCP เซิร์ฟเวอร์ภายนอก เพื่อให้นักพัฒนาสามารถผสานรวมเครื่องมือ ทรัพยากร และการดำเนินการระยะไกลภายใน Agentforce ได้ในรูปแบบมาตรฐาน ช่วยให้ Agentforce ใช้ความสามารถภายนอกผ่านสัญญาของเครื่องมือ แทนการผสานรวมแบบจุดต่อจุดที่สร้างขึ้นเฉพาะเจาะจง

กรอบการตัดสินใจ: ใช้ MCP Client เมื่อ Agentforce ควรยังคงเป็นโปรแกรมสร้างสรรค์หลักและเพียงต้องการเข้าถึงความสามารถภายนอกในรูปแบบเครื่องมือ ตัวอย่างเช่น การดึงข้อมูลจากระบบภายนอก การเรียกใช้เวิร์กโฟลว์ การค้นหาแหล่งความรู้ หรือการดำเนินการผ่านแพลตฟอร์มของบุคคลที่สาม

ใช้ MCP Client เมื่อ Agentforce ควรใช้ความสามารถภายนอกในรูปแบบเครื่องมือ

• ข้อดี: เปลี่ยนบริการภายนอกให้เป็นเครื่องมือที่ปลอดภัยและสามารถกำกับดูแลได้สำหรับ Agentforce โดยไม่ต้องเขียนโค้ดแบบกำหนดเอง พร้อมฟีเจอร์ด้านความปลอดภัย เช่น การตรวจสอบความถูกต้องเชิงความหมาย (anti-rug pull) และการให้คะแนนความเสี่ยงเพื่อป้องกันการปนเปื้อนเครื่องมือ ช่วยให้วงจรการให้เหตุผลยังคงอยู่ที่ศูนย์กลางใน Agentforce ขณะที่ขยายขอบเขตสิ่งที่ Agentforce สามารถทำได้
• ข้อเสีย: เลเยอร์นามธรรมนี้ออกแบบมาโดยเน้นเครื่องมือเป็นศูนย์กลางโดยเจตนา หากความสามารถระยะไกลเหมาะที่จะจำลองเป็นตัวแทนเฉพาะทางที่ควรรับผิดชอบส่วนหนึ่งของการให้เหตุผลหรือเวิร์กโฟลว์ การบังคับให้ความสามารถนั้นอยู่ใน MCP อาจไม่เป็นธรรมชาติ นอกจากนี้ เนื่องจากโครงสร้างถูกกำหนดโดยเซิร์ฟเวอร์ภายนอก การเปลี่ยนแปลงสัญญาอาจทำให้การผสานรวมล้มเหลวจนกว่าจะมีการรีเฟรชหรือลงทะเบียนใหม่

Agentforce A2A ขาออก เป็นวิธีแบบเนทีฟสำหรับตัวแทน Agentforce ในการทำงานร่วมกันโดยตรงกับตัวแทนของบุคคลที่สาม เพื่อเปิดใช้งานสิ่งนี้ ผู้ดูแลระบบต้องลงทะเบียนตัวแทนภายนอกก่อน โดยระบุทักษะ ความสามารถ และโปรโตคอลการรับส่งข้อมูลเฉพาะของตัวแทนนั้น เมื่อลงทะเบียนและเชื่อมต่อกับตัวแทน Agentforce แล้ว ตัวแทนดังกล่าวจะพร้อมใช้งานขณะรันไทม์สำหรับการมอบหมายงานข้ามแพลตฟอร์มอย่างปลอดภัย

กรอบการตัดสินใจ: ใช้ Agentforce A2A เมื่อเครือข่าย Agentforce แบบเนทีฟของคุณต้องการโต้ตอบอย่างปลอดภัยกับตัวแทนของผู้ให้บริการภายนอก เช่น Google หรือ Box หมายเหตุ: ในกรณีนี้ ตัวแทนหนึ่งต้องมอบหมายงานให้ตัวแทนอีกรายที่รับผิดชอบบางส่วนของการให้เหตุผล การวางแผน หรือการดำเนินการ

• ข้อดี: เนื่องจากสร้างขึ้นโดยตรงใน Agentforce คุณจึงไม่จำเป็นต้องซื้อเครื่องมือควบคุมและจัดการภายนอกเพื่อจัดการเวิร์กโฟลว์แบบหลายตัวแทนเหล่านี้ ช่วยให้ผู้ใช้ได้รับระบบนิเวศ AI ที่มี “แบรนด์แบบรวมเป็นหนึ่งเดียว” และใช้ความเชี่ยวชาญที่สร้างไว้ล่วงหน้าจากแพลตฟอร์มภายนอก
• ข้อเสีย: การไว้วางใจตัวแทนของบุคคลที่สามและการรับรองความเป็นส่วนตัวของข้อมูลข้ามระบบอาจเป็นเรื่องท้าทาย จำเป็นต้องลงทะเบียนความสามารถของตัวแทนบุคคลที่สามด้วยตนเองและให้ตรงตามมาตรฐานการตรวจสอบสิทธิ์

ใช้กฎง่ายๆ นี้: ประเด็นสำคัญไม่ได้อยู่ที่ว่ามี AI อยู่ทั้งสองฝั่งหรือไม่ ประเด็นสำคัญคือ วิธีที่จำลองความสามารถระยะไกล:

• หากจำลองเป็น เครื่องมือ ให้ใช้ MCP
• หากจำลองเป็น ตัวแทนที่ทำงานร่วมกัน ให้ใช้ A2A

A2A ขาเข้าช่วยให้ตัวแทนของบุคคลที่สามภายนอกสามารถเรียกใช้ทักษะเฉพาะทางและข้อมูลของตัวแทน Agentforce ได้โดยตรงแบบเนทีฟ การตั้งค่านี้ทำให้ Agentforce เป็น “ผู้เชี่ยวชาญ” ที่มีมูลค่าสูง ซึ่งระบบภายนอกสามารถเรียกใช้เพื่อดำเนินการที่เฉพาะเจาะจงกับ Salesforce ได้ ด้วยการเปิดเผยความสามารถของ Agentforce ผ่านปลายทาง API ที่ปลอดภัย แพลตฟอร์มภายนอกสามารถมอบหมายงานให้ Salesforce ได้โดยที่ผู้ใช้ไม่ต้องออกจากแอปพลิเคชันของบุคคลที่สามเลย

กรอบการตัดสินใจ: ใช้ A2A ขาเข้าเมื่ออินเทอร์เฟซ AI หลักของคุณอยู่ในระบบของบุคคลที่สาม (เช่น พอร์ทัลที่สร้างขึ้นเองหรือบอตภายนอก) แต่ต้องดำเนินการเวิร์กโฟลว์ที่ซับซ้อนภายใน Salesforce

• ข้อดี: เสริมความสามารถให้แอปพลิเคชันภายนอกด้วยข้อมูล Salesforce แบบเรียลไทม์และระบบอัตโนมัติ โดยไม่ต้องทำซ้ำตรรกะ
• ข้อเสีย: ระบบภายนอกต้องจัดการการควบคุมและจัดการตัวแทนและตรรกะของ “การส่งต่องาน” เพื่อให้มั่นใจว่าผู้ใช้จะได้รับประสบการณ์ที่ราบรื่น

MCP เซิร์ฟเวอร์ที่โฮสต์โดย Salesforce ช่วยให้ความสามารถของ Agentforce ถูกเปิดเผยให้กับ Host ภายนอก เช่น ตัวแทนของบุคคลที่สาม Copilot และแพลตฟอร์ม LLM ผ่านอินเทอร์เฟซ MCP มาตรฐาน ช่วยให้แพลตฟอร์มภายนอกเรียกใช้ Agentforce ในฐานะผู้ให้บริการเครื่องมือ ขณะที่ Agentforce ยังคงรวบรวมการดำเนินการระดับองค์กร ตรรกะทางธุรกิจ และการควบคุมและจัดการตัวแทนไว้เบื้องหลังสำหรับงานที่ซับซ้อนและเฉพาะทาง

กรอบการตัดสินใจ: ใช้ตัวแทน Agentforce เป็น MCP เซิร์ฟเวอร์เมื่อแพลตฟอร์มภายนอกควรใช้ Agentforce ในฐานะผู้ให้บริการเครื่องมือ สิ่งนี้มีประโยชน์อย่างยิ่งในสองสถานการณ์:

• การทำงานร่วมกันระหว่างตัวแทนระดับองค์กร: เมื่อตัวแทนระดับองค์กรของบุคคลที่สาม เช่น Microsoft Copilot ต้องการเรียกใช้ตัวแทน Agentforce เนื่องจาก Agentforce มีการดำเนินการระดับองค์กรที่จำเป็นต่อการทำงานให้เสร็จสมบูรณ์
• การกระจายไปยัง LLM / ช่องทางภายนอก: เมื่อคุณต้องการให้ความสามารถของ Agentforce ภายใต้แบรนด์สามารถเข้าถึงได้ภายในอินเทอร์เฟซการสนทนาภายนอก เช่น ChatGPT, Gemini หรือ Host ที่คล้ายกัน

ในโมเดลนี้ แพลตฟอร์มภายนอกยังคงเป็นประสบการณ์หลักของ Host ขณะที่ Agentforce ถูกเปิดเผยผ่าน MCP โดยเจตนาในรูปแบบปลายทางเครื่องมือ แม้ว่าจะ Agentforce เป็นแบบ Agentic ภายในแต่รูปแบบการทำงานร่วมกันยังคงเป็นแบบ MCP เนื่องจากความสัมพันธ์ภายนอกคือการเรียกใช้เครื่องมือแทนการมอบหมายตัวแทนแบบ peer-agent

• ข้อดี: ทำให้สามารถใช้ตัวแทน Agentforce ที่ทรงพลังและมีความเชี่ยวชาญซึ่งสร้างขึ้นสำหรับธุรกิจของคุณบนข้อมูล Salesforce (การเรียกเก็บเงิน การสนับสนุน ฯลฯ) ซ้ำภายนอก Salesforce ผ่านโปรโตคอลมาตรฐานได้อย่างง่ายดาย ช่วยให้ผู้ช่วยภายนอกและตัวแทนระดับองค์กรใช้การควบคุมและจัดการตัวแทนและการดำเนินการทางธุรกิจของ Agentforce ได้โดยไม่ต้องสร้างขึ้นใหม่ และรองรับทั้งการทำงานร่วมกันระหว่างตัวแทนระดับองค์กรและการกระจายไปยังช่องทางภายนอก
• ข้อเสีย: Host ภายนอกเป็นผู้ควบคุมประสบการณ์ผู้ใช้หลักและวงจรการให้เหตุผล ดังนั้น Agentforce จึงมีการควบคุมวิธีการและเวลาที่ถูกเรียกใช้งานน้อยลง สถานการณ์ระดับองค์กรยังต้องมีการจัดการที่รัดกุมสำหรับการตรวจสอบสิทธิ์ การอนุญาต การส่งต่อข้อมูลตัวตน และการส่งต่อบริบท

ภาพรวมข้างต้นเป็นเพียงจุดเริ่มต้น ซึ่งช่วยให้คุณระบุได้ว่ารูปแบบการควบคุมและจัดการตัวแทนใดเหมาะกับกรณีการใช้งานของคุณ อ่านต่อเพื่อดูวิธีออกแบบและนำไปใช้งานจริง

นี่คือสิ่งที่คุณจะได้เรียนรู้เมื่อดาวน์โหลดตอนที่ 2: คู่มืออ้างอิงการควบคุมและจัดการตัวแทนหลายรายการสำหรับสถาปนิก:

• แยกกระบวนการที่ซับซ้อนออกเป็นตัวแทนที่ยังคงรับผิดชอบต่อหน้าที่ของตน กลยุทธ์สามรูปแบบ ได้แก่ ตามความเชี่ยวชาญเฉพาะด้าน ตามขั้นตอนของเวิร์กโฟลว์ หรือ ตามความสามารถ ช่วยเปลี่ยนตัวแทนที่มีขนาดใหญ่และซับซ้อนหนึ่งตัวให้เป็นชุดของตัวแทนเฉพาะทางที่แต่ละตัวทำงานหนึ่งอย่างได้อย่างมีประสิทธิภาพ
• จับคู่สถาปัตยกรรมของคุณกับหนึ่งในห้ารูปแบบการควบคุมและจัดการตัวแทน Supervised Mode และ Handoff Mode พร้อมใช้งานทั่วไปแล้วในปัจจุบัน Parallel Execution, Event-Driven Background Agents และ Plan and Present อยู่ในแผนงานการพัฒนา
• เลือกระหว่างการกำหนดเส้นทางที่ขับเคลื่อนด้วย LLM และการกำหนดเส้นทางแบบกำหนดแน่นอน กลไกการประมวลผลโดยการใช้ตรรกะและกฎเกณฑ์สามารถปรับให้ยืดหยุ่นตามคำขอที่ไม่มีรูปแบบตายตัวได้ สคริปต์ของตัวแทนช่วยให้คุณควบคุมแบบกำหนดแน่นอนได้เมื่อเวิร์กโฟลว์ต้องการลำดับขั้นตอนที่รับประกันได้ การออกแบบแบบหลายตัวแทนส่วนใหญ่ใช้ทั้งสองรูปแบบ
• หลีกเลี่ยงรูปแบบการออกแบบที่ไม่เหมาะสมซึ่งพบบ่อยที่สุด 7 รูปแบบ การควบคุมและจัดการแบบ Mesh ตัวแทนย่อยที่มีขอบเขตงานทับซ้อนกัน และการมอบหมายงานหลายชั้นเกินไป เป็นวิธีที่รวดเร็วที่สุดในการบั่นทอนการกำกับดูแลและความสามารถใน การตรวจสอบ ในระดับขนาดใหญ่
• ออกแบบโดยคำนึงถึงสิ่งที่รองรับในปัจจุบัน ข้อจำกัดปัจจุบันขอสคริปต์ของตัวแทน (การส่งต่องานแบบ Sticky Handoff, การมอบหมายงานแบบซ้อนกัน และขีดจำกัดตัวแทนย่อยที่เชื่อมต่อได้ 7 รายการ) เป็นตัวกำหนดว่ารูปแบบใดที่คุณสามารถนำไปใช้งานได้ในขณะนี้ เทียบกับรูปแบบที่ควรวางแผนสำหรับไตรมาสถัดไป