تیم‌های ایجنتی نقش‌محور در CrewAI: نقش‌ها، وظایف و فرایندها

سیستم‌های چندایجنت (Multi-Agent Systems) در دموهای اولیه جذاب به نظر می‌رسند، اما هنگام استقرار در محیط عملیاتی، چالش‌هایی نظیر غیرقطعی بودن اجرا، هزینه‌ی بالای توکن‌ها و دشواری خطایابی خود را نشان می‌دهند. فریم‌ورک CrewAI با تفکیک وظایف بر پایه‌ی نقش‌ها، راهکاری ساخت‌یافته برای مدیریت این پیچیدگی ارائه می‌دهد.

در این درس یاد می‌گیرید که چگونه با استفاده از چهار عنصر اصلی CrewAI یعنی Agent، Task، Crew و Process، یک تیم همکاری خودکار بسازید و چرا برای سیستم‌های آماده‌ی بهره‌برداری باید از ساختار رویدادمحور و قطعی Flow استفاده کنید.

اگر برای اجرای پروژه‌ها با مدل‌های ابری مانند OpenAI دسترسی مستقیم ندارید یا پرداخت ارزی برایتان دشوار است، می‌توانید از گیت‌وی‌های واسط داخلی سازگار با OpenAI استفاده کنید یا با ابزارهایی مانند Ollama مدل‌های متن‌باز را به شکل محلی به کار بگیرید و وابستگی‌ها را با ابزار uv یا میرورهای pip نصب کنید.

چهار عنصر پایه: ایجنت (Agent)، وظیفه (Task)، کرو (Crew) و فرایند (Process). دو ساختار سطح‌بالا: Crews (همکاری خودکار و نقش‌محور) و Flows (رویدادمحور و قطعی). CrewAI پیاده‌سازی مرجع سال 2026 است و مستنداتش با صراحت می‌گویند: «برای هر برنامه‌ی آماده‌ی محیط عملیاتی، با یک Flow شروع کنید.»

اهداف یادگیری

• نام بردن چهار عنصر پایه‌ی CrewAI (ایجنت، Task، کرو و Process) و حیطه‌ی مسئولیت هر کدام.
• تشخیص تفاوت فرایندهای ترتیبی (Sequential)، سلسله‌مراتبی (Hierarchical) و فرایند برنامه‌ریزی‌شده‌ی اجماع (Consensus)؛ و انتخاب یکی بر اساس بار کاری.
• تمایز قائل شدن میان Crews (نقش‌محور و خودکار) و Flows (رویدادمحور و قطعی)، و توضیح توصیه‌ی مستندات برای محیط عملیاتی.
• اتصال ابزارها با استفاده از دکوراتور @tool و زیرکلاس BaseTool؛ و بررسی تفاوت خروجی ساختاریافته (Structured Output) با متن آزاد.
• نام بردن چهار نوع حافظه‌ی CrewAI و شناخت زمان مناسب برای بهره‌گیری از هر کدام.
• پیاده‌سازی یک تیم سه‌ایج smash (پژوهشگر، نویسنده، ویراستار) با پایتون خالص برای تولید یک گزارش خلاصه. <!-- REVIEW: در متن مبدأ three-agent crew آمده؛ عبارت سه‌ایج smash یا تیم سه‌ایج smash اصلاح شد به تیم سه‌ایج smash. -->
• شناسایی چهار حالت شکست (Failure modes) در CrewAI: باد کردن پرامپت (Prompt-bloat)، هزینه‌ی LLM مدیر (Manager-LLM tax)، دست‌به‌دست کردن شکننده‌ی کار بین ایجنت‌ها (Brittle handoffs) و استفاده‌ی مستقیم از Crew در محیط عملیاتی (Crew-as-prod).

صورت مسئله

تیم‌هایی که به سراغ فریم‌ورک‌های چندایج smash می‌روند به یک مانع تکراری برمی‌خورند. «همکاری خودکار» در دمو فوق‌العاده به نظر می‌رسد؛ اما بعد از آن، مشتری یک باگ گزارش می‌کند و شما نیاز به بازپخش قطعی (Deterministic replay) دارید. یا تیم مالی می‌پرسد هزینه‌ی هر بار اجرای یک تیمِ مسیریابی‌شده با LLM چقدر است. یا نیروی آن‌کال (On-call) باید بداند کدام ایجنت در ساعت 3 نیمه‌شب گیر کرده است.

تیم‌های آزاد و مسیریابی‌شده با LLM پاسخ تمیزی به هیچ‌کدام از این‌ها نمی‌دهند. گراف‌های جهت‌دار غیرمدور خالص (Pure DAGs) به همه‌ی این‌ها پاسخ می‌دهند، اما ساختار اکتشافی لازم برای یک ایجنت ایده‌پرداز را از دست می‌دهند.

تفکیک ارائه‌شده در CrewAI در مورد این بده‌بستان صادقانه است: Crews برای کارهای مشارکتی، نقش‌محور و اکتشافی؛ و Flows برای کارهای رویدادمحور، تحت کنترل کد، و قابل حساب‌رسی در محیط عملیاتی. یک فریم‌ورک، دو ساختار؛ انتخاب بر اساس نیاز کاری.

مفاهیم پایه

چهار عنصر پایه

فضای بیرونی CrewAI کوچک است. این چهار مورد را به خاطر بسپارید؛ باقی فقط پیکربندی است.

• ایجنت (Agent). ترکیب role + goal + backstory + tools + (optional) llm. بخش داستان پیش‌زمینه (Backstory) نقش باربری دارد؛ لحن، قضاوت و زمان توقف ایجنت را شکل می‌دهد. ابزارها توابعی هستند که ایجنت می‌تواند فراخوانی کند (توضیحات بیشتر در ادامه).
• وظیفه (Task). ترکیب description + expected_output + agent + (optional) context + (optional) output_pydantic. یک واحد کاری با قابلیت استفاده‌ی مجدد. پارامتر expected_output همان قرارداد کاری است. پارامتر context وظایف بالادستی را مشخص می‌کند که خروجی‌هایشان به این وظیفه تزریق می‌شود. پارامتر output_pydantic ساختاری مشخص به خروجی تحمیل می‌کند.
• تیم یا کرو (Crew). ظرف دربرگیرنده. مالک فهرست agents، فهرست tasks، استراتژی process، و تنظیمات اختیاری memory ،verbose و manager_llm.
• فرایند (Process). استراتژی اجرا. ترتیبی (Sequential)، سلسله‌مراتبی (Hierarchical)، و اجماع (Consensus - برنامه‌ریزی‌شده). ساختار کلی اجرا را مشخص می‌کند.

ایجنت‌ها مستقیماً یکدیگر را نمی‌بینند. Taskها به ایجنت‌ها ارجاع می‌دهند. Crew توالی وظایف را مرتب می‌کند. Process تعیین می‌کند چه کسی وظیفه‌ی بعدی را برمی‌دارد. کل مدل ذهنی ماجرا همین است.

تاییدشده بر اساس CrewAI 0.86 (مه 2026). نسخه‌های جدیدتر ممکن است انواع فرایندها را تغییر نام دهند یا ادغام (merge) کنند؛ پیش از اتکا به یک ساختار خاص، مستندات فرایندهای CrewAI را بررسی کنید.

فرایندهای Sequential در مقابل Hierarchical در مقابل Consensus

• ترتیبی (Sequential). وظایف به همان ترتیبی که تعریف شده‌اند اجرا می‌شوند. خروجی وظیفه‌ی N به عنوان context در اختیار وظیفه‌ی N+1 قرار می‌گیرد. کمترین هزینه و بیشترین قابلیت پیش‌بینی. زمانی استفاده کنید که ترتیب کارها ثابت است.
• سلسله‌مراتبی (Hierarchical). یک ایجنت مدیر (با یک فراخوانی مجزای LLM) کارها را بین متخصصان مسیریابی می‌کند. CrewAI مدیر را بر اساس تنظیمات manager_llm شما یا به صورت پیش‌فرض می‌سازد. مدیر در هر دور وظیفه‌ی بعدی را انتخاب می‌کند و می‌تواند کار را رد کند یا مسیر آن را تغییر دهد. زمانی از آن استفاده کنید که چهار متخصص یا بیشتر دارید و ترتیب کارها واقعاً به خروجی پیشین (Prior) بستگی دارد.
• اجماع (Consensus). برنامه‌ریزی‌شده، اما هنوز در API عمومی پیاده‌سازی نشده است. مستندات این نام را برای یک فرایند آینده بر مبنای رای‌گیری رزرو کرده‌اند. فعلاً روی آن حساب نکنید.

روش Hierarchical علاوه بر هزینه‌ی فراخوانی هر متخصص، یک فراخوانی LLM اضافه در هر دور برای مدیر تحمیل می‌کند. در یک اجرای پنج‌مرحله‌ای، مصرف توکن می‌تواند تا سه برابر (Triple) افزایش یابد. فقط زمانی هزینه‌اش را بپردازید که به این نوع مسیریابی واقعاً نیاز دارید.

مقایسه‌ی Crews و Flows

این همان قالبی است که مستندات در سال 2026 با آن شروع می‌کنند.

• کرو (Crew). خودکاری مبتنی بر LLM. فریم‌ورک ساختار را در محیط اجرا (Runtime) انتخاب می‌کند. مناسب برای: پژوهش، طوفان فکری، پیش‌نویس اولیه، و هر جایی که خودِ مسیر بخشی از پاسخ است. بازپخش آن سخت است. تست آن دشوار است. ساخت نمونه‌ی اولیه با آن کم‌هزینه است.
• فلو (Flow). گرافی رویدادمحور که در کنترل خودتان است. علامت @start نقطه‌ی ورود را مشخص می‌کند. علامت @listen(topic) مرحله‌ای را نشان می‌دهد که پس از انتشار آن تاپیک توسط مرحله‌ای دیگر فعال می‌شود. هر مرحله کد پایتون خالص است (و در داخل می‌تواند یک Crew را فراخوانی کند). مناسب برای: محیط عملیاتی. قابل رصد. قابل تست. قطعی و پیش‌بینی‌پذیر.

توصیه‌ی مستندات سال 2026 برای محیط عملیاتی: با یک Flow شروع کنید. هر جا که خودکاری ارزش هزینه‌اش را داشت، Crewها را در قالب فراخوانی‌های Crew.kickoff() در داخل مراحل Flow بگنجانید. Flow ردگیری محاسبات (Trace) و امکان حساب‌رسی را برایتان فراهم می‌کند و Crew توانایی اکتشاف را به شما می‌دهد. این دو را ترکیب کنید، نه این‌که بینشان فقط یکی را انتخاب کنید.

یکپارچه‌سازی ابزارها

سه راه برای اضافه کردن ابزار به یک ایجنت وجود دارد. ساده‌ترین موردی که کارتان را راه می‌اندازد انتخاب کنید.

1. دکوراتور @tool. توابع خالص (Pure Functions) تبدیل به ابزار می‌شوند. امضای تابع همان اسکیما است؛ Docstring نیز توضیحی است که LLM می‌بیند. بهترین گزینه برای کارهای کمکی کوچک.

      from crewai.tools import tool
   
      @tool("Search the web")
      def search(query: str) -> str:
          """Return top results for the query."""
          return run_search(query)

2. زیرکلاس BaseTool. ابزار مبتنی بر کلاس با اسکیمای آرگومان مشخص، پشتیبانی از async، و قابلیت تلاش مجدد. زمانی استفاده کنید که ابزار دارای وضعیت داخلی (مثل کلاینت یا حافظه‌ی موقت) است یا به آرگومان‌های ساختاریافته نیاز دارد.

      from crewai.tools import BaseTool
      from pydantic import BaseModel
   
      class SearchArgs(BaseModel):
          query: str
          limit: int = 10
   
      class SearchTool(BaseTool):
          name = "web_search"
          description = "Search the web and return top results."
          args_schema = SearchArgs
   
          def _run(self, query: str, limit: int = 10) -> str:
              return self.client.search(query, limit=limit)

3. جعبه‌ابزارهای داخلی. CrewAI تطبیق‌دهنده‌های (Adapters) رسمی داخلی به همراه دارد: SerperDevTool ،FileReadTool ،DirectoryReadTool ،CodeInterpreterTool ،RagTool و WebsiteSearchTool. همگی با یک دستور import آماده‌ی استفاده می‌شوند.

خروجی‌های ساختاریافته با Pydantic کار می‌کنند. کافی است پارامتر output_pydantic=MyModel را به Task بدهید. CrewAI پاسخ LLM را بر اساس مدل اعتبارسنجی می‌کند و در صورت نیاز آن را تبدیل یا فراخوانی را مجدداً تکرار می‌کند. این قابلیت را با یک رشته‌ی دقیق برای expected_output همراه کنید. خروجی‌های متنی آزاد برای پیش‌نویس‌ها مناسبند؛ اما این خروجی‌های ساختاریافته هستند که می‌توانند خوراک Flowهای بعدی شوند.

سازوکارهای حافظه

CrewAI چهار نوع حافظه را به صورت پیش‌فرض ارائه می‌دهد. این حافظه‌ها با هم ترکیب می‌شوند؛ یعنی یک Crew می‌تواند هر چهار نوع را هم‌زمان فعال کند.

تاییدشده بر اساس CrewAI 0.86 (مه 2026). نسخه‌های جدید همه‌چیز را از طریق یک سیستم یکپارچه‌ی Memory هدایت می‌کنند که این چهار مخزن را در بر می‌گیرد. مدل مفهومی زیر همچنان برقرار است، اما کلاس‌های عمومی ممکن است در نسخه‌های جدیدتر در یک نقطه‌ی ورودی واحد Memory ادغام شوند؛ برای اطلاع از API فعلی مستندات حافظه‌ی CrewAI را ببینید.

• کوتاه‌مدت (Short-term). بافر گفت‌وگو در طول یک نوبت گفت‌وگو (Turn) یا اجرای منفرد. در انتهای اجرا پاک می‌شود.
• بلندمدت (Long-term). ماندگار میان اجراهای مختلف. در یک پایگاه داده‌ی برداری ذخیره می‌شود (به صورت پیش‌فرض Chroma، با قابلیت تعویض). بازیابی بر اساس شباهت به وظیفه‌ی فعلی انجام می‌شود.
• موجودیت (Entity). فکت‌های مربوط به موجودیت‌ها. مثل «مشتری X حساب شرکتی دارد». کلیدواژه‌ی آن خود موجودیت است، نه شباهت معنایی. میان اجراهای مختلف حفظ می‌شود.
• زمینه‌ای (Contextual). بازیابی در زمان سرهم‌بندی پرامپت. حافظه‌ی مرتبط را دقیقاً در همان لحظه‌ای که ایجنت به آن نیاز دارد می‌آورد، نه از قبل.

حافظه را در Crew با memory=True یا پیکربندی مجزا برای هر نوع فعال کنید. این قابلیت متکی به ارائه‌دهنده‌ی امبدینگ (Embedding) انتخابی شماست (به صورت پیش‌فرض OpenAI، با قابلیت تعویض به مدل‌های محلی). حافظه یکی از جاهایی است که CrewAI برتری خود را نسبت به فریم‌ورک‌های سبک‌تر نشان می‌دهد؛ چرا که در LangGraph خالص باید تک‌تک این بخش‌ها را خودتان سیم‌کشی کنید.

چه زمان تیم‌های نقش‌محور مناسبند؟

• وقتی سه تا شش ایجنت با نقش‌های مشخص و فرایند کاری مشارکتی دارید: پیش‌نویس، بازبینی، برنامه‌ریزی و طوفان فکری.
• در مسیریابی‌هایی که قضاوت LLM درباره‌ی مرحله‌ی بعدی، بخشی از ارزش کار است (روش Hierarchical).
• هر جایی که تیم ترجیح می‌دهد به جای خواندن یک گراف پیچیده، ترکیب role + goal + backstory را بخواند.

چه زمان مناسب نیستند؟

• گراف‌های جهت‌دار غیرمدور (DAG) قطعی با ترتیب سفت‌وسخت. در این حالت از LangGraph (درس 13) استفاده کنید. ساختار گراف انتزاع بهتری برای این کار است؛ تعریف نقش در CrewAI اصطکاک بیهوده ایجاد می‌کند.
• سقف تاخیرهای (Latency budgets) زیر ثانیه. روش Hierarchical درخواست و پاسخ رفت‌وبرگشتی اضافه می‌کند. حتی روش Sequential نیز پرامپت‌هایی شامل داستان‌های پیش‌زمینه و خروجی‌های پیشین را پشت سر هم ردیف می‌کند.
• حلقه‌های تک‌ایجنتی. از فریم‌ورک صرف‌نظر کنید؛ یک حلقه‌ی ایجنت (Agent loop، درس 1) به همراه رجیستری ابزار کد کمتری می‌برد.

