تصور کنید یک عامل هوشمند را مدیریت می‌کنید که باید با بودجه‌ی ناچیز ۲۰ دلار در هفته، یک میلیون دلار سود خالص ایجاد کند. در این شرایط، هر توکن مصرف‌شده شبیه به خرج کردن پول نقد از جیب شماست، نه یک منبع رایگان و نامحدود.
به نقل از گزارش فنی منتشر شده در ۵ اکتبر ۲۰۲۶ در وب‌سایت dev.to، یک عامل خودگردان مبتنی بر Gemini در حال حاضر در یک بنچمارک عمومی به نام milliondollars.live شرکت کرده است. این عامل با سرمایه‌ی اولیه صفر و سقف ۱۰۰ دلار کمک‌هزینه (که نیاز به تایید انسانی دارد) شروع به کار کرده است. در این ساختار، اپراتور انسانی کاملاً غیرفعال است و تنها نقش نظارتی، رگولاتوری و تأمین گاردریل‌های مربوط به هویت را بر عهده دارد.
بسیاری از توسعه‌دهندگان عادت دارند برای هر مرحله از چرخهٔ کاری یک عامل، از قدرتمندترین مدل‌های استدلالی استفاده کنند. اما طبق این گزارش، چنین رویکردی منجر به شکست مالی می‌شود؛ چراکه مدل‌های پیشرو هزینه‌ای بین ۲ تا ۱۵ دلار به ازای هر میلیون توکن دارند. برای عاملی که روزانه ۴۰ گردش عملیاتی ساده — مثل خواندن HTML، تجزیه پاسخ‌ها یا بررسی اعتبارنامه‌ها — انجام می‌دهد، این هزینه‌ها پیش از آنکه حتی یک سنت درآمد ایجاد شود، به صدها دلار در ماه می‌رسد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم، راهکار این عامل استفاده از «اقتصاد نامتقارن توکن‌ها» است. این سیستم زمان اجرای خود را به دو سطح متمایز تقسیم می‌کند:
- زمان‌های اجرای سریع و ارزان: با استفاده از مدل gemini-3.8-flash (با هزینه ۰.۷۵ تا ۳.۷۵ دلار به ازای هر میلیون توکن)، ۹۵٪ وظایف شامل بازرسی DOM، نظارت بر وضعیت، فراخوانی‌های ساختاریافته API و ویرایش‌های روتین بخش‌ها انجام می‌شود.
- زمان‌های اجرای استدلالی پیشرو: مدل‌هایی مانند gemini-3.1-pro-preview صرفاً برای بازنگری‌های معماری، تولید کدهای پیچیده و چرخش‌های استراتژیک حیاتی رزرو شده‌اند.
علاوه بر این، معماری سیستم از قابلیت Context Caching (ذخیره‌سازی زمینه) تامین‌کنندگان استفاده می‌کند تا پیشوندهای پرامپت را «گرم» نگه دارد. این کار باعث می‌شود هزینه‌های دفعات تکراری در زمان‌های اوج مصرف (Burst Turns) در مقایسه با نظرسنجی‌های تصادفی (Random Polling)، به‌شدت کاهش یابد.
مدیریت وضعیت (State Management) نیز از طریق یک «معماری حافظه سه‌گانه» انجام می‌شود تا از پدیده Context Bloat (تورم زمینه) و انحراف توجه (Attention Drift) جلوگیری شود. مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — در هر نوبت اجرا هیچ حافظه RAM دائمی ندارد. بنابراین، ریختن کل تاریخچه گفتگو در هر نوبت، باعث می‌شود هزینه‌های توکن به‌صورت نمایی افزایش یابد و مدل دچار توهم (Hallucination) شود؛ یعنی وقتی مدل با اطمینان اتفاقات گذشته را به اشتباه تعریف می‌کند، شبیه دوستی که خاطره‌ای را اشتباه بازگو می‌کند.
این مدل حافظه به‌جای یک تاریخچه ساده که فقط به آن داده اضافه شود (Append-only)، از سه بخش مجزا استفاده می‌کند:
- دفترچه راهنما (استراتژی دائمی): سندی با محدودیت سخت‌گیرانه حدود ۸۰۰۰ کاراکتر شامل اکتشافات اصلی (Heuristics)، قوانین عملیاتی، محدودیت‌های ریسک و درس‌های معماری.
- تمرکز فعلی (حافظه کاری گذرا): یک یادداشت کوچک ۵۰۰۰ کاراکتری که در پایان هر نوبت اجرا به‌طور کامل بازنویسی می‌شود تا وظایف تکمیل‌شده، وضعیت فعال پلتفرم و گام فوری بعدی را ثبت کند.
- دفتر کل (ردپای حسابرسی): یک لیست تک‌خطی و تغییرناپذیر که هر آزمایش مجزا و هر معیار را با فرمت [زمان] اقدام -> نتیجه -> بعدی ثبت می‌کند.
این ساختار تضمین می‌کند که سربار حافظه، چه در نوبت دهم و چه در نوبت ۱۰,۰۰۰ام، ثابت بماند و رشد نکند.
در تعامل با وب نیز برای کاهش اتلاف توکن، سلسله‌مراتب سخت‌گیرانه‌ای اجرا می‌شود. این عامل از مرورگرهای بدون سر (Headless Browsers) مثل Playwright یا Puppeteer به عنوان رابط اصلی دوری می‌کند، زیرا یک چرخه مرورگر برای تحلیل درخت عناصر DOM و شاخص‌های دکمه‌ها، هزاران توکن مصرف می‌کند.
سلسله‌مراتب ابزارها به این ترتیب است:
- فراخوانی مستقیم API (web_request): سریع‌ترین و مطمئن‌ترین روش با استفاده از اعتبارنامه‌های ایزوله و اسکیماهای JSON قطعی.
- بازیابی وب استاتیک (web_fetch): استخراج متن ساختاریافته خام از طریق حذف اسکریپت‌ها و استایل‌های سنگین CSS.
- اجرای مرورگر (browser): فقط برای راه‌اندازی جلسه (Bootstrap)، رندر کردن JSهای پیچیده یا تغییرات تعاملی DOM استفاده می‌شود.
پس از آنکه یک جلسه مرورگر موفق به دریافت توکن احراز هویت یا کلید API شخصی شد، این اطلاعات به یک «گاوصندوق اعتبارنامه‌ها» (Credential Vault) در سمت سرور منتقل می‌شود. این کار مانع از افشای اسرار به صورت متن ساده (Plaintext) در متن پرامپت شده و اجازه می‌دهد عامل دوباره به تعاملات ارزان‌تر مبتنی بر API بازگردد.
برای حفظ استانداردهای اخلاقی، عامل تحت قوانین شفافیت سخت‌گیرانه‌ای عمل می‌کند. این شامل افشای کامل این موضوع است که پست‌ها به‌صورت خودکار توسط Gemini از طریق API سایت DEV ارسال شده‌اند (با نام کاربری gemini-million-dollars@) و هرگونه استفاده از حلقه‌های تعامل مصنوعی یا طرح‌های «دنبال کردن متقابل» (Follow-for-follow) به‌طور کامل ممنوع است.
این تغییر در طراحی نشان می‌دهد که مرز بعدی خودمختاری، پنجره‌های متنی بزرگ‌تر نیست، بلکه هرس کردن تهاجمی وضعیت (State Pruning) است. با تبدیل حافظه به یک پایگاه‌داده ساختاریافته به‌جای یک لاگ چت، می‌توان عامل‌هایی ساخت که هفته‌ها بدون برخورد با سقف مالی اجرا شوند.
برای کسانی که در حال ساخت حلقه‌های تولیدی هستند، تمرکز باید از «هوشمندترین مدل» به «ارزان‌ترین مدلِ کافی» تغییر کند. توانایی جابه‌جایی پویا بین مدل‌ها، همان چیزی است که یک نمونه اولیه (Prototype) را از یک کسب‌وکار خودگردان سودآور جدا می‌کند.
شما می‌توانید تله‌متری لحظه‌ای و جدول امتیازات این آزمایش را در سایت milliondollars.live دنبال کنید تا ببینید آیا این محدودیت‌ها واقعاً می‌توانند به نتیجه‌ای یک میلیون دلاری منجر شوند یا خیر.
گام بعدی شما
- در پروژه‌های خود، وظایف را به دو دسته «روتین» و «استراتژیک» تقسیم کنید و برای هر کدام مدل متفاوتی (مثلاً Flash در برابر Pro) تعریف کنید.
- به‌جای ارسال کل تاریخچه گفتگو به مدل، یک «دفترچه راهنما» (Playbook) ثابت و یک «یادداشت وضعیت» (Status Note) متغیر ایجاد کنید.
- برای تعامل با وب، ابتدا از APIهای مستقیم استفاده کنید و مرورگرهای Headless را فقط به عنوان آخرین گزینه برای کارهای پیچیده نگه دارید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو