聯通元景萬悟：把 FDE 交付鏈路搬進一個 Go 平台
China Unicom's Yuanjing Wanwu Agent Platform is an enterprise-grade, multi-tenant AI agent development platform. It helps users build applications such as intelligent agents, workflows, and rag, and also supports model management. The platform features a developer-friendly license, and we welcome all developers to build upon the platform.
秒懂
- 它是什麼？
- 元景萬悟（wanwu）是中國聯通開源的企業級多租戶 Agent 開發平台，Apache-2.0 授權，主體用 Go 撰寫。它的賣點不是單一 Agent 框架，而是把 RAG、本體推理、工作流、GUI 操作與 Skill 開發堆在同一套可交付的工具鏈裡。
- 適合誰用？
- 元景萬悟適合已經有明確企業交付場景、需要多租戶隔離與私有化部署的團隊，尤其是承接客戶現場專案的 FDE 型組織；如果你的需求只是單一 RAG 問答或個人實驗，這套平台的部署重量與模組耦合會是負擔。導入前先確認三件事：Go 版本是否達到 README 標示的 >= 1.24.0、GUI Agent 的沙箱容器在你的環境能否取得映像、以及 Dify 知識庫 API 匯入後檢索結果是否符合預期。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 12 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是交付問題，不是模型問題
多數 Agent 框架的預設讀者是個人開發者：裝一個 SDK，寫幾十行 Python，接上自己的 API Key 就能跑。元景萬悟的定位明顯不同。README 把它描述為 all-in-one 的企業級平台，並反覆提到一個角色：Forward Deployed Engineer（FDE）。這個詞在中文技術圈還沒有穩定譯法，大致對應「駐場交付工程師」，工作內容是把 AI 能力嵌進客戶既有系統，並在客戶現場把專案跑通。
平台要解決的痛點因此不是「怎麼呼叫 LLM」，而是「怎麼把 RAG、結構化資料推理、流程編排、老舊系統操作這幾件互不相干的事，收斂成一套能重複交付的工具鏈」。README 用五個核心能力模組來回應：RAG 知識庫 Agent、本體（Ontology）Agent、工作流 Agent、GUI Agent、以及通用 Agent 加 Skill 開發。這五塊並非平行的功能清單，而是對應不同類型的客戶現場需求：文件散亂、資料是結構化的、流程需要合規、系統沒有 API、以及需要把前四者串成一個對話入口。
判斷誰該看這個專案，關鍵在「多租戶」三個字。企業級平台意味著同一套部署要服務多個業務線或多家客戶，權限、知識庫、模型都要隔離。這是單機 Agent 框架通常不處理的層級，也是這個專案相對昂貴的地方。
五個能力模組各自綁定了什麼技術選擇
RAG 模組的規格寫得最具體。README 稱支援 12 種檔案格式與 URL 抓取，OCR 與 MinerU 模型可私有化部署，檢索側提供多模態檢索、串接式與自適應切塊、智慧排序、圖文生成與來源引用。這裡有一個值得注意的取捨：MinerU 是外部模型，把它列為可私有部署，等於承認高精度解析在純規則管線下做不到，使用者得額外承擔一份模型部署成本。
GraphRAG 是這一模組的第二層。README 說內建 UniAI-GraphRAG，走領域本體建模，用於跨文件摘要與多跳推理，並自稱 industry-leading F1 score。這類自評數字沒有第三方複現，我不會把它當成選型依據；真正有價值的是它承認了純向量檢索在跨文件彙總上的不足，並給出本體建模這條路。
本體 Agent 處理的是結構化資料。README 的說法是「打破 LLM 只懂文字的侷限」，做法是從企業資料與文件中自動建構業務知識網路。這裡的關鍵字是「自動建構」，它同時是賣點也是風險：自動生成的知識網路若與實際業務語義有偏差，除錯成本會落在交付工程師身上。
工作流 Agent 走低程式碼路線，README 列出畫布內建條件分支、API、LLM、知識庫、程式碼、MCP 等節點，支援端到端除錯與效能分析。GUI Agent 則是完全不同的思路：不接 API，直接讓 AI 看畫面、點介面，並為每個 bot 開一個隔離的 Docker 容器執行 UI 操作。至於通用 Agent，README 強調「零程式碼 Skill 呼叫」與「一句話建立 Skill」，把平台內既有應用一鍵轉成 Skill。
三種部署路徑對應三種權限等級
README 把部署方式分成三條，這個切法比功能清單更能說明平台的設計意圖。
第一條是開箱即用的視覺化平台，不做開發，直接在介面上建 Agent、工作流與問答。適合現場快速驗證。第二條是 RESTful API，README 稱之為 BaaS，用來嵌進 OA、CRM、ERP，並附帶細粒度權限控制。這一條的假設是客戶已有成熟系統，AI 只作為能力被呼叫。第三條是 Skill 加 UniClaw 專用客戶端，針對高權限場景，例如本機 PC 控制、釘釘訊息，由 FDE 開發 Skill 後透過 UniClaw 執行跨系統操作。
三條路徑的權限模型是遞進的：平台內操作、系統間 API 呼叫、本機高權限操作。最後一條最敏感，也最難標準化，因為它直接碰觸使用者的桌面與內部通訊工具。README 給出的 UniClaw 下載位址是 maas.ai-yuanjing 開頭的網址，內容在提供的材料中被截斷，實際取得方式需要自行確認。
值得注意的是 GUI Agent 的下載連結指向百度網盤，並附帶提取碼。對需要在內網或受監管環境部署的團隊來說，這是一個需要提前規劃的環節：二進位檔的取得管道與平台的 Apache-2.0 授權是兩件事。
跑起來之前要對齊的版本與依賴
README 的徽章明確標示 Go 版本要求為 >= 1.24.0。這是硬性門檻，低於此版本的建置環境無法直接編譯。專案主語言為 Go，預設分支 main，最新發布為 v0.6.4，時間標記為 2026-09-04，往前還有 v0.6.2 與 v0.6.1，間隔分別約兩個月與一週。從版本節奏看，v0.6.x 系列仍在密集迭代。
提供的材料中，Quick Start 章節的實際內容被截斷，我無法給出確切的啟動指令、環境變數或 compose 檔案名稱。這一點必須說清楚：如果你需要的是「複製三行指令就能跑」的評估，現有材料不足以支撐，得直接進倉庫看部署文件。
可以從 README 確認的設定面資訊有兩處。一是 RAG 模組提到 OCR 與 MinerU 模型支援私有部署，意味著存在對應的模型端點設定。二是外部知識庫相容性，README 說明支援以 API 匯入在 Dify 中建立的知識庫，供 Agent、對話與工作流檢索。這代表平台在知識庫層留了外部介面，而不是要求所有資料都先進它的儲存。
工作流畫布列出的節點類型（條件分支、API、LLM、知識庫、程式碼、MCP）可以視為設定面的縮影：每一類節點背後都對應一組需要填寫的參數。這些鍵名在 README 中沒有展開，需以倉庫內的實際設定檔為準。
多租戶與 GUI 沙箱帶來的實際代價
這個平台最容易被低估的成本有兩項。
第一是多租戶本身。多租戶不是一個開關，它意味著每個租戶的知識庫、模型憑證、工作流定義、Skill 都要在儲存與執行時隔離。企業級平台通常還要處理租戶層級的配額與稽核。README 對這部分只有一句 fine-grained permission control，沒有展開隔離粒度是到租戶、到應用還是到單一知識庫。對打算用同一套部署服務多個客戶的團隊，這是選型時必須先問清楚的問題，因為它決定了資料外洩的邊界畫在哪裡。
第二是 GUI Agent 的沙箱。README 說每個 bot 使用隔離的 Docker 容器執行 UI 操作。容器化確實比直接在宿主機上跑點擊腳本安全，但代價是每個 bot 都要一份執行環境，還要處理容器內如何看到目標應用畫面、如何處理需要圖形介面的桌面環境。在無圖形介面的伺服器上，這條路徑的可行性需要實測。
還有一個容易被忽略的限制：GUI Agent 走的是視覺與點擊，這條路徑對介面改版極度敏感。目標系統換一次版型，原本的點擊座標或視覺定位就可能失效。README 把它定位為解決「沒有 API 的遺留系統」，這個定位是誠實的，但也意味著它本質上是一層脆弱的適配層，適合穩定、少改版的內部系統，不適合高頻迭代的 SaaS 介面。
與 Dify 的關係不是替代而是接取
在中文圈的 Agent 平台選型裡，Dify 是最常被拿來對比的對象。元景萬悟對 Dify 的態度很有意思：README 明確寫著支援以 API 匯入在 Dify 中建立的知識庫，供本平台的 Agent、對話與工作流檢索。
兩者的路線差異在於重心。Dify 從 LLM 應用編排起步，知識庫與工作流是應用的一部分，部署相對輕，社群版本對個人與小團隊友善。元景萬悟從企業交付起步，把多租戶、私有化模型部署、GUI 操作、Skill 分發都納入範圍，代價是整套系統的重量。前者讓你先跑起來，後者讓你交付得出去。
這個差異直接反映在整合方向上。元景萬悟願意讀取 Dify 的知識庫，說明它把自己放在更上層的交付位置：客戶既有的 Dify 資產不必丟棄，可以被納入更大的平台。反過來，如果你的團隊已經用 Dify 跑通了主要場景，且沒有多租戶與 GUI 操作的需求，切換到元景萬悟的收益有限，遷移成本卻不小。
如果需求集中在知識庫問答，另一個方向是直接使用向量資料庫搭配自建檢索層，省去平台層。這條路的代價是要自己處理切塊、排序與引用，正好是元景萬悟聲稱已經做完的部分。
授權、維護與升級的現實面
專案採用 Apache-2.0，README 也自稱 commercial-friendly licensed。Apache-2.0 允許商業使用、修改與再發布，並附帶專利授權條款，對企業內部部署與二次開發是相對寬鬆的選擇。需要留意的是授權只覆蓋倉庫內的程式碼，README 中提到的 MinerU、OCR 模型、以及透過百度網盤取得的 GUI Agent 客戶端，各自受其原始授權約束，這部分不在 Apache-2.0 的範圍內。以上是授權條款的技術性描述，不構成法律意見。
維護成本可以從版本節奏推估。v0.6.1 到 v0.6.2 相隔約一週，v0.6.2 到 v0.6.4 相隔約六週，且 v0.6.4 與最後推送時間同為 2026-09-04。這說明專案處於活躍開發期，好處是問題修得快，代價是介面與設定可能變動，跟版升級需要預留測試時間。對把平台嵌進客戶系統的 FDE 來說，鎖定特定版本並記錄該版本的設定鍵是務實做法。
還有一項維護面的判斷：這個平台的能力邊界橫跨檢索、推理、編排與桌面自動化，任何一塊出問題都會反映在整體交付上。團隊需要具備 Go 的除錯能力，以及對 Docker 與模型部署的基本掌握。若團隊只有 Python 背景且無運維人力，這個專案的長期持有成本會比預期高。
編輯結論
元景萬悟適合已經有明確企業交付場景、需要多租戶隔離與私有化部署的團隊，尤其是承接客戶現場專案的 FDE 型組織；如果你的需求只是單一 RAG 問答或個人實驗，這套平台的部署重量與模組耦合會是負擔。導入前先確認三件事：Go 版本是否達到 README 標示的 >= 1.24.0、GUI Agent 的沙箱容器在你的環境能否取得映像、以及 Dify 知識庫 API 匯入後檢索結果是否符合預期。
社群筆記