معماری ایجنتیک و هوش مصنوعی۱۸ دقیقه مطالعه عمیق تعاملیپاییز ۱۴۰۵مهدی و ایجنت agy

کالبدشکافی ایجنت‌های هوش مصنوعی: از مغز آلزایمری (LLM) تا مهندسی هارنس (Harness)

چرا مدل‌های زبانی ذاتاً آلزایمر دارند؟ چطور با پایتون و JSON Schema به آن‌ها دست‌وپا می‌دهیم؟ پروتکل MCP چیست، چرا مثال ۱۰ سیب و ۱۰ کارگر فلسفه چندایجنتی را اثبات می‌کند و فریم‌ورک‌های دنیا چطور این موجود پرحرف را با هارنس مهار می‌کنند؟

کاراکتر مکعبی در هارنس مهار شده
Agent Harness

استعاره ملموس مهندسی هارنس: بستن زین و مهار به این موجود مکعبی پرحرف! 🎯

بخش اولمبانی محاسباتی

کالبدشکافی LLM؛ موجودِ نابغه اما آلزایمری!

یک تابع ریاضی احتمالاتی، بدون حالت و فاقد حافظه پیوسته

مدل زبانی بزرگ (LLM) در هسته مرکزی خود، هیچ شباهتی به یک موجود هوشیار با حافظه پیوسته ندارد؛ بلکه در واقع چیزی جز یک موجودِ آلزایمری و یک تابع ریاضی بدون حالت (Stateless) و احتمالاتی نیست که تعدادی توکن را به عنوان ورودی می‌گیرد و بر اساس محاسبات آماری، توکن‌های بعدی را حدس می‌زند.

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

اما مکانیزم بقا و فعالیت او لحظه‌ای است: صرفاً با هر بار فراخوانی (API Call)، برای چند ثانیه بیدار می‌شود، نسبت به توکن‌های ورودی، توکن‌های خروجی را می‌سازد و آن‌قدر به تولید کلمه ادامه می‌دهد تا یا به توکنِ پایانِ جمله برسد و یا به سقف محدودیت توکن خروجی (max_tokens) که برایش ست شده برخورد کند؛ و بلافاصله بعد از آن برای همیشه خاموش می‌شود—طوری که انگار اصلاً هیچ‌وقت روشن نبوده است!

۱. سیستم‌پرامپت (System Prompt) و فایل‌های هویتی؛ نسخه بیداری

از آنجایی که این مدل در هر بار اجرا با ذهنی کاملاً پاک‌شده بیدار می‌شود، اولین ورودی مدل حیاتی‌ترین بخش ماجراست. این ورودی اول همان چیزی است که به مدل شخصیت، چارچوب، لحن و جهت می‌دهد و در ادبیات فنی به آن سیستم‌پرامپت (System Prompt) گفته می‌شود.

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

  • فایل‌های نقش و قوانین (ROLE.md یا SOUL.md یا RULES.md): به مدل می‌گویند اسمش چیست، چه شخصیتی دارد و چه قوانین و خط قرمزهایی برای گفتگو وجود دارد.
  • فایل‌های مهارت (SKILL.md): دستورالعمل‌های تخصصی و روش انجام کارهای خاص را به مدل یاد می‌دهند.
  • فایل‌های حافظه (MEMORY.md): خلاصه‌ای از اتفاقات و دانسته‌های مهم قبلی را نگه می‌دارند.

۲. ترفندِ تاریخچه چت و برخورد به دیوارِ کانتکست

پس در یک چت‌بات معمولی چطور حس می‌کنیم مدل حرف‌های دو دقیقه پیش ما را یادش هست؟ برای حل مشکل حافظه در چت، ما یک کلکِ مهندسی می‌زنیم: در هر نوبت، تمام ورودی‌ها و خروجی‌های قبلیِ گفتگو را برمی‌داریم و همراه با پیام جدیدِ کاربر، یک‌جا دوباره به مدل می‌فرستیم! وقتی مدل از خواب بیدار می‌شود، در کسری از ثانیه کلِ طومارِ مکالمه را از اول می‌خواند تا اول بفهمد بحث سر چه بوده، قبلاً چه جوابی داده، الان در کجای مکالمه ایستاده است، و بعد جوابِ بعدی را تولید کند.

