شکست لایهٔ گزارش‌دهی؛ چرا عامل‌های کدنویس در مقیاس واقعی متوقف می‌شوند؟

تصور کنید کارمندی دیجیتال دارید که حجم کاری یک هفته را در ۸ ساعت انجام می‌دهد، اما ۱۰ ساعت بعدی را صرف فریاد زدن می‌کند که همه چیز در حال سوختن است؛ حتی وقتی هیچ مشکلی وجود ندارد. اگر امروز برای مدیریت پروژه‌هایتان از عامل‌های هوشمند استفاده می‌کنید، احتمالاً متوجه شده‌اید که مشکل اصلی نه در «هوش» مدل، بلکه در مسیری است که نتایج را به شما خبر می‌دهد.

این تجربه توسط یک توسعه‌دهنده با استفاده از Claude Code به چالش کشیده شد. او توانست در یک شب ۶۶ مورد استقرار کد را به‌صورت خودکار انجام دهد، اما درست در همین نقطه بود که سامانهٔ گزارش‌دهی فروپاشید. طبق گزارش این توسعه‌دهنده، چالش فعلی برنامه‌نویسان دیگر «پرامپت» نیست، بلکه «پایپ‌لاین» است؛ یعنی همان پلی که خروجی ماشین را به اعتماد انسان متصل می‌کند. او دریافته است که توانایی مدل در کدنویسی، ساده‌ترین بخش معادله است و دشواری واقعی در زیرساختی است که باید به انسان بگوید ماشین دقیقاً چه کاری انجام داده است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به خروجی هوش مصنوعی مستلزم وجود لایه‌های نظارتی سخت‌گیرانه است. در دنیای واقعی، یک عامل (Agent) — شبیه به دستیاری که می‌تواند به‌تنهایی ابزارها را اجرا کند — اگر نتواند وضعیت دقیق خود را گزارش دهد، از یک مزیت تبدیل به یک مزاحم تبدیل می‌شود. این چالش دقیقاً زمانی رخ می‌دهد که توسعه‌دهندگان از رابط‌های ساده‌ی چت به سمت عامل‌های خودمختاری حرکت می‌کنند که مستقیماً روی فایل‌های محلی عملیات انجام می‌دهند. این گذار به سمت خودمختاری کامل، نیازمند زیرساخت‌های کنترلی جدیدی است؛ درست مانند آنچه در طراحی لایه‌های کنترل از راه دور برای Claude Code بررسی کردیم تا دسترسی به این عامل‌ها امن‌تر و مدیریت‌شده‌تر شود.

زمینه: از ده لیست تا یک لیست واحد

داستان از جایی شروع شد که این توسعه‌دهنده حدود ۱۰ پروژه زنده را روی یک Mac Studio مدیریت می‌کرد و هر پروژه در پوشه‌ای مجزا قرار داشت. گردش کار او شامل باز نگه داشتن یک تب در iTerm برای هر پروژه بود که هر کدام یک جلسه (Session) مجزای Claude Code را اجرا می‌کردند. اگرچه معمولاً دو یا سه جلسه به‌طور هم‌زمان کارهای واقعی را انجام می‌دادند، اما گلوگاه اصلی این بود که بدانند «چه چیزی را بعد از چه چیزی کد کنیم».

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

معماری ناظر ارشد (Master-Supervisor)

برای حل این مشکل، در اواسط جولای ۲۰۲۴، او یک پروژه «ناظر ارشد» (Master-Supervisor) راه انداخت. این سیستم در ابتدا به صورت یک اسکریپت شروع شد که تمام مخازن (Repo) را پیمایش می‌کرد، یک فایل وضعیت کوچک را از هر پروژه می‌خواند و یک نمای کلی و رتبه‌بندی شده می‌ساخت. این سیستم به جای اینکه فقط یک جفت دست اضافی باشد، مانند یک «رئیس کارکنان» برای کل پورتفولیو عمل می‌کرد.

حیاتی‌ترین اقدام، حذف تمام لیست‌های تودوزی در سطح هر پروژه بود. آن‌ها با یک لیست واحد در سطح سیستم جایگزین شدند که مالکیت آن بر عهده ناظر ارشد بود. ورودی‌ها از «کارهای آینده» (To-dos) به «سفارشات» (Orders) تغییر نام یافتند (مانند سفارش‌های کاری صنعتی). این تغییر ترمینولوژی یک سیگنال مهم بود: این‌ها دیگر یادداشت‌های شخصی نبودند، بلکه واحدهای کاری بودند که ماشین می‌توانست آن‌ها را بردارد و اجرا کند. اگرچه هر پروژه هنوز فایل خاص خود را داشت، اما این فایل‌ها اکنون در مخزن ناظر ارشد به عنوان «صف» (Queue) ذخیره می‌شدند، نه به عنوان دفترچه یادداشت.

هر سفارش در این سیستم یک بلوک کوچک از Markdown است که شامل عنوان، چند فیلد و یک یا دو خط توضیحات است. برای مثال:

## ORDER update-mcp-server
art: autonomous
prio: medium
Bump the MCP server to the current major version and re-run the integration tests.

دو فیلد اصلی، منطق سیستم را هدایت می‌کنند:

• سطح خودمختاری (Art): این فیلد سطح استقلال مدل را تعریف می‌کند.
  • Autonomous (خودکار): Claude Code می‌تواند این کار را بدون نظارت انجام دهد و کد را منتشر (Ship) کند.
  • Dialog (گفتگو): انسان می‌خواهد در حین انجام کار در جریان باشد و نظارت کند.
  • Decision (تصمیم): فقط انسان می‌تواند تصمیم نهایی را بگیرد (مثلاً فعال کردن یک پرداخت، خرید دامنه یا یک اعلان عمومی).
• اولویت (Priority): یک برچسب دستی (زیاد، متوسط، کم). توسعه‌دهنده اعتراف می‌کند که این بخش هنوز کامل نشده است و او هر چند روز یک‌بار صف را دستی بازبینی می‌کند، زیرا ترتیب‌بندی خودکار کافی نیست. او در یک بازبینی، از میان ۴۱ سفارش خودکار، ۱۳ مورد را آزاد و ۱۴ مورد را با استفاده از یک هایلایت (و نه الگوریتم) نگه داشت.

یک نکته بسیار حیاتی در این معماری وجود دارد: هیچ هوش مصنوعی تصمیم نمی‌گیرد که سفارش در کدام دسته (Bucket) قرار بگیرد. شخصی که سفارش را می‌نویسد، برچسب را در همان لحظه و با داشتن تمام زمینه‌ها تعیین می‌کند. «توزیع‌کننده» (Dispatcher) به‌طور عمدی از حدس زدن منع شده است، زیرا اسکریپتی که فقط عنوان را می‌خواند، نمی‌تواند سختی یا ریسک کار را قضاوت کند. پیش‌فرض برای هر فیلد گم‌شده یا نامشخص، همیشه «گفتگو» است و هرگز «خودکار» نیست. این عدم تقارن، هستهٔ مدل ایمنی است؛ زیرا تأخیر در یک سفارش انسانی هزینه کمی دارد، اما یک سفارش خودکار که به اشتباه اجرا شود، می‌تواند محیط عملیاتی (Production) را نابود کند.

پذیرش و دروازه‌بانی (Intake and Gatekeeping)

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

۱. ایمیل‌ها و هشدارها: ایده‌های ارسالی به ایمیل شخصی و هشدارهای سیستمی در یک اینباکس می‌روند. این‌ها هرگز به‌طور خودکار به سفارش تبدیل نمی‌شوند و فقط در طول «غربالگری انسانی» (Human Triage) به سفارش تبدیل می‌گردند. این یک قانون ثابت است تا مانع از آن شود که یک مهاجم ایمیلی بفرستد و هوش مصنوعی آن را به عنوان قصد کاربر اشتباه بگیرد.
۲. درخواست‌های سطح پروژه: وقتی توسعه‌دهنده داخل یک پروژه است و می‌گوید «این را به لیست اضافه کن»، درخواست از طریق یک صندوق پستی مشترک و «فقط-افزودنی» (Append-only) ارسال می‌شود. سپس ناظر ارشد این‌ها را به سفارشات واقعی در فایل‌های خود تبدیل می‌کند، به گونه‌ای که هر فایل فقط یک نویسنده داشته باشد تا تاریخچه خواندنی بماند. این مورد توسط یک Hook (قلاب) اجباری شده است که در صورت تخلف، خطا برمی‌گرداند.
۳. ورود دستی: ثبت مستقیم در صفِ ناظر ارشد.

مکانیسم شیفت شب (The Night Shift)

برای اجرای این سفارشات، یک اسکریپت هر ۵ دقیقه فعال می‌شود. این اسکریپت سفارشات برتری را شناسایی می‌کند که هم «تأیید شده» و هم «خودکار» علامت زده شده‌اند. برای تضمین پایداری، سیستم از یک safeguard فنی خاص استفاده می‌کند:

• Git Worktrees: به جای استفاده از نسخه فعال توسعه‌دهنده (که ممکن است شامل ویرایش‌های نیمه‌تمام باشد)، اسکریپت یک Git Worktree تازه می‌سازد. این یک Checkout تمیز از شاخه اصلی پروژه در یک دایرکتوری ایزوله است. این کار مانع از تداخل ماشین با انسان یا سایر جلسات فعال می‌شود.
• اجرای بدون سر (Headless Execution): مدل Claude Code به‌صورت Headless در محیط worktree اجرا می‌شود و توسط یک Timeout (محدودیت زمانی) و سقف تعداد سفارش در هر چرخه کنترل می‌شود تا یک فرآیند runaway (از کنترل خارج شده) کل شب را «ببلعد».
• قوانین ادغام (Merge Rules): اگر ادغام کد به‌صورت Fast-forward و تمیز باشد، ماشین به‌تنهایی آن را انجام می‌دهد. اما اگر هرگونه تضادی (Conflict) وجود داشته باشد، ماشین از «هوشمند شدن» منع شده است. کد را همان‌طور رها می‌کند، به گوشی توسعه‌دهنده پیام می‌دهد و درخواست حل انسانی می‌کند؛ زیرا باگ‌های ظریف دقیقاً در همان جایی هستند که ماشین سعی می‌کند تضادهای کد را به‌طور «هوشمندانه» حل کند.
• اعتبارسازی: پس از یک ادغام تمیز، یک بررسی مستقل دوم اجرا می‌شود. اگر این مرحله پاس شود، کد به محیط عملیاتی منتقل می‌شود. در این سیستم، «تأیید شده» یعنی «زنده و فعال».

جایی که سیستم شکست خورد

در یکی از شب‌های پربازده، این عامل توانست ۶۶ سفارش را در ۱۶ مخزن کد مختلف (۱۰ پروژه اصلی به علاوه مخازن زیرساختی) با موفقیت بسازد، ادغام کند و منتشر کند. او وابستگی‌ها را وصله کرد، یک سرور MCP ساخت و یک بنر زبانی را منتشر کرد؛ کارهایی که در حالت عادی یک هفته تلاش سخت می‌طلبید.

با این حال، این موفقیت یک «فروپاشی در گزارش‌دهی» را آشکار کرد. توسعه‌دهنده برنامه‌ریزی کرده بود که ماشین هنگام پایان هر سفارش و هنگامی که به تصمیم نیاز است، ایمیلی بفرستد. چون ماشین حجم عظیمی از کارهای عقب‌مانده را پاک کرد، توسعه‌دهنده با ۱۰۰ ایمیل بیدار شد: ۷۲ پیام «انجام شد» و ۲۸ پیام «به تو نیاز دارم». آن ۲۸ درصد حیاتی — سفارشات تصمیم‌گیری که ماشین به‌درستی در آن‌ها متوقف شده بود — زیر ۷۲ پیامی دفن شده بودند که اساساً می‌گفتند «لازم نبود برای این مورد اینجا باشی».

