منبع: این نوشته برداشت و تحلیل فارسی نکست ادمین از مطلب Building always-on agents است که William Hu در ۱۳ نوامبر ۲۰۲۶ در بخش بهترین روش‌های پلتفرم Claude منتشر کرده.
خلاصه در یک نگاه
- ایجنت «همیشهروشن» وضعیتش را بین جلسه‌ها نگه میدارد و بدون نظارت مستقیم کار میکند. حلقهی ایجنتش همان حلقهی معمولی است؛ فرقش در معماری اطراف آن است: کِی بیدار شود، چه چیزی بین اجراها بماند و خروجی چطور به کاربر برسد.
- دو روند این الگو را دوباره داغ کرده: قضاوت بهتر مدل‌ها (بهتر می‌فهمند کِی باید از کاربر بپرسند) و ارزان‌تر شدن هوش. در یک بنچمارک کدنویسی طولانی، هزینه‌ی هر تسک حل‌شده با Opus 5.5 حدود ۷۸٪ کمتر از Opus 5 بود.
- مقاله ساختار را در پنج جزء خلاصه میکند: صندوق رویداد، تایمرها، حافظه، مجوزها و صندوق خروجی.
- قاعده‌های کلیدی: همه‌چیز در ذخیره‌ساز پایدار، فقط یک کارگر فعال برای هر صندوق، اعتبارنامه بیرون از دسترس ایجنت، و ایجنتی که کم‌حرف شروع میکند.
«همیشه روشن» در واقع یعنی بیشتر وقت خواب
اسم گمراه‌کننده است. ایجنت همیشهروشن بیشتر زمانش بیکار است و در این فاصله‌ها هزینه‌ای ندارد. واحد واقعی کار «اجرا» (run) است: یک رویداد می‌رسد، ایجنت کارش را انجام میدهد و وضعیتش را ذخیره میکند. هر اجرا داخل یک «نشست» (session) اتفاق می‌افتد که رونوشت پیام‌ها و فراخوانی‌های ابزار است. بعد از اجرا ایجنت تا رویداد بعدی می‌خوابد. «همیشه روشن» توصیف تجربه‌ی کاربر است، نه رفتار سرور.
۱. صندوق رویداد
ایجنت همیشهروشن فقط با پیام کاربر بیدار نمی‌شود؛ وب‌هوک‌ها، کارهای زمان‌بندی‌شده و کارهای پس‌زمینه هم آن را صدا می‌زنند. اگر هر رویداد مستقیم ایجنت را اجرا کند، دو مشکل پیش میآید: رویدادهای همزمان اجراهای رقیب راه می‌اندازند، و با یک کرش رویداد گم میشود.
راه‌حل یک جدول پایدار (معمولاً یک جدول پایگاه داده) است، به‌همراه یک هندلر HTTP که رویداد را ثبت میکند و یک کارگر پس‌زمینه که آن را می‌خواند. پیشنهاد شروع: یک صندوق برای هر کاربر. رویدادی که ادامه‌ی کار قبلی است، مثل پاسخ کاربر، همان نشست را ادامه میدهد و بقیه نشست تازه باز می‌کنند.
- سریع تأیید کنید. سرویس‌های وبهوک پاسخ کند را خطا حساب می‌کنند؛ بررسی‌های سنگین مثل تشخیص تزریق پرامپت را به داخل اجرا بسپارید.
- فقط یک کارگر فعال برای هر صندوق. برای رویدادی که وسط اجرا می‌رسد یکی از سه راه را انتخاب کنید: صف برای اجرای بعد، ادغام در اجرای فعلی، یا قطع و شروع دوباره.
- دسته کنید. چند پیام پشت‌سرهم کاربر باید در یک اجرا پردازش شود تا ایجنت یک‌بار جواب بدهد.
- تکراری‌ها را حذف کنید با شناسه‌ی یکتایی که خود منبع رویداد میدهد.
۲. تایمرها
دو نوع تایمر لازم است: پیگیری‌های یک‌باره که ایجنت برای خودش تنظیم میکند (مثلاً «فردا ببین جواب داده یا نه») و زمان‌بندی‌های تکرارشونده مثل خبرنامه‌ی روزانه. تایمرها در ذخیره‌ساز خودشان، جدا از صندوق، نگه داشته می‌شوند؛ صندوق فقط کار آماده‌ی همین حالا را دارد.
تایمر هم مستقیم اجرا راه نمی‌اندازد. یک زمان‌بند در فاصله‌های ثابت سه کار انجام میدهد: تایمرهای سررسیده را پیدا میکند، وضعیتشان را به‌روز میکند (پیگیری انجام‌شده، زمان‌بندی به نوبت بعد) و یک رویداد در صندوق می‌گذارد تا کارگر بیدار شود. این را میشود خودتان ساخت یا از یک موتور اجرای پایدار (durable execution) استفاده کرد.
۳. حافظه
حافظه باید در ذخیره‌سازی بماند که از کارگر بیشتر عمر کند، مثل پایگاه داده یا object storage. قاعده‌ی سرانگشتی مقاله این است: فقط چیزی را نگه دارید که ایجنت نمیتواند دوباره پیدا کند. اگر اطلاعات جای دیگری هست، مثلاً در ابزار مدیریت تیکت، یک اشارهگر کافی است.
مقاله چهار نوع حافظه را جدا میکند:
- دستورهای کاربر: دستورهای ثابت رفتاری که در شروع هر اجرا بار می‌شوند، چون کاربر همیشه حاضر نیست.
- یادداشت‌های کاربر: چیزهایی که دربارهی نقش، ترجیح‌ها و اصلاح‌های کاربر یاد گرفته. اول یک فایل، و وقتی بزرگ شد یک فهرست بهعلاوهی فایل‌های جدا که فقط فهرست پیش‌فرض بار میشود.
- پیام‌های قبلی: سابقهی چیزهایی که قبلاً به کاربر گفته شده تا ایجنت حرف تکراری نزند.
- پیشرفت کارها: برای هر کار یک فایل با بخش‌های انجام‌شده و مانده، تا اجرای بعدی بتواند ادامه بدهد.
یک لایه‌ی اختیاری هم «رؤیا دیدن» (dreaming) است: فرایندی آفلاین که نشست‌های گذشته را مرور میکند، حافظه‌های کهنه را جایگزین میکند و الگوهایی را پیدا میکند که فقط در چندین اجرا دیده می‌شوند.
مدیریت پنجره‌ی زمینه: هر اجرا یک سربار ثابت دارد؛ پرامپت سیستم، تعریف ابزارها و فایل‌های حافظه. این سربار را کوچک نگه دارید و از کش پرامپت استفاده کنید. نشست تازه فقط سربار و رویدادهای محرک را دارد؛ نشست ادامه‌دار رونوشت قبلی را هم می‌آورد. وقتی نشست زیادی بلند شد، یا پیام‌های قدیمی را فشرده کنید یا نشست تازه باز کنید. هر دو جزئیات را از بین می‌برند، پس چیزهای مهم را از قبل در حافظه بنویسید.
۴. مجوزها: پرریسک‌ترین بخش
ایجنت با دسترسی کاربر و بدون حضور او کار میکند؛ برای همین مقاله مجوزها را پرخطرترین بخش معماری می‌داند. برای هر فراخوانی ابزار سه حالت هست: ادامه، توقف، یا انتظار برای تأیید.
- اعتبارنامه بیرون از ایجنت: یک پراکسی بیرون از محیط ایجنت. ایجنت درخواست را بدون اعتبارنامه می‌فرستد و پراکسی قبل از ارسال آن را اضافه میکند؛ رازها هیچ‌وقت به دست ایجنت نمی‌رسند.
- حالت خودکار: در Claude Code، طبقه‌بندها کارهای پرخطر را بررسی می‌کنند و موارد خطرناک را می‌بندند تا Claude راه امن‌تری پیدا کند؛ تصمیم‌های مهم همچنان با کاربر است.
- فراخوانی ابزار معوق: یک هوک می‌تواند فراخوانی را به تعویق بیندازد. اجرا تمام میشود و نشست وسط فراخوانی ذخیره میشود. درخواست به کاربر نشان داده میشود (مثلاً یک کارت تعاملی ساخته‌شده با MCP Apps) و پاسخ کاربر مثل یک رویداد تازه به صندوق برمی‌گردد و همان نشست را ادامه میدهد. در این فاصله کارگر می‌تواند رویدادهای دیگر را پردازش کند و ایجنت گیر نمی‌کند.
۵. صندوق خروجی
کاربر قرار نیست قدم‌به‌قدم استدلال ایجنت را ببیند؛ نتیجه و جزئیات کلیدی را می‌خواهد. هر اجرا به یکی از سه شکل تمام میشود: پیام می‌فرستد، تصمیم می‌گیرد چیزی برای گفتن نیست، یا یک فراخوانی معوق برای تأیید یا گرفتن ورودی می‌سازد.
برای بیشتر ایجنت‌ها یک ابزار «ارسال» که مستقیم به کاربر پیام بدهد کافی است. اگر لازم است پیام‌ها را زمان‌بندی کنید یا از خطای تحویل بازیابی کنید، یک جدول خروجی جدا با یک «توزیع‌کننده» در پس‌زمینه بسازید. مهم‌تر از معماری، میزان حرف زدن است: ایجنت پرحرف آزاردهنده است و ایجنت کم‌حرف چیزها را از دست میدهد. توصیه‌ی مقاله این است که برای این تعادل ارزیابی بسازید و کم‌حرف شروع کنید تا توجه کاربر را به‌تدریج به دست بیاورید.
همه‌چیز کنار هم
تایمرها و صندوق رویداد هر اجرا را شروع می‌کنند. کارگر یک نشست تازه یا قبلی را باز میکند. ایجنت زمینه را از حافظه می‌خواند، در محدوده‌ی مجوزهایش کار میکند، آموخته‌هایش را در حافظه می‌نویسد و نتیجه را در صندوق خروجی می‌گذارد تا به کاربر برسد. پاسخ کاربر رویداد تازه‌ای در صندوق می‌سازد و ایجنت می‌تواند برای بیدار شدن بعدی‌اش تایمر بگذارد.
برای تیم‌های ما چه معنایی دارد؟
این بخش برداشت خود ماست. خبر خوب این است که هیچ‌کدام از این پنج جزء تکنولوژی عجیبی نمی‌خواهد؛ بیشترش همان ابزارهایی است که تیم‌های بک‌اند سال‌هاست با آن کار می‌کنند:
- صندوق رویداد با یک جدول PostgreSQL ساده شروع میشود. ستون وضعیت، شناسه‌ی یکتای منبع با قید unique، و
SELECT … FOR UPDATE SKIP LOCKEDبرای این‌که فقط یک کارگر رویداد را بردارد. صف پیام جدا لازم نیست تا وقتی واقعاً لازم شود. - تایمر با cron یا یک کار زمان‌بندی‌شده‌ی ساده. مهم این است که تایمر مستقیم ایجنت را صدا نزند و فقط رویداد بسازد.
- حافظه را مثل داده‌ی کاربر جدی بگیرید. پشتیبان، امکان مشاهده و حذف توسط کاربر، و اگر داده‌ی حساس است، رمزنگاری. هر چیزی را که در سیستم اصلی هست کپی نکنید.
- کلید API هرگز در محیط ایجنت نباشد. پراکسی که مقاله پیشنهاد میدهد با چند خط nginx یا یک سرویس کوچک ساخته میشود و جلوی بدترین نوع نشت را می‌گیرد.
- هزینه را از روز اول بسنجید. سربار ثابت هر اجرا ضرب در تعداد بیدار شدن‌ها هزینه‌ی واقعی است؛ کش پرامپت و کوچک نگه داشتن فایل‌های حافظهی همیشگی بیشترین اثر را دارند.
- اول کم‌حرف. ایجنتی که هر ساعت پیام بدهد خیلی زود بی‌صدا (mute) میشود. با خلاصه‌ی روزانه شروع کنید و پیام فوری را فقط برای موارد واقعاً مهم نگه دارید.
پرسش‌های پرتکرار
ایجنت همیشهروشن با ایجنت معمولی چه فرقی دارد؟
حلقهی ایجنت در هر دو یکی است. فرق در معماری اطراف است: ایجنت همیشهروشن با رویدادها و تایمرها بیدار میشود، وضعیتش را بین اجراها نگه میدارد و بدون حضور کاربر کار میکند.
چرا وبهوک نباید مستقیم ایجنت را اجرا کند؟
چون رویدادهای همزمان اجراهای رقیب میسازند و با کرش، رویداد گم میشود. ثبت رویداد در یک جدول پایدار و پردازشش توسط یک کارگر یکتا هر دو مشکل را حل میکند.
چه چیزی باید در حافظهی ایجنت ذخیره شود؟
فقط چیزی که ایجنت نمیتواند دوباره پیدا کند: دستورهای ثابت کاربر، چیزهایی که دربارهی کاربر یاد گرفته، سابقهی پیامهایی که فرستاده و پیشرفت کارهای نیمهتمام. برای بقیه اشارهگر کافی است.
ایجنت چطور منتظر تأیید کاربر بماند بیآنکه گیر کند؟
با فراخوانی ابزار معوق: اجرا تمام میشود و نشست ذخیره میشود، درخواست به کاربر نشان داده میشود و پاسخ او مثل یک رویداد تازه همان نشست را ادامه میدهد. در این فاصله کارگر کارهای دیگر را انجام میدهد.
ایجنت همیشهروشن چقدر هزینه دارد؟
در زمان خواب هیچ. هزینه از اجراها میآید: سربار ثابت هر اجرا (پرامپت، ابزارها، حافظه) بهعلاوهی کار واقعی. کش پرامپت، سربار کوچک و دسته کردن رویدادها هزینه را پایین نگه میدارد.
منبع
William Hu، Building always-on agents، Claude by Anthropic، ۱۳ نوامبر ۲۰۲۶. عددها و ادعاهای فنی از همین منبع است؛ نمودارها را نکست ادمین بر اساس توضیحات آن بازطراحی کرده و بخش «برای تیم‌های ما چه معنایی دارد؟» تحلیل خود ماست.
