تصور کنید هر روز ۳۰ تا ۴۰ دقیقه از تمرکز عمیق شما توسط ایمیل‌های کوتاه و پراکنده پشتیبانی تکه‌تکه شود. این دقیقاً همان «مالیات جابه‌جایی زمینه» (Context-switching tax) است که بسیاری از مؤسسان استارتاپ‌ها را مجبور می‌کند بین استخدام نیروی گران‌قیمت — که توسعه‌دهنده در این مورد هنوز توان مالی‌اش را نداشت — یا کاهش سرعت توسعه فنی خود یکی را انتخاب کنند. پشتیبانی برای تیم‌های کوچک، قاتل بهره‌وری است؛ زیرا به ندرت به صورت بلوک‌های زمانی طولانی می‌آید، بلکه در تکه‌های پنج دقیقه‌ای ظاهر می‌شود که تمرکز شناختی را در هم می‌شکند. توسعه‌دهنده این وضعیت را بدترین شکل ممکن برای یک روز کاری توصیف کرد و اشاره کرد که هر بار برای انجام کاری که نیاز به تفکر عمیق داشت می‌نشست، صندوق ورودی او را به بیرون می‌کشید.
به نقل از گزارش dev.to در ۸ سپتامبر ۲۰۲۶، یک توسعه‌دهنده مستقل توانست با استفاده از ترکیبی از Agno، Atomic Mail و GPT-4o (از طریق OpenRouter)، خط اول پشتیبانی خود را به‌طور کامل خودکار کند و تقریباً یک ساعت از زمان کاری روزانه خود را برای «کار عمیق» (Deep-work) پس بگیرد. این رویکرد عملی، نمونه‌ای بارز از این است که چگونه عامل‌های هوش مصنوعی تمرکز صنعت را از تولید محتوا به اجرای هدف تغییر داده‌اند تا کارهای عملیاتی واقعی را مدیریت کنند. این سیستم که در مجموع دو تا سه ساعت زمان برد تا ساخته شود (شامل زمانی که صرف شکستن و عیب‌یابی آن شد)، به جای استفاده از معماری‌های پیچیده، بر یک سازوکار ساده متکی است: یک کران‌جاب (Cron Job) — شبیه به یک ساعت زنگ‌دار دیجیتال که هر ۵ دقیقه یک‌بار بیدار می‌شود — عامل را برای بررسی صندوق ورودی فعال می‌کند. معماری سیستم عمداً سبک طراحی شده تا از مهندسی بیش از حد (Over-engineering) مانند پایگاه‌داده‌های برداری یا صف‌های پیچیده «انسان در حلقه» (Human-in-the-loop) اجتناب شود. در این استک فنی، به جز کلید مدل، همه چیز رایگان است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، سادگی در طراحی عامل‌ها اغلب منجر به پایداری بیشتر می‌شود. در این پروژه نیز توسعه‌دهنده از پایگاه‌داده‌های برداری پیچیده دوری کرده تا هزینه و زمان نگهداری را به حداقل برساند.
زیرساخت فنی
مغز متفکر این سیستم GPT-4o است. دلیل این انتخاب، تعادل میان سرعت و هزینه است. توسعه‌دهنده خاطرنشان کرد که طبقه‌بندی پشتیبانی در واقع یک وظیفه «بازیابی» (Retrieval) و «تطبیق لحن» است، نه یک وظیفه استدلالی سنگین؛ بنابراین استفاده از مدل‌های استدلالی سطح پیشرو (Frontier-tier reasoning models) غیرضروری بود. پرداخت هزینه برای یک مدل سنگین‌تر، در واقع پرداخت هزینه برای قابلیت‌هایی بود که هرگز مورد استفاده قرار نمی‌گرفتند.
اجزای اصلی این سیستم عبارت‌اند از:
- Agno: چارچوب عامل (Agent Framework) که تعریف عامل، دستورالعمل‌ها و دانش او را در خود نگه می‌دارد.
- Atomic Mail: ابزاری برای مدیریت ایمیل که مخصوص عامل‌های هوش مصنوعی ساخته شده است. این ابزار صندوق ورودی‌ای را فراهم می‌کند که عامل می‌تواند آن را بخواند و به آن پاسخ دهد، بدون اینکه نیاز باشد یک کلاینت IMAP را با «چسب و نوارهای دست‌ساز» به سیستم متصل کند.
- Cron Job: محرکی که هر ۵ دقیقه سیستم را بیدار کرده و فعال می‌کند.
- GPT-4o (via OpenRouter): مدل زبانی زیرساختی برای پردازش متن.
گردش کار (Workflow) یک مسیر خطی سخت‌گیرانه را دنبال می‌کند:
۱. یک کران‌جاب هر پنج دقیقه عامل را فعال می‌کند.
۲. عامل از طریق Atomic Mail ایمیل‌های خوانده‌نشده را می‌خواند.
۳. پرس‌وجوی کاربر را با مستندات محصول و کتابخانه‌ای از نمونه پاسخ‌ها بررسی می‌کند.
۴. پاسخی را با لحن خاص شرکت پیش‌نویس می‌کند.
۵. پاسخ را ارسال کرده و رشته ایمیل را به عنوان «رسیدشده» (Handled) علامت‌گذاری می‌کند.
رمز دستیابی به لحن طبیعی
یکی از یافته‌های کلیدی این پروژه، تفاوت بنیادین میان «مستندات» و «نمونه‌ها» بود. در حالی که مستندات محصول حقایق را ارائه می‌دهند، اما پاسخ‌های حاصل از آن‌ها اغلب شبیه به «اطلاعیه‌های انطباق» (Compliance notices) خشک و اداری است. برای حل این مشکل، توسعه‌دهنده توده‌ای از پاسخ‌های انسانی قبلی را به مدل داد. این رویکرد به مدل آموخت که چگونه انسانی به نظر برسد: کوتاه، ساده و به دور از پرکننده‌های شرکتی (Corporate filler).
توسعه‌دهنده زمان بیشتری را صرف نام‌گذاری عامل و نوشتن دستورالعمل‌ها کرد تا سیم‌کشی کدها. او تأکید کرد که «در اینجا دستورالعمل‌ها همان محصول هستند و کد تنها مکانیسم تحویل است». این دیدگاه با رویکرد جدید Kiro Crew برای بسته‌بندی عامل‌ها در اپلیکیشن هم‌سو است که بر سرعت در تبدیل ایده‌های عامل‌محور به ابزارهای کاربردی تأکید دارد. دستورات خاصی که به عامل داده شد شامل موارد زیر بود:
- پاسخ دادن به ایمیل‌های خط اول پشتیبانی برای محصول.
- تطبیق لحن با نمونه پاسخ‌ها (کوتاه، ساده، بدون کلیشه‌های شرکتی).
- در صورتی که پاسخ در مستندات نباشد، رشته ایمیل را علامت‌گذاری کرده و اعلام کند که در حال بررسی موضوع با تیم است.
- ممنوعیت سخت‌گیرانه در مورد اختراع قیمت‌ها، جدول‌های زمانی یا ویژگی‌های جدید محصول.
مکانیسم «درگاه خروج»
برای جلوگیری از توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — یک «درگاه خروج» (Escape Hatch) اجباری طراحی شده است. اگر پاسخ در مستندات ارائه شده یافت نشود، عامل دستور دارد بگوید که در حال بررسی با تیم است و رشته ایمیل را برای یک انسان علامت‌گذاری کند.
این رفتار دقیقاً مشابه عملکرد یک نیروی پشتیبانی تازه‌کار (Junior) است. توسعه‌دهنده اشاره کرد که عاملی بدون درگاه خروج، با اعتماد به نفس کامل درباره سیاست‌های استرداد وجه (Refund policy) چیزهایی از خودش می‌سازد. این مکانیسم، عامل را از یک ریسک احتمالی به یک «تولیدکننده سیگنال» تبدیل می‌کند؛ اکنون هر رشته ایمیلی که علامت‌گذاری شود، نشان‌دهنده یک شکاف مشخص در مستندات محصول است که دارای برچسب زمانی است. پیش از این، توسعه‌دهنده این شکاف‌ها را صرفاً با تکیه بر دانش شخصی‌اش پوشش می‌داد، اما اکنون آن‌ها به صورت یک لیست تمیز از نیازهای مستندسازی ظاهر می‌شوند.
شکست در حلقه بی‌نهایت
پروژه زمانی با یک مشکل بزرگ مواجه شد که توسعه‌دهنده متوجه شد عامل فاقد «حافظه وضعیت» (State Memory) است. چون عامل نمی‌دانست به چه چیزی پاسخ داده است، هر پنج دقیقه همان رشته‌های خوانده‌نشده را می‌دید و مکرراً به همان مشتریان پاسخ می‌داد. مدل وظیفه خود را به طور کامل انجام می‌داد؛ از او پرسیده می‌شد «آیا این ایمیل نیاز به پاسخ دارد؟» و چون حافظه‌ای نداشت، پاسخ صادقانه همیشه «بله» بود.
برای حل این «حلقه پرحرف» (Chatty loop)، چهار حفاظ (Guardrails) تعریف شد:
- فیلتر کردن پرس‌وجو: تغییر پرس‌وجو از «دریافت صندوق ورودی» به «فقط دریافت خوانده‌نشده‌ها». پرس‌وجو باید خودش فیلتر باشد، زیرا هر چیزی که بعد از دریافت فیلتر شود، همچنان برای مدل قابل مشاهده است.
- تغییر وضعیت فوری: علامت‌گذاری رشته‌ها به عنوان رسیدشده بلافاصله پس از ارسال، نه در پایان اجرای برنامه. این کار تضمین می‌کند که اگر برنامه در میانه راه متوقف شود، ایمیل‌های ارسال شده همچنان علامت‌گذاری شده باقی بمانند.
- ردیابی شناسه پیام: نگهداری سوابقی از ID پیام‌های پاسخ‌داده‌شده به عنوان یک بررسی ثانویه (مانند سیستم کمربند و تعلیق) پیش از پیش‌نویس کردن پاسخ.
- کنترل هم‌زمانی: افزودن یک فایل قفل (Lock file) برای جلوگیری از اجراهای هم‌پوشان. اگر پردازش یک دور بیش از پنج دقیقه طول بکشد، بدون این قفل، دو نسخه از عامل به طور هم‌زمان به یک رشته ایمیل نگاه می‌کردند.
اصطکاک محیطی
جالب است که سخت‌ترین بخش کار، منطق هوش مصنوعی نبود، بلکه تنظیمات محیط محلی (Local Environment) بود. مشکلاتی در مورد نسخه‌ها، کلیدها و Importهایی که در نسخه‌های مختلف چارچوب Agno جابه‌جا شده بودند، زمان بیشتری نسبت به تعریف خودِ عامل گرفت. توسعه‌دهنده ذکر کرد که در این مرحله، «Hermes» بیشتر کارهای سخت را انجام داد.
این موضوع نشان می‌دهد که برای اکثر پروژه‌های عامل‌محور، «مهندسی» در دستورالعمل‌ها و حفاظ‌هاست، اما «سختی و ملال» در «گل‌ولای محیط توسعه» (Environment mud) نهفته است. توسعه‌دهنده هشدار می‌دهد کسانی که برای ساخت چنین سیستمی زمان‌بندی می‌کنند، باید زمان را برای تنظیمات محیط محلی در نظر بگیرند، نه فقط برای منطق عامل.
نتایج نهایی و تاملات
اکنون پشتیبانی به‌طور کامل واگذار شده و تضمین می‌شود که هیچ ایمیلی شبانه بدون پاسخ نمی‌ماند. توسعه‌دهنده دیگر ۳۰ تا ۴۰ دقیقه از روز خود را در تکه‌های پنج دقیقه‌ای از دست نمی‌دهد و خستگی ذهنی ناشی از جابه‌جایی مداوم زمینه را حذف کرده است.
درس کلی آموخته شده این است که عاملی که روی یک زمان‌بند (Timer) قرار دارد، یک کارمند نیست که ایمیل‌ها را چک کند؛ بلکه یک حلقه while True است که هزینه می‌برد و با مشتریان صحبت می‌کند. هر چنین حلقه‌ای به یک «شرط پایان» (Termination condition) سخت‌گیرانه نیاز دارد.
در نگاه به آینده، توسعه‌دهنده کنجکاو است بداند آیا دیگران فراتر از پشتیبانی خط اول — مانند استرداد وجه یا تغییرات حساب کاربری که نیاز به نوشتن در سیستم دارد — را مدیریت می‌کنند و چگونه ارتقای درخواست‌ها (Escalation) را فراتر از علامت‌گذاری ساده انجام می‌دهند. او علاقه ویژه‌ای به دیدن نسخه‌های «بیش‌مهندسی شده» این سیستم (مثلاً کسانی که برای تعداد کمی مشتری از سه عامل و یک پایگاه‌داده برداری استفاده می‌کنند) و شنیدن درباره «شکست‌های خاموش» (Quiet failures) دارد که به اندازه یک حلقه پاسخ پنج دقیقه‌ای، مشهود نیستند.
گام بعدی شما
- اگر از ابزارهای پشتیبانی سنگین استفاده می‌کنید، ابتدا یک «درگاه خروج» برای مدل خود تعریف کنید تا نرخ توهم به صفر برسد.
- به جای تکیه بر مستندات خشک، مجموعه‌ای از ۱۰ پاسخ انسانی موفق را به عنوان نمونه (Few-shot) به پرامپت سیستمی خود اضافه کنید.
- برای هر عامل که روی زمان‌بند (Timer) اجرا می‌شود، حتماً یک مکانیسم قفل (Lock) برای جلوگیری از اجرای هم‌زمان تعریف کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو