إيقاف بناء الوكلاء غير المستقرين: استخدم سير العمل والذاكرة

أنماط حتمية للنماذج غير الحتمية.

LLMs لديها خاصية غريبة: فهي بارعة في فهم الفروق الدقيقة ولكنها سيئة في اتباع الوصفات. إذا أعطيت GPT‑4 مشكلة غامضة فستفكر في الاحتمالات. إذا أعطيتها تسلسلًا دقيقًا من الخطوات، قد تتخطى الخطوة 3 لأن الخطوة 5 “بدت أكثر صلة”.

هذا ليس خللًا في النموذج. إنه سمة أساسية للأنظمة الاحتمالية التي تحاول حل مشاكل حتمية.

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

الحل ليس تحسين المطالبات. إنه معرفة متى نتوقف عن طلب من الـ LLM “التفكير” ونبدأ بإخباره “الامتثال”.

عندما تكون الحتمية أفضل من الإبداع

فكر فيما يحدث عندما تحتاج إلى معالجة تذكرة دعم. منطق الأعمال في العالم الحقيقي يبدو تقريبًا هكذا:

1. جلب تفاصيل التذكرة من قاعدة البيانات
2. التحقق مما إذا كان المستخدم مؤهلاً للاسترداد (قواعد السياسة)
3. التأكد من وجود المعاملة ولم يتم استردادها مسبقًا
4. حساب مبلغ الاسترداد
5. معالجة عكس الدفع
6. تحديث حالة التذكرة
7. إرسال بريد تأكيد

يمكنك أن تسلم هذا للـ LLM كتمرين استدعاء أدوات. وفقًا لتجربتي، هذا دعوة للمشاكل. قد يقرر النموذج أن الخطوتين 2 و3 “هي في الأساس نفس الشيء” ويتخطى إحداهما. أو قد يعالج الاسترداد قبل التحقق من الأهلية لأن المستخدم بدا غاضبًا.

توجد سير العمل لهذا السيناريو بالضبط. ليست مثيرة، لكن هذا هو المقصود.

بناء مخطط نشاطات الطقس

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

import { createWorkflow, createStep } from '@mastra/core/workflows';
import { Agent } from '@mastra/core/agent';
import { openai } from '@ai-sdk/openai';
import { z } from 'zod';

// Step 1: Fetch weather data (Deterministic)
const fetchWeather = createStep({
  id: 'fetch-weather',
  description: 'Fetches weather forecast for a given city',
  inputSchema: z.object({
    city: z.string(),
  }),
  outputSchema: z.object({
    location: z.string(),
    temperature: z.number(),
    conditions: z.string(),
    precipitationChance: z.number(),
  }),
  execute: async ({ inputData }) => {
    // ... (fetch logic) ...
    const weather = await fetch(`https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current=temperature_2m,weather_code&daily=precipitation_probability_mean`).then(r => r.json());

    return {
      location: inputData.city,
      temperature: weather.current.temperature_2m,
      conditions: getWeatherCondition(weather.current.weather_code),
      precipitationChance: weather.daily.precipitation_probability_mean[0],
    };
  },
});

// Step 2: Agent suggests activities (Creative)
const activityPlanner = new Agent({
  id: 'activity-planner-agent',
  name: 'Activity Planner',
  instructions: `You are a local activities expert. Based on weather conditions, suggest 3-5 appropriate activities.
    - For rain (>50% precipitation), prioritize indoor activities
    - For extreme temperatures, consider climate-appropriate options
    - Always include one adventurous and one relaxing option`,
  model: openai('gpt-5'),
});

const planActivities = createStep({
  id: 'plan-activities',
  description: 'Uses AI to suggest activities based on weather',
  inputSchema: z.object({
    location: z.string(),
    temperature: z.number(),
    conditions: z.string(),
    precipitationChance: z.number(),
  }),
  outputSchema: z.object({
    activities: z.string(),
  }),
  execute: async ({ inputData }) => {
    const prompt = `Weather in ${inputData.location}: ${inputData.temperature}°C...`;
    const response = await activityPlanner.generate(prompt);
    return { activities: response.text };
  },
});

// The Pipeline
export const activityPlannerWorkflow = createWorkflow({
  id: 'activity-planner',
  inputSchema: z.object({ city: z.string() }),
  outputSchema: z.object({ activities: z.string() }),
})
  .then(fetchWeather)
  .then(planActivities);

activityPlannerWorkflow.commit();

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

متى يجب التفكير في استخدام سير العمل:

• لديك تسلسل معروف من الخطوات يجب أن يحدث بترتيب محدد
• تحتاج إلى مراقبة في كل مرحلة (سجلات، مقاييس، توقيت)
• تحتاج إلى منطق إعادة محاولة للواجهات الخارجية غير المستقرة
• لا يمكن “تفسير” قواعد العمل – يجب اتباعها بدقة

مشكلة نافذة السياق التي لا يتحدث عنها أحد

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

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

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

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

الذاكرة العاملة مقابل التخزين طويل‑الأمد

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

import { Agent } from '@mastra/core/agent';
import { Memory } from '@mastra/memory';
import { LibSQLStore } from '@mastra/libsql';

export const memoryAgent = new Agent({
  id: 'memory-agent',
  name: 'Memory Agent',
  instructions: 'You are a helpful assistant with perfect recall of our conversations.',
  model: openai('gpt-5'),
  memory: new Memory({
    storage: new LibSQLStore({
      id: 'memory-agent-store',
      url: 'file:../mastra.db',
    }),
    options: {
      lastMessages: 20,  // Keep last 20 messages in context
      semanticRecall: {
        enabled: true,  // Use embeddings to find old stuff
        topK: 5,
        threshold: 0.7,
      },
    },
  }),
});

هذا ما يحدث عمليًا. يطرح مستخدم سؤالًا: “ما هو المطعم الإيطالي الذي أوصيت به الشهر الماضي؟”

بدون البحث الدلالي، يرى الوكيل آخر 20 رسالة فقط. توصية المطعم كانت في الرسالة رقم 487 من 506. لذا اختفت. يرد الوكيل: “ليس لدي تلك المعلومة.”

مع البحث الدلالي:

1. يُحوَّل الاستعلام إلى تمثيل متجه: [0.234, -0.567, 0.891, ...]
2. يُقارن هذا المتجه مع الرسائل التاريخية
3. الرسالة 487 (“أوصي بـ Trattoria Bella – الكاربونارا لديهم لا تُقاوم”) تحصل على تشابه 0.89
4. تُحقن تلك الرسالة في السياق الحالي
5. يرد الوكيل: “أوصيت بـ Trattoria Bella. الكاربونارا هي ما جذب انتباهي.”

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

التنسيق عبر شبكات الوكلاء

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

توفر شبكات الوكلاء منسقًا يقرر أي وكيل متخصص أو سير عمل يُستدعى بناءً على المهمة. فكر فيها كـ “موازن تحميل ذكي” لقدرات الذكاء الاصطناعي.

export const coordinatorAgent = new Agent({
  id: 'coordinator-agent',
  name: 'Research Coordinator',
  instructions: `You are a network of researchers and writers.
    - Use researchAgent for gathering facts
    - Use writingAgent for producing final content
    - Use weatherTool for current weather data
    - Use activityPlannerWorkflow for location-based planning

    Always produce comprehensive, well-structured responses.`,
  model: openai('gpt-5'),

  // Available primitives
  agents: { researchAgent, writingAgent },
  workflows: { activityPlannerWorkflow },
  tools: { weatherTool },

  // Network requires memory
  memory: new Memory({
    storage: new LibSQLStore({ id: 'network-store', url: 'file:../network.db' }),
  }),
});

عند استعلام هذا الشبكة، يقوم المنسق بتحليل الطلب وتوجيهه وفقًا لذلك:

• "أحتاج إلى حقائق حول X" يُفعِّل وكيل البحث
• "خطط لعطلة نهاية أسبوع في سياتل" يُشغِّل سير عمل مخطط النشاط
• "اكتب تقريرًا عن Y" يُستدعي وكيل الكتابة

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

تجميع المكوّنات

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

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

لا شيء من هذا يَبدو براقًا. لكن بعد مشاهدة عدد كافٍ من “الوكلاء المستقلين بالكامل” يفشلون في الإنتاج، أصبحت أُقدِّر الاعتمادية المملة على عدم التنبؤ المثير.

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

موارد

• توثيق سير عمل Mastra
• توثيق ذاكرة Mastra
• الكود الكامل للعرض التوضيحي

اقرأ السلسلة

1. توجيه LLM
2. الأمان والضوابط
3. MCP وتكامل الأدوات
4. سير العمل والذاكرة (هذه المشاركة)