Claude Code اختار Resend في 64 حالة من أصل 102: كيف تبني منتجًا للوكلاء

تخيّل أنك تطلب من Claude Code «أضف إرسال الرسائل الإلكترونية»، وتقبل التعديل، فإذا بمزوّد محدد مثبَّت في المستودع. أنت لم تخترْه. الوكيل هو من اختار. هذه اللحظة بالذات يحللها زينو روشا، المؤسس المشارك والرئيس التنفيذي لـ Resend، في بودكاست Latent Space. وكان المنطلق لغزًا طرحه مقدّما البرنامج: لماذا يوصي الوكلاء بـ Resend وليس Cloudflare Email، مع أن لدى Cloudflare ميزة «اللعب على أرضها» وحجمًا أكبر؟

من يأتي أولًا في التوصية يفوز

في إحدى دراسات AEO (answer engine optimization، أي التحسين لإجابات الذكاء الاصطناعي) سمّى Claude Code خدمة Resend أولًا في 64 توصية من أصل 102 توصية مستخرجة. أما SendGrid فجاء أولًا سبع مرات فقط، لكنه ذُكر 55 مرة كبديل. المنطق بسيط: إذا قبل المطوّر التعديل، فنادرًا ما يصل الأمر إلى الخيار الثاني.

وثمة تحفظ مهم: دراسة أحدث وأوسع تبيّن أنها أكثر تنافسية، وكان Postmark في المقدمة لدى معظم النماذج. لذا فإن هذه المكانة ليست دائمة وتعتمد على النموذج وإصداره. وبحسب روشا، كان لدى Resend وقت التسجيل 4.3 مليون مستخدم و120 ألف عميل يدفعون.

منتج يستطيع الوكيل قراءته

لم يكن أول قناة توزيع لـ Resend هو الـ API، بل React Email، وهي مكتبة لتنسيق الرسائل الإلكترونية. ويمكن استخدامها مع SendGrid أيضًا، بل وصف الفريق كيف يتم ذلك. والنتيجة أنه حين احتاج المطوّر إلى مزوّد آخر، كان جزء من كود Resend موجودًا أصلًا في مستودعه.

لننظر الآن بعيني الوكيل. في صفحة أسعار Resend شريط تمرير: يحرّك الإنسان المؤشر إلى الحجم المطلوب فيرى المبلغ. وهذا قليل الفائدة للوكيل. الحل متواضع: إضافة .md إلى عنوان الصفحة للحصول على جدول عادي يمكن قراءته بطلب واحد. اختبار ذاتي جيد: افتحوا صفحة أسعاركم وتحققوا هل يستطيع النموذج أن يجيب منها عن سؤال عميل.

80 أداة أم اثنتان

نما خادم MCP الخاص بـ Resend من نحو 20 أداة إلى أكثر من 80. هدف روشا أن يكون بالإمكان من الدردشة فعل كل ما هو متاح في لوحة التحكم: إرسال رسالة، ودعوة زميل، ومراجعة الاستهلاك، وإدارة الفوترة. إرسال الرسالة يصلح للعرض التجريبي، أما العمل الحقيقي فيتكوّن من «ذيل طويل» من هذه العمليات.

تتبنى Cloudflare نهجًا معاكسًا: يتيح Code Mode الوصول إلى كامل الـ API عبر أداتين هما search() وexecute(). لكن عدد الأدوات لا يحل كل شيء. فروشا يفتح الاستدعاءات المطوية في جلساته الخاصة ويرى ما فعله الوكيل حقًا. وفي إحدى الحالات لم تتسع النتيجة ببساطة في السياق، ولم يكن تقليل عدد الأدوات ليصلح ذلك.

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

بعد الاختيار يبدأ التسليم

إقناع الوكيل باعتماد الـ SDK الخاص بك هو نصف المهمة فقط، فلا يزال عليك تسليم الرسالة. مثال ذلك تتبع النقرات. قد يعيد المزوّد كتابة الروابط عبر نطاق مشترك لاحتساب النقرات. فإذا استخدم أحد العملاء هذا النطاق في التصيّد الاحتيالي ووقع في قائمة الحظر، تضررت الرسائل المشروعة لدى العملاء الآخرين أيضًا. لذلك أدخلت Resend نطاقات تتبع خاصة.

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

ماذا نفعل بذلك

القيود واضحة. دراسات AEO تقيس نماذج محددة في لحظة محددة، والبودكاست هو رواية مؤسس وليس تدقيقًا مستقلًا. ولا يمكن نقل نتائج Resend آليًا إلى أي منتج.

لكن الخلاصات العملية صالحة:

1. أنشئوا نسخ markdown من الوثائق وصفحة الأسعار ليقرأها الوكيل دون تفاعل.
2. افحصوا استجابات خادم MCP الخاص بكم من حيث التضخم: غالبًا لا تكمن المشكلة في عدد الأدوات بل في حجم النتيجة.
3. أعطوا المطوّر أداة مفيدة قبل اختيار المزوّد، كما فعلت React Email.
4. لا تنشئوا موارد مشتركة يفسد فيها عميل سيئ واحد سمعة الجميع.

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