التنفيذ المتين هو متطلب البنية التحتية الحقيقي للوكلاء طويلة التشغيل

لماذا تكسر تشغيلات الوكلاء نموذج الطلب-الاستجابة

معظم أطر الوكلاء مبنية حول حلقة طلب-استجابة: أرسل prompt، استقبل completion، أضف إلى buffer، كرر. هذا النموذج ينجح في التفاعلات القصيرة. لكنه يفشل في التشغيلات التي تمتد ساعات، وتستدعي أنظمة خارجية، وتنتظر مدخلات بشرية، وتكتمل جزئيًا قبل أن يقاطعها شيء.

الوكيل طويل التشغيل ليس inference واحدًا. إنه workflow: سلسلة من القرارات، وtool calls، وفترات الانتظار، والكتابات إلى أنظمة خارجية. كل خطوة يمكن أن تفشل بشكل مستقل. يمكن إعادة تشغيل العملية بسبب نشر تحديث. يمكن أن ينتهي وقت مزود الخدمة في منتصف الاستدعاء. يمكن طرد عامل. عندما يحدث أي من هذا، تُترك التشغيلة في حالة غير متسقة: بعض الآثار الجانبية وقعت، وبعضها لم يقع، وbuffer المحادثة الذي حمل الخطة قد ضاع.

بدون آلية إعادة تشغيل، استراتيجية الاسترداد الوحيدة هي البدء من جديد. البدء من جديد يكرر كل كتابة خارجية نجحت بالفعل. هذه ليست مخاوف نظرية. إنها السلوك الافتراضي لمعظم حزم الوكلاء اليوم، وهي السبب في أن الفرق تنتهي بكتابة سكريبتات تسوية مخصصة أو إصلاح الحالة يدويًا بعد الانهيار.

الخاصيتان المهمتان

التنفيذ المتين للوكلاء يقوم على خاصيتين. كلتاهما مفهومة جيدًا في الأنظمة الموزعة. ولا واحدة منهما قياسية في أطر الوكلاء.

إعادة التشغيل الحتمية

بالنظر إلى نفس القرارات ونتائج الأدوات المسجلة، يجب أن تستأنف التشغيلة من نفس النقطة. هذا يعني أن كل مدخل غير حتمي — مخرجات النموذج، استجابة الأداة، قراءة الساعة، البذرة العشوائية — يُسجل في سجل append-only. عند إعادة التشغيل، يعيد runtime تشغيل السجل، ويعيد تنفيذ الأجزاء الحتمية من الworkflow، ويتخطى الآثار الجانبية المسجلة. تستأنف التشغيلة من الخطوة التي كانت قيد التنفيذ عندما ماتت العملية.

هذا ليس نفس checkpointing المحادثة. buffer المحادثة ملخص ضائع. سجل إعادة التشغيل سجل دقيق لما قررته التشغيلة وما لاحظته. الفرق مهم عندما تعتمد خطوة على نتيجة أداة لم تعد قابلة للاسترجاع، أو عندما تحدد مخرجات النموذج في الخطوة السابعة أي فرع تسلكه الخطوة الثامنة.

الآثار المتكافئة

كل كتابة خارجية يجب أن تحمل مفتاحًا يجعل المحاولة المتكررة no-op. إذا استدعت التشغيلة API دفع، يتضمن الاستدعاء مفتاح idempotency مشتقًا من معرّف التشغيلة ومعرّف الخطوة. إذا استقبل API نفس المفتاح مرتين، يعيد النتيجة الأصلية بدلًا من الخصم مرة أخرى. إذا أرسلت التشغيلة بريدًا إلكترونيًا، يكون الإرسال مفتاحًا بحيث لا تنتج إعادة المحاولة نسخة مكررة. إذا كتبت التشغيلة إلى قاعدة بيانات، تكون الكتابة upsert مفتاحًا على التشغيلة والخطوة.

Idempotency ليست خاصية للوكيل. إنها خاصية للعقد بين الوكيل وكل نظام خارجي يلمسه. هذا العقد يجب تصميمه وتوثيقه واختباره. لا يمكن استنتاجه من prompt.

أين يغيّر هذا تصميم الوكلاء

بمجرد قبول إعادة التشغيل الحتمية والآثار المتكافئة كمتطلبات، تتغير عدة قرارات تصميمية.

تصنيف الأدوات

يجب تصنيف tool calls إلى ثلاث فئات:

• نقية: لا أثر خارجي، آمنة للتكرار. قراءة ملف، حساب hash، تنسيق نص.
• متكافئة: أثر خارجي، آمنة للتكرار بنفس المفتاح. Upserts، استدعاءات API مفتاحة، إرسال رسائل متكافئ.
• غير قابلة للتكرار: أثر خارجي لا يمكن تكراره بأمان. إرسال إشعار لمرة واحدة، تنفيذ صفقة، حذف مورد بدون مسار soft-delete.

الفئة الثالثة تحتاج تأكيدًا بشريًا عند إعادة التشغيل. إذا ماتت التشغيلة بعد محاولة أثر غير قابل للتكرار ولكن قبل تأكيده، لا يمكن لruntime أن يقرر بنفسه ما إذا كان سيعيد المحاولة. يجب أن يبرز الغموض وينتظر. هذه تكلفة حقيقية: تضيف خطوة human-in-the-loop إلى الاسترداد، وتعني أن بعض التشغيلات لا يمكن أن تتقارب بدون تدخل. البديل — إعادة المحاولة بصمت — أسوأ.

الحالة في مخزن متين

حالة الوكيل تنتمي إلى مخزن متين بمخطط صريح، لا إلى buffer محادثة. يجب أن يصف المخطط التشغيلة: مدخلاتها، خطوتها الحالية، نتائج الخطوات المكتملة، الخطوة المعلقة، والميزانية المستهلكة حتى الآن. المحادثة عرض فوق تلك الحالة، وليست الحالة نفسها.

لهذا نتيجة عملية: يمكن تبديل النموذج، ويمكن إعادة كتابة prompt، ويمكن للتشغيلة أن تستأنف. الحالة غير مقترنة بنافذة سياق النموذج.

الميزانية مرتبطة بالتشغيلة

فرض الميزانية يرتبط بالتشغيلة المتينة، لا بعملية أو جلسة. التشغيلة المستأنفة تستمر في العد ضد نفس السقف. إذا استهلكت التشغيلة 60 بالمئة من ميزانية token قبل انهيار، تستأنف مع بقاء 40 بالمئة. هذا يمنع نمط الفشل حيث تضاعف حلقة انهيار-وإع

الآلية بسيطة: الميزانية حقل في سجل التشغيلة المتين، يُنقص عند كل خطوة ويُثبت قبل محاولة الأثر الجانبي للخطوة. المقايضة أن فحوصات الميزانية تضيف كتابة إلى كل خطوة، مما يزيد latency وتكلفة التخزين. للتشغيلات التي تقوم بخطوات صغيرة كثيرة، هذا العبء قابل للقياس. البديل — فقدان حالة الميزانية عند الانهيار — أسوأ.

تبعات التقييم

التنفيذ المتين يغيّر كيفية اختبار أنظمة الوكلاء.

حقن الانهيار كاختبار قياسي

أكثر اختبار مفيد هو حقن الانهيار: اقتل العامل عند كل خطوة وأكّد أن التشغيلة تتقارب إلى نفس الحالة النهائية. هذا ليس unit test. إنه property test على آلة حالة التشغيلة. يلتقط الأخطاء المهمة: خطوات غير متكافئة، حالة غير مثبتة قبل أثر جانبي، مسارات إعادة تشغيل تتباعد عن التنفيذ الأصلي.

أداة حقن الانهيار تحتاج طريقة لقتل العامل عند خطوة محددة. هذا يعني أن runtime يجب أن يعرض حدود الخطوات كhooks. بناء تلك الhooks عمل. تخطيها يعني أن أنماط الفشل تظهر فقط في الإنتاج.

سجلات إعادة التشغيل كfixtures للتقييم

سجل إعادة التشغيل سجل لمسار حقيقي: المدخلات، القرارات، نتائج الأدوات، الآثار الجانبية. يمكن استخدام ذلك السجل كfixture للتقييم. يمكن لفريق إعادة تشغيل مسار ضد نموذج جديد دون إعادة تنفيذ الآثار الجانبية. تُقارن قرارات النموذج بالقرارات المسجلة، وتُحلل الفروق.

هذا تحول كبير. اليوم، تقييم نموذج جديد على مهام الوكلاء يعني عادة إعادة تشغيل المهمة من البداية إلى النهاية، مما يعني إعادة تنفيذ الآثار الجانبية، مما يعني إما استخدام sandbox أو قبول التكلفة. سجلات إعادة التشغيل تتيح للفرق فصل جودة القرار عن تنفيذ الأثر. المقايضة أن سجلات إعادة التشغيل جودتها بقدر جودة التسجيل: إذا كانت التشغيلة الأصلية غير حتمية بطرق لم يلتقطها السجل، ستتباعد إعادة التشغيل لأسباب لا علاقة لها بالنموذج.

ما يجب بناؤه أولًا

الترتيب مهم. ابدأ بسجل إعادة التشغيل: سجل append-only للقرارات، ونتائج الأدوات، وحدود الخطوات. ثم اجعل كل كتابة خارجية متكافئة بمفتاح مشتق من التشغيلة والخطوة. ثم صنّف الأدوات وأضف تأكيدًا بشريًا للفئة غير القابلة للتكرار. ثم اربط الميزانية بسجل التشغيلة. ثم ابنِ أداة حقن الانهيار.

كل خطوة مفيدة بشكل مستقل. سجل إعادة التشغيل وحده يجعل debugging ممكنًا. الكتابات المتكافئة وحدها تمنع الآثار الجانبية المكررة. النظام الكامل يجعل الوكلاء طويلة التشغيل قابلة للتشغيل.

حلقة prompt ليست الجزء الصعب. الجزء الصعب هو البنية التحتية التي تتيح لتشغيلة أن تنجو من العملية التي بدأتها.