📌 项目地址：macro-inc/macro | ⭐ 1,505 颗星 | 🔧 Rust | 📜 未标注
工具太多，本身就是问题。Macro 团队在上一家公司扩张到 20 人时，被 Slack、Linear、Notion、HubSpot、Superhuman 的组合拳打懵了。每个工具单看都挺能打，但它们之间靠 MCP 和 Zapier 强行缝合，出了问题找数据像在五个抽屉里翻找一颗螺丝钉。创始人原话是：”The company was not computable.”
他们的解法不是再写一层集成，而是把所有工作软件推倒重写成一个系统。Macro 把邮件、消息、文档、任务、CRM、通话、文件、PR 全部塞进一个界面，用同一个后端存储。这个项目是 Rust 写的，Star 数 1505。
双向图：@ 不是装饰，是数据结构
Macro 最核心的设计藏在”双向图”里。你在文档里 @ 一个任务，系统不是存一个链接地址，而是把这条引用关系作为数据结构存下来。任务那边能感知到被哪个文档引用了，消息里的 @ 能关联到对应的邮件线程，PR 和任务之间互相可见。
这套东西的实际效果是：你可以问 AI “上周客户邮件里提的需求对应哪个任务？”它能沿着图关系给出答案，而不是在一堆文件里做关键词搜索。
功能块设计：每个模块独立，但共享一个后端
Macro 的功能块（blocks）设计思路是模块化，像乐高一样拼装。每个模块都研究过现有产品里最好的实现，然后试着做得更好。下表是 README 里列出的模块和它们的作用：
| 模块 | 作用 |
|---|---|
| 多账户统一收件箱，快捷键，共享收件箱，支持 Gmail | |
| Messages | 频道和私信，设计给技术讨论用 |
| Tasks | Linear 风格任务，和频道、邮件、agent 深度集成 |
| Docs | 实时协作，原生 Markdown，基于 CRDT，带 @ 提及 |
| Canvas | 2D 白板，可以嵌入任务、文件、邮件的 @ 链接 |
| Agents | 统一的团队级记忆，能代理用户执行操作 |
| Calls | 通话录制、转写、记录，供给 agent 使用 |
| File storage | 从邮件和频道自动导入文件，全文可搜索 |
| Pull requests | 关联任务和频道，agent 也可以读到 |
| CRM | 和上面所有模块共享同一个数据图 |
注意一个细节：CRDT 做实时协作，说明文档是类似 Notion 那样多人同时编辑的设计。而”每个表面为特定任务定制”意味着邮件界面就是邮件界面，消息界面就是消息界面，不是从一个通用 block 套壳改出来的。
实际体验：这是一个商业 SaaS，不是自托管项目
README 里没有任何安装命令，没有 Docker 部署，也没有 cargo install。Macro 的 GitHub 仓库更像产品主页和文档入口，实际使用需要去 macro.com 注册。产品文档在 docs.macro.com，每个模块都有独立文档页（比如 /product/email、/product/channels）。
这点需要准备入手的团队注意：如果你找的是能自己部署的开源替代品，Macro 不是。它是云端商业产品，数据在官方服务上跑。团队记忆、agent 行为、@ 链接的搜索都依赖云端，想在内网部署就不用考虑了。
和”缝合怪”工具的差别
市面上很多工作空间套件做的事是：把不同工具的 API 串起来，加一层统一界面。Macro 的做法是让所有数据类型共享一个图谱，AI agent 也在这个图谱上工作，而不是每个工具各带一个孤立助手。
这个差异对实际使用的影响挺大：同样是”把邮件和任务关联”，缝合方案是建一个外挂的 relationship 表，Macro 是原生存储在数据结构里。后者的查询能力、agent 的可操作性、跨模块响应的速度都不在一个量级。
几个需要提前确认的点
- 邮箱目前只支持 Gmail，重度用其他邮件服务商的团队要等一等
- 这是商业产品，虽然有免费注册入口，团队规模大了大概率要联系销售问价格
- 基于 Rust 和 SolidJS，速度和响应可以期待，但它不支持自托管，数据主权由官方控制
我觉得这个项目最值得关注的不是它”能做多少事”，而是它验证了一条路：工作软件确实可以用单一系统替代多个工具的拼凑。至少从团队两年多的内部使用来看，这个方向走得通。