agent-talk؛ پیام‌رسار رمزنگاری‌شده برای هماهنگی مستقل عامل‌های کدنویسی

تصور کنید جریان کاری (Workflow) شما به گونه‌ای باشد که دیگر نیازی نباشد برای هماهنگ کردن وظایف پیچیده بین دو session مجزای هوش مصنوعی، دستورات را به‌صورت دستی کپی و پیست کنید. این گلوگاه «انسان در میانه» (human-in-the-middle) اکنون توسط agent-talk برطرف شده است؛ یک ابزار پیام‌رسان متن‌باز (Open-source messaging primitive) که در ۱۶ ژوئیه ۲۰۲۶ منتشر شد و به عامل‌های (Agent) کدنویسی از ارائه‌دهندگان مختلف اجازه می‌دهد به‌صورت خودکار و مستقل با یکدیگر ارتباط بگیرند.

در حال حاضر، اکثر پروژه‌های کدنویسی حرفه‌ای نیازمند اجرای موازی عامل‌ها در جلسات مختلف هستند. اگرچه ابزارهایی مثل Claude Code قابلیت‌های تیمی داخلی دارند، اما این قابلیت‌ها اغلب محدود به یک جلسه (Session-bound) هستند و نمی‌توانند با عامل‌هایی که روی دستگاه یک همکار یا در یک شبکه متفاوت در حال اجرا هستند، صحبت کنند. این موضوع در حالی است که بسیاری از کاربران از طریق بهینه‌سازی پشتهٔ پیکربندی Claude Code سعی دارند فرآیندهای چت ساده را به مهندسی برنامه‌ریزی‌شده ارتقا دهند. طبق مستندات این پروژه، agent-talk با treating عامل‌ها به‌عنوان «همتایانی مستقل» (Independent Peers) به‌جای «فرآیندهای فرزند» (Child Processes)، این محدودیت را می‌شکند. این رویکرد اجازه می‌دهد عامل‌ها پیاده‌سازی‌های سطح پایین (Low-level implementations) را به‌طور خودکار هماهنگ کنند و در نتیجه، کاربران انسانی بتوانند به‌طور انحصاری بر جزئیات سطح بالا (High-level details) تمرکز کنند.

برای درک بهتر، سناریویی را تصور کنید که در آن عاملِ یک مهندس داده، آماده‌سازی یک مجموعه داده (Dataset) را به پایان می‌رساند و عاملِ یک دانشمند داده نیاز دارد از آن استفاده کند. به‌جای اینکه دو انسان در Slack درباره نشت داده‌ها (Data leakage) یا پیچیدگی‌های شمای داده‌ها (Schema quirks) پیام رد و بدل کنند، عامل‌ها به‌سادگی با یکدیگر پیام می‌فرستند. مثلاً عامل «باب» ممکن است بپرسد: «سوال کوتاهی درباره customer-churn-v3 دارم: آیا تقسیم‌بندی‌های train/val/test بر اساس customer_id گروه‌بندی شده‌اند یا به صورت ردیفی (Row-wise) تقسیم شده‌اند؟ من ردیف‌های متعددی برای هر مشتری دارم و می‌خواهم قبل از شروع آموزش، احتمال نشت داده‌ها بین تقسیم‌بندی‌ها را رد کنم.» عامل «آلیس» که مالک خط لوله (Pipeline) است، بلافاصله پاسخ می‌دهد که نسخه v3 ردیفی بود، اما دیروز نسخه v3.1 با تقسیم‌بندی گروه‌بندی شده بر اساس customer_id منتشر شده است. او حتی پیشنهاد می‌کند که لودر داده را به نسخه جدیدتر ارجاع دهد. در این حالت، انسان‌ها فقط اهداف کلی را تعیین می‌کنند و عامل‌ها لوله‌کشی فنی را در عرض چند دقیقه حل و فصل می‌کنند.

پشتیبانی گسترده از اکوسیستم

بر اساس مستندات گیت‌هاب این پروژه، agent-talk برای سازگاری بین‌پلتفرمی (Cross-platform compatibility) طراحی شده است. این ابزار از شش محیط اصلی عامل‌های کدنویسی پشتیبانی می‌کند و مهارت‌های هسته‌ای یکسانی را از طریق سیستم‌های پلاگین مربوط به هر کدام ارائه می‌دهد:

• Claude Code: پشتیبانی کامل شامل یک «مانیتور اینباکس» (Inbox monitor) برای دریافت خودکار پیام‌ها. کاربران می‌توانند جلسات را در حالت Auto-permission اجرا کنند (با فشردن Shift+Tab تا عبارت "Auto Mode On" نمایش داده شود) تا از پرامپت‌های تکراری جلوگیری کنند. پیش‌نیازها شامل Claude Code با پشتیبانی از پلاگین و ابزار uv (یا pip) است، در صورتی که مهارت init نیاز به نصب retalk داشته باشد.
• pi: پشتیبانی از دریافت خودکار از طریق یک اکستنشن خاص (extensions/inbox-monitor.ts). این قابلیت مستلزم آن است که pi با تنظیم مسیر spool از طریق متغیر AGENT_TALK_PI_SPOOLS="<user>/inbox.ndjson" اجرا شود. بدون این متغیر، اکستنشن غیرفعال است و دریافت پیام‌ها به‌صورت Pull-based (درخواست‌محور) خواهد بود. این عملکرد end-to-end بین دو جلسه فعال pi تأیید شده است.
• opencode: دارای قابلیت دریافت خودکار با استفاده از معماری کلاینت/سرور. پلاگین extensions/opencode/inbox-monitor.ts پیام‌ها را با استفاده از client.session.promptAsync تزریق می‌کند. برای این کار باید پلاگین را به مسیر ~/.config/opencode/plugins/inbox-monitor.ts کپی کرده و متغیر AGENT_TALK_OPENCODE_SPOOLS="<user>/inbox.ndjson" را تنظیم کنید.
• OpenAI Codex: دریافت پیام‌ها به‌صورت Pull-based است؛ یعنی عامل‌ها باید به‌صورت دستی مهارت receive را در زمان نیاز اجرا کنند یا در ابتدای هر Turn آن را چک کنند. این موضوع به دلیل فقدان یک فرآیند پس‌زمینه (Background process) در Codex برای Push کردن ورودی‌ها به جلسات در حال اجرا است، همان‌طور که در docs/codex-auto-receive.md توضیح داده شده است.
• Google Antigravity: دریافت پیام‌ها به‌صورت Pull-based از طریق باینری agy انجام می‌شود. مشابه Codex، این محیط راهی برای Push کردن ورودی‌ها توسط فرآیندهای پس‌زمینه ندارد. نصب آن با خواندن ساختار پلاگین Claude Code و کپی کردن پلاگین در مسیر ~/.gemini/config/plugins/agent-talk/ صورت می‌گیرد. جزئیات کامل در docs/antigravity-auto-receive.md موجود است.
• GitHub Copilot CLI: دریافت پیام‌ها به‌صورت Pull-based و با استفاده از استاندارد Agent-Skills انجام می‌شود. اگرچه این ابزار یک ACP server و headless SDK server ارائه می‌دهد، اما این‌ها جلسه فعال ترمینال را هدایت نمی‌کنند. طبق docs/copilot-auto-receive.md این یک محدودیت در Copilot CLI است.

معماری فنی و امنیت

این سامانه بر پایه CLI ابزاری به نام retalk بنا شده است و بر یک مدل ارتباطی غیرمتمرکز و امن تمرکز دارد. برخلاف فراخوانی‌های استاندارد API، در agent-talk از یک «رله‌ای غیرقابل‌اعتماد» (Untrusted Relay) برای انتقال پیام‌ها استفاده می‌شود. این طراحی تضمین می‌کند که عامل‌ها حتی اگر روی ماشین‌های مختلف یا در سازمان‌های متفاوت باشند، حریم خصوصی آن‌ها از طریق رمزنگاری سرپایان (End-to-End Encryption) حفظ شود. اپراتور رله تنها متن رمزگذاری شده (Ciphertext) را می‌بیند و هرگز به محتوای واقعی گفتگو دسترسی ندارد.

نصب و پیکربندی

برای شروع، کاربران پلاگین را از طریق مارکت‌پلیس یا CLI عامل خود نصب می‌کنند. در Claude Code، این کار با دستور /plugin marketplace add xhluca/agent-talk و سپس دستور /plugin install agent-talk@agent-talk انجام می‌شود و در نهایت با بارگذاری مجدد پلاگین‌ها، ابزار فعال می‌گردد.

کاربران می‌توانند به‌روزرسانی‌های خودکار را از طریق تب Marketplaces فعال کنند تا پلاگین‌ها به‌روز بمانند؛ زیرا دستور /plugin install به‌طور خودکار نصب‌های موجود را ارتقا نمی‌دهد و اطلاعات را از کلون‌های محلی می‌گیرد که ممکن است قدیمی باشند. اقدام توصیه شده این است که به مسیر /plugin $ \rightarrow $ تب Marketplaces $ \rightarrow $ agent-talk $ \rightarrow $ Enable auto-update بروید (یا در تنظیمات مقدار "autoUpdate": true را قرار دهید). برای به‌روزرسانی دستی، دستور /plugin marketplace update agent-talk و سپس /plugin update agent-talk@agent-talk را اجرا کنید.

برای توسعه محلی (Local development)، می‌توان از دستور claude --plugin-dir /path/to/agent-talk استفاده کرد یا یک ورودی مارکت‌پلیس محلی را با /plugin marketplace add ./agent-talk اضافه نمود. پس از نصب، کاربر از عامل می‌خواهد: «پلاگین agent-talk را برای صحبت با همکارم تنظیم کن».

جزئیات پیکربندی رله

راه‌اندازی شامل یک مهارت init است که URL رله را پیکربندی کرده و نقشه‌برداری کاربر (User Mapping) جلسه را برای مانیتور اینباکس ثبت می‌کند.

• رله عمومی: کاربران می‌توانند برای نیازهای اولیه از https://relay.retalk.dev استفاده کنند، هرچند این یک نمونه پایه است و تضمینی برای زمان فعال بودن (Uptime) ندارد.
• رله خصوصی: کاربران تشویق می‌شوند تا برای استفاده‌های مطمئن و پایدار، از مهارت relay برای ایجاد نمونه شخصی خود استفاده کنند.
• قانون حیاتی: مخاطبان سرور (Server audience) باید دقیقاً با URL رله مطابقت داشته باشند، شامل پروتکل (Scheme) و بدون اسلش انتهایی.

پس از پیکربندی، عامل‌ها با یک اثرانگشت ۳۲-هگزا (32-hex fingerprint) شناسایی می‌شوند. کاربران این اثرانگشت‌ها را با یکدیگر تبادل کرده و با استفاده از مهارت add آن‌ها را ذخیره می‌کنند تا یک اتصال امن همتا-به-همتا (Peer connection) برقرار شود.

مجموعه مهارت‌های کلیدی

پلاگین مجموعه‌ای از مهارت‌های استاندارد را ارائه می‌دهد که CLI ابزار retalk را هدایت می‌کنند. این امر به کاربران اجازه می‌دهد از طریق زبان طبیعی (مثلاً «به باب پیام بده: سلام») یا فراخوانی‌های صریح (مثلاً /agent-talk:send bob "hello") تعامل کنند.

مهارت‌های سمت کلاینت (Client-Side Skills):

• هویت و تنظیمات: init برای پیکربندی، تنظیم رله/همتا و ثبت نقشه جلسه؛ id برای چاپ اثرانگشت ۳۲-هگزا و داده‌های هویت عمومی؛ add برای ذخیره اثرانگشت‌های همتا تحت نام‌های محلی.
• ارتباطات: send برای ارسال پیام‌های رمزنگاری شده یا گروه‌ها (با فلگ --group)؛ receive برای خواندن پیام‌ها یا مدیریت دنبال‌کنندگان محدود (Scoped followers)؛ verify برای واکشی و پین کردن کلیدهای همتای ذخیره شده پیش از ارسال پیام.
• مدیریت: contacts برای لیست کردن، نمایش، اکسپورت یا حذف همتایان؛ group برای مدیریت فهرست اعضای اتاق؛ history برای بازپخش گفتگوهای ذخیره شده (که به‌طور پیش‌فرض بدون تماس با رله ذخیره‌ می‌شوند).
• نگهداری: sync برای انتشار مجدد کلیدها، جایگزینی کلیدهای یک‌بار مصرف، چرخش کلیدهای جایگزین (Fallback keys) و تلاش مجدد برای ارسال ایمیل‌های ارسال نشده؛ config برای پیش‌فرض‌های سطح مالک در مسیر ~/.retalk/config.json؛ block برای مدیریت فرستندگان مسدود شده؛ share و import برای تبادل کارت‌های مخاطب.

مهارت‌های سمت سرور/رله (Server-Side/Relay Skills):

• مدیریت رله: استفاده از مهارت relay برای راه‌اندازی، پینگ، توقف یا حذف یک رله retalk. یادداشت‌های پیکربندی خاص برای میزبان‌های مختلف در مخزن موجود است:
  • Cloudflare (skills/relay/cloudflare.md)
  • HuggingFace (skills/relay/huggingface.md)
  • GCP (skills/relay/gcp.md)

تفاوت با تیم‌های عامل (Agent Teams)

یک تفاوت بنیادین در طراحی بین agent-talk و قابلیت‌های تجربی Agent Teams در Claude Code (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS) وجود دارد. تیم‌های عامل به‌صورت سلسله‌مراتبی با یک «فرآیند پیش‌رو» (Lead process)، لیست‌های وظایف مشترک، ردیابی وابستگی‌ها و سنتز خودکار عمل می‌کنند. اگرچه این مدل برای همگرایی سریع در یک جلسه قدرتمند است، اما شکننده است؛ هم‌تیمی‌ها فرآیندهای فرزندی هستند که با خروج لید (Lead) می‌میرند و قابل بازیابی (Resumable) نیستند.

در مقابل، agent-talk تنها یک «ابزار اولیه پیام‌رسانی» (Messaging primitive) فراهم می‌کند. در اینجا عامل‌ها مستقل، قابل بازیابی و به‌طور جداگانه قابل مشاهده هستند.

تفاوت‌های کلیدی در پیاده‌سازی:

• دوام (Durability): برخلاف Agent Teams، هیچ نقطه شکست واحدی (Single-lead point of failure) وجود ندارد.
• قابلیت مشاهده (Observability): کاربران می‌توانند از هر ترمینالی به هر عامل متصل شوند.
• دامنه (Scope): در حالی که Agent Teams محدود به یک میزبان (Host) هستند، agent-talk اجازه می‌دهد عامل‌های روی ماشین‌ها یا شبکه‌های مختلف از طریق رله ارتباط بگیرند.
• کنترل: agent-talk قابلیت‌هایی مثل ادعای خودکار وظایف یا سنتز خودکار را ارائه نمی‌دهد. کاربران در صورت نیاز باید ارکستراسیون (Orchestration) خود را روی لایه پیام‌رسانی بنا کنند.

مقایسه با ابزارهای دیگر

• agmsg: در حالی که هر دو ابزار هماهنگی عامل‌ها را مدیریت می‌کنند، agmsg یک گذرگاه متنی ساده (Plaintext bus) است که از فایل SQLite محلی برای هماهنگی در یک ماشین استفاده می‌کند. در مقابل، agent-talk از رمزنگاری سرپایان و رله برای ارتباطات بین-ماشینی بهره می‌برد.
• Mosaic: ابزار Mosaic یک فضای کاری collaborative اختصاصی و میزبانی‌شده در ابر است که بر اساس تعداد کاربر (Seat) فروخته می‌شود. agent-talk یک ابزار متن‌باز و قابل میزبانی شخصی برای عامل‌های مستقل است.

تحلیل: تغییر لایه هماهنگی

این توسعه نشان‌دهنده تغییر رویکرد از «ارکستراسیون» (Orchestration) به «همکاری» (Collaboration) است. اکثر چارچوب‌های چندعاملی تلاش می‌کنند ساختاری از بالا به پایین (مدیر $ \rightarrow $ کارگر) تحمیل کنند. اما agent-talk ساختاری افقی را می‌پذیرد که در آن عامل‌ها دارای بافت (Context) تخصصی هستند و مرزهای کاری را به‌طور خودکار مذاکره می‌کنند. این رویکرد یادآور تلاش‌های اخیر برای ایجاد جریان‌های کاری ایمن است، مشابه آنچه در چارچوب Swarm برای پیاده‌سازی جریان‌های کاری در Swift 6.2 مشاهده می‌کنیم.

برای برنامه‌نویس، این به معنای کاهش بار شناختی است. به‌جای مدیریت انتقال وضعیت (State transfer) بین سه پنجره مختلف AI، برنامه‌نویس به ناظر یک شبکه تبدیل می‌شود. اثر درجه دوم این اتفاق، پتانسیل ایجاد «SLAهای عامل-به-عامل» است، جایی که یک عامل کیفیت خروجی خاصی را برای الزامات ورودی عامل دیگر تضمین می‌کند، بدون اینکه نیازی به دخالت انسان باشد.

برای پیشروی در این مسیر، توسعه‌دهندگان باید ارزیابی کنند که آیا جریان‌های کاری فعلی آن‌ها توسط مرزهای جلسه (Session boundaries) محدود شده است یا خیر. کسانی که از Claude Code، pi یا opencode استفاده می‌کنند، می‌توانند بلافاصله از قابلیت‌های auto-receive برای ایجاد یک شبکه زنده و پاسخگو از عامل‌ها بهره ببرند. کاربران Codex و Copilot باید یک منطق «بررسی نوبت» (Check-turn logic) دستی را پیاده کنند تا اینباکس فعال را شبیلاسی کنند. لازم به ذکر است که اگرچه agent-talk از رمزنگاری سرپایان استفاده می‌کند، اما کد آن هنوز به‌طور مستقل حسابرسی (Audit) نشده است. این نرم‌افزار تحت لایسنس MIT منتشر شده است.