ملاحظة الكاتب: ننطلق من مبدأ «لا تطلب قرارًا بشريًا إلا عند حذف البيانات أو إنفاق المال أو تغيير الاتجاه»، لنشرح ثلاثة أبعاد لتحديد حدود القرار البشري في أنظمة أتمتة الـAgent، وتصميم مسار الموافقات، وتوزيع مهام التحقق عبر CI.
عندما ينتقل الـAgent من «محادثتك» إلى «إنجاز العمل بدلًا منك»، لا تكون أصعب مهمة غالبًا هي تشغيله، بل تحديد متى يجب أن يتوقف. فإذا كثرت نقاط الموافقة، تحولت الأتمتة إلى مجرد «نقر بشري على زر التأكيد». وإذا قلّت أكثر من اللازم، فقد يمحو حذف خاطئ أو إنفاق خارج السيطرة مكاسب أشهر من زيادة الكفاءة. تتناول هذه المقالة سؤال متى يجب أن يتوقف الـAgent ليسأل شخصًا؟، وتقدم طريقة قابلة لإعادة الاستخدام لتحديد حدود القرار البشري.
هذه ليست مناقشة عامة من نوع «الذكاء الاصطناعي خطير، فلنحذر». ننطلق من نظام حقيقي شارك صاحبه تفاصيله علنًا: بنى صانع المحتوى كازيك نظام أتمتة قائمًا على الـAgent على مدى قرابة عام، ولا يطلب منه الحسم عبر بطاقات Feishu إلا في ثلاثة أنواع من القرارات المهمة: حذف البيانات، وإنفاق المال، وتغيير الاتجاه. نحول هذا المبدأ إلى أبعاد تساعد على اتخاذ القرار، ونضيف طريقة لتصميم مسار الموافقات.
الفائدة الأساسية: بعد قراءة المقال، ستتمكن من تحديد العمليات التي يمكن للـAgent تنفيذها باستقلالية، وتلك التي تتطلب تأكيدًا بشريًا، وستعرف كيف تصمم مسار موافقات يحد من المخاطر دون تعطيل الأتمتة.
متى يجب أن يتوقف الوكيل ويسأل الإنسان؟ ثلاث نقاط للقرار
يقدم نظام كازيك إجابة محددة: يتدخل الإنسان في ثلاث حالات فقط. يربط الجدول التالي بين نقاط القرار الثلاث وطبيعة المخاطر التي تنطوي عليها.
| نقطة القرار | العمليات المعتادة | طبيعة المخاطر | لماذا يلزم تدخل الإنسان؟ |
|---|---|---|---|
| حذف البيانات | تنظيف سجلات قاعدة البيانات، وحذف الملفات، والكتابة فوق الإصدارات السابقة | يصعب التراجع عنها | بمجرد التنفيذ، تصبح تكلفة التراجع مرتفعة للغاية، وقد يتعذر استرداد البيانات |
| إنفاق المال | استدعاء خدمات مدفوعة، وشراء الموارد، واستهلاك حصص النموذج بكميات كبيرة | تدفق الأموال إلى الخارج | تترتب عليها تكاليف فعلية قد تتضاعف بسبب التكرار |
| تغيير الاتجاه | تعديل موضوعات المحتوى، أو تغيير استراتيجية المنتج، أو إعادة صياغة القواعد المعتمدة | التأثير في الأهداف | يفتقر الوكيل إلى سياق العمل الكامل والقدرة على الحكم وفق القيم والأولويات |
موقع حدود القرار البشري في البنية ذات الطبقات الأربع
وفقًا للملخص المنشور، تقوم الفكرة الأساسية لنظام كازيك على «إبعاد الإنسان عن نقطة بدء المهام»: تبدأ الأحداث عمل الوكيل بدلًا من أن يطلق الإنسان كل مهمة بنفسه. يتكون النظام من أربع طبقات، ويقع القرار البشري في الطبقة الأخيرة، ليعمل بمثابة «فرامل» للسلسلة بأكملها لا «دواسة وقود».
| الطبقة | المسؤولية | طريقة التنفيذ وفق المعلومات المنشورة |
|---|---|---|
| منصة الأتمتة | إدارة تشغيل المهام استجابةً للأحداث وجدولة الوكلاء في مكان موحد | إعداد القواعد مركزيًا باستخدام rules.json |
| طبقة تنفيذ الوكلاء | تشغيل مهام الوكلاء فعليًا | التشغيل محليًا على Mac Mini |
| منصة CI | تنفيذ خمس خطوات: المراجعة والفحص والدمج والنشر والتحقق | مطوّرة داخليًا |
| طبقة القرار في فيشو | طلب قرار بشري عند نقاط القرار المهمة | بطاقات فيشو |
يكشف هذا التقسيم عن توجه مهم في التصميم: تُترك معظم أسئلة «هل هذا صحيح؟» للتحقق الآلي في منصة CI، بينما تُحال إلى الإنسان أسئلة «هل ينبغي فعل هذا؟» فقط. فالنوع الأول يمكن فحصه وفق معايير موضوعية، أما الثاني فيتعلق بالمفاضلة والمسؤولية. وهذا هو الحد الفاصل الأساسي للقرار البشري.
تجدر الإشارة إلى أن المصدر الأصلي ليس سوى ملخص لم يكشف عن الحقول المحددة لبطاقات فيشو، أو وتيرة القرارات البشرية وسرعة الاستجابة لها، أو التعريف الدقيق لـ«تغيير الاتجاه». لذلك، فإن ما يرد لاحقًا في هذه المقالة بشأن تصميم البطاقات ومعايير الحكم هو اقتراحات إضافية مبنية على هذا المبدأ، وليس وصفًا لما ورد عن النظام الأصلي.
كيف نحدد متى يجب أن يتوقف الوكيل ويسأل الإنسان: طريقة الأبعاد الثلاثة
«حذف البيانات، وإنفاق المال، وتغيير الاتجاه» نقطة بداية جيدة، لكن العمليات في الأنظمة الواقعية تتجاوز هذه الحالات الثلاث بكثير. وعندما نختصرها في ثلاثة أبعاد قابلة لإعادة الاستخدام، يصبح تصنيف أي عملية جديدة سريعًا: قابلية التراجع، والأثر على التكلفة، والأثر على الاتجاه.
البعد الأول: قابلية التراجع تحدد إمكانية إصلاح العواقب
السؤال هنا هو: «إذا حدث خطأ، هل يمكن التراجع عنه؟». كتابة مسودة، أو إنشاء فرع، أو تشغيل برنامج نصي في بيئة اختبار، كلها عمليات يمكن التراجع عنها؛ فإذا حدث خطأ، يكفي التخلص من النتيجة والبدء من جديد. أما حذف بيانات بيئة الإنتاج، أو إرسال رسائل بريد إلكتروني إلى جهات خارجية، أو نشر محتوى رسميًا، فهي عمليات لا يمكن التراجع عنها، أو لا يمكن التراجع عنها بالكامل، وتكلفة إصلاحها أعلى بكثير من تكلفة تنفيذها.
وللحكم على ذلك، يمكن طرح سؤال محدد: إذا اكتشف الوكيل الخطأ فور تنفيذ العملية، فكم من الوقت والجهد البشري يلزم لإصلاحه؟ إذا تجاوزت الإجابة ما يمكنك تحمّله، فيجب إخضاع العملية للموافقة.
البُعد الثاني: أثر التكلفة يحدد الحاجة إلى حدّ للموافقة على الإنفاق
لا يقتصر أثر التكلفة على «كم سننفق هذه المرة؟»، بل يشمل أيضًا احتمال تضخّم الإنفاق. غالبًا ما تنشأ أكبر المخاطر المالية للوكيل (Agent) من حلقات التكرار: فقد يؤدي خطأ في منطق إعادة المحاولة أو شرط تشغيل واسع أكثر من اللازم إلى تكرار استدعاء النموذج لساعات. وقد تصبح عملية منخفضة التكلفة في كل مرة غير مقبولة إذا تكررت بلا سيطرة.
لذلك، من العملي تحديد سقف للميزانية: ينفّذ الوكيل العمليات تلقائيًا ما دامت تكلفة كل عملية والتكلفة التراكمية ضمن الحد، ويتوقف لطلب موافقة شخص عند تجاوزه. وإذا كان الوكيل يحتاج إلى استدعاء عدة نماذج لغة كبيرة، فإن تجميع الاستدعاءات عبر منصة بواجهة موحدة مثل APIYI على apiyi.com يتيح متابعة إجمالي الاستهلاك من مكان واحد ومقارنته بالسقف، بدلًا من التنقل بين لوحات تحكم عدة مزوّدين.
البُعد الثالث: تغيير الاتجاه يحدد من يتحمل مسؤولية الهدف
تغيير الاتجاه هو الأقل وضوحًا بين الأبعاد الثلاثة. والمقصود به ما إذا كانت العملية ستغيّر «الوجهة التي نسعى إليها»، مثل تعديل استراتيجية اختيار الموضوعات، أو إعدادات القواعد، أو أولويات المنتج. يجيد الوكيل العثور على أفضل مسار نحو هدف محدد، لكنه لا يجيد الحكم على ضرورة تغيير الهدف نفسه، لأن ذلك يتطلب فهم سياق العمل، وتقدير أثر القرار على العلامة التجارية، وتحمل المسؤولية.
ومن الطرق العملية لتحديد ذلك: إذا كانت العملية ستعدّل قواعد الوكيل نفسه أو أهدافه، مثل إعادة صياغة شروط التشغيل في rules.json، أو إذا كانت نتيجتها ستصبح أساسًا لعدد كبير من المهام اللاحقة، فاعتبرها «تغييرًا للاتجاه».
| البُعد | خصائص المخاطر المنخفضة | خصائص المخاطر المرتفعة | طريقة التعامل المقترحة |
|---|---|---|---|
| قابلية التراجع | مسودة، فرع، بيئة اختبار، إمكانية التراجع بنقرة واحدة | الحذف، الاستبدال، النشر للعامة، إرسال الرسائل | المخاطر المرتفعة تتطلب موافقة |
| أثر التكلفة | تكلفة منخفضة للعملية الواحدة، وإجمالي ضمن الميزانية | تجاوز الحد، احتمال التضخّم بسبب التكرار | تنفيذ تلقائي ضمن الحد، وموافقة عند تجاوزه |
| تغيير الاتجاه | التنفيذ ضمن الأهداف المحددة | تعديل القواعد أو الأهداف أو الاستراتيجية طويلة المدى | يُترك القرار دائمًا لشخص |
| التقييم المشترك | الأبعاد الثلاثة كلها منخفضة المخاطر | ارتفاع المخاطر في أي بُعد | التوقف وطلب رأي شخص عند ارتفاع المخاطر في أي بُعد |
تكلفة الإفراط في طلب الموافقات والتقليل منها
يكمن جوهر وضع الحدود في الموازنة بين نوعين من الإخفاق. فكثرة الموافقات وقلتها قد تؤديان إلى فشل مشاريع أتمتة الوكلاء (Agents)، لكن بطرق مختلفة.
| الحالة | المظاهر المعتادة | النتيجة المباشرة | الأثر طويل المدى |
|---|---|---|---|
| الإفراط في طلب الموافقات | طلب تأكيد في كل خطوة وتراكم بطاقات الموافقة | تتحول الأتمتة إلى «ضغط أزرار يدوي» | إرهاق الموافقات، فيبدأ الأشخاص بالموافقة دون قراءة المحتوى |
| التقليل من طلب الموافقات | تنفيذ العمليات المهمة بشكل مستقل أيضًا | حذف بالخطأ، وتجاوز الميزانية، والخروج عن المسار | حادثة واحدة كفيلة بتدمير الثقة في النظام |
| حدود معقولة | التوقف عند ثلاثة أنواع فقط من الحالات عالية المخاطر | يتعامل الأشخاص فقط مع ما يحتاج فعلًا إلى حكم بشري | تتراكم الثقة تدريجيًا، ويمكن توسيع الصلاحيات بالتدريج |
أكثر أضرار الإفراط في طلب الموافقات خفاءً هو «إرهاق الموافقات». فعندما يتلقى الشخص عشرات بطاقات التأكيد يوميًا، سرعان ما يعتاد الموافقة دون قراءة محتواها. عندها تصبح الموافقة شكلية، بل أخطر من غيابها، لأن الجميع يظنون أن هناك من يدقق في الأمر. لهذا يلتزم نظام كازيك بطلب تدخل بشري في ثلاثة أنواع من الحالات فقط، حتى يستحق كل طلب اهتمامًا جادًا.
البدء السريع بتحديد حدود القرار البشري للوكيل: بناء مسار موافقة في خمس خطوات
إليك خطوات تصميم مسار موافقة من الصفر. لا تعتمد هذه الخطوات على إطار عمل معين، ويمكنك تنفيذها باستخدام أي أداة لجدولة الأحداث ومنصة مراسلة فورية.
الخطوة الأولى: حصر جميع إجراءات الوكيل
أدرج جميع الأدوات والإجراءات التي يستطيع الوكيل استدعاءها، مثل قراءة الملفات وكتابتها، وحذف السجلات، واستدعاء واجهات API خارجية، وإرسال الرسائل، وتعديل الإعدادات. صنّف كل إجراء وفق ثلاثة أبعاد لإنشاء «قائمة بمخاطر الإجراءات». تشكّل هذه القائمة أساس جميع القواعد اللاحقة، وتمنح الفريق لغة مشتركة لمناقشة الحدود.
الخطوة الثانية: إدارة القواعد مركزيًا
على غرار نهج كازيك في استخدام rules.json لإدارة قواعد التفعيل والجدولة مركزيًا، أدرج أيضًا «الإجراءات التي تتطلب موافقة» في إعدادات مركزية، بدلًا من توزيعها على موجهات كل وكيل. للإعدادات المركزية فائدتان:
- قابلة للتدقيق: يستطيع أي شخص معرفة العمليات التي تتطلب تأكيدًا بشريًا حاليًا؛
- سهلة التعديل: عندما تحتاج الحدود إلى تشديد أو تخفيف، يكفي تعديل موضع واحد.
لاحظ أن تعديل هذه الإعدادات بحد ذاته يُعد «تغييرًا للاتجاه»، لذا يجب أن يقتصر على البشر.
الخطوة الثالثة: دع CI يتحقق آليًا أولًا
قبل طلب تدخل الإنسان، دع الفحوصات الآلية تتحقق من كل ما يمكنها التحقق منه. تتضمن منصة CI المركزية لدى كازيك خمس خطوات: المراجعة، والفحص، والدمج، والإصدار، والتحقق. وهذا يعني أن القرارات التي تصل إلى الإنسان تكون قد استُبعدت منها المشكلات البسيطة، مثل أخطاء التنسيق وفشل الاختبارات. لا ينبغي للإنسان أن يجري الفحوصات بدلًا من الآلة، ولا للآلة أن تتخذ قرارات المفاضلة بدلًا من الإنسان.
الخطوة الرابعة: تصميم بطاقة القرار
فيما يلي مقترحاتنا لتصميم بطاقة القرار، وليست تفاصيل من النظام الأصلي. والمبدأ الأساسي هو تمكين الشخص من اتخاذ قرار خلال عشرات الثواني:
- وصف المطلوب في جملة واحدة: مثل «سيُحذف 3 سجلات مسودات تعود إلى ما قبل مارس»؛
- أبعاد المخاطر المنطبقة: توضيح ما إذا كان الإجراء غير قابل للتراجع، أو يتجاوز الميزانية، أو يغيّر الاتجاه؛
- نطاق التأثير والتكلفة: عدد سجلات البيانات المعنية والتكلفة المتوقعة؛
- مبررات الوكيل وأدلته: سبب اتخاذ الإجراء ونتائج تحقق CI؛
- أزرار إجراءات واضحة: الموافقة والرفض، مع توفير خيار «التعديل ثم التنفيذ» عند الحاجة.
الخطوة الخامسة: تحديد المهلة والسلوك الافتراضي
لا يمكن للإنسان أن يكون متاحًا طوال الوقت. لذلك يجب تحديد المدة التي تُعد بعدها البطاقة غير المعالجة منتهية المهلة، وما إذا كان السلوك الافتراضي عند انتهائها هو «عدم التنفيذ» أم «التنفيذ بوظائف محدودة». بالنسبة إلى إجراءات مثل حذف البيانات أو إنفاق المال، ينبغي أن يكون الخيار الافتراضي هو «عدم التنفيذ». فمن الأفضل إبقاء المهمة في الانتظار على أن يتحول الصمت إلى تفويض.
🚀 بداية سريعة: عند بناء النموذج الأولي، يُنصح باستخدام واجهة موحدة للنماذج أولًا لتجربة المسار كاملًا: «تنفيذ الوكيل ← تحقق CI ← اعتماد البطاقة». يتيح لك استدعاء عدة نماذج رائدة عبر APIYI على apiyi.com التبديل بينها دون تغيير منطق الاعتماد، ومقارنة عدد مرات طلب الاعتماد وجودة المبررات التي يقدمها كل نموذج.
توزيع الأدوار بين التحقق عبر CI والقرار البشري
تتساءل فرق كثيرة: إذا كان CI قادرًا على إجراء الفحوصات، فلماذا نحتاج إلى الإنسان؟ الإجابة هي أن كلاً منهما يجيب عن سؤال مختلف. يوضح الجدول التالي حدود دور كل منهما:
| المرحلة | السؤال الذي تجيب عنه | أساس الحكم | الجهة المسؤولة |
|---|---|---|---|
| المراجعة / الفحص | هل يتوافق الناتج مع المعايير؟ | القواعد والاختبارات والتنسيق | منصة CI المركزية |
| الدمج / النشر | هل يمكن الانتقال إلى المرحلة التالية؟ | اجتياز جميع الفحوصات | منصة CI المركزية |
| التحقق | هل طُبّقت النتيجة فعليًا؟ | التحقق بعد التنفيذ | منصة CI المركزية |
| حذف البيانات / إنفاق المال / تغيير الاتجاه | هل ينبغي القيام بذلك؟ | تقدير احتياجات العمل وتحمل المسؤولية | القرار البشري |
| مصدر استدعاء النموذج | أي نموذج يُستخدم، وما تكلفة استخدامه؟ | حدود الميزانية | قواعد الإعداد مع تدخل بشري عند الحاجة، ويمكن الاستعانة بـ APIYI apiyi.com لتجميع بيانات الاستخدام |
الأسئلة الشائعة FAQ
س1: ما حدود اتخاذ القرار البشري للوكيل (Agent)؟
هي مجموعة قواعد تفصل بين العمليات التي يمكن للوكيل تنفيذها ذاتيًا وتلك التي تتطلب موافقة بشرية. يعمل الوكيل بحرية داخل هذه الحدود، ويتوقف عند بلوغها ليترك القرار للإنسان. وتُحدَّد الحدود عادةً وفق ثلاثة معايير: إمكانية التراجع عن الإجراء، وتأثيره على التكلفة، وتأثيره على الاتجاه.
س2: ما الفرق بين الموافقة البشرية والفحوصات الآلية للتكامل المستمر (CI)؟
تجيب فحوصات CI عن سؤال «هل الإجراء صحيح؟» استنادًا إلى القواعد والاختبارات، لذا تناسب الآلات. أما الموافقة البشرية فتجيب عن سؤال «هل ينبغي اتخاذ هذا الإجراء؟» استنادًا إلى تقدير احتياجات العمل وتحمل المسؤولية. يُفضَّل أتمتة النوع الأول قدر الإمكان، وحصر الثاني في القرارات المهمة، فالجمع بينهما يحقق السرعة والاستقرار.
س3: كيف نحدّد فئة غامضة مثل «تغيير الاتجاه»؟
لم تكشف المصادر الأصلية عن الطريقة التي استخدمها الكاتب لتحديد هذه الفئة. ونقترح التعامل مع أي إجراء يعدّل قواعد الوكيل أو أهدافه، أو تصبح نتيجته أساسًا لعدد كبير من المهام اللاحقة، على أنه «تغيير للاتجاه». وعندما تكون الحدود غير واضحة، فمن الأفضل اشتراط الموافقة أولًا، ثم توسيع صلاحيات الوكيل تدريجيًا حسب الحاجة.
س4: ما السيناريوهات التي تحتاج أكثر إلى نقاط قرار بشرية؟
تشمل أهمها:
– **مهام تنظيف البيانات**: حذف السجلات أو الملفات منتهية الصلاحية دوريًا؛
– **النشر الآلي للمحتوى**: التأكيد النهائي قبل النشر للعموم؛
– **استدعاء النموذج على نطاق واسع**: الاستدعاءات المدفوعة التي قد تتضاعف بسبب التكرار؛
– **تعديلات السياسات**: تغيير اتجاه اختيار الموضوعات أو قواعد الجدولة، وغيرها.
س5: كيف يمكن التحكم في تكلفة استدعاء الوكيل لنموذج لغة كبير؟
يُنصح بتحديد حدَّين للميزانية: أحدهما لكل استدعاء والآخر للتكلفة التراكمية. ينفّذ الوكيل العمليات ذاتيًا ضمن هذه الحدود، ويطلب الموافقة عند تجاوزها. ويمكن تجميع استدعاءات النموذج عبر منصة واجهة موحّدة مثل APIYI apiyi.com، لتسهيل مراقبة الاستخدام ومراجعته مقارنةً بالحدود المحددة.
س6: كيف أتحقق سريعًا من ملاءمة حدود الموافقة التي وضعتها؟
ابدأ بتجربة مهام حقيقية على نطاق صغير، وسجّل عدد طلبات الموافقة اليومية، ومعدل الرفض، ومتوسط وقت الاستجابة. إذا كانت الطلبات كثيرة ومعدل الرفض منخفضًا جدًا، فالحدود متشددة أكثر من اللازم؛ أما إذا ظهرت مشكلات لم تُكتشف إلا لاحقًا، فالحدود متساهلة أكثر من اللازم. في المرحلة الأولى، يمكنك استخدام APIYI apiyi.com لتشغيل مجموعة المهام نفسها على عدة نماذج، ومقارنة الحالات التي يطلب فيها كل نموذج الموافقة.
س7: ما حدود هذا النهج؟
تعتمد الموافقة البشرية على توافر الشخص وسرعة استجابته، ما قد يؤدي إلى تراكم المهام في وقت متأخر من الليل أو خلال العطلات. وقد يخطئ الشخص أيضًا في الحكم إذا كانت معلومات البطاقة غير مكتملة. إضافةً إلى ذلك، تستند هذه المقالة إلى ملخص للمصدر الأصلي، ولا تتوفر حتى الآن تفاصيل منشورة عن حالات التنفيذ الخاطئ بسبب عدم الحصول على الموافقة أو عن آليات الحماية المحددة. لذلك، عند التطبيق، ينبغي إضافة آليات للمهلات الزمنية وتسجيل الأحداث والتراجع عن التغييرات بما يناسب النظام المستخدم.
متى ينبغي للوكيل أن يتوقف ويسأل الإنسان: أهم النقاط
- المبدأ الأساسي: لا تطلب تدخل الإنسان إلا في ثلاث حالات: حذف البيانات، أو إنفاق المال، أو تغيير الاتجاه. هكذا تحتفظ كل موافقة بأهميتها.
- التقييم بثلاثة أبعاد: صنّف أي إجراء جديد بسرعة وفق إمكانية التراجع عنه، وتأثيره على التكلفة، وتأثيره على الاتجاه.
- توزيع واضح للمسؤوليات: يتولى التكامل المستمر (CI) التحقق من «هل التنفيذ صحيح؟»، بينما يقرر الإنسان «هل ينبغي تنفيذه؟». ولا يغني أحدهما عن الآخر.
- الحذر من إرهاق الموافقات: كثرة طلبات الموافقة قد تدفع الشخص إلى الموافقة تلقائيًا، وهو أخطر من غياب الموافقة.
- التحفظ افتراضيًا: إذا انتهت المهلة دون معالجة الطلب، فلا تُنفّذ العمليات عالية المخاطر افتراضيًا.
- نقطة وصول موحدة: استخدم APIYI على apiyi.com لاستدعاء نماذج متعددة من مكان واحد، ما يسهّل إدارة حدود التكلفة ومقارنة النماذج.
الخلاصة
إن تحديد متى يجب على الـAgent التوقف وطلب رأي الإنسان يعني، في جوهره، رسم خط واضح بين الكفاءة والمخاطر:
- ابدأ بثلاث فئات من القرارات: حذف البيانات، وإنفاق الأموال، وتغيير الاتجاه؛ فهي تغطي معظم السيناريوهات عالية المخاطر.
- وسّع الحدود باستخدام ثلاثة معايير: قابلية التراجع، وتأثير التكلفة، ومدى تغيير الاتجاه، لتطبيقها على أي إجراء جديد.
- خفّف العبء بالتحقق الآلي: دع CI يستبعد المشكلات البسيطة، ليقتصر دور الإنسان على ما يحتاج فعلًا إلى تقدير بشري.
ليست هذه الحدود ثابتة إلى الأبد، بل يمكن توسيعها تدريجيًا مع تراكم الثقة. يُنصح ببدء تجربة تشغيلية بحدود صارمة، ثم استخدام البيانات لتحديد المجالات التي يمكن منح الـAgent فيها مزيدًا من الصلاحيات. وفي مرحلتي البناء والضبط، يُنصح باستخدام APIYI عبر apiyi.com للوصول إلى نماذج متعددة من مكان واحد، واختبار أدائها سريعًا ضمن سلسلة الموافقات لديك.
📚 المراجع
- تشارك «数字生命卡兹克» بنية نظام أتمتة للـAgent طوّرته على مدار عام: مصدر المبادئ ومعلومات البنية الواردة في هذا المقال
- الرابط:
aihot.news/items/dzwfvd9xp6v4qaj6olxezpier - توضيح: يعرض بنية من أربع طبقات تشمل منصة الأتمتة، وتنفيذ الـAgent، ومنصة CI، واتخاذ القرارات عبر Feishu، إلى جانب مبدأ «الرجوع إلى الإنسان فقط عند حذف البيانات أو إنفاق الأموال أو تغيير الاتجاه». المادة ملخص، ويجب الرجوع إلى النص الأصلي للتحقق من التفاصيل.
الكاتب: الفريق التقني في APIYI
للتواصل التقني: يسعدنا تواصلكم معنا عبر الصفحة الرئيسية لـAPIYI على apiyi.com لتبادل الخبرات العملية حول أتمتة الـAgent والتعاون بين الإنسان والآلة. ولمزيد من المعلومات، يمكنكم زيارة مركز التوثيق على docs.apiyi.com
