AI Agents as Users
نویسندگان: سارا گیبونز و کیت موران
تاریخ انتشار: ۱۰ آوریل ۲۰۲۶
این مقاله با رویکرد حفظ لغات تخصصی و تخصصی-مانند برای درک بهتر ترجمه شده است.
خلاصه برای ذهنهای کمطاقت
AI Agents اکنون در کنار انسانها با رابطهای دیجیتال تعامل دارند. طراحی برای هر دو نیازمند بازاندیشی در معنای “User” و اولویتبندی Accessibility است.
۱۲ نکته کلیدی از مقاله “AI Agents as Users”
۱. تعریف “User” باید تغییر کند
Agentها در هر sense functional یک user هستند: آنها goal دارند، با interface مواجه میشوند، سعی میکنند goal را انجام دهند، و interface یا موفق میشود یا نمیشود. فرض core باید بهروز شود: “User” دیگر مترادف با “Human” نیست.
۲. سه روش اصلی تعامل Agents با Interfaces
- Vision-Based Interaction: agent از صفحه screenshot میگیرد و با vision model تفسیر میکند. (slow، error-prone، token-intensive)
- Accessibility-Tree Parsing: agent درخت دسترسپذیری مرورگر را میخواند. (ارزانتر، قابل اعتمادتر)
- Direct API Access: agent مستقیماً از طریق API با سیستم ارتباط برقرار میکند. (بدون نیاز به interface)
۳. Accessibility کلید طراحی برای Agents است
Interfaces که برای accessibility خوب ساخته شدهاند، برای agents نیز legibleتر هستند: semantic HTML، برچسبگذاری مناسب، roles واضح، و hierarchy منطقی. همان اصول accessibility به agents نیز خدمت میکند.
۴. طراحی برای هر دو (Human و Agent) در کوتاهمدت
سه توصیه اصلی:
- برچسبگذاری clear و descriptive (اجتناب از icon-only buttons)
- الگوهای consistent و predictable
- حداقل وابستگی به visual-only information architecture
۵. کارهای ساده برای Agents به tasks بزرگ تبدیل میشوند
یک parent که میخواهد رویدادهای مدرسه را با calendar خانواده تطبیق دهد، برای agent تبدیل میشود به: پردازش screenshot، تشخیص dates از pixel clusters، handling محتوای dynamic، PDFها، و loginهای مختلف. هر مرحله احتمال error و token-use را افزایش میدهد.
۶. Accessibility سرمایهگذاری با ROI واضح است
کسبوکارهایی که در accessibility دقیق بودهاند، بدون اینکه بدانند، interfaces ساختهاند که agents میتوانند به طور مؤثر در آنها حرکت کنند. اکنون یک business case واضح برای سرمایهگذاری در accessibility وجود دارد.
۷. گاهی نمیخواهید Agents در محصول شما باشند
چهار سناریو:
- وقتی خود visit محصول ارزش دارد (سایتهای ad-supported)
- وقتی friction عمدی است (خدمات مالی، healthcare برای دلایل regulatory)
- وقتی از competitive intelligence محافظت میکنید (price data airlines)
- وقتی خودتان میخواهید لایه agent باشید
۸. ریسک رقابتی blocking agents
اگر بانکی به دلایل امنیتی agents را block کند، اما رقیب شروع به تبلیغ “پشتیبانی از agentic wealth managers” کند، چه؟ خروج کامل از agents نیز ریسک خاص خود را دارد.
۹. استاندارد MCP (Model Context Protocol)
استانداردهای در حال ظهور مانند MCP، رویکرد direct API access را استانداردتر میکنند. این agents را قادر میسازد بدون تعامل با representation بصری صفحه، مستقیماً دادهها را query و actions را execute کنند.
۱۰. در بلندمدت، لایه Interface واگرا میشود
زمانی که agents بتوانند structured data را مستقیماً query کنند، interface بصری برای آنها irrelevant میشود. اما humans هنوز به interfaces بصری و interactive برای comprehension و decision-making نیاز دارند.
۱۱. مشکلات فعلی با Vision-Based Interaction
یک screenshot واحد نیاز به پردازش دهها هزار token دارد، محتوای dynamic را در نظر نمیگیرد، و agents مجبورند از pixel clusters استنباط کنند که کدام متن date است، کدام title، و چگونه به هم مرتبط هستند.
۱۲. حرف آخر مقاله
تشخیص agents به عنوان users نیازمند گسترش فرضی implicit است که از ابتدای رشته طراحی داشتیم. آنچه تغییر میکند دامنه کسانی است که برای آنها طراحی میکنیم، و urgency اقداماتی که قبلاً میدانستیم مهم هستند: semantic structure، accessibility، clear labeling، و predictable interaction patterns.
مقدمه
جامعه طراحی دههها را صرف refine کردن معنای طراحی برای users کرده است. ما رفتارهای آنها را مطالعه میکنیم، journeys آنها را نقشهبرداری میکنیم، و فرضیات خود را در برابر نیازهایشان آزمایش میکنیم.
AI Agents (سیستمهایی که با انجام اقدامات تکراری، ارزیابی پیشرفت، و تصمیمگیری برای گامهای بعدی خود، یک هدف را دنبال میکنند) اکنون با همان رابطهای دیجیتالی که برای انسانها طراحی میکنیم، تعامل دارند.
آنها در وبسایتها حرکت میکنند، فرمها را پر میکنند، گزینهها را مقایسه میکنند، و تراکنشها را اجرا میکنند. از نظر functional، آنها users رابطهای ما هستند، حتی اگر آنها را به این عنوان نشناخته باشیم. یک تغییر conceptual مورد نیاز است. یک فرض core باید بهروز شود: “User” دیگر مترادف با “Human” نیست.
در این مقاله:
- تعریف در حال گسترش “User”
- چگونه Agents امروز با Interfaces تعامل میکنند
- چه چیزی هنگامی که Agents کاربر هستند خراب میشود
- کوتاهمدت: طراحی برای هر دو
- بلندمدت: زمانی که لایه Interface واگرا میشود
۱. تعریف در حال گسترش “User”
در بیشتر تاریخچه طراحی دیجیتال، کلمه “User” به طور ضمنی به معنای یک human در مقابل صفحه نمایش بوده است. بیشتر design heuristics، usability principles، و research methods یک human را در آن سوی خط فرض میکنند.
People در حال واگذاری یک تنوع تقریباً نامحدود از tasks به agents خود هستند: ترکیب calendars و اضافه کردن رویدادهای جدید، رزرو پرواز، بررسی پر شدن مجدد prescription، پیدا کردن بهترین محصول بررسیشده زیر یک قیمت مشخص. Agent با interfaces دیجیتال تعامل میکند تا اطلاعات را پیدا کند، actions موجود را درک کند، و آنها را execute کند، درست مانند یک human user.
اگرچه ممکن است برخلاف فلسفه user experience به نظر برسد، این واقعیت به این معناست که agent از هر جهت functional یک user است:
- یک goal دارد
- با یک interface روبرو میشود
- سعی میکند آن goal را از طریق آن interface به انجام برساند
- یا interface از آن تلاش پشتیبانی میکند یا نمیکند
این تمایز مهم است زیرا interfacesی که امروز طراحی میکنیم در حال fail کردن این نوع جدید user هستند. و آن agents نیز به نوبه خود، human آن سوی صفحه را fail میکنند.
۲. چگونه Agents امروز با Interfaces تعامل میکنند
سه رویکرد primary وجود دارد که agents برای تعامل با interfaces دیجیتال استفاده میکنند، و هر کدام مجموعه متفاوتی از فرضیات طراحی را نشان میدهد که از کار میافتند.
Vision-Based Interaction
رویکرد ابتداییترین، مشابه آن چیزی است که humans انجام میدهند: agent از interface یک screenshot میگیرد و از یک vision model برای تفسیر آنچه میبیند استفاده میکند. Agent به صفحه نگاه میکند، elements (buttons، text fields، navigation items) را شناسایی میکند، تصمیم میگیرد روی چه چیزی کلیک کند، و تکرار میکند.
این رویکرد expensive است — slow، از نظر محاسباتی wasteful، error-prone، و token-intensive است. یک screenshot واحد نیاز به پردازش دهها هزار token توسط model دارد و محتوای dynamic یا workflows چند مرحلهای را در نظر نمیگیرد.
Accessibility-Tree Parsing
به جای screenshot گرفتن از صفحه، agents همچنین میتوانند accessibility tree مرورگر را بخوانند (the structured representation of the page که browsers از HTML تولید میکنند). این همان data structure است که screen readers برای navigable کردن interfaces برای people با اختلالات بینایی استفاده میکنند.
Accessibility tree یک representation hierarchical و تمیز از page elements ارائه میدهد: roles، labels، states، و relationships آنها. پردازش آن به چند هزار token نیاز دارد (کسری از چیزی که یک screenshot نیاز دارد) و اطلاعات قابل اعتمادتری ارائه میدهد.
Interfacesی که به خوبی برای accessibility ساخته شدهاند، در حال حاضر برای agents نیز legibleتر هستند: semantic HTML، elements با برچسبگذاری مناسب، roles واضح، و logical page hierarchy نیز به agent users خدمت میکنند.
Direct API Access
رویکرد سوم به طور کامل interface را با agent-to-agent interactions و agent-to-API interactions دور میزند. زمانی که structured APIs در دسترس هستند، agents میتوانند دادهها را query کنند و actions را مستقیماً execute کنند، بدون نیاز به تعامل با هر representation بصری یا ساختاری از یک صفحه.
استانداردهای در حال ظهور مانند Model Context Protocol (MCP) این رویکرد را استانداردتر میکنند، اما نه لزوماً گستردهتر.
۳. چه چیزی هنگامی که Agents کاربر هستند خراب میشود
یک مثال معمولی را در نظر بگیرید. یک parent از agent خود میخواهد وبسایت مدرسه را برای رویدادهای پیشرو بررسی کند، آن تاریخها را با shared calendar خانواده تطبیق دهد، و هر گونه تداخلی را علامتگذاری کند. یک human صفحه رویدادها را scan میکند، تاریخها را یادداشت میکند، و calendar را بررسی میکند.
تجربه agent متفاوت است. وبسایت مدرسه برای این طراحی شده که یک parent به صورت بصری scan کند. رویدادها با dates، times، و descriptions مرتب شده از طریق spatial grouping فهرست شدهاند. یک human ممکن است برای خواندن این مشکل نداشته باشد، اما برای یک agent که یک screenshot را پردازش میکند، هر قطعه اطلاعات باید از pixel clusters استنباط شود: کدام متن یک date است، کدام یک title است، و چگونه به هم مرتبط هستند. صفحه رویدادها ممکن است به صورت dynamic لود شود و یک صفحه ناقص را capture کند. برخی رویدادها در وبسایت هستند، برخی دیگر در یک PDF قابل دانلود، و برخی دیگر پشت یک parent-portal login قرار دارند.
هر مرحله احتمال error و همچنین token-use را افزایش میدهد. انجام چنین چیزی معمولی و روزمره به یک task بزرگ تبدیل میشود، چه برسد به agents که tasks پیچیدهتری را انجام میدهند: ایجاد تغییرات در یک profile، سفارش یک کالا، یا بررسی availability و رزرو.
۴. کوتاهمدت: طراحی برای هر دو
در کوتاهمدت، سوال طراحی این است: “چگونه interfaces بسازیم که هم به human users و هم به agent users به طور همزمان خدمت کنند؟”
Accessibility Guidelines به این هدف طراحی میرسند:
- Clear, descriptive element names
- Predictable interaction patterns
- Logical page hierarchy
- Semantic HTML
- ARIA standards
سرمایهگذاری در accessibility کار درستی بوده است، اما اکنون یک business case واضح برای آن وجود دارد، زیرا agents در کوتاهمدت از این طریق از محصولات و services استفاده خواهند کرد. سازمانهایی که در مورد accessibility دقیق بودهاند، شاید بدون اینکه متوجه شده باشند، interfaces ساختهاند که agents در حال حاضر میتوانند به طور مؤثرتری در آنها حرکت کنند:
- Clear, descriptive labeling: از icon-only buttons، ambiguous link text (“اینجا کلیک کنید”)، و labels که به visual context وابسته هستند اجتناب کنید.
- Predictable, consistent patterns: ساختارهای navigation consistent، الگوهای فرم استاندارد، و state changes قابل پیشبینی احتمال compounding errors agents را در workflows چند مرحلهای کاهش میدهند.
- Minimal reliance on visual-only information architecture: ساختار markup باید منعکسکننده grouping بصری باشد تا agents بتوانند relationships را درک کنند.
هیچ یک از این توصیهها جدید نیستند. آنها همان اصولی هستند که interfaces را برای humans با disabilities کاربردیتر، در دستگاهها و contextهای مختلف robustتر، و در طول زمان maintainableتر میکنند.
چه میشود اگر Agent را در محصول خود نمیخواهید؟
مطمئناً مدلهای business و دستهبندیهای محصولی وجود دارند که داشتن یک agent در محصول ممکن است نامطلوب باشد. استدلال برای طراحی با در نظر گرفتن agents این فرض را میکند که اهداف users شما و اهداف business شما هنگامی که یک machine از طرف user عمل میکند، همسو باقی میمانند. این همیشه درست نیست.
زمانی که Visit خود محصول است
برخی businesses به این بستگی دارند که humans واقعاً از محصول بازدید کنند. برای این شرکتها، یک agent که value را بدون بازدید استخراج میکند، یک مشکل existential است. Ad-supported content و content marketing sites قبلاً شروع به دیدن impacts این تغییر در metrics خود کردهاند.
Streaming services نیز نسخهای از این مشکل را دارند. Netflix میخواهد شما browse کنید — browse time محتوای original را نمایان میکند و حلقه engagement را عمیقتر میکند که retention را هدایت میکند. یک agent که به این سوال پاسخ میدهد “امشب چه چیزی تماشا کنم؟” بدون اینکه user هرگز اپ را باز کند، تجربه discovery را که Netflix سالهاست بهینهسازی کرده تضعیف میکند.
زمانی که Friction عمدی است
هر friction در یک interface یک شکست طراحی نیست. در برخی domains، friction به دلایل regulatory، legal، یا safety وجود دارد — و حذف آن ایجاد liability میکند.
Financial services پر از مثالهای این موضوع است. یک کارگزاری که اجرای trades توسط یک agent را بدون safety checkpoints و افشای legal آسان میکند، خود را در معرض regulatory risk قرار میدهد. Friction ضروری است.
Healthcare products با چالشهای مشابهی روبرو خواهند شد. HIPAA محدود میکند که دادههای patient چگونه و توسط چه کسی قابل دسترسی باشد، و این سوال که آیا یک AI agent که از طرف یک patient عمل میکند به عنوان یک authorized accessor واجد شرایط است یا خیر، حل نشده است.
زمانی که از Competitive Intelligence محافظت میکنید
برخی interfaces عمداً برای machines opaque هستند زیرا دادههای پشت آنها competitively sensitive است.
Airlines، هتلها، و شرکتهای اجاره ماشین سالها را صرف مبارزه با screen-scraping bots کردهاند. pricing آنها dynamic، proprietary، و به صورت استراتژیک مدیریت میشود — دسترسی real-time به آن دادهها دقیقاً همان چیزی است که competitors و price-comparison aggregators میخواهند. Agent-friendly کردن interfaces همه آن را خنثی میکند.
زمانی که میخواهید محصول خود Agent باشد
platformهای زیادی هستند که خودشان میخواهند لایه agent باشند. برخی محصولات به طور فعال دسترسی third-party agents را مسدود میکنند — blocking external MCP calls، محدود کردن API surface area — زیرا آنها قابلیتهای AI خود را یک differentiator میبینند.
ریسک رقابتی انتخاب نکردن
هیچ یک از اینها به این معنا نیست که تصمیم به blocking agents بدون ریسک است. سوال دشوارتر این است: چه اتفاقی میافتد وقتی یک رقیب آنها را block نمیکند؟
اگر برای یک بانک کار میکنید، ممکن است انتخاب معقولی برای جلوگیری از execute کردن تراکنشها توسط agents از طرف مشتریان خود به دلایل امنیتی داشته باشید. اما چه اتفاقی میافتد وقتی یک رقیب که محصولات مالی مشابهی ارائه میدهد شروع به تبلیغ کند که آنها از agentic wealth managers پشتیبانی میکنند؟
این یک calculus استراتژیک است، نه یک imperative جهانی. طراحی برای agents همیشه تصمیم درستی نیست، اما خروج کامل نیز ریسک خاص خود را دارد. چه برای agents بهینهسازی کنید و چه نه، همه ما حداقل باید تشخیص دهیم که agents سعی خواهند کرد از محصولات ما استفاده کنند.
۵. بلندمدت: زمانی که لایه Interface واگرا میشود
زمانی که agents بتوانند structured data را query کنند و actions را execute کنند، interface بصری برای آنها irrelevant خواهد شد. همانطور که سازمانهای بیشتری services خود را از در معرض agent-compatible APIs قرار میدهند، مسئله طراحی برای human users و agent users به طور فزایندهای از هم جدا خواهد شد.
علیرغم این، humans هنوز به interfaces نیاز خواهند داشت — visual، interactive طراحی شده برای مقایسه و تصمیمگیری.
Agents مستقیماً با دادهها و logic underlying تعامل خواهند کرد. تجربهای که یک human خواهد داشت به توانایی agent او برای تکمیل یک task بستگی دارد.
نتیجهگیری
کلمه “User” همیشه یک shorthand یا کوتاهنویسی مفهومی بود. این موجودی را توصیف میکرد که سعی دارد از طریق چیزی که ما طراحی کردیم به یک goal برسد. برای دههها، آن موجود منحصراً human بود، که دیگر اینطور نیست.
تشخیص agents به عنوان users نیازمند گسترش فرضی است که از زمان شروع این رشته در کار ما implicit بوده است. آنچه با این تغییر تغییر میکند، دامنه کسانی است که برای آنها طراحی میکنیم، و urgency اقداماتی که قبلاً میدانیم مهم هستند: semantic structure، accessibility، clear labeling، و predictable interaction patterns.
مقاله اصلی: nngroup.com/articles/ai-agents-as-users