AI 工程

Cline SDK v0.0.61 拆解:讓模型「知道自己在 Plan 還是 Act」,加上看得見進度的 context compaction

如果你用 Cline 跑過稍微複雜一點的任務,大概踩過這兩個坑:Plan 模式跟它討論了半天架構,一切到 Act,agent 卻好像沒進入狀況、還在唯讀地打轉;或者對話一長,畫面突然卡住好幾秒,你分不清它是在壓縮上下文、還是直接當掉了。Cline SDK v0.0.61(依 GitHub releases 標註於 2026-07-15 隨 CLI 與 IDE 擴充一起釋出)這一版的兩把刀,砍的正是這兩個地方:讓模型知道自己現在在 Plan 還是 Act,以及讓 context compaction 邊跑邊回報進度

這兩個聽起來像小修補,但它們是「agent 好不好用」的地基。這篇把機制拆給你看,並且給你能直接照做的設定、指令與操作習慣。

先搞清楚:Cline SDK 跟 Plan/Act 是什麼

Cline 團隊在 2026 年把整個 agent runtime 抽成開源的 Cline SDK,拆成 @cline/sdk(對外介面)、@cline/core(Node 端的 session、內建工具、自動化)、@cline/agents(可在瀏覽器跑的無狀態執行邏輯)、@cline/llms(provider 與模型目錄)、@cline/shared(共用型別)五個套件。重點是:IDE 擴充、CLI、Kanban 現在全走同一個 SDK session 層,「模式協調、compaction、mistake limit、checkpoint」這些行為只要在 SDK 修一次,三個入口一起受惠——這也是為什麼一個 0.0.61 的小版號值得單獨談:它動到的是所有 Cline 入口共用的核心。

Plan/Act 是 Cline 的招牌雙模式。Plan 模式是刻意受限的探索期:可以讀 codebase、跑搜尋、討論策略,但不能改檔、不能執行指令,對應工具是 plan_mode_respond。Act 模式才解鎖完整能力:改檔、跑指令、呼叫工具,對應 switch_to_act_mode。官方文件講得很直接——切模式時對話歷史會沿用,「Cline 記得你在 Plan 討論的一切,你不用重講一遍」。這個「唯讀規劃 → 全能執行」的兩段式,本質上是把人類 code review 的節奏搬進 agent:先讓它想清楚、你點頭,再放它動手。

這套雙模式之所以能做得穩,靠的是 SDK 把「session(一段對話任務的狀態)」和「coordinator(協調 Plan/Act、compaction、mistake limit 等行為的調度層)」拆乾淨。你在介面上的每一個動作——切模式、按 Compact、繼續同一個 session——都被翻譯成對這個 session 的操作,而不是散在各入口各自實作。理解這層,你才會明白為什麼 0.0.61 這種小版號能同時修好體感問題:因為它們共用同一條路。

運作原理一:模式引導,讓切換「對模型可見」

Plan/Act 模式引導機制:SDK 如何把模式狀態與切換提示注入 system prompt

過去的問題不是模式不能切,而是模型不知道你切了。從 CLI changelog 可以看到一連串修補:v3.0.36 修掉「Plan 模式的 switch_to_act_mode 要到回合結束才生效」的 bug;v3.0.37 明確寫著「Plan/act mode switches are now visible to the model」(模式切換現在對模型可見),並且緊接著「Fixed plan/act mode notices being dropped from prompts」——也就是說,先前切換的通知會被丟出 prompt,模型根本讀不到,難怪它切完還照舊行為。同一版還修了「在空 session 切模式會觸發重啟」的 race condition。

v0.0.61 把這件事收斂成一個乾淨的機制:SDK 在組 system prompt 時,會固定注入一段「當前模式」,並在你切換的那一刻插入一段切換提示(nudge)。對模型來說,它不再是被動地被抽換工具集,而是被明確告知「你剛從 Plan 進到 Act,已核准的計畫在這裡,接著執行」。在擴充端對應的描述是「Rework Plan/Act mode handling through SDK coordinators, including closer CLI parity and automatic continuation when switching from Plan to Act」——切到 Act 會結束 Plan run 並自動接續已核准計畫,不用你再手動打一句「開始做」。

為什麼「對模型可見」這麼關鍵?因為 LLM 沒有記憶、也感知不到 UI 狀態,它唯一的世界就是那份 prompt。你在介面上點了「Act」,若這個事實沒被寫進 prompt,模型就活在「還在 Plan」的舊認知裡。把模式狀態變成 prompt 裡的一段文字,等於幫模型接上了「它現在被允許做什麼」的感官。

從 prompt 工程的角度看,這也給你一個可遷移的啟示:任何你希望 agent 遵守的「狀態」,都得變成 prompt 裡明確的文字,而不是只存在你的心裡或 UI 上。 Cline 的模式是內建做到這件事,但你自己在寫 system prompt 或 rules(.clinerules)時同樣適用——與其期待模型「應該知道現在是 code review 階段」,不如在 prompt 裡直接標明「目前階段:只審查、不改動」。v0.0.61 等於官方替 Plan/Act 這組狀態做了示範。

實戰上這代表什麼:以前你得養成習慣,切 Act 後補一句「請依剛剛的計畫開始實作」來喚醒它;現在這一步被吃進機制裡,切換即接續。一個具體的操作節奏可以是這樣——

# Plan 模式
你:幫我把 auth middleware 從 session-based 換成 JWT,先別動手,
    列出要改哪些檔、風險在哪、測試怎麼補。

Cline(plan_mode_respond):列出 5 個檔案的改動計畫 + migration 順序 + 風險點

你:第 3 步的 refresh token 輪替再展開講;其他 OK
Cline:補充 refresh 流程

# 你按下 switch_to_act → v0.0.61 直接依核准計畫開工,不需再下指令

但自動接續也有反效果要注意:如果你只是想在 Plan 裡多問一輪,卻手滑切到 Act,它會直接開工。想更保守,就把 Plan 的最後一句留成「這樣可以嗎?有疑慮先問我再動手」,讓它停在確認點。

運作原理二:看得見進度的 context compaction

Context compaction 進度回報:v0.0.61 前後對比

Auto Compact(自動壓縮)本身不是新東西,Cline 擴充在 v3.25.0 就導入,用來在逼近 token 上限前,自動把較舊的訊息摘要壓縮,避免爆掉 context 而報錯。真正的變化是它被搬進 SDK session 層:擴充 changelog 寫「Route compacting and mistake-limit behavior through the SDK so the Compact button and mistake tracking affect the active SDK session」——手動的 Compact 按鈕、自動壓縮、mistake 計數,現在都作用在同一個 active session 上,不會出現「你按了 Compact,但底層 session 沒同步」的錯位。

v0.0.61 這一版把使用體驗補齊。CLI v3.0.41 明列兩條關鍵:「Compaction now shows progress status in the TUI」(壓縮時在終端顯示進度狀態)與「Compaction no longer runs during an active turn」(壓縮不再於回合進行中觸發)。前者解掉「卡住不知它在幹嘛」的焦慮,後者避免壓縮打斷正在跑的工作——想像 agent 正在跑一串 tool call,中途突然停下來壓縮,那種體驗又慢又容易出錯。再往前一版 v3.0.39 還修了「Fixed context compaction so canonical session history is preserved」——壓縮後保留正規的 session 歷史,不會壓一壓就把訊息順序或內容弄丟。

換句話說,compaction 從一個「你只能祈禱它不出事的黑箱」,變成「有進度、時機正確、歷史可信」的背景維護程序。對長會談(跑一整個下午的重構)來說,這是能不能安心讓它跑下去的分水嶺。

這裡也順帶講一個容易被忽略的細節:compaction 是有損的。它把舊訊息摘要化,換取 token 空間,代價是細節被抽象掉。所以如果你的任務高度依賴前面某段具體內容(例如一份長 spec、一段錯誤堆疊),與其讓它被自動壓縮成一句摘要,不如把關鍵資訊落地成檔案(寫進 repo 的 docs/.clinerules),讓 agent 需要時重新讀取,而不是全靠對話記憶。把「該長存的」放進檔案、把「對話流」交給 compaction 管理,是長會談不掉細節的實用分工。

數據與限制:誠實標註

必須講清楚:我沒有實際跑過 v0.0.61 這顆版本,以上是從 GitHub releases 與 apps/cli/CHANGELOG.md 逐條對照得到的結論,不是實測。GitHub releases 頁把 v0.0.61 的兩大重點記為「Plan/Act mode guidance added to the system prompt, with nudges when switching modes」與「Context compaction now reports progress status while it runs」;而更細、可交叉驗證的行為,散在 CLI 的 v3.0.36~v3.0.41 各版。

要注意的是,CLI changelog 頂端幾則並沒有逐字寫出「Bump SDK to 0.0.61」這種對應行(我能查到明確版號對應的最後一則停在 v3.0.38 的 SDK v0.0.57/0.0.58),所以「哪一顆 CLI 剛好綁 0.0.61」我無法百分之百鎖定,這裡以 releases 頁與可觀察的功能行為為準。你若要在文件或投影片裡引用具體數字或版號,請回到一手 changelog 再核對一次,別直接抄二手摘要——這類版號、日期、行為描述,二手來源很容易寫錯。

什麼時候該用、什麼時候別

該開 Plan 的時機:跨多檔的改動、需要先對齊架構決策、或你自己都還沒想清楚要怎麼做。這類任務可以直接下 /deep-planning,它會啟動一段延長的規劃會談,適合牽涉多檔的架構決策。可以直接 Act 的時機:小而明確的改動(改一個字串、加一行 log、補一個 null check),開 Plan 只是徒增來回。

trade-off:Plan 模式刻意建立的上下文,正是 Act 能做對決定的本錢;跳過它,agent 常常因為缺乏足夠理解而亂改。反過來,v0.0.61 的「自動接續」讓「誤切」的成本變高——手滑切 Act 它就開工,所以在敏感 repo(正式環境設定、migration、刪檔)上,Plan 的最後一句最好留成「確認無誤再讓我切」,把停損點握在自己手上。

對工程團隊,幾個可照做的招式

  1. 把 Plan/Act 當成兩段式提交:Plan 產出計畫 → 你 review → 切 Act 自動執行。現在切換對模型可見、且自動接續,你不必再補「開始做」,但相對地,要把中間那關 review 當真,別把「切 Act」當成隨手一點。
  2. 考慮關掉跨模式自動換模型:Cline 早在擴充 v3.6.5 就加了「在設定裡關閉 Plan/Act 之間自動切換模型」的開關。若你想用強推理模型規劃、用另一顆便宜模型執行,保留它;若你想全程同一顆、避免行為飄移,把它關掉更穩定可預期。
  3. 相信進度、別急著中斷:看到 TUI 出現 compaction 進度就讓它跑完,那是正常維護,不是當機。長會談時它會自己挑回合之間的空檔壓縮,不會在你等結果時插隊。
  4. 善用手動 Compact:對話變鈍、或你察覺 context 快滿時,主動按一次 Compact 主動壓縮。現在它作用在同一個 active session、且保留 canonical 歷史,比整個重開任務省事,也不會丟掉前面累積的脈絡。
  5. 升級後回頭驗一次你的自動化腳本:如果你用 Cline SDK(@cline/sdk)自己接了 CI/自動化流程,Plan/Act 與 compaction 都改走 SDK coordinator,行為對齊了 CLI,值得跑一次回歸確認你的 event handler(如 assistant-text-delta)與模式判斷沒被影響。

來源(primary sources)

整理:DataAgent · Coding Agent 實戰教學

發表迴響

%d 位部落客按了讚: