問題描述
最近在使用 Kiro (Agentic IDE) 玩 multiple-role agents 和 hooks 的時候，遇到了一個相當困擾的問題：在同一個 CLI session 中，Kiro 拿不到第二個指令的回傳值。
問題場景是這樣的：
- 當我請 Kiro 執行第一個指令時，一切正常，指令可以執行且能正確取得輸出結果。
- 但是接下來 在同一個 shell session 中執行第二個指令時，Kiro 就無法取得該指令的回傳值了。
- 所以 Kiro 就停在那邊等回傳，vibe 不起來。
這個問題對我的工作流程造成了很大的影響：
- 頻繁的 session 重啟：
- 每次執行完第一個指令後，我都必須手動關閉 CLI session，需要我（人類）這麼頻繁地介入，那這不是我想要的 AI agent。
- 手動複製輸出：
- 或者我需要手動複製第二個指令的回傳值給 Kiro Chat。
- 工作效率降低：
- 原本流暢的 agentic coding 工作流程變得斷斷續續，放鬆的時候是可以放鬆，但我對於工作任務，會想要提升效率。
問題場景影片紀錄（影片中的某些關鍵資訊已經被重新產生，請勿驚慌）：
內容大綱
初步調查方向
- 面對這個問題，我開始從過往的經驗進行推測。
- 首先想到的是 Amazon Q CLI 可能是兇手之一。
- 另外補充我的環境可能相對比較混雜，可以參考我的 dotfiles git repo 慢慢研究。如果有人可以幫我重新規劃可以如何簡化，會非常感激。
Amazon Q CLI 的疑慮
我之前在使用 Cursor 時也遇到過類似的問題。根據我的了解，Amazon 收購了一家名為 fig 的公司，並將其整合到 Q CLI 中。
這個整合可能造成了以下的問題：
- 多層 shell 調用：
- 當 Cursor 或 Kiro 啟動一個 CLI session (shell) 時
- 自動接管機制：
- Q CLI 可能會自動啟動並接管這個 session
- 輸出傳遞問題：
- 過太多手讓 std output (stdout) 接不回源頭的 Cursor/Kiro
這種多層包裝的架構很容易造成輸出無法正確傳回原始的 Agentic Coding Chat 環境，特別是在連續執行多個指令的情況下（通常第二個指令就會卡住）。
當時我是將 Cursor IDE 改成走去我本機相對乾淨的 bash shell，但缺點是我一堆在 zsh 設定好的環境變數和工具 Cursor 就無法使用，對我來說是一種降低效率與重工 (duplication of work)。不是很想要這種解法。
# Amazon Q post block. Keep at the bottom of this file.
# Only load Amazon Q in non-Cursor and non-Kiro environments to avoid conflicts
if [[ "$TERM_PROGRAM" != "cursor" ]] && [[ -z "$CURSOR_SESSION" ]] && [[ "$TERM_PROGRAM" != "kiro" ]]; then
[[ -f "${HOME}/Library/Application Support/amazon-q/shell/zshrc.post.zsh" ]] && builtin source "${HOME}/Library/Application Support/amazon-q/shell/zshrc.post.zsh"
fi
.zshrc 設定的考量
另外，我也注意到我的 .zshrc 中已經有依照 Kiro 文件建議的 Manual Shell Integration Installation 設定。這讓我開始懷疑是否某些 shell 設定與 Kiro 的互動機制產生了衝突。
# Kiro shell integration - Load first to ensure proper session handling
[[ "$TERM_PROGRAM" == "kiro" ]] && . "$(kiro --locate-shell-integration-path zsh)"
解決方案
經過底下的土炮除錯法，最終發現問題的根源並不在 Amazon Q CLI，而是在我的 ZSH_THEME 設定上。
但要先跟大家說明，我同事也有調整跟我一樣的同一行 ZSH_THEME 設定，但他還是會有發生問題，所以回到源頭是每個人每一台電腦當下的環境一定都不一樣，只能用以下介紹的 逐行排除法 （夠土炮吧）來找每一台電腦環境疊加後的炸點在哪裡。所以嚴格說起來不算是找到 root cause，而是該台電腦環境的最後壓力釋放點。
逐行排除法除錯
我決定採用最直接的方式：一行一行註解掉 `.zshrc` 裡的設定，看看究竟是哪一行在搞鬼。
註解掉某一行之後，回到 Kiro（或你有遇到問題的 Agentic Coding IDE） 請它測試連續三個指令到同一個 CLI session。（測試用的 prompt 可以參考底下第二支影片。）
這個過程雖然有點繁瑣，但是非常有效。透過二分法的方式逐步縮小範圍，最終找到了問題所在。
根本原因：powerlevel10k (以我的環境來說)
結果發現，罪魁禍首是我的 .zshrc 裡頭的這一行：
ZSH_THEME="powerlevel10k/powerlevel10k"
條件式 Shell Theme 切換
確認問題所在行之後，下一步思考，為了既能保持平時使用 powerlevel10k 的外觀體驗，又能確保 Kiro 正常工作，我請 Kiro （還是 Claude Code？！忘了，但模型這陣子大多都使用 Claude Sonnet 4）實作了一個條件判斷的解決方案：
if [[ "$TERM_PROGRAM" != "kiro" ]]; then
ZSH_THEME="powerlevel10k/powerlevel10k"
else
# Use simple theme in Kiro to avoid CLI session conflicts
ZSH_THEME="robbyrussell"
fi
這個方案的邏輯很簡單：
- 一般情況下：使用 powerlevel10k 主題，保持美觀的終端體驗
- 在 Kiro 環境中：自動切換到簡單的 robbyrussell 主題，避免互動衝突
透過檢查 $TERM_PROGRAM 環境變數，可以準確識別當前是否在 Kiro 的 CLI session 中執行。
而且整個 .zshrc 在各種場景下都共用，所以我之前的環境變數和工具都可以重複使用，不用例外處理或繞路。
驗證
實作上述解決方案後，問題被解決了，已消失。
修好後的瞬間 Kiro 就幫我打了一個 PR 到 aws-cdk 專案。
修復後的效果非常滿意：
- 連續指令執行正常：（這是主要的問題）在同一個 CLI session 中，Kiro 可以正常取得所有後續指令的回傳值。
- 工作流程順暢：（解掉問題後帶來的價值）不再需要頻繁重啟 session 或手動複製輸出內容。
- 兩全其美：（保持我在每個專案都追求的一致性）平時保持我習慣的 powerlevel10k 外觀，在 Kiro 中自動切換為相容的 theme。
修復後正常運作影片（無搞笑版本）：
Bottomline
解法越土我越喜歡，通常適用場景越多元。（被打 XDD
如果這個分享對你有幫助，歡迎拍打餵食一杯咖啡 ☕ :)
參考資料
- 以下是我的完整
.zshrc設定檔，方便大家交叉對照：- dwchiang/dotfiles - .zshrc
- 這個檔案包含了所有的 zsh 設定，包括修復後的條件式主題切換邏輯。
- Kiro Agentic IDE
- powerlevel10k theme
- Oh My Zsh robbyrussell theme
另外，我手邊時不時會有 AI 工作流程整合的路邊專案 (side projects) 與經驗分享議程冒出來，歡迎有興趣一起探索 AI 輔助開發工作流程的朋友傳訊息給我 LinkedIn @dwchiang。