jcode: هيكل وكلاء بلغة Rust يقلع في 14 مللي ثانية

معظم أدوات البرمجة بالذكاء الاصطناعي تتنافس على النموذج. أما jcode فيتنافس على كل ما يحيط بالنموذج.

كُتب jcode بلغة Rust على يد المطور الفردي Jesse Huang، وصدر برخصة MIT، وهو وكيل برمجة يعمل في الطرفية تجاوز 12 ألف نجمة على GitHub خلال ستة أشهر تقريباً. طرحه غير مألوف: لا يدرّب نموذجاً، ولا يضبطه، ولا يدّعي تفوقاً في اختبار SWE-bench. ما يدّعيه هو أن الهيكل نفسه — أي بيئة التشغيل التي تحفظ السياق وتدير الجلسات وتستدعي الأدوات وترسم الواجهة — كان يهدر قدراً هائلاً من الأداء.

والأرقام التي ينشرها تدعم هذا الادعاء بوضوح.

المقارنة التي أشعلت النقاش

رقم 27.8 ميغابايت مقيس مع تعطيل التضمينات؛ ومع تفعيل نظام الذاكرة الدلالية تقترب الجلسة من 167 ميغابايت — أي أقل من نصف الحد الأساسي لـ Claude Code. أما Cursor Agent فيسجل 1,949 مللي ثانية حتى أول إطار، و GitHub Copilot CLI يستهلك 333 ميغابايت لكل جلسة.

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

الذاكرة كرسم بياني لا كدفتر ملاحظات

الجزء المعماري الجدير بالدراسة هو طريقة تعامل jcode مع الذاكرة.

النمط السائد في 2026 هو دفتر ملاحظات بصيغة markdown — ملف CLAUDE.md أو AGENTS.md أو أمر /remember — بالإضافة إلى أداة استرجاع يستدعيها النموذج حين يظن أنه يحتاج إلى السجل. وكلا النصفين مكلف. الدفتر يتضخم حتى يلتهم نافذة السياق. وأداة الاسترجاع تحرق الرموز في كل بحث تخميني، كما أن على النموذج أن يقرر البحث، وهو غالباً لا يفعل.

يستبدل jcode كليهما بخط أنابيب آلي:

1. كل دورة محادثة تُضمَّن كمتجه وتُكتب في رسم بياني للذاكرة.
2. في كل دورة جديدة يُستعلم الرسم البياني بتشابه جيب التمام عن الذكريات ذات الصلة.
3. وكيل فرعي مستقل للتحقق يفحص النتائج المسترجعة قبل حقنها في السياق.
4. عملية دمج تعمل في الخلفية توفّق بين الحقائق القديمة أو المتضاربة.

لا استدعاءات /remember، ولا رموز مهدورة على أدوات البحث، ولا تقدير من النموذج لمسألة التحقق من عدمها. خطوة التحقق هي تحديداً ما تتجاهله معظم طبقات ذاكرة RAG المصنوعة يدوياً، وهي الأهم — فالتشابه الدلالي يسترجع ما هو ذو صلة أكثر بكثير مما يسترجع ما هو صحيح الآن. الحقيقة التي كانت صائبة قبل أربعين دورة ("معالج المصادقة موجود في middleware.ts") تتحول إلى عبء فعلي بمجرد أن تنقله.

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

السياق التراكمي، ولماذا تعاقبك ذاكرة التخزين المؤقت

هناك تحسين أهدأ في تصميم jcode هو هندسة السياق التراكمي (append-only).

تسعّر كل من Anthropic و OpenAI و Google رموز الإدخال المخزنة مؤقتاً بخصم كبير — غالباً نحو عُشر السعر غير المخزن. والتخزين المؤقت يقوم على البادئة: يبقى صالحاً ما دامت بداية طلبك مطابقة بايت ببايت للطلب السابق. غيّر حرفاً واحداً قرب الأعلى فيبطل التخزين كاملاً ويُعاد احتسابه بالسعر الكامل.

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

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

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

