🔬 در پست قبلی درباره این صحبت کردم که چرا نباید با شنیدن #AI_Agent، مفهوم #Agent را از صفر و صرفاً در چارچوب هوش مصنوعی تعریف کنیم. اما این نگاه یک نتیجه جالب‌تر هم دارد.
اگر Agent یک مفهوم عمومی باشد، آن‌وقت عاملیت (Agency) فقط دربارهٔ هوشواره‌ها نیست؛ درباره نحوه‌ای است که یک موجودیت می‌تواند مسئولیت انجام چیزی را بر عهده بگیرد، تصمیم بگیرد و در چارچوب توانمندی و اختیار خود عمل کند. و وقتی این مفهوم را وارد #مدل_سازی کنیم، بعضی مفاهیم بسیار آشنای نرم‌افزار هم ناگهان شکل دیگری پیدا می‌کنند.
⏳ مثلاً #Process. ما معمولاً Process را از روی چیزهایی که برای اجرای آن ساخته‌ایم تصور می‌کنیم: Thread، Coroutine، Queue، Lock، Transaction، Scheduler و... در حالی که هیچ‌کدام از این‌ها ذات Process نیستند. Process ابتدا باید از خود progression، فعالیت‌ها، مشارکت‌کنندگان، مسئولیت‌ها، وابستگی‌ها، محدودیت‌ها و نتایجش فهمیده شود؛ بعد تازه می‌توانیم درباره مکانیزم اجرای آن تصمیم بگیریم.
همین نگاه، برداشت ما از #Concurrency را هم تغییر می‌دهد.
آیا واقعاً هر جا چند فعالیت هم‌زمان یا درهم‌تنیده داریم باید به سراغ Lock برویم؟
آیا مسئله این است که چند Thread داریم؟ یا شاید مسئله واقعی این باشد که چه کسی مسئول انجام یک فعالیت است و در هر لحظه چه عاملی مسئول وضعیت مورد نظر است؟
اگر بتوانیم مسئولیت را درست میان عامل‌های پردازشی تقسیم کنیم، شاید اصلاً نیازی به بسیاری از مکانیزم‌های هماهنگی که بعداً برای جلوگیری از تعارض ایجاد می‌کنیم نباشد. حتی ممکن است دو فعالیت روی یک CPU Core اجرا شوند و همچنان مسئلهٔ Concurrency داشته باشیم؛ بنابراین Core فیزیکی و Agent یا Worker منطقی را هم نباید یکی فرض کنیم.
اینجاست که به نظرم مفهوم Agent واقعاً ارزش خودش را نشان می‌دهد.
🚨 اگر به جای اینکه از مکانیزم شروع کنیم، از عاملیت، مسئولیت، اختیار، قابلیت و ارتباط میان عامل‌ها شروع کنیم، ممکن است بسیاری از راه‌حل‌هایی که امروز به‌عنوان «راه‌حل‌های استاندارد» می‌شناسیم، دیگر تنها گزینه‌های ممکن به نظر نرسند.
حتی ممکن است بفهمیم بعضی از پیچیدگی‌هایی که سال‌ها با Queue و Lock و Synchronization و Scheduler به سیستم اضافه کرده‌ایم، در واقع حاصل این بوده که خود مسئله را به‌درستی مدل (Modeling) نکرده‌ایم. این دقیقاً همان چیزی است که در #معماری برای ما اهمیت دارد:
از مکانیزم شروع نکنیم؛ ابتدا واقعیت را مدل کنیم.
🤔 حالا یک سؤال جدی‌تر:
چه کسی بدون اینکه از ابتدا به دنبال ساختن Actor، Worker، Coroutine، Thread Pool، Lock یا یک Scheduler باشد، به این نتیجه رسیده که می‌توان Process را ابتدا از منظر Agency، Responsibility و Ownership مدل کرد و سپس Actor یا Worker را به‌عنوان یکی از نمودهای اجرایی آن مدل به دست آورد؟
یعنی ابتدا بپرسیم:
چه عامل‌هایی داریم؟ هر عامل چه مسئولیتی دارد؟ چه چیزی را می‌داند؟ چه چیزی را می‌تواند تغییر دهد؟ در هر لحظه چه چیزی تحت مسئولیت کدام عامل است؟ و چه ارتباطی واقعاً میان عامل‌ها لازم است؟
شاید آن‌وقت #Concurrency دیگر مسئله‌ای نباشد که بعد از طراحی سیستم مجبور شویم برایش Lock بسازیم؛ بلکه تا حد زیادی نتیجهٔ طبیعی مدلی باشد که از ابتدا عاملیت و مسئولیت را درست فهمیده است.
🔗 اگر موضوع براتون جذاب هست میتونید پروژه #معمار (پست مربوطه) را دنبال کنید. یک مثال و یک شاهد عینی هم در کامنت‌ها برای همین پست می‌گذارم که درک بهتری از این ایده ایجاد بشه.