賣掉上一家公司后，這位連續創業者拿下1600萬美元，要用開源顛覆AI Agent開發

你有沒有想過，開發一個真正可靠的 AI agent 有多難？大多數人以為原型階段就是全部，但當你真正要把 AI agent 推向生產環境時，你會發現這才是噩夢的開始。如何處理任務失敗？如何管理并發？如何調試出了問題的 agent？如何確保系統在高負載下依然穩定運行？這些問題讓無數開發者陷入困境，不得不從頭開始構建復雜的微服務架構，處理各種邊緣情況，花費數月時間在基礎設施上，而不是真正的產品創新上。

Trigger.dev 正是為了解決這個痛點而生。這家開源公司剛剛宣布完成了 1600 萬美元的 A 輪融資，由 Standard Capital 領投。更令人矚目的是，他們每月已經在為超過 30000 名開發者執行數億次 AI agent 任務。從教育科技到視頻廣告制作，從音頻數據集構建到各種企業應用，Trigger.dev 正在成為開發者構建生產級 AI agent 的首選平臺。我深入研究了他們的技術方案和客戶案例后，發現這家公司正在解決一個被嚴重低估但極其關鍵的問題：如何讓 AI agent 從演示走向真正可靠的生產應用。

AI Agent 開發的真實挑戰

我發現很多人對 AI agent 開發存在一個巨大的誤解：他們認為只要調用幾個大語言模型的 API，寫幾行代碼，agent 就能工作了。這種想法在做演示或原型時確實沒問題，但當你要把它部署到生產環境，服務真實用戶時，你會發現問題遠比想象中復雜得多。讓我從一個具體的場景說起，這樣你就能理解開發者面臨的真實困境。

想象你正在構建一個教育科技產品，需要分析數百萬學生與 AI 的互動記錄，為老師提供實時洞察。每次學生完成一輪對話，你的系統就需要觸發一個分析任務，提取學生的參與度、興趣點、可能存在的問題行為等信息，然后生成摘要發送給老師。聽起來很簡單，對吧？但實際上，你需要處理以下這些復雜問題：這個分析任務可能需要幾秒鐘甚至更長時間才能完成，你不能讓用戶界面一直等待。如果分析過程中大語言模型返回了格式錯誤的數據怎么辦？如果網絡請求失敗了怎么辦？如果同時有成千上萬個學生完成對話，你的系統能處理這么大的并發量嗎？你如何確保優先處理付費用戶的請求，同時又不讓免費用戶完全得不到服務？當出現問題時，你如何快速定位是哪個環節出了錯？

這就是 MagicSchool AI 面臨的真實挑戰。MagicSchool 是有史以來增長最快的教育科技公司，僅用兩年時間就服務了全球超過 450 萬名教師，并被獨立評為最安全的 AI 平臺。他們的平臺為教師提供了一整套持續更新的 AI 工具，幫助教師節省時間、促進負責任的 AI 素養培養，并為學生開啟新的學習機會。但要實現這個愿景，他們必須解決一個核心技術挑戰：如何從數百萬學生互動中快速提取有價值的洞察，并實時傳遞給教師。

教師需要快速而清晰的洞察來了解學生如何使用 AI 工具。但監控每一次互動對時間緊張的教育工作者來說太耗時了，所以 MagicSchool 希望構建實時摘要系統，直接發送給教師。這些摘要會突出顯示學生的參與程度，從分心到高度投入，同時還會注意到新的興趣點，并在存在問題行為時發出警報。舉個例子，摘要可能會告訴教師學生在關于氣候變化的討論中表現出高度參與，或者可能會提醒教師某個學生一直在試圖讓 AI 講屎尿屁笑話。這些高層次的洞察可以為教師節省數小時逐條審查每條消息的時間，同時讓他們保持知情。這也讓教育工作者在部署 MagicSchool 這樣的工具時更加放心，因為他們知道可以為學生提供一個安全的環境來接觸 AI 并培養 AI 素養。

如果沒有 Trigger.dev，MagicSchool 的工程師就必須自己構建整個任務編排系統。他們需要設置消息隊列、實現重試邏輯、處理失敗情況、監控任務執行狀態、管理并發控制、實現優先級隊列等等。這至少需要幾個月的開發時間，而且還需要持續維護。更糟糕的是，這些基礎設施代碼會占用大量工程資源，而這些資源本可以用來開發真正為用戶創造價值的功能。這就是為什么越來越多的開發者轉向 Trigger.dev 這樣的平臺：它讓你可以專注于構建 AI agent 的核心邏輯，而不是被基礎設施問題困擾。

Trigger.dev 如何解決這些問題

在深入了解 Trigger.dev 的技術方案后，我認為他們最聰明的地方在于找到了開發者體驗和系統可靠性之間的完美平衡點。他們沒有試圖重新發明輪子，而是專注于解決開發者在構建 AI agent 時遇到的最核心痛點：如何讓復雜的異步任務變得簡單可靠。

讓我繼續用 MagicSchool 的案例來說明 Trigger.dev 是如何工作的。每當學生與 AI 完成一輪對話后，系統會觸發一個任務，將摘要狀態更新為"待處理"狀態保存到數據庫中。這個觸發過程非常簡單，開發者只需要幾行代碼就能完成。系統會通過實時廣播通知教師端，告訴他們"我們正在為這個對話生成摘要"。然后，任務被加入到 Trigger.dev 的隊列中等待執行。

這里的關鍵在于，開發者不需要擔心如何實現這個隊列系統，不需要考慮如果任務失敗了該怎么辦，也不需要處理大量并發請求時的資源分配問題。Trigger.dev 把這些復雜性都隱藏在了簡潔的 API 背后。開發者只需要定義任務的邏輯，剩下的交給平臺處理。

當任務開始執行時，Trigger.dev 會查詢所有相關數據，然后運行分析提示詞。MagicSchool 使用 Zod 模式配合 Vercel 的 AI SDK generateObject 函數來從大語言模型獲取結構化輸出。這個組合特別強大，因為它內置了數據解組、驗證和重試邏輯。這意味著開發者不再需要擔心大語言模型返回的數據格式不正確，或者調用失敗的情況。這些邊緣情況都被自動處理了。

一旦摘要生成完成，它會被保存到數據庫中，然后 Trigger.dev 會廣播另一條消息通知教師關于新摘要的信息。整個流程從用戶的角度看起來是無縫的：學生完成對話，幾秒鐘后教師就能看到分析摘要。但在幕后，有大量的復雜操作在進行：任務排隊、資源分配、錯誤處理、重試機制、狀態管理等等。

我特別欣賞 Trigger.dev 在代碼組織方面的設計。開發者可以像編寫普通的 TypeScript 函數一樣編寫任務代碼，但這個函數實際上運行在分布式系統中，具有微服務的所有優勢。用他們自己的話說："你有一個 TypeScript 函數，這就是你的微服務。你像調用函數一樣與它交互，但它像微服務一樣運行。"這種抽象層次恰到好處，既保持了代碼的簡潔性，又提供了生產級系統所需的可靠性和可擴展性。

MagicSchool 的工程師 Ben Duggan 分享說，使用 Trigger.dev，他們在短短幾周內就總結了超過一百萬次學生互動。由于這些任務是 I/O 密集型的，它們非常適合小型機器配置，這樣可以保持低成本的同時確保可靠性。Trigger.dev 在機器規格和運行時間上的靈活性也為更高級的處理打開了大門，比如生成詳細報告來幫助教師基于這些摘要規劃后續活動或重訪關鍵主題。

從這個案例中，我看到了 Trigger.dev 的核心價值主張：讓開發者能夠快速構建生產級 AI agent，而不需要成為分布式系統專家。這種能力在當前的 AI 時代變得越來越重要，因為越來越多的應用需要集成復雜的 AI 功能，但大多數團隊并沒有資源或時間從零開始構建基礎設施。

從視頻廣告到教育科技：Trigger.dev 的應用場景

在研究 Trigger.dev 的客戶案例時，我發現了一個有趣的模式：那些最成功地使用 Trigger.dev 的公司，往往是那些需要處理大量并行任務、對延遲敏感、且任務邏輯相對復雜的場景。Icon.com 就是一個完美的例子。

Icon.com 正在用 AI 徹底改變視頻廣告制作行業。他們的產品允許用戶上傳大量產品視頻素材，比如屏幕錄屏或實拍視頻，然后描述想要的廣告效果，系統就會自動生成大量廣告供用戶選擇，最后可以直接發布到 Instagram 或 TikTok。聽起來很酷，但實現起來涉及大量復雜的視頻處理任務。

Icon 的創始工程師 Caleb Tan 分享了他們面臨的挑戰：他們需要能夠同時處理數千個視頻。為了讓用戶能夠快速預覽和瀏覽視頻目錄，他們需要為每個視頻生成縮略圖序列。同時，廣告生成必須快速完成，他們的目標是在 5 分鐘內為用戶生成視頻。

這些需求對技術架構提出了極高的要求。想象一下，當一個用戶連接他們的 Google Drive 時，可能有數百個甚至上千個視頻文件需要處理。系統需要提取每個視頻、轉碼、生成縮略圖序列、轉錄音頻內容、將內容分塊等等。如果按順序處理，這可能需要幾個小時甚至幾天。但用戶顯然不會等那么久。

Icon 使用 Trigger.dev 來處理他們的整個視頻處理管道。他們使用 FFmpeg 為每個視頻生成縮略圖序列，這樣用戶就可以在他們提供的各種產品中快速瀏覽這些視頻。他們的主要廣告生成管道同時支持 AdGPT 和 AdCut 兩個產品。通過使用 Trigger.dev 并行化大量后臺任務，他們成功實現了低于 5 分鐘的視頻生成目標。

更令人印象深刻的是，他們還使用 Trigger.dev 的實時鉤子在前端提供任務的實時上下文信息。這意味著用戶可以看到廣告生成、產品評論抓取、受眾分析和視頻生成的實時進度。這種實時反饋大大提升了用戶體驗，讓用戶知道系統正在工作，而不是在一個黑盒中等待。

Caleb 解釋了他們為什么選擇 Trigger.dev："Trigger 是一個可靠的后臺任務平臺，能夠在我們的正常代碼庫中編寫任務改變了游戲規則。由于我們的工作負載是資源密集型的，能夠將任務卸載到 Trigger 的云平臺并獲得內置的可觀測性是一個巨大的優勢。"

這段話道出了 Trigger.dev 的另一個關鍵優勢：開發者可以在同一個代碼庫中編寫任務代碼，而不需要維護單獨的微服務倉庫。這大大簡化了開發流程，減少了上下文切換，也讓團隊協作變得更加容易。同時，當任務執行時，它們運行在 Trigger.dev 的云基礎設施上，可以獲得強大的計算資源，而不會影響主應用的性能。

Icon 通過使用 Trigger.dev 實現了以下成果：能夠同時分析數千個視頻；使用 useRealtime 鉤子和任務元數據在前端顯示實時任務進度；可靠地為處理的每個視頻生成縮略圖序列；通過并行處理將廣告生成時間縮短到 5 分鐘以內。這些成果讓 Icon 能夠與傳統視頻廣告代理商競爭，甚至取而代之，因為他們可以在幾分鐘內完成傳統方法需要幾天或幾周才能完成的工作。

從 MagicSchool 到 Icon，我看到了一個清晰的模式：Trigger.dev 特別適合那些需要處理大量異步任務、對可靠性有高要求、同時又希望快速迭代產品的團隊。無論是教育科技、視頻處理，還是其他 AI 驅動的應用場景，Trigger.dev 都在幫助開發者將更多時間投入到產品創新上，而不是基礎設施建設上。

為什么是 TypeScript 和開源

