<h2>نظرة متعمقة في OpenAI AgentKit: تقييم تقني</h2>
وجهة نظر الكاتب: لماذا يُعد "قويًا ولكنه ليس مثاليًا"؟ كيف يتعايش مع Dify/n8n، وفي أي سيناريوهات يتفوق؟
<h3>1. ملخص تنفيذي (الاستنتاجات أولاً)</h3>
<ul>
<li>
"Dify قد انتهى / سيتم استبدال n8n" هو حكم عاطفي. إن "سير العمل" (workflow) الخاص بـ OpenAI يشبه منصة متكاملة لتطوير—تقييم—نشر—تضمين الوكلاء (AgentKit + Agent Builder + Evals + embedded UI)، وهو ليس مصمماً ليكون ناقل أتمتة مؤسسياً شاملاً.
</li>
<li>
المزايا الجوهرية: مكونات وكلاء (Agent) أصلية، تنسيق مرئي مع تتبع الإصدارات، تقييم مدمج (Evals)، واجهة مستخدم مضمنة، موصلات رسمية وحوكمة أمنية، مما يقلل بشكل كبير من الاحتكاك في مرحلة الانتقال من "النموذج الأولي إلى الإنتاج".
</li>
<li>
لكنه ليس بديلاً مباشراً لـ Dify/n8n: تكاليف هجرة وتعلم عالية للأنظمة الحالية؛ لا يزال النموذج يعتمد على "سير العمل القائم على العقد" (node-based workflow)، وليس خروجاً جذرياً عن التنسيق التقليدي.
</li>
<li>
المستخدمون الحقيقيون هم بشكل أساسي في "السوق المتنامي": المشاريع الجديدة، الفرق التي تطبق الوكلاء (Agents) لأول مرة، والفرق التي تحتاج إلى تحويل المنتجات لواقع ملموس بسرعة وحلقات تقييم فعالة.
</li>
<li>
المستقبل يخص بنية الأكواد القائمة على الذكاء الاصطناعي (AI-native)؛ أما سير العمل فما هو إلا حالة مؤقتة.
</li>
</ul>
<h3>2. ما هو "سير العمل" الجديد من OpenAI بالضبط؟</h3>
يُطلق عليه رسمياً AgentKit (بما في ذلك Agent Builder، إلخ). الجوهر هو تغليف سلسلة "التنسيق، تكامل الأدوات، التقييم، وتضمين الواجهة الأمامية" التي كانت مشتتة سابقاً في منصة موحدة: يمكنك بناء عمليات قائمة على العقد على لوحة قماشية (مسار مزدوج كود/مرئي)، وربط الأدوات والموصلات، وتشغيل تقييمات متكاملة (Evals)، وإنتاج أشكال منتجات بسرعة مع واجهة مستخدم مضمنة.
<ul>
<li>
Agent Builder: لوحة مرئية تحتوي على عقد تشمل استدعاءات النماذج، الأدوات/MCP/الموصلات، الشروط/الحلقات وقيود الحماية (guardrails)، مع دعم لإصدارات النسخ وتشغيل الاختبارات التجريبية (dry-run).
</li>
<li>
Agents SDK: مسار يعتمد على الكود أولاً، متطابق مع اللوحة المرئية؛ كلاهما يعتمد على نفس تجريد الاستجابة/وقت التشغيل (مما يسهل التعاون بين الفريق في أسلوب "ما تراه هو ما تحصل عليه مقابل الكود").
</li>
<li>
Evals for Agents: تقييم مدمج في حلقة التطوير، يدعم المقارنة الأساسية/التراجعية/A-B، لتجنب "الإنتاج بناءً على الشعور".
</li>
<li>
Embedded UI (مثل ChatKit/Apps SDK): يقلل من هندسة الواجهة الأمامية، مما يسمح بتضمين الوكلاء بسرعة في المنتجات الحالية أو تشغيلهم داخل ChatGPT.
</li>
<li>
الموصلات والأمن: نظام بيئي مدار رسمياً، مما يقلل من مخاطر الامتثال والأمن الناتجة عن النصوص البرمجية غير الرسمية.
</li>
</ul>
<h3>3. اختلافات التمركز والمقارنة مع Dify/n8n</h3>
<ol>
<li>
التمركز: تسعى OpenAI نحو "منصة تطوير تعتمد على الوكلاء بشكل أصيل"؛ بينما Dify/n8n هما أقرب إلى مراكز أتمتة وتنسيق شاملة ذات اتصال أوسع.
</li>
<li>
الحدود: تتفوق OpenAI في "المتجر الشامل لتحويل الوكلاء إلى منتجات" (التنسيق ← التقييم ← التضمين ← الإنتاج)؛ بينما تتفوق Dify/n8n في "التكامل النظامي داخل وخارج المؤسسة ونظام المحفزات (triggers)".
</li>
<li>
الهندسة: تجعل التقييمات (Evals) وتتبع الإصدارات تقارب جودة الوكيل قابلاً للقياس، وهو ما يمثل حلقة ضعيفة في منصات الأتمتة التقليدية.
</li>
<li>
الهجرة: بالنسبة للفرق التي تمتلك عدداً كبيراً من العقد/العمليات المخصصة، فإن نسبة قيمة الهجرة إلى المخاطرة ليست عالية على المدى القصير؛ النهج الأكثر واقعية هو الوصول الجانبي للقدرات الجديدة.
</li>
</ol>
<h3>4. لماذا هو "قوي ولكنه ليس بديلاً"؟</h3>
<ul>
<li>
الاعتماد على المسار للأنظمة الحالية: سنوات من مكتبات العقد المتراكمة، والعمليات، والأعراف التنظيمية لن تهاجر بالكامل لمجرد وجود منصة جديدة.
</li>
<li>
النموذج لم يتغير جذرياً: لا يزال مدفوعاً بـ "العقد + الرسوم البيانية الموجهة"؛ لا تزال الأعمال المعقدة تتطلب من المطورين تغليف العقد المخصصة وقواعد الحوكمة.
</li>
<li>
اتساع النظام البيئي: من حيث "ربط أكثر من 1000 تطبيق SaaS عبر الويب"، من الصعب مضاهاة اتساع منصات الأتمتة الراسخة في المدى القصير.
</li>
</ul>
<h3>5. من هم المستخدمون الحقيقيون (السوق المتنامي)؟</h3>
<ul>
<li>
المشاريع/الفرق الجديدة التي تقترب من الوكلاء لأول مرة: يحتاجون لتحويل إثبات المفهوم (PoC) بسرعة إلى شكل جاهز للإنتاج.
</li>
<li>
المؤسسات التي تركز على حلقات التقييم واستضافة الأمن: تحتاج إلى تقديم "الجودة والحوكمة" في المراحل الأولى.
</li>
<li>
الفرق التي تأمل في توزيع/تشغيل التطبيقات مباشرة في ChatGPT: الاستفادة من التطبيقات/واجهة المستخدم المضمنة للوصول إلى المستخدمين بشكل أسرع.
</li>
</ul>
<h3>6. التحليل التقني: كيف يعمل سير العمل؟</h3>
طبقة العملية (Process Layer): عقد اللوحة = استدعاءات (نماذج لغوية/أدوات/موصلات) + تدفق التحكم (شروط/حلقات/توازي) + قيود الحماية (قيود/تحقق).
طبقة وقت التشغيل (Runtime Layer): سواء كانت مرئية أو برمجية، فإنها تخرائط في النهاية إلى تجريد موحد للاستجابة/التنفيذ (مما يسهل تتبع الإصدارات والقدرة على التتبع).
طبقة التقييم (Evaluation Layer - Evals): إنشاء مجموعات مهام ومقاييس تأكيد للمسارات الرئيسية، وأي تغييرات تتطلب تشغيل التقييم الأساسي/التراجعي أولاً؛ كما يتم أرشفة النتائج الوسيطة من المحادثات/استدعاءات الأدوات للمقارنة.
طبقة التضمين (Embedding Layer): استناداً إلى المكونات (مثل ChatKit/Apps SDK)، يتم عرض الوكلاء في "شكل منتج" للمستخدمين النهائيين، مع إدارة حالة المحادثة والتحكم في الوصول.
<h3>7. "عدم استخدام الكود هو للمبتدئين" هو طرح خاطئ</h3>
تقلل الواجهات الرسومية من عتبة البناء ولكنها لا تقوم تلقائياً بإنشاء تفكيك معقول للمهام وحوكمة للحدود. لا تزال العمليات المستقرة والقابلة للصيانة تتطلب من المطورين التحكم في التجريد، والتراجع (rollback)، وقابلية الملاحظة، والتقييم. يقلل سير عمل OpenAI من الاحتكاك الهندسي لكنه لا يلغي الهندسة نفسها.
<h3>8. ليس ذكاءً اصطناعياً أصيلاً (AI-Native) تماماً بعد: الفجوات والتوقعات</h3>
<ul>
<li>
لا يزال يعامل "العمليات المحددة مسبقاً" كعناصر أساسية: مساحة محدودة للتنظيم الذاتي/التطور الذاتي.
</li>
<li>
العقد المخصصة لا تزال ثقيلة: تحتاج الأعمال المعقدة إلى صيانة مكتبات الوظائف/مكتبات السياسات، وتكاليف الحوكمة ليست ضئيلة.
</li>
<li>
توجه أكثر نحو الـ AI-Native: جعل "الهدف—السياسة—الدليل" عناصر أساسية، وإدخال دلالات سلوكية قابلة للتحقق ووقت تشغيل مدفوع بالقيود.
</li>
</ul>
أفكار مرجعية وممارسة مستمرة: Axon (الجوهر: تخطيط انعكاسي ذاتي، مدفوع بالقيود، دلالات قابلة للتحقق) — <a href="https://github.com/nxcode-io/Axon">https://github.com/nxcode-io/Axon</a>
<h3>9. توصيات التنفيذ لمختلف الفرق</h3>
الفرق التي تستخدم Dify/n8n حالياً: لا تتعجل في الهجرة. استخدم أولاً تقييم OpenAI وواجهة المستخدم المضمنة كـ "قدرات خارجية"، وقم بالوصول إليها من منصتك الأصلية، وقم بقياس الفوائد قبل التفكير في هجرة سلاسل الوكلاء.
المشاريع الجديدة/الفرق الناشئة: إذا كان الهدف هو "تسليم الوكلاء كمنتجات"، فأعطِ الأولوية لمسار AgentKit للحصول على أشكال جاهزة للإنتاج وأنظمة مقاييس بسرعة.
الفرق التي تسعى للـ AI-Native: صمم آليات "التقييم كحوكمة"، وقلل من الاعتماد على "الأسلاك المسبقة"، وعزز "الأهداف والأدلة"، مع جعل وقت التشغيل القائم على السياسة/القيود هو الجوهر.
<h3>المراجع والروابط</h3>
[1] OpenAI | Introducing AgentKit: <a href="https://openai.com/index/introducing-agentkit/">https://openai.com/index/introducing-agentkit/</a>
[2] OpenAI | Build every step of agents on one platform (Agent Platform): <a href="https://openai.com/agent-platform/">https://openai.com/agent-platform/</a>
[3] OpenAI | DevDay 2025: <a href="https://openai.com/devday/">https://openai.com/devday/</a>
[4] OpenAI | New tools for building agents: <a href="https://openai.com/index/new-tools-for-building-agents/">https://openai.com/index/new-tools-for-building-agents/</a>
[5] OpenAI Agents SDK Documentation: <a href="https://openai.github.io/openai-agents-python/">https://openai.github.io/openai-agents-python/</a>
[6] Wired | OpenAI Wants ChatGPT to Be Your Future Operating System: <a href="https://www.wired.com/story/openai-dev-day-sam-altman-chatgpt-apps">https://www.wired.com/story/openai-dev-day-sam-altman-chatgpt-apps</a>
[7] The Verge | OpenAI will let developers build apps that work inside ChatGPT: <a href="https://www.theverge.com/news/793039/openai-chatgpt-apps-developers-sdk-canva-zillow-devday-2025">https://www.theverge.com/news/793039/openai-chatgpt-apps-developers-sdk-canva-zillow-devday-2025</a>
[8] TechCrunch | OpenAI launches AgentKit to help developers build and ship AI agents: <a href="https://techcrunch.com/2025/10/06/openai-launches-agentkit-to-help-developers-build-and-ship-ai-agents/">https://techcrunch.com/2025/10/06/openai-launches-agentkit-to-help-developers-build-and-ship-ai-agents/</a>
[9] VentureBeat | OpenAI unveils AgentKit that lets developers drag and drop to build AI agents: <a href="https://venturebeat.com/ai/openai-unveils-agentkit-that-lets-developers-drag-and-drop-to-build-ai">https://venturebeat.com/ai/openai-unveils-agentkit-that-lets-developers-drag-and-drop-to-build-ai</a>
[10] Box Blog | Box enables the agentic enterprise with support for OpenAI's new AgentKit: <a href="https://blog.box.com/box-enables-agentic-enterprise-support-openais-new-agentkit">https://blog.box.com/box-enables-agentic-enterprise-support-openais-new-agentkit</a>
[11] The Tech Portal | OpenAI integrates third-party apps and introduces AgentKit: <a href="https://thetechportal.com/2025/10/07/openai-integrates-third-party-apps-in-chatgpt-and-introduces-agentkit-for-developers/">https://thetechportal.com/2025/10/07/openai-integrates-third-party-apps-in-chatgpt-and-introduces-agentkit-for-developers/</a>
[12] Axon (nxcode-io): <a href="https://github.com/nxcode-io/Axon">https://github.com/nxcode-io/Axon</a>

