你肯定見過這樣的場景一個剛接觸 Agent 開發(fā)的工程師興奮地調通了一個大模型的 API然后開始瘋狂地往提示詞里塞各種指令試圖讓它“理解”復雜的任務。結果呢任務稍微一長模型就開始“失憶”邏輯稍微一繞輸出就變得不可預測。最后項目變成了一個由無數if-else和字符串拼接組成的“屎山”維護成本高得嚇人。問題出在哪很多人把 Agent 開發(fā)等同于“調 API 寫提示詞”這就像試圖用一把瑞士軍刀去蓋一棟大樓。工具本身沒錯但用錯了方法。真正的 Agent 開發(fā)核心不是“讓模型變得更聰明”而是如何把復雜、不確定的任務拆解成一套穩(wěn)定、可觀測、可迭代的執(zhí)行流程。今天我們不談那些玄乎的概念就從三個最具體、也最能代表不同開發(fā)階段的“形態(tài)”入手LangGraph、MCP和Workflow。它們分別對應著 Agent 開發(fā)的三個核心命題狀態(tài)管理、能力擴展和流程編排。更重要的是我們會深入一個常被忽略但至關重要的設計模式漸進式披露 Skills以及與之配套的Harness 架構。理解了這些你才能從“調 API 的腳本小子”進化成能設計健壯 Agent 系統(tǒng)的工程師。1. 別再“一把梭”認清 LangGraph、MCP、Workflow 的三種角色很多人一上來就糾結“選哪個框架”這其實是個偽命題。LangGraph、MCP 和 Workflow 不是三選一的單選題而是解決 Agent 系統(tǒng)不同層面問題的三種“形態(tài)”或“組件”。用錯了地方事倍功半。1.1 LangGraph為 Agent 裝上“狀態(tài)大腦”和“記憶回路”LangGraph 的核心價值是解決了 Agent 開發(fā)中最頭疼的狀態(tài)管理和循環(huán)控制問題。傳統(tǒng)痛點你用 LangChain 或其他庫寫個 Agent每次調用都是獨立的。你想讓 Agent 記住上一步的結果或者根據中間結果決定下一步做什么比如“如果搜索結果不理想就換一個關鍵詞再搜”就需要自己寫一堆代碼來維護狀態(tài)、判斷分支。代碼很快變得混亂不堪。LangGraph 的解法它引入了StateGraph的概念。你可以把整個 Agent 任務定義為一個有向圖。圖中的節(jié)點Node是一個個具體的操作比如“調用搜索工具”、“分析結果”、“生成報告”邊Edge定義了節(jié)點之間的流轉條件。最關鍵的是它維護了一個全局的State對象在各個節(jié)點間傳遞和更新。這帶來了什么改變可視化與可調試你的任務邏輯變成了一張圖哪里卡住了、循環(huán)了幾次一目了然。這對于復雜流程的調試是革命性的。內置循環(huán)與中斷實現“思考-行動-觀察”的 ReAct 循環(huán)或者滿足某個條件才退出的循環(huán)變得非常簡單。你不再需要手動寫while循環(huán)和狀態(tài)標志。清晰的關注點分離你只需要關心每個節(jié)點“做什么”以及節(jié)點之間“在什么條件下流轉”。狀態(tài)管理的臟活累活LangGraph 幫你干了。簡單來說LangGraph 是 Agent 的“神經系統(tǒng)”和“短期記憶”。它負責協調各個功能模塊按照既定邏輯有序工作并記住工作過程中的上下文。它不關心“搜索”這個功能具體是怎么實現的那是 MCP 或 Skills 的事它只關心“在某個狀態(tài)點需要觸發(fā)搜索功能”。1.2 MCP打破“能力孤島”實現工具的動態(tài)集成如果說 LangGraph 是神經系統(tǒng)那么 MCP 就是讓神經系統(tǒng)能控制手、腳、眼睛的“標準接口協議”。MCP 全稱是Model Context Protocol。它的核心思想是標準化。在沒有 MCP 之前每個 AI 應用如 Claude Desktop、Cursor想要接入外部工具如數據庫、GitHub、Jira都需要和工具提供商進行一對一的深度集成開發(fā)成本極高且用戶無法靈活組合。MCP 做了什么它定義了一套簡單的、基于 JSON-RPC 的通信協議。任何工具只要實現一個 MCP Server對外暴露自己的“能力”比如查詢數據庫、創(chuàng)建日歷事件任何兼容 MCP 的 AI 應用MCP Client就可以自動發(fā)現并使用這些能力。對開發(fā)者的意義你寫的工具Skill只需要適配 MCP 協議就能被所有支持 MCP 的 Agent 平臺或應用使用。反過來你在構建自己的 Agent 時也可以像插拔 USB 設備一樣動態(tài)地接入或移除由 MCP Server 提供的各種 Skills而無需修改核心 Agent 代碼。MCP 是 Agent 的“外設標準”和“能力總線”。它解決了工具生態(tài)的碎片化問題讓 Agent 的能力可以像樂高一樣自由組合、即插即用。在 LangGraph 的圖中一個調用 MCP 工具的節(jié)點其背后的具體實現可能是本地的一個 Python 腳本也可能是遠程的一個專業(yè)服務。1.3 Workflow從單次任務到可復用、可監(jiān)控的業(yè)務流程當你用 LangGraph 設計好了一個任務流程圖并通過 MCP 集成了各種工具后這個“智能流程”如何變成一個團隊可協作、業(yè)務可依賴的“服務”這就是 Workflow 要解決的問題。這里的 Workflow 不是指某個具體叫workflow的庫而是一種工程化形態(tài)。它關注的是編排與調度如何定時、按需或由事件觸發(fā)這個 Agent 流程監(jiān)控與可觀測性每個步驟的執(zhí)行狀態(tài)、耗時、輸入輸出是什么哪里失敗了版本管理與回滾我的 Agent 流程迭代了如何平滑升級出問題了如何快速回退權限與審計誰可以觸發(fā)這個流程執(zhí)行記錄是否可追溯你可以使用像Airflow、Prefect、Dagster這樣的通用工作流編排引擎也可以使用為 AI 優(yōu)化的如LangGraph Studio云服務或Solon Flow等框架來將你的 LangGraph 圖“托管”起來。Workflow 是 Agent 的“生產車間”和“控制塔”。它將一個實驗性的、在筆記本里運行的智能腳本變成了一個高可用、可運維的企業(yè)級服務。形態(tài)核心解決什么問題類比在 Agent 系統(tǒng)中的地位LangGraph狀態(tài)管理與流程控制神經系統(tǒng)與短期記憶編排層定義“怎么干”的邏輯和順序MCP工具能力的標準化與動態(tài)集成外設接口標準USB能力層提供“用什么干”的標準化工具Workflow流程的工程化、運維與調度生產車間與控制塔運維層保障“穩(wěn)定干”和“持續(xù)干”理解了這三者的分工你就知道在 Agent 開發(fā)的不同階段應該聚焦什么。接下來我們深入到最體現設計水平的細節(jié)如何優(yōu)雅地管理和使用那些“工具”Skills。2. 技能Skills管理的核心難題為什么不能一次性全給 Agent有了 MCP我們可以輕松集成幾十上百個 Skills。一個自然的想法是“我把所有 Skills 的描述都塞進系統(tǒng)提示詞System Prompt里讓 Agent 自己選不就行了” 這是新手最容易掉入的“萬能提示詞”陷阱。這么做的災難性后果上下文爆炸每個 Skill 都有名稱、描述、參數說明。幾十個 Skill 的描述文本會急劇膨脹嚴重擠占本應用于任務分析和思考的上下文窗口。決策癱瘓面對一長串功能相似的技能列表比如5個不同的“搜索”技能Agent 會陷入困惑做出隨機或錯誤的選擇。提示詞工程地獄你需要精心設計提示詞來區(qū)分這些技能維護成本極高。安全與成本不必要的技能暴露可能帶來誤操作風險如刪除數據且每次調用都攜帶巨大上下文浪費 tokens。正確的思路是漸進式披露Progressive Disclosure。即不要一開始就把所有技能都暴露給 Agent而是根據任務的當前上下文和執(zhí)行階段動態(tài)地、按需地提供最相關的少數幾個技能。3. 漸進式披露 Skills像導航一樣只顯示當前需要的選項漸進式披露不是一個新概念但在 Agent 設計中至關重要。它的實現依賴于一個核心組件Skill Router或稱為 Tool Router/Selector。3.1 Skill Router 的工作原理技能注冊與分類所有 Skills 在系統(tǒng)啟動時向一個中央注冊表注冊并攜帶豐富的元數據名稱、描述、功能分類、適用場景、輸入輸出格式、權限等級等。上下文感知當 Agent 執(zhí)行到某個節(jié)點需要決定下一步行動時Skill Router 會介入。它接收當前的State任務狀態(tài)、歷史記錄、用戶目標等。路由決策Router 根據預定義的策略可以是規(guī)則引擎、向量檢索相似度甚至是一個小型的決策模型從所有已注冊的技能中篩選出與當前上下文最相關的Top N例如3-5個技能。動態(tài)提示只將這 N 個技能的描述注入到本次 Agent 調用的提示詞中。Agent 在這個精簡、精準的列表中選擇和執(zhí)行。# 概念性偽代碼展示 Skill Router 在 LangGraph 節(jié)點中的角色 def planning_node(state): 規(guī)劃節(jié)點決定下一步做什么 # 1. 獲取當前完整狀態(tài) current_context state[messages] state[intermediate_results] # 2. 調用 Skill Router獲取當前最相關的技能列表 relevant_skills skill_router.route(current_context, top_k3) # 3. 構建只包含相關技能的提示詞 prompt build_prompt_with_skills(relevant_skills, current_context) # 4. 調用 LLM讓它從這3個技能中選擇或提出新想法 llm_response call_llm(prompt) # 5. 更新狀態(tài)決定下一個節(jié)點 state[next_action] parse_llm_response(llm_response) return state # 后續(xù)的 execution_node 只會收到 state[“next_action”] 指定的具體技能去執(zhí)行。3.2 這樣做的好處上下文高效每次決策都在清晰的選項中進行極大節(jié)省 tokens提升推理質量。決策精準Agent 不再需要從海量工具中“大海撈針”。易于維護新增一個 Skill只需要注冊即可無需修改核心提示詞。安全可控高權限技能如delete_database可以設置路由規(guī)則僅在特定任務狀態(tài)下才被披露。漸進式披露的本質是將“工具選擇”這個復雜問題從 LLM 的提示詞工程轉移到了更可控、更可編程的 Skill Router 邏輯中。這是 Agent 系統(tǒng)設計從“藝術”走向“工程”的關鍵一步。4. Harness 架構駕馭復雜 Agent 的“韁繩與鞍具”當我們把 LangGraph流程、MCP Skills能力、Skill Router調度組合在一起時系統(tǒng)復雜度開始上升。如何讓這些組件優(yōu)雅地協作而不是變成一團亂麻這就需要Harness 架構。Harness原意是“馬具”引申為“駕馭、控制”的框架。在 Agent 開發(fā)中Harness 指的是一套封裝了核心執(zhí)行邏輯、狀態(tài)管理、工具調用、路由決策和異常處理的運行時框架。它不是某個具體庫而是一種設計模式。一個典型的 Harness 架構包含以下層次|-----------------------------| | Workflow 層 | -- 調度、觸發(fā)、監(jiān)控 (e.g., Airflow, 自定義服務) |-----------------------------| | Harness 核心層 | | ------------------------- | | | LangGraph (StateGraph) | | -- 流程與狀態(tài)中樞 | ------------------------- | | | Skill Router | | -- 動態(tài)技能路由 | | Memory Manager | | -- 長/短期記憶管理 | | Guardrails | | -- 安全與合規(guī)檢查 | ------------------------- | |-----------------------------| | MCP 適配層 | -- 與各種 MCP Server 通信 |-----------------------------| | 外部工具/服務 | -- 數據庫、API、自定義函數等 |-----------------------------|4.1 Harness 的核心職責生命周期管理初始化 Agent注入配置啟動任務優(yōu)雅停止。狀態(tài)托管作為 LangGraph State 的持有者和持久化管理者如存入數據庫。技能路由執(zhí)行集成 Skill Router在適當的節(jié)點調用它并將路由結果轉化為對具體 MCP Skill 的調用。統(tǒng)一異常處理捕獲 Skill 執(zhí)行失敗、LLM 響應異常、網絡超時等錯誤并決定重試、降級或失敗處理策略?？捎^測性埋點自動記錄每個節(jié)點的輸入輸出、耗時、技能調用詳情方便日志追蹤和性能分析。提供統(tǒng)一接口對外暴露一個干凈的 API如harness.run(task_input)隱藏內部所有復雜細節(jié)。4.2 為什么需要 Harness直接寫 LangGraph 不行嗎可以但會很痛苦。想象一下你的 LangGraph 每個節(jié)點里都需要寫重復的代碼調用 Router、處理異常、記錄日志、更新特定格式的狀態(tài)。Harness 將這些橫切關注點Cross-cutting Concerns抽象出來讓你專注于業(yè)務邏輯圖的設計。Harness 是你與底層復雜組件LangGraph, MCP之間的“適配器”和“緩沖層”。它讓 Agent 的核心邏輯保持簡潔同時具備了生產環(huán)境所需的健壯性。5. 實戰(zhàn)推演從零設計一個支持漸進式披露的新聞分析 Agent讓我們把以上所有概念串起來設計一個“新聞分析Agent”。它的目標是給定一個主題自動搜索最新信息總結觀點并評估其可信度。5.1 第一步定義 Skills 并實現 MCP Server我們注冊幾個技能web_search(query: str): 通用網頁搜索。academic_search(query: str): 學術數據庫搜索。summarize_text(text: str): 文本總結。sentiment_analysis(text: str): 情感分析。fact_check(claim: str, source: str): 事實核查高權限需謹慎使用。每個技能都實現為一個 MCP Server提供標準的list_tools和call_tool接口。5.2 第二步設計 LangGraph StateGraph定義狀態(tài)Stateclass AgentState(TypedDict): topic: str search_results: List[Dict] summary: str credibility_score: float messages: List[BaseMessage] # 對話歷史 next_step: str # 由 Router 和 LLM 決定設計圖節(jié)點plan_search: 規(guī)劃搜索策略需要 Skill Router。execute_search: 執(zhí)行搜索調用web_search或academic_search。analyze_results: 分析結果決定是繼續(xù)搜索還是進入總結。generate_summary: 生成總結調用summarize_text。assess_credibility: 評估可信度可能調用sentiment_analysis和fact_check。5.3 第三步實現 Skill RouterRouter 的策略可以很簡單在plan_search節(jié)點只披露web_search和academic_search。在analyze_results節(jié)點如果結果包含爭議性陳述則披露fact_check否則披露sentiment_analysis和summarize_text。fact_check技能設置高權限閾值除非明確需要否則不披露。5.4 第四步構建 Harness創(chuàng)建一個NewsAnalysisHarness類在__init__中構建上述 LangGraph并傳入配置好的 Skill Router。run方法接收主題初始化 State運行 Graph并返回最終結果。在 Harness 內部每個節(jié)點調用前后自動添加日志記錄。對fact_check的調用添加額外的用戶確認或審核流程Guardrails。5.5 第五步嵌入 Workflow最后將這個NewsAnalysisHarness包裝成一個可執(zhí)行單元提交到 Airflow 或 Prefect。配置為每天定時運行或由消息隊列觸發(fā)。Workflow 系統(tǒng)負責監(jiān)控每次運行的成功與否、耗時并存儲最終的分析報告。6. 避坑指南與進階思考在實踐這套架構時有幾個關鍵點必須注意Skill Router 的質量決定上限如果 Router 總是選錯技能整個 Agent 就會跑偏。初期可以用基于關鍵詞和規(guī)則的 Router后期可以考慮用一個小型微調模型或 embedding 相似度來提升路由精度。狀態(tài)設計要精簡LangGraph 的 State 應該只包含必要信息。避免把整個對話歷史或大量中間數據全塞進去這會影響性能和圖的可讀性?？紤]將大數據單獨存儲State 中只保留引用 ID。MCP Server 的穩(wěn)定性Skill 作為獨立進程或服務必須有良好的錯誤處理和重試機制。Harness 層需要對 MCP 調用超時、無響應等情況有降級策略。測試策略不要只測試端到端。要分層測試單獨測試每個 Skill測試 Skill Router 的決策測試 LangGraph 各個節(jié)點的狀態(tài)轉換最后進行集成測試。從簡單開始不要一開始就追求完美的漸進式披露和復雜的 Harness。先用 LangGraph 把核心流程跑通然后逐步引入 MCP 標準化工具再根據需要添加 Router 和 Harness 的增強功能。真正的 Agent 開發(fā)其復雜度不在于調用哪個大模型的 API而在于如何像設計一個分布式系統(tǒng)一樣設計好組件的邊界、通信協議、狀態(tài)流和異常處理。LangGraph、MCP、Workflow 提供了優(yōu)秀的底層積木而漸進式披露和 Harness 架構則是將這些積木搭建成穩(wěn)固大廈的藍圖和粘合劑。下一次當你啟動一個新的 Agent 項目時不妨先問自己三個問題1我的任務狀態(tài)圖是什么LangGraph 2我需要哪些標準化工具MCP 3我如何讓它成為一個可靠的服務Workflow Harness。想清楚這些代碼寫起來才會有的放矢系統(tǒng)才會真正健壯、可維護。