在與 Trigger.dev 的創始人交談時，我發現他們對技術選擇有著非常明確的觀點。CEO Matt Aitken 和他的團隊堅信，TypeScript 將成為構建 AI agent 的主導語言。這不是一個隨意的技術決策，而是基于對行業趨勢的深刻洞察。

Matt 的論點很有說服力：AI agent 實際上就是新一代的應用程序。應用程序應該用 TypeScript 編寫，因為這是一種更適合創建應用的語言。你可以用同一種語言編寫前端和后端。TypeScript 的獨特優勢在于，大語言模型非常擅長編寫 TypeScript 代碼。這形成了一個正向飛輪效應：TypeScript 是一種很好的與大語言模型交互的語言，同時大語言模型也非常擅長編寫 TypeScript。

這個觀察非常深刻。在 AI 時代，代碼不僅是人類開發者編寫的，也越來越多地由 AI 生成或輔助生成。如果一種編程語言既適合人類閱讀和編寫，又適合 AI 理解和生成，那么它就具有巨大的優勢。TypeScript 恰好滿足這兩個條件：它有強大的類型系統和現代的語法特性，同時大語言模型在 TypeScript 上的表現也非常出色，因為互聯網上有大量高質量的 TypeScript 代碼作為訓練數據。

Trigger.dev 的大賭注就是 TypeScript 將贏得 AI agent 開發這個領域，而他們正在努力為 TypeScript 開發者提供最佳體驗。這種專注讓他們能夠深度優化開發者體驗，而不是試圖支持所有編程語言。當然，正如他們自己開玩笑說的，讓所有人同意哪種編程語言最好并不容易，但從實際采用情況來看，他們的判斷正在被市場驗證。

另一個讓我印象深刻的是他們對開源的承諾。Trigger.dev 是 Apache 2 開源的，這在當今的創業環境中并不常見。許多公司會選擇閉源或者使用更嚴格的開源許可證來保護自己的商業利益。但 Trigger.dev 選擇了最寬松的開源許可證之一，這反映了他們對開源社區的信任和承諾。

開源帶來了多重好處。它讓開發者能夠查看源代碼，理解系統是如何工作的，甚至可以自己部署和定制。這種透明度在處理敏感數據或關鍵業務邏輯時特別重要。同時，開源也促進了社區貢獻和生態系統的發展。Trigger.dev 目前在 GitHub 上已經有超過 12000 個星標，這個數字還在快速增長。

從商業角度看，開源也是一種聰明的市場策略。它降低了開發者的采用門檻，讓他們可以先試用產品，了解它是否適合自己的需求，然后再決定是否使用付費的云服務。這種模式在開發者工具市場已經被證明非常有效。而對于 Trigger.dev 來說，他們可以通過托管服務、企業支持和高級功能來實現商業化，同時保持核心平臺的開源。

這種開源 + 商業的模式也讓 Trigger.dev 能夠吸引到最優秀的工程人才。在采訪中，他們提到正在歐洲各地招聘最hardcore的工程師。他們的招聘主張很有吸引力：解決真正困難的技術問題，既有創業公司的文化，又有大公司級別的技術挑戰。他們處理的規模遠超一般 A 輪公司，需要應對復雜的代碼執行、沙箱安全和大規模系統的挑戰。開發者會遇到各種奇怪的邊緣情況，這在技術上非常具有挑戰性。

Trigger.dev 的發展軌跡和未來方向

了解 Trigger.dev 的發展歷程讓我對他們的成功有了更深的理解。這不是一夜之間的成功，而是經過多次迭代和調整才找到正確方向的結果。

Trigger.dev 團隊在 2023 年 1 月參加了 Y Combinator，但有趣的是，他們當時帶去的是一個完全不同的想法，而且那個想法并不好。后來他們轉向了后臺任務處理，在 Hacker News 上獲得了成功的發布。他們在這個方向上工作了 18 個月，但進展并不理想。直到大約一年半前，他們推出了產品的第三個版本，開始執行用戶代碼，事情才真正開始起飛。

這個轉折點很關鍵。開始執行用戶代碼意味著他們不僅僅是一個任務調度系統，而是成為了一個真正的執行平臺。開發者可以編寫任意復雜的代碼，Trigger.dev 會在云端安全地執行這些代碼，處理所有的資源管理、隔離和安全問題。這種能力的提升正好趕上了 AI agent 的爆發，時機恰到好處。

Matt 在采訪中提到："我認為它之所以成功，部分是因為我們在做這個，部分也是時機的原因。AI agent 開始成為真實存在的東西，我們的客戶正在使用我們的平臺來構建它們。"這句話體現了創業中一個重要的真理：技術能力和市場時機同樣重要。Trigger.dev 花了 18 個月找到正確的產品方向，但當他們找到時，市場需求恰好爆發了。

從一年半前幾乎從零開始，到現在每月執行超過 2.5 億次 agent 運行，這種增長速度是驚人的。這不僅證明了他們的技術方案的價值，也說明了市場對生產級 AI agent 基礎設施的強烈需求。開發者不想重復造輪子，他們想要一個可靠的平臺來構建自己的產品。

關于未來，Trigger.dev 有著清晰的規劃。他們計劃對現有平臺進行重大改進，首先是更高級的可觀測性功能。在構建復雜的 AI agent 時，能夠清楚地看到每一步發生了什么、為什么發生、耗時多少，這些信息至關重要。他們還計劃使用 MicroVM 技術加快任務啟動速度，這將進一步提升用戶體驗。

他們也在擴展產品線以解決構建 AI agent 時更常見的問題。沙箱功能將允許執行不受信任的代碼，這對于那些需要運行用戶提供的代碼或第三方代碼的應用非常重要。他們還將推出一整套用于上下文工程和管理的工具，這正是我們之前討論的 AI agent 的關鍵組成部分。更多與常見第三方服務的集成也在計劃中，這將讓開發者更快上手，或者更容易將數據導出到其他系統。

從投資者陣容來看，Trigger.dev 獲得了強大的支持。這輪 1600 萬美元的 A 輪融資由 Standard Capital 領投，這是一家由 Y Combinator 任職時間最長的合伙人 Dalton Caldwell、Paul Buchheit 和 Bryan Berg 創立的新 A 輪基金。Trigger.dev 是 Standard Capital 首期基金的第一批公司之一。新投資者還包括 Michael Grinich 和 CTO Fund。現有投資者包括 Y Combinator、Liquid 2、Wayfinder Ventures、Pioneer Fund 和 Rebel Fund 也再次參與了本輪融資。

在采訪中，Trigger.dev 的聯合創始人分享了他們選擇 Standard Capital 的原因。流程簡單快速，讓他們能夠快速拿到資金，繼續專注于構建公司。對創始人友好，沒有董事會席位，這意味著他們保留了更多公司控制權，稀釋也比通常情況少。最重要的是，能夠與其他處于類似階段的創業公司一起學習和成長。他們提到參加了 Standard Capital 第一期的集體辦公時間，從其他公司那里學到了很多關于招聘和營銷的想法，這正是他們當前最關注的兩個領域。

有趣的是，他們還提到了 Paul Buchheit 著名的那句話："為什么你不能增長得更快？"這句話已經成為硅谷創業者的經典壓力源，但同時也是一種激勵。Trigger.dev 的創始人說他們在回家路上一直在討論："我們如何變得更激進？如何變得更激進？"這種對增長的渴望和緊迫感，正是推動創業公司不斷突破的動力。

我對 Trigger.dev 和 AI Agent 未來的思考

在深入研究了 Trigger.dev 之后，我對 AI agent 的發展有了一些新的認識。我認為我們正處在一個關鍵的轉折點：AI agent 正在從實驗性技術轉變為生產級的基礎設施。這個轉變的核心挑戰不是 AI 模型本身，而是如何將 AI 能力可靠地整合到實際應用中。

Trigger.dev 的成功說明了一個重要趨勢：開發者需要的不是更多的 AI 模型，而是更好的工具來構建基于 AI 的應用。市場上不缺少大語言模型或其他 AI 能力，缺少的是能夠讓這些能力可靠運行、易于調試、可以擴展的基礎設施。這就是為什么像 Trigger.dev 這樣的平臺變得越來越重要。

我特別認同 Trigger.dev 關于 TypeScript 的觀點。在 AI 時代，編程語言的選擇不僅僅是技術偏好問題，更是戰略選擇。一種能夠同時滿足人類開發者和 AI 模型需求的語言，將會獲得巨大的網絡效應。越多的人使用 TypeScript 構建 AI agent，就會有越多的示例代碼和最佳實踐，這又會讓大語言模型在 TypeScript 上表現得更好，進而吸引更多開發者使用 TypeScript。這是一個正向循環。

從商業模式角度看，我認為 Trigger.dev 找到了一個甜蜜點：通過開源建立社區和信任，通過托管服務實現商業化。這種模式在開發者工具領域已經被多次驗證，但成功的關鍵在于平衡免費開源版本和付費托管服務之間的價值。Trigger.dev 做得很好的一點是，他們的托管服務提供的不僅僅是便利性，還有規模、可靠性和高級功能。這讓付費變得有價值，而不僅僅是為了避免自己部署的麻煩。

我也看到了一些挑戰。隨著越來越多的公司開始構建 AI agent，市場上會出現更多類似的平臺和工具。Trigger.dev 需要持續創新，保持技術領先，同時建立強大的社區和生態系統。他們在可觀測性、沙箱執行、上下文管理等方面的規劃是正確的方向，因為這些都是構建復雜 AI agent 時的真實痛點。

另一個有趣的觀察是 AI agent 對軟件架構的影響。傳統的軟件架構往往是同步的、請求響應式的。但 AI agent 本質上是異步的、事件驅動的。一個 agent 可能需要執行多個步驟，每個步驟可能需要不同的時間，可能會失敗需要重試，可能需要人工干預。這種異步性要求我們重新思考軟件架構。Trigger.dev 提供的任務編排能力正是為了應對這種新的架構需求。

從行業發展趨勢看，我預測未來幾年我們會看到更多的"AI-native"應用出現。這些應用從一開始就圍繞 AI agent 設計，而不是將 AI 作為附加功能。MagicSchool 和 Icon 就是很好的例子。這類應用的成功需要強大的基礎設施支持，而 Trigger.dev 正在成為這個基礎設施的關鍵組成部分。

在傳統軟件開發中，當出現問題時，我們可以查看日志、監控指標、使用調試器等工具來定位問題。但在 AI agent 中，問題往往更加微妙。一個 agent 可能沒有明顯的錯誤，但生成的結果質量不佳。或者 agent 陷入了無限循環，不斷重復相同的操作。或者 agent 的決策過程不透明，我們不知道它為什么做出某個選擇。這些問題都需要強大的可觀測性工具來解決。Trigger.dev 在這方面的投入是明智的，因為隨著 AI agent 變得越來越復雜，可觀測性將成為最關鍵的需求之一。

總的來說，Trigger.dev 的故事給我最大的啟發是：在技術快速演進的時代，找到正確的抽象層次至關重要。太底層的工具讓開發者負擔過重，太高層的工具又缺乏靈活性。Trigger.dev 在這兩者之間找到了平衡，讓開發者既能快速構建 AI agent，又能在需要時進行深度定制。這種平衡不容易實現，但一旦實現，就會創造巨大的價值。從他們每月 2.5 億次的任務執行量來看，市場已經用實際行動驗證了這種價值。

結尾

也歡迎大家留言討論，分享你的觀點！

覺得內容不錯的朋友能夠幫忙右下角點個贊，分享一下。您的每次分享，都是在激勵我不斷產出更好的內容。

歡迎關注深思圈，一起探索更大的世界。