Back home

سازگاری وب برای Agents از یک ویژگی الحاقی به یک نیاز پیش فرض در حال حرکت است

سایت‌های عمومی باید توسط انسان‌ها، خزنده‌ها و عوامل قابل خواندن، تأیید و ردیابی باشند.

یک قطعه معمولی از محتوا در مرورگر ظاهر می شود، اما اغلب وقتی به برنامه عامل منتقل می شود، نمی توان آن را به طور کامل خواند. فقط به این دلیل که صفحه را می توان باز کرد، به این معنی نیست که صفحه واقعاً قابل مصرف است. فقط به این دلیل که توسط مردم قابل مشاهده است، به این معنی نیست که می توان آن را به طور پایدار توسط ماشین ها خواند، تأیید و ردیابی کرد.

این موضوع قبلاً به عنوان یک موضوع جانبی مانند “نقشه سایت را پر کنید” یا “افزودن برخی داده های ساختاریافته به صفحه مقاله” در نظر گرفته می شد. دیگر گوشه ای نیست. هنگامی که یک سایت عمومی با خزنده‌های هوش مصنوعی، بازیابی خودکار و جریان‌های کاری مبتنی بر عامل مواجه می‌شود، اشیاء سازگار دیگر فقط مرورگرها و موتورهای جستجو نیستند، بلکه نوعی کلاینت هستند که می‌توانند صفحات را بر اساس معنایی تقسیم کنند، بر اساس پیوندها پرش کنند و بر اساس وضعیت اجرا را ادامه دهند. اگر صفحه ای فقط برای خوانندگان انسان دوستانه باشد اما برای چنین مشتریانی مملو از تله باشد، مانند یک وب سایت با سازگاری ناقص به نظر می رسد.

فقط به این دلیل که صفحه قابل باز شدن است به این معنی نیست که صفحه قابل خواندن است.

اولین مشکل معمولا کیفیت محتوا نیست، بلکه نحوه خروجی محتواست.

اگر یک صفحه متن بدنه را در رندر سمت کلاینت جاسازی کند، فیلدهای کلیدی را در پانل های آکاردئونی پنهان کند، صفحه بندی را به یک جریان پیمایشی بدون URL های صریح تبدیل کند، و جداول را به تصویر تبدیل کند، برنامه عامل فقط می تواند بر حدس و گمان تکیه کند. برای انسان ها، یک حدس اشتباه ممکن است به این معنی باشد که یک پاراگراف از قلم افتاده است. برای یک ماشین، یک حدس نادرست ممکن است باعث شود اقدامات بعدی به بیراهه بروند، و چند مرحله دیگر در آینده فقط در امتداد درک اشتباه ادامه خواهند داشت.

این نوع مشکل به ویژه در سایت های سند و سایت های محتوا مشهود است. خوانندگان انسانی لایه بصری را دنبال می کنند و خود زمینه را تکمیل می کنند. عوامل نمی کنند. چیزی که نماینده می بیند DOM، سلسله مراتب هدر، روابط پیوند، کنترل های فرم، کدهای وضعیت و متن قابل خزیدن است. اگر ارتباط متن اصلی با این سیگنال‌های اصلی قطع شود، صفحه در حالت ناخوشایندی ظاهر می‌شود: به نظر مدرن است اما در واقع ناپایدار است.

هنگام مهاجرت برنامه های تک صفحه ای در گذشته، این لایه اغلب اولین لایه ای بود که در معرض دید قرار می گرفت. صفحه اول ظاهر می شود و تعامل امکان پذیر است، اما دستگاه پوسته را می گیرد و متن واقعی تا زمانی که اسکریپت تمام نشده ظاهر نمی شود. همراه با بارگذاری تنبل، پیمایش بی‌نهایت، و طرح‌های مختلف «بسط و مشاهده»، صفحه محتوا به مجموعه‌ای از رویدادهای تصادفی تبدیل می‌شود. برای کاربران مرورگر، این فقط یک کاهش جزئی است. برای نمایندگان، این زنجیره ای از ورودی های غیرقابل اعتماد است.

چیزی که ماشین می خواهد ورودی پایدار است، نه محتوای بصری.

“آماده کردن” سایت در اصل به جای افزودن یک ترفند جدید، یک لایه سازگاری را اضافه می کند.

باارزش‌ترین جنبه این لایه سازگاری این نیست که صفحه را «به نظر می‌رسد که برای ماشین‌ها است»، بلکه به وضوح بیان کردن ابتدایی‌ترین حقایق است: این چه صفحه‌ای است، متن کجاست، وضعیت فعلی چگونه است، آیا می‌تواند به پرش ادامه دهد یا خیر، و چه چیزی باید در صورت خرابی بازگردانده شود. تا زمانی که این حقایق ناپایدار هستند، عوامل به طور مکرر مرزها را آزمایش می کنند.

باارزش ترین چیزهایی که باید ابتدا در سایت های محتوا با آنها برخورد کرد، معمولاً موارد زیر است:

  • متن باید مستقیماً از طریق HTML بدون تکیه بر اسکریپت ها برای حدس زدن آن قابل دسترسی باشد
  • سلسله مراتب عنوان باید پایدار باشد و اجازه ندهید سبک بصری جایگزین ساختار معنایی شود.
  • صفحه بندی، فیلتر کردن، و نتایج جستجو باید URL های قابل اشتراک گذاری داشته باشند، نه اینکه فقط در حالت front-end موجود باشند.
  • تصاویر، جداول و بلوک های کد باید متن جایگزین یا متن اصلی قابل خواندن داشته باشند
  • صادرات اولیه canonical، sitemap و feed باید تمیز باشد و با یکسری پارامترهای موقت مخلوط نشود.

اینها ممکن است کلیشه به نظر برسند، اما معنای آنها اکنون تغییر کرده است. در گذشته، اینها به خاطر موتورهای جستجو و قابلیت دسترسی اضافه می شدند. اکنون، اینها اضافه می شوند تا به عامل اجازه دهند تا محتوا را به طور پایدار پیدا کند، رابطه بین صفحات را تعیین کند و بدون درخواست دستی به مرحله بعدی ادامه دهد. همه آنها به یک چیز اشاره می کنند: صفحه باید به عنوان یک ورودی قطعی توسط مشتری دیگر در نظر گرفته شود، نه یک نتیجه بصری یک بار.

به همین دلیل است که “افزودن دکمه هوش مصنوعی” واقعا کمکی نمی کند. خود دکمه صفحه را قابل مصرف تر نمی کند. در بهترین حالت، فقط یک عمل را در یک ورودی جدید قرار می دهد. اگر لایه پایین همچنان به چیدمان بصری و حالت موقت برای حفظ درک متکی باشد، برنامه عامل همچنان هنگام تازه کردن، پرش، برگشتن به عقب و تغییر مجوز، کنترل خود را از دست خواهد داد.

تعامل باید عمل را کامل کند، نه اینکه فقط در اعلان متوقف شود

اگر صفحه فقط برای نمایش محتوا باشد، مشکلات مربوط به سازگاری نسبتاً آسان است. وقتی نوبت به سطح تعامل و عملیات می رسد، مشکل حتی دشوارتر می شود.

چیزی که یک عامل واقعاً به آن نیاز دارد “تقریبا کافی” نیست، بلکه مرزهای عمل روشن است. ارسال، تأیید، لغو، دانلود، اشتراک، پرش و صادر کردن، این اقدامات ترجیحاً باید دارای پیش‌شرط‌های واضح، بازگشت‌های شکست و نتایج قابل ردیابی باشند. تا زمانی که کنش‌ها با دسته‌ای از پنجره‌های بازشو، درخواست‌ها و تأییدهای ثانویه ترکیب شوند، دستگاه بارها و بارها در همان مکان گیر می‌کند.

اینجاست که تفاوت بین سایت های عمومی و سیستم های داخلی شروع به بزرگ شدن می کند. سایت های عمومی با قابلیت مصرف مواجه هستند، در حالی که سیستم های داخلی با مجوزها و کنترل ریسک مواجه هستند. اولی برای تثبیت ساختار اطلاعات و معناشناسی عمل مناسب تر است، به طوری که مشتریان خارجی بتوانند از انحرافات اجتناب کنند. دومی نباید مرزها را کاهش دهد تا “سازگار با نمایندگان” باشد، به ویژه در مواردی که بودجه، انتشار، حذف و تغییرات مجوز درگیر است. ما همچنان باید محافظه کار باشیم در جایی که باید محافظه کار باشیم.

بنابراین این در مورد تبدیل همه صفحات وب به رابط ماشین نیست. یک رویکرد واقع بینانه تر این است که صفحاتی را که در اصل برای مصرف خارجی در نظر گرفته شده اند به ورودی های ثابت، قابل تایید و قابل پخش تبدیل کنیم. صفحات مقاله، صفحات اسناد، پایگاه‌های دانش، مراکز کمک، APIهای باز و نتایج جستجوی عمومی اولین کسانی هستند که تحت تأثیر قرار می‌گیرند و اولین مزایایی را می‌بینند.

این سطح از سازگاری دارای مرزهای روشن است

Agent-ready یک هدف برای همه نیست.

پشتیبان یک اینترانت کامل، سیستم تجاری با کنترل مجوز قوی، صفحه فعالیت چرخه کوتاه مدت و ایستگاه محتوا برای مصرف عمومی در یک سطح نیستند. اولی بیشتر به کنترل اهمیت می دهد، در حالی که دومی بیشتر به خوانایی، نمایه سازی و ردیابی اهمیت می دهد. تحمیل این دو نوع سیستم به مجموعه استانداردهای یکسانی که «ماشین ها را قابل استفاده می کند» در نهایت هزینه های مدیریتی را افزایش می دهد.

اما ادامه تظاهر به اینکه هیچ چیز در سایت عمومی تغییر نکرده است دشوار است. خزنده های هوش مصنوعی به طور فزاینده ای صفحات را مستقیماً می خوانند و گردش کار نماینده به طور فزاینده ای بر محتوای ساختار یافته و اقدامات پایدار متکی خواهد بود. اگر سایتی همچنان به این ایده پایبند باشد که «کافی است مردم آن را ببینند»، دیر یا زود شکاف هایی در توزیع محتوا، بازیابی، بایگانی و یکپارچه سازی خودکار ایجاد می شود.

بنابراین این تغییر بیشتر شبیه ارتقای سازگاری است. در گذشته، front-end مجبور بود مرورگرهای مختلف، صفحه نمایش های مختلف و شبکه های مختلف را در نظر بگیرد. اکنون باید یک نوع کلاینت را نیز در نظر بگیرد که بتواند صفحات را به خودی خود تقسیم کند، پیوندها را دنبال کند و به تنهایی وضعیت را تأیید کند. با اضافه شدن این لایه سازگاری، سایت می تواند واقعاً یک نیاز پیش فرض جدید را وارد کند: نه تنها باید قابل مشاهده باشد، بلکه باید به طور پایدار مصرف شود.

FAQ

What to read next

Related

Continue reading

Frontend · 3 tags

تحویل فرانت‌اند در عصر انتشار با فرکانس بالا نیاز به طراحی مجدد در حافظه پنهان و همکاری فشرده‌سازی دارد.

همانطور که منابع بیشتر و بیشتر تکه تکه می شوند و نسخه ها بیشتر و بیشتر می شوند، اغلب سرعت فشرده سازی نیست که واقعاً ابتدا از کنترل خارج می شود، بلکه ریتم انتشار کلیدهای حافظه پنهان، نسخه های فرهنگ لغت و هزینه های بازگشت به مبدا است.