بروتوكول ACP: معيار موحّد لوكلاء البرمجة بالذكاء الاصطناعي

إذا جرّبت خلال العام الماضي أدوات مثل Claude Code و Codex CLI و Gemini CLI وحفنة من الوكلاء المدمجين في المحررات، فقد شعرت بالاحتكاك نفسه: كل وكيل يتحدث بلهجته الخاصة، ويأتي بواجهته الخاصة، ويحبسك داخل أداة واحدة. تبديل المحرر يعني إعادة تعلّم الوكيل، وبناء محرر يعني إعادة دمج كل وكيل يدويًا.

بروتوكول عميل الوكيل (Agent Client Protocol – ACP) يحلّ هذه المشكلة. إنه معيار مفتوح قائم على JSON-RPC يتيح لأي وكيل برمجة ذكي التحدث مع أي محرر شيفرة. اعتبره بروتوكول خادم اللغة (LSP) لكن للوكلاء — تنفّذه مرة واحدة فيعمل وكيلك في كل مكان. يشرح هذا الدليل آلية عمل ACP، ويعرض إعدادات حقيقية، ويوضّح لماذا صار من أهم معايير المطورين في 2026.

المشكلة التي يحلّها ACP

قبل ACP كانت منظومة البرمجة بالذكاء الاصطناعي أشبه بتشابك من عمليات الدمج الثنائية المباشرة. كان على كل محرر بناء موصّل مخصّص لكل وكيل، وعلى كل وكيل شحن إضافات لكل محرر. مع وجود عدد N من المحررات و M من الوكلاء، كانت الصناعة مطالَبة بعدد N × M من عمليات الدمج — فوضى تضاعفية تُبطئ الجميع وتحبس المطورين داخل حدائق مسوّرة.

هذه هي المشكلة نفسها التي حلّها بروتوكول خادم اللغة لأدوات اللغات قبل عقد. فبدل أن يبني كل محرر دعم Python و Rust و Go على حدة، عرّف LSP بروتوكولًا واحدًا يجعل خادم لغة واحدًا يخدم كل المحررات المتوافقة. يطبّق ACP الفكرة نفسها على وكلاء البرمجة: عرّف العقد مرة واحدة فينهار عدد N × M إلى N + M.

كيف يعمل ACP

يوحّد ACP التواصل بين دورين:

• العميل (Client) — محرر تفاعلي مثل Zed أو محرر JetBrains أو Neovim أو Emacs أو حتى دفتر مثل marimo.
• الوكيل (Agent) — برنامج يستخدم الذكاء التوليدي لقراءة الشيفرة والتفكير فيها وتعديلها ذاتيًا، مثل Claude Code أو Gemini CLI.

يتواصل الطرفان عبر JSON-RPC 2.0، عادةً عبر تيارَي الدخل والخرج القياسيين لعملية الوكيل الفرعية. يُطلق المحرر الوكيل كعملية ابنة فيتبادلان رسائل منظّمة. ولأن النقل يجري عبر stdio فلا منافذ لإدارتها ولا خوادم لنشرها ولا إعداد شبكي — يعمل الوكيل محليًا بجانب محررك.

دورة حياة الرسائل

تتبع جلسة ACP نموذجية تدفقًا متوقّعًا:

1. التهيئة (Initialize) — يتبادل العميل والوكيل المصافحة، ويتفاوضان على protocolVersion ويعلنان قدراتهما. النسخة المستقرة الحالية من البروتوكول هي 1، وتُحدَّد التوافقية بهذه القيمة المتفاوَض عليها لا بأرقام نسخ الحزم.
2. المصادقة (Authenticate) — إن كان الوكيل يحتاج بيانات اعتماد يوفّرها العميل.
3. إنشاء الجلسة — يستدعي العميل session/new لبدء محادثة ذات حالة مرتبطة بمجلد عمل.
4. التوجيه (Prompting) — يرسل العميل طلب المستخدم عبر session/prompt، حاملًا التعليمة مع السياق المناسب.
5. التحديثات المتدفّقة — أثناء عمل الوكيل يبثّ إشعارات session/update إلى المحرر: نصوص التفكير واستدعاءات الأدوات وفروقات الملفات والتقدّم. يعرضها المحرر فوريًا مع تلوين الصيغة و«متابعة الوكيل» فتشاهد العمل وهو يجري.
6. طلبات الإذن — قبل أي إجراء حساس يستدعي الوكيل session/request_permission فيطلب المحرر منك الموافقة أو الرفض، ما يُبقي الإنسان في الحلقة للعمليات الخطرة.

الوصول إلى الملفات والطرفية

والأهم أن الوكيل لا يلمس نظام ملفاتك مباشرة، بل يطلب من المحرر القيام بذلك عبر طرق البروتوكول مثل fs/read_text_file و fs/write_text_file. هذا خيار تصميمي مقصود: فالمحرر يملك أصلًا مخازنك غير المحفوظة ومراقبات الملفات وسجل التراجع. توجيه عمليات الملفات عبر العميل يعني أن الوكيل يرى ما تراه تمامًا، وأن كل تغيير يمرّ عبر آلية المراجعة والتراجع المعتادة في المحرر بدل تعديل الملفات خلف ظهرك.

إعداد وكيل ACP

لأن البروتوكول موحّد، فإن ربط وكيل جديد يقتصر غالبًا على إخبار محررك بكيفية تشغيله. في Zed توضع الوكلاء الخارجيون المخصّصون تحت مفتاح agent_servers في settings.json:

{
  "agent_servers": {
    "my-agent": {
      "type": "custom",
      "command": "node",
      "args": ["~/projects/agent/index.js", "--acp"],
      "env": {}
    }
  }
}

الحقول بسيطة: command هو الملف التنفيذي، و args وسائط التشغيل (هنا نمرّر علم --acp ليبدأ البرنامج بوضع البروتوكول)، و env لحقن متغيرات البيئة مثل مفاتيح الواجهات البرمجية. بمجرّد الحفظ يظهر الوكيل في لوحة الوكلاء وجاهز لاستقبال الأوامر. وتتبع محررات JetBrains و Neovim و Emacs النمط نفسه عبر واجهات إعدادها.

بناء وكيل ACP

إن كنت في الجهة الأخرى — تبني وكيلًا لا تستهلكه — فهناك حزم تطوير رسمية للّغات التي تستخدمها على الأرجح:

• Rust عبر حزمة agent-client-protocol
• TypeScript عبر حزمة @agentclientprotocol/sdk على npm
• وتتوفّر كذلك حزم لـ Python و Java و Kotlin

تتولّى الحزمة سباكة JSON-RPC — تأطير الرسائل ومطابقة الطلب بالاستجابة وتوزيع الإشعارات — فتنفّذ أنت المعالِجات المهمّة: الاستجابة لـ initialize، وقبول session/prompt، وبثّ إشعارات session/update أثناء تفكير النموذج، وطلب الإذن قبل الإجراءات المدمّرة. سطح البروتوكول صغير بما يكفي ليتّسع وكيل بسيط في بضع مئات من الأسطر، ومعبّر بما يكفي لدعم تدفّقات عمل وكيلية كاملة.

سجلّ ACP: نفّذ مرة واحدة ووزّع في كل مكان

البروتوكول نصف القصة، والنصف الآخر هو الاكتشاف والتوزيع. في 28 يناير 2026 أطلق المشروع سجلّ ACP (ACP Registry) لسدّ هذه الفجوة.

قبل السجلّ كان حتى الوكيل المتوافق مع ACP يواجه صداع التوزيع: على المطوّرين نشره كإضافة منفصلة لكل عميل، أو الطلب من المستخدمين تثبيته يدويًا. السجلّ يمركز هذا. يتبع مؤلّف الوكيل دليل التقديم ويفتح طلب دمج إلى مستودع السجلّ، ومن هذا الإجراء الواحد يصبح الوكيل متاحًا عبر كل عميل متوافق.

أما على جانب الاستهلاك فيأتي Zed بصفحة سجلّ ACP مدمجة لتصفّح الوكلاء وتثبيتها، وأضافت محررات JetBrains القدرة نفسها عبر شراكة مستمرّة. تصفّح، اضغط تثبيت، وستملك دائمًا أحدث نسخة. يضمّ السجلّ بالفعل Claude Code و Codex CLI و GitHub Copilot CLI و OpenCode و Gemini CLI وقائمة متنامية من غيرها. هذا ما حقّق أخيرًا وعد ACP الأصلي «نفّذ مرة واحدة، يعمل في كل مكان».

علاقة ACP بـ MCP و A2A

من حقّ المطورين المتابعين لمجال معايير الوكلاء أن يسألوا أين يقع ACP بجانب بروتوكول سياق النموذج (MCP) وبروتوكول الوكيل-إلى-وكيل (A2A). إنها متكاملة لا متنافسة:

• MCP يربط الوكيل بـ الأدوات والبيانات — قواعد البيانات والواجهات البرمجية ومخازن الملفات والخدمات الخارجية. يجيب عن سؤال: «ماذا يستطيع الوكيل أن يستخدم؟»
• A2A يربط الوكيل بـ وكلاء آخرين للتفويض والتعاون. يجيب عن: «كيف يتحدث الوكلاء فيما بينهم؟»
• ACP يربط الوكيل بـ المحرر والإنسان الذي يقوده. يجيب عن: «كيف يُظهر الوكيل عمله لي، وكيف أوجّهه؟»

يستطيع وكيل برمجة واحد أن يتحدث الثلاثة معًا: ACP لعرض تفكيره في محررك، و MCP للوصول إلى قاعدة بياناتك، و A2A لتسليم مهمة فرعية لوكيل متخصّص. كل منها يشغل طبقة مختلفة من المكدّس نفسه.

لماذا يهمّ هذا للمطورين والفرق في منطقة الشرق الأوسط

للمطورين في تونس والسعودية ومنطقة الشرق الأوسط الأوسع، يحمل ACP مكسبًا استراتيجيًا يتجاوز الراحة. فلأن البروتوكول يفصل الوكيل عن المحرر، لم يعد اختيارك للوكيل قيدًا طويل الأمد. إن تغيّر التسعير أو قُيّد نموذج بضوابط التصدير أو ظهر وكيل أفضل، فتبدّل السطر في settings.json وتحتفظ بمحررك وذاكرتك العضلية وسير عملك سليمًا.

هذه القابلية للنقل تهمّ في عام صار فيه الوصول إلى نماذج الجبهة المتقدّمة غير متوقّع — مقيَّدًا بضوابط التصدير وموافقات عميل-بعميل وتسعير متغيّر. المحرر الناطق بـ ACP يستطيع التوجيه إلى وكيل جبهة مستضاف اليوم وإلى وكيل مفتوح الأوزان قابل للاستضافة الذاتية غدًا، دون إعادة بناء الأدوات. وللفرق التي توحّد مكدّسها الهندسي، فإن الرهان على البروتوكول المفتوح بدل أي مورّد واحد هو الخيار الأكثر مرونة.

كيف تبدأ

لتجربة ACP في أقل من عشر دقائق:

1. ثبّت محررًا داعمًا لـ ACP مثل Zed أو إصدارًا حديثًا من محررات JetBrains.
2. افتح سجلّ ACP المدمج وثبّت وكيلًا مثل Claude Code أو Gemini CLI.
3. افتح مشروعًا، استدعِ لوحة الوكلاء، وأرسل أمرًا — وشاهد التحديثات المتدفّقة ووافِق على الإجراءات حين تظهر.
4. وحين تريد وكيلًا مخصّصًا، أضف إدخال agent_servers يشير إلى ملفك التنفيذي.

الخلاصة

يفعل ACP لوكلاء البرمجة الذكية ما فعله LSP لذكاء اللغات: يحوّل فوضى متشابكة من عمليات الدمج الثنائية إلى معيار مفتوح ونظيف يفيد الجميع. المحررات تنال الوصول إلى كل وكيل، والوكلاء يصلون إلى كل محرر، والمطورون ينالون حرية اختيار أدواتهم وتبديلها بلا ألم مع إبقاء الإنسان راسخًا في الحلقة. في مشهد وكلاء سريع التغيّر في 2026، ليست هذه القابلية للنقل رفاهية — بل هي الطريقة التي تتجنّب بها الوقوع في رهان خاطئ.