تصور کنید یک توئیت ۱۲ کلمهای بتواند هزاران برنامهنویس را متقاعد کند که کل معماری نرمافزاری خود را تغییر دهند. این دقیقاً همان اتفاقی بود که در جولای ۲۰۲۶ رخ داد و موجی از وحشت و عجله برای مهاجرت به معماریهای جدید در دنیای عاملهای هوش مصنوعی ایجاد کرد.
در ۱۸ جولای ۲۰۲۶، ساعت ۰۰:۳۴ UTC، پیتر استاینبرگر (Peter Steinberger)، خالق OpenClaw، سؤالی را در توییتر مطرح کرد: «آیا هنوز داریم دربارهٔ حلقهها حرف میزنیم یا دیگر به گرافها کوچ کردیم؟». او هیچ تعریف فنی یا اصل طراحی ارائه نکرد و هدفش صرفاً کنایه زدن به عادت صنعت در تغییر نام مفاهیم تکراری بود. اما جامعهٔ هوش مصنوعی این سؤال را به جای یک شوخی، یک تغییر پارادایم تلقی کرد. تنها چهار ساعت و نیم بعد، هامِل حسین (Hamel Husain) مقالهای منتشر کرد و مرگ «مهندسی حلقه» را اعلام نمود. تا روز بعد، این شعار به یک روایت غالب تبدیل شد و پیش از آنکه معنای پایداری پیدا کند، راهنماها و جداول مقایسهای برای رشتهای ساخته شدند که اساساً بر پایه یک شوخی بود.
این چرخهٔ تورن اصطلاحات، الگویی تکراری در فضای عاملمحور (Agentic) است. مهندسی پرامپت به مهندسی زمینه، سپس مهندسی هارنس و در نهایت مهندسی حلقه تبدیل شد. در هر مورد، واژگان سریعتر از پیادهسازیهای فنی تغییر کردند. استاینبرگر بعدها با انتشار نموداری از یک ماشین وضعیت ساده — که فقط دو حالت «حلقه» و «پایان» داشت — این هیاهو را به سخره گرفت و نوشت: «این همان چیز مسخرهای است که هفتهها دربارهاش هایپ کردید». هایپ «مهندسی گراف» آخرین تکرار این روند بود؛ جایی که یک نکته طنزآمیز به اشتباه به عنوان یک نقشه راه فنی تلقی شد.
توهم مهاجرت
بسیاری از توسعهدهندگان شروع به برنامهریزی برای مهاجرت به سیستمهای گرافمحور کردند، با این باور که در حال حرکت به سمت معماری پیشرفتهتری هستند. من هم یکی از آنها بودم؛ مخزن کد agentsmyth را باز کردم تا برای این مهاجرت برنامهریزی کنم، اما متوجه شدم که ساختارم یک توالی ثابت با نقاط بازرسی بین هر مرحله است و دقیقاً از هر گره، تنها یک یال خارج میشود. هیچ حلقهای وجود نداشت که بخواهم آن را بیرون بکشم و هیچ جای مشخصی برای قرار دادن یک گراف نبود.
هریسون چیس (Harrison Chase)، خالق LangGraph، اشاره کرد که مهندسی گراف یک رشته مجزا نیست، بلکه اساساً همان کاری است که LangGraph از ابتدا انجام میداد. چیس در پاسخ به این موج اعتراف کرد که نمیداند «مهندسی گراف» دقیقاً چیست، اما احتمالاً همان LangGraph است. چهار روز بعد، او و سیدنی رانکل (Sydney Runkle) مقالهای بر اساس سه سال تجربه در ساخت سیستمهای عامل گراف منتشر کردند تا به این سردرگمی پایان دهند. آنها استدلال کردند که هرگز نیازی به «مهاجرت» نبوده است. عاملهای عملیاتی (Production Agents) به چرخه نیاز دارند زیرا باید فراخوانهای شکستخورده را تکرار کنند، اطلاعات گمشده را درخواست کنند، پس از اعتبارسنجی خود را اصلاح کنند و برای دریافت ورودی انسان متوقف شوند.
واقعیت فنی این است که یک حلقه، صرفاً یک گراف جهتدار چرخشی (Directed Cyclic Graph) است — نکتهای که آنها به دیوید خورشید (David Khourshid) نسبت میدهند. بنابراین، مهندسی حلقه جایگزین مهندسی گراف نیست، بلکه سادهترین حالت ممکن از آن است. فریمورک LangChain خود بر بستر LangGraph اجرا میشود، به این معنا که مهاجرتی که بسیاری برایش برنامهریزی میکردند، سه سال پیش در لایههای زیرین و بدون نامی خاص رخ داده بود. این وابستگی ساختاری نشان میدهد که چرا مقیاسپذیری عاملهای هوش مصنوعی به معماری Loop وابسته است و بدون آن، سیستمها در محیطهای عملیاتی شکست میخورند.
پیشینه و الگوها
این موضوع کشف جدیدی نیست. پیشینه فنی این موضوع عمیقتر از ترند فعلی است. در اوایل سال ۲۰۲۴، آنتروپیک (Anthropic) چندین الگوی کلیدی را مستند کرد و توصیه نمود که توسعهدهندگان تنها زمانی پیچیدگی را اضافه کنند که چیزی واقعاً آن را طلب کند:
- زنجیرهسازی پرامپت (Prompt Chaining): توالی خطی وظایف.
- مسیریابی (Routing): هدایت ورودیها به مسیرهای مختلف.
- موازیسازی (Parallelization): اجرای همزمان وظایف.
- ارکستراتور-کارگر (Orchestrator-Worker): یک عامل مرکزی برای مدیریت زیرمجموعهها.
- ارزیاب-بهینهساز (Evaluator-Optimizer): حلقهای از نقد و اصلاح.
فریمورکهایی مثل LangGraph، AutoGen و Google ADK همگی پیش از ترند شدن این واژه، گردشکارهای گراف را ارائه داده بودند. هیچ پارادایمی برای تغییر وجود نداشت چون ابزارها از قبل موجود بودند. گویاترین جزئیات این هایپ، فقدان دقت در گزارشها بود: مقالاتی که این ترند را توضیح میدادند حتی بر سر تعداد کلمات توئیت استاینبرگر اتفاق نظر نداشتند؛ برخی میگفتند ۶ کلمه و برخی ۹ کلمه، در حالی که در واقع ۱۲ کلمه است. تعداد بازدیدهای توئیت از ۵۷۵,۰۰۰ تا ۲.۹ میلیون گزارش شد. دهها مقاله درباره جملهای نوشته شد که بخش قابل توجهی از نویسندگانش حتی آن را با دقت نخوانده بودند.
هزینه پنهان یالها
افزودن یالها (Edges) به یک گردشکار — یعنی تبدیل یک زنجیره خطی به یک گراف شاخهدار — ارتقایی رایگان نیست. هر یال اضافی، یک تصمیم پیچیدگی است که هزینهای مشخص در نظارت و اعتبارسنجی دارد. سؤال واقعی این نیست که آیا از گراف استفاده کنیم یا نه، بلکه این است که هر یال اضافی چه هزینهای خواهد داشت.
یک زنجیره هفتمرحلهای مثل agentsmyth را در نظر بگیرید که از مشخصات (Specification) شروع شده و از طریق برنامهریزی، پیادهسازی، بازبینی، تست و در نهایت انتشار پیش میرود. در یک زنجیره خطی، یک بازبین انسانی (در اینجا من) میتواند در یک نقطه بازرسی بین هر مرحله بایستد. هر مرحله خروجی مکتوب مرحله قبل را میخواند، نه کل تاریخچه گفتگو را.
اگر یک مشخصه اشتباه وارد سیستم شود — مشخصهای که منسجم و مطمئن به نظر میرسد اما کمی در جهت غلط است — پیش از آنکه هر چیزی ساخته شود، به یک نقطه بازرسی میرسد. اگر من آن را تشخیص دهم، هزینه تنها کار یک مرحله است. اگر آن را نادیده بگیرم، دقیقاً یک مرحله پیش میرود و نقطه بازرسی دیگری در انتظار است.
اما در یک گراف شاخهدار، همان مشخصه اشتباه میتواند به سه مسیر مختلف تقسیم شود. سه گره مختلف به طور موازی بر اساس آن خطا پیش میروند و هر کدام نسبت به ورودی معیوب، «درست» عمل میکنند. خطا در نقاط بازرسی ظاهر نمیشود چون مشخصه از تنها دروازهای که قرار بود ملاقات کند، عبور کرده است. در عوض، خطا در نقطه تلاقی (Convergence) ظاهر میشود، یعنی زمانی که شاخهها بازمیگردند و با هم جفت نمیشوند. تا آن زمان، تمام کارها قبلاً انجام شده است. این چالشهای مدیریتی در حلقههای عملیاتی Hermes در برابر رویکردهای سنتی و پراکنده در مدیریت رویدادها به دقت بررسی شده است تا راهکارهای بهینهتری برای کنترل جریان دادهها ارائه شود.
مسئله دروازهبانی (Gating)
در حالی که ابزارهایی مثل LangGraph قابلیت «قطع» (Interrupts) برای توقف و دخالت انسان را فراهم میکنند، توپولوژی گراف اقتصاد دروازهبانی را تغییر میدهد:
- زنجیرههای خطی: یک نقطه برای ایستادن دارند؛ دروازهبانی ارزان است و اغلب به طور پیشفرض اتفاق میافتد.
- گرافها: به تعداد شاخههایشان، نقطه ایستادن دارند. هر شاخه باید تعریف شود، نیروی انسانی داشته باشد و منتظر تایید بماند.
در هیچکدام از این ساختارها دروازهبانی رایگان نیست، اما در زنجیره آنقدر ارزان است که نامرئی میشود. وقتی توسعهدهندگان به سراغ گرافها میروند، اغلب یالها (توپولوژی) را اضافه میکنند اما نقاط بازرسی (Gating) را فراموش میکنند. هر شاخه بدون نظارت، در واقع نقطه بازرسیای است که توسعهدهنده تصمیم گرفته آن را رها کند.
شکست در مقیاس واقعی
پیچیدگی فقط حجم کار را زیاد نمیکند، بلکه ردیابی خطاها را سختتر میکند. سال گذشته، من یک مکانیزم رویداد جهانی برای یک اپلیکیشن React Native به یک عامل سپردم. برنامه را نوشتم، بررسی کردم و تایید کردم. عامل برنامه را درست اجرا کرد، اما اپلیکیشن در جاهایی شکست خورد که برنامه بیسروصدا نادیده گرفته بود: کامپوننتهای غیرفعالی که خارج از محدوده رویداد بودند و اجرای تکراری یک رویداد.
من تنها با اضافه کردن لاگهای کنسول برای ردیابی جریان، متوجه خطا شدم. سه روز زمان برد تا آن را اصلاح کنم و نتیجه نهایی تنها ۷۰ تا ۷۵ درصد با آنچه واقعاً خواسته بودم همسو بود. چون فرآیند یک توالی خطی بود، خطا قابل ردیابی بود. من حفره را در سه روز پیدا کردم چون تنها یک مسیر برای ردیابی به عقب وجود داشت. در یک گراف چندشاخه، چنین خطای مشخصاتی تبدیل به یک کابوس عیبیابی میشد، زیرا خطا در چندین مسیر موازی که همزمان اجرا میشوند، توزیع میشد. برای جلوگیری از چنین شکستهایی در محیطهای عملیاتی، پیادهسازی پروتکل بازپخش در برابر بنچمارک میتواند راهکاری حیاتی برای تضمین پایداری مدلها باشد.
چه زمانی واقعاً از گراف استفاده کنیم؟
ساختاری که به دست نیامده باشد، یک بدهی است. از نظر متخصصان، یالها تنها در شرایط خاص باید اضافه شوند:
- شاخهبندی: وقتی مسیر واقعاً باید تقسیم شود.
- مسیریابی: وقتی کار باید بین چندین عامل متمایز جابجا شود.
- پایداری: وقتی اجرا باید در حین توقف برای انسان، زنده بماند.
حتی تیم LangChain اعتراف کرده که در برخی محصولات، از گرافهای پیشتعریفشده به سمت حلقههای عاملمحور منعطفتر حرکت کرده است، زیرا کارها بیش از آنکه در گرههای ثابت جای بگیرند، سیال بودند. آنها دریافتند که کارها در گرههای ثابت آرام نمیگیرند، و این ثابت کرد که ساختار گاهی میتواند یک مانع باشد.
تله مشخصات (Specification Trap)
سختترین بخش شاخهبندی، توپولوژی نیست، بلکه «مشخصات» است. برای اجرای موفق شاخههای موازی، توسعهدهنده باید یک شرط دشوار سوم را برآورده کند: او باید هر دو نیمه یک وظیفه را چنان دقیق تعریف کند که در نقطه تلاقی همچنان با هم سازگار باشند.
این یک مشکل تعریف (Specification) است، نه مشکل گراف. افزودن یال به یک تعریف معیوب، فقط سرعت تولید خطاهای موازی و مطمئن را افزایش میدهد. فرآیندهای اینچنینی معمولاً به دلیل اشتباه نمیمیرند، بلکه به دلیل اصطکاک میمیرند. هر یال، جایی برای گیر کردن است. من پشتیبانی از گراف را به agentsmyth اضافه نمیکنم چون یال، تصمیمی در مورد پیچیدگی است که تنها زمانی سودده است که کار واقعاً نتواند به صورت توالی اجرا شود. یالها هرگز بخش جذاب ماجرا نبودند؛ جذابیت در تعریف بود. زنجیره هفتمرحلهای این مقاله، همان agentsmyth است که با npx agentsmyth init قابل نصب است.
گام بعدی شما
- پیش از تبدیل زنجیرههای خطی به گراف، ابتدا نقاط بازرسی (Gating) خود را تعریف کنید تا از توزیع خطا در شاخههای موازی جلوگیری کنید.
- اگر گردشکار شما بیش از حد سیال است، به جای گرههای سخت، از حلقههای عاملمحور منعطف استفاده کنید.
- در هر مرحله از پیچیدگی، از خود بپرسید: «آیا این یال جدید، هزینه نظارت من را افزایش میدهد یا بهرهوری را؟»
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو