不再迷信Hackathon，把Agent推翻重做了4次！Notion負責人復盤：做AI產品如何避免“逆流而上”？

撞了 3 年墻才上線 Custom Agents，Notion 的兩位負責人認為，AI 真正替代的不是人，而是流程。

編譯 | 王啟隆

出品丨AI 科技大本營（ID：rgznai100）

很多人現在做 Agent，第一反應還是給模型加工具。

工具不夠，就繼續加工具。system prompt 不夠，就繼續堆 system prompt。模型不穩定，就換一個更強的模型。可做著做著，你會發現問題并不只是模型夠不夠聰明，也不只是工具調不調得動，而是這套東西到底要長在哪兒，它跟原來的產品、權限、組織和工作流，究竟怎么接上。

這是我最近看 Latent Space 對 Notion 的一場播客時，最強烈的感受。

這期節目里，主持人找來的是 Notion 負責 AI engineering 的Sarah Sachs（右2），以及長期主導產品和原型方向的Simon Last（右1）。背景也很明確，Notion 剛剛上線Custom Agents。表面上看，這像是又一個大廠把 agent 做進辦公軟件里的故事。

他們聊的并不只是一個新功能怎么發布，而是 Notion 這幾年怎么把 Agent 這件事推倒重來四五次，才慢慢摸到一條能成立的路。

這里面最有信息量的地方，不是某個 demo 漂不漂亮，也不是 system prompt 寫得多巧，而是他們把幾件原本經常被分開談的東西扣在了一起：模型能力、工具抽象、權限設計、評測體系、團隊組織，甚至定價。

換句話說，Notion 想做的并不是一個掛在軟件外面的會聊天的助手。

他們更像是在試著把企業軟件本身，重做成一個既給人用、也給 agent 用的工作底座。

要點速覽

• Notion 從 2022 年就開始做 agent，但真正讓他們覺得能往前推的，不是一個模型突然變聰明了，而是他們重做了四五輪之后，終于把模型、產品和權限接到了同一套框架里。

• 編程智能體（Coding Agent）像 AGI 的內核，而軟件工廠則是在繼續把這種能力往團隊協作和代碼維護的整條鏈路上推。

• 應用公司做 AI 不是包一層模型就結束了，而是要判斷自己是不是在逆流而上，要看清模型能力的水流到底往哪邊走。

• Notion 對 MCP 和 CLI 的態度也很現實，MCP 更輕、更好控權限，CLI 更強，也更有自舉和自修復能力。選哪一個，不只是技術問題，也是能力、權限和成本怎么對齊的問題。

• 比起自己訓練一個基礎模型，Notion 現在更在意的是檢索、排序、搜索這些更貼著 agent 工作流的基礎層，因為越來越多搜索流量已經不是人發起的，而是 agent 發起的。

不是在追模型熱點，而是在等那條河真正改道

主持人（Alessio）：恭喜你們最近發布了自定義智能體。這個功能折騰了這么久，終于正式上線了。現在回頭看，是什么感覺？

Sarah Sachs：我們的發布節奏一直比較穩。它其實已經內測了一段時間。當一個產品走到這個階段時，一撥人會盯著怎么把它順利推上線，另一撥人已經開始做下一個版本。所以很多時候，真正發布時的那種成就感，反而會來得比較晚。

但現在回頭看，還是會覺得值。大家確實為它投入了很多力氣，而且今天做 AI 產品，用戶教育也比兩三年前容易多了，大家大致都能看懂你在做什么。這次發布在免費試用和用戶轉化上的表現，是我們到目前為止最好的一次。三個月的免費試用幫了很大忙。當然，后面還有很多東西要繼續做。

Simon Last：對我來說，最激動的一點是，這套系統大概已經被我們重構了四次，甚至五次。

主持人（Alessio）：畢竟你們從 2022 年就開始做這件事了。

Simon Last：對。2022 年底，我們剛拿到 GPT-4 的訪問權限時，腦子里最早冒出來的一個念頭就是，干脆做一個智能體，給它 Notion 的全部工具權限，讓它在后臺替我們干活。那時候我們還不怎么叫它智能體，更多還是叫助手。

然后我們試了很多次，但那個時間點確實太早了。

主持人（Swyx）：你得把這個“太早了”展開講講。到底哪里不行？

Sarah Sachs：那時候連函數調用都還沒出來。我們在和前沿實驗室，還有 Fireworks 這類團隊合作，想微調一個能調用 Notion 函數的模型。我加入時，這件事已經在推進了。

Simon Last：對。我們前后都和 Anthropic、OpenAI 合作過。最開始的時候，連“工具”這個概念都還沒有。我們自己設計了一套工具調用框架，然后想辦法去微調模型，讓它能在多輪對話里使用這套框架。

但效果并不好。說到底，當時模型還是太笨，上下文窗口也太短。我們在這個問題上磕了很久。中間偶爾也能看到一點希望，但始終沒有到那種既真正能用、又足夠讓人驚艷的程度。

直到去年初 Claude 3 Sonnet 出來，情況才突然有了很大變化。那時我們開始做去年發布的那版智能體，之后再一路做到現在的自定義智能體。

不過自定義智能體花的時間更長，因為你不僅要讓它能跑，還要讓它足夠可靠，尤其是它在后臺運行的時候。然后就是權限、分享、管理界面的設計。比如，一個智能體被分享給某個 Slack 頻道里的一群人，但它又能訪問另一批文檔，這兩批人的權限邊界怎么解釋清楚，管理員怎么一眼看明白，這些都不是 demo 階段的問題，而是真正做產品一定會遇到的問題。

Sarah Sachs：歸根結底，這些問題最后都會落到同一件事上，角色訪問控制，也就是權限管理。

主持人（Alessio）：我很好奇，在模型能力還不夠的時候，你們怎么規劃路線圖？一方面你得相信模型會繼續變強，另一方面你們又不是一家零用戶的小公司，你們在 2022 年就已經有很大的客戶基礎了。

Simon Last：這始終是一種平衡。你既得有一點 AGI 信仰，去為未來布局；你又必須交付當下真的有用的東西。我們一直在試著在兩者之間找平衡。

我們的做法更像一個投資組合。一邊維護和打磨已經發布、也已經跑得不錯的功能，一邊始終保留幾個聽起來有點瘋狂的前沿項目。

主持人（Alessio）：那你們現在有哪些這種 AGI 信仰級別的方向？不用說太細，但我很好奇，有什么是你們現在做著，18 個月以后大家會覺得“原來這真的就是答案”的東西？

Simon Last：現在同時在發生很多事。一個越來越清楚的趨勢是，編程智能體正在變成 AGI 的核心，某種程度上可以說萬物皆可編程智能體。真正讓人興奮的地方，是智能體開始能引導出自己的軟件和能力，然后自己去調試、維護它們。

