Kander

这个 Agent 能做什么，适合哪些场景？

Kander 是一个用 Go 编写的终端看板工具，用来协调多个 AI 编码代理并行推进同一仓库中的任务。它把每张任务卡映射为一次隔离的代理执行：借助 Git worktree 与 tmux/herdr 容器把终端和工作区分开，再通过静态分析分支重叠与文件修改边界来排程，避免并发写入冲突。执行与评审在物理上分离，PMQA 评审环节专门捕捉语义错误与状态机缺陷，阻止「假绿」测试通过。它还内置了卡片事务与崩溃恢复、持久化派发协议，以及零 Token 的 GitHub 集成——直接复用本地 gh 凭据浏览 issue、导入卡片并同步进度。项目以 MIT 许可发布，通过 Homebrew、二进制包或 Windows zip 分发，运行时需要 Git 以及 Codex、Claude、Grok、Cursor、Pi 中至少一个代理。

用户在终端运行 kander 打开交互式看板，用 Space/Enter 查看任务详情，用 m 执行启动、移动、归档，用 / 过滤检索，用 g 打开 GitHub Issues 浮层并一键导入。代理在讨论需求后创建并启动任务卡，Kander 为每张卡分配独立的 Git worktree 和 tmux/herdr 会话，使多个代理互不干扰地改代码。调度层会静态分析 Git 分支重叠和文件修改边界，决定哪些卡可以安全并发。执行完成后进入两阶段独立评审：PMQA 在隔离环境中运行，检查语义与状态机问题，并依据评审处置与完成门禁决定是否放行。全过程由卡片事务与持久化派发协议记录，支持崩溃恢复；kander doctor 用于检查并修复环境依赖、代理可用性、启动器和规则配置。

1. 一个人同时驱动 5–6 个编码代理、跨多个项目推进需求，需要统一的任务看板来观察进度。
2. 多个代理并行修改同一仓库时，希望用 worktree 隔离工作区并避免分支与文件写冲突。
3. 团队担心低成本模型写出的「假绿」测试通过评审，需要独立的第二道评审门禁。
4. 开发者希望直接从 GitHub issue 导入任务卡，而不想额外申请或配置访问令牌。
5. 代理运行中崩溃或终端断开后，需要能恢复到中断前状态的交付流程。

如何安装或部署这个 Agent？

运行前提：已安装 Git，并至少具备 Codex、Claude、Grok、Cursor、Pi 中的一个编码代理。

macOS 使用 Homebrew：

brew install dualface/tap/kander

kander

Linux 直接下载二进制：

ARCH=$(uname -m); [ "$ARCH" = x86_64 ] && ARCH=amd64; [ "$ARCH" = aarch64 ] && ARCH=arm64
curl -fsSL "https://github.com/dualface/kander/releases/latest/download/kander-linux-${ARCH}.tar.gz" | tar xz

./kander

Windows 从 Releases 下载 kander-windows-amd64.zip，解压后运行：

kander.exe

首次启动时若尚未安装，会进入交互式安装向导；安装完成后即可使用。需要 GitHub 集成时另需安装 GitHub CLI（gh）。

如何使用这个 Agent？

第一步，启动一个代理会话，把需求、目标和验收标准讨论清楚（推荐使用代理的 Plan 模式）。第二步，任务确认后，加载了 Kander 规则的代理会询问是否通过看板流程启动；确认后任务卡自动创建并开始执行。第三步，对多个需求重复前两步，持续排程与启动任务。第四步，用以下命令查看任务状态：

kander

环境检查与修复：

kander doctor

在终端看板中：Space/Enter 查看详情，m 打开任务操作菜单，g 打开 GitHub Issue 浮层，c 进入独立聊天会话，y 复制任务 ID，/ 过滤搜索，r 刷新看板。若要把卡片交接给另一个代理，先停止当前代理，再让新代理接管指定 TASK-ID；卡片 ID 可在看板中按 y 复制。

这个 Agent 有哪些优点和局限？

这个 Agent 与同类方案有什么区别？

与相关度最高的同类 agent 并排比较关键指标。

FollowAgents 如何评估这个 Agent？

常见问题