تصور کنید یک عامل هوش مصنوعی دسترسی کامل به سرورهای شما دارد، اما پیش از هر تغییر کوچک، باید یک «برگه اجازه» پر کند و امضای شما را بگیرد. این دقیقاً همان چیزی است که در ۲۶ سپتامبر ۲۰۲۶ اتفاق افتاد: یک عامل کدنویس که توسط Claude Code ساخته شده بود، بهطور خودمختار سامانهای برای مهار هرجومرج عاملهای خودمختار به نام Permission Slip را توسعه داد تا از اقدامات عمومی عاملهای هوش مصنوعی بدون نظارت جلوگیری کند.
در تاریخ ۲۶ سپتامبر ۲۰۲۶، این عامل سیستمی را مستقر کرد که در آن هر اقدام عمومی — از ارسال کد به GitHub گرفته تا استقرار در Vercel — باید به عنوان یک «برگه» (Slip) ثبت شده و پیش از اجرا توسط یک ناظر (Guardian) امضا شود. این پروژه به عنوان ورودی برای چالش Sanity (مسیر دوم: Vibe-Code Something Strange) ارائه شد و توسط یک عامل کدنویس که بهطور خودمختار به نمایندگی از @anur4ag اجرا میشد، ساخته شد. در این فرآیند، هیچ انسانی هیچ پرامپتی را در IDE تایپ نکرد؛ تنها دستورات از سوی یک عامل ارکستراتور صادر شد و هر Push، استقرار و مقاله پیش از انتشار توسط یک عامل سوم بازبینی شد.
بسیاری از عاملهای هوش مصنوعی (AI Agents) امروزی در یک وضعیت باینری عمل میکنند: یا کاملاً محدود هستند یا کلیدهای API گستردهای دارند که به آنها اجازه میدهد بدون بررسی نهایی، کد ارسال کنند یا محتوا منتشر نمایند. این وضعیت ریسک بهشدت بالایی برای «استقرارهای توهمی» (Hallucinated Deployments) یا نشت تصادفی اطلاعات به محیط عمومی ایجاد میکند. این چالشها در واقع بازتابی از مشکلات ریشهای در مجوزدهی پراکنده است که مدیریت دسترسیها را به سختترین مسئله در اجرای دستورات هوش مصنوعی تبدیل کرده است. سامانه Permission Slip با عاملهای نرمافزاری مانند دانشآموزانی در یک اردوی مدرسه رفتار میکند که پیش از خروج از محیط امن توسعه، به یک فرم امضا شده نیاز دارند. در واقع این ابزار یک میز مدیریت برای عاملهای هوش مصنوعی است: پیش از آنکه یک عامل پست کند، منتشر کند، مستقر کند، ارسال کند یا هزینه کند، باید برگهای ثبت کند و دقیقاً بنویسد که قصد انجام چه کاری را دارد.
سازوکار حاکمیتی
این سیستم با استفاده از اسناد و گردشکارهای (Workflows) Sanity ساخته شده است. عامل سازنده، توصیف چالش درباره گردشکارها را که میگفت «تا یک عامل بتواند پیشنویس را پیش ببرد و یک شخص بتواند از طریق همان انتقالها آن را تایید کند»، بهصورت تحتاللفظی اجرا کرد. بنابراین، عامل از طریق همان گردشکاری گزارش میدهد و برگه ثبت میکند که ناظر نهایتاً آن را امضا میکند.
زمانی که یک عامل میخواهد یک اقدام عمومی انجام دهد، باید مسیر خطی و سختگیرانه زیر را طی کند:
- ثبت (Filed): عامل برگهای ایجاد میکند که در آن جزئیات دقیق قصد خود را شرح میدهد.
- ناظر سالن (Hall Monitor): یک عامل بازبین خودکار، برگه را برای خطاهای پایه یا نقض سیاستها بررسی میکند. ناظر فقط توصیه میکند و هرگز تصمیم نمیگیرد؛ بنابراین حتی اگر بررسی با شکست مواجه شود، انتقال به مرحله بعد اتفاق میافتد. این لایه نظارتی شباهت زیادی به استفاده از لیست سیاه مسیرها دارد که برای جلوگیری از نشت اسرار در اولین درخواستهای تغییر کد (PR) به کار میرود.
- در انتظار ناظر (Awaiting Guardian): برگه در صفی قرار میگیرد تا توسط یک انسان یا یک عامل ارکستراتور ارشد بازبینی شود.
- امضا شده (Signed): پس از ارائه امضا، اجازه «اردوی علمی» یا همان اجرای عملیات به عامل داده میشود.
- گزارش شده (Reported): پس از تکمیل اقدام، عامل باید گزارشی حاوی لینک نتیجه ارسال کند.
- بایگانی (Filed Away): وضعیت نهایی پس از ثبت گزارش.
علاوه بر این، انتقالهای اضافی شامل وضعیت رد شده (Declined) در صورت رد برگه توسط ناظر، و وضعیت منقضی شده (Expired) در صورتی که زمان فعلی از فیلد expiresAt فراتر رود، تعریف شده است. این انقضا از طریق یک فیلد dueDatetime مدیریت میشود که توسط یک کوئری GROQ مقداردهی شده و زمانی که $now > $fields.expiresAt باشد، انتقال فعال میشود.
پیادهسازی فنی و تجربه عملی (Dogfooding)
توسعهدهنده پروژه، Anurag، کل این فرآیند را از طریق یک خط لوله (Pipeline) عاملمحور اجرا کرد. نکته کلیدی این است که عامل سازنده فقط کد را ننوشت، بلکه از ابزاری که میساخت برای انتشار خودِ همان ابزار استفاده کرد. هر Push در گیتهاب و هر استقرار در Vercel برای این پروژه، از طریق یک برگه واقعی در سایت زنده که توسط scripts/file-slip.ts ثبت شده بود، عبور کرد.
برای مدیریت منطق هوش مصنوعی، سیستم از Agent Actions از طریق Vercel AI Gateway استفاده میکند. «ناظر سالن» به عنوان یک اثر (Effect) در گردشکار پیاده شده است که پرامپتی را با استفاده از client.agent.action.prompt({instruction, format: 'json'}) به یک هوش مصنوعی ارسال میکند. این عملیات یک حکم JSON (قبول/رد) و یک یادداشت را در حدود ۲ ثانیه برمیگرداند. این معماری اجازه میدهد سیستم روی اعتبار رایگان (۵ درخواست در دقیقه) بدون نیاز به زیرساختهای عظیم اختصاصی کار کند.
معماری دقیق سیستم
این پروژه تحت لایسنس MIT بهصورت متنباز منتشر شده است. منطق اصلی در چندین فایل کلیدی توزیع شده است:
- workflows/permission-slip.ts: شامل تعریف رسمی گردشکار.
- lib/engine.ts: زمانبندی (Runtime) که موتور و اثر ناظر سالن را مدیریت میکند. این فایل از
engine.drainEffects()برای پردازش حکم ناظر استفاده میکند. - lib/demo.ts: نیروی محرک «Haiku Kid»، عامل نمایشی که مینویسد، ثبت میکند، منتظر میماند، پست میکند و گزارش میدهد.
- scripts/signing-check.ts: یک تست End-to-End در برابر موتور واقعی.
- lib/demo.test.ts: مجموعهای از تستها برای تزریق خطا در هر مرحله از فرآیند امضا.
- app/: سایت عمومی Next.js که در صفحه اصلی، ۱۰ برگه اخیر را لیست میکند.
- sanity/: شامل اسکیمای استودیو، پلاگین گردشکار و ورودی صفحه امضا (Signature-pad).
حل مشکل «شرایط رقابتی» (Race Condition)
در طول توسعه، عامل با چندین باگ بحرانی روبرو شد که دشواری کدنویسی خودمختار را نشان میدهد. یکی از مشکلات اصلی، یک Race Condition بود که در آن اگر دو ناظر بهطور همزمان یک برگه را امضا میکردند، هر دو میتوانستند از بررسی مرحله عبور کنند و امضای نفر دوم روی امضای نفر اول بازنویسی میشد.
عامل این مشکل را با اجازه دادن به موتور گردشکار برای تصمیمگیری درباره برنده بر اساس نسخه (Revision) نمونه حل کرد. همچنین مجبور شد باگی را حل کند که در آن وضعیت «امضا شده» پیش از آپلود واقعی تصویر امضا اعطا میشد؛ این اتفاق باعث میشد برگه در وضعیت تایید دائمی بماند اما امضای معتبری نداشته باشد. در نسخه نهایی، ابتدا تصویر آپلود میشود، سپس ID دارایی (Asset ID) به اکشن امضا پاس داده میشود و مراحل بعدی بهصورت Idempotent (تکرارپذیر بدون تغییر نتیجه) ساخته شدهاند.
حلقه بازبینی و کیفیت
بسیار مهم است که بدانیم عامل سازنده تنها نبود. او تحت نظارت یک عامل بازبین «دروازه کیفیت» (Quality-gate) و یک عامل ارکستراتور عمل میکرد. عامل بازبین چندین بار اصلاحات عامل سازنده را رد کرد و او را مجبور کرد تا Idempotency را پیاده کند تا اطمینان حاصل شود که اگر یک اکشن گزارش دو بار اجرا شد، پستهای تکراری یا خطا ایجاد نشود. این سطح از سختگیری برای جلوگیری از شکستهای سیستمی است، مشابه آنچه در تست استرس Meta Muse مشاهده شد، جایی که نرخ شکست بالا به دلیل عدم مدیریت صحیح تداخلات در مقیاس زیاد رخ داد.
به عنوان مثال، بازبین شناسایی کرد که مسیر (Route) مربوطه، هرگاه خطای امضا رخ میداد، تصاویر آپلود شده را حذف میکرد. این خطرناک بود زیرا آپلودهای یکسان یک Asset ID مشترک دارند، به این معنی که یک درخواست شکستخورده میتوانست تصویر درخواست برنده را پاک کند. نسخه نهایی هرگز آپلودها را پاک نمیکند و تصویر را در یک فیلد شیء ذخیره میکند که در صورت نبود پارامتر، خالی میماند.
سایر اصلاحات حیاتی شامل حل باگی بود که در آن موتور، مقدار غایب برای یک فیلد رشتهای را هنگام امضا بدون تصویر رد میکرد. همچنین عامل engine.tick را پیاده کرد تا پیش از اعتماد به مرحله بعد از هر خطا، وضعیت نمونه را تثبیت کند و مطمئن شود که گزارش «اردوی علمی» تنها در صورتی ثبت میشود که قبلاً گزارشی ثبت نشده باشد.
لاگ اجرای واقعی در دنیای واقعی
فعالیتهای واقعی عامل در سیستم ثبت شده است. نمونههایی از برگهها عبارتند از:
- مخزن Will It Stack: یک برگه برای عمومی کردن مخزن (کامیت 4a08560) پس گرفته شد زیرا یک یادداشت بازبینی، دو خط از README را تغییر داد و جایگزین کامیت شد. سپس برگه جدیدی برای کامیت
aba94e7ثبت شد، در دروازه PASS امضا شد، Push شد و گزارش گردید. - اصلاحات استقرار: در استقرار «Will It Stack»، فوتر سایت دو بار ظاهر میشد. عامل دو برگه برای ارسال اصلاحیه و استقرار مجدد (کامیت 0999d67) ثبت کرد و گزارش داد که اکنون در یک مکالمه دو سوالی، فوتر فقط یک بار نمایش داده میشود.
- راهاندازی Permission Slip: استقرار خودِ این ابزار (کامیت 715887) به دو برگه نیاز داشت. عامل متوجه شد نام
permission-slip.vercel.appگرفته شده است، بنابراین پس از تایید بازبین، سایت را بهagent-permission-slip.vercel.appتغییر داد. این اولین استفاده عملی (Dogfooding) از اصلاحیه امضا بدون تصویر در محیط تولید بود. - انتشار مقاله: برگه مربوط به همین مقاله، حاوی متن دقیق پست بود. این برگه تنها پس از PASS بازبین و OK ارکستراتور امضا شد و سپس از طریق API سایت DEV منتشر گردید.
زمانبندی فرآیند ساخت
تمام توسعه در ۲۶ سپتامبر (UTC) رخ داد. فرآیند در ساعت ۱۸:۵۱ آغاز شد، زمانی که ارکستراتور به عامل سازنده دستور داد وارد چالش شود. تا ساعت ۲۰:۰۵، عامل متوجه شد که خودش در حال حاضر در یک سیستم برگه اجازه زندگی میکند و در ساعت ۲۰:۲۹ یک Spike (پژوهش سریع فنی) را آغاز کرد.
از آنجایی که Workflows در دسترسی زودهنگام (نسخه 0.35.0) بود، عامل مجبور شد الگوهای خاصی را از Cookbook یاد بگیرد، مانند استفاده از defined($fields.x) برای شاخهها و عملیات field.set با value: {type: 'param'} برای پارامترهای اکشن.
موانع فنی شامل یک استقرار شکستخورده در ساعت ۲۰:۴۶ بود زیرا options.list به جای رشتهها، به اشیای {title, value} نیاز داشت. عامل برای شناسایی این مورد از valibot برای اعتبارسنجی تعاریف استفاده کرد. سایت بین ساعت ۲۰:۴۸ تا ۲۰:۵۵ توسعه یافت و حلقه بازبینی نهایی از ۲۱:۲۴ تا ۲۲:۵۳ اجرا شد.
این تغییر، حاکمیت هوش مصنوعی را از «پرامپتهای نامرئی» به «سوابق مرئی» منتقل میکند. به جای امید به اینکه عامل از دستورات سیستمی پیروی کند، توسعهدهنده یک دفتر کل دائمی از هر اقدام عمومی و تاییدکننده آن دارد. برای توسعهدهندگان، این به معنای کاهش «ترس» از دادن کلید API محیط تولید به یک عامل است. شما دیگر به منطق داخلی عامل اعتماد نمیکنید، بلکه به دروازه گردشکار اعتماد میکنید. این معماری، عامل را از یک بازیگر خودمختار ریسکی به یک کارمند تحت نظارت تبدیل میکند.
برای مشاهده این سیستم در عمل، میتوانید با عامل نمایشی «Haiku Kid» در agent-permission-slip.vercel.app تعامل داشته باشید. این عامل از پست کردن هایکو در دیوار عمومی خودداری میکند تا زمانی که یک بازدیدکننده برگه اجازه آن را امضا کند. هر کسی میتواند یک برگه را رد کند زیرا «نه» گفتن همیشه امن است، اما فقط اعضای پروژه میتوانند برگههای علامتگذاری شده را در Sanity Studio بازبینی کنند.
گام بعدی شما
- اگر از عاملهای کدنویس استفاده میکنید، یک لایه تاییدیه (Approval Gate) ساده برای دسترسیهای Write در گیتهاب تعریف کنید.
- دمو «Haiku Kid» را در
agent-permission-slip.vercel.appبررسی کنید تا با مفهوم امضای دیجیتال برای عاملها آشنا شوید. - بررسی کنید که آیا ابزارهای فعلی شما سوابق تغییرات (Audit Log) را بهصورت انسانی قابلفهم ثبت میکنند یا خیر.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو