بروتوكول ACP: اختر وكيل البرمجة واحتفظ بمحررك

يتيح لك بروتوكول ACP، واسمه الكامل Agent Client Protocol، تبديل وكيل البرمجة مع الاحتفاظ بمحررك، ما دام الطرفان يدعمان البروتوكول. ومع إصدار Rabbit 2 من Android Studio، أصبح هذا الخيار عمليًا لمطوري Android: فقد أعلنت Google في أكتوبر إتاحة أكثر من 40 وكيل برمجة، مع إمكانية اختيار الوكيل من داخل بيئة التطوير. الفائدة هنا واضحة: تحتفظ ببيئة عملك وتختار الوكيل الذي ينفذ المهمة.

يرد هذا العدد في إعلان Google عن Android Studio بتاريخ 28 أكتوبر 2026. وقد جرى التحقق من تفاصيل الدعم والإعداد الواردة أدناه بالرجوع إلى موقع البروتوكول ووثائق المحررات في 3 نوفمبر 2026. يستند هذا الدليل إلى الوثائق، ولا يقدم اختبار أداء عمليًا للوكلاء.

ما الذي يغيّره بروتوكول ACP؟

يوفر ACP واجهة مشتركة بين المحررات ووكلاء البرمجة لتبادل المطالبات وتحديثات التقدم وطلبات الأذونات والنتائج. الوكيل برنامج يستعين بنموذج وأدوات ودورة عمل لتنفيذ مهمة. أما المحرر، أو بيئة التطوير المتكاملة (IDE)، فهو المكان الذي تفحص فيه الشيفرة وتراجع التغييرات وتتفاعل مع ذلك البرنامج.

أقرب تشبيه هو Language Server Protocol (LSP)، الذي وحّد طريقة الاتصال بين المحررات وخوادم اللغات. يوفر خادم اللغة قدرات خاصة بلغة البرمجة، مثل تشخيص الأخطاء. ويطبق ACP الفصل نفسه على وكلاء البرمجة: ينفذ المحرر طرف العميل في الاتصال، بينما يدعم الوكيل ACP مباشرة أو عبر مهايئ. ولا بد من توافق الطرفين. وتصف مقدمة ACP الفكرة بأنها تلغي الحاجة إلى بناء تكامل مخصص لكل اقتران بين محرر ووكيل.

إذا كنت تتنقل بين Claude Code من Anthropic وCodex من OpenAI وGemini CLI من Google، فالمكسب هو ثبات مساحة العمل. يمكنك تقييم وكيل آخر من دون إدخال المحرر نفسه ضمن عملية الانتقال. لكن طرق تكامل هذه الوكلاء مع ACP تظل مختلفة، كما توضح قائمة الدعم أدناه.

من أطلق ACP؟

أنشأت Zed Industries بروتوكول ACP، وتعاونت مع Google ليكون Gemini CLI أول تطبيق مرجعي له. وأعلنت Zed هذا التعاون في 27 أغسطس 2025. ثم انضمت JetBrains إلى الجهود؛ وتصف صفحتها الحالية البروتوكول بأنه يُطوَّر بصورة مفتوحة على يد JetBrains وZed. أما Google فهي شريك مبكر في التطبيق، وتتبنى البروتوكول من خلال Android Studio. ويوضح منشور الإطلاق من Zed وصفحة ACP لدى JetBrains هذه الأدوار المختلفة.

هذا التمييز مهم عند تقييم الدعم. فإنشاء البروتوكول، وصيانة مهايئ، وإتاحة عميل داخل محرر، مساهمات منفصلة.

ما المحررات والوكلاء التي تدعم ACP؟

توفر Zed وبيئات JetBrains وAndroid Studio طرقًا موثقة لاستخدام وكلاء ACP. وتعتمد محررات أخرى على إضافات أو امتدادات، لذا تحقق من التكامل الذي ستثبته فعليًا. وجود إدخال في الدليل يثبت وجود تكامل، لكنه لا يضمن أن جميع الميزات تعمل بالطريقة نفسها.

ترد أسماء الإضافات أعلاه كما يسميها دليل عملاء ACP. أما تفاصيل Zed وJetBrains وAndroid Studio فمصدرها وثائقها المشار إليها أدناه. وهذه مجموعة مختارة تناسب سير عمل البرمجة، وليست قائمة شاملة بكل عملاء ACP.

الوكلاء الخارجيون في Zed لهم إعداداتهم الخاصة

تعرض Zed وكلاء ACP في Agent Panel وThreads Sidebar. وتذكر وثائقها الحالية Claude وCodex وOpenCode وCopilot وCursor وPi ضمن الوكلاء الخارجيين الشائعين، كما توفر إرشادات لإعداد Gemini CLI. وطريقة التثبيت الأساسية هي ACP Registry. وتشرح وثائق الوكلاء الخارجيين في Zed خطوات التثبيت والجهة التي تتبع لها الإعدادات.

القيد العملي هنا يتعلق بانتقال الإعدادات. فلا تتحول ملفات تعريف Zed Agent ولا Zed Skills تلقائيًا إلى إعدادات للوكيل الخارجي. وعند توثيق إعداد فريقك، سجّل التعليمات وبيانات الاعتماد والأدوات الخاصة بالوكيل نفسه.

JetBrains: تحقق من قيود المؤسسة وبيئة التشغيل

يتيح JetBrains AI Assistant وكلاء ACP عبر AI Chat. ويمكن تثبيت وكيل من Settings > Tools > AI Assistant > Agents، أو إضافة وكيل مخصص باستخدام acp.json. وتوضح الوثائق أيضًا أن وكلاء ACP غير مدعومين حاليًا في Windows Subsystem for Linux (WSL)، وأن المسؤولين يستطيعون تقييد إدخالات السجل أو الوكلاء المخصصين. وتُعد وثائق ACP لدى JetBrains المرجع لهذه القيود.

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

دعم الوكلاء: ما الفرق بين الدعم الأصلي والمهايئات؟

يسمي دليل وكلاء ACP التكاملات المعنية بدقة:

• يُدرج Claude Agent عبر مهايئ SDK من Zed. هذا هو الاسم الذي يستخدمه الدليل لتكامل Claude، ولا يعني أن واجهة Claude Code CLI نفسها تدعم ACP دعمًا أصليًا.
• يُدرج Codex CLI عبر مهايئ ACP. أدرج هذا المهايئ ضمن المكونات التي تتتبعها لمعرفة ما يشغله المحرر.
• يُدرج Gemini CLI بوصفه وكيلًا يطبق البروتوكول، من دون الإشارة إلى مهايئ.
• يُوسم GitHub Copilot صراحة بأنه في المعاينة العامة على تلك الصفحة.

وتسرد الصفحة نفسها Augment Code وCline وCursor وcagent من Docker وFactory Droid وGoose وHermes Agent وJunie من JetBrains وKimi CLI وKiro CLI وMistral Vibe وOpenCode وOpenHands وQwen Code. أما Pi فيُدرج عبر مهايئ pi-acp. هذه إدخالات مختارة بأسمائها الواردة في الدليل؛ وتتوفر القائمة الكاملة في الصفحة المرتبطة.

لا تتعامل مع ذلك الدليل بوصفه مقياسًا شاملًا للتوافق مع المحررات. فصلاحية التركيبة للاستخدام تعتمد على الوكيل، ومهايئه إن لزم، وتكامل المحرر، والقدرات التي يتفق الطرفان على دعمها.

ماذا تتيح Bring Your Own Agent في Android Studio؟

يتيح لك Android Studio اختيار وكيل البرمجة مع الاحتفاظ بأدوات تطوير Android. ويذكر إعلان Google عن الإصدار المستقر Claude Agent وCodex وJunie وGoogle Antigravity، ويقول إن الوكلاء يستطيعون الوصول إلى Android Emulator وأنظمة البناء وLogcat ومهارات Android. وLogcat هو عارض سجلات التطبيقات والنظام في Android. ويوثق إعلان Google عن Rabbit 2 إتاحة هذه الأدوات.

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

ولقائد الفريق الهندسي، تتيح هذه الإمكانية تجربة أولية أكثر فائدة. ثبّت المستودع والمهمة وإجراءات المراجعة، ثم قارن الوكلاء المعتمدين داخل البيئة نفسها. قيّم التعديل الناتج، والأوامر التي طُلب تنفيذها، والأدلة التي يستند إليها الجواب. فنجاح الاتصال وحده لا يعني نجاح التعميم على الفريق.

بدأت بمعاينة وأصبحت الآن مستقرة

قدمت Google ميزة BYOA في معاينة بتاريخ 24 سبتمبر 2026، بدءًا من Android Studio Rabbit 2 Canary. وفي 28 أكتوبر 2026، أعلنت الإصدار المستقر من Rabbit 2، بما فيه BYOA. ويحل الإعلان الأحدث محل وصف الميزة بأنها في المعاينة في منشور الإطلاق. إعلان المعاينة، إعلان الإصدار المستقر.

اربط وصف «المعاينة» بالمكوّن المحدد الذي يحمله. فاستقرار إصدار Android Studio لا يلغي وصف وكيل آخر بأنه في المعاينة العامة، ولا يضمن تكافؤ ميزات المهايئ.

كيف تعمل جلسة ACP؟

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

تسير الجلسة وفق تسلسل واضح:

1. التشغيل والتفاوض. يشغّل المحرر الوكيل أو المهايئ ويرسل initialize. ويتبادل الطرفان إصدارات البروتوكول والقدرات المدعومة.
2. المصادقة عند الحاجة. أكمل طريقة المصادقة التي يعلن الوكيل عن دعمها. فنجاح الاتصال بالمحرر لا يمنحك حسابًا لدى الوكيل.
3. بدء المحادثة. يرسل المحرر session/new مع مجلد العمل وأي خوادم MCP يوفرها. ويعيد الوكيل معرّفًا للجلسة.
4. إرسال المهمة وتلقي تحديثات التقدم. يرسل المحرر session/prompt، ويبلّغ الوكيل عن الرسائل ونشاط الأدوات عبر إشعارات session/update.
5. التعامل مع الإجراءات المطلوبة. عندما يطلب الوكيل إذنًا، يعرض المحرر الخيارات المتاحة ويرسل القرار إليه. وتنتهي دورة التفاعل في النهاية برد يوضح سبب توقفها.

هذا هو تدفق الرسائل وهذه هي قواعد إنشاء الجلسات كما توثقها المواصفات. والجلسة هي محادثة الوكيل بسياقها وحالتها الخاصين، وليست ملف محادثة موحدًا تتشاركه جميع الشركات المزودة.

تعديل الملفات وتشغيل أوامر الطرفية

الوصول إلى الملفات والطرفية من القدرات التي يتفاوض الطرفان على دعمها. وعند توفر الدعم، يستطيع الوكيل استخدام fs/read_text_file للقراءة عبر المحرر، بما يشمل التغييرات غير المحفوظة، واستخدام fs/write_text_file للكتابة من خلاله. وتظهر أهمية ذلك عندما يختلف محتوى الملف المفتوح على شاشتك عن نسخته المحفوظة على القرص. مواصفات نظام الملفات في ACP.

أما للأوامر، فتطلب terminal/create من العميل بدء عملية. وتتيح طرق مرتبطة بها جلب المخرجات، وانتظار الاكتمال، وإيقاف الأمر، وتحرير موارد الطرفية. وعلى الوكيل التحقق من أن العميل أعلن دعم الطرفية قبل استخدام هذه الطرق. مواصفات الطرفية في ACP.

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

ACP vs MCP: ما الفرق في وظيفة الاتصال؟

يربط ACP المحرر بالوكيل، بينما يربط Model Context Protocol (MCP) تطبيق الذكاء الاصطناعي أو الوكيل بالأدوات والبيانات. ويمكن أن يعملا معًا في الجلسة نفسها. تستند هذه المقارنة إلى مواصفات جلسات ACP ومقدمة MCP.

عند غياب أداة، افحص اتصال الأدوات إلى جانب اتصال المحرر. فمثلًا، توفر JetBrains إعدادات منفصلة لتمرير خوادم MCP المخصصة وخادم IntelliJ MCP المدمج فيها إلى الوكلاء. ودعم ACP وحده لا يفعّل جميع الأدوات. وتوثق إعدادات السجل لدى JetBrains عناصر التحكم هذه.

إذا كنت تصمم حدود الخدمة الأساسية، فإن مقارنة MCP وAPI تتناول قرارًا مختلفًا: كيف تتيح وظائف التطبيق. أما إذا كنت تبني تطبيقًا يعتمد على وكلاء البرمجة، فيشرح دليل مهايئ ACP في Vercel AI SDK طبقة التكامل تلك.

كيف تربط Claude Agent بـAndroid Studio؟

استخدم محدد الوكلاء في Android Studio وأكمل المصادقة لدى مزود الوكيل. وتبدأ طريقة الإعداد الحالية لدى Google من نافذة الوكلاء أو Settings > Tools > AI > Agents. وتنص تعليمات الإطلاق على تسجيل الدخول أو تقديم مفتاح API، على أن يحدد المزود خطط الحسابات المدعومة. طريقة الإعداد الحالية، تعليمات المصادقة.

1. 1

   استخدم إصدارًا يدعم BYOA

   استخدم الإصدار المستقر من Android Studio Rabbit 2، أو إصدارًا أحدث تتضمن وثائقه BYOA. فالتعليمات الأصلية التي اشترطت Canary تخص مرحلة إطلاق المعاينة.

2. 2

   اختر Claude Agent

   افتح نافذة الوكلاء واختر Claude Agent. ويمكنك أيضًا اختيار الوكلاء من Settings > Tools > AI > Agents.

3. 3

   أكمل المصادقة الخاصة بالوكيل

   اتبع خطوات تسجيل الدخول إلى الوكيل، أو قدم مفتاح API إذا أتيح هذا الخيار. استخدم الحساب وطريقة الوصول المعتمدين لمشروعك. ويتطلب ربط وكيل آخر المصادقة الخاصة به واستحقاق الوصول إليه.

4. 4

   ابدأ بمطالبة محدودة النطاق

   تنتهي خطوات الإعداد لدى Google بإرسال مطالبة. ومن المهام المناسبة للبداية: «اشرح كيفية بناء هذا المشروع وحدد مهمة الاختبار ذات الصلة. لا تغيّر الملفات». هذه المطالبة نقطة بداية مقترحة، وليست نتيجة اختبار أجراه المزود.

5. 5

   افحص سير العمل قبل توسيع نطاقه

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

إذا فشلت المصادقة، عالج إعداد الحساب أو المفتاح الخاص بالوكيل المختار. وإذا اتصل الوكيل لكنه عجز عن استخدام أداة، فافحص القدرات التي يتيحها ذلك التكامل. هذان موضعان مختلفان للفشل، لذا وثقهما على نحو منفصل في ملاحظات الإعداد.

ما القيود التي ينبغي للفريق الانتباه إليها؟

وحّد طريقة الاتصال، ثم تحقق من سلوك كل وكيل. يزيل البروتوكول تكرار أعمال التكامل، لكنه لا يجعل الوكلاء قابلين للاستبدال في كل تفاصيل التشغيل.

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

استعادة الجلسات مشروطة. تتطلب عملية session/load في البروتوكول دعم الوكيل لقدرة loadSession. ويتيح ذلك تحميل جلسة موجودة حيثما طُبّق هذا الدعم، لكنه لا يثبت أن وكيلًا من مزود مختلف يستطيع وراثة الحالة الخاصة بالوكيل الأصلي. وقبل أن تعد بانتقال سلس، تحقق بدقة من كيفية تعامل تركيبتك مع سجل المحادثة. مواصفات تحميل الجلسات.

الدعم عن بُعد يحتاج إلى التحقق من التطبيق المحدد. تعرّف صفحة النقل الحالية stdio، وتقول إن مواصفات وسيلة نقل Streamable HTTP قيد الإعداد. ويُسمح بوسائل نقل مخصصة. لذلك لا تفترض أن نجاح تكامل محلي يعني أنه يعمل تلقائيًا مع نقطة اتصال لوكيل بعيد. مواصفات النقل في ACP.

طلب الإذن لا يوفّر بيئة تشغيل معزولة

يوفر ACP تنسيقًا لرسائل قرارات الأذونات، لكنه لا يفرض حدود عزل على مستوى نظام التشغيل. تنص المواصفات على أن الوكيل يعمل بصلاحيات العملية الخاصة به، وأن طلبات الأذونات استشارية، وأن مسؤولية احترام القرارات تقع على الوكيل. وينفذ العميل، بصورة منفصلة، طرق نظام الملفات والطرفية المطلوبة من خلال قدراته هو. الاعتبارات الأمنية في ACP.

قد يتيح الطلب خيارات للموافقة أو الرفض لمرة واحدة، أو لتذكر القرار لاحقًا. ويحدد الوكيل نطاق القرارات المحفوظة ومدة استمرارها. اقرأ الخيار المعروض قبل أن تفترض أن «دائمًا» تقتصر على الأمر الحالي أو المجلد الحالي. دلالات خيارات الأذونات.

إذا كنت مسؤولًا عن تشغيل منصة، فتحقق من الملف التنفيذي للوكيل وبيئة التنفيذ وسياسة الأذونات إلى جانب إعداد المحرر. تساعد نافذة الموافقة على إظهار ما يجري، لكن وجودها وحده لا يثبت أن التنفيذ محصور داخل حدود آمنة.

أين تكمن المبالغة، ومن ينبغي له البدء؟

الفائدة التي يمكن التعويل عليها هي تقليل الارتباط بين المحرر والوكيل. فدعم ACP لا يثبت أن الوكيل يكتب شيفرة أفضل، أو أن إعداداته تنتقل من وكيل آخر، أو أن كل اقتران يتيح سير العمل نفسه. قيّم هذه النتائج مباشرة.

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

على قادة الفرق الهندسية إجراء تجربة أولية قبل اعتماد إعداد موحد. ثبّت المهمة ومعايير القبول عند المقارنة بين الوكلاء. وسجّل تفاصيل المصادقة، والأدوات المدعومة، واستعادة الجلسات، وسلوك الأذونات. ابنِ الاختيار على العمل الناتج وإمكانية التحكم فيه، لا على حجم السجل.

على مسؤولي تشغيل المنصات الانتظار عندما لا تكون بيئة لازمة مدعومة. يمثل قيد WSL الموثق لدى JetBrains مثالًا واضحًا. وكذلك فإن اعتماد سير عمل بعيد على سلوك نقل لم يُتحقق منه سبب آخر لاختبار التركيبة قبل تعميمها.

أما المطور المرتاح للعمل من الطرفية، فلن يتغير عليه الكثير. لا يوجد ما يدعو إلى تغيير الواجهة لمجرد وجود بروتوكول. وإذا كان السؤال الذي لم تحسمه هو أي الوكلاء أنسب لعملك، فاستعن بـمقارنة Codex وClaude Code لتحديد معايير الاختيار، ثم اختبرها على مستودعك.

أسئلة شائعة

ما هو بروتوكول Agent Client Protocol؟

Agent Client Protocol هو الواجهة المشتركة بين وكيل البرمجة والمحرر أو أي عميل آخر. ويتيح للتطبيقات المتوافقة تبادل المطالبات وتحديثات التقدم والإجراءات، من دون بناء تكامل مخصص منفصل لكل اقتران.

ما الفرق بين ACP وMCP؟

يتولى ACP الاتصال بين المحرر والوكيل. ويربط MCP تطبيق الذكاء الاصطناعي أو الوكيل بالأدوات والبيانات الخارجية. ويمكن لجلسة ACP توفير إعدادات خوادم MCP، لذا يستطيع البروتوكولان المشاركة في سير العمل نفسه.

ما الفرق بين A2A وMCP؟

يوحّد Agent2Agent (A2A) الاتصال بين الوكلاء المستقلين. أما MCP فيربط تطبيقات الذكاء الاصطناعي بالقدرات والبيانات الخارجية. يعالج A2A تعاون الوكلاء، بينما يعالج ACP موضوع هذا المقال الاتصال بالمحرر. راجع شرح مشروع A2A.

هل يدعم Claude Code بروتوكول Agent Client Protocol؟

الإدخال الدقيق في الدليل هو Claude Agent عبر مهايئ SDK من Zed. استخدم التكامل المدعوم الذي توثقه جهة المحرر؛ ولا تفسر ذلك الإدخال على أنه دعم أصلي لـACP في كل ملف تنفيذي من Claude Code. وتوثق Zed الوكيل Claude Agent بوصفه وكيلًا خارجيًا له مصادقته الخاصة.

هل ما زال Claude Code أفضل وكيل برمجة؟

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

من طوّر بروتوكول Agent Client Protocol؟

أنشأت Zed بروتوكول ACP وتعاونت مع Google ليكون Gemini CLI أول تطبيق مرجعي له. ثم انضمت JetBrains إلى الجهود، وتصف وثائقها الحالية ACP بأنه يُطوَّر بصورة مفتوحة على يد JetBrains وZed.

ما الفرق بين Agent Client Protocol وAgent Communication Protocol؟

هما مشروعان مختلفان يشتركان في الاختصار. يربط Agent Client Protocol المحررات بوكلاء البرمجة. أما Agent Communication Protocol من IBM فكان يعالج الاتصال بين الوكلاء؛ وتقول IBM Research الآن إنه جزء من A2A.

كيف يعمل ACP؟

في الجلسة المحلية، يشغّل المحرر الوكيل كعملية فرعية ويتواصل معه باستخدام JSON-RPC عبر stdio. ويتفاوض الطرفان على القدرات، ويكملان أي مصادقة مطلوبة، ويفتحان جلسة، ثم يتبادلان المطالبات والتحديثات وقرارات الأذونات.

ماذا يعني ACP في الذكاء الاصطناعي القائم على الوكلاء؟

في سياق التكامل مع المحررات، يشير ACP عادة إلى Agent Client Protocol. تحقق من الاسم الكامل عند قراءة بنية نظام أو اختيار مكتبة، لأن اختصار Agent Communication Protocol يشير إلى مشروع مختلف.

ماذا تفعل في جلسة العمل التالية؟

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

للحصول على أدلة عملية حول التغييرات في سير عمل التطوير، اشترك في النشرة البريدية.