Kandev：用看板让多个 AI 编程 Agent 真正学会协同作战
Kandev：用看板让多个 AI 编程 Agent 真正学会”协同作战”
你有没有这种感觉：Claude Code 开 3 个、Codex 开 2 个、Cursor 再来 1 个——结果本地机器跑成暖手宝，代码冲突一堆，回头 PR 都不知道哪个是谁写的？
kdlbs/kandev 想解决的问题很直接：当一个团队开始同时跑多个 AI 编程 Agent，怎么让它们不打架、让人还能看懂改了什么。
它到底是什么
Kandev 是一个 AI 开发环境，核心理念是”人类在前，Agent 在后“。它用看板（Kanban）组织任务，用工作流（Workflow）编排 Agent，用隔离的工作树（Git Worktree）防止代码冲突——所有变更在合并前必须经过人工 review。
简单说：它不是又一个 AI 编程 CLI，而是一套多 Agent 协作与人工审核的工作台。
当前最新版本 v0.86.1（2026-08-10），活跃维护中。
核心能力拆解
多 Agent 并行编排
Kandev 支持 20+ 主流编程 Agent：Claude Code、Codex、Cursor、Devin、Qwen、Pi、Kimi、Grok……可以在同一个任务的不同步骤里指定不同的 Agent。
典型场景：Claude Code Opus 做架构设计 → GitHub Copilot 实现 → Codex 审查代码变更。Workflow 编排，多步自动衔接，无需反复切换上下文。
看板式任务管理
不只是把 Todo 列表画成看板。Kandev 的任务板与 Agent 执行深度绑定：每个任务卡片可以分配给指定 Agent 执行，Agent 的输出、错误、进度直接反映在卡片上。
支持子任务：一个大任务可以分裂出多个子任务，每个子任务有独立的工作树和分支，最后各自开 PR。
Git Worktree 隔离
这是关键工程决策：当多个 Agent 同时修改同一个仓库，传统方式会让分支冲突。Kandev 为每个任务创建独立的工作树，真正物理隔离，从根本上避免并发冲突。
多仓库任务
一个任务可以跨越多个仓库，每个仓库有独立的工作树、独立分支、独立 PR，最终在 Changes 面板统一 review。这对微服务架构团队来说很实用。
灵活的运行时
- 本地进程
- Docker 隔离容器
- 远程服务器 SSH
- 云端 Executor（如 sprites.dev）
算力不够？把 Agent 执行扔到服务器上，本地只跑控制台。
集成覆盖
开箱即用：GitHub / GitLab / Jira / Linear / Sentry / Slack。另有 MCP（Model Context Protocol）扩展能力。
什么人适合用
适合：
- 已经在用多个 AI 编程 CLI 的团队或个人，想统一管理
- 需要多 Agent 协作生产代码、但必须有人 review 的工程团队
- 有远程算力需求（本地机器跑不动大模型）
- 微服务/多仓库项目，想让不同 Agent 各管一个 repo
不适合：
- 单 Agent solo 写代码的个体开发者（直接用 Claude Code 就够了，不需要这层复杂度）
- 追求零配置、快速上手的用户（Kandev 有一定学习曲线，需要配置 Agent、Workflow、Executor）
- 对本地隐私有绝对要求且不愿自托管的（Kandev 支持自托管，但默认配置需要一定基础设施）
项目边界说明
Kandev 不是：AI 编程 CLI 替代品（不自己做代码生成）、云托管服务（需要自己部署）、低代码平台（输出是代码，不是应用）。
它是：多 Agent 编排层 + 任务管理层 + 代码 review 界面的综合开发工具，定位接近”AI 编程的 CI/CD”，但跑在本地而非云端。
许可证为 AGPL-3.0。
下一步建议
如果 kandev 解决的问题让你有共鸣，可以这样开始：
- Clone 试试：
git clone https://github.com/kdlbs/kandev && cd kandev，按 README 启动 - 配一个 Agent：在 Settings 里填入你的 Claude Code 或 Codex token
- 跑一个简单任务：创建一个任务，选择一个仓库，观察 Agent 如何写代码、生成 PR
- 试试多 Agent 工作流：参考
docs/workflow-tips.md配置一个多步骤 Pipeline - 关注它的发展：Discord 社区活跃，Roadmap 在
docs/roadmap.md公开
GitHub 仓库：https://github.com/kdlbs/kandev
评论区
登录后可评论。