07 أكتوبر 2025·8 دقيقة
تصميم أنظمة عاملية لا تنهار في الإنتاج
لماذا تفشل العديد من الأنظمة العاملية في الإنتاج وكيفية تصميم وكلاء موثوقين باستخدام آلات الحالة، عقود أدوات صريحة، سياسات إعادة المحاولة، ومراقبة عميقة.
لماذا تفشل العديد من الأنظمة العاملية في الإنتاج وكيفية تصميم وكلاء موثوقين باستخدام آلات الحالة، عقود أدوات صريحة، سياسات إعادة المحاولة، ومراقبة عميقة.
الأنظمة العاملية هي تطبيقات حيث لا يكتفي نموذج اللغة الكبير بالإجابة على مطالبة، بل يقرر ما الذي ينبغي فعله تاليًا: أي أدوات يستدعي، أي بيانات يجلب، أي خطوات ينفذ، ومتى يُعلن أنه "انتهى". تجمع هذه الأنظمة بين نموذج، ومجموعة أدوات (واجهات برمجة، قواعد بيانات، خدمات)، حلقة تخطيط/تنفيذ، وبنية تحتية تصل كل شيء ببعضه.
في العرض التوضيحي، يبدو هذا سحريًا: يضع الوكيل خطة، يستدعي بعض الأدوات، ويعيد نتيجة مثالية. مسار السعادة قصير، الكمون منخفض، ولا شيء ينهار في نفس الوقت.
تحت أحمال حقيقية، يتعرض نفس الوكيل لضغوط لم يشهدها العرض التوضيحي:
النتيجة: سلوك متقلب يصعب إعادة إنتاجه، فساد بيانات صامت، وتدفقات مستخدمين تتوقف أو تدور إلى ما لا نهاية بين الحين والآخر.
الوكلاء المتقلبون لا يؤثرون فقط على "سعادة" المستخدم؛ بل:
هذا المقال حول أنماط هندسية، ليس "مطالبات أفضل". سننظر إلى آلات الحالة، عقود الأدوات الصريحة، استراتيجيات إعادة المحاولة ومعالجة الفشل، التحكم في الذاكرة والتزامن، وأنماط المراقبة التي تجعل الأنظمة العاملية متوقعة تحت الحمل — وليس فقط مبهرة على المسرح.
معظم أنظمة الوكلاء تبدو جيدة في عرض توضيحي لمجرى السعادة الواحد. تفشل عندما تأتي حركة المرور والأدوات وحالات الحافة معًا.
التنسيق السطحي يفترض أن النموذج سيـ"يفعل الشيء الصحيح" في استدعاء أو اثنين. تحت الاستخدام الحقيقي، ترى أنماطًا متكررة:
دون حالات صريحة وشروط نهاية، تصبح هذه السلوكيات حتمية.
التعيين العشوائي لنماذج LLM، تفاوت الكمون، وتوقيت الأدوات يخلق عدم حتمية خفيّة. نفس المدخل قد يسلك فروعًا مختلفة، يستدعي أدوات مختلفة، أو يفسر نتائج الأدوات بطرق متباينة.
عند النطاق، تسود مشاكل الأدوات:
كل واحد من هذه يؤدي إلى حلقات عشوائية، عمليات إعادة محاولة، أو إجابات نهائية غير صحيحة.
ما لا ينهار كثيرًا عند 10 طلبات في الثانية سينهار باستمرار عند 1,000 طلب في الثانية. يكشف التزامن عن:
فرق المنتج تتوقع غالبًا تدفقات عمل حتمية، مستويات خدمة واضحة، وقابلية للتتبع. يقدم الوكلاء، إذا تُركوا بلا قيد، سلوكًا احتماليًا وبأفضل جهد مع ضمانات ضعيفة.
عندما تتجاهل البنى هذا التعارض — تعامل الوكلاء كخدمات تقليدية بدلًا من مخطّطي احتمالات — تتصرف الأنظمة بشكل غير متوقع تمامًا عندما تكون الموثوقية مهمة أكثر.
الوكلاء الجاهزون للإنتاج أقل ارتباطًا بـ "مطالبات ذكية" وأكثر ارتباطًا بتصميم نظم منضبط. طريقة مفيدة للتفكير فيهم هي كآلات صغيرة متوقعة تستدعي LLM أحيانًا، لا ككتل غامضة من LLM تلمس أنظمتك أحيانًا.
أربع خصائص مهمة:
لن تحصل على هذه الخصائص من المطالبات فقط. تحصل عليها من البنية.
النمط الافتراضي الذي يبدأ به الكثير من الفرق هو: "طالما لم ننتهِ، استدعِ النموذج، دعه يفكر، ربما يستدعي أداة، كرر". هذا سهل للنمذجة وصعب للتشغيل.
نمط أكثر أمانًا هو تمثيل الوكيل كسير عمل صريح:
COLLECTING_INPUT, PLANNING, EXECUTING_STEP, WAITING_ON_HUMAN, DONE).هذا يحوّل الوكيل إلى آلة حالة حيث يمكن فحص كل خطوة، اختبارها، وإعادة تشغيلها. الحلقات الحرة الشكل تبدو مرنة، لكن سير العمل الصريح هو ما يجعل الحوادث قابلة للتصحيح والسلوك قابلًا للتدقيق.
الوكلاء الأحاديون الشمول الذين "يفعلون كل شيء" جذابون، لكنهم يخلقون ترابطًا قويًا بين مسؤوليات غير مرتبطة: التخطيط، الاسترجاع، منطق الأعمال، تنسيق واجهة المستخدم، والمزيد.
بدلاً من ذلك، ركب وكلاء/مهارات صغيرة ومحددة النطاق:
يمكن لكل مهارة أن تملك آلة الحالة الخاصة بها، الأدوات، وقواعد الأمان. يصبح منطق التركيب بعد ذلك سير عمل أعلى مستوى، لا مطالبة متزايدة داخل وكيل واحد.
هذه البساطة تُبقي كل وكيل قابلًا للفهم وتسمح بتطوير قدرة واحدة دون زعزعة بقية النظام.
نموذج ذهني مفيد هو تقسيم الوكيل إلى ثلاث طبقات:
سياسة القرار (مطالبات LLM + النموذج)
تغطي كيف يختار الوكيل الإجراءات التالية، ضمن قيود صارمة. يجب أن تتمكن من تبديل النموذج، تعديل الحرارة، أو تحسين المطالبات دون العبث بربط النظام.
آلة الحالة / محرك سير العمل
يملك أين أنت في العملية، أي انتقالات ممكنة، وكيف تحفظ التقدم. تقترح السياسة تحركًا؛ آلة الحالة تتحقق وتطبقه.
طبقة الأدوات
تنفّذ ما يمكن أن يحدث في العالم: واجهات برمجة التطبيقات، قواعد البيانات، الطوابير، والخدمات الخارجية. تكشف الأدوات عن عقود ضيقة ومصنفة وتفرض التفويض، حدود المعدل، والتحقق من المدخلات.
بفرض هذا الفصل، تتجنب فخ إخفاء منطق الأعمال داخل المطالبات أو أوصاف الأدوات. يصبح LLM مكوّن قرار داخل غلاف حتمي واضح، لا الغلاف نفسه.
أكثر الأنظمة العاملية موثوقية ليست أكثرها إثارة — بل تلك التي يمكنك شرح سلوكها على سبورة بيضاء.
عمليًا:
الميول نحو وكلاء صغار، مركّبون، ومنظمون جيدًا هو ما يسمح للأنظمة بالنمو دون الانهيار تحت ثقل التعقيد.
تبدأ معظم تطبيقات الوكلاء كحلقة "فكر، افعل، لاحظ" حول استدعاء LLM. هذا مقبول للعروض، لكنه يتحول سريعًا إلى غامض وهش. نهج أفضل هو اعتبار الوكيل آلة حالة صريحة: مجموعة نهائية من الحالات، مع انتقالات معرفة تُنفَّذ عبر أحداث.
بدلاً من ترك النموذج يقرر ضمنيًا ما التالي، عرّف مخطط حالة صغير:
تُطلِق الانتقالات بين هذه الحالات أحداث مَكتوبة مثل UserRequestReceived, ToolCallSucceeded, ToolValidationFailed, TimeoutExceeded, أو HumanOverride. كل حدث، مع الحالة الحالية، يحدد الحالة التالية والإجراءات.
هذا يجعل المحاولات والمهلات مباشرة: تُرفَق سياسات بحالات فردية (مثلاً CALL_TOOL قد يعيد المحاولة 3 مرّات بتراجع أُسِّي، بينما PLAN قد لا يُعاد المحاولة إطلاقًا) بدلًا من نشر منطق إعادة المحاولة عبر الشيفرة.
خزّن الحالة الحالية والسياق القليل الضروري في مخزن خارجي (قاعدة بيانات، طابور، أو محرك سير العمل). يصبح الوكيل عندئذ دالة نقية:
next_state, actions = transition(current_state, event, context)
هذا يمكّن من:
مع آلة حالة، كل خطوة من سلوك الوكيل صريحة: أي حالة، أي حدث وقع، أي انتقال نفّذ، وأي آثار جانبية أنتجت. هذه الوضوح يسرّع التصحيح، يبسط تحقيق الحوادث، ويخلق أثر تدقيق طبيعي للامتثال. يمكنك إثبات، من السجلات وتاريخ الحالة، أن إجراءات خطرة معينة تُؤخذ فقط من حالات محددة وتحت شروط معرّفة.
يتصرف الوكلاء بشكل أكثر توقعًا عندما تبدو الأدوات أقل كـ "واجهات مخفية في نص" وأكثر كواجهات جيدة التصميم مع ضمانات صريحة.
يجب أن تشتمل كل أداة على عقد يغطي:
InvalidInput, NotFound, RateLimited, TransientFailure) مع دلالات واضحة.عرّض هذا العقد للنموذج كوثائق مُهيكلة، لا كتلة نصية كبيرة. يجب أن يعرف مخطط الوكيل أي الأخطاء قابلة لإعادة المحاولة، أيها يتطلب تدخل المستخدم، وأيها يوقِف سير العمل.
عامل مدخلات ومخرجات الأدوات كما أي واجهة إنتاجية:
هذا يسمح بتبسيط المطالبات: بدلًا من تعليمات وصفية مطولة، اعتمد على توجيه يقوده المخطط. القيود الواضحة تقلل الحشو والنداء لأدوات هلوغرافية وتسلسل استدعاءات غير منطقي.
تتطور الأدوات؛ يجب ألا تنهار الوكلاء في كل مرة يحدث فيها هذا.
v1, v1.1, v2) وثبّت الوكلاء على إصدار.يمكن لمنطق التخطيط بعد ذلك مزج وكلاء وأدوات بمستويات نضج مختلفة بثقة.
صمّم العقود مع وضع الفشل الجزئي في الحسبان:
بإمكان الوكيل عندئذ التكيّف: متابعة سير العمل بوظائف أقل، طلب تأكيد المستخدم، أو التحول إلى أداة بديلة.
عقود الأدوات مكان طبيعي لترميز حدود الأمان:
confirm: true).ادمج هذا مع فحوصات على الخادم؛ لا تعتمد فقط على انضباط النموذج في "التصرّف".
عندما تمتلك الأدوات عقودًا واضحة ومتحقق منها ومُرقَّمة، تصبح المطالبات أقصر، يصبح التنسيق أبسط، ويصبح التصحيح أسهل بكثير. تنقل التعقيد من تعليمات اللغة الطبيعية الهشة إلى مخططات وسياسات حتمية، مما يقلل من استدعاءات أدوات هلوسية وآثار جانبية غير متوقعة.
تفترض الأنظمة العاملية الموثوقة أن كل شيء سيفشل في مرحلة ما: النماذج، الأدوات، الشبكات، حتى طبقة التنسيق الخاصة بك. الهدف ليس تجنّب الفشل، بل جعله رخيصًا وآمنًا.
القدرة على التكرار تعني: تكرار نفس الطلب يعطي نفس الأثر الظاهر خارجيًا كما لو نُفذ مرة واحدة. هذا مطلوب لوكلاء LLM الذين يعيدون غالبًا إصدار استدعاءات الأدوات بعد فشل جزئي أو استجابة غامضة.
اجعل الأدوات قابلة للتكرار عبر التصميم:
request_id ثابت. تخزن الأداة هذا وتُرجع نفس النتيجة إذا رأت المعرف مرة أخرى.استخدم محاولات منظمة للأخطاء العابرة (المهلات، حدود المعدل، 5xx): تراجع أسي، تشويش لتجنّب سرب المحاولات، وحد أقصى محاولات صارم. سجّل كل محاولة بمعرّفات ترابط حتى يمكنك تتبّع سلوك الوكيل.
لأخطاء دائمة (4xx، أخطاء التحقق من الصحة، انتهاكات قواعد الأعمال)، لا تعيد المحاولة. أبلِغ الوكيل بخطأ مُهيكل حتى يعيد التخطيط، يطلب من المستخدم، أو يختار أداة مختلفة.
نفّذ قواطع دائرة على مستوى الوكيل والأدوات: بعد تكرار الفشل، احظر استدعاءات تلك الأداة مؤقتًا وافشل بسرعة. اقترن هذا بوضع بدائل محددة: أوضاع متدهورة، بيانات مخبأة، أو أدوات بديلة.
تجنّب المحاولات العمياء من حلقة الوكيل. بلا أدوات قابلة للتكرار وفئات فشل واضحة، ستضاعف فقط الآثار الجانبية والكمون والتكلفة.
الوكلاء الموثوقون يبدأون بتفكير واضح حول ما هي الحالة وأين تعيش.
عامل الوكيل كما تفعل خدمة تعالج طلبًا:
خلط هذين يؤدي إلى ارتباك وأخطاء. مثلاً، وضع نتائج أدوات مؤقتة في "الذاكرة" يجعل الوكلاء يعيدون استخدام سياق قديم لاحقًا.
لديك ثلاث خيارات رئيسية:
قاعدة جيدة: LLM دالة بلا حالة على كائن حالة صريح. احفظ هذا الكائن خارج النموذج وأعد توليد المطالبات منه.
نمط فشل شائع هو استخدام سجلات المحادثة، الآثار، أو المطالبات كذاكرة افتراضية.
المشاكل:
بدلًا من ذلك، عرّف مخططات ذاكرة مُهيكلة: user_profile, project, task_history، إلخ. استخلص السجلات من الحالة، لا العكس.
عندما تُحدّث أدوات أو وكلاء متعددون نفس الكيانات (مثلاً سجل CRM أو حالة تذكرة)، تحتاج ضوابط تناسق أساسية:
للعمليات عالية القيمة، سجّل سجل قرارات منفصلًا عن سجل المحادثة: ماذا تغيّر، لماذا، واستنادًا إلى أي مدخلات.
للبقاء على قيد الحياة أثناء الانهيارات، النشر، وحدود المعدل، يجب أن تكون التدفقات قابلة للاستئناف:
هذا يمكّن أيضًا من تصحيح عبر الزمن: يمكنك فحص وإعادة تشغيل الحالة الدقيقة التي أدت إلى قرار سيئ.
الذاكرة مسؤولية بقدر ما هي ميزة. للوكلاء الإنتاجيين:
عامل الذاكرة كسطح منتج: مصمَّم، مُرقَّم، ومحكوم — ليس مجرد ركام نصي متزايد مُلحق بوكيلك.
يبدو الوكلاء متسلسلين على السبورة، لكنهم يتصرفون كنظم موزعة تحت حمل حقيقي. بمجرد أن يكون لديك العديد من المستخدمين المتزامنين، الأدوات، والوظائف الخلفية، ستتعامل مع حالات سباق، عمل مكرر، ومشاكل ترتيب.
أوضاع فشل شائعة:
تخفف هذه بمزيج من عقود أدوات قابلة للتكرار، حالة سير عمل صريحة، وقفل تفاؤلي/تشاؤمي في طبقة البيانات.
التدفق التزامني طلب–استجابة بسيط لكن هش: كل تبعية يجب أن تكون متاحة وفي حدود المعدل وسريعة. عندما يتفرع الوكيل إلى عدة أدوات أو مهام فرعية متوازية، انقل الخطوات طويلة التشغيل أو ذات الآثار الجانبية خلف قائمة انتظار.
تمكّنك التنظيم عبر قوائم الانتظار من:
عادةً ما يصطدم الوكلاء بثلاث فئات من الحدود:
تحتاج طبقة حدود معدل صريحة مع حصص per-user، per-tenant، وعالمية. استخدم دلاء توكن أو دلاء مسربة لتطبيق السياسات، وعرّف أخطاء واضحة (مثلاً RATE_LIMIT_SOFT, RATE_LIMIT_HARD) حتى يتراجع الوكلاء بهدوء.
الضغط العكسي هو كيف يحمي النظام نفسه تحت الضغط. استراتيجيات تشمل:
راقب إشارات التشبّع: عمق القوائم، استغلال العمال، ومعدلات أخطاء/كمون الأدوات والنماذج. ارتفاع القوائم مع زيادة الكمون أو أخطاء 429/503 هي إنذار مبكر أن الوكلاء يتجاوزون بيئتهم.
لا يمكنك جعل وكيل موثوقًا إذا لم تستطع الإجابة على سؤالين بسرعة: ماذا فعل؟ ولماذا فعل ذلك؟ المراقبة للأنظمة العاملية تجعل تلك الإجابات رخيصة ودقيقة.
صمّم المراقبة بحيث أن مهمة واحدة لها تتبّع يمر عبر:
أرفق داخل ذلك التتبّع سجلات مُهيكلة للقرارات الرئيسية (اختيار المسار، مراجعة الخطة، تشغيل الحماية) ومقاييس للحجم والصحة.
تتبّع مفيد عادةً يحتوي على:
سجّل المطالبات، مدخلات الأدوات، ومخرجاتها بصيغة مُهيكلة، لكن مررها أولًا عبر طبقة تنقيح:
أبقِ المحتوى الخام خلف مفاتيح ميزة في بيئات التطوير؛ افتراضيًا يجب أن تعرض الإنتاج وجهات نظر منقّحة.
على الأقل، تتبّع:
عند حدوث حادث، تسمح التتبّعات والمقاييس الجيدة بالانتقال من "الوكيل يبدو هشًا" إلى بيان دقيق مثل: "P95 المهام تفشل في ToolSelection بعد محاولتين بسبب مخطط جديد في billing_service"، ما يقلل وقت التشخيص من ساعات إلى دقائق ويعطي أدوات ضبط ملموسة.
اختبار الوكلاء يعني اختبار كلٍ من الأدوات التي يستدعونها والتدفقات التي تربط كل شيء معًا. عامله كاختبار نظم موزعة، لا مجرد تعديل للمطالبات.
ابدأ باختبارات وحدة عند حد الأدوات:
هذه الاختبارات لا تعتمد أبدًا على LLM. تنادي الأداة مباشرة بمدخلات تركيبية وتتحقق من المخرجات أو عقد الخطأ بالضبط.
تختبر اختبارات التكامل سير عمل الوكيل من الطرف إلى الطرف: LLM + أدوات + التنسيق.
نمذجها كاختبارات مبنية على سيناريو:
تؤكد هذه الاختبارات انتقالات الحالة واستدعاءات الأدوات، لا كل توكن من كلمات LLM. تحقّق من: أي أدوات استُدعيت، بأي معاملات، بأي ترتيب، وما النتيجة النهائية/الحالة التي وصل إليها الوكيل.
للحفاظ على تكرارية الاختبارات، ثبّت ردود LLM ومخرجات الأدوات.
نمط شائع:
with mocked_llm(fixtures_dir="fixtures/llm"), mocked_tools():
result = run_agent_scenario(input_case)
assert result.state == "COMPLETED"
يجب أن يُثير كل تغيير في مطالبة أو مخطط مجموعة انحدار إلزامية:
تطور المخططات (إضافة حقول، تشديد الأنواع) يحصل له اختبارات انحدار خاصة لالتقاط الوكلاء أو الأدوات التي لا تزال تفترض العقد القديم.
لا تُدشّن نموذجًا جديدًا، سياسة، أو استراتيجية توجيه مباشرةً إلى إنتاج.
بدلًا من ذلك:
فقط بعد اجتياز بوابات غير متصلة يجب أن يصل الإصدار إلى الإنتاج، ويفضل خلف أعلام ميزة وإطلاق تدريجي.
سجلات الوكلاء غالبًا تحتوي بيانات حساسة. يجب أن يحترم الاختبار ذلك.
رمّز هذه القواعد كجزء من خط CI بحيث لا يمكن إنشاء أو تخزين أثر اختبار دون فحوصات تعمية.
تشغيل الوكلاء في الإنتاج أقرب إلى إدارة نظام موزع من نشر نموذج ثابت. تحتاج ضوابط للنشر، أهداف موثوقية واضحة، وإدارة تغيير منضبطة.
قدّم وكلاء أو سلوكيات جديدة تدريجيًا:
ادعم كل هذا بأعلام ميزة وسياسات قابلة للتكوين: قواعد التوجيه، الأدوات المفعّلة، الحرارة، إعدادات الأمان. يجب أن تكون التغييرات قابلة للنشر عبر التكوين، لا الشيفرة، وقابلة للعكس فورًا.
عرّف SLOs تعكس صحة النظام وقيمة المستخدم:
اربط هذه بتنبيهات وادِر الحوادث كما لأي خدمة إنتاجية: ملكية واضحة، دفاتر تشغيل للتشخيص، وخطوات تخفيف معيارية (تراجع العلم، تصفية الحركة، وضع آمن).
استخدم السجلات، التتبّعات، ونصوص المحادثات لتحسين المطالبات، الأدوات، والسياسات. عامل كل تغيير كأثر مُرقّم بمراجعة، موافقة، وقدرة على التراجع.
تجنّب تغييرات المطالبات أو الأدوات الصامتة. بلا تحكم بالتغيير لا يمكنك ربط التراجعات بتحريرات معينة، ويصبح الاستجابة للحوادث لعبة تخمين بدلًا من هندسة منهجية.
يستفيد نظام وكيل جاهز للإنتاج من فصل واضح للمسؤوليات. الهدف هو إبقاء الوكيل ذكيًا في اتخاذ القرار، لكن غبيًا في البنية التحتية.
1. البوابة / حافة API
نقطة دخول موحدة للعملاء (التطبيقات، الخدمات، واجهات المستخدم). تتعامل مع:
2. المنسق (Orchestrator)
المنسق هو "جذع الدماغ"، لا الدماغ. ينسق:
تعيش نماذج LLM خلف المنسق، تُستخدم من قبل المخطط وبواسطة أدوات محددة تحتاج فهم اللغة.
3. طبقة الأدوات والتخزين
يبقى منطق الأعمال في خدمات الميكرو الحالية، الطوابير، وأنظمة البيانات. الأدوات هي أغلفة رقيقة حول:
يستدعي المنسق الأدوات عبر عقود صارمة، بينما تظل أنظمة التخزين مصدر الحقيقة.
فرض المصادقة والحصص عند البوابة؛ وفرض الأمان، وصول البيانات، والسياسة في المنسق. تصدر كل الاستدعاءات (LLM والأدوات) قياسات مُهيكلة إلى خط أنابيب يغذي:
بنية أبسط (بوابة → منسق واحد → أدوات) أسهل في التشغيل؛ إضافة مخططات منفصلة، محركات سياسة، وبوابات نماذج يزيد المرونة بتكلفة تنسيق أعلى، كمون، وتعقيد تشغيلي.
الآن لديك المكوّنات الأساسية لوكلاء يتصرفون بتوقع تحت حمل حقيقي: آلات حالة صريحة، عقود أدوات واضحة، محاولات منضبطة، ومراقبة عميقة. الخطوة النهائية هي تحويل تلك الأفكار إلى ممارسة متكررة لفريقك.
فكّر في كل وكيل كسير عمل ذو حالة:
عندما تتوافق هذه القطع، تحصل على أنظمة تتدهور بلطف بدلًا من الانهيار تحت حالات الحافة.
قبل شحن وكيل نموذجي للمستخدمين الحقيقيين، تأكد من:
إن كان أي بند ناقصًا، فأنت لا تزال في طور النموذج الأولي.
إعداد مستدام عادةً يفصل:
هذا يسمح لفرق المنتج بالتحرّك بسرعة بينما تضمن فرق المنصة الموثوقية، الأمان، وضوابط التكلفة.
بعد تأسيس الأسس المستقرة، يمكنك استكشاف:
التقدّم هنا يجب أن يكون تدريجيًا: أدخل مكونات التعلم خلف أعلام ميزة، مع تقييم غير متصل وحواجز أمان قوية.
الموضوع المشترك طوال هذا كله هو نفسه: صمّم للفشل، فضّل الوضوح على البراعة، وكرر حيث يمكنك الملاحظة والعودة بسهولة. مع هذه القيود في مكانها، تتوقف الأنظمة العاملية عن كونها نماذج مرعبة وتصبح بنية تحتية يمكن لمؤسستك الاعتماد عليها.
نظام عامل هو تطبيق حيث لا يكتفي نموذج اللغة الكبير (LLM) بالإجابة على مطلب واحد، بل يقرر ما الذي ينبغي فعله تاليًا: أي أدوات يستدعي، أي بيانات يجلبها، أي خطوة من سير العمل ينفذ، ومتى يتوقف.
على عكس إكمال الدردشة البسيط، يجمع النظام العامل بين:
في الإنتاج، يصبح نموذج اللغة مكوّنًا واحدًا لاتخاذ القرار داخل غلاف حتمي أكبر — ليس النظام بأكمله.
العروض التوضيحية عادةً تعمل في مسار سعيد واحد: مستخدم واحد، أدوات تعمل على نحو مثالي، لا تأخيرات زمنية، لا انجراف في المخططات، ومحادثات قصيرة. تحت حمل الإنتاج تواجه الوكلاء:
دون سير عمل صريح، عقود، ومعالجة للأخطاء، تولد هذه العوامل حلقات، توقفات، أعمال جزئية، وأخطاء صامتة لا تظهر في بيئة العرض.
اجعل النموذج يعمل داخل هيكل واضح بدلًا من حلقة حرة الشكل:
بهذا يمكنك شرح واختبار وتصحيح السلوك خطوة بخطوة بدلًا من مطاردة "تفكير الوكيل" الغامض.
نمذجة الوكيل كـ سير عمل ذو حالات مسماة وأحداث مكتوبة بدلًا من while not done: call LLM.
الحالات النموذجية قد تشمل:
صمّم الأدوات مثل واجهات إنتاجية جيدة، لا كأوصاف نصية مخفية داخل المطالبات. يجب أن يحتوي كل أداة على:
افترض أن كل استدعاء خارجي سيفشل أحيانًا وصمّم حول ذلك.
نمطيات رئيسية:
افصل الحالة قصيرة الأمد عن الذاكرة طويلة الأمد، واجعل LLM بلا حالة.
تجنّب استخدام السجلات الخام أو سجل المحادثة كـ "ذاكرة"؛ اشتق سجلات مهيكلة صغيرة منها مع قواعد احتفاظ وخصوصية واضحة.
اعتبر نظام الوكيل نظامًا موزعًا تحت الحمل حتى لو بدا متسلسلًا.
للبقاء موثوقًا:
تحتاج أن تجيب على سؤالين لكل مهمة: "ماذا فعل؟" و"لماذا فعل ذلك؟".
متطلبات عملية:
عامل الوكلاء كخدمات متطورة وادِرهم بنفس الصرامة مثل أي نظام إنتاجي آخر.
ممارسات موصى بها:
هذا يمكّنك من تحسين الوكلاء باستمرار مع احتواء الأخطاء، تشخيصها، وقابلية التراجع.
PLAN – تفسير الطلب وإخراج خطة خطوة بخطوةCALL_TOOL – استدعاء أداة محددة أو دفعة أدواتVERIFY – التحقق من المخرجات مقابل قواعد بسيطة أو فحوصات نموذج ثانويةRECOVER – معالجة الأخطاء عبر محاولات، بدائل، أو تصعيدDONE / FAILED – نتائج نهائيةالأحداث (مثل ToolCallSucceeded, TimeoutExceeded) مع الحالة الحالية تحدد الحالة التالية. هذا يجعل المحاولات والمهلات ومعالجة الأخطاء صريحة بدلًا من مبعثرة في المطالبات أو الشيفرة.
InvalidInput, NotFound, RateLimited, TransientFailureحقق صحة المدخلات قبل الاستدعاء وبعده. صنّف الإصدارات وثبّت الوكلاء على إصدار معين حتى لا تكسر تغييرات المخطط التدفقات بصمت.
request_idهذا يحافظ على موثوقية عالية دون حلقات خارجة عن السيطرة، آثار جانبية مكررة، أو تكلفة متفجرة.
راقب أعماق القوائم، النسب المئوية للزمن والتأخير، ومعدلات 429/503 لالتقاط الحمل الزائد قبل أن يصبح انقطاعًا.
مع هذا، ينتقل تشخيص الحوادث من "الوِكيل يبدو متقلبًا" إلى تحديد الحالة، الأداة، والتغيير الذي سبّب التراجع.