很多企业已经把内部文档接入大模型，也做了 RAG。员工问制度、查产品资料，系统基本能回答。
可一旦问题变成：
“帮我看看华东区上个月毛利为什么掉了，顺便找出影响最大的三个客户。”
系统往往就卡住了。
它可能搜到《经营指标口径说明》，也可能知道公司有订单查询、客户分析、财务报表等工具。但“华东区”对应哪些组织编码，“上个月”按自然月还是财务月，“毛利”指毛利额还是毛利率，该调用哪个工具、参数怎么填，这些问题仅靠文档相似度解决不了。
这也是不少企业知识库接入 Agent 后暴露出来的短板：资料很多，知识却没有被组织成一个机器能够理解、查询和行动的业务世界。
LLM Wiki 提供了一种值得关注的知识管理方式；Ontology 则进一步定义这个业务世界中的实体、关系和约束。两者结合，才能让 Agent 从“会搜索资料”走向“理解业务并正确调用工具”。
一、企业缺的往往不是知识，而是知识结构
设想一下，新员工第一次听到“华东大客户毛利”。他需要逐步弄清楚：
“华东”是销售区域、交付区域，还是客户注册地； “大客户”按照合同额、年度收入，还是客户等级判断； “毛利”采用哪个财务口径，是否包含渠道返利和售后成本； 数据来自订单系统、财务系统，还是经营分析平台； 哪个接口能查，调用时需要传什么参数。
这些知识散落在指标文档、组织架构、接口说明、会议纪要和员工经验里。传统知识库通常把它们切成片段、生成向量，再等用户提问时召回。
问题是，相关片段不等于完整答案。系统可能同时召回三份“毛利”定义，却不知道哪一份适用于当前业务；也可能找到一个接口说明，却无法把用户口中的“华东”映射成接口要求的 region_id。
💡 关键洞察：Agent 的上限不只由模型决定，也由企业是否整理清楚“有哪些业务对象、它们如何关联、哪些工具可以操作它们”决定。
二、LLM Wiki：知识不是临时检索，而是提前编译
Karpathy 在 2026 年提出的 LLM Wiki 思路，核心不是换一种知识库界面，而是改变知识处理的时机。
普通 RAG 在收到问题后，临时从原始文档中检索片段，再由模型拼出答案。下一次遇到相似问题，检索和归纳过程还要重来。
LLM Wiki 会先让模型阅读新资料，把内容编译进一个持续维护、相互链接的 Wiki：
新的组织文件进入后，更新“华东区”“销售区域”和相关负责人页面； 新的财务口径发布后，更新“毛利率”页面，并标记旧口径已被替代； 一次高质量分析得到确认后，可以沉淀为新的知识页面； 定期检查孤立页面、冲突说法、失效链接和过期结论。
Karpathy 给出的基础架构有三层：
| 层级 | 保存什么 | 谁负责维护 |
|---|---|---|
| Raw Sources | ||
| Wiki | ||
| Schema |
这套方式最有价值的地方，是把每次阅读和分析留下来。新资料不是简单增加几个向量，而是可能更新多个已有页面，补充关系，指出冲突，让知识逐步积累。
不过，原始 LLM Wiki 中的 Schema 更像 Wiki 的维护规范，不等于严格的 Ontology。企业如果想让这些知识参与工具调用，还要补上一层清晰的业务语义模型。
三、企业海量数据如何构建进知识库
讲到这里，一个更现实的问题出现了：企业有数据仓库、业务数据库、上万份文档、几百个 API，还有持续增长的日志和会议记录，难道要把它们全部写进 Wiki？
答案是否定的。
LLM Wiki 不是新的数据湖，也不应该复制所有业务明细。订单流水仍留在数据库，实时库存仍由业务系统管理，日志仍进入日志平台。知识库保存的是这些数据的语义抽象、使用规则和来源指针：这张表代表什么、字段采用什么口径、实体之间如何关联、什么工具能查询、结果是否有权限限制。
3.1 先把数据源分层
不同数据不能用同一种方式摄取。
| 数据类型 | 典型内容 | 进入知识体系的方式 |
|---|---|---|
| 非结构化资料 | ||
| 结构化主数据 | ||
| 交易与事实数据 | ||
| 工具与接口 | ||
| 事件与日志 |
这一步很容易被忽略。把一亿条订单都做成向量没有意义，Agent 真正需要的是“订单是什么、在哪里查、按什么字段关联客户、查询结果采用哪个时间口径”。
3.2 再做实体抽取、消歧和关系对齐
数据进入后，系统需要完成一轮知识加工：
从文档、数据目录和接口说明中识别客户、产品、区域、指标、工具等候选实体。
把“华东”“东区”“East China”归并到同一个实体 ID，同时保留别名和适用范围。
对齐关系，例如客户归属哪个区域、指标依赖哪些字段、工具能够查询哪些实体。
记录来源、版本、生效时间、负责人和可信状态，避免把旧制度与新口径混在一起。
LLM 很适合做候选抽取、别名发现和关系建议，但实体合并、指标口径、权限规则不能完全自动发布。企业需要审核队列，让业务负责人确认高风险变更。
3.3 把知识编译成多种可查询形态
知识构建完成后，不应该只得到一个向量库。更实用的系统通常同时保留五种入口：
| 查询入口 | 适合解决的问题 |
|---|---|
| Wiki 目录和主题页 | |
| 关键词与向量索引 | |
| 实体索引 | |
| 关系拓扑 | |
| 工具目录 |
一次查询可以先读 Wiki 目录确定主题，再通过实体索引完成消歧，沿关系拓扑找到数据集和工具，最后用 RAG 补充原始证据。检索不是单一路径，而是一套逐步收窄的路由机制。
3.4 增量更新，而不是定期推倒重建
企业知识每天都在变化。组织和客户主数据可以通过 CDC 或定时同步更新；接口发布时刷新工具 Schema；新制度进入后触发 Wiki 编译；数据负责人确认后再变更指标版本。
每次更新都要回答三个问题：新增了什么实体，影响了哪些旧页面，哪些缓存和索引需要失效。原始证据不覆盖，旧版本不直接删除，查询时按照生效时间选择正确版本。
这才是可长期运行的知识构建流程。一次性导入文档，只能做出一个很快过期的问答库。
四、Ontology 管的不是文档，而是业务世界
Ontology 常被翻译成“本体”。这个词有些抽象，可以把它理解为一套业务世界说明书。
W3C 对 OWL 的说明是：用机器可处理的方式表达事物、事物集合以及它们之间的关系。落到企业场景，Ontology 通常要回答四类问题：
有哪些类型：客户、区域、组织、产品、订单、指标、工具。
有哪些实例：华东区、客户 A、毛利率、订单明细查询工具。
它们如何关联：客户归属区域，订单属于客户，指标依赖数据字段，工具能够查询某类实体。
有哪些约束：毛利率必须指定口径版本；财务数据需要权限；自然语言地区名必须先解析成组织编码。
比如“华东区”可以被维护为一张实体页：
id: region.east_china
type: SalesRegion
name: 华东区
aliases:
- 华东
- East China
- 东区
contains:
- org.shanghai
- org.jiangsu
- org.zhejiang
valid_from: 2026-01-01
source: 2026版销售组织架构
status: verified
“毛利率”也不是文档中的一个词，而是有定义、有版本、有依赖关系的指标实体：
id: metric.gross_margin_rate.v3
type: BusinessMetric
name: 毛利率
formula: （不含税收入 - 可归属成本）/ 不含税收入
time_basis: 财务月
dimensions:
- region
- customer
- product
data_source: finance_mart.profit_detail
replaces: metric.gross_margin_rate.v2
effective_from: 2026-04-01
有了这些实体，系统才知道用户说的词对应什么业务对象。更重要的是，工具、参数和权限也可以进入同一套 Ontology，而不是继续藏在几十份 API 文档里。
五、一套知识如何被多个场景复用
很多企业按项目建设知识库：客服有一套客户库，经营分析再建一套客户库，风控项目又维护一份客户名称映射。项目上线了，知识也被锁在各自的应用里。半年之后，同一个客户在三个系统里出现三个 ID，同一个“收入”指标有四种解释。
要让知识被复用，需要把公共语义层和场景应用层分开。
公共语义层：
- Ontology：客户、产品、区域、指标、事件等统一类型
- 实体中心：唯一ID、别名、主数据映射和版本
- LLM Wiki：定义、规则、关系、经验和来源
- 工具目录：MCP、CLI、API的能力与参数
- 检索服务：关键词、向量、实体和图关系查询
场景应用层：
- 经营分析：查询收入、毛利和客户贡献
- 客户服务：识别客户、合同、工单与产品
- 风险管理：查询主体关系、规则和异常事件
- 采购管理：关联供应商、物料、价格和合同
场景不再复制知识，只声明自己需要哪些实体、关系、工具和权限。例如“华东区”这个实体由公共语义层维护，经营分析用它查毛利，客服用它分派区域服务团队，风控用它聚合区域风险。组织调整后只更新一次，所有场景都读取新版本。
复用不意味着所有应用拥有相同权限。知识定义可以共享，实体属性和工具调用仍要经过租户、部门、字段和行级权限过滤。Agent 能知道“有这个数据”，不等于它可以读取具体数值。
六、把工具也纳入知识管理
不少平台接入了上百个工具，却把每个工具的完整定义一次性塞进模型上下文。工具越多，Token 越贵，模型也越容易选错。
更合适的做法是分两级暴露。
第一级只给 Agent 一份轻量能力目录，例如：
tool_id: finance.query_profit
name: 查询经营毛利
capability: 按区域、客户、产品和月份查询毛利额与毛利率
entity_types:
- SalesRegion
- Customer
- BusinessMetric
risk_level: read_only
当 Agent 判断这个工具可能适用时，再调用统一的 help 工具取得完整说明：
tool: help
arguments:
tool_id: finance.query_profit
returns:
description: 查询已关账月份的经营毛利数据
required_parameters:
region_id: 标准销售区域ID
start_period: YYYY-MM格式的财务月
end_period: YYYY-MM格式的财务月
metric_id: 已生效的指标口径ID
optional_parameters:
customer_level: 客户等级
top_n: 返回数量，范围1到100
preconditions:
- 用户拥有经营分析数据权限
- region_id必须先经过实体解析
output:
- revenue
- gross_profit
- gross_margin_rate
这类 help 工具，本质上是工具知识库的查询入口。它让 Agent 在需要时才展开参数、示例、限制和返回结构。
MCP 的官方设计也采用类似思想：通过 tools/list 发现工具定义，通过 tools/call 执行工具；工具输入由 JSON Schema 描述。企业可以在此基础上再增加 Ontology，把“自然语言中的业务实体”与“工具要求的参数类型”连接起来。
💡 关键洞察：工具说明不是开发文档的附属品，而是 Agent 的运行时知识。只要工具可被模型调用，它的名称、能力、参数、约束、权限和示例就应该进入统一知识管理。
七、一次自然语言查询，如何串联多个 MCP 和 CLI
回到最初的问题：
“帮我看看华东区上个月毛利为什么掉了，顺便找出影响最大的三个客户。”
这句话背后可能涉及实体解析服务、财务查询工具、客户主数据和归因分析工具。它们可能来自不同的 MCP Server，也可能是已有 CLI、内部 API 或数据平台查询服务。
是否每次都要把所有 MCP 和 CLI 调一遍？不需要。
如果平台有几百个工具，让模型逐个运行 --help，成本高，也会把大量无关参数塞进上下文。更合理的是两级发现：平台先维护一份轻量能力索引，模型根据用户意图筛出几个候选工具，再按需调用 --help、tools/list 或统一 help(tool_id) 取得完整参数。
整条链路可以拆成六步。
7.1 第一步：查看有哪些工具和参数
CLI 通常通过 --help 暴露子命令、参数和示例；MCP 通过 tools/list 返回工具名称、描述和输入 Schema。平台可以把两者统一成一个能力目录：
查询诉求: 华东区上月毛利下降原因
候选能力:
- entity.resolve
来源: master-data MCP
用途: 解析区域、客户、产品和指标实体
- finance.query_profit
来源: finance CLI
用途: 按期间和维度查询收入、毛利额、毛利率
- finance.query_profit_drivers
来源: analytics MCP
用途: 分析价格、销量、成本和一次性项目的影响
能力索引可以定期从 MCP Schema、CLI --help、OpenAPI 文档和数据目录中同步。只有工具版本发生变化时才重新编译，不必每次用户查询都从头扫描。
7.2 第二步：模型选择合适的工具组合
模型先判断任务需要哪些能力，而不是立即生成调用参数。这个问题至少包含三个子任务：
解析“华东区”“上个月”“毛利”； 查询本期、对比期以及客户维度的毛利数据； 对下降幅度最大的客户做原因分析。
因此，它可能选择一个实体解析 MCP、一个财务 CLI 和一个归因分析 MCP。简单查询则可能只需一个工具。例如“客户 A 属于哪个区域”只需要实体或主数据服务。
工具选择依赖三类知识：能力描述是否匹配用户目标，工具是否支持需要的实体与维度，当前用户是否拥有调用权限。
7.3 第三步：把自然语言转换成时间、实体和指标
这一步是 Ontology 真正参与运行的地方。模型不能把用户原话直接塞给底层接口，而要形成标准查询语义：
原始表达:
区域: 华东区
时间: 上个月
指标: 毛利
目标: 找出下降原因和影响最大的三个客户
标准语义:
region_id: region.east_china
current_period: 2026-06
comparison_period: 2026-05
metric_id: metric.gross_margin_rate.v3
ranking_metric: gross_profit_delta
group_by: customer
top_n: 3
时间转换需要结合当前日期、财务日历和数据关账状态。实体转换需要处理别名、层级和生效版本。“毛利”如果存在多个合法口径，系统应根据部门默认规则选择，无法确定时再询问用户。
7.4 第四步：Agent 绑定参数并发起调用
模型已经确定语义，Agent 再根据工具的参数 Schema 绑定字段：
工具: finance.query_profit
参数:
region_id: region.east_china
start_period: 2026-05
end_period: 2026-06
metric_id: metric.gross_margin_rate.v3
group_by: customer
权限上下文:
user_id: user.1024
data_scope: east_china
调用前要做类型、枚举、时间范围和权限校验。查询类工具可以自动执行；涉及写入、付款、发消息等高风险操作时，还需要审批或人工确认。
7.5 第五步：模型解析返回结果，必要时继续调用
财务工具可能只返回一张客户毛利变化表。模型从中找出 A、B、C 三个客户贡献了 78% 的降幅，但这还不足以回答“为什么”。于是 Agent 再调用归因工具，查询价格、销量、成本和一次性费用。
第一次观察:
华东区毛利率: 下降2.1个百分点
主要影响客户: [客户A, 客户B, 客户C]
三家客户贡献: 毛利额降幅的78%
下一步行动:
tool: finance.query_profit_drivers
customer_ids: [customer.a, customer.b, customer.c]
period: 2026-06
第二次观察:
客户A: 折扣增加
客户B: 原材料成本上升
客户C: 一次性售后成本
这就是 ReAct 的作用：模型根据工具返回的观察更新判断，再决定是否继续调用。步骤二到步骤五可能循环多次，直到证据足以回答问题，或者系统发现权限不足、参数缺失、结果冲突而停止。
7.6 第六步：生成用户真正需要的结果
最终回复不应只是把工具 JSON 改写成自然语言。模型还要完成排序、对比、归因和口径说明，并保留可追溯信息：
结论:
华东区2026年6月毛利率环比下降2.1个百分点。
客户A、B、C贡献了78%的毛利额降幅。
原因:
- 客户A折扣率提高，是最大影响项
- 客户B原材料成本上升
- 客户C发生一次性售后成本
口径与来源:
指标: metric.gross_margin_rate.v3
区域: region.east_china
数据工具: finance.query_profit
归因工具: finance.query_profit_drivers
数据状态: 2026-06已关账
用户看到的是一份分析结论，系统内部则完成了工具发现、语义转换、参数绑定、多步执行和证据整理。LLM Wiki 保存工具与业务知识，Ontology 提供统一语义，MCP/CLI 负责访问真实系统，ReAct 负责在执行中调整下一步。
八、LLM Wiki 和 RAG 到底有什么区别
RAG 与 LLM Wiki 并不是二选一。两者解决的问题不同。
RAG 的经典定义来自 Lewis 等人在 2020 年发表的论文：模型在生成答案时访问外部的非参数化知识。工程上通常表现为切分文档、建立索引、检索片段，再把片段交给模型回答。
LLM Wiki 更像一个位于原始资料和问答系统之间的“知识编译层”。模型在资料进入时就完成抽取、归并、交叉引用和冲突标记，查询时优先读取已经维护好的知识页面。
| 对比维度 | RAG | LLM Wiki |
|---|---|---|
| 主要对象 | ||
| 主要处理时机 | ||
| 知识是否积累 | ||
| 关系表达 | ||
| 冲突处理 | ||
| 适合场景 | ||
| 主要风险 |
企业中的合理组合通常是：
原始文档继续由 RAG 提供大范围检索和证据定位； 高频、稳定、跨文档的知识编译进 LLM Wiki； Ontology 统一实体、指标、关系、权限和工具语义； Agent 通过 help 获取工具细节，再用 ReAct 完成任务。
换句话说，RAG 负责找证据，LLM Wiki 负责沉淀认识，Ontology 负责统一语言。
九、企业如何开始：先做一个最小可用 Ontology
不要一开始就试图给整个公司建一张完美的知识图谱。范围过大，半年后可能还停留在字段讨论。
更实际的办法，是选择一个高频、数据明确、结果容易验证的业务场景。例如经营分析、售后工单或采购询价。
9.1 选出最小实体集合
以经营分析为例，第一版可以只有区域、客户、产品、订单、指标和工具六类实体。先解决一个问题：用户说出的业务词，能否稳定映射到系统中的唯一对象。
9.2 为每类实体建立规范页面
页面至少包含唯一 ID、名称、别名、定义、关系、来源、版本、负责人和验证状态。LLM 可以协助抽取，但新增实体、合并实体和修改核心口径要有人审核。
9.3 把工具注册成知识实体
每个工具都要说明：它能解决什么问题、输入参数对应哪些实体类型、调用前置条件、权限、风险、返回结构和失败处理方式。
然后提供统一的能力检索和 help 接口。Agent 不需要提前背下所有工具，只要知道在哪里查。
9.4 建立 Wiki 的摄取、查询和巡检流程
新资料进入时，不能只新增页面，还要检查它影响了哪些旧页面。过期指标要标记替代关系，组织调整要设置生效时间，矛盾结论要保留来源并进入审核队列。
9.5 用真实任务评测，而不是只测问答
评测至少要覆盖：
实体解析是否正确； 指标口径是否匹配场景； 工具选择和参数填写是否正确； 权限不足时是否停止； 多步调用能否根据观察调整计划； 最终结论能否追溯到知识页面和工具结果。
如果只测“答案像不像”，很容易得到一个说得通、却调用错系统的 Agent。
十、知识管理的终点，是让知识能够参与行动
过去做知识库，目标常常是“让员工搜得到文档”。大模型出现后，目标开始变化：系统需要理解知识之间的关系，并据此选择工具、补齐参数、执行任务。
LLM Wiki 解决了知识如何持续沉淀的问题。Ontology 让业务对象、指标口径和工具能力拥有统一语义。RAG 保留对大规模原始资料的检索能力。ReAct 则把这些知识带入一次次真实行动。
这套体系最难的部分，不是搭建向量库，也不是给 Agent 再写一版更长的 Prompt。真正费功夫的是实体治理：同一个客户有没有多个名字，同一个指标有没有多个口径，一次组织调整从哪天生效，一个工具参数究竟对应哪个业务对象。
这些基础工作有些琐碎，却决定了 Agent 是在“猜着调用”，还是在一个清楚、可追溯的业务世界里行动。