در ساعت ۰۱:۴۴ بامداد، توسعه‌دهنده متوجه شد کانالی که «همه چیز» را گزارش می‌کند، در واقع «هیچ چیز» را گزارش نمی‌کند. راه حل این بود که ایمیل‌های «انجام شد» کاملاً حذف شوند؛ موفقیت‌ها اکنون به یک Log می‌روند، در حالی که فقط شکست‌ها و تصمیمات واقعی به انسان می‌رسند و به صورت یک سوال همراه با توصیه فرموله می‌شوند.

شکست لایه اعتبارسنجی (Verification Layer)

فراتر از اعلان‌ها، لایه اعتبارسنجی (کدهایی که برای چک کردن کار AI نوشته شده بود) باگ‌دارتر از خودِ هوش مصنوعی ظاهر شد. عامل‌ها کار را درست انجام می‌دادند، اما لایه اعتبارسنجی چیزهای خوب را «بد» تشخیص می‌داد:

• هشدار کاذب: یک تسک پاک‌سازی هیچ چیزی را به محیط عملیاتی نفرستاد. لایه چک‌کننده این را نمی‌دانست، تقاضای استقراری کرد که هرگز نمی‌توانست اتفاق بیفتد و هر ۵ دقیقه فریاد می‌زد.
• خطای Shell: یک علامت ! در ابتدای یک خط لوله (pipeline) در شل، کد خروجی (exit code) بخش اشتباهی از فرآیند را خنثی کرد. بررسی‌ای که پاس شده بود، شبیه به شکست به نظر می‌رسید و در حالی که همه چیز خوب بود، هشدارها فعال شدند.

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

در نهایت، یک خطای منطقی در توزیع‌کننده (Dispatcher) باعث «قفل شدن سراسری» شد. توزیع‌کننده فقط اولین سفارش هر صف را می‌دید. اگر سفارش اول یک تسک «گفتگو» بود که منتظر انسان بود، کل صف پشت آن منجمد می‌شد — حتی اگر سفارش هفتم کاملاً خودکار و آماده بود. یک پروژه با چهار سفارش تأیید نشده، تمام موارد دیگر را مسدود کرده بود و تا زمانی که توسعه‌دهنده خودش به دنبالش نرفت، نامرئی بود.

گلوگاه خودمختاری

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

این آزمایش ثابت می‌کند که جریان‌های کاری عامل‌محور (Agentic Workflows) در حال حاضر توسط «کانال بازگشتی به انسان» محدود شده‌اند. چه یک صف که توسط یک تسک «گفتگو» با اولویت بالا منجمد شده باشد و چه یک طوفان اعلان، اصطکاک در مدیریت است، نه در اجرا. توانایی عامل در انجام تسک تقریباً حل شده است؛ بخش حل‌نشده این است که کارها را در یک مکان جمع کنیم، صادقانه برچسب بزنیم و اطمینان حاصل کنیم که سیگنال «به تو نیاز دارم» بدون غرق شدن در تشویق‌های ماشین، به انسان برسد. چنین رویکردed-driven به بهره‌وری، در بخش‌های تجاری نیز دیده می‌شود؛ برای مثال، اتوماسیون عامل‌محور در شرکت Itelnet توانست زمان انجام کارهای بازاریابی را تا ۳۰ درصد کاهش دهد، هرچند مدیریت این بازدهی همواره با چالش‌های نظارتی همراه است.

برای خواننده، این بدان معنای است که مقیاس‌بندی بهره‌وری AI در گرو یافتن یک LLM بهتر نیست، بلکه در گرو ساخت حفاظ‌های سخت‌گیرانه‌تر حول کدهای خروجی (Exit Codes)، قفل‌های فایل و فیلترهای اعلان است. ایمنی یک سیستم خودمختار در یک «پرامپت» نیست؛ بلکه در منطق باینری اسکریپتی است که وقتی شک دارد، از اجرا خودداری می‌کند. بریفینگ‌های نوشته شده برای هر پروژه «چرایی» را توضیح می‌دهند، اما بخش‌هایی که واقعاً سیستم را نگه می‌دارند، آن‌هایی هستند که یک جلسه خسته نمی‌تواند با صحبت کردن، خودش را از آن‌ها خلاص کند.

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

گام بعدی شما

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

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