چهار بلوک ساختاری FROST حافظهٔ بلندمدت را به عامل‌های هوش مصنوعی بازگرداند

تصور کنید برنامه‌نویسی هستید که از تکرار مداوم یک عملیات سنگین در هر اجرای جدیدِ عامل خود خسته شده است. اگر هنوز هر بار تمام زمینه (Context) را به مدل ارسال می‌کنید تا حافظه داشته باشد، باید بدانید که راهی بهینه‌تر برای مدیریت وضعیت وجود دارد.

بر اساس مستندات منتشر شده در ۳۰ ژوئیه ۲۰۲۶ توسط توسعه‌دهنده Shen Tong، فریم‌ورک FROST (Runtime of Orchestrated Skills & Tasks) ثابت می‌کند که می‌توان یک عامل وظیفه‌محور را تنها با چهار بلوک ساختاری در ۵ دقیقه ایجاد کرد. این رویکرد با این پیش‌فرض آغاز می‌شود که یادگیری یک فریم‌ورک نه با خواندن کوه‌ها از مستندات، بلکه با ساخت چیزی است که واقعاً اجرا شود.

bیشتر فریم‌ورک‌های مدرن با مشکل «حافظه ماهی» دست‌وپنجه نرم می‌کنند؛ یعنی هر اجرا از صفر شروع می‌شود. این ناکارآمدی باعث می‌شود توسعه‌دهندگان یا بودجه توکن (Token) — تکه‌های کوچکی از متن که شبیه برش‌های یک کیک طولانی‌اند و مدل تکه‌تکه آن‌ها را می‌خورد — را با ارسال مجدد زمینه هدر دهند یا هفته‌ها وقت صرف ساخت لایه‌های دیتابیس سفارشی کنند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مدیریت وضعیت در مدل‌های زبانی اشاره کردیم، جداسازی قابلیت اجرا از حافظهٔ اجرا، کلید مقیاس‌پذیری است. FROST دقیقاً همین کار را می‌کند: جداسازی توانایی انجام یک تکلیف از حافظه‌ی مربوط به انجام آن.

چهار مؤلفه اتمی

به نقل از راهنمای فنی این پروژه، فریم‌ورک بر یک سلسله‌مراتب ساختاری سخت‌گیرانه برای مدیریت اجرا تکیه دارد. نویسنده برای توضیح این چهار اتم از تشبیهات بیولوژیک و عملیاتی استفاده کرده است:

• ذخیره‌ساز (Store): ظرف حافظه که مسئول ذخیره و بازیابی داده‌ها است (مشابه هسته سلول).
• مهارت (Skill): واحدی از قابلیت که بدون وضعیت (Stateless) است و اثر جانبی ندارد (مشابه پروتئین).
• عامل (Agent): موجودیتی اجرایی که یک ذخیره‌ساز و مجموعه‌ای از مهارت‌ها را ترکیب می‌کند (مشابه سلول).
• SOP (رویه عملیاتی استاندارد): فهرستی مرتب از گام‌ها که دیکته می‌کند عامل کدام مهارت را و با چه ترتیبی فراخوانی کند (مشابه دفترچه راهنمای عملیات).

در این مدل، جریان کار کاملاً خطی است: وظیفه کاربر $
ightarrow$ عامل $
ightarrow$ اجرای مهارت از طریق SOP $
ightarrow$ ذخیره نتایج در Store $
ightarrow$ خروجی نهایی.

منطق پیاده‌سازی و محیط

FROST یک پروژه خالص پایتون با صفر وابستگی خارجی برای کد هسته است؛ به این معنا که برای کارکرد پایه نیازی به API مدل‌های زبانی (LLM) ندارد. توسعه‌دهندگان می‌توانند پروژه را از Gitee از طریق آدرس https://gitee.com/liao_liang_7514/frost.git کلون کنند. تأیید محیط با اجرای دستور python -m pytest انجام می‌شود که طی آن ۱۹۷ مورد تست (Test Case) اجرا شده و همگی سبز (موفق) می‌شوند. همچنین توسعه‌دهندگان می‌توانند به سادگی با دستور pip install -r requirements.txt پیش‌نیازهای اصلی را نصب کنند.

از آنجا که کد هسته تنها حدود ۵۰۰ خط پایتون است، پیشنهاد می‌شود کاربران ابتدا فایل core.py را بخوانند تا طراحی رابط (Interface Design) این چهار اتم را به طور کامل درک کنند.

برای ساخت یک عامل حداقلی، فرآیند دقیقاً از یک گردش کار سه مرحله‌ای پیروی می‌کند:

گام ۱: تعریف مهارت.
یک مهارت باید یک تابع خالص (Pure Function) باشد. این تابع یک دیکشنری context را به عنوان ورودی می‌گیرد و یک دیکشنری context تغییر یافته را برمی‌گرداند. مهارت نمی‌تواند وضعیت داخلی داشته باشد (یعنی هیچ استفاده‌ای از self.xxx نشود). برای مثال، مهارت skill_uppercase یک متن را می‌گیرد و آن را به حروف بزرگ تبدیل می‌کند، در حالی که skill_add_prefix رشته‌ای مانند [FROST] را به ابتدای متن اضافه می‌کند. این رویکرد توابعی تضمین می‌کند که مهارت‌ها ترکیب‌پذیر و قابل آزمایش باشند، که دقیقاً بازتاب‌دهنده اصول برنامه‌نویسی تابعی است.

گام ۲: اسمبل کردن عامل.
عامل با مقداردهی اولیه یک Store با یک مسیر ذخیره‌سازی مشخص (مثلاً ./my_agent_memory) و ثبت مهارت‌ها در یک دیکشنری ایجاد می‌شود. عاملی به نام "text_processor" به ذخیره‌ساز خود و مجموعه‌ای از مهارت‌های نگاشته شده متصل می‌شود: {"uppercase": skill_uppercase, "add_prefix": skill_add_prefix}. این کار به عامل دو قابلیت مشخص می‌دهد: تبدیل به حروف بزرگ و افزودن پیشوند.

گام ۳: اجرا از طریق SOP.
به جای تکیه بر حدس‌های مدل زبانی برای گام بعدی، توسعه‌دهنده یک توالی صریح تعریف می‌کند. با استفاده از متد agent.run و ارسال sop_steps=["uppercase", "add_prefix"] به همراه یک زمینه اولیه (مثلاً {"text": "hello frost", "prefix": "[Processed]"})، خروجی قطعی و پیش‌بینی‌پذیر تولید می‌شود: [Processed] HELLO FROST.

حل تکرار محاسباتی با حافظه

قدرت واقعی FROST هنگام تحلیل داده‌های پیچیده و «وراثت حافظه» نمایان می‌شود. در سناریوهای واقعی، یک عامل می‌تواند با بررسی Store برای یک کلید داده‌ای خاص، از محاسبات تکراری و هزینه‌بر جلوگیری کند.

یک عامل تحلیل داده را تصور کنید که از دو مهارت خاص استفاده می‌کند:

• skill_analyze: این مهارت ابتدا از طریق context["_store"] به ذخیره‌ساز دسترسی پیدا می‌کند و با استفاده از یک data_key بررسی می‌کند که آیا نتیجه‌ای در کش (Cache) وجود دارد یا خیر. اگر پیدا شود، منبع (source) را روی "cache" تنظیم کرده و مقدار را برمی‌گرداند. در غیر این صورت، یک دیکشنری نتیجه شامل count (تعداد)، sum (مجموع)، avg (میانگین) و یک برچسب زمانی با استفاده از datetime.now().isoformat() محاسبه می‌کند. سپس این نتیجه را برای استفاده‌های آینده در Store ذخیره می‌کند (مثلاً store.save(f"analysis_{data_key}", result)).
• skill_report: این مهارت نتایج را در قالب یک گزارش فرمت‌بندی شده نمایش می‌دهد. این مهارت از یک رشته فرمت شده برای نمایش منبع داده (محاسباتی در مقابل کش)، تعداد کل، مجموع و میانگین (که تا دو رقم اعشار رند شده است) استفاده می‌کند.

این «اثر ترکیبی» اجازه می‌دهد عامل‌ها از محاسبات گران‌قیمت عبور کنند. در یک اجرای آزمایشی با کلیدی مانند sales_2026q2 و داده‌های [100, 200, 150, 300, 250]، اجرای اول منبع را source = "computed" نشان داد. اما اجرای دوم دقیقاً همان وظیفه را فوراً با نتیجه source = "cache" بازگرداند و کل فرآیند محاسبه را نادیده گرفت. این ثابت می‌کند عامل‌های FROST دارای حافظه میان-وظیفه‌ای هستند، در حالی که عامل‌های سنتی هر بار از صفر شروع می‌کنند.

انتقال به تولید با FROST-SOP

در حالی که کتابخانه اصلی FROST یک ابزار آموزشی سبک با حدود ۵۰۰ خط پایتون در فایل core.py است، اما مبنایی برای FROST-SOP فراهم می‌کند که یک پیاده‌سازی در سطح مهندسی است و در آدرس https://gitee.com/liao_liang_7514/frost-sop در دسترس است.

FROST-SOP سیستم را از یک فرآیند تک‌گام و همگام (Synchronous) به یک پلتفرم Event-Driven (رویداد-محور) ارتقا می‌دهد. برای انتقال از محیط آموزشی به محیط تولید، این نسخه موارد زیر را مدیریت می‌کند:

• هماهنگ‌سازی (Orchestration): تغییر از لیست‌های خطی ساده به ارکستراسیون مبتنی بر گراف‌های جهت‌دار بدون دور (DAG) از طریق SOPEngine و EventBus.
• مدیریت وابستگی: در نسخه مهندسی، وظایف به شکل اشیاء تعریف می‌شوند. یک وظیفه مانند "quarterly_analysis" می‌تواند یک DAG داشته باشد که در آن fetch_data هیچ وابستگی‌ای ندارد، analyze به fetch_data وابسته است، report به analyze وابسته است و notify به report وابسته است.
• امنیت و انطباق: پیاده‌سازی سطوح دسترسی (مانند دسترسی سطح "P2") و محیط‌های ایزوله (Sandbox) برای جلوگیری از اجرای غیرمجاز مهارت‌ها.
• عملیات (Operations): افزودن زمان‌بندی نامتقارن (Asynchronous scheduling)، لاگ‌های بازرسی (Audit Logs) جامع و ردیابی هزینه منابع برای مشاهده‌پذیری (Observability) بهتر.

در نسخه مهندسی، فرآیند از یک agent.run() ساده به یک فراخوانی نامتقارن تغییر می‌کند: await engine.execute(task).

تحلیل: بازتعریف معماری عامل

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

این معماری یک مسیر رشد شفاف برای توسعه‌دهندگان ایجاد می‌کند:

۱. یادگیری: درک ۴ اتم از طریق فریم‌ورک ۵۰۰ خطی FROST.
۲. مهندسی: پیاده‌سازی DAGهای رویداد-محور و سیستم‌های بازرسی از طریق FROST-SOP.
۳. مقیاس‌پذیری: مدیریت خانواده‌های چندعاملی از طریق یک سلسله‌مراتب شامل هماهنگی پدربزرگ (Grandparent Coordination)، زمان‌بندی پدر (Parent Scheduling) و اجرای نوه (Grandchild Execution).

این نشان می‌دهد که آینده هوش مصنوعی قابل اعتماد در پرامپت‌های بهتر نیست، بلکه در هماهنگ‌سازی (Orchestration) بهتر است. توانایی اشتراک وضعیت در یک خانواده از عامل‌ها، مقیاسی از عملیات را ممکن می‌کند که عامل‌های تک‌رشته‌ای (Single-threaded) هرگز به آن نمی‌رسند.

تمرین کاربردی و منابع

برای تسلط بر این مدل، سه تمرین پیش‌رونده پیشنهاد شده است:

• مبتدی: اجرای مثال ۳ مرحله‌ای برای درک جریان مهارت $
  ightarrow$ عامل $
  ightarrow$ SOP.
• متوسط: افزودن مدیریت خطا به skill_analyze (مثلاً مدیریت داده‌های خالی یا خطاهای نوع داده) برای درک محدودیت‌های یک تابع خالص.
• پیشفته: کلون کردن FROST-SOP و استفاده از SOPEngine برای بازنویسی وظیفه تحلیل داده جهت مشاهده تفاوت‌های میان نسخه آموزشی و مهندسی.

برای مطالعه بیشتر، منابع زیر در دسترس هستند:

• فریم‌ورک آموزشی FROST: https://gitee.com/liao_liang_7514/frost (شامل فایل WHITEPAPER.md نسخه ۴).
• پلتفرم FROST-SOP: https://gitee.com/liao_liang_7514/frost-sop (شامل اسناد طراحی دقیق در دایرکتوری /docs).

با پایبندی به سه اصل «مهارت‌های بدون وضعیت»، «ذخیره‌سازهای دارای وضعیت» و «SOPهای ترکیب‌پذیر»، توسعه‌دهندگان می‌توانند عامل‌هایی بسازند که حس واقعی تبار، حافظه و قابلیت اطمینان عملیاتی دارند. این رویکرد، هوش مصنوعی را از مجموعه‌ای از پرامپت‌های گسسته به یک سیستم ساختاریافته، شریف و منظم از حافظه و توانمندی تبدیل می‌کند.

گام بعدی شما

• کدهای core.py در مخزن FROST را بخوانید تا با پیاده‌سازی minimalist اتم‌های چهارگانه آشنا شوید.
• سعی کنید یک مهارت (Skill) جدید بنویسید که فقط ورودی بگیرد و خروجی بدهد، بدون اینکه متغیری را در خارج از تابع تغییر دهد.
• تفاوت اجرای خطی در نسخه آموزشی و اجرای مبتنی بر گراف (DAG) در نسخه SOP را با یک پروژه کوچک تست کنید.

اما داستان سخت‌افزاریِ مدیریت این حافظه‌ها در مقیاس کلان، ابعاد پیچیده‌تری دارد — به تحلیل ما درباره‌ی بهینه‌سازی KV Cache در مدل‌های زبانی مراجعه کنید.