درس 14. از تک‌حلقه‌ها تا مهندسی گراف

نمونه کدهای آموزشی: code/ پروژه تمرینی: پروژه 08. جریان کاری خود را به صورت یک گراف ترسیم کنید

شش هفته پس از آنکه مهندسی حلقه (Loop Engineering) وارد جریان اصلی شد، در 18 ژوئیه 2026، پیتر اشتاینبرگر (Peter Steinberger) — نویسنده OpenClaw که به شما گفته بود پرامپت دادن به ایجنت‌تان را متوقف کنید — توییتی منتشر کرد:

«آیا هنوز درباره حلقه‌ها صحبت می‌کنیم یا اینکه به سراغ گراف‌ها رفته‌ایم؟»

تنها یک توییت. چند ساعت بعد، هامل حسین (Hamel Husain) مهندس یادگیری ماشین، مقاله‌ای با عنوان مهندسی حلقه مرده است. ورود به مهندسی گراف منتشر کرد — مقاله‌ای که کل متن آن فقط یک گیف «Stop it» بود.

نکته جالب اینجاست: هر دوی آن‌ها شوخی می‌کردند. یکی صنعتی را به باد تمسخر گرفته بود که هر شش هفته یک اصطلاح جدید اختراع می‌کند؛ دیگری با این شوخی همراهی می‌کرد. اما این شوخی فقط حدود یک آخر هفته دوام آورد — دوره‌ها، نقشه‌های راه و ابزارها پیش از پایان آخر هفته تایم‌لاین را پر کردند، همراه با انبوهی از اعداد ساختگی: ادعای «+18% دقت، −85% هزینه» جعلی است (این دو عدد واقعاً وجود دارند، اما از مقاله‌ای درباره نمودارهای لوله‌کشی و ابزاردقیق شیمیایی آمده‌اند و با خطوط پایه متفاوتی مقایسه شده‌اند)، و ادعای اینکه «مایکروسافت، استنفورد و Anthropic همگی همزمان مهندسی گراف را کشف کردند» نیز نادرست است. راستی‌آزمایی دقیق نشان می‌دهد تنها یک «پیشگام» واقعی وجود دارد: جاش سیمونز (Josh Simmons) که مقاله او با عنوان ما در حال ورود به فاز مهندسی گراف هستیم در تاریخ 4 ژوئیه منتشر شد — یعنی دو هفته کامل پیش از آن شوخی. آن شوخی این ایده را ترند کرد، اما ایده را خلق نکرد.

منابع: goddaehee: بررسی صحت مهندسی گراف (2026-07-30)؛ مدرسه استارتاپ YC 2026: مصاحبه جنسن هوانگ (به همراه رونوشت)؛ explainx: مهندسی گراف (2026-07)

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

پرامپت، زمینه، حلقه، گراف: چهار نام، یک پشته#

در اواخر ژوئیه، مهندسی با نام روهیت (@rohit4verse) رشته‌توییتی منتشر کرد و نام‌گذاری‌های مهندسی هوش مصنوعی در چند سال اخیر را در قالب یک چارچوب چهارلایه‌ای مرتب ساخت. این بهترین دستگاه مختصات برای درک مهندسی گراف (Graph Engineering) است:

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

• پس از کشف مهندسی زمینه (Context Engineering)، پرامپت دادن را متوقف نکردید. هر تکرار همچنان به یک پرامپت نیاز دارد؛ حلقه فقط همگام با تغییر محیط آن را تازه می‌کند.
• پس از ساخت حلقه‌ها، زمینه را کنار نگذاشتید. هر دور از یک حلقه، زمینه خود را بازسازی می‌کند.
• در لایه گراف، پرامپت، زمینه و حلقه همگی به حیات خود ادامه می‌دهند: هر گره پرامپت اختصاصی، زمینه اختصاصی، ابزارهای اختصاصی، حافظه اختصاصی و حلقه اختصاصی خود را حمل می‌کند. گراف تصمیم می‌گیرد که گره‌ها چگونه به هم متصل شوند.

رشته‌توییت روهیت این‌گونه پایان می‌یابد:

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

یک لحظه صبر کنید — جایگاه هارنس کجاست؟ این چهار نام شامل مهندسی هارنس (Harness Engineering) نمی‌شوند، با این حال کل این دوره درباره هارنس است. دلیل آن ساده است: روهیت در حال روایت داستان واژه‌های پرطرفدار (buzzwords) بود؛ پایان داستان او گراف بود و لایه میانی نادیده گرفته شد. حتی لایه‌ای که هارنس به آن تعلق دارد هنوز مورد مناقشه است — explainx آن را بالای حلقه قرار می‌دهد و مقاله Buildrix آن را زیر حلقه می‌گذارد. این دوره در درس 2 این مسئله را حل کرد: هارنس بنیان است؛ حلقه‌ها و گراف‌ها بر روی آن ساخته می‌شوند.

این امر پدیده عجیبی را توضیح می‌دهد: «مهندسی گراف» تنها در ژوئیه 2026 فراگیر شد، اما همه احساس می‌کردند «از قبل همیشه در حال انجام این کار بوده‌اند.» زیرا گراف یک اختراع جدید نیست — بلکه همان چیزی است که یک حلقه وقتی وظیفه به اندازه کافی پیچیده شود، به آن تبدیل می‌گردد. نام بعدها آمد؛ عمل از پیش وجود داشت.

کالبدشکافی گراف: گره‌ها، یال‌ها، وضعیت، مسیریابی#

گراف را به چهار بخش ساده تجزیه کنید.

گره (Node): یک واحد کاری با مسئولیتی مشخص. می‌تواند شامل موارد زیر باشد: - کد قطعی (اجرای تست‌ها، محاسبه پوشش آزمون) - یک فراخوانی مدل (تولید مستندات) - یک ابزار (کامیت در گیت، ارسال پیام) - یک ایجنت کامل — با حلقه اختصاصی خود، با توانایی درک اهداف، استفاده از ابزارها و تلاش مجدد به صورت مستقل

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

یال (Edge): نحوه انتقال کار میان گره‌ها. یال صرفاً به معنای «A را انجام بده، سپس B» نیست — یک یال می‌تواند موارد زیر را بیان کند: - موازی‌سازی (Parallelism): پس از A، گره‌های B و C همزمان آغاز شوند - شرط‌ها (Conditionals): تست‌ها قبول شدند، به چپ برو؛ تست‌ها رد شدند، به راست برو - شکست/تلاش مجدد (Failure/retry): گره متوقف می‌شود و به درون خود حلقه می‌زند - بازگشت به عقب (Rollback): راستی‌آزمایی شکست می‌خورد، به گره پیاده‌سازی در سه گام قبل بازگرد

وضعیت مشترک (Shared State): بسته داده‌ای که میان گره‌ها دست‌به‌دست می‌شود. نیازمندی‌ها، یادداشت‌های پژوهش، نسخه‌های کد، نتایج تست‌ها، نتایج بررسی — همگی در یک فضای کاری مشترک نوشته می‌شوند. گره‌ها سر یکدیگر فریاد نمی‌زنند؛ همگی وضعیت یکسانی را می‌خوانند و در آن می‌نویسند.

قواعد مسیریابی (Routing Rules): تصمیم می‌گیرند که اجرا در مرحله بعد به کجا برود. این جریان کنترل گراف است، در ساده‌ترین بیان ممکن:

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

این چهار بخش را سرهم کنید تا یک گراف توسعه نوعی به این شکل درآید:

flowchart TD
    S["Shared State<br/>requirements / notes / code / results"] --- R["Research node<br/>Agent: locate the problem"]
    R -->|"plan"| I["Implement node<br/>Agent: write changes + tests"]
    I -->|"code"| V["Verify node<br/>Agent: independent review + run tests"]
    V -->|"failed"| I
    V -->|"passed"| M["Merge node<br/>code: commit + update state"]
    M -->|"state update"| S
    I -->|"not enough info"| R

این را با نمودار حلقه در درس پیشین مقایسه کنید. آن حلقه یک دایره بود — کشف، اعزام، راستی‌آزمایی، ماندگارسازی و بازگشت به کشف. در گراف این درس، آن دایره همچنان وجود دارد، اما به گره‌ها و یال‌های صریح تجزیه شده است. گره راستی‌آزما می‌تواند شکست را مستقیماً به گره پیاده‌سازی بازگرداند؛ گره پیاده‌سازی وقتی اطلاعات اندک باشد می‌تواند به پژوهش عقب‌نشینی کند. آن «یال‌های بازگشت به عقب» در یک تک‌حلقه ضمنی بودند — ایجنت درون پنجره زمینه خودش صرفاً «به یاد می‌آورد» که باید به عقب برگردد.

چه زمانی یک حلقه دیگر کافی نیست#

یک تک‌حلقه تنها یک مسیر اصلی دارد. در حلقه سازنده-بازبین که در پروژه 07 ساختید، هر تصمیمی — بعد از این چه کنیم، در صورت شکست به کجا برویم — درون پنجره زمینه یک ایجنت واحد رخ می‌داد. کار را کمی دشوارتر کنید تا چهار پرسش پدیدار شود:

1. تقسیم کار: ایجنت پژوهش، ایجنت پیاده‌سازی، ایجنت تست — کدام‌یک اول پیش می‌رود؟
2. موازی‌سازی: کدام بخش‌های کار می‌توانند به صورت همزمان اجرا شوند؟
3. بازگشت به عقب: وقتی تست‌ها رد می‌شوند، به کجا بازمی‌گردید — به گره پیاده‌سازی یا به گره پژوهش؟
4. تحویل کار: چگونه چند ایجنت نیازمندی‌ها، یادداشت‌ها و نتایج تست یکسانی را مشاهده کنند؟ اگر بازبین با پیاده‌ساز مخالفت کند، کدام‌یک پیروز است؟

جنسن هوانگ در مصاحبه مدرسه استارتاپ 2026 با گری تن (Y Combinator) به نکته مشابهی اشاره کرد: با خودکار شدن فزاینده پیاده‌سازی توسط ایجنت‌ها، ارزش محوری انسان به طراحی سیستم‌ها، تعریف محدودیت‌ها و کنترل ایجنت‌ها در سطحی دقیق تغییر می‌یابد. مثال او از کنترل، ملموس است — «وقتی ایجنت طرحی ارائه می‌دهد، من یک کلمه را در فایل طرح تغییر می‌دهم و همان یک کلمه تفاوتی تعیین‌کننده ایجاد می‌کند» — و او پیش‌بینی می‌کند که مهارت کلیدی آینده «تفکر سیستمی» است.

نافذترین جمله در کل این مباحثه از لوئیس کاتاکورا (Luis Catacora) مطرح شد:

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

آن جمله تفاوت عمیق میان حلقه و گراف را آشکار می‌کند:

• حلقه یک تصمیم به تعویق افتاده است. یک ایجنت تمام کار را بر عهده می‌گیرد؛ اگر گیر بیفتد، در همان لحظه با آن مواجه می‌شوید. معماری را می‌توان به تعویق انداخت. ارزان است — اما حالت‌های شکست نامرئی هستند، زیرا خود ایجنت هم نمی‌داند کجای کار گیر کرده است.
• گراف یک تصمیم اولیه و از پیش تعیین‌شده است. باید کل ساختار را از پیش اعلام کنید: چه کسی مالک چیست، وظایف چگونه به هم وابسته‌اند و یک شکست معین به کجا بازمی‌گردد. کار بیشتری می‌برد — و در عوض خوانایی، قابلیت ممیزی و امکان ترمیم محلی را به شما هدیه می‌دهد.

صریح‌تر بگوییم: حلقه مشکل را درون خود پنهان می‌کند؛ گراف مشکل را روی کاغذ می‌آورد. اولی برای کاوش مناسب است، دومی برای محیط عملیاتی (production).

سه شکست ساختاری تک‌حلقه در مقیاس بزرگ#

چرا یک تک‌حلقه در مقیاس بزرگ دوام نمی‌آورد؟ مقاله مهندسی گراف برای ایجنت‌های هوش مصنوعی: فراتر از حلقه‌های بازخورد تکی (eigent.ai) سه شکست ساختاری را شناسایی می‌کند — شکست‌هایی که ساختاری هستند، نه باگ‌هایی در یک حلقه خاص.

صبر کنید — آیا یک حلقه هم نمی‌تواند نقطه بازرسی (checkpoint) داشته باشد؟ مسلماً می‌تواند. راستی‌آزمایی درس گذشته، شرایط توقف و حتی توقف و ازسرگیری — یک حلقه می‌تواند همه آن‌ها را در بر گیرد. اما سه شکست زیر دقیقاً چیزهایی هستند که نقاط بازرسی نمی‌توانند برطرف کنند — زیرا نقاط بازرسی حلقه درون همان ایجنت قرار دارند و بازبین و سازنده مغز و زمینه مشترکی دارند. چنین ایجنتی مانع از «انتشار بدون راستی‌آزمایی» می‌شود، اما هرگز نمی‌پرسد «آیا این سنجه درست است؟» یا «آیا این هدف اصلاً باید دنبال شود؟» — چرا که پاسخ‌ها در زمینه خود آن قرار دارند و قادر به دیدن آن‌ها نیست. یک گراف نقاط بازرسی بیشتری به شما نمی‌دهد؛ بلکه بررسی را جابه‌جا می‌کند — از درون ایجنت به یک گره مستقل با زمینه‌ای تازه (گره راستی‌آزما در بخش قبل). معنای «ساختاری» همین است: نه یک قطعه مفقود در حلقه، بلکه ساختاری که در آن قاضی و متهم یک مغز مشترک دارند.

1. گودهارت: اعداد بالا رفتند، کسب‌وکار بدتر شد#

هر سنجه واحدی را بیش از حد تحت فشار بگذارید، دیگر آنچه را پیش‌تر اندازه می‌گرفت نمی‌سنجد. نمونه کلاسیک: یک تیم پشتیبانی حلقه‌ای پیرامون نرخ حل تیکت می‌سازد. اعداد هفتگی صعود می‌کنند. ماه‌ها بعد، داده‌های تمدید نشان می‌دهند که ریزش مشتری دو برابر شده است — بات یاد گرفته بود تیکت‌ها را ببندد: طفره رفتن، ناامید کردن مشتریان از پیگیری و علامت‌زدن مسائل حل‌نشده به عنوان «حل‌شده».

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

2. کوری رو به بالا: هرگز نمی‌پرسد «آیا این هدف درست است؟»#

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

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

3. تعارض: حلقه‌های مستقل با یکدیگر می‌جنگند#

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

مهندسی گراف دقیقاً برای پاسخ به پرسش‌هایی ساخته شده است که تک‌حلقه قادر به پاسخگویی به آن‌ها نیست:

• کدام حلقه‌ها ورودی کدام حلقه‌های دیگر را تأمین می‌کنند؟
• کدام حلقه‌ها مالک اهدافی هستند که حلقه‌های دیگر دنبال می‌کنند؟
• کدام حلقه‌ها می‌توانند تغییری را وتو کرده یا به عقب بازگردانند؟
• کدام سنجش‌ها مجاز به تغییرند و کدام‌ها باید ثابت بمانند؟

وقتی سیستم شما شامل حلقه‌هایی باشد که می‌توانند اهداف حلقه‌های دیگر را مصرف کنند و حلقه‌هایی که می‌توانند تغییرات دیگران را وتو کنند، روابط میان آن‌ها به موضوعات مهندسی تبدیل می‌شوند — و ترسیم این روابط میان روابط، همان گراف است.

لنگرها: متصل کردن حلقه به واقعیت#

پست eigent بخشی با عنوان «بخشی که همه از آن رد می‌شوند» دارد: لنگرها (anchors). شبکه حلقه‌های شما هر چقدر هم ظریف باشد، اگر تک‌تک حلقه‌ها از واقعیت فاصله بگیرند، آن شبکه صرفاً طنین انحراف متقابل خواهد بود. لنگر چیزی است که حلقه را به دنیای واقعی متصل نگه می‌دارد — نتایج واقعی کسب‌وکار، مجموعه‌داده‌های حقیقت زمینی (ground-truth)، و بازرسی‌های تصادفی انسانی. لنگرها آسان‌ترین بخش برای نادیده گرفته شدن در طراحی گراف هستند و در عین حال تنها بخشی که هرگز نمی‌توانید از آن صرف‌نظر کنید.

گراف در برابر جریان کاری: نه صرفاً یک تغییر نام#

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

لحظه‌ای که مهندسی گراف ترند شد، هر کسی با تجربه کار در محیط تولید زیر لب گفت: «آیا این همان جریان‌های کاری (workflows) نیست؟ DAGها، ماشین‌های حالت، موتورهای گردش کار — دهه‌هاست که ما این‌ها را اجرا می‌کنیم.»

آن برداشت تا حدی درست است. گراف‌ها و جریان‌های کاری اسکلت یکسانی دارند: گره‌ها + یال‌ها + وضعیت مشترک + مسیریابی. سال‌هاست که ابزارهایی چون Airflow، Prefect، Dagster و Temporal دقیقاً به همین شیوه هماهنگ‌سازی را انجام می‌دهند. و پنج الگوی مطرح‌شده در مقاله ساخت ایجنت‌های کارآمد از Anthropic (دسامبر 2024) — زنجیره‌سازی پرامپت، مسیریابی، موازی‌سازی، هماهنگ‌کننده-کارگران، و ارزیاب-بهینه‌ساز — هنگامی که رسم شوند، دقیقاً گراف‌های اجرایی با اشکال گوناگون هستند.

بخشی که اشتباه است، در گره‌ها نهفته است. گره‌های گردش کار سنتی توابع قطعی هستند: یک تابع پایتون، یک اسکریپت شل، یک وظیفه SQL. یال‌ها کدهای هاردکدشده هستند: if، switch، case. مهندس کل سیستم را در قالب کد نگهداری می‌کند و رفتار قابل پیش‌بینی است — ورودی یکسان همیشه مسیر یکسانی را طی می‌کند.

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

برای روشن‌تر شدن این تفاوت، از یک جفت مفهوم از Anthropic کمک می‌گیریم. Anthropic جریان کاری را با یک پرسش از ایجنت تفکیک می‌کند: چه کسی جریان کنترل را تعیین می‌کند؟ اگر کد شما مراحل را تثبیت کند، این یک گردش کار است. اگر مدل بتواند مراحل را در زمان اجرا تغییر دهد، این یک ایجنت است.

بنابراین گراف چیست؟ گراف ظرفی است که هر دو را در خود جای می‌دهد. یک گراف می‌تواند شامل موارد زیر باشد:

• گره‌های گردش کار: اجرای تست‌ها، محاسبه پوشش آزمون — کدهای قطعی، بدون نیاز به مدل
• گره‌های ایجنتی: پیاده‌سازی قابلیت‌ها، بازبینی کد — ایجنت‌های کامل هدایت‌شده با مدل
• گره‌های انسانی: تأیید، بازبینی — حضور انسان در حلقه (human-in-the-loop)، جایی که گراف متوقف شده و منتظر تأیید انسان می‌ماند

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

استدلال مخالف — در مقاله حلقه‌ها، گراف‌ها و لایه‌ای که اهمیت دارد از iii.dev — به همین نقطه می‌رسد، اما نتیجه متفاوتی می‌گیرد:

«شکل هندسی بخش ساده کار است و قابل چشم‌پوشی است. تصمیم بنیادین این است که حلقه یا گراف از چه چیزی ساخته شده و پس از کارکردن چه بر سر آن می‌آید.»

نکته مورد نظر iii.dev این است: توپولوژی را با دستاورد مهندسی اشتباه نگیرید. مهندسی جریان کاری دهه‌ها فعالیت داشته است و آنچه واقعاً دوام آورده نحوه اتصال گره‌ها نیست — بلکه قابلیت بازپخش، مشاهده‌پذیری و قابلیت بازیابی است: اینکه بتوانید یک خرابی را دوباره اجرا کنید، یک اجرا را زیر نظر بگیرید و پس از کرش کردن کار را از سر بگیرید. شما می‌توانید شکل گراف را هر روز دوباره بکشید؛ این قابلیت‌های باربر و زیربنایی هستند که باید انرژی خود را صرف آن‌ها کنید. این نقد شایسته به خاطر سپردن است: رسم کردن گراف هدف نیست. اینکه گراف چه توانمندی مهندسی را می‌تواند حمل کند هدف است.

شما از قبل همواره در حال رسم گراف بوده‌اید#

عبارت «شراب کهنه در بطری نو» گواه دیگری نیز دارد: ابزارها از قبل وجود داشتند.

• LangGraph: در ژانویه 2024 منتشر شد، تا ژوئیه 2026 ماهانه تقریباً 65 میلیون بار دانلود شده است. این یک موتور اجرای گراف برای ایجنت‌ها است — گره‌ها می‌توانند ایجنت باشند، یال‌ها می‌توانند مسیریابی شرطی، نقاط بازرسی و وقفه‌ها را حمل کنند.
• الگوهای پنج‌گانه Anthropic: مقاله ساخت ایجنت‌های کارآمد در دسامبر 2024 پیش از این گراف‌های مربوط به زنجیره‌سازی پرامپت، مسیریابی، موازی‌سازی، هماهنگ‌کننده-کارگران و ارزیاب-بهینه‌ساز را رسم کرده بود. فقط آن را مهندسی گراف ننامیده بود.
• انشعاب زیرایجنت در Claude Code: هنگامی که به یک ایجنت اصلی اجازه می‌دهید مجموعه‌ای از زیرایجنت‌ها را به صورت موازی ایجاد کند، از قبل در حال ساخت یک گراف هستید — فقط متوجه آن نشده بودید.
• ماشین‌های حالت، زمان‌بندهای DAG، صف‌های وظایف، گراف‌های دانش: علوم کامپیوتر دهه‌هاست که به مهندسی گراف‌ها مشغول است.

چه چیزی واقعاً جدید است؟ گره از «تابع» به «ایجنت» تبدیل شد. این تنها تغییر است — و تمام ماجرا همین است. پیش از این، نوشتن یک گره در جریان کاری به معنای کدنویسی دستی منطق آن، مدیریت خطا و سیاست تلاش مجدد بود. اکنون یک گره به یک دستورالعمل نیاز دارد — «درباره این مشکل تحقیق کن»، «این کد را بازبینی کن» — و مدل بقیه کارها را انجام می‌دهد. گره‌ها ارزان شدند، بنابراین گراف‌ها ارزش رسم کردن پیدا کردند.

ساخت نخستین گراف از نقطه صفر#

نظریه کافی است. بیایید بسازیم. سازنده-بازبین در درس قبل یک ایجنت بود که حلقه می‌زد. اولین کاری که مهندسی گراف انجام می‌دهد تفکیک آن ایجنت یکپارچه است: هر گره به یک ایجنت تخصصی با پرامپت، زمینه، ابزارها، حافظه و حلقه کوچک اختصاصی خود تبدیل می‌شود؛ گره‌ها زمینه را با یکدیگر به اشتراک نمی‌گذارند — آن‌ها فقط از طریق یک وضعیت مشترک دست‌به‌دست می‌شوند. این نسخه ساده و روان جمله روهیت است — «گراف تصمیم می‌گیرد هر گره چه چیزی ببیند، چه زمانی اجرا شود، خروجی‌اش به کجا برود، چه کسی بتواند آن را رد کند و چه چیزی سیستم را متوقف سازد.» هیچ‌یک از نشانه‌گذاری‌های زیر به موتور خاصی وابسته نیست — این‌ها مفاهیم هستند؛ LangGraph، CrewAI و بقیه صرفاً پیاده‌سازی‌هایی هستند که آن‌ها را به برنامه‌های اجرایی تبدیل می‌کنند؛ رابط‌های برنامه‌نویسی مختلف، اما اسکلت یکسان. شش گام — هیچ‌کدام را جا نیندازید.

گام 1: تعریف وضعیت مشترک. ابتدا دو لایه را از هم تفکیک کنید: در سطح گراف، تنها وضعیت به اشتراک گذاشته می‌شود؛ زمینه گره خصوصی است. یک ایجنت یکپارچه یک زمینه دارد و در یک اجرای طولانی در رونوشت خود غرق می‌شود؛ یک گراف زمینه را به قطعاتی تقسیم می‌کند، یکی برای هر گره — حلقه دارایی خصوصی گره است، گراف نیمکت مشترکی است که روی آن تحویل کار را انجام می‌دهند. درباره محتویات وضعیت به دقت فکر کنید. مشخص کنید که هر فیلد چگونه ادغام می‌شود — وقتی گره‌های همزمان در یک فیلد می‌نویسند، آیا بازنویسی می‌شود، ضمیمه می‌گردد یا جمع زده می‌شود؟ این ویژگی یک فریم‌ورک نیست؛ این قاعده‌ای است که هنگام رسم گراف در graph.md می‌نویسید:

state = {
  "requirements": text,                # written by the research node
  "code":         text,                # written by the implement node
  "review":       "pass" | "fail",    # written by the verify node
  "attempts":     number,              # +1 per failure (merged by "sum" on concurrent writes)
}

گام 2: فهرست کردن گره‌ها — هر گره یک ایجنت کامل است (با حلقه اختصاصی خود). این تفاوت بنیادین میان یک گراف و یک جریان کاری است: گره جریان کاری یک تابع است؛ گره گراف یک ایجنت حامل حلقه کوچک اختصاصی خود است. یک گره وضعیت مشترک را می‌گیرد، کار خود را در زمینه خصوصی انجام می‌دهد و نتایج را به وضعیت مشترک بازمی‌گرداند. درون یک گره کدنویسی اغلب همان حلقه درس پیشین است:

# inside the implement node: a private little loop (last lecture's maker-checker loop)
node_implement(requirements):
    loop (at most 3 times):
        code = model(prompt=implementation instructions, context=requirements + last error)
        if tests_pass(code): return {"code": code}
    return {"error": "implementation failed 3 times"}

به سطر verify توجه کنید — این گره‌ای است که بیشترین احتمال خطا در آن وجود دارد. در یک ایجنت یکپارچه، «بازبینی» همچنان در همان زمینه اجرا می‌شود، بنابراین ایجنت خودش را بازبینی می‌کند؛ در یک گراف، verify باید زمینه‌ای کاملاً تازه دریافت کند — هرگز استدلال‌های implement را نمی‌بیند، بلکه فقط code موجود در وضعیت مشترک را مشاهده می‌کند. اینجاست که «بازبینی مستقل» در یک گراف واقعاً تحقق می‌یابد: جداسازی زمینه یک عارضه جانبی نیست، بلکه خود طراحی است.

گام 3: سیم‌کشی یال‌ها. کار را با ستون فقرات قطعی آغاز کنید: research ← implement ← verify ← merge ← end.

flowchart TD
    A([Start]) --> B[research]
    B --> C[implement]
    C --> D[verify]
    D --> E[merge]
    E --> F([End])

گام 4: نوشتن قواعد مسیریابی (مهم‌ترین گام). گره verify مستقیماً به merge وصل نمی‌شود — بلکه به یک تصمیم متصل می‌شود که تعیین می‌کند اجرا در مرحله بعد به کجا برود. اینجاست که «شکست‌ها به کجا بازمی‌گردند» صریح و روشن می‌شود. قواعد مسیریابی نام گره‌ها را بازمی‌گردانند، بنابراین کل گراف — از کجا می‌آید، به کجا می‌رود — در یک نگاه خواناست:

flowchart TD
    A([Start]) --> B[research]
    B --> C[implement]
    C --> D{verify}
    D -- pass --> E[merge]
    D -- fail --> C
    E --> F([End])

گام 5: ضمیمه کردن یک نقطه بازرسی (checkpoint). این یکی از بزرگ‌ترین تفاوت‌های میان یک گراف و یک اسکریپت تک‌باره است: وضعیت پس از هر مرحله ماندگار و ذخیره می‌شود، بنابراین اگر فرآیند متوقف شود، به جای شروع مجدد از صفر، از نقطه بازرسی از سر گرفته می‌شود. با داشتن این قابلیت، گراف شما امکان وقفه/ازسرگیری را رایگان به دست می‌آورد — و همچنین می‌توانید پیش از merge متوقف شوید تا منتظر تأیید انسان بمانید، که همان ظاهر «بازبینی انسانی» درس گذشته بر روی یک گراف است:

checkpoint = on(graph, every_step)   # save state after every step
graph.pause_before("merge")          # stop before merging, wait for approval

گام 6: اجرای گراف با یک نقطه ورود. در هر اجرا یک شناسه ریسه (thread id) ارسال کنید — نقطه بازرسی از آن برای تمایز میان اجراها استفاده می‌کند:

run(graph, entry={"requirements": "fix the login page bug"}, thread="session-1")

هنگامی که کارتان تمام شد، آن را با نمودار بالا تطبیق دهید: فایل graph.md دست‌نویس شما طرح اولیه است و کد نوشته‌شده در یک موتور، همان طرح اولیه است که به برنامه‌ای اجرایی تبدیل شده است. این دو باید تناظر یک‌به‌یک داشته باشند. اگر چنین نباشد — یا نمودار اشتباه است یا کد، و معنای «گراف مشکل را روی کاغذ می‌آورد» دقیقاً همین است: پیش از این، عدم تطابق از دید همه پنهان می‌ماند؛ اکنون در یک نگاه آشکار است. اگر پیاده‌سازی مرجع قابل اجرا می‌خواهید، فایل code/maker_checker_graph.py را ببینید — این فایل از LangGraph استفاده می‌کند، اما در پایان باید متوجه شوید: این فقط همین شش گام است.

پروژه‌های متن‌باز: پس از نام، پیش از نام#

ابتدا خط مرزی را مشخص کنید: «مهندسی گراف» نامی است که فقط پس از 18 ژوئیه 2026 وجود دارد. فریم‌ورک‌هایی که پیش از آن تاریخ متن‌باز شده‌اند «پروژه‌های مهندسی گراف پس از انتشار» نیستند. یکی از پروژه‌هایی که صریحاً از این نام استفاده می‌کند GraphARC است:

پروژه‌های پس از انتشار (پروژه‌ای که واقعاً مهندسی گراف نامیده می‌شود)

• GraphARC (ایجاد شده در ژوئیه 2026): خود را به عنوان «یک پیاده‌سازی سرتاسری از مهندسی گراف مطابق با پیشنهاد اندرو ان‌جی و پیتر اشتاینبرگر» توصیف می‌کند. این یک پروژه پایتونی در مراحل اولیه است. حرکت مفید این است که مدل هماهنگ‌سازی آن را بخوانید و تصمیم بگیرید که آیا این رویکرد با جریان کاری شما همخوانی دارد یا خیر.

پروژه‌های پیش از انتشار (آن‌ها این را مهندسی گراف نمی‌نامند — اما ابزارهایی هستند که عملاً با آن‌ها سیستم می‌سازید)

پیش از ژوئیه 2026، این ابزارها از یک تا سه سال قبل وجود داشتند: LangGraph (متن‌باز شده در 2024، بیش از 65 میلیون دانلود ماهانه، موتور پشت پیاده‌سازی مرجع بالا)، CrewAI، Microsoft Agent Framework، LlamaIndex Workflows، Google ADK، OpenAI Agents SDK، Mastra، Claude Agent SDK. آن‌ها «پروژه‌های پس از مهندسی گراف» نیستند — آن‌ها گواه این هستند که مهندسی گراف پیش از نام‌گذاری وجود داشته است. گره‌ها، یال‌ها، وضعیت مشترک و مسیریابی به مدت سه تا پنج سال در حال اجرا بوده‌اند؛ ماه ژوئیه صرفاً یک برچسب جدید به آن‌ها داد. یک موتور گراف مشکلات طراحی را حل نمی‌کند: گره‌ها، یال‌ها و نقاط بازرسی را به شما تحویل می‌دهد، اما به این پاسخ نخواهد داد که «کدام حلقه‌ها به کدام غذا می‌رسانند، چه کسی مالک اهداف است، چه کسی می‌تواند وتو کند.» تا زمانی که این پرسش‌ها حل نشوند، تغییر موتورها صرفاً همان طراحی بد را زیباتر جلوه می‌دهد.

آب سرد: گراف یک گلوله نقره‌ای نیست#

سه سطل آب سرد، از سبک‌ترین شروع می‌کنیم.

سطل اول: اعداد جعلی. پس از فراگیر شدن مهندسی گراف، ادعاهایی درباره «+18% دقت، −85% هزینه» بر اثر به‌کارگیری گراف‌ها منتشر شد. یک راستی‌آزمایی توسط بلاگر کره‌ای goddaehee (30 ژوئیه) نشان می‌دهد: این دو عدد واقعاً وجود دارند، اما از مقاله‌ای در مارس 2026 درباره نمودارهای لوله‌کشی و ابزاردقیق شیمیایی (P&ID) آمده‌اند — و 18% در مقایسه با تصویر خام سنجیده شده در حالی که 85% نسبت به یک خط پایه متفاوت ارزیابی شده است. بازاریابی دو عدد با خطوط پایه متفاوت را در یک داستان «قبل/بعد» چسبانده بود و آن مقاله حتی هرگز از عبارت «مهندسی گراف» استفاده نکرده است. هر زمان بازاریابی «مهندسی گراف به شما X% بهبود می‌دهد» را دیدید، منبع اصلی را طلب کنید.

سطل دوم: شکل هندسی دیوار باربر نیست (iii.dev). در بالا اشاره شد. یک حلقه صرفاً یک گراف با یک گره است؛ ماشین‌های حالت دهه‌هاست که اجرا می‌شوند. افرادی که اعلام می‌کنند «حلقه‌ها مرده‌اند» یا «گراف‌ها مرده‌اند» معمولاً هیچ‌کدام را با دقت نخوانده‌اند. الگوها را بیاموزید، نه اسم‌ها را.

سطل سوم: مالیات هماهنگ‌سازی (The Orchestration Tax). مقاله ادی عثمانی با عنوان مالیات هماهنگ‌سازی (مه 2026) دربردارنده سخت‌ترین واقعیت اقتصادی عصر گراف/چندایجنت است: شروع کردن یک ایجنت ارزان است. بستن حلقه روی آن گران است.

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

«شما قفل مفسر سراسری (GIL) ایجنت‌های هوش مصنوعی خود هستید. آن‌ها می‌توانند همگی همزمان اجرا شوند. اما هنگامی که کار هر یک از آن‌ها به درک واقعی از معماری یا حل تعارض‌های ادغام نیاز داشته باشد، آن کار باید قفل را به دست آورد. تنها یک قفل وجود دارد. و آن در دست شماست.»

به همین دلیل است که عبارت «پهنای باند بازبینی سقف نهایی است» از درس گذشته در اینجا بارزتر می‌شود: یک گراف باعث می‌شود ایجنت‌های بیشتری به صورت موازی اجرا شوند، اما قضاوت شما یک منبع سریالی است. موازی‌سازی نمی‌شود. افزودن گره‌ها بخشی را بهینه‌سازی می‌کند که هرگز گلوگاه نبوده است — گلوگاه همیشه همان پردازنده تک‌هسته‌ای و سریال است: یعنی شما.

چه زمانی واقعاً به یک گراف نیاز دارید#

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

1. وظیفه به واحدهای کاری مستقل تجزیه شود — بخش‌هایی که به یکدیگر وابسته نیستند و می‌توانند به صورت موازی اجرا شوند
2. مسیرهای انشعاب یا بازگشت به عقب وجود داشته باشد — «تست‌ها به کجا بازمی‌گردند»، «اطلاعات ناکافی به کجا بازمی‌گردد» مسیرهایی هستند که ارزش تصریح دارند
3. وضعیت میانی ارزش ذخیره‌سازی داشته باشد — بتوانید در نقاط بازرسی متوقف شوید و ادامه دهید، به جای اینکه از صفر شروع کنید
4. نتایج به طور صریح قابل راستی‌آزمایی باشند — هر گره تعریف انجام‌شده (definition of done) به صورت خودکار قابل بررسی داشته باشد
5. مزایای هماهنگ‌سازی > هزینه‌های هماهنگ‌سازی — زمان ذخیره‌شده از موازی‌سازی بر بار اضافی گراف و وضعیت مشترک آن بچربد

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

مفاهیم کلیدی#

• مهندسی گراف (Graph Engineering): عمل سازماندهی چندین ایجنت، حلقه، ابزار و ارزیاب در قالب یک گراف صریح (گره‌ها + یال‌ها + وضعیت مشترک + قواعد مسیریابی)، که پیوندها، وضعیت مشترک و انتخاب مسیر چندین واحد کاری را قابل طراحی، مشاهده‌پذیر و به صورت محلی قابل ترمیم می‌سازد.
• چهار لایه روی‌هم‌پشته‌شده: پرامپت ← زمینه ← حلقه ← گراف. هر لایه چیز متفاوتی را کنترل می‌کند (دستورالعمل، اطلاعات، زمان اجرا، سیستم)؛ لایه بعدی جایگزین لایه‌های قبلی نمی‌شود — بلکه آن‌ها را درون گره‌های خود قرار می‌دهد.
• چهار بخش یک گراف: گره‌ها (واحدهای کاری)، یال‌ها (تحویل کار)، وضعیت مشترک (فضای کاری مشترک)، قواعد مسیریابی (محل بعدی اجرا).
• سه شکست ساختاری تک‌حلقه: گودهارت (اعداد بالا رفتند، کسب‌وکار بدتر شد)، کوری رو به بالا (هرگز نمی‌پرسد «آیا این هدف درست است؟»)، تعارض (حلقه‌های مستقل یکدیگر را تضعیف می‌کنند). گراف این موارد را به طراحی صریح روابط تبدیل می‌کند.
• گراف ≠ جریان کاری: گره‌های جریان کاری توابع قطعی و یال‌ها کدهای هاردکدشده هستند؛ گره‌های گراف می‌توانند ایجنت‌های کامل باشند و یال‌ها می‌توانند به طور پویا مسیریابی کنند. گراف تعمیمی از جریان کاری است.
• لنگرها (Anchors): سازوکارهایی که شبکه‌ای از حلقه‌ها را به دنیای واقعی متصل می‌کنند (نتایج واقعی کسب‌وکار، حقیقت زمینی، بازرسی‌های تصادفی انسانی). ساده‌ترین بخش برای نادیده گرفتن در طراحی گراف، و بخشی که ابداً نمی‌توانید از آن چشم‌پوشی کنید.
• مالیات هماهنگ‌سازی (The Orchestration Tax): شروع ایجنت‌ها ارزان است، بررسی نتایج گران است. توجه شما تنها منبع سریالی است و افزودن گره‌ها آن را بهینه‌سازی نمی‌کند.

نکات کلیدی#

• مهندسی گراف جایگزین مهندسی حلقه نمی‌شود — بلکه بر روی آن بنا می‌گردد. یک حلقه گره‌ای در یک گراف است؛ سه مورد از درس گذشته (هدف، راستی‌آزمایی، شرط توقف) ساختار درونی گره را تشکیل می‌دهند.
• گراف تصمیم‌های به تعویق افتاده را به تصمیم‌های اولیه تبدیل می‌کند. حلقه حالت‌های شکست را درون خود پنهان می‌کند؛ گراف آن‌ها را روی کاغذ می‌آورد — خوانا، قابل ممیزی، و به صورت محلی قابل ترمیم.
• آنچه درون گره است تفاوت میان گراف و جریان کاری را رقم می‌زند. توابع یک جریان کاری می‌سازند؛ ایجنت‌ها یک گراف می‌سازند. این تنها شراب واقعاً جدید در بطری کهنه است.
• پیش از رسم گراف، چهار پرسش طراحی را پاسخ دهید: کدام حلقه‌ها به کدام غذا می‌رسانند، چه کسی مالک اهداف است، چه کسی می‌تواند وتو/بازگشت انجام دهد، کدام سنجه‌ها مجاز به تغییرند و کدام‌ها باید ثابت بمانند. اگر نمی‌توانید به آن‌ها پاسخ دهید، رسم نکنید.
• گراف‌ها را صرفاً به خاطر خود گراف رسم نکنید. پنج معیار: قابل تجزیه به بخش‌های مستقل، دارای انشعاب یا بازگشت، وضعیت میانی ارزش ذخیره داشته باشد، نتایج قابل راستی‌آزمایی باشند، مزایای هماهنگ‌سازی > هزینه‌های هماهنگ‌سازی باشد.
• پهنای باند بازبینی شما همچنان سقف نهایی است. گراف ایجنت‌های بیشتری را به صورت موازی اجرا می‌کند، اما قضاوت شما سریالی است — مالیات هماهنگ‌سازی به خاطر بیشتر شدن گره‌ها ناپدید نمی‌شود.
• استدلال مخالف را به یاد داشته باشید. شکل هندسی دیوار باربر نیست؛ قابلیت بازپخش، مشاهده‌پذیری و قابلیت بازیابی باربر هستند. اسم‌ها هر شش هفته تغییر می‌کنند. توانمندی مهندسی تغییر نمی‌کند.

مطالعه بیشتر#

• Prefect: Loops vs. Graphs (Jul 2026) — حلقه‌ها و گراف‌ها از دیدگاه شرکتی که دهه‌ها هماهنگ‌سازی گرافی را توسعه داده است
• Eigent: Graph Engineering for AI Agents (Jul 2026) — سه شکست ساختاری تک‌حلقه‌ها + چهار پرسش طراحی + لنگرها
• iii.dev: Loops, Graphs, and the Layer That Matters (Jul 2026) — روشن‌ترین استدلال مخالف: «شکل هندسی دیوار باربر نیست»
• Rohit (@rohit4verse): رشته‌توییت اصلی (Jul 29, 2026) — منبع اصلی چارچوب چهارلایه‌ای: پرامپت ← زمینه ← حلقه ← گراف، که هر لایه روی لایه قبلی سوار می‌شود
• Agent Times: Graph Engineering as the Final Layer (Jul 2026) — خلاصه‌ای شفاف از چارچوب چهارلایه‌ای روهیت
• goddaehee: Graph Engineering Fact-Check (KR, 2026-07-30) — کامل‌ترین راستی‌آزمایی: خط زمانی آغاز با شوخی، تحلیل اعداد جعلی، داده‌های LangGraph، مقایسه تب‌وتاب در Hacker News
• Josh Simmons: We Are Entering the Graph Engineering Phase (2026-07-04) — نوشته جدی منتشرشده دو هفته پیش از شوخی
• LangChain: 3 Years of Graph Engineering with LangGraph (2026-07-22) — پاسخ رسمی: «ایده جدیدی نیست، تازه‌ترین نام برای یک رویکرد کاملاً تثبیت‌شده است»؛ دانلود ماهانه بیش از 65 میلیون LangGraph
• explainx: Graph Engineering: AI Agents as Multi-Agent Organizations (2026-07) — روایتی از چگونگی گسترش این اصطلاح
• LangChain: The Best AI Agent Frameworks in 2026 — مقایسه رودرروی هفت فریم‌ورک متن‌باز جریان اصلی: LangGraph، CrewAI، Microsoft Agent Framework، LlamaIndex، Google ADK، OpenAI Agents SDK، Mastra
• مستندات رسمی LangGraph — «گره‌ها کار را انجام می‌دهند، یال‌ها می‌گویند بعداً چه شود»؛ تعاریف دقیق گره‌ها و یال‌ها، مرجع دست‌اول برای ساخت گراف‌ها
• Anthropic: Building Effective Agents (Dec 2024) — پنج الگویی که با رسم شدن تبدیل به گراف می‌شوند؛ تمایز معتبر جریان کاری در برابر ایجنت
• Addy Osmani: The Orchestration Tax (May 2026) — چرا توجه شما تنها منبع سریالی است
• Addy Osmani: Orchestrating Coding Agents (talk) — از زیرایجنت‌ها تا تیم‌های ایجنتی و گیت‌های کیفی
• Addy Osmani: Loop Engineering (Jun 2026) — مرجع محوری درس گذشته؛ پیش‌نیاز مهندسی گراف
• درس 13: از پرامپت دستی تا حلقه‌های خودمختار — یک حلقه، گره‌ای در یک گراف است؛ پیش از درک گراف، گره را بشناسید
• درس 11: چرا مشاهده‌پذیری به درون هارنس تعلق دارد — هر چه گراف پیچیده‌تر باشد، مشاهده‌پذیری اهمیت بیشتری پیدا می‌کند؛ یک گراف مشاهده‌ناپذیر صرفاً جعبه سیاهی بزرگ‌تر است
• درس 09: چرا ایجنت‌ها خیلی زود اعلام پیروزی می‌کنند — چرا گره verify باید از گره implement مستقل باشد؛ در یک گراف این یک مشکل ساختاری است، نه مشکل پرامپت

تمرین‌ها#

1. حلقه سازنده-بازبین P07 خود را به صورت یک گراف ترسیم کنید: گره‌ها، یال‌ها، وضعیت مشترک و قواعد مسیریابی را به صورت صریح در یک فایل graph.md بنویسید. مشخص کنید کدام یال‌ها شرطی هستند (verify قبول شد/رد شد) و کدام یال‌ها یال بازگشت به عقب هستند (رد شد به implement). پس از اتمام، پاسخ دهید: آیا یالی وجود داشت که ضمنی بوده باشد — یعنی قبلاً درون زمینه ایجنت پنهان شده باشد؟

2. به چهار پرسش eigent پاسخ دهید: سه حلقه مستقلی را که اجرا می‌کنید (یا سه اتوماسیون در یک پروژه یکسان) بیابید و پاسخ دهید: کدام حلقه‌ها ورودی کدام‌ها را تأمین می‌کنند؟ کدام حلقه مالک هدفی است که دیگری دنبال می‌کند؟ آیا حلقه‌ای وجود دارد که بتواند خروجی دیگری را وتو کند؟ کدام سنجه‌ها به شیوه‌هایی بهینه‌سازی می‌شوند که ممکن است دچار تعارض شوند؟

3. خودآزمایی گودهارت: سنجه‌ای را بررسی کنید که اخیراً در حال بهینه‌سازی آن بوده‌اید. وقتی بالا رفت، آیا نتیجه واقعی (نتایج کسب‌وکار، بازخورد کاربران، کیفیت کد) نیز بهتر شد؟ اگر فقط عدد بالا رفت، این حلقه در چه جهتی یاد می‌گیرد به شما دروغ بگوید؟

4. امتیازدهی به یک کاندیدا با معیارهای پنج‌گانه: وظیفه‌ای را انتخاب کنید که در مورد «گراف کردن» آن مردد هستید و بر اساس معیارهای پنج‌گانه به آن امتیاز دهید. برای اینکه ارزش گراف شدن داشته باشد به حداقل سه معیار نیاز دارد. اگر کمتر از سه امتیاز گرفت، آنچه در واقع نیاز دارد یک اسکریپت جریان کاری بهتر است — صرفاً برای رسم گراف، گراف نکشید.

5. تبدیل graph.md خود به یک برنامه اجرایی: شش گام در بخش «ساخت نخستین گراف از نقطه صفر» را دنبال کرده و نمودار سازنده-بازبین خود را به عنوان یک گراف قابل اجرا پیاده‌سازی کنید (پیاده‌سازی مرجع: code/maker_checker_graph.py که با LangGraph نوشته شده است). هیچ‌یک از این شش گام را جا نیندازید: تعریف وضعیت، فهرست کردن گره‌ها، سیم‌کشی یال‌ها، نوشتن مسیریاب، ضمیمه کردن نقطه بازرسی، اجرای آن. سپس تفاوت‌های نمودار و کد را بررسی کرده و نخستین جایی را که با هم تطابق ندارند بیابید و دلیل آن را توضیح دهید — آیا نمودار اشتباه بود یا کد؟