Notion API 正在争夺 Agent 控制面：8 月 11 日是 Notion credits 计费拐点

5 月 13 日，Notion API 版图随 Developer Platform 发布而扩张：Workers、External Agent API 和 CLI 同时登场，Claude Code、Cursor、Codex 也被当作工作区的原生参与者。这里的野心远不止一次产品更新：Notion 正在争夺 Agent 控制面。日历上真正需要圈出的日期，只有 8 月 11 日。

Notion API 与 Developer Platform 这次交付了什么

一次发布，六项基础能力。Workers 是一套托管式 Node/TypeScript 运行时，目前处于 public beta，仅面向 Business 和 Enterprise 套餐。External Agents 处于 Alpha 阶段，Claude Code、Cursor、Codex 与 Decagon 的合作伙伴集成开箱即用。面向自定义 Agent 的 External Agent API 仍是 private beta，需加入候补名单。CLI 名为 ntn，所有套餐均可使用，安装命令为 curl -fsSL https://ntn.dev | bash。数据库同步由 Workers 驱动，覆盖 Zendesk / Salesforce / Postgres。Webhook 触发器则把任意应用的事件送入 Worker，再写入 Notion。来源：Notion Developer Platform 发布公告。

另外两个信号同样关键。Notion Agent SDK（Alpha，需加入候补名单）可将 Notion Custom Agents 嵌入 MS Teams、Discord、Amplitude 和 Hex。治理能力也已纳入其中：Agent 操作采用渐进式信任机制，Workers 在沙箱中运行，每次部署都有独立的认证与权限。

从运营者视角看，Notion 在争什么

真正的标题不是“Notion 发布了一个 SDK”，而是“Notion 宣布自己就是 Agent 工作区”。当 Claude Code、Cursor、Codex 和 Decagon 以合作伙伴 Agent 的身份进入侧边栏，IDE 就不再天然是编排层。这个位置已经有人正面争夺。

5 月 13 日的发布说明把演示闭环写得很明白：Decagon 接下客服工单，把 bug 交给编程 Agent，再将修复方案送回团队审批。如今，这套流程横跨三个应用和一条 Slack 讨论串；Notion 要把它压缩到同一个界面里。

谁掌握工作区，谁就掌握集成税。Notion 现在要向 Agent 厂商收取这笔税，而不是 CRM 厂商。这才是变化的核心。

反方观点也很清楚：大多数运营技术栈早已有默认入口——CRM、项目管理工具，或自建后台。真正的问题在于，对本就驻扎在 Notion 的团队而言，Notion 这套数据库原生、Agent 原生、浏览器优先的形态，能否凭既有惯性胜出。不使用 Notion 的团队，什么都不会改变；深度使用 Notion 的团队，则需要重新计算每个即将搭建的内部工具究竟该自建还是采购。

8 月 11 日：Notion credits 计费拐点

Workers 在 public beta 期间免费。自 2026 年 8 月 11 日起，运行将消耗 Notion credits，具体费率尚未公布。这既是非对称机会，也是陷阱。

机会在于：现在基于 Workers 开发不花钱。如果能在 8 月 10 日前上线三个同步和两个 Agent 工具，就能以零成本消化集成开销。若选择等待，之后可能不得不从 Notion 最终公布的费率方案上迁走，而且这个 credits 定价模型从未进入你的路线图测算。

算一笔具体账。每 5 分钟同步一次，每月会触发 8,640 次；三个同步就是每月 25,920 次。8 月 10 日之后，这项成本仍是未知数。若 Notion 的价格低于每百万次 $1，它就会便宜到足以承担 glue tier，所有接触 Notion 数据的工作都值得迁入；若达到每百万次 $5+，Cloudflare 仍会留住成本敏感的市场，Notion Workers 也只适合处理 Notion 数据。

陷阱在于：已经能在现有技术栈上确定性、低成本运行的工作负载，不要迁。只迁移那些因靠近 Notion 数据而真正受益的部分：读取 Notion 的同步任务、写入 Notion 的 Agent 工具，以及向 Notion 数据库分发事件的 Webhook。其他工作继续留在原处。

本周值得上线什么

先安装 CLI。运行 curl -fsSL https://ntn.dev | bash，完成认证即可。免费，也不要求平台套餐。CLI 概览。

上线一个能自证价值的 Worker：选择一个每周会被 Custom Agents 调用 50+ 次的确定性 Agent 工具，例如按邮箱查找客户、把任务推送到 Linear、生成周报。它应当 token 开销低，不需要 LLM 推理，并在沙箱中运行。工具指南。

再上线一个过去不值得开发的同步：把 Postgres 表、Stripe 支付数据或 GitHub PR 状态送进 Notion 数据库。调度与凭据交给 Workers。如果“把某项数据放进 Notion，让团队都能看到”这件事已经拖了很久，就趁免费在本周完成。

加入 External Agent API 候补名单。如果已经基于 Cloudflare Agents SDK、Mastra 或 LangGraph 构建了 Agent，就用这个 API 把它们接入工作区，成为其中的参与者。不要等到 GA。

跳过 Custom Agents 重建。已经跑在真正支持持久执行的运行时上的 Agent，不要迁入 Notion Workers。Workers 适合做工具，不适合做编排。

Notion Workers 无法替代哪些 Cloudflare 能力

持久化工作流。Notion Workers 不具备步骤级缓存、可安全重放、持续数小时的持久执行能力。如果已经在使用 Cloudflare Workflows、Inngest 或 Temporal，继续保留。

Vectorize 与 embedding。Notion 没有向 Workers 暴露向量能力，记忆与 RAG 仍应留在自己的技术栈中。

公开 API 端点。Notion Workers 是从 Notion 内部调用的工具，不是供公网访问的 HTTP 服务。

间隔短于 5 分钟的 Cron 调度。对于紧密循环，Cloudflare Cron Triggers 配合 Agents SDK 的 this.schedule() 仍然胜出。

休眠 Agent 模式。Notion 的 Custom Agents 擅长单次工作流，但面对基于 Durable Objects 构建、拥有实例级存储的长期运行 Agent 时较弱。我在面向小企业的 Claude 技术栈中介绍过这种模式：六个专业 Agent，各自拥有记忆与调度。如今，它并不能干净地装进 Workers 沙箱。

准确的判断是：Notion Workers 可以替代 Zapier、AWS Lambda glue tier，以及为了给 Custom Agent 提供一个确定性工具而搭起的 200 行 Node 代码；它不能替代应用后端。我在讨论 Stainless 收购案时写过的多供应商问题，在这里同样成立：保持编排层可移植，把 Notion 当成交互入口，而不是运行时。

接下来 30 天要盯住什么

External Agent API GA。private beta 候补名单仍是门槛。一旦开放，每个使用 Mastra 和 LangGraph 的团队都会在当周推出 Notion 适配器。

8 月 11 日前公布 credits 费率。两种情形都真实存在，而且互不相容：每百万次低于 $1，Workers 就会成为不二之选的 glue layer；每百万次 $5+，采用范围就会被限制在已经深度绑定 Notion 的团队中。

合作伙伴 Agent 扩容。Claude Code、Cursor、Codex 和 Decagon 之后，谁会加入？重点关注 Replit Agent、Devin、Lovable，以及任何来自 Anthropic 生态的 Managed Agents 适配器。每增加一个合作伙伴，运营者就少一个离开 Notion 界面的理由。

Notion Agent SDK GA。这是一场倒置——Notion Agents 开始运行在其他工具内部。Notion 押注的护城河是数据，而不是工作区。如果两者都在 Q3 发布，Notion 争夺的将不再是界面，而是 Agent 本身。