Kun：共用同一本地運行時的 AI Agent 桌面與終端工作台
Local-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.
秒懂
- 它是什麼？
- Kun 以單一本地運行時同時驅動桌面 GUI 與終端 TUI，把 Code 與 Work 兩種任務模式放進同一個工作區。本文從架構、啟動方式、授權限制與適用邊界檢視這個專案。
- 適合誰用？
- Kun 適合需要把 AI 任務的計畫、審批與證據留在本機，且同時使用桌面介面與終端機的個人開發者或研究人員。因為授權是 PolyForm Noncommercial 1.0.0，任何商業使用、SaaS 託管或整合進商業產品都需要作者另行書面授權，這會直接排除以公司名義部署的場景。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
一個運行時，兩種介面
Kun 的核心主張不是又多了一個 AI 助手，而是把桌面 GUI 與終端 TUI 綁在同一個本地運行時上。README 描述這個運行時叫做 kun serve，GUI 與 TUI 共享執行緒、目標、計畫、審批與背景任務。意思是你在桌面版開了一個任務，切到終端機繼續操作時，看到的是同一個任務狀態，不是兩套各自為政的對話紀錄。這個設計直接回應一個常見痛點：圖形介面適合觀察與審閱，終端適合專注打字，但多數工具要嘛只有 GUI，要嘛只有 CLI，兩者切換時上下文就斷了。Kun 用同一個運行時把這兩種使用情境接起來。對工程師來說，這意味著你可以把 Kun 當成背景服務，桌面版負責視覺化檢視 Diff 與審批，TUI 負責快速下指令。架構上這比 Electron 外殼包一個 CLI 的做法更一致，因為狀態不是同步出來的，而是本來就同一份。
Code 與 Work：兩種任務模式的分工
Kun 把工作分成兩個主模式。Code 模式面向軟體交付，包含專案上下文、檔案編輯、終端、Git 與 Worktree、Diff、測試與審查。Work 模式則涵蓋寫作、資料整理、文件分析與簡報產出，可以編輯 Markdown、預覽並引用 PDF 或 Office 文件、分析試算表，還能從大綱建立簡報。值得注意的是 Office 檔案在 Work 模式保持唯讀，這是一個明確的安全界線：AI 可以讀取內容但不會直接竄改原始 Office 文件。Code 模式內還提供 Design 畫布，可以在同一個任務中切換，把原型或設計系統的產出轉成 Design 到 Code 的上下文。這種設計把設計與開發放進同一條任務流，而不是分屬兩個產品。從 README 的流程描述看，任務會經歷澄清目標、形成計畫、執行與協作、檢查證據、交付或繼續。計畫與需求預設可以存進專案，因此能進版本控制。
從目標到證據的執行機制
Kun 的執行流程不是單純叫模型寫程式。README 列出五個步驟：澄清目標、形成計畫、執行與協作、檢查證據、交付或繼續。Agent 會讀取工作區上下文，制定計畫，呼叫工具，修改檔案，然後執行驗證，最後把證據留在任務旁邊。這個「證據」概念是關鍵。它指的是 Diff、測試結果、瀏覽器或終端輸出，這些都關聯到具體任務，而不是散落在對話紀錄裡。需求變更時，任務可以繼續、分叉、歸檔或重新規劃。這種設計把 AI 的工作成果變成可審計的產物，而不是一次性回覆。對需要事後檢討或恢復流程的專案來說，這比純聊天介面更接近真實開發流程。但 README 沒有詳細說明證據具體如何儲存，是純文字紀錄還是結構化資料，這點需要看程式碼或實際操作才能確認。
啟動方式：桌面版、TUI 與原始碼
對一般使用者，直接從 GitHub Releases 下載安裝包。macOS 有 .dmg 或 .zip，Windows 是 .exe，Linux 是 .AppImage 或 .deb。啟動後先選語言，設定一個模型 Provider，然後打開本地專案或建立工作區。從 0.3.8 開始，TUI 不再單獨分發壓縮包，必須用桌面應用內建的終端指令啟動。在專案目錄執行 kun 即可。這是一個重要的變更：如果你只想用 TUI，還是得先裝桌面版。從原始碼跑需要 Node.js 22.19 以上與 npm，指令是 git clone、npm ci、npm run dev。開發用指令包含 dev:tui 啟動 TUI、typecheck、lint、test、build，以及 dist:mac、dist:win、dist:linux 打包。中國大陸網路慢時可以用 npmmirror 來源執行 npm ci。整體啟動流程不算複雜，但依賴 Node.js 版本，舊環境可能要升級。
本地優先的界線：資料與模型
Kun 強調本地優先，但 README 說得很直接：本地優先不等於永不連網。工作階段、偏好、日誌與運行時資料預設存在本機，但如果你選擇雲端模型，提示、附件與任務上下文會送給 Provider。這是一個必須先確認的點。README 列出支援的模型生態，包括 ChatGPT、Claude、Gemini、Cursor、Ollama、DeepSeek、Kimi、GLM、Qwen、MiniMax 與小米 MiMo。你可以用 API、訂閱或自訂 Provider。工具權限、敏感操作與擴充權限會在介面中呈現，由使用者決定是否授權。這個設計把資料流向的決定權留給使用者，但前提是你真的會去讀每個 Provider 的資料政策。對處理機密程式碼的人來說，即使本地優先，只要接上雲端模型就等於把程式碼片段送出，這不是 Kun 能解決的問題，而是模型服務的本質。
自動化與擴充：Loops、MCP、Skills
Kun 提供 Scheduled tasks、Loops、Hooks、MCP、Skills 與可安裝擴充來處理重複流程。文件分別對應 workflow-loop.md、project-mcp-skills.md 與 extensions/README.md。MCP 讓 Agent 可以接外部工具，Skills 則是可重用的能力封裝。Loops 可能用於需要反覆執行的任務，例如持續監看某個條件。但 README 對這些機制的描述非常簡略，只列出名稱，沒有解釋 Loops 與 Scheduled tasks 的差異，也沒有說明 Hooks 掛在哪些事件上。這是一個明顯的資訊缺口。如果你打算用 Kun 做自動化，現有材料不足以判斷它是否比直接寫 shell script 或 CI pipeline 更好。你需要翻閱 docs 目錄下的文件，或直接看程式碼。這種說明不足在早期專案常見，但對採用決策來說是阻礙，因為自動化機制的穩定性與錯誤處理往往決定實際可用性。
授權限制與維護成本
Kun 使用 PolyForm Noncommercial License 1.0.0，README 明確說僅供學習、研究與非商業用途。商業使用、商業分發、SaaS 或託管服務、轉售或整合到商業產品都需要作者單獨書面授權。這個授權是最大的採用門檻。對公司或自由接案者來說，這不是一個可以隨便拿來用的工具。即使你只是內部使用，只要屬於商業活動，就可能踩線。維護成本方面，專案最後一次推送是 2026 年 9 月，最近有 0.3.9、0.3.8、0.3.7 三個版本，發布頻率看起來不低，但無法從 README 判斷長期維護承諾。貢獻流程要求外部貢獻者接受 CLA，日常集成分支是 develop。這代表專案有正式的治理結構，但同時也意味著如果你想自行修改並用於商業，授權問題會更複雜。建議在投入任何整合之前，先寫信給作者確認商業授權條件，否則後續升級或法律風險都無法評估。
編輯結論
Kun 適合需要把 AI 任務的計畫、審批與證據留在本機，且同時使用桌面介面與終端機的個人開發者或研究人員。因為授權是 PolyForm Noncommercial 1.0.0，任何商業使用、SaaS 託管或整合進商業產品都需要作者另行書面授權，這會直接排除以公司名義部署的場景。不適合的人包括：需要多人協作或雲端同步的團隊，因為 README 只描述單機運行時；需要商用授權的組織，因為授權條款明確限制非商業用途。採用前應先驗證三件事：第一，確認你選的模型 Provider 的資料政策，因為選擇雲端模型時提示與任務上下文會送出；第二，在一個小型專案上跑通從目標到證據的完整流程，確認審批機制符合你的工作習慣；第三，檢查 0.3.8 之後 TUI 不再單獨分發，必須透過桌面應用內建終端啟動，這是否影響你的操作環境。最後的判斷是：Kun 的單運行時設計有實際價值，但授權邊界讓它現階段只適合非商業的個人用途。
社群筆記