搭了 16 个 Notion Custom Agent，活下来 4 个。
二月初我开始正式折腾 Agent，邮件处理、任务管理、笔记整理、数据同步……能想到的场景都试了一遍。一个月后回头看，4 个还在用，9 个暂停了，3 个彻底失败。存活率 25%。
这篇不是教你怎么创建 Agent 的教程（那些内容可以看这篇入门指南）。这篇想聊的是——在真正把 Agent 用起来、用一阵子、然后有的停掉之后，我学到了什么。
教训一：增量信息才值得自动化，存量信息别碰
这是我花了最多时间才想明白的一件事。
我做了两个 Agent 专门处理存量信息：随机笔记重逢和随机任务重逢。思路很简单——Notion 里积累了几百篇笔记和几百条任务，让 Agent 每天随机挑几条推送给我，帮我「重新发现」遗忘的内容。
听起来很美，实际效果很差。
存量信息的量太大了，Agent 每次随机挑出来的内容和当下的需求完全不匹配。看了几天之后，我开始直接忽略推送。两个最终都停掉了。
反过来，处理增量信息的 Agent 效果明显好得多。比如今日小事整理——我在 Notion 里有一个零门槛的收件箱，想到什么随手丢进去，不用考虑分类和排期。这个 Agent 每天早上自动跑一遍，把昨天未完成的任务提取到今天继续执行。范围小、信息新、每天都在产生实际有用的结果。
结论：Agent 擅长的是「新东西进来，帮你处理好」，不是「翻出旧东西让你看看」。设计 Agent 时，优先考虑增量场景。
教训二：不是所有事都该自动化
任务跟进助手一开始设的是页面更新时自动触发，每当任务页面有变动，它就自动跑一遍，然后把任务的下一步动作写入备注字段，然而很多时候我只是改了个标签或者加了行笔记，Agent 就兴冲冲跑来「跟进」，输出的内容完全不是我需要的。
后来改成手动呼叫：需要的时候 @它，不需要就安静。效果反而好了，因为手动呼叫意味着你带着明确目的，Agent 的输出更符合预期。
类似的情况出现在好几个 Agent 上。我现在的原则是：除非场景天然适合自动化（比如邮件来了就处理、定时汇总当天数据），否则默认用手动呼叫。
自动化不等于更好——这句话用在 Agent 上尤其成立。
教训三：检测到了但没有下一步，等于白搭
软件更新检查 Agent 的功能很单纯：定时检查我关注的几款软件有没有新版本。检测能力没问题，也能给我发送通知 ✅ 确实能发现更新。但然后呢？它告诉我「XX 软件更新到了 v2.3」，然后就没有然后了。没有自动创建任务，没有触发下一个流程，只是「通知」了我一下。
几天后，这个通知就和其他一堆消息混在一起，我根本不会专门去处理。最终我暂停了它。原因不是检测能力不行，而是动作链不完整。
一个好的 Agent 需要完整的链路：触发 → 处理 → 落地。如果最后一步「落地」缺失——不管是写入数据库、创建任务、还是触发下一个流程——整个 Agent 就是在做无用功。
教训四：给每个 Agent 一个独立记忆页
这是我最近在实践的一个技巧。
Notion Custom Agent 每次被触发时，能读取指定的页面作为上下文。我的做法是给那些需要更多上下文的 Agent 创建一个独立的「记忆页」，Agent 每次运行时读取这个页面，运行完把关键信息写回去。
以邮件智能代理为例，它需要记住之前处理过哪些邮件、用户偏好是什么、哪些规则是后来新增的。有了记忆页之后，它的行为一致性大幅提升，不会重复处理同一封邮件，也不会忘记后来加的规则。
具体做法：
- 在 Agent 的知识库文件夹里创建一个页面，命名为「XX Agent 记忆」
- 在指令里加一句：每次运行前先读取这个页面，运行后更新它
- 让 Agent 自己决定记什么——它写入的内容往往比你预想的更准确
一个有记忆的 Agent 和一个没有记忆的 Agent，体验差距巨大。
教训五：积分消耗是真实约束
Notion Custom Agent 的运行基于积分制，它是实实在在会影响你设计决策的实际约束。
最直接的例子：Git 记录 Agent。它每天定时去 GitHub 拉取提交记录写入 Notion，功能完全正常 ✅。但每天跑一次，积分累积消耗不小。最后我暂停了它，改用更灵活的方案按需查询。
另一个正面案例是邮件处理的路由模式。一开始我用三个独立 Agent 分别处理三种邮件（Stripe 订单、联系表单、Newsletter）。每封邮件触发一个 Agent，积分消耗是三份。后来改成一个入口 Agent 做路由：先判断邮件类型，再分发到对应处理逻辑。同样的邮件量，积分消耗降到原来的三分之一。
设计 Agent 时不能只想「能不能做到」，还要想「值不值得这么做」。
教训六：数据驱动比任务提醒活得更久
早晨简报 Agent 经历了三个阶段。
第一阶段，它生成一份标准日报——今天的日程、待办事项、天气。格式整齐，每天准时推送。
第二阶段，我给它加了数据源，让它不只是列任务，而是汇总昨天的工作数据、分析趋势。
第三阶段，我把它暂停了。
为什么？因为它的输出本质上还是在重复我已经知道的信息。日程我自己会看，待办我自己知道。它只是换了个形式再说一遍——时间久了就变成了机械性的背景噪音。
相比之下，做数据汇总和交叉分析的模式活得更久。区别在于：
- 任务提醒型：「你今天有 5 件事要做」→ 我知道，不需要你告诉我
- 数据驱动型：「上周处理了 23 封邮件，其中 60% 是 Newsletter，建议调整订阅列表」→ 这个有用
Agent 的价值不在于帮你列出已知信息，而在于从数据中提炼出你不知道的洞察。
16 个 Agent 的最终成绩单
| 状态 | 数量 | 比例 | 代表 |
|---|---|---|---|
| ✅ 仍在使用 | 4 | 25% | 邮件智能代理、今日小事、Newsletter 收录、节假日同步 |
| 🔧 暂停 | 9 | 56% | 早晨简报、Git 记录、随机笔记、任务跟进等 |
| ❌ 彻底失败 | 3 | 19% | YouTube 通知、B 站追踪、Readwise MCP |
存活率 25%，但这不是坏事。暂停的 Agent 不代表失败——它们帮我搞清楚了什么模式有效、什么模式行不通。3 个彻底失败的都是因为外部访问限制（Agent 无法访问 YouTube、抓取不了动态渲染页面、第三方 MCP 连接不稳定），这是产品当前的能力边界，不是设计问题。
如果你也准备开始用 Notion Custom Agent，我的建议是：从一个小的增量场景开始，用手动呼叫验证效果，确认动作链完整后再考虑自动触发，同时留意积分消耗。
不要想着一步到位搭一个完美系统。Agent 是用来迭代的，不是用来部署然后不管的。
不过，Agent 能发挥多大作用，取决于你的 Notion 工作区是否有清晰的结构。如果你还在摸索怎么组织任务、笔记和项目，可以看看我做的 FLO.W 模板——这也是我所有 Agent 运行的基础。
常见问题
Notion Custom Agent 值得用吗？
值得，但要管理预期。它不是设好就能忘掉的自动化工具，更像一个需要调教的助手——初期投入时间理解它的能力边界，搭好架构之后确实能省事。我的邮件 Agent 现在每天自动处理所有来信，完全不需要我介入。
Notion Custom Agent 最大的限制是什么？
外部访问能力有限。Agent 无法访问 YouTube、抓取不了需要登录或动态渲染的网页、第三方 MCP 服务的连接不算稳定。如果你的场景依赖外部数据，建议先测试 Agent 能不能成功读取，再投入时间搭完整流程。可以通过 Worker 扩展 Agent 的能力，但目前 Worker 还在 alpha 阶段。
Notion Custom Agent 需要编程基础吗？
创建和配置 Agent 本身不需要任何编程基础，只需要会写中文指令。但如果要用 Worker 扩展功能（比如调用外部 API 发推特），那部分需要写代码。我自己零编程基础，Worker 部分完全靠 AI 辅助完成。
🤖 让 Notion Agent 发挥极致威力
Notion Agent 的能力必须建立在结构化的 Notion 工作区之上。FLO.W Notion 模板预设了清晰的数据库结构，字段设计经过反复打磨，可以直接被 Agent 识别和调用。
