ساخت تیم چند Agent با AutoGen؛ چه زمانی Multi-Agent بهتر از یک Agent است؟

این سؤال، نقطه شروع طراحی سیستم‌های Multi-Agent است. در چنین سیستم‌هایی، چند Agent با نقش‌های متفاوت با یکدیگر همکاری می‌کنند. برای مثال، Agent اول اطلاعات را جمع‌آوری می‌کند، Agent دوم آن‌ها را تحلیل می‌کند و Agent سوم کیفیت نتیجه را بررسی می‌کند.

یکی از فریم‌ورک‌هایی که این معماری را رایج کرد، AutoGen مایکروسافت است. AutoGen با قابلیت‌هایی مانند AgentChat، Core، Teams و ابزارهای مدیریت گفتگو، امکان تعریف Agentهای متخصص و هماهنگ کردن آن‌ها را فراهم می‌کند.

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

در این مقاله ساخت یک AutoGen Multi Agent را با Python روی VPS آموزش می‌دهیم. ابتدا تفاوت AgentChat و Core را بررسی می‌کنیم، سپس تیم سه‌نقشی برای تهیه و بازبینی گزارش وضعیت یک سرویس آزمایشی می‌سازیم. در ادامه، الگوهای Teams، شرط‌های توقف، جداسازی Toolها، هزینه Token، خطاهای رایج و نحوه انتخاب میان Single-Agent و Multi-Agent را توضیح خواهیم داد.

AutoGen چیست و سیستم Multi-Agent چگونه کار می‌کند؟

AutoGen یک فریم‌ورک متن‌باز برای ساخت برنامه‌های مبتنی بر Agentهای هوش مصنوعی است که ابتدا در Microsoft Research توسعه پیدا کرد.

در معماری Multi-Agent، به‌جای سپردن تمام وظایف به یک Agent، می‌توان کار را میان چند Agent با دستورالعمل‌ها، ابزارها و مسئولیت‌های مختلف تقسیم کرد.

برای مثال، تیمی را در نظر بگیرید که وظیفه‌اش تهیه گزارش درباره یک سرویس آزمایشی است:

در این معماری، هر Agent می‌تواند از مدل مشابه یا متفاوتی استفاده کند و لزوماً نیازی نیست تمام Agentها به ابزارهای یکسان دسترسی داشته باشند.

آیا Multi-Agent یعنی چند مدل متفاوت؟

خیر. می‌توان سه Agent با نقش‌های متفاوت ساخت که همگی از یک مدل زبانی استفاده می‌کنند. تفاوت آن‌ها ممکن است فقط در System Message، ابزارها، محدوده داده و جایگاهشان در گردش کار باشد.

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

آیا Agentها باید روی سرورهای جداگانه اجرا شوند؟

خیر. در یک نمونه ساده، تمام Agentها می‌توانند در یک فرآیند Python روی یک VPS اجرا شوند.

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

تفاوت Single-Agent با Multi-Agent چیست؟

Single-Agent یک Agent اصلی دارد که خودش تصمیم می‌گیرد چه ابزارهایی را فراخوانی کند و چگونه نتیجه را آماده کند.

در Multi-Agent، مسئولیت میان چند Agent تقسیم می‌شود و یک سازوکار هماهنگ‌کننده، ترتیب یا مسیر ارتباط آن‌ها را تعیین می‌کند.

آیا Multi-Agent همیشه پاسخ دقیق‌تری تولید می‌کند؟

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

کیفیت نتیجه باید با آزمون واقعی اندازه‌گیری شود؛ نه با تعداد Agentهای موجود در معماری.

یک مثال عملی

اگر کاربر فقط می‌خواهد بداند وضعیت یک سرویس آنلاین است یا خیر، احتمالاً یک Agent با Tool مناسب کافی است.

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

چه زمانی ساخت چند Agent بهتر از یک Agent است؟

پیش از انتخاب Multi-Agent، باید مشخص کنید مشکل اصلی پروژه چیست.

۱. وقتی وظایف به تخصص‌های متفاوت نیاز دارند

برای مثال، یک پروژه می‌تواند شامل تحلیل امنیتی، بررسی عملکرد و تهیه گزارش مدیریتی باشد. داشتن Agentهای جداگانه با دستورالعمل‌های تخصصی ممکن است طراحی و ارزیابی را ساده‌تر کند.

۲. وقتی ابزارها باید از یکدیگر جدا باشند

Agent خواندن لاگ نباید الزاماً مجوز تغییر Firewall داشته باشد. تقسیم ابزارها بین نقش‌ها می‌تواند از اعطای دسترسی غیرضروری جلوگیری کند؛ البته فقط زمانی که مجوز در Backend نیز واقعاً اجرا شود.

۳. وقتی بازبینی خروجی ارزش مشخصی دارد

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

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

۴. وقتی چند کار مستقل قابل انجام هستند

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

توجه کنید که RoundRobinGroupChat به‌صورت پیش‌فرض پردازش Agentها را به ترتیب نوبت انجام می‌دهد، نه اینکه تمام کارها را موازی اجرا کند.

۵. وقتی یک Agent بیش از حد پیچیده شده است

اگر System Prompt طولانی، تعداد Toolها زیاد و انتخاب مسیر اجرا دشوار شده است، ممکن است تفکیک وظایف به Agentهای محدودتر مفید باشد.

اما پیش از این تصمیم، ساده‌سازی Prompt، کم کردن ابزارهای غیرضروری و استفاده از Workflow قطعی را امتحان کنید.

چه زمانی Multi-Agent انتخاب مناسبی نیست؟

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

وضعیت فعلی AutoGen؛ آیا هنوز برای پروژه جدید مناسب است؟

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

مخزن رسمی AutoGen اعلام کرده این پروژه دیگر به شکل قبلی توسط مایکروسافت توسعه داده نمی‌شود و برای ساخت برنامه‌های جدید، Microsoft Agent Framework توصیه شده است.

بنابراین بهتر است میان دو نوع پروژه تفاوت بگذاریم:

• پروژه موجود AutoGen: می‌توان کد فعلی را نگهداری، مستندسازی و برای مهاجرت برنامه‌ریزی کرد.
• پروژه آموزشی یا تحقیقاتی: AutoGen همچنان برای شناخت Teams، AgentChat و Core مفید است.
• پروژه Production جدید: بهتر است ابتدا Microsoft Agent Framework و سایر گزینه‌های دارای پشتیبانی فعال ارزیابی شوند.

این تفاوت اهمیت دارد؛ زیرا وجود مستندات آنلاین یا نصب موفق بسته Python به معنی دریافت قابلیت‌های جدید و رفع امنیتی بلندمدت نیست.

مخزن رسمی AutoGen در GitHub

راهنمای رسمی مهاجرت AutoGen به Microsoft Agent Framework

تفاوت AutoGen AgentChat و AutoGen Core چیست؟

AutoGen دو سطح مهم برای توسعه سیستم‌های Agentمحور دارد.

AgentChat؛ مناسب شروع و ساخت Teamهای آماده

AgentChat رابط سطح‌بالاتری فراهم می‌کند که با آن می‌توانید AssistantAgent، Team و شرط‌های توقف را تعریف کنید.

برای مثال، ایجاد یک تیم با RoundRobinGroupChat به چند خط کد نیاز دارد:

team = RoundRobinGroupChat(
    participants=[researcher, analyst, reviewer],
    termination_condition=stop_condition,
)

این شیوه برای نمونه‌سازی، آزمایش همکاری نقش‌ها و وظایف گفتگومحور مناسب است.

Core؛ مناسب معماری رویدادمحور

Core سطح پایین‌تری دارد و بر پیام‌رسانی، Agent Runtime، RoutedAgent و مدیریت رویدادها تکیه می‌کند.

در این معماری می‌توان Agentهایی طراحی کرد که پیام‌های مشخص را از طریق Runtime دریافت کنند و براساس نوع پیام پاسخ دهند.

نمونه مفهومی Core

from dataclasses import dataclass

from autogen_core import (
    MessageContext,
    RoutedAgent,
    message_handler,
)


@dataclass
class ReviewRequest:
    report: str


class ReviewAgent(RoutedAgent):
    @message_handler
    async def review(
        self,
        message: ReviewRequest,
        ctx: MessageContext,
    ) -> None:
        print("Review request received")

این مثال فقط تعریف نوع پیام و Handler را نشان می‌دهد. برای اجرای آن باید Runtime ساخته شود، Agent ثبت شود و پیام به آن ارسال شود.

هدف این بخش نمایش تفاوت مدل برنامه‌نویسی Core با AgentChat است، نه ساخت یک برنامه Core کامل.

کدام را انتخاب کنیم؟

انواع Team در AutoGen چه تفاوتی دارند؟

AgentChat چند الگوی آماده برای هماهنگی Agentها ارائه می‌کند.

RoundRobinGroupChat

Agentها به ترتیب مشخص نوبت می‌گیرند. برای مثال، Researcher، سپس Analyst و سپس Reviewer پاسخ می‌دهند.

این روش زمانی مناسب است که می‌دانید ترتیب نقش‌ها چگونه باید باشد.

SelectorGroupChat

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

اما انتخاب Agent بعدی ممکن است به فراخوانی‌های اضافی مدل نیاز داشته باشد و هزینه را افزایش دهد.

Swarm

در Swarm، انتقال کنترل میان Agentها با Handoff انجام می‌شود.

برای مثال، Agent پشتیبانی ممکن است بر اساس نوع درخواست، کار را به Agent فنی یا مالی واگذار کند.

MagenticOneGroupChat

این الگو برای حل وظایف باز و چندمرحله‌ای طراحی شده است که نیازمند برنامه‌ریزی و همکاری چند Agent هستند.

چنین معماری‌ای از یک Team ساده RoundRobin پیچیده‌تر است و باید محدودیت تعداد مراحل، هزینه و شکست عملیات به‌دقت تنظیم شود.

GraphFlow

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

با توجه به وضعیت نگهداری AutoGen، پیش از استفاده جدید از GraphFlow در Production باید قابلیت متناظر آن را در Microsoft Agent Framework نیز بررسی کنید.

معماری تیم نمونه AutoGen روی VPS

در نمونه عملی، سه Agent خواهیم داشت:

• Researcher: اطلاعات یک سرویس آزمایشی را از Tool فقط‌خواندنی دریافت می‌کند.
• Analyst: داده‌ها را تحلیل و نتیجه اولیه را آماده می‌کند.
• Reviewer: بررسی می‌کند گزارش با داده‌های ارائه‌شده سازگار باشد و محدودیت‌ها را مشخص کند.

گردش کار ما به شکل زیر است:

User Task
   |
Researcher
   |  Read-only demo tool
   v
Analyst
   |  Interpret available evidence
   v
Reviewer
   |  Check accuracy and limitations
   v
TaskResult
   |
External Result Verification

در این مثال، تمام اطلاعات ساختگی و آزمایشی هستند و هیچ API مدیریتی واقعی فراخوانی نمی‌شود.

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

پیش‌نیازهای اجرای AutoGen Multi Agent روی VPS

برای این آموزش از Ubuntu 24.04 LTS و Python استفاده می‌کنیم. مدل‌ها از طریق API فراخوانی می‌شوند؛ بنابراین اجرای همین نمونه به GPU محلی احتیاج ندارد.

این اعداد برآورد اولیه برای برنامه Python و ابزارهای محلی هستند، نه حداقل رسمی AutoGen. مصرف واقعی با تعداد Teamها، ابزارها، فایل‌ها و درخواست‌های هم‌زمان تغییر می‌کند.

نکته درباره مصرف منابع

اگر از OpenAI API استفاده می‌کنید، افزایش RAM یا CPU VPS به‌تنهایی تعداد Token مصرف‌شده مدل را کاهش نمی‌دهد.

اما اگر چند Worker، ابزار تحلیل فایل، مرورگر Headless یا دیتابیس محلی داشته باشید، منابع بیشتر می‌توانند ظرفیت اجرای هم‌زمان را افزایش دهند.

مرحله اول: نصب AutoGen و کتابخانه‌های لازم روی Ubuntu VPS

نصب Python و ابزارهای پایه

sudo apt update

sudo apt install -y \
python3 \
python3-venv \
python3-pip \
ca-certificates

ساخت پروژه

mkdir -p ~/autogen-multi-agent
cd ~/autogen-multi-agent

python3 -m venv .venv

.venv/bin/python -m pip install --upgrade pip

نصب AgentChat و OpenAI Extension

برای سازگاری بهتر با مثال‌های این مقاله، نسخه AgentChat را روی انتشار 0.7.5 ثابت می‌کنیم. این نسخه در PyPI منتشر شده و برای بازتولید آموزش استفاده می‌شود، نه به‌عنوان توصیه به آغاز پروژه جدید با AutoGen.

.venv/bin/python -m pip install \
"autogen-agentchat==0.7.5" \
"autogen-ext[openai]==0.7.5"

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

بررسی نصب

.venv/bin/python -m pip show autogen-agentchat

.venv/bin/python -m pip check

تنظیم API Key

برای اجرای Agentهای متصل به OpenAI، یک API Key معتبر لازم دارید.

export OPENAI_API_KEY="YOUR_OPENAI_API_KEY"

export AUTOGEN_MODEL="gpt-4o-mini"

مدل gpt-4o-mini در این مثال صرفاً یک انتخاب سازگار با الگوی Chat Completions است. می‌توانید مدل را با یک مدل پشتیبانی‌شده و فعال در پروژه API خود جایگزین کنید، اما باید سازگاری Model Client و قابلیت Tool Calling را آزمایش کنید.

برای محیط عملیاتی، API Key را داخل کد یا مخزن Git قرار ندهید و از روش محافظت‌شده مدیریت Secrets استفاده کنید.

مرحله دوم: ساخت تیم سه‌Agent با AutoGen AgentChat

اکنون یک برنامه Python می‌نویسیم که وضعیت یک سرویس آزمایشی را بررسی و گزارش کند.

تنها Researcher به Tool دسترسی خواهد داشت. Analyst و Reviewer هیچ ابزاری برای خواندن فایل، اجرای فرمان یا تغییر سرویس دریافت نمی‌کنند.

ساخت فایل multi_agent.py

nano ~/autogen-multi-agent/multi_agent.py

کد کامل پروژه

import asyncio
import os

from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.conditions import MaxMessageTermination
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_core.model_context import (
    BufferedChatCompletionContext,
)
from autogen_ext.models.openai import (
    OpenAIChatCompletionClient,
)


ALLOWED_SERVICE = "demo-vps-01"


def read_demo_status(service_id: str) -> dict:
    """Return read-only status of the allowed demo service."""

    if service_id != ALLOWED_SERVICE:
        raise ValueError("Service is not allowed")

    return {
        "service_id": "demo-vps-01",
        "environment": "demo",
        "status": "online",
        "cpu_percent": 37,
        "memory_percent": 54,
        "players": 4,
        "warning": "No critical incident in demo data",
    }


async def main():
    model_client = OpenAIChatCompletionClient(
        model=os.getenv("AUTOGEN_MODEL", "gpt-4o-mini"),
        parallel_tool_calls=False,
        timeout=30,
    )

    try:
        researcher = AssistantAgent(
            name="researcher",
            model_client=model_client,
            tools=[read_demo_status],
            reflect_on_tool_use=True,
            max_tool_iterations=2,
            model_context=BufferedChatCompletionContext(
                buffer_size=8
            ),
            system_message=(
                "You are a read-only data researcher. "
                "Use read_demo_status for demo-vps-01. "
                "Do not invent measurements. "
                "Report only data actually returned. "
                "Write in Persian."
            ),
        )

        analyst = AssistantAgent(
            name="analyst",
            model_client=model_client,
            model_context=BufferedChatCompletionContext(
                buffer_size=8
            ),
            system_message=(
                "You are a technical analyst. "
                "Analyze only the evidence shared by researcher. "
                "Distinguish facts from hypotheses. "
                "Do not claim access to real servers. "
                "Write in Persian."
            ),
        )

        reviewer = AssistantAgent(
            name="reviewer",
            model_client=model_client,
            model_context=BufferedChatCompletionContext(
                buffer_size=8
            ),
            system_message=(
                "You are a quality reviewer. "
                "Check the preceding report against demo evidence. "
                "Mention unsupported claims and limitations. "
                "Return a concise final report in Persian. "
                "Do not execute any operations."
            ),
        )

        termination = MaxMessageTermination(
            max_messages=4
        )

        team = RoundRobinGroupChat(
            participants=[
                researcher,
                analyst,
                reviewer,
            ],
            termination_condition=termination,
        )

        result = await asyncio.wait_for(
            team.run(
                task=(
                    "برای سرویس آزمایشی demo-vps-01 "
                    "یک گزارش وضعیت با تحلیل و بازبینی تهیه کن. "
                    "هیچ تنظیمی را تغییر نده."
                )
            ),
            timeout=90,
        )

        print("STOP REASON:", result.stop_reason)

        for message in result.messages:
            if message.source in {
                "researcher",
                "analyst",
                "reviewer",
            }:
                if isinstance(message.content, str):
                    print(
                        f"\n[{message.source}]\n"
                        f"{message.content}\n"
                    )

    finally:
        await model_client.close()


if __name__ == "__main__":
    asyncio.run(main())

نقش Researcher در این کد چیست؟

Researcher تنها Agent دارای دسترسی به تابع read_demo_status است. این تابع فقط داده ثابت آزمایشی برمی‌گرداند و شناسه سرویس را با Allowlist بررسی می‌کند.

اگر شناسه‌ای غیر از demo-vps-01 ارسال شود، تابع خطا می‌دهد.

نقش Analyst چیست؟

Analyst براساس اطلاعاتی که در گفتگو دریافت می‌کند، تحلیل ارائه می‌دهد.

این Agent هیچ Tool مستقلی ندارد و نباید ادعا کند مستقیماً وضعیت واقعی سرور را بررسی کرده است.

نقش Reviewer چیست؟

Reviewer وظیفه بررسی سازگاری گزارش با داده‌های موجود را دارد.

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

چرا از MaxMessageTermination استفاده کردیم؟

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

مقدار max_messages=4 برای پیام اولیه کاربر و سه پاسخ Agent در نظر گرفته شده است. استفاده از سقف پیام، خطر ادامه نامحدود گفتگو را کاهش می‌دهد.

اگر Agentها پیام‌های داخلی یا Tool Event تولید کنند، نحوه شمارش باید با رفتار واقعی نسخه SDK بررسی شود؛ بنابراین خروجی را با result.stop_reason نیز کنترل می‌کنیم.

مرحله سوم: اجرای تیم AutoGen و بررسی خروجی

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

cd ~/autogen-multi-agent

.venv/bin/python multi_agent.py

اگر API Key معتبر باشد و Model Client به مدل انتخاب‌شده دسترسی داشته باشد، برنامه گفتگو را اجرا می‌کند و پیام‌های Agentها را نمایش می‌دهد.

خروجی مورد انتظار

در یک اجرای موفق، Researcher باید داده‌های آزمایشی را گزارش کند؛ Analyst تحلیل خود را بر همان داده‌ها بنا کند و Reviewer محدودیت‌ها و نتیجه نهایی را اعلام کند.

نمونه محتوای منطقی گزارش می‌تواند چنین باشد:

سرویس آزمایشی demo-vps-01 با وضعیت online گزارش شده است. مقدار CPU برابر ۳۷ درصد و مصرف حافظه برابر ۵۴ درصد است. در داده آزمایشی نشانه‌ای از حادثه بحرانی ثبت نشده است؛ بااین‌حال این اطلاعات مربوط به محیط تست بوده و وضعیت سرور واقعی را نشان نمی‌دهند.

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

چگونه بفهمیم Team درست کار کرده است؟

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

برای پروژه واقعی بهتر است نتیجه را با تست‌های خودکار و معیارهای مشخص مقایسه کنید.

Termination در AutoGen؛ چگونه جلوی گفتگوی بی‌پایان Agentها را بگیریم؟

یکی از مشکلات رایج Multi-Agent این است که Agentها ممکن است بارها پاسخ یکدیگر را بررسی کنند، بدون اینکه به نتیجه جدیدی برسند.

این رفتار می‌تواند زمان اجرا و هزینه Token را افزایش دهد.

MaxMessageTermination

با این شرط، Team پس از تعداد مشخصی پیام متوقف می‌شود.

termination = MaxMessageTermination(max_messages=8)

TextMentionTermination

این شرط زمانی فعال می‌شود که یک متن مشخص در پیام‌های Agent مشاهده شود.

from autogen_agentchat.conditions import (
    MaxMessageTermination,
    TextMentionTermination,
)

termination = (
    TextMentionTermination("REPORT_COMPLETE")
    | MaxMessageTermination(max_messages=10)
)

در این روش می‌توان به Reviewer دستور داد پس از پایان بررسی عبارت REPORT_COMPLETE را تولید کند.

اما نباید این عبارت را به‌تنهایی اثبات موفقیت واقعی عملیات در نظر گرفت. مدل ممکن است عبارت را زودتر یا در متن نامناسب تولید کند.

برای عملیات حساس، وضعیت موفقیت باید توسط برنامه یا Backend مستقل تأیید شود.

TokenUsageTermination

این شرط برای متوقف کردن Team براساس مصرف گزارش‌شده Token کاربرد دارد.

اما به گزارش مصرف توسط Agentها وابسته است و به‌تنهایی یک کنترل قطعی هزینه در سطح ارائه‌دهنده API محسوب نمی‌شود.

TimeoutTermination و Timeout بیرونی

می‌توانید شرط زمانی خود AutoGen را تعریف کنید و علاوه بر آن، در سطح برنامه از asyncio.wait_for استفاده کنید.

اگر یک Tool خارجی فراخوانی شود، باید Timeout همان Tool را نیز جداگانه تنظیم کنید.

ExternalTermination

این شرط امکان درخواست توقف از بیرون Team را فراهم می‌کند.

برای مثال، در یک پنل مدیریتی می‌توان دکمه «توقف اجرای Agent» ایجاد کرد.

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

قانون مهم برای Production

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

یک شرط Termination واحد نمی‌تواند تمام سناریوهای شکست و افزایش مصرف را پوشش دهد.

Tool Isolation؛ چگونه ابزارهای هر Agent را جدا کنیم؟

در یک سیستم Multi-Agent، تفکیک نقش‌ها زمانی ارزش امنیتی دارد که دسترسی ابزارها نیز واقعاً جدا باشد.

اگر تمام Agentها با یک کلید مدیریتی به تمام Backendها دسترسی داشته باشند، تفاوت نام و System Prompt امنیت قابل اتکایی ایجاد نمی‌کند.

اصل حداقل دسترسی

برای مثال، Researcher فقط مجوز خواندن وضعیت را دریافت کند، Analyst فقط داده را تحلیل کند و Reviewer صرفاً خروجی را بررسی کند.

اگر Tool مدیریتی مانند restart_server نیاز است، باید در یک Executor مستقل با کنترل مجوز و تأیید مناسب قرار گیرد.

نمونه Tool با Allowlist

ALLOWED_SERVICES = {
    "demo-vps-01",
    "demo-vps-02",
}


def get_demo_service(service_id: str) -> dict:
    """Read only an allowed demo service."""

    if service_id not in ALLOWED_SERVICES:
        raise PermissionError("Access denied")

    return {
        "service_id": service_id,
        "environment": "demo",
    }

در این مثال، مجوز در خود تابع کنترل می‌شود و صرفاً در دستورالعمل Agent تعریف نشده است.

آیا ابزارهای Agent دیگر کاملاً مخفی می‌مانند؟

در GroupChat، Agentها ممکن است بخش‌هایی از پیام‌ها یا خروجی یکدیگر را دریافت کنند. بنابراین جداسازی دسترسی Toolها لزوماً به معنی جداسازی کامل اطلاعات و زمینه گفتگو نیست.

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

خطر Prompt Injection میان Agentها

اگر Researcher محتوای یک سایت یا سند خارجی را بخواند، ممکن است آن محتوا شامل دستورهای مخرب باشد.

Analyst و Reviewer نباید این دستورها را به‌عنوان سیاست جدید سیستم تلقی کنند.

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

خطر Code Execution

AutoGen ابزارهایی برای اجرای کد نیز دارد. اگر یک Agent قرار است Python یا Shell تولید کند، اجرای آن مستقیماً روی VPS اصلی با دسترسی مدیریتی خطرناک است.

برای چنین سناریوهایی باید از Sandbox یا کانتینر با کاربر غیر root، محدودیت شبکه و دسترسی فایل استفاده شود.

استفاده از DockerCommandLineCodeExecutor می‌تواند بخشی از معماری ایزولاسیون باشد، اما تنظیمات Docker و مجوزهای Volume همچنان باید بررسی شوند.

تأیید انسانی برای ابزارهای حساس

اگر Tool توانایی حذف داده، پرداخت، انتشار محتوا یا تغییر تنظیمات سرور را دارد، بهتر است پیش از اجرای اثر جانبی تأیید معتبر دریافت شود.

مراحل ساخت چنین سیستمی در مقاله آموزش Human-in-the-Loop برای AI Agent به‌صورت جداگانه بررسی شده است.

هزینه Token در AutoGen Multi-Agent چگونه محاسبه می‌شود؟

یکی از مهم‌ترین معیارهای انتخاب Multi-Agent، هزینه واقعی اجرای هر کار است.

هر بار که یک Agent مدل را فراخوانی می‌کند، ممکن است Token ورودی و خروجی مصرف شود.

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

مثال محاسبه هزینه

فرض کنید یک Agent با یک درخواست، ۳۰۰۰ Token ورودی و ۶۰۰ Token خروجی مصرف می‌کند.

حالا اگر یک تیم سهAgent در مجموع ۵ فراخوانی مدل داشته باشد، مصرف کل لزوماً پنج برابر نیست؛ زیرا حجم Context در هر فراخوانی متفاوت است.

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

فرمول کلی:

\(\text{Cost} = \frac{\text{Input Tokens} \times \text{Input Price} + \text{Output Tokens} \times \text{Output Price}}{1{,}000{,}000}\)

در این فرمول، قیمت‌ها باید براساس تعرفه واقعی هر مدل و هر نوع Token در زمان اجرا وارد شوند.

نمونه محاسبه Token از پیام‌های Team

AutoGen می‌تواند اطلاعات مصرف مدل را همراه پیام‌ها برگرداند. در نمونه زیر مصرف گزارش‌شده پیام‌ها را جمع می‌کنیم:

prompt_tokens = 0
completion_tokens = 0

for message in result.messages:
    usage = getattr(
        message,
        "models_usage",
        None,
    )

    if usage is not None:
        prompt_tokens += usage.prompt_tokens
        completion_tokens += usage.completion_tokens

print("Input tokens:", prompt_tokens)
print("Output tokens:", completion_tokens)

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

برای حسابداری دقیق، مصرف گزارش‌شده Model Client و داده‌های صورتحساب API را نیز بررسی کنید.

چگونه هزینه Multi-Agent را کاهش دهیم؟

• فقط Agentهایی را نگه دارید که ارزش مشخصی ایجاد می‌کنند.
• برای وظایف ساده از یک Agent یا کد معمولی استفاده کنید.
• پیام‌ها و Context غیرضروری را حذف کنید.
• برای مراحل ساده، مدل متناسب با پیچیدگی کار انتخاب کنید.
• از سقف مراحل و Timeout استفاده کنید.
• از SelectorGroupChat فقط در صورت نیاز به انتخاب پویای نقش استفاده کنید.
• خروجی ابزارها را خلاصه و ساختاریافته نگه دارید.
• برای درخواست‌های تکراری، در صورت مجاز بودن از Cache استفاده کنید.

BufferedChatCompletionContext چه کمکی می‌کند؟

در نمونه عملی از BufferedChatCompletionContext استفاده کردیم تا تعداد پیام‌های موجود در Context هر Agent محدود شود.

این کار می‌تواند از رشد نامحدود زمینه مدل جلوگیری کند؛ اما اگر پیام‌های ضروری حذف شوند، کیفیت تصمیم‌گیری کاهش می‌یابد.

بنابراین اندازه Buffer باید با وظیفه واقعی و تست کیفیت تنظیم شود.

آیا Multi-Agent سریع‌تر است؟

نه لزوماً. در RoundRobin، Agentها به ترتیب پاسخ می‌دهند و تأخیر آن‌ها جمع می‌شود.

برای کارهای واقعاً مستقل، اجرای موازی ممکن است زمان کل را کاهش دهد؛ اما هزینه Token همچنان وجود دارد و ممکن است رقابت بر سر منابع نیز افزایش یابد.

Failure Modes؛ خطاهای رایج در سیستم‌های Multi-Agent

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

۱. گفتگوی بی‌پایان Agentها

Researcher و Reviewer ممکن است مدام از یکدیگر اصلاحات جدید بخواهند، بدون اینکه نتیجه قابل توجهی ایجاد شود.

راهکار: سقف پیام، سقف زمان و معیار پایان مشخص تعریف کنید.

۲. تکرار خطای یک Agent توسط بقیه

اگر Agent اول داده اشتباه تولید کند، Agentهای بعدی ممکن است همان اطلاعات را معتبر فرض کنند.

راهکار: داده‌های خام را از استنتاج جدا کنید و نتیجه را در صورت امکان با منبع معتبر بررسی کنید.

۳. Role Confusion

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

راهکار: مسئولیت هر نقش را روشن کنید و خروجی مورد انتظار را به‌صورت ساختاریافته تعریف کنید.

۴. Tool Abuse

ممکن است Agent تلاش کند ابزاری را خارج از هدف موردنظر فراخوانی کند.

راهکار: مجوز و پارامترهای ابزار باید در Backend بررسی شوند، نه فقط در Prompt.

۵. Prompt Injection در پیام‌های مشترک

یک خروجی خارجی آلوده ممکن است در Context چند Agent منتشر شود.

راهکار: داده‌های خارجی را غیرقابل اعتماد بدانید و از ایجاد مجوز اجرایی براساس متن ورودی جلوگیری کنید.

۶. افزایش غیرمنتظره هزینه

Agentها ممکن است تعداد بیشتری پیام تولید کنند یا Selector برای تعیین نوبت‌ها فراخوانی اضافی انجام دهد.

راهکار: مصرف Token و تعداد فراخوانی‌ها را برای هر Job ثبت کنید و محدودیت بودجه داشته باشید.

۷. توقف یکی از Toolها

اگر یک API خارجی پاسخ ندهد، ممکن است کل Team منتظر بماند.

راهکار: Timeout، Retry کنترل‌شده و سیاست شکست مشخص تعریف کنید.

۸. تکرار عملیات خارجی بعد از Crash

ممکن است یک Tool خارجی اجرا شده باشد اما نتیجه آن در وضعیت ذخیره‌شده Agent ثبت نشده باشد.

راهکار: از Idempotency و بررسی نتیجه واقعی عملیات استفاده کنید. ذخیره Team State به‌تنهایی تضمین اجرای دقیقاً یک‌باره ایجاد نمی‌کند.

۹. ناهماهنگی نسخه Agentها

ممکن است Prompt یا Tool یک Agent تغییر کند ولی نسخه‌های دیگر همچنان روی قرارداد قدیمی کار کنند.

راهکار: ورودی و خروجی هر نقش را نسخه‌بندی کنید و تست سازگاری داشته باشید.

۱۰. دسترسی بیش از حد به اطلاعات

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

راهکار: پیام‌رسانی، Context و دسترسی داده را براساس حداقل نیاز طراحی کنید.

ذخیره و بازیابی وضعیت Team بعد از Restart

AutoGen قابلیت save_state و load_state برای Agentها و Teamها دارد.

با این قابلیت می‌توانید وضعیت گفتگو و اطلاعات داخلی Team را در فایل یا دیتابیس ذخیره کنید و بعداً آن را بازیابی کنید.

ذخیره State

import json
from pathlib import Path

state = await team.save_state()

state_path = Path("team-state.json")

state_path.write_text(
    json.dumps(state, ensure_ascii=False),
    encoding="utf-8",
)

بازیابی State

saved = json.loads(
    state_path.read_text(encoding="utf-8")
)

await team.load_state(saved)

این کد فرض می‌کند Team و Agentها با نام‌ها و ساختار سازگار از قبل ساخته شده‌اند.

آیا می‌توان وسط اجرای Team وضعیت را ذخیره کرد؟

مستندات AutoGen هشدار می‌دهند که ذخیره Team State هنگام اجرای هم‌زمان Team ممکن است وضعیت ناسازگار ایجاد کند.

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

آیا این روش جایگزین Crash Recovery کامل است؟

خیر. این روش State داخلی Agentها را حفظ می‌کند، اما عملیات خارجیِ انجام‌شده را به‌صورت خودکار به یک تراکنش پایدار تبدیل نمی‌کند.

اگر Tool قابلیت تغییر داده یا ارسال درخواست بیرونی دارد، باید وضعیت اجرایی، شناسه عملیات و نتیجه واقعی آن جداگانه ثبت شوند.

برای طراحی این قسمت می‌توانید مقاله AI Agent Persistence؛ بازیابی پس از Crash و Restart را مطالعه کنید.

لاگ و Tracing در سیستم چندAgent

در Single-Agent ممکن است بررسی متن گفتگو برای رفع مشکل کافی باشد؛ اما در Multi-Agent باید بدانید کدام Agent چه تصمیمی گرفته، چه ابزاری را فراخوانی کرده و چقدر زمان یا Token مصرف کرده است.

چه اطلاعاتی را ثبت کنیم؟

چرا فقط متن نهایی کافی نیست؟

ممکن است خروجی نهایی صحیح به نظر برسد، اما Agentها در مسیر اجرا چندین درخواست غیرضروری یا اشتباه انجام داده باشند.

برای ارزیابی واقعی باید هزینه، تعداد مراحل، کیفیت نتیجه و خطاهای داخلی را با هم بررسی کنید.

آیا همه پیام‌های Agentها باید در Log ذخیره شوند؟

خیر. پیام‌ها ممکن است شامل داده‌های مشتری یا اطلاعات محرمانه باشند.

بهتر است ثبت لاگ متناسب با هدف و سطح حساسیت انجام شود و Credentialها و اطلاعات خصوصی غیرضروری حذف شوند.

استقرار AutoGen Multi-Agent روی VPS؛ نکات Production

برای اجرای یک تیم آزمایشی، یک برنامه Python کافی است. اما سرویس Production به کنترل‌های بیشتری نیاز دارد.

اجرای بدون دسترسی root

برنامه بهتر است با کاربر Linux مستقل و حداقل دسترسی اجرا شود.

همچنین فایل API Key نباید در مسیرهای عمومی یا در دسترس سایر کاربران سیستم قرار داشته باشد.

مدیریت فرآیند با systemd

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

نمونه کلی یک واحد systemd برای Worker موجود:

[Unit]
Description=AutoGen Multi-Agent Worker
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=agentworker
Group=agentworker
WorkingDirectory=/opt/autogen-team
EnvironmentFile=/etc/autogen-team/agent.env

ExecStart=/opt/autogen-team/.venv/bin/python worker.py

Restart=on-failure
RestartSec=10

NoNewPrivileges=true
PrivateTmp=true

MemoryAccounting=true
CPUAccounting=true

[Install]
WantedBy=multi-user.target

این قالب فرض می‌کند فایل worker.py، کاربر agentworker و مسیرهای موردنظر قبلاً ساخته شده‌اند. فایل multi_agent.py آموزشی این مقاله یک Job را اجرا می‌کند و سپس پایان می‌یابد؛ بنابراین نباید بدون افزودن حلقه Worker یا Queue آن را مستقیماً جایگزین یک سرویس دائمی کنید.

کنترل هم‌زمانی

Agentها و Teamهای AutoGen وضعیت داخلی دارند. بنابراین نباید یک Team یا Agent State مشترک را بدون هماهنگی میان چند درخواست هم‌زمان استفاده کنید.

برای درخواست‌های مستقل، ایجاد Team مستقل یا استفاده از Workerهای دارای مالکیت Job روش مناسب‌تری است.

محدودیت شبکه ابزارها

اگر Toolها می‌توانند به APIهای داخلی یا اینترنت متصل شوند، فقط بررسی Prompt کافی نیست. بهتر است دسترسی خروجی فرآیند و Credentialهای هر ابزار نیز محدود شوند.

Backup و نسخه‌بندی

برای Teamهای دارای وضعیت پایدار، فایل یا دیتابیس State، نسخه Agentها، تعریف Toolها و تنظیمات لازم برای بازیابی باید محافظت و نسخه‌بندی شوند.

این موضوع برای پروژه‌ای که ممکن است بعداً به Microsoft Agent Framework مهاجرت کند اهمیت بیشتری دارد.

چگونه از AutoGen به Microsoft Agent Framework مهاجرت کنیم؟

مایکروسافت برای انتقال پروژه‌های AutoGen به Microsoft Agent Framework یک راهنمای رسمی منتشر کرده است.

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

معادل‌سازی اجزای اصلی

این جدول تطبیق مفهومی است؛ همه اجزا الزاماً جایگزینی یک‌به‌یک ندارند. بعضی الگوها هنگام مهاجرت باید بازطراحی شوند.

مراحل پیشنهادی مهاجرت

1. فهرست Agentها، نقش‌ها و Toolهای پروژه موجود را تهیه کنید.
2. تمام مسیرهای اجرای عملیات حساس را مشخص کنید.
3. قرارداد ورودی و خروجی هر Agent را مستند کنید.
4. معیارهای کیفیت، هزینه و تأخیر نسخه فعلی را اندازه‌گیری کنید.
5. یک نسخه آزمایشی از Workflow جدید بسازید.
6. رفتار نسخه جدید را با همان داده‌های تست مقایسه کنید.
7. Migration وضعیت‌های ذخیره‌شده و Jobهای نیمه‌تمام را جداگانه طراحی کنید.
8. پس از بررسی امنیت و سازگاری، ترافیک را مرحله‌ای منتقل کنید.

در زمان مهاجرت نباید فرض کرد فایل‌های save_state مربوط به AutoGen بدون تبدیل در Framework جدید قابل بازیابی هستند.

راهنمای رسمی مهاجرت مایکروسافت

AutoGen، Microsoft Agent Framework و OpenAI Agents SDK؛ کدام مناسب‌تر است؟

انتخاب فریم‌ورک به نوع پروژه و میزان کنترل موردنیاز بستگی دارد.

نباید فقط براساس محبوبیت یا تعداد ستاره‌های GitHub تصمیم گرفت. بهتر است یک وظیفه واقعی را در گزینه‌های مناسب پیاده‌سازی و نتیجه را براساس کیفیت، هزینه، امنیت و نگهداری مقایسه کنید.

برای شروع از صفر چه پیشنهادی داریم؟

اگر فقط به یک Agent با چند Tool و Handoff نیاز دارید، لازم نیست حتماً به یک سیستم Teamمحور مهاجرت کنید.

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

اگر پروژه‌ای با AutoGen دارید، مسیر مهاجرت رسمی را مطالعه کنید و بدون تست سازگاری، کد عملیاتی را ناگهان جایگزین نکنید.

سؤالات متداول درباره AutoGen Multi Agent

AutoGen Multi Agent چیست؟

روشی برای ساخت برنامه‌هایی است که چند Agent با نقش‌های متفاوت در آن همکاری می‌کنند و از طریق سازوکارهایی مانند AgentChat Teams یا Core با یکدیگر ارتباط دارند.

آیا AutoGen هنوز فعال است؟

مخزن رسمی AutoGen آن را آرشیوشده معرفی می‌کند و برای پروژه‌های جدید Microsoft Agent Framework را توصیه می‌کند.

آیا AutoGen برای یادگیری Multi-Agent مناسب است؟

بله. معماری AgentChat، Core و Teamهای آن همچنان نمونه‌های آموزشی مفیدی برای درک همکاری Agentها هستند.

AgentChat و Core چه تفاوتی دارند؟

AgentChat رابط سطح‌بالاتر برای ساخت Agent و Team است؛ Core چارچوب پایین‌تری برای پیام‌رسانی رویدادمحور و Agent Runtime فراهم می‌کند.

آیا Multi-Agent همیشه بهتر از Single-Agent است؟

خیر. برای کارهای ساده، Single-Agent معمولاً ساده‌تر و کم‌هزینه‌تر است. Multi-Agent زمانی مفید است که تقسیم نقش‌ها ارزش مشخصی ایجاد کند.

آیا هر Agent باید مدل متفاوتی داشته باشد؟

خیر. چند Agent می‌توانند از مدل یکسان با دستورالعمل‌ها و ابزارهای متفاوت استفاده کنند.

RoundRobinGroupChat چیست؟

الگویی است که در آن Agentها به ترتیب مشخص نوبت می‌گیرند و پیام‌های خود را در فضای مشترک Team منتشر می‌کنند.

SelectorGroupChat چه مزیتی دارد؟

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

Swarm در AutoGen چیست؟

الگویی برای انتقال کنترل بین Agentها از طریق پیام‌های Handoff است.

Magentic-One چیست؟

یک الگوی هماهنگ‌سازی چندAgent برای وظایف باز و پیچیده است که به برنامه‌ریزی و همکاری نیاز دارند.

چگونه جلوی گفتگوی بی‌پایان Agentها را بگیریم؟

با تعریف MaxMessageTermination، محدودیت زمانی، سقف Token و سیاست پایان مشخص.

آیا عبارت TERMINATE برای توقف کافی است؟

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

آیا AutoGen امکان استفاده از Tool دارد؟

بله. هر AssistantAgent می‌تواند توابع Python یا ابزارهای پشتیبانی‌شده دریافت کند.

چگونه Toolها را میان Agentها جدا کنیم؟

برای هر Agent فقط ابزارهای لازم را تعریف کنید و کنترل مجوز را در Backend نیز اعمال کنید.

آیا چند Agent امنیت بیشتری ایجاد می‌کنند؟

صرف چندAgent بودن امنیت را افزایش نمی‌دهد. جداسازی واقعی Credential، مجوز و اطلاعات لازم است.

آیا AutoGen امکان اجرای کد Python دارد؟

بله، اما اجرای کد تولیدشده توسط مدل باید در محیط Sandbox و با محدودیت‌های امنیتی مناسب انجام شود.

هزینه Multi-Agent چقدر است؟

هزینه به تعداد فراخوانی مدل، مصرف Token ورودی و خروجی، نوع مدل و طول گفتگو بستگی دارد.

آیا Multi-Agent مصرف Token بیشتری دارد؟

اغلب ممکن است چنین باشد، زیرا Agentها چندین بار مدل را فراخوانی می‌کنند و پیام‌های قبلی را به‌عنوان Context دریافت می‌کنند.

چگونه هزینه Token را کاهش دهیم؟

با کاهش Agentهای غیرضروری، محدود کردن Context، کنترل مراحل و انتخاب مدل متناسب با وظیفه.

آیا اجرای Multi-Agent به GPU نیاز دارد؟

اگر مدل‌ها از طریق API فراخوانی شوند، برای اجرای خود برنامه معمولاً GPU محلی لازم نیست.

آیا می‌توان چند Team را روی یک VPS اجرا کرد؟

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

آیا AutoGen وضعیت Team را ذخیره می‌کند؟

AgentChat قابلیت save_state و load_state دارد که می‌توان از آن برای ذخیره و بازیابی وضعیت سازگار Team استفاده کرد.

آیا Team State تضمین می‌کند Tool دوباره اجرا نشود؟

خیر. برای عملیات خارجی به Idempotency و بررسی نتیجه واقعی نیاز دارید.

آیا می‌توان AutoGen را به Microsoft Agent Framework منتقل کرد؟

بله. مایکروسافت راهنمای رسمی مهاجرت منتشر کرده است، اما بعضی الگوها و ساختارهای State به بازطراحی نیاز دارند.

برای پروژه جدید AutoGen بهتر است یا Microsoft Agent Framework؟

با توجه به وضعیت فعلی نگهداری AutoGen، برای پروژه جدید بهتر است ابتدا Microsoft Agent Framework را ارزیابی کنید.

جمع‌بندی

ساخت AutoGen Multi Agent می‌تواند برای پروژه‌هایی مفید باشد که به همکاری چند نقش تخصصی، بازبینی نتیجه یا تقسیم ابزارها نیاز دارند.

در این مقاله تفاوت Single-Agent و Multi-Agent را بررسی کردیم و با AgentChat یک تیم سه‌نقشی ساختیم که اطلاعات یک سرویس آزمایشی را دریافت می‌کند، آن را تحلیل می‌کند و نتیجه را مورد بازبینی قرار می‌دهد.

همچنین توضیح دادیم که استفاده از چند Agent لزوماً دقت یا سرعت را افزایش نمی‌دهد. تعداد فراخوانی‌های مدل، حجم Context، پیچیدگی Debugging و احتمال خطاهای هماهنگی ممکن است افزایش یابند.

برای کنترل این مشکلات باید Termination مشخص، محدودیت هزینه، جداسازی Toolها، ثبت رخدادها و تست کیفیت وجود داشته باشد.

از طرف دیگر، به‌دلیل تغییر وضعیت توسعه AutoGen، برای ساخت پروژه جدید باید مسیر Microsoft Agent Framework را جدی بررسی کنید.

نتیجه نهایی: از ساده‌ترین معماری‌ای شروع کنید که نیاز شما را برطرف می‌کند. Multi-Agent زمانی انتخاب بهتری است که بتوانید بهبود کیفیت، جداسازی مسئولیت یا ارزش عملی آن را در تست واقعی نشان دهید.

اگر هنوز با مفهوم Agent و Tool آشنا نیستید، ابتدا مقاله آموزش ساخت AI Agent با OpenAI Agents SDK روی VPS را مطالعه کنید.