Notion：Custom Agents、Evals 与 Future of Work 学习笔记

Table of contents

1. 背景与问题

1.1 视频试图回答的核心问题

这段访谈围绕一个更具体的问题展开：

当 AI 从“聊天助手”走向“后台执行的工作代理”时，产品、权限、工具接口、评估体系、组织协作方式需要如何一起变化？

从字幕看，Notion 的核心判断包括：

• Agent 不是简单的“把 LLM 接上工具”就能稳定落地。
• 真正可用的 Agent，必须同时解决：
  • 可靠性
  • 权限边界
  • 工具可用性
  • 数据表示方式
  • 评估与回归控制
  • 组织内的维护机制

📡 扩展
Notion 在 2026-02-24 正式发布 Custom Agents，其定位不是普通聊天助手，而是可以“给它一个任务、配置触发器或定时器，然后让它 24/7 在后台执行”的自治式 Agent。官方给出的例子包括：任务分拣、内部问答、每日站会摘要、Inbox Zero 等。这与字幕中“后台运行”“更高可靠性”“精细权限配置”的强调完全一致。
参考：Notion 3.3 发布说明、Notion 博客《Introducing Custom Agents》。

1.2 为什么这个问题重要

字幕里有一个很关键的隐含前提：

Notion 不只是做 AI 功能，而是想继续做 enterprise work 的 system of record（企业工作的事实与记录中心）。

这意味着 Notion 做 Agent 时，不只是追求“能回答”，而是追求：

• 能读写工作上下文
• 能在权限约束下执行动作
• 能被团队持续复用
• 能和已有工作流共存，而不是把用户数据搬到另一个孤岛里

📡 扩展
Notion 官方对 Notion MCP 的定义，是“让 AI 工具安全访问你的 Notion 工作区的托管 MCP Server”；其目标就是把 Notion 变成 Claude、Cursor、VS Code、ChatGPT 等工具都能安全调用的工作上下文层。这与访谈里“system of record”与“我们会一直支持 MCP”的表述高度一致。
参考：Notion Docs《What is Notion MCP?》《Connecting to Notion MCP》。

2. 核心概念

2.1 关键术语总表

2.2 MCP

字幕中的观点：

• Simon/Sarah 并没有“否定 MCP”
• 他们认为 MCP 很适合：
  • 窄任务
  • 轻量 Agent
  • 强权限约束
• 但对更高自由度、更强自举能力的 agent，CLI 可能更强

📡 扩展
MCP（Model Context Protocol）官方定义是：一种把 AI 应用连接到外部系统的开放标准，用于共享上下文、暴露工具、构建组合式工作流。规范层基于 JSON-RPC 2.0，角色通常分为 Host、Client、Server。
Anthropic 最早在 2024-11 公布 MCP；截至 2025-11 的规范文档，MCP 已明确支持 tools、resources、prompts 等能力对象。
这意味着访谈里“它是 dumb simple thing that works”并不是贬义，而是在说：它的边界清晰、协议简单、权限可控，因此很适合生产环境里的一类集成问题。
参考：Anthropic《Introducing the Model Context Protocol》；MCP 官方规范。

2.3 Evals

字幕中的观点：

Evals 不是一个单点概念，而像“测试”的总称：

• 类似 unit tests / regression tests 的部分可以进 CI
• 产品开发阶段会有更贴近用户任务的评估
• 夜间跑批、模型快照对比、回归检测也都属于 eval
• 有些回归可以接受，只要它换来了更低延迟或更低成本，并且这是“被理解的回归”

📡 扩展
OpenAI 官方对 evals 的定义是：检查模型输出以及生成过程是否符合预期。核心价值不是“凭感觉调 prompt”，而是把“是否变好”转换为可度量的问题。
这与视频里“不是 vibes，而是理解 regressions / latency / quality tradeoff”的工程思想高度一致。
参考：OpenAI《Testing Agent Skills Systematically with Evals》、OpenAI Evals Cookbook、OpenAI《How evals drive the next chapter in AI for businesses》。

2.4 Agent harness

从字幕语境看，agent harness 不是单一工具，而是一个共用执行底座：

• 同一套 harness 上可以承载多种 agent 服务
• 团队可以反复重构 harness，而不是死守旧架构
• 后期他们还把 eval system 也按 harness 思路来设计
• 目标是让 agent 能下载数据集、跑 eval、观察失败、调试、修复

可把它理解成：

“统一运行与迭代 agent 的底盘”

2.5 System of record

访谈中这是 Notion 的战略锚点。

它的含义不是“数据库”这么窄，而是：

• 用户的文档、任务、数据库、会议记录、团队协作上下文，本来就已经在这里
• 因此 Agent 最有价值的地方，不是把用户拉去新工具，而是直接在现有工作发生地执行工作

📡 扩展
Notion 官方对其 AI 与 MCP 的定位都在强化这一点：让 AI 直接在用户已有 Notion 工作区里读写、执行、复用，而不是把上下文复制到另一个外部 Agent 平台。
这也是为什么访谈里强调“most of the information should live here”。
参考：Notion AI 产品页、Notion MCP 文档。

3. 主体内容

3.1 从“早期尝试”到“可上线产品”的演化

访谈给出的一个核心经验是：

不是没有想到 Agent，而是太早想到了；真正难的是：什么时候模型、产品、权限体系、组织能力同时成熟到够用。

flowchart TD
    A([早期设想：让 Notion 工具在后台为人工作]) --> B[多次尝试<br>模型能力不足 / 体验不稳定]
    B --> C{问题出在哪?}
    C -->|模型本身还不够| D[等待 Frontier 模型能力提升]
    C -->|产品/权限设计没跟上| E[重做权限、共享、管理员可见性]
    C -->|数据表示不适合模型| F[重做数据接口与表示层]
    C -->|工程底座不适配| G[多次重构 agent harness]
    D --> H[Claude Sonnet 代际能力提升]
    E --> I[Custom Agents 产品化]
    F --> I
    G --> I
    H ==> I
    I ==> J([可在后台运行的自治 Agent])

这段演化最值得记的不是“某个模型变强了”

而是：

1. 能力成熟不是单一变量
2. 需要同时满足：
   • 模型够稳
   • 权限够清楚
   • 用户能理解 agent 会做什么
   • 管理员知道 agent 能访问什么
   • 团队能持续评估与维护它

📡 扩展
Notion 在 2026-02-24 发布 Custom Agents 时，明确把它定位成“可设置触发器或定时器的自治代理”；这说明视频里谈到的“后台执行 + 权限边界 + 共享与访问理解”最终已经进入正式产品形态。
参考：Notion 3.3 发布说明、Notion 博客《Introducing Custom Agents》。

3.2 MCP vs CLI vs Full Coding Agent

这是整期最有价值的判断之一。

结构化对比

访谈里的关键判断

• MCP 不是过时方案
• 它是适合某一类任务的正确方案
• CLI 之所以强，是因为 Agent 可以在同一环境里“给自己补工具、修 bug、继续执行”
• 但能力越大，权限与安全问题越不是协议层自动帮你兜底的

flowchart TD
    A([选择什么执行接口?]) --> B{任务形态}
    B -->|轻量 / 窄能力 / 强权限| C[MCP]
    B -->|需要更强自举与工程灵活性| D[CLI-based agent]
    B -->|复杂端到端开发执行| E[Full coding agent]
    C --> F[简单、可控、易集成]
    D --> G[可修复自身工具链]
    E --> H[能力最强但治理最重]

📡 扩展
MCP 官方文档强调其目标就是为 AI 应用提供统一的上下文与工具接入标准；Notion 官方也将 Notion MCP 描述为“安全访问工作区的托管服务器”，可与 Claude Code、Cursor、VS Code、ChatGPT 等集成。
因此，这期视频不是在讲“MCP vs 非 MCP 的胜负”，而是在讲：
MCP 更像标准化、收敛边界的连接层；CLI 更像高自由度代理执行层。
参考：MCP 官方文档、Notion MCP 文档。

3.3 真正的难点：权限模型与后台信任

字幕里有一句非常关键：

Custom Agents 默认没有权限，必须显式授予权限。

这句话的重要性在于：

• 前台对话式 AI 出错，用户还能及时发现
• 后台自治式 Agent 一旦出错，影响是延迟暴露的
• 所以后台 Agent 的前提不是“更聪明”，而是“更可信”

flowchart TD
    A([Custom Agent 默认无权限]) --> B[显式授予能力]
    B --> C[读取哪些内容]
    B --> D[能否写入 / 修改]
    B --> E[能否发邮件 / 调 Slack / 建任务]
    C --> F{权限边界清楚吗?}
    D --> F
    E --> F
    F -->|是| G([可以放心让它后台运行])
    F -->|否| H([不能进入自治执行阶段])

可记录的产品原则

• 后台 Agent 的可用性 = 能力 × 信任
• 信任来自：
  • 默认无权限
  • 显式授权
  • 管理员可理解
  • 分享与访问范围可解释
  • 执行动作有边界

📡 扩展
Notion 的官方文档同样强调，连接 Notion MCP 后，AI 工具只能基于用户已有访问权限读写工作区内容。
换句话说，Notion 并不是把 AI 放到权限体系之外，而是让 AI 变成权限体系里的一个执行体。
参考：Notion Docs《Connecting to Notion MCP》。

3.4 “Give models what they want”：数据表示必须向模型妥协

这一段非常值得单独记。

他们踩过的坑

坑 1：面向 Notion 数据模型设计，而不是面向模型设计

• 早期他们用一种能无损映射 Notion blocks 的 XML 格式
• 对工程来说很优雅
• 对模型来说却不友好

坑 2：数据库查询接口太像内部 API，而不像模型熟悉的表达

• Notion API 原本是复杂 JSON 查询
• 他们后来改成更接近 SQLite 的查询方式
• 因为模型对 SQL / SQLite 的熟悉度更高

核心结论

不要执着于“最忠实内部结构”的接口；要优先考虑“模型最容易稳定使用”的接口。

flowchart TD
    A([数据接口设计]) --> B{先满足谁?}
    B -->|满足内部系统映射| C[无损 XML / 复杂 JSON API]
    B -->|满足模型使用习惯| D[Markdown / SQLite 风格接口]
    C --> E[工程上优雅]
    C --> F[模型不熟 / prompt 成本高 / 使用不稳]
    D --> G[模型熟悉]
    D --> H[调用更自然 / 质量更高]
    F --> I([重构])
    H --> J([Give models what they want])

📡 扩展
这类经验与当前主流 Agent 工程实践高度一致：很多时候最有效的接口不是“理论上最抽象的接口”，而是模型训练分布里最常见、最易推理的接口形式。
从 OpenAI、Anthropic、MCP 社区的实践看，Markdown、SQL、结构化工具 schema、清晰资源对象，都比“自创复杂 DSL”更容易获得稳定结果。
参考：OpenAI 开发者文档、MCP 文档、Notion MCP 文档。

3.5 Evals 不是“评估模块”，而是 Agent 开发速度平台

Sarah 在字幕里给出了非常工程化的表述：

他们投入了一整个组织去做 agent dev velocity

这句话值得翻译成更直白的话：

Eval 做得越好，团队越能放心地更快迭代 Agent。

他们的做法可以整理成一个 Eval 飞轮

flowchart TD
    A([新能力 / 新模型 / 新工具]) --> B[定义目标任务与成功标准]
    B --> C[编写团队自有 eval]
    C --> D[接入 CI / 夜间跑批 / 回归监控]
    D --> E{结果如何?}
    E -- "通过" --> F[上线 / 放量 / 继续监控]
    E -- "失败" --> G[定位失败模式]
    G --> H[调 prompt / 工具 / 权限 / 模型 / 产品交互]
    H -.-> C
    F -.-> I[新模型快照对比]
    I -.-> D

这里最重要的不是“跑分”，而是“分层评估”

