ما هو سير العمل الوكيل؟ وكيف تبني واحدًا يخطط ويعمل ويقيّم

سير العمل الوكيل (Agentic Workflow) هو نظام متعدد الخطوات حيث يقوم نموذج اللغة بأكثر من مجرد إجابة لمرة واحدة: فهو يخطط، ويختار الأدوات، وينفذ الإجراءات، ويتحقق من النتيجة، ويقرر ما يجب فعله بعد ذلك حتى اكتمال المهمة. عمليًا، هذا يعني الجمع بين طبقة استدلال من نموذج لغة كبير (LLM) مع استدعاء الأدوات، وبيئة تنفيذ حقيقية، وحلقة تقييم. إذا كنت تبني وكلاء برمجة، أو وكلاء بحث، أو أتمتة داخلية يجب أن تتكيف أثناء منتصف المهمة، فعادةً ما تكون هذه هي البنية التي تقوم ببنائها بالفعل.

ما هو سير العمل الوكيل؟

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

1. قراءة الهدف والحالة الحالية.
2. التخطيط للخطوة التالية.
3. استدعاء أداة أو تشغيل كود.
4. مراقبة النتيجة.
5. تقييم ما إذا كانت المهمة مكتملة.
6. التكرار إذا لزم الأمر.

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

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

كيف يختلف سير العمل الوكيل عن وكيل الذكاء الاصطناعي؟

غالبًا ما يستخدم الناس المصطلحين بالتبادل، لكن من الأكثر فائدة الفصل بينهما:

• سير العمل الوكيل هو نمط التنفيذ.
• وكيل الذكاء الاصطناعي هو المنتج أو النظام المبني على هذا النمط.

يمكن أن يكون لديك سير عمل وكيل ضيق النطاق يقوم فقط بفرز تذاكر الدعم، أو وكيل ذكاء اصطناعي أوسع ينسق التخطيط، واستخدام الأدوات، والذاكرة، ونقاط التحقق من الموافقة عبر العديد من المهام.

إذا كنت تريد قاعدة عملية، استخدم سير العمل عندما تتحدث عن البنية وتدفق التحكم، واستخدم الوكيل عندما تتحدث عن النظام الموجه للمستخدم.

ما هي الأجزاء الأساسية لسير العمل الوكيل؟

تنتهي معظم الأنظمة الإنتاجية بنفس الأجزاء الخمسة.

1. المخطط (Planner)

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

التخطيط الجيد لا يعني توليد مخطط طويل لكل طلب. بل يعني الحفاظ على وضوح الحركة التالية. للمهام القصيرة، يكفي التخطيط بخطوة واحدة. للمهام الأطول مثل إعادة هيكلة المستودعات، أو أتمتة المتصفح، أو مراجعة المستندات، فإن التخطيط الصريح يقلل من التخبط.

2. طبقة الأدوات (Tool layer)

الأدوات هي واجهة سير العمل مع العالم. عادةً ما تكون طبقة الأدوات القوية ضيقة وقابلة للتنبؤ. على سبيل المثال:

• read_file(path)
• write_file(path, content)
• search_files(query)
• run_command(cmd)
• fetch_url(url)

الأدوات الصغيرة أسهل للنموذج في استدعائها بشكل صحيح، وأسهل في التسجيل، وأسهل في التأمين. الأدوات الكبيرة “التي تفعل كل شيء” تبدو ملائمة في البداية لكنها تصبح صعبة التصحيح لأنه لا يمكنك معرفة ما إذا كانت الإخفاقات ناتجة عن قرار النموذج، أو تنفيذ الأداة، أو النظام الخارجي خلفها.

3. بيئة التشغيل (Execution runtime)

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

هنا يأتي دور صندوق الرمل (Sandbox). صندوق الرمل للوكيل من Novita مصمم لطبقة التنفيذ هذه: بيئة منفصلة يمكن للإجراءات الوكيلة أن تعمل فيها دون لمس النظام المضيف مباشرة. هذا هو الفرق بين “النموذج اقترح أمرًا” و"سير العمل نفذ هذا الأمر بأمان".

