Vercel Agent چون پیش‌فرض فقط‌خواندنی است به درد می‌خورد
گسترش ایجنت داخل داشبورد Vercel از این جهت جالب است که تحقیق روی پروداکشن، جواب به سؤال پروژه، و پیشنهاد عمل را یک‌جا گذاشته. بخشی که ارزش کپی کردن دارد جعبه چت نیست. حالت پیش‌فرض است: فقط‌خواندنی، تا وقتی انسان یک طرح با دامنه مشخص را تأیید کند، و کد تولیدشده قبل از نزدیک شدن به ترافیک زنده در سندباکس سنجیده شود.
این کمترین امتیاز با شکل محصول است. نقطه مقابلش همان الگوی داخلی است که هنوز زیاد می‌بینم: یک توکن پهن را در نوار کناری می‌چسبانند و امیدوارند پرامپت «مراقب باش» کافی باشد.
بازاریابی می‌گوید اقدام کن؛ طراحی می‌گوید اول بپرس
ایجنت می‌تواند PR باز کند، یک استقرار را برگرداند، یا پیکربندی را عوض کند. این فعل‌ها بوی خودمختاری می‌دهند. جریان واقعی باریک‌تر است. ایجنت با هویت خودش کار می‌کند، داخل مرز مجوز همان کاربری می‌ماند که درخواست داده، و تا وقتی به دسترسی بالاتر نیاز ندارد فقط می‌خواند. بعد یک طرح نشان می‌دهد، منتظر تأیید می‌ماند، کار را انجام می‌دهد، و با تمام شدن طرح به فقط‌خواندنی برمی‌گردد.
خود این توالی محصول است. بدون آن یک نشست چت داری که به پروداکشن وصل است. با آن چیزی نزدیک‌تر به درخواست تغییر داری: ایجنت پیش‌نویس را می‌نویسد و انسان امضا را مال خودش می‌داند.
دلیل اهمیتش این است که ایجنت داشبورد کنار همان سیگنال‌هایی نشسته که اشتباه در آن‌ها گران است: استقرار، لاگ، متریک، پیکربندی پروژه، مصرف، و ریپوی متصل. زمینه همان دلیل مفید بودن ایجنت است. زمینه همان دلیل بد بودن نوشتن پیش‌فرض هم هست. همان پنجره‌ای که جهش هزینه را توضیح می‌دهد می‌تواند اصلاحی را هم منتشر کند که قصدش را نداشتی.
کلید پروداکشن را به جعبه چت نده
شکل خرابی که در پروتوتایپ تیمی تکرار می‌شود ساده است. یک مدل را با توکن پهن به API پلتفرم، ابزار مشاهده‌پذیری، و GitHub وصل می‌کنند. یک جمله سیستمی می‌گذارند که بگوید مراقب باشد. اسمش را ایجنت SRE می‌گذارند. این مراقبت نیست. یک اعتبارنامه است که پشت زبان آزاد نشسته.
اگر ایجنت داشبورد را روشن می‌کنی، فعال‌سازی را مثل هر مسیر دسترسی پروداکشن دیگر حساب کن.
اول فقط چت و تحقیق. ببین چه می‌بیند قبل از اینکه بگذاری چیزی را عوض کند. عمل نوشتن را پشت کسانی نگه دار که از قبل حق استقرار دارند. «هر کس داشبورد را باز می‌کند» نباید تبدیل شود به «هر کس می‌تواند بازگشت را تأیید کند».
برای تغییری که کد یا پیکربندی متعلق به git است، اصلاح به‌شکل PR را به جهش مستقیم پروداکشن ترجیح بده. برای کار برگشت‌ناپذیر تأییدکننده نام‌دار بخواه: بازگشت استقرار، پاک کردن کش، عوض کردن env، ویرایش دامنه یا DNS.
ایجنتی که اصلاح را پیشنهاد می‌دهد نباید تنها کنشگری باشد که می‌تواند همان اصلاح را تأیید کند. همان قاعده‌ای که برای اپراتور انسانی داری.
کد تولیدشده را جدا از روایت بسنج
اجرای کد تولیدشده در یک محیط جدا، با کپی پروژه، تا بیلد و تست و linter قبل از ظاهر شدن پیشنهاد به‌صورت PR بشکنند، مرز درست وصله ایجنت است. اگر روی Vercel نیستی هم ایده را بردار، نه الزاماً محصول را.
طرح، مرز قابلیت است. تأیید یک توانایی کوتاه‌عمر برای همان طرح می‌دهد، نه یک نقش ایستاده که «ایجنت حق نوشتن در پروداکشن دارد». وقتی طرح تمام شد امتیاز جمع می‌شود.
اگر ایجنت بتواند پروداکشن را بدون یک شیء طرح که بعداً بشود حسابرسی کرد عوض کند، تأیید نداری. لاگ چت داری و پشیمانی.
این را با مسیر درخواست در اپ خودت یکی نکن. Route Handler که یک کار مشخص را با مجوز کاربر انجام می‌دهد، ایجنت نیست. ایجنت وقتی خطرناک می‌شود که قصد را از متن آزاد می‌گیرد و همان متن را به چند سیستم نوشتنی وصل می‌کند. مرز را روی عمل بگذار، نه روی لحن پرامپت.
rollout را از تشخیص شروع کن، نه از کلیک بازگشت
هفته اول فقط تحقیق. ایجنت را به استقرار شکست‌خورده و خطای زمان اجرا نشان بده. داستان علّی‌اش را با چیزی که آن‌کال از قبل می‌دانست مقایسه کن. اعتماد از کیفیت تشخیص می‌آید، نه از سرعت کلیک روی بازگشت.
بعد، برای یک پروژه غیرحساس اجازه بده PR باز کند. انسان هنوز بازبینی و ادغام می‌کند. ببین وصله‌ای که بیرون از پروداکشن سنجیده شده چند وقت بدون بازنویسی اساسی از بازبینی انسانی رد می‌شود. اگر تقریباً همیشه بازنویسی می‌شود، عمل عملیاتی را روشن نکن. اول کیفیت پیشنهاد را درست کن.
فقط بعد از آن عمل عملیاتی تأییدشده را در نظر بگیر: بازگشت، به‌روزرسانی پیکربندی، با همان جدیت مدیریت تغییر که برای انسان داری. عمل را به ایجنت، درخواست‌کننده، و تأییدکننده نسبت بده. اگر شش ماه بعد نمی‌توانی جواب بدهی «چه کسی این را تأیید کرد؟» مسیر نوشتن را دوباره خاموش کن.
خیال اینکه ایجنت داشبورد یک‌شبه SRE شود را کنار بگذار. الگو را نگه دار: پهن بخوان، باریک بنویس، طرح را تأیید کن، کد تولیدشده را دور از پروداکشن بسنج. این‌طور از ایجنتی که پروداکشن را می‌بیند ارزش می‌گیری بدون اینکه جعبه چت را پوسته root حساب کنی.
پرسش‌های کوتاه
**تحقیق فقط‌خواندنی هم خطر دارد؟** بله، اگر داده مشتری یا راز را داخل رونوشت چت بریزد. دیدن لاگ با کپی کردن لاگ داخل پرامپت یکی نیست. دامنه خواندن را هم تنگ کن.
**بازگشت خودکار را کی روشن کنم؟** وقتی تشخیص قابل اعتماد شده، تأییدکننده غیر از ایجنت داری، و می‌توانی بعداً بگویی چه کسی طرح را قبول کرده. زودتر از این، سرعت بازگشت هزینه حسابرسی را نمی‌دهد.
**PR بهتر از تغییر مستقیم است؟** برای کد و پیکربندی داخل git بله. برای عمل فوری زمان اجرا، PR تأخیر اضافه می‌کند ولی هنوز باید طرح و تأیید داشته باشد، نه دستور آزاد.