macro-inc/macro · 上手攻略
- 仓库：macro-inc/macro
- 链接：https://github.com/macro-inc/macro
- 分类：agent · skill · 团队协作操作系统（全开源 / AGPLv3）
- 作者：spark
- 更新：2026-10-22
1. 这是什么
Macro 想做的是"团队的操作系统"——把邮件、消息、文档、任务、Agent、电话、CRM 全部用 @mention 串起来，由同一份"团队级 AI 记忆"驱动，按统一权限在同一块画布上协作。它不是一个"更轻的 Notion"或"更快的 Slack"，而是一个打通 8 个 SKU 的"可在浏览器里跑的 Macro Mail + Chat + Tasks + Docs + Canvas + Agents + Calls + CRM"。
实现上：
- 前端：SolidJS + Tauri 桌面 + iOS 应用（Android 即将上线），轻/重渲染按视图分形。
- 后端：
crates/167 个 Rust crate（领域模型 + 仓储 + 适配层）；services/42 个可部署服务；packages/共享 TS（lexical-core、loro-mirror 等）。 - CRDT 实时协作：Docs 用 Cloudflare Durable Objects + Loro-mirror（"loro-mirror"指基于 Loro CRDT 的镜像机制），不是"ka-chunk"型同步。
- 许可：不是 open core，是全开源——GNU AGPLv3，可自托管（FAQ 单独列了自托管路径）。
仓库卡片指标（采集时 2026-10-22）：Stars 4797，但 周增 +0——它是"已被发现"型仓库，不再是"正在爬升"型。
2. 解决什么问题
创始人背景：种子轮跑下来 ~20 人时，工具链（Slack / Linear / Notion / HubSpot / Superhuman）虽然都好，但彼此不通，全部靠 MCP + Zapier 缝合。这种"拼装式工作流"问题在大约 15–30 人阶段会全面暴露：
- CRM 不可计算：单独系统，团队聊到的最新状态永远不在 CRM 里。
- Issue tracker 失活：太刚性、跟主流聊天脱钩，所以没人愿意维护。
- AI 记忆只覆盖自己：聊天机器人只知道自己历史对话，不了解团队其他人在做什么。
- 跨 SKU 的上下文每传一次都要重打：邮件→任务→PR 之间的"为什么"要靠口头解释。
Macro 的核心论断是"The company was not computable. It was chaotic."，而 Macro 的解决方案是：把每个 surface 的"最佳实践"做好，再把它们存到一个统一后端 + 双向 @link 图里，并用每日 cron 把"团队记忆"合成给 Agent。
3. 快速安装
Macro 不是单条 pip install 或 npm install，而是有两种启动方式：
3.1 直接注册 SaaS 用
https://macro.com/app —— 连 Gmail 或 Google Workspace，跟着 getting-started 15 分钟能跑通。
iOS 应用：https://apps.apple.com/us/app/macro-app/id6743133649
3.2 自己跑前端 / 自托管（开发者）
git clone https://github.com/macro-inc/macro
cd macro
# 拉前端 + 服务 + 数据库走本地 Compose
# 详见 docs/development/running-locally.md
仓库根目录结构（README 摘录）：
macro/
├── apps/ SolidJS 客户端（浏览器 / Tauri 桌面 / 移动端）
├── apps/docs/ docs.macro.com 站点源码
├── services/ 42 个可部署服务 / workers / Lambda handlers
├── crates/ 167 个 Rust crate（领域逻辑 / 模型 / db 客户端）
├── packages/ 共享 TypeScript（lexical-core / loro-mirror 等）
├── infra/ Pulumi 资源定义
├── docker/ 本地 Compose 栈
├── nix/ 锁定版本 dev shell 与 build inputs
└── tooling/ 仓库脚本与代码生成器
服务层走六边形架构（inbound adapter → domain core with ports → outbound adapter），具体约束写在 docs/development/style-guide.md，PR 流程写在 CONTRIBUTING.md。
3.3 把现有 coding agent 接到 Macro
claude mcp add --transport http macro https://mcp-server.macro.com/mcp
详见 https://docs.macro.com/AI/mcp/overview 与"agent recipes" https://docs.macro.com/AI/recipes。
4. 核心用法
4.1 9 个 Block（README 摘）
| Block | 做什么 | 文档 |
|---|---|---|
| 多账户合并收件箱、键盘快捷键、共享收件箱（Gmail） | product/email |
|
| Messages | 频道 + DM，前几条回复 inline、其余收进 thread（针对"技术讨论"做减负） | product/channels |
| Tasks | Linear 风格任务，紧贴 channels / email / agents | product/tasks |
| Docs | markdown 原生 + CRDT 实时协作 + 历史/fork + 离线编辑 + Agent 原生编辑 | product/docs |
| Canvas | 2D 画布，@link 到任务 / 文件 / 邮件 | product/canvas |
| Agents | 团队级记忆，能代你执行 | product/agents |
| Calls | 录音 + 转写 + 落到团队记忆供 Agents 检索 | product/calls |
| File storage | 从 email / channels 自动导入、可全文检索 | product/folders |
| Pull requests | 链接到任务、可嵌入 channel、对 Agent 可用 | integrations/github |
| CRM | 公司/联系人对象、自定义属性、邮箱同步、自动补全 | product/crm |
4.2 让 Tools / MCP Agent 接到 Macro
- 在 Macro 里建一个 agent chat，走 MCP 协议。
- Macro 给出近 100% UI 操作覆盖的 tool / MCP surface（README 原话："near 100% coverage of the things you can do in Macro's UI"），且没有速率限制。
- Agent 可起草 / 编辑 / 发送邮件（在 chat 里完成，不开邮件应用）；可跨账户全文搜索所有邮件附件中的 PDF（不再"先取邮件线程再下载附件"）；可执行与 CRM 查询相关的检索与动作。
4.3 团队记忆
- 通过每日 cron 合成记忆，融合 team 谈话、DM、收发邮件、已建 / 已完任务；不是按"会话"单独建档，而是合成到上次记忆上。
- 记忆可被外部 agent 通过 MCP 读取，也可由 OpenAI / Google / Anthropic 等任何模型直接读取（走 model picker，可移植性优先）。
- 记忆以 markdown 平铺存储，可任意导出；想手动更新只需对 AI 说"记住/更新"。
- README 案例：作者用 notepad 截图 → 让 agent 建 tickets 并派给正确工程师 → 一次成功 0 工具调用。
4.4 Docs 的工程细节
- markdown 原生 + bulk import/export（README 强调 "file over app paradigm"）。
- CRDT + Cloudflare Durable Objects 让协作感觉"同一台机器"在编辑（不像 Google Docs 的"ka-chunk"延迟）。
- 版本控制：history + forking；目前是 v1，未来可能引入 git 兼容。
- 离线编辑 + 调和。
@link到 workspace 的所有对象：邮件、docs、任务、消息、频道、公司、联系人等。- Agent 作为"CRDT 协作系统的一等公民"对 docs 做协同编辑——见 https://404wolf.com/posts/AgentsAttackTheDocument/。
- 合并冲突交给 CRDT；例如："每晚 Macro Automation 滚一次办公室桌游清单 → 扫描通道看谁有一项已写 → 写入 doc；如 agent 发现人已编辑 doc，则放弃本次更新。"
4.5 Tasks 的创建入口
- 在邮件里
task一键 → 自动双向链接到"创建它的邮件"。 - 任意位置
c t。 - Markdown doc 内
/task。 - 任何
- [ ]bullet 高亮 + 点 "Task"。 - 任何 channel / DM
@Macro create tasks。 - 任意 agent chat。
- 外部 MCP / API / SDK。
用户故事强约束："为什么做这个" → 任务 → agent → PR，全链可审计。
4.6 CRM 的关键差异
- 默认按"团队 chat + email 的实际内容"自动更新 CRM，而非"独立 CRM + 经纪人手动同步"。
@公司名在消息里自动双向链接到公司记录。- 每条 deal "notes" 复用 channel / DM 系统（实际上是"每条 deal 自带一个被钉在 deal 记录上的频道"）。
- 不是要"完全重做 CRM"——kanban / 自定义阶段 / 列表视图 / 保存视图 / 共享视图等都保留，但消除"为跟进一个 deal 切换 4 个工具"的成本。
4.7 邮箱核心差异点（Macro Mail）
- 多账户 + 统一收件箱。
- j k 与 e 一键操作（键盘优先）。
- 邮件 / 消息 / @mention / 待办任务 = 一个收件箱。
- 多窗口分屏（≥3 split，随显示器扩展），起草邮件时可并行回看历史 thread。
cmd+k到联系人直接看与之的全部邮件，或到 @公司 看"全队 ↔ 全司"邮件；邮箱聚类还能喂给 agent 做 CRM 类问答。
4.8 安全与合规
- 与模型供应商签的合同：零数据保留 + 不训练客户数据。
- SOC 2 Type II 合规。
- 安全报告邮箱
security@macro.com，按严重等级与影响给赏金。 - AGPLv3 全开源；想"open core 之外"商用授权联系
licensing@macro.com；自托管 / hosted 联系self-host@macro.com。
5. 典型适用场景
- 小团队 / 早期 startup（10–30 人）：把工具链合并成 1 块画布，降低"为同步一下这件事切换 5 个工具"的税。
- 中型公司里"团队 OS"试点：挑一个 5–15 人小组，强制走 Macro，把 Linear + Slack + Notion + HubSpot 缩到一个工作区。
- 产品研发团队：用 Tasks ↔ Channels ↔ PR 的双向链接做"为什么做这个 / 谁在做 / 卡在哪"全链审计。
- 咨询 / 外销 / SDR 团队：用 CRM ↔ Channels / Email 的双向链接把"实际对话 = 实际 CRM"。
- 已有 AI agent 团队的接入：通过 MCP（
mcp-server.macro.com/mcp）把 Agent 接到 Macro，让 Agent 看到团队记忆而不是单会话历史。 - 私人 / 小公司希望"全开源替代"：因为是 AGPLv3，自托管门槛在 FAQ 里有专门路径。
6. 坑与注意
| # | 现象 | 影响 | 修复 |
|---|---|---|---|
| 1 | 误以为"开箱即用"就是注册 SaaS | 自己 clone 后跑不起来 | 区分 SaaS（macro.com/app）vs 本地自托管（docs/development/running-locally.md）；AGPLv3 自托管路径有 FAQ 专页 |
| 2 | 期待"周增"极高的相关活跃度 | 误判项目状态 | 仓库卡片 Stars 4797 / 周增 +0，写作时（2026-10-22）已属"被广泛认知"型仓库 |
| 3 | 用单一 channel 处理所有沟通 | thread / Noise/Signal 切分失效 | README 强调 Macro Chat 是"前两条回复 inline、其余收 thread"，让 busy channel 可读；按主题分 channel 而不是按项目名 |
| 4 | 把 CRDT 协作的"无冲突"当成"无覆盖" | 老用户手动改完不写 changelog | 用 history + fork 做版本回溯；agent 写之前先看 doc 是否被人工编辑过（CRDT 会告诉它） |
| 5 | 误把"团队记忆 = 自我聊天历史"对比给老板 | 演示效果被打折扣 | 一行解释：Macro 是从 team 整体（邮件 / IM / 任务）合成，所以能看到别人在做什么 |
| 6 | 接 MCP agent 但限速到 burst 模式 | 触发第三方速率限制 | README 明示 Macro MCP 没有速率限制，但如果中途接 OpenAI / Anthropic 等底层模型，限速来自上游 |
| 7 | 把 AGPLv3 当成"闭源 SaaS 兼容"做二次分发 | 法务冲突 | 想闭源分发或售卖衍生必须走 licensing@macro.com；明确"AGPLv3 = 修改后网络对外提供服务也必须开源" |
| 8 | 假设 cursor 自动装好 CRDT / Durable Objects | 自托管环境需 Cloudflare 账户 | 自托管路线请走 FAQ 中 self-host@macro.com，先确认 DO 资源与账号配额 |
| 9 | 把 @mention 自动共享错认为 ACL 替代品 |
内部机密类型被自动暴露 | README 强调 channel-based permissions：被 @mention 即默认共享，仍要遵守 channel 成员 |
| 10 | 没用 docs 的 history/fork 就大改 markdown | 丢失旧版本 | v1 历史/fork 已可回滚，但要养成"先 fork 再改"的习惯；不建议直接覆盖 |
7. 与同类对比
| 维度 | Macro | Slack + Linear + Notion + HubSpot | Notion + AI | Linear（单工具） |
|---|---|---|---|---|
| 团队记忆共享 | 每日 cron 合成、跨 SKU | 各自一份 | Notion AI 单体记忆 | 单工具局部 |
@link 双向图 |
原生（同一后端） | 只能靠 Zapier / 手动复制 | 部分 Notion 内 | 否 |
| 邮件内嵌 | 是（Gmail） | 否 | 否 | 否 |
| CRM 内嵌 | 是（原生物件） | 否 | 否 | 否 |
| MCP / Tool 覆盖率 | "near 100%"，无限速 | 部分 | 部分 | 否 |
| 开源协议 | AGPLv3 全开源 | 闭源 | 闭源 | 闭源 |
| 前端栈 | SolidJS + Tauri + iOS | 各异 | Web | Web/Desktop |
| 后端栈 | Rust 167 crate + 42 服务 | 各异 | Notion 内 | 单体 |
| 自托管 | 是（AGPLv3） | 否 | 否 | 否 |
| 适用阶段 | 10–30 人创业团队最甜蜜 | 任何规模 | 任何规模 | 工程团队 |
8. 一句话推荐结论
如果你的团队卡在 10–30 人、并且日常被"邮件 / 聊天 / 任务 / CRM 互相不通"反复咬——值得试 Macro；如果是 50+ 大公司里某个 5–15 人小组，可以先做小范围 PoC，确认 AGPLv3 的法务兼容性后再铺开。
不确定 / 诚实标注
- 仓库卡片
Stars 4797 / 周增 +0 / 最近提交 2026-10-21 / 采集 2026-10-22，但周增为 0 不代表项目停滞——README 自述内部 ~15 人团队 self-hosted 使用两年。实际活跃度请直接看 GitHub Insights / commit history。 crates//services//packages/数量（167 / 42）以 README 写作时为准；后续 release 可能增减。- 截至本次写作，Android 应用未上线（README 自述 "Android coming soon"）。
- "loro-mirror" 的具体同步协议细节未在本仓库 README 展开，需看
packages/loro-mirror/的源。 - AGPLv3 在团队内部自托管 vs SaaS 改造的法务边界，请联系
licensing@macro.com做合规审查；本文仅复述 README。