Cursor 在 5/21 釋出一篇「What we've learned building cloud agents」，作者是 Josh Ma。看起來像普通的工程經驗總結，但藏了一個讓我看完盯著螢幕想很久的數字：他們把 Cursor 內部 monorepo 的 40% PR 交給雲端 Agent 寫，而且這個比例還在漲。

這套系統最後支撐到 40% 之前，他們花了一年——不是「把本地 Agent 搬到伺服器」那種一年，而是把可靠性從 90%（一個九）拉到 99%（兩個九），中間放棄了自研架構、改用 Temporal、重新拆解了 agent、機器、對話三個狀態。

我自己沒做過 cloud agent 產品，但這篇花了一個下午消化，因為文章拆出來的五個學習，每一個都是「想做 AI Agent SaaS 的人遲早會撞上的牆」。寫一篇給台灣中階開發者看的拆解版。（附帶一個小插曲：中文 AI 資訊聚合站把原文的 "two nines" 翻成「99.9%」，實際是 99%。讀任何技術摘要，最後一步都要回原文校對。）

第一個坑：以為雲端 Agent 就是把本地 Agent 搬到 server

Cursor 自己承認，一年前推出 cloud agents 時，內部把它當成「本地 Agent 的延伸」。後來才發現這個定位完全錯了。

本地 Agent 跑在你筆電上，繼承你的工作環境——你裝好的 SDK、登入過的 GitHub、設定好的 .env、跑過的 dev server。你寫程式時這些東西「就在那裡」。Agent 也用得到。

搬到雲端，這套不見了。你得從零重建。

而最狡猾的問題是：環境不完整不會崩潰。Agent 還是會跑完任務、還是會生出一個 PR、還是會自信地回覆「已經改好」。但輸出品質會悄悄下降——少了某個 lib、少了某個權限、少了某個內部 API token，結果就是 Agent 開始繞路、用 workaround、寫出能跑但完全沒抓到重點的代碼。

Cursor 為了解決這個問題，最後在自家做了一整套「Agent 專用的企業 IT」：

  • VM 之間的 sleep / resume 機制
  • VM 映像的 checkpoint、restore、fork pipeline
  • 受控的網路存取（建 PR、拉依賴、做研究）
  • 密鑰編輯、網路政策、認證管理

看到這串清單我笑了。這些不是「AI 功能」——這是 IT 部門做的事。要做雲端 Agent 產品，你會先變成你自己團隊的 IT。

第二個坑：自研架構撐不到「兩個九」

Cursor 最初的雲端 Agent 架構叫「工作竊取」（work-stealing）——一堆 worker node 從佇列裡撈 Agent 任務、跑到完成。聽起來合理：你有一堆 VM、一堆 task，誰閒就誰拿。

結果早期測試版的可靠性只有「一個九」（90%）。

這個數字看起來不差。一百個任務跑完九十個。但你想想，如果你的 cloud agent 任務平均跑 30 分鐘，使用者一天用十次，那一週後他會碰到 7 次失敗——而且不是「跑到一半提示要重試」的乾淨失敗，是「跑了 25 分鐘然後 worker pod 被 K8s 替換掉、任務蒸發」的那種失敗。

三個風險來源直接打在工作竊取架構的最弱點：

  1. 推理供應商中斷（OpenAI / Anthropic API 抖一下）
  2. Pod 需要被替換（Kubernetes 滾動更新、scale down）
  3. EC2 節點故障（AWS 隨時可能 reclaim 機器）

Cursor 發現自己正在重建一套東西：跨機器調度、自動重試、節點故障下的耐久執行（durable execution，意思是任務狀態要能撐過機器死亡而不丟）。然後意識到——這套東西已經有人做過了，叫 Temporal。

他們遷過去。

遷移後的數字：

  • 可靠性突破「兩個九」（99%）
  • Temporal 每天處理 5000 萬個 actions、跨 700 萬個唯一 workflow
  • Cursor 內部 monorepo 的 40% PR 由 cloud agent 寫

另一個值得單獨提的細節，Cursor 還重寫了 Temporal workflow 的設計——從「永恆」（eternal）workflow 改成「完成一個任務就退出」的短 workflow。原因不是可靠性，是版本升級——eternal workflow 跑半年的話，你想改一行 logic 都得處理「進行中的 workflow 用舊版、新進來的用新版」的相容性。短 workflow 就沒這問題。

說白了，他們交出去的不是性能，是控制權。自研架構完全掌握，但 race condition、跨機器調度、節點故障下的耐久執行——這些工程時間 Temporal 全部還給你。代價是你不能再從根上動它。

第三個坑：Agent、機器、對話狀態本來是同一個東西

本地 Agent 你不會分這三層。你的 IDE 開著、Agent 在那個 process 裡跑、對話歷史寫在 IDE 的 SQLite。三層合一。

雲端不能這樣。

Cursor 拆成三層：

  1. Agent 循環：跑在 Temporal 上，跟特定 VM 解耦——VM 死了 Temporal 還記得任務跑到哪
  2. VM 池：支援多種 pod 類型（唯讀 VM、預熱 VM、含特殊權限的 VM）。Agent 循環需要哪種就要哪種
  3. 對話狀態：分成存儲層（append-only 結構）和串流層（往 web / desktop client 推更新）

第三層藏了一個容易被略過但很要緊的細節。原文是這樣寫的：

這層會處理重試。若 agent 循環步驟在串流部分輸出後失敗並重新嘗試，client 能偵測並回卷串流、顯示新資料。

翻譯成人話：Agent 跑到一半失敗、Temporal 重試、第二次跑出來的結果可能跟第一次「已經串流給使用者看的部分」不一樣。Cursor 的 client 會自動把先前看到的部分「捲回去」、用新的取代。

一般 web app 你失敗就重新整理。但 AI Agent 的 token 是邊算邊吐的——失敗發生在第 3000 個 token 的時候，前 2999 個你已經給使用者看了。這是 streaming 時代才有的 UX bug，而且解法不在前端、不在後端，是要在「對話協議」這一層處理。

第四個坑：Harness 一開始抓得太緊

Harness 是 Agent 跑在裡面的「外殼」——決定哪些工具給 Agent 用、什麼時候強制中斷、出錯時怎麼 fallback。

Cursor 早期的 harness 很「保姆型」：

  • 每個 task 跑完後雙重檢查
  • 強制提交、強制 push
  • 多倉庫情境硬編碼 routing 邏輯
  • CI 失敗時自動抓 log 給 Agent

隨著 GPT-4 / Claude 3 / 後來的 Claude Opus 變聰明，這些 hard-coded 邏輯反而成了限制。Cursor 改成「只給工具、讓 Agent 自己決定」：

  • 多倉庫：給 Agent「倉庫佈局描述」+「PR 工具」，讓它自己選怎麼走
  • CI Autofix：只給 GitHub CLI 存取，Agent 自己抓 log、自己決定要不要寫到檔案

文章裡有一句話直接寫出 cloud agent 的本質：

Cloud agents 需要不同的 harness 提示詞。鼓勵更高自主性，因為阻塞成本更高——本地你知道 agent 何時停止等待許可，但雲端可能數小時無人檢查。

這直接打到我在 Claude Code 裡的體感。本地你可以一直 Ctrl+C 重來，停五分鐘等你回來。雲端不行——你 5 點下班開始跑、半夜 12 點看，發現它 5:03 就卡在等你回答「要不要建分支」的對話框。整個晚上白等。

所以雲端 harness 的 prompt 要更狠：「自己決定、不要等、出錯就 retry、最壞情況留 log 給人類事後看。」

第五個坑（沒講透但很重要）：自癒環境

文章最後一段提到他們未來方向是給 Agent「理解周圍系統」的工具，讓它能自己回報「缺少某個 API key」「網路被擋」這類阻礙，再自己修。Cursor 把這方向叫 autoinstall。

這段原文寫得很短，但落地代表著 Agent 從「會用工具」走向「會診斷自己的環境」。目前的 Agent 碰到環境問題會「猜」——猜你用 npm、猜你的 PATH、猜你的 GitHub token 在哪。猜對就跑、猜錯就用 workaround 繞過。

要做到「Agent 知道自己不知道什麼」很難，這不是寫個 introspect 工具就能解的——你得設計 prompt、訓練模型在不確定時主動報告而不是硬猜、再設計回報後的人類介入流程。Cursor 寫得輕描淡寫，但這是整篇文章我覺得最遠的目標。

對台灣中階工程師意味著什麼

你大概不會明天就開始做雲端 Agent SaaS。但如果你的團隊接下來會讓 Agent 動到 PR 流程（不論用的是 Cursor、Claude Code、Codex、還是別的），Cursor 這篇文章揭示了一個現實：你能讓 Agent 跑多遠，取決於你的開發環境長得多漂亮。

具體該動的幾件事：

  • devcontainer 寫好寫滿：Agent 拿到的環境得跟工程師本地一致，缺一個 lib 就出現「能跑但繞路」的悄悄掉品質
  • CI log 要能被機器讀：靠人類解讀的 stack trace、亂碼編碼、混在 stdout 裡的 ANSI escape——Agent 看到只會無腦重試
  • Secret policy 要有「Agent 視角」：哪些 token 可以給 Agent、哪些不行、給的時候有沒有 expiration 和 audit log
  • Repo layout 寫成文件：多倉庫專案的關係、哪個 repo 跑哪個 service、哪個 PR 要連帶改哪些——這在 Cursor harness 改造後變成 Agent 自己要讀的「地圖」

如果這幾項沒做，買再多 Cursor Pro / Claude Max 都救不回品質。

看完這篇的三個帶得走的判斷

  1. 「把 X 搬到雲端」永遠是錯的問題。真正的問題是「X 在雲端要附帶哪些原本免費繼承的東西」。本地免費的環境，到雲端都要付錢做基礎設施。

  2. 可靠性不是寫程式寫出來的，是選對抽象選出來的。Cursor 自研架構卡在 90%，不是因為他們工程師不夠強——是 work-stealing 模型本身對「跨機器耐久性」這件事不友善。換成 Temporal 不是「改架構」，是換問題的座標系。

  3. 40% 的內部 PR 由 Agent 寫，這個數字會繼續漲。Cursor 不是普通公司——他們是天天跟 Agent 工作的人。如果這 40% 是真的且還在漲，那其他公司之後也會走到這數字。中階工程師最該擔心的不是「會不會被取代」，而是「我的 PR 流程裡有沒有對 Agent 友善的設計」。

一個值得回頭翻的細節：Temporal 把可靠性推上 99%，而 eternal workflow 改成 short workflow 是為了版本升級——兩個決定一個解可靠性、一個解可維護性。工程師讀技術文章常會把「換工具的決定」記得很牢，忘了真正讓系統長久工作的是後面那些沒人講的設計取捨。

老實說，我看完最大的感覺不是「我也想做雲端 Agent 產品」，而是 Cursor 願意把踩過的工程坑寫出來——這在 2026 年的 AI 創業圈非常少見。多數公司會把這種文章鎖在內部 wiki 裡，當競爭壁壘。

原文：cursor.com/blog/cloud-agent-lessons