هر نرمافزاری که امروزه استفاده میکنید، بر اساس یک فرض واحد ساخته شده است. کسی با انگشتان دست پشت یک صفحه نمایش نشسته است. دکمهها نشاندهنده قصد و نیت هستند. راهنماهای گامبهگام (Wizards) پیچیدگی را مدیریت میکنند. فرمها به تفکر انسانی ساختار میدهند. این معماری دههها بر طراحی محصول حاکم بوده است، زیرا تا همین اواخر، فقط انسانها کلیک میکردند.
این فرض اکنون شکسته شده است. عاملهای هوش مصنوعی (AI agents) رابطهای کاربری را نمیخوانند. آنها از راهنمایهای کوچک (tooltips) یا کادرهای تأیید (confirmation dialogs) بهرهای نمیبرند. وقتی یک سیستم خودگردان نیاز دارد از طرف کاربر عمل کند، عناصر گرافیکی رابط کاربری (chrome) مانع میشوند. نتیجه این است که شکاف فزایندهای بین نحوه ساخت محصولات و نحوه رفتار واقعی فراخوانهای (callers) مدرن ایجاد شده است.
پارادایم کلیک
نرمافزارهای سنتی بر یک قرارداد بصری تکیه دارند. یک انسان دکمهای را میبیند، برچسب آن را درک میکند و تصمیم میگیرد که آیا آن را فشار دهد یا خیر. جریانهای کاری (Workflows) عمداً با اصطکاک همراه شدهاند. راهنماهای گامبهگام چندمرحلهای به این دلیل وجود دارند که انسانها مرتکب اشتباه میشوند و به حفاظها (guardrails) نیاز دارند. منوهای کشویی (Dropdowns) و دکمههای رادیویی (radio buttons) ورودی را محدود میکنند، زیرا متنهای آزاد، آشفتگی به همراه دارند.
این رویکرد زمانی که اپراتور یک انسان باشد، به خوبی کار میکند، اما وقتی اپراتور یک عامل (agent) باشد، از هم میپاشد. یک ماشین برای لغو اشتراک یا تغییر یک رکورد، به یک راهنمای گامبهگام پنج مرحلهای نیاز ندارد. ماشین به بیانی شفاف از عملیاتهای موجود و پاسخی قطعی درباره اینکه آیا اجازه انجام آنها را دارد یا خیر، نیاز دارد. وقتی تیمها این موضوع را نادیده میگیرند، معمولاً به سراغ دو میانبر میروند.
اول، یک کلید API به عامل میدهند. دوم، رابط کاربری موجود را درون یک چتبات میپیچند و ادعا میکنند که یکپارچهسازی کامل شده است. هیچکدام از این دو رویکرد مشکل اصلی را حل نمیکنند.
یک کلید API به این سوال پاسخ میدهد که: «آیا این درخواست از یک منبع قابل اعتماد آمده است؟» اما هرگز به سوال مهمی که وجود دارد پاسخ نمیدهد: «آیا این فراخوان (caller) خاص میتواند این رکورد خاص را بخواند؟» یک کلید، مانند یک کلید همهکاره (skeleton key) است. پس از صدور، معمولاً دسترسی گستردهای را به منابع و زمینههای مختلف میدهد. این کلید هیچ اطلاعی از سیاستهای حاکم بر اقدامات انفرادی در سیستم شما ندارد.
پیچیدن یک رابط گرافیکی (GUI) در یک چتبات حتی شکنندهتر است. عامل، تمام فرضهای انسانمحور را که در رابط کاربری نهفته است، به ارث میبرد. عامل، کلیکها را از طریق پنجرههای مودال (modals) و فرمهایی شبیهسازی میکند که برای چشم انسان طراحی شدهاند، نه برای منطق خودگردان. چتبات ممکن است با موفقیت در میان عناصر گرافیکی پیمایش کند، اما این کار را بدون درک انجام میدهد. این فقط یک «نمایش اتوماسیون» است. در لایههای زیرین، هنوز هیچ قرارداد ماشینخوان درباره آنچه مجاز است، وجود ندارد.
آنچه عاملها نیاز دارند، کلید دیگری برای در ورودی نیست؛ آنها به «گیتها» (gates) نیاز دارند.
گیتها واقعاً چه کار میکنند
یک گیت، یک لایه اجرای تحت مدیریت است. به جای اعتماد به یک اعتبارنامه (credential) و امید به اینکه فراخوان رفتار درستی داشته باشد، سیستمی که دارای گیت است، هر درخواست را بر اساس قوانین اعلامشده ارزیابی میکند. این قوانین مستقل از هرگونه رابط کاربری، چه انسانی و چه غیره، وجود دارند.
یک گیت مناسب چهار مورد را تعریف میکند: اعلام میکند چه اقداماتی در محصول وجود دارد؛ مشخص میکند چه کسی میتواند آنها را تحت چه شرایطی فراخوانی کند؛ تعیین میکند که فراخوان در چه زمانی باید متوقف شده و قبل از ایجاد اثرات جانبی (side effects)، رضایت صریح را درخواست کند؛ و تضمین میکند که سیستم هر تصمیم را در یک مسیر (trail) ساختاریافته و قابل پرسوجو (queriable) ثبت کند.
این اساساً با کنترل دسترسی سنتی متفاوت است. سیستمهای مبتنی بر نقش (Role-based) اغلب در دم در میپرسند: «آیا شما مدیر هستید؟» و سپس اجازه میدهند در ساختمان پرسه بزنید. اما گیتها در هر تقاطع میپرسند: «آیا اجازه دارید همین الان این کلید خاص را بزنید؟». در اینجا هویت در درجه دوم اهمیت نسبت به رفتار قرار میگیرد. سیاست (policy) همراه با خودِ اقدام حرکت میکند.
برای ملموستر شدن این موضوع، عاملی را تصور کنید که نیاز به بازگرداندن وجه به یک مشتری دارد. یک رویکرد مبتنی بر کلید ممکن است به هر کسی که کلید را در اختیار دارد اجازه دهد در صورت در دسترس بودن نقطه پایانی (endpoint)، فرآیند بازگشت وجه را انجام دهد. اما یک رویکرد مبتنی بر گیت، فهرست (manifest) اقدامات موجود را بررسی میکند، مجوز عامل را نسبت به رکورد مشتری خاص تأیید میکند، برای اثر جانبی مالی نیاز به تأیید صریح کاربر دارد و کل این توالی را در یک گزارش حسابرسی (audit log) مینویسد. گیت سیاست را اجرا میکند، نه فقط هویت را.
آزمایش آن روی Whistler
ما این مدل را روی Whistler به کار گرفتیم. به جای ساخت خط لولههای (pipelines) جداگانه برای انسانها و ماشینها، یک لایه سیاست واحد نوشتیم و دو فراخوان متفاوت را روی آن اجرا کردیم.
یکی از فراخوانها، انسانی بود که از Shell تعبیه شده استفاده میکرد. دیگری یک عامل شخص ثالث بود که خارج از تیم ما توسعه یافته بود. هر دو به یک manifest یکسان متصل شدند. هر دو در هر مرحله با بررسیهای مجوز یکسان روبرو شدند. هر زمان که یکی از فراخوانها سعی میکرد اقدامی با اثرات جانبی انجام دهد (مانند تغییر دادهها یا ایجاد یک رویداد خارجی)، سیستم نیاز به تأیید صریح داشت. هر درخواست، تأیید و رد، همان مسیر حسابرسی ساختاریافته را ایجاد میکرد.
هیچکدام از فراخوانکنندگان از یک کلید اصلی API استفاده نکردند. هیچ در پشتی یا اعتبارنامه سطح بالایی که سیاستها را دور بزند، وجود نداشت. انسان به دلیل داشتن رمز عبور و مرورگر، با محدودیتهای کمتری مواجه نشد. عامل (agent) نیز به دلیل نداشتن اثر انگشت انسانی، با مسدودسازیهای خودسرانه روبرو نشد. دروازه، اقدام، زمینه (context) و قوانین را ارزیابی کرد. کل تراکنش همین بود.
نتیجه، سیستمی بود که در آن افزودن یک فراخوانکننده جدید، چه انسان و چه ماشین، نیازی به بازنویسی (refactoring) منطق دسترسی نداشت. شما سیاست را بهروزرسانی کردید و دروازه آن را اعمال کرد.
بازنگری در پرسش محصولی
اگر تیم شما در حال حاضر در تلاش است تا بفهمد چگونه عاملهای هوش مصنوعی (AI agents) را به محصولی که توسط انسان ساخته شده اضافه کند، احتمالاً دارید با پرسش اشتباهی شروع میکنید. تیمها به طور غریزی میپرسند که آیا باید یک API ارائه دهند یا خیر. در عوض، آنها باید بپرسند که آیا برای هر فراخوانکننده، یک لایه اجرای تحت مدیریت (governed execution layer) دارند یا خیر.
یک API بدون دروازه، صرفاً دری پهنتر است. اگر سیاستهای داخلی شما فقط در منطق راهنما (wizard logic)، اعتبارسنجی فرم و متنهای راهنمای قابل خواندن برای انسان تعریف شده باشند، هیچ اندپوینتی (endpoint) که منتشر میکنید برای فراخوانکنندگان خودگردان ایمن نخواهد بود. عامل یا از طریق یک کلید، اعتماد بیش از حدی به ارث میبرد، یا از طریق یک پوشش چتبات (chatbot wrapper)، نوعی عروسکگردانی شکننده انجام میدهد.
اولویت دادن به ساخت دروازهها به این معناست که هر اقدام معنادار در محصول خود را به عنوان یک عملیات اعلامشده (declared operation) فهرست کنید. به این معناست که بررسی مجوز را از رابط کاربری جدا کنید تا هم یک کاربر Shell و هم یک عامل خارجی با یک اجرای یکسان در زمان اجرا (runtime enforcement) روبرو شوند. به این معناست که قلابهای رضایت (consent hooks) را برای عملیاتهای مخرب، پیش از آنکه به آنها نیاز پیدا کنید، بگنجانید؛ نه بعد از اینکه یک عامل، مجموعه داده اشتباهی را پاک کرد. و به این معناست که ردپای حسابرسی (audit trails) تولید کنید که تیمهای امنیت و انطباق بتوانند بدون اهمیت دادن به اینکه فراخوانکننده از جنس کربن بوده یا سیلیکون، آنها را بررسی کنند.
این امر مستلزم یک تغییر معماری واقعی است. طراحی انسانمحور، منطق را در لفافهای از همدلی و اصطکاک میپیچد. طراحی آماده برای عامل (Agent-ready design)، منطق را از طریق قراردادهای صریح و ماشینخوان ارائه میدهد. در اینجا رابط کاربری دیگر خودِ سیاست نیست، بلکه مانیفست (manifest) به سیاست تبدیل میشود.
این گذار به معنای جایگزینی انسانها نیست؛ بلکه به معنای تشخیص این است که نرمافزار شما اکنون بیش از یک نوع فراخوانکننده دارد و هر یک از آنها شایسته همان سطح از دقت و سختگیری هستند.
نکته اصلی
طراحی برای «کلیک» را متوقف کنید. طراحی برای «قاعده» را شروع کنید. اگر سیستم شما بتواند هر فراخوانکننده را از طریق اقدامات اعلامشده، مجوزهای زمینهای (contextual permissions)، بررسیهای رضایت و ردپای حسابرسی مشترک مدیریت کند، دیگر فرقی نمیکند چه کسی یا چه چیزی در آن سوی خط باشد. انسان یا عامل، همه با یک دروازه روبرو میشوند. ابتدا دروازه را بسازید. API فقط یک در است؛ اما سیاست (Policy) همان چیزی است که اتاق را سالم نگه میدارد.