OpenViking CLI(ov)安装、配置与验证完全指南:从手动向导到 Agent 自动化配置
【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking
导读
本文是 OpenViking 客户端 CLI(ov)的配置实战指南,覆盖从安装、连接目标选择、密钥类型理解,到手动交互式配置与 Agent 非交互式自动化配置的完整流程,并深入到仓库源码层面解释配置文件的存储机制、退出码语义与密钥安全约定。读完本文,你将掌握:ov的三种安装方式、~/.openviking/ovcli.conf的 active/命名配置机制、OpenViking Service(火山引擎云)与自定义服务端的连接配置、user key / root key 的差异与组合方式,以及如何在 Agent 场景下安全、确定性地完成 CLI 配置与验证。
重要前提:
ov是客户端 CLI,它负责连接一个已经存在的 OpenViking 服务端,或连接 OpenViking Service(火山引擎云)托管服务。它不是服务端安装命令。如果你还没有安装或启动自定义 OpenViking 服务端,请先阅读 快速开始 或 服务端模式。
你可以用两种方式阅读本文:
- 如果你自己手动配置
ov,请阅读手动配置; - 如果你让 Agent 帮你配置,请把本文交给 Agent,并让它阅读 Agent 辅助配置。
CLI 会持续演进,请把ov --help和ov <command> --help作为当前安装版本命令准确信息的最终来源。当本文与本地帮助不一致时,以本地帮助为准。
本文配置什么:配置存储机制
CLI 使用~/.openviking/ovcli.conf作为active 客户端连接配置(即当前生效的配置)。
- 创建命名配置时,
ov会把配置保存为~/.openviking/ovcli.conf.<name>; - 切换配置时,
ov会把选中的已保存配置复制到~/.openviking/ovcli.conf,使其成为 active 配置。
ov config是面向人的交互式配置管理器,可以新增、编辑、删除、校验和切换配置。而ov config add、ov config edit、ov config list、ov config switch <name>和ov config delete是面向脚本和 Agent 的确定性命令——它们不依赖交互菜单,参数确定时结果可预期、可重复执行。
从源码看,默认配置路径由 default_config_path() 定义,即用户主目录下.openviking/ovcli.conf;同时支持通过环境变量OPENVIKING_CLI_CONFIG_FILE覆盖配置文件路径(见 config.rs 中的OPENVIKING_CLI_CONFIG_ENV常量与load_required()的解析顺序:环境变量优先于默认路径)。配置文件本身是 JSON 格式,Config 结构体定义了完整的字段集合,包括url、api_key、root_api_key、account、user、actor_peer_id、agent_id、timeout(默认 60 秒)、output(默认table)、echo_command、show_progress、verbose、profile、upload、extra_headers、gateway_token、auth_mode等。其中timeout必须为正的有限秒数,output只接受table或json(见 validate_runtime_values() 的实现,非法值会被运行时的普通命令拒绝,但允许ov config加载以便修复)。
选择连接目标
运行配置命令前,首先要明确要连接哪种 OpenViking 目标。除非用户已经明确说明,Agent 应先询问用户;已有配置、active 配置、本地文件、默认端口和正在运行的服务只能帮助 Agent 追问细节,不代表用户同意Agent 选择目标、切换或替换配置、探测本地服务、启动服务端或写入数据。
OpenViking Service(火山引擎云)
如果你希望使用火山引擎云上的 OpenViking 托管服务,选择此项。
ov使用的服务端端点:https://api.vikingdb.cn-beijing.volces.com/openviking- 管理 API Key 的控制台页面:
https://console.volcengine.com/vikingdb/openviking/region:openviking+cn-beijing(在控制台进入 User Management → API Key,查看并复制你的 key) - API Key 必填。
- 标准配置只需要 API Key。除非用户的管理员明确提供身份覆盖值,否则不要询问
--account或--user。
该固定端点在源码中以常量形式定义,见 store.rs 中的 OPENVIKING_SERVICE_URL。ov-service目标不接受自定义服务端 URL。
远程自定义
如果你要连接不在当前机器上的自定义 OpenViking 服务端,选择此项。
- 服务端 URL 由用户或服务端管理员提供。
- 可能需要 API Key。
- 只有 root key 的配置需要
--account和--user。
源码层面,远程自定义配置强制要求 API Key:custom_requires_api_key(url)的实现是「非 localhost 即必须带 key」(见 store.rs)。
本地自定义
只有当用户要连接当前机器上的自定义 OpenViking 服务端时,才选择此项。
- 本地默认 URL:
http://127.0.0.1:1933 - 本地无鉴权服务通常不需要 API Key。
- 除非用户选择本地自定义配置,否则 Agent 不应探测本地端口、curl 本地 health endpoint,或运行启动服务端的命令。
本地默认 URL 与默认端口在 config.rs 中定义(DEFAULT_CUSTOM_PORT = "1933"、DEFAULT_CUSTOM_URL = "http://127.0.0.1:1933")。本地豁免鉴权的判定逻辑见 custom_allows_empty_api_key():只有 host 为localhost、127.0.0.1、::1或[::1]时允许空 API Key。normalize_custom_url()(store.rs)还会把localhost、127.0.0.1、::1等简写自动规范化为带默认端口的http://URL,并把结尾多余的/去掉。
注意:显示语言要求(v0.3.23+):最近的 CLI 版本要求在运行大多数命令前先保存一个显示语言。在交互式终端中,CLI 会在首次使用时提示你选择;在非交互式 shell(Agent 或 CI)中,任何非豁免命令都会以退出码
2结束,直到你运行ov language en或ov language zh-CN。只有ov language/ov lang、ov config add|edit|delete|list和ov config switch <name>是豁免的,因此请在ov config validate、ov health和ov status之前先运行ov language <code>。
开始前:你需要准备什么
- 一种安装 CLI 的方式:
- 使用 Node.js 和 npm 安装独立的
@openviking/cli包,或 - 使用 Python 工具安装完整的
openviking包。
- 使用 Node.js 和 npm 安装独立的
- 一个可访问的 OpenViking 目标:OpenViking Service(火山引擎云),或自定义 OpenViking 服务端。
- 如果目标需要鉴权,准备 API Key。
API Key 是敏感凭证。手动配置时优先通过ov config的交互式输入框输入。只有当你明确相信当前渠道时,才把 API Key 提供给 Agent。Agent 应通过 stdin 传入 key,不能把 key 写进 shell 命令、日志、长期记忆或原始配置输出。只有当 key 已经存在于当前 shell 环境变量中时,才使用环境变量。
安装 ov
先检查是否已经安装:
command -v ov ov --version如果ov --version或任何其他ov命令提示 OpenViking 需要显示语言,请先选择语言再重试:
ov language en # 或 ov language zh-CN安装或升级 npm 包(最轻量的独立 CLI 安装方式):
npm i -g @openviking/cli也可以从源码构建 Rust CLI:
cargo install --git https://github.com/volcengine/OpenViking ov_cli说明:仓库内
ov_cli的 Rust 实现位于 crates/ov_cli,其入口为 main.rs;同时 Python 侧还有对应的openviking_cli包(openviking_cli),其 rust_cli.py 负责与 Rust CLI 交互。如果你同时需要 Python SDK 或服务端包,Python 包也会提供ov:
uv tool install openviking --upgrade # 或 pip install openviking --upgrade --force-reinstall验证安装:
ov --help如果仍然找不到ov,关闭并重新打开 shell,或检查 npm 全局 prefix:
npm prefix -g在 macOS 和 Linux 上,全局 npm binary 目录通常是$(npm prefix -g)/bin,确认该目录已经加入PATH。
密钥类型:user key 与 root key
OpenViking CLI 配置可以包含 user key、root key,或同时包含两者。
- User key:用于普通数据命令,例如
ov add-resource、ov find和ov tree。服务端会从 key 推导身份,所以通常不需要传--account或--user。这是大多数用户需要的方式。 - Root key:用于管理操作和需要
--sudo的命令。Root key 自身不包含租户身份。如果一个配置只有 root key,就必须同时包含--account和--user;这个 root key 会同时服务于该身份下的普通命令和--sudo命令。 - User key + root key:适合一个配置同时支持日常数据操作和偶尔的管理操作。普通命令使用 user key,
--sudo命令使用 root key,并带上配置中的 account 和 user。
从源码看,这一语义体现在 effective_auth_with_overrides() 中:当sudo为真时优先取root_api_key,否则取api_key,并回退到root_api_key;account与user支持命令行覆盖(--account、--user),与配置中的值合并后随 HTTP 请求下发。此外,配置还支持actor_peer_id(与agent_id互斥,同时设置会在加载时报错,见 validate_identity_mode()),用于标识执行命令的 Agent 身份。
手动配置
如果你准备自己配置ov,使用这条路径。
运行:
ov config然后选择:
Add configOpenViking Service(火山引擎云)或自定义- 配置名称,或留空自动生成
- 上面选择的目标所需的 URL 和 API Key
- 校验成功后保存配置
如果你维护多个 OpenViking 目标,之后可以使用:
ov config switch切换 active 配置。配置完成后,继续阅读验证配置。
Agent 辅助配置
如果 Agent 正在替用户配置ov,使用这条路径。Agent 应该阅读整篇文档;当确定性命令不适合用户环境时,上面的手动配置流程就是回退路径。
Agent 检查清单
- 除非用户已经明确说明,先询问用户要连接哪种目标:OpenViking Service(火山引擎云)、远程自定义,还是本地自定义。
- 不要根据已有配置、active 配置、本地文件、默认端口或正在运行的服务推断用户想要的 setup。
- 切换配置、替换配置、探测本地服务、启动服务端或写入数据前,都要先询问用户。
- 在选择命令前,运行
ov --help、ov config --help和相关 config 子命令的帮助。 - 如果你具备长期记忆能力,并且用户允许,可以记录当前
ov --help命令面的简要摘要。不要记录 API Key 或其他密钥。 - 当必需信息明确时,使用非交互式
ov config命令。 - Agent 配置时始终传
--name,这样重试会命中同一个 saved config。 - 如果 Agent 已经通过可信渠道拿到 API Key,使用
--api-key-stdin或--root-api-key-stdin,并且只把 key 内容写入 stdin。只有当环境变量已经存在时,才使用--api-key-env或--root-api-key-env。不要要求用户额外打开一个 shell 只为了给 Agent export 一个 key。 - 使用
-o json,并根据 JSON 结果和进程退出码分支处理。 - 使用
ov config validate校验 active 配置,然后运行ov health和ov status。 - 如果非交互式配置因为信息缺失、鉴权不明确或终端输入更安全而失败,请引导用户使用
ov config交互式向导。
查看当前安装的 CLI
运行:
ov --help ov config --help ov config add --help ov config add ov-service --help ov config add custom --help ov config edit --help以当前安装版本的 CLI 帮助为准。如果本文与本地帮助不一致,请遵循本地帮助,并告诉用户差异是什么。
如果 help 命令提示 OpenViking 需要显示语言,请运行ov language en;如果用户希望使用中文,则运行ov language zh-CN,然后重试。ov config add、ov config list、ov config edit、ov config switch <name>和ov config delete等非交互式 config 子命令可以在设置显示语言前运行。
使用稳定名称便于重试
Agent 创建配置时始终传--name。如果省略名称,ov会随机生成名称;重试时可能创建第二个 saved config,而不是更新预期的配置。
当传入相同--name且配置内容完全一致时,ov config add可以安全重复运行。它会以退出码0结束,--activate也会再次把该 saved config 设为 active。如果同名配置已经存在但内容不同,命令会以退出码3结束,并要求只有在确认替换时才使用--force。
下面示例中的<CONFIG-NAME>和<REMOTE-OPENVIKING-URL>等占位符需要替换成用户确认过的值再运行,运行时不要保留尖括号。
读取结果:JSON 输出与退出码
对非交互式 config 命令使用-o json时,成功结果会输出到stdout:
{"status":"ok","result":{"action":"add","name":"<CONFIG-NAME>"}}result对象会随子命令变化。add和edit还会包含kind、url、saved_path、active_path、activated和validation等字段(这一点与源码中 AddEditResult 的序列化字段一一对应),因此 Agent 不应该假设结果里只有action和name。
错误结果会输出到stderr:
{"status":"error","error":{"code":"bad_input","message":"..."}}Agent 应该根据进程退出码和 JSON 中的error.code分支处理,不要解析面向人的说明文字。退出码常量在 config_agent.rs 中直接定义:
| 退出码 | 含义 |
|---|---|
0 | 成功,或已经处于目标状态 |
2 | 输入错误、缺少参数、名称非法、无法读取密钥来源,或在非交互式 shell 中尚未选择显示语言(请先运行ov language <code>) |
3 | 同名配置已经存在但内容不同;只有确认要替换时才传--force |
4 | 服务端不可达,或配置校验失败 |
5 | 鉴权或 key 角色不匹配,例如把 root key 传到了需要 user key 的位置 |
6 | 操作被拒绝,例如删除 active 配置 |
对应的错误类型(bad_input、config_exists、validation_failed、auth_mismatch、refused)也封装在 AgentError 中,便于 Agent 按error.code稳定分支。
列出已有配置
ov config list -o json列表输出形状如下:
{"status":"ok","result":[{"name":"<CONFIG-NAME>","kind":"OpenViking Service","url":"https://api.vikingdb.cn-beijing.volces.com/openviking","active":true}]}做存在性检查时,读取result[].name;判断是否还需要切换 active config 时,读取匹配项的active标记。
如果已经存在合适的 saved config,可以按名称激活:
ov config switch <CONFIG-NAME> -o json然后运行验证命令。
添加 OpenViking Service(火山引擎云)
如果 Agent 已经通过可信渠道拿到 API Key,运行:
ov config add ov-service --name <CONFIG-NAME> --api-key-stdin --activate -o jsonshell pipe 形式如下:
printf '%s' "$API_KEY" | ov config add ov-service --name <CONFIG-NAME> --api-key-stdin --activate -o json$API_KEY表示可信的运行时密钥来源,不是字面量 key。Agent 能在不把 key 写进命令文本、shell history、日志或长期 export 的环境变量时提供 key,就应使用 stdin。
只把 API Key 内容写入 stdin,不要把 key 放进 shell 命令本身。这会写入一个 OpenViking Service 配置,并使用固定端点https://api.vikingdb.cn-beijing.volces.com/openviking(ov-service目标不接受自定义服务端 URL)。
只有当环境变量已经存在时,才使用环境变量:
ov config add ov-service --name <CONFIG-NAME> --api-key-env <API-KEY-ENV-VAR> --activate -o json标准 OpenViking Service 配置不要传--account或--user。只有当用户或 OpenViking 管理员提供身份覆盖值时,才使用它们。
添加本地自定义服务
只有当用户选择本地自定义时,才使用这个路径。对于本地无鉴权服务:
ov config add custom --name <CONFIG-NAME> --url http://127.0.0.1:1933 --activate -o json如果本地服务没有运行,请先引导用户启动服务端,参见服务端模式。本地 URL 的简写(如127.0.0.1、localhost)会被 normalize_custom_url() 自动补全为http://<host>:1933。
添加远程自定义服务
对于使用普通 API Key 的远程自定义服务:
ov config add custom --name <CONFIG-NAME> --url <REMOTE-OPENVIKING-URL> --api-key-stdin --activate -o jsonstdin pipe 形式如下:
printf '%s' "$API_KEY" | ov config add custom --name <CONFIG-NAME> --url <REMOTE-OPENVIKING-URL> --api-key-stdin --activate -o json把 API Key 写入 stdin。如果 key 已经存在于当前 shell 环境变量中,可以改用--api-key-env <API-KEY-ENV-VAR>。
如果用户只提供 root API key,需要同时提供目标 account 和 user:
ov config add custom --name <CONFIG-NAME> --url <REMOTE-OPENVIKING-URL> --root-api-key-stdin --account <ACCOUNT-ID> --user <USER-ID> --activate -o json把 root API key 写入 stdin。Root key 需要显式--account和--user,这样普通 CLI 命令才知道以哪个身份执行。
如果用户同时拥有 user key 和 root key,可以把两者放在同一个配置里:
ov config add custom --name <CONFIG-NAME> --url <REMOTE-OPENVIKING-URL> --api-key-stdin --root-api-key-env <ROOT-API-KEY-ENV-VAR> --account <ACCOUNT-ID> --user <USER-ID> --activate -o json这样普通命令使用 user key,需要--sudo的命令使用 root key。因为一个命令只有一个 stdin 流,第二个 key 必须来自已经存在的环境变量。如果两个 key 都不在环境变量中,请使用ov config并引导用户完成交互式流程。
编辑或替换配置
先列出配置:
ov config list -o json重命名并激活 saved config:
ov config edit <CONFIG-NAME> --new-name <NEW-CONFIG-NAME> --activate -o json替换 API Key:
ov config edit <CONFIG-NAME> --api-key-stdin --activate -o json把新的 API Key 写入 stdin。
替换自定义服务 URL:
ov config edit <CONFIG-NAME> --url <CUSTOM-OPENVIKING-URL> --activate -o json只有在你明确要覆盖已有 saved config 名称时,才使用--force。
删除 saved config
只删除非 active 的 saved config:
ov config delete <OLD-CONFIG-NAME> -o json如果该配置正处于 active 状态,先切换到另一个配置:
ov config switch <CONFIG-NAME> -o json ov config delete <OLD-CONFIG-NAME> -o json删除 active 配置属于被拒绝的操作(对应退出码6),这也是必须先切换再删除的原因。
验证配置
运行:
ov config show ov config list -o json ov config validate ov health ov status检查配置时优先使用ov config show,因为它会隐藏密钥。除非你理解配置文件可能包含密钥,否则不要打印原始配置文件(~/.openviking/ovcli.conf)。
如果验证命令提示 OpenViking 需要显示语言,请运行ov language en;如果用户希望使用中文,则运行ov language zh-CN,然后重新验证。
ov status包含更宽泛的服务端和数据诊断。如果ov config validate和ov health通过,ov status中的 warning 不一定代表 CLI 配置失败——它可能反映的是数据侧或服务端侧的宽松诊断信息。
凭证安全
- API Key 可能允许访问你的 OpenViking 数据,务必视同密码管理。
- 手动配置时,优先使用
ov config的交互式输入框。 - Agent 辅助配置时,只有通过你明确相信的渠道提供 API Key。
- Agent 应通过 stdin 传入 key。只有当环境变量已经存在于当前 shell 中时,才使用环境变量。
- 不要把 API Key 直接写进可能被 shell history 保存的命令。
- 不要打印原始
~/.openviking/ovcli.conf。 - 不要分享包含 API Key 的截图。
- 演示和试用建议使用临时或可撤销的 key。
常见问题
找不到ov
npm i -g @openviking/cli npm prefix -g然后重新打开 shell,或把 npm 全局 binary 目录加入PATH。在 macOS 和 Linux 上,该目录通常是$(npm prefix -g)/bin。
npm 全局安装失败
如果 npm 报权限错误,请按你平时管理 Node.js 的方式处理。除非你本来就用 sudo 管理全局 npm 包,否则不要直接运行sudo npm i -g。
本地服务端没有运行
只有当用户选择本地自定义时才使用此项。先验证服务端:
curl http://127.0.0.1:1933/health如果失败,先启动服务端再配置ov,参见服务端模式。
API Key 校验失败
重新运行ov config并编辑配置。对于 OpenViking Service,确认 API Key 来自上文提到的 OpenViking 控制台地址;对于自定义服务,确认服务端是否要求鉴权。
Agent 不应该反复重试未知 key,请让用户确认目标类型、服务端 URL、key 类型、account 和 user。
active 配置不对
ov config show ov config list ov config switch ov config validateAgent 可以按名称切换:
ov config list -o json ov config switch <CONFIG-NAME> -o json非交互式配置不适合当前情况
使用交互式向导:
ov config当密钥应由用户直接在终端输入、连接目标不明确,或校验结果需要人工判断时,这是合适的回退路径。
旧配置命令
使用ov config。不要使用旧的或已移除的配置命令,例如ov config setup-cli。源码中加载配置时的错误提示也刻意不再引导用户使用已移除的命令(见 config.rs 中的相关测试)。
配置完成后的下一步
CLI 配置完成后,使用ov --help和ov <command> --help继续了解其他命令。
添加资源会把数据写入 active OpenViking 服务端。如果你想做一个小演示,请选择你愿意存入服务端的资源。Agent 运行这类演示命令前,必须先征得用户同意:
ov add-resource https://github.com/volcengine/OpenViking --wait ov find "what is OpenViking" ov tree viking://resources/ -L 2查看全部命令:
ov --help ov config --help ov add-resource --help重建索引:reindex 的三种模式
ov reindex <uri>用于重建已导入内容的索引,支持三种模式(对应实现位于 commands/content.rs):
--mode vectors_only—— 只刷新向量。--mode semantic_and_vectors—— 先重新生成语义产物(.abstract.md、.overview.md),再刷新向量。--mode prune_orphans—— 清理源文件已不存在的向量记录,加--dry-run可预览而不实际执行。
semantic_and_vectors默认递归处理整个子树。对已经具有下级摘要、只需要重新生成目标目录.abstract.md/.overview.md的场景,可添加--recursive=false;此时仅刷新目标目录语义产物和该目录的 L0/L1 向量。
注意:没有semantic或full这样的模式别名,模式名必须精确使用上述三种。
延伸阅读
- OpenViking 快速开始:在安装 CLI 之前,了解 OpenViking 的整体快速上手路径。
- 服务端模式:自定义服务端的安装与启动方式。
- 为 Agent 配置 OpenViking:面向 Agent 场景的整体配置流程。
- 源码参考:CLI 配置模型、Agent 配置命令实现、配置存储与校验、CLI 入口与命令分发。
【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考