در درس 28 (الگوهای ارکستراسیون) این ساختارها را شانه به شانه مقایسه می‌کنیم. خلاصه‌ی ماجرا: جایگاه CrewAI در گوشه‌ی «همکاری نقش‌محور» است.

ساختار وابستگی‌ها

مستقل از LangChain است. سازگار با Python 3.10 تا 3.13. از uv استفاده می‌کند. تعداد ستاره‌ها: به crewAIInc/crewAI سر بزنید (اسنپ‌شات تا مه 2026). یکپارچگی با AWS Bedrock مستندسازی شده است؛ بنچمارک‌های ارائه‌شده از طرف توسعه‌دهنده‌ی فریم‌ورک در بار کاری پرسش و پاسخ، افزایش سرعت چشمگیری را نسبت به LangGraph گزارش می‌کنند، اما متدولوژی آن‌ها (مجموعه‌داده، سخت‌افزار، سنجه‌ی ارزیابی) منتشر نشده است، بنابراین آمار ارائه‌شده توسط شرکت سازنده را فقط در حد یک تقریب اولیه در نظر بگیرید.

مواردی که این الگو به مشکل می‌خورد

• باد کردن پرامپت با پیش‌زمینه‌ها. پیش‌زمینه‌ای با 2000 کلمه به ازای هر ایجنت در یک تیم پنج‌نفره، سقف توکن کانتکست را قبل از اولین فراخوانی ابزار می‌سوزاند. پیش‌زمینه‌ها را زیر 200 کلمه نگه دارید. عبارات را میان ایجنت‌ها بازنویسی کنید و شیوه‌نامه‌ی سازمان را پنج بار تکرار نکنید.
• هزینه‌ی توکن LLM مدیر. فرایند سلسله‌مراتبی قبل از هر بار صدا زدن متخصص، یک فراخوانی LLM برای مدیر اضافه می‌کند. در یک تیم با پنج وظیفه، این یعنی ده فراخوانی LLM به جای پنج تا، و پرامپت مدیر کل فهرست وظایف و خروجی‌های قبلی را هم در خود دارد. اگر مسیریابی وابسته به خروجی نیست، حالت را روی Sequential بگذارید.
• تحویل شکننده‌ی کار. خروجی مورد انتظار (expected_output) وظیفه‌ی N برابر با «یک ساختار کلی» است. وظیفه‌ی N+1 آن را به عنوان context می‌خواند و سعی می‌کند سه بخش را پارس کند؛ اما LLM چهار بخش تولید کرده است. ایجنت پایین‌دستی شروع به بداهه‌پردازی می‌کند. راه‌حل: روی وظیفه‌ی N از output_pydantic استفاده کنید تا وظیفه‌ی N+1 یک شیء دارای نوع مشخص بخواند، نه متن آزاد.
• استفاده‌ی مستقیم از Crew در محیط عملیاتی. فرستادن یک Crew آزاد به محیط عملیاتی بدون قرار دادن آن داخل یک پوشش Flow. تنوع خروجی زیاد است؛ بازپخش ممکن نیست؛ و نیروی آن‌کال نمی‌تواند تفاوت اجرای خراب را با اجرای سالم بفهمد. آن را داخل یک Flow بگذارید.

پیاده‌سازی از صفر

فایل code/main.py هر دو ساختار را به همراه یک تیم سه‌ایج smash در پایتون خالص پیاده می‌کند. تنها وابستگی خارجی خارج از کتابخانه‌ی استاندارد، numpy برای شبیه‌سازی شباهت معنایی است.

ساختار:

• دیتاکلاس‌های Agent و Task منطبق بر اینترفیس CrewAI.
• تابع SequentialCrew.kickoff(inputs) وظایف را به ترتیب تعریف اجرا می‌کند و خروجی‌ها را به عنوان context دست‌به‌دست می‌کند.
• تابع HierarchicalCrew.kickoff(topic) یک ایجنت مدیر اضافه می‌کند که در هر دور متخصص بعدی را انتخاب کرده و با عبارت «done» به کار پایان می‌دهد.
• کلاس Flow با دکوراتورهای @start و @listen(topic)، یک حلقه‌ی رویداد کوچک، و امکان ردگیری محاسبات (Trace).
• دکوراتور tool(name) مشابه ساختار @tool در CrewAI.
• کلاس Memory با مخازن short_term ،long_term و entity؛ محاسبه‌ی شباهت ساختگی از numpy استفاده می‌کند.
• پاسخ‌های ساختگی LLM رشته‌های ثابتی هستند که بر اساس نقش و پیشوند ورودی تعیین می‌شوند. بدون نیاز به شبکه و با خروجی کاملاً قطعی.

دموی عملی: تیم متشکل از پژوهشگر، نویسنده و ویراستار که گزارشی کوتاه درباره‌ی «agent engineering 2026» تولید می‌کنند. پژوهشگر منابع ساختگی را گردآوری می‌کند. نویسنده پیش‌نویس می‌نویسد. ویراستار متن را صیقل می‌دهد. همین تیم داخل یک Flow هم اجرا می‌شود تا ساختار قطعی آن را نشان دهد.

اجرای برنامه:

python3 code/main.py

ردگیری محاسبات شامل این موارد است: تیم ترتیبی که خروجی‌ها را از طریق context ردوبدل می‌کند؛ تیم سلسله‌مراتبی با انتخاب‌های مدیر (پژوهشگر، نویسنده، ویراستار، سپس «done»)؛ اجرای Flow برای همان سه مرحله با تاپیک‌های مشخص (researched ،drafted ،edited)؛ فراخوانی‌های ابزار (Tool calls) که از مسیر @tool مسیریابی شده‌اند؛ و ماندگاری حافظه‌ی بلندمدت در طول دو بار اجرا.

ردگیری Crew منعطف است؛ مدیر در اصل می‌توانست ترتیب را تغییر دهد. ردگیری Flow کاملاً ثابت است. درس اصلی این بخش در همین تفاوت انتخاب نهفته است.

استفاده از ابزارهای واقعی

• CrewAI Flow برای محیط عملیاتی. حتی اگر Flow فقط یک مرحله باشد که Crew.kickoff() را صدا می‌زند. Flow مرزهای حساب‌رسی و نظارت را برایتان معین می‌کند.
• CrewAI Crew (Sequential) برای کارهای مشارکتی با ترتیب مشخص، به‌خصوص پیش‌نویس اول و چرخه‌های بازبینی.
• CrewAI Crew (Hierarchical) زمانی که مسیریابی به خروجی وابسته است و چهار متخصص یا بیشتر دارید.
• LangGraph (درس 13) برای ماشین‌های وضعیت (State Machines) صریح، ادامه‌ی مطمئن پردازش (Durable resume) و ترتیب سفت‌وسخت.
• AutoGen v0.4 (درس 14) برای هماهنگی با مدل اکتور (Actor-model concurrency) و جداسازی خطاها.
• OpenAI Agents SDK (درس 16) برای محصولات مبتنی بر اکوسیستم OpenAI با قابلیت جابه‌جایی وظایف (Handoffs) و گاردریل‌ها (سازوکارهای ایمنی).
• Claude Agent SDK (درس 17) برای محصولات مبتنی بر Claude با ساب‌ایجنت‌ها و ذخیره‌سازی نشست (Session store).

خروجی این درس

فایل outputs/skill-crew-or-flow.md ساختار مناسب (Crew یا Flow) را برای کار شما تعیین کرده و اسکلت حداقلی آن را می‌سازد. در این فرایند، ساخت Crew بدون داستان پیش‌زمینه، ساخت Flow بدون تاپیک‌های صریح، و اجرای حالت Hierarchical با کمتر از سه متخصص بلافاصله رد می‌شود.

دام‌های رایج

• دیدن پیش‌زمینه به عنوان متنی تزئینی. پیش‌زمینه به خروجی فرم می‌دهد. سه نسخه‌ی مختلف را برای هر ایجنت تست کنید؛ تفاوت‌ها جدی است. یکی را نهایی کرده و روی همان بمانید.
• حذف expected_output. بدون وجود یک قرارداد مشخص برای هر وظیفه، وظایف بعدی هر چه را که LLM تولید کند به عنوان ورودی برمی‌دارند. تیم کار می‌کند، اما خروجی نهایی از بررسی کیفی رد نمی‌شود.
• روشن گذاشتن دائمی حافظه. حافظه‌ی بلندمدت در هر بار اجرا داده می‌نویسد. پایگاه داده‌ی برداری باد می‌کند و کیفیت بازیابی به دلیل نویز کاهش می‌یابد. دامنه‌ی (Scope) نوشتن را محدود به وظایفی کنید که فکت‌های پایدار دارند.
• تغییر تدریجی رفتار پرامپت مدیر. پرامپت مدیر در حالت Hierarchical پنهان است. اگر مسیریابی عجیبی دیدید، پرامپت را در حالت پرگویی (Verbose) چاپ کرده و دقیق بخوانید.
• اثرات جانبی ابزار در Crews. یک Crew ممکن است ابزاری را بیشتر از تعداد دفعات پیش‌بینی‌شده فراخوانی کند. عملیات POST، عملیات DELETE یا پرداخت مالی باید درون یک مرحله از Flow قرار بگیرند، نه داخل ابزاری که در اختیار Crew است.

تمرین‌ها

1. تیم ترتیبی (Sequential) را به یک Flow تبدیل کنید. بخش‌هایی را که میزان خطای تصادفی در آن‌ها کاهش پیدا کرده بشمارید. بررسی کنید خوانایی در کدام بخش‌ها کمتر شده است.
2. حافظه‌ی موجودیت (Entity memory) را به تیم اضافه کنید: فکت‌های مربوط به یک مشتری بین چند بار اجرای kickoff باقی بماند. مطمئن شوید بازیابیْ موجودیتِ درست را می‌خواند.
3. یک فرایند Hierarchical بسازید که در آن، مدیر از ارجاع کار به ویراستار خودداری کند مگر این‌که خروجی نویسنده حداقل سه پاراگراف داشته باشد. این تلاش مجدد را در ردگیری محاسبات بررسی کنید.
4. یک زیرکلاس BaseTool برای جست‌وجوی وب (ساختگی) پیاده کنید. ساختار ردگیری محاسبات آن را با نسخه‌ی دکوراتور @tool مقایسه کنید.
5. قابلیت output_pydantic=Brief را به وظیفه‌ی ویراستار اضافه کنید، به طوری که Brief دارای فیلدهای title ،summary و sections باشد. کاری کنید که وظیفه‌ی نویسنده یک بار خروجی JSON نامعتبر بدهد؛ رفتار تلاش مجدد CrewAI را در ردگیری برنامه بررسی کنید.
6. بخش معرفی مستندات CrewAI را مطالعه کنید. کد ساده‌ی این درس را به رابط واقعی کتابخانه‌ی crewai منتقل کنید. نسخه‌ی نوشته‌شده با کتابخانه‌ی استاندارد چه تضمین‌هایی را نادیده گرفته بود؟
7. ابزار AgentOps یا Langfuse (درس 24) را به یک اجرای واقعی وصل کنید. چه ردگیری‌هایی در نسخه‌ی پایتون استاندارد ما وجود نداشت؟

اصطلاحات کلیدی

برای مطالعه‌ی بیشتر

• معرفی مستندات CrewAI: مفاهیم پایه و مسیر پیشنهادی برای محیط عملیاتی
• راهنمای Flows در CrewAI: ساختار رویدادمحور، @start و @listen
• مرجع ابزارهای CrewAI: دکوراتور @tool، کلاس BaseTool، و جعبه‌ابزارهای داخلی
• حافظه در CrewAI: کوتاه‌مدت، بلندمدت، موجودیت و زمینه‌ای
• مقاله‌ی Anthropic درباره‌ی ساخت ایجنت‌های موثر: زمان مفید بودن یا نبودن سیستم‌های چندایج smash
• نمای کلی LangGraph: راهکاری جایگزین بر پایه‌ی ماشین وضعیت