ملاحظة المؤلف: تشرح هذه المقالة في 5 خطوات كيفية تصميم بوابات قبول للوكيل، بحيث يكون للوكيل الذكي الذي يعمل لفترات طويلة نقطة نهاية واضحة، وتغذية راجعة موثوقة، وتكلفة قابلة للتحكم.
بعد أن يعمل الوكيل ساعات متواصلة أو حتى أيامًا، يعيد نتيجة تبدو مكتملة، لكن لا أحد يجرؤ على دمجها مباشرة؛ هذه مشكلة تواجهها كثير من فرق التطوير. تقدم هذه المقالة طريقة من 5 خطوات لتصميم بوابات قبول الوكيل، لتساعدك قبل بدء المهام الطويلة على تعريف «الإنجاز» كمعيار يمكن للآلة فحصه مرارًا.
في 27 أكتوبر 2026، أعلن Gregory Kurtzer، أحد مؤسسي CentOS، عن مشروع Ginux. ووفقًا للتقارير، اعتمد خلال 11 يومًا بشكل أساسي على مهمة Codex تعمل باستمرار، وترك حوالي 139 ألف سطر من الشيفرة، ما مكّن هذه النواة المستقلة من إقلاع Rocky Linux 10 وتشغيل systemd. وحين سُئل بإلحاح عن كيفية إعادة الوكيل الذي انحرف إلى المسار الصحيح، كان جوابه بسيطًا: أن يضع بوابات قبول كثيرة.
ليست هذه مقالة أخرى عن حيل الموجهات، بل تركز على البنية الهندسية التي تعتمد عليها المهام الطويلة فعليًا: الهدف، والبوابات، والأدلة، واختبارات الانحدار، وشروط التوقف.
القيمة الأساسية: بعد قراءة هذه المقالة، ستتمكن من كتابة مجموعة بوابات قبول للوكيل لمشروعك، وتحديد أي الخطوات تُترك للآلة وأي القرارات يجب أن تبقى للبشر.
النقاط الجوهرية لبوابات القبول في الـ Agent
بوابات قبول الـ Agent هي مجموعة من نقاط التحقق المحددة مسبقًا والقابلة للتنفيذ بشكل متكرر. إنها تخبر الـ Agent بما إذا كانت النتيجة الحالية تستوفي المعايير، وتخبر الإنسان أيضًا بالأدلة التي تستحق المراجعة.
| النقطة | الشرح | القيمة |
|---|---|---|
| تقديم معايير القبول | كتابة نقطة النهاية والأهداف المرحلية بوضوح قبل بدء المهام الطويلة | تقليل استبدال الـ Agent للنجاح الجزئي بالإنجاز الكلي |
| قابلية تنفيذ البوابات | الحكم باستخدام الأوامر أو السكربتات أو CI أو نتائج التشغيل الفعلية | يمكن للـ Agent التكرار ذاتيًا دون انتظار التدخل البشري |
| فحص سلوك النظام | التركيز على أداء البرنامج أثناء التشغيل الفعلي | اكتشاف المخرجات الخاطئة التي “تبدو موثوقة” |
| توزيع المسؤولية بين الإنسان والآلة | يحدد الإنسان البنية ومعايير القبول، ويقوم الـ Agent بالتنفيذ واختبارات الانحدار | لم يعد الإنسان هو الحلقة الأبطأ في الدورة |
| التحكم في الميزانية | تحديد عدد مرات الفشل والاستهلاك وشروط الإيقاف مسبقًا | تجنب استمرار المهام الطويلة في استهلاك الموارد في اتجاه خاطئ |
بوابات قبول الـ Agent في حالة Ginux
لم يسلّم Kurtzer مهمة “كتابة نواة” مباشرة إلى الـ Agent، بل اختار بوابات صارمة مثل قدرة برامج مساحة المستخدم في Linux على العمل، أو قدرة systemd على الإقلاع. يعتمد systemd على عدد كبير من مكونات النظام، وهو العملية الأساسية لتشغيل وإدارة النظام بأكمله، لذا فهو مناسب جدًا لاختبار ما إذا كانت النواة قابلة للاستخدام فعليًا.
يعمل هذا المشروع ضمن حلقتين متكاملتين. الحلقة الخارجية يقودها الإنسان، بدءًا من الرؤية والبنية والقيود وبوابات القبول، وصولاً إلى مراجعة السلوك الفعلي واتخاذ قرار بالتصحيح أو القبول؛ أما الحلقة الداخلية فينجزها الـ Agent، وتتمثل في التنفيذ المتكرر والبناء والتشغيل في QEMU وقياس الأعطال وتحليلها والمراجعة واختبارات الانحدار.
كما نبه Kurtzer بشكل خاص إلى أن العديد من الأعطال تنتج مخرجات تبدو موثوقة جدًا، لكنها في الواقع تخالف الدلالات أو متطلبات العزل أو سلوك دورة الحياة. وإذا غابت البوابات، فمن السهل جدًا أن ينتهي بك الأمر إلى كود يعمل ظاهريًا لكن بنيته هشة.
لماذا يجب أن تعمل بوابة قبول الوكيل تلقائيًا
يعتبر مهندس Cursor، Lauren Tan، التحقق أيضًا أهم مهارة عند استخدام الوكيل. ويشمل التحقق كما تقصده: أن تجعل الوكيل يشغّل الشيفرة فعليًا، ويجمع تتبعات CPU أو لقطات كومة الذاكرة، ويفتح محاكي iOS، ويتفاعل مع التطبيق بالطريقة نفسها التي يتفاعل بها المستخدم.
وقد ذكرت علنًا أنها تستطيع دمج 4000 طلب سحب (PR) في بيئة الإنتاج شهريًا. وحتى لو خصّص شخص 5 دقائق فقط لمراجعة كل PR، فسيبلغ الإجمالي نحو 333 ساعة؛ لذلك يجب أن يعمل نظام الفحص على هذا النطاق دون تدخل بشري. تثير هذه الحالة القصوى جدلًا كبيرًا، لكنها توضح درسًا ينطبق على الفرق العادية أيضًا: لا يستطيع الوكيل مواصلة العمل إلا إذا كان قادرًا على فحص مخرجاته بنفسه؛ وإذا لم يستطع، فلن يملك سوى تسليم الـ diff إليك والتوقف.
يمكن نقل الحلقة المزدوجة الواردة في المخطط مباشرة إلى المشاريع اليومية. وإذا أردت استخدام نماذج مختلفة للتنفيذ والمراجعة على الترتيب، فيمكنك الاتصال عبر APIYI على apiyi.com، ثم إدراج استدعاءات النماذج ضمن الحلقة الداخلية.
بدء سريع مع بوابات قبول الوكيل: منهجية التصميم في 5 خطوات
نستخدم فيما يلي مهمة شائعة كمثال: أن يقوم الوكيل بترحيل خدمة REST قديمة إلى إطار عمل جديد، مع الحفاظ على عملاء الخدمة الحاليين دون أي تأثير. ويمكنك استبدال عناصر الفحص الواردة في المثال بعمليات البناء والاختبار والنشر الخاصة بمشروعك.
الخطوة 1: حدّد نقطة النهاية على مستوى النظام لبوابة قبول الوكيل
ابدأ بكتابة جملة قابلة للملاحظة تصف ما ينبغي أن يحدث في النظام عند انتهاء المهمة. عبارة «إتمام ترحيل الخدمة» غامضة أكثر من اللازم، أما عبارة «باستخدام نفس مجموعة طلبات الإعادة، تبقى رموز الحالة وحقول الاستجابة الأساسية متطابقة بين الخدمة القديمة والخدمة الجديدة» فهي قابلة للتحقق.
عادةً ما تنبع نقاط النهاية الجيدة من مسارات الاستخدام الحقيقية. فنقطة نهاية Ginux هي وصول Rocky Linux 10 إلى multi-user.target في systemd، ونقطة نهاية تطبيق ويب يمكن أن تكون نجاح مسار المستخدم الأساسي من أوله إلى آخره، ونقطة نهاية مهمة بيانات يمكن أن تكون تطابق النتائج المُخرجة مع مجموعة البيانات المرجعية.
الخطوة 2: تقسيم بوابات قبول الوكيل إلى خمس طبقات
الاعتماد على تغذية راجعة واحدة من اختبار نهائي يكون بطيئًا جدًا، كما يصعب تحديد موقع المشكلة بعد فشل الوكيل. من الأفضل ترتيب البوابات من الأقل إلى الأعلى في تكلفة التشغيل، بحيث تعترض الفحوصات منخفضة التكلفة الأخطاء الواضحة أولًا.
| طبقة البوابة | ما يتم فحصه | مثال | الإجراء بعد الفشل |
|---|---|---|---|
| L1 القيود الثابتة | التنسيق والأنواع وحدود الاعتماديات | منع الاستيراد المتقاطع بين الوحدات | يصحح الوكيل فورًا |
| L2 سلوك الوحدات | منطق الدوال والوحدات | اختبارات الوحدة الأساسية | يحدد الوكيل المشكلة ويصلحها |
| L3 عقود التكامل | الواجهات وقواعد البيانات والاعتماديات الخارجية | اختبارات عقود الواجهات | يقارن الوكيل الفروقات ثم يعدّل |
| L4 تشغيل النظام | السلوك الحقيقي للخدمة الكاملة | تشغيل الخدمة وإعادة بث الطلبات | يجمع الوكيل السجلات وبيانات الأداء |
| L5 القبول البشري | المعمارية والمخاطر والمقايضات التجارية | مراجعة حزمة الأدلة وتحديد ما إذا كان سيتم الدمج | يقدم الإنسان قيدًا جديدًا أو يوقف المهمة |
تقدم معمارية Dune من Lauren Tan مثالًا متطرفًا على L1. فقد أعادت بناء المشروع عبر أكثر من 600 طلب سحب (PR)، واستخدمت CI للتحقق من رسم الاعتماديات، بما يضمن ألا تستورد مجلدات main و renderer في Electron من بعضها بعضًا، مع تعطيل useEffect ومنع كتابة التعليقات. قد لا تناسب هذه القواعد قاعدة الشفرة لديك، لكن فكرة تحويل قيود الفريق إلى فحوصات آلية تستحق الاقتداء.
الخطوة 3: اكتب بوابات قبول الوكيل (Agent) على شكل بطاقات قابلة للتنفيذ
يجب أن تكون لكل بوابة بطاقة قصيرة تُوضع في وثائق المشروع التي يستطيع الوكيل قراءتها عند بدء التشغيل. عندما تكون البطاقة واضحة، لن يضطر الوكيل إلى تخمين معنى “النجاح”، وسيتمكن الإنسان أيضًا من تتبع الأدلة بناءً عليها.
| الحقل | متطلبات التعبئة | مثال على ترحيل الخدمة |
|---|---|---|
| اسم البوابة | سمِّها حسب السلوك | اتساق الطلبات المعاد تشغيلها |
| بيئة التشغيل | إصدارات وتبعيات ثابتة | بيئة اختبار معزولة مع لقطة بيانات ثابتة |
| نقطة التنفيذ | قدِّم أمرًا واحدًا واضحًا | make gate-replay (أمر مثال) |
| معيار النجاح | استخدم نتائج قابلة للمقارنة | تطابق رموز الحالة وجميع الحقول الأساسية |
| مخرجات الأدلة | احفظ ملفات قابلة للمراجعة | تقرير الفروقات، سجلات الخدمة، سجل الأداء |
| قواعد الحماية | حدد ما لا يجوز تعديله | عينات القبول وسكربت الحكم للقراءة فقط |
| استراتيجية الفشل | اشرح الإجراء التالي | إذا لم يُحل الخطأ نفسه خلال 3 جولات متتالية، فأوقف العمل |
من أسهل ما يُغفل هنا قواعد الحماية. يميل الوكيل إلى اختيار أقصر طريق أمامه، وإذا كان بإمكانه تعديل عينات القبول أو تخفيف سكربت الحكم، فستفقد نتائج الاختبار معناها. يُنصح بوضع هذا الجزء في دليل محمي، والتحقق من التغييرات ذات الصلة في CI.
الخطوة 4: إدخال بوابة قبول الوكيل الذكي في حلقة انحدار تلقائي
اكتب الحلقة الداخلية في تعليمات المهمة: أنجز تغييرًا صغيرًا أولًا، ثم شغّل بوابة المستوى الحالي، وراجع أدلة الفشل، وبعد التعديل أعد تشغيل البوابات التي نجحت من قبل. اختبار الانحدار مهم هنا؛ وإلا فقد يصلح الوكيل موضعًا ثم يكسر موضعًا آخر من دون أن يلاحظ أحد.
في نهاية كل جولة، اطلب من الوكيل تسجيل ما تغيّر، والبوابات التي شغّلها، والنتائج، والمشكلات غير المحلولة. سياق المهام الطويلة ينمو باستمرار، وهذا السجل يساعد الجلسات اللاحقة على استعادة الحالة بسرعة، ويسهّل على البشر الحكم على ما إذا كان الوكيل يتقدم فعلًا أم يدور في مكانه.
يجب أن تحمي بوابات القبول أيضًا من «النجاح الزائف». وهذه الحالات شائعة بشكل خاص عند التشغيل الطويل:
| نوع النجاح الزائف | العَرَض النموذجي | خط الدفاع المقابل |
|---|---|---|
| تعديل الاختبارات | حذف حالات الفشل أو تخفيف معايير الحكم | ملفات القبول للقراءة فقط، وCI يفحص التغييرات |
| اختبار المسار السعيد فقط | نجاح الطلبات العادية، وانهيار السيناريوهات الاستثنائية | إضافة حقن الأعطال وعينات الحدود |
| استبدال التبعيات الحقيقية بالمحاكاة | نجاح جميع Mocks في الاختبار، وفشل بيئة التكامل | يجب أن يشغّل L4 الخدمات الحقيقية |
| المخرجات تبدو صحيحة لكن الدلالة خاطئة | السجلات مكتملة، لكن سلوك دورة الحياة خاطئ | مقارنة الحالة والتسلسل الزمني والآثار الجانبية |
| نجاح جزئي يخفي المخاطر | تحسّن مؤشر واحد، وتراجع الاستقرار العام | تشغيل الانحدار الكامل عند كل علامة فارقة |
الخطوة 5: إعداد نقاط قرار بشرية وشروط توقف لبوابات قبول الوكيل
ينبغي أن يتركز عمل الإنسان على الأحكام التي يصعب على الوكيل استبدالها. يتولى Kurtzer مسؤولية البنية المعمارية، وأهداف التوافق مع Linux، ونموذج التشغيل، وتفسير الأعطال، وقرار التوقف؛ وعندما لا يكون راضيًا عن الشفرة التي يولّدها الوكيل، فقد يصل به الأمر إلى إغلاق IDE، ويكبح رغبته في التعديل بيده، وبدلًا من ذلك يقدّم توجيهات جديدة.
يُنصح بوضع ثلاثة أنواع من شروط الإيقاف المؤقت على الأقل: فشل متكرر في البوابة نفسها عبر عدة جولات، أو محاولة الوكيل تغيير محتوى محمي، أو اقتراب استهلاك المهمة من الميزانية. كما ينبغي نقل تركيز المراجعة بعد الإيقاف إلى حزمة الأدلة أولًا، بالنظر إلى سلوك النظام والمخاطر قبل تقرير ما إذا كان ينبغي التعمق في قراءة diff.
نصيحة للبدء السريع: اختر أولًا معلمًا صغيرًا يمكن إنجازه في يوم واحد، واكتب 3 إلى 5 بطاقات بوابات فقط. يوفر APIYI apiyi.com استدعاءات API لنماذج GPT وClaude وغيرها من السلاسل المذكورة في هذا المقال، وهو متوافق مع صيغ واجهات OpenAI وAnthropic؛ وعادةً لا تحتاج الأدوات الحالية إلا إلى تعديل عنوان الواجهة والمفتاح وفقًا للتوثيق، ويمكن تأكيد الطرازات المتاحة تحديدًا من صفحة الأسعار على APIYI.
كيف تغيّر بوابات قبول وكيل الذكاء الاصطناعي تكلفة المهام الطويلة
لا يمكن الحكم على تكلفة المهام الطويلة بمجرد النظر إلى «إجمالي عدد الرموز المستخدمة». تشير التقارير إلى أن إحصاءات الرموز (tokens) في الصفحة الرئيسية لـ Cursor تتضمن على الأقل أربعة أنواع: الإدخال العادي، وإخراج النموذج، وكتابة التخزين المؤقت، وقراءة التخزين المؤقت، وهي تختلف اختلافًا كبيرًا في السعر. وقد استخدم المجتمع بيانات الاستخدام نفسها البالغة 1.5 تريليون رمز لتقدير الفاتورة، لكن النتائج اختلفت كثيرًا بين طرق الحساب، وكان الخلاف الأساسي حول أساس الفوترة وحصة التخزين المؤقت.
| بند الفوترة | المصدر الرئيسي في المهام الطويلة | طريقة التحكم | أساس السعر |
|---|---|---|---|
| الإدخال العادي | تعليمات المهمة، والسجلات، ومقتطفات الشيفرة | مرّر فقط الأدلة المرتبطة بالفشل | وفق البيانات الفعلية في صفحة أسعار APIYI |
| إخراج النموذج | الشيفرة والتحليل وخطة المراجعة | حدّد نطاق الإخراج في كل جولة | وفق البيانات الفعلية في صفحة أسعار APIYI |
| كتابة التخزين المؤقت | سياق ثابت جديد أو متغيّر | حافظ على استقرار بنية قواعد المشروع | وفق البيانات الفعلية في صفحة أسعار APIYI |
| قراءة التخزين المؤقت | سياق يُعاد استخدامه عبر جولات متعددة | راقب نسبة الإصابة وتجنّب تعديل البادئة كثيرًا | وفق البيانات الفعلية في صفحة أسعار APIYI |
يمكن استخدام التكلفة الإجمالية للحالات المعلنة لفهم حجم المشروع، لكن لا يمكن تحويلها مباشرة إلى سعر وحدة. ذُكر أن رسوم استدعاء API لدى Ginux بلغت نحو 8000 دولار، أما تجربة Nicholas Carlini لبناء مترجم C باستخدام 16 وكيل Claude متوازيًا فكلّفت نحو 20 ألف دولار. تختلف النماذج والتخزين المؤقت وبنية المهام خلف هذه الأرقام، لذا يظل مشروعك بحاجة إلى قياس مستقل.
الطريقة الأكثر أمانًا هي تنفيذ مرحلة إنجاز كاملة أولاً، وتسجيل استخدام الرموز من الأنواع الأربعة وعدد مرات فشل البوابات، ثم الحساب وفق البيانات الحالية في صفحة أسعار APIYI https://docs.apiyi.com/models. بهذه الطريقة تأتي الميزانية من شكل مهمتك الخاص، وهي أكثر موثوقية من تطبيق متوسط سعر وحدة لدى الآخرين مباشرة.
يوضح الشكل أعلاه أن البوابات نفسها تستهلك موارد أيضًا، لكنها تكشف الفشل مبكرًا. بالنسبة للفرق العادية، ينبغي أن يكون الهدف الحصول على قدر كافٍ من الثقة ضمن ميزانية محدودة، لا السعي إلى تشغيل أغلى تحقق كامل عند كل تغيير.
الأسئلة الشائعة حول بوابات قبول الوكيل (Agent)
س1: ما هي بوابة قبول الوكيل؟
هي نقاط تحقق قابلة للتنفيذ ومحددة مسبقًا، تُستخدم للحكم على ما إذا كانت النتائج المرحلية للوكيل قد بلغت المعيار المطلوب. تتضمن البوابة الكاملة بيئة التشغيل، ونقطة الدخول التنفيذية، ومعايير النجاح، والمنتجات كأدلة، واستراتيجية الفشل.
س2: ما الفرق بين بوابة قبول الوكيل و CI العادي؟
CI هو وسيلة تنفيذ شائعة، أما بوابة القبول فهي تصميم أشمل للتحكم في المهمة. فإلى جانب الحكم على ما إذا كان الكود سيجتاز الاختبارات، عليها أن تحدد سلوك النظام، والأدلة، ونطاق الاختبارات الرجعية، ونقاط القرار البشري، وشروط الإيقاف المؤقت.
س3: متى يجب تصميم بوابة قبول الوكيل؟
عندما تتطلب المهمة عدة جولات من التعديل، أو تمتد عبر عدة وحدات، أو تستغرق وقتًا طويلاً في التشغيل، أو عندما يكون من الصعب اكتشاف المخرجات الخاطئة بالعين المجردة، ينبغي تصميمها مسبقًا. يمكن تبسيط الأمر في السكربتات الصغيرة لمرة واحدة، لكن يجب على الأقل تحديد طريقة تحقق واحدة قابلة للتشغيل.
س4: هل ما زلنا بحاجة إلى مراجعة الكود البشرية (Code Review) بعد وجود بوابة قبول الوكيل؟
نعم. البوابات الآلية مناسبة للحكم على المعايير المعروفة، لكن البشر ما زالوا مسؤولين عن اختيار البنية، والموازنة بين المخاطر، والقبول النهائي. ويؤكد Kurtzer أيضًا أن الخبرة تظل حاسمة عند الحكم على مدى اكتمال النتائج، وما إذا كان النجاح الجزئي قد يجلب مخاطر على مستوى النظام.
س5: كيف يمكن الوصول إلى النموذج عبر API لتشغيل هذه العملية؟
1. سجّل في APIYI على apiyi.com وأنشئ مفتاح API.
2. راجع مركز التوثيق `docs.apiyi.com` للتأكد من عنوان الواجهة وطريقة الاستدعاء.
3. اختر تنسيق واجهة OpenAI أو Anthropic وفقًا للأداة لإكمال الإعداد.
4. تحقق من طراز النموذج والسعر على `https://docs.apiyi.com/models` قبل بدء تجربة تشغيل صغيرة النطاق.
س6: كيف يمكن تبسيط بوابة قبول الوكيل عند محدودية الميزانية؟
أعطِ الأولوية للاحتفاظ بالبوابات منخفضة التكلفة L1 و L2، ودعها تعمل في كل جولة؛ بينما تُنفَّذ L3 و L4 عند اكتمال الميزات أو عند نقاط الإنجاز الرئيسية. تُظهر إحصاءات Jellyfish لـ 12 ألف مطور أن المستخدم النموذجي يستهلك نحو 51 مليون توكن شهريًا، وهو فارق كبير عن الحالات القصوى، لذلك ينبغي تحديد تكرار التحقق بناءً على مخاطر المهمة. أما أسعار النماذج فيُرجى الاعتماد على البيانات الفعلية في صفحة أسعار APIYI.
س7: ما هي قيود بوابة قبول الوكيل؟
تغطي البوابة فقط المخاطر المحددة لها، فاجتياز جميع الاختبارات لا يعني أن الكود مناسب للصيانة طويلة المدى. تمكنت Ginux من تشغيل Rocky Linux 10، لكن لا يزال أمامها طريق طويل للوصول إلى نواة بمستوى الإنتاج؛ فدعم العتاد، واستقرار الواجهات، والمراجعة الأمنية، وصيانة المجتمع، كلها أمور لا يمكن إثباتها بتشغيل واحد. كما أن انتقادات المجتمع لنمط طلبات السحب (PR) عالية التكرار تذكّرنا بضرورة مواصلة الاهتمام بقابلية الكود للصيانة.
أهم النقاط الأساسية لبوابات قبول Agent
- حدّد نقطة النهاية أولًا: صِف إنجاز المهمة من خلال سلوك نظام قابل للملاحظة، وتجنّب الأهداف الغامضة.
- بوابات متدرجة: انتقل تدريجيًا من القيود الثابتة إلى التشغيل الفعلي ثم القبول البشري.
- احتفظ بالأدلة: احفظ السجلات وتقارير الفروقات وسجلات الأداء في كل تشغيل.
- قواعد التقييم غير قابلة للتغيير: يجب حماية عينات القبول والسكربتات لمنع Agent من سلوك مسارات مختصرة.
- اجعل اختبار الانحدار أمرًا معتادًا: بعد إصلاح مشكلة جديدة، أعد تشغيل البوابات ذات الصلة التي نجحت سابقًا.
- القرار بيد الإنسان: يحدد المسؤول اتجاه البنية والمخاطر وقرار التوقف والقبول النهائي.
- اختبر التكلفة أولًا: تحقق على نطاق صغير عبر APIYI apiyi.com، ثم قدّر الميزانية وفق صفحة الأسعار.
الخلاصة: ابدأ بناء سير عمل ذاتي انطلاقًا من بوابات قبول Agent
تعتمد قدرة Agent على العمل ذاتيًا لفترة طويلة على امتلاكه هدفًا واضحًا وتغذية راجعة موثوقة. عند تصميم بوابات قبول Agent، تذكّر ثلاث نقاط:
- حوّل “الإنجاز” إلى معيار قابل للتنفيذ: اجعل Agent يعتمد على نتائج التشغيل لتحديد التقدم.
- دع الآلة تتولى التحقق المتكرر: اختصر دورة التغذية الراجعة عبر بوابات متدرجة واختبار انحدار تلقائي وحزمة أدلة.
- اترك القرارات الحاسمة للبشر: يحدد المسؤول اتجاه البنية وحدود المخاطر وتوقيت التوقف.
نوصي بالبدء من المهمة المتوسطة الحجم التالية: اكتب بطاقة البوابة أولًا، ثم شغّل Agent. وعند الحاجة إلى اختبار نماذج مختلفة، يمكنك الاتصال عبر APIYI apiyi.com باستخدام واجهات متوافقة مع تنسيقات OpenAI وAnthropic، وطريقة الإعداد موضحة في مركز التوثيق docs.apiyi.com. أما أسعار النماذج ومنهجية الفوترة فتُعتمد وفق البيانات الفعلية في https://docs.apiyi.com/models.
📚 المراجع
- InfoQ – تقرير مشروع Ginux: عملية بناء Codex لنواة متوافقة مع Linux وطريقة قبولها
- الرابط:
infoq.cn/article/OiyNEtFwV05opvsLTcvK -
الوصف: يتضمن الحلقة المزدوجة HDAE، وحجم المشروع، وتحليل القيود
-
InfoQ – تقرير عن فاتورة رموز مهندس Cursor: سير عمل Agent مكثف والجدل حول التكلفة
- الرابط:
infoq.cn/article/q9iebpvFozfy4bgCYUyE -
الوصف: يتضمن حلقة التحقق، وبنية Dune، وانتقادات المجتمع
-
التقرير الفني لـ Ginux: تقرير فني أصدره Gregory Kurtzer
- الرابط:
zenodo.org/records/23682548 -
الوصف: مناسب للتعمق في أهداف البحث ومنهجه وحدود النتائج
-
مستودع Ginux على GitHub: شفرة المشروع
- الرابط:
github.com/gmkurtzer/ginux -
الوصف: يمكن الاطلاع على شفرة المشروع ومعلومات ترخيص المصدر المفتوح
-
وثائق APIYI وصفحة الأسعار: إعدادات الواجهة وأسعار النماذج
- رابط الوثائق:
docs.apiyi.com - رابط الأسعار:
https://docs.apiyi.com/models - الوصف: يرجى الاعتماد على البيانات الفعلية في الصفحة فيما يخص طرازات النماذج والأسعار وأساس الفوترة
المؤلف: فريق APIYI التقني
التواصل التقني: مرحبًا بزيارة APIYI apiyi.com للتواصل معنا حول ممارسات هندسة Agent، ولمزيد من مواد الوصول يمكن مراجعة مركز وثائق docs.apiyi.com.
