Notion 自定义 Agent：从任务描述到权限治理
Notion 3.3: Custom Agents
01 · 先读这里
为什么推荐
从自然语言创建、事件驱动分诊到资源权限配置，展示了主动 Agent 的完整工作链，而不只是聊天入口。重点看触发后如何生成真实任务，以及管理员如何治理。
02
这篇讲什么
Notion Custom Agents 把团队反复出现的问答、请求分诊和项目汇报变成持续运行的自动化任务。用户先用自然语言描述工作，再检查触发器、指令、数据来源和模型；分诊 Agent 在请求出现时捕获信息、建立任务并路由负责人。资源级权限、连接管理、运行日志、撤销和停用能力约束自治范围。官方页面包含创建、分诊的产品动图及权限截图，适合研究主动式交互怎样进入业务对象和组织权限模型。官方客户效果是自述，非独立 UX 实验。
扩展评分
一句话带走
主动 Agent 要从业务事件进入流程，但必须保留可检查的配置与权限。
交互范式
交互到底改变了什么
- 原来的交互
- 手动查消息、建任务、分派责任人并跨工具复制信息。
- Agent 带来的变化
- 自然语言生成 Agent 配置，事件触发后自动更新任务对象。
- 用户的新成本
- 用户需理解触发条件、资源权限和错误路由的纠正责任。
- 关键交互机制
- 自然语言建 Agent；事件触发分诊；资源级权限；日志、撤销与停用。
- HCI 依据
- 原文未提供
- 团队设计信号
- 按问答、分诊、汇报场景展示价值，再展示配置与权限治理。
设计策略
从具体设计中学习
01
让用户描述工作而非先配置技术组件
- 看图重点
- 看任务描述怎样转成可调整的配置。
- 图像作用
- 官方产品 GIF
- 问题
- 用户知道目标却未必懂 Agent 配置。
- 方案
- 先描述工作，再调整触发器、来源、指令与模型。
- 为什么这样做
- 意图优先，逐步精化降低空白配置门槛。
- 取舍
- 根据方案推断：自动生成的规则仍需人工复核。
原文依据与解读
Build agents for every workflow
- 译文
- 为各类工作流构建 Agent。
- 解读
- 自然语言是入口，结构化配置是约束。
可迁移规则先收集目标，再暴露可检查的关键参数。
02
让分诊 Agent 在业务请求出现时自动接入
- 看图重点
- 看请求怎样变成任务记录并被分派。
- 图像作用
- 官方产品 GIF
- 问题
- 人工跨系统分类和路由容易漏办。
- 方案
- Agent 捕获请求、创建任务并路由负责人。
- 为什么这样做
- AI 从问答入口移到事件驱动的业务流。
- 取舍
- 根据方案推断：误分诊需有更正与审计入口。
原文依据与解读
Task routing agents automatically manage incoming requests
- 译文
- 分诊 Agent 自动管理新请求。
- 解读
- 主动式 AI 要产生业务对象而非只发消息。
可迁移规则触发后必须生成可追踪对象和责任人。
03
将数据权限设计为 Agent 上线前的显式配置
- 看图重点
- 看不同数据对象对应不同授权级别。
- 图像作用
- 官方产品截图
- 问题
- Agent 可能跨文档访问敏感数据。
- 方案
- 显式设置资源与访问级别，支持停用和审计。
- 为什么这样做
- 自治能力受已有工作空间权限约束。
- 取舍
- 根据方案推断：粒度增加治理负担，需最小权限默认值。
原文依据与解读
You control what Custom Agents see and do
- 译文
- 用户控制 Agent 能看和能做的内容。
- 解读
- 能力边界不能只藏在 Prompt 中。
可迁移规则提供数据范围、权限、日志和停用控制。
推理链
从问题到设计判断
- 问题
- 重复任务依赖人工整理与指派，Agent 权限也需要统一治理。
- 证据
- 官方创建与分诊 GIF、权限截图及客户案例。
- 判断
- Agent 入口是任务和事件，控制权在配置、权限和可追踪对象中。
- 设计策略
- 让用户描述工作而非先配置技术组件；让分诊 Agent 在业务请求出现时自动接入；将数据权限设计为 Agent 上线前的显式配置
- 结果
- 官方引用 Remote 每周节省约 20 小时、分诊准确率超过 95% 的客户自述；方法和样本未提供。
迁移原则
带回自己的项目
- 先收集目标，再暴露可检查的关键参数。
- 触发后必须生成可追踪对象和责任人。
- 提供数据范围、权限、日志和停用控制。
03
它真正解决的问题
重复任务依赖人工整理与指派，Agent 权限也需要统一治理。
04
作者用了什么依据
官方创建与分诊 GIF、权限截图及客户案例。
05
核心设计洞察
Agent 入口是任务和事件，控制权在配置、权限和可追踪对象中。
06
具体做了什么
让用户描述工作而非先配置技术组件：先描述工作，再调整触发器、来源、指令与模型。；让分诊 Agent 在业务请求出现时自动接入：Agent 捕获请求、创建任务并路由负责人。；将数据权限设计为 Agent 上线前的显式配置：显式设置资源与访问级别，支持停用和审计。
07
为什么这样做
重复任务依赖人工整理与指派，Agent 权限也需要统一治理。 → 官方创建与分诊 GIF、权限截图及客户案例。 → Agent 入口是任务和事件，控制权在配置、权限和可追踪对象中。 → 让用户描述工作而非先配置技术组件；让分诊 Agent 在业务请求出现时自动接入；将数据权限设计为 Agent 上线前的显式配置 → 官方引用 Remote 每周节省约 20 小时、分诊准确率超过 95% 的客户自述；方法和样本未提供。
08
有什么关键取舍
根据方案推断：自动生成的规则仍需人工复核。；根据方案推断：误分诊需有更正与审计入口。；根据方案推断：粒度增加治理负担，需最小权限默认值。
09
最终有没有验证
官方引用 Remote 每周节省约 20 小时、分诊准确率超过 95% 的客户自述；方法和样本未提供。
从这篇学习
值得学什么
先收集目标，再暴露可检查的关键参数。
触发后必须生成可追踪对象和责任人。
原文未提供
先确定需要人类判断的环节，再定义 AI 的行动边界。
Agent 入口是任务和事件，控制权在配置、权限和可追踪对象中。
以原文界面截图、机制与取舍说明设计判断。
10 · 迁移
可以带走什么
先收集目标，再暴露可检查的关键参数。
你的反馈
这篇对你有用吗？
反馈只会记录下来，不会自动改变推荐算法。