تصور کنید برنامه‌نویسی هستید که از فراموشی مداوم مهارت‌های عامل‌های هوش مصنوعی در هر بار پاک شدن پنجره متنی خسته شده است. معماری Alice ثابت می‌کند که برای داشتن هوش عملیاتی، نیازی به به‌روزرسانی دائمی وزن‌های مدل نیست. این چارچوب نشان می‌دهد که می‌توان با جدا کردن هویت سیستم از مدل زبانی، به پایداری دست یافت.
این سامانه با تبدیل مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — به یک قطعه قابل تعویض، تمرکز را از «مدل‌های بهتر» به «مدارهای بازیابی و اجرای بهتر» منتقل کرده است. در واقع، Alice نگاه می‌کند که چگونه می‌توان از مدل به عنوان یک ابزار استفاده کرد، نه به عنوان کل سیستم. طبق مستندات فنی منتشر شده در ۲۸ اوت ۲۰۲۶، هوش در Alice حاصل فرمول «مدل + حافظه + نقشه + مسیریابی + مدارها + ابزارها + یادگیری + اجرا» است.
بسیاری از عامل‌های امروزی صرفاً پوسته‌ای دور پنجره متنی یک مدل هستند. وقتی پنجره متنی پاک می‌شود، «مهارت» آن‌ها معمولاً ناپدید می‌شود، مگر اینکه از طریق تنظیم دقیق (Fine-tuning) در وزن‌های مدل تثبیت شده باشد. Alice در زمانی ظهور کرده است که صنعت با هزینه‌های بالای یادگیری مداوم و شکنندگی حافظه در عامل‌های هوشمند دست‌وپنجه نرم می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، وابستگی شدید به وزن‌های مدل، انعطاف‌پذیری سیستم را می‌گیرد. در Alice، مدل Qwen2.5-3B-Instruct (نسخه Q4_K_M) تنها موتور زبانی است و هویت سیستم را تعریف نمی‌کند.
هویت Alice
یک اصل بنیادی در این معماری این است که Alice با Qwen برابر نیست. در حالی که Qwen درک زبان، تولید متن و برخی توانایی‌های استدلال را فراهم می‌کند، Alice کل ساختاری است که این مدل را احاطه کرده است. رفتار کلی سیستم به نحوه ترکیب مدل با مسیریاب، حافظه، نقشه و ابزارها بستگی دارد.
بنابراین، ارزیابی Alice صرفاً بر اساس توانایی‌های ذاتی مدل Qwen یک خطای دسته‌بندی است. یک قابلیت می‌تواند متعلق به معماری Alice باشد بدون آنکه بخشی از توانایی‌های پیش‌فرض یا بومی مدل زبانی زیربنایی باشد. سیستم به‌گونه‌ای طراحی شده است که مدل هرگز به عنوان تنها نماینده یا معرف این موجودیت در نظر گرفته نشود.
لایه ارکستراسیون
قلب تپنده این سیستم فایل router.py است که مانند یک رهبر ارکستر عمل می‌کند. این مسیریاب به‌جای ارسال مستقیم هر درخواست به مدل، یک سلسله‌مراتب سخت‌گیرانه از کارایی را دنبال می‌کند تا از اتکای بیش از حد به LLM جلوگیری کند:
- مشاوره با نقشه زنده: ابتدا به‌دنبال یک مدار عملیاتی مرتبط می‌گردد تا ببیند آیا راهکار آماده‌ای وجود دارد یا خیر.
- جست‌وجوی حافظه SQLite: رویه‌های تأییدشده و تجربیات قبلی را در پایگاه داده بررسی می‌کند.
- فعال‌سازی ابزارهای تخصصی: در صورتی که درخواست شامل خواندن تصویر باشد از نویسه‌خوانی نوری (OCR) استفاده می‌کند یا اقدامات مستقیم سیستمی را شناسایی می‌کند.
- اجرای LLM: تنها در موارد پیچیده، برای استدلال‌های خاص یا تولید پاسخ نهایی از Qwen کمک می‌گیرد.
این استراتژی باعث می‌شود مدل هرگز مجبور نباشد مسئله‌ای را حل کند که Alice پیش‌تر برای آن یک رویه تأییدشده دارد. در واقع، اولویت سیستم «دانستنِ نحوه انجام» است، نه «پیش‌بینی توکن بعدی».
حافظه و نقشه زنده
حافظه در Alice یک گزارش ساده از چت‌ها یا تاریخچه گفتگو نیست، بلکه پایگاه‌داده‌ای ساختاریافته است که شامل جداولی برای «رویه‌ها» (procedures) و «تجربیات» (experiences) است. یک رویه تنها زمانی عملیاتی و قابل اعتماد تلقی می‌شود که وضعیت آن به «تأییدشده» (VERIFIED) تغییر کند. برای مثال، یکی از رویه‌های تأییدشده در این سیستم از چهار عملیات بسیار خاص تشکیل شده بود.
دانش در اینجا با پاک شدن پنجره متنی از بین نمی‌رود و «پاک‌شده» تلقی نمی‌شود؛ بلکه بخشی از حافظه معماری باقی می‌ماند. نقشه زنده (cartes.json) نمایش ساختاریافته‌ای از این مدارهای قابل دسترس است. این نقشه به مسیریاب اجازه می‌دهد فوراً قابلیت مورد نیاز را مکان‌یابی کند. این یعنی هر راهکاری که یک‌بار کشف و به دانش قابل استفاده تبدیل شود، برای همیشه و به‌طور نامحدود قابل بازاستفاده است.
یادگیری از طریق تقویت (RL)
یادگیری در Alice به معنای به‌دست آوردن یک رویه کاربردی است، نه بهینه‌سازی یک امتیاز عددی یا ریاضی. این سیستم از یک خط لوله تخصصی یادگیری تقویتی (RL) برای مدیریت وظایف ناوبری منطقی یا فیزیکی استفاده می‌کند.
به نقل از گزارش‌های فنی، Alice در یک محیط آزمایشی شامل یک شبکه ۵ در ۵، با استفاده از Gymnasium و Q-learning به کاوش در فضا پرداخت. در این محیط، عامل تنها به چهار حرکت محدود است: بالا، پایین، چپ و راست. مسیر فنی این خط لوله به صورت خطی است: محیط RL $\rightarrow$ Q-learning $\rightarrow$ سیاست (Policy) $\rightarrow$ مدار $\rightarrow$ نقشه زنده $\rightarrow$ مسیریاب.
وقتی یک سیاست یاد گرفته شد، به‌عنوان یک «مدار» صادر (Export) می‌شود. این مدار سپس در منطقه «دانش» در نقشه زنده ذخیره می‌گردد. دفعه بعد که وظیفه‌ای مشابه پیش بیاید — مثلاً درخواستی برای حرکت به سمت یک هدف — مسیریاب مستقیماً مدار را فعال می‌کند و دیگر نیازی نیست مدل زبانی دوباره برای نحوه حرکت «استدلال» کند.
کالبدشکافی اجزا
برای درک دقیق جریان عملیاتی، باید به ابزارها و آداپتورهای خاصی که در سیستم ادغام شده‌اند نگاه کرد:
- ابزارهای محلی: این‌ها شامل جست‌وجوی حافظه، خواندن فایل، تست، خلاصه‌سازی، عملیات سیستمی، OCR، یک ثبات زبانی (language register) و توابع «مراقبت» (care functions) هستند.
- آداپتورها:
alicization_adapter.py: رابطteach()را برای یادگیری‌های جدید مدیریت می‌کند.memory.py: پایداری داده‌ها و ذخیره‌سازی رویه‌ها در SQLite را بر عهده دارد.adaptateur_carte.py: رابط ارتباطی با نقشه زنده را فراهم می‌کند.
- محیط اجرا: سیستم توسط
llama-serverروی ماشین Alice با آی‌پی ۱۹۲.۱۶۸.۱.۶۱ و با پنجره متنی ۴۰۹۶ توکن سرویس‌دهی می‌شود.
مشخصات فنی و محدودیت‌ها
تا ۲۸ اوت ۲۰۲۶، وضعیت سیستم بر اساس اجرای تأییدشده است، نه کدهای تئوریک. در مستندات اشاره شده که یک تناقض در گزارش‌های سخت‌افزاری ماشین میزبان وجود دارد — دو فهرست سخت‌افزاری متناقض ثبت شده است — که باید پیش از مستندسازی نهایی سخت‌افزار حل شود.
علاوه بر این، توسعه‌دهندگان باید بین محیط فعلی و محیط‌های قدیمی‌تر تمایز قائل شوند. در حالی که Alice فعلاً از Qwen2.5-3B-Instruct استفاده می‌کند، برخی گزارش‌های قدیمی‌تر به Qwen2.5-Coder-1.5B روی ماشینی دیگر اشاره دارند؛ این دو نباید با هم ادغام شوند. خط لوله RL و پایداری SQLite از طریق pytest تأیید شده‌اند و در تست‌های هسته RL، نرخ موفقیت ۴ از ۴ ثبت شده است.
فلسفه «به اندازه کافی خوب»
معماری Alice وسواس صنعت روی بهینه‌سازی مداوم و بی‌پایان را رد می‌کند. اصل حاکم در اینجا این است: بدان $\rightarrow$ انجام بده $\rightarrow$ در صورت نیاز یاد بگیر $\rightarrow$ حفظ کن $\rightarrow$ بازاستفاده کن. اگر یک مدار وظیفه‌ای را به‌درستی انجام می‌دهد، حفظ می‌شود.
این معماری صراحتاً جایگزینی یک رویه کاربردی را صرفاً به این دلیل که یک رویه «تئوریک بهتر» وجود دارد، ممنوع می‌کند، مگر اینکه یک شکست عملیاتی و واقعی رخ داده باشد. این رویکرد باعث می‌شود دانش به‌جای تغییر و جایگزینی، «افزایشی» باشد. یادگیری دیگر نیازی به تغییر وزن‌ها (Weights) — یعنی همان تنظیمات داخلی شبکه عصبی که تعیین‌کننده رفتار مدل است — ندارد و فقط به افزودن یک ورودی جدید به نقشه و حافظه نیاز دارد. هرگونه تغییر در یک مدار باید توسط عملکرد واقعی آن توجیه شود، نه بر اساس ترجیحات کلی معماری.
اعتبارسنجی و قوانین عامل
برای هر عامل هوش مصنوعی که روی Alice کار می‌کند، مجموعه‌ای از قوانین سخت‌گیرانه اعمال می‌شود. آن‌ها نباید ویژگی‌هایی را صرفاً به این دلیل که در سایر سیستم‌های عاملی رایج است، معرفی کنند. برای اینکه یک قابلیت جدید به عنوان «اکتساب‌شده» اعلام شود، سیستم باید زنجیره کامل را به اثبات برساند: تولید $\rightarrow$ حفظ $\rightarrow$ بازیابی $\rightarrow$ بهره‌برداری.
این تغییر دیدگاه، معیار سنجش (Benchmark) عامل‌های هوش مصنوعی را عوض می‌کند. به‌جای اندازه‌گیری امتیاز MMLU یک مدل، چارچوب Alice توانایی کشف یک راهکار، تبدیل آن به یک نمایش قابل بهره‌برداری، حفظ آن و بازیابی آن برای استفاده‌های بعدی را می‌سنجد.
برای توسعه‌دهندگان، این یعنی «هوش» یک عامل را می‌توان از طریق لایه مسیریابی و ساختار حافظه مهندسی کرد. در این حالت، انتخاب مدل زبانی صرفاً به کیفیت زبانی و لحن مربوط می‌شود، نه به توانایی‌های هسته‌ای و بنیادین سیستم.
در آینده باید منتظر متن‌باز شدن احتمالی فرمت «نقشه زنده» بود؛ اتفاقی که می‌تواند به سیستم‌های مختلف هوش مصنوعی محلی اجازه دهد تا مدارهای عملیاتی خود را بدون نیاز به اشتراک‌گذاری وزن‌های عظیم مدل‌ها، با یکدیگر به اشتراک بگذارند.
گام بعدی شما
- بررسی ساختار فایل‌های JSON برای پیاده‌سازی نقشه‌های زنده در پروژه‌های محلی.
- جایگزینی استدلال‌های تکراری LLM با رویه‌های تأییدشده در پایگاه‌داده SQLite برای کاهش هزینه استنتاج.
- مطالعه متدولوژی Q-learning برای تبدیل رفتارهای تکراری عامل به مدارهای ثابت.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو