تصور کنید ساعت ۲ صبح است و یک هشدار بحرانی شما را از خواب می‌پراند؛ اما به جای اینکه با چشم‌های خواب‌آلود ساعت‌ها گزارش‌ها را بکاوید، یک گزارش کامل از علت خرابی روی میز شماست. این دقیقا همان کاری است که Poirot انجام می‌دهد؛ یک کارآگاه خودکار که سخت‌ترین و طاقت‌فرسای‌ترین سی دقیقه اول از پاسخ به حوادث (Incident Response) را بر عهده می‌گیرد. به جای اینکه یک مهندس خسته در ساعات ابتدایی صبح به دنبال امضاهای خطا (Error Signatures) بگردد، این عامل هوشمند جهش‌ها را بررسی کرده و یک گزارش مستند از علت ریشه‌ای را مستقیماً به اینباکس کاربر ارسال می‌کند.
پاسخ به حوادث معمولاً یک روتین تکراری است: استخراج لاگ‌ها، شناسایی آخرین استقرار (Deployment) و تخمین محدوده اثر (Blast Radius). این فرآیند چون عمدتاً بر پایه خواندن داده‌ها (Read-heavy) و محدود است، یک کاندیدای ایده‌آل برای اتوماسیون عامل‌محور (Agentic) محسوب می‌شود. طبق مستندات پروژه در ۲۴ ژوئن ۲۰۲۶، این سیستم به عنوان پیاده‌سازی عملی یک الگوی عامل بدون رابط کاربری (Headless Agent) در محیط‌های محاسباتی مشترک معرفی شده است.
همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، اعتماد مطلق به مدل‌ها خطرناک است. به همین دلیل Poirot با استفاده از TypeScript و AWS Cloud Development Kit (CDK) ساخته شده است. این سیستم از الگویی بهره می‌برد که ابتدا توسط Danielle Heberling طراحی شده بود؛ الگویی که در ابتدا از یک عامل کدنویسی بدون رابط کاربری برای بررسی استقرارهای شکست‌خورده در CloudFormation استفاده می‌کرد. در حالی که DNA این دو سیستم یکسان است، Poirot دامنه فعالیت را به پاسخ به حوادث عمومی در کل پشته فناوری (Across the stack) گسترش داده است.
خط لوله بررسی حادثه
فرآیند زمانی آغاز می‌شود که یک هشدار CloudWatch روی جهش خطاهای لاگ فعال شود. طبق سازوکار تعریف‌شده، این هشدار از طریق SNS یک اعلان می‌فرستد که یک تابع Lambda را برای شروع یک Build فعال می‌کند. بخش اصلی عملیات و پردازش‌های سنگین در AWS CodeBuild رخ می‌دهد، جایی که عامل در یک محیط بدون رابط کاربری (Headless Environment) فعالیت می‌کند.
درون CodeBuild، سیستم ابتدا ابزار Claude Code را نصب کرده و سپس یک اجراکننده TypeScript را فعال می‌کند. عامل با استفاده از دستور claude -p در یک حالت بدون رابط کاربری و در قالب Stream-JSON عمل می‌کند. از این نقطه به بعد، عامل با استفاده از AWS CLI استاندارد با محیط تعامل برقرار می‌کند تا بتواند CloudWatch Logs Insights، متریک‌ها و تاریخچه استقرارها را کوئری کند و استخراج نماید.
مهندسی مرزهای سخت امنیتی
یکی از کلیدی‌ترین تصمیمات در طراحی Poirot، امتناع از اعتماد به وعده‌های مدل هوش مصنوعی است. برای جلوگیری از اینکه عامل به صورت تصادفی یا عمدی به محیط تولید (Production) آسیب بزند، سیستم تحت یک نقش IAM (مدیریت دسترسی و هویت) اختصاصی و «فقط‌خواندنی» فعالیت می‌کند که کاملاً از نقشی که باعث لانچ آن می‌شود جدا است. این رویکرد امنیتی مشابه استراتژی‌هایی است که در پروژه ninoxAI برای حذف ریسک‌های اجرای هوش مصنوعی در محیط Production به کار گرفته شد. این ساختار تضمین می‌کند که عامل هرگز نمی‌تواند هیچ منبعی را ایجاد، تغییر، ری‌استارت یا حذف کند.
برای مقابله با ریسک تزریق پرامپت (Prompt Injection) — یعنی زمانی که محتویات غیرقابل اعتماد در لاگ‌ها سعی می‌کنند مدل را به مسیر غلط ببرند — توسعه‌دهنده یک فهرست «عدم دسترسی» (Deny List) صریح برای خواندن داده‌های حساس تعریف کرده است. نقش بررسی‌کننده (Investigator Role) از دسترسی به موارد زیر کاملاً تهی شده است:
- اسرار (Secrets) و پارامترهای SSM
- رمزگشایی KMS
- محتوای آبجکت‌های S3
- داده‌های DynamoDB
مدیریت بهینه هزینه و منابع
برخلاف اکثر عامل‌های هوش مصنوعی که از طریق API Key و بر اساس تعداد توکن (Token) هزینه می‌گیرند، Poirot از یک توکن اشتراکی Claude Pro/Max برای احراز هویت استفاده می‌کند. این معماری منجر به ایجاد یک مدل هزینه ثابت (Flat-cost) می‌شود؛ به این معنا که چه یک وابستگی متلاطم یک هشدار فعال کند و چه پنجاه هشدار، صورت‌حساب ماهانه ثابت باقی می‌ماند.
انتخاب CodeBuild به جای Lambda کاملاً عمدی بود. بررسی‌ها معمولاً طولانی و متلاطم هستند و به یک شل (Shell) کامل همراه با زنجیره ابزارهای Node و CLI نیاز دارند. CodeBuild این محیط را بدون هزینه‌های مربوط به سرورهای دائمی و بدون استفاده (Idle Costs) فراهم می‌کند.
تشریح یک گزارش مبنی‌سازی‌شده
هر بررسی با یک گزارش ساختاریافته به پایان می‌رسد که با مبنی‌سازی (Grounding) — یعنی متصل کردن هر ادعا به یک مدرک واقعی استخراج شده — از «حس کلی AI» (AI vibes) فاصله می‌گیرد. این تلاش برای کاهش خطاها ضروری است، چرا که تفکیک توهمات مدل از نقص‌های ابزار-بندی (Instrumentation) یکی از چالش‌های کلیدی در توسعه عامل‌های AI است. یک گزارش استاندارد شامل این موارد است:
- خلاصه حادثه: جهش دقیق متریک و برچسب زمانی (Timestamp).
- علت ریشه‌ای: همبستگی با یک ID استقرار خاص.
- شواهد: تعداد دقیق لاگ‌ها و زمان‌های ثبت شده در CloudWatch.
- محدوده اثر: مناطق (Regions) آسیب‌دیده و درصد شکست درخواست‌ها.
- سطح اطمینان: بالا، متوسط یا پایین، بر اساس میزان همسویی شواهد.
این رویکرد نقش مهندس را از یک جمع‌کننده داده دستی به یک تصمیم‌گیرنده تبدیل می‌کند. عامل کارهای سخت و جست‌وجوها را انجام داده و یک «متهم» را شناسایی می‌کند، اما انسان تنها کسی است که اختیار اجرای اصلاحات و Fix نهایی را دارد.
برای خواننده، این موضوع نشان‌دهنده تغییری در تجربه «آن‌کال» (On-call) است. هدف این نیست که مهندس جایگزین شود، بلکه هدف حذف بخش‌های کسل‌کننده و خواب‌آلود شب‌های کاری است. با ساختن یک دیوار «محدوده اثر» به دور هوش مصنوعی، سیستم مزایای خودمختاری را بدون ریسک‌های دسترسی کنترل‌نشده به محیط تولید فراهم می‌کند.
گام بعدی شما
- برای مشاهده پیاده‌سازی کامل، کد منبع را در گیت‌هاب به آدرس
github.com/wakeupmh/poirot-agentبررسی کنید و کارهای بنیادین Danielle Heberling را مرور نمایید. - معماری Read-Only IAM را در سیستم‌های مانیتورینگ خود پیاده کنید تا ریسک دسترسی عامل‌ها به محیط Production حذف شود.
- از الگوی Headless Agent برای اتوماسیون کارهای تکراری در زیرساخت‌های AWS استفاده کنید.
این تنها آغاز ماجراست؛ اثر موج‌گونه‌ی این تصمیم بر اکوسیستم متن‌باز را در گزارش بعدی بررسی خواهیم کرد.
گفتگو