در انتظار ارائه‌دهنده.

چگونه نادیده گرفته می‌شود

عامل شما تمام نشده، اما واقعاً هم فکر نمی‌کند. درخواست‌ها با خطای ظرفیت برمی‌گردند. بدون یک سیگنال واضح، کاهش سرعت ارائه‌دهنده می‌تواند مثل یک جلسه کند یا بی‌پاسخ به نظر برسد.

دو رد ارائه‌دهنده را در حین اجرای یک وظیفه تصور کنید. عامل ممکن است بی‌صدا تلاش مجدد کند، یا از پیشرفت مفید باز بماند. انتظار بیشتر هر مشکل سهمیه یا ظرفیتی را برطرف نمی‌کند، به‌ویژه وقتی چند جلسه محدودیت‌های یکسان را به اشتراک می‌گذارند.

آنچه ClawMetry شناسایی می‌کند

ClawMetry در نتایج ابزار و رویدادهای صریح خطای API به دنبال رد ظرفیت می‌گردد. کدهای وضعیت مانند HTTP 429 و HTTP 529 را همراه با متن محدودیت نرخ و اضافه‌بار تشخیص می‌دهد. ردهای مکرر یک هشدار ایجاد می‌کنند.

تفاوتی که یافته را تغییر می‌دهد

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

{
  "kind": "rate_limited",
  "severity": "warning",
  "evidence": {
    "refusals": 2,
    "threshold": 2,
    "threshold_source": "static",
    "observed": "HTTP 429/529 status or rate-limit text on tool results and API error events",
    "sample": ""
  }
}

آنچه بعداً باید بررسی کنید

وضعیت ارائه‌دهنده و محدودیت‌های حساب یا مدل در حال استفاده را بررسی کنید. در صورت مناسب بودن، کار همزمان را کاهش دهید یا منتظر بازنشینی محدودیت مربوطه باشید. سپس تأیید کنید که درخواست‌ها بازیابی می‌شوند به جای اینکه فرض کنید عامل از سر گرفته است.

1. وضعیت ارائه‌دهنده را بررسی کنید
2. سهمیه و همزمانی را بررسی کنید
3. تأیید کنید درخواست‌ها بازیابی می‌شوند