这是构建 Agent 系统绕不开的四个基础词。一次性把它们的区别、各自干什么、为什么 OpenViking 都需要——讲透。
这是计算机软件最古老的两个角色。一句话：Server 是干活的，Client 是发号施令的。
百度网盘：你硬盘里所有文件其实都在百度的服务器机房里——那是 Server。你电脑/手机上装的"百度网盘 App"只是一个能上传下载的小工具——那是 Client。App 卸了文件还在，机房断电了 App 就啥也干不了。
MySQL 数据库 也一样：数据库本体（MySQL Server）在某台机器上跑着，你打开 Navicat 连过去查数据——Navicat 就是 Client。
真正"干活"的那个进程。所有数据、索引、计算都在它这里。
127.0.0.1:1933"用"那个服务的工具。它本身什么都不存，只负责把你的请求发给 Server。
ov、Python import openviking、HTTP curl 都算它们之间长这样：
这张图里有三个东西在不同地方：你 Windows 上跑的 Client 很轻，远程 Linux 服务器上跑的 Server 是重头，而 Server 自己还要去调火山引擎的 API（下半部分要讲的 Embedding 和 VLM）。
直接对应到你的具体场景。
你在 Windows 上只装一个轻量的 ov 命令行工具，或者写 Python 代码 import openviking。它们通过 HTTP 连到远程 Server（比如你 PuTTY 连的那台 Linux）。Windows 这边几乎没负担，BOM 那些边角问题也完全碰不上——因为重活都在 Linux 那边干。
把整个服务装在 Windows 上，监听端口、存数据、处理请求都在 Windows 上完成。这就是 v0.2.6 之前坑多的地方——UTF-8 BOM、路径分隔符、Go 二进制兼容、文件锁等一堆 Windows 特有问题。能跑通，但折腾。要在 Windows 上跑 Server，请走 WSL2（Windows 里的 Linux 子系统）或 Docker Desktop，那样实际上还是 Linux 在跑。
Client 只是个"遥控器"，跨平台没压力；Server 是"主机"，原生跑在 Windows 上历来都比 Linux 麻烦。 这不是 OpenViking 独有的问题，是所有 Linux 系开源服务的通病。
RAG / 向量数据库 / 语义搜索的底层基础设施。
Vision-Language Model 的缩写。是个能"看"又能"说"的多模态模型。
普通 LLM 只懂文字；VLM 还能"看"图。GPT-4V、豆包·视觉版、Gemini 都是 VLM。
VLM 跟你平时用的 ChatGPT/Claude 是同类，只是多了一只"眼睛"——你可以扔一张截图、PDF、产品照、流程图给它，它能描述、提取信息、回答关于图片的问题。
在 OpenViking 里，VLM 实际上承担两个职责——很多人以为它只用来处理图片，其实更重要的是第二个用途：
两件事各干各的，缺一不可。
▸ 场景 ① 新增一份资料 (fan-out)
▸ 场景 ② 搜索一份资料 (linear)
没有 VLM → 没有 L0/L1 摘要 → 三层加载机制失效
没有 Embedding → 没法做语义搜索 → find 命令直接报废
所以"OpenViking 必须连外部 embedding+VLM API"的真正含义是：OpenViking 自己没有大脑，它本质上是个聪明的"上下文管理器"，但具体的"理解能力"——读懂、总结、向量化——必须借给外部模型完成。
所谓"外部 API"，就是火山引擎的 Ark 平台、OpenAI 的 API、Gemini 的 API 这种云端模型服务。你的 OpenViking Server 在处理数据时，会用 HTTP 调用它们，把 embedding 和 VLM 的工作"外包"出去，然后把结果拿回来存。
用一句话把这次学的东西全部串起来：你 Windows 工作机上的代码（Client）通过 HTTP 调用部署在某台 Linux 服务器上的 openviking-server（Server），Server 在存数据时调用火山引擎的 Embedding API 把内容向量化，调用 VLM API 生成 L0/L1 摘要；你搜索时 Server 又用 Embedding API 把你的问题转成向量去比对——整个链路里 OpenViking 自己不做任何 AI 推理，它只负责"组织"和"调度"。
这种设计的好处是解耦：embedding/VLM 模型随时可以换（豆包换 OpenAI、再换 Gemini，改个配置文件的事），但你那套上下文文件系统不动。