تصور کنید باید صدها مهمان و سنتهای متضاد چندین خانواده را در یک مراسم عروسی مدیریت کنید بدون آنکه کسی از ترتیب مراسم رنجیده شود. Owambe Desk برای حل همین آشوب به عنوان بخشی از چالش Sanity طراحی شده تا نشان دهد چگونه گردشکارهای ساختاریافته میتوانند از فروپاشی لجستیکی در رویدادهای فرهنگی بزرگ جلوگیری کنند. این ابزار تخصصی مبتنی بر هوش مصنوعی، نمونهای است از اینکه چگونه میتوان از جریانهای کاری برای مدیریت پیچیدگیهای اجتماعی استفاده کرد.
برنامهریزی برای یک عروسی سنتی نیجریهای یا «اوامبه» (Owambe)، یعنی عبور از میان آداب سختگیرانه قبیلهای و مذاکرات حساس خانوادگی. در این مراسمها، یک اختلاف کوچک بر سر ترتیب اتفاقات — مثلاً اینکه چه زمانی باید دانه کولا شکسته شود یا دعا خوانده شود — میتواند کل فرآیند را متوقف کند. Owambe Desk با تبدیل این قوانین فرهنگی به محدودیتهای دادهای سخت، این نقاط اصطکاک را مدیریت میکند.
زمینه: مخاطرات فرهنگی
در پیوندی بین دو قبیله مختلف، هر خانواده سنتهایی دارد که هرگز از آنها کوتاه نمیآید. این موارد صرفاً ترجیحات شخصی نیستند، بلکه الزامات فرهنگی محسوب میشوند. برای مثال، خانواده دام ممکن است اصرار داشته باشند دانه کولا پیش از پذیرایی هر مهمانی شکسته شود. در مقابل، خانواده عروس ممکن است الزام کنند که دعای خاص آنها پیش از بریدن کیک خوانده شود.
همانطور که در تحلیلهای پیشین ما دربارهی سیستمهای عاملمحور اشاره کردیم، کلید موفقیت این ابزارها در تبدیل «سلیقه» به «قانون» است. طبق مستندات پروژه، این موارد غیرقابلمذاکره در سندی به نام familySide ذخیره میشوند. این یعنی عامل (Agent) — شبیه دستیاری که دستورالعملهای دقیق را در دست دارد و هرگز از آنها تخطی نمیکند — هر بار که پیشنویس برنامهای میزند، ابتدا این قوانین را میخواند تا از هرگونه خطای فرهنگی پیش از رسیدن به خانوادهها جلوگیری کند.
موتور تایید برنامه
متلاطمترین بخش یک اوامبه، «برنامه رویداد» است؛ همان ترتیبی که مشخص میکند چه کسی صحبت کند، غذا چه زمانی سرو شود و زوج چه زمانی برقصند. Owambe Desk این فرآیند را از طریق یک خط لوله تایید چندمرحلهای مدیریت میکند:
- تدوین: یک عامل هوش مصنوعی بر اساس یادداشتهای زوج و قوانین غیرقابلمذاکره هر دو خانواده، اولین پیشنویس را میسازد.
- بررسی موازی: پیشنویس بهطور همزمان برای هر دو خانواده ارسال میشود. این مرحله به صورت دو فعالیت موازی طراحی شده است؛ یکی برای هر خانواده.
- اصلاح تکرارشونده: اگر هر یک از خانوادهها نسخهای را رد کنند، باید دلیل آن را ذکر کنند. عامل سپس برنامه را دقیقاً در تقابل با آن دلیل خاص بازنویسی میکند.
- نهاییسازی: برنامه تنها زمانی به وضعیت «آماده چاپ» میرسد که هر دو خانواده دقیقاً یک نسخه واحد را تایید کنند. در این لحظه، سند قفل میشود.
برای جلوگیری از سردرگمی، سیستم از «حفاظها» (Guards) استفاده میکند تا سند را در زمان رایگیری منجمد کند و اجازه ندهد کسی نسخهای را که در حال بررسی است، تغییر دهد.
اتوماسیون لجستیک Aso Ebi
مدیریت «آسو اِبی» (Aso Ebi) — پارچههای ست شدهای که مهمانان میپوشند — معمولاً یک کابوس دستی از ردیابی پرداختها و سفارشات خیاط است. Owambe Desk این فرآیند را با یک گردشکار سختگیرانه جایگزین کرده است:
- انتخاب: مهمانان پارچه را در وبسایت انتخاب کرده و از طریق درگاه Bachs (که در حال حاضر در محیط sandbox است) پرداخت میکنند.
- تایید خودکار: یک وبهوک (Webhook) امضای پرداخت را تایید میکند. این وبهوک از نوع idempotent است و بهطور خودکار وضعیت گردشکار سفارش را تغییر میدهد.
- تایید رباتیک: سیستم بهگونهای کدنویسی شده که هیچ انسانی نمیتواند دستی وضعیت سفارش را به «پرداخت شده» تغییر دهد؛ تنها یک توکن رباتیک پس از ثبت حقایق تایید شدهی پرداخت در سفارش، میتواند این انتقال وضعیت را تحریک کند.
- تامین: پس از تایید خودکار، هماهنگکننده برای ارسال پارچه به خیاط مطلع میشود.
هماهنگی زنده رویداد
به دلیل تغییرات احتمالی در زمانبندی مراسم، یک کنسول هماهنگکننده زنده با استفاده از Sanity UI App SDK در داخل داشبورد Sanity تعبیه شده است. هماهنگکننده با زدن دکمه «شروع» و «پایان» برای هر بخش در لحظه وقوع، وبسایت عمومی ساخته شده با Next.js را بهصورت لحظهای بهروز میکند تا مهمانانی که مثلاً در پارکینگ هستند، بدانند در حال حاضر چه اتفاقی میافتد و برنامه بعدی چیست.
اگر مراسم بیش از ۱۰ دقیقه از برنامه عقب بیفتد، هماهنگکننده میتواند از عامل هوش مصنوعی درخواست پیشنهاد زمانبندی جدید کند. نکته حیاتی این است که عامل فقط پیشنهاد میدهد و هماهنگکننده باید تغییرات را دستی تایید کند تا روی سایت فعال شود.
برای حفظ دقت، یک اعتبارسنج داخلی تمام پاسخهای مدل را چک میکند. این ابزار تضمین میکند که هیچ تداخلی در زمانبندی بخشها نباشد و هیچ برنامهای قبل از ظهر یا بعد از ساعت ۲۲:۰۰ نباشد. همچنین یک بررسی قوانین مکتوب انجام میدهد تا نشان دهد هر یک از الزامات غیرقابلمذاکره خانوادهها چگونه رعایت شده است. اگر مدل پاسخ اشتباهی بدهد، سیستم با استفاده از ایرادات دقیق اعتبارسنج، دوباره تلاش میکند.
معماری فنی
کل سیستم به صورت یک pnpm monorepo با استفاده از Sanity Workflows ساخته شده است، جایی که قوانین فرآیند در همان پایگاه دادهای قرار دارند که محتوا در آن است. توسعهدهنده از Claude Code به عنوان برنامهنویس جفت برای ساخت استودیو استفاده کرده که شامل ۱۰ نوع سند مختلف است: event ،person ،familySide ،guest ،vendor ،programOfEvents ،programItem ،programAdjustment ،asoEbiLot و asoEbiOrder.
جزئیات فنی کلیدی عبارتند از:
- فرانتاند: Next.js با محتوای زنده next-sanity، Tailwind v4 و فونت Bricolage Grotesque.
- مدلسازی داده: افراد، خانوادهها، رویدادها و سفارشات به جای متن تکراری، از طریق ارجاعات (References) به هم متصل شدهاند تا از ناهماهنگی دادهها (Data Drift) جلوگیری شود.
- منطق عامل: یک اجراکننده TypeScript کوچک با استفاده از Agent Actions که عملیات
Generate(تدوین)،Transform(بازنویسی) وTranslate(ترجمه) را مدیریت میکند. - ایمنی زبانی: عامل میتواند دعوتنامهها را به زبانهای یوروبا، ایگبو و پدجین نیجریهای ترجمه کند. با این حال، این متون بررسی نشده باقی میمانند و تا زمانی که یک بازبین انسانی مسلط به زبان، آنها را تایید و نام خود را به عنوان تاییدکننده ثبت نکند، برای مهمانان مخفی میمانند.
تستهای واقعی و شکستها
این پروژه شامل یک عروسی نمایشی برای «تولو آدیمی» و «امکا اوکافور» در شهر آسابا در ایالت دلتا است که برای ۱۲ دسامبر ۲۰۲۶ برنامهریزی شده است. توسعهدهنده یک فایل BUILD_LOG.md صادقانه برای ثبت شکستها نگه داشته است؛ مثلاً در استقرار اولیه Netlify، به دلیل اینکه CLI هیچ فایلی را از monorepo آپلود نکرده بود، خطاهای ۴۰۴ رخ داد.
چالشهای دیگر شامل رد کردن URLهای بازگشت localhost توسط Bachs بود که نیاز به یک تونل عمومی برای Redirect و دستور bachs listen برای وبهوک داشت. علاوه بر این، در اولین تلاش زنده برای زمانبندی مجدد، عامل دو بار سعی کرد زمان رقص را افزایش دهد تا تاخیرهای بخشهای دیگر را جبران کند؛ اعتبارسنج این مورد را شناسایی کرد و منجر به تعریف قانون جدیدی شد: عامل تنها میتواند به اندازه مقدار تاخیر مراسم، از زمان بخشهای دیگر کم کند.
این پیادهسازی، نقش هوش مصنوعی را از یک تصمیمگیرنده به یک «تدوینگر پیشرفته» تغییر میدهد. با گنجاندن الزام «انسان در حلقه» (Human-in-the-loop) مستقیماً در تعریف گردشکار — جایی که عامل میتواند پیشنویس بزند، بازنویسی کند و پیشنهاد دهد، اما نمیتواند برنامهای را تایید کند یا سفارشی را پرداختشده علامت بزند — سیستم تضمین میکند که قدرت تصمیمگیری فرهنگی همچنان در دست خانوادهها باقی بماند.
برای کسانی که سیستمهای عاملمحور مشابه میسازند، این پروژه اهمیت «اعتبارسنجها» و تصمیم به حذف نوع سند مجزا برای «تصمیمات» را برجسته میکند، زیرا موتور Workflows هر تصمیم را به همراه بازیگر آن ذخیره میکند.
نقشه راه آینده
برای فراتر رفتن از نسخه نمایشی، توسعهدهنده برنامههای زیر را دارد:
۱. اختصاص حساب Sanity مجزا به هر تاییدکننده خانواده برای اجرای دقیق نقشها (در حال حاضر تاییدها ثبت میشوند اما توسط حساب کاربری سختگیرانه اجرا نمیشوند).
۲. اجرای عامل روی یک Sanity Function به جای فرآیندی که نیاز به شروع دستی دارد.
۳. تست سیستم با یک هماهنگکننده حرفهای عروسی برای شناسایی نقاط اصطکاک در دنیای واقعی.
گام بعدی شما
- بررسی نحوه پیادهسازی Sanity Workflows برای تبدیل فرآیندهای اداری به دادههای ساختاریافته.
- مطالعه درباره مدلهای «انسان در حلقه» برای کاهش نرخ توهم در سیستمهای حساس فرهنگی.
- آزمایش ابزار Claude Code برای تسریع در توسعه استودیوهای مدیریت محتوا.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو