تصور کنید یک اشتباه کوچک در یک دستور SQL کل سیستم بانکی یا فروشگاهی یک شرکت را ساعتها متوقف کند؛ کابوسی که هر مدیر پایگاهدادهای (DBA) با آن میجنگد. برای حل این بحران اعتماد، یک مهندس اوراکل در ۱۲ ژوئیه ۲۰۲۶ چارچوبی را معرفی کرد که در آن هیچ مدل زبانی بزرگی اجازه ندارد بهصورت خودکار تغییری در محیط عملیاتی ایجاد کند. هزینه تولید گزارشهای صبحگاهی توسط این سیستم "Agentic OS" تنها ۰.۰۱ دلار است.
این سیستم با رویکرد «گیت یا دروازه»، هر اقدام حساس را متوقف کرده و تایید انسانی میگیرد تا محیط Production هرگز به دست یک مدل بدون نظارت نسپاری نشود. طبق گزارش منتشرشده در وبسایت dev.to، این معماری بهجای اینکه هوش مصنوعی را یک پوسته همهکاره ببیند، آن را به مجموعهای از «مهارتهای» تخصصی نمادین تقسیم کرده است. این طراحی مانع از آن میشود که هر مدلی بهطور خودمختار پایگاه داده را تغییر دهد. این رویکرد کنترلشده، پاسخی مستقیم به دغدغههای امنیتی است که در بررسی لایههای میانی متنباز برای کاهش خطرات دسترسی عاملها به آنها پرداختیم.
بسیاری از عاملهای هوش مصنوعی فعلی با رویکرد «امید به بهترین نتیجه» کار میکنند؛ یعنی یک ترمینال و یک پرامپت میگیرند و رها میشوند. اما برای یک DBA، این روش خودکشی دیجیتال است، زیرا یک دستور نادرست میتواند کل کسبوکار را به زمین بزند. همانطور که در تحلیلهای پیشین ما درباره امنیت مدلهای بازمتن اشاره کردیم، جداسازی لایه تصمیم از لایه اجرا تنها راه دستیابی به پایداری در مقیاس صنعتی است. در این سیستم، لحظه کشف حقیقت (A-ha moment) این است که مدل اعتماد به عنوان محصول اصلی در نظر گرفته شده و هوش مصنوعی تنها به عنوان یک رابط انعطافپذیر عمل میکند. این تمرکز بر حاکمیت کاربر بر ابزارها، یادآور فلسفه انتقال مالکیت دستیاران هوش مصنوعی به سرورهای شخصی در پروژه AIDA است تا کنترل دادهها و اجراها کاملاً در دست کاربر باقی بماند.
زمینه و معماری
این سیستم شامل شش مهارت مجزا است. هر مهارت در پوشه مخصوص به خود قرار دارد که حاوی یک فایل Manifest و یک پرامپت است. افزودن یک مهارت جدید بسیار ساده است و تنها با قرار دادن پوشهای شامل فایل manifest.yaml در سیستم انجام میشود.
این مهارتها عبارتند از:
- ebs-dba: مدیریت تشخیصهای فقطخواندنی اوراکل و EBS، شامل خلاصههای AWR، شناسایی SQLهای برتر (Top SQL) و تحلیل نشستهای مسدود شده (Blocking Sessions).
- patch-triage: تجزیه و تحلیل اطلاعیههای امنیتی CPU اوراکل. این مهارت دادهها را برای استکهای 19c و EBS R12.2.11 فیلتر کرده، آنها را بر اساس فوریت دستهبندی میکند و آسیبپذیریهای شناختهشده و بهرهبرداریشده (CISA KEV) را در اولویت قرار میدهد.
- daily-brief: این مهارت ساعت ۷:۰۰ صبح بیدار میشود تا سلامت پایگاهداده و وضعیت git را در تمامی پروژهها بررسی کرده و خلاصهای را از طریق مدل Haiku با هزینه تقریبی یک سنت ارسال کند.
- research: انجام جستوجوهای گسترده در وب (Fan-out) همراه با ذکر منابع و بررسی متقابل ادعاها برای اطمینان از صحت آنها.
- project-runner: مدیریت وظایف ساخت (Build)، تست و استقرار (Deploy). نکته حیاتی این است که تمامی استقرارها نیازمند تایید صریح انسان هستند.
- content-pipeline: پیشنویس محتوا را تهیه میکند، اما از نظر ساختاری هرگز قادر به انتشار مستقیم محتوا نیست.
هسته دسترسی (Permission Kernel)
قلب تپنده این سیستم، یک «هسته دسترسی» است که ابزارها را به چهار سطح متمایز تقسیم میکند: خواندن (Read)، نوشتن (Write)، هزینه (Spend) و تغییر عملیاتی (Prod-touch). این هسته ادعاهای مدل هوش مصنوعی را نادیده میگیرد و قوانین سختگیرانهای را بر اساس ثبت ابزار اجرا میکند:
- Read: بهصورت خودکار اجرا میشود. تمامی ابزارهای اوراکل در این دسته ثبت شدهاند زیرا هیچ مسیر نوشتاری به پایگاه داده ندارند.
- Write/Spend/Prod-touch: اجرای مدل را متوقف کرده، یک پیشنمایش از اجرای آزمایشی (Dry-run) را نمایش میدهد و نیازمند یک تایید انسانی هششده و یکبار مصرف است.
بسیار مهم است که تاییدیه کاربر دقیقاً با آرگومانهای هششده مطابقت داشته باشد؛ بنابراین تایید دستور npm run build هرگز نمیتواند برای اجرای rm -rf بازتولید شود. اگر یک دروازه نتواند ورودی استاندارد (stdin) را بخواند، سیستم بهصورت پیشفرض بسته میشود (Fail closed). از آنجایی که اجراهای خودکار (Cron) نمیتوانند از کاربر سوال کنند، فراخوانهای دروازهدار در یک صف قرار میگیرند و به کاربر اطلاعرسانی میشود.
برای جلوگیری از تزریق پرامپت (Prompt Injection) یا حذفهای تصادفی، از یک لیست سفید (Allowlist) سختگیرانه برای دستورات شل استفاده شده است. بهطور مثال، دستورات git status ،pytest و npm run build در دسته Read اجرا میشوند. اما دستوراتی مانند vercel --prod یا terraform apply در دسته Spend علامتگذاری شدهاند و یک دروازه سخت را فعال میکنند.
در مورد ابزار sqlite3، دسترسی تنها در صورتی مجاز است که دستور حاوی عبارت "SELECT" باشد و از یک بررسی Regex (SQLITE_WRITE_RE) برای مسدود کردن عملیات نوشتن عبور کند. این طراحی زمانی تایید شد که مجموعه تستهای نویسنده، آسیبپذیریای را شناسایی کرد که در آن فلگهایی مانند -header -column میتوانستند قوانین پیشوندی ساده را دور زده و اجازه اجرای یک DELETE بدون تایید را بدهند. این مورد اکنون به عنوان یک تست رگرسیون در مجموعه تستها قرار دارد.
مهارتهای عامل و ردیابی هزینه
برای وظایفی با تکرار بالا و پیچیدگی کم، مانند گزارش سلامت ساعت ۷ صبح، سیستم از مدل Claude Haiku 4.5 استفاده میکند تا هزینه هر گزارش حدود ۰.۰۱ دلار بماند. اما برای پژوهشهای سنگین که نیاز به استدلال زیاد دارند، سیستم بهطور خودکار به مدل Claude Opus 4.8 سوئیتش میکند.
هر گردش (Turn) مدل بهطور کامل در یک پایگاهداده SQLite و یک فایل JSONL مخصوص هر اجرا审计 (Audit) میشود. موارد ردیابی شده عبارتند از:
- تمام گردشهای مدل و فراخوانی ابزارها به همراه آرگومانها و مدت زمان اجرا.
- تمام تصمیمات مربوط به تایید کاربر.
- هزینه توکنها که بهصورت گامبهگام انباشته میشوند.
برای نمونه، یک اجرای پژوهشی دقیقاً ۰.۶۶۳۳ دلار هزینه داشته است و نویسنده این ارقام را تا چهار رقم اعشار ردیابی میکند. این دقت مانع از «شوک صورتحساب» میشود که در جریانهای کاری عاملمحور رایج است و در آن یک حلقه (Loop) میتواند بهطور مخفیانه اعتبارها را مصرف کند.
پشته فنی (Technical Stack)
زیرساخت این پروژه بر پایه Python 3.12 و بالاتر ساخته شده و با ابزار uv برای مدیریت وابستگیهای دقیق (شامل anthropic, mcp, typer, apscheduler, fastapi, pyyaml, و rich) مدیریت میشود. این سیستم از پروتکل زمینهٔ مدل (Model Context Protocol - MCP) بهره میبرد تا عاملها را از طریق یک ورودی YAML واحد به سرور mcp-oracle-dba متصل کند.
رابط کاربری نیز یک اپلیکیشن سبک FastAPI است که روی localhost اجرا میشود؛ یک فایل HTML تکصفحهای بدون هیچ CDN که لاگهای حسابرسی را از طریق SSE (Server-Sent Events) دنبال میکند. این رابط، جریان لحظهای افکار عامل و «کارتهای قرمز تایید» را برای اقدامات حساس نشان میدهد که شامل JSON مربوط به اجرای آزمایشی (Dry-run) است.
برای تضمین پایداری، سیستم شامل ۳۰ تست است، از جمله حلقههای هسته (Kernel loops) سرتاسری (End-to-End) علیه یک سرور واقعی MCP از طریق stdio. این تغییر رویکرد از «عاملهای خودمختار» به «سیستمهای عاملمحور کنترلشده»، هدف را از حداکثر کردن استقلال مدل به حداکثر کردن قابلیت حسابرسی تغییر میدهد.
در گام بعدی، نویسنده قصد دارد یک «حلقه دیدهبان» (Sentinel loop) پیادهسازی کند که هر چند ثانیه یکبار پایگاههای داده زنده را برای شناسایی نشستهای مسدودکننده، فشار Tablespace یا انباشت درخواستهای همزمان بررسی کرده و بهطور خودکار تحقیقات علت ریشهای (Root-cause) را آغاز کند. شما میتوانید مستندات پروتکل MCP را بررسی کنید تا ببینید چگونه سرورهای ابزاری مشابه را به جریانهای کاری هوش مصنوعی خود متصل کنید.
گام بعدی شما
- بررسی مستندات پروتکل MCP برای اتصال ابزارهای محلی شرکتتان به مدلهای زبانی.
- پیادهسازی لایه Dry-run برای هر ابزاری که دسترسی Write به دادههای حساس دارد.
- استفاده از مدلهای کوچکتر (SLMs) برای تسکهای زمانبندیشده (Cron jobs) جهت کاهش هزینه استنتاج.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو