برچسب: طراحی سیستم AI

تفکیک مسئولیت و کنترل، به‌جای شمارش مدل‌ها یا Agent‌ها

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

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

    در موج جدید AI، وسوسه‌ای طبیعی وجود دارد: یک مسئلهٔ پیچیده را به چند Agent تقسیم کنیم. انتظار داریم با افزایش تعداد Agent‌ها، خروجی هم بهتر گردد.

    اما هر Agent جدید فقط یک «نیروی کار دیجیتال» اضافه نمی‌کند. یک نقطهٔ تازه برای هماهنگی، انتقال context، کنترل دسترسی، ارزیابی، خطا و تصمیم‌گیری هم ایجاد می‌کند.

    چرا این پرسش امروز مهم‌تر از قبل است؟

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

    OpenAI در معرفی Agents API بر harness، استفاده از ابزار و هماهنگی subagent‌ها تأکید می‌کند. Salesforce نیز در سپتامبر ۲۰۲۶ از معماری سازمانی برای هماهنگی Agent‌ها و کنترل آن‌ها سخن می‌گوید.

    بنابراین معیار درست دیگر «چند Agent داریم؟» نیست. پرسش مهم‌تر آن است که هر Agent چه مسئولیتی دارد و آیا افزودن آن، نتیجه را بهتر از هزینهٔ هماهنگی آن می‌کند؟

    چه زمانی «بیشتر» را با «بهتر» اشتباه می‌گیریم؟

    یک workflow ساده ممکن است با یک Agent به‌خوبی کار کند. بعد مسئله پیچیده‌تر می‌گردد: یکی برای تحقیق، یکی برای برنامه‌ریزی، یکی برای اجرا و دیگری برای کنترل کیفیت اضافه می‌گردد.

    روی کاغذ، تقسیم کار منطقی به نظر می‌رسد. اما حالا سیستم باید بداند:

    • چه کسی تصمیم می‌گیرد؟
    • چه کسی خروجی دیگری را بررسی می‌کند؟
    • context چگونه منتقل می‌گردد؟
    • اگر دو Agent نتیجهٔ متفاوت دادند، چه اتفاقی می‌افتد؟
    • چه کسی مسئول خطای نهایی است؟

    از اینجا به بعد، بخشی از بهره‌وری بالقوهٔ Agent‌ها صرف مدیریت خودِ Agent‌ها می‌گردد.

    پژوهش مستقلی دربارهٔ orchestration چند-Agent نیز نشان می‌دهد اضافه‌کردن Agent‌ها لزوماً سود خالص ایجاد نمی‌کند. اثربخشی orchestration به تفاوت واقعی عملکرد یا هزینه میان Agent‌ها بستگی دارد.

    چرا(Agent)بیشتر،(coordination)بیشتری هم می‌خواهد؟

    هر Agent جدید می‌تواند یک interface، یک context، یک tool access و یک مسیر خطای جدید ایجاد کند.

    این مسئله فقط نرم‌افزاری نیست. در سطح زیرساخت نیز workflow‌های agentic می‌توانند مجموعه‌ای از inference‌ها، tool call‌ها و تصمیم‌های orchestration ایجاد کنند. پژوهش معماری‌ای که در ۲۰۲۶ منتشر گردید نشان می‌دهد همین ساختار تکه‌تکه می‌تواند الگوی مصرف منابع را پیچیده‌تر کند. این ساختار می‌تواند بارهای متغیر و bursty بسازد.

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

    اگر پاسخ روشن نباشد، ممکن است فقط یک لایهٔ coordination جدید ساخته باشیم.

    افزایش تعداد چرخ‌دنده‌های واسط در سیستم Agent بدون خروجی بیشتر - نکسچر
    لایهٔ هماهنگی اضافه در سیستم Agent – نکسچر

    مسئلهٔ واقعی چیست: تعداد(Agent)یا طراحی مسئولیت؟

    NIST در کار خود روی Agentic AI و استانداردهای Agent‌ها، هم‌زمان روی interoperability، evaluation، governance و risk management تأکید می‌کند. در اسناد مرتبط با Agent identity نیز مسئلهٔ اصلی فقط «توانایی انجام کار» نیست. دسترسی Agent به اطلاعات، ابزارها و سیستم‌ها نیز باید کنترل گردد.

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

    ممکن است یک workflow با دو Agent و یک نقطهٔ مشخص human approval از یک سیستم ده‌عاملی قابل‌کنترل‌تر و اقتصادی‌تر باشد.

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

    چه زمانی باید یک Agent جدید به سیستم اضافه کرد؟

    یک قاعدهٔ ساده می‌تواند کمک‌کننده باشد: هر Agent جدید باید یک bottleneck مشخص را حذف کند.

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

    این نگاه، AI را از «جمع‌کردن Agent‌ها» به طراحی سیستم کار منتقل می‌کند.

    جمع‌بندی: گاهی یک Agent کمتر، سیستم بهتری می‌سازد

    در سیستم‌های agentic، مقیاس همیشه با تعداد Agent‌ها اندازه‌گیری نمی‌گردد.

    گاهی یک Agent کمتر، با مسئولیت روشن‌تر، context محدودتر، دسترسی دقیق‌تر و نقطهٔ کنترل مشخص، می‌تواند سیستم بهتری بسازد.

    بهره‌وری زمانی افزایش می‌یابد که Agent‌ها کار را تقسیم کنند؛ نه اینکه فقط پیچیدگی را تقسیم کنند.

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


    پرسش و پاسخ

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

    خیر. هر Agent جدید فقط نیروی کار دیجیتال اضافه نمی‌کند؛ نقطهٔ تازه‌ای برای هماهنگی، انتقال context، کنترل دسترسی، ارزیابی، خطا و تصمیم‌گیری هم می‌سازد. پژوهش مستقل دربارهٔ orchestration چند-Agent نشان می‌دهد افزودن Agent لزوماً سود خالص ایجاد نمی‌کند. اثربخشی به تفاوت واقعی عملکرد یا هزینه میان Agent‌ها بستگی دارد.

    هزینهٔ پنهان افزودن یک Agent جدید چیست؟

    هر Agent جدید می‌تواند interface، context، tool access و مسیر خطای تازه‌ای ایجاد کند. در سطح زیرساخت نیز workflow‌های agentic مجموعه‌ای از inference، tool call و تصمیم orchestration می‌سازند. پژوهش معماری ۲۰۲۶ نشان می‌دهد این ساختار می‌تواند الگوی مصرف منابع را پیچیده‌تر و بارها را متغیر و bursty کند.

    معیار درست برای ارزیابی یک معماری چندعاملی چیست؟

    معیار باید تفکیک مسئولیت، کیفیت خروجی، هزینهٔ اجرا، سطح کنترل و قابلیت audit باشد، نه تعداد Agent‌ها. NIST در کار خود هم‌زمان روی interoperability، evaluation، governance و risk management تأکید می‌کند. در اسناد Agent identity نیز کنترل دسترسی Agent به اطلاعات، ابزارها و سیستم‌ها مهم است.

    چه زمانی افزودن یک Agent جدید موجه است؟

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

    آیا معماری با Agent کمتر می‌تواند بهتر باشد؟

    بله. ممکن است یک workflow با دو Agent و یک نقطهٔ مشخص human approval از یک سیستم ده‌عاملی قابل‌کنترل‌تر و اقتصادی‌تر باشد. در سیستم‌های agentic، مقیاس همیشه با تعداد Agent‌ها اندازه‌گیری نمی‌گردد. گاهی مسئولیت روشن‌تر، context محدودتر، دسترسی دقیق‌تر و نقطهٔ کنترل مشخص، سیستم بهتری می‌سازد.