در مقاله قبلی درباره تغییری صحبت کردیم که در ظاهر ساده بود؛ تغییر مقدار radius-md از 8px به 12px. دیدیم که یک Agent نباید فقط مقدار Token را تغییر دهد، بلکه باید وابستگیها را پیدا کند، تستها را اجرا کند، نتیجه را بررسی کند و در صورت شکست، دوباره برای اصلاح برگردد.
این ساختار یک Loop بود؛ فرایندی که خروجی را ارزیابی میکند و تا رسیدن به نتیجه قابل قبول، دوباره اجرا میشود.
اما فرض کنیم همین تغییر فقط به کامپوننتها محدود نباشد.
وقتی یک Loop دیگر کافی نیست
تیم Brand باید بررسی کند که Radius جدید همچنان با زبان بصری محصول هماهنگ است یا نه. تیم Accessibility باید اثر تغییر را روی Focus Stateها بررسی کند. تیم Front-end باید تغییرات کد و Snapshotها را ارزیابی کند. تیم Documentation باید تصاویر و مثالها را بهروزرسانی کند و تیمهای محصول هم باید مشخص کنند آیا این تغییر روی تجربههای قدیمی اثر نامطلوبی گذاشته یا نه.
بعضی از این بررسیها میتوانند همزمان انجام شوند، بعضی فقط بعد از پایان مرحلهای دیگر شروع میشوند و بعضی هم ممکن است کل فرایند را به مسیر متفاوتی بفرستند.
برای مثال، اگر تستهای فنی موفق باشند اما بررسی Accessibility شکست بخورد، لازم نیست همه مراحل از ابتدا تکرار شوند. فقط بخشی که به Focus Stateها و کامپوننتهای مرتبط مربوط است باید اصلاح و دوباره ارزیابی شود. اگر تغییر در چند محصول ناسازگاری ایجاد کند، شاید مسیر بهجای انتشار مستقیم، به ساخت Migration Plan برسد. اگر میزان اثرگذاری بیش از حد انتظار باشد، حتی ممکن است تصمیم اولیه دوباره وارد Design Review شود.
اینجا دیگر یک Agent که در یک مسیر مشخص جلو میرود و در صورت شکست به عقب برمیگردد، بهتنهایی کافی نیست. فرایند به چند شاخه تقسیم شده که هرکدام وظیفه، Context، ابزار و معیار موفقیت خودشان را دارند.
اینجاست که از Loop Engineering به Graph Engineering میرسیم.
Graph چگونه فرایند را مدل میکند؟
در Graph، هر مرحله میتواند یک Node مستقل باشد؛ تحلیل وابستگیها، بررسی بصری، تست Accessibility، ارزیابی کد، مستندسازی یا تأیید انسانی. ارتباط بین این Nodeها هم مشخص میکند هر خروجی باید به کجا برود، کدام مراحل موازی اجرا شوند و در چه شرایطی فرایند به عقب برگردد یا وارد مسیر جدیدی شود.
در واقع Graph، Loop را حذف نمیکند. یک Graph میتواند چند Loop مختلف درون خودش داشته باشد. تست بصری ممکن است تا رفع خطا تکرار شود، بررسی Accessibility Loop خودش را داشته باشد و تولید مستندات هم تا تأیید نهایی دوباره اجرا شود. تفاوت این است که حالا این Loopها بخشی از یک معماری بزرگتر هستند، نه کل معماری.
- 1تحلیل تغییر
- 2تقسیم به Nodeهای مستقل
- 3اجرای ترتیبی یا موازی
- 4تصمیمگیری شرطی
- 5Loopهای اصلاح
- 6تأیید و انتشار
فریمورکهایی مثل LangGraph هم Workflowهای Agentها را با همین منطق مدل میکنند: مجموعهای از Nodeها که از طریق یک State مشترک به هم متصل میشوند و میتوانند مسیرهای ترتیبی، شرطی، موازی و تکرارشونده داشته باشند. مستندات این ابزار هم بین Workflowهای از پیش تعریفشده و Agentهایی که مسیر خودشان را پویا انتخاب میکنند تفاوت قائل میشود.
Graph همیشه انتخاب بهتری نیست
اضافه کردن Graph همیشه به معنی بهتر شدن سیستم نیست.
اگر فرایند ساده باشد، تبدیل کردن آن به دهها Node و Agent فقط هزینه هماهنگی، Debug و نگهداری را بیشتر میکند. حتی مستندات سیستمهای چندعاملی هم تأکید میکنند که هر مسئله پیچیدهای لزوماً به چند Agent نیاز ندارد و گاهی یک Agent با ابزارها و Context مناسب، همان نتیجه را سادهتر به دست میآورد.
بنابراین سؤال اصلی این نیست که «Loop بهتر است یا Graph؟»
سؤال این است که پیچیدگی مسئله ما از چه نوعی است؟
اگر یک مسیر اصلی داریم که باید اجرا، ارزیابی و اصلاح شود، Loop انتخاب مناسبی است. اما اگر چند مسئولیت مستقل، مسیرهای شرطی، اجرای موازی و نقاط تصمیم متعدد داریم، Graph کمک میکند این پیچیدگی را بهجای پنهان کردن، بهصورت شفاف طراحی کنیم.
Loop یا Graph؟
- 1Loop Engineering روی بهتر شدن یک مسیر تمرکز میکند.
- 2Graph Engineering روی هماهنگ کردن چند مسیر تمرکز میکند.
برای Design Systemها این تفاوت مهم است، چون نگهداری سیستم هیچوقت فقط یک چرخه واحد نیست. Design، Code، Documentation، Accessibility، Governance و Adoption هرکدام جریان خودشان را دارند، اما تصمیمهای یک بخش میتواند مسیر بقیه را تغییر دهد.
وقتی AI وارد چنین سیستمی میشود، مسئله اصلی دیگر نوشتن یک Prompt یا حتی ساختن یک Loop نیست. باید مشخص کنیم هر تصمیم کجا گرفته میشود، چه اطلاعاتی بین مراحل جابهجا میشود، چه کسی حق تأیید یا توقف دارد و شکست در هر بخش، کدام مسیر را فعال میکند.
Graph Engineering از جایی شروع میشود که طراحی رفتار یک Agent کافی نیست و باید نحوه همکاری کل سیستم را طراحی کنیم.
کامنتها
…