Kiro CLI 2.29 跨 session 記憶實戰：讓 coding agent 不再每次從零開始

瀏覽次數: 1

你有沒有算過，每開一個新的 coding agent session，要花幾分鐘把同樣的話再講一次？「這個 repo 用 pnpm 不是 npm」「跑整合測試前要先 seed 本機資料庫」「那個 retry 的做法上次試過了，沒用」。agent 很會寫 code，但只要一關掉終端機，這些辛苦累積的上下文就歸零了。

AWS 的 Kiro 團隊在 2026 年 10 月 9 日釋出 Kiro CLI 2.29.0，主打功能就是 Memory Across Chat Sessions：在本機的 V3 session 裡，Kiro 可以把「repo 的指令和慣例」這類上下文記下來，在之後的 session 自動拿出來用。

這篇不談趨勢，只做三件事：講清楚它怎麼運作、手把手把它設定好，以及教你怎麼跟既有的 Steering 分工，讓記憶幫上忙而不是越幫越亂。先說明：以下內容整理自 Kiro 官方 changelog 與文件，沒有實測數據；凡是文件沒寫清楚的地方，我會直接標「文件未說明」。

本文大綱

一、它要解決什麼：agent 的「失憶」成本

Kiro 原本就有好幾種 context 來源，但沒有一種能「自己從工作中學、跨 session 帶走」：

Steering：你手寫的規則檔，放在 .kiro/steering/（workspace）或 ~/.kiro/steering/（全域），也支援 AGENTS.md。它一定會被讀到，但要你自己寫、自己維護。
Session history：同一個 session 接續或 resume 時的對話紀錄，換一個新 session 就沒了。
Compaction：長對話快爆 context 時，把舊段落壓成摘要，一樣只活在該 session 裡。
Knowledge bases（CLI）：你指定並建立索引的參考資料，是「你餵的」，不是「它學的」。

缺的那塊是：agent 在 debug 過程中自己發現的東西。例如它花了十分鐘才搞懂整合測試要先 seed 資料庫，這個領悟原本會隨著 session 結束一起消失，下次再重新踩一次。Memory 就是補這個洞。

官方文件把 Memory 定位成 Kiro agent harness（負責組 context、跑 agent 的那層系統）的一部分，要同時解兩個問題：哪些東西值得留下來，以及眼前這個任務該叫出哪一筆記憶。

二、運作原理：學習、存成紀錄、相關時回想

1. 三步驟迴圈

依官方文件，流程是這樣的：

從當前任務開始：你的請求、目前對話、Steering 一起進入 harness，成為當前 context。
從工作中學習：harness 會辨識出有用的上下文，新增或修正一筆 memory。
相關時回想：在之後的 session，Kiro 處理你的請求時，可以取出相符的那筆 memory。

文件列出它能記的內容類型包括：repo 的指令與慣例、你對它的糾正、debug 洞察、已經排除過的做法，以及你偏好的工作方式。最後一項「排除過的做法」特別實用，很多 agent 浪費時間的原因就是把已經證明無效的路再走一遍。

2. 一筆記憶長什麼樣

關鍵設計是：每筆 memory 是一筆紀錄，不是過去對話的副本。它有：

title：例如 seed-db-before-integration-tests
description：一行摘要
content：實際內容
type：這筆記憶屬於哪一類資訊
scope：適用範圍。綁定單一 repo 的記憶會顯示成 repo:github/<owner>/<repository>

這個設計的好處是可以被列出、搜尋、預覽、修改，比「把整段對話塞回去」精準也省 token。從 workspace trust 的文件可以看到，記憶存在本機的 memory database，位置在 ~/.kiro/memories/ 底下。

文件沒有說明的部分：type 有哪幾種固定分類、檢索是用關鍵字還是語意比對、記憶數量有沒有上限、多久會淘汰。這些都只能等官方補充或自己觀察。

3. 你怎麼知道它「想起來了」

當 Kiro 在工作中讀取了一筆記憶，chat 會出現一個 Memory 條目：

Memory
command=get, title=seed-db-before-integration-tests

command=get 代表讀取，後面接記憶的 title。這是你判斷記憶有沒有在發揮作用、或有沒有被錯誤套用的最直接線索，下面會教你怎麼利用它。

4. 兩道閘門：存取等級與 workspace trust

存取等級有三種：

等級	行為
`read & write`	使用記憶，也能修改（仍受你的 permissions 約束）
`read only`	使用既有記憶，不做任何修改或自動更新
`off`	不使用也不修改

只有 read & write 能新增、更新、刪除記憶。另外還有一個子選項 Automatic memory updates，說明文字是「Automatically create and refine memories, including after a session ends」，也就是允許 Kiro 自己管理記憶，包括在 session 結束之後。它必須搭配 read & write。

Workspace trust 是第二道閘門：在你還沒信任的 workspace 裡，就算設成 read & write，Kiro 也不能新增、修改、刪除記憶，只能讀。Permissions 文件寫得更細：未信任時，對 ~/.kiro/memories/ 的寫入會被直接拒絕、不會跳詢問，用意是避免一個不受信任的 session 改寫其他 session 的狀態。

這點很重要。想像你 clone 了一個陌生 repo，裡面的 README 或程式碼註解藏了 prompt injection，如果 agent 能把它寫進「跨 session 的長期記憶」，污染就會延續到你之後所有的工作。Kiro 用 trust 把這條路擋掉，是合理的預設。

三、手把手：把 Memory 設定起來

步驟 0：確認你在 V3

Memory 只支援本機的 V3 session。Kiro CLI V3 目前是 early release，可以用 kiro-cli --v3 開啟互動 session；2.28.0 也加了在終端機內直接從 Classic 切到 3.0 的互動升級。

升級前注意官方列的兩個坑：

V3 的 session 格式跟 v2 不相容，升級前先備份 ~/.kiro/sessions/。
V3 session 無法在 V2 裡 resume，切回 V2 引擎後看不到 V3 建立的 session。

# 先備份舊 session
cp -r ~/.kiro/sessions ~/.kiro/sessions.bak-$(date +%F)

# 以 V3 啟動互動 session
kiro-cli --v3

步驟 1：設定存取等級

在 V3 session 裡：

輸入 /memories
選 config
選存取等級
如果選了 read & write，再決定要不要勾 Automatic memory updates

有一個容易踩的時間差：存取等級的變更要到下一個新 session 才生效，但 Automatic memory updates 的變更是立即生效。改完等級發現沒反應，先重開 session 再判斷。

我的建議起手式：

自己的主力 repo：read & write + 開自動更新，讓它累積。
剛 clone 的開源專案、客戶的 repo：先別信任 workspace，記憶自然只讀；或乾脆設 read only。
錄 demo、寫教學、做 agent 評測：設 off。你需要的是「可重現」，前一次 session 留下的記憶會讓結果不一致。

步驟 2：定期檢查它記了什麼

輸入 /memories 選 list：

直接打字可以過濾，列表會顯示目前存了幾筆
每列顯示 title、一行 description、多久前更新
按 ctrl+p 或點擊可預覽 type、scope、更新時間、description
按 Enter 或雙擊打開完整內容，含 content、ID、時間戳

注意 list 是唯讀的，不能在這裡直接編輯或刪除。

建議養成習慣：每週或每次大重構之後，花兩分鐘掃一次 list。重點看兩種：過時的（例如你已經從 Jest 換成 Vitest，但記憶還寫著 npm run jest），以及記錯的（agent 把一次性的 workaround 當成了慣例）。

步驟 3：用對話修正或刪除記憶

要改記憶，直接在 chat 裡請 Kiro 處理，前提是 read & write 且 workspace 已信任。幾個可以直接照抄的 prompt：

列出你目前關於這個 repo 測試流程的記憶，逐筆告訴我 title 和內容。

把 seed-db-before-integration-tests 這筆記憶更新：
seed 指令已經從 `npm run db:seed` 改成 `pnpm db:seed`，
而且只有 tests/integration/ 底下的測試需要。

刪掉關於「用 sleep 等待 container 起來」的記憶，
那是暫時的 workaround，我們已經改用 healthcheck。

把我們剛才確認無效的做法記下來：
直接調高 jest timeout 解決不了這個 flaky test，根因是測試之間共用 DB 狀態。

最後一個是主動「餵」記憶的寫法。比起等 agent 自己判斷值不值得記，在一段艱苦 debug 結束時明確說「把這個結論記下來，包含排除過的方向」，品質通常比較可控。這是建議的工作習慣，不是官方保證的行為。

步驟 4：盯著 `command=get` 看

每次 chat 出現 Memory command=get, title=...，順手看一眼 title 跟眼前任務有沒有關係：

有關、而且它少問了你一句：記憶在發揮作用。
跟任務無關卻被叫出來：可能是 title 或 description 寫得太籠統，請 Kiro 把它改得更具體。
該想起來卻沒想起來：可能是那筆記憶根本不存在，或描述跟你的用詞對不上，回 /memories list 搜一下。

四、Memory 跟 Steering 怎麼分工

官方文件講得很直白：Memory 是學來的 context，它不取代目前對話、Steering 或參考資料。如果一條規則必須一致套用，就寫進 Steering。

實務上可以這樣切：

這類資訊	放哪	理由
「禁止直接改 migration 檔」「API 回傳一律用 Result 型別」	Steering	必須每次遵守，不能靠「剛好想起來」
團隊共用的技術棧、目錄結構	Steering（`tech.md`、`structure.md`）或 `AGENTS.md`	要進 git、要能 code review、所有人一致
「整合測試前要 seed DB」	先讓 Memory 學，確認穩定後升級成 Steering	起初是發現，久了就是規則
「上次試過 X 沒用」	Memory	情境性高，不適合寫成永久規則
你個人偏好（例如先給計畫再動手）	Memory 或全域 Steering `~/.kiro/steering/`	想要穩定就用 Steering，懶得寫就讓 Memory 學

這裡有一個很好用的節奏：把 Memory 當成 Steering 的草稿區。agent 在日常工作中累積記憶，你定期掃 /memories list，發現某筆記憶連續好幾週都在被 command=get 叫出來，代表它其實是團隊規則，就把它寫進 .kiro/steering/ 進 git 給全隊用。

為什麼不全部丟給 Memory 就好？因為從文件描述看，記憶存在你本機的 ~/.kiro/memories/，是個人的、不進 repo（官方沒有說明 CLI 端的團隊共享機制）。同事的 Kiro 不會知道你的 Kiro 學到了什麼。團隊共識還是要靠 Steering。

五、限制與要誠實面對的地方

官方沒有給任何效益數字。 changelog 與文件都沒有提供「省下多少 token」「減少多少重複提問」之類的 benchmark。任何聲稱 Kiro Memory 提升多少效率的說法，目前都沒有一手來源支撐。

其他已知限制，依文件整理：

只支援本機 V3 session。 V1／V2 以及 Classic 非 TUI 模式都不適用。
未信任的 workspace 只能讀。 這是安全設計，但也代表在新 clone 的 repo 裡，它不會自動學。
存取等級要重開 session 才生效。
list 是唯讀，修改要透過對話。 沒有手動編輯 UI，前提還是 read & write 加上信任。
記憶會過時。 這是所有長期記憶系統的共同風險，文件沒有提到自動過期機制。過時的記憶比沒有記憶更糟，因為 agent 會很有自信地照著錯的做。
檢索細節不透明。 什麼時候會觸發 recall、怎麼排序、同時叫出幾筆，文件都沒寫。

另外值得一提：Kiro Web 的文件也有 Memory 頁面，但 CLI 與 Web 的記憶是否互通，我沒有在文件中找到明確說法，先不下結論。

六、什麼時候該開、什麼時候別開

適合開 read & write + 自動更新：

長期維護的主力 repo，你會反覆在裡面開 session
有很多「部落知識」的專案：特殊的啟動順序、環境變數、只在某台機器能跑的測試
你常常需要跟 agent 說「這個我們試過了」

適合 read only：

已經累積了一批好記憶，想凍結狀態、不想被新的雜訊污染
需要稍微穩定一點的行為，但又不想完全失去記憶

適合 off：

錄 demo、寫教學、做 agent 或 prompt 的 A/B 評測，需要可重現
共用機器或敏感專案，不希望任何上下文跨 session 留存
你在除錯 agent 行為本身，想排除記憶這個變數

七、給工程團隊的落地清單

先備份再升 V3。 ~/.kiro/sessions/ 備份好，再用 kiro-cli --v3 或 2.28 起的互動升級。
按 repo 分級。 主力 repo 開 read & write；外部、陌生 repo 不信任 workspace，讓它自動降成唯讀。
把規則寫進 Steering。 「必須遵守」的東西不要賭 Memory 會想起來。
debug 結束時主動餵。 一句「把結論和排除過的方向記下來」，比等 agent 自己判斷可靠。
每週掃一次 /memories list。 刪過時的、改籠統的，把高頻記憶升級成 Steering 進 git。
評測與 demo 關掉。 要可重現就設 off。
看 command=get。 它是你唯一的即時觀測窗口，不相關的召回就是該整理的訊號。

如果要自己驗證，值得實測的點是：同一個 debug 任務在開與關 Memory 的情況下，各需要你補充幾次上下文；Automatic memory updates 在 session 結束後到底寫了哪些東西；以及記憶累積到幾十筆之後，召回的精準度會不會下降。這些官方都還沒回答。

來源

Kiro CLI 2.29.0 Changelog — Memory Across Chat Sessions（Kiro / AWS，2026-10-09）：https://kiro.dev/changelog/cli/2-29/
Kiro Docs — Memory（2026-10-09 更新）：https://kiro.dev/docs/memory/
Kiro Docs — Permissions（含 Workspace trust、~/.kiro/memories/ 寫入限制）：https://kiro.dev/docs/permissions/
Kiro Docs — Steering：https://kiro.dev/docs/steering/
Kiro Docs — What's new in CLI V3（升級方式、session 格式不相容）：https://kiro.dev/docs/cli/v3/
Kiro CLI Changelog（2.25 至 2.29 版本脈絡）：https://kiro.dev/changelog/cli/