این قضیه در هر پیام تکرار می‌شود و ادامه پیدا می‌کند؛ اما یک جای کار می‌لنگد: با طولانی شدن چت، این بستهٔ ورودی مدام حجیم‌تر می‌شود تا جایی که به محدودیت سقف ورودی مدل (Context Window Limit) می‌خورد. حتی خیلی قبل‌تر از اینکه ظرفِ ورودی کاملاً پر شود، شلوغیِ بیش از حدِ متن باعث می‌شود تمرکزِ ریاضیِ مدل به هم بریزد، جزئیات وسطِ مکالمه را گم کند (پدیده‌ای معروف به Context Rot یا پوسیدگی کانتکست) و دقت خروجی به شدت افت کند.

آزمایشگاه تعاملی • شبیه‌سازی زنده این بخش
شبیه‌ساز ۱: هسته بدون حالت LLM و سقف کانتکستمعماری محاسباتی
خاموش (RAM = 0)RAM: 0 Tokens
بخش دومتولد دست و پا

متولد شدن ایجنت‌ها (Function Calling)؛ دست و پا دادن به مغزِ دربند!

پیوند مدل زبانی، کاتالوگ JSON Schema و محیط اجرایی پایتون

تا اینجای کار، ما یک موجودِ علامه و سخنگو داریم که هیچ کاری در دنیای واقعی از دستش برنمی‌آید و فقط می‌تواند متن تولید کند. اما از کنار هم قرار دادن پایتون (Python) و مدل زبانی (LLM)، می‌توان کارهای فوق‌العاده جالبی انجام داد که سرآغازِ تولد ایجنت‌ها (Agents) است.

مکانیزم کار از این قرار است: ما در کدهای خودمان، یک تابع یا مجموعه‌ای از توابع پایتونی می‌سازیم که هر کدام برای انجام یک تسک مشخص طراحی شده‌اند؛ فرضاً تابعی که به API یک شرکت یا صرافی وصل می‌شود، قیمت لحظه‌ای را می‌گیرد، یا اطلاعاتی را در دیتابیس ثبت می‌کند.

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

اجزای کلیدی کاتالوگ ابزار در فرمت JSON Schema

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

  • اسم تابع (name)
  • هدف و توضیحات دقیق تابع (description - اینکه تابع چه کاری انجام می‌دهد و کِی باید از آن استفاده شود)
  • ورودی‌ها و نوع هر ورودی (parameters & types - مثلاً رشته، عدد صحیح یا بولین)
  • فرمت خروجی مورد انتظار

لحظه جادویی: تولید خروجی ابزار به جای بافتن متن

حالا اتفاق جادویی رخ می‌دهد: وقتی کاربر درخواستی می‌دهد، اگر آن مدلِ زبانیِ آلزایمری نسبت به بینش و تحلیلی که در آن لحظه دارد حس کند که برای جواب دادن به این مرحله، به جای بافتنِ متن معمولی نیاز است که یکی از آن توابع به کار بیفتد، دیگر جواب متنی تولید نمی‌کند! بلکه در result خروجی JSON که برای سرورِ پایتونی ما برمی‌گرداند، بخش ویژه‌ای به نام tool_calls را پر می‌کند. در این بخش دقیقاً مشخص شده است که کدام تابع و با چه ورودی‌هایی (Arguments) باید کار کند.

در این لحظه، سرور پایتونی ما آن دستور JSON را می‌گیرد، تابعِ پایتونیِ مربوطه را با همان ورودی‌هایی که مدل زبانی استخراج کرده است فراخوانی و اجرا می‌کند. اینجاست که به یک مدلِ صرفاً متنی، «دست و پا» داده می‌شود!

آزمایشگاه تعاملی • شبیه‌سازی زنده این بخش
شبیه‌ساز ۲: پل ارتباطی ۳ بخشی پرامپت، JSON Schema و پایتوندست و پا دادن به مدل
۱. درخواست ورودی کاربرPrompt
کاربر: «وضعیت سفارش شماره ۸۹۲۰ رو از API شرکت چک کن ببین کجاست.»

مدل متوجه می‌شود اطلاعات سفارش در دیتابیس داخلی او نیست و باید از کاتالوگ ابزارها کمک بگیرد.

۲. هسته LLM + کاتالوگ ابزارJSON Schema
کاتالوگ ابزار ضمیمه شده به پرامپت:
{ "name": "get_company_order_status", "description": "استعلام وضعیت سفارش از دیتابیس انبار شرکت", "parameters": { "type": "object", "properties": { "order_id": { "type": "integer", "description": "شناسه یکتای سفارش خریدار" } }, "required": ["order_id"] } }
⚡ استخراج بسته فراخوانی ابزار (tool_calls):
{ "tool_calls": [ { "name": "get_company_order_status", "arguments": { "order_id": 8920 } } ] }
۳. محیط اجرایی پایتونRuntime
کد تابع پایتونی در سرور:
def get_company_order_status(order_id: int) -> dict: # فراخوانی وب‌سرویس و واکشی اطلاعات record = database.query(order_id=order_id) return { "order_id": order_id, "status": "Shipped", "carrier": "ExpressPost", "eta": "فردا ساعت ۱۴:۰۰" }
✓ نتیجه خروجی اجرای تابع پایتون:
{
  "order_id": 8920,
  "status": "Shipped",
  "carrier": "ExpressPost",
  "eta": "Tomorrow 14:00"
}
بخش سومموتور ReAct

حلقه ایجنتیک (The Agentic Loop)؛ چرخه‌ای که مدل را به هدف می‌رساند

چرا خروجی پایتون هرگز مستقیماً به کاربر نشان داده نمی‌شود؟

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

قبل از اینکه هیچ جوابی برای کاربر جنریت (Generate) و نمایش داده شود، سرور پایتون خروجی و نتیجهٔ اجرای آن تابع را برمی‌دارد و دوباره به سمتِ خودِ مدل زبانی می‌فرستد! چرا؟ تا وقتی مدل دوباره از خواب بیدار شد، ببیند نتیجهٔ ابزاری که صدا زده بود چه شده است و بر اساس آن تصمیم بگیرد که در قدم بعدی باید چه کار کند:

تصمیم‌گیری‌های مدل پس از بازگشت خروجی ابزار

مدل زبانی با دریافت ورودی‌های قبلی به همراه نتیجه بازگشتی ابزار، سه مسیر محتمل را ارزیابی می‌کند:

  • آیا لازم است بر اساس این داده، حالا تابعِ دیگری را فرابخواند؟
  • آیا اجرای تابع به خطا خورده و باید ورودی‌ها را عوض کند و دوباره تلاش کند؟
  • یا اینکه اطلاعات کاملاً کافی است و حالا وقتش رسیده که جواب نهایی را بسته‌بندی کند و تحویل کاربر بدهد؟

تولد مفهوم بنیادین حلقه (While Loop)

اینجاست که مفهوم بنیادین Loop (حلقه) به وجود می‌آید! یک فرآیند چرخشی و تکرارشونده که مدل به دفعات آن را انجام می‌دهد—ابزار صدا می‌زند، خروجی را می‌بیند، فکر می‌کند و ابزار بعدی را صدا می‌زند—تا زمانی که با کمک ابزارهایی که در اختیار دارد به خروجیِ نهاییِ مد نظر برسد (و یا به سقف محدودیت تکرار که برای جلوگیری از چرخشِ بی‌نهایت برایش تعیین شده برخورد کند). این حلقه، قلب تپندهٔ تمام ایجنت‌های هوش مصنوعی است.

آزمایشگاه تعاملی • شبیه‌سازی زنده این بخش
شبیه‌ساز ۳: چرخه ۳ مرحله‌ای ReAct و حلقه بازگشتی به مدلموتور حلقه ایجنتیک
گام 1 از 5
مغز تصمیم‌گیر (LLM)بررسی ورودی و انتخاب ابزار
tool_calls ➔⮌ tool_output
موتور اجرایی پایتوناجرای تابع و کوئری API
⛔ دروازه قفل
پاسخ نهایی به کاربرتحویل پیام پس از اتمام کار
گام ۱: بیداری اول مدل و تصمیم به استعلام انبارLLM Thought #1

