إذا كنت ترغب في بناء تطبيق LLM أو وكيل ذكاء اصطناعي دون توصيل كل مكون بآخر في بايثون، فإن Flowise يوفر لك لوحة مرئية بدلاً من ذلك. إنها أداة مفتوحة المصدر ومنخفضة التعليمات البرمجية حيث تقوم بسحب العقد وتوصيلها، والحصول على سير عمل AI فعال مع نقطة نهاية API في النهاية. يشرح هذا الدليل ماهية Flowise، وكيف تختلف مسارات الدردشة (chatflows) ومسارات الوكلاء (agentflows) الخاصة به، وكيف تقوم بنشره، وكيف تختبر نقطة نهاية التنبؤ وواجهات برمجة التطبيقات (APIs) التي يستدعيها سير عملك. إذا كنت قد قرأت شرحنا حول LangGraph، فإن Flowise يقع على الطرف المقابل من الطيف: مرئي أولاً بدلاً من التعليمات البرمجية أولاً. يمكنك قراءة ملف README للمشروع على GitHub للمصدر.
ما هو Flowise
Flowise عبارة عن منصة تطوير ذكاء اصطناعي توليدي مفتوحة المصدر لبناء وكلاء الذكاء الاصطناعي وسير عمل نماذج اللغة الكبيرة (LLM). تم إصدارها بموجب ترخيص Apache 2.0، لذا يمكنك تشغيلها محليًا، أو استضافتها ذاتيًا، أو تفرّعها (fork) .
الفكرة الأساسية هي لوحة عمل قائمة على العقد. كل عقدة هي وحدة بناء: نموذج دردشة، مخزن متجه، محمل مستندات، وحدة ذاكرة، مسترجع، أداة. تقوم بسحب هذه العقد إلى لوحة العمل، ورسم اتصالات بينها، وتحدد الاتصالات كيفية تدفق البيانات. عندما ينتهي التدفق، يكشف Flowise عنه كواجهة برمجة تطبيقات REST يمكنك استدعاؤها من أي تطبيق.
تحت الغطاء، يربط Flowise المكونات من أطر عمل مثل LangChain و LlamaIndex. لذا ستبدو التجريدات مألوفة إذا كنت قد استخدمت أحدهما: السلاسل، الوكلاء، مخازن المتجهات، محركات الاستعلام. الفرق هو أنك تقوم بتجميعها بالنقر والتوصيل بدلاً من استيراد الفئات واستدعاء المنشئات. هذه هي المقايضة التي يقوم بها Flowise. تتخلى عن بعض التحكم الدقيق وتكتسب سرعة ونموذجًا مرئيًا مشتركًا يمكن لفريقك بأكمله قراءته.
مسارات الدردشة، مسارات الوكلاء، والمساعدون
يوفر لك Flowise ثلاثة أنواع من البناة، واختيار النوع الصحيح أمر مهم.
| نوع البناء | الأفضل لـ | النطاق |
|---|---|---|
| المساعد (Assistant) | للمبتدئين؛ مساعدو الدردشة الذين يتبعون التعليمات، ويستخدمون الأدوات، ويقومون بـ RAG على الملفات المحملة | الأضيق، الأكثر توجيهًا |
| مسار الدردشة (Chatflow) | أنظمة الوكيل الواحد، روبوتات الدردشة، تدفقات LLM الأبسط؛ يدعم Graph RAG والمصنفين (rerankers) | وكيل واحد |
| مسار الوكيل (Agentflow) | أنظمة الوكلاء المتعددة والتنسيق المعقد مع التفريع والتكرار والتوجيه | الأوسع؛ مجموعة شاملة من Chatflow و Assistant |
مسار الدردشة (chatflow) هو تدفق Flowise الكلاسيكي. تقوم ببناء مسار منطقي واحد: تلقي سؤال، استرداد السياق، استدعاء نموذج، إرجاع إجابة. إنه يتعامل جيدًا مع روبوتات الدردشة ذات الوكيل الواحد و RAG.
مسار الوكيل (agentflow) هو اللوحة الأكبر. Flowise يضعه كمجموعة شاملة من مسار الدردشة والمساعد. هذا هو المكان الذي تبني فيه أنظمة متعددة الوكلاء، وتوجيه بين الفروع، وتكرار، وتشغيل تنسيق سير عمل أكثر تعقيدًا. إذا كان تصميمك يحتوي على عدة وكلاء يسلمون العمل لبعضهم البعض، فإن مسار الوكيل هو الطبقة التي تريدها.
المساعد (assistant) هو الخيار الأكثر توجيهًا. تعطيه تعليمات، وتُلحق به أدوات، وتوجهه إلى الملفات للاسترداد. إنها أسرع طريقة للحصول على شيء مفيد دون التفكير في بنية الرسم البياني.
كيف يتكون التدفق على لوحة العمل
تبدو عملية البناء في Flowise كالتالي. تبدأ مسار دردشة، ثم تضيف عقدًا من اللوحة اليسرى.
- أسقط عقدة نموذج دردشة واختر مزودًا (OpenAI، Anthropic، نموذج محلي، وما إلى ذلك).
- أضف محمل مستندات ومخزن متجهات إذا كنت بحاجة إلى الاسترداد.
- أضف عقدة ذاكرة بحيث يتذكر التدفق المحادثة.
- وصل المخرجات بالمدخلات بحيث يتدفق السياق إلى النموذج.
- احفظ، ثم افتح لوحة الدردشة لاختبارها مباشرة.
يدعم المحرر المرئي التعبيرات، وعقد التعليمات البرمجية المخصصة، والتفريع، والتكرار، ومنطق التوجيه. لذا فأنت لست مقيدًا. عندما لا توجد عقدة لحالتك، يمكنك كتابة عقدة وظيفة مخصصة صغيرة والحفاظ على الباقي مرئيًا.
نشر Flowise ونقطة نهاية تنبؤ REST
يعمل Flowise كتطبيق Node على المنفذ 3000 افتراضيًا. أسرع بداية هي npm:
npm install -g flowise
npx flowise start
# open http://localhost:3000
للنشر المتكرر، استخدم Docker:
docker run -d --name flowise -p 3000:3000 flowiseai/flowise
يدعم Flowise أيضًا عمليات النشر المستضافة ذاتيًا والمعزولة عن الشبكة، وهو أمر مهم إذا كانت بياناتك لا يمكن أن تغادر شبكتك.
بمجرد حفظ التدفق، يحوله Flowise إلى واجهة برمجة تطبيقات REST. تغطي وثائق التنبؤ الرسمية تنسيق الطلب الكامل. يحصل كل مسار دردشة ومسار وكيل على نقطة نهاية تنبؤ خاصة به:
POST /api/v1/prediction/{id}
الـ {id} هو معرف التدفق. ترسل نص JSON يحتوي على حقل question على الأقل، وتتلقى استجابة التدفق. تبدو مكالمة بسيطة كالتالي:
curl -X POST http://localhost:3000/api/v1/prediction/<flow-id> \
-H "Content-Type: application/json" \
-d '{"question": "What are your store hours?"}'
يدعم نص الطلب أكثر من السؤال. يمكنك تمرير streaming لتدفق الرموز مرة أخرى، و overrideConfig لتغيير إعدادات التدفق لكل طلب، و history لزرع أدوار سابقة، و uploads للصور أو الصوت. عندما يكون البث قيد التشغيل، يصدر Flowise أحداثًا مثل start و token و metadata، ثم حدث end نهائي. يشحن Flowise أيضًا حزم SDKs رسمية للبايثون و TypeScript تغلف نقطة النهاية هذه.
نقطة النهاية الواحدة هذه هي العقد بين Flowise وبقية مكدسك. يتحدث الواجهة الأمامية، والواجهة الخلفية، وخدماتك الأخرى جميعها إلى التدفق من خلالها. ولهذا السبب تحديدًا يستحق الأمر الاختبار بعناية.
متى تكون التعليمات البرمجية المنخفضة مناسبة، ومتى تفوز التعليمات البرمجية أولاً
Flowise مناسب تمامًا عندما تريد السرعة، ونموذجًا مرئيًا مشتركًا، وتكرارًا سريعًا. النماذج الأولية، وروبوتات الدردشة الداخلية، ومساعدو RAG عبر مجموعة مستندات، والعروض التوضيحية كلها تتجمع بسرعة. يمكن للمهندسين غير المتخصصين في الفريق قراءة اللوحة وفهم ما يفعله الوكيل، وهو أمر يصعب الحصول عليه من ملف بايثون.
تتقدم أطر العمل القائمة على التعليمات البرمجية أولاً عندما تحتاج إلى تحكم دقيق. إذا كنت تقوم بتتبع إصدارات منطق الوكيل في Git مع اختلافات كاملة، وكتابة اختبارات وحدة مكثفة حول كل خطوة، أو بناء آلات حالة غير عادية، فإن مكتبة مثل LangGraph أو Google Agent Development Kit تمنحك مساحة أكبر. وينطبق الشيء نفسه على OpenAI Agents SDK عندما تعتمد وكلائك على استدعاءات أدوات مخصصة. تستخدم العديد من الفرق كليهما: النموذج الأولي في Flowise، ثم نقل التصميم المثبت إلى التعليمات البرمجية بمجرد استقرار المتطلبات.
القراءة الصادقة هي أن هذا ليس ثنائيًا. يحتوي Flowise على وصول عبر API و CLI و SDK، بالإضافة إلى ميزات التتبع والتقييم والتدخل البشري، لذا فهو يتوسع إلى أبعد من كونه مجرد لعبة. ولكن كلما كان منطقك يشبه البرامج الحقيقية، كلما كافأك المكدس القائم على التعليمات البرمجية أولاً.
اختبار نقطة نهاية التنبؤ وواجهات برمجة التطبيقات التي يستدعيها تدفقك
إن الوكيل المبني في Flowise موثوق به بقدر موثوقية واجهات برمجة التطبيقات التي تدعمه. يستدعي التدفق واجهة برمجة تطبيقات LLM، وعادةً ما يستدعي أيضًا واجهات برمجة تطبيقات أدوات خارجية أو REST. هذه هي الأجزاء التي تفشل في الإنتاج، وهي بالضبط ما يمكنك اختباره في Apidog.
ابدأ بنقطة نهاية التنبؤ نفسها. تعامل مع POST /api/v1/prediction/{id} كأي نقطة نهاية REST أخرى. في Apidog، تقوم بتعيين عنوان URL، وإرسال حمولة question، وكتابة تأكيدات API التي تتحقق من شكل الاستجابة والحقول الرئيسية. قم بتشغيل ذلك كاختبار تلقائي حتى يتم اكتشاف أي تغيير في التدفق يكسر العقد قبل أن يفعله تطبيقك.
ثم اختبر واجهات برمجة التطبيقات الأساسية التي يعتمد عليها تدفقك. يمكن الوصول إلى مزود LLM وكل نقطة نهاية أداة مباشرة. إذا كنت ترغب في التطوير مقابل LLM دون استهلاك الرموز أو تجاوز حدود المعدل، وجه التدفق إلى واجهة برمجة تطبيقات وهمية تُرجع استجابات معلبة وواقعية. تعمل نفس الخدعة لواجهة برمجة تطبيقات أداة طرف ثالث غير مستقرة: قم بتقليدها، وتأكد من أن تدفقك يتعامل مع الشكل، وحافظ على مجموعة اختبارك حتمية. يوجد شرح أكثر تفصيلاً في دليل تسخير اختبار وكيل الذكاء الاصطناعي.
يتعامل Apidog أيضًا مع الأجزاء المملة ولكن الحرجة. تقوم بتخزين مفاتيح المزود لكل بيئة، لذا يستخدم تدفق التطوير الخاص بك مفتاح اختبار ويستخدم الإنتاج المفتاح الحقيقي دون تغييرات في التعليمات البرمجية. يستغرق تنزيل Apidog وإعداد هذا بضع دقائق.
الأسئلة الشائعة
هل Flowise مجاني ومفتوح المصدر؟
نعم. Flowise مفتوح المصدر بموجب ترخيص Apache 2.0، ويمكنك تشغيله مجانًا عن طريق استضافته ذاتيًا باستخدام npm أو Docker. يوجد أيضًا خيار سحابي مستضاف إذا كنت تفضل عدم إدارة البنية التحتية. بالنسبة للإعدادات الخاصة أو المعزولة عن الشبكة، يحافظ المسار المستضاف ذاتيًا على كل شيء داخل شبكتك.
هل يستخدم Flowise LangChain؟
يربط Flowise المكونات من LangChain و LlamaIndex على حد سواء. تتوافق العقد على اللوحة مع مفاهيم مألوفة من تلك الأطر: السلاسل، الوكلاء، مخازن المتجهات، المسترجعون، ومحركات الاستعلام. تحصل على نفس اللبنات الأساسية دون الحاجة إلى كتابة تعليمات الربط يدويًا.
ما الفرق بين مسار الدردشة (chatflow) ومسار الوكيل (agentflow)؟
صُمم مسار الدردشة (chatflow) لأنظمة الوكيل الواحد، وروبوتات الدردشة، وخطوط أنابيب LLM الأبسط. مسار الوكيل (agentflow) هو المجموعة الفائقة: فهو يتعامل مع أنظمة متعددة الوكلاء والتنسيق المعقد مع التفريع، والتكرار، والتوجيه. ابدأ بمسار دردشة لمساعد مباشر، وانتقل إلى مسار وكيل عندما يحتاج العديد من الوكلاء إلى التنسيق.
كيف أختبر واجهة برمجة تطبيقات تدفق Flowise؟
استدعِ نقطة نهاية التنبؤ، POST /api/v1/prediction/{id}، مع نص JSON يحتوي على question. يمكنك فعل ذلك باستخدام curl، أو حزم SDK الرسمية، أو أداة مخصصة. في Apidog، ترسل الطلب، وتؤكد الاستجابة، وتُحاكي واجهات برمجة تطبيقات LLM والأدوات التي يستدعيها التدفق، وتُشغل كل ذلك في CI. للحصول على تفاصيل المصادقة والبث الخاصة بنقاط نهاية LLM، راجع دليلنا حول اختبار واجهة برمجة تطبيقات ChatGPT باستخدام Apidog.
الخلاصة
Flowise هو المسار منخفض التعليمات البرمجية لتطبيقات LLM ووكلاء الذكاء الاصطناعي. يمكنك البناء على لوحة العقد، والاختيار بين مسارات الدردشة، ومسارات الوكلاء، والمساعدين، ونشر نقطة نهاية تنبؤ REST دون كتابة التنسيق يدويًا. إنه مناسب تمامًا للنماذج الأولية والتدفقات التي يمكن للفريق قراءتها، وتظل أطر العمل القائمة على التعليمات البرمجية أولاً هي الأفضل عندما تحتاج إلى تحكم عميق. بغض النظر عن المسار الذي تسلكه، فإن التدفق ينجح أو يفشل بالواجهات البرمجية التي يستدعيها. اختبر نقطة نهاية التنبؤ تلك وقم بتقليد واجهات برمجة تطبيقات LLM والأدوات خلفها في Apidog، وسيتصرف وكيلك بنفس الطريقة في الإنتاج كما فعل على اللوحة.