firstmate：把单个编码智能体变成一支可监督的船员队伍
项目速览：与一位代理人交谈。与船员一起航行。对于较大的舰队，您可以选择持久的二副：二副仍然是普通的直接报告，但从他们自己孤立的大副家中运行。
秒懂
- 它是什么？
- firstmate 是一个以 Shell 脚本和 AGENTS.md 为核心的智能体发行版，让你只与一个主智能体对话，由它调度多个子智能体在独立 git worktree 中并行干活。它的价值在于把并行任务的监督逻辑固化到磁盘状态和会话后端里，但你需要接受它的运行方式与维护成本。
- 适合谁用？
- 适合已经熟练使用 Claude Code、Grok 或 Pi，并且经常需要并行处理多个项目任务（如修复、调查、审计）的开发者。不适合只跑单一任务、不想维护 tmux 会话或不愿意信任项目内钩子的人。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Shell（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的不是单任务效率，而是并行任务的监督问题
单个编码智能体跑一个任务很容易，但当你同时要三个任务并行，比如修一个 bug、做一次调查、写一份审计报告，你就会变成标签页管理员。你要盯着多个会话，来回复制上下文，还得记住哪个终端里跑着失败的测试。firstmate 把模型反过来：你只跟一个主智能体说话，它负责生成子智能体、给每个子智能体分配一个干净的 git worktree、监督它们完成，最后把结果交给你。它面向的是已经用智能体干活但被并行任务搞烦的人，不是第一次接触编码智能体的新手。
它不是一个应用，而是一套目录约定
firstmate 没有安装程序，克隆下来的仓库本身就是发行版。它包含 AGENTS.md、一组内置技能和辅助脚本，任何支持这些约定的终端智能体都能加载。启动一个受支持的智能体（比如 Claude Code、Grok 或 Pi）后，AGENTS.md 会接管，把这个通用智能体变成你的大副。这种设计意味着没有独立的守护进程，也没有中央服务器，一切运行在你的终端和文件系统里。好处是透明，你可以直接读脚本看它做了什么；代价是它依赖你选的主智能体是否完整执行这些约定。
每个任务一个 worktree，互不干扰
并行任务在同一仓库里跑最容易冲突，firstmate 用 treehouse 这个 git worktree 机制解决。每个子智能体在一个独立的 worktree 里工作，互不碰撞。如果你选择 backend=orca，则用 Orca 管理的 worktree。主智能体对项目是只读的，除了少数受保护的操作（比如 fleet sync 的安全分支清理），所有项目变更都由子智能体在配置的合并权限下完成。这保证了并行改动不会互相覆盖，也让你能随时查看每个任务的工作现场。
两种任务形状和三种项目模式
firstmate 把任务分成两种：ship 任务负责交付经过授权的变更，scout 任务只留下独立的调查报告。每个项目还要声明自己的模式：no-mistakes、direct-PR 或 local-only，还可以加一个 +yolo 标志允许自动合并。这个设计把风险控制前置了，你不需要在每次任务里反复叮嘱智能体该怎么做。但这也意味着你要为每个项目想清楚它的交付方式，这本身是一种额外的心智负担。
监督靠事件驱动，不靠轮询
firstmate 声称使用零 token 的监督方式：一个 bash watcher 在后台休眠，只有需要你的时候才唤醒主智能体。对于验证过的主智能体，还有一个 turn-end 保护机制，防止工作未完成时被盲目停止。Claude Code 用 Stop hook，Grok 用后台通知，Pi 用扩展，三者都有验证过的保护路径。但 Codex 和 OpenCode 虽然也支持，却有更多监督上的取舍，比如 Codex 用有界的前台检查点，OpenCode 用 TUI 插件。这意味着你选择的智能体直接决定了监督的可靠性，不是所有智能体都一样。
启动方式：从 gh auth login 开始
首先要保证 GitHub CLI 已认证，然后克隆仓库并进入目录。接着启动你选的主智能体，比如 Claude Code 直接运行 claude，Grok 需要带 --trust 参数，Pi 则运行 pi。对于 Grok，--trust 只需要在每次克隆后第一次运行，也可以用 /hooks-trust 命令；Pi 需要在首次启动时批准项目信任提示。如果你用 Cursor Agent CLI，必须用 --trust 启动，否则项目钩子不会加载，而且 headless 模式下没有 turn-end 钩子，必须交互式运行。这些细节都写在 README 里，但很容易被忽略。
限制：不是万能的，也不是无成本的
firstmate 依赖你选的主智能体完整执行 AGENTS.md 的约定，如果某个智能体不遵守，整个监督链条就断了。它没有提供独立的智能体运行时，所以你不能脱离这些受支持的 harness 单独使用它。其次，它的状态全部存在磁盘和会话后端里，默认是 tmux，这意味着你要熟悉 tmux 的基本操作，否则连查看子智能体的工作窗口都困难。另外，它明确不是 CLI、不是 MCP 服务器，所以如果你期望一个命令行工具来直接控制它，会失望。对于只需顺序跑几个任务的场景，它的并行机制反而增加了复杂度。
替代方案：直接跑多个智能体实例，或使用专门的编排框架
一个直接的替代方案是手动打开多个终端，每个终端跑一个独立的智能体会话，自己复制上下文和合并结果。这种方式没有额外的脚本和状态约定，灵活但容易出错，尤其是当你需要跨仓库同步信息时。另一个替代是使用像 LangGraph 或 CrewAI 这样的编排框架，它们提供显式的 agent 图和任务依赖管理，但通常需要写代码，而且它们不依赖 git worktree 这种仓库级隔离。firstmate 的差异在于它把监督逻辑做成了 shell 脚本和文件约定，不需要写 Python 或学习新的 API，但这也意味着它的扩展能力受限于 shell 和你的智能体对 AGENTS.md 的遵循程度。
编辑结论
适合已经熟练使用 Claude Code、Grok 或 Pi，并且经常需要并行处理多个项目任务（如修复、调查、审计）的开发者。不适合只跑单一任务、不想维护 tmux 会话或不愿意信任项目内钩子的人。采用前先验证你的主智能体是否在支持列表内，确认 GitHub CLI 已认证，并检查你的终端后端（默认 tmux）是否可用。firstmate 的价值在于它把并行任务的监督变成可恢复的磁盘状态，但这也意味着你要接受它的状态约定和更新方式，否则它只是一堆脚本。
社区笔记