معماری جدید: کنترل عامل‌های کدنویسی با مدل ۴ بیتی کوانتیده

تصور کنید در حالی که در تخت‌خواب هستید یا در اتوبوس به سر می‌برید، یک Pull Request کامل با ۶ کامیت و ۸ فایل تغییریافته را روی گیت‌هاب ثبت کنید، بدون آنکه حتی لپ‌تاپتان را باز کرده باشید. این دیگر یک رویای آینده‌نگرانه نیست، بلکه نتیجه‌ی جداسازی «قصد کاربر» از «اجرای کد» است.

به نقل از یک گزارش فنی منتشر شده در ۷ اوت ۲۰۲۶، این فرآیند منجر به ثبت تغییراتی شد که ۴۱۷ تست را با موفقیت پشت سر گذاشتند. تمام این چرخه از طریق یک گوشی موبایل مدیریت شد، در حالی که محاسبات سنگین در پس‌زمینه توسط عامل‌های تخصصی انجام می‌شد.

این رویکرد شکاف بهره‌وری را برای توسعه‌دهندگانی که برنامه‌های پراکنده دارند، پر می‌کند. توسعه‌دهنده‌ی این سیستم که یک دانشجوی بین‌المللی است و برای تأمین هزینه‌های زندگی کارهای پاره‌وقت انجام می‌دهد، اشاره می‌کند که چنین کارهایی نه‌تنها ساعات شیفت، بلکه ساعت قبل و بعد از آن را نیز در تکه‌هایی بسیار کوچک می‌بلعند که برای شروع یک کار واقعی برنامه‌نویسی کافی نیستند. شما نمی‌توانید در ۴۰ دقیقه پیش از خروج از خانه برای رفتن به سر کار، کل ساختار یک پروژه را در ذهن خود بارگذاری کنید. با تفکیک لایه‌ی مدیریت (قصد کاربر: چه کاری انجام شود) از لایه‌ی اجرا (نحوه کدنویسی: چگونه انجام شود)، زمان‌های مرده در اتوبوس یا در حین شیفت‌های کاری به چرخه‌های توسعه فعال تبدیل می‌شوند. هدف در اینجا سرعت کدنویسی نبود، بلکه اطمینان از پیشروی پروژه در زمان‌هایی بود که دسترسی به ماشین اصلی وجود ندارد.

معماری مدیریت (Orchestration)

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت دسترسی‌ها در سیستم‌های عامل‌محور حیاتی است. در این معماری، هسته‌ی مرکزی سیستم Hermes Agent از شرکت Nous Research است. این ابزار برخلاف مدل‌های سنتی که همه کارها را انجام می‌دهند، مانند یک درگاه پیام‌رسان عمل می‌کند. هرمس با لایسنس MIT منتشر شده و پلتفرم‌هایی مثل دیسکورد، تلگرام و اسلک را به ابزارهای تخصصی کدنویسی متصل می‌کند. این سیستم به‌صورت پیش‌فرض قابلیت‌های ارجاع به Claude Code و OpenCode را دارد و نیازی به نوشتن کدهای رابط (Glue Code) برای اتصال آن‌ها نیست.

برای اینکه سیستم روی یک لپ‌تاپ دانشجویی اجرا شود، این توسعه‌دهنده پیش‌فرض «اجرای محلی مدل‌های سنگین کدنویسی» را کنار گذاشت. به‌جای آن، از مدل Qwen3.6-35B-A3B برای مدیریت (Orchestration) استفاده کرد. این مدل از معماری ترکیب خبره‌ها (Mixture of Experts یا MoE) بهره می‌برد. اگرچه این مدل ۳۵ میلیارد پارامتر کل دارد، اما در هر توکن تنها حدود ۳ میلیارد پارامتر فعال هستند (که همان A3B است). این موضوع محاسبات مورد نیاز برای درک قصد کاربر و ارسال دستورات را به‌شدت کاهش می‌دهد. در واقع، درک قصد کاربر و توزیع دستورات، وظیفه‌ای بسیار کوچک‌تر از پیاده‌سازی کد است و با این تفکیک، مشکل سخت‌افزاری تا حد زیادی حل می‌شود. این استراتژی در راستای رویکردهای محلی‌محور برای کاهش تأخیر در چرخه‌های تکرار عامل‌هاست که بهره‌وری را در محیط‌های توسعه افزایش می‌دهد.

پشته سخت‌افزاری و نرم‌افزاری

زیرساخت سخت‌افزاری مورد استفاده شامل موارد زیر بود:

• GPU: مدل RTX 5070 Ti موبایل (۱۲ گیگابایت VRAM)
• RAM: ۳۲ گیگابایت
• CPU: Core Ultra 9 275HX
• OS: ویندوز به همراه WSL

برای جای دادن مدل ۳۵ میلیارد پارامتری در ۱۲ گیگابایت حافظه ویدیویی، از نرم‌افزار LM Studio با یک استراتژی تقسیم حافظه خاص استفاده شد:

• GPU Offload: لغزنده آف‌لود روی تمام لایه‌ها تنظیم شده است، اما مسیر توجه (Attention Path) برای حفظ پهنای باند روی GPU باقی می‌ماند.
• System RAM: نرم‌افزار LM Studio وزن‌های خبره‌ها برای ۳۲ لایه MoE را به حافظه رم سیستم (۳۲ گیگابایت) منتقل می‌کند. این تقسیم‌بندی است که اجازه می‌دهد یک مدل 35B در کنار ۱۲ گیگابایت VRAM جای بگیرد.
• Quantization: مدل از Unsloth GGUF با دقت UD-Q4_K_XL استفاده می‌کند.

این پیکربندی اجازه می‌دهد مدل از یک پنجره متنی (Context Window) بومی به اندازه ۲۶۲,۱۴۴ توکن استفاده کند. به دلیل استفاده از توجه خطی Gated DeltaNet در مدل Qwen3.6 برای اکثر لایه‌ها، این مدل به‌جای KV Cache که با طول توالی رشد می‌کند، از یک حالت (State) با اندازه ثابت استفاده می‌کند. تنها لایه‌های توجه استاندارد هزینه توکن پرداخت می‌کنند، به این معنی که هزینه حافظه در متون طولانی تنها کسری از چیزی است که یک مدل کاملاً متراکم (Dense) می‌طلبد. توسعه‌دهنده همچنین از کوانتیده کردن FP8 برای KV Cache استفاده کرده است. اگرچه سرعت این سیستم بالا نیست، اما ارسال یک دستور مدیریتی نیازی به سرعت خیره‌کننده ندارد.

لایه‌ی پیاده‌سازی

پس از آنکه مدیر محلی قصد کاربر را از طریق دیسکورد درک کرد، کار را به عامل‌های کدنویسی قدرتمندتر می‌سپارد. در این پروژه از دو ابزار استفاده شد:

• Claude Code (با استفاده از مدل Opus)
• OpenCode (با استفاده از مدل DeepSeek V4 Flash NEW)

از نظر هزینه، لایه‌ی مدیریت کاملاً رایگان است چون روی سخت‌افزار موجود اجرا می‌شود. لایه‌ی اجرا معمولاً پولی است، اما توسعه‌دهنده از سطح رایگان OpenCode Zen برای مدل DeepSeek V4 Flash NEW استفاده کرد. در نتیجه، کل این Pull Request بدون پرداخت حتی یک دلار هزینه API ثبت شد — شامل مراحل برنامه‌ریزی و پیاده‌سازی. البته توسعه‌دهنده اشاره می‌کند که این یک سطح تبلیغاتی (Promotional Tier) است و ممکن است برای همیشه باقی نماند. بخش ساختاری هزینه (سخت‌افزار) رایگان است، در حالی که بخش پیاده‌سازی (سطح رایگان Zen) موقتی است.

در یک مورد خاص، کاربر درخواست رفع مشکل شماره ۴۴ را داد. مدیر محلی ابتدا نام مالک مخزن را اشتباه حدس زد (سعی کرد به Aegis-MD/Aegis-MD متصل شود)، اما سریعاً آن را به PyaesoneP/Aegis-MD اصلاح کرد. سپس «حالت برنامه‌ریزی» (Plan Mode) OpenCode را فعال کرد. عامل ابتدا سه تصمیم طراحی مسدودکننده — از جمله تداخل نام بین year_published و publication_year و سؤالی درباره اینکه آیا Chroma می‌تواند فیلدهای لیستی را مستقیماً ذخیره کند یا خیر — را شناسایی کرد و آن‌ها را به‌صورت سؤال از کاربر پرسید تا پیش از نوشتن هر خط کد، پاسخ آن‌ها را دریافت کند. همین نکته که مدل به‌جای تصمیم‌گیری خاموش، سؤال می‌پرسد، تفاوت بین یک PR قابل بررسی در اتوبوس و یک کد خراب است. این رویکرد دقیق در برنامه‌ریزی، یادآور راهکارهای ابزاری مانند Planwright است که برای رفع گلوگاه‌های برنامه‌ریزی در عامل‌های کدنویس طراحی شده‌اند.

