تصور کنید ابزارهای هوش مصنوعی که هر روز با آن‌ها کار می‌کنید، موجوداتی جادویی نیستند، بلکه مجموعه‌ای از دستورالعمل‌های سخت‌گیرانه هستند. به نقل از نقد فنی منتشر شده در وب‌سایت dev.to در ۱۳ اکتبر ۲۰۲۶، وسواس صنعت روی «عامل‌های هوش مصنوعی» (AI Agents) در واقع تلاشی برای منحرف کردن توجه ما از واقعیت‌های توسعه نرم‌افزار است.
برای درک بهتر، اپلیکیشن مورد علاقه خود را شبیه به یک خانه تصور کنید؛ در اینجا «عامل» روحی نیست که درون خانه زندگی می‌کند، بلکه همان لوله‌کشی و آجرهای ساختمان است. در فضای فعلی فناوری، ما اغلب پیچیدگی‌های سازمان‌دهی را با یک نوع جدید از هستی اشتباه می‌گیریم و فراموش می‌کنیم که هر عملیات دیجیتال هنوز به یک CPU یا GPU وابسته است. همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های انتزاعی نباید ما را از زیرساخت‌های سخت‌افزاری غافل کنند.
بر اساس این تحلیل، دنیای دیجیتال به دو دسته‌ی سخت و مجزا تقسیم می‌شود:
- نرم‌افزار: شامل برنامه‌نویسی قطعی و داده‌های غیرتنسوری، مانند منطق کنترلی، ورودی‌های کاربر، پایگاه‌های داده، APIها و اکتشافات تجربی (Heuristics).
- مدل‌های یادگیری ماشین (Machine Learning Models) — شبیه به موتورهای ریاضی که داده‌ها را پردازش می‌کنند — که بر پایه تنسورها بنا شده‌اند.
طبق گزارش نویسنده، هر سیستم هوش مصنوعی موجود در حال حاضر در یکی یا هر دو دسته‌ی بالا جای می‌گیرد و هیچ عنصر سوم و مرموزی وجود ندارد. چه یک چت‌بات ساده باشد و چه یک گردش‌کار خودکار، همگی از کدهای سنتی تشکیل شده‌اند که از یک مدل استفاده می‌کنند. این تضاد میان ساختار ساده‌ی فنی و ادعاهای پیچیده، اغلب منجر به شکافی میان دموی جذاب و استقرار واقعی در مقیاس صنعتی می‌شود که پیش‌تر به آن پرداخته‌ایم.
این تغییر دیدگاه به این معناست که برچسب «عامل»، یک لایه‌ی بازاریابی است، نه یک دسته‌بندی فنی. برای کاربر نهایی، این یعنی قابلیت اطمینان یک سیستم به کیفیت نرم‌افزار قطعیِ پیرامون مدل بستگی دارد، نه به «هوش» خودِ عامل.
اگر در حال توسعه محصول با هوش مصنوعی هستید، به جای جست‌وجوی یک «حفاظ» (Harness) جادویی، روی منطق کنترلی خود تمرکز کنید. در واقع، پایداری عامل‌های هوش مصنوعی بیش از هر چیز به مهندسی دقیق این هارنس وابسته است تا قدرت مدل زبانی مورد استفاده. دفعه بعد که خبر معرفی یک «عامل» جدید را شنیدید، از خود بپرسید: کدام بخش مدل تنسوری است و کدام بخش صرفاً یک فراخوانی API خوش‌ساخت است؟
گام بعدی شما
- در بررسی ابزارهای جدید، به جای تمرکز بر ادعای «عامل بودن»، معماری لایه‌ی نرم‌افزاری آن‌ها را تحلیل کنید.
- برای افزایش پایداری سیستم‌های خود، منطق کنترلی (Control Logic) را از مدل‌های احتمالی جدا کنید.
- مستندات فنی APIهای مورد استفاده خود را بازخوانی کنید تا مرز بین کد قطعی و استنتاج مدل را شناسایی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو