كيف نحدد نطاق مشاريع وكلاء الذكاء الاصطناعي (AI Agents): المنهجية الكامنة وراء السعر الثابت

معظم عروض الوكالات البرمجية حول وكلاء الذكاء الاصطناعي (AI agents) هي محض خيال. فهم يعدون بموظف رقمي مستقل يتولى "كل الدعم الفني" أو "خطوط معالجة الاكتتاب بالكامل" مقابل اشتراك شهري ثابت، لينتهي الأمر بتقديم حلقة تكرارية هشة من LangChain ZeroShotAgent تستهلك 400 دولار من رصيد واجهة برمجة تطبيقات (API) لـ OpenAI gpt-4o خلال عطلة نهاية الأسبوع بسبب حلقات استدعاء الأدوات المتكررة (recursive tool-calling loops)، قبل أن ينهار النظام بسبب خطأ غير معالج مثل RateLimitError أو تجاوز حجم الحالة (state-size overflow).

يعاني قطاع التقنية حالياً مما يُعرف بـ "برزخ المشاريع التجريبية" (pilot purgatory). تفشل ما بين 80% إلى 95% من مبادرات الذكاء الاصطناعي لأن نطاقها يُحدد كمشاريع بحثية مفتوحة الأفق بدلاً من التعامل معها كـ هندسة برمجيات حتمية (deterministic software engineering). عندما تبني تطبيق CRUD تقليدي، تكون مساحة الحالة (state space) محدودة. أما عند بناء وكيل ذكاء اصطناعي (AI agent)، تصبح مساحة الحالة غير محدودة، يمليها الطابع غير المتوقع لمدخلات المستخدم غير المنظمة وتباين مخرجات النموذج (LLM output variance). بالنسبة لمؤسسي شركات SaaS ومشتري الحلول للمؤسسات الكبرى، يمثل هذا الغموض مخاطرة مالية هائلة—ساعات تطوير غير محدودة، قفزات غير متوقعة في فواتير الـ API، وأضرار كارثية بسمعة العلامة التجارية إذا بدأ وكيل غير مقيد بالهلوسة (hallucinating) أمام العميل.

في Verel Systems، نحن لا نبني نماذج تجريبية (demos)، ولا نعمل بنظام العقود الشهرية مفتوحة الساعات التي تشجع على بطء التنفيذ. نحن نبني أنظمة جاهزة للإنتاج (production-grade systems) على أساس نطاق عمل ثابت وسعر ثابت. ولكي نحقق ذلك دون التعرض لخسائر أو تسليم برمجيات معطوبة، كان علينا بناء إطار عمل كمي صارم لتحديد نطاق سير العمل المعتمد على الوكلاء (agentic workflows). يزيل هذا الإطار المخاطر المالية من طرفك عبر نقل مخاطر التنفيذ بالكامل إلينا.

إليك بالتفصيل كيف نقوم بذلك.

لماذا يفشل تحديد النطاق التقليدي للبرمجيات مع الذكاء الاصطناعي

في هندسة البرمجيات الكلاسيكية، تقوم بتقدير الجهد بناءً على قصص المستخدمين (user stories)، ومخططات قواعد البيانات (database schemas)، ونقاط نهاية واجهة برمجة التطبيقات (API endpoints). إذا كانت نقطة النهاية الواحدة تستغرق ثلاثة أيام لبنائها، فإن خمس نقاط نهاية ستستغرق خمسة عشر يوماً.

لا تتوسع وكلاء الذكاء الاصطناعي بشكل خطي. فالوكيل الذي يمتلك أداتين ليس أكثر تعقيداً بمرتين من الوكيل الذي يمتلك أداة واحدة؛ بل هو أكثر تعقيداً بشكل أسي (exponentially) لأن النموذج (LLM) يجب أن يقرر الآن بين هاتين الأداتين، ويدير انتقال الحالة بينهما، ويتعامل مع انتشار الأخطاء لكليهما. بالنسبة للأعمال التجارية، هذا يعني أن المشروع الذي يبدأ بميزانية قدرها 15,000 دولار يمكن أن يتضخم بسهولة إلى 60,000 دولار بينما يطارد المهندسون الحالات الاستثنائية (edge cases) في مساحة حالة غير مقيدة. من خلال فهم هذه الديناميكيات، يمكنك القضاء تماماً على مخاطر تكاليف التطوير المتصاعدة.

