龙芯信创部署：芯语 CAP 应用商店的设计思考

测试环境：龙芯 3A6000 / 2K3000，LoongArch64，AOSC / openKylin

一、一个真实的部署场景

2025 年初，某信创单位在龙芯 3A6000 上部署 AI 编程助手。流程如下：

# Step 1: 找安装包 → 没有龙芯版本
# Step 2: 找源码 → 依赖链 27 个库，其中大量没有 LoongArch 预编译支持
# Step 3: 交叉编译 → 工具链版本不匹配，折腾 3 天
# Step 4: 终于跑起来了 → 启动 15 秒，界面卡顿，CPU 占满
# Step 5: 发现缺少 Python 环境 → 回到 Step 1

这是龙芯信创部署的真实日常。一个 AI 工具的部署成本，超过了工具本身的使用成本。

二、为什么现有方案不行？

信创生态的痛点不是"软件少"，而是**“软件到了龙芯上就变味”**：

方案	优势	问题
应用商店（统信/麒麟）	基础办公软件齐全，系统集成度高	AI 工具较少，第三方应用上架流程长
Docker / Podman	环境隔离性好，分发标准	龙芯镜像少，交叉编译成本高，x86 镜像无法直接运行
pip / npm / cargo	生态庞大，社区活跃	大量包无 LoongArch 预编译，源码编译可能遇到依赖链断裂
自行移植	完全可控，可深度优化	每个项目重复踩相同的编译坑，维护成本高
Electron 应用	跨平台一致性好，Web 技术栈	在龙芯上启动慢、内存占用高、UI 渲染不如原生流畅

但问题的根源在于：龙芯需要一个原生的、面向 AI 时代的软件分发和运行环境，而不是把 x86 的方案硬搬过来。

三、底层解决逻辑：应用商店 ≠ 下载器

芯语 CAP（Xinyu-CAP）不是传统意义上的"应用商店"。它的设计围绕三个核心问题展开：

3.1 应用怎么来？

芯语 CAP 的应用清单硬编码在源码中，通过 get_builtin_apps() 函数定义。每个应用的 AppInfo 结构体包含完整的元数据：

pub struct AppInfo {
    pub id: String,
    pub name: String,
    pub display_name: String,
    pub description: String,
    pub version: String,
    pub author: String,
    pub license: String,
    pub category: AppCategory,   // Agent / Tool / Gateway / Plugin / System
    pub status: AppStatus,
    pub is_installed: bool,
    pub download_url: String,
    pub install_dir: String,
    pub executable: String,      // 启动命令
    pub port: Option<u16>,
    pub icon: Option<String>,
    pub process_id: Option<u32>,
}

以 Git Panel 为例，其真实定义如下：

AppInfo::new(
    "git_panel",
    "git-panel",
    "Git Panel",
    "轻量级局域网 Git 仓库与 CI/CD 管理平台。提供类 GitHub 的 Web 界面...",
    "2.2.7",
    "H076lik",
    "LGPL-3.0",
    AppCategory::Tool,
    "npm",   // 通过 npm 全局安装
    "git-panel",
    "git-panel",
    Some(3456),
)

应用来源分为三类：

• npm 安装：Git Panel、OpenClaw、Flowise 通过 npm install -g 或 npx 安装
• 二进制下载：XinyuREG、Browser Bridge、XinyuToolkit、Crush-Zh 直接从 GitCode Releases 下载 loongarch64 二进制
• tar.gz 解压：Git Panel Client 下载压缩包后解压到应用目录

值得注意的是，上架的 8 款应用中，5 款由 H076lik 原创开发（Git Panel、XinyuREG、Git Panel Client、Browser Bridge、XinyuToolkit），Crush-Zh 为官方版本的龙芯适配增强版，仅 OpenClaw 与 Flowise 为第三方开源工具集成——属于典型的"自产自用"（dogfooding）。

3.2 应用怎么跑？

采用 Firejail 沙箱 + 进程生命周期管理 的双层隔离：

用户启动应用
  → firejail 创建沙箱环境（网络/文件系统/进程隔离）
  → 芯语 CAP 监控进程状态（PID、CPU、内存）
  → 应用退出后沙箱自动销毁
  → 状态持久化到 ~/.cache/xinyu-cap/，支持崩溃恢复

Firejail 沙箱的集成代码在 firejail.rs 中实现，核心逻辑不到 200 行：

pub fn run_in_sandbox(app_name: &str, command: &str) -> Result<Child> {
    let sandbox_profile = format!("/etc/firejail/{}.profile", app_name);
    let args = if Path::new(&sandbox_profile).exists() {
        vec!["--profile=", &sandbox_profile, "--", command]
    } else {
        vec!["--net=none", "--private", "--", command]
    };
    // 启动 firejail 进程，返回 child 句柄供主循环监控
    Command::new("firejail").args(&args).spawn()
}

另外发现在2k3000上面会禁用沙箱，不过功能运行正常。

3.3 应用之间怎么协作？

芯语 CAP 的核心理念是 “应用商店即集成平台”。上架应用可选择通过 MCP（Model Context Protocol）协议暴露接口供其他工具调用。用户在芯语 CAP 中安装 Crush（终端 AI）后，配置Crush 的大模型API Key后可以让其自发现安装的 XinyuREG（知识库）和 Browser Bridge（浏览器）的 MCP 工具，无需人工手动配置。当然，openclaw也可以。

四、架构思考：为什么用 Rust + Iced？

芯语 CAP 选择 Rust + Iced（而非 Electron 或 Qt）的原因很直接：

1. LoongArch 原生编译 — Rust 1.85+ 官方支持 loongarch64-unknown-linux-gnu 目标，无需任何补丁
2. 内存可控 — iced 基于 wgpu/tiny-skia 渲染，无 V8 引擎、无 GC，在龙芯 3A6000 上实测内存占用稳定在 ~50MB
3. 启动速度 — 原生二进制，无 JIT 预热，在龙芯 3A6000 上实测冷启动约 0.8 秒
4. Firejail 天然兼容 — Rust 无动态链接依赖链，沙箱策略简单

五、现状与展望

芯语 CAP 当前已上架 8 款应用，覆盖 AI 智能体、知识库管理、CI/CD、浏览器自动化等场景。所有应用均为龙芯 LoongArch64 原生适配。

核心结论：信创部署的瓶颈不是硬件性能，而是软件分发的效率。芯语 CAP 的解法是构建一个面向龙芯的、原生编译的、MCP 互联的应用生态。

• 项目地址：https://gitcode.com/XinyuCAP/Xinyu-CAP
• 官网：https://xinyucap.upma.site/

---

生态矩阵

芯语 CAP 是面向龙芯 LoongArch 的开源生态入口，以下项目共同构成完整的本地优先开发工具链：

项目	定位	仓库
Xinyu-CAP	龙芯 AI 智能体应用商店	GitCode
browser-bridge	浏览器自动化工具（MCP 兼容）	GitCode
XinyuREG	AI Agent 记忆外骨骼（纯本地知识库）	GitCode
XinyuToolkit	开发者一体化工具箱	GitCode
git-panel	本地 Git 托管 + CI/CD	GitCode
GitPanelClient	Git Panel TUI 桌面客户端	GitCode

项目开发者 H076lik（B站 076lik）| 演示：生态总览 · XinyuToolkit 介绍