هماهنگی چندسیستمی با تصمیم‌های قضاوتی

یک گردش کار معمولی خرید تا پرداخت با دوازده سیستم در تماس است. درخواست خرید در یک پلتفرم شروع می‌شود، در پلتفرم دیگری به زنجیره تأیید هدایت می‌شود، در سومی جستجوی فروشنده را فعال می‌کند، در چهارمی سفارش خرید ایجاد می‌کند، در پنجمی فرآیند دریافت را آغاز می‌کند، در ششمی فاکتورها را تطبیق می‌دهد، در هفتمی پرداخت را زمان‌بندی می‌کند، و در هشتمی همه چیز را ثبت می‌کند. هر سیستم API خودش، جدول به‌روزرسانی خودش، مدل احراز هویت خودش، و حالت‌های خرابی خودش را دارد.

اتوماسیون سنتی این را با خطوط لوله سخت‌گیرانه مدیریت می‌کند. مرحله اول API A را فراخوانی می‌کند، پاسخ را تجزیه می‌کند، یک فیلد را به مرحله دوم منتقل می‌کند که API B را فراخوانی می‌کند. کار می‌کند تا زمانی که نکند. یک رکورد فروشنده با تنسیق کمی متفاوت از انتظار دارد. یک تأیید با کد وضعیتی که خط لوله برای آن طراحی نشده برمی‌گردد. یک فیلد مورد نیاز جدید در یک به‌روزرسانی API ظاهر می‌شود. یک مرحله خراب کل زنجیره را خراب می‌کند، و کسی نمی‌داند تا زمانی که یک فرآیند پایین‌دستی روزها بعد شکست بخورد.

مشکل عمیق‌تر شکنندگی فنی نیست. این است که فرآیندهای تجاری واقعی به قضاوت نیاز دارند. آیا این اختلاف فاکتور باید تشدید شود یا به‌طور خودکار حل شود؟ آیا الگوی تحویل دیرهنگام این فروشنده باید بررسی قرارداد را توجیه کند؟ آیا این درخواست تأیید آنقدر فوری است که مسیریابی استاندارد را نادیده بگیرد؟ این تصمیمات در حال حاضر در ذهن مردم زندگی می‌کنند، به این معنی که اتوماسیون تنها می‌تواند مسیر عادی را مدیریت کند.

چگونه Triggerfish این را حل می‌کند

موتور گردش کار Triggerfish تعریف‌های گردش کار مبتنی بر YAML را که اتوماسیون قطعی را با استدلال هوش مصنوعی در یک خط لوله ترکیب می‌کنند، اجرا می‌کند. هر مرحله در گردش کار از همان لایه اجرای امنیتی که همه عملیات Triggerfish را کنترل می‌کند عبور می‌کند، بنابراین ردیابی طبقه‌بندی و مسیرهای حسابرسی در سراسر زنجیره، صرف نظر از تعداد سیستم‌های درگیر، حفظ می‌شوند.

مراحل قطعی برای کار قطعی

وقتی یک مرحله از گردش کار ورودی شناخته‌شده و خروجی شناخته‌شده‌ای دارد، به عنوان فراخوانی HTTP استاندارد، دستور shell، یا فراخوانی ابزار MCP اجرا می‌شود. بدون دخالت LLM، بدون جریمه تأخیر، بدون هزینه استنتاج. موتور گردش کار از call: http برای REST APIها، از call: triggerfish:mcp برای هر سرور MCP متصل، و از run: shell برای ابزارهای خط فرمان پشتیبانی می‌کند. این مراحل دقیقاً مانند اتوماسیون سنتی اجرا می‌شوند، زیرا برای کارهای قابل پیش‌بینی، اتوماسیون سنتی رویکرد درستی است.

زیرعامل‌های LLM برای تصمیم‌های قضاوتی

وقتی یک مرحله از گردش کار به استدلال متنی نیاز دارد، موتور با استفاده از call: triggerfish:llm یک جلسه زیرعامل LLM واقعی ایجاد می‌کند. این یک تبادل prompt/پاسخ واحد نیست. زیرعامل به هر ابزار ثبت‌شده در Triggerfish دسترسی دارد، از جمله جستجوی وب، حافظه، اتوماسیون مرورگر، و همه یکپارچه‌سازی‌های متصل. می‌تواند اسناد را بخواند، پایگاه داده‌ها را جستجو کند، رکوردها را مقایسه کند، و بر اساس همه چیزی که پیدا می‌کند تصمیم بگیرد.

خروجی زیرعامل مستقیماً به مرحله بعدی گردش کار تغذیه می‌شود. اگر در طول استدلال به داده‌های طبقه‌بندی‌شده دسترسی داشته باشد، taint جلسه به‌طور خودکار تشدید می‌شود و به گردش کار والد برمی‌گردد. موتور گردش کار این را ردیابی می‌کند، بنابراین یک گردش کار که با سطح PUBLIC شروع کرد اما در طول یک تصمیم قضاوتی به داده‌های CONFIDENTIAL دست یافت، کل تاریخچه اجرای آن در سطح CONFIDENTIAL ذخیره می‌شود. یک جلسه با طبقه‌بندی پایین‌تر حتی نمی‌تواند بداند که گردش کار اجرا شده است.

انشعاب شرطی بر اساس زمینه واقعی

DSL گردش کار از بلوک‌های switch برای مسیریابی شرطی، حلقه‌های for برای پردازش دسته‌ای، و عملیات set برای به‌روزرسانی حالت گردش کار پشتیبانی می‌کند. ترکیب با مراحل زیرعامل LLM که می‌توانند شرایط پیچیده را ارزیابی کنند، به این معنی است که گردش کار می‌تواند بر اساس زمینه تجاری واقعی نه فقط مقادیر فیلد منشعب شود.

یک گردش کار تدارکات می‌تواند بر اساس ارزیابی زیرعامل از ریسک فروشنده، مسیریابی متفاوتی داشته باشد. یک گردش کار ورود می‌تواند مراحلی را که برای یک نقش خاص مرتبط نیستند، نادیده بگیرد. یک گردش کار پاسخ به حادثه می‌تواند بر اساس تحلیل علت اصلی زیرعامل، به تیم‌های مختلف تشدید کند. منطق انشعاب در تعریف گردش کار قرار دارد، اما ورودی‌های تصمیم از استدلال هوش مصنوعی می‌آیند.

خودترمیمی هنگام تغییر سیستم‌ها

وقتی یک مرحله قطعی به این دلیل که یک API تنسیق پاسخش را تغییر داده یا یک سیستم خطای غیرمنتظره‌ای برگردانده شکست می‌خورد، گردش کار فقط متوقف نمی‌شود. موتور می‌تواند مرحله شکست‌خورده را به یک زیرعامل LLM واگذار کند که خطا را می‌خواند، پاسخ را بررسی می‌کند، و رویکرد جایگزینی را امتحان می‌کند. یک API که یک فیلد مورد نیاز جدید اضافه کرده توسط زیرعامل که پیام خطا را می‌خواند و درخواست را تنظیم می‌کند مدیریت می‌شود. یک سیستم که جریان احراز هویتش را تغییر داده توسط ابزارهای اتوماسیون مرورگر هدایت می‌شود.

این به معنای آن نیست که هر شکستی به‌طور جادویی حل می‌شود. اما به این معنی است که گردش کار به‌جای شکست بی‌صدا، به‌آرامی تخریب می‌شود. زیرعامل یا راهی به جلو پیدا می‌کند یا توضیح روشنی از آنچه تغییر کرده و چرا دخالت دستی لازم است تولید می‌کند، به‌جای یک کد خطای مبهم که در یک فایل لاگ که کسی بررسی نمی‌کند دفن شده.

امنیت در سراسر زنجیره

هر مرحله در یک گردش کار Triggerfish از همان هوک‌های اجرای خط‌مشی مانند هر فراخوانی مستقیم ابزار عبور می‌کند. PRE_TOOL_CALL قبل از اجرا مجوزها را تأیید و محدودیت‌های نرخ را بررسی می‌کند. POST_TOOL_RESPONSE داده‌های بازگشتی را طبقه‌بندی و taint جلسه را به‌روز می‌کند. PRE_OUTPUT اطمینان می‌دهد که هیچ چیزی با سطح طبقه‌بندی بالاتر از آنچه هدف اجازه می‌دهد از سیستم خارج نشود.

این به این معنی است که یک گردش کار که از CRM شما (CONFIDENTIAL) می‌خواند، داده‌ها را از طریق LLM پردازش می‌کند، و یک خلاصه به Slack ارسال می‌کند، به‌طور تصادفی جزئیات محرمانه را به یک کانال عمومی درز نمی‌دهد. قانون جلوگیری از نوشتن به پایین آن را در هوک PRE_OUTPUT می‌گیرد، صرف‌نظر از اینکه داده‌ها از چند مرحله میانی گذشته‌اند. طبقه‌بندی در سراسر گردش کار با داده‌ها همراه می‌شود.

تعریف گردش کار خودش می‌تواند یک classification_ceiling تعیین کند که از دسترسی گردش کار به داده‌های بالاتر از سطح مشخص‌شده جلوگیری کند. یک گردش کار خلاصه هفتگی طبقه‌بندی‌شده در INTERNAL حتی اگر اعتبارنامه‌های لازم برای انجام آن را داشته باشد نمی‌تواند به داده‌های CONFIDENTIAL دسترسی داشته باشد. سقف در کد اجرا می‌شود، نه به این امید که LLM دستورالعمل یک prompt را رعایت کند.

محرک‌های Cron و Webhook

گردش‌های کاری نیازی به راه‌اندازی دستی ندارند. زمان‌بند از محرک‌های cron برای گردش‌های کاری تکراری و محرک‌های webhook برای اجرای رویداد محور پشتیبانی می‌کند. یک گردش کار گزارش صبحگاهی ساعت ۷ صبح اجرا می‌شود. یک گردش کار بررسی PR وقتی GitHub یک webhook ارسال می‌کند فعال می‌شود. یک گردش کار پردازش فاکتور وقتی یک فایل جدید در یک درایو مشترک ظاهر می‌شود فعال می‌شود.

رویدادهای Webhook سطح طبقه‌بندی خودشان را دارند. یک webhook GitHub برای یک مخزن خصوصی بر اساس نگاشت‌های طبقه‌بندی دامنه در پیکربندی امنیتی به‌طور خودکار در CONFIDENTIAL طبقه‌بندی می‌شود. گردش کار آن طبقه‌بندی را به ارث می‌برد و همه اجرای اجرایی پایین‌دستی اعمال می‌شود.

در عمل چگونه به نظر می‌رسد

یک شرکت متوسط که خرید تا پرداخت را در NetSuite، Coupa، DocuSign، و Slack اجرا می‌کند، یک گردش کار Triggerfish تعریف می‌کند که چرخه کامل را مدیریت می‌کند. مراحل قطعی فراخوانی‌های API را برای ایجاد سفارش‌های خرید، هدایت تأییدیه‌ها، و تطبیق فاکتورها مدیریت می‌کنند. مراحل زیرعامل LLM استثناها را مدیریت می‌کنند: فاکتورهایی با اقلام سطری که با سفارش خرید مطابقت ندارند، فروشندگانی که اسناد را با تنسیق غیرمنتظره ارسال کرده‌اند، درخواست‌های تأیید که به زمینه‌ای درباره تاریخ درخواست‌کننده نیاز دارند.

گردش کار در یک نمونه Triggerfish خود میزبان اجرا می‌شود. هیچ داده‌ای از زیرساخت شرکت خارج نمی‌شود. سیستم طبقه‌بندی تضمین می‌کند که داده‌های مالی از NetSuite در سطح CONFIDENTIAL باقی بماند و نتواند به یک کانال Slack طبقه‌بندی‌شده در سطح INTERNAL ارسال شود. مسیر حسابرسی هر تصمیمی را که زیرعامل LLM گرفت، هر ابزاری را که فراخوانی کرد، و هر داده‌ای را که به آن دسترسی داشت ثبت می‌کند، با ردیابی کامل نسب برای بررسی انطباق ذخیره‌شده.

وقتی Coupa API خود را به‌روز کند و نام یک فیلد را تغییر دهد، مرحله HTTP قطعی گردش کار شکست می‌خورد. موتور به یک زیرعامل واگذار می‌کند که خطا را می‌خواند، فیلد تغییریافته را شناسایی می‌کند، و با پارامتر درست مجدداً تلاش می‌کند. گردش کار بدون دخالت انسان کامل می‌شود، و حادثه ثبت می‌شود تا یک مهندس بتواند تعریف گردش کار را برای مدیریت تنسیق جدید در آینده به‌روز کند.