تصور کنید یک پشتیبان فنی هستید که باید یک زنجیره ایمیل ۵۰ موردی را تحلیل کند؛ در مدل‌های سنتی، این کار هزینه‌ای ۱۰ برابر یک پاسخ کوتاه دارد. اما حالا با مدل جدید Oxlo.ai، هزینه یک درخواست ساده با یک تحلیل پیچیده از هزاران توکن هیچ تفاوتی ندارد. در واقع، یک رشته ایمیل ۵۰ پیامی برای یک عامل پشتیبانی دقیقاً همان هزینه‌ای را دارد که یک تبادل ۳ پیامی در Oxlo.ai هزینه دارد.
این تغییر بنیادین، نقطه پایان عصر «بریدن تاریخچه گفتگو» برای نجات بودجه است. در دنیای فعلی، اکثر ارائه‌دهندگان مدل زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — بر اساس تعداد توکن‌ها هزینه می‌گیرند. بنابراین هرچه گفتگو طولانی‌تر شود، صورت‌حساب سنگین‌تر می‌شود. این موضوع باعث می‌شد توسعه‌دهندگان مجبور شوند تاریخچه گفتگو را کوتاه کنند تا از جهش‌های ناگهانی بودجه جلوگیری کنند. این رویکرد بخشی از استراتژی گسترده‌تر این شرکت برای پایان دادن به هزینه‌های توکنی و معرفی مدل قیمت‌گذاری به‌ازای هر درخواست است که پیش‌تر معرفی شده بود. همان‌طور که در تحلیل قبلی ما درباره‌ی مقیاس‌پذیری قیمت‌گذاری در ابزارهای آموزشی اشاره کردیم، این رویکرد جدید به عامل‌ها اجازه می‌دهد تا بدون جریمه‌های مالی توکن‌محور، آگاهی کامل از موقعیت (Situational Awareness) را حفظ کنند و تضاد بین دقت مدل و بودجه شرکت در محیط‌های عملیاتی (Production) برطرف شود.
طبق راهنمای فنی منتشر شده در ۲۶ ژوئیه ۲۰۲۶ در وب‌سایت dev.to، یک عامل پشتیبانی آماده‌ی تولید را می‌توان با اجزای کلیدی زیر پیاده کرد:
- موتور اصلی: سیستم از مدل Llama 3.3 70B برای تست‌های اولیه اتصال و از Qwen-3-32B برای حلقه اصلی عملیات عامل استفاده می‌کند.
- خروجی ساختاریافته: برای جلوگیری از پاسخ‌های طولانی و توصیفی (Prose-heavy)، عامل از طرح‌های Pydantic استفاده می‌کند تا مدل را مجبور به ارائه فرمت سخت‌گیرانه JSON کند. این خروجی شامل علت ریشه‌ای، ارجاعات به دفترچه راهنما (Runbook Citations) و سطح اطمینان است.
- یکپارچگی ابزارها: عامل از ابزار
search_runbookبرای پرس‌وجو از مستندات داخلی (مانند راهنمای SMTP یا OAuth) استفاده می‌کند، به جای آنکه صرفاً به دانش داخلی و احتمالاً قدیمی مدل تکیه کند.
زمینه فنی
برای ساخت این عامل، توسعه‌دهندگان به پایتون ۳.۱۰ یا نسخه‌های جدیدتر، کتابخانه‌های openai و pydantic و یک کلید API از سایت https://portal.oxlo.ai نیاز دارند. فرآیند با یک «تست دود» (Smoke Test) آغاز می‌شود که در آن SDK شرکت OpenAI روی آدرس پایه Oxlo.ai یعنی https://api.oxlo.ai/v1 تنظیم می‌شود. یک درخواست ساده از مدل Llama 3.3 70B برای ارسال عبارت «Say ok» تأیید می‌کند که نقطه اتصال (Endpoint) و کلید API فعال هستند، پیش از آنکه توسعه‌دهنده وارد منطق پیچیده عامل شود.
جزئیات اجرایی
در جزئیات اجرایی، این عامل تحت یک پرامپت سیستمی سخت‌گیرانه عمل می‌کند که سه شرط اصلی دارد: بیان علت ریشه‌ای در تنها یک جمله، فراخوانی ابزار search_runbook و ارائه پاسخی آرام و دقیق به مشتری. کل خروجی باید در قالب JSON سخت‌گیرانه و بدون هیچ‌گونه علامت‌های Markdown (مانند فنس‌های کد) باشد.
- طرح Pydantic: کلاس
TicketResolutionفیلدهایی برای علت ریشه‌ای (root_cause)، بخش مربوطه در دفترچه راهنما (runbook_section)، پیش‌نویس پاسخ (draft_reply) و سطح اطمینان (confidence) تعریف می‌کند که مقدار اخیر تنها می‌تواند «بالا»، «متوسط» یا «پایین» باشد. - پایگاه داده راهنما (Runbook DB): عامل یک دیکشنری حاوی راهنمایی‌های فنی حیاتی را جست‌وجو می‌کند. برای مثال، بخش ۴.۲ برای تأخیرات تحویل SMTP/DNS، بخش ۷.۱ برای بازپرداخت‌های صورت‌حساب (که مستلزم فعال بودن کمتر از ۱۴ روز و مصرف کمتر از ۱۰ گیگابایت است) و بخش ۹.۳ برای عدم تطابق URIهای هدایت OAuth. این قابلیت جست‌وجوی هوشمند در مستندات، یادآور روش‌های اتوماسیون طبقه‌بندی اسناد در Oxlo.ai است که بدون نیاز به زیرساخت‌های پیچیده محلی عمل می‌کند.
- مکانیسم حلقه عامل: تابع
resolve_ticketکل رشته گفتگو و پرامپت سیستمی را به مدل می‌فرستد. اگر مدل یک فراخوانی ابزار (Tool Call) را فعال کند، سیستم ابزارsearch_runbookرا با کلمه کلیدی ارائه‌شده اجرا کرده و نتیجه را به تاریخچه گفتگو بازمی‌گرداند. سپس یک درخواست نهایی برای دریافت خروجی JSON ساختاریافته ارسال می‌شود.
برای گفتگوهای بسیار پیچیده یا مبهم، جریان کاری می‌تواند به مدل DeepSeek R1 671B ارجاع داده شود. به لطف API قیمت‌ثابت، استفاده از چنین مدل‌های استدلالی عظیم (Reasoning Models) — که شبیه شطرنج‌بازی هستند که چند حرکت جلوتر را می‌بیند — دیگر باعث افزایش متناسب هزینه‌ها و ورشکستگی مالی پروژه نمی‌شود.
این تغییر، مدیریت پنجرهٔ زمینه (Context Window) — که مثل میز کاری است که جا برای چند ورق دارد، نه برای کل کتابخانه — را متحول می‌کند. توسعه‌دهندگان دیگر نیازی به ساخت لایه‌های پیچیده برای خلاصه‌سازی متن (Summarization) یا بافرهای لغزان (Sliding-window buffers) ندارند تا هزینه API قابل پیش‌بینی باشد. مرکز هزینه از «مقدار داده پردازش شده» به «تعداد تعاملات» تغییر مکان داده است.
از نظر مالی، این یعنی هزینه یک تیکت دو صفحه‌ای با یک سلام ساده برابر است. برای مثال، تحلیل یک رشته گفتگو طولانی شامل خطای تایم‌اوت ۴.۴.۷ و مسائل انتشار رکورد SPF، دقیقاً همان هزینه‌ای را دارد که حل یک سلام و احوالپرستی ساده. حالا چالش فنی از «بهینه‌سازی هزینه» به «بهبود خالص دقت حلقه فراخوانی ابزار» تغییر یافته است.
شما می‌توانید دیکشنری ساده راهنما را با یک پایگاه‌داده برداری حرفه‌ای مثل pgvector یا Milvus جایگزین کنید تا از یک نمونه اولیه به یک خط لوله تولیدی کامل برسید. برای اطلاعات بیشتر در مورد قیمت‌گذاری ثابت برای هر درخواست، به https://oxlo.ai/pricing مراجعه کنید.
گام بعدی شما
- بررسی مدل‌های قیمت‌گذاری در
https://oxlo.ai/pricingبرای تخمین بودجه پروژه‌های عامل‌محور. - جایگزینی متدهای خلاصه‌سازی متن با ارسال تاریخچه کامل در APIهای قیمت‌ثابت.
- آزمایش مدل DeepSeek R1 روی داده‌های حجیم بدون نگرانی از هزینه توکن‌ها.
باید منتظر ماند و دید آیا سایر ارائه‌دهندگان استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند و شبیه خودِ آشپزی است — به این مدل قیمت‌گذاری واکنش نشان می‌دهند یا خیر؛ زیرا این رویکرد می‌تواند یک تغییر گسترده در صنعت ایجاد کند و استاندارد ریزشمار توکن‌ها را کنار بزند.
گفتگو