دیفالتهای غلط؛ مانیفستی برای ایجنتهای هوش مصنوعی
هوش مصنوعیخلاصهٔ کاملتر
نویسندهٔ این پست میگه رابط ایجنتهای هوش مصنوعی همه شبیه هم شدن: چند سشن چت، انتخاب مدل، تنظیم لحن، اتصال MCP — یعنی پروتکل استانداردی که ابزارها رو به مدل وصل میکنه — بهعلاوهٔ skill و memory. به گفتهٔ اون اینا شدن «استاندارد صنعت» و هرکی ایجنت تازه میسازه همینا رو کپی میکنه. حرف اصلی مقاله اینه که این دیفالتها غلطن و باید شکسته شن.
استدلالش اینه که هر تنظیمات، در واقع یه راه مؤدبانه برای تحویلدادن بلاتکلیفی به کاربره: سازنده نقش تصمیمگیر رو میندازه گردن اون. نتیجهش اینه که کارمند وسط کار باید از خودش بپرسه اون بحث رو کجا داشتم، کانتکست پر شده یا نه، کدوم مدل رو بزنم. نویسنده اینو با آیفون مقایسه میکنه: انتخاب کمتر، ولی از جیب که درش میاری کار میکنه — و برای سازمانی که دنبال پذیرش انبوهه، همین نسخه درسته.
پیشنهادهای عملیش چهارتاست. یک: یک گفتوگوی همیشگی بهجای چند سشن، چون حل مشکل بودجهٔ کانتکست کار سازندهست نه کاربر. دو: نشوندن ایجنت داخل خود Slack یا Teams تا کپیپیست بین دو ابزار حذف شه و کانتکست تیم از دست نره. سه: یک ایجنت عمومی که بسته به نقش هر نفر skill بار میکنه، بهجای دهها ایجنت تخصصی. چهار: دادن ابزار عمومی مثل curl به ایجنت، بهجای یه CLI جدا برای هر سرویس.
دو تا از توصیههای رایج رو هم زیر سؤال میبره. میگه ساخت و نگهداری knowledge base و پایپلاین RAG — یعنی بیرونکشیدن دادهٔ شرکت از یه مخزن و دادنش به مدل — یه کامپوننت مهندسی سنگین و بیپایانه، درحالیکه مدلهای امروز با همون دادهٔ نامرتب و یه دستور روشن، جوابهای بهقدر کافی دقیق میدن. fine-tuning رو هم گرون و نامطمئن میدونه و بهجاش دادهٔ زنده از API رو ترجیح میده، حتی به قیمت درخواستهای تکراری.
نکات کلیدی:
- یک گفتوگوی پیوسته بهجای چند سشن چت؛ مدیریت بودجهٔ کانتکست وظیفهٔ سازندهست
- یک ایجنت عمومی که skill رو بر اساس نقش کاربر بار میکنه، بهجای چندین ایجنت تخصصی
- ابزار عمومی مثل curl برای دسترسی به هر API، بهجای CLI جداگانه برای Jira و Confluence و Google
- ایجنت داخل Slack یا Teams، تا کانتکست گفتوگوی تیمی و فایلها از دست نره
- از نظر نویسنده RAG نگهداری سنگینی داره و fine-tuning گرون و نامطمئنه؛ دادهٔ زنده از API جایگزین بهتریه
