Kiro Crew：讓 agent 工作跨會話持續的開源常駐工作臺

Kiro Crew 是 kirodotdev 開源的開發工作臺，採用 Apache 2.0 許可。它的定位很明確：一個「持久、自學習、自演進」的工作空間，可以跑在你自己的本機或遠端主機上，讓開發工作在一次會話結束之後繼續向前。多數 agent 會話在聊天視窗關閉時就結束了。Kiro Crew 反其道而行：它以一個常駐的 Gateway 程序為核心，把會話、記憶、計劃任務和任務檢查點都儲存下來，在兩次對話之間依然保持工作。 從公開的專案說明可以拆出四層結構。第一層是 Gateway，一個常駐服務，預設監聽 5476 埠；官方 Docker 示例把它繫結在 127.0.0.1，說明預設姿態是隻對本機開放。第二層是入口：桌面應用、Web 儀表盤和命令列，外加 Slack、Discord 等連線工具，同一項工作可以在這些入口之間接續。第三層是 agent 後端：預設 agent 執行在 kiro-cli 之上，透過 ACP 後端接入，同時專案提到還有其他經過驗證的 ACP harness。第四層是 Kiro Crew Apps：把一個為特定任務定製的介面，與 agents、skills、計劃任務、整合和後端服務打包在一起。

它的核心機制可以歸結為三件事。第一是持久化。會話、記憶、計劃任務和任務檢查點在 Gateway 重啟後依然存在。檢查點的意義在於：多步任務被打斷後，可以從斷點恢復，而不是整個重來。第二是無人值守執行。多步任務可以在無人盯著終端時執行，週期性作業按你設定的日程觸發，心跳（heartbeat）持續監控系統，直到出現需要人介入的情況才提醒。第三是自學習。專案稱糾正和任務失敗會被沉澱為持久的經驗。需要說明的是，我們拿到的 README 節選在這裡被截斷，具體如何儲存、如何複用這些經驗，要以官方文件為準。 分發和安裝方式透露了工程上的取捨。一行命令 curl -fsSL https://download.crew.kiro.dev/cli.sh | sh 會安裝已簽名的 Stable wheel，無需克隆倉庫或自己構建前端。用 --version 可以固定版本，但最低只能固定到 0.1.2，原因是 0.1.0 和 0.1.1 釋出時還沒有清單簽名，無法驗證。這說明團隊把供應鏈完整性放在了明處。專案還提供三個釋出通道：Stable 為預設，Insider 跟隨候選釋出，Nightly 跟隨 main 分支。容器方面，Gateway 以多架構公共映象釋出在 GHCR，適合常駐伺服器。原始碼構建要求 Python 3.12 以上、Node.js 22.12 以上，流程是 make build，然後依次執行 kirocrew setup、kirocrew doctor 和 kirocrew gateway。其中 doctor 命令用來在啟動前檢查環境。

關於效能，要說清楚一點：我們看到的公開材料裡沒有基準測試資料，沒有延遲、吞吐或任務成功率的對比，因此本文不會編造任何數字。可以做的是定性判斷成本結構。Kiro Crew 自身是排程與持久化層，真正的推理開銷來自它所連線的 agent 後端，預設是 kiro-cli 背後的模型呼叫。常駐的計劃任務和心跳意味著持續的後臺呼叫，團隊需要為這部分自行做預算，併為心跳設定合理的頻率。換來的好處是人的時間：同一件事不必每次重新交代背景。 對開發者和企業的影響，主要在三個方面。其一，工作方式從「一次性對話」變成「長期隊友」，記憶和檢查點讓上下文不再隨會話消失。其二，自託管加 Apache 2.0 許可，讓程式碼和資料留在自己的硬體上，這對有合規要求的團隊很有吸引力。其三，ACP 相容的多 harness 設計降低了對單一 agent 的繫結。Slack 和 Discord 的接入，則讓它能進入團隊已有的溝通流程。Trendshift 上的榜單標記也顯示它在釋出初期就受到了開發者社群的關注。 侷限同樣明顯。第一，預設後端要求你另行安裝並登入 kiro-cli，首次啟動會檢查這一前置條件，缺失時給出官方指引。第二，無人值守執行放大了許可權風險：一個能長期自主執行任務的 agent，必須配合沙箱、最小許可權和審計，專案為此提供了安全策略文件和沙箱設定，使用者應當認真閱讀。第三，「自學習」是一把雙刃劍：被固化下來的錯誤經驗會反覆影響後續任務，需要有人審查和修剪。第四，專案版本仍然很早，文件裡以 0.6.0 作為固定版本的示例，介面和行為可能繼續變化。此外，專案含有匿名使用遙測章節，企業使用者在部署前應當確認其範圍和關閉方式。 如果把它放進團隊的日常流程，可以設想這樣的用法：白天由工程師透過桌面應用或 Slack 交代任務，夜裡 agent 繼續執行多步工作並在檢查點儲存進度；定時作業負責例行巡檢，心跳在系統出現異常時才提醒負責人。第二天早上，同一個會話裡的記憶和進度都還在，人只需要審閱結果，而不是重新搭建上下文。這種模式對長週期、低頻但需要持續跟進的工作尤其合適，比如依賴升級、日誌巡查、文件同步和迴歸檢查。當然，這些場景是基於公開功能描述的推演，具體效果取決於所接 agent 的能力和你設定的許可權範圍。 總的來看，Kiro Crew 值得關注的地方，不在於某個單項指標，而在於它把「agent 要長期線上」這件事當作一等公民來設計：持久化的狀態、可恢復的任務、定時與心跳、多入口接續、簽名分發。能否兌現承諾，要看自學習的質量和無人值守時的安全邊界，這兩點值得在後續版本中持續觀察。