الانتقال إلى المحتوى الرئيسي
عندما يحتاج الوكيل إلى شخص، أو إلى مهمة خارجية، أو إلى أداة ينفّذها تطبيقك، يعود التشغيل بشكل طبيعي (لا كخطأ) بالحالة waiting_for_human ومعه كل ما يلزم للمتابعة. احفظ النتيجة كاملة، واجمع القرار في تطبيقك، ثم مرّر النتيجة المحفوظة والقرار إلى دالة المتابعة في الوكيل.
لا تخزّن Phaseo عمليات تشغيل Agent SDK. احفظ الحالة القابلة للاستئناف في تطبيقك عندما يجب أن تصمد بعد انتهاء طلب أو إعادة تشغيل العملية.

وافق على استدعاءات الأدوات أو ارفضها

توقف الأدوات المشروطة بالموافقة واليدوية والتفاعلية (بمشاركة بشرية) التشغيل مؤقتًا قبل تنفيذها. لكل استدعاء معلّق call من النموذج (مع id الخاص به) وkind: إما approval أو manual أو hitl. أجب عن كل استدعاء بمعرّف الاستدعاء بعينه، لا باسم الأداة، كي يبقى استدعاءان للأداة نفسها منفصلين. الاستدعاء الموافَق عليه ينفّذ أداته. أما الاستدعاء المرفوض فيرسل {"error": "<reason>"} إلى النموذج بوصفه نتيجة الأداة، مع السبب الافتراضي Tool call rejected.
أين توجد الاستدعاءات المعلّقة، وما الذي يحدث عند غياب قرار: للتوقف المؤقت نفسه أيضًا kind. تضبطه Go وC# على tool_approval لكل توقف بسبب أداة. وتضبط PHP وRuby وJava القيمة tool_approval عندما يحتاج أي استدعاء معلّق إلى موافقة، وإلا فنوع الاستدعاء الأول. أما Rust فتستخدم tool_approval لاستدعاءات الموافقة، وexternal_output عندما تحتاج كل الاستدعاءات المعلّقة إلى نتيجة خارجية، وtool_input عند الجمع بين الاثنين.
لا يوجد في Rust 0.2 نوع للرفض ولا حقل rejections. اترك الاستدعاء غير الموافَق عليه موقوفًا مؤقتًا، أو طبّق سياسة الرفض في تطبيقك قبل المتابعة.
لاشتراط الموافقة على كل استدعاء أداة بدلًا من كل أداة على حدة، اضبط requireApproval على تعريف الوكيل (require_approval في Python وRuby، وRequireApproval في Go وC#). في TypeScript هي دالة requireApproval(call, context). لا تدعم Rust الموافقة إلا لكل أداة، عبر Tool::require_approval(). توضح صفحة الأدوات كيف يُعرَّف كل نوع من الأدوات.

قدّم النتائج للأدوات اليدوية والتفاعلية

لاستدعاءات manual وhitl، مرّر النتيجة التي أنتجها تطبيقك، مفهرسة بمعرّف الاستدعاء. في Rust، هذه هي الأدوات المبنية باستخدام Tool::external(...).
يؤدي غياب المخرجات إلى فشل المتابعة بالخطأ Missing output for tool call <id> (missing بأحرف صغيرة في Go، وValueError في Python، وAgentError في Rust). لا تحل رسالة الإدخال البشري محل مخرجات الأداة.

توقّف للمراجعة البشرية

اضبط دالة رد نداء للمراجعة البشرية على تعريف الوكيل لفحص كل استجابة من النموذج قبل أن يتابع التشغيل. أعِد طلب مراجعة يتضمن reason (واختياريًا payload) للتوقف مؤقتًا، أو لا تُعِد شيئًا للاستمرار. قيمة kind للتوقف هي human_review. تستقبل دالة رد النداء معرّف التشغيل وفهرس الخطوة والرسائل واستجابة النموذج والمخرجات المحلَّلة (في Rust: معرّفي التشغيل والوكيل وفهرس الخطوة والرسائل والاستجابة وسياق التطبيق).
تابع بإدخال بشري، يُضاف إلى المحادثة كرسالة من المستخدم:
تفشل متابعة توقف المراجعة دون إدخال بشري بالخطأ Run <id> is waiting for human input (في Go: run <id> is waiting for human input؛ وفي Java: Run is waiting for human input). تشترط Rust قيمة human_input غير فارغة. وتقبل TypeScript أيضًا humanMessages منظَّمة.

احفظ حالة التشغيل بين الطلبات

نتيجة التشغيل بيانات عادية: خزّنها في قاعدة بياناتك أو مخزن الكائنات أو سجل المهمة، وأبقِ context التطبيق قابلًا للتسلسل. لا يمكن متابعة التشغيل إلا بوكيل يحمل المعرّف نفسه. توضح وصفة حلقة الوكيل المتينة تدفقًا كاملًا للحفظ والاستئناف. لتدع حزمة SDK تحفظ عمليات التشغيل وتحمّلها نيابة عنك، مرّر أداة وصول إلى الحالة تتضمن load(runId) وsave(result). عندها تحفظ الحزمة بعد كل تشغيل ومتابعة، ويمكنك المتابعة بمعرّف التشغيل بدلًا من تمرير السجل عبر كل طبقة.
في Rust، أعد إنشاء تعريف الوكيل والأدوات نفسها قبل المتابعة: فالإغلاقات (closures) وAgentDefinition ليست جزءًا من التشغيل المسلسَل. يُخزَّن النموذج الفعلي وحد الخطوات في RunRecord، لذا تبقى تجاوزات كل تشغيل فعّالة بعد المتابعة. أيًّا كان ما تخزّنه، يتولى تطبيقك تشفير عمليات التشغيل المحفوظة والاحتفاظ بها، والتفويض للموافقات والإدخال البشري، وضمان تساوي القوة (idempotency) للآثار الجانبية التي تُنفَّذ مجددًا بعد الاستئناف.
آخر تعديل في ٥ نوفمبر ٢٠٢٦