Kandev：把一群 AI 编程 Agent 变成一条可审查的流水线

一、先说场景

想象这样一个下午：你手上有三个需求——给老接口补测试、把前端组件重构一遍、给新模块写文档。你打开三个终端，分别敲进 Claude Code、Codex 和 Gemini CLI，然后……就盯着它们各自滚动的输出。

半小时后问题来了：Claude Code 改了一个文件，Codex 也改了一个文件，改的是同一行；你无法确认谁对谁错；你想看 diff，得在三个终端里 git diff 来回切；等你终于理清思路，其中一个 Agent 已经把它那份改动推到了远端分支上。

Kandev 想解决的就是这个场景。它的定位不是"又一个 AI 终端"，而是一个把 Agent 编排、代码审查、版本控制收敛到同一张工作台上的控制平面。1077 star、179 fork、84 位贡献者，2026 年 1 月立项，至今不到一年已经发布到 v0.99.1——这个迭代速度本身就说明它非常"忙"。

图：Kandev 官方 README 的产品演示录屏

二、它到底解决什么

Kandev 的核心理念写得很直白："Humans stay in control."（人始终掌握控制权）。围绕这一句，它把 Agent 编程拆成了三段——计划、并行执行、审查交付。

看板式任务管理是它区别于纯终端工具的地方。任务有工作流位置（Backlog / Work / Review / Done），工作流步骤可以配置门禁（gate）。人负责决定"什么可以上线"，Agent 只在允许的范围内跑。

图：拖拽式看板，任务在工作流阶段之间流转

多 Agent 流水线是它的第二层能力。一个工作流的不同步骤可以指定不同的 Agent——比如让 Claude Code Opus 出设计方案，让 GitHub Copilot Sonnet 实现，再让 Codex 复核 diff。这不是"多开几个终端"，而是一条串行依赖的 Agent 管道，前一步的产物成为后一步的输入。

Worktree 隔离解决了并行冲突的技术难题。每个任务用独立的 Git worktree checkout，agent 之间物理上碰不到彼此的文件，再配合"一仓一分支、一仓一 PR"的多仓库任务模型，多个 Agent 可以安全地同时改同一个仓库。

三、支持的生态有多广

这是 Kandev 最"卷"的地方——它接了 22 个 Agent CLI，包括 Claude Code、Codex、GitHub Copilot、Gemini CLI、Amp、Auggie、OpenCode、Cursor、Devin、Qwen Code、Kimi、Kiro、Trae、Grok，甚至包括 Hermes 本身。

技术上，主流 Agent 走 ACP（Agent Client Protocol） 这一层抽象协议接入；对于不支持 ACP 的工具，Kandev 提供 "bring your own TUI" 方案——把任意 CLI 塞进 PTY 终端里跑，保留原生态的终端交互习惯。

Executor（执行器）同样分了 5 档：本地进程、Docker 容器、Kubernetes Pod、SSH 远程主机、以及 sprites.dev 云沙箱。远程执行的目的是让 Agent 跑在大代码库的计算节点上，而不是开发者的笔记本里。

图：任务会话中对话、终端、代码变更三栏合一

四、技术实现：Go 后端 + React 前端的单体交付

Kandev 的技术选型有几个值得注意的点。

后端是 Go 1.26，用 Gin 提供 HTTP/WS API，用 gorilla/websocket 承载实时推送，用 coder/acp-go-sdk 对接 Agent 协议，用 mark3labs/mcp-go 实现 MCP 服务端与客户端。数据库默认 SQLite（mattn/go-sqlite3），可切换 PostgreSQL（jackc/pgx/v5）；事件总线默认进程内内存总线，配置 NATS 后切换到 nats-io/nats.go 做跨实例广播。

前端是 React 19 + Vite 8 + TypeScript，状态用 Zustand，UI 组件是自研的 @kandev/ui（基于 Radix UI + Tailwind CSS 4）。编辑器集成了 Monaco 与 CodeMirror 双内核，终端用 xterm.js，复杂 diff 渲染交给 @pierre/diffs。

最关键的架构决策是"编译进二进制"：前端构建产物被嵌入 Go 可执行文件，运行时不需要 Node.js、不需要独立的 Web 服务器、不需要 Nginx 反代——单端口 38429 同时提供 API、WebSocket 和 SPA 静态资源。这个设计让自托管变得极其干净。

代码量级上，Go 约 100MB、TypeScript 约 62MB 字节量，Go 测试文件 6584 个，后端、前端、E2E 分三条独立 CI 流水线（backend-tests.yml / frontend-tests.yml / e2e-tests.yml），另有 30 个 workflow 覆盖发布、架构 lint、文档校验等。

图：可视化工作流编辑器，每一步可指定 Agent 与门禁

五、部署可行性评估

这是本次分析的重点。

Docker 路径：开箱即用。 官方镜像发布在 GHCR（ghcr.io/kdlbs/kandev:latest），amd64/arm64 双架构：

docker run -p 38429:38429 -v kandev-data:/data ghcr.io/kdlbs/kandev:latest

一条命令起服务，浏览器打开 http://localhost:38429 即可。数据（SQLite 库、worktrees、agent CLI 登录态）全部落在 /data 卷，重启不丢。另有 :universal 变体镜像（约 1.4GB）预装 Go/Rust/Playwright Chromium，适合 Agent 要在容器里编译或跑无头浏览器的场景。

Dockerfile 本身是单阶段消费预编译产物——CI 先打出各架构 release bundle，再由 Dockerfile 拷贝进 debian:bookworm-slim 运行时镜像。这意味着本地 docker build . 会失败（缺 bundle/ 目录），得先解压 release tar 包再构建，对开发者略反直觉。

K8s：官方提供但明确标注为实验性。 k8s/ 目录有 deployment/service/ingress/pvc/executor-rbac 全套 manifest，但架构文档写得很清楚：只有单副本控制平面，工作区与运行时状态仍绑在本地副本上，PostgreSQL 或 NATS 单独并不构成受支持的多副本拓扑。别指望它开箱做 HA。

原生二进制：最推荐。 Homebrew / Scoop / npm / npx 都有发行渠道，数据默认在 ~/.kandev。从源码构建需要 Go 1.26.0 + Node.js 24 + pnpm 9.15.9（mise.toml 固定），通过 make bootstrap 一键装好。

资源需求：纯 CPU，无需 GPU——Kandev 自身不跑模型，只调度别人的 Agent。2GB 内存 + 2GB 磁盘起步即可（universal 镜像另需空间）。唯一硬性前置是 Git（worktree 依赖）和 各 Agent 自己的订阅/API Key。

图：Agent 配置界面，托管安装各 Agent CLI 并管理模型

六、局限与争议

AGPL-3.0 协议是最大的一颗雷。 源码开放无争议，但 AGPL 的网络分发条款意味着：任何基于 Kandev 改造并对外提供服务的场景，都必须开源你的修改。对企业内部自托管无影响，对想把它嵌入商业产品的团队则需谨慎评估法务。

"多 Agent" 的实际收益存疑。 编排 22 个 Agent CLI 听起来很美，但多 Agent 并行写代码的收益高度依赖模型自身能力和任务拆分质量。Kandev 提供的隔离、审查、门禁是必要基础设施，但垃圾进垃圾出——拆分策略和提示词质量仍由人来把关。

项目太新、变化太快。 v0.x 阶段、30 天内合并 515 个 PR、平均每月一个大版本，文档跟不上实现是常态。README 提到 "Office mode"（持久化 Agent 团队自治层）仍是实验特性且默认关闭。API 破坏性变更几乎是必然的。

依赖外部 Agent 生态的连锁风险。 Kandev 自己稳定，但它依赖的 Claude Code、Codex、Copilot CLI 全都在快速演进——上游改一次协议或包名，Kandev 就得跟着改。仓库里有专门的 update-agent-runtime-pins workflow 来管理这层耦合，本身就说明问题所在。

功能密度带来的复杂度。 80+ 个后端内部模块、20+ 个集成、30 条 CI 流水线，是一个企业级体量。文档目录有 72 个 md 文件、超过 30 万字符，学习曲线不浅。

图：内置系统状态监控，展示各执行器与运行时健康状况

七、谁适合用

适合：需要同时驱动多个编程 Agent 的重度用户；希望 Agent 执行在远程服务器（SSH/Docker/K8s）而非本地笔记本上的团队；重视"人审后合并"流程、且已自建类似 CI 流水线的工程师；想摆脱单一厂商绑定的多模型团队。

不适合：只用 Claude Code 一个 Agent 的个人开发者（Kandev 明显过重）；无法部署 Go/Node 工具链的纯业务岗；需要严格商业许可的项目；期待"装完就能用"的用户——每个 Agent 的账号、订阅、API Key 都得自己配。

结论

Kandev 是 2026 年 AI 编程工具赛道里少见的**站在"编排层"而非"模型层"**的项目。它不训练模型、不写模型，只解决"怎么让一群 Agent 有序干活，并且让人看得懂、改得动、审得放心"这个已经被证实是真痛的问题。

技术实现上，Go 单体 + 前端嵌入二进制的分发方式、多档 Executor、ACP 协议抽象层，都体现出相当成熟的工程判断。1077 star、84 位贡献者、v0.99.1 的迭代节奏，说明它在这个细分领域站住了脚。

风险提示：AGPL 协议、v0.x 的破坏性变更、Office mode 尚未稳定、以及对上游 Agent CLI 生态的深度依赖——这四点决定了它现在更适合"敢折腾的早期采用者"，而非"求稳的企业级采购"。

部署结论：Docker 单命令可跑，资源门槛极低，无需 GPU；原生二进制是更推荐的路径；K8s 方案仅适合实验性单人使用。