另一個我特別興奮的方向，是所謂的軟件工廠。現在很多人都在講這個詞。簡單說，就是你能不能把開發、調試、合并、評審和維護代碼庫、服務的整個流程盡可能自動化，讓一群智能體在內部協同工作。這套東西到底該怎么設計，我覺得特別值得做。

Sarah Sachs：如果回到你最開始那個問題，為什么這件事花了這么久，我覺得大家很容易給出一個很偷懶的答案，說以前不行，后來推理模型出來了，就行了。

這當然是其中一部分，但我覺得真正讓 Notion 每次都能抓住新能力的，是我們一直在練兩種技能。

第一種，是別逆流而上。你得很快判斷清楚，你現在碰到的到底是模型能力本身的天花板，還是因為你沒有給模型正確的信息，沒有搭對基礎設施。

第二種，是一旦你確認自己不是在逆流而上，就要看清河流真正往哪里走。你要在技術還沒完全成熟的時候，就開始搭產品。這樣等它成熟的時候，你不會從零開始。

這件事有時候聽起來很反直覺。比如工具調用模型還不存在的時候，我們就在嘗試微調類似能力。訣竅不是死磕太久，而是意識到那里有機會。

我們其實有過很多這樣的嘗試。像會議紀要功能，在最后正式出來之前，我們在語音轉錄上已經迭代過很多版了。

Simon Last：那個我可以講很久。

不是套殼，而是把“怎么工作”重新做一遍

Sarah Sachs：我們和前沿實驗室在模型能力上的合作一直很緊密，但我們自己也必須有一個很明確的信念，隨著這些能力不斷演進，Notion 的使命仍然是成為你協作和工作的最好地方。如果大家的工作方式變了，那 Notion 這個產品故事也得跟著繼續往前寫。

主持人（Swyx）：對，你之前跟我說過你很喜歡“智能體實驗室”那套理論，其實就是這個意思吧。

Sarah Sachs：對。我給很多候選人看過那套東西。它甚至已經成了我 Chrome 里的自動補全項。我拿它去解釋，為什么你應該來 Notion，而不是去 OpenAI。因為這是兩種完全不同的事情。

這也是為什么我們不是一個簡單的套殼公司。雖然說實話，早期我們做的某些部分，確實也是在已有能力上做了一層封裝。但那不是推動營收的核心產品，也不一定是用戶真正需要的東西。

主持人（Alessio）：某種意義上，Notion 也可以說是 AWS 的套殼，但這個殼做得非常精致。

Sarah Sachs：我很喜歡拿 Datadog 和 AWS 來做類比。沒有云存儲，Datadog 根本不可能存在，這是它的底座。AWS 自己也有 CloudWatch，但 Datadog 真正懂的是，用戶到底想怎樣監控自己的系統。

同樣地，我們真正懂的是，人們希望怎樣協作。這才是我們的壁壘。

主持人（Alessio）：但你們跟 Datadog 又不太一樣。Datadog 面向的是工程團隊，用戶比較像；你們是個平臺，Notion 的終端用戶幾乎可以是任何人。所以這種專業知識怎么融進產品里？

Simon Last：對，這個類比到這里就會有點不一樣。Datadog 這種經典垂直 SaaS，理解的是一群相對窄的人。Notion 一直非常橫向。我們的任務始終是在兩股有點對立的力量之間找平衡，一邊是傾聽廣泛客戶群體的需求，一邊是把這些需求拆解成優雅、好用的底層原語，同時還要盡量讓整個系統保持純粹、易用。

Sarah Sachs：所以我們最后還是會回到用戶旅程。老實說，我們團隊最容易跑偏的時候，往往就是過度關注“什么工具看起來很酷”。那通常也是我們推進最慢的時候，因為你最終總得圍繞某個真實用戶旅程來做事。

比如我們每周五都會坐下來，看那些最消耗 Token 的自定義智能體日志，分析它們為什么表現差，然后砍掉一批不合理的任務。我們會堅持盯一些必須跑通的場景，比如郵件分類。我們也會在做聊天功能時認真思考 PDF 導出怎么做好。這里面可能需要構建可以訪問計算機沙盒、文件系統、還能寫代碼的工具，但我們的出發點永遠是“用戶的工作里真的需要導出 PDF”，而不是“哇，做個計算機控制工具好酷，我們來試試”。

如果你不圍繞用戶旅程做事，你的優先級很快就會失去戰略方向。

真正拉開差距的，不是點子，而是低 ego 的組織能力

主持人（Swyx）：你感覺有一套特別鮮明的方法論。你是怎么管理團隊的？

Sarah Sachs：我覺得“怎么和 Sarah 共事”這件事，得看你問誰。團隊成員、合作伙伴、供應商的答案可能都不一樣。

但對我來說，有一個很重要的轉變是，我很早就接受了一點，我的工作不是那個負責出最好點子的人，也不是那個技術最強的人。我的職責是，確保每個人都清楚目標，有資源去判斷該優先做什么，而且有渠道去推進他們認為重要的事情。

這一點對所有領導層都成立，但在 AI 團隊里尤其成立。因為我們很多最好的點子，都是那些看到了用戶痛點，然后自己做出酷炫原型的人提出來的。

如果所有點子都得先經過我、產品搭檔，或者 Simon 和 Ivan 的“嗅覺測試”，那損失會非常大。因為我們做的很多事，本質上都在探索模型能力邊界。

所以第一點，我從不覺得工程領導的角色是層級式的。現在更不是。我們非常愿意根據結果改方向。

第二點，當你把底層框架重構了三四次之后，你就必須建立一個真正 low-ego 的團隊。能刪自己的代碼，不在乎是不是自己先提的方案，一切以大局為重，也不會靠寫一堆設計文檔來給自己加戲。

在我加入之前，Notion 就已經有這種文化了。大家愿意一起上去解決問題，也愿意因為情況變化而推翻重做。在很多公司里，這種事會產生巨大摩擦，在 Notion 不會。

Simon Last：我不像 Sarah 那樣是個管理者。我的角色更多是盡量把事情想遠一點，確保我們建立在正確的能力基礎上，再去做原型。不斷從頭思考真的非常關鍵。每次遇到新東西，我都會問，如果我們從頭來過，會怎樣。所以我基本上每六個月就在重復這個循環。

主持人（Alessio）：那你們信不信黑客松？

Sarah Sachs：我覺得分兩種情況。

一種是，我們有一批非常可靠的資深工程師，他們會隨時加入或退出我們內部所謂的“Simon 漩渦”，把一些高速變化的東西真正產品化。這種項目不需要黑客松，它需要的是能信任、能快速進出的資深工程師。

在這種情況下，組織邊界會非常松。你可能名義上向這個人匯報，但現在正在為另一個人工作。我們在招管理者時，其實很看重他們能不能接受這種模糊邊界。因為我們往往是在產品發布之后，才慢慢把組織架構固化下來。

另一種是，全公司的黑客松。這個是有的。它更多是為了讓那些平時不直接做 AI 項目的人，也能停下來學學怎么提升自己的生產力，怎么用 Notion 自定義智能體搭東西。黑客松里有一部分內容，就是鼓勵大家從零開始照著教程搭一套自己的工具調用循環。

主持人（Swyx）：是那個 Compound Engineering 的教程嗎？

Sarah Sachs：對。我們希望公司里的每個人都會用 Claude Code，或者任何他們喜歡的編程智能體，并理解這里面最基礎的原理。所以我們會專門空出一天半時間來做這件事。

不過半開玩笑地說，我們做的很多東西在最初都有點像黑客松產物，直到它真正長大，穿上“大人的衣服”，有了推廣計劃、數據科學家、完整的產品運營節奏。

主持人（Alessio）：那也得先過安全審查和企業合規吧。

Sarah Sachs：實際上，安全審查往往是我們最早引入的環節之一。因為如果你拖到后面才做，它會嚴重拖慢進度，還會制造很多矛盾。安全團隊越早進來，越能幫我們做出更好的產品。這不是公關話術，是我們踩過坑之后留下來的傷疤。

Simon Last：我覺得黑客松對于提升全員素養很重要，但如果那是你們構建新東西的唯一方式，那就完蛋了。它必須融入日常流程。在 AI 時代，杠桿越來越傾向于那些最有好奇心、最有熱情的人。如果有人周末興奮地折騰出一個原型，而且它真的重要，那它就該立刻變成主線，而不是等到季度黑客松。

Sarah Sachs：對。我們現在 Notion 里的圖像生成功能就是這么出來的。它一直是那種“有了挺好”的能力，很難進最核心的優先級，但數據庫團隊的 Jimmy 就非常想做。于是我們說，那你就放手做，我們給資源、給支持、給接口、給 Token 追蹤、給郵件支持。最后它真就變成了完整項目。

Simon Last：這就是為什么作為領導者不能 ego 太強。否則這種事根本不會發生。

當整個公司都開始為智能體開發，評估就不再只是測試

主持人（Alessio）：你們現在團隊大概有多大？

Sarah Sachs：我管的團隊主要負責核心 AI 能力和基礎設施，大概五十人左右。除此之外，還有一些合作團隊負責產品層面的包裝，比如決定 AI 最后出現在哪，是角落里的聊天框、自定義智能體，還是會議紀要，這部分大概三四十人。

但更重要的是，在 Notion，任何一個擁有用戶可見產品服務的團隊，都必須負責維護自己那部分被智能體調用的工具。做編輯器的團隊，不僅要考慮人類怎么編輯，還得負責兩個智能體同時改一塊內容時的沖突問題；做底層 SQL 引擎的團隊，也得確保智能體發起 SQL 查詢時能高效執行。

從這個角度看，只要你在做產品工程，你的任務就是同時服務人類用戶和智能體。因為隨著時間推移，大量流量都會來自使用我們界面的智能體，而不是人類。我們的目標，就是讓整個產品組織都開始為智能體開發。

主持人（Alessio）：這會不會讓原型門檻變得特別低？現在大家很容易就在現有代碼庫里拼出一個新原型。那什么樣的原型才算值得認真看待？

Simon Last：門檻確實在很多方面都變低了。我們設計團隊就做了一個很酷的東西，他們自己建了一個獨立 GitHub 倉庫，叫“設計游樂場”，里面有很多輔助組件可以快速拼 UI，現在甚至內置了一個智能體。

所以他們現在不再交靜態設計圖，而是直接給你一個能跑的可交互原型。對工程師來說，門檻其實也很明確，能做出一個真正跑通的 feature flag，這就夠了。

Sarah Sachs：Notion 很獨特的一點，也是我為什么會加入這里，這個世界上沒有誰比 Notion 自己的員工更頻繁地在工作中使用 Notion。所以任何我們發布的東西，都會先被內部用起來，并迅速收獲反饋。

有時候我們內部的開發實例簡直亂成一鍋粥，開關開得到處都是，但這已經是常態了。無論是做 IT 工單、采購還是招聘的人，大家都在同一個開著各種原型功能的 Notion 里工作。

我們團隊的設計師 Brian Leven 還一直推一個理念，叫“Demos over Memos”，演示勝于文檔。這極大推動了原型文化。但它也迫使我們必須對方向有足夠強的信念。因為如果任何東西都能被做成 demo，你就更得知道你在堆的是一座塔，而不是一個平庸的小土丘。

Simon Last：總的來說，這套機制運轉得挺好。幾乎所有工程師都有足夠好的品味，知道一個原型在產品里合不合理。所以我們很少看到那種完全無意義的原型。更多的問題在于，先做哪一個，以及怎么控制它的開關。

Sarah Sachs：不過從評估和平臺角度看，這對底層團隊確實帶來了不小壓力。比如你要在 Notion 里做圖像生成，那附件處理方式、模型返回結果的預期、合規要求、供應商合同，全都得重做一遍。有時候一個功能在開發環境里待幾周不能上線，不是因為它的想法不行，而是因為你得先把底層打穩。

這也是為什么我們非常強調“智能體開發效能”。如果你愿意在平臺上投資，智能體能力迭代的速度就會快很多。

Sarah Sachs：所以我們現在其實有一個完整的組織，專門圍繞智能體平臺效能來搭。每個團隊都可以建立自己的評估體系，并且在發布后繼續維護它。如果模型變了，比如某個模型被棄用，我們也得能夠盡快更新。

很多評估會直接接進 CI，或者每晚自動運行。我們甚至還有一個自定義智能體，一旦某個關鍵能力出現重大失敗，就會自動報警，把團隊叫去看。

這件事非常重要，因為現在太多不同的產品服務都跑在同一個智能體框架上，只是打包方式不同。如果底層一變，你要能很快知道哪里受影響了。

主持人（Alessio）：我有個關于評估的問題。你們會不會發現模型供應商暗中把模型變差了？

Sarah Sachs：如果你說的是那種高峰期模型突然變笨的情況，我覺得更常見的是不穩定性。有些時候，不同渠道給出來的所謂“同一個模型”，質量其實并不完全一樣。有時是量化策略不一樣，有時就是他們內部做了調整，但你拿到的效果和宣傳并不完全一致。

我們當然會去理解這些變化。比如某些退化如果能換來明顯更好的延遲，而且退化幅度在可接受范圍內，那對某些場景未必不能接受。關鍵是，你得有足夠好的評估手段去看懂它。

甚至在和實驗室測試預發布模型時，他們會給我們多個快照。我們也確實遇到過，他們先給的版本不是我們真正想要的，但會根據我們的反饋繼續改。因為我們的反饋很多時候更偏企業協作場景，而不是編程智能體場景。

主持人（Alessio）：那你們會不會有一批用例，長期過不了，就等著未來哪天模型終于能過？

Sarah Sachs：當然有，而且我覺得這里有一個很大的誤區。很多人一提評估，就只是把它等同于質量測試，好像評估就是另一種單元測試。但這遠遠不夠。

我們大致有三層。

第一層，像單元測試和回歸測試，跑在 CI 里，要達到一定通過率。

第二層，是產品級評估。也就是當你在做一個產品時，你會明確說，這些用例目前還沒通過，所以這個功能還不能發。我們內部會有一張成績單，某些關鍵用戶旅程必須跑到 80% 或 90% 以上，才算達到發布標準。

第三層，是更前沿的評估，也可以叫天花板評估。對于這類評估，我們甚至會故意把目標通過率放在 30% 左右。因為它的目的不是今天發版，而是讓我們看清技術的天花板在哪里。

過去兩三個月，我們和 Anthropic、OpenAI 合作時，很大一塊工作就在這里。因為有一段時間我們發現評估有點飽和了，我們除了告訴對方“模型沒變差”，已經給不出太有洞察的反饋。這對他們沒幫助，對我們自己判斷未來方向也沒幫助。

所以我們花了很多時間去思考，什么才叫“Notion 的終極考試”。不是人類的終極考試，而是從 Notion 作為產品的角度，什么才是最難、最關鍵、最能決定未來方向的能力。

主持人（Swyx）：你們現在在招模型行為工程師？

Sarah Sachs：對，正在招。

主持人（Swyx）：這個崗位到底是什么？

Sarah Sachs：模型行為工程師。這個職位剛開始其實不叫這個名字。最早的時候，他們更像數據專員。那時他們跟 Simon 一起看 Google 表格，幫忙判斷哪些結果好，哪些不好。

當時我們招了很多很特別的人，有語言學背景的人，也有計算機文學背景的人。他們特別出色，后來幾乎等于自己把這個崗位定義了出來。

現在這個角色又在變。以前他們更像人工審閱結果的人，現在隨著編程智能體出現，他們越來越多是在構建評估系統本身，比如讓智能體自動寫評估用例、使用 LLM 裁判之類的。

但我覺得這個角色真正有意思的地方在于，它不是一個純工程崗位。它其實混合了數據科學家、產品經理、提示工程師的很多能力。你得理解模型能做什么、不能做什么，什么叫合理的天花板，什么叫一個真正好的用戶旅程。你還得判斷模型到底是變好了，還是只是換了一種方式失敗。

這類工作里有大量定性的判斷，特別依賴直覺和品味，而這不一定來自傳統軟件工程訓練。所以我們一直都很歡迎非傳統背景的人。我們非常相信，要在這件事上做得頂尖，不一定需要工程背景。

Simon Last：這也是我最近特別興奮的一件事。我們在努力把評估系統本身當成一個智能體框架來對待。

理想狀態是，你應該可以讓一個智能體端到端下載數據集、運行評估、分析失敗原因、調試、修復，最后再重新跑一遍。人類更多是在系統外面看著它，而不是自己手工去串這一整套流程。

我們已經在這件事上花了很多力氣，而且效果相當不錯。本質上，你就是把評估變成了一個編程智能體要解決的問題。

主持人（Swyx）：那是你們自己的編程智能體，還是任何一個通用智能體都可以？

Simon Last：我覺得應該是通用的。把它綁在某一個特定編程智能體上，反而是錯的。說到底，它更像一個 CLI 工具。

Sarah Sachs：當然，這里面依然需要很多監督。我們只是覺得，這種監督不一定非得由軟件工程師來做，因為其中有很多工作本質上更像用戶研究，比如你要對失敗案例進行分類，然后判斷下一步應該往哪里打。

軟件工程師不會消失，但工作的重心會變

主持人（Alessio）：那會不會有一天，Notion 里根本不需要軟件工程師了？

Sarah Sachs：這要看你怎么定義軟件工程師。

Simon Last：我更愿意把它看成一條連續演化的曲線。三年前，人類還在手寫所有代碼；后來有了自動補全；再后來有了整段補全；現在則進入了智能體可以執行長周期任務、調試、修 Bug、驗證效果，甚至提交 PR、合并和部署的階段。

我覺得我們只是一直在往更高的抽象層走。人類的角色會越來越像觀察者和外部系統維護者。你會看到一串智能體在跑，然后你關注哪里偏了，哪些地方需要審批，哪里還缺有效的學習機制或記憶機制。

所以這仍然是一個很硬核的工程問題，我們只是在技術棧上又往上走了一層。

Sarah Sachs：今年夏天，Notion 的很多軟件工程師都經歷了一次挺明顯的身份變化。我們內部有位工程主管說得很好，每個軟件工程師都在經歷管理者才有的身份認同危機。他們突然發現，自己最重要的能力不再只是寫代碼，而是委派任務和切換上下文。

從這個角度看，傳統軟件工程師的角色確實在被超越。

Simon Last：但這里和管理人類團隊有一個很大不同，這里面其實非常技術化。人類是模糊的、感性的，你不能像調度一個嚴密系統那樣調度一群人。你不能假設任務像 PR 一樣在人與人之間自動流轉、阻塞、恢復。

但對一群智能體，你是可以這么設計的。這背后其實有非常嚴謹的技術邏輯。歸根結底，這還是一個系統設計問題。

主持人（Alessio）：那你們現在心里的軟件工廠到底長什么樣？

Simon Last：我們在嘗試很多不同的方向。最終你想要的是一個盡可能少需要人類干預，但又能維持關鍵系統不變量的系統。

有幾件事我覺得特別重要。第一，必須有一個規范層。你得有某種東西能把任務、需求、約束寫清楚。直接提交 Markdown 文件就很好，作為 Notion 這當然很有意思，因為 PRD 天然就應該活在 Notion 里，它可以是一頁文檔，也可以是頁面數據庫。

但它必須首先是人類可讀、可見的。

第二，必須有一個非常強的自我驗證循環。你基本上需要一層非常強的測試體系，不然你根本不可能放心讓一群智能體去接手那么多流程。

第三，就是工作流本身的設計。Bug 進來以后怎么進系統？是由某個子智能體接手嗎？它怎么提交 PR？誰審查？怎么合并？怎么部署？這一整套流轉，都是你要設計的東西。

自定義智能體真正替代的，是那層最煩的人工流程

主持人（Alessio）：我們錄節目之前其實剛好做了一個自定義智能體的 demo。我們每次錄節目都會試產品。這次我們用它給 Kernel Labs 的共享辦公空間做了一個申請處理智能體。

以前的流程是，我收到郵件，讀一遍申請，想想這個人值不值得聊，再回郵件，對方再回。現在我只花了十五分鐘就搭好一個智能體，我告訴它去檢查收件箱里的申請，然后它自動給我建數據庫記錄，去網上搜申請人信息，把時間、背景這些都補全。

這當然不是 AGI，但它干掉了我最不想手工做的那部分活。而且我特別喜歡的是，這些信息本來就該放在 Notion 里，而不是逼我再把數據搬到別的工具里。

Sarah Sachs：這其實就是我們看到的最大價值來源。很多時候，自定義智能體最大的收益不是替代掉某個人，而是替代掉流程中那層額外的人工干預。

像 Bug 分流就是最典型的用例。如果有人在 Slack 里提了問題，你能不能讓一個駐留在那里的智能體，根據自己的路由規則判斷應該歸誰處理，然后在任務數據庫里建卡，再回到 Slack 里回復。

這其實是我們內部最早做出來的一批東西之一。它真的改變了 Notion 公司內部很多事情的運行方式。沒有東西會被遺漏——好吧，大部分不會被遺漏。畢竟你永遠不可能知道自己不知道什么。

主持人（Alessio）：所以它并不是在替代人，而是在替代繁瑣流程。

Sarah Sachs：對，就是這樣。

主持人（Alessio）：我還在做另一個東西，類似租約填寫器。每當有人正式簽約成為租戶，它就去填租約。那是不是再往前一步，應該有一個辦公室經理智能體，它負責處理請求、制作租約、開門禁之類的？

Simon Last：我覺得這里有兩種組合方式。

一種是通過數據原語來組合。比如一個智能體向數據庫寫數據，另一個智能體再去遍歷這個數據庫繼續處理。這種解耦協同的方式就很好。

另一種是讓它們直接耦合起來。一個功能大概很快就會上線，在智能體設置里，你可以允許它調用別的智能體。這樣它們就可以直接對話。

主持人（Alessio）：那不會無限遞歸嗎？

Simon Last：代碼里肯定有個限制數值。但總會有人把它玩壞，你可以試試。畢竟一切最后都可能走向回形針制造機。

不過這個功能真的很有用。前幾天我就在內部幫一個同事解決了類似的問題。他給市場團隊建了三十多個自定義智能體，各干各的活，比如收集客戶信息、分類客戶反饋之類。然后他開始天天收到七十多條通知，全是這些智能體卡住了。

我就跟他說，這很明顯，你需要一個管理者智能體。

于是我們幫他建了一個可以調用其他所有智能體的管理者智能體。它像是在上面再加了一層抽象，負責監控和觀察。結果他每天收到的通知，從七十多條降到了五條，而且這個管理者智能體自己還會幫忙調試和修復其他智能體的問題。

主持人（Alessio）：聽起來像是它們有一個內部收件箱，彼此可以發消息。

Simon Last：它們用的其實還是 Notion 這個記錄系統。

Sarah Sachs：對，我們其實沒有發明什么特別新的概念。與其讓我自己收到那些通知，它們完全可以直接往某個數據庫里寫任務，讓另一個智能體監聽，或者通過 Webhook 去 @ 它。

Simon Last：我們現在就是盡量先用稍微粗糙一點但能跑通的方法把它做起來。那次我們就是建了一個記錄智能體 Issue 的新數據庫，讓這些智能體都有權往里提交問題，再給管理者智能體讀這個庫的權限。結果效果很好。

本質上就是給智能體建了一套內部 Issue 追蹤系統。如果以后這被證明是個普遍有用的概念，我們也許會把它打包成更標準的產品。但總的來說，我們還是盡量通過組合基礎原語來解決問題。

再比如，Notion 本身并沒有所謂“記憶”這個獨立概念。記憶就是頁面和數據庫。你想給智能體記憶，就給它一個頁面，再給它編輯權限。人類能改，智能體也能改。這個模式特別好用，而且可擴展性很高。

郵件、日歷和原生集成，重點在于誰對體驗負責

主持人（Alessio）：我在搭那個 demo 時，系統問我想接 Gmail 還是 Notion Mail。我當時心想，我其實哪個都不關心，我只想讓你幫我搞定。那你們怎么分配這類產品精力？Notion Mail、Notion Calendar 這些界面還重要嗎？

Simon Last：我覺得很重要的一點是，你不應該被迫使用 Notion Mail 才能接入郵件功能。我們應該能直接接 Gmail，或者你喜歡的其他服務。郵件之所以偉大，很大程度上就是因為它特別適合被智能體驅動。某種意義上，郵件應用本身也可以被看成一個預先打包好的收件箱自動化智能體。

Sarah Sachs：但這里的區別在于質量所有權。

當我們和 Gmail 集成時，我們更多是通過 MCP 或 API 向 Gmail 提供一組工具；而當我們接 Notion Mail 時，就會有專門的 Notion Mail 工程團隊去打造最適合那個場景的工具，對延遲、性能和質量負責。

那邊的產品負責人會直接思考郵件場景下的用戶痛點。所以我們通常會先做原生集成，再考慮如何把它通用化。因為先做原生集成，往往更容易把體驗打磨到位。

CLI 和 MCP，不是誰贏誰輸，而是誰更像下一代基礎設施

主持人（Swyx）：說到集成，我必須問一件事，MCP 還是 CLI？

Simon Last：我個人絕對非常看好 CLI。它有幾個特別迷人的地方。第一，它運行在終端環境里，自帶很多力量。比如長輸出可以分頁，你可以在里面瀏覽。第二，它天然支持漸進式呈現，你一開始不會把所有工具都攤給模型，它先看到的是 CLI 外殼，可以用 help，可以讀文件。

最酷的是它的自舉能力。如果出了問題，智能體可以在自己使用工具的那個環境里直接調試和修復。

我今天早上就看到一條推文，有人說自己的智能體沒有瀏覽器，所以它給自己寫了一個瀏覽器工具。不到一百行代碼，它就封裝了 Chromium API，給自己搓了個小瀏覽器。如果這個工具有 Bug，它還能繼續修自己。

相反，如果你用的是 Chrome DevTools 的 MCP，而傳輸通道崩了，智能體就徹底失去瀏覽器，也失去了自救能力。我覺得這里有非常根本的差異。

主持人（Swyx）：不過話說回來，它的很多問題也不是協議本身的問題。比如漸進式呈現完全可以靠更好的框架來實現。最開始大家一股腦把所有工具都扔給模型，當然不行，但那不一定是 MCP 自身的錯。

Simon Last：這點我同意。現在確實有很多實現得不太好的 MCP，因為大家之前都沒經驗。

總的來說，我很看好 CLI。但在某些環境下，我也仍然很看好 MCP。特別是那種需要輕量、單一能力、權限邊界極清晰的智能體場景。很多時候，你不需要一個擁有完整計算運行時的編程智能體，你需要的只是一個只能調用工具的東西。

MCP 在這件事上天然非常強。而 CLI 的問題在于，它的權限邊界往往沒那么直觀。它能不能接觸 API Token？Token 有沒有被妥善處理？這些都會引入很多真實而棘手的新問題。

所以我會說，MCP 是那種簡單、粗暴，但非常管用的好東西。

