AI 就绪企业 Wiki：架构与实施指南

AI 就绪企业 Wiki 是一套受治理的组织知识源。人可以编辑它，AI 智能体可以在相同权限、来源与时效信号下检索它。它不是接在文件夹前面的聊天机器人。真正可用的系统会把权威知识、派生索引、访问控制、智能体交付和人工审核分开。

本文回答实施与采购问题：怎样设计和购买这套系统。我们的 Open Knowledge Format 指南解释交换格式，OpenKB 评测分析一种知识编译器，RAG 生产就绪清单覆盖检索质量。本文把这些层连接成一套全公司的运行模型。

什么让企业 Wiki 真正做到 AI 就绪？

当人和智能体都能找到同一个答案，并以同样方式判断权限、来源、时效与质量时，Wiki 才算 AI 就绪。语义搜索能改善发现，但不会自动分配负责人、解决矛盾或保留文档权限。

哪种架构同时适合人和 AI 智能体？

耐用的模式是六层知识系统。每层只承担一个职责，因此可以更换搜索引擎或模型，而无需迁移权威来源。

1. 源系统。现有 Wiki、政策、工单、代码库、数据库和获准使用的对话仍是证据，不应混成无差别的数据堆。
2. 权威知识。定价规则、事故手册、客户定义等持久概念拥有稳定 ID、负责人、来源和生命周期元数据。
3. 治理控制面。分类、访问政策、复核日期、审批、保留与审计记录跟随概念。
4. 派生索引。关键词、向量和图索引都是可重建的投影，绝不能成为知识的唯一副本。
5. 交付层。理解权限的 API 或 MCP 服务器只交付最小相关上下文，并指回权威来源。
6. 使用界面。员工浏览和编辑 Wiki，助手回答问题，智能体为边界明确的任务加载上下文。

Google Cloud 的 Open Knowledge Format v0.2 规范适合权威知识层。它用人类可读的 Markdown 保存概念，并提供可选的来源、验证、生命周期与时效字段。它不定义检索、权限或运行时交付，所以其他层仍然必需。

是否应该替换现有 Wiki？

开始时通常不应该。先把当前 Wiki 视为编辑界面或证据来源，再围绕一个高价值流程建立受治理的知识层。尚未证明检索质量，就先迁移全部页面，只会得到一个没有商业价值证据的迁移项目。

权威来源有三种可行模式：

好的试点可以从 30 到 50 个高价值概念开始。不要导入整个公司云盘。先处理拖慢入职、支持、销售或事故响应的问题，以及回答这些问题的证据。

智能体应该怎样检索企业知识？

没有一种检索方法能赢下所有问题。选择能保留所需含义与证据的最低成本方法。

评估必须包含真实且不完整的用户语言。Google Cloud 关于 智能体发现能力评估的研究把检索描述为大海捞针，并追问问题含糊到什么程度时发现会失败。企业 Wiki 应测试缩写、旧名称、不完整问题和相互冲突的来源，而不只是实施团队写好的提示。

怎样保障权限和智能体写入安全？

权限检查必须在检索路径中执行。把受限文档复制到共享向量索引，再在生成之后过滤已经太晚。每次搜索和读取都必须从请求者身份出发，与源权限求交集，只返回获准概念。

OWASP 关于向量与嵌入弱点的指南把跨上下文泄露、知识投毒和薄弱访问控制列为具体 RAG 风险。其缓解措施包括权限感知存储、可信来源验证、分类与检索日志。

如果通过 MCP 暴露 Wiki，身份验证和授权必须留在该边界。当前的 MCP 安全指南要求验证所有入站请求，并禁止直接传递 token，因为它会绕过控制并破坏问责。搜索结果 ID 或状态 handle 不能证明调用者有权读取底层页面。

写入应从非对称模式开始：

• 人发布，智能体提议。智能体创建带来源与修改理由的草稿或补丁。
• 审核人接受差异。定价、法律政策、生产 runbook 等高影响概念必须有指定负责人。
• 批准后再重建索引。被拒绝或未审核的智能体输出不会成为可信检索上下文。
• 每个答案都可追踪。记录查询、检索概念 ID、政策决定、答案和反馈，但不记录机密。

Cloudflare 最近发布的 企业 AI 智能体工作区参考架构采用相同分离方式：共享组织上下文集中发布到有版本、只读的库中，模型访问、工具、凭据和执行则在工作区之外受治理。

每个知识概念应该包含什么？

一个概念应回答一个持久问题，并提供足够元数据，让系统在阅读全文前判断它是否安全可用。

---
type: Policy
title: 生产事故升级
owner: team:platform
status: stable
classification: internal
generated: { by: human:platform-lead, at: 2026-08-13T09:00:00Z }
verified: { by: human:security-owner, at: 2026-08-13T11:00:00Z }
stale_after: 2026-11-13
sources:
  - id: incident-policy
    resource: https://intranet.example/policies/incidents
---

# 决策

确认一级严重事件后，通知事故指挥官。

# 例外

客户自主管理的部署遵循合同专用 runbook。

# 流程

1. 创建事故频道。
2. 记录证据与开始时间。
3. 通知责任人。

前置元数据不能替代清晰正文。它让人、确定性过滤器和智能体在消耗时间与模型上下文前，拒绝过期、废弃或未授权概念。

30 天试点应该怎样进行？

1. 第 1 到 3 天，选择流程。挑选一个成本高的路径，例如开发者入职、支持升级或事故诊断。定义负责人和成功指标。
2. 第 4 到 7 天，建立问题集。收集 25 个真实问题、预期答案、获批来源、授权角色与应拒绝案例。
3. 第 8 到 14 天，策划知识切片。规范 30 到 50 个概念，分配负责人，删除重复项，并明确记录矛盾。
4. 第 15 到 20 天，构建检索和访问。比较关键词与混合检索，在检索前强制执行源权限，每个答案返回来源链接。
5. 第 21 到 25 天，加入两种界面。人可以浏览和纠正内容，一个获批智能体可通过精简 API 或 MCP 界面搜索和读取。
6. 第 26 到 30 天，运行盲测。相对现有流程，测量有来源的正确率、检索召回、拒答质量、中位回答时间、审核工作量与权限失败。

只有在不削弱访问控制、不制造无人负责内容队列的前提下改善业务结果，试点才应扩展。我们的 DACH 内部 AI 助手成本模型解释了为何内容准备、权限、评估与维护通常比模型账单更重要。

应该自建、购买还是扩展？

不要让供应商演示替你做决定。要求导出、权限测试，以及基于自己问题的盲测。如果系统不能说明答案为何被检索、谁能看见、来源何时最后验证，它还不适合成为企业记忆。

AI 就绪企业 Wiki 验收清单

1. 每个高影响概念都有指定负责人。
2. 稳定 ID 和指向获批来源的可见链接。
3. 明确的状态、验证与复核日期。
4. 检索前强制执行源权限。
5. 权威内容与可重建搜索索引分离。
6. 答案引用实际检索到的概念。
7. 智能体通过可审核草稿或差异提议修改。
8. 冲突和过期知识被显示，而不是混合。
9. 固定评估集覆盖含糊问题、拒答和访问边界。
10. 上线前测试内容导出、审计日志与模型可移植性。