Kun 拆解：桌面 GUI 与 TUI 共用一套本地运行时的 AI Agent 工作台

Kun 要解决的是会话断裂，不是模型能力

多数编码 Agent 的形态是一个对话框：你问，它答，改完文件，会话结束。下次打开，计划、审批记录、跑过的测试都不在原处。Kun 的定位写在 README 第一段里，把 AI 从回答问题推进到完成工作，并让 Agent 读取工作区上下文、制定计划、调用工具、修改文件、运行验证，把证据留在任务旁。它把任务组织成五个阶段：澄清目标、形成计划、执行与协作、检查证据、交付或继续。这个流程本身不新鲜，关键在于 README 说明需求和计划默认可以保存在项目中，因此能进入版本控制、代码审查和恢复流程。目标读者是需要在真实项目里追踪 Agent 做过什么的人，而不是只想让模型补一段代码的人。Work 模式把同一套流程搬到写作、资料整理、文档分析和演示产出上，Office 文件在文档里被描述为保持只读。

一个 kun serve 运行时，两个前端

Kun 的架构判断集中在一点：GUI 和 TUI 不是两套产品。README 说两者通过同一个本地 `kun serve` 运行时共享线程、目标、计划、审批和后台任务，而不是两套彼此割裂的会话。桌面 GUI 承担观察、审阅和控制过程，终端 TUI 承担键盘密集的工作。从 0.3.8 起不再单独分发 TUI 压缩包，终端命令由桌面应用内置提供，在项目目录里执行 `kun` 即可。这个选择有代价：TUI 不再是可独立安装的组件，想用终端就得先装桌面应用。好处也直接，审批状态和后台任务不会在两个入口之间分叉。仓库的语言是 TypeScript，桌面端用 Electron 加 React，主题标签里同时出现 electron、react 与 tui。记忆架构方面，README 的致谢部分说明参考了 Nowledge Mem 公开文档中的 Thread / Memory 分离、来源追踪与混合检索理念，实现保持独立。这是设计参考，不是代码依赖。

Code 与 Design 在同一任务里切换

Code 模式的职责是软件交付：项目上下文、文件编辑、终端、Git 与 Worktree、Diff、测试和审查。Design 不是独立模式，README 明确说它是在同一个 Code 任务中切换的画布，用来沉淀原型、设计系统和 Design 到 Code 的上下文。这个安排的好处是设计产物和实现产物共享同一份任务上下文，不必在两个工具之间复制粘贴。Work 模式则换一套界面：工作区文件树、任务启动器、Work assistant，可以起草 Markdown、总结或询问文档、分析电子表格、从大纲创建演示文稿，还提到用白板梳理想法。把写作和编码放进同一个运行时，意味着模型 Provider、审批机制、扩展权限这些底层设施只需要配置一次。对同时写代码和写文档的人，这比在两个应用之间切换省事；对只做其中一件事的人，多出来的界面就是噪音。

从源码跑起来需要哪些命令

README 给出的前置条件是 Node.js 22.19 以上、npm，以及至少一个可用的模型连接。源码运行流程是 `git clone https://github.com/KunAgent/Kun.git`、`cd Kun`、`npm ci`、`npm run dev`。`npm run dev` 会构建运行时并启动 Electron 开发环境，`npm run dev:tui` 构建运行时并启动终端 TUI。其余脚本包括 `npm run typecheck`、`npm run lint`（文档说明会运行 ESLint 与文件大小检查）、`npm run test`、`npm run build`，以及 `npm run dist:mac`、`dist:win`、`dist:linux` 三个平台打包命令。中国大陆网络较慢时，README 建议改用 `npm ci --registry=https://registry.npmmirror.com`。不想编译的人可以从 GitHub Releases 下载安装包，macOS 提供 `.dmg` 与 `.zip`（Apple Silicon 和 Intel），Windows 提供 `.exe`（x64），Linux 提供 `.AppImage` 与 `.deb`（x64）。启动后需要先配置一个模型订阅、计划、API 或自定义 Provider，再打开本地项目。

本地优先的边界在哪里

README 有一节标题就叫本地优先，不等于永不联网，这句话值得原样记住。会话、偏好、日志和运行时数据默认保存在本机，但一旦选择云端模型，提示、附件和任务上下文就会发送给所选 Provider，README 要求使用前确认该服务的数据政策。也就是说，本地优先约束的是存储位置，不是数据流向。想避免上下文离开本机，只能接自托管模型。工具权限、敏感操作和扩展权限会在界面中呈现，是否授权仍由使用者决定。Provider 覆盖范围在 README 里列出为 ChatGPT / Codex、Claude、Gemini、Cursor、Ollama、DeepSeek、Kimi、GLM、Qwen、MiniMax、Xiaomi MiMo 等，但文档同时提醒登录方式、模型、地区与额度取决于当前版本和 Provider 规则。这类清单会随版本变化，不要把它当成长期承诺。

PolyForm Noncommercial 1.0.0 划出的硬边界

仓库的 LICENSE 徽章与许可证章节都指向 PolyForm Noncommercial License 1.0.0，README 写明仅供学习、研究和非商业用途。商业使用、商业分发、SaaS 或托管服务、转售，以及集成到商业产品中，都需要作者的单独书面授权。仓库元数据里的 License 字段显示为 NOASSERTION，与 README 的表述存在出入，判断时以 LICENSE 文件和 README 文字为准。这条边界比多数开源项目的许可严格得多，也直接决定了适用人群：公司内部拿它跑生产任务、把它包装成对外服务、或者把 Agent 能力嵌进自家产品，都属于需要单独授权的范围。这里不构成法律意见，涉及具体用途应当自行确认授权条件。另一个需要留意的是贡献流程，日常集成分支是 `develop`，PR 需要以 `develop` 为目标分支，外部贡献者还要接受 CLA。

什么时候该换成别的工具

Kun 的体积和架构决定了它不适合所有人。它依赖 Electron 桌面应用，TUI 从 0.3.8 起不再独立分发，所以只想在服务器或容器里跑一个纯命令行 Agent 的场景，Kun 不是顺手的选择，Aider 这类直接操作 Git 仓库、以命令行交互为主的工具更贴合。如果需求是把 Agent 嵌进自己的 CI 或后端服务，PolyForm Noncommercial 1.0.0 会在授权环节就拦住，此时 Apache-2.0 或 MIT 许可的项目更省事。Work 模式里 Office 文件保持只读，需要就地修改 `.docx` 或 `.xlsx` 的流程得另找工具。README 没有给出性能数据、内存占用或并发任务上限，仓库材料里也没有可核实的基准，这些只能自己实测。版本节奏可以参考：v0.3.7 到 v0.3.8 相隔九天，v0.3.8 到 v0.3.9 在同一天内发布，说明迭代较快，升级前应当先看 release notes。

编辑结论

个人开发者、研究者、以及需要在本地项目里保留计划与审批记录的独立工作者，可以先用 GitHub Releases 的安装包跑一个范围明确的小任务，确认模型 Provider 能连上、工作区文件读写符合预期，再决定是否把日常流程搬进去。以商业分发、SaaS 托管或把 Agent 能力嵌进自家产品为目标的团队不应采用，PolyForm Noncommercial 1.0.0 明确要求这类用途取得作者的单独书面授权，这不是配置问题，而是许可证边界。动手之前先确认三件事：Node.js 是否达到 22.19 以上、`kun serve` 运行时与桌面端能否同时连上同一个会话、以及你选的 Provider 会把哪些提示与附件发到云端。

官方来源

1. Issues
2. KunAgent/Kun on GitHub
3. Project website
4. README
5. Releases