Kiro CLI 2.10 的 Config Hot-Reload：改 MCP 設定免重啟，30 輪對話脈絡不再歸零

瀏覽次數: 2

工程師都有過這一幕：你跟 coding agent 來回對了快三十輪，好不容易把一個橫跨五個檔案的 bug 收斂到剩最後一步驗證，這時你忽然需要一台新的 MCP server——比如一個能查資料庫 schema 的工具，好讓 agent 別再用猜的。你打開 mcp.json、貼上設定、存檔——然後 CLI 告訴你：請重啟 session 讓新設定生效。

重啟下去，那三十輪的對話、agent 好不容易在腦中建起來的程式碼心智模型，全部歸零。你得重新餵 context、重新解釋你在幹嘛。這個「為了改一行設定，犧牲整段工作脈絡」的取捨，是所有 MCP-based coding agent 共同的痛點。

AWS 的 coding agent Kiro 在 2026 年 6 月 26 日釋出的 CLI 2.10，主打的兩個功能就是衝著這件事來的：Config Hot-Reload（設定熱重載）與 Resource Inheritance Control（資源繼承控制）。它們聽起來像不痛不癢的 DX 小修補，但對每天靠 coding agent 幹活的人來說，差別是「能不能在不中斷思緒的前提下調整工具」。這篇就手把手拆給你看：它怎麼運作、設定檔放哪、什麼情況該開什麼開關。

先講清楚：以下內容是從 Kiro 官方 changelog 與 docs 整理，作者本人尚未實機跑過 2.10，文中標「值得實測」處請以你自己的環境為準。

本文大綱

一、先搞懂 Kiro 的設定長什麼樣

要看懂 hot-reload 的價值，得先知道 Kiro 的設定散在哪幾個地方。Kiro CLI 的 MCP server 設定走的是三層、由高到低覆寫的模型：

Agent Config（最高優先）——寫在 agent JSON 檔裡的 mcpServers 欄位
Workspace——專案根目錄下的 .kiro/settings/mcp.json
Global（最低優先）——使用者家目錄的 ~/.kiro/settings/mcp.json

合併規則是「完整覆寫（complete override）」：同一個 server 名稱如果在多層都出現，只採用最高層那一份定義，不會做欄位級的 merge；不同名稱的 server 則是跨層相加。換句話說，你可以在 Global 放共用的工具、在 Workspace 放專案專屬的工具，而某個 agent 想用自己客製版的同名 server，就在它的 agent JSON 裡覆蓋掉。

每台 MCP server 的設定本身分兩種。本地 server 用 command 指定執行檔，搭配選用的 args 跟 env（環境變數支援 ${VARIABLE_NAME} 語法展開）；遠端 server 用 url（HTTPS，localhost 可 HTTP）搭配選用的 headers。兩者都支援 disabled、autoApprove、disabledTools 這幾個欄位。一份最小的 mcp.json 大概長這樣：

{
  "mcpServers": {
    "postgres": {
      "command": "uvx",
      "args": ["mcp-server-postgres", "--dsn", "${DB_DSN}"],
      "env": { "DB_DSN": "postgres://localhost/app" },
      "autoApprove": ["query"]
    }
  }
}

二、Config Hot-Reload 到底怎麼運作

2.10 之前，上面那份 mcp.json 你改完得重啟 session。2.10 之後，官方的說法是：「Agent 與 MCP 設定會在你把變更存到磁碟時 hot-reload。」拆開來看，背後有四個動作：

① File watcher 在背景監看。 Kiro 會盯著 .kiro/agents 目錄以及各層的 mcp.json 檔案。你只要在編輯器裡存檔——編輯一份 agent 設定、新增一個 agent 檔、或改動 mcp.json——watcher 就會偵測到。

② Order-independent diff 比對。 這是最關鍵、也最容易被忽略的設計。它不是「檔案一動就全部重來」，而是做順序無關的設定差異比對。意思是：你把 env 裡幾個環境變數的順序對調、或重排 JSON 的 key，內容其實沒變——這種情況不會被判定成變更，自然也就不會觸發任何重啟。只有真正新增、移除、或修改了某個 server 的內容，才算數。

③ 只重啟受影響的 server。 假設你有五台 MCP server 在跑，你只改了其中一台的參數，那麼只有那一台會重啟，另外四台繼續維持連線、維持它們已經載入的狀態。沒被你動到的東西不受牽連。

④ 在對話 turn 之間的 idle 邊界 reconcile。 這個 reconcile 不會打斷你正在進行的一輪對話，而是挑在 agent 兩輪之間的閒置點完成。所以你不會看到對話「卡住重連」，整段 conversation context 全程保留。官方還特別提到：那些你在 session 中途用 /mcp add 臨時加進來的 server，也會在 reconcile 時被保留並重新併入，不會因為一次存檔就被洗掉。

把這四步連起來看，重點不是「自動 reload」這四個字，而是「最小破壞」這個設計取向：能不重啟就不重啟、要重啟也只動該動的那一台、而且絕不犧牲對話脈絡。這跟很多工具「設定變了就請你重開」的粗暴做法是兩種思路。

三、Resource Inheritance Control：把繼承關掉的開關

2.10 的第二個功能，要從 Kiro 在 v2.7.0 引入的一個行為講起。從 2.7 開始，你自訂的 agent 會自動繼承一批預設資源，包括：

Steering 檔（專案層級的引導設定，類似專案版的規則）
Skills（打包好的多步驟技能）
AGENTS.md（專案的 agent 說明文件）

立意是好的：大部分情況你會希望自訂 agent 也吃到專案的共同規範。但問題來了——當你想做一個乾淨、可控、只帶它自己那套資源的專用 agent（例如一個只負責跑測試、不該被一堆 steering 規則干擾的 agent），這個自動繼承反而變成雜訊，甚至會讓 agent 行為不可預測。

2.10 給了你關掉它的開關。這是一個 CLI 設定：

kiro-cli settings chat.disableInheritingDefaultResources true

設成 true 之後，自訂 agent 就不再繼承預設的 steering、skills 與 AGENTS.md，只帶它自己 resources 欄位裡明確列出的東西。要注意兩件事：第一，內建 agent 永遠繼承預設資源，不受這個開關影響；第二，這是個全域 CLI 設定，不是寫在單一 agent 檔裡的欄位——它影響的是「所有自訂 agent 的繼承行為」。

順帶補一下 agent 設定檔本身的樣子，這樣你才知道「它自己那套資源」要寫在哪。Agent JSON 放在 .kiro/agents/（專案層、只在該目錄下可用）或 ~/.kiro/agents/（全域、任何目錄可用），同名時專案層蓋過全域。檔名就是 agent 名稱。核心欄位包括 prompt（支援 inline 文字或 file:// 引用）、mcpServers、tools、allowedTools（免逐次確認就能用的工具）、resources、model、keyboardShortcut 等。resources 支援三種來源：file://（啟動時直接載入）、skill://（啟動載 metadata、用到才載全文）、以及 knowledgeBase（建索引、可搜尋）。一份精簡範例：

{
  "name": "test-runner",
  "description": "只負責跑測試與回報的乾淨 agent",
  "prompt": "file://./prompts/test-runner.md",
  "tools": ["read", "shell"],
  "allowedTools": ["read"],
  "resources": ["file://README.md", "skill://.kiro/skills/**/SKILL.md"]
}

把 chat.disableInheritingDefaultResources 開成 true，這個 test-runner 就只會看到 README.md 跟它指定的 skill，不會被全域 steering 污染——這正是「可預測的專用 agent」要的效果。

四、數據與限制：誠實說清楚

先把不確定的地方標出來。官方 changelog 與 docs 用的是描述性語言（「只有受影響的 server 重啟」「順序無關的 diff」「在 idle 邊界 reconcile」），沒有給出具體的延遲數字、watcher 的 polling 間隔、或大型設定檔的 reconcile 耗時。所以這篇不會丟任何「快了幾倍」「省了幾秒」的數據——因為原始來源就沒有，硬掰只會是幻覺。

幾個值得你自己實測確認的點：

reconcile 的時機：官方說在「對話 turn 之間的 idle 邊界」生效。如果你存檔的當下 agent 正在跑一輪長任務，新設定要等這一輪結束才會套用，不是「秒級即時」。這對需要中途緊急換工具的情境是個前提。
「只重啟受影響的 server」的邊界：改了某台 server 的 env，它會重啟；但這台 server 重啟期間，正在用它的那輪工具呼叫會怎樣？官方沒明說，值得實測。
order-independent diff 的範圍：明確講到「重排環境變數順序不觸發重啟」。但更刁鑽的情況（例如把一台 server 拆成兩台同等效果的設定）會不會被判成變更，文件沒涵蓋。

限制面也要講白：hot-reload 解決的是「改設定的摩擦」，不是「設定本身的複雜度」。三層覆寫加 agent 級 mcpServers，本來就容易讓人搞不清「現在到底生效的是哪一份」。hot-reload 讓你改得更快，但也意味著你更容易在不知不覺中改動了行為——這把雙面刃下面會談。

五、什麼時候該用、什麼時候要小心

該用、會很爽的場景：

長對話中途調工具。這是最大受益點。你在一個深度 debugging 或重構的 session 裡，發現少了一台 server 或某個工具參數不對，直接改檔存檔，脈絡不斷。
迭代 agent 設定。你在調一個自訂 agent 的 prompt、tools、resources，以前每改一次重開一次，現在存檔就看到新行為，回饋迴圈短很多。
多 server 環境。server 越多，「為了改一台而重啟全部」的代價越高，hot-reload 的相對收益越大。

要小心、甚至該關掉自動繼承的場景：

設定來源不只你一個人。團隊共用 .kiro/settings/mcp.json 又各自有 agent 級覆寫時，hot-reload 會讓「誰改了什麼、現在生效哪份」更難追。建議把 .kiro/ 納入 code review，別把它當成隨手改的暫存區。
要可重現的 agent 行為。如果你在做評測、或這個 agent 的輸出要進 CI，預設資源自動繼承會引入你沒列出來的變因。這時把 chat.disableInheritingDefaultResources 設 true，讓 agent 只吃明確宣告的資源，行為才可重現。
正在跑長任務。記得 reconcile 在 idle 邊界才發生，別期待存檔當下立刻換掉正在用的工具。

一句話的 trade-off：hot-reload 用「改設定變快」換來「設定可能在你沒注意時悄悄變動」。前者對個人開發體驗是淨賺，後者對團隊與可重現性是要管理的風險。

六、對工程團隊的意義：可以照做的幾招

把 .kiro/ 當程式碼管。 mcp.json、.kiro/agents/*.json、steering 檔全部進版控、進 review。hot-reload 讓這些檔案「存了就生效」，等於它們的權重跟程式碼一樣高，別放任。
為「可重現的 agent」預設關繼承。 凡是要進 CI、跑評測、或對外交付結果的 agent，建立時就把 chat.disableInheritingDefaultResources 設 true，並在 resources 裡明確列出它需要的每一項。寧可多寫幾行，也不要靠隱性繼承。
善用三層分工。 Global 放跨專案共用工具、Workspace 放專案專屬、agent JSON 放該 agent 客製的覆寫。記住「同名只取最高層、不同名相加」，照這個心智模型佈局就不會打架。
改設定挑時機。 知道 reconcile 在 turn 之間發生，就養成「等 agent 講完這一輪、再存設定檔」的習慣，套用最乾淨。
升級前看清版本脈絡。 2.10 的繼承開關是為了修補 2.7 引入的自動繼承；如果你團隊還停在更舊版本，升級時要一起把這兩個行為的變化讀過，別只看最新一版的 changelog。

Kiro 2.10 不是什麼驚天動地的大功能，但它代表一個對的方向：coding agent 的設定，應該能像改程式碼一樣即時、像版控一樣可追，而不是每次微調都要你付出「重啟、丟脈絡」的稅。把這兩個開關用對，你跟 agent 的協作會少掉很多被打斷的瞬間。

來源

Kiro CLI 2.10.0 Changelog（AWS Kiro 團隊，2026-06-26）：https://kiro.dev/changelog/cli/2-10/
Kiro Docs — MCP Configuration / Hot-Reload：https://kiro.dev/docs/cli/mcp/configuration/
Kiro Docs — Custom Agents Configuration Reference（含 chat.disableInheritingDefaultResources）：https://kiro.dev/docs/cli/custom-agents/configuration-reference/