شما نمی‌توانید وظیفه‌ای را به یک عامل هوش مصنوعی بسپارید، اگر برای تأیید نتیجه مجبور باشید تمام مسیر را خودتان دوباره طی کنید. این شکاف بنیادی باعث ایجاد «مالیات اعتماد» شده است؛ وضعیتی که در آن کاربر یا تمام وقتش را صرف نظارت بر هر گام می‌کند یا ریسک شکست‌های خاموش در محیط عملیاتی را می‌پذیرد. در ۲ سپتامبر ۲۰۲۶، چارچوبی برای حل این معضل با معرفی Agateon ارائه شد. این یک پروتکل ارکستراسیون (Orchestration) متن‌باز است که طراحی شده تا تأیید را به جای یک امیدواری ساده، به یک امر ساختاری تبدیل کند.
اکثر کاربران فعلاً با عامل‌های کدنویسی پیشرفته به سه روش ناکارآمد تعامل می‌کنند. گروه اول هر تغییر (diff) و هر فراخوانی ابزار را نظارت می‌کنند و عملاً زمانی را که قصد داشتند ذخیره کنند، صرف بررسی می‌کنند. گروه دوم «اعتماد می‌کنند و امیدوار می‌مانند» و تنها زمانی متوجه انحراف (drift) مدل می‌شوند که باگ در محیط عملیاتی ادغام شده، مستقر شده یا سه روز پس از آن، زمانی که بافتار (Context) پروژه بیش از حد زیاد شده، کشف شود. گروه سوم نیز فقط وظایف کوچک و بازگشت‌پذیر — مثل تغییر در یک فایل واحد — را می‌سپارند که سریعاً با یک نگاه گذرا قابل بررسی باشد. در هر سه حالت، محدودکننده اصلی IQ مدل نیست، بلکه اعتماد کاربر به خروجی است.
این مشکل با افزایش توانایی مدل‌ها تشدید می‌شود، زیرا سرعت رشد قابلیت‌های آن‌ها از سرعت خواندن و تأیید خروجی توسط انسان پیشی می‌گیرد. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، هرچه پیچیدگی سیستم بالا می‌رود، نقاط کور نظارتی بیشتر می‌شوند. سپردن کارهای کوتاه و تک‌باره (Single-burst)، مثل ساختار اولیه یک مخزن کد یا رفع یک خطای lint، آسان است چون کل خروجی یک‌باره دیده می‌شود؛ اما در کارهای طولانی که ساعت‌ها زمان می‌برند و ده‌ها گام دارند، حجم داده‌ها بسیار بیشتر از آن است که یک انسان بتواند در ذهن خود نگه دارد. در اکثر سیستم‌های فعلی، تنها خلاصه موجود، گزارش خودِ عامل است.
این وضعیت سقفی ایجاد می‌کند که مرز تفویض اختیار را نه بر اساس توانایی مدل، بلکه بر اساس میزان ریسک‌پذیری کاربر تعیین می‌کند. دو مهندس با یک مدل یکسان، سقف‌های متفاوتی خواهند داشت؛ تماماً بسته به اینکه چه چیزی را قادر به تأیید هستند. هر چه شکاف بین آنچه مدل می‌تواند انجام دهد و آنچه کاربر جرئت می‌دهد انجام شود عمیق‌تر شود، هر کسی که این شکاف را با ساختار پر کند، سهمی بسیار بیشتر از توانایی‌های هوش مصنوعی به دست خواهد آورد.
سازوکار Agateon
Agateon تلاش می‌کند با تبدیل تأیید به زیرساخت، این سقف را جابه‌جا کند. به جای تکیه بر ادعای عامل مبنی بر اینکه کار «تمام شده است»، این پروتکل کار را مجبور می‌کند تا از هشت فاز مجزا عبور کند. هر فاز با شواهد عینی و ماشین‌خوان قفل شده است:
- کدهای خروج (Exit Codes): یک اجراکننده تست باید کد موفقیت برگرداند تا ماشین وضعیت پیش برود. پیشروی بر اساس ادعای «به نظر می‌رسد تمام شده» ممکن نیست.
- گزارش‌های گیت (Git Logs): تمام تغییرات باید در کنترل نسخه ثبت شوند. این کار تضمین می‌کند که در صورت شکست یک فاز، بازگشت (Rollback) در تاریخچه گیت ثبت شود و از ریست شدن خاموشِ شمارنده تلاش‌ها (retry-counter) که می‌تواند شبکه ایمنی را از کار بیندازد، جلوگیری شود.
- وضعیت دیسک (Disk State): وجود فایل‌های خاص روی دیسک، به عنوان یک پیش‌شرط سخت برای پیشروی در مراحل عمل می‌کند. این رویکرد سخت‌گیرانه به نظارت بر فایل‌ها، یادآور روش‌های سنجش امنیت سیستم‌فایل با استفاده از فایل‌های تله است که برای شناسایی نفوذهای غیرمجاز به کار می‌رود.
به نقل از مستندات پروژه، چون تمام پیشرفت‌ها در قالب Markdown و تحت کنترل نسخه ذخیره می‌شوند، جلسات در برابر کرش‌ها مقاوم هستند. یک وظیفه متوقف‌شده دیگر به معنای شروع مجدد نیست، بلکه یک مسئله زمان‌بندی است و سیستم از آخرین فاز تأییدشده ادامه می‌دهد. برای اطمینان از نبود نقص در خودِ گیت‌ها، توسعه‌دهندگان از تست‌های خصمانه (Adversarial Tests) و یک داور مستقل در یک بستر تازه برای بازبینی پذیرش استفاده می‌کنند. در این سیستم، کد خروج — و نه نظر مدل — معیار موفقیت است.
کاربرد واقعی و محدودیت‌ها
طبق گزارش dev.to، این پروتکل در حال حاضر در مرحله «استفاده داخلی» (Dogfooding) است؛ به این معنا که مخزن کد خود Agateon با استفاده از همین ابزار ساخته شده است. تاریخچه وظایف در دایرکتوری agate-workspace/tasks/ سندی عمومی از این چرخه است. این تاریخچه شامل وظایفی است که نقاط ضعف خودِ پروتکل را برطرف کرده‌اند، از جمله بررسی‌های سازوکاری که شکاف‌های یافته‌شده در ممیزی‌ها را بستند و یک مرحله بهسازی پروتکل (hygiene pass) که اجراهای تکراری و زائد تأیید را حذف کرد.
با این حال، این سیستم یک پروتکل است، نه یک محصول آماده و Plug-and-play. پذیرش آن نیازمند انضباط خاصی است، از جمله استفاده از لینک‌های نمادین (Symlinks)، هوک‌ها و رعایت فازبندی توسط عامل‌ها. این رویکرد «مالیات اعتماد» را با «هزینه راه‌اندازی» و تشریفات (ceremony) جایگزین می‌کند؛ به همین دلیل توسعه‌دهندگان پیشنهاد می‌کنند پذیرش آن را به صورت تدریجی و با استفاده از جریان‌های ساده‌شده (pruned flows) برای وظایف کوچک آغاز کنید.
محدودیت‌های ساختاری زیر نیز باید در نظر گرفته شوند:
- کیفیت شواهد: یک گیت تنها به اندازه تستی که اجرا می‌کند قوی است. اگر توسعه‌دهنده تست ضعیفی بنویسد، پروتکل ضعف را تأیید می‌کند، نه کیفیت کد را. هیچ پروتکلی نمی‌تواند سقف کیفیتِ تست‌های زیربنایی را اصلاح کند.
- شکاف خود-مجوزی: زمانی که عامل کد را می‌نویسد و همان گیت کد را قضاوت می‌کند، شکافی باقی می‌ماند. اگرچه استفاده از داور مستقل هزینه «جعل» (fakery) را بالا می‌برد و یک ردپای ممیزی باقی می‌گذارد، اما این حقیقت که نویسنده و داور یک بازیگر هستند، همچنان یک محدودیت ساختاری است (LIMITATIONS-3). این چالش در مورد عامل Sonjomon نیز دیده شد که برای جلوگیری از خطاهای بحرانی، ترجیح داد از اصلاح خودسرانه دست بکشد تا ریسک‌های عملیاتی کاهش یابد.
- کمبود داده: در حال حاضر داده‌های بلندمدت درباره میزان دقیق کاهش نظارت انسانی در پروژه‌های متنوع و واقعی وجود ندارد.
تغییر پارادایم کاری
وقتی تأیید ساختاری می‌شود، ماهیت مهندسی تغییر می‌کند. کاربران از «پرستاری» فرآیند دست می‌کشند و به جای دستورات گام‌به‌گام، اهداف را تعریف می‌کنند. پیشروی دیگر بر اساس ادعا نیست، بلکه بر اساس شواهد بررسی‌شده است. تمرکز از بررسی متن گفتگوهای AI به بررسی محصول نهایی و تصمیم‌گیری‌های سطح بالا منتقل می‌شود که ماشین قادر به انجام آن‌ها نیست.
این چرخش، مرز تفویض را از «آنچه جرئت ریسکش را دارم» به «آنچه می‌توانم چک کنم» تغییر می‌دهد. با بستن شکاف بین توانایی مدل و تأیید انسانی، کاربران می‌توانند قضاوت خود را برای کارهای پیچیده‌ای که واقعاً به لمس انسان نیاز دارد، بازیابی کنند. هدف، رسیدن به عاملی است که واقعاً قابل تفویض باشد؛ نه به این دلیل که صادق است، بلکه چون کارش قابل بررسی است.
اگر در حال حاضر با عامل‌ها محصول می‌سازید، مفیدترین سؤال این است: «چه اتفاقی بیفتد که مجبور نباشم هر لحظه این را تماشا کنم؟» اگر پاسخ صادقانه این است که «هیچ، باید به آن اعتماد کنم»، شما با یک شکاف تأیید روبرو هستید که نیاز به راهکار مکانیکی دارد. مخزن Agateon تحت لایسنس MIT در گیت‌هاب در دسترس است (github.com/randomgitsrc/agateon) و با یک دستور curl تک‌خطی نصب می‌شود. با گنجاندن تأیید در زیرساخت، سقف آنچه می‌توان تفویض کرد، بالاخره جابه‌جا می‌شود.
گام بعدی شما
- بررسی مخزن Agateon در گیت‌هاب برای درک نحوه پیاده‌سازی فازهای تأیید.
- شناسایی تکراری‌ترین بخش‌های نظارتی در گردش‌کارهای فعلی‌تان و تبدیل آن‌ها به تست‌های خودکار (Exit Codes).
- آزمایش رویکرد «داور مستقل» برای کاهش توهمات در خروجی‌های پیچیده.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو