【AI 原生 Meeting】Tana 怎样让会议成为工作的容器
背景
之前的文章有提到过，我在公司内一直是 Meeting 模块的主要开发。今年由于 AI 的爆发，我也开始转向会议 AI 功能的开发。
一个月以前，老板给我推荐了 Tana，还让我把它作为主题开一场分享会。于是我开始着手调研。过去我研究的竞品都是钉钉、飞书和腾讯会议。它们都在做会议，也都在加 AI；在我看来，AI 做的无非是把会里的信息收集得更快一点，让人更容易回顾。
我当时思考 Meeting AI，也是从会议本身出发。会议就是不同的人交流信息、表达想法，最后形成一点共识。那 AI 能做什么？实时把话转出来，归纳大家提到的重点，开完会给一份纪要，再把待办摘出来。这条思路很自然，我之前做的功能也大多落在这里。
上手玩了几天之后，我真的被 Tana 惊喜到了。极简的卡片化布局，卡片化的会议页把 Proposal、任务和文档摆在同一个工作台里，实时的 Voice Agent 能听大家说话，也能看共享屏幕；再加上 Do work in the meeting 这句话背后的做法，会议里的方案和任务已经可以当场继续往下处理。
Tana 让我换了一个看会的角度。会上讲出来的东西，最终还得回到原来的客户、任务和文档里去；Tana 把这一步也放进了会议里。
所以这篇想顺着 Tana 的官方文档和演示，把它在 Meeting 这件事上做了什么拆开看一遍。语我主要参考了 Tana 官方演示、产品说明和 Meeting 帮助文档；文中关于实现的判断，来自公开界面和行为，通过交互来分析产品形式。
一、Tana 是什么样的产品
我第一次打开 Tana 官网，最先看到的是一句 Do work in the meeting。页面上接着列了几件很具体的事：更新团队 OKR、创建 Issue、起草客户合同、给团队发消息。它想表达的产品边界很明确，Meeting 负责把人拉进一个视频房间，也负责把讨论后的工作继续处理掉。也就是说，真正的将可以让meeting可以开始干活，而不是开完会了再去分析，再去浪费时间去整理。(Tana 官网)
从公开页面和帮助文档看，Tana 的 Meeting 可以先拆成四部分：
-
一场带日程、参会人和视频通话的 Meeting；
-
一组被 Pin 到会议里的 Doc、Task、Canvas、Proposal 等工作对象；
-
会中持续产生的转写、话题摘要和屏幕 Capture；
-
会后提取出的 Summary、Decision、Action Item，以及对原对象的更新建议。
这四部分留在同一个 Meeting 页面。Tana 自己可以开视频会，也能在桌面端 Capture Zoom、Teams、Google Meet 等外部会议；内部会议会把实时转写、共享屏幕和会议页里的对象放在一起。(Tana Meetings)
这样做带来的产品能力很具体。产品会里讨论到一个 Bug，可以提成带类型的 Issue；客户会里改了需求，可以针对已有 Proposal 给出变更建议；技术方案确认后，会议或文档的上下文可以继续交给 Codex、Claude Code 等工具处理。每个动作都有明确的目标对象。
还有一个容易混淆的地方。原来的 Tana 现在叫 Tana Outliner，主要做知识管理和大纲式编辑；本文写的是新的 Tana，它围绕实时协作、Meeting 和 AI Agent 重新组织产品。(The next chapter for Tana)
二、为什么我会觉得 Tana 是一个 AI 原生产品
先举一个例子，我去看 Tana 官网时，拉到最下面看到了一个 Ask your AI。旁边放的是一份完整的产品说明 Markdown，用户复制给自己平时在用的 AI 或 Agent，就可以接着问“它适不适合我的团队”“它和正在用的工具有什么区别”这类问题。这个和我以前所参考的会议产品的形态非常不一样，它默认了使用者可能对于ai有一定的了解，就是这个想法就让我觉得非常的惊喜！(Tana 官网)
图：Tana 直接提供产品说明 Markdown，让用户复制给自己的 Agent。
Tana的集成度非常广泛，集成用户常用app。 Outlook 日程可以同步到 Tana 的 Today 页面，会议里提到的 Bug 和需求可以写进 Jira；当前会议或文档的上下文还能直接交给 Codex、Claude Code（CC）、Cursor 这类编码工具，带着已经整理好的 Prompt 去继续写代码。(Tana Integrations)
图：Tana 的 Integrations 页面里可以连接 GitHub、Slack、Linear、Jira 等工作工具。
第三方接入把 Tana 放在已有工作流的中间。日程留在 Outlook，需求和缺陷仍由 Jira、Linear 管理，团队继续在 Slack 沟通，代码交给各自的编码工具。Tana 从这些系统中带入本场 Meeting 需要的资料，再把会议里确认过的任务、文档修改或代码工作交回对应的系统。
这也决定了 Agent 的工作范围。它拿到的上下文不止是 Tana 里的一份文档，还包括日程、任务、需求和代码相关的信息；它的输出也能回到团队原来就在用的工具里。Meeting 因此成了这条工作流里汇集上下文、发起动作和审核变更的位置。
Tana不仅仅可以调用外部工具，也可以将自己作为MCP Server。 不仅可以调用别人的功能，也可以作为mcp被调用.让 Tana 调用 Outlook、Jira 这类外部服务；MCP 则让 Claude Code 等外部 Agent 通过标准工具协议调用 Tana 工作区。Tana 提供 MCP Server URL，完成 OAuth 授权后，外部 Agent 能搜索、读取和遍历工作区，也能处理表格、类型、日历和 Meeting 上下文。(Tana MCP)
图：Tana 提供 MCP Server URL，并给出 Claude Code 的接入命令。
Tana 把自己的工作区做成了 Agent 能直接使用的能力。外部 Agent 可以在任务执行过程中搜索相关会议、读取已 Pin 的文档、查看已有任务。这些信息按任务动态读取，会议上下文也能跟着被取走，后面的代码、文档或任务处理就能接上前面的讨论。
写入仍然先生成 Proposal，用户审核、编辑或丢弃。Tana 内置 Agent 和外部 Agent 共用这条写入边界，所有写入都经过同一套审核流程。
这种开放给用户留了很大的选择空间。团队可以按自己已有的工具组合继续工作，也可以选择自己常用的 MCP Agent 访问同一份 Meeting 上下文。Tana 在其中负责保留会议、文档和决策之间的引用关系，Agent 先读上下文，再产生 Proposal，最后由用户决定何时写入、写到哪里。这也是它能融入不同用户工具生态的原因。(Tana MCP)
三、Tana 怎么把会前、会中和会后串起来
图：Tana 用 meetings in, finished work out 概括会议中的四步：开会、AI 在会中整理产出、用户确认、产出进入任务和文档。
这张图画的是一场会里的四步。把连续的客户会或周期会放进来，Tana 的数据流会变成：会前把已有对象 Pin 进 Meeting，会中补充对话和屏幕信息，会后提取 Outcomes，下一次会前再把 Outcomes 变成 Brief。它把一次会议的输入和输出都留在同一条工作流上。
阶段Meeting 里保留的对象下一步如何使用
会前日程、参会人、议程、已 Pin 的文档和任务明确会议主题，给 Agent 一个可引用的业务对象
会中转写、时间线、屏幕 Capture、Live Digest将对话与当时展示的资料对应起来
会后Summary、Action Item、Decision、Open Question、ProposalProposal 审核后更新任务、文档或外部工具
下一次会前上一次的 Outcomes 和尚未完成的任务生成 Brief，避免再次翻历史信息
上一次会后留下的 Outcomes 包含已经做出的决策、还没完成的任务和待解决的问题。下一次会前，Agent 可以把这些内容整理进 Brief。会上有了新的讨论和结论，确认以后又变成新的 Outcomes。连续会议就有了一个稳定的上下文入口。
我以前参考钉钉的时候，看过一篇 《如何用钉钉开一场高质量会议？》。里面引用了一间日本公司算会议成本的公式：2S × Q × T，Q 是参会人数，T 是会议时长，文中把 S 设成平均时薪的三倍。
这个公式提醒我先看会前准备。十个人开一小时，有人进会才开始翻资料，其他人只能等；背景没有对齐，后面很可能还要再约一场。会议成本在会前就已经开始产生了。
钉钉那篇文章也按会前、会中、会后把流程串了起来。Tana 将会前资料、Meeting 和后续写入目标连成了一组对象关系。
会前：先把这场会放回原来的工作里
在 Tana 官方演示《How To Get Outcomes From Your Meetings》 里，有一场客户跟进会，叫 Nordfish - Saga follow up。我本来以为视频会从“进入会议”开始，结果用户先在聊天框里调了一个 Prep for an account call。
图：用户先让 Tana 为当天的客户会准备资料。截图来自上方官方演示。
它拿到的是一份带着具体业务关系的会前资料。页面里能看到 Meeting、Company、Deal、Proposal 这些已经连起来的内容。用户接着让它把 Brief 建成文档，再 Pin 到今天的会议里。
图：Brief 里能看到会议、公司、商机和已有 Proposal 的关联。
会前准备的重点是建立引用关系。用户 Pin 一份已有 Proposal，Meeting 就有了这次讨论的主对象；再把 Company、Deal、旧任务和 Brief 放进来，Agent 才能判断“这个试点”“上次那个方案”分别在说什么。Tana 的帮助文档也说明，Pin 到会议里的文档会影响会后的提取结果：当会议有 Product Track 或开放 Issue 这类文档时，提取过程会优先更新它，而不是另建一份平行文档。(Tana Meetings)
如果自己实现，我会把这一层叫 MeetingContext。它不该只是一段拼在 Prompt 后面的文本，至少要记录当前 Meeting 能访问哪些对象、哪些对象只是参考、哪些对象允许成为更新目标。后面的任务创建、文档 Diff 和外部写入都依赖这层边界。
会后：一场会留下哪些 Outcomes
会后有一个命名值得拆开看。Tana 会生成 Summary，同时还会给出一组 Outcomes。Summary 负责回顾讨论，Outcomes 则把 Action Item、Decision、Open Question 这些内容提成有类型的对象。任务可以带负责人和截止时间，决策能保留当时的理由；会议中已经 Pin 了 Proposal 或项目文档时，Tana 会优先把它作为更新目标。(Tana Meetings)
产品上，Summary 和 Outcomes 分别对应两种访问方式。Summary 让人回看这场会，Outcomes 让人继续处理这场会留下的对象。Tana 在会后自动生成 Summary，并提取任务和决策；重新执行提取时会更新已有产出，避免重复创建同一条结果。(Tana Meetings)
下一次同一个客户会或周期会开始前，Agent 可以把上次的决策、未完成任务和已经变化的内容整理进 Brief。上一次会后的产出就成了下一次会前的上下文。(How to manage executive meetings in Tana)
四、卡片化布局，让会议成为一个 AI 读得懂的容器
这里的“容器”指的是 Meeting 页面收纳了这次工作需要的上下文、证据和动作入口：人说了什么、屏幕展示了什么、当前讨论的是哪份文档、AI 可以创建或修改什么。它们需要在同一个作用域里被引用，会议才能承担后续工作的入口。
进到会议页以后，Tana 的界面像一个视频会议和工作台拼在一起。左边是视频，中间是 Live Digest，右侧摆着 Talking Points、Brief、Proposal 这些卡片。公开文档里也把它描述成三栏结构，已 Pin 的公开文档和已批准的 Outcomes 会显示在右侧的 surface column。(Tana Meetings)
图：会议页同时放着视频、聊天和讨论中的对象。
把这个页面按产品能力拆开，可以看到四层：
层会议中承载的内容对 Agent 的意义
证据层转写、发言人、时间戳、屏幕 Capture回答“谁在什么时候说了什么、当时展示了什么”
业务对象层已 Pin 的 Doc、Task、Canvas、Proposal回答“这次会正在处理哪份资料、哪个任务”
交互层Voice、Chat、Capture、拖动和 Pin人能在会议里显式补充上下文或发起动作
结果层Summary、Outcome、Proposal、Doc DiffAI 的输出有位置可展示、可审核、可回写
Proposal 被 Pin 到会议以后，参会人和 Agent 都有一个明确的引用目标。有人说“这一段要改一下”，系统不用只从转写里猜“这一段”属于哪份文档。Tana 的帮助文档明确写到，Pin 到会议里的文档会被作为会议主题，Outcome 提取会优先更新它。(Tana Meetings)
卡片在这里同时做了两件事。对人来说，它把会议中的资料和操作放在伸手可及的位置；对 Agent 来说，它把原本散在聊天、文档和任务系统里的对象变成可引用的上下文。内部实现未必真是“卡片”这种数据结构，但产品界面已经把对象、来源和操作目标显式地暴露出来了。
这也是我会用“Meeting 容器”形容它的原因。普通会议页面主要承载音视频和聊天记录，Tana 的 Meeting 还承载业务对象、会中证据和待执行动作。AI 能读到一组有类型、有来源、有操作目标的对象。
五、Tana：一个参与会议的 Voice Agent
Voice Agent 是这套 Meeting 容器上的一个实时交互入口。Tana 的内部会议可以通过唤醒词或页面控制启动语音 Agent，它会作为一个语音参与者出现在会议里；外部会议的桌面 Capture 暂时没有这个能力。(Tana Meetings)
能听
Tana 对每个参会人的音频分别做实时转写，转写里带发言人和时间戳。会议页的 Live Digest 则把当下的讨论组织成可浏览的话题。(Tana Meetings)
语音 Agent 用这份会议状态回答问题。用户问“刚才定了什么”“目前提取了哪些内容”时，不需要重新描述会议背景。官方文档列出的上下文包括当天议程、当前 Meeting 详情、正在说的话、已 Pin 的对象、共享屏幕和已经 Capture 的 Outcomes。它接到任务后可以在后台执行，结果会放到下一次合适的停顿再播报，避免打断正在说话的人。(Tana Meetings)
能看
只听语音仍然会缺很多信息。产品会共享的是原型、数据面板和需求文档，会议里常见的“看这里”“这个按钮”“上面这条数据”都没有出现在转写文本里。
Tana 会定期截取共享屏幕，过滤重复帧，为保留下来的画面生成描述，再把 Capture 放到对应的讨论时间线中。Outcome 提取时，Agent 可以同时引用屏幕内容和语音内容。(Tana Meetings) 人投屏原本是为了让参会者共同看资料，Tana 把这份画面也变成了 Agent 的上下文。摄像头画面不会进入这些 Capture，用户还可以通过 Off the Record 同时暂停转写和屏幕 Capture。(Tana Meetings)
Capture 把多模态上下文转成结构化结果。用户可以把刚刚的一段讨论提成 Task、Bug、Decision，或者工作空间里自定义的其他类型。会后页面也会把 Action Item、Decision 这些结果单独放出来。(Tana Meetings)
拿一个产品会里很常见的句子举例：
这个交互先按 B 方案走，李明补一下埋点，下周三前给我看数据。
实时摘要可以写成“团队决定采用 B 方案，并补充埋点”。如果要继续处理，系统还得区分一条决策和一条任务，提取负责人和日期，并保留这段话的来源。用户从任务列表回到 Meeting 时，需要能看到原始讨论；再次 Capture 同一段内容时，也不能再创建一张重复任务。
Tana 的文档提到，重复提取会更新已有产出。这个能力表面很小，背后需要处理结果的身份、来源片段和更新语义。模型抽出一条待办不算难，判断它是新增任务、补充任务还是修改已有任务，才决定这条结果能不能进真实工作流。
六、AI 怎么参与会议，并且把活干下去
Voice Agent、卡片栏和 Capture 最后都得落到具体动作上。Tana 的 Capture 可以选择回看范围，例如最近 2 分钟、10 分钟或整场会，再选择要提取的类型。系统据这段带时间边界的对话创建 Task、Bug、Decision 等结构化对象。(Tana Meetings)
有了类型还不够，AI 还要找到操作对象。Meeting 里已 Pin 的 Proposal、Issue 或项目文档提供了这个目标引用。系统可以把会议结论整理成任务和决策，也可以据对话更新目标文档；外部 Agent 通过 MCP 写入工作区时，同样走 Proposal 审核。(Tana Meetings) (Tana MCP)
Proposal 和 Doc Diff
演示里客户团队讨论完语言培训试点后，原来的 Proposal 没有被直接改掉。页面上先出现了 To Be Updated，点进去能看到红绿 Diff。用户点 Update，改动才写回 Proposal。
图：Tana 先给出 Proposal 的修改建议，底部保留 Update 这个确认动作。
会议里的句子经常带不确定性。有人说“要不改成两周”，它还只是一个提议；有人说“那就按两周走”，才可能是一次决策。Agent 很难仅凭一句话承担直接修改正式文档的责任。
Proposal 在这里承担的是审核层。它把一次 AI 操作拆成几个用户能检查的字段：改哪个对象、改了哪一段、建议内容是什么、来源是否合理。Doc Diff 让用户看到红绿变更，再决定更新、编辑或丢弃。Tana 对 MCP 写入也使用同一套 Proposal 机制，外部 Agent 同样要经过这个审核点。(Tana MCP)
如果从实现角度列一个最小模型，一次可写入的会议产出至少要保存以下信息：
-
产出类型，例如 Task、Decision 或文档修改；
-
目标对象，例如某个 Proposal、Issue 或任务列表；
-
证据来源，例如对应的转写片段和屏幕 Capture；
-
结构化字段，例如负责人、截止时间、修改后的内容；
-
Proposal 状态，例如待审核、已接受、已拒绝。
这些字段把模型输出和真实副作用隔开。模型可以猜错，用户仍然能看到、拒绝或修改这次变更；系统也能根据来源和状态判断后续是更新已有产出，还是创建一条新记录。
七、Tana 如何 Redefine Meeting
Tana 官网把自己的 slogan 写成了 Do work in the meeting。这里的 Do 不是一句文案，它对应着一套产品结构：会议先拿到业务上下文，会中持续收集语音和视觉证据，Agent 把结果提成结构化对象，再通过 Proposal 把变更写回文档、任务或外部系统。
传统 Meeting 产品的主输出是视频、录音、转写和纪要。Tana 把 Meeting 往前推成了一个工作单元：它有输入对象、有实时证据、有可调用的 Agent、有审核状态，也有明确的写入目标。客户会里更新 Proposal，产品会里创建 Bug，技术方案会里把准备好的上下文交给编码工具，都沿着这个单元继续执行。
这也给 Meeting AI 的实现提出了更具体的问题。实时转写和 Summary 只是输入层和回顾层，后面还要处理引用消解、对象类型、权限范围、变更审核和写入幂等性。没有这些能力，AI 很容易只停在“把会记下来”；补齐这些能力，会议里的讨论才有机会变成系统里可继续推进的工作。
Tana 重新组织了 Meeting 与文档、任务、日程和外部工具之间的关系。后面做 Meeting AI 时，我会先找这场会需要引用哪些对象、会产生哪些可执行结果、每种结果由谁审核和写入，再去设计转写、总结和交互。
本文调研内容，截图，示例，想法都来自于真实调研和思考，ai仅参与文章润色
评论
暂无公开评论。