بروتوكول اتصال الوكيل (ACP) هو معيار مفتوح للاتصال بين الوكلاء. باستخدام هذا البروتوكول، يمكننا تحويل المشهد الحالي من الوكلاء المنعزلين إلى أنظمة وكلاء قابلة للتشغيل المتبادل مع تكامل وتعاون أسهل.
النشرة الإخبارية الخاصة بالمجال
ابقَ على اطلاع دومًا بأهم—اتجاهات المجال وأكثرها إثارة للفضول—بشأن الذكاء الاصطناعي والأتمتة والبيانات وغيرها الكثير مع نشرة Think الإخبارية. راجع بيان الخصوصية لشركة IBM.
سيتم تسليم اشتراكك باللغة الإنجليزية. ستجد رابط إلغاء الاشتراك في كل رسالة إخبارية. يمكنك إدارة اشتراكاتك أو إلغاء اشتراكك هنا. راجع بيان خصوصية IBM لمزيد من المعلومات.
باستخدام ACP، الذي قدَّمَته IBM لأول مرة عبر BeeAI، يمكن لوكلاء الذكاء الاصطناعي التعاون بحرية عبر الفرق وأطر العمل والتقنيات والمؤسسات. إنه بروتوكول عالمي يحوِّل المشهد المُجزَّأ لوكلاء الذكاء الاصطناعي اليوم إلى زملاء فريق مترابطين، وهذا المعيار المفتوح يفتح مستويات جديدة من التشغيل البيني وإعادة الاستخدام والتوسع. كخطوة تالية بعد بروتوكول سياق النموذج (MCP)، وهو معيار مفتوح للوصول إلى الأدوات والبيانات، يحدِّد بروتوكول سياق النموذج (ACP) كيفية عمل الوكلاء وتواصلهم.1
للتوضيح، وكيل الذكاء الاصطناعي هو نظام أو برنامج قادر على تنفيذ المهام بشكل مستقل نيابةً عن مستخدم أو نظام آخر. وينفِّذ هذه المهام من خلال تصميم سير العمل واستخدام الأدوات المتاحة. تتكون الأنظمة متعددة الوكلاء من وكلاء ذكاء اصطناعي متعددين يعملون بشكل جماعي لأداء المهام نيابةً عن مستخدم أو نظام آخر.
باعتباره معيارًا لتواصل وكلاء الذكاء الاصطناعي مع حوكمة مفتوحة، يسمح ACP لوكلاء الذكاء الاصطناعي بالتواصل عبر أطر عمل ومجموعات تقنية مختلفة. بدءًا من تلقي استفسارات المستخدم في شكل لغة طبيعية إلى تنفيذ سلسلة من الإجراءات، يعمل وكلاء الذكاء الاصطناعي بشكل أفضل عند تزويدهم ببروتوكولات الاتصال. تنقل هذه البروتوكولات هذه المعلومات بين الأدوات والوكلاء الآخرين وفي النهاية إلى المستخدم.
يشير اتصال وكيل الذكاء الاصطناعي إلى كيفية تفاعل وكلاء الذكاء الاصطناعي مع بعضهم أو البشر أو الأنظمة الخارجية لتبادل المعلومات واتخاذ القرارات وإكمال المهام. يُعَد هذا التواصل مهمًا بشكل خاص في الأنظمة متعددة الوكلاء، حيث يتعاون العديد من وكلاء الذكاء الاصطناعي، وفي التفاعل بين الإنسان والذكاء الاصطناعي.
يُعَد ACP جزءًا من منظومة متنامية تشمل BeeAI. فيما يلي بعض الميزات الرئيسية، ويمكنك الاطلاع على المفاهيم الأساسية والتفاصيل الكاملة في الوثائق الرسمية.
ملاحظة: يُتيح ACP تنسيق الوكلاء لأي بنية وكيلية، ولكنه لا يُدير سير العمل أو عمليات النشر أو التنسيق بين الوكلاء. وبدلًا من ذلك، فهو يُتيح التنسيق بين وكلاء مختلفين من خلال توحيد كيفية تواصلهم. قامت شركة IBM Research بتطوير BeeAI، وهو نظام مفتوح المصدر مصمم للتعامل مع تنسيق الوكلاء ونشره ومشاركته باستخدام ACP كطبقة اتصال.
مع استمرار ارتفاع مستوى الذكاء الاصطناعي الوكيل، يتزايد أيضًا مقدار التعقيد في تحديد كيفية الحصول على أفضل نتيجة من كل تقنية مستقلة لحالة الاستخدام لديك، دون الاقتصار على مورِّد معين. يقدِّم كل إطار عمل ومنصة ومجموعة أدوات مزايا فريدة، ولكن دمجها جميعًا في نظام وكيل واحد يُعَد أمرًا صعبًا.
اليوم، تعمل معظم أنظمة الوكلاء في صوامع معزولة. يتم بناؤها على أطر عمل غير متوافقة، وتستخدم واجهات برمجة تطبيقات ونقاط نهاية مخصصة، وتفتقر إلى بروتوكول موحَّد للتواصل. ويتطلب ربطها تكاملات هشة وغير قابلة للتكرار، وهي مكلفة للغاية في البناء.
يمثل ACP تحولًا جوهريًا: من نظام بيئي مجزأ وعشوائي إلى شبكة مترابطة من الوكلاء، يستطيع كل منهم اكتشاف الآخرين وفهمهم والتعاون معهم، بغض النظر عن الجهة المطوِّرة أو البيئة التقنية التي يعملون عليها. بفضل ACP، يمكن للمطوِّرين الاستفادة من الذكاء الجماعي لوكلاء متنوعين لبناء سير عمل أقوى مما يمكن أن يقدمه أي نظام فردي بمفرده.
على الرغم من النمو السريع في قدرات الوكلاء، إلا أن التكامل في العالم الحقيقي لا يزال يشكل عقبة كبيرة. فمن دون بروتوكول اتصال مشترك، تواجه المؤسسات العديد من التحديات المتكررة:
لتوضيح الحاجة الواقعية إلى التواصل بين الوكلاء، دعنا نأخذ مثالًا على مؤسستَين:
تخيَّل الآن أن نظام الشركة المصنِّعة يحتاج إلى تقدير مواعيد التسليم لطلب معدات مخصصة كبيرة الحجم لإبلاغ العميل بعرض السعر.
دون ACP: يتطلب هذا النهج بناء تكامل مخصص بين برنامج التخطيط الخاص بالشركة المصنِّعة وواجهات برمجة التطبيقات الخاصة بمزوِّد الخدمات اللوجستية. وهذا يعني التعامل مع المصادقة وعدم تطابق تنسيق البيانات وتوافر الخدمة يدويًا. هذه التكاملات مكلفة وهشة ويصعب توسيع نطاقها مع انضمام المزيد من الشركاء.
مع ACP: تقوم كل مؤسسة بتغليف وكيلها بواجهة ACP. يُرسل وكيل التصنيع تفاصيل الطلب والوجهة إلى وكيل الخدمات اللوجستية، والذي يستجيب بخيارات الشحن في الوقت الفعلي وأوقات الوصول المتوقعة. يقوم كِلا النظامين بالتعاون الوكيل دون الكشف عن العناصر الداخلية أو كتابة تكاملات مخصصة. يمكن تقديم شركاء لوجستيين جُدُد ببساطة عن طريق تنفيذ ACP. تُتيح الأتمتة التي يوفرها وكلاء الذكاء الاصطناعي المقترنين بـ ACP قابلية التوسع وتبسيط تبادل البيانات.
البساطة هي مبدأ التصميم الأساسي لإطار ACP. من الممكن تغليف وكيل باستخدام ACP في بضعة أسطر من التعليمات البرمجية فقط. باستخدام حزمة SDK الخاصة بـ Python، يمكنك تعريف وكيل متوافق مع ACP ببساطة من خلال تزيين وظيفة.
هذا التنفيذ البسيط:
مثال على الكود:
from typing import Annotated
import os
from typing_extensions import TypedDict
from dotenv import load_dotenv
#ACP SDK
from acp_sdk.models import Message
from acp_sdk.models.models import MessagePart
from acp_sdk.server import RunYield, RunYieldResume, Server
from collections.abc import AsyncGenerator
#Langchain SDK
from langgraph.graph.message import add_messages
from langchain_anthropic import ChatAnthropic
load_dotenv()
class State(TypedDict):
messages: Annotated[list, add_messages]
#Set up the AI model of your choice
llm = ChatAnthropic(model="claude-3-5-sonnet-latest",
api_key=os.environ.get("ANTHROPIC_API_KEY"))
#------ACP Requirement-------#
#START SERVER
server = Server()
#WRAP AGENT IN DECORACTOR
@server.agent()
async def chatbot(messages: list[Message])-> AsyncGenerator[RunYield, RunYieldResume]:
"A simple chatbot enabled with memory"
#formats ACP Message format to be compatible with what langchain expects
query = " ".join(
part.content
for m in messages
for part in m.parts
)
#invokes llm
llm_response = llm.invoke(query)
#formats langchain response to ACP compatible output
assistant_message = Message(parts=[MessagePart(content=llm_response.content)])
# Yield so add_messages merges it into state
yield {"messages": [assistant_message]}
server.run()
#---------------------------#
الآن، أنشأت وكيلًا متوافقًا تمامًا مع ACP والذي يمكن:
لفهم دور ACP بشكل أفضل في نظام الذكاء الاصطناعي المتطور، من المفيد مقارنته ببروتوكولات ناشئة أخرى. هذه البروتوكولات ليست بالضرورة متنافسة. بل إن كلًّا منها يتعامل مع طبقات مختلفة من حزمة تكامل أنظمة الذكاء الاصطناعي، وغالبًا ما تُكمِّل بعضها.
لمحة عامة:
بروتوكول سياق النموذج (MCP): مصمم لإثراء سياق نموذج واحد بالأدوات والذاكرة والموارد. تم تطويره بواسطة Anthropic.
التركيز: نموذج واحد، أدوات متعددة.
بروتوكول اتصال الوكيل (ACP): مصمم للاتصال بين الوكلاء المستقلين عبر الأنظمة والمؤسسات. تم تطويره بواسطة BeeAI من IBM.
التركيز: عدد كبير من الوكلاء يعملون بأمان كمشاركين متساوين، دون احتكار من جهة مزوّدة، وبحوكمة مفتوحة.
بروتوكول Agent2Agent (A2A): مصمم للتواصل بين الوكلاء المستقلين عبر الأنظمة والمؤسسات. تم تطويره بواسطة Google.
التركيز: عدد كبير من الوكلاء يعملون كمشاركين متساويين، ومحسَّنون للعمل ضمن منظومة Google.
استكشف فريق ACP في البداية إمكانية تكييف بروتوكول سياق النموذج (MCP) لأنه يوفر أساسًا قويًا للتفاعلات بين النموذج والسياق. ومع ذلك، سرعان ما واجهوا قيودًا معمارية جعلته غير مناسب للتواصل الحقيقي بين الوكلاء.
لماذا لا يفي بروتوكول MCP بالغرض في الأنظمة متعددة الوكلاء؟
البث: يدعم MCP البث الأساسي، غالبًا لرسائل كاملة، لكنه لا يدعم النمط الأكثر دقة المعروف بـ "delta"، حيث يتم إرسال التحديثات فور حدوثها. تُعَد تدفقات Delta، مثل الرموز المميزة وتحديثات المسارات، تدفقات مكونة من تحديثات تدريجية بدلًا من حمولات البيانات الكاملة. هذا القيد يعود إلى أن MCP عند إنشائه لم يتم تصميمه ليتناسب مع نمط التفاعل بين الوكلاء.
مشاركة الذاكرة: لا يدعم MCP تشغيل وكلاء متعددين عبر الخوادم مع الحفاظ على الذاكرة المشتركة. لا يدعم ACP هذه الوظيفة بشكل كامل حتى الآن أيضًا، ولكنه مجال نشط قيد التطوير.
هيكل الرسالة: يقبل MCP أي مخطط JSON ولكنه لا يحدِّد هيكل نص الرسالة. تجعل هذه المرونة قابلية التشغيل البيني صعبة، خاصةً بالنسبة إلى وكلاء البناء الذين يجب أن يفسِّروا تنسيقات الرسائل المتنوعة.
تعقيد البروتوكول: يستخدم MCP بروتوكول JSON-RPC ويتطلب حزم SDK وبيئات تشغيل محددة. في المقابل، يتميز تصميم ACP المعتمد على REST والداعم للتواصل المتزامن وغير المتزامن بأنه أخف وأسهل في التكامل.
يمكن تشبيه MCP بتقديم أدوات أفضل لشخص ما، مثل آلة حاسبة أو مرجع، لتعزيز أدائه. على النقيض من ذلك، يهدف ACP إلى تمكين الأشخاص من تشكيل فرق، حيث يساهم كل شخص، أو وكيل، بقدراته بشكل تعاوني داخل تطبيق الذكاء الاصطناعي.
يمكن أن يُكمل كلٌّ من ACP وMCP بعضهما:
بروتوكول Agent2Agent (A2A) من Google، الذي تم تطويره بعد فترة وجيزة من ACP، يهدف أيضًا إلى توحيد الاتصال بين وكلاء الذكاء الاصطناعي. يتشارك كِلا البروتوكولين في هدف تمكين أنظمة متعددة الوكلاء، لكنهما يختلفان في الفلسفة والحوكمة.
الاختلافات الرئيسية:
تم تصميم ACP عمدًا ليكون:
يمكن أن يتعايش كِلا البروتوكولين معًا، حيث يخدم كل منهما احتياجات مختلفة حسب البيئة. يُتيح تصميم ACP الخفيف والمفتوح والقابل للتوسعة توافقًا مثاليًا مع الأنظمة اللامركزية والتشغيل البيني الواقعي عبر حدود المؤسسات. قد تجعل قابلية A2A للتكامل الطبيعي منه خيارًا أكثر ملاءمة للمستخدمين ضمن منظومة Google.
مع تطور ACP، يتم استكشاف إمكانيات جديدة لتعزيز التواصل مع الوكيل. فيما يلي بعض مجالات التركيز الرئيسية:
يتم تطوير ACP باستخدام المصدر المفتوح لأن المعايير تعمل بشكل أفضل عندما يتم تطويرها مباشرةً مع المستخدمين. المساهمات من المطوِّرين والباحثين والمؤسسات المهتمة بمستقبل قابلية التشغيل البيني لوكيل الذكاء الاصطناعي. انضم إلينا للمساعدة على تشكيل معيار الذكاء الاصطناعي التوليدي هذا.
لمزيد من المعلومات، تفضَّل بزيارة موقع ACP الرسمي وانضم إلى المحادثة على GitHub وDiscord.
يمكنك إنشاء مساعدين ووكلاء ذكاء اصطناعي ووكلاء أقوياء يعملون على أتمتة مهام سير العمل والعمليات باستخدام الذكاء الاصطناعي التوليدي ونشرها وإدارتها.
يمكنك بناء مستقبل عملك باستخدام حلول الذكاء الاصطناعي الجديرة بالثقة.
تساعد خدمات IBM Consulting AI في إعادة تصور طريقة عمل الشركات باستخدام حلول الذكاء الاصطناعي من أجل النهوض بأعمالها.