درون سازوکار Claude Code؛ حذف توقف‌های مکرر در اجرای بلندمدت

تصور کنید ساعت ۱۰ شب یک مهندس نرم‌افزار در شرکت Nuro یک عامل هوش مصنوعی را روی یک تسک پیچیده کدنویسی رها کند و صبح ساعت ۵ با سه Pull Request آماده، تست‌شده و تکمیل‌شده بیدار شود. این سناریو دیگر یک تخیل نیست، بلکه نتیجه‌ی معرفی حالت Auto Mode در Claude Code توسط شرکت Anthropic است. این قابلیت به عامل اجازه می‌دهد تا در مقایسه با تنظیمات پیش‌فرض قبلی، ۹ برابر بیشتر بین مداخلات انسانی به طور مداوم کار کند. این تحول در واقع تکامل قابلیت‌هایی است که پیش‌تر در نقشه راه آنتروپیک برای تبدیل Auto Mode به حالت پیش‌فرض پیش‌بینی شده بود.

به نقل از Anthropic، گلوگاه اصلی در استفاده از عامل‌های کدنویسی، نه لزوماً هوش، پنجره‌های متنی بزرگتر یا درک عمیق‌تر از مخازن کد، بلکه «پرامپت‌های اجازه» (Permission Prompts) بود؛ یعنی نیاز مداوم و خسته‌کننده به تایید انسان برای هر عملیات ساده از خواندن یک فایل و ویرایش آن گرفته تا اجرای یک تست یا نصب یک وابستگی. همان‌طور که در تحلیل قبلی ما درباره‌ی شکاف کارایی بین Vercel eve و Claude Code اشاره کردیم، تمرکز اکنون از تعداد گام‌های برداشته شده به «تداوم اجرا» (Continuity of Execution) تغییر یافته است.

سقف پنهان در تاییدات دستی

برای مدت‌ها تصور می‌شد سقف پیشرفت عامل‌های کدنویسی در توانایی استدلال یا درک ساختار مخازن بزرگ است، اما یک سقف پنهان وجود داشت: فرکانس توقف‌ها. در یک گردش‌کار معمولی، عامل برای هر مرحله نیاز به تایید داشت: خواندن فایل، ویرایش فایل، اجرای تست، نصب یک Dependency، ایجاد یک Branch، Commit کردن و در نهایت Push کردن.

داده‌های آنتروپیک نشان می‌دهد کاربران ۹۳٪ از این درخواست‌های اجازه را تایید می‌کنند. این درصد بسیار بالا نشان می‌دهد که این پرامپت‌ها دیگر به عنوان ابزارهای کنترل امنیتی جدی عمل نمی‌کنند، بلکه تبدیل به وقفه‌هایی عادت‌گونه (Muscle-memory interruptions) شده‌اند. این وقفه‌ها محدودیتی سخت برای استقلال عامل ایجاد می‌کنند؛ یک عامل نمی‌تواند در حالی که توسعه‌دهنده در خواب است کار کند، اگر در ساعت ۱۰:۰۷ شب برای تایید یک مجموعه تست متوقف شود. همچنین نمی‌تواند سه جریان کاری موازی را مدیریت کند اگر هر کدام هر چند دقیقه یک‌بار نیاز به توجه داشته باشند، و نمی‌تواند برای هفت ساعت روی بهبود یک متریک ارزیابی کار کند اگر یک درخواست شبکه روتین، حلقه را بعد از تکرار دوم متوقف کند.

سازوکار Auto Mode: فراتر از نادیده گرفتن اجازه

حالت Auto صرفاً اجازه ها را حذف یا نادیده نمی‌گیرد. در عوض، تصمیمات مربوط به تاییدات روتین را به یک مدل طبقه‌بندی (Classifier) مجزا می‌سپارد که اقدامات پیشنهادی را پیش از اجرا ارزیابی می‌کند. این معماری دو لایه امنیتی اصلی را معرفی می‌کند:

• کاوش لایه ورودی (Input-Layer Probe): یک اسکن سمت سرور که تلاش‌های تزریق پرامپت (Prompt Injection) را در نتایج ابزارها (مانند فایل‌های README، بدنه Issueها، صفحات وب یا خروجی‌های شل) شناسایی می‌کند. این لایه به عامل هشدار می‌دهد که محتوا را نامعتبر بداند و دوباره بر روی درخواست واقعی کاربر متمرکز شود.
• طبقه‌بندی لایه خروجی (Output-Layer Classifier): یک مدل «نابینا نسبت به استدلال» (Reasoning-blind) که فراخوانی ابزار پیشنهادی را با درخواست اصلی کاربر می‌سنجد. این مدل متون متقاعدکننده‌ی خودِ عامل و نتایج خام ابزارها را حذف می‌کند تا از این احتمال که عامل با «صحبت کردن» و متقاعد کردن بازبین، او را به یک اقدام ریسکی سوق دهد، جلوگیری کند.

این طبقه‌بندی از یک مسیر تصمیم‌گیری مشخص پیروی می‌کند: ابتدا قوانین صریح بررسی می‌شوند (قوانین منع یا Deny مسدود می‌کنند، قوانین درخواست یا Ask پرامپت می‌فرستند و قوانین اجازه محدود یا Narrow Allow تایید می‌کنند). ابزارهای Read-only و ویرایش‌های داخل پروژه معمولاً برای جلوگیری از تأخیر (Latency) سریعاً عبور می‌کنند. اما اقدامات با ریسک بالاتر — مانند دستورات شل، عملیات شبکه، یکپارچگی‌های خارجی و تفویض کار به زیر-عامل‌ها (Subagents) — تحت نظارت شدید قرار می‌گیرند. اگر اقدامی مسدود شود، کلود می‌تواند روشی ایمن‌تر را امتحان کند. با این حال، مسدود شدن‌های مکرر یک سیستم توقف (Backstop) را فعال می‌کند: سه بار مسدود شدن متوالی یا در مجموع ۲۰ بار مسدود شدن، باعث توقف Auto Mode و بازگشت کنترل به انسان می‌شود. برای مدیریت دقیق‌تر این توقف‌ها و جلوگیری از تخریب کد در مراحل حساس، مکانیزم Plan Mode به عنوان یک ترمز دستی عمل می‌کند تا پیش از اجرای خودکار، نقشه راه تغییرات تایید شود.

مقایسه حالت‌های دسترسی

Claude Code بسته به سطح اعتماد و نوع تسک، حالت‌های مختلفی ارائه می‌دهد:

• Manual (پیش‌فرض): خواندن فایل‌ها خودکار است؛ اما اکثر ویرایش‌ها و دستورات نیاز به تایید دارند. بهترین گزینه برای کارهای حساس یا محیط‌های ناآشنا.
• Edits: ویرایش فایل‌های در محدوده (In-scope) و عملیات رایج فایل‌سیستم به صورت خودکار اجرا می‌شوند. بهترین گزینه برای کدنویسی تعاملی همراه با بازبینی Diffها.
• Auto Mode: اقدامات روتین بدون پرامپت اجرا شده و اقدامات ریسکی از طریق بررسی‌های امنیتی پس‌زمینه مدیریت می‌شوند. بهترین گزینه برای کارهای طولانی‌مدت با جهت‌گیری مورد اعتماد.
• dontAsk: هر چیزی که صراحتاً پیش‌تایید نشده باشد، مسدود می‌شود. بهترین گزینه برای محیط‌های CI بسته و لیست‌های سفید (Allowlists) دقیق.
• bypassPermissions: پرامپت‌های اجازه و اکثر بررسی‌های امنیتی نادیده گرفته می‌شوند. فقط برای کانتینرهای ایزوله یا ماشین‌های مجازی (VM) توصیه می‌شود.

تحلیل ریسک و اعداد واقعی

بر اساس ارزیابی مهندسی Anthropic، این سیستم بی‌نقص نیست. شرکت نرخ مثبت کاذب (False-Positive) ۰.۴٪ در ۱۰,۰۰۰ فراخوانی ابزار داخلی را گزارش کرده است، اما یک نرخ منفی کاذب (False-Negative) قابل توجه‌تر یعنی ۱۷٪ در مجموعه‌ای کوچک از ۵۲ اقدام «بیش از حد مشتاقانه» (Overeager) مشاهده شده است. آنتروپیک این را «عدد صادقانه» می‌نامد تا هشدار دهد Auto Mode یک مرز امنیتی مطلق و خطاناپذیر نیست.

به طور پیش‌فرض، طبقه‌بندی‌کننده اقدامات با ریسک بالا را مسدود می‌کند، از جمله:

• دانلود و اجرای کدهای نامعتبر (مانند curl | bash).
• استخراج (Exfiltrating) Secrets یا داده‌های حساس.
• Force Pushها و عملیات‌های مخرب Git.
• استقرار در محیط Production و مهاجرت‌های دیتابیس (Database Migrations).
• حذف انبوه در فضای ذخیره‌سازی ابری یا اعطای دسترسی‌های IAM/Repository.
• تغییر زیرساخت‌های مشترک یا دور زدن بررسی‌های امنیتی شکست‌خورده.
• نوشتن اعتبارنامه‌ها (Credentials) در ترنسکریپت‌ها یا فایل‌ها.
• ادغام (Merge) یک Pull Request بدون تایید انسان یا تایید PR خودش.
• غیرفعال کردن بررسی‌های CI یا راه‌اندازی یک عامل خودگردان بدون محدودیت دیگر.

مدل عملیاتی «شبانه»

افزایش ۹ برابری تداوم اجرا، واحد کار نرم‌افزاری را از «نوبت‌های تعاملی» به «اجراهای خودگردان محدود» تغییر می‌دهد. این موضوع درباره سرعت یا صحت کد نیست، بلکه درباره تداوم است. اکثر تسک‌های نرم‌افزاری حلقه‌هایی هستند: $\text{inspect} \rightarrow \text{plan} \rightarrow \text{edit} \rightarrow \text{test} \rightarrow \text{diagnose} \rightarrow \text{repeat}$. حذف وقفه‌های روتین اجازه می‌دهد این حلقه بدون نظارت اجرا شود. با این حال، باید توجه داشت که حتی در حالت خودکار، مدیریت بهینه پنجره زمینه همچنان کلیدی‌ترین عامل در جلوگیری از افت کیفیت خروجی‌هاست.

برای عملیاتی کردن این مدل، رویکرد «قرارداد تفویض» (Contract Approach) پیشنهاد می‌شود:

۱. هدف (Objective): یک نتیجه دقیق (مثلاً: کاهش مصرف حافظه پیک برای report-worker حداقل ۱۵٪ در یک بنچمارک خاص بدون تغییر در خروجی).
۲. محدوده (Scope): دایرکتوری‌ها و اینترفیس‌های صراحتاً نام‌برده شده (مثلاً: فقط در services/report-worker و تست‌های آن کار کن؛ قراردادهای سریال‌سازی مشترک را تغییر نده).
۳. خط پایه (Baseline): اندازه‌گیری وضعیت پیش از شروع (مثلاً: دستور npm run benchmark:memory را سه بار اجرا کن و میانه peak RSS را ثبت کن).
۴. تاییدکننده (Verifier): شرایط قابل اجرا برای پذیرش یا رد (مثلاً: تست‌های واحد، تست‌های قرارداد و پنج تکرار بنچمارک؛ اگر p95 زمان اجرا بیش از ۳٪ بدتر شد، رد کن).
۵. مرزها (Boundaries): قوانین سخت‌گیرانه درباره آنچه عامل نباید انجام دهد (مثلاً: Merge نکن، Deploy نکن، سیاست CI را تغییر نده و با سیستم‌های خارجی به جز GitHub ارتباط برقرار نکن).
۶. بودجه (Budget): محدودیت توکن یا زمان برای جلوگیری از حلقه‌های بی‌نهایت (مثلاً: بعد از شش تلاش برای پیاده‌سازی یا ۹۰ دقیقه بدون بهبود، متوقف شو).
۷. شواهد (Evidence): الزام به ارائه یک Draft PR حاوی متریک‌های خط پایه/نهایی، دستورات اجرا شده، نتایج تست و رویکردهای رد شده.

چرا اجرای شبانه Nuro موفق بود؟

مثال شرکت Nuro حیاتی است چون تفاوت بین «اهداف مبهم» و «سیگنال‌های قابل اندازه‌گیری» را نشان می‌دهد. به عامل گفته نشد «رانندگی خودکار را بهبود ببخش»؛ بلکه او روی متریک‌های ارزیابی و منفی‌های کاذب در یک سیستم تست موجود کار کرد. تیم دیگری در Nuro از این قابلیت برای کاهش اثر حافظه (Memory Footprint) یک باینری خاص استفاده کرد — یک مسئله «صعود از تپه» (Hill-climbing) که در آن عامل بر اساس یک متریک هدف $Q$ و یک مجموعه رگرسیون $T$ تکرار می‌کند.

این الگو برای چندین نوع تسک شبانه قابل تعمیم است:

• کاهش حجم Bundle: هدف، اندازه آرتیفکت ساخته شده زیر یک آستانه مشخص است.
• بهبود تأخیر کوئری‌ها: هدف، کاهش p95 بدون رگرسیون در صحت نتایج است.
• رفع تست‌های ناپایدار (Flaky Tests): هدف، پاس شدن تکرارهای تست با نرخ مشخص است.
• مهاجرت یک API: هدف، کامپایل موفق و پاس شدن تست‌های قرارداد است.
• بازتولید یک باگ: هدف، ایجاد تست جدیدی است که قبل از اصلاح شکست بخورد و بعد از آن پاس شود.
• اصلاح دسترسی‌پذیری (Accessibility): هدف، پاس شدن قوانین خودکار به همراه اسکرین‌شات‌های پیوست شده است.

استک امنیتی برای ریسک‌های بدون نظارت

برای جلوگیری از «ریسک‌های بدون نظارت»، پلتفرم یک استراتژی دفاعی هفت‌لایه توصیه می‌کند:

• لایه ۱: قوانین دسترسی پایدار: استفاده از قوانین ask برای نقاط بازرسی (مانند git push یا terraform apply) و قوانین deny برای عملیات ممنوعه (مانند git push --force یا خواندن فایل‌های .env). تنظیمات قوانین در برابر فشرده‌سازی متن (Context Compression) مقاوم‌تر از پرامپت‌ها هستند.
• لایه ۲: مرزهای اعتماد پیکربندی‌شده: تعریف دامنه‌های داخلی مورد اعتماد، باکت‌های ابری و رجیستری‌های پکیج در تنظیمات مدیریت شده. این کار به طبقه‌بندی‌کننده کمک می‌کند تا هدف داخلی «مورد اعتماد» را از یک دیتابیس حساس Production تشخیص دهد.
• لایه ۳: سندباکس در سطح OS: استفاده از سندباکس برای محدود کردن دسترسی‌های یک پردازش. این ضروری است زیرا تحلیل‌های سطح مدل نمی‌توانند ایمنی وابستگی‌های (Dependencies) آلوده را تضمین کنند. (کاربران ویندوز باید از WSL2، Dev Containers یا VM استفاده کنند). سندباکس باید شامل لیست‌های سفید شبکه و عدم دسترسی به ~/.ssh یا ~/.aws/credentials باشد.
• لایه ۴: اعتبارنامه‌های محدود: عامل نباید هویت کامل توسعه‌دهنده را به ارث ببرد. از توکن‌های کوتاه‌مدت استفاده کنید و دسترسی را فقط به مخزن هدف و برنچ تسک محدود کنید. عامل نباید اجازه انتشار پکیج یا دسترسی Admin سازمان را داشته باشد.
• لایه ۵: ابزارهای MCP محدود: سرورهای کامل را مسدود کنید یا برای ابزارهایی که اثر جانبی دارند (مانند Slack، Jira یا PagerDuty) تایید بخواهید. برای مثال، Garner Health حالت Auto را طوری پیکربندی کرد که هر اقدامی برای ارتباط با افراد دیگر را مسدود کند تا عامل با صدای یک انسان صحبت نکند.
• لایه ۶: هوک‌های قطعی (Deterministic Hooks): استفاده از هوک‌های Stop برای جلوگیری از اینکه کلود در حالی که تست‌ها در حال شکست هستند، ادعای موفقیت کند. برای مثال، هوک npm run verify:overnight می‌تواند بر اساس کد خروجی ۲، تکمیل تسک را مسدود کند. هوک‌ها اجرایی هستند و بسیار قابل‌اعتمادتر از پرامپت‌های توصیه‌ای‌اند.
• لایه ۷: تایید مستقل: استفاده از یک زیر-عامل تازه یا یک جلسه (Session) دوم برای بازبینی Diff نهایی جهت شناسایی انحراف از محدوده (Scope Drift) یا تضعیف Assertها. مانیتورینگ سیستم با استفاده از متریک‌های OpenTelemetry برای جلسات، هزینه و تلاش‌های انجام عملیات غیرمجاز.

تحلیل: تغییر به سمت طراحی تفویض (Delegation Design)

این تحول نشان‌دهنده یک تغییر بنیادین در نقش توسعه‌دهنده است. مهارت اصلی از «تایید دستورات» به «طراحی تفویض» تغییر می‌کند. توسعه‌دهنده دیگر خلبانی نیست که عامل را در لحظه هدایت کند، بلکه معمار محیط، هدف و مسیر تایید است.

برای حوزه فنی، این بدان معناست که «Pull Request» به ابتدایی‌ترین واحد تحویل تبدیل می‌شود. با نگه داشتن خروجی عامل در یک PR، تیم‌ها یک دروازه کنترل‌شده توسط انسان برای پذیرش حفظ می‌کنند، در حالی که عامل مسئول آماده‌سازی است. PR اجازه حفاظت از برنچ، بررسی‌های CI و مسیریابی CODEOWNERS را می‌دهد. ارزش دیگر با خطوط کد اندازه‌گیری نمی‌شود، بلکه با تعداد Issueهای تایید شده، بهبودهای بنچمارک یا کاهش حافظه/تأخیر در زمانی که تیم آفلاین است، سنجیده می‌شود.

انتخاب تسک: چه کارهایی را شبانه اجرا کنیم؟

همه تسک‌ها برای Auto Mode مناسب نیستند. خط dividing بین «ابهام» و «برگشت‌پذیری» است.

کاندیداهای مناسب:

• باگ‌هایی با تست‌های شکست‌خورده قابل بازتولید.
• مهاجرت‌هایی با لیست فایل‌های محدود و بازخورد کامپایلر.
• بهینه‌سازی‌های بنچمارک با فیکسچرهای پایدار.
• به‌روزرسانی وابستگی‌ها با CI گسترده.
• خطاهای Lint، فرمتینگ یا Type با دستورات قطعی.
• مستنداتی که از کد تولید شده و لینک‌هایشان تایید شده است.
• اصلاحات امنیتی محدود با اسکنرهای صریح.

کاندیداهای نامناسب:

• بازطراحی‌های معماری باز و بدون هدف مشخص.
• مهاجرت‌های دیتابیس Production یا تغییرات IAM/DNS/TLS.
• پاسخ به حوادث (Incident Response) با تاثیر مستقیم روی مشتری.
• تسک‌هایی که نیاز به قضاوت حقوقی، حریم خصوصی یا سیاست‌گذاری دارند.
• تسک‌هایی که تنها معیار موفقیت در آن‌ها «بهتر به نظر رسیدن» است.

برای پیاده‌سازی ایمن، تیم‌ها باید از یک نردبان پذیرش پیروی کنند:
۱. Auto Mode تعاملی: استفاده در حین کدنویسی عادی برای یادگیری اینکه چه زمینه‌های زیرساختی مفقود است.
۲. تسک‌های محلی کوتاه: اجرای تسک‌های ۱۵ تا ۳۰ دقیقه‌ای؛ کار را برگشت‌پذیر نگه دارید و Push را ممنوع کنید.
۳. Draft PRها در برنچ‌های ایزوله: اجازه Push برای کلاس‌های محدود از مخازن را بدهید.
۴. اجراهای شبانه محدود: استفاده از متریک‌های اجرایی و بودجه‌های سخت‌گیرانه زمان/هزینه.
۵. پلتفرم تیمی: انتقال پیکربندی‌ها به سیاست‌های مدیریت شده و قراردادهای استاندارد تسک.

در آینده شاهد ظهور «قراردادهای تسک» استاندارد و تنظیمات سیاست مدیریت شده خواهیم بود، زیرا سازمان‌های مهندسی بزرگ تلاش می‌کنند این شیفت‌های شبانه خودگردان را حاکمیت‌گذاری (Govern) کنند.

گام بعدی شما

• برای تسک‌های کوچک ۱۵ تا ۳۰ دقیقه‌ای، حالت Auto را در محیط محلی تست کنید اما اجازه Push ندهید.
• یک «قرارداد تفویض» با متریک‌های قابل اندازه‌گیری برای اولین اجرای شبانه خود بنویسید.
• محیط اجرای عامل را به یک کانتینر ایزوله منتقل کنید تا دسترسی به فایل‌های حساس سیستم شما قطع شود.

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