برنامه‌ریزی ایجنت؛ ساخت برنامه مطالعه چندمرحله‌ای و قابل اجرا

برنامه‌ریزی ایجنت وقتی لازم می‌شود که کار برای انجام در یک قدم خیلی پیچیده است. اما برنامه‌ای که فقط فهرستی از کارها باشد، ممکن است روی کاغذ خوب به نظر برسد و در عمل اجرا نشود. برنامه‌ریز خوب باید محدودیت زمان، ترتیب پیش‌نیازها و نتیجه‌ی هر مرحله را در نظر بگیرد.

در این قسمت از مجموعه‌ی آموزش هوش مصنوعی تخته سبز، الگوی طراحی برنامه‌ریزی را مرور می‌کنیم. یاد می‌گیریم هدف را روشن تعریف کنیم، کار را تجزیه کنیم و برنامه را به شکل خروجی ساختاریافته بگیریم. بعد برنامه را با کد اعتبارسنجی می‌کنیم؛ چون برنامه‌ای که مدل می‌سازد همیشه قابل اجرا نیست.

هدف روشن؛ نقطه‌ی شروع برنامه‌ریزی

بیشتر کارهای دنیای واقعی برای یک قدم خیلی پیچیده‌اند. ایجنت به هدفی روشن و مختصر نیاز دارد تا برنامه‌ریزی و اقدام‌هایش را هدایت کند. هدفی مثل «یک برنامه‌ی سفر سه‌روزه بساز» ساده بیان شده، اما هنوز به دقت بیشتری نیاز دارد.

هرچه هدف دقیق‌تر باشد، ایجنت، و هر همکار انسانی، بهتر روی نتیجه‌ی درست تمرکز می‌کند. برای یک برنامه‌ی مطالعه، هدف خوب این‌هاست: موضوع دقیق، زمان آزاد هفتگی، دانش فعلی و مهلت. «می‌خواهم در دوازده هفته، با هفته‌ای چهار ساعت، از صفر به ساخت یک پروژه‌ی تحلیل داده با پایتون برسم» هدفی است که می‌شود برایش برنامه ساخت.

تجزیه‌ی کار

کارهای بزرگ وقتی به زیرکارهای کوچک‌تر و هدفمند تقسیم شوند، قابل مدیریت می‌شوند. در مثال سفر، هدف به رزرو پرواز، رزرو هتل، اجاره‌ی خودرو و شخصی‌سازی تقسیم می‌شود. هر زیرکار را می‌توان به یک ایجنت تخصصی سپرد؛ یکی در یافتن بهترین قیمت پرواز تخصص دارد و دیگری در رزرو هتل.

این رویکرد ماژولار بهبود تدریجی را هم ممکن می‌کند. می‌توانید بعداً ایجنت‌های تازه‌ای، مثلاً برای پیشنهاد رستوران یا فعالیت محلی، اضافه کنید، بی‌آنکه بقیه‌ی سیستم تغییر کند. برای برنامه‌ی مطالعه هم زیرکارها مرحله‌های یادگیری‌اند: مبانی زبان، کار با داده، نمودارسازی و پروژه‌ی پایانی.

خروجی ساختاریافته برای برنامه‌ی قابل‌اعتماد

مدل‌های زبانی می‌توانند خروجی ساختاریافته، مثلاً JSON، تولید کنند. این خروجی برای ایجنت‌ها و سرویس‌های بعدی بسیار راحت‌تر قابل پردازش است. در برنامه‌ریزی این قابلیت حیاتی است؛ چون برنامه را کد می‌خواند تا زیرکارها را به ایجنت مناسب بفرستد، نه فقط انسان.

تعریف طرح‌واره‌ی برنامه

بهترین راه، تعریف طرح‌واره‌ی برنامه با Pydantic است. هر زیرکار شناسه، عنوان، ساعت تقریبی و فهرست پیش‌نیازها دارد:

from pydantic import BaseModel, Field
from openai import OpenAI

class StudyTask(BaseModel):
    id: str
    title: str
    hours: float = Field(gt=0)
    depends_on: list[str] = []

class StudyPlan(BaseModel):
    goal: str
    weekly_hours: float
    tasks: list[StudyTask]

client = OpenAI()
response = client.responses.parse(
    model="gpt-5-mini",
    input="برای رسیدن از صفر به ساخت یک پروژه‌ی تحلیل داده با پایتون در ۱۲ هفته، با هفته‌ای ۴ ساعت، برنامه‌ی مطالعه بساز.",
    text_format=StudyPlan,
)
plan: StudyPlan = response.output_parsed

متد responses.parse مدل را مجبور می‌کند خروجی را دقیقاً با همین طرح‌واره تولید کند. نتیجه یک شیء پایتون است که مستقیم قابل استفاده است؛ دیگر لازم نیست متن آزاد را تجزیه کنید.

برنامه‌ریز و ایجنت‌های تخصصی

در الگوی پیشرفته‌تر، برنامه‌ریز یک ایجنت مرکزی است که فهرست ایجنت‌های تخصصی و ابزارهایشان را می‌شناسد. درخواست کاربر را می‌گیرد، برنامه‌ی ساختاریافته می‌سازد و هر زیرکار را به ایجنت مربوط می‌فرستد. در طرح‌واره، نام ایجنت مسئول هر زیرکار را هم می‌توان با یک Enum مشخص کرد.

اگر برنامه فقط یک زیرکار داشته باشد، برنامه‌ریز پیام را مستقیم به همان ایجنت می‌فرستد. اگر چند زیرکار باشد، هماهنگی میان چند ایجنت لازم می‌شود. در پایان هم برنامه‌ریز نتیجه را برای کاربر خلاصه می‌کند.

اعتبارسنجی برنامه با کد

خروجی ساختاریافته تضمین می‌کند برنامه شکل درستی دارد؛ اما تضمین نمی‌کند منطقی باشد. مدل ممکن است جمع زمان‌ها را از بودجه بیشتر کند یا پروژه‌ی پایانی را پیش از یادگیری مبانی بگذارد. این خطاها را باید با کد پیدا کرد، نه با امید.

بررسی زمان و ترتیب پیش‌نیازها

تابع زیر دو بررسی اصلی را انجام می‌دهد: آیا جمع ساعت‌ها در بودجه جا می‌شود و آیا هر زیرکار بعد از پیش‌نیازهایش آمده است:

def validate_plan(plan: StudyPlan, weeks: int) -> list[str]:
    problems = []
    total = sum(t.hours for t in plan.tasks)
    budget = plan.weekly_hours * weeks
    if total > budget:
        problems.append(f"جمع زمان‌ها {total} ساعت است اما بودجه {budget} ساعت است.")
    seen = set()
    for task in plan.tasks:
        missing = [d for d in task.depends_on if d not in seen]
        if missing:
            problems.append(f"«{task.title}» پیش از پیش‌نیازهایش آمده است: {', '.join(missing)}")
        seen.add(task.id)
    return problems

اگر فهرست مشکلات خالی نبود، همان مشکلات را به‌عنوان بازخورد به مدل برمی‌گردانید و برنامه‌ی تازه می‌خواهید. این حلقه‌ی کوتاه، یعنی ساخت، بررسی و اصلاح، کیفیت برنامه را به‌شدت بالا می‌برد. همان الگوی سازنده و بازرس است که در قسمت قبل دیدیم.

زمان مرور را فراموش نکنید

یک خطای رایج در برنامه‌های مطالعه، نبود زمان مرور و تمرین است. برنامه‌ای که ۱۰۰ درصد زمان را به مطالب تازه بدهد، در عمل از هفته‌ی سوم عقب می‌افتد. در پرامپت برنامه‌ریز صریحاً بخواهید حدود یک‌پنجم زمان را برای مرور و تمرین کنار بگذارد.

همین قاعده را می‌توان در اعتبارسنجی هم اضافه کرد. اگر هیچ زیرکاری با برچسب مرور وجود نداشت، برنامه را برگردانید. جدول زیر یک برنامه‌ی نمونه‌ی خوب را نشان می‌دهد.

برنامه‌ریزی دوباره

برخی کارها به رفت‌وبرگشت نیاز دارند؛ نتیجه‌ی یک زیرکار روی زیرکار بعدی اثر می‌گذارد. مثلاً اگر ایجنت هنگام رزرو پرواز با داده‌ی غیرمنتظره‌ای روبه‌رو شود، باید پیش از رفتن سراغ رزرو هتل، راهبردش را تغییر دهد.

وقتی کاربر عقب می‌افتد

در برنامه‌ی مطالعه هم همین اتفاق می‌افتد. دانشجو در هفته‌ی پنجم متوجه می‌شود از برنامه دو هفته عقب است. یا ترجیح تازه‌ای دارد؛ مثلاً می‌خواهد به‌جای نمودارسازی، زودتر سراغ پروژه برود. در این حالت‌ها برنامه‌ی فعلی، پیشرفت واقعی و تغییرها همراه هم به برنامه‌ریز داده می‌شوند.

برنامه‌ریز نباید از صفر شروع کند؛ باید کارهای انجام‌شده را نگه دارد و فقط بخش باقی‌مانده را اصلاح کند. برای کارهای بسیار پیچیده‌تر، سیستم‌هایی مثل Magentic-One مایکروسافت نشان می‌دهند یک ایجنت هماهنگ‌کننده چطور می‌تواند برنامه را در طول کار بارها بازبینی کند.

سناریوی عملی؛ برنامه‌ی مطالعه‌ی دانشجو

دانشجویی هفته‌ای چهار ساعت وقت دارد و می‌خواهد اول مبانی پایتون و بعد تحلیل داده یاد بگیرد. نمودار زیر چرخه‌ی کامل برنامه‌ریزی برای این هدف را نشان می‌دهد.

ورودی و معیار پذیرش

ورودی آزمون چهار بخش دارد: هدف، زمان آزاد، دانش قبلی و پیش‌نیازهای دوره‌ها. یک نمونه‌ی ناقص هم بگذارید؛ مثلاً دانشجویی که زمان آزادش را نگفته است. در این حالت برنامه‌ریز باید بپرسد، نه حدس بزند.

اقدام مورد بررسی، ساخت برنامه‌ی مرحله‌ای با زمان تقریبی و وابستگی میان فعالیت‌هاست. معیار پذیرش دو بخش دارد: جمع زمان‌ها با بودجه سازگار باشد و ترتیب پیش‌نیازها رعایت شود.

نمونه‌ی شکست

شکستی که باید عمداً دنبالش بگردید این است: پروژه‌ی پیشرفته پیش از مهارت‌های لازم قرار بگیرد، یا زمان مرور نادیده گرفته شود. این دو خطا برنامه را جذاب اما غیرقابل اجرا می‌کنند.

تابع validate_plan خطای اول را پیدا می‌کند. برای خطای دوم، قاعده‌ی زمان مرور را اضافه کنید. بعد عمداً برنامه‌ای بدون مرور یا با ترتیب اشتباه بسازید و مطمئن شوید رد می‌شود.

تمرین عملی؛ برنامه‌ی مطالعه با روش اصلاح

خروجی این تمرین یک برنامه‌ی مطالعه‌ی ساختاریافته همراه روش اصلاح پس از عقب افتادن است:

1. طرح‌واره‌ی StudyPlan را تعریف کنید و با responses.parse یک برنامه بسازید.
2. برنامه را با validate_plan بسنجید و اگر مشکلی بود، مشکلات را به مدل برگردانید تا اصلاح کند.
3. سناریوی «دو هفته عقب افتادن» را شبیه‌سازی کنید و برنامه‌ی اصلاح‌شده را با برنامه‌ی اول مقایسه کنید.

مشخص کنید کدام بخش را واقعاً اجرا کرده‌اید و کدام هنوز فرض است.

سخن پایانی

برنامه‌ریزی ایجنت با یک هدف روشن شروع می‌شود و با تجزیه‌ی کار به زیرکارهای مدیریت‌پذیر ادامه پیدا می‌کند. خروجی ساختاریافته برنامه را برای کد قابل‌خواندن می‌کند، اعتبارسنجی با کد جلوی برنامه‌های غیرقابل اجرا را می‌گیرد و برنامه‌ریزی دوباره، برنامه را با واقعیت هماهنگ نگه می‌دارد. برنامه‌ی خوب برنامه‌ای است که اجرا شود، نه برنامه‌ای که فقط خوب به نظر برسد.

در قسمت بعد تقسیم مسئولیت در سیستم‌های چندایجنتی را می‌بینیم؛ تحویل کار میان ایجنت‌ها بدون گم شدن زمینه.

این آموزش بر پایه‌ی درس Planning Design از مجموعه‌ی آزاد AI Agents for Beginners مایکروسافت (مجوز MIT) به فارسی بازنویسی و تکمیل شده است.