ایجنت را مثل API نسخه‌بندی کن، نه مثل یک پرامپت در داشبورد
بیشتر تیم‌ها هنوز ایجنت را این‌طور «نسخه‌بندی» می‌کنند که پرامپت را در یک UI عوض کنند و امیدوار باشند سه‌شنبه بعد staging همان رفتار را داشته باشد. نتیجه رگرسیون بی‌صدا است. همان چت، ابزار دیگر، مدل دیگر، مجوز دیگر، و هیچ‌کس نمی‌تواند بگوید کدام ترکیب جواب خوب هفته پیش را ساخته.
اگر ایجنت به مشتری می‌رسد یا روی مسیر پروداکشن نشسته، مثل API با آن رفتار کن. کل بسته را نسخه بزن.
پرامپت واحد انتشار نیست
متن پرامپت یک ورودی است. رفتار به این‌ها هم بسته است: کدام ابزارها وجود دارند و schema آن‌ها چه می‌گوید، کدام مدل و کدام pin ارائه‌دهنده، تنظیم دما یا استدلال که سبک صدای ابزار را عوض می‌کند، مجموعه مجوز و دروازه تأیید، مجموعه بازیابی یا فایل مهارتی که در زمینه بار می‌شود، و موردهای eval که تعریف می‌کنند «هنوز به اندازه کافی خوب هست که منتشر شود».
هر کدام از این‌ها را عوض کنی، ایجنت را عوض کرده‌ای. فرستادن فقط diff پرامپت مثل این است که handler جدید HTTP بفرستی و بی‌صدا کلاینت دیتابیس را عوض کنی و اسمش را اصلاح جمله بگذاری.
حادثه‌هایی دیده‌ام که پشتیبانی قسم می‌خورد پرامپت عوض نشده. راست می‌گفتند. کسی allowlist ابزار را بازتر کرده بود. مدل شروع کرد به صدای ابزار نوشتنی که قبلاً نمی‌دید. رونوشت شبیه بود. اثر جانبی نه.
مانیفست را کنار کد بگذار
تعریف ایجنت را در ریپو نگه دار. نسخه را pin کن. در PR بازبینی کن. همان‌طور مستقر کن که سرویس را مستقر می‌کنی.
فرمت کمتر از قاعده مهم است. یک رشته نسخه باید کل بسته را نام ببرد. وقتی ابزار، schema، دستورالعمل، pin مدل، یا سیاست مجوز عوض شد آن را بالا ببر. برای غلط املایی سندی که ایجنت هرگز بار نمی‌کند بالا نبر.
بارگذاری زمان اجرا را به همان نسخه وصل کن. وقتی جواب بد منتشر شد، می‌توانی همان نسخه را بازپخش کنی به‌جای باستان‌شناسی در ویرایش‌های Slack.
قطعه‌هایی را که مهم‌اند موقع بار هش کن: هش فایل دستورالعمل، هش schema هر ابزار، هش پیکربندی مجوز، شناسه مدل. با شناسه درخواست لاگ کن. تیکت پشتیبانی می‌شود «کدام بسته؟» نه «ماه پیش بهش چه گفتیم؟».
Semver برای ایجنت، نه حال‌وهوا
از semver رابط برنامه‌نویسی قرض بگیر و کسلش کن.
patch برای عبارتی در دستورالعمل است که ابزار، مجوز، یا رد مورد انتظار ابزار را عوض نمی‌کند. غلط و روشن‌سازی فقط.
minor برای ابزار فقط‌خواندنی تازه، schema تنگ‌تر، مورد eval جدید، یا قابلیت اختیاری پشت پرچم است که پیش‌فرض خاموش است.
major برای ابزار نوشتنی تازه، برداشتن یک امتناع، مجوز بازتر، عوض شدن خانواده مدل، یا هر تغییری است که انتظار eval قبلی را باطل می‌کند.
pin مدل جزو بسته است. «آخرین را استفاده کن» pin نیست. اگر ارائه‌دهنده شناسه را عوض یا بازنشسته کرد، آن ارتقا یک PR عمدی با eval است، نه غافلگیری خودکار صبح دوشنبه. ادعای دقیق رفتار یک شناسه مدل را تا خود سند ارائه‌دهنده نخوانده‌ای قول نده. خود pin را قول بده.
eval اگر جزو بسته نباشد به حساب نمی‌آید
ایجنت نسخه‌دار بدون مورد eval یک حدس برچسب‌خورده است. کنار مانیفست مجموعه کوچک fixture نگه دار: ورودی، رد ابزار مجاز، نام ابزار ممنوع، و شکل استناد یا امتناع مورد انتظار. روی هر PR مانیفست اجرا کن. اگر تغییر schema صدای مورد انتظار را بشکند، یا تغییر مجوز ناگهان اجازه کاری مثل بازپرداخت بدهد، PR را رد کن.
بنچمارک پژوهشی لازم نیست. نگهبان رگرسیون لازم است برای رفتارهایی که یک بار آسیب زده‌اند: لو رفتن شناسه داخلی، اختراع سیاست، صدای ابزار نوشتن روی تیکت فقط‌خواندنی، جواب دادن قبل از جستجوی سند.
رد طلایی را داده نگه دار، نه اسکرین‌شات UI چت. اگر مجموعه را نتوانی در CI با همان بارکننده‌ای که پروداکشن استفاده می‌کند اجرا کنی، مجموعه نمایش است.
staging «یک پرامپت دیگر» نیست
نسخه بسته پروداکشن را در staging آینه کن. نسخه را مثل مصنوع ساخت ارتقا بده. اگر ایجنت رو به مشتری است، درصدی از ترافیک را روی نسخه جدید قناری کن. عقب‌گرد با رشته نسخه باشد، نه با چسباندن مجدد یک فیلد داشبورد زیر فشار.
ویرایشگر پرامپت داشبورد برای آزمایش خوب است. برای هر چیزی که اعتبارنامه به آن وصل است منبع حقیقت ضعیفی است.
این هفته چه کار کن
یک ایجنت پروداکشن را بردار. پرامپت سیستم را از داشبورد به فایل ببر. ابزارها و schema را در همان پوشه فهرست کن. شناسه مدل را pin کن. پنج مورد eval از شکست واقعی بنویس. پوشه را نسخه اولیه بزن و زمان اجرا را وادار کن روی هر درخواست آن نسخه را لاگ کند.
تغییر بعدی که ابزار یا مجوز را عوض می‌کند bump جزئی یا اصلی می‌گیرد، PR، و اجرای eval. همان انضباطی که برای API عمومی داری. ویرایش فقط پرامپت می‌تواند patch بماند. بقیه انتشار است.
ایجنتی که مهم است بهداشت انتشار می‌خواهد. بسته را نسخه بزن، وگرنه همان قطعی را با پرامپت جدیدتر دوباره کشف می‌کنی.
بسته را با درخواست هم‌تراز لاگ کن
نسخه روی دیسک اگر در درخواست نباشد به درد حادثه نمی‌خورد. زمان اجرا باید رشته نسخه، هش دستورالعمل، و شناسه مدل را با همان شناسه درخواستی بنویسد که لاگ اپ از قبل دارد. پشتیبانی آن‌وقت می‌تواند از تیکت به بسته برسد بدون اینکه داشبورد پرامپت را ورق بزند.
اگر دو محیط یک شماره نسخه را نشان می‌دهند ولی هش دستورالعمل فرق دارد، انتشار را خراب کرده‌ای نه کاربر را. شماره را فقط وقتی یکی بدان که بارگذار همان فایل‌ها را خوانده باشد. کپی دستی پرامپت به سرور کناری این تضمین را می‌شکند، حتی اگر برچسب git درست به نظر برسد.
پرسش‌های کوتاه
**غلط املایی پرامپت هم نسخه می‌خواهد؟** اگر ابزار و مجوز و رد eval عوض نشود، patch کافی است. اگر ایجنت آن فایل را اصلاً بار نمی‌کند، نسخه را بالا نبر.
**داشبورد را کامل حذف کنم؟** نه. برای آزمایش نگه دار. منبع حقیقت مسیر پروداکشن نباشد.
**eval چند مورد لازم دارد؟** به اندازه شکست‌هایی که قبلاً خورده‌ای و نمی‌خواهی تکرار شوند. پنج مورد واقعی بهتر از صد مورد خیالی است.