اگر توسعهدهندهای هستید که ابزارهای خود را برای رباتها بهینه میکنید، باید بدانید که هیچ میانبری برای دور زدن رتبهبندیهای رایج وجود ندارد. یک عامل هوش مصنوعی هنگام جستوجوی ابزار در Apify، دقیقاً همان رتبهای را میبیند که یک کاربر انسانی در فروشگاه مشاهده میکند. این یافته که در یک تحلیل فنی منتشر شده در ۶ اوت ۲۰۲۶ به تفصیل شرح داده شد، این امید را که توسعهدهندگان جدید میتوانند با بهینهسازی اختصاصی برای فراخوانهای رباتیک، یک «در پشتی» برای دیده شدن پیدا کنند، کاملاً از بین میبرد.
برای توسعهدهندگانی که «اکتورها» (Actors) — ابزارهای میزبانیشده — میسازند، وعده این بود که هر ابزاری با توصیفات دقیق، توسط هر رباتی که بودجهای در اختیار داشته باشد، پیدا خواهد شد. Apify سال گذشته تلاش کرد تا عبارت «اکتور شما به عنوان ابزاری برای عاملهای هوش مصنوعی» را به واقعیت تبدیل کند. این کار از طریق راهاندازی یک سرور میزبانیشده برای پروتکل زمینهٔ مدل (Model Context Protocol یا MCP)، سیستم پرداخت به ازای هر رویداد (per-event billing) و ایجاد ریلهای پرداخت کریپتویی (مانند پروتکل x402 که در ژوئن ۲۰۲۶ مستقر شد) صورت گرفت. این زیرساخت اجازه میدهد پرداختهای USDC بدون نیاز به داشتن حساب کاربری Apify در سمت فراخوانکننده انجام شود. این مدل تبادلات مالی، بخشی از روند گستردهتری است که در بازارهای عاملهای هوش مصنوعی و آغاز عصر تجارت خودکار ماشینها مشاهده میشود. اما واقعیت مانند یک آینه است: اگر ابزار شما برای انسانها در صفحه پنجم دفن شده است، برای عاملها نیز دقیقاً در همان جایگاه دفن شده است. این بدان معناست که چشمانداز رقابتی برای کشف ابزارهای هوش مصنوعی، دقیقاً مشابه سئو (SEO) در اپاستورهای سنتی است.
خط لوله کشف ابزار
برای درک نحوه یافتن ابزار توسط یک عامل، باید به سرور MCP نگاه کرد. یک عامل (یا محیط اجرای آن، مانند Claude Desktop یا یک حلقه SDK) از طریق Streamable HTTP به آدرس https://mcp.apify.com متصل میشود. احراز هویت در این مسیر از طریق OAuth یا یک هدر توکن API ساده مدیریت میشود.
یک پیکربندی حداقلی برای کلاینت به این شکل است:{ "mcpServers": { "apify": { "url": "https://mcp.apify.com", "headers": { "Authorization": "Bearer <APIFY_TOKEN>" } } } }
پس از برقراری اتصال، عامل معمولاً یک جریان سهمرحلهای را با استفاده از سه ابزار اصلی طی میکند:
search-actors: انجام یک جستوجوی کلیدواژهای در کل فروشگاه.fetch-actor-details: بازیابی کارت کامل یک اکتور، شامل توصیفات، قیمتگذاری، آمار، طرح ورودی (input schema) و فایل README.call-actor: اجرای یک اکتور بر اساس نام آن با یک ورودی JSON، که در زمان اجرا با توجه به طرح ورودی اعتبارسنجی میشود.
به عنوان یک جایگزین، یک اکتور خاص میتواند به عنوان یک ابزار نامگذاریشده نصب شود. این کار با افزودن ?tools=username/name به URL سرور انجام میشود و به سرور MCP اجازه میدهد تا بر اساس طرح ورودی اکتور، یک ابزار اختصاصی تولید کند.
چه ابزارهایی در معرض دید هستند؟
طبق مستندات فنی، هر ابزاری برای عاملها در دسترس نیست. سرور فیلترهای خاصی را برای تضمین ایمنی و سازگاری اعمال میکند. برای اینکه یک اکتور برای فراخوانهای عاملمحور قابل مشاهده باشد، باید معیارهای زیر را داشته باشد:
- استفاده از قیمتگذاری رایگان یا پرداخت به ازای هر رویداد (PPE)؛ اکتورهایی که مدل اجارهای (rental-model) دارند، حذف میشوند.
- گذراندن بررسیهای امنیتی پلتفرم.
- اجرا با دسترسیهای محدود.
- نبودن در حالت Standby.
هیچ فرآیند ثبتنام یا Opt-in خاصی وجود ندارد؛ هر اکتور PPE که این معیارها را داشته باشد، بهطور خودکار وارد لیست میشود. تا اواخر ژوئیه ۲۰۲۶، کمی بیش از ۲۹,۰۰۰ اکتور در فروشگاه این استانداردها را پاس کردند (بر اساس شمارش از طریق API عمومی فروشگاه با فیلتر agentic-users).
تلههای اندازهگیری و خطاهای فنی
بررسیهای پژوهشگران نشان داد که طراحی ضعیف API میتواند عاملهای هوش مصنوعی را به راحتی به گمراهی بکشاند. برای دریافت خامترین دیدگاه ممکن، پژوهشگر مستقیماً با استفاده از curl و پروتکل JSON-RPC با سرور صحبت کرد. این فرآیند شامل مقداردهی اولیه یک جلسه برای دریافت mcp-session-id از هدرهای پاسخ و سپس فراخوانی ابزار جستوجو بود.
مرحله اول نیازمند یک دستور curl خاص برای مقداردهی اولیه و ثبت شناسه جلسه بود. در اینجا یک جزئیات حیاتی ظاهر شد: استفاده از grep برای عبارت ^mcp-session-id: همراه با علامت لنگر (anchor) ضروری است. بدون آن، اولین تطبیق یافت شده خط access-control-expose-headers است که صرفاً به شناسه اشاره میکند و باعث میشود کاربر به اشتباه لیست هدرهای CORS را به عنوان شناسه جلسه ارسال کند.
در تلاشهای اولیه برای اندازهگیری رتبهها، پژوهشگر به جای آرگومان keywords از آرگومان search در فراخوانی JSON-RPC استفاده کرد. از آنجایی که طرح ورودی ابزار هیچ آرگومانی را اجباری نکرده بود و keywords را با مقدار پیشفرض "" لیست کرده بود، سرور بیصدا این غلط املایی را نادیده گرفت. در نتیجه، سرور صرفنظر از عبارت جستوجو، لیستی کاملاً پذیرفتنی از ۱۰ اکتور محبوب (مانند استخراجکنندههای Google Maps و TikTok) را برگرداند.
این موضوع توهمی ایجاد کرد که اکتورهای جدید برای عاملها کاملاً نامرئی هستند. نشانه این خطا این بود که لیست نتایج برای هر کوئری، از نظر بایتی دقیقاً یکسان بود. اما وقتی آرگومان درست (keywords) استفاده شد، نتایج فوراً به یک رتبهبندی واقعی مبتنی بر کلیدواژه تغییر کرد و یک اکتور جدید برای کوئریهای خاص در رتبه ۴ قرار گرفت.
چالش تحلیل مارکداون در برابر نثر
یک تله فنی دیگر مربوط به فرمت خروجی بود. ابزار search-actors نتایج را به صورت مارکداون (Markdown) برمیگرداند، نه JSON. این خروجی شامل یک عنوان، یک گلوله (bullet) با کوئری و سپس یک بخش برای هر اکتور است. یک تحلیلگر Regex ساده که هر الگوی owner/name را از متن بیرون میکشد، میتواند توسط قطعات README یا متن توصیفات فریب بخورد (مثلاً عباراتی مانند "JSON/CSV"، "pros/cons"، "surface/rooms" یا "10/10").
این نویزها باعث جابجایی رتبهها میشود. در یک تست، یک تحلیلگر ساده اکتوری را که رتبه ۷ واقعی داشت، در رتبه ۸ قرار داد و اکتور دیگری را کاملاً از ۱۰ رتبه اول حذف کرد. تنها لنگر قابل اعتماد، URL رسمی است: re.findall(r'https://apify\.com/([a-zA-Z0-9_.-]+/[a-z0-9-]+)', txt). سپس یک حذف تکرار (deduplication) با حفظ ترتیب لازم است، زیرا هر بلوک لیست، URL را تا سه بار تکرار میکند (لینک عنوان، فیلد URL و لینک قیمتگذاری).
علاوه بر این، کانال MCP برخلاف API عمومی GET /v2/store تعداد کل نتایج را ارائه نمیدهد. فیلد "Number of Actors found" در واقع شمارش همان صفحه است، نه تعداد کل. این یعنی عاملها نمیتوانند تشخیص دهند که یک حوزه (niche) خاص چقدر شلوغ است.
آینهای از فروشگاه انسانی
مقایسه دیدگاه عامل با API عمومی Apify Store در ۶ اوت (نسخه سرور 0.14.2) تطابق یکبهیک را نشان داد. برای کوئریهایی که تا عمق ۵۰ بررسی شدند، جایگاهها کاملاً یکسان بود:
- Avito real estate: رتبه ۲ (عامل) / رتبه ۲ (فروشگاه)
- Lazada reviews: رتبه ۴ (عامل) / رتبه ۴ (فروشگاه)
- Wildberries reviews: رتبه ۷ (عامل) / رتبه ۷ (فروشگاه)
- Wildberries: رتبه ۲۰ (عامل) / رتبه ۲۰ (فروشگاه)
این همگرایی توسط کد منبع سرور MCP نیز تأیید شده است. فایل search_actors.ts صرفاً همان API جستوجوی عمومی فروشگاه را فراخوانی میکند که وبسایت از آن استفاده میکند. لایه MCP فقط فرمت را به مارکداون تبدیل میکند اما منطق رتبهبندی را تغییر نمیدهد. مستندات Apify تأیید میکند که رتبهبندی جستوجو پارامترهایی مشابه با «امتیاز کیفیت اکتور» (Actor quality score) را ارزیابی میکند و این دو در هر دو کانال همبستگی شدیدی دارند.
یک واگرایی کوتاه در ۳۰ ژوئیه رخ داد. در آن زمان، تأیید حساب کاربری پژوهشگر در جریان بود. فروشگاه وب اکتورهای جدید را حذف کرده بود، اما کانال عامل آنها را در رتبههای ۲ و ۴ لیست کرده بود. به محض تکمیل تأیید حساب، نتایج وب نیز بهروز شدند. این یک ناهنجاری موقت بود و رتبهبندی زیربنایی در تمام مدت یکسان بود.
کارت ابزار به عنوان ابزار فروش
وقتی عاملی ابزاری را پیدا میکند، کارت آن را از طریق fetch-actor-details میخواند. این کارت شامل عنوان، قیمت و بهطور حیاتی، تعداد کاربران است.
اگر ابزاری دارای «۳ کاربر کل و ۲ کاربر ماهانه» باشد، عامل این اثبات اجتماعی (Social Proof) را در پنجره متنی (Context Window) خود میبیند. عاملها ابزارها را صرفاً بر اساس طرحهای فنی قضاوت نمیکنند، بلکه تحت تأثیر همان سیگنالهای محبوبیت هستند که انسانها میباشند. این رفتار در تحلیلهای مربوط به سازوکار یک عامل محلی برای تحلیل فرصتهای مالی در وب نیز مشهود است، جایی که عاملها برای تصمیمگیری از دادههای محیطی استفاده میکنند.
علاوه بر این، توصیفات قیمتگذاری که در کنسول مانیتایزیشن نوشته شدهاند، عیناً رندر میشوند. برای مثال، یک اکتور Wildberries ممکن است رویداد "Product scraped" را با قیمت ۰.۰۰۳۵ دلار و رویداد "Review scraped" را با قیمت ۰.۰۰۲ دلار لیست کند. اگر توسعهدهنده به جای متن واضح، از شناسههای داخلی استفاده کند، عامل توضیحات گیجکنندهای دریافت میکند.
توسعهدهندگان همچنین باید مراقب جمعبستن مکانیکی (mechanical pluralization) باشند. خط قیمت در فروشگاه، عنوان رویداد را بهطور خودکار جمع میبندد. عنوانی مانند "product scraped" ممکن است به صورت "from $3.50 / 1,000 product scrapeds" رندر شود. استفاده از اسمهای ساده مانند "Product" یا "Review" از این عبارتهای ناهنجار جلوگیری میکند.
اجرای فنی و مدیریت بودجه
گام نهایی، یعنی call-actor به عامل اجازه میدهد ابزارها را با یک سقف بودجه سختگیرانه از طریق maxTotalChargeUsd اجرا کند.
در یک اجرای آزمایشی برای استخراجکننده نظرات Lazada، عامل سقف ۵ سنتی تعیین کرد. ورودی با طرح ورودی اکتور اعتبارسنجی شد و اجرا با محدودیت waitSecs برابر با ۴۵ ثانیه انجام شد. اگر یک اجرا از این بازه زمانی فراتر رود، باید بهطور غیرهمزمان از طریق get-actor-run جمعآوری شود.
سیستم صورتحساب را به تفکیک ارائه کرد: یک رویداد شروع (۰.۰۱ دلار)، یک محصول (۰.۰۰۲ دلار) و سه نظر (۳ × ۰.۰۰۶ دلار) که در مجموع ۳ سنت شد. پاسخ همچنین فیلدهای تایپشده مجموعه داده (dataset) را برشمرد و یک nextStep ارائه داد که فراخوانکننده را برای استفاده از get-dataset-items با یک datasetId خاص راهنمایی میکرد.
با این حال، پلتفرم بهطور خودکار اجرا را هنگام رسیدن به سقف بودجه متوقف نمیکند. کد اکتور باید بهصورت دستی پرچم eventChargeLimitReached را از Actor.charge() بررسی کند و خودش را خاموش کند. اگر کد این مقدار بازگشتی را نادیده بگیرد، اکتور به استخراج رایگان در یک فضای تهی ادامه میدهد. یک پیادهسازی صحیح به این شکل است:
const res = await Actor.charge({ eventName: 'review-scraped', count: batch.length }); if (res.eventChargeLimitReached) { log.info('Charge limit reached — stopping gracefully'); break; }
استراتژیهای کلیدی برای توسعهدهندگان
از آنجایی که بازی جداگانهای به نام «سئو برای عاملها» وجود ندارد، توسعهدهندگان باید بر این ۶ بهینهسازی عملی تمرکز کنند:
۱. تطبیق کلیدواژهها: بر عناوین و نامها تمرکز کنید. عبارات دقیق در عنوان اغلب رتبههای بالاتری نسبت به اکتورهای محبوبتر با نامهای کلی میگیرند. برای مثال، اکتوری با ۱۵ کاربر میتواند از اکتوری با ۶۰۸ کاربر پیشی بگیرد اگر عبارت دقیق در عنوان باشد. جستوجو روی عنوان، نام، توصیفات، نام کاربری و README انجام میشود.
۲. توصیفات طرح (Schema): توصیفات طرح ورودی را به عنوان آرگومانهای راهنما در نظر بگیرید. سرور MCP توصیفات ویژگیها را در ۵۰۰ کاراکتر و لیستهای enum را در ۲۰۰۰ کاراکتر قطع میکند. از این فضا برای توضیح دلیل انتخاب یک مقدار پیشفرض استفاده کنید. در اکتور Lazada، فیلد مرتبسازی توضیح میدهد که مرتبسازی بر اساس "relevance" میتواند نتایج را منحرف کند و نظرات ۱-۲ ستاره را به انتها ببرد، که این به عامل اجازه میدهد پارامترها را درست انتخاب کند.
۳. متادیتای مجموعه داده: تمام فیلدها در طرح مجموعه داده (نوع، عنوان، توصیف و مثال) را پر کنید. عاملها برای درک خروجی به این متادیتا تکیه میکنند؛ بدون آن، آنها مجبورند معنا را فقط از روی نامها استنباط کنند. اگر یک اکتور انواع مختلفی از ردیفها را ترکیب میکند، از یک تمایز صریح مانند "type": "product" | "review" استفاده کنید.
۴. مثالهای واقعگرایانه: مثال ورودی پیشفرض {"helloWorld": 123} را با یک کوئری واقعی (مثلاً یک URL واقعی محصول) جایگزین کنید تا از شکست در اولین اجراها جلوگیری شود.
۵. وضعیت آماده برای ماشین: اطمینان حاصل کنید که اکتور دارای قیمتگذاری PPE است، دسترسیهای محدودی دارد و در حالت Standby نیست تا در استخر عاملها باقی بماند. این وضعیت همچنین ریلهای پرداخت عاملمحور مانند پروتکل x402 برای پرداختهای USDC را فعال میکند. در واقع، ایجاد چنین مسیرهایی برای تسهیل تراکنشها، مشابه استراتژیهایی است که در سازوکار جذب عاملهای هوش مصنوعی به درگاههای پرداخت بررسی شده است.
۶. احترام به بودجه: خاموش شدن آرام (graceful shutdown) هنگام رسیدن به حد هزینه پیادهسازی کنید. علاوه بر این، با defaultRunOptions.memoryMbytes به عنوان یک ردیف قیمتگذاری برخورد کنید. چون رویداد "Actor Start" به ازای هر گیگابایت حافظه یک رویداد صورتحساب میکند، افزایش حافظه پیشفرض از ۱ گیگابایت به ۴ گیگابایت، هزینه شروع را بدون تغییر در فیلدهای قیمت، بهطور بیصدا چهار برابر میکند.
این تغییر به این معناست که مشکل «شروع سرد» (cold start) برای ابزارهای هوش مصنوعی واقعی و پایدار است. تنها راه برای جلب توجه عامل، جلب توجه انسان در درجه اول است.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو