مستندات راهنمای عامل‌های هوش مصنوعی صرفاً یک «آرزو» هستند

تصور کنید قانونی برای کاهش هزینه‌ها تعریف کرده‌اید تا کارهای ساده به مدل‌های ارزان سپرده شوند؛ قانونی که به طور واضح در پیکربندی پروژه مستند شده است، اما توسط عامل هوش مصنوعی کاملاً نادیده گرفته می‌شود. این سناریو تنها یک احتمال نیست، بلکه نتیجه‌ی یک ممیزی دقیق روی Claude Code است که توسط یک توسعه‌دهنده به اشتراک گذاشته شد. این مورد نشان می‌دهد که دستورالعمل‌های مکتوب و «بهترین روش‌ها» برای کنترل رفتار مدل‌ها تقریباً هیچ اثری ندارند، مگر اینکه در مسیر اجرای سیستم کدنویسی (Hard-coded) شده باشند.

این شکست، شکافی سیستمی را در نحوه مدیریت جریان‌های کاری عامل‌محور (Agentic Workflows) آشکار می‌کند. بسیاری از توسعه‌دهندگان به فایل‌هایی مثل AGENTS.md یا CLAUDE.md یا اسناد مربوط به بهترین روش‌های تیمی تکیه می‌کنند و آن‌ها را به عنوان سطوح کنترل (Control Surfaces) می‌بینند. این رویکرد اغلب منجر به تحلیل تدریجی کیفیت دستورالعمل‌ها می‌شود، موضوعی که در بررسی الگوی «استانداردهای کدگونه» برای جلوگیری از فساد دستورالعمل‌ها به تفصیل به آن پرداختیم. همان‌طور که در تحلیل قبلی ما درباره‌ی برتری محک‌های اختصاصی بر جدول‌های رده‌بندی عمومی اشاره کردیم، این مورد ثابت می‌کند که مستندات داخلی جایگزین ضعیفی برای محدودیت‌های واقعی سیستم هستند. طبق گزارش توسعه‌دهنده‌ی این پروژه، اگر نمی‌توانید با یک عدد دقیق بگویید عامل شما چند درصد از قوانین را رعایت می‌کند، شما «قانون» ندارید، بلکه فقط «آرزو» دارید.

زمینه‌ی این شکست

به نقل از گزارش این توسعه‌دهنده، او سه پروژه‌ی عملیاتی را با Claude Code اجرا کرد و یک قانون مسیریابی مدل (Model-routing rule) را در تنظیمات مشترک نوشت. منطق این قانون بسیار ساده بود: کارهای مکانیکی — مانند بررسی موجودی، تغییر نام فایل‌ها و تولید کدهای تکراری (Boilerplate) — باید به مدل ارزان سپرده شوند، در حالی که استدلال‌های سخت و پیچیده — شامل معماری سیستم، مسائل امنیتی و مهاجرت‌های دیتابیس (Migrations) — باید به مدل گران‌قیمت بروند.

این قانون به عنوان یک «بهترین روش» که باید به طور خودکار پذیرفته شود، ترویج شد. اما واقعیت این است که مستندات، ابزار کنترل نیستند. توسعه‌دهنده متوجه شد که این مستندات حتی یک تسک را هم به درستی مسیریابی نکرده‌اند؛ زیرا مدل به محض اینکه احساس کند تسک هنوز تمام نشده است، تمام یادآوری‌ها را نادیده می‌گیرد و از کنار آن‌ها می‌گذرد. این دقیقاً همان اشتباه ساختاری است که وقتی بودجه را در یک پرامپت (Prompt) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — می‌نویسید، رخ می‌دهد؛ گفتن اینکه «به سطح مدل دقت کن» یا «حداکثر ۸ جست‌وجو انجام بده»، صرفاً یک امید با فرمت زیباست. برای کاهش این خطاها، برخی تیم‌ها از جایگزینی دستورالعمل‌های انتزاعی با مراجع زنده تولید استفاده می‌کنند تا دقت مدل در محیط عملیاتی افزایش یابد.

جزئیات اندازه‌گیری و خطا

برای تست میزان پذیرش قوانین، توسعه‌دهنده یک تحلیل‌گر مصرف (Usage Analyzer) ساخت که هیچ وابستگی به کتابخانه‌های خارجی نداشت. این ابزار صرفاً تاریخچه‌ی جلسات (Session Transcripts) را که ابزار Claude Code از قبل روی دیسک می‌نوشت، می‌خواند. داده‌های اولیه نشان‌دهنده‌ی یک شکست فاجعه‌بار در پذیرش قوانین بود:

• استفاده از مدل ارزان: تنها ۰.۰۳٪ از کل خروجی (۱۸ هزار توکن در برابر ده‌ها میلیون توکن).
• قانون تعریف شده: کارهای مکانیکی به مدل ارزان، استدلال‌ها به مدل گران.
• نتیجه: مصرف مدل ارزان نه تنها کم بود، بلکه در حد یک خطای گرد کردن بود، نه صرفاً «کم‌مصرف».

اما داستان زمانی پیچیده‌تر شد که توسعه‌دهنده تصمیم گرفت خودِ ابزار اندازه‌گیری را ممیزی کند. او متوجه شد که کارهای «عامل‌های فرعی» (Subagents) در فایل‌های جداگانه‌ای به نام زنجیره‌های فرعی (Sidechain files) در دایرکتوری جلسه ذخیره می‌شدند. چون ابزار تحلیل‌گر او به صورت بازگشتی (Recursive) عمل نمی‌کرد، هرگز آن فایل‌ها را باز نکرد و در نتیجه، تمام توکن‌هایی که توسط عامل‌های فرعی مصرف شده بود، نامرئی بودند.

ممیزی و درس دوم

پس از اصلاح ابزار از طریق یک کامیت با عنوان «خواندن زنجیره‌های فرعی»، توسعه‌دهنده متوجه شد که عدد «Haiku=0» در واقع یک خطای اندازه‌گیری (Measurement Artifact) بوده است. با اصلاح ابزار، عدد ۰.۰۳٪ به ۰.۷۵٪ تغییر کرد (۳۷۰ هزار توکن از مجموع ۴۹.۴ میلیون توکن). اگرچه این عدد هنوز نشان‌دهنده‌ی شکست در اجرای قانون است، اما یک درس حیاتی مرتبه دوم را آشکار کرد: اندازه‌گیری‌ای که هرگز ممیزی نشود، خود یک «آرزو» است. عددها می‌توانند تردید ما را از بین ببرند، چون لباس عدد به تن دارند و شک کردن به آن‌ها را سخت‌تر می‌کنند.

این ثابت می‌کند شمارنده‌هایی که هرگز سعی نشده باشد آن‌ها را به شکست بکشانید، هرگز واقعاً تایید نشده‌اند. توسعه‌دهنده یک ماه کامل اعتماد بیش از حدی به ابزارش داشت، چون دقیقاً همان بخشی از سیستم را اندازه می‌گرفت که قانونش در آنجا نادیده می‌شد و ابزارش قادر به دیدن آن نبود.

گذار از مستندات به تزریق

برای کسانی که عامل‌های عملیاتی مدیریت می‌کنند، راهکار تغییر از «یادآوری» به «تزریق» (Injection) است. ارسال یادآوری در هر جلسه لازم است اما کافی نیست. به جای فایل‌های Markdown که مدل شاید هرگز باز نکند، قوانین باید به صورت رشته‌های استاتیک و قطعی در بستر شروع جلسه (Session-start context) تزریق شوند. این رویکرد در واقع پیاده‌سازی گیت‌های اعتبارسنجی سخت در برابر دستورالعمل‌های طولانی است که تضمین می‌کند مدل از قوانین عبور نکند.

این روش مزایای مشخصی دارد:

• بدون هزینه اضافی: چون از رشته‌های ثابت استفاده می‌کند و نیاز به تولید متن توسط مدل ندارد، هزینه‌ی اضافی ایجاد نمی‌کند.
• پایداری (Fails Open): حتی اگر تزریق ساده باشد، سیستم همچنان به کار خود ادامه می‌دهد و متوقف نمی‌شود.
• مسیر قطعی: قانون را در لایه‌ای قرار می‌دهد که مدل به طور ساختاری مجبور است از آن عبور کند، نه در سندی که مدل باید «انتخاب کند» بخواند.

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

گام بعدی شما

• بررسی کنید آیا قوانین عامل‌های شما در فایل‌های .md است یا در لایه‌ی System Prompt تزریق شده است.
• ابزارهای مانیتورینگ مصرف توکن خود را ممیزی کنید تا مطمئن شوید خروجی‌های Subagentها را از دست نمی‌دهید.
• برای کارهای تکراری، به جای توصیه به مدل، از رشته‌های استاتیک در ابتدای هر Session استفاده کنید.

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