揭秘｜LangChain團隊用AI agent做銷售和營銷的最佳實踐

你有沒有想過，銷售這件事可能會被徹底重新定義？不是那種換個 CRM 系統或者學幾個銷售話術的小改進，而是從根本上改變銷售人員的日常工作方式。想象一下，銷售代表不再需要在 Salesforce、Gong、LinkedIn、公司網站之間瘋狂切換標簽頁，不再需要花 15 分鐘做背景調查才能寫出第一個字，也不用擔心同事昨天剛聯系過的客戶今天又被重復騷擾。這不是未來的幻想，而是 LangChain 團隊已經實現的現實。他們構建了一個 GTM Agent（Go-to-Market Agent，市場推廣 AI agent），從 2025 年 12 月到 2026 年 3 月，僅僅三個月時間，就把潛在客戶到合格商機的轉化率提升了 250%，pipeline 規模增長了 3 倍，同時為整個銷售團隊節省了 1320 個小時。

當我讀到 LangChain 分享的這個案例時，我意識到這不只是一個銷售自動化工具的成功故事。這代表了一種全新的工作范式：AI agent 不再是簡單地回答問題或生成內容，而是真正能夠端到端地執行復雜業務流程，并且在執行過程中不斷學習和優化。更重要的是，LangChain 作為一家 AI 基礎設施公司，他們自己就是這項技術的第一個用戶，這讓他們的經驗格外具有說服力。我想深入剖析他們是如何做到的，以及這對我們理解 AI agent 在企業應用中的真實價值有什么啟發。

銷售流程的真實痛點

LangChain 在文章開頭就直接描述了他們銷售團隊之前的工作狀態：每一次外呼都是從同樣的方式開始的，銷售代表在多個標簽頁之間切換。打開 Salesforce 查看客戶記錄，切到 Gong 聽通話歷史，再跳到 LinkedIn 看聯系人信息，然后去公司網站了解背景。光是做這些背景研究就要花掉 15 分鐘，而且完全無法確定團隊里的其他人是不是昨天剛聯系過這個客戶。對于入站線索的跟進，則意味著要手動在 Apollo 里給每個新聯系人發送同樣的消息。

這個場景我太熟悉了。我之前和很多銷售團隊合作過，發現這種低效不是個例，而是行業普遍現象。問題的核心在于，銷售是一個高度依賴上下文信息的工作。你必須了解客戶是誰、他們的公司在做什么、之前有過什么互動、現在處于什么階段，才能寫出一封真正有針對性的郵件。但這些信息散落在至少五六個不同的系統里，沒有任何一個系統能給你完整的畫面。

更糟糕的是，銷售團隊規模擴大后，協調成本會呈指數級增長。你不僅要擔心自己有沒有遺漏什么信息，還要擔心同事有沒有已經聯系過這個人。我見過太多次這樣的尷尬場景：同一家公司的兩個銷售代表在同一周內給同一個潛在客戶發了幾乎一模一樣的郵件，結果客戶直接拉黑了這家公司。這種失誤不僅浪費了銷售機會，還會嚴重損害品牌形象。

所以當 LangChain 決定構建一個能夠端到端處理這個流程的 AI agent 時，他們瞄準的是一個真實存在、影響巨大的痛點。這不是為了 AI 而 AI 的技術炫技，而是為了解決銷售團隊每天都在面對的實際問題。

GTM Agent 到底做了什么

LangChain 構建的 GTM Agent 主要做兩件事情。第一，它能夠研究潛在客戶并撰寫個性化的郵件草稿。第二，它會聚合賬戶層面的各種信號，包括網站活動、開發者生態系統數據、產品使用情況和營銷接觸點，幫助銷售代表清楚地知道應該把精力集中在哪里。通過將這些意圖數據與銷售代表負責的賬戶關聯起來，它能夠浮現出有意義的活動，標記出交易風險和競爭對手的動向，并明確下一步應該聯系誰。

我覺得這個設計非常巧妙的一點是，它不是試圖完全取代銷售人員，而是把銷售人員從重復性的研究和起草工作中解放出來，讓他們能夠專注于真正需要人類判斷和創造力的部分。整個流程是這樣的：當一個新的潛在客戶出現在 Salesforce 系統里時，AI agent 會立即接管。它做的第一件事不是馬上寫郵件，而是尋找"不應該發送任何內容"的理由。如果這個人剛剛提交了一個技術支持工單，或者團隊成員在本周早些時候已經聯系過，那么發送自動化郵件就是一個錯誤。這個 agent 被設計成非常謹慎的。

一旦通過了這些檢查，它會做銷售代表過去手動做的所有研究工作：拉取完整的 Salesforce 記錄，閱讀 Gong 的通話記錄，查看潛在客戶的 LinkedIn 個人資料。如果內部歷史記錄不多，它會使用 Exa 這個工具去網上搜索，了解這家公司目前在 AI 方面正在做什么。

如何撰寫郵件草稿取決于關系的狀態。這個 agent 遵循一個定義好的 outbound skill（外呼技能），這是一個它在起草之前會加載的行動手冊。這個技能被設計成能夠覆蓋溫暖和冷淡兩種情況。現有客戶會收到與溫暖潛在客戶不同的內容，而溫暖潛在客戶又會收到與冷接觸不同的內容。對于冷外呼，agent 會保持簡潔并以研究為基礎，遵循他們在技能中定義的行動手冊。

銷售代表會在 Slack 私信中看到完成的草稿，帶有發送、編輯或取消的按鈕。他們還可以看到 agent 的推理過程，這樣就能清楚地知道它為什么采取了特定的角度。如果他們發送了郵件，agent 會排好一組后續跟進郵件，讓銷售代表可以選擇是否將這個潛在客戶加入后續培育流程。

我認為這里有一個非常關鍵的設計決策：human-in-the-loop（人在回路中）。LangChain 明確表示，沒有經過銷售代表的明確審查和批準，任何內容都不會被發送出去。一封時機不當的郵件可能會毀掉數月的關系建設。這不僅是一個安全措施，也是一個數據收集機制。每次銷售代表的操作（發送、編輯、取消）都成為系統可以學習的信號。

賬戶智能：從被動響應到主動洞察

隨著團隊規模的擴大，銷售代表開始負責 50 到 100 多個賬戶。在這種規模下，很容易讓一些賬戶變得沉默，或者讓擴展機會悄悄溜走。LangChain 的解決方案是讓 GTM Agent 每周一早上自動從 Salesforce 和 BigQuery 拉取數據，然后檢查外部世界的融資輪次、產品發布和新的 AI 計劃。

他們為兩個受眾定制了報告：銷售團隊和部署工程團隊，因為他們關心不同的數據點。對于銷售團隊，agent 會聚合產品使用、開發者生態系統、網站活動、招聘趨勢和公司新聞等信號，以浮現擴展機會。它會標記高管變動、軟件包安裝量的激增，以及公司是否正在積極招聘 AI 工程師或構建 agentic 系統——這是他們準備擴展的強烈信號。當他們推出新功能時，它還會識別潛在的良好匹配對象，將最近活動與新功能良好契合的賬戶匹配起來。而且因為僅僅知道一個賬戶是活躍的還不夠，它會浮現哪些個人最活躍，并建議下一步應該聯系誰。

對于部署工程師，重點轉向賬戶健康狀況。agent 從 BigQuery 拉取產品使用數據，提取最近客戶電話的要點，即將到來的續約日期，以及客戶接近用完額度的情況。它還會浮現最近通話中的開放問題和未解決的線索。目標是標記真正需要人工介入的內容，這樣團隊就不用在周日晚上翻看儀表板了。

我覺得這個賬戶智能功能特別有價值的地方在于，它不只是被動地回答銷售代表的問題，而是主動地發現和浮現重要的信號。傳統的商業智能工具通常需要你知道要問什么問題，然后去查詢數據。但現實中，銷售代表往往不知道應該關注什么，或者他們根本沒有時間去主動挖掘數據。AI agent 通過持續監控多個數據源并識別有意義的模式，實際上是在充當一個永不疲倦的分析師，幫助銷售團隊發現那些可能會錯過的機會。

更重要的是，這種主動洞察是基于多源數據的綜合分析。一個公司在招聘 AI 工程師可能意味著他們在擴大 AI 團隊。如果同時他們的軟件包下載量在激增，高管層有了新的 CTO，那么這三個信號結合起來就構成了一個非常強烈的擴展機會指示。單獨看每個信號可能不夠有說服力，但當 AI agent 能夠跨多個數據源進行綜合分析時，它就能發現這些隱藏的模式。

技術架構：為什么選擇 Deep Agents

LangChain 在構建這個系統時面臨的核心挑戰是：這個 agent 需要從多個來源拉取數據，跨這些數據進行推理，并產生個性化的輸出。這遠遠超出了簡單的 LLM 調用能夠可靠處理的范圍。

他們選擇了 Deep Agents 來處理多步驟編排，原因是輸入本質上是尖峰化的：會議數據、CRM 歷史記錄和網絡研究在大小和結構上變化很大。使用 Deep Agents，大型工具結果會自動卸載到虛擬文件系統中，所以他們不必構建自己的截斷和檢索層。他們還使用了 harness 的原生規劃工具來強制執行一致的檢查清單（不發送檢查 → 研究 → 草稿 → 理由 → 后續跟進），這使得運行更容易調試并減少了 agent 的漫游。

我認為這個技術選擇非常關鍵。很多人在構建 AI agent 時低估了處理可變輸入和多步驟編排的復雜性。當你只是做一個簡單的問答系統時，輸入和輸出都相對可預測。但當你要處理真實的業務流程時，數據的復雜性會爆炸式增長。有些客戶可能有十幾次 Gong 通話記錄，每次通話可能持續一小時；有些客戶可能完全是新的，只有一個 LinkedIn 個人資料和一個公司網站。如果你沒有一個能夠優雅處理這種可變性的架構，系統很快就會變得不可靠。

Deep Agents 提供的虛擬文件系統功能解決了一個很實際的問題：當工具返回的數據太大而無法直接放入 LLM 的上下文窗口時，應該怎么辦？傳統方法是截斷數據或者構建復雜的檢索系統。但 Deep Agents 通過自動將大型結果卸載到虛擬文件系統，讓 agent 可以在需要時再去訪問相關部分，既保持了效率又不會丟失信息。

另一個重要的技術選擇是將 agent 連接到 LangSmith，這樣他們可以理解銷售代表實際上是如何使用它的，并衡量 agent 是否隨著時間的推移而改進。這意味著從一開始就設置評估，而不是后來再改裝，這對于在迭代提示或切換模型版本時捕獲回歸至關重要。

Memory 系統：讓 AI Agent 從每次編輯中學習

LangChain 在文章中描述的 Memory（記憶）系統是我覺得整個設計中最巧妙的部分之一。當銷售代表在 Slack 中編輯草稿時，系統會將原始版本與修訂版本進行比較。如果更改是實質性的，一個 LLM 會分析差異并提取結構化的風格觀察：發生了什么變化，這對銷售代表的偏好意味著什么，以及一個可選的引用示例。這些觀察被存儲在 PostgreSQL 中，按銷售代表分組，每次未來運行都會在起草之前讀取它們。

每個銷售代表在語氣和簡潔性方面都有風格偏好。反饋循環是自動的。每次編輯都會教會 agent，下一次草稿就會反映出來。一個每周的定時任務會壓縮這些記憶，防止它們隨著時間的推移變得臃腫。

我認為這個設計天才的地方在于，它把人在回路中的需求轉化成了一個持續學習的機制。很多人把 human-in-the-loop 僅僅看作是一個安全措施——確保 AI 不會犯錯誤。但 LangChain 意識到，每次人類編輯實際上都是一個訓練信號。銷售代表刪掉了一句話？那可能意味著草稿太啰嗦了。他們改變了開頭的語氣？那可能意味著對于這種類型的客戶，應該用更正式或更隨意的方式。

更重要的是，這個記憶系統是個性化的。不同的銷售代表有不同的風格，面對不同的市場和客戶群。一個專注于企業客戶的銷售代表可能需要更正式的語言，而一個專注于初創公司的銷售代表可能更喜歡簡潔直接的風格。通過為每個銷售代表維護獨立的記憶，系統能夠適應這些個人差異，而不是強迫每個人使用同一種模板。

這種學習循環的強大之處在于它的隱性和持續性。銷售代表不需要填寫反饋表單或者給 AI 打分，他們只需要像平常一樣編輯草稿。系統會自動從這些日常操作中學習和改進。隨著時間的推移，草稿會越來越符合每個銷售代表的風格，需要的編輯會越來越少。這就是我理解的真正的 AI 助手：不是一個需要你適應它的工具,而是一個能夠適應你的伙伴。

Subagent Delegation：如何處理復雜的并行任務

在處理賬戶智能功能時，LangChain 采用了一個叫做 subagent delegation（子 agent 委托）的模式。賬戶智能通過編譯的 subagents 運行：這些是具有受限工具集和結構化輸出模式的輕量級 agents，它們作為與主 agent 的契約。銷售研究 subagent 可以訪問 Apollo、Exa 和 BigQuery，并返回結構化的潛在客戶和市場上下文。部署工程師 subagent 使用 Salesforce、Gong 和支持工具來返回使用趨勢、開放工單和擴展信號。

父 agent 為每個賬戶生成一個 subagent，保持工具隔離和輸出可預測。因為 subagents 獨立運行，他們可以并行執行它們。LangSmith Deployment 處理水平擴展和持久執行，所以系統隨著量的增長保持可靠。

我覺得這個架構設計解決了一個很現實的問題：當你需要處理幾十個甚至上百個賬戶時，如果串行處理，整個流程可能需要幾個小時才能完成。但如果你能夠并行處理，就可以在可接受的時間內完成所有分析。

更深層的洞察是關于責任邊界的清晰劃分。每個 subagent 都有明確定義的工具集和輸出格式。銷售研究 subagent 不會去看支持工單，部署工程師 subagent 不會去做市場研究。這種清晰的邊界不僅使系統更容易理解和調試，也減少了 agent 出錯或產生不相關輸出的可能性。

我在構建復雜系統時經�？吹降囊粋�問題是，當一個組件試圖做太多事情時，它往往什么都做不好。通過將復雜任務分解成多個專門的 subagents，每個都專注于特定的數據源和輸出格式，LangChain 創建了一個更模塊化、更可維護的系統。如果他們需要改進銷售研究的質量，他們可以只修改那個 subagent，而不用擔心影響部署工程師的功能。

Evals 和反饋：如何確保質量不會退化

LangChain 強調，在為新工作流編寫任何生產代碼之前，他們會在 LangSmith 中定義成功的樣子。他們從一個小型的代表性場景庫開始，這些場景都基于銷售代表實際面對的情況，使用這些來構建初始 agent 或功能，并確�；A功能在擴展之前是有效的。

一旦功能正常運行，他們會在 LangSmith 中擴大評估集，以涵蓋更難的情況：深入研究 agentic AI 或 NLP 的研究人員，他們試圖重新吸引的現有客戶，有先前 Gong 記錄的賬戶，像醫療保健這樣有大量行話的垂直行業。一切都通過一個測試工具運行，該工具模擬他們的外部 API，這樣他們可以在接觸真實數據之前在受控環境中觀察行為。

他們在兩個層面進行評估。首先，基于規則的斷言檢查基礎知識：正確的工具、正確的順序、沒有重復的草稿。其次，LLM 評委對語氣、字數和格式進行評分。兩者都作為 CI 中完整評估套件的一部分運行，他們將 agent 行為中任何無法解釋的漂移視為值得調查的 bug。

但我認為 LangChain 在這里真正聰明的地方是，他們意識到評估只能講述部分故事。真正重要的是銷售代表日常如何使用草稿。他們跟蹤每個 Slack 操作（發送、編輯、取消）并將其直接附加到 LangSmith 中的 trace。隨著時間的推移，這讓他們能夠將寫作模式與真實結果相關聯：哪些風格帶來了打開率，哪些主題行得到了回復。當某些模式在足夠多的銷售代表中成立時，他們就會將其編碼到 agent 的默認行為中。

我覺得這種雙軌制的評估體系非常值得學習。自動化評估能夠快速發現明顯的錯誤和回歸，但它無法告訴你 AI 生成的內容在真實世界中是否有效。只有通過跟蹤真實用戶的行為和結果，你才能知道什么真正起作用。

這也解決了 AI 系統的一個核心挑戰：如何持續改進。很多 AI 系統在部署后就停止進化了，因為沒有有效的反饋機制。但 LangChain 通過將用戶操作與 traces 關聯起來，創建了一個持續的學習循環。每次銷售代表發送、編輯或取消一個草稿，系統都會學到一些東西。這些學習可以用來調整提示、改進模型，或者更新默認行為。

意外的跨團隊采用

LangChain 在文章最后分享了一個有趣的發現：GTM Agent 最初是作為一個 ambient agent（環境 agent）開始的，作為后臺進程運行。潛在客戶出現在 Salesforce 中，agent 運行，草稿發送到銷售代表的 Slack。沒有觸發器，沒有手動工作。

后來他們構建了一個對話式 Slack 界面作為副項目，主要是為了給 SDR 一種直接與 agent 交互的方式。他們沒有預料到的是它傳播到公司其他部門的速度有多快。因為 agent 已經連接到 Salesforce、Gong、BigQuery 和 Gmail，人們發現了他們沒有設計的用途。工程師在不編寫 SQL 的情況下檢查產品使用情況。客戶成功團隊在續約電話之前拉取支持歷史�？蛻艚浝碓跁h前總結 Gong 記錄。

他們沒有有意構建任何這些工作流。agent 有訪問權限，人們找到了阻力最小的路徑。與機器人交談比打開六個不同的標簽頁更容易。

我認為這個意外的跨團隊采用揭示了一個深刻的洞察：當你構建一個真正有用的 AI agent 并給它訪問核心數據系統的權限時，它的價值會自然地擴散到你最初設想之外的用例。這不是因為你做了什么特別的營銷或推廣，而是因為人們會自然地尋找更高效的工作方式。

這也說明了為什么將 AI agent 與現有的系統記錄（systems of record）集成如此重要。如果 LangChain 構建的是一個獨立的工具，需要手動輸入數據或者只能訪問有限的信息源，它可能永遠不會獲得這種有機的跨團隊采用。但因為它已經連接到 Salesforce、Gong、BigQuery 等核心系統，它自然而然地成為了一個任何需要訪問這些數據的人都可以使用的界面。

我也注意到一個有趣的演進：從環境 agent 到對話式界面。環境 agent 非常適合標準化、可預測的工作流，但當人們需要更靈活、更探索性的使用方式時，對話式界面就變得非常有價值。能夠直接問"這個客戶的產品使用趨勢如何"或者"最近一次與這個客戶的通話提到了什么問題"，比導航一個復雜的 UI 或者編寫 SQL 查詢要直觀得多。

我的思考：AI Agent 的真正價值在哪里

讀完 LangChain 的這個案例，我最大的感受是：AI agent 的真正價值不在于完全自動化某個任務，而在于重新定義人機協作的邊界。

很多人在談論 AI agent 時，關注的是它能否完全取代人類完成某項工作。但我認為這個視角太狹隘了。LangChain 的 GTM Agent 之所以成功，恰恰是因為它沒有試圖取代銷售代表，而是識別出銷售流程中哪些部分是重復性的、可自動化的，哪些部分需要人類的判斷和創造力。研究客戶背景、拉取歷史記錄、起草初版郵件——這些都是費時但相對機械的工作，AI 可以做得很好。但決定是否發送、如何調整語氣、什么時候跟進——這些仍然需要人類的專業判斷。

我也看到了一個重要的模式：最成功的 AI agent 往往是那些能夠融入現有工作流程的。LangChain 沒有要求銷售代表學習一個新的界面或者改變他們的工作習慣。草稿出現在 Slack 中，他們已經每天都在用的工具。數據來自 Salesforce 和 Gong，他們已經在使用的系統。這種無縫集成大大降低了采用的摩擦力。

另一個深刻的洞察是關于學習循環的重要性。一個靜態的 AI 系統，無論最初設計得多么好，都會隨著時間的推移變得過時。但如果你能構建一個從每次交互中學習的系統，它就會持續改進。LangChain 的 Memory 系統和反饋追蹤機制創建了這樣一個學習循環，使得系統能夠適應不同銷售代表的風格偏好，并從真實的結果數據中學習什么真正有效。

我還特別欣賞 LangChain 對可解釋性的重視。AI agent 不只是給出一個結果，它還解釋為什么選擇了某個角度，使用了哪些數據源。這種透明度不僅建立了信任，也讓銷售代表能夠更好地理解和改進系統的輸出。在企業環境中，這種可解釋性往往比純粹的性能更重要。

最后，我認為 LangChain 這個案例證明了一點：構建 AI 基礎設施的公司應該成為自己產品的第一個用戶。他們在構建 GTM Agent 的過程中積累的經驗和遇到的挑戰，直接幫助他們改進了 LangChain 和 LangSmith 這些產品。這種"吃自己的狗糧"（dogfooding）不僅能發現產品的真實問題，也能讓他們更深刻地理解客戶的需求。

從更宏觀的角度看，我相信 LangChain 的 GTM Agent 代表了企業 AI 應用的一個重要方向：不是構建獨立的 AI 工具，而是將 AI 能力深度集成到現有的業務流程中，創建一個人機協作的智能系統。這種系統能夠處理大量的重復性工作，同時保持人類在關鍵決策點的控制權，并且能夠從每次交互中持續學習和改進。這才是 AI agent 在企業環境中應該有的樣子。

結尾

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

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

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

- END -

兩個“特別坑”的AI產品創業方向，你知道嗎

速度將成為AI時代唯一的護城河

a16z重磅預測：Vibe coding贏者通吃？錯了，垂直專業化才是未來