title: "我花了一整天體驗 Kiro Crew。這東西到底能做什麼？"
published: true
description: "4 分鐘示範：AI 代理調查 P1 延遲尖峰、建立預防自動化，並整理組織內部知識。每起事件成本：$0.04。"
tags: agents, ai, showdev, discuss
cover_image: https://img.youtube.com/vi/6-1sYpXk1XQ/maxresdefault.jpg
series: "Kiro Crew"
https://www.youtube.com/watch?v=6-1sYpXk1XQ
我把整個過程都錄下來了。從頭到尾，四分鐘。
上週我把 Kiro Crew 介紹成一個開源 AI 代理協調器。概念很有意思，但概念不會把軟體交付出去，也不會在凌晨 3 點幫你修好正式環境。
所以我把它丟進我的 DevOps 專案裡，直接給它一個情境：延遲尖峰警報。就是那種會把你從睡夢中吵醒，讓你盯著 CloudWatch 皺著眉看 40 分鐘，最後還得寫一份沒人會看的事後檢討報告的那種事。
目錄
情境
我的專案倉庫裡有部署提交、依賴套件升級，以及設定變更（這是任何團隊都會累積的 git 歷史）。我把一則警報丟給代理，假裝是 PagerDuty 觸發的：
支付服務的延遲在凌晨 3:12 從 200ms 飆到 4,500ms。這是 22 倍的增幅。客戶在結帳時發生逾時。
沒有人醒著。值班工程師人在不同時區。等他們切換情境、理解系統並開始調查時，20 分鐘已經過去。也可能是 40 分鐘。
AI 代理能不能先做第一線應對？不是修好服務（這仍然需要人類），而是先蒐集證據、形成假設，等工程師打開筆電時就已經有答案在那裡。
調查（不到 60 秒）
我直接把警報貼進 Kiro Crew（在正式環境中，這會自動由 PagerDuty webhook 送進來）：
URGENT P1: Our payment-service hit 4500ms latency (normal is 200ms) at 3:12 AM.
Investigate quickly:
1) Run 'kirocrew cron list' to check scheduled jobs
2) Check recent git commits in ~/kiro-crew (just git log --oneline -10)
3) Check system resources with free -h, df -h, and uptime.
Give me a quick incident summary with root cause hypothesis.代理並行執行了七個診斷步驟。33 秒後，它透過關聯 git 歷史、cron 排程與系統資源資料，產出了一份完整的事件摘要：
排程工作： 正常。事件發生時間附近沒有任何 cron 工作被觸發。
最近部署： 可疑。找到 deploy: payment-service v2.3.1 to production，以及 chore: bump dependencies (aws-sdk, pg-pool) 和 fix: increase connection pool timeout to 30s。
系統資源： Load average 為 4.31（偏高）。記憶體與磁碟空間正常。
根因假設： 資料庫連線池在近期依賴套件升級後出現設定錯誤。新的 pg-pool 版本加上修改過的連線逾時，導致在凌晨 3:12 左右發生連線耗盡。
如果是人類工程師做同樣的調查，至少要 15 到 30 分鐘。前提還是他們知道要看什麼。
代理的假設也許是錯的。它只是值班工程師的起點，不是最後判決。但當你早上 7 點打開筆電時，眼前已經有一個帶著證據的假設，這真的很有價值。
把它自動化，讓它別再吵醒你
調查是被動反應。真正的價值在於預防。
Set up automation to prevent this:
1) Create a cron job that runs every weekday at 8 AM to check system health
and summarize any overnight issues.
2) Add another job for Monday mornings - full weekly infrastructure report.
Use descriptive names so the team knows what each job does.代理建立了兩個現在會自動執行的排程工作。當我週一早上進辦公室時，會有一份報告等著我，上面寫著「一切正常」或「這是昨晚發生的事」。
過去幾年，我在三個客戶現場一直手動做這件事。每個週一都要花 30 分鐘拉同樣的指標。現在，這些都只是……自動完成了。
建立組織知識
這是大多數人會跳過、然後在六個月後後悔的部分。
Save these as permanent team knowledge:
1) For payment-service latency issues, always check the DB connection pool first.
2) Our SLA target is 99.95% uptime with p99 latency under 500ms.
3) Escalation path: on-call engineer → team lead @sarah → VP Eng @mike.
4) All production services run in us-east-1 with failover to us-west-2.代理把這四項都持久化了。下次有人調查 payment-service 問題時，這些背景資訊已經載入。不用翻 Confluence。也不用再問「我要找誰升級處理？」
知識原本存在於人的腦中。人一離開，知識也跟著走了。這裡不一樣，知識是活的。代理在調查時會直接使用它。這就是能被自動套用的組織記憶。
儀表板也證明一切都真的有在運作。排程分頁顯示 cron 工作正在執行。知識分頁顯示這四項內容已被儲存並建立索引。還有 137 條打包好的 deny pattern，即使代理擁有廣泛授權，也能阻擋破壞性命令。
為什麼這對企業團隊很重要
在 Big 4 顧問專案待了 10 多年後，我看到的模式始終一樣：
- 事故發生
- 聰明的工程師花 30 到 60 分鐘做偵查
- 他們修好問題
- 有人寫事後檢討報告
- 沒人看
- 三個月後又發生同類型事故
Kiro Crew 在三個地方打破了這個循環。偵測時間從幾分鐘降到幾秒。預防變成自動化（健康檢查只要設一次，之後永遠執行）。知識會持續累積，而不是逐漸流失。
這次示範完整工作流程的總耗時：4 分鐘 36 秒。
這要花多少錢
一次調查大約會用掉 3,000 到 5,000 個輸入 token，以及 1,500 到 2,500 個輸出 token。以 Claude Sonnet 的計價來看，每起事件成本大約是 $0.02 到 $0.04。每天的健康檢查 cron 會再增加 $0.05/天。
拿這個成本去和凌晨 3 點把年薪 20 萬美元的資深工程師叫醒相比。
自己試試看
Kiro Crew 是開源專案（Apache 2.0，截至撰文時版本為 v0.1.2）。
前置需求： Python 3.10+、Node.js 18+、已登入的 Kiro CLI、以及一個已初始化 git 的專案目錄。
# 安裝
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
# 啟動 gateway
kirocrew gateway
# 開啟網頁儀表板
kirocrew token先在倉庫裡建立一些類部署風格的提交，讓代理有歷史可以關聯（或者直接用一個本來就有這些提交的既有專案）：
git commit --allow-empty -m "deploy: payment-service v2.3.1 to production"
git commit --allow-empty -m "chore: bump dependencies (aws-sdk, pg-pool)"在儀表板把核准模式設為 "Trust"，貼上調查提示，然後看它怎麼運作。
https://github.com/kirodotdev/KiroCrew
如果是正式環境，我會怎麼做
在正式環境中，我會透過 PagerDuty webhook 觸發，而不是手動輸入。Kiro Crew 支援 HTTP 觸發，因此在警報一響起時，調查就會立刻開始。
我也會用 deny list 來限制代理可用的工具。不要在正式環境給它廣泛的 shell 存取權。自主調查可以，但重啟服務仍然需要人工核准。復原流程要保留 human-in-the-loop。
在可觀測性方面，我會透過 MCP 工具把它連接到 CloudWatch、Datadog 或 Grafana。並且要主動建立知識。從第一天就把架構決策、SLA 目標和已知故障模式餵給它，不要等到第一起事故之後才做。
這是我 Kiro Crew 系列的第二篇。第三篇會深入談安全模型，因為企業要不要採用，往往就取決於這個問題。
對於自主 AI 代理，最讓你不安的是哪一部分？是自主性？是影響範圍？還是它會在你睡覺時自己跑起來？我在各個客戶專案裡也一直在思考同樣的問題，而且到現在還沒有簡單的答案。
想看更多 AWS 架構、DevOps 和 AI 基礎架構內容，歡迎追蹤我：
作品集 | LinkedIn | Dev.to | YouTube | Email | AWS Builder Center
原文出處：https://dev.to/aws-builders/i-spent-a-day-with-kiro-crew-heres-what-it-actually-does-fk0
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
