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