چرا تغییر پرامپت‌ها خطاهای ساختاری عامل‌های هوشمند را می‌پوشاند؟

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

به نقل از مستندات فنی این رویکرد، اکثر شکست‌های عامل‌های هوشمند از دستورات ضعیف نشأت نمی‌گیرند، بلکه نتیجه‌ی شکست‌های نامرئی در تبادل داده‌های سطح درخواست (Request-level data) بین کاربر و مدل هستند. در واقع، مشکل در کل بسته‌ای است که برای مدل ارسال می‌شود، نه لزوماً در جمله‌ی اول یا پرامپت اولیه کاربر. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، شفافیت در لایه‌های میانی استنتاج، کلید دستیابی به پایداری در سیستم‌های پیچیده است.

برنامه‌نویسی با هوش مصنوعی در دو سال اخیر جهشی سریع داشت. ما از تکمیل‌کدهای ساده‌ای در سبک Copilot به ابزارهای پیشرفته و پیچیده‌ای مثل Claude Code، Codex، OpenCode، Cursor و Cline رسیدیم. این ابزارها دیگر فقط پیشنهاددهنده چند خط کد نیستند؛ آن‌ها پروژه‌ها را می‌خوانند، فایل‌ها را مستقیماً تغییر می‌دهند، دستورات سیستم را اجرا می‌کنند، ابزارها را فراخوانی می‌کنند، خطاها را تحلیل کرده و در حلقه‌های پیچیده تکرار می‌شوند. این سطح از خودمختاری، یک مشکل «جعبه سیاه» ایجاد کرده است؛ جایی که پاسخ نهایی فقط به ما می‌گوید «چه چیزی» اتفاق افتاده (چه تغییری اعمال شد)، اما دلیل یا «چرا»ی یک شکست را کاملاً مخفی می‌کند.

جریان کاری پنهان

در جریان‌های کاری حرفه‌ای، فاصله بین پرامپت کاربر و خروجی مدل یک پرش ساده نیست، بلکه یک فرآیند چندمرحله‌ای و زنجیره‌ای است:

• کاربر یک وظیفه یا تسک را پیشنهاد می‌دهد.
• مدل یک پرامپت سیستمی (System Prompt)، زمینه (Context) فعلی و لیستی از ابزارهای در دسترس را دریافت می‌کند.
• مدل تصمیم می‌گیرد ابزاری خاص را فراخوانی کند (به عنوان مثال، خواندن یک فایل خاص یا جستجو در کدهای پروژه).
• ابزار مذکور به‌صورت محلی اجرا شده و نتیجه‌ی حاصله به عنوان ورودی به درخواست بعدی مدل ارسال می‌شود.
• مدل نتیجه را ارزیابی کرده و تصمیم می‌گیرد که آیا باید دوباره وارد حلقه شود و ابزار دیگری را صدا بزند یا پاسخ نهایی را ارائه دهد.

آنچه ما در ترمینال یا ادیتور می‌بینیم، تنها بخشی کوچک از این زنجیره است. طبق گزارش‌های توسعه‌دهندگان، وقتی فقط به پاسخ نهایی نگاه می‌کنیم، تشخیص این مسائل غیرممکن است: آیا عامل واقعاً فایل حیاتی را دیده است؟ آیا زمینه (Context) در جایی قطع شده یا حذف شده است؟ یا اینکه یک خطای ۴۰۰ از سمت ارائه‌دهنده، مربوط به خودِ مدل بوده یا به دلیل مشکل در فرمت درخواست ارسال شده است؟

چهار لایه شکست عامل‌ها

خطاهای عامل‌ها را نباید به‌سادگی با برچسب «مدل ضعیف است» رد کرد. این خطاها به‌طور کلی در چهار لایه یا سطح distinct رخ می‌دهند:

۱. دید زمینه (Context Visibility)
این شایع‌ترین نوع شکست است. شما تصور می‌کنید عامل فایلی خاص را خوانده است، اما در واقعیت، پادمان (Payload) ارسالی به مدل فاقد آن محتوا بوده یا آن محتوا در دورهای بعدی گفتگو حذف شده است. وقتی این اتفاق می‌افتد، مدل بر اساس اطلاعات ناقص تصمیم می‌گیرد. در این موارد، گفتن این جمله که «دقیق‌تر بخوان» کاملاً بی‌معنی است؛ زیرا هدف اصلی باید این باشد که تأیید کنیم آیا زمینه حیاتی اصلاً وارد آخرین درخواست ارسال شده است یا خیر.

۲. ابهام در طرحواره ابزار (Tool Schema Ambiguity)
توانایی فراخوانی ابزارها به‌معنای استفاده درست از آن‌ها نیست. مدل یک «طرحواره ابزار» (Tool Schema) را می‌بیند که شامل نام ابزار، شرح آن و ساختار پارامترها است. مشکلات زمانی بروز می‌کنند که:

• توضیحات ابزار برای مدل بیش از حد گنگ باشد و مدل نداند چه زمانی باید از آن ابزار استفاده کند.
• ساختار پارامترها بیش از حد پیچیده باشد و منجر به تولید خطاهای نحوی در فراخوانی شود.
• تعداد ابزارهای موجود زیاد باشد و باعث شود مدل ابزار اشتباهی را انتخاب کند.
  این مشکلات با گسترش پروتکل‌های جدیدی مثل پروتکل زمینه مدل (MCP)، پلاگین‌ها و ابزارهای مدیریت زیر-وظیفه‌ها (sub-task tools) شدیدتر شده است.

۳. حلقه‌های اجرای شکسته
یک چرخه سالم فراخوانی ابزار باید از یک حلقه سخت‌گیرانه پیروی کند: دستیار: استفاده از ابزار $
ightarrow$ ابزار: نتیجه $
ightarrow$ دستیار: استدلال بر اساس نتیجه. اگر هر یک از این پیوندها قطع شود، عامل رفتارهای عجیبی نشان می‌دهد. برخی باگ‌های رایج عبارت‌اند از:

• ابزار در واقعیت هرگز اجرا نشده است، اما مدل باور دارد که اجرا شده و پاسخ دریافت کرده است.
• نتیجه ابزار (tool_result) بیش از حد طولانی بوده و باعث آلودگی یا پر شدن پنجره متنی برای دور بعدی شده است.
• پیام‌های نتیجه ابزار در ترتیب اشتباهی به مدل رسیده‌اند.
• پیام‌های tool_use و tool_result به‌درستی با یکدیگر جفت نشده‌اند.
• فرمت پیام مورد نیاز ارائه‌دهنده (Provider) با فرمتی که کلاینت ذخیره کرده متفاوت است.

۴. نشت توکن و هزینه
هزینه‌های توکن فقط مربوط به پاسخ نهایی نیستند. در سناریوهای عامل‌محور، حجم عظیمی از توکن‌ها توسط پرامپت‌های سیستمی، طرحواره‌های ابزار، تاریخچه گفتگو، محتوای فایل‌ها، نتایج جستجو، خروجی‌های دستورات ترمینال و زمینه‌های مربوط به زیر-عامل‌ها مصرف می‌شود. یک تسکِ به‌شدت گران‌قیمت، اغلب نتیجه‌ی یک دور (Round) خاص است که یک زمینه عظیم و تکراری را حمل کرده است، نه لزوماً به دلیل طولانی بودن پاسخ نهایی. ردیابی کل هزینه جلسه کافی نیست؛ توسعه‌دهنده باید میزان مصرف توکن را برای هر درخواست به‌صورت مجزا مشاهده کند.

چارچوب اشکال‌زدایی در سطح درخواست

برای تبدیل «حس کردن باگ» به «اثبات باگ»، توسعه‌دهندگان باید تحلیل پنج دسته داده‌ی مشخص را در اولویت قرار دهند:

• پرامپت‌های سیستمی (System Prompts): این‌ها محدودیت‌های پایه هستند. آن‌ها توضیح می‌دهند چرا یک عامل اصرار دارد ابتدا نقشه بکشد، چرا از تغییر برخی فایل‌ها خودداری می‌کند یا چرا مکرراً درخواست تأیید می‌کند.
• تاریخچه پیام‌ها (Message History): تمرکز نباید بر این باشد که عامل «زمانی» چه چیزی خواند، بلکه باید دقیقاً بررسی شود که در «دور فعلی» چه مواردی در پنجره ارسال شده است. خواندن محلی یک فایل تضمین نمی‌کند که آن فایل در دور بعدی در پنجره مدل باقی بماند.
• طرحواره‌های ابزار (Tool Schemas): قبل از متهم کردن مدل به عدم فراخوانی ابزار، بررسی کنید: آیا ابزار واقعاً در لیست ارسالی بود؟ آیا شرح آن شفاف است؟ آیا ساختار آن منطقی است؟ آیا ابزارهای مشابهی وجود دارند که باعث سردرگمی مدل شوند؟ آیا ارائه‌دهنده از این طرحواره خاص پشتیبانی می‌کند؟
• جفت‌های فراخوانی/نتیجه (Call/Result Pairs): این بهترین راه برای یافتن خطاهای منطقی است. بررسی کنید کدام ابزار انتخاب شد، چه پارامترهایی ارسال شد، ابزار چه چیزی برگرداند و آیا آن نتیجه واقعاً در گام بعدی استدلال مدل اثر گذاشت یا خیر.
• معیارهای استفاده (Usage Metrics): این بخش شامل تحلیل این است که در کدام دور جهش توکن‌های ورودی رخ داده، کدام نتیجه ابزار بیش از حد بزرگ بود، آیا از کش (Cache) استفاده شده است، کدام مدل گران‌ترین بوده و تأخیر (Latency) هر درخواست چقدر بوده است.

معرفی ccglass

برای حل این نبودِ شفافیت و دید، پروژه متن‌بازی به نام ccglass معرفی شده است (در دسترس در https://github.com/jianshuo/ccglass). برخلاف ابزارهای عمومی تحلیل بسته یا اسنیفرهایی مثل Charles، mitmproxy یا Proxyman، ابزار ccglass یک ابزار مشاهده‌پذیری (Observability) محلی و اختصاصی برای عامل‌های هوش مصنوعی است. این ابزار یک پروکسی محلی و داشبورد ایجاد می‌کند که به‌طور خاص برای ابزارهایی مثل Claude Code، Codex، OpenCode، CodeBuddy و Qoder طراحی شده است.

ccglass موانع شبکه‌ای خاص هوش مصنوعی را حل می‌کند؛ موانعی مانند کلاینت‌هایی که پروکسی‌های سیستمی را نادیده می‌گیرند، کلاینت‌هایی که از URLهای پایه سفارشی استفاده می‌کنند، یا فرمت‌های متفاوتی از استریمینگ که بین لایه‌های سازگاری OpenAI و Anthropic وجود دارد. این ابزار ترافیک خام HTTP را به یک نمای ساختاریافته از پرامپت‌های سیستمی، پیام‌ها، طرحواره‌های ابزار، فراخوانی‌ها، نتایج و بدنه درخواست‌ها/پاسخ‌ها تبدیل می‌کند و حتی امکان مشاهده تفاوت‌های (Diff) دور به دور را فراهم می‌سازد.

یک مورد استفاده واقعی

تصور کنید از Claude Code برای رفع یک باگ استفاده می‌کنید. کد تغییر می‌کند اما نتیجه نهایی اشتباه است یا احساس می‌کنید چیزی درست نیست. به جای اجرای مجدد پرامپت و امید به شانس، می‌توانید با ccglass یک زنجیره شواهد (Evidence Chain) بسازید:
۱. آیا درخواست اول واقعاً شامل فایل‌های مرتبط با باگ بود؟
۲. آیا پرامپت سیستمی به‌گونه‌ای بود که استراتژی تغییر مدل را تحت تأثیر قرار داد؟
۳. دقیقاً کدام ابزارها فراخوانی شدند و چه نتایجی برگرداندند؟
۴. آیا تغییر کد «بعد» از آنکه عامل پیام خطای تست را ببیند اتفاق افتاد یا قبل از آن؟
۵. آیا در یک دور خاص، تعداد توکن‌ها به‌صورت انفجاری افزایش یافت و باعث حذف Contextهای قبلی شد؟

آینده مشاهده‌پذیری

با تکامل ابزارهای برنامه‌نویسی، عامل‌ها مستقل‌تر خواهند شد؛ آن‌ها فایل‌های بیشتری را می‌خوانند، ابزارهای پیچیده‌تری را فراخوانی می‌کنند و زیر-عامل‌ها را مدیریت می‌کنند. این روند کارایی را بالا می‌برد اما پیچیدگی را نیز افزایش می‌دهد. گلوگاه‌های آینده دیگر این نخواهد بود که آیا یک مدل می‌تواند یک تابع را بنویسد یا خیر، بلکه این خواهد بود که چرا یک عامل در دور هفتم ابزار خاصی را فراخوانی کرد و آن نتیجه را تا ۱۲ دور بعدی یدک کشید، یا چرا یک تسک به‌طور غیرمنتظره ۳۰۰,۰۰۰ توکن هزینه داشت.

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

توسعه‌دهندگانی که از IDEهای عامل‌محور (Agentic IDEs) استفاده می‌کنند باید از رویکرد «شکست‌های مهندسی پرامپت» به سمت «دیباگ زنجیره شواهد» حرکت کنند. برای کسانی که با Claude Code، Codex یا Qoder کار می‌کنند، ccglass پنجره‌ای به ذهن عامل است تا دقیقاً بدانند هوش مصنوعی چه دیده و چرا قدم بعدی را برداشته است.

گام بعدی شما

• اگر از ابزارهای Agentic استفاده می‌کنید، به جای تغییر کلمات پرامپت، ابتدا جریان داده‌های ارسالی (Payload) را بررسی کنید.
• ابزار ccglass را روی پروژه‌های فعلی خود نصب کنید تا نقاط نشت توکن در حلقه‌های تکرار را شناسایی کنید.
• شرح ابزارهای (Tool Descriptions) خود را بازبینی کنید تا ابهام در انتخاب ابزار توسط مدل کاهش یابد.

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