Notion 的 Token Town：五次推倒重来、100+ 工具与软件工厂愿景
访谈概述
本期播客由 Latent Space 的创始人 Alessio 和编辑 Swyx 主持，邀请了知名生产力工具 Notion 的联合创始人 Simon Last 以及 AI 工程负责人 Sarah Sachs 做客节目。双方深入探讨了 Notion 刚刚重磅推出的自定义智能体（Custom Agents）背后的故事。
在访谈中，Simon 和 Sarah 揭秘了为什么这个功能早在 2022 年就开始研发，却经历了四五次彻底的推倒重来才最终上线。他们分享了早期在工具调用（Tool-calling）上的失败尝试，以及如何从单纯的“套壳应用”转向构建真正的“智能体实验室（Agent Lab）”理念。此外，对话还深入探讨了 Notion 的产品与工程哲学，包括：不拘小节的团队文化、“演示胜于文档”的开发模式、创新的“模型行为工程师（MBE）”角色、复杂的测评（Evals）机制、MCP（模型上下文协议）与 CLI（命令行）的技术路线抉择，以及将 Notion 打造为未来“软件工厂（Software Factory）”和企业级智能体协作核心数据系统的宏大愿景。
专用词语翻译列表
| 英文原词 | 中文翻译/解释 |
|---|---|
| Custom Agents | 自定义智能体 |
| Agent Harness | 智能体测试/运行框架 |
| Function Calling / Tool Calling | 函数调用 / 工具调用 |
| Progressive Disclosure | 渐进式呈现（一种UI/UX设计模式，逐步向用户或AI展示复杂功能） |
| MCP (Model Context Protocol) | 模型上下文协议 |
| CLI (Command Line Interface) | 命令行界面 |
| Evals (Evaluations) | 模型评估/测评 |
| Model Behavior Engineer (MBE) | 模型行为工程师（Notion 内部专设的职位） |
| Software Factory | 软件工厂（指由多个智能体协同完成软件开发、测试、审查全流程的系统） |
| System of Record | 核心数据系统 / 记录系统 |
| Wrapper | 包装器 / 套壳应用 |
| Frontier Labs | 前沿 AI 实验室（指 OpenAI、Anthropic、Google 等头部 AI 机构） |
| AGI-pilled | 信仰 AGI / 深受 AGI 理念影响 |
| Demos over memos | 演示胜于文档（Notion 内部推崇的产品开发文化） |
| Retrieval / Ranking | 检索 / 排序（搜索与 RAG 技术核心环节） |
Alessio: 大家好，欢迎收听 Latent Space 播客。我是 Kernel Labs 的创始人 Alessio，和我一起的是 Latent Space 的编辑 Swyx。
Swyx: 大家好。我们回到了 Alessio 为我们搭建的漂亮演播室。今天迎来了 Notion 的 Simon 和 Sarah。欢迎你们。
Sarah Sachs: 谢谢你们邀请我们。
Alessio: 感谢你们的到来。
Swyx: 恭喜你们最近发布了 Notion Custom Agents（自定义智能体），终于上线了。感觉怎么样？
Sarah Sachs: 我们的发布节奏其实比较慢。这个功能在 Alpha 阶段已经测试了一段时间。当一个产品处于 Alpha 阶段时，团队里有一部分人负责确保它能顺利进入生产环境，而另一部分人已经开始研发下一个功能了。所以有时候，这类发布会有一种延迟的满足感。因为你不能自满，必须保持超前两三个里程碑的节奏，所以发布时反而需要提醒自己之前付出了多少努力。不过，看到大家理解这个功能的用处感觉很棒。我觉得今天做 AI 工具比两三年前容易多了，用户基本能理解它的价值，所以用户教育成本降低了。这是我们在免费试用和用户转化方面最成功的一次发布。当然，还有很多东西要建。
Swyx: 给用户三个月的免费试用期肯定有帮助。
Simon Last: 对我来说这绝对超级激动人心，因为这大概是我们第四次或第五次重构这个功能了。
Swyx: 是的。你们从 2022 年就开始做这个了。
Simon Last: 没错，就在 2022 年底我们刚拿到 GPT-4 访问权限时，我们最初的想法之一就是：我们要弄一个智能体（当时还没有Agent这个词，我们叫它助手），给它访问 Notion 所有工具的权限，让它在后台替我们工作。然后我们尝试了很多次，但时机实在太早了。
Swyx: 我必须要让你深入讲讲这点。什么是“太早了”？当时是什么行不通？
Sarah Sachs: 在函数调用（Function Calling）功能问世之前，我们就试图和前沿实验室以及 Fireworks 合作，微调一个能在 Notion 函数上进行函数调用的模型。那正是我加入公司的时候。我加入是因为 Simon 需要一个管理者，这样他才能休假。所以你可以更详细地讲讲当时的细节。
Simon Last: 我们在不同时期与 Anthropic 和 OpenAI 都进行过合作。我们第一次尝试时，甚至还没有“工具（Tools）”这个概念。我们设计了自己的工具调用框架，然后尝试微调模型，让它在多轮对话中使用这个框架。但开箱即用的效果并不好，模型太笨了，上下文窗口也太短了。
Alessio: 是的。
Simon Last: 我们在上面死磕了很久。不幸的是，它总是偶尔闪现出一点能用的光芒，但从未达到足够稳定、能让人觉得它是一个有用且令人愉悦的产品的程度。直到去年初 Claude 3 Sonnet 发布，那是一个巨大的突破。从那时起，我们开始研发去年发布的 Notion Agent，然后是自定义智能体（Custom Agents）。自定义智能体花了更长时间，因为我们想大幅提高它的可靠性，毕竟它是在后台自动运行的。
Sarah Sachs: 还有产品界面的问题，比如权限控制。你需要让管理员明白：这个自定义智能体被分享在某个 Slack 频道里，有特定的一群人可以使用它；同时它能访问的文档也是针对另一群人的，而这两群人的交集可能并不完全重合。如何围绕权限设计产品，让管理员清晰理解，我们在这上面也推倒重来了好几次。
Alessio: 归根结底，任何事情都不容易。我很好奇，当模型还不够好的时候，你们是如何规划产品路线图的？你们一方面要预期模型会以合理的速度进化并为此做准备，但另一方面，你们在 2022 年就已经有庞大的用户群了，你们并不是一家从零开始的初创公司。
Simon Last: 这里面总存在一种平衡：你既想拥抱 AGI 理念，高瞻远瞩，为未来的发展方向做准备；但同时你也需要交付当下就有用的产品。我们一直试图保持这种平衡。我们采取了类似投资组合的策略：我们总是在同时推进多个项目，维护已经发布并运行良好的功能，同时保留几个看起来有点疯狂的前沿项目。
Alessio: 那你们今天有哪些“拥抱 AGI（AGI-pilled）”的项目？我很好奇，不需要分享具体的机密，但有哪些东西是你们现在正在做，而 18 个月后人们会觉得“哦，这显然是行得通的”？
Sarah Sachs: 18个月在AI领域可是很长一段时间。
Simon Last: 有很多事情正在发生。我觉得越来越清晰的一点是：编程智能体（Coding Agents）似乎是 AGI 的内核，某种程度上，一切都可以看作是编程智能体。这是一个方向。令人兴奋的是，你的智能体可以引导自己的软件和能力进化，并且能够自行调试和维护。我们在这方面思考了很多。另一个让我非常兴奋的类别是“软件工厂（Software Factory）”，现在大家也都在用这个词。它基本上意味着，你能不能创造一个尽可能自动化的工作流，用于开发、调试、合并、代码审查以及维护代码库和服务？在这个系统里有一群智能体协同工作，这会是怎样一种运作模式？
Sarah Sachs: 如果回到你最初的问题：为什么花了这么长时间？在这三年半的尝试中，到底发生了什么改变？
Swyx: 我其实没这么问，但没错，请继续。因为大多数人总是说“之前不行，后来推理模型出来了就行了”。我想稍微深挖一下。
Sarah Sachs: 那只是其中一部分原因。但我认为，让 Notion 在面对每一种新能力时脱颖而出的，是我们具备两项应对前沿能力的关键技能。第一，是不逆流而上。也就是要快速意识到，你到底是在跟模型的硬性能力瓶颈死磕，还是仅仅因为你没有把正确的信息暴露给模型，或者没有搭建好合适的基础设施。这本身就是一种直觉技能。第二，当你确认自己没有逆流而上时，你要看清河流的流向，并开始超前思考产品，哪怕它现在还不够好。你要提前搭建好它，这样当模型能力到位时，你们就已经准备好了。
这两点有时候听起来是矛盾的。比如，在工具调用模型还不存在时，我们就试图去微调一个。这里的诀窍是不要在这上面耗费太久，而是要意识到那个方向是对的。我们有很多次因为顺错了水流方向而失败的经历。比如在最终做出 Meeting Notes（会议笔记）之前，我们在转录（Transcription）功能上迭代了好几个版本。
Swyx: 稍后我必须得跟你聊聊这个。
Sarah Sachs: 所以，我们在能力层面与前沿实验室紧密合作，同时我们也必须有坚定的信念：随着这些能力的提升，Notion 致力于成为人们协作和完成工作的最佳场所的愿景不会变。如果人们工作的方式发生了改变，我们的产品叙事该如何随之演变？
Swyx: 你之前跟我说过你是“智能体实验室（Agent Lab）”理论的粉丝，这就是它的核心对吧？
Sarah Sachs: 对，我给很多求职者看过那个理论。现在它简直成了我浏览器自动填充的常用网址，是我访问最频繁的页面之一。
Swyx: 这是在告诉他们“为什么你应该来 Notion 而不是去 OpenAI”吗？
Sarah Sachs: 是告诉他们这里有什么不同，为什么我们不仅仅是一个“套壳应用（Wrapper）”。我觉得现在越来越多的人明白我们不仅仅是一个套壳了。顺便说一下，在早期阶段，我们构建的部分功能确实是对底层模型能力的封装，这很正常，但这并不是驱动我们核心营收的产品，也不一定是用户最需要的东西。
Swyx: 我的意思是，Notion 某种程度上也是 AWS 的套壳，但这层“壳”非常漂亮，打磨得非常精细。
Sarah Sachs: 我最近经常用 Datadog 和 AWS 来做类比。没有云存储，Datadog 就不可能存在，这是它运作的基础。AWS 也有自己的 CloudWatch 产品，但 Datadog 才是理解人们到底希望如何监控和观测他们发布的产品的专家。同样的，我们是理解人们究竟希望如何协作的专家，这才是我们的专业领域所在，不管底层用的是什么工具。
Alessio: 我很好奇你们是如何看待“隐性专业知识”和“显性专业知识”的。我觉得 Datadog 各占一半，他们了解跨市场和跨行业的工程团队通常需要什么。但对于 Notion 来说，专业知识似乎更多地存在于边缘端，因为作为一个平台，你们太横向了，最终用户的需求千差万别。Datadog 的最终用户总是工程负责人或 SRE 相关人员，但在 Notion 里，用户可能是任何人。我很好奇你们是如何将这种专业知识融入产品的？显然 AWS 无法造出 Notion，但在这种情况下它是如何运作的？
Simon Last: 它们的形态有点不同。对于典型的垂直 SaaS，比如 Datadog，他们对个别客户有非常深刻的理解，那是一个很窄的切面。而 Notion 一直是非常横向的。我们的任务总是平衡两股有些对立的力量：一方面倾听客户的需求，这涉及非常广泛的群体；另一方面思考如何将他们的需求解构为好用的基础组件（Primitives），让我们以最小的代价获得最大的收益，同时还要维护整个系统，让它保持整洁和易用。
Sarah Sachs: 我们依然会关注用户旅程（User Journeys）。实际上，当团队过度关注那些“看起来很酷的工具”时，往往是我们失败的时候。
Simon Last: 是的。
Sarah Sachs: 我认为这时候我们的进展会最慢，因为你必须对用户旅程有所聚焦。比如，我们每周五都会坐下来，查看在 Token 消耗上排在 P99（最耗费资源）的自定义智能体记录，分析它为什么表现不好，然后砍掉一堆不必要的任务。我们依然会坚持认为，某些特定场景必须能跑通，比如邮件分类分发（Email triaging）必须能顺畅工作。
同样的，我们之前在讨论如何做 PDF 导出时，如果这项功能需要，我们可能才会考虑构建一个能够访问计算机沙盒、文件系统以及具备写代码能力的工具。但这一切是因为我们在考虑用户日常工作需要导出 PDF，而不是因为我们觉得“弄个计算机操作工具好像很酷，我们来看看会发生什么”。我们必须聚焦于特定的用户旅程，否则我们就没有足够的战略方向来确定优先级。
Swyx: 我觉得你们有很多非常强烈的观点。Sarah，你有没有类似于“Sarah团队管理之道”之类的东西？感觉你积累了很多鲜明的观点。显然，其中一部分体现在你的“Token Town”理念里。
Sarah Sachs: 和我共事到底是什么体验，这得看你问谁。可能取决于你是我团队的人、是合作伙伴，还是供应商。其他人可能想用我的方式来管理团队，当然，你把这些观点带入了工作中。
Swyx: 同样地，Simon，当你在做自定义智能体演示时，你说“我们一直在使用自定义智能体，这里有一长串它能做的事情，而且没有人类去读这些指令。”
Sarah Sachs: 对于我来说，我很快学到并欣然接受的一点是：我的工作不是成为那个提出所有点子的人，也不是成为技术专家。我的工作是确保每个人都理解目标，提供资源帮助他们确定优先级，并为他们认为重要的事情提供优先级通道。我认为这适用于所有的领导岗位，但在 AI 团队尤为明显。
我们几乎所有最棒的点子都来自于原型（Prototypes），来自那些因为看到了用户痛点而萌生酷点子的人。如果所有这些点子都必须通过我和产品合伙人，或者 Simon 和 Ivan（Notion CEO）的“嗅觉测试”来决定方向，那将是一种巨大的帮倒忙。因为我们做的很多事情都是在探索能力的边界。
所以首先，我并不认为工程领导的角色是自上而下的层级结构。尤其是在现在，我们需要非常愿意根据实际效果来改变方向。我们大概重构了我们的运行框架（Harness）三四次。当你这样做时，工程领导的第二条准则就是：你需要建立一个乐于删掉自己写的代码、极度低自尊（Low ego，指不居功自傲）、一切以公司利益为导向的团队。他们写设计文档不是为了晋升。这种文化在加入之前 Notion 就已经存在了，我们愿意群策群力解决不同问题，并在情况发生变化时重做以前做过的东西。在很多公司，这样做会产生巨大的摩擦，但在 Notion 不会。当新人加入时，他们不会因为“那段代码是我写的”就阻碍改变。这种文化的形成，我认为直接归功于 Simon 和 Ivan，因为他们非常思想开明。
Swyx: Simon，你有什么要补充的吗？
Simon Last: 我不像 Sarah 那样是个管理者。我的角色更多是试着超前思考一点，确保我们建立在正确的能力之上，以及做原型开发之类的事情。总是从头开始是非常关键的。比如，“这是一个新东西，这意味着什么？如果我们重新思考一切或重写一切会怎样？”基本上，我每六个月就会在这样一个循环里重复做这件事。
Swyx: 你们相信在这个领域搞内部黑客松（Hackathons）吗？
Sarah Sachs: 我觉得这里有两种不同的情况。一种是，我们有一批非常坚实的资深工程师，他们会在所谓的“Simon旋涡（Simon Vortex）”以及产品化阶段进进出出。当你处于“Simon旋涡”时，开发速度极高，方向每天都在变，这其实就相当于一个臭鼬工厂（Skunk Works lab）。对于这种模式，我们不需要搞黑客松。我们需要的是我们信任的资深工程师能够灵活地加入和退出这些项目。比如，管理边界非常松散——你向他汇报，但你现在为她工作。我们在招聘管理者时，非常看重他们不介意这种模式，因为我们的架构是非常灵活的，通常是在功能发布后才固化结构，而不是在之前。
第二点是，我们确实会举办全公司范围的黑客松。实际上，我们今天早上刚刚举办了上周黑客松的 Demo Day。这更多是为了让那些没有直接参与核心 AI 项目的人，觉得他们有时间停下来，学习如何让自己变得更高效，或者学习如何使用 Notion 自定义智能体来构建一些东西。这次黑客松的一部分内容，其实是鼓励全公司所有人从零开始构建自己的智能体工具调用循环，可以跟着任何一篇博客文章来做。
Swyx: 这有点像复合型工程（Compound engineering）理念。
Sarah Sachs: 是的，我们希望公司里的每个人都能使用 Claude Code 或任何他们喜欢的编程智能体，去理解这些基本原理。所以我们留出了一天半的时间，所有领导层都鼓励自己团队的人去参与。所以我们有这类黑客松。不过开个玩笑说，我们构建的所有东西，在它正式“毕业”、穿上大人衣服、配备产品运营推广负责人、分配数据科学家之前，都有点像黑客松产物。
Swyx: 还有安全审查、企业级合规之类的。
Sarah Sachs: 实际上，安全团队是我们最早引入的环节之一。因为如果不早点引入，后期会极大拖慢我们的速度，引发很多矛盾。如果他们尽早参与，我们能打造出更好的产品。
Swyx: 这是很标准的公关式回答哦。
Sarah Sachs: 不，这不仅仅是公关说辞，这是真实的经历。
Swyx: 我懂，这都是过往留下的“伤疤”。
Sarah Sachs: 我之前在 Robinhood 工作了好几年。所以关于合规这些事情，如果它没有成为自然而然的流程，你是会吃大苦头的。
Simon Last: 我觉得黑客松对于提升全体员工的认知非常重要。但是，如果这是你构建新东西的唯一方式，那你们就完蛋了。它必须融入到日常流程中。在 AI 时代，拥有最强好奇心和热情的人将掌握巨大的杠杆效能。我们就是要激发这种能量。如果有人在周末研究一些他们感到兴奋且重要的东西，那这应该成为我们正在做的主要事情，而不是一季度才安排一次的黑客松。它就是日常流程，是文化的一部分。
Sarah Sachs: 我们在 Notion 里发布图像生成功能就是这么来的。这曾经是一个我们觉得“有也不错”的功能，但在产品优先级里并不明确，而且要做的话工作量很大。我们数据库集合团队里有个叫 Jimmy 的员工，他说：“我真的很想在 Notion 里做用于封面照片的图像生成功能。”我们说：“如果你想做，拜托一定要做！我们全力支持你。”我们为他提供了所有资源，让他直接与 Gemini 合作，跟踪 Token 使用情况，提供终端支持，提供测评（Eval）支持等一切条件，然后这就变成了一个完整的项目。这就是为什么作为领导者你不能有自我包袱（Ego），这就是我们的工作方式。
Alessio: 目前团队的规模有多大？包括工程团队和整体规模。
Sarah Sachs: 我管理的团队叫做“核心 AI 能力与基础设施团队”，大约有 50 人。但我们有对接的合作团队负责产品打包，比如它在侧边栏聊天框、自定义智能体或会议笔记中如何呈现，那又是另外 30 到 40 人。
而且，任何在 Notion 负责面向用户产品界面的团队，都拥有智能体将要调用的工具接口。比如编辑器团队，那个负责离线模式 CRDT（无冲突复制数据类型）的团队，同样也是处理两个智能体如何编辑竞争区块（Blocks）的团队，这本质上是同一个问题。构建底层 SQL 引擎的团队，同样负责让智能体能够高效地请求执行 SQL 查询。
从这个角度看，任何从事产品工程的人员，现在都被赋予了既为人类客户也为智能体客户构建功能的任务。因为随着时间的推移，我们界面的大部分流量将来自使用它的智能体，而不是人类。我们的目标是让整个产品组织都在为智能体进行构建。
Alessio: 这在内部带来了哪些变化？启动门槛是不是降低了很多？现在任何人似乎都很容易创建一个原型，尤其是在你们现有的代码库中。你们是否提高了人们提交原型的标准？
Simon Last: 是的，门槛在很多方面都降低了。我们的设计团队做了一件很酷的事，他们建了一个独立的 GitHub 仓库，叫做“设计游乐场（Design Playground）”。里面包含了很多辅助组件，你可以用它们快速拼凑出 UI，它变得相当复杂，里面甚至有智能体。所以，他们现在基本不画静态的线框图了，他们直接做完整的交互原型。他们会给你一个 URL，说“看，它跑起来了”。然后我们就得想办法把它变成真正的生产版本。对于工程师来说，原型的门槛就是通过功能开关（Feature Flag）把它做出来，而且能实际运行。
Sarah Sachs: 关于 Notion 有一个非常独特的地方，也是我加入的原因之一：没有任何人能像 Notion 自己的员工那样，在工作中如此高频地使用 Notion。
Simon Last: 当然。
Sarah Sachs: 我们发布的任何功能，都会先在内部上线，并获得大量快速的反馈。当然，有时候我们的开发实例会完全崩溃，你不得不修改一堆开关才能完成工作。但不管是做 IT 工单的、做供应链采购的、还是做招聘的，公司里的每个人都在使用同一个开启了各种原型测试开关的 Notion 实例。我们团队的设计师 Brian Levin 推广了“演示胜于文档（Demos over memos）”的理念。这对构建原型非常有帮助。
但这也对我们提出了更高的要求，我们需要有非常坚定的产品信念。因为如果任何东西都能做成 Demo，你就真的需要一个强大的过滤器，确保你在做的工作是专注于攀登一座高峰，而不是在平地上摊大饼。这其实要求我们的 PM、设计师以及整个公司对我们要走的用户旅程有更坚定的信念。
Simon Last: 总体来说，我觉得效果很好。几乎所有的工程师都有足够的品味去判断一个原型在产品中是否合理。所以我很少看到那种让人觉得“这完全没道理”的原型。大家做的都是合理的事情。接下来的问题就是决定先做什么，以及如何做好功能的开关控制。在我们实验性的聊天 UI 里，可能有上百个复选框来控制不同功能的开启或关闭。
Sarah Sachs: 那真是要了我的命（笑）。不过，从管理测评（Evals）团队的角度来看，这确实给平台团队增加了一层压力。比如，如果我们要上线图像生成功能，那么我们处理附件的方式、LLM 的补全逻辑、Token 消耗的处理方式都需要调整，因为现在它返回的是图像了。我们需要夯实很多平台级别的工作。所以有时候功能在开发环境中待了几周才能上线生产环境，因为我们还得保证它的健壮性，确保它符合 HIPAA 合规要求、ZDR（零数据保留）合规要求，还要弄清楚如何与供应商签约等等。
更重要的是，我们需要对其进行测评（Evals），因为我们希望开发团队能够维护他们构建的东西。如果我们有一堆原型，不能总是指望一小群人来维护所有的东西。所以我们在测评和理解模型行为的团队上投入了大量人力。我们称之为“智能体开发提效（Agent Dev Velocity）”。如果你投资这个平台，你开发智能体的速度就会更快。我们专门有一个组织致力于提升智能体平台速度，这样你就可以构建自己的测评用例，并在发布后进行维护。比如当新模型发布时……
Swyx: 每个团队维护自己的测评用例？
Sarah Sachs: 我们维护测评框架。每个团队拥有自己的测评用例，很多都集成到了 CI（持续集成）中，或者我们会每晚运行。我们有一个自定义智能体，当发现重大失败时，它会触发警报通知相关团队查看。这非常关键。因为我们现在有很多不同的产品界面，虽然大部分运行在同一个底层框架上（只是打包方式不同），但当智能体有新功能时，比如 Anthropic 弃用了 Claude 3.5 Sonnet 或者某个模型，我们需要自动更新。
Swyx: 他们已经弃用了吗？时间过得真快。
Alessio: 对，是 3.5。
Sarah Sachs: 是 3.5，3.7 刚发布。5.2 版……如果 OpenAI 弃用 GPT-4.0（注：此处为闲聊玩笑），你会从我这听到抱怨的，因为 5.4 比 5.2 贵 40%。不过这是另一个话题了。
Swyx: 我有个关于测评的犀利问题。你们有没有注意到各大模型供应商有任何暗中的性能下降（Secret degradation）？比如在流量高峰期，模型突然变笨了？
Sarah Sachs: 是的。我们绝对注意到了不稳定。我们明确发现，特别是对于某些供应商，在工作时间段响应速度会变慢……
Swyx: 这是延迟问题。我说的是质量问题。
Sarah Sachs: 关于质量差异，有一点很有意思：即使供应商声称通过第一方或者通过 Bedrock、Azure 提供了同一个模型，我们有时确实会看到质量上的差异。这涉及到量化（Quantization）的问题，模型质量并不总是像广告宣传的那样。
Swyx: 是的，比如之前在某些平台上，同样的测试集跑出来的结果明显不同，这就很尴尬。
Sarah Sachs: 我们会聘请第三方（Subprocess）来帮我们弄清楚这些。我们想了解模型在哪里退步了，在哪里优化了。有时候，如果退步是为了换取更低的延迟，且退步发生在我们认为合理的范围内，我们也是可以接受的。我们的工作是确保拥有测评手段，去理解那些对我们来说至关重要的变化。
即使是我们在与前沿实验室合作测试预发布模型时，他们也会发送多个快照（Snapshots）给我们。他们发布的模型有时并不是我们想要的那个快照版本，他们也会根据我们的反馈修改模型。因为我们的反馈往往更侧重于企业办公场景，而不是编程场景。
Alessio: 你们有没有遇到一些失败的测评用例，是你们寄希望于未来出现更好的模型时就能自然通过的？
Sarah Sachs: 我们可以就这个聊上 60 分钟。我觉得当人们提到“测评（Evals）”时，如果仅仅把它等同于质量测试或单元测试，那是个大问题。我们有等同于单元测试的回归测试，在 CI 里运行，必须达到特定的通过率。当我们构建产品时，还有发布质量的测评。我们有一份“成绩单”，在所有用户旅程类别中，必须达到 80% 或 90% 的及格率才能发布。
然后，我们还有所谓的“前沿或天花板测评（Frontier/Headroom evals）”，对于这类测评，我们主动希望它只有约 30% 的通过率。这其实是我们在过去两三个月里与 Anthropic 和 OpenAI 合作的一项工作。因为我们到了一个阶段，发现我们的测评指标已经饱和了，除了能告诉实验室“它没有变差”之外，无法提供更多有见地的反馈。这不仅对合作伙伴没帮助，对我们了解“河流”将流向何方也没有帮助。所以我们花了很多时间思考，Notion 的“终极考试（Last Exam）”应该是什么样的。关于这块我们内部有专门的全职团队，包括一名数据科学家、一名模型行为工程师，以及一名专门负责那些只有 30% 通过率测评的全职工程师。
Swyx: 你在招聘 MBE 吗？什么是 MBE？
Sarah Sachs: MBE，全称是“模型行为工程师（Model Behavior Engineer）”。在我加入之前，这个角色叫数据专员（Data Specialist）。当时 Simon 只需要有人看电子表格，告诉他“这个看起来很糟，那个看起来不错”。所以我们聘请了背景非常多样的人，比如语言学博士辍学生、斯坦福大学的新毕业生。他们非常棒，基本上开创了一个新的职能。随着时间推移，我们建立了一个完整的团队。现在有了专门的经理，正在重新定义这个角色在应对编程智能体时代时的职责。
他们过去主要是在手动检查代码。现在，他们主要在构建能为自身或 LLM 裁判（LLM Judges）编写测评用例的智能体。大约一年半前，有一天 Simon 在白板前教他们如何使用 GitHub，因为他觉得如果数据专员学会用 GitHub 提交代码会快得多。到了今天，写代码的门槛已经变得非常低。这个角色的未来，更像是数据科学家、PM 和提示词工程师的结合体。因为你需要理解模型能做什么、不能做什么，去定义什么是“天花板”，定义什么是好的用户旅程。这个模型是否更好？为什么失败？这其中有很多定性分析、直觉和品味，而这并不纯粹是软件工程。我们坚信这是一条独立的职业路径，我们一直欢迎那些“非传统背景”的人才。你不需要有工程背景就能成为这方面最顶尖的人，这是这个角色非常独特的地方。
Simon Last: 这也是我最近非常兴奋的一点：我们努力把测评系统打造成一个智能体运行框架（Agent Harness）。你可以想象，一个端到端的智能体，能够自己下载数据集、运行测评、针对失败项进行迭代调试，最后实现修复。最终，你只需要让一个人类去观察这个外层系统，就能驱动全职的研发流程。我们在这个方向投入很大，目前效果非常好。这基本上把它变成了一个编程智能体的问题。
Swyx: 你是说用你们自己的编程智能体，还是任何运行框架？
Simon Last: 是通用框架，可以用 Claude Code 等等。把它绑定在任何特定的编程智能体上都是错误的。归根结底，它们只是各种 CLI（命令行）工具。
Sarah Sachs: 就像你会让编程智能体写单元测试一样，你也应该让它写测评用例。但这其中仍然需要大量的监督。只是我们认为这种监督不一定非得由软件工程师来做，因为其中很大一部分是用户体验（UX）的分析。正是这些人对失败进行分类，并告诉我们下一步应该在哪里投资。
Swyx: 我要问个犀利的问题：Notion 内部是不是没有软件工程师了？
Simon Last: 那要看你对“软件工程师”的定义是什么了。
Swyx: 正是如此。
Simon Last: 我觉得事情的走向是，我们正处在一条连续的轴上。三年前，人类在敲所有的代码；然后我们有了自动补全，你少敲了一点；然后我们有了帮你补齐一行或多行的智能体；现在我们进入了智能体执行长流程任务的阶段——它们可以调试、实施修复、验证有效性，甚至自动提交 PR 和部署。我们正在抽象的阶梯上不断攀升。人类的角色更多变成了观察和维护这个外层系统。看着一连串的智能体跑通流程、提交 PR，判断什么地方偏离了轨道，我需要批准什么，有没有学习或记忆机制在起作用。这依然是一个硬核的工程问题，只是我们在往更高的技术栈移动。
Sarah Sachs: 就像机器学习工程师经历过的转变一样对吧？我已经很久没看过精确率-召回率曲线（PR Curve）了。过去是你自己做这些事，现在自动化研究工具能做了。所以这取决于你如何定义软件工程师。
Swyx: 是的，角色正在发生变化。
Sarah Sachs: 我觉得今年夏天 Notion 里的每一位软件工程师都经历了一种“身份认同危机”。公司的一位工程负责人形容说：每个软件工程师都在经历每个新经理都会经历的危机——他们突然意识到，自己写代码的能力变得不如委派任务和切换上下文的能力重要了。我认为这是从传统软件工程师角色的一种过渡。
Simon Last: 这里和做经理有一个关键的区别，那就是它仍然是非常底层的、极度技术化的工作。人类是很模糊的，你不能像管理一个严密的系统那样去管理一个由人组成的团队，比如处理被阻塞的 PR 该走什么流程。但对于一群智能体，你确实可以把它当作一个严密的系统来设计。我认为这涉及到很多有趣的工程严谨性，最终它是一个技术设计问题。
Alessio: 你们正在构建的这个“软件工厂（Software Factory）”的设计是什么样的？
Simon Last: 我们在尝试很多不同的东西。最终，你想要设计一个需要尽可能少的人类干预的系统，但同时要维持你所关心的那些系统不变量（Invariants）。我觉得有几个组件非常重要。首先，有一个可以通过提交 Markdown 文件来完成的“规范说明层（Specification Layer）”。这非常有效。
Swyx: 用 Notion 真是太爽了，我是说，规范说明天然的家就是 Notion。
Simon Last: 对，它可以是一个页面数据库。它必须是人类可读和可查看的，这非常关键。另一个非常关键的组件是自我验证循环。你基本上需要非常好的测试层，这是一个很深的技术问题。当你把这个做对了，剩下的就是工作流的问题：当出现 Bug 时会怎样？它是如何流入系统的？是否有子智能体在处理它？它如何提交 PR，谁来审查？
Swyx: 酷。在你们来之前，我们确实做了一个智能体的演示。因为我们每做一期节目都会试用相关产品。
Alessio: 这是为 Kernel Labs（我们所在的孵化空间）做的。下周我们将开放租户申请，所以我们弄了一个网页表单。在以前，工作流是：我收到一封邮件，然后我看看这个人，心想“我应该花时间和他聊聊吗？”然后我回复，他们再回复。现在我建了这个智能体。它的名字是它自己想出来的。你们是如何让它自己想出名字的？
Simon Last: “Resilient Collector（韧性收集者）”？这个名字很贴切。这其实是一个随机名字生成器。它能挑出这个名字真的挺搞笑的。
Sarah Sachs: 我从来没看过那部分代码，没去质疑过。我觉得它有点像个填词游戏。
Simon Last: 不过，如果你让 AI 来设置它自己，它可以更新自己的名字。
Alessio: 我就直接在聊天框里跟它说：“检查我的收件箱，寻找共享办公空间的申请。帮我留意合适的人。”然后它为我创建了数据库（在 Notion 里就是表格）。每当有邮件进来，它就会为那个人新建一行。接着它通过网络搜索来丰富这个人的资料档案，搜索这人是谁，填上他们希望入住的时间等等。这虽然不是 AGI，但我终于不用再做这些繁琐的工作了。我大概只花了 15 分钟就设置好了这一切。而且我非常喜欢它把所有信息都保留在 Notion 里，而不是让我把数据搬到别的工具去。
Sarah Sachs: 我们最大的应用场景和收益，正是来自于在流程中去除了人类介入的那多出来的一层。比如我们最大的应用场景之一是 Bug 分发（Bug triaging）。有人在 Slack 里发了问题，你能不能让一个自定义智能体驻留在那，根据它内置的路由规则判断这个问题属于哪个团队，在任务数据库中创建任务，然后回复那个 Slack 频道？这是我们内部最早构建的工具之一，它彻底改变了 Notion 作为一个公司的运转方式。没有东西会从缝隙中漏掉，它不是在取代人，而是在取代繁琐的流程。
Alessio: 我很好奇你们是如何看待这些智能体的可组合性（Composability）的？我做的另一个智能体是用来填租约的。如果有新租户签约，它帮他们生成租约。这可能需要一个“办公室经理智能体”来处理请求、起草租约，然后给他们办公楼的门禁权限。你们怎么思考这个特性？
Simon Last: 有两种组合方式。一种是通过数据原语进行组合：你可以让一个智能体向数据库写入数据，另一个智能体监视这个数据库。这种方式解耦得比较好，运行得很顺畅。另一种方式是让它们直接耦合。我想这个功能可能下周就要发布了——在智能体的设置里，你可以赋予它调用任何其他智能体的权限。这样它们就可以直接对话了。
Swyx: 有没有限制递归调用的次数？不然很容易陷入死循环。
Simon Last: 应该是有的。
Swyx: 稍不留神就会变成“无限制造回形针”的失控局面。
Simon Last: 哈哈，这功能非常有用。前几天我在内部帮一个人，他为我们的 GTM（走向市场）团队建了 30 多个自定义智能体，做各种不同的事情，比如客户调研、整理反馈等。他甚至做了一个所有智能体的数据库。然后他说：“我现在每天收到 70 多条通知，全是因为各个智能体卡在了某些环节。”我当时就说：“哦，这很明显，你应该建一个‘经理智能体（Manager Agent）’。”这就等于在你的 30 个智能体之上增加了一个抽象层。这个经理智能体拥有调用所有其他智能体的权限，它可以观察它们。这样你每天收到的 70 条通知就变成了 5 条。经理智能体还能帮着调试和修复其他智能体的问题。
Swyx: 这其中是否有类似“收件箱”的概念？你基本上是说它们可以互相发消息？
Simon Last: 我们没有创造任何特殊的概念。它们使用的记录系统就是 Notion 本身。它们可以往另一个智能体正在监听的数据库里写一条任务，或者直接调用另一个智能体的 Webhook（相当于@那个智能体）。
我们通常的做法是，先让一件事变得可行，哪怕一开始的方式有点简陋。比如，我们创建了一个记录自定义智能体遇到的“问题（Issues）”的数据库，给所有智能体写入问题的权限，然后给经理智能体读取问题的权限。这就像是给智能体建了一个内部的 Issue 追踪系统。如果这被证明是一个有用的概念，我们以后也许会把它封装成标准化功能。但总的来说，我们尽量坚持用现有的原语进行组合。
再举个例子，我们没有内置的“记忆（Memory）”概念。记忆对我们来说就是页面和数据库。所以如果你想赋予它记忆，只要给它一个页面，给它编辑权限就行了。这种模式非常管用。
Alessio: 当我设置这个时，我连接了收件箱，系统问我想用 Gmail 还是 Notion Mail。我当时想，我哪个都不想用，我只想让你去把事情办了。我很好奇，你们是如何在 Notion Mail、Notion Calendar 这些完整的 UI/UX 界面应用，与这种在后台把界面抽象掉的智能体之间分配产品研发精力的？
Simon Last: 我们觉得很重要的一点是，你不必非得使用 Notion Mail 才能连接邮件能力。你可以连接 Gmail 或任何你想用的服务。我们将 Notion Mail 视作一个从底层开始就是为智能体打造的优质服务，也许它的邮件 App 形态只是一个预先打包好的智能体，用来帮你自动化处理收件箱。
Sarah Sachs: 当我们集成 Gmail 时，我们通过 MCP 或 API 向 Gmail 提供一系列工具。而当我们集成 Notion Mail 时，我们有 Notion Mail 的工程团队为我们构建完全契合、在延迟和质量上都做到最优的工具，他们有专门的 PM 在思考邮件场景下的用户痛点。所以，当构建集成连接时，我们倾向于优先在内部原生构建，然后再考虑如何推广给外部系统，因为原生构建总是更容易。
Swyx: 既然你提到了集成，我必须得问了：MCP（模型上下文协议）和 CLI（命令行接口），你们到底是怎么看的？
Simon Last: 我非常看好并对 CLI 感到兴奋。CLI 有几个非常酷的地方：它运行在终端环境中，获得了许多额外的能力，比如它可以对长输出进行分页和光标控制；它天生具有渐进式呈现（Progressive disclosure）的特性，你不会一次看到所有工具，你只看到 CLI 外壳，可以使用帮助命令读取文件。最酷的一点是，它是天生支持自我引导和自修复的。如果出现了问题，智能体可以在使用工具的同一环境中自我调试和修复。
我今早看到一条推文，有人说“我的智能体没有浏览器，所以我让它写一个调用工具，用不到 100 行代码，它就给自己弄了一个基于 Chromium API 的小浏览器。”这太不可思议了！如果出现 Bug，它会立刻尝试去修复。
相比之下，如果你使用 MCP 提供 Chrome 开发者工具，我遇到过传输层出错的情况。一旦出错，智能体就没有办法自我修复，它失去了浏览器，就彻底罢工了。虽然我觉得 MCP 存在的一些缺陷是可以修复的，但我总体上非常看好 CLI。
当然，我在某些特定环境下也依然看好 MCP。特别是在你想要一个窄领域的、轻量级的智能体时。有很多场景你并不需要一个带有完整计算运行时的编程智能体，而且你需要非常严格的权限控制。MCP 天生具有强大的权限模型：你能做的就是调用暴露给你的工具。而 CLI 的权限边界比较模糊：我能访问 API Token 吗？你能确保安全地加密 Token 不被窃取吗？这引入了很多真实且难以解决的安全问题。MCP 是一种“傻瓜式简单”但很有效的方案。
Sarah Sachs: 我补充两点。第一，Notion 致力于成为人们进行企业级工作的最佳核心系统。所以只要有人在使用 MCP，我们就会始终支持我们的 MCP。我们有一支非常棒的团队正在这方面投入。第二点，我最近一直在思考如何让功能的价值与定价模型对齐。
用语言模型去执行确定性的任务，是对资源的浪费。让语言模型去和第三方提供商对接那些根本不需要语言模型参与的任务，也是一种浪费。特别是由于我们的自定义智能体采用基于用量的计费方式（Usage-based pricing），我们把定价看作使用产品的门槛，我们非常有责任确保这不会产生浪费。不仅因为这对客户不划算，这对业务本身也不利。我们希望客户只为真正的价值买单。
如果我们的智能体能够生成代码，在 CLI 环境中确定性地执行，那这就是一次性的成本。相比之下，让语言模型不断地通过 MCP 集成、反复支付 Token 费用，而且这些都发生在缓存窗口之外，这不仅昂贵，而且缺乏确定性。
Alessio: 是的，开放性是一个关键点。如果我只是写代码去调用一个简单的 API，我绝对不会用 MCP。但有时候当你明确知道要调用什么，又不想让模型每次都从头开始执行代码时，MCP 就很有用了。我很好奇，你们在内部是如何做决策的？什么时候应该直接调用 API，什么时候用 MCP，什么时候用极其开放的沙盒编程智能体？
Sarah Sachs: 在 Notion AI 内部，通常是因为我们想要对质量有更深度的控制，所以我们会选择不使用 MCP。搜索（Agentic Find）就是最大的一个例子。我们的智能体可以跨 Slack、Linear、Jira 和 Notion 进行搜索。我们没有单纯使用那些公司提供的 MCP 搜索功能，因为我们认为想要掌控智能体的搜索轨迹（Search Journey）质量，我们需要对搜索过程有更多的控制权。
这往往是出于对质量的要求。当然，存在长尾的工具需求，这就是为什么我们构建了一个 MCP 服务器，以便人们可以连接任何他们想要的东西。但对于核心搜索，它是用户的主要入口，还有一些其他的核心连接，我们愿意自己承担更多的开发工作来保证体验。
Simon Last: 我觉得这并不是非此即彼的冲突，它们只是技术栈中不同的抽象层。MCP 是一个非常棒的开放协议，能让你获取访问工具的权限，处理长尾需求非常合适。但比如“触发器（Trigger）”，MCP 就做不到。如果你打开我们自定义智能体的设置，你会看到“触发器”选项，这部分协议是没有的，我们必须自己构建。所以，像 Linear 和 GitHub，我们使用 MCP 集成。但对于 Slack、Mail 等，我们是内部原生构建的，花了很多时间微调工具以确保极致体验。我们只需要在合适的时机使用合适的底层技术。
Alessio: 你们内部有一个关于这些工具的规范化抽象层吗？把 MCP 和自建工具统一包装起来？
Simon Last: 是的，我们内部有对于什么是“工具”、什么是“智能体”、什么是“补全调用”的抽象。
Sarah Sachs: 我们甚至有针对聊天原型的抽象，无论是来自 Teams 还是 Slack 的对话，都有统一的抽象处理方式。
Swyx: 这是一个可能有点过分的要求，但我想试试。你们多次提到，这个功能经历了四五次重构。你能简短回顾一下每次重构都在做什么吗？
Simon Last: 当然，我可以试试。这其实很有意思。
第一版（2022 年底）：那实际上是一个编程智能体。我们想，别做工具了，让一切都变成 JavaScript，给它 API 接口，让它自己写代码去调用。但当时模型写代码的能力太烂了。
第二版：我们转向了工具调用抽象。当时业内还没有原生的 Function Calling，所以我们创造了一套完整的 XML 格式方案。最大的教训是：我们过度迎合了 Notion 的数据模型，而忽视了模型真正想要什么。我们做了一个能够无损映射成 Notion 区块（Blocks）的 XML 格式，但效果很糟，因为模型根本不懂这种自定义的 XML，而且极度消耗 Token。
第三版：我们意识到必须用 Markdown，因为模型懂 Markdown。所以我们搞了一个“Notion 风格的 Markdown”，不追求无损转换，只要核心是简单的 Markdown 并加以增强即可。这是一个大进步。
第四版：我们对数据库层进行了同样的改造。Notion API 查询数据库时使用的是一种极其复杂的 JSON 格式。我们废弃了那个做法，决定把所有东西都当作 SQLite 数据库来处理。你可以像写 SQLite 查询一样去查询它。模型在写 SQL 方面简直是专家！所以核心理念就是：给模型它想要的东西，尽量不要向它暴露你系统内部不必要的复杂性。
第五版：这与渐进式呈现（Progressive disclosure）有关。在最新版本的智能体中，仅处理 Notion 的各种复杂操作就有一百多个工具。如果把所有工具的描述都塞进 Prompt 里，一方面 Token 消耗极其庞大，导致响应非常慢；另一方面会带来质量问题，任何工程师添加一个小众工具，都可能因为模型被误导而削弱整体性能。所以我们重新设计了运行框架，让它能够优雅地实现工具的渐进式展开。
Sarah Sachs: 我想补充一点，这也是一次重大的效率飞跃。当我们从“少样本提示（Few-shot prompting）”转向定义工具的目标（把系统从一个静态的 DAG 转变为有反馈的动态系统），我们就能更好地将工具的所有权分配给各个业务团队。
以前全是少样本提示时，大家都在争相编辑同一个长字符串（System Prompt）。有很多论文指出，提示词顺序很重要，越靠前模型越听。我们当时花费巨大精力去对抗排序和样本选择。这导致这部分工作成了一个高度集中的瓶颈，只有五六个人被允许修改那部分代码。
现在有了更好的测评体系，我们可以把定义工具的工作分发下去。有时会出现疯狂的情况：两个团队写了名字相同的两个工具，导致智能体崩溃。有趣的是，Claude 3 Sonnet 无法处理同名工具，但 OpenAI 的模型却能自己弄明白。
这不仅解放了模型能力，也让我们内部的研发速度实现了规模化扩张。过去那个掌握“唯一系统提示词文件”的卓越中心团队，一夜之间转型成了平台团队，这也是一次巨大的内部转变。
Swyx: 你们会公开这些工具列表吗？这是机密吗？
Simon Last: 完全公开。你直接在聊天框问智能体就行了，它会告诉你的。我们不认为我们的系统提示词是我们的核心秘密。我们并不想隐藏工具。实际上，作为高级用户，你有权审视系统是如何运作的：它有哪些工具？它们是如何工作的？我该如何提示它更好地使用这些工具？
Sarah Sachs: 实际上，我们并不试图让它的使用门槛降到最低。因为我们越是这样做，就越会抽象掉 Simon 提到的那种“可解释性”，这反而会削弱模型或智能体的能力。在构建自定义智能体时，我们团队达成的最关键共识就是：我们不是在为所有人构建这个功能。如果我们试图打造一个傻瓜式的用户体验，那只会削弱它的能力。当我们全员达成共识，专注于为高阶操作者服务时，我们的开发速度立刻就提上来了。
Alessio: 这个用来生成元提示词（Meta-prompt）的逻辑是怎么运作的？我看到系统提示词里规定它要使用 Emoji，这显然不是默认行为。
Simon Last: 这其实就是智能体自己在做。我们在自定义智能体中做了一件我很喜欢的事，那就是它能够“自我设置”。我们不仅给了它发送邮件等执行任务的工具，还给了它设置自身和调试自身的工具。所以当你要求它写系统提示词时，是你的智能体自身在帮你完成。
如果你关闭设置面板，你会看到聊天界面。我们管这叫“Flippy（翻转）”。过去，设置页面是主界面，聊天测试在旁边。但拥抱 AGI 理念的思考方式是：一切都应该是智能体。它可以设置自己、测试自己、运行工作流。所以我们翻转了主次：主视图是聊天，设置面板只是用来预览它做出的更改。我们希望你能通过与它对话完成所有的设置。
Sarah Sachs: 顺便说一下，为了实现这种体验的转变，其实是我们发布该功能前遇到的最大阻碍。因为这改变了早期测试用户已经习惯的设置流程。为了解决这个问题，我们从三个不同的团队抽调了三名工程师组成突击队，大家毫无怨言地完成了工作并顺利发布。
Alessio: 在对话里直接让它修复自己真是太棒了。现在这个功能还在免费期，非常好用。但我开始担心收费后会怎样。你们如何设计基于价值的任务定价？Notion Credits（额度）是如何与底层 Token 剥离的？
Sarah Sachs: 我们之所以不能仅仅根据 Token 吞吐量来计费，是因为背后的成本并不总是这样计算的。我们的微调模型和开源模型是在我们自己的 GPU 上运行的；网络搜索的计费方式不同；未来的沙盒托管成本也不同。所以我们需要一个高于 Token 的抽象概念，也就是 Credits（额度）。而且，不同模型的服务层级（优先处理、异步处理）、缓存命中率都不同。
我们的初衷是确保客户得到公平的交易。我们不是想借此大捞一笔，而是希望用户为合理的服务付费。作为一款企业级 SaaS，抽象出 Credit 包也让我们的销售流程更容易运作，企业买得多可以有折扣。
另外，并不是所有的知识工作都具有相同的价值。这其实是我们采用基于用量计费的最大原因之一。如果用户想要让最昂贵的模型（比如 Opus）去自动分类每一封邮件，或者在每一个数据库单元格里运行，那将耗费数十亿美元，甚至会让公司破产。我们需要找到一种方式，让那些愿意为了高级能力付更多钱的客户有一个出口，同时又不需要把这种高成本强加给位于需求曲线底端的用户。
我们会通过产品内的小提示告诉用户某项任务是否昂贵或缓慢。因为大多数自定义智能体是异步运行的，用户其实不太关心速度。因此，激励用户做出最适合自己的选择的最佳方式，就是让他们用自己的钱投票。
Swyx: 对于不熟悉的人来说，打开模型选择菜单可能会很困惑。没有 Claude 3.5 Sonnet，只有 Auto。这怎么选？
Sarah Sachs: “Auto（自动）”模式是我们目前投入巨大精力的地方。我们要说服用户：“Auto”不仅不是我们为了省钱用的最笨的模型，它反而是最适合你当前任务的模型。就像现在的理财市场，你可以自己盯盘，也可以买指数基金或用智能投顾（Robo-advisor）。我们在某种程度上就是智能投顾：我们有一大批人专门研究哪个模型最适合哪种任务。我们不是用“Auto”来赚取差价，我们只是用它来减少用户的选择压力。对于绝大多数任务来说，你根本不需要 Opus 级别的智力。
Simon Last: 与前沿实验室不同，我们没有任何动机去诱导你消耗尽可能多的 Token。我们非常希望为你提供最合适的工具。很多时候，最合适的工具其实是让智能体直接写一段代码去跑，甚至根本不需要调动语言模型进行复杂推理。我们非常乐意看到智能体能通过自动化把自己“优化”掉。
Sarah Sachs: 对此我深有感触。前沿实验室目前并没有强烈的动力去满足市场所有层级的需求，他们只是变得越来越强、越来越贵。这对解决 Notion 上的复杂任务是好事。但问题在于处于中间地带的需求——那些“推理模型半年前的能力水平”。因为现在没有足够的低成本模型去完美填补这个区间，导致我们和客户为了并不需要的多余能力支付了过高的溢价。
所以我们正在做大量工作来保持选择模型的灵活性，并大力投资开源模型（比如 MiniMax），因为它们正在达到推理模型几个月前的水平。我们希望填满由“智能水平、价格、延迟”组成的那个能力三角，为用户提供最具有性价比的选择。
Swyx: 听起来，总有一天你们会自己训练一个基础模型？
Sarah Sachs: 不，我们没有钱去训练一个前沿基础模型。那不需要成为我们的核心竞争力。
Simon Last: 训练模型太诱人了，我个人曾在尝试训练模型上烧掉了大量时间。但后来我意识到，这是一个陷阱。你应该把模型看作一个实现细节。核心问题是你的“外层循环（Outer Loop）”是什么？模型加上运行框架，与系统进行交互。当出现问题时，解决办法通常不是去训练一个新模型，99% 的情况下只是某个工具里有 Bug。直接修复那个 Bug 就行了。所以，更具成效的思考方式是：如何通过打造更好的工具、更好的运行框架和测评系统，来提升我们的开发速度和系统鲁棒性。
如果我们真的要做某种训练，我最感兴趣的领域是：针对企业客户的极度个性化的微调。当技术允许时，训练一个真正了解你们公司运作方式、了解公司员工及其上下文的模型，我认为这会带来巨大的质量提升。
Sarah Sachs: 我们现在更多将模型优化的精力投入到了检索（Retrieval）领域。因为在我们的 AI 订阅计划中，当前搜索负载和流量的大部分来自智能体，而不是人类。智能体构建查询的方式不同，返回结果的要求也不同。对于智能体来说，绝对的排序位置可能不那么重要，但 Top-K（前 K 个结果）的质量至关重要。
我们正在重新思考针对智能体的搜索，不仅仅是查询生成，还包括建立不同形式的索引。因为像“自定义智能体的设置生成器”或者“会议笔记”这样的东西，完全打破了我们传统的“区块嵌套（Block）”数据模型。所以，我们确实在招聘排序（Ranking）工程师和模型训练工程师，但主要是专注于检索排序领域的。
Swyx: 排序（Ranking）在你们这里等同于推荐系统（RecSys）对吧？
Sarah Sachs: 是的。目前对于 Notion 的检索来说，向量嵌入（Vector Embeddings）的重要性在下降。我们刚做过实验，重点转移到了并发穷举查询（Parallel exhaustive queries）和多样性生成上。
Swyx: 我们聊得有点超时了。最后我必须谈谈 Notion 的 Meeting Notes（会议笔记），它带来了巨大的增长。
Sarah Sachs: Meeting Notes 最初让我们很紧张，因为我们怕需要改变用户的工作习惯，带来过高的摩擦。但这确实成为了我们最大的增长引擎之一，无论是采用率还是用户留存率都极具病毒式传播效应。
我认为它之所以强大，是因为 Notion 是人们工作的核心记录系统。我现在的习惯是，每个 1v1 和会议都会生成会议笔记。做年度绩效评估时，我主要就是看我跟经理沟通的这些笔记。它为记录系统增加了极其重要的高质量优先级信号，这对我们的智能体来说非常有用。
Simon Last: Meeting Notes 团队最近做的一件事让我很震撼。当它生成会议摘要时，它会自动在文档中“@”提及被提到的人。所以我现在只要有人在会议里谈到我负责的事情，我就会收到通知。这太神奇了。智能体会自动分析语境，找出那个最可能被谈论的“Simon”。
Sarah Sachs: Meeting Notes 本质上就是建立在“转录原语”之上的智能体。它把传统的会议记录变成了一个“数据捕获（Data Capture）”的过程。在这个基础上，我们让会议摘要变得具有智能体特性：比如未来它可以直接连接你的任务数据库，在你们开会讨论时实时更新任务，分配后续工作，完全实现“双手离开键盘”。
Swyx: OpenAI 正在做硬件，你们会出一款专门用来记录会议的硬件设备吗？
Simon Last: 可能不会。但我对那个产品类别很兴奋。
Sarah Sachs: 这只是一个数据捕获机制。无论谁做出最好的硬件，我们都会愿意合作，确保它能完美接入 Notion。目前有很多做可穿戴设备的酷公司来找我们的合作团队演示。他们都希望设备能具备搜索和构建上下文的能力，比如当你走进一个会议室时，设备能调取 CRM 信息。
但正如我之前提到的，这种硬件捕获属于“前端极度简化”的设备，对于数据捕获很好，但很难在上面进行我们自定义智能体那种高级的、深度的权限控制和复杂工作流操作。
Simon Last: 我曾经强烈地提醒过 Sarah：我们的工作不是打造最完美的智能体测试框架，或者最棒的硬件录音笔。我们的使命是打造人们协作的“最佳场所”。我们要做的是让 Notion 成为那个会议笔记最终沉淀下来的最好的家。
Swyx: 非常棒的深潜对话。感谢你们。
Sarah Sachs: 谢谢你们。