Notion Workers:从笔记工具到可编程 AI 平台

Notion Workers：从笔记工具到可编程 AI 平台

TL;DR Notion 发布了 Workers — 一个用 TypeScript 编写自定义工具的开发者框架，让 Custom Agents 能调用任何外部 API。底层跑在 Vercel Sandbox 的 Firecracker 微虚拟机上，凭证注入在网络层完成，代码本身碰不到密钥。这标志着 Notion 从文档工具正式转型为可编排整个技术栈的 AI 中枢。

Notion 不只是笔记工具了

2025 年 9 月，Notion 3.0 发布，AI Agent 成为核心。2026 年 2 月，Custom Agents 上线，能 24/7 自主执行工作流。但有一个问题始终没解决：Agent 只能操作 Notion 内部数据和预置集成。想发一条短信？调一下内部 API？没门。

Workers 的发布补上了这块。

一个 Worker 就是一小段 TypeScript 程序，部署在 Notion 的基础设施上，注册为 Custom Agent 的工具（tool）。Agent 在执行任务时可以调用这些工具，就像人类点击一个按钮一样自然。

区别在于：这次你写什么代码，Agent 就能做什么事。Twilio 发短信、GitHub 建 Issue、Discord 发通知、ElevenLabs 文字转语音 — 只要有 API，就能接入。

从文档到平台：Notion 的三次跳跃

理解 Workers 的意义，需要看它在 Notion 产品演进中的位置。

第一跳：Notion API（2021）

Notion 开放公共 API，第三方可以读写页面和数据库。这让 Notion 从封闭笔记变成了”可被连接的数据层”。但 API 是被动的 — 你需要自己搭服务器、写逻辑、管部署。

第二跳：Custom Agents（2026 年 2 月）

Notion 3.3 发布 Custom Agents。用自然语言描述任务，设置触发器或定时计划，Agent 自动执行。支持 Slack、Notion Mail、Calendar，以及通过 MCP 协议连接 Linear、Figma、HubSpot 等第三方。

限制也很明显：Agent 只能用 Notion 预置的集成。你的内部系统、小众 SaaS、私有 API — 一概接不上。

第三跳：Workers（2026 年 3 月）

Workers 打通了最后一环。开发者用 TypeScript 写自定义工具，部署到 Notion 基础设施，Custom Agent 直接调用。不需要你自己管服务器，不需要 webhook 中转，代码跑在 Vercel Sandbox 的安全沙箱里。

三次跳跃的本质：

阶段	能力	开发者负担
API	外部系统读写 Notion 数据	自建服务器、自管部署
Custom Agents	AI 自主执行预置工作流	零代码，但受限于预置集成
Workers	AI 调用任意自定义代码	写 TypeScript，Notion 管部署

从”你来调 Notion”到”Notion 来调你的代码”– 控制权反转了。

Workers 的技术架构

Workers 的技术挑战很直白：每个 Worker 都运行开发者写的任意代码，代表某个 Notion 用户执行，可能在企业级工作区里。一个 Worker 出问题，不能连带其他用户或其他 Worker。

Notion 把代码执行层交给了 Vercel Sandbox。

Firecracker 微虚拟机

每个 Worker 跑在一个独立的 Firecracker microVM 里 — 不是容器，是虚拟机，有自己的内核、文件系统和网络栈。执行完毕后，虚拟机销毁或快照保存。

这意味着一个 Worker 永远无法访问另一个 Worker 的数据或状态。隔离不是靠命名空间，是靠硬件级虚拟化。

凭证注入：密钥永远不进沙箱

传统做法：把 API Key 存成环境变量，代码里 process.env.API_KEY 读取。问题是，如果代码被 prompt injection 操纵，密钥可以被发送到攻击者的服务器。

Vercel Sandbox 的方案更彻底：防火墙代理（firewall proxy）在网络层拦截出站请求，自动注入凭证到 HTTP 头。代码能通过代理发出认证请求，但代码本身看不到密钥。

对 Agent 驱动的工作负载，这消灭了最危险的攻击向量 — Agent 被诱导泄露密钥。

动态网络策略

Sandbox 支持运行时动态调整网络策略，不需要重启进程：

1. 安装阶段：开放网络，下载依赖
2. 执行阶段：锁定出口流量，只允许白名单域名

企业客户可以精确控制 Worker 能访问哪些外部服务，符合合规要求。

快照与冷启动优化

第一次运行：安装依赖、初始化环境，然后快照文件系统状态。后续调用直接从快照恢复，冷启动时间大幅缩短。

配合 active-CPU 计费（只计算代码实际执行时间，不计 I/O 等待），成本可控。

三大使用模式

Workers 支持三种核心使用模式，覆盖了绝大多数自动化场景。

模式一：定时数据同步

把外部数据定期拉进 Notion 数据库。CRM 记录、运营数据、客服工单 — 你定义数据源和映射规则，Worker 按计划执行同步。

典型场景：每天早上 9 点，把 HubSpot 的新线索同步到 Notion 的销售管道数据库。

模式二：按钮触发自动化

把 Worker 绑定到 Notion 页面上的按钮。点击一下，执行一段自定义逻辑。

典型场景：在客户数据库的每行加一个”发送欢迎邮件”按钮，点击后调用 SendGrid API 发送模板邮件。

模式三：Agent 工具调用

这是 Workers 最强大的模式。Worker 注册为 Custom Agent 的工具，Agent 在执行任务时自主决定何时调用。

典型场景：一个负责客户支持的 Custom Agent，在 Slack 收到客户消息后，自动查 Notion 数据库找到客户信息，用 Worker 调用内部 API 查询订单状态，然后在 Slack 回复客户。

三个模式不是互斥的。一个 Worker 可以同时被定时任务触发、被按钮调用、被 Agent 使用。

实战：构建你的第一个 Worker

下面用一个”发送 Slack 通知”的 Worker 走一遍完整流程。

前置条件

• 工作区管理员已开启 Custom Agents
• 安装了 Node.js 和 npm
• 有 Notion CLI（ntn）

第一步：初始化项目

ntn workers new my-slack-notifiercd my-slack-notifiernpm install

项目结构：

my-slack-notifier/  src/    index.ts       # Worker 入口  package.json  tsconfig.json

第二步：定义工具

编辑 src/index.ts：

import { Worker, j } from "@notionhq/workers";const worker = new Worker();worker.tool("sendSlackMessage", {  title: "发送 Slack 消息",  description: "向指定 Slack 频道发送一条消息",  schema: j.object({    channel: j.string().describe("Slack 频道名称，如 #general"),    message: j.string().describe("要发送的消息内容"),  }),  execute: async ({ channel, message }) => {    const response = await fetch("https://slack.com/api/chat.postMessage", {      method: "POST",      headers: {        "Content-Type": "application/json",        Authorization: `Bearer ${process.env.SLACK_BOT_TOKEN}`,      },      body: JSON.stringify({ channel, text: message }),    });    const data = await response.json();    if (!data.ok) {      throw new Error(`Slack API error: ${data.error}`);    }    return { success: true, channel, timestamp: data.ts };  },});export default worker;

核心要素：

• j.object() 定义参数 schema，Agent 据此理解该传什么
• description 告诉 Agent 这个工具做什么、什么时候该用
• execute 是实际执行逻辑

第三步：配置密钥

ntn workers env set SLACK_BOT_TOKEN=xoxb-your-token-here

密钥存储在 Notion 基础设施中，通过 Vercel Sandbox 的防火墙代理注入，不进入代码运行环境。

第四步：本地测试

ntn workers exec sendSlackMessage \  --channel "#test" \  --message "Hello from Notion Worker!"

第五步：部署

ntn workers deploy

部署完成后，Worker 自动出现在 Custom Agent 的工具列表中。

第六步：绑定到 Custom Agent

在 Notion 中创建或编辑一个 Custom Agent：

1. 进入 Agent 设置页面
2. 在”工具”区域，找到你刚部署的 Worker
3. 勾选 sendSlackMessage 工具
4. 在 Agent 指令中描述何时使用：”当任务状态变更为’已完成’时，向 #project-updates 频道发送通知”

Agent 会在合适的时机自主调用这个工具。

Workers + Custom Agents：编排你的技术栈

单个 Worker 能力有限，真正的威力在于组合。

设想一个”新客户入职”自动化流程：

1. 触发：Sales 在 Notion CRM 数据库标记一条记录为”已签约”
2. Custom Agent 启动：检测到状态变更，开始执行入职流程
3. Worker A — CRM 同步：把客户信息同步到内部系统
4. Worker B — 账号创建：调用内部 API 创建客户账号
5. Worker C — 邮件通知：通过 SendGrid 发送欢迎邮件
6. Worker D — Slack 通知：在 #new-customers 频道通知团队
7. Agent 收尾：在 Notion 数据库更新状态为”入职完成”，创建跟进任务

整个流程不需要 Zapier、不需要 Make、不需要自建中间件。Notion 是控制中枢，Workers 是执行手臂，Custom Agent 是决策大脑。

这就是”可编程 AI 平台”的含义：不是你来编排流程，是 AI 来编排，你只需要提供工具和规则。

安全模型与企业级控制

Workers 运行任意代码，安全是第一优先级。Notion + Vercel 的方案在四个层面建立防线：

防线	机制	解决的问题
计算隔离	Firecracker microVM	Worker 之间互不可见
凭证安全	网络层注入，代码不碰密钥	Prompt injection 无法泄露 API Key
网络管控	动态出口策略 + 域名白名单	防止数据外泄到未授权服务
审计追踪	执行日志 + 权限记录	每次调用可追溯、可回滚

企业级额外控制：

• 工作区管理员可以决定谁能创建和部署 Workers
• Custom Agent 日志记录每次触发原因和执行动作
• 自动暂停：接近信用额度时告警，超额后 Agent 自动停止
• Notion AI 不使用你的内容训练模型，Enterprise 计划零数据保留

当前限制与注意事项

Workers 仍处于极早期的 alpha 阶段，使用前需要明确几点：

1. Breaking changes 随时可能发生。API 接口、CLI 命令、SDK 结构都可能变。生产环境慎用
2. 需要管理员开启。工作区管理员必须主动 opt-in，才能使用 Workers 功能
3. TypeScript only。目前只支持 TypeScript/Node.js 环境，不支持 Python 或其他语言
4. 定价尚未明确。Custom Agents 5 月 4 日开始按 token 计费（1,000 tokens = $10），Workers 的计算成本如何叠加，还没有公开细节
5. 权限模型待完善。Notion 计划为 Workers 平台扩展细粒度权限能力，但目前还在开发中

三条设计原则

原则一：从最小的自动化开始。 不要一上来就编排五个 Worker 的复杂流程。先用一个 Worker 解决一个具体痛点（比如自动发通知），验证价值后再扩展。

原则二：密钥永远不硬编码。 用 ntn workers env set 管理所有凭证。即便 Vercel Sandbox 提供了网络层注入，养成好习惯比依赖安全网更重要。

原则三：给 Agent 写好”使用说明书”。 Worker 的 description 字段决定了 Agent 能否在正确的场景下调用它。描述要具体 — 不是”发送消息”，而是”当客户提交工单后，向对应的支持团队 Slack 频道发送通知”。