قابلیت جدید Anthropic، حجم درخواست ایجنت‌های هوش مصنوعی را از ۸۰۰ به ۱٫۸ کیلوبایت کاهش داد

شرکت Anthropic نسخه بتای عمومی قابلیت ترد پیام‌ها (Message Threads) را برای Messages API منتشر کرده است. این قابلیت وضعیت فعال گفتگو را در فاصله بین نوبت‌ها روی سرورهای Anthropic ذخیره می‌کند و به کلاینت‌ها اجازه می‌دهد به‌جای آپلود کل تاریخچه گفتگو در هر درخواست، تنها پیام‌های جدید را ارسال کنند.

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

چرا درخواست‌های سنگین در ایجنت‌ها با کندی مواجه می‌شوند؟

کاربران و برنامه‌های متصل به Messages API معمولاً در هر نوبت تمام پیام‌های قبلی و نتایج ابزارها را دوباره به سرور ارسال می‌کنند. یک ایجنت کدنویسی در طول فعالیت طولانی خود ممکن است صدها درخواست بفرستد و هم‌زمان محتوای فایل‌ها، تغییرات کد، خروجی دستورها و پاسخ‌های مدل را در زمینه خود انباشته کند. در مقیاس‌های بزرگ متنی، هر درخواست می‌تواند شامل چندین مگابایت داده در قالب JSON باشد که باید سریالسازی شده و از طریق پروتکل HTTPS آپلود شود.

قابلیت ترد پیام‌ها این چرخه ارسال را دگرگون می‌کند. در این شیوه، نخستین درخواست کل گفتگو را در بر می‌گیرد و یک ترد جدید باز می‌کند؛ اما درخواست‌های بعدی تنها حامل پیام‌های جدید و شناسه یکتایی هستند که پاسخ قبلی دریافت کرده است. بدین ترتیب Anthropic وضعیت قبلی را در سرور نگه می‌دارد و زمینه کامل گفتگو را برای Claude بازسازی می‌کند.

نتایج ملموس در ابزار Claude Code

شرکت Anthropic این قابلیت را در ابزار Claude Code ارزیابی کرده و میانگین نتایج را به شرح زیر گزارش داده است:

مدل Claude همچنان در هر نوبت کل گفتگو را پردازش می‌کند؛ بنابراین هزینه توکن‌های ورودی تغییری نمی‌کند. این صرفهجویی و کاهش زمان صرفاً ناشی از انتقال داده‌های بسیار کمتر میان کلاینت و سرورهای Anthropic پیش از شروع استنتاج مدل است.

تنها یکبار ارسال تاریخچه گفتگو

برای فعال‌سازی این قابلیت، افزودن پارامتر thread و هدر اختصاصی نسخه بتا در درخواست‌ها ضروری است. در مستندات API شرکت Anthropic ساختار و شمای دقیق این درخواست‌ها تشریح شده است.

1. ارسال کل گفتگو در نخستین درخواست Messages API.
2. ذخیره شناسه پاسخ بازگرداندهشده توسط سرورهای Anthropic.
3. ارسال صرفاً پیام‌های جدید در نوبت بعدی به‌همراه ارجاع به شناسه پاسخ قبلی.
4. تکرار این الگو تا زمانی که ترد همچنان فعال و معتبر است.
5. ارسال مجدد کل تاریخچه گفتگو در صورت انقضای ترد.

طول عمر پنج دقیق‌های و سازوکار مدیریت پایداری

تردها وضعیتی کوتاهمدت را در سمت سرور نگهداری می‌کنند؛ از این رو کلاینت‌ها در محیط‌های عملیاتی همچنان باید نسخه مرجع تاریخچه گفتگو را برای مواقع بازیابی نزد خود حفظ کنند.

بیشترین بهره برای پردازش‌های سنگین و طولانی

بارهایی که رفتوبرگشت پیاپی و داده‌های ارسالی سنگینی دارند، بیشترین کاهش تأخیر را تجربه می‌کنند:

• ایجنت‌های کدنویسی طولانیمدت: خواندن مداوم فایل‌ها، تغییرات کد، خروجی دستورات و بازخورد ابزارها به‌مرور حجم گفتگو را به‌شدت گسترش می‌دهند.
• ایجنت‌های تعامل با رایانه (Computer-Use): اسکرینشات‌ها در طول ترد ذخیره می‌مانند و نیازی نیست در هر نوبت دوباره آپلود شوند.
• فرایندهای مبتنی بر اسناد و تصاویر حجیم: فایل‌های پیوست بزرگ در ترد فعال حفظ می‌شوند، در حالی که کاربر صرفاً درخواست‌های متنی کوتاه بعدی را ارسال می‌کند.

مکالمات کوتاه با چند هزار توکن تغییر محسوسی احساس نخواهند کرد؛ اما حلقه‌های تعاملی ایجنت‌ها که طی دهها گام پیوسته باری بالغ بر ۵۰۰ هزار توکن را حمل می‌کنند، از حجم چشمگیری از آپلودهای تکراری بینیاز می‌شوند.

مدل همچنان تمامی توکن‌ها را پردازش می‌کند

قابلیت ترد پیام‌ها فرایند انتقال درخواست و مدیریت نشست‌های کوتاهمدت را بهینه می‌کند، اما سایر بخش‌های کلیدی رفتار API بدون تغییر باقی می‌مانند:

• محاسبه هزینه توکن‌ها همچنان بر پایه کل زمینه پردازششده توسط Claude انجام می‌پذیرد.
• سقف پنجره متنی مدل افزایش نیافته است.
• سازوکار ذخیره‌سازی موقت پرامپت (Prompt Caching) دستنخورده باقی می‌ماند.
• برنامه‌ها باید همچنان طول گفتگو را مدیریت و کنترل کنند.
• کلاینت‌ها موظفند وضعیت کافی برای بازیابی پس از انقضای ترد را نزد خود نگه دارند.

تیم‌هایی که از ایجنت‌های Claude با زمینه‌های متنی بزرگ استفاده می‌کنند، می‌توانند تنها با تغییری جزئی در ساختار درخواست‌ها و پیش‌بینی سازوکار انقضا، این امکان را به کار بگیرند. سنجش زمان تا دریافت اولین توکن و حجم درخواست‌ها مشخص خواهد کرد که آیا حجم داده‌های یک سرویس برای بهره‌گیری از این ویژگی به حد نصاب می‌رسد یا خیر.