درخواست کاربر وارد شد. مدل کاتالوگ را بررسی کرده و تصمیم می‌گیرد ابتدا موجودی کارت گرافیک را بسنجد.

tool_calls: [
  {
    "name": "check_inventory",
    "arguments": { "item": "GPU" }
  }
]
بخش چهارممعماری پروتکل

پروتکل MCP (Model Context Protocol)؛ فانکشن کالینگ با پیازداغِ بیشتر!

گذر از توابع هاردکد شده محلی به سمت سرورهای توزیع‌شده و پلاگین‌های ماژولار

خب، حالا یک قدم جلوتر برویم. ما می‌توانیم آن تابعی که مدل دوست دارد فراخوانی شود را در سیستم شخصی و داخل کدهای پروژه خودمان داشته باشیم؛ یا اینکه آن تابع اصلاً روی سیستم ما نباشد! بلکه روی یک سرور دیگر، روی یک وب‌سایت، یا روی زیرساخت یک شرکت دیگر مستقر باشد و ایجنتِ ما از راه دور به آن مقصد درخواست بدهد.

فکرش را بکنید: با این روش، همهٔ سرویس‌دهنده‌ها، سایت‌ها و پلتفرم‌ها می‌توانند خدمات و قابلیت‌هایی که دارند را در یک قالبِ استاندارد در اختیار مدل‌های زبانی قرار دهند؛ طوری که کاربر به جای اینکه خودش مجبور باشد به صورت دستی وارد آن سایت یا سرویس شود، در منوها بگردد و دکمه بزند، صرفاً خواستهٔ خودش را به ایجنتش بگوید و ایجنت خودش مستقیماً سرویس‌های آن مقصد را نسبت به خواستهٔ کاربر استفاده کند!

به این استاندارد و زبانِ ارتباطیِ جهانی، Model Context Protocol یا به اختصار MCP می‌گویند. اگر بخواهیم خیلی راحت و بدون تعارف بگوییم: MCP در باطن همان Function Calling است، ولی یکم با پیازداغِ بیشتر!

تفاوتش این است که همه‌چیز در یک پروتکل استاندارد بسته‌بندی شده و سرورهای اجرایی (جایی که کدِ توابع واقعاً اجرا می‌شود) جایی دیگر و مستقل از کدهای اصلی ایجنت ما قرار دارند. این معماری کاربردهای بی‌شماری دارد:

اصطلاحات بنیادین اکوسیستم MCP

دو مفهوم کلیدی در توسعه و استفاده از پروتکل کانتکست مدل وجود دارد:

  • به آن سرورِ مستقلی که ابزارها و توابع را میزبانی می‌کند و در اختیار مدل می‌گذارد، MCP Server می‌گویند.
  • و به مجموعه‌ای از این MCP Serverها، اسکیل‌ها و تنظیمات که کنار هم پکیج می‌شوند تا یک مهارت و قابلیت کامل را به ایجنت اضافه کنند، پلاگین (Plugin) گفته می‌شود.
آزمایشگاه تعاملی • شبیه‌سازی زنده این بخش
شبیه‌ساز ۴: پروتکل MCP و هاب اتصال پلاگین‌های ماژولارمعماری کلاینت/سرور MCP
ایجنت کاربر (MCP Client / Host)
مجهز به پورت استاندارد MCP Bus • تعداد ابزارهای فعال: 4 ابزار • بار کانتکست کاتالوگ: 1200 توکن
MCP Universal Bus: READY
پلاگین صرافی و ترید
Exchange MCP Server
ابزارهای در دسترس:get_live_ticker(symbol)place_limit_order(side, price)
پلاگین گیت‌هاب
GitHub MCP Server
ابزارهای در دسترس:create_pull_request(title, branch)search_commits(query)
پلاگین دیتابیس سازمانی
Postgres MCP Server
ابزارهای در دسترس:run_readonly_query(sql)inspect_schema(table)
پلاگین پیام‌رسان
Telegram MCP Server
ابزارهای در دسترس:send_channel_alert(msg)send_chart_photo(file)
بخش پنجمفلسفه چندایجنتی

چرا یک مدلِ غول‌پیکر با همهٔ ابزارها کافی نیست؟ (فلسفه تعدد ایجنت‌ها)

گلوگاه‌های فنی، انفجار کانتکست و استعاره بنیادین ۱۰ سیب و ۱۰ کارگر

اینجا یک سوال بسیار منطقی و مهم پیش می‌آید: «خب اگر ما هم مدل‌های زبانی فوق‌العاده قوی داریم و هم پروتکل MCP و ابزارها را داریم، چرا تمامِ این صدها ابزار را یک‌جا به یک مدلِ خیلی قوی ندهیم که خودش همه‌چیز را بداند و همه‌کار بکند؟ اصلاً چرا به معماری‌های چندایجنتی (Multi-Agent)، تیم‌های ایجنتی و گاهی دهها یا صدها ایجنتِ مختلف نیاز داریم؟»

جواب این سوال در گلوگاه‌های فنیِ مدل‌ها و واقعیتِ مسائل پیچیده نهفته است. نکات بسیار مهمی در این باره وجود دارد:

۱. محدودیت کانتکست و آلودگی حافظه (Context Limit & Pollution)

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

۲. شاخه‌ای بودن تسک‌ها و تضاد شخصیت‌ها (Branching vs. Linear Execution)

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

۳. سرعت، موازی‌سازی و ریسکِ خستگی در وسط راه (مثال ۱۰ سیب و ۱۰ کارگر)

وقتی یک تسک بزرگ به تعدادِ ایجنت‌های مختلف شکسته شود، هم بسیار سریع‌تر به نتیجه می‌رسد و هم ریسک شکستِ کلِ عملیات به حداقل می‌رسد. بیایید یک مثال ملموس بزنیم: فرض کنید ۱۰ تا سیب روی زمین ریخته است.

  • اگر ما ۱۰ کارگر (۱۰ ایجنت موازی) داشته باشیم که هر کدام هم‌زمان فقط یک بار خم شوند و یک سیب را از روی زمین جمع کنند، کلِ این پروژه با یک بار حرکت و در کمترین زمان ممکن تمام می‌شود!
  • اما اگر فقط یک کارگر (یک ایجنت تکی) داشته باشیم که بخواهد به تنهایی ۱۰ بار خم و راست شود؛ اولاً زمانِ بسیار بیشتری می‌گیرد تا یکی‌یکی سیب‌ها را بردارد، و ثانیاً اصلاً مشخص نیست که آن یک کارگر بتواند هر ۱۰ بار را به سلامت خم شود! شاید در دفعهٔ هفتم کمرش بگیرد یا مشکلی برایش پیش بیاید (مدل در حلقهٔ هفتم دچار توهم شود، کانتکستش خراب شود یا خطای منطقی بدهد) و دیگر نتواند ادامه بدهد؛ در این حالت کلِ فرآیند متوقف می‌شود!

۴. گیج شدن مدل در برابر انبوه ابزارها (Tool Overload)

وقتی جلوی یک مدل زبانی ۳ تا ۵ ابزار مشخص می‌گذارید، با دقت نزدیک به صد درصد ابزار درست را انتخاب می‌کند. اما وقتی ۱۰۰ ابزار مختلف از چندین MCP Server را یک‌جا جلوی یک مدل می‌ریزید، مدل در انتخاب ابزار درست سردرگم می‌شود، ابزارهای شبیه به هم را اشتباه می‌گیرد و در هر بار بیدار شدن، هزاران توکن فقط صرفِ خواندنِ کاتالوگ ابزارهایی می‌شود که اصلاً در آن لحظه به کارش نمی‌آیند.

۵. بهینه‌سازی هزینه و انتخاب مغز متناسب با تسک (Cost & Model Routing)

همهٔ کارها به یک اندازه سخت نیستند. اگر فقط یک ایجنتِ غول‌پیکر داشته باشید، مجبورید برای ساده‌ترین کارها (مثل فرمت کردن یک متن یا استخراج یک عدد) هم از گران‌ترین و کندترین مدلِ دنیا استفاده کنید. اما وقتی کار بین ایجنت‌ها تقسیم شود، ایجنتِ «فرمانده و برنامه‌ریز» از قوی‌ترین مدل استفاده می‌کند، و کارگرهایی که قرار است آن ۱۰ تا سیب را از روی زمین بردارند، از مدل‌های کوچک، فوق‌سریع و بسیار ارزان استفاده می‌کنند.

۶. امنیت و محدود کردن شعاع خطا (Security & Sandboxing)

اگر یک ایجنتِ همه‌کاره داشته باشید که هم به اینترنت، هم به دیتابیس مالی و هم به خط فرمان سرور دسترسی دارد، یک خطا یا فریب خوردنِ مدل مساوی است با فاجعه! اما با شکستن سیستم به ایجنت‌های مجزا، هر ایجنت فقط و فقط به همان یکی دو ابزاری دسترسی دارد که برای وظیفهٔ کوچکش لازم است.

آزمایشگاه تعاملی • شبیه‌سازی زنده این بخش
شبیه‌ساز مسابقه‌ای ۵: بنچمارک ۱۰ سیب (۱ کارگر متوالی در برابر ۱۰ کارگر موازی)معماری چندایجنتی (Multi-Agent)
مسیر اول: تک‌ایجنت همه‌کاره (۱ کارگر برای جمع‌آوری ۱۰ سیب متوالی)آماده شروع
🍎سیب #1
🍎سیب #2
🍎سیب #3
🍎سیب #4
🍎سیب #5
🍎سیب #6
🍎سیب #7
🍎سیب #8
🍎سیب #9
🍎سیب #10
وضعیت کارگر تک‌ایجنت: در انتظار دستور
کوله کانتکست: 0% آلودگی کانتکست
مسیر دوم: معماری چندایجنتی (۱۰ کارگر تخصصی و موازی)آماده شروع
🍎سیب #1کارگر #1
🍎سیب #2کارگر #2
🍎سیب #3کارگر #3
🍎سیب #4کارگر #4
🍎سیب #5کارگر #5
🍎سیب #6کارگر #6
🔄سیب #7کارگر #7
🍎سیب #8کارگر #8
🍎سیب #9کارگر #9
🍎سیب #10کارگر #10
وضعیت تیم چندایجنتی: هر ۱۰ کارگر فقط ۱ بار به طور هم‌زمان خم شدند.
بار کانتکست هر کارگر: ۱۰٪ (کاملاً تمیز و ایزوله)
بخش ششمجمع‌بندی و اکوسیستم

«هارنس» (Harness)؛ زین و افسارِ این موجودِ پرحرف!

هسته LLM در برابر اسکلت مکانیکی و فریم‌ورک‌های مهندسی کنترل

حالا وقت آن است که تمام قطعات این پازل را کنار هم بگذاریم و تصویر بزرگ را ببینیم.

به کلِ این فرآیندِ حلقه (Loop) که در بالا به سادگی ذکر شد—به اضافهٔ نحوه تزریق فایل‌های مارک‌داون (ROLE و SKILL)، مدیریت حافظه و کانتکست، اتصال به سرورهای MCP، کنترل خطاها و هماهنگ کردن ایجنت‌های مختلف با هم—در مهندسی هوش مصنوعی اصطلاحاً «هارنس» (Harness) گفته می‌شود.

کلمه Harness در لغت به معنای «زین و برگ، افسار یا سازوکار مهارکننده و هدایت‌کننده» است.

واقعیت این است که امروز بحث و گفتگوهای بسیار زیادی در دنیای تکنولوژی در جریان است که این هارنس چقدر می‌تواند بهینه، سبک، سریع و هوشمند باشد و چه کارهایی را می‌تواند انجام دهد. اگر دقیق نگاه کنید، کلِ بحث، رقابت و تفاوت بین تمام فریم‌ورک‌ها و ابزارهای ایجنتیک دنیا، صرفاً طراحیِ همین «هارنس» به دورِ آن موجودِ آلزایمریِ پرحرف با بی‌نهایت اطلاعات به نام LLM است!

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

فهرست فریم‌ورک‌های پیشگام در مهندسی هارنس

این فریم‌ورک‌ها محورهای اصلی پرونده‌های عمیق آینده وب‌سایت خواهند بود:

  • Antigravity (agy sdk) — فریم‌ورک سبک، با تمرکز بر اجرای ایجنت‌های مستقل، بدون وابستگی‌های سنگین ابری و بهینه‌شده برای توسعه سریع تک‌نفره
  • PydanticAI — مهندسی تایپ‌سیف و اعتبارسنجی ورودی/خروجی‌های ساختاریافته ابزارها با قدرت Pydantic v2
  • LangGraph — پیاده‌سازی هارنس در قالب گراف‌های چرخه‌ای حالت‌دار (Stateful Cyclical Graphs) با قابلیت بازگشت در زمان (Time Travel)
  • CrewAI — ساختاردهی ایجنت‌ها بر اساس فرهنگ سازمانی، نقش‌های شغلی و واگذاری تسک‌های ترتیبی و سلسله‌مراتبی
  • AutoGen — معماری چندعامله مبتنی بر گفتگوی چندطرفه و کانوِرسِیشِنال توسط مایکروسافت
  • OpenClaw — هارنس تخصصی برای اتوماسیون وب، مرورگر و کارهای بصری با ایجنت‌های چندوجهی
  • Hermes Agent — فریم‌ورک سبک برای استقرار ایجنت‌ها روی سخت‌افزارهای محلی و مدل‌های منبع‌باز کوانتیزه‌شده

آینده این مسیر در وب‌سایت

و ابزارهای دیگری که در تاپیک‌ها و بخش‌های آینده وب‌سایت، به سراغ تک‌تک آن‌ها می‌رویم و کالبدشکافی می‌کنیم که هر کدام چطور این موجودِ آلزایمریِ نابغه را مهار و هدایت می‌کنند!

آزمایشگاه تعاملی • شبیه‌سازی زنده این بخش
شبیه‌ساز ۶: چرخ معماری هارنس و اطلس مقایسه‌ای فریم‌ورک‌های دنیامعماری کلان سیستم
وضعیت هارنس پیرامون مغز زبانی:

مدل زبانی به تنهایی یک تابع ریاضی بدون حالت است؛ هارنس اسکلت بیرونی کنترل‌کننده آن است.

هسته مرکزی: Stateless LLM
موجود آلزایمری و پرحرف با بی‌نهایت اطلاعات و صفر حافظه پیوسته
حلقه 1: لایه هویت و مهارت
ROLE.md & SKILL.md Injector
حلقه 2: مدیریت حافظه و کانتکست
Memory & Context Compaction
حلقه 3: موتور حلقه ایجنتیک
The ReAct Loop Engine
حلقه 4: درگاه ابزارها و پلاگین‌ها
Function Calling & MCP Router
حلقه 5: هماهنگ‌کننده چندایجنتی
Multi-Agent & Sub-Agent Orchestrator
اطلس مقایسه‌ای فریم‌ورک‌های دنیا (روی هر کدام کلیک کنید):
Antigravity (agy sdk)Solo Dev Native
تمرکز روی حلقه‌های: 1، 2، 4، 5
PydanticAIType-Safe Core
تمرکز روی حلقه‌های: 1، 4
LangGraphStateful Graphs
تمرکز روی حلقه‌های: 3، 5
CrewAIRole-Based Crews
تمرکز روی حلقه‌های: 1، 5
AutoGenConversational Multi-Agent
تمرکز روی حلقه‌های: 3، 5
OpenClawWeb & GUI Automation
تمرکز روی حلقه‌های: 3، 4
Hermes AgentEdge & Local Deploy
تمرکز روی حلقه‌های: 2، 4
بررسی معماری: Antigravity (agy sdk)تخصص در لایه‌های 1 و 2 و 4 و 5 هارنس

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

چرا در مقالات آینده آن را کالبدشکافی می‌کنیم؟ الگوی اصلی توسعه این سایت و معماری پیش‌فرض ما برای اجرای مستقل تسک‌ها در دو سیستم‌عامل لینوکس و ویندوز.

ادامه این پرونده تخصصی

کالبدشکافی عمیق تک‌تک فریم‌ورک‌های دنیا در مقالات بعدی

در بخش‌های بعدی به سراغ سورس کد و مهندسی معکوس فریم‌ورک‌های agy sdk، PydanticAI، LangGraph، CrewAI و AutoGen خواهیم رفت تا ببینیم هر کدام در عمل چطور این هارنس را پیاده‌سازی کرده‌اند.

بازگشت به مرکز آموزش‌ها و مقالات