مهندسی گراف در عصر عامل‌های LLM: از هوش فردی به هوش سیستمی

مقاله «Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence»، نسخه‌ی دوم آن در ۲۶ اوت ۲۰۲۶ منتشر شده و یک مقاله‌ی مروری (Survey) است، نه یک مدل یا الگوریتم جدید.

خلاصه‌ی فارسی

ایده‌ی اصلی در یک جمله

مقاله می‌گوید:

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

نویسندگان این توانایی را System Intelligence می‌نامند و برای رسیدن به آن مفهوم Graph Engineering را پیشنهاد می‌کنند.

۱. مشکل چیست؟

روند تکامل Agentها را مقاله تقریباً این‌طور می‌بیند:

Model Intelligence → Individual Intelligence → System Intelligence

در ابتدا تمرکز روی خود مدل بود؛ بعد با Prompt Engineering، Context Engineering، ابزارها، حافظه و Loopها، یک LLM به یک Agent مستقل تبدیل شد.

اما برای کارهای خیلی پیچیده، یک Agent به تنهایی کافی نیست.

مثلاً تصور کن بخواهی یک پروژه‌ی نرم‌افزاری بزرگ را انجام دهی:

• یک Agent کد را تحلیل کند

• یکی تست بنویسد

• یکی باگ را reproduce کند

• یکی امنیت را بررسی کند

• یکی مستندات را بنویسد

• چند کار به‌صورت موازی انجام شوند

• یک Agent نتیجه‌ی Agent دیگر را verify کند

• اگر یکی خراب شد، فقط همان بخش دوباره اجرا شود

یک Agent واحد معمولاً این کارها را در یک loop نسبتاً خطی انجام می‌دهد. نتیجه:

• موازی‌سازی ضعیف

• قاطی‌شدن نقش‌ها

• خطاهای زنجیره‌ای

• دشواری پیدا کردن منشأ خطا

• از دست رفتن state در کارهای طولانی

مقاله دقیقاً این محدودیت‌ها را انگیزه‌ی حرکت به سمت System Intelligence می‌داند.

۲. Graph Engineering چیست؟

ایده‌ی کلیدی مقاله این است که به جای اینکه رابطه‌ی بین Agentها، taskها و stateها فقط به‌صورت implicit داخل prompt/context وجود داشته باشد، آن‌ها را صریحاً در قالب Graph نمایش دهیم.

یعنی چیزی شبیه:

                 Goal
                  │
          ┐───────┴───────┌
          ▼               ▼
      Research          Coding
          │               │
     ┐────┴────┌       ┐──┴───┌
     ▼         ▼       ▼      ▼
  Search    Verify   Implement Test
     │         │       │      │
     ┘─────────┴───────┴──────└                 
                  ▼
             Final Result

اما گراف فقط workflow نیست؛ مقاله سه لایه‌ی اصلی را مطرح می‌کند:

① Task / Work Organization

یعنی:

«چه کاری باید انجام شود؟»

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

مثلاً:

Build Product
   ┤── Research ────────┌
   ┤── Backend ─────────├
   ┤── Frontend <────────┤───── Integration
   ┘── Security ────────└

② Agent Coordination

یعنی:

«چه کسی این کار را انجام دهد؟»

Agentها قابلیت‌های متفاوتی دارند. Graph می‌تواند مشخص کند:

• چه Agentهایی وجود دارند

• هرکدام چه capability دارند

• چه نقشی دارند

• با چه Agentهایی ارتباط دارند

• چه اطلاعاتی را باید دریافت کنند

در نتیجه به‌جای یک Agent همه‌کاره، یک تیم Agentی تخصصی داریم.

③ Runtime State Management

این قسمت به نظرم یکی از مهم‌ترین بخش‌های مقاله است.

سیستم باید بداند:

«الان دقیقاً چه اتفاقی افتاده؟»

نه اینکه فقط conversation history داشته باشد.

برای هر تغییر مهم باید بتوانیم بدانیم:

چه کسی؟
چه کاری؟
چه زمانی؟
با چه input؟
چه نتیجه‌ای؟
بر اساس چه evidence؟
چه stateای ایجاد شد؟

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

۳. نکته‌ی خیلی مهم: Recovery

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

فرض کن:

A → B → C → D → E

در C یک خطا اتفاق افتاده.

سیستم naïve ممکن است کل فرآیند را از اول اجرا کند.

ولی Graph-based system می‌تواند بفهمد:

A ✓
B ✓
C ✗
D ?
E ?

بنابراین:

A ✓
B ✓
      ↓
    Repair C
      ↓
    Re-run D
      ↓
      E

یعنی valid work حفظ می‌شود و فقط بخش آسیب‌دیده دوباره اجرا می‌شود. مقاله این را با مفاهیمی مثل state recording، fault localization و recovery frontier توضیح می‌دهد.

۴. Graph باید ثابت نباشد

مقاله فقط نمی‌گوید workflow را به شکل graph بنویسیم.

گراف باید بتواند در طول اجرا تغییر کند.

مثلاً:

Task A
   ↓
Task B
   ↓
Task C

اگر Agent بفهمد C به دو کار مستقل نیاز دارد:

        ┌── C1 ──┐
B ──────┤        ├──> D
        └── C2 ──┘

یا اگر یک Agent عملکرد ضعیفی دارد، سیستم می‌تواند Agent دیگری را جایگزین کند.

یا اگر شرایط محیط تغییر کرد، communication topology تغییر کند.

بنابراین Graph Engineering به نوعی یعنی:

ساختار سیستم خودش هم قابل تکامل باشد.

۵. System Evolution

اینجا مقاله یک قدم جلوتر می‌رود.

سیستم فقط نباید task را انجام دهد؛ باید از اجرای قبلی یاد بگیرد که دفعه‌ی بعد بهتر عمل کند.

مثلاً:

Execution
    ↓
Experience
    ↓
Analyze failures/successes
    ↓
Modify workflow
    ↓
Modify agent team
    ↓
Modify communication
    ↓
Better execution

بنابراین سه چیز می‌توانند evolve شوند:

1. Task organization

2. Agent coordination

3. Runtime state / experience

مقاله این را یک loop بسته‌ی

Execution → Experience → Evolution

می‌داند.

۶. اما یک مشکل بزرگ باقی می‌ماند: Ontology

به نظرم این بخش یکی از جذاب‌ترین ایده‌های مقاله است.

فرض کن دو Agent درباره‌ی «task complete» برداشت متفاوتی داشته باشند.

Agent A:

«کد اجرا شد، پس task تمام است.»

Agent B:

«کد باید test هم شده باشد، پس هنوز تمام نشده.»

Graph به‌تنهایی این مشکل را حل نمی‌کند.

چون Graph می‌گوید:

Agent A → Task B → State C

ولی الزاماً نمی‌گوید Task B دقیقاً چه معنایی دارد.

اینجاست که مقاله Ontology Engineering را مطرح می‌کند.

Ontology قرار است یک زبان/مدل معنایی مشترک برای مفاهیمی مثل:

• Goal

• Agent

• Capability

• Evidence

• Policy

• State

• Outcome

ایجاد کند.

در واقع:

Ontology = معنی چیزها

Graph = رابطه‌ی چیزها

Runtime system = اجرای چیزها

این تفکیک خیلی مهم است.

۷. معماری ذهنی مقاله

اگر بخواهم کل مقاله را در یک تصویر ذهنی خلاصه کنم:

                 ┌─────────────────────┐
                 │      ONTOLOGY       │
                 │ "این چیزها چه معنی  │
                 │      دارند؟"        │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │   GRAPH ENGINEERING │
                 │                     │
                 │ Tasks               │
                 │ Agents              │
                 │ Dependencies        │
                 │ Communication       │
                 │ Runtime State       │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │    EXECUTION        │
                 │                     │
                 │ Plan → Act → Verify │
                 │ → Recover → Learn   │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │     EVOLUTION       │
                 │                     │
                 │ Better tasks        │
                 │ Better teams        │
                 │ Better workflows    │
                 └─────────────────────┘

۸. مقاله چه چیزهایی را بررسی می‌کند؟

چون مقاله Survey است، تعداد زیادی سیستم و پروژه‌ی موجود را دسته‌بندی می‌کند.

از جمله کاربردها در:

• Software Engineering

• Scientific Discovery

• Healthcare

• Enterprise Workflow

• Personal Agents

• Social Simulation

• Multi-Agent Systems

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

همچنین مجموعه‌ای از benchmarkها را برای Model Intelligence، Individual Intelligence و System Intelligence دسته‌بندی می‌کند.

۹. نقد مهم مقاله

نویسندگان تأکید می‌کنند که صرفاً بهتر شدن نتیجه‌ی نهایی به معنی داشتن System Intelligence نیست.

مثلاً اگر سیستم از:

• مدل بزرگ‌تر

• compute بیشتر

• context طولانی‌تر

• sampling بیشتر

استفاده کند و بهتر جواب دهد، الزاماً به این معنی نیست که معماری multi-agent آن بهتر شده است.

برای ارزیابی واقعی باید چیزهایی مثل این‌ها سنجیده شوند:

• کیفیت decomposition

• parallelism

• allocation قابلیت‌ها

• کیفیت تصمیم جمعی

• consistency حالت سیستم

• failure recovery

• انتقال تجربه به taskهای جدید

• هزینه‌ی runtime

و حتی باید سیستم را در شرایطی مثل failure، workload همزمان، اطلاعات ناقص و تغییر محیط آزمایش کرد.

۱۰. چالش‌های آینده

مقاله چند مسیر پژوهشی مهم را مطرح می‌کند:

🔹 Autonomous Ontology Construction

Agentها بتوانند خودشان ontology را بسازند و تکامل دهند، ولی با validation و human governance.

🔹 Graph-Native Capability Substrates

به‌جای اینکه memory، skills، tools و capabilityها سیستم‌های جداگانه باشند، خودشان بخشی از زیرساخت graph شوند.

🔹 Self-Evolving Graph Systems

سیستم بتواند ساختار خودش را بر اساس تجربه تغییر دهد.

🔹 Graph-Native Agent Operating Systems

ایده‌ی بسیار جالب مقاله: چیزی شبیه یک Operating System برای Agentها که task، agent، state، memory، permission و execution را در سطح سیستم مدیریت کند.

🔹 Privacy & Ethics

وقتی همه‌ی فعالیت Agentها به‌صورت graph و trace ذخیره شود، مسائل جدی درباره‌ی privacy، governance و دسترسی به اطلاعات ایجاد می‌شود.

جمع‌بندی خیلی ساده

اگر بخواهم مقاله را در ۵ جمله خلاصه کنم:

1. یک LLM قوی به‌تنهایی برای کارهای پیچیده‌ی طولانی کافی نیست.

2. باید چند Agent تخصصی را به یک سیستم هماهنگ تبدیل کنیم.

3. برای این کار، taskها، Agentها، dependencyها و state باید به‌صورت Graph صریح و قابل تغییر مدل شوند.

4. این Graph باید امکان parallel execution، verification، fault localization، recovery و evolution را فراهم کند.

5. در مرحله‌ی بعد، Graph به یک Ontology مشترک نیاز دارد تا Agentهای مختلف واقعاً درک مشترکی از goal، state، evidence و capability داشته باشند.

برداشت شخصی من از اهمیت مقاله: این مقاله بیشتر از اینکه یک تکنیک جدید معرفی کند، یک نقشه‌ی معماری برای نسل بعدی سیستم‌های Agentic AI ارائه می‌دهد: حرکت از «Agent به‌عنوان یک حلقه‌ی reasoning» به سمت «سیستم Agentها به‌عنوان یک سیستم توزیع‌شده با graph، state، governance و قابلیت تکامل».

نسخه PDF مقاله در arXiv