Tự host Open Connector cho AI agent trên VPS

Open Connector làm gì cho một AI agent

Tự host Open Connector giúp bạn đặt một auth gateway giữa các AI agent và mọi API SaaS mà chúng gọi, nhờ đó agent không bao giờ nắm giữ token của nhà cung cấp. Đây là một gateway dạng source-available từ OOMOL Lab, hiện đang được cấp phép theo giấy phép Apache 2.0 đã sửa đổi với các điều kiện bổ sung. Các bản release đến v1.9.4 vẫn giữ nguyên Apache 2.0; v1.9.5 đã giới thiệu thay đổi này. Việc cung cấp dịch vụ hosted hoặc managed có giá trị cốt lõi là chức năng của OpenConnector yêu cầu giấy phép thương mại từ OOMOL. Nó chạy dưới dạng một container, lưu trạng thái trong một file SQLite duy nhất và phơi bày các action của nhà cung cấp qua HTTP và MCP (model context protocol).

Khó khăn bắt đầu từ lần tích hợp thứ hai. Mỗi nhà cung cấp có flow OAuth (open authorization) riêng, thời hạn refresh token riêng và tên scope riêng. Việc tự tay kết nối năm nhà cung cấp vào một agent đồng nghĩa với năm trình xử lý redirect, năm kho lưu trữ credential và năm vòng lặp refresh phải chạy trước khi token hết hạn. Hầu như không ai tự viết code đó. Họ tạo ra một personal access token có thời hạn dài cho mỗi dịch vụ rồi dán nó vào cấu hình agent, file môi trường hoặc chính trong prompt. Token đó sau đó có thể bị đọc bởi mọi công cụ mà agent chạy, và nó sẽ nằm trong transcript, dẫn đến lỗi mà giữ bí mật không để lộ trong AI agents đã mô tả.

Một auth gateway chia credential thành hai phần. Gateway lưu trữ credential của nhà cung cấp và chạy flow OAuth. Agent nhận được một runtime token chỉ có giá trị đối với gateway. Khi agent gọi một action, gateway sẽ tải credential đã lưu, chèn nó vào request gửi đi ở phía server và chỉ trả về phần body của response. Agent không bao giờ nhận được access token của nhà cung cấp, vì vậy nếu transcript của agent bị lộ, bạn chỉ mất một runtime token có thể thu hồi thay vì mất quyền truy cập vào tài khoản GitHub của mình.

Danh mục của dự án quảng cáo hơn 1.000 nhà cung cấp và 10.000 action được xây dựng sẵn, đây là con số do chính dự án đưa ra và không phải thứ bạn có thể xác minh từ bên ngoài. Điều bạn có thể xác minh là cấu trúc: một HTTP endpoint cho mỗi action, một kết nối được lưu trữ cho mỗi nhà cung cấp, một token cho mỗi agent. Nếu phía agent vẫn còn mới mẻ và các thuật ngữ như tool call hoặc MCP server vẫn chưa ổn định, lộ trình từng bước trong cách học AI agents từ con số 0 sẽ giúp bạn xây dựng vòng lặp, các công cụ và thói quen an toàn mà một gateway như thế này mặc định là bạn đã có sẵn.

Tại sao nên tự host Open Connector thay vì dùng dịch vụ connector được quản lý

Một dịch vụ connector được quản lý thực hiện công việc tương tự và nó lưu trữ các refresh token cho mọi nhà cung cấp mà bạn kết nối. Một refresh token cho Google hoặc GitHub là một khóa có thời hạn dài để truy cập vào email và các kho lưu trữ của bạn. Khi hệ thống của họ bị breach, dữ liệu của bạn cũng bị breach theo. Việc tự host sẽ chuyển các bản ghi đó vào SQLite trên máy chủ mà bạn thuê và quản trị, được bảo vệ bằng một khóa không bao giờ rời khỏi máy chủ của bạn.

Hãy cân nhắc kỹ chi phí trước khi bắt đầu. VPS này sẽ trở thành máy chủ quan trọng nhất mà bạn vận hành. Nó chứa thông tin xác thực đang hoạt động cho hàng tá dịch vụ trong một file duy nhất, vì vậy nó cần được đối xử như một máy chủ quản lý mật khẩu: một firewall chỉ mở cổng 443, không dùng chung tài khoản đăng nhập, có bản backup mà bạn đã thực sự khôi phục thành công ít nhất một lần, và có cảnh báo khi nó ngừng phản hồi. Nếu bạn không đặt kho lưu trữ mật khẩu của mình trên máy chủ này, thì cũng đừng đặt connector trên đó.

Ghim phiên bản trước khi cài đặt bất cứ thứ gì

Open Connector còn khá mới. Hướng dẫn này ghim phiên bản v1.3.3, được phát hành vào ngày 30 tháng 7 năm 2026, làm snapshot cài đặt cho ngày 1 tháng 8 năm 2026. Đây không còn là bản release mới nhất nữa. Registry cũng xuất bản một tag tip, được build từ commit mới nhất trên main.

Đối với một dự án mới như thế này, các tag thay đổi liên tục. Một docker compose pull nhảy vọt qua hai bản release có thể làm thay đổi endpoint mà agent của bạn đang phụ thuộc, và bạn sẽ mất cả buổi tối để debug vì tưởng đó là lỗi của agent. Hãy ghim image vào một tag release cụ thể và chỉ nâng cấp khi bạn đã sẵn sàng, sau khi đã đọc kỹ release notes.

Triển khai Open Connector sau TLS trên VPS của bạn

Trước khi container khởi động, bạn cần:

• Docker Engine 28.0.0 trở lên kèm plugin Compose, chạy trên Ubuntu 24.04 hoặc hệ điều hành tương đương.
• Một hostname có bản ghi A trỏ về VPS này, ví dụ connect.example.com.
• Một reverse proxy đã thực hiện TLS termination (transport layer security) cho hostname đó.
• Hai chuỗi bí mật ngẫu nhiên, được tạo bên dưới.

Bài viết Traefik reverse proxy cho nhiều ứng dụng Docker Compose hướng dẫn về phía proxy. Các bước thiết lập chứng chỉ hoàn chỉnh cho một ứng dụng đơn lẻ nằm trong hướng dẫn n8n trên VPS với Docker và HTTPS.

Hãy tạo các chuỗi bí mật trước. Encryption key dùng để mã hóa các thông tin xác thực được lưu trữ. Admin token bảo vệ giao diện web và toàn bộ bề mặt /api. Cả hai không có giá trị mặc định, và runtime vẫn sẽ khởi động dù bạn không thiết lập chúng.

mkdir -p ~/open-connector && cd ~/open-connector
umask 077
printf 'OOMOL_CONNECT_ENCRYPTION_KEY=%s\n' "$(openssl rand -base64 32)" > .env
printf 'OOMOL_CONNECT_ADMIN_TOKEN=%s\n' "$(openssl rand -base64 32)" >> .env
chmod 600 .env

Hãy sao chép cả hai giá trị vào trình quản lý mật khẩu của bạn ngay bây giờ, trước lần khởi động đầu tiên. Encryption key không có cơ chế khôi phục, lý do nằm trong danh sách các lỗi bên dưới.

Bây giờ là compose.yaml. File này khác với ví dụ gốc ở hai điểm, và cả hai đều quan trọng.

services:
  connector:
    image: ghcr.io/oomol-lab/open-connector:v1.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - connector-data:/app/data
    environment:
      OOMOL_CONNECT_DATA_DIR: /app/data
      OOMOL_CONNECT_ORIGIN: "https://connect.example.com"
      OOMOL_CONNECT_ENCRYPTION_KEY: "${OOMOL_CONNECT_ENCRYPTION_KEY:?set this in .env}"
      OOMOL_CONNECT_ADMIN_TOKEN: "${OOMOL_CONNECT_ADMIN_TOKEN:?set this in .env}"

volumes:
  connector-data:

Thay đổi đầu tiên là sử dụng tag cố định thay vì latest. Thay đổi thứ hai là cổng. File gốc publish 3000:3000, vốn bind vào mọi interface trên host. Docker ghi các cổng đã publish vào bảng NAT (network address translation) trước khi chuỗi filter của ufw kịp xử lý gói tin, vì vậy ufw deny 3000 không đóng cổng đó được, đây là cái bẫy được mô tả trong tại sao các cổng Docker bỏ qua ufw. Việc ghi 127.0.0.1:3000:3000 chỉ publish trên interface loopback, và reverse proxy của bạn kết nối từ chính host đó. Trước Docker Engine 28.0.0, các host trên cùng phân đoạn L2 có thể truy cập các cổng publish ra localhost, đó là lý do hướng dẫn này yêu cầu phiên bản 28.0.0 trở lên.

:? đánh dấu mỗi biến là bắt buộc, vì vậy stack sẽ từ chối khởi động khi thiếu .env thay vì khởi động với thông tin xác thực không được mã hóa. Việc lưu các giá trị trong .env thay vì trong file compose là mô hình từ Docker Compose env files và secrets. Hãy giữ /v1 và /mcp ở chế độ riêng tư tại reverse proxy cho đến khi bạn tạo được token runtime đầu tiên bên dưới.

docker compose up -d
docker compose logs -n 30 connector
curl -s http://127.0.0.1:3000/health
sudo ss -tlnp | grep 3000

/health sẽ trả lời { "ok": true } sau khi runtime đã sẵn sàng. ss phải in ra 127.0.0.1:3000. Một dòng hiển thị 0.0.0.0:3000 nghĩa là listener đã bind vào mọi interface IPv4, nhưng không chứng minh được khả năng truy cập từ internet: các firewall phía trước hoặc các quy tắc trong chuỗi DOCKER-USER của Docker vẫn có thể chặn lưu lượng bên ngoài. Lỗi Connection refused khi kiểm tra health check nghĩa là container chưa lắng nghe, vì vậy hãy đọc log trước khi can thiệp vào proxy.

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.connector.rule=Host(`connect.example.com`)"
      - "traefik.http.routers.connector.entrypoints=websecure"
      - "traefik.http.routers.connector.tls.certresolver=le"
      - "traefik.http.services.connector.loadbalancer.server.port=3000"

Tại sao OAuth callback cần origin chính xác

OOMOL_CONNECT_ORIGIN là thiết lập mà mọi người thường bỏ qua, và việc bỏ qua nó làm hỏng OAuth theo cách trông giống như lỗi của nhà cung cấp. Runtime tự xây dựng redirect URI từ origin đó, dưới dạng <origin>/oauth/callback. Nếu để trống, origin mặc định là http://localhost:3000, vì vậy runtime gửi cho nhà cung cấp một redirect URI là http://localhost:3000/oauth/callback trong khi ứng dụng OAuth của bạn đã đăng ký https://connect.example.com/oauth/callback. Hai chuỗi này khác nhau, nên GitHub trả về lỗi:

The redirect_uri MUST match the registered callback URL for this application.

Nhà cung cấp OAuth chuyển hướng trình duyệt quay lại URI đó, vì vậy địa chỉ phải truy cập được từ trình duyệt. OAuth không yêu cầu bắt buộc phải có hostname công khai: OpenConnector ghi nhận các callback của GitHub tại http://localhost:3000/oauth/callback. Triển khai VPS này sử dụng hostname và chứng chỉ để trình duyệt truy cập gateway tại origin HTTPS của nó. Hãy thiết lập origin trước lần khởi động đầu tiên, vì giá trị này được đọc lúc khởi động: sau khi chỉnh sửa .env hoặc compose.yaml, hãy chạy lại docker compose up -d để áp dụng thay đổi.

Kết nối provider đầu tiên qua OAuth

Trước tiên, tạo OAuth app trên provider. Trên GitHub, vào Settings, rồi Developer settings, rồi OAuth Apps, rồi New OAuth App. Đặt authorization callback URL thành https://connect.example.com/oauth/callback. Lưu client ID và client secret.

Mỗi lệnh gọi /api đều gửi kèm admin token, vì vậy hãy export token một lần cho shell session.

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

Danh sách này hiển thị redirect URI mà runtime cần cho từng provider. Đây là cách nhanh nhất để kiểm tra origin đã được áp dụng chưa. Nếu vẫn hiển thị localhost, container đang chạy với giá trị cũ và OAuth flow sẽ fail ở bước cuối.

Lưu client credentials, rồi bắt đầu authorization.

curl -s -X PUT https://connect.example.com/api/oauth/configs/github \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"clientId":"...","clientSecret":"..."}'

curl -s -X POST https://connect.example.com/api/oauth/authorizations \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"service":"github"}'

Lệnh gọi thứ hai trả về một authorizationUrl. Mở nó trong browser, chấp thuận các scope, rồi provider sẽ đưa browser quay lại /oauth/callback. Tại đó, runtime exchange code và lưu credential. Web console tại origin của bạn cũng thực hiện cùng các bước này qua một form, sử dụng cùng admin token. Provider dùng plain API key thì bỏ qua toàn bộ quy trình này: PUT /api/connections/<service> với {"authType":"api_key","values":{"apiKey":"..."}} sẽ lưu trực tiếp key.

Cấp cho mỗi agent một runtime token, tuyệt đối không dùng credential

Agent xác thực với gateway bằng runtime token, loại token này được tạo ra từ admin API.

curl -s -X POST https://connect.example.com/api/runtime-tokens \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"name":"research-agent"}'

Phản hồi chứa một token bắt đầu bằng oct_. Hãy cấp một token cho mỗi agent và đặt tên theo agent đó, vì nếu bạn thu hồi một token mà không xác định được nó thuộc về ai, bạn sẽ phải thu hồi tất cả. Sau đó, agent sẽ gọi các hành động thông qua HTTP thông thường.

curl -s -X POST https://connect.example.com/v1/actions/github.get_current_user \
  -H "authorization: Bearer oct_..." \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Một phản hồi hợp lệ là một envelope có trường success là true, với payload của provider nằm dưới data. GitHub token không xuất hiện ở bất kỳ đâu trong phản hồi đó. Đối với MCP client, hãy trỏ nó đến https://connect.example.com/mcp với cùng header bearer, và gateway sẽ cung cấp các công cụ khám phá như search_actions và execute_action thay vì một công cụ cho mỗi API, điều này giúp danh sách công cụ của agent gọn nhẹ hơn. Chạy các MCP server trên VPS bao gồm phần client của quy trình kết nối này.

Hãy thực hiện thêm một bước kiểm tra nữa trước khi kết thúc. Lặp lại lệnh gọi hành động với header authorization đã bị xóa. Hướng dẫn quickstart của dự án gọi /v1 mà không cần bearer, vì vậy nếu cài đặt mà không cấu hình runtime auth, hệ thống sẽ thực thi hành động cho bất kỳ ai có thể truy cập vào cổng đó. Nếu lệnh gọi không xác thực của bạn vẫn thành công, bạn có hai cách xử lý: cấu hình runtime token và xác nhận rằng lệnh gọi ẩn danh hiện đã bị từ chối, hoặc giới hạn /api, /v1 và /mcp tại reverse proxy chỉ cho phép các địa chỉ IP mà agent của bạn sử dụng. /oauth/callback phải có thể truy cập được bởi trình duyệt đang thực hiện xác thực; nó không nhất thiết phải mở công khai cho toàn bộ Internet.

Rút gọn danh sách hành động xuống đúng mức agent cần

Một gateway có hàng nghìn provider phía sau sẽ tạo ra bề mặt quyền hạn rất rộng cho language model. Bề mặt này còn rộng hơn ngay khi model bắt đầu đọc nội dung do chính nó không tạo ra, vì một trang do SearXNG instance của bạn trả về khi agent tìm kiếm trên web có thể chứa chỉ dẫn nhắm đến bất kỳ hành động nào mà agent được phép thực hiện. Nguyên tắc hạn chế giúp coding agent thực hiện thay đổi nhỏ nhất nhưng vẫn hoạt động cũng áp dụng cho permission của agent: chỉ cấp một số ít hành động mà công việc thực sự cần, không cấp thêm. Có hai control giúp thu hẹp phạm vi này.

OOMOL_CONNECT_ALLOWED_ACTIONS nhận allowlist phân tách bằng dấu phẩy và hiểu service.* cùng *. OOMOL_CONNECT_BLOCKED_ACTIONS là denylist, và denylist được ưu tiên. Đặt allowlist thành github.get_current_user,github.list_issues nghĩa là mọi hành động khác đều bị từ chối, bất kể agent yêu cầu gì. Đây là khác biệt giữa một lỗi và một sự cố bảo mật. Runtime token có các quy tắc hành động riêng, áp dụng thêm trên các quy tắc global. Danh sách allowedProxies của chúng mặc định rỗng, vì vậy POST /v1/proxy/:service sẽ bị từ chối cho đến khi bạn cấp quyền. Proxy endpoint đó chuyển tiếp raw request đến một provider kèm credential của bạn, vì vậy hãy để trống trừ khi một agent cụ thể cần dùng.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK mặc định là false. Thiết lập này ngăn kết nối đến self-hosted provider trỏ vào địa chỉ private như cloud metadata service tại 169.254.169.254 hoặc database trên cùng network. Hãy để tắt. Chỉ bật khi provider do chính bạn host.

Sao lưu máy chủ chứa mọi token

Có 2 thứ quan trọng, và mỗi thứ đều vô dụng nếu thiếu thứ kia. Database tại /app/data/connect.sqlite bên trong volume connector-data chứa các credential đã được niêm phong. Encryption key trong .env dùng để mở chúng. Backup volume mà không có key thì không khôi phục được gì; key mà không có volume cũng không khôi phục được gì. Vì vậy, hãy lưu key trong password manager và đưa volume vào lịch backup thông thường.

Hãy dừng container trong khi sao chép file SQLite, vì bản sao được tạo trong lúc database đang ghi có thể khôi phục thành database bị hỏng.

docker volume ls | grep connector-data
docker compose stop connector
docker run --rm -v open-connector_connector-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/connector-data.tgz -C /data .
docker compose start connector

Tên volume là thư mục project của bạn cộng với _connector-data. Đó là lý do lệnh đầu tiên có mặt ở đây: hãy dán tên thực tế vào lệnh thứ 3. Đưa archive ra khỏi VPS bằng backup restic từ VPS. restic sẽ mã hóa archive trước khi archive rời khỏi VPS, vì archive đó chính là credential store.

Runtime giữ các lần chạy action gần đây dưới dạng audit record, mặc định là 5,000 record. Nhờ đó, console có thể cho biết agent nào đã chạy action nào và chạy vào thời điểm nào. Đây là log đầu tiên cần đọc khi agent hoạt động bất thường. Đồng thời, hãy trỏ một status page của Uptime Kuma vào https://connect.example.com/health. Khi gateway ngừng phản hồi, agent sẽ fail theo những cách khó hiểu. Biết gateway đang down giúp bạn không phải mất cả giờ đọc output của agent.

Sự cố và thông báo bạn sẽ thấy

redirect_uri_mismatch tại nhà cung cấp. Origin và callback URL đã đăng ký không khớp. So sánh chuỗi chính xác từ /api/oauth/configs với cài đặt ứng dụng tại nhà cung cấp, bao gồm https với http và mọi dấu gạch chéo ở cuối.

Mọi lệnh gọi /api đều trả về 401. Header của admin token bị thiếu hoặc bị viết sai. Header là Authorization: Bearer <token>, và web console cũng yêu cầu đúng token đó.

Container vẫn chạy, còn credential được lưu dưới dạng plain text. Điều này xảy ra khi OOMOL_CONNECT_ENCRYPTION_KEY không đến được container, vì runtime lưu các bản ghi credential không mã hóa thay vì từ chối khởi động. Hãy kiểm tra trên chính hệ thống của bạn: kết nối một provider bằng API key mà bạn nhận biết được, rồi tìm key đó trong database.

docker compose cp connector:/app/data/connect.sqlite /tmp/connect.sqlite
grep -c 'github_pat_' /tmp/connect.sqlite
shred -u /tmp/connect.sqlite

Giá trị lớn hơn 0 nghĩa là key chưa có hiệu lực. Hãy kiểm tra .env nằm cùng thư mục với compose.yaml và docker compose config hiển thị giá trị đó. Khi đã đặt key, cùng truy vấn sẽ trả về 0, vì bản ghi được mã hóa bằng AES-256-GCM (advanced encryption standard, khóa 256-bit, chế độ Galois/counter).

Không có dữ liệu nào được giải mã sau khi restore. Encryption key đã bị thay đổi hoặc bị mất. Theo thiết kế, key không bao giờ được ghi cạnh dữ liệu, nên không có cách khôi phục và việc gửi ticket cho support cũng không giúp được. Hãy kết nối lại mọi provider. Việc rotation được hỗ trợ thông qua một biến key riêng và một data command trong runtime, vì vậy hãy đọc release notes hiện tại trước khi rotation.

Agent báo lỗi gọi tên một action mà nó vẫn thấy trong catalog. Discovery và execution là hai bước riêng biệt. Một action có thể xuất hiện trong search_actions nhưng vẫn bị OOMOL_CONNECT_ALLOWED_ACTIONS, denylist hoặc chính các rule của runtime token đó từ chối.

Nâng cấp. Backup volume, sửa image tag thành release mới, rồi docker compose pull && docker compose up -d. Theo dõi docker compose logs -n 50 connector để tìm dòng migration, sau đó chạy lại health check và một action thực tế trước khi tiếp tục tin cậy hệ thống. Rollback nghĩa là khôi phục tag cũ. Việc này chỉ hoạt động vì bạn đã pin tag đó.

FAQ

Tôi có cần một domain công khai để tự host Open Connector không?

Đối với các nhà cung cấp sử dụng API key, câu trả lời là không: một gateway trên 127.0.0.1 là đủ. OAuth cũng không bắt buộc phải có domain trong mọi trường hợp: tài liệu của OpenConnector ghi nhận callback cục bộ của GitHub là http://localhost:3000/oauth/callback. Trình duyệt thực hiện xác thực phải truy cập được URL callback này. Đối với việc triển khai trên VPS này, hãy đặt OOMOL_CONNECT_ORIGIN thành hostname https:// của bạn trước lần khởi động đầu tiên, và đăng ký <origin>/oauth/callback trong ứng dụng OAuth của nhà cung cấp.

Điều gì xảy ra nếu tôi làm mất khóa mã hóa Open Connector?

Các thông tin xác thực đã lưu sẽ không thể giải mã được và không có cách nào khôi phục. Khóa này cố tình không bao giờ được lưu trữ cùng với dữ liệu, vì vậy không ai sở hữu database có thể đọc được nó, kể cả bạn. Lựa chọn duy nhất là thiết lập một khóa mới và kết nối lại với mọi nhà cung cấp. Hãy lưu khóa trong trình quản lý mật khẩu và đưa database vào quy trình backup, vì việc khôi phục cần cả hai.

AI agent của tôi có thể thấy access token của nhà cung cấp không?

Không, khi nó gọi thông qua gateway. Agent xác thực bằng một runtime token bắt đầu bằng oct_, và gateway sẽ chèn thông tin xác thực của nhà cung cấp vào yêu cầu gửi đi trên máy chủ, chỉ trả về kết quả phản hồi. Có hai trường hợp phá vỡ cơ chế này: endpoint /v1/proxy/:service, nơi chuyển tiếp các yêu cầu thô kèm theo thông tin xác thực của bạn (đây là lý do các quyền truy cập mặc định để trống), và việc bạn tự dán API key vào agent, hành động này bỏ qua hoàn toàn gateway.

Gateway có nên được truy cập từ Internet công khai không?

OAuth callback phải được truy cập bởi trình duyệt đang thực hiện xác thực, điều này không yêu cầu quyền truy cập từ toàn bộ Internet. Với Docker Engine 28.0.0 trở lên và cấu hình bridge networking mặc định, hãy publish cổng container trên 127.0.0.1 để giữ cho cổng này chỉ có thể truy cập từ host, sau đó đặt reverse proxy ở phía trước. Các bản Docker cũ hơn cho phép các host trên cùng L2 segment truy cập được các cổng publish trên localhost. Sau đó, hãy kiểm tra một action call mà không có header authorization. Nếu thành công, hãy giới hạn /api, /v1 và /mcp tại proxy chỉ cho các địa chỉ mà agent của bạn sử dụng cho đến khi chỉ các cuộc gọi đã xác thực mới hoạt động.

Open Connector đã sẵn sàng cho môi trường production chưa?

Các bản phát hành hiện tại sử dụng giấy phép Apache 2.0 đã sửa đổi với các điều kiện bổ sung; các bản phát hành đến v1.9.4, bao gồm cả bản v1.3.3 đã ghim, vẫn giữ nguyên Apache 2.0. Một dịch vụ connector được host hoặc quản lý mà giá trị cốt lõi là chức năng của OpenConnector sẽ yêu cầu giấy phép thương mại từ OOMOL theo giấy phép hiện hành. Các lệnh cài đặt v1.3.3 vẫn là bản snapshot của ngày 1 tháng 8 năm 2026, và bản phát hành đó đã được tung ra vào ngày 30 tháng 7 năm 2026. Hãy chạy nó bằng cách ghim vào một release tag, không bao giờ chạy trên latest hoặc tip, đọc ghi chú phát hành trước mỗi lần nâng cấp, và duy trì một bản backup volume mà bạn đã từng thử khôi phục thành công. Thiết kế này ổn định cho một máy chủ bạn sở hữu, rủi ro nằm ở sự thay đổi phiên bản, không phải ở kiến trúc.