系統架構

架構設計的目標是把兩路異構資源——礦工節點供給的運行算力、第三方供給的大模型推理算力——抹平為一個統一的 Agent 運行環境。

七層架構

系統自上而下分為七個層次，每層職責單一、介面清晰：

表　xmuse 七層架構

層次	組件	關鍵能力
應用層	Agent 模板市場、控制枱、SDK	用戶與開發者的唯一入口
運行時層	任務編排器、沙箱、工具鏈、長期記憶	Agent 的規劃—執行—交付閉環
調度層	任務分派、實例調度、配額管理	把任務匹配到合適的算力節點
運行算力層	分佈式節點、容器運行時	提供 Agent 虛擬小主機的 GPU、CPU、儲存與頻寬
模型接入層	統一模型網關、多模型路由、credit 計費	聚合第三方大模型，輸出統一計量單位
共識與獎勵層	代幣鑄造、質押、計費、回購銷燬、Merkle 承諾	xmuse 專用鏈（自建）
合規對接層	候選外部支付、身份與交易服務	候選服務需確認接入，項目主體責任另行評估

運行時層：xmuse 的核心資產

運行時層決定用戶體驗的上限，是否具備「常駐」能力由這一層決定：

• 持久工作區——每個項目擁有獨立的持久化工作區，會話之間不重置，上下文、文件與中間產物跨會話留存；
• 事件驅動觸發——Agent 不僅可被時鐘觸發，還可被外部信號觸發（郵件到達、數據變化、日曆更新），支撐真正的異步自治；
• 精益加載——按任務動態裝載能力模塊，而非預載全部工具，這是控制 Token 成本的關鍵；
• 統一工具鏈——瀏覽器、代碼執行、文件處理、外部 API 調用統一抽象，屏蔽底層節點差異；
• 算力配額感知——運行時實時讀取帳號的配額餘量，在配額臨界時提前告警並按策略降級任務，避免任務中途失敗。

詳見 Agent 雲主機。

運行算力層：只承載 Agent 虛擬小主機

運行算力層只承載一件事：Agent 的虛擬小主機——持久工作區、沙箱進程、工具鏈執行與長週期任務調度。

這條邊界是刻意劃的

大模型推理不落在礦工節點上，而是走獨立的模型接入層。把「輕量但常駐」與「重型但突發」兩類負載分開後，礦工只需為可預測的常駐負載配置硬件，模型側則由專業服務商承擔。

節點由三類角色構成，責任分離參照行業成熟做法。三類角色的獎勵都只有代幣這一種資產：

表　三類算力節點

節點類型	職責	激勵來源
計算節點	執行 Agent 的沙箱任務與常駐負載，提供虛擬小主機	代幣（按時空證明有效權重佔比分配）
驗證節點	抽檢在線率、算力真實性與任務成功率，出具時空證明	代幣（同上，另計驗證權重）
索引節點	匹配任務與節點、維護路由與信譽	代幣（由網絡運維預算按代幣計價發放）

模型接入層：不自研模型，但必須自建的一層

模型接入層對外只暴露一個統一網關，對內聚合多家第三方模型服務商：

• 統一接入——同時接入多家主流大模型服務商與模型版本，按任務類型、成本與可用性自動路由，單家服務不可用時自動降級切換；
• 統一計量——把不同廠商按 token、按次、按算力等口徑各異的計費方式，換算為平台統一的 credit，用戶與開發者只面對一種計量單位；
• 訂閱供給——credit 以訂閱方式提供，分檔位與有效期，實際閒置額度成本以套餐條款為準；訂閱收入扣除模型採購成本後的價差，構成平台的第二條收入流；
• 成本緩衝——平台以批量採購與多供應商比價平抑單價波動，把議價能力轉化成用戶的成本優勢。

營運主體是基金會的商業公司

模型採購涉及商業合約、發票、SLA 與供應商結算，屬於典型的商業營運事項，與鏈上經濟循環天然分離：

事項	責任主體
Agent 運行環境的代幣發行與結算	xmuse 專用鏈
模型採購合約、發票、SLA、供應商結算	基金會的商業公司
credit 定價、訂閱與結算	商業公司擬按服務條款與費率處理
稅後收入回注協議	商業公司按約定比例執行（見費用分配）

共識與獎勵層：xmuse 專用鏈

獎勵的發行與承諾承載於一條自建的專用鏈。採用專用鏈是原方案選擇，目標是適配週期獎勵與異構節點。該選擇仍需與其他方案比較承諾、領取、儲存和營運成本。住宅節點不必承擔出塊職責；gas 獲取、代付及領取成本應單獨說明，不能僅通過改用項目代幣宣稱沒有成本。

這條鏈擬遵循三條設計原則：

• 共識與算力解耦——出塊權由驗證者的質押量決定，礦工的算力權重只決定獎勵分配，礦工不承擔出塊義務；
• 鏈級週期鑄造——每週期先鑄造一筆全網發行量，再按有效權重佔比分配，發行量由當期真實收入調節（見發行機制）；
• Merkle 批量承諾——全網權重在鏈下計算並生成 Merkle 樹，每週期只上鍊一筆根哈希，礦工自持證明按需領取，批量承諾提交成本降低；領取與證據成本仍需計入。

建設路徑採取兩階段：先經 RaaS 部署一條 EVM 兼容鏈跑通最小閉環，再遷移至主權鏈。驗證者的席位規則見驗證者。

合規對接層：身份、支付與上幣

合規與出入金不在 xmuse 自建，而是對接持牌生態既有能力：Agent 的鏈上身份擬評估原方案提及的 ZKID 候選服務，機器間支付擬評估原方案提及的 HSP 候選服務，交易通道為擬對接方向，需平台確認。這一選擇降低了自研合規成本，相關主體仍須完成自身業務的合規評估。

本層是身份、支付與出入金的候選對接邊界，不承載獎勵的鑄造與分發，也不把項目自身合規責任轉移給外部機構。詳見與 HashKey 生態的協同。

相關內容

• 參與者與角色——誰在系統裏扮演甚麼角色
• 時空證明——算力真實性如何被驗證
• 費用分配——兩條收入線如何分帳

常駐服務的可靠性與數據邊界

“跨會話保留工作區”是產品目標，不自動錶示節點故障時零數據丟失。以下項目尚需提供實際方案、測試證據與服務條款：

事項	發佈前需要明確
故障與遷移	節點掉線檢測、實例重建、容量預留、恢復目標 RTO 和數據丟失窗口 RPO
持久數據	副本/備份範圍、故障域、恢復演練、儲存與跨區費用
權限與密鑰	宿主節點可見範圍、密鑰託管、隔離邊界、日誌脫敏與審計
用戶退出	工作區導出、保留和刪除期限、贖回後實例停止順序
服務承諾	規格、地域、可用性統計口徑、支援渠道、補償與免責範圍

候選隔離或加密手段必須說明能夠防護的威脅與剩餘信任，不能僅以“容器”或“去中心化”推出數據安全。生產入口和實現狀態見閱讀前須知。