OpenViking 零代码搭建 LLM-Wiki：团队文档不再各说各话

从一通不敢回答的电话，到一套跨平台、跨 Agent 的团队知识。

周三下午，客户在电话那头问了一个再普通不过的问题：这票货没保价，出了问题怎么赔？

你刚接手业务不太熟悉，在工作群里问了一句，结果：

——老王说按 1 倍运费，他做这块四年了；
——小李翻出一份产品文档，白纸黑字写着 3 倍基本运费、最高 1000 元；
——售后的同事更谨慎：这个得分产品，我再查查。

三个人，三个答案，而且每个人都能翻出一份正式材料。

客户还在电话那头等，团队却从不同正式资料中找出了三个答案。

负责任的你没有立刻报一个赔付数字，转头把这句话输入给你的办公智能体，想进一步核实清楚再回复。Agent 能检索团队知识库、给出引用，似乎应该比单独问人更靠谱？

可这次 Agent 也帮不到你了：它告诉你“根据当前信息无法给出准确回复”，然后甩给你一堆线索文档，让你先确认清楚客户采购的服务类型，再查看相应的计费标准。

Agent 给出了多种带引用的口径，但没法判断哪一条适用于眼前这个客户。

你作为新人，客户的情况还没来得及了解清楚，只能回复客户：“我这边确认一下，稍后回复您。”

这就是团队知识最容易卡住的地方：团队沉淀了很多文档和知识库，AI 办公工具也有，但资料都找到了，适用关系却还没有理清。

一、团队缺的不是文档，而是一张能串起来的 Wiki 网络

Agent 找到了很多资料，却仍然无法回答“到底怎么赔”，因为团队真正缺少的，不是更多知识库文档，而是围绕客户、产品、规则和流程组织的 Wiki。

2026 年 4 月，Andrej Karpathy 提出了 LLM-Wiki 这一知识库范式：在原始资料和用户之间，增加一层由 LLM 维护的、持久化的 Markdown Wiki。新资料进入后，需同步更新实体页、概念页、对比页，补充交叉引用，并标记新旧材料之间的矛盾。

这些 Wiki 既能独立维护，又能被 Agent 按问题动态检索和串联。而且当新证据出现时，更新的是同一套知识，而不是再生成一份互不相认的新答案。

也许下一次遇到赔付问题，可以不用再从一堆文档中拼凑答案，而是有一条可追溯的知识链：

• 先查客户 Wiki，确认客户采购了什么服务、属于哪种业务类型；
• 再查产品 Wiki，确定对应的产品、线路和服务范围；
• 最后关联到计费与赔付 Wiki，找到当前生效的标准、适用条件和例外规则。

这正是 LLM-Wiki 的价值：把散落的文档编织成一张可以按需查找、关联和更新的业务知识网络，沉淀成可以继续生长的团队知识。

方法论有了，那应该如何搭建起团队的 LLM-Wiki 呢？团队把这个任务交给了你，让你探索出来一个最佳实践。不用感觉到有压力，因为现在可以用 OpenViking 零代码构建了。

二、使用 OpenViking 搭建 LLM-Wiki

2.1 散落四处的资料，先导入至 OpenViking

你先从那通赔付电话出发，把相关资料盘点了一遍：产品说明和 FAQ 在飞书里，历年的赔付细则存在本地电脑上，产品变更的背景散落在项目记录中，还有 GitHub 的代码仓库等等......

要把这些资料编成 Wiki，第一步是让它们汇集到同一个地方。OpenViking 已有现成的 Connector 和导入入口，可以把分散在不同位置的数据接进来，作为后续编译 Wiki 的原料。

进入 OV 控制台，点击左侧目录树上方的“＋”：

对应刚才盘点的资料，你可以这样操作：

• 本地电脑里的文件：选择“本地上传”，上传赔付细则、历史规则和业务说明等文件。
• 网页、在线资料与 Git 仓库：通过链接接入对应资源。例如，当你需要导入业务线下的整个代码仓库时，只需要把 GitHub 地址 填入即可把 README、代码和配置文件一起纳入团队知识。
• 飞书里的产品说明与 FAQ：选择“数据源同步 → 飞书文档”，按页面提示完成授权与导入配置。
• ......

更多 Connector 正在陆续开放中...

如果你需要定期跟进仓库更新（或者有大批量的数据需要导入），也可以用 add-resource 命令完成接入：

ov add-resource "https://github.com/your-org/product-config" \  此处填入你代码仓库的地址
  --to viking://resources/xxx \   此处填入你自定义的写入目录
  --watch-interval 60

--watch-interval 60 表示每 60 分钟同步一次。Git 导入保留原有目录层级，并遵循 .gitignore 等过滤规则；后续查阅时，仍能沿着目录找到相关说明、代码和配置。

资料导入并完成处理后，就已经可以接入 Agent 使用了。你可以按 官方接入指南，为 Codex、TRAE 等配置对应的插件或集成，让它们访问同一套 OV 资源。

到这一步，其实你已经可以用这套资料查问题、做工作了。OpenViking 的检索是层级式渐进读取：先看摘要与概述，定位到相关模块后，再读取具体文档详情——这种全新的检索范式，可以帮你节省很多检索 Token。

但你没有忘记初心：接下来，为了让客户、产品和规则之间的关系也沉淀下来，你计划通过 Compile 将它们整理成团队可复用的 Wiki。

2.2 使用 Compile 功能，把数据编译为 Wiki

Compile 是 OpenViking 最新上线的功能，可以支持你自定义 skill 或使用预置的 LLM-Wiki skill，并基于 skill 指导 Agent 把原始数据重新组织、编译成你想要的形式。

简单来说就是，你告诉它读取哪些资料、按什么规则组织、把结果写到哪里，它就会执行这次整理任务，并将产物保存回 OpenViking，供团队继续查看、检索和复用。

第一步，你要先把“怎样才算一份好 Wiki”写进自定义 Skill。

你回想那通电话：老王和小李都找到了依据，但适用条件没有对齐。因此，这次生成的 Wiki 必须同时保留产品、地区、版本和例外，还要把相关页面连接起来。这些要求，就应该成为 Skill 的一部分。

自定义 Skill，可以先说清四件事：

• 给谁用
• 按什么方式组织
• 哪些事实和条件必须保留
• 完成后如何检查

你按照这个思路，写完了适用于你们团队业务场景的 skill，并通过 add-skill 将它导入 OV：

ov add-skill ./claims-wiki

导入完成后，别忘了记住导入任务返回的实际 Skill URI（后面发起 compile 任务时要用到）。这份 Skill 可以持续维护，团队新增规则后，下次编译继续复用。

当然，作为业务新人的你，有可能没法立刻写出一份完美的 skill。不用担心，你可以先用官方现成的 Skill：

OpenViking 已提供 llm-wiki 模板，用于生成有出处、相互链接、带导航入口的知识库。这次搭建团队 Wiki，可以直接导入它：

ov add-skill https://github.com/volcengine/OpenViking/tree/skills/llm-wiki

官方还提供日报、知识蒸馏、知识图谱等模板，可按任务选择。

第二步，在控制台发起 compile。

使用 compile 功能之前，需要开通火山方舟 Managed Agents 并配置推理接入点，可按 官方指引 完成前置准备。

打开 OV 控制台的终端界面，输入 /，在“核心流程”菜单中选择 compile，进入编译任务的参数配置。

Compile 命令的参数包括：

• --from 来源：这次让 Agent 读取哪些资料，填写已导入的来源目录或文件 URI。
• --to 目标：生成的 Wiki 保存到哪里，使用一个独立的产物目录。
• --skill 生成规则：使用哪份 Skill，决定如何处理资料、生成什么内容。刚刚你自定义或者导入的官方 skill URI，就是粘贴在这里。
• --instruction 补充说明：补充这一次的受众、范围和侧重点等一些你希望强调的内容，也可以不填。

ov compile \
  --from viking://resources/demo/raw \
  --to viking://resources/xxx/wiki \
  --skill <导入后返回的Skill_URI> \
  --instruction "面向一线答疑整理，重点关联客户、产品和赔付规则"

发送指令后，控制台会返回 task_id，可用命令查看进度。

到这里，你已经把“读哪些资料、怎样整理、结果存在哪里”交代清楚。等任务完成，就可以打开目标目录，检查这套 Wiki 是否真正能支持一线答疑。

2.3 团队成员可查看 Wiki，不满意随时改

编译任务完成后，Wiki 会保存在 OV 的目标目录中，团队成员可以随时打开、查阅，也可以继续编辑和更新。

登录控制台，找到本次 Compile 的目标目录，即可查看完整 Wiki 的内容。

比如，小李想确认某个产品的赔付标准，可以从 index.md 进入对应规则页；你要了解某位客户采购了什么服务，也可以先读客户页，再顺着关联查看产品说明。有访问权限的同事，都可以从同一个目录查阅这套知识。

如果习惯使用命令行，也可以直接查看目录和导航页。将示例路径替换为上一节实际使用的目标目录：

ov tree viking://resources/xxx/wiki
ov read viking://resources/xxx/wiki/index.md

你读到某条赔付规则，发现数字有了，适用地区却漏写了。这时可以点击页面右上角的“编辑”，在当前页面中补齐条件并保存。表述不清、标题不好找、页面关联不完整等问题，也都可以在查阅时逐项调整。

保存后，再重新打开页面确认修改结果。你修正的是保存在 OV 中的这份 Wiki，下一位同事查阅时，可以直接看到已经补充好的内容。

2.4 还可以让你的 Agent 直接检索 Wiki

Wiki 已经整理好了，你又想到一个更顺手的用法：下次客户来问，能不能直接在自己常用的 Agent 里得到答案，不必再手动打开目录、逐页查找？

当然可以。OpenViking 目前已经支持 MCP、CLI、API、SDK 等通用方式接入各大主流 Agent。接下来只需要补上两件事：把 OpenViking 接入到你的 Agent 里，再用检索 Skill 告诉它应该怎样查、怎样判断。

第一步，把 OpenViking 接到 Agent。

以接入 Codex 为例，直接复制下方指令，将地址与密钥替换成团队的实际配置，发送给你的 Codex：

## 步骤1：安装
1. 在终端执行如下安装命令：
   ```bash
   bash <(curl -fsSL https://ovrelease.tos-cn-beijing.volces.com/memory-plugin-shared/install.sh) --harness codex --dist tos
   ```
2. 安装器会依次询问以下信息：语言（English / 中文）、OpenViking 凭据。在 OpenViking 凭据配置中，选择连接至「火山引擎 OpenViking 云服务 [api.vikingdb.cn-beijing.volces.com]」，并填入 API KEY：
   ```text
此处替换成你的 API KEY
   ```
## 步骤2：验证
1. 启动 Codex。
2. 审批 Hooks：输入 `/hooks`，系统将提示类似 `4 hooks need review` 的信息，逐一审批通过。其中 OpenViking 相关的 4 个 Hook 为：
   ```text
   SessionStart
   UserPromptSubmit
   Stop
   PreCompact
   ```
3. 验证 Profile 加载：审批完成后，提交第一条 Prompt（内容随意即可）。此时插件应自动加载 Profile——若对话开头出现记忆召回内容，则表明接入成功：
   ```text
   • UserPromptSubmit hook (completed)
     hook context: <openviking-context source="auto-recall" format="digest">
       OpenViking memory digest:
   ```
## 故障排查
| 问题 | 处理 |
|---|---|
| 鉴权失败 | 检查 `~/.openviking/ovcli.conf` 的 `api_key`，重启 Codex |
| 连接失败 | `curl "$(jq -r '.url' ~/.openviking/ovcli.conf)/health"` |
| `4 hooks need review` | `/hooks` 里批准 |
| 需要日志 | `OPENVIKING_DEBUG=1`，看 `~/.openviking/logs/codex-hooks.log` |

使用其他 Agent 的同事，也可按 OpenViking 接入说明 连接同一套服务。

安装完成并重启 Codex 后，输入 /mcp 检查连接，再让 Codex 实际读取一次 Wiki：

请使用 OpenViking 读取：
viking://resources/xxx/wiki/index.md
列出其中的主要主题，并保留对应页面的 URI。

能返回导航页里的实际内容，说明这条链路走通了。

第二步，把团队的查阅方法写成检索 Skill。

编译 Skill 负责生成 Wiki，检索 Skill 则把团队“怎样查、怎样判断”的经验交给 Agent。以赔付答疑为例，把下面四件事说清楚即可：

• 何时使用：遇到客户服务、产品适用范围、计费或赔付问题时，查阅团队 Wiki。
• 去哪查：指定 Wiki 目录，先通过导航或检索定位相关主题，再按需读取正文。
• 怎么核实：沿“客户 → 服务 → 产品 → 规则”查清适用关系，核对地区、时间和例外，必要时回看原始来源。
• 如何回答：给出结论、适用条件和来源；依据不足或口径冲突时明确说明，不补猜答案。

PS：同样地，这里也可以让 Agent 帮你生成一个检索 OV Wiki 的 skill，只需要把上述要点告诉它即可。

Skill 在团队内分享后，团队成员就可以继续使用各自熟悉的 Agent，而答案背后查阅的，会是同一套持续维护的 Wiki。

2.5 不止 Wiki，还有更多

团队 Wiki 搭起来后，你还可以用这些资料做更多事。正如上方提到的，Compile 生成什么，取决于你选择的 Skill。换用日报、知识蒸馏或知识图谱 Skill，就能把相关资料整理成工作日报、专题分析或实体关系，让同一批知识服务不同的工作场景。

这些产物也都会保存在 OV 中，供同事查阅、编辑，供 Agent 检索和复用。Wiki 是这次实践的起点，团队还可以继续探索更多用法。

三、回到那通电话，变化发生在哪里

下一次客户再问未保价怎么赔，一线看到的不再是三份互相打架的文档，而是一条可以继续向下展开的团队知识：

• 目前确认的口径；
• 适用的产品、地区、时段和例外；
• 历史版本与变更关系；
• 仍未解决的冲突；
• 每句话对应的来源。

能回答的，当场回答；需要确认的，知道找谁、确认什么。确认结果回到同一套知识里，下一位同事不必重新找三个人。

这才是 OpenViking × LLM-Wiki 的价值：它不只是让 Agent“搜得更快”，而是把一次次搜索、讨论和确认，变成团队下一次可以直接复用的共同知识。

从一通不敢回答的电话，到一套可以继续使用的团队知识，现在已经是人人都可以快速落地的资产升级了。