不再迷信Hackathon，把Agent推翻重做了4次！Notion负责人复盘：做AI产品如何避免“逆流而上”？

撞了 3 年墙才上线 Custom Agents，Notion 的两位负责人认为，AI 真正替代的不是人，而是流程。

编译 | 王启隆

出品丨AI 科技大本营（ID：rgznai100）

很多人现在做 Agent，第一反应还是给模型加工具。

工具不够，就继续加工具。system prompt 不够，就继续堆 system prompt。模型不稳定，就换一个更强的模型。可做着做着，你会发现问题并不只是模型够不够聪明，也不只是工具调不调得动，而是这套东西到底要长在哪儿，它跟原来的产品、权限、组织和工作流，究竟怎么接上。

这是我最近看 Latent Space 对 Notion 的一场播客时，最强烈的感受。

这期节目里，主持人找来的是 Notion 负责 AI engineering 的Sarah Sachs（右2），以及长期主导产品和原型方向的Simon Last（右1）。背景也很明确，Notion 刚刚上线Custom Agents。表面上看，这像是又一个大厂把 agent 做进办公软件里的故事。

他们聊的并不只是一个新功能怎么发布，而是 Notion 这几年怎么把 Agent 这件事推倒重来四五次，才慢慢摸到一条能成立的路。

这里面最有信息量的地方，不是某个 demo 漂不漂亮，也不是 system prompt 写得多巧，而是他们把几件原本经常被分开谈的东西扣在了一起：模型能力、工具抽象、权限设计、评测体系、团队组织，甚至定价。

换句话说，Notion 想做的并不是一个挂在软件外面的会聊天的助手。

他们更像是在试着把企业软件本身，重做成一个既给人用、也给 agent 用的工作底座。

要点速览

• Notion 从 2022 年就开始做 agent，但真正让他们觉得能往前推的，不是一个模型突然变聪明了，而是他们重做了四五轮之后，终于把模型、产品和权限接到了同一套框架里。

• 编程智能体（Coding Agent）像 AGI 的内核，而软件工厂则是在继续把这种能力往团队协作和代码维护的整条链路上推。

• 应用公司做 AI 不是包一层模型就结束了，而是要判断自己是不是在逆流而上，要看清模型能力的水流到底往哪边走。

• Notion 对 MCP 和 CLI 的态度也很现实，MCP 更轻、更好控权限，CLI 更强，也更有自举和自修复能力。选哪一个，不只是技术问题，也是能力、权限和成本怎么对齐的问题。

• 比起自己训练一个基础模型，Notion 现在更在意的是检索、排序、搜索这些更贴着 agent 工作流的基础层，因为越来越多搜索流量已经不是人发起的，而是 agent 发起的。

不是在追模型热点，而是在等那条河真正改道

主持人（Alessio）：恭喜你们最近发布了自定义智能体。这个功能折腾了这么久，终于正式上线了。现在回头看，是什么感觉？

Sarah Sachs：我们的发布节奏一直比较稳。它其实已经内测了一段时间。当一个产品走到这个阶段时，一拨人会盯着怎么把它顺利推上线，另一拨人已经开始做下一个版本。所以很多时候，真正发布时的那种成就感，反而会来得比较晚。

但现在回头看，还是会觉得值。大家确实为它投入了很多力气，而且今天做 AI 产品，用户教育也比两三年前容易多了，大家大致都能看懂你在做什么。这次发布在免费试用和用户转化上的表现，是我们到目前为止最好的一次。三个月的免费试用帮了很大忙。当然，后面还有很多东西要继续做。

Simon Last：对我来说，最激动的一点是，这套系统大概已经被我们重构了四次，甚至五次。

主持人（Alessio）：毕竟你们从 2022 年就开始做这件事了。

Simon Last：对。2022 年底，我们刚拿到 GPT-4 的访问权限时，脑子里最早冒出来的一个念头就是，干脆做一个智能体，给它 Notion 的全部工具权限，让它在后台替我们干活。那时候我们还不怎么叫它智能体，更多还是叫助手。

然后我们试了很多次，但那个时间点确实太早了。

主持人（Swyx）：你得把这个“太早了”展开讲讲。到底哪里不行？

Sarah Sachs：那时候连函数调用都还没出来。我们在和前沿实验室，还有 Fireworks 这类团队合作，想微调一个能调用 Notion 函数的模型。我加入时，这件事已经在推进了。

Simon Last：对。我们前后都和 Anthropic、OpenAI 合作过。最开始的时候，连“工具”这个概念都还没有。我们自己设计了一套工具调用框架，然后想办法去微调模型，让它能在多轮对话里使用这套框架。

但效果并不好。说到底，当时模型还是太笨，上下文窗口也太短。我们在这个问题上磕了很久。中间偶尔也能看到一点希望，但始终没有到那种既真正能用、又足够让人惊艳的程度。

直到去年初 Claude 3 Sonnet 出来，情况才突然有了很大变化。那时我们开始做去年发布的那版智能体，之后再一路做到现在的自定义智能体。

不过自定义智能体花的时间更长，因为你不仅要让它能跑，还要让它足够可靠，尤其是它在后台运行的时候。然后就是权限、分享、管理界面的设计。比如，一个智能体被分享给某个 Slack 频道里的一群人，但它又能访问另一批文档，这两批人的权限边界怎么解释清楚，管理员怎么一眼看明白，这些都不是 demo 阶段的问题，而是真正做产品一定会遇到的问题。

Sarah Sachs：归根结底，这些问题最后都会落到同一件事上，角色访问控制，也就是权限管理。

主持人（Alessio）：我很好奇，在模型能力还不够的时候，你们怎么规划路线图？一方面你得相信模型会继续变强，另一方面你们又不是一家零用户的小公司，你们在 2022 年就已经有很大的客户基础了。

Simon Last：这始终是一种平衡。你既得有一点 AGI 信仰，去为未来布局；你又必须交付当下真的有用的东西。我们一直在试着在两者之间找平衡。

我们的做法更像一个投资组合。一边维护和打磨已经发布、也已经跑得不错的功能，一边始终保留几个听起来有点疯狂的前沿项目。

主持人（Alessio）：那你们现在有哪些这种 AGI 信仰级别的方向？不用说太细，但我很好奇，有什么是你们现在做着，18 个月以后大家会觉得“原来这真的就是答案”的东西？

Simon Last：现在同时在发生很多事。一个越来越清楚的趋势是，编程智能体正在变成 AGI 的核心，某种程度上可以说万物皆可编程智能体。真正让人兴奋的地方，是智能体开始能引导出自己的软件和能力，然后自己去调试、维护它们。

另一个我特别兴奋的方向，是所谓的软件工厂。现在很多人都在讲这个词。简单说，就是你能不能把开发、调试、合并、评审和维护代码库、服务的整个流程尽可能自动化，让一群智能体在内部协同工作。这套东西到底该怎么设计，我觉得特别值得做。

Sarah Sachs：如果回到你最开始那个问题，为什么这件事花了这么久，我觉得大家很容易给出一个很偷懒的答案，说以前不行，后来推理模型出来了，就行了。

这当然是其中一部分，但我觉得真正让 Notion 每次都能抓住新能力的，是我们一直在练两种技能。

第一种，是别逆流而上。你得很快判断清楚，你现在碰到的到底是模型能力本身的天花板，还是因为你没有给模型正确的信息，没有搭对基础设施。

第二种，是一旦你确认自己不是在逆流而上，就要看清河流真正往哪里走。你要在技术还没完全成熟的时候，就开始搭产品。这样等它成熟的时候，你不会从零开始。

这件事有时候听起来很反直觉。比如工具调用模型还不存在的时候，我们就在尝试微调类似能力。诀窍不是死磕太久，而是意识到那里有机会。

我们其实有过很多这样的尝试。像会议纪要功能，在最后正式出来之前，我们在语音转录上已经迭代过很多版了。

Simon Last：那个我可以讲很久。

不是套壳，而是把“怎么工作”重新做一遍

Sarah Sachs：我们和前沿实验室在模型能力上的合作一直很紧密，但我们自己也必须有一个很明确的信念，随着这些能力不断演进，Notion 的使命仍然是成为你协作和工作的最好地方。如果大家的工作方式变了，那 Notion 这个产品故事也得跟着继续往前写。

主持人（Swyx）：对，你之前跟我说过你很喜欢“智能体实验室”那套理论，其实就是这个意思吧。

Sarah Sachs：对。我给很多候选人看过那套东西。它甚至已经成了我 Chrome 里的自动补全项。我拿它去解释，为什么你应该来 Notion，而不是去 OpenAI。因为这是两种完全不同的事情。

这也是为什么我们不是一个简单的套壳公司。虽然说实话，早期我们做的某些部分，确实也是在已有能力上做了一层封装。但那不是推动营收的核心产品，也不一定是用户真正需要的东西。

主持人（Alessio）：某种意义上，Notion 也可以说是 AWS 的套壳，但这个壳做得非常精致。

Sarah Sachs：我很喜欢拿 Datadog 和 AWS 来做类比。没有云存储，Datadog 根本不可能存在，这是它的底座。AWS 自己也有 CloudWatch，但 Datadog 真正懂的是，用户到底想怎样监控自己的系统。

同样地，我们真正懂的是，人们希望怎样协作。这才是我们的壁垒。

主持人（Alessio）：但你们跟 Datadog 又不太一样。Datadog 面向的是工程团队，用户比较像；你们是个平台，Notion 的终端用户几乎可以是任何人。所以这种专业知识怎么融进产品里？

Simon Last：对，这个类比到这里就会有点不一样。Datadog 这种经典垂直 SaaS，理解的是一群相对窄的人。Notion 一直非常横向。我们的任务始终是在两股有点对立的力量之间找平衡，一边是倾听广泛客户群体的需求，一边是把这些需求拆解成优雅、好用的底层原语，同时还要尽量让整个系统保持纯粹、易用。

Sarah Sachs：所以我们最后还是会回到用户旅程。老实说，我们团队最容易跑偏的时候，往往就是过度关注“什么工具看起来很酷”。那通常也是我们推进最慢的时候，因为你最终总得围绕某个真实用户旅程来做事。

比如我们每周五都会坐下来，看那些最消耗 Token 的自定义智能体日志，分析它们为什么表现差，然后砍掉一批不合理的任务。我们会坚持盯一些必须跑通的场景，比如邮件分类。我们也会在做聊天功能时认真思考 PDF 导出怎么做好。这里面可能需要构建可以访问计算机沙盒、文件系统、还能写代码的工具，但我们的出发点永远是“用户的工作里真的需要导出 PDF”，而不是“哇，做个计算机控制工具好酷，我们来试试”。

如果你不围绕用户旅程做事，你的优先级很快就会失去战略方向。

真正拉开差距的，不是点子，而是低 ego 的组织能力

主持人（Swyx）：你感觉有一套特别鲜明的方法论。你是怎么管理团队的？

Sarah Sachs：我觉得“怎么和 Sarah 共事”这件事，得看你问谁。团队成员、合作伙伴、供应商的答案可能都不一样。

但对我来说，有一个很重要的转变是，我很早就接受了一点，我的工作不是那个负责出最好点子的人，也不是那个技术最强的人。我的职责是，确保每个人都清楚目标，有资源去判断该优先做什么，而且有渠道去推进他们认为重要的事情。

这一点对所有领导层都成立，但在 AI 团队里尤其成立。因为我们很多最好的点子，都是那些看到了用户痛点，然后自己做出酷炫原型的人提出来的。

如果所有点子都得先经过我、产品搭档，或者 Simon 和 Ivan 的“嗅觉测试”，那损失会非常大。因为我们做的很多事，本质上都在探索模型能力边界。

所以第一点，我从不觉得工程领导的角色是层级式的。现在更不是。我们非常愿意根据结果改方向。

第二点，当你把底层框架重构了三四次之后，你就必须建立一个真正 low-ego 的团队。能删自己的代码，不在乎是不是自己先提的方案，一切以大局为重，也不会靠写一堆设计文档来给自己加戏。

在我加入之前，Notion 就已经有这种文化了。大家愿意一起上去解决问题，也愿意因为情况变化而推翻重做。在很多公司里，这种事会产生巨大摩擦，在 Notion 不会。

Simon Last：我不像 Sarah 那样是个管理者。我的角色更多是尽量把事情想远一点，确保我们建立在正确的能力基础上，再去做原型。不断从头思考真的非常关键。每次遇到新东西，我都会问，如果我们从头来过，会怎样。所以我基本上每六个月就在重复这个循环。

主持人（Alessio）：那你们信不信黑客松？

Sarah Sachs：我觉得分两种情况。

一种是，我们有一批非常可靠的资深工程师，他们会随时加入或退出我们内部所谓的“Simon 漩涡”，把一些高速变化的东西真正产品化。这种项目不需要黑客松，它需要的是能信任、能快速进出的资深工程师。

在这种情况下，组织边界会非常松。你可能名义上向这个人汇报，但现在正在为另一个人工作。我们在招管理者时，其实很看重他们能不能接受这种模糊边界。因为我们往往是在产品发布之后，才慢慢把组织架构固化下来。

另一种是，全公司的黑客松。这个是有的。它更多是为了让那些平时不直接做 AI 项目的人，也能停下来学学怎么提升自己的生产力，怎么用 Notion 自定义智能体搭东西。黑客松里有一部分内容，就是鼓励大家从零开始照着教程搭一套自己的工具调用循环。

主持人（Swyx）：是那个 Compound Engineering 的教程吗？

Sarah Sachs：对。我们希望公司里的每个人都会用 Claude Code，或者任何他们喜欢的编程智能体，并理解这里面最基础的原理。所以我们会专门空出一天半时间来做这件事。

不过半开玩笑地说，我们做的很多东西在最初都有点像黑客松产物，直到它真正长大，穿上“大人的衣服”，有了推广计划、数据科学家、完整的产品运营节奏。

主持人（Alessio）：那也得先过安全审查和企业合规吧。

Sarah Sachs：实际上，安全审查往往是我们最早引入的环节之一。因为如果你拖到后面才做，它会严重拖慢进度，还会制造很多矛盾。安全团队越早进来，越能帮我们做出更好的产品。这不是公关话术，是我们踩过坑之后留下来的伤疤。

Simon Last：我觉得黑客松对于提升全员素养很重要，但如果那是你们构建新东西的唯一方式，那就完蛋了。它必须融入日常流程。在 AI 时代，杠杆越来越倾向于那些最有好奇心、最有热情的人。如果有人周末兴奋地折腾出一个原型，而且它真的重要，那它就该立刻变成主线，而不是等到季度黑客松。

Sarah Sachs：对。我们现在 Notion 里的图像生成功能就是这么出来的。它一直是那种“有了挺好”的能力，很难进最核心的优先级，但数据库团队的 Jimmy 就非常想做。于是我们说，那你就放手做，我们给资源、给支持、给接口、给 Token 追踪、给邮件支持。最后它真就变成了完整项目。

Simon Last：这就是为什么作为领导者不能 ego 太强。否则这种事根本不会发生。

当整个公司都开始为智能体开发，评估就不再只是测试

主持人（Alessio）：你们现在团队大概有多大？

Sarah Sachs：我管的团队主要负责核心 AI 能力和基础设施，大概五十人左右。除此之外，还有一些合作团队负责产品层面的包装，比如决定 AI 最后出现在哪，是角落里的聊天框、自定义智能体，还是会议纪要，这部分大概三四十人。

但更重要的是，在 Notion，任何一个拥有用户可见产品服务的团队，都必须负责维护自己那部分被智能体调用的工具。做编辑器的团队，不仅要考虑人类怎么编辑，还得负责两个智能体同时改一块内容时的冲突问题；做底层 SQL 引擎的团队，也得确保智能体发起 SQL 查询时能高效执行。

从这个角度看，只要你在做产品工程，你的任务就是同时服务人类用户和智能体。因为随着时间推移，大量流量都会来自使用我们界面的智能体，而不是人类。我们的目标，就是让整个产品组织都开始为智能体开发。

主持人（Alessio）：这会不会让原型门槛变得特别低？现在大家很容易就在现有代码库里拼出一个新原型。那什么样的原型才算值得认真看待？

Simon Last：门槛确实在很多方面都变低了。我们设计团队就做了一个很酷的东西，他们自己建了一个独立 GitHub 仓库，叫“设计游乐场”，里面有很多辅助组件可以快速拼 UI，现在甚至内置了一个智能体。

所以他们现在不再交静态设计图，而是直接给你一个能跑的可交互原型。对工程师来说，门槛其实也很明确，能做出一个真正跑通的 feature flag，这就够了。

Sarah Sachs：Notion 很独特的一点，也是我为什么会加入这里，这个世界上没有谁比 Notion 自己的员工更频繁地在工作中使用 Notion。所以任何我们发布的东西，都会先被内部用起来，并迅速收获反馈。

有时候我们内部的开发实例简直乱成一锅粥，开关开得到处都是，但这已经是常态了。无论是做 IT 工单、采购还是招聘的人，大家都在同一个开着各种原型功能的 Notion 里工作。

我们团队的设计师 Brian Leven 还一直推一个理念，叫“Demos over Memos”，演示胜于文档。这极大推动了原型文化。但它也迫使我们必须对方向有足够强的信念。因为如果任何东西都能被做成 demo，你就更得知道你在堆的是一座塔，而不是一个平庸的小土丘。

Simon Last：总的来说，这套机制运转得挺好。几乎所有工程师都有足够好的品味，知道一个原型在产品里合不合理。所以我们很少看到那种完全无意义的原型。更多的问题在于，先做哪一个，以及怎么控制它的开关。

Sarah Sachs：不过从评估和平台角度看，这对底层团队确实带来了不小压力。比如你要在 Notion 里做图像生成，那附件处理方式、模型返回结果的预期、合规要求、供应商合同，全都得重做一遍。有时候一个功能在开发环境里待几周不能上线，不是因为它的想法不行，而是因为你得先把底层打稳。

这也是为什么我们非常强调“智能体开发效能”。如果你愿意在平台上投资，智能体能力迭代的速度就会快很多。

Sarah Sachs：所以我们现在其实有一个完整的组织，专门围绕智能体平台效能来搭。每个团队都可以建立自己的评估体系，并且在发布后继续维护它。如果模型变了，比如某个模型被弃用，我们也得能够尽快更新。

很多评估会直接接进 CI，或者每晚自动运行。我们甚至还有一个自定义智能体，一旦某个关键能力出现重大失败，就会自动报警，把团队叫去看。

这件事非常重要，因为现在太多不同的产品服务都跑在同一个智能体框架上，只是打包方式不同。如果底层一变，你要能很快知道哪里受影响了。

主持人（Alessio）：我有个关于评估的问题。你们会不会发现模型供应商暗中把模型变差了？

Sarah Sachs：如果你说的是那种高峰期模型突然变笨的情况，我觉得更常见的是不稳定性。有些时候，不同渠道给出来的所谓“同一个模型”，质量其实并不完全一样。有时是量化策略不一样，有时就是他们内部做了调整，但你拿到的效果和宣传并不完全一致。

我们当然会去理解这些变化。比如某些退化如果能换来明显更好的延迟，而且退化幅度在可接受范围内，那对某些场景未必不能接受。关键是，你得有足够好的评估手段去看懂它。

甚至在和实验室测试预发布模型时，他们会给我们多个快照。我们也确实遇到过，他们先给的版本不是我们真正想要的，但会根据我们的反馈继续改。因为我们的反馈很多时候更偏企业协作场景，而不是编程智能体场景。

主持人（Alessio）：那你们会不会有一批用例，长期过不了，就等着未来哪天模型终于能过？

Sarah Sachs：当然有，而且我觉得这里有一个很大的误区。很多人一提评估，就只是把它等同于质量测试，好像评估就是另一种单元测试。但这远远不够。

我们大致有三层。

第一层，像单元测试和回归测试，跑在 CI 里，要达到一定通过率。

