وكلاء AI الدائمون: نقاط الحفظ وحدها لا تكفي

وكيل الذكاء الاصطناعي الذي يستدعي أدوات لدقائق أوينتظر موافقة لأيام هو نظام موزع، لاطلب HTTP طويلًا. قد تساعد ذاكرة المحادثة النموذج على تذكر الكلام، لكنها لا تثبت وحدها أي أداة نُفذت، ومن وافق على الإجراء، وهل اعتمد API خارجي العملية قبل Timeout، أوأي إصدار من الكود يجب أن يستأنف المهمة.

تفصل وثائق OpenAI Agents SDK الحالية بين Sessions وحالة المحادثة المدارة وبين `RunState` القابلة لاستئناف العمل المتوقف. وتشير كذلك إلى تكاملات Durable Orchestration للتشغيلات التي تمتد عبر انتظار طويل وإعادة محاولات وإعادة تشغيل للعمليات. أما إرشادات Microsoft Durable Task فتصف حفظ انتقالات الحالة تلقائيًا والتعافي من آخر Checkpoint. هذه أدوات مهمة، لكن السلامة الإنتاجية تأتي من العقد المحيط بها.

يتكون التصميم الموثوق من أربع طبقات: ذاكرة المحادثة، وحالة التنفيذ، والتنسيق الدائم، وسجل الآثار الخارجية. اعتبار أي طبقة منها حلًا كاملًا ينتج الأعطال الأهم: Refunds مكررة، ورسائل بريد معادة، وموافقات قديمة، وتشغيلات تستأنف تحت كود غير متوافق.

افصل الذاكرة عن حقيقة التنفيذ

تجيب الذاكرة عما يجب أن يراه Model Call التالي. أما Execution State فتجيب عما اعتمده النظام فعلًا. افصلهما حتى إن كان SDK واحد يستطيع تخزينهما. قد تحتوي Session رسائل المستخدم ومخرجات الأدوات، بينما يجب أن يحمل سجل التنفيذ Run ID والخطوة الحالية وإصدار Workflow وPending Tool Calls وحالة الموافقة وعدد المحاولات والمواعيد ومراجع الإيصالات الخارجية.

توثق OpenAI أن `RunState` حد قابل للتسلسل للإيقاف والاستئناف، ويشمل Model Responses وGenerated Items وInterruptions وحالة الموافقة. ويحذر المرجع من استئناف Snapshots مستقلة بالتوازي على Session نفسها. يكشف ذلك مسؤولية على التطبيق: أضف Optimistic Version أوLease حتى يملك Worker واحد فقط انتقال الحالة.

يمكن أن يبدأ السجل الدائم هكذا:

run_id, tenant_id, workflow_version
state_version, status, current_step
pending_action_id, approval_id
checkpoint_uri, session_ref
lease_owner, lease_expires_at
created_at, updated_at

خزن Model Context الكبير أوArtifacts منفصلة، وأشر إليها عبر IDs ثابتة. شفّر الحالة الحساسة وطبّق Tenant Isolation وسياسة Retention. لا تعِد Snapshot أرسلها Client مباشرة إلى Runner؛ تقول الوثائق إن الحالة المتسلسلة تحتوي Approvals وPending Tool Arguments لكنها لا تتحقق من أصالة Snapshot أوهوية المراجع.

احفظ انتقالات الأعمال لا كل Token

يجب أن تمثل Checkpoint حدًا ثابتًا قابلًا للإعادة والتدقيق: قبول الخطة، أوتسجيل Tool Result، أوطلب الموافقة، أوحسمها، أواعتماد المخرج النهائي. تخزين كل Streaming Token يرفع الكلفة دون حماية External Action. والتخزين عند النهاية فقط يفقد عمل النموذج المكلف ويترك عمليات غامضة بعد العطل.

اكتب State Transition والJob التي تجدول الخطوة التالية ذريًا متى أمكن. يفيد Outbox عندما لا تشترك قاعدة البيانات وQueue في Transaction واحدة: اعتمد `step_completed` مع Outbox Row، ثم دع Dispatcher ينشر Job التالية. لا ينفذ Consumer الإقرار إلا بعد اعتماد الحالة الدائمة التالية.

يجب أن تحمل Checkpoint إصدارات Workflow وPrompt وTool Schema التي أنشأتها. قد يتوقف Run اليوم للموافقة ويستأنف بعد Deployment غدًا. إذا فسّر Worker الجديد الحالة القديمة بطريقة مختلفة، يصبح التعافي Migration لاRetry. وجّه التشغيلات القديمة إلى Workers متوافقة أوهاجر Snapshots صراحة عبر Version Adapters مختبرة.

صمّم كل أثر خارجي لتنفيذ مرة واحدة على الأقل

يمنع Durable Orchestration ضياع التقدم، لكنه لا يجعل Payment أوEmail أوERP Mutation تنفذ مرة واحدة سحريًا. توثق Microsoft أن Durable Task Activities تضمن At-least-once Execution: إذا اكتملت Activity ولم يُسجل Result فقد يعيد Runtime تشغيلها. لذلك توصي الإرشادات الرسمية بمنطق Idempotent مثل Upsert أوفحص النتيجة القائمة قبل الإنشاء.

امنح كل Tool Call مؤثرة Operation Key يملكه التطبيق، مثل `run_id + action_id + semantic_version`. احفظ Action Ledger Row قبل الإرسال، وأرسل المفتاح نفسه إلى المزودين الذين يدعمون Idempotency، ثم احفظ Provider Receipt. تبدأ المحاولة المعادة بقراءة السجل. إذا كانت الحالة `succeeded` أعد النتيجة المحفوظة؛ وإذا انتهت مهلة `in_flight` طابق مع المزود قبل اتخاذ قرار الاستدعاء مجددًا.

prepared -> dispatched -> succeeded
                     \-> outcome_unknown -> reconciled

لا تولد مفتاحًا جديدًا لكل Retry. ولا تسجل Failure لمجرد أن Client تعرض لـTimeout؛ فقد يكون الطرف البعيد قد اعتمد العملية. للمزود الذي لا يدعم Idempotency Keys، استخدم Natural Business Key وUnique Constraint وPreflight Lookup وReconciliation. بعض الآثار، مثل إرسال بريد للخارج، لا يمكن عكسها تمامًا؛ الهدف بروتوكول قابل للقياس للغموض، لاضمان Exactly-once خيالي.

اجعل الموافقة قرارًا دائمًا وذريًا

يسمح دليل OpenAI للموافقة البشرية بإيقاف التشغيل عند Tool Call، وتسلسل الحالة، وتطبيق Approval أوRejection، ثم الاستئناف. ويقدم توجيهًا أمنيًا مهمًا: احتفظ بالحالة الكاملة على الخادم، وتحقق من هوية المراجع وصلاحيته، وطابق Decision IDs مع الطلبات المعلقة التي يملكها الخادم، واستهلك كل قرار ذريًا حتى لا تستأنف طلبات متزامنة أومعادة Snapshot نفسها مرتين.

يجب أن ترتبط الموافقة بإجراء محدد ومعاملاته وإصدار السياسة وTenant ووقت انتهاء، لا بجملة غامضة مثل وافق على هذا الوكيل. اعرض للمراجع Normalized Diff يوضح المستلم والمبلغ والمورد والتغيير المتوقع ومسار التراجع أوالتعويض. وتعامل مع Tool Names وArguments كمحتوى عرض غير موثوق أنتجه النموذج ونفذ Escaping له.

بعد الموافقة، تحقق من Mutable Preconditions مرة أخرى مباشرة قبل التنفيذ. قد يتغير رصيد العميل أوDeployment Target أوAccess Role أثناء التوقف. توافق الموافقة على النية التي روجعت، ولا يجب أن تتجاوز Authorization أوLimits أوInput Guardrails الحالية. سجل من قرر ومتى وتحت أي Policy وأي Action Fingerprint شمله القرار.

حافظ على قابلية إعادة التنسيق وإصداره

تعيد محركات التنفيذ الدائم بناء Control State عبر Replay للتاريخ. تشترط وثائق Temporal الرسمية أن يكون Workflow Code حتميًا، وأن توضع API Calls وDatabase Queries وModel Invocations والأعمال غير الحتمية في Activities خارج Replay Path. كما تحذر من أن تغيير ترتيب الأوامر لتشغيل قائم قد ينتج Nondeterminism، وتقدم Worker Versioning أوPatching.

الحد العملي واضح: يقرر Orchestration الخطوة التالية من التاريخ المسجل؛ وتنفذ Activities عمليات I/O غير المضمونة. لا تقرأ Wall Clock أوRandomness أوMutable Configuration داخل المنطق المعاد إلا إذا سجل Runtime القيمة. تنتمي Model Calls إلى Activities لأن Prompt نفسه قد يعيد إجابة مختلفة لاحقًا.

أصدر Prompts وTool Schemas وRouting Policy بشكل مستقل. لا يعني Deployment متوافق للكود أن Prompt متغير آمن لموافقة قديمة. احتفظ بالـModel Result الذي اختار الأداة، لكن طبق Authorization وBusiness Rules في كود تطبيقي حتمي بدل مطالبة النموذج بتذكر السياسة عند الاستئناف.

اختبر الأعطال عند حدود الاعتماد

لا يثبت Happy Path Demo شيئًا تقريبًا عن الاستمرارية. ابنِ اختبارات فشل حول النوافذ الضيقة التي تجعل النتيجة غامضة: بعد اعتماد المزود وقبل حفظ الإيصال؛ وبعد اعتماد Checkpoint وقبل نشر Job التالية؛ وبعد تسجيل الموافقة بينما يتسابق Workers للاستئناف؛ وأثناء Deployment مع تشغيلات قديمة منتظرة؛ وبعد نجاح Session Append ثم انهيار Worker.

راقب Recovery Time والآثار المكررة التي مُنعت وUnknown Outcomes التي تنتظر المطابقة وعمر Checkpoint وتعارض Leases وزمن الموافقة والموافقات المنتهية وRetries لكل Activity وToken Cost لكل Run مكتمل والتشغيلات المثبتة على Workflow Versions قديمة. تفيد Trace IDs في التحقيق، لكن Traces للملاحظة وليست مصدر حقيقة التنفيذ.

ابدأ بمسار مؤثر واحد، واكتب Invariants قبل اختيار Framework: مالك واحد لكل انتقال، وهوية دائمة واحدة لكل أثر، وقرار مصرح واحد لكل موافقة، ومسار إصدار متوافق لكل Checkpoint. ثم قرر هل تكفي Serialized SDK State مع Queue أمأن Durable Orchestrator مبرر. المعمارية الأقوى ليست الأكثر تجريدًا في الوكلاء، بل التي تستطيع بعد العطل تفسير ما حدث بالضبط وما الآمن فعله تاليًا.

إعداد: Noor Yasser