جریان کار ایجنتی وقتی لازم میشود که یک کار از چند مرحلهی مشخص تشکیل شده باشد. در چنین جریانی، دانستن اینکه الان کجای کار هستیم به اندازهی نتیجهی نهایی مهم است. بدون وضعیت روشن، تکرار یک درخواست یا قطع ارتباط ممکن است باعث دوبارهکاری شود؛ یا بدتر، تصمیمی که انسان گرفته بود گم شود.
در این قسمت از مجموعهی آموزش هوش مصنوعی تخته سبز، سیستم گردش کار Microsoft Agent Framework را میشناسیم. بعد الگوی ترتیبی را با یک مثال واقعی پیاده میکنیم و در پایان وضعیتی طراحی میکنیم که به ما اجازه دهد پس از قطع اجرا، کار را از آخرین مرحلهی موفق ادامه دهیم. دو قسمت بعدی به الگوهای همزمان و شرطی میپردازند.
جریان کار ایجنتی چیست؟
ایجنت هوش مصنوعی سیستمی است که فراتر از یک مدل زبانی معمولی کار میکند. محیطش را درک میکند، تصمیم میگیرد و برای رسیدن به هدف اقدام میکند. وقتی چند ایجنت یا چند مرحله کنار هم قرار میگیرند، به یک ساختار هماهنگکننده نیاز داریم. این ساختار همان جریان کار است.
سناریوهای رایج
جریان کار ایجنتی در سه نوع کار بیشتر به کار میرود. اول، حل مسئلهی پیچیده؛ مثل برنامهریزی یک رویداد که به ایجنتهای بودجه، اطلاعرسانی و تدارکات تقسیم میشود. دوم، دستیار مجازی که کار را به ایجنتهای تخصصی میسپارد.
سوم، تولید خودکار محتوا. یک ایجنت پیشنویس مینویسد، ایجنت دیگر آن را از نظر دقت و لحن بررسی میکند و ایجنت سوم منتشرش میکند. همین مثال آخر، الگوی بسیاری از محصولات واقعی است.
سه الگوی سازماندهی
جریانهای کار در سه الگوی اصلی سازماندهی میشوند. در الگوی ترتیبی، ایجنتها مثل خط تولید پشت سر هم کار میکنند و خروجی یکی ورودی بعدی است. در الگوی همزمان، ایجنتها موازی روی بخشهای مختلف کار میکنند و نتایج در پایان جمع میشوند.
در الگوی شرطی، مسیر بر اساس خروجی یک مرحله انتخاب میشود؛ مثل یک دستور if و else. در این مقاله روی الگوی ترتیبی و وضعیت تمرکز میکنیم. الگوهای همزمان و شرطی را در دو قسمت بعدی میبینیم.
معماری گردش کار در Microsoft Agent Framework
سیستم گردش کار Agent Framework یک موتور هماهنگسازی برای تعاملهای پیچیده میان چند ایجنت است. بر پایهی یک معماری گرافی ساخته شده که شبیه LangGraph است؛ با این تفاوت که بخشی از اکوسیستم مایکروسافت است و برای پایتون و .NET در دسترس است.
سه جزء اصلی
معماری سه جزء اصلی دارد. اجراکننده (Executor) واحد پردازش است. یک ایجنت نوعی اجراکننده است، اما یک تابع معمولی هم میتواند باشد. هر اجراکننده پیامهایی میگیرد، پردازش میکند و خروجی تولید میکند.
یال (Edge) مسیر پیام میان اجراکنندهها را تعریف میکند. یالها میتوانند شرط داشته باشند و پیام را بر اساس محتوایش به مسیرهای مختلف بفرستند. خود گردش کار (Workflow) هم کل فرایند را هماهنگ میکند و مطمئن میشود پیامها به ترتیب درست میان اجراکنندهها جابهجا میشوند.
چرا گراف؟
ساختار گرافی سه الگوی پایه را ممکن میکند: زنجیرهی ترتیبی، پخش و جمع (fan-out و fan-in) برای پردازش موازی، و انشعاب شرطی. این سه الگو را میتوان با هم ترکیب کرد و جریانهای پیچیده ساخت.
مزیت اصلی گراف، پیشبینیپذیری است. مسیر اجرا از پیش مشخص است و میتوان هر مرحله را جداگانه آزمود. این همان مزیتی است که در قسمت LangGraph هم دیدیم.
الگوی ترتیبی با یک مثال
سادهترین الگو، زنجیرهی ترتیبی است. در مثال درسنامه دو ایجنت داریم. ایجنت پذیرش هتل که به کوتاهگویی معروف است، یک پیشنهاد سفر میدهد. ایجنت مشاور که تجربههای محلی و اصیل را ترجیح میدهد، پیشنهاد را بررسی میکند و جایگزین بهتری میدهد.
تعریف ایجنتها و ساخت گراف
مسافری میگوید «میخواهم به پاریس بروم». ایجنت پذیرش موزهی لوور را پیشنهاد میدهد و ایجنت مشاور یک تجربهی محلی کمتر شلوغ را جایگزین میکند. در کد، ابتدا دو ایجنت با دستورالعمل خودشان ساخته میشوند و بعد با WorkflowBuilder به هم وصل میشوند:
front_desk = chat_client.as_agent(name="FrontDesk", instructions=FRONTDESK_INSTRUCTIONS)
concierge = chat_client.as_agent(name="Concierge", instructions=CONCIERGE_INSTRUCTIONS)
workflow = WorkflowBuilder(start_executor=front_desk).add_edge(front_desk, concierge).build()
events = await workflow.run("I would like to go to Paris.")
outputs = events.get_outputs()ایجنت پذیرش نقطهی شروع است و یک یال خروجی آن را به ایجنت مشاور میرساند. نام کلاسها و متدها ممکن است در نسخههای تازهی فریمورک تغییر کند؛ پیش از استفاده، نمونهکدهای رسمی مخزن را ببینید.
زنجیرهی چندمرحلهای
همین الگو را میتوان به چند مرحله گسترش داد. در مثال دوم درسنامه، کاربر تصویر یک اتاق نشیمن را میفرستد و قیمت مبلمان را میخواهد. ایجنت فروش اقلام را در تصویر شناسایی میکند، ایجنت قیمت برای هر قلم سه گزینهی اقتصادی، متوسط و گران پیشنهاد میدهد و ایجنت پیشفاکتور همه را در یک سند رسمی جمع میکند.
هر مرحله فقط یک کار انجام میدهد و خروجیاش ورودی مرحلهی بعد است. این سادگی، آزمون هر مرحله را آسان میکند. اگر پیشفاکتور اشتباه بود، میتوانید خروجی هر مرحله را جداگانه بررسی کنید و بفهمید اشکال از کجاست.
طراحی وضعیت برای ادامهی اجرا
اجرای چندمرحلهای ممکن است وسط کار قطع شود. سرویس مدل ممکن است موقتاً در دسترس نباشد، شبکه قطع شود یا مرحلهای منتظر تأیید انسان بماند. اگر وضعیت ذخیره نشده باشد، تنها راه، شروع دوباره از ابتداست؛ یعنی هزینهی دوباره و گاهی نتیجهی متفاوت.
قرارداد وضعیت هر مرحله
راهحل این است که هر مرحله قرارداد وضعیت روشنی داشته باشد: چه ورودیای میگیرد، چه خروجیای ذخیره میکند و در چه شرایطی به مرحلهی بعد میرود. خروجی هر مرحله با شناسهی کار ذخیره میشود.
کد زیر یک اجراکنندهی ساده با این قرارداد است. هر مرحله فقط وقتی اجرا میشود که خروجیاش هنوز ذخیره نشده باشد:
import json, pathlib
STEPS = ["receive", "review", "summarize", "queue_for_approval"]
def run_workflow(doc_id: str, handlers: dict, state_dir="state") -> dict:
path = pathlib.Path(state_dir) / f"{doc_id}.json"
state = json.loads(path.read_text()) if path.exists() else {"doc_id": doc_id, "done": {}}
for step in STEPS:
if step in state["done"]:
continue # این مرحله قبلاً موفق بوده؛ دوباره اجرا نمیشود
result = handlers[step](state)
if result.get("stop"):
state["stopped_at"] = step
break
state["done"][step] = result
path.parent.mkdir(exist_ok=True)
path.write_text(json.dumps(state, ensure_ascii=False))
return stateاگر اجرا در مرحلهی خلاصهسازی قطع شود، اجرای بعدی از همان مرحله ادامه پیدا میکند. دریافت و بررسی دوباره انجام نمیشوند و نتیجهشان همان قبلی است.
تصمیم انسان هم بخشی از وضعیت است
تصمیم بازبین انسانی هم باید در وضعیت ذخیره شود. اگر مدرس خلاصهای را رد کرده و دلیلش را نوشته، این تصمیم نباید با اجرای دوباره گم شود. در غیر این صورت ممکن است همان خلاصهی ردشده دوباره در صف تأیید قرار بگیرد.
فریمورکهای گردش کار معمولاً سازوکار ذخیرهی نقطهی بازیابی (Checkpoint) دارند. Agent Framework و LangGraph هر دو این قابلیت را ارائه میدهند. اما حتی با این ابزارها، باید خودتان تصمیم بگیرید چه چیزی بخشی از وضعیت است و چه چیزی نیست.
سناریوی عملی؛ پردازش یک متن آموزشی
یک متن آموزشی باید دریافت، بررسی و خلاصه شود و نتیجه در صف تأیید مدرس قرار بگیرد. نمودار زیر چهار مرحلهی این جریان را نشان میدهد.

ورودی و معیار پذیرش
ورودی آزمون سه بخش دارد: شناسهی سند، متن اولیه و وضعیت پردازش. یک نمونهی ناقص هم بگذارید؛ مثلاً سندی بدون متن. اقدام مورد بررسی، تعریف مرحلههای مشخص با خروجی قابل ذخیره و شرط انتقال به مرحلهی بعد است.
معیار پذیرش روشن است: پس از قطع اجرا، کار باید از آخرین مرحلهی موفق ادامه پیدا کند. جدول زیر قرارداد وضعیت هر مرحله را نشان میدهد.
| مرحله | ورودی | خروجی ذخیرهشده | شرط رفتن به مرحلهی بعد |
|---|---|---|---|
| دریافت | شناسه و متن | متن تمیزشده و زمان دریافت | متن خالی نباشد |
| بررسی | متن تمیزشده | نتیجهی بررسی و دلیل | بررسی قبول شود |
| خلاصه | متن و نتیجهی بررسی | خلاصه و نسخهی آن | خلاصه ساخته شود |
| صف تأیید | خلاصه | شناسهی درخواست تأیید | منتظر تصمیم مدرس |
نمونهی شکست؛ شروع دوباره یا تصمیم گمشده
دو شکست را عمداً بازسازی کنید. اول، اجرا را در مرحلهی خلاصه قطع کنید و ببینید آیا اجرای بعدی همهی مراحل را از اول شروع میکند. اگر بله، وضعیت درست ذخیره نمیشود.
دوم، یک خلاصه را از طرف مدرس رد کنید و اجرا را دوباره راه بیندازید. آیا همان خلاصه دوباره در صف قرار میگیرد؟ اگر بله، تصمیم بازبین بخشی از وضعیت نبوده است. نتیجهی مورد انتظار هر دو را پیش از اجرا بنویسید.
تمرین عملی؛ نقشهی جریان کار و قرارداد وضعیت
خروجی این تمرین نقشهی جریان کار و قرارداد وضعیت هر مرحله است:
- جریان چهارمرحلهای بالا را با تابع
run_workflowو چهار تابع ساده پیاده کنید. - اجرا را در مرحلهی سوم با یک خطای شبیهسازیشده قطع کنید و دوباره اجرا کنید.
- بررسی کنید مرحلههای اول و دوم دوباره اجرا نشدهاند و تصمیم مدرس حفظ شده است.
مشخص کنید کدام بخش را واقعاً اجرا کردهاید و کدام هنوز فرض است.
سخن پایانی
جریان کار ایجنتی کار چندمرحلهای را به گرافی از اجراکنندهها و یالها تبدیل میکند؛ ساختاری که قابلپیشبینی و قابل آزمون است. Microsoft Agent Framework این ساختار را با اجراکننده، یال و گردش کار پیاده میکند. اما مهمترین تصمیم طراحی، وضعیت است. هر مرحله باید قرارداد روشنی داشته باشد، خروجیاش را ذخیره کند و تصمیمهای انسانی را نگه دارد. در این صورت، قطع اجرا دیگر فاجعه نیست؛ فقط یک مکث است.
در قسمت بعد اجرای ترتیبی و همزمان را مقایسه میکنیم؛ انتخاب الگو برای سرعت و درستی پاسخ.
این آموزش بر پایهی راهنمای Workflows with Microsoft Agent Framework از مجموعهی آزاد AI Agents for Beginners مایکروسافت (مجوز MIT) به فارسی بازنویسی و تکمیل شده است.
پرسشهای پرتکرار
جریان کار ایجنتی با ایجنت آزاد چه فرقی دارد؟
در ایجنت آزاد، مدل خودش تصمیم میگیرد قدم بعدی چیست. در جریان کار ایجنتی، مسیر میان مرحلهها از پیش به شکل گراف تعریف شده و هر مرحله میتواند یک ایجنت یا یک تابع معمولی باشد. نتیجه قابلپیشبینیتر و قابل آزمونتر است.
اجزای گردش کار در Microsoft Agent Framework کداماند؟
سه جزء؛ اجراکننده که واحد پردازش است و میتواند یک ایجنت باشد، یال که مسیر پیام میان اجراکنندهها را تعریف میکند و میتواند شرط داشته باشد، و خود گردش کار که کل فرایند را هماهنگ میکند.
چرا باید وضعیت هر مرحله را ذخیره کرد؟
چون اجرای چندمرحلهای ممکن است وسط کار قطع شود؛ به دلیل خطای شبکه، محدودیت سرویس یا انتظار برای تأیید انسان. با وضعیت ذخیرهشده، اجرا از آخرین مرحلهی موفق ادامه پیدا میکند، نه از ابتدا.
قرارداد وضعیت مرحله چیست؟
توافقی دربارهی اینکه هر مرحله چه ورودیای میگیرد، چه خروجیای ذخیره میکند و در چه شرایطی به مرحلهی بعد میرود. این قرارداد آزمون هر مرحله را بهطور جداگانه ممکن میکند.







دیدگاهها
هنوز دیدگاهی ثبت نشده است. شروعکننده باشید — پرسش و اصلاح را با آغوش باز میپذیریم.