GitHub 2.6K Star 的团队操作系统：@ 串起邮件、聊天、文档、任务、Agent

macro-inc/macro 是一个统一团队工作空间。它把邮件、聊天、文档、任务、Agent、通话、CRM 全部收进一个系统，再用 @ 提及把它们串成一张网。项目最近刚开源，GitHub Star 数已经来到 2,609，其中 1,239 颗是最近新增的。

它解决什么问题

创始人直接在 README 里点明了问题：

我们用过所有好工具——Slack、Linear、Notion、HubSpot、Superhuman——但它们没法作为一个系统协同工作。公司规模到 20 人时，每个团队选自己的工具，公司靠 MCP 和 Zapier 勉强粘在一起。系统不可计算，只有混乱。

这大概是很多创业公司的真实写照：

• 客户信息在 HubSpot，沟通在 Slack，任务在 Linear，文档散落在 Notion
• 想翻出"上周客户 X 提的那个需求"，得在好几个工具之间来回切换
• CRM 永远不更新——因为真实的对话都发生在聊天工具里
• Agent 没法跨工具理解上下文，只能记住和你的对话历史

Macro 给出的解法很直接：把这些工具放进同一个系统，从底层重新设计一遍。

GitHub 数据

指标	数值
总 Stars	2,609
Forks	278
主要语言	Rust / TypeScript
开源协议	AGPLv3

值得关注的点

1. 不是"多合一"，而是"从零重新设计"

市面上不少产品号称"多合一"，本质上就是把好几个工具的体验强行糊在一起。Macro 的思路明显不一样：

• Email 模块：学习 Superhuman 的键盘优先设计，同时加入多账户统一收件箱、AI 辅助起草、公司/联系人聚合
• Tasks 模块：参考 Linear 的体验，但和 Channel、Email、Agent 深度打通——可以从邮件一键创建任务，任务还会自动链接回原始邮件
• Docs 模块：借鉴 Notion，但基于 CRDT 做实时协作，支持 @ 提及任何对象（邮件、任务、联系人）
• CRM 模块：对标 HubSpot，当对话发生在 Channel 时，@ 提及公司名就能自动关联到 CRM 记录

每个模块各自对标了该领域的最佳实践，但底层共享同一个数据库和权限系统。

2. @ 提及串起整个系统

Macro 的核心交互就是一个 @：

• 在 Channel 里 @ 一份文档 → 形成双向链接，从文档点进去能看到哪些 Channel 讨论过它
• 在邮件里 @ 一个任务 → 自动建立关联，任务详情能直接看到原始邮件
• 在 CRM 记录里 @ 一个客户 → 所有相关对话自动聚合到这条记录

这套设计让跨工具找上下文变成了一件自然到几乎无感的事。反过来想想传统工具：你得死记"那封邮件在 Gmail，讨论在 Slack，任务在 Linear"。

3. 团队级 AI 记忆，不只是聊天历史

Macro 的 Agent 记忆机制很特别：

• 它不是只记你和它的聊天记录
• 而是从整个团队的所有活动中构建记忆——邮件、聊天、任务、文档、通话记录
• 记忆每晚自动更新一次，把当天的新活动合成进已有记忆

这意味着你可以直接问 Agent："上周客户 X 的需求，工程师 Y 是怎么回应的？"——它不需要你去 Slack 翻记录、去 Linear 找任务、再去 Gmail 翻邮件。

要搭出这类团队级 Agent，底层大模型的调用和接入也得提前规划。如果不想逐个对接 Claude、GPT、Gemini 等各家 API，RouteFast.ai 这类模型 API 中转服务可以统一处理，省下不少适配成本。

4. 完全开源，不是 Open Core

Macro 采用 AGPLv3 协议，而不是常见的"核心功能开源、高级功能收费"模式。这意味着：

• 全部功能代码都公开在 GitHub 上
• 任何人都可以自己部署完整版本
• 商业化通过托管服务和企业许可来实现

技术栈组合也很有意思：SolidJS + Rust，总共 42 个可部署服务、167 个 Rust 库。团队做了两年才正式开源，目前大约有 15 人在使用。

个人启发

产品思路：在"老赛道"里找到结构性缺口

Macro 闯进的是一个巨头环伺的赛道——Email 有 Superhuman，Chat 有 Slack，Tasks 有 Linear，Docs 有 Notion，CRM 有 HubSpot。

但它偏偏找到了一个结构性缺口：这些工具各自为政，没法作为一个系统协同工作。

这个缺口不是"功能不够"，而是"架构不对"。每个工具都守着独立数据库，跨工具的数据流动只能靠 Zapier、MCP 这类外挂管道。Macro 从第一天起就设计为单一数据库加上模块化 UI，数据天然互通。

这给了一个很实在的启发：在成熟赛道里找机会，不一定非要做"新功能"，也可以试着找结构性错位——用户已经用了一堆工具，但这一堆工具加在一起，并不等于最优解。

技术栈：为什么选 Rust + SolidJS

README 里有个细节值得注意：选 SolidJS 和 Rust，都是为了速度和可靠性。

• SolidJS 是细粒度响应式框架，性能接近原生，比 React 快一个量级
• Rust 在服务端保证内存安全和高并发，167 个库意味着他们把业务逻辑拆到了非常细的粒度

这个选择的背后，是对性能的极致追求。团队协作工具一旦卡顿，体验会迅速崩塌。Macro 的设计目标之一是"像 Superhuman 一样快"，技术选型正是为了支撑这个目标。

定位策略：先说服"小团队"

Macro 把目标用户锁定在"小公司或大公司里的小团队"。这个定位确实聪明：

• 小团队做工具选型相对简单，不用说服 500 人整体迁移
• 小团队更愿意尝试新工具，因为现有工具的"混乱"对效率的影响更直接
• 只要小团队用爽了，自然会向更大组织扩散

README 里有一句话："Any small company or team at a larger company can use as their operating system。" 仔细品一下，它不是卖"工具"的，而是在卖"操作系统"。

相关链接

• GitHub：github.com/macro-inc/macro
• 官网：macro.com

对这类开源项目感兴趣的话，也欢迎到云栈社区交流讨论。