أحدث اتجاهات الذكاء الاصطناعي، يقدمها لك الخبراء
احصل على رؤى منسقة حول أهم أخبار الذكاء الاصطناعي وأكثرها إثارةً للاهتمام. اشترِك في خدمة رسائل Think الإخبارية الأسبوعية. راجع بيان الخصوصية لشركة IBM.
بروتوكول اتصال الوكيل (ACP) هو معيار مفتوح للاتصال بين الوكلاء. باستخدام هذا البروتوكول، يمكننا تحويل المشهد الحالي من الوكلاء المنعزلين إلى أنظمة وكلاء قابلة للتشغيل المتبادل مع تكامل وتعاون أسهل.
باستخدام ACP، الذي قدَّمَته IBM لأول مرة عبر BeeAI، يمكن لوكلاء الذكاء الاصطناعي التعاون بحرية عبر الفرق وأطر العمل والتقنيات والمؤسسات. إنه بروتوكول عالمي يحوِّل المشهد المُجزَّأ لوكلاء الذكاء الاصطناعي اليوم إلى زملاء فريق مترابطين، وهذا المعيار المفتوح يفتح مستويات جديدة من التشغيل البيني وإعادة الاستخدام والتوسع. كخطوة تالية بعد بروتوكول سياق النموذج (MCP)، وهو معيار مفتوح للوصول إلى الأدوات والبيانات، يحدِّد بروتوكول سياق النموذج (ACP) كيفية عمل الوكلاء وتواصلهم.1
للتوضيح، وكيل الذكاء الاصطناعي هو نظام أو برنامج قادر على تنفيذ المهام بشكل مستقل نيابةً عن مستخدم أو نظام آخر. وينفِّذ هذه المهام من خلال تصميم سير العمل واستخدام الأدوات المتاحة. تتكون الأنظمة متعددة الوكلاء من وكلاء ذكاء اصطناعي متعددين يعملون بشكل جماعي لأداء المهام نيابةً عن مستخدم أو نظام آخر.
باعتباره معيارًا لتواصل وكلاء الذكاء الاصطناعي مع حوكمة مفتوحة، يسمح ACP لوكلاء الذكاء الاصطناعي بالتواصل عبر أطر عمل ومجموعات تقنية مختلفة. بدءًا من تلقي استفسارات المستخدم في شكل لغة طبيعية إلى تنفيذ سلسلة من الإجراءات، يعمل وكلاء الذكاء الاصطناعي بشكل أفضل عند تزويدهم ببروتوكولات الاتصال. تنقل هذه البروتوكولات هذه المعلومات بين الأدوات والوكلاء الآخرين وفي النهاية إلى المستخدم.
يشير اتصال وكيل الذكاء الاصطناعي إلى كيفية تفاعل وكلاء الذكاء الاصطناعي مع بعضهم أو البشر أو الأنظمة الخارجية لتبادل المعلومات واتخاذ القرارات وإكمال المهام. يُعَد هذا التواصل مهمًا بشكل خاص في الأنظمة متعددة الوكلاء، حيث يتعاون العديد من وكلاء الذكاء الاصطناعي، وفي التفاعل بين الإنسان والذكاء الاصطناعي.
يُعَد ACP جزءًا من منظومة متنامية تشمل BeeAI. فيما يلي بعض الميزات الرئيسية، ويمكنك الاطلاع على المفاهيم الأساسية والتفاصيل الكاملة في الوثائق الرسمية.
- الاتصال القائم على REST: يستخدم ACP اتفاقيات HTTP القياسية للاتصال، ما يجعل من السهل دمجه في الإنتاج. بينما يعتمد MCP على تنسيق JSON-RPC الذي يتطلب طرق اتصال أكثر تعقيدًا.
- لا حاجة إلى SDK: لا يتطلب ACP أي مكتبات متخصصة. يمكنك التفاعل مع الوكلاء الأذكياء باستخدام أدوات مثل cURL أو Postman أو حتى المتصفح. لزيادة سهولة الاستخدام، تتوفر حزمة تطوير البرمجيات (SDK).
- الاكتشاف دون اتصال بالإنترنت: يمكن لوكلاء ACP تضمين البيانات الوصفية مباشرةً في حزم التوزيع الخاصة بهم، ما يُتيح الاكتشاف حتى عندما يكونون غير نشطين. يدعم هذا البيئات القابلة للتوسع حتى الصفر، حيث يتم تخصيص الموارد ديناميكيًا وقد لا تكون متاحة دائمًا على الإنترنت.
- الأولوية للتواصل غير المتزامن، مع الدعم المتزامن: تم تصميم ACP بحيث يكون التواصل غير المتزامن هو الوضع الافتراضي. هذه الطريقة مثالية للمهام طويلة الأمد أو المعقدة. كما يدعم أيضًا الطلبات المتزامنة.
ملاحظة: يُتيح ACP تنسيق الوكلاء لأي بنية وكيلية، ولكنه لا يُدير سير العمل أو عمليات النشر أو التنسيق بين الوكلاء. وبدلًا من ذلك، فهو يُتيح التنسيق بين وكلاء مختلفين من خلال توحيد كيفية تواصلهم. قامت شركة IBM Research بتطوير BeeAI، وهو نظام مفتوح المصدر مصمم للتعامل مع تنسيق الوكلاء ونشره ومشاركته باستخدام ACP كطبقة اتصال.
مع استمرار ارتفاع مستوى الذكاء الاصطناعي الوكيل، يتزايد أيضًا مقدار التعقيد في تحديد كيفية الحصول على أفضل نتيجة من كل تقنية مستقلة لحالة الاستخدام لديك، دون الاقتصار على مورِّد معين. يقدِّم كل إطار عمل ومنصة ومجموعة أدوات مزايا فريدة، ولكن دمجها جميعًا في نظام وكيل واحد يُعَد أمرًا صعبًا.
اليوم، تعمل معظم أنظمة الوكلاء في صوامع معزولة. يتم بناؤها على أطر عمل غير متوافقة، وتستخدم واجهات برمجة تطبيقات ونقاط نهاية مخصصة، وتفتقر إلى بروتوكول موحَّد للتواصل. ويتطلب ربطها تكاملات هشة وغير قابلة للتكرار، وهي مكلفة للغاية في البناء.
يمثل ACP تحولًا جوهريًا: من نظام بيئي مجزأ وعشوائي إلى شبكة مترابطة من الوكلاء، يستطيع كل منهم اكتشاف الآخرين وفهمهم والتعاون معهم، بغض النظر عن الجهة المطوِّرة أو البيئة التقنية التي يعملون عليها. بفضل ACP، يمكن للمطوِّرين الاستفادة من الذكاء الجماعي لوكلاء متنوعين لبناء سير عمل أقوى مما يمكن أن يقدمه أي نظام فردي بمفرده.
على الرغم من النمو السريع في قدرات الوكلاء، إلا أن التكامل في العالم الحقيقي لا يزال يشكل عقبة كبيرة. فمن دون بروتوكول اتصال مشترك، تواجه المؤسسات العديد من التحديات المتكررة:
- تنوع أطر العمل: تُدير المؤسسات عادةً المئات أو الآلاف من الوكلاء الذين تم إنشاؤهم باستخدام أطر عمل مختلفة مثل LangChain، أو crewAI، أو AutoGen، أو المجموعات المخصصة.
- التكامل المخصص: دون بروتوكول قياسي، يجب على المطوِّرين كتابة موصِّلات مخصصة لكل تفاعل وكيل.
- التطوُّر الأُسي: مع وجود n وكيلًا، قد تحتاج إلى n(n-1)/2 نقطة تكامل مختلفة، ما يجعل من الصعب صيانة أنظمة الوكلاء واسعة النطاق.
- الاعتبارات عبر المؤسسة: تؤدي نماذج الأمان المختلفة وأنظمة المصادقة وتنسيقات البيانات إلى تعقيد التكامل بين الشركات.
لتوضيح الحاجة الواقعية إلى التواصل بين الوكلاء، دعنا نأخذ مثالًا على مؤسستَين:
- شركة تصنيع تستخدم وكيلًا مستقلًا لإدارة جداول الإنتاج وتنفيذ الطلبات استنادًا إلى المخزون الداخلي وطلب العملاء.
- مزود خدمات لوجستية يُدير وكيلًا لتقديم تقديرات الشحن في الوقت الفعلي وتوافر الناقل وتحسين المسار.
تخيَّل الآن أن نظام الشركة المصنِّعة يحتاج إلى تقدير مواعيد التسليم لطلب معدات مخصصة كبيرة الحجم لإبلاغ العميل بعرض السعر.
دون ACP: يتطلب هذا النهج بناء تكامل مخصص بين برنامج التخطيط الخاص بالشركة المصنِّعة وواجهات برمجة التطبيقات الخاصة بمزوِّد الخدمات اللوجستية. وهذا يعني التعامل مع المصادقة وعدم تطابق تنسيق البيانات وتوافر الخدمة يدويًا. هذه التكاملات مكلفة وهشة ويصعب توسيع نطاقها مع انضمام المزيد من الشركاء.
مع ACP: تقوم كل مؤسسة بتغليف وكيلها بواجهة ACP. يُرسل وكيل التصنيع تفاصيل الطلب والوجهة إلى وكيل الخدمات اللوجستية، والذي يستجيب بخيارات الشحن في الوقت الفعلي وأوقات الوصول المتوقعة. يقوم كِلا النظامين بالتعاون الوكيل دون الكشف عن العناصر الداخلية أو كتابة تكاملات مخصصة. يمكن تقديم شركاء لوجستيين جُدُد ببساطة عن طريق تنفيذ ACP. تُتيح الأتمتة التي يوفرها وكلاء الذكاء الاصطناعي المقترنين بـ ACP قابلية التوسع وتبسيط تبادل البيانات.
البساطة هي مبدأ التصميم الأساسي لإطار ACP. من الممكن تغليف وكيل باستخدام ACP في بضعة أسطر من التعليمات البرمجية فقط. باستخدام حزمة SDK الخاصة بـ Python، يمكنك تعريف وكيل متوافق مع ACP ببساطة من خلال تزيين وظيفة.
هذا التنفيذ البسيط:
- يُنشئ مثيل خادم ACP.
- يحدِّد وظيفة وكيل باستخدام وظيفة التزيين @server.agent() .
- ينفِّذ وكيلًا باستخدام إطار LangChain مع نموذج لغة كبير (LLM) كخلفية وذاكرة للحفاظ على السياق.
- يترجم بين تنسيق الرسائل في ACP والتنسيق الأصلي للإطار لعرض استجابة منظمة.
- يبدأ تشغيل الخادم، ما يجعل الوكيل متاحًا عبر HTTP.
مثال على الكود:
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.
لفهم دور 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 عمدًا ليكون:
- سهل التكامل من خلال استخدام أدوات HTTP الشائعة ومعايير REST.
- مرنًا عبر مجموعة واسعة من أنواع الوكلاء وأعباء العمل.
- محايدًا من حيث المورِّدين، مع حوكمة مفتوحة ومواءمة واسعة للمنظومة.
يمكن أن يتعايش كِلا البروتوكولين معًا، حيث يخدم كل منهما احتياجات مختلفة حسب البيئة. يُتيح تصميم ACP الخفيف والمفتوح والقابل للتوسعة توافقًا مثاليًا مع الأنظمة اللامركزية والتشغيل البيني الواقعي عبر حدود المؤسسات. قد تجعل قابلية A2A للتكامل الطبيعي منه خيارًا أكثر ملاءمة للمستخدمين ضمن منظومة Google.
مع تطور ACP، يتم استكشاف إمكانيات جديدة لتعزيز التواصل مع الوكيل. فيما يلي بعض مجالات التركيز الرئيسية:
- اتحاد الهوية: كيف يستطيع ACP العمل مع أنظمة المصادقة لتحسين الثقة عبر الشبكات؟
- تفويض الوصول: كيف يمكننا تمكين الوكلاء من تفويض المهام بأمان مع الحفاظ على تحكُّم المستخدم؟
- دعم السجلات المتعددة: هل يستطيع ACP دعم اكتشاف الوكيل اللامركزي عبر شبكات مختلفة؟
- مشاركة الوكلاء: كيف يمكننا جعل مشاركة الوكلاء وإعادة استخدامهم عبر المؤسسات أو داخلها أسهل؟
- عمليات النشر: ما الأدوات والقوالب التي يمكنها تبسيط نشر الوكيل؟
يتم تطوير ACP باستخدام المصدر المفتوح لأن المعايير تعمل بشكل أفضل عندما يتم تطويرها مباشرةً مع المستخدمين. المساهمات من المطوِّرين والباحثين والمؤسسات المهتمة بمستقبل قابلية التشغيل البيني لوكيل الذكاء الاصطناعي. انضم إلينا للمساعدة على تشكيل معيار الذكاء الاصطناعي التوليدي هذا.
لمزيد من المعلومات، تفضَّل بزيارة موقع ACP الرسمي وانضم إلى المحادثة على GitHub وDiscord.
الموارد
يمكنك إنشاء مساعدين ووكلاء ذكاء اصطناعي ووكلاء أقوياء يعملون على أتمتة مهام سير العمل والعمليات باستخدام الذكاء الاصطناعي التوليدي ونشرها وإدارتها.
يمكنك بناء مستقبل عملك باستخدام حلول الذكاء الاصطناعي الجديرة بالثقة.
تساعد خدمات IBM Consulting AI في إعادة تصور طريقة عمل الشركات باستخدام حلول الذكاء الاصطناعي من أجل النهوض بأعمالها.