یک طرح‌واره (Schema) ساده‌ی JSON، تفاوت میان هوش مصنوعی‌ای است که «ادعا می‌کند» فایلی را پاک کرده و سیستمی که «واقعاً» دستور پاک‌سازی را اجرا می‌کند. باید بدانید که این تمایز، هسته مرکزی معماری کلاود کد (Claude Code) است؛ ابزاری که طبق بررسی‌های فنی در ۱ اوت ۲۰۲۶، از یک مکانیزم ابزاری سخت‌گیرانه در چهار لایه برای مدیریت عملیات استفاده می‌کند.
هدف آنتروپیک (Anthropic) از این چرخش، حذف توهم (Hallucination) — شبیه دوستی که با اطمینان خاطره‌ای را اشتباه تعریف می‌کند — در سیستم‌های عامل‌محور (Agentic) است. در واقع، این رویکرد تلاش می‌کند شکاف میان «تولید متن» و «اتخاذ اقدام» را پر کند. همان‌طور که در تحلیل قبلی ما درباره‌ی تغییرات شخصیتی مدل‌های کلاود اشاره کردیم، مشکل اصلی این است که یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — ممکن است بگوید «کد را به‌روز کردم»، اما بدون یک کانال مطمئن، هیچ تغییری در سیستم فایل رخ نمی‌دهد. این رویکرد در واقع تکامل‌یافته‌ی ساختارهای دایرکتوری‌محور برای اتوماسیون کد است که پیش‌تر در جریان‌های کاری کلاود کد بررسی شده بود.
به نقل از مستندات فنی، یک LLM به‌تنهایی فقط متن تولید می‌کند و نمی‌تواند مستقیماً بر جهان خارج اثر بگذارد. ابزارها این شکاف را با دو سازوکار پر می‌کنند:
- اقدامات (Actions): ابزار یک تابع قابل‌اجرا را تعریف می‌کند تا مدل بتواند عملیاتی مثل خواندن فایل یا ارسال درخواست را انجام دهد.
- ساختار (Structure): یک JSON Schema ورودی‌ها را تعریف می‌کند تا هرگونه ورودی نامعتبر پیش از اجرا رد شود.
طبق گزارش‌های منتشرشده، تعریف ابزار در API آنتروپیک یک شیء JSON است که سه میدان اصلی دارد: name (شناسه منحصربه‌فرد)، description (راهنمای متنی برای زمان استفاده) و input_schema (قوانین اعتبارسنجی).
برای مثال، ابزار AskUserQuestion محدودیتی برای تعداد سوالات (بین ۱ تا ۴ مورد) تعریف کرده و الزام می‌کند که هر سوال حتماً با علامت سوال پایان یابد. این یعنی مدل دیگر اجازه ندارد بر اساس حدس و گمان عمل کند.
به گزارش وب‌سایت dev.to، کلاود کد تعاریف ابزار را در چهار لایه سازمان داده است تا مدل دقیقاً بداند چه زمانی و چگونه عمل کند:
- لایه اول: نام‌گذاری. استفاده از سیگنال‌های نام‌گذاری برای انتقال معنا به مدل.
- لایه دوم: توصیف سطح ابزار. راهنمایی متنی برای تعیین مرزهای رفتاری کلی (آیا این ابزار برای این تسک مناسب است؟).
- لایه سوم: توصیف سطح میدان. راهنمایی‌های دقیق برای پر کردن هر فیلد در
input_schema. - لایه چهارم: اعتبارسنجی طرح‌واره. استفاده از
typeوenumبرای مسدود کردن هرگونه ورودی غلط.
در این چرخه، تعاریف ابزار در هر درخواست API ارسال می‌شوند. این موضوع دو پیامد دارد: اول اینکه هر کلمه در توصیفات، هزینه توکن (Token) — تکه‌های کوچکی از متن شبیه برش‌های کیک — را بالا می‌برد. دوم اینکه ابزارها می‌توانند به یکدیگر ارجاع دهند؛ مثلاً ابزار AskUserQuestion صریحاً می‌گوید برای تأیید برنامه از ابزار ExitPlanMode استفاده کن.
وقتی ابزاری فعال می‌شود، یک مسیر رفت‌وبرگشتی سه‌مرحله‌ای طی می‌شود:
۱. مدل یک بلوک tool_use شامل شناسه و آرگومان‌های JSON تولید می‌کند.
۲. سیستم میزبان (Harness) دستور را اجرا کرده و نتیجه را می‌گیرد.
۳. نتیجه در قالب بلوک tool_result به مدل بازمی‌گرداند تا تصمیم بگیرد ابزار دیگری را فراخوانی کند یا پاسخ نهایی را بدهد.
یکی از چالش‌های جدی در این مسیر، مدیریت پنجره متنی (Context Window) است — میزان متنی که مدل هم‌زمان در ذهن نگه می‌دارد، شبیه میز کاری که فقط جای چند ورق دارد. اگر نتیجه یک دستور grep ۱۰۰ هزار خط باشد، حافظه مدل فوراً پر می‌شود. برای حل این مشکل، کلاود کد از استراتژی‌های خلاصه‌سازی، برش (Truncation) و صفحه‌بندی (Pagination) استفاده می‌کند.
در مورد مدیریت خطا، برخلاف پرامپت‌های آزاد که خطاها را می‌پوشانند، این سیستم از پرچم is_error: true استفاده می‌کند. این کار باعث ایجاد یک «شکست بلند» می‌شود که مدل را مجبور می‌کند خطا را بپذیرد و مسیر جدیدی (مثل تلاش مجدد یا درخواست کمک از کاربر) را انتخاب کند. برای محیط‌های حساس‌تر، می‌توان لایه‌های امنیتی سخت‌گیرانه‌تری را برای ابزارهای دیتابیس پیاده کرد تا ریسک‌های عملیاتی به حداقل برسد.
تفاوت این رویکرد با مهندسی پرامپت (Prompt Engineering) — یا همان هنر سؤال درست پرسیدن از یک مشاور — در جابجایی از «شهود» به «مشخصات» است. در پرامپت‌های آزاد، مدل بداهه عمل می‌کند و خطاها مخفی می‌مانند، اما در سیستم ابزاری، هر مورد با یک قرارداد رفتاری سخت‌گیرانه محدود شده است.
این تغییر نشان می‌دهد آینده عامل‌های هوش مصنوعی در مدل‌های بزرگ‌تر نیست، بلکه در «حفاظ‌های» (Guardrails) محکم‌تر است. تمرکز اکنون از «آموزش مدل» به «محدود کردن مدل» از طریق طرح‌واره‌ها تغییر کرده است.
گام بعدی شما
- جریان‌های کاری (Workflows) عامل‌محور خود را بررسی کنید تا ببینید کجا می‌توانید دستورات متنی را با JSON Schema جایگزین کنید.
- برای کاهش هزینه‌ها، توصیفات ابزارهای تکراری را بهینه‌سازی کنید تا مصرف توکن کاهش یابد.
- از سیستم «شکست بلند» برای عیب‌یابی سریع‌تر در پیاده‌سازی‌های Agentic استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو