در طراحی عاملهای هوشمند، الگوی محبوب ReAct با گرهزدن استدلال و اجرای ابزار در یک حلقه، برای کارهای کوتاه بسیار عالی است. با این حال، با افزایش مراحل کار، ارسال مکرر تاریخچهی کامل باعث رشد انفجاری مصرف توکن و افزایش هزینهها میشود. از طرفی چون دسترسی به API مدلهای خارجی و پرداختهای ارزی چالشهای هزینهای خاص خود را دارد، کاهش مصرف توکن و بهینهسازی فراخوانیها اهمیت فنی دوچندانی پیدا میکند.
الگوی ReWOO با تفکیک فرآیند تصمیمگیری به سه نقش «برنامهریز»، «مجری» و «حلکننده»، برنامه را در قالب یک گراف جهتدار بدون دور (DAG) پیشاپیش تدوین میکند. این کار بار پردازشی پرامپتها را تا 5 برابر کاهش میدهد، امکان گردآوری موازی شواهد را فراهم میسازد و تابآوری سیستم را در برابر خطای ابزارها بالا میبرد.
در این درس یاد میگیرید که چگونه با الگوهای ReWOO و Plan-and-Execute کارهای پیچیده و چندمرحلهای را بدون اتلاف توکن معماری کنید و با پیادهسازی گامبهگام آن در پایتون، عاملهای کارآمدتر و پایدارتری بسازید.
الگوی ReAct استدلال و اقدام را در یک جریان پیوسته در هم میتند. در مقابل، ReWOO این دو را از هم تفکیک میکند: ابتدا یک برنامهی جامع و یکباره، سپس اجرا. نتیجه؟ مصرف توکن 5 برابر کمتر، 4%+ دقت بالاتر روی HotpotQA و امکان تقطیر دانش (distillation) برنامهریز در یک مدل 7B. الگوی Plan-and-Execute این رویکرد را تعمیم داد و Plan-and-Act آن را برای پیمایش وب در ابعاد بزرگ پیاده کرد.
اهداف یادگیری
- دلیل کاهش مصرف توکن و افزایش تابآوری در تفکیک سهگانهی ReWOO (برنامهریز / مجری / حلکننده) نسبت به حلقهی درهمتنیدهی ReAct را توضیح دهید.
- یک DAG برنامه، یک مجری با ترتیب حل وابستگیها (dependency resolution) و یک حلکننده برای ترکیب خروجیهای مجریها پیادهسازی کنید — همگی صرفاً با کتابخانهی استاندارد پایتون (stdlib).
- با تکیه بر چارچوب «پنج الگوی گردش کار» Anthropic در سال 2026، تشخیص دهید چه زمانی باید کار را بهصورت «برنامهریزی سپس اجرا» پیش برد و چه زمانی بهشکل حلقهی درهمتنیدهی ReAct.
- زمان نیاز به دادههای برنامهریزی ساختگی (synthetic plan data) در Plan-and-Act را برای کارهای افقبلند (long-horizon) در وب یا موبایل تشخیص دهید.
صورت مسئله
حلقهی درهمتنیدهی «فکر-اقدام-مشاهده» در ReAct ساده و منعطف است، اما هر فراخوانی ابزار (tool call) باید کل زمینهی پیشین (prior context) — از جمله تکتک فکرهای قبلی — را به دوش بکشد. با افزایش عمق مراحل، مصرف توکن رشد درجهدو (quadratic) پیدا میکند. بدتر از آن: وقتی ابزاری در میانهی حلقه با خطا روبهرو میشود، مدل مجبور است کل برنامه را از روی همان مشاهدهی خطا از نو بازتولید کند.
ReWOO (شو و دیگران، arXiv:2305.18323، می 2023) متوجه این ضعف شد و دست روی رویکرد متفاوتی گذاشت: از همان ابتدا برای کل مسیر برنامهریزی کن، شواهد (evidence) را موازی به دست بیاور، و در پایان پاسخ را جمعبندی کن. یک فراخوانی مدل زبانی برای برنامهریزی، N فراخوانی ابزار برای شواهد (با امکان اجرای موازی)، و یک فراخوانی نهایی مدل زبانی برای حل مسئله. بهای این کار کاهش انعطافپذیری است (چون برنامه ایستا است)، اما در عوض کارایی مصرف توکن بهمراتب بالاتر میرود و حالتهای شکست (failure modes) کاملاً شفاف میشوند.
مفاهیم پایه
سه نقش اصلی
Planner: user_question -> [plan_dag]
Workers: [plan_dag] -> [evidence] (tool calls, possibly parallel)
Solver: user_question, plan_dag, evidence -> final_answer
برنامهریز (Planner) یک DAG میسازد. هر گره نام ابزار، آرگومانهای آن، و گرههای پیشینی را که به آنها وابسته است مشخص میکند (با ارجاعاتی مانند #E1 و #E2). مجریها (Workers) گرهها را با ترتیب توپولوژیک اجرا میکنند. حلکننده (Solver) همهچیز را کنار هم میگذارد و پاسخ نهایی را میسازد.
چرا 5 برابر مصرف توکن کمتر؟
در ReAct، با افزایش تعداد گامها، طول پرامپت (prompt) خطی بالا میرود. در گام 10، پرامپت شامل فکر 1 بهعلاوهی اقدام 1، مشاهدهی 1، فکر 2، اقدام 2، مشاهدهی 2 و همینطور تا آخر است. علاوه بر این، تکتک گامهای میانی پرامپت اولیه را هم بهطور تکراری در خود دارند.
اما ReWOO هزینهی یک پرامپت برنامهریز (بزرگ)، N پرامپت کوچک مجری (هرکدام صرفاً شامل همان فراخوانی ابزار، بدون زنجیرهی فکر قبلی)، و یک پرامپت حلکننده را میپردازد. مقالهی اصلی روی بنچمارک HotpotQA نشان میدهد که این روش مصرف توکن را حدود 5 برابر کمتر میکند و همزمان 4+ درصد دقت مطلق بیشتری به دست میآورد.
چرا تابآورتر است؟
در ReAct، اگر مجری 3 با خطا متوقف شود، حلقه باید در میانهی راه و از درون همان خطا مسیر جدیدی پیدا کند. در ReWOO، مجری 3 صرفاً یک رشتهی خطا برمیگرداند؛ سپس حلکننده آن خطا را در بستر برنامهی اصلی میبیند و میتواند رفتار سیستم را بدون فروپاشی ناگهانی و با وقار مدیریت کند (graceful degradation). ریشهیابی خطا هم گرهبهگره انجام میشود، نه گامبهگام در میان کل تاریخچه.
تقطیر دانش برنامهریز
دومین دستاورد مقاله: از آنجا که برنامهریز مشاهدات محیطی را نمیبیند، میتوانید یک مدل 7B را روی خروجیهای برنامهریزِ یک مدل استاد (teacher) با ابعاد 175B فاینتیون کنید. مدل کوچک کار برنامهریزی را به دوش میکشد و در زمان استنتاج دیگر نیازی به مدل بزرگ نخواهید داشت. این الگو اکنون جا افتاده است — بسیاری از ایجنتهای عملیاتی در سال 2026 از یک برنامهریز کوچک در کنار یک مجری بزرگ یا برعکس بهره میبرند.
الگوی Plan-and-Execute (سال 2023)
مقالهی آگوست 2023 تیم LangChain ایدهی ReWOO را در قالبی عمومیتر با عنوان Plan-and-Execute معرفی کرد: یک برنامهریز در ابتدا فهرستی از گامها را بیرون میدهد، مجری هر گام را اجرا میکند، و یک بازبرنامهریز (replanner) اختیاری میتواند پس از مشاهدهی نتایج، برنامه را بازنگری کند. این الگو نسبت به ReWOO به ReAct نزدیکتر است (چون بازبرنامهریز مشاهدات را دوباره وارد فرآیند برنامهریزی میکند)، ولی در عین حال صرفهجویی در مصرف توکن را نگه میدارد.
الگوی Plan-and-Act (اردوغان و دیگران، arXiv:2503.09572، کنفرانس ICML 2025)
الگوی Plan-and-Act این ایده را برای ایجنتهای وب و موبایل با کارهای افقبلند مقیاسپذیر کرد. دستاورد اصلی آن تولید دادههای برنامهریزی ساختگی است: یک مولد ردپا (trajectory) با برچسبگذاری دقیق، دادههای آموزشی تولید میکند که در آنها برنامه کاملاً صریح و مشخص است. از این دادهها برای فاینتیون کردن مدلهای برنامهریز استفاده میشود؛ مدلهایی که روی تسکهای شبیه به WebArena حتی پس از 30 تا 50 گام همچنان به کار ادامه میدهند؛ جاهایی که یک ردپای تکمسیرهی ReAct معمولاً انسجام خود را از دست میدهد.
کدام الگو را چه زمانی انتخاب کنیم؟
| الگو | چه زمانی؟ |
|---|---|
| ReAct | کارهای کوتاه، محیط ناشناخته، نیاز به مدیریت واکنشگرای استثناها |
| ReWOO | کارهای ساختاریافته با ابزارهای مشخص، حساسیت به مصرف توکن، شواهد با قابلیت گردآوری موازی |
| Plan-and-Execute | شبیه به ReWOO، ولی همراه با بازبرنامهریزی پس از اجرای بخشی از گامها |
| Plan-and-Act | کارهای افقبلند (بیش از 30 گام)، تعامل با وب/موبایل/رایانه |
| Tree of Thoughts | مسائلی که جستوجو در آنها ارزش هزینهکردن دارد (درس 04) |
توصیهی Anthropic در دسامبر 2024 روشن است: کار را با سادهترین ساختار شروع کنید. اگر کل تسک با یک فراخوانی ابزار و یک خلاصهسازی تمام میشود، به سراغ ReWOO نروید. اما اگر با یک کار پژوهشی 40گامه روبهرو هستید، به ReAct بهتنهایی تکیه نکنید.
پیادهسازی عملی
کد code/main.py یک نسخهی ساده از ReWOO را پیاده میکند:
Planner— یک منطق برنامهنویسیشده (scripted policy) که با گرفتن پرامپت، DAG برنامه را تولید میکند.Worker— فراخوانی ابزار مربوط به هر گره را از طریق رجیستری ارسال میکند.Solver— ترکیبکنندهای که شواهد را میخواند و پاسخ نهایی را میسازد.- حل وابستگیها (Dependency resolution) — ارجاعاتی مانند
#E1با خروجیهای مجریهای قبلی جایگزین میشوند.
این برنامه به پرسش «جمعیت پایتخت فرانسه چقدر است، گردشده به میلیون؟» در قالب یک برنامهی دوگامه پاسخ میدهد: (1) پیدا کردن پایتخت، (2) استخراج جمعیت، و سپس ارائهی پاسخ نهایی.
اجرایش کنید:
python3 code/main.py
ردگیری محاسبات (trace) ابتدا برنامهی کامل، سپس نتایج مجریها و در پایان ترکیب حلکننده را نشان میدهد. مصرف توکن را (که اینجا تقریبی از تعداد کاراکترها را چاپ میکنیم) با اجرای درهمتنیدهی سبک ReAct مقایسه کنید — ReWOO در این تیپ کارهای ساختاریافته برندهی بلامنازع است.
کاربرد در محیط واقعی
فریمورک LangGraph الگوی Plan-and-Execute را در قالب یک الگو آماده کرده است (create_react_agent برای ReAct، و گرافهای سفارشی برای ترکیب برنامهریزی-اجرا). قابلیت Flows در CrewAI این الگو را مستقیماً در خود دارد: شما تسکها را از پیش تعریف میکنید و DAG جریان کار آنها را پیش میبرد. رویکرد دادههای ساختگی در Plan-and-Act هنوز عمدتاً در سطح پژوهش است؛ اما الگوی محیط اجرای (runtime) آن (یعنی DAG برنامهی صریح) در سطح عملیاتی با LangGraph و CrewAI Flows به کار گرفته میشود.
تحویل نهایی
فایل outputs/skill-rewoo-planner.md با گرفتن درخواست کاربر و کاتالوگ ابزارها، یک DAG برنامهی ReWOO تولید میکند. این ابزار پیش از تحویل برنامه به مجری، صحت آن را میسنجد (اطمینان از بدوندور بودن گراف، حل شدن همهی ارجاعات و موجود بودن همهی ابزارها).
تمرینها
- اجرای مجریها را برای گرههای مستقل برنامه موازی کنید. این کار روی یک DAG ششگرهای با 2 گروه موازی چه دستاوردی دارد؟
- یک گره بازبرنامهریز اضافه کنید تا اگر هر مجری با خطا روبهرو شد، به کار بیفتد. کوچکترین تغییری که ReWOO را به Plan-and-Execute تبدیل میکند چیست؟
- بخش
Plannerرا با یک مدل کوچک (ردهی 7B) جایگزین کنید وSolverرا روی یک مدل پیشرو نگه دارید. کیفیت سرتاسری (end-to-end) را بسنجید — این تفکیک وظایف در کجا به بنبست میخورد؟ - بخش 4 مقالهی ReWOO دربارهی تقطیر دانش برنامهریز را بخوانید. دستاورد تبدیل 175B به 7B را بهصورت مفهومی بازتولید کنید: به چه دادههای آموزشی نیاز دارید و کیفیت برنامه را چطور ارزیابی میکنید؟
- کد نمونه را به قالب ردپای Plan-and-Act منتقل کنید: بهجای DAG، برنامه یک توالی خطی باشد. چه مصالحههایی تغییر میکنند؟
واژگان کلیدی
| اصطلاح | در گفتگوها | معنای دقیق فنی |
|---|---|---|
| ReWOO | «استدلال بدون مشاهدات» | برنامهریزی، سپس دریافت موازی شواهد، سپس حل نهایی — بدون گنجاندن مشاهدات در پرامپت برنامهریزی |
| Plan-and-Execute | «الگوی برنامهریزی-اجرای LangChain» | همان ReWOO همراه با یک گره بازبرنامهریز اختیاری پس از اجرا |
| Plan-and-Act | «برنامهریزی-اجرای مقیاسیافته» | تفکیک صریح برنامهریز/مجری همراه با دادههای آموزشی برنامهی ساختگی برای کارهای افقبلند |
| Evidence reference | «#E1، #E2، ...» | جانگهدار در گره برنامه که در زمان ارسال فراخوانی، با خروجی مجری پیشین جایگزین میشود |
| Planner distillation | «برنامهریز کوچک، مجری بزرگ» | فاینتیون کردن یک مدل کوچک روی ردگیریهای محاسباتی برنامهریز از یک مدل استاد بزرگ |
| Token efficiency | «تعداد رفتوبرگشت کمتر» | 5 برابر مصرف توکن کمتر در HotpotQA نسبت به ReAct بر اساس مقاله |
| DAG executor | «توزیعکنندهی توپولوژیک» | اجرای گرههای برنامه بر اساس ترتیب وابستگیها؛ بهشکل موازی در هر سطح |
مطالعهی بیشتر
- مقالهی مرجع ReWOO: جداسازی استدلال از مشاهدات (Xu et al., arXiv:2305.18323)
- مقالهی Plan-and-Act: ساختار مقیاسیافتهی برنامهریز-مجری با برنامههای ساختگی (Erdogan et al., arXiv:2503.09572)
- راهنمای Plan-and-Execute در LangGraph — دستورالعمل رسمی فریمورک
- راهنمای ساخت ایجنتهای کارآمد از Anthropic — انتخاب سادهترین الگوی کارآمد
