تصور کنید میخواهید سیستمی بسازید که بسته به دادههای دریافتی، مسیرش را عوض کند؛ در مدلهای فعلی، شما باید هر مسیر احتمالی را مثل یک نقشه پیچیده از پیش رسم کنید. اما اگر بتوانید به جای رسم نقشه، فقط به عاملها بگویید چه چیزی تولید میکنند و چه چیزی نیاز دارند، سیستم خودش مسیر را پیدا میکند.
مدیریت گردشکارهای پیچیده در عاملهای هوش مصنوعی (AI Agents) اغلب به یک تمرین سیمکشی دستی تبدیل میشود که به محض مقیاسپذیر شدن مسئله، از هم میپاشد. reactifact (که پیشتر با نام ctxloom شناخته میشد) با حذف کامل مفاهیم گره و یال — که در ابزارهای پیشرویی مثل LangGraph یا CrewAI رایج است — قصد دارد این بنبست را بشکند.
اکثر چارچوبهای فعلی از توسعهدهنده میخواهند دقیقاً تعیین کند کدام مرحله بعد از مرحله دیگر میآید. در LangGraph این ساختار به شکل گرهها و یالهاست و در CrewAI به صورت نقشهها در یک گروه. این روش برای خط لولههای خطی عالی است، اما وقتی با یک پرسوجوی واقعی روبرو میشویم — مثلاً تحلیل جهش هزینههای زیرساختی یک فصل — سیستم باید بهطور پویا از ابزارهایی مثل Confluence، GitLab و ماشینحسابهای CSV استفاده کند و سپس تأیید انسانی بگیرد. در چنین شرایطی، کدنویسی تمام مسیرهای ممکن به عنوان یالهای گراف، تبدیل به یک کابوس نگهداری میشود.
به گزارش وبسایت dev.to در تاریخ ۱۴ سپتامبر ۲۰۲۶، نسخه ۰.۷.۰ reactifact جریان کنترل را از یالهای دستی به اعلانهای «مصرف/تولید» منتقل کرده است. در این مدل، زمان اجرا (Runtime) بر اساس اینکه چه مصنوعات (Artifacts) — شبیه به قطعات لگویی که هر کدام جایگاه مشخصی دارند — در محیط موجود است، تصمیم میگیرد چه اتفاقی بیفتد. دو عامل که هرگز بهطور صریح به هم متصل نشدهاند، میتوانند بهدرستی با هم ترکیب شوند، به شرطی که یکی دادهای را تولید کند که دیگری به آن نیاز دارد. بنابراین دیگر نیازی به همگامسازی نمودارهای پیچیده نیست، چون سیمکشی از دل تعریف انواع داده بیرون میآید.
همانطور که در تحلیلهای قبلی ما دربارهی چالشهای ارکستراسیون مدلهای زبانی اشاره کردیم، وابستگی به ساختارهای صلب، بزرگترین مانع برای رسیدن به عاملهای خودگردان است.
مدل مصنوعات (Artifact Model)
به جای استفاده از یک دیکشنری مشترک برای وضعیت (State) — که ساختارش در زمان اجرا مشخص میشود و ابزارهای بررسی نوع (Type Checkers) نمیتوانند آن را تأیید کنند — reactifact از مصنوعات نسخهبندی شده بر پایه مدلهای Pydantic استفاده میکند.
در این مدل، یک عامل تنها یک ظرف سبک است و منطق اصلی در کلاس Produce یا توابعی با دکوراتور @produce قرار دارد. توسعهدهنده تغییرات (ایجاد، بهروزرسانی، لینک یا درخواست) را در self.effects مینویسد و سیستم این اثرات را در یک وصله (Patch) اتمیک کامپایل میکند.
این چرخش معماری مزایای فنی مشخصی دارد:
- تغییرناپذیری (Immutability): هر مصنوع دارای نوع، شناسه، نسخه و برچسب زمانی است. هیچ دادهای در جای خود بازنویسی نمیشود و هر بهروزرسانی، نسخهای جدید میسازد.
- قابلیت بازرسی: توسعهدهندگان میتوانند با دستور
context.diff(v1, v2)دقیقاً ببینند وضعیت چگونه تغییر کرده است، بدون اینکه نیاز باشد رویدادها را از میان لاگهای پراکنده بازسازی کنند. این رویکرد دقیقاً همان فلسفهای است که در تغییر رویکرد از Log Stream به Run Card برای دیباگینگ عاملها دنبال میشد تا ردیابی وضعیت در سیستمهای پیچیده تسهیل شود. - منشأ داده (Provenance): ایجاد لینک یک مکانیزم درجهیک است. با استفاده از
effects.linkرابطهای پرسوجوپذیر بین پاسخ و شواهد ایجاد میشود که میتوان آن را به صورت نمودارهای Mermaid رندر کرد. - مکانیزم بازگشت (Rollback): سیستم از همین لینکها استفاده میکند تا بفهمد بعد از یک بازگشت یا ادغام سه-طرفه، دقیقاً چه بخشهایی باید دوباره اجرا شوند.
قابلیتهای جدید در نسخه ۰.۷.۰
هدف اصلی این نسخه، کاهش اصطکاک در مقیاس بالا و تثبیت API پیش از عرضه نسخه ۱.۰ است. همچنین پشتیبانی از OAuth در client_credentials برای پروتکل زمینهٔ مدل (MCP) اضافه شده است.
یکی از اضافات کلیدی، DeferredToolGroup است که مشکل «تورم زمینه» (Context Bloat) را حل میکند. در حالت عادی، اتصال چندین سرور MCP به معنای ریختن تمام طرحوارههای ابزارها در پرامپت سیستمی است که باعث هدر رفتن فضای پنجرهٔ زمینه (Context Window) — شبیه به میز کاری که از شدت شلوغی جا برای نوشتن ندارد — در هر فراخوانی میشود.
با DeferredToolGroup توسعهدهنده ابزارها را پشت یک نام و توصیف ثبت میکند. مدل ابتدا فقط یک ورودی تکخطی میبیند و تنها زمانی که واقعاً به ابزاری نیاز داشته باشد، طرحوارههای آن را بارگذاری میکند. این بارگذاری در هر اجرا حداکثر یک بار و بر اساس نیاز رخ میدهد.
علاوه بر این، یک OTLPTracer مستقل از فروشنده معرفی شده است. در حالی که نسخههای قبلی به Langfuse وابسته بودند، ردیاب جدید از کنوانسیونهای معنایی هوش مصنوعی زاینده (Generative AI) استفاده میکند و دادهها را بدون نیاز به وابستگیهای جدید، به هر جمعکننده OTLP ارسال میکند.
موازنه و محدودیتها
این رویکرد جایگزینی جهانی نیست. نویسنده اشاره میکند که برای خط لولههای کاملاً ثابت (A ← B ← C) که هیچ انشعابی بر اساس داده ندارند، یک گراف ساده یا تابع معمولی، پیچیدگی کمتری نسبت به مدلسازی مصنوعات دارد.
سایر محدودیتها عبارتند از:
- در دسترس بودن پلتفرم: reactifact یک کتابخانه است، نه یک سرویس ابری (SaaS). بنابراین فاقد پلتفرمهای مدیریتی است که در LangGraph یا CrewAI Enterprise دیده میشود.
- اندازه اکوسیستم: تعداد تجربیات عملی از استقرار این ابزار در محیط تولید کمتر است. هرچند استفاده از MCP این فاصله را کم میکند، اما تلاش نمیکند در زمینه بازیابی منابع از رقبای بزرگتر پیشی بگیرد.
- نگهداری: پروژه فعلاً در مرحله پیش از ۱.۰ است و توسط یک نگهدارنده واحد مدیریت میشود.
برای توسعهدهنده، این تغییر یعنی توقف رسم نمودار و شروع به تعریف قراردادهای داده. سیمکشی حالا یک ویژگی نوظهور از انواع دادههای تعریف شده است؛ یعنی سیستم با افزودن انواع مصنوعات جدید تکامل مییابد، نه با بازترسیم نقشه.
اگر در حال ساخت سیستمی هستید که مسیر رسیدن به پاسخ بر اساس دادههای کشفشده در میانه راه تغییر میکند، مدل مبتنی بر مصنوعات نیاز به پیشبینی تمام شاخهها را از بین میبرد. این مدل، اندازه اکوسیستم را فدای خلوص معماری و عیبیابی آسانترِ تغییرات وضعیت میکند.
گام بعدی شما
- اگر از LangGraph خسته شدهاید، کتابخانه را با
pip install reactifactنصب کنید و مدل مصنوعات را تست کنید. - نمونههای ادغام (merge) و شاخه (fork) را در گیتهاب پروژه بررسی کنید تا درک بهتری از مدیریت وضعیت بدون گراف پیدا کنید.
- برای کاهش هزینه توکنها، قابلیت
DeferredToolGroupرا در پروژههایی که ابزارهای متعددی دارند پیادهسازی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو