درون وزارتخانهٔ تاییدات؛ بازسازی بروکراسی اداری با عامل‌های هوش مصنوعی

تصور کنید فرمی را برای تغییر نام گربه‌تان ارسال می‌کنید، اما یک ربات با دقت وسواس‌گونه، آن را به دلیل نبود «شماره ارجاع طبق ماده ۸ بند ۳» رد می‌کند. در دنیایی که همه به دنبال بهینه‌سازی هستند، وزارت تأییدیه‌ها (Ministry of Approvals) دقیقاً برعکس عمل می‌کند و عمداً مدارک شما را گم می‌کند. این وب‌سایت که توسط یک مدیر جامعه برای چالش Sanity در تاریخ ۴ اکتبر ۲۰۲۶ ساخته شد، وحشتِ انتظار برای یک مهر دولتی را به یک شبیه‌ساز دیجیتال تبدیل کرده است که اگرچه «نفرین‌شده» است، اما کاملاً کاربردی است.

در حالی که اکثر برنامه‌های هوش مصنوعی برای حداکثر بهره‌وری و تجربه‌های کاربری بدون اصطکاک طراحی می‌شوند، این پروژه دقیقاً مسیر معکوس را طی می‌کند. این سیستم از یک گردش‌کار پیچیده عامل‌محور (Agentic Workflow) استفاده می‌کند تا حس خاص گذراندن سال‌ها زمان در انتظار یک کارمند اداری با یک مهر لاستیکی را بازسازی کند و شکست‌های اداری را به شکلی از سرگرمی تعاملی تبدیل نماید. این رویکرد در تضاد با تلاش‌های صنعتی برای رفع نقص‌های عامل‌هاست، چرا که برخی تحلیل‌ها دلایل شکست عامل‌های هوش مصنوعی در مقیاس واقعی را در همین پیچیدگی‌های عملیاتی می‌بینند.

معماری ناکارآمدی

کل این سیستم بر پایه Sanity Workflows بنا شده است. در واقع «راهروهای» این وزارتخانه، تعاریفی از گردش‌کار هستند که در همان مجموعه‌داده‌ای قرار دارند که فرم‌های کاربران در آن ذخیره می‌شوند. هر مرحله‌ای که کاربر در سایت می‌بیند، بازخوانی لحظه‌ای از این گردش‌کار است.

بر اساس مستندات پروژه، فرآیند با ارسال یک فرم توسط شهروند آغاز می‌شود؛ این فرم می‌تواند هر چیزی باشد، از یک میم (Meme)، نامی برای گربه، یک طرح پیشنهادی یا حتی یک شکایت رسمی درباره همان طرح. سپس فرم از سه دپارتمان مختلف عبور می‌کند که هر کدام توسط یک عامل (Agent) — مثل کارمندی مجازی که دستورالعمل‌های خاصی برای رفتار دارد — اداره می‌شوند:

• دپارتمان وسواس (The Department of Pedantry): این عامل به دنبال یک جزئیات کوچک گم‌شده می‌گردد و قانونی را در لحظه اختراع می‌کند تا فرم را رد کند. برای مثال، اگر کسی درخواست ناهار دهد، ممکن است با این پاسخ مواجه شود: «لطفاً شماره ارجاع ثبت را اضافه کنید، همان‌طور که در ماده ۸ بند ۳ الزامی شده است.»
• دپارتمان مهرهای لاستیکی (The Department of Rubber Stamps): این عامل همه چیز را تأیید می‌کند، اما یادداشت‌هایی می‌گذارد که ثابت می‌کند اصلاً متن ارسالی را نخوانده است.
• بایگانی (The Archive): این عامل عمداً هر سومین فرم (به طور خاص آن‌هایی که شماره سریالشان بر ۳ بخش‌پذیر است) را گم می‌کند و رسید می‌دهد که توضیح می‌دهد فایل احتمالاً کجا رانده شده است. برای مثال، یک میم درباره چاپگر ممکن است در «قفسه M، استعفا داده شده، جایی که ارسال‌های تکراری میم و شواهد چاپگر بدون هیچ بلندپروازی‌ای منتظر می‌مانند» گم شود.

گلوگاه انسانی

اگر فرمی از دست کارمندهای هوش مصنوعی جان سالم به در ببرد، روی میز وزیر (توسعه‌دهنده) می‌رسد. وزیر دقیقاً یک ساعت فرصت دارد تا تصمیم بگیرد. طبق گزارش توسعه‌دهنده، اگر این مهلت بدون هیچ اقدامی بگذرد، «دپارتمان تأخیرات» فعال شده و فایل را دوباره به بایگانی می‌فرستد، جایی که گم شدن مجدد آن تضمین شده است.

این مکانیسم توسط یک فیلد مهلت (deadline) در سطح مرحله تغذیه می‌شود که مقدار آن از یک کوئری GROQ گرفته می‌شود (string(dateTime(now()) + 3600)). یک تریگر نظارت می‌کند که چه زمانی $fields.deadline <= $now رخ می‌دهد. یک تابع زمان‌بندی شده (Scheduled Function) هر ساعت یک بار تمام اجراهای باز را بررسی می‌کند، در حالی که صفحه وضعیت در صورتی که کاربر فعالانه در حال تماشای فایل باشد، تیک می‌زند.

به نقل از سازنده، یکی از نمونه‌های واقعی، فرم شماره ۶ با موضوع «اعلام گیاه دفتر به عنوان همکار ارشد» بود. این فرم در ساعت ۱۳:۴۱:۵۱ UTC به میز وزیر رسید. پس از آنکه نادیده گرفته شد، یک تیک در ساعت ۱۴:۴۲:۰۸ آن را به بایگانی فرستاد. بایگانی‌دار یادداشت کرد که مدارک احتمالاً به «قفسه F، استعفا داده شده، پشت گواهینامه‌های منقضی‌شده گیاهان، پس از آنکه وزیر اجازه داد مهلت بگذرد» رانده شده‌اند. او همچنین اشاره کرد که «ممکن است وزیر متوجه شود که گیاه همچنان ارشد باقی مانده در حالی که مدارک ارتقا نیافته‌اند». تا ساعت ۱۴:۴۲:۲۷، این فرم برای دور سوم به دپارتمان وسواس بازگشت.

برای مدیریت این آشوب، توسعه‌دهنده یک پنل مدیریت (Back Office) سفارشی با استفاده از App SDK در داخل داشبورد Sanity ساخت. این رابط به وزیر اجازه می‌دهد فایل را بردارد، آن را با یک یادداشت تأیید کند، با یک دلیل رد کند یا آن را به یکی از دپارتمان‌ها ارجاع دهد. پس از تأیید، سیستم یک گواهینامه PNG واقعی با مهرهای دارای بافت جوهر تولید کرده و آن را به طور خودکار در دیسکورد منتشر می‌کند. کل این مسیر حسابرسی — تأیید، صدور، گواهینامه، اعلام در دیسکورد، قاب کردن و نصب روی دیوار — حدود ۱۵ ثانیه زمان می‌برد.

جزئیات فنی

طرح داده‌ها و انواع (Data Schema and Types)
این سیستم برای حفظ نظم بروکراسی از ۵ نوع سند خاص استفاده می‌کند:

• submission: فقط شامل آنچه شهروند نوشته است؛ هیچ فیلد وضعیتی ندارد. مکان حضور فرم در نمونه گردش‌کار (workflow instance) ردیابی می‌شود.
• workflow instance: ذخیره می‌کند که فرم در حال حاضر در کجا قرار دارد؛ صفحه وضعیت عمومی از یک کوئری GROQ واحد روی این سند استفاده می‌کند.
• department: یک مرحله که به عنوان محتوا توصیف شده است، شامل نام، شعار، کارمند و رنگ مهر. تغییر نام یک دپارتمان یک ویرایش ساده محتوایی است، نه یک استقرار مجدد (redeploy).
• clerk: یک شخصیت هوش مصنوعی شامل پرامپت سیستمی، عدد خلق‌وخو، تکیه‌کلام و پرتره.
• certificate: توسط یک هندلر اثر (effect handler) نوشته می‌شود و یادداشت‌های کارمند را به عنوان مهر کپی می‌کند تا اطمینان حاصل شود که حتی اگر اجرای گردش‌کار حذف شود، گواهینامه روی دیوار باقی می‌ماند.
• receipt: بر اساس کلید اثر (effect key) کلیدگذاری شده است تا از صدور دو رسید برای یک مورد گم شدن توسط هندلرهای تکراری جلوگیری شود.

موتور گردش‌کار (The Workflow Engine)
گردش‌کار شامل ۷ مرحله است. هر دپارتمان یک فعالیت (activity) با سه تریگر است: یکی برای صف کردن اثر کارمند، یکی برای علامت‌گذاری «انجام شده» پس از تثبیت اثر، و یکی برای علامت‌گذاری «شکست». انتقال‌ها بر اساس خروجی‌های تایپ‌شده اثرات شاخه می‌زنند، مانند complete: boolean برای دپارتمان وسواس یا lost: boolean برای بایگانی.

پیاده‌سازی عامل‌ها (Agent Implementation)
پروژه بر Agent Actions متکی است که در آن شخصیت‌ها به عنوان محتوا ذخیره شده‌اند. یک «لغزنده خلق‌وخو» در استودیو به توسعه‌دهنده اجازه می‌دهد شخصیت کارمند را از یک «مهرزن» به یک «سخت‌گیر» تغییر دهد، که به طور خودکار پرامپت سیستمی هوش مصنوعی را بازنویسی می‌کند. پرتره‌های کارمندان نیز توسط Agent Actions بر اساس شرح شغلی‌شان تولید شدند. برای مثال، خانم «رگولیشن اونا» بدون اینکه از او خواسته شود، با یک خودکار قرمز تولید شد. تولید هر یک از این پرتره‌ها ۳ اعتبار تصویر هزینه داشت و حدود ۴۰ ثانیه زمان برد. این استفاده از عامل‌ها برای مدل‌سازی رفتارهای خاص، یادآور معماری Steadywag است که از ترکیب Claude Code و Sanity برای مدل‌سازی داده‌های گمشده بهره می‌برد.

چالش‌های پیاده‌سازی و شکست‌ها

ساخت این سیستم چندین مانع فنی را آشکار کرد. توسعه‌دهنده اشاره کرد که Sanity Workflows (نسخه ۰.۳۳.۰) یک کتابخانه است، نه یک سرویس؛ به این معنی که مراحل هوش مصنوعی به طور خودکار اجرا نمی‌شوند. آن‌ها مجبور شدند یک Blueprint با توکن ربات و یک Document Function پیاده کنند تا اثرات ادعا نشده (unclaimed effects) را «تخلیه» کرده و فرم‌ها را به جلو برانند. یک گذر کامل از ارسال مجدد تا میز وزیر حدود ۲۰ ثانیه زمان می‌برد.

سایر چالش‌ها عبارت بودند از:

• جهنم وابستگی‌ها (Dependency Hell): توسعه‌دهنده مجبور شد استودیو را روی نسخه ۶.۹.۲ قفل کند زیرا Workflows 0.33 با @sanity/ui 3 سازگار است، در حالی که استودیو ۶.۱۰ به بالا با @sanity/ui 4 عرضه می‌شود. علاوه بر این، اسکلت‌بندی سریع App SDK نسخه ۲ را ایجاد می‌کرد در حالی که Workflows نسخه ۳.۱ را می‌خواست. CLI نسخه ۶.۹.۲ دو هفته قبل از SDK 3 منتشر شده بود، بنابراین اپلیکیشن برای عبور از اسپینر داشبورد، فقط برای CLI از نسخه جدیدتر Sanity استفاده کرد. همچنین، @sanity/workflow-components تایپ‌هایی را اعلام می‌کند که ارسال نمی‌کند و این امر مستلزم یک فایل اعلان محلی ۲۰ خطی بود.
• افت عملکرد (Performance Hits): استفاده از فیلترهای SVG زنده برای بافت کاغذ (به ویژه feTurbulence) باعث ایجاد Timeout در مرورگر هنگام گرفتن اسکرین‌شات می‌شد. این موضوع توسعه‌دهنده را مجبور کرد به کاشی‌های PNG پیش‌رندر شده روی بیاورد و چرخش‌ها را در ورودی‌ها حذف کند. این مشکل به عنوان «مالیات بازترسیم» (repaint tax) شناسایی شد.
• باگ‌های منطقی (Logic Bugs): مجموعه‌ای از ۱۴ تست با استفاده از @sanity/workflow-engine-test باگی را پیدا کرد که در آن پنل مدیریت اجازه یادداشت‌های تأیید خالی را می‌داد، اما تابع field.set موتور از پردازش آن امتناع می‌کرد. توسعه‌دهنده همچنین دریافت که کوئری مهلت (deadline) بر اساس ساعت دیواری lake در حافظه حل می‌شود نه ساعت bench. تحویل رویدادها به شدت متغیر بود (از ۴ ثانیه تا ۳ دقیقه)، که منجر به ایجاد یک سیستم نظارتی (status poll) شد تا هر اثر ادعا نشده برای ۳۰ ثانیه را تخلیه کند. برای جلوگیری از چنین خطاهای منطقی و توهمات در سیستم‌های جدی‌تر، سامانه The Letter از گیت‌های قطعی برای حذف توهمات هوش مصنوعی استفاده کرده است.
• هنگ کردن داشبورد (The Dashboard Hang): هوک useWorkflowSession از @sanity/workflow-sdk باعث هنگ کردن iframe اپلیکیشن می‌شد. توسعه‌دهنده با استفاده از useDocument در App SDK و فراخوانی مستقیم engine.evaluate و engine.fireAction این مشکل را دور زد. همچنین AssigneePicker هنگام اتصال به engine.editField باعث هنگ کردن فریم می‌شد و در نهایت به یک دکمه ساده «این فایل را بگیر» تبدیل شد.
• مشکلات استقرار (Deployment Issues): برای جلوگیری از خطای ۵۰۰ در تولید گواهینامه‌های PNG، باید wasm مربوط به yoga و harfbuzz در Satori و wasm در resvg به includeFiles در آداپتور Vercel اضافه می‌شدند. همچنین بررسی CSRF در Astro درخواست‌های POST بدون هدر Origin را مسدود می‌کرد که بر درخواست‌های curl تأثیر می‌گذاشت.
• تکرار طراحی (Design Iteration): در نسخه اول، وب‌سایت اصلاحات را مستقیماً در سند submission می‌نوشت. این روش هنگام اجرای اکشن‌ها از طریق CLI شکست خورد. راه حل این بود که گردش‌کار مالک فرآیند شود: ارسال مجدد، اصلاحات را با عملیات fieldRead روی فیلدهای گردش‌کار پارک می‌کند و سپس هندلر دپارتمان وسواس آن را روی سند ثبت می‌کند. همچنین نام Guardها برای اطمینان از یکتایی در هر تعریف، با نام مرحله پسوند گرفتند.

تجربه بصری

برای دوری از ظاهر کلیشه‌ای «تولید شده توسط AI»، توسعه‌دهنده از یک مشخصات طراحی الهام گرفت که ترکیبی از کارت‌های تیتراژ وس اندرسون، فرم‌های وزارتخانه‌های دهه ۱۹۷۰، فیزیک مهرهای لاستیکی و حکاکی دیپلم‌ها بود. نتیجه، راهرویی گچی با درهای SVG است که از اسناد دپارتمان‌ها ترسیم شده‌اند و یک اسپرایت کاغذ که بین دپارتمان‌ها می‌لغزد. درها پس از هر بازدید مهر «دیده شد» (SEEN) می‌خورند و گواهینامه‌ها در قاب‌های برنجی کج نمایش داده می‌شوند. سایت برای تکمیل این زیبایی‌شناسی از فونت‌های Fraunces، Special Elite و IBM Plex Sans استفاده می‌کند.

پروژه در اعداد

• ۷ مرحله در گردش‌کار.
• ۳ کارمند هوش مصنوعی.
• ۳ فراخوانی Agent Action در هر مسیر موفق (بیشتر در صورت بازگشت یا گم شدن).
• ۲ تابع Sanity.
• ۱۴ تست که در ۰.۶ ثانیه اجرا می‌شوند.
• ۴ بسته Workflows در حالت lockstep.
• ۱ نسخه استودیو قفل شده (۶.۹.۲).
• ۳ پرتره تولید شده (با هزینه ۳ اعتبار تصویر و ۴۰ ثانیه برای هر کدام).
• ۸ فرم ارسال شده در محیط عملیاتی (با ۳ مورد گم شده، که یکی از آن‌ها متعلق به خود توسعه‌دهنده بود).

زیرساخت پروژه

این پروژه تحت Project v6745vem در مجموعه‌داده ministry میزبانی می‌شود. تعریف گردش‌کار (sanity.workflow.definition) و هر اجرا (sanity.workflow.instance) به عنوان سند در کنار ارسال‌ها، دپارتمان‌ها، کارمندان، گواهینامه‌ها و رسیدها ذخیره می‌شوند. کد منبع تحت لایسنس MIT باز است و به چهار پوشه تقسیم شده است: studio (استودیو ۶.۹ با پلاگین Workflows)، workflows (تعاریف، هندلرها و زمان اجرا)، app (پنل مدیریت App SDK) و web (سایت Astro 7 با رندرر گواهینامه).

این شبیه‌ساز ثابت می‌کند که عامل‌های هوش مصنوعی را می‌توان نه فقط برای حل مسائل، بلکه برای تقلید دقیق از شکست‌های سیستماتیک انسانی به کار برد. با تبدیل «شخصیت» به یک فیلد داده، این پروژه نشان می‌دهد چقدر راحت می‌توان هوش مصنوعی را برای ایجاد مزاحمت تنظیم کرد.

اگر می‌خواهید شانس خود را امتحان کنید، می‌توانید از دموی زنده بازدید کنید و پیش از ارسال فرم، در پیشخوان پذیرش بررسی کنید که آیا شماره سریال شما بر سه بخش‌پذیر است یا خیر.