Claude Code、LangGraph 與 n8n：GTM 工程技術棧

AI GTM 工程正在催生一個新的技術棧。

它不只是 CRM 自動化，不只是 outbound 工具，也不只是 AI agent。它橫跨這一切之間：市場研究、資料豐富化（enrichment）、lead scoring、工作流設計、內容策略、客戶情報、outbound 個人化、營運自動化。

這帶出一個令人困惑的選型問題：

你該用 Claude Code 這類 harness？LangGraph？n8n？還是三個都用？

乾淨的答案是：

Harness + skills = 設計／除錯／操作者
LangGraph = 推理工作流
n8n = 觸發器／連接器／自動化黏著層

它們不是彼此的替代品，而是同一套 GTM 工程系統裡的不同層。

短版結論

當人類 GTM 工程師還在摸索時，用 harness。

當工作流包含需要結構、狀態、測試與人工核可的 AI 推理時，用 LangGraph。

當工作流主要是觸發器、連接器、API 呼叫和工具間資料搬移時，用 n8n。

最常見的錯誤，是硬要一個工具同時做三份工作。

第一層：Harness + Skills = 設計、除錯、操作者

Claude Code 或 Codex 這類 harness，最好理解成一個 AI 操作者環境。

它能讀檔案、檢視資料夾、搜尋文件、瀏覽網頁、執行指令、使用 MCP 工具、改程式碼、寫 playbook、建立 skill，並在工作過程中隨時和人對話。

這讓它特別適合處理混亂的 GTM 工程工作。

用 harness 來做：

研究一個市場
建立 ICP 定義
設計 GTM 打法
檢視 CRM 匯出資料
分析競品定位
撰寫銷售／客戶研究 prompt
建立內容策略系統
打造 lead scoring 邏輯原型
除錯壞掉的工作流
比較各家 API
把散落的知識整理成結構化 playbook

例如：

研究 50 家 APAC AI 基礎設施公司。
找出哪些可能需要 inference／GPU 成本優化。
寫出客戶筆記、購買訊號和 outreach 切角。

這就是 harness 的工作。

工作流還很模糊，人可能隨時改方向，agent 需要檢視來源、在混亂的脈絡中推理，最後產出有用的成品。

不要太早把這種工作硬塞進 LangGraph 或 n8n。

第二層：LangGraph = 推理工作流

LangGraph 的用途，是把驗證過的 AI 工作流變成明確的軟體。

當 GTM 工作流有重複出現的推理步驟時，它就派上用場：

蒐集證據
判斷契合度
為 lead 評分
決定什麼重要
產出 outreach 切角
請人核可
證據不足時重試或 fallback
跨步驟記住狀態

LangGraph 不只是「prompt 執行器」。它讓你把工作流建模成節點與狀態轉移。

例如：

new_account
-> enrich_company
-> extract_buying_signals
-> score_icp_fit
-> generate_outreach_angle
-> draft_message
-> human_review
-> return_approved_output

這樣做的價值在於，每個節點都可以有：

自己的 prompt
自己的輸入／輸出 schema
自己的重試行為
自己的 eval
自己的 log
自己的人工核可點

一旦工作流變得重要，這些就很關鍵。

用 LangGraph 來做：

lead 資格判斷 agent
客戶研究 agent
購買訊號偵測
closed-lost 名單再啟動
通話前準備資料生成
交易風險分析
有證據依據的評分
需人工審核的 outreach 草稿
需要記憶／checkpoint 的多步驟工作流

LangGraph 是混亂的打法變成可重複機器的地方。

第三層：n8n = 觸發器、連接器、自動化黏著層

n8n 是一個工作流自動化平台。

它的強項是快速串接系統：觸發器、SaaS 連接器、API 呼叫、排程、webhook、資料搬移。現在的 n8n 也有原生 AI 功能和 AI agent 節點，但核心強項仍然是工作流自動化。

用 n8n 來做：

cron job
webhook
HubSpot／Salesforce 觸發器
Slack 通知
Google Sheets 更新
Notion 更新
email 草稿分派
API 呼叫
在系統之間傳遞輸出
簡單的 enrichment 步驟
把記錄移進審核佇列

例如：

每個工作日早上 9 點：
抓取新的 HubSpot lead
把每個 lead 送進 LangGraph 評分
把高契合度的 lead 發到 Slack
把分數寫回 HubSpot

n8n 非常擅長這種事。

如果工作流大致上是「發生這件事時，呼叫這個 API、發這個通知、更新這筆記錄」，n8n 大概就是對的工具。

為什麼只用 n8n 不一定夠

n8n 可以跑 AI 節點，但複雜的 AI 推理在視覺化工作流裡會變得難以維護。

風險是視覺化義大利麵：

分支太多
節點裡塞著巨大的 prompt
狀態不清楚
可測試性弱
變更難以 review
fallback 邏輯難做
版本控制紀律有限

如果 AI 部分很簡單，留在 n8n 就好。

如果 AI 部分成長為產品等級的推理工作流，就把那段邏輯搬進 LangGraph，讓 n8n 去呼叫它。

為什麼只用 LangGraph 不一定夠

LangGraph 可以呼叫工具和 API，但它不一定是串接每個 GTM 系統最快的方法。

如果你的工作流需要：

HubSpot 觸發器
Slack 訊息
Gmail 草稿
Google Sheets 新增列
Notion 頁面
webhook 監聽
簡單排程

n8n 通常會讓你更快到位。

推理歸 LangGraph，黏著歸 n8n。

為什麼只用 Harness 不一定夠

Harness 的強大在於它能像個人類操作者一樣行動。

但這也是它的極限。

Harness + skills 並不等於生產級的工作流系統。它不適合：

數百筆並發記錄
嚴格的重試機制
可靠的 checkpoint
稽核 log
角色權限控管
排程的高量 CRM 更新
有回歸測試的工作流
生產環境監控

用 harness 來設計、檢視、除錯。不要硬把它變成你永久的自動化後端。

最好的架構是三個都用

最乾淨的 GTM 工程技術棧長這樣：

Harness + skills
= 設計、研究、除錯、工作流創建
 
LangGraph
= 推理、狀態、人工核可、eval
 
n8n
= 觸發器、連接器、排程、遞送

來看一個實際例子。

工作流：新 Lead 資格判斷

n8n

新 HubSpot lead 建立時觸發。
抓取公司網域、email、職稱、來源和 CRM metadata。
把 payload 送到 LangGraph endpoint。

LangGraph

豐富化公司資料。
搜尋購買訊號。
判斷 ICP 契合度。
為緊迫度評分。
產出推理過程。
草擬 outreach 切角。
信心不足時暫停，等人工審核。

n8n

把結果發到 Slack。
更新 HubSpot 欄位。
為負責人建立任務。
把核可的草稿送進 Gmail 或 sequencing 工具。

Harness

檢視壞的輸出。
改進 prompt 和評分準則。
Review log 和範例。
更新 playbook。
建立工作流的下一版。

這是健康的分工。

工作流：GTM 內容引擎

一個週期性的內容引擎也遵循同樣的分工。

n8n

每天早上執行。
抓取 RSS／部落格／新聞／模型發布 feed。
把相關項目送進 LangGraph。

LangGraph

分類每個項目：模型發布、benchmark、競品動作、募資新聞、基礎設施趨勢。
為它與你 ICP 的相關性評分。
建議內容切角。
產出 LinkedIn、X、Threads 的結構化草稿。

Harness

Review 整體策略。
更新內容 skill。
打磨內容支柱格式。
把強的貼文擴寫成長文。
除錯為什麼某些輸出讀起來很空泛。

Harness 是內容總編輯，LangGraph 是內容推理工作流，n8n 是排程的管線。

決策表

情境	最佳工具
「我還不知道 GTM 打法是什麼」	Harness
「研究這些公司並提出切角」	Harness
「把這個混亂的流程整理成規格」	Harness
「每個新 lead 都需要 enrichment」	n8n + LangGraph
「在 HubSpot、Slack、Gmail、Sheets 之間搬資料」	n8n
「用證據和推理判斷 ICP 契合度」	LangGraph
「更新 CRM 前先暫停等核可」	LangGraph 或 n8n + LangGraph
「跑每日競品／新聞監控」	n8n 觸發器 + harness 或 LangGraph
「產出可重複的客戶研究報告」	LangGraph
「除錯工作流為什麼產出爛結果」	Harness
「跑高量的生產管線」	n8n + LangGraph

失敗模式

每個工具的失敗方式都不同。

Harness 的失敗模式

Harness 變成一個無所不知的手動操作者，但什麼都沒有產品化。

症狀：

一堆很棒的一次性工作
沒有可重複的系統
prompt 只存在於聊天記錄裡
輸出品質忽好忽壞
難以擴展到創辦人／操作者以外

解法：把可重複的步驟提煉成 schema、prompt、eval 和 LangGraph 節點。

LangGraph 的失敗模式

GTM 打法還沒驗證，LangGraph 就先過度工程化。

症狀：

太早寫太多程式碼
工作流不斷改動
脆弱的假設
很難對 GTM 使用者解釋
agent 很可靠地解決錯的問題

解法：先在 harness 裡打出打法原型，只把重複出現的行為產品化。

n8n 的失敗模式

n8n 變成巨大的視覺化迷宮，節點裡塞了太多推理。

症狀：

工作流節點裡嵌著巨大的 prompt
變更難以 review
狀態不清楚
分支太多
測試困難
輸出品質難以除錯

解法：把推理搬進 LangGraph，讓 n8n 專注在觸發器、連接器和遞送。

實用法則

工作還很模糊，用 harness。
工作是推理密集且可重複的，用 LangGraph。
工作是串接工具，用 n8n。

這條法則能避開大多數糟糕的架構決策。

FAQ

做 GTM 工程一定要三個工具都用嗎？ 不用——從符合你當下問題的那一層開始。多數團隊從 harness 起步（手動探索一個打法），等工作流需要排程或串接系統時加上 n8n，只有當 AI 推理步驟本身需要狀態、重試和人工核可時，才引入 LangGraph。

n8n 可以取代 LangGraph 做 AI agent 嗎？ 簡單的 AI 步驟——一個 prompt、一個輸出——可以。一旦工作流需要多步驟推理、跨步驟記憶或條件式重試，n8n 的視覺化節點就會變得難以維護，LangGraph 的顯式 graph 狀態是更好的選擇。

Claude Code 和生產級 AI agent 框架的差別是什麼？ Claude Code 這類 harness，是人和 AI 一起迭代、設計和除錯工作流的地方。LangGraph 這類生產框架，是工作流驗證完成後無人值守運行的地方，具備 checkpoint、重試和可觀測性。

Clay 在這個技術棧裡的位置是什麼？ Clay 比較接近 LangGraph + n8n 這兩層的打包版本——GTM 專用的編排和 agent 原語（Claygent、Clay Functions），加上內建連接器。自建技術棧的團隊，本質上是在組裝一個 Clay 開箱即用能力的客製版；參考架構可看 Clay 自己怎麼做 GTM 工程。

這對 GTM 工程意味著什麼

未來的 GTM 工程團隊不會只挑一個工具。

它會同時擁有：

用於探索和除錯的操作者 harness
用於生產 AI 工作流的推理框架
用於工具整合的自動化平台

這就是技術棧。

Harness 是 GTM 工程師思考的地方。

LangGraph 是他們驗證過的推理工作流運行的地方。

n8n 是這些工作流和公司其他部分連接的方式。

錯誤的做法，是要求一層同時變成三層。

資料來源

LangGraph 文件：durable execution、memory、human-in-the-loop、部署：github.com/langchain-ai/langgraph
n8n 文件／repo：工作流自動化、整合、原生 AI 功能：github.com/n8n-io/n8n
Clay：How We Built Clay's GTM Engineering Function
Clay：The Four Layers of Winning GTM Infrastructure