現成的 AI 撞牆了:HubSpot 怎麼解

TL;DR

• 三個教訓:(1) 有彈性的基礎設施(自建 harness、可換模型的抽象層);(2) 完整且可信的 context;(3) 到客戶所在的地方去(meet customers where they are)。
• 不強迫,用數據說服:他們沒有規定工程師必須用 AI。最大的阻力是工程師擔心可靠度受損——所以他們拿數據證明可靠度維持中性,後來甚至上升。
• 模型選擇不是二選一,而是三維權衡:quality、latency、cost,且是這個優先順序。因為每一項 go-to-market 任務對這三者的價值主張都不同——大宗低風險任務可以先做成本優化,高風險任務(例如會直接接觸「客戶的客戶」的動作)則不能妥協。
• context 的難點不是塞不塞得下:不只是 context window 上限或 context drift,更是一個 overfitting 問題——丟太多、品質差、對當下任務不夠具體的 context,結果反而更爛。
• 共用平台會複利:「任何人建的每一個 agent,都會讓所有 agent 更好」,因為它同時貢獻了 context 與平台能力本身。
• 放棄把客戶鎖在自家 UI:深度整合進 Claude、Gemini、ChatGPT,讓客戶在他們原本工作的地方就能用到 HubSpot 的 agent 平台與 context;自家 web / mobile UI 與 Breeze assistant 維持完整功能對等。

重點整理

背景與問題(約 00:52–00:53)

HubSpot 上個月剛過 20 週年,做的是 go-to-market 平台——服務中小企業與部分大型企業的行銷、業務、客服團隊。今天有超過 300,000 家企業、約 140 個國家、橫跨數十個產業在用,所以他們看得到各種規模與地區公司的實況。

客戶現在問的問題,關鍵在多出來的那個副詞:「我到底要怎麼真的用 AI 轉型?」——不是跑試點、不是玩玩,而是為公司大規模交付真實價值。他們三年多的結論是:工具與工具鏈只是起點,不夠;怎麼做才是差別所在。

而且有個意外收穫:他們一開始問的是「怎麼用 AI 換一種方式做開發」,結果這些教訓大量適用於「該替客戶做什麼、怎麼在客戶的旅程上接住他們」。

教訓一:有彈性的基礎設施(約 00:53–00:59)

撞牆點:2023 年左右他們從 code assist 往早期 co-pilot 走,但現成系統撐不住他們的規模——當時每天約 100 萬次 build、超過 10,000 個微服務(現在更多)。問題核心是:模型很懂一般的 coding 問題,但不懂他們的業務與工作方式。選擇是等工具廠商追上,或自己下去解——他們選了後者。

做法:

• 在 MCP 非常早期就建了一批 MCP 整合,把環境知識直接帶進 co-pilot。
• 很早就建了現在會叫做 agent execution platform / agent harness 的東西:容器化架構,能輕鬆開出 sandbox 讓測試迴圈全自動跑、不需人介入,對工程師來說很輕量,對可靠度與資安來說也安全。
• 不強制使用 AI。他們想讓工程師自己被說服。最大的阻力是可靠度——平台對 go-to-market 團隊與客戶是 mission-critical,工程師擔心生成的程式碼會拖垮它。於是他們拿數據說話:早期使用區域的資料顯示可靠度維持中性;而今天,可靠度其實是上升的。
• 成果(三年前):約 80% 採用率、整體生產力與速度提升約 51%。他特別說明這是複合指標,刻意不只看 PR 數或程式碼行數,以免過度轉向單一指標。

外推到客戶端的教訓:不能依賴單一廠商或單一模型家族。模型不只一直在進步(有點像賽馬),更重要的是它們在不同領域是參差的(jagged);套到 go-to-market 這種很具體的領域,不同模型、不同尺寸、不同廠商各有勝場,right tool for the right job。

所以他們很早就需要能跑 eval、對模型與尺寸做 A/B test 的能力。而判準不是單純的「品質」或「eval 分數」,而是 quality、latency、cost 三者的組合,而且是這個優先順序。因為他們替數百種 go-to-market 任務建 agent,每一種任務對這三者的價值主張都不同:有些是低風險的大宗流程,品質門檻仍高但成本優化很早就很重要;有些則是高風險——特別是 HubSpot 平台要去跟客戶的客戶互動的時候。

於是他們建了抽象層(今天會叫它 agent harness),2026 年的版本比 2023 年成熟得多。它讓他們在底層直接換模型、跑 eval、做回歸測試與比較;而且刻意設計成讓 feature team 完全不必碰底下的管線——團隊自己建 eval、對多個模型跑、換進換出而不出現回歸,全程不需要理解底層。

收斂成一句話:共用地基要先做,不要最後做。 精實或求快的直覺會讓人「一套 stack 打天下」,但他們的經驗相反:前期花在 harness 上的力氣,換來的是對自己命運的掌控權——能做 eval、能換模型、能改 agentic loop 的跑法。而且今天做這件事容易多了,市面上有很多好方案(他點名 Fireworks)。

教訓二:完整且可信的 context(約 00:59–01:02)

當他們從 co-pilot 走到自主的 coding agent,agent 需要理解 codebase、慣例與整個環境;而他們有十年份的自建工具鏈。這裡連 MCP 都不夠——要讓 coding agent 理解 build chain 的一切,他們投入大量心力在回填 context,這才是從前沿模型身上多榨出效能的關鍵。

context 很難,而且難在意想不到的地方:不只是撞到 context window 上限或處理 context drift,更是一個 overfitting 問題——如果你只是丟一大堆 context,而品質不好、對當下任務不夠具體,結果反而更差。把這件事做對,本身就是一項值得養成的技能與平台能力。

• 內部成果(2025 年初):96% 的工程師在用 AI,速度提升 60%。
• 客戶端:go-to-market 旅程上有大量不同任務與 agent(prospecting agent、customer support agent⋯),在對的時間給對的 context 能顯著改善品質、效能與成本。最具體的例子:一個「demo 後續追蹤信」的 agent,六個月內從「業務約三分之二的時候需要改寫(調整語氣或修正錯誤)」變成「約三分之二的時候直接原封不動寄出」。

他的總結:AI 懂世界懂得很多,但你需要一個懂你的世界的平台。 而那些資料,大多只存在你公司內部,不在外面的世界裡,因此也不在模型裡。

教訓三:到客戶所在的地方去(約 01:02–01:04)

對內:共用工具、共用原語、建在共用平台上。「任何人建的每一個 agent,都會讓所有 agent 更好」,因為它同時貢獻了整體 context 與 agent 平台本身。成果:

• 100% 的工程師用 agentic coding 開發
• 程式碼行數 +73%
• PR 首次回饋時間 -90%
• 速度上升的同時,品質與可靠度也在上升

對外:身為 SaaS 廠商,歷史上你會想著「怎麼把客戶留在我的 UI 裡」——他們完全放掉了這件事。真正要交付的價值是「讓我們建立的智慧,在客戶工作的任何地方都不可或缺」。所以他們深度整合進 Claude、Gemini 與 ChatGPT,讓客戶在那些地方就能拿到 HubSpot agent 平台的完整能力與 context。當然很多客戶仍選擇用 web / mobile UI 或自家的 Breeze assistant——這幾條路線維持完整的功能對等。

結語:地基沒打好,曲線會 plateau;地基一旦到位,就會出現複利式的威力,不只改變團隊怎麼做東西,也放大了能交付給客戶的價值。

金句

"AI knows a lot about the world, but you need a platform that knows your world."(約 01:01)

整場最凝練的一句——context engineering 的商業版本。

"Do that first, not last."(約 00:58)

指共用地基(harness、eval、抽象層)。他明說這與「先求 MVP、單一 stack 打天下」的直覺相反。

"Every agent anybody builds makes all agents better."(約 01:02)

共用平台的複利效果:每個 agent 都同時貢獻 context 與平台能力。

"It's not a matter of just hitting a context window limit or dealing with context drift. It's also the fact that there's effectively an overfitting problem."(約 01:00)

對 context engineering 難點最精準的診斷:多不等於好。