Macro：用双向链接与共享记忆重造团队工作区

先给判断：Macro 不是「又一个 All-in-One 工具」，它对团队软件有一个结构性主张——分散工具的病根是数据不连通，解法是把邮件、消息、文档、任务、CRM 放进同一个数据底座，让所有对象互相 @ 链接、双向可溯，再让代理以一等公民身份住进这张图里。这个主张决定了它值得看的姿势：不是对比功能清单，而是看它的数据模型。

macro-inc/macro 4,478 stars / 434 forks（截至 2026-09-29），主语言 Rust，AGPLv3（README 强调 fully open source，不是 open core），2025 年 11 月开源，本文核实前一天仍在 push——开源不满一年维持这个节奏，说明它活着。团队自述在纽约与多伦多设计，约 15 人内部吃自家狗粮两年才放出来。

系统地图：十个 block，一张图

Macro 把每个功能面称为 block（积木块）。各 block 为自己的工作专门设计，但共享同一个后端。先看全景：

这张表的读法：每一行都是竞品扎堆的成熟赛道，单独看任何一格，Macro 都是追随者；它的赌注押在「所有格子共享同一个后端」上——这个组合别处没有。

出发点：公司不该靠胶水黏合

README 的动机段写得相当直白：这批人自己开过公司，Slack、Linear、Notion、HubSpot、Superhuman 全都用过，工具一多，公司就靠 MCP 和 Zapier 勉强缝在一起——「公司不可计算（not computable）」。上一个项目做到约 20 人时这套缝合开始散架：每个团队各带各的工具，没有哪个系统能回答「公司现在到底什么状态」。Macro 的答案是从零设计一个单一系统。

数据模型：一切对象住在一张双向图里

Macro 的每个 block 不是独立子系统，而是同一后端上的不同视图。交叉引用以**双向图（bidirectional graph）**原生存储——文档 @ 提及一封邮件、频道消息 @ 链接一个任务、CRM 公司记录挂进工程任务，从任一端都能导航到另一端。

权限也长在图上：在频道里 @ 的对象自动对成员可见，加入频道获得访问权、退出即失去，没有逐条授权的「权限申请舞」。README 把这条单列为卖点（channel-based permissions）。

代理不是挂在旁边的插件。代理编辑文档走与人类相同的 CRDT 协同协议，作为「同行编辑者」参与，冲突由 CRDT 原生解决。README 给的日常例子：一个每日自动化扫描所有频道、更新办公室桌球赛战绩文档；若发现已有人手改过，它感知到并跳过。

任务与 CRM：两场针对「记录会过期」的设计论

任务和 CRM 是最值得细看的两个 block，因为它们的动机同构。

任务侧，他们引 Linear 那份「issue tracking 已死」的报告，但立场更强：issue tracking 从来就没真正工作过，因为它与真实对话（聊天）是两个系统，注定过期——所有人都在「错误地」使用 issue tracker，这恰恰说明问题在工具设计，不在用户。解法也不是放弃追踪（他们试过，是另一种混乱），而是把轻量任务直接长在对话发生的地方。建任务入口因此到处都是：从邮件一键转、任意处按 c t、markdown 里敲 /task、高亮任意 - [ ] 勾选项、频道里 @Macro，或者走外部 MCP/API/SDK。

CRM 侧的逻辑一样：交易的真实讨论发生在聊天里而非 CRM 字段里，独立 CRM 的记录注定滞后。Macro 把 CRM 与聊天同置（colocate），@ 提及公司名即建双向链接，聊天发生即记录更新，不再需要有人负责回填。还有个细心的设计：每笔交易（deal）自动获得一个 pin 在记录上的频道，客户讨论天然有归属。

团队级记忆：代理的第一等公民待遇

Macro 的记忆机制建立在「所有业务数据本来就在同一个库里」这个前提上。它不是聊天记录摘要，而是每晚一个 cron 任务把频道对话、DM、收发邮件、任务的创建与完成合成一遍的团队记忆，再与旧记忆合并产出新版本。README 举的例子很具体：拍一张纸上功能清单的照片发给代理，它能建好工单并派给对应工程师，全程没有运行时工具调用。

三条配套设计：

• 记忆以明文 markdown 存储，随时可导出、可直接让 AI 改写；
• 对外经 MCP 暴露给任意代理，一行接入 Claude Code/Codex 等 MCP 客户端：claude mcp add --transport http macro https://mcp-server.macro.com/mcp；
• 模型可换（OpenAI、Google、Anthropic……），记忆跟着工作区走而不是锁死在某家厂商。

另一个信号是 MCP 工具面的完整度：README 宣称对 UI 能力接近 100% 覆盖、MCP 无速率限制，代理甚至能用统一搜索直接检索邮件附件里解析出的 PDF。代理在 Macro 里能做的事不设人为上限，这在 SaaS 产品里少见。

一次任务如何流过系统

把上面的机制串成一条线。假设一封客户支持邮件进来：

1. 你在邮件上按 task，生成一张工单，工单双向链接回邮件——「为什么做这个」永远可溯；
2. 工单派给编码代理，代理领到关联分支开始干活（README 的 agent handoff 演示正是这个场景）；
3. 代理提交 PR，PR 关联任务、嵌入频道，团队在讨论发生的地方看到进展；
4. 任务的创建与完成进入当晚的团队记忆合成——第二天任何代理被问「这个客户提了什么」，答案已经在记忆里。

「为什么做 → 任务 → 代理 → PR」整条链在一个系统内可审计，因为上下文没有散落到五六个工具里。

技术栈与工程形态

前端 SolidJS（浏览器、Tauri 桌面、移动端，iOS app 已上架 App Store），后端 Rust。仓库布局（README 自述，括号内为 2026-09-29 目录实况）：

• apps/：web（SolidJS 客户端）+ docs（docs.macro.com 站点）
• services/：42 个可部署服务/worker/Lambda（目录实况 48 个条目）
• crates/：167 个 Rust 库——领域逻辑、模型、DB 客户端（目录实况 218 个）
• packages/：共享 TypeScript——协同、lexical-core、loro-mirror、sdk 等（8 个）
• 另有 infra/（Pulumi）、docker/（本地 Compose 栈）、nix/（锁定版本的开发壳）、tooling/（脚本与代码生成）

语言构成按字节计 Rust 37 MB、TypeScript 29.6 MB，前后端体量相当。服务遵循六边形架构（hexagonal layout）：入站适配器、带端口的领域核心、出站适配器。无论按 README 的 167 还是目录实况的 218 来数 crate，这个规模都说明这不是玩具仓库，是一个真实产品的完整后端。

部署形态上主推托管版（macro.com/app，接 Gmail 或 Google Workspace 即用，官方入门指引称约 15 分钟完成初始配置），本地跑按 docs/RUNNING_LOCALLY.md 走 docker compose 栈。安全侧：SOC 2 Type II 认证与 ISO 27001 徽章，对模型供应商零数据保留（不用客户数据训练），设漏洞赏金计划。

适用边界

AGPLv3 + 全开源意味着自托管与二次开发在许可上没有障碍（想用其他许可构建商业产品，需联系官方 licensing 邮箱），但近 50 个服务的运维复杂度摆在那里——个人用户和两三人小团队托管它不划算，直接用托管版更现实。

它的最佳受众是 10-50 人规模、被工具碎片化拖累、且已经开始用 AI 代理干活的技术团队：双向图让「上下文搬家」消失，团队记忆让代理不需要每次从头了解业务。反过来，如果你的团队深度依赖某个单品的独有能力（比如 Jira 的高级报表），Macro 对每个 block 的取舍是「够用且互相连通」，不是「单项最强」。

想再深入，三条路径：docs.macro.com 的 FAQ 覆盖竞品对比、许可与自托管细节；key concepts 讲透 blocks、提及、属性与权限；代理编辑文档的协同机制有一篇技术博客专文。

一句收束：多数 All-in-One 产品死在「功能都齐了但数据不通」，Macro 押注的是反过来——先造一张连通一切的双向图，功能只是图上的视图。这个赌注成不成立，值得做协作工具的人盯着它的留存看一年。