مهارت‌های انسانی در مقیاس عامل‌ها؛ چرا خروجی‌های «به نظر درست» باعث شکست سیستم

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

«مهارت‌هایی که برای استفاده انسانی ساخته شده‌اند، تحت بارِ عامل‌های خودکار به شکلی پیش‌بینی‌پذیر تخریب می‌شوند و خروجی‌هایی تولید می‌کنند که به‌طور بصری indistinguishably یا به معنای Totally indistinguishable صحیح به نظر می‌رسند، اما در لایه‌های زیرین، به‌طور خاموش و ظریف اشتباه هستند.» این جمله، تز مرکزی The Level 5 Engineer است؛ یک دفترچه یادداشت آموزشی عمومی که در آن یک مهندس نرم‌افزار ارشد و رهبر فنی (Tech Lead) فاش می‌کند چرا پرامپت‌های باکیفیت AI که برای انسان‌ها عالی عمل می‌کنند، اغلب هنگام ادغام در جریان‌های کاری خودکارِ عامل-محور (Agent Workflows)، باعث شکست‌های فاجعه‌بار و خاموش می‌شوند. این یافته، این پیش‌فرض رایج را که «خروجی بهتر AI همیشه به معنای عملکرد بهتر سیستم است»، به‌طور جدی به چالش می‌کشد.

در اکثر موارد، توسعه‌دهندگان مهارت‌های AI را برای مصرف انسانی می‌سازند؛ جایی که انسان به عنوان لایه اصلاح نهایی عمل می‌کند. اگر یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — یک شناسه کاربر (User ID) یا کد وضعیت HTTP را اشتباه پیشنهاد دهد، انسان آن را می‌بیند، با ورودی مقایسه می‌کند و پیش از رسیدن به محیط تولید (Production)، خطا را می‌گیرد. این لایه انسانی است که عدم دقت مهارت را مدیریت می‌کند. اما در محیط‌های مقیاس عامل-محور، این لایه اصلاح حذف می‌شود. یک عامل (Agent) پایین‌دستی که خروجی مهارت را مصرف می‌کند، آن را به عنوان یک مصنوع (Artifact) تأییدشده می‌پذیرد. این عامل ورودی اصلی را برای تطبیق دوباره نمی‌خواند؛ بلکه هر آنچه مهارت تولید کرده را پیاده‌سازی می‌کند و بدین ترتیب، یک توهم ظریف را به یک باگ سخت سیستمی تبدیل می‌کند. برای مثال، یک شناسه کاربر تغییریافته تبدیل به یک مقدار تغییریافته در تعریف گام (Step Definition) می‌شود، یا یک نقطه پایانی (Endpoint) اختراعی تبدیل به بخشی از کار پیاده‌سازی می‌شود که هرگز درخواست نشده بود. یک تضاد باقی‌مانده در متن تبدیل به تستی می‌شود که هرگز نمی‌تواند پاس شود.

این پژوهش بر اساس یک چارچوب مفهومی توسط دن شاپیرو (مدیرعامل Glowforge و پژوهشگر Wharton)، به‌ویژه پست وبلاگی او با عنوان «پنج سطح: از تکمیل خودکار تندوباز تا کارخانه تاریک» (The Five Levels: from Spicy Autocomplete to the Dark Factory)، و استراتژیست AI، نیت بی. جونز (Nate B. Jones)، شکل گرفته است. کار شاپیرو ستون فقرات مفهومی و واژگان این مسیر را فراهم کرد، در حالی که ویدیوی جونز با عنوان «۵ سطح کدنویسی AI (چرا اکثر شما از سطح ۲ فراتر نخواهید رفت)» به عنوان ماشه و محرک این تحقیق عمل کرد. هدف این بود که مشخص شود آیا مهارتی که برای انسان «درست» به نظر می‌رسد، می‌تواند فشار فراخوانی توسط عامل‌های دیگر را بدون نظارت انسانی تحمل کند یا خیر. در این راستا، مهندس یک مهارت «ارزیاب کیفیت Gherkin» را برای بهبود مشخصات API مورد آزمایش قرار داد.

مکانیزم‌های مقیاس عامل-محور

به نقل از این گزارش، برای بقا در مقیاس عامل-محور، یک مهارت باید از «مفید بودن» (Helpfulness) ساده فراتر رود و سه ویژگی خاص داشته باشد که آن را از یک پرامپت انسان‌محور متمایز می‌کند:

• تکرارپذیری (Idempotency): فراخوانی دو‌باره مهارت با ورودی یکسان باید دقیقاً همان خروجی قبلی را تولید کند. نه یک خروجی مشابه، بلکه دقیقاً همان خروجی.
• پایداری خروجی (Output Stability): فرمت خروجی نباید بر اساس نحوه بیان درخواست یا قاب‌بندی (Framing) تغییر کند؛ تغییر باید فقط و فقط بر اساس محتوای ورودی باشد.
• صراحت در شکست (Failure Specificity): وقتی مدل نمی‌تواند خروجی درست تولید کند، باید به‌گونه‌ای شکست بخورد که به فراخوان‌کننده بگوید دقیقاً چه چیزی کم است، نه اینکه پاسخی بسازد که «پذیرفتنی» یا «به نظر درست» باشد اما در واقع غلط باشد.

شکاف تکرارپذیری

در اولین تست استرس، مهندس روی تکرارپذیری تمرکز کرد: توانایی مهارت در تولید خروجی دقیقاً یکسان در برابر ورودی یکسان. او از یک سناریوی استاندارد استفاده کرد: «سفارش زمانی تأیید می‌شود که تمام شرایط برقرار باشد. Given کاربر با حساب معتبر And اقلام در دسترس هستند When سفارش ثبت می‌شود Then باید موفق شود.»

پنج بار اجرا با این ورودی یکسان انجام شد، اما «قاب‌بندی» (Framing) برای هر بار تغییر کرد تا واکنش AI به تفاوت‌های ظریف زبانی بررسی شود:

1. «این سناریو را با استفاده از مهارت کیفیت Gherkin ارزیابی کن.»
2. «مهارت کیفیت Gherkin را برای بهبود این سناریو اعمال کن.»
3. «از مهارت کیفیت Gherkin استفاده کن تا این سناریو را قبل از اینکه پیاده‌سازی کنم، چک کند.»
4. «این سناریو باید آماده‌ی عامل (Agent-ready) باشد. آن را از طریق مهارت کیفیت Gherkin اجرا کن.»
5. «مهارت کیفیت Gherkin باید این را ارزیابی کند. چه خروجی تولید می‌کند؟»

با وجود یکسان بودن سناریوی ورودی، خروجی‌ها در این پنج اجرا به‌شدت تغییر کردند (Drift):

• کدهای وضعیت HTTP: این کدها بین ۲۰۱ (در اجراهای ۱، ۳ و ۴) و ۲۰۰ (در اجراهای ۲ و ۵) متغیر بود. کلمه «بهبود» (Improve) در اجرای دوم و لحن مجهول در اجرای پنجم، مدل را به سمت پیش‌فرض‌های با تعهد پایین‌تر سوق داد، در حالی که عبارت «آماده‌ی عامل» در اجرای چهارم، مدل را تحریک کرد تا فرضیات صریح‌تری را بیرون بکشد.
• تعداد سناریوها: ساختار به‌شدت نوسان داشت. برخی اجراها دو سناریو تولید کردند (۱ و ۴)، یکی دو سناریوی متفاوت تولید کرد (۳) و برخی دیگر تنها یک سناریو ارائه دادند (۲ و ۵).
• مسیرهای شکست: مدل توهمات متفاوتی زد. برای اجراهای ۱ و ۴ کمبود موجودی کالا را پیشنهاد داد، برای اجرای ۳ رد پرداخت را، و برای اجراهای ۲ و ۵ هیچ مسیر شکستی ارائه نداد.
• کامنت‌های فرضیات: حجم متا-دیتا تغییر کرد؛ از ۰ کامنت در اجرای ۳، به ۱ کامنت در اجراهای ۲ و ۵، ۲ کامنت در اجرای ۱، و ۳ کامنت در اجرای ۴ رسید.

برای انسان، این یک مزاحمت کوچک است؛ انسان هر پنج مورد را می‌خواند، بهترین عناصر را ترکیب می‌کند و پیش می‌رود. اما برای یک عامل پایین‌دستی، این یک «نقض قرارداد» (Contract Violation) خاموش است. عاملی که خروجی اجرای ۲ را می‌گیرد (یک سناریو، HTTP 200)، نمی‌داند که خروجی اجرای ۴ (دو سناریو، HTTP 201، سه کامنت فرضیه) کامل‌تر بود. توصیف سیگنال مسیریابی مشخص نکرده بود که آیا سناریوهای شکست اضافه شوند یا در صورت سکوت ورودی، از کدام کد HTTP استفاده شود. این تصمیمات ساختاری باز مانده بود و قاب‌بندی‌های مختلف، آن‌ها را به شکل‌های متفاوتی حل کردند.

پارادوکس «بهتر، بدتر است»

تست‌های تکمیلی نشان داد که مهارت‌های AI اغلب سعی می‌کنند «بیش از حد مفید» باشند و قرارداد فنی را به نفع کیفیت ادراکی نادیده بگیرند. مهندس یک تست پایداری خروجی با شش ورودی (A تا F) انجام داد که هر یک کمی نسبت به خط پایه بهبود یافته بودند. در حالی که ورودی‌های A تا E پایدار ماندند و بهبودها را بدون تغییر در ساختار خروجی جذب کردند، ورودی F منجر به یک شکست بحرانی شد.

ورودی F سناریویی بود که از پیش به‌طور قابل توجهی درست شکل گرفته بود و مستقیماً از فایل tests/features/order_creation.feature گرفته شده بود. در آن آمده بود: «Scenario: سفارش با موفقیت ایجاد می‌شود وقتی پرداخت موفق شود و همه اقلام در موجودی باشند. Given کاربر ثبت‌نام شده با شناسه "user-123" And سرویس موجودی تأیید کند همه اقلام موجود‌اند And درگاه پرداخت شارژ را بپذیرد When کاربر سفارشی برای SHOE-RED-42 و BELT-BRN-M ثبت می‌کند Then وضعیت سفارش "CONFIRMED" است And پاسخ شامل یک شناسه سفارش است And درگاه پرداخت دقیقاً یک درخواست شارژ دریافت کرده است And سرویس موجودی یک درخواست رزرو دریافت کرده است.»

مهارت به‌درستی دو بدهی (Debt) جزئی واقعی را یافت: نبود کد وضعیت HTTP در بخش Then و نبود تعداد برای درخواست رزرو. اما سپس، یک بازنویسی کامل از کل سناریو تولید کرد. شناسه user-123 را به یک شناسه جدید تغییر داد و عبارت «کاربر سفارش را ثبت می‌کند» را با «کلاینت یک درخواست POST به /orders می‌فرستد» جایگزین کرد. تمام بندهایی که از پیش درست بودند را دوباره بیان کرد.

در حالی که خروجی معیار های کیفیت را داشت و «بهتر» از ورودی به نظر می‌رسید، اما قرارداد واقعی را شکست: «فقط آنچه نقض قرارداد است را تغییر بده». یک عامل پایین‌دستی که این خروجی را دریافت می‌کند، نمی‌تواند تشخیص دهد که آیا این بازنویسی لازم بوده یا مدل فرضیات جدیدی — مانند یک فرمت خاص UUID در مقابل یک عدد ساده — وارد کرده که با مشخصات واقعی محصول در تضاد است. مهارت هیچ بررسی تکرارپذیری نداشت و همه چیز را بازنویسی کرد، حتی بخش‌هایی که نیازی به بازنویسی نداشتند.

شکست‌های خصمانه و رانش دامنه

چهار تست خصمانه (Adversarial) برای بررسی حالت‌های شکست طراحی شد که آسیب‌پذیری‌های عمیق‌تری را در طراحی‌های AI انسان‌محور افشا کرد:

• حلقه‌های خود-ارجاع (Adversarial B): خروجی خط پایه از اولین اجرا دوباره به عنوان ورودی جدید به مهارت داده شد. مهارت باید آن را بدون تغییر بازمی‌گرداند. در عوض، بازنویسی جدیدی تولید کرد. بدون هیچ دلیل معنایی، user-baseline-001 را به user-selfref-001 و user-baseline-002 را به user-selfref-002 تغییر داد. بدتر از آن، به‌طور خاموش یک کامنت فرضیه حیاتی را حذف کرد: # Assumption: "registered user" implies an existing user ID, not an auth token. یک عامل پایین‌دستی خروجی‌ای با فرمت درست می‌بیند، اما تعریف گامی که روی شناسه اصلی Hardcode شده است، اکنون با شکست مواجه می‌شود.
• رانش دامنه (Adversarial C): مهندس یک سناریوی UI درباره ورود کاربر به داشبورد ارائه داد. مهارت آن را رد نکرد. در عوض، تعامل UI را به یک قرارداد HTTP API ترجمه کرد: «Scenario: احراز هویت کاربر موفق می‌شود وقتی اعتبارنامه‌ها معتبر باشند. Given کاربر ثبت‌نام شده با شناسه "user-ui-001" و رمز عبور "••••••••" When کلاینت یک POST به /auth/login با نام کاربری "user-ui-001" می‌فرستد Then وضعیت پاسخ HTTP برابر ۲۰۰ است And بدنه پاسخ شامل یک فیلد "token" در فرمت JWT است.» مدل یک نقطه پایانی (/auth/login)، یک فرمت توکن (JWT) و یک ساختار پاسخ اختراع کرد. هیچ‌کدام در کدبیس وجود نداشتند. یک عامل پایین‌دستی زیرساخت احراز هویتی را می‌ساخت که هرگز در مشخصات نیامده و درخواست نشده بود.
• مدیریت تناقض (Adversarial D): ورودی حاوی محدودیت‌های منطقی ناسازگار بود: در بند When آمده بود «شارژ را دقیقاً یک بار پردازش می‌کند» و در بند Then آمده بود «بیش از ۳ بار فراخوانی نشود». مهارت تناقض را در یک کامنت فرضیه شناسایی کرد، اما باز هم بازنویسی را انجام داد و هر دو تضاد را در متن گنجاند. این منجر به تستی می‌شود که هرگز نمی‌تواند پاس شود زیرا محدودیت‌ها برای یک اقدام واحد ناسازگار هستند.
• ورودی‌های خالی (Adversarial A): این تنها مورد موفقیت بود؛ یک سناریوی خالی باعث تحریک یک سیگنال شکست صریح شد بدون اینکه گام‌های خیالی بسازد.

مهندسی مهارت تقویت‌شده

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

• بررسی تکرارپذیری (Idempotency Check): پیش از تولید خروجی، مهارت بررسی می‌کند که آیا ورودی در حال حاضر قرارداد خروجی را ارضا می‌کند یا خیر. اگر بله، ورودی را بدون تغییر با تگ زیر بازمی‌گرداند: # SKILL: No changes required — scenario satisfies output contract. اگر فقط بخشی از آن ارضا شده باشد، تنها اصلاحات هدفمند و حداقلی را بازمی‌گرداند.
• حفاظ دامنه (Domain Guard): اگر ورودی توصیف‌کننده تعاملات UI باشد — مانند کلیک روی مرورگر، بارگذاری صفحه یا ارسال فرم — مهارت اکنون صراحتاً با این پیام شکست می‌خورد: # SKILL FAILURE: This scenario describes UI behaviour, not an HTTP API contract. # This skill applies to API-level specifications only.
• توقف در تناقض (Contradiction Halt): اگر محدودیت‌های منطقی ناسازگار یافت شوند، مهارت هشدار می‌دهد و کاملاً متوقف می‌شود و از بازنویسی خودداری می‌کند: # SKILL WARNING: Contradicting constraints detected in [step]. # Resolve before implementation.
• حفاظ خود-ارجاع (Self-Reference Guard): بررسی تکرارپذیری این مورد را به‌طور خودکار مدیریت می‌کند. خروجی مهارت که دوباره به عنوان ورودی داده شود، اکنون بدون تغییر بازمی‌گرداند. این رفتار به‌طور صریح در بخش قرارداد خروجی مهارت مستند شده است تا اطمینان حاصل شود که این یک ویژگی برنامه‌ریزی‌شده است، نه یک اتفاق تصادفی.

نتایج تقویت

اجرای ورودی‌های خصمانه در مهارت تقویت‌شده، تغییر کاملی در قابلیت اطمینان و پیش‌بینی‌پذیری نشان داد:

تغییر در پارادایم تمرین AI

این پژوهش نشان می‌دهد که یک مهارت «انسان-پسند»، در مقیاس عامل-محور در واقع خطرناک است. چون مدل‌های انسان‌محور آموزش دیده‌اند که همیشه پاسخی بدهند که مفید به نظر برسد، آن‌ها فاقد «شرایط پایان» (Termination Conditions) برای موارد خاص (Edge Cases) هستند. آن‌ها ورودی یک دامنه اشتباه را ترجمه می‌کنند یا یک تضاد را در کامنت مستند کرده و همچنان به کار ادامه می‌دهند، به‌جای اینکه از کار کردن امتناع کنند.

در یک جریان کاری تولیدی (Production Agentic Workflow)، یک پاسخ «مفید» که به‌طور ظریفی غلط است، بسیار ویران‌گرتر از یک پیام خطای صریح است. چون خروجی شبیه به موفقیت است — نام فیلدها، فرمت و ساختار درست است — بنابراین اقدام پایین‌دستی اجرا می‌شود. این چالش در پیاده‌سازی‌های واقعی اتوماسیون نیز دیده می‌شود؛ برای مثال، در گزارش‌های اخیر دیده شده که چگونه اتوماسیون بدون کد توانسته زمان عملیات را تا ۸۷.۵٪ کاهش دهد، اما پایداری این سیستم‌ها به‌شدت به دقت تعریف قراردادها وابسته است. خطا تنها زمانی نمایان می‌شود که یک تست برای شناسه کاربری که به‌طور خاموش تغییر کرده شکست بخورد، یا وقتی یک مهندس بپرسد چرا زیرساخت احرازی ساخته شده که هرگز در محدوده (Scope) پروژه نبوده است.

تغییر لازم برای توسعه‌دهندگان باید حرکت از «کیفیت خروجی» (آیا درست به نظر می‌رسد؟) به سمت «پایداری قرارداد» (آیا پیش‌بینی‌پذیر و تکرارپذیر است؟) باشد. شما می‌توانید تکامل این چارچوب‌ها را با بررسی «معماری مهارت‌های عامل-اول» (Agent-First Skills Architecture) که توسط نیت بی. جونز مستند شده است، دنبال کنید؛ معماری‌ای که از پرامپت‌نویسی ساده فراتر رفته و به سمت یک نظم مهندسی ساختاریافته برای عامل‌های AI حرکت می‌کند. گام بعدی در این مسیر، « divisors بررسی مهارت» (The Skill Review) است که بر این تمرکز دارد که مرور کد (Code Review) چگونه باید باشد وقتی هدف بررسی، خودِ مهارت است و نه تغییرات کد (Diff).

گام بعدی شما

• در طراحی پرامپت‌های عامل-محور، به‌جای تشویق مدل به «خلاقیت» یا «بهبود»، روی «حداقل تغییرات لازم برای رعایت قرارداد» تأکید کنید.
• برای هر مهارت AI، یک تست تکرارپذیری (Idempotency Test) تعریف کنید: خروجی مدل باید در ۵ بار اجرای متوالی با ورودی یکسان، دقیقاً یکسان باشد.
• سیگنال‌های شکست صریح (Explicit Failure Signals) را جایگزین پاسخ‌های تخمینی کنید تا عامل‌های پایین‌دستی متوجه توقف عملیات شوند.

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