Macro 的权限模型：频道成员身份决定共享范围，@提及在哪会授权、在哪只是链接
多数协作工具的权限是”逐文件”的：你建一个文档，然后一个一个把人加进去；有人问”这个我打不开”，你回去改一次共享设置。工具一多更麻烦——消息在一个系统里，文档在另一个系统里，两边的权限各管各的，于是就有了那句经典的”能帮我开一下权限吗”。
Macro 换了个做法：权限不挂在文件上，挂在频道成员身份上。官方文档把它叫做 channel-based sharing（频道式共享）。在一个频道里 @提及某个东西，它就被共享给了这个频道的全部成员；有人被加进频道，他就获得了频道里已共享的一切；有人被移出频道，他就失去这些访问权。
这套模型的好处很直接，坑也很直接：共享变成了发消息的副作用。你在频道里随手 @了一份文档，就等于给了这个频道所有人读它的权限——包括三个月后才加进来的新同事。所以搞清楚”哪种 @提及会授权、哪种不会”，比记住某个设置项藏在哪里要重要得多。
权限从哪来：一条主线加一个例外
官方文档给的主线只有一条：频道成员身份就是访问边界。安全文档里写得更硬——它把这个模型直接称为安全边界（security boundary），而不是一个便利功能。在频道里提及一个 block，它就对该频道每个成员可见；把某人移出频道，在那里共享过的东西随之收回。
主线之外有一个例外：Teams（团队）。团队对任务、邮件、通话这几类内容有专门的自动共享规则，目的是让团队成员不必把每一条任务都手动丢进某个频道，也能看到别人在做什么。换句话说，你的工作区里同时跑着两套授权来源——频道给的，和团队默认给的。排查”为什么他能看到这个”时，两边都得看一眼。
关于团队怎么建、成员怎么邀请，可以看 团队与成员管理；频道本身的组织方式在 频道与私信怎么组织 里。
@提及在哪里会授权、在哪里只是链接
这是整套模型里最容易踩的地方。同一个 @ 动作，放在不同容器里效果完全不同。按官方文档的说法整理如下：
| 提及发生的位置 | 会不会共享 | 会不会产生收件箱通知 |
|---|---|---|
| 频道消息里提及文档 / block | 会，共享给全频道成员 | @user 通知一人，@here 通知全频道 |
| 文档正文里提及某人 | 不会 | 不会 |
| 文档评论里提及某人 | 不会（评论提及不改共享） | 会，进对方收件箱 |
| 任务正文里提及某人 | 不会 | 不会 |
| 任务评论里提及某人 | 不会 | 会 |
| 把任务指派给某人 | —— | 会 |
| 邮件正文里提及某人 | —— | 该人被加进 cc |
| 邮件正文里提及文档 | 会：插入链接并更新该文档权限，使收件人能打开 | —— |
| 提及频道、会话或某条消息 | 不会授予任何权限 | —— |
| 提及联系人 / 公司记录 | 不会，这类的共享由 Teams 决定 | —— |
| 从日期选择器插入日期 | 不会 | 不会 |
文档里把通用规则总结成两句：用户必须先被共享了某个文件，才可能收到关于它的收件箱通知；在 markdown 正文（文档、任务）里 @提及不会产生收件箱通知，而在 thread container（评论、消息）里 @提及会。
正文提及为什么故意不通知？官方给的理由是自己长期使用后的取舍：你想在文档里 @某人的时候，按定义你还没写完这份文档，此时并不希望对方立刻收到提醒；而”到底什么时候该提醒”又说不清楚，于是干脆决定文档语境下的提及既不通知也不共享。想要对方知道，就手动把文档共享给他。
邮件是另一个特例。频道里那种自动共享不会发生在邮件上，官方文档给的原因是：邮件链可以被转发、可以中途加人，谁需要访问权事先不可知、事后也不可追溯。所以在邮件里放的链接，得你自己确认收件人能打开；发出去之后，@mention 在别人的邮件客户端里只是一个普通超链接。@提及的机制细节可以看 @ 提及怎么把东西连起来。
还有一条容易被问到的：没法把单条消息分享给不在频道里的人。因为能否看到一条消息完全由频道成员身份决定，官方文档给的替代办法很朴素——发截图；要让人真正看到，就去频道里把他加成参与者，而不是在别处 @这个频道。
团队默认替你打开了哪些共享
加入团队会改掉几类 block 的默认共享，其余的仍然保持私有直到你主动共享。文档列出的自动共享是：
- 任务：默认进入团队记忆，团队任何成员都能看到指派给自己和别人的全部任务。
- 通话：默认录制、转写，并共享到团队记忆；任何人都可以把某一通退出共享，退出后这通仍在个人记忆里，但不进团队记忆。转写和 AI 摘要是自动生成的。
- 邮件：当某家公司的 Email Sync 打开时，与被跟踪客户往来的邮件通过 CRM 共享。
- 片段（Snippets）：默认是个人的，直到你打开”Share with team”；共享后它会出现在每个队友的片段菜单里，并且队友可以编辑它。
角色只有三个，权限逐级递增：
| 角色 | 相比上一级多了什么 |
|---|---|
| Member | 团队共享的一切：团队任务、共享通话、可见的 CRM 记录 |
| Admin | 管理 CRM 可见性：按公司开关 Email Sync、隐藏或取消隐藏记录 |
| Owner | 以上全部，加上邀请与移除成员 |
Owner 可以移除任何成员，但不能移除自己。成员被移除时会自动失去团队共享内容；而把他从频道里移除，才会收回在那些频道里共享过的东西——这两步是分开的，只做前一步不等于清干净了。
三个最容易漏的口子
公开链接。 文档支持对没有 Macro 账号的人共享：用邮箱地址分享，或者启用 Public Link。官方文档在这里给了明确提醒：任何拿到公开链接的人都能读这份文档，敏感内容要回去检查一下共享设置。这是唯一一处完全绕开频道成员身份的授权方式，也是最该定期复查的一处。
按域名自动入团。 Admin 和 Owner 可以在 Settings → Team 里打开 Auto-join on domain。打开之后，凡是用团队 owner 域名邮箱（例如 @acme.com）注册 Macro 的人会自动加入团队——也就自动获得团队默认共享的那批内容。随时可以关掉回到仅邀请制，已有成员不受影响。这个开关方便，但它意味着”新成员进来”这件事不再需要人工动作。
通话默认共享。 队友的每一通通话都会出现在通话列表里，无论你有没有参加。默认行为是把录音和转写共享到团队记忆，需要单独退出才不进团队。对于涉及外部客户或敏感话题的通话，这是一个需要在会议开始时就处理的决定，而不是事后补救的。
另外，频道本身对外是开放的：任何人都可以用邮箱被加进频道，无论他有没有 Macro 账号，非 Macro 用户会收到相应的邮件通知。参与者随时可以增删。
Agent 能看到的，不会超过你能看到的
这套权限模型对 AI 的部分是这么划边界的：Agent 继承你的权限。官方文档写得很直白——agent 只能触达你能触达的内容，没共享给你的东西不会进入 agent 的上下文。如果你试图把一份自己无权访问的文档丢给 agent，agent 同样访问不到，并且会明确告诉你。
顺带一条实用建议来自官方文档：你其实不必总是把实体 @给 agent，因为它自己有搜索和列举工具，能在工作区里找。建议 @的场景是你已经知道该看哪一份——省掉一轮搜索，也保证上下文是对的。
连接器与 MCP 客户端是按工作区选择性开启的（opt-in）。要注意的是，你自己连上去的第三方 MCP 服务器，你发过去的数据由那家提供方的条款约束，不适用 Macro 这边的说明。更完整的安全口径见 安全与数据处理的官方说明。
这套模型解决不了什么
第一，它不是细粒度的 ACL。你没有”某人只读、某人可编辑某一段”这类逐文件的分级控制，权限的单位是”是否在这个频道里”。需要精细分级的场景，得靠拆频道来近似，而不是靠调权限。
第二，企业身份体系的对接目前不完整。官方文档明确标注 SAML 与 SCIM 尚未支持，登录方式是 Google、iOS 上的 Apple，或者发到邮箱的一次性链接；实际的策略执行点因此落在 Google Workspace 上——双因素、会话时长、设备限制这些由 Google 侧的策略生效。撤销 Macro 在 Google 账号中的授权，或在连接设置里断开，会停止邮件同步。
第三，责任划分要看清楚。官方的共享责任模型里，配置团队访问与角色、决定把哪些数据共享进哪些频道、哪些文档开了公开链接、连接了哪些 agent 与 MCP 客户端、登录用的 Google 账号安全设置，这些全部算在使用方这一侧。平台负责应用层、平台层和云基础设施的安全控制与监控。
第四，删除不等于消失。删除一个 block 会先进回收站以便恢复；删除账号是永久的，需要经过确认步骤；组织级的保留窗口（自动删除多少天未访问的文档与聊天）不是自助配置项，需要联系官方开通。断开 Gmail 账号只会停止后续同步，已经同步过来的邮件不会被删掉。
真要在团队里用起来，我的建议是先做一件小事：把现有频道的参与者列表逐个过一遍，再检查一遍哪些文档开着公开链接。这套模型把”共享”做得足够顺手，代价就是它容易在你没注意的时候悄悄扩大范围——定期回看参与者名单，比事后追查谁看过什么要省事得多。
延伸阅读
- 从头读起：Macro 是什么：邮件、任务、文档、CRM 共用一个双向数据库的开源工作区
- 本专题共 40 篇，完整分组目录见专题页
- Macro 团队与成员管理：三种拉人方式、Member/Admin/Owner 三档角色与移除成员时收回什么
- Macro 计费规则怎么算：免费版的四条天花板与 Premium 每人 40 美元的边界
本文依据 Macro 官方仓库（github.com/macro-inc/macro，AGPL-3.0 协议）的 apps/docs/ 产品文档、
MCP 工具参考与自托管说明整理，核对日 2026-08-17。
我们没有注册或运行过 Macro，因此不涉及界面外观与操作手感；
官方标注为计划中的能力文中已如实标明，不代表当前可用。
价格与额度以官网 macro.com 最新页面为准；许可证相关问题请咨询专业人士并以官方许可证原文为准。