用消费级显卡搭一套能操控电脑的本地 AI Agent：Holo 3.1 开源模型 + llama.cpp + OpenClaw 完整部署与实测拆解

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

如果你只想要一个结论，先记住这几句：Holo 3.1 是法国 H Company 发布的一套专门面向"电脑操作"的开源视觉语言模型，参数规模从 0.8B 一直覆盖到 35B-A3B，全部可以本地部署。它最大的意义在于——你不再需要为云端 Agent 持续付费，一张消费级显卡就能把模型跑在自己电脑上，配合 llama.cpp 这个推理引擎和 OpenClaw 这个开源 Agent 框架，就能让 AI 真正去看屏幕、点鼠标、敲键盘、翻网页、整理资料。我自己用一张 24GB 显存的卡跑 35B-A3B 的 Q4 量化版本，实测下来浏览器自动化、信息检索、文件保存、图片溯源这些任务都能跑通，速度也比想象中流畅。

这篇文章我会把整条链路从头到尾讲清楚：Holo 3.1 到底是什么、它和普通大模型差在哪、几个尺寸怎么按显卡选、为什么要用"推理引擎 + 模型 + Agent 框架"这三层结构、llama.cpp 怎么把模型跑起来、OpenClaw 怎么对接本地接口，最后再用几个真实任务把它的能力边界摸一遍。新手不用怕，每个术语第一次出现我都会用大白话解释一遍。

想看完整拆解，往下翻。

为什么"让 AI 操控电脑"这件事，过去一直卡在成本上

这两年只要关注 AI，几乎绕不开一个词：Agent（智能体）。简单说，Agent 就是能自己"动手干活"的 AI，而不是只会陪你聊天的对话机器人。你给它一个目标，它会自己拆解步骤、调用工具、一步步把事情做完。

而 Agent 里最让人眼前一亮的一类，就是"Computer Use"——直译过来是"电脑操作"。这类能力让 AI 不再只是吐文字，而是能像真人一样去操作图形界面：移动鼠标、点击按钮、在输入框里打字、在网页之间跳转。OpenAI 那边有 Operator，Anthropic 的 Claude 有 Computer Use，都是这个方向上比较早出圈的尝试。它们演示出来的效果确实震撼，你说一句"帮我订张票""帮我把这份表格整理一下",它真的能自己在浏览器里折腾半天给你办了。

但这里有个绕不开的现实问题，我自己在折腾的过程中体会特别深：贵。

云端 Agent 的计费逻辑，本质上是按"消耗"来收钱的。要么你接它的 API，按调用量、按 Token 付费；要么你订阅会员，到点续费。听起来好像还好，可一旦真用起来，问题就来了——Agent 干一件事往往要跟界面来回交互几十上百次，每一次它都得"看一眼屏幕、想一下、再操作",而"看屏幕"这件事意味着要把截图喂给模型，图像消耗的 Token 量相当可观。

我打个通俗的比方：你雇了个按小时结账、而且眼睛特别"费电"的助理，他每多看你一眼桌面都要单独跟你算钱。偶尔用用没感觉，可要是让他连续工作几个小时,或者一个团队、一家公司同时让一堆这样的助理跑任务，账单累积起来的速度会超出很多人的预期。尤其是企业场景下如果不设上限，一晚上跑下来的费用可能就让人肉疼。

成本之外还有第二个隐患：数据。云端方案意味着你的屏幕截图、操作内容、文件信息要发到别人的服务器上去处理。对很多需要处理敏感资料的场景来说，这一条本身就是劝退理由。

所以一直以来，"让 AI 操控电脑"虽然很酷，但对普通人来说更像是个"看看就好"的功能。门槛卡在两处：一是持续烧钱，二是数据要出本地。

转折点在于——模型开始往本地搬了。

当一个专门为电脑操作优化过的模型，能被压缩到消费级显卡也跑得动的体积，并且开源免费、可以完全离线运行，那前面那两个问题就同时被解掉了：跑在自己机器上，没有 Token 账单，想跑多久跑多久；数据全程不出本地网络，隐私自然也守住了。

这里得多说一句：本地化这条路其实一直有人想走，但过去走不通，卡点在三个地方。一是模型太大，动辄几百亿参数的全精度模型，光显存就不是普通人能凑齐的；二是推理太慢，没有针对消费级硬件优化的引擎，跑起来慢得没法用；三是缺一个趁手的"指挥层",就算模型跑起来了，也没有成熟的框架替它去操作电脑。

