Cursor 08-19 更新拆解：讓 agent 訂閱事件、睡著等 CI，醒來繼續把 PR 推到 merge

瀏覽次數: 1

你的 coding agent 把功能寫完、推了一個 PR，然後呢？CI 紅了、reviewer 留了三條 comment、lint bot 又補一刀——這些事全部發生在 agent 那個 turn 結束之後。過去你只能自己回到 chat，把錯誤訊息貼回去，再按一次 Enter。

Cursor（Anysphere, Inc.）在 2026-08-19 發的 changelog《Cloud Agents and Cursor Harness Improvements》就是在補這一段。官方開場原話是：要讓 always-on agent 能「operate as a system, building and shipping software on their own without the need for intervention at each loop」。

這篇把五個改動的機制拆開講，並且給你今天就能照抄的設定、檔案格式與 prompt。先給一覽：

改動	一句話	適用範圍
Subscriptions	agent 訂閱事件源、結束回合去睡，事件來了自動醒	官方註明「for now」僅 cloud agents
Custom modes	任何 skill 都能釘成整場都在的模式	Agent chat
Subagents on their own machines	每個 subagent 拿一份獨立專案副本與獨立環境	編輯器／CLI／Cloud Agents
/goal	給一個長效目標，做到完成為止	CLI 文件有列，標註 Rolling out
Steering 改進	中途插話不打斷，排到下一個 tool call 才處理	全平台

本文大綱

一、Subscriptions：把「回合結束」從死亡改成睡眠

機制

這是這次最有結構性的一項。過去的 agent 是 one-shot：給 prompt → 跑一串 tool call → 回一段結論 → turn 結束，狀態就散了。Subscriptions 讓 agent 可以主動說「我先睡，某件事發生再叫我」。

Cursor 文件（Cloud Agents → Capabilities）描述的流程是三步：agent 訂閱一個事件源 → 主動結束這個回合 → 符合條件的事件抵達時，以 follow-up message 的形式喚醒同一個對話。因為是同一個對話，context 完整保留，agent 不需要你重新交代前情。

有兩個細節官方寫得很明白，而且直接決定它在真實 PR 上會不會失控：

突發事件會合併（bursts coalesce）。短時間內連續抵達的事件可能只喚醒 agent 一次，而且 agent 醒來後會重新讀取來源本身（那個 PR、那條 thread、那張 issue），而不是只看事件通知。這正是避免「10 條 review comment 觸發 10 次重複修改」的設計。
單一訂閱最長 180 天，另外 agent 判斷等待結束時也會自己退訂。

可以訂閱哪些事件源

照文件列出的整合，目前有四類：

來源	事件
GitHub	單一 PR／整個 repo／某位作者的 PR 活動（留言、review、生命週期變更），以及分支上的 CI 結果
Slack	thread 回覆、頻道訊息、新建立的公開頻道
Linear	issue 建立或狀態變更、issue 新留言
Timers	一次性延遲提醒，或 cron 週期排程

怎麼觸發（不需要學新語法）

最簡單的方式是直接在 prompt 裡把「等待」寫出來：

open a PR and keep it green until merge

ask in #releases and wait for approval before deploying

Cursor 也內建 /subscribe skill，效果一樣：告訴它要盯什麼，由 agent 自己挑合適的訂閱型別。週期性迴圈則對應到內建的 /loop skill，文件描述是「Runs a prompt or skill repeatedly at a specified interval」。

一個容易搞混的點：/loop 出現在內建 skill 清單裡，而不是 CLI 的 slash command 參考文件裡；CLI 那份參考目前只列了 /goal [objective]，並標註「Rolling out」。所以你在 cursor-agent CLI 打 /loop 找不到，那是預期的，不是壞了。

二、PR 自動顧到底——但要知道它什麼時候會停手

changelog 說「cloud agents automatically subscribe to PRs they create and drive them to completion, fixing CI and addressing bot comments」。這句話在文件裡有非常具體的邊界，這段是實務上最該背下來的部分：

