كيف استبدلت حلقات API المكلفة بأنابيب مدفوعة بـ Lobster وإدارة ذاكرة Honcho — ولماذا فقط المصلح يلامس النهايات المدفوعة.

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

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

هنا بالضبط كيف فعلت ذلك.

البنية: هجينة متعددة الوكلاء + مجموعات الوكلاء الفرعية

معظم التنفيذات تعامل كل وكيل كمتصل API من الدرجة الأولى. وهذا يستهلك الرموز.

إعداد OpenClaw الخاص بي يستخدم نموذجًا هجينيًا:

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

القاعدة الذهبية: فقط المُصحح يتحدث إلى واجهات برمجة التطبيقات المدفوعة

هنا هو القيد الذي غير كل شيء.

في سير عملي، هناك مكون واحد فقط لديه وصول إلى نقاط نهاية واجهات برمجة التطبيقات المدفوعة: المُصحح.

كل الوكلاء الآخرين—الأساسي، الفرعي، المنسق، عامل الذاكرة—يعملون على الاستدلال المحلي (Ollama، LM Studio، أو سحابة مجانية من الفئة). المُصحح وحده يمكنه استدعاء GPT-4، Claude، أو أي نموذج مدفوع.

لماذا؟ ثلاثة أسباب:

1. انضباط معماري مفروض

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

2. التصحيح كخدمة الطبقة المدفوعة، وليس كاعتماد وقت التشغيل

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

3. التكلفة تزداد مع المشكلات، وليس مع الاستخدام

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

Honcho إدارة الذاكرة: مستمرة، قابلة للبحث، بدون تكلفة

للذاكرة، قمت بدمج Honcho—طبقة ذاكرة مبرمجة ذات أولوية محلية. يمنحني Honcho:

• تخزين مستمرة للمستخدم/الجلسة
• بحث متجه دون قواعد بيانات متجهة سحابية
• صفر مكالمات API لقراءة وكتابة الذاكرة

كل تفاعل وكيل يكتب إلى Honcho. كل وكيل فرعي يبدء سياقه عبر القراءة من Honcho. لا تضمينات مدفوعة. لا خدمة ذاكرة خارجية

ولأن أداة التصحيح لا تمس عمليات الذاكرة أبداً، يعمل Honcho بالكامل مجاناً

الاضمحلال الزمني + MMR: مكافحة الذاكرة العتيقة

الذاكرة عديمة الفائدة إذا هيمنت على السياق الحديث. نفذت آليتين لاسترداد المعلومات داخل Honcho:

1. الاضمحلال الزمني

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

2. MMR (الملاءمة الهامشية القصوى)

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

كلاهما يعمل محليًا. التكلفة: $0. لا يرى المصححهما أبدًا.

Lobster: تفويض المهام و خط الأنابيب دون العبء

هنا ينهار استخدام الرموز.

استبدلت سلاسل الوكلاء الخطية بـ Lobster—وقت تشغيل خط أنابيب مهام خفيف الوزن. يتيح لي Lobster تعريف رسوم بيانية موجهة غير دورية (DAGs) للمهام.

سير عملي:

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

نظرًا لأن خطوط أنابيب Lobster تعيد استخدام السياق وتجنب استدعاءات LLM مكررة، فقد خفضت استهلاك الرموز بنحو 70-80% في أعباء عمل مماثلة. ونظرًا لأن أداة تصحيح الأخطاء تتعامل فقط مع الاستثناءات، فإن هذا التخفيض بنسبة 70-80% ينطبق على الاستخدام المدفوع تحديدًا.

التأثير الحقيقي على استهلاك الرموز (واجهات برمجة التطبيقات المدفوعة)

دعنا نتحدث بالأرقام.

قبل هذا الإعداد، كانت محادثة الوكلاء المتعددين النموذجية: 3 وكلاء، كل واحد يستدعي GPT-4. يتم إضافة استرجاع الذاكرة إلى كل مطالبة. النتيجة: 8,000–12,000 رمز لكل تفاعل مستخدم.

بعد OpenClaw + Honcho + Lobster + الوصول المدفوع المحدود للمصحح: الوكلاء الأساسيون يعملون محليًا. الوكلاء الفرعيون يعملون محليًا. الذاكرة تعمل محليًا. Lobster ينسق كل شيء دون استدعاءات API. يحدث الاستخدام المدفوع لـ API فقط عند الفشل — والذي، بعد استقرار خط الأنابيب، يحدث في أقل من 5% من التفاعلات.

النتيجة: 50–500 رموز لكل تفاعل للواجهات البرمجية المدفوعة، مع تكلفة معظم التفاعلات تساوي 0 دولار.

وهذا يمثل انخفاضًا بنسبة 20–100x في استهلاك الرموز المدفوع مقارنةً بأنظمة الوكلاء المتعددة التقليدية.

للتطبيقات ذات الحجم العالي—مثل دعم العملاء، ووكلاء البحث، والأتمتة—هذا هو الفرق بين منتج قابل للتطبيق وحفرة أموال. عند 10,000 تفاعل يوميًا، قد تكلف الإعدادات التقليدية 200–500 دولار. هذا الإعداد يكلف قرشات، إن وُجد.

لماذا يفرض قيد المصحح فقط هندسةً أفضل؟

وهذا هو البصيرة غير البديهية: تقييد الواجهات البرمجية المدفوعة للمصحح يحسن موثوقية النظام، وليس التكلفة فقط.

عندما يمكن لكل وكيل استدعاء GPT-4، فإنك تتسامح مع المطالبات غير الدقيقة، واسترداد الذاكرة السيء، والأنابيب الهشة. الواجهة البرمجية المدفوعة تغطي الشقوق.

عندما يكون فقط للمصحح هذا الامتياز، فإنك مضطر إلى:

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

النتيجة نظام يفشل بأناقة، يصحح نفسه، وتكلفة تشغيله تكاد تكون منعدمة.

لماذا هذا مهم

لا تحتاج إلى ذاكرة سحابية باهظة الثمن أو حلقات API لا تتوقف لبناء وكلاء ذكيين.

مع OpenClaw، Honcho، وLobster—وقيود API المدفوعة المخصصة للمصحح فقط—يمكنك بناء:

• ذاكرة مستمرة مع تسوس زمني و MMR
• سربات هجينة من الوكلاء/الوكلاء الفرعية
• خط أنابيب المهام مع استعادة تلقائية للفشل
• نظام تكون فيه واجهات برمجة التطبيقات المدفوعة معالجات استثناءات، وليس اعتماديات وقت التشغيل

...مع الحفاظ على فاتورة واجهة برمجة التطبيقات المدفوعة الخاصة بك على بعد مسافة البصق من صفر

أنا لا أحتكر هذا. اسألني عن ملفات الإعداد، والسمات Honcho، وتعريفات DAG الخاصة بـ Lobster، أو كيف قمت بتوصيل المصحح لتفعيله فقط عند فشل خطوط الأنابيب

لنبنِ بأقل تكلفة. لنبنِ بأذكى طريقة. لنجعل واجهات برمجة التطبيقات المدفوعة الملاذ الأخير، وليس الغريزة الأولى