⚡ Kiro CLI Headless Mode

🧭 核心概念

IDE 與 CLI 的關係

IDE 與 CLI 其實本質上都是工具層，只要底層使用的模型相同，使用的 Context 內容相同，其實兩個工具的成效並沒有差別。

實際的差距在於實踐的模式，如果想要在代碼中引入 LLM 的能力，例如，每天早上固定收集某個賣家的資料，然後藉由 LLM 將資料整理成一份檔案，這種做法就必須要讓代碼本身就能自己呼叫 LLM，而不是通過打開 IDE 或者打開 CLI 來做為流程的一部分。

如何在代碼中使用 LLM 能力，才是今天要解決的底層需求。

為什麼排程工具只能呼叫 CLI，不能呼叫 IDE？

既然 IDE 和 CLI 成效相同，為什麼做自動化就一定要 CLI？答案不在工具的能力，而在它們被外部呼叫的方式。

Windows Task Scheduler、Linux cron、CI/CD 這類排程工具，本質上只會做一件事：在指定時間啟動一個可執行檔，把參數傳進去，等它跑完結束。

啟動 python.exe → python 啟動 kiro-cli.exe → 跑完自動結束

啟動 Kiro IDE → ？？？ → 自動打開對話框 → ？？？ → 自動輸入指令

差別就在「？？？」那兩個位置。IDE 是給人用的圖形介面，沒有設計外部 API 讓別的程序告訴它「去打開對話框、輸入這段文字、按送出」。它預設就是要有人坐在前面操作。

CLI 則是反過來設計：只要有 --no-interactive 和 --trust-tools 這兩個參數，它就會默默跑完、默默結束，完全不需要人盯著。這才是它能被排程工具、CI/CD、其他腳本任意呼叫的根本原因。

所以判斷標準很單純：

Headless 模式是什麼？

可以通過腳本代碼以及API Key 認證，就使用到 Opus 4.6 的能力，而不需要通過 IDE 或 CLI 使用對話的方式來呼喚 LLM。

1安裝 Kiro CLI

打開 PowerShell 輸入以下代碼：

2設定預設模型

安裝完成後，先輸入以下代碼，確保預設模型切換至 Opus 4.6 1M：

3測試登入

在 PowerShell 輸入 kiro-cli，檢查是否能正常登入：

看到以下畫面表示安裝成功：

Kiro · claude-opus-4.6-1m
ask a question or describe a task ↵

4驗證 MCP 是否正常

在 Kiro CLI 中輸入 / 可以進入指令選項，其中 /mcp 可以查看有啟動的 MCP server。

因為 Skill & MCP 設置是共享機制，所以不做任何變動，CLI 也應該要能正確的讀取到 IDE 中設置好的 MCP。

如果有出現無法讀取，或者工具遺漏的狀況，建議先回到 IDE 中，截圖讓 Opus 4.6 維護。

5申請 API Key

API Key 是讓代碼可以引入 LLM 能力的重要憑證。申請方式如下：

登入 KIRO 的後台介面

1. 前往 app.kiro.dev
2. Sign in 方式選擇 Your organization
3. Organization 的資訊如下：

Start URL: https://amzn.awsapps.com/start
Region:    us-east-1

產生 API Key

在 API Keys 的欄位輸入一個 API 的代稱（例如 Kiro CLI），然後點 Create Key。

6設定環境變數

設定變量

將 API Key 寫入系統層級的使用者環境變數，這樣排程任務才能讀到。把你剛才產生的 API Key 貼到下方輸入框，複製按鈕會自動帶入對應的完整指令：

驗證變量

開一個新的 PowerShell，然後輸入：

輸入後應該出現剛剛設定的 API Key。

🎯 Demo — 體驗使用腳本引入 LLM 的流程

這個 demo 由兩段組成，目標是讓你親身感受兩個關鍵時刻：

1. 「咦，沒打開 IDE 也能觸發 LLM？」——手動跑 1_poetry-demo.ps1，看 Kiro CLI 在純代碼裡產出檔案
2. 「咦，我都沒動電腦，怎麼檔案自己出現了？」——用 Task Scheduler 排程觸發，體驗真正的無人值守

為了保持教材簡潔，所有腳本的完整內容都放在同一個 GitHub repo，下載後直接放在你自己的練習資料夾就能跑。每個腳本的開頭都有寫清楚使用方式。

Step 1：下載唐詩產生器腳本

這隻腳本會呼叫 kiro-cli chat --no-interactive --trust-tools，連續產生三首唐詩 md 檔到當前資料夾。整支腳本只有 30 多行，核心就是那一句 CLI 呼叫：

核心代碼就是這段（節錄），其他部分都只是包裝：

kiro-cli chat --no-interactive --trust-tools=write `
  "Pick a classic Tang Dynasty poem at random.
   Write it in Traditional Chinese to the file $filename ..."

固定的代碼 + 動態的 prompt，產出訂製化的內容，這就是 CLI 路線無法被 IDE 取代的核心價值。

Step 2：把腳本註冊成自動排程

手動跑腳本只是第一步，真正的自動化是讓它「自己跑」。以下兩組腳本分別註冊一個 Task Scheduler 任務，在「當下時間 + 1 分鐘」自動觸發一次唐詩產生器。

兩組差別只在一個參數：-WindowStyle Hidden。建議兩組都跑過一次，親眼對比體驗差異。

組合 A：有視窗版（執行時會彈出黑色 PowerShell 視窗）

組合 B：隱藏版（執行時完全靜默，體驗真正的「無感」自動化）

🧪 執行與測試

把前面下載的五個腳本放在同一個資料夾（建議桌面新建一個 kiro-demo/ 資料夾），然後依序體驗三個階段。

第一階段：感受「代碼能呼喚 LLM」

開一個新的 PowerShell，切到剛才放腳本的資料夾，執行：

腳本會立即啟動，依序產生三首唐詩 md 檔到當前資料夾。執行完你會看到類似這樣：

poem-20260418_143022-1.md
poem-20260418_143022-2.md
poem-20260418_143022-3.md

你會發現一件神奇的事：全程沒有打開 Kiro IDE，也沒有進入 Kiro CLI 的對話介面，LLM 卻確實被呼叫了。這就是 headless 模式——讓 LLM 成為「代碼能呼叫的函式」，而不是「人坐在前面聊天的對象」。

第二階段：排程測試（體驗「有視窗版」）

第一次先跑有視窗版的，方便你親眼看到「排程真的觸發了」：

執行完會顯示觸發時間（當下 + 1 分鐘）。接著什麼都不要做，等一分鐘。

時間到時，你會看到畫面上突然彈出一個黑色 PowerShell 視窗，裡面跑出唐詩產生器的日誌，幾秒後自動關閉，資料夾又多了三首新詩。

排程測試完畢，執行清理腳本移除任務：

第三階段：排程測試（體驗「隱藏版」）

現在試試靜默版：

同樣等一分鐘，但這次畫面完全不會有任何變化——沒有彈窗、沒有提示、沒有動靜。可是一分鐘後去資料夾看，又多了三首新詩。

這就是 headless 模式的終點：沒有人工、沒有工具層（CLI or IDE）、也沒有任何視覺干擾，但需要 LLM 介入的任務已經被完成了。

清理隱藏版排程：

進階案例：真實業務自動化

唐詩 demo 是用最少的代碼展示 headless 的魔力，但它跟實際工作距離太遠。這一節用一個真實場景延伸：每天自動下載 Google Sheets 的報名資料，合併去重，然後讓 LLM 寫一份分析報告。

這是一個真實需求——2026 AGS Expo 的台灣廠商報名資料分散在 Google Sheets 的三個分頁，業務每週都要人工下載、合併、整理摘要給主管。整個流程完全可以自動化。

職責劃分：確定性 vs 模糊

實作這種場景時，最重要的不是代碼多漂亮，而是哪些事給代碼做、哪些事給 LLM 做：

硬讓 LLM 做下載合併，代價是慢、貴、不可靠；硬用代碼寫分析結論，結果會僵硬又沒重點。讓彼此做擅長的事，自動化才真的實用。

架構總覽

資料夾結構

KiroCLIAutomation/
├── 6_sp_expo_demo.py                  ← 主腳本，一鍵跑完整流程
├── 7_sp_expo_sheets.json              ← 要下載的 Google Sheets 網址
└── YYYYMMDD SP-EXPO 彙總報告.md     ← 執行後產生，LLM 寫的最終報告

執行過程中會在系統暫存目錄（%TEMP%）寫一份合併後的 CSV 給 LLM 讀，跑完自動清掉。所以專案目錄裡永遠只會看到一份結果報告，不會有中間產物殘留。

Headless 核心呼叫

整個腳本有兩百多行，但真正跟 Kiro CLI 互動的只有這段。Python 用 subprocess 啟動 kiro-cli，把 prompt 當參數傳進去：

import subprocess

prompt = f"""你是資料分析助手。請完成以下任務：
1. 讀取：{merged_csv}
2. 這是 2026 AGS Expo 台灣廠商報名資料
3. 產出繁體中文 markdown 報告，寫入：{report_path}

報告結構：
## 一、整體概況
## 二、亞馬遜站點分佈
## 三、產品類別分析
## 四、廠商經營型態
## 五、能力分析
## 六、關鍵洞察（3 到 5 點重點觀察）

直接把完整報告寫入指定檔案，不要在對話中重複輸出。"""

subprocess.run([
    "kiro-cli", "chat",
    "--no-interactive",
    "--trust-tools=read,write",
    prompt,
], capture_output=True, encoding="utf-8")

這段代碼跟唐詩 demo 的kiro-cli chat --no-interactive完全一樣，只是換成 Python 寫、prompt 換成業務需求。同一套 headless 模式，撐住不同的業務場景，這就是這套方法的價值所在。

語言不是限制

前面唐詩 demo 用 PowerShell，這邊 SP-EXPO 用 Python，看似換了技術棧，其實本質相同：

Headless 模式的好處是：只要你的語言能啟動子程序，就能用這套模式。Node.js、Go、甚至 .bat 都行。選擇哪個語言當外殼，看團隊習慣和場景需要，不影響 LLM 那一段。

把 SP-EXPO 也排程化

學會唐詩 demo 的排程技巧後，把同一套方法套用到 SP-EXPO，就是真正可以上線的自動化：每天固定時間，自己產出一份業務報告。

這裡提供兩個對應的排程腳本，設計上跟唐詩 demo 一致（「當下時間 + 1 分鐘」觸發，方便驗證）：

體驗方式：把 6_sp_expo_demo.py、7_sp_expo_sheets.json 和這兩個腳本放在同一個資料夾，執行：

等一分鐘，資料夾會悄悄出現一份 YYYYMMDD SP-EXPO 彙總報告.md。畫面上沒有任何動靜，但 LLM 確實被呼叫了、下載了資料、產出了報告。

清理：

總結：這套方法能解決什麼？

在這次的體驗中，重點不在於過程中不使用 LLM 的工具層，而是最終交付的結果，不需要工具層也能持續運作。

從唐詩產生器到 SP-EXPO 報告，我們跨越了兩個量級——從「玩具」到「真實業務」，但用的方法完全相同。這就是 headless 模式最珍貴的地方：寫一次，用到各種場景。

在編寫代碼的過程中，我仍建議大家使用 IDE 進行代碼的編輯、測試。只是最終的產出，可以是一個封裝好的腳本。

對方只需要具備三個條件就能運行：

1. 將腳本加到 Windows Task Scheduler 中
2. 配置 LLM API（本次使用 Kiro 為例，但實際上可以使用任何第三方 API）
3. 有 LLM CLI 的工具層，運行代碼