dmux
用 tmux 和 Git worktree 并行管理多个编码智能体。
每个任务使用独立 worktree 和分支，降低代理之间的写入冲突；合并、提交、暂存、取消及冲突处理均有明确交互选项，相关测试也覆盖失败分支。扣分在于：AI 命名、摘要和分析涉及推理提供商，但材料没有说明具体发送哪些代码、差异或元数据，也未说明 API 密钥的存储、日志脱敏或保留策略；“智能合并和清理”的恢复边界不够具体。发布流程使用冻结锁文件、npm provenance 和有限的工作流权限，但没有依赖审计、漏洞处置或更新策略证据。作者、许可证和仓库信息可见，不过 standardagents 与 formkit 链接并存，使来源归属不完全稳定。
README、包元数据和合并测试共同呈现了连贯的 worktree/tmux 多代理产品，并明确 Node、Git、tmux 和外部代理 CLI 依赖。测试显示 AI 超时或失败时回退到手动输入，并为暂存、提交、冲突窗格创建和缺少代理提供具体错误消息，因此失败消息可给满分。扣分在于依赖可用性仍依赖多个外部 CLI、订阅和平台工具，且材料未展示启动前全面诊断；仓库及问题链接的组织名不一致也削弱整体一致性。
目标受众、并行开发、普通终端、跨项目、冲突处理及多代理选择等场景描述充分，快捷键和代理选择流程也较明确。能力边界通过系统要求、可选 AI 功能和支持的 CLI 得到部分界定，但没有完整说明不支持的仓库状态、钩子信任边界或平台差异。触发操作通常由按键和选择驱动，不过自动提交、自动清理及生命周期钩子的精确触发条件未在所给材料中完整展开。环境适配覆盖 Node 18+、tmux 3+、Git 2.20+ 和多个代理，但 macOS 通知/辅助组件与其他平台的差异说明有限。
README 提供安装、快速开始、功能、快捷键、要求、文档、贡献和许可证结构，并有日文版本；安装命令简洁，MIT 正文和包元数据一致，许可证可给满分。版本号、标签发布、自动生成 GitHub release 和发布脚本提供了更新路径。扣分在于没有随附 FAQ、实际变更日志或集中式已知限制说明；安装后验证、卸载及故障排除不充分；standardagents、formkit 和 dmux.ai 的命名/维护归属混杂，且仅有个人作者字段，维护责任和企业身份不清楚。
隔离 worktree、并行代理、内置浏览器、代理多选和合并工作流形成了可直接使用的开发输出，且相较手工创建 worktree、tmux 窗格和分支具有明显增量价值。测试所示的可编辑提交消息、取消、暂存和冲突处理进一步提升可用性。扣分主要在成本收益说明：需要 tmux、Node、Git、至少一个代理 CLI，部分能力还需要 API 密钥或付费订阅，而材料没有量化资源消耗、并发成本或大型仓库开销。
主要产品主张可在 README、package.json、发布工作流及针对提交和冲突流程的测试之间追踪；版本、依赖、许可证、发布来源证明和错误处理都有文件级依据。扣分在于提供的测试集中于合并子系统并大量使用 mock，无法交叉支持全部功能列表；外部文档未包含在材料中；“完全隔离”“智能合并”等宣传性表述没有在所给源码片段中被完整限定。事实与推断总体可区分，但对自动清理、数据流和平台行为仍需保守推断。
- 启用 AI 命名、摘要、窗格分析或 AI 冲突解决前，确认代理 CLI 和推理提供商会接收哪些仓库内容，并自行核查密钥存储、日志和数据保留设置。
- 自动提交、合并、暂存和清理会改变 Git 状态；首次使用应在可恢复的测试仓库中验证取消、冲突、stash 恢复及 worktree 清理行为。
- 生命周期钩子可执行脚本，但所给材料没有说明审批或沙箱机制；仅运行受信任仓库和受审查的钩子。
- 核实 standardagents/dmux、formkit/dmux 和 dmux.ai 之间的当前维护与发布关系；现有材料不足以确认发布者身份。
- 静态评审未执行构建、测试、安装或依赖漏洞扫描，测试文件中的行为不等于独立复现。
这个 Agent 能做什么，适合哪些场景？
dmux 是一个面向本地 Git 项目的命令行多路复用器，用独立 worktree、分支和 tmux pane 隔离并行开发任务。用户通过键盘界面创建普通终端或启动一个或多个受支持的编码智能体，包括 Claude Code、Codex、OpenCode、Gemini CLI 和 Copilot CLI 等。每个任务在单独的工作副本中执行，完成后可由 pane 菜单自动提交、合并和清理，或者推送分支并创建 GitHub Pull Request。它还提供内置文件浏览与差异预览、终端与智能体会话恢复、多项目视图、pane 隐藏控制和生命周期钩子。dmux 作为安装在开发者机器上的 Node.js CLI 运行，依赖 tmux 和 Git；推理服务只用于 AI 命名、摘要和 pane 分析等可选功能。
在 Git 项目中运行 dmux 后，按 n 输入任务提示并选择一个或多个已启用的智能体；dmux 为任务创建 tmux pane、Git worktree 和分支，然后启动所选智能体。多智能体启动会沿用共享名称并添加智能体专属后缀，也可在建 pane 时指定基础分支或明确的分支/worktree 名称。用户可按 f 搜索和预览 worktree 中的文件、代码与 diff，按 m 执行 Merge 或 Create GitHub PR。合并流程可自动提交改动、合并分支并清理资源。普通终端会恢复到上次记录的目录；对 Codex、Claude 等受支持的智能体，dmux 会跟踪并在 pane 重建时恢复对话。它还能在 worktree 创建、合并前后等阶段执行生命周期脚本。
- 需要同时处理多个独立功能或缺陷的开发者，可让每个编码智能体在各自的 worktree 和分支中工作。
- 负责审阅智能体产出的维护者，可在 dmux 内浏览文件和 diff，再选择合并或创建 GitHub Pull Request。
- 想用同一提示比较多个编码智能体结果的用户，可一次选择多个已启用的 CLI，并获得带智能体后缀的隔离分支。
- 同时维护多个 Git 仓库的开发者，可把多个项目加入同一会话，并筛选指定项目的 pane。
- 需要标准化 worktree 初始化或合并检查的团队，可在创建、合并前和合并后阶段配置生命周期脚本。
- 希望长时间保留开发上下文的终端用户，可利用目录恢复以及受支持智能体的对话恢复功能。
这个 Agent 有哪些优点和局限？
- 每个任务都使用独立 Git worktree、分支和 tmux pane，可避免并行智能体直接修改同一工作副本。
- 原生支持多种编码智能体 CLI，并能用同一提示一次启动任意组合的已启用智能体。
- 从任务启动到自动提交、合并、清理或创建 GitHub Pull Request，覆盖了较完整的分支交付流程。
- 内置文件搜索、代码与 diff 预览、多项目管理及 pane 可见性控制，减少在终端工具之间切换。
- 可恢复普通终端目录及受支持智能体的对话，并提供多个阶段的生命周期钩子。
- 运行环境明确依赖 tmux 3.0+、Node.js 18+ 和 Git 2.20+，不适合缺少这些工具的环境。
- 智能体 pane 还要求用户单独安装并配置至少一个受支持的编码智能体 CLI。
- AI 命名、摘要和 pane 分析需要额外的提供商凭据或订阅登录，可能带来服务费用和账号依赖。
- GitHub Pull Request 流程需要网络和远程仓库；来源未说明对其他代码托管平台的同等支持。
- 原生通知仅明确记录了 macOS 支持，其他操作系统是否提供同等通知能力没有证据。
如何安装或部署这个 Agent？
前置条件为 tmux 3.0+、Node.js 18+、Git 2.20+。若要启动智能体 pane，还需安装至少一个受支持的智能体 CLI，例如 Claude Code、Codex、OpenCode、Cline CLI、Gemini CLI、Qwen CLI、Amp CLI、pi CLI、Cursor CLI、Copilot CLI 或 Crush CLI。全局安装命令：
npm install -g dmuxAI 命名、摘要和 pane 分析属于可选功能；使用这些功能时，需要推理服务 API 密钥、由 ChatGPT 订阅支持的 Codex CLI 登录，或由 SpaceXAI 订阅支持的 Grok Build CLI 登录。
如何使用这个 Agent？
进入一个 Git 项目并启动：
cd /path/to/your/projectdmux
按 n 创建新 pane，输入提示，然后选择一个或多个智能体；也可不选智能体以创建普通终端。首次运行时可配置主要推理提供商/模型及可选备用提供商，之后可通过 s → Inference Providers 重新配置。任务完成后按 m，选择 Merge 将结果合入主分支，或选择 Create GitHub PR 推送分支并创建 Pull Request。常用操作还包括 t 新建终端、f 浏览 worktree 文件、x 关闭 pane、p 从另一项目新建 pane，以及 q 退出。