كيفية بناء أدوات (Custom Tools) خاصة للـ LangChain Agents تناسب عملك

لماذا تحتاج إلى Custom Tools داخل LangChain Agents؟

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

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

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

المعمارية الهندسية لتدفق العمل بين LLM والأدوات

أفضل طريقة لفهم بناء الأدوات هي النظر إلى النظام على شكل طبقات:

• طبقة الإدخال: سؤال المستخدم أو الحدث التشغيلي القادم من واجهة أو API.
• طبقة التوجيه: الـ Agent يقرر هل يجيب مباشرة أم يحتاج أداة.
• طبقة الأدوات: دوال مخصصة تنفذ مهام مثل البحث في SQL، استرجاع وثائق RAG، أو حساب أسعار.
• طبقة التحقق: فحص المدخلات والمخرجات، ومنع الاستخدام الخاطئ أو Prompt Injection.
• طبقة الملاحظة: تسجيل الخطوات، الزمن، التكلفة، وعدد Tokens وربطها مع LangSmith.

هذا التدفق يجعل النظام أقل عشوائية من الاعتماد على برومبت طويل فقط. كما أنه يفصل المنطق التجاري عن منطق النموذج. وهذه نقطة مهمة جداً لأي تطبيق إنتاجي.

ما الذي يجعل الأداة “مناسبة لعملك”؟

ليست كل أداة نافعة تجارياً. الأداة الجيدة في بيئة الأعمال يجب أن تحقق 4 خصائص:

• وضوح الهدف: تؤدي وظيفة واحدة محددة مثل جلب حالة طلبية أو حساب عمولة.
• مدخلات مضبوطة: تستقبل حقولاً واضحة بدلاً من نص حر غير منضبط.
• مخرجات قابلة للمعالجة: الأفضل أن تعيد JSON أو نصاً بنيةُه ثابتة، كما شرحنا في Output Parsers.
• صلاحيات محدودة: لا تمنح الأداة وصولاً مفتوحاً إلى كل شيء.

على سبيل المثال، بدلاً من أداة اسمها query_database بشكل عام، صمّم أداة أدق مثل get_order_status أو find_customer_invoice. كلما زادت الدقة، زادت إمكانية الاعتماد على النظام.

خطوات بناء أداة مخصصة داخل LangChain

1) تجهيز البيئة والمكتبات

قبل أي شيء تأكد من إعداد بيئتك كما في تثبيت مكتبات Python الأساسية، ثم ثبّت الحزم اللازمة:

pip install langchain langchain-openai langchain-core pydantic

2) تعريف منطق العمل الحقيقي

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

from typing import Optional

FAKE_ORDERS_DB = {
    "ORD-1001": {"status": "shipped", "customer": "Ahmed", "eta_days": 2},
    "ORD-1002": {"status": "processing", "customer": "Sara", "eta_days": 5},
    "ORD-1003": {"status": "delivered", "customer": "Mona", "eta_days": 0},
}

def fetch_order_status(order_id: str) -> dict:
    order = FAKE_ORDERS_DB.get(order_id)
    if not order:
        return {"found": False, "message": "Order not found"}
    return {
        "found": True,
        "order_id": order_id,
        "status": order["status"],
        "customer": order["customer"],
        "eta_days": order["eta_days"],
    }

3) تغليف الدالة كأداة باستخدام مخطط مدخلات

استخدام Pydantic مهم جداً لأنه يفرض بنية صارمة على المدخلات، ويمنع تمرير قيم غامضة للنظام.

from pydantic import BaseModel, Field
from langchain_core.tools import tool

class OrderStatusInput(BaseModel):
    order_id: str = Field(..., description="The order ID, e.g. ORD-1001")

@tool(args_schema=OrderStatusInput)
def get_order_status(order_id: str) -> dict:
    """Return the status of a customer order from the internal system."""
    return fetch_order_status(order_id)

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

4) ربط الأداة مع النموذج والـ Agent

بعد ذلك نربط الأداة مع نموذج محادثي. إذا كنت تحتاج تهيئة الاتصال من الصفر راجع جلب مفاتيح API وكتابة أول سكربت اتصال.

from langchain_openai import ChatOpenAI
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

tools = [get_order_status]

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a helpful business operations agent. Use tools when needed."),
    ("human", "{input}"),
    ("placeholder", "{agent_scratchpad}")
])

agent = create_tool_calling_agent(llm=llm, tools=tools, prompt=prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

response = agent_executor.invoke({
    "input": "Check the status of order ORD-1002 and explain it briefly."
})

print(response)

كيف يقرر الـ Agent استخدام الأداة؟

في بيئات ReAct أو Tool Calling لا يتم استدعاء الأداة عشوائياً. النموذج يقرأ:

• وصف الأداة
• أسماء الوسائط
• سؤال المستخدم
• السياق النظامي داخل البرومبت

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

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

هذه الصياغة تقلل الهلوسة وتدفع النموذج لاحترام حدود البيانات المتاحة.

دمج أدوات الأعمال مع RAG وVector DB

من أقوى الأنماط الإنتاجية أن تجمع بين أدوات تشغيلية وأدوات معرفية. مثلاً:

• أداة تشغيلية تسترجع حالة طلبية من قاعدة الشركة.
• أداة معرفية تسترجع سياسة الشحن من نظام RAG.

بهذا يستطيع الـ Agent أن يجيب: “طلبك قيد المعالجة، وزمن الشحن المعتاد حسب السياسة هو 3 إلى 5 أيام”. هنا هو لم “يؤلف” المعلومة؛ بل ركبها من مصدرين موثوقين.

إذا كنت تبني هذا المسار، فراجع مقالات Embeddings، Vector Databases، وRetriever، لأن الأداة يمكن أن تكون ببساطة واجهة تستدعي مسترجعاً داخلياً.

أفضل الممارسات الهندسية عند تصميم الأدوات

تحديد نطاق الأداة بدقة

الأداة الصغيرة المحددة أفضل من أداة عملاقة متعددة السلوكيات. هذا يقلل الالتباس عند الاختيار ويُسهّل الاختبار.

إرجاع مخرجات منظمة

حتى لو كان الجواب النهائي نصياً للمستخدم، احرص أن تعيد الأداة داخلياً بنية منظمة مثل dict أو JSON.

إضافة الحماية والتحقق

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

المراقبة والتقييم

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

حالات استخدام مباشرة تناسب الشركات

• أداة لجلب بيانات العملاء من CRM.
• أداة لتحليل ملفات CSV كما في تحليل Excel/CSV مباشرة.
• أداة Text-to-SQL للاستعلام من قواعد البيانات التحليلية.
• أداة للبحث في مستندات الشركة عبر RAG.
• أداة لأتمتة العمليات المتكررة عبر Selenium + AI.

الخلاصة العملية

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

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