تنسيق الأنظمة المتعددة مع قرارات حكمية

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

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

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

كيف تحل Triggerfish هذا

يُنفذ محرك سير عمل Triggerfish تعريفات سير عمل مبنية على YAML تمزج الأتمتة الحتمية مع استدلال AI في خط أنابيب واحد. تمر كل خطوة في سير العمل عبر نفس طبقة تطبيق الأمان التي تحكم جميع عمليات Triggerfish، لذا يظل تتبع التصنيف ومسارات التدقيق قائمَين عبر السلسلة بأكملها بصرف النظر عن عدد الأنظمة المعنية.

خطوات حتمية للعمل الحتمي

عندما تكون لخطوة سير العمل مدخل معروف ومخرج معروف، فإنها تُنفَّذ كاستدعاء HTTP قياسي، أو أمر shell، أو استدعاء أداة MCP. لا تدخل LLM، ولا تأخر في الكمون، ولا تكلفة استنتاج. يدعم محرك سير العمل call: http لـ REST APIs، وcall: triggerfish:mcp لأي خادم MCP متصل، وrun: shell لأدوات سطر الأوامر. تُنفَّذ هذه الخطوات تماماً كالأتمتة التقليدية، لأن الأتمتة التقليدية هي النهج الصحيح للعمل القابل للتنبؤ.

وكلاء LLM الفرعيون لقرارات الحكم

عندما تتطلب خطوة سير عمل استدلالاً سياقياً، يُنشئ المحرك جلسة وكيل فرعي LLM حقيقية باستخدام call: triggerfish:llm. هذا ليس تبادل prompt/استجابة واحداً. الوكيل الفرعي لديه وصول إلى كل أداة مسجلة في Triggerfish، بما في ذلك البحث على الويب والذاكرة وأتمتة المتصفح وجميع التكاملات المتصلة. يمكنه قراءة المستندات والاستعلام عن قواعد البيانات ومقارنة السجلات واتخاذ قرار استناداً إلى كل ما يجده.

يُغذي مخرج الوكيل الفرعي مباشرة في الخطوة التالية من سير العمل. إذا وصل إلى بيانات مُصنفة أثناء استدلاله، يتصاعد taint الجلسة تلقائياً وينتشر إلى سير العمل الأصلي. يتتبع محرك سير العمل هذا، لذا يُخزَّن سير العمل الذي بدأ بمستوى PUBLIC ولكنه وصل إلى بيانات CONFIDENTIAL أثناء قرار حكمي بمستوى CONFIDENTIAL بأكمله. جلسة ذات تصنيف أدنى لا تستطيع حتى معرفة أن سير العمل قد جرى.

تفريع شرطي مبني على سياق حقيقي

يدعم DSL لسير العمل كتل switch للتوجيه الشرطي، وحلقات for للمعالجة الدفعية، وعمليات set لتحديث حالة سير العمل. مقترناً بخطوات وكيل LLM الفرعي القادرة على تقييم شروط معقدة، يعني هذا أن سير العمل يستطيع التفرع استناداً إلى السياق التجاري الفعلي لا مجرد قيم الحقول.

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

الإصلاح الذاتي عند تغيير الأنظمة

عندما تفشل خطوة حتمية لأن API غيّر تنسيق استجابته أو أعاد نظام خطأً غير متوقع، لا يتوقف سير العمل فحسب. يستطيع المحرك تفويض الخطوة الفاشلة إلى وكيل LLM فرعي يقرأ الخطأ ويفحص الاستجابة ويحاول نهجاً بديلاً. API أضاف حقلاً مطلوباً جديداً يعالجه الوكيل الفرعي بقراءة رسالة الخطأ وتعديل الطلب. نظام غيّر تدفق المصادقة يتعامل معه الوكيل الفرعي بأدوات أتمتة المتصفح.

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

الأمان عبر السلسلة بأكملها

كل خطوة في سير عمل Triggerfish تمر عبر نفس hooks تطبيق السياسات كأي استدعاء أداة مباشر. يتحقق PRE_TOOL_CALL من الصلاحيات وفحص حدود المعدل قبل التنفيذ. يُصنف POST_TOOL_RESPONSE البيانات المعادة ويحدّث taint الجلسة. يضمن PRE_OUTPUT عدم مغادرة أي شيء للنظام بمستوى تصنيف أعلى مما يسمح به الهدف.

يعني هذا أن سير عمل يقرأ من نظام CRM لديك (CONFIDENTIAL)، ويعالج البيانات عبر LLM، ويرسل ملخصاً إلى Slack، لا يسرّب تفاصيل سرية عرضاً في قناة عامة. تلتقط قاعدة منع الكتابة التنازلية ذلك في hook PRE_OUTPUT، بصرف النظر عن عدد الخطوات الوسيطة التي مرت بها البيانات. يسير التصنيف مع البيانات عبر سير العمل كاملاً.

يستطيع تعريف سير العمل نفسه تحديد classification_ceiling يمنع سير العمل من الوصول إلى بيانات فوق المستوى المحدد. سير عمل الملخص الأسبوعي المصنف بمستوى INTERNAL لا يمكنه الوصول إلى بيانات CONFIDENTIAL حتى لو كانت لديه بيانات الاعتماد للقيام بذلك. السقف مطبَّق في الكود، ليس بالأمل في أن يحترم LLM تعليمات prompt.

إطلاق Cron والـ Webhook

لا تتطلب سير العمل من أحد تشغيلها يدوياً. يدعم المُجدوِل إطلاق cron لسير العمل المتكرر وإطلاق webhook للتنفيذ المدفوع بالأحداث. يعمل سير عمل الإحاطة الصباحية في الساعة 7 صباحاً. يُطلق سير عمل مراجعة PR عند إرسال GitHub لـ webhook. يُطلق سير عمل معالجة الفواتير عند ظهور ملف جديد في محرك مشترك.

تحمل أحداث Webhook مستوى تصنيفها الخاص. يُصنف webhook من GitHub لمستودع خاص تلقائياً بمستوى CONFIDENTIAL استناداً إلى تعيينات تصنيف النطاق في إعدادات الأمان. يرث سير العمل ذلك التصنيف وتسري عليه جميع إجراءات التطبيق المنبثقة عنه.

كيف يبدو هذا عملياً

تعمل شركة متوسطة الحجم على الشراء حتى الدفع عبر NetSuite وCoupa وDocuSign وSlack، وتعرّف سير عمل Triggerfish يعالج الدورة الكاملة. تتولى الخطوات الحتمية استدعاءات API لإنشاء أوامر الشراء وتوجيه الموافقات ومطابقة الفواتير. تتولى خطوات وكيل LLM الفرعي الاستثناءات: الفواتير ذات البنود التي لا تطابق أمر الشراء، والبائعون الذين قدموا وثائق بتنسيق غير متوقع، وطلبات الموافقة التي تحتاج سياقاً حول تاريخ مقدم الطلب.

يعمل سير العمل على نسخة Triggerfish مستضافة ذاتياً. لا تغادر البيانات البنية التحتية للشركة. يضمن نظام التصنيف بقاء البيانات المالية من NetSuite بمستوى CONFIDENTIAL وعدم إرسالها إلى قناة Slack مصنفة بمستوى INTERNAL. يلتقط مسار التدقيق كل قرار اتخذه وكيل LLM الفرعي، وكل أداة استدعاها، وكل بيانات وصل إليها، مُخزَّنة مع تتبع كامل للنسب لمراجعة الامتثال.

عندما يحدّث Coupa API خاصته ويغيّر اسم حقل، تفشل خطوة HTTP الحتمية في سير العمل. يفوّض المحرك إلى وكيل فرعي يقرأ الخطأ ويحدد الحقل المتغير ويعيد المحاولة بالمعامل الصحيح. يكتمل سير العمل دون تدخل بشري، ويُسجَّل الحادث ليتمكن مهندس من تحديث تعريف سير العمل للتعامل مع التنسيق الجديد مستقبلاً.