نسبت ورودی‌های تکراری؛ عامل پنهان اتلاف بودجه در عامل‌های کدنویسی

مدیران فنی تیم‌های نرم‌افزاری اغلب با این تناقض روبه‌رو هستند که ابزارهای کدنویسی هوش مصنوعی بهره‌وری را بالا می‌برند، اما در عمل، هر درخواست تغییر کد (Pull Request) را به یک صورت‌حساب مرموز تبدیل می‌کنند. تیم‌های توسعه معمولاً به صورت‌حساب‌های ماهانه مدل‌ها تکیه می‌کنند، اما این خلاصه‌ها یک الگوی خطرناک را می‌پوشانند: جلساتی که بارها یک زمینه (Context) یکسان را می‌خوانند، منتظر تأییدیه‌های متوقف‌شده می‌مانند، برنامه‌های ضعیف را چندین بار تکرار می‌کنند و برای ارسال یک تغییر کوچک (Diff)، مدام بین ابزارهای مختلف جابه‌جا می‌شوند.

بر اساس راهنمایی که در ۱ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، راهکار خروج از این وضعیت، حرکت از «داشبوردهای مجموع هزینه» به سمت یک «دفتر کل هزینه‌های تراکنشی» (Transaction-based cost ledger) است. این تغییر رویکرد از آن جهت اهمیت دارد که جریان‌های کاری مبتنی بر عامل (Agentic Workflows) به‌طور بنیادی پیچیده‌تر و «کثیف‌تر» از فراخوانی‌های کلاسیک API هستند. در یک فراخوانی سنتی API، هزینه ساده است: یک نقطه اتصال (Endpoint) فراخوانده می‌شود و سیستم تعداد درخواست‌ها، شناسه مشتری یا فضای کاری، زمان پاسخ و هزینه ارائه‌دهنده را رصد می‌کند.

اما عامل‌های کدنویسی متفاوت‌اند. یک وظیفه واحد اکنون شامل زنجیره‌ای از ساخت پرامپت‌ها، جستجو در مخزن کد، خواندن فایل‌ها، اجرای دستورات شل (Shell)، اجرای تست‌ها، ویرایش‌های شکست‌خورده، تلاش‌های مجدد مدل، فراخوانی ابزارها، توقف برای تأییدیه و در نهایت ایجاد PR در چندین مدل مختلف است. شما ممکن است از یک مدل ارزان برای خلاصه‌سازی لاگ‌ها استفاده کنید، در حالی که یک مدل با استدلال بالا (High-reasoning) برای برنامه‌ریزی اصلاحیه به کار می‌رود و مدل دیگری تغییرات نهایی را بازبینی می‌کند. اگر شما فقط درخواست نهایی را رصد کنید، اقتصاد واقعی این گردش کار را از دست داده‌اید.

تصور کنید ابزار توسعه‌دهنده را به جای جریانی از درخواست‌ها، به صورت مجموعه‌ای از «جلسات» (Sessions) مجزا ببینید. برای یک عامل کدنویسی، «جلسه» واحدِ کار است. یک واحد کاری در یک جلسه می‌تواند چیزی مثل «رفع باگ تکرار وب‌هوک استرایپ»، «افزودن دکبه خروجی به جدول فاکتورها»، «بازسازی تست‌های ایمیل ورود کاربر» یا «بررسی کندی عملیات ingest در RAG» باشد. با متصل کردن هر رویداد هزینه به یک session_id است، شما را قادر می‌سازد تا در نهایت هزینه‌ها را به نتایج مشخصی متصل کنید؛ نتایجی مانند یک PR ادغام‌شده، تست‌های پاس‌شده یا یک Issue حل‌شده. این سطح از شفافیت، هزینه را از یک مشکل مالی به یک اهرم طراحی محصول تبدیل می‌کند که بر مسیریابی مدل، محدودیت‌های زمینه، گیت‌های تأییدیه، قالب‌های گردش‌کار و قیمت‌گذاری اثر می‌گذارد. اگر نتوانید هزینه را به نتیجه متصل کنید، نقشه راه عامل شما بر اساس حدس و گمان است.

سازوکارهای دفتر کل هزینه

هدف از ایجاد یک دفتر کل هزینه برای عامل‌های کدنویسی، ثبت ساختاریافته هر رویداد هزینه معنادار در طول یک جلسه توسعه است. هدف در اینجا حسابداری کامل و بی‌نقص نیست، بلکه دستیابی به «شفافیت در سطح تصمیم‌گیری» است. این سیستم به شما اجازه می‌دهد به این نتیجه برسید که، برای مثال، یک عامل ۸.۴۰ دلار هزینه کرده و ۴۲ دقیقه زمان صرف کرده تا یک اصلاحیه ۱۲ خطی تولید کند، اما ۷۸٪ از این هزینه صرف بازخوانی زمینه‌هایی شده است که هیچ تغییری نکرده بودند.

یک دفتر کل قدرتمند باید هر رویداد هزینه معنادار را به صورت یک رکورد «فقط-افزودنی» (Append-only) ثبت کند. این کار باعث می‌شود بی‌اعتمادی‌هایی که در اثر استفاده از شمارنده‌های قابل تغییر (Mutable counters) در جریان‌های کاری پیش‌بینی‌ناپذیر ایجاد می‌شود، از بین برود. یک شیء جلسه (Session Object) در سطح حداقلی باید موارد زیر را رصد کند:

• شناسه‌ی جلسه (session_id) مانند "ags_01J..."
• شناسه‌ی مستاجر یا مشتری (tenant_id) مانند "team_123"
• نام مخزن کد (repo) مانند "billing-api"
• نوع بازیگر (actor_type) مانند "coding_agent"
• عنوان وظیفه (task_title) مانند "Fix duplicate webhook retries"
• برچسب‌های زمانی شروع و پایان (started_at و ended_at)
• وضعیت جلسه (status) مانند "completed"
• نتیجه نهایی (outcome) مانند "pull_request_opened"
• لینک PR مربوطه (pr_url)
• سطح ریسک (risk_tier) مانند "medium"

درخواست‌های مدل در این جلسات باید فراتر از توکن‌ها رصد شوند. شما باید موارد زیر را ثبت کنید:

• توکن‌های ورودی و خروجی
• برخوردها و عدم برخوردها با کش (به‌ویژه cached_input_tokens)
• هزینه تخمینی ارائه‌دهنده
• هدف مشخص از فراخوانی (مانند patch_plan برای برنامه اصلاح، repo_scan برای اسکن مخزن، debug برای عیب‌یابی، review برای بازبینی، summarize برای خلاصه‌سازی یا handoff برای تحویل وظیفه)
• متاداده‌ها شامل نسخه‌های پرامپت (مثلاً "coding-agent-plan-v7") و کلیدهای کش

فراخوانی ابزارها و رویدادهای تأییدیه (Verification) به همان اندازه حیاتی هستند. ثبت این موارد به صورت رویدادهای فقط-افزودنی، یک ردپای قابل حسابرسی از رفتار عامل ایجاد می‌کند. برای مثال، رکورد یک فراخوانی ابزار باید شامل نام ابزار (tool_name مانند read_file)، هدف (target مانند src/webhooks/stripe.ts) و مقدار بایت‌های خوانده شده (bytes_read) باشد. یک رویداد تأییدیه نیز باید دستور خاص اجرا شده (مثلاً npm test -- webhook)، وضعیت (passed)، مدت‌زمان (duration_ms) و این نکته که آیا تست پیش از اصلاحیه شکست خورده بود یا خیر را رصد کند.

تحلیل سیگنال‌های فعلی در کارهای عامل‌محور

بحث‌های اخیر توسعه‌دهندگان از «آیا عامل‌ها می‌توانند کد بزنند؟» به «آیا می‌توانند بدون اتلاف بودجه، کارهای واقعی را به‌طور قابل‌اطمینان انجام دهند؟» تغییر یافته است. روندی رو به رشد برای استفاده از لایه‌های مشاهده‌پذیری (Observability) و Sidecarهای محلی برای جلسات کدنویسی دیده می‌شود. برخی گزارش‌های اخیر با اندازه‌گیری میلیاردها توکن پرامپت در جلسات واقعی، دریافته‌اند که بخش اعظم ورودی‌ها صرف تکرار زمینه‌های یکسان شده است. این چرخه‌های تکراری گاهی منجر به بحران‌های مصرفی می‌شوند که برای مقابله با آن‌ها، ابزارهایی نظیر ai-loopguard برای توقف چرخه‌های مرگبار عامل‌ها توسعه یافته‌اند تا از اتلاف بی‌دلیل منابع جلوگیری کنند.

سیگنال‌های دیگر نشان می‌دهند که کدنویسی مبتنی بر عامل در حال حرکت از مرحله «دمو» به «جریان‌های کاری روزمره توسعه‌دهندگان» است. این گذار با موارد زیر همراه است:

• رقابت قیمتی بین مدل‌های وزن‌های باز (Open-weight) و مدل‌های بسته که باعث تغییر در انتخاب‌های مسیریابی (Routing) می‌شود.
• آزمایش با ابزارهای MCP (پروتکل زمینه مدل)، عامل‌های مرورگر (Browser Agents) و عامل‌های محلی.
• تغییر محور بحث‌های بودجه از «دسترسی کلی به مدل» به «اقتصاد واحد» (Unit Economics).
• الزامات امنیتی و انطباقی (Compliance) که اکنون انتخاب مدل را به ردپاهای حسابرسی (Audit trails) گره می‌زند.

سنجش ۵ معیار اتلاف بودجه

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

۱. هزینه کل جلسه: مجموع هزینه‌های مدل، ابزارها و محیط‌های Sandbox. فرمول: session_cost = sum(model_cost + tool_cost + sandbox_cost). حتی اگر هزینه ابزارها امروز صفر باشد، رصد آن از شما در برابر قیمت‌گذاری‌های آینده برای اتوماسیون مرورگر، سندباکس‌های میزبانی‌شده، APIهای جستجو، بازیابی برداری و اجرای بیلدها محافظت می‌کند. در این راستا، مفاهیمی مانند پروتکل FLAT برای شکستن گلوگاه‌های بودجه به دنبال ایجاد استقلال مالی برای عامل‌ها هستند تا مدیریت هزینه‌ها به صورت توزیع‌شده‌تر صورت گیرد.

۲. نسبت ورودی‌های تکراری: محاسبه شده به صورت repeated_input_tokens / total_input_tokens. نسبت بالا نشان می‌دهد عامل بیش از حد در حال بازخوانی زمینه مخزن، لاگ‌ها، مستندات یا وضعیت گفتگوهای قبلی است. این وضعیت نیاز به موارد زیر را نشان می‌دهد:

• کش‌های خلاصه‌ساز مخزن
• هضم‌های (Digests) سطح فایل
• بسته‌های زمینه (Context Packets)
• محدودیت‌های بازیابی (Retrieval Limits)
• قراردادهای وظیفه قوی‌تر و تحویل‌های کوتاه‌تر بین جلسات.

۳. هزینه به ازای هر تغییر پذیرفته‌شده: هزینه جلسه تقسیم بر خطوط کد پذیرفته‌شده در Diff. اگرچه این معیار کامل نیست، اما مواردی را برجسته می‌کند که عامل بدون تولید خروجی، در حال چرخش (Churn) است. سیگنال‌های ارزشمندتر شامل این موارد است:

• تعداد PRهای ادغام‌شده
• تعداد Issueهای بسته شده
• تست‌های اضافه شده
• باگ‌های بازتولید شده
• حوادث (Incidents) کاهش یافته
• مهاجرت‌های (Migrations) تکمیل شده.

۴. زمان انتظار برای تأیید (Idle Approval Time): تفاضل بین زمان درخواست تأیید و زمان پاسخ آن (approval_resolved_at - approval_requested_at). زمان انتظار بالا نشان‌دهنده نیاز به سطوح ریسک بهتر، مسیریابی بازبین‌ها، تأیید خودکار برای اقدامات کم‌ریسک، محموله‌های تأیید شفاف‌تر یا تایم-اوت‌ها با قابلیت بازگشت ایمن (Safe rollback) است.

۵. پوشش تأییدیه (Verification Coverage): وجود شواهدی مبنی بر اینکه اصلاحیه واقعاً کار می‌کند. این شامل یک تست شکست‌خورده پیش از اصلاح، یک تست پاس‌شده بعد از آن، خروجی‌های Lint/Typecheck، اسکرین‌شات‌ها یا Traceها برای تغییرات UI، اجرای آزمایشی مهاجرت‌ها یا یک برنامه بازگشت (Rollback plan) است. یک جلسه ارزان که کدی تست‌نشده ارسال می‌کند، در واقع ارزان نیست.

معماری پیاده‌سازی

برای کسانی که این سیستم را می‌سازند، یک طرح (Schema) فشرده در Postgres پیشنهاد می‌شود. جدول agent_sessions متاداده‌ها را مدیریت می‌کند و جدول agent_cost_events از یک ستون jsonb برای متاداده‌های منعطف استفاده می‌کند:

create table agent_sessions (
 id text primary key, 
 tenant_id text not null, 
 repo text not null, 
 task_title text not null, 
 actor_type text not null, 
 risk_tier text not null default 'low', 
 status text not null, 
 outcome text, 
 pr_url text, 
 started_at timestamptz not null, 
 ended_at timestamptz 
);

create table agent_cost_events (
 id text primary key, 
 session_id text not null references agent_sessions(id), 
 event_type text not null, 
 occurred_at timestamptz not null, 
 model text, 
 tool_name text, 
 purpose text, 
 input_tokens integer default 0, 
 output_tokens integer default 0, 
 cached_input_tokens integer default 0, 
 estimated_cost_usd numeric(12, 6) default 0, 
 duration_ms integer, 
 status text, 
 metadata jsonb not null default '{}'
);

create index idx_agent_cost_events_session on agent_cost_events(session_id);
create index idx_agent_cost_events_type on agent_cost_events(event_type);
create index idx_agent_cost_events_metadata on agent_cost_events using gin(metadata);

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

برچسب‌های طبقه‌بندی (Classifier labels) برای مفید بودن این داده‌ها ضروری هستند. بدون برچسب‌های هدف مانند repo_scan، plan، patch، debug، review، summarize و handoff تمام هزینه‌ها یکسان به نظر می‌رسند. با این برچسب‌ها، می‌توانید تشخیص دهید که مثلاً بیشتر هزینه‌ها ناشی از اسکن‌های تکراری است یا اینکه فراخوانی‌های بازبینی (Review) ارزان اما در یافتن خطاها بسیار مؤثر هستند.

تصمیمات محصولی بر اساس داده

هشدار‌های کلی مانند «هزینه‌های AI حدود ۱۲٪ افزایش یافت» بی‌فایده‌اند. هشدارهای مؤثر باید عملیاتی باشند و به یک ردپای (Trace) جلسه خاص اشاره کنند. نمونه‌ها عبارتند از:

• هزینه جلسه از p95 مربوط به آن مخزن خاص فراتر رفته است.
• نسبت ورودی تکراری از ۶۰٪ بیشتر شده است.
• تعداد تلاش‌های مجدد مدل (Retry) از سه بار فراتر رفته است.
• انتظار برای تأیید بیش از ۳۰ دقیقه طول کشیده است.
• فراخوانی ابزارها از بودجه پیش‌بینی شده برای آن گردش‌کار فراتر رفته است.
• هیچ رویداد تأییدیه‌ای پیش از ایجاد PR رخ نداده است.
• ابزاری با ریسک بالا بدون تاییدیه استفاده شده است.

این بینش‌ها باید ۵ تصمیم محصولی مشخص را هدایت کنند:
۱. انتخاب مسیر درست مدل: اگر فراخوانی‌های برنامه‌ریزی گران هستند اما از ایجاد اصلاحات بد جلوگیری می‌کنند، آن‌ها را قوی نگه دارید. اگر فراخوانی‌های خلاصه‌سازی گران و کم‌ریسک هستند، آن‌ها را به مدل‌های ارزان‌تر هدایت کنید.
۲. بهبود مهندسی زمینه: اگر نسبت ورودی تکراری بالاست، پیش از تغییر مدل، حجم زمینه را کاهش دهید. پنجره‌های متنی بزرگ می‌توانند اتلاف را پنهان کنند، اما آن را حذف نمی‌کنند.
۳. تعیین بودجه مستاجر (Tenant Budgets): در محصولات چندمستاجری، هزینه‌ها را به شناسه مستاجر و فضای کاری متصل کنید تا استفاده منصفانه را اجرا کرده، سوءاستفاده‌ها را شناسایی کنید و قیمت‌گذاری را بدون حدس و گمان طراحی کنید.
۴. بازنویسی قالب‌های گردش‌وار: اگر یک گردش‌وار مدام در مرحله تأییدیه شکست می‌خورد، احتمالاً مشکل از قالب وظیفه (Task Template) است، نه مدل. ابتدا قرارداد وظیفه را بهبود ببخشید.
۵. تعیین اولویت اتوماسیون: بهترین کاندیداهای اتوماسیون، وظایفی هستند که در آن‌ها هزینه، نرخ موفقیت و شواهد تأییدیه با هم هم‌راستا باشند.

ایمنی و استقرار

از آنج که دفترهای کل هزینه ممکن است به‌طور تصادفی داده‌های حساس را ذخیره کنند، باید به عنوان مخازن امن مدیریت شوند. به‌جای ذخیره پرامپت‌های خام یا تکه‌های کامل کد، موارد زیر را ترجیح دهید:

