دفتر هماهنگ: جریان‌های کاری عامل‌های هوش مصنوعی

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

این راهنما برای تیم عملیات، محصول، ریسک و مهندسی است که از دمو به فرایند واقعی می‌روند. اصل مرکزی این است: مدل ابهام زبان و شواهد را مدیریت کند؛ اجزای قطعی، اختیار و commit را.

یک فرایند انتخاب کنید، نه مجموعه‌ای از پرامپت‌ها

از کاری شروع کنید که trigger، مالک پاسخ‌گو، وضعیت پایان و سامانه مرجع روشن دارد. «به تیم فروش کمک کن» فرایند نیست. «سرنخ ورودی سازمانی را ارزیابی کن، فیلدهای مجاز را غنی کن، پاسخ بساز، برای حساب regulated تأیید بگیر و نتیجه را ظرف دو ساعت در CRM ثبت کن» قابل آزمون است.

پیش از افزودن عامل، وضع موجود را نقشه‌برداری کنید:

• محرک و درخواست‌کننده؛
• ورودی لازم و منبع معتبر؛
• نقطه تصمیم و سیاست؛
• اقدام ابزاری و گیرنده خارجی؛
• مالک انسانی، handoff و SLA؛
• نوع استثنا و مسیر escalation؛
• وضعیت نهایی در سامانه مرجع؛
• خط مبنای زمان، خطا، دوباره‌کاری و هزینه.

فرایندی را که مالک یا سیاستش ناشناخته است خودکار نکنید. مدل ممکن است ابهام را خوش‌ظاهر کند و هم‌زمان تصمیم ناسازگار را چند برابر سازد.

گردش‌کار را ماشین حالت محدود مدل کنید

گردش‌کار قابل اتکا حالت‌های محدود و نام‌دار دارد: received، evidence_ready، proposal_ready، awaiting_approval، executing، verifying، completed، compensating و manual_review. هر انتقال بازیگر مجاز، شاهد لازم، timeout، سیاست retry و شِمای خروجی دارد.

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

این پایه عملی گردش‌کار ماندگار عامل است. مکالمه یک رابط است؛ رکورد workflow مرجع است. restart کارگر یا تغییر مدل نباید وضعیت را پاک کند.

پیشنهاد، مجوز، اجرا و راستی‌آزمایی را جدا کنید

خروجی یک مدل نباید مستقیم تولید را تغییر دهد. چهار مرحله مستقل بسازید:

1. پیشنهاد: مدل برنامه یا اقدام تایپ‌شده با ارجاع شاهد می‌دهد.
2. مجوز: سیاست قطعی، هویت، tenant، منبع، مبلغ، گیرنده و تأیید را بررسی می‌کند.
3. اجرا: ابزار باریک با اعتبارنامه محدود اقدام مصوب را انجام می‌دهد.
4. راستی‌آزمایی: سامانه نتیجه معتبر را می‌خواند و وضعیت مورد انتظار کسب‌وکار را تأیید می‌کند.

مثلاً عامل حساب‌های پرداختنی داده فاکتور را استخراج و match پیشنهاد می‌کند. سیاست، وضعیت vendor، tolerance سفارش، علامت تکراری و حد approver را می‌سنجد. سرویس پرداخت فقط دستور تأییدشده را اجرا می‌کند. سپس ledger و وضعیت بانک خوانده می‌شوند؛ پاسخ «success» ابزار شاهد نهایی نیست.

مشخصات ابزار MCP نسخه 2026-07-28 شِمای ورودی و خروجی را پشتیبانی می‌کند و برای عملیات حساس، تأیید و audit را توصیه می‌کند. چه MCP باشد چه نباشد، metadata رابط را توصیف می‌کند؛ سیاست برنامه اختیار را می‌دهد.

تأیید انسانی را در نقطه تغییر ریسک بگذارید

تأیید باید متناسب با پیامد باشد. کلیک اجباری برای هر جست‌وجوی بی‌خطر fatigue می‌سازد؛ تأیید کلی یکباره برای دنباله‌ای از اقدام‌های متغیر خارجی، کنترل واقعی را حذف می‌کند.

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

• اولین اجرای workflow یا نسخه ابزار تازه؛
• match هویت یا entity با اعتماد کم؛
• استثنای سیاست و شاهد متعارض؛
• پرداخت، قرارداد، حذف، privilege یا پیام عمومی؛
• مقدار بالاتر از سقف نقش؛
• مقصد، تأمین‌کننده یا گیرنده خارج از baseline تأییدشده.

صفحه تأیید باید اقدام دقیق، هدف، شاهد، پیامد و گزینه دیگر را نشان دهد. تأیید به هش درخواست بسته و منقضی شود. تغییر آرگومان تأیید را باطل می‌کند. راهنمای طراحی تأیید انسانی پیش‌نمایش، step-up authentication، واگذاری و شاهد حسابرسی را بازتر توضیح می‌دهد.

هر تغییر را برای تلاش دوباره امن کنید

گردش‌کار توزیع‌شده ممکن است بین «اقدام انجام شد» و «پاسخ به caller رسید» شکست بخورد. retry بدون idempotency پرداخت، تیکت، مرسوله یا ایمیل تکراری می‌سازد. استاندارد معنای HTTP در RFC 9110 idempotency متدهای HTTP را تعریف می‌کند، ولی idempotency کسب‌وکار باید در لایه بالاتر طراحی شود.

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

شکست‌ها را طبقه‌بندی کنید:

• موقت: backoff نمایی محدود با jitter؛
• ورودی یا سیاست: بدون اصلاح retry نشود؛
• احراز: refresh یا مجوز دوباره از مسیر کنترل‌شده؛
• commit مبهم: پیش از تکرار با کلید جست‌وجو شود؛
• خرابی دائمی مقصد: جبران یا ارجاع به مالک.

«تا موفقیت retry کن» نباید در پرامپت باشد. retry سیاست orchestrator با بودجه و حالت نهایی قابل مشاهده است.

پیش از اعطای اختیار، جبران را طراحی کنید

rollback پایگاه داده نمی‌تواند ایمیل خوانده‌شده، کالای ارسال‌شده یا سفارش معامله‌شده را برگرداند. برای هر اثر خارجی بنویسید برگشت‌پذیر، قابل جبران یا غیرقابل برگشت است.

جبران می‌تواند سفارش اجرا‌نشده را لغو، دعوت را revoke، سند حسابداری اصلاحی ثبت، نسخه تنظیمات را restore یا پرونده اپراتور متخصص ایجاد کند. این اقدام تازه، مجوز و failure mode جدا دارد. رخداد اصلی را نگه دارید؛ audit trail را طوری بازنویسی نکنید که انگار اتفاقی نیفتاده است.

دنباله ناقص را آزمون کنید: CRM به‌روزرسانی شد اما اعلان شکست خورد؛ سفارش خرید ایجاد شد ولی رزرو منقضی گردید؛ دو شاخه موازی commit شدند و سومی شکست خورد. مشخص کنید فرایند ادامه می‌دهد، جبران می‌شود یا دستی حل می‌گردد. runbook باید مالک و شاهد معتبر لازم برای بستن incident را نام ببرد.

زمینه، ابزار و حافظه را ورودی نامطمئن بدانید

گردش‌کار Agentic دستور کاربر، سند بازیابی‌شده، توضیح ابزار، نتیجه ابزار و حافظه را ترکیب می‌کند. هرکدام می‌توانند غلط یا خصمانه باشند. ده ریسک برتر برنامه‌های Agentic در OWASP برای ۲۰۲۶ ربایش هدف، سوءاستفاده ابزار، اختیار بیش‌ازحد، مسموم‌سازی حافظه، خرابی آبشاری و trace ناکافی را برجسته می‌کند.

دفاع باید معماری باشد:

• دستور از داده بازیابی‌شده جدا شود؛
• ابزار مجاز پیش از نمایش به مدل محدود گردد؛
• هر ورودی و خروجی ساختاریافته بررسی شود؛
• نتیجه ابزار نتواند سیاست را عوض کند؛
• فیلتر tenant و هدف پیش از retrieval اعمال شود؛
• شاهد کم‌اعتماد quarantine شود؛
• برای هر مرز اجرا credential جدا باشد؛
• fan-out، recursion، هزینه token و زمان سقف داشته باشد؛
• سند خصمانه و خروجی فریبنده ابزار شبیه‌سازی شود.

تعریف workflow هدف را تعیین می‌کند، نه سند بازیابی‌شده. PDF تأمین‌کننده نمی‌تواند افزودن حساب بانکی را مجاز کند؛ فقط می‌تواند داده‌ای برای مرحله راستی‌آزمایی مستقل فراهم کند.

مشاهده‌پذیری را حول نیت کسب‌وکار بسازید

لاگ زیرساخت نشان می‌دهد درخواست اجرا شد. مشاهده‌پذیری فرایند باید نشان دهد چرا، با اختیار چه کسی، بر اساس کدام شاهد و با چه نتیجه‌ای اجرا شده است. یک correlation ID را از درخواست، مدل، retrieval، سیاست، تأیید، ابزار، تراکنش مقصد، verification و compensation عبور دهید.

انتقال حالت، نسخه مدل و پرامپت، شناسه شاهد، نسخه ابزار و شِما، نسخه سیاست، principal، subject واگذارشده، artifact تأیید، کلید idempotency، آرگومان redactشده، latency، هزینه، علت retry و وضعیت نهایی ثبت شوند. فیلد حساس و retention بر اساس هدف کنترل شود.

dashboard باید حالت گیرکرده، صف تأیید، انتقال تکراری، رد سیاست، retry storm، حجم جبران، مقصد غیرمنتظره و شکست verification را آشکار کند. مشاهده‌پذیری عامل درباره طراحی trace و هشدار عملیاتی جزئیات بیشتری دارد.

rollback و مهار را کوچک و هدفمند بسازید

کنترل‌هایی ریزتر از «هوش مصنوعی را خاموش کن» لازم است. feature flag باید workflow، انتقال، ابزار، tenant، نسخه مدل یا سطح اتوماسیون را جداگانه متوقف کند. kill switch اثر تازه را ببندد، ولی شاهد و وضعیت قابل بازیابی را حفظ کند.

تعریف workflow نسخه‌دار و migration برای پرونده در جریان نگه دارید. rollback کد بدون فهم state ذخیره‌شده می‌تواند کار را رها یا اقدام را تکرار کند. پیش از انتشار، این موارد را تست کنید:

• worker تازه checkpoint قدیمی را بخواند؛
• worker قدیمی حالت تازه را امن رد کند؛
• policy یا schema downgrade شود؛
• یک connector ابطال گردد؛
• از آخرین checkpoint replay انجام شود؛
• بعد از rollback استقرار، compensation اجرا شود.

چک‌لیست آمادگی عملیاتی برای مالکیت، هشدار، runbook، بازبینی دسترسی، backup، rollback و ارتباط incident باید release gate باشد.

نتیجه کسب‌وکار و کیفیت کنترل را بسنجید

«تعداد اقدام عامل» معمولاً vanity metric است. workflow باید نتیجه کسب‌وکار را تغییر دهد. با baseline پیش از اتوماسیون مقایسه و بر اساس نسخه، سطح ریسک و نوع استثنا تفکیک کنید.

شاخص کسب‌وکار:

• زمان انتها‌به‌انتها و زمان صف؛
• تکمیل مستقیم پس از verification؛
• هزینه هر پرونده کامل؛
• خطا، دوباره‌کاری و بازشدن مجدد؛
• conversion، collection، fulfillment یا resolution؛
• زمان آزادشده کارکنان برای کار ارزشمندتر؛
• رضایت مشتری و ثبات پاسخ.

شاخص کنترل:

• اقدام غیرمجاز موفق که باید صفر بماند؛
• رد درست و غلط سیاست؛
• زمان تأیید، انصراف و override؛
• اثر جانبی تکراری پس از retry؛
• کشف ورودی poison و false positive؛
• سن حالت گیرکرده و زمان بازیابی؛
• تعداد و موفقیت compensation؛
• پوشش trace و provenance؛
• incident در هر هزار workflow کامل.

تکمیل خودکار، تکمیل با کمک انسان و کار ناموفق یا رهاشده را جدا گزارش کنید؛ دخالت انسان نباید نتیجه ضعیف را پنهان کند.

مالکیت و تغییر را حاکمیت کنید

هر workflow مالک کسب‌وکار، مالک فنی، مالک ریسک و مالک سامانه مرجع دارد. روشن کنید چه کسی پرامپت، ابزار، سیاست، threshold و مجموعه ارزیابی را عوض می‌کند. تغییر شِما یا permission ابزار یک تغییر production است، حتی اگر مدل ثابت بماند.

چارچوب مدیریت ریسک هوش مصنوعی NIST ساختار مفیدی دارد: govern برای پاسخ‌گویی، map برای فرایند و آسیب، measure برای عملکرد و ریسک و manage برای اصلاح و ریسک باقی‌مانده. برنامه استانداردهای عامل هوش مصنوعی NIST بر interoperability امن، هویت عامل و evaluation تأکید جاری می‌افزاید. هیچ‌یک گواهی محصول نیستند؛ برای طرح پرسش درست در چرخه عمر مفیدند.

پیش از promotion ارزیابی الزامی باشد: پرونده تاریخی، edge case، حمله و shadow traffic زنده. تغییر فقط وقتی جلو برود که آستانه کسب‌وکار را بگذراند و مجوز، traceability، latency یا recovery را ضعیف نکند. دسترسی و state نگهداری‌شده دوره‌ای بازبینی شوند.

از حالت کمکی به اتوماسیون محدود بروید

در shadow mode آغاز کنید: فرایند پیشنهاد می‌دهد، اما اجرا نمی‌کند. پیشنهاد را با تصمیم واقعی اپراتور مقایسه و اختلاف را ثبت کنید. سپس ساخت draft و تغییر داخلی برگشت‌پذیر را مجاز کنید. برای اثر خارجی یا پرریسک تأیید صریح اضافه کنید. اجرای مستقیم فقط برای حالت باریک، پایدار و دارای verification قوی مناسب است.

از نسخه اول مسیر استثنا داشته باشید. پرونده حل‌نشده باید با شواهد جمع‌شده، state فعلی، تلاش‌های انجام‌شده و علت روشن escalation به انسان برسد، نه پیام مبهم «عامل شکست خورد». اپراتور باید اصلاح کند و درس ساختاریافته وارد ارزیابی شود.

گردش‌کار خوب کمتر شبیه «کارمند خودمختار» و بیشتر شبیه عملیات منظم است: مسئولیت دیده می‌شود، کار از وقفه جان سالم می‌برد، اختیار محدود است، شکست مالک دارد و بهبود قابل اندازه‌گیری است.

یادداشت منابع

بازبینی محتوایی در ۲۰۲۶-۰۷-۳۰ انجام شد. معماری از راهنمای جاری رابط ابزار MCP، معنای HTTP در IETF برای idempotency انتقال، برنامه‌های جاری NIST برای ریسک و استاندارد عامل و چارچوب تهدید Agentic در OWASP استفاده می‌کند. تأیید، جبران و KPI راهنمای عملیاتی‌اند و باید با قانون، قرارداد و کنترل حوزه تطبیق داده شوند.

• مشخصات ابزار MCP، نسخه ۲۰۲۶-۰۷-۲۸
• RFC 9110، معنای HTTP
• چارچوب مدیریت ریسک هوش مصنوعی NIST
• برنامه استانداردهای عامل هوش مصنوعی NIST
• ده ریسک برتر برنامه‌های Agentic در OWASP برای ۲۰۲۶