AI Agents در سال ۲۰۲۶؛ از مدل‌های زبانی تا عامل‌های هوشمند خودمختار

در سه سال گذشته، مدل‌های زبانی بزرگ (LLM) دنیای نرم‌افزار را تکان دادند. اما در سال ۲۰۲۶، مرکزِ ثقلِ بحث دیگر «مدل» نیست؛ عامل (Agent) است. تفاوت ظریف اما بنیادی است: یک LLM حرف می‌زند، اما یک Agent کار می‌کند. این مقاله یک بررسی فنی و عمیق است از اینکه عامل‌های مدرن دقیقاً چگونه کار می‌کنند، از چه اجزایی ساخته شده‌اند، چه تفاوت معماری‌ای با ChatGPT دارند، و این فناوری به کجا می‌رود.

ما در این مقاله دو پروژه‌ی شاخص و متن‌بازِ نسل جدید — OpenClaw و Hermes Agent — را به‌صورت عمیق کالبدشکافی می‌کنیم، آن‌ها را با فریم‌ورک‌های دیگر مقایسه می‌کنیم، به سراغ سیستم‌های چندعاملی و امنیت می‌رویم، و در پایان یک معماری مرجع برای ساخت یک Agent از صفر ارائه می‌دهیم. تمرکز ما بر فهم عمیق فنی است، نه معرفی سطحی؛ و هرجا اختلاف‌نظر یا ادعای تأییدنشده‌ای وجود دارد، صریحاً آن را علامت می‌زنیم.

بخش اول: LLM چیست و چرا کافی نیست؟

برای فهمِ اینکه چرا Agentها به‌وجود آمدند، اول باید دقیق بدانیم یک LLM چه می‌کند — و مهم‌تر، چه نمی‌تواند بکند.

ChatGPT دقیقاً چگونه کار می‌کند؟

در قلبِ ChatGPT (و هر LLM دیگری) یک مکانیزم فریبنده‌ساده قرار دارد: پیش‌بینیِ توکنِ بعدی (next-token prediction). مدل یک دنباله از توکن‌ها (context) را می‌گیرد و یک توزیع احتمال روی توکنِ بعدی تولید می‌کند؛ یک توکن نمونه‌برداری می‌شود، به انتهای متن اضافه می‌شود، و این چرخه تکرار می‌شود — توکن به توکن. مدل با یادگیریِ خودنظارتی روی حجم عظیمی از متن آموزش دیده تا احتمالِ ادامه‌ی درست را بالا ببرد.

از همین طراحیِ ساده، دو ویژگیِ سرنوشت‌ساز بیرون می‌آید:

• بی‌حالتی (Statelessness): رفتار مدل فقط به «پنجره‌ی متنِ فعلی» و وزن‌های ثابتش وابسته است. هیچ حالتی بین دو فراخوانیِ API در خودِ مدل باقی نمی‌ماند. به‌همین‌دلیل APIهای LLM ذاتاً بدونِ حالت هستند؛ در هر درخواست، کلِ تاریخچه دوباره فرستاده می‌شود.
• دانشِ منجمد: هرچه مدل «می‌داند» در زمان آموزش در وزن‌هایش پخته شده. نمی‌تواند اطلاعات تازه بگیرد و نمی‌تواند روی دنیای بیرون عمل کند.

محدودیت‌های یک LLM معمولی

یک «دستیار» (مثل ChatGPT در حالت چت ساده) در واقع همان LLM است که با تنظیم دستوری (instruction tuning / RLHF) و یک قالب گفت‌وگو پیچیده شده. پس همه‌ی محدودیت‌های پایه را به ارث می‌برد:

محدودیت	ریشه‌ی فنی
حافظه‌ی پایدار بین نشست‌ها ندارد	بی‌حالتی — تنها حاملِ حالت، پنجره‌ی متن است که محدود است
ابزار ندارد، عمل نمی‌کند	مدل فقط متن تولید می‌کند؛ خودش چیزی را اجرا نمی‌کند
به داده‌ی تازه دسترسی ندارد	دانش در وزن‌ها منجمد است
توهم (Hallucination) و انتشار خطا	استدلالِ صرفاً زنجیره‌ای، «زمین‌گیر» (grounded) نیست
برنامه‌ریزی و پیگیریِ هدف ندارد	حلقه‌ای وجود ندارد؛ حالتی نیست که هدفِ چندمرحله‌ای را حمل کند

چرا نیاز به Agent ایجاد شد؟

Agent دقیقاً پاسخِ معماری به این محدودیت‌هاست. هر کمبود را با یک لایه‌ی بیرونی وصله می‌کند:

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

مقاله‌ی بنیادینِ ReAct (Yao و همکاران، ۲۰۲۲) دقیقاً همین را نشان داد: وقتی مدل به‌جای صرفاً «فکر کردن»، بین فکر و کنش رفت‌وبرگشت کند و نتیجه‌ی کنش را ببیند، هم توهمش کم می‌شود و هم می‌تواند خودش را تصحیح کند.

LLM در برابر Assistant در برابر Agent

معیار	LLM خام	Assistant (چت‌بات)	Agent
مکانیزم اصلی	پیش‌بینی توکن بعدی	LLM + تنظیم دستوری و قالب چت	LLM به‌عنوان «مغز» + برنامه‌ریزی + حافظه + ابزار
حالت (State)	بدون حالت	بدون حالت (فقط درونِ یک نشست)	دارای حالت، پایدار بین نشست‌ها
کنش	هیچ (فقط متن)	هیچ (فقط متن)	ابزار و کنشِ واقعی در محیط اجرا می‌کند
کنترلِ جریان	—	یک نوبت: پرسش ← پاسخ	خودِ LLM جریان چندمرحله‌ای را هدایت می‌کند
داده‌ی تازه	خیر	خیر	بله (بازیابی، وب، API)
افقِ هدف	یک تکمیل	یک پاسخ	چندمرحله‌ای و هدف‌محور

⚠️ یک اختلاف‌نظرِ واقعی: مرزِ «دستیار» و «عامل» شفاف نیست. یک چت‌بات که فقط یک ابزار صدا می‌زند هم گاهی «Agent» بازاریابی می‌شود. تعریفِ عملیاتی‌ای که بیشترین اجماع را دارد، از Anthropic است و مرز را روی مالکیتِ جریانِ کنترل می‌گذارد (در ادامه).

بخش دوم: AI Agent دقیقاً چیست؟

تعریف دقیق

معتبرترین تعریفِ عملیاتی از مقاله‌ی «ساخت Agentهای مؤثر» (Anthropic، دسامبر ۲۰۲۴) می‌آید که همه‌چیز را زیر چترِ «سیستم‌های عامل‌گونه» می‌گذارد اما یک خطِ معماریِ تیز می‌کشد:

• Workflow (گردش‌کار): «سیستم‌هایی که در آن‌ها LLMها و ابزارها از طریق مسیرهای کدِ از پیش تعریف‌شده هماهنگ می‌شوند.» جریانِ کنترل را برنامه‌نویس هاردکد کرده است.
• Agent (عامل): «سیستم‌هایی که در آن‌ها LLM به‌صورت پویا فرایندها و استفاده از ابزارهای خود را هدایت می‌کند و کنترلِ چگونگیِ انجام کار را در دست دارد.» جریانِ کنترل متعلق به خودِ مدل است.

پس معیارِ تمایز، «چه کسی جریان کنترل را در اختیار دارد» است: برنامه‌نویس (اسکریپت) یا مدل (سیاست). Anthropic هشدار هم می‌دهد: خودمختاریِ Agent یعنی «هزینه‌ی بالاتر و احتمالِ انباشتِ خطا»، و توصیه می‌کند همیشه ساده‌ترین راه‌حلِ کافی را انتخاب کنید.

تعریفِ کلاسیکِ آناتومی هم از Lilian Weng (ژوئن ۲۰۲۳) می‌آید: «LLM به‌عنوان مغزِ عامل عمل می‌کند، که با چند جزء کلیدی تکمیل می‌شود» — یعنی برنامه‌ریزی، حافظه و استفاده از ابزار.

اجزای یک Agent

جزء	نقش
Brain (مغز — همان LLM)	کنترل‌کننده/سیاستِ مرکزی؛ تصمیم می‌گیرد گام بعدی چه فکر یا چه کنشی باشد
Reasoning Engine (موتور استدلال)	زنجیره‌ی تفکر (CoT) و جانشینانش؛ تولید گام‌های استدلالیِ میانی پیش از پاسخ یا کنش
Planning System (برنامه‌ریزی)	تجزیه‌ی هدف به زیرهدف‌ها + بازاندیشی و اصلاحِ مسیر
Memory (حافظه)	کوتاه‌مدت (پنجره‌ی متن) + بلندمدت (ذخیره‌ساز بیرونی)
Tool Layer (لایه‌ی ابزار)	تعریفِ شِماییِ ابزارها که مدل می‌تواند صدایشان بزند
Execution Layer (لایه‌ی اجرا)	رانتایمِ بیرونی که فراخوانی را واقعاً اجرا و نتیجه را برمی‌گرداند — این با خودِ مدل فرق دارد
Feedback Loop (حلقه‌ی بازخورد)	مشاهده‌ی نتیجه/خطا و بازگرداندنش به متن برای گام بعد
Environment (محیط)	دنیایی که Agent روی آن عمل می‌کند: مرورگر، شل، پایگاه‌داده، یا نشستِ کاربر

چارچوبِ آکادمیکِ CoALA (Sumers و همکاران، ۲۰۲۳) این را رسمی‌تر می‌کند و زیرلایه‌ی حافظه را به چهار نوع تقسیم می‌کند: کاری (Working)، رویدادی (Episodic)، معنایی (Semantic) و رویه‌ای (Procedural) — که در بخش چهارم عمیق می‌شویم.

دیاگرام معماری (Mermaid)

برای کسانی که می‌خواهند این معماری را در ابزار خودشان بازسازی کنند، معادلِ Mermaidِ دیاگرام بالا:

graph TD
    U[User Goal] --> C[Agent Controller]
    C --> B[Brain: LLM]
    B --> R[Reasoning: CoT / ReAct]
    B --> P[Planning: decompose goal]
    B --> T[Tool Layer: schemas]
    T --> E[Execution Layer: runtime]
    E --> ENV[(Environment: browser, shell, API, DB)]
    ENV --> F[Feedback: observation]
    F --> B
    M[(Memory: short + long term)] <--> B
    B --> OUT[Result]

بخش سوم: چرخه‌ی کاری یک AI Agent

قلبِ هر Agent یک حلقه است. برخلاف چت‌بات که یک‌بار پاسخ می‌دهد و تمام، Agent تا رسیدن به هدف (یا رسیدن به سقفِ تکرار) می‌چرخد. الگوهای بنیادینِ این حلقه از چند مقاله‌ی کلیدی می‌آیند:

مرحله	الگوی پژوهشی	در عمل چه اتفاقی می‌افتد
Observe (مشاهده)	ReAct	خواندنِ ورودی کاربر، حالت فعلی و نتیجه‌ی آخرین کنش
Reason (استدلال)	Chain-of-Thought	تولید گام‌های فکریِ میانی پیش از تصمیم
Plan (برنامه‌ریزی)	Plan-and-Solve، ToT، LLM+P	تجزیه‌ی هدف به زیرگام‌های اجراپذیر
Act (کنش)	ReAct، Function Calling	انتخاب ابزار و تولید فراخوانیِ ساختاریافته
Evaluate (ارزیابی)	Reflexion، Self-Refine	آیا نتیجه درست بود؟ خطا خورد؟
Learn (یادگیری)	Reflexion، Voyager	نوشتنِ درس‌آموخته در حافظه یا ساختِ یک «مهارت»

مقالات کلیدی که این حلقه را ساختند

• Chain-of-Thought (Wei و همکاران، ۲۰۲۲): وادارکردن مدل به تولید گام‌های استدلالیِ میانی. نکته‌ی مهم: این توانایی فقط در مدل‌های به‌قدر کافی بزرگ ظهور می‌کند.
• ReAct (Yao و همکاران، ۲۰۲۲): درهم‌تنیدنِ Thought → Action → Observation. تعامل با یک API ساده‌ی ویکی‌پدیا، توهم و انتشارِ خطای CoTِ خالص را جبران کرد. نتایج: +۳۴٪ مطلق در ALFWorld و +۱۰٪ در WebShop نسبت به خطوطِ پایه.
• Reflexion (Shinn و همکاران، ۲۰۲۳): تقویت با بازخوردِ کلامی، نه به‌روزرسانیِ وزن. سه‌گانه‌ی Actor / Evaluator / Self-Reflection؛ بعد از هر تلاش، بازاندیشی در یک بافرِ حافظه‌ی رویدادی نوشته و در تلاش بعدی خوانده می‌شود. نتیجه: ۹۱٪ pass@1 روی HumanEval در برابر ۸۰٪ خطِ پایه‌ی GPT-4.
• Plan-and-Solve (Wang و همکاران، ۲۰۲۳): اول نقشه بکش، بعد اجرا کن — برای رفعِ خطاهای محاسباتی و گام‌های جاافتاده.
• Tree of Thoughts (Yao و همکاران، ۲۰۲۳): جست‌وجو روی درختی از «افکار» با پیش‌نگری و عقب‌گرد. در بازیِ Game of 24، GPT-4 با CoT فقط ۴٪ و با ToT ۷۴٪ موفق شد.
• LLM+P (Liu و همکاران، ۲۰۲۳): ترجمه‌ی مسئله به زبانِ برنامه‌ریزیِ کلاسیک (PDDL)، حل با یک برنامه‌ریزِ کلاسیک، و ترجمه‌ی برگشت — چون LLMها به‌تنهایی اغلب حتی نقشه‌ی شدنی برای افق‌های بلند تولید نمی‌کنند.

مثال واقعی: «برای من یک گزارش بازار سهام آماده کن»

ببینیم یک Agent در عمل چه می‌کند. کاربر می‌گوید: «برای من یک گزارش از بازار سهام امروز آماده کن.»

گام	Agent چه می‌کند
۱. Observe	ورودی کاربر را می‌خواند. حافظه را چک می‌کند: «این کاربر قبلاً گفته گزارش‌ها را به‌صورت جدول و به فارسی می‌خواهد.»
۲. Reason	«برای یک گزارش بازار، به سه چیز نیاز دارم: شاخص کل، نمادهای پرمعامله، و خبرهای مهم امروز. هیچ‌کدام در دانشِ من نیست — باید داده‌ی زنده بگیرم.»
۳. Plan	نقشه: (الف) فراخوانیِ API قیمت‌ها؛ (ب) جستجوی وب برای اخبار؛ (ج) تحلیل و محاسبه؛ (د) تولید فایل خروجی.
۴. Act	ابزار market_api.get_index() را با آرگومان‌های ساختاریافته صدا می‌زند. خودِ مدل اجرا نمی‌کند — فقط یک فراخوانیِ JSON تولید می‌کند؛ رانتایم آن را اجرا می‌کند و نتیجه را برمی‌گرداند.
۵. Evaluate	پاسخ خطای ۴۲۹ (محدودیت نرخ) می‌دهد. Agent می‌بیند شکست خورده؛ چند ثانیه صبر و دوباره تلاش می‌کند. بار دوم داده می‌آید. بررسی می‌کند که آیا داده کامل است.
۶. Act (تکرار حلقه)	ابزار جستجوی وب را برای اخبار صدا می‌زند، بعد ابزار اجرای کد (Python) را برای محاسبه‌ی درصد تغییرات، و در نهایت write_file() را برای ساختِ گزارش.
۷. Learn	در حافظه می‌نویسد: «API بازار سهام محدودیت نرخ دارد؛ دفعه‌ی بعد بین فراخوانی‌ها تأخیر بگذار.» شاید حتی یک «مهارت» به‌نام گزارش روزانه‌ی بازار ذخیره کند تا دفعه‌ی بعد کل این مسیر را از نو کشف نکند.

یک چت‌بات در گام ۲ گیر می‌کرد و یا می‌گفت «من به داده‌ی زنده دسترسی ندارم» یا — بدتر — عددی از خودش می‌ساخت. تفاوت، در همان حلقه و ابزار است.

بخش چهارم: حافظه (Memory) در AI Agentها

اگر بخواهیم یک تفاوت را به‌عنوان مهم‌ترین تفاوتِ Agent و چت‌بات انتخاب کنیم، آن حافظه است. چون API مدل بی‌حالت است، یک چت‌بات هر درخواست را یک تراکنشِ منزوی می‌بیند. یک Agentِ دارای حالت اما پیش از ساختنِ پرامپت، حالتِ پیشین را از یک ذخیره‌ساز بیرونی می‌خواند و پس از پاسخ، حالتِ به‌روز را برمی‌گرداند.

جمله‌ای که این را خوب خلاصه می‌کند: پنجره‌ی متن، Agent را درونِ یک نشست منسجم نگه می‌دارد؛ اما حافظه است که آن را بین نشست‌ها هوشمند می‌کند.

انواع حافظه

نوع	چیست	کجا ذخیره می‌شود
Working (کاری)	متغیرهای زنده‌ی همین چرخه‌ی تصمیم — دفترچه‌ی یادداشتِ لحظه‌ای	پنجره‌ی متن
Short-Term (کوتاه‌مدت)	تاریخچه‌ی گفت‌وگوی همین نشست؛ «یادگیری درون‌متنی»	پنجره‌ی متن (محدود و متناهی)
Long-Term (بلندمدت)	هر چیزی که باید بعد از بسته‌شدنِ نشست بماند	پایگاه‌داده‌ی بیرونی
Vector (برداری)	امبدینگ‌ها + جست‌وجوی شباهت؛ پایه‌ی RAG	پایگاه‌داده‌ی برداری (FAISS، HNSW و...)
Episodic (رویدادی)	تجربه‌ها و مسیرهای اجرایِ گذشته («دفعه‌ی قبل چه کردم و چه شد»)	ذخیره‌ساز بیرونی
Semantic (معنایی)	دانش درباره‌ی جهان و درباره‌ی خودِ کاربر («این کاربر مدیر مالی است»)	ذخیره‌ساز بیرونی
Procedural (رویه‌ای)	«چگونه انجام دادن» — مهارت‌ها و رویه‌های آموخته‌شده	وزن‌های مدل + کد/فایل‌های مهارت

معماری‌های مرجعِ حافظه

• RAG (Lewis و همکاران، ۲۰۲۰): ترکیبِ حافظه‌ی پارامتری (وزن‌های مدل) با حافظه‌ی غیرپارامتری (یک ایندکسِ برداریِ متراکم که با یک بازیاب عصبی خوانده می‌شود). این همان مکانیزمی است که زیرِ «حافظه‌ی برداری» نشسته است.
• MemGPT / Letta (Packer و همکاران، ۲۰۲۳): مدیریتِ متنِ مجازی به‌قیاسِ حافظه‌ی سلسله‌مراتبیِ سیستم‌عامل. یک main context (پنجره‌ی متن = «RAM») و یک external context (بایگانی = «دیسک»). نکته‌ی درخشان: خودِ LLM با فراخوانیِ توابعِ خودش اطلاعات را بین این دو صفحه‌بندی (page in/out) می‌کند — حتی می‌تواند پرامپتِ سیستمیِ خودش را ویرایش کند.
• Generative Agents (Park و همکاران، ۲۰۲۳): یک «جریانِ حافظه» به زبان طبیعی، با امتیازِ بازیابی = تازگی + اهمیت + ارتباط. تازگی با افتِ نمایی (γ = ۰.۹۹۵)، اهمیت با یک امتیازِ ۱ تا ۱۰ که خودِ LLM می‌دهد، و ارتباط با شباهتِ کسینوسیِ امبدینگ. مکانیزمِ Reflection هم به‌صورت دوره‌ای خاطراتِ سطحِ پایین را به انتزاع‌های سطحِ بالاتر تبدیل می‌کند.
• A-MEM (Xu و همکاران، ۲۰۲۵): حافظه‌ی عامل‌گونه به سبکِ Zettelkasten؛ هر خاطره یک یادداشتِ ساختاریافته (توضیح، کلیدواژه، برچسب) می‌شود، سیستم خودش یادداشت‌های مرتبط را به هم لینک می‌کند، و — نکته‌ی متمایز — افزودنِ یک خاطره‌ی جدید می‌تواند خاطراتِ قدیمی را هم به‌روز کند (تکاملِ پویا)، نه اینکه فقط درج شود.

⚠️ حافظه هنوز حل‌نشده است. این رویکردها واگرا هستند (صفحه‌بندی به سبکِ OS در MemGPT، امتیازدهیِ وزن‌دار در Generative Agents، گرافِ دانشِ تکامل‌یابنده در A-MEM) و هیچ استانداردِ غالبی وجود ندارد — نشانه‌ی روشنی از اینکه این حوزه هنوز در حال تثبیت است.

بخش پنجم: استفاده از ابزار و اجرای کنش

اینجا مهم‌ترین سوءتفاهمِ فنیِ حوزه‌ی Agent را باید رفع کنیم.

تفاوت بنیادی: تولیدِ متن در برابر اجرای کنش

LLM هیچ‌وقت چیزی را اجرا نمی‌کند. کاری که می‌کند این است که یک فراخوانیِ ساختاریافته (معمولاً یک آبجکت JSON با نام تابع و آرگومان‌ها) تولید می‌کند — و این خودش «تولید متن» است. سپس یک رانتایمِ بیرونی آن فراخوانی را می‌گیرد، واقعاً اجرا می‌کند (تابع را صدا می‌زند، به API می‌زند، کوئری می‌گیرد، کد را اجرا می‌کند) و نتیجه را به متنِ مدل برمی‌گرداند.

هر دو غولِ اصلی این را صریح گفته‌اند:

• OpenAI (Function Calling، ژوئن ۲۰۲۳): توسعه‌دهنده توابع را توصیف می‌کند؛ مدل «هوشمندانه انتخاب می‌کند که یک آبجکت JSON حاوی آرگومان‌ها خروجی دهد» — اما اجرا نمی‌کند؛ کدِ توسعه‌دهنده اجرا و نتیجه را برمی‌گرداند.
• Anthropic (Tool Use): Claude «یک فراخوانیِ ساختاریافته برمی‌گرداند که اپلیکیشنِ شما اجرا می‌کند». جریان: مدل stop_reason: "tool_use" می‌دهد ← کدِ شما اجرا می‌کند ← یک tool_result برمی‌گردانید ← مدل پاسخ نهایی را می‌دهد.

پس دقیق‌تر است بگوییم: مدل «قصدِ کنش» تولید می‌کند؛ Agent (رانتایم) آن قصد را به کنشِ واقعی تبدیل می‌کند. این جداییِ ظریف، هم کلیدِ فهمِ معماری است و هم — همان‌طور که در بخش امنیت می‌بینیم — کلیدِ فهمِ خطرات.

Agent چگونه کنش‌های واقعی انجام می‌دهد؟

کنش	مکانیزم	مثال ابزار
باز کردن مرورگر	ابزارِ اتوماسیونِ مرورگر (Playwright/Puppeteer) یا «استفاده از کامپیوتر»	browser.navigate(url)، computer (Anthropic)
فراخوانی API	یک تابع که درخواستِ HTTP می‌زند	http.get(endpoint, params)
کوئریِ پایگاه‌داده	ابزاری که SQL را روی اتصالِ محدودشده اجرا می‌کند	db.query(sql)
ساخت/ویرایش فایل	ابزارِ سیستمِ فایل	text_editor، write_file()
اجرای کد	مفسر در یک محیطِ ایزوله (sandbox)	code_execution، python(code)
تعامل با سیستم‌عامل	ابزارِ شل با مجوزهای محدود	bash(command)

ریشه‌های پژوهشی

• Toolformer (Schick و همکاران، Meta AI، ۲۰۲۳): مدل به‌صورت خودنظارتی به خودش ابزار یاد می‌دهد. نمونه‌فراخوانی‌های API تولید می‌کند، اجرا می‌کند، و فقط آن‌هایی را نگه می‌دارد که نتیجه‌شان سرگشتگی (perplexity) مدل را روی متنِ اطراف کاهش می‌دهد، سپس روی همان داده‌ی فیلترشده فاین‌تیون می‌شود. یاد می‌گیرد کدام API، کِی، با چه آرگومانی، و چگونه از نتیجه استفاده کند.
• ReAct: همان حلقه‌ی Thought→Action→Observation که زیربنای همه‌ی فریم‌ورک‌های ابزارمحورِ امروزی است.

یک بهینه‌سازیِ جالبِ ۲۰۲۵-۲۰۲۶: فراخوانیِ برنامه‌نویسی‌شده‌ی ابزار (Programmatic Tool Calling) — به‌جای اینکه هر فراخوانی یک رفت‌وبرگشت با مدل باشد، مدل کدی می‌نویسد که ابزارها را درونِ یک محیطِ اجرای کد صدا می‌زند. Anthropic گزارش کرده این کار روی یک بنچمارکِ داخلیِ ۷۵ ابزاره، حدود ۳۸٪ توکنِ ورودیِ کمتر بدون افتِ دقت مصرف می‌کند.

بخش ششم: بررسی کامل OpenClaw

⚠️ ابهامِ نام: یک پروژه‌ی قدیمی و کاملاً بی‌ربط هم به نام «OpenClaw» وجود دارد (بازسازیِ C++ِ بازیِ Captain Claw). آنچه اینجا بررسی می‌کنیم، پلتفرمِ AI Agent است. همچنین در جست‌وجوها چند «مقاله‌ی arXiv» با عناوین مشکوک درباره‌ی OpenClaw ظاهر می‌شود که اعتبارشان تأیید نشد و ما به آن‌ها استناد نمی‌کنیم.

OpenClaw چیست و چه مشکلی را حل می‌کند؟

OpenClaw یک پلتفرمِ دستیارِ شخصیِ هوش مصنوعی، متن‌باز و خودمیزبان است که روی سختِ‌افزارِ خودتان اجرا می‌شود و از طریق همان اپ‌های پیام‌رسانی که هر روز استفاده می‌کنید به شما می‌رسد. ساخته‌ی Peter Steinberger (برنامه‌نویس اتریشی، سازنده‌ی PSPDFKit)، با مجوز MIT، عمدتاً به زبانِ TypeScript. نسخه‌ی اولیه در نوامبر ۲۰۲۵ منتشر شد و در ۳۰ ژانویه ۲۰۲۶ به نام OpenClaw تغییرِ نام داد.

ماجرای نام خودش گویاست: نامِ اولیه اشاره‌ای به «Claude» داشت و پس از اعتراضِ حقوقیِ Anthropic تغییر کرد و در نهایت «OpenClaw» شد. (جزئیاتِ ریزِ زنجیره‌ی نام‌ها در منابع مختلف متناقض است؛ همین‌قدر قابل‌اتکاست.)

مسئله‌ای که حل می‌کند در شعارش خلاصه شده: «دستیارِ شما. ماشینِ شما. قوانینِ شما.» دستیارهای اصلیِ بازار ابری‌اند و داده‌ی شما را در اختیار دارند؛ OpenClaw داده، کلیدها و محاسبات را روی زیرساختی نگه می‌دارد که خودتان کنترل می‌کنید. شعارِ دومش هم فلسفه‌ی Agent را می‌رساند: «هوش مصنوعی‌ای که واقعاً کارها را انجام می‌دهد.»

فلسفه‌ی طراحی

• محلی‌محور (Local-first) و حاکمیتِ کاربر: شما مالکِ سخت‌افزار، کلیدها و داده‌اید.
• کنش‌گرا، نه پاسخ‌گو: اجرای دستورِ شل، اتوماسیونِ مرورگر، ایمیل، تقویم و عملیاتِ فایل — نه صرفاً جواب‌دادن.
• پیش‌دستانه (Proactive) و پایدار: بدونِ اینکه از او بپرسید، طبق زمان‌بندی کار می‌کند و بین نشست‌ها به‌یاد می‌آورد.
• هَک‌پذیر و مدل‌ناوابسته: یک پلتفرم است نه یک سرویسِ بسته؛ با Claude، GPT، Gemini و مدل‌های محلی کار می‌کند.

معماری داخلی

مؤلفه	نقش
Gateway (صفحه‌ی کنترلِ مرکزی)	یک فرایندِ خودمیزبان که «تنها منبعِ حقیقت برای نشست‌ها، مسیریابی و اتصالِ کانال‌هاست». یک Gateway هم‌زمان به همه‌ی کانال‌های پیکربندی‌شده سرویس می‌دهد.
Messaging / Channel Layer	پلاگین‌های کانال، اپ‌های بیرونی را به Gateway وصل می‌کنند: واتساپ، تلگرام، اسلک، دیسکورد، سیگنال، iMessage، Teams، Matrix، IRC و ده‌ها مورد دیگر — به‌علاوه‌ی نودهای مک/iOS/اندروید.
Agent Runtime	لایه‌ی پردازش که پرسش‌ها و استفاده از ابزار را اجرا می‌کند. مدل‌ناوابسته از طریق یک واسطِ یکپارچه‌ی provider. پیام‌های مستقیم یک نشستِ اصلی مشترک دارند؛ اما هر گروه، نشستِ جداگانه‌ی خودش را می‌گیرد.
Skill System	مهارت‌ها «به Agent می‌گویند چگونه کارها را انجام دهد» — بسته‌های متنی/مارک‌داونیِ رویه‌های تخصصی که Agent می‌تواند نصب و استفاده کند.
Plugin System	پلاگین‌ها ماژول‌های TypeScript هستند که درونِ فرایندِ Gateway اجرا می‌شوند و به Agent توانایی‌های تازه می‌دهند. تفاوت کلیدی: مهارت = دستورالعمل (متن)، پلاگین = قابلیت (کد).
ClawHub (رجیستری)	مخزنِ رسمیِ مهارت‌ها و پلاگین‌ها: «انتشار، نسخه‌بندی و جست‌وجوی مهارت‌های متنی» با جست‌وجوی برداری — و Agent می‌تواند خودش مهارتِ جدید را پیدا و اضافه کند.
Memory Model	حالتِ پایدارِ گفت‌وگو از طریق نشست/متن/حافظه. چند منبع گزارش می‌کنند حافظه به‌صورت فایل‌های Markdown روی ماشینِ خودتان ذخیره می‌شود (منطبق با فلسفه‌ی local-first). (این جزئیات از منابعِ ثانویه است.)
Heartbeat (زمان‌بندِ پیش‌دستانه)	یک دیمنِ زمان‌بندی‌شده که به Agent اجازه می‌دهد خودش «بیدار شود»، فایل‌ها/پایگاه‌داده را رصد کند و بدونِ اینکه از او خواسته شود اقدام کند. این همان مکانیزمِ پشتِ گزارش‌های خودکار است.
Multi-agent routing	کانال‌ها/حساب‌ها/فرستنده‌های ورودی می‌توانند به Agentها و فضاهای کاریِ ایزوله مسیریابی شوند.

قابلیت‌های درجه‌یکِ دیگر: ابزارهای داخلی (مرورگر، cron، نشست‌ها)، یک فضای کاریِ بصریِ زنده به نام Canvas، حالتِ صوتیِ Wake & Talk روی مک/موبایل، و اپ‌های همراه.

همه‌چیز چگونه کنار هم می‌نشیند

یک Gateway روی سخت‌افزارِ خودتان اجرا می‌شود. پلاگین‌های کانال پیام‌ها را از هر اپِ چتی به داخل می‌آورند؛ رانتایمِ Agent آن‌ها را با LLMِ انتخابیِ شما پردازش می‌کند و با ابزارها + مهارت‌ها/پلاگین‌ها (از ClawHub) کنش می‌کند؛ حافظه/نشست‌ها زمینه را نگه می‌دارند؛ مسیریابیِ چندعاملی زمینه‌ها را جدا می‌کند؛ و heartbeat اجازه می‌دهد پیش‌دستانه عمل کند.

مثال واقعی: یک Agent شخصیِ کامل

بیایید یک عاملِ شخصی بسازیم که تلگرام، تقویم، ایمیل، دسترسیِ فایل و اتوماسیون دارد.

# 1) نصب و راه‌اندازی
npm install -g openclaw@latest
openclaw onboard --install-daemon
openclaw dashboard        # پنل کنترل: http://127.0.0.1:18789/

# 2) اتصال تلگرام: از BotFather یک توکن بگیرید، بعد:
openclaw gateway
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>   # کد یک ساعت اعتبار دارد

پیکربندیِ کانال (JSON5):

{ channels: { telegram: { enabled: true, botToken: "YOUR_TOKEN",
    dmPolicy: "pairing", groups: { "*": { requireMention: true } } } } }

گردش‌کارِ کامل — «گزارشِ صبحگاهی»:

1. heartbeat ساعت ۷ صبح Agent را بیدار می‌کند (بدون اینکه شما چیزی بپرسید).
2. Agent از طریقِ پلاگین‌های متصل، ایمیل‌های شبِ گذشته و رویدادهای امروزِ تقویم را می‌خواند و یک پوشه‌ی رصدشده را چک می‌کند.
3. با استفاده از مهارتِ «گزارش صبحگاهی» (یک فایل مارک‌داون که به او می‌گوید چه چیزی و در چه قالبی خلاصه کند)، همه را جمع‌بندی می‌کند.
4. خلاصه را در حافظه‌ی محلیِ Markdown می‌نویسد تا فردا بداند چه چیزی را قبلاً گزارش کرده.
5. نتیجه را از طریقِ پلاگینِ کانالِ تلگرام برای شما DM می‌کند.

اگر مهارتی که لازم دارد نداشته باشد، می‌تواند در ClawHub جست‌وجو کند و آن را خودش نصب کند. این ترکیبِ «کانالِ چت + heartbeat + مهارت + حافظه‌ی محلی» همان چیزی است که OpenClaw را از یک چت‌باتِ ساده جدا می‌کند.

چه چیزی OpenClaw را متمایز می‌کند؟

• در برابر LangChain/CrewAI و امثالهم: آن‌ها کتابخانه‌هایی هستند که با آن‌ها اپ می‌سازید؛ OpenClaw یک محصولِ آماده‌ی محلی است که نصب می‌کنید و از همان اپ‌های چتِ موجود با آن حرف می‌زنید.
• در برابر دستیارهای ابری: محلی و خودمیزبان، مدل‌ناوابسته.
• نوآوری‌های خاص: Gatewayِ چندکاناله (۲۰+ پیام‌رسان در یک صفحه‌ی کنترل)، heartbeatِ پیش‌دستانه، تفکیکِ «مهارت = متن / پلاگین = کد» با کشفِ خودکار از ClawHub، حافظه‌ی محلیِ Markdown، و فضای کاریِ Canvas.

مقیاس: این پروژه رشدِ انفجاری داشته — از حدود ۲۴۷ هزار ستاره‌ی گیت‌هاب (مارس ۲۰۲۶) تا حدود ۳۸۰ هزار ستاره و ۸۰ هزار فورک در میانه‌ی ۲۰۲۶. (عدد دقیق دائماً تغییر می‌کند.) امروز یک بنیادِ غیرانتفاعیِ OpenClaw راهبری‌اش می‌کند.

بخش هفتم: بررسی کامل Hermes Agent

⚠️ اشتباه نگیرید: Hermes Agent با سریِ مدل‌های زبانیِ Hermes 2/3/4 (همان آزمایشگاه، Nous Research) یکی نیست. آن‌ها مدل‌اند؛ این یک عامل است و مدل‌ناوابسته است. مقاله‌ی arXivِ دیگری هم به نام «Hermes» درباره‌ی شبکه‌های سلولی وجود دارد که کاملاً بی‌ربط است.

Hermes Agent چیست؟

Hermes Agent یک عاملِ خودبهبود (self-improving)، متن‌باز (MIT)، به زبانِ Python، ساخته‌ی Nous Research است. شعارش: «عاملی که با تو رشد می‌کند.» هم یک ابزارِ CLI/TUI است و هم می‌تواند به‌عنوان یک عاملِ همیشه‌روشن روی ۲۰+ پیام‌رسان اجرا شود.

توصیفِ رسمیِ خودِ مخزن، دقیقاً نقطه‌ی تمایزش را می‌گوید: «تنها عاملی که یک حلقه‌ی یادگیریِ توکار دارد — از تجربه مهارت می‌سازد، آن‌ها را حین استفاده بهبود می‌دهد، خودش را به ماندگارکردنِ دانش هُل می‌دهد، در گفت‌وگوهای گذشته‌ی خودش جست‌وجو می‌کند، و مدلی عمیق‌تر از اینکه شما که هستید می‌سازد.»

در میانه‌ی ۲۰۲۶ حدود ۲۱۵ هزار ستاره دارد و Nous Research در حال جذبِ سرمایه با ارزش‌گذاریِ حدود ۱.۵ میلیارد دلار گزارش شده است. TechCrunch صراحتاً آن را رقیبِ OpenClaw معرفی می‌کند و می‌گوید Hermes «هفته‌ها پس از وایرال‌شدنِ یک عاملِ رقیب» منتشر شد.

معماری

مؤلفه	جزئیات
هسته‌ی ارکستراسیون	یک کلاسِ AIAgent که همه‌چیز را از «سرِهم‌کردنِ پرامپت تا اعزامِ ابزار و جابه‌جاییِ provider هنگام خطا» مدیریت می‌کند.
لایه‌ی مدل‌ناوابسته	چهار حالتِ API: chat_completions، codex_responses، anthropic_messages، bedrock_converse. با OpenAI، OpenRouter، پورتالِ Nous یا هر endpointِ دلخواه کار می‌کند.
رجیستریِ ابزار	ثبتِ خودکارِ ابزارها؛ ده‌ها ابزارِ داخلی.
بک‌اندهای اجرا	شش گزینه: local، Docker، SSH، Singularity، Modal، Daytona.
پایداریِ حالت	SQLite، شامل یک ایندکسِ FTS5 برای جست‌وجوی تمام‌متنِ تاریخچه‌ی نشست‌ها.
ایمنیِ لایه‌ای	بررسیِ دستوراتِ خطرناک با هوک‌های pre/post.

حلقه‌ی کاری (Agent Loop)

نکته‌ی جالب: حلقه‌ی Hermes رسماً «مشاهده ← برنامه‌ریزی ← کنش ← بازاندیشی» برچسب نخورده است. چرخه‌ی مستندِ هر نوبت این است:

1. تولیدِ task_id (در صورت نیاز)
2. افزودنِ پیامِ کاربر به تاریخچه
3. ساخت یا استفاده‌ی مجدد از پرامپتِ سیستمیِ کش‌شده
4. بررسیِ فشردگیِ متن — اگر بیش از ۵۰٪ پنجره پر شده باشد، فشرده‌سازی فعال می‌شود
5. ساختِ پیام‌های API از تاریخچه
6. تزریقِ لایه‌های پرامپتِ گذرا (مثل هشدارِ فشارِ متن یا بودجه)
7. اعمالِ نشانه‌های کشِ پرامپت
8. یک فراخوانیِ API قابلِ‌وقفه
9. تجزیه‌ی پاسخ: اگر فراخوانیِ ابزار بود ← اجرا (چند فراخوانی به‌صورت موازی با ThreadPool) ← نتیجه به تاریخچه ← بازگشت به گام ۵؛ اگر متن بود ← ذخیره و پایان.

بودجه‌ی تکرار: پیش‌فرض ۹۰ تکرار؛ در سقفِ ظرفیت، Agent متوقف می‌شود و خلاصه‌ای از کار برمی‌گرداند. و نکته‌ی مهم برای صداقتِ فنی: مستنداتِ رسمی صریحاً می‌گویند «هیچ گامِ بازاندیشیِ (reflection) صریحی در این حلقه مستند نشده است».

چرا به آن «عاملِ خودبهبود» می‌گویند؟

این مهم‌ترین بخشِ Hermes است و باید دقیق فهمیده شود. خودبهبودیِ آن انباشتِ حافظه‌ی رویه‌ای است، نه یادگیریِ تقویتیِ زنده. سه ستون دارد:

1. ساختِ خودکارِ مهارت: پس از یک کارِ پیچیده، Agent خودش یک فایلِ SKILL.mdِ قابل‌استفاده‌ی مجدد می‌نویسد.
2. حافظه‌ی خودگردان با «تلنگر» (nudge): پرامپتِ سیستمی به‌صورت دوره‌ای Agent را ترغیب می‌کند حقایقِ ماندگار را در فایل‌های حافظه بنویسد و مدلش از کاربر را به‌روز کند.
3. بازیابیِ بین‌نشستی: جست‌وجوی تمام‌متنِ FTS5 روی گفت‌وگوهای گذشته — و نتایج پیش از تزریق به متن، توسط LLM خلاصه می‌شوند.

⚠️ یک تنشِ واقعی که باید بگوییم: یک کالبدشکافیِ فنیِ مستقل استدلال می‌کند که Hermes در زمانِ اجرا از شکست‌های خودش بازاندیشی و یادگیری نمی‌کند؛ مسیرهای اجرا (trajectories) صرفاً به‌صورت JSONL برای تحلیلِ آفلاین ذخیره می‌شوند و «عاملِ در حالِ اجرا هرگز مسیرهای خودش را برای هدایتِ رفتارش مصرف نمی‌کند». هر فاین‌تیونِ RL هم دستی فراخوانی می‌شود. این با عبارتِ بازاریابیِ «مهارت‌ها حین استفاده خودبهبود می‌شوند» در تنش است. جمع‌بندیِ منصفانه: نوشتنِ مهارت پس از خطا واقعاً وجود دارد (مستند است)، اما ادعای قوی‌ترِ «خوداصلاحیِ پیوسته از روی مسیرها» تأییدنشده است.

سیستم مهارت (Skill)

ویژگی	جزئیات
قالب	فایل‌های SKILL.md (مارک‌داون با فرانت‌ماترِ YAML: نام، توضیح، نسخه) — داده‌اند، نه کد
محلِ ذخیره	~/.hermes/skills/
شرطِ ساختِ خودکار	«پس از تکمیلِ گردش‌کارهای پیچیده (۵+ فراخوانیِ ابزار)، هنگامِ مواجهه با خطا، یا هنگامِ کشفِ رویه‌های غیربدیهی»
مدیریت	create، patch، edit، delete
افشای تدریجی (بهینه‌سازی توکن)	سه سطح: L0 فقط متادیتا (~۳ هزار توکن) · L1 بارگذاریِ کاملِ مهارت در صورت نیاز · L2 فایل‌های مرجعِ خاص
استاندارد	سازگار با استانداردِ بازِ agentskills.io

حافظه و MCP

حافظه: ترکیبی از (۱) فایل‌های مارک‌داونِ «عکسِ منجمد» که در ابتدای نشست خوانده و در پرامپتِ سیستمی جاسازی می‌شوند (MEMORY.md برای حقایقِ ماندگار، USER.md برای پروفایلِ کاربر)، (۲) بازیابیِ بین‌نشستی با FTS5، و (۳) یک انتزاعِ MemoryProvider که به سیستم‌های بیرونی (مثل Honcho) وصل می‌شود. اصلِ طراحیِ مستند: «حافظه، حقایقِ کوچکِ ماندگار را ذخیره می‌کند و مهارت‌ها، رویه‌های طولانی را.»

MCP: Hermes یک کلاینتِ بومیِ MCP است. دو انتقال: stdio (زیرفرایندهای محلی) و HTTP (endpointهای راه‌دور با توکن یا OAuth 2.1). ابزارهای MCP با پیشوندی ضدِتصادم در همان رجیستری ثبت می‌شوند: mcp_<server>_<tool> — مثلاً mcp_github_create_issue. نصب: hermes mcp install <name>.

مثال: امروز انجام می‌دهد، دفعه‌ی بعد بهتر

این دقیقاً معنیِ عملیِ «خودبهبودی» است:

بارِ اول. می‌گویید: «پرداخت‌های ماهِ گذشته‌ی Stripe را بیاور و یک خلاصه‌ی CSV بساز.» Agent نقشه می‌کشد، سرورِ MCPِ Stripe را وصل می‌کند (mcp_stripe_*)، صفحه‌بندیِ API را طی می‌کند، به خطای محدودیتِ نرخ می‌خورد و با تلاشِ مجدد ردش می‌کند، داده را بازآرایی و CSV را می‌نویسد. این یک گردش‌کارِ پیچیده، خطاخورده و بیش از ۵ فراخوانیِ ابزار بود — دقیقاً شرطِ ساختِ مهارت. Agent فایلِ ~/.hermes/skills/finance/stripe-payout-summary/SKILL.md را می‌نویسد: کدام ابزارهای MCP، الگوی صفحه‌بندی، تلاشِ مجدد در محدودیتِ نرخ، و شِمای CSV.

ماهِ بعد. همان درخواست را می‌دهید. در سطحِ L0 نام و توضیحِ آن مهارت از قبل در متنِ Agent هست؛ می‌فهمد یک «دستورپختِ آزموده» دارد. با skill_view رویه‌ی کامل را بارگذاری می‌کند، آزمون‌وخطا و آن خطای محدودیتِ نرخ را دور می‌زند، و کار را با تکرارهای بسیار کمتری تمام می‌کند. اگر راهِ بهتری کشف کند، مهارت را patch می‌کند. هم‌زمان در MEMORY.md نوشته: «این کاربر خلاصه‌ی پرداخت را به‌صورت CSV می‌خواهد.»

نتیجه: فراخوانیِ کمتر، خطای تکراریِ کمتر، سرعتِ بیشتر. اما — همان‌طور که گفتیم — این بازاستفاده از حافظه‌ی رویه‌ای است، نه بازآموزیِ زنده‌ی مدل.

بخش هشتم: مقایسه‌ی عمیق OpenClaw و Hermes Agent

سوالِ درست «کدام بهتر است؟» نیست؛ سوالِ درست این است: هرکدام برای حلِ چه مسئله‌ای ساخته شده‌اند؟

معیار	OpenClaw	Hermes Agent
فلسفه‌ی طراحی	حاکمیتِ کاربر و محلی‌محوری؛ «دستیارِ شخصیِ همیشه‌در‌دسترس»	یادگیری و رشد؛ «عاملی که با تو بهتر می‌شود»
معماری	Gateway + پلاگین‌های کانال + رانتایم (TypeScript)	کلاسِ AIAgent + رجیستریِ ابزار + بک‌اندهای اجرا (Python)
حلقه‌ی Agent	رویداد-محور + heartbeatِ پیش‌دستانه (خودش بیدار می‌شود)	حلقه‌ی نوبتیِ ابزار با بودجه‌ی ۹۰ تکرار و فشرده‌سازیِ متن
حافظه	نشست‌ها + فایل‌های Markdownِ محلی	MEMORY.md/USER.md + SQLite FTS5 برای بازیابیِ بین‌نشستی
سیستم مهارت	مهارت = متن؛ پلاگین = کد؛ رجیستریِ ClawHub با کشفِ خودکار	SKILL.md + افشای تدریجی (L0/L1/L2) + استانداردِ agentskills.io
توانِ یادگیری	مهارت‌ها را نصب می‌کند (از رجیستری)	مهارت‌ها را خودش می‌سازد (از تجربه) — ستونِ اصلیِ محصول
اجرای ابزار	ابزارهای داخلی + پلاگین‌های TypeScript در همان فرایند	رجیستریِ ابزار + ۶ بک‌اند (local/Docker/SSH/Modal/...) + MCPِ بومی
پیام‌رسانی	⭐ نقطه‌ی قوتِ اصلی: ۲۰+ کانال در یک Gateway	دارد (۲۰+ پلتفرم) اما تمرکزِ اصلی روی CLI/TUI است
توسعه‌پذیری	پلاگین (کد) + مهارت (متن) + ClawHub	ابزار + مهارت + MCP (اکوسیستمِ بازِ بیرونی)
امنیت	مدلِ sandbox برای گروه‌ها/کانال‌ها، جداسازیِ نشست	بررسیِ دستورِ خطرناک با هوک، اجرا در Docker/sandbox
تجربه‌ی توسعه‌دهنده	نصب و «حرف‌زدن از تلگرام» — کاربرمحور	hermes در ترمینال — توسعه‌دهنده‌محور
مجوز / زبان	MIT · TypeScript	MIT · Python
مناسب برای	یک دستیارِ شخصیِ همیشه‌روشن که در زندگیِ دیجیتالِ شما (چت، ایمیل، تقویم، فایل) زندگی می‌کند	یک همکارِ فنیِ ترمینال که کارهای تکرارشونده را یاد می‌گیرد و بهتر می‌کند

جمع‌بندیِ منصفانه: OpenClaw مسئله‌ی «چطور یک دستیارِ واقعی داشته باشم که همه‌جا با من باشد و داده‌ام مالِ خودم بماند» را حل می‌کند — نقطه‌ی قوتش حضورِ چندکاناله و پیش‌دستانه است. Hermes مسئله‌ی «چطور عاملی داشته باشم که هر بار کارِ تکراری را بهتر انجام دهد» را حل می‌کند — نقطه‌ی قوتش حلقه‌ی یادگیریِ مهارت است. این دو حتی مکمل‌اند: می‌شود Hermes را پشتِ یک Gateway چندکاناله تصور کرد.

بخش نهم: مقایسه با سایر فریم‌ورک‌های Agent

OpenClaw و Hermes «محصول» هستند. اما اکوسیستمِ بزرگ‌تری از فریم‌ورک‌ها وجود دارد که با آن‌ها Agent می‌سازید:

فریم‌ورک	سازنده	پارادایم	مناسب برای
LangGraph	LangChain	ماشینِ حالت (گره، یال، حالتِ مشترک)	تولیدِ صنعتی با کنترلِ دقیقِ حالت، پایداری و دخالتِ انسان (HITL)
AutoGen	Microsoft	گفت‌وگوی چندعاملی (group chat)	سناریوهای پژوهشی و همکاریِ عامل‌ها از طریق مکالمه
CrewAI	CrewAI	نقش‌محور (تیمی از عامل‌های نقش‌دار با وظایف)	راه‌اندازیِ سریعِ تیم‌های چندعاملی (~۳۰-۶۰ خط کد)
OpenAI Agents SDK	OpenAI	Agent + handoff + guardrail	یک Agentِ ساده با یکی‌دو ابزار — سریع‌ترین مسیر
Claude Agent SDK	Anthropic	ابزارِ بومی + حافظه	استقرارِ تولیدی با ابزار و حافظه‌ی بومی
Devin	Cognition	محصولِ بسته (نه فریم‌ورک)	«مهندسِ نرم‌افزارِ خودمختار» — یک محصول، نه کتابخانه
BabyAGI / AutoGPT	جامعه (۲۰۲۳)	حلقه‌ی فهرستِ وظایف	پیشگامانِ تاریخی؛ امروز بیشتر آموزشی/آزمایشی
SuperAGI	SuperAGI	پلتفرمِ متن‌بازِ Agent	اجرای همزمانِ چند Agent با رابطِ گرافیکی

روندِ ۲۰۲۶: فریم‌ورک‌ها روی انتزاع‌های مشترک هم‌گرا شده‌اند و تمایزشان بیشتر در عمقِ اکوسیستم است تا در ایده‌ی بنیادی. یک قاعده‌ی سرانگشتیِ عملی: برای یک Agent با چند ابزار، SDKهای رسمی (OpenAI/Anthropic) سریع‌ترین راه‌اند؛ برای کنترلِ دقیقِ حالت و تولید، LangGraph؛ برای تیم‌های نقش‌محور، CrewAI.

⚠️ توجه: BabyAGI و AutoGPT در سال ۲۰۲۳ سروصدای زیادی کردند اما به‌سرعت محدودیت‌هایشان آشکار شد (حلقه‌های بی‌پایان، انباشتِ خطا، هزینه). آن‌ها بیشتر ارزشِ تاریخی دارند تا کاربردِ تولیدی — و درسی که دادند، همان چیزی است که در بخشِ امنیت و آینده به آن برمی‌گردیم.

بخش دهم: سیستم‌های چندعاملی (Multi-Agent Systems)

تا اینجا از «یک Agent» حرف زدیم. اما گاهی چند Agent تخصصی کنار هم می‌نشینند. تفاوت‌شان:

	تک‌عاملی (Single-Agent)	چندعاملی (Multi-Agent)
مزیت	ساده، ارزان، زمینه‌ی یکپارچه، بدون سوءتفاهمِ بین‌عاملی	موازی‌سازی، تخصص‌گرایی، پنجره‌های متنِ جدا برای کارهای بزرگ
عیب	یک پنجره‌ی متن برای همه‌چیز؛ در کارهای خیلی بزرگ اشباع می‌شود	هزینه‌ی توکنِ چند برابر، هماهنگیِ شکننده، تصمیم‌های متناقض

الگوهای ارکستراسیون

• ارکستریتور-کارگر (Orchestrator-Worker): یک عاملِ رهبر هدف را تجزیه می‌کند، به زیرعامل‌ها می‌سپارد و نتایج را ادغام می‌کند. (معماریِ سیستمِ پژوهشیِ چندعاملیِ Anthropic.)
• سلسله‌مراتبی: عامل‌ها در چند لایه، هر لایه زیرمجموعه‌ی بالایی را مدیریت می‌کند.
• خطِ لوله‌ی ترتیبی (Pipeline): خروجیِ هر عامل ورودیِ عاملِ بعدی است.
• گفت‌وگو/مناظره (Group Chat / Debate): عامل‌ها با هم بحث می‌کنند تا به توافق برسند (رویکردِ AutoGen، MetaGPT، ChatDev).

مثال کاربردی: یک تیم چهارعامله

یک سیستمِ توسعه‌ی نرم‌افزار با چهار عامل را در نظر بگیرید:

1. عاملِ برنامه‌ریزی: نیازمندی را می‌گیرد و به وظایفِ کوچک تجزیه می‌کند.
2. عاملِ تحقیق: مستندات و APIهای لازم را جمع می‌کند (پنجره‌ی متنِ جدا، موازی).
3. عاملِ کدنویسی: بر اساسِ نقشه و تحقیق، کد را می‌نویسد.
4. عاملِ بازبینی: کد را تست و بازبینی می‌کند و ایرادها را برمی‌گرداند.

ارکستریتور این چرخه را هماهنگ می‌کند: برنامه‌ریزی → (تحقیق موازی) → کدنویسی → بازبینی → و در صورتِ ایراد، بازگشت به کدنویسی. اما اینجا به مهم‌ترین بحثِ باز می‌رسیم.

⚠️ بحثِ واقعی: آیا چندعاملی واقعاً بهتر است؟

این یکی از داغ‌ترین مناظره‌های ۲۰۲۵-۲۰۲۶ است و دو طرفِ معتبر دارد:

• طرفِ موافق (Anthropic): سیستمِ پژوهشیِ چندعاملیِ آن‌ها (رهبر Opus + زیرعامل‌های Sonnet) حدود ۹۰.۲٪ بهتر از یک عاملِ منفرد عمل کرد. اما نکته‌ی مهم: این سیستم حدود ۱۵ برابر توکنِ بیشتر از یک چت مصرف می‌کند، و خودِ Anthropic می‌گوید مصرفِ توکن به‌تنهایی ۸۰٪ تفاوتِ عملکرد را توضیح می‌دهد. یعنی چندعاملی زمانی صرف می‌کند که ارزشِ کار به‌قدری بالا باشد که هزینه‌ی توکن را توجیه کند (تحقیقاتِ حقوقی، هوشِ رقابتی، مرورِ منابعِ زیست‌پزشکی).
• طرفِ مخالف (Cognition، «چندعاملی نسازید»): استدلال می‌کند که فن‌کردنِ کار به زیرعامل‌های موازی ذاتاً شکننده است؛ چون هر زیرعامل روی «دیدِ جزئی» عمل می‌کند و تصمیم‌های ضمنیِ متناقض می‌گیرد. مثالِ معروفشان: عاملی که یک کلونِ Flappy Bird می‌سازد و کار را بین دو زیرعامل تقسیم می‌کند؛ یکی پس‌زمینه‌ای به سبکِ Super Mario می‌سازد و دیگری پرنده‌ای واقع‌گرا — و هماهنگ‌کننده با دو قطعه‌ی ناسازگار می‌ماند. آن‌ها می‌گویند «ناهم‌ترازیِ بین‌عاملی، ۳۲.۳٪ از شکست‌ها را می‌سازد» — شکست‌هایی که در سیستمِ تک‌عاملی اصلاً رخ نمی‌دهند. راه‌حلِ آن‌ها: زمینه را کامل به‌اشتراک بگذارید و کلِ ردِ عامل را منتقل کنید، نه فقط پیام‌ها را.

جمع‌بندی: چندعاملی «جادو» نیست. برای کارهای قابل‌موازی‌سازی با ارزشِ بالا (که هزینه‌ی توکن را توجیه می‌کند) عالی است؛ اما برای بیشترِ کارها، یک عاملِ منفردِ خوش‌ساخت با زمینه‌ی کامل هم ارزان‌تر است و هم قابل‌اعتمادتر.

بخش یازدهم: امنیت AI Agentها

اینجا جدی‌ترین بخشِ مقاله است. لحظه‌ای که یک LLM از «حرف‌زدن» به «کنش‌کردن» می‌رسد، سطحِ حمله به‌طرزِ انفجاری بزرگ می‌شود. در دسامبر ۲۰۲۵، OWASP اولین «Top 10 برای اپلیکیشن‌های عامل‌گونه» را منتشر کرد — نخستین چارچوبِ داوری‌شده که مخصوصِ امنیتِ عامل‌های خودمختار است (با مشارکتِ ۱۰۰+ متخصص و تأییدِ NIST، مایکروسافت و NVIDIA).

تهدیدها

تهدید	چگونه کار می‌کند
تزریق پرامپت (Prompt Injection)	مهاجم دستوراتِ مخرب را در متنی که Agent می‌خواند پنهان می‌کند. مستقیم (در ورودی) یا غیرمستقیم (در یک صفحه‌ی وب، ایمیل یا سندی که Agent بازیابی می‌کند). Simon Willison — که خودِ اصطلاح را ساخت — آن را به تزریقِ SQL تشبیه می‌کند: مخلوط‌شدنِ محتوای معتمد و نامعتمد در یک زمینه.
سوءاستفاده از ابزار (Tool Abuse)	مهاجم Agent را فریب می‌دهد تا ابزارهای مجازش را برای کارِ ناخواسته به کار برد — یک دستورِ مخرب می‌تواند فایل حذف کند، ایمیلِ غیرمجاز بفرستد یا خسارتِ مالی بزند. (T2 در OWASP.)
مسموم‌سازیِ حافظه (Memory Poisoning)	مهاجم داده‌ی مخرب را در حافظه‌ی بلندمدت/RAG تزریق می‌کند. برخلافِ تزریقِ پرامپت، این ماندگار است — Agent مدت‌ها پس از حمله همچنان نادرست رفتار می‌کند. (T1 در OWASP.)
مسموم‌سازیِ مهارت/پلاگین (Supply Chain)	یک مهارت یا پلاگینِ آلوده از رجیستری نصب می‌شود و کدِ مخرب یا دستورالعملِ بد را وارد می‌کند.
نشتِ اعتبارنامه (Credential Leakage)	Agent به کلیدها و توکن‌ها دسترسی دارد؛ با یک تزریقِ موفق می‌تواند آن‌ها را به بیرون بفرستد.
خسارتِ خودمختار (Autonomous Damage)	Agent با «عاملیتِ بیش‌ازحد» کنشِ مخرب و برگشت‌ناپذیر انجام می‌دهد (حذفِ داده، تراکنشِ مالی).
دسترسیِ بیش‌ازحد (Over-Privilege)	به Agent مجوزهای بیشتر از نیاز داده می‌شود؛ یک خطای کوچک به فاجعه تبدیل می‌شود.

«مثلث مرگبار» (The Lethal Trifecta)

مفهومی که Simon Willison در ژوئن ۲۰۲۵ مطرح کرد و به مهم‌ترین قاعده‌ی امنیتیِ عامل‌ها تبدیل شد. اگر یک Agent هم‌زمان این سه ویژگی را داشته باشد، در معرضِ سرقتِ داده است:

1. دسترسی به داده‌ی خصوصیِ شما،
2. مواجهه با محتوای نامعتمد (هر متنی که مهاجم می‌تواند کنترلش کند)،
3. توانِ ارتباطِ بیرونی (هر راهی برای فرستادنِ داده به بیرون).

اگر هر سه با هم باشند، مهاجم می‌تواند Agent را فریب دهد تا داده‌ی خصوصی را بخواند و برای او بفرستد. Willison هشدار می‌دهد که مشکلِ MCP دقیقاً همین است: کاربران را تشویق می‌کند ابزارها را از منابعِ مختلف قاطیِ هم کنند — و کافی است یکی داده‌ی خصوصی بدهد و دیگری یک درخواستِ HTTP بزند تا مثلث کامل شود.

راهکارها

راهکار	چه می‌کند
جعبه‌ی شنی و ایزولاسیون (Sandbox)	اجرای کنش‌ها در محیطِ محصور (کانتینر) تا خسارت مهار شود
تأییدِ انسانی (Human-in-the-loop)	کنش‌های حساس (ارسال ایمیل، حذف، پرداخت) پیش از اجرا منتظرِ تأییدِ شما بمانند
کمترین دسترسی (Least Privilege)	به هر Agent فقط دقیقاً مجوزهای لازم را بدهید، نه بیشتر
لاگِ ممیزی (Audit Log)	ثبتِ هر کنش برای ردیابی و بازبینیِ پس از حادثه
محدودسازیِ قابلیت	«شکستنِ مثلث»: اگر Agent داده‌ی خصوصی می‌بیند، اجازه‌ی ارتباطِ بیرونیِ آزاد ندهید
فیلترِ ورودی/خروجی و Guardrail	پالایشِ محتوای نامعتمد و بازبینیِ خروجی پیش از کنش

قاعده‌ی طلایی: هیچ‌وقت هر سه ضلعِ مثلثِ مرگبار را به یک Agent با هم ندهید. اگر مجبورید، حداقل ضلعِ «ارتباطِ بیرونی» را با تأییدِ انسانی مهار کنید.

بخش دوازدهم: آینده‌ی AI Agentها

در ۱ تا ۳ سالِ آینده، عامل‌ها کجا می‌روند؟ چند مسیرِ محتمل:

• عاملِ شخصی (Personal AI Agent): دقیقاً چیزی که OpenClaw و Hermes پیش‌درآمدش هستند — یک دستیارِ همیشه‌روشن که ایمیل، تقویم، فایل و اپ‌های شما را می‌شناسد و کارها را پیش می‌برد.
• «کارمندِ هوش مصنوعی» (AI Employee): عامل‌هایی که نقشِ یک همکارِ تمام‌وقت را در گردش‌کارهای سازمانی بازی می‌کنند.
• توسعه‌دهنده‌ی خودمختار: در مسیرِ Devin — عاملی که یک تیکت را می‌گیرد و PR تحویل می‌دهد.
• دستیارِ پژوهش: عامل‌هایی که ساعت‌ها منابع را می‌خوانند، تحلیل می‌کنند و گزارش می‌سازند.
• «سیستم‌عاملِ هوش مصنوعی» (AI OS): ایده‌ای که در آن Agent لایه‌ی اصلیِ تعامل با کامپیوتر می‌شود، نه اپ‌ها.

⚠️ وزنه‌ی تعادل: مسئله‌ی قابلیت‌اعتماد

اما باید هیجان را با واقعیت متعادل کرد. مهم‌ترین داده‌ی ضدِهایپ از METR می‌آید که «افقِ زمانیِ» عامل‌ها را می‌سنجد — یعنی طولِ کاری که یک عامل با نرخِ موفقیتِ مشخص می‌تواند تمام کند:

• METR تخمین زده افقِ زمانیِ عامل‌ها روی کارهای نرم‌افزاری تقریباً هر ۷ ماه دو برابر می‌شود (و در ۲۰۲۴-۲۰۲۵ حتی هر ۴ ماه). اگر این روند ادامه یابد، عامل‌ها شاید حدود ۲۰۲۷ به کارهای یک‌ماهه برسند.
• اما نکته‌ی حیاتی: نرخِ موفقیت با طولِ کار افت می‌کند. عامل‌ها در کارهای کوتاه عالی‌اند، اما هرچه کار طولانی‌تر و چندمرحله‌ای‌تر شود، احتمالِ شکست بالا می‌رود — به‌خاطرِ همان انباشتِ خطا که Anthropic هم هشدارش را داد. یک خطای کوچک در گام دهم، کلِ کار را خراب می‌کند.

پس تصویرِ واقع‌بینانه این است: عامل‌ها با سرعتی چشمگیر بهتر می‌شوند، اما «قابلیت‌اعتماد در افق‌های بلند» هنوز مرزِ حل‌نشده‌ی این حوزه است. آینده‌ای که در آن یک Agent بدونِ نظارت یک پروژه‌ی چندروزه را بی‌نقص پیش ببرد، هنوز نیامده — و شاید بزرگ‌ترین چالشِ فنیِ سه سالِ آینده همین باشد.

بخش سیزدهم: ساخت یک Agent از صفر

حالا همه‌ی تکه‌ها را کنار هم می‌گذاریم. یک معماریِ مرجع برای ساختِ یک Agent شاملِ این اجزاست:

مؤلفه	مسئولیت
LLM	مغز؛ استدلال و تصمیمِ گامِ بعد. ترجیحاً مدل‌ناوابسته (پشتِ یک واسط)
Agent Controller	خودِ حلقه: مشاهده، برنامه‌ریزی، فراخوانی ابزار، ارزیابی، تکرار تا هدف
Memory Database	حالتِ نشست‌ها و حقایقِ ماندگار (مثلاً SQLite)
Vector Database	بازیابیِ معناییِ حافظه‌ی بلندمدت (امبدینگ + جست‌وجوی شباهت)
Tool Registry	فهرستِ ابزارها با شِمای‌شان؛ نقطه‌ی وصلِ MCP
Scheduler	اجرای زمان‌بندی‌شده/پیش‌دستانه (مثلِ heartbeatِ OpenClaw)
Security Layer	sandbox، کمترین‌دسترسی، تأییدِ انسانی، لاگِ ممیزی — لایه‌ای که همه‌چیز را دربرمی‌گیرد

معادلِ Mermaid برای بازسازیِ این معماری:

graph TD
    User[User / Channel] --> Ctrl[Agent Controller]
    Ctrl <--> LLM[LLM: the brain]
    Ctrl --> TR[Tool Registry]
    TR --> MCP[[MCP servers]]
    Ctrl <--> MemDB[(Memory DB: sessions, facts)]
    Ctrl <--> VecDB[(Vector DB: semantic recall)]
    Sched[Scheduler / Heartbeat] --> Ctrl
    subgraph SEC[Security Layer]
      Ctrl
      TR
    end
    SEC -. sandbox, least-privilege, approval, audit .-> Ctrl

حداقلی‌ترین حلقه‌ی کنترلر، در شبه‌کد:

state = load_memory(user)                 # حافظه‌ی بلندمدت
messages = build_prompt(goal, state)
for step in range(MAX_STEPS):             # بودجه‌ی تکرار (مثلاً 90)
    reply = llm(messages, tools=registry) # مدل: فکر یا فراخوانیِ ابزار
    if reply.tool_calls:
        for call in reply.tool_calls:
            check_permission(call)         # لایه‌ی امنیت
            result = runtime.execute(call)  # اجرای واقعی در sandbox
            audit_log(call, result)
            messages.append(result)
    else:
        save_memory(user, reply)           # یادگیری/ماندگاری
        return reply                        # هدف محقق شد

همین اسکلتِ ساده، هسته‌ی مشترکِ OpenClaw، Hermes و تقریباً هر Agent دیگری است؛ تفاوتِ محصولات در این است که هر کدام کدام قطعه را قوی‌تر کرده‌اند (OpenClaw کانال‌ها و heartbeat را، Hermes حلقه‌ی مهارت و حافظه را).

جمع‌بندی

سفرِ از LLM به Agent، سفرِ از «حرف» به «کار» است. یک LLM یک پیش‌بینِ توکنِ بی‌حالت و بی‌ابزار است؛ یک Agent همان مدل را با حافظه، ابزار و یک حلقه‌ی خودگردان به چیزی تبدیل می‌کند که می‌تواند مشاهده کند، نقشه بکشد، عمل کند، ارزیابی کند و یاد بگیرد. پروژه‌هایی مثلِ OpenClaw (دستیارِ شخصیِ چندکاناله و محلی‌محور) و Hermes Agent (عاملِ خودبهبودِ ترمینال) دو تجسمِ واقعی و متن‌بازِ این ایده‌اند که هر کدام برای مسئله‌ی متفاوتی ساخته شده‌اند.

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

منابع علمی

مقالات و مستنداتِ کلیدیِ استفاده‌شده در این تحقیق:

• Anthropic — Building Effective Agents (۲۰۲۴): anthropic.com
• Lilian Weng — LLM Powered Autonomous Agents (۲۰۲۳): lilianweng.github.io
• ReAct — arXiv:2210.03629 · Chain-of-Thought — arXiv:2201.11903 · Reflexion — arXiv:2303.11366
• Tree of Thoughts — arXiv:2305.10601 · Plan-and-Solve — arXiv:2305.04091 · LLM+P — arXiv:2304.11477
• RAG — arXiv:2005.11401 · MemGPT/Letta — arXiv:2310.08560 · Generative Agents — arXiv:2304.03442 · A-MEM — arXiv:2502.12110 · CoALA — arXiv:2309.02427
• Toolformer — arXiv:2302.04761 · Voyager — arXiv:2305.16291
• MCP — Anthropic · modelcontextprotocol.io
• OpenClaw — GitHub · مستندات · Hermes Agent — GitHub · مستندات
• Anthropic — Multi-Agent Research System: anthropic.com · Cognition — Don't Build Multi-Agents: cognition.ai
• OWASP Top 10 for Agentic Applications (۲۰۲۵): genai.owasp.org · Simon Willison — The Lethal Trifecta: simonwillison.net
• METR — Measuring AI Ability to Complete Long Tasks: metr.org

یادداشتِ روش: اطلاعاتِ این مقاله از چند منبع مستقل بررسی و متقاطع (cross-check) شده است. جزئیاتِ مربوط به پروژه‌های نو (OpenClaw، Hermes) و آمارهای متغیر (تعداد ستاره‌ها، ارقامِ بازار) در زمان نگارش درست بوده‌اند اما ممکن است تغییر کنند؛ ادعاهای تأییدنشده یا مورد اختلاف در متن علامت‌گذاری شده‌اند.