لماذا يُعد 'قويًا ولكنه ليس مثاليًا'؟ كيف يتعايش مع Dify/n8n، وفي أي سيناريوهات يتفوق؟

نظرة متعمقة في OpenAI AgentKit: تقييم تقني

<h2>فخ سير العمل</h2>
أكتوبر 2025
نحن بحاجة إلى اسم لهذا النوع الجديد من تطبيقات الذكاء الاصطناعي التي يبدو أن الجميع يبنيها باستخدام أدوات مرئية مثل Agent Builder. إنها تبدو مثل الذكاء الاصطناعي، وتستخدم الذكاء الاصطناعي، لكنها ليست ذكاءً اصطناعياً بالطريقة المهمة حقاً. لنطلق عليها اسم "سير العمل الذكي" (Smart Workflows).
سير العمل الذكي عبارة عن مخطط انسيابي (flowchart) محدد مسبقاً حيث يتم تشغيل بعض نقاط القرار بواسطة نموذج لغوي. هذا يختلف عن "الوكيل الحقيقي" (True Agent). الوكيل الحقيقي لديه هدف ويقوم بإنشاء خطته الخاصة. أما سير العمل الذكي فهو مجرد تنفيذ لخطة قمت أنت بإنشائها له مسبقاً.
قد يبدو الفرق طفيفاً، لكنه جوهري. إنه الفرق بين تعيين متدرب لاتباع قائمة مهام (checklist) وتعيين مدير لإدارة قسم. يمكن للمتدرب أن يكون فعالاً جداً في وضع علامات "صح" على المهام. أما وظيفة المدير فهي معرفة ما هي المهام التي يجب أن تكون في قائمة المهام في المقام الأول.
تعتبر "سير العمل الذكية" مغرية لأنها تطور مباشر لشيء نفهمه بالفعل: أتمتة سير العمل. لمدة عشرين عاماً، سمحت لنا أدوات مثل Zapier بربط التطبيقات بمنطق <code>if/then</code>. سير العمل الذكي هو مجرد Zapier مع منطق <code>if</code> أكثر ذكاءً بكثير. بدلاً من "إذا كان عنوان البريد الإلكتروني يحتوي على كلمة 'فاتورة'"، يمكن أن يكون "إذا كانت نبرة المستخدم تبدو مستعجلة". هذا تحسن حقيقي، لكنه تحسن تدريجي. إنه يجعل النموذج القديم أفضل، ولا يخلق نموذجاً جديداً.
خطر "سير العمل الذكي" هو أنه يمنحك شعوراً بالتقدم بينما يقودك إلى طريق مسدود. يمنحك حداً أقصى محلياً من القدرات بينما يعميك عن القمة الأعلى بكثير للوكلاء الحقيقيين. هذا هو "فخ سير العمل" (The Workflow Trap).
<hr>
لماذا يعد الفخ فعالاً للغاية؟ هناك ثلاثة أسباب رئيسية.
أولاً، أدوات البناء المرئية تعطي شعوراً بالإنتاجية. سحب مربع مكتوب عليه "Call API" وتوصيله بمربع مكتوب عليه "Summarize Output" يمنحك إشباعاً فورياً. لقد صنعت شيئاً، ويمكنك رؤيته على الشاشة.
لكن هذا الوضوح المرئي هو وهم ينهار أمام التعقيد. حاول تمثيل عملية تجارية واقعية بهذه الطريقة؛ عملية دعم عملاء تتضمن التحقق من سجل الطلبات، وفئة اشتراك المستخدم، وتذاكر الدعم السابقة، ثم منطقاً متفرعاً لعمليات الاسترداد أو التصعيد أو الخصومات. عند خمس عقد (nodes)، تكون العملية واضحة. عند خمسين عقدة، تصبح عقدة غير قابلة للقراءة.
هذا هو السبب في أننا اخترعنا لغات البرمجة. الكود هو نص، والنص هو أفضل أداة لدينا لإدارة التعقيد. يمكننا إخفاء التفاصيل في دوال (functions)، وإعادة استخدام المنطق مع المكتبات (libraries)، وفهم التغييرات باستخدام <code>git diff</code>. لا يمكنك إجراء <code>git diff</code> لعملية سحب وإفلات. لا يمكنك كتابة اختبار وحدة (unit test) لاتصال واحد. أنت تتخلى عن أقوى الأدوات التي تم ابتكارها على الإطلاق لإدارة التعقيد مقابل شعور مؤقت بالسهولة. [1]
ثانياً، يعد Agent Builder تحفة فنية في تقييد المستخدم بالمنصة (platform lock-in). السبب في أنك لا تستطيع استبدال النموذج اللغوي (LLM) الخاص به أو استضافة أدواته ذاتياً ليس عائقاً تقنياً، بل هو استراتيجية عمل.
خطة اللعب كلاسيكية:
<ol>
<li>استدراجك بتجربة سهلة ومتكاملة تكون أفضل حقاً للمهام البسيطة.</li>
<li>جعلك تعتمد على ميزات ملكية خاصة وعالية الأداء (مثل Code Interpreter) غير متوفرة في مكان آخر.</li>
<li>بمجرد أن يصبح منطق تطبيقك متشابكاً بعمق مع هذه الميزات المملوكة، تصبح تكلفة الانتقال باهظة للغاية.</li>
<li>تتدفق كل نفقاتك إلى مورد واحد.</li>
</ol>
يبدو الأمر وكأنه منصة موحدة، لكنه يعمل كقفص مذهب. أنت تتاجر بحريتك المستقبلية مقابل الراحة الحالية. تموت الشركات الناشئة عندما تفقد درجات حريتها. إن التنازل الطوعي عن التحكم في منطقك الأساسي وبنيتك التحتية لمورد واحد متجانس هو خطأ فادح.
ثالثاً، وهو الأهم، سير العمل الذكي يعلمك الأشياء الخاطئة. فهي تدربك على التفكير كمدير مهووس بالتفاصيل (micromanager). تقضي وقتك في رسم مخططات انسيابية أكثر تعقيداً، محاولاً توقع كل احتمال ممكن. هذه لعبة خاسرة؛ فالعالم الحقيقي أكثر تعقيداً بكثير من أي مخطط انسيابي يمكنك رسمه.
العمل على "وكيل حقيقي" يجبرك على التفكير بشكل مختلف. تتوقف عن تحديد العملية وتبدأ في تحديد الهدف. تتوقف عن تحديد الكيفية وتركز على الماذا. بدلاً من بناء خريطة مفصلة، أنت تبني مركبة ذكية مزودة بنظام تحديد مواقع (GPS). أنت تعطيها وجهة، وهي تحدد المسار، وتعيد الحساب عندما تواجه زحاماً مرورياً أو طريقاً مسدوداً.
يتطلب هذا مجموعة مختلفة من المهارات. لم تعد مصمماً لسير العمل، بل أصبحت مصمماً لـ "ما وراء المعرفة" (meta-cognition). تبدأ بالقلق بشأن أمور مثل:
<ul>
<li>التخطيط (Planning): كيف يقسم الوكيل هدفاً كبيراً إلى خطوات صغيرة يمكن إدارتها؟</li>
<li>استخدام الأدوات (Tool Use): كيف يعرف الأداة التي يجب استخدامها، وكيف يتعافى عندما تفشل أداة أو تعيد نتائج غير مجدية؟</li>
<li>الذاكرة (Memory): كيف يتذكر ما فعله وما تعلمه، سواء داخل مهمة واحدة أو عبر مهام متعددة؟</li>
<li>التصحيح الذاتي (Self-Correction): كيف يعرف متى لا تعمل خطته ومتى يجب تجربة نهج مختلف؟</li>
</ul>
هذه هي المشاكل الصعبة والمثيرة للاهتمام. إنها مشاكل خوارزمية ومعمارية، ولا يمكن حلها إلا بالكود.
<hr>
ماذا يعني هذا من الناحية العملية؟
هذا لا يعني أنه لا يجب عليك أبداً لمس Agent Builder. إنها أداة استثنائية لبناء النماذج الأولية (prototyping). يمكنك على الأرجح استخدامها لبناء منتج أدنى قابل للتطبيق (MVP) لفكرة جديدة بشكل أسرع من أي طريقة أخرى. وهذا أمر قيم؛ فالفكرة التي تم اختبارها مع مستخدمين حقيقيين تساوي مائة فكرة لم تُختبر.
لكن عليك أن تتعامل معها كنموذج أولي. كن مستعداً للتخلص منها. بمجرد العثور على ملاءمة المنتج للسوق (product-market fit)، يجب عليك بناء الإصدار الثاني الحقيقي بالكود. لقد أوصلك النموذج الأولي إلى سفح الجبل، لكنه لن يوصلك إلى القمة.
الفخ هو تصديق التسويق. الفخ هو الاعتقاد بأنك تبني وكيلاً "حقيقياً" على هذه المنصات. أنت لا تفعل ذلك؛ أنت تبني سير عمل ذكياً. وإذا قضيت كل وقتك في أن تصبح أفضل من يبني سير عمل ذكياً في العالم، فستتخلف عن الركب عندما ينتقل العالم إلى الوكلاء الحقيقيين.
لا تخلط بين نهاية حقبة وبداية حقبة أخرى. العمل الحقيقي يحدث في الكود، وفي أطر العمل مفتوحة المصدر التي تسمح لخطة الوكيل بأن تكون كائناً ديناميكياً وقابلاً للحساب. إنه أمر أكثر فوضوية وأصعب، ويتطلب منك أن تكون مبرمجاً لا مجرد راسم مخططات. ولكن هذا هو المكان الذي يُبنى فيه المستقبل. الفرص الكبرى لا توجد أبداً في الطرق الممهدة جيداً.
<hr>
ملاحظات
[1] يحاول الناس استبدال البرمجة بأدوات مرئية منذ 40 عاماً على الأقل. لم ينجح الأمر أبداً في التطبيقات الجادة. السبب هو أن التعقيد متأصل في المشكلة نفسها، وليس في طريقة كتابتها. التمثيل المرئي لا يزيل التعقيد؛ بل يخفيه فقط، مما يجعل التفكير فيه وإدارته أصعب في كثير من الأحيان. الكود، برغم كل صعوبته المتصورة، هو أصدق تمثيل لمنطق البرنامج لدينا.
[2] نموذج ذهني مفيد هو التفكير في "خطة" الوكيل على أنها كود. سير العمل الذكي يشبه ملفاً تنفيذياً مترجماً (compiled binary)؛ يمكنك تشغيله، لكن لا يمكنك تغييره بسهولة. الوكيل الحقيقي يشبه مترجماً (interpreter) يعمل في بيئة REPL. يمكنه فحص وتعديل وتوسيع الكود الخاص به (الخطة) أثناء تشغيله. هذه القابلية للتغيير في وقت التشغيل هي الفرق الرئيسي.
[3] يمكنك رؤية هذا التمييز في أنواع الأخطاء التي يرتكبها كل نظام. يفشل سير العمل الذكي عندما يواجه موقفاً لم يتوقعه المصمم البشري، فيصطدم بطريق مسدود في مخططه الانسيابي. أما الوكيل الحقيقي فيفشل عندما تكون عملية التخطيط أو التفكير لديه معيبة؛ قد يعلق في حلقة مفرغة أو يختار مساراً غير مثالي. النوع الثاني من الفشل أكثر إثارة للاهتمام وقابل للإصلاح؛ إنه "خطأ" (bug) في "عقل" الوكيل، وليس مجرد فجوة في السيناريو الخاص به.

فهم الفرق الجوهري بين سير العمل الذكي والوكلاء الحقيقيين، ولماذا قد يقودك نموذج سير العمل المرئي إلى طريق مسدود.

NxCode

مدونتنا

نظرة متعمقة في OpenAI AgentKit: تقييم تقني

فخ سير العمل