متن
قبل از انتخاب framework، معماری را روشن کنید
وقتی از ساخت AI Agent صحبت میکنیم، خیلی زود بحث روی اسم frameworkها یا مدلها میافتد. اما قبل از انتخاب ابزار، باید بفهمیم معماری Agent چیست. معماری یعنی نحوه تقسیم مسئولیتها، شکل جریان تصمیم، مرز ابزارها، نوع حافظه، loop اجرا و نقطههای کنترل.
اگر این لایه روشن نباشد، انتخاب framework فقط ظاهر مسئله را تغییر میدهد. ممکن است Agent شما روی کاغذ پیشرفته به نظر برسد، اما در عمل معلوم نباشد چه زمانی باید برنامهریزی کند، چه زمانی ابزار صدا بزند، چه چیزی را در حافظه نگه دارد و کجا باید متوقف شود.
ورودی → هدف → planning → tool use / memory → بازبینی → خروجیاین مسیر اگر روشن باشد، انتخاب framework هم معنیدارتر میشود.
وقتی میگوییم معماری AI Agent، دقیقا از چه حرف میزنیم؟
معماری AI Agent یعنی پاسخدادن به چند سوال بنیادی:
- Agent هدف را چگونه میفهمد؟
- آیا قبل از اجرا برنامهریزی میکند یا قدمبهقدم تصمیم میگیرد؟
- چه ابزارهایی در اختیار دارد و با چه محدودیتی؟
- state کوتاهمدت و دانش بلندمدت را چگونه نگه میدارد؟
- در چه loopی اجرا میشود؟
- چه زمانی باید به انسان یا سیستم دیگر handoff کند؟
این نگاه کمک میکند Agent را نه به عنوان «یک prompt بزرگ»، بلکه به عنوان یک سیستم چندلایه ببینیم.
بلوکهای اصلی معماری Agent
لایه goal و planning
Agent باید بداند چه کاری را برای چه هدفی انجام میدهد. بعضی معماریها از همان ابتدا plan تولید میکنند. بعضی دیگر plan را در حین اجرا اصلاح میکنند.
لایه reasoning و control
منظور از reasoning در معماری Agent، جادو یا AGI نیست. منظور، شکستن مسئله به گامهای کنترلپذیر و انتخاب تصمیم بعدی بر اساس context موجود است.
لایه tool use
Tool use یعنی Agent فقط متن تولید نکند و بتواند در جای درست به ابزار، API یا منبع داده وصل شود. این لایه باید با scope، اعتبارسنجی و کنترل طراحی شود، نه با اتصال خام.
جزئیات اجرای این بخش را در Tool Calling ببینید.
لایه memory و context
Agent برای اجرای چندمرحلهای معمولا به چیزی بیشتر از prompt لحظهای نیاز دارد. اینجا بحث memory، retrieval و state management وارد میشود.
لایه orchestration
اگر workflow چندمرحلهای باشد، باید مشخص شود چه چیزی ترتیب اجرا، handoff، retry و توقف را کنترل میکند.
لایه execution loop
هر Agent در عمل داخل یک loop اجرا میشود:
- دریافت هدف
- تحلیل وضعیت
- انتخاب اقدام
- فراخوانی ابزار یا تولید خروجی
- بررسی نتیجه
- تصمیم برای ادامه، توقف یا handoff
planning چه الگوهایی دارد؟
plan-once
در این الگو Agent اول یک نقشه کلی میسازد و بعد اجرا میکند. برای کارهای نسبتاً روشن مفید است، اما اگر وضعیت وسط کار تغییر کند، plan اولیه ممکن است سریع کهنه شود.
iterative planning
در این الگو Agent در هر مرحله plan را بازبینی میکند. این روش انعطاف بیشتری دارد، اما هزینه، latency و complexity آن هم بیشتر است.
decomposition by subtask
بعضی معماریها مسئله را به زیروظیفههای مشخص میشکنند. این روش برای workflowهای سازمانیافته مفید است، چون traceability بهتری میدهد.
tool use فقط اتصال به API نیست
Tool use فقط اتصال خام به API نیست. در معماری، مهم است Agent بداند چه زمانی به ابزار نیاز دارد، چه scopeی مجاز است و خروجی چگونه اعتبارسنجی میشود.
- انتخاب ابزار باید وابسته به نیاز واقعی باشد، نه عادت.
- هر ابزار باید scope مشخص داشته باشد.
- ورودی و خروجی باید قبل از اجرا قابلاعتبارسنجی باشند.
- اگر جزئیات اجرایی میخواهی، Tool Calling را جدا بخوان.
memory با RAG یکی نیست
در بسیاری از بحثها memory و RAG بهجای هم استفاده میشوند، اما از نظر معماری یکی نیستند. برای جزئیات بیشتر، Memory و RAG را جدا ببین.
| لایه | نقش | مثال |
|---|---|---|
| state کوتاهمدت | نگهداشتن وضعیت همین workflow | گام فعلی، نتیجه مرحله قبل، پارامترهای فعال |
| memory بلندمدت | نگهداشتن ترجیحها و الگوهای پایدار | لحن ترجیحی کاربر، تاریخچه کار، تصمیمهای تکرارشونده |
| RAG | آوردن دانش مرتبط از منبع بیرونی | بازیابی سند، مقاله یا بخش مرتبط برای پاسخ دقیقتر |
یک Agent ممکن است retrieval خوب داشته باشد اما memory ضعیف، یا برعکس. همین تفاوت است که طراحی معماری را مهم میکند.
orchestration کجا وارد میشود؟
وقتی Agent فقط یک سؤال را جواب نمیدهد و وارد زنجیره کار میشود، orchestration مهم میشود.
linear workflow
مناسب کارهایی است که ترتیب ثابتی دارند: دریافت ورودی، بازیابی دانش، تولید خروجی، بازبینی.
router-worker pattern
در این الگو یک لایه تصمیم میگیرد که کدام worker یا ابزار باید وارد عمل شود. برای سناریوهای چندمسیره مناسب است.
planner-executor pattern
در این الگو یک بخش plan میچیند و یک بخش دیگر آن را اجرا میکند. اگر درست پیاده شود، traceability و کنترل بیشتری میدهد.
retrieval-augmented workflow
در این مدل، retrieval بخشی از pipeline است نه یک الحاق تزئینی. معماری باید مشخص کند retrieval در کدام مرحله و با چه محدودیتی وارد میشود.
execution loop را دستکم نگیرید
بسیاری از Agentها در demo خوب به نظر میرسند چون فقط یک قدم را نشان میدهند. اما در عمل کیفیت loop تعیینکننده است.
stop condition
Agent باید بداند چه زمانی کار تمام شده است. نبود stop condition روشن میتواند به loopهای بیپایان یا هزینه اضافی منجر شود.
retry policy
اگر ابزار خطا داد، آیا Agent باید دوباره تلاش کند؟ چند بار؟ با چه تغییری؟ اینها تصمیمهای معماریاند.
handoff policy
گاهی بهترین تصمیم این است که Agent ادامه ندهد و کار را به انسان یا workflow دیگر بسپارد.
یک مثال کوتاه
اگر Agent باید یک transcript جلسه را خلاصه کند، loop میتواند اینطور پیش برود:
- هدف را میگیرد: خلاصه مدیریتی برای جلسه ۳۰ دقیقهای
- متن جلسه را به بخشهای کوچکتر تقسیم میکند
- نکات تصمیم، ریسک و action item را استخراج میکند
- اگر داده ناقص بود، یک سوال تکمیلی برای انسان میسازد
- خروجی را در قالب خلاصه و action item تحویل میدهد
single-agent در برابر multi-agent
اگر مسئله را هنوز با یک نقش و یک مسیر اجرا میشود حل کرد، single-agent را نگه دارید. multi-agent فقط وقتی ارزش پیدا میکند که تفکیک نقشها، handoff و traceability واقعا سود بدهند.
| نشانه | single-agent | multi-agent |
|---|---|---|
| مسئله باریک و روشن است | بهترین شروع | اضافهکاری |
| نقشها و handoffها واضح است | کافی است | مناسبتر میشود |
| کنترل و debugging مهمتر از تنوع نقشهاست | بهتر است | ریسک بالاتر |
| وظیفهها واقعا مستقلاند | سادهتر است | ارزش پیدا میکند |
هزینه پنهان multi-agent فقط در هوشمندی بیشتر نیست؛ coordination، latency، debugging و evaluation را هم سختتر میکند.
tradeoffهای معماری را باید زود دید
انعطاف در برابر قابلیت کنترل
معماری بازتر میتواند adaptableتر باشد، اما کنترل و تست را سختتر میکند.
توانمندی در برابر هزینه
هر لایه جدید:
- planning پیشرفتهتر
- memory بیشتر
- retrieval عمیقتر
- ابزارهای بیشتر
میتواند capability را بالا ببرد، اما cost surface را هم بزرگتر میکند.
autonomy در برابر observability
هرچه تصمیمها خودکارتر شوند، نیاز به logging، trace و monitoring بیشتر میشود.
نسبت معماری با framework و platform
Frameworkها و platformها معماری را جایگزین نمیکنند. آنها فقط بعضی الگوها را آسانتر یا سختتر میکنند.
مثال مفهومی
- اگر دنبال orchestration و tool use هستید، بهتر است چند تحلیل پروژه از فریمورکهای شاخص را کنار هم بخوانید تا تفاوت رویکردها روشنتر شود.
- اگر retrieval و workflowهای دادهمحور برایتان مهم است، از تحلیلهایی شروع کنید که روی جریان داده، بازیابی دانش و طراحی workflow تمرکز دارند.
- اگر میخواهید لایه پلتفرمی را ببینید، مرور چند پروفایل ابزار در کنار تحلیل پروژهها به فهم تفاوت execution layer و research layer کمک میکند.
اما انتخاب framework نباید قبل از روشن شدن pattern معماری انجام شود.
برای اولین معماری واقعی از کجا شروع کنیم؟
- مسئله را باریک تعریف کنید.
- با single-agent شروع کنید.
- فقط ابزارهای ضروری را وصل کنید.
- memory را فقط وقتی اضافه کنید که نیازش روشن شده باشد.
- retrieval را به عنوان یک جزء سنجشپذیر وارد کنید، نه یک buzzword.
- multi-agent را آخر اضافه کنید، نه اول.
بعد از این مقاله چه بخوانیم؟
اگر میخواهید مسیر بعدی را روشنتر کنید، این مقالهها را بهترتیب ببینید:
جمعبندی
خلاصهٔ عملی این است: معماری AI Agent یعنی روشنکردن مسیر ورودی → تصمیم → ابزار/حافظه → بازبینی → خروجی و بعد انتخاب framework، memory و multi-agent فقط وقتی این مسیر در عمل جواب نداد.
- اگر مسئله باریک است، single-agent نقطه شروع بهتری است.
- اگر state، retrieval و handoff روشن نباشند، پیچیدگی فقط بیشتر میشود.
- اگر observability ندارید، autonomy بیشتر ریسک است تا مزیت.