可以把视频里的 eval 体系拆成 4 层：

📡 扩展
OpenAI 官方材料强调：eval 的真正价值在于把“感觉更好”转成“可以验证的改进”，而且要围绕业务目标定义指标。
这与访谈里“接受某些质量回归，以换取合理延迟/成本，只要你知道自己在失去什么”的表述完全一致。
参考：OpenAI《Testing Agent Skills Systematically with Evals》、OpenAI《How evals drive the next chapter in AI for businesses》。

3.6 把 Eval 系统也当成 Agent Harness

访谈里一个更前沿的观点是：

Eval system 本身也可以 agent 化。

也就是：

• Agent 下载数据集
• 运行 eval
• 发现失败
• 调试原因
• 提出修复
• 实施修复
• 人在外层监督

这不是“模型完全自主”叙事，而是：

把评估与迭代流程尽量转换成 agent 可操作的问题。

3.7 组织设计：不是少数天才做 Demo，而是让很多团队可维护地交付

字幕里能看到 Notion 的几个组织原则：

1. 愿意反复删代码、重构 harness
2. 管理边界较松，快速 swarm 到问题上
3. 不是少数 AI 团队包办所有能力
4. 产品团队要拥有自己接给 Agent 的工具质量
5. 每个团队维护自己的 eval，而平台团队维护 eval framework

这其实是一种很明确的组织分工：

flowchart TD
    A([Agent 平台团队]) --> B[维护 harness / eval framework / 基础设施]
    C([产品团队]) --> D[维护各自工具质量与产品任务]
    E([模型行为/数据/UX 角色]) --> F[观察失败模式 / 标注 / triage / 改进建议]
    B <--> D
    D <--> F
    B <--> F
    B ==> G([提升 agent dev velocity])

对个人学习最有价值的点

这说明未来做 Agent，不只是“会写 prompt”的工作。

还会越来越需要：

• 工具设计
• 数据表示设计
• 评估设计
• 故障归因
• 权限设计
• 产品交互设计

📡 扩展
Notion 在发布 Custom Agents 后，很快又在 2026-03-20 推出 Custom Skills，允许把重复 AI 任务封装成可复用命令，并在 agent chat 中 @ 调用。
这说明他们正在把“个别 agent 能做什么”，继续演进成“团队可以沉淀哪些可复用工作能力”。
参考：Notion 发布说明《Custom skills for Notion AI》。

3.8 Future of Work：Software Factory 的含义

视频里“future of work”最接地气的表达，其实不是宏大叙事，而是：

• bug triage 自动化
• inbox / 邮件处理自动化
• 表单/租约填写自动化
• agent 直接在 Slack / 邮件 / 数据库之间做流转
• 让流程尽量不掉链子

一个典型内部例子：Slack 中的 Bug Triage

sequenceDiagram
    participant U as 员工
    participant S as Slack
    participant A as Custom Agent
    participant N as Notion任务库
    participant T as 对应团队

    U->>S: 在频道里报告问题
    S->>A: 触发消息事件
    A->>A: 根据 routing constitution 判断归属团队
    A->>N: 创建任务 / 记录上下文
    A->>S: 回复频道，说明已归档或分派
    N->>T: 团队在任务库中继续处理

这一案例的本质

它不是“替代工程师”，而是：

• 替代低价值的路由流程
• 减少信息遗漏
• 让上下文沉淀到 system of record
• 让人把精力放到真正的判断与处理上

📡 扩展
Notion 官方对 Custom Agents 的典型用例也包括 task triage、internal Q&A、daily standups、inbox 处理等，和字幕中的内部实践高度对应。
参考：Notion 3.3 发布说明。

4. 实践案例

4.1 Case 1：Slack Bug Triage

场景

员工在 Slack 里反馈问题。

Agent 做什么

• 识别问题类型
• 根据“路由宪法（routing constitution）”判断归属团队
• 在任务数据库建单
• 回写 Slack 结果

价值

• 减少信息遗漏
• 降低跨团队转派成本
• 把非结构化反馈转成结构化工作项

4.2 Case 2：邮件 / Inbox Zero

场景

用户希望自动化处理邮件、标签、分类、摘要。

价值点

• 更适合后台 Agent
• 但前提是权限清楚
• 典型问题不是“能不能读邮件”，而是“能不能安全地只做被允许的动作”

4.3 Case 3：文书/租约填充

场景

表单、租约、资料补全等重复流程。

价值点

• 能联网搜索补充外部信息
• 能把结果更新回原有工作流载体
• 用户不需要把材料搬进一个陌生系统

5. 可迁移的方法论

5.1 做 Agent 时，优先检查这 7 件事

5.2 一个很实用的判断框架

flowchart TD
    A([要不要上 Agent?]) --> B{任务是否重复且规则可归纳?}
    B -- "否" --> C([先保留人工主导])
    B -- "是" --> D{是否需要后台自治执行?}
    D -- "否" --> E([先做对话式/半自动助手])
    D -- "是" --> F{权限和边界能否清晰表达?}
    F -- "否" --> G([先补权限模型与审计能力])
    F -- "是" --> H{是否有持续 eval 与回归监控?}
    H -- "否" --> I([先补 eval，再放量])
    H -- "是" --> J([进入可控自治阶段])

6. 核心结论

6.1 一句话结论

Agent 时代真正的竞争力，不只是模型接得快，而是能否把“权限、工具、数据表示、评估、组织协作”一起工程化。

6.2 这期视频最值得记住的 10 条

1. MCP 仍然非常重要，尤其适合轻量、窄边界、强权限控制的 agent。
2. CLI-based agent 更自由，但安全边界和治理复杂度也更高。
3. 后台 Agent 的核心门槛不是炫技，而是可信。
4. 默认无权限 + 显式授权 是自治 agent 的关键产品原则。
5. 不要强迫模型适应你的内部接口，要主动把接口改成模型更擅长的形式。
6. Markdown / SQL/SQLite 这类“模型熟悉表示”通常更稳。
7. Evals 不是一个测试脚本，而是一套提高 agent 开发速度的平台能力。
8. Eval 需要分层：CI、回归、产品任务、快照对比、人工 triage。
9. 组织上要允许删代码、重做 harness、快速重组团队。
10. 未来工作流更像 software factory：人负责约束、判断、监督，agent 负责执行、路由、修复、迭代。

6.3 对你自己做技术学习/产品判断的建议

• 如果你在看 Agent 产品，不要只问“能不能做”
  要问：权限怎么收、失败怎么发现、谁来维护 eval、接口是不是顺着模型设计
• 如果你在做知识工作自动化，优先找：
  • 重复
  • 有上下文
  • 权限可控
  • 可回写 system of record 的场景
• 如果你在搭企业内 Agent，先把 MCP + 权限 + eval 打扎实，再谈 fully autonomous

7. 可继续延伸的知识节点（Obsidian 双链建议）

• MCP（Model Context Protocol）
• Agent Evals
• Agent Harness
• System of Record
• Custom Agents
• Progressive Disclosure
• Software Factory
• Markdown as Model Interface
• SQL/SQLite as Agent Interface
• AI 权限模型设计
• Agent Dev Velocity

8. 参考资料

1. Notion 3.3: Custom Agents
2. Introducing Custom Agents - Notion Blog
3. Notion MCP Docs
4. Connecting to Notion MCP
5. Build your own MCP client for Notion
6. Model Context Protocol - Intro
7. MCP Specification
8. Anthropic: Introducing the Model Context Protocol
9. OpenAI: Testing Agent Skills Systematically with Evals
10. OpenAI Evals Cookbook
11. OpenAI: How evals drive the next chapter in AI for businesses
12. Notion: Custom skills for Notion AI

9. 备注

• 本笔记以字幕为主进行整理；未逐句核对音频。
• 凡是明显属于字幕误听的技术名词，已按行业语境直接修正。
• 涉及具体发布日期、官方定义、官方产品能力的部分，均以官方文档为准。