تصور کنید تیمی از برنامه‌نویسان دارید که هر کدام روی پروژه‌ای متفاوت کار می‌کنند، اما همگی از یک دستیار هوش مصنوعی مشترک استفاده می‌کنند که حافظه‌اش به‌سرعت با تداخل اطلاعات به‌هم‌ریخته می‌شود. QM — که در ۳۱ ژوئیه ۲۰۲۶ توسط شرکت YC Software عرضه شد — با اختصاص یک فضای کاری ایزوله به هر کارمند که تداخلی با دیگران ندارد، این هرج‌ومرج را متوقف می‌کند.
بیشتر عامل‌ها (Agents) در حال حاضر مانند دستیاران شخصی عمل می‌کنند. اما وقتی این ابزارها در مقیاس یک استارتاپ به کار می‌روند، مدیریت یک «مغز شرکتی» مشترک در کنار نیازهای فردی کاربران، باعث ایجاد تداخلی آشفته در دسترسی‌ها و حافظه می‌شود. QM این لایه‌ها را از هم جدا می‌کند تا کاربران بتوانند هم به‌صورت مستقل کار کنند و هم در کانال‌های مشترک Slack، پیام‌های گروهی و پروژه‌های مشترک با یکدیگر تعامل داشته باشند.
به نقل از مخزن گیت‌هاب این پروژه، سیستم برای هر شخص و هر اتاق گفتگو، یک حافظه محدوده (Scoped Memory)، نمای کلیدها (Keychain view)، مجوزها، کرون‌ها (Crons)، وب‌اپلیکیشن‌ها و یک ساندباکس (Sandbox) — شبیه به یک اتاقک آزمایش امن که هر اتفاق در آن به محیط بیرون آسیبی نمی‌زند — دائمی فراهم می‌کند. این ساختار تضمین می‌کند که اقدامات یک عامل در یک پروژه، به پروژه‌ای دیگر نفوذ نکند و دقیقاً مشابه سازمان‌دهی واقعی توسعه‌دهندگان در محیط‌های کاری باشد.
هسته فنی و معماری
معماری این سیستم بر یک هسته بدون رابط کاربری (Headless) متکی است که با زبان TypeScript روی Node ساخته شده و از Fastify برای ارتباطات HTTP استفاده می‌کند. هر چرخه عملیاتی (Turn) از این هسته مرکزی عبور می‌کند که می‌تواند بدون وابستگی به یک فروشنده خاص (Vendor Lock-in)، بین مدل‌ها و هارنس‌های مختلف جابه‌جا شود. درایورهای پشتیبانی‌شده شامل Pi، OpenCode، Codex و Claude Code هستند که همگی یک هسته واحد را به حرکت درمی‌آورند.
- پایداری داده‌ها (Persistence): یک لایه Postgres داده‌های کاربر، تاریخچه جلسات، صف‌ها و سایر وضعیت‌های دائمی را مدیریت می‌کند.
- اجرا (Execution): عامل از یک سطح ابزار محدود و ثابت استفاده می‌کند. ابزار اصلی
executeاست که دستورات را در یک کامپیوتر ایزوله، دائمی و مختص به آن محدوده اجرا می‌کند؛ جایی که ابزارهای نصب‌شده، حتی پس از اتمام جلسه، روی سیستم باقی می‌مانند. - رابط‌های کاربری (Interfaces): رابط وب (ساخته شده با Vite و رندر شده با Lit)، پنل مدیریت و پورتال عمومی، همگی پلاگین‌های اختیاری هستند که بر روی API هسته قرار می‌گیرند. Slack نیز یک پلاگین داخلی است که توسط هسته از طریق یک کلاینت سرویس مستقیم با استفاده از Bolt استارت زده و نظارت می‌شود.
کنترل سازمانی و مهارت‌ها
مدیران می‌توانند پیکربندی‌های سطح سازمان و وضعیت امنیتی (Security Posture) را تعیین کنند و تصمیم بگیرند کدام مدل‌ها و هارنس‌های خاص برای تیم در دسترس باشند. این سیستم از «مهارت‌های مشترک» پشتیبانی می‌کند؛ توانایی‌هایی که متعلق به یک محدوده خاص هستند اما می‌توان دسترسی به آن‌ها را از طریق اعطای مجوز (Grant) به دیگران منتقل کرد. مدیران می‌توانند این مهارت‌ها را به کل سازمان تعمیم دهند یا بسته‌های مهارت (Skill packs) را از مخازن گیت وارد کنند.
کارهای پس‌زمینه از طریق سیستم‌های زمان‌بندی (Crons) و نظارت‌ها (Watches) مدیریت می‌شوند تا عامل‌ها بتوانند حتی زمانی که هیچ انسانی نظارت نمی‌کند، وظایف خود را انجام دهند. این هویت و پیکربندی به‌طور یکپارچه و بدون گسست بین Slack و اپلیکیشن وب منتقل می‌شود.
کاربردهای عملی
بر اساس مستندات QM، به دلیل حافظه محدوده‌بندی شده و قابلیت‌های ادغام، این ابزار در موارد زیر کاربرد دارد:
- جست‌وجوی هم‌زمان در یادداشت‌های داخلی، ایمیل‌ها، اسناد، پایگاه‌های داده و وب برای استخراج اطلاعات از «مغز شرکت».
- ساخت اپلیکیشن‌های وب داخلی سفارشی، انتشار آن‌ها برای افراد خاص و به‌روز نگه داشتن داده‌های مرتبط.
- یادگیری لحن نوشتاری کاربر از پیام‌های ارسال‌شده در گذشته برای دسته‌بندی اینباکس‌ها طبق یک برنامه زمانی، شامل تولید برچسب‌ها (Labels) و پیش‌نویس پاسخ‌ها.
- کار در مخازن کد موجود برای اجرای تست‌ها، باز کردن PRها، نظارت بر CI و بررسی لاگ‌های سیستم.
- ردیابی یک پروژه در یک کانال مشترک از طریق ارسال به‌روزرسانی‌ها و پیگیری‌های بعدی.
وضعیت‌های امنیتی
QM از رویکرد عامل‌های کدنویسی محلی مانند OpenCode، Codex و Claude Code پیروی می‌کند: عامل دقیقاً همان‌طور عمل می‌کند که کاربرش عمل می‌کند و از اعتبارنامه‌ها و مجوزهای خاص او استفاده می‌کند. تمام اقدامات مورد بازرسی (Audit) قرار می‌گیرند. نویسندگان سیستم سه وضعیت امنیتی را برای مدیریت ریسک تعریف کرده‌اند:
۱. سخت‌گیرانه (Strict): هر فراخوانی ابزار توسط هارنس، برای تأیید انسانی متوقف می‌شود؛ به استثنای دو مورد «پایان‌دهنده چرخه» (Turn enders) که تأثیری بر سیستم ندارند.
۲. خودکار (Auto): حالت پیش‌فرض است؛ یک طبقه‌بندی‌کننده (Classifier)، داده‌های خارجی با برچسب منشأ و نتایج ابزارها را قبل از رسیدن به مدل غربال می‌کند. استقرارهای مختلف می‌توانند این مورد را به یک پروکسی غربالگری سفارشی متصل کنند.
۳. خطرناک (Dangerous): هیچ غربالگری محتوایی یا توقفی بین فراخوانی ابزارها وجود ندارد.
صرف‌نظر از وضعیت انتخابی، یک «سیاست دستوری پیش‌تعریف‌شده» (Predeclared command policy) اعمال می‌شود. این شامل قوانین تأیید و ممنوعیت‌های سخت برای اقدامات مخرب، مانند حذف‌های بازگشتی (Recursive deletes) یا دستورات تخریب‌گر SQL است. مدل‌های دقیق تهدید و مفروضات اپراتور در فایل SECURITY.md نگهداری می‌شوند.
استقرار و شخصی‌سازی
استقرار QM از طریق یک رابط خط فرمان (CLI) انجام می‌شود که یک «مهارت استقرار» (Deployment skill) را ایجاد می‌کند. این فرآیند اپراتور را در مراحل زیر راهنمایی می‌کند: زیرساخت، ورود به وب، اعتبارنامه‌های اتصال‌دهنده، دسترسی اختیاری به Slack و تأیید زنده. برای راه‌اندازی اولیه نیازی به دریافت کد منبع (Source checkout) نیست. سیستم در حساب ابری خود اپراتور اجرا می‌شود و از مقاصدی مانند AWS یا Fly.io پشتیبانی می‌کند. مقداردهی اولیه باعث ایجاد CI برای استقرار نمی‌شود و مخزن هیچ گردش‌کار استقرار تولیدی (Production deployment workflow) ندارد.
برای سازمان‌هایی که کنترل مهندسی عمیق‌تری می‌خواهند، توسعه‌دهندگان روش «فورک خصوصی» (Private fork) را توصیه می‌کنند. این یک مخزن خصوصی مستقل است که از طریق یک کلون ساده (Clone) ایجاد می‌شود و نه از طریق دکمه Fork گیت‌هاب. این کار از چندین مشکل جلوگیری می‌کند:
- قابلیت مشاهده: فورک‌های گیت‌هاب، قابلیت مشاهده عمومی منبع اصلی را به ارث می‌برند؛ اما یک کلون ساده می‌تواند خصوصی ساخته شود.
- حریم خصوصی: فورک‌ها یک شبکه اشیاء مشترک دارند؛ کامیت‌های ارسال شده به یک فورک ممکن است از طریق SHA از سمت عمومی قابل دریافت باشند. یک کلون ساده این ریسک را حذف می‌کند.
در این ساختار، مهندسان شخصی‌سازی‌های خود را در مسیر deploy/layers/<org>/ — شامل پیکربندی‌ها، ابزارهای ساندباکس، مهارت‌ها و تصاویر پلاگین — نگه می‌دارند، در حالی که هسته را به‌صورت بایت-به-بایت با منبع اصلی (Upstream) یکسان نگه می‌دارند. این کار تضمین می‌کند که ادغام‌ها (Merges) کوچک باقی بمانند. دو مهارت خاص این مرز را حفظ می‌کنند: update-qm تغییرات منبع اصلی را در فورک ادغام می‌کند و upstream-pr اصلاحات عمومی را پس از پاک‌سازی شناسه‌های سازمانی، به پروژه اصلی باز می‌گرداند.
این چرخش به سمت «چندنفره کردن» (Multiplayer) ابزارهای عامل‌محور نشان می‌دهد که مرحله بعدی پذیرش هوش مصنوعی، نه در پرامپت‌های بهتر، بلکه در محدوده‌بندی (Scoping) بهتر است. با تبدیل عامل به یک زیرساخت با سیستم فایل دائمی به جای یک پنجره چت، AI به یک همکار قابل‌اعتماد با میز کار و حافظه مستقل تبدیل می‌شود.
گام بعدی شما
- اگر تیمی از توسعه‌دهندگان را مدیریت می‌کنید، بررسی کنید که آیا ابزار فعلی شما باعث تداخل زمینه‌های متنی (Context) می‌شود یا به یک سیستم ایزوله‌ای مانند QM نیاز دارید.
- مخزن گیت‌هاب QM را بررسی کنید تا با متدولوژی «فورک خصوصی» برای حفظ امنیت داده‌های سازمانی آشنا شوید.
- مدل‌های مختلف مانند Claude Code یا OpenCode را در بستر QM تست کنید تا نقاط قوت هر یک در محیط ایزوله را بسنجید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو