Notion 3.6：外部 Agent 进入团队看板与审计日志
Notion 3.6: External Agents, HTML blocks, and more
01 · 先读这里
为什么推荐
官方动图和审计日志截图可直接核对两种界面。它把 Agent UX 从能执行推进到能分派、能监督、能追责，非常适合企业级设计。
02
这篇讲什么
Notion 3.6 将 Claude、Cursor 等外部 Agent 纳入同一协作界面，用户可以从共享看板指派任务、在团队内容里 @mention，并查看其执行过程；与此同时，Custom Agent 的活动进入企业审计日志，记录运行、修改与触发者。这里值得拆的是两个互补界面：前台用既有任务对象组织人机协作，后台用结构化事件证明 Agent 的实际操作。官方同时发布交互式 HTML Blocks 等能力，但本期只聚焦任务编排与治理两条策略，避免将多个功能混为一谈。文章提供对应官方 GIF 和真实产品截图，未披露相关用户测试指标。
扩展评分
一句话带走
Agent 真正进入企业工作流，必须同时成为可分派的协作者和可审计的执行者。
交互范式
交互到底改变了什么
- 原来的交互
- 任务在团队看板，Agent 在外部 CLI/IDE，执行和日志分散。
- Agent 带来的变化
- 外部 Agent 进入共享看板协作，写入操作进入企业审计日志。
- 用户的新成本
- 需要理解 Agent 身份、授权边界、状态一致性及日志查询方式。
- 关键交互机制
- 共享看板指派；@mention 外部 Agent；执行跟踪；审计日志事件筛选。
- HCI 依据
- 原文未提供
- 团队设计信号
- 同时设计前台协作与后台治理，体现跨产品工作流的系统性思考。
设计策略
从具体设计中学习
01
让外部 Agent 成为看板中的任务参与者，而非游离在独立工具里
- 看图重点
- 观察看板任务、@mention 和外部 Agent 执行状态如何在同一协作界面关联。
- 图像作用
- 官方产品 GIF / 任务编排
- 问题
- 外部 Agent 在终端和 IDE 中独立工作，团队看不到任务进度或交付归属。
- 方案
- 在团队共享看板中指派外部 Agent，像协作者一样 @mention，并在同一界面跟踪运行。
- 为什么这样做
- 用原有任务对象承载 Agent 工作，减少跨应用协调和结果交接成本。
- 取舍
- 根据方案推断：跨工具任务状态可能存在同步延迟，且团队需要管理外部 Agent 的访问权限。
原文依据与解读
assign them tasks from a board
- 译文
- 直接从看板给这些 Agent 分派任务。
- 解读
- 任务卡是人机协作的共同工作对象，而不是仅用来展示 AI 结果的容器。
可迁移规则外部 Agent 接入复杂 B 端时，优先嵌入既有任务卡、责任人和状态流转。
02
将 Agent 操作写进可筛选的审计日志，而不是只显示一句完成
- 看图重点
- 观察 Date、Person or agent、Event 三种筛选，以及事件列表如何标识 Agent、动作和对象。
- 图像作用
- 官方产品截图 / 执行证据
- 问题
- Agent 修改内容后，管理员难以回答是谁触发、改了什么、何时发生。
- 方案
- 在审计日志中记录 Custom Agent 的运行、修改和触发者；界面支持按时间、操作者和事件筛选。
- 为什么这样做
- 将执行证据变成可追溯的结构化记录，支持排障、合规和责任界定。
- 取舍
- 根据方案推断：完整事件留痕提高日志量与审查负担；原文说明该能力面向 Enterprise。
原文依据与解读
what it changed, and who triggered it
- 译文
- 它修改了什么，以及由谁触发。
- 解读
- 执行成功是系统状态，谁对哪个对象做了什么才是人能审计的证据。
可迁移规则有写入权限的 Agent 必须保留操作者、对象、动作、时间与触发来源。
推理链
从问题到设计判断
- 问题
- 外部 Agent 的工作游离于团队任务界面，且修改记录难审计。
- 证据
- 官方发布展示共享看板分派外部 Agent 的动图及审计日志截图。
- 判断
- Agent 应进入现有协作对象，同时为写入行为提供独立留痕。
- 设计策略
- 看板任务分派 + Agent 审计事件。
- 结果
- 官方说明能力发布；效率、错误率和用户研究数据原文未提供。
迁移原则
带回自己的项目
- 把 Agent 放进原有任务对象和责任流转，不额外制造孤立 AI 工作台。
- 对任何会写入业务数据的 Agent，提供按人/Agent、时间、事件过滤的操作日志。
- 把任务状态和审计证据分层展示：一层服务执行，一层服务追责。
03
它真正解决的问题
跨应用 Agent 怎样进入团队协作，同时保证执行责任可追溯。
04
作者用了什么依据
官方产品发布、演示 GIF 和审计日志截图。
05
核心设计洞察
Agent 真正进入企业工作流，必须同时成为可分派的协作者和可审计的执行者。
06
具体做了什么
让外部 Agent 成为看板中的任务参与者，而非游离在独立工具里：在团队共享看板中指派外部 Agent，像协作者一样 @mention，并在同一界面跟踪运行。；将 Agent 操作写进可筛选的审计日志，而不是只显示一句完成：在审计日志中记录 Custom Agent 的运行、修改和触发者；界面支持按时间、操作者和事件筛选。
07
为什么这样做
外部 Agent 的工作游离于团队任务界面，且修改记录难审计。 → 官方发布展示共享看板分派外部 Agent 的动图及审计日志截图。 → Agent 应进入现有协作对象，同时为写入行为提供独立留痕。 → 看板任务分派 + Agent 审计事件。 → 官方说明能力发布；效率、错误率和用户研究数据原文未提供。
08
有什么关键取舍
根据方案推断：跨工具任务状态可能存在同步延迟，且团队需要管理外部 Agent 的访问权限。；根据方案推断：完整事件留痕提高日志量与审查负担；原文说明该能力面向 Enterprise。
09
最终有没有验证
原文未提供
从这篇学习
值得学什么
Agent 真正进入企业工作流，必须同时成为可分派的协作者和可审计的执行者。
把 Agent 放进原有任务对象和责任流转，不额外制造孤立 AI 工作台。
原文未提供
先识别原流程的认知或协作断点，再决定 Agent 在哪里提出建议、何时执行及怎样接受监督。
对任何会写入业务数据的 Agent，提供按人/Agent、时间、事件过滤的操作日志。
用真实任务、界面截图、操作顺序和明确证据构成案例，未公开效果不补写。
10 · 迁移
可以带走什么
把 Agent 放进原有任务对象和责任流转，不额外制造孤立 AI 工作台。
你的反馈
这篇对你有用吗？
反馈只会记录下来，不会自动改变推荐算法。