تصور کنید یک عامل هوش مصنوعی در تمام شبانه‌روز روی سرور شما کد می‌زند، اما شما در مترو هستید و نمی‌دانید آیا سیستم در ساعت ۹ شب واقعاً اجرا شده، در جایی گیر کرده است یا در حال بازنویسی تاریخچه گیت (git history) است. این «اضطراب پس‌زمینه» (Background Anxiety)، مانع اصلی بهره‌برداری کامل از عامل‌های خودکار است؛ وضعیتی که در آن حتی اگر عامل برای ماه‌ها به‌طور کامل و بی‌نقص عمل کرده باشد، نبود دید کافی در ساعات غیرکاری منجر به چک کردن‌های وسواسی و مداوم می‌شود.
به نقل از یک گزارش فنی در ۱۰ ژوئیه ۲۰۲۶ در وب‌سایت dev.to، یک توسعه‌دهنده با تغییر مدل تعامل از «دسترسی به ترمینال» به «مدیریت صف پیام»، راهکاری برای کنترل Claude Code روی یک مک مینی (Mac mini) ابداع کرده است. او متوجه شد که برای مدیریت عامل (Agent) — سیستمی که تکالیف را می‌گیرد، کد می‌نویسد، کارهای خود را تأیید می‌کند و در نهایت کامیت (commit) می‌کند و تمام این‌ها را طبق یک برنامه زمانی در روز و شب انجام می‌دهد — نیازی به محیط متنی سخت نیست، بلکه تنها به سه قابلیت نیاز دارد: یک «نگاه سریع» (Glance) ۵ ثانیه‌ای به فعالیت جاری، یک «تکان» (Nudge) برای ارسال فرمان‌های ایمن (مانند توقف یا اجرای تست‌ها) و توانایی «رها کردن سیستم» و دریافت نتیجه از طریق اعلان.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، هرگونه دسترسی مستقیم و باز به محیط اجرای کد، ریسک‌های امنیتی و خطاهای انسانی را افزایش می‌دهد. در این پروژه، توسعه‌دهنده ابتدا سعی کرد این مشکل را با SSH و ابزارهایی مثل Tailscale حل کند که یک شبکه Mesh مبتنی بر WireGuard بدون نیاز به پیکربندی برای در دسترس نگه داشتن مک مینی فراهم می‌کند. اما او به این نتیجه رسید که کیبورد تلفن‌های همراه اساساً با محیط‌های شل (Shell) دشمن هستند. برای مثال، تصحیح خودکار کلمات (Autocorrect) در گوشی، دستور git log --oneline را به شکلی غلط با استفاده از یک em dash به git log —oneline تغییر می‌دهد. علاوه بر این، هنگام جابجایی بین ایستگاه‌های مترو، نشست‌های (Sessions) ارتباطی به‌طور مداوم قطع می‌شوند. حتی با وجود tmux که نشست‌ها را ذخیره می‌کند، اسکرول کردن در یک صفحه ۶ اینچی بسیار دشوار و دردناک است. در یک مورد، توسعه‌دهنده ساعت ۲ صبح به‌طور تصادفی دستوری را در پنل tmux مربوط به عامل تایپ کرد به‌جای اینکه در شل خودش بنویسد و این باعث شد عامل ۲۰ دقیقه وقتش را تلف کند تا سعی کند روی یک متن بی‌معنی (gibberish) اقدام کند.
برای حل این مشکل، او یک لایه کنترل از راه دور ساخت که تلفن را به‌جای یک ترمینال، به عنوان یک «صندوق ورودی» می‌بیند. این معماری باعث می‌شود هیچ پورت بازی روی سخت‌افزار خانه نباشد و قطعی شبکه در مسیر، خللی در پیشرفت عامل ایجاد نکند. این رویکرد یادآور تغییر پارادایم در ابزارهایی است که به‌جای چت‌های پراکنده، بر مدیریت ساختاریافته‌ی Pull Requestها در فضای ابری تمرکز کرده‌اند تا کنترل دقیق‌تری بر خروجی کدنویسی ایجاد شود.
معماری سه‌لایه سیستم
این سیستم بر پایه یک طراحی «ساده/خسته‌کننده» اما مستحکم است:
- لایه انتقال: یک کانال پیام‌رسان خصوصی مانند بات تلگرام، یک کانال خصوصی دیسکورد یا حتی ایمیل به عنوان رابط عمل می‌کند. تلفن با این «صندوق ساده» صحبت می‌کند و سرور از طریق API پیام‌ها را می‌خواند (Poll می‌کند). این یعنی حتی در وای‌فای‌های محدود هتل که همه چیز به‌جز HTTPS مسدود است، سیستم کار می‌کند چون تلفن هرگز مستقیماً با عامل صحبت نمی‌کند.
- دمون ناظر (Watcher Daemon): یک اسکریپت ۱۰۰ خطی با زبان پایتون ۳.۱۳ که تحت مدیریت launchd در مک مینی اجرا می‌شود. این اسکریپت هر ۳۰ ثانیه پیام‌های جدید را از صندوق ورودی چک کرده، آن‌ها را با یک «لیست مجاز» (Allowlist) سخت‌گیرانه می‌سنجد و به‌صورت فایل‌های JSON در یک پوشه می‌نویسد.
- صف دستورات: به‌جای استفاده از ابزارهای پیچیده و سنگین مثل Redis یا RabbitMQ، از یک دایرکتوری شامل فایل‌های JSON استفاده شده است. سیستم از بازنام‌گذاری اتمیک (Atomic Rename) در پوشه‌های
inbox/،processing/وdone/برای مدیریت قفل کردن تسک‌ها و اجرای آن‌ها استفاده می‌کند.
جزئیات پیاده‌سازی
منطق ناظر
دمون پایتون از یک نگاشت (Mapping) خاص برای دسته‌بندی دستورات استفاده می‌کند. اگر دستوری در مجموعه ALLOWED_COMMANDS نباشد، سیستم پیام «دستور ناشناخته» (Unknown command) می‌فرستد و گزینه‌های در دسترس را پیشنهاد می‌دهد. برای اقدامات تخریبی یا حساس، یک جریان تأیید فعال می‌شود: دستور ابتدا در وضعیت «در انتظار» (Pending) قرار می‌گیرد و کاربر باید ظرف ۶۰ ثانیه آن را دوباره ارسال کند تا تأیید شود. این کار از اجرای یک اقدام پرریسک بر اثر یک ضربه تصادفی روی صفحه گوشی جلوگیری می‌کند.
مکانیزم صف
وقتی حلقه اصلی عامل به یک نقطه توقف طبیعی بین تسک‌ها می‌رسد، پوشه inbox/ را چک می‌کند. اگر فایلی مانند 2026-07-10T13-42-01_run-tests.json پیدا کند، آن را به processing/ منتقل می‌کند تا تسک قفل شود. این بازنام‌گذاری اتمیک در یک سیستم‌فایل واحد، یک مکانیزم قفل رایگان فراهم می‌کند. پس از اجرا، نتیجه در پوشه done/ نوشته می‌شود.
یک فایل JSON نتیجه معمولی شامل موارد زیر است:
- نام دستور
- برچسب‌های زمانی شروع و پایان (مثلاً از
2026-07-10T13:42:31+09:00تا13:44:02+09:00) - وضعیت موفقیت (
ok: true) - یک خلاصه (مثلاً: "142 passed, 0 failed, 3 skipped (91s)")
ناظر این فایل جدید را در done/ می‌بیند، خلاصه را فرمت کرده و آن را به کانال پیام‌رسان می‌فرستد. کل زمان رفت و برگشت برای دستوری مثل run-tests حدود دو دقیقه است که در این مدت کاربر هیچ زمانی را صرف خیره شدن به ترمینال نمی‌کند.
میان‌بر وضعیت
دستور status ده برابر بیشتر از مجموع تمام دستورات دیگر ارسال می‌شود. برای اینکه پاسخ آن فوری باشد، عامل به‌طور مداوم فایلی به نام status.json را به‌روز می‌کند که شامل تسک جاری، آخرین ضربان قلب (heartbeat)، تسک‌های تکمیل شده امروز و آخرین خطا است. ناظر این فایل را مستقیماً می‌خواند و با دور زدن صف، پاسخ را در کمتر از یک ثانیه می‌فرستد.
مثال خروجی وضعیت:
- ▶ در حال کار روی: بازنویسی منطق تلاش مجدد در تست‌های زمان‌بند (refactor retry logic in scheduler tests)
- ⏱ ضربان قلب: ۱۲ ثانیه پیش
- ✅ امروز: ۴ تسک انجام شد، ۰ شکست
اگر ضربان قلب بیشتر از ۱۰ دقیقه باشد، ناظر به‌طور خودکار آن را علامت‌گذاری می‌کند؛ مکانیزمی که تا کنون منجر به شناسایی دو مورد هنگ واقعی سیستم شده است که در صورت نبود این سیستم، ساعت‌ها نادیده می‌ماندند.
حفاظ‌ها و طراحی مبتنی بر قصد (Intent-Based)
یک ویژگی حیاتی این است که کاربر نمی‌تواند رشته‌های متنی دلخواه (Arbitrary strings) به عامل بفرستد. هر دستور یک «قصد» (Intent) نام‌گذاری شده با سطح ریسک مشخص است:
- فقط خواندنی (ریسک:
read| نیازمند تأیید:False): دستوراتstatusوlog-tail. - اجرا (ریسک:
exec| نیازمند تأیید:False): دستورrun-tests. - اجرا با ریسک (ریسک:
exec| نیازمند تأیید:True): دستورretry-last. - تغییر وضعیت (ریسک:
state| نیازمند تأیید:False): دستوراتpauseوresume. - تخریبی (ریسک:
write| نیازمند تأیید:True): دستورrollback(که نیاز به تأیید دو مرحله‌ای ظرف ۶۰ ثانیه دارد).
درس‌های مهندسی برای کنترل هوش مصنوعی
توسعه‌دهنده این پروژه ۵ درس کلیدی را استخراج کرد:
۱. به‌جای ترمینال، صندوق ورودی بسازید: کنترل از راه دور یک عامل خودکار ذاتاً ناهمزمان (Asynchronous) است. مدل «ارسال و فراموش» (Fire-and-forget) همراه با یک اعلان در پایان، در هر سناریوی موبایلی برتر از ترمینال زنده است. او اعتراف کرد که هفته‌ها وقتش را تلف کرد تا SSH را در موبایل ارگونومیک کند، پیش از آنکه بفهمد مدل تعاملی اشتباه است.
۲. دستورات باید «قصد» باشند، نه «رشته متنی»: یک مجموعه بسته از قصد‌های نام‌گذاری شده، جلوی غلط‌های املایی، تغییرات مخرب تصحیح خودکار و ریسک‌های ناشناخته را می‌گیرد. لیست مجاز در عمل هرگز محدودکننده نبود. اگر تسکی نیاز به یک دستور خام شل داشته باشد، این نشانه آن است که تسک باید تا زمانی که کاربر پشت یک کیبورد واقعی باشد، منتظر بماند.
۳. عملیات خواندنی را رایگان و فوری کنید: ارائه وضعیت از طریق یک فایل به‌جای صف، باعث می‌شود مورد رایج (Common case) بدون ریسک باشد. مشاهده‌پذیری ارزان و سریع به‌طور فعال از دخالت‌های خطرناک جلوگیری می‌کند، زیرا کاربر احساس نیاز کمتری به مداخله می‌کند.
۴. بازبینی هر ۳۰ ثانیه کافی است: برای تسک‌هایی که دقایق زمان می‌برند، تأخیر ۳۰ ثانیه‌ای ناچیز است. حلقه بازبینی حدود ۴۰ خط کد است، به‌طور ساختاری در برابر قطعی‌های شبکه مقاوم است و هیچ نیازی به نگهداری ندارد. برای ابزاری تک‌کاربره، تحمل تأخیر یک هدیه است.
۵. حفاظ‌ها برای شما هستند، نه برای مدل: جریان‌های تأیید در درجه اول برای محافظت در برابر «اشتباهات لمسی» یا تصمیمات ساعت ۲ صبح کاربر است که صبحگاه پشیمان شود. عامل دترمینستیک و پیش‌بینی‌پذیر است؛ اما انسانی که ساعت ۲ صبح با تلفن در دست است، این‌طور نیست.
این چرخش از «دسترسی به شل» به «ارسال قصد»، مدل ذهنی ارکستراسیون عامل را تغییر می‌دهد. این کار اپراتور را از حالت مدیریت جزئیات (Micro-manager) به یک نقش نظارتی سطح بالا منتقل کرده و بار شناختی حفظ یک خط لوله خودکار ۲۴/۷ را کاهش می‌دهد. در کنار این کنترل‌های عملیاتی، مدیریت هزینه‌های جاری نیز حیاتی است؛ برای instance، استفاده از لایه‌های حفاظتی مانند AI CostGuard می‌تواند از انفجار هزینه‌ها در عامل‌های همیشه فعال جلوگیری کند.
نقشه راه آینده
در نسخه‌های آتی، موارد زیر فراتر از بازبینی ساده (Polling) اضافه خواهند شد:
- اعلان‌های مبتنی بر شکست: ارسال نوتیفیکیشن‌های فعال برای تسک‌های شکست‌خورده به همراه گزینه یک‌ضربه برای
retry-lastتا سیستم از حالت «کشیدن» (Pull) به حالت «فشار» (Push) حرکت کند. - گزارش‌های روزانه: یک خلاصه شبانه از دستاوردهای روزانه عامل برای کاهش تعداد چک‌های دستی وضعیت از ۶ بار در روز به ۱ بار.
- تفاوت‌های تصویری (Image-based diffs): رندر کردن خلاصه‌های تغییرات کد (Diff) به‌صورت تصاویر، که در صفحات موبایل بسیار خواناتر از متن‌های خام مارک‌داون هستند.
نکته قابل توجه این است که توسعه‌دهنده صراحتاً از افزودن دسترسی مستقیم به شل (Shell passthrough) یا یک داشبورد کامل وب خودداری کرد؛ او به این درس پایبند است که محدود کردن قصدها یک «قابلیت» است، نه یک «محدودیت». هر بار که وسوسه می‌شود ویژگی‌های جدید اضافه کند، درس دوم را مجدداً می‌خواند.
نتیجه‌گیری
اگر هرگونه عامل هوش مصنوعی طولانی‌مدت را اجرا می‌کنید، این توسعه‌دهنده توصیه می‌کند نسخه «ساده و خسته‌کننده» این سیستم را بسازید: یک فایل وضعیت، یک لیست مجاز و یک پوشه از فایل‌های JSON. این کار معمولاً یک بعدازظهر زمان می‌برد اما اضطراب مبهم پس‌زمینه را به یک نگاه ساده به تلفن تبدیل می‌کند. شما می‌توانید با نگاشت متداول‌ترین بررسی‌های عامل خود به یک سیستم محرک ساده مبتنی بر JSON در سرور محلی، پیاده‌سازی چنین پوششی را آغاز کنید. در این مسیر، بهینه‌سازی مصرف توکن‌ها نیز اهمیت دارد؛ برای مثال راهکارهای حذف تورم متنی در سامانه‌هایی مانند Headroom AI نشان می‌دهد چگونه می‌توان هزینه‌های عملیاتی عامل‌های هوشمند را به‌شدت کاهش داد.
گام بعدی شما
- اگر عامل‌های کدنویس را روی سرور اجرا می‌کنید، به‌جای SSH، یک فایل
status.jsonساده بسازید که هر چند ثانیه به‌روز شود. - دستورات متداول خود را در یک لیست مجاز (Allowlist) تعریف کنید تا از خطاهای تایپی در موبایل جلوگیری شود.
- برای عملیات حساس (مانند حذف یا بازگردانی)، مکانیزم تأیید دو مرحله‌ای با فاصله زمانی کوتاه پیاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو