omp²: هارنس ایجنت رو مثل موتور بازی بساز
هوش مصنوعیخلاصهٔ کامل‌تر
تو این مقاله اومده که نوشتن یه هارنس ایجنتی (یعنی همون برنامه‌ای که مدل رو صدا می‌زنه، ابزارها رو اجرا می‌کنه و کل گفت‌وگو رو نگه می‌داره) خیلی سخت‌تر از یه حلقهٔ while دور یه fetch ـه. نویسنده می‌گه پروژه‌هایی مثل OpenCode و Pi و omp همزمان دارن بازنویسی کامل می‌کنن، چون این دسته نرم‌افزار قبلاً وجود نداشت و ترک‌هاش فقط بعد از ساختن نسخهٔ ساده معلوم شد.
مقایسهٔ اصلی مقاله با موتور بازی Source ـه. اونجا تنها منبع حقیقت لیست entityهاست و حالتی که قابل بازپخش نباشه اصلاً قابل نمایش دادن نیست. تو هارنس‌های امروزی اما درخت پیام‌ها یه صاحب داره و چیزهایی مثل شمارندهٔ retry، وضعیت todo و رجیستری زیرایجنت‌ها یه صاحب دیگه، معمولاً یه let ساده تو کلوژر ماژول. به گفتهٔ نویسنده همین دوگانگی ـه که rewind و resume رو می‌شکنه.
برای اینکه نشون بده مشکل از کمبود مستندات نیست، ۷۸ نمونه‌افزونهٔ رسمی Pi بررسی شده. ۶۰ تاشون اصلاً state نداشتن و از ۱۷ تای باقی‌مونده فقط ۲ تا درست بودن. مثلاً status-line.ts شمارندهٔ نوبت رو تو کلوژر نگه می‌داره، پس اگه از نوبت ۳ به ۱ برگردی نوبت بعدی میشه ۴، و بعد از resume هم از صفر شروع می‌کنه.
راه‌حل omp² اینه که کل جلسه به شکل یک درخت واحد ماتریالایز بشه و ژورنال فقط تغییر پراپرتی‌ها رو نگه داره. نویسنده XML رو انتخاب کرده چون ترکیب و بازرسی و دیباگش راحته:
<meta>
<todo>…</todo>
<jobs>…</jobs>
</meta>
<body>
<user id="e12">…</user>
<ai id="e13">…</ai>
</body>با یک مرجع، چند مسئلهٔ سخت به یه عملیات واحد تبدیل می‌شن. rewind میشه diff گرفتن بین حالت فعلی و حالت هدف: اگه یه المان تو حالت هدف نباشه یعنی باید نابود بشه. replication هم میشه subscribe کردن به همون استریم patch، پس کلاینت وب و کلاینت ریموت دیگه لولهٔ state جدا نمی‌خوان. نویسنده می‌گه با این کار اضافه کردن یه قابلیت stateدار جدید هیچ call site تازه‌ای به rewind و fork و resume اضافه نمی‌کنه.
بخش دوم مقاله دربارهٔ مرز اجراست. نویسنده معتقده سندباکس فقط باید اجرا کنه نه تصمیم بگیره: میزبان مالک state جلسه، سیاست، مسیریابی ابزار و ژورنال می‌مونه و داخل VM فقط یه stub کوچیک و مطیع می‌شینه که حجم چیزی که برمی‌گردونه هم سقف داره تا حافظهٔ میزبان پر نشه. برای زیرایجنت‌ها هم همین منطق تو لایهٔ فایل‌سیستم با pi-iso و یه ویوی copy-on-write از کل ورک‌اسپیس پیاده میشه.
نکات کلیدی:
- از ۷۸ نمونه‌افزونهٔ رسمی Pi، ۶۰ تا بدون state بودن و از ۱۷ تای دارای state فقط ۲ تا درست بودن.
- omp² کل جلسه رو به شکل یک درخت XML نگه می‌داره و ژورنال فقط ops تغییر پراپرتی رو ذخیره می‌کنه.
- rewind به یه diff بین درخت فعلی و درخت هدف تبدیل میشه، بدون call site اضافه.
- میزبان مالک state و سیاست می‌مونه؛ داخل VM فقط یه stub اجراکننده با سقف حجم استریم قرار می‌گیره.
- pi-iso به هر زیرایجنت یه ویوی copy-on-write از ورک‌اسپیس می‌ده، روی APFS و btrfs و ZFS و overlayfs و ProjFS.
