模式

模式是什麼

模式是空間的屬性，儲存為空間資料列上的單一欄位。空間內的每個對話都共用它，討論串也不例外——討論串會像任何其他對話一樣繼承所屬空間的模式。因此，同一個代理可以在同一時間於不同空間中處於不同模式，而切換某個空間的模式會改變下一個回合的行為，完全不需碰觸代理。

恰好有四種：chat、review、plan、orchestrate。列舉本身不帶任何政策。模式所保證的一切只宣告一次，寫在一份能力設定檔裡，由每個強制執行層投射而來：

工具介面——該模式下究竟有哪些工具存在，表現為最高核准層級、允許清單、拒絕清單，以及一組拒絕的效果類別。
必要的輸出動詞——一次執行必須呼叫什麼，才算交付了任何東西。
拒絕的效果類別——動作護欄會直接拒絕的類別。
工作樹姿態——工作樹是否可以被寫入。這是透過把會變更狀態的工具從介面中剔除來強制執行，也正是它能在每個主機上成立的原因。當主機有作業系統沙箱時，同一個姿態也會刻出檔案系統的寫入規則——唯讀模式會以唯讀方式掛載工作樹——但那是這項保證的第二份副本，不是真正起作用的那一份。
系統提示區塊——一段_生成的_能力前言，衍生自實際具體化後的工具清單，再加上手寫的指引。

每個強制執行層都從那一份設定檔投射而來，因此工具介面、護欄、工作樹姿態與提示不可能彼此不一致。

四種模式

聊天 — 顯示為「Agent」

這是預設模式，也是唯一沒有額外限制的模式：一路到執行層級的完整工具介面、可寫入的工作樹、沒有拒絕的效果類別，也沒有完成契約。可用於實作、修錯、關於程式碼庫的問題，以及任何臨時性的事。

注意標籤：在輸入區中，這個模式顯示為**「Agent」**，而不是「Chat」。

計畫 — 唯讀、單一交付物

計畫模式會把工作樹設為唯讀，並把寫入工具整個從介面中剔除，因此這項限制是結構性的，而不是靠指示得來的。代理會閱讀、搜尋與研究，並只交付一件事：一次 submit_plan 呼叫，攜帶一份具型別的相依圖——一個目標，加上各帶鍵、標題、描述，以及各自相依之節點鍵的節點。

計畫會以精簡的一列呈現在對話中，並在旁邊的分頁中開啟 Plan Studio。核准它，會把這份圖編譯成一項編排、執行生成的工作，並把撰寫這份計畫的空間翻回代理模式。

如果一次計畫模式的執行結束時從未呼叫 submit_plan，迴圈會先注入一則催促，說明除非該呼叫成功，否則計畫並不存在。這則催促明確授權誠實地以「這裡不需要計畫」退出，因為計畫模式是空間層級的設定，在裡面問一個普通的問題不該被迫生出一份硬湊出來的計畫。

還有第二種、各自獨立的出路：exit_plan_mode。它是一道硬性核准關卡，而不是輸出動詞——一個改為呼叫它、而非呼叫 submit_plan 的代理，什麼都沒有交付。第一次呼叫會開啟一筆持久的 plan_exit 核准並回傳 pending，空間維持唯讀；重複的呼叫會維持在 pending，而不會開啟第二道關卡。只有當核准被授予之後，後續的呼叫才會把空間翻轉為聊天模式。被拒絕時，代理可以針對修訂後的計畫開啟一個全新的請求。

要自行離開計畫模式，請切換輸入區的下拉式選單（或按 Shift+Tab）。exit_plan_mode 由 decide_approval MCP 工具決定。收件匣的「代理核准」列是另一回事：那是執行中代理逐回合發出的確認提示。

審查 — 唯讀、無契約

審查模式用於 PR 審查。它會把工作樹設為唯讀、把工具介面上限壓在執行層級之下，並套用一份精心挑選的允許清單，涵蓋審查、工單與通訊工具。為某個 pull request 開啟的空間，會自動以審查模式建立。

代理的產出是結構化的發現——審查節點——以及在一次審查定案時的一份判定。一個節點帶有種類（bug、suggestion、recommendation、question 或 ticket）、從 P0（阻擋發行）到 P3（可有可無）的優先順序、一項自我評估的信心、一個選用的錨點（檔案加上一段行號範圍；涵蓋整個儲存庫的註記則沒有），以及一個生命週期狀態，在同儕——絕不是作者本人——確認後，從 open 進到 consensusReady。優先順序或信心缺漏、或超出範圍的發現，會在讀取邊界被丟棄，而不是汙染判定。

判定為 ship、hold 或 block，而且只會因為納入其中的各軸結果而變得_更_嚴厲：受閘門控管卻失敗的軸會強制 block，受閘門控管卻無法執行的軸則至少強制 hold。缺乏證據永遠不會讓一道閘門轉綠。

與計畫和編排不同，審查模式沒有完成契約。發現透過 add_review_node 累積，並由 finalize_review 發佈，而兩者被呼叫零次都是合理的——在審查模式中執行的管線代理，可能只是為了完成一張工單才待在那裡。

編排 — 唯讀、提出一個團隊

編排模式把一個目標變成一份整團隊的計畫。與計畫模式一樣，它是唯讀的，無法寫入檔案；在研究介面之上，它有一個唯一的特權動詞 propose_orchestration，會發出一份結構化的提案：角色、一棵子工單樹、一個彙整步驟與一份預算。提示只會列出介面上有的工具，因此模型不會把回合花在描述它根本無法呼叫的招募或工單工作上。

提案裡的任何東西在你核准之前都不會執行。核准時，一個確定性的具體化器會雇用代理、建立工單與一個專案，並執行一條生成的管線。核准只有操作者能做：沒有供它使用的 MCP 工具，因此代理可以提出，卻永遠不能核准自己的計畫。由代理發起的重新提案受兩分鐘冷卻時間的速率限制，因此連續的重新規劃會被拒絕，並被要求合併處理。請參見編排。

兩條值得知道的規則

模式自己的輸出動詞永遠不能被拒絕。 submit_plan 與 propose_orchestration 被釘入工具介面，並預先核准，越過工具篩選器、核准關卡與動作護欄，因此每個空間的自主程度旋鈕無法讓某個模式的交付物噤聲。執行環境的 ask_user 也基於同樣的理由被釘住：它_正是_一次執行觸及操作者的方式，因此把它設為關卡會讓一個需要提問的執行死鎖。它屬於讀取層級，因此每個唯讀模式都會保留它，而且它豁免於核准包裝——在提示前面再放一道提示，會在沒有連接任何核准者的情況下失效即拒絕，那將會讓代理連提問這個動作都被拒絕。

唯讀模式不會拒絕網路存取或密鑰。 審查、計畫與編排所拒絕的效果類別，是那些會改變世界的類別：刪除檔案、在工作樹之外寫入、提交、推送、建立與發佈 PR、供應商同步寫入、安裝套件、生成處理序、變更工作區，以及操控隔離艙。網路出站與密鑰存取刻意維持在它們的預設值——研究正是唯讀模式存在的全部意義。

選擇與切換模式

輸入區的模式下拉式選單提供三個選項：Agent（聊天）、Plan 與 Orchestrate。review 不是使用者可選的——它是在建立 PR 審查空間時由系統設定，並由管線步驟設定。

一個開啟空間的管線節點，可以用 extras['mode'] 鍵（chat、review 或 plan）釘住該房間的模式。這個鍵採精確比對：任何其他拼法——包括 orchestrate——都會被默默忽略，房間則取得該 body 的預設值（在建立空間的 body 上為 review）。代理步驟會加入一個不是它建立的房間，且不會重新調整它的權限。

解析本身很簡單。派送器會讀取空間的 mode 欄；一次沒有空間的派送——單次執行、一次 CLI 呼叫，或一個來自另一個工作區的空間 id（它根本不在這個工作區的資料庫檔案裡）——會解析為 chat。切換模式會從下一個回合起生效。

保證真正成立的地方

模式的工具介面是由內建執行環境建構並強制執行的。它是唯一能讓工具變成看不見、而不只是被拒絕，能在每次呼叫執行前把它擋下，並能觀察完成契約的傳輸方式。

在 Claude Code 配接器上，非聊天模式會以 --permission-mode plan 傳入。Claude 依慣例遵守這項設定；它自己的讀取、寫入與編輯工具會在不被看見的情況下執行，shell 命令也只由一個讀取命令列的鉤子檢查。對那個配接器而言，模式只是指引，而不是 Control Center 的界線——請參見代理模型。

允許清單約束的是寫入層級及以上的工具。內建執行環境的讀取層級仍可觸及沒有任何清單指名的工具；在 Claude Code 上，允許清單未列出的工具，無論伺服器有沒有它，都會被拒絕。