Phase 15: Autonomous Systems

الإنسان في الحلقة: تقدم ثم التزاما

الإجماع عام 2026 حول HITL محدد. ليس "الوكيل يسأل، المستخدم يضغط على موافقة". هو اقتراح ثم التزام: يتم استمرار العمل المقترح إلى متجر دائم مع مفتاح إزالة القدرة؛ ظهر للمراجعة مع النية، سلسلة البيانات، والإذنات الملموسة، نصف قطر الانفجار، وخطة العودة إلى الوراء؛ تم التزامها فقط بعد الاعتراف الإيجابي؛ يتم التحقق منها بعد التنفيذ لتأكيد أن التأثير الجانبي حدث فعلا. لاندغراف interrupt()بالإضافة إلى نقاط التفتيش PostgreSQL، Microsoft Agent Framework RequestInfoEventو (كلاودفلاير)waitForApproval()جميعها تنفيذ نفس الشكل. وضع الفشل القنوني هو موافقة العلامة المطاطية: "موافق عليه؟" يتم النقر دون مراجعة. التخفيف الموثق هو التحدي والاستجابة مع قائمة تفتيش صريحة.

Type: Learn

Languages: Python (stdlib, propose-then-commit state machine with idempotency)

Prerequisites: Phase 15 · 12 (Durable execution), Phase 15 · 14 (Tripwires)

Time: ~60 minutes

المشكلة

يقوم وكيل بعمل. يجب على المستخدم أن يقرر: الموافقة على ذلك أم لا. إذا كان القرار فوريًا، فمن المحتمل أن لا يكون مراجعة. إذا كان القرار مهيكناً، فمن البطء ولكن موثوق به. السؤال الهندسي هو كيفية جعل مراجعة مهيكنة مسار أقل مقاومة.

كان نمط HITL لعصر 2023 طلبًا متزامنًا: "يريد العميل إرسال رسالة بريد إلكتروني إلى X مع جسم Y الموافقة؟" يضغط المستخدم على موافقة. يشعر الجميع بأن النظام آمن. في الممارسة العملية ، يتم وضع علامات مطاطية شديدة على هذه السطح: يوافق المستخدمون بسرعة ، والإقرارات تتوقع القليل ، وعندما يخطئ العميل ، يظهر مسار التحقيق تاريخًا طويلًا من الموافقة التي لا يمكن للمستخدم تذكرها.

نمط 2026 اقتراح ثم الالتزام ينقل HITL إلى أساس دائم ، ويربط البيانات المعدنية المهيكلة ، ويطلب الالتزام الإيجابي. كل وكيل SDK المدار يرسل نسخة: LangGraph interrupt()، Microsoft Agent Framework RequestInfoEvent, Cloudflare waitForApproval(). أسماء API تختلف، الشكل لا.

المفهوم

آلة الدولة التي تقدم ثم تتعهد

Propose.يقوم العميل بإنتاج إجراء مقترح. يظل متخزنًا دائمًا (PostgreSQL، Redis، Durable Object). يشتمل على:

- النية (لماذا يقوم العميل بهذا)

- نسب البيانات (ما المصدر الذي أدى إلى هذا الاقتراح)

- الإذنات الملموسة (ما هي النطاقات / الملفات / النقاط النهائية)

- نصف قطر الانفجار (ما هو أسوأ حالة)

- خطة إعادة التأثير (إذا تم التزامها، كيف نُلغي ذلك)

- مفتاح الاستثمار (فريد لكل اقتراح؛ إعادة تقديم يعود نفس السجل)

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

مفتاح الإستقلال

بدون مفتاح idempotency ، يمكن لإعادة المحاولة بعد فشل مؤقت تنفيذ إجراء معتمد مرتين. مثال ملموس: المستخدم يوافق على "تحويل 100 دولار من A إلى B". التنفيذات الشبكة. تدفق العمل يوافق مرة أخرى. المستخدم قد وافق مرة واحدة ولكن يتم تنفيذ التحويل مرتين. مفتاح idempotency يربط الموافقة بأثر جانبي فريد واحد ؛ التنفيذ الثاني هو عدم العملية.

هذا هو نفس نمط الاختلاف الذي تستخدمه Stripe و AWS APIs. إعادة استخدامها لموافقة الوكيل واضح في مستندات Microsoft Agent Framework.

الاستدامة: لماذا تتجاوز عمليات الموافقة

غرفة انتظار الموافقة هي قطعة من الحالة التي لا يملكها الوكيل. يتم إيقاف سير العمل (الدرس 12) عندما يصل الموافقة، تستأنف سير العمل من تلك النقطة بالضبط. لهذا السبب تنزج لنجراف interrupt()مع التحقق من PostgreSQL وليس فقط في حالة الذاكرة موافقة بعد يومين لا يزال يجد التدفق العمل سليم.

الموافقة على طوابع المطاط والتخفيف من التحديات والرد

يُنتج واجهة المستخدم الافتراضي الخاصة بـ HITL ("موافق" / "رفض" أزرار) الموافقات السريعة دون مراجعة حقيقية. التخفيف الموثق: قائمة تفقد التحديات والردات التي تتطلب إجابات إيجابية على أسئلة محددة قبل تمكين زر الموافقة. شكل ملموس:

"هل تفهمين ما المورد الذي يلمسه هذا؟"
"هل تأكدت أن نصف قطر الانفجار مقبول؟"
"هل لديك خطة إعادة التأثير إذا فشل هذا؟ "

لا بيروقراطية من أجل نفسها وظيفة إجباري. المراجع الذي لا يستطيع إدخال علامات على الصناديق إما يطلب توضيحًا (التصاعد) أو يرفض (المتخلف الآمن). يذكر بحث الأمن العامل الإنثروپي صراحة HITL القائم على القائمة التحقق كحد من أنماط موافقة العلامات المطاطية.

ما الذي يعتبر نتيجة

ليس كل عمل يحتاج إلى اقتراح ثم التزام

Consequential actions(دائماً HITL): رسائل غير قابلة للتعديل، المعاملات المالية، الاتصالات الخارجة، تغييرات قاعدة بيانات الإنتاج، عمليات نظام الملفات المدمرة.
Reversible actions(أحياناً HITL): تحرير الملفات المحلية، تغييرات المرحلة، كتابات قابلة للتعديل مع إعادة التدفق واضحة.
Reads and inspections(لا HITL أبدا): قراءة ملف، قائمة الموارد، ودعوة API القراءة فقط.

التحقق بعد الإجراء

"تم تشغيل التزام" ليس نفس "حدثت تأثير جانبية". يمكن أن تنتج ظروف القسم الشبكي والمسابقة تدفق العمل الذي يعتقد أنه نجح بينما لم يستمر الخلفي. تقوم خطوة التحقق بإعادة قراءة الموارد المستهدفة بعد التزام التأكيد. هذا هو نفس النمط مع معاملات قاعدة البيانات مع RETURNINGشروط أو AWS GetObjectبعدPutObject. . .

قانون الاتحاد الأوروبي للاستخبارات الذكية المادة 14

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

استخدمها

code/main.pyيقوم القيادة بتحاكي ثلاثة حالات: تدفق الموافقة النظيفة، والإعادة المحاولة بعد فشل مؤقت (الذي لا يجب أن يتم تنفيذها مرتين) ، وتخزين طلاء مطلقة افتراضي مقابل تدفق التحدي والرد.

أرسله

outputs/skill-hitl-design.mdيراجع سير عمل HITL المقترح للقراءة ثم التزام الشكل والعلامات المفقودة البيانات المعدنية، والفائدة، والتحقق، أو الصعوبات والرد.

التمارين

أركضcode/main.pyتأكيد أن محاولة إعادة عرض اقتراح معتمد تستخدم سجل دائم ولا تعيد تنفيذها. الآن قم بتغيير مفتاح الإعفاء لتشمل طابع زمني وتظهر محاولة إعادة تنفيذ مزدوجة.

تمديد سجل المقترحات بـ rollbackمحاكاة تنفيذ فشل خطوة التحقق، عرض إطلاق التراجع تلقائيًا.

اقرأ إطار عملاء مايكروسوفت RequestInfoEventأدرج حقل البيانات المتحركة يشتمل على أن محرك الألعاب مفقود. أضفيه و اشرح ما يحميه من.

قم بتصميم قائمة تفحص للتحديات والرد على إجراء معين (مثل "التسجيل إلى حساب تويتر عام"). ما هي الأسئلة الثلاثة التي يجب على المراجع الإجابة عليها؟ لماذا هذه الثلاثة؟

اختر حالة واحدة حيث سيكون استدعاء "موافق؟" متزامن كافيا (لا حاجة إلى متجر دائم). شرح السبب، ونسم فئة المخاطر التي تقبل.

الشروط الرئيسية

Term	What people say	What it actually means
Propose-then-commit	"Two-phase approval"	Persisted proposal + positive commit + verify
Idempotency key	"Retry-safe token"	Unique per proposal; second execution no-ops
Data lineage	"Where it came from"	The specific source content that led to the proposal
Blast radius	"Worst case"	Scope of effect if the action goes wrong
Rubber-stamp	"Fast approval"	"Approve" clicked without genuine review
Challenge-and-response	"Forcing checklist"	Reviewer must positively acknowledge specific questions
RequestInfoEvent	"MS Agent Framework primitive"	Durable HITL request with structured metadata
`interrupt()` / `waitForApproval()`	"Framework primitives"	LangGraph / Cloudflare equivalents of the same shape