ما الذي يشتريه محرك السياق فعلاً: قمنا بتشغيل 22 مراجع كود ذكي بخمس طرق مختلفة

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

الملخص التنفيذي: ملخص محرك السياق بالإضافة إلى قراءة واحدة مباشرة لملف السياسة القابل للقراءة الآلية تفوقت على كل استراتيجية أخرى: 1.56 دولار لكل مراجعة و 9.6/13 نتائج مؤكدة — أرخص من قراءة المستندات (2.30 دولار، 8.6/13) وأفضل من الملخص وحده (1.77 دولار، 7.8/13). قراءة كل شيء سجلت الأسوأ من بين الجميع (7.4/13). جميع 22 وكيل تم تشغيلهم على Claude Opus 4.8، و 21 من 22 وصلوا إلى نفس الحكم.

ما هو: حزام، محرك سياق، وطلب سحب واحد

ما هو “الحزام”؟

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

طبقة النص — الاتفاقيات، قواعد العمارة، معايير الاختبار. في مستودعنا هذا هو CLAUDE.md و docs/**: “الخلفية هي snake_case”، “المجال لا يستورد البنية التحتية”، “جميع معالجات المسار غير متزامنة”. يقرأها البشر؛ يُطلب من الوكلاء قراءتها أيضاً.

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

"tier3": {
  "requiredChecks": [
    "lint", "test", "build", "review-agent",
    "harness-smoke", "manual-approval", "expanded-coverage"
  ],
  "mergePolicy": {
    "minApprovals": 2,
    "requireReviewAgent": true,
    "allowSelfMerge": false
  }
}

(ملاحظة المصطلحات: “الحزام” يسمي أيضاً وقت تشغيل الوكيل نفسه — السقالة من الأدوات والمهارات وخوادم MCP التي يعمل من خلالها وكيل، كما في harnext ، “حزام وكيل الترميز.” في هذا المنشور، تكوين الحزام هو ملف السياسة للمستودع الذي يطبقه هذا الوقت التشغيلي و CI.)

لا يمكن لمراجع الكود — بشري أو وكيل — الحكم على “هل يُسمح لهذا طلب السحب بالدمج؟” بدون هذا الملف. طلب سحب Tier-3 مع فحص review-agent المتخطى هو انتهاك للسياسة حتى لو كل اختبار أخضر. احتفظ بهذا المثال في الذاكرة؛ إنه يقرر التجربة.

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

التقديم مع harnext و meaninggrid

meaninggrid هو محرك السياق المستضاف من harnext ، حزام وكيل ترميز مرخص MIT من QualityUnit، محايد للمزود (ستة أدوات — قراءة، كتابة، تحرير، bash، مهارة، mcp — npm i -g harnext). ملعب المزود لمحرك السياق صريح: “دماغ وكيلك.” المصادر تتدفق إلى فهرس محدث بشكل مستمر — “الشبكة” — وفي كل استعلام يقوم المحرك “بترتيب وتقليص في سياق فعال من حيث الرموز، مرتبط مباشرة في الحزام”: فهرس مستمر، ترتيب الصلة، إزالة التكرار والتخزين المؤقت. رقم العنوان الرئيسي لـ harnext هو −89% رموز لكل استعلام في المتوسط. هذا هو ادعاء المزود؛ كان أحد أغراض هذه التجربة قياس، بأرقامنا الخاصة على مهمة حقيقية، ما الذي توفره هذه الضغط — وما الذي تكلفه.

في نشرنا، تستقبل الشبكة توثيق النص للمستودع؛ كل استقبال ينتج لقطة ثابتة ومصدرة. يستعلم الوكلاء عنها عبر MCP (meaninggrid.harnext.dev/mcp) مع استدعاء context_research واحد ويتلقون ملخصاً مركباً منسوباً مختوماً بـ snapshot_id، الذي يجب على الوكيل الاستشهاد به في كتلة التأكيد — سياق قابل للتدقيق مصنوع ملموساً.

ما تنتجه البوابة — كتلة التأكيد (مثال؛ تفاصيل المشروع حُذفت):

تم التحميل عبر: هجين محسّن (ملخص محرك السياق + ملف السياسة فقط).

- استدعاء context_research #1 (الاتفاقيات / التطبيق الطبقي / الاختبار / الأمان /
  مستويات المخاطر) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- استدعاء context_research #2 (قائمة التحقق من تكامل مزود LLM +
  قواعد الرعاية الإضافية لمحرك التدفق) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- قراءة تكوين الحزام (كامل) من القرص للحصول على أنماط المستوى الدقيقة،
  requiredChecks، mergePolicy، evidenceConfig.
  لم يقرأ CLAUDE.md أو docs/* (مغطى بالملخص).

snapshot_id حقيقي — يمكن لمراجع التحقق بالضبط من إصدار القواعد الذي عمل منه الوكيل.

ثلاث فرضيات

تم تصميم التجربة لتسوية ثلاث تنبؤات قابلة للاختبار، مكتوبة مسبقاً:

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

H2 — إعادة الصياغة تدمر السياسة. يمكن لملخص أن ينقل “Tier 3 يتطلب مراجعة بشرية” بدون فقدان. لا يمكنه نقل "requireReviewAgent": true بدون فقدان — التفاصيل الدقيقة والمقتبسة التي يحتاجها المراجع للادعاء بانتهاك تموت في الملخص. إذا كان صحيحاً: يجب أن تفتقد وكلاء الملخص فقط بشكل منهجي انتهاكات البوابة التي تلتقطها الوكلاء التي تحتفظ بملف السياسة الحرفي.

H3 — السياق الأقل يقرأ بشكل أعمق. يتم دفع السياق مرتين — مرة بالدولار، مرة بالانتباه: كل مستند زائد في النافذة يتنافس مع الكود قيد المراجعة. إذا كان صحيحاً: قراءة كل شيء (ملخص + جميع المستندات) يجب ألا تفوز؛ أقل سياق كافٍ يجب أن يفوز.

كيف اختبرناها

راجع اثنان وعشرون وكيل نفس طلب السحب Tier-3 في مستودعنا الإنتاجي (تكامل مزود LLM: 44 ملف، +2,111 سطر، حصص حقيقية — جداول الفواتير، توجيه محرك التدفق). خمس ذراع، تختلف فقط في خطوة تحميل السياق:

القواعد الأرضية: التزام مثبت واحد، نص مطالبة واحد، نموذج واحد — Claude Opus 4.8 — جميع الذراعات متشابكة في دفعة متزامنة واحدة. تم منع الوكلاء من خيط تعليقات طلب السحب، حتى لا تتسرب جولات التجربة السابقة. كل رقم يأتي من نسخ الوكيل الخام، مع استخدام الرموز المنزوعة لكل طلب API وتسعيرها بأسعار القائمة. يتم تسجيل الجودة مقابل 13 عيوب حقيقية مؤكدة بشكل مستقل في طلب السحب، مطابقة النمط في نص كل مراجعة وتدقيق يدوي للإيجابيات الخاطئة. اتفاق الحكم عبر جميع الذراعات: 21/22 قالت طلب تغييرات.

إذاً ماذا: التكوين الأرخص فاز أيضاً على الجودة

★ = التكوين الذي نشحنه الآن كمهارة افتراضية للمستودع. يتضمن الوقت الفعلي المنافسة المشتركة من تشغيل 22 وكيل متزامن.

H1 — مؤكدة

راجعت ذراع الملخص فقط بـ 1.77 دولار مقابل 2.30 دولار لقراءة المستندات (−23%)، والذراع الفائزة ملخص-بالإضافة-إلى-ملف-واحد بـ 1.56 دولار (−32%) — بنفس الأحكام. ينضم الاختيار: يحل الملخص محل مكدس من المستندات التي ستركب بخلاف ذلك من خلال كل استدعاء API لاحق في السياق.

H2 — مؤكدة، حاسمة

فحص review-agent المتخطى — انتهاك حقيقي لسياسة الدمج في طلب السحب هذا — تم اكتشافه من قبل 5 من 5 وكلاء يحتفظون بملف السياسة الحرفي، و 1 من 5 وكلاء ملخص فقط. الآلية هي بالضبط ما توقعته H2: لكتابة تلك النتيجة، يجب على الوكيل مطابقة أسماء فحوصات CI الدقيقة مقابل حقول التكوين الدقيقة — إعادة صياغة ليست دليلاً قابلاً للاقتباس، لذا يتردد وكلاء الملخص فقط وتسقطها. قراءة مباشرة واحدة تستعيدها.

H3 — مؤكدة

حملت الهجين قراءة-كل-شيء السياق الأكثر من أي ذراع وسجلت الأسوأ (7.4/13)، بينما سجلت ذراع أقل سياق كافٍ الأفضل (9.6/13) — وكانت الأفضل من بين جميع الذراعات في أعمق نتيجة واحدة، خلل كود ميت يتطلب تتبع مسار استدعاء عبر ثلاثة ملفات. لم تضف النثر الزائد معلومات؛ تنافس مع الكود على الانتباه.

تذييل صريح واحد: خط الأساس البارد (8.0/13 بـ 1.64 دولار) يوضح أن معظم العيوب الـ 13 هي أخطاء كود عادية يجدها نموذج قوي بدون سياق اتفاقية على الإطلاق. ما لا يمكن لـ cold القيام به هو النصف السياسي من المهمة — البوابات والمستويات وقواعد الدمج — وهو بالضبط حيث تنفصل الذراعات.

قم بتنسيق النثر إلى ملخص. اقرأ ملف السياسة خاماً. لا تقرأ أي شيء مرتين.

الكشف الكامل

• النموذج: كل استدعاء API لكل وكيل تم تشغيله على claude-opus-4-8 (Claude Opus 4.8) — تم التحقق من حقل model في كل سطر نسخة، وليس مفترضاً. قد تختلف النتائج على نماذج أخرى؛ النماذج الأصغر حجماً تعتمد على الأرجح أكثر على السياق المنسق، وليس أقل.
• الأسعار: تستخدم التكاليف أسعار Anthropic المدرجة في وقت الكتابة؛ قد يختلف الفواتير الفعلية. المقارنات النسبية لا تتأثر.
• حجم العينة: n=5 لكل ذراع (n=2 للبارد)، طلب سحب واحد، مستودع واحد، نوع مهمة واحد. تأثير البوابة (5/5 مقابل 1/5) حاد؛ معدلات لكل نتيجة في مكان آخر هي ±1 وكيل. تعاملها كتجربة استكشافية قوية، وليس معيار.
• مقياس الجودة: كشف النمط على نص المراجعة (الاستشهادات مستثناة)، يتم تدقيقها يدويًا للإيجابيات الخاطئة. يحسب ذكر العيوب المؤكدة، وليس بلاغة المراجعة الشاملة.
• التوقيت: جميع 22 وكيل يشاركون جهاز واحد وحصة API واحدة؛ أرقام الوقت الفعلي تتضمن تلك المنافسة.
• صححنا أنفسنا مرتين: كانت عدادات الرموز الأولية متضخمة 2–3× (ازدواجية الاستخدام لكل سطر في النسخ؛ تم الإصلاح بواسطة إزالة تكرار معرف الطلب)، وكان تصور الخط الزمني السابق لا يحسب وقت الجدار (تم الإصلاح بواسطة نسبة الفاصل الكامل). كلا الإصلاحات مدمجة في كل رقم هنا.

هل أنت مستعد لتنمية عملك؟

ابدأ تجربتك المجانية اليوم وشاهد النتائج في غضون أيام.

طلب عرض توضيحي تسجيل الدخول

الآن ماذا: سرق الحلقة

ما شحناه

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

ما يمكنك فعله يوم الاثنين

1. قسم سياق الوكيل إلى اثنين: نثر (الاتفاقيات والعمارة والاختبار) مقابل السياسة القابلة للقراءة الآلية (بوابات CI ومستويات المخاطر وقواعس الدمج).
2. أنشئ ملخصاً للنثر؛ لا تنشئ ملخصاً للسياسة أبداً. قدم النثر من خلال محرك سياق — meaninggrid هو لنا — واجعل ملف السياسة قراءة إجبارية حرفية في بوابة السياق.
3. اجعل السياق قابلاً للتدقيق. نسخ السياق المستقبل؛ اطلب من الوكلاء الاستشهاد بمعرف اللقطة في كتلة تأكيد يمكن للمراجعين التحقق منها فعلاً.
4. قياس قبل أن تؤمن — بما في ذلك نحن. حفنة من الوكلاء لكل ذراع على مستودعك الخاص كافية لرؤية النمط. سجل المراجعات مقابل النتائج المؤكدة، وليس الحدس.

دعوة مفتوحة

إذا أجريت هذه التجربة على مستودعك الخاص — نفس الذراعات، نموذجك، حزامك — فنحن نود حقاً رؤية أرقامك، خاصة إذا كانت تدحض أرقامنا. وإذا أرادت فريقك مساعدة في إعداد بوابة سياق مثل هذه، أو أرادت التحدث عن meaninggrid وكومة harnext، فتواصل مع فريق FlowHunt أو ابحث عن الحزام مفتوح المصدر في harnext.dev . التكرارات والأسئلة والتصحيحات جميعها مرحب بها.