• شناسه‌ی نسخه‌ی پرامپت
• هش (Hash) بسته‌های بزرگ زمینه
• مسیر فایل‌ها به جای محتوای کامل فایل
• ورودی‌های پاکسازی‌شده (Redacted) ابزارها
• فیلدهای خلاصه‌شده
• ارجاعات رمزگذاری‌شده به آرتیفکت‌ها
• پنجره‌های زمانی کوتاه برای نگهداری Traceهای خام

علاوه بر این، جداسازی سخت‌گیرانه مستاجران (Tenant Isolation) را اجرا کنید. یک جلسه مربوط به یک مشتری هرگز نباید در تحلیل‌های مشتری دیگر ظاهر شود، حتی در نماهای تجمیعی که حجم نمونه‌های کوچک می‌تواند باعث نشت اطلاعات شود. داشبوردهای ادمین باید جزئیات کافی برای عیب‌یابی الگوهای هزینه را داشته باشند بدون اینکه اسرار تجاری را افشا کنند.

استقرار باید در ۵ مرحله رخ دهد:

• مرحله ۱: ثبت جلسات و فراخوانی‌های مدل. رصد شناسه جلسه، مدل، توکن‌ها، هزینه، هدف و نتیجه برای شفافیت فوری.
• مرحله ۲: افزودن رویدادهای ابزاری و تأیید. ثبت خواندن/نوشتن فایل‌ها، دستورات، تست‌ها و توقف‌های تأیید برای توضیح هزینه‌های جلسه.
• مرحله ۳: ایجاد گزارش‌های تجمیعی (Rollups). ایجاد خلاصه‌های روزانه بر اساس مخزن، مستاجر، مدل، هدف و نوع گردش‌وار.
• مرحله ۴: افزودن بودجه‌ها و هشدارها. ابتدا بودجه‌های نرم (Soft budgets) را تعریف کنید و هنگام انحراف جلسات به توسعه‌دهندگان اطلاع دهید. توقف‌های سخت (Hard stops) را تنها پس از درک الگوهای نرمال اضافه کنید.
• مرحله ۵: بازگرداندن بینش‌ها به عامل. استفاده از داده‌های دفتر کل برای بهبود مسیریابی، محدودیت‌های زمینه، سیاست‌های تأیید و قالب‌های گردش‌وار.

پرسش‌های متداول

آیا این روش با مشاهده‌پذیری (Observability) LLM متفاوت است؟
بله. مشاهده‌پذیری روی Traceها، تأخیر (Latency)، خطاها و دیباگ تمرکز دارد. دفتر کل هزینه روی پاسخگویی مالی و گردش‌وار تمرکز دارد: کدام جلسات هزینه بردند، چرا، و آیا نتیجه آن هزینه را توجیه کرد؟

آیا توسعه‌دهندگان تک‌نفره باید این سیستم را بسازند؟
بله، اما کوچک شروع کنند. یک فایل CSV، جدول SQLite یا یک طرح ساده Postgres کافی است. رصد شناسه جلسه، مدل، توکن‌ها، هزینه تخمینی، وظیفه و نتیجه را ثبت کنید. عادت به رصد هزینه مهم‌تر از ابزاری است که استفاده می‌کنید.

اولین متریکی که باید رصد کرد چیست؟
نسبت ورودی تکراری. این معیار اغلب سریع‌تر از هزینه کل، اتلاف‌های پنهان را برملا می‌کند زیرا عامل‌های کدنویسی معمولاً زمینه مخزن، لاگ‌ها و دستورالعمل‌ها را در طول یک جلسه بارها بازخوانی می‌کنند.

این روش چگونه به قیمت‌گذاری AI SaaS کمک می‌کند؟
این کار مصرف را به اقتصاد واحد (Unit Economics) متصل می‌کند. شما می‌بینید کدام مستاجران، گردش‌وارها، مدل‌ها و ویژگی‌ها باعث ایجاد هزینه می‌شوند و در نتیجه محدودیت‌های استفاده و سیاست‌های استفاده منصفانه را کمتر بر اساس حدس و گمان طراحی می‌کنید.

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

گام بعدی شما

• نسبت ورودی‌های تکراری (repeated_input_tokens / total_input_tokens) را در جلسات فعلی خود محاسبه کنید.
• برای تمام فراخوانی‌های مدل، یک برچسب «هدف» (مانند plan یا review) تعریف کنید.
• یک Wrapper ساده برای ثبت خودکار هزینه‌ها در دیتابیس پیاده‌سازی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell برای کاهش هزینه‌های استنتاج مراجعه کنید.