Kandev：用看板管住多个 AI 编码代理，把审查拉回人类手里

终端代理的审查瓶颈，正是 Kandev 要解决的问题

单个代理在终端里跑得欢，但一旦任务多了，问题就来了。你没法在 TUI 里同时看多个代理的输出，也没法方便地对比不同分支的改动。Kandev 的定位很明确：它不是一个代理，而是一个控制平面。README 里直接说，终端代理 TUI 适合运行代理，但审查和迭代变更在那里扩展不了。Kandev 把看板、文件编辑器、终端、git 变更面板和浏览器预览集成到一个界面里，让你在一个地方处理多个代理的产出。它的目标用户是 power user，那些想自定义工作流、代理配置、提示词和审查门槛的人。

多代理并行与工作流编排的实际机制

Kandev 的核心机制是任务和代理的解耦。你定义任务，把它们放到看板列里，然后代理从不同提供商被分配来执行。关键的是工作流：一个多步骤管道，每一步可以指定不同的代理。README 给的例子是 Claude Code Opus 设计计划，GitHub Copilot Sonnet 实现，Codex GPT 5.4 审查。这种混搭不是噱头，它反映了不同模型在不同环节的优势。并行执行时，Kandev 用 git worktree 做工作区隔离，避免多个代理同时改一个目录导致冲突。任务还可以跨多个仓库，每个仓库一个 worktree、一个分支、一个 PR，这在 monorepo 或多服务项目里很实用。

从看板到 PR：任务的生命周期由你控制

一个任务从看板列开始，代理执行后，变更会出现在 git changes 面板里。你可以在内置编辑器里审查，用 LSP 看代码，在终端里跑测试，然后决定是否打开 PR。这个流程是 review-first 的，README 的愿景部分强调人类保持控制，定义任务，构建带门槛的工作流，审查每个变更。自动化功能允许你用调度或 webhook 触发任务，并配置运行目的地、上下文和并发度。子任务机制也很有意思：代理可以生成子任务，从父任务的会话继续，适合拆分过大的任务，或者从同一出发点产出多个 PR。

运行方式：本地、Docker、SSH 还是云执行器

Kandev 支持多种运行时。代理可以作为本地进程运行，也可以放进隔离的 Docker 容器，或者通过 SSH 在远程服务器上跑，甚至可以用 sprites.dev 这样的云执行器。这个灵活性直接回应了 README 里提到的痛点：在大型代码库上跑多个代理很容易耗尽本地机器的资源。你可以把执行卸载到服务器，从任何地方编排，包括手机。运行时设置里可以配置执行器档案、密钥、自定义提示词和工具代理。资源指标也在设置里可见，这对监控远程执行器的负载有帮助。

安装与配置：从仓库到第一个任务

README 没有给出具体的安装命令，但项目是 Go 写的，主页是 kandev.ai，仓库里有 docs 目录，包括 run-as-a-service.md 和 ARCHITECTURE.md。你可以从源码构建，或者按照文档以服务方式运行。配置上，工作流是可移植的 YAML，可以导出和导入，这意味着你可以把定义好的工作流跨工作区或安装实例共享。代理接入通过 ACP（Agent Client Protocol）实现，支持列表很长，包括 Claude Code、Codex、GitHub Copilot、Gemini CLI 等。每个代理对应一个 npm 包或命令，比如 Claude Code 是 @agentclientprotocol/claude-agent-acp。你需要先安装对应的 CLI 包，然后在 Kandev 里配置。

外部 MCP 与插件：扩展边界的两种方式

Kandev 提供两种扩展途径。一种是 Task-agent MCP，让代理能够创建子任务、定位兄弟仓库、附加额外分支、给其他任务发消息、读取会话和检查相关任务。这实际上是把看板变成了代理可操作的环境，代理不只是执行者，还能协作。另一种是 External MCP，允许从外部通过 streamable HTTP 或 SSE 管理 Kandev，并提供可复制的配置片段，方便集成到其他代理 CLI 里。插件市场支持浏览、安装、更新和配置插件，比如 MCP Explorer 和 Bitbucket 插件。Bitbucket 支持是通过插件实现的，而不是内置，这说明核心集成只覆盖 GitHub、GitLab、Jira、Linear、Sentry 和 Azure DevOps。

限制与陷阱：AGPL、配置复杂度和未完成的功能

Kandev 是 AGPL-3.0 许可证，这意味着如果你修改代码并分发，你必须开源修改。对于内部使用问题不大，但如果想基于它构建商业服务，需要仔细考虑。另一个限制是，它依赖大量外部代理 CLI，每个代理的安装和维护成本不同，比如 Cursor 需要 Pro 订阅，Devin 需要单独安装 CLI。配置上，工作流是 YAML，代理列表很长，但每个代理的接入质量可能参差不齐，README 里 iFlow 标注了 beta，说明不是所有集成都成熟。还有一个明显的未完成功能：Office mode，一个带角色和权限的持久代理团队层，目前只是 feature-flagged，文档明确说在功能上线前不会作为受支持功能记录。这意味着如果你需要预算控制或任务委派，现在还得等。

替代方案与比较：原生 TUI 与云端平台

最直接的替代方案是继续使用代理自带的终端 TUI，比如 Claude Code 的原生界面。这种方式的优点是零额外配置，代理的所有功能都在，但缺点是无法同时管理多个代理，也没有看板视图。另一个方向的替代是云端托管平台，比如 OpenAI 的 Codex 云端版本或 GitHub Copilot Workspace，它们提供了托管执行和协作界面，但 Kandev 强调自己是自托管的，不绑定任何云，没有遥测。如果你需要完全掌控数据和执行环境，Kandev 的本地或 SSH 运行时更合适；如果你不在乎数据出网，云端平台可能更省事。关键差异在于 Kandev 把工作流定义成可移植 YAML，并且允许混搭不同提供商，这是大多数单一代理平台做不到的。

编辑结论

Kandev 适合那些已经习惯用 Claude Code、Codex 等 CLI 代理，但苦于在终端里无法有效审查和迭代大量变更的开发者。它尤其适合需要并行处理多个任务、并且希望用看板和工作流把代理行为规范化的团队。不适合只想快速跑一个代理、不想折腾配置的人，也不适合对 AGPL 许可证敏感的商业闭源项目。在采用之前，你应该先验证三件事：你的代理 CLI 是否在支持列表里且能通过 ACP 接入，你的代码托管平台（GitHub、GitLab 等）是否在你的网络环境下可用，以及你能否接受所有工作流和代理配置都以 YAML 文件形式维护。如果这些都没问题，Kandev 的 review-first 设计值得一试；如果不行，继续用原生代理 TUI 可能更省事。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes