تخصص نقش برنامه نویس، منتقد، اجرای، تأیید کننده
Code = SOP(Team). . ChatDev (arXiv:2307.07924) از طریق یک "چت چت" با "حلال شناسي" (عملاء به طور صریح درخواست جزئیات گمشده) ، طراح، برنامه نویس، بازرس، آزمایش کننده را به زنجیره ای متصل می کند. تایید کننده تحمل بار: Cemri و همکارانش (MAST، arXiv:2503.13657) نشان می دهد هر شکست چند عامل می تواند به تایید گمشده یا شکسته ردیابی شود. PwC گزارش داد که 7x افزایش دقت (10٪ → 70٪) از حلقه های تأیید ساختار یافته در CrewAI.Type: Learn + Build
Languages: Python (stdlib)
Prerequisites: Phase 16 · 04 (Primitive Model), Phase 16 · 05 (Supervisor)
Time: ~60 minutes
مشکل
سیستم های چند عامل عمومی تولیدات عمومی را تولید می کنند. سه کدگر در یک چت گروهی سه طعم از همان کد متوسط را می نویسند. شما می توانید عوامل بیشتری اضافه کنید، دور های بیشتری اضافه کنید و هنوز هم از حد کیفیت عبور نکنید.
اصلاح بیشتر عوامل نیست این عوامل متفاوت است. نقش های متفاوتی را اختصاص دهید. ابزار انتقادی را که برنامه نویس ندارد، به ابزار انتقادی بدهید. یک مجموعه آزمایش هدفمند را به تأیید کننده بدهید. اکنون سیستم با اصلاح مبتنی بر زمین، نه فقط حدس زدن موازی، اختلاف داخلی دارد.
مفهوم
چهار نقش کاینونیکی
Planner.هدف را می خواند، یک لیست گام ها یا مشخصات را تولید می کند ابزار: بازیافت دانش، اسناد، محصول: برنامه ساختاری.
Executor.یک مرحله از یک برنامه را در یک زمان می خواند، آرتیفاکت را تولید می کند. ابزار: ابزارهای کار واقعی (توسعه ساز کد، پوسته، مشتری API) ، محصول: آرتیفاکت.
Critic.در حال خواندن محصول اجرا کننده در مقابل قصد برنامه نویس ابزار: دسترسی تنها به اثر، تجزیه و تحلیل جامد، محصول: قبول / رد با دلایل.
Verifier.ابزار: آزمایشی، تایپ چک، تأیید کننده شیما، خروجی: عبور / شکست با شواهد.
منتقد ذهنی، نظرمند، اغلب مبتنی بر LLM است. تایید کننده عینی، تعیین کننده، اغلب مبتنی بر کد است. آنها نقش مشابهی ندارند.
الگوی SOP MetaGPT
MetaGPT (arXiv:2308.00352) SOP های مهندسی نرم افزار را به عنوان پیام های نقش رمزگذاری می کند:
- Product Managerنوشته هاي سازمان ملل
- Architectطراحی سیستم را تولید می کند.
- Project Managerوظایف را تقسیم می کند.
- Engineerابزارها
- QA Engineerتست ها رو انجام ميده
هر نقش دارای یک طرح ورودی / خروجی دقیق است. پیامک نقش می گوید نقش چیست و چه چیزی باید تولید کند .Code = SOP(Team)فرمولا SOP های تعیین کننده یک تیم LLM را به یک خط لوله قابل پیش بینی تبدیل می کنند.
ديهالوسيناسي ارتباطي چاد ديو
ChatDev یک حرکت کلیدی را اضافه می کند: هنگامی که یک اجرا کننده به جزئیات خاصی نیاز دارد که در برنامه نبود، قبل از ادامه به طور صریح از طراح می پرسد. این مانع از شکست کلاسیک LLM از اختراع دقیق می شود.
پیاده سازی: پیامک نقش شامل "وقتی به اطلاعات خاصی نیاز دارید که به شما داده نشده است، قبل از تولید محصول از نقش مربوطه نام بپرسید".
چرا تایید کننده مهم ترین است
Cemri et al. (MAST) 1642 شکست اجرای چند عامل را ردیابی کرد. 21.3% شکاف های تأیید بودند سیستم پاسخی را ارسال کرد که هیچ کس بررسی نکرده بود. 79% باقی مانده اغلب به "یک چک وجود داشت که به طور ساکت شکست خورد یا هرگز اجرا نشد".
PwC گزارش داد (CrewAI deployments، 2025) که اضافه کردن یک حلقه تأیید ساختار یافته دقت را از 10٪ به 70٪ منتقل کرد. 7 × افزایش از یک نقش.
منتقد مقابل تأیید کننده
- منتقدي يه مدرک تحصيلي است که يه اثر را به نظر مي رسونه
- یک تایید کننده یک برنامه تعیین کننده ای است که روی اثر اجرا می شود. هدف. با شواهد عبور می کند.
از هر دو استفاده کنید. منتقد مشکلات طعم را می گیرد که تأیید کننده نمی تواند بیان کند. تایید کننده اشکال را می گیرد که منتقد نمی تواند ببیند زیرا آنها فقط در زمان اجرا ظاهر می شوند.
این ضد الگوی
هر نقش در سیستم شما یک LLM است و هر نقش محصول "به نظر من خوب است". حالت شکست MAST کلاسیک. حداقل یک تایید کننده را اضافه کنید که عبور / شکست آن توسط کد تصمیم می گیرد، نه توسط LLM.
نقشه برداری چارچوب
- CrewAI
Agent(role, goal, backstory)سطح تخصصی کتاب های درسی است. - LangGraph گره ها می توانند پیام های تخصصی داشته باشند؛ حاشیه ها خط لوله را تقویت می کنند.
- AutoGen عوامل قابل گفتگو خاص نقش با نام های یک کلمه در یک گروه چت.
- OpenAI Agents SDK ابزار انتقال بین عوامل تخصصی نقش.
آن را بسازید
code/main.pyیک خط لوله 4 نقش را اجرا می کند که یک تابع ساده پایتون را ایجاد می کند:
- Plannerتولید یک مشخصات.
- Executorیک رشته کد تولید می کند.
- Critic(تخونیک LLM) مشکلات واضح را نشان می دهد.
- Verifierکد تولید شده را در یک جعبه قمار اجرا می کند (
exec) در مقابل یک مورد آزمایش.
دمو دو بار اجرا می شود: یک بار که اجرا کننده کد صحیح تولید می کند (تهمین کدهای انتقادی + تأیید کننده عبور می کنند) ، یک بار که اجرا کننده کد غیر مشخصی تولید می کند (تهمین خطا را از دست می دهد زیرا قابل قبول به نظر می رسد ، تأیید کننده آن را به دلیل شکست آزمون دریافت می کند).
راه رفتن:
python3 code/main.pyازش استفاده کن
outputs/skill-role-designer.mdیک کار را انجام می دهد و لیست نقش (3-5 نقش) ، طرح ورودی / خروجی هر نقش و چک تایید کننده را تولید می کند.
-باده
فهرست چک:
- At least one deterministic verifier.هرگز تمام-LLM.
- Explicit I/O schema per role.برنامه نویس یک مشخصات را باز می گرداند، نه پروزه؛ اجرا کننده آن طرح را می خواند.
- Communicative dehallucination.اجرايي بايد از برنامه ريزيگاه بپرسد که چه وقت اطلاعات گم شده، هرگز اختراعش نکن.
- Critic/verifier ordering.ابتدا منتقد را اجرا کنید (بایسته، مشکلات طراحی را می گیرد) ، دوم تایید کننده (بیمار، اشکال را می گیرد).
- Loop budget.ماکس 2 دورات بازنگري از منتقد و اجراگر قبل از اينکه به انسان ارتقا پيدا کنه
تمرینات
- فرار کن
code/main.pyو مشاهده کنید که چگونه تایید کننده خطا را که منتقد از دست داده است تشخیص می دهد. یک بررسی تجزیه و تحلیل استاتیک اضافه کنید (حاصلات شمارشreturn) به عنوان یک تأیید کننده اضافی. چه چیزی را که آزمایش زمان اجرا از دست می دهد، می گیرد؟ - یک نقش پنجم اضافه کنید: "تحلیلی نیازها" که خواسته های کاربر را به مشخصات آماده برنامه ریزی کننده ترجمه می کند. چه درخواست های ارتباطی از الهلوسانی باید به آن برسد؟
- بخش 3 (اعمال) MetaGPT را بخوانید. طرح ورودی/خروجی هر یک از 5 نقش MetaGPT را لیست کنید.
- نمودار زنجیره چت چت چت دیو را بخوانید (ارکسوی:2307.07924 شکل 3) شناسایی کنید که در کجا دی هالوشیناسیون ارتباطی یک حلقه را که در غیر این صورت بی نهایت است شکسته است.
- افزایش دقت 7x PwC از حلقه های تأیید ناشی شد. فرضیه سه وظیفه که در آن اضافه کردن یک تأیید کننده کمک نمی کند در آن جا که بررسی تعیین کننده درستی غیرممکن یا بسیار گران است.
اصطلاحات کلیدی
| Term | What people say | What it actually means |
|---|---|---|
| Role specialization | "Different agents, different jobs" | Distinct system prompts tuned for planner/executor/critic/verifier roles. |
| SOP pattern | "Encoded standard operating procedure" | MetaGPT's framing: strict I/O schemas per role turn a team into a pipeline. |
| Communicative dehallucination | "Ask before inventing" | ChatDev pattern: executor asks planner when a detail is missing rather than making one up. |
| Critic | "LLM reviewer" | Subjective, opinionated reviewer. Catches taste issues. Can be fooled by plausible prose. |
| Verifier | "Deterministic check" | Code-based pass/fail. Test runner, type checker, schema validator. Cannot be fooled. |
| Verification gap | "No one checked" | 21.3% of MAST failures. Answer shipped without a check that would have caught the bug. |
| Revision loop | "Critic sends it back" | Critic rejection triggers executor re-run with feedback. Needs a budget. |
| All-LLM anti-pattern | "Looks good to me" | Every role is an LLM, no deterministic check. Classic MAST failure. |
خواندن بیشتر
- Hong et al. — MetaGPT: Meta Programming for Multi-Agent Collaboration ورق مرجع SOP به عنوان نقش
- Qian et al. — Communicative Agents for Software Development (ChatDev) زنجیره چت + تخفیف الهلوس
- Cemri et al. — Why Do Multi-Agent LLM Systems Fail? طبقه بندی MAST؛ شکاف های تأیید 21.3% از شکست ها را تشکیل می دهد
- CrewAI docs — Agent roles سطح مشخصات نقش تولید
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.