大家好，我是玄姐。

如何在分布式、多端協同的復雜場景下，構建高效的 Human In The Loop（人機回路）機制。本文詳細闡述了基于 Model Context Protocol（MCP）協議的一體化解決方案，通過標準化工程設計，在各類 Agent 平臺上實現了靈活、可靠的人機協同，為大模型 Agent 的實用化落地提供了關鍵技術參考。

一、背景與挑戰

1.1 人機回路的核心內涵

Human In The Loop（人機回路）是指人類通過監督、交互參與 Agent 運行過程的協同模式，核心包含三類交互場景：

基礎輸入與中斷：人類向 Agent 下發任務、提供上下文，或暫停、終止 Agent 活動；

疑問澄清：當 Agent 對任務上下文存在歧義時，主動向人類發起問詢以補充信息；

授權確認：Agent 執行關鍵操作（比如：文件修改、數據訪問）前，需獲得人類批準后方可繼續。

典型案例，比如： "AI 搜索助手"：用戶觸發天氣問詢后，Agent 若未獲取具體城市信息，會通過人機回路向用戶確認，待得到答復后再執行后續查詢。

1.2 服務端部署的技術困境

Cline、Cursor 等終端工具的人機回路實現相對簡單，因 Agent 直接運行在用戶本地設備，調用 UI 交互無需復雜架構設計。但在企業級應用中，Agent 多部署于遠端服務端，面臨三大核心挑戰：

分布式協同難題：微服務架構下，并發請求、跨節點通信導致人機交互鏈路斷裂；

狀態持久化缺失：主流 Agent 框架缺乏 LangGraph 式的 HITL 節點能力，流式響應（SSE）場景下難以保存和恢復交互狀態；

多端同步復雜：Web、APP、桌面端等多終端需同步交互狀態，確保人類在任意端的操作都能被 Agent 感知。

盡管 MCP 協議的 stdio Transport 因 "單進程單客" 模式易于實現，但在微服務部署后，即便引入 HTTP + SSE Transport，仍無法解決狀態同步、跨節點恢復等問題，直到 Streamable Transport 出現才略有緩解，但核心痛點尚未根除。

二、基于 MCP 的解決方案

2.1 核心思路：將人類 "確認" 能力封裝為 MCP 工具

MCP 協議的工具調用（tool/call）本質是 "請求 - 響應" 模式，這與人機回路的 "問詢 - 答復" 邏輯天然契合。我們將人類參與抽象為一個專用 MCP 工具（send_inquiry），實現流程如下：

圖片

第一、Agent 通過 tool/call 向 MCP Server 的 inquiry 工具發送問詢請求；

第二、MCP Server 掛起該請求，通過 UI 向人類展示疑問；

第三、人類提交答復后，MCP Server 恢復請求并將答復作為 tool/call 響應返回給 Agent；

第四、Agent 接收答復后繼續執行后續流程。

關鍵技術實現

交互入口設計：在 MCP Server 所在微服務中提供 HTTP 接口，支持所有終端 UI 接入，接口僅需一個 response 參數接收人類答復；

多客關聯機制：通過 ID + 哈希表實現不同 Agent 問詢與人類答復的精準匹配，解決微服務多用戶場景下的混淆問題；

異步通知優化：利用 MCP 的 Notification 機制，在 Agent 調用 send_inquiry 后，通過 Notification 幀實時推送問詢 ID（憑條），避免同步調用導致的阻塞。

示例 MCP Notification 響應幀：

{
"method":"notifications/progress",
"params":{
"meta":{
"question":"明天北京天氣如何？",
"inquiryId":"a4cecc76-2fb3-41bc-97ae-e809059ad68a",
"type":"INQUIRY"
},
"progressToken":1,
"progress":0,
"method":"notifications/progress"
},
"jsonrpc":"2.0"
}

該幀通過 SSE 鏈路轉發給 Agent 調用方（比如：ChatCompletions 接口），終端接收后即可渲染問詢 UI，等待人類響應。

2.2 工具代理：實現全流程操作確認

為滿足 "Agent 每步操作均需人類確認" 的場景，我們采用代理模式設計 MCP Proxy 服務，在原有工具調用前植入確認邏輯：

透傳基礎請求：MCP Proxy 將 tools/list 等查詢類請求直接轉發給后端 MCP Server，不干預正常流程；

圖片

攔截工具調用：當 Agent 發起 tool/call 時，MCP Proxy 先觸發人機確認流程；

圖片

分支執行邏輯：人類答復 "是" 則繼續調用后端工具并返回結果，答復 "否" 則直接返回 "人類拒絕執行" 的文本響應。

該方案無需修改原有 Agent 和工具服務架構，僅通過代理層即可實現全流程確認，具備極強的兼容性和可擴展性。

2.3 YOLO 模式的決策機制

YOLO（You Only Look Once）模式允許 Agent 自動執行需人類確認的操作，無需人工干預，核心解決 "誰來決策" 和 "如何決策" 兩大問題：

決策主體選擇

服務端決策：Agent 通過 Prompt 約束繞過 HITL MCP Server，或直接跳過 MCP Proxy 的確認流程，但靈活性不足；

客戶端決策：瘦客戶端僅支持三種策略：隨機選擇、默認同意（YOLO）、請求外援（調用專用決策 Agent）；

獨立決策 Agent：專門處理人類未答復的場景，接收原 Agent 的上下文和疑問后生成決策，既保證原架構純凈，又支持決策日志審計。

決策 Prompt 設計

通過提示詞規范 Agent 在特殊場景下的行為：

拒絕回答：收到 "拒絕回答" 時，按自身理解繼續流程；

超時未答：判斷現有上下文是否足夠完成任務，不足則再次發起問詢。

2.4 多端協同方案

借鑒 iCloud 多設備登錄授權機制，實現多終端的交互同步：

圖片

主終端（發起任務的終端）通過 SSE 鏈路接收 Agent 問詢幀，其他終端通過服務端通知獲取問詢信息；

所有終端均渲染問詢 UI，人類可在任意終端作答；

任意終端完成答復后，服務端向所有終端發送 "已答復" 通知，關閉其他終端的問詢 UI；

Agent 通過主終端的 SSE 鏈路接收答復，繼續執行流程。

該方案確保人類在 Web、APP、桌面端等任意設備上都能參與交互，且狀態實時同步，提升使用靈活性。

2.5 超時策略配置

為避免 Agent 因等待人類答復而長期阻塞，設計三級超時機制：

端側超時：終端設置計時器，超時未作答則自動發送 "超時未回答" 響應；

人機回路服務超時：長于端側超時，確保終端有足夠時間處理交互；

MCP Client 超時：最長超時時間，大于人機回路服務超時，避免 Agent 提前終止工具調用。

三級超時的合理配置（例如：端側 30 秒、服務端 60 秒、MCP Client 90 秒），既保證用戶體驗，又提升 Agent 魯棒性。

三、人類答復的多樣化實現

3.1 直接回答的兩種模式

多輪單問題模式

Agent 每次僅提出一個疑問，人類答復后再根據情況提出下一個問題，類似人類下屬向領導逐步澄清需求。優點是交互自然、疑問聚焦，缺點是輪次過多易引發用戶厭煩，需平衡問詢次數與信息完整性。

單輪多問題模式

Agent 一次性提出多個疑問，人類集中答復，適合需要批量補充信息的場景。核心解決兩個問題：

結構化傳遞：采用 JSON 等結構化格式便于 UI 渲染，但對 Prompt 工程要求極高，需避免格式錯誤；

非結構化傳遞：使用 Markdown 格式的非結構化文本，人類在富文本編輯器中直接作答，工程實現簡單，且支持 Agent 生成默認答復供人類修改（"作弊" 模式）。

3.2 特殊答復處理

拒絕回答

用戶明確拒絕答復時，終端返回預設文本（比如："我也不是很清楚這里的細節，你可以根據你的想法做發揮"），Agent 通過提示詞調整行為，避免重復問詢。

超時未作答

終端超時未收到用戶操作時，自動發送 "超時未回答" 響應（比如："我這會兒有事情要忙，你可以根據你的想法做發揮"），復用拒絕回答的 Prompt 邏輯。

默認作答

引入輔助 Agent 為原 Agent 的疑問生成默認答復，連同疑問一并展示給人類，人類可直接提交或修改后提交，解決兜底答復的場景局限性問題。

四、提示詞優化策略

4.1 Agent Prompt 設計

通過結構化指令引導 Agent 正確使用人機回路工具：

意圖分析：先判斷用戶需求是否清晰；

意圖澄清：需求模糊時，必須調用 send_inquiry 工具問詢，嚴禁直接回復；

信息檢索：意圖明確后，需外部信息則調用搜索工具；

結果驗證：對搜索結果存疑時進行補充搜索；

綜合回答：整合信息形成最終答案。

關鍵約束指令（clarify_user_intent）：明確要求 Agent 在意圖不明確時，必須通過 send_inquiry 工具問詢，禁止直接生成文本提問。

4.2 工具 Description 優化

MCP 工具的 Description 直接影響 Agent 對工具的理解和使用時機，需詳細說明適用場景、核心功能和操作建議。例如 Sequential-Thinking 工具的 Description 明確列出 14 項操作建議，幫助 Agent 正確判斷使用時機。

對于 send_inquiry 工具，采用動態 Description 策略：

QueryString 參數：通過會話級參數動態調整 Description，無需重啟服務；

客戶端覆蓋：Agent 接收 MCP Server 的 tools/list 響應后，根據需求替換工具 Schema，實現個性化適配。

4.3 擬人化溝通原則

大模型會將自身視為與人類平等的個體，設計提示詞時應避免使用 "工具""LLM""大模型" 等術語，采用擬人化表述，減少 Agent 的理解偏差，提升交互自然度。

五、總結與應用延伸

基于 MCP 協議的人機回路方案，通過將人類交互封裝為標準化工具，解決了服務端部署場景下的分布式協同、狀態持久化、多端同步等核心難題，具備以下優勢：

架構兼容性強：無需重構現有 Agent 框架和微服務架構，通過 MCP 協議快速集成；

交互體驗一致：支持多終端協同，人類可在任意設備參與交互，狀態實時同步；

擴展性良好：可通過代理模式快速適配現有工具，支持 YOLO 等多樣化交互模式。

該方案已在智能導購等業務場景中落地應用。比如：在主動式智能導購助手場景中，Agent 通過人機回路向顧客詢問商品參數（比如：尺寸、顏色、預算），收集齊全后自動檢索商品數據庫并推薦匹配產品，實現全天候自動化導購服務。

未來，我們將進一步優化決策 Agent 的智能度，提升多輪交互的上下文理解能力，探索基于用戶畫像的個性化問詢策略，讓人機回路更高效、更貼合人類使用習慣。

好了，這就是我今天想分享的內容。

本文轉載自??玄姐聊AGI??  作者：玄姐???