📌 项目地址：macro-inc/macro | ⭐ 1,505 颗星 | 🔧 Rust | 📜 未标注
这不是一个寻常的开源项目
Macro 的 GitHub 仓库有 1505 个 star，语言是 Rust。但它的 README 没有安装命令，没有 Docker 部署指南，也没有 cargo install。页面顶部是 Sign up、Book demo、Website 三个链接。
这是个商业 SaaS 的产品主页，代码开放在 GitHub 上。
创始人说的”公司不可计算”是什么意思
README 里有一段自述，讲为什么要做 Macro。
创始团队在上一家公司扩张到 20 人时，工具链崩了：Slack 管沟通，Linear 管任务，Notion 管文档，HubSpot 管客户，Superhuman 管邮件。每个团队都有自己的工具，公司靠 MCP 和 Zapier 把系统粘在一起。原文用了一个很重的词：The company was not computable。
意思是，公司的整体信息状态无法用统一逻辑描述。一条客户反馈从邮件进来，到销售记录，到产品任务，到工程实现，数据被复制搬运了至少三次，每次都在不同系统里留下一个独立副本。事后有人问”这个需求当初是谁提的”，你得搜五个系统才能拼出答案。
Macro 的思路是把存储层统一，所有模块读写同一份数据图。
核心设计：双向图
Macro 把功能拆成 blocks——Email、Messages、Tasks、Docs、Canvas、Agents、Calls、CRM——每个模块界面独立，但共享同一个后端。README 里有一句关键描述：
cross-references between a doc and a task, or a channel message and an email, are natively stored as a bidirectional graph.
文档和任务之间的引用，频道消息和邮件之间的引用，原生就是双向图里的边，不是事后用 API 同步出来的。
这个差异很实在。传统套件里，文档里 @ 一个任务，系统调用任务 API 去创建一个链接字段；任务模块要显示反向引用，得再查一次。Macro 里一条边存两端，文档指向任务的边天然携带从任务返回文档的查询能力。
所有界面读的是同一份数据。邮件界面里建的任务节点，不需要”同步”就会出现在 Tasks 模块里。消息里 @ 一个邮件线程，两个实体之间的关系在存储层就已经存在。
模块是独立界面，不是通用模板套壳
README 的表格里列了每个模块的设计思路和文档链接。几个要点：
- Email：多账户统一收件箱，快捷键操作，共享收件箱，接 Gmail
- Messages：频道和直接消息，定位是”focused technical discussions”
- Tasks：Linear-inspired，和频道、邮件、agents 深度集成
- Docs：实时协作，Markdown 原生，基于 CRDT，支持 @mentions
- Canvas：2D 面板，可以嵌入任务、文件、邮件的 @ 链接
- Agents：统一团队级记忆，可以代为执行操作
注意最后一行。Agents 的记忆是 team-level 的，不是个人助手式的独立记忆。它可以回答”上周客户邮件里提的需求对应哪个任务”这类跨模块问题，因为邮件、任务、文档之间的关联在图上直接可达。传统工具里 agent 得先猜数据在哪个系统，然后逐个调 API 再自己拼上下文。
为什么是 Rust 和 SolidJS
README 里只有一句：Built in SolidJS and Rust for speed and reliability。
SolidJS 做前端，Rust 做后端。这个组合在 2025 年的 SaaS 创业公司里不算常见，但符合产品定位：统一收件箱要处理多账号邮件流的实时推送，全图搜索要跨所有模块的数据做遍历，双向图的读写路径不能有性能瓶颈。Rust 在这里解决的是后端吞吐和内存安全的问题，不是用来写脚本的。
Docs 模块用了 CRDT（无冲突复制数据类型）。多人同时编辑同一篇文档时，冲突解决在前端本地完成，不需要后端锁。这和 Figma 的多人协作思路类似，但实现难度不低——CRDT 的合并算法和存储设计都复杂，README 里敢直接写出来，说明团队在这块有过硬积累。
开源状态需要看清
仓库代码公开，但产品是 SaaS。数据跑在官方云端，不支持自托管（至少 README 没有提供任何自托管方案）。邮件模块目前只接 Gmail。
对国内团队，这意味着数据合规和网络延迟是两道硬门槛。如果你所在的公司对数据出域有严格要求，这个产品暂时用不了。
我的看法
Macro 值得关注的点不是”又一个 All-in-One 工作台”，而是它用双向图把模块间的关系做成了存储层基础设施。这个设计决定了对 agent 的支持不是后加的接口层，而是数据本身就结构化地表达了实体之间的关联。
代价也很明显：这是一套重后端系统，CRDT 协作、实时同步、全图搜索，每一项都是基础设施级的工程投入。小团队做不出来，大公司未必愿意用一个创业公司的云端服务承载全部工作数据。
如果你所在的公司 20 人以内，工具链已经乱到搜索一个信息要开五个应用（我经历过这种状态，确实抓狂），Macro 值得试一下。如果你所在的公司数据主权敏感，或者已经有一套完整工具链且运转顺畅，迁移成本要好好算。
Rust 写的办公软件不多，双向图驱动的团队记忆更少。这个项目的价值在于它认真尝试了”把工作软件重做一遍”这件事，而且做出了一些实在的设计决策。