實戰(zhàn)：從記憶、編排到可觀測性的系統(tǒng)優(yōu)化)
1. 從“能跑”到“跑通”一次Agent實戰(zhàn)的認知升級最近在折騰一個叫Gliding Horse的Agent項目它基于Agent Harness框架目標是實現(xiàn)一個能自主處理復雜任務的“智能閉環(huán)”系統(tǒng)。說實話剛開始拿到這個項目時感覺挺酷的——框架搭好了基礎功能也都有跑起來也能看到Agent在按部就班地執(zhí)行任務。但用了一段時間尤其是在處理一些需要多步驟、有狀態(tài)依賴的真實場景時問題就暴露出來了任務流程是“跑”起來了但離“跑通”還差得遠。這里的“跑通”不是指程序不報錯而是指整個智能體系統(tǒng)能像我們期望的那樣形成一個穩(wěn)定、可靠、可解釋的閉環(huán)工作流而不是一個脆弱的、經(jīng)常需要人工介入的“半自動”玩具。這次對Gliding Horse的深度優(yōu)化就是圍繞這個核心目標展開的。我們不再滿足于讓Agent“動起來”而是要讓它“聰明地跑起來”。優(yōu)化的焦點集中在了幾個最影響閉環(huán)質(zhì)量的痛點上記憶系統(tǒng)的健壯性、任務編排SA Orchestration的靈活性以及整個執(zhí)行流程的可觀測性。這背后涉及到的不僅僅是改幾行代碼更是對Agent Harness這類框架在實際應用中“水土不服”問題的系統(tǒng)性思考和解決。如果你也在用類似框架構(gòu)建自己的智能體或者對如何讓AI Agent從Demo走向?qū)嵱酶信d趣那么這次踩坑和填坑的經(jīng)歷或許能給你一些直接的啟發(fā)。2. 記憶系統(tǒng)的重構(gòu)從“瞬時記憶”到“工作記憶長期記憶”最初的Gliding Horse版本其記憶系統(tǒng)設計得相對簡單可以稱之為“瞬時記憶”模式。Agent在執(zhí)行每個步驟時能夠獲取到上一步的輸出和當前的環(huán)境狀態(tài)但一旦任務鏈稍長或者需要回溯到很久之前的上下文時Agent就顯得力不從心了。它就像一個只有短期記憶的人記得剛說過的話但忘了十分鐘前討論的目標導致決策偏離初衷。這在處理諸如“分析一份文檔然后根據(jù)分析結(jié)果起草郵件最后檢查郵件是否符合公司規(guī)范”這類連貫任務時問題尤為突出。2.1 原有記憶機制的瓶頸分析原有的記憶機制主要依賴于任務執(zhí)行時的即時上下文傳遞。在Agent Harness的框架下這通常是通過在State對象中攜帶有限的幾步歷史記錄來實現(xiàn)的。這種設計帶來了幾個明顯問題第一是上下文窗口的硬性限制。為了控制計算和存儲成本歷史記錄通常只保留最近的N條。當任務步驟超過N時關鍵的初始指令或中間決策依據(jù)就會被“遺忘”導致后續(xù)步驟失去方向。第二是記憶的“扁平化”。所有歷史記錄無論是核心的用戶指令、關鍵的推理結(jié)果還是普通的工具調(diào)用日志都被混在一起沒有優(yōu)先級和結(jié)構(gòu)。當Agent需要做決策時它不得不從一堆雜亂的信息中費力地尋找相關線索效率低下且容易出錯。第三是缺乏記憶的主動管理。記憶只是被被動地記錄和讀取沒有“記住重點、忘記冗余”的機制。在長對話或多輪任務中無關信息會不斷累積形成噪音干擾Agent的核心判斷。2.2 引入分層記憶架構(gòu)為了解決這些問題我們參考了人類認知中“工作記憶”和“長期記憶”的概念對Gliding Horse的記憶系統(tǒng)進行了分層重構(gòu)。工作記憶Working Memory被設計為Agent當前的“思考白板”。它容量有限但訪問速度極快專門用于存放與當前步驟高度相關的即時信息。例如當前步驟的精確目標。上一步執(zhí)行的關鍵結(jié)果或產(chǎn)出。為解決當前子問題而臨時提取的幾條最關鍵的歷史信息。當前步驟的臨時推理過程和待辦事項。在實現(xiàn)上工作記憶通常通過優(yōu)化Prompt工程和上下文管理來實現(xiàn)。我們會動態(tài)地構(gòu)建一個高度濃縮的上下文只包含執(zhí)行當前動作所必需的最小信息集。這大大降低了模型的計算負擔并提高了響應的相關性和準確性。長期記憶Long-Term Memory則扮演了“知識庫”和“經(jīng)驗檔案”的角色。它用于存儲跨越整個任務會話甚至多個會話的重要信息。主要包括會話記憶Session Memory本次任務的核心目標、用戶的關鍵約束條件如預算、時間、已經(jīng)達成的重要里程碑、以及產(chǎn)生的最終或中間產(chǎn)物如生成的報告、代碼片段。這些信息會被結(jié)構(gòu)化存儲例如使用向量數(shù)據(jù)庫存儲關鍵決策點的Embedding并用元數(shù)據(jù)標注。實體記憶Entity Memory在任務執(zhí)行過程中識別出的重要實體及其屬性關系。例如在處理客戶支持任務時識別出的客戶ID、問題類型、產(chǎn)品型號、已嘗試的解決方案等。這些實體可以跨會話關聯(lián)實現(xiàn)個性化的服務。技能/工具記憶Skill Memory記錄Agent調(diào)用各種工具或API的成功與失敗經(jīng)驗。例如“調(diào)用天氣API時城市名必須用英文”“生成圖表時參數(shù)X和Y不能同時為空”。這類記憶可以幫助Agent在未來遇到類似場景時做出更優(yōu)的選擇或提前規(guī)避已知錯誤。我們?yōu)镚liding Horse集成了向量數(shù)據(jù)庫如Chroma或Weaviate來存儲和檢索長期記憶。關鍵的一步是設計了一套記憶寫入與讀取的觸發(fā)與篩選策略。不是所有信息都值得存入長期記憶。我們定義了規(guī)則只有被標記為“里程碑事件”、“用戶明確強調(diào)的信息”、“任務產(chǎn)出的核心結(jié)果”或“從失敗中總結(jié)的教訓”才會被寫入。讀取時則根據(jù)當前工作記憶中的焦點從長期記憶中召回最相關的幾條記錄動態(tài)注入到工作上下文中。2.3 記憶優(yōu)化的實戰(zhàn)效果與配置示例經(jīng)過重構(gòu)后最直觀的感受是Agent的“連貫性”和“目的性”大大增強。例如在一個“競品分析報告生成”的任務中Agent能夠記住報告的核心框架要求長期記憶并在撰寫每個部分時準確引用之前步驟中爬取到的對應競品數(shù)據(jù)從長期記憶中動態(tài)檢索并加載到工作記憶而不會在寫結(jié)論時忘了開頭設定的分析維度。這里分享一個簡化版的記憶系統(tǒng)配置示例展示了如何結(jié)合LangChain假設的底層庫進行設置# 偽代碼示例展示分層記憶的初始化 from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.schema import Document import json class EnhancedMemorySystem: def __init__(self): # 初始化向量數(shù)據(jù)庫作為長期記憶存儲 self.embedding_function OpenAIEmbeddings() self.vector_store Chroma(embedding_functionself.embedding_function, persist_directory./memory_db) self.session_summary # 會話記憶的文本摘要 self.working_memory_buffer [] # 工作記憶的臨時緩沖區(qū) def commit_to_long_term(self, content, metadata): 將重要信息提交到長期記憶 doc Document(page_contentcontent, metadatametadata) self.vector_store.add_documents([doc]) # 同時更新會話摘要 self._update_session_summary(content) def retrieve_for_context(self, query, k3): 根據(jù)當前查詢從長期記憶中檢索最相關的信息 docs self.vector_store.similarity_search(query, kk) return \n.join([f[記憶{i1}]: {doc.page_content} for i, doc in enumerate(docs)]) def set_working_memory(self, current_goal, last_result, retrieved_memories): 設置當前工作記憶 self.working_memory_buffer [ f當前目標: {current_goal}, f上一步結(jié)果: {last_result[:200]}..., # 截斷避免過長 f相關歷史背景: {retrieved_memories} ] def get_working_context(self): 獲取整合后的工作上下文用于生成Prompt return \n.join(self.working_memory_buffer) # 在Agent執(zhí)行步驟中使用 memory_system EnhancedMemorySystem() # 當完成一個重要步驟時如“確定了報告大綱” memory_system.commit_to_long_term( content已確定競品分析報告大綱1.市場概述 2.功能對比 3.定價策略 4.SWOT分析 5.結(jié)論, metadata{type: milestone, step: outline, task_id: 123} ) # 在執(zhí)行“撰寫功能對比”步驟前 relevant_mem memory_system.retrieve_for_context(競品功能對比維度, k2) memory_system.set_working_memory( current_goal撰寫‘功能對比’章節(jié)需對比產(chǎn)品A、B、C的核心功能點。, last_result已爬取到產(chǎn)品A、B、C的官方功能列表。, retrieved_memoriesrelevant_mem ) # 然后將 memory_system.get_working_context() 注入到LLM的Prompt中注意記憶系統(tǒng)的設計需要在“記住更多”和“避免干擾”之間取得平衡。過度依賴長期記憶可能導致上下文膨脹反而降低模型性能。我們的經(jīng)驗是為記憶的寫入設定較高的閾值并為檢索配置一個“相關性分數(shù)”過濾器只召回分數(shù)高于閾值的最相關記憶。3. SA編排引擎的精細化改造讓任務流“活”起來Gliding Horse最初的任務編排SA Orchestration相對剛性可以理解為一種“預定義流程圖”的模式。任務步驟Step和動作Action之間的流轉(zhuǎn)邏輯大多通過硬編碼的條件判斷if-else或簡單的線性順序來驅(qū)動。這種模式在面對規(guī)劃清晰、路徑單一的任務時沒問題但一旦遇到需要動態(tài)決策、分支選擇或異常處理的情況就顯得非常笨拙。所謂的“智能閉環(huán)”在這里出現(xiàn)了斷點因為流程本身不智能。3.1 從靜態(tài)流程圖到動態(tài)狀態(tài)機我們的優(yōu)化核心是將編排引擎從“靜態(tài)流程圖”升級為“動態(tài)狀態(tài)機”。這不是簡單地換一個技術名詞而是設計理念的轉(zhuǎn)變。在靜態(tài)流程圖模式下流程路徑是預先完全確定的。Step A之后一定是Step B除非遇到特定錯誤跳轉(zhuǎn)到Step Error。而在動態(tài)狀態(tài)機模式下我們定義的是狀態(tài)State和狀態(tài)轉(zhuǎn)移的條件Condition。每個步驟執(zhí)行后會產(chǎn)生一個新的狀態(tài)包含執(zhí)行結(jié)果、環(huán)境變量、記憶內(nèi)容等。編排引擎的核心職責是根據(jù)當前的這個完整狀態(tài)通過一個決策函數(shù)Decision Function來決定下一個要執(zhí)行的動作或步驟。這個決策函數(shù)可以非常簡單比如基于某個結(jié)果字段的字符串匹配也可以非常復雜比如調(diào)用一個小型LLM根據(jù)當前狀態(tài)的自然語言描述來推理下一步該做什么。后者正是實現(xiàn)“智能”閉環(huán)的關鍵。3.2 實現(xiàn)基于LLM的動態(tài)路由我們在Gliding Horse中引入了一個輕量級的“路由決策器”模塊。它的輸入是當前的任務狀態(tài)包括目標、歷史、上一步結(jié)果、可用工具列表等輸出是下一個步驟的ID或動作指令。這個決策器本身可以由一個配置了特定Prompt的LLM來驅(qū)動。例如在一個“內(nèi)容創(chuàng)作”Agent中步驟可能包括“搜集資料”、“撰寫草稿”、“潤色修改”、“配圖建議”。傳統(tǒng)的流程會按順序執(zhí)行。但引入動態(tài)路由后情況變了在“搜集資料”后決策器會評估資料的充分性。如果資料已經(jīng)很豐富則直接進入“撰寫草稿”如果資料不足則可能觸發(fā)“深入搜索”或“向用戶提問澄清需求”的步驟。在“潤色修改”后決策器可以調(diào)用一個“質(zhì)量檢查”工具來評估文本質(zhì)量。如果分數(shù)達標則進入“配圖建議”如果不達標則可能返回“重新潤色”或“調(diào)整文章結(jié)構(gòu)”。這個決策過程被封裝成一個可配置的“路由節(jié)點”。我們在編排配置文件中不再只是線性地列出步驟而是定義狀態(tài)和路由規(guī)則# 簡化的動態(tài)編排配置示例 workflow: states: - id: gather_info action: web_search parameters: { query: {{task.topic}} } - id: decide_next action: llm_router # 這是一個特殊的決策動作 parameters: prompt: | 你是一個任務調(diào)度專家。根據(jù)以下任務狀態(tài)決定下一步 任務目標{{task.goal}} 已搜集信息{{state.last_result}} 當前進度{{state.step_history}} 可選下一步[write_draft, search_deeper, ask_user] 請只返回選擇項的字符串。 - id: write_draft action: write_content condition: {{state.last_decision}} write_draft - id: search_deeper action: advanced_web_search condition: {{state.last_decision}} search_deeper - id: ask_user action: request_clarification condition: {{state.last_decision}} ask_user在這個配置中decide_next就是一個路由節(jié)點它利用LLM分析當前狀態(tài)動態(tài)選擇后續(xù)分支。condition字段確保了只有被選中的分支才會執(zhí)行。3.3 編排中的異常處理與回退機制一個健壯的閉環(huán)系統(tǒng)必須能處理異常。之前的版本中異常往往導致整個任務鏈中斷?，F(xiàn)在我們將異常也視為一種特殊的“狀態(tài)”并為其設計了專門的路由和處理邏輯。我們定義了不同級別的異常可重試錯誤Retriable Error如網(wǎng)絡超時、API臨時限速。編排引擎會自動根據(jù)策略如指數(shù)退避重試當前步驟。需降級處理錯誤Fallback Error如某個高級分析工具失效。決策器可以捕獲這個錯誤狀態(tài)并路由到一個使用基礎工具的降級步驟。需人工干預錯誤Human Intervention Error如遇到無法理解的用戶輸入或違反安全策略。流程會暫停并通過預設渠道如發(fā)送消息到Slack通知人類操作員。邏輯失敗Logic Failure如經(jīng)過多次嘗試和降級后仍無法完成子目標。這時決策器可能選擇跳過當前子任務記錄失敗原因并嘗試繼續(xù)執(zhí)行后續(xù)可能成功的其他部分或者優(yōu)雅地終止整個任務并生成總結(jié)報告。實現(xiàn)上我們在每個Action的執(zhí)行外層包裹了一個統(tǒng)一的錯誤捕獲和狀態(tài)包裝器。錯誤信息會被結(jié)構(gòu)化地記錄到任務狀態(tài)中供決策器使用。同時我們設置了一個全局的“異常處理路由表”作為決策器的后備選擇確保任何未預料的錯誤都有一個最終的、安全的處理路徑。提示動態(tài)路由雖然強大但也會增加系統(tǒng)的復雜性和不確定性LLM決策可能不穩(wěn)定。我們的經(jīng)驗是對于關鍵的業(yè)務邏輯分支最好還是結(jié)合規(guī)則判斷如if result.confidence 0.8和LLM路由形成“規(guī)則為主LLM為輔”的混合決策模式在靈活性和可靠性之間取得平衡。4. 可觀測性體系建設看清Agent的“思考過程”在早期版本中Gliding Horse就像一個黑盒輸入任務等待輸出中間過程除了簡單的日志輸出幾乎不可見。當任務失敗或結(jié)果不如預期時排查問題非常困難你只知道它“錯了”但很難知道它“為什么錯”以及在哪個環(huán)節(jié)開始“想歪了”。這對于調(diào)試和優(yōu)化一個旨在實現(xiàn)“智能閉環(huán)”的系統(tǒng)來說是致命的。閉環(huán)的可靠性建立在每一步的可理解、可驗證之上。4.1 結(jié)構(gòu)化日志與執(zhí)行軌跡追蹤我們首先摒棄了零散的print語句建立了一套結(jié)構(gòu)化的日志系統(tǒng)。每一個Agent的步驟Step、動作Action、工具調(diào)用Tool Call都會產(chǎn)生一條帶有統(tǒng)一格式的日志事件。每條日志至少包含時間戳和唯一會話ID。事件類型如STEP_START,ACTION_CALL,TOOL_SUCCESS,LLM_REQUEST。關聯(lián)的組件或節(jié)點ID。輸入數(shù)據(jù)經(jīng)過脫敏處理。輸出結(jié)果或狀態(tài)變更。執(zhí)行耗時。這些日志被實時收集并發(fā)送到像ELKElasticsearch, Logstash, Kibana或時序數(shù)據(jù)庫如InfluxDB中。更重要的是我們引入了執(zhí)行軌跡Execution Trace的概念。一條軌跡完整記錄了一個任務從開始到結(jié)束或失敗的所有關鍵事件并保持了它們之間的父子關系和順序關系。這讓我們能夠像看調(diào)用鏈一樣清晰地還原出Agent的完整“思考-行動”路徑。例如通過Kibana我們可以輕松過濾出所有失敗的任務然后鉆取到某一條具體軌跡看到“哦它在第三步調(diào)用‘數(shù)據(jù)提取工具’時超時了然后重試了一次還是失敗接著決策器試圖降級到‘基礎解析工具’但輸入格式不匹配最終觸發(fā)了人工干預?！?.2 關鍵指標的監(jiān)控與告警除了事后分析我們還需要實時感知系統(tǒng)的健康狀況。我們定義并監(jiān)控了一系列關鍵指標Metrics任務成功率單位時間內(nèi)成功完成的任務比例。平均任務耗時從開始到結(jié)束的平均時間可以按任務類型細分。步驟耗時分布分析哪個步驟最耗時成為性能瓶頸。工具調(diào)用統(tǒng)計各工具的成功率、失敗率、平均響應時間。這能快速定位不可靠的外部依賴。LLM使用情況Token消耗量、請求速率、各Prompt模板的調(diào)用頻率。記憶系統(tǒng)效能長期記憶的檢索命中率、檢索延遲。這些指標通過Prometheus等監(jiān)控系統(tǒng)進行采集和聚合并配置Grafana儀表盤進行可視化。我們?yōu)殛P鍵指標設置了告警規(guī)則例如“如果‘數(shù)據(jù)清洗工具’的失敗率在5分鐘內(nèi)超過10%”則立即觸發(fā)告警通知開發(fā)人員檢查。4.3 思維鏈CoT的持久化與可視化對于基于LLM的Agent其核心的“智能”體現(xiàn)在推理過程中。為了真正理解Agent的決策邏輯我們強制要求關鍵決策點特別是LLM路由決策和復雜問題分解必須輸出其思維鏈Chain-of-Thought。這不是最終答案而是模型得出答案前的推理文本。我們將這些原始的CoT文本也作為執(zhí)行軌跡的一部分持久化存儲起來。在前端調(diào)試界面我們開發(fā)了一個簡單的可視化工具可以將一個任務的執(zhí)行軌跡以時間線或樹形圖的方式展開并在每個LLM調(diào)用節(jié)點上懸浮顯示其完整的Prompt和CoT響應。這個功能的價值巨大。有一次我們發(fā)現(xiàn)Agent在撰寫產(chǎn)品描述時總是忽略某個關鍵特性。通過查看CoT我們發(fā)現(xiàn)是因為在信息檢索步驟LLM在總結(jié)資料時無意中漏掉了包含該特性的一句話。問題根源不是出在撰寫步驟而是在上游的信息理解步驟。沒有CoT我們可能要在撰寫模塊的Prompt優(yōu)化上浪費大量時間。注意持久化CoT會帶來額外的存儲開銷和潛在的隱私/合規(guī)考慮可能包含敏感數(shù)據(jù)或模型權重信息。務必對CoT日志進行嚴格的訪問控制并考慮在存儲前對敏感信息進行脫敏或加密處理。對于生產(chǎn)環(huán)境可以只采樣存儲一部分任務的CoT用于分析。5. 實戰(zhàn)案例一個營銷文案生成Agent的閉環(huán)優(yōu)化之旅為了將上述優(yōu)化點具體化我們以Gliding Horse內(nèi)部孵化的一個“營銷文案生成Agent”為例看看這些改進如何在實際場景中發(fā)揮作用。這個Agent的原始目標是輸入一個產(chǎn)品名稱和核心賣點自動生成一篇用于社交媒體發(fā)布的營銷文案。最初的流程很簡單1. 搜索產(chǎn)品信息。 2. 搜索同類競品文案。 3. 調(diào)用LLM生成文案。 4. 輸出結(jié)果。優(yōu)化前的問題生成文案風格不穩(wěn)定時而活潑時而嚴肅。經(jīng)常遺漏輸入的核心賣點。如果搜索不到競品信息整個流程會報錯停止。無法判斷生成的文案質(zhì)量好壞只能盲目輸出。我們?nèi)绾螒脙?yōu)化方案第一步強化記憶與目標對齊長期記憶我們讓Agent在任務開始時將用戶輸入的“產(chǎn)品名稱”、“核心賣點”以及用戶可能指定的“文案風格”如“科技感”、“溫馨親切”作為最高優(yōu)先級的記憶項存入。工作記憶在每一步如“搜集競品文案”時工作記憶中會明確包含“核心賣點XXX 風格要求XXX”確保搜索和后續(xù)處理都圍繞這些核心要素展開。效果生成的文案幾乎不再遺漏賣點風格一致性也大幅提升。因為在整個思考過程中這些關鍵約束條件被反復強調(diào)和引用。第二步動態(tài)編排應對不確定性我們將“搜索競品文案”步驟改造為一個動態(tài)子流程。首先嘗試通用搜索。如果結(jié)果數(shù)量不足決策器LLM路由會判斷是因為產(chǎn)品太新還是搜索關鍵詞不佳如果是后者則自動衍生出一個“優(yōu)化關鍵詞并重新搜索”的步驟。如果確認是產(chǎn)品太新缺乏競品則決策器會跳過“借鑒競品”這個分支直接進入“基于產(chǎn)品基本信息生成創(chuàng)意”的步驟并記錄“本次任務缺乏競品參考”到狀態(tài)中。效果Agent不再因為“搜不到競品”而崩潰而是能夠靈活調(diào)整策略繼續(xù)完成任務實現(xiàn)了真正的閉環(huán)。第三步引入質(zhì)量檢查與迭代優(yōu)化在生成文案后我們新增了一個“文案質(zhì)量評估”步驟。這個步驟調(diào)用另一個LLM或評估模型根據(jù)預定義的維度如吸引力、相關性、語法、包含核心賣點對文案進行打分。編排引擎根據(jù)打分結(jié)果做決策如果分數(shù) 85分直接輸出最終文案。如果 60分 分數(shù) 85分則進入“文案潤色優(yōu)化”步驟將評估結(jié)果如“吸引力不足”作為反饋輸入讓LLM重寫一遍。如果分數(shù) 60分則認為本次生成失敗可能觸發(fā)“重新分析需求”或“通知人工”的流程。效果文案的平均質(zhì)量得分顯著提高且避免了產(chǎn)出明顯不合格的文案。這個“生成-評估-優(yōu)化”的微循環(huán)是智能閉環(huán)在質(zhì)量層面的重要體現(xiàn)。第四步全程可觀測與持續(xù)調(diào)優(yōu)我們將每次任務的完整軌跡、CoT、各步驟耗時、質(zhì)量評估分數(shù)都記錄了下來。通過分析儀表盤我們發(fā)現(xiàn)“文案質(zhì)量評估”步驟的耗時占了大頭。進一步查看發(fā)現(xiàn)是因為評估Prompt過于復雜導致LLM響應慢。我們優(yōu)化了評估Prompt將其拆解為幾個更簡單、可并行執(zhí)行的檢查如語法檢查、賣點檢查分開并將評估模型換成了更輕量級的版本成功將該步驟耗時降低了60%。通過分析失敗任務的CoT我們發(fā)現(xiàn)一些文案吸引力得分低是因為LLM在生成時過于追求信息全面而顯得枯燥。于是我們在生成Prompt中增加了“請使用至少一個比喻或感嘆句來增加感染力”的約束。經(jīng)過這一系列的優(yōu)化這個營銷文案生成Agent從一個脆弱的腳本進化成了一個能夠自主處理一定不確定性、保障輸出質(zhì)量、且其行為可分析、可優(yōu)化的真正“智能體”。它不再是一個開環(huán)的工具而是一個能夠感知環(huán)境搜索反饋、評估結(jié)果、調(diào)整策略動態(tài)路由、并朝著穩(wěn)定目標高質(zhì)量文案持續(xù)努力的閉環(huán)系統(tǒng)。6. 踩坑實錄從“理論可行”到“生產(chǎn)可用”的關鍵障礙在將Gliding Horse這套優(yōu)化方案落地的過程中我們遇到了不少預料之外的問題。把這些坑記錄下來可能比成功的經(jīng)驗更有價值。第一個大坑記憶檢索的“相關性幻覺”我們最初直接使用向量檢索的Top-K結(jié)果作為記憶上下文。但在實踐中發(fā)現(xiàn)有時檢索到的記憶片段雖然向量相似度高但語義上并不相關甚至會產(chǎn)生誤導。例如任務是關于“編寫Python單元測試”卻檢索到了之前“部署Python服務”的記憶因為兩者都頻繁出現(xiàn)“Python”這個詞。我們的解決方案混合檢索結(jié)合關鍵詞BM25和向量檢索取并集或?qū)Y(jié)果重排序提高召回率。元數(shù)據(jù)過濾在存入記憶時打上更豐富的元數(shù)據(jù)標簽如task_type: “testing”,language: “python”。檢索時先根據(jù)當前狀態(tài)的元數(shù)據(jù)如從任務描述中提取出的task_type進行預過濾再進行向量相似度計算。重排序Re-ranking用一個更小、更快的“重排序模型”對初步檢索到的N條記憶進行相關性打分只選取分數(shù)最高的前M條MK。這雖然增加了一次計算但顯著提升了上下文質(zhì)量。第二個大坑動態(tài)路由的決策不穩(wěn)定LLM作為路由決策器有時會給出不一致的決策。比如在完全相同的任務狀態(tài)下可能一次選擇search_deeper另一次選擇ask_user。這種不確定性在測試時難以復現(xiàn)給調(diào)試帶來了噩夢。我們的解決方案降低溫度Temperature將路由決策LLM的溫度參數(shù)設為0或接近0鼓勵其輸出最確定的答案減少隨機性。結(jié)構(gòu)化輸出約束要求LLM必須以嚴格的JSON格式輸出決策甚至只允許輸出預定義選項中的一個并在Prompt中強調(diào)“必須選擇最直接、最有效的下一步”。引入決策緩存對于相同的輸入狀態(tài)哈希緩存其路由決策結(jié)果一段時間。這不僅能提高性能還能在短時間內(nèi)保證決策的一致性。當然對于需要探索不同路徑的場景可以禁用緩存。設置默認路由和超時如果LLM路由決策超時或返回無法解析的結(jié)果則降級到一套基于規(guī)則的默認路由邏輯保證系統(tǒng)至少能以一種可預測的方式繼續(xù)運行。第三個大坑可觀測性數(shù)據(jù)泛濫當我們把日志、指標、軌跡、CoT全量記錄后數(shù)據(jù)量暴漲存儲成本和查詢性能成了問題。同時信息太多也讓問題定位反而變慢了就像在森林里迷了路。我們的解決方案分級存儲與采樣實時日志只保留最近7天的詳細日志用于實時調(diào)試和近期問題排查。執(zhí)行軌跡全量存儲但采用列式壓縮存儲并建立高效的索引按任務ID、狀態(tài)、時間。CoT數(shù)據(jù)并非所有任務都需要。我們只對失敗任務、耗時異常任務、以及隨機采樣的一部分成功任務進行全量CoT存儲。聚合指標原始的高頻指標數(shù)據(jù)在計算聚合值如每分鐘成功率后原始數(shù)據(jù)只保留較短時間聚合數(shù)據(jù)長期保留。構(gòu)建診斷視圖在監(jiān)控儀表盤上我們不是簡單羅列所有數(shù)據(jù)而是創(chuàng)建了幾個專用的“診斷視圖”。例如“失敗任務分析視圖”會自動關聯(lián)展示失敗任務的軌跡、錯誤日志和CoT讓開發(fā)者一鍵直達問題現(xiàn)場。第四個大坑閉環(huán)中的“死循環(huán)”智能體在自主決策時可能陷入死循環(huán)。例如在“生成-評估-優(yōu)化”循環(huán)中如果評估標準過于嚴苛或生成模型能力有限可能導致Agent不斷重寫永遠無法達到“通過”閾值。我們的解決方案設置硬性限制對所有循環(huán)如重試、優(yōu)化迭代設置最大次數(shù)限制如3次。達到上限后必須跳出循環(huán)要么失敗要么走降級流程。引入“進展”檢測在循環(huán)中不僅看當前結(jié)果的絕對分數(shù)還看相比上一次迭代是否有改進。如果連續(xù)兩次迭代沒有顯著改進如分數(shù)提升1%則判定為陷入局部最優(yōu)主動退出循環(huán)。設計“逃生艙”在編排中預設“終極回退”步驟。當系統(tǒng)檢測到可能陷入死循環(huán)或經(jīng)過多次嘗試仍失敗時強制跳轉(zhuǎn)到該步驟。這個步驟可能是一個極簡的保底方案或者是發(fā)送通知給人類。這些坑讓我們深刻認識到構(gòu)建一個可靠的智能閉環(huán)技術方案只占一半另一半是對邊界情況、異常狀態(tài)和系統(tǒng)韌性的周密考慮。每一次填坑都讓Gliding Horse向“生產(chǎn)可用”的目標更近了一步。 AI Agent智能閉環(huán)實戰(zhàn)：從記憶、編排到可觀測性的系統(tǒng)優(yōu)化
1. 從“能跑”到“跑通”一次Agent實戰(zhàn)的認知升級最近在折騰一個叫Gliding Horse的Agent項目它基于Agent Harness框架目標是實現(xiàn)一個能自主處理復雜任務的“智能閉環(huán)”系統(tǒng)。說實話剛開始拿到這個項目時感覺挺酷的——框架搭好了基礎功能也都有跑起來也能看到Agent在按部就班地執(zhí)行任務。但用了一段時間尤其是在處理一些需要多步驟、有狀態(tài)依賴的真實場景時問題就暴露出來了任務流程是“跑”起來了但離“跑通”還差得遠。這里的“跑通”不是指程序不報錯而是指整個智能體系統(tǒng)能像我們期望的那樣形成一個穩(wěn)定、可靠、可解釋的閉環(huán)工作流而不是一個脆弱的、經(jīng)常需要人工介入的“半自動”玩具。這次對Gliding Horse的深度優(yōu)化就是圍繞這個核心目標展開的。我們不再滿足于讓Agent“動起來”而是要讓它“聰明地跑起來”。優(yōu)化的焦點集中在了幾個最影響閉環(huán)質(zhì)量的痛點上記憶系統(tǒng)的健壯性、任務編排SA Orchestration的靈活性以及整個執(zhí)行流程的可觀測性。這背后涉及到的不僅僅是改幾行代碼更是對Agent Harness這類框架在實際應用中“水土不服”問題的系統(tǒng)性思考和解決。如果你也在用類似框架構(gòu)建自己的智能體或者對如何讓AI Agent從Demo走向?qū)嵱酶信d趣那么這次踩坑和填坑的經(jīng)歷或許能給你一些直接的啟發(fā)。2. 記憶系統(tǒng)的重構(gòu)從“瞬時記憶”到“工作記憶長期記憶”最初的Gliding Horse版本其記憶系統(tǒng)設計得相對簡單可以稱之為“瞬時記憶”模式。Agent在執(zhí)行每個步驟時能夠獲取到上一步的輸出和當前的環(huán)境狀態(tài)但一旦任務鏈稍長或者需要回溯到很久之前的上下文時Agent就顯得力不從心了。它就像一個只有短期記憶的人記得剛說過的話但忘了十分鐘前討論的目標導致決策偏離初衷。這在處理諸如“分析一份文檔然后根據(jù)分析結(jié)果起草郵件最后檢查郵件是否符合公司規(guī)范”這類連貫任務時問題尤為突出。2.1 原有記憶機制的瓶頸分析原有的記憶機制主要依賴于任務執(zhí)行時的即時上下文傳遞。在Agent Harness的框架下這通常是通過在State對象中攜帶有限的幾步歷史記錄來實現(xiàn)的。這種設計帶來了幾個明顯問題第一是上下文窗口的硬性限制。為了控制計算和存儲成本歷史記錄通常只保留最近的N條。當任務步驟超過N時關鍵的初始指令或中間決策依據(jù)就會被“遺忘”導致后續(xù)步驟失去方向。第二是記憶的“扁平化”。所有歷史記錄無論是核心的用戶指令、關鍵的推理結(jié)果還是普通的工具調(diào)用日志都被混在一起沒有優(yōu)先級和結(jié)構(gòu)。當Agent需要做決策時它不得不從一堆雜亂的信息中費力地尋找相關線索效率低下且容易出錯。第三是缺乏記憶的主動管理。記憶只是被被動地記錄和讀取沒有“記住重點、忘記冗余”的機制。在長對話或多輪任務中無關信息會不斷累積形成噪音干擾Agent的核心判斷。2.2 引入分層記憶架構(gòu)為了解決這些問題我們參考了人類認知中“工作記憶”和“長期記憶”的概念對Gliding Horse的記憶系統(tǒng)進行了分層重構(gòu)。工作記憶Working Memory被設計為Agent當前的“思考白板”。它容量有限但訪問速度極快專門用于存放與當前步驟高度相關的即時信息。例如當前步驟的精確目標。上一步執(zhí)行的關鍵結(jié)果或產(chǎn)出。為解決當前子問題而臨時提取的幾條最關鍵的歷史信息。當前步驟的臨時推理過程和待辦事項。在實現(xiàn)上工作記憶通常通過優(yōu)化Prompt工程和上下文管理來實現(xiàn)。我們會動態(tài)地構(gòu)建一個高度濃縮的上下文只包含執(zhí)行當前動作所必需的最小信息集。這大大降低了模型的計算負擔并提高了響應的相關性和準確性。長期記憶Long-Term Memory則扮演了“知識庫”和“經(jīng)驗檔案”的角色。它用于存儲跨越整個任務會話甚至多個會話的重要信息。主要包括會話記憶Session Memory本次任務的核心目標、用戶的關鍵約束條件如預算、時間、已經(jīng)達成的重要里程碑、以及產(chǎn)生的最終或中間產(chǎn)物如生成的報告、代碼片段。這些信息會被結(jié)構(gòu)化存儲例如使用向量數(shù)據(jù)庫存儲關鍵決策點的Embedding并用元數(shù)據(jù)標注。實體記憶Entity Memory在任務執(zhí)行過程中識別出的重要實體及其屬性關系。例如在處理客戶支持任務時識別出的客戶ID、問題類型、產(chǎn)品型號、已嘗試的解決方案等。這些實體可以跨會話關聯(lián)實現(xiàn)個性化的服務。技能/工具記憶Skill Memory記錄Agent調(diào)用各種工具或API的成功與失敗經(jīng)驗。例如“調(diào)用天氣API時城市名必須用英文”“生成圖表時參數(shù)X和Y不能同時為空”。這類記憶可以幫助Agent在未來遇到類似場景時做出更優(yōu)的選擇或提前規(guī)避已知錯誤。我們?yōu)镚liding Horse集成了向量數(shù)據(jù)庫如Chroma或Weaviate來存儲和檢索長期記憶。關鍵的一步是設計了一套記憶寫入與讀取的觸發(fā)與篩選策略。不是所有信息都值得存入長期記憶。我們定義了規(guī)則只有被標記為“里程碑事件”、“用戶明確強調(diào)的信息”、“任務產(chǎn)出的核心結(jié)果”或“從失敗中總結(jié)的教訓”才會被寫入。讀取時則根據(jù)當前工作記憶中的焦點從長期記憶中召回最相關的幾條記錄動態(tài)注入到工作上下文中。2.3 記憶優(yōu)化的實戰(zhàn)效果與配置示例經(jīng)過重構(gòu)后最直觀的感受是Agent的“連貫性”和“目的性”大大增強。例如在一個“競品分析報告生成”的任務中Agent能夠記住報告的核心框架要求長期記憶并在撰寫每個部分時準確引用之前步驟中爬取到的對應競品數(shù)據(jù)從長期記憶中動態(tài)檢索并加載到工作記憶而不會在寫結(jié)論時忘了開頭設定的分析維度。這里分享一個簡化版的記憶系統(tǒng)配置示例展示了如何結(jié)合LangChain假設的底層庫進行設置# 偽代碼示例展示分層記憶的初始化 from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.schema import Document import json class EnhancedMemorySystem: def __init__(self): # 初始化向量數(shù)據(jù)庫作為長期記憶存儲 self.embedding_function OpenAIEmbeddings() self.vector_store Chroma(embedding_functionself.embedding_function, persist_directory./memory_db) self.session_summary # 會話記憶的文本摘要 self.working_memory_buffer [] # 工作記憶的臨時緩沖區(qū) def commit_to_long_term(self, content, metadata): 將重要信息提交到長期記憶 doc Document(page_contentcontent, metadatametadata) self.vector_store.add_documents([doc]) # 同時更新會話摘要 self._update_session_summary(content) def retrieve_for_context(self, query, k3): 根據(jù)當前查詢從長期記憶中檢索最相關的信息 docs self.vector_store.similarity_search(query, kk) return \n.join([f[記憶{i1}]: {doc.page_content} for i, doc in enumerate(docs)]) def set_working_memory(self, current_goal, last_result, retrieved_memories): 設置當前工作記憶 self.working_memory_buffer [ f當前目標: {current_goal}, f上一步結(jié)果: {last_result[:200]}..., # 截斷避免過長 f相關歷史背景: {retrieved_memories} ] def get_working_context(self): 獲取整合后的工作上下文用于生成Prompt return \n.join(self.working_memory_buffer) # 在Agent執(zhí)行步驟中使用 memory_system EnhancedMemorySystem() # 當完成一個重要步驟時如“確定了報告大綱” memory_system.commit_to_long_term( content已確定競品分析報告大綱1.市場概述 2.功能對比 3.定價策略 4.SWOT分析 5.結(jié)論, metadata{type: milestone, step: outline, task_id: 123} ) # 在執(zhí)行“撰寫功能對比”步驟前 relevant_mem memory_system.retrieve_for_context(競品功能對比維度, k2) memory_system.set_working_memory( current_goal撰寫‘功能對比’章節(jié)需對比產(chǎn)品A、B、C的核心功能點。, last_result已爬取到產(chǎn)品A、B、C的官方功能列表。, retrieved_memoriesrelevant_mem ) # 然后將 memory_system.get_working_context() 注入到LLM的Prompt中注意記憶系統(tǒng)的設計需要在“記住更多”和“避免干擾”之間取得平衡。過度依賴長期記憶可能導致上下文膨脹反而降低模型性能。我們的經(jīng)驗是為記憶的寫入設定較高的閾值并為檢索配置一個“相關性分數(shù)”過濾器只召回分數(shù)高于閾值的最相關記憶。3. SA編排引擎的精細化改造讓任務流“活”起來Gliding Horse最初的任務編排SA Orchestration相對剛性可以理解為一種“預定義流程圖”的模式。任務步驟Step和動作Action之間的流轉(zhuǎn)邏輯大多通過硬編碼的條件判斷if-else或簡單的線性順序來驅(qū)動。這種模式在面對規(guī)劃清晰、路徑單一的任務時沒問題但一旦遇到需要動態(tài)決策、分支選擇或異常處理的情況就顯得非常笨拙。所謂的“智能閉環(huán)”在這里出現(xiàn)了斷點因為流程本身不智能。3.1 從靜態(tài)流程圖到動態(tài)狀態(tài)機我們的優(yōu)化核心是將編排引擎從“靜態(tài)流程圖”升級為“動態(tài)狀態(tài)機”。這不是簡單地換一個技術名詞而是設計理念的轉(zhuǎn)變。在靜態(tài)流程圖模式下流程路徑是預先完全確定的。Step A之后一定是Step B除非遇到特定錯誤跳轉(zhuǎn)到Step Error。而在動態(tài)狀態(tài)機模式下我們定義的是狀態(tài)State和狀態(tài)轉(zhuǎn)移的條件Condition。每個步驟執(zhí)行后會產(chǎn)生一個新的狀態(tài)包含執(zhí)行結(jié)果、環(huán)境變量、記憶內(nèi)容等。編排引擎的核心職責是根據(jù)當前的這個完整狀態(tài)通過一個決策函數(shù)Decision Function來決定下一個要執(zhí)行的動作或步驟。這個決策函數(shù)可以非常簡單比如基于某個結(jié)果字段的字符串匹配也可以非常復雜比如調(diào)用一個小型LLM根據(jù)當前狀態(tài)的自然語言描述來推理下一步該做什么。后者正是實現(xiàn)“智能”閉環(huán)的關鍵。3.2 實現(xiàn)基于LLM的動態(tài)路由我們在Gliding Horse中引入了一個輕量級的“路由決策器”模塊。它的輸入是當前的任務狀態(tài)包括目標、歷史、上一步結(jié)果、可用工具列表等輸出是下一個步驟的ID或動作指令。這個決策器本身可以由一個配置了特定Prompt的LLM來驅(qū)動。例如在一個“內(nèi)容創(chuàng)作”Agent中步驟可能包括“搜集資料”、“撰寫草稿”、“潤色修改”、“配圖建議”。傳統(tǒng)的流程會按順序執(zhí)行。但引入動態(tài)路由后情況變了在“搜集資料”后決策器會評估資料的充分性。如果資料已經(jīng)很豐富則直接進入“撰寫草稿”如果資料不足則可能觸發(fā)“深入搜索”或“向用戶提問澄清需求”的步驟。在“潤色修改”后決策器可以調(diào)用一個“質(zhì)量檢查”工具來評估文本質(zhì)量。如果分數(shù)達標則進入“配圖建議”如果不達標則可能返回“重新潤色”或“調(diào)整文章結(jié)構(gòu)”。這個決策過程被封裝成一個可配置的“路由節(jié)點”。我們在編排配置文件中不再只是線性地列出步驟而是定義狀態(tài)和路由規(guī)則# 簡化的動態(tài)編排配置示例 workflow: states: - id: gather_info action: web_search parameters: { query: {{task.topic}} } - id: decide_next action: llm_router # 這是一個特殊的決策動作 parameters: prompt: | 你是一個任務調(diào)度專家。根據(jù)以下任務狀態(tài)決定下一步 任務目標{{task.goal}} 已搜集信息{{state.last_result}} 當前進度{{state.step_history}} 可選下一步[write_draft, search_deeper, ask_user] 請只返回選擇項的字符串。 - id: write_draft action: write_content condition: {{state.last_decision}} write_draft - id: search_deeper action: advanced_web_search condition: {{state.last_decision}} search_deeper - id: ask_user action: request_clarification condition: {{state.last_decision}} ask_user在這個配置中decide_next就是一個路由節(jié)點它利用LLM分析當前狀態(tài)動態(tài)選擇后續(xù)分支。condition字段確保了只有被選中的分支才會執(zhí)行。3.3 編排中的異常處理與回退機制一個健壯的閉環(huán)系統(tǒng)必須能處理異常。之前的版本中異常往往導致整個任務鏈中斷?，F(xiàn)在我們將異常也視為一種特殊的“狀態(tài)”并為其設計了專門的路由和處理邏輯。我們定義了不同級別的異常可重試錯誤Retriable Error如網(wǎng)絡超時、API臨時限速。編排引擎會自動根據(jù)策略如指數(shù)退避重試當前步驟。需降級處理錯誤Fallback Error如某個高級分析工具失效。決策器可以捕獲這個錯誤狀態(tài)并路由到一個使用基礎工具的降級步驟。需人工干預錯誤Human Intervention Error如遇到無法理解的用戶輸入或違反安全策略。流程會暫停并通過預設渠道如發(fā)送消息到Slack通知人類操作員。邏輯失敗Logic Failure如經(jīng)過多次嘗試和降級后仍無法完成子目標。這時決策器可能選擇跳過當前子任務記錄失敗原因并嘗試繼續(xù)執(zhí)行后續(xù)可能成功的其他部分或者優(yōu)雅地終止整個任務并生成總結(jié)報告。實現(xiàn)上我們在每個Action的執(zhí)行外層包裹了一個統(tǒng)一的錯誤捕獲和狀態(tài)包裝器。錯誤信息會被結(jié)構(gòu)化地記錄到任務狀態(tài)中供決策器使用。同時我們設置了一個全局的“異常處理路由表”作為決策器的后備選擇確保任何未預料的錯誤都有一個最終的、安全的處理路徑。提示動態(tài)路由雖然強大但也會增加系統(tǒng)的復雜性和不確定性LLM決策可能不穩(wěn)定。我們的經(jīng)驗是對于關鍵的業(yè)務邏輯分支最好還是結(jié)合規(guī)則判斷如if result.confidence 0.8和LLM路由形成“規(guī)則為主LLM為輔”的混合決策模式在靈活性和可靠性之間取得平衡。4. 可觀測性體系建設看清Agent的“思考過程”在早期版本中Gliding Horse就像一個黑盒輸入任務等待輸出中間過程除了簡單的日志輸出幾乎不可見。當任務失敗或結(jié)果不如預期時排查問題非常困難你只知道它“錯了”但很難知道它“為什么錯”以及在哪個環(huán)節(jié)開始“想歪了”。這對于調(diào)試和優(yōu)化一個旨在實現(xiàn)“智能閉環(huán)”的系統(tǒng)來說是致命的。閉環(huán)的可靠性建立在每一步的可理解、可驗證之上。4.1 結(jié)構(gòu)化日志與執(zhí)行軌跡追蹤我們首先摒棄了零散的print語句建立了一套結(jié)構(gòu)化的日志系統(tǒng)。每一個Agent的步驟Step、動作Action、工具調(diào)用Tool Call都會產(chǎn)生一條帶有統(tǒng)一格式的日志事件。每條日志至少包含時間戳和唯一會話ID。事件類型如STEP_START,ACTION_CALL,TOOL_SUCCESS,LLM_REQUEST。關聯(lián)的組件或節(jié)點ID。輸入數(shù)據(jù)經(jīng)過脫敏處理。輸出結(jié)果或狀態(tài)變更。執(zhí)行耗時。這些日志被實時收集并發(fā)送到像ELKElasticsearch, Logstash, Kibana或時序數(shù)據(jù)庫如InfluxDB中。更重要的是我們引入了執(zhí)行軌跡Execution Trace的概念。一條軌跡完整記錄了一個任務從開始到結(jié)束或失敗的所有關鍵事件并保持了它們之間的父子關系和順序關系。這讓我們能夠像看調(diào)用鏈一樣清晰地還原出Agent的完整“思考-行動”路徑。例如通過Kibana我們可以輕松過濾出所有失敗的任務然后鉆取到某一條具體軌跡看到“哦它在第三步調(diào)用‘數(shù)據(jù)提取工具’時超時了然后重試了一次還是失敗接著決策器試圖降級到‘基礎解析工具’但輸入格式不匹配最終觸發(fā)了人工干預?！?.2 關鍵指標的監(jiān)控與告警除了事后分析我們還需要實時感知系統(tǒng)的健康狀況。我們定義并監(jiān)控了一系列關鍵指標Metrics任務成功率單位時間內(nèi)成功完成的任務比例。平均任務耗時從開始到結(jié)束的平均時間可以按任務類型細分。步驟耗時分布分析哪個步驟最耗時成為性能瓶頸。工具調(diào)用統(tǒng)計各工具的成功率、失敗率、平均響應時間。這能快速定位不可靠的外部依賴。LLM使用情況Token消耗量、請求速率、各Prompt模板的調(diào)用頻率。記憶系統(tǒng)效能長期記憶的檢索命中率、檢索延遲。這些指標通過Prometheus等監(jiān)控系統(tǒng)進行采集和聚合并配置Grafana儀表盤進行可視化。我們?yōu)殛P鍵指標設置了告警規(guī)則例如“如果‘數(shù)據(jù)清洗工具’的失敗率在5分鐘內(nèi)超過10%”則立即觸發(fā)告警通知開發(fā)人員檢查。4.3 思維鏈CoT的持久化與可視化對于基于LLM的Agent其核心的“智能”體現(xiàn)在推理過程中。為了真正理解Agent的決策邏輯我們強制要求關鍵決策點特別是LLM路由決策和復雜問題分解必須輸出其思維鏈Chain-of-Thought。這不是最終答案而是模型得出答案前的推理文本。我們將這些原始的CoT文本也作為執(zhí)行軌跡的一部分持久化存儲起來。在前端調(diào)試界面我們開發(fā)了一個簡單的可視化工具可以將一個任務的執(zhí)行軌跡以時間線或樹形圖的方式展開并在每個LLM調(diào)用節(jié)點上懸浮顯示其完整的Prompt和CoT響應。這個功能的價值巨大。有一次我們發(fā)現(xiàn)Agent在撰寫產(chǎn)品描述時總是忽略某個關鍵特性。通過查看CoT我們發(fā)現(xiàn)是因為在信息檢索步驟LLM在總結(jié)資料時無意中漏掉了包含該特性的一句話。問題根源不是出在撰寫步驟而是在上游的信息理解步驟。沒有CoT我們可能要在撰寫模塊的Prompt優(yōu)化上浪費大量時間。注意持久化CoT會帶來額外的存儲開銷和潛在的隱私/合規(guī)考慮可能包含敏感數(shù)據(jù)或模型權重信息。務必對CoT日志進行嚴格的訪問控制并考慮在存儲前對敏感信息進行脫敏或加密處理。對于生產(chǎn)環(huán)境可以只采樣存儲一部分任務的CoT用于分析。5. 實戰(zhàn)案例一個營銷文案生成Agent的閉環(huán)優(yōu)化之旅為了將上述優(yōu)化點具體化我們以Gliding Horse內(nèi)部孵化的一個“營銷文案生成Agent”為例看看這些改進如何在實際場景中發(fā)揮作用。這個Agent的原始目標是輸入一個產(chǎn)品名稱和核心賣點自動生成一篇用于社交媒體發(fā)布的營銷文案。最初的流程很簡單1. 搜索產(chǎn)品信息。 2. 搜索同類競品文案。 3. 調(diào)用LLM生成文案。 4. 輸出結(jié)果。優(yōu)化前的問題生成文案風格不穩(wěn)定時而活潑時而嚴肅。經(jīng)常遺漏輸入的核心賣點。如果搜索不到競品信息整個流程會報錯停止。無法判斷生成的文案質(zhì)量好壞只能盲目輸出。我們?nèi)绾螒脙?yōu)化方案第一步強化記憶與目標對齊長期記憶我們讓Agent在任務開始時將用戶輸入的“產(chǎn)品名稱”、“核心賣點”以及用戶可能指定的“文案風格”如“科技感”、“溫馨親切”作為最高優(yōu)先級的記憶項存入。工作記憶在每一步如“搜集競品文案”時工作記憶中會明確包含“核心賣點XXX 風格要求XXX”確保搜索和后續(xù)處理都圍繞這些核心要素展開。效果生成的文案幾乎不再遺漏賣點風格一致性也大幅提升。因為在整個思考過程中這些關鍵約束條件被反復強調(diào)和引用。第二步動態(tài)編排應對不確定性我們將“搜索競品文案”步驟改造為一個動態(tài)子流程。首先嘗試通用搜索。如果結(jié)果數(shù)量不足決策器LLM路由會判斷是因為產(chǎn)品太新還是搜索關鍵詞不佳如果是后者則自動衍生出一個“優(yōu)化關鍵詞并重新搜索”的步驟。如果確認是產(chǎn)品太新缺乏競品則決策器會跳過“借鑒競品”這個分支直接進入“基于產(chǎn)品基本信息生成創(chuàng)意”的步驟并記錄“本次任務缺乏競品參考”到狀態(tài)中。效果Agent不再因為“搜不到競品”而崩潰而是能夠靈活調(diào)整策略繼續(xù)完成任務實現(xiàn)了真正的閉環(huán)。第三步引入質(zhì)量檢查與迭代優(yōu)化在生成文案后我們新增了一個“文案質(zhì)量評估”步驟。這個步驟調(diào)用另一個LLM或評估模型根據(jù)預定義的維度如吸引力、相關性、語法、包含核心賣點對文案進行打分。編排引擎根據(jù)打分結(jié)果做決策如果分數(shù) 85分直接輸出最終文案。如果 60分 分數(shù) 85分則進入“文案潤色優(yōu)化”步驟將評估結(jié)果如“吸引力不足”作為反饋輸入讓LLM重寫一遍。如果分數(shù) 60分則認為本次生成失敗可能觸發(fā)“重新分析需求”或“通知人工”的流程。效果文案的平均質(zhì)量得分顯著提高且避免了產(chǎn)出明顯不合格的文案。這個“生成-評估-優(yōu)化”的微循環(huán)是智能閉環(huán)在質(zhì)量層面的重要體現(xiàn)。第四步全程可觀測與持續(xù)調(diào)優(yōu)我們將每次任務的完整軌跡、CoT、各步驟耗時、質(zhì)量評估分數(shù)都記錄了下來。通過分析儀表盤我們發(fā)現(xiàn)“文案質(zhì)量評估”步驟的耗時占了大頭。進一步查看發(fā)現(xiàn)是因為評估Prompt過于復雜導致LLM響應慢。我們優(yōu)化了評估Prompt將其拆解為幾個更簡單、可并行執(zhí)行的檢查如語法檢查、賣點檢查分開并將評估模型換成了更輕量級的版本成功將該步驟耗時降低了60%。通過分析失敗任務的CoT我們發(fā)現(xiàn)一些文案吸引力得分低是因為LLM在生成時過于追求信息全面而顯得枯燥。于是我們在生成Prompt中增加了“請使用至少一個比喻或感嘆句來增加感染力”的約束。經(jīng)過這一系列的優(yōu)化這個營銷文案生成Agent從一個脆弱的腳本進化成了一個能夠自主處理一定不確定性、保障輸出質(zhì)量、且其行為可分析、可優(yōu)化的真正“智能體”。它不再是一個開環(huán)的工具而是一個能夠感知環(huán)境搜索反饋、評估結(jié)果、調(diào)整策略動態(tài)路由、并朝著穩(wěn)定目標高質(zhì)量文案持續(xù)努力的閉環(huán)系統(tǒng)。6. 踩坑實錄從“理論可行”到“生產(chǎn)可用”的關鍵障礙在將Gliding Horse這套優(yōu)化方案落地的過程中我們遇到了不少預料之外的問題。把這些坑記錄下來可能比成功的經(jīng)驗更有價值。第一個大坑記憶檢索的“相關性幻覺”我們最初直接使用向量檢索的Top-K結(jié)果作為記憶上下文。但在實踐中發(fā)現(xiàn)有時檢索到的記憶片段雖然向量相似度高但語義上并不相關甚至會產(chǎn)生誤導。例如任務是關于“編寫Python單元測試”卻檢索到了之前“部署Python服務”的記憶因為兩者都頻繁出現(xiàn)“Python”這個詞。我們的解決方案混合檢索結(jié)合關鍵詞BM25和向量檢索取并集或?qū)Y(jié)果重排序提高召回率。元數(shù)據(jù)過濾在存入記憶時打上更豐富的元數(shù)據(jù)標簽如task_type: “testing”,language: “python”。檢索時先根據(jù)當前狀態(tài)的元數(shù)據(jù)如從任務描述中提取出的task_type進行預過濾再進行向量相似度計算。重排序Re-ranking用一個更小、更快的“重排序模型”對初步檢索到的N條記憶進行相關性打分只選取分數(shù)最高的前M條MK。這雖然增加了一次計算但顯著提升了上下文質(zhì)量。第二個大坑動態(tài)路由的決策不穩(wěn)定LLM作為路由決策器有時會給出不一致的決策。比如在完全相同的任務狀態(tài)下可能一次選擇search_deeper另一次選擇ask_user。這種不確定性在測試時難以復現(xiàn)給調(diào)試帶來了噩夢。我們的解決方案降低溫度Temperature將路由決策LLM的溫度參數(shù)設為0或接近0鼓勵其輸出最確定的答案減少隨機性。結(jié)構(gòu)化輸出約束要求LLM必須以嚴格的JSON格式輸出決策甚至只允許輸出預定義選項中的一個并在Prompt中強調(diào)“必須選擇最直接、最有效的下一步”。引入決策緩存對于相同的輸入狀態(tài)哈希緩存其路由決策結(jié)果一段時間。這不僅能提高性能還能在短時間內(nèi)保證決策的一致性。當然對于需要探索不同路徑的場景可以禁用緩存。設置默認路由和超時如果LLM路由決策超時或返回無法解析的結(jié)果則降級到一套基于規(guī)則的默認路由邏輯保證系統(tǒng)至少能以一種可預測的方式繼續(xù)運行。第三個大坑可觀測性數(shù)據(jù)泛濫當我們把日志、指標、軌跡、CoT全量記錄后數(shù)據(jù)量暴漲存儲成本和查詢性能成了問題。同時信息太多也讓問題定位反而變慢了就像在森林里迷了路。我們的解決方案分級存儲與采樣實時日志只保留最近7天的詳細日志用于實時調(diào)試和近期問題排查。執(zhí)行軌跡全量存儲但采用列式壓縮存儲并建立高效的索引按任務ID、狀態(tài)、時間。CoT數(shù)據(jù)并非所有任務都需要。我們只對失敗任務、耗時異常任務、以及隨機采樣的一部分成功任務進行全量CoT存儲。聚合指標原始的高頻指標數(shù)據(jù)在計算聚合值如每分鐘成功率后原始數(shù)據(jù)只保留較短時間聚合數(shù)據(jù)長期保留。構(gòu)建診斷視圖在監(jiān)控儀表盤上我們不是簡單羅列所有數(shù)據(jù)而是創(chuàng)建了幾個專用的“診斷視圖”。例如“失敗任務分析視圖”會自動關聯(lián)展示失敗任務的軌跡、錯誤日志和CoT讓開發(fā)者一鍵直達問題現(xiàn)場。第四個大坑閉環(huán)中的“死循環(huán)”智能體在自主決策時可能陷入死循環(huán)。例如在“生成-評估-優(yōu)化”循環(huán)中如果評估標準過于嚴苛或生成模型能力有限可能導致Agent不斷重寫永遠無法達到“通過”閾值。我們的解決方案設置硬性限制對所有循環(huán)如重試、優(yōu)化迭代設置最大次數(shù)限制如3次。達到上限后必須跳出循環(huán)要么失敗要么走降級流程。引入“進展”檢測在循環(huán)中不僅看當前結(jié)果的絕對分數(shù)還看相比上一次迭代是否有改進。如果連續(xù)兩次迭代沒有顯著改進如分數(shù)提升1%則判定為陷入局部最優(yōu)主動退出循環(huán)。設計“逃生艙”在編排中預設“終極回退”步驟。當系統(tǒng)檢測到可能陷入死循環(huán)或經(jīng)過多次嘗試仍失敗時強制跳轉(zhuǎn)到該步驟。這個步驟可能是一個極簡的保底方案或者是發(fā)送通知給人類。這些坑讓我們深刻認識到構(gòu)建一個可靠的智能閉環(huán)技術方案只占一半另一半是對邊界情況、異常狀態(tài)和系統(tǒng)韌性的周密考慮。每一次填坑都讓Gliding Horse向“生產(chǎn)可用”的目標更近了一步。