多个 AI 编程智能体怎么组队干活？openrig 用 tmux 搭了个常驻团队

GitHub 仓库

mvschwarz/openrig

总 Stars

★ 8,378

主要语言

TypeScript

查看 GitHub 项目

openrig 想解决一个具体问题：一个智能体干大活总会顾此失彼，那就组个队。仓库 8,378 个 star，主语言 TypeScript，Apache-2.0 许可证，2026 年 10 月 30 日有新推送。它把 Claude Code、Codex、Pi 编成有角色、有共享上下文、有分工的常驻团队，底层跑在 tmux 上。

它是什么

一套多智能体编排框架：定义团队、角色和任务归属，智能体共享上下文、各自认领工作，跑在 tmux 会话里，关掉终端也不散。官网 openrig.dev，fork 数 692，open issue 132 个。

能干嘛

拆得开的大任务：一个写接口、一个写测试、一个盯文档，彼此能看到共享上下文，减少重复问、重复做。个人开发者也能把长期项目挂成常驻团队，隔天回来接着干，不用每次重新交代背景。

组队之后，成本和扯皮怎么办？

两个现实问题先想好。第一是钱：智能体翻倍，API 调用量跟着翻倍，账单先按两到三倍估。第二是协调：角色和任务边界写不清楚，智能体会互相改同一处代码。openrig 给的是骨架，规矩得自己定，先定两个角色跑顺了再加。

适合谁 / 注意点

适合熟悉 tmux 的开发者、想试多智能体协作的技术负责人。注意：它只是编排层，不自带模型，账单和密钥还是自己的事；132 个 open issue 说明还在早期，复杂场景先在小项目里验证。核验：2026 年 10 月 31 日北京时间 8 点 44 分，GitHub API。

站长点评

我收这篇是想给读者一个清醒的参照：多智能体是真趋势，但组队不等于省心。openrig 的卖点——常驻、共享上下文、角色分工——恰好打在单智能体的痛点上。真要上，我的顺序是：先定两个角色、跑两周、算清账单，再谈扩大。