تقييم وكلاء استخدام الأدوات في بيئات العالم الحقيقي

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

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

ما هو OpenEnv؟

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

يستخدم OpenEnv واجهة برمجة تطبيقات موجهة للصالة الرياضية (reset, step, action, observations) مثل صالة الألعاب الرياضية في OpenAI. يستخدم OpenEnv أيضًا واجهة استدعاء أداة MCP القياسية للاتصال بالبيئات التي توفر واجهة متسقة عبر المجالات ومحاكاة لبيئات الإنتاج.

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

صالة التقويم الرياضية: معيار إنتاجي

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

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

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

from openenv_wrapper.client import MCPEnvClient
from openenv_wrapper.data_models import MCPAction

with MCPEnvClient.from_hub(base_url="TuringEnterprises/calendar-gym") as client:
    
    result = client.reset()
    print("Reset successful:", result.observation.success)

    
    result = client.step(MCPAction(action_type="ListToolsAction"))
    print("Available tools:", len(result.observation.tools_list))

    
    result = client.step(MCPAction(
        action_type="ToolCallAction",
        tool_name="calendars_list",
        arguments={}
    ))
    calendars = result.observation.tool_result["items"]
    print("Calendars:", calendars)

    
    result = client.step(MCPAction(
        action_type="ToolCallAction",
        tool_name="events_insert",
        arguments={
            "calendarId": "primary",
            "summary": "Team Sync",
            "start": {"dateTime": "2026-01-15T14:00:00Z"},
            "end": {"dateTime": "2026-01-15T15:00:00Z"}
        }
    ))
    print("Event created:", result.observation.success)

فيما يلي مقتطف مما يعود به Calendar Gym عند الاتصال ListToolsAction. يتضمن كل إدخال اسم الأداة بالإضافة إلى مخطط الإدخال (ما هي الوسائط التي تقبلها الأداة).

{
  "tools_list": [
    {
      "name": "calendars_list",
      "description": "List calendars visible to the current user.",
      "input_schema": {
        "type": "object",
        "properties": {},
        "additionalProperties": false
      }
    },
    {
      "name": "events_insert",
      "description": "Create an event in a calendar.",
      "input_schema": {
        "type": "object",
        "properties": {
          "calendarId": { "type": "string" },
          "summary": { "type": "string" },
          "start": {
            "type": "object",
            "properties": { "dateTime": { "type": "string" } },
            "required": ["dateTime"]
          },
          "end": {
            "type": "object",
            "properties": { "dateTime": { "type": "string" } },
            "required": ["dateTime"]
          }
        },
        "required": ["calendarId", "summary", "start", "end"]
      }
    }
  ]
}

ما تعلمناه

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

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

الغموض يؤدي إلى تدهور الأداء بشكل كبير. وكلاء حققوا ما يقرب من نجاح 90% في المهام ذات معرفات التقويم الصريحة، ولكن انخفض النجاح إلى ما يقرب من 40% عندما تمت صياغة نفس المهام باستخدام أوصاف اللغة الطبيعية. يبدو من الضروري إجراء بحث وتحقق أقوى في حلقات الوكيل – بدلاً من الاعتماد على LLM لحل المراجع دون مساعدة.

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

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

التطلع إلى الأمام

يوفر OpenEnv أساسًا لاختبار الوكلاء في ظل ظروف واقعية، ويوضح Calendar Gym كيف يمكن للنطاقات التي تبدو بسيطة أن تطرح تحديات عميقة في التفكير وحل الغموض واستخدام الأدوات. ومن خلال تقييم الوكلاء حيث يكون الفشل قابلاً للقياس والقيود حقيقية، نكتسب رؤية أوضح حول ما يلزم لبناء وكلاء يعملون بشكل موثوق في الإنتاج.

للتعمق بشكل أعمق في تصميم Calendar Gym ومنهجية قياس الأداء والنتائج الكمية، استكشف المقالة الفنية الكاملة على موقع Turing. لاستكشاف نسخة من Calendar Gym، قم بزيارة مساحة Calendar Gym.

ملحق: حالات الأخطاء الشائعة في استخدام الأداة

من الناحية العملية، نادرًا ما تفشل عمليات تكامل الأدوات بطرق مثيرة؛ إنهم يفشلون في الأمور الصغيرة التي يمكن التنبؤ بها. عند توصيل أدوات MCP بواجهات برمجة التطبيقات الحقيقية (مثل عمليات التقويم)، واجهنا عددًا من المشكلات المتكررة.

تم العثور على حالات خطأ محددة في البرية

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

1. أخطاء التحقق من صحة المخطط (الوسائط المفقودة أو المشوهة)

يستدعي الوكيل أداة صالحة (على سبيل المثال events_insert)، ولكن الوسائط لا تتطابق مع مخطط JSON المُعلن.

• الحقول المطلوبة مفقودة مثل calendarId
• التداخل غير الصحيح start / end
• تمرير سلسلة حيث من المتوقع وجود كائن.

{
  "ok": false,
  "error_type": "validation_error",
  "tool_name": "events_insert",
  "message": "Invalid arguments for tool 'events_insert'.",
  "details": {
    "missing_required_fields": ["calendarId", "end"],
    "invalid_fields": [
      {
        "field": "start",
        "expected_type": "object",
        "received_type": "string"
      }
    ]
  }
}

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

2. أخطاء الإذن/الترخيص (401/403)

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

• نطاقات OAuth مفقودة
• رمز الوصول منتهي الصلاحية
• يفتقر المستخدم إلى حق الوصول للكتابة إلى التقويم الهدف

{
  "ok": false,
  "error_type": "permission_error",
  "tool_name": "events_insert",
  "http_status": 403,
  "message": "The authenticated user does not have write access to calendar 'primary'.",
  "remediation": [
    "Ensure the OAuth token includes calendar write scope.",
    "Verify the user has edit access to the target calendar.",
    "Reconnect the integration if the token has expired."
  ]
}

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

3. أخطاء التاريخ/التنسيق (مشكلات RFC3339 والمنطقة الزمنية)

تم رفض الحدث بواسطة واجهة برمجة التطبيقات (API)، أو تم إنشاؤه في وقت غير متوقع.

• إزاحة المنطقة الزمنية مفقودة
• تنسيق وقت غير RFC3339
• التداخل غير الصحيح start.dateTime أو end.dateTime
• خلط التوقيت المحلي والتوقيت العالمي المنسق (UTC) دون تحديد الإزاحة

{
  "ok": false,
  "error_type": "format_error",
  "tool_name": "events_insert",
  "message": "Invalid datetime format for field 'start.dateTime'.",
  "details": {
    "received": "02/11/2026 9:30 AM",
    "expected_format": "RFC3339 (e.g. 2026-02-11T09:30:00-05:00)"
  }
}

يمكننا التخفيف من ذلك من خلال توحيد RFC3339 مع إزاحات المنطقة الزمنية الواضحة (على سبيل المثال 2026-02-11T09:30:00-05:00). قم بتضمين مثال واحد صحيح على الأقل للتاريخ والوقت في وثائقك لترسيخ سلوك النموذج وتقليل عمليات إعادة محاولات الإصلاح.