LangChain 與 Claude Code：GTM 工程何時該用哪一個？

GTM 工程正逐漸成為 AI Agent 最明確的應用場景之一。

這份工作充滿半結構化任務：客戶研究、資料補全、名單評分與分流、開發訊息個人化、通話前準備、CRM 清理、廣告受眾同步、QBR 產出、流失商機再啟動，以及內部通知。每個工作流程都需要資料、判斷、工具，以及一定程度的人為控制。

這也帶出一個實際問題：

GTM 工程團隊應該使用 LangChain 或 LangGraph 這類框架建置系統，還是透過 Claude Code／Codex 類型的 Harness 來操作？

答案是：兩者都要，但用在不同層次。

LangChain 和 LangGraph 更適合正式環境中的 Agent 應用；Claude Code 類型的 Harness 則更適合作為 GTM 工程師的工作台，讓人研究、製作原型、檢查、除錯並持續改善系統。

Clay 自己的 GTM 工程技術棧，正好能清楚說明這項區別。

Clay 的 GTM 工程技術棧實際長什麼樣？

Clay 曾公開相當詳細的資料，說明內部 GTM 工程團隊如何運作。重點不在於 Clay 使用 Clay，而是整體架構。

Clay 表示，其內部 GTM 工程團隊以四項核心工具運作：

• Clay：負責協調 GTM 工作流程
• Snowflake：儲存產品與使用資料
• Salesforce：管理 CRM 紀錄
• Gong：保存通話錄音、逐字稿與營收相關脈絡

Slack 則是日常操作介面。Clay 表示，他們建立了一個 Slack App，讓 GTM 工程師不用另開分頁，就能啟動行銷活動、查看訊號、取得通話前研究、存取會議筆記，以及寄出後續訊息。

他們也加入多項 AI 工具：

• Dust：建立在 Notion、Gong、Salesforce、Slack 等公司知識之上的內部 Agent 層
• Claude 和 ChatGPT：業務代表使用的對話介面
• Clay MCP：讓這些對話工具呼叫經核准的 Clay 資料與工作流程
• Clay Functions：受到治理、可重複使用的工作流程單元
• Claygents：Clay 的 GTM Agent 基礎元件
• Claygent Builder 和 Sculptor：用來建置、測試、版本控制及部署 GTM Agent

這套技術棧並不是「把 20 個 SaaS 工具黏在一起」，而更接近：

Salesforce、Snowflake 與 Gong 是記錄系統；Clay 負責協調；Slack、Claude 與 ChatGPT 則作為操作介面。

真正值得複製的是這套架構。

資料來源：How Clay Built Its GTM Engineering Function、How Clay Uses Clay from Inside Claude and ChatGPT、Clay MCP

Clay 如何處理「工程」這一部分？

Clay 的 GTM 工程團隊不像一個被動回應零散需求的 Ops 團隊，反而更像產品工程團隊。

Clay 描述了幾項運作原則：

1. 兩週一個 Sprint。 其他團隊提交自動化、資料品質修正與工作流程需求，GTM 工程團隊負責分流、整批規劃並在 Sprint 內交付。
2. 版本控制。 Clay 表示，他們將資料表與工作流程視為程式碼。每次變更都有版本、文件紀錄，並經過有意識的發布流程。
3. Release notes。 團隊會發布更新說明，讓公司其他成員知道有哪些變更。
4. 集中建置，分散使用。 Ops 與 GTM 工程團隊建立經核准的工作流程；業務代表則透過 Slack、Claude、ChatGPT、CRM 欄位或其他熟悉的介面使用它們。
5. 預設納入治理。 業務代表不需要接觸底層工作流程。透過 Clay MCP 與 Functions，Ops 可以決定每個流程能做什麼、可存取哪些資料、誰可以使用，以及適用的預算限制。

這就是 GTM 工程的核心模式：

集中建置邏輯，再透過使用者原本就在工作的介面提供功能。

這和叫每位業務自己寫 Prompt 完全不同——它把上市推廣視為工程問題，而不是一堆個人習慣的集合。

Clay 使用哪一種 Agent 框架？

Clay 並未公開表示「我們使用 LangChain」、「我們使用 CrewAI」或「我們使用 Temporal」。根據公開資料，答案其實更直接：Clay 使用自家的 Agent／工作流程平台。

公開的基礎元件包括：

• Claygent：用於研究、評分、分類、個人化與網頁任務的 GTM Agent
• Claygent Builder：用來建置、測試、版本控制、回復與部署 Claygent
• Sculptor：以自然語言建立工作流程與 Agent 的工具
• Clay Functions：受到治理、可重複使用的工作流程邏輯
• Clay MCP：一個 Model Context Protocol 介面，將 Clay 資料與 Functions 提供給 Claude、ChatGPT 與 Codex 類型的環境
• Claygent Navigator：可在網頁上執行操作、類似瀏覽器 Operator 的 Claygent

Clay 的 Agent 開發循環非常明確：

1. 用自然語言描述 Agent 應該完成的任務。
2. 使用 Sculptor 將意圖轉換成可運作的 Agent 或工作流程。
3. 用真實的 Clay 資料表資料測試。
4. 使用不同模型執行。
5. 比較輸出結果。
6. 調整 Prompt、Guardrail 與模型選擇。
7. 為變更建立版本。
8. 如果品質下降，就回復上一版。
9. 將同一套 Agent 邏輯部署至多個資料表或工作流程。

這不像通用的開源 Agent 框架，反而更像一套內部 GTM Agent 平台。

資料來源：Claygent Builder、Claygent Navigator

LangChain 與 LangGraph 適合放在哪裡？

LangChain 是建置 LLM 應用的廣泛生態系；真正和嚴謹 GTM 工程最相關的則是 LangGraph，因為它是為長時間執行、具狀態的 Agent 工作流程而設計。

LangGraph 的公開文件特別強調：

• 持久化執行（durable execution）
• Human-in-the-loop 中斷點
• 短期與長期記憶
• Checkpoint 與持久化
• 使用 LangSmith 除錯
• 正式環境部署

當 GTM 工作流程從實驗走向正式環境後，你遇到的正是這些問題。

例如，想像一個「流失商機再啟動」Agent：

1. 監控已流失的客戶。
2. 偵測相關訊號：新一輪募資、新任主管、產品發布、招募異動、競爭對手變化。
3. 取得 CRM 歷史紀錄。
4. 取得通話逐字稿。
5. 摘要商機流失的原因。
6. 判斷該客戶是否值得重新接觸。
7. 草擬訊息。
8. 要求人員核准。
9. 將任務或 Email 推送至 Salesforce、HubSpot 或 Slack。
10. 記錄結果，並從後續成果中學習。

這就是適合 LangGraph 的使用情境：它需要狀態、可重複性、錯誤處理、人工核准與可觀測性。

資料來源：LangGraph docs

Claude Code 或 Codex Harness 適合放在哪裡？

Claude Code／Codex 類型的 Harness 和 LangGraph 並不是同一種東西。

它不像已部署的工作流程後端，更像是一個 AI 操作環境——與其說是託管式 SaaS 工具，不如說更接近大型企業為何開始打造自己的 Coding Agent。它可以檢查檔案、執行指令、瀏覽文件、呼叫 MCP 工具、編輯程式碼、建立 Script、撰寫 Prompt、分析匯出資料，並與人一起反覆迭代。

因此，在一套打法成為正式基礎設施之前，這類 Harness 對 GTM 工程非常有用。

Harness 適合用來：

• 研究目標客群
• 設計 GTM 打法
• 整理需要使用的資料來源
• 撰寫資料補全 Prompt
• 在 CSV 上測試評分規則
• 產生第一版工作流程
• 檢查 CRM 匯出資料
• 撰寫 Script 以標準化資料
• 建立內部文件
• 建置可重複使用的 Skill 與 Playbook
• 找出工作流程失敗的原因
• 比較供應商或 API

換句話說：

LangGraph 負責執行已驗證的工作流程；Harness 則協助 GTM 工程師發掘、建置與改善這套流程。

實際差異

問題	LangChain／LangGraph	Claude Code／Codex Harness
它是什麼？	建置 Agent 應用的框架	執行 AI 輔助工作的操作環境
最適合的用途	可重複執行的正式環境工作流程	研究、原型製作、除錯與工作流程設計
主要使用者	軟體工程師	GTM 工程師、創辦人、Ops 人員、技術行銷人員
狀態	明確的 Graph state、Checkpoint 與記憶	對話脈絡、檔案、Workspace、Skill 與外部工具
人工核准	直接設計在工作流程中	透過對話、權限、檔案審查自然完成
部署方式	後端服務／Agent 應用	Agent Session、自動化或工具輔助工作流程
可觀測性	LangSmith、Trace 與 Graph state	Log、Terminal 輸出、檔案與對話紀錄
Guardrail	程式碼層級政策與 Graph 結構	工具權限、指令、核准與審查
擴展性	大量使用者、大量執行、正式排程	高槓桿的專家工作，較不適合高併發
最適合的 GTM 範例	全天候客戶監控器	由人主導建立這個客戶監控器

一條簡單的判斷規則

當工作流程仍然混亂時，使用 Claude Code 類型的 Harness；當工作流程已經驗證成功時，使用 LangGraph。

聽起來很簡單，卻能避免大量無效的工程投入。

許多團隊還沒理解 GTM 動作，就急著開始打造「Agent」。他們把尚未成熟的打法包進一套耐久的系統裡；等到打法改變、資料假設失效，原本的工程投入反而成為阻力。

更好的路徑是：

1. 使用 Harness 探索。
2. 以人工或半人工方式執行這套打法。
3. 找出可以重複執行的步驟。
4. 定義資料契約。
5. 加入核准與品質檢查。
6. 最後才把工作流程搬進 LangGraph 或其他正式環境框架。

Clay 自己的做法也指向這條路。他們將工作流程視為程式碼，同時讓使用者介面維持簡單。業務代表不必理解底層基礎設施，只要提出想要的結果即可。

從哪裡開始？

多數團隊一開始都不該打造完整的 GTM Agent 平台。

先建立一套由 Claude Code／Codex 類型 Harness 驅動的 GTM 工程工作台，並用它打造第一批打法：

• 研究目標客群中的客戶
• 監控競爭對手
• 根據 Inbound 訊號進行名單評分
• 追蹤產品發布與招募訊號
• 建立目標客戶名單
• 建立內容研究與分發工作流程
• 挖掘客戶使用情境
• 將創辦人主導的 Outbound 訊息個人化

等到某套打法證明可以重複執行，再把它提升為正式環境中的 Agent 工作流程。

一套實用的架構可以長這樣：

• 單一事實來源：HubSpot 或 Salesforce
• 資料倉儲：BigQuery、Snowflake 或 Postgres
• 工作流程後端：LangGraph
• 可觀測性：LangSmith 或其他同類 Trace 工具
• 介面：Slack、Linear、Email、Claude、ChatGPT 或 Codex
• 工具層：連接 CRM、網路研究、資料補全、Email、廣告與文件的 MCP Server
• 操作工作台：Claude Code／Codex Harness

這能讓你同時取得兩邊的優點：Harness 適合混亂、需要 Human-in-the-loop 的 GTM 工程；LangGraph 則適合耐久、可重複執行的工作流程。

從 Clay 身上真正該學的事

Clay 的 GTM 工程優勢並不來自某一個 Agent 框架，而是它的運作模式：

• 維持精簡的技術棧
• 集中管理工作流程邏輯
• 在使用者原本就工作的地方提供工作流程
• 把 GTM 系統視為程式碼
• 使用真實資料測試
• 對 Prompt 與工作流程進行版本控制
• 在擴大規模前加入治理
• 將成功的打法轉換成可重複使用的基礎設施

這才是所有 AI 原生 GTM 團隊都該學的事。

LangChain 或 LangGraph 可以協助你建置正式環境層；Claude Code 或 Codex 則能幫助 GTM 工程師在探索正式環境該長什麼樣子的過程中加速前進。

把兩者視為競爭對手才是真正的錯誤。它們是同一套系統中的不同部分。

如果再加入 n8n，整套技術棧就會從兩層變成三層——請參考 Claude Code、LangGraph 與 n8n：GTM 工程技術棧，了解自動化膠水層如何融入其中。

資料來源

• Clay：How We Built Clay's GTM Engineering Function
• Clay：The Four Layers of Winning GTM Infrastructure
• Clay：How Clay Uses Clay from Inside Claude and ChatGPT
• Clay：Claygent Builder
• Clay：Clay MCP
• Clay：Claygent Navigator
• LangGraph：LangGraph GitHub docs