第二层，是产品级评估。也就是当你在做一个产品时，你会明确说，这些用例目前还没通过，所以这个功能还不能发。我们内部会有一张成绩单，某些关键用户旅程必须跑到 80% 或 90% 以上，才算达到发布标准。

第三层，是更前沿的评估，也可以叫天花板评估。对于这类评估，我们甚至会故意把目标通过率放在 30% 左右。因为它的目的不是今天发版，而是让我们看清技术的天花板在哪里。

过去两三个月，我们和 Anthropic、OpenAI 合作时，很大一块工作就在这里。因为有一段时间我们发现评估有点饱和了，我们除了告诉对方“模型没变差”，已经给不出太有洞察的反馈。这对他们没帮助，对我们自己判断未来方向也没帮助。

所以我们花了很多时间去思考，什么才叫“Notion 的终极考试”。不是人类的终极考试，而是从 Notion 作为产品的角度，什么才是最难、最关键、最能决定未来方向的能力。

主持人（Swyx）：你们现在在招模型行为工程师？

Sarah Sachs：对，正在招。

主持人（Swyx）：这个岗位到底是什么？

Sarah Sachs：模型行为工程师。这个职位刚开始其实不叫这个名字。最早的时候，他们更像数据专员。那时他们跟 Simon 一起看 Google 表格，帮忙判断哪些结果好，哪些不好。

当时我们招了很多很特别的人，有语言学背景的人，也有计算机文学背景的人。他们特别出色，后来几乎等于自己把这个岗位定义了出来。

现在这个角色又在变。以前他们更像人工审阅结果的人，现在随着编程智能体出现，他们越来越多是在构建评估系统本身，比如让智能体自动写评估用例、使用 LLM 裁判之类的。

但我觉得这个角色真正有意思的地方在于，它不是一个纯工程岗位。它其实混合了数据科学家、产品经理、提示工程师的很多能力。你得理解模型能做什么、不能做什么，什么叫合理的天花板，什么叫一个真正好的用户旅程。你还得判断模型到底是变好了，还是只是换了一种方式失败。

这类工作里有大量定性的判断，特别依赖直觉和品味，而这不一定来自传统软件工程训练。所以我们一直都很欢迎非传统背景的人。我们非常相信，要在这件事上做得顶尖，不一定需要工程背景。

Simon Last：这也是我最近特别兴奋的一件事。我们在努力把评估系统本身当成一个智能体框架来对待。

理想状态是，你应该可以让一个智能体端到端下载数据集、运行评估、分析失败原因、调试、修复，最后再重新跑一遍。人类更多是在系统外面看着它，而不是自己手工去串这一整套流程。

我们已经在这件事上花了很多力气，而且效果相当不错。本质上，你就是把评估变成了一个编程智能体要解决的问题。

主持人（Swyx）：那是你们自己的编程智能体，还是任何一个通用智能体都可以？

Simon Last：我觉得应该是通用的。把它绑在某一个特定编程智能体上，反而是错的。说到底，它更像一个 CLI 工具。

Sarah Sachs：当然，这里面依然需要很多监督。我们只是觉得，这种监督不一定非得由软件工程师来做，因为其中有很多工作本质上更像用户研究，比如你要对失败案例进行分类，然后判断下一步应该往哪里打。

软件工程师不会消失，但工作的重心会变

主持人（Alessio）：那会不会有一天，Notion 里根本不需要软件工程师了？

Sarah Sachs：这要看你怎么定义软件工程师。

Simon Last：我更愿意把它看成一条连续演化的曲线。三年前，人类还在手写所有代码；后来有了自动补全；再后来有了整段补全；现在则进入了智能体可以执行长周期任务、调试、修 Bug、验证效果，甚至提交 PR、合并和部署的阶段。

我觉得我们只是一直在往更高的抽象层走。人类的角色会越来越像观察者和外部系统维护者。你会看到一串智能体在跑，然后你关注哪里偏了，哪些地方需要审批，哪里还缺有效的学习机制或记忆机制。

所以这仍然是一个很硬核的工程问题，我们只是在技术栈上又往上走了一层。

Sarah Sachs：今年夏天，Notion 的很多软件工程师都经历了一次挺明显的身份变化。我们内部有位工程主管说得很好，每个软件工程师都在经历管理者才有的身份认同危机。他们突然发现，自己最重要的能力不再只是写代码，而是委派任务和切换上下文。

从这个角度看，传统软件工程师的角色确实在被超越。

Simon Last：但这里和管理人类团队有一个很大不同，这里面其实非常技术化。人类是模糊的、感性的，你不能像调度一个严密系统那样调度一群人。你不能假设任务像 PR 一样在人与人之间自动流转、阻塞、恢复。

但对一群智能体，你是可以这么设计的。这背后其实有非常严谨的技术逻辑。归根结底，这还是一个系统设计问题。

主持人（Alessio）：那你们现在心里的软件工厂到底长什么样？

Simon Last：我们在尝试很多不同的方向。最终你想要的是一个尽可能少需要人类干预，但又能维持关键系统不变量的系统。

有几件事我觉得特别重要。第一，必须有一个规范层。你得有某种东西能把任务、需求、约束写清楚。直接提交 Markdown 文件就很好，作为 Notion 这当然很有意思，因为 PRD 天然就应该活在 Notion 里，它可以是一页文档，也可以是页面数据库。

但它必须首先是人类可读、可见的。

第二，必须有一个非常强的自我验证循环。你基本上需要一层非常强的测试体系，不然你根本不可能放心让一群智能体去接手那么多流程。

第三，就是工作流本身的设计。Bug 进来以后怎么进系统？是由某个子智能体接手吗？它怎么提交 PR？谁审查？怎么合并？怎么部署？这一整套流转，都是你要设计的东西。

自定义智能体真正替代的，是那层最烦的人工流程

主持人（Alessio）：我们录节目之前其实刚好做了一个自定义智能体的 demo。我们每次录节目都会试产品。这次我们用它给 Kernel Labs 的共享办公空间做了一个申请处理智能体。

以前的流程是，我收到邮件，读一遍申请，想想这个人值不值得聊，再回邮件，对方再回。现在我只花了十五分钟就搭好一个智能体，我告诉它去检查收件箱里的申请，然后它自动给我建数据库记录，去网上搜申请人信息，把时间、背景这些都补全。

这当然不是 AGI，但它干掉了我最不想手工做的那部分活。而且我特别喜欢的是，这些信息本来就该放在 Notion 里，而不是逼我再把数据搬到别的工具里。

Sarah Sachs：这其实就是我们看到的最大价值来源。很多时候，自定义智能体最大的收益不是替代掉某个人，而是替代掉流程中那层额外的人工干预。

像 Bug 分流就是最典型的用例。如果有人在 Slack 里提了问题，你能不能让一个驻留在那里的智能体，根据自己的路由规则判断应该归谁处理，然后在任务数据库里建卡，再回到 Slack 里回复。

这其实是我们内部最早做出来的一批东西之一。它真的改变了 Notion 公司内部很多事情的运行方式。没有东西会被遗漏——好吧，大部分不会被遗漏。毕竟你永远不可能知道自己不知道什么。

主持人（Alessio）：所以它并不是在替代人，而是在替代繁琐流程。

Sarah Sachs：对，就是这样。

主持人（Alessio）：我还在做另一个东西，类似租约填写器。每当有人正式签约成为租户，它就去填租约。那是不是再往前一步，应该有一个办公室经理智能体，它负责处理请求、制作租约、开门禁之类的？

Simon Last：我觉得这里有两种组合方式。

一种是通过数据原语来组合。比如一个智能体向数据库写数据，另一个智能体再去遍历这个数据库继续处理。这种解耦协同的方式就很好。

另一种是让它们直接耦合起来。一个功能大概很快就会上线，在智能体设置里，你可以允许它调用别的智能体。这样它们就可以直接对话。

主持人（Alessio）：那不会无限递归吗？

Simon Last：代码里肯定有个限制数值。但总会有人把它玩坏，你可以试试。毕竟一切最后都可能走向回形针制造机。

不过这个功能真的很有用。前几天我就在内部帮一个同事解决了类似的问题。他给市场团队建了三十多个自定义智能体，各干各的活，比如收集客户信息、分类客户反馈之类。然后他开始天天收到七十多条通知，全是这些智能体卡住了。

我就跟他说，这很明显，你需要一个管理者智能体。

于是我们帮他建了一个可以调用其他所有智能体的管理者智能体。它像是在上面再加了一层抽象，负责监控和观察。结果他每天收到的通知，从七十多条降到了五条，而且这个管理者智能体自己还会帮忙调试和修复其他智能体的问题。

主持人（Alessio）：听起来像是它们有一个内部收件箱，彼此可以发消息。

Simon Last：它们用的其实还是 Notion 这个记录系统。

Sarah Sachs：对，我们其实没有发明什么特别新的概念。与其让我自己收到那些通知，它们完全可以直接往某个数据库里写任务，让另一个智能体监听，或者通过 Webhook 去 @ 它。

Simon Last：我们现在就是尽量先用稍微粗糙一点但能跑通的方法把它做起来。那次我们就是建了一个记录智能体 Issue 的新数据库，让这些智能体都有权往里提交问题，再给管理者智能体读这个库的权限。结果效果很好。

本质上就是给智能体建了一套内部 Issue 追踪系统。如果以后这被证明是个普遍有用的概念，我们也许会把它打包成更标准的产品。但总的来说，我们还是尽量通过组合基础原语来解决问题。

再比如，Notion 本身并没有所谓“记忆”这个独立概念。记忆就是页面和数据库。你想给智能体记忆，就给它一个页面，再给它编辑权限。人类能改，智能体也能改。这个模式特别好用，而且可扩展性很高。

邮件、日历和原生集成，重点在于谁对体验负责

主持人（Alessio）：我在搭那个 demo 时，系统问我想接 Gmail 还是 Notion Mail。我当时心想，我其实哪个都不关心，我只想让你帮我搞定。那你们怎么分配这类产品精力？Notion Mail、Notion Calendar 这些界面还重要吗？

Simon Last：我觉得很重要的一点是，你不应该被迫使用 Notion Mail 才能接入邮件功能。我们应该能直接接 Gmail，或者你喜欢的其他服务。邮件之所以伟大，很大程度上就是因为它特别适合被智能体驱动。某种意义上，邮件应用本身也可以被看成一个预先打包好的收件箱自动化智能体。

Sarah Sachs：但这里的区别在于质量所有权。

当我们和 Gmail 集成时，我们更多是通过 MCP 或 API 向 Gmail 提供一组工具；而当我们接 Notion Mail 时，就会有专门的 Notion Mail 工程团队去打造最适合那个场景的工具，对延迟、性能和质量负责。

那边的产品负责人会直接思考邮件场景下的用户痛点。所以我们通常会先做原生集成，再考虑如何把它通用化。因为先做原生集成，往往更容易把体验打磨到位。

CLI 和 MCP，不是谁赢谁输，而是谁更像下一代基础设施

主持人（Swyx）：说到集成，我必须问一件事，MCP 还是 CLI？

Simon Last：我个人绝对非常看好 CLI。它有几个特别迷人的地方。第一，它运行在终端环境里，自带很多力量。比如长输出可以分页，你可以在里面浏览。第二，它天然支持渐进式呈现，你一开始不会把所有工具都摊给模型，它先看到的是 CLI 外壳，可以用 help，可以读文件。

最酷的是它的自举能力。如果出了问题，智能体可以在自己使用工具的那个环境里直接调试和修复。

我今天早上就看到一条推文，有人说自己的智能体没有浏览器，所以它给自己写了一个浏览器工具。不到一百行代码，它就封装了 Chromium API，给自己搓了个小浏览器。如果这个工具有 Bug，它还能继续修自己。

相反，如果你用的是 Chrome DevTools 的 MCP，而传输通道崩了，智能体就彻底失去浏览器，也失去了自救能力。我觉得这里有非常根本的差异。

主持人（Swyx）：不过话说回来，它的很多问题也不是协议本身的问题。比如渐进式呈现完全可以靠更好的框架来实现。最开始大家一股脑把所有工具都扔给模型，当然不行，但那不一定是 MCP 自身的错。

Simon Last：这点我同意。现在确实有很多实现得不太好的 MCP，因为大家之前都没经验。

总的来说，我很看好 CLI。但在某些环境下，我也仍然很看好 MCP。特别是那种需要轻量、单一能力、权限边界极清晰的智能体场景。很多时候，你不需要一个拥有完整计算运行时的编程智能体，你需要的只是一个只能调用工具的东西。

MCP 在这件事上天然非常强。而 CLI 的问题在于，它的权限边界往往没那么直观。它能不能接触 API Token？Token 有没有被妥善处理？这些都会引入很多真实而棘手的新问题。

所以我会说，MCP 是那种简单、粗暴，但非常管用的好东西。

Sarah Sachs：我从 Notion 的角度补两个视角。

第一，Notion 的使命是成为企业工作里最好的记录系统。所以只要外部生态还在使用 MCP，我们就一定会继续支持它。无论我们个人偏好什么，Notion 已经在这上面投入了很多，也有很强的团队在做。

第二，是成本问题。我最近一直在想一件事，怎么让定价真的和模型能力匹配起来。对于一些确定性很强的任务，如果你还要让大模型经由 MCP 去跟第三方服务反复交互，那其实是一种浪费。它不只是贵，而且不够确定。

尤其是我们的自定义智能体是按使用量计费的。我们把定价看成用户使用产品的门槛，所以非常在意别浪费用户的钱。对客户不公平，对商业上也不是好事。

如果某件事能通过 CLI 确定性地写代码执行，那可能就是一次性成本；相反，如果它每次都要经由模型和 MCP 重复跑一遍，你就会不断烧 Token，甚至缓存一失效又得再来一遍。那没有必要。

主持人（Swyx）：对，开放性是关键。如果我自己能直接写代码调 API，我也不会去用 MCP。但在一些场景里，你知道要调用什么，又不想每次都从头开始实现，那 MCP 还是很有价值。

主持人（Alessio）：那你们内部到底怎么判断？什么时候用简单 API，什么时候用 MCP，什么时候又要上更开放的智能体，比如带代码沙盒的那种？

Sarah Sachs：在 Notion AI 内部，我们不会简单说，因为这个能力太开放，所以我们就不发布它。

但有很多时候，我们不选 MCP，是因为我们想对质量有更深的控制。搜索和我们所谓的“智能体查找”就是典型例子。

我们在 Notion 里集成了 Slack、Linear、Jira 的搜索，但没有直接使用这些公司提供的搜索 MCP。因为我们觉得，想让一个智能体工作流真的表现出色，就必须对搜索旅程本身的细节有更多控制。

当然，长尾需求还是很多，所以我们也会做 MCP 服务器，让大家接他们想接的任何东西。但像搜索这种核心入口，以及少数一些特别关键的集成，我们会更愿意自己下场来做，因为我们知道自己的秘方在哪。

Simon Last：我觉得这里面其实没有真正的冲突，只是技术栈层级不同。MCP 提供的是一个获取工具访问权限的协议，它是开放协议，所以很适合覆盖大量长尾需求。

但如果你看我们的工具设置，你会发现“触发器”根本不在里面，因为 MCP 做不到触发器协议。这意味着有些东西我们必须自己建。

我们现在有些集成用了 MCP，比如 Linear 和 GitHub；但 Slack、邮件和日历是内部自建的，因为我们不仅要把工具打磨得极好，还得加上触发器。

所以我更愿意把它理解成，不同层级在做不同事。关键是你得在对的时间，用对的工具。

主持人（Swyx）：你一直在说重构。能不能大概回顾一下，你们这几次重构都改了什么？

Simon Last：我试试，这差不多得像做代码考古一样。

2022 年底我们最早做的那个版本，本质上其实是个编程智能体。我们当时想，与其造一堆工具，不如让一切都变成 JavaScript。我们给它 JavaScript API，让它自己写代码来完成调用。

但那时候模型写代码真的太烂了，所以不行。于是我们转向工具调用。问题是，那时原生工具调用功能还没出现，所以我们发明了一整套 XML 表示法。

那一版最大的教训是，我们太迎合 Notion 自己的数据模型了，而忽略了模型真正想要什么。比如我们做了一套能无损映射到 Notion Blocks 的 XML，转换非常方便，也有一整套页面编辑的 mutation 操作。但效果很糟。因为模型根本不懂这套东西，而且你还得在提示词里把它硬塞进去。

主持人（Swyx）：对，而且塞进去之后模型也用不好。

Simon Last：对。所以后来我们意识到，不行，必须上 Markdown。模型懂 Markdown。

于是我们又做了一次大重构，基本上是造了一种“Notion 风格的 Markdown”。核心想法是，底层必须尽量是纯 Markdown，然后在上面做增强。它不一定非得做到完全无损。

数据库这一层也有类似的教训。Notion API 原本的数据库查询是很复杂的 JSON 格式，和内部表示能很好对应，但模型不喜欢。于是我们把它推翻了，想法变成，一切都做成 SQLite，所有查询都让模型像写 SQLite 一样去写。模型对这个特别擅长。

所以我觉得有一个特别大的教训，就是给模型它真正想要的东西。你在设计环境的时候，必须极其谨慎地想清楚，模型究竟喜欢什么表达形式。不要把系统里那些没必要的复杂性暴露给它。

Sarah Sachs：但这还不是全部。后来又有了原生工具调用，我们做了研究模式，然后我们彻底抛弃了少样本提示词，转向更纯粹的工具定义。现在我们又在思考智能体 2.0。

Simon Last：对。整体的发展弧线其实很有意思。一开始你依赖单样本、少样本；然后变成给工具，但还要保留很多示例；再后来变成，干脆直接给它一堆工具。

但这又带来新问题。当工具越来越多的时候，渐进式呈现就变得非常关键。我们一度遇到一个瓶颈，智能体本来工作得很好，但随着工具不断增加，整个系统越来越难继续扩展，我们开始担心新的工具会把模型搞崩。

主持人（Swyx）：就那种，你只是说句“你好”，都要消耗一大堆 Token，而且速度很慢。

Simon Last：对，不只是成本问题，也是质量问题。因为每个工程师为了某个小众功能引入新工具，都有可能导致模型过度调用它，最后拖累整体表现。所以我们后面专门做了一轮框架优化，把渐进式呈现做得优雅一点。

Sarah Sachs：我甚至觉得，这可能比推理模型本身带来的转折还大。因为从少样本提示转向以目标为导向的工具描述之后，我们终于能把工具所有权真正分发给不同团队。

在过去，大家其实都在共同编辑同一串系统提示词，稍微顺序不一样，模型行为就会变化。那种模式不可能扩展，公司根本没法规模化。后来通过评估体系和更好的工具抽象，我们才终于把工具分出去，让每个团队能拥有自己的工具和定义。

当然也会出事故。比如我们曾经写出两个同名工具，Anthropic 的 Sonnet 就崩了，OpenAI 的模型反而自己想办法绕过去了。很多教训都不是纸上来的，是一脚踩出来的。

最危险的误解，是把自定义智能体做成“谁都能一眼看懂”的玩具

主持人（Swyx）：那你们会把这些工具列表公开吗？还是这属于机密？

Simon Last：完全公开。你直接问智能体，它会告诉你。

Sarah Sachs：我们不觉得系统提示词是我们的核心秘密。

Simon Last：而且我觉得，对操作者来说，理解这些其实很重要。有哪些工具、工具怎么运作、该怎么提示它，都是高级用户需要知道的。

我们内部有一句话，叫“教班里最聪明的学生”。我们希望自定义智能体是强大的工具。虽然设置界面尽量做得简单，但它应该有深度。操作者得能探到它的工作原理。

Sarah Sachs：甚至可以再说得更绝一点，我们其实并没有试图让它变成一个任何人都能一下子完全搞懂的产品。因为你越想把它简化到那个程度，你越会把可解释性和能力一起抽掉。

我们在做自定义智能体的时候，大概花了一个半星期才达成这个共识，我们不是在为所有人构建这个产品。一旦大家在这件事上想明白，整个团队推进速度反而更快了，因为目标用户终于更清晰了。

主持人（Alessio）：那个给智能体生成提示词的配置过程，到底是怎么工作的？

Simon Last：其实就是智能体自己在工作。我们在自定义智能体上做了一件我特别喜欢的事，它可以配置它自己。我们不仅给了它发邮件之类的工具权限，也给了它配置和调试自身的工具。

所以当你让它去写系统提示词时，本质上就是这个智能体自己在做这件事。我们并没有硬塞太多东西，只是给了它一份“怎么做一个好自定义智能体”的开发指南。

最棒的地方在于，如果它失败了，你可以直接问它为什么失败，再告诉它，更新你的指令，下次别再犯这个错。这个闭环非常自然。

Sarah Sachs：很显然，这也意味着我们下一步应该去做更明确的“自我修复”功能。

主持人（Alessio）：我其实已经体验到了。虽然还不是全自动，但我有一次配错了东西，点一下“修复”按钮，它就会自己帮我改。

Simon Last：这里其实牵扯到一个很关键的权限问题。自定义智能体默认是没有任何权限的，你必须显式授予它所有权限，这样你才能放心让它后台运行。

比如你知道，它可以读我的邮件，但不能发邮件，那你心里就有数了。如果你让它完全自动修自己，它就会跨过这个边界，因为它不应该自己偷偷修改自己的权限。

所以现在的做法更像是，你点击一个按钮，进入管理员模式，和它做一段同步对话。它在改之前也会先给你确认。

主持人（Alessio）：而且我很喜欢的一点是，编辑它和使用它是在同一个聊天框里完成的。不是一个地方配置、另一个地方使用。

Sarah Sachs：对。这个设计我们内部叫“Flippy”。

Simon Last：最开始的想法其实相反，设置是主界面，旁边放一个测试区。但如果你真的接受“它就是一个智能体”这件事，那更合理的设计就是翻过来。主视图应该是聊天框，设置更像一个侧边栏，用来预览它正在修改什么。我们希望最后做到，你几乎不需要手动去碰那些设置，而是直接通过对话完成。

Sarah Sachs：这个功能其实是这次发布里最大的拦路虎之一。因为很多早期用户已经习惯了旧流程，改他们的认知很痛苦。我们甚至为此多拖了一个月。但所有人最后都觉得，这个方向太对了，必须这么做。

主持人（Alessio）：现在它是免费的，这很好。但以后开始收费时，你们为什么会选用积分这种方式？

Sarah Sachs：因为真实成本不只是 Token。我们确实是跟 Token 使用量挂钩，但你不能把所有东西都直接摊平成 Token 价格。比如有些开源模型跑在 GPU 上，网络搜索有自己的成本，沙盒又是另一种成本。再加上高优先级处理、异步处理、缓存命中率，这些全都不一样。

所以我们必须在 Token 之上再建一个抽象层。

更重要的是，我们从一开始就想让客户得到公平交易。不是说我们想在这里暴利，而是客户应该只为合理的事情付钱。我们卖的本来就是企业级 SaaS，如果你卖积分包，客户买得多也更容易做折扣，这在销售流程上也更顺。

主持人（Alessio）：但价值不是均匀的。有人可能拿它去更新食谱，有人可能拿它去回投资人的重要邮件，价值差距很大。你们内部会讨论按价值收费吗？

Sarah Sachs：我们当然想过。但问题是，什么叫“复杂”或“有价值”，一旦真要严格定义，就会非常复杂。我们最开始也想过按智能体运行次数收费，但推演一圈之后你会发现，最终还是绕不开与 Token 吞吐量直接相关的复杂性。

所以目前按量计费是最朴素也最现实的方式。

还有一个特别现实的原因，我们的核心智能体一直带着模型选择器。为了维持利润率，有些功能我们根本承担不起。比如以后数据库自动填充如果都变成智能体驱动，而每个单元格都在跑 Opus 级别的能力，那这个产品在商业上根本不成立。

所以我们需要给那些愿意花钱做更多事的人一个出口，但又不能把高成本强加给低频用户。

而且，不是所有知识工作都一样复杂。很多智能体任务其实很快就碰到模型能力天花板，根本不需要一个特别贵的模型。我们希望用户自己决定，到底要不要为某个任务花那笔钱。甚至现在产品里也会主动提醒你，这个操作是不是很贵。

主持人（Alessio）：有趣的是，大家在这种异步场景里，似乎也没那么在意速度。

Sarah Sachs：对。当任务本身是异步的，“更快一点”这个优势就没那么重要了。我们更想做的是把真正有价值的额外服务给到用户，而最好的约束就是让他们自己掏自己的钱。

主持人（Swyx）：那 Auto 呢？很多人会本能地以为，Auto 只是选最便宜的模型。

Sarah Sachs：这正是我们现在特别努力的一件事，让大家明白 Auto 不是“最便宜、最笨”的那个，而是最适合你当前任务的那个。

我们其实在花很多力气优化 Auto，因为这就是智能体实验室真正该做的事。某种意义上，Auto 很像智能投顾。我们不是拿它当利润工具，而是拿它去减少用户压力。

它肯定不会永远是最强的模型，因为大多数任务根本不需要 Opus 那种级别的能力。

Simon Last：而且和很多前沿实验室不一样，我们并没有被激励去让你尽可能多地消耗 Token。我们真正关心的是，为你找到完成任务的正确工具。很多时候，那个正确工具甚至是直接写代码，根本不需要智能体。

如果某个智能体最终能自动化地把自己“炒掉”，我们其实会很开心。

Notion 真正想卡位的，是协作发生后的全部沉淀

主持人（Swyx）：我听下来，你们早晚会去训练自己的模型。毕竟你们有这么多 Token 数据。

Sarah Sachs：如果你说的是花自己的钱去训练一个基础模型，我并不这么看。

Simon Last：我也不觉得这应该成为我们的核心竞争力。

如果真要往模型训练走，我更感兴趣的不是给全世界做一个超级通用模型，而是未来是不是能做那种真正理解某一家企业上下文的模型。不是所有人共用一个大脑，而是一个特别懂你们公司业务、员工、流程的模型。那种东西如果有一天足够可行，我觉得质量提升会非常明显。

Sarah Sachs：现在确实已经有企业客户会问类似的问题，比如能不能把一个很懂他们内部环境的模型带进来，或者自己带密钥接进来。这也正是为什么我们会更愿意把系统提示词和工具接口做得开放一点。

当然，在 Notion 的某些具体能力上，我们还是会做微调和强化学习。但那不一定需要直接吃用户数据。只要我们的数据科学家和模型行为工程师足够清楚地理解差距在哪，我们就会在那些地方下手。

