二月初，我開始正式折騰 Notion Custom Agent。一個月過去，前前後後搭了 16 個 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 識別和呼叫。
