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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. المخطط

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

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

2. طبقة الأدوات

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

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

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

3. بيئة التنفيذ

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

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

4. الحالة والذاكرة

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

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

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

5. حلقة التقييم

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تقييم مستوى الخطوة

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

أمثلة:

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

تقييم مستوى المهمة

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

أمثلة:

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

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

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

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

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

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

مثال: وحدة تحكم سير عمل وكالي في بايثون

المثال أدناه يوضح شكل حلقة التحكم. يستخدم واجهة 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، ودعم استدعاء الدوال، ودعم المخرجات المنظمة، ونافذة سياق مستضافة بحجم 160K. بالنسبة للعديد من مهام الأتمتة الداخلية والبرمجة، هذا كافٍ لبناء نسخة أولى جادة قبل الانتقال إلى مخطط أكبر أو أكثر تخصصًا.

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

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

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

الإفراط في استخدام الأدوات

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

قواعد توقف ضعيفة

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

معالجة ضعيفة للأخطاء

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

لا حدود للصندوق الرملي

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

لا مقيم

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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