تصور کنید میخواهید برای یک عامل هوش مصنوعی، یک گراف اجرای پیچیده رسم کنید؛ در واقع شما دارید سعی میکنید آینده را پیشبینی کنید. ctxloom، یک محیط اجرای متنباز برای عاملها، استدلال میکند که مسائل مربوط به دانش، «گردشکار» (Workflow) نیستند و نباید با آنها اینگونه برخورد شود.
بسیاری از چارچوبهای فعلی، توسعهدهندگان را مجبور میکنند گرهها را به هم متصل کنند، حافظه را سیمکشی کنند و جریانهای کنترلی سختگیرانهای تعریف کنند. طبق گزارش توسعهدهندگان این پروژه، این روش زمانی شکست میخورد که یک پرسش — مثلاً «چرا هزینههای زیرساختی در سه ماهه دوم افزایش یافت؟» — نیازمند مسیری پویا باشد؛ مسیری که از اسناد Confluence شروع شده، به درخواستهای ادغام GitLab میرود، دادههای CSV مربوط به هزینهها را تحلیل میکند، یک محاسبه انجام میدهد، منابع را تأیید میکند و شاید در نهایت نیاز به یک سؤال شفافساز از کاربر داشته باشد. در چنین سناریوهایی، گام بعدی کاملاً به یافتههای گام قبلی بستگی دارد و تعریف یک گراف جامع و جهانی که بتوان آن را نگهداری کرد، غیرممکن است.
ctxloom با تکیه بر چالشهای صنعت در زمینه قابلیت اطمینان عاملها، پارادایم «سیمکشی» را به «واکنش» تغییر میدهد. این سیستم، حلقهٔ عمل عامل را به صورت توالیِ خلق «مصنوعات» (Artifacts) و واکنش به آنها میبیند: یک مصنوع ایجاد میشود، عاملها به آن واکنش نشان میدهند، یک تغییر اتمی اعمال میشود و زمینه (Context) پیش میرود. همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، مدیریت دقیق وضعیت سیستم، کلید دستیابی به قابلیت اطمینان در مدلهای پیچیده است. این رویکرد در واقع پاسخی به این چالش است که چرا بسیاری از عاملهای هوش مصنوعی در مقیاس بالا و بدون معماریهای حلقوی شکست میخورند.
سازوکار واکنشگرا
در این سیستم هیچ خط لولهای از گرهها وجود ندارد. بهجای آن، محیط اجرا بر اساس تغییرات وضعیت تصمیم میگیرد چه چیزی اجرا شود. این چرخه از یک الگوی مشخص پیروی میکند: ایجاد مصنوع $\rightarrow$ واکنش عاملها $\rightarrow$ اعمال یک وصله (Patch) اتمی $\rightarrow$ پیشروی زمینه.
بهعنوان مثال، یک پرسش دانشبنیان درباره «هزینه استنتاج GPU چقدر است؟» زنجیرهای از مصنوعات تایپشده را فعال میکند:
- UserQuery $\rightarrow$ TypedDoc $\rightarrow$ Evidence $\rightarrow$ Claim $\rightarrow$ Answer
هر مرحله توسط عاملی مدیریت میشود که یک نوع مصنوع خاص را مصرف و نوع دیگری را تولید میکند. چون رویدادی که عامل را بیدار میکند مستقیماً از تغییر وضعیت سیستم مشتق شده، زنجیرهٔ علّی هرگز از وضعیت واقعی سیستم فاصله نمیگیرد و دچار انحراف نمیشود.
جزئیات پیادهسازی
توسعهدهندگان عاملها را با استفاده از دکوراتور produce و مدلهای Pydantic برای مدیریت وضعیت تعریف میکنند. برای مثال، یک عامل analyze_question به یک Question واکنش نشان داده و یک Finding تولید میکند. سپس عامل دوم یعنی concluder به آن یافته واکنش نشان داده تا یک Conclusion ایجاد کند.
- پیوند منشأ (Provenance Linking): عامل نتیجهگیر با استفاده از دستور
conclusion.link("supported_by", finding)یک لبهٔ منشأ ایجاد میکند تا سیستم دقیقاً بداند چه چیزی پاسخ نهایی را پشتیبانی میکند و ردپای استدلال حفظ شود. - تضعیف تدریجی (Graceful Degradation): سیستم از فراخوانی
structured_llmاستفاده میکند. اگر مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — پاسخ ندهد یا شکست بخورد، سیستم مقدارNoneبرمیگرداند تا بهجای توهم (Hallucination)، اجرای برنامه بهصورت کنترلشده متوقف شود و سیستم بهطور تدریجی تضعیف گردد. - کنترل محیط اجرا: اجرا توسط یک شیء
Runtimeبا بودجهای مشخص (مثلاًmax_runs=20) مدیریت میشود تا از ایجاد حلقههای بینهایت جلوگیری شود.
اثرات اتمی و قطعیت
برخلاف چارچوبهایی که واحدهای کاری نتیجه را به یک ارکستراتور برمیگردانند، ctxloom از مدل «اثرات» (Effects) استفاده میکند. در این مدل، تولیدکننده اعلام میکند چه چیزی باید تغییر کند و مقدار None برمیگرداند.
این رویکرد تضمین میکند که یک «کامیت» اتمی رخ دهد؛ یعنی هیچ تغییری اعمال نمیشود مگر اینکه تابع تولید بهطور کامل بازگردد. یا کل مرحله بهطور کامل ثبت میشود یا هیچکدام از آن اعمال نمیشود. این مکانیسم مانع از ایجاد وضعیتهای نیمهاعمالشده شده و نیاز به ساختارهای پیچیده برای بازگشت دستی (Rollback ladders) را از بین میبرد. علاوه بر این، دستگیرهها (Handles) بهجای شناسهها (IDs)، به عنوان اشیاء در نظر گرفته میشوند؛ این یعنی یک عامل میتواند یک شیء Evidence ایجاد کند و بلافاصله آن را پیوند دهد، بدون اینکه نیاز به یک جستجوی ثانویه در دیتابیس باشد.
حضور انسان در حلقه (Human-in-the-loop) نیز به عنوان یک اثر درجهیک ادغام شده است. با استفاده از self.effects.ask(...) سؤال از کاربر پرسیده میشود و با effects.resume(...) پاسخ دریافت و اجرا بازخواسته میگردد؛ بنابراین انسانها دیگر یک مورد خاص نیستند که به صورت وصلهای به معماری اضافه شده باشند، بلکه بخشی از جریان اثرات هستند. این سطح از کنترل دقیق، در واقع همان استقلال محدود است که برای خروج عاملها از محیطهای دمو و ورود به محیطهای عملیاتی ضروری است.
بر اساس مستندات ctxloom، مرز سختگیرانهای بین وظایف زاینده (Generative) و قطعی (Deterministic) وجود دارد. قانون ساده است: اگر وظیفهای قابل محاسبه است — مثل تبدیل CSVSource $\rightarrow$ Spreadsheet $\rightarrow$ Calculation روی دادههای ساختاریافته — باید حتماً توسط کد قطعی انجام شود، نه LLM. مدل تنها برای زبان و قضاوت به کار میرود تا نرخ توهم کاهش یابد. در صورت شکست، تابع تولید بهجای ارائه یک حدس مطمئن، مقدار None برمیگرداند.
منشأ ساختاری
هر اجرا در ctxloom مانند یک کامیت در گیت در نظر گرفته میشود که امکان Diff، بازگشت (Rollback) و شاخهبندی (branch) و ادغام (merge) وضعیت گفتگو را فراهم میکند. این قابلیت، بازپخش قطعی (Deterministic Replay) را برای اهداف حسابرسی و بازبینی ممکن میسازد.
این ساختار یک ردپای حسابرسی ساختاری ایجاد میکند که در آن هر پاسخ به ادعای پشتیبان، هر ادعا به شواهد و هر شاهد به سند منبع متصل است:
Answer $\rightarrow$ supported_by $\rightarrow$ Claim $\rightarrow$ derived_from $\rightarrow$ Evidence $\rightarrow$ extracted_from $\rightarrow$ Doc
این «منشأ رایگان» به این معناست که وقتی عاملی پاسخی میدهد، کاربر میتواند از طریق لینکها به عقب برگردد و دقیقاً ببیند چرا عامل چنین گفته است. این رویکرد، پاسخگویی را از یک ویژگی ظاهری به یک الزام ساختاری تبدیل میکند.
پیادهسازی عملی
این محیط اجرا شامل ۱۳ مثال قابل اجرا و آفلاین است که نیازی به کلید API ندارند. این مثالها حوزههای زیر را پوشش میدهند:
- دانش و پژوهش: یک چت دانش چندمنبعی با پاسخهای مستند، یک پژوهشگر وب و یک آزمایشگاه فرضیه.
- عملیات: یک دستیار عملیاتی (Ops assistant) و مثالی از بازسازی اتاق که برنامهریزی، تخمین هزینهها و خروجی CSV را مدیریت میکند.
- مدیریت وضعیت: برنامهریزی مجدد با در نظر گرفتن بودجه و اکتشافات از طریق شاخهبندی و ادغام.
همچنین یک ماتریس تبدیل (Port matrix) ارائه شده که الگوهای سنتی عاملها — مانند ReAct، بازتاب (Reflection)، Map-Reduce، ناظر (Supervisor)، تلخیص (Summarize)، سفر در زمان (Time-travel) و برنامهریزی و اجرا (Plan-and-execute) — را به این زبان واکنشگرا ترجمه میکند. برای استقرار نیز یک لایه وب سبک با استفاده از ChatAssistant و create_chat_router فراهم شده است تا چتهای SSE با وضعیت ذخیرهشده در نشست (Session) روی برنامههای FastAPI نصب شوند و از Fallbackهای ثبتشده برای جلوگیری از خطاهای ۵۰۰ استفاده کنند.
چه زمانی از واکنشگرایی اجتناب کنیم؟
توسعهدهندگان اذعان دارند که این رویکرد جهانی نیست. برای خط لولههای ثابت که تسکها در یک توالی سختگیرانه (مثلاً پنج مرحلهای) بدون عناصر واکنشگرا هستند، گرافهای کلاسیک یا توابع ساده همچنان ابزار برترند.
همچنین برای «پلیگراندها» که هدف فقط این است که مدل «خودش راه را پیدا کند» و کاربر اهمیتی به قطعیت، منشأ پاسخ یا پاسخگویی نمیدهد، تشریفات و ساختار ctxloom ممکن است غیرضروری باشد.
با این حال، برای هر عاملی که وظیفه جمعآوری شواهد، تأیید ادعاها، محاسبه دادهها، رعایت بودجه یا تعامل با انسان را دارد، گذار به سمت واکنشگرایی جایگزینی مقیاسپذیرتر و قابلحسابرتر نسبت به رسم دستی گرافهاست.
این تغییر نشان میدهد که آینده هوش مصنوعی عاملمحور نه در ارکستراسیون بهتر LLMها، بلکه در مدیریت بهتر وضعیت (State) و مصنوعاتی است که این مدلها تولید میکنند. با تبدیل LLM به یک جزء استدلالی بهجای منبع حقیقت، توسعهدهندگان میتوانند سیستمهایی بسازند که واقعاً پاسخگو باشند.
گام بعدی شما
- اگر از LangGraph یا CrewAI استفاده میکنید، بررسی کنید آیا جریانهای کاری شما واقعاً خطی هستند یا در واقع به تغییرات وضعیت واکنش میدهند.
- بسته را از طریق
pip install "ctxloom[web]"نصب کنید و دموی دانش را با دستورpython ./examples/knowledge/web.pyاجرا کنید تا حلقه «شاهد به پاسخ» را در عمل ببینید. - در پروژههای حساس، وظایف محاسباتی را از LLM جدا کرده و به توابع قطعی منتقل کنید تا توهمات مدل را به صفر برسانید.
اما مدیریت حافظه در این سیستمها حتی پیچیدهتر است — به تحلیل ما دربارهی پروتکل MCP و مدیریت زمینه مراجعه کنید.
گفتگو