100 個工具、30 個 Agent 和一個經理 Agent：Notion 如何打造 AI 代理工廠

本文整理自 Latent Space Podcast 2026 年 4 月播出的單集。

{{< youtube ATt7QJgt-2k >}}

{{< spotify "episode/0pI3rxITA2D1HPUKpPb8Kv" >}}

{{< apple-podcast "tw/podcast/notions-token-town-5-rebuilds-100-tools-mcp-vs-clis/id1674008350?i=1000761419695" >}}

---

工具越多，Agent 越笨

Notion Custom Agents 是公司史上最成功的產品發布，帶來最高的免費試用轉換率。但在這個光鮮的數字背後，Notion AI 團隊踩過一個痛苦的坑：工具越多，Agent 的表現反而越差。

Notion 共同創辦人 Simon Last 在 Latent Space Podcast 上回憶，團隊一開始的做法很直覺，就是把所有 Notion 能做的事情都變成工具，丟給 Agent。問題是，當工具數量膨脹到接近一百個時，系統開始出現明顯的退化。Agent 只是打個招呼，就要消耗好幾千個 token，因為系統提示詞塞滿了工具定義。更麻煩的是，任何工程師都能替自己負責的功能新增工具。結果某個冷門功能的工具就會干擾模型判斷，讓它在不該呼叫的時候亂呼叫。

這不只是效率問題，更是品質問題。Notion AI 工程負責人 Sarah Sachs 形容，那段時期「連說 hello 都要花上好幾千個 token」。團隊意識到，不能把所有工具一次攤開給模型看，必須做「漸進式揭露」（progressive disclosure），根據當下的對話情境，只顯示相關的工具。這個改造是一項大工程，但它讓 Notion 在不犧牲品質的前提下，把工具數量推到了超過一百個。

Simon Last 觀察到一個核心原則：要仔細想清楚模型需要什麼樣的環境，然後配合它。盡量不讓模型碰到系統裡不必要的複雜性。這聽起來簡單，做起來卻違背工程師的直覺。工程師習慣讓系統完整呈現所有能力，但對模型來說，少即是多。

CLI 還是 MCP？Simon Last 的實務判斷

在 AI 工具生態裡，MCP（Model Context Protocol）和 CLI（命令列介面）是兩條路線。Simon Last 對兩者都看好，但有清楚的場景區分。

CLI 的最大優勢是「自我修復」（bootstrapping）能力。在終端環境中，Agent 遇到問題可以自己除錯。Simon Last 舉了一個例子：有人的 Agent 沒有瀏覽器可用，就讓 Agent 自己寫了一個，不到一百行程式碼就包裝了 Chromium API。如果那個自製瀏覽器有 bug，Agent 還能立刻修。但如果用的是 Chrome DevTools MCP，一旦傳輸層出問題，Agent 就完全癱瘓了，因為它沒有能力修復自己依賴的通訊協定。

CLI 還有天然的漸進式揭露：Agent 不需要一次看到所有指令，它可以用 help 指令探索、用分頁瀏覽長輸出。這些在 MCP 裡需要額外設計，但在 CLI 裡是內建的。

不過 MCP 也有它不可取代的位置。Simon Last 認為，MCP 非常適合需要輕量、窄範圍、嚴格權限控制的場景。MCP 天生有強力的權限模型，Agent 只能呼叫被授權的工具。CLI 環境就模糊多了，Agent 能不能存取 API 金鑰？加密是否到位？這些都是需要額外處理的安全問題。

Sarah Sachs 從商業角度補了一刀：MCP 每次呼叫都要消耗 token，而且如果超出快取視窗，同樣的工具定義要重複傳送。如果 Agent 可以寫一段程式碼，透過 CLI 執行確定性的 API 呼叫，那就是一次性成本。比起反覆用語言模型透過 MCP 溝通，划算得多。Notion 採用按用量計費（usage-based pricing），所以對 token 浪費特別敏感，他們不只是替自己省錢，也是在替客戶省錢。

Notion 的實際做法是混合策略。核心整合（Slack、Mail、Calendar）自己建造原生工具，確保延遲和品質可控。長尾整合（Linear、GitHub）用 MCP。至於觸發器（trigger），因為沒有對應的開放協定，所以完全自建。MCP 在 Notion 的技術堆疊裡是一種整合「類型」，不是唯一的整合方式。

30 個 Agent 的經理問題

當 Agent 數量變多，新的管理問題就出現了。Simon Last 分享了一個內部案例：有個同事替 go-to-market 團隊建了超過 30 個 Custom Agent，負責各種任務，研究客戶背景、分類客戶回饋、自動填入資訊。很快，問題浮現了，這個人每天收到超過 70 則 Agent 通知，全都是 Agent 在某個環節卡住了，需要人類介入。

Simon Last 的解法直覺到令人發笑：「那就做一個經理 Agent 吧。」

他們建了一個管理層級的 Agent，授權它呼叫其他 30 個 Agent。這個經理 Agent 監控下屬的狀態，遇到小問題自己處理，只有真正重要的事才通知人類。結果 70 則通知變成 5 則。這不是什麼高深的架構設計，就是在現有的元件上多加一層抽象。

Notion 的 Agent 組合有兩種模式。第一種是鬆耦合：一個 Agent 寫入資料庫，另一個 Agent 監聽同一個資料庫。兩者透過 Notion 的資料基元（data primitives，即頁面和資料庫）協調，彼此不需要知道對方的存在。第二種是緊耦合：在 Agent 的設定中直接授權它呼叫其他 Agent。Simon Last 透露，這個功能很快就會正式推出。

值得注意的是 Notion 對「記憶」的處理方式。他們沒有建任何內建的記憶機制。記憶就是 Notion 的頁面和資料庫。你想讓 Agent 記住什麼，就給它一個頁面的存取權限。人類和 Agent 都可以編輯那個頁面。這個做法的優點是完全透明，使用者可以直接檢視和修改 Agent 的「記憶」，不需要理解任何底層技術。

用聊天設定 Agent：Flippy 設計哲學

Custom Agents 有一個設計決策讓 Notion 內部爭論了很久，甚至為此延後了幾週上線。團隊內部叫它「Flippy」。

最初的設計是傳統的做法：設定頁面是主畫面，你填好各種選項之後，可以測試 Agent。但團隊後來翻轉了這個邏輯。Simon Last 說，如果你信奉 AGI 的思路，那一切都應該是 Agent。Agent 能自己設定自己、自己測試自己、自己跑工作流程。所以他們把聊天介面變成主畫面，設定頁面變成側面板，只是用來預覽 Agent 對自己做的修改。

Latent Space 共同主持人 Alessio 在節目上實際演示了這個體驗。他建了一個管理共享工作空間申請的 Agent，只跟 Agent 說「幫我監看信箱裡的共享空間申請，建一個表格追蹤」。Agent 自己建了資料庫、設定了觸發條件、寫好了篩選邏輯。整個過程大約 15 分鐘。

更聰明的設計是，當 Agent 在執行任務時遇到失敗，使用者可以直接在同一個聊天視窗裡問 Agent 為什麼失敗，然後要求它更新自己的指示。不需要複製錯誤訊息、切換到設定頁面、手動修改，全部在同一個對話裡完成。Simon Last 承認，這裡有一個微妙的權限問題：Custom Agent 預設沒有任何權限，所有權限都要使用者明確授予。如果讓 Agent 自己修改權限，就破壞了這個信任基礎。目前的折衷是，使用者可以進入「管理模式」的同步對話，在這裡 Agent 可以建議變更，但每次都需要確認才會生效。

不是所有知識工作都值得用 Opus

Notion 的定價模式反映了他們對 AI 成本的務實態度。Sarah Sachs 談到，他們很早就決定不能讓所有功能都跑最貴的模型。如果資料庫自動填充功能（database autofill）的每一格都用 Opus 模型跑 Agent，那每個月的帳單就是天文數字。

所以 Notion 做了兩件事。第一，推出按用量計費，讓使用者自己選擇要在什麼任務上花多少智慧。如果你要 Opus 幫你分類所有郵件，可以，但你會看到成本提示。第二，他們投入大量心力在「Auto」模式上，讓系統自動為每個任務選擇最適合的模型。Sarah Sachs 把這比喻為 Robinhood 的自動投資功能：你可以自己選股，也可以讓系統幫你配置。

這裡有一個有趣的觀察。在 Custom Agent 的場景裡，使用者並不在乎速度。因為 Agent 是在背景執行的，快三秒慢三秒沒差。這表示用 Haiku 模型省錢的「更快」賣點，在這個場景裡完全失效。使用者在乎的只有兩件事：品質和價格。Sarah Sachs 認為，目前前沿模型供應商之間缺乏足夠的價格差異化。高階模型很強但很貴，便宜模型還沒追上六個月前推理模型的水準，中間有一大片空白。Notion 正在積極與開源模型實驗室合作，用他們的「Notion 最終考試」（一套通過率只有 30% 的高標評估）來幫助這些模型在企業知識工作任務上進步，把那個三角形填滿。

做最好的協作場所

訪談尾聲，Sarah Sachs 提到了 Simon Last 曾經提醒她的一句話：「我們的工作不是打造最好的 Agent Harness，我們的工作是打造人們協作的最好場所。」

這句話點出了 Notion 在 AI 時代的定位邏輯。他們不跟 OpenAI、Anthropic 搶基礎模型，不跟 Cursor、Claude Code 搶 coding Agent，也不跟硬體廠商搶穿戴裝置。他們要做的是讓所有這些東西的產出最終流向 Notion，因為那裡是團隊協作和知識管理的中心。

就像 Datadog 不需要自己做雲端運算，但它是企業理解自己雲端服務最好的地方。Notion 要成為企業理解自己團隊如何協作的最好場所。不管 Agent 用什麼模型、什麼協定、什麼工具鏈，只要最終的文件、任務、會議紀錄都在 Notion 裡，Notion 就贏了。

這個策略聽起來簡單，執行起來卻需要極大的克制。當你的 AI 團隊有 50 個人，外加 30 到 40 個做功能封裝的夥伴團隊，再加上所有產品工程團隊都必須讓自己的服務同時服務人類和 Agent 時，很容易就會迷失在技術的迷宮裡，開始追逐最炫的 Agent 能力。但 Sarah Sachs 堅持，團隊每週五都要看最耗 token 的 Agent 對話紀錄，分析為什麼失敗、砍掉不必要的功能。這種聚焦於使用者旅程而非技術展示的紀律，或許才是 Notion 在 AI 時代最重要的護城河。