«گذار از ابزار به لایه»؛ رویکرد جدید H2A2H در مدیریت عامل‌ها

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

به نقل از گزارش ۱۴ جولای ۲۰۲۶ در وب‌سایت dev.to، این رویکرد اساس معماری H2A2H (Human-to-Agent-to-Human یا انسان به عامل به انسان) است. اصل مرکزی این معماری این است که «انسان‌ها نقطه نهایی اعتبار‌سنجی باقی می‌مانند، در حالی که عامل‌ها پیچیدگی‌های فنی اجرای توزیع‌شده را مدیریت می‌کنند». در این مدل، لایه هماهنگی اختصاصی عامل‌محور جایگزین خط لوله سنتی «انسان به اپلیکیشن» می‌شود. هدف این چارچوب جایگزینی تعاملات انسانی نیست، بلکه ایجاد یک مدل همکاری است که در آن انسان‌ها «قصد» (Intention) خود را بیان می‌کنند و عامل‌ها پیچیدگی‌های فنی را برای رسیدن به آن قصد حل می‌کنند.

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

چارچوب فنی هسته

این معماری برای حفظ امنیت، شفافیت و قابلیت اطمینان، بر چندین لایه حیاتی تکیه دارد که هر یک وظیفه‌ای مشخص در چرخه عملیاتی دارند:

• لایه هویت عامل (Agent Identity Layer): هر عامل در این شبکه دارای یک شناسایی جهانی (Universal Identification)، سیستم احراز هویت و سابقه اعتبار (Reputation History) است. این ساختار اجازه می‌دهد تا با عامل‌ها به عنوان شرکت‌کنندگانی قابل‌اتبات و شناسایی در یک شبکه گسترده‌تر برخورد شود.
• لایه قابلیت (Capability Layer): عامل‌ها نه بر اساس کدهای برنامه‌نویسی، بلکه بر اساس «قابلیت‌های» آن‌ها تعریف می‌شوند. یک قابلیت تعیین می‌کند که عامل چه کاری می‌تواند انجام دهد، چه ورودی‌هایی را می‌پذیرد، چه نتایجی تولید می‌کند و چه محدودیت‌هایی دارد. برای مثال، قابلیت PaymentValidation ورودی یک transaction (تراکنش) را می‌گیرد و در خروجی یک verified_payment (پرداخت تأییدشده) تولید می‌کند.
• کشف قابلیت (Capability Discovery): سیستم باید بتواند عامل‌هایی را که قادر به حل یک «قصد» خاص هستند، کشف کند. به‌جای استفاده از فراخوانی‌های سخت‌افزاری (Hard-coded) مانند POST /payment/check، مدل H2A2H مسیری را دنبال می‌کند که شامل این مراحل است: قصد («تأیید پرداخت») ← کشف (یافتن عامل‌های دارای قابلیت PaymentValidation) ← اجرا.
• لایه قصد (Intent Layer): در این لایه، ارتباطات از فراخوانی‌های فنی توابع به یک توالی منطقی تغییر می‌یابد: «قصد ← استدلال ← انتخاب قابلیت ← اجرا ← تأیید».
• لایه ارتباطات عامل (Agent Communication Layer): این لایه بر پایه ارتباطات استاندارد است و «حمل‌ونقل» (Transport) را از «قصد» جدا می‌کند. این لایه می‌تواند از پروتکل‌های متنوعی مانند QUIC، NATS، gRPC، WebSocket یا سایر پروتکل‌های تخصصی استفاده کند. این بدان معناست که یک عامل نیازی ندارد مکان دقیق یا آدرس فیزیکی عامل دیگر را بداند تا با آن تعامل کند.

مکانیسم‌های عملیاتی عامل‌ها

در مدل H2A2H، نقش‌ها به‌دقت تعریف شده‌اند تا «حلقه اعتماد» به‌طور کامل حفظ شود و هیچ مرحله‌ای بدون نظارت باقی نماند:

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

امنیت و حافظه

از آنجایی که عامل‌ها به نمایندگی از انسان‌ها عمل می‌کنند، سیستم از مدل اعتماد صفر (Zero Trust) بهره می‌برد. در این مدل، انسان‌ها کنترل دائمی و مطلق به عامل‌ها نمی‌دهند؛ بلکه مجوزهای موقت و محدودی صادر می‌کنند که به «مجوز انسانی» (Human Authorization) معروف است. این سیستم اجازه می‌دهد «عامل X بتواند قابلیت Y را در بازه زمانی Z اجرا کند» و برای این کار از احرازهویت‌های قوی و توکن‌های کوتاه‌مدت استفاده می‌کند.

برای تضمین پاسخگویی (Accountability)، سیستم از تکیه بر حالت‌های حافظه دائمی اجتناب می‌کند. به‌جای آن، تمامی اجراها به صورت جریانی از رویدادها (Event Stream) ثبت می‌شوند. برای مثال:

• رویداد ۱: انسان درخواست اقدام را ارسال کرد.
• رویداد ۲: عامل قابلیت مربوطه را کشف کرد.
• رویداد ۳: عامل عملیات را اجرا کرد.
• رویداد ۴: انسان نتیجه را تأیید کرد.

این رویکرد رویداد-محور (Event-driven)، امکان حسابرسی کامل، شفافیت مطلق و توانایی بازسازی توالی اقدامات را برای مقاصد بازیابی (Recovery) فراهم می‌کند.

گذار از اپلیکیشن به عامل

این تغییر پارادایم، صنعت نرم‌افزار را از سامانه‌هایی که حول محور اپلیکیشن‌های ایستا (Static Applications) می‌چرخند، به سمت سامانه‌هایی می‌برد که محور آن‌ها عامل‌های پویا (Dynamic Agents) هستند. معماری H2A2H در واقع تکاملی از مفاهیم موجود است: در این مدل، APIها به «قابلیت‌ها»، میکروسرویس‌ها به «عامل‌های متخصص» و جریان‌های کاری (Workflows) به «قصدها» تبدیل می‌شوند. این مدل فناوری‌های فعلی را حذف نمی‌کند، بلکه آن‌ها را در قالب یک مدل عامل-محور سازماندهی می‌کند.

در حالی که ابزارهای فعلی فرض می‌کنند کاربر می‌داند کدام سیستم یا اپلیکیشن را باید فراخوانی کند، H2A2H فرض می‌کند کاربر فقط «هدف» یا همان Objective را می‌داند و زیرساخت متولی کشف مسیر رسیدن به آن هدف است. برای یک متخصص، این به معنای کاهش شدید پیچیدگی رابط کاربری (UI) است؛ شما دیگر ابزارها را مدیریت نمی‌کنید، بلکه «قصدها» را مدیریت می‌کنید.

نقشه راه و نسخه‌ها

این پروژه در حال حاضر در مرحله توسعه به عنوان H2A2H v0.3 قرار دارد. تمرکز فعلی تیم توسعه بر تثبیت و یکپارچه‌سازی بنیادها است: شامل مدل‌های عامل، سیستم هویت، تعریف قابلیت‌ها، پروتکل‌های ارتباطی، امنیت و استانداردهای تعامل.

پس از نهایی شدن نسخه v1.0، یک مقاله علمی رسمی منتشر خواهد شد. این مقاله به تفصیل موارد زیر را شرح خواهد داد:

• مبانی رسمی و مدل معماری.
• ویژگی‌های نوظهوری (Emerging Properties) که در این سیستم شکل می‌گیرند.
• مقایسه‌های دقیق با معماری‌های موجود در صنعت.
• موارد استفاده (Use cases) خاص و نتایج به‌دست‌آمده از آزمایش‌های عملی.

چه یک توسعه‌دهنده باشید و چه یک رهبر کسب‌وکار، گذار به H2A2H نوید آینده‌ای را می‌دهد که در آن واژه «اپلیکیشن» به یک اصطلاح قدیمی (Legacy) تبدیل شده و جای خود را به «قابلیت» می‌دهد. در این آینده، انسان‌ها قصد را فراهم می‌کنند، عامل‌ها قابلیت اجرا را می‌آورند و سیستم‌ها زیرساخت را تأمین می‌کنند تا همگی در یک لایه همکاری توزیع‌شده، امن و قابل‌راستی‌آزمایی به هم متصل شوند.

گام بعدی شما

• بررسی مفاهیم «کشف قابلیت» برای جایگزینی فراخوانی‌های سخت‌افزاری (Hard-coded) در پروژه‌های خود.
• مطالعه مدل‌های Trustless برای مدیریت دسترسی‌های موقت در سامانه‌های عامل‌محور.
• تحلیل تفاوت بین Workflow-centric و Intent-centric بودن در طراحی محصول.

اما اثر این معماری بر هزینه‌های استنتاج در مقیاس سازمانی حتی پیچیده‌تر است — به تحلیل ما درباره‌ی بهینه‌سازی‌های لایه استنتاج مراجعه کنید.