Amazon Q Developer CLI：終端機裡的代理式對話，以及它停止維護之後
✨ Agentic chat experience in your terminal. Build applications using natural language.
秒懂
- 它是什麼？
- 這個 Rust 專案把代理式對話放進終端機，用自然語言操作 shell 與檔案。README 開頭已宣告它不再積極維護，功能主線轉往閉源的 Kiro CLI；本文只根據倉庫提供的材料，說明它的機制、安裝路徑、授權與該不該採用。
- 適合誰用？
- 已經在用、且只需要關鍵安全修補的團隊，留在 v1.19.x 這條線上風險可控，但別把它當成新功能的來源。要新功能的人應該直接評估 Kiro CLI，因為 README 明講 Amazon Q Developer CLI 已由 Kiro CLI 取代，而 Kiro CLI 是閉源產品。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 22 天前。
- 用什麼語言寫的？
- 主要是 Rust（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它把 shell 操作變成一段對話，代價是綁在 AWS 的登入流程上
這個專案要解的問題很具體：工程師在終端機裡做一連串瑣碎動作，查檔案、拼指令、翻錯誤訊息，每一步都要自己切換上下文。Amazon Q Developer CLI 把這些動作收進一個可對話的介面，README 對它的定位是「Agentic chat experience in your terminal. Build applications using natural language.」，也就是讓使用者用自然語言驅動建置流程。它服務的對象是長時間待在終端機、不想離開 shell 去開瀏覽器或 IDE 的人。
但這個便利有一條前置條件。開發流程裡的第一個子命令是登入，README 給的例子是 `cargo run --bin chat_cli -- login`。也就是說，對話能力不是本地模型跑出來的，而是要先通過登入取得服務。這對已經在 AWS 生態裡的團隊幾乎沒有摩擦，對不想把開發對話送進外部服務的團隊則是當場出局。這個取捨在 README 裡沒有討論，它只給了指令。
Rust 工作區加一個 chat_cli binary，前端與代理邏輯分層
從倉庫結構看，這是一個 Cargo workspace。README 的 Project Layout 列出四個位置：`chat_cli`（放在 crates/chat-cli/）是使用者實際打交道的 `q` CLI，`scripts/` 放營運與建置相關腳本，`crates/` 收所有 Rust crate，`docs/` 放技術文件。整個專案的 primary language 標示為 Rust，但 topics 裡同時出現 TypeScript，表示倉庫內並非只有單一語言。
這種切法的意義在於：對話介面與代理邏輯被拆成可獨立編譯的 crate，而不是全部塞進一個 main。要理解某個行為，得先判斷它落在哪一層。README 沒有提供 crate 之間的依賴圖，也沒有說明代理如何決定要呼叫哪個工具、對話歷史怎麼保存、工具呼叫的權限邊界在哪。這些是評估時最想知道的部分，而材料裡沒有。`docs/` 目錄被標為技術文件所在，但 README 沒有列出裡面有什麼，所以只能說：進一步的機制細節要從那份文件或原始碼本身取得，本文無法代為確認。
安裝路徑與從原始碼編譯的實際指令
一般使用者走安裝包。macOS 有兩種：直接下載 DMG，或 `brew install --cask amazon-q`。Linux 方面 README 指向官方文件的三個段落，分別對應 Ubuntu/Debian、AppImage 與其他替代建置，實際指令不在倉庫裡，要連到 docs.aws.amazon.com 的安裝頁。
想從原始碼編譯的人，README 把前置條件寫得偏窄：MacOS 需要 Xcode 13 或更新版本，以及 Brew。Linux 與 Windows 的前置條件沒有列出。流程是先 `git clone https://github.com/aws/amazon-q-developer-cli.git`，再用 rustup 裝工具鏈：`rustup default stable` 與 `rustup toolchain install nightly`，另外 `cargo install typos-cli` 用來檢查拼字。日常動作用 `cargo run --bin chat_cli` 編譯並執行，`cargo test` 跑測試，`cargo clippy` 跑 lint，`cargo +nightly fmt` 格式化。要帶子命令時寫成 `cargo run --bin chat_cli -- {subcommand}`。這裡有個容易踩到的細節：格式化用的是 nightly 工具鏈，而預設是 stable，所以 CI 上要兩條工具鏈都裝，否則 `cargo +nightly fmt` 會直接失敗。
README 第一段就宣告停止積極維護，這是採用決策的核心
README 最上方有一段 IMPORTANT 標註，內容是這個開源專案已不再積極維護，只會收到關鍵安全修補，Amazon Q Developer CLI 現在以 Kiro CLI 的形式提供，而 Kiro CLI 是閉源產品，最新功能與更新要走 Kiro CLI，Kiro CLI 的問題要回報到另一個倉庫。
這段話把專案切成兩種狀態。已經在用的人拿到的是穩定性與安全修補，不是新功能。正在選型的人拿到的是一個明確的替代路徑，但那個路徑沒有原始碼。這是本文最該講清楚的一點：把這個倉庫當成可長期演進的基礎，與 README 的敘述不符。
還有一個容易誤讀的地方。倉庫的 License 欄位標示 Apache-2.0，README 的 Licensing 段落則寫明這個 repo 是 MIT 與 Apache 2.0 雙授權，兩份檔案分別是 LICENSE.MIT 與 LICENSE.APACHE。欄位與 README 不一致時，以倉庫內實際的授權檔案為準。另外 README 附上商標聲明：Amazon Web Services 及相關標記是 AWS 的商標或商業外觀，不得用於非 AWS 的產品或服務，也不得以可能造成混淆或貶損 AWS 的方式使用。這對想 fork 後重新散布的人是一條實際限制，不是形式條款。
最後一個現實訊號是版本節奏。近期釋出的是 v1.19.7（2025-11-17）、v1.19.6（2025-11-13）、v1.19.5（2025-11-12），三版集中在同一週。這種密集的修補節奏與「只收關鍵安全修補」的敘述可以並存，但它不代表功能路線仍在推進。
與 Kiro CLI 的差別不在功能清單，在原始碼是否可見
README 指名的替代品是 Kiro CLI，並附上 kiro.dev/cli 與問題回報的 GitHub 位址。兩者的差異不是某個功能有沒有做，而是授權模式：這個倉庫是 MIT 加 Apache 2.0 的開源專案，Kiro CLI 是閉源產品。
這個差異會直接影響幾件事。要審計程式碼、要自己打補丁、要把工具鏈固定在自家環境的人，只能留在這個倉庫。想要 README 所說的最新功能與更新的人，只能接受看不到原始碼的前提。兩邊不是同一條路上的前後版本，而是分岔後的兩條路。
至於其他終端機代理工具，材料裡完全沒有提及，本文不對它們的機制或差異做任何陳述。
什麼情況下這個工具是錯的選擇
第一種情況是資料不能離開你的環境。登入是使用流程的第一步，對話要經過登入後的服務，README 沒有提供任何本地模型或離線模式。如果法規或內部政策不允許開發對話外送，這個工具在架構上就不成立，不是設定調一調能解決的。
第二種情況是把新功能當成採用理由。README 已經說明只收關鍵安全修補，任何期待上游持續加功能的計畫都會落空。
第三種情況是團隊沒有 Rust 能力卻想自行維護分支。倉庫是多 crate 的 Rust workspace，README 列出的前置條件以 macOS 為主，`docs/` 的內容在 README 中沒有展開，機制細節得自己讀原始碼。沒有能力讀的人，遇到問題時能做的很有限。
還有一種要留意：README 把 `cargo run --bin chat_cli` 當成主要開發入口，這與安裝後的 `q` 指令是兩條不同的路徑。用安裝包的使用者與從原始碼編譯的開發者，跑的未必是同一份東西，回報問題時要講清楚是哪一種。
授權、維護成本與要先查證的事
授權方面，README 寫的是 MIT 與 Apache 2.0 雙授權，對應 LICENSE.MIT 與 LICENSE.APACHE 兩個檔案，倉庫欄位則只標 Apache-2.0。雙授權通常表示使用者可擇一遵循，但實際條文要看檔案內容，本文不提供法律意見。商標那一段是額外限制：AWS 的標記不得用於非 AWS 的產品或服務，也不得以造成混淆或貶損的方式使用，這會影響你 fork 之後怎麼命名與對外描述。
維護成本要分開算。追上游幾乎沒有成本，因為上游只出關鍵安全修補，這是停止積極維護帶來的少數好處之一。自行維護的成本則落在建置鏈上：需要 stable 與 nightly 兩條 Rust 工具鏈、`cargo install typos-cli`，以及 macOS 上的 Xcode 13 以上與 Brew。要改動代理行為的人，還得先摸清 crates/ 底下的 crate 邊界，而 README 沒有給依賴圖。
採用前建議先驗證三件事，而且每一件都能用具體指令確認。第一，跑一次 `cargo build` 與 `cargo test`，確認你的環境能編過，特別是 nightly 那條。第二，打開 LICENSE.MIT 與 LICENSE.APACHE，確認你散布 binary 的方式符合哪一份。第三，翻 `docs/` 目錄，確認代理的工具呼叫與權限邊界有沒有寫在裡面。這三件沒過，後面的評估都是空的。
編輯結論
已經在用、且只需要關鍵安全修補的團隊，留在 v1.19.x 這條線上風險可控，但別把它當成新功能的來源。要新功能的人應該直接評估 Kiro CLI，因為 README 明講 Amazon Q Developer CLI 已由 Kiro CLI 取代，而 Kiro CLI 是閉源產品。打算自行 fork 或長期維護的團隊，先確認三件事：crates/ 底下的 Rust crate 是否足以支撐你要改的路徑、chat_cli 這個 binary 的建置鏈是否能在你的 CI 上跑起來、以及 LICENSE.MIT 與 LICENSE.APACHE 兩份授權檔案對你散布 binary 的方式有什麼要求。這三項沒查清楚之前，不要把它排進任何有交付期限的計畫。
社群筆記