−25%

روی پرداخت سالانه Windows، تا ۳۱ اکتبر. مشاهده پلن‌ها

EQVPS
شروع کنید

عامل‌های هوش مصنوعی واقعاً چه چیزی از زیرساخت لازم دارند: ۷ نیاز، و جایی که میزبانی ساخته‌شده برای انسان مانع می‌شود

18 مهر 1405 · 5 دقیقه مطالعه · EQVPS Team

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

وسوسه‌انگیز است که بگوییم «فقط یک API به او بدهید». این نیاز اول است، نه آخر. در ادامه هفت نیازی آمده که به نظر ما مهم‌اند، برگرفته از ساختن سرور MCP و REST API خودمان برای عامل‌ها. برای هرکدام: بدون آن چه چیزی خراب می‌شود.

۱. هر چیزی که عامل لازم دارد قابل برنامه‌نویسی باشد

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

بدون آن: عامل ۸۰٪ راه را می‌رود و در همان یک گامی که کلیک لازم دارد می‌ماند، و در نهایت انسانی باید کار را تمام کند. یک API نیمه‌کاره اغلب از نبودنش بدتر است، چون خودکارسازی‌ای را دعوت می‌کند که نمی‌تواند به پایان برسد.

۲. خطاهایی که برنامه بتواند بر اساسشان عمل کند

عامل پاسخ را می‌خواند و تصمیم می‌گیرد بعد چه کند. بدنهٔ JSON با کدی پایدار (402 insufficient_balance، 409 sandbox_paused، 429 budget_exceeded همراه با زمان بازنشانی) چیزی است که می‌تواند بر اساس آن تصمیمش را شاخه‌بندی کند. صفحهٔ خطای HTML یا یک 500 با پیامی مبهم، او را به حدس زدن وامی‌دارد: اغلب چیزی را تکرار می‌کند که هرگز موفق نخواهد شد.

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

۳. پرداخت بدون انسان در میانه

پرداخت با کارت پر از گام‌هایی است که برای اطمینان از حضور یک انسان ساخته شده‌اند: کدهای 3-D Secure، تأیید در اپلیکیشن بانک، بررسی هویت. این‌ها برای جلوگیری از تقلب خوب‌اند و برای نرم‌افزار ناممکن. موجودی پیش‌پرداختی که از قبل شارژ شده (در مورد ما اغلب با استیبل‌کوین) به عامل اجازه می‌دهد هزینهٔ آنچه را مصرف می‌کند بپردازد، بی‌آنکه انسانی هر کسر را تأیید کند.

بدون آن: یا انسانی هر خرید را تأیید می‌کند، که کل هدف را بی‌معنا می‌کند، یا کسی کارتی به عامل می‌دهد، که ریسکی است که هیچ‌کس نباید بپذیرد.

۴. سقف‌های سخت‌گیرانه برای هزینه

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

بدون آن: از روی موجودی می‌فهمید که حلقه‌ای در کار بوده. صورت‌حساب سندباکس‌های ما به همین دلیل سقف دارد، و صفحهٔ محافظ‌های MCP پیشنهاد می‌کند کدام کارها اصلاً باید به تأیید انسان نیاز داشته باشند.

۵. پردازش با دانه‌بندی درست

عامل‌ها سه نوع کار بسیار متفاوت تولید می‌کنند:

  • ثانیه‌ها: اجرای تکه‌ای از کد تولیدشده، بررسی یک پاسخ، امتحان یک اصلاح.
  • ساعت‌ها: یک ارزیابی، یک خزش وب، یک build طولانی.
  • همیشه روشن: یک ربات، یک API، یک worker زمان‌بندی‌شده.

پلتفرمی که فقط سرور ماهانه ارائه می‌دهد، نوع اول را به‌طرز مضحکی گران می‌کند؛ پلتفرمی که فقط سندباکس‌های کوتاه‌عمر دارد، نوع سوم را شکننده می‌کند. کاری ۲۰ ثانیه‌ای روی ماشینی که ساعتی حساب می‌شود، هزینهٔ ۵۹ دقیقه هیچ را می‌پردازد. صورت‌حساب ثانیه‌ای چطور کار می‌کند نشان می‌دهد هر مدل کجا دیگر منطقی نیست.

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

۶. جداسازی به‌صورت پیش‌فرض

کدی که عامل می‌نویسد کدی است که هیچ‌کس بازبینی‌اش نکرده. باید جایی اجرا شود که هیچ چیز ارزشمندی در آن نیست: نه میزبان خود عامل، نه سروری با کلیدهای شما، نه ماشینی که ایمیل شما را می‌فرستد. در عمل یعنی یک ماشین مجازی یا microVM جداگانه برای هر کار که بعد حذف شود. سطوح جداسازی برای کد نامطمئن گزینه‌ها را مقایسه می‌کند؛ Firecracker microVM به زبان ساده توضیح می‌دهد چرا هستهٔ مستقل اهمیت دارد.

بدون آن: اولین تزریق دستور (prompt injection) که به کد تولیدشده راه پیدا کند، به هر چیزی که میزبان عامل به آن دسترسی دارد دست می‌یابد.

۷. دید و کلید توقف

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

بدون آن: پاک‌سازی به باستان‌شناسی تبدیل می‌شود. منابع فراموش‌شده همچنان هزینه می‌سازند؛ توکن نشت‌کرده همچنان کار می‌کند.

آنچه عامل‌ها لازم ندارند

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

آنچه هنوز حل نشده

همهٔ این‌ها مسئلهٔ مهندسی حل‌شده نیستند.

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

به کجا رسیده‌ایم

تلاش کرده‌ایم برای این نیازها بسازیم، نه دور زدنشان: سرور MCP و REST API که کل چرخهٔ عمر را پوشش می‌دهند، خطاهای قابل خواندن برای ماشین، موجودی پیش‌پرداخت، سقف‌های هزینه، سندباکس‌های کد ثانیه‌ای برای کار کوتاه و سرورهای ماهانه مانند تعرفهٔ AI agent برای کار طولانی. مروری بر بخش سندباکس‌ها در سندباکس برای عامل‌های هوش مصنوعی آمده است. ترجیح می‌دهیم فهرست را بر اساس ارزش خودش بسنجید؛ این فهرست برای هر پلتفرمی که عاملی را در آن رها می‌کنید، چک‌لیست مفیدی است.

سؤالات متداول

آیا یک API برای اینکه عامل از سرویس میزبانی استفاده کند کافی نیست؟

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

اگر عامل‌ها از موجودی پیش‌پرداخت پول می‌دهند، چرا به سقف هزینه نیاز دارند؟

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

واحد درست پردازش برای یک عامل چیست؟

بستگی به کار دارد. اجرای تکه‌ای از کد تولیدشده چند ثانیه طول می‌کشد و سندباکس ثانیه‌ای مناسبش است. کاری چندساعته هم با همان یا با ماشینی ساعتی جور است. سرویسی که همیشه روشن است جایش روی سرور ماهانه است. عامل‌ها هر سه کار را انجام می‌دهند، پس به هر سه نیاز دارند.

چه چیزی هنوز حل نشده است؟

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

نظرات

هنوز نظری نیست. اولین نفر باشید.

یک نظر بگذارید

نظرات پیش از نمایش بررسی می‌شوند.