我們如何構建LangChain的GTM代理

在LangChain，每一個外呼銷售流程都曾經從相同的方式開始：銷售代表在多個標籤頁之間切換，檢視Salesforce、Gong、LinkedIn和公司網站，花費15分鐘進行研究，然後才能寫一個字。而且，他們無法知道團隊成員是否已經在前一天聯絡過潛在客戶。入站跟進也意味著手動將相同的資訊輸入到Apollo中。為了解決這個問題，我們構建了一個端到端的GTM代理，它可以自動處理整個流程。

該代理在Salesforce中出現新線索時觸發，檢查是否應該聯絡，收集背景資訊（包括會議歷史），並透過Slack傳送草稿供代表批准。它基於Deep Agents構建，適合這種多步驟、長時間執行的任務。關鍵成果令人印象深刻：從2025年12月到2026年3月，線索到合格機會的轉化率提高了250%，管線金額增加了3倍。代表們對低意向線索的跟進增加了97%，高意向線索增加了18%，每位代表每月節省40小時，團隊總計1320小時。銷售團隊的每日活躍使用率為50%，每週活躍使用率為86%。

在編寫程式碼之前，我們定義了代理必須滿足的約束和成功標準。兩個目標是：減少代表研究每個線索的時間，提高營銷入站的轉化率。非談判條件是：必須有人的參與，沒有任何郵件可以在代表審查和批准之前傳送；代理必須知道通話記錄，以避免重複聯絡。核心能力包括：關係感知個性化（根據客戶狀態調整草稿）、可解釋性（代表可以看到關鍵輸入並理解代理的推理）、學習迴圈（代理從代表的編輯中學習）。每個代表的操作（傳送、編輯、取消）都被記錄到LangSmith中，用於評估質量。

隨著範圍擴大，代理還加入了賬戶情報功能。每週一早上，代理從Salesforce和BigQuery拉取資料，並檢查外部世界的融資、產品釋出和AI動態。為銷售團隊和部署工程團隊定製報告。銷售報告聚合產品使用、開發者生態系統、網路活動等訊號，識別擴充套件機會和競爭動向。工程師報告關注賬戶健康狀況，包括產品使用、客戶通話精彩部分、續訂日期等，以便團隊及時介入。

代理使用Deep Agents進行多步驟編排，因為輸入大小和結構變化很大。Deep Agents自動將大型工具結果解除安裝到虛擬檔案系統，避免手動截斷。我們還使用本機規劃工具強制執行檢查清單：不傳送檢查→研究→草稿→理由→跟進。代理透過LangSmith連線，從開始就設定評估，捕捉迴歸問題。兩個關鍵代理模式是記憶和子代理委派。記憶系統：當代表編輯草稿時，系統比較原始和修訂版本，提取風格偏好並儲存。每個代表的偏好被自動應用，每週進行壓縮。子代理委派：賬戶情報透過編譯的子代理執行，每個子代理有受限的工具集和結構化輸出模式，父代理為每個賬戶生成一個子代理，並行執行，由LangSmith Deployment處理擴充套件。

評估和反饋：在編寫任何生產程式碼之前，我們在LangSmith中定義成功標準。具有代表性場景的評估集從簡單到複雜，涵蓋各種情況。評估分為兩層：規則性斷言檢查基本正確性，LLM法官評分語氣、字數和格式。兩者作為CI的一部分執行。除了評估，還跟蹤每個Slack動作並關聯到實際結果，從而驅動改進。

代理最初作為後臺過程執行，但後來構建的對話式Slack介面意外地被公司其他部門採用。工程師、客戶成功和客戶經理都開始使用它來查詢產品使用、支援歷史和Gong轉錄，而無需手動搜尋。這證明，只要代理擁有資料訪問許可權，人們會找到最輕鬆的使用路徑。