مصرف توکن‌ها در تولید: تحلیل ساختاری هزینه‌ها در خطوط لوله چندعاملی

«توکنومیکس» (Tokenomics) در محیط سیستم‌های عاملی هوشمند، به معنای سنجش کمی توزیع واحدهای محاسباتی — یعنی توکن‌ها — در میان فازهای منطقی یک سیستم خودمختار است. این مفهوم هیچ ارتباطی با رمزارزها ندارد؛ بلکه متریک فیزیکی و بنیادینی است که مشخص می‌کند آیا یک سیستم چندعاملی (Multi-Agent) در محیط تولید واقعی از نظر مالی و عملیاتی توجیه‌پذیر است یا خیر. در عمل سیستم‌سازی، بارها دیده‌ام که وعده‌ی شیرین «نیروهای کار دیجیتال خودمختار» به محض برخورد با واقعیت هزینه‌های سرسام‌آور API و تأخیرهای محاسباتی (latency) فرو می‌پاشد. ما نمی‌توانیم سیستم‌هایی پایدار بسازیم مگر اینکه دقیقاً بدانیم توکن‌هایمان کجا مصرف می‌شوند.

برای مقیاس‌پذیری این ابزارها، باید از فرضیات کیفی فراتر برویم و داده‌های تجربی حاصل از ردگیری سیستم (execution traces) را تحلیل کنیم. یک مقاله پژوهشی اخیر با عنوان Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering دقیقاً همین خط مبنای تجربی را در اختیار ما قرار می‌دهد. پژوهشگران در این مطالعه، رفتار سیستم چندعاملی ChatDev را در جریان اجرای ۳۰ وظیفه توسعه نرم‌افزار با استفاده از مدل استدلال‌گر GPT-5 بررسی کرده‌اند. آن‌ها فازهای داخلی این سیستم را به فازهای کلاسیک چرخه حیات نرم‌افزار (SDLC) یعنی طراحی، کدنویسی، تکمیل کد، بازبینی کد (Code Review)، تست و مستندسازی نگاشت کردند تا توزیع فیزیکی مصرف توکن را اندازه‌گیری کنند.

نتایج این تحقیق دو ناکارآمدی ساختاری بزرگ را برملا می‌کند که هر مهندس هوش مصنوعی کاربردی باید برای آن‌ها چاره‌ای بیندیشد.

مالیات سنگین بازبینی کد

نخست، یافته‌های این پژوهش نشان می‌دهد که فاز بازبینی کد (Code Review) به تنهایی به‌طور میانگین ۵۹.۴٪ از کل توکن‌های مصرفی سیستم را به خود اختصاص می‌دهد. این یک موازنه‌ی (trade-off) بسیار مهم در طراحی سیستم است. در نگاه اول، ممکن است تصور شود که فاز «کدنویسی» — یعنی نوشتن خام نحو (syntax) — بیشترین هزینه را دارد. اما در عمل، تولید کدهای اولیه بسیار ارزان است؛ چالش و هزینه‌ی اصلی در فرآیندهای بازبینی، ارزیابی، هم‌راستاسازی و اصلاحات مکرر نهفته است.

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

گلگاه توکن‌های ورودی

دومین یافته‌ی کلیدی این است که توکن‌های ورودی (Input Tokens) با سهم میانگین ۵۳.۹ درصدی، بیشترین بخش مصرف را تشکیل می‌دهند. این پدیده خروجی مستقیم معماری پیام‌رسانی در فریم‌ورک‌های عاملی است. در یک سیستم چت‌محور سنتی، عامل‌ها با ارسال متون به یکدیگر تعامل می‌کنند. با هر گام جدید، تمام تاریخچه گفت‌وگو، دستورالعمل‌های سیستمی و وضعیت فعلی کد به عنوان Context به مدل فرستاده می‌شود.

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

این پدیده در عمل چه معنایی دارد؟

وقتی ما سیستم خودکارسازی اسناد حقوقی Mandamus & MOA را برای استخراج و نگارش لوایح قضایی از پرونده‌های حجیم طراحی می‌کردیم، دقیقاً با همین محدودیت ساختاری روبه‌رو شدیم. نگارش اسناد چندمرحله‌ای حقوقی، شباهت عجیبی به مهندسی نرم‌افزار دارد. اگر به سادگی تمام تاریخچه چت را بین عامل نویسنده و عامل ممیز دست‌به‌دست کنید، حجم توکن‌های ورودی به سرعت منفجر شده و توجیه اقتصادی پروژه از بین می‌رود. برای حل این مشکل، ما معماری مبتنی بر انتقال پیام (message-passing) را کنار گذاشتیم و به سمت مدیریت متمرکز وضعیت رفتیم.

با تکیه بر این داده‌های تجربی و تجربه‌های پیاده‌سازی خودم، سه راهکار کاربردی برای بهینه‌سازی معماری سیستم‌های چندعاملی در تولید پیشنهاد می‌کنم:

۱. جداسازی وضعیت از ارتباطات (Decoupling State): به جای ارسال مداوم تاریخچه گفتگوها بین عامل‌ها، وضعیت فعال پروژه (کدها یا اسناد تولیدشده) را در یک پایگاه داده متمرکز مانند SQL Server ذخیره کنید. عامل‌ها باید صرفاً تغییرات (diffs) یا بخش‌های خاصی از وضعیت را از طریق APIهای تعریف‌شده بخوانند و بنویسند. این کار مانع از انباشت نمایی کانتکست در پرامپت‌ها می‌شود.

۲. به‌کارگیری فعال کانتکست کشینگ (Context Caching): با توجه به اینکه بیش از ۵۳ درصد توکن‌ها ورودی هستند، کش کردن کانتکست‌های طولانی و ثابت مانند ساختار کلی ریپازیتوری، قوانین سیستمی و مستندات پایه در لایه‌ی API، هزینه‌ها را به شدت کاهش می‌دهد. این رویکرد، هزینه‌های متغیر سرسام‌آور را به یک هزینه‌ی زیرساختی قابل پیش‌بینی و کنترل‌شده تبدیل می‌کند.

۳. معماری نامتقارن مدل‌ها (Model Tiering): دلیلی ندارد برای تمام فازهای خط لوله از گران‌ترین مدل‌های استدلالی استفاده کنید. کارهایی نظیر نگارش مستندات ساده یا فاز ابتدایی تولید کدهای پایه را می‌توان به مدل‌های ارزان‌تر و سریع‌تر (مانند Gemini 2.5 Flash یا مدل‌های محلی روی Ollama) واگذار کرد. مدل‌های استدلالی رده‌بالا (مانند GPT-5) را صرفاً برای فاز بحرانی بازبینی و تست که ۵۹.۴٪ توکن‌ها را می‌بلعد نگه دارید؛ جایی که تفکر عمیق و منطق چندمرحله‌ای واقعاً مورد نیاز است.

در نهایت، مهندسی عامل‌ها یک مسئله‌ی تخصیص بهینه‌ی منابع است. برای ساخت سیستم‌های پایدار، باید با مصرف توکن با همان جدیتی برخورد کنیم که با مصرف رم (RAM) یا پهنای باند شبکه برخورد می‌کنیم. تنها با بهینه‌سازی این جنبه‌های عملیاتی است که می‌توان مهندسی نرم‌افزار عاملی را از یک آزمایش گران‌قیمت به یک زیرساخت مطمئن برای کسب‌وکارها تبدیل کرد.

منابع

• [2601.14470] Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering — Manual / ad-hoc · 2026-06-10