استقرار و شبکه

پیاده‌سازی این خط لوله نیازمند حل یک مشکل شبکه‌ای خاص در WSL (زیرسیستم ویندوز برای لینوکس) است. چون LM Studio روی ویندوز و Hermes در WSL اجرا می‌شوند، آن‌ها در فضاهای نام شبکه (Network Namespaces) متفاوتی قرار دارند. بنابراین، آدرس Localhost:1234 از داخل WSL به میزبان ویندوزی نمی‌رسد.

برای حل این مشکل، توسعه‌دهنده مراحل زیر را طی کرد:
۱. فعال‌سازی 'Serve on local network' و 'Enable CORS' در تب توسعه‌دهندگان LM Studio.
۲. ارجاع هرمس به IP شبکه محلی ماشین (مثلاً http://192.168.x.x:1234/v1) به‌جای localhost.
۳. باز کردن دسترسی LM Studio در فایروال ویندوز (Windows Defender Firewall) برای شبکه‌های خصوصی تا از مسدود شدن اتصالات ورودی جلوگیری شود.

تأیید اتصال بسیار حیاتی است. توصیه می‌شود از دستور curl http://192.168.x.x:1234/v1/models از داخل WSL استفاده کنید تا مطمئن شوید JSON حاوی ID مدل بازگردانده می‌شود. اگر دستور متوقف شد (Hang)، معمولاً مشکل از فایروال است؛ اگر اتصال رد شد (Refused)، سرور خاموش است یا IP اشتباه است. همچنین چون IPهای محلی با تجدید DHCP تغییر می‌کنند، این اولین جایی است که در صورت قطع شدن ناگهانی سیستم پس از یک هفته باید بررسی شود.

نصب و پیکربندی

• نصب هرمس: از طریق دستور curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash و سپس اجرای source ~/.bashrc. پیکربندی از طریق hermes setup و hermes model برای اتصال به اندپوینت سازگار با OpenAI انجام می‌شود. توسعه‌دهنده تأکید می‌کند که نباید از تأیید TUI پیش از انتقال به دیسکورد صرف‌نظر کرد.
• نصب عامل‌ها: نصب جهانی Claude Code و OpenCode از طریق دستورات npm install -g @anthropic-ai/claude-code و npm i -g opencode-ai@latest. همچنین نصب و احراز هویت GitHub CLI (gh) برای مدیریت ثبت PR الزامی است. دستورات تأیید شامل claude --version ، opencode auth list و gh auth status است.
• یکپارچگی با دیسکورد: ایجاد بات در پورتال توسعه‌دهندگان دیسکورد با فعال کردن 'Message Content Intent' (برای جلوگیری از دریافت متن خالی) و 'Server Members Intent' (برای شناسایی کاربران). بات با یک URL خاص OAuth2 و مجوزهای ۲۷۴۸۷۸۲۸۶۹۱۲ دعوت شد. همچنین باید Developer Mode در تنظیمات دیسکورد فعال باشد تا بتوان User ID را کپی کرد.
• امنیت: استفاده از hermes gateway setup برای تعریف DISCORD_ALLOWED_USERS. این مورد در نسخه‌های جدید اجباری است تا از رد شدن تمام پیام‌ها یا اجازه اجرای دستورات شل (Shell) روی میزبان توسط کاربران غیرمجاز جلوگیری شود. فایل .env با دستور chmod 600 ایمن شد و از کنترل نسخه (Version Control) دور نگه داشته شد. همچنین هشدار داده شده که LM Studio را Port-Forward نکنید زیرا هیچ سیستم احراز هویتی ندارد.
• مسیریابی اختیاری: متغیر DISCORD_HOME_CHANNEL را می‌توان برای مدیریت پیام‌های پیش‌کنشی (Proactive) تنظیم کرد که برای کارهای زمان‌بندی شده (Cron Jobs) یا اعلان‌های تکمیل کار مفید است.

نتیجه و چرخه بررسی

کل فرآیند از برنامه‌ریزی تا ثبت PR حدود ۴۰ دقیقه زمان برد. در این مدت، توسعه‌دهنده هیچ نظارتی بر ماشین نداشت و این زمان عملاً برای او «رایگان» بود چون در حین شیفت کاری بود. برای بررسی نهایی، او از حالت 'print mode' در Claude Code روی Diff تغییرات استفاده می‌کند تا پیش از تایید، آن‌ها را ببیند.

با این حال، این سیستم «بدهی بررسی» (Review Debt) را از بین نمی‌برد. در حالی که هوش مصنوعی می‌تواند یک Diff با ۶۳۰ خط اضافه و ۳۷ خط حذف تولید کند که ۴۱۷ تست را پاس می‌کند، بررسی چنین تغییری روی گوشی موبایل صرفاً یک نگاه گذرا (Skimming) است. توسعه‌دهنده فهرستی از موارد حساس (Do-not-touch list) مثل مهاجرت‌های دیتابیس، احراز هویت، به‌روزرسانی وابستگی‌ها و تنظیمات CI دارد که هرگز روی موبایل تایید نمی‌کند و فقط پشت میز بررسی می‌کند. در نهایت، خط لوله CI به عنوان دروازه‌بان اصلی عمل کرده و Branch Protection فعال است تا هیچ کدی بدون تایید انسانی ادغام نشود.

تحلیل: تغییر در محدودیت‌های توسعه‌دهنده

این معماری گلوگاه توسعه‌دهنده را از «سرعت کدنویسی» به «کیفیت تیکت» تغییر می‌دهد. وقتی پیاده‌سازی تقریباً رایگان و خودکار می‌شود، یک تیکت مبهم در گیت‌هاب منجر به یک PR با اطمینانِ غلط می‌شود. توسعه‌دهنده اشاره می‌کند که اکنون تیکت‌ها را با دقت بسیار بیشتری می‌نویسد تا چرخه‌های عامل را هدر ندهد.

چند مورد شکست احتمالی در این سیستم وجود دارد:

• خطاهای مدیریتی: مدل Qwen (در حالت ۴ بیتی) بیشترین قدرت تصمیم‌گیری را دارد. اگر قصد کاربر را اشتباه بفهمد، ممکن است بدون خطا، دستور غلط صادر کند. راهکار این است که مدل ابتدا تفسیر خود را تکرار کند (مثلاً: «در حال کار روی تیکت ۴۴، گسترش متادیتای تکه‌ها، شروع کنم؟») یا از یک واژگان دستوری ثابت استفاده شود تا خطاهای تجزیه (Parse) به‌وضوح نمایان شوند.
• کوری بررسی: Claude Code در تشخیص ناسازگاری‌های داخلی Diff خوب است، اما در تشخیص اینکه آیا کل رویکرد اشتباه است ضعیف است، زیرا از همان چارچوبی استفاده می‌کند که کد را تولید کرده است.
• وابستگی سخت‌افزاری: لپ‌تاپ باید همیشه روشن بماند؛ تنظیمات Sleep ویندوز اگر پیکربندی نشوند، می‌توانند کل جریان کاری را مختل کنند.

در سطح کلان، این پروژه مسیر «رایانش لبه برای مدیریت» (Edge Orchestration) را نشان می‌دهد. ثابت شد که برای اجرای یک جریان کاری عامل‌محور، نیازی به مدل‌های محلی عظیم نیست؛ بلکه فقط مدلی لازم است که بتواند قصد را درک کرده و API درست را فراخوانی کند. در اینجا «هوش» بین یک دیسپچر ارزان محلی و یک اجراکننده قدرتمند ابری توزیع شده است. این روش برای کسانی که زمان‌های کوتاه دور از سیستم دارند، پروژه‌ای با تیکت‌های شفاف دارند و به مجموعه تست‌های خود اعتماد می‌کنند، شدیداً توصیه می‌شود. بدون تست‌های خودکار، این سیستم صرفاً ماشینی برای تولید اشتباهات متقاعدکننده است.

گام بعدی شما

• اگر از LM Studio استفاده می‌کنید، قابلیت Serve on local network را برای اتصال به ابزارهای WSL تست کنید.
• برای کاهش هزینه API، لایه‌ی مدیریت را روی مدل‌های کوچک MoE مثل Qwen اجرا کنید و فقط برای پیاده‌سازی از مدل‌های Opus یا GPT-4 استفاده کنید.
• یک مجموعه تست (Test Suite) جامع بنویسید؛ بدون آن، استفاده از عامل‌های کدنویس ریسک تخریب پروژه را بالا می‌برد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و بهینه‌سازی استنتاج مراجعه کنید.