這類產品強調的已經不只是回答問題，而是讓系統能夠理解上下文、聯動知識、調用能力、自動完成部分流程，再把人工坐席從機械操作裡釋放出來，轉向確認、判斷和兜底。

這些判斷並不是來自一次性的靈感，而是來自長期的客戶回饋、實施經驗和對未來服務方式的持續思考。對微語來說，更重要的問題不是「還能多加一個什麼 AI 功能」，而是如何把現有的客服、工單、知識庫、工作流、機器人和 AI 模組真正串成一個可落地的企業級 Agent 平台。

微語在長期客戶溝通中看到的變化​

如果把這些一線回饋和產品思考壓縮成幾個關鍵判斷，我認為核心有四點。

1. 客服行業正在從「人操作系統」走向「系統服務於人」​

傳統客服平台的底層邏輯，是讓人去切換多個系統、檢索知識、填寫表單、推進流程、協調後端。系統本身更多只是承載資料和等待操作。

而新一代 Agent 平台試圖反過來做這件事：

• 系統先理解會話意圖
• 系統主動組織所需知識和動作
• 系統自動執行標準化步驟
• 人工只在關鍵節點介入確認與決策

這意味著產品設計重點，已經從「功能有沒有」轉向「任務能不能閉環完成」。

2. 真正有競爭力的，不是 AI 助手，而是 AI 數位員工​

從客戶真實使用回饋看，單純「給建議、寫回覆、做摘要」的助手能力已經不夠。企業真正需要的，是能夠直接參與業務執行的 Agent。

例如在客戶進入會話後，系統不只是推薦一句話術，而是能夠連續完成：

• 意圖識別
• 標籤生成
• 知識召回
• 工單建立
• 表單預填
• 情緒識別
• 風險預警
• 會後小結
• CRM 資料沉澱

這類鏈路的價值在於，它把多個原本分散的 AI 小功能，變成了一個圍繞任務結果展開的執行流。

3. Agent + Skill 會成為聯絡中心的重要產品形態​

從微語自己的產品規劃角度看，「核心 Agent + 多 Skill」的組織方式非常值得進一步落地。核心 Agent 負責統一理解上下文和當前階段，再按場景調用不同技能能力，而不是把智慧回覆、質檢、填單、導航、總結等能力孤立地散落在各個模組裡。

這對企業場景尤其重要，因為企業真正要的不是十幾個分散的 AI 開關，而是一套能在服務流程裡穩定協同的能力系統。

4. Agent 的人格化和組織化會越來越重要​

另一個越來越明確的趨勢是，Agent 不再只是一個「機器人入口」，而是應該被設計成具備名稱、角色、頭像、技能邊界、協作關係的數位同事。

這看上去像產品包裝，但本質上是在解決兩個問題：

• 讓企業更容易理解不同 Agent 的職責邊界
• 讓坐席更自然地與系統協同，而不是把 AI 看成一個割裂工具

對微語而言，這意味著後續做 Agent 能力時，不能只停留在模型接入層，還要考慮角色建模、技能編排和協作體驗。

微語下一階段值得重點建設的能力​

如果只看「下一階段最值得投入什麼」，我認為重點不是單個 feature，而是下面幾組能力組合。

1. 統一會話中樞 Agent​

微語後續最值得補的一層，不是再加一個單獨的 AI 面板，而是在客服工作台之上建立統一會話中樞 Agent，讓它串聯目前已有能力：

• 訪客資訊與歷史上下文
• FAQ／知識庫召回
• 工單建立與欄位填充
• 服務流程節點推進
• 坐席輔助建議
• 質檢與風險提示

這層中樞如果做成，很多現在分散在訊息、工單、知識庫、服務設定裡的能力，才會真正形成協同。

2. 即時執行型 Skill，而不是靜態提示詞​

微語已經具備模型接入、知識庫、機器人、工作流等基礎，但下一步更關鍵的是把能力顯式抽象成 Skill，例如：

• 智慧回覆 Skill
• 智慧填單 Skill
• 即時質檢 Skill
• 知識導航 Skill
• 智慧小結 Skill
• 客戶情緒識別 Skill
• 風險預警 Skill

這些 Skill 不該只是 prompt 配置，而應該有明確的輸入、輸出、觸發條件、依賴資料源和執行結果記錄。

3. 人機協同式工單自動化​

從大量客戶現場回饋來看，工單相關動作仍然過度依賴人工錄入。對微語來說，這非常值得優先規劃：

• 根據會話內容自動識別工單類型
• 自動抽取客戶資訊和關鍵欄位
• 自動生成工單標題與摘要
• 自動推薦處理路徑或知識答案
• 在人工確認後完成建立或流轉

這類能力對金融、政務、企業服務、售後支援都很實用，也最容易直接體現效率收益。

4. 即時情緒識別與投訴預警​

傳統質檢很多是事後分析，但即時預警的業務價值更高。微語如果要往企業級客服平台走，這塊值得重點建設：

• 即時識別負面情緒
• 識別重複追問、長時間未解決、敏感詞觸發
• 給坐席即時提醒和建議動作
• 必要時自動升級主管或轉高級坐席

這會讓質檢從「復盤工具」升級成「過程干預工具」。

5. 會後自動沉澱，而不是只做回答生成​

真正拉開差距的，通常不是「回答生成得多漂亮」，而是每次服務結束後系統能沉澱下什麼。微語值得重點補齊：

• 自動生成服務小結
• 自動生成會話標籤
• 自動回填 CRM／客戶檔案
• 自動歸檔高價值問答到知識庫候選池
• 自動記錄失敗場景，供後續優化機器人和 Skill

如果這條鏈路打通，客服系統就會逐步從「解決當下問題」進化成「持續累積組織知識」。

結合微語現狀，產品規劃上更應該怎麼做​

微語已經有客服、機器人、知識庫、工單、工作流、多渠道和 AI 模組，問題不是「有沒有基礎」，而是這些基礎還沒有圍繞 Agent 形成統一的任務閉環。

相比繼續疊加零散功能，我更建議後續按照下面四個方向推進。

一，先定義微語自己的 Agent 物件模型​

要讓 Agent 真正成為平台能力，首先要把它從「機器人增強功能」提升為正式物件。至少需要定義清楚：

• Agent 角色與職責
• 綁定的 Skill 集合
• 可存取的資料範圍
• 可調用的工具和工作流
• 人工接管與升級規則

這樣後續不同場景下的客服 Agent、銷售輔助 Agent、質檢 Agent、工單 Agent 才能共用一套平台能力。

二，把客服工作流從「頁面配置」升級到「任務編排」​

今天很多系統裡的 workflow 更接近表單或路由配置。微語後續更值得做的是，把它升級成 Agent 視角的任務編排層，讓系統明確知道：

• 當前處於哪種服務場景
• 下一步應該先調知識、先問澄清問題，還是先建單
• 何時觸發質檢、預警、升級、轉人工
• 哪些動作可以自動執行，哪些動作必須人工確認

一旦做到這一層，微語的工作流就不只是「配置項」，而會成為 Agent 的執行框架。

三，把回饋體系升級成可營運的 Agent 評估系統​

如果微語未來真的要做強 Agent，必須把回饋資料結構化沉澱下來，而不是只看滿意度。

建議重點記錄這些訊號：

• AI 建議是否被採用
• 使用者是否重複追問
• 是否觸發轉人工
• 是否產生投訴或風險事件
• 哪些表單欄位仍需人工修改
• 哪些知識答案被頻繁命中但仍未解決問題

只有這些資料具備結構化記錄，後面 Skill 診斷、Agent 調優、知識庫迭代才有基礎。

四，把 Agent 做成後台可營運資產​

Agent 不應該只存在於會話頁裡，也應該在管理後台成為一個可配置、可分析、可發布的物件：

• 支援 Agent 版本管理
• 支援 Skill 配置和複用
• 支援不同租戶／工作組的灰度發布
• 支援按行業導入模板
• 支援查看關鍵指標變化

這會直接決定微語未來是「接了大模型的客服系統」，還是「可持續營運的企業 Agent 平台」。

一個更現實的微語落地順序​

從投入產出比來看，後續實現可以分三步走。

第一階段：補齊執行鏈路裡的自動化節點​

優先把最容易產生價值的能力做深：

• 會話意圖識別
• 標籤自動生成
• 工單欄位預填
• 服務小結生成
• 坐席即時輔助

這一階段的目標不是全自動，而是先把人工從重複勞動裡解放出來。

第二階段：建立 Agent + Skill 編排模型​

在管理後台增加 Agent 和 Skill 的配置能力，讓知識庫、工單、工作流和 AI 調用真正接入統一編排層。

這一階段完成後，微語才能從多個獨立功能，升級成一套面向場景執行的系統。

第三階段：形成持續優化閉環​

當回饋資料、Skill 配置、執行記錄都具備後，再推進：

• 失敗樣本歸因
• Skill 優化建議
• 行業模板沉澱
• 關鍵指標對比
• Agent 版本迭代

這一步決定微語後面能不能形成真正的產品壁壘。

微語接下來應該把哪些經驗沉澱成產品能力​

過去和客戶長期溝通後，微語越來越確認一個核心問題：如何讓系統代替人去組織資訊、執行動作、沉澱結果。

對微語來說，後續產品規劃如果仍然停留在「增加幾個智慧按鈕」，價值會比較有限；但如果能把知識庫、工單、工作流、坐席輔助、質檢和多模型能力組織成統一 Agent 體系，微語就有機會把客服平台從功能型產品，推進到真正具備執行能力和成長能力的企業服務作業系統。

參考​

• 微語客戶實踐溝通、專案復盤與產品規劃總結
• 從 SkillForge 看微語下一步：面向企業客服的自進化 Agent Skills
• 從成本中心到增長引擎：微語客服如何用 AI 與大數據重塑服務價值

過去幾年，微語持續接觸來自政務、金融、零售、電商、企業服務、售後支援等場景的真實需求。我們越來越明確地看到，企業已經不滿足於「接入一個大模型」或「加幾個智慧按鈕」，他們真正關心的是另一件事：系統能不能在服務流程裡穩定地理解上下文、輔助坐席、推動任務、沉澱知識，並最終形成持續優化的閉環。

因此，微語下一階段的建設重點，不是單點 AI 能力的繼續堆疊，而是把客服、工單、知識庫、工作流、質檢、多模型和營運後台，升級成一套面向企業服務場景的 Agent 平台。

本文希望回答四個問題：

• 微語為什麼要走向 Agent 平台
• 這套平台的目標結構應該是什麼
• 路線圖應該按什麼階段推進
• 每個階段要拆成哪些明確模組

一、為什麼微語需要一份 Agent 產品路線白皮書​

在傳統客服系統裡，很多關鍵動作仍然依賴人工串聯完成：

• 人工識別使用者意圖
• 人工搜尋知識答案
• 人工判斷是否建單
• 人工填寫客戶資訊與摘要
• 人工判斷風險、投訴和升級路徑
• 人工在會後補齊紀錄與沉澱經驗

這帶來三個長期問題。

1. 系統能力分散，流程無法閉環​

很多企業並不缺知識庫、工單、機器人、質檢和 CRM，但這些能力經常彼此割裂，客服坐席仍然需要在多個系統之間切換。

2. AI 價值停留在「輔助建議」層​

如果 AI 只能做潤飾回覆、生成摘要、推薦答案，它很難真正改變服務效率。企業更希望系統能進入流程，承擔標準化執行環節。

3. 經驗難以沉澱為組織資產​

很多高價值經驗存在於優秀坐席、歷史工單和專案實施中，但沒有被結構化回寫到系統中，導致知識和能力無法持續複用。

微語制定這份白皮書，本質上就是要解決這個問題：把原來散落在不同模組和不同角色裡的服務能力，重組為統一的 Agent 運行體系。

二、微語 Agent 平台的目標定義​

微語要建設的，不是一個簡單的「AI 客服外掛」，而是一套面向企業服務場景的 Agent 平台。它至少要具備以下四層能力。

1. 理解層​

負責理解使用者、上下文和當前服務階段，包括：

• 使用者身分識別
• 多輪上下文理解
• 意圖識別與問題分類
• 情緒識別與風險感知
• 歷史紀錄與會話狀態繼承

2. 執行層​

負責將理解轉化為動作，包括：

• 知識召回與答案生成
• 工單建立與欄位預填
• 服務流程節點推進
• 表單填寫與資訊抽取
• 風險提醒與升級觸發

3. 協同層​

負責人機協同和跨模組協同，包括：

• 坐席輔助建議
• 人工確認與接管
• Agent 與 Skill 編排
• Agent 與工作流聯動
• Agent 與工單、知識庫、CRM 聯動

4. 營運層​

負責把 Agent 變成可管理、可優化、可發布的產品能力，包括：

• Agent 配置管理
• Skill 配置與版本管理
• 效果評估與指標看板
• 失敗樣本回收與診斷
• 灰度發布與模板沉澱

三、微語 Agent 平台的總體模組拆解​

如果按產品建設視角拆解，微語後續可以分成八個核心模組。

模組 A：會話中樞 Agent​

這是整個 Agent 平台的入口層，也是最核心的調度中樞。

主要職責：

• 統一接收當前會話上下文
• 判斷當前服務場景和任務階段
• 決定調用哪個 Skill 或業務模組
• 管理會話內的執行順序和狀態

核心價值：

• 避免能力分散在多個頁面和按鈕中
• 讓訊息、工單、知識、工作流真正連起來

模組 B：Skill 能力中心​

Skill 不是簡單 prompt，而是可配置、可複用、可追蹤的執行單元。

建議首批建設的 Skill：

• 智慧回覆 Skill
• 智慧填單 Skill
• 智慧小結 Skill
• 知識導航 Skill
• 即時質檢 Skill
• 情緒識別 Skill
• 風險預警 Skill

後續擴展 Skill：

• 投訴處理 Skill
• 工單分派 Skill
• 線索識別 Skill
• 售後流程 Skill

模組 C：知識與經驗中台​

這不是單純的 FAQ 管理，而是面向 Agent 的知識供給層。

建議拆成兩類：

• 靜態知識：FAQ、文件、制度、產品說明、介面說明
• 動態經驗：歷史工單、優質話術、升級規則、澄清路徑、優秀案例

目標不是只讓 AI「知道答案」，而是讓系統逐步具備「知道怎麼處理問題」的能力。

模組 D：工單自動化引擎​

工單模組是最容易體現業務價值的落地點之一。

重點能力包括：

• 工單類型自動識別
• 標題和摘要自動生成
• 客戶資訊自動抽取
• 欄位自動預填
• 處理路徑自動推薦
• 人工確認後自動建立或流轉

這部分會直接影響坐席操作時長和複雜問題處理效率。

模組 E：即時質檢與風險控制​

如果只做事後質檢，很多問題已經造成影響。微語更適合建設即時干預型能力。

重點能力包括：

• 即時情緒識別
• 重複追問識別
• 長時間未解決識別
• 敏感詞與投訴風險識別
• 坐席提醒與主管升級機制

這部分會直接影響滿意度、投訴率和服務風險控制能力。

模組 F：坐席輔助工作台​

Agent 平台不應該繞開人工，而應該增強人工。

重點能力包括：

• 即時建議回覆
• 知識答案推薦
• 表單欄位推薦
• 下一步動作建議
• 會後小結生成

目標是把人工從重複勞動中解放出來，讓坐席更多做判斷和確認。

模組 G：回饋診斷與優化閉環​

這是 Agent 平台是否能持續成長的關鍵。

建議統一回收以下訊號：

• AI 建議是否被採用
• 使用者是否重複追問
• 是否觸發轉人工
• 是否出現投訴或風險事件
• 哪些欄位被人工修改
• 哪些知識答案命中後仍未解決問題

這些資料後續可以支撐：

• Skill 效果評估
• Agent 診斷報告
• 知識庫優化
• 版本對比和發布決策

模組 H：Agent 營運後台​

最終，Agent 必須成為後台可營運物件，而不是藏在聊天頁裡的隱式能力。

建議能力包括：

• Agent 列表與角色配置
• Skill 綁定與版本管理
• 租戶／工作組灰度發布
• 行業模板導入
• 執行指標看板
• 失敗樣本與優化建議面板

四、微語 Agent 路線圖的四個階段​

為了避免一開始就追求「大而全」，微語更適合按四個階段推進。

第一階段：坐席增強​

階段目標：先讓 AI 真正提升一線坐席效率。

建議交付內容：

• 會話意圖識別
• FAQ／知識召回優化
• 建議回覆
• 會後小結生成
• 工單欄位預填
• 基礎情緒識別

核心衡量指標：

• 平均回應時長
• 單次會話處理時長
• 工單錄入時長
• AI 建議採納率

階段價值：

• 快速體現 AI 投入產出
• 降低一線重複勞動
• 為後續 Agent 閉環累積基礎資料

第二階段：流程接管​

階段目標：讓 Agent 從「建議者」變成「執行者」。

建議交付內容：

• 會話中樞 Agent 初版
• 智慧填單 Skill
• 風險預警 Skill
• 知識導航 Skill
• 工單建立與流轉聯動
• 人工確認後的自動執行鏈路

核心衡量指標：

• 自動觸發執行次數
• 工單自動建立比例
• 人工確認通過率
• 重複操作減少比例

階段價值：

• 讓系統真正進入流程
• 把多個 AI 點能力串成任務閉環

第三階段：平台編排​

階段目標：把 Agent 從功能升級成平台能力。

建議交付內容：

• Agent 物件模型
• Skill 中心
• 工作流與 Agent 編排
• Agent 與知識／工單／CRM 的標準化聯動
• 角色化 Agent 配置

核心衡量指標：

• Skill 複用率
• 不同租戶配置複用率
• 新場景接入週期
• Agent 配置覆蓋率

階段價值：

• 提高平台可擴展性
• 降低行業化方案交付成本

第四階段：持續進化​

階段目標：讓 Agent 能夠基於回饋持續優化。

建議交付內容：

• 失敗樣本結構化回收
• Skill 診斷機制
• Agent 效果評估看板
• 優化建議生成
• 模板沉澱與灰度發布機制

核心衡量指標：

• 滿意度提升
• 轉人工率變化
• 投訴率變化
• 版本優化收益對比

階段價值：

• 形成產品壁壘
• 讓 Agent 真正成為可持續營運資產

五、每個階段對應的優先模組映射​

為了讓路線圖更易執行，可以把階段和模組做一個簡化映射：

這個順序的核心邏輯是：

• 先做最容易產生價值的坐席增強
• 再做真正進入流程的自動執行
• 然後建設可複用的 Agent 平台結構
• 最後做持續進化和營運閉環

六、微語在不同客戶場景中的落地優先級建議​

不同客戶群體的優先級會略有不同。

1. 政務與熱線場景​

優先模組：

• 工單自動化引擎
• 風險與投訴預警
• 知識導航 Skill

重點目標：

• 縮短分派時間
• 提升熱點問題回應效率
• 降低升級與投訴壓力

2. 金融與高合規服務場景​

優先模組：

• 即時質檢與風險控制
• 坐席輔助工作台
• 會話中樞 Agent

重點目標：

• 降低合規風險
• 提升複雜服務場景處理一致性

3. 零售、電商與售後場景​

優先模組：

• 知識與經驗中台
• 工單自動化引擎
• 會後自動沉澱

重點目標：

• 提高高峰場景承接能力
• 提高售後問題處理效率

4. 企業服務與 B2B 支援場景​

優先模組：

• Skill 能力中心
• Agent 營運後台
• 回饋診斷與優化閉環

重點目標：

• 支援複雜流程配置
• 支援跨租戶複製和行業模板沉澱

七、這份白皮書對微語意味著什麼​

微語接下來要建設的，不只是一個更聰明的客服機器人，也不只是一個整合了大模型的會話系統，而是一套真正能夠進入服務流程、參與任務執行、沉澱業務經驗、支援長期營運的 Agent 平台。

這也是為什麼我們需要把產品規劃拆成清晰階段，把能力拆成明確模組，再把每個階段的價值、交付內容和衡量指標寫清楚。只有這樣，微語的 Agent 路線才不會停留在概念層，而能真正轉化為產品能力、專案能力和平台能力。

如果說傳統客服系統解決的是「如何更快回覆」，那麼微語下一階段要解決的，是「如何讓系統和人一起完成服務工作，並且越做越好」。

延伸閱讀​

• 從「會思考、能執行」的數位員工，到微語的下一代客服 Agent 路線圖
• 從 SkillForge 看微語下一步：面向企業客服的自進化 Agent Skills
• 從成本中心到增長引擎：微語客服如何用 AI 與大數據重塑服務價值

DeepSeek-V4 帶來了什麼​

根據 DeepSeek 官方發布說明，DeepSeek-V4 預覽版重點帶來以下變化：

• 支援 1M 超長上下文，更適合長文件問答、複雜知識庫和多輪業務對話
• Agent 能力進一步增強，在程式碼生成、文件生成和工具調用場景中表現更強
• 提供更清晰的產品分層：deepseek-v4-pro 面向高品質複雜任務，deepseek-v4-flash 面向高性價比與更快回應場景

對於客服、智慧問答、知識庫檢索和自動化流程這類業務來說，長上下文和 Agent 能力的提升都非常關鍵。尤其是在需要持續理解歷史會話、工具調用結果和業務文件時，DeepSeek-V4 會比舊模型更穩定。

微語目前已支援的 DeepSeek 新模型​

在微語的模型配置中，DeepSeek 供應商下已提供以下模型：

也就是說，如果你此前已經在微語中使用 DeepSeek，現在只需要在 AI 模型配置頁把模型切換為 deepseek-v4-flash 或 deepseek-v4-pro，即可開始使用最新能力。

舊模型名棄用說明​

DeepSeek 官方已明確說明：

• deepseek-chat 將於 2026-07-24 停止使用
• deepseek-reasoner 將於 2026-07-24 停止使用

在目前過渡階段，這兩個舊模型名仍然可用，但它們主要用於相容舊配置：

• deepseek-chat 目前指向 deepseek-v4-flash 的非思考模式
• deepseek-reasoner 目前指向 deepseek-v4-flash 的思考模式

如果你正在新建機器人、工作組或租戶級 AI 配置，建議直接使用 deepseek-v4-flash 或 deepseek-v4-pro，不再繼續依賴舊模型名。

微語中的建議遷移方式​

如果你已經在生產環境使用 DeepSeek，建議按下面方式遷移：

1. 優先從舊模型名切換到新模型名​

將預設模型從下列舊值替換為新值：

• deepseek-chat -> deepseek-v4-flash
• deepseek-reasoner -> deepseek-v4-pro 或 deepseek-v4-flash

如果你的場景更看重回應速度和成本，優先使用 deepseek-v4-flash；如果更看重複雜推理、長鏈路任務和 Agent 表現，優先使用 deepseek-v4-pro。

2. 保持 base URL 不變​

DeepSeek-V4 的 API 接入方式沒有改變，仍然使用原有 DeepSeek API 地址：

https://api.deepseek.com

遷移時主要修改的是 model 參數，而不是接入地址。

3. 在微語後台完成切換​

你可以直接在微語管理後台中完成以下操作：

1. 登入管理後台
2. 進入 AI 模型配置頁面
3. 選擇 DeepSeek 作為模型供應商
4. 將預設模型切換為 deepseek-v4-flash 或 deepseek-v4-pro
5. 儲存並測試對話效果

整個過程不需要重新嵌入聊天程式碼，也不需要改動訪客端接入方式。

選擇建議​

如果你不確定該如何選擇，可以參考下面的實踐建議：

• 線上客服機器人預設首選 deepseek-v4-flash
• 複雜業務問答、知識庫深度問答、工作流助手優先選擇 deepseek-v4-pro
• 對歷史配置做相容保留時，可暫時保留 deepseek-chat 與 deepseek-reasoner，但應盡快遷移

總結​

隨著 DeepSeek-V4 發布，微語已經同步支援最新的 deepseek-v4-flash 與 deepseek-v4-pro。對於需要長上下文、複雜推理、Agent 協作和更高品質自動化客服體驗的團隊來說，這是一輪值得儘快完成的升級。

如果你已經在使用微語對接 DeepSeek，建議盡快把預設模型從 deepseek-chat 或 deepseek-reasoner 遷移到新的 V4 模型名稱，以避免後續棄用帶來的影響。

相關資源​

• DeepSeek-V4 預覽版：邁入百萬上下文普惠時代
• DeepSeek API 文件

這篇論文給出的答案很直接：不要只盯著模型本身，而要把 Agent Skill 當成一個可版本化、可診斷、可優化的資產，圍繞它建立「建立 - 執行 - 評估 - 診斷 - 優化」的閉環。

對微語來說，這個方向非常有價值。因為微語本身已經具備多模型接入、知識庫檢索、機器人路由、工作流配置、人工接管這些基礎能力，下一步真正拉開差距的，不會只是「接了多少模型」，而是誰能先把客服機器人做成一個會自我沉澱、會利用失敗持續進化的系統。

這篇論文到底解決了什麼問題​

SkillForge 聚焦的是企業級雲端技術支援場景，但它的核心矛盾和客服系統高度相似。

論文認為，企業 Agent 往往會遇到兩個長期問題：

• 初始技能寫得不夠貼近業務。通用的 Skill Creator 不理解企業內部知識、歷史工單、工具鏈和處理流程，所以生成出來的技能容易空泛。
• 技能上線後不會真正成長。線上每天都會累積失敗樣本，但很多系統並沒有把這些失敗系統性地追溯到技能缺陷，再回寫到技能定義裡。

這也是很多 AI 客服專案「展示很好看，生產越跑越虛」的根源。模型能力也許夠強，但真正約束回答品質的，往往是領域知識、澄清策略、工具調用方式、回覆風格，以及這些能力有沒有隨著線上回饋持續修正。

SkillForge 的核心方法​

論文把 Agent Skill 當成一個可進化的軟體資產。它的核心流程可以概括為五步。

1. 用領域上下文生成初始技能​

不是拿一個通用模板直接寫 SKILL.md，而是先從三類材料中抽取上下文：

• 歷史工單
• 技術文件或知識庫
• 人工專家常用工具與解決流程

然後再生成更貼近業務的初始技能。論文把這一層叫做 Domain-Contextualized Skill Creator。

2. 在線執行並持續收集壞樣本​

Agent 在真實任務中使用當前版本技能執行。只要發現輸出與專家參考答案不一致，或者人工沒有採用，就把這個 case 標記為 bad case。

這一步非常關鍵。因為自進化的起點不是「繼續調 prompt」，而是先持續穩定地定義和收集失敗。

3. 對失敗做多維歸因​

SkillForge 不是簡單地把失敗歸因為「模型答錯了」，而是拆成四個維度去分析：

• Knowledge：知識缺失、知識錯誤、知識衝突
• Tool：工具沒調、參數錯、結果理解錯
• Clarification：該追問沒追問、不該追問卻追問、追問方向偏了
• Style：語氣生硬、冗長、過冷、不符合客服場景

這一步的價值在於，它把「壞回答」變成了結構化缺陷，而不是一句抽象的「效果不好」。

4. 把失敗映射回技能定義​

論文裡的 Skill Diagnostician 會讀取壞樣本聚合報告和當前 SKILL.md，把問題具體定位到技能內容本身。

例如：

• 某類 FAQ 總是漏關鍵前置條件，說明故障排查步驟不完整
• 某類工單總是少調一個內部工具，說明工具調用規則沒寫清楚
• 某類場景下回覆太機械，說明風格要求或優先級不明確

這一步把線上效果問題，轉成了「應該修改技能的哪一段」。

5. 只做最小必要修改，生成下一版技能​

Skill Optimizer 根據診斷報告修改 SKILL.md 和 references，生成新版本技能，然後進入下一輪執行。

論文特別強調兩點：

• 盡量只做最小修改，避免破壞已有正確行為
• 整個技能資產要可追蹤、可版本化、可回滾

這其實已經非常接近現代軟體工程思路，而不只是提示詞工程。

為什麼這件事對微語尤其重要​

微語不是一個單點聊天機器人，而是一個同時覆蓋訪客端、客服端、知識庫、工單、工作流、音視訊和企業接入場景的客服系統。系統越複雜，AI 能力越不能只靠一個「大模型回答介面」來支撐。

從目前程式碼能力看，微語已經具備幾塊很重要的基礎。

1. 已有多模型與多供應商接入能力​

在模型供應商配置裡，微語已經支援 OpenAI、Anthropic、Gemini、DeepSeek、通義、OpenRouter、Dify、n8n、Ragflow 等多個供應商。這意味著微語已經具備「技能運行時可切換模型底座」的基礎，不需要從零開始設計模型抽象。

2. 已有知識庫檢索與 LLM 拼接鏈路​

目前機器人回答鏈路已經支援知識庫搜尋結果聚合，並把 FAQ 檢索結果轉成上下文交給 LLM。也就是說，論文裡「Domain Context」最核心的一塊，微語並不缺，只是今天它主要還是停留在「回答時注入知識」，還沒有進一步沉澱成版本化的技能資產。

3. 已有機器人路由與人工兜底機制​

工作組側已經具備「是否轉機器人」「離線時是否優先備選人工／備選工作組」「強制轉人工」等路由邏輯。這意味著微語天然適合做論文裡的人機協同模式，而不是把 Agent 直接放到無人監管的全自動鏈路裡。

4. 已有工作流和服務設定入口​

服務設定裡已經能看到 workflow、faqKbUid、inputAssociation、showFaqs 等配置項。說明微語不是沒有編排入口，而是下一步可以把「技能」提升為與 workflow、knowledge base 並列的正式配置物件。

5. 已有回饋實體雛形，但還不夠厚​

訊息回饋實體目前已經存在，但欄位和處理鏈路還比較薄。它很適合作為 SkillForge 式閉環的起點，但距離「結構化失敗記錄 + 自動診斷 + 自動優化」還有明顯距離。

結合微語現狀，下一步最值得做的升級方向​

如果把這篇論文轉成微語的產品與架構路線，我認為最值得優先做的是下面五件事。

一，把技能從隱式 prompt 提升為顯式資產​

今天很多客服機器人系統雖然也有「提示詞」，但它往往分散在機器人設定、工作組設定、知識庫、FAQ、預設回覆等多個地方。長期看，這會導致能力難以沉澱。

更合適的做法是把 Skill 定義成一個一等公民物件，至少包含這些部分：

• 指令層：適用場景、目標、邊界、澄清策略、回覆風格
• 知識層：FAQ、文件切片、術語、示例工單、常見故障樹
• 工具層：允許調用哪些工具、何時調用、輸入輸出約束
• 流程層：不同場景的處理順序、升級條件、轉人工條件
• 評估層：成功定義、失敗分類、人工回饋映射規則

這樣做之後，微語裡的 robot、workgroup、assistant、workflow 才能真正共享和複用同一套技能資產。

二，把失敗日誌升級成結構化 Failure Record​

如果沒有結構化失敗記錄，自進化就無從談起。微語下一步應該優先把以下訊號統一沉澱下來：

• 使用者是否繼續追問同一問題
• 使用者是否觸發「轉人工」
• 客服是否重寫了 AI 建議
• AI 回覆是否被坐席採納、部分採納或放棄
• 使用者是否點踩、投訴、低滿意度
• 工具調用是否失敗、超時或未命中

然後按照論文的四個主維度去歸因：Knowledge、Tool、Clarification、Style。這樣後面無論是做人工復盤、規則分析，還是做自動診斷，資料基礎才是統一的。

三，把知識庫升級成「技能知識庫」，而不只是 FAQ 檢索​

微語現在已經有 FAQ、向量檢索、來源引用，這是好基礎。但論文提醒了一個很關鍵的點：企業 Agent 的知識不只是「文件內容」，還有「怎麼處理事情」的經驗。

所以更值得做的是把知識源分成兩類：

• 靜態知識：FAQ、產品文件、介面說明、制度規則
• 動態經驗：歷史工單中的高品質解決路徑、澄清話術、升級判斷、常用工具組合

如果只做靜態 RAG，系統會回答「知道的內容」；如果把優秀工單和處置路徑也納入技能參考，系統才更接近「像資深客服一樣處理問題」。

四，引入技能診斷器與技能優化器​

這是論文最有啟發性的部分，也是微語現在最缺的一段。

微語完全可以在現有 AI 模組之上新增兩類背景任務：

• Skill Diagnostician：週期性讀取失敗樣本，輸出「哪些技能段落有問題」的診斷報告
• Skill Optimizer：在人工審核後，自動生成新的技能草案或 references 更新建議

注意這裡不一定要一步做到全自動上線。更現實的第一階段路徑是：

1. 自動生成診斷報告
2. 自動生成技能修訂草案
3. 由營運、質檢或管理員審核
4. 審核通過後發布新版本

這會比現在很多系統「人工看聊天紀錄，再手改 prompt」高效得多，也更可追蹤。

五，把技能營運做成後台可視化能力​

如果技能只是寫在文件裡，企業最終用不起來。微語更適合把它做成後台裡的營運物件：

• 查看技能版本歷史
• 對比兩個技能版本差異
• 查看每個版本上線後的命中率、轉人工率、滿意度變化
• 支援按租戶、工作組、機器人做 A/B 測試
• 支援按行業導入行業技能模板

一旦走到這一步，微語的競爭力就不再只是「有機器人」，而是「有一套可持續營運的企業 Agent Skill 平台」。

一個更現實的微語落地順序​

如果按照投入產出比來排優先級，我更建議分三期推進。

第一期：先把資料閉環打通​

• 補全訊息回饋實體與失敗記錄結構
• 統一記錄 AI 建議、人工採納、轉人工、使用者追問、使用者評價
• 建立基礎失敗分類看板

第二期：把技能變成正式配置物件​

• 在 robot settings、workgroup settings、agent settings 中引入 skill 配置
• 支援技能模板、技能版本、技能發布與回滾
• 將優秀 FAQ、歷史工單摘要、工作流節點說明沉澱到技能 references

第三期：引入半自動進化能力​

• 定期跑技能診斷任務
• 自動生成優化建議與新版本草案
• 審核後灰度發布
• 對比上線前後的核心指標變化

這條路線最大的好處是，不要求一開始就相信「AI 自動改技能一定靠譜」。它允許微語先把證據鏈、診斷鏈、審核鏈做好，再逐步把優化自動化程度提高。

SkillForge 給微語的真正啟發​

這篇論文最有價值的地方，不是又提出了一個新框架名字，而是把一個常被忽視的問題講清楚了：企業 Agent 的核心資產，正在從「模型參數」轉向「技能系統」。

誰能把領域知識、工具規範、工作流、失敗回饋、人工經驗沉澱成可進化的技能，誰就更有機會把 AI 從「能聊天」做成「能穩定解決問題」。

微語已經具備了這條路線的多個基礎模組。下一步如果能把知識庫、機器人、工作流、訊息回饋、質檢和後台配置真正串成一個 SkillForge 式閉環，那麼微語做的就不再只是一個接入大模型的客服系統，而會更接近一個面向企業服務場景的自成長 Agent 平台。

參考資料​

• SkillForge: Forging Domain-Specific, Self-Evolving Agent Skills in Cloud Technical Support
• 微語 AI 與大數據客服能力概覽

技術重構服務底層：AI 與大數據的核心應用​

AI 與大數據對客戶服務的革新，本質是透過數據驅動決策 + 智慧自動化執行，覆蓋服務全流程的關鍵節點，實現從「人力密集」到「技術密集」的轉型。

1. 大數據：構建客戶服務的「洞察引擎」​

大數據技術的核心價值在於打破數據孤島，實現用戶需求的精準預判與全生命週期管理。微語客服系統透過整合電話、網頁、APP、社群等多渠道數據，構建三維客戶畫像體系：

• 基礎屬性：年齡、地域、消費能力
• 行為偏好：瀏覽記錄、諮詢歷史、購買頻次
• 需求特徵：高頻問題、潛在訴求、情緒傾向

這種全景式洞察讓客服從「被動等待諮詢」變為「主動預判需求」——當用戶連續查看某類產品售後政策時，系統可提前推送操作指南；當高價值客戶出現服務頻次下降時，自動觸發專屬客服跟進，實現流失預警。

同時，大數據的即時分析能力優化了服務資源配置。透過對歷史話務量、諮詢熱點的統計建模，微語客服可精準預測高峰期（如電商大促、政策調整期）的服務需求，動態調配 AI 機器人與人工座席的比例，避免用戶排隊等待。

2. AI：打造客戶服務的「智慧執行中樞」​

如果說大數據是「眼睛」，AI 就是客戶服務的「大腦與手腳」，微語系統的 AI 能力已滲透到服務全流程：

智慧回應層​

基於大型語言模型（LLM）的 AI 客服實現 7×24 小時秒級回應，支援多模態互動（語音、文字、圖片），解決「簡單問題反覆問」的痛點。透過上下文感知實現多輪對話，避免機械式重複提問。

人機協同層​

當問題超出 AI 能力範圍時，系統自動生成對話摘要、預填工單欄位，讓人工座席「接手即戰」。智慧輔助模組可在人工服務過程中即時推送話術建議與合規提醒，幫助新人快速上手，大幅縮短培訓週期。

智慧運營層​

微語透過知識圖譜技術實現答案的權威更新與動態學習。當企業調整售後政策時，管理員只需上傳新文件，AI 便自動解析變更點並同步應答策略；同時從未解決問題中提煉新知識點，形成「服務—優化」的自循環。

核心價值：三重突破​

AI 與大數據在微語客服系統中的應用，已實現三重核心價值突破：

效率革命​

AI 機器人承擔 70% 以上的高頻簡單諮詢，人工座席聚焦複雜問題與情感溝通。經實踐驗證，首次解決率可提升 50%，客服運營成本顯著下降。

體驗升級​

全渠道無縫對接、個性化應答、秒級回應，讓用戶徹底擺脫「排隊等待」「重複說明」的困擾，用戶滿意度大幅提升。

價值重構​

客服不再是單純的售後環節，而是成為需求挖掘、業務轉化、產品優化的關鍵觸點——透過用戶對話數據反哺前端產品設計與行銷決策，真正將「成本中心」升級為「成長引擎」。

適用行業場景​

微語客服系統的 AI 與大數據能力，已廣泛適用於多個行業：

未來趨勢​

隨著技術的持續迭代，微語客服將持續演進，引領三大趨勢：

1. 多模態互動普及：AI 透過圖片、影片等形式實現「看圖診斷」「遠端指導」，進一步降低用戶溝通成本。
2. 隱私合規與數據安全並重：透過權限分級、數據加密等技術平衡服務體驗與用戶信任，滿足企業合規需求。
3. 從「需求回應」到「需求預見」：透過更深度的數據分析，在用戶提出問題前主動提供解決方案，實現「服務未呼，體驗已至」。

AI 與大數據正在重塑客戶服務的核心邏輯。微語客服系統不僅讓服務更高效、更溫暖，更將客戶服務從企業的「成本負擔」，轉變為驅動成長的「隱形引擎」，為各行業數位升級注入持久動力。

歡迎體驗微語客服系統，開啟您的智慧客服升級之旅。

概述​

多模态集成是指系统能够处理文本、图像、视频、音频等多种形式的信息输入，并将其转化为统一的知识表示，从而实现跨模态的信息理解与响应。微语系统集成了先进的多模态模型，使客服机器人能够：

• 读取并理解用户上传的图片内容
• 提取视频中的关键信息和场景
• 转录并理解音频内容
• 结合企业知识库，对多模态内容进行专业解答

视觉理解能力​

微语系统的视觉理解模块可以处理多种类型的图像内容，为用户提供智能分析和解答。

图像处理场景​

应用场景示例​

• 智能客服场景：用户上传产品图片，系统自动识别产品型号并提供相关信息
• 文档处理：将图像类文档解析为结构化文本，精准识别文字并提取表格信息
• 图像问答：识别图像中的人物、物体、场景等，并进行分类标记
• 数学题解答：识别并解答用户拍摄的数学题目，适用于各教育阶段
• 物体定位：在图像中准确定位特定物体，返回坐标信息
• 表单信息提取：从票据、证件、表单中提取关键信息并格式化输出

微语系统支持多语言文字识别，包括：中文、英语、日语、韩语、阿拉伯语、越南语、法语、德语、意大利语、西班牙语、俄语和葡萄牙语。

视频理解能力​

微语系统能够分析视频内容，提取关键信息，为用户提供更全面的服务支持。

视频处理功能​

• 场景识别：自动识别视频中的关键场景和内容
• 事件定位：定位视频中的特定事件并生成时间戳
• 内容摘要：生成视频关键时间段的文字摘要
• 视频问答：针对视频内容回答用户提问

视频应用场景示例​

• 教学视频分析：从教学视频中提取关键知识点
• 产品演示理解：分析产品演示视频，提取操作步骤和要点
• 视频故障诊断：识别设备故障视频中的异常状况

音频理解能力​

微语系统集成了先进的音频语言模型，能够处理多种音频输入并提供智能理解和分析。

音频处理功能​

• 语音转文字：将用户语音准确转录为文本
• 音频语义理解：理解语音内容的深层含义
• 情感分析：分析语音中的情感色彩和语气
• 音频事件检测：识别特定音频事件和场景
• 多语言支持：支持多种语言的语音识别和理解

音频应用场景示例​

• 客服语音交互：理解用户语音问题并给出专业回答
• 语音指令处理：执行用户通过语音发出的各类指令
• 会议记录整理：自动转录会议内容并提取关键信息
• 情感分析：分析客户语音反馈中的情感倾向

与知识库结合​

微语系统的多模态能力与企业知识库深度结合，实现了更加智能的用户服务体验：

1. 多模态输入理解：系统首先理解用户上传的图片、视频或音频内容
2. 知识库联动查询：将理解的内容与企业知识库进行关联查询
3. 专业解答生成：结合多模态理解与知识库信息，生成专业、准确的回答

这种结合使客服系统能够：

• 对用户上传的产品照片进行型号识别并提供相应的使用指南
• 分析用户提交的故障视频并给出针对性的解决方案
• 理解用户的语音描述并匹配知识库中的相关信息

总结​

微语系统的多模态集成能力大大拓展了智能客服的服务边界，使系统能够处理更加丰富的用户输入形式，提供更加全面、精准的服务。通过结合企业知识库，微语系统不仅能够"看懂"和"听懂"用户问题，还能给出专业的解答，真正实现智能化的客户服务体验。

Pellentesque elementum dignissim ultricies.

Pellentesque elementum dignissim ultricies.

Qwen3大模型介绍​

通义千问Qwen3是阿里云推出的大型语言模型，具有强大的理解能力和生成能力。Qwen3系列模型在多轮对话、文本生成、问答解析等方面表现出色，非常适合客服场景应用。

一、Ollama安装Qwen3​

Ollama是一个开源的大模型运行框架，可以在本地部署运行多种大型语言模型，包括Qwen3。下面是安装和配置步骤：

1. 安装Ollama​

根据您的操作系统，选择相应的安装方法：

MacOS:

curl -fsSL https://ollama.ai/install.sh | sh

Linux:

curl -fsSL https://ollama.ai/install.sh | sh

Windows: 从Ollama官网下载并安装Windows版本。

2. 拉取Qwen3模型​

安装完成后，通过命令行拉取Qwen3模型：

# 拉取Qwen3 5B模型
ollama pull qwen3:5b

# 如果需要更大参数的模型，也可以选择其他版本
# ollama pull qwen3:7b
# ollama pull qwen3:14b

3. 验证模型安装​

通过以下命令验证Qwen3模型是否安装成功：

ollama list

您应该能看到已下载的qwen3模型列表。

4. 启动Ollama服务​

确保Ollama服务正在运行：

# 在某些系统上，安装后会自动启动服务
# 如果没有自动启动，请使用以下命令
ollama serve

默认情况下，Ollama服务会在http://localhost:11434端口运行。

二、在微语管理后台设置Qwen3对话模型​

完成Ollama和Qwen3模型的安装后，我们需要在微语管理后台进行配置：

1. 登录微语管理后台​

访问您的微语管理后台，输入账号和密码登录系统。

2. 导航到AI设置​

在左侧导航栏中，找到并点击"AI助手"或"大模型设置"选项。

3. 添加Qwen3模型配置​

在AI设置页面中：

1. 点击"添加新模型"或"新建配置"按钮

2. 选择模型类型为"Qwen3"

3. 填写配置信息：

   • 模型名称：自定义一个便于识别的名称，如"Qwen3助手"
   • 接口地址：填写http://localhost:11434/api/chat（如果Ollama在远程服务器上，请替换localhost为相应IP）
   • 模型标识：输入qwen3:5b（或您安装的其他版本）
   • 温度参数：建议设置为0.7（可根据需要调整，较低值更精确，较高值更创造性）
   • 系统提示词：可以设置默认的AI人设，例如"你是微语客服系统的智能助手，请用专业、友善的口吻回答用户问题。"

4. 点击"测试连接"按钮，验证配置是否正确

5. 确认无误后，点击"保存"按钮

4. 设置为默认模型（可选）​

如果您希望将Qwen3设置为系统默认的AI对话模型：

1. 在模型列表中找到刚刚创建的Qwen3配置
2. 点击"设为默认"按钮或切换相应的开关

三、开始使用Qwen3进行智能对话​

配置完成后，您可以开始体验Qwen3赋能的智能客服功能：

1. 创建知识库（可选）​

为了让AI回答更加准确，您可以创建和维护特定领域的知识库：

1. 导航到"知识库"或"AI训练"模块
2. 点击"新建知识库"，输入名称和描述
3. 上传文档或手动添加Q&A对，丰富AI的专业知识

2. 测试对话效果​

您可以通过以下方式测试Qwen3的对话能力：

1. 在管理后台的"对话测试"功能中，输入问题进行测试
2. 通过客服端应用，模拟用户提问，验证AI回复效果
3. 通过访客端，体验实际用户视角下的AI交互

3. 对话效果展示​

以下是一些使用Qwen3进行智能对话的演示截图：

图1：用户咨询产品功能，Qwen3给出详细解答

图2：处理复杂问题时，Qwen3展现出强大的理解和推理能力

图3：Qwen3能够根据上下文提供连贯的多轮对话

四、优化和调整​

为了获得最佳的Qwen3对话效果，您可以进行以下优化：

1. 调整模型参数​

根据实际需求调整模型参数，如温度值、最大token数等，以平衡回答的创造性和精确性。

2. 优化系统提示词​

系统提示词对AI的行为有重要影响，您可以根据业务场景定制专业的提示词，引导AI表现出理想的对话风格。

3. 结合人工审核​

设置人工干预机制，对AI无法准确回答的问题进行人工接管，并将这些案例记录下来用于进一步训练和优化。

总结​

通过将微语客服系统与通义千问Qwen3大模型对接，您可以显著提升客服自动化水平和用户体验。本指南详细介绍了从安装Ollama、配置Qwen3模型到实际应用的完整流程。

随着您不断优化提示词和积累领域知识库，AI助手的表现会越来越符合您的业务需求，为客户提供更加专业、高效的服务体验。

如有任何问题或需要进一步的技术支持，请随时联系我们的技术团队。

希望本指南对您成功部署和使用微语+Qwen3智能客服系统有所帮助！

扫码登录实现流程

Here are a few tips you might find useful.

Simply add Markdown files (or folders) to the blog directory.

Regular blog authors can be added to authors.yml.

The blog post date can be extracted from filenames, such as:

• 2019-05-30-welcome.md
• 2019-05-30-welcome/index.md

A blog post folder can be convenient to co-locate blog post images:

The blog supports tags as well!

And if you don't want a blog: just delete this directory, and use blog: false in your Docusaurus config.

For example, use JSX to create an interactive button:

<button onClick={() => alert('button clicked!')}>Click me!</button>

Use a <!-- truncate --> comment to limit blog post size in the list view.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

...consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet