身边不少朋友看到“AI Agent”四个字，第一反应就是得租一台服务器，然后装Linux、配环境、挂代理、配安全组……一套下来，还没开始写功能，人先被服务器折腾麻了。OpenClaw这个开源Agent框架，我最初也差点走上“租VPS”这条路，但实测下来，一台Windows台式机、一块RTX显卡，完全可以把整套Agent跑在本地——不用VPS，不用云主机月租，数据不出机箱，显存直接被本地推理引擎吃满。这篇文章就完整记录我这次从零开始，在纯Windows环境里安装OpenClaw，并用Ollama直驱RTX显存跑本地模型的全部过程，包括配置细节、踩坑记录和可以直接抄作业的方案。适合手头有N卡、不想折腾Linux、想快速把本地AI Agent真正用起来的朋友。
1. 为什么选择纯Windows本地方案，而不是VPS
1.1 先盘一盘云主机的几个现实痛点
这里聊的VPS，本质就是一台租来的云主机。很多人觉得部署Agent必须用它，其实是惯性思维：以前跑服务都放服务器上，于是Agent也照搬。但仔细算一笔账就明白了。
一台配置勉强够用的云主机，CPU推理跑个7B模型就已经很吃力，想流畅跑Agent的多次工具调用，至少得4核8G起步，带GPU的实例更是价格感人。一个月几十块看着不贵，一年下来几百上千，够买一块不错的二手显卡了。更别说还要管系统更新、网络波动、机房故障这些破事。我自己早几年用云主机跑自动化脚本，最怕半夜收到告警短信，登录上去一看，进程崩了，原因仅仅是磁盘满了或者内存被别的进程吃了。
数据隐私也是个大问题。Agent在工作过程中会读取你的文档、处理你的表格、甚至操作你的账号。这些数据如果在云主机上过一遍，等于把自己的一部分工作流交到了别人手里。本地Windows方案里，所有数据都在自己的硬盘上，推理也在本地显卡上完成，隐私边界清清楚楚。
网络依赖则是最后一个稻草。云主机部署的Agent，一旦主机和客户端之间的网络出现波动，或者机房的链路抽风，整个服务就跟着断。而本地方案跑在127.0.0.1上，只要机器开着，Agent就在。
1.2 这套方案适合谁，不适合谁
这套“Windows + OpenClaw + RTX显卡”的组合，最典型的适用人群有三类。
第一类是个人开发者或效率工具重度用户，想用Agent自动处理文件、整理资料、调用脚本，但又不想为了一点自动化需求去维护一台服务器。第二类是数据敏感场景的从业者，比如处理客户表格、内部文档、账号操作这类内容，数据留在本地方心。第三类就是单纯想尝鲜AI Agent的玩家，手头正好有一块RTX显卡，哪怕只有6GB显存，也能跑得有模有样。
但它也有明确边界。如果你需要7x24小时对外提供服务，或者要同时服务几十个用户，那桌面级Windows本机确实不合适，还是得回归专业服务器方案。再就是显存太小的话，比如4GB以下的核显或入门卡，跑起来会很憋屈，建议先用小模型体验流程，再考虑升级硬件。
我这次测试用的机器是RTX 5090 D 32GB显存的台式机，标题里也提到了这块卡。32GB显存意味着什么？跑一个7B-8B的量化模型绰绰有余，甚至可以往上够70B级别的量化模型。如果你手头是8GB显存的卡，也不用慌，跑7B-8B模型做日常Agent完全够用。
2. 先搞清楚OpenClaw是什么，以及Agent的运作逻辑
2.1 Agent框架的主流架构，OpenClaw站在哪一层
不少人对AI Agent的误解是：Agent就是一个聊天机器人，多轮对话而已。实际上，Agent的核心价值是把大模型从“纸上谈兵”变成“动手干活”。
主流Agent架构可以类比成一个三人小团队。大模型是大脑，负责理解任务、拆解计划、判断下一步做什么；工具是手脚，负责执行具体动作，比如读取文件、搜索网页、发送请求、调用API；记忆和上下文是记事本，负责记录任务背景和中间结果。Agent每完成一个任务，就要经历“思考 -> 调工具 -> 看结果 -> 再思考 -> 再调工具”的循环，直到任务完成为止。
OpenClaw这个开源框架，解决的就是“把大脑接上手和脚”这件事。它自己不提供大模型，但可以接上各种模型来源，尤其适合接本地推理引擎。它有技能（Skill）机制，让模型能调用外部工具；有管理层，让多个任务可以并发执行；还能通过配置文件控制模型的各类参数。我以前写自动化脚本，每个场景都得手写一套代码，有了Agent框架之后，我只需要告诉它“去扫描这个目录，把新生成的报告整理成摘要发到群里”，剩下的决策和调用它自己完成。
2.2 理解Token、上下文窗口和Agent的显存消耗
如果配置OpenClaw时看到Token这个词发懵，我来把它讲透。
Token是模型处理文本的最小单位。中文场景下，1个汉字大约对应1-2个Token。模型每一次思考，都要把“系统提示词 + 你的任务 + 历史对话 + 工具返回的结果”全部放进上下文窗口里。窗口越大，它能记住的信息越多，但同时显存占用也越大。
我举个例子：你给Agent的任务是“整理这个文件夹里所有Excel的数据”。它先要读取文件列表，然后把每个文件读进来，可能还要连续调用几次工具，每次返回的表格内容都占Token。如果上下文窗口只有2048，前几步就把窗口塞满了，后面的工具结果直接被截断，Agent就会“失忆”，表现就是答非所问。所以我配置OpenClaw时，显存够的情况下，一般把上下文窗口拉到8192甚至更高。
这也解释了为什么本地跑Agent比单纯跑聊天机器人更吃显存——Agent的工具调用会频繁产生长文本往返，上下文占用远高于普通聊天。
2.3 OpenClaw本地部署逻辑：算力必须走API吗
社区里有个高频问题：“OpenClaw只能用接入API的方式使用算力吗？”答案是：完全不是。
OpenClaw这类框架通常支持多种模型来源。第一种是本地推理引擎，比如Ollama、vLLM、GPUStack，模型跑在你自己显卡上；第二种才是云端API，比如OpenAI、Anthropic这类付费接口；第三种是兼容OpenAI接口的本地网关，本质还是本地算力，只是外面套了一层标准API外壳。
我这篇文章走的就是第一种，本地推理引擎Ollama + RTX显卡直驱。这种方案最大的好处是：不需要API Key，不算Token费用（严格说是本地不计费），断网也能跑，隐私完全不出本机。
3. 环境准备：Windows下把RTX显卡喂给Ollama
3.1 系统和驱动，先打个底
Windows版本方面，建议用Windows 10 22H2或Windows 11（比如现在的26H2版本），不要再折腾Windows 7了。2026年1月Windows 7 SP1已经彻底停止补丁支持，新版的Ollama和运行时在旧系统上兼容性也很差，我见过很多老系统跑起来各种莫名其妙的环境错误，最后还得换系统，浪费时间。
驱动方面，NVIDIA显卡装好较新的官方驱动即可，Game Ready和Studio版都行，关键是确保nvidia-smi命令能正常输出显卡信息。打开CMD，输入：
nvidia-smi能看到显卡型号、驱动版本、显存总量，就说明驱动没问题。
然后还要顺手做一件事：检查虚拟内存。Windows默认识别不到你即将跑的大模型，模型加载时如果物理内存紧张，虚拟内存不够会导致进程被杀。建议把虚拟内存设置为32GB以上，放在剩余空间比较充足的盘上。
3.2 安装Ollama，配置GPU直驱
Ollama是目前在Windows上跑本地模型最省事的推理引擎，从官网下载安装包一路Next就装好了。安装完成后，先做两个环境变量配置，避免后面遇到坑。
第一个是OLLAMA_MODELS，指定模型存放目录。默认模型会下到C盘用户目录，而模型文件动辄几个GB，C盘分分钟爆掉。我习惯设成OLLAMA_MODELS=D:\ollama_models。第二个是OLLAMA_HOST，默认127.0.0.1:11434就够了，本地访问不用改。
接下来验证GPU直驱是否生效。启动Ollama服务后，拉一个主流开源模型试试，比如：
ollama pull qwen2.5:7b-instruct然后看模型是不是跑在GPU上：
ollama ps输出里PROCESSOR那列如果显示GPU，就说明RTX显卡在干活。我第一次跑的时候，这列显示的是CPU，排查了半天才发现是Ollama版本太旧，升级到新版后立刻识别到了显卡。如果你也遇到这种问题，不要慌，先检查驱动和Ollama版本，大概率是版本不匹配。
关于模型选型，我做了一个当前主流开源模型的参考表格：
| 显存容量 | 推荐模型规模 | 典型模型示例 | 适合场景 |
|---|---|---|---|
| 6GB | 3B-4B量化 | qwen2.5:3b | 简单对话、脚本调用 |
| 8GB | 7B-8B量化 | llama3.1:8b | 日常Agent的甜点区 |
| 12GB | 12B-14B量化 | qwen2.5:14b | 复杂任务、更长上下文 |
| 24GB | 32B量化 | qwen2.5:32b | 接近商用能力 |
| 32GB | 70B量化 | qwen2.5:72b | 标题同款RTX 5090 D可跑 |
选型逻辑也很简单。每10亿参数，FP16精度约需2GB显存，Q4量化后约需0.6-0.8GB。7B模型量化后大概需要6GB左右，14B需要11GB左右，70B量化大约需要32GB。再加上上下文窗口的KV Cache开销，所以32GB显存跑70B量化模型基本卡在极限边缘，实际使用建议留一点余量。
4. OpenClaw安装与初始配置，核心是config文件
4.1 获取OpenClaw并装好依赖
openclaw项目托管在GitHub上，搜索“OpenClaw”就能找到仓库。安装方式有两种，一种是直接下载发布版压缩包，解压即用；另一种是拉源代码自己构建，适合想二次开发的人。我用的是源码方式，Windows下装好仓库要求的运行时环境后，在项目根目录安装依赖就行。
这里有一点经验之谈：不要着急改源码，先把官方示例配置跑通一遍。我见过太多人一上来就想改代码加功能，结果依赖没装全、环境不对，报了一堆错，最后连基础demo都没跑起来。先把默认配置跑通，再逐步改，这才是正确节奏。
4.2 核心配置：让OpenClaw接上Ollama
OpenClaw的配置核心是一个config文件，所有关键行为都在这里定义。不同版本的字段命名会有些差异，但结构大体如下：
agent: name: openclaw-local model: qwen2.5:7b-instruct ollama: base_url: http://127.0.0.1:11434 context_window: 8192 temperature: 0.7 system_prompt: | 你是运行在本机的个人助理OpenClaw。 你的运行环境是Windows，GPU为RTX显卡。 回答问题要简洁，需要工具时主动调用Skill，所有回复使用中文。几个关键参数背后都有讲究。
base_url填Ollama的本地地址，127.0.0.1:11434就是Ollama默认端口，如果改了环境变量就对应调整。context_window是上下文窗口，显存有余量就尽量设大，8GB显存跑7B模型建议8192起步。temperature是随机性参数，0.7属于平衡值，做内容创作可以调到0.9，做数据整理、脚本生成这种精确度要求高的任务，建议调到0.2-0.3，减少模型“发挥”。
system_prompt最容易被人忽略，但它决定了Agent的“人设”和工作方式。我见过有人不写这个字段，结果Agent完全不知道自己能调工具，遇到问题只会说“抱歉，我无法完成这个操作”。写清楚“需要工具时主动调用Skill”，效果天差地别。
4.3 第一次启动，观察决策循环
配置写好之后，启动OpenClaw，然后在对话界面里给它一个简单任务，比如“查看当前目录下有哪些文件”。
这时候你能在日志里看到它的完整决策过程：先是思考如何完成任务，然后调用文件读取工具，拿到结果后再思考，最后组织语言输出。这个过程就是Agent的核心决策循环。多观察几次，你对“Agent是怎么工作的”就有了直观理解，后面调参和写Skill都会更有感觉。
5. Skill机制与实操：从内置技能到自定义技能
5.1 Skill是什么，跟插件有什么区别
如果说Agent框架是身体，Skill就是手臂。一个Skill通常包含三部分：技能描述文件（告诉模型这个技能是干什么用的）、提示词模板（教模型怎么用这个技能）、脚本程序（真正干活的代码）。
举个生活化的例子。你请了一个助理，助理本身有脑子（模型），但你要给他写工作流程SOP（技能描述），还要给他配好工具箱（脚本）。比如“整理Excel数据”这件事，SOP里写清楚要做哪些步骤，工具箱里有操作Excel的函数，助理就能独立完成，而不是你每次手把手教。
OpenClaw内置了一些常用Skill，比如文件读写、网页搜索、HTTP请求、代码执行。但真正体现价值的是自定义Skill，因为你最清楚自己需要什么。
5.2 实操示例：写一个“局域网消息通知”Skill
我来演示一个我现在还在用的Skill：定时扫描指定目录里的新文件，并把文件名通过Webhook发到企业微信群。业务场景很常见：每天有人往文件夹里丢报表，我需要第一时间知道。
Skill的目录结构大概是这样的：
skills/ notify_webhook/ skill.yaml run.ps1 prompt.mdskill.yaml里写技能名称、触发条件和默认参数。prompt.md里写使用说明，告诉模型什么时候该调用这个技能、参数怎么填。run.ps1是真正干活的脚本，Windows下我用PowerShell，核心就几行：
$body = @{ msg = $env:OPENCLAW_MSG } | ConvertTo-Json Invoke-RestMethod -Uri "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxx" -Method Post -ContentType "application/json" -Body $body配置好之后，我只需要对Agent说“帮我看下D:\reports目录下今天有没有新文件，有的话通知我”，它就会自动调用Skill，读目录、判断时间、发Webhook，整个过程不需要我写一步命令。
5.3 电商与运营场景的落地思路
结合热词里的“openclaw电商”，我再说一个实际思路。电商运营经常要处理订单数据、客户留言、商品描述。以前我的做法是写一堆一次性脚本，现在直接用OpenClaw配上电商相关的Skill。
比如让它每天定时读取订单表格，筛选出异常订单（退货、超时未发货），生成摘要后通过邮件或Webhook发出来；或者给它一份商品参数表，让它批量生成商品描述草稿，方便运营润色后发布。这类任务本质是“读取数据 -> 分析整理 -> 输出结果”，正好是Agent框架最擅长的活。
这里必须强调一条红线：凡是涉及自动发布、自动回复外部平台的，先搞清楚平台API权限和频控限制。社区里有人讨论“让Agent自动发小红书消息”，我的态度是，做提醒类、草稿类、数据整理类完全没问题，但自动化发布到公开平台，一定要确认目标平台规则，该走官方API走官方API，该人工审核就保留人工审核环节。Agent是帮你提效的，不是替你去踩平台的合规线。
5.4 Skill设计的两条经验
第一个经验是Skill职责要单一。一个Skill只解决一类问题，不要贪多。Skill描述写得越清楚，模型调用的准确率越高。我的两个Skill“读取Excel生成摘要”和“发送Webhook通知”就是从同一个大Skill里拆出来的。
第二个经验是异常处理要写在脚本里。脚本本身要做容错，比如目录不存在、网络超时、返回非200状态码，都要有默认行为。模型不会在脚本报错时帮你自动重试，它只会拿到报错信息然后告诉你出错了。脚本越健壮，Agent才越靠谱。
6. Windows下的OpenClaw常见问题排查实录
6.1 服务起不来，端口被占用
这是Windows上最常碰到的问题之一。启动Ollama或者OpenClaw时，提示端口被占用，最常见的两个端口是11434（Ollama默认）和OpenClaw自身的服务端口。
排查方法很简单，CMD里执行：
netstat -ano | findstr 11434找到占用端口的PID后，到任务管理器里确认进程，如果是残留的旧进程就直接：
taskkill /PID 1234 /F如果是别的程序占用了端口，可以手动修改Ollama或OpenClaw的默认端口。总之，先看清楚是谁占的，再决定是杀掉还是换端口。
6.2 模型跑起来了，但Agent智商不在线
模型明明已经加载进GPU了，回答却总是答非所问，或者遇到稍微复杂一点的任务就卡住。
大概率原因有三个。第一，模型太小，3B以下的模型做工具调用的能力很弱，只能简单对话，建议至少上7B模型。第二，上下文窗口设太小，工具调用结果刚返回就被截断，Agent等于“失忆”了，把context_window调大一些，同时观察显存占用。第三，系统提示词没写清楚，没有明确告诉它要调用Skill，或者某些Skill没有出现在描述里，模型根本不知道有这些工具可用。
6.3 显存爆了，OOM报错怎么处理
Windows下跑本地模型，CUDA out of memory是避不开的坎。显存不够时，按优先级做三件事。
第一步，减小上下文窗口。8192降到4096，能省下一大块KV Cache显存。第二步，换更低精度的量化版本，Q4降Q3，能明显减小模型体积。第三步，检查系统里是不是同时加载了多个模型，用ollama ps看一下，把不用的模型卸掉：
ollama rm llama3.1:latest还有一个小技巧：用ollama serve启动时，设置环境变量OLLAMA_KEEP_ALIVE=5m，让模型空闲5分钟后自动从显存中释放，避免长期占用。这个设置对普通用户很实用。
6.4 Windows特有的几个坑
Windows上跑开源项目，总是有一些系统的老毛病，我整理成了一张速查表：
| 现象 | 大概率原因 | 解决动作 |
|---|---|---|
| PowerShell脚本无法执行 | 执行策略受限 | Set-ExecutionPolicy RemoteSigned -Scope CurrentUser |
| 控制台中文乱码 | 代码页不对 | CMD里执行chcp 65001切到UTF-8 |
| 杀毒软件拦截进程 | 误报 | 把项目目录和Ollama目录加入白名单 |
| 路径含空格导致脚本失败 | 未加引号 | 代码里统一用英文引号包裹路径 |
| 中文目录名编码报错 | 字符编码不一致 | 统一用UTF-8 with BOM保存脚本文件 |
尤其注意最后一条。Windows默认的中文编码是GBK，而开源项目大多是UTF-8，两种编码不一致，容易在读取文件路径时炸掉。我的习惯是：所有配置文件、脚本文件统一UTF-8，浏览器配置用UTF-8，问题能少一大半。
7. 进阶玩法：从单机到局域网，再到更多扩展
7.1 把OpenClaw变成局域网服务
本地跑通之后，下一步十有八九是让手机或另一台电脑也能访问。Windows下要做两件事。
第一件事，把Ollama的监听地址改为0.0.0.0，这样局域网设备才能通过主机IP访问11434端口。设置环境变量：
setx OLLAMA_HOST "0.0.0.0"第二件事，Windows防火墙添加入站规则，允许TCP 11434端口通过。然后局域网内其他设备就能通过http://主机IP:11434访问了。
这里必须提醒一句：暴露到局域网等于打开了执行入口，Agent能调用脚本，意味着局域网内其他人也有权限操作这个Agent。务必确认你的局域网可信，不要直接映射到公网。公网映射这扇门，我建议直接不打开，真要对外服务，老老实实走专业服务器。
7.2 对接ROS2与机器人仿真生态
OpenClaw的能力边界不在桌面端。社区里有人把OpenClaw和ROS2 Humble、Gazebo仿真环境连起来，做机器人行为实验。思路是让Agent通过Skill调用ROS2的action/service接口，自动规划机器人在仿真场景里的运动行为。
这个方向很有意思，但门槛比桌面应用高不少。ROS2在Windows上跑，要么走WSL，要么得双系统，环境复杂度直线上升。我的建议是先把桌面版跑通，对OpenClaw配置和Skill机制熟悉了，再考虑仿真联动。我手头也在折腾这个方向，等跑通了再单独写一篇，现在不展开。
7.3 手机端访问Roadmap
手机端访问是另一个方向。社区里有人用Termux在安卓上跑OpenClaw，手机内存够的话能跑小模型，但性能和存储都受限，更多是图个便携演示。真正要干活，还是得回到桌面显卡上。手机端适合做的是“远程查看状态、发指令、看结果”，也就是当成一个移动控制台来用，而不是指望手机跑大模型。
7.4 后续扩展：MCP协议、知识库、多Agent协作
最后聊几个我接下来准备试的方向。
MCP协议现在是Agent生态里的热门话题，它统一了Agent和外部数据源的接入方式，本地知识库、数据库、办公套件都能通过MCP接进来。OpenClaw如果支持MCP，就能把Notion、飞书文档、SQLite这些日常工具全部变成Agent的可调用资源。知识库方面，给Agent挂一个本地向量库，它就不再是“记忆力只有一段上下文”的对话机器了，而是能把你自己积累的文档变成长期记忆。多Agent协作也值得关注，一个Agent做任务规划，另一个Agent负责执行，适合更复杂的业务流。这几个方向，都是同一套OpenClaw框架上长出来的，配置思路不会变，只是Skill和工具层的复杂度高了。
这套“Windows + OpenClaw + RTX显卡”方案，我自己跑下来最大的感受是：本地Agent的价值不在于参数多炫、模型多大，而在于能把那些重复性的、需要串联多个工具的动作交给它，而且全程数据不上云。如果你手头正好有一块RTX显卡，建议先别急着买服务器，就按这篇文章的流程，先用一个7B-8B小模型把OpenClaw跑通，把Skill机制玩明白，再考虑换更大的模型和更复杂的场景。我踩过最大的坑不是安装，而是总想一步到位上70B大模型，结果环境问题一堆、交互卡成PPT。从小的开始，反而更快。
