‏هارنس agent رو مثل یه محصول مدیریت کن

سسیلیا جرالدو از Thoughtworks تو این مقاله که بر پایه‌ی جلد ۳۵ Technology Radar نوشته شده، می‌گه agent harness دیگه یه جزئیات پیاده‌سازی نیست و باید مثل یه محصول مدیریت بشه. harness یعنی هرچیزی که بین مدل و کار واقعی قرار می‌گیره: دستورها و skillهایی که agent لود می‌کنه، ابزارهایی که صدا می‌زنه، مجوزها و sandboxها، سیاست انتخاب context، state بین مراحل، orchestration، ارزیابی و telemetry.

به گفته‌ی نویسنده هیچ‌کدوم از اینا تو مهندسی نرم‌افزار جدید نیستن، ولی قبلاً بین فریم‌ورک، تیم پلتفرم و CI پخش بودن. تو سیستم‌های agentic همه‌شون تو یه چیز جمع می‌شن که یه تیم کوچیک می‌تونه یه بعدازظهر عوضش کنه و معمولاً هیچ‌کس مسئولش نیست. سناریوی رایج: شش ماه بعد از اولین پروتوتایپ، یه پوشه Markdown داری، چند تا اسکریپت و یه نفر که می‌دونه منطق retry چرا اونجاست. نویسنده اینو «بدهی پیکربندی با یه system prompt» می‌دونه.

مقاله به استانداردهای جدید اشاره می‌کنه: Agent Plugins که skillها و MCP serverها رو تو یه پلاگین قابل نصب بسته‌بندی می‌کنه، و Agent Package Manager و marketplaceها که اجازه می‌دن قابلیت‌ها منتشر و pin بشن. نویسنده می‌گه یه prompt کپی‌شده نسخه و مسیر آپدیت نداره ولی یه پکیج داره. وقتی harness به پلاگین بقیه وابسته می‌شه، دیگه نرم‌افزاره و نگهداری می‌خواد.

به گفته‌ی نویسنده بیشتر تیم‌ها نمی‌تونن جواب بدن آخرین تغییر agent رو بهتر کرده یا بدتر. معیارهایی مثل توکن مصرفی یا تعداد پیشنهادهای قبول‌شده فقط نشون می‌دن سیستم مشغوله. پیشنهادش اینه که یه golden test set از ۲۰ تا ۳۰ کار واقعی بسازی، کنار harness نسخه‌بندیش کنی و رو هر تغییر مهم regression بگیری. هزینه و latency هم باید معیار اصلی باشن: harnessی که خروجی رو بهتر کنه ولی خرج رو دو برابر، محصول رو بهتر نکرده. قانونش ساده‌ست: بدون eval، هیچ تغییری نه.

درباره‌ی self-improving harness (یعنی harnessی که خودش دستورها و ابزارهاش رو عوض می‌کنه) نویسنده سه پیش‌شرط می‌ذاره: یه evaluation harness برای اندازه‌گیری، provenance تا هر تغییر قابل ردگیری و برگشت باشه، و یه مسیر rollback. قانونش اینه که پیشنهاد رو خودکار کن ولی تأیید رو دست آدم نگه دار.

تو سطح سازمان، enterprise harness یعنی تیم‌های پلتفرم باید auditability، کنترل دسترسی، sandboxing پیش‌فرض، allow-list پلاگین‌ها، model routing و سیاست deprecation رو مدیریت کنن. مهم‌ترین مسئله identity هست: agent با مجوز چه کسی کار می‌کنه و بدون پرسیدن چی کار می‌تونه بکنه. نویسنده هشدار می‌ده اگه harness رسمی از چیزی که یه تیم تو یه آخر هفته سرهم می‌کنه کندتر باشه، آدم‌ها دورش می‌زنن و shadow IT راه می‌افته که می‌تونه مشکل امنیتی بشه.

نکات کلیدی:

• harness شامل دستورها، ابزارها، مجوزها، context، state، orchestration، eval و telemetry هست
• Agent Plugins، skillها و MCP serverها رو تو یه پلاگین قابل نصب بسته‌بندی می‌کنه
• golden test set پیشنهادی: ۲۰ تا ۳۰ کار واقعی، نسخه‌بندی‌شده کنار harness
• هزینه و latency باید معیار اصلی باشن، نه فقط کیفیت خروجی
• self-improvement سه پیش‌شرط داره: eval، provenance و rollback
• harness کند و ناکارآمد باعث رشد shadow IT می‌شه
• سه سؤال پیشنهادی: صاحبش کیه، از کجا می‌دونی آخرین تغییر بهترش کرده، و به چی دسترسی داره