这两年这三道坎被逐个填平了。量化技术让大模型能在不明显变笨的前提下大幅瘦身；像 llama.cpp 这类轻量推理引擎把消费级显卡甚至个人电脑的算力压榨得越来越到位；OpenClaw 这类开源 Agent 框架成熟起来，补上了"动手"那一环。三股力量汇到一起，"个人电脑上跑一个能自己操作电脑的 AI"才从设想变成了能落地的事。业内甚至有人开始把这类"主要使用者是 AI 智能体而非人类"的机器，单独叫作"Agent 计算机",和传统个人电脑区分开——可见这股本地化的势头有多受关注。

Holo 3.1 就是踩在这个节点上出现的。它不是又一个"更聪明的聊天模型",而是一套从设计之初就奔着"操控电脑"去的模型，而且这一代专门补上了"本地部署"这块拼图。下面我先把它讲清楚，再带你一步步搭起来。

Holo 3.1 到底是什么：一款专为"操控电脑"而生的视觉语言模型

先把出身交代一下。Holo 3.1 来自一家叫 H Company 的法国 AI 公司，总部在巴黎。这家公司的主线一直就是做"能操作软件的 AI 智能体",此前已经放出过 Holo3，在开发者和企业里用得不少。Holo 3.1 是 2026 年 6 月初发布的迭代版本，定位写得很直白——Fast & Local Computer Use Agents，翻成人话就是"又快又能在本地跑的电脑操作智能体"。

它和普通大模型差在哪

要理解 Holo 3.1 的特别之处，得先分清两个概念。

我们平时接触最多的是 LLM（大语言模型），它的世界是纯文本的，你给它文字，它还你文字。而 Holo 3.1 属于 VLM（视觉语言模型，Vision-Language Model）——多了一只"眼睛"。所谓 VLM，就是既能读文字、又能"看图"的模型。对电脑操作这件事来说，这只眼睛是命门：因为电脑界面本质上是一张张画面，按钮在哪、输入框在哪、当前页面是什么状态，模型得先"看懂"屏幕，才谈得上操作。

更关键的是，Holo 3.1 不只是会看，它被专门训练成擅长两件事：

第一是 UI grounding（界面定位）。这个词听着唬人，其实意思很朴素——给定一句指令和一张屏幕截图，模型能准确说出"该点的那个东西在屏幕的哪个坐标"。比如你说"点登录按钮",它得能在一整张花花绿绿的页面里精确圈出登录按钮的位置。这是所有点击操作的基础。

第二是 规划与执行。看懂屏幕、定位元素只是第一步，模型还得把"发布一篇文章"这种大目标，自己拆成"找到发布入口 → 点进去 → 填标题 → 填正文 → 点发布"这一连串小动作，并按顺序执行下去。

所以你可以这么理解：普通 LLM 是个很会聊天的"嘴",Holo 3.1 是个长了眼睛、还会动手的"操作工"。

技术底子和能力范围

Holo 3.1 是基于 Qwen 3.5 系列做的二次训练（业内叫"微调"，就是在一个已经很强的基础模型上，针对特定任务再训一轮）。这意味着它继承了 Qwen 这套架构的底子，又在"电脑操作"这个垂直方向上做了大量针对性强化。

相比上一代 Holo3，3.1 这一代主要补强了三块，我整理成一张表你一眼就能看明白：

这里解释一下 function-calling（函数调用）这个新手容易懵的点。你可以把它想成模型和外部工具之间的一套"标准接口"。模型不直接去戳软件，而是按约定的格式说一句"我要调用'点击'这个工具，参数是坐标 (x, y)",外面的框架接到这句话，就替它真去点。Holo 3.1 原生支持这套协议，好处是它能无缝插进市面上各种主流 Agent 框架里，不用额外做一堆胶水代码。

至于能力到底强不强，可以看几个公开的基准测试（benchmark，就是业内统一的"考试题库",用来横向比较不同模型）：

• 在 AndroidWorld（专门考手机界面操作的测试）上，35B-A3B 这个最大尺寸从上一代的 67% 提升到了 79.3%，较小的 4B、9B 版本也从 58% 提到了 71% 左右。
• 在 OSWorld（考桌面操作的测试）以及覆盖电商、办公软件、协作流程的内部测试里，函数调用方式和原生执行方式基本打平，说明它接进第三方框架后掉点很少。

这里还藏着一个普通用户容易忽略、但其实很要命的点：鲁棒性（robustness，可以理解为"换个环境还能不能稳定发挥"）。H Company 自己复盘上一代时发现一个反复出现的问题——模型在某一个环境里测得很好，换到另一个环境就掉链子。手机界面、不同的 Agent 框架、不同的执行方式，每一种都会带来所谓的"分布漂移"（简单说就是"模型没见过的新情况"），让表现打折。Holo 3.1 这一代花了大力气在这上面，目标就是"无论你把它塞进哪种环境、接到哪个框架，发挥都尽量稳"。对要真正拿来干活的人来说，这种"换地方也不掉链子"的稳定，往往比榜单上多那么一两分更值钱。

再补一句它为什么基于 Qwen。Qwen 系列本身是一套被验证过、底子很扎实的开源模型架构，社区生态、工具链支持都很完善。H Company 没有从零造轮子，而是站在 Qwen 这个肩膀上，把精力集中投到"电脑操作"这个垂直能力的强化上。这种做法的好处很实在：继承了成熟架构的稳定性和广泛的工具兼容（比如能顺利转成 GGUF 格式、被 llama.cpp 加载），同时又在专业方向上做到了拔尖。

简单说，这一代不是"刷分好看"那种进步，而是冲着"在真实环境里少卡壳、少重试、更多任务能一次跑完"去优化的。莫潇羽@源码七号站 自己实测下来，最直观的感受就是它在网页里那种"该点哪就点哪"的稳定度，确实比一般通用模型靠谱不少——这点后面实测章节会展开讲。

它在同类里大概是什么位置

光看自家前后代对比还不够直观，横向比一比更有数。从公开信息看，Holo 3.1 这套被拿来和一批通用大模型同台较量过，在"电脑操作"这个专项上表现相当能打——毕竟它是专门为此训练的，面对通用模型有"术业有专攻"的优势。上一代 Holo3 在桌面操作的 OSWorld 测试里就拿到过很高的分数，超过了同期一些顶级的通用旗舰模型，而成本只是后者的一个零头；3.1 在此基础上又把移动端和跨框架的短板补齐了。

这里我想给新手建立一个正确的预期："专项强"不等于"样样强"。Holo 3.1 在"看屏幕、点界面、走流程"这件事上很专业，但你别指望它像通用大模型那样陪你写长文、做复杂推理——那不是它的活儿。它的定位就是一个高效的"操作工",评价它得看它干本职工作干得怎么样，而不是拿通用能力去苛求它。想明白这层，你对它的体验会顺很多，也不会因为"它不会写诗"就觉得它不行。

另外值得一提的是它的开放程度。模型放在公开的模型社区上，任何人都能下载、本地部署、免费使用，这种开放生态本身就是它能在短时间内被大量开发者拿去折腾、快速积累实战反馈的原因。一个被很多人真正跑在自己机器上的模型，往往比只活在演示视频里的模型更经得起检验。

模型家族与量化版本：从 0.8B 到 35B-A3B 到底怎么选

很多人卡在第一步不是不会装，而是不知道"我这台机器该下哪个版本"。Holo 3.1 一口气放出了四个尺寸，再叠加多种量化精度，组合起来确实容易挑花眼。这一节我把选择逻辑捋顺，你对着自己显卡就能下结论。

四个尺寸怎么理解

Holo 3.1 家族目前包含 0.8B、4B、9B、35B-A3B 四个成员。前面那个数字代表参数量（B 是 Billion，十亿），数字越大、通常越聪明，但对显存和算力的胃口也越大。

需要专门拎出来讲的是最大那个 35B-A3B，它的名字里藏着这一代能"以小博大"的关键秘密——MoE 架构（Mixture-of-Experts，专家混合）。

我用大白话解释一下 MoE。传统的"稠密模型"好比一家公司里，每接一个活儿全体员工都得到场开会，35B 的模型每次推理就要动用全部 350 亿参数，又慢又费资源。而 MoE 把模型拆成很多个"专家小组",每次只叫醒和当前任务最相关的那几组上工。35B-A3B 里那个 A3B 就是"Activated 3B"——激活 30 亿参数的意思：模型总盘子有 35B，但每一步实际干活的只有约 3B。

这就解释了一个看起来矛盾的现象：为什么一个标称 35B 的大模型，居然能在 24GB 显存的消费级显卡上跑得动、而且不慢。因为它"块头大但每次只出一小队人",兼顾了能力和速度。

不过这里有个新手特别容易想岔的地方，我得点破：MoE"每次只激活 3B",省的是计算量（所以快），但显存这块省得有限。因为你没法预知下一步会叫醒哪几个专家，所以全部 35B 的参数原则上都得先装进显存待命。这也是为什么 35B-A3B 即便量化到 Q4，体积还是有 20GB 上下，得用 24GB 的卡才稳妥——它快是真快，但占地方也是真占。把"激活参数少 = 显存需求小"画等号，是装之前最常见的误判，记住别踩。

量化精度是什么，为什么必须关心

光有尺寸还不够，还得看"量化版本"。

量化（Quantization）这个词，新手第一次听很容易发怵，其实概念很简单：模型里全是数字（权重），原始状态下每个数字记得特别精确，占空间也大；量化就是把这些数字"压缩"成更省地方的低精度格式，体积大幅缩小，代价是损失一丁点精度。好比把一张超高清照片压成清晰度依然够用的版本——文件小了一大圈，肉眼几乎看不出区别。

Holo 3.1 的 35B-A3B 提供了这么几种量化：

官方有一组数据挺有说服力：FP8 和 NVFP4 在桌面操作测试里的得分，和全精度 BF16 基本持平，只差大约 2 分。换句话说，量化带来的"变笨"幅度小到可以忽略，但省下的资源是实打实的。

我们这次走的是 Q4 GGUF 这条线。GGUF 是 llama.cpp 这个推理工具专用的模型格式（后面会讲到 llama.cpp），Q4 表示 4 位量化。35B-A3B 的 Q4_K_M 版本，体积大概在 20GB 上下，配 24GB 显存的卡刚刚好。

对着显卡选版本

我把选择做成一张速查表，你照着自己的显存对号入座就行：

我自己是 24GB 显存，所以全程用的是 35B-A3B 的 Q4_K_M。我的建议是：显存够的话别犹豫，直接上 35B-A3B。原因很现实——Agent 任务是多步骤连续操作，中间任何一步判断失误都可能让整条链路崩掉，模型聪明一点点，跑通率就高一截，省下的反而是你来回返工的时间。显存确实紧张，再退而求其次选小尺寸先把流程体验起来。

这里再补一个小提醒：除了主模型，视觉模型还需要一个配套的小文件（通常文件名以 MM 开头，体积只有几百兆），它专门负责"看图"那部分。这个文件后面下载和部署时别落下，否则模型就只剩"嘴"没了"眼睛",在电脑操作场景里基本等于废了。具体怎么放，下一章讲架构和部署时会细说。

部署前先搞懂：这套本地 Agent 是怎么搭起来的

直接照着教程点点点也能装上，但我一向主张先看懂结构再动手——明白了每个零件干嘛的，万一中途报错你才知道去哪查。这套本地 Agent 其实就是三层结构搭起来的，我先用一张图把全貌摆出来：

flowchart TD
    A["你（下达任务）"] --> B["OpenClaw（Agent 框架 / 大脑指挥中心）"]
    B -->|"把屏幕截图 + 指令发给模型"| C["llama.cpp（推理引擎 / 发动机）"]
    C -->|"加载并运行"| D["Holo 3.1 模型（GGUF 格式 / 真正的大脑）"]
    D -->|"返回：该点哪、输入什么"| C
    C -->|"把决策传回"| B
    B -->|"真正去操作"| E["你的电脑（浏览器、文件、界面）"]
    E -->|"操作后的新屏幕"| B

这张图的循环就是 Agent 干活的完整节奏：你下指令 → OpenClaw 截屏并打包发给模型 → llama.cpp 驱动 Holo 3.1 看图思考、给出下一步动作 → OpenClaw 替它真去操作 → 操作完截新的图，再来一轮，直到任务完成。下面把三层挨个说清楚。

第一层：llama.cpp —— 让模型跑起来的"发动机"

模型文件下载下来只是一堆"死"的权重数据，本身不会动。要让它真正运转、能接收输入吐出结果，需要一个"推理引擎"来加载和驱动它。llama.cpp 就是目前本地部署里最流行的引擎之一。

它的好处是又轻又通用：用 C++ 写的，对硬件适配特别广，N 卡、A 卡、甚至 Mac 的芯片都能伺候，而且专门吃我们前面说的 GGUF 格式模型。你可以把它理解成一台发动机——模型是燃料，llama.cpp 负责点火、供油，让车真正能跑。它跑起来之后会在本地开一个服务地址（类似 127.0.0.1:1234 这种），对外提供一个标准接口，谁想用这个模型，连这个地址就行。

第二层：Holo 3.1 模型 —— 真正的"大脑"

这一层就是前两章讲的主角，GGUF 格式的 Holo 3.1，加上那个负责看图的视觉小文件。它是整套系统真正"思考"的地方：看懂屏幕、判断该点哪、决定输入什么，全靠它。它被 llama.cpp 加载着，本身不直接和你打交道。

第三层：OpenClaw —— 会动手的"大脑指挥中心"

光有发动机和大脑还不够，因为模型只会"想",不会真的去碰你的鼠标键盘和浏览器。中间还缺一个"手脚",这就是 OpenClaw 的角色。

OpenClaw 是一个开源的 AI Agent 框架，2026 年初在开发者社区里热度很高，GitHub 上很快攒到了十万级别的星标。它的定位不是聊天机器人，而是一个跑在你本地的"指挥进程"：一边连着模型（大脑），一边握着你电脑的实际操作权限（手脚）。它能干的事很实在——打开和控制浏览器、运行终端命令、读写文件、把任务流程记在本地的记忆文件里，甚至能接上 Telegram、微信这类消息渠道，让你用手机远程发指令。

它有个很关键的特性叫"模型无关（model-agnostic）",意思是它不挑大脑：你可以给它接云端的商业模型，也可以像我们这样接一个完全本地的模型。正是这个特性，让"OpenClaw + 本地 Holo 3.1"这套组合成立——OpenClaw 负责动手，Holo 3.1 负责思考，llama.cpp 在底下供能，三层各司其职。

为什么非要分成三层

可能有人会问：搞这么多零件干嘛，不能一个软件全包了吗？这里其实藏着一个很值得理解的设计思路——解耦，说白了就是"各管各的，谁也别绑死谁"。

分层最大的好处是灵活。模型层和引擎层分开，意味着你今天想换个更小的模型省显存、明天想试试新出的量化版本，只要换 models 文件夹里的文件就行，OpenClaw 那头一个字都不用改。反过来，框架层独立出来，意味着 OpenClaw 不在乎底下接的是本地模型还是云端模型——这正是它"模型无关"特性的由来。三层之间靠那个标准接口（还记得 /v1 吗）对话，谁都可以被单独替换升级，整套系统的可玩性和生命力就出来了。

这种"乐高积木式"的搭法，也是开源本地方案相比一体化云端产品的独特价值：你不是在用一个黑盒，而是在搭一套自己看得见、改得动、换得了的系统。理解了这点，你就会明白后面每一步装的到底是哪块积木，遇到问题也知道该拆哪一层去查。

把这套结构记在脑子里，接下来的部署你就不会是机械地照抄命令，而是清楚"这一步是在搭哪一层"。从下一章开始正式动手。

第一步：用 llama.cpp 把模型跑起来

正式动手了。这一步的目标，是把发动机（llama.cpp）和大脑（Holo 3.1 模型）装好并点火，让本地出现一个能用的模型服务地址。我按自己实操的顺序往下走，每一步都说清楚为什么这么做。

下载 llama.cpp，注意区分显卡品牌

先去 llama.cpp 的官方发布页拿最新版本。它更新很勤，几乎天天有新构建，挑最新的那个稳定版即可。

下载页面会列出一堆不同平台、不同后端的包，新手最容易在这里下错。记住这条原则——按你的显卡品牌选：

我自己是 N 卡，所以选的 CUDA 版本。选错后端最常见的后果就是"装上了但用不了显卡，全靠 CPU 硬扛",慢到怀疑人生，所以这一步务必对号入座。

解压并建好放模型的文件夹

把下载的压缩包解压出来，放个顺手的位置（我直接丢桌面）。进到解压出来的 llama.cpp 根目录，在里面新建一个文件夹，命名为 models。这个文件夹待会儿专门用来放模型文件，规整一点后面好找。

llama.cpp/            ← 解压出来的根目录
├── llama-server.exe  ← 启动服务的主程序
├── ...
└── models/           ← 自己新建的，放模型

下载主模型 + 视觉投影文件

回到模型下载页（H Company 在 Hugging Face 上放了完整的模型集合，也有人打包好了各种尺寸的 GGUF 版本）。这里要下载两个文件，缺一不可：

第一个：主模型。 因为我们用 llama.cpp，所以必须下 GGUF 格式。我是 24GB 显存，选的是 35B-A3B 的 Q4_K_M 量化版，体积大概 20GB（页面上可能标 19.8GB 到 21GB 之间，正常）。如果你显存小，就回去下对应的 9B / 4B / 0.8B 版本。

第二个：视觉投影文件（mmproj）。 就是前面反复提醒的那个、文件名通常以 MM 开头的小文件，只有几百兆。它负责把"图像"翻译成模型能理解的信号——没有它，模型就瞎了，电脑操作根本无从谈起。新手最常踩的坑就是只下了主模型，结果模型看不见屏幕，干瞪眼。

两个都下完，一起拖进刚才建好的 models 文件夹里。

准备一键启动脚本

接下来要让 llama.cpp 带着正确的参数把模型跑起来。手敲命令容易出错，所以做成一个批处理脚本（.bat 文件），双击就能启动。

操作很简单：把现成的启动脚本内容复制出来，在桌面新建一个文本文档，粘贴进去，然后"另存为"。另存的时候盯紧三个地方，错一个就启动不了：

• 编码选 UTF-8（不然中文路径和提示会乱码）；
• 保存类型选"所有文件"（不然会被强行加上 .txt 后缀）；
• 文件名写成 启动.bat（关键是 .bat 这个后缀，代表它是个可执行的批处理）。

存好之后，把这个 启动.bat 放到 llama.cpp 的根目录下（和 llama-server 主程序同级）。

如果你想理解脚本背后到底在干嘛，它核心其实就是调用 llama.cpp 的服务程序，大致是这么一条命令的样子（仅作示意，实际以脚本为准）：

# 示意：启动一个带视觉能力的本地模型服务
llama-server \
  -m ./models/Holo3.1-35B-A3B-Q4_K_M.gguf \   # 主模型
  --mmproj ./models/mmproj-Holo3.1.gguf \       # 视觉投影文件，让它能看图
  --host 127.0.0.1 \                            # 只在本机监听
  --port 1234 \                                 # 服务端口
  -ngl 99                                        # 尽量把层放到显卡上跑

这里 -ngl（GPU 层数）这个参数值得记一下：它决定把模型的多少"层"丢到显卡上算。值越大、用显卡越多、越快，但越吃显存。脚本通常会按不同显存档位预设好，你不用自己算。

按显存选启动模式，点火

双击运行 启动.bat。脚本一般会列出几种启动模式（常见是 5 种），对应不同的显存档位。这里就体现出"懂硬件"的好处了——按你的显存选对应那档就行，选高了会爆显存启动失败，选低了又浪费性能。我 24GB 显存，选的是偏高的那一档。

选好确认、放行权限请求，稍等模型加载。加载完成后，终端里会给出一个本地访问链接，类似 http://127.0.0.1:1234。

到这一步，发动机已经轰起来了。你可以在浏览器打开这个地址验证一下，能看到当前加载的模型信息就说明成功了。记住这个地址和端口，下一步对接 OpenClaw 时要用。 然后把这个窗口最小化但不要关闭——它一关，模型服务就停了，整套系统也就断电了。

如果这一步卡住了

第一步是整条链路里最容易出岔子的地方，我把自己和身边人遇到过的几种情况列出来，对照排查：

• 双击 启动.bat 一闪而过、窗口直接消失：多半是路径或文件名不对，或者保存时编码 / 后缀没设对。先确认那三个保存设置（UTF-8、所有文件、.bat 后缀）都对，再检查脚本里写的模型文件名和你实际下载的是否完全一致。
• 报显存不足 / out of memory：说明启动模式选高了，或者 -ngl 给太大。退回去选低一档的模式，或把分到显卡的层数调小，让一部分计算交给内存扛。
• 启动很慢、感觉全程在用 CPU：大概率是 llama.cpp 后端下错了（比如 N 卡却下了纯 CPU 版）。回到下载那步，N 卡认准 CUDA、A 卡认准 Vulkan/HIP 重新下。
• 浏览器打开本地地址看不到模型：稍等一会儿，大模型加载本身要时间；如果一直加载不出来，多半是模型文件没放对位置或文件损坏，重新核对 models 文件夹。

把这几条过一遍，绝大多数启动问题都能解决。

第二步：安装并配置 OpenClaw

发动机和大脑就位，现在装"手脚"——OpenClaw。这一步命令稍多，但逻辑很清晰：装好 OpenClaw，再告诉它"你的大脑在哪个地址"。

用管理员权限安装

OpenClaw 需要比较高的系统