Macro：用 Rust 重写整个公司工作区，还让 Agent 当 CRDT 协作的一等公民
Macro：用 Rust 重写整个公司工作区，还让 Agent 当 CRDT 协作的一等公民
把 Slack、Linear、Notion、HubSpot、Superhuman 全塞进一个 app，还全开源。
先说一个真实痛点。Macro 的创始团队在 README 里写得很直白：他们上一个创业公司扩张到约 20 人时，工具链崩了。每个团队各用各的--Slack 聊天、Linear 管任务、Notion 写文档、HubSpot 管 CRM、Superhuman 收邮件，公司靠 MCP 和 Zapier 粘在一起。原文那句话值得直接引用："The company was not computable. It was chaotic."（公司不可计算，一片混乱。）
Macro 是他们对工作软件的推倒重设计：Email、聊天、文档、任务、AI Agent、通话、CRM 统一进一个快速界面，全部通过双向 @链接打通，外加团队级共享 AI 记忆。NYC 和 Toronto 的团队开发，约 15 人内部用了两年才开源。当前 3,962 星、AGPLv3（明确写了 not open core）、Rust 后端 + SolidJS 前端。
这个项目最让我感兴趣的其实不是"又一个 all-in-one"，而是它对 AI Agent 的处理方式--这是第一个把 Agent 当成协作系统 peer（对等者）的工作区。
本文提纲
- 一体化的代价与解法：模块化 blocks
- 双向 @链接：把工作区变成一张图
- 团队级 AI 记忆：每晚刷新一次，纯 markdown 存储
- Agent 是 CRDT 里的 peer，不是外挂
- 42 个服务、167 个 Rust crate 的重型工程
- 本地跑起来：Nix + just
- 坦诚的局限与开源态度
一体化的代价与解法：模块化 blocks
"一体化工作区"不是新想法，为什么大多数失败了？因为一体化通常意味着每个模块都做得平庸。Macro 的策略是模块化 blocks，每个 block 对标一个最佳产品并试图超越它：
| Block | 对标 | 差异点 |
|---|---|---|
| Superhuman | 键盘优先、多 Google 账号统一收件箱、cmd+k 直达联系人或公司 |
|
| Messages | Slack | 前几条回复内联、其余折叠进 thread，更聚焦 |
| Tasks | Linear | 更激进--"issue tracking never really worked"，任务与频道紧耦合 |
| Docs | Notion | Markdown 原生 + CRDT 实时协作、历史版本、fork、离线编辑 |
| Canvas | - | 2D 白板，可嵌入 @链接 |
| Calls | - | 录音、转写、自动写入团队记忆 |
| CRM | HubSpot | 每个 deal 自动获得专属"频道"作为笔记 |
注意 CRM 这行。Macro 对 CRM 的核心判断是：CRM 不保持更新，是因为 deal 的真正对话发生在消息里而不是 CRM 里。所以它把 CRM 记录和聊天频道直接打通--deal 频道里的对话就是 CRM 的活数据，不需要任何人手动同步。README 对 CRM 部分甚至自嘲："We haven't innovated on the core idea of CRM... None of this should be that interesting."--重心根本不在 CRM 本身，在打通。
双向 @链接：把工作区变成一张图
Macro 的架构级设计有四条，第一条是最基础的：Bidirectional @linking（双向 @链接）。
在消息里 @一篇文档，双方互相知道。文档知道谁提到了它，消息知道它提到了什么。原生存储就是一张双向图。这个设计配合第二条 Channel-based permissions 发挥威力：在频道里 @的任何东西自动共享给频道成员，加入频道即获得权限，退出即失去--没有"申请权限"的流程。
第三条是 One inbox：邮件、频道消息、任务分配、@提及、Agent 回复全部进一个收件箱，分成 Signal 和 Noise 两类，j k e 键盘导航一切。
这三条合起来是个完整的答案：工具碎片化的本质是上下文碎片化，权限碎片化又是协作摩擦的来源。把三者一起解决，才配叫"一体化"。
团队级 AI 记忆：每晚刷新一次，纯 markdown 存储
Agent 记忆是 Macro 在 AI 叙事上最独特的点。
它的记忆模型是团队级的：Agent 记住整个团队（而非个人）在邮件、消息、任务、文档、通话中做的事。实现方式很克制--每晚一个 cron job，把所有来源单次综合（one pass）成一份记忆，而不是分别合成再拼接。存储格式是纯 markdown，随时可导出。
这个"file over app"的选择值得玩味。记忆不是锁在数据库里的 embedding，是一份人类可读、可编辑、可 git 管理的文档。你不满意 AI 的记忆？直接改文件。
记忆还能通过 MCP 提供给任何外部 Agent：
claude mcp add --transport http macro https://mcp-server.macro.com/mcp
一行命令，Claude Code 就能接入 Macro 的团队记忆和工具面。README 说 MCP 工具对 UI 能力的覆盖率"接近 100%"，且MCP 无速率限制--第三方 Agent 在 Macro 里能做的事，几乎和真人用户一样多。
Agent 是 CRDT 里的 peer，不是外挂
这是我认为整个项目技术上最有趣的决定。
Macro 的文档协作基于 CRDT（Cloudflare Durable Objects 之上）。Agent 编辑文档时，像 CRDT 协作系统里的"人"一样以 peer 身份参与--不是通过某个特殊的 API 通道，而是和真人用户走同一套协作协议。README 里有个自动化的例子很生动：
"我们有一个每天运行的 Macro Automation，更新办公室台球游戏的 markdown 文档。它扫描所有频道看有没有人赢了一局，然后更新文档。如果有人已经手动编辑过文档，它能感知到并放弃更新。冲突由 CRDT 协作系统原生处理。"
多个 Agent 同时编辑同一篇文档、和真人同时编辑、离线再合并--全部由 CRDT 的冲突解决机制原生处理。Agent swarm 作为协作者而不是工具调用，这个心智模型和其他产品把 Agent 当"外挂大脑"的做法完全不同。
另一个 README 里的用户场景：
"我把写在纸质笔记本上的功能点拍了张照片，让 agent 创建 tickets 并分配给合适的工程师--它没用到任何运行时工具就完美完成了。"
最新 main 分支的提交还在往这个方向推进："give ai tools to create and manage bots"（AI 可以创建和管理 bot）、"local Docker sandboxes"（Agent 本地 Docker 沙箱）。
42 个服务、167 个 Rust crate 的重型工程
代码规模值得单独一节。仓库约 17,030 个文件，结构如下：
macro/
├── apps/
│ ├── web/ SolidJS client - browser, Tauri desktop, mobile
│ └── docs/ docs.macro.com
├── services/ 42 deployable services, workers, and Lambda handlers
├── crates/ 167 Rust libraries - domain logic, models, db clients
├── packages/ shared TypeScript - collaboration, lexical-core, loro-mirror
├── infra/ Pulumi definitions
├── docker/ local Compose stack
├── nix/ pinned dev shell and build inputs
└── tooling/ repo scripts and code generators
42 个可部署服务里包括 mcp_service、agent_harness_service、email_service、transcription、lexical-service、coding-agent-worker、sync-service 等。服务采用六边形架构（hexagonal layout）：入站适配器、带 ports 的领域核心、出站适配器。本地栈在 Docker 里跑 Postgres、Redis、LocalStack、OpenSearch、Kafka、FusionAuth。
有个细节能看出这个代码库对 AI coding agent 的友好程度：每个文件树里有 .claude/、.cursor/、.zed/、.helix/、AGENTS.md、CLAUDE.md。这就是为 AI 协作深度优化的仓库的样子。
安全性方面有 SOC 2 Type II 认证和 ISO 27001，与模型提供商零数据保留、不用客户数据训练。
本地跑起来：Nix + just
自部署路径（来自 docs/RUNNING_LOCALLY.md）：
git clone https://github.com/macro-inc/macro.git
cd macro
nix develop # Nix 提供全部工具链：just、Cargo、Bun、sqlx
just run_local --no-doppler # 无 Doppler 权限的普通贡献者路径
just seed-scenario apply --file seed/scenarios/team-perms.json # 灌入演示数据
本地栈用确定性 stub 替代第三方集成密钥（Google/GitHub/Stripe/CloudFront），auth、文档、邮件、搜索等核心功能完整可用。登录验证码邮件落在本地 Mailpit（http://localhost:8025）。
Nix 是唯一的宿主依赖--有人会觉得重，但换来的是"所有人拿到完全相同的工具链"。托管版则直接注册连 Gmail，约 15 分钟完成初始设置，有 iOS App，Android 还没发布。
版本发布用日期式 calver（如 v2026.8.20.2），8 月 20 日一天发了 3 个版本，节奏极快。
坦诚的局限与开源态度
README 和 CONTRIBUTING 里的坦诚程度在同类项目里少见：
- 文档版本控制："still in v1"，要接近 git 还有很多要做，可能最终加 git 兼容
- 邮件仅支持 Gmail/Google 账号
- Android 未发布
- 本地开发强依赖 Nix
- 贡献政策："Unreviewed AI output submitted as-is wastes reviewer time and will be closed."（未经人工审阅的 AI 生成 PR 会被直接关闭）--和 Prime Agent 一样，这是 agent 时代开源治理的先行实验
AGPLv3 + not open core 的立场在商业化产品里不多见。商业授权走 licensing@macro.com，托管版和自部署版功能同源。对比那些核心功能闭源的"开源"项目，Macro 的选择意味着你可以真的把它 fork 走。
要不要切过去？我的判断：如果你的团队正被工具碎片化折磨（尤其是 CRM 和聊天割裂、Agent 没有团队记忆这两个痛点），值得试。邮件只支持 Gmail 这条要先确认。如果你重度依赖某个单品的深度功能（比如 Linear 的_cycle 管理、Notion 的 database view），迁移成本要算清楚--每个 block 对标最佳产品，但"对标"不等于"追平"。
参考文档与链接
- GitHub: macro-inc/macro - 3,962 星，AGPLv3，Rust + TypeScript，17,030 个文件
- Macro 官网 - 托管版注册入口
- 官方文档 - 含 Switch to Macro 迁移指南
- Agent Recipes - Agent 应用场景合集
- FAQ - 对比、许可、自部署问题
- RUNNING_LOCALLY.md - 本地部署完整指南
- Cloudflare Durable Objects - 文档 CRDT 协作的底层设施
- Loro - 仓库里 loro-mirror 包对应的 CRDT 库
你的公司现在用几个工具拼工作流？切到一体化工作区的最大顾虑是什么？评论区聊聊。觉得 Rust 重写工作区这事靠谱的，点个赞。
作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
浙公网安备 33010602011771号