تجربهی ایجنت: نوبتِ مهندسیِ محیطِ هوش مصنوعی
هوش مصنوعیخلاصهٔ کاملتر
نویسنده با این مقدمه شروع میکنه که ده سالِ گذشته همهی تمرکزش روی حلقهی بازخوردِ توسعهدهنده بوده؛ کامپایلر، لینتر، hot reload و پریویوِ هر برنچ، تورِ ایمنیِ سریع و قابلاتکایی میسازن که توسعهدهنده با خیال راحت کد بزنه. حالا یه نوع مشارکتکنندهی جدید وارد مخزنها شده: ایجنتهای هوش مصنوعی. ولی به گفتهی نویسنده ما اشتباهی اینها رو مثل جادوگر میبینیم، در حالی که ابزارهای کاملاً بیحالت (stateless) هستن که هیچ حافظهای از محصول ما ندارن.
نکتهی اصلیِ مقاله اینه که اگه میخوایم ایجنتها روی کدبیس واقعی کار مفید بکنن، باید از بهینهکردنِ صِرفِ پرامپت بگذریم و محیط اونها رو مهندسی کنیم. نویسنده اسم این رشته رو میذاره «تجربهی ایجنت» (AX) و تعریفش میکنه: طراحیِ لایهی بینِ مدل و کدبیسِ واقعی؛ یعنی کانتکست، ابزارها، دسترسیها، تستها و حلقههای بازبینی که به ایجنت میگن چی مهمه، به چی میتونه دست بزنه و از کجا بفهمه کارش درست بوده.
بعد هفت اصلِ کلیدی رو میچینه. اول اینکه کانتکست همون آنبوردینگه، منتها این بار سرِ هر تسک تکرار میشه؛ و کانتکستِ خوب مثل کدِ خوبه: کم، شفاف و تستشده، نه یه انبارِ بهمریخته از قانونهای قدیمی. دوم اینکه محیط بخشی از پرامپته: چون موتورِ مدل احتمالاتی و غیرقطعیه، بقیهی محیطِ اجرا باید کاملاً قطعی باشه؛ اگه ایجنت نتونه کد رو کامپایل کنه، سرورِ توسعه رو بالا بیاره یا دیتابیس رو seed کنه، خروجیش قابلاعتماد نیست.
اصل سوم: هیچ تحویلی بدون اثبات. نویسنده میگه ما داریم زحمتِ نوشتنِ کد رو با بارِ سنگینِ بازبینیِ اون عوض میکنیم؛ اگه برای هر PRِ ایجنت نیم ساعت دستی QA کنیم، ایجنت وقتی برامون آزاد نکرده، فقط کار رو جابهجا کرده. پس ایجنت باید قبلِ تحویل، شواهد بذاره: تستِ اجراشده، اسکرینشات، فلوهای بررسیشدهی مرورگر و لاگها. ابزارهایی مثل Chrome DevTools MCP و Playwright و پریویوِ خودکارِ برنچ کمک میکنن ایجنت قبلِ مصرفِ توجهِ بازبین، توکن خرج کنه؛ چون به قولِ نویسنده توکن ارزون و بیپایانه ولی تمرکزِ توسعهدهندهی ارشد گرونه.
اصل چهارم دربارهی امنیته: ایمنی باید ساختاری و قطعی باشه، نه یه جملهی خواهشی تو پرامپت. ایجنت سریع و تحتاللفظی عمل میکنه، پس کارهای خطرناک باید غیرممکن بشن، نه فقط سخت؛ با sandbox، کرِدِنشیالِ محدود، جداییِ دادهی توسعه و پروداکشن و تأییدِ انسانی برای کارهای پرریسک. نویسنده میگه هر وقت تو توییتر میبینه یه ایجنت دیتابیس رو پاک کرده، سؤالش اینه که اصلاً چرا سیستم همچین دسترسیای بهش داده بوده.
سه اصلِ آخر هم به همین منطق وصلن. مسیریابیِ مدل باید مثل زیرساختِ بیسروصدا باشه: مدلِ ارزون و سریع برای کارهای کمریسک مثل خلاصهسازی و دستهبندی، و مدلِ گرونِ استدلالی فقط برای قضاوتِ سختِ چندفایلی. معماریِ کد و دیزاینسیستم بهترین منبعِ حقیقت برای ایجنته؛ اگه کدبیس بهمریخته باشه، ایجنت همون آشفتگی رو به «آشغالِ خوشظاهر» تبدیل میکنه. و در نهایت ایجنتها به چسبِ بینِ تیمها تبدیل میشن، طوری که دیزاینر و PM و مارکتر هم بتونن داخلِ یه پریویوِ امن مستقیم با ایجنت کار کنن و توسعهدهنده دیگه آدمِ کپیپیستِ بازخوردها نباشه.
نکات کلیدی:
- ایجنتها ابزارهای بیحافظهان، نه متخصص؛ پس باید محیطشون رو مهندسی کرد نه فقط پرامپتشون رو
- AX یعنی طراحیِ کانتکست، ابزار، دسترسی، تست و حلقهی بازبینیِ بینِ مدل و کدبیس
- چون مدل غیرقطعیه، محیطِ اجرا باید کاملاً قطعی و قابلاتکا باشه
- ایمنی باید ساختاری باشه (sandbox، کرِدِنشیالِ محدود)، نه یه خواهشِ توی پرامپت
- ایجنت باید قبلِ تحویل، خودش شواهدِ درستیِ کارش رو جمع کنه تا بارِ بازبینی کم بشه