Traditional API: Input -> Pydantic Validation -> Business Logic -> DB Transaction (Deterministic)
AI Agent:        Input -> LLM Planner (GPT-4o) -> Dynamic Tool Call -> LLM Reflection Node -> State Mutation -> DB Write (Non-deterministic)

إذا كان وكيلك يمتلك خمس أدوات ويُسمح له بالتكرار بحرية، فقد أنشأت آلة حالة غير محدودة (infinite state machine). وتحت ضغط التشغيل، ستنجرف هذه الآلة في النهاية إلى حالات غير معالجة، أو تنفذ استدعاءات API متكررة، أو تهلوس ببارامترات تتجاوز التحقق من صحة قاعدة البيانات الخاصة بك. هذا هو مصدر "سباغيتي الذكاء الاصطناعي" (AI spaghetti): طبقات من ترقيعات الموجهات (prompt patches) الارتجالية المكتوبة لإصلاح الحالات الاستثنائية التي تم اكتشافها في بيئة الإنتاج.

بدون بنية معمارية مقيدة، فإنك تخاطر بتعريض قواعد بياناتك الأساسية لبيانات تالفة، مما يؤدي إلى عمليات تنظيف يدوية مكلفة وتوقف العمليات التشغيلية. لتحديد نطاق مشروع وكيل بسعر ثابت، يجب علينا تحويل هذه الحلقة غير الحتمية إلى مخطط مقيد ذي حالة (bounded, stateful graph). نقوم بذلك عن طريق قياس أربعة أبعاد محددة من التعقيد قبل كتابة أي عرض مقترح.

الأبعاد الأربعة لتعقيد الوكيل

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

إذا تجاوز المشروع حدودنا في أي من هذه المجالات، فلا نبنيه كوكيل واحد. بل نقسمه إلى نظام متعدد الوكلاء (multi-agent system) أو سير عمل مهيكل باستخدام LangGraph.

1. عدد عقد مخطط الحالة الدائري (Cyclic State Graph Node Count)

نقوم برسم خريطة لعملية اتخاذ القرار الخاصة بالوكيل كمخطط (graph). على عكس خطوط المعالجة (pipelines) البسيطة، غالباً ما تتطلب مخططات الوكلاء مسارات دائرية (cyclic paths) للتفكير، والتصحيح الذاتي، وإعادة المحاولة. كل حالة (مثل "استخراج البيانات"، "التحقق من المخطط"، "استدعاء واجهة برمجة تطبيقات ERP") تمثل عقدة (node). والتحولات بينها هي حواف (edges) (إما مباشرة أو مشروطة).

• ▸الوكلاء البسطاء (أقل من 4 عقد): مسارات خطية مع توجيه أساسي (if/else). مخاطر منخفضة، وتكاليف تشغيل متوقعة للغاية.
• ▸الوكلاء المعقدون (5-12 عقدة): توجيه ديناميكي، وحلقات تكرارية مع شروط إنهاء صارمة، وخطوات تحقق تتطلب تدخلاً بشرياً (human-in-the-loop). مخاطر متوسطة، تتطلب حدود حالة صارمة لمنع الحلقات اللانهائية.
• ▸الأنظمة متعددة الوكلاء (13 عقدة فأكثر): وكلاء مستقلون متعددون يتشاركون في حالة مركزية أو يتواصلون عبر عقدة مشرفة (supervisor node). تعقيد عالٍ، مصمم لأتمتة سير العمل على مستوى المؤسسات الكبرى.

2. صرامة مخطط الأدوات (Tool Schema Strictness)

جودة الوكيل من جودة أدواته. إذا كان الوكيل بحاجة إلى البحث في قاعدة بيانات المتجهات (vector database)، فإن مخطط الأداة يكون بسيطاً (سلسلة نصية للاستعلام). أما إذا كان الوكيل بحاجة إلى الكتابة في نظام SAP ERP، فإن مخطط الأداة يصبح معقداً للغاية، ويتطلب تحققاً صارماً باستخدام Pydantic، وإدارة رموز المصادقة (auth tokens)، وخطوات تحقق تجريبية (dry-run validation). تزيد المخططات المعقدة من مخاطر أخطاء استدعاء الأدوات من قبل النموذج (LLM)، مما يتطلب عقد معالجة أخطاء أكثر قوة.

3. حجم حمولة الحالة وتعقيد دالة الاختزال (State Payload Size & Reducer Complexity)

ما الذي يحتاج الوكيل إلى تذكره بين الخطوات؟ إذا كان يحتاج فقط إلى تمرير معرف معاملة واحد، فإن إدارة الحالة تكون بسيطة. أما إذا كان يجب عليه نقل حمولة JSON بحجم 50 كيلوبايت تمثل سجلاً طبياً أو فاتورة مؤسسة عبر عشر خطوات تحليل مختلفة، فإن خطر انحراف الحالة (state drift) - حيث يسقط النموذج (LLM) أو يغير مفاتيح في الـ JSON بالخطأ - يزداد بشكل أسي. نحن نحد من هذا الخطر باستخدام مخططات حالة صارمة من Pydantic ودوال اختزال (reducer functions) مخصصة للتعامل مع تحديثات الحالة بشكل حتمي، مما يحميك من تلف البيانات.

4. مجموعة بيانات التقييم وحجم حزمة اختبارات التراجع (Evaluation Dataset & Regression Suite Size)

لا يمكنك إطلاق وكيل في بيئة الإنتاج دون حزمة تقييم (evaluation suite). نحن نحدد نطاق مرحلة الاختبار بناءً على عدد حالات الاختبار الذهبية (golden test cases) (أزواج المدخلات والمخرجات) التي نحتاج إلى تشغيلها عبر مسار التقييم (Evaluation Pipeline) الخاص بنا (باستخدام Langfuse للتتبع و RAGAS لتقييم مقاييس مثل الأمانة المعرفية واستدعاء السياق) لضمان معدل دقة يبلغ 99% في المسارات الحرجة. هذا الاختبار الصارم يجنبك المخاطر الكارثية للفشل الصامت في بيئة الإنتاج.

مصفوفة Verel لتحديد النطاق

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

من خلال مطابقة مشروعك مع هذه المصفوفة، فإننا نلغي مفهوم "الصندوق الأسود للاستشارات" التقليدي. بالنسبة لمنصة SaaS متوسطة الحجم، فإن الانتقال من نهج البحث والتطوير (R&D) مفتوح الساعات إلى "الفئة 2: المخطط المنسق" يوفر في المتوسط 24,000 دولار من ساعات الهندسة المهدرة ويقلل وقت طرح المنتج في السوق بمقدار 6 إلى 8 أسابيع، مع وضع حد أقصى صارم لتكاليف الـ API الشهرية. إذا عُرض عليك مبلغ 5,000 دولار لنظام يتطلب عشرة تكاملات كتابة مختلفة لواجهات برمجة التطبيقات وبدون أي حواجز حماية تتطلب تدخلاً بشرياً، فأنت تشتري نموذجاً تجريبياً مكلفاً سيتعطل في اليوم الثالث. نحن لا نقدم مثل هذه العروض.

القيود على مستوى الكود: منع الحلقة اللانهائية

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

يستخدم هذا التنفيذ كلاً من LangGraph و LiteLLM لفرض حدود صارمة على عدد الخطوات، والتحقق من صحة وسيطات الأدوات باستخدام Pydantic v2، ومنع الوكيل من استنزاف ميزانية الـ API الخاصة بك.

import os
from typing import Annotated, Dict, Any, List, Literal
from typing_extensions import TypedDict
from pydantic import BaseModel, Field
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages
from litellm import completion

# 1. Define structured state with Pydantic-validated fields
class State(TypedDict):
    messages: Annotated[List[Dict[str, Any]], add_messages]
    user_id: int
    tax_rate: float
    execution_errors: List[str]

# 2. Define tool schemas for strict schema enforcement
class TaxCalculationSchema(BaseModel):
    user_id: int
    country_code: str = Field(..., description="ISO 3166-1 alpha-2 country code, e.g. 'AE' or 'US'")

def calculate_tax(payload: TaxCalculationSchema) -> Dict[str, Any]:
    """Calculate tax rate based on user location."""
    if payload.country_code == "AE":
        return {"tax_rate": 0.05, "status": "success"}
    return {"tax_rate": 0.15, "status": "success"}

# 3. Define the LLM Router node using LiteLLM
def call_model(state: State) -> Dict[str, Any]:
    messages = state["messages"]
    
    # We use LiteLLM for model-agnostic schema enforcement
    response = completion(
        model="azure/gpt-4o",
        messages=messages,
        tools=[{
            "type": "function",
            "function": {
                "name": "calculate_tax",
                "description": "Calculate tax rate based on user location.",
                "parameters": TaxCalculationSchema.model_json_schema()
            }
        }],
        tool_choice="auto"
    )
    
    message = response.choices[0].message
    return {"messages": [message]}

# 4. Define deterministic tool execution node with schema validation
def execute_tools(state: State) -> Dict[str, Any]:
    last_message = state["messages"][-1]
    tool_calls = last_message.get("tool_calls", [])
    
    results = []
    errors = []
    for tool_call in tool_calls:
        if tool_call["function"]["name"] == "calculate_tax":
            try:
                # Validate args dynamically using Pydantic v2
                args = TaxCalculationSchema.model_validate_json(tool_call["function"]["arguments"])
                result = calculate_tax(args)
                results.append({
                    "role": "tool",
                    "tool_call_id": tool_call["id"],
                    "name": "calculate_tax",
                    "content": str(result)
                })
            except Exception as e:
                errors.append(f"Tool validation failed: {str(e)}")
                results.append({
                    "role": "tool",
                    "tool_call_id": tool_call["id"],
                    "name": "calculate_tax",
                    "content": f"Error: Invalid arguments. {str(e)}"
                })
    
    return {"messages": results, "execution_errors": errors}

# 5. Routing logic
def route_after_model(state: State) -> Literal["tools", "__end__"]:
    last_message = state["messages"][-1]
    if last_message.get("tool_calls"):
        return "tools"
    return "__end__"

# Build the LangGraph StateGraph
workflow = StateGraph(State)
workflow.add_node("agent", call_model)
workflow.add_node("tools", execute_tools)

workflow.add_edge(START, "agent")
workflow.add_conditional_edges("agent", route_after_model)
workflow.add_edge("tools", "agent")

app = workflow.compile()

# Execute with strict step limits (recursion_limit)
if __name__ == "__main__":
    inputs = {
        "messages": [{"role": "user", "content": "Calculate tax for user 102 in AE"}],
        "user_id": 102,
        "tax_rate": 0.0,
        "execution_errors": []
    }
    
    # Enforce hard limit of 10 steps to prevent infinite routing loops
    try:
        config = {"recursion_limit": 10}
        for event in app.stream(inputs, config=config):
            for k, v in event.items():
                print(f"Node '{k}' executed.")
    except Exception as e:
        # Catch GraphRecursionError if step limit is exceeded
        print(f"Execution boundary triggered: {str(e)}")

هذه البنية المعمارية متينة للغاية. فهي تضمن أنه بغض النظر عما يقرره النموذج (LLM)، لا يمكن للنظام تنفيذ أكثر من 10 خطوات، ولا يمكنه استدعاء أدوات غير معتمدة، وسينتقل إلى حالة بديلة نظيفة (fallback state) في حال فشل استدعاء الـ API أو فشل التحقق من الصحة.

مخرج الطوارئ للتدخل البشري (Human-in-the-Loop)

إن سر تقديم وكلاء ذكاء اصطناعي ذوي موثوقية عالية بميزانية ثابتة لا يكمن في السعي وراء استقلالية كاملة بنسبة 100%.

إن إيصال الوكيل إلى استقلالية بنسبة 90% أمر مباشر وسهل نسبياً. أما الوصول به إلى استقلالية بنسبة 100% فيتطلب زيادة أسية في الميزانية، والوقت، والاختبار. إن مطاردة الـ 10% الأخيرة هي فخ مالي؛ فهي تزيد عادةً من تكاليف التطوير بنسبة تتراوح بين 300% إلى 500% للتعامل مع الحالات الاستثنائية الغريبة، وأخطاء الترجمة، ومحاولات اختراق الموجهات الخبيثة (مثل الاختراق غير المباشر عبر مستندات يرفعها المستخدم) والتي لا تحدث إلا بنسبة 1% من الحالات.

نحن نصمم كل نظام مع "مخرج طوارئ" صريح. إذا انخفضت درجة ثقة التقيية الذاتي للنموذج (LLM) عن 0.85 (يتم تقييمها عبر مخططات JSON المهيكلة باستخدام logprobs أو نموذج حكم مساعد يقوم بتشغيل Claude 3.5 Haiku)، أو إذا وصلت حالة النظام إلى عقدة غير مرسومة في بنية LangGraph الخاصة بنا، فإن الوكيل لا يخمن. بل يقوم بحزم حمولة الحالة الحالية، وتجميد التنفيذ، وتسليم المهمة إلى موظف بشري عبر Slack webhook، أو إشعار بريد إلكتروني، أو لوحة تحكم مخصصة.

يحمي هذا النهج علامتك التجارية، ويحافظ على نظافة قاعدة بياناتك، ويوفر عليك مئات الآلاف من تكاليف البحث والتطوير (R&D)، مع القضاء تماماً على مخاطر السمعة الناتجة عن هلوسة الذكاء الاصطناعي وتقديم بيانات خاطئة لعميل من المؤسسات الكبرى. لا يتعين علينا تسعير التعقيد اللانهائي للحالات الاستثنائية النادرة؛ بل نبني ببساطة مساراً نظيفاً يحيل المهمة إلى عنصر بشري يمكنه التعامل معها.

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

س: ما هو العائد على الاستثمار (ROI) وفترة الاسترداد النموذجية لأنظمة الوكلاء هذه؟

بالنسبة لعملائنا من المؤسسات الكبرى وشركات SaaS، فإن المحركات الرئيسية للعائد على الاستثمار هي التوفير المباشر في تكاليف العمالة (تقليل عبء الدعم الفني أو إدخال البيانات اليدوي في المكاتب الخلفية بنسبة 70-80%) وتسريع وتيرة المعاملات. عادةً ما يغطي وكيل من الفئة 2 (بتكلفة تتراوح بين 10,000 إلى 18,000 دولار) تكلفته في غضون 3 إلى 5 أشهر من تشغيله، وذلك من خلال استعادة أكثر من 120 ساعة تشغيلية شهرياً ومنع أخطاء إدخال البيانات اليدوية المكلفة.

س: ماذا يحدث إذا قام مزود النموذج (LLM) بتحديث نموذجه وتسبب ذلك في عطل وكيلنا؟

نحن لا نربط نظامك بواجهة برمجة تطبيقات لنموذج واحد. نحن نبني وكلائنا باستخدام LiteLLM كبوابة موحدة، مما يسمح لنا بتبديل النماذج (على سبيل المثال، من Claude 3.5 Sonnet إلى GPT-4o أو نموذج Qwen3.5 محلي) عبر تغيير بسيط في الإعدادات. خلال مرحلة تحديد النطاق، نضع مجموعة بيانات تقييم أساسية. وإذا قام المزود بتحديث النموذج، نقوم بتشغيل وكيلك عبر حزمة تقييم CI/CD المؤتمتة الخاصة بنا (لتنفيذ أكثر من 100 حالة اختبار ذهبية على Langfuse وتقييمها مقابل مقاييس RAGAS مثل الأمانة المعرفية وملاءمة الإجابة) للتحقق من أن مقاييس الدقة وزمن الاستجابة لا تزال تلبي متطلبات الإنتاج قبل نشر التغيير.

س: لماذا تتقاضون سعراً ثابتاً بدلاً من سعر استشاري بالساعة؟

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

س: كيف تضمنون ألا ينفذ الوكيل أوامر ضارة؟

نحن نطبق فصلاً مادياً صارماً بين محرك الاستدلال (reasoning engine) الخاص بالوكيل وبيئة التنفيذ. لا يمتلك الوكيل وصولاً مباشراً عبر SSH، أو بيانات اعتماد قاعدة البيانات، أو مفاتيح API مفتوحة الصلاحيات. يمكنه فقط إنشاء حمولات JSON يتم إرسالها إلى واجهة برمجة تطبيقات (API) مقيدة للغاية. تقوم هذه البوابة بالتحقق من صحة الحمولة مقابل مخطط Pydantic صارم وتدقيقها وفقاً لقواعد منطق العمل (مثل: "عدم معالجة أي استرداد مالي يتجاوز 500 دولار دون موافقة المدير") قبل تنفيذ أي عمليات كتابة.

س: هل نحتاج إلى دفع تكاليف تراخيص LLM باهظة الثمن للمؤسسات؟

لا. نحن نصمم الأنظمة لتعمل على واجهات برمجة التطبيقات التجارية القياسية (التي تُحتسب تكلفتها بناءً على الرموز المستهلكة - tokens) أو على نماذج مفتوحة المصدر (مثل Llama 3.3 أو Qwen3.5) المستضافة على بنية تحتية لوحدات معالجة الرسوميات بدون خادم (serverless GPU) مثل Modal أو runpod.io. وخلال مرحلة تحديد النطاق، نقوم بإجراء تقدير للتكلفة بناءً على حجم الاستخدام الشهري المتوقع لضمان توافق تكلفة الرموز التشغيلية مع هوامش ربح عملك.

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

احجز مكالمة معمارية مدتها 30 دقيقة مع مهندس أول