یک برنامهنویس مستقل اکنون میتواند یک هویت مستقل برای هوش مصنوعی خود بسازد و آن را در یک فضای کاری مشترک مستقر کند. این امکان از طریق پشتیبانی جدید عامل هرمس (Hermes Agent) از Buzz فراهم شده است.
طبق اعلام Nous Research در هفته جاری، این مسیرهای ادغام به عاملها اجازه میدهد تا مانند شهروندان درجهیک با کلیدهای رمزنگاری و عضویتهای کانال اختصاصی فعالیت کنند. این رویکرد، مدل محدودکننده «توکنهای ربات» را که در اکثر ابزارهای چت شرکتی دیده میشود، کنار میزند. در واقع بسیاری از سازمانها هنوز با این چالش دست و پنجه نرم میکنند، چرا که طبق آمارهای اخیر، ۷۱٪ از عاملهای هوش مصنوعی در شرکتها تنها پوششی برای چتباتها هستند و فاقد استقلال عملیاتیاند.
همانطور که در تحلیل قبلی ما دربارهی استفاده از عاملهای هوش مصنوعی برای مقیاسبندی دانش سازمانی اشاره کردیم، این بهروزرسانی عامل را از یک ابزار تکنفره به یک محیط همکاری جمعی منتقل میکند. Buzz که توسط شرکت Block توسعه یافته، یک فضای کاری متنباز بر پایه پروتکل Nostr است. از آنجانی که هر پیام در این سامانه یک رویداد امضاشده روی یک رله (Relay) تحت مالکیت کاربر است، یک مسیر بازرسی شفاف برای انسانها و هوش مصنوعی ایجاد میکند.
بر اساس مستندات منتشرشده، بسته به نیاز فنی، کاربران میتوانند از سه مسیر استقرار استفاده کنند:
۱. محیط اجرای دسکتاپ (Desktop Runtime)
برای کسانی که از نسخه دسکتاپ Buzz استفاده میکنند، هرمس به صورت یک بستار پیشفرض در دسترس است. کاربران باید به مسیر Settings ← Runtimes بروند تا عامل را بهصورت محلی اجرا کنند. ارتباطات ورودی از طریق ACP روی stdio صورت میگیرد. این رویکرد یادآور معماریهای جدیدی است که استنتاج هوش مصنوعی را از ابر به شبکهای از دستگاههای محلی منتقل کردهاند تا کنترل بیشتری بر پردازش دادهها داشته باشند.
۲. پل رله (Relay Bridge)
این ادغام انتقالدهنده از بستار buzz-acp برای متصل کردن یک کانال به ACP هرمس روی stdio استفاده میکند تا از طریق WebSocket به رله برسد. این روش اجازه میدهد یک هویت میزبانیشده، همان تنظیمات، حافظه و مهارتهای میزبان محلی را داشته باشد.
۳. درگاه بومی (Native Gateway)
این عمیقترین سطح ادغام است که با Buzz مانند یک پلتفرم پیامرسان استاندارد (شبیه دیسکورد) برخورد میکند. این مسیر از تعاملات کامل کانال، از جمله پاسخهای رشتهای، واکنشها و ارسالهای زمانبندی شده پشتیبانی میکند. به گزارش MarkTechPost، این متد از یک WebSocket نوستر با احراز هویت NIP-42 استفاده میکند و در صورت عدم موفقیت، هر ۴ ثانیه یک بار از طریق CLI وضعیت را بررسی میکند.
حریم خصوصی در این انتشار اولیت اصلی است. به طور پیشفرض، عامل تنها زمانی پاسخ میدهد که صراحتاً در کانالها مورد اشاره قرار گیرد، هرچند پیامهای مستقیم (DM) همیشه باعث فعال شدن آن میشوند. دسترسیها از طریق یک لیست سفیدِ کلید عمومی (pubkey allow-list) محدود شدهاند تا امنیت حفظ شود. این مدل مدیریت دسترسی، با مفاهیم هوش مصنوعی حاکمیتی برای حذف ریسک نشت داده در سازمانها همسو است.
این تغییر، گذاری از «مدیریت متمرکز رباتها» به سوی «هویت غیرمتمرکز» است. با دادن کلیدهای Nostr به عاملها، تیمهای مهندسی میتوانند با هوش مصنوعی به عنوان یک همتیمی با هویت پایدار برخورد کنند، نه صرفاً یک افزونه. این ساختار، کاربردهای عملی مانند پیشنویس یادداشتهای انتشار توسط عامل یا بررسی کدها در شاخههای خاص گیت را ممکن میکند.
تیمهای بازار متوسط هدف اصلی این ابزار هستند، زیرا زیرساخت رله بر پایه Postgres, Redis و S3/MinIO است. کاربران سازمانی باید در حال حاضر با این ابزار به صورت آزمایشی (Pilot) برخورد کنند، زیرا کلاینتهای موبایل و گیتهای رسمی تأیید جریان کاری هنوز در دست توسعهاند.
گام بعدی شما
- بررسی مستندات Buzz Adapter Reference برای درک معماری اتصال
- مطالعه مخزن گیتهاب پروژه برای شروع میزبانی شخصی (Self-hosting)
- تست مدل Native Gateway برای جایگزینی رباتهای متمرکز در تیمهای کوچک
اما داستان زیرساختی این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی پروتکلهای ارتباطی جدید در سیستمهای عاملمحور مراجعه کنید.
گفتگو