اگر امروز یک عامل هوش مصنوعی را در محیط تولید (Production) رها کنید، احتمالاً با بحرانی امنیتی یا خطاهای خاموش روبرو خواهید شد. تفاوت میان یک دموی خیره‌کننده و یک سیستم سازمانی قابل‌اعتماد، نه در هوش مدل، بلکه در چارچوبی است که مدل را در بر گرفته است. موش سامبول (Moshe Sambol)، نایب‌رئیس راهکارهای مشتری در شرکت لایتران (Lightrun)، استدلال می‌کند که شکاف میان یک نمایش موفق و یک سیستم سازمانی مورد اعتماد، توسط چارچوب پیرامون مدل تعریف می‌شود، نه توسط هوش ذاتی خود مدل.
سامبول بیش از دو دهه تجربه در مهندسی نرم‌افزار، معماری و زیرساخت‌های ابری را به این چالش می‌آورد. او پیش از پیوستن به لایتران در سال ۲۰۲۲، نزدیک به یک دهه را در گوگل در جایگاه‌های مدیریتی گذراند، از جمله به عنوان مدیر مهندسی مشتریان ابری (Cloud Customer Engineering Manager)، جایی که به سازمان‌ها در پذیرش و مقیاس‌بندی فناوری‌های گوگل کلاود کمک کرد. سوابق شغلی او همچنین شامل نقش‌های رهبری مهندسی و توسعه در اوراکل (Oracle)، سان مایکروسیستمز (Sun Microsystems)، بی‌ام‌سی سافت‌ور (BMC Software) و جی‌پی مورگان چیس (JPMorgan Chase) است. او در لایتران ابتدا رهبری مهندسی راهکارهای جهانی را بر عهده داشت و سپس به مقام نایب‌رئیس راهکارهای مشتری ارتقا یافت، جایی که اکنون بر کمک به مشتریان برای تبدیل فناوری «بینش‌های زمان اجرا» (Runtime Insights) به دستاوردهای قابل اندازه‌گیری در کسب‌وکار و بهره‌وری توسعه‌دهندگان تمرکز دارد.
بسیاری از سازمان‌ها با عامل‌های هوش مصنوعی مانند کارمندان جدید رفتار می‌کنند و آن‌ها را بر اساس خروجی، قضاوت و توانمندی‌هایشان ارزیابی می‌کنند. با این حال، در صنایع تحت نظارت و رگولاتوری، عاملی که «معمولاً» درست عمل می‌کند، در واقع یک ریسک و بدهی (Liability) است. محیط‌های تولید حاوی مالکیت‌های معنوی حساس، کدهای منبع و الزامات امنیتی سخت‌گیرانه‌ای هستند که استدلال‌های احتمالی (Probabilistic Reasoning) به تنهایی نمی‌توانند آن‌ها را برآورده کنند. هر هفته نمونه‌های جدیدی از سیستم‌های هوش مصنوعی می‌بینیم که در تلاش برای رسیدن به یک هدف، در نهایت باعث ایجاد اکسپلویت‌های امنیتی می‌شوند یا خود در برابر آن‌ها آسیب‌پذیر می‌گردند.
سامبول معتقد است که سؤال واقعی برای مدیران این نیست که «آیا عامل به اندازه کافی باهوش است؟»، بلکه این است که «آیا سیستم پیرامون آن می‌تواند لحظاتی را که عامل باهوش نیست، شناسایی و مهار کند؟». این امر مستلزم تغییر دیدگاه از نگاه به عامل‌ها به عنوان ابزارهای مستقل، به نگاه به آن‌ها به عنوان بخشی از یک سیستم آماده برای تولید است؛ سیستمی که باید دسترسی‌های محدود (Least-privilege) را اعمال کند، فعالیت‌ها را نظارت نماید، یک ردپای حسابرسی (Audit Trail) را حفظ کند، از اقدامات با ریسک غیرقابل قبول جلوگیری کند و در زمان لازم، یک انسان را وارد مدار کند.
با تکیه بر تغییر رویکرد صنعت به سمت گردش‌کارهای عاملی (Agentic Workflows)، چالش فعلی انتقال از تحلیل ایستا (Static Analysis) به تأیید پویا (Dynamic Verification) است. این رویکرد در عمل می‌تواند منجر به تحولات چشمگیری در بهره‌وری شود، مشابه آنچه در کاهش زمان برنامه‌ریزی فنی از ۲ روز به ۳۰ دقیقه با گردش‌کار عامل‌محور مشاهده شد. در حالی که بسیاری از تیم‌ها بر این باورند که اتصال یک مدل زبانی بزرگ (LLM) به مستندات، تیکت‌ها و تله‌متری کافی است، آن‌ها اغلب نیاز حیاتی به یک مدل اعتبارسنجی برای هر گام از استدلال هوش مصنوعی را نادیده می‌گیرند.
شکست استدلال احتمالی
سامبول اشاره می‌کند که بزرگ‌ترین نقطه قوت هوش مصنوعی، یعنی استدلال احتمالی، در سیستم‌های پیچیده به بزرگ‌ترین ریسک تبدیل می‌شود. چون توسعه‌دهندگان دقیقاً تجویز نمی‌کنند که یک سیستم عاملی چگونه کار کند — بلکه هدفی را تعیین کرده و ابزارهایی را فراهم می‌کنند و مدل مسیر را تعیین می‌کند — رفتار سیستم سخت‌تر پیش‌بینی می‌شود. این انعطاف‌پذیری قدرتمند است، اما یک پیش‌بینی‌ناپذیری بنیادی را معرفی می‌کند که با استانداردهای سخت‌گیرانه سازمانی ناسازگار است.
در محیط‌های تولید پیچیده و متصل به هم، یک حدس احتمالی واحد می‌تواند باعث رگرسیون‌های پایین‌دستی، شکست‌های خاموش یا سایر رفتارهای غیرمنتظره شود که تاب‌آوری عملیاتی را تهدید می‌کند. برای سازمان‌ها، به‌ویژه در صنایع تحت نظارت، گردش‌کارهای تولیدی که «معمولاً» کار می‌کنند یا زمان نامشخصی برای تکمیل نیاز دارند، کاملاً غیرقابل قبول هستند.
برای مقابله با این موضوع، سازمان‌ها باید «هدایت قطعی» (Deterministic Steering) را پیاده کنند. این بدان معناست که در حالی که استدلال داخلی عامل احتمالی باقی می‌ماند، اما نقاط کنترلی (Checkpoints) که اقدامات او را مدیریت می‌کنند باید مطلق باشند. یک عامل باید پیش از اجرا، فرضیه اقدام بعدی خود را در برابر واقعیت محیط تولید بسنجد — یک گیت قطعی به جای یک حدس احتمالی دیگر. عامل باید ببیند نتیجه آن تصمیم چه خواهد بود و تنها زمانی آن را تأیید کند که تعیین کرده باشد اقدام مذکور ایمن است.
اشتباهات معماری در نسل اول عامل‌ها
بسیاری از عامل‌های نسل اول مانند جعبه‌های سیاه عمل می‌کنند. آن‌ها داده‌ها را از منابع مختلف جمع‌آوری کرده و تصمیماتی می‌گیرند که در اصل منطقی به نظر می‌رسند اما واقعیت «کثیف» و آشفته سیستم‌های زنده را نادیده می‌گیرند. سامبول مشاهده می‌کند که بسیاری از تیم‌ها این باور ساده‌لوحانه را داشتند که یک پرامپت خوب، زمینه (Context) مرتبط و ابزارهای مناسب می‌تواند هر چالشی را حل کند و انتظار داشتند LLM صرفاً از طریق استدلال به تصمیم درست برسد.
سامبول چندین شکاف معماری اصلی را شناسایی می‌کند:
- فقدان حلقه‌های بازخورد: عامل‌ها اغلب به کد منبع ایستا یا تله‌متری قدیمی تکیه می‌کنند. فراهم کردن مشاهده‌پذیری لحظه‌ای در زمان اجرا (Live Runtime Observability)، زمینه عامل را بر آنچه «همین حالا» در حال رخ دادن است متمرکز می‌کند و به او اجازه می‌دهد تحلیل علت ریشه‌ای (Root Cause Analysis) و توصیه‌های کاهش خطا را در برابر واقعیت بسنجد، نه در برابر فرضیات.
- نبود گیت‌های اعتبارسنجی: اقدامات اغلب بدون یک بررسی قطعی انجام می‌شوند. تیم‌ها نیاز دارند جریان عاملی را به‌گونه‌ای بازسازی کنند که استفاده از ابزارها مشمول نظارت، حسابرسی و بازبینی باشد.
- اتکای بیش از حد به پرامپت‌ها: تیم‌ها به اشتباه فکر می‌کنند مهندسی پرامپت می‌تواند جایگزین مهندسی دقیق نرم‌افزار شود. سامبول یک راهکار تدریجی پیشنهاد می‌کند: سرمایه‌گذاری روی «مهارت‌ها» (Skills) که رفتار را هدایت می‌کنند. مهارت‌هایی که با دقت طراحی و ارزیابی شده‌اند، عامل را به سمت یک گردش‌کار قطعی سوق می‌دهند و باید با همان سخت‌گیریِ هر قطعه دیگر از منطق تولید (Production Logic) با آن‌ها برخورد شود.
شکاف میان تست و تولید
عامل‌ها اغلب در تست‌های کنترل‌شده عملکرد خوبی دارند اما وقتی در معرض کاربران واقعی قرار می‌گیرند، شکست می‌خورند. این اتفاق به این دلیل می‌افتد که تست‌های کنترل‌شده، تغییرپذیری محیط تولید را حذف می‌کنند: داده‌ها گلچین شده‌اند، رفتار ابزارها پیش‌بینی‌پذیر است، مجوزها شناخته شده‌اند و تیم تنها مسیرهایی را پوشش می‌دهد که پیش‌بینی کرده است.
در دنیای واقعی، محیط به‌طور بنیادی متفاوت است:
- تغییرپذیری کاربر: کاربران درخواست‌های مبهم ارسال می‌کنند و اقدامات هم‌زمان (Concurrent) را اجرا می‌کنند.
- نوسان سیستم: وضعیت سیستم در تغییر مداوم است و عامل اغلب مجبور است با داده‌های ناقص کار کند.
- ناپایداری ابزارها: ابزارهای خارجی تأخیرهای خاص خود و حالت‌های شکست (Failure Modes) متفاوتی را به همراه می‌آورند.
از آنجایی که مدل احتمالی است، هر متغیر جدید نقطه‌ای را ایجاد می‌کند که در آن گردش‌کار می‌تواند منحرف شود یا یک اشتباه قبلی را تشدید کند. خطرناک‌ترین جنبه این است که یک عامل می‌تواند به نظر برسد که به درستی کار می‌کند، در حالی که پاسخ‌هایی پذیرفتنی اما نادرست را بر اساس داده‌های ناقص یا قدیمی تولید می‌کند. این امر مستلزم ارزیابی مداوم پس از عرضه، مدیریت صریح داده‌های مفقود و شکست ابزارها، و تأیید زنده یک تصمیم پیش از تکمیل یک اقدام با تأثیر بالا است.
نقش زمینه لحظه‌ای (Runtime Context)
مشاهده‌پذیری متداول — شامل لاگ‌ها، متریک‌ها و تریس‌ها — ایستا است. این ابزارها فقط آنچه را ثبت می‌کنند که توسعه‌دهندگان در زمان نوشتن کد، فکر می‌کردند باید ابزارگذاری (Instrument) کنند. این داده‌ها اغلب تجمیع شده، نمونه‌برداری شده یا از طریق داشبوردهایی که بر اساس آستانه‌ها (Thresholds) فعال می‌شوند، فیلتر شده‌اند و در واقع یک گزارش تاریخی از اتفاقات گذشته هستند. این رویکرد به توانایی توسعه‌دهنده در پیش‌بینی اطلاعاتی که در آینده مورد نیاز خواهد بود، وابسته است.
لایتران (Lightrun) یک پلتفرم قابلیت اطمینان مهندسی بومی هوش مصنوعی است که طراحی شده تا به توسعه‌دهندگان و عامل‌های هوش مصنوعی، دید مستقیم به رفتار نرم‌افزار در حین اجرا بدهد. این پلتفرم شکاف ایستایی را با فراهم کردن زمینه پویا در زمان اجرا برطرف می‌کند. این امر به یک عامل اجازه می‌دهد تا بدون نیاز به تغییر کد یا استقرار مجدد، لاگ‌ها، اسنپ‌شات‌ها، متریک‌ها، تریس‌ها، مقادیر متغیرها و زمینه اجرا را به‌طور پویا از برنامه‌های زنده استخراج کند.
این قابلیت به عامل اجازه می‌دهد تا بر حسب نیاز، ابزارگذاری‌های جدیدی را در کد در حال اجرا قرار دهد. عامل می‌تواند مقادیر دقیق متغیرها، آرگومان‌های توابع، وضعیت اشیاء، پشته‌های فراخوانی (Call Stacks) یا شرایط شاخه‌ای (Branch Conditions) را در لحظه وقوع مشاهده کند. این کار، قابلیت مشاهده را از نیاز به دانستن پیش‌اپیشِ آنچه ممکن است جالب باشد، جدا می‌کند.
این موضوع برای تشخیص «شکست‌های خاموش» ضروری است. یک عامل ممکن است ابزار اشتباهی را انتخاب کند، آرگومان غلطی را پاس دهد یا بر اساس یک فرض قدیمی عمل کند و همچنان وظیفه خود را بدون ایجاد یک خطای استاندارد به پایان برساند. چنین شکست‌هایی در تله‌متری ایستا ظاهر نمی‌شوند زیرا هیچ‌کس نمی‌دانست که باید از قبل برای آن‌ها ابزارگذاری کند. تنها بررسی پویا می‌تواند نشان دهد که مدل ذهنی عامل کجا از واقعیت فاصله گرفته است و ابزارگذاری جدید را دقیقاً در جایی که انحراف رخ داده، قرار دهد.
استقرار امن از طریق MCP
برای جلوگیری از دسترسی بیش از حد عامل‌ها به محیط تولید، لایتران از پروتکل زمینه مدل (Model Context Protocol یا MCP) استفاده می‌کند. این لایه یکپارچه‌ساز اجازه می‌دهد دستیاران کدنویسی و ابزارهای عاملی به جای تکیه صرف بر کد منبع ایستا، از زمینه زنده برنامه استفاده کنند. این امر سیستم‌های هوش مصنوعی را قادر می‌سازد تا مسائل تولید را بررسی کرده و فرضیات را در برابر رفتار واقعی اجرا تأیید کنند، در حالی که کنترل‌های سازمانی حفظ می‌شوند.
از طریق یک سرور MCP، یک عامل می‌تواند یک قابلیت خاص و محدود (Scoped) را فراخوانی کند، به جای اینکه دسترسی گسترده به سیستم به او داده شود. یک عامل می‌تواند شواهد «فقط خواندنی» — مانند مقدار یک متغیر، یک مسیر فراخوانی، یا اینکه آیا یک آستانه رد شده است یا خیر — را درخواست کند، بدون اینکه دسترسی نوشتن، توانایی استقرار مجدد کد یا نیاز به اعتبارنامه‌های دائمی به محیط زیربنایی داشته باشد. این تضمین می‌کند که عامل می‌تواند شواهد را جمع‌آوری کند بدون اینکه ریسک تغییر در سیستم وجود داشته باشد.
معماری منسجم برای تولید
سامبول استدلال می‌کند که مجوزها، حافظه و نظارت را نمی‌توان به عنوان ویژگی‌های جداگانه به سیستم «پیچاند» (Bolt-on)، زیرا هر یک از آن‌ها روی دیگری تأثیر می‌گذارد. آن‌ها باید بخشی از یک معماری واحد و منسجم باشند:
۱. هارنس (The Harness): چارچوبی که حلقه عامل را کنترل کرده و گردش‌کار بین چندین عامل و سایر بازیگران را سازماندهی می‌کند.
۲. قرارداد (The Contract): تعریف واضحی از اینکه چه شواهدی مورد نیاز است، عامل مجاز به بازرسی کدام سیستم‌ها است، آیا می‌تواند نتایج را منتشر کند یا فقط پیش‌نویس بنویسد، چه زمانی یک انسان باید گام بعدی را تأیید کند و اگر شواهد زمان اجرا در دسترس نباشد چه اتفاقی می‌افتد.
۳. درگاه (The Gateway): بهره‌گیری از گیت‌وی‌های MCP برای محدود کردن دسترسی عامل به قابلیت‌های خاص مرتبط با هدفش، تا تضمین شود ابزارها با کمترین سطح دسترسی اعطا می‌شوند.
۴. ردپای حسابرسی (The Audit Trail): یک رکورد مشترک که محرک، مجوزها، شواهد، فراخوانی‌های ابزار، تأییدات، اقدام و نتیجه را به هم متصل می‌کند.
در این معماری، حافظه باید با حذف قطعی داده‌های حساس (PII Redaction) تحت نظارت باشد و بازیابی (Retrieval) باید بر اساس شواهد خاصی که گردش‌کار نیاز دارد طراحی شود. سیستم باید اندازه‌گیری کند که آیا نتایج درست و مورد حمایت هستند یا خیر، زمانی که ریسک یا عدم قطعیت از یک آستانه تعریف شده فراتر رفت، یک انسان را وارد کند و در صورت ناکافی بودن شواهد، به توصیه‌های «فقط خواندنی» بازگردد.
حفاظ‌های SRE هوش مصنوعی در محیط‌های حساس
هنگام ساخت Lightrun AI SRE، تیم سیستم را به عنوان یک بازیگر عملیاتی دارای امتیاز (Privileged Operational Actor) طراحی کرد، نه یک دستیار چت. یک تصمیم طراحی مرکزی، جداسازی سخت‌گیرانه «صفحه بازرسی» (Inspection Plane) از «صفحه اقدام» (Action Plane) بود.
AI SRE شواهد را از طریق یکپارچگی‌های فقط خواندنی و ابزارگذاری‌های زمان اجرای سندباکس شده جمع‌آوری می‌کند. دسترسی‌ها بر اساس هویت، مستاجر (Tenant)، سرویس و محیط محدود شده‌اند. در حالی که این سیستم می‌تواند شواهد مفقود را تولید کرده و اجرای زنده را بازرسی کند، لایه بازرسی زمان اجرا از تغییر وضعیت برنامه منع شده است.
در محیط‌های تحت نظارت، این مرز توسط موارد زیر پشتیبانی می‌شود:
- کنترل‌های دسترسی: RBAC، SSO و جداسازی مستاجران.
- حریم خصوصی: حذف داده‌های حساس (PII) و کنترل‌های سخت‌گیرانه نگهداری داده‌ها.
- محدودیت‌های عملیاتی: محدودیت در مقدار داده‌های قابل جمع‌آوری و دفعات پرس‌وجو از زمان اجرا.
- قابلیت حسابرسی: یک ردپای کامل که نشان می‌دهد کدام ابزارها و شواهد از هر نتیجه پشتیبانی کرده‌اند.
اگر نتیجه‌ای قابل تأیید نباشد یا شواهدی مفقود شود، AI SRE به‌گونه‌ای طراحی شده است که این شکاف را بپذیرد و تصمیم را به انسان بسپارد، به جای اینکه طوری رفتار کند که انگار بیش از آنچه می‌داند، می‌داند. هدف، «خودمختاری کنترل‌شده» است: به اندازه کافی مفید برای تسریع در بررسی، اما به اندازه کافی محدود برای ایمن ماندن در سیستم زنده.
آینده رابطه مهندس و هوش مصنوعی
همان‌طور که عامل‌ها از مرحله آزمایشات فراتر می‌روند، آمادگی برای تولید باید با معیارهای خاصی سنجیده شود: دقت نتایج تأیید شده، پوشش شواهد، زمان تأیید علت ریشه‌ای، نرخ بازگشت موفق به حالت انسانی و نتایج پس از اقدام. آمادگی بر اساس این تعریف می‌شود که نتایج هر چند وقت یک‌بار در برابر حقیقت تولید (Production Truth) پایداری می‌کنند و آیا عامل در صورت نبود شواهد، به‌طور مرئی و ایمن شکست می‌خورد یا خیر.
در سال‌های آینده، احتمالاً عامل‌ها بخش عمده جمع‌آوری شواهد، بررسی‌های اولیه و نظارت بر گردش‌کارهای عاملی را بر عهده خواهند گرفت. آن‌ها در حال یادگیری مداوم از تجربه و بازخوردها خواهند بود.
مهندسان انسان تمرکز خود را به تعیین سیاست‌ها، حل ابهامات، تأیید اقدامات پرریسک و هدایت سیستم‌های عاملی خود-بهبودبخش تغییر خواهند داد. اعتماد، گردش‌کار به گردش‌کار به دست خواهد آمد و تنها به عامل‌هایی اعطا می‌شود که بتوانند نتایج خود را به شواهد زنده و قابل تأیید بازگردانند و به‌وضوح فاش کنند که چه چیزهایی را نتوانستند تأیید کنند. آن‌هایی که نتوانند این کار را بکنند، صرف‌نظر از اینکه چقدر فصیح به نظر برسند، به وظایف محدود و کم‌ریسک محدود خواهند ماند.
گام بعدی شما
- اگر از عامل‌های هوش مصنوعی در محیط تولید استفاده می‌کنید، بررسی کنید که آیا هر اقدام حساس توسط یک گیت «قطعی» (غیر احتمالی) تأیید می‌شود یا خیر.
- برای کاهش ریسک، دسترسی‌های عامل‌ها را از طریق پروتکل‌هایی مانند MCP به حالت «فقط خواندنی» محدود کنید.
- یک ردپای حسابرسی (Audit Trail) ایجاد کنید که هر تصمیم مدل را به یک داده واقعی در محیط Runtime متصل کند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو