بازاریابی عاملیتی در ۲۰۲۶: چهار چیزی که یک سیستم باید ارائه دهد

پاسخ کوتاه: بازاریابی عاملیتی کاری بازاریابی است که توسط نرم‌افزاری انجام می‌شود که گام بعدی خود را انتخاب می‌کند و سپس آن را برمی‌دارد. تقریباً توافق تا همین‌جا ادامه دارد. ما یازده صفحه‌ای را که در ۱۸ اوت ۲۰۲۶ برای این اصطلاح و گونه‌های آن بازگشت داده شد واکشی کردیم، و هشت‌تای آن‌ها هرگز به پروتکل، فراخوانی ابزار یا فراخوانی تابع اشاره نمی‌کنند — همان لایه‌ای که در آن یک عامل از یک پنجره چت فراتر می‌رود و به چیزی تبدیل می‌شود که می‌تواند جامعه، کمپین یا سوابق مشتری شما را تغییر دهد. بنابراین این نوشته بازاریابی عاملیتی را با چهار چیزی تعریف می‌کند که یک سیستم باید ارائه دهد تا یک عامل بتواند اصلاً هر کار بازاریابی را انجام دهد، از پروتکل Model Context Protocol درباره اینکه چرا برچسب‌هایی که این سیستم‌ها درباره خودشان منتشر می‌کنند غیرقابل‌اعتمادند نقل می‌کند، و سطح عامل خود Zealy را در برابر این تعریف می‌سنجد، از جمله بخشی که در آن رد می‌شویم.

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

آخرین بازبینی: ۱۸ اوت ۲۰۲۶.

بازاریابی عاملیتی چیست؟

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

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

1. ابزارهای نام‌دار، نه یک کادر متنی. یک عامل به عملیاتی با نام‌ها، آرگومان‌ها و شکل‌های بازگشتی نیاز دارد، چیزهایی مانند create_campaign, list_members و send_message، زیرا مدلی که فقط می‌تواند متن تولید کند، فقط می‌تواند متن تولید کند. پروتکل زمینه مدل (Model Context Protocol) روش رایج کنونی برای انتشار چنین فهرستی است و ابزارهای آن همان چیزی است که آن را مدل‌کنترل‌شده می‌نامد: مدل زبانی خودش آن‌ها را بر اساس زمینه و درخواست کاربر کشف و فراخوانی می‌کند. بدون این لایه، شما یک دستیار نوشتن دارید. آن محصول مفیدی است؛ اما این محصول نیست.
2. کشف پیش از اقدام. عامل باید بتواند پیش از هر تعهدی بپرسد چه چیزهایی وجود دارند و هرکدام چه کاری می‌کنند. یکپارچه‌سازی سخت‌کدشده‌ای که در آن انسان از پیش سه فراخوانی را انتخاب کرده، خودکارسازی‌ای است با یک مدل چسبیده به نسخه.
3. مرز تأییدی که کسی به‌عمد انتخاب کرده است. هر اقدام یا برای یک شخص متوقف می‌شود یا نمی‌شود، و جایی قاعده‌ای هست که این را تعیین می‌کند. قاعده می‌تواند سخت‌گیرانه یا سهل‌گیرانه باشد. آنچه نمی‌تواند باشد، بررسی‌نشده است.
4. مرز اعتماد بر آنچه بازمی‌گردد. نتایج ابزار داده‌هایی هستند که افراد دیگر نوشته‌اند: اعضا، مشتریان، فرم‌ها، صفحه‌های استخراج‌شده. اگر یک رشتهٔ بازگشتی بتواند عامل را به فراخوانی ابزار بعدی‌اش وادار کند، سیستمی ساخته‌اید که دستورها را از هر کسی که فیلد ارسال کوئست شما را پر می‌کند می‌گیرد.

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

تعاریف موجود و اینکه هرکدام مرز خودمختاری را کجا می‌کشند

تعاریف منتشرشده توافق دارند که یک عامل به‌طور مستقل برنامه‌ریزی و عمل می‌کند و بر سر میزان دخالت انسانی که مجاز است باقی بماند اختلاف دارند. مدرسه کسب‌وکار ولریک حداقل مداخله را مجاز می‌داند. Braze سیستم‌هایی را توصیف می‌کند که ادراک، تصمیم و عمل می‌کنند. Young Urban Project و Netcore هر دو مرز را در تأیید انسانی در هر مرحله می‌گذارند. Forrester عامل‌ها را کاملاً از هوش مصنوعی عاملی جدا می‌کند.

ستون میانی را پیش از ستون سمت راست بخوانید. اینکه چه کسی این دسته را تعریف می‌کند چیزهای زیادی درباره جایگاه مرز به شما می‌گوید.

هر رشته در ستون سمت راست با متن خام صفحهٔ پیوندشده که در ۱۸ اوت ۲۰۲۶ واکشی شد تطبیق داده شد، نه با خواندن از یک نتیجهٔ جستجو. شش صفحه‌ای که برای این عبارت رتبه دارند اصلاً خوانده نشدند. Salesforce، IBM، Gartner و BCG به هر تلاش 403 برگرداندند و McKinsey و Adobe به پایان مهلت رسیدند. هیچ‌کدام از آن‌ها اینجا نقل نشده است.

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

در برابر اتوماسیون بازاریابی. Treasure Data می‌نویسد که «بازاریابی عاملیت‌محور از بازاریابی هوش مصنوعی محدودتر است و از اتوماسیون بازاریابی متمایز است»، زیرا «اتوماسیون بازاریابی جریان‌های کاری ثابت و تعریف‌شده توسط انسان را اجرا می‌کند». معیار این نیست که نرم‌افزار بدون شما عمل کند. ابزار ایمیل شما همین حالا این کار را می‌کند. معیار این است که آیا توالی مراحل از پیش توسط یک شخص انتخاب شده است.

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

در برابر یک دستیار. تندترین جمله‌ای که هر کسی در این مجموعه نوشته، متعلق به Docket's Arjun Pillai: «یک دستیار منتظر کاربر می‌ماند، در انجام یک کار کمک می‌کند و درون یک گردش‌کار انسانی زندگی می‌کند.» نیمهٔ عامل آن این است: «یک عامل به‌سوی هدفی عمل می‌کند، تصمیم‌های محدود می‌گیرد، گردش‌کارها را راه می‌اندازد و بخشی از اجرا را زیر نظارت بر عهده دارد.» یک بند جداگانه در همان صفحه سازوکاری را که این عبارت فاقد آن است فراهم می‌کند: انسان‌ها «اهداف، قواعد تشدید، محدودیت‌های موضوعی و آستانه‌های تأیید را تعریف می‌کنند. عامل درون این مرزها فعالیت می‌کند. وقتی چیزی بیرون از آن‌ها بیفتد، آن را تشدید می‌کند.» تشدید همان مرز تأیید در تعریف ماست که از سمت عامل توصیف شده است.

یک اختلاف نظر ارزش چاپ دارد و نباید هموار شود. Forrester، در صفحه‌ای دربارهٔ موارد استفادهٔ عامل هوش مصنوعی که نام Craig Le Clair روی آن آمده، دو اصطلاحی را که هر صفحهٔ فروشندهٔ بالا آن‌ها را قابل‌جانشینی می‌داند از هم جدا می‌کند: عامل‌های هوش مصنوعی بر «قواعد از پیش تعریف‌شده» اجرا می‌شوند، در حالی که «هوش مصنوعی عامل‌محور خودمختاری و انطباق‌پذیری گسترده‌تری معرفی می‌کند». هشدار منصفانه دربارهٔ این ارجاع — این یک صفحهٔ فرود پادکست است، نه یادداشت پژوهشی منتشرشده، و ما آن را به‌عنوان چارچوب‌بندی یک شرکت تحلیلی نقل می‌کنیم، نه به‌عنوان یافته.

لایه‌ای که هشت تعریف از یازده تعریف نادیده می‌گیرند

از یازده صفحه‌ای که در 18 اوت 2026 برای این اصطلاح واکشی کردیم، هشت صفحه هرگز به Model Context Protocol، فراخوانی ابزار یا فراخوانی تابع اشاره نکردند. این لایه تفاوت میان مدلی است که برایتان یک خلاصهٔ کمپین می‌نویسد و مدلی که می‌تواند یک کوئست بسازد، عضوی را مسدود کند یا جریان رویداد شما را به جای تازه‌ای هدایت کند.

هشت موردی که هیچ‌یک از این رشته‌ها در آن‌ها ذکر نشده است: braze.com، cdp.com، docket.io، forrester.com، netcore.ai، tofuhq.com، vlerick.com و youngurbanproject.com. از سه مورد باقی‌مانده، hubspot.com به Model Context Protocol اشاره می‌کند اما صفحه‌ای تعریفی نیست. Optimove همان چیزی است که در ذهنمان ماند: رشتهٔ MCP در صفحهٔ آن فقط در منوی ناوبری، با عنوان «The Optimove MCP»، ظاهر می‌شود و هرگز در متن مقاله‌ای که این دسته را توضیح می‌دهد نمی‌آید. فروشنده‌ای که یک سرور MCP عرضه می‌کند، اما توضیح‌دهندهٔ خودش دربارهٔ بازاریابی عاملی هرگز به همان چیزی که عرضه می‌کند نمی‌رسد. این سخنی دربارهٔ یازده صفحه در یک روز است، نه دربارهٔ کل دسته — اما برای هر صفحه‌ای که بررسی کردیم صادق بود.

دو صفحه در این مجموعه لایهٔ گمشده را نام می‌برند و هر دو این کار را خوب انجام می‌دهند.

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

Real Story Group، یک شرکت تحقیقاتی مارتک که ارزیابی فروشندگان را می‌فروشد، جمله‌ای را ارائه می‌دهد که به بحث پایان می‌دهد. در مقاله‌ای درباره MCP مورخ 11 ژوئن 2025، تحلیلگر ارشد اسکات سیمونز آن را «لایه انتزاعی API جهانی ساخته‌شده برای عامل‌های هوش مصنوعی» می‌نامد و به این نتیجه می‌رسد که یک عامل «تنها به اندازه‌ای قدرتمند است که فروشنده انتخاب می‌کند در معرض دید قرار دهد.»

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

چرا فهرست ابزارها مدرک است و برچسب ابزار فقط یک اشاره

پروتکل Model Context به پرسش اینکه یک عامل چه کاری می‌تواند با شما بکند پاسخ می‌دهد، با این دستور که فهرست ابزارهای سرور را بخوانید، و سپس به کلاینت‌ها می‌گوید به آنچه این فهرست درباره خودش می‌گوید اعتماد نکنند. یادداشتی که این را بیان می‌کند در شِما قرار دارد نه در متن، و بخشی از دلیل اینکه افراد کمی آن را خوانده‌اند همین است.

این است قطعه‌ای از ToolAnnotations رابط در طرح‌واره مشخصات در بازبینی 2026-07-28:

توجه: همه ویژگی‌های موجود در ToolAnnotations هستند راهنماها. آن‌ها تضمین نمی‌کنند که توصیف وفادارانه‌ای از رفتار ابزار ارائه دهند (شامل ویژگی‌های توصیفی مانند title).

و در همین موضوع، از صفحه ابزارها:

برای اعتماد، ایمنی و امنیت، کلاینت‌ها باید حاشیه‌نویسی‌های ابزار را نامعتبر بدانند مگر اینکه از سرورهای مورد اعتماد آمده باشند.

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

چهار برچسب از این نوع وجود دارد — readOnlyHint, destructiveHint, idempotentHint و openWorldHint — و دو مورد از آن‌ها، destructiveHint و openWorldHint، به‌طور پیش‌فرض به true. بنابراین یک ابزار بدون برچسب مخرب فرض می‌شود و فرض بر این است که به دنیای بیرون دسترسی دارد، که تصمیم درستی است و برخلاف انتظار بیشتر افراد.

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

این همچنین نسخه صادقانه چیزی است که بازاریابان مدام آن را «عاملیت‌شویی» می‌نامند. Young Urban Project آن را دقیق نام‌گذاری می‌کند: «رایج‌ترین شکست عاملیت‌شویی است؛ برداشتن یک محصول اتوماسیون یا چت‌بات موجود و تغییر برند آن به عاملیت‌محور بدون افزودن لایه برنامه‌ریزی یا تصمیم‌گیری در زیر آن»، و می‌افزاید که «نسخه نمایشی طوری نوشته شده که دقیقاً همان شکافی را که مهم است پنهان کند». فهرست ابزارها بسیار سخت‌تر از یک نسخه نمایشی قابل دستکاری است. همچنین تنها مصنوعی در این کل دسته است که خریدار می‌تواند بدون همکاری فروشنده بررسی کند، و به همین دلیل راهنمای گام‌به‌گام جداگانه‌ای نوشتیم درباره نحوه فهرست‌کردن ابزارهای هر سرور MCP پیش از اتصال به آن.

مرز تأیید کجا قرار می‌گیرد، و چه کسی supposed است آن را آنجا بگذارد

پروتکل Model Context Protocol می‌گوید یک انسان باید همیشه در حلقه باشد و توانایی رد فراخوانی ابزارها را داشته باشد، و این را به برنامه کلاینت می‌گوید، به‌صورت SHOULD نه MUST. هیچ‌چیز در پروتکل، سروری را که به آن متصل می‌شوید ملزم نمی‌کند. اینکه مرز تأیید شما کجا باشد، انتخابی است که کسی انجام داده، و اغلب نه شما.

جمله دقیق:

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

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

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

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

اکنون پاسخی سنجیده نیز برای این پرسش وجود دارد که کدام فراخوان‌ها شایسته دروازه‌اند، و آن پاسخ همانی نیست که شهود به شما می‌گوید. SABER: کنش‌های کوچک، خطاهای بزرگ — محافظت از گام‌های تغییردهنده در عامل‌های LLM, توسط Alejandro Cuadron، Pengfei Yu، Yang Liu و Arpit Gupta و ارسال‌شده در 26 نوامبر 2025، بررسی می‌کند که کجا مسیر اشتباه یک عامل ابزارمحور واقعاً برای شما هزینه دارد. این گزارش می‌گوید: «در مقابل، انحرافات در کنش‌های غیرتغییردهنده تأثیر بسیار کمی دارند یا هیچ تأثیری ندارند.» جملهٔ بلافاصله پیش از آن، روی دیگر ماجرا را نشان می‌دهد: هر انحراف اضافی در یک تغییردهنده کنش، شانس موفقیت را تا 92% در یکی از دو دامنهٔ آن و تا 96% در دامنهٔ دیگر، برای مدل‌های پیشرفته، کاهش می‌دهد. شکست در فراخوانی‌هایی متمرکز است که وضعیت را تغییر می‌دهند.

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

همان الگوی «به پیادهساز واگذار شده» یک لایه پایینتر، در بخش چهارم تعریف ما، جریان دارد. ما در ۱۸ اوت ۲۰۲۶ هفت صفحه مشخصات و امنیت را دانلود و جستوجو کردیم: مدل تهدید مشخصات، مدل تهدید مجوزدهی و انتقال است و نماینده گیجشده، عبور توکن، جعل درخواست سمت سرور و سرور محلی بهخطرافتاده را در میان چند مورد دیگر پوشش میدهد، در حالی که حمله لایه مدل به پیادهسازان واگذار شده است. در صفحاتی که دانلود کردیم، عبارت «prompt injection» ظاهر نمیشود؛ چهار تطابق «injection» در سند بهترین شیوههای امنیتی، اسکریپتنویسی بینسایتی، تزریق فرمان پوسته و اجرای کد از راه دور هستند. این شکایتی از یک مشخصات انتقال نیست، که حق دارد دامنه خود را تعیین کند. این بیانیهای است درباره اینکه بهمحض اتصال چیزی، کدام نیمه مسئله را به ارث میبرید و درباره اینکه چرا مرز اعتماد روی دادههای بازگشتی باید کار صریح کسی باشد نه ویژگی فرضشده پروتکل.

Zealy در تعریف خودش شکست میخورد و اینجاست که

بر اساس سختگیرانهترین تعاریف این پست — «بدون اینکه یک انسان هر مرحله را تأیید کند» از Young Urban Project و «بدون نیاز به تأیید انسانی در هر مرحله» از Netcore — Zealy بازاریابی عاملمحور انجام نمیدهد. هر نوشتن از طریق سطح عامل Zealy برای یک نفر متوقف میشود و نوشتنها تا زمانی که یک اپراتور آنها را روشن نکند خاموش هستند.

ترجیح میدهیم این را بگوییم تا بعداً بحث را ببازیم. این کارنامه کامل در برابر چهار بخش تعریف خودمان است، دستاول و حسابرسینشده.

هر چهار مورد موجود است، که بخش آسان ماجراست. مورد سوم برای این برچسب برعکس تنظیم شده است. سرور Zealy دروازه تأیید را در سمت سرور قرار می‌دهد، که بیش از آن چیزی است که پروتکل از یک سرور می‌خواهد و بیش از آنچه تعریف سخت‌گیرانه بازاریابی عاملی مجاز می‌داند. سطح ابزار خود به‌اندازه‌ای بزرگ است که ارزش حسابرسی داشته باشد — ۷۲ ابزار نام‌دار در زمانی که آن‌ها را شمردیم — اما عدد مهم نیست. تنظیمات مهم است.

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

پس برچسب را بردارید. آنچه Zealy واقعاً ارائه میدهد یک سطح قابلخواندن برای عامل است با یک مرحله تأیید انسانی، که نامی خستهکننده برای چیزی است که بیشتر تیمها باید اول بخواهند. اگر مکانیک اتصال آن را میخواهید، مستندات یکپارچهسازی MCP مرجع اصلی است و این پست عمداً آنها را تکرار نمیکند؛ اگر سطح قدیمیتر و گستردهتر زیر آن را میخواهید، مستندات API آن را پوشش میدهند. و اگر هرگز از محصول استفاده نکردهاید، Zealy چیست آیا مسیر کوتاه‌تر در آن است؟

چه چیزی را پیش از خرید چیزی به نام بازاریابی عاملیتی بپرسید

فهرست ابزارها را بخواهید. فروشنده‌ای که بازاریابی عاملیتی می‌فروشد یا می‌تواند عملیات نام‌دار و مجوزهای پیوست‌شده‌ای را که یک عامل دریافت می‌کند نشان دهد، یا نمی‌تواند. هر چیز دیگری، زبان برنامه‌ریزی و زبان هدف‌جویی و دمو، با یک چت‌بات متصل به یک فرم سازگار است و Young Urban Project نامی برای آن دارد.

پنج پرسش، به ترتیبی که با کمترین زمان جلسه بیشترین اطلاعات را به شما می‌دهد:

1. «عامل با نام کدام عملیات را دریافت می‌کند؟» اگر پاسخ یک جمله درباره توانایی باشد نه یک فهرست، پاسخ خود را گرفته‌اید. اگر فهرست است، آن را برای یافتن فعل‌ها بخوانید. خواندن، نوشتن، حذف، ارسال، انتشار، پرداخت.
2. «کدام‌یک از آن‌ها می‌تواند بدون من عمل کند؟» نه «آیا انسان در چرخه هست»: آن پرسش از همه پاسخ بله می‌گیرد. بپرسید کدام فراخوانی‌های مشخص از شخص عبور می‌کنند و چه کسی آن تقسیم را انتخاب کرده است.
3. «وقتی عامل متنی را که مشتری نوشته است می‌خواند، چه اتفاقی برای آن متن می‌افتد؟» شما می‌پرسید که آیا نتایج ابزارها به‌عنوان داده در نظر گرفته می‌شوند یا به‌عنوان دستورالعمل‌های احتمالی. فروشنده‌ای که به این موضوع فکر کرده باشد فوراً پاسخ می‌دهد، چون این همان حالت شکستی است که مهندسانش را بیدار نگه می‌دارد.
4. «برچسب‌های ریسک شما چه معنایی دارند؟» سپس پاسخ را با مشخصات فنی بسنجید، نه با ارائهٔ فروش، و بپرسید پیش‌فرض‌ها چیستند — بیشتر مردم آن‌ها را برعکس حدس می‌زنند.
5. «چه کاری را نمی‌تواند انجام دهد؟» فهرست مرزها ارزان‌ترین نشانهٔ اعتبار ممکن است و تقریباً هیچ‌کس آن را منتشر نمی‌کند. نبودش دلیل بر چیزی نیست. وجودش بسیار ارزشمند است.

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