《Cursor文檔》-我的機器

“我的機器”是個人版的自託管機器配置。它允許特定用戶在自己已使用的機器上運行雲端代理的工具調用，例如筆記本電腦、devbox 或遠程 VM。當某臺機器正是某個倉庫所需的執行環境時，就適合使用此功能。

你機器上的一個 worker 會向 Cursor 發起出站連接。智能體循環運行在 Cursor 雲中，但終端命令、文件編輯、瀏覽器操作以及其他工具調用都在你的機器上執行。無需開放入站端口，也無需修改防火牆。

對大多數團隊來說，Cursor-managed 雲端代理都是推薦方案，包括
需要訪問私有網絡的團隊。你可以使用網絡允許列表、
Tailscale 或類似客戶端，以及針對受支持源代碼
管理路徑的私有網絡連接，而無需自行運行 worker。請參閱選擇雲端代理
的運行位置。

如果你想要以下能力，請使用“我的機器”：

使用已具備你的倉庫和工具的 devbox 或遠程工作站
在某個用戶的機器上爲特定倉庫執行工具調用
複用你不想在雲環境中重新創建的機器本地狀態
在搭建集中管理的用量池之前，先體驗 worker 模式

如需爲整個組織管理 worker fleet，請參閱團隊用量池。

快速開始¶

1. 安裝命令行界面¶

# macOS、Linux 和 WSL
curl https://cursor.com/install -fsS | bash

# Windows PowerShell
irm 'https://cursor.com/install?win32=true' | iex

確認 CLI 可用：

agent --version

2. 登錄¶

對於個人設備，使用瀏覽器登錄最簡單：

agent login

3. 啓動 worker¶

agent worker start

在你使用這臺機器期間，請保持此進程運行。默認情況下，我的機器 worker 是長駐的：它會一直保持連接，直到你手動停止，並且可在後續的雲端代理會話中重複使用。

4. 運行智能體¶

前往 cursor.com/agents。
該機器應會顯示在“環境”下拉菜單中。
發送任務。

Cursor 的“運行於”菜單，“我的機器”下高亮顯示 my-devbox

通用選項¶

爲機器命名¶

如果同一倉庫有多臺機器，請使用便於區分的名稱：

agent worker start --name "my-devbox"

在其他倉庫目錄中運行¶

agent worker start --worker-dir /path/to/repo

重複指定 --worker-dir 可註冊多個代碼倉庫根目錄：

agent worker \
  --worker-dir "$HOME/repos/app" \
  --worker-dir "$HOME/repos/infra" \
  start

每個 path 都必須存在。對於每個配置了 git remote 的 root，worker 會註冊 routing metadata，以便 Cursor 將 requests 匹配到正確的 checkout。

使用 API 密鑰¶

在 devbox 或不便通過瀏覽器登錄的自動化場景中，請使用 Cursor 儀表盤 → API 密鑰中的個人用戶 API 密鑰：

agent worker start --api-key "your-user-api-key"

我的機器 worker 需要個人憑據：瀏覽器登錄、個人用戶 API 密鑰或用戶級 token。服務賬戶 API
密鑰只能啓動用量池 worker
(--pool) ，而團隊 Admin API 密鑰和組織 API 密鑰則完全無法啓動
worker。如需團隊共享的 worker，請參閱自託管用量池。

使用用戶級 token¶

對於自行管理的單用戶 worker，請先通過 POST /v1/sub-tokens 創建一個短期有效的用戶級 token，然後用該 token 啓動 worker：

agent worker start --auth-token "your-user-scoped-token"

對於長期運行的 worker，請從文件中讀取 token：

agent worker start --auth-token-file /var/run/cursor/token

這在 Kubernetes 中很有用，因爲來自 Secrets 的環境變量在 pod 啓動時就固定了。Secret 卷會在 pod 運行期間更新，而掛載的 token 路徑可以在 pod 內實時更新，因此你可以在 pod 運行時刷新 token。

啓用計算機使用¶

在 start 前傳入 --computer-use，讓智能體能在本機上點擊、輸入、截取屏幕截圖並操作應用：

agent worker --computer-use --name "my-mac" start

在 macOS 上，首次啓動會安裝 Cursor Computer Use 輔助應用。請在“系統設置 → 隱私與安全性”中爲其授予輔助功能和屏幕錄製權限，然後用一個需要屏幕截圖的任務進行測試。在 Linux 上，請先安裝桌面端軟件包。有關 macOS 權限設置步驟、MDM 指南以及 Linux 顯示選項，參見計算機使用與桌面共享。

通過聊天入口觸發這臺機器¶

當你希望 Slack、GitHub 或 Linear 中的請求在你已命名的某臺機器上運行時，請使用 worker= 或 machine=。這是僅有的以“我的機器”爲目標的觸發選項。

使用 --name 啓動機器，然後在請求中帶上該名稱：

在 Slack 中，使用 @Cursor worker=my-devbox fix the flaky test 或 @Cursor machine=my-devbox fix the flaky test。
在 GitHub 中，在評論裏使用 @cursoragent worker=my-devbox fix the flaky test 或 @cursoragent machine=my-devbox fix the flaky test。你必須是受信任的倉庫評論者，並且目標機器必須屬於與你的 GitHub 賬戶關聯的 Cursor 賬戶。
在 Linear 中，將 worker=my-devbox 或 machine=my-devbox 添加到 issue 正文中。你也可以使用名爲 worker 或 machine 的父級標籤，並搭配名爲 my-devbox 的子標籤。

Cursor 如何選擇你的機器¶

只有當以下三個條件都滿足時，worker=<name> 請求才會在某臺機器上運行：

該機器屬於觸發此請求的 Cursor 用戶。
該機器的 --name 與請求中的 <name> 匹配。
該機器註冊的倉庫與觸發器的目標倉庫匹配。

觸發器的目標倉庫來自觸發界面，而不是機器名稱：

Slack 會優先使用你消息中的 repo= (如果有) ，然後依次使用頻道默認倉庫、你的用戶默認倉庫，以及團隊默認倉庫。
Linear 會使用從 issue 或 project 解析出的倉庫 (例如 [repo=]、issue labels、project labels 或儀表盤默認值) 。參見 Repository selection。
GitHub 會使用提及 @cursoragent 的 issue、PR 或評審評論所在的倉庫。

每臺機器註冊的倉庫來自其 worker 目錄中的 git remote。若要讓一臺機器爲多個倉庫提供服務，可爲每個 checkout 分別傳入一次 --worker-dir，或在每個倉庫的 checkout 中分別啓動一個 worker。

當 `worker=` 請求無法運行時¶

如果你有一臺同名機器，但它註冊的是另一個倉庫，Cursor 會拒絕該請求，而不是讓它在錯誤的 checkout 上運行：

worker=<name> 已註冊到你的機器上，但對應的是另一個代碼倉庫。請先在目標倉庫的 checkout 中啓動 worker。

這個錯誤會顯示爲 Slack 中的臨時回覆、Linear 中的智能體活動錯誤，以及 GitHub 上給受信任評論者的 @cursoragent 回覆。這是有意設計的行爲：針對倉庫 A 的請求絕不應該在倉庫 B 的機器 checkout 上運行。

如果沒有機器同時匹配已關聯的用戶和目標倉庫，該請求會直接失敗，而不會回退到其他環境。請確認機器名稱、你的 Cursor 賬戶關聯狀態，以及 worker 目錄的 git remote。

單獨使用 self_hosted、pool= 和 repo= 並不會將目標指向我的機器。請將它們與團隊用量池 worker 一起使用。當你將 repo= 與 worker= 搭配使用時，它會指定 Cursor 用來與你的機器匹配的倉庫。

鉤子¶

我的機器 worker 與其他自託管機器 worker 運行相同的鉤子：即你啓動 worker 所在工作區中 .cursor/hooks.json 裏基於命令的鉤子。在企業版中，它還會運行團隊鉤子和企業託管鉤子。

用量池上的鉤子介紹了在 worker 上生效的內容，包括 session 佔用和釋放機器時觸發的 sessionStart 與 sessionEnd。鉤子參考介紹了 schema、事件和示例。

製品¶

製品在自託管 workers 和 Cursor 託管的智能體上的行爲完全一致。智能體在 worker 內生成製品，再由 worker 通過 HTTPS 上傳到 Cursor 管理的存儲中。所有後續環節 (PR 嵌入、儀表盤預覽、通知附件) 都由 Cursor 的後端處理，不取決於 worker 在何處運行。

製品默認啓用。有關它們在 UI 中的顯示方式，請參閱能力。

要禁用製品上傳，請阻止發往 cloud-agent-artifacts.s3.us-east-1.amazonaws.com 的出站流量。智能體會話仍會繼續運行；但會話期間生成的製品將無法上傳。

網絡¶

worker 需要能夠通過出站 HTTPS 訪問：

api2.cursor.sh 和 api2direct.cursor.sh，用於智能體會話
downloads.cursor.com，用於命令行界面更新以及在 macOS 上首次安裝 Cursor Computer Use
cloud-agent-artifacts.s3.us-east-1.amazonaws.com，用於上傳製品

如果你的防火牆只能匹配通配符，*.s3.us-east-1.amazonaws.com 可以覆蓋製品主機，但也會同時放開該區域內的所有其他 bucket。防火牆支持時，優先使用精確匹配主機的規則。

不需要入站端口、公開 IP 或 VPN 隧道。如果你使用代理，請在 worker 環境中設置 HTTPS_PROXY 或 https_proxy。

故障模式¶

如果你屏蔽…	影響
`api2.cursor.sh` or `api2direct.cursor.sh`	worker 將無法啓動或繼續智能體會話。
`downloads.cursor.com`	命令行界面更新以及在 macOS 上首次安裝 Cursor Computer Use 會失敗。已安裝兩者的 worker 仍可繼續運行。
`cloud-agent-artifacts.s3.us-east-1.amazonaws.com`	製品上傳會失敗。依賴製品的 PR 嵌入、儀表盤預覽和通知附件將會缺失。智能體會話和其他工具調用仍可繼續工作。
特定工具或集成所需的某個出站主機	只有該工具或集成會失效。智能體會繼續運行。

MCP 服務器¶

MCP 服務器按傳輸類型路由：

Transport	Runs on	Use case
Command (stdio)	你的機器	MCP 進程會在你的機器上啓動，因此可以訪問私有網絡、內部 API 和本地服務。
HTTP / SSE (url)	Cursor backend	對於基於 HTTP 的 MCP 服務器，Cursor 會在後端處理 OAuth、會話緩存和認證。

如果你的 MCP 服務器需要訪問私有網絡中的端點，請使用 Command (stdio) 傳輸。該進程會直接在你的機器上運行，並使用你機器所在的網絡。對於基於 HTTP 的 MCP 服務器，連接由 Cursor 後端管理。

疑難排查¶

運行預檢調試報告：

agent worker debug

這會檢查身份驗證、隱私路由、倉庫標籤，以及 Cursor 能否找到匹配的 worker。若要在啓動 worker 前打印同樣的診斷信息，請使用 agent worker start --debug。

如果機器未出現在選擇器中：

確認 worker 進程仍在運行。
確認 Cursor 應用和命令行界面使用的是同一賬戶。
檢查 worker 目錄是否配置了預期的 Git remote。
檢查是否能出站訪問網絡中列出的主機。

如果在 Mac 上計算機使用失敗，該報告只能確認是否已安裝 Cursor Computer Use，而無法確認其權限是否已授予。請在“系統設置 → 隱私與安全性”中爲 Cursor Computer Use 授予 輔助功能 和 屏幕錄製 權限，然後重試一個屏幕截圖任務。參見 macOS。

後續步驟¶

計算機使用：讓 agents 在你的機器上操作桌面和瀏覽器，並在 Cursor 中查看或控制智能體桌面。
API 參考文檔：worker、用量池、待處理請求隊列以及 worker token 相關的端點。