تصور کنید یک مهندس نرمافزار هستید که باید ۲۰ دقیقه منتظر بماند تا آموزش یک مدل تمام شود، اما نمیخواهد هر دو دقیقه یکبار فایل لاگ را چک کند. ابزار Monitor در Claude Code دقیقاً برای حذف همین انتظار خستهکننده طراحی شده است تا هوش مصنوعی را از یک پرسوجوگر فعال (Active Poller) به یک دریافتکنندهٔ غیرفعال (Passive Receiver) از رویدادهای سیستم در لحظه تبدیل کند. هدف اصلی این ابزار این است که نیاز توسعهدهندگان به بررسی دستی لاگها یا تنظیم تایمرهای دستوپاگیر در طول فرآیندهای طولانی را از بین ببرد.
این قابلیت در راستای تلاش گستردهتر برای ایجاد ابزارهای انتظار غیرهمزمان (Asynchronous Waiting Primitives) برای عاملهای هوش مصنوعی (AI Agents) — شبیه به دستیاری که میداند چه زمانی باید سکوت کند و چه زمانی خبر دهد — عرضه شده است. همانطور که در تحلیل قبلی ما دربارهی حذف اصطکاکهای دسترسی در VS Code اشاره کردیم، ابزار Monitor اکنون ضلع سوم مثلث مکانیسمهای انتظار را تکمیل میکند: اجرای پسزمینه Bash برای تکمیل کارهای یکباره، Cron برای محرکهای ساعتمحور و Monitor برای جریانهای مداوم رویداد.
سازوکار شنود رویدادمحور
به نقل از یک بررسی فنی عمیق منتشر شده در ۱ سپتامبر ۲۰۲۶ در وبسایت dev.to، ابزار Monitor بهعنوان یک شنوندهٔ داخلی جریان رویداد (Event-stream listener) عمل میکند. این ابزار مشکل تأخیر و اشغال پنجرهٔ زمینه (Context Window) — که مثل میز کاری است که فقط جای چند ورق کاغذ دارد و زود پر میشود — را در روشهای سنتی حل میکند. بهجای اینکه مدل هر چند دقیقه بپرسد «آیا کار تمام شد؟»، یک حسگر روی جریان داده قرار میدهد و منتظر میماند تا سیستم اعلان را ارسال کند.
این رویکرد تفاوت بنیادی در مدیریت زمان و رویدادها ایجاد میکند. در حالی که Cron ساعتمحور است — جایی که زمان طرف فعال است و میگوید «وقتی وقتش رسید از تو میپرسم» — ابزار Monitor رویدادمحور است. در این مدل، رویداد خارجی طرف فعال است و در واقع به Claude میگوید: «هر وقت اتفاقی افتاد، به من خبر بده».
ابزار Monitor از دو منبع داده اصلی پشتیبانی میکند:
- دستورات شل (Shell Commands): هر دستوری که در stdout بنویسد. هر خط جدید بهعنوان یک رویداد مجزا تلقی میشود. این ساختار بهطور طبیعی با قراردادهای یونیکس (Unix) همسو است، جایی که هر خط خروجی استاندارد یک اعلان محسوب میشود.
- وبساکتها (WebSockets): اتصال مستقیم به URLها (مانند
wss://events.example.com/stream) که نیاز به ابزارهای واسط و شکننده مانندwebsocatرا حذف کرده و نگاشت فریمها به رویدادها را استاندارد میکند. در این حالت، فریمهای متنی بهعنوان رویداد تلقی میشوند، در حالی که فریمهای باینری بهصورت[binary frame, N bytes]نمایش داده میشوند.
حل مسئلهٔ «پرسوجوی مکرر»
روشهای سنتی نظارت بر کارهای طولانی اغلب ناکارآمد هستند. یک دستور سادهی sleep آگاهی مدل را تا پایان زمانسنج مسدود میکند و باعث میشود شکستهای زودهنگام نادیده گرفته شوند. برای مثال، استفاده از دستور Bash(command: "sleep 1200 && cat train.log", timeout: 1300000) به این معناست که اگر پردازشی بعد از ۳ دقیقه شکست بخورد، Claude تا پایان ۲۰ دقیقه متوجه این موضوع نمیشود و در واقع در وضعیت کور باقی میماند.
از سوی دیگر، استفاده از یک Job در Cron برای چک کردن لاگ هر دو دقیقه، تأخیر قابل توجهی ایجاد کرده و با خواندن مکرر یک فایل، فضای گفتگو را هدر میدهد. دستوری مانند CronCreate(cron: "*/2 * * * *", recurring: true, prompt: "check train.log and report ERROR") باعث ایجاد تأخیری تا دو دقیقه شده و با هر بار بیدار شدن، حجم زیادی از زمینه (Context) را مصرف میکند زیرا مدل باید دوباره فایل را بخواند تا تغییرات را تشخیص دهد.
Monitor اینها را با مدل «پوش» (Push-based) جایگزین میکند. کاربر میتواند به Claude دستور دهد تا لاگ آموزش را برای کلمات کلیدی خاصی زیر نظر بگیرد، مثلاً با دستوری شبیه به این:
Monitor( command: "tail -f train.log | grep -E --line-buffered 'elapsed_steps=|Traceback|Error|FAILED|Killed|OOM'", description: "training log: progress and errors", timeout_ms: 1500000 )
در این حالت، محیط اجرا (Runtime) در پسزمینه لاگ را دنبال کرده و تنها خطوط منطبق را فوراً به گفتگو میفرستد. Claude میتواند به کارهای دیگر برسد و در عین حال، پیشرفت یا شکستها را بهصورت خودکار دریافت کند، بدون اینکه نیاز باشد مدام وضعیت را چک کند.
قوانین نظارت در سطح SRE
برای جلوگیری از غرق شدن مدل در حجم زیاد داده، Monitor اصول مهندسی قابلیت اطمینان سایت (SRE) را مستقیماً در پرامپت ابزار گنجانده است. یکی از قوانین سختگیرانه آن «سکوت به معنای موفقیت نیست» است. این بدان معناست که فیلترها باید بهگونهای طراحی شوند که نه تنها «مسیر موفقیت» (مانند مراحل پیشرفت)، بلکه حالتهای شکست نهایی مانند "Killed" یا "FAILED" را هم شکار کنند.
اگر یک مانیتور فقط منتظر elapsed_steps= باشد، در صورت کرش کردن یا هنگ کردن سیستم ساکت میماند و شکست از اجرای عادی قابل تشخیص نیست. سیستم از مدل میخواهد این سؤال را بپرسد: «اگر پردازش همین الان کرش کند، آیا فیلتر من چیزی خروجی میدهد؟»
محدودیتهای فنی اجرا شده در Runtime عبارتاند از:
- کنترل بافرینگ: ابزار کاربر را به استفاده از
--line-bufferedدر grep وfflush()در awk تشویق میکند تا اطمینان حاصل شود رویدادها بهدلیل بافرینگ یونیکس تأخیر نمیخورند. همچنین صراحتاً نسبت به استفاده ازheadهشدار میدهد، زیرا ممکن است پیش از تولید خروجی، منتظر N مورد تطبیق بماند و باعث تأخیر در اعلان شود. - محدودیت نرخ (Rate Limiting): اگر خروجی بیش از حد زیاد شود، Runtime بهطور خودکار مانیتور را متوقف میکند تا از نشست (Session) محافظت کند و از پر شدن سریع پنجره زمینه جلوگیری نماید. در این صورت Claude باید آن را با فیلتر دقیقتری مجدداً راهاندازی کند.
- دستهبندی (Batching): خطوطی که در بازه ۲۰۰ میلیثانیه میرسند، در یک اعلان تجمیع میشوند تا خوانایی خطاهای چندخطی (Tracebacks) حفظ شود و مدل با سیل اعلانهای تکخطی بمباران نشود.
- زمانهای انتظار (Timeouts): مانیتورهای غیرپایدار پیشفرض ۳۰۰,۰۰۰ میلیثانیه و حداکثر ۳,۶۰۰,۰۰۰ میلیثانیه (یک ساعت) اعتبار دارند.
نظارت پایدار در برابر تکمرحلهای
Claude Code بین کارهای موقت و دائمی تفاوت میگذارد. برای اعلانهای یکباره (مثلاً «وقتی بیلد آماده شد خبر بده»)، سیستم توصیه میکند از حلقههای Bash در پسزمینه استفاده شود، مانند: until grep -q "Ready" dev.log; do sleep 0.5; done.
استفاده از Monitor برای یک اعلان تکمرحلهای توصیه نمیشود، زیرا دستورات نامحدودی مانند tail -f ... | grep -m 1 "Ready" ممکن است بعد از یافتن نتیجه باز بمانند و مانیتور را تا پایان زمان انتظار متصل نگه دارند. Monitor برای رویدادهای مستمر بهینه شده است، نه برای تکمیل تکمرحلهای.
با این حال، برای نیازهای طولانیمدت مانند تغییر وضعیت PRها یا اشتراک در وضعیت استقرار (Deployment)، فیلد persistent: true اجازه میدهد مانیتور برای کل نشست فعال بماند و محدودیت یکساعته را نادیده بگیرد. این مانیتورها تنها با پایان نشست یا دستور صریح TaskStop متوقف میشوند.
طراحی فنی و طرحواره (Schema)
نام "Monitor" بهعنوان یک اصطلاح خنثی در SRE انتخاب شده تا مدل را به سمت «ایجاد نظارت و گزارش رویداد» سوق دهد، نه یک جستوجوی ساده و یکباره با grep. این ابزار از پنج فیلد خاص استفاده میکند:
- command: منبع شل (که با
wsمتقابلاً انحصاری است). - ws: منبع وبساکت شامل
urlوprotocols. - description: یک برچسب اجباری که در هر اعلان نمایش داده میشود.
- timeout_ms: پیشفرض ۳۰۰,۰۰۰ میلیثانیه؛ حداکثر ۳,۶۰۰,۰۰۰ میلیثانیه.
- persistent: پیشفرض false؛ اگر true باشد، مانیتور را برای کل نشست زنده نگه میدارد.
منطق و محدودیتهای زمان اجرا
فراتر از طرحواره، Runtime قوانین عملیاتی سختگیرانهای را برای تضمین پایداری اجرا میکند:
- انحصار منبع: دقیقاً یکی از
commandیاwsباید ارسال شود. ارائه هر دو یا هیچکدام منجر به شکست در اجرای ابزار میشود. - برچسبگذاری: فیلد
descriptionاجباری است زیرا در هر اعلان قابل مشاهده است و زمینه لازم را برای مدل فراهم میکند تا بداند هر رویداد چه معنایی دارد و مربوط به کدام فرآیند است. - منطق Timeout: یک مانیتور غیرپایدار نمیتواند از حد یک ساعت فراتر رود. اگر
persistent: trueتنظیم شود، مقدارtimeout_msبهطور کامل نادیده گرفته میشود زیرا مانیتور تا پایان نشست فعال میماند. - شفافیت شکست: سیستم بهگونهای طراحی شده که یک مانیتور معیوب نتواند بهصورت خاموش «سالم» به نظر برسد. شکستها «بلند» و واضح هستند تا مدل متوجه شود چه زمانی یک نظارت متوقف شده است و نیاز به اصلاح دارد.
تحلیل: تغییر پارادایم عاملها
این تغییر از مدل «کشیدن» (Pull) به «پوشیدن» (Push) یک تکامل حیاتی در هوش مصنوعی عاملمحور است. تقسیم مسئولیتها اکنون بهوضوح نقشهبرداری شده است:
- Bash background: منتظر میماند تا یک کار تمام شود؛ یکبار هنگام خروج از پردازش خبر میدهد.
- CronCreate: منتظر یک زمان خاص میماند؛ برای هر تطبیق با برنامه زمانبندی، یکبار خبر میدهد.
- Monitor: منتظر یک جریان رویداد میماند؛ برای هر خط stdout یا فریم وبساکت، یکبار خبر میدهد.
بیشتر عاملهای LLM فعلی در یک حلقه «درخواست-پاسخ» عمل میکنند، که آنها را برای ماهیت غیرهمزمان مهندسی نرمافزار در دنیای واقعی نامناسب میکند. با تبدیل یک خط stdout به یک محرک درجه اول، Anthropic در حال نزدیک کردن Claude به یک «دیمون سیستم» (System Daemon) واقعی است، نه صرفاً یک رابط چت.
برای توسعهدهنده، این بدان معناست که هوش مصنوعی اکنون میتواند کارهای «کمتوجه» (Low-attention) را مدیریت کند. شما میتوانید بخشهای کسالتبار SRE — مانند نظارت بر استقرار یک نسخه یا اجرای یک مجموعه تست — را به او بسپارید، با این اطمینان که مدل تنها زمانی شما را متوقف میکند که یک رویداد خاص و قابل اقدام رخ دهد. این امر بار شناختی ناشی از جابجایی مداوم بین ترمینال و هوش مصنوعی را کاهش میدهد.
منتظر بررسیهای آتی ما درباره مکانیسمهای پسزمینه باشید، جایی که جزئیات ادغام run_in_background در Bash، Agent و خانواده Task برای ایجاد یک معناشناسی غیرهمزمان یکپارچه در Claude Code را بررسی خواهیم کرد.
گام بعدی شما
- اگر از Claude Code استفاده میکنید، بهجای استفاده از
sleepدر دستورات Bash، ازMonitorبرای دنبال کردن لاگهای طولانی استفاده کنید. - فیلترهای grep خود را با
--line-bufferedبنویسید تا رویدادها را بدون تأخیر دریافت کنید. - برای نظارت بر وضعیت استقرار (Deployment) در طول یک روز کاری، از حالت
persistent: trueبهره ببرید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو