kdlbs/kandev

如果你已经在终端里用编码 Agent，并且感到逐个翻 diff、逐个审查难以扩展，Kandev 值得看一眼。它不是新的编码模型或助手，而是围绕你已装好的 Agent 搭建的控制台。

解决什么问题

开发者想同时把几个任务交给不同的编码 Agent，并且在上线前真正看懂每一处改动。现在的常见做法是开多个终端标签，每个 Agent 改同一份检出，审查时只能翻原始输出。Kandev 改变了这一步：每个任务有自己的 git worktree，配一个包含文件树、编辑器、终端、浏览器预览和 git 改动面板的工作区。任务放在看板或流水线视图里，最终得到一批可以在同一处检查的 Agent 改动。

有什么不同

Kandev 的核心机制是 ACP（Agent Client Protocol）集成。它不自建 Agent，而是按你的选择启动已有工具的 CLI——列表中包括 Claude Code、Codex、GitHub Copilot、Gemini CLI 等——并放进执行器里运行。执行器可以是本地进程、Docker、Kubernetes、SSH 或远程云环境，profile 则把准备脚本、环境变量和凭据打包复用。worktree 隔离避免并发的 Agent 互相覆盖文件，工作流还能给不同步骤分配不同 Agent，例如一个负责规划，另一个负责审查。

好处是覆盖面：同一块看板可以混用不同厂商的 Agent，自动化还能按计划或 webhook 触发任务。代价是 Kandev 站在许多活动部件之上。每个受支持的 Agent 仍需单独安装并完成认证，而 worktree、隔离和执行器这些核心能力，取决于你的 git 和运行环境配置是否正确。这是给 Agent 工作用的基础设施，不是装完就不必再配置 Agent 的单一程序。

谁值得试

适合已经在本机跑通两三种 Agent CLI，希望让它们在不同分支上并行工作、再并排审查 diff 的开发者或小团队；也适合想要一套可共享、有明确约束的工作流，而不是每次随手提示的人。如果你只是偶尔用一个 Agent、习惯在单一检出里工作，或者不愿维护服务器、Agent 凭据和执行器配置，它就不太合适。自托管的分发方式让团队把代码和会话留在自己的机器上，但也意味着部署和更新需要有人负责。

使用条件与边界

你需要先装好要使用的 Agent CLI，还要准备所选执行器对应的运行环境：Docker 用于容器、Kubernetes 访问用于 Pod、SSH 目标用于远程会话，本地进程执行器则需要本地工具。worktree 和 SQLite 数据库默认放在 ~/.kandev，磁盘布局和备份由你负责。原生 Go 二进制内嵌了前端，应用服务器不需要 Node.js；只有 npm/npx 启动方式会引入 Node.js 依赖。支持 macOS、Linux，以及 Windows 的 WSL 或原生环境，但第三方 Agent 有各自的前置条件，例如列表中的 Cursor 需要 Cursor Pro。

Office 模式是面向持久 Agent 团队的实验层，包含角色、预算和审批等功能，默认关闭，项目也明确说明它还不是稳定的生产契约。可以把它当作预览，而不是团队流程的基础。

HotRepo 点评

HotRepo 对这个仓库只有一条带日期的观察：2026-10-25 它处在 1,006 stars，当天增加 4，并出现在当天的新项目榜上。只有这一个样本，无法判断热度能否持续，长期价值仍需观察。采用前具体要确认的是执行器文档：你计划使用的执行器是否支持团队已有的凭据和存储方式——这比 Agent 列表更能决定并行工作流是否可行。