公司**不可计算，就自己做操作系统

它想证明的不是再做一个 Slack，而是把公司做成一张可计算的图。
⚡️ 30 秒速读：macro-inc/macro 以 2,995 星、今日 +435 登上 GitHub Trending #4，连续 3 天在榜，排名从 08-13 的 #2 落到昨日 #7，再回到 #4。README 称 Macro 是一体化工作区，把邮件、消息、文档、任务、Agent、通话和 CRM 放进同一界面，对象 @linked，交叉引用存成双向图；用 SolidJS 和 Rust 写，纽约与多伦多设计，约 15 人团队自用两年。风险同样明确：团队记忆一节在「Macro has the best memory on wh」处被截断；最新 Release v2026.8.14.0 的说明在 fix(mobile): filter by assign 处被截断；许可证是 AGPL-3.0；Android 应用写明 coming soon；昨日单日 +1,180，今日回落到 +435，材料不能把名次回升归因于这次 Release。

项目概览

属性	值
仓库	macro-inc/macro
定位	一体化团队工作区：邮件、聊天、文档、任务、Agent、通话与 CRM；对象 @linked，带共享团队记忆
主要语言	Rust（54.7%）
其他语言	TypeScript（41.9%）、MDX（1.2%）、Swift（0.6%）、PLpgSQL（0.4%）、CSS（0.2%）
许可证	AGPL-3.0
总星标	2,995
今日新增	+435
Forks	303
最新版本	v2026.8.14.0（2026-08-14）
建库时间	2025-11-08
最近推送	2026-08-14
开放 issue	53
订阅者	44
Trending 排名	#4，连续 3 天在榜；昨日 #7，前日 #2

能确认的趋势事实有三天：08-13 以 #2、当日 +325、总星标 1,705 上榜；08-14 落到 #7，当日 +1,180，总星标 2,580；08-15 回到 #4，当日 +435，总星标 2,995，Forks 303。单日新增从 +1,180 回落到 +435，排名从峰值 #2 下滑后再回升，不能写成持续加速。v2026.8.14.0 发布于 2026-08-14T14:47:26Z，与昨日高增量同一天，但现有材料不足以把名次变动归因于这次 Release 或 README 中的某一项能力。

它是什么

Macro 是 macro-inc 发布的一体化团队工作区。README 第一句写成：它把 email + messages + docs + tasks + agents + CRM 统一进「a single fast interface with shared team-level memory」。GitHub 描述补上 calls，并写「@-linked together with shared AI memory」。主页为 macro.com，应用入口为 macro.com/app，文档在 docs.macro.com。

「Why Macro」把动机写得很具体：作者想要「a single operating system for our startup」，用过 Slack、Linear、Notion、HubSpot 和 Superhuman，但「they don't work together as one system」。上一间公司扩到约 20 人时，「every team got their own tools and the company was held together by MCP and Zapier. The company was not computable. It was chaotic.」Macro 被写成「a complete redesign of work software from the ground up as a single system」。设计在纽约和多伦多，约 15 人团队自用两年；README 写 Built in SolidJS and Rust。目标用户是「any small company or team at a larger company」把 Macro 当操作系统。

产品被拆成可组合的 blocks。每个表面为自己的工作单独设计，而不是从通用 block 拼出来，但共用同一套后端；文档与任务、频道消息与邮件之间的交叉引用「natively stored as a bidirectional graph」。功能表列出十块：Email（多账户统一收件箱，写明 Gmail）、Messages、Tasks（Linear-inspired）、Docs（markdown-native，CRDT，@mentions）、Canvas、Agents（团队级记忆，可代为行动）、Calls（录音、转写并写入团队记忆）、File storage、Pull requests、CRM。仓库 topics 含 slack-alternative、notion、linear、mcp、crm，但这些是标签，不能当成已完成的对等替换证明。

技术要点

双向图，而不是工具间复制粘贴 ：README 反复写 everything is @linked。邮件可一键生成关联任务，文档里可 @mention 一封 .eml，任务与创建它的消息/邮件双向相连；从「why are we doing this」到 task、agent、pull request 被写成同一条可审计链。
SolidJS + Rust，语言构成可核对：README 写 Built in SolidJS and Rust。deep-pick 的语言构成是 Rust 54.7%、TypeScript 41.9%、MDX 1.2%、Swift 0.6%、PLpgSQL 0.4%、CSS 0.2%。没有单独的 SolidJS 行；Swift 与后文 iOS 应用一致，但不能从 0.6% 推出客户端完成度。
邮件：Superhuman 键盘流 + 统一收件箱 ：Macro Mail 写明受 Superhuman 键盘优先界面启发。多账户处理 Google 账户；统一列表里同时出现 emails、messages、@mentions 和待办任务，用 j k e 导航。内置窗口管理可开 3+ 分栏。AI/MCP 暴露统一搜索，让 agent 直接搜从邮件解析出的附件 PDF，而不是先拉线程再找附件；也可在 AI 聊天里起草、编辑、发送邮件。cmd+k 跳到联系人，@acme.com 看团队与该公司的全部邮件和文件。功能表这一格只写了 Gmail。
聊天：比 Slack 更收束，agent 当一等公民：前几条回复内联，其余收进线程；线程可单独授权，靠复制链接跨频道分享。作者把两条原则写死：消息应是任务、邮件、文档的中心，agent 和人类用户一样是一等公民；技术讨论要可读，不能变成语境丢失的噪声战。
任务：轻量 issue，焊在频道和 DM 上 ：作者同意 Linear「issue tracking is dead」的判断，并认为传统 tracker 过时，是因为与真实对话系统分离。创建路径写得很全：从邮件、任意位置 c t、文档 /task、把 - [ ] 标成 Task、频道/DM 里 @Macro、agent 聊天，以及 external MCP、API 或 SDK。
文档：CRDT + Cloudflare Durable Objects ：原生 markdown，支持批量导入导出，并点名 file over app。实时协作用 CRDT 和 Cloudflare durable objects，编辑「come in ~instantly instead of ka-chunking like Google Docs」。有历史、fork 和离线和解。版本控制「still in v1」，「there's a lot to do to get it closer to git, or we may eventually add git compatibility」。agent 可作为 CRDT 对等方编辑开关着的文档；示例是每天跑一条 Automation，扫频道更新办公室 Pool Games 文档，冲突交给 CRDT。技术说明指向 Wolf 的博文。
CRM：和聊天、邮件放在一起：作者承认「haven't innovated on the core idea of CRM」，差异是把记录与频道/邮件同居。@mention 公司或联系人会建立双向链接；每个 deal 自动有一条钉在记录上的频道。功能包括 Kanban、可定制阶段、列表/保存/可分享视图。对照点名 Attio、HubSpot、Salesforce，以及 Airtable/Notion 上的自制 CRM。
团队记忆：每日 cron，一节被截断：README 写团队上下文在单一数据库里，记忆由 cron 每天更新，来源包括团队对话、DM、收发邮件、创建和完成的任务；「synthesized together in one pass, rather than severally」，再与上一版记忆合并。摘录在「Macro has the best memory on wh」处切断，不能补写后半句，也不能把「best memory」当成完整结论。
最新 Release ：v2026.8.14.0 于 2026-08-14T14:47:26Z 发布，非 prerelease。能看清的变更包括：typed notification metadata、GraphQL notification 订阅、user mention 显示名、DOCX 大小写扩展名、search/queue lambda 告警、日历拖拽改时间、只申请 Macro 用到的 Google Calendar scope、Outlook 账户关联、升级已连接收件箱时只追加日历权限、confirmation dialog、把 rig fork 迁到 upstream rig-core/rig-agent 0.41、多日事件渲染、mark as read、iPad 修复。说明在 fix(mobile): filter by assign 处被截断，不能补写未给出的其余变更。

功能表没有单独列出 Calendar 这一块，但 Release 里出现了日历拖拽、Google Calendar scope 和 Outlook 关联。这只能说明仓库在改日历和邮箱连接，不能把日历写成与 Email/Tasks 同级的、已在 README 功能表里定义完整的产品块。

为什么现在火

热度可以量化，原因不能。三天轨迹是：08-13 #2、+325、总星 1,705；08-14 #7、+1,180、总星 2,580；08-15 #4、+435、总星 2,995。仓库还有 303 个 Forks、44 个订阅者、53 个开放 issue。能确认的是它连续 3 天在榜，且昨日出现过 +1,180 的单日高峰；不能确认增量来自哪个渠道、哪类用户，或是否由 v2026.8.14.0 驱动。

README 呈现的产品冲突很鲜明：一边是 Slack、Linear、Notion、HubSpot、Superhuman 各自好用，另一边是约 20 人规模时公司要靠 MCP 和 Zapier 粘合，「The company was not computable。」Macro 给出的回答是一张双向图、共享团队记忆，以及把 agent 写成和人类一样的一等公民。这个叙事与三日连登同时出现，但现有材料不足以证明两者存在因果关系。

冷静思考

团队记忆是核心卖点，但摘录在「Macro has the best memory on wh」处切断。能核对的只有每日 cron、来源列表和「one pass」合成；不能复述后半句，也不能把「best」当成已完成的评测结论。
最新 Release 说明同样被截断。能列出通知、日历、Outlook 关联和 rig 0.41 等条目，不能判断 v2026.8.14.0 相对前一版本改完了哪些模块，也不能把截断处的 fix(mobile): filter by assign 补全。
许可证是 AGPL-3.0。README 同时给出 Sign up、Book demo 和 Contribute，说明这是带商业站点的开源仓库。摘录没有自托管步骤、AGPL 对二次分发的约束说明，或 SaaS 与源码的关系，不能写成「可随意商用」或「已经提供一键私有化」。
GitHub 仓库建于 2025-11-08，README 写约 15 人自用两年。这两条都只按原文记录；材料没有解释公开仓库和内部使用的时间差，不能把建库日写成产品诞生日，也不能把「两年」外推成 2,995 星的积累周期。
功能表写 Email 时只点名 Gmail，Release 才出现 Outlook 账户关联。不能把邮箱支持写成「已覆盖主流提供商」，也不能从一条 feat 推出 Outlook 与 Gmail 同级。
文档版本控制仍是 v1，作者自己写离 git 还很远，甚至只是「may eventually add git compatibility」。离线和解被提到了，但没有冲突率、延迟或和 Google Docs 的对照数字。
作者对 CRM 的自我评价是核心概念没有创新。Kanban、阶段、视图是常规能力；「每个 deal 自动有一条频道」是结构选择，不是摘录里的效果数据。
「issue tracking is dead」是 Linear 报告加上作者经验，不是 deep-pick 里的使用率或完成率统计。任务创建入口很多，不等于这些入口都被验证过。
Android 应用写明 coming soon。iOS 有 App Store 链接，Release 有 iPad 修复，但没有 iOS 功能清单、触控工作流或与桌面的差距。
53 个开放 issue、44 个订阅者只是计数。这个数字不能直接解释为 53 个缺陷，也不能判断严重程度。昨日 +1,180、今日 +435 说明热度在回落，材料没有解释回落原因。

这套产品最有辨识度的判断不是再做一个聊天工具，而是把邮件、任务和 CRM 焊进同一张图，让公司重新变得可计算。

适合谁

小公司，或大公司里的一支团队，想把 Macro 当「operating system」，并接受邮件、聊天、文档、任务、CRM 放在同一权限体系里
已经同时使用 Slack、Linear、Notion、HubSpot、Superhuman，并认同「靠 MCP 和 Zapier 粘合后公司不可计算」这个诊断的人
需要对象之间双向 @link：从客户邮件建任务、在文档里引用邮件、在消息里点开公司记录
想让 agent 以 CRDT 对等方改文档、或从统一收件箱/附件 PDF 检索的团队；能接受走 MCP 或内部 agent
可以先用 Web 或 iOS（App Store id 6743133649），并接受 AGPL-3.0 与商业站点并存

如果你需要完整的团队记忆评测、Android 客户端、与 git 对等的文档版本、Gmail 以外已验证的邮箱矩阵，或从现有五件套迁出的步骤和数字，当前 deep-pick 材料还不足以支持这些结论。

未来展望

从 README 已经写出的方向看，项目把「单一操作系统」收成一张双向图：blocks 共用后端，交叉引用原生落图，文档用 CRDT 让人和 agent 当对等编辑，记忆按日从对话、邮件和任务合成。作者点名的后续只有两处：文档版本「get it closer to git, or we may eventually add git compatibility」，以及「Android app coming soon」。当前材料没有承诺记忆章节补全、Outlook 与 Gmail 对齐，或把日历升格成功能表里的正式块。

如果你们也被 Slack、Linear、Notion、HubSpot 和 Superhuman 拆成五套系统，你会接受 AGPL-3.0、iOS/Web 先行、文档版本还是 v1 的 Macro，把对象焊进一张双向图，还是继续用 MCP 和 Zapier 把现有工具粘在一起？

📊 数据来源：GitHub Trending · 2026-08-15

本文是对今日 GitHub Trending #4 项目的深度解读。完整榜单见当日日报。

每天追踪 GitHub Trending，写日报和深度解读。更多内容可关注公众号「AI Agent 赛道技术拆解」。