الثلاثاء، 10:15
على الطاولة عرضان لبناء وكيل ذكاء اصطناعي. الأول يشغل صفحة واحدة: "وكيل ذكي يدير لك الموقع والإعلانات والمحتوى"، مع سعر شهري وتاريخ بدء.
والثاني أطول، ويبدأ بأسئلة: أين سيعمل الوكيل، وبأي صلاحية سيدخل إلى الموقع، ومن يوافق قبل النشر، وماذا يحدث إذا انكسر شيء.
كلاهما يعد بوكيل. واحد فقط أخبرك بما تحت الجدران.
يبدو بناء وكيل ذكاء اصطناعي لنشاط تجاري من الخارج بسيطًا: تربط ChatGPT، وتعطيه اسمًا، وهذا كل شيء. أما في الواقع فالمحادثة في تيليغرام مجرد الواجهة. تحتها خادم، وروابط، وصلاحيات، وذاكرة، وقواعد، وسجل.
في هذا الدليل نجيب عن سؤالين: كيف تبني وكيل ذكاء اصطناعي يمكنك الاعتماد عليه حتى في الشهر الثالث، وعلى أي بنية تحتية تشغّله حين تمتد المهام لساعات. وإن كنت لا تزال في مرحلة "ما هو الوكيل أصلًا"، فابدأ بـالدليل الأساسي عن وكيل الذكاء الاصطناعي للنشاط التجاري.
باختصار
- بناء وكيل ذكاء اصطناعي هو تأسيس منظومة لا تثبيت أداة: نموذج، وروابط بأقل صلاحية، ومعرفة بالنشاط، وقواعد موافقة وسجل، على بنية تعمل حتى حين يكون حاسوبك مطفأً.
- كيف تبني وكيل ذكاء اصطناعي: ثماني مراحل، من مهمة محددة إلى توسّع تدريجي. معظم العمل في الصلاحيات والتعليمات والفحص، لا في الكود.
- للعمل الطويل للوكلاء توجد اليوم ثلاث طرق رئيسية: منصة مُدارة مثل Agents API من OpenAI (في المرحلة التجريبية)، أو وكيل على خادم سحابي مخصص، أو وكيل جاهز مثل dots أو Muse. ما يجدي يتوقف على طول المهام والأنظمة ومقدار التحكم الذي تحتاج إليه.
- ما تأتي به أنت: 2 إلى 3 مهام، ووصول منظم إلى الأنظمة، وأمثلة على "الجيد"، وشخص يوافق.
بناء وكيل ذكاء اصطناعي هو بناء بيت، لا تثبيت تطبيق
العرض التجريبي يريك الصالون. العرض الجاد يحدثك عن الأساسات. هذه الجملة تستحق أن تأخذها إلى كل اجتماع مع من يعرض عليك بناء وكيل.
حين يُبنى بيت، لا يتحمس أحد للأساسات. يتحمسون للمطبخ والإطلالة. لكن بيتًا بمطبخ جميل وأساسات ضعيفة سيبدأ بالتشقق بعد الشتاء الأول.
وكيل الذكاء الاصطناعي يعمل بالطريقة نفسها. في العرض التجريبي ترى محادثة ذكية، وربما منتجًا يُرفع إلى الموقع. ولا ترى أين يعمل الوكيل، وبأي مستخدم يدخل إلى الموقع، ومن يوافق قبل النشر، وأين مسجّل ما فعله بالأمس.
الطبقات السبع لوكيل الذكاء الاصطناعي لنشاط تجاري
النموذج طبقة واحدة فقط من سبع. تصف OpenAI، في دليلها لبناء الوكلاء، ثلاثة مكوّنات أساسية: نموذج، وأدوات، وتعليمات. وفي نشاط حقيقي يلزم أن نضيف حولها عدة طبقات، ليكون الوكيل آمنًا للعمل اليومي. هكذا تبدو، من الأسفل إلى الأعلى.
1. الأساسات: خادم منفصل وعزل
يحتاج الوكيل إلى مكان يعمل فيه طوال الوقت، حتى حين يكون حاسوبك مطفأً. نفضّل خادمًا سحابيًا منفصلًا لكل نشاط، بحيث لا تجلس معلوماتك وروابطك وإعداداتك بجوار ما يخص نشاطًا آخر.
ما تسأل عنه: أين سيعمل الوكيل، وهل يشارك خادمًا أو حسابًا مع أنشطة أخرى؟
2. الأنابيب: الروابط والصلاحيات
هذه هي الطبقة التي تحوّل الدردشة إلى وكيل. بحسب توثيق OpenAI، لا يشغّل النموذج الأدوات بنفسه: إنه يطلب تشغيل أداة، والمنظومة المحيطة به تنفّذ الإجراء. أي أن ما يستطيع الوكيل فعله يتحدد في الأنابيب، لا في "حسن نوايا" النموذج.
ولذلك يحتاج كل ربط إلى مستخدم مخصص وصلاحية دنيا. وكيل يرفع منشورات إلى المدونة لا يحتاج إلى صلاحية مدير على الموقع كله.
ما تسأل عنه: بأي مستخدم سيدخل الوكيل إلى كل نظام، وماذا بالضبط سيستطيع أن يفعل هناك؟
3. العقل: نموذج وتعليمات
النموذج هو محرك التفكير. والتعليمات وصف الوظيفة: ماذا يفعل الوكيل، وكيف يتكلم، ومتى يتوقف ويسأل. النموذج نفسه مع تعليمات مبهمة يعطي نتائج مبهمة.
ما تسأل عنه: من يكتب التعليمات، وكيف تُحدَّث حين لا يعمل شيء؟
4. الذاكرة: معرفة النشاط
الوكيل العام يعرف أن يكتب. أما وكيل نشاطك فيعرف أن يكتب مثلك: النبرة، والمنتجات، والجمهور، والأسئلة المتكررة، وما يُمنع قوله. هذه المعرفة ينبغي أن تكون في ملفات يمكن قراءتها وتصحيحها وتصديرها.
ما تسأل عنه: أين تُحفظ المعرفة بالنشاط، وإن توقفنا عن العمل معًا، هل تبقى عندي؟
5. الباب: تيليغرام
من هنا تدخل أنت. تكتب للوكيل كما تكتب لموظف، وترسل صورة أو ملفًا، وتتلقى ناتجًا أو سؤالًا. وفي تيليغرام يسهل ضبط الوكيل على ألا يتلقى تعليمات إلا منك أو ممن حددتهم.
ما تسأل عنه: من بالضبط يستطيع أن يعطي الوكيل تعليمات، وماذا يحدث إذا حاول غريب؟
6. السقف: ما يحتاج إلى موافقة
تُحدَّد مسبقًا ثلاثة مستويات: ما يفعله الوكيل وحده، وما ينتظر موافقتك، وما لا يلمسه إطلاقًا. وتوصي توثيقات OpenAI أيضًا بإيقاف الإجراءات الحساسة أو غير الواضحة لموافقة بشرية صريحة قبل تشغيل الأداة.
والقاعدة يجب أن تكون في البنية التحتية، لا في التعليمات وحدها. "من فضلك لا تنشر بلا موافقة" طلب. أما منظومة لا تسمح بالنشر بلا موافقة، فهذا سقف.
ما تسأل عنه: هل تُفرض الموافقة في البنية التحتية، أم أنها مكتوبة فقط في تعليمات النموذج؟
7. السجل: التوثيق وطريق العودة
كل إجراء مهم يُسجَّل: ماذا فُعل، ومتى، وفي أي نظام، وبموافقة من. وإلى جانب نسخة احتياطية قبل أي تغيير كبير، يجيب السجل عن سؤال "ماذا حدث هنا؟" ويتيح العودة إلى الوراء.
ما تسأل عنه: إذا تغيّر شيء في الموقع، كيف أعرف من فعل ذلك وكيف نعيده؟
| الطبقة | دورها | ماذا يحدث حين تُتجاهل |
|---|---|---|
| الأساسات | مكان ثابت ومعزول للعمل | يتوقف الوكيل حين يُطفأ الحاسوب، أو يجلس بجوار معلومات الآخرين |
| الأنابيب | ربط بالأنظمة بصلاحية محددة | وكيل يتكلم فقط، أو وكيل بصلاحية مدير على كل شيء |
| العقل | التفكير ووصف الوظيفة | إجابات عامة وقرارات غير متسقة |
| الذاكرة | المعرفة بالنشاط | نصوص لا تشبهك |
| الباب | قناة التعليمات | تعليمات من كل اتجاه، أو وكيل يصعب التحدث إليه |
| السقف | ما يحتاج إلى موافقة | نشر أو إنفاق دون علمك |
| السجل | توثيق ونسخ احتياطي | لا طريقة لمعرفة ما حدث ولا طريقة للعودة |
كيف تبني وكيل ذكاء اصطناعي: خطوة بخطوة
يُبنى الوكيل كما يُستقبل موظف جديد: وظيفة محددة، ووصول محدود، وفترة تسليم، ثم مزيد من المسؤولية. هذه المراحل الثماني تناسب سواء بنيت وحدك أو بنى معك أحد. ولكل مرحلة نهاية واضحة، حتى لا تكتشف بعد شهر أنك لا تزال "في منتصف التأسيس".
- حدّد 2 إلى 3 مهام. كل مهمة في جملة واحدة: ما الذي يدخل، وماذا يفعل الوكيل، وما الذي يخرج. "حين أرسل صورًا وسعرًا، يُرفع منتج كمسودة"، لا "أدِر المتجر". نهاية المرحلة: وثيقة قصيرة بالمهام والأنظمة وما يُعدّ نجاحًا.
- اختر نموذجًا. توصي OpenAI في دليلها بأن نبدأ بأقوى نموذج لتحديد المعيار، ثم نفحص هل يظل نموذج أصغر وأرخص يحقق ذلك المعيار. نهاية المرحلة: نموذج فُحص على أمثلة حقيقية من نشاطك، لا على اختبارات الأداء فقط.
- اربط الأنظمة بأقل صلاحية. مستخدم مخصص في كل نظام، بالوصول الذي تحتاج إليه المهمة فقط. والمفتاح الفريد أفضل من كلمة مرور مشتركة، وقبل أي تغيير في الموقع يلزم نسخة احتياطية وطريق للعودة. نهاية المرحلة: كل ربط اجتاز عملية قراءة وإجراءً صغيرًا واحدًا.
- اكتب التعليمات ورتّب المعرفة. توصي OpenAI ببناء التعليمات من مستندات موجودة أصلًا في النشاط، وبأن يُكتب مسبقًا ما يُفعل في الحالات الحدّية. وفي نشاط صغير، هذه عادةً أمثلة لعمل أعجبك، ونبرة، وقائمة أسعار، وقائمة "ممنوع". نهاية المرحلة: مهمة تجريبية تبدو كشيء كنت ستفعله بنفسك.
- حدّد قواعد الموافقة. النشر، والميزانية، والرسالة باسم النشاط، والتغيير الجوهري في الموقع، كلها تنتظر موافقتك. والحذف غير القابل للتراجع وبيانات الدفع خارج النطاق. نهاية المرحلة: القواعد تُفرض في البنية التحتية، وتحققت أن إجراءً يحتاج إلى موافقة يتوقف فعلًا.
- افحص على مهام حقيقية. لا على عرض تجريبي. خذ مهامّ من الأسابيع الأخيرة وقارن الناتج بما أُنجز فعلًا. بحسب دليل OpenAI، المشاركة البشرية مهمة خصوصًا في بداية الطريق، لأن الحالات الحدّية تنكشف هناك. نهاية المرحلة: معظم النواتج تمر عندك دون تصحيحات.
- شغّل السجل والمتابعة. كل إجراء مهم يُسجَّل، وهناك من ينظر في السجل وفي الأخطاء. وحين يتكرر شيء، يُصحَّح التوجيه أو الصلاحية، لا الناتج وحده. نهاية المرحلة: تعرف أن تجيب عن "ماذا فعل الوكيل هذا الأسبوع؟" دون أن تسأله.
- وسّع مهمة واحدة في كل مرة. توصي OpenAI أيضًا بنهج تدريجي: وكيل واحد تُضاف إليه الأدوات ببطء، قبل أن تتعجل تقسيمه إلى عدة وكلاء. نهاية المرحلة: لا تدخل مهمة جديدة إلا حين تستقر السابقة.
مثال: المراحل الثماني في نشاط واحد
كيف يبدو الأمر حين نمر بكل المراحل على مهمة واحدة؟ اضغط على المراحل وانظر. هذا توضيح لمتجر إلكتروني صغير لأدوات الخزف، لا توثيق لنشاط حقيقي.
المرحلتان 1 و2 · نحدد المهمة ونختار النموذج
في كل مرة تصل شحنة، أقضي أمسية كاملة في رفع المنتجات. هذا ما أريد أن أنقله.
المهمة في جملة واحدة: حين ترسلين الصور وقائمة الأسعار، يُرفع لكل صنف منتج كمسودة، مع وصف وسعر وفئة.
النجاح: سعر مطابق للقائمة، ووصف بنبرة المتجر، وصفر منتجات تُنشر بلا موافقة.
✓ مهمة محددة · ✓ نموذجان يُفحصان على الأمثلة العشرة نفسها
المرحلة 3 · الروابط والصلاحيات
أُنشئ في الموقع مستخدم مخصص للوكيل، بوصول إلى المنتجات فقط. ليس له وصول إلى الإضافات أو المستخدمين أو الإعدادات. وقبل البدء فُحص أن هناك نسخة احتياطية حديثة.
✓ قراءة منتج قائم · ✓ إنشاء مسودة واحدة · ✗ لا وصول إلى الإعدادات
المرحلتان 4 و5 · التعليمات وقواعد الموافقة
أرفق خمسة أوصاف تعجبني. وبلا كلمة "فاخر"، فهذا ليس أسلوبنا.
دخل في التعليمات. والقواعد: المسودة ينشئها الوكيل وحده. النشر وتغيير السعر ينتظران موافقتك. حذف المنتج محظور.
وحده: المسودات · بموافقة: النشر والسعر · محظور: الحذف
المرحلة 6 · الفحص على مهام حقيقية
شغّلنا شحنة الأسبوع الماضي: 12 صنفًا. مرّ 10 دون تصحيح. وفي اثنين قرّب الوكيل السعر، لأن قائمة الأسعار كانت بخط اليد.
دخل التصحيح في التعليمات: السعر غير الواضح لا يُقرَّب، بل يُوضَع عليه علامة ويُسأل عنه.
! تصحيحان · ✓ حُدّثت التعليمات · ✓ نجح التشغيل المعاد
المرحلتان 7 و8 · السجل، وبعده فقط التوسّع
في السجل: أُنشئت 6 مسودات، ونُشرت 4 بموافقتك، واثنتان تنتظران فحص السعر. بعد بضعة أسابيع مستقرة تُضاف مهمة ثانية: منشور على إنستغرام عن كل منتج جديد، وهو أيضًا بموافقتك.
✓ المهمة 1 مستقرة · ← المهمة 2 تدخل
توضيح. النشاط والأرقام والمحادثات في المثال مختلقة.
ما يجب تجهيزه قبل بناء وكيل ذكاء اصطناعي لنشاطك
كثير من الوقت في بناء وكيل يذهب في أمور لا علاقة لها بالتقنية. البحث عمّن يحمل كلمة مرور حساب الإعلانات، وفهم ما هو "المنشور الجيد"، أو اكتشاف أنه لا توجد نسخة احتياطية للموقع. حدّد ما لديك أصلًا.
قائمة التجهيز لبناء وكيل
لم تحدّد كل شيء؟ لا بأس. بعض البنود تُحسم أصلًا في المرحلة الأولى. لكن بلا الثلاثة الأولى لا يوجد بعد ما يُبنى.
أي بنية تحتية تناسب العمل الطويل للوكلاء في 2026؟
لا توجد بنية تحتية واحدة هي "الأجدى". ما يجدي يتوقف على ثلاثة أشياء: كم تستغرق كل مهمة، وبأي أنظمة يتعامل الوكيل، وكم تحتاج من التحكم في الصلاحيات والمعلومات.
مهمة تمتد ساعات، مثل مراجعة كل صفحات الموقع أو تجهيز عشرات المنتجات، تحتاج إلى أكثر من نموذج جيد. تحتاج إلى مكان يُحفظ فيه العمل، وطريقة للتعافي من عطل في المنتصف، وقدرة على التوقف لموافقتك دون أن يضيع ما أُنجز. ومن يبحث عن البنية الأجدى لـworkflows طويلة للوكلاء يختار في الحقيقة بين ثلاث طرق.
منصة وكلاء مُدارة. فُتح Agents API من OpenAI في نسخة تجريبية عامة في 10 سبتمبر 2026. بحسب التوثيق، تدير OpenAI الجلسات والتنسيق وضغط السياق والتعافي من الأعطال، ويوفّر المطوّر الأدوات ويختار أين يعمل الوكيل: دون بيئة، أو في بيئة تستضيفها OpenAI، أو في بيئته الخاصة. وفي 29 سبتمبر أُضيف computer use، وكيل يعمل في متصفح تستضيفه OpenAI. يطلب المتصفح موافقة قبل دخول أي موقع جديد، وبحسب التوثيق يتطلب حاليًا GPT-6 Astra.
وكيلك على خادم سحابي مخصص. يعمل الوكيل على خادم مخصص لنشاط واحد، ويتصل بالنموذج عبر الـAPI. أنت، أو من يبني معك، تحددون المستخدمين في كل نظام وقواعد الموافقة والسجل والنسخ الاحتياطية. والثمن أن أحدًا يجب أن يصون هذا كله.
وكيل جاهز للمستهلكين. تعمل dots من OpenAI داخل ChatGPT، وبحسب MacRumors تُفتح تدريجيًا لمشتركي Pro وBusiness Premium وEnterprise في أسواق مختارة. ويعمل Muse من Meta على حاسوب افتراضي مخصص في السحابة، وهو بحسب Meta متاح حاليًا في الولايات المتحدة وكندا فقط. فصّلنا الحديث عنهما في دليل dots ودليل Muse.
| الخيار | منصة مُدارة (Agents API) | خادم سحابي مخصص | وكيل جاهز (dots وMuse) |
|---|---|---|---|
| نموذج التكلفة | حسب الاستخدام: النموذج والأدوات وزمن بيئة التشغيل | خادم شهري ثابت، والنموذج حسب الاستخدام، وصيانة | اشتراك أو استخدام مجاني بحدود |
| التحكم | عالٍ في الكود، ضمن حدود API تجريبي | كامل: المستخدمون والصلاحيات والموافقات والسجل | ضمن القواعد التي يعرضها المنتج |
| المعلومات | بحسب التوثيق، حاليًا التخزين في الولايات المتحدة فقط وبلا Zero Data Retention | على خادمك. والطلبات إلى النموذج تمر إلى المزوّد | في حسابك لدى المزوّد |
| الصيانة | عند المطوّر: كود قد يتغير مع النسخة التجريبية | عند من يدير الخادم | شبه معدومة |
| يناسب حين... | يوجد مطوّر، وتعمل المهام ساعات في بيئة معزولة | يتعامل الوكيل مع الموقع والإعلانات وأنظمة النشاط | المهام شخصية والتطبيقات مدعومة |
المصدر: صفحة الأسعار وصفحة النموذج في OpenAI للمطورين، جرى فحصهما في 6 أكتوبر 2026. أسعار النماذج سارية على طلبات حتى 272 ألف token في المدخل، وما فوق ذلك أعلى.
ما الذي يرفع تكلفة العمل الطويل؟ في الأساس السياق. مهمة تجرّ وراءها تاريخًا طويلًا تعالجه مرة بعد مرة، وفوق 272 ألف token في المدخل يرتفع سعر الـtoken أيضًا. وفي البيئة المستضافة يُضاف إلى ذلك زمن التشغيل. ولذلك، في كل بنية تحتية، يستحسن تقسيم العمل الطويل إلى مراحل بنقاط حفظ، وفحص المهمة على Sol قبل الانتقال إلى Astra.
منصة مُدارة
شخص آخر يمسك المحرك
- جلسات تحفظ العمل بين الأدوار
- تعافٍ مدمج من الأعطال
- دفع حسب الاستخدام، بلا خادم ثابت
- تجريبية، مع تخزين المعلومات في الولايات المتحدة
- تتطلب مطوّرًا يكتب الكود ويصونه
خادم سحابي مخصص
بيتك، ومفاتيحك أنت
- عزل كامل عن الأنشطة الأخرى
- مستخدم مخصص وصلاحية دنيا في كل نظام
- موافقات تُفرض في البنية التحتية
- سجل ونسخ احتياطية تبقى عندك
- يتطلب شخصًا مسؤولًا عن الصيانة
رأينا: لنشاط صغير يتعامل وكيله مع موقع WordPress وGoogle Ads وMeta، يبقى الخادم المخصص لكل نشاط هو الخيار الأكثر أمانًا اليوم. Agents API مثير جدًا للاهتمام، وفيه أيضًا إمكانية لبيئة على بنيتك التحتية، لكن بحسب التوثيق لا تجعل هي الأخرى الخدمة مؤهلة لـZero Data Retention. نتابعه ونختبره. وإن كانت مهامك شخصية، مثل البريد والتقويم والمستندات، فقد يكفي وكيل جاهز تمامًا.
وماذا عن أدوات مثل n8n؟ أدّت عملًا جيدًا في عالم المسارات الثابتة. لكن المهمة الطويلة مليئة بقرارات صغيرة، ووكيل واحد بالصلاحيات الصحيحة يغني عن عشرات العقد التي يجب صيانتها. توسّعنا في ذلك في المقارنة بين n8n ووكيل الذكاء الاصطناعي.
ما عليك وما على من يبني
لا تحتاج إلى أن تعرف البرمجة، لكنك تحتاج إلى أن تكون حاضرًا، خصوصًا في البداية. بناء وكيل ذكاء اصطناعي لنشاط عمل مشترك.
تأتي أنت بـ
المعرفة والقرارات
- المهام وتعريف "الجيد"
- وصول إلى الأنظمة، أو من يستطيع منحه
- أمثلة ونبرة وحدود
- موافقات وملاحظات في فترة التشغيل التجريبي
- قرار ما يُوسَّع ومتى
ويأتي من يبني بـ
البنية التحتية والمسؤولية
- خادم منفصل ومؤمَّن
- روابط بأقل صلاحية
- تعليمات وذاكرة وقواعد موافقة
- نسخة احتياطية وسجل وطريق للعودة
- إصلاحات حين يتغير نظام أو ينكسر شيء
علامات الخطر في عرض بناء وكيل ذكاء اصطناعي
"لا" واحدة ليست سببًا للتخلي، لكنها سبب للسؤال. تلقيت عرضًا؟ راجعه بهذه الأسئلة.
وهناك ثلاثة أشياء لن نوافق عليها، حتى لو بدت مريحة:
- "وكيل واحد يدير النشاط كله من اليوم الأول". الوكيل الجيد يُبنى مهمة بعد مهمة. من يبدأ بكل شيء لا يعرف ما الذي لا يعمل بالضبط.
- "أعطوه صلاحية مدير، هذا أبسط". هذا بسيط، حتى الخطأ الأول. الصلاحية الدنيا هي الفارق بين خطأ صغير ومشكلة كبيرة.
- "نبني وننتهي". المواقع والإضافات وواجهات Google وMeta تتغير. وكيل بلا من يتولى أمره سيبدأ بالتآكل، كأي بيت بلا صيانة.
تبني وحدك، أم بدعم، أم أن الوقت لم يحن؟
ليس كل نشاط يحتاج إلى من يبني له وكيلًا، وليس كل نشاط يحتاج إلى وكيل أصلًا. هكذا ننظر إلى الأمر:
أي مسار يناسبك
يمكنك أن تجرّب وحدك
- ترتاح مع الأدوات التقنية
- مهمة واحدة، داخلية
- لا شيء يُنشر إلى الخارج
- لديك وقت للصيانة
يستحسن أن يبني معك أحد
- عدة أنظمة مربوطة
- نشر أو ميزانية أو محتوى عام
- موقع يدرّ مالًا
- لا وقت لديك للانشغال بالبنية التحتية
ربما ليس بعد وكيل
- لا يوجد عمل متكرر كافٍ
- لا يوجد من يوافق
- المهام شخصية ويكفي وكيل جاهز
- لا أنظمة لربطها
إذا وقعت معظم علاماتك في العمود الأحمر، فالأرجح أن الوقت مبكر. وإن كان موقعك مبنيًا على WordPress، فقد كتبنا عنه على حدة: إدارة موقع WordPress بوكيل ذكاء اصطناعي.
كم يكلّف بناء وكيل ذكاء اصطناعي؟
السعر ينشأ مباشرة من الطبقات والبنية التحتية. هناك عادةً ثلاثة مكوّنات: تأسيس لمرة واحدة، وخدمات خارجية مثل النموذج والخادم، ومتابعة جارية. فصّلنا ذلك في دليل سعر وكيل الذكاء الاصطناعي.
وحين تقارن العروض، تذكّر: العرض الرخيص جدًا لا يبني عادةً البيت نفسه بسعر أقل. الأرجح أنه يبني طوابق أقل. قارن طبقة بطبقة، لا السطر الأخير بالسطر الأخير فقط.
الأسئلة الشائعة
ما هو بناء وكيل الذكاء الاصطناعي؟
بناء وكيل الذكاء الاصطناعي هو تأسيس منظومة يرتبط فيها نموذج لغوي بأدوات النشاط ويعمل فيها بحسب تعليمات وصلاحيات وقواعد موافقة. ويشمل بنية تحتية يعمل عليها الوكيل، وروابط بأنظمة مثل الموقع وحسابات الإعلانات، ومعرفة منظمة بالنشاط، وقناة محادثة مع صاحب النشاط، وتوثيقًا لكل إجراء مهم.
كيف تبني وكيل ذكاء اصطناعي؟
تحدّد 2 إلى 3 مهام متكررة وما يُعدّ نجاحًا، وتختار نموذجًا بحسب فحص على أمثلة حقيقية، وتربط الأنظمة بمستخدم مخصص وصلاحية دنيا. بعد ذلك تكتب التعليمات والمعرفة بالنشاط، وتحدّد ما يحتاج إلى موافقة، وتفحص على مهام الأسابيع الأخيرة، وتشغّل السجل، ثم توسّع، مهمة واحدة في كل مرة.
كم يستغرق بناء وكيل ذكاء اصطناعي لنشاط تجاري؟
يتوقف على الحجم: كم مهمة، وكم نظامًا، ومدى تنظيم الوصول إليها. المعتاد أسابيع، بما فيها فترة التشغيل التجريبي. ومن يعد بوكيل يدير النشاط كله في يوم واحد، فالأرجح أنه يتجاوز بعض الطبقات.
ما البنية التحتية الأجدى للعمل الطويل للوكلاء؟
لا يوجد جواب واحد. منصة مُدارة مثل Agents API من OpenAI، وهي في المرحلة التجريبية، تحاسب حسب الاستخدام وتدير لك الجلسات والتعافي. وخادم سحابي مخصص يكلّف مبلغًا ثابتًا ويمنح تحكمًا كاملًا بالصلاحيات والمعلومات. ووكيل جاهز مثل dots أو Muse لا يكاد يحتاج إلى صيانة، لكنه يعمل فقط مع ما يدعمه المنتج. وفي كل منها انتبه إلى كمية السياق التي يعالجها النموذج، فهي ما يرفع تكلفة المهام الطويلة.
ماذا يحدث لمعلومات النشاط حين نبني وكيلًا على النموذج الذي يختاره النشاط؟
تختلف الشروط من مزوّد إلى آخر، وعادةً لا تُستخدم المعلومات المرسلة عبر الـAPI في شروط الأعمال في تدريب النماذج افتراضيًا، لكن يجب مراجعة شروط كل مزوّد. فبحسب توثيق OpenAI مثلًا، لا تُستخدم المعلومات المرسلة عبر الـAPI الخاصة بها في تدريب نماذجها أو تحسينها، إلا إذا اخترت صراحةً أن تشاركها. وفي Agents API، بحسب التوثيق نفسه، تُحفظ حالة التطبيق إلى أن تُحذف. اسأل من يبني أين تُحفظ المعرفة بالنشاط، ومن يستطيع الوصول إليها، وهل يمكنك الحصول عليها.
على أي نماذج وأدوات تبني Platin Digital الوكلاء؟
Platin Digital هي OpenAI Select Partner. نبني لأصحاب الأعمال وكلاء ذكاء اصطناعي بالنماذج والأدوات الأنسب لكل عمل، من OpenAI وAnthropic وGoogle وغيرها، وأحيانًا بدمج بينها، على خادم سحابي منفصل لكل نشاط، بمستخدم مخصص وصلاحية دنيا في كل نظام، وقواعد موافقة تُحدَّد مسبقًا.
المصادر
- https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
- https://developers.openai.com/api/docs/guides/function-calling
- https://developers.openai.com/api/docs/guides/agents/guardrails-approvals
- https://developers.openai.com/api/docs/guides/your-data
- https://developers.openai.com/api/docs/guides/agents-api/overview
- https://developers.openai.com/api/docs/guides/agents-api/sessions
- https://developers.openai.com/api/docs/guides/agents-api/environments/self-hosted
- https://developers.openai.com/api/docs/guides/agents-api/tools/computer-use
- https://developers.openai.com/api/docs/changelog
- https://developers.openai.com/api/docs/pricing
- https://developers.openai.com/api/docs/models/gpt-6.1-sol
- https://www.macrumors.com/2026/09/29/openai-launches-dots/
- https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/
- https://about.fb.com/news/2026/09/introducing-muse-small-business/
