تصور کنید از یک هوش مصنوعی می‌پرسید چرا شرایط خدمات یک محصول تغییر کرده است و پاسخی دقیق دریافت می‌کنید: «عامل شماره ۱۲ در فراخوانی ابزار شماره ۳۲ این تغییر را اعمال کرد، زیرا تصمیم شماره ۲۳۴ در ۱۲ اوت توسط مدیر انسانی در پاسخ به تغییر مقررات Y تأیید شده بود». این سطح از دقت در استقرار فعلی هوش مصنوعی وجود ندارد و اکثر سیستم‌ها به پنجره‌های زمینهٔ شکننده و جست‌وجوی معنایی متکی هستند.
بسیاری از توسعه‌دهندگان، «فراموشی» یا رانش زمینه (Context Drift) در مدل‌ها را یک نقص فنی می‌بینند که باید با بزرگ‌تر کردن پنجرهٔ زمینه (Context Window) — شبیه به میز کاری که هرچه بزرگ‌تر باشد، ورق‌های بیشتری را هم‌زمان در دسترس دارد — یا بهبود پایگاه‌داده‌های برداری (Vector Database) حل شود. این چالش‌ها در واقع بخشی از تقابل میان ذخیره‌سازهای معنایی و حافظه خطی برای حفظ دستورات اولیه هستند که بر نحوه تعامل عامل‌ها با داده‌های بلندمدت تأثیر می‌گذارد. اما طبق یک پیشنهاد معماری مفصل که در ۱۴ سپتامبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این موضوع یک شکست سیستمی در طراحی سازمانی است، نه یک مشکل حافظه. نویسنده استدلال می‌کند که سازمان‌ها در واقع شبکه‌هایی از تصمیمات هستند که به ورودی‌ها واکنش نشان می‌دهند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر احتمالات در محیط‌های حساس ریسک بالایی دارد. در همین راستا، این معماری جدید بر مفهوم «واقعیت عملیاتی» تأکید می‌کند.
مفهوم واقعیت عملیاتی
راهکار پیشنهادی، چارچوبی به نام واقعیت عملیاتی (Operational Reality) است. این مدل تمرکز را از «به یاد آوردن» گفتگوها به حفظ یک وضعیت قطعی و مشترک از تصمیمات تغییر می‌دهد. بر اساس این دیدگاه، یک سازمان از طریق یک حلقه بازخورد داخلی عمل می‌کند که منجر به نقاط تماس با دنیای بیرون می‌شود و سپس یک حلقه بازخورد خارجی را تجربه می‌کند. این چرخه (ورودی $\rightarrow$ استدلال $\rightarrow$ تصمیم) کل سطح تصمیم‌گیری سازمان را تعریف می‌کند.
در یک سازمان مدرن، شبکه تصمیم‌گیری یک گراف ترکیبی است که در آن انسان‌ها قدرت تصمیم‌گیری دارند و عامل‌های هوش مصنوعی (AI Agents) سرعت اجرا را فراهم می‌کنند. هوش مصنوعی در اینجا مانند یک کاتالیزور فعال عمل می‌کند که سرعت تغییر واقعیت عملیاتی را به‌شدت افزایش می‌دهد. این شتاب در اجرا اگر بدون نظارت ساختاری باشد، می‌تواند منجر به ایجاد سیستم‌های شکننده به دلیل حذف فرآیندهای بازسازی کد در لایه‌های زیرین نرم‌افزاری شود.
برای جلوگیری از تضاد این دو نیرو، این چارچوب «استدلال» را از «تصمیم» جدا می‌کند. در حالی که استدلال سیال و احتمالی است، تصمیمات قطعی هستند و از وضعیت‌های مشخصی عبور می‌کنند. این جداسازی به چهار دلیل ضروری است:
- تداوم کسب‌وکار: انسان‌ها و مدل‌ها در طول زمان جایگزین می‌شوند، اما تصمیمات زیربنایی باید باقی بمانند.
- قابلیت حسابرسی: ثبت دقیق دلیل تغییر یک وضعیت.
- کنترل انسانی: حفظ قدرت تصمیم‌گیری بدون ایجاد گلوگاه در اجرا.
- بهینه‌سازی: جداسازی حوزه‌های فنی و عملکردی.
ماشین وضعیت تصمیم‌گیری
در پیاده‌سازی Smeldr (به‌ویژه در بخش orchDecisionFlow)، تصمیمات صرفاً متنی نیستند، بلکه اشیایی در یک ماشین وضعیت‌اند. این تصمیمات از پنج وضعیت مشخص عبور می‌کنند:
- پیشنهادی (Proposed)
- تأییدشده (Ratified)
- جایگزین‌شده (Superseded)
- در انتظار ارزیابی مجدد (Pending-re-evaluation)
- بایگانی‌شده (Archived)
هر یک از این انتقال‌ها دارای برچسب زمانی، هویت عامل تغییردهنده و دلیل مشخصی است. این ساختار یک ردپای حسابرسی دائمی ایجاد می‌کند که نیاز به «تفسیر» در جلسات بررسی کسب‌وکار را از بین می‌برد.
ترسیم گراف تصمیمات
این سیستم از یال‌های جهت‌دار برای تعریف رابطه بین تصمیمات استفاده می‌کند تا استدلال ساختاریافته و تحلیل اثرات ممکن شود. این روابط شامل موارد زیر است:
- پاسخ می‌دهد به (Addresses): پیوندی که در آن یک تصمیم، پرسشی باز در تصمیم دیگر را حل می‌کند.
- جایگزین می‌شود (Supersedes): وقتی تصمیم جدید جایگزین تصمیم قدیمی می‌شود.
- تضاد دارد (Contradicts): پرچمی که نشان‌دهنده یک تعارض واقعی است.
- وابسته است به (Depends_on): پیوند بین دو وظیفه.
- مشتق شده از (Derives_from): پیوند بین یک وظیفه و یک هدف.
- بررسی می‌کند (Investigates): پیوند بین یک وظیفه و یک تصمیم.
به دلیل وجود این ساختار، یک مدیر می‌تواند فوراً بپرسد: «اگر این تصمیم معماری را تغییر دهم، کدام تصمیمات دیگر تحت تأثیر قرار می‌گیرند؟».
پاک‌سازی ساختاری و حاکمیت
سیستم مکانیزمی به نام SweepStructural دارد که به‌طور فعال تمام روابط را بررسی می‌کند تا ببیند آیا هدف هنوز «زنده» است یا خیر. اگر هدفی منسوخ شود، یال مربوطه در همان لحظه نامعتبر شده و یک فراخوان (Callback) فعال می‌شود.
برای جلوگیری از تبدیل شدن مدیران انسانی به گلوگاه، تصمیمات در سه بعد طبقه‌بندی می‌شوند:
- دامنه (Scope): بخش یا تیمی که تحت تأثیر قرار می‌گیرد.
- رتبه اختیار (Authority Rank): تشخیص اینکه تصمیم بنیادی است یا جزئی.
- برگشت‌پذیری (Reversibility): تشخیص اینکه اقدام دائمی است یا تخریبی.
ردپای حسابرسی
قابلیت حسابرسی از طریق ساختار AuditRecord در هسته سیستم تعبیه شده است. هر سیگنال چرخه عمر (مانند انتشار یا بایگانی) داده‌های زیر را ثبت می‌کند:
- برچسب زمانی UTC
- نوع سیگنال و محتوا
- شناسه یکتای عامل (ActorID)
- نقش عامل (مهمان، نویسنده، ویرایشگر یا مدیر)
- وضعیت قبلی پیش از انتقال
سیستم به‌طور عمدی از شناسه‌های UUID به‌جای نام افراد استفاده می‌کند تا جداسازی فنی حفظ شود.
گام بعدی شما
- قوانین حیاتی کسب‌وکار خود را به‌جای ویکی‌های استاتیک، به‌صورت یک گراف جهت‌دار از تصمیمات ترسیم کنید.
- برای خودکارسازی ابطال وظایف وابسته، انتشار قابلیت «آبشاری ترانزیتی» (Transitive Cascading) در چارچوب Smeldr را دنبال کنید.
- استراتژی استقرار عامل‌های خود را از «بهبود حافظه» به «ثبت وضعیت تصمیم» تغییر دهید.
اما چالش اصلی در پیاده‌سازی این گراف‌ها، مدیریت تضادهای تصمیم‌گیری در مقیاس بزرگ است — به تحلیل ما درباره‌ی پروتکل‌های همراستاسازی در سازمان‌های توزیع‌شده مراجعه کنید.
گفتگو