«جایگزینی آزادی با SOP»؛ راهکار جلوگیری از انفجار توکن‌ها در Claude

تصور کنید یک برنامه‌نویس است که ساعت‌ها وقتش را صرف اصلاح کدهای متناقض عامل‌های هوش مصنوعی می‌کند؛ وضعیتی که در این پروژه به «اثر رامن» معروف شده است. این نوسان شدید بین نتایج درخشان و فاجعه‌بار، بزرگ‌ترین چالش در پیاده‌سازی یک سیستم‌فایل Copy-on-Write (COW) از صفر است. برای حل این مشکل، نویسنده در ۴ اکتبر ۲۰۲۶ یک چرخش راهبردی ایجاد کرد: گذار از یک ساختار تخاصمیِ سه-جانبه به سمت یک خط لوله‌ای صلب از دستورالعمل‌های عملیاتی استاندارد (SOP) و گیت‌های مکانیکی برای تضمین کیفیت کد در سطح تولید.

برای درک دقیق «اثر رامن»، نویسنده یک SOP را به یک کاسه رامن ژاپنی تشبیه می‌کند: یک دستور پخت دقیق که دقیقاً مشخص می‌کند چه مقدار نودل، چه مقدار آب، چه مقدار نمک و چه مقدار پیازچه باید استفاده شود. بدون این دستور، فرآیند به عباراتی چون «مقداری نودل»، «کمی روغن»، «مقدار مناسب آب» و «پیازچه به مقدار دلخواه» تبدیل می‌شود که منجر به کیفیتی تصادفی می‌گردد. به همین ترتیب، عامل‌های هوش مصنوعی بدون محدودیت‌های سخت، مستندات و گزارش‌هایی می‌نویسند که کیفیت آن‌ها جایی بین «لذیذ» و «افتضاح» نوسان می‌کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی مقابله با توهمات API در Claude Code اشاره کردیم، این رویکرد جدید روی یک مشکل سیستمی عمیق‌تر دست می‌گذارد: خودمختاری بیش از حد عامل‌ها. وقتی به عامل‌ها آزادی زیاد داده می‌شود، آن‌ها اغلب در پاسخ به سوالات باز بیش از حد فکر می‌کنند یا «نوچه‌های نوچه» (sub-agents) ایجاد می‌کنند که از نظارت انسانی خارج می‌شوند. نویسنده اشاره می‌کند که در حالی که یک انسان می‌تواند یک جلسه «تفکر» ۴۰ دقیقه‌ای را تحمل کند، اما سه جلسه متوالی از این دست غیرممکن است. علاوه بر این، «انفجار توکن» ناشی از عامل‌های بازگشتی، نقطه‌کوری ایجاد می‌کند که در آن مدیر انسانی دیگر نمی‌تواند منطق لایه‌های زیرین (نوچه‌های نوچه‌های نوچه‌ها) را دنبال کند. نویسنده این وضعیت را چنین توصیف می‌کند: «نوچه‌های نوچه‌های نوچه‌های من، دیگر نوچه‌های من نیستند.»

خط لوله SOP

معماری جدید، سازماندهی عامل‌ها را به یک خط لوله خطی تبدیل کرده است: بازیابی $ \rightarrow $ بررسی $ \rightarrow $ پیاده‌سازی $ \rightarrow $ خود-ارزیابی $ \rightarrow $ پاک‌سازی دانش $ \rightarrow $ گیت. این رویکرد یادآور استراتژی‌های مشابهی است که در جداسازی برنامه‌ریزی کدنویسی از اجرای آن در Ordewell دیدیم تا از هرج‌ومرج در محیط‌های چند-عاملی جلوگیری شود. هر مرحله توسط یک عامل تخصصی در مسیر .claude/agents/ مدیریت می‌شود که یک قانون سخت‌گیرانه دارد: آن‌ها فقط می‌توانند با نام فراخوانی شوند و هرگز اجازه ندارند عامل‌های دیگر را به‌صورت خودکار فعال (auto-dispatch) کنند. در توصیف هر عامل صراحتاً ذکر شده است: «فقط زمانی استفاده شو که عامل اصلی تو را با نام فراخوانی کند... هرگز به‌طور خودکار عامل دیگری را فعال نکن.»

• بازیابی (Retrieval): عامل prior-art با استفاده از مدل Sonnet (با تنظیم effort: high و omitClaudeMd: true) حقایق و استنادات را از سورس‌کد و مستندات سایر سیستم‌فایل‌ها استخراج می‌کند. این عامل اکیداً از ارائه هرگونه استدلال منع شده و فقط فکت‌ها را همراه با استناد برمی‌گرداند. ورودی‌های مورد نیاز آن شامل دایرکتوری پیش‌نویس و گزارش است و از ابزارهایی مانند Read، Bash، WebFetch و WebSearch استفاده می‌کند.
• بررسی (Investigation): در این مرحله از یک ساختار تخاصمی سه-جانبه برای یافتن رویکرد مناسب استفاده می‌شود. عامل experiment-designer (با مدل Opus، effort: high و omitClaudeMd: true) یک شماره آزمایش را دریافت کرده و پیش از ایجاد هرگونه کد یا آرتیفکت، ثبت‌نام‌های پیش‌اجرا (شامل بازوها، کنترل‌ها، معیارها و بندهای شکست) را می‌نویسد. ورودی‌های آن شامل دایرکتوری پیش‌نویس، بند مورد آزمایش و فهرستی از فورک‌ها، سوالات یا اجراهای مجدد است. سپس عامل three-way-attack (با مدل Opus، effort: high و omitClaudeMd: true) به عنوان بازوی مهاجم در این استدلال عمل می‌کند و با استفاده از مطالب پیش‌زمینه، سطوح حمله و احکام دورهای قبلی، رویکرد را به چالش می‌کشد. ورودی‌های آن شامل لیست عدم-خواندن، دایرکتوری پیش‌نویس، مطالب پیش‌زمینه و سطح حمله است.
• پیاده‌سازی (Implementation): عامل implementation-writer (با مدل Opus، effort: high و omitClaudeMd: true) تغییرات را در پوشه crates/ برای یک گام مایل‌استون، یک خط موازی یا خوشه‌ای که عامل اصلی دسته‌بندی کرده، اعمال می‌کند. این عامل باید تست‌ها را ارائه دهد و ثابت کند که تست‌ها در ابتدا «قرمز» (شکست‌خورده) می‌شوند. ورودی‌های آن شامل دایرکتوری پیش‌نویس، گزارش، بند مربوطه و فایل‌های crates است که باید تغییر کنند. عامل tooling-writer (با مدل Sonnet، effort: high و omitClaudeMd: true) مراحل گیت، قلاب‌ها (hooks)، اسکریپت‌های پژوهشی، دیده‌بان‌ها و تعاریف عامل‌ها یا محدودیت‌های مشترک را مدیریت می‌کند. هر تغییر در اینجا ابتدا باید ورودی‌ای بسازد که قرمز شود. ورودی‌های آن شامل دایرکتوری پیش‌نویس، گزارش، خروجی و فایل‌های مورد تغییر است.
• خود-ارزیابی (Self-Check): عامل investigator (با مدل Opus، effort: high و omitClaudeMd: true) زمانی که نتیجه یک تست یا گیت با انتظارات متفاوت است، علائم را بازتولید می‌کند. این عامل خطا را تا سطح فایل و خط دقیق دو-نیم (bisect) کرده و یک بازتولید حداقلی (minimal repro) به همراه شرطی که آن را رد کند، برمی‌گرداند. اگر دستور فراخوانی «پس از یافتن، اصلاح کن» باشد و بند مربوطه روش اصلاح را مشخص کرده باشد، آن را پیاده کرده و قرمز شدنش را ثابت می‌کند؛ در غیر این صورت، متوقف شده و کنترل را به عامل اصلی باز می‌گرداند. ورودی‌های آن شامل علامت خطا، دایرکتوری پیش‌نویس و گزارش است.
• پاک‌سازی دانش (Knowledge Rot): عامل sweep (با مدل Sonnet، effort: high و omitClaudeMd: true) کل مخزن را بازرسی می‌کند. هرگاه عددی پس گرفته شود، یک ثابت فرمت تغییر کند، معیار جدیدی ایجاد شود یا مرحله‌ای از کار به پایان برسد، این عامل در مخزن به دنبال مقادیر قدیمی یا استنادات نادرست گشته و فهرستی طبقه‌بندی شده ارائه می‌دهد. ورودی‌های آن دایرکتوری پیش‌نویس و گزارش است.

محدود کردن قابلیت‌های عامل

برای حذف نقطه‌کوری که توسط تولید بازگشتی عامل‌ها ایجاد می‌شد، توسعه‌دهنده متغیر محیطی CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 را تنظیم کرد. این کار باعث ایجاد یک سلسله‌مراتب تک‌لایه می‌شود؛ یعنی عامل‌های زیرمجموعه نمی‌توانند نوچه‌های خودشان را داشته باشند. این اقدام ریسک رسیدن به وضعیتی که «نوچه‌های نوچه‌های نوچه‌ها دیگر نوچه‌های من نیستند» را از بین می‌برد. همچنین برای پیشگیری بیشتر، هیچ‌کدام از نقش‌ها در ابزارهای خود کلمه «Agent» را ندارند.

دسترسی‌ها از طریق مجموعه‌ابزارهای محدودتر برای حذف «منطقه خاکستری» رفتارهای عامل محدود شده‌اند:

• محدودیت ابزارها: در حالی که اکثر عامل‌ها به Bash دسترسی دارند، فقط پژوهشگر می‌تواند از طریق WebFetch و WebSearch به وب متصل شود. ابزارها اکیداً به زیرمجموعه‌ای از Read، Edit، Write، Bash، WebFetch و WebSearch محدود شده‌اند.
• کنترل زمینه: از پرچم omitClaudeMd=true برای حذف زمینه‌های غیرضروری استفاده شده تا مدل دچار «تداعی آزاد» نشود و هدف اصلی را گم نکند. توسعه‌دهنده تاکید دارد که هر زمینه‌ای که عامل نیازی به دانستن آن ندارد، بدون استثنا حذف شود.
• قلاب‌های اجرا: به دلیل دسترسی همگانی به Bash، قفل‌ها روی قلاب‌های اجرا (hooks) قرار گرفته‌اند. الگوهای خطرناک پیش از اجرا رد می‌شوند تا سیستم به «ادب و نزاکت» عامل تکیه نکند.
• مدیریت توان: تنظیم effort: high به‌صورت هوشمندانه استفاده می‌شود تا سیستم برای حل مسائل ساده، بیش از حد توان مصرف نکند.

سامانه گیت‌های مکانیکی

حیاتی‌ترین بخش این معماری، «گیت» است؛ مجموعه‌ای از الزامات سخت‌گیرانه که کد باید پیش از ورود به دایرکتوری اصلی از آن‌ها عبور کند. این رویکرد سخت‌گیرانه برای حذف خطاهای سیستمی، مشابه استراتژی Dusyn در استفاده از معماری ماشین حالت (State Machine) است تا از رفتارهای پیش‌بینی‌ناپذیر عامل‌ها جلوگیری شود. نویسنده گیت را به «ساعت منع خروج» در دوران کودکی تشبیه می‌کند؛ شما می‌توانید انتخاب کنید که دیر به خانه بیایید (مثلاً بعد از ساعت یازده)، اما نیامدن به خانه اصلاً یک گزینه نیست. گیت به‌طور خودکار هنگام ورود فعال می‌شود، چه برای تک‌نفره‌ها و چه برای دو-نفره‌ها.

۱. اثبات دوگانه قرمز-سبز: صرفاً پاس شدن تست (سبز شدن) کافی نیست. عامل باید شواهدی ارائه دهد که تست واقعاً قادر به شناسایی خطا است (قرمز شدن). گیت به‌طور مکانیکی کد را در یک نقطه می‌شکند تا تایید کند تست طبق انتظار شکست می‌خورد؛ شواهد قرمز و سبز باید با هم ارسال شوند تا اطمینان حاصل شود که تست یک «مثبت کاذب» نیست.
۲. منشأ سخت‌گیرانه: هر «کد شبحی» که فاقد سوابق تصمیم‌گیری تاریخی یا لینک به آزمایش باشد، رد می‌شود. گیت به‌طور سخت‌گیرانه بررسی می‌کند که آیا کامنت‌ها دقیقاً توضیح می‌دهند کد از کجا آمده است و پیاده‌سازی را به سوابق تصمیم و آزمایش گره می‌زند.
۳. نقاط کاوش جامع: سیستم نیازمند یک «شبکه عصبی» از پروب‌هاست تا ثابت کند جریان داده کامل است. حتی اگر کد در یک محیط شبیه‌سازی شده از ۲۰۰,۰۰۰ نقطه مختلف عبور کند، توسعه‌دهنده باید نشان دهد که جریان داده فاقد تخلف است. بررسی‌هایی که هنوز سیم‌کشی نشده‌اند باید صادقانه به عنوان «پیاده‌نشده» علامت‌گذاری شوند و نمی‌توانند تظاهر به پاس شدن کنند.
۴. گیت فرمت: تمام مستندات و ورودی‌های پایگاه دانش برای رعایت دقیق فرمت‌های JSON یا Markdown بررسی می‌شوند. حتی یک تاریخ باید طبق استاندارد نوشته شود؛ هرگونه بداهه‌نویسی منجر به شکست در گیت می‌شود.

حفاظت در برابر نوشتن کثیف (Dirty-Write)

برای جلوگیری از فساد وضعیت و «نوشتن‌های کثیف»، جداسازی فیزیکی اعمال شده است. اکثر فریم‌ورک‌های بالغ از یک worktree و یک فضای کاری ریشه برای جداسازی استفاده می‌کنند، اما نویسنده یک قفل اضافی افزود: هیچ کدی اجازه ورود به دایرکتوری crates را ندارد مگر اینکه از گره اختصاصی عامل implementation-writer عبور کرده باشد.

کسی که کد را می‌نویسد و کسی که آن را بازبینی می‌کند باید به‌طور فیزیکی ایزوله باشند. بدون امضای دوجانبه، کد نمی‌تواند از آستانه مخزن اصلی عبور کند. این کار از نوشتن در دایرکتوری اصلی توسط عامل‌های زیرمجموعه‌ای که با یکدیگر در حال جنگ هستند (پیش از رسیدن به نتیجه نهایی) جلوگیری می‌کند.

در نهایت، یک مکانیسم تایم-اوت به عنوان «گشت منظم» عمل می‌کند. عامل اصلی یک اسکریپت زمان‌بندی شده را ضمیمه می‌کند که به‌طور مداوم عامل‌های زیرمجموعه را زیر نظر دارد. اگر حجم زمینه (context) بیش از حد رشد کند یا زمان اجرا از حد مجاز بگذرد، عامل اصلی پیشرفت کار را بررسی کرده و در صورت انحراف از انتظارات، بلافاصله عامل را بازمی‌گرداند.

این تغییر، گذاری از «مهندسی پرامپت» به «مهندسی فرآیند» است. با نگاه به عامل‌های هوش مصنوعی به عنوان کارگران متخصص در یک کارخانه (به جای همکاران خلاق)، کیفیت خروجی را به معماری سیستم گره زده است، نه به «تمرکز» روزانه مدل.

برای کسانی که جریان‌های کاری عامل‌محور در مقیاس بزرگ را مدیریت می‌کنند، گام بعدی بازرسی عمق فعلی عامل‌های شماست. اگر عامل‌های شما بدون محدودیت سخت‌گیرانه در عمق (depth)، زیر-عامل تولید می‌کنند، احتمالاً از همان «نقطه کور» و «پوسیدگی زمینه» رنج می‌برید که در اینجا توصیف شد.