Macro 的 properties 机制：给邮件、任务、文档挂上同一套结构化字段
评估 Macro 的时候，很容易卡在一个具体问题上：一个工作区里同时塞着邮件、任务、文档、CRM 记录，这些东西各自的”字段”到底怎么管？按常规工具的分法，任务管理器有自己的一套自定义字段，CRM 有另一套，文档系统可能干脆没有，三套字段互不认识，想跨着筛一次就得导出来手工拼。
Macro 官方文档给的答案是 properties。这篇把 concepts/properties 和 product/tagging 两篇官方文档里写明的机制过一遍：支持哪几种数据类型、system 与 custom 怎么分、pin 是干什么的、各个 block 自带哪些系统字段，以及标签为什么在 Macro 里也被算作一个 property。
先说清楚边界：我们没有安装、没有运行过 Macro，下面全部是官方文档写明的机制、字段名和步骤，不含任何实测数据和使用感受。文档没写的部分，本文会直接标出来”官方文档未说明”，而不是替它补。
properties 挂在”实体”上，不是挂在某个应用上
文档的表述是：Macro 用 properties 给任意 entity（邮件、任务、文档、CRM 记录等）附加结构化数据。这套 properties 系统跨 blocks 统一，因此你可以用同一组字段去组织不同的内容类型，也可以给不同内容类型建各自的字段。
文档还专门补了一句解释为什么这样设计：任务和 CRM 显然需要的属性很不一样，但概念是相同的、UI 是共用的，所以团队之间可以有效协作。
这里的关键词是 entity 和 block。Macro 把邮件、任务、文档这些东西统称为 block 类型，它们共用一套底层数据结构，properties 正是架在这套结构之上的字段层——关于 block 这一层的说法，可以看数据模型 blocks 是怎么回事。理解了这一点，后面”为什么一个标签能横跨邮件和任务”就不需要额外解释了：它们本来就在同一套字段体系里。
八种数据类型，文档列的是一个封闭清单
文档写得很明确：每一个支持 properties 的 entity，支持的数据类型都是同一套。
| 类型 | 官方给的说明与例子 |
|---|---|
STRING（文本） | 电话、职位、部门、备注 |
NUMBER | 营收、员工数、ARR |
BOOLEAN | 开关 |
DATE | 最后联系时间、合同/续约日期 |
SELECT_STRING | 单选/多选，选项是字符串，选项可自定义颜色与图标 |
SELECT_NUMBER | 单选/多选，选项是数值 |
ENTITY | 指向另一个 entity 的引用（User、Company、Contact、Document、Project、Channel、Chat、Task、Thread） |
LINK | URL，例如网站、LinkedIn |
ENTITY 类型值得单独拎出来看。它让一个字段的值不是一段文本，而是真正指向工作区里的另一个对象，可引用的范围是文档明确列出的九类。也就是说，“这家公司的对接人”这种字段不必存一个人名字符串，而是可以直接挂上 Contact 实体本身。
需要克制的地方也在这里：文档只列了这八种类型和这九类可引用实体，没有写能不能自定义新的数据类型，也没有提公式字段、汇总（rollup）这类衍生能力。没写的就当作没有，别按其他工具的经验往上套。
system、custom 与 metadata 标记
一个 property 要么是 system（内置、不可移除，例如任务的 Status），要么是 custom（你自己加的）。这条区分决定了哪些字段能删、哪些不能。
另外还有一个正交的标记：properties 可以被标为 metadata，作用是把它挡在主视图之外。也就是说”是否内置”和”是否露脸”是两件独立的事，一个自建字段完全可以标成 metadata 静静待着。
文档提到编辑属性有三种编辑器形态：inline（在列表或 pill 里点开就改）、popover（聚焦的对话框）、modal（跨多个字段的批量编辑）。三者分别对应”随手改一个值""专心改一个字段""一次改一整组”这三种场景。
pin 决定哪些字段露在外面
文档写的规则是：你可以把属性 pin 起来，让它显示在右侧那张卡片里，或者显示在统一列表中；如果某个属性更像是不需要看的隐藏元数据，那就让它保持隐藏，否则就 pin 上。
每种 block 类型有自己的默认 pin 集合。文档给的例子是任务：开箱即 pin 的是 Status、Priority、Assignees 三个。加更多属性的入口，文档写的是 Add property。
把 pin 和 metadata 放在一起看，其实是同一条轴的两端：字段本身一直在库里，区别只是它要不要占用视觉预算。这对多人协作有实际影响——如果每个人都把自己关心的字段 pin 上去，卡片会迅速变成一面墙，所以更稳的做法是团队先约定”哪几个字段是所有人都要扫一眼的”，其余全部走 metadata。
各 block 自带的系统字段
有些 block 自带一组系统属性，文档逐一列了出来：
| Block | 官方列出的自带字段 |
|---|---|
| Tasks | Status、Priority、Assignees、Due Date、Parent Task / Subtasks、Depends On、Effort、Story Points、Relevant Documents |
| Documents | Owner、Folder、创建与更新时间戳，以及可指派的字段如关联的 Task 和 urgency |
| CRM companies（Customers） | Stage（Lead、Qualified、Demo、Trial、Negotiation、Customer、Churned）、Owner（团队里的某个人）、Revenue，外加一个 Last Interaction 时间戳，它由同步过来的工作区邮件自动更新 |
| CRM contacts & companies | Email、Name、Company、交互时间戳、Domains、Email Sync 等 |
任务这一行的字段密度不低，Depends On、Effort、Story Points 这些是直接内建的而不是靠自定义字段拼出来的，任务这一块的整体设计可以看任务模块的组织方式。
CRM 那个 Last Interaction 值得留意：它是文档里少数明说”自动更新”的字段，来源是同步的工作区邮件。换句话说这条时间戳的准确性取决于邮箱有没有接好，而不是取决于有没有人手动维护。
标签也是一个 property
tagging 文档的第一句话就把关系挑明了：一个 tag 就是一个 property；因为 properties 在整个工作区共享，所以单一的 tag 命名空间横跨所有 block 类型。给一封邮件打 marketing、给一个任务打 marketing，那就是同一个 marketing——一种颜色、一个筛选条件、点一下看到全部。
文档同时划了一条使用边界：tag 是用来按项目、团队、领域组织工作的，比如 marketing、hiring、q3-launch，它不是用来跟踪状态的。status、priority、assignees 这些 property 描述的是单个条目，而 tag 这个 property 的作用是把相关条目跨工作区串起来。
可以打标签的对象，文档列的是：文档（含 PDF、其它文件和 snippets）、任务、邮件（整个 thread）、AI 会话、通话（录音或转写）。
创建与应用的方式有两条：在文档里输入 # 打开标签菜单，选已有的或直接新建，标签会以彩色 pill 的形式内联渲染；其它地方则用 properties 窗口里的标签面板。一个条目可以带任意多个标签，同一封邮件同时挂在 marketing 和 q3-launch 下面是允许的。文档另外提了一个操作细节：按住 Shift 点击可以批量选中或取消选中多个标签。
作用域分两种，创建时就要选：
- Personal——只有你自己看得见，任何人都能建。
- Team——与团队里所有人共享，建团队标签的前提是你在一个 team 里。
关于改名和删除，文档的说法是：重命名或改颜色会保留标签的身份，变更会流向所有已经带着它的条目；而删除是破坏性的，标签会一次性从所有条目上被移除，且不可撤销。这条建议直接当红线处理。
颜色是一个固定调色板，文档列了十二种：Red、Tomato、Orange、Amber、Yellow、Green、Teal、Blue、Indigo、Purple、Pink、Gray。
筛选有两个层级：在任意一个 block 里走 Filter → Tags，只显示带该标签的条目；要一次性跨整个工作区筛，就用搜索的筛选菜单里那个同名的 Tags chip。选中两个及以上标签时会出现匹配模式开关——Any 表示带任意一个（默认），All 表示同时带上全部选中的标签，例如既是 marketing 又是 q3-launch 的那些。
有一条注记很容易被忽略，文档单独标了出来：Macro 的 tag 不是邮件 label。Gmail 的 label（Inbox、Starred、Important 以及你自己建的）照旧同步，并且驱动归档、加星这类收件箱动作；Macro tag 是叠在上层的另一套跨工作区标记，一个邮件 thread 可以同时带着两者。迁移的时候如果把这两层当成一回事，筛选结果会对不上。
标签的集中管理入口，文档写的是 Settings → Tags，那里按 Personal 和 Team 两组列出全部标签，带编辑、删除动作和一个 New tag 按钮。标签和文件夹这两套归类方式的分工，另见文件夹与标签的两套归类。
Agent 通过 MCP 读写属性
properties 文档最后一节写的是 agent 侧：agent 通过 MCP 的实体类工具读写 properties——GetEntityProperties 用于读，SetEntityProperty 用于更新（状态、负责人、日期、自定义字段），ListEntities 用于浏览。这几个工具的用法参见MCP 实体类工具。
tagging 文档补了一个具体用法：对已连接 MCP 服务的 AI 客户端（文档点名的是 Claude Code 和 Cursor）说”给这个 thread 打上 marketing 标签”，或者”建一个 q3-launch 标签并加到这些任务上”，它会处理掉，不用离开编辑器。
把两篇文档并起来看，有一个合理的读法：既然 tag 本身就是一个 property，那 agent 打标签走的应该也是同一组实体工具，而不是另一套标签专用接口——官方文档没有单独列出 tag 专用工具，这一点值得在实际接入时验证一下，别当成已经确认的结论。
设计字段之前先回答三个问题
文档里的规则拆开看是散的，合起来其实能收成三个判断：
- 这个字段是在描述单个条目，还是在把多个条目串起来？ 前者用普通 property，后者用 tag。这条线是官方文档自己划的，不是我们的发挥。
- 需不需要天天看见？ 需要就 pin 到卡片和列表里，不需要就标成 metadata 让它退到后台。默认 pin 集合每种 block 自带，任务是 Status、Priority、Assignees。
- 它是不是在引用另一个东西？ 是的话就用
ENTITY类型直接挂对象，而不是拿STRING存一个名字。可引用的范围就是文档列的那九类，超出范围的关系只能退回文本。
哪些地方文档没说清
- 规模与约束：单个 entity 能挂多少属性、自定义属性有没有数量上限、能不能扩展新的数据类型，官方文档未说明。
- 权限粒度：谁有权创建或删除 custom property、能不能限制某些人改某些字段，properties 文档没有涉及。标签这边只写了 Personal 与 Team 两种作用域，以及建团队标签需要在 team 里，更细的授权规则同样没写。
- 批量搬迁：字段的批量导入导出、跨工作区迁移怎么做，这两篇文档没有覆盖。
- 删除不可逆：删除标签会一次性从所有条目移除且不可撤销，这是文档明说的，动手之前先确认没有人在用。
- 别拿 tag 当状态机：如果你的实际需求是”把邮件按阶段往前推”，文档的立场是这件事交给 status 类 property 而不是 tag，硬用标签模拟阶段会跟内置的 Stage、Status 字段打架。
再强调一次口径：以上全部来自 Macro 官方文档 concepts/properties 与 product/tagging 两篇，我们没有安装运行过它，具体版本的实际行为请以官方文档和你自己的验证为准。
延伸阅读
- 从头读起：Macro 是什么：邮件、任务、文档、CRM 共用一个双向数据库的开源工作区
- 本专题共 40 篇，完整分组目录见专题页
- Macro 统一记忆记的是什么：个人记忆与团队记忆的边界，以及唯一写明的退出开关
- Macro 里的 Agent 到底能替你做哪些事，权限边界又卡在哪一层
本文依据 Macro 官方仓库（github.com/macro-inc/macro，AGPL-3.0 协议）的 apps/docs/ 产品文档、
MCP 工具参考与自托管说明整理，核对日 2026-08-17。
我们没有注册或运行过 Macro，因此不涉及界面外观与操作手感；
官方标注为计划中的能力文中已如实标明，不代表当前可用。
价格与额度以官网 macro.com 最新页面为准；许可证相关问题请咨询专业人士并以官方许可证原文为准。