Lifecycle stage — Build
لا أحد تقريبًا شحن نظامًا متعدد الوكلاء على نطاق إنتاجي. المسافة بين عرض LangGraph يعمل في مفكّرة ونظام يعمل لعملاء يدفعون هي المكان الذي يتعثّر فيه كل فريق آخر — ويتعثّر لأسباب غير واضحة حتى تبني واحدًا. هذه هي مرحلتا ENGINEER وPILOT من منهجية DEPLOY، مضغوطتان في مهمّة مضمَّنة لاثني عشر أسبوعًا للفرق التي تمتلك أصلًا نموذجًا أوليًا لوكيل بمستخدمين حقيقيين وتحتاج إلى تصنيعه. لقد صمّمت Auralink — 1.7 مليون سطر من الكود الإنتاجي، وحوالي 20 وكيلًا ذاتيًا يحلّون 78٪ من الحوادث دون تدخّل بشري، مراجعًا من الأقران على arXiv. لا يوجد نظام متعدد الوكلاء مماثل في الإنتاج اليوم. العمل الذي سأقوم به مع فريقك هو العمل نفسه الذي قمت به مع فريقي، مكيّفًا على قاعدة كودك ووكلائك وقيودك التشغيلية. شحنت ثمانية مشاريع ذكاء اصطناعي للإنتاج. أعرف أي القرارات يمكن تأجيلها وأيها سيعضّك بعد ستة أسابيع من الإطلاق إن تخطّيتها الآن.
Every agent demo works in a notebook and falls apart under concurrent production traffic. The tutorial uses synchronous calls, a single happy-path trajectory, and mocked tools. Production runs dozens of agent sessions in parallel, each making real tool calls with real failure modes, and the naive orchestration pattern that looked clean in the demo becomes a thundering herd of retries, deadlocks, and half-committed state. Your team knows this is a problem and does not have the reference architecture for solving it.
Your eval strategy for single-turn LLM calls does not extend to multi-step agent trajectories. You can evaluate a prompt. You cannot yet evaluate a 14-step plan where the fifth step chose the wrong tool, the ninth step passed the wrong argument, and the final answer was still technically correct. Failure modes in agent trajectories compound across steps and the evaluation methodology from single-turn work produces misleading scores. Without trajectory-level evaluation you cannot tell whether a model update improved or regressed the system, and you cannot ship with confidence.
Cost-per-task explodes unpredictably because each agent step multiplies token burn. A single user request triggers a plan, which triggers tool calls, which trigger sub-agents, which trigger more tool calls. Your per-session token count is now 40x a regular LLM call and your CFO wants a model that explains why one power user cost €18 in tokens last Tuesday. You have no instrumentation to answer that — no per-step token accounting, no routing logic that picks cheaper models for easier steps, no budget caps that fail gracefully when a session runs away.
When an agent does something wrong in production you have no observability stack that tells you which step, which prompt, which tool call caused it. The user complains that 'the agent gave a weird answer.' Your logs show the final response and nothing else. You cannot reproduce the trajectory because the agent is non-deterministic. You cannot tell whether the bug is in the planner, the tool router, the retrieval layer, or a specific prompt template. Every incident becomes a multi-day forensics exercise and your team loses confidence in the system faster than users do.
تسير المهمّة في أربع مراحل مدّة كل منها ثلاثة أسابيع. أعمل مضمَّنًا مع فريق الهندسة لديك — مهندسوك يبنون، وأُحضر أنا قرارات الطوبولوجيا ومنهجية التقييم وأنماط الرصد من Auralink. لا يتمّ أي عمل على شريحة استشارة. بنهاية الأسبوع الثاني عشر يشغّل فريقك النظام بدوني.
أتعمّق في نموذجك الأوّلي الحالي — رسم الوكلاء، ومخزون الأدوات، وإدارة الحالة، وأنماط الفشل التي واجهتها سابقًا. أُنتج تصميم طوبولوجيا مكتوبًا: أيُّ الوكلاء، وأيّ المسؤوليات، وأيّ أنماط التواصل، وأيّ حدود الحالة، وأيّ مناطق عزل الفشل. التصميم خاص بمجالك وقاعدة كودك، لا معمارية مرجعية مُقتبسة من مدوّنة. بنهاية الأسبوع الثالث يمتلك فريقك مخطّطًا يستطيع الدفاع عنه أمام مراجع أقدم ومسار هجرة من النموذج الأوّلي الحالي لا يتطلّب إعادة كتابة.
مهندسوك ينفّذون الطوبولوجيا. أعمل معهم على القرارات الأصعب — بدائل التنسيق، واستراتيجية التزامن، وآلة الحالة للجلسات الطويلة، ومنطق إعادة المحاولة والتعويض عند أعطال الأدوات. نشحن تدريجيًا مقابل حركة إنتاج حقيقية من الأسبوع الخامس فصاعدًا، لا انتقالًا كاملًا في الأسبوع السابع. بنهاية الأسبوع السابع تخدم الطوبولوجيا الجديدة الحركة الإنتاجية ويتم إيقاف النموذج الأوّلي القديم.
تقييم على مستوى المسار مبني على الأنماط التي طوّرتها لـ Auralink — تقييم لكل خطوة، ومسارات حقيقة أرضية لاختبار الانحدار، وLLM-as-judge بمُوجّهات معايَرة، والمنهجية الإحصائية التي تسمح لك بقول «هذا التحديث للنموذج حسّن النظام بنسبة 4.2٪ بـ p < 0.01» بدلًا من «الإصدار الجديد يبدو أفضل». محاسبة رموز لكل خطوة ولوحات كلفة لكل مهمّة حتى يستطيع مديرك المالي الإجابة عن الأسئلة التي ستأتي. يدير فريقك التقييم عند كل تغيير من الأسبوع التاسع فصاعدًا.
حزمة رصد يستعملها مهندس المناوبة لديك حين ينطلق النداء في الثالثة فجرًا — تتبّعات المسارات المرتبطة بجلسات المستخدمين، وموجّهات واستجابات لكل خطوة، ومدخلات ومخرجات استدعاءات الأدوات، ومحاسبة الرموز، وتفصيل زمن الاستجابة، وعزو التكلفة. أدلّة تشغيل لأكثر 10 أنماط حوادث في نظامك. جلسات عمل مع فريق SRE لديك حتى يمتلكوا حدود التنبيه واللوحات وأدلّة الاستجابة للحوادث. عندما أرحل، يشغّل فريقك النظام. لا عقد دائم، ولا اعتماد مستمر.
منظّمات التقنية المؤسسية والشركات الناشئة بعد الجولة B التي تمتلك نموذجًا أوّليًا لوكيل ذي مستخدمين حقيقيين، وميزانية لمهمّة مضمَّنة لاثني عشر أسبوعًا، وفريق هندسة بقدرة على تملّك النظام بعد التسليم. فرق المنتج حيث اصطدم المدير التقني أو نائب رئيس الهندسة بالحائط بين «عرض الوكيل يعمل» و«نظام الوكيل يعمل» ويعرف أن الفجوة هي مشكلة طوبولوجيا ومشكلة تقييم ومشكلة قابلية رصد — لا مشكلة هندسة موجّهات. هذه المهمّة ليست للفرق التي لا تمتلك خبرة LLM إنتاجية — فهؤلاء يحتاجون أولًا إلى تدقيق الجاهزية أو سباق الاستراتيجية. وليست كذلك للفرق التي لا تملك قاعدة كود قائمة؛ تفترض المهمّة وجود نموذج أوّلي لتصنيعه، لا بناء من الصفر.
ليس كثيرًا. إطار التنسيق مجرّد مركبة — القرارات التي تهمّ هي الطوبولوجيا وإدارة الحالة ومنهجية التقييم وقابلية الرصد. لقد عملت عبر الأطر الرئيسية وعبر كود تنسيق مخصّص. في الأسبوع الأول أقيّم ما إذا كان إطارك الحالي هو المركبة المناسبة لوجهتك؛ أحيانًا تكون الإجابة نعم ونبني عليه، وأحيانًا يستدعي عنق زجاجة معيّن الهجرة. أتخذ هذا القرار بناءً على الأدلة، لا على أي إطار يمتلك أفضل تسويق.
مهندس ذكاء اصطناعي أقدم توظّفه في 2026 على الأرجح لم يشحن نظامًا متعدد الوكلاء في الإنتاج لأن لا أحد تقريبًا فعل ذلك. لقد فعلتها مرة، عند 1.7 مليون سطر و78٪ حلّ ذاتي. هذا التعرّف على الأنماط غير متاح في سوق المتعاقدين بعد. مهندسوك ينفّذون؛ أُحضر أنا قرارات الطوبولوجيا ومنهجية التقييم وأنماط الرصد التي كانت ستكلّفهم ثلاث تكرارات واثني عشر شهرًا لتعلّمها. عندما أرحل، يملك فريقك كل شيء ولا يحتاج إليّ ثانيةً.
لا. طوبولوجيا الوكلاء وإطار التقييم وقابلية الرصد كلٌّ منها مشكلة ثلاثة أسابيع تُنجز جيدًا ومشكلة أسبوع تُنجز سيّئًا. النسخة المضغوطة تنتج نظامًا يعمل إلى أن يتوقّف، وتكلفة تصحيحه في الشهر الرابع تفوق توفير الاستشارة في الشهر الأول. إذا لم يكن لديك اثنا عشر أسبوعًا، فالمهمّة الصحيحة هي خدمة تصليب من التجربة إلى الإنتاج، التي تغطي عمل الجاهزية الإنتاجية دون إعادة تصميم الطوبولوجيا الكاملة. سأوصي بذلك بصدق إن كان الأنسب.
نادرًا جدًا. في المهمّات التي أدرتها، يحافظ تصميم الطوبولوجيا على 60-80٪ من الكود الحالي ويغيّر طبقة التنسيق وحدود الحالة وأنماط عزل الفشل. منطق الأعمال الذي كتبه فريقك غالبًا على ما يرام؛ ما يلزم تغييره هو كيف ينسّق الوكلاء وكيف تُدار الحالة وكيف تُعالج الأعطال. إعادات الكتابة الكاملة علامة على مستشار لا يريد قراءة كودك. أنا أقرأ كودك.
إنه رقم مقاس من نظام Auralink الإنتاجي، ورد في ورقة arXiv. 78٪ من الحوادث المُسندة إلى مجموعة الوكلاء تُحلّ دون بشر في الحلقة — ويشمل ذلك الحالات التي يُصعّد فيها الوكيل بشكل صحيح، لا فقط الحالات التي يحلّها من البداية إلى النهاية. منهجية القياس جزء ممّا أحضره لمهمّتك. ينتهي كل فريق عملت معه برقم مختلف لأن ملفّ مهامّه مختلف؛ النقطة ليست تكرار 78٪، بل بناء بنية القياس التي تخبرك برقمك الحقيقي.
استكشف خدمات أخرى تُكمّل هذا العرض
٣٠ دقيقة. أشخّص وضعك وأخبرك بصراحة ما إذا كانت هذه الخدمة مناسبة — وإن لم تكن، فأيها مناسب.