السرب: وكلاء ينتبه بعضهم لبعض

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

يسلك نمط swarm في jcode مسار المستودع المشترك ويضيف إليه التنسيق. يتتبع خادم في الخلفية الملفات التي قرأها كل وكيل والتي كتب فيها. وحين يعدّل الوكيل «أ» ملفاً مفتوحاً لدى الوكيل «ب» يُخطَر «ب» ويفحص الفروق قبل المتابعة. كما يمكن للوكلاء تبادل الرسائل مباشرة، أو البث للمجموعة، أو إنشاء فرق عمل تابعة لهم.

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

التشغيل

# macOS / Linux
curl -fsSL https://jcode.sh/install | bash
 
# ويندوز (PowerShell 5.1+)
irm https://jcode.sh/install.ps1 | iex
 
# Homebrew
brew tap 1jehuang/jcode && brew install jcode

أو البناء من المصدر، ويستغرق دقائق قليلة:

git clone https://github.com/1jehuang/jcode.git
cd jcode && cargo build --release

ثم صادق على المزود الذي تدفع له أصلاً:

jcode login --provider claude

الأوامر التي تهم يومياً:

jcode                    # واجهة طرفية تفاعلية
jcode run "أصلح اختبار المصادقة الفاشل"   # تشغيل مرة واحدة
jcode --resume fox       # استئناف جلسة مسماة
jcode serve              # خادم في الخلفية
jcode connect            # ربط عميل به

توجيه المزودين ومخرج الطوارئ

يتحدث jcode مع Claude و OpenAI و Gemini و GitHub Copilot و Azure و Alibaba و OpenRouter و DeepSeek و Mistral و Groq و Perplexity و Fireworks و Ollama و LM Studio وأي نقطة نهاية متوافقة مع OpenAI — أكثر من 30 مزوداً، عبر OAuth أو مفتاح API.

وإضافة بوابتك الخاصة لا تتعدى بضعة أسطر TOML في ~/.jcode/config.toml:

[providers.my-api]
type = "openai-compatible"
base_url = "https://llm.example.com/v1"
api_key_env = "JCODE_PROVIDER_API_KEY"

النتيجة العملية هي حرية الاختيار بين المزودين. فحين يبلغ اشتراك حده الأقصى، يبدّل /account إلى اشتراك آخر في منتصف الجلسة؛ وحين يتعطل مزود، توجّه الطلب إلى غيره بدل أن تتوقف عن العمل. وهي حجة المرونة نفسها التي طرحناها في استراتيجية التبديل بين النماذج، لكن منفَّذة في طبقة الهيكل بدل طبقة التطبيق.

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

ما يستحق التشكيك

لا شيء هنا مجاني.

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

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

مشرف واحد ومشروع عمره ستة أشهر. اثنا عشر ألف نجمة زخم لا استقرار. صدرت النسخة 0.56.0 في 24 يوليو 2026 وإيقاع الإصدارات سريع، وهذا سلاح ذو حدين.

طرفية فقط. لا يوجد تكامل مع بيئات التطوير على النحو الذي يوفره Cursor أو Windsurf. أُعلن عن تطبيق iOS أصلي، ولا شيء غير ذلك.

لماذا يتجاوز هذا أداة واحدة

الادعاء المثير في jcode ليس رقم 245×، بل ما يلمّح إليه.

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

وسواء صار jcode أداتك المفضلة أم لا، فالنمط الذي يبرهن عليه هو ما ينبغي استيعابه: سياق تراكمي، وذاكرة آلية مُتحقَّق منها، وتوازٍ واعٍ بالتعارضات. هذه الأفكار الثلاث تنتمي إلى أي حلقة وكيل تبنيها في 2026 مهما كان الهيكل الذي تختاره.

المستودع هو 1jehuang/jcode. تجربته لا تكلف شيئاً، ونحو أربعة عشر مللي ثانية لتعرف النتيجة.