اولین گردش کار (workflow) عامل شما با یک پرامپت و چند ابزار شروع می‌شود. به سوالات پاسخ می‌دهد. وضعیت سفارش را بررسی می‌کند. کار می‌کند، پس آن را عرضه می‌کنید.

سپس محصول رشد می‌کند. تیم فروش یک به‌روزرسان CRM می‌خواهد که یادداشت‌های جلسات را همگام‌سازی کند. تیم پشتیبانی به یک گردش کار بازپرداخت نیاز دارد که سه سیستم داخلی را درگیر کند. تیم مهندسی قابلیت‌های مرورگر را برای پر کردن فرم‌های تامین‌کنندگان اضافه می‌کند. هر درخواست کوچک به نظر می‌رسد. هر کدام فایل پرامپت، رشته گفتگو در Slack و «اصلاح سریع» مخصوص به خود را پیدا می‌کنند. شش ماه بعد، عامل شما دیگر یک سیستم واحد نیست. بلکه مجموعه‌ای پراکنده از پرامپت‌های کپی‌شده، قوانین تجاری پنهان و تصمیماتی است که در رشته گفتگوهای قدیمی گرفته شده و هیچ‌کس نمی‌تواند آن‌ها را پیدا کند. این همان «پراکندگی پرامپت» (prompt sprawl) است. این وضعیت باعث می‌شود محصول هوش مصنوعی شما به سختی تست شود، به سختی بازبینی شود و با اطمینان غیرممکن باشد که آن را به حالت قبل بازگردانید (roll back).

راه حل، یک «ثبت مهارت» (skill registry) برای عامل‌های هوش مصنوعی است.

مهارت در واقع چیست

یک مهارت، صرفاً پرامپتی نیست که در یک پوشه ذخیره شده باشد. بلکه یک بسته نسخه‌گذاری‌شده و قابل تست است که تعریف می‌کند عامل چه کاری انجام می‌دهد، از کدام ابزارها می‌تواند استفاده کند و هرگز نباید چه کاری انجام دهد. آن را به عنوان قراردادی بین تیم شما و ماشین در نظر بگیرید. وقتی یک عامل، یک مهارت را بارگذاری می‌کند، باید دقیقاً بداند مرزهایش کجاست و موفقیت چه شکلی است.

بدون این ساختار، هر پرامپت به یک سیستم تولیدی کوچک و اعلام‌نشده تبدیل می‌شود. این پرامپت‌ها دارای مجوزهای پنهان، قوانین تجاری تعبیه‌شده و اثرات هزینه‌ای هستند که هیچ‌کس آن‌ها را ردیابی نکرده است. این پرامپت‌ها از محصول واقعی فاصله می‌گیرند، زیرا نقشه راه محصول (roadmap) تغییر کرده اما پرامپت در جای قبلی باقی مانده است. بدتر از همه این است که کپی می‌شوند. کسی آن را برای یک دمو فورک (fork) می‌کند یا در یک میکروسرویس جدید می‌چسباند، و حالا شما دو منبع حقیقت دارید که در تاریکی از هم فاصله می‌گیرند.

چرا پرامپت‌ها به تنهایی از هم می‌پاشند

پرامپت‌ها شبیه متن هستند، بنابراین تیم‌ها با آن‌ها مانند پیکربندی (configuration) برخورد می‌کنند. در واقعیت، آن‌ها بسیار بیشتر از آنچه کسی اعتراف می‌کند به کد نزدیک هستند. یک پرامپت در محیط تولید معمولاً منطقی را در مورد ترتیب اجرا، قالب‌بندی، مدیریت خطا و کنترل دسترسی کدگذاری می‌کند. وقتی آن منطق فقط در زبان طبیعی وجود داشته باشد، با ابهام مواجه می‌شوید. آیا عامل اجازه به‌روزرسانی CRM را دارد یا پرامپت فقط آن را پیشنهاد داده است؟ اگر API صورت‌حساب از کار بیفتد، آیا پرامپت می‌داند چگونه با امنیت شکست بخورد (fail safely) یا یک پیام موفقیت خیالی (hallucinate) تولید می‌کند؟

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

انحراف (Drift) زمانی رخ می‌دهد که کسب‌وکار تغییر می‌کند اما متن تغییر نمی‌کند. سیاست بازپرداخت شما اکنون برای مبالغ بالاتر از یک حد مشخص، نیاز به تأیید مدیر دارد. اگر آن قانون به جای یک لایه سیاست (policy layer)، درون یک پرامپت باشد، باید تمام نسخه‌های منتشر شده را جستجو کنید تا کپی‌هایی را که نیاز به به‌روزرسانی دارند پیدا کنید. اگر یکی را از قلم بیندازید، عامل‌هایی خواهید داشت که پول‌هایی را پرداخت می‌کنند که نباید.

آناتومی یک مهارت در محیط تولید

اگر می‌خواهید از این آشفتگی رها شوید، با هر مهارت مانند یک مصنوع نرم‌افزاری (software artifact) برخورد کنید. یک مهارت کاربردی در محیط تولید، چیزی فراتر از متن است. به موارد زیر نیاز دارد:

  • نام و هدف. نه "prompt_v3_final"، بلکه "process_standard_refund" همراه با توضیحی روشن از هدف تجاری.
  • طرح ورودی (Input schema) و بافت (context) مورد نیاز. فیلدهای دقیقی که مهارت انتظار دارد را تعریف کنید. آیا به شناسه کاربر، تاریخچه گفتگو یا شناسه مستاجر (tenant identifier) نیاز دارد؟ استفاده از تایپینگ قوی (Strong typing) در اینجا از حدس و گمان‌های عامل جلوگیری می‌کند.
  • مجوزهای ابزار و محدودیت‌های ایمنی. به‌طور صریح لیست کنید که مهارت می‌تواند کدام ابزارها را فراخوانی کند. برای تلاش‌های مجدد (retries)، محدودیت‌های هزینه و سقف نرخ درخواست (rate caps)، حفاظ‌هایی (guardrails) تعیین کنید. اگر مهارت نباید به API حذف کاربر دسترسی داشته باشد، این را در کد بیان کنید، نه فقط در متن.
  • معیارهای موفقیت و موارد تست. یک مهارت صرفاً به این دلیل که اجرا می‌شود، «کار می‌کند» نیست. تعریف کنید که خروجی باید شامل چه مواردی باشد. برای یک مهارت بازپرداخت، موفقیت ممکن است به معنای یک رکورد تراکنش تأیید شده، ارسال ایمیل تأیید و ایجاد یک ورودی در گزارش بازرسی (audit log) باشد.
  • تاریخچه نسخه و وضعیت مالکیت. یک نفر باید مسئول این مهارت باشد. یک لیست تغییرات (changelog) باید توضیح دهد که چرا نسخه v2.3 ایجاد شده و چه چیزی در نسخه v2.2 خراب شده است.

لایه‌های خود را جدا کنید

بزرگترین اشتباهی که تیم‌ها مرتکب می‌شوند، چپاندن همه چیز در یک پرامپت است. آن‌ها راهنمایی‌های دوستانه، مستندات ابزار، سیاست‌های امنیتی و مدیریت خطا را در یک دیوار از متن با هم مخلوط می‌کنند. این کار غیرقابل نگهداری است.

آن را تفکیک کنید:

  • Instructions (دستورالعمل‌ها) راهنمایی‌هایی برای عامل (agent) هستند. آن‌ها لحن، قالب و رویکرد کلی را توضیح می‌دهند.
  • Tool Rules (قوانین ابزار) به عامل می‌گویند چه ابزارهایی وجود دارند و چه کاری انجام می‌دهند. این مرحله از نوع کشف (discovery) است، نه گرفتن اجازه.
  • Policy (سیاست) توسط کد اجرا می‌شود، نه با امید و دعا. اگر یک بازپرداخت بیش از ۵۰۰ دلار نیاز به بررسی مجدد دارد، آن بررسی در یک تابع اعتبارسنجی (validation function) قرار دارد که قبل از فراخوانی ابزار اجرا می‌شود.
  • Evals (ارزیابی‌ها) تست‌هایی هستند که ثابت می‌کنند مهارت پس از هر تغییر، همچنان کار می‌کند.

به عنوان مثال، ننویسید: «لطفاً هرگز شماره کامل کارت اعتباری مشتری را فاش نکنید.» در عوض، یک فرمت‌کننده داده (data formatter) بسازید که شماره‌های PAN را قبل از اینکه عامل آن‌ها را ببیند، پنهان کند. سیاست‌ها باید در کد باشند، زیرا یک کاربر با ورودی‌های هوشمندانه نمی‌تواند کد را از انجام وظیفه‌اش منصرف کند.

از اتصال محیط عملیاتی (Production) به نسخه "Latest" خودداری کنید

هیچ‌چیز مثل یک به‌روزرسانی بی‌صدای پرامپت، عصر جمعه را خراب نمی‌کند. اگر عامل عملیاتی شما همیشه آخرین نسخه (latest) از یک مهارت را فراخوانی کند، هر ادغام (merge) در شاخه main یک حادثه احتمالی در محیط زنده خواهد بود. شما به نام‌های مستعار (aliases) مانند dev ،staging و prod نیاز دارید. یک نسخه شناخته‌شده و تست‌شده را از طریق این مراحل ارتقا دهید. وقتی prod به نسخه v2.1.4 اشاره می‌کند، می‌توانید اجرای آن را نظاره کنید، رفتار آن را بسنجید و با خیال راحت بخوابید. اگر مشکلی پیش آمد، نام مستعار را به عقب برگردانید. شما نباید نیمه‌شب و تحت فشار، به دیباگ کردن زبان طبیعی بپردازید.

این انضباط همچنین تیم شما را مجبور می‌کند تا به سازگاری با نسخه‌های قبلی (backwards compatibility) فکر کنند. آیا نسخه v2.2 می‌تواند همان ساختار ورودی نسخه v2.1 را مدیریت کند؟ اگر نه، فرآیند ارتقا در مرحله staging با شکست مواجه می‌شود و شما قبل از اینکه مشتری متوجه شود، آن را شناسایی می‌کنید.

امنیت از درون بسته (Package) شروع می‌شود

یک ریجستری (registry) پر از پرامپت‌های حسابرسی‌نشده، یک آسیب‌پذیری در انتظار وقوع است. شما باید مهارت‌های خود را برای همان ریسک‌هایی که در کد اسکن می‌کنید، بررسی کنید.

به دنبال اسرار (secrets) یا کلیدهای API که به صورت هاردکد (hardcoded) در قالب‌های پرامپت جاسازی شده‌اند، بگردید. وب‌هوک‌های خارجی یا دستورات شل (shell commands) که داده‌ها را استخراج (exfiltrate) می‌کنند، بررسی کنید. مراقب تلاش‌ها برای نادیده گرفتن سیاست‌های سیستم باشید؛ مانند پرامپت‌هایی که حاوی عبارت "ignore previous instructions" هستند یا از عامل می‌خواهند پیکربندی خودش را فاش کند. این‌ها فقط تئوری نیستند؛ این‌ها الگوهای رایج در حملات تزریق پرامپت (prompt-injection attacks) هستند و خطرناک‌اند، زیرا اغلب همراه با متن‌های کپی‌شده‌ای می‌آیند که هیچ‌کس آن‌ها را بازبینی نکرده است.

بسته‌های مهارت خود را از طریق تحلیل استاتیک (static analysis) عبور دهید. اگر یک فایل مهارت حاوی یک URL است که در لیست مجاز (allowlist) نیست، فرآیند ساخت (build) را متوقف کنید. اگر به ابزاری اشاره می‌کند که در مانیفست (manifest) تأییدشده نیست، آن را رد کنید.

اگر نمی‌توانید آن را تست کنید، نمی‌توانید به آن اعتماد کنید

یک ریجستری بدون ارزیابی‌ها (evaluations)، فقط پوشه‌ای از پرامپت‌هاست. هر مهارت به یک مجموعه تست نیاز دارد که مسیرهای اصلی (happy path)، حالت‌های مرزی (edge cases) و حالت‌های شکست (failure modes) را آزمایش کند. برای مهارت‌های پرخطر، شما به چیزی فراتر از تست‌های عملکردی نیاز دارید. شما باید مرزهای دسترسی (permission boundaries) را بررسی کنید تا مطمئن شوید عامل نمی‌تواند داده‌های کاربر دیگری را ببیند. شما به بررسی‌های رفتار امتناع (refusal behavior checks) نیاز دارید تا تأیید کنید وقتی سیاست‌ها مانع یک اقدام می‌شوند، عامل پاسخ «نه» می‌دهد. شما به تست‌های مقاومت در برابر تزریق پرامپت نیاز دارید تا تأیید کنید ورودی‌های خصمانه (adversarial inputs) از محافظت‌های سطح کد شما عبور نمی‌کنند.

نام تست‌های خود را صریح انتخاب کنید. تستی با نام "refund_skill_rejects_negative_amount" دقیقاً به مهندس بعدی می‌گوید که چه رفتاری محافظت شده است. وقتی یک تست در طول ارتقای نسخه با شکست مواجه می‌شود، شما مدرک محکمی دارید که نسخه کاندید، ناامن است.

هدف واقعی، کنترل است

استفاده مجدد (Reuse) خوب است، اما کنترل است که جایگاه شغلی شما را حفظ می‌کند. یک ریجستری مهارت به تیم شما اجازه می‌دهد با اطمینان بگوید: این گردش کار تأیید شده است. این نسخه‌ای است که در محیط عملیاتی در حال اجراست. این‌ها ابزارهایی هستند که می‌تواند استفاده کند. و این دقیقاً روش بازگردانی (roll back) ما است.

این شفافیت، شما را از عرضه دموهای هوشمندانه به سمت مدیریت نرم‌افزارهای قابل اعتماد حرکت می‌دهد. دموها ذینفعان را برای ده دقیقه تحت تأثیر قرار می‌دهند. اما نرم‌افزار قابل اعتماد، ساعت سه صبح کار می‌کند، استثناها را به درستی مدیریت می‌کند و رفتار خود را فقط به این دلیل که کسی یک pull request را در بعدازظهر سه‌شنبه ادغام کرده است، تغییر نمی‌دهد.

ریجستری خود را بسازید. مهارت‌های خود را نسخه‌بندی کنید. سیاست‌های خود را در کد اعمال کنید. طوری تست کنید که انگار برنامه خوابتان به آن بستگی دارد. خودِ آینده‌تان از شما سپاسگزار خواهد بود.