ما تعلمناه من إطلاق منتج بحزمة تطوير تطبيقات ChatGPT

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

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

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

• ما نجح معنا هو وضوح الأدوات وسلوك الأدوات المصغّرة والخطوات التالية. اعتمدنا على هذه العناصر لتحديد التدفق، لا على النماذج اللغوية الكبيرة (LLM). بلغت فائدة النموذج أقصاها حين كان يشرح النتائج التي اختارها النظام بالفعل.

• فيما يلي: كيفية الاختيار، ثم ما نجح وما لم ينجح.

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

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

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

• عدم الحاجة إلى بناء منتج دردشة مخصص واستضافته—فقد أراد الوصول إلى المستخدمين داخل ChatGPT، لا إنشاء واجهة مستقلة لمساعد آخر.

• الدردشة مع واجهة مستخدم صغيرة ومخصصة للمهمة—بضع خطوات مركّزة عبر أدوات مصغّرة، لا منتجًا متكاملًا آخر داخل سير العمل.

• إتاحة وظائف الواجهة الخلفية عبر أدوات MCP—أي استدعاء قياسي للأدوات، لا بيئة تشغيل مخصصة لوكيل يمتلكها العميل بالكامل.

• إمكانية اكتشافه داخل ChatGPT—بحيث يجد المستخدمون سير العمل حيث يعملون بالفعل.

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

يربط التطبيق المبني بحزمة تطوير التطبيقات ثلاثة عناصر:

1. بيئة تشغيل الوكيل في ChatGPT

2. أدوات MCP الخاصة بك

3. واجهة الأداة المصغّرة الخاصة بك

التدفق عمليًا:

1. يطلب المستخدم شيئًا من ChatGPT.

2. قد يستدعي ChatGPT إحدى أدوات MCP الخاصة بك.

3. يعيد خادمك نتيجة منظَّمة للأداة.

4. يقرأ ChatGPT النتيجة ويقرر الخطوة التالية: استدعاء مزيد من الأدوات، أو الرد على المستخدم، أو كليهما. إذا أرفقت أداة مصغّرة بتلك الأداة، فيمكن أن تظهر خلال هذه الجولة.

5. يتابع المستخدم عبر الدردشة أو الأداة المصغّرة، بنص متابعة أو اختيار أو استدعاء أداة تطلقه الأداة المصغّرة. يؤدي ذلك إلى تحديث المحادثة؛ فيُجري ChatGPT جولة أخرى وتتكرر الخطوات من 2 إلى 4 حتى إنجاز المهمة.

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

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

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

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

استخدم حزمة تطوير التطبيقات عندما تريد

• إطلاق سير عمل في ChatGPT بسرعة.

• جعل ChatGPT يستضيف المحادثة.

• الجمع بين اللغة الطبيعية وبضع خطوات مركّزة في واجهة المستخدم.

• تجنب بناء واجهة دردشة وحاوية وكيل وآلية اكتشاف خاصة بك.

تكتسب النقطة الأخيرة أهمية خاصة عندما يعمل مستخدموك بالفعل في ChatGPT.

ابنِ وكيلك الخاص عندما تحتاج إلى

• تدفق ثابت خطوة بخطوة يمكنك فرضه برمجيًا.

• واجهة مستخدم ومسار تأكيد مخصصين تملكهما بالكامل.

• نموذج خاص بك للذاكرة والحالة.

• سلوك يجب أن يكون متوقعًا في كل تشغيل.

• بيانات التتبع والسجلات والمقاييس الخاصة بالوكيل.

إذا كان المخطط ومطالبات النظام وسير العمل الكامل هي جوهر منتجك، فعادةً تكون البنية المخصصة أنسب.

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

يبدو المسار المثالي سهلًا: يطلب المستخدم، وتعمل الأداة، وتعود البيانات، ثم تظهر الأداة المصغّرة عندما يلزم اتخاذ قرار.

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

كانت البنية التقنية للمشروع مباشرة: FastMCP وPydantic وReact وTypeScript. ولم يكن دمجها مشكلة. تمثّل العمل الفعلي في جعل النموذج والأدوات وواجهة المستخدم تتفق على ما سيحدث تاليًا.

اجعل كل نقطة انتقال واضحة

توقفنا عن التعامل مع نتائج الأدوات بوصفها حمولات بيانات خامًا من الواجهة الخلفية. وأصبحت كل نتيجة نقطة انتقال.

نتيجة الأداة الجيدة:

• توفر للأداة المصغّرة ما تحتاج إليه لعرض الواجهة.

• توفر لـChatGPT حقائق منظَّمة يستند إليها في الرد.

• وتحدد، عندما يتطلب التدفق ذلك، ما ينبغي حدوثه تاليًا حتى لا يضطر النموذج إلى التخمين.

ينبغي ألا تعيد إجراءات الأداة المصغّرة نصوصًا مبهمة إلى المحادثة. بل يجب أن توضّح ما فعله المستخدم وما ينبغي حدوثه تاليًا.

ازدادت الموثوقية بعدما أصبحت نقاط الانتقال واضحة.

يتبع النموذج التعليمات القصيرة والواضحة عندما ترد في مخرجات الأداة وإجراءات الأداة المصغّرة.

فيما يلي بنية Pydantic صغيرة استخدمناها. يحتوي الحقل output على البيانات المنظَّمة التي تحتاج إليها الأداة المصغّرة عند عرضها، وعلى الحقائق التي ينبغي أن يستخدمها ChatGPT في الجلسة. يحتوي الحقل agent_directions على سطر قصير يحدد ما ينبغي أن يفعله المساعد تاليًا. الحقل Reason اختياري.

1from typing import Generic, TypeVar2
3from pydantic import BaseModel4
5T = TypeVar("T")6
7class AgentDirections(BaseModel):8 assistant_instruction: str9 reason: str | None = None10
11class ToolResults(BaseModel, Generic[T]):12 agent_directions: AgentDirections13 output: T

اجعل الأدوات المصغّرة بسيطة

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

استخدام ضمير الغائب في رسائل الأداة المصغّرة

توقفنا عن كتابة متابعات الأداة المصغّرة كأنها دردشة صادرة من المستخدم (“I selected…,” “I confirmed…”). وكتبناها كتقارير قصيرة عما فعله المستخدم (“The user selected…,” “The user confirmed…”). جرّبنا هذا النهج لأن ChatGPT كان يضيف رسائل الأداة المصغّرة كرسائل أدوات بدلًا من رسائل مستخدم.

تنفيذ الإجراءات مباشرةً عندما تكون الخطوة التالية واضحة

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

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

معالجة الأخطاء

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

إدارة سياق الأدوات

احتفظنا بحالة الجلسة على خادمنا. يرسل ChatGPT سياقًا خاصًا بالجلسة مع استدعاءات الأدوات؛ وفي FastMCP منحنا كل أداة معلمة Context كي يتمكن المعالج من قراءة تلك الحالة وتحديثها.

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

• وعندما ظهرت حلقات في استدعاءات الأدوات، استطعنا اكتشاف الاستدعاءات المكررة وإعادة خطأ واضح ضمن نتيجة الأداة.

• وظلت سجلات الجلسات لدينا لاستخدامها في تصحيح الأخطاء والدعم.

في البداية، كنا نعرض أداة مصغّرة ونفترض أن النموذج «فهم المطلوب»، ثم ننتظر استدعاء المتابعة الصحيح للأداة. كان ذلك يحدث أحيانًا. لكنه غالبًا لم يحدث.

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

كان الحل هو توضيح الخطوة التالية صراحةً في المخرجات المنظَّمة وحمولات الأدوات المصغّرة، لا انتظار أن يستنتجها النموذج.

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

تصف وثائق حزمة تطوير التطبيقات أدوات يمكنك استبعادها من قائمة أدوات الوكيل كي لا يختارها، مع استمرار إمكانية استدعائها من الأداة المصغّرة. لكن عندما ضبطنا مستوى الظهور على app-only، لم تعد تلك الأدوات متاحة من الأداة المصغّرة أيضًا، لا من الوكيل وحده. لم نتوصل قط إلى إعداد لا يرى فيه الوكيل أداةً بينما تظل الأداة المصغّرة قادرة على رؤيتها.

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

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

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

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

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