إعادة كتابة أساس الوكيل: إعادة هيكلة Orkas من الصفر

عندما ينضج منتج قائم على وكلاء الذكاء الاصطناعي، لا تكون الميزات هي الأعلى تكلفة — بل الأساس. تستعرض هذه المقالة إعادة الهيكلة الجذرية التي أجراها Orkas عبر سلسلة إصداراته 1.0 — وهي تجديد شامل لاستدعاء النماذج، وحلقة الوكيل، وتنسيق الوكلاء المتعددين، ومنظومة الأدوات — والمفاضلات وراء كل قرار.

لماذا نغيّر الأساس

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

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

2. كان التنسيق «تخطيطًا ثابتًا». كان الإصدار المبكر محرك خطة/رسم بياني موجّه غير دوري (DAG): يُطلب من النموذج أولًا تقسيم المهمة إلى رسم بياني للخطة، ثم يوزّع المنفّذ العمل وفق الرسم. يبدو ذلك منظمًا، لكن واقع الوكيل شديد الديناميكية — قد تكشف قراءة ملف واحد ضرورة تغيير الاتجاه، وقد تحدّد نتيجة مهمة فرعية الجهة التي تُسند إليها الخطوة التالية. تجميد القرارات في رسم مولّد مسبقًا يعني أن كل حالة «الخطة لا تواكب الواقع» تحتاج إلى معالجة ترقيعية داخل المنفّذ.

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

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

1. جلب مجموعة كاملة من قدرات وكيل البرمجة إلى سطح المكتب

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

المخرج الأساسي لإعادة الهيكلة موجود تحديدًا لجلب هذه المجموعة من القدرات بشكل أصيل إلى عملية Orkas نفسها — بيئة تشغيل وكلاء مستقلة، قابلة للتحميل ديناميكيًا، وتعمل داخل العملية (تُسمّى core-agent في الشيفرة). إنها ليست غلاف دردشة آخر؛ بل محرك وكلاء يتحكم فيه Orkas بنفسه.

كان القرار المعماري الأساسي هو تقسيمها إلى طبقتين:

• طبقة المحرك (حزمة مستقلة): آليات الوكيل الخالصة — حلقة استدعاء الأدوات، وتدفّق الأحداث، وضغط السياق، وتصنيف الأخطاء وإعادة المحاولة، وتجريد المزوّد، وبيئة العزل، وفحص المهارات، والذاكرة، والتطور الذاتي. وهي لا تعرف شيئًا عن أي منطق تطبيقي خاص بـ Orkas: لا تقرأ أدلة بيانات التطبيق، ولا تفهم تنسيق ملفات المحادثات، ولا تتعامل مطلقًا مع الاتصال بين العمليات (IPC).
• طبقة المهايئ (داخل العملية الرئيسية): تربط المحرك بـ Orkas — حفظ الجلسات، والتناوب بين المزوّدين، وأذونات الأدوات، وسجل المهارات، والموصلات، وقاعدة المعرفة، وأدوات التوليد المختلفة. وتحوّل الأحداث الأصلية للمحرك إلى صيغ أحداث Orkas، بحيث لا ترى طبقة التطبيق إلا واجهة مستقرة.

هذا الحد الفاصل بين المحرك والمهايئ هو أصل كل المرونة اللاحقة. يمكن اختبار المحرك وتطويره مستقلًا؛ ويمكن لطبقة المهايئ استيعاب تعقيدات Orkas الخاصة بأمان (التناوب، وفترة التهدئة، والعزل، والأذونات) دون تلويث المحرك. لخّصت مراجعة الفريق المعمارية الأمر في جملة واحدة: هذا تعقيد مبرّر — فلا تدمجوا الطبقتين.

ما مجموعة القدرات فعلًا

امتلاك زمام بيئة التشغيل ليس استعراضًا؛ بل وسيلة لتمكين الوكيل من «خوض العمل الفعلي» على سطح المكتب. تنقسم القدرات تقريبًا إلى أربع مجموعات:

• عمليات ملفات دقيقة وبحث محلي. read_file يدعم القراءة حسب نطاق المحارف ويستخرج النص تلقائيًا من مستندات PDF / Office؛ edit_file ينفّذ استبدالًا دقيقًا من «السلسلة القديمة → السلسلة الجديدة»، ويشترط القراءة قبل أي كتابة؛ write_file يحفظ الناتج ويتتبّع سجلًا له؛ stat_file يتحقق من الحجم؛ search_files يحدّد المواقع بالاسم/نمط glob، grep_files يبحث في المحتوى عبر الملفات. تتيح هذه المجموعة للوكيل «التنقيب في الشيفرة وتعديل الملفات» داخل مساحة عمل حقيقية كالمهندس، بدلًا من الاكتفاء باستيعاب كتل كاملة وإخراجها.
• Bash وأدوات النظام. منفّذ صدفة معزول، مع وضع للتنفيذ في الخلفية (تنفصل المهام الطويلة عن الجولة الحالية، وتُحفظ السجلات في ملف) وضوابط متدرجة حسب المخاطر للعمليات الخطرة. يأتي جانب كبير من قوة الوكيل المكتبي تحديدًا من قدرته على التحكم المباشر في سلسلة أدوات النظام.
• عمّال متعددون بالتوازي. داخل الجولة الواحدة، تعمل أدوات القراءة فقط المستقلة بالتزامن؛ وعلى مستوى المهمة، يستطيع القائد أيضًا توزيع المهام الفرعية المستقلة على عدة عمّال بالتوازي (انظر القسم 3). تنفيذ العمل بالتوازي حيث يكون آمنًا هو مفتاح تقليص «المهام طويلة الأمد» إلى زمن فعلي مقبول.
• استدلال وحل مهام على المدى الطويل. حلقة تستطيع تنفيذ عشرات الجولات المتتالية، وإدارة سياقها بنفسها، والتعافي من الأخطاء، وتجنّب الدوران في المكان — هذا هو الفارق بين «إنجاز عمل معقد» و«الإجابة عن سؤال».

كيف جُعلت جاهزة للإنتاج هندسيًا

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

• نافذة سياق حقيقية + ضغط عند 80% فقط. يقرأ المحرك نافذة السياق لكل نموذج بحجمها الحقيقي (بما في ذلك النماذج ذات نافذة المليون رمز)، ولا يفعّل الضغط إلا عندما يبلغ الاستخدام 80% — بدلًا من البدء احترازيًا عند 60% والتخلّي عن 40% من السياق المفيد. وهناك أيضًا حاجز وقائي لـ«الضغط بلا مكسب»: إذا كان الجزء الأخير المحتفَظ به يملأ النافذة بالفعل (مثل وجود نتيجة قراءة ملف ضخمة جدًا في آخر السياق)، فلن يحرّر الضغط أي مساحة، لذا يكتفي بتسجيل تحذير ويتجاوزه، دون تنفيذ استدعاء تلخيص مهدَر. قدرة المهمة طويلة الأمد على «تذكّر ما سبق» تعتمد على هذا كله.

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

• القراءة قبل الكتابة + التحكم التفاؤلي في التزامن. يجب قراءة الملف قبل تعديله؛ يسجّل المحرك حالة مرجعية للملف المقروء ويتحقق عند التعديل من أنها لم تتغيّر. عندما يعدّل عمّال متوازون الملف نفسه في الوقت ذاته، يتلقى الطرف الذي سبقه الآخر خطأ واضحًا يفيد بأن نسخته «قديمة»، بدلًا من الكتابة فوق تغييرات بعضهم بصمت. مع عمل عدة عمّال بالتوازي في مساحة العمل نفسها، لا غنى عن هذا الضمان.

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

• اكتشاف الحلقات المتكررة. عندما يتكرر استدعاء الأداة نفسه على التوالي، ينبّه المحرك أولًا (في المرة الثالثة)، ثم يوقف التنفيذ إيقافًا صارمًا (في الخامسة)؛ وأي توقيع مختلف يعيد العدّ إلى الصفر — فلا تُصنّف خطأً اختلافات مشروعة مثل التنقل بين الصفحات أو الاستقصاء الدوري. عندما يعلق النموذج، لا يعود يستهلك الرموز بصمت.

