آیا عامل‌های هوش مصنوعی واقعاً می‌توانند تأیید کنند کدهای پیچیده‌ای که می‌نویسند، در عمل کار می‌کنند؟ طبق گزارشی که Stripe در ۱۵ ژوئیه ۲۰۲۶ منتشر کرد، پاسخ این سؤال منفی است.
به نقل از این گزارش، یک مجموعه محک (Benchmark) جدید نشان می‌دهد شکافی حیاتی در قابلیت اعتماد این ابزارها وجود دارد: عامل‌ها در مرحله ساخت اولیه عالی عمل می‌کنند، اما در مرحله اعتبارسنجی و اصلاح خودکار به‌طور مداوم شکست می‌خورند.
این ناتوانی در عیب‌یابی خودکار زمانی رخ می‌دهد که صنعت در حال گذار از رابطهای ساده‌ی گفتگو به خودکارسازی پیچیده گردش‌های کاری است. این روند را می‌توان در پیاده‌سازی‌های عملیاتی دید، جایی که ابزارهایی مانند پروتکل MCP برای حذف کدهای یکپارچه‌ساز در گردش‌کارهای B2B به‌کار گرفته می‌شوند تا پیچیدگی‌های ادغام کاهش یابد. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، گلوگاه فعلی تنها امنیت نیست، بلکه ناتوانی بنیادی یک عامل (Agent) — شبیه دستیاری که دستورات را اجرا می‌کند اما نمی‌داند اشتباه کرده است — در تشخیص خطاهای خود در محیط عملیاتی است.
در کنار این یافته‌ها، الگوی جدیدی برای استقرار مدل‌ها از طریق اجرای سمت کاربر در حال شکل‌گیری است. به گزارش وب‌سایت Dev.to، یک توسعه‌دهنده عاملی برای بخش فرانت‌اند ساخته که کاملاً درون مرورگر وب اجرا می‌شود. این رویکرد با سیر تکاملی WebGPU که استنتاج هوش مصنوعی را از سرورها به مرورگر منتقل کرد همسو است و امکان پردازش محلی را فراهم می‌کند. این دستاورد با تنظیم دقیق (Fine-tuning) — یعنی تخصصی کردن یک مدل کلی برای یک حوزه خاص، شبیه وقتی به پزشک عمومی تخصص پوست می‌دهیم — مدل‌های LFM2.5 شرکت LiquidAI در نسخه‌های ۲۳۰ و ۳۵۰ میلیون پارامتری ممکن شده است.
با حذف پردازش‌های سمت سرور و نیاز به کلیدهای API، این روش هزینه‌های ابری را حذف کرده و حریم خصوصی کاربران را به‌شدت بهبود می‌بخشد.
برای کسانی که این عامل‌ها را در مقیاس سازمانی گسترش می‌دهند، تمرکز اکنون روی زیربناهای داده‌ای است. گوین شاپیرا (Gwen Shapira) استراتژی جدیدی را معرفی کرد که در آن از PostgreSQL فراتر از یک پایگاه‌داده ساده استفاده می‌شود. در این الگو، Postgres به‌عنوان لایه سازمان‌دهنده عمل می‌کند و از قابلیت‌های زیر بهره می‌برد:
- پشتیبانی از JSONB برای ساختارهای انعطاف‌پذیر و در حال تغییر عامل‌ها.
- قابلیت‌های تراکنشی (Transactional) برای مدیریت مطمئن وضعیت.
- پرس‌وجوهای رابطهای برای ردیابی تاریخچه گفتگوها و ابزارهای استفاده شده.
این تغییر معماری، عامل‌ها را از پایگاه‌داده‌های برداری ساده دور کرده و به سمتی می‌برد که قابلیت حسابرسی و ماندگاری وضعیت، ویژگی‌های اصلی باشند. استفاده از یک بستر رابطهای به شرکت‌ها اجازه می‌دهد عامل‌ها را بدون ایجاد سیلوهای ذخیره‌سازی پراکنده، با استراتژی‌های داده‌ای موجود ادغام کنند.
برای یک توسعه‌دهنده، این یعنی پشته (Stack) ایده‌آل برای عامل‌ها به دو مسیر جدا می‌راند. احتمالاً از مدل‌های بسیار کوچک (مانند LiquidAI) برای تعاملات سریع و خصوصی در رابط کاربری استفاده خواهید کرد و برای منطق‌های پیچیده تجاری به لایه‌ای متکی بر Postgres تکیه می‌کنید.
با این حال، داده‌های Stripe یک هشدار جدی است. فارغ از اینکه استقرار چقدر بهینه یا پایگاه‌داده چقدر قدرتمند باشد، عاملی که نتواند خروجی خود را اعتبارسنجی کند، در یک خط لوله تولیدی یک ریسک است. تکامل بعدی باید روی «منتقد» تمرکز کند؛ یعنی بخشی از عامل که قادر به تست سخت‌گیرانه و اصلاح تکرارشونده است.
گام بعدی شما
- بررسی چارچوب‌های جدیدی که روی «حلقه اعتبارسنجی» متمرکز هستند تا از خطاهای تولیدی جلوگیری کنید.
- تست مدل‌های کوچک LFM2.5 برای پیاده‌سازی قابلیت‌های ساده در سمت کلاینت جهت کاهش هزینه استنتاج.
- ارزیابی استفاده از PostgreSQL به‌جای ذخیره‌سازهای برداری برای مدیریت وضعیت‌های پیچیده عامل‌ها.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو