---
service: "Publicasta"
schema_version: "1.0"
article_id: 766
title: "October Bus يفتح طبقة لتنسيق وكلاء البرمجة — ما الذي أصبح جاهزاً للاختبار"
language: "ar"
default_language: "en"
canonical_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=ar"
json_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=ar"
api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/october_bus_open_source_agent_coordination?lang=ar"
channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar"
channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-10-05T06:49:03+00:00"
updated_at: "2026-10-05T06:49:03+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=ar"
    markdown_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=ar"
    json_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=de"
    markdown_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=de"
    json_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=en"
    markdown_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=en"
    json_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=es"
    markdown_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=es"
    json_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=fr"
    markdown_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=fr"
    json_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=pl"
    markdown_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=pl"
    json_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=ru"
    markdown_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=ru"
    json_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination?lang=zh"
    markdown_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.md?lang=zh"
    json_url: "https://publicasta.com/open_source_radar/october_bus_open_source_agent_coordination.json?lang=zh"
---

# October Bus يفتح طبقة لتنسيق وكلاء البرمجة — ما الذي أصبح جاهزاً للاختبار

> يفصل October Bus تنسيق الوكلاء عن بيئة البرمجة نفسها. يتيح وقت تشغيل محلياً، وبروتوكولاً أولياً، ومهاماً دائمة، وإيصالات، وترخيص Apache 2.0، لكن الواجهات ما زالت غير مستقرة وحدود الأمان لا تتجاوز التنفيذ المحلي.

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

 ![ثلاثة أجهزة عمل للبرمجة متصلة بالكابلات بجهاز شبكة مركزي صغير في مساحة عمل مضاءة بإضاءة دافئة.](https://publicasta.com/storage/projects/10/pages/766/2026/10/3bb25dab-6ec1-4698-a3ab-7f069fdfd34c.webp)

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

 وهذا هو الفارق الأهم في الإصدار. October Bus ليس نموذج برمجة آخر، ولا واجهة طرفية جديدة، ولا مشرفاً مستقلاً. إنه مجموعة بدائيات للتنسيق. وقت التشغيل المحلي، وخادم Go، وعميل TypeScript، وأدوات MCP، ومخزن SQLite، والمواصفة الأولية 0.1 كلها قابلة للتشغيل، بينما يحذر المشروع صراحة من أن واجهات البروتوكول والحزم قد تتغير قبل الوصول إلى إصدار مستقر.

 ## المشكلة التي يحاول October Bus حلها فعلاً

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

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

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

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

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

 ## ما الموجود في المستودع المفتوح

 يصف مستودع October Bus أربع طبقات مهمة لمن يريد تقييمه. الأولى هي سطح البروتوكول: مواصفة أولية 0.1، وعقد HTTP، ومواءمة MCP، وعقد للمحوّلات، ومخططات JSON. ومن المفترض أن تكون إصدارات البروتوكول مستقلة عن إصدارات وقت التشغيل وحزم SDK، وهو أمر منطقي إذا كان متوقعاً أن تتبنى بيئات تشغيل مختلفة لغة التنسيق نفسها بسرعات مختلفة.

 الثانية هي وقت التشغيل المرجعي المحلي. يقول المشروع إن خادم Go، وعميل TypeScript، ومخزن SQLite الدائم، وأدوات MCP، والاختبارات قابلة للتشغيل اليوم. ولهذا التشغيل المحلي أولاً أهمية عملية. يستطيع المطور دراسة السلوك والتجربة من دون الوثوق أولاً بخدمة تنسيق مستضافة أو جعل حساب سحابي مركز سير العمل.

 الثالثة هي بدائيات التنسيق نفسها:

 - **الهوية والاكتشاف:** لكل وكيل هوية مستقرة، ويمكنه إعلان قدراته وتوافره.
- **الحضور:** يُعامل الوجود والاستعداد وإمكانية الوصول ودورة الحياة كحقائق منفصلة، لا كإشارة واحدة متصلة أو غير متصلة.
- **المراسلة:** الإشعارات والطلبات والردود وصناديق الوارد والإيصالات سجلات دائمة.
- **التفويض:** يستطيع وكيل أن يطلب من وكيل آخر تنفيذ عمل محدود.
- **المهام المشتركة:** يستطيع البشر والوكلاء إضافة العمل، واستلامه، والإبلاغ عن التقدم، وتحريره، وإتمامه، وإعلان تبعياته.
- **التصعيد البشري:** يستطيع الوكيل طلب رأي أو إذن بدلاً من اختلاق إجابة.
- **المراقبة:** يستطيع أصحاب النطاق متابعة الأحداث المرتبة من دون جمع كل آثار الاستدلال الخاص.

 أما الطبقة الرابعة فهي فكرة المحوّل. يفترض أن يعمل October Bus أسفل منطق توزيع الأدوار وسير العمل الخاص بالمنتج. يربط المحوّل بيئة التشغيل بـ Bus، بينما تظل البيئة مسؤولة عن استدعاءات النموذج وأدواتها ومعالجة السياق وصلاحياتها. وهذا الفصل هو أقوى حجة للمشروع كمصدر مفتوح: يمكن لعقد التنسيق أن يصبح بنية مشتركة حتى لو استخدم المطورون بيئات تشغيل مختلفة.

 يوضح مستودع October Harness شكل التكامل في الواقع. يمكن تشغيله تفاعلياً في طرفية، أو كعملية طباعة لمرة واحدة، أو في وضع JSON، أو عبر RPC، أو كـ SDK مضمّن. تكامله مع Bus مقيد بالتنفيذ: يمرر المشغّل عنواناً، ونقطة نهاية MCP، وهوية الوكيل، وهوية التنفيذ، ورمزاً، ولا يسجل أدوات Bus والخطافات إلا عند وجود إعداد صالح. يجعل ذلك التكامل أكثر واقعية من وعد في ملف README، لكنه لا يثبت بعد توافقاً مع بيئات تشغيل لا علاقة لها به.

 ## التسليم الدائم أهم من الدردشة

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

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

 قد تبدو هذه التفاصيل إدارية، لكنها الموضع الذي تصبح فيه أنظمة الوكلاء المتعددة غير موثوقة عادة. فمن دون منع التكرار قد تنشئ إعادة المحاولة مهام مكررة. ومن دون تأكيد صريح لا يستطيع المرسل التمييز بين «لم ترها العملية قط» و«رأتها العملية ولم تتصرف بعد». ومن دون انتهاء صلاحية قد يُنفذ طلب قديم بعد تغير الكود أو القرار المحيط به. ومن دون دلالات الملكية والتحرير قد يعتقد وكيلان معاً أنهما مسؤولان عن العمل نفسه.

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

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

 ## نموذج الأمان محدود عمداً

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

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

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

 والحدود لا تقل أهمية. October Bus ليس صندوق عزل لنظام التشغيل، ولا يجعل تشغيل وكيل برمجة على مستودع غير موثوق آمناً. توضح وثائق October Harness أن عمليات وكيل البرمجة المحلية تعمل بصلاحيات نظام التشغيل للمستخدم الذي يبدأها، وتوصي باستخدام حاوية أو آلة افتراضية أو micro-VM أو صندوق عزل تتحكم فيه السياسات عند التعامل مع عمل غير موثوق أو غير مراقب. كما يجب التعامل مع الامتدادات والمهارات والمطالبات والحزم التابعة لجهات أخرى بوصفها كوداً وتعليمات قابلة للتنفيذ.

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

 ## لماذا يهم ترخيص Apache 2.0

 مرخص October Bus بموجب Apache 2.0. يقول المستودع إن الترخيص المتساهل مقصود حتى يستطيع مطورو الوكلاء وبيئات التشغيل، بما في ذلك المنتجات التجارية، تبني البروتوكول وتطبيقه. ويغطي الترخيص الكود والوثائق الموجودة في المستودع، لا أسماء October أو شعاراتها أو أصول علامتها التجارية.

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

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

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

 ## ما الجاهز للاختبار الآن

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

 يبدو اختبار محلي نموذجي هكذا:

 ```text
المخطط  -> يكتشف وكيل البناء ووكيل المراجعة
البناء  -> يستلم مهمة التنفيذ
البناء  -> يطلب مراجعة تغيير محدود واحد
المراجع -> يستلم مهمة المراجعة ويبلغ عن التقدم
المراجع -> يعيد النتائج في رد مرتبط بالطلب
البناء  -> يؤكد النتيجة أو يصعّدها إلى إنسان
```

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

 يوثق مستودع October Harness مثالاً محلياً متعدد اللاعبين يبدأ فيه Bus مثبتاً وعملية عاملي SDK بهويتين منفصلتين. قد تتغير الأوامر الدقيقة وإعدادات التشغيل ما دام المشروع غير مستقر، ولذلك ينبغي أخذها من المستودع الحالي لا نسخها إلى دليل تشغيل طويل العمر. والنتيجة المهمة للاختبار ليست قدرة طرفيتين على تبادل النص. بل بقاء المهمة قابلة للنسبة والاسترجاع عبر حدود العمليات.

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

 في أول تقييم، سجّل على الأقل الملاحظات التالية:

 - كم يستغرق اكتشاف قرين والتحقق من قدرته المعلنة؟
- هل يستطيع المرسل التمييز بين الحفظ والتسليم والتأكيد وانتهاء الصلاحية والرد المتأخر؟
- هل يحرر العامل المنهار مطالبته بالمهمة بعد فترة الإيجار المتوقعة؟
- هل يستطيع وقت التشغيل المستقبِل تنفيذ الطلب من دون تلقي سياق خاص غير ذي صلة؟
- هل يستطيع الإنسان رفض عملية مقترحة أو تعديلها من دون أن يتجاوز القرين ذلك القرار؟
- هل يمكن ترقية النظام من دون إبطال الرسائل أو سجلات المهام المخزنة؟
- هل تكفي السجلات لإعادة بناء ما حدث من دون جمع استدلال النموذج؟

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

 ## من ينبغي أن ينتبه

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

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

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

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

 ## البدائل والمشاريع المجاورة

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

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

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

 لذلك فالمقارنة المفيدة ليست «أي وكيل أذكى؟» بل «أين توجد حالة التنسيق، ومن يستطيع رؤيتها، وكيف يثبت العامل أنه ما زال مالك العمل؟». يحاول October Bus جعل هذه الأسئلة صريحة عبر بيئات التشغيل.

 ## خطر المصدر المفتوح هو انحراف البروتوكول

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

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

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

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

 ## الخلاصة

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

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

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

 ## المصادر

 [مستودع October Bus والمواصفة الأولية](https://github.com/october-dev/october-bus)، [مستودع October Harness ووثائق التكامل](https://github.com/october-dev/october-harness)، [حدود أمان التنفيذ المحلي في Pi](https://github.com/earendil-works/pi/security)، [وثائق وكيل البرمجة Pi وترخيص MIT](https://github.com/pi-packages/earendil-works-pi/blob/main/packages/coding-agent/README.md).