为现有 Agent 接入 Context0,并完成知识库的 Wiki 生成配置后,直接询问架构、概念和决策背景即可。内置 Skill 会帮助 Agent 搜索主题、阅读页面、展开关联知识,您无需学习检索接口。
架构

Wiki 能帮您做什么
团队知识往往散落在设计文档、会议纪要、操作手册里。Wiki 将这些资料提炼为相互链接的主题页,让 Agent 更方便地理解系统全貌、关联概念和历史决策。您询问系统设计背景,Agent 通过 Wiki 主题页梳理模块职责和关联关系,在内置 Skill 的指导下完成查找、阅读和回答。
您:我们的发布系统整体是怎么设计的?当初为什么这么做?
Agent:我会先阅读发布系统的 Wiki 总览和关联设计页面,说明各模块的职责、交互关系,以及已有资料记录的设计取舍。什么时候用 RAG,什么时候用 Wiki
选型决策:
查具体规定、参数和操作步骤,优先用 RAG。RAG 从源文档中检索相关片段,适合回答“具体是什么、应该怎么做”,并提供原文依据。
理解概念、整体架构和决策背景,优先用 Wiki。Wiki 先把资料整理成相互关联的主题页,适合回答“整体是什么、为什么这样设计、各部分有什么关系”。
同时需要原理与细节,就让两者配合。
按您的问题选择
您想问的问题 | 建议使用 | 为什么 |
“连接超时默认多少秒?参数名是什么?” | RAG | 查配置手册中的精确值和原文说明 |
“报销需要哪些材料?紧急发布有哪些审批步骤?” | RAG | 查具体条款、办理流程和适用条件 |
“这个错误码代表什么?文档建议如何处理?” | RAG | 查错误码说明和对应操作指南 |
“我们的订单系统整体怎么设计?各服务怎么协作?” | Wiki | 从主题总览理解模块职责,再沿关联页面了解交互 |
“为什么采用 Kafka?当时有哪些备选方案和取舍?” | Wiki | 关联选型、设计和验证资料,理解已有记录中的决策背景 |
“先解释重试机制,再给出重试次数、配置方法和出处。” | Wiki + RAG | 先建立整体理解,再用源文档核对具体参数 |
选择主要看问题目标。即使资料很多,只查一个参数也可以直接用 RAG。需要了解一个模块的设计来龙去脉时,可以使用 Wiki。个人偏好、之前对话里的项目约定,则交给长期记忆。
初次接入时,应该准备哪一种
团队的主要需求 | 建议怎么接入 |
查制度、手册、接口规范,尽快开始使用 | 先接入RAG知识库,完成上传、索引和权限配置即可 |
新人理解系统、梳理架构、查阅历史技术决策 | 在知识库上开启 Wiki,并为已有资料补建主题页 |
既要理解系统,又要写代码、改配置和核对原文 | 同一个知识库同时使用 RAG 和 Wiki,资料只需接入一次 |
RAG 在文档完成索引后即可检索。Wiki 还需要额外的生成和发布时间,生成过程会使用 LLM 并产生相应消耗。源文档更新后,RAG 要等待同步与索引完成,Wiki 还要等待对应页面更新。因此,查询最新参数、制度条款或精确引用时,优先让 Agent 核对已更新的原文。
开启 Wiki 后,同一个知识库支持三种使用方式
知识库开启 Wiki 并完成页面生成后,安装配置好 Context0 插件,Agent 就可以在同一套资料上使用 RAG、Wiki,或将两者混合使用。 两种能力共用同一个知识库和连接配置,已有的 RAG 检索也继续可用。日常您只需在现有 Agent 中正常提问,内置 Skill 会帮助 Agent 根据问题选择:查具体内容时用 RAG,理解整体时用 Wiki,同时需要原理与细节时组合使用。
以同一个“发布规范”知识库为例,同一知识库内 RAG 与 Wiki 按问题类型自动切换的三组典型场景:
"紧急发布要哪些审批?"
→ Agent 用 RAG 查找审批条款,给出原文出处。
"我们的发布系统为什么分成这几个阶段?"
→ Agent 阅读 Wiki 总览和相关设计页,解释阶段关系与设计原因。
"先讲清发布系统的设计,再按最新规范列出上线步骤。"
→ Agent 先用 Wiki 理解设计,再用 RAG 核对操作步骤。Wiki 尚未生成或资料不够完整时,Agent 可以在同一知识库范围内使用已开启的 RAG 补充,并说明依据。日常查询不需要临时开启生成或补建,这些属于前期准备工作。
快速上手
步骤一:接入 Agent 并准备知识库
按让您的 Agent 快速拥有长期记忆完成服务开通、CLI 安装与连接,再按知识库文档准备资料。已有接入和知识库时,可直接进行下一步。
内置 Wiki Skill 随插件安装,Wiki 检索能力默认开启。配置生成需要目标知识库的Owner/Admin权限,User Key有相应角色即可操作。
步骤二:开启生成,准备好 Wiki 页面
可以在Context0 dashboard控制台的知识库详情页打开Wiki 知识蒸馏,也可以直接让 Agent 完成一次性准备:
请为 Context0 中的“工程规范”知识库开启 Wiki 生成,
并对已有文档补建 Wiki。我同意本次生成使用 LLM。内置 Skill 会指导 Agent 检查权限和生成能力、开启该知识库的生成开关,再为已有文档提交补建。新上传的文档在索引和必要审核完成后会按配置持续生成 Wiki。生成在后台异步执行,等页面生成并发布后即可使用。Agent 也可以帮您查看当前是否已有可读页面。开启配置不会自动补建历史资料,因此首次设置已有知识库时,要同时说明“补建已有文档”。若团队管理员已经完成这些准备,普通使用者只需有读取权限,直接进入下一步。
步骤三:回到现有 Agent,正常提问
Wiki 页面就绪后,直接在 Agent 中提问即可获取主题概览和关联页面。
请结合"工程规范"里的 Wiki,介绍我们的系统架构和模块关系。Agent 会搜索相关主题、阅读全文,必要时沿链接展开。如果您还需要具体参数或准确条款,它可以继续查询同范围的原文资料。前期配置完成后,无需每次开启 Wiki、手动查页面 ID 或执行读页命令。 内置 Skill 会帮助 Agent 完成这些操作。
日常使用举例
以下示例以团队知识库中已有对应资料、Wiki 页面已就绪为前提。
新人了解系统全貌
新人通过 Wiki 主题页快速理解消息队列的整体架构和模块关系。Wiki 帮助 Agent 把分散的资料组织成完整说明,您不用逐篇翻阅设计文档。
您:我们的消息队列架构是怎么设计的?
Agent:根据消息队列 Wiki,总体采用 Kafka,生产者来自订单和支付服务,
消费者组按业务域划分,失败消息进入死信队列。
我会结合关联页面继续说明消费者组和重试机制。理解历史技术决策
Agent 关联选型和设计文档,解释历史技术决策的背景和取舍。Agent 会依据已有资料回答;资料没有记录的原因,应说明缺口。
您:当初为什么选 Kafka?和 RabbitMQ 比较过哪些方面?
Agent:我找到了消息队列选型和性能验证的关联页面。
已记录的比较维度包括吞吐量、消息回放和运维成本,
下面按文档中的结论说明各项取舍。排查问题时关联历史经验
排查故障时,Agent 从 Wiki 中关联历史复盘和现行规范。
您:这个模块上次出现 OOM 是什么原因?当时怎么修的?
Agent:Wiki 中有一篇相关故障复盘,记录了大查询造成内存峰值,
修复方式包括分页和限制批量大小。
我会再关联查询规范,整理当前排查时需要关注的点。整体流程与准确条款一起查
Wiki 梳理流程 + RAG 核对精确条款,同一个问题可以同时使用 Wiki 和 RAG,您无需手动切换工具。
您:我们的发布流程是什么?紧急发布的审批要求请给出原文出处。
Agent:我先根据 Wiki 梳理发布流程,再从发布规范原文中查找
紧急发布的审批条款,并附上文档来源。安装配置说明
配置位置 | 默认状态 | 用途 |
服务端 Wiki 读取能力 | 开启 | 提供搜索、读页和链接展开;管理员可以显式关闭 |
每个知识库的 Wiki 生成 | 关闭 | 首次使用时为需要的知识库开启 |
Agent 的 Wiki 能力 | 开启 | 内置 Skill 可指导 Agent 按需使用 Wiki |
生成还需要服务端的生成Worker可用,若部署关闭了这项能力,Agent 会提示联系管理员。
开关用于控制能力和未来生成,页面是否可读取决于已有的发布内容。停止后续生成不会删除已生成页面。
需要调整 Wiki 内容侧重点时,可在知识库配置面板设置:
参数
说明
extraction_granularityfocused少而精 /standard默认 /exhaustive更全面wiki_language页面语言,默认
Chinesecontent_instructions例如“侧重架构决策和系统关系”
普通上手无需调整这些参数。高级管理 API 示例,请参见API参考手册。
(可选)主动使用 CLI
下面提供另一种主动使用方式,适合脚本或排查场景。日常使用者可以直接把同样的需求告诉 Agent。
# 一次性开启已有知识库的生成,并补建历史文档
ctxdb0 knowledge sources set '工程规范' --wiki-enabled --json
ctxdb0 wiki build --source '工程规范' --json
# 主动查看、搜索和阅读
ctxdb0 wiki status --source '工程规范' --json
ctxdb0 wiki search '发布流程' --source '工程规范' --json
ctxdb0 wiki read-page <page-id> --json
# 关闭未来生成,保留已有页面
ctxdb0 knowledge sources set '工程规范' --no-wiki-enabled --json补建返回的
accepted/enqueued表示已提交后台处理,不是已生成页数。wiki status查看库级已发布页面,处理未完成时应先查状态,不要连续重复补建。搜索默认
keyword,也可通过--mode regex按已知名称做字面匹配,--source可重复传入。不指定时搜索当前 Key 可访问的知识库,超过 100 个时需要收窄范围。主动读页可使用命中的页面 ID,无需自行推断所属知识库。
常见问题
现象 | 处理方式 |
安装后还没有 Wiki 内容 | 安装负责接入,需要为目标知识库开启生成,并准备源文档和已发布页面 |
开启后仍搜不到页面 | 后台仍在处理,或已有文档尚未补建。让 Agent 检查索引、审核和生成状态 |
配置或补建报 403 | 检查目标知识库的Owner/Admin权限,读取不需要这一级权限 |
读侧能力不可用 | 联系服务管理员检查 Wiki 读取配置 |
Agent 没有使用 Wiki | 检查内置 Skill 已加载、连接和权限正常,项目配置未关闭 Wiki 能力 |
Wiki 资料不够完整 | 在 RAG 可用时,Agent 可查询相同知识库的原文补充,并说明来源 |
当前检索由内置 Skill 指导 Agent 按需执行,不需要设置旧的 prompt-wiki-recall 或 recall-mode。新建、开启生成和补建属于前期写入操作,向 Agent 说明目标知识库和操作意图即可。