Simon Last：我自己以前在模型训练上花过非常多时间。那件事特别容易让人上瘾。你会一直训练、一直重训，睡前都得确保实验在跑。

Sarah Sachs：然后我这个管预算的人就会出现，把你叫停。

Simon Last：是的。但现在很有意思的是，编程智能体又把这种状态带回来了。现在我睡觉前也会想，我有没有启动足够多的智能体，让它们在我睡着的时候继续跑。

有一次我甚至让一个编程智能体线程连续跑了十七天。

Sarah Sachs：然后前沿实验室的人跑来问我，Simon 到底在干嘛，他是不是在证明弦理论。

Sarah Sachs：不过我们现在确实有一个领域在明显加大训练投入，就是检索。

因为现在我们很多搜索流量，其实已经不是人发起的，而是智能体发起的。打到 ElasticSearch 或向量索引上的那些查询，背后很多根本不是人在搜，而是智能体在搜。

这件事会改变整个检索系统的优化目标。对于人类搜索，你可能特别在意第一名和第六名的位置差异、点击率这些。但对智能体来说，更重要的是 Top-K 是否够全、返回结果能不能覆盖更多可能答案。

你会开始思考并行查询、查询扇出、查询多样性这些问题。甚至很多时候，向量嵌入本身已经不是最重要的优化层级了。更重要的是检索、排序、查询生成这整条链怎么一起工作。我们内部把这个方向叫“智能体查找”。

所以你会看到我们开始更认真地招排序工程师、模型训练工程师，因为这里确实已经变成一个新的核心问题。

主持人（Alessio）：我们也得聊聊会议纪要。这个功能现在做得很好，背后到底发生了什么？

Sarah Sachs：会议纪要其实一开始让我们非常紧张。我们担心它会逼着大家学习一套新的工作方式，担心用户摩擦太大。

但现在回头看，它已经成了我们最强的增长引擎之一，无论是病毒式传播还是留存都很强。所以随着它表现越来越好，我们也在不断往里加资源。

我觉得这个功能真正强大的地方在于，Notion 本来就是一个记录系统，而会议纪要让它开始捕获另一类以前很难系统化保存的数据。

比如我自己用它的方法就是，每次和经理的一对一会议，我都会留纪要。等到年终做绩效自评时，我基本上就是回头去看这些会议记录，然后写我这一年做了什么。因为如果某件事从来没有进入我和经理的一对一讨论，那它大概率也不是最重要的优先级。

所以会议纪要给我们带来了大量非常有价值的信号。这对一个记录系统当然很重要，对智能体也很重要。因为一旦你开始有了大量转录文本，你的内容规模会爆炸式增长，你怎么做上下文压缩、怎么在智能体里利用这些内容，都会被它反过来推动。

主持人（Alessio）：某种意义上，这是在捕获一类全新的数据。以前 Notion 里已经有我很多别的资料，所以我自然也会把这些新东西继续放进来。

Sarah Sachs：完全是这样。我们团队现在的工作方式基本上已经连起来了。每天站会前，会有一个自定义智能体先去读 Slack 和 GitHub，生成会前阅读。然后会议纪要记录会议过程。开完会之后，再有一个和日历联动的智能体，根据讨论内容往任务数据库里生成今天或明天要做的事，同时自动发出我们在会里决定要跟进的 Slack 消息。

所以我们在会里基本可以双手离开键盘，把注意力放在问题本身，而不是围绕问题做一堆繁琐记录。

Simon Last：会议纪要最近还多了一个我特别喜欢的功能。它在生成总结时会自动 @ 提及被提到的人。所以现在只要有人在会里提到我，我就会收到通知。

主持人（Alessio）：这会让你立刻知道，哦，他们正在聊我负责的东西。

Simon Last：对。我一看到这种通知，就会想，太好了，我应该马上去跟他们聊聊。

Sarah Sachs：这背后其实也有很多小但关键的质量工作。比如如果公司里有两个 Simon，系统怎么知道会议里提到的是哪一个？我们会做参会者相似度缓存，也会建立人物画像去辅助判断。目标当然是尽量别搞错。

会议纪要本质上就是建立在转录原语上的智能体原语。它一开始可能只是总结，现在已经越来越像一个数据捕获问题。以后我们当然希望它更进一步，比如它能在会议进行的同时，知道这场会对应哪个任务数据库、应该往哪里更新哪些任务，让整个过程更无缝。

主持人（Alessio）：那你们会不会去做硬件？比如 OpenAI 现在就在做新的硬件形态。

Sarah Sachs：大概率不会。

Simon Last：但我对这个品类本身是很兴奋的。

Sarah Sachs：我会把它理解成一种机制，而这种机制应该和 Notion 深度配合。无论最后是谁在做这类硬件，我们都愿意和他们合作。

现在已经有很多很有意思的公司在做可穿戴设备，他们都在和我们的合作团队交流。我每次都很爱旁听这些 demo。因为你完全可以想象，这种能一直陪在你身边的设备，一旦能搜索上下文、接入 CRM、再连上 Notion 智能体，会形成很多新的用法。

但这里又和自定义智能体不太一样。它越简单，你反而越难对它进行那种非常高级的能力控制。所以它更像是一个很好的数据捕获入口，不一定适合做复杂工作流本身。

Simon Last：而且这类设备天然很私人。公司不可能强迫每个人都戴个腕带，对吧。

我们真正关心的切面更像是，公司能不能把会议里所有这些上下文最终变成对自己有价值的记录和能力。

Sarah Sachs：对，这其实和我前面说的是一回事。我们的工作不是去构建最好的智能体运行框架，也不是构建最好的硬件。我们的工作是成为人们协作的最佳场所，是这些记录最终最该落下来的地方。

主持人（Alessio）：也就是说，别人把数据管道接进来，你们把后面的事做好。

Sarah Sachs：对，我觉得这就是最合理的定位。

【活动分享】"48 小时，与 50+ 位大厂技术决策者，共探 AI 落地真路径。"奇点智能技术大会是由深耕多年的「全球机器学习技术大会」重磅升级而来。2026 奇点智能技术大会将于 4 月 17-18 日在上海环球港凯悦酒店正式召开，大会聚焦大模型技术演进、智能体系统工程、OpenClaw 生态实践及 AI 行业落地等十二大专题板块，特邀来自BAT、京东、微软、小红书等头部企业的 50+ 位技术决策者分享实战案例。旨在帮助技术管理者与一线 AI 落地人员规避选型风险、降低试错成本、获取可复用的工程方法论，真正实现 AI 技术的规模化落地与商业价值转化。这不仅是一场技术的盛宴，更是决策者把握 2026 AI 拐点的战略机会。