近兩年做智能體Agent項目的人越來越多但大多數(shù)團隊都卡在同一個地方模型能聊天但干不了實事。要讓大模型真正“上手干活”繞不開會話管理、工具調(diào)用、外部協(xié)議接入、記憶系統(tǒng)這四根柱子。我最近在做的Hermes Agent項目正好把這四塊能力完整趟了一遍這里把關(guān)鍵設計和踩過的坑整理出來給同樣在做智能體框架的朋友一份參考。Hermes Agent是一個面向通用任務執(zhí)行的智能體運行時框架核心定位是“讓模型不僅能說還能做”。它通過結(jié)構(gòu)化的會話狀態(tài)管理、動態(tài)工具注冊與執(zhí)行、MCP開放協(xié)議接入、分層記憶存儲把大模型從單純的文本生成器變成能感知上下文、調(diào)用外部能力、跨會話保持狀態(tài)的執(zhí)行體。這套設計適合正在搭建智能體產(chǎn)品的開發(fā)者、研究多智能體協(xié)作的團隊以及準備在生產(chǎn)環(huán)境中落地Agent應用的工程人員。下面按能力拆開細說。1. 會話能力拆解多輪對話狀態(tài)管理的設計思路1.1 會話不只是消息列表而是一個“工作臺”很多初版Agent實現(xiàn)里會話就是往消息數(shù)組里不斷append全量拼進Prompt。這種做法在測試Demo時看不出問題一旦進入真實業(yè)務場景就會暴露兩個致命缺陷token消耗失控模型注意力被無關(guān)歷史稀釋。我在Hermes Agent里把會話重新定義為“結(jié)構(gòu)化工作臺”而不是線性消息流。每個會話包含三類數(shù)據(jù)核心消息序列用戶輸入、工具結(jié)果、模型回復、衍生狀態(tài)當前任務目標、待執(zhí)行動作列表、引用上下文、運行指標輪次計數(shù)、Token消耗統(tǒng)計、各工具調(diào)用頻率。這么做的好處是Prompt組裝階段可以根據(jù)當前任務意圖動態(tài)篩選歷史消息。比如用戶在執(zhí)行一個多步驟的數(shù)據(jù)處理任務時前三輪關(guān)于賬號配置的閑聊就不應該繼續(xù)占據(jù)窗口。我在實踐中的做法是給每輪會話打上意圖標簽構(gòu)建階段只挑選與當前意圖標簽匹配或時間衰減權(quán)重高的歷史消息。1.2 對話中的上下文窗口管理策略上下文管理直接決定Agent的穩(wěn)定性和成本。我試過幾種窗口策略從最粗暴的“固定截斷最近N條”到“按Token預算動態(tài)裁剪”最后落地的是組合策略分層保留 摘要壓縮。核心層最近2輪完整消息保留所有細節(jié)模型推理主要依賴這部分工作層當前任務相關(guān)的歷史消息按相關(guān)度排序保留單條消息會做截斷歸檔層更早的對話內(nèi)容交給記憶模塊處理會話層僅保留摘要實現(xiàn)上有一個細節(jié)容易忽略截斷操作會在Tools調(diào)用結(jié)果的返回路徑上產(chǎn)生臟數(shù)據(jù)。工具返回的JSON片段如果不做結(jié)構(gòu)歸一化直接塞進歷史下一次模型調(diào)用工具時參數(shù)里可能出現(xiàn)殘留字段。我的處理是在會話存儲層加一個標準化器工具結(jié)果統(tǒng)一轉(zhuǎn)為JSON Schema定義的結(jié)構(gòu)無法解析的原始輸出降級為純文本摘要。1.3 會話恢復與Branch處理另一個會話層面的硬骨頭是恢復和分支。用戶在調(diào)試Agent時會反復執(zhí)行同一個任務而上一輪的中間狀態(tài)可能已經(jīng)失效。Hermes Agent在會話記錄里增加了branch標記每次工具調(diào)用或用戶消息變更時生成新的分支節(jié)點回滾時只需切換branch指針不需要重建整個上下文。// 會話分支切換的簡化實現(xiàn)思路 class SessionBranchManager { constructor(sessionId) { this.branches loadBranches(sessionId); this.currentBranch this.branches[this.branches.length - 1]; } rollbackTo(branchId) { const target this.branches.find(b b.id branchId); if (!target) throw new Error(Branch ${branchId} not found); this.currentBranch target; rebuildPromptContext(target); } forkFrom(branchId) { const base this.branches.find(b b.id branchId); const newBranch createChildBranch(base); this.branches.push(newBranch); this.currentBranch newBranch; return newBranch.id; } }這個設計在支持“重新執(zhí)行上次失敗步驟”的場景中特別實用用戶可以先嘗試方案A失敗后回滾再走方案B整個過程模型不會因為歷史沖突產(chǎn)生幻覺。2. 工具調(diào)用機制Function Calling與執(zhí)行沙箱2.1 工具定義要像接口文檔一樣嚴謹工具調(diào)用是Agent落地中最需要較真的環(huán)節(jié)。模型對工具的理解完全依賴你提供的定義文本。我剛開始寫工具描述時比較隨意用自然語言習慣描述功能結(jié)果模型頻繁選錯工具。后來總結(jié)出工具定義的幾個關(guān)鍵字段字段作用常見錯誤name工具唯一標識需符合小駝峰命名命名風格不一致誤導模型推斷description說明工具功能的完整描述過于簡略或含糊如“處理數(shù)據(jù)”parametersJSON Schema定義參數(shù)結(jié)構(gòu)缺少必填項約束或類型定義模糊restrictions工具使用的邊界條件未說明錯誤輸入時的兜底邏輯Description字段的寫法直接影響模型選工具的準確率。經(jīng)測試一個好的描述應該包含三個維度功能范圍、典型使用場景、與其他工具的邊界。例如“get_user_orders”的描述不能只寫“獲取用戶訂單”而要寫“根據(jù)用戶ID查詢其在當前平臺的全部訂單訂單狀態(tài)包含pending、paid、shipped、completed。此工具僅用于查詢訂單不處理退款相關(guān)操作”。2.2 工具執(zhí)行的隔離與權(quán)限邊界模型生成的工具調(diào)用參數(shù)本質(zhì)上不可完全信任。一個正規(guī)的Agent框架必須在執(zhí)行層做隔離。Hermes Agent的工具執(zhí)行統(tǒng)一走子進程或運行時沙箱不在主進程內(nèi)直接執(zhí)行模型傳來的代碼或命令。我在框架中抽象了一個執(zhí)行器接口支持三種執(zhí)行后端的切換本地子進程適合開發(fā)調(diào)試、容器運行時適合多租戶隔離、遠程函數(shù)計算適合生產(chǎn)擴展。切換的關(guān)鍵參數(shù)是資源限制和超時控制。檢測模型調(diào)用工具時必須能優(yōu)雅中斷超過策略閾值的執(zhí)行。超時閾值我一般設置為普通工具10秒、重型任務30秒不同的工具類型可以在注冊時單獨覆蓋。另外還需要注意工具執(zhí)行的冪等性。LLM在生成失敗重試時很可能會把同一個寫操作請求發(fā)出兩次?？蚣茉谔幚砉ぞ哒{(diào)用時需要記錄request_id同一個request_id重復到達時直接返回上一次的執(zhí)行結(jié)果而不是再次執(zhí)行副作用操作。這個點在對接支付回調(diào)、文件寫入等場景中極其重要。2.3 工具結(jié)果反饋的結(jié)構(gòu)化壓縮工具執(zhí)行完成后返回的結(jié)果是整個鏈路中最容易失控的環(huán)節(jié)。一個查詢工具可能返回數(shù)百行JSON直接全量塞進上下文Token瞬間爆炸而且模型也抓不住重點。我采用的方法是“三級結(jié)果處理管線”第一級原始結(jié)果按Schema校驗非法結(jié)構(gòu)過濾第二級超長字段截斷數(shù)組超過20條時抽樣并標注總數(shù)第三級根據(jù)當前任務目標生成摘要字段摘要由模型在空閑輪次預生成還是由規(guī)則模板即時生成取決于結(jié)果復雜度規(guī)則模板適合結(jié)構(gòu)化強、字段固定的工具結(jié)果。例如數(shù)據(jù)庫查詢結(jié)果表結(jié)構(gòu)固定可以直接用模板抽取列名和行數(shù)。而網(wǎng)頁抓取這種非結(jié)構(gòu)化結(jié)果需要額外調(diào)一次模型生成摘要雖然增加一次推理開銷但后續(xù)對話質(zhì)量的提升非常明顯。3. MCP集成方法擴展能力邊界的關(guān)鍵協(xié)議3.1 MCP在Agent框架中的定位MCPModel Context Protocol可以理解為智能體世界的USB-C接口。過去每個Agent要接外部數(shù)據(jù)源都要寫一套自定義對接邏輯數(shù)據(jù)源一變代碼就得跟著改。MCP的初衷是把“工具提供方”和“工具消費方”解耦統(tǒng)一成一套標準協(xié)議。在實際架構(gòu)中MCP解決的是“Agent能感知和操作什么”的問題。HerMes Agent通過MCP客戶端連接文本編輯器、數(shù)據(jù)庫、瀏覽器自動化工具、企業(yè)IM等外部能力。每次連接對應一個MCP Server實例Server暴露的工具以統(tǒng)一格式向Agent注冊。Agent側(cè)只需要維護一份Server注冊表不需要關(guān)心具體服務是Python寫的還是Node.js寫的。3.2 協(xié)議對接的踩坑實錄MCP的對接過程并不是文檔里寫的那么順暢。最典型的坑是初始化握手和Capability協(xié)商。不同語言版本的MCP SDK對工具列表的返回格式存在細節(jié)差異有些版本返回的schema直接兼容有些則需要手動做一層轉(zhuǎn)換。標準化的對接流程我拆成四步啟動外部服務進程通過stdio或SSE建立通道連接發(fā)送initialize請求攜帶協(xié)議版本和客戶端能力聲明等待服務端返回初始化響應記錄服務端支持的工具列表注冊工具回調(diào)將MCP工具翻譯為Agent內(nèi)部統(tǒng)一的工具Schema{ jsonrpc: 2.0, id: 1, method: initialize, params: { protocolVersion: 2024-11-05, capabilities: { tools: { listChanged: true }, resources: { subscribe: true } }, clientInfo: { name: hermes-agent, version: 0.4.2 } } }實操中容易忽略的點是服務端進程的優(yōu)雅退出。Agent退出時如果沒有向MCP Server發(fā)送shutdown通知并等待其清理資源會導致下次啟動時的端口占用和緩存臟數(shù)據(jù)。我給框架的MCP客戶端加了生命周期鉤子在Agent主進程退出前統(tǒng)一執(zhí)行關(guān)閉序列。3.3 連接池與多Server調(diào)度一個Agent同時接多個MCP Server時調(diào)度策略就變得很關(guān)鍵。大多數(shù)MCP Server單進程承載不了高并發(fā)請求所以不能每來一次工具調(diào)用就新建連接。我在Server連接層加了連接池配置每個Server默認維持min2, max10的動態(tài)連接數(shù)。調(diào)度時還有一個優(yōu)先級問題多個Server提供類似能力時模型該選哪一個我給每個Server配了權(quán)重評分由三個維度構(gòu)成響應延遲的滑動平均、工具調(diào)用歷史成功率、服務端聲明的能力匹配度。這個評分會在實際調(diào)用后實時更新模型在參考列表中看到的結(jié)果就是這個動態(tài)評分排序后的版本。# MCP Server調(diào)度權(quán)重計算的偽代碼 def update_server_score(server_id, latency, success): server registry[server_id] server.latency_ema 0.7 * server.latency_ema 0.3 * latency server.success_rate 0.8 * server.success_rate 0.2 * success server.score ( 0.4 * (1.0 / (server.latency_ema 0.1)) 0.6 * server.success_rate )這套調(diào)度機制上線后多Server接入時的工具調(diào)用成功率從85%提升到96%左右。核心收益是避免了“A服務超時了還反復試A”的笨重邏輯。4. 記憶系統(tǒng)設計短期與長期記憶的配合4.1 記憶分成三層工作記憶、情景記憶、語義記憶記憶是Agent從“聊完就忘”進化為“越用越懂你”的關(guān)鍵也是最難做對的部分。記憶系統(tǒng)設計參照認知科學的分類分成三層。工作記憶對應當前會話內(nèi)的臨時信息類似人的“腦內(nèi)緩存”比如用戶剛提的臨時偏好“這次用簡潔風格回復”這一層在會話結(jié)束后清空。情景記憶存儲具體的交互事件如“用戶在2025年1月10日運行了數(shù)據(jù)清洗任務使用了Python腳本”。語義記憶提取的是跨會話的穩(wěn)定知識如“用戶偏好省中型SQL風格”“用戶的操作習慣是先預覽后執(zhí)行”。三層記憶的存儲介質(zhì)完全不同。工作記憶在內(nèi)存中使用TTL淘汰策略。情景記憶寫入向量數(shù)據(jù)庫按時間衰減調(diào)整檢索權(quán)重。語義記憶使用知識圖譜結(jié)構(gòu)存儲實體與關(guān)系支持推理查詢。架構(gòu)上分層的核心原則是不同生命周期和結(jié)構(gòu)的數(shù)據(jù)不能混在一個存儲里否則檢索質(zhì)量和維護成本都會失控。4.2 記憶寫入與提取的觸發(fā)策略不會寫記憶和不會提取記憶都是問題。寫入過頻則上下文和存儲不堪重負寫入過少則Agent喪失長期連續(xù)性。我采用的策略是“關(guān)鍵節(jié)點強制寫入定期掃描提煉”。強制寫入觸發(fā)點包括任務完成、用戶明確表達偏好、工具執(zhí)行失敗并重試成功、跨會話引用需求發(fā)生。定期掃描則是一個后臺任務每30分鐘掃描近期交互日志用摘要模型抽取候選語義記憶經(jīng)過置信度過濾后寫入知識圖譜。// 記憶寫入的觸發(fā)判斷邏輯簡化版 const triggers { TASK_COMPLETED: (ctx) ctx.status success, USER_PREFERENCE: (ctx) ctx.message.includes(喜歡) || ctx.message.includes(不要) || ctx.message.includes(以后), ERROR_RETRY: (ctx) ctx.retryCount 0 ctx.status success }; function shouldWriteMemory(sessionEvent) { return Object.values(triggers).some(trigger trigger(sessionEvent)); }提取記憶時需要注意檢索相關(guān)性和時效性的平衡。純向量相似度檢索容易把久遠的相似事件也翻出來而且提取結(jié)果沒有區(qū)分直接證據(jù)和推測信息。我的做法是混合檢索加權(quán)重排序既有向量庫相似度打分也按時間衰減系數(shù)加權(quán)最后再加一步記憶類型的過濾器與當前任務類型不匹配的記憶直接剔除。4.3 跨會話知識更新的沖突消解記憶系統(tǒng)最隱蔽的坑是知識沖突。用戶可能一開始說“報表喜歡Excel格式”兩個月后說“以后都用PDF”。如果不做沖突消解Agent會陷入自我矛盾。處理方式是給每條語義記憶綁定置信度和時間戳新寫入的知識如果與舊知識沖突不直接覆蓋而是同時保留并標記待確認狀態(tài)下一次交互根據(jù)用戶的實際行為裁定勝負。5. 四種能力的協(xié)同編排一個完整任務的執(zhí)行流5.1 從用戶請求到最終執(zhí)行的全鏈路單獨理解每一種能力還不夠四者協(xié)同才能真正體現(xiàn)Agent的價值。我用一個真實場景串聯(lián)用戶說“幫我把上個月銷售數(shù)據(jù)匯總一下出一份分析報告發(fā)到項目群以后每個月都提醒我”。完整執(zhí)行鏈路如下會話模塊先激活該用戶的工作空間加載用戶畫像摘要判斷這是一個跨會話任務Agent解析意圖后從語義記憶中檢索到“用戶偏好Markdown格式報告”“匯報對象是銷售組”等知識工具調(diào)用環(huán)節(jié)Agent選擇 query_database 工具讀取銷售表調(diào)用 report_generator 工具生成報告初稿在生成分析結(jié)論時Agent調(diào)用MCP協(xié)議接入的網(wǎng)頁搜索服務補充行業(yè)趨勢數(shù)據(jù)工具執(zhí)行結(jié)果經(jīng)過結(jié)構(gòu)化壓縮反饋給模型做二次總結(jié)會話模塊將本輪的完整過程和結(jié)果存檔提煉新的語義記憶“用戶每月需要銷售匯總報告”情景記憶模塊記錄任務執(zhí)行細節(jié)報告生成路徑、數(shù)據(jù)表位置、使用的工具列表5.2 協(xié)同時的沖突處理四能力協(xié)同也帶來了新的沖突場景會話需要控制token預算但記憶系統(tǒng)希望注入更多歷史上下文工具調(diào)用追求快速執(zhí)行但MCP連接池需要對slow請求進行超時保護。這些沖突沒有銀彈解決方案只能做優(yōu)先級分級。我在Hermes Agent里定義了“執(zhí)行優(yōu)先級”概念從高到低依次是用戶明確指令 工具執(zhí)行的正確性 會話的連貫性 記憶的完整性。任何設計決策與高優(yōu)先級沖突時低優(yōu)先級自動讓位。比如記憶寫入失敗時不阻塞主流程降級為離線重試隊列。5.3 失敗恢復機制協(xié)同鏈路中任何一個環(huán)節(jié)失敗都會產(chǎn)生連鎖反應。我重點處理兩個場景。第一個是工具執(zhí)行失敗后如何決定下一步。Hermes Agent的判斷邏輯是先檢查失敗類型。參數(shù)校驗失敗則重新生成參數(shù)服務端崩潰則切換備用的MCP Server數(shù)據(jù)缺失則向用戶確認輸入。判斷邏輯必須預設重試次數(shù)上限避免模型陷入死循環(huán)。第二個是會話上下文損壞后的恢復。會話存儲使用雙寫機制一份是結(jié)構(gòu)化JSON一份是純文本鏡像。JSON解析失敗時用純文本鏡像重建上下文雖然損失部分結(jié)構(gòu)信息但至少能維持對話連續(xù)性。6. 常見問題與調(diào)試心得實錄6.1 模型連續(xù)調(diào)用工具的循環(huán)失控最早遇到的高頻問題是模型會在一次任務中連續(xù)調(diào)用同一個工具超過十次不收斂。通常原因是缺乏中間反饋模型的每次調(diào)用都能拿到數(shù)據(jù)但沒有判斷“這些數(shù)據(jù)是否滿足最終目標”的過程。解決辦法是在每一輪工具執(zhí)行后追加一段“目標達成度評估”由規(guī)則引擎判定當前狀態(tài)與最終目標的距離距離未縮短時強制終止當前策略并提示模型換方案。6.2 上下文注入順序?qū)δＰ洼敵龅挠绊慞rompt的組裝順序確實影響模型行為。經(jīng)驗總結(jié)是最佳順序是系統(tǒng)指令 用戶目標 關(guān)鍵記憶 相關(guān)歷史 工具結(jié)果 當前問題。把工具結(jié)果放在靠近當前問題的位置能顯著提升模型引用數(shù)據(jù)的準確性。大幅偏離這個順序時模型會更容易忽略早期注入的信息。6.3 工具Schema頻繁變更的兼容策略工具定義不是一成不變的。數(shù)據(jù)庫加了一個字段、接口多了一個參數(shù)工具Schema就需要更新。更新不及時會導致模型按舊參數(shù)格式調(diào)用被服務端拒絕。我維護了一組Rule集每次Schema調(diào)整時會根據(jù)變更類型自動判斷是否觸發(fā)緩存過期、是否需要重寫歷史會話中的相關(guān)消息。復雜字段重構(gòu)時還會額外生成遷移說明注入系統(tǒng)提示讓模型知道新舊接口的異同。6.4 記憶污染與信息過時記憶系統(tǒng)運行久了必然積累過時信息。這是不可回避的問題。我做了三層防御寫入前增加置信度門檻寫入后綁定有效期情景記憶默認30天、語義記憶默認180天定期巡檢時對低頻訪問的知識做降權(quán)或歸檔。就算這樣也無法完全避免污染因此所有記憶內(nèi)容在注入Prompt時都會攜帶置信度和時間標簽讓模型對不確定性信息保持警覺。7. Hermes Agent的適用范圍與邊界7.1 適合什么場景這套架構(gòu)適合需求清晰、執(zhí)行路徑可驗證的業(yè)務場景。例如數(shù)據(jù)分析Agent、客服工單處理Agent、跨系統(tǒng)數(shù)據(jù)同步Agent。這類場景的共同特征是外部系統(tǒng)有明確接口工具調(diào)用能產(chǎn)生確定性結(jié)果用戶有明確的目標預期并且流程中可以設定成功率、時延等量化評估指標。7.2 不建議硬套的場景不要指望Agent框架解決所有問題。純開放式的創(chuàng)意生成場景不需要復雜的工具調(diào)用過重的會話狀態(tài)管理反而拖慢響應。實時性要求極高、達到毫秒級延遲的場景也不適合多輪推理和工具調(diào)用的耗時在這里是硬傷。此外高風險決策場景如果缺少人工復核環(huán)節(jié)再強的記憶和工具能力都不該直接拍板。7.3 擴展方向多智能體協(xié)作Hermes Agent目前的單Agent能力已經(jīng)相對完整我正在擴展的方向是多智能體協(xié)作。每個Agent實例獨立運行通過共享記憶層和MCP協(xié)議互相感知。當一個Agent發(fā)現(xiàn)自身能力邊界時可以向協(xié)作網(wǎng)絡廣播任務由匹配到的其他Agent接管子任務。這套擴展依賴的核心還是本文說的四種基礎能力只是增加了Agent之間的會話路由和記憶共享協(xié)議后續(xù)有實際進展了我再寫一篇細聊。回到這篇文章的主題我想強調(diào)的是會話、工具、MCP、記憶不是四個獨立模塊而是一個完整執(zhí)行體的一體四面。會話是工作臺工具是手MCP是外部世界的接口記憶是長期經(jīng)驗庫。四者配合得好Agent才能真正從一個聊天窗口進化為一個數(shù)字員工。我做Hermes Agent過程中的一個體會是不要一開始就追求功能數(shù)量先把會話狀態(tài)管理做扎實再鋪工具和記憶迭代節(jié)奏會更穩(wěn)。