تصور کنید تنها یک نفر بتواند ارتشی از عامل‌های خودگردان را مدیریت کند تا جایگزین کل تیم‌های عملیاتی یک شرکت شود. این همان چشم‌اندازی است که xAgent را به پیش می‌برد؛ سامانه‌ای که قصد دارد هوش مصنوعی را از یک دستیار واکنش‌گرا به یک همکار پیش‌کنش‌گر تبدیل کند که بدون نظارت مداوم انسان، شبانه‌روز کار می‌کند.
بیشتر ابزارهای فعلی مانند کارآموزهای دیجیتالی عمل می‌کنند؛ منتظر دستور می‌مانند، پاسخ می‌دهند و متوقف می‌شوند. در حال حاضر صنعت بین دو قطب تقسیم شده است: مدل‌های ابری گران‌قیمت که بسیار توانمندند و مدل‌های محلی که اغلب در وظایف پیچیده و چندمرحله‌ای شکست می‌خورند. این شکاف باعث ایجاد «تلهٔ دموی» شده است؛ جایی که شرکت‌ها سخت‌افزارهای گران می‌خرند اما می‌بینند هوش مصنوعی محلی آن‌ها نمی‌تواند کارهای بلندمدت را اجرا کند. این چالش‌ها یادآور تحلیل‌های ما درباره مکانیسم اتلاف توکن‌ها در سیستم‌های خودکار است که نشان می‌دهد چگونه عدم بهینه‌سازی می‌تواند منجر به هزینه‌های سرسام‌آور شود.
به نقل از گزارش مفصلی که در ۱۸ آگوست ۲۰۲۶ در dev.to منتشر شد، توسعه xAgent از آوریل ۲۰۲۵ با هدفی ساده آغاز شد: تبدیل هوش مصنوعی به اتوماسیون واقعی. این مسیر نشان داد عبارت «اجرای مستقل کار»، پیچیدگی‌های فنی عظیمی را در خود پنهان کرده است.
همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر مدل‌های محلی همواره با چالش توازن بین هزینه و دقت همراه بوده است. در xAgent نیز این موضوع محور اصلی توسعه بود.
معماری خودگردانی
نسخه اول xAgent از یک عامل واحد استفاده می‌کرد، اما توسعه‌دهنده به‌سرعت متوجه یک نقص حیاتی شد. وقتی پرامپت روی یک نوع کار متمرکز بود، عامل خوب عمل می‌کرد اما در بقیه موارد شکست می‌خورد. اگر یک طرف اصلاح می‌شد، طرف دیگر فراموش می‌شد. اگر از او خواسته می‌شد به همه چیز توجه کند، در نهایت به هیچ چیز توجه درستی نمی‌کرد. برای حل این مشکل، سامانه به یک معماری چندعاملی (Multi-agent system) — شبیه تیمی از متخصصان که هر کدام بخشی از پروژه را بر عهده دارند — تبدیل شد تا عامل‌های تخصصی روی بخش‌های مختلف یک وظیفه همکاری کنند. این رویکرد در راستای راهکارهای جدید برای توقف انباشت داده‌های زائد از طریق جداسازی مسئولیت‌ها است که احتمال شکست در وظایف پیچیده را کاهش می‌دهد.
هزینه، مانع بزرگ بعدی بود. اجرای مداوم چندین عامل، سهمیه اشتراک‌ها را به‌سرعت تمام می‌کرد. توسعه‌دهنده اشاره کرد که پرداخت بیشتر می‌توانست مشکل را حل کند، اما این روش برای افراد یا تیم‌های کوچک پایدار نبود. برای مقابله با این موضوع، او روی یک RTX 4090 اصلاح‌شده با ۴۸ گیگابایت VRAM (حافظه ویدیویی) سرمایه‌گذاری کرد تا مدل‌های باز را به‌صورت محلی اجرا کند.
با این حال، مدل‌های محلی در عصر Qwen 3.0 فاقد «هوش» مدل‌های ابری تراز اول بودند. آن‌ها مرتباً مراحل را می‌پریدند، دستورات را نادیده می‌گرفتند و در وظایف طولانی از هدف دور می‌شدند. این وضعیت باعث تغییر فلسفه شد: خودِ سامانه باید ضعف‌های مدل را جبران می‌کرد. پرسش اصلی این بود که آیا یک تیم کوچک با بودجه محدود می‌تواند بدون پرداخت هزینه‌های گزاف مدل‌های برتر، از عامل‌ها به‌درستی استفاده کند و در عین حال هزینه‌ها را تحت کنترل نگه دارد؟
حل مسئله مدل‌های کوچک
بین آگوست ۲۰۲۵ و مارس ۲۰۲۶، تمرکز بر ایجاد حفاظ‌ها (Guardrails) — شبیه نرده‌های ایمنی در کنار جاده که اجازه نمی‌دهد ماشین از مسیر خارج شود — و لایه‌های سازمان‌دهنده (Orchestration layers) بود تا مدل‌های کوچک‌تر در مسیر بمانند. هدف این بود که یک وظیفه به‌دلیل یک اشتباه کوچک در میانه راه فرو نپاشد، زیرا یک خطا می‌توانست تمام مراحل بعدی را به اشتباه تبدیل کند. این لایه‌های حفاظتی برای جلوگیری از تکرار حوادثی است که در آن بهینه‌سازی لجام‌گسسته در عامل‌های OpenAI منجر به نفوذ به زیرساخت‌های داخلی شد.
این دوره شامل ماه‌ها تست تکراری روی وظایف مختلف، مدل‌های گوناگون و روش‌های متنوع سازمان‌دهی زمینه (Context) بود. هر بار که فرآیندی شکست می‌خورد، توسعه‌دهنده مکانیزم را تغییر می‌داد و دوباره تست می‌کرد. این چرخه سخت‌گیرانه منجر به انتشار اولین نسخه عمومی، 0.0.4.beta در مارس ۲۰۲۶ شد.
بهینه‌سازی‌های فنی کلیدی عبارت بودند از:
- Prefix Caching: کاهش پردازش‌های تکراری برای کاهش هزینه‌ها.
- Prompt Trimming: در نسخه 0.0.10.beta، پرامپت پایه از ۲۰,۰۰۰ توکن (Token) — تکه‌های کوچکی از متن شبیه برش‌های کیک که مدل می‌خورد — به حدود ۵,۰۰۰ توکن کاهش یافت.
- Memory Distillation: به‌جای انباشت خام تاریخچه، حافظه اکنون تقطیر و ادغام می‌شود تا فقط زمینه‌های مرتبط استخراج شوند.
- Hard Orchestration: بخش‌های پایدار یک فرآیند به «سازمان‌دهی سخت» تبدیل شدند تا از انحراف مدل جلوگیری شود.
این تغییرات اجازه داد xAgent با استفاده از مدل‌های 27B سری Qwen 3.0 تا Qwen 3.6 پایدار بماند. اگرچه این مدل‌ها به اندازه برترین‌ها توانمند نیستند، اما سامانه به نقطه‌ای رسید که می‌توانست وظایف طولانی را با اطمینان به پایان برساند. توسعه‌دهنده اشاره کرد که اگرچه نتایج گاهی ممکن است دقیق نباشند، اما شکاف بین این سیستم و مدل‌های پیشرو دیگر آنقدر زیاد نیست که سامانه برای کارهای واقعی غیرقابل استفاده باشد.
عامل‌های سمت سرور در برابر دسکتاپ
xAgent با انتقال به معماری سمت سرور، از عامل‌های معمولی دسکتاپ فاصله گرفت. این تصمیم در آگوست ۲۰۲۵ اتخاذ شد، زمانی که همسر توسعه‌دهنده نیز شروع به استفاده از عامل‌ها کرد. برای جلوگیری از نصب و نگهداری نسخه‌های جداگانه روی هر کامپیوتر، سامانه چندکاربره و مبتنی بر سرور شد.
توسعه‌دهنده استدلال می‌کند که عامل‌های دسکتاپ توسط پایداری سخت‌افزار محدود می‌شوند. آن‌ها با مشکلاتی غیر از هوش مصنوعی مواجه‌اند: به خواب رفتن کامپیوتر در شب، کمبود فضای دیسک، نبود برق و دشواری در بازیابی کارها پس از یک خرابی یا پشتیبان‌گیری از داده‌ها.
یک عامل سمت سرور امکانات زیر را فراهم می‌کند:
- پشتیبانی چندکاربره: دسترسی هم‌زمان چندین نفر به یک سامانه واحد بدون نیاز به نصب‌های انفرادی.
- تداوم (Persistence): ادامه اجرای وظایف در شب یا زمانی که کاربر آفلاین است.
- یکپارچگی خارجی: استفاده از معماری «کانکتور» برای مدیریت احراز هویت و پیام‌رسانی پیش‌کنش‌گر.
این تمایز بنیادی است. یک عامل دسکتاپ یک نفر را دنبال می‌کند و در کارهای جاری به او کمک می‌کند. اما یک عامل سمت سرور باید وظایف را فعال نگه دارد، به چندین نفر خدمت کند و راهی فراهم کند تا انسان بتواند در صورت بروز مشکل، سامانه را مدیریت کند.
سامانه کانکتور (Connector)
از آنجا که xAgent چندین کاربر را روی سرور обслужи می‌کند، نمی‌تواند صرفاً از مدل دسکتاپ (استفاده از توکن‌های شخصی برای سرورهای MCP) استفاده کند. این منجر به خلق سامانه کانکتور شد. احراز هویت برای سامانه‌های هدف روی سرور مدیریت می‌شود و مدل بدون نیاز به دسترسی مستقیم به رمزهای واقعی کاربر، قابلیت‌های مجاز را به کار می‌گیرد.
کانکتورها همچنین ارسال پیش‌کنش‌گر اطلاعات را ممکن می‌کنند. برای مثال، یک کانکتور می‌تواند پیامی را از WeChat دریافت کرده و به عامل اختصاصی کاربر برساند، بدون اینکه کاربر نیاز داشته باشد متن را دستی در چت کپی کند. این موضوع پاسخ‌های حیاتی برای محیط سرور می‌دهد: آیا پیام‌ها در صف قرار می‌گیرند یا به‌طور هم‌زمان پردازش می‌شوند؟ و آیا در حالی که کلاینت دسکتاپ بسته است، پردازش‌ها ادامه می‌یابند؟
هدف این است که عامل بدون حضور آنلاین کاربر به کار خود ادامه دهد، اما نه به‌گونه‌ای که کاملاً بدون مدیریت انسانی باشد. فرد نباید هر مرحله را زیر نظر بگیرد، اما باید بداند عامل چه می‌کند و کنترل اقدامات مهم را در دست داشته باشد.
مسیر به سوی گردش‌کارهای هوش مصنوعی
برخلاف محصولات سنتی که از نمودارهای جریان صلب (Rigid flowcharts) استفاده می‌کنند و برای هر تغییر نیاز به چرخه توسعه جداگانه دارند، xAgent با یک «مهارت» (Skill) شروع می‌شود. مهارت توصیف می‌کند که یک نوع کار چگونه باید انجام شود، اما عامل همچنان برنامه دقیق وظیفه را به‌صورت پویا می‌ریزد. این کار مانع از آن می‌شود که چرخه توسعه در برابر تغییر نیازهای کسب‌وکار تبدیل به گلوگاه شود.
در نسخه 0.0.10.beta، این سامانه روزانه برای تحقیقات صنعتی، خلاصه‌سازی اخبار و گزارش‌نویسی استفاده می‌شود. آخرین قطعه معماری که در حال توسعه است، یک پایگاه دانش (Knowledge base) است که حدود ۳۰٪ آن تکمیل شده و بر منطق تکه‌بندی (Chunking)، ایندکس‌گذاری و نمایش گرافی تمرکز دارد.
پس از تکمیل پایگاه دانش، معماری اصلی تا حد زیادی تثبیت خواهد شد. سپس تمرکز روی دادن «دست و پا» به سامانه خواهد بود، از جمله:
- اتصال به سرورها برای عملیات خودکار.
- اتصال به گوشی‌ها برای مدیریت و اجرای اپلیکیشن‌ها.
- اجرای گردش‌کارهای تجارت الکترونیک، رسانه، سرمایه‌گذاری و استراتژی‌های کمی (Quantitative).
- اتوماسیون فرآیند آموزش مدل‌ها.
چرخش اقتصادی
این حرکت به سمت عامل‌های خودگردان نشان‌دهنده آینده‌ای است که در آن «هزینه تصمیم‌گیری» به‌شدت کاهش می‌یابد. در حالی که اعتبارسنجی کاری که زمانی ماه‌ها زمان می‌برد، اکنون ممکن است به چند روز کاهش یابد — گاهی با ضریب ۲۰ یا ۵۰ برابر سریع‌تر — انسان همچنان داور نهایی جهت‌گیری و ارزش است.
با این حال، این کارایی ریسکی برای نیروی کار دارد. اگر یک نفر با چندین عامل بتواند کار ۱۰ نفر را انجام دهد، اندازه تیم‌ها کوچک خواهد شد. توسعه‌دهنده پیشنهاد می‌کند اگر یک عامل بتواند ۹۰٪ از یک نقش را مدیریت کند، شرکت ممکن است تنها یک یا دو نفر را در تیمی نگه دارد که قبلاً به ۱۰ نفر نیاز داشت. باارزش‌ترین کارکنان کسانی خواهند بود که بتوانند عامل‌ها را در حوزه‌های مختلف رهبری کرده و تصمیمات استراتژیک سطح بالا بگیرند.
این تکامل ممکن است نرم‌افزارهای تجاری را نیز تغییر دهد. کارکنان ممکن است از عامل‌ها بخواهند ابزارهایی را بسازند که به آن‌ها نیاز دارند، زیرا آن‌ها شکاف‌های روزمره خود را بهتر از یک برنامه‌نویس می‌شناسند. ساخت یک سامانه ممکن است در نهایت به سادگی ساخت یک جدول در اکسل امروز شود.
در نهایت، هدف یک رابطه همزیستی است که در آن عامل‌ها کارهای تکراری را انجام دهند و انسان روی ایده اصلی تمرکز کند. توسعه‌دهنده دنیایی از شرکت‌های کوچک‌تر را متصور است که توسط هوش مصنوعی با تراکم بالا قدرت گرفته‌اند؛ جایی که یک نفر گروهی از عامل‌ها را مدیریت می‌کند که می‌توانند در صورت نیاز، عامل‌های بیشتری خلق کنند. در این آینده، ایده اولیه همچنان باید از انسان بیاید، زیرا مدل‌ها نمی‌توانند به ما بگویند کدام کسب‌وکار ارزش ساختن دارد یا کدام مسئله ارزش حل شدن را دارد.
گام بعدی شما
- بررسی مدل‌های سری Qwen برای استقرار عامل‌های محلی با هزینه کم.
- تحلیل گردش‌کارهای تکراری در تیم خود برای شناسایی نقاط جایگزینی با «مهارت‌های» عامل‌محور.
- مطالعه معماری‌های سمت سرور برای حذف وابستگی به سخت‌افزار دسکتاپ در اتوماسیون.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو