Modly 深度研究
> Local AI-powered 3D mesh generation from images —— 本地、开源、以 GPU 跑开源 AI 模型的「图生 3D」桌面应用
>
> 研究对象：lightningpixel/modly（本地克隆 C:UserslinkeWorkBuddy智柴modly-researchmodly）
> 研究时间：2026-08-14 ｜ 四路专项 Agent 并行深读 + 代码级交叉核证 + 外源（GitHub API / Releases / shields / WebSearch）核实
—
〇、费曼视角 · 一句话讲清
设想市面有一堆开源「图生 3D」的菜谱（Hunyuan3D、TripoSG、Trellis2……），各自要你先配齐灶台、买齐料、背熟火候，方能开火。普通人望而却步。
Modly 就是那间「双击即开的中央厨房」：Electron 当门面，内嵌一个绿色 Python 当灶具，把各家菜谱收进菜单（扩展系统），灶火是你自家的 GPU。你传张照片，它按菜谱现炒出一只 3D 模型（.glb），全程不出你家门（隐私本地）。
一句话：ComfyUI 是「给你食材和灶，自己搭厨房」，Meshy/Tripo 是「上馆子（云端 SaaS）」，Modly 是「把开源菜谱 + 自家灶 + 可视化流水线，打包成一个普通人能双击装好的厨房」——本地 AI 3D 的「发行版（distribution）」。
然则天下无免费之炊：厨房虽好，你得自备 GPU 灶、联网把食材（模型权重）先搬回家、且炒出来的菜色，上限取决于你买的料（本地模型质量）。更有一桩隐忧——这厨房允许你从任意 GitHub 仓库「装新菜谱即执行」，门禁只查「是不是 github.com 来的」，不查菜谱本身安不安全。此乃后文 PK 之主战场。
—
一、它到底是什么（侦察结论 + 事实校正）
1.1 基本档案
| 项 | 内容 |
|---|---|
| 定位 | 本地、开源、图生 3D 网格之桌面应用（Electron + React 前端 + Python/FastAPI 后端，全跑于本机 GPU） |
| 作者 | Lightning Pixel（lightningpixel 组织，核心疑似 1–2 人） |
| 首发 | 2026-03-17（GitHub created_at） |
| 当前版本 | v0.4.1（2026-07-16；release 自题 "Modly Beta"，诚实早期定位） |
| 实现 | 前端 TypeScript（Electron+Vite+React+React-Three-Fiber+@xyflow/react 节点画布）；后端 Python（FastAPI，端口 8765）；MCP server + stdlib-only CLI |
| 平台 | Windows / Linux / Apple Silicon macOS only（Intel Mac 明确不支持） |
| GitHub | 5,541 星、582 fork、52 open issues、47 subscribers（GitHub API，2026-08-14 实测）；官网 modly3d.app；独立 Discord |
| 许可 | 实质 MIT（可闭源商用）。附带一段 fork 署名「善意请求」，致 GitHub 自动分类为 NOASSERTION，不影响宽松性 |
1.2 三处事实校正（读码前极易被带偏）
| 常见说法 | 核证结论 | 依据 |
|---|---|---|
「默认模型是 TripoSR（stabilityai/TripoSR，改 services/model_manager.py）」 | 失实三重：仓库内无任何 TripoSR 生成器；services/model_manager.py 文件不存在；services/generators/ 仅有 base.py 与 __init__.py，零内建生成器。此说出自过时之 api/README.md | api/services/generators/ 目录、api/README.md:36-38 |
「代码默认 sf3d（Stable Fast 3D）」 | 半真：generator_registry.py:165 确写 os.environ.get("SELECTED_MODEL_ID", "sf3d")；但 Electron 恒设该 env（空串），实际行为回退到「加载用户安装的第一个扩展」；且 sf3d 是 HF gated 模型（需 token），主 README 扩展表竟未列它 | api/services/generator_registry.py、README.md 扩展表 |
「扩展经 public_key.pem 做签名校验」 | 证伪（关键）：api/resources/public_key.pem 是孤儿文件（113 字节，全代码零引用）；requirements 里的 cryptography 依赖在 api/ 内亦无 sign/verify 用法；下载链路搜遍无 hashlib/checksum/integrity/signature。当前无任何供应链完整性校验（详见第四章） | 代码级 grep 核实（见 §4.2） |
| 「runs entirely on your GPU / 全本地」 | 推理确 100% 本地、无云端 API；但「全本地」≠「完全离线」：首次必联网从 HuggingFace 拉权重，扩展从 GitHub 拉取，Agent 路由依赖本地 Ollama。离线仅在「下完权重、装好扩展」之后成立 | api/routers/model.py、api/routers/agent.py、各 agent 报告一致 |
| 「本地 × 开源 × 桌面，独一份」 | 成立：检索未见第二个「打包好、开箱即用、全本地、图生 3D」桌面 App。裸模型仓库（Hunyuan3D/TRELLIS/TripoSR）与需自搭的节点平台（ComfyUI）皆非同类 | WebSearch 竞品版图（见第五章） |
> 结论：Modly 是一个「模型无关宿主」——二进制里不写死任何模型权重与推理代码，靠扫描 EXTENSIONS_DIR 动态注册扩展。所谓「默认模型」在 api/README、代码常量、扩展宣传表三处各说各话；真实默认是「你装的第一个扩展」。文档链已明显落后于代码与扩展生态。
1.3 时间线速览
| 时间 | 事件 |
|---|---|
| 2026-03-17 | 仓库创建 |
| 2026-04-21 → 05-11 | v0.3.2→v0.3.6，早期滚动快（1–10 天一版） |
| 2026-06-21 | v0.4.0 大功能合并期（Apple Silicon、Agent CLI、扩展页重设计） |
| 2026-07-16 | v0.4.1（月度维护节奏确立） |
| 2026-08-13 | 仍活跃推送（GitHub pushed_at） |
—
二、架构鸟瞰（技术深拆）
2.1 第一性设计：双运行时，Python 由 Electron 托管
用户 (鼠标/键盘) │ ▼ ┌──────────────────────────────────────────────────────────────────────────┐ │ Electron 主进程 (electron/main/index.ts) │ │ • whenReady → syncBuiltinExtensions() → new PythonBridge() │ │ • setupIpcHandlers() ◄──── 63KB 单体 IPC 契约 (ipc-handlers.ts) │ │ • createWindow() (frameless, contextIsolation:true, nodeIntegration:false)│ │ │ │ ipcMain.handle/on ── invoke/send ──┐ │ └────────────────────────────────────┼──────────────────────────────────────┘ │ IPC (contextIsolated, 渲染侧经 preload 类型包装) ▼ ┌──────────────────────────────────────────────────────────────────────────┐ │ 渲染进程 (React, src/) ◄── preload/electron-api.ts │ │ • three.js / react-three-fiber 3D 预览 • @xyflow/react 节点工作流画布 │ └──────────────────────────────────────────────────────────────────────────┘
主进程以 HTTP 客户端身份调用本地 FastAPI：
axios / net ──▶ http://127.0.0.1:8765
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ Python 后端 (api/main.py → uvicorn，由 python-bridge spawn) │
│ lifespan: generator_registry.initialize() 扫描 EXTENSIONS_DIR │
│ routers: status / settings / model / generate / optimize / extensions / │
│ export / workflow_runs / agent │
│ │
│ GeneratorRegistry ── 每扩展 = 独立 venv 子进程 + runner.py ─┐ │
│ ▼ │
│ ExtensionProcess ── stdin/stdout NDJSON ──▶ 模型推理(torch, GPU/MPS) │
│ (取消=协作后硬杀，释放显存靠进程退出) │
└──────────────────────────────────────────────────────────────────────────┘
│
▼ (扩展 setup.py 运行时 pip install torch …)
HuggingFace Hub (首次按需拉权重；gated 需 HF token)
2.2 进程模型要点
– 拉起方式：child_process.spawn(pythonExec, ['-m','uvicorn','main:app','--host','127.0.0.1','--port',8765])。Python 用内嵌 python-build-standalone 3.11.9（构建期由 scripts/download-python-embed.js 拉取，打包为 extraResource）——零系统依赖的「绿色」运行时，用户机器无需预装 Python，venv 基于内嵌解释器创建，干净隔离。
– 端口：硬编码 8765，启动前 killProcessOnPort() 清场（应对上次异常残留）。代价：不支持并行多开实例。
– 健康：轮询 /health，最多 180×500ms≈90s；/health 仅返回 {"status":"ok"}，无能力级检查（不验模型/扩展是否就绪）。
– 崩溃恢复：python:crashed 仅通知渲染层，无自动重启 supervisor。单点后端崩 = 当前生成任务丢失，恢复靠用户手动。此乃架构性缺口。
– 进程组隔离：Unix 下 detached 为进程组 leader，退出时整组击杀（避免被 launchd 收养成孤儿、长期占 MPS 显存）；Windows 用 taskkill /PID /T /F。
2.3 IPC 契约：规模合理，单体成债
– ipc-handlers.ts 共 1545 行 / 63KB，含 63 个 ipcMain.handle/on 注册点，已按 16 个 domain 分组（log/window/setup/python/fs/model/shell/system/app/settings/cache/workspace/extensions/updater/api/workflows）。
– 类型安全「半截」：preload electron-api.ts 给渲染侧提供手写类型化包装（调用端类型安全），但 IPC 契约本体是 stringly-typed（channel: string、...args: unknown[]），通道名/参数靠约定对齐，无 schema 生成/编译期校验，重命名通道编译器不会报错。
– 63KB 单体 = 维护债：混入 GPU 探测（nvidia-smi 解析）、扩展安装编排（~250 行）、路径守卫、工作流、资产库等迥异职责。合理拆分（GPU→gpu.ts、扩展安装→extension-install.ts）尚未做。能跑，但债在累积。
2.4 扩展宿主：应用与重模型彻底解耦
– GeneratorRegistry._discover_extensions() 扫 EXTENSIONS_DIR，每扩展需 manifest.json（id/type/generator_class/nodes[]）+ generator.py（继承 BaseGenerator）。
– 节点 ID = ext_id/node_id；两种加载：subprocess 模式（扩展自带 venv → ExtensionProcess + NDJSON 子进程，新）与 direct 模式（无 venv → importlib 直载，旧）。
– 基础 requirements.txt 不含 torch；torch 等重型依赖随扩展 setup.py 即时 pip install。利好分发与隔离，但「开箱即用」门槛被推到「装扩展」阶段（数 GB 下载 + venv 等待）。
2.5 工作流引擎：前端拓扑驱动，后端无 DAG 调度
– 节点画布用 @xyflow/react；preflight.ts 做静态类型/连线校验（类型不匹配、缺连接、Wait 分支合并等→WorkflowPreflightIssue[]），校验失败直接阻止运行（比 README「只是警告」更严）。
– 真正执行在 workflowRunStore.ts（前端）：identifyBranches() 拓扑排序、遇 waitNode 暂停交用户 Continue、逐节点调 /generate/from-image（模型）或 extensions.runProcess（过程）。后端 workflow_runs.py 仅暴露单图→网格 + 轮询，无全局 DAG 调度器。
> 架构评价：思路清晰、细节打磨扎实（stall 检测、MPS 显存回收、AppImage 稳定化、Windows 锁文件重试、extension-path-guard 防穿越）。短板集中在：63KB 单体 IPC、后端无自动恢复、测试偏薄、macOS 未签名/手动更新、本地化不彻底。「Beta 0.4.1」自我定位准确。
—
三、模型与生成管线
3.1 模型技术谱系（Web 核实）
| 模型 | 图生 3D 方法 | 架构要点 | 显存门槛 | 备注 |
|---|---|---|---|---|
| Hunyuan3D 2 / 2 Mini（腾讯） | 两阶段高质量图/文生 3D | 形状：Hunyuan3D-DiT（Rectified-Flow 扩散 Transformer + Shape VAE）；纹理：Hunyuan3D-Paint（扩散烤 PBR） | 形状 ~6GB；全量 ~16–24GB | VAE+扩散；2 Mini 为轻量蒸馏(0.6B)，Turbo/Fast 为加速版；Apache-2.0 |
| TripoSG（VAST） | 单图→高保真 3D 形状（SOTA 形状） | Rectified-Flow Transformer(1.5B)，3D VAE 用 SDF+法线+eikonal 混合监督 | ≥8GB（约 15s） | 仅形状、无内置纹理 |
| Trellis / Trellis2（微软） | 结构化潜扩散，多格式输出 | SLAT（稀疏体素+多视角特征）= Rectified-Flow Transformer；解码到 Radiance Field / 3DGS / Mesh | ≥16GB | 1.2B；GGUF 量化是社区扩展，降显存但以质为代价 |
| TripoSR（Stability+Tripo） | 单图快速重建（LRM 类） | 前馈 Transformer，非扩散，<0.5s/次 | ~6GB | 顶点色/烘焙纹理，MIT；对称/遮挡歧义明显 |
| Stable Fast 3D / sf3d（Stability） | 单图→3D（TripoSR 后继） | 同系前馈 + 纹理管线，依赖 texture_baker+uv_unwrapper | 中等（gated，需 token） | 即代码默认 sf3d；未列于主 README 扩展表 |
谱系分野：前馈回归（LRM：TripoSR/sf3d） 快而廉，细节与多视角一致性弱；潜扩散/Rectified-Flow（Hunyuan3D-DiT、TripoSG、Trellis） 质高而慢、吃显存。
3.2 端到端管线
┌────────────┐ │ Input Image│ POST /generate/from-image (model_id, remesh, enable_texture, params) └─────┬──────┘ ▼ ┌─────────────────────────────────────────────────────────────┐ │ ExtensionProcess 子进程（per-extension venv + runner.py） │ │ ├─ 解码图像 → generator.generate(image, params) │ │ │ 产出原始网格（隐式/体素 → marching cubes → mesh） │ │ └─ 可选：纹理阶段（Hunyuan3D-Paint / sf3d 烘焙） │ └─────┬───────────────────────────────────────────────────────┘ ▼ 返回 .glb 路径 → WORKSPACE_DIR// ┌────────── 后处理（可独立触发，亦可编入节点图）────────────────┐ │ A. UV 展开 (uv_unwrapper, box-projection) │ │ B. 贴图烘焙 (texture_baker, 重心坐标光栅化) │ │ C. 网格优化 (optimize.py, trimesh+pymeshlab)： │ │ decimation(quadric edge collapse) / laplacian smoothing / transform │ │ D. 3D Gaussian Splatting 转换 (.ply → .splat) │ └─────┬──────────────────────────────────────────────────────────┘ ▼ ┌──────────────┐ 导出 glb / stl / obj / ply │ Export .glb │ glb 直出；余者 trimesh 转换 └─────┬────────┘ ▼ 3D Viewer（Three.js）展示，可入资产库
关键事实：基础 /generate/from-image 已能直接吐 .glb。UV/烘焙/减面平滑是可选叠加，既可由用户手动触发，亦可作为「process 扩展节点」编入工作流。
3.3 「全本地 GPU 跑」真实性
– 推理 100% 本地，无云端推理 API：模型在 ExtensionProcess 子进程内 torch 直推，权重在 MODELS_DIR，全程不离开本机 GPU；后处理皆本地库。
– 唯一外网依赖 = 权重下载：hf_download / BaseGenerator._auto_download() 走 HuggingFace Hub（可带 HF token，gated 模型用）；代码内无任何第三方推理 SaaS 调用。
– caveat：首次必联网下数 GB 权重；texture_baker/uv_unwrapper 仅提供 Windows cp310 预编译 .pyd，Linux/macOS 需源码重编（CUDA/Metal）；pymeshlab 在受控 Windows 环境可能被白名单拦截（503）。
– 质量上限：单图重建固有限制（背面/遮挡靠先验「想象」、对称歧义），开源本地模型对人物近看有「融化蜡像」感——此非 Modly 之过，乃单图重建通病。
—
四、扩展生态与安全（PK 主战场）
4.1 安装与执行全链路
Models 页 → Install from GitHub → 输入 URL │ ▼ [Electron 主进程] extensions:installFromGitHub (ipc-handlers.ts:1023-1233) [1] 解析 URL：仅校验 hostname===’github.com’ 且 path 形如 owner/repo ⚠ 不校验 owner 身份、不校验仓库存在、不钉扎 commit [2] 下载 tarball(HEAD, 可变)：GET api.github.com/repos/{o}/{r}/tarball/HEAD ⚠ 无 SHA256 / 签名校验 [3] 解包到 temp（tar 条目未做穿越审计） [4] 校验 manifest.json（结构完整性；assertSafeExtensionId 限 id 字符集） [5] staging（含 esbuild 编译攻击者 TS）→ 原子 rename（先备份旧版） [6] Setup（真正执行第三方代码）： ├─ Python 扩展: 运行 setup.py ⚠ 当前用户权限，无沙箱 └─ JS 扩展: npm install –omit=dev ⚠ 拉取攻击者 package.json 依赖 [7] 清 marker，触发 /extensions/reload
执行时：模型扩展 → ExtensionProcess（venv 子进程，NDJSON，继承宿主全部环境含 HF_TOKEN）；进程扩展 → process-runner.ts spawn。内置扩展（build-builtins.mjs 编译随包）不经 GitHub 安装路径，是「出厂自带可信代码」。
4.2 三层防护各防什么、防不住什么（亲验结论）
| 层 | 防什么 | 防不住什么 |
|---|---|---|
extension-path-guard.ts | 扩展 id 路径穿越到系统目录（测试充分） | 扩展代码本身是否可信（合规 id 如 evil-mesh 照常装） |
extension-install-utils.ts | manifest 结构完整性（id/type/entry/nodes） | 代码来源/内容（任意合法 manifest 即可装） |
artifact-registry-service.ts | 工作区资产路径穿越（限 Workflows/Exports 根） | 与扩展安装无关 |
> 路径/结构层纵深防御做得好且可验证；代码信任层从安装入口起就是全开。 此结构性取舍，非配置疏漏。
关于「签名校验」之 PK 决断：D 卷据 api/resources/public_key.pem + cryptography 依赖推断「扩展有签名校验」；C 卷经代码检索称「下载链路无任何 hash/签名/完整性校验」。吾亲验：
– public_key.pem 确存在（113 字节），但 api/ 内零处引用（grep public_key/.pem/sign/verify 在 api 仅命中无关词）；
– cryptography 在 requirements.txt，但 api/ 内无任何 sign/verify/import cryptography；
– 下载链路（model.py:125-278、extension_process.py:55-58）无 hashlib/checksum/integrity/signature。
拍板：C 卷成立、D 卷推断证伪。Modly 当前无任何扩展/权重供应链完整性校验。 public_key.pem 系孤儿文件（疑似作者曾设想、未接线），此「想做而未做」本身即安全成熟度信号。
4.3 安全发现清单
🔴 高危
| # | 发现 | 说明 |
|---|---|---|
| H1 | 任意 GitHub 仓库 = 以用户权限执行第三方代码（设计性 RCE） | 仅校验 github.com 主机名 + owner/repo 形态；无代码签名、无维护者 allowlist、无人工审阅闸门 |
| H2 | 模型权重无完整性校验 + hf_repo 由扩展可控 = 供应链 RCE | PyTorch 权重 pickle.load 即代码执行；无 hash/签名；repo_id 由扩展 manifest 声明（攻击者可控） |
| H3 | 扩展子进程无沙箱、继承宿主全部环境（含 HF_TOKEN/SSL_CERT_FILE/代理） | 恶意扩展 = 完整主机沦陷（读密钥、外联 C2、写自启） |
| H4 | POST /extensions/setup/{ext_id} 路径穿越（未 sanitize） | 安装路径有守卫，但此 HTTP 端点无 assertSafeExtensionId；任意 ext_id（如 ../../x）可指向他处 setup.py 以 sys.executable 执行；无鉴权 localhost 即可触发 |
🟠 中危
| # | 发现 |
|---|---|
| M1 | 无版本/commit 钉扎，tarball/HEAD 可变，安装不可重现、无法审计「当时装了什么」 |
| M2 | FastAPI 控制平面 127.0.0.1:8765 完全无鉴权；任意本地进程/智能体/已装恶意扩展可调生成、导入网格、触发 /extensions/reload、/extensions/setup |
| M3 | 「官方可信注册表」仅作 UI 徽章，非执行闸门；离线拉取失败失败开放（返回空集，照样随意装） |
| M4 | HF token 以 URL query 传递（model.py:131/309），易落日志/SSE/进程列表 |
| M5 | JS 扩展 npm install 拉取攻击者 package.json 依赖（无 lockfile 校验要求） |
| M6 | tar 解包未审计条目穿越（symlink/../ 历史 CVE；落 temp 内仍可被滥用） |
🟡 低危
– L1 typo-squat / 同名仓库冒用（仅校验主机名，不验 owner 真实）；L2 实验 comfy-* 信任可配 COMFYUI_URL，投毒指向远端即成出网通道；L3 dev ensure-server 可凭空拉起无鉴权后端，放大暴露窗。
✅ 已缓解（值得肯定）
– 扩展 id 路径穿越守卫（R1）、工作区资产路径守卫（R2）、畸形 manifest 拒绝（R3）、安装原子性+回滚（R4）、CLI 工作区路径校验（R5）、自动 pip 修复白名单克制仅 PIL→Pillow（R6）。
4.4 智能体接口（MCP / CLI）：面小，底座大
– MCP server（mcp_server.py，10 工具）：modly_list_models / switch_model / generate_from_image / get_generation_status / decimate_mesh / smooth_mesh / import_mesh / unload_models / get_settings——是「智能体→智能体驱动」薄封装，仅覆盖生成+优化+模型管理，未直接暴露扩展安装/任意进程/权重下载。面相对克制。
– CLI（tools/modly-cli/agent.py，65KB，stdlib-only）：canonical health / model / workflow-run / capability / process-run + 友好 generate（驱动 /workflow-runs/from-image 并轮询导出 glb）；stdout 机器可读 JSON、失败关闭（fail-closed）、模型 id 经 /model/all 校验。契约分明（legacy/experimental 与 canonical 隔离）。
– PK 要点：MCP/CLI 自身克制，但其依赖的 127.0.0.1:8765 无鉴权控制平面（M2）——「导入网格/重载扩展/重跑 setup（且 setup 端点有 H4 穿越）」等高危能力对本地一切进程敞开。面小不能抵消底座大。
4.5 安全张力
1. 开放扩展生态 vs 本地应用安全：任意 GitHub 仓库即执行，仅以 github.com 为信任锚；无签名、无钉扎、无沙箱。路径层优秀，代码信任层敞开——结构性「便利压倒安全」。
2. 「本地优先 / 隐私」叙事 vs 无校验联网拉权重：强调 runs entirely on your GPU，但权重须从 HF 拉且无完整性校验、hf_repo 可控、PyTorch 加载即代码执行。隐私主张与供应链风险并存。
3. 强智能体接口 vs 攻击面放大：MCP/CLI 越强，本地任意进程（含恶意扩展）可借无鉴权底座之杠杆越大。
—
五、产品定位与竞品
5.1 竞品对照表（维度 × 产品，质量★为相对档位）
| 产品 | 形态 | 本地/云 | 开源 | 价格（量级） | 上手 | 质量★ | 可扩展 | 显存 |
|---|---|---|---|---|---|---|---|---|
| Modly | 本地桌面 App | 本地 | MIT | 免费（自购 GPU） | 低 | ★★★ | 高（扩展+节点+CLI/MCP） | ~6GB 起 |
| Meshy | 云端 SaaS | 云 | 专有 | 免费额 + ~ 20/月 | 极低 | ★★★★ | 中（API） | 无 |
| Rodin (Hyper3D/Deemos) | 云端 SaaS | 云 | 专有 | 生成免费，下载 ~$0.5–1.5/个 | 低 | ★★★★★ | 中（API） | 无 |
| Luma Genie | 云端 | 云 | 专有 | 免费 | 极低 | ★★★ | 低 | 无 |
| TripoSR | 开源模型 | 本地 | MIT | 免费 | 中 | ★★★(白模) | 高（当组件） | 中 |
| ComfyUI | 开源节点平台 | 本地 | GPL | 免费 | 高 | ★★★★(看接啥) | 极高 | 中高 |
| TRELLIS（微软） | 开源模型 | 本地 | MIT/Apache | 免费 | 高 | ★★★★ | 高 | 中高 |
| Hunyuan3D（腾讯） | 开源模型 | 本地 | 开源 | 免费 | 高 | ★★★★ | 高 | 中高 |
> 竞品量级参考（2026-08 检索）：Tripo/Meshy 双雄约 27–28M 月访、9 万开发者；Rodin 出品方为 Hyper3D（影眸科技/Deemos），非微软（微软对应开源模型是 TRELLIS）。
5.2 定位图（四象限）
开源 / 开放 (上) ┌─────────────────────────────────────────────┐ │ TripoSR / TRELLIS / Hunyuan3D / │ Modly ★ │ ComfyUI / InstantMesh / Unique3D │ (本地+开源+桌面，独一份子格) ├──────────────────┼─────────────────────────────┤ │ (空白：本地开源且打包桌面 │ Meshy / Tripo │ 几乎只有 Modly) │ Rodin / Luma Genie └─────────────────────────────────────────────┘ (云端专有 SaaS) 专有 / SaaS (下)
Modly 占据「本地 × 开源」象限中「还做了桌面打包」的几乎无人占据子格——既是战略机会，也是工程风险源（要补的活最多）。
5.3 营销主张事实核查
– 「Turn any photo into a 3D model」：✅ 成立（Image→Generate→Add to Scene）。⚠️ 单图重建质量上限明显（背面/遮挡幻觉，人物近看「蜡像感」）。 – 「runs entirely on your GPU」：✅ 推理本地、数据不出机。⚠️ 首次必联网下权重、扩展走 GitHub；「entirely on GPU」指计算层，非「离线可用」。 – 「local, open source」：✅ MIT、全本地推理、可 clone 自跑。⚠️ macOS 仅 Apple Silicon；无 Intel Mac/移动/云。
5.4 成熟度评分卡（1–5）
| 维度 | 分 | 依据 |
|---|---|---|
| 代码活跃度 | 4 | 月级发布、5.5k 星/582 fork、仍活跃；核心疑似 1–2 人 |
| 文档 | 3.5 | README/API/扩展/Jetson/ADR/SKILL 齐；缺整体架构总览、模型显存对照 |
| 测试 | 3 | pytest + node 测试接入 npm test，但用例体量小、覆盖广度有限 |
| 社区 | 2.5 | Discord + 3 赞助 + 52 issues；规模小 |
| 平台覆盖 | 3.5 | Win/Linux/Apple Silicon 三端；缺口 Intel Mac/移动/云 |
| 许可 | 4.5 | 实质 MIT 商用友好；小扣 NOASSERTION + fork 署名 |
| 综合（工程成熟度） | ~3.5 | 活跃的早期 Beta：方向对、形态清，离生产稳定仍有距 |
5.5 适用人群
– 该用：隐私/数据主权优先者；已有本地 GPU、想零边际成本批量出模型者；agent builder（MCP+CLI 是真正卖点）；想玩多模型/改管线者；离线/边缘（Jetson 无头）部署。 – 暂勿用/谨慎：无像样独显的笔记本（~6GB 显存门槛）；要「开箱即最高质量」商业交付（云端 Rodin/Tripo 更稳）；Intel Mac；需企业级 SLA 的团队；只想偶尔出一张图的 casual 用户（云端免费额更省事）。
—
六、趋势论之
– local AI 3D generation 浪潮：2026 开源模型（Hunyuan3D-2.1 带 PBR、TRELLIS、TripoSR）质量已「能用」，把推理搬回本机具技术+需求双基。Modly 踩中。 – agent-driven 3D 创作：MCP/CLI 是 2026 明显趋势。Modly 在 README 即重投 CLI/MCP，属先行者姿态，比多数开源模型仓库更懂「给 agent 用」。 – everything local 运动：隐私+零边际成本+主权，与本地 LLM（Ollama 类）同源。Modly 是这条线在 3D 领域的对应物。 – 定位结论：在「本地 × 开源 × 桌面打包」子格，Modly 是品类定义者/先行者；但在「图生 3D 整体质量与商业成熟度」上，它是追赶者（云端双雄 27–28M 月访）。即：分发形态领先，模型质量与生态规模追赶。
—
七、PK 拍板 · 结论与建议
7.1 四路之争的整合结论
| 维度 | 四方共识 | 关键张力（待拍板者） |
|---|---|---|
| 架构 | 双运行时思路清晰、绿色分发高明、路径层安全扎实 | 63KB IPC 单体债、后端无自动重启、本地化不彻底 |
| 模型 | 模型无关宿主、推理 100% 本地、多模型可插拔 | 默认模型悬空（sf3d 不在宣传表）、文档漂移、质量受本地算力锁死 |
| 安全 | 路径/结构层防护好 | 代码信任层全开：任意仓库 RCE、权重无校验、无沙箱、控制平面无鉴权、setup 端点穿越 |
| 定位 | 本地×开源×桌面独一份、agent 接口先行 | 野心 ≫ 工程成熟度（1–2 人、测试薄、社区小） |
最大分歧（已决）：「扩展有无签名校验」——D 卷推断有、C 卷称无；吾亲验证伪 D 卷：当前零供应链完整性校验（孤儿 public_key.pem 为证）。此一决断，直接拉高安全结论的严重度。
7.2 给步子哥的一句话 verdict
> Modly 是当下「本地、开源、图生 3D 桌面 App」这一品类的独苗与先行者，方向对、体验巧、agent 接口前瞻；但 v0.4.1 仍是早期 Beta——它把「便利与开放」放在「代码信任与安全」之前，对普通用户是「传图即出模的隐私厨房」，对安全敏感场景则是「装扩展即开门揖盗」的未设防城堡。值得技术玩家与隐私党尝鲜，不宜在企业/高价值资产环境无脑装第三方扩展。
7.3 给用户（步子哥）的使用建议
1. 自用无妨，慎装扩展：只装官方 lightningpixel/* 扩展，且手动核对仓库与 commit；绝不装不知名 GitHub 仓库扩展（= 以你权限跑任意代码）。
2. 硬件门槛：独显 ≥ 8GB 显存起步（TripoSG/Hunyuan3D-Mini 下限），大模型/带纹理需更高；Intel Mac 用户请绕行。
3. 质量预期：单图重建对物体稳、对人物有「蜡像感」；要生产级拓扑仍须 Blender 收尾。
4. 隐私边界：推理不出机属实，但首次须联网下权重；gated 模型（sf3d 等）需 HF token。
5. agent 玩法：MCP/CLI 接 Claude/Codex 编工作流是真亮点，但认清底座 127.0.0.1:8765 无鉴权——别在装了不可信扩展的机器上跑 agent。
7.4 给项目方的优先修复清单（摘要）
1. 安装闸门：维护者 allowlist / 签名校验 / commit 钉扎（至少记录安装时 commit SHA 供审计），离线失败关闭而非放行。
2. FastAPI 鉴权：127.0.0.1:8765 加本地令牌（MODLY_API_TOKEN，Electron/CLI/MCP 共享），至少把 /extensions/*、/process-runs、/hf-download 纳入。
3. 修 H4：/extensions/setup/{ext_id} 先 assertSafeExtensionId。
4. 权重完整性：/hf-download 校验 expected_sha256（来自经签名 manifest），否则拒载；PyTorch 加载前做完整性断言。
5. 最小环境注入：扩展子进程勿继承 HF_TOKEN 等密钥，按需显式传入；考虑 macOS App Sandbox / Windows 低权限令牌。
6. ComfyUI URL 白名单：限 COMFYUI_URL 仅 localhost。
—
附：关键文件溯源
| 主题 | 文件 |
|---|---|
| 启动/进程生命周期 | electron/main/index.ts、python-bridge.ts |
| IPC 契约单体 | electron/main/ipc-handlers.ts（1545 行/63KB） |
| 路径守卫 | electron/main/extension-path-guard.ts + .test.ts |
| 模型注册/默认 ID | api/services/generator_registry.py:165 |
| 子进程推理宿主 | api/services/extension_process.py、api/runner.py |
| 生成/工作流接口 | api/routers/generation.py、workflow_runs.py |
| 减面/平滑/GS | api/routers/optimize.py |
| 权重下载 | api/routers/model.py:125-278 |
| MCP server | api/mcp_server.py（10 工具） |
| CLI | tools/modly-cli/agent.py（65KB）+ SKILL.md |
| 节点画布/前端执行 | src/areas/workflows/{preflight.ts,workflowRunStore.ts,WorkflowsPage.tsx} |
| 内置过程节点 | src/areas/workflows/nodes/{mesh-exporter,mesh-optimizer,mesh-smoother,mesh-remesher,mesh-repair} |
| 可信注册表(UI 徽章) | electron/main/ipc-handlers.ts:854-883（失败开放） |
| 孤儿签名文件 | api/resources/public_key.pem（113B，全代码零引用） |