Notion 的 Token Town：5 次重建、100+ 工具、MCP vs CLIs 与软件工厂的未来——Notion 的 Simon Last 与 Sarah Sachs
摘要
- Notion Custom Agents 的上线，在免费试用和转化方面创下公司迄今最强表现，但这已经是自2022年末以来的第4次或第5次重建。 swyx 指出，免费开放3个月确实起到了帮助作用；Simon Last 表示，早期模型缺乏工具概念、智能和足够长的上下文窗口，只能偶尔显露出「有用的曙光」。去年初，能力大约在「Sonnet 3.6 或 3.7」时才开始具备可行性；而可靠的后台执行和企业权限体系，还需要额外的产品工程。
- Notion 的价值在于企业级事实记录系统和协作能力，而不是拥有底层模型或 Agent 运行框架。 Sara Ma 将其定位类比为 AWS 之上的 Datadog：底层基础设施不可或缺，但真正构成价值层的是理解客户如何协作。Notion 预计未来「我们大多数流量」最终会来自 Agent，因此公司积累的文档、会议、任务和权限数据，战略重要性将持续上升。
- 随着模型能力不断迁移，Notion 已把持续重建组织化，产品团队是在交付之后而不是之前组建。 Sara 的原则是先避免「逆流而上」，再判断河流正在流向哪里；Simon 则大约每6个月重新思考一次技术栈。「Simon 漩涡」、松散的汇报边界、「演示优先于备忘录」，以及不介意删除自己代码的文化，将好奇心转化为运营优势。
- Evals 已成为产品质量和模型厂商反馈的核心基础设施。 上线报告卡要求在定义好的用户旅程上达到80%-90%，而「Notion’s Last Exam」则有意将通过率维持在约30%，以暴露能力上限。Notion 发现，名义上相同的模型经不同供应商提供时质量也会不同，并利用企业工作反馈影响了模型发布前的版本快照。
- Simon 关于「coding agents 是 AGI 的内核」的判断，指向一种软件工厂：人类监督外围系统，而不再亲手敲出每一行代码。 这座工厂需要人类可读的规格说明、强大的自验证能力，以及能将 Bug 转化为经过审查并合并的修复方案、同时尽量减少人工介入的工作流。Sara 将近期人类角色的变化称为一场「身份危机」：编码本身的重要性下降，委派和上下文切换的重要性上升；但 Simon 认为，最终形成的控制平面依然高度技术化。
- CLI 和 MCP 服务于不同的 Agent 架构，并非一场非赢即输的协议竞赛。 Boris Power 认为，CLI 提供渐进式披露，以及调试或创建自身工具的自举能力；Simon Last 则称 MCP 是适用于狭窄、轻量且权限边界明确的 Agent 的「简单到笨、但能工作的东西」。Notion 会继续支持 MCP，但 Sara 认为，如果代码可以一次性执行确定性操作，就没必要反复消耗语言模型 token。
- Usage credits 让 Notion 可以对模型、GPU 提供的微调模型、网页搜索、沙箱、缓存和服务层级统一计量，而不必暴露每项底层成本。 按感知到的商业价值收费被证明过于复杂，而 Agent 式自动填充——尤其是「每一个数据库单元格都跑 Opus」——可能带来数十亿美元成本。Auto 当前的设计目标是选择合适的模型、降低用户决策压力，而非最大化利润；MiniMax 等开源选项则帮助补上智能、价格和延迟三角中的缺口。
- Meeting Notes 与可组合的 Custom Agents 构成了最清晰的数据飞轮：捕捉更多工作，让系统更有用，再自动化围绕这些工作的流程。 一名内部运营人员曾由30多个 Agent 每天产生超过70条通知，通过一个管理 Agent 将面向人的负载降至约5条；普通页面和数据库则同时承担记忆与协作功能。Sara 的战略边界很明确：「我们的工作不是打造最好的 Meeting Notes 可穿戴采集设备，而是打造 Meeting Notes 最佳存放之处。」
精读
1. Custom Agents 在市场成熟前经历了多轮试错
Sara Ma 称 Custom Agents 是 Notion 在免费试用和转化方面最成功的发布，swyx 则补充了一个有用的限定条件：「免费3个月当然有帮助。」由于团队当时已经领先市场2或3个里程碑，发布日更像是延迟兑现的满足感，而不是项目真正完成。
Simon 表示，这大概已经是第4次或第5次重建。第一次尝试始于2022年末获得 GPT-4 使用权限之后，当时团队把这个概念称为「assistant」：赋予它 Notion 的全部能力，让它在后台运行，并自主完成工作。
在原生 function calling 出现之前，Notion 曾与 Anthropic、OpenAI 和 Fireworks 合作，搭建自己的多轮工具框架并进行微调。那些模型「实在太笨」，上下文窗口也太短，演示中颇有希望的效果始终无法稳定地变成令人愉悦的产品体验。
Simon 将模型层面的突破点放在去年初的「Sonnet 3.6 或 3.7」附近。此后的 Custom Agents 比早期 Agent 花费更长时间，原因在于无人值守执行需要更高的可靠性，还需要一套用户能够理解的权限界面，覆盖部分重叠的 Slack 群组和文档可见人群。
2. Notion 在不逆流而上的前提下布局 AGI
Simon 描述了一种项目组合：在维护性工作、当下已经可用的能力，以及「几个有点疯狂的项目」之间取得平衡。公司希望在建设面向模型未来的能力时保持「AGI-pilled」，但不能因此放弃持续交付有用的产品。
Sara 的纪律分为两步：首先判断团队究竟是在模型能力的限制下「逆流而上」，还是只是上下文或基础设施出了问题；然后再判断河流正在朝哪个方向流动。关键是要尽早开始为那个方向建设，但不能在不可能实现的方案上坚持太久。
当被问及18个月后什么会显得显而易见时，Simon 回答：「coding agents 是 AGI 的内核。一切都是 coding agent。」由于 Agent 可以自举、调试并维护自身能力，Notion 正在探索一座「软件工厂」，让多个 Agent 协同开发、审查、合并并运营一项服务。
3. 价值来自协作能力，而非模型所有权
Sara 用 Datadog 与 AWS 作比：即便 AWS 提供 CloudWatch，Datadog 仍需要云基础设施，但它真正的专长在于理解客户希望如何做可观测性。同样，无论底层能力由哪个模型提供，Notion 的专长都是「理解人们想如何协作」。
Simon 将 Notion 与狭窄的垂直 SaaS 区分开来。Notion 的任务是倾听广泛客户群体的需求，将不同请求拆解为可复用的基础能力，并维持一个始终连贯、好用的系统，而不是不断堆积彼此割裂的垂直功能。
Sara 警告，沉迷于「酷工具」会让团队陷入最低速的工作状态。团队每周五都会查看 P99 最耗 token 的 Custom Agent 对话，并针对邮件分拣等具体用户旅程，砍掉失败的任务；沙箱或 computer tool 是否获得优先级，取决于它能否解决 PDF 导出问题，而不是工具名称听起来是否令人兴奋。
4. 「Simon 漩涡」让持续重建制度化
Sara 不认为自己的职责是提供所有想法，或成为技术最深的人。领导层负责设定目标和优先级机制，再让最接近用户问题的人用原型反过来改变路线图：「成效最终要看结果。」
将 Agent 运行框架重建3次或4次，需要团队成员不介意删除自己的工作，也不能把设计文档当成晋升材料。Sara 将这种低自我、低职级政治的文化归功于 Simon Last 和 Notion 联合创始人 Ivan：不能因为一句「这段代码是我写的」就让组织无法前进。
「Simon 漩涡」类似一个 skunkworks 式机制：一批受信任的资深工程师围绕快速变化的原型轮换。汇报关系和协作关系保持松散，Notion 历来的做法是「先把东西交付出来，再组建组织结构」，而不是反过来。
公司黑客松向更广泛的员工传授这套方法；最近一次活动就要求所有人构建一个 Agent 式工具循环。但 Simon 的警告是绝对的：如果黑客松是创新的唯一通道，「那你就完了」。Image generation 能够交付，是因为 AI 团队之外的工程师 Jimmy 借助 Gemini 使用权限、token 跟踪和 eval 支持持续推进，最终把它做成了完整项目。
5. 用演示取代 Mock，平台承接试验的爆炸半径
Sara 负责的核心 AI 能力和基础设施团队约有50人，另有30-40人将这些技术封装进聊天、Custom Agents 和 Meeting Notes。每个产品团队也都负责自身服务面向 Agent 的版本，从相互竞争的 CRDT 编辑到 SQL 查询，均由对应团队拥有。
这种 ownership 建立在一个判断之上：未来大多数产品流量最终会来自 Agent，而不是人类。因此，编辑器、数据库和其他产品团队同时为两类使用者建设能力，而不是把所有 Agent 功能都交给一个中央 AI 团队。
Notion 的 Design Playground 为设计师提供可复用组件和一个能工作的 Agent，因此设计师交付的是 URL，而不是 Mock。对工程师而言，Simon 说原型的门槛基本就是「真正能工作的 feature flag」；在充满实验性 flag 的开发环境中进行全公司 dogfooding，又进一步放大了这一点。
「演示优先于备忘录」让产品判断变得更严格，因为如今几乎任何东西都可以被演示。Sara 的检验标准，是这项工作究竟是在「建一座塔」，还是只是在「堆一片很平的山」；在背后，agent-platform-velocity 组织提供 eval 工具、合规、供应商协作和运营加固，让原型负责人能够继续维护已经交付的能力。
6. Evals 是产品系统，而不是单一质量分数
Sara 不接受把「evals」等同于某一个质量数字。CI 中包含带随机性容忍区间、类似单元测试的回归测试；产品报告卡要求上线关键旅程达到约80%-90%；而 frontier 或 headroom evals 则有意设计成只有约30%的通过率。
30%通过率的测试套件名为「Notion’s Last Exam」，它是在旧 evals 饱和之后创建的，因为旧测试除了说明「没有变差」之外，几乎无法提供更多信息。Notion 为此配置了一名数据科学家、一名模型行为工程师和一名全职 eval 工程师，既为了预判河流的方向，也为了向 Anthropic 和 OpenAI 提供有用的前沿反馈。
Notion 观察到，名义上相同的模型，经由第一方服务或 Bedrock、Azure 及其他供应商提供时，质量会有所不同；工作时间的服务速度也更慢。Sara 表示，模型实验室还曾发送多个发布前版本快照，有时在 Notion 发现企业工作场景中的回归问题、而编码类基准未能捕捉到之后，最终发布的版本也随之改变。
模型行为工程师这一岗位，已经从过去手动评判 Google Sheets 的「数据专家」演变为一条独立职业路径，结合了数据科学、测试 PM、提示词、语言学和品味。如今 coding agents 可以帮助他们下载数据集、运行 evals、诊断失败并实施修复，但 Sara 坚持认为，监督工作不必由软件工程师承担。
7. 软件工程师向上迁移，进入技术控制平面
Sara 表示，Notion 每位工程师都经历过类似新任管理者的身份危机：「写代码的能力，不如委派和上下文切换的能力重要。」Simon 将同一变化描述为一条连续光谱：从手动编写代码，到使用自动补全，再到由 Agent 长时间执行调试、验证、合并和部署。
Simon 不认同这只是把工程师变成人员管理者。人类的行为模糊，而 Agent 可以被建模为一套严谨系统，包括 PR、阻塞状态、审批、记忆和恢复机制。设计外围系统仍然是「一个很难的工程问题」，而且本质上高度技术化。
他的软件工厂首先需要一层人类可读的规格说明，可以是 Markdown 文件，也可以是由 Notion 页面组成的数据库；其后是强大的自验证和测试能力。流程层必须定义：报告的 Bug 如何交给子 Agent、如何变成 PR、如何接受审查并合并，同时以尽量少的人工介入维持必要的不变量。
8. Custom Agents 通过普通记录协作，而非依赖复杂编排
Alessio 在 Kernel Labs 的演示中，将收到的共享办公申请转化为一个经过丰富处理的 Notion 数据库：Agent 检查邮件、添加行、搜索网页，并提取入住时间。整个设置过程约15分钟，而且信息仍然留在他原本就会使用的位置。
Sara 认为内部最有代表性的案例是 Bug 分拣：一个驻留在 Slack 的 Agent 使用路由规则宪章，在适当的任务数据库中创建条目，再回帖到频道。她的表述非常准确：「它不是在替代人，而是在替代流程。」
Simon 介绍了两种组合方式。松耦合的 Agent 可以通过监视和写入数据库来协作；即将推出的设置则允许一个 Agent 直接调用另一个 Agent。Alessio 立即提出递归和无限循环风险——「最后全都会变成回形针」——Simon 和 Sara 也承认必须存在某种限制，但没有给出具体数字。
一名负责 go-to-market 的运营人员此前拥有30多个 Agent，每天产生超过70条阻塞任务通知；一个读取其问题数据库的管理 Agent 将面向人的负载降至约5条，还能协助诊断失败原因。Notion 同样没有引入专门的 memory primitive：记忆就是一个人类和 Agent 都能编辑的页面或数据库。
9. MCP 和 CLI 在技术栈的不同层级各有优势
Boris Power 对 CLI 的论据始于终端原生的杠杆效应：分页、文件、帮助命令和渐进式披露，可以把无关能力隐藏起来，直到真正需要时才展示。更重要的是，这个环境具备自举能力：据称，一个没有浏览器的 Agent 曾为自己写出约100行的 Chromium 封装；工具出错时，它也能自行修复。
Boris 以 Chrome DevTools MCP 为反例，揭示了其中的取舍：一旦传输层出问题，Agent 会失去浏览器，也无法修复外部服务器。但 Simon 仍称 MCP 是适用于狭窄、轻量 Agent 的「简单到笨、但能工作的东西」（“dumb simple thing that works”），这类 Agent 的权限边界应停留在明确暴露出来的工具调用上。
CLI 带来更棘手的 token 和凭证问题，因为拥有运行时权限的 Agent 可能接触甚至窃取 API token。Sara 还提出了经济层面的论据：反复使用语言模型执行确定性的第三方操作会浪费 token，尤其是在缓存窗口之外；相比之下，由生成的代码调用 CLI，只需承担一次性的推理成本。
因此，Notion 采用混合分层方案。Linear 和 GitHub 集成可能使用 MCP，而 Slack、邮件、日历和搜索则获得更深度的原生工具与触发器支持；MCP 本身没有 trigger 协议。内部抽象层统一了工具、Agent、completions、任务和聊天范式，MCP 只是其中一种集成类型，而不是完整架构。
10. 多轮重建最终收敛到模型原生抽象和100+工具
2022年末的第一套架构本身就是一个 coding agent：把每个动作表示为 JavaScript，并暴露 JavaScript API。但当时模型还不擅长写代码，因此在标准 tool calling 尚未出现之前，Notion 就转向了工具调用。
后来的替代方案使用 XML 表示法，目标是无损映射到 Notion blocks。它与 Notion 的内部结构很匹配，却不符合模型学到的环境，于是团队得出了更广泛的经验：「给模型它们想要的东西。」Notion-flavored Markdown 保留普通 Markdown 作为核心，并接受转换不必无损。
数据库访问也走过同样的路径。一套复杂的 JSON 查询格式能够整齐映射内部结构，却给模型增加了负担，因此 Notion 改为暴露 SQLite 风格查询。这一选择也受益于既有系统：Notion 数据库本来就会在成组的 SQLite 数据库之间进行查询。
更广泛的演进，是从一次性 prompt 和 few-shot 示例，转向由目标驱动的工具定义与反馈循环。工具所有权由5或6名 prompt 把关人转移到各产品团队；如今最新 Agent 已超过100个工具，渐进式披露同时保护质量和 token 使用，否则光说一句 hello 就可能消耗数千个 token。
11. 「向班级最优者教学」塑造了 Agent 的用户体验
Notion 不把 system prompt 或工具列表视为秘密武器，运营人员可以直接询问 Agent 有哪些工具。Simon 的原则是「向班级最优者教学」，保留足够的深度和可解释性，让高级用户理解 Agent 如何工作，并能够精准地为它编写 prompt。
团队进一步明确了其中的取舍：如果把设置做得过于简单，可能抽走可解释性，并让 Agent「降级」。一次关键的产品转折，是团队认定 Custom Agents 并不适合所有人；目标用户由此变得清晰，开发速度也随之加快。
Agent 可以自行完成配置，因为它会获得设置和调试工具，以及一份解释如何编写优质指令、如何进行端到端测试的开发指南。出现失败时，用户可以追问原因，并要求 Agent 更新指令；完全自动化的自我修复仍属于路线图工作。
权限会限制这种自举能力。后台 Agent 初始没有任何访问权限，也不能悄悄修改自己的权限；用户按下 Fix 后，会进入同步的管理员模式，所有拟议变更都必须可见并经确认。以聊天为先的「Flippy」重设计，让设置和使用发生在同一段对话中，虽然使发布推迟了约1个月，却取代设置页成为主要体验。
12. Credits 为算力定价，Auto 负责选择模型
Credits 位于原始 token 之上，因为 Notion 的成本还包括 GPU 提供的微调模型、价格不同的网页搜索、潜在的沙箱、不同的服务层级、缓存命中率以及异步处理。对企业采购和批量折扣而言，credit packs 也比逐项暴露基础设施计量单位更合适。
Notion 最初考虑按每次 Agent 运行或任务价值收费，但复杂度一次次最终都回到了 token 吞吐量。按使用量收费还可以避免灾难性的补贴：Madhu Muthukumar 表示，如果对每一个数据库自动填充单元格都以 Agent 方式运行 Opus，成本可能达到「数十亿美元」。
Auto 的目标是为任务选择最佳模型，而不是为 Notion 选择最便宜的模型；Madhu 表示，它目前并不是利润工具。由于异步用户对速度不那么敏感，Notion 会增加成本提示，也可能引导用户不要用 Opus 去分拣每一封邮件。
Madhu 认为，智能、价格和延迟三角之间仍有一块空白：模型集中在少数几个能力、速度和成本点上，而更小的模型并不总能实现成比例的低价。Notion 提供 MiniMax，并与开源实验室合作扩充选择；Simon 还补充说，理想的 Agent 可能会通过用代码替代重复推理，「把自己自动化到失去工作」。
13. 训练不如优化外围循环——除非检索确实改变了问题
Madhu 不认为训练 Notion 基础模型是必须具备的核心能力。Simon 更感兴趣的是了解企业上下文和人员关系的企业专用微调；大型客户也在询问 bring-your-own-model 方案，而公开的 prompt 和工具定义让这些模型更容易接入。
Simon 承认自己「花了很多时间尝试训练模型」。Notion 每天都在改变工具，专门针对工具训练的模型可能在投资回本前就已经过时；他当前的判断是，「99%的时候，问题出在某个工具上」，因此提升 harness、工具、验证和调试的速度，比条件反射式地重新训练更重要。
但他的工作方式最终绕了一圈回到原点：过去训练模型需要在夜间启动实验，如今则是在睡前启动 coding agents，希望任务能一直运行到早上。其中一条线程几乎连续运行了17天，并因 harness bug 触发了约100x压缩。
检索是主要例外，因为 AI 方案中的大多数搜索流量如今来自 Agent。Agent 的查询更看重 top-K 覆盖率，而不是人类点击位置；它们需要不同的摘要片段，以及并行、穷举式搜索。swyx 描述了一种8路查询 fan-out，用来最大化查询多样性。如今「agentic find」团队把排序、查询生成、索引和检索视为同一条用户旅程，而不再过度强调选择哪种向量 embedding。
14. Meeting Notes 将对话变成不断复利的企业上下文
Sara 称 Meeting Notes 是 Notion 在用户采用、传播性和留存方面最强的增长杠杆之一。她自己的例子体现了其作为权威记录系统的价值：在撰写自我评价时，她会以与经理的对话为基础，因为工作中从未在这些一对一会议里提及的事情，很可能并不影响评价。
在内部，一个 Custom Agent 会从 Slack 和 GitHub 汇总 standup 会前材料，创建会议记录，并要求参会者提前阅读。一次脱离键盘的讨论结束后，另一个由日历触发的 Agent 会创建任务，并发送会议中决定好的后续 Slack 消息。
转录带来了长篇内容的爆发，迫使 Notion 改进搜索、上下文管理和压缩。Agent 式摘要如今会尝试解析并 @mention 正确的人——例如最有可能的 Simon——使用出席数据、生成式个人档案和人员相似度机制，但 Sara 和 Simon 都承认结果仍可能出错。
Sara 将产品重新定义为数据捕捉：转录是基础能力，Meeting Notes 则是在其上封装的 Agent；未来的 Agent 可能在对话进行时直接更新相关任务数据库。可穿戴设备合作可以向 Notion 输入更多上下文，但产品边界依然是协作：打造「Meeting Notes 最佳存放之处」，而不一定是最好的采集硬件。