کنترل از راه دور و موبایل
Control Center یک برنامهٔ رومیزی است، اما کاری که دنبال می‌کند با دور شدن شما از
میز متوقف نمی‌شود. کنترل از راه دور تلفن شما را با cc_serverتان جفت
می‌کند؛ با استفاده از Remote، برنامهٔ همراهی
که در remote.usectrl.dev قرار دارد، تا از همان‌جا ناوگان را دنبال کنید: پیام‌ها
و تیکت‌ها را بخوانید، به یک عامل پاسخ دهید، خوراک خبری‌تان را تریاژ کنید — بدون
آن‌که صدا، رونوشت، کد منبع یا اعتبارنامه‌هایی که روی سرور هستند، هرگز از آن بیرون
بروند.
آن را همراهی عمدتاً خواندنی برای تختهٔ فرمان در نظر بگیرید. قرار نیست جایگزین کلاینت کامل رومیزی شود.
انتقال
بخش با عنوان “انتقال”تلفن از راه یک WebSocket به cc_server می‌رسد: یا اتصالی مستقیم (loopback، LAN،
tailnet یا wss://) یا اتاقی دعوت‌محور روی یک کارگزار سیگنالینگ که فریم‌های
مهروموم‌شده را رله می‌کند. هیچ کانال دادهٔ همتا-به-همتا وجود ندارد.
تلفن چه کارهایی می‌تواند انجام دهد
بخش با عنوان “تلفن چه کارهایی می‌تواند انجام دهد”تلفن جفت‌شده به برش کوچک و تعمدی از سطح سرور دسترسی دارد:
- خواندن تیکت‌ها، عامل‌ها، فضاها و پیام‌هایشان و خوراک خبری شما
- پاسخ‌دادن: فرستادن پیام در یک فضا، به‌روزرسانی یا واگذاری یک تیکت، علامت‌زدن یک مقاله به‌عنوان خوانده‌شده یا ذخیره‌شده
- اجرای یک کتابچه: نمونه‌سازی یک قالب برنامهٔ ذخیره‌شده با پارامترهایش. این کار فقط یک برنامه را پیشنهاد می‌دهد؛ هیچ چیزی اجرا نمی‌شود و هزینه‌ای صرف نمی‌شود تا آن‌که یک اپراتور آن را در Plan Studio روی یک کلاینت کامل تأیید کند
- جابه‌جایی میان فضاهای کاری، از انتخابگر خود تلفن
تقریباً همین تمام ماجراست. تلفن یک موجودیتِ کم‌اولویت نسبت به یک کلاینت کامل است. نمی‌تواند فرایند بسازد، بودجهٔ LLM هزینه کند، به GitHub push کند یا فضای کاری بسازد. برای این‌که این محدودیت چگونه اعمال می‌شود و نه فقط قصد شده، مدل دسترسی را ببینید.
پیوند چگونه ساخته می‌شود
بخش با عنوان “پیوند چگونه ساخته می‌شود”اتصال سوار بر یک رلهٔ کارگزاری‌شده است: سرور به‌عنوان مالک به یک اتاق
دعوت‌محور روی کارگزاری wss:// می‌پیوندد و هر کلاینت جفت‌شده — رومیزی، وب،
تلفن — با یک توکن پذیرش زمان‌دار به همان اتاق می‌پیوندد. سه قطعه در هم می‌آیند:
| قطعه | نقش |
|---|---|
| Remote (برنامهٔ تلفن) | برنامهٔ وب همراه، که به‌طور پیش‌فرض در remote.usectrl.dev میزبانی می‌شود یا خودمیزبان است. در مرورگر بار می‌شود و رکورد جفت‌سازی را در IndexedDB نگه می‌دارد. |
| کارگزار رله | یک رلهٔ بی‌وضعیت wss:// (cc_signaling_server) که اتاق‌های Nطرفه را میزبانی می‌کند. فقط فریم‌های مات را حمل می‌کند: هر payload میان تلفن و سرور به‌صورت سرتاسری مهروموم می‌شود، پس کارگزار هرگز دادهٔ برنامه یا راز جفت‌سازی را نمی‌بیند و هرگز تفسیر نمی‌کند که چه چیزی را جلو می‌فرستد. |
cc_server |
مالک اتاق. تماس‌های تلفن را از همان dispatcherی پاسخ می‌دهد که هر کلاینت دیگر استفاده می‌کند. |
یک پیشنهاد جفت‌سازی حامل یک توصیفگر اتصال است که همهٔ مسیرها به سرور (LAN،
tailnet، wss:// عمومی، رله) به‌همراه اثر انگشت هویتش را فهرست می‌کند. resolver
تلفن بهترین مسیر قابل‌دسترس را برمی‌گزیند و اثر انگشت را در نخستین اتصال پین
می‌کند (TOFU)؛ رله حتی وقتی هیچ مسیر مستقیمی وجود ندارد اتصال را تضمین می‌کند،
بی‌آن‌که هرگز بتواند ترافیک را بخواند.
payload جفت‌سازی چیست
بخش با عنوان “payload جفت‌سازی چیست”جفت‌سازی از خود برنامه صادر می‌شود و به‌شکل یک پیوند عمیق تحویل داده می‌شود؛ برای رویهٔ کار جفت‌کردن دستگاه را ببینید. آنچه این‌جا مهم است، کالبد آن است.
https://<pwa-host>/#<payload>payload در قطعهٔ URL سوار می‌شود؛ همان بخش پس از # که مرورگرها هرگز آن را
به سرور نمی‌فرستند، پس میزبان HTTPS برنامهٔ PWA هرگز آن را نمی‌بیند. این payload
همهٔ چیزهایی را حمل می‌کند که تلفن برای رسیدن به سرور و اثبات هویتش لازم دارد:
توصیفگر اتصال (همهٔ مسیرها به‌همراه اثر انگشت هویت)، یک شناسهٔ دستگاه تازه‌صادرشده،
یک کلید از پیش به‌اشتراک‌گذاشته‌شدهٔ 32بایتی و یک مُهر انقضا. تلفن آن را
رمزگشایی می‌کند، یک رکورد جفت‌سازی را به‌صورت محلی ذخیره می‌کند و قطعه را حذف
می‌کند تا راز از URL بیرون برود.
دو شکل payload وجود دارد و این دو قابل تعویض نیستند. QR مخصوص تلفن که از پنل
جفت‌سازی درون‌برنامه‌ای صادر می‌شود، همان PairingPayload نسخهٔ v2 بالا است که به
میزبان PWA مربوط به Remote اشاره می‌کند. cc_server pair --client-url پیوند
متفاوت و قدیمی‌تری از نسخهٔ v1 منتشر می‌کند ({s, i, k} — نشانی سرور، شناسهٔ
دستگاه، کلید) که فقط برای کلاینت وب در نظر گرفته شده است.
این دو در طول عمر هم تفاوت دارند، نکته‌ای که به‌راحتی اشتباه گرفته می‌شود:
| صادرشده توسط | انقضای اعتبارنامه |
|---|---|
پنل جفت‌سازی درون‌برنامه‌ای (pairing.mint) |
30 روز، همیشه |
cc_server pair روی خط فرمان |
هیچ — اعتبارنامه منقضی نمی‌شود |
مدل دسترسی
بخش با عنوان “مدل دسترسی”یک دستگاه جفت‌شده احراز هویت شده است، اما مورد اعتماد نیست. چندین دروازهٔ مستقل نمی‌گذارند یک جفت‌سازی تأییدشده (یا لو رفته) به کنترل کامل سرور تبدیل شود.
1. مرز، عضویت است، نه جفت‌سازی
بخش با عنوان “1. مرز، عضویت است، نه جفت‌سازی”یک کلید جفت‌سازی معتبر ثابت می‌کند کدام دستگاه هستید. این‌که چه چیزی را می‌توانید بخوانید یا تغییر دهید، با نقش فضای کاری شما تعیین می‌شود که در هر فراخوانی از نو حل می‌شود، و برای هر چیزی که محتوای مخزن را آشکار می‌کند، با اعطای دسترسی به‌ازای هر مخزن. دستگاهی که کلیدی کاملاً معتبر دارد اما به کاربری تعلق دارد که عضو فضای کاری نام‌برده نیست، با پیام «Not a member of this workspace» رد می‌شود.
کفِ نقش از نوع خود عملیات گرفته می‌شود، مگر آن‌که عملیات نقشی برای خودش اعلام
کند: خواندن‌ها guest می‌خواهند، جهش‌ها member و عملیات مخرب admin.
2. تلفن یک ردهٔ نشستِ پایین‌تر است
بخش با عنوان “2. تلفن یک ردهٔ نشستِ پایین‌تر است”فراتر از بررسی نقش، یک نشست تلفن توانمندی کمتری از یک نشست رومیزی یا وب دارد. عملیاتی که فقط برای کلاینت کامل مجاز اعلام شده‌اند، پیش از اجرای handler برای تلفن رد می‌شوند، هر قدر هم کاربرِ پشت آن دارای امتیاز باشد: صدور، فهرست‌کردن، تغییر نام و لغو جفت‌سازی دستگاه‌ها؛ خواندن و تنظیم اتصال تونل؛ پشتیبان‌گیری سرور و برون‌بری/درون‌بری فضای کاری؛ تشخیص و کشتن فرایند؛ کاوش آداپتورها؛ تنظیمات سرور؛ مدیریت SSO؛ کنترل ناوگان؛ و در دست گرفتن یا بازگرداندن یک عامل در حال اجرا.
3. فهرست مجازِ ابزار با پیش‌فرضِ رد
بخش با عنوان “3. فهرست مجازِ ابزار با پیش‌فرضِ رد”به‌طور خاص برای سطح ابزار MCP (tools/call)، یک فهرست مجاز با پیش‌فرضِ رد تعیین
می‌کند تلفن چه ابزارهایی را می‌تواند فراخوانی کند. هر چیزی که در فهرست نباشد، پیش
از اجرا رد می‌شود. این فهرست بیشتر خواندن و مشاهده است، به‌همراه چند نوشتنِ
فقط‌محلی — یک پیام، یک به‌روزرسانی تیکت، یک نشانه روی یک مقاله — که بودجهٔ
LLM خرج نمی‌کنند، فرایندی نمی‌سازند و به هیچ سامانهٔ بیرونی دست نمی‌زنند.
برای نمونه رد می‌شوند: مشاوره گرفتن از یک عامل، شروع یک بازبینی هوش مصنوعی، کشتن یک عامل، انتشار یک بازبینی در GitHub، استخدام یا اخراج عامل‌ها و ساختن یک فضای کاری.
4. محدوده‌بندی فضای کاری به‌ازای هر فراخوانی
بخش با عنوان “4. محدوده‌بندی فضای کاری به‌ازای هر فراخوانی”سرور هیچ «فضای کاری جاری»ای نگه نمی‌دارد. طبق طراحی بی‌وضعیت است: هر
فراخوانیِ محدود به فضای کاری باید workspace_id هدفش را در آرگومان‌هایش نام
ببرد و dispatcher وقتی این شناسه غایب باشد یا فضای کاری‌ای را نام ببرد که سرور
ثبتش نکرده، فراخوانی را یکسره رد می‌کند — پیش از آن‌که چیزی پایگاه‌داده‌ای باز
کند. پس تلفن هرگز نمی‌تواند به محدودهٔ کلاینت دیگری ارث برسد یا به آن لغزش کند،
و نام‌بردن از یک فضای کاری بیگانه هم کمکی نمی‌کند، چون بررسی عضویت در دروازهٔ 1
همچنان اعمال می‌شود. این همان ایزوله‌سازی فضای کاری
ثابتی است که بقیهٔ محصول اعمال می‌کند.
5. فریم‌های مهروموم‌شدهٔ سرتاسری با کلید از پیش به‌اشتراک‌گذاشته‌شده
بخش با عنوان “5. فریم‌های مهروموم‌شدهٔ سرتاسری با کلید از پیش به‌اشتراک‌گذاشته‌شده”هر فریم میان تلفن و سرور با کلید جفت‌سازی مهروموم می‌شود؛ توکن پذیرش فقط یک کلاینت را به اتاق می‌آورد و هیچ چیزی را رمزگشایی نمی‌کند. کارگزار فقط متن رمزشده را رله می‌کند و هرگز کلید را نمی‌بیند. دستگاهی که لغو شده، می‌بیند که اعتبارنامه‌اش از قبل رفته است، پس در اتصال دوباره به‌صورت ایمن شکست می‌خورد.
اعتبارنامه‌ای که برنامه صادر می‌کند تا 30 روز زمان‌دار است؛ پس از آن، دروازهٔ اتصال آن را رد می‌کند و تلفن باید دوباره جفت شود. لغو شدن زنده است: سرور جدول دستگاه‌ها را می‌پاید و نشست‌های باز یک دستگاه لغوشده را در چند ثانیه می‌بندد، نه این‌که منتظر اتصال بعدی‌اش بماند.
6. محدودسازی نرخ به‌ازای هر موجودیت
بخش با عنوان “6. محدودسازی نرخ به‌ازای هر موجودیت”یک محدودکنندهٔ پنجرهٔ لغزان ترافیک ابزار از راه دور را روی 120 فراخوانی در دقیقه سقف می‌گذارد، با یک سقف فرعی سخت‌گیرانه‌تر 30 در دقیقه برای افعال تغییردهنده. این سهمیه به موجودیت تعلق دارد، نه به نشست: سه دستگاه شما از یک اعتبار برداشت می‌کنند، پس یک کلاینت ربوده‌شده نمی‌تواند با باز کردن نشست‌های بیشتر فضای اضافی بخرد و یک عضو پرصدا نمی‌تواند بقیه را از سهمیه محروم کند.
7. کارگزاری که چیزی یاد نمی‌گیرد
بخش با عنوان “7. کارگزاری که چیزی یاد نمی‌گیرد”کارگزار رله عمداً ساده نگه داشته شده است: اتاق‌ها را میزبانی می‌کند، فریم‌های مهروموم‌شده را جلو می‌فرستد و هیچ حساب، هیچ دادهٔ برنامه‌ای و هیچ کلیدی نگه نمی‌دارد. اتاق‌ها دعوت‌محور و گذرا هستند. دادهٔ برنامه، صدا، رونوشت، منبع و اعتبارنامه‌ها همگی روی سرور می‌مانند.
به‌روزرسانی‌های زنده
بخش با عنوان “به‌روزرسانی‌های زنده”پس از جفت شدن، تلفن به‌روزرسانی‌های زنده را به‌شکل فریم‌های اعلان دریافت می‌کند — پیام‌های تازهٔ عامل‌ها، تیکت‌های واگذارشده به شما، تغییرهای وضعیت — درست مانند اعلان‌های خودِ رومیزی. سرور این فریم‌ها را برای هر نشست متصل پخش می‌کند و فیلتر فضای کاری در سمت کلاینت اعمال می‌شود، پس آنچه می‌بینید محدود به فضای کاری‌ای است که به آن نگاه می‌کنید.
کجا پیدایش می‌کنید
بخش با عنوان “کجا پیدایش می‌کنید”| نما | چه چیزی نشان می‌دهد |
|---|---|
تنظیمات ← شما ← دستگاه‌های شما (/workspaces/:workspaceId/settings/you/devices) |
کلاینت‌های جفت‌شده با وضعیت زنده، به‌همراه جفت‌سازی کلاینت جدید (مرورگر وب، برنامهٔ رومیزی یا تلفن) و لغو |
همین پنل برای مرورگر یا برنامهٔ رومیزی دومی هم جفت‌سازی صادر می‌کند، نه فقط برای تلفن‌ها — جریان کار یکسان است و تنها پیوند عمیق تفاوت دارد.
همچنین ببینید
بخش با عنوان “همچنین ببینید”- فضاهای کاری و ایزوله‌سازی: محدوده‌بندی به‌ازای هر فراخوانی که این کنترل بر آن تکیه دارد
- چندنفره — هویت، عضویت و حضور: نقش‌ها، عضویت و اعطای دسترسی مخزن
- استقرار و کلاینت‌ها: جایگاه کنترل از راه دور میان رده‌های کلاینت
- معماری: جایگاه کنترل از راه دور در پشته
- جفت‌کردن دستگاه