只支援 GitHub Actions。
只要你自己往那個分支推了 commit，自動修 CI 就停手——cloud agent 不會去動人類的 commit。
只要你送了 follow-up 訊息給該 agent，自動修 CI 也停手。
如果同一個 check 在 PR 的 base commit 上就已經是紅的，它不修（那不是這個 PR 造成的）。
同一個 PR 最多 10 次 CI-failure follow-up，超過就不再自動跟。
目前只在 Teams 方案上提供，文件寫非 Teams 帳號「coming soon」。

關掉的方式有兩層：整個帳號在 Cursor Dashboard → Cloud Agents → My Settings 關掉「Automatically fix CI Failures」；單一 PR 則在該 PR 留言 @cursor autofix off（@cursor autofix on 開回來）。

實戰招式：如果你不在 Teams，或想要更明確可控的行為，就別依賴這個自動行為，直接在原始 prompt 裡把需求寫死——

open a PR for this change, then monitor CI and address review comments
until all checks pass and the PR is ready to merge

這條路走的是通用 subscription 機制，不受 auto-fix 的 Teams 限制，而且行為是你自己指定的，比較好預期。

三、Subagent 各自一台機器：三層隔離，選錯就互相覆蓋

預設是共用的，這是最常踩的坑

這次 changelog 的說法是「Subagents can now run on their own virtual machines. Each gets an isolated copy of the project with clean context in its own cloud environment.」但更重要的是文件裡那句前提：subagent 預設共用 parent agent 的 checkout。當好幾個 subagent 同時改檔案，它們會互相覆蓋。

要隔離，你必須在 prompt 裡講出來。文件給的觸發句是：

run a swarm of subagents to fix these five flaky tests, each in its own environment

這時每個 subagent 會拿到自己的環境與自己的分支：同一台機器上的獨立 git worktree，或自己的 cloud environment（專屬 VM ＋一份 repo clone）。改動留在各自分支上，直到 parent agent 把結果合併回來。

另外兩個新入口值得記：從本地 session 打 /in-cloud，下一個送出的任務就會變成跑在自己 VM 與分支上的 cloud subagent；/babysit 則是叫一個 cloud subagent 去顧一個 PR，遠端反覆迭代直到可以 merge，不佔用你本地 session。

把 subagent 寫成檔案，而不是每次用嘴講

檔案放 .cursor/agents/（專案）或 ~/.cursor/agents/（使用者全域）。Cursor 也相容 .claude/agents/ 與 .codex/agents/，同名時 .cursor/ 優先。格式是 markdown ＋ YAML frontmatter：

---
name: verifier
description: Validates completed work. Use after tasks are marked done to confirm implementations are functional.
model: inherit
readonly: true
---

You are a skeptical validator. Your job is to verify that work claimed as
complete actually works.

When invoked:
1. Identify what was claimed to be completed
2. Check that the implementation exists and is functional
3. Run relevant tests or verification steps
4. Look for edge cases that may have been missed

Report what was verified and passed, and what is still incomplete.

frontmatter 欄位（全部 optional）：

欄位	預設	作用
`name`	由檔名推導	識別名稱，小寫加連字號
`description`	—	agent 用它決定要不要自動委派
`model`	`inherit`	`inherit` 或指定 model ID
`readonly`	`false`	`true` 時不能改檔、不能跑會改狀態的 shell 指令
`is_background`	`false`	`true` 時不阻塞 parent

readonly: true 是這張表裡最被低估的一格。驗證型 subagent 本來就不該有寫入權——它一旦能改 code，就會傾向「順手修好」而不是「誠實回報沒過」。這是把 curse of knowledge 從 prompt 層搬到權限層。

model 還支援方括號參數，這在成本控制上很有用：

model: claude-opus-5[effort=high,context=300k]
# 或 composer-2.5[fast=false]

成本要先算

文件自己講得很直白：subagent 各自消耗 token，同時跑五個大約等於五倍的 token；而且簡單任務因為啟動成本，用 subagent 反而比 main agent 直接做更慢。所以 swarm 的門檻是「這五件事真的彼此獨立，而且各自需要跑 dev server／測試」，不是「我想快一點」。

四、/goal：目標不是 prompt

/goal 給的是一個長效目標，agent 會持續朝它推進直到真的完成，而不是回一次答案就結束。CLI 參考文件的描述是「Give the agent a long-lived objective to work towards until it's fully complete.」

寫法上只有一條原則：目標必須有可機器驗證的終止條件。

✅ /goal fix all flaky tests and make CI green
✅ /goal get PR #482 merged: resolve conflicts, fix CI, address review comments
❌ /goal 把測試改好一點
❌ /goal 重構這個模組讓它更乾淨

下面兩個沒有終止條件，agent 只會在裡面繞，最後你得自己判斷什麼時候叫停——那就失去用 /goal 的意義了。

changelog 建議的組合技也很直接：/goal 負責「要到什麼結果」，custom mode 負責「照什麼 playbook 做」，/loop 負責「多久回來檢查一次」。三者是正交的。

五、Steering：插話不再打斷

過去在 agent 跑到一半送訊息，等於把它從 tool call 中間切斷。現在 follow-up 會排隊等到下一個 tool call 的間隙才插入。送法兩種：正常按 Send，或連按兩次 Enter。

實戰意義很具體：agent 正在跑整套 test suite 的時候，你可以補一句「順便把 timeout 從 5s 改成 30s」，它會把這件事排進來，而不是把跑到一半的測試砍掉重來。

反過來說也要記住：如果你真的想立刻停，steering 幫不了你，還是要按停止。這個改動是把「補充」和「中斷」拆成兩件事，別把它們混用。

六、Custom Modes：把 skill 從「一次性」變「整場都在」

機制差異只有一句話：用 / 叫出來的 skill 只 attach 到那一則訊息；Custom Mode 讓 skill 在整個 session 都留在 context 裡。changelog 的比喻是「always on 的 skill」。

操作：在 chat 打 / → 選中某個 skill → 按 ⌥⏎（Mac）／Alt+Enter（Windows），或直接選 Use as Mode。啟用後 chat input 會顯示一個 badge。

這代表你的 SKILL.md 現在有兩個新的 frontmatter 欄位可以用來標示模式：

---
name: tdd
description: Test-driven development playbook for this repo.
icon: beaker
color: green
---

# TDD 模式

1. 先寫一個會失敗的測試，跑一次確認它真的紅
2. 寫最小實作讓它變綠
3. 重構，每一步都重跑測試
4. 不准為了讓測試過而放寬斷言

完整的 frontmatter 欄位：name（必填，須與資料夾同名）、description（必填，agent 靠它判斷相關性）、paths（glob，把 skill 限縮到符合的檔案）、disable-model-invocation（設 true 就只能手動 /skill-name 叫，agent 不會自動套用）、icon、color、metadata。

skill 目錄：專案層 .cursor/skills/ 或 .agents/skills/，使用者層 ~/.cursor/skills/ 或 ~/.agents/skills/，並相容 .claude/skills/ 與 .codex/skills/。monorepo 特別實用——放在 apps/web/.cursor/skills/ 的 skill 會自動 scope 到 apps/web/ 底下的檔案，不需要另外設 paths。

七、數據與限制：哪些數字可信、哪些要打折

誠實講清楚這一段：

這次 08-19 的 changelog 完全沒有給任何量化數字。 沒有「訂閱讓 PR merge 時間縮短 X%」這類說法。所有效益都是機制性的描述，不是實測結果。看到二手文章給你百分比，請回去對原文。

唯一相關的公開數字來自六天前的 08-13 changelog《Cloud Agents Start 3x Faster with Builds》，原話是：「Internally, our environments now boot 10x faster, with 3x faster time to first token.」注意兩件事——這是 Cursor 自己內部環境的量測，而且沒有公開方法學，沒有 repo 規模、依賴數量、基準環境的分母。你的 monorepo 未必有同樣倍數。

其他明確寫在文件裡的硬限制：

Subscriptions 目前僅 cloud agents（changelog 原文用了「for now」）。本地 agent 不能訂閱。
單一訂閱最長 180 天。
自動修 CI：僅 GitHub Actions、僅 Teams、單一 PR 上限 10 次 follow-up。
Cloud subagent 的 MCP server 來自團隊在 cursor.com/agents 的設定，不是你本地 session 的設定——這點在本地跑得好、丟上雲就少工具的時候會咬人。
Cloud agents 依 model 與 context window 以 API 價計費。跑 swarm 前先看一眼帳。

最後一個誠實的標註：我沒有在自己的 repo 上跑完整的 subscription → merge 流程，上面全部來自 Cursor 官方 changelog 與 docs 的敘述。從文件看，最值得自己實測的兩個點是——訂閱在真實 PR 上的喚醒延遲有多久，以及 burst coalescing 在一次湧入 20 條 review comment 時，實際會合併成幾次動作。這兩個數字文件沒給，但直接決定它好不好用。

八、什麼時候別用

別在高風險 repo 直接開全自動 PR 訂閱。 agent 會在你不在場的時候往分支推 commit。先拿 docs repo 或內部工具 repo 試一輪，看它在哪些地方會做過頭。
別把 subagent swarm 當萬用加速器。 文件自己說了：簡單任務因為啟動成本反而更慢，N 個 subagent ≈ N 倍 token。它適合的是「彼此獨立、各自需要跑 server 或整套測試」的任務。
別把 /goal 當許願池。 沒有可驗證終止條件的目標，只會讓 agent 在裡面繞到你自己叫停。
別把 Custom Mode 當 rules 用。 mode 是整場都在的行為約束，開太多層等於每一輪都在燒 context。長期團隊規範應該放 rules，或用 paths scoped 的 skill 讓它只在相關檔案出現。

九、今天可以做的三件事

1. 先把環境變成 Build（這是 cloud agent 好用的前置條件）

Cloud Agents dashboard → 選你的 environment → Builds tab → Enable Builds（或先按 Run setup agent 測試遷移）。然後把 .cursor/environment.json 的職責分清楚：能預先做的全部搬進 install，只把「每次 session 都需要新鮮」的服務留在 start。

{
  "install": "pnpm install --frozen-lockfile && pnpm build:packages",
  "start": "docker compose up -d postgres redis"
}

文件明確要求 install 必須是冪等的（每個 Build 在背景跑一次）。可用欄位還有 snapshot、build.dockerfile、build.context、terminals（跑在共用 tmux session 裡的長駐程序）。terminals 的確切欄位結構請以你的 Cursor 版本產生的檔案為準，我沒有逐欄位驗證過。

2. 建一個 readonly 的 verifier subagent

把上面那份 .cursor/agents/verifier.md 抄進去。以後任何「做完了」的宣告，都用 /verifier 確認 auth flow 真的完成了 過一次。它沒有寫入權，所以只能誠實回報，不能順手把測試改寬。

3. 挑一個低風險 PR 跑一次完整訂閱

open a PR for this change, then keep it green until merge:
fix CI failures and address review comments as they come in

送出後把視窗關掉去做別的事。隔天回來看三件事：它醒了幾次、每次醒來做了什麼、在哪裡停下來。這三個觀察會告訴你，你的團隊能把多少 PR 收尾工作真的交出去。

來源

Cursor Changelog, Cloud Agents and Cursor Harness Improvements（Anysphere, Inc., 2026-08-19）— https://cursor.com/changelog/08-19-26
Cursor Docs, Cloud Agents → Capabilities（Subscriptions、Fixing CI Failures、MCP 段落）— https://cursor.com/docs/cloud-agents/capabilities
Cursor Docs, Subagents（檔案格式、隔離、cloud subagent）— https://cursor.com/docs/agent/subagents
Cursor Docs, Agent Skills（SKILL.md 格式、Custom Mode、內建 skill 清單）— https://cursor.com/docs/context/skills
Cursor Docs, Cloud Agents Setup（.cursor/environment.json）— https://cursor.com/docs/cloud-agents/setup
Cursor Docs, Cloud Agent Builds — https://cursor.com/docs/cloud-agents/builds
Cursor Changelog, Cloud Agents Start 3x Faster with Builds（2026-08-13，3x／10x 數字出處）— https://cursor.com/changelog/08-13-26
Cursor Docs, CLI Slash Commands Reference（/goal，標註 Rolling out）— https://cursor.com/docs/cli/reference/slash-commands