Notion 只让 MiniMax M2.5 做 Agents？当用户在别人的工作台里用你的 App 时

Notion 联合创始人 Akshay Kothari 宣布，Notion Custom Agents 已正式引入由 MiniMax 研发的开源权重模型 MiniMax M2.5，并作为实验性功能向全球用户开放，与 Claude Sonnet 4.6、Opus 4.6、Haiku 4.5 及 GPT-5.2、GPT-5.3 Codex 等主流闭源模型并列。新浪科技的快讯和多家科技媒体都提到，这是中国开源大模型首次进入 Notion 的核心模型选择列表。品玩的报道进一步强调，MiniMax M2.5 是目前列表中唯一的开源权重模型，对于简单任务的调用成本明显低于闭源模型。对所有做 B2B SaaS 和 App 的团队来说，更关键的问题是：当用户在 Notion 这个“别人家的工作台”里，通过 Custom Agents 用你的服务时，你还能看清楚自己的入口和流量真身吗？

Notion 为什么要在 Custom Agents 里选 MiniMax M2.5

从“只用几个头部闭源模型”到“混合模型生态”

在这次更新之前，Notion Custom Agents 的模型选择主要集中在几家闭源巨头：

• Anthropic 的 Claude 系列（Sonnet、Opus、Haiku）

• OpenAI 的 GPT-5.2 / GPT-5.3 Codex 等

这次更新之后，MiniMax M2.5 以“开源权重模型”的身份，首次独立列入 Notion 的模型选择列表，与这些闭源旗舰并列。36 氪快讯和香港经济通 ACN 报道都明确了这一点。媒体的解读主要集中在两个层面：

• 打破“只看闭源巨头”的垄断，让 Notion 更接近模型不可知（Model Agnostic）：

  • 用户可以按任务选择：写长文/创意找 Claude 或 GPT，做大量结构化整理/自动化任务则选成本更低的 MiniMax M2.5。

• 为自定义智能体（Custom Agents）提供更高性价比的底座：

  • 在文档整理、日程同步、数据库清洗等高频轻任务场景中，MiniMax M2.5 的调用成本显著低于闭源模型，被视为“生产力刚需选项”。

这种“混合模型生态”背后，是 Notion 对自己角色的重新定位：在它的官方更新说明中，Custom Agents 被形容为“自动化请求路由和任务管理的 AI 同事”，用户可以给它指定工作、触发条件和模型，然后让它 7×24 小时在后台跑工作流。Notion 的官方更新页也强调了这一点。

Notion 本身已经是一个“应用内操作系统”

目前的 Notion 已经不只是“笔记 + 文档”工具，而是一个集：

• 文档

• 笔记

• 数据库

• 项目管理

于一体的全能工作台，全球用户数超过 1 亿，广泛覆盖个人效率管理和团队协作场景。新浪与 36 氪的多篇报道都提到这一点。在这种架构下，Custom Agents 本质上是：

• Notion 内部的“智能操作系统”，负责理解用户在页面、数据库上的意图；

• 再通过集成接口调用你的服务，例如拉取任务、创建记录、同步状态或生成内容片段。

当 MiniMax M2.5 这种成本更低、面向 Agent 工作流优化的模型进入 Custom Agents，Notion 就拥有了一个更便宜、更易定制的“AI 工人”；而对你来说，这则意味着：你的 App 可能被卷入越来越多的 Notion 工作流中，变成“别人工作台里的一个工具块”。

当用户在 Notion 里用你的 App 时，入口变成了什么样

用户入口从“你的产品界面”前移到了“Notion 页面”

此前，用户使用你的 App，路径一般是：

浏览器 / 应用商店 → 你的官网 / 应用详情页 → 注册登录 → 在你的界面里完成任务。

在 Notion + Custom Agents 的环境中，路径更像这样：

• 用户在 Notion 打开一个项目看板、需求表或 OKR 页面；

• 在某条记录、某个数据库视图或一个侧边栏中，通过自然语言给 Custom Agent 一段指令；

• Agent 解析意图后：

  • 先用所选模型（例如 MiniMax M2.5）做整理、筛选或决策；

  • 再通过集成接口调用你的服务，创建任务、拉取数据或触发自动化；

• 用户感知到的是“在 Notion 里把事办完”，你的 App 扮演的是“在背后干活”的角色。

对用户来说，入口是 Notion 的页面和 Agent 面板； 对你来说，很容易只看到一堆“来自 Notion 集成的 API 请求”，而看不到：

• 请求来自哪个 Workspace、哪个页面或哪个工作流；

• 它是一次性的轻量操作，还是一个长期任务的一部分；

• 这些使用背后，到底有多少用户真正变成了你的高价值客户。

智能体工作流正在重排“谁拥有用户界面”

随着 Custom Agents 在 Notion 中逐渐成熟，加上官方博客对“为每个工作流创建 Agent”的鼓励，Notion 更新页中提到内部已经有超过 2800 个 Agent 在 7×24 小时持续运行。这会带来一种新格局：

• 用户把“看板、数据库、文档和对话”都放在 Notion，视其为“数字工作台”；

• 各家 SaaS 和 App 则以“插件、集成、工具”的形态出现在工作流底部；

• 真正的入口不再是一堆独立产品的菜单，而是 Notion 页面结构和 Agent 对话。

这对你来说，有好有难：

• 好的一面：

  • 通过 Notion 这种平台级入口，你有机会触达大量原本很难直达的高价值团队和用户；

  • 用户不必完整学会你的产品 UI，也能通过 Agent 调用你最核心的那几类能力。

• 难的一面：

  • 大量使用行为发生在 Notion 的上下文中，你自己的 App 视角很容易只剩下一串“调用记录”；

  • 如果没有合理的标识和归因，你在报表里看到的只是“Notion 集成调用次数”，而看不到哪些路径和用户真正值得加深合作和投入。

在“别人的工作台”里，怎么重构入口设计与归因

给 Notion 和不同工作流一人发一张“名片”：IntegrationCode / ChannelCode

第一步，仍然是统一命名和编号，把 Notion 视作一个渠道，再细化到不同工作流。

在你自己的系统中，可以建立一套命名惯例，例如：

• IntegrationCode=NOTION-CUSTOM-AGENT：

  • 表示调用来自 Notion Custom Agents 集成整体。

• ChannelCode=NOTION-TASK-AUTO-ASSIGN：

  • 表示由“任务自动分配”工作流触发的调用。

• ChannelCode=NOTION-DB-SYNC-CRM：

  • 表示从 Notion 数据库同步到你们 CRM 的工作流。

• ChannelCode=NOTION-DOC-SUMMARY-EDITOR：

  • 表示在文档页面中使用的“总结并推送到你们 App”功能。

这些编码可以通过：

• 在 Notion 集成配置页面，由管理员在连接时选择/输入；

• 或在你们提供给 Notion 的集成说明中，约定好不同工作流所使用的 ChannelCode；

• 后端在接收请求时，从 Header 或参数中读取并写入日志。

如果你的产品同时在多个平台提供类似集成（如 Slack、飞书、Jira 等），同一套 ChannelCode 体系也可以横向复用，把“Notion 工作台里的调用”与其他渠道区分开来，最终统一进你们自己的全渠道统计体系中。配合 Xinstall 的全渠道统计能力，未来还可以把这些来源贯穿到 App 安装和激活端。

用智能传参安装，把“是哪个 Workspace、哪种场景带来的用户”带进 App

很多团队会在 Notion 集成中提供“进一步使用请打开 App / Web 端”的入口：

• 在 Notion 里提供轻量操作和预览；

• 真正深入使用则需要跳转到你的产品界面。

典型入口包括：

• Notion 页面中的按钮链接；

• Custom Agent 回复中的超链接；

• 页面右侧的“在某某 App 中打开”按钮。

如果这些链接只是普通 URL，你只能知道“来自 Notion”，看不到更细维度。通过智能传参安装/拉起，可以这样设计：

• 对每个 Workspace + 工作流生成带参数的链接，例如：

  • https://www.xinstall.com/?integration=NOTION&workspace_id=xxx&scene=db_sync&channel=NOTION-DB-SYNC-CRM

• 对尚未安装 App 的用户：

  • 该链接先落到中转页，触发对应应用商店安装；

  • 安装后通过 Xinstall 的智能传参 将参数还原，带入 App。

• 对已安装 App 的用户：

  • 通过深度链接直接拉起 App，并打开正确的项目、任务或页面。

在 App 首启或拉起时：

• 解析这些参数并写入用户画像：

  • integration=NOTION

  • workspace_type=team/individual

  • scene=db_sync/task_auto_assign/doc_summary

  • channel=NOTION-DB-SYNC-CRM 等；

• 用于：

  • 带着正确上下文打开页面；

  • 面向不同 Workspace 类型和场景，展示不同的引导和功能建议；

  • 后续分析“哪些 Notion 场景更容易把用户引流到你们自己的产品里深度使用”。

在数据仓里维护一张“工作台集成事件图”

要真正看清“用户在别人的工作台里用你的 App”的价值，建议在数据仓里单独维护一张“工作台集成事件图”：

• 平台事件：

  • 来自 Notion 的调用：触发时间、工作流类型、成功/失败、耗时；

  • 来自其他工作台（如 Slack、飞书）的类似事件。

• 跳转事件：

  • 从 Notion 跳到你的 Web / App；

  • 通过带参链接安装/拉起的行为。

• App 内事件：

  • 首次使用某个模块、完成关键任务、付费/续费、升级等。

通过 IntegrationCode、ChannelCode 和传参与用户 ID，把这些事件串起来，就可以回答：

• 哪一类 Notion 工作流（任务自动化、数据库同步、文档协作）最容易带来高价值用户？

• Notion 中的“轻量调用”有多少真正沉淀为你产品中的深度使用？

• 与其他平台集成相比，Notion 渠道带来的生命周期价值和留存表现如何？

这些结论会反向指导你：

• 要不要在 Notion 渠道上继续加大集成功能和合作资源投入；

• 哪种 Agent 使用方式（例如“主动推荐 + 一键创建” vs “被动按钮触发”）更值得推广。

这件事和开发 / 增长团队有什么关系

对开发者：把你的产品做成“可被工作台智能体安全调用的服务”

从工程角度看，Custom Agents + MiniMax M2.5 这类低成本模型组合，会让平台更愿意在后台大量跑 Agent 工作流，这自然会带来更多自动调用你服务的机会。开发侧可以提前：

• 提供标准化、文档良好的 API/SDK 作为“智能体工具”：

  • 避免让 Agent 通过页面抓取、宏脚本等脆弱方式调用你的产品。

• 在接口协议中预留集成与渠道标识位：

  • 例如通过 Header 或参数传递 IntegrationCode、ChannelCode。

• 在权限与安全上区分：

  • Notion Agent 调用 vs 用户直接调用；

  • 不同 Workspace 的配额与速率限制；

  • 使用审计日志追踪和回溯“智能体误操作”的可能。

对增长团队：把 Notion 视作“入口前置的超级渠道”

增长视角下，Notion 具备典型“超级入口”特征：

• 用户量级超过 1 亿，且高度集中在知识工作者和团队协作人群；

• 使用场景以任务、项目和知识管理为核心，而不是纯内容消费；

• Custom Agents + 多模型选择，使得“在一个地方调用多种服务”变得非常自然。

这意味着：

• 你可以把 Notion Custom Agents 看成一个新的“应用商店 + 搜索 + 推荐 + 工作流编排”的复合渠道；

• 通过合理的集成与体验，把你的 App 放到更多高频工作流中；

• 用前面提到的 ChannelCode + 智能传参与事件图，把这些入口从“黑盒流量”变成“可分析、可优化”的长期渠道。

只要你能在数据层面回答：

• 哪些 Notion 工作流真正带来了高价值用户和收入；

• 哪些集成功能几乎没人用，或者只是刷调用量；

就可以针对性迭代产品和商务策略，而不是“凭感觉押注”。

常见问题（FAQ）

我们现在没有 Notion 集成，关注这些是不是太早？ 即便暂时没有 Notion 集成，未来你很可能会接入一个或多个“工作台级”平台（包括国内外的文档、协作与项目管理工具）。提前在内部用 ChannelCode、智能传参与事件图搭好“第三方工作台集成”的通用框架，可以保证以后每接入一个新平台，都能快速纳入同一套归因和分析体系，而不必每次从零设计。

如果 Notion 自己也有使用报表，我们还需要自建归因吗？ Notion 的报表能很好告诉你“在我这里，用户怎么用你的集成”，但它看不到：

• 用户跳出 Notion 后，在你产品里的深度使用和付费情况；

• 用户从其他渠道（广告、直连、其他平台）来的行为对比。

自建一套围绕 IntegrationCode、ChannelCode 与事件图的归因，是为了把 Notion 视作众多渠道中的一个，用统一口径进行比较和决策，而不是完全依赖任何单一平台的视角。

MiniMax M2.5 是开源权重模型，这对我们有什么额外影响？ 对你而言，更直接的影响在于：

• 平台在成本敏感场景下更愿意频繁使用 Agent 工作流，这意味着更多自动调用你服务的机会；

• “国产模型 + 海外平台”的组合，会让你的集成有机会被更多国内外团队看到和尝试。

从入口设计和归因角度看，你不需要直接对接 M2.5，但要意识到：它可能让 Notion 这类平台在后台更频繁、更加“无感”地调用你的服务，越早把这些调用纳入可观测、可分析的体系，就越不容易错过这波隐形增量。

行业动态观察：从“谁家的模型更强”到“谁掌握了工作台入口”

Notion 引入 MiniMax M2.5 作为首个开源权重模型，并把它和 Claude、GPT 系列放在同一模型列表里，本身说明一件事：模型之争正在从“闭源 vs 开源”“谁跑分更高”转向“谁更适合跑在具体工作流里”。Notion 的官方更新页和外部媒体都强调了“给每个工作流一个专属 Agent”的方向，这意味着未来大量用户任务会在工作台级产品中发起和完成。

对 App 和 B2B 团队来说，这次变动更像是一声提醒：

• 未来用户完成任务的主界面，可能越来越集中在少数几个工作台里；

• 真正被频繁调用的，是那些以 API 和集成形态嵌在工作流里的服务；

• 谁能更早用清晰的入口设计、ChannelCode 和智能传参，把这些“嵌在别人的工作台里”的流量看清楚、用起来，谁就更有可能在这轮 AI + 工作流的洗牌中变成关键节点，而不是被平台吃掉名字的“无名工具函数”。