4. الحالة والذاكرة (State and memory)

يحتاج سير العمل الوكيل إلى ذاكرة عمل عبر الخطوات. يتضمن ذلك عادةً:

• حالة المحادثة
• مخرجات الأدوات
• الملفات الوسيطة
• سجلات التنفيذ
• مسودة أو خطة قصيرة

بدون حالة، تصبح كل خطوة عبارة عن هندسة استدعاء عديمة الحالة، وينهار النظام بمجرد أن تمتد المهمة لأكثر من إجراء واحد.

5. حلقة التقييم (Evaluation loop)

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

بدون تقييم، غالبًا ما يتحول “الوكيل” إلى “استمر في استدعاء الأدوات حتى انتهاء المهلة”.

لماذا يهم التخطيط في بناء سير العمل الوكيل؟

أكبر خطأ في بناء سير العمل الوكيل هو افتراض أن النموذج يجب أن يرتجل كل شيء من الصفر في كل دورة.

هذا عادةً ما يخلق ثلاث مشكلات:

• يعيد النموذج زيارة نفس الملفات أو عناوين URL بشكل متكرر
• يصبح استخدام الأداة مزعجًا ومكلفًا
• يفقد سير العمل شرط توقف واضح

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

في سير العمل البرمجي، غالبًا ما يبدو التخطيط كالتالي:

1. تحديد الملفات المعنية.
2. قراءة التنفيذ الحالي.
3. تحديد الحد الأدنى من التغيير.
4. إجراء التعديل.
5. تشغيل التحقق.
6. إما التوقف أو الإصلاح.

هذا لا يزال وكيليًا، لأن النموذج يمكنه التفرع عندما يفاجئه المستودع. لكنه ليس تجولًا عشوائيًا.

كيف يجب أن يعمل استخدام الأداة في سير العمل الوكيل؟

يجب أن يكون استخدام الأدوات صريحًا، ومصنفًا (typed)، وقابلًا للملاحظة.

إذا كان نموذجك يدعم استدعاء الدوال (function calling)، فاستخدمه. توفر واجهة برمجة تطبيقات LLM من Novita نقطة نهاية متوافقة مع OpenAI وتوثق استدعاء الدوال مباشرة، وهي أنظف طريقة للسماح للنموذج بالاختيار بين الأدوات دون الاعتماد على تحليل سلاسل هش.

بعض القواعد تجعل استخدام الأداة أكثر موثوقية:

• حافظ على أسماء الأدوات ملموسة.
• استخدم مخططات تحتوي على حقول مطلوبة.
• أعد نتائج كاملة، بما في ذلك الأخطاء.
• سجل كل استدعاء ووسيط ومخرج.
• اجعل الإجراءات التدميرية نادرة وسهلة الحماية.

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

لماذا يحتاج تنفيذ الكود إلى صندوق رمل؟

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

صندوق الرمل يحل مشكلتين مختلفتين:

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

بالنسبة للعديد من الفرق، النقطة الثانية لا تقل أهمية عن الأولى. سير العمل الذي يحرر الكود، ويشغل الاختبارات، ويصلح الفشل، ويعيد تشغيل التحقق ليس ممكنًا إذا بدأت كل خطوة من آلة نظيفة.

لهذا السبب فإن البنية العملية عادةً ما تكون:

• واجهة برمجة تطبيقات LLM للتخطيط واختيار الأداة
• بيئة صندوق الرمل للتنفيذ والاستمرارية

تناسب Novita هذا التقسيم بشكل طبيعي: واجهة برمجة تطبيقات LLM تعمل كطبقة تخطيط واستدعاء أداة، بينما صندوق الرمل للوكيل يتولى بيئة التنفيذ الفعلية.

كيف تقيّم سير العمل الوكيل؟

يجب أن يتم التقييم على مستويين.

تقييم مستوى الخطوة (Step-level evaluation)

هل نجح الإجراء الأخير؟

أمثلة:

• هل انتهى الأمر بنجاح؟
• هل أعادت واجهة برمجة التطبيقات JSON صالحًا؟
• هل تم إنشاء الملف المتوقع؟
• هل احتوت صفحة المتصفح على العنصر المستهدف؟

تقييم مستوى المهمة (Task-level evaluation)

هل حل سير العمل مشكلة المستخدم؟

أمثلة:

• هل نجحت الاختبارات بعد تغيير الكود؟
• هل الإجابة على سؤال البحث مدعومة بالأدلة؟
• هل أكملت الأتمتة المعاملة دون تنظيف يدوي؟

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

بنية عملية لبناء سير العمل الوكيل

هذه هي البنية التي يجب أن يبدأ بها معظم الفرق:

1. يدخل طلب المستخدم إلى تطبيقك.
2. يرسل المتحكم الخاص بك الهدف والحالة والأدوات المتاحة إلى نموذج لغة كبير (LLM).
3. يعيد النموذج إما إجابة مباشرة أو استدعاء أداة.
4. ينفذ المتحكم الخاص بك الأداة داخل صندوق رمل أو بيئة تشغيل مضبوطة أخرى.
5. يتم إلحاق نتيجة الأداة بحالة المحادثة.
6. يتحقق المقيم من الاكتمال أو الفشل أو بوابات الموافقة.
7. تستمر الحلقة حتى يتم الانتهاء من سير العمل أو حظره.

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

مثال: متحكم سير عمل وكيل بلغة Python

المثال أدناه يوضح شكل حلقة التحكم. يستخدم واجهة برمجة تطبيقات Novita المتوافقة مع OpenAI لاستدعاء الأدوات. دوال التنفيذ متروكة لك لتنفيذها مقابل بيئة التشغيل الخاصة بك أو صندوق الرمل.

import json
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.novita.ai/openai",
    api_key=os.environ["NOVITA_API_KEY"],
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "Read a file from the workspace",
            "parameters": {
                "type": "object",
                "properties": {"path": {"type": "string"}},
                "required": ["path"],
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "run_command",
            "description": "Run a shell command in the sandbox",
            "parameters": {
                "type": "object",
                "properties": {"cmd": {"type": "string"}},
                "required": ["cmd"],
            },
        },
    },
]


def read_file(path: str) -> str:
    # Implement this against your own workspace or sandbox filesystem.
    raise NotImplementedError


def run_command(cmd: str) -> str:
    # Implement this against your sandbox runtime.
    raise NotImplementedError


dispatch = {
    "read_file": read_file,
    "run_command": run_command,
}


def run_workflow(task: str, model: str) -> str:
    messages = [
        {
            "role": "system",
            "content": (
                "You are a workflow controller. Use tools when needed, "
                "check results after each action, and stop when the task is complete."
            ),
        },
        {"role": "user", "content": task},
    ]

    while True:
        response = client.chat.completions.create(
            model=model,
            messages=messages,
            tools=tools,
            tool_choice="auto",
        )

        message = response.choices[0].message
        messages.append(message)

        if not message.tool_calls:
            return message.content

        for call in message.tool_calls:
            fn = dispatch[call.function.name]
            args = json.loads(call.function.arguments)
            result = fn(**args)
            messages.append(
                {
                    "role": "tool",
                    "tool_call_id": call.id,
                    "content": result,
                }
            )

هذا هو الحد الأدنى المقصود. في الإنتاج، ستضيف أيضًا:

• سياسة إعادة المحاولة للأخطاء المؤقتة
• مهلات وحدود ميزانية
• موافقة بشرية للإجراءات الحساسة
• سجلات خطوات منظمة
• مقيم على مستوى المهمة قبل الاكتمال النهائي

أي نموذج يجب استخدامه كمخطط؟

بالنسبة لسير العمل الوكيل، لا يحتاج نموذج المخطط إلى الذكاء الخام فحسب. بل يحتاج إلى الشكل الصحيح:

• استدعاء أداة موثوق
• سلوك مستقر للسياق الطويل
• اتباع تعليمات قوي
• زمن استجابة متوقع في العمق متعدد الأدوار

إذا كنت تريد نقطة بداية مفتوحة الأوزان على Novita، فإن Qwen3 Coder 30B A3B Instruct هو خيار عملي لتخطيط سير العمل واستخدام الأدوات الموجهة للبرمجة. قائمة نماذج Novita الحالية توفر وصولًا متوافقًا مع OpenAI، ودعم استدعاء الدوال، ودعم المخرجات المنظمة، ونافذة سياق مستضافة بحجم 160 ألف رمز. بالنسبة للعديد من مهام الأتمتة الداخلية والبرمجة، هذا كافٍ لبناء نسخة أولى جادة قبل الانتقال إلى مخطط أكبر أو أكثر تخصصًا.

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

أنماط الفشل الشائعة في سير العمل الوكيل

معظم الإخفاقات ليست دراماتيكية. إنها متكررة ومكلفة.

الإفراط في الأدوات (Over-tooling)

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

قواعد توقف ضعيفة (Weak stopping rules)

إذا كان النظام لا يعرف أبدًا متى تكون “المهمة منتهية” حقيقية، فإنه يستمر في توليد خطوة إضافية أخرى.

معالجة أخطاء سيئة (Poor error handling)

إذا أعادت الأدوات رسائل غامضة مثل “فشل” بدلاً من مخرجات قابلة للتنفيذ، لا يمكن للنموذج التعافي.

لا حدود لصندوق الرمل (No sandbox boundary)

قد يعمل سير العمل في بيئة التطوير، ثم يصبح غير آمن بمجرد أن يلمس ملفات حقيقية، أو بيانات اعتماد، أو أنظمة خارجية.

لا مقيم (No evaluator)

يبدو الوكيل مشغولاً لكنه لا يثبت أبدًا أن المهمة اكتملت بشكل صحيح.

متى لا يجب استخدام سير العمل الوكيل؟

لا تقم ببناء واحد فقط لأن المصطلح شائع.

على الأرجح لن تحتاج إلى سير عمل وكيل إذا:

• كانت المهمة عبارة عن توليد لمرة واحدة
• المسار ثابت ونادرًا ما يتغير
• يمكن لبرنامج تقليدي أن يقرر كل خطوة بتكلفة منخفضة
• لا حاجة لاستخدام الأدوات أو التنفيذ

على سبيل المثال، إذا كان تطبيقك دائمًا يأخذ إدخال نموذج، ويستدعي استدعاء واحد، ويعيد بريدًا إلكترونيًا منسقًا، فإن سير عمل LLM عادي أبسط وأفضل.

سير العمل الوكيل يؤتي ثماره عندما يمكن للبيئة أن تفاجئ النظام ولا يزال النظام بحاجة إلى الاستمرار.

إذا كنت تريد نقطة بداية نموذج ذات سياق طويل، قارن بداية سريعة لنموذج Macaron V1 Tall على Novita AI و نموذج Qwen3.8-Max على Novita AI.

الأسئلة الشائعة

هل سير العمل الوكيل هو نفس استدعاء الدوال؟

لا. استدعاء الدوال هو آلية واحدة داخل سير العمل. سير العمل الكامل يحتاج أيضًا إلى تدفق تحكم، وحالة، وتنفيذ، وتقييم.

هل أحتاج إلى وكلاء متعددين لبناء سير العمل الوكيل؟

لا. يجب أن يبدأ معظم الفرق بحلقة تحكم واحدة وبضع أدوات. التصميمات متعددة الوكلاء مفيدة لاحقًا، لكنها ليست نقطة البداية الافتراضية.

ما هو أهم عنصر تحكم في السلامة؟

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

ما هو أبسط إعداد جاهز للإنتاج؟

إعداد أول جيد هو: واجهة برمجة تطبيقات LLM متوافقة مع OpenAI، وسجل أدوات صغير، وبيئة تشغيل معزولة بصندوق رمل، ومقيم يمكنه تحديد متى تكون المهمة منتهية بالفعل.

مقالات موصى بها

• ما هي وكلاء البرمجة؟ كيف يعملون وكيف تبني واحدًا؟
• ما هو صندوق الرمل لوكيل الذكاء الاصطناعي؟
• الوكيل مقابل سير العمل: الاختلافات الرئيسية والمقايضات العملية