我們如何構建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轉錄，而無需手動搜索。這證明，只要代理擁有數據訪問權限，人們會找到最輕鬆的使用路徑。