Notion AI Agent 四年实践揭示：流程自动化比人工更易被替代

首页

热心网友

转载

2026-05-19

Notion的AI工程负责人Sarah Sachs和技术核心Simon Last最近在Latent Space播客上做了一次深度分享，将团队过去四年在AI产品上的探索、试错与重构，毫无保留地摊开来讲。从技术选型的反复推翻，到团队管理的独特哲学，再到定价策略的深层考量，信息密度极高。对于任何正在或即将涉足AI产品领域的人来说，其中的许多洞察都堪称“避坑指南”。

以最近上线的Custom Agents功能为例，这个允许用户创建后台自动运行AI助手的产品，取得了Notion历史上最高的免费试用转化率。但很少有人知道，这个看似顺理成章的功能，其背后是一段从2024年底开始、历经四五次几乎从零开始重建的曲折历程。

四年五次重建，每一次推翻都是因为搞错了方向

时间回到2024年底，Notion团队刚获得GPT-4的早期访问权限，他们的第一个想法就是打造一个能在后台自动工作的“智能体”（当时还没有Agent这个流行词，他们称之为Assistant）。最初的思路非常直接：将Notion所有能执行的操作都暴露给大模型，让它自己编写Ja vaScript代码来调用。

结果呢？模型生成代码的能力远未成熟，这条路根本走不通。

于是，团队转向第二版方案。他们自己设计了一套优雅的XML格式来描述Notion的数据结构，并配套了一套专用的变更操作语法。从内部数据模型的角度看，这套方案堪称完美。但问题在于，大模型完全不认识这套自定义格式，需要在提示词中耗费大量篇幅进行“教学”，效果依然不尽如人意。

这次失败带来了一个关键教训：要迎合模型的习惯，而不是强迫模型来适应你的系统。

第三版方案果断转向了Markdown。模型天然理解Markdown，无需额外教导。同时，数据库查询也从Notion复杂的原生JSON格式，换成了模型更擅长的SQLite语法。技术负责人Simon Last总结道，这个转变的核心就是一句话：给模型它想要的东西，别把你系统的复杂性暴露给它。

接下来的一个重要转变，是从Few-shot提示词迁移到工具定义（Tool Definition）的方式。这个改变的深远意义远超技术层面。过去，所有人都在编辑同一个庞大的提示词文件，示例的先后顺序都会影响模型行为，团队内部常因此产生摩擦，且只有少数人有权限修改。采用工具定义后，每个团队可以独立维护自己的工具集，协作效率大幅提升。Sarah Sachs认为，这可能是他们在工程效率上最大的一次飞跃。

最新的版本则实现了工具的“渐进式暴露”。此前，Agent一启动就能看到所有工具，工具一多模型就容易“犯晕”，产生无效调用。现在，超过100个工具可以按需加载，模型只在需要时才看到相关工具。团队一直在努力将提示词压缩得尽可能短。

这段历史给人的最大启示是，AI产品的开发几乎没有“一步到位”的可能。每一次推倒重来，往往不是因为技术能力不足，而是源于对模型能力认知的刷新，以及对产品形态理解的深化。Sarah Sachs提炼了两个至关重要的能力：第一，快速判断自己是否在“逆流而上”——是在与模型的固有局限死磕，还是自身的基础设施没搭对；第二，看清“河流”的流向，提前朝那个方向布局，哪怕当前方案不够完美，但当模型能力到位时，你将成为准备最充分的那一个。

这两条原则听起来简单，但践行起来需要极强的直觉和巨大的勇气，因为它意味着要不断否定过去的自己，并随时准备重新开始。

低自我、高流动：AI时代的团队应该长什么样

Sarah Sachs管理着Notion约50人的核心AI团队，加上协作的产品与设计团队，规模更大。她对AI团队的管理有着鲜明的见解。

她认为，AI团队的领导者不应是创意的最终拍板人或技术权威。其核心职责是确保每个人都理解共同目标，拥有排定优先级的资源，以及推进自认为重要事项的通道。在AI领域，最宝贵的想法往往来自一线工程师的原型，因为他们离用户问题最近，也最先感知到模型能力的微妙变化。如果所有想法都需要层层审批，无异于浪费最前沿的信息源。

Notion内部有一个著名的概念叫“Simon Vortex”（西蒙漩涡）。Simon Last负责前沿探索，他的项目方向可能日新月异，速度极快，就像一个内部的“臭鼬工厂”实验室。高级工程师会被临时抽调进去，完成一个阶段任务后再回到原团队。管理边界非常模糊，汇报线和工作线时常分离。在招聘管理者时，Notion会特别考察一点：你是否介意自己的下属被“借走”。过于看重“地盘”意识的人，在这里可能难以适应。

Sarah反复强调“低自我”（Low Ego）文化。团队必须愿意删除自己写的代码，推翻自己构建的系统。Custom Agents框架历经四五次重建，每次重建都意味着此前的工作可能归零。如果团队中有人固守“这是我写的代码，不能动”的想法，整个迭代节奏就会被拖慢。这种文化由创始团队奠定，新人加入后会自然融入，没有人想成为阻碍变化的那个人。

另一个核心理念是“演示胜过备忘录”（Demos over Memos）。设计团队专门建立了名为“Design Playground”的GitHub仓库，里面全是可快速拼装UI的组件。设计师不做静态稿，直接产出可交互的原型。工程师的原型标准则是做成一个可用的功能开关（Feature Flag），直接在内部版本中运行。Notion的一大优势在于，全公司——从工程到采购再到招聘——都运行在同一个Notion实例上，内部反馈循环极快。

这种组织方式对许多追求秩序的公司而言可能显得“混乱”，但在AI这个底层技术每隔数月就可能发生根本性变革的领域，速度和灵活性或许真的比完美的计划更重要。花费三个月撰写一份详尽的技术方案，写完时其前提可能已经过时。

评估体系：Notion的「末日考试」

Notion在模型评估（Eval）上投入重兵，且思路独树一帜。

他们将评估分为三层。第一层是回归测试，集成在持续集成（CI）流程中每日运行，确保已有功能不退步。第二层是发布质量评估，有一套记分卡体系，核心用户场景必须达到80%到90%的通过率才能上线。第三层则是最具创新性的“前沿评估”或“余量评估”，其设计目标是通过率仅为30%。

为什么要做一套大部分都通不过的测试？因为他们发现，当现有评估全部达到饱和后，就无法向模型供应商提供有价值的改进反馈了，只能说“没有变差”，这对双方都无益。同时，你也看不清模型能力的演进方向。因此，他们投入大量精力设计Notion版的“末日考试”，专门测试那些当前模型做不好、但未来有望突破的任务。这套测试由专人全职维护，团队包括数据科学家、模型行为工程师和评估工程师。

“模型行为工程师”（Model Beha vior Engineer）是Notion自创的岗位。最初只是需要有人帮忙分析Google Sheets中的测试结果。他们招募了一些语言学背景的人才，后来这一角色逐渐演变为独立的职能方向。现在，这些人的工作是理解模型的能力边界，定义何为良好的用户旅程，分析失败案例，并判断下一步的投资方向。Sarah形容这个岗位混合了数据科学家、产品经理和提示词工程师的特质，需要强大的直觉和品味，而不一定需要深厚的软件工程背景。

Notion还做了一件前瞻性的事：将整个评估系统本身当作一个Agent框架来运行。理想状态下，一个Agent可以端到端地下载数据集、运行评估、分析失败原因、调试并修复问题，人类只需在外围监督。Simon认为，这本质上就是把评估问题转化为了一个编码Agent的问题。

这套体系最值得借鉴的，正是那个30%通过率的前沿评估。大多数团队追求测试全部通过，但Notion刻意保留了一大块“尚未做到”的区域，用它来感知未来。这个思路可以迁移到许多场景：你不仅要知道现在能做什么，更要持续追踪还不能做什么，以及这条边界正在如何移动。

Agent之间怎么协作：30个Agent和一个经理

访谈中有一个生动的案例。Notion内部有人为市场推广（GTM）团队创建了超过30个Custom Agent，分别负责客户调研、信息填充、反馈分类等任务。结果，此人每天收到70多条通知，全是Agent运行卡住、需要人工介入的提醒。

Simon Last给出的解决方案简单而巧妙：再创建一个“经理Agent”。这个经理Agent有权调用其他所有Agent，负责监督运行状态、处理遇到的问题。通知量瞬间从每天70多条降至5条。

更有趣的是实现方式。他们并未为Agent协作设计任何专用机制，而是直接利用了Notion自身的数据库。新建一个数据库作为Agent内部的问题追踪器（Issue Tracker），所有Agent遇到问题就写入记录，由经理Agent读取处理。记忆功能也是如此，没有专门的记忆模块，直接赋予Agent一个Notion页面进行读写，人类也能编辑。

Simon阐述了他们的设计哲学：尽量用已有的基础组件进行组合，能不创造新概念就不创造。数据库、页面、子页面——这些Notion固有的元素，天然构成了Agent协作的基础设施。

这个思路值得深思。许多人一想到Agent协作，就联想到复杂的通信协议或专用编排框架。但Notion的实践表明，如果底层数据结构足够灵活，Agent协作可以异常简单。一个共享的数据库就是最好的消息队列，一个页面就是最佳的记忆存储器。

MCP还是CLI：两种路线的取舍

Simon Last非常看好命令行界面（CLI）路线。他认为CLI的最大优势在于，Agent可以在同一环境中进行自我调试。他举例说，有人的Agent没有浏览器功能，就让Agent自己写了一个，大约100行代码封装了Chromium的API。如果出现Bug，Agent可以立即修复。但如果使用Chrome DevTools的模型上下文协议（MCP），一旦传输层出问题，Agent就完全“失联”，丧失了自救能力。

不过，他也承认MCP自有其优势。MCP的权限模型非常清晰，Agent只能调用被明确授权的工具，不会越界。而CLI的权限边界则模糊得多，Agent能否访问API令牌、会否泄露敏感信息，都是真实存在的安全隐患。因此，MCP特别适合需要严格权限控制的轻量级Agent场景。

Sarah Sachs补充了一个常被忽略的成本视角。MCP意味着每次工具调用都要经过语言模型，Token费用会不断累积。如果同一操作在缓存窗口外被反复执行，你就得为同样的事情反复付费。但如果Agent能编写一段确定性代码直接调用API，那就是一次性成本。对于Notion这种按用量收费的产品而言，这直接影响到用户的使用成本和公司的毛利率。

在实际操作中，Notion的策略是：核心功能自建，长尾集成采用MCP。例如搜索功能，他们没有使用Slack、Linear、Jira等提供的搜索MCP，因为搜索对Agent工作流太关键，需要更精细的质量控制。但对于那些非核心的第三方集成，则开放MCP让用户自行连接。

这种分层策略适用于所有AI产品团队：核心路径上的每一步都要自己掌控质量，边缘场景则可以交给通用协议。

定价的学问：为什么不能按Token收费

Notion的Custom Agents采用积分（Credit）体系，而非直接按Token收费。Sarah解释了原因：不同模型、不同服务层级、网页搜索、代码沙箱等组件的成本结构差异巨大，无法统一用Token衡量。此外，优先级处理、异步执行、缓存命中率等变量也让直接按Token计费显得过于粗糙。

他们曾尝试按Agent运行次数收费，但发现复杂度太高，最终回归到与Token用量挂钩但加以抽象的积分体系。企业客户购买积分包可获得折扣，这也方便了销售团队的工作。

