‏ابزارسازی برای ایجنت‌ها، تخصص بعدی مهندس‌ها

Arize تو قسمتی از مجموعهٔ Rise of the AI Engineer با ایوان بورازین، هم‌بنیانگذار و مدیرعامل Daytona، حرف زده. Daytona سندباکس اجرای کد می‌فروشه و بورازین پیش‌بینی می‌کنه ایجنت‌ها به کاربر اصلی ابزارهای دیجیتال تبدیل بشن. به همین خاطر تعریف خودش از AI engineer شامل کسانی هم می‌شه که نرم‌افزار می‌سازن تا ایجنت‌ها استفاده کنن. نویسنده می‌گه جدی گرفتن این پیش‌بینی از یه سوال ساده شروع می‌شه: ایجنت می‌تونه یه کار واقعی مشتری رو با همون سطح دسترسی و بودجهٔ زمانی که دادی تموم کنه؟

گلایهٔ اول بورازین هویته: ایجنت‌هایی که استفاده می‌کنه طوری رفتار می‌کنن که انگار خودشن. تبدیل این گلایه به یه نیاز مهندسی یعنی مشخص کردن سیستم چه چیزی رو مجاز می‌دونه، مستقل از اینکه مدل خودشو چی معرفی کنه. مثلاً استاندارد OAuth token exchange (RFC 8693) اجازه می‌ده بین صاحب توکن و عاملی که به نمایندگی کار می‌کنه فرق بذاری. فقط دادن یه اکانت جدا به ایجنت مسئله رو حل نمی‌کنه، چون تصمیم‌های اصلی مجوزدهی سر جاشون می‌مونن: ممکنه کاربر گزارش یه پروژه رو اجازه بده ولی خروجی گرفتن از کل سازمان رو نه.

تو این مقاله اومده که agent harness (یعنی همون runtime که فراخوانی مدل و اجرای ابزار رو هماهنگ می‌کنه) می‌تونه context رو حمل کنه و جلوی tool call غیرمجاز رو بگیره، ولی سرویس‌هایی که درخواست رو اجرا می‌کنن هم باید خودشون authorization رو اعمال کنن. کد واسط مورد اعتماد می‌تونه credential رو نگه داره و فقط عملیات مجاز رو باز کنه، بدون اینکه خود secret بره داخل context مدل. کنارش یه audit record لازمه که بعد از اجرا بشه بازسازی کرد کدوم اپلیکیشن به نمایندگی کدوم کاربر چه کاری کرده.

گلایهٔ دوم جای خرابیه. نویسنده مثال می‌زنه: ایجنت داره گزارش آماده می‌کنه، از یه سرویس درخواست export می‌کنه و درخواست timeout می‌خوره. از خود timeout نمی‌فهمی سرویس درخواست رو رد کرده، شروع کرده، یا تمومش کرده. پس ابزار باید بگه وضعیت عملیات رو چطور چک کنی و کِی retry بی‌خطره. اگر بک‌اند idempotent request پشتیبانی کنه، می‌تونی همون کلید و پارامترها رو دوباره بفرستی، ولی این تضمین رو سرور می‌ده، نه اضافه کردن یه شناسه به درخواست. وقتی نتیجه همچنان نامعلوم می‌مونه، سیستم باید مسیر مشخصی برای reconciliation یا escalation داشته باشه.

گلایهٔ سوم، شکست روی کاری که ایجنت قبلاً انجامش داده. بورازین از نه بار موفقیت و بعدش یه شکست می‌گه، که به گفتهٔ نویسنده فقط نشون‌دهندهٔ ناامیدکننده بودن ماجراست و نرخ خرابی اندازه‌گیری‌شده‌ای به دست نمی‌ده. برای سنجیدنش باید یه task تکرارشدنی و تعریف روشنی از موفقیت داشته باشی، بعد مدل و دستورها و harness و بودجه‌ها رو ثابت نگه داری و هر نسخه رو چند بار از وضعیت اولیهٔ یکسان اجرا کنی، تو محیط تستی که ریست می‌شه. راهنمای Anthropic دربارهٔ ارزیابی ایجنت‌ها هم هشدار می‌ده state باقی‌مونده نتیجه رو خراب می‌کنه، چون یه export قدیمی می‌تونه به تلاش بعدی کمک کنه.

نویسنده یه trade-off رو هم یادآوری می‌کنه: پاسخ بزرگ‌تر ابزار بیشتر توضیح می‌ده ولی context بیشتری می‌خوره و ممکنه همون فیلدی که ایجنت لازم داره رو گم کنه؛ عملیات خیلی باریک هم یه کار رو ساده می‌کنه ولی بیان بقیهٔ کارها رو سخت‌تر. بورازین اشتباه استراتژیک خودشون رو تعلل تو سرمایه‌گذاری روی همین کار می‌دونه و می‌گه «ما هم شرط‌هامون رو پخش کردیم و به همین خاطر کندتر از چیزی که باید بودیم».

نکات کلیدی:

• بورازین می‌گه دسترسی نداشتن به ابزار بیشتر از خود مدل باعث شکست ایجنت‌هاش شده
• استاندارد OAuth token exchange (RFC 8693) بین صاحب توکن و عامل نماینده فرق می‌ذاره
• credential باید پیش کد واسط بمونه، نه داخل context مدل
• از یه timeout نمی‌شه فهمید export رد شده، شروع شده یا تموم شده؛ ابزار باید راه چک کردن وضعیت بده
• تضمین idempotency کار سرور هست، نه فرستادن یه شناسهٔ تکراری از سمت کلاینت
• برای مقایسهٔ دو پیاده‌سازی ابزار، مدل و harness و بودجه ثابت و محیط تست ریست‌شدنی لازمه
• کامل شدن کار مشتری با درست طی کردن workflow دو چیز جداست و باید جدا اندازه‌گیری بشن