Postman تطلق Agent Mode على Amazon Bedrock لخدمة 40 مليون مطوّر

كشفت Postman وAWS كيف بُني Agent Mode، وهو وكيل ذكاء اصطناعي داخل منصة لتصميم واجهات API واختبارها وتوثيقها. يبلغ جمهور المنتج نحو 40 مليون مطوّر، ويستدعي الوكيل النماذج عبر Amazon Bedrock. الفكرة الرئيسية في العرض: بناء وكيل يبدو جيدًا في العرض التجريبي أمر سهل نسبيًا، أما جعله يعمل بثبات أمام جمهور بهذا الحجم فصعب، وتكمن الصعوبة في البنية المحيطة بالنموذج.

ثلاثة مبادئ يقوم عليها Agent Mode

يصف الكتّاب ثلاثة أنماط. الأول: التحكم في «تضخم الأدوات» (tool sprawl). في منصة مثل Postman عدد الإجراءات كبير جدًا: إنشاء مجموعة (collection)، وتشغيل طلب، وتعديل البيئة، وتوليد الاختبارات، وتحديث التوثيق. وإذا مُنح الوكيل هذه الإجراءات كلها في قائمة واحدة، فستستحوذ أوصاف الأدوات على حصة ملحوظة من السياق. عندها يبدأ النموذج بالخلط بين الوظائف المتشابهة، ويستدعي الأداة الخاطئة بوتيرة أكبر. لذلك لا بد من تضييق مجموعة الأدوات وتنظيمها عن قصد.

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

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

لماذا Amazon Bedrock هنا؟

يؤدي Bedrock في هذه القصة دور طبقة البنية التحتية. وهو خدمة مُدارة من AWS يمكن عبرها الوصول إلى نماذج أساسية مختلفة من خلال API موحّد، دون تشغيل مجموعات GPU خاصة. وبالنسبة إلى منتج يضم عشرات الملايين من المستخدمين، يعني ذلك التوسع لتحمل ذروة الحمل، وآليات أمان مألوفة للعملاء من الشركات، وإمكانية تبديل النماذج دون إعادة كتابة التطبيق بالكامل.

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

ما المعروف من الإعلان

• المنتج: Agent Mode في Postman، وهو وكيل للعمل مع واجهات API.
• الجمهور: نحو 40 مليون مطوّر.
• منصة الاستدلال: Amazon Bedrock.
• الأنماط الرئيسية: الحدّ من مجموعة الأدوات، والقراءة عبر المخططات، وإدارة السياق.
• لم يُكشف عنه: النماذج المستخدمة، وزمن الاستجابة، وتكلفة الطلب، ومقاييس الجودة.

ما الذي يمكن أخذه إلى بنيتك التقنية

إذا كنت تبني وكيلًا خاصًا بك، ففي المادة ثلاثة استخدامات عملية.

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

الثاني: أنشئ للوكيل طبقة لقراءة البيانات فوق مخططات رسمية، سواء كانت OpenAPI أو JSON Schema أو مخطط قاعدة بيانات. فالوكيل الذي يطلب الجزء المطلوب بحسب البنية يستهلك سياقًا أقل، ويهلوس (hallucinate) بوتيرة أقل من وكيل أُلقيت أمامه الوثائق كاملة.

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

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