تأیید ابزار طراحی محصول است، نه یک چک‌باکس ایمنی
در دموهای ایجنت یک اشتباه را زیاد می‌بینم: تاگلی با برچسب «برای ابزار تأیید لازم است»، یک تیک سبز، و ادعایی که محصول حالا امن است. آن تاگل محصول نیست. یادآوری است که کسی هنوز حالت انتظار را طراحی نکرده.
تأیید ابزار یک گردش کار است. مکث دارد، تصمیم انسان دارد، مسیر ادامه دارد، و مجموعه‌ای از اثر جانبی که شاید قبل از هر کلیکی شروع شده باشد. اگر مثل پرچم مجوز روی یک completion با آن رفتار کنی، یا روی هر `ls` قفل می‌کنی یا آرام پروداکشن را عوض می‌کنی در حالی که تأییدکننده در جلسه است.
مکث ماشین حالت است، نه اسپینر
وقتی ایجنت به ابزار دروازه‌دار می‌رسد، اجرا باید طوری بایستد که بستن تب، استقرار، و چهار ساعت بی‌توجهی به Slack را تاب بیاورد. یعنی وضعیت ماندگار، چیزی مثل `waiting_for_approval`، که مال زمان اجرا باشد نه مال WebSocket مرورگر.
تیم‌هایی را دیده‌ام که «در انتظار تأیید» را فقط در state ری‌اکت نگه می‌دارند. کاربر رفرش می‌کند. اجرا فکر می‌کند رد شده. یا بدتر: فکر می‌کند هیچ اتفاقی نیفتاده و ابزار را دوباره می‌زند. مکث بدون ماندگاری فقط UI آویزان با جاه‌طلبی است.
ادامه مشکل را برعکس دارد. تأیید نباید کل نقشه را از گام اول بازپخش کند. باید از همان صدای ابزار مسدودشده با تصمیم ثبت‌شده ادامه دهد. زمان اجرای ماندگار این را کسل‌کننده و درجه‌یک می‌کند: شناسه اجرا می‌ماند، صدای ابزار در انتظار شناسه دارد، و worker بعدی «تأیید» یا «رد» را می‌بیند بدون حدس از متن چت.
زمان اجرا قلاب را می‌دهد. سیاست هنوز مال محصول است.
چه کسی تأیید می‌کند سؤال محصول است
«انسان در حلقه» وقتی انسان را نام نبری فرو می‌ریزد.
توسعه‌دهنده‌ای است که اجرا را شروع کرده؟ صاحب ریپو؟ مهندس آن‌کال برای هر چیزی که استقرار یا راز را لمس می‌کند؟ کانال تیمی که هر کس دسترسی نوشتن دارد مهر می‌زند؟
ایجنت داخلی دیده‌ام که کسی که پرامپت را تایپ کرده تنها کسی بوده که می‌توانسته مهاجرت دیتابیس را تأیید کند. برای sandbox تک‌نفره کار می‌کند. اولین باری که کسی اجرا را شروع می‌کند که روی `main` پول‌ریکوئست باز می‌کند و بعد می‌رود ناهار، می‌شکند. وقتی شروع‌کننده حساب ربات از یک webhook است هم می‌شکند.
تأییدکننده را با ریسک انتخاب کن، نه با مالکیت نشست:
بازرسی فقط‌خواندنی ریپو: بدون تأیید، یا اختیاری. نوشتن روی شاخه یا باز کردن PR پیش‌نویس: شروع‌کننده یا کسی با دسترسی نوشتن ریپو. ادغام، استقرار، چرخش راز، کسر از مشتری: نقشی که خود ایجنت نیست و ترجیحاً همان آدمی نیست که بی‌خیال پرامپت را زده.
اگر محصول نتواند بگوید «این یکی صاحب از تیم پلتفرم می‌خواهد»، تأیید ابزار نداری. یک modal داری.
تأییدکننده شواهد می‌خواهد، نه حال‌وهوا
دکمه‌ای که می‌گوید «اجازه `execute_sql`» و SQL را نشان نمی‌دهد بی‌فایده است. دکمه‌ای که کل رونوشت ایجنت را می‌ریزد هم بی‌فایده است. کسی قبل از استندآپ چهل نوبت را نمی‌خواند.
روی کارت تأیید این‌ها را می‌خواهم: نام ابزار و قصد کوتاه، آرگومان دقیق با redact جایی که لازم است، چرا ایجنت فکر می‌کند این قدم بعدی است در یکی دو جمله نه تخلیه زنجیره فکر، چه قبلاً اتفاق افتاده، شعاع انفجار شامل محیط و ریپو و صف و محدوده مشتری، و انقضا یعنی این تأیید چقدر زنده می‌ماند.
بدون این زمینه، آدم‌ها از خستگی تأیید می‌کنند. تأیید خستگی همان است که حادثه را با لاگ تمیز کلیک بله تحویل می‌دهد.
تأیید و رد هر دو idempotency می‌خواهند
این قسمت در پروداکشن می‌سوزاند.
انسان تأیید می‌کند. webhook دوباره می‌آید. handler ابزار را دو بار اجرا می‌کند. یا انسان رد می‌کند، UI مهلت می‌خورد، دوباره رد می‌کند، و رد دوم با ادامه کهنه مسابقه می‌دهد که ابزار را قبلاً شروع کرده.
تصمیم تأیید را مثل webhook پرداخت بدان. تصمیم را یک بار با کلید `toolCallId` ذخیره کن. اجرای ابزار گام جداست که چک می‌کند تصمیم وجود دارد، تأیید شده، و هنوز اجرا نشده. رد برای آن صدای ابزار پایانی است. اجرا را در حالت نیمه‌باز نگذار که retry بعدی از آن رد شود.
همچنین تصمیم بگیر رد برای کل اجرا یعنی چه. قطع؟ از ایجنت بخواه مسیر دیگر انتخاب کند؟ اجرا را با دلیل انسانی شکست‌خورده علامت بزن؟ محصول‌ها جواب مختلف می‌خواهند، ولی «رد» که بی‌صدا ادامه می‌دهد باگ با برچسب مؤدب است.
رد حسابرسی برای سه‌شنبه بعد از قطعی است
وقتی همه‌چیز کار می‌کند به UX تأیید اهمیت نمی‌دهی. اهمیت می‌دهی وقتی استقرار شب رفته بیرون و سه نفر قسم می‌خورند تأیید نکرده‌اند.
حداقل لاگ کن: چه کسی اجرا را خواسته، کدام صدای ابزار دروازه داشته، هش آرگومان یا محموله redactشده، چه کسی از کدام سطح تأیید یا رد کرده، زمان درخواست و تصمیم و اجرا، و آیا اجرا به‌خاطر تصمیم تکراری رد شده.
این را بیرون رونوشت چت نگه دار. رونوشت کوتاه، خلاصه، و توسط مدل بازنویسی می‌شود. ردیف حسابرسی باید کسل، فقط‌افزودنی، و به اندازه کافی خسته‌کننده باشد که امنیت بتواند بدون یادگیری سبک پرامپت تو بخواندش.
زمان اجرای ماندگار کار را تمام نمی‌کند
ایجنتی که بتواند روی صدای ابزار مکث کند، با webhook بیدار شود، و بدون از دست دادن sandbox ادامه دهد نسبت به «امیدوار باش تب چت باز مانده» پیشرفت واقعی است. آن زیرساخت را می‌خواهم. از آن استفاده می‌کنم.
ولی ماندگاری بدون مالکیت محصول فقط سیاست بد را طولانی‌تر زنده نگه می‌دارد. اگر هر کس بتواند استقرار پروداکشن را از اعلان گوشی بدون آرگومان تأیید کند، زمان اجرای ماندگار آن اشتباه را هر بار وفادارانه ثبت می‌کند.
پس به‌عنوان طراحی محصول مالک شو: حالت انتظار را تعریف کن، تأییدکننده را نام ببر، کارت شواهد را بفرست، تأیید و رد را idempotent کن، رد حسابرسی را نگه دار که از نشست مدل بیشتر عمر کند. چک‌باکس می‌تواند در پنل ادمین بماند. فقط تظاهر نکن که خود فیچر است.
پرسش‌های کوتاه
**هر ابزار را تأیید کنم؟** نه. خواندن و تست واحد نباید انسان را پیج کند. کار برگشت‌ناپذیر را دروازه بگذار.
**اگر تب را ببندند چه؟** اگر وضعیت فقط در مرورگر است، طراحی نکرده‌ای. وضعیت باید مال رانر باشد.
**رد یعنی اجرا تمام؟** باید صریح باشد. ادامه بی‌صدا بعد از رد باگ است.