• إزالة السقف الصارم لمخرجات الجولة الرئيسية. لم تعد مخرجات الجولة الرئيسية مقيدة بسقف ضئيل، فلا تُقتطع التقارير الطويلة والتعديلات الكبيرة بصمت؛ أما الاستدعاءات المساعدة (الضغط، والتأمل) فما زالت تستخدم سقفًا صغيرًا على نحو احترازي.

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

تجيب هذه التحسينات مجتمعة عن سؤال «لماذا لا نستخدم حزمة تطوير برمجيات جاهزة فحسب»: لأن أقوى قدرات الوكيل المكتبي تقع تحديدًا في الطبقة التي لا تتيحها حزمة التطوير؛ ولجعلها جاهزة للإنتاج، يجب أن تكون الحلقة تحت سيطرتك.

2. إبقاء النموذج متصلًا دائمًا: غلاف المزوّد متعدد الطبقات

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

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

كما أن قرار مكوّن التناوب منضبط، ويتمحور حول الحد الذي يمثله أول حدث محتوى:

• حدوث فشل قبل أن يصدر النموذج أي محتوى فعلي (نص/استدعاء أداة) — يسمح بالانتقال الآمن إلى المرشّح التالي؛
• بمجرد صدور أول حدث محتوى — يتوقف التناوب ويُسمح بتمرير الخطأ إلى الطبقات الأعلى، لأن النموذج ربما نفّذ جولة كاملة بالفعل، وإعادتها ستكرر الآثار الجانبية.

تصنيف الخطأ يحدّد «التناوب، أو عدم التناوب، أو إعادة المحاولة». على مستوى الحساب، حالات الفشل مثل فشل المصادقة، أو عدم كفاية الرصيد، أو تقييد المعدل، أو انتهاء الاشتراك — تُحدَّد لها فترة تهدئة ويجري التناوب؛ أما أعطال الشبكة العابرة، مثل إعادة ضبط الاتصال — فلا فترة تهدئة لها، بل تُعاد المحاولة في موضعها عدة مرات دون الاحتفاظ بحالة؛ بينما تُمرَّر الطلبات غير السليمة، وأخطاء سياسة المحتوى، وأخطاء الخادم 5xx — التي ستفشل بالطريقة نفسها مع مفتاح آخر — مباشرة دون تناوب. فترة التهدئة إشارة مدتها عشر دقائق، داخل العملية وغير محفوظة بصورة دائمة : إنها إشارة قصيرة الأجل فقط، لا تستحق الكتابة إلى القرص عند كل فشل، وإعادة تشغيل العملية هي اللحظة المناسبة تمامًا لإعادة التحقق.

على صعيد «قائمة» المزوّدين، توحّد إعادة الهيكلة ثلاثة أنواع من المصادر في تجريد واحد:

• نموذج لغوي كبير يديره Orkas: وكيل وسيط على الخادم، جاهز للاستخدام بعد تسجيل الدخول، مع تولّي الخادم التوجيه بين نماذج النصوص والصور؛
• استخدام مفتاحك الخاص: مزوّدو النماذج الكبيرة الشائعون ذوو الواجهات القياسية؛
• مهايئات الاتصال الخارجي المباشر: مجموعة نماذج تتطلب اتصالًا مباشرًا أو تتولى فوترتها بنفسها، جرى تكييفها يدويًا لتعمل عبر واجهة المزوّد نفسها.

تظهر كل هذه العناصر للطبقات الأعلى في صورة زوج واحد مستقر (provider, model) — إذ يُخفى التناوب، وفترة التهدئة، والتكييف الخارجي كلها داخل طبقة المهايئ.

3. الدردشة الجماعية للتنسيق: من مخطط خطة DAG ثابت إلى قائد داخل الحلقة

هذا أكثر أجزاء إعادة الهيكلة تطلبًا لتغيير طريقة التفكير.

كان النموذج القديم تخطيطًا ثابتًا: يولّد النموذج أولًا خطة/رسم DAG، ثم ينفّذ المنفّذ وفق الرسم. يزيل النموذج الجديد ذلك الرسم بالكامل ويستبدله بـ تنسيق ديناميكي عبر دردشة جماعية يقوده قائد داخل الحلقة.

والصورة المجازية له هي غرفة دردشة جماعية:

• الـ Commander هو مضيف الغرفة، وليس برمجية وسيطة غير مرئية؛
• الوكلاء العمّال أعضاء أساسيون متساوون في الغرفة؛
• جميع التفاعلات رسائل غير متزامنة، تُدرج في طابور عبر ناقل رسائل واحد فقط (لا يوجد مسار خاص لتوزيع العمل بالتوازي).

«إسناد» القائد ليس @somebody مكتوبًا في النص — فكتابة نموذج لغوي كبير @AgentA في متن النص ليست سوى Markdown من بيانات التدريب، ولا يمكن الوثوق بها. إشارة الإسناد الحقيقية هي استدعاء أداة منظّم، وبعد إعادة الهيكلة تستقر في ثلاثة إجراءات واضحة الدلالة:

• dispatch_to — إرسال وكيل لينفّذ المهمة حتى اكتمالها ويعيد النتيجة، ثم يجمع القائد النتائج في خلاصة. يمكن توزيع عدة مهام مستقلة لتنفيذها بالتزامن.
• run_worker — مهمة فرعية يتولاها القائد بنفسه، وتُعاد نتيجتها بصورة متزامنة؛ العامل المجهول هو «يد» القائد (غير مرئي للمستخدم)، بينما العامل المسمّى متخصص ظاهر.
• hand_off_to — تسليم المحادثة إلى الوكيل؛ ينسحب القائد، ويجيب الوكيل المستخدم مباشرة دون أن يضيف القائد خلاصة في هذه الجولة.

لماذا الدردشة الجماعية بدلًا من منسّق أو شجرة وكلاء فرعيين

تحويل تعدد الوكلاء إلى دردشة جماعية يحقق عدة فوائد لا يتيحها منسّق تقليدي أو شجرة وكلاء فرعيين:

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

كانت مراجعة الفريق المعمارية صريحة بالقدر نفسه في هذه النقطة: ناقل دردشة جماعية مع قائد داخل الحلقة هو بنية تعدد الوكلاء في Orkas؛ وإضافة مسار موازٍ آخر لإسناد العمل إلى وكلاء فرعيين داخل العملية ستخرق المبدأ الثابت القائل «مسار واحد فقط للإسناد عبر الدردشة الجماعية».

الجديد في هذا الإصدار: التسليم التفاعلي

أحدث إضافة في هذا المسار هي تسليم المحادثة التفاعلي إلى الوكيل.

المشكلة ملموسة: يعلّم وكيل من نوع «المعلّم» المستخدم خلال جولة، ويريد المستخدم مواصلة طرح الأسئلة، لكن النظام يعيد زمام الحديث قسرًا إلى القائد، فيضطر المستخدم إلى إعادة-@ ذلك الوكيل في كل سطر.

الحل هو زمام حديث يحدّده الخادم + مستلِم يحدّده النموذج:

• يصبح زمام الحديث حقل حالة دائمًا، يُحفظ عبر عمليات إعادة التحميل، ويستخدم حدث تغيّر الحالة الموجود لإجراء مزامنة تلقائية إلى جميع الواجهات — دون الحاجة إلى نوع حدث جديد.
• بعد أن يستخدم القائد hand_off_to لمنح زمام الحديث لوكيل تفاعلي، فإن رسائل المستخدم اللاحقة «بلا-@» تذهب مباشرة إلى ذلك الوكيل، حتى يعيد الوكيل زمام الحديث من تلقاء نفسه أو يوجّه المستخدم حديثه مجددًا إلى القائد.
• يعيد الوكيل التحكم باستخدام علامة <handback /> ؛ ويتحقق التحليل بصرامة من وجود تطابق حقيقي (حتى لا يُساء فهم <handback عارضة في النص على أنها تسليم للتحكم).
• إذا كان سجل المهام يتضمن عملًا غير مكتمل عند إعادة التحكم، يستأنف القائد العمل من السجل ويواصل.