Sarah Sachs：我從 Notion 的角度補兩個視角。

第一，Notion 的使命是成為企業工作里最好的記錄系統。所以只要外部生態還在使用 MCP，我們就一定會繼續支持它。無論我們個人偏好什么，Notion 已經在這上面投入了很多，也有很強的團隊在做。

第二，是成本問題。我最近一直在想一件事，怎么讓定價真的和模型能力匹配起來。對于一些確定性很強的任務，如果你還要讓大模型經由 MCP 去跟第三方服務反復交互，那其實是一種浪費。它不只是貴，而且不夠確定。

尤其是我們的自定義智能體是按使用量計費的。我們把定價看成用戶使用產品的門檻，所以非常在意別浪費用戶的錢。對客戶不公平，對商業上也不是好事。

如果某件事能通過 CLI 確定性地寫代碼執行，那可能就是一次性成本；相反，如果它每次都要經由模型和 MCP 重復跑一遍，你就會不斷燒 Token，甚至緩存一失效又得再來一遍。那沒有必要。

主持人（Swyx）：對，開放性是關鍵。如果我自己能直接寫代碼調 API，我也不會去用 MCP。但在一些場景里，你知道要調用什么，又不想每次都從頭開始實現，那 MCP 還是很有價值。

主持人（Alessio）：那你們內部到底怎么判斷？什么時候用簡單 API，什么時候用 MCP，什么時候又要上更開放的智能體，比如帶代碼沙盒的那種？

Sarah Sachs：在 Notion AI 內部，我們不會簡單說，因為這個能力太開放，所以我們就不發布它。

但有很多時候，我們不選 MCP，是因為我們想對質量有更深的控制。搜索和我們所謂的“智能體查找”就是典型例子。

我們在 Notion 里集成了 Slack、Linear、Jira 的搜索，但沒有直接使用這些公司提供的搜索 MCP。因為我們覺得，想讓一個智能體工作流真的表現出色，就必須對搜索旅程本身的細節有更多控制。

當然，長尾需求還是很多，所以我們也會做 MCP 服務器，讓大家接他們想接的任何東西。但像搜索這種核心入口，以及少數一些特別關鍵的集成，我們會更愿意自己下場來做，因為我們知道自己的秘方在哪。

Simon Last：我覺得這里面其實沒有真正的沖突，只是技術棧層級不同。MCP 提供的是一個獲取工具訪問權限的協議，它是開放協議，所以很適合覆蓋大量長尾需求。

但如果你看我們的工具設置，你會發現“觸發器”根本不在里面，因為 MCP 做不到觸發器協議。這意味著有些東西我們必須自己建。

我們現在有些集成用了 MCP，比如 Linear 和 GitHub；但 Slack、郵件和日歷是內部自建的，因為我們不僅要把工具打磨得極好，還得加上觸發器。

所以我更愿意把它理解成，不同層級在做不同事。關鍵是你得在對的時間，用對的工具。

主持人（Swyx）：你一直在說重構。能不能大概回顧一下，你們這幾次重構都改了什么？

Simon Last：我試試，這差不多得像做代碼考古一樣。

2022 年底我們最早做的那個版本，本質上其實是個編程智能體。我們當時想，與其造一堆工具，不如讓一切都變成 JavaScript。我們給它 JavaScript API，讓它自己寫代碼來完成調用。

但那時候模型寫代碼真的太爛了，所以不行。于是我們轉向工具調用。問題是，那時原生工具調用功能還沒出現，所以我們發明了一整套 XML 表示法。

那一版最大的教訓是，我們太迎合 Notion 自己的數據模型了，而忽略了模型真正想要什么。比如我們做了一套能無損映射到 Notion Blocks 的 XML，轉換非常方便，也有一整套頁面編輯的 mutation 操作。但效果很糟。因為模型根本不懂這套東西，而且你還得在提示詞里把它硬塞進去。

主持人（Swyx）：對，而且塞進去之后模型也用不好。

Simon Last：對。所以后來我們意識到，不行，必須上 Markdown。模型懂 Markdown。

于是我們又做了一次大重構，基本上是造了一種“Notion 風格的 Markdown”。核心想法是，底層必須盡量是純 Markdown，然后在上面做增強。它不一定非得做到完全無損。

數據庫這一層也有類似的教訓。Notion API 原本的數據庫查詢是很復雜的 JSON 格式，和內部表示能很好對應，但模型不喜歡。于是我們把它推翻了，想法變成，一切都做成 SQLite，所有查詢都讓模型像寫 SQLite 一樣去寫。模型對這個特別擅長。

所以我覺得有一個特別大的教訓，就是給模型它真正想要的東西。你在設計環境的時候，必須極其謹慎地想清楚，模型究竟喜歡什么表達形式。不要把系統里那些沒必要的復雜性暴露給它。

Sarah Sachs：但這還不是全部。后來又有了原生工具調用，我們做了研究模式，然后我們徹底拋棄了少樣本提示詞，轉向更純粹的工具定義。現在我們又在思考智能體 2.0。

Simon Last：對。整體的發展弧線其實很有意思。一開始你依賴單樣本、少樣本；然后變成給工具，但還要保留很多示例；再后來變成，干脆直接給它一堆工具。

但這又帶來新問題。當工具越來越多的時候，漸進式呈現就變得非常關鍵。我們一度遇到一個瓶頸，智能體本來工作得很好，但隨著工具不斷增加，整個系統越來越難繼續擴展，我們開始擔心新的工具會把模型搞崩。

主持人（Swyx）：就那種，你只是說句“你好”，都要消耗一大堆 Token，而且速度很慢。

Simon Last：對，不只是成本問題，也是質量問題。因為每個工程師為了某個小眾功能引入新工具，都有可能導致模型過度調用它，最后拖累整體表現。所以我們后面專門做了一輪框架優化，把漸進式呈現做得優雅一點。

Sarah Sachs：我甚至覺得，這可能比推理模型本身帶來的轉折還大。因為從少樣本提示轉向以目標為導向的工具描述之后，我們終于能把工具所有權真正分發給不同團隊。

在過去，大家其實都在共同編輯同一串系統提示詞，稍微順序不一樣，模型行為就會變化。那種模式不可能擴展，公司根本沒法規模化。后來通過評估體系和更好的工具抽象，我們才終于把工具分出去，讓每個團隊能擁有自己的工具和定義。

當然也會出事故。比如我們曾經寫出兩個同名工具，Anthropic 的 Sonnet 就崩了，OpenAI 的模型反而自己想辦法繞過去了。很多教訓都不是紙上來的，是一腳踩出來的。

最危險的誤解，是把自定義智能體做成“誰都能一眼看懂”的玩具

主持人（Swyx）：那你們會把這些工具列表公開嗎？還是這屬于機密？

Simon Last：完全公開。你直接問智能體，它會告訴你。

Sarah Sachs：我們不覺得系統提示詞是我們的核心秘密。

Simon Last：而且我覺得，對操作者來說，理解這些其實很重要。有哪些工具、工具怎么運作、該怎么提示它，都是高級用戶需要知道的。

我們內部有一句話，叫“教班里最聰明的學生”。我們希望自定義智能體是強大的工具。雖然設置界面盡量做得簡單，但它應該有深度。操作者得能探到它的工作原理。

Sarah Sachs：甚至可以再說得更絕一點，我們其實并沒有試圖讓它變成一個任何人都能一下子完全搞懂的產品。因為你越想把它簡化到那個程度，你越會把可解釋性和能力一起抽掉。

我們在做自定義智能體的時候，大概花了一個半星期才達成這個共識，我們不是在為所有人構建這個產品。一旦大家在這件事上想明白，整個團隊推進速度反而更快了，因為目標用戶終于更清晰了。

主持人（Alessio）：那個給智能體生成提示詞的配置過程，到底是怎么工作的？

Simon Last：其實就是智能體自己在工作。我們在自定義智能體上做了一件我特別喜歡的事，它可以配置它自己。我們不僅給了它發郵件之類的工具權限，也給了它配置和調試自身的工具。

所以當你讓它去寫系統提示詞時，本質上就是這個智能體自己在做這件事。我們并沒有硬塞太多東西，只是給了它一份“怎么做一個好自定義智能體”的開發指南。

最棒的地方在于，如果它失敗了，你可以直接問它為什么失敗，再告訴它，更新你的指令，下次別再犯這個錯。這個閉環非常自然。

Sarah Sachs：很顯然，這也意味著我們下一步應該去做更明確的“自我修復”功能。

主持人（Alessio）：我其實已經體驗到了。雖然還不是全自動，但我有一次配錯了東西，點一下“修復”按鈕，它就會自己幫我改。

Simon Last：這里其實牽扯到一個很關鍵的權限問題。自定義智能體默認是沒有任何權限的，你必須顯式授予它所有權限，這樣你才能放心讓它后臺運行。

比如你知道，它可以讀我的郵件，但不能發郵件，那你心里就有數了。如果你讓它完全自動修自己，它就會跨過這個邊界，因為它不應該自己偷偷修改自己的權限。

所以現在的做法更像是，你點擊一個按鈕，進入管理員模式，和它做一段同步對話。它在改之前也會先給你確認。

主持人（Alessio）：而且我很喜歡的一點是，編輯它和使用它是在同一個聊天框里完成的。不是一個地方配置、另一個地方使用。

Sarah Sachs：對。這個設計我們內部叫“Flippy”。

Simon Last：最開始的想法其實相反，設置是主界面，旁邊放一個測試區。但如果你真的接受“它就是一個智能體”這件事，那更合理的設計就是翻過來。主視圖應該是聊天框，設置更像一個側邊欄，用來預覽它正在修改什么。我們希望最后做到，你幾乎不需要手動去碰那些設置，而是直接通過對話完成。

Sarah Sachs：這個功能其實是這次發布里最大的攔路虎之一。因為很多早期用戶已經習慣了舊流程，改他們的認知很痛苦。我們甚至為此多拖了一個月。但所有人最后都覺得，這個方向太對了，必須這么做。

主持人（Alessio）：現在它是免費的，這很好。但以后開始收費時，你們為什么會選用積分這種方式？

Sarah Sachs：因為真實成本不只是 Token。我們確實是跟 Token 使用量掛鉤，但你不能把所有東西都直接攤平成 Token 價格。比如有些開源模型跑在 GPU 上，網絡搜索有自己的成本，沙盒又是另一種成本。再加上高優先級處理、異步處理、緩存命中率，這些全都不一樣。

所以我們必須在 Token 之上再建一個抽象層。

更重要的是，我們從一開始就想讓客戶得到公平交易。不是說我們想在這里暴利，而是客戶應該只為合理的事情付錢。我們賣的本來就是企業級 SaaS，如果你賣積分包，客戶買得多也更容易做折扣，這在銷售流程上也更順。

主持人（Alessio）：但價值不是均勻的。有人可能拿它去更新食譜，有人可能拿它去回投資人的重要郵件，價值差距很大。你們內部會討論按價值收費嗎？

Sarah Sachs：我們當然想過。但問題是，什么叫“復雜”或“有價值”，一旦真要嚴格定義，就會非常復雜。我們最開始也想過按智能體運行次數收費，但推演一圈之后你會發現，最終還是繞不開與 Token 吞吐量直接相關的復雜性。

所以目前按量計費是最樸素也最現實的方式。

還有一個特別現實的原因，我們的核心智能體一直帶著模型選擇器。為了維持利潤率，有些功能我們根本承擔不起。比如以后數據庫自動填充如果都變成智能體驅動，而每個單元格都在跑 Opus 級別的能力，那這個產品在商業上根本不成立。

所以我們需要給那些愿意花錢做更多事的人一個出口，但又不能把高成本強加給低頻用戶。

而且，不是所有知識工作都一樣復雜。很多智能體任務其實很快就碰到模型能力天花板，根本不需要一個特別貴的模型。我們希望用戶自己決定，到底要不要為某個任務花那筆錢。甚至現在產品里也會主動提醒你，這個操作是不是很貴。

主持人（Alessio）：有趣的是，大家在這種異步場景里，似乎也沒那么在意速度。

Sarah Sachs：對。當任務本身是異步的，“更快一點”這個優勢就沒那么重要了。我們更想做的是把真正有價值的額外服務給到用戶，而最好的約束就是讓他們自己掏自己的錢。

主持人（Swyx）：那 Auto 呢？很多人會本能地以為，Auto 只是選最便宜的模型。

Sarah Sachs：這正是我們現在特別努力的一件事，讓大家明白 Auto 不是“最便宜、最笨”的那個，而是最適合你當前任務的那個。

我們其實在花很多力氣優化 Auto，因為這就是智能體實驗室真正該做的事。某種意義上，Auto 很像智能投顧。我們不是拿它當利潤工具，而是拿它去減少用戶壓力。

它肯定不會永遠是最強的模型，因為大多數任務根本不需要 Opus 那種級別的能力。

Simon Last：而且和很多前沿實驗室不一樣，我們并沒有被激勵去讓你盡可能多地消耗 Token。我們真正關心的是，為你找到完成任務的正確工具。很多時候，那個正確工具甚至是直接寫代碼，根本不需要智能體。

如果某個智能體最終能自動化地把自己“炒掉”，我們其實會很開心。

Notion 真正想卡位的，是協作發生后的全部沉淀

主持人（Swyx）：我聽下來，你們早晚會去訓練自己的模型。畢竟你們有這么多 Token 數據。

Sarah Sachs：如果你說的是花自己的錢去訓練一個基礎模型，我并不這么看。

Simon Last：我也不覺得這應該成為我們的核心競爭力。

如果真要往模型訓練走，我更感興趣的不是給全世界做一個超級通用模型，而是未來是不是能做那種真正理解某一家企業上下文的模型。不是所有人共用一個大腦，而是一個特別懂你們公司業務、員工、流程的模型。那種東西如果有一天足夠可行，我覺得質量提升會非常明顯。

Sarah Sachs：現在確實已經有企業客戶會問類似的問題，比如能不能把一個很懂他們內部環境的模型帶進來，或者自己帶密鑰接進來。這也正是為什么我們會更愿意把系統提示詞和工具接口做得開放一點。

當然，在 Notion 的某些具體能力上，我們還是會做微調和強化學習。但那不一定需要直接吃用戶數據。只要我們的數據科學家和模型行為工程師足夠清楚地理解差距在哪，我們就會在那些地方下手。

Simon Last：我自己以前在模型訓練上花過非常多時間。那件事特別容易讓人上癮。你會一直訓練、一直重訓，睡前都得確保實驗在跑。

Sarah Sachs：然后我這個管預算的人就會出現，把你叫停。

Simon Last：是的。但現在很有意思的是，編程智能體又把這種狀態帶回來了。現在我睡覺前也會想，我有沒有啟動足夠多的智能體，讓它們在我睡著的時候繼續跑。

有一次我甚至讓一個編程智能體線程連續跑了十七天。

Sarah Sachs：然后前沿實驗室的人跑來問我，Simon 到底在干嘛，他是不是在證明弦理論。

Sarah Sachs：不過我們現在確實有一個領域在明顯加大訓練投入，就是檢索。

因為現在我們很多搜索流量，其實已經不是人發起的，而是智能體發起的。打到 ElasticSearch 或向量索引上的那些查詢，背后很多根本不是人在搜，而是智能體在搜。

這件事會改變整個檢索系統的優化目標。對于人類搜索，你可能特別在意第一名和第六名的位置差異、點擊率這些。但對智能體來說，更重要的是 Top-K 是否夠全、返回結果能不能覆蓋更多可能答案。

你會開始思考并行查詢、查詢扇出、查詢多樣性這些問題。甚至很多時候，向量嵌入本身已經不是最重要的優化層級了。更重要的是檢索、排序、查詢生成這整條鏈怎么一起工作。我們內部把這個方向叫“智能體查找”。

所以你會看到我們開始更認真地招排序工程師、模型訓練工程師，因為這里確實已經變成一個新的核心問題。

主持人（Alessio）：我們也得聊聊會議紀要。這個功能現在做得很好，背后到底發生了什么？

Sarah Sachs：會議紀要其實一開始讓我們非常緊張。我們擔心它會逼著大家學習一套新的工作方式，擔心用戶摩擦太大。

但現在回頭看，它已經成了我們最強的增長引擎之一，無論是病毒式傳播還是留存都很強。所以隨著它表現越來越好，我們也在不斷往里加資源。

我覺得這個功能真正強大的地方在于，Notion 本來就是一個記錄系統，而會議紀要讓它開始捕獲另一類以前很難系統化保存的數據。

比如我自己用它的方法就是，每次和經理的一對一會議，我都會留紀要。等到年終做績效自評時，我基本上就是回頭去看這些會議記錄，然后寫我這一年做了什么。因為如果某件事從來沒有進入我和經理的一對一討論，那它大概率也不是最重要的優先級。

所以會議紀要給我們帶來了大量非常有價值的信號。這對一個記錄系統當然很重要，對智能體也很重要。因為一旦你開始有了大量轉錄文本，你的內容規模會爆炸式增長，你怎么做上下文壓縮、怎么在智能體里利用這些內容，都會被它反過來推動。

主持人（Alessio）：某種意義上，這是在捕獲一類全新的數據。以前 Notion 里已經有我很多別的資料，所以我自然也會把這些新東西繼續放進來。

Sarah Sachs：完全是這樣。我們團隊現在的工作方式基本上已經連起來了。每天站會前，會有一個自定義智能體先去讀 Slack 和 GitHub，生成會前閱讀。然后會議紀要記錄會議過程。開完會之后，再有一個和日歷聯動的智能體，根據討論內容往任務數據庫里生成今天或明天要做的事，同時自動發出我們在會里決定要跟進的 Slack 消息。

所以我們在會里基本可以雙手離開鍵盤，把注意力放在問題本身，而不是圍繞問題做一堆繁瑣記錄。

Simon Last：會議紀要最近還多了一個我特別喜歡的功能。它在生成總結時會自動 @ 提及被提到的人。所以現在只要有人在會里提到我，我就會收到通知。

主持人（Alessio）：這會讓你立刻知道，哦，他們正在聊我負責的東西。

Simon Last：對。我一看到這種通知，就會想，太好了，我應該馬上去跟他們聊聊。

Sarah Sachs：這背后其實也有很多小但關鍵的質量工作。比如如果公司里有兩個 Simon，系統怎么知道會議里提到的是哪一個？我們會做參會者相似度緩存，也會建立人物畫像去輔助判斷。目標當然是盡量別搞錯。

會議紀要本質上就是建立在轉錄原語上的智能體原語。它一開始可能只是總結，現在已經越來越像一個數據捕獲問題。以后我們當然希望它更進一步，比如它能在會議進行的同時，知道這場會對應哪個任務數據庫、應該往哪里更新哪些任務，讓整個過程更無縫。

主持人（Alessio）：那你們會不會去做硬件？比如 OpenAI 現在就在做新的硬件形態。

Sarah Sachs：大概率不會。

Simon Last：但我對這個品類本身是很興奮的。

Sarah Sachs：我會把它理解成一種機制，而這種機制應該和 Notion 深度配合。無論最后是誰在做這類硬件，我們都愿意和他們合作。

現在已經有很多很有意思的公司在做可穿戴設備，他們都在和我們的合作團隊交流。我每次都很愛旁聽這些 demo。因為你完全可以想象，這種能一直陪在你身邊的設備，一旦能搜索上下文、接入 CRM、再連上 Notion 智能體，會形成很多新的用法。

但這里又和自定義智能體不太一樣。它越簡單，你反而越難對它進行那種非常高級的能力控制。所以它更像是一個很好的數據捕獲入口，不一定適合做復雜工作流本身。

Simon Last：而且這類設備天然很私人。公司不可能強迫每個人都戴個腕帶，對吧。

我們真正關心的切面更像是，公司能不能把會議里所有這些上下文最終變成對自己有價值的記錄和能力。

Sarah Sachs：對，這其實和我前面說的是一回事。我們的工作不是去構建最好的智能體運行框架，也不是構建最好的硬件。我們的工作是成為人們協作的最佳場所，是這些記錄最終最該落下來的地方。

主持人（Alessio）：也就是說，別人把數據管道接進來，你們把后面的事做好。

Sarah Sachs：對，我覺得這就是最合理的定位。