Macro 的任务管理拆解：状态、属性字段，以及它和频道、邮件、文档怎么联动
大多数团队的任务系统都有同一个毛病：任务躺在一个专门的任务工具里，讨论躺在聊天工具里，需求文档躺在第三个地方。三边靠人工贴链接维持同步，链接过一周就烂掉——标题改了、状态变了，聊天记录里那条链接还是旧的。
Macro 对这件事的处理方式，是不把任务做成一个独立模块，而是把它做成工作区里的一种”实体”（entity），和邮件、文档、CRM 记录共用同一套属性系统。这样带来的直接结果是：任务可以被 @提及到任何地方，提及出来的是活的、会跟着任务当前状态走的引用，而不是一段死文本。
这篇按官方文档把这套机制拆开讲：状态模型有几档、任务自带哪些字段、自定义属性支持哪些数据类型、GitHub 和 MCP 各自介入到什么程度。我们没有安装运行过 Macro，所以只讲文档写明的机制和配置项，不谈使用体感。
只有三个维度：状态、优先级、负责人
Macro 官方文档对任务字段的态度很明确：因为任务本身已经嵌在工作区里，不需要额外的标签和分类体系，任务就是状态（Status）、优先级（Priority）、负责人（Assignees）三样。这是官方的说法，它背后的假设是——分类信息本来就藏在任务被 @提及的那个上下文里（哪个频道、哪封邮件、哪份文档），不需要再用标签重复标注一遍。
状态一共四档：
| 状态 | 文档定义 |
|---|---|
| Not Started | 任务还没有被人接手 |
| In Progress | 有人正在处理 |
| In Review | 工作已完成，等待评审 |
| Completed | 任务已完成 |
这四档的粒度值得留意：它把”做完”和”验收完”拆成了 In Review 和 Completed 两档。很多轻量任务工具只有待办/进行中/完成三档，结果”我提交了”和”这事真过了”混在同一格里。Macro 把评审单列一档，是为了后面和 GitHub 拉取请求对齐——PR 开出来到合并之间的那段时间，正好对应 In Review。
这里有一处文档自身的措辞不一致值得记下来：状态清单里第四档写的是 Completed，而 GitHub 集成那一节描述状态自动流转时，写的是任务会自动移动到 “In Progress”、“In Review” 或 “Done”。同一份文档里出现了 Completed 和 Done 两种叫法，指向的应该是同一档。官方文档没有解释这个差异，接入前建议以实际接口返回的枚举值为准。
新建任务的快捷键，文档给的是 c + t。除此之外，在频道里或者邮件上悬停时会出现任务按钮，可以直接从那条消息、那封邮件建任务——也就是说，任务的产生位置就在它被讨论的地方，不需要先切换到任务列表。
属性系统：任务只是它的一个使用者
真正让这套设计成立的，是 Macro 的属性（Properties）系统。文档把它描述为一套跨 block 统一的机制：邮件、任务、文档、CRM 记录都用同一套字段系统挂结构化数据。任务和 CRM 需要的字段显然差别很大，但概念一致、界面共享，所以团队里做销售的人和做研发的人在心智上是一套东西。
支持的数据类型是全实体通用的，也就是说凡是支持属性的实体，能用的类型都一样：
| 类型 | 用途（文档举例） |
|---|---|
| STRING | 文本，如电话、职位、部门、备注 |
| NUMBER | 数值，如营收、员工数、ARR |
| BOOLEAN | 开关 |
| DATE | 日期，如最近联系时间、合同/续约日期 |
| SELECT_STRING | 单选/多选，选项为字符串，选项可自定义颜色和图标 |
| SELECT_NUMBER | 单选/多选，选项为数值 |
| ENTITY | 指向另一个实体的引用，可指向 User、Company、Contact、Document、Project、Channel、Chat、Task、Thread |
| LINK | URL，如网站、LinkedIn |
其中 ENTITY 类型是这套系统里最关键的一个。它意味着一个字段的值可以是另一个对象本身，而不是一段描述那个对象的文字。可指向的目标里包含 Task、Document、Channel、Chat、Thread——所以”这个任务关联哪份文档""这条 CRM 记录对应哪个项目”这类关系，是用引用表达的，不是靠人手抄标题。属性和 blocks 数据模型的关系，可以对照 Macro 的数据模型与 blocks 设计 一起看。
属性分为系统属性（内置、不可删除，比如任务的 Status）和自定义属性（自己加的）。另外属性还可以被标记为 metadata，标了之后就不出现在主视图里。文档提到有三种编辑方式：inline（在列表或 pill 上点开就改）、popover（独立的聚焦对话框）、modal（跨多个字段批量编辑）。
还有一个”固定”（pin）的概念：被 pin 的属性会显示在属性卡片和统一列表中，没 pin 的就留作隐藏元数据。每种 block 类型有自己的默认值，任务默认 pin 的是 Status、Priority、Assignees 三个——这正是上一节说”只有三个维度”的实现方式：不是任务只有三个字段，而是它默认只把三个字段摆到台面上。
任务实际自带的字段比三个多
文档在”按 block 划分的内置字段”一节里，给出了任务的完整系统属性清单，比默认 pin 的三个多得多：
- Status（状态）
- Priority（优先级）
- Assignees（负责人）
- Due Date（截止日期）
- Parent Task / Subtasks（父任务 / 子任务）
- Depends On（依赖）
- Effort（工作量）
- Story Points（故事点）
- Relevant Documents（相关文档）
Parent Task / Subtasks 和 Depends On 这两组说明任务之间是有拓扑关系的：既能做层级拆分，也能表达”A 要等 B”。Effort 和 Story Points 并列出现，说明它同时照顾了工时估算和敏捷点数两套习惯。Relevant Documents 则是 ENTITY 类型的典型用法——直接挂文档实体。
作为对照，文档也列了别的 block 的内置字段：文档有 Owner、Folder、创建与更新时间戳，以及可指派的关联任务和紧急度；CRM 公司（Customers）有 Stage（Lead、Qualified、Demo、Trial、Negotiation、Customer、Churned 七档）、Owner、Revenue，外加一个会从已同步的工作区邮件自动更新的 Last Interaction 时间戳。这个自动更新的时间戳能说明问题：邮件同步进来之后，是直接改写了 CRM 记录的属性值，而不是另存一份日志。属性字段本身的机制细节，可以看 Macro 属性系统怎么工作。
@提及：任务在频道、邮件、文档里是同一个对象
文档里有一句是这套设计的地基：任务是 markdown 实体（markdown entities）。所以它能被 @提及到 Macro 里的任何位置——文档、邮件、聊天、频道，甚至另一个任务里。
提及渲染出来是一个 pill，这个 pill 会和任务的状态、标题保持同步，点它可以直接跳到任务。这解决的正是开头那个”链接会烂”的问题：你在三个月前的频道讨论里 @了一个任务，今天翻回去看，看到的是它现在的状态，不是当时的快照。反过来，从频道消息或邮件上悬停建任务，新任务和原始上下文之间的连接也是在创建时就建立的。频道这一侧的组织方式可以参考 Macro 的频道与消息机制。
团队共享这块的规则，文档写得比较死：
- 在团队里创建的任务，自动共享给团队全体成员，不需要额外发到频道或逐个分享；
- 队友可以查看和评论任务，但状态和属性的控制权在创建者和负责人手上；
- 加入一个团队，就能看到该团队的全部任务，包括分给自己的和分给别人的；
- 被移出团队，就失去这些任务的访问权；
- 不在任何团队里，任务对自己私有。
指派任务给某人会发送收件箱通知，在任务评论里 @某个队友也会。也就是说通知是绑在”指派”和”评论提及”这两个动作上的。
GitHub 与 MCP：两条自动改状态的通道
GitHub 集成的作用是让状态自己走。文档的描述是：在创建分支、评审、合并的过程中，任务会自动移动到 In Progress、In Review 或 Done，并且任务会记录下与之关联的是哪个拉取请求。配置路径是 Settings → Connections 里关联 GitHub 账号后点连接，连上之后任务就跟着 PR 走。这条链路的细节见 Macro 的 GitHub 集成。
第二条通道是 MCP。Macro 提供 MCP server，让 Claude Code、Codex、Cursor 这类 AI 客户端直接操作任务。连接方式是在 Settings → MCP server 里用 Macro 账号授权一次，文档明确写了 MCP 访问包含在所有套餐里，免费版也包括。
任务相关的 MCP 用途，文档列了四项：
| 操作 | 说明 |
|---|---|
| Create a task | 新建任务 |
| Find your tasks | 查找自己的任务 |
| Read a task | 读取某个任务 |
| Update a task | 更新任务 |
也就是标准的增查改，没有删除。文档举的场景是：在编辑器里就能建任务、给列表做分诊、把某项挪到 In Review，不用离开编辑器；改动会实时反映到 Macro 里。
属性层面另有一组 MCP 实体工具，Agent 通过它们读写属性：GetEntityProperties 读取，SetEntityProperty 更新（状态、负责人、日期、自定义字段都走它），ListEntities 用于浏览。所以 Agent 操作任务其实有两层入口——任务级的四个动作，和属性级的通用读写。
什么情况下这套设计不合适，以及文档没交代的部分
先说边界。如果你的流程强依赖标签体系或多维分类，Macro 的默认取向是反着来的——官方明确说不需要额外的标签和分类。虽然自定义属性里有 SELECT_STRING 可以当标签用，但这属于逆着产品默认假设走，值得先想清楚。
如果团队没有在用 GitHub，状态自动流转这条最有价值的链路就用不上，四档状态退化成纯手动维护，那和普通任务工具的差别就只剩 @提及和属性统一这两点了。
权限粒度只到团队一级。 文档说的是”加入团队即可见全部任务、移出即失去访问”，没有提任务级别的私密标记，也没有提团队内部的更细分权限。需要按项目隔离可见范围的场景，文档没有给答案。
再说文档没写清楚的几处，接入前值得自己验证：
- Completed 与 Done 的命名不一致，前面已经说过，接口枚举值以实际为准；
- 状态自动流转是否可关闭或改映射，文档只说”自动跟着 PR 走”，没说能不能定制这个映射；
- MCP 没有删除任务的能力，文档列的四项里没有 delete，是不支持还是没列出来，文档没说；
- 属性的自动化能力，除了 CRM 的 Last Interaction 会从同步邮件自动更新之外，文档没有描述其它自动改写属性的规则引擎；
- 自定义属性有没有数量或类型上的限制，文档只给了类型清单，没给约束。
如果要一句话概括这套东西的取舍：Macro 把任务做薄了（只有三个默认字段），但把任务所在的位置做厚了（可以出现在任何地方且保持同步）。这个取舍对”讨论和任务高度交织”的团队是划算的，对需要把任务系统当成独立台账来管的团队，则要先确认属性系统能不能撑起你原来那套字段。
延伸阅读
- 从头读起：Macro 是什么：邮件、任务、文档、CRM 共用一个双向数据库的开源工作区
- 本专题共 40 篇，完整分组目录见专题页
- Macro 的文档块：markdown 原生编辑与 Loro CRDT 实时协作是怎么组织的
- Macro 的 Canvas 二维板怎么用：板上的 @ 链接是活块，权限和反链要分开看
本文依据 Macro 官方仓库（github.com/macro-inc/macro，AGPL-3.0 协议）的 apps/docs/ 产品文档、
MCP 工具参考与自托管说明整理，核对日 2026-08-17。
我们没有注册或运行过 Macro，因此不涉及界面外观与操作手感；
官方标注为计划中的能力文中已如实标明，不代表当前可用。
价格与额度以官网 macro.com 最新页面为准；许可证相关问题请咨询专业人士并以官方许可证原文为准。