一个有趣的细节是“自动”（Auto）模式。用户可手动选择模型，也可选择“Auto”让系统自动匹配。Sarah指出，许多用户误以为“Auto”就是最便宜、能力最弱的模型，但实际上系统是在根据任务类型选择最合适的模型。团队花费了大量精力说服用户信任“Auto”模式，甚至在界面上添加提示，告知用户当前任务使用的模型成本高低。

Sarah还提到了一个现实困境：前沿模型越来越强大，但也越来越昂贵，而许多企业任务其实不需要如此顶级的智能。中间地带的模型选择很少，较小模型的能力尚未达到半年前推理模型的水平，大模型又贵得令人咋舌。因此，Notion正在积极投资开源模型，与不同的开源实验室合作，利用Notion的评估体系帮助这些模型提升在企业任务上的表现，从而在智能、价格和延迟三个维度上为用户提供更多选择。

这里蕴含着一个深刻洞察：模型供应商与应用层公司的激励机制并不一致。模型供应商希望用户消耗更多Token、使用更贵的模型。但应用层公司希望用户用最合适的工具完成任务，有时最合适的工具甚至不需要Agent，一段确定性代码足矣。Simon表示，他们的理想状态是Agent能将自己“自动化”掉——当发现某个任务可用确定性代码解决时，就不再每次都走模型推理。

不训练自己的基础模型，但在检索上下重注

当被问及是否会训练自己的基础模型时，Simon的回答很干脆：这不需要是我们的核心能力。他坦言自己曾花费大量时间尝试各种训练方案，直到Sarah Sachs看到账单后叫停了这项探索。

他们当前的判断是，工具变化太快了。如果你针对当前的工具集微调了一个模型，几天后工具可能就变了，又得重新训练，这个节奏跟不上。而且，每次决定自行训练，本质上都是在赌前沿模型不会在你训练完成前就解决同样的问题——到目前为止，这个赌注还没赢过。

但有一个方向他们确实在重金投入：检索与排序。Sarah透露了一个有趣的数据：Notion企业版和AI版的搜索流量，大部分已来自Agent，人类搜索反而成了少数。Agent的搜索行为与人类截然不同：人类关注前几条结果的排序，Agent关注的是Top K结果的召回质量；人类需要好的摘要片段来决定是否点击，Agent需要的信息粒度也不同。

因此，他们正在重新设计整个检索系统，以同时服务人类和Agent两类用户。他们正在招聘排序工程师和模型训练工程师，但主要聚焦于排序相关工作。Simon还提到一个有趣的实验方向：与其耗费巨力优化向量嵌入的选择，不如让模型生成多样化的查询，同时发起八个不同角度的搜索请求，通过扩大搜索空间来提升召回率。

这个趋势值得所有SaaS产品开发者注意。当你的产品流量越来越多地来自Agent时，你的搜索、API、数据结构都需要为此优化。这可能是未来几年软件行业必须面对的根本性转变之一。

会议笔记：被低估的数据飞轮

会议笔记是Notion增长最快的功能之一，在用户获取和留存方面表现强劲。Sarah分享说，她自己每次一对一会议都会使用，撰写年度绩效自评时，直接翻看与老板的对话记录——如果某件事从未在一对一中讨论过，那它很可能也不值得写入绩效报告。

从产品视角看，会议笔记的价值远不止“记录会议内容”。它本质上是一个强大的数据采集入口。每一场会议产生的文本，都蕴含着任务分配、决策记录、人员关系、项目进展等丰富信息。当这些数据流入Notion，Agent就获得了更多上下文来理解你的工作。

Notion内部的站会流程已完全由Agent接管。会前，一个Agent自动读取Slack和GitHub动态，生成预读材料并创建会议笔记。会后，另一个Agent根据讨论内容自动创建任务、发送Slack跟进消息。人类只需专注于问题讨论，所有的记录与后续跟进均由Agent处理。

最近，他们还增加了一个让Simon特别兴奋的功能：会议摘要会自动@提及被讨论的人。例如，会上有人说“Simon正在做这个项目”，Simon本人就会收到通知。这样他就能主动去找对方沟通，而无需等待转达。这个功能背后已是Agent在运行，它能识别“Simon”具体指哪一位，运用了人员相似度缓存和参会者信息。

Sarah将会议笔记重新定义为一个数据采集问题。从这个角度思考，许多新的可能性随之打开：会议中提到的任务可自动关联到对应数据库，讨论涉及的项目状态可实时更新，甚至在会议进行中就能完成大部分后续工作的分发。

软件工厂：Agent替代的是流程，不是人

Simon对未来最兴奋的方向是他们称之为“软件工厂”的构想。简而言之，这是一套尽可能自动化的工作流，由一群Agent协作完成代码的编写、调试、审查、合并、部署和维护。

他认为，编码Agent是通往通用人工智能（AGI）的内核。因为一个能写代码的Agent可以为自己创造工具、扩展能力、调试问题。这种自我引导的能力是其他类型Agent难以具备的。

Sarah提到了一个形象的比喻：今年夏天，每位软件工程师都经历了一场身份危机，就像每位新晋管理者都会经历的那样。你突然意识到，编写代码的能力变得不那么绝对重要了，更重要的是委派任务和切换上下文的能力。但Simon补充道，管理Agent与管理人类有一个关键区别：人类是模糊的，你无法将一个人类团队当作一个严格的系统来运行；但Agent可以。你可以精确追踪每个Agent的状态，设计严格的流程，并在某个环节卡住时拥有明确的处理机制。这本质上是一个深度的技术设计问题。

他们正在构建的“软件工厂”包含几个关键组件：一个用Markdown或Notion页面描述需求的规格层；一个确保生成代码符合预期的自验证循环；一个处理Bug发现、修复、提交、审查、合并全流程的工作流引擎。Simon说他现在的睡前习惯是确保所有Agent都在运行，且任务量大到在他醒来前不会做完。他曾有一个编码Agent的线程连续运行了17天。

Sarah在访谈中说了一句非常精准的话：Agent替代的是流程，而不是人。 Notion内部使用Custom Agent进行Bug分类：当有人在Slack中报告一个问题，Agent会自动判断其所属团队，在任务数据库中创建记录，并在对应的Slack频道中通知。这个流程以前需要人工处理，经常遗漏，现在几乎不会了。

Flippy：让Agent自己设置自己

Custom Agents有一个巧妙的产品设计，内部代号为“Flippy”。最初版本是传统的设置页面，用户手动填写各种配置，然后切换到聊天界面测试。后来，团队将整个逻辑翻转了过来：主界面就是聊天，用户直接通过与Agent对话来完成设置。Agent有权修改自己的配置、更新名称、调整系统提示词。设置面板变成了一个侧边栏，用户可以查看Agent做了哪些改动，也可手动调整，但理想状态是你永远不需要触碰那些设置项。

如果Agent在运行中间出错，你可以直接在对话中让它修复自己。这比复制错误信息、切换到设置页面、手动修改要自然得多。当然，这里存在一个微妙的权限平衡：Custom Agent默认没有任何权限，所有权限都需要用户显式授予，这是其能在后台安全运行的基础。但如果让它修复自己，就意味着它能在某种程度上修改自己的行为边界。因此，目前的设计是，Agent不能修改自己的权限，但可以在用户监督下修改自己的配置。

这个“Flippy”设计差点让产品发布延迟一个月，因为许多早期用户已习惯旧的设置流程，改变他们的心智模型需要时间。但整个团队都认为这个方向明显更优，因此坚持推进。执行这次改动的是从三个不同团队临时抽调的三名工程师，没有人抱怨，没有人说“这不是我的职责”。Sarah表示，这正是Notion组织文化在关键时刻发挥作用的体现。