ويأتي معه أيضًا إصلاح لتجربة الاستخدام — فقاعات حلقة القائد. كانت حلقة القائد «إسناد → قراءة النتيجة → إسناد مجددًا» داخل الجولة الواحدة تُدمج في فقاعة واحدة، بل كانت تقفز إلى الأسفل خارج ترتيبها عند إعادة التحميل. تقسم إعادة الهيكلة الجولة الواحدة إلى مقاطع متعددة عند كل حد فاصل لإسناد مرئي، ويصبح كل مقطع رسالة مستقلة بطابع زمني تصاعدي — للمرة الأولى يستطيع المستخدم رؤية القائد وهو «يكرّر دورة التنسيق»، ويصبح ترتيب إعادة التحميل صحيحًا أيضًا.

وأخيرًا، آليتا أمان تعملان طوال الوقت: الإلغاء الجماعي هو مسار الإيقاف الوحيد لجميع الأطراف (بمجرد أن يضغط المستخدم على «إيقاف»، تُفعّل إشارة الإلغاء لكل عامل، ويشمل ذلك حتى العمّال الفرعيين المجهولين عبر مطابقة احتياطية)؛ وكذلك الآلية المذكورة سابقًا المقاطعة لتوجيه المسار، التي تدمج مداخلة المستخدم أثناء التشغيل في الجولة الحالية.

4. من كتالوج مغلق إلى مضيف مفتوح

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

فككت إعادة الهيكلة بصورة منهجية عدة نقاط اختناق «مغلقة»:

• الحزم الخارجية. يقدم المستخدم عنوان مستودع، ويستضيفه Orkas محليًا مستنسخًا كما هو تمامًا داخل مجلد — دون توحيد بنيته أو إعادة كتابته أو مزامنته مع السحابة مطلقًا (لأنه يحتوي على مجلدات تبعيات تابعة لجهات خارجية). تتولى أداة مستقلة لسطر الأوامر دورة التثبيت والتحديث والتشغيل والإيقاف، وتفحص ما إذا كان على «هيئة مهارة» (يتضمن ملف وصف مهارة) أو على «هيئة أداة سطر أوامر» (يتضمن نقطة دخول قابلة للتنفيذ)، وتكتب البيانات الوصفية في سجل خارج مجلد الحزمة (حتى لا تتعارض معه تحديثات السحب المستقبلية). يمر تثبيت التبعيات بتأكيد من خطوتين وفق مبدأ «اسأل مرة واحدة، ثم تذكّر»؛ وتُنشأ أغلفة وسيطة لنقاط الدخول القابلة للتنفيذ وتُضاف إلى PATH الخاص بأداة bash، ليتمكن النموذج من استدعاء أدوات سطر الأوامر الخارجية هذه مباشرة.

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

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

• MCP يضبطه المستخدم. لم تعد الموصلات دليلًا ثابتًا في الشيفرة. يستطيع المستخدم إضافة أي خادم MCP — بصيغة HTTP بعيدة (منخفضة المخاطر) أو بصيغة عملية فرعية محلية (عالية المخاطر). يمثّل النموذج نفسه واجهة الموافقة (ويُعرض الأمر الذي كتبه المستخدم يدويًا كما هو حرفيًا)، وتُحفظ إعدادات النقل بالكامل، بما فيها الأسرار، في تخزين مشفّر، وتحمل المثيلات المخصصة دائمًا بادئة ثابتة تمنعها من انتحال صفة موصل رسمي في الدليل.

• الجسر العكسي: تمكين الوكلاء الخارجيين على الجهاز من الاطلاع على Orkas بدورهم. هذا هو الجزء الأكثر إثارة للاهتمام. كانت أدوات الوكلاء الخارجيين الموجودة أصلًا على جهاز المستخدم صندوقًا أسود بالنسبة إلى Orkas؛ أما الآن، فعندما يكلّفها Orkas بعمل، يحقن قناة جسر تتيح لها في الاتجاه المعاكس سرد مهارات Orkas وقراءتها وتشغيلها، واستدعاء الموصلات، والبحث في قاعدة المعرفة. يعمل الجسر عبر قناة محلية بين العمليات (دون فتح منفذ شبكي)، وتُوثّق هويته ببيانات اعتماد تُستخدم مرة واحدة، وتكون فريدة لكل تشغيل وتُتلف فور انتهائه. يمر كل استدعاء لموصل له أثر جانبي خارجي عبر مربع حوار لتأكيد المستخدم — لا عبر تخمين لطبيعة القراءة أو الكتابة بناءً على اسم الأداة (وهو ما قد يميل إلى التساهل المفرط)، بل بتأكيد واحد لكل زوج (وكيل، موصل)، مع خيار «السماح دائمًا».

• نهج برمجي للحالات غير الشائعة. تكتسب شجرة قرارات القائد فرعًا جديدًا: عندما لا يوجد وكيل أو مهارة أو موصل مناسب، قيّم إمكانية حل المهمة مباشرة باستخدام bash وبرنامج نصي قصير، ونفّذها في هذا الدور، وتحقق من المخرجات، واعرض اختياريًا تحويلها إلى مهارة مخصصة. يصاحب ذلك تنفيذ bash في الخلفية (تنفصل المهام الطويلة عن الدور الحالي، وتُحفظ السجلات في ملف) ومجلدات يمنح المستخدم صلاحية الوصول إليها.

انفتاح مع استمرار الرقابة

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

• تمر عمليات الملفات دائمًا عبر عزل المسارات (مساحة العمل + المرفقات الحالية + المجلدات التي منح المستخدم الوصول إليها صراحة)، بينما مجلدات بيانات الاعتماد ومجلدات النظام ومجلدات Orkas نفسه لا يمكن منح الوصول إليها;
• تستدعي أوامر bash الخطرة (تسريب البيانات، والحذف المدمّر، وتصعيد الصلاحيات، والمسارات الحساسة) تأكيدًا للصلاحية، مع تقسيم القرار إلى «هذه المرة فقط / لهذا التشغيل / رفض»، ولا تسجل السجلات إلا الفئة والطول — ولا تسجل نص الأمر مطلقًا;
• تثبيت الحزم الخارجية يتوقف بأمان عند الإخفاق ويرفض رفضًا قاطعًا الحزم التي تتضمن روابط رمزية (لمنع استخدام رابط رمزي لإدخال ملفات حساسة من خارج البيئة المعزولة ضمن نطاق القراءة)، ويُقيّد مصدر الاستنساخ بقائمة بروتوكولات مسموح بها؛
• تُشفّر جميع إعدادات النقل والأسرار التي تتضمن بيانات اعتماد عند التخزين، وتُعزل بيانات اعتماد الجسر لكل تشغيل؛
• تزيل النسخة الموزعة المفتوحة المصدر / المستضافة القدرات الحصرية للمضيف وفق قاعدة تقليص.

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

5. ذكاء يتنامى عبر الجلسات: الذاكرة والتطور الذاتي

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

الذاكرة عبر الجلسات تستخدم استرجاعًا هجينًا: بحثًا دلاليًا بالمتجهات + بحثًا بالكلمات المفتاحية (BM25)، تُدمج نتائجهما عبر RRF (دمج مقلوب الرتب) لتجنب إخفاق أي قناة منفردة؛ وتُحفظ في تخزين محلي (مع فهرس للنص الكامل). تأتي الذاكرة بنوعين — ملاحظات الوكيل نفسه وملف تفضيلات المستخدم — ولكل منهما حد أقصى لعدد المحارف، ويُفحصان بحثًا عن تهديدات حقن التعليمات قبل الكتابة، ثم يُحقنان كلقطة ثابتة في تعليمات النظام عند بداية كل دور. لا يخدم نظام الذاكرة بأكمله إلا غرض فهم الوكيل للمستخدم الحالي على نحو أفضل؛ وتبقى البيانات محلية دائمًا، ويمكن للمستخدم عرضها وتحريرها وتصديرها في أي وقت من الإعدادات.

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

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

الفلسفة الهندسية: التعقيد المبرّر — لا تزلْه باسم التبسيط

أجرى الفريق جولات متعددة من مراجعة البنية أثناء إعادة الهيكلة، وظل استنتاج واحد يتكرر ويستحق إبرازه منفردًا: ميّز بين «التضخم التنظيمي» و«التعقيد المبرّر»، ولا تمس إلا الأول.

• استراتيجيات الدمج المتعددة لمحرك المزامنة، وحلقة الوكيل المبنية داخليًا، والغلاف متعدد الطبقات لمزوّد النماذج، وحدود التحكم عن بُعد عبر الهاتف — تبدو هذه الأمور معقدة، لكن لكل طبقة ما يبرر وجودها (اتساق نهائي عبر أجهزة متعددة، وتكامل عميق، وتدوير مفاتيح متعددة، وحد نهائي تقرره متطلبات المنتج). ولن يؤدي «تبسيطها» قسرًا إلا إلى فقدان البيانات وطمس الفصل بين الطبقات.
• ما يستحق التعديل حقًا هو «الوحدات المتحكمة بكل شيء» والتكرار الموضعي: استخراج الدوال النقية عديمة الحالة من ناقل الدردشة الجماعية المتضخم (تجميع التعليمات، وأدوات القائد، ودور سطر الأوامر)، وتوحيد نمط «مربع حوار التأكيد» المكرر عدة مرات في مكوّن مشترك واحد.

ما يدعم هذا النوع من الأحكام هو مجموعة من الضوابط الصارمة المدونة في وثيقة قيود المشروع: الحدود (عملية واحدة، والتواصل بين العمليات IPC هو المسار الوحيد، ولا يمكن تحميل بيئة التشغيل إلا ديناميكيًا)، والطبقات (اتجاه التبعيات لكل طبقة)، ومصدر الحقيقة الوحيد (الفئات، وتصنيف بيانات القياس، والنطاقات)، و«تدقيق للتعليمات» إلزامي مع كل إيداع برمجي يمس التعليمات الموجهة للنموذج. ما يتيح إعادة بناء الأساس دون انهياره ليس تصميمًا بارعًا ما — بل الالتزام المستمر بهذه الثوابت.

ختام

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

• بيئة تشغيل داخل العملية بطبقتين، محرك ومحوّل، تجلب مجموعة كاملة من نقاط قوة وكلاء البرمجة — عمليات الملفات، والبحث المحلي، وأدوات النظام، وعمال متعددون متوازون، وحل المهام الممتدة — إلى سطح المكتب بصورة أصلية، وتجعل كلًا منها جاهزًا للاستخدام الفعلي؛
• طبقة نماذج متعددة المستويات تُبقي المحادثة مستمرة قدر الإمكان خلال اضطرابات المفاتيح والمزوّدين والشبكة؛
• تنسيق متعدد الوكلاء على هيئة دردشة جماعية يشارك فيه القائد باستمرار، ويستبدل «التخطيط الثابت» بـ«القرار الديناميكي»، ويجعل انتقال المهام بين الوكلاء طبيعيًا للمرة الأولى؛
• منظومة تنتقل من دليل مغلق إلى بيئة استضافة مفتوحة، مع إتاحة الحزم الخارجية والمهارات العامة وMCP المخصص والجسر العكسي جميعًا — بينما لم تتحرك نقاط التحكم في الإطلاق قيد أنملة؛
• وذاكرة وتطور ذاتي معطّلان افتراضيًا، ومحدودا النطاق، وقابلان للرصد.

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