文档大纲

一个AI干不完所有事：openrig怎么搭一支专业代理小队？

当你一个人干活干到很烦的时候，你有没有想过：如果能克隆出好几个自己，一个写代码、一个检查、一个测试，那多爽？

mvschwarz/openrig 把这种"分身干活"的思路变成了可运行的代码：构建一个由多个专业代理组成的持久化团队，让 AI 代理像一支小队那样协作，而不是把所有事情都塞给一个代理。

如果你正在用 Claude Code、Cursor 这类 AI 工具做开发，或者你是一个电商运营、内容创作者，每天都在和 AI 协作但又觉得"一个 AI 干不了所有事"，那这个项目值得花 5 分钟了解一下。

openrig 到底在解决什么问题？

过去一两年，AI 编码工具的演进基本沿着一条路走：单个代理越来越强。Claude Code 能写代码、能调 API、能跑测试；Cursor 能补全、能解释、能重构。但用着用着你会发现一些卡点：

上下文窗口是有限的：一个项目写了几千行代码之后，AI 代理就开始"失忆"，前面的设计决策忘了
专业深度不够：让一个 AI 同时写前端、调数据库、写 SQL、调 API、设计 UI，它哪样都能做，但哪样都不够专业
任务切换成本高：你让它"先写代码，写完做 review，再写测试"，每次切换都要重新铺垫上下文
每次对话都要重新解释背景：今天聊过的设计决策，明天重新开一个对话又要讲一遍

openrig 的思路不一样：

与其让一个 AI 代理当"全能选手"，不如组建一支专业小队。

具体怎么实现？四个核心机制：

角色化代理（Role-based Agents）：每个代理有明确角色，比如 coder、reviewer、tester、文档写手，各司其职
共享上下文（Shared Context）：所有代理读同一份"团队记忆"，不需要你每次重新铺垫背景
持久化团队（Persistent Team）：代理团队是常驻的，不是用一次就解散
任务所有权（Task Ownership）：每个任务有明确的负责代理，驱动工作流转，谁干完谁接手下一个

技术架构：四层目录看清全貌

openrig 是 TypeScript 写的（仓库地址：https://github.com/mvschwarz/openrig ），目前 3,800 多颗星，今天新增 642 颗。它的目录结构非常清晰：

openrig
├── agents/        # 代理定义：每个角色的 prompt、工具、能力边界
├── context/       # 共享上下文管理：团队记忆怎么存、怎么读、怎么压缩
├── tasks/         # 任务系统：任务怎么分配、流转、追踪
└── runtime/      # 运行时调度：代理什么时候上线、什么时候下班

几个值得关注的关键特性：

与 Cursor / Claude Code / pi 兼容：你不用切换工具链，openrig 是在你现有工具上做编排
支持 MCP（Model Context Protocol）工具调用：MCP 是 Anthropic 推的"AI 工具标准协议"，能让 AI 调用外部工具（数据库、API、本地文件等）
持久化会话内存：团队记忆不会因为对话结束而清空
跨 17 个平台 Hook 路由：Hook 就是"在某个动作发生时自动触发另一段逻辑"，openrig 把这套机制扩展到了 17 个平台

和同类项目比，openrig 强在哪？

光说"我们支持多代理"不够，得跟同类的开源项目比一比。我挑了两个同期热门项目对比：

特性	openrig	obra/superpowers	mksglu/context-mode
代理网络	✅ 原生支持	✅	❌
持久化团队	✅	✅	❌
上下文压缩	❌	❌	✅ 98% 压缩
MCP 工具调用	✅	✅	✅
TypeScript 原生	✅	❌	❌

看表格更直观一些：

obra/superpowers：也是多代理框架，但它是 Claude 生态的 skill 框架，TypeScript 友好度不如 openrig
mksglu/context-mode：不搞多代理，但它把"上下文窗口优化"做到了极致——工具输出压缩 98%，省 token 省钱

openrig 的定位很清晰：多代理 + 持久化 + MCP，如果你正好需要"长期运行的专业 AI 团队"，它是最贴合的选择。

哪些思路可以借鉴到你的工作里？

openrig 是为软件工程场景设计的，但它背后的几个设计哲学，对所有用 AI 协作的人都有启发：

1. 「懒代理」哲学：先问"真的需要 AI 吗？"

这不是 openrig 自己说的，是同期另一个 trending 项目 DietrichGebert/ponytail 的核心理念——"最好的代码是根本没写的代码"。

套用到 AI 工作流就是：先判断任务是否真的需要代理，还是一个简单脚本就能解决。很多"自动化"其实是过度设计，明明 bash 一行命令能搞定的事，非要让 AI 代理跑一圈，反而更慢更贵。

2. 角色化代理：把"一个人干所有事"拆成"专业小队"

openrig 的 coder、reviewer、tester 这种角色分工，完全可以映射到内容生产、电商运营、客服等各种场景。

举几个具体的例子：

内容生产流水线：选题代理（找热点）→ 写作代理（初稿）→ 润色代理（去 AI 味）→ 发布代理（推到平台）
电商客服：售前代理（答咨询）→ 售后代理（处理退货）→ 升级代理（处理投诉），每个角色用不同的 prompt 和知识库
数据分析：数据清洗代理 → 指标计算代理 → 报告生成代理，每一步的输入输出明确

3. 持久化上下文：定期压缩省成本

context-mode 的 98% 工具输出压缩是个非常实用的优化思路。对于长期运行的自动化任务，定期压缩上下文可以显著降低成本。

具体做法：

每完成一轮对话，就把对话历史做摘要
只保留"决策结论"和"关键数据"，丢掉中间过程
下一轮对话开始时，把摘要作为新上下文喂回去

这样你的 token 消耗可以从"线性增长"变成"对数增长"。

4. 多代理 + Skill 框架：1+1>2

openrig 的多代理协作模式，可以和 superpowers 这种 skills 框架结合——每个代理不仅有自己的角色，还能挂载特定的 skills。相当于：

"你是一个 Java 工程师（角色），同时你精通性能优化（skill），还熟悉我们公司的代码规范（私有 skill）。"

这种"角色 + 技能"的组合，比单纯的 prompt 注入要灵活得多。

什么时候你用不上它？

实话实说，openrig 不是万能药。以下几种情况，你可能根本不需要：

一次性脚本 / 临时查询：开个 Claude 对话问一句的事，别上多代理
超小项目（<1000 行代码）：单代理就够用，团队化反而是负担
预算有限 / Token 敏感：多代理意味着多轮调用，token 消耗比单代理高 3-10 倍
没有清晰的"角色边界"：如果你的任务本身就是模糊的（比如"帮我设计一个 logo"），强行分角色反而越搞越乱

判断标准：你的任务能不能拆成 3 个以上、彼此输入输出清晰的子任务？能 → 多代理值得尝试；不能 → 单代理更省心。

快速上手建议

如果你看完有点心动，建议按这个顺序尝试：

先读 README 跑通最小 demo：openrig 仓库有现成的 example，按文档跑一遍看是否符合你的预期
从 2 个代理开始：别一上来就搞 5 个代理，先试 coder + reviewer 这个最小协作单元
明确每个代理的 prompt 边界：别让两个代理的职责有重叠，否则会出现"两个代理都说这事归我管"的混乱
用 MCP 接你的真实工具：MCP 是 openrig 的杀手锏，把它和你日常用的数据库、API、文件管理接起来
观察一周再决定是否扩展：第一周只看"代理之间的协作是否顺畅"，第二周再决定是否加第三个代理

💡 落地案例：内容团队的"代理小队"

一个真实的场景参考——如果你也在做内容生产，可以这样搭：

代理角色	职责	输入	输出
选题代理	监控热点、推荐选题	行业关键词列表	5 个候选选题 + 热度评分
写作代理	根据选题生成初稿	选题 + 风格指南	800-1500 字初稿
润色代理	去 AI 味、检查错别字	初稿	终稿
发布代理	推送到 WordPress / 公众号	终稿 + 平台配置	发布成功回执

这套小队跑起来后，一个人可以同时维护 3-5 个内容账号，每天产出 10-15 篇符合调性的文章。

你也可以用类似方式搭自己的"代理小队"——客服、数据分析、代码 review、销售跟进，原理都是一样的：把流程拆清楚，把角色定义清楚，让 AI 替你做重复劳动。

写在最后

openrig 的价值不只是"又一个 AI 框架"，而是它背后那个朴素的想法：专业的事情应该交给专业的人，AI 也一样。

与其追求"一个超级 AI 替你干所有事"，不如花点时间想想：你的工作里，哪些环节可以拆给"专业代理"？哪些环节其实不需要 AI？

想清楚这两个问题，openrig 这类工具对你才是真有用，否则你只是又装了一个跑不起来的玩具。

项目地址：https://github.com/mvschwarz/openrig

今日数据：3,817 stars · 642 新增 · TypeScript

适合谁：多步骤、可拆解、长期运行的 AI 协作场景

不适合谁：一次性脚本、超小项目、预算敏感的轻量场景

阅读量： 323