عامل Ankita با حلقه‌ی پیش‌کنش، اتوماسیون بدون پرامپت را ممکن کرد

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

در ۲۹ سپتامبر ۲۰۲۶، توسعه‌دهنده‌ای به نام Krish جزئیات پیاده‌سازی یک «حلقه‌ی پیش‌کنش» (Proactive Loop) را برای دستیار متن‌باز Ankita منتشر کرد. این تغییر بنیادین باعث می‌شود مدل از حالت واکنشی — یعنی منتظر ماندن برای پرامپت کاربر برای هر اقدام — به حالت پیش‌کنش تغییر وضعیت دهد. این رویکرد یادآور مهندسی موتورهای حلقوی در اتوماسیون Moadim است که پیش از این برای جایگزینی پرامپت‌های دستی بررسی شده بود. با این معماری، Ankita می‌تواند هر صبح کاربر را بریف کند یا نقاط داده‌ی خاصی را در وب رصد نماید و بدین ترتیب، عامل را از یک رابط چت ساده به یک سرویس پس‌زمینه (Daemon) تبدیل کند.

لایه مدیریت وضعیت (State Management)

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت وضعیت در سیستم‌های خودکار همواره یک چالش بوده است. طبق گزارش منتشر شده در dev.to، استقلال این سیستم بر پایه یک فایل JSON واحد است که توسط کلاسی به نام RoutineStore مدیریت می‌شود. این فایل وظیفه ردیابی روتین‌های زمان‌بندی‌شده (مانند گزارش صبحگاهی در ساعت ۰۸:۰۰)، نظارت بر URLها (مانند رصد تعداد ثبت‌نام‌ها) و مکان‌نمای (Cursor) دریافت به‌روزرسانی‌های تلگرام (getUpdates) را بر عهده دارد.

برای جلوگیری از تخریب داده‌ها، تمام عملیات نوشتن به‌صورت اتمیک (Atomic) انجام می‌شود. این امر تضمین می‌کند که اگر سیستم در میانه ذخیره‌سازی دچار کرش شود، برنامه روز بعد هرگز تخریب نشود. یک چالش بحرانی در اینجا وجود داشت: از آنجایی که دیمون (Daemon)، محیط REPL و ابزارهای عامل، هر کدام نمونه (Instance) جداگانه‌ای از RoutineStore را نگه می‌دارند، بدون بازخوانی از دیسک پیش از هر تغییر، آخرین نمونه‌ای که می‌نوشت با یک اسنپ‌شات قدیمی پیروز می‌شد و احتمالاً نظارتی (Watch) را که در میانه یک روتین ایجاد شده بود، پاک می‌کرد.

توسعه‌دهنده برای حل این مشکل، یک متد سه خطی به نام _fresh() را پیاده کرد که سیستم را مجبور می‌کند پیش از هر تغییر (Mutation)، وضعیت را دوباره از دیسک بخواند. این راهکار «ساده و خسته‌کننده» باعث شد تا داده‌های واقعی از حذف بی‌صدا نجات یابند.

سازوکار نظارت بر وب

Ankita صفحات وب را با استفاده از مجموعه‌ای از قوانین سخت‌گیرانه رصد می‌کند تا قابلیت اطمینان را تضمین کند:

• استخراج مقدار (Value Extraction): تابع extractValue یک تابع خالص است که از Regex یا CSS Selectorها برای بیرون کشیدن داده‌ها از متن صفحه استفاده می‌کند. در حالت Regex، اولین گروه کپچر شده (Capture Group) به عنوان منبع داده در نظر گرفته می‌شود. نظارت‌های مبتنی بر Selector از همان لایه‌های اسکرپینگ کل اپلیکیشن استفاده می‌کنند تا صفحات سنگین JS یا صفحات مسدود شده را مدیریت کنند.
• تشخیص تغییر (Change Detection): سیستم از hashContent برای تهیه یک هش SHA-256 از مقدار (با حفظ ۱۶ کاراکتر هگز) استفاده می‌کند. همچنین تابع numericDelta کاماها و فاصله‌ها را حذف می‌کند تا تغییرات عددی دقیق را محاسبه کند (مثلاً تبدیل «۱,۲۰۴» در مقابل «۱,۲۲۷» به عدد ۲۳+). اگر هر یک از طرفین غیرعددی باشد، این تابع مقدار null برمی‌گرداند تا از ایجاد دلتاهای جعلی هنگام تغییر تیترها از متن به عدد جلوگیری شود.
• جلوگیری از کش (Cache Avoidance): برای جلوگیری از گزارش‌های نادرست «بدون تغییر»، سیستم کش را هنگام دریافت داده‌ها غیرفعال می‌کند. خواندن یک نسخه کش‌شده، یکی از نقاط شکست رایج است که منجر به گزارش‌های غلط می‌شود.
• مدیریت خطا (Error Handling): بررسی‌کننده از طریق checkWatch بین ابزار On-demand و دیمون زمان‌بندی‌شده مشترک است. این بخش به‌گونه‌ای طراحی شده است که هرگز خطا (Throw) ندهد؛ در عوض، صفحات ناپایدار به عنوان خطا لاگ می‌شوند تا از کرش کردن کل سیستم جلوگیری شود.

یکپارچه‌سازی و ارتباطات

حلقه پیش‌کنش از همان کلاس عامل (Agent) استفاده می‌کند که در محیط REPL به کار می‌رود. این طراحی «تقریباً خالص» (Pure-ish by construction) است، به این معنی که هر اثر جانبی (Side Effect) — مانند اجرای یک پرامپت یا ارسال پیام — تزریق (Inject) می‌شود. این ساختار اجازه می‌دهد کل حلقه بدون نیاز به شبکه یا ترمینال تست شود.

روتین‌های زمان‌بندی‌شده در واقع پرامپت‌هایی هستند که عامل به‌تنهایی اجرا می‌کند. ابزارهای ایجاد این روتین‌ها یعنی schedule و watch بدون نیاز به تأیید کاربر در اختیار مدل قرار دارند و به دستیار اجازه می‌دهند کارهای آینده خود را سازماندهی کند. این موارد در قالب یک جدول ساده نمایش داده می‌شوند که نام روتین، تکرار و مقدار فعلی را نشان می‌دهد.

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

۱. پایداری مکان‌نما (Cursor Persistence): مکان‌نما در فایل JSON ذخیره می‌شود. این کار مانع از آن می‌شود که سیستم پس از ری‌استارت، آخرین دسته به‌روزرسانی‌ها را دوباره اجرا کرده و پاسخ‌های تکراری ارسال کند.
۲. تجزیه تأییدیه‌ها (Approval Parsing): پارسر سیستم تأییدیه‌های تک‌کلمه‌ای مانند «y»، «yes»، «ok» و «always» را درک می‌کند و به‌جای فوروارد کردن ساده، آن‌ها را پردازش می‌کند.
۳. گارد تأیید دیرهنگام (Late-Approval Guard): یک گارد امنیتی پاسخ‌های «بله» به تأییدیه‌هایی که قبلاً منقضی شده‌اند را شناسایی می‌کند تا مدل با پرامپت‌های گیج‌کننده مواجه نشود و نپرسد: «آیا منظورتان تایپ y بود؟»

برای اینکه اعلان‌ها مدیریت‌پذیر باقی بمانند، سیستم از یک بازه استراحت یا کول‌داون (shouldAlert) استفاده می‌کند و چندین تغییر را در یک پیام واحد در هر تیک (Tick) دسته‌بندی می‌کند. دیمون یک شمارنده changesAlerted را ردیابی می‌کند تا تأیید کند این ویژگی در محیط واقعی به‌درستی عمل می‌کند.

این معماری تمرکز را از مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — به سمت مدیریت وضعیت (State Management) سوق می‌دهد. با اولویت دادن به نوشتن اتمیک و کنترل سخت‌گیرانه کش، توسعه‌دهنده سیستمی ساخته است که در حالی که بدون نظارت در پس‌زمینه اجرا می‌شود، قابل اعتماد باقی می‌ماند. برای جلوگیری از رفتارهای پیش‌بینی‌نشده در این حالت، پیاده‌سازی الگوی مدارشکن می‌تواند راهکاری حیاتی برای توقف احتمالی حلقه‌های تکراری در چنین سیستم‌های خودکاری باشد.

برای کسانی که عامل‌های خودکار می‌سازند، درس اصلی این است که قابلیت اطمینان از تصمیمات «پارانوئید» — مانند بازخوانی وضعیت پیش از تغییر، پایداری مکان‌نماها و دسته‌بندی اعلان‌ها — حاصل می‌شود، نه از منطق‌های پیچیده مدل. کدهای این پیاده‌سازی در دایرکتوری src/automation/ در مخزن گیت‌هاب Ankita در آدرس https://github.com/akyourowngames/A.N.K.I.T.A در دسترس است.

گام بعدی شما

• اگر توسعه‌دهنده هستید، متد _fresh() را در مدیریت وضعیت عامل‌های خود بررسی کنید تا از تداخل داده‌ها جلوگیری کنید.
• برای کاهش نویز اعلان‌ها، مکانیزم shouldAlert را برای دسته‌بندی پیام‌ها در پروژه‌های خود پیاده کنید.
• مخزن گیت‌هاب Ankita را برای بررسی نحوه پیاده‌سازی نظارت بر وب بدون کش مطالعه کنید.

اما داستان سخت‌افزاری اجرای این عامل‌ها در لبه (Edge) حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های NPU مراجعه کنید.