如果你用过Claude Code或Codex，你应该见过这个画面：你开了三个终端窗口，每个Agent跑一个任务。一个修bug，一个写测试，一个重构模块。你在三个窗口之间来回切，等A回复的时候去看B，发现B卡在了一个需要你确认的操作上，已经卡了二十分钟。
这不是你的工作流有问题。是单Agent模型的根本局限，一个Agent一次只能做一件事。
Firstmate做的事情足够简单也足够激进：你只跟一个Agent对话，它负责管理一整支Agent团队。你像船长一样下命令，大副（first mate）调度船员，你等着收PR就行了。整个项目是一个代理发行版（agent distro），不装任何东西，clone下来就能用。
这个模式不是吹概念。翻完它的架构和设计决策之后，我的判断是：这可能是2026年多Agent编码工具这个赛道里，设计思路最干净的一个。别急着下结论。我们来看看它到底怎么做到的，以及哪些地方会让你踩坑。
打动我的几个地方
Agent编织（orchestration）不是个新词。2026年已经冒出了十几个多Agent编码工具，Claude Squad、Superset、Paseo、Conductor，各有各的定位。Firstmate跟它们最根本的差别不在功能列表上，在架构哲学上。
它是一个发行版，不是应用。你不需要npm install、不需要brew、不需要docker pull。clone仓库，cd进去，启动你的Agent harness，就完了。所有的技能、工具、策略、状态约定都在仓库目录里。这意味着你可以fork它、改它、在团队里分发你自己的版本。这不是开源许可条款里的权利，是架构上的设计意图。
上图把Firstmate的三层结构画得很清楚。顶部是船长（你），中间是大副（firstmate核心进程），底部是三个并行的船员，各自跑在独立的git worktree里。bash观察者在后台监听，Agent状态发生变化时才唤醒大副，不需要持续轮询消耗token。
Git worktree隔离是第二个真正聪明的地方。每个船员Agent跑在独立的git worktree里，不是虚拟环境、不是容器、不是tmux pane级别的工作目录切换。是真正的文件系统级隔离。两个Agent可以同时改同一个文件的同一个函数，互不冲突，因为它们的变更发生在两个不同的worktree上，合并在最后统一处理。
这个设计解决了一个很多人没意识到的问题：多Agent并行最大的障碍不是算力，是文件冲突。你在A Agent里改了main.py第42行，B Agent也改了同一行，merge conflict是唯一结果。Worktree方案把这个冲突从”运行时就爆炸”变成了”最后合并时才处理”，这是个质变。
事件驱动监督机制也值得聊。大部分多Agent工具需要一个持续运行的监控进程，不断地轮询Agent状态、粘token。Firstmate反着来，一个bash观察者（watcher）在后台休眠，只有当Agent的状态发生变化时才唤醒大副。零token监督不是营销话术，是bash wait/signal机制的自然结果。
上面这张图对比了Firstmate的两种任务模式。Ship模式走的是编码→审查→合并→PR的标准交付管线，Scout模式生成独立的调查报告，不碰代码。两种模式最终都通过bash观察者来触发状态汇报，整个流程的监督成本接近于零。
内置的五个命令技能，/afk（离线模式）、/ahoy（回顾未处理事件）、/bearings（生成状态摘要）、/updatefirstmate（自更新）、/stow（知识归档），不是那种”我们加了命令系统所以显得高级”的花活。每一个解决的都是多Agent场景下的真实需求。尤其是/bearings，能在你离开几个小时后一句命令告诉你”这段时间发生了什么，哪些事需要你决策”，在多任务并行的时候，这个功能价值比看上去大得多。说完了亮点，上手试试看。
跑起来看看
安装步骤就是没有安装步骤：
gh auth login
git clone https://github.com/kunchenguid/firstmate
cd firstmate
然后启动你用的Agent harness。项目给出的推荐排序很实在，Claude Code排第一，因为它支持Stop hook实现无token的观察者重新武装和唤醒：
claude
启动后跟大副说的第一句话可以是：
ahoy! look at my github project xyz, then fix the flaky login test and add dark mode
大副会先检查工具链、克隆项目到projects/目录、在后台生成两个隔离的worker，分别处理”修flaky测试”和”加暗色模式”，几分钟后告诉你PR准备好了。上面的截图展示的就是这个首次交互过程，大副接管后用户只需要等结果就行。
跑起来很容易，但卡住的地方有几个。554个open issue不是摆设。从Issue区的反馈来看，Windows用户踩的坑最多，tmux在WSL2和原生PowerShell之间的兼容性问题经常导致后端初始化失败。Herdr和Zellij这两个实验性后端在某些Linux发行版上的socket权限配置也有坑，需要手动调。
另外，项目启动时需要能访问GitHub API。如果你的网络环境对GitHub有限制，大副的初始化阶段可能会在gh auth这一步反复超时。项目文档建议用SSH key替换token认证来绕过去，但README里没写具体步骤，需要去docs/configuration.md里翻。
支持的Agent harness覆盖了主流选择：Claude Code、Grok、Pi、Codex、OpenCode。不过要注意，每个harness的体验不完全一样，tmux后端在Claude Code上最成熟，herdr/zellij在Pi上表现更好。文档里有一张harness和后端的兼容性矩阵，选之前先看一眼能省不少折腾。看完怎么用，该聊点更实际的。
什么时候用，什么时候别用
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 并行多任务开发 | 同时维护多个feature/repo的开发者 | Worktree隔离，零冲突风险 | 任务拆分逻辑需要手动规划 |
| 无人值守编码 | 想让Agent在睡觉时工作的个人开发者 | /afk离线模式加零token监督 | 554个open issue说明稳定性还欠火候 |
| 代码审查辅助 | 需要AI review PR的团队 | Scout模式生成独立调查报告 | 审查质量依赖底层LLM能力 |
| X(Twitter)集成 | 想在公开平台at Agent触发任务 | 可选X模式 | 需额外配置.env token |
不推荐的情况也很明确：
-
你只用一个Agent做一件事：Firstmate的价值在”并行”上。如果你的日常工作模式就是开一个Claude Code窗口、改一个文件，那它的复杂度对你来说性价比不高，直接用Claude Code更省心。 -
你在Windows上做主力开发：tmux后端的Win32路径转换问题还没有处理好，Issue区里Windows相关的抱怨占了相当比例，Mac/Linux是当前的正确选择。 -
你对稳定性要求很高：项目上线不到两个月，554个open issue，核心维护者只有一个人。它现在的状态是”很好玩，但生产环境要等”，不是”可以直接替换你的工作流”。
聊完了场景，得看看社区靠不靠谱。
社区怎么样了
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | 2,724 | 截至2026年8月，上线不到两个月，增速可观 |
| 核心维护者 | 1人(kunchenguid) | Bus Factor=1，高风险。320次提交均由一人完成 |
| Open Issues | 554 | 比例偏高（每5.5个Star对应1个Issue），迭代速度vs技术债的矛盾明显 |
| 协议 | MIT | 商业友好，可自由使用和修改 |
2724个Star，上线不到两个月。这个数字放在2026年的Agent工具赛道里不算最炸的，Superset同期已经破万，但考虑到这是一个纯Bash项目、没有图形界面、没有市场营销，纯粹靠”agent distro”这个概念在开发者社区里传开的，含金量不算低。
在BestHub于2026年7月发布的一篇多Agent工具对比评测中，Firstmate被归入”协作层”（collaboration layer），定位是”让用户同时调度多个Agent”。评测肯定了它的worktree隔离和零token监督，但也指出”项目太年轻，稳定性还没有经过大规模验证”。Reddit和HackerNews上的讨论集中在同一个疑问上：一个纯Bash项目能承载多Agent编排这么重的任务吗？目前社区的答案大致是”概念满分，执行待观察”。
协议方面，MIT意味着你可以把它嵌入商业产品、fork后闭源、或者在公司内部随意修改部署，没有任何法律负担。这一点比很多竞品友好，Superset用的是Elastic License 2.0（非OSI认证），Paseo是AGPL-3.0（强制衍生代码开源）。
不过有一个数据得说清楚：554个open issue对于一个320次提交、单维护者的项目来说，太高了。我翻了翻Issue区，大部分是后端兼容性问题、Windows路径问题、配置文件的边界情况。不是那种”项目有设计缺陷”的致命问题，更像是”一个快速迭代的年轻项目在兼容性上欠了技术债”。短期内你不用期待每个Issue都能及时处理。该给个真实判断了。
我的真实看法
我花了大半个下午翻Firstmate的架构文档和AGENTS.md，结论比最开始想的复杂。这个项目最值钱的东西不是代码，是”agent distro”这个想法。以前的Agent工具都在走应用路线，装一个软件、配一堆设置、用一个固定界面。Firstmate说：别装了，仓库本身就是应用。你clone下来的那个目录里，包含了一个Agent团队运行需要的所有东西，技能、工具、策略、状态约定。这比任何一行Bash脚本都重要。
但它的实现还很粗糙。554个open issue不是小事。单维护者的Bus Factor是实打实的风险，如果kunchenguid因为任何原因停止维护，这个项目会迅速变成僵尸。320次提交看起来勤奋，但一个月提交320次也暴露了另一个问题：代码在快速迭代，文档跟不上，测试覆盖不足。
跟同类项目的对比更有意思。Claude Squad（6.9k Stars, MIT）也是多Agent CLI工具，功能重叠度很高，worktree隔离、tmux会话管理、attach/detach。但Claude Squad是Go写的单二进制文件，启动快、依赖少。Firstmate强在概念完整性和内置技能系统，弱在实现成熟度和跨平台体验。如果你要一个”现在就稳定能用”的多Agent工具，Claude Squad更务实。如果你想要一个”设计思路更前卫、但有成长空间”的项目，Firstmate值得盯着。
有一个指标我会持续关注：Issue的关闭速度。目前来看响应不快，但如果未来两个月内核心兼容性问题开始大规模关闭，说明项目站稳了，从”一个人的side project”变成”可以依赖的工具”。如果Issue数继续涨而关闭速度没有变化，那它大概率会变成又一个”概念很好但没人维护”的开源项目。
当然，如果它成了，影响可能比看上去大。”agent distro”这个模式一旦跑通，后面会有其他人fork它、改它、为不同场景定制不同的发行版。Firstmate真正的价值不在今天能跑几个Agent，在它能不能定义一个Agent协作的范式。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/kunchenguid/firstmate |
先在Mac上跑起来
如果你日常用Mac或Linux做主力开发、同时维护多个项目、受够了在Agent窗口之间来回切，Firstmate值得试。从安装开始，clone后直接claude启动，选一个你知道怎么做的小任务交给它。
如果你在Windows上、或者对稳定性要求高、或者只用一个Agent就够了，等两个月再看看。关注两个指标：Windows后端的兼容性改善，以及Issue关闭速度是否明显提升。这两点决定了它能不能从”好玩的概念验证”变成”靠谱的生产力工具”。
一个只有两个月的Bash项目，定义了2026年最有想象力的Agent协作范式。代码远没跟上想法，但这个想法本身，值得你记住这个名字。