1. 从“starnet”这个名字说起：它到底想解决什么问题

第一次看到“starnet”这个项目名，我脑子里蹦出来的不是某个具体产品，而是一种架构隐喻——星型网络。中心节点负责调度，外围节点负责执行，节点之间通过标准化协议通信。把这个隐喻放到当下的 AI agents 生态里，几乎是一拍即合：中心是一个桌面端的 agent 宿主程序，外围是各种能力节点（浏览器、数据库、设计工具、安全测试工具），它们之间靠 MCP 协议对话，靠 OpenRouter 这类模型网关统一接入大模型。

所以 starnet 本质上不是一个“软件”，而是一套桌面端 AI agent 的组网方案。它要解决的问题很具体：现在大家手里有一堆好用的工具——Docker Desktop 跑容器、Playwright 做浏览器自动化、Burp Suite 做安全测试、Figma 做设计稿读取、Redis Desktop Manager 看缓存——但这些工具彼此孤立，AI 想用它们，得一个个写胶水代码。starnet 的思路是：把这些工具都包装成 MCP Server，让桌面端的 agent 通过统一的 MCP 协议去调用，模型侧则统一走 OpenRouter，密钥、充值、模型切换都在一个地方管。

这套东西适合谁？三类人最该关注。第一类是独立开发者，想快速搭一个能操控本地工具的 AI 助手，不想从零造轮子；第二类是测试与安全从业者，希望 AI 直接操作 Playwright、Burp Suite 这类工具做自动化；第三类是效率工具爱好者，手里已经装了 Docker Desktop、Claude Desktop、GitHub Desktop 这一堆桌面软件，想让它们“活”起来，被 AI 串成一条流水线。

我先把话说在前面：starnet 这类方案的门槛不在代码，而在环境。Docker Desktop 起不来、虚拟化没开、MCP 连接没启用、OpenRouter 密钥配错，这四个坑能拦住八成新手。下面我按实际搭建顺序，把每个环节拆开讲，包括我踩过的坑和最后跑通的配置。

2. 整体架构设计：为什么是“桌面 + MCP + OpenRouter”这个组合

2.1 三层结构拆解：宿主、协议、模型网关

starnet 的架构可以拆成三层，我用一个生活化的类比来解释。想象你开了一家餐厅：桌面宿主是餐厅经理，负责接待客人（用户指令）、安排任务；MCP 协议是餐厅内部的对讲机系统，经理用统一的话术跟厨师、服务员、采购沟通；OpenRouter是食材供应商，不管你要川菜还是粤菜，都从这一个渠道进货，不用分别对接几十个供应商。

具体到技术层：

• 桌面宿主层：通常是 Claude Desktop、或基于 Electron/Tauri 自建的桌面应用。它负责 UI 交互、会话管理、MCP Client 的连接维护。选桌面而不是纯 Web，核心原因是本地工具（Docker、Burp Suite、本地文件系统）需要进程级访问权限，浏览器沙箱给不了。
• MCP 协议层：MCP（Model Context Protocol）是一套让模型和外部工具对话的规范。它定义了 Server 如何暴露工具（tools）、资源（resources）、提示（prompts），Client 如何发现和调用。你可以把它理解成“AI 工具界的 USB-C”——不管什么工具，只要实现 MCP Server，就能插上来用。
• 模型网关层：OpenRouter 提供统一的 API 入口，背后聚合了多家模型。好处是密钥只配一次，模型随时切换，充值走支付宝就行，不用每家模型单独注册。

提示：MCP 是软件协议，不是硬件协议。硬件里对应的概念叫“总线协议”（如 I2C、SPI），软件里 MCP 扮演的是类似的“标准化接口”角色。很多人第一次听到会混淆，记住它是跑在进程间的 JSON-RPC 就行。

2.2 为什么不用纯 API 直连，非要套一层 MCP

这是新手最常问的问题：我直接写代码调 OpenRouter API 不就行了，为什么要搞 MCP？答案在于复用性和解耦。

假设你有 5 个工具要接：Playwright、Burp Suite、Figma、Redis、Docker。纯 API 直连的做法是，为每个工具写一套 function calling 的 schema，塞进每次请求的上下文里。工具一多，上下文爆炸，而且每换一个模型，schema 格式可能还要微调。

MCP 的做法是：每个工具自己实现一个 MCP Server，对外暴露标准接口。宿主程序启动时，通过配置文件把这些 Server 挂载进来，模型看到的是一份统一的工具清单。换模型？不用改工具代码。加工具？改一行配置。这就是解耦的价值。

我实测下来，用 MCP 方式接入 5 个工具，配置文件大概 30 行 JSON，而纯 API 方式光 schema 就得写 200 多行，还得维护。差距很明显。

2.3 OpenRouter 在其中的角色：统一密钥与模型路由

OpenRouter 解决的是“模型碎片化”问题。现在模型更新极快，今天用这个，明天可能就换那个。如果每个模型都单独申请密钥、单独充值，管理成本很高。OpenRouter 把这件事收敛成一个 API Key、一个余额账户。

它的工作方式是：你发请求时指定模型名（比如anthropic/claude-3.5-sonnet或openai/gpt-4o），OpenRouter 负责路由到对应后端，返回结果。计费按实际用量扣，充值支持支付宝，对国内用户友好。

在 starnet 里，OpenRouter 的密钥通常配在宿主程序的环境变量或设置面板里，MCP Server 本身不直接碰模型，它只负责“执行工具”，模型调用由宿主统一发起。这个分工要搞清楚，否则容易把密钥配错地方。

3. 环境准备：Docker Desktop 与虚拟化这两个拦路虎

3.1 Docker Desktop 安装：从下载到汉化

starnet 的很多 MCP Server 是跑在容器里的，所以 Docker Desktop 基本是必装项。安装流程本身不复杂，但有几个细节决定成败。

第一步，去官网下载对应系统的安装包。Windows 用户注意，安装时会让你选 WSL 2 还是 Hyper-V 后端，优先选 WSL 2，性能和兼容性都更好。Mac 用户分 Intel 和 Apple Silicon 两个版本，别下错。

第二步，安装完成后首次启动，如果卡在“Starting the Docker Engine”很久，八成是虚拟化没开。Windows 上要进 BIOS 打开 VT-x/AMD-V，然后在“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。Mac 上一般不用管，但如果是虚拟机里套 Docker，要开嵌套虚拟化。

第三步，汉化。官方没有中文界面，社区有汉化包（比如 asxez/dockerdesktop-cn 这类项目）。用法是把汉化文件替换到 Docker Desktop 的 resources 目录下，重启生效。我的建议是：新手先别急着汉化，英文界面就那么几个词，汉化包版本跟不上的时候反而容易出问题。等用熟了再考虑。

注意：Docker Desktop 商用需要授权，个人学习免费。如果你在公司电脑上装，先确认一下授权政策，别踩坑。

3.2 “Virtualization support not detected”报错全解

这个报错我见过太多次了，docker desktop failed to start because virtualization support not detected，几乎每个 Windows 新手都会遇到。排查顺序如下：

我遇到最多的是 BIOS 虚拟化没开，其次是 Hyper-V 和 VMware 打架。如果你同时用 VMware，建议把 Docker 后端切成 WSL 2，冲突会少很多。

3.3 验证 Docker 是否真正可用

装完别急着往下走，先跑三个命令验证：

docker --version docker run hello-world docker ps

第一条看版本，第二条拉一个测试镜像跑起来，第三条看容器列表。三条都过了，说明 Docker 环境没问题。如果hello-world拉不下来，是网络问题，配一下镜像加速器。

我个人的习惯是，装完 Docker 先跑一个 Redis 容器练手，因为后面 starnet 接 Redis Desktop Manager 会用到：

docker run -d --name test-redis -p 6379:6379 redis:latest

跑起来后用 Redis Desktop Manager 或 Another Redis Desktop Manager 连localhost:6379，能连上就说明容器网络通了。这一步看着多余，其实是在提前验证“容器—宿主—桌面工具”这条链路，后面接 MCP 时省事。

4. MCP 协议实操：从配置到跑通第一个 Server

4.1 MCP 到底是什么：用对讲机类比讲清楚

MCP 全称 Model Context Protocol，核心就三件事：发现、调用、返回。宿主程序启动时，读取配置文件，知道有哪些 MCP Server 可用（发现）；用户下达指令，模型决定调用哪个工具，宿主转发给对应 Server（调用）；Server 执行完，把结果按标准格式返回（返回）。

通信方式主要有两种：stdio（标准输入输出，本地进程间通信）和SSE/WebSocket（网络通信，适合远程 Server）。本地工具一般用 stdio，远程服务用网络方式。你看到的wss://api.xiaozhi.me/mcp/?token=...这种，就是远程 MCP Server 的接入地址，token 是鉴权用的。

配置文件通常是 JSON，挂在宿主程序的设置里。以 Claude Desktop 为例，配置文件在~/Library/Application Support/Claude/claude_desktop_config.json（Mac）或%APPDATA%\Claude\claude_desktop_config.json（Windows）。结构大概是这样：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp-server"] }, "redis": { "command": "docker", "args": ["run", "-i", "--rm", "mcp/redis"] } } }

每个 Server 一个条目，command 是启动命令，args 是参数。宿主启动时会把它们拉起来，建立连接。

4.2 浏览器扩展里的“MCP 连接”开关

很多人不知道，Chrome 和 Edge 的开发者工具里已经内置了 MCP 相关的实验性功能。在扩展设置或开发者工具的实验选项里，能找到“启用 MCP 连接”之类的开关。打开后，浏览器会暴露一个本地 MCP 端点，让 AI 直接操控 DevTools。

这个功能配合 Playwright MCP 用，威力很大。传统 Playwright 是写脚本跑自动化，现在可以让 AI 实时看页面、点元素、读控制台。我实测过一个场景：让 AI 打开一个页面，自动找出所有 console error，然后定位到对应代码行。整个过程不用写一行脚本，全靠 MCP 工具调用。

开启方式（以 Chrome 为例）：地址栏输入chrome://flags，搜索 MCP，把相关实验项设为 Enabled，重启浏览器。然后在 DevTools 的设置里确认 MCP 端点已监听。具体端口每个版本可能不同，看 DevTools 里的提示。

提示：这个功能还在实验阶段，版本更新可能改位置。找不到就去 DevTools 的 Experiments 面板翻一翻，或者查对应版本的 release notes。

4.3 接入 Playwright MCP 与 Burp Suite MCP

Playwright MCP 是目前最成熟的浏览器自动化 MCP Server 之一。接入后，AI 能做的事包括：打开 URL、点击元素、填表单、截图、读 DOM、执行 JS。配置上，用 npx 拉起最省事，不用手动装依赖。

Burp Suite MCP 稍微特殊，因为 Burp 是 Java 应用，MCP Server 通常以扩展形式加载。流程是：在 Burp 的 Extender 里加载 MCP 扩展 jar 包，扩展启动后会监听一个本地端口，宿主程序通过这个端口通信。接入后，AI 能操控 Burp 做扫描、抓包分析、重放请求。安全测试从业者会很喜欢这个组合，因为很多重复性的抓包分析可以交给 AI 预处理。

我踩过的一个坑：Burp 的 MCP 扩展和 Burp 版本强相关，版本不匹配会加载失败。装之前先看扩展的 README，确认支持的 Burp 版本范围。另外，Burp 默认走代理，MCP 通信端口要加到“不拦截”列表里，否则请求会被 Burp 自己拦下来，形成死循环。

4.4 其他值得接入的 MCP Server 清单

除了上面两个，还有几个我实际用过、觉得有价值的：

• Figma MCP：读取设计稿的图层、颜色、间距，让 AI 直接根据设计稿生成代码。前端开发提效明显。
• Blender MCP：用自然语言控制 3D 建模操作，适合做原型。
• Unity MCP：游戏开发场景，AI 操控编辑器做场景搭建。
• Redis MCP：查询、写入缓存数据，配合 Redis Desktop Manager 做可视化。
• GitHub MCP：操作仓库、issue、PR，把 AI 接进开发流程。

这些 Server 的接入方式大同小异，都是“找到 Server 实现→写配置→重启宿主→验证”。建议一次只加一个，跑通了再加下一个，否则出问题不好定位。

5. OpenRouter 配置：密钥、充值与模型选择

5.1 获取 API Key 的完整流程

OpenRouter 的注册流程不复杂，但有几个细节。第一步，进官网注册账号，邮箱验证。第二步，进 Keys 页面创建一个新 Key，创建时立刻复制保存，页面刷新后就看不到了。第三步，把 Key 配到宿主程序的环境变量或设置里。

密钥的格式一般是sk-or-v1-开头的一长串。配置时注意别多复制空格，也别漏字符。我见过有人把 Key 配到 MCP Server 的配置里，结果不生效——记住，Key 是给宿主程序调模型用的，不是给 MCP Server 用的。

如果你在多个工具里用同一个 Key，建议给每个工具建单独的 Key，方便追踪用量和吊销。OpenRouter 的 Keys 页面支持给 Key 设额度上限，这个功能很实用，防止某个工具跑飞了把余额烧光。

5.2 充值方式与额度管理

OpenRouter 支持多种充值方式，国内用户常用的是支付宝。充值流程：进 Credits 页面，选金额，走支付，到账后余额显示在右上角。

额度管理有几个经验：

• 先充小额试水，比如 5 美元，跑通流程再追加。
• 给每个 Key 设上限，在 Key 的设置里可以限制这个 Key 最多花多少。
• 关注模型单价差异，不同模型价格差几十倍，用之前看清楚。
• 开启用量告警，余额低于阈值时邮件提醒。

我个人的做法是，主力 Key 设一个月度上限，测试用的 Key 设很低的上限，这样即使配置出错也不会大出血。

5.3 模型选择：不同任务配不同模型

OpenRouter 的好处是模型随便切，但别一个模型用到底。我的经验是按任务分：

在 starnet 里，agent 调度和工具调用是高频操作，这部分别省，用能力强的模型。具体的模型名 OpenRouter 官网有列表，按需选。

注意：模型名要写全，比如anthropic/claude-3.5-sonnet，只写claude会报错。切换模型时，先在小任务上验证，确认工具调用正常再上生产。

6. 常见问题与排查技巧实录

6.1 MCP Server 连不上的排查顺序

这是最高频的问题。排查按这个顺序走：

1. 看宿主日志：宿主程序一般有日志面板，MCP 连接失败会打错误。先看这里，能省一半时间。
2. 手动跑 Server 命令：把配置里的 command 和 args 复制到终端手动执行，看能不能起来。起不来就是 Server 本身的问题。
3. 检查路径和权限：stdio 方式要求 command 在 PATH 里，或者写绝对路径。Windows 上路径带空格要加引号。
4. 看端口占用：网络方式的 Server，检查端口是否被占。
5. 重启宿主：改完配置必须重启宿主程序，热加载不一定生效。

我遇到过一个诡异问题：Server 手动跑没问题，宿主里就是连不上。最后发现是宿主启动时的工作目录不对，导致相对路径解析错误。改成绝对路径就好了。

6.2 Docker 容器与 MCP 的联动坑

用 Docker 跑 MCP Server 时，有几个坑：

• 网络隔离：容器里的 Server 访问宿主服务，不能用localhost，要用host.docker.internal（Mac/Windows）或宿主 IP（Linux）。
• stdio 模式：Docker 跑 stdio Server 要加-i参数保持标准输入打开，否则通信会断。
• 镜像拉取慢：配镜像加速器，或者提前docker pull好。
• 资源限制：给容器设内存上限，防止 Server 跑飞拖垮宿主。

一个实测可用的配置示例：

{ "mcpServers": { "redis": { "command": "docker", "args": ["run", "-i", "--rm", "--add-host=host.docker.internal:host-gateway", "mcp/redis"], "env": { "REDIS_URL": "redis://host.docker.internal:6379" } } } }

关键是--add-host那行，保证容器能解析到宿主地址。

6.3 密钥与鉴权类问题速查

密钥问题九成是复制粘贴出错。建议复制后先在文本编辑器里看一眼，确认没有多余空格和换行。

6.4 性能与稳定性优化心得

跑通之后，优化方向有几个：

• 减少上下文体积：MCP 工具清单别一次全挂，按需加载。工具太多会拖慢每次请求。
• 缓存常用结果：比如 Figma 设计稿读取，同一稿子别反复拉。
• 并发控制：多个 MCP 调用别同时发，容易触发限流。
• 日志分级：调试时开详细日志，生产时关掉，减少 IO。
• 定期更新：MCP Server 和宿主程序都在快速迭代，定期更新能修不少 bug。

我个人的体会是，starnet 这类方案的稳定性，七分靠环境，三分靠配置。环境干净了，配置对了，跑起来很稳。环境乱，配置再对也白搭。所以新手别急着堆功能，先把 Docker、虚拟化、MCP 基础连接这三样弄扎实，后面加什么工具都是顺水推舟。

最后分享一个小技巧：建一个“最小可用配置”文件，只挂一个最简单的 MCP Server（比如文件系统读取），作为排障基线。出问题时，先切回这个基线，确认宿主本身没问题，再逐个加回其他 Server，能快速定位是哪个环节出的问题。这个习惯帮我省了无数排查时间。