تا جایی که بیشتر ما به خاطر میآوریم، «تجربه توسعهدهنده» یا Developer Experience (DX) اصطلاح چتری بوده است که برای سنجش میزان استفادهپذیری، قابلیت اطمینان و اثربخشی APIها به کار میرفته است.
یک تجربه توسعهدهنده عالی، یعنی تجربهای که کارها را تا حد ممکن ساده میکند و اصطکاک را به حداقل میرساند، استاندارد طلایی محسوب میشود. اگر DX خود را درست پیادهسازی کنید، آوازه API شما همهجا پخش خواهد شد. (حداقل در تئوری.) اما به نظر میرسد آن روزها رو به پایان باشند.
مصرف داده بهصورت عاملیتمحور (Agentic) بهسرعت در حال افزایش است. گارتنر پیشبینی میکند که تا سال ۲۰۲۸، ۳۳٪ از اپلیکیشنهای سازمانی شامل هوش مصنوعی عاملیتمحور خواهند بود و این عاملها ۱۵٪ از تصمیمات روزمره کاری را بهصورت خودکار اتخاذ خواهند کرد.
در رویداد Dreamforce 2024، مدیرعامل Salesforce، مارک بنیوف، چشمانداز خود از یک میلیارد عامل هوش مصنوعی تا پایان سال ۲۰۲۶ را مطرح کرد.
اگر بخواهیم جمله معروف پل ریور را بد تعبیر کنیم: عاملها در راهاند.
در این مقاله بررسی میکنیم که رشد مصرف عاملیتمحور چه معنایی برای سرویسهای دیجیتال امروزی دارد. تفاوتهای کلیدی میان طراحی فناوری برای انسانها و برای عاملها را برجسته میکنیم و چند راهکار برای شروع تفکر درباره AX و بهبود آن ارائه میدهیم.
تکامل تجربه عامل (یکشبه اتفاق نیفتاد)
ابتدا یک تعریف سریع از AX ارائه کنیم:
تجربه عامل به طراحی محصول بهگونهای اشاره دارد که عاملهای هوش مصنوعی بتوانند آن را «درک کنند» و بهصورت خودکار و قابلاعتماد با آن تعامل داشته باشند. نه بیشتر، نه کمتر.
بهجای آنکه AX را صرفاً یک واژه مُد روز در دنیای فناوری بدانیم، بهتر است آن را گام بعدی در یک مسیر تکاملی طبیعی در نظر بگیریم؛ مسیری که مدتهاست در حال شکلگیری است.
یک پست وبلاگی از Adobe در سال ۲۰۱۷ اشاره میکند که اصطلاح UX (تجربه کاربری) احتمالاً توسط دونالد نورمن، زمانی که در اوایل دهه ۱۹۹۰ بهعنوان «معمار تجربه کاربری» به اپل پیوست، رایج شد. البته خود مفهوم UX بسیار قدیمیتر از آن است.
تجربه کاربری خوب چیزی جز ساخت محصولی نیست که تا حد ممکن برای کاربران نهایی شهودی و قابلفهم باشد.
زمانی که جرمایا لی کوهیک در سال ۲۰۱۱ اصطلاح Developer Experience (DX) را در مقاله «Effective Developer Experience» معرفی کرد، کسی DX را متهم نکرد که قصد جایگزینی UX را دارد. (در دنیای APIها، جایی که تقریباً تمام مصرفکنندگان توسعهدهنده هستند، DX و UX عملاً یک معنا دارند.) DX صرفاً زاویه دید متفاوتی به نوع خاصی از تجربه کاربری بود.
به همین شکل، AX در واقع UX است، با این تفاوت که کاربر یک عامل هوش مصنوعی است.
در سخنرانیای درباره ساخت تجربه ایدهآل عامل در رویداد Platform Summit 2025، جان گرن از Gravitee تأکید کرد که:
«یک عامل باید یک کاربر در اکوسیستم شما باشد. باید شهروند درجهیک باشد، درست مانند انسانها.»
هیچ نیازی نیست توسعهدهندگان API تمام بهترین شیوههای UX که تاکنون استفاده کردهاند را کنار بگذارند؛ چرا که توسعهدهندگان انسانی همچنان در آینده قابل پیشبینی با APIها کار خواهند کرد.
به بیان دیگر، AX به معنای کنار گذاشتن انسانها به نفع عاملهای خودمختار نیست، بلکه به معنای طراحی برای هر دو مخاطب بهصورت همزمان است.
با این حال، حتی در این مراحل ابتدایی استفاده خودکار از APIها، تفاوتهای مهمی میان نحوه تعامل انسانها و عاملها دیده میشود. برای مثال، عاملها تصمیمات را بهصورت برنامهنویسیشده میگیرند و تمایل بیشتری به زنجیرهسازی فراخوانیهای API دارند. با افزایش مصرف عاملیتمحور، بهینهسازی برای آن به یک ضرورت تبدیل خواهد شد.
عاملهای هوش مصنوعی و انسانها متفاوت عمل میکنند
(DX) اصطلاح چتری بوده است که برای سنجش میزان استفادهپذیری، قابلیت اطمینان و اثربخشی APIها به کار میرفته است.
یک تجربه توسعهدهنده عالی، یعنی تجربهای که کارها را تا حد ممکن ساده میکند و اصطکاک را به حداقل میرساند، استاندارد طلایی محسوب میشود. اگر DX خود را درست پیادهسازی کنید، آوازه API شما همهجا پخش خواهد شد. (حداقل در تئوری.) اما به نظر میرسد آن روزها رو به پایان باشند.
مصرف داده بهصورت عاملیتمحور (Agentic) بهسرعت در حال افزایش است. گارتنر پیشبینی میکند که تا سال ۲۰۲۸، ۳۳٪ از اپلیکیشنهای سازمانی شامل هوش مصنوعی عاملیتمحور خواهند بود و این عاملها ۱۵٪ از تصمیمات روزمره کاری را بهصورت خودکار اتخاذ خواهند کرد.
در رویداد Dreamforce 2024، مدیرعامل Salesforce، مارک بنیوف، چشمانداز خود از یک میلیارد عامل هوش مصنوعی تا پایان سال ۲۰۲۶ را مطرح کرد.
اگر بخواهیم جمله معروف پل ریور را بد تعبیر کنیم: عاملها در راهاند.
در این مقاله بررسی میکنیم که رشد مصرف عاملیتمحور چه معنایی برای سرویسهای دیجیتال امروزی دارد. تفاوتهای کلیدی میان طراحی فناوری برای انسانها و برای عاملها را برجسته میکنیم و چند راهکار برای شروع تفکر درباره AX و بهبود آن ارائه میدهیم.
تکامل تجربه عامل (یکشبه اتفاق نیفتاد)
ابتدا یک تعریف سریع از AX ارائه کنیم:
تجربه عامل به طراحی محصول بهگونهای اشاره دارد که عاملهای هوش مصنوعی بتوانند آن را «درک کنند» و بهصورت خودکار و قابلاعتماد با آن تعامل داشته باشند. نه بیشتر، نه کمتر.
بهجای آنکه AX را صرفاً یک واژه مُد روز در دنیای فناوری بدانیم، بهتر است آن را گام بعدی در یک مسیر تکاملی طبیعی در نظر بگیریم؛ مسیری که مدتهاست در حال شکلگیری است.
یک پست وبلاگی از Adobe در سال ۲۰۱۷ اشاره میکند که اصطلاح UX (تجربه کاربری) احتمالاً توسط دونالد نورمن، زمانی که در اوایل دهه ۱۹۹۰ بهعنوان «معمار تجربه کاربری» به اپل پیوست، رایج شد. البته خود مفهوم UX بسیار قدیمیتر از آن است.
تجربه کاربری خوب چیزی جز ساخت محصولی نیست که تا حد ممکن برای کاربران نهایی شهودی و قابلفهم باشد.
زمانی که جرمایا لی کوهیک در سال ۲۰۱۱ اصطلاح Developer Experience (DX) را در مقاله «Effective Developer Experience» معرفی کرد، کسی DX را متهم نکرد که قصد جایگزینی UX را دارد. (در دنیای APIها، جایی که تقریباً تمام مصرفکنندگان توسعهدهنده هستند، DX و UX عملاً یک معنا دارند.) DX صرفاً زاویه دید متفاوتی به نوع خاصی از تجربه کاربری بود.
به همین شکل، AX در واقع UX است، با این تفاوت که کاربر یک عامل هوش مصنوعی است.
در سخنرانیای درباره ساخت تجربه ایدهآل عامل در رویداد Platform Summit 2025، جان گرن از Gravitee تأکید کرد که:
«یک عامل باید یک کاربر در اکوسیستم شما باشد. باید شهروند درجهیک باشد، درست مانند انسانها.»
هیچ نیازی نیست توسعهدهندگان API تمام بهترین شیوههای UX که تاکنون استفاده کردهاند را کنار بگذارند؛ چرا که توسعهدهندگان انسانی همچنان در آینده قابل پیشبینی با APIها کار خواهند کرد.
به بیان دیگر، AX به معنای کنار گذاشتن انسانها به نفع عاملهای خودمختار نیست، بلکه به معنای طراحی برای هر دو مخاطب بهصورت همزمان است.
با این حال، حتی در این مراحل ابتدایی استفاده خودکار از APIها، تفاوتهای مهمی میان نحوه تعامل انسانها و عاملها دیده میشود. برای مثال، عاملها تصمیمات را بهصورت برنامهنویسیشده میگیرند و تمایل بیشتری به زنجیرهسازی فراخوانیهای API دارند. با افزایش مصرف عاملیتمحور، بهینهسازی برای آن به یک ضرورت تبدیل خواهد شد.
عاملهای خودمختار هوش مصنوعی صرفاً یک مصرفکننده دیگر API نیستند. آنها نمیتوانند نقاط پراکندهای را که یک کاربر انسانی میتواند به هم وصل کند، به هم ربط دهند. نمیتوانند از «عقل سلیم» برای درک یک تعریف مبهم استفاده کنند و قطعاً از ارجاعات طنزآمیز مثل Back to the Future در مقدمه مستندات شما لذت نمیبرند.
به گفته گرن: «تجربه عامل ضعیف به این معناست که عاملها نمیدانند چه کاری انجام دهند و در نتیجه ابزار دیگری را انتخاب میکنند.»
در ادامه، چند راهکار برای جلوگیری از این اتفاق بررسی میشود.
۱. عاملها به مستندات شفاف و بدون ابهام نیاز دارند
ابزارهای هوش مصنوعی در استنتاج زمینه یا خواندن بین خطوط ضعیف هستند. اگر عباراتی مانند «چند تا» یا «کمی امتحان کن» استفاده شود، احتمال زیادی وجود دارد که عامل دچار سردرگمی شود. این موضوع در مورد اصطلاحات پیچیدهتر و زبان مرتبط با APIها نیز صدق میکند.
گفته میشود محتوایی که برای مصرف AI طراحی میشود، باید کمتر شبیه پست وبلاگ و بیشتر شبیه قرارداد حقوقی باشد. تجربه عامل عالی یعنی حداکثر شفافیت و پیشبینیپذیری. یعنی بدون زبان بازاریابی، بدون تغییر در تعاریف، و با قوانین و محدودیتهایی که هیچ جایی برای تفسیر باقی نمیگذارند. چون «لغزش» عاملیتمحور میتواند فاجعهبار باشد.
گرن میگوید: «باید بتوانیم به عاملها اعتماد کنیم که از حدود دسترسی خود فراتر نمیروند. همچنین به قابلیت توضیحپذیری نیاز داریم تا بدانیم دقیقاً چه اقداماتی انجام دادهاند.»
۲. کشفپذیری باید در اولویت باشد
اگر به یک عامل هوش مصنوعی نگویید که API شما چه کاری میتواند انجام دهد، بعید است خودش به آن پی ببرد. حتی ممکن است به سراغ API یا سرویس دیگری برود، در حالی که API شما همان قابلیت را دارد اما مستند نشده است.
فراتر از مستندسازی کامل تمام قابلیتها، این موضوع شامل استفاده از اسکیماهای دقیق، استانداردهایی مانند OpenAPI Specification، بهروزرسانی منظم مستندات و استفاده از Model Control Protocol (MCP) نیز میشود.
دهانبهدهان شدن بین عاملهای هوش مصنوعی وجود ندارد. آنها کنار آبسردکن درباره API فوقالعادهای که کشف کردهاند صحبت نمیکنند. بنابراین باید مطمئن شویم اطلاعات جایی منتشر میشود که عاملها بتوانند آن را پیدا کنند.
۳. در نظر گرفتن احراز هویت و مجوزدهی
هوش مصنوعی با الگوهای احراز هویت به شکل امروزی مشکل دارد. ریدایرکت و کپچا برای انسانها ساده است، اما برای عاملهای خودمختار میتواند بنبست ایجاد کند.
تجربه عامل مؤثر نیازمند احراز هویت غیرتعاملی و مسیرهای مشخص برای زمانی است که احراز هویت یا مجوزدهی شکست میخورد.
گرن پیشنهاد میکند که هنگام واگذاری کنترل به عاملها، از توکنهای کوتاهعمر و مجوزهای محدود استفاده شود.
تعریف شفاف مرزهای دسترسی عاملها، میتواند اعتماد کاربران انسانی بدبین به AI را نیز افزایش دهد.
۴. پذیرش رشد MCP
Model Context Protocol (MCP) که متنباز بوده و توسط Anthropic پشتیبانی میشود، استانداردی برای اتصال اپلیکیشنهای هوش مصنوعی به پلتفرمهای خارجی است. MCP بهعنوان «USB-C برای اپلیکیشنهای AI» توصیف شده است.
به گفته گرن: «اگر یک عامل بتواند MCP صحبت کند، میتواند با سرویس شما یکپارچه شود.»
یکی از چالشها در MCP، مدیریت پنجرههای کانتکست برای جلوگیری از تورم توکنهاست. تکنیکهایی مانند کوچکسازی اسکیما، برش کانتکست و فشردهسازی میتوانند مفید باشند.
۵. پایداری و مدیریت خطا
وقتی یک فراخوانی API برای کاربر انسانی شکست میخورد، احتمالاً یک ایمیل یا تیکت پشتیبانی دریافت میکنید. اما عاملها چنین کاری نمیکنند. آنها فقط از کار میافتند و همانطور باقی میمانند.
پیامهای خطایی که مشکل را توضیح دهند و مسیر بازیابی را مشخص کنند، همراه با ابزارهای مشاهدهپذیری API، برای استفاده عاملها حیاتی هستند.
گرن پیشنهاد میکند معیارهای پذیرش عامل و تستهای خودکار عاملها پیش از انتشار عمومی اجرا شوند.
تجربه عامل، محرک مصرف عاملهای هوش مصنوعی
در بررسی وضعیت API در سال ۲۰۲۵، مشخص شد که با وجود استفاده گسترده از ابزارهای gen AI، تنها ۲۴٪ از پاسخدهندگان APIهای خود را با در نظر گرفتن عاملها طراحی کردهاند.
این در حالی است که:
-
فوربس پیشبینی میکند تا ۷۰٪ کارهای اداری در دهه آینده خودکار شوند
-
میانگین استفاده API در سازمانها بین ۰.۵ تا ۲ API بهازای هر کارمند است
-
در سال ۲۰۱۸، ۸۳٪ ترافیک وب مربوط به APIها بوده است
این آمار نشان میدهد موج مصرف عاملیتمحور اجتنابناپذیر است.
خلاصه
این مقاله توضیح میدهد تجربه عامل (AX) چیست، چگونه UX و DX را برای عاملهای خودمختار گسترش میدهد و چرا ارائهدهندگان API باید خود را برای مصرف ماشینی آماده کنند.
