في 10 سبتمبر، أطلقت OpenAI واجهة برمجة التطبيقات Agents API في مرحلة التجربة العامة (public beta)، لتوفر "نفس بيئة التشغيل والبنية التحتية التي تُشغّل Codex للمطورين من خلال واجهة بسيطة ومرنة". وفي مؤتمر DevDay في 29 سبتمبر، أضافت الواجهة ميزة استخدام الحاسوب (computer use)، ونسخة مخصصة لبيئة AWS، إلى جانب خدمة أخرى: فوكلاء dots الجدد الذين يعملون باستمرار في ChatGPT يعملون على نفس بيئة تشغيل Codex.
إذا قرأت هذا كمطور يبني منتجاً قائماً على الوكلاء الأذكياء، فهذه أخبار سارة: فبيئة التشغيل التي كنت ستتكبد عناء بنائها بجودة متواضعة أصبحت الآن مسؤولية طرف آخر. أما إذا قرأته كمهندس يدير فريقه بالفعل كلاً من Claude Code وCodex على قاعدة برمجية حقيقية، فإن السؤال يتغير تماماً. تجيب واجهة برمجة التطبيقات على سؤال: "كيف أُبقي الوكيل قيد التشغيل لساعات؟"، لكنها لا تجيب على: "كيف يعرف فريقي ما أنجزه ستة وكلاء، ومن وافق على الموقع الإلكتروني الذي سجل أحدهم الدخول إليه للتو؟". وهنا بالتحديد يأتي دور Sharkly للإجابة عن هذا السؤال الثاني.
ملخص سريع
تستضيف Agents API بيئة تشغيل Codex: الجلسات طويلة الأمد، وضغط سياق المحادثة (compaction)، والبحث عن الأدوات، والوكلاء الفرعيين (subagents)، وبيئة معزولة (sandbox) سواء من OpenAI أو من بنيتك التحتية أو من تسعة شركاء، دون أي رسوم إضافية سوى تكلفة الرموز (tokens) والأدوات ووقت تشغيل الحاويات. وأضاف DevDay ميزة استخدام الحاسوب (computer use)، حيث يعتمد تطبيقك كل نطاق موقع جديد وكل عملية تسجيل دخول (الموافقة على النطاق لا تعني تأكيد الإجراءات الفردية)، إلى جانب Bedrock Managed Agents التي تشغل إمكاناتها الأساسية داخل AWS. ومع ذلك، لا يغطي أيٌّ من هذا طبقة إدارة الفريق: من أسند المهمة، وأي وكيل ينفذها، وما الذي اكتمل أو فشل، ومن يعتمد النتيجة النهائية.
ما هي Agents API وما الذي تديره OpenAI فعلياً
يلخص الدليل التعريفي من OpenAI واجهة برمجة التطبيقات في أربعة مفاهيم أساسية. الوكيل (Agent) هو "النموذج والتعليمات والأدوات وخوادم MCP المتاحة للوكيل". البيئة (Environment) هي "بيئة معزولة أو حاسوب اختياري يصل من خلاله الوكيل إلى الملفات ويحمّل المهارات وينفذ الأوامر". الجلسة (Session) هي "نسخة تشغيلية دائمة من الوكيل تعمل على المهام وتستجيب للمدخلات". أما الأحداث والعناصر (Events and items) فهي المدخلات التي ترسلها والمخرجات التي تتلقاها في المقابل.
يمكنك إنشاء جلسة باستخدام تهيئة محددة للوكيل، وتعيين مهمة له بمجرد جاهزية البيئة، ثم متابعة تقدمه عبر البث الحي أو خطافات الويب (webhooks)، وإرسال المزيد من المهام أو التوجيهات ضمن الجلسة نفسها. إليك مثالاً مختصراً من التوثيق الرسمي:
const session = await client.beta.agents.sessions.create({
agent: {
model: "gpt-6-astra",
instructions: "Use the docs MCP and web search. Delegate independent research to subagents when useful.",
tools: [
{ type: "programmatic_tool_calling" },
{ type: "mcp", server_label: "openai_docs", transport: { type: "http", server_url: "https://developers.openai.com/mcp" } },
{ type: "web_search" },
],
multi_agent: { enabled: true, max_concurrent_subagents: 4 },
},
environment: { type: "self_hosted", workspace_directory: "/workspace" },
input: [{ role: "user", content: [{ type: "input_text", text: "Research how to connect an MCP server to an OpenAI agent and summarize the setup." }] }],
});
هناك سطران يحملان معظم التحديثات المهمة: يُمكّن multi_agent توزيع المهام على وكلاء فرعيين مع تحديد حد أقصى للتنفيذ المتزامن، بينما يحدد environment.type مكان تشغيل التعليمات البرمجية: إما openai_hosted أو self_hosted أو إحدى البيئات المعزولة من الشركاء (Blaxel أو Cloudflare أو Daytona أو DigitalOcean أو E2B أو Modal أو Oracle أو Runloop أو Vercel).
يوضح التوثيق تقسيم المسؤوليات في جملة واحدة: "تدير OpenAI الجلسات والتنسيق وضغط السياق واستعادة الحالة، بينما يوفر تطبيقك الأدوات ويختار بيئة التنفيذ".
| ما تديره OpenAI | ما يقع على عاتقك توفيره |
|---|---|
| حلقة عمل الوكيل: استدعاءات النموذج، واستخدام الأدوات، وإعادة المحاولة | المهمة، ومعايير اكتمالها (definition of done) |
| ضغط سياق المحادثة عند اقتراب الجلسة من الحد الأقصى | الأدوات: خوادم MCP، والدوال البرمجية، والأدوات المدمجة |
| البحث عن الأدوات وتحميلها | بيانات الاعتماد، عبر معرفات خزائن الأسرار (vault IDs) |
| تقسيم المهام على الوكلاء الفرعيين وتنسيق عملهم | اختيار بيئة التشغيل وإعدادها |
| استئناف الجلسات وتوجيه مسارها | كل ما يحدث بعد انتهاء الجلسة |
تُحسب تكلفة استخدام النماذج وفقاً لأسعار الواجهة البرمجية المعتادة للنموذج، وتكلفة الأدوات بالأسعار القياسية، والبيئات المعزولة المستضافة لدى OpenAI بأسعار الحاويات؛ وجاء في منشور الإطلاق أنه "لا توجد رسوم إضافية لاستخدام Agents API". كما يوضح التوثيق قيدين صريحين: الواجهة البرمجية "تدعم حالياً إقامة البيانات في الولايات المتحدة فقط، ولا تدعم ميزة عدم الاحتفاظ بالبيانات (Zero Data Retention - ZDR)"، واختيار بيئة معزولة ذاتية الاستضافة لا يجعلها مؤهلة لميزة ZDR. فإذا كان أي منهما أمراً حاسماً لمتطلبات الامتثال لديك، فإن تشغيل البيئة المعزولة داخلياً لن يغير من الأمر شيئاً.
ما أضافه مؤتمر DevDay
استخدام الحاسوب (Computer use): بمجرد إضافة أداة computer_use وتفعيل واجهة سطح المكتب في بيئة مستضافة لدى OpenAI، يستطيع الوكيل التحكم في متصفح مستضاف. ويبني دليل استخدام الحاسوب مسار العمل حول أحداث الموافقة؛ حيث يطلب المتصفح موافقة المستخدم قبل فتح أي نطاق موقع إلكتروني جديد، بما في ذلك المواقع العامة. وتأتي عمليات تسجيل الدخول كطلبات منفصلة يعرضها تطبيقك لحقول البريد الإلكتروني وكلمة المرور ورمز التحقق؛ مع العلم أن مفاتيح المرور (passkeys) وتسجيل الدخول عبر رمز QR غير مدعومة، ولا يمكن إلا للوكيل الرئيسي فقط، دون الوكلاء الفرعيين، طلب بيانات الاعتماد. والعبارة التي تستحق التوقف عندها وقراءتها بعناية هي: "الموافقة على النطاق لا تعني تأكيد الإجراءات الفردية مسبقاً". ففي حالات عمليات الشراء أو التعديلات الحساسة، ينصح التوثيق بتقييد المتصفح المستضاف على موارد لا تتيح تنفيذ مثل هذه الإجراءات، أو استخدام بيئة تشغيل متصفح تخضع لسيطرتك المباشرة. ويذكر ملخص DevDay توفر ميزة استخدام الحاسوب "عبر واجهة برمجة التطبيقات وفي Codex وChatGPT Work لباقتي Pro 500 وEnterprise".
Bedrock Managed Agents المدعومة من OpenAI: دمجت شركتا OpenAI وAmazon "الإمكانات الأساسية لـ Agents API" مع إمكانات تخصيص لتتوافق أصلياً مع منظومة AWS. وتوضح صفحة منتج AWS أنها في مرحلة المعاينة (preview)، مشيرةً إلى أن بيئة تشغيل الوكيل واستنتاج النماذج يبقيان داخل AWS، حيث يتمتع كل وكيل بهويته وصلاحياته الخاصة داخل AWS.
وكلاء Dots على نفس بيئة التشغيل: تفيد تقارير Decrypt بأن بيئة تشغيل Codex "أصبحت تُشغل dots الآن وهي مفتوحة المصدر". وdots هي وكلاء ChatGPT التي تعمل بصفة دائمة، ويمتلك كل منها حاسوبه السحابي الخاص، ويوضح مقالنا التوضيحي حول dots أبرز ما تجيده هذه الأدوات.
وهكذا باتت هناك حلقة عمل واحدة تُشغل وكيل البرمجة، وجلسة واجهة برمجة التطبيقات، ووكيل AWS، والمساعد الدائم العمل. لقد بدأت بيئات التشغيل تتقارب وتتكامل. ولكن الجزء الذي يلقي بظلاله مباشرة على فرق العمل هو أحداث الموافقة: فكل حدث منها يمثل استفساراً داخل جلسة واحدة، ينتظر إجابة من الشخص الذي يتابع بثها المباشر. وعندما تتوالى الأسئلة من خمس جلسات متزامنة، يتعين على أحدهم تحديد من يملك صلاحية الموافقة على كل نطاق، وأين يُسجَّل هذا القرار. هذه معضلة بوابات الموافقة (approval gates)، وقد تناولنا النسخة المتعلقة بالحاسوب بالتفصيل في مقال ضوابط استخدام الحاسوب في GPT-6 Astra.
ما لا تديره هذه الأدوات: طبقة إدارة الفريق
الجلسة لا تدرك سوى ما يدور داخلها فقط؛ فهي لا تعلم أن هناك ثلاث جلسات أخرى تعدل على المستودع البرمجي نفسه، أو أن نتيجة جلسة رابعة ظلت دون مراجعة منذ يوم الثلاثاء. هذه تحديات إدارية تبدأ في الظهور فور قيام أكثر من شخص بتشغيل أكثر من وكيل في الوقت ذاته.
خمسة أسئلة تتركها واجهة برمجة التطبيقات دون إجابة، بحكم تصميمها:
- من أسند هذه المهمة، ولأي تذكرة تتبع؟ تمتلك الجلسة معرّفاً وأي بيانات وصفية يدرجها الكود الخاص بك داخلها. أما المسؤول أو دورة العمل (Sprint) أو الرابط المؤدي إلى المشكلة الأصلية، فلن توجد إلا إذا أضفتها بنفسك.
- أي مستودع وفرع برمجِيّ طالهما التعديل؟ يجب نقل فارق التعديلات (diff) إلى مكان يستطيع المراجع الاطلاع عليه وفحصه.
- ما الذي اكتمل، وما الذي تعثر، وما الذي لا يزال قيد الانتظار؟ تتدفق الأحداث أثناء متابعتك للبث المباشر أو تصلك عبر الـ webhooks، ولا يتم تجميع أي نتائج تلقائياً في قائمة انتظار بانتظار تدخل بشري.
- من يعتمد النتيجة النهائية؟ تقتصر أحداث الموافقة على زيارة المواقع أو تسجيل الدخول، وليس جودة العمل المنجز. فـ "انتهاء الجلسة" و"مراجعة شخص للأدلة والموافقة عليها" هما أمر واحد ما لم تبنِ بنفسك آلية للموافقة الثانية.
- ماذا عن الوكلاء التابعين لشركات أخرى غير OpenAI؟ إن استخدام Claude Code لفئة معينة من المهام وCodex لفئة أخرى يعني التعامل مع نموذجين مختلفين للجلسات والبحث في مكانين منفصلين.
يمكنك بالطبع بناء حلول لهذه الأسئلة الخمسة بالاعتماد على تدفق الأحداث: لوحة مهام، خطاف ويب (webhook)، حقل لتحديد الحالة، وعمود للمراجعة. ولكن عندما يسأل شخص ما: "هل أطلقنا بالفعل إصلاح ميزة التصدير؟"، ستجد أن الإجابة تائهة في سجل محادثة لم يحفظه أحد. يتناول مقالنا عن إدارة مهام وكلاء الذكاء الاصطناعي متطلبات بناء هذه المنظومة بنفسك.
وكلاء فرعيون داخل الجلسة، أم مهام على لوحة العمل؟
يعد خيار max_concurrent_subagents حل واجهة برمجة التطبيقات للتنفيذ المتوازي، وهو حل ممتاز لطبيعة عمل محددة. إنه نفس التوازن الذي تناولناه حين رفعت Codex الحد الأقصى للوكلاء الفرعيين إلى 64: حيث يشترك الوكلاء الفرعيون في وكيل رئيسي واحد، ويجمعون نتائجهم في رد نهائي موحد، وتتم مراجعتهم كناتج واحد.
اعتمد على الوكلاء الفرعيين داخل الجلسة عندما تكون المهام معتمدة في معظمها على القراءة، ومستقلة عن بعضها، ولا يهمك سوى الناتج النهائي المجمع: مثل البحث في أربع واجهات برمجة تطبيقات، أو فحص قاعدة الكود للبحث عن نمط معين، أو جمع الأدلة لتشخيص خلل طارئ.
أما إذا كانت كل مهمة تتضمن كتابة كود يحتاج إلى مراجعة مستقلة، فاستخدم مهام منفصلة (Tasks): كعمليات ترحيل قواعد البيانات، أو إضافة ميزة لوحدة برمجية محددة، أو تعديل يشمل ملفاً مشتركاً. ففي Sharkly، يحصل كل تشغيل على شجرة عمل git معزولة (isolated git worktree) خاصة به على حاسوب تملكه، وتعود كل نتيجة إلى مهمتها الخاصة مرفقة بفارق التعديلات (diff)، وسجل التنفيذ، والمراجع المخصص لها. إن دمج أربعة تعديلات برمجية كبيرة في ملخص واحد لوكيل فرعي يعني إخفاء أربعة قرارات داخل قرار واحد.
الأسئلة الشائعة
ما هو النموذج الذي يدعم ميزة استخدام الحاسوب؟ تستخدم الأمثلة الواردة في التوثيق نموذج gpt-6-astra. احرص على مراجعة الدليل قبل افتراض أن نموذجاً آخر يتوافق مع أداة computer_use.
هل تشغّل Sharkly جلسات Agents API؟ تشغّل Sharkly وكلاء البرمجة عبر واجهة سطر الأوامر (CLI) المثبتين على حواسيبك (Computers)، مثل Codex وClaude Code، كبيئات تشغيل (Runtimes). وتعد جلسات Agents API خدمة مستضافة وليست بيئة تشغيل مثبتة محلياً، لذا يجب التعامل معها كمسار تنفيذ منفصل.
أين تتم المراجعة البشرية؟ في Agents API، تتم في أي مكان تبنيه بنفسك: حيث تغطي أحداث الموافقة الوصول للمواقع وتسجيل الدخول فقط، وليس قبول النتيجة النهائية. أما في Sharkly، فيمكن للوكيل تعليق المهمة بانتظار المراجعة البشرية، حيث يصل الطلب مباشرة إلى صندوق الوارد الخاص بالشخص المسؤول، والذي يقوم بدوره بتحديث الحالة بعد الاطلاع على الرد وسجل التنفيذ وفارق التعديلات.
المكان الأنسب لكل طبقة
تعد الجلسة طويلة الأمد المستضافة في بنية OpenAI التحتية العنصر الأكثر ملاءمة في هذا الإطلاق، والأكثر إحكاماً لربطك بالمنصة (stickiest). وبالنسبة للفريق الهندسي، فإن هذا الأمر بالغ الأهمية؛ فالوكيل البرمجي الأفضل يتغير باستمرار، وأي فريق يرتبط نظام مراجعته وقواعد إسناد مهامه بمخزن جلسات لدى مزود خدمة واحد سيضطر إلى إعادة بناء مسار عمله بالكامل في كل مرة تتبدل فيها الصدارة بين النماذج.
إذا كنت تبني منتجاً أو خدمة خلفية مدعومة بوكلاء الذكاء الاصطناعي، فإن Agents API هي الطبقة المناسبة لك، وتعد Bedrock Managed Agents الخيار المكافئ للفرق التي تحتاجها داخل منظومة AWS. ستحصل على بيئة التشغيل دون عناء صيانتها، وعلى بيئات معزولة دون الحاجة لتهيئتها. وقد لا تحتاج إلى لوحة مهام على الإطلاق، فتطبيقك هو اللوحة بحد ذاته.
أما إذا كان وكلاؤك يعملون كأعضاء فريق على شفرتك البرمجية الخاصة—يُشغّلهم البشر، ويراجع أعمالهم البشر، وتُدمج نتائجهم عبر مستودعاتك البرمجية وأنظمة التتبع الحالية لديك—فإن المعادلة تختلف هنا. يتولى Codex وClaude Code التنفيذ البرمجي، بينما تدير Sharkly إسناد المهام على مستوى الفريق، والحواسيب المتصلة، وسياق المهام، ومعدلات التقدم، والعوائق، والنتائج، والمراجعة البشرية عبر كل تلك الأدوات. إنها ليست بديلاً عن أي من بيئتي التشغيل، ولا عن Agents API. وتحديد المكان الأنسب ينطبق أيضاً على Codex نفسها، وهو ما نفصله في مقالنا Codex السحابية مقابل حواسيبك الخاصة.
استأجر بيئة التشغيل إذا كنت تبني وكيلاً ذكياً. واحتفظ بطبقة الإدارة لنفسك مستقلة ومحايدة عن أي مزود خدمة إذا كنت تدير عملهم.
إذا كنت تشغّل بالفعل عدة وكلاء، توفر لك Sharkly مكاناً موحداً لإدارة مهامهم ونتائجهم. مع العلم أن Sharkly لا تبيع رموز الذكاء الاصطناعي (tokens)، بل يستمر استهلاك النماذج عبر اشتراكاتك أو مفاتيح API المهيأة في الأدوات التي تربطها بالمنصة.
