文章总结： OpenViking与LLM-Wiki结合，解决团队知识库中资料分散、难以关联的问题，通过零代码构建Wiki网络，实现知识沉淀和复用，提高团队协作效率。
综合评分： 85
文章分类： 安全工具,团队知识管理,产品介绍,AI安全,技术标准
OpenViking × LLM-Wiki：让团队文档不再“各说各话”
原创
OpenViking
OpenViking
字节跳动技术团队
2026年9月23日 18:06
北京
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
从一通不敢回答的电话，到一套跨平台、跨 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-resouce 命令完成接入：
ov add-resource "https://github.com/your-org/product-config" \ 此处填入你代码仓库的地址 --to viking://resources/xxx \ 此处填入你自定义的写入目录 --watch-interval 60
–watch-interval 60 表示每 60 分钟同步一次。Git 导入保留原有目录层级，并遵循 .gitignore 等过滤规则；后续查阅时，仍能沿着目录找到相关说明、代码和配置。
资料导入并完成处理后，就已经可以接入 Agent 使用了。你可以按官方接入指南（https://docs.volcengine.com/docs/84313/2371368?lang=zh），为 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 并配置推理接入点，可按官方指引（https://docs.volcengine.com/docs/84313/2692655?lang=zh）完成前置准备 。
打开 OV 控制台的终端界面，输入 /，在“核心流程”菜单中选择 compile，进入编译任务的参数配置。
Compile 命令的核心参数有 3 个：
- 来源–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，可用下面的命令查看进度：
发送指令后，控制台会返回 task_id，可用下面的命令查看进度：
到这里，你已经把“读哪些资料、怎样整理、结果存在哪里”交代清楚。等任务完成，就可以打开目标目录，检查这套 Wiki 是否真正能支持一线答疑。
2.3 团队成员可查看 Wiki，不满意随时改
编译任务完成后，Wiki 会保存在 OV 的目标目录中，团队成员可以随时打开、查阅，也可以继续编辑和更新。
登录控制台，找到本次 Compile 的目标目录，即可查看完整 Wiki 的内容。
比如，小李想确认某个产品的赔付标准，可以从 index.md 进入对应规则页；你要了解某位客户采购了什么服务，也可以先读客户页，再顺着关联查看产品说明。有访问权限的同事，都可以从同一个目录查阅这套知识。
如果习惯使用命令行，也可以直接查看目录和导航页。将示例路径替换为上一节实际使用的目标目录：
ov tree viking://resources/xxx/wikiov 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 接入说明 （https://docs.openviking.ai/zh/agent-integrations/01-overview）连接同一套服务。
安装完成并重启 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“搜得更快”，而是把一次次搜索、讨论和确认，变成团队下一次可以直接复用的共同知识。
从一通不敢回答的电话，到一套可以继续使用的团队知识，现在已经是人人都可以快速落地的资产升级了。
加入我们，共建 Agent 上下文的未来。
🚀 上手试用：访问 OpenViking 官网（https://www.volcengine.com/product/openviking-service），无需自行部署，即可将常用 Agent 接入 OpenViking，体验上下文的持续积累与跨任务复用。
🌟 给个 Star：访问我们的 GitHub 仓库（https://github.com/volcengine/OpenViking），为我们点亮一颗Star，你的 Star 是我们前进的最大动力！
💬加入社区：扫描下方飞书二维码，加入官方交流群，与顶尖开发者一起探讨 Agent 上下文的无限可能。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：字节跳动技术团队 OpenViking
OpenViking《OpenViking × LLM-Wiki：让团队文档不再“各说各话”》