Macro 是什么：邮件、任务、文档、CRM 共用一个双向数据库的开源工作区
“把邮件、消息、任务、文档、通话、CRM 放进一个界面”这句话，过去十年被讲过无数遍。多数时候它的实现是：几个独立产品共用一套登录态，侧边栏并排放几个图标，点进去还是各自的数据库，跨系统引用靠粘链接。用过的人都知道后面会发生什么——任务里贴了一条 Slack 链接，三个月后点进去发现没权限；CRM 里的公司记录停留在两个季度前，真实进展在某个群聊里；文档提到了某个工单，但工单那边完全不知道自己被提过。
Macro（GitHub 仓库 macro-inc/macro，AGPL-3.0，官网 macro.com）想解决的正是这一层。它的自我描述是”你和团队的一体化工作区”，把邮件、消息、文档、任务、Agent、CRM 收进同一个界面，共享团队级记忆；官方 README 里那句关键的话是：工作区里的一切都被 @ 链接、都可搜索，人和 Agent 都不用切工具。
这篇是这个专题的总入口。我们没有安装也没有运行过这套软件，下面所有内容都来自它公开的文档与 README，讲的是机制、配置和官方自己给出的定位，不涉及界面观感与实测数据。
它为什么被做出来：官方给的动机
README 里”Why Macro”一节写得相当直白：团队自己想要一个创业公司的操作系统。他们用过 Slack、Linear、Notion、HubSpot、Superhuman，评价是这些都是不错的产品，但”它们不作为一个系统协同工作”。当上一家公司规模扩到约 20 人时，问题开始暴露——每个团队各选各的工具，整家公司靠 MCP 和 Zapier 粘在一起。他们对那个状态的形容是：公司”不可计算”，很混乱。
所以 Macro 的定位不是再做一个更好的邮件客户端或更好的工单系统，而是把办公软件从地基重新设计成一个系统。团队在纽约和多伦多，自称约 15 人内部试用了两年，技术选型是 SolidJS 加 Rust。
“统一”的第一层含义：一切都是块
文档里的核心概念叫 block（块）。Macro 里所有东西都是块，官方列出的第一方块类型有：md（文档）、email、channel、chat（Agent 会话）、automation、project（任务）、contact（CRM 联系人）、company（CRM 公司）、call、canvas、code、image、video、pdf，以及兜底的 unknown。
这里有个容易误读的地方，README 专门澄清过：每个界面是为它自己的活儿单独做的，不是从一个通用块原语拼出来的；但所有界面共用同一个后端，文档与任务之间、频道消息与邮件之间的交叉引用，以双向图的形式原生存储。也就是说”块”更像是统一的引用与权限单位，而不是说邮件和画布用同一套渲染组件。
块层面还有几个统一能力：每个块都有 References 面板，回溯它被提及或嵌入的所有位置；每个块共用同一个分享对话框，权限级别是 owner / editor / commenter / viewer，文档另有公开链接。搜索是一份索引覆盖全部块类型，可以按类型、按被提及的人过滤。
块的具体字段与协作机制，我们单独拆了一篇：Macro 的数据模型：块、双向链与权限。
官方拿哪些产品做参照
这一点值得如实转述，因为它是理解各块设计取向最省事的入口。以下全部是官方文档的说法，不是我们的评测结论：
| 块 | 官方文档的定位原话（转述） |
|---|---|
| 比 Superhuman 更快，且带统一收件箱；多账号、键盘快捷键、共享收件箱，接 Gmail | |
| Messages | 设计成比 Slack 更聚焦、更少噪音，面向技术讨论的频道与私信 |
| Docs | 比 Notion 更简单；实时协作、markdown 原生、支持 @ 提及 |
| Tasks | 从 Linear “偷师”，但仪式感更低——周期、点数这些”真想要”也有，但官方建议别用 |
| Canvas | 2D 画板，内嵌指向任务、文件、邮件的 @ 链接 |
| Agents | 统一记忆、团队级记忆，可代表你执行动作 |
| Calls | 录制、转写，并记入团队级记忆供 Agent 使用 |
| File Storage | 从邮件和频道自动导入，全文可搜 |
| Pull Requests | 与任务关联，可嵌入频道，Agent 可访问 |
| CRM | 客户与联系人对象、自定义属性、邮件同步、信息补全 |
需要说明的是，“更快""更简单”这类比较是厂商自述，我们没有跑过对照测试，也不打算替它下结论。真正可核查的是机制部分，比如 Email 的多账号统一收件箱怎么工作、Tasks 从哪些入口创建，这些文档里写得很具体。
第二层含义：@ 提及生成双向链
Macro 反复强调的机制是 bidirectional @linking。在频道消息里 @ 一篇文档，消息和文档互相知道对方存在，于是任何一件事都能追溯它被讨论过的位置。这套机制跨所有块类型生效：文档、任务、邮件、文件、通话都算。
落到具体场景，README 给的例子挺能说明问题：任务与创建它的上下文（比如一封客户邮件）双向关联，于是”为什么要做这件事 → 任务 → Agent → Pull Request”这条链在同一个系统里是可审计的。CRM 那节的逻辑也一样——@ 提及一个公司记录会在消息和记录之间建立双向链，事后从记录出发能回溯当时的对话。官方对独立 CRM 的判断是：关于一笔单子的真正重要对话不发生在 CRM 里，而发生在消息里。
任务的创建入口，README 列了七种：从邮件创建、任意位置按 c t、在文档里用 /task、把任意 - [ ] 待办高亮后点 Task、在频道或私信里 @Macro、在 Agent 会话里、以及通过外部 MCP / API / SDK。
第三层含义：权限跟着频道走
这条规则很短但影响很大：权限从频道继承。你在频道里 @ 的东西，频道所有成员自动获得访问权，不用再走一遍”能不能分享给我”的流程；人加入频道就拿到权限，离开就失去。
但文档里有一个必须记住的例外，容易踩坑：在文档里做嵌入或提及，不会自动授予权限，这和频道里的提及规则相反，嵌入的文件仍需另行分享。这种”看起来一样、规则不一样”的设计差异，比任何界面细节都值得提前知道。
嵌入的做法是先用 @ 或拖拽生成一个 @ 提及，然后悬停点 Convert to embed；大多数块在 markdown 文档里以只读方式嵌入，编辑与批注工具被禁用。
第四层含义：一个收件箱 + 键盘流
统一收件箱把邮件、频道消息、任务指派、@ 提及、Agent 回复都收到一处，按 Signal（需要你处理）与 Noise（其余）分开；未读通知按时间倒序汇总成一份列表。
官方入门文档给的”先学五个键”是这样：
| 按键 | 作用 |
|---|---|
c | 打开创建启动器，再按 d 文档 / t 任务 / e 邮件 / m 消息 / a AI 会话 |
cmd+k | 命令菜单，按名字跳到任何东西 |
/ | 跨邮件、文档、任务、消息、通话、文件的统一搜索 |
j / k | 在任意列表里下移 / 上移 |
e | 标记完成：归档邮件、清掉收件箱条目 |
另外 g+i 打开统一收件箱，space 预览。桌面端（移动端没有）还带自己的窗口管理器，在浏览器一个标签页里分屏：cmd+\ 新建 split，shift+enter 把列表项或 @ 提及在新 split 打开，shift+h / shift+l 切换焦点，shift+escape 最大化，cmd+escape 关闭，opt+[ / opt+] 在单个 split 内前进后退。能开几个 split 由显示器尺寸和缩放决定，放不下就开不了新的。
上手流程官方说约 15 分钟，我们把七个步骤拆成了一篇：Macro 十五分钟上手：从空账号到能干活。
Agent 共享同一份记忆
这是”共用一个库”这件事最直接的收益，也是 Macro 和拼装型方案差别最大的地方。因为团队上下文本来就在同一个数据库里，它用一个每日 cron 任务更新团队级记忆：来源包括团队对话、私信、收发的邮件、创建与完成的任务等，全部一次性综合成一份输出，再与此前的记忆合并，而不是各来源分别成文。
几条可核查的边界：这份记忆通过 MCP 对外部 Agent 开放，也可以经模型选择器给到 OpenAI、Google、Anthropic 等模型；记忆以纯 markdown 存储，可以自行导出；要手动更新，直接让 AI 记住某件事或更新记忆。官方也说明记忆不该包打一切，所以另外提供了工具 / MCP 面，覆盖率接近 Macro UI 里能做的全部操作，且 MCP 没有速率限制。
编码 Agent 接进去只要一条命令：
claude mcp add --transport http macro https://mcp-server.macro.com/mcp
记忆的生成口径、能覆盖什么、不覆盖什么，展开在这篇：Macro 的统一记忆是怎么攒出来的。
底座：Rust + Solid，协作走 Loro CRDT
文档里提到的技术细节不多，但都挺具体。前端 SolidJS，后端 Rust。协作类的块（文档、PDF 批注）通过 Loro CRDT 在 Cloudflare Durable Objects 后端上同步：Rust 写的 sync-service 为每篇文档启一个 Durable Object “房间”，客户端用 WebSocket 连到 /document/:id。多人编辑、在线光标、完整离线支持都建立在这套之上。
文档还提到 Agent 以对等身份加入 CRDT 协作体系去编辑文档，冲突由 CRDT 原生处理；Agent 可以编辑打开或未打开的文档。README 举的例子是一个每天跑的 Automation，扫遍频道后更新一份内部 markdown 文档，如果有人已经手工改过，它能识别并跳过更新。
仓库结构官方也贴了：apps/web（SolidJS 客户端，覆盖浏览器、Tauri 桌面端、移动端）、apps/docs、services（42 个可部署服务、Worker 与 Lambda handler）、crates（167 个 Rust 库）、packages（共享 TypeScript）、infra（Pulumi）、docker、nix、tooling。服务按六边形架构组织：入站适配器、带端口的领域核心、出站适配器。
许可证是 GNU AGPL v3.0，官方强调是完全开源而非 open core，可以按 AGPLv3 自托管。自托管的具体路数见：Macro 自托管与本地跑起来。
什么时候不适用，以及还没解决的
邮件账号类型是硬门槛。 Macro 不是邮件服务器，只是客户端，与已有的 Gmail 或 Google Workspace 账号同步，邮件仍留在 Gmail。Outlook 与自定义 IMAP/SMTP 支持，官方标注为计划中，目前尚未提供。如果团队邮箱在 Exchange/Outlook 或自建邮件系统上，这一条基本就把邮件这块排除了。
平台覆盖有缺口。 桌面端的窗口管理器与分屏在移动端没有；移动侧有 iOS App，Android App 官方标注为计划中，目前尚未提供。
“一个系统”的代价是耦合。 把邮件、任务、CRM、文档全押在同一个库上，意味着迁移成本和单点依赖都集中了。官方给的缓解手段是 markdown 原生与批量导入导出（README 引用了 “file over app” 的说法）、记忆以 markdown 明文存储、以及 AGPLv3 允许自托管——这几条是否够用，取决于你对退出路径的要求有多硬。
版本控制还早。 文档的历史与分叉功能，官方自述仍在 v1，“要接近 git 还有很多事要做，或者我们最终会加上 git 兼容”。把它当成 Google Docs 式的版本历史看待更稳妥。
迁移不是零成本。 Notion、Slack 等工具可以通过 Settings → Connectors 里的 MCP 连接器让 Agent 访问，GitHub 在 Settings → Account 里绑定后任务会随分支、开 PR、合并在 In Progress / In Review / Done 之间流转。但这些是连接，不等于把历史数据搬过来。
安全资质方面，README 列了 SOC 2 Type II 认证与 ISO 27001 徽标，并声明与模型提供方零数据留存、不用客户数据训练。这些是厂商自述与第三方认证的组合，采购时按常规流程索要报告即可，不必只信 README。
如果你正在评估要不要动这套东西，我的建议是先把两个问题问清楚：邮箱在不在 Gmail 生态里，以及能不能接受把跨系统引用这件事从”粘链接”换成”@ 提及 + 频道权限”。前者是能不能用的问题，后者是习惯改不改的问题——文档里那条”频道提及自动授权、文档嵌入不自动授权”的差异，就是这套习惯要重新校准的第一个点。
延伸阅读
- 本专题共 40 篇，完整分组目录见专题页
- Macro 十五分钟上手：官方 Get Started 的七步里，哪几步是真卡点
- Macro 邮箱怎么接入：Gmail 多账号合成一个收件箱，以及它管不管你的邮箱
本文依据 Macro 官方仓库（github.com/macro-inc/macro，AGPL-3.0 协议）的 apps/docs/ 产品文档、
MCP 工具参考与自托管说明整理，核对日 2026-08-17。
我们没有注册或运行过 Macro，因此不涉及界面外观与操作手感；
官方标注为计划中的能力文中已如实标明，不代表当前可用。
价格与额度以官网 macro.com 最新页面为准；许可证相关问题请咨询专业人士并以官方许可证原文为准。