Bỏ qua để đến nội dung

Cài đặt

Control Center chạy theo hai cách: dưới dạng ứng dụng web tại app.usectrl.dev, không phải tải xuống gì, hoặc dưới dạng ứng dụng desktop mà bạn cài đặt. Chúng là cùng một ứng dụng với cùng tính năng. Khác biệt duy nhất là nơi máy chủ chạy — và ứng dụng web không thể chạy máy chủ thay bạn.

app.usectrl.dev là chính ứng dụng này được biên dịch cho trình duyệt. Không phải cài đặt, không phải cập nhật. Mở lên và kết nối.

Điều mà một tab trình duyệt không thể làm là trở thành máy chủ. Mọi máy khách — desktop, web, điện thoại — đều chỉ là một lớp hiển thị mỏng trên một cc_server không giao diện, thứ sở hữu cơ sở dữ liệu và làm mọi công việc, nên ứng dụng web luôn nói chuyện với một máy chủ do bạn chạy. Có hai cách để cung cấp máy chủ cho nó:

Máy chủ trên chính máy của bạn. Khởi động cc_server cục bộ và trỏ ứng dụng web tới ws://localhost:9030. Trình duyệt coi localhost là đáng tin cậy, nên cách này không cần chứng chỉ và không cần đường hầm. Đây là cách nhanh nhất để thử ứng dụng web và dữ liệu của bạn không bao giờ rời khỏi máy.

Máy chủ trên một máy khác. Vì app.usectrl.dev được phục vụ qua HTTPS, một máy chủ không cục bộ phải truy cập được qua wss:// với chứng chỉ mà trình duyệt đã tin cậy. cc_server từ chối bind một địa chỉ không phải loopback khi không có TLS, nên hãy chọn một trong các cách sau:

  • cấp chứng chỉ trực tiếp cho nó, bằng --tls-cert và --tls-key
  • đặt nó sau một reverse proxy kết thúc TLS và khởi động nó với --insecure
  • đưa nó ra ngoài qua một đường hầm hoặc VPN cung cấp chứng chỉ — Tailscale, cloudflared hoặc tương tự. Cài đặt → Máy chủ → Kết nối & trạng thái có tùy chọn bật đường hầm tích hợp nằm dưới Chia sẻ máy chủ này.

Mỗi khi máy chủ nằm sau proxy, NAT hoặc đường hầm, hãy đặt --public-url thành địa chỉ mà máy khách thực sự cần gọi. Nó mặc định theo bind cục bộ, nên nếu không đặt, máy khách sẽ thử nhầm máy chủ.

Một vài thứ vẫn chỉ có trên desktop, vì chúng cần một cửa sổ native hoặc chính các thiết bị âm thanh của máy: viên nổi chế độ tập trung, thông báo nổi của hệ điều hành (trung tâm thông báo trong ứng dụng hoạt động ở mọi nơi), “bắt đầu ghi & liên kết” từ một sự kiện lịch, và chạy lại bản tóm tắt cuộc họp. Mọi thứ còn lại — space, agent, rà soát pull request, quy trình, phiếu, bộ nhớ và chính việc ghi cuộc họp — đều hoạt động như nhau.

Để kết nối ứng dụng web với một máy chủ, hãy làm theo Kết nối máy chủ từ xa. Để tự lưu trữ máy chủ, hãy làm theo Chạy máy chủ không giao diện.

Yêu cầu macOS Windows Linux
Phiên bản hệ điều hành macOS 13+ (Ventura) Windows 10+ Ubuntu 22.04+ hoặc bản phân phối khác có glibc 2.35+ và GTK 3
Kiến trúc Apple Silicon (arm64) x64, ARM64 x86_64
Git Bắt buộc Bắt buộc Bắt buộc
Dung lượng đĩa ~200 MB cho ứng dụng, cộng thêm thư mục dữ liệu của máy chủ ~200 MB ~200 MB

Máy Mac Intel không có bản tải xuống dựng sẵn. Hãy xây dựng từ mã nguồn.

Thư mục dữ liệu của máy chủ lớn hơn nhiều so với ứng dụng. Ở lần khởi động đầu tiên, cc_server bắt buộc cài đặt các mô hình trên thiết bị — embedding văn bản (~90 MB), phân tách người nói (~35 MB) và mô hình giọng nói đã chọn (mặc định là Parakeet TDT v3, ~600 MB; các biến thể Whisper từ 198–626 MB) — cùng một bản dựng code-server nhúng, và mỗi cuộc hội thoại agent nhận một worktree copy-on-write của các kho mã mà nó làm việc trên đó (git worktree thuần trên Windows). Giọng nói không phải tùy chọn: nếu không có mô hình ASR, các tác vụ họp và đọc chính tả sẽ không được phục vụ. Lần tải xuống mô hình giọng nói đầu tiên vẫn cần một lần khởi động lại trước khi tính năng ghi hoạt động.

Ứng dụng desktop trỏ máy chủ của nó tới thư mục hỗ trợ ứng dụng theo từng người dùng của hệ điều hành. Một cc_server khởi động thủ công mà không có --data-dir sẽ mặc định dùng <application data>/control-center — ~/Library/Application Support/control-center trên macOS, %APPDATA%\control-center trên Windows, $XDG_DATA_HOME/control-center (hoặc ~/.local/share/control-center) trên Linux.

Mọi tệp phát hành bên dưới đều đến từ GitHub Releases.

Tải Control-Center-<version>-arm64.dmg, mở nó và kéo Control Center vào Applications. Bản dựng được ký bằng một Developer ID và được Apple công chứng, nên nó mở bình thường.

  • Control-Center-<version>-x64-setup.exe: trình cài đặt theo từng người dùng.
  • Control-Center-<version>-windows-x64.zip: tệp zip di động.
  • Control-Center-<version>-arm64-setup.exe: trình cài đặt theo từng người dùng.
  • Control-Center-<version>-windows-arm64.zip: tệp zip di động.

Windows dùng git worktree cho các bản checkout của space (không có copy-on-write).

  • Control-Center-<version>-x86_64.AppImage
  • Control-Center-<version>-linux-x64.tar.gz

AppImage mang theo thông tin cập nhật, nên AppImageUpdate hoặc appimaged có thể đưa nó lên bản phát hành mới nhất ngay tại chỗ, chỉ tải xuống những gì đã thay đổi.

Cả hai đều được dựng trên Ubuntu 22.04 và chạy trên nó hoặc bất kỳ bản nào mới hơn (Debian 12, Fedora 36 trở lên): chúng liên kết với glibc 2.35 và libstdc++ của GCC 12, đồng thời lấy GTK 3 từ hệ thống. Vài thư viện mà một bản desktop tiêu chuẩn có thể thiếu thì đi kèm bên trong chúng, nên không cần cài thêm gì. Âm thanh — phát lại cuộc họp, soundscape, âm thanh rig và âm báo thông báo — phát qua libmpv của hệ thống (libmpv1 trên Ubuntu 22.04, libmpv2 trên Ubuntu và Debian mới hơn, mpv-libs trên Fedora); nếu không có nó, ứng dụng khởi động với các điều khiển đó bị ẩn.

Mỗi bản phát hành cũng mang theo máy chủ không giao diện riêng — cc_server-<version>-macos-arm64.tar.gz, cc_server-<version>-linux-x64.tar.gz, cc_server-<version>-windows-x64.zip, cc_server-<version>-windows-arm64.zip — cùng với các ảnh cc-server, cc-webapp và cc-remote trên GHCR. Xem Chạy máy chủ không giao diện.

Bản lưu trữ Linux được dựng trên Ubuntu 22.04 và các thư viện native đi kèm của nó liên kết với glibc 2.35 và libstdc++ của GCC 12, nên nó cần một máy chủ ít nhất mới như vậy (Ubuntu 22.04, Debian 12, Fedora 36 trở lên). Trên một bản phân phối cũ hơn, hãy chạy ảnh cc-server thay thế — container mang theo userland của riêng nó, nên chỉ có kernel là phải của bạn.

Control Center điều phối agent thông qua adapter. Có hai adapter, danh sách này cố định và chúng được phát hiện tự động — không có cách nào đăng ký thêm một cái nữa.

Adapter Control Center (tích hợp sẵn) không cần CLI bên ngoài: vòng lặp agent chạy bên trong máy chủ và nói chuyện với các nhà cung cấp mô hình qua HTTP, nên nó luôn sẵn có. Kết nối một nhà cung cấp trong Cài đặt → Máy chủ → Nhà cung cấp mô hình. OpenAI, Codex, Cursor và Kimi Code cho phép đăng nhập qua trình duyệt; Anthropic, OpenRouter, Google Gemini, DeepSeek, Mistral, xAI, z.ai và Moonshot nhận khóa API. Codex và Cursor là các nhà cung cấp trên runner này, không phải CLI riêng. z.ai được liệt kê hai lần là có chủ đích: z.ai là nền tảng mở trả theo mức dùng, tính vào số dư tài khoản của bạn, còn z.ai GLM Coding Plan là gói đăng ký. Đó là cùng một khóa tài khoản, nhưng z.ai phục vụ gói này từ một host khác — dán khóa của gói lập trình vào ô z.ai thường thì mọi yêu cầu đều trả về 429 … "Insufficient balance or no resource package", vì gói này không có số dư để tiêu. Gói đăng ký Claude Pro/Max không phải là đăng nhập API Anthropic; thay vào đó hãy dùng gói đó qua adapter Claude Code. Thứ bạn có thể thêm trên trang đó là một nhà cung cấp tùy chỉnh — bất kỳ endpoint tương thích OpenAI hoặc Anthropic nào (Ollama, LM Studio, vLLM, một triển khai riêng) trong Nhà cung cấp tùy chỉnh → Thêm nhà cung cấp.

Adapter còn lại bao bọc một CLI bên ngoài:

  • Claude Code (claude): npm install -g @anthropic-ai/claude-code

Việc phát hiện thăm dò PATH của máy đang chạy cc_server — chính máy đó khi ứng dụng desktop tự chạy máy chủ của nó, còn nếu không thì là máy chủ từ xa. Hãy cài CLI Claude Code ở đó, không phải trên máy khách. Nút Làm mới trên trang đó sẽ chạy lại thăm dò.

Danh sách mô hình được phục vụ trực tiếp bởi từng nhà cung cấp đã kết nối; models.dev chỉ cung cấp siêu dữ liệu về giá và cửa sổ ngữ cảnh. Xem Quản lý adapter và mô hình.

Thông tin xác thực GitHub là của bạn và nằm trên máy chủ, được đánh khóa theo id người dùng của bạn — không nằm trong keychain của hệ điều hành máy khách. Mọi thiết bị bạn đăng nhập đều dùng cùng một thông tin xác thực, và không thành viên nào khác đọc được nó.

Nếu máy chủ có đăng ký một GitHub App (Tạo GitHub App), Cài đặt → Không gian làm việc → Hồ sơ & danh tính → Lưu trữ mã có Đăng nhập với GitHub (một luồng thiết bị do máy chủ thực hiện). Nếu không, hãy dán một token truy cập cá nhân:

  • Loại Classic: repo và read:org
  • Loại Fine-grained: Contents và Pull requests (đọc và ghi), Checks và Actions (đọc)

Tạo một token tại GitHub → Settings → Developer settings → Personal access tokens. Máy chủ thăm dò token để lấy tên tài khoản ngay khi nó được lưu, nên hàng đó có thể ghi “đã đăng nhập với tên …”; một thăm dò thất bại vẫn lưu token, và một lỗi đánh máy hay thiếu quyền sẽ hiện ra dưới dạng một yêu cầu thất bại sau này.

Bước đầu tiên của quá trình thiết lập ban đầu là kết nối này. Sau đó, chính thẻ đó là nơi bạn thay thế hoặc xóa nó. GitLab và Bitbucket dùng cùng thẻ đó; xem Kết nối máy chủ mã.

Control Center là một máy khách mỏng trên một tiến trình cc_server không giao diện, thứ sở hữu cơ sở dữ liệu và làm mọi công việc; Triển khai và máy khách giải thích ý nghĩa của sự tách biệt đó đối với desktop, web và điện thoại.

Ở lần khởi chạy đầu tiên, ứng dụng desktop hỏi “Control Center nên chạy như thế nào?”:

  • Chạy trong ứng dụng này: ứng dụng desktop khởi tạo và giám sát một cc_server trên máy này rồi nói chuyện với nó qua loopback. Không cần cấu hình gì thêm. Đây là thiết lập mà bắt đầu nhanh giả định.
  • Kết nối tới một phiên bản từ xa: trỏ ứng dụng desktop tới một cc_server đang chạy ở nơi khác bằng URL WebSocket của nó, một id thiết bị, và hoặc một khóa ghép nối hoặc một mã mời dùng một lần. Máy chủ đó sở hữu dữ liệu; desktop này chỉ hiển thị nó.

Thêm hoặc chuyển đổi máy chủ sau này trong Cài đặt → Máy chủ → Kết nối & trạng thái. Việc chuyển đổi kết nối lại ngay tại chỗ — không cần khởi động lại. Trình duyệt không thể chạy máy chủ, nên máy khách web luôn là từ xa; xem Kết nối máy chủ từ xa.

Để tự lưu trữ một máy chủ, hãy làm theo Chạy máy chủ không giao diện. Trang đó đề cập đến việc dựng tệp nhị phân, tạo khóa ghép nối trước lần khởi động đầu tiên, và các cờ --data-dir / --port / --bind.

  1. Cài đặt → Máy chủ → Nhà cung cấp mô hình liệt kê cả hai adapter. “Control Center (tích hợp sẵn)” hiển thị là đã tìm thấy với phiên bản built-in; Claude Code hiển thị là đã tìm thấy nếu CLI của nó nằm trên PATH của máy chủ. Nhấn Làm mới nếu nó bị thiếu.
  2. Cài đặt → Không gian làm việc → Kho lưu trữ liệt kê các kho mã của không gian làm việc này, và Thêm kho lưu trữ duyệt các thư mục của máy chủ.
  3. Cài đặt → Không gian làm việc → Agent liệt kê năm agent mà không gian làm việc đầu tiên của bạn tạo sẵn. Mỗi agent cần được đặt Bộ điều hợp và Mô hình trước khi có thể chạy.
  4. Cài đặt → Máy chủ → Chẩn đoán & quyền riêng tư báo cáo các backend sandbox mà máy chủ này cung cấp, trạng thái của mô hình embedding, và việc ghi nhật ký.

Các thư viện native là bắt buộc và không có chế độ suy giảm: thiếu một thư viện là lỗi khởi động cứng, không phải một đường chậm hơn. Hãy chuẩn bị chúng trước mọi thứ khác. Mọi lệnh Flutter và Dart đều đi qua fvm, vì phiên bản SDK được kho mã ghim cố định.

Cửa sổ terminal
git clone https://github.com/SamuelAlev/control-center.git
cd control-center
scripts/natives/build_natives.sh
fvm flutter pub get
fvm flutter pub run build_runner build --delete-conflicting-outputs
fvm flutter gen-l10n
fvm flutter run -d macos # or -d windows, -d linux

Trên macOS, kho lưu trữ bảo mật (đăng nhập GitHub, Linear và Google) cần ứng dụng được ký bởi một nhóm Apple — một Apple ID miễn phí là đủ, và đây là thiết lập một lần được mô tả trong local development signing. Nếu không có nó, ứng dụng vẫn khởi chạy; chỉ kho lưu trữ bảo mật là không khả dụng. Windows và Linux không cần ký.

Để dựng tệp nhị phân máy chủ không giao diện, hãy chuẩn bị native theo cùng cách trước, rồi:

Cửa sổ terminal
cd apps/cc_server
fvm dart build cli

Hook của bản dựng sao chép mọi thứ đã có trong build/natives/ vào gói, nên dựng trước khi chuẩn bị sẽ tạo ra một gói không có native và một máy chủ từ chối khởi động.

Với máy khách web, hãy dùng scripts/build_web.sh (--target remote cho PWA trên điện thoại). Đây là thứ CI chạy: lệnh flutter build web thông thường bỏ qua dấu nhận diện bản dựng, việc tạo lại Web Worker, manifest triển khai và kiểm tra ngân sách tài nguyên.