چرا چت‌های طولانی با هوش مصنوعی، هزینه استنتاج شما را به‌شدت بالا می‌برد؟

اگر امروز برای یک عامل کدنویسی هوش مصنوعی هزینه پرداخت می‌کنید، احتمالاً در هر پرامپت مبلغی را به عنوان «مالیاتِ زمینهٔ کهنه» می‌پردازید. تصور کنید در سی‌امین پیام یک جلسه، متوجه می‌شوید که در واقع دارید به یک عامل کدنویسی پول می‌دهید تا دوباره استک‌تریس‌ها (stack traces)، برنامه‌های رها شده، مستندات پکیج‌ها و فرضاتی را که یک ساعت پیش مطرح شده بودند، بازخوانی کند. این روند توکن‌ها و بودجه شما را بدون افزودن هیچ ارزش جدیدی می‌سوزاند. صورت‌حساب نهایی این نشت هزینه را پنهان می‌کند؛ زیرا ردیفی در فاکتور وجود ندارد که بگوید: «زمینهٔ کهنه: ۳۰ دلار».

به گزارش توسعه‌دهنده این پروژه، جیم زاندوئتا، در ۶ ژوئن ۲۰۲۶ ابزاری به نام oowl معرفی شد تا این نشت هزینه را با شکستن یک چت طولانی به قطعات کوچک و هدفمند یا همان آرتیفکت‌ها (Artifacts) متوقف کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مدیریت حافظه در مدل‌های زبانی اشاره کردیم، حجم زیاد داده‌های ورودی لزوماً به معنای دقت بیشتر نیست و گاهی باعث سردرگمی مدل می‌شود.

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

oowl برای حل این مشکل با فریم‌ورک OpenCode ادغام شده است تا یک خط لوله (Pipeline) ساختاریافته ایجاد کند. طبق مستندات این پروژه، دلیل انتخاب OpenCode پشتیبانی بومی آن از سوارم (Swarm) — که شبیه به تیمی از متخصصان است که هر کدام وظیفهٔ خاصی دارند و توسط یک مدیر هماهنگ می‌شوند — است. این قابلیت به عامل اصلی اجازه می‌دهد تا در طول یک اجرا، چندین عامل دیگر را فعال کرده و به هر یک، پرامپت و مدل خاصی را اختصاص دهد. در این ساختار، به‌جای یک چت واحد، یک توزیع‌کننده (Dispatcher) درخواست‌ها را به نقش‌های تخصصی می‌فرستد. هر مرحله یک آرتیفکت دائمی (مثل design.md یا implementation.md) تولید می‌کند که تنها منبع اطلاعاتی برای عامل بعدی در زنجیره است.

مکانیزم گردش کار oowl

این فرآیند برای حفظ مرزهای اطلاعاتی از یک توالی سخت‌گیرانه پیروی می‌کند:

• درخواست $
  ightarrow$ توزیع‌کننده: هدایت وظیفه به مسیر درست.
• معمار: نوشتن آرتیفکت design.md برای تأیید کاربر.
• برنامه‌ریز: تبدیل طرح به برنامهٔ اجرایی دقیق در implementation.md برای تأیید کاربر.
• سازنده: زمان‌بندی وظایف قفل‌شده برای جلوگیری از تداخل در ویرایش‌ها.
• عامل‌های اجرا: نقش‌های تخصصی (فرانت‌اند، بک‌اند، دیتابیس، تست و امنیت) کد را می‌زنند.
• بازبین: نوشتن review.md برای تطبیق و اعتبارسنجی نتیجه با برنامهٔ اولیه.

جزئیات آرتیفکت‌های محدود و کنترل

با جایگزینی متن کامل گفتگو با آرتیفکت‌های محدود، سیستم «انحراف در اجرا» (Implementation Drift) و تصمیمات معماری نامرئی را حذف می‌کند. هر انتقالِ وظیفه، یک رکورد به جا می‌گذارد:

• طرح و برنامه: ثبت معماری و تجزیهٔ کار (Work Breakdown) پیش از آنکه عامل‌ها به فایل‌ها دست بزنند.
• قفل فایل‌ها: تعیین محدوده و جلوگیری از ویرایش‌های غافلگیرکننده.
• خروجی تأیید: ثبت شواهد عینی مبنی بر تکمیل کار.
• سند بازبینی: ثبت چک‌لیست و بررسی نهایی.

این یعنی عامل فرانت‌اند فقط وظیفهٔ رابط کاربری و فایل‌های مربوطه را می‌خواند، در حالی که عامل دیتابیس فقط طرحواره (Schema) و یادداشت‌های مهاجرت را می‌بیند. بازبین نیز به‌جای کل تاریخچهٔ چت، فقط برنامه، تغییرات (Diff) و خروجی تأیید را بررسی می‌کند. این امر تضمین می‌کند که اعتبارسنجی بر اساس شواهد واقعی باشد، نه بر اساس حافظهٔ احتمالی مدل از یک پرامپت قدیمی.

نقشه‌برداری مدل‌ها و بهینه‌سازی هزینه

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

• ارزان (deepseek-v4-flash): برای توزیع‌کننده، سازنده و نقش‌های مهندسی سطح پایین.
• متوسط (minimax-m2.7): برای معمار، برنامه‌ریز، مهندسان فرانت‌اند، بک‌اند و بازبین.
• متوسط (deepseek-v4-pro): مخصوص مهندس دیتابیس.
• گران‌قیمت (qwen3.7-max / glm-5.1): برای موارد پیچیدهٔ معماری (High-architect escalation) و حسابرس امنیتی.

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

برای شروع، توسعه‌دهندگان می‌توانند دستور npx @jimzandueta/oowl install opencode را در ریشهٔ پروژه اجرا کنند. این دستور فریم‌ورک OpenCode، شامل عامل‌ها، دستورات اسلش، پرامپت‌های گردش کار، قوانین حفاظت از مشخصات (Spec rules)، قوانین قفل فایل، الزامات تأیید، پروفایل‌های مدل، پیکربندی زمان اجرا (Runtime config) و دستورالعمل‌های گردش کار را نصب می‌کند. همچنین دستور oowl init برای تحلیل ساختار پروژه و پیشنهاد مهارت‌های اضافی برای هر عامل در دسترس است.

زاندوئتا قصد دارد این گردش کار را به ابزارهایی مثل Codex و Claude Code نیز منتقل کند. در این صورت ممکن است نام پروژه به 'cowl' تغییر یابد و تصمیم بگیرند که آیا لوگوی جغد باقی می‌ماند یا جای خود را به یک «گاو بسیار جدی» می‌دهد.

چه یک پروژه تک‌نفره داشته باشید و چه یک تیم، درس اصلی این است که «زمینه یا کانتکست، خود یک هزینه است». حالا می‌توانید بهره‌وری هزینه‌های AI خود را با بررسی میزان اتکای عامل‌ها به آرتیفکت‌ها در برابر تاریخچهٔ خام چت ردیابی کنید.