LLM WIKI实战：让智能体真正读懂企业业务，排障Agent从0到1

很多团队把智能体做出来了，但回复准确率惨不忍睹。问题不在模型，而在于智能体根本没理解企业业务。本文基于一个订单客服排障Agent的真实落地案例，拆解如何用LLM WIKI把代码库和业务逻辑变成智能体可理解的知识，覆盖概念原理、仓库构建、增量更新、MCP服务端到排障实战的完整链路。

智能体准确性差的根源

为什么你的智能体“不懂业务”？

据B站UP主（马式教育大模型主讲老师）的分享，他最近三个月给就业学员打电话，几乎所有人都在诉苦：给甲方做的智能体上线了，但回复准确性非常差。追问下来，最核心的原因只有一个——智能体没有真正理解企业的业务。

这个判断在视频里被反复强调，也是后续所有方案设计的出发点。企业业务落地到智能体时，普遍卡在三个现实障碍上：

业务描述没有文字化：以客服为例，通常是客服经理带几个助手和普通员工手把手教，教完就结束，没有人把业务规则和业务边界写成文档。
业务流程不完整：没人告诉你完整流程，只给一部分，剩下靠“老人”的经验，而这些经验同样没有走进文字。
业务人员不配合：不少业务线的人觉得“事不关己”，让FD工程师自己去了解业务线，领导最多说一句“你跟着业务线走一个星期”。

业务描述文字化的困境

结果就是：你想生成文字、想组织权威业务人员一条条梳理规则、想从头到尾捋流程，现实中都推不动。这不是技术问题，是组织协作问题——而LLM WIKI要解决的，正是这个“没人给你写文档”的僵局。

LLM WIKI是什么：把代码库变成智能体的业务知识库

UP主没有停留在理论层面，而是直接模拟了一条订单客服业务线：同样没有任何文字化的业务规则、没有完整流程文档。他要验证的是——在“零文档”前提下，智能体能不能自己处理订单客服问题。

LLM WIKI的思路可以理解为：让智能体从代码库和系统中反向抽取业务知识，形成结构化、可检索的Wiki，再通过MCP服务端暴露给排障Agent使用。这与传统RAG的区别在于，RAG通常依赖人工整理的文档切片，而LLM WIKI的知识源是代码库本身——代码里藏着订单状态流转、异常分支、接口约束，这些就是最真实的业务规则。

真实案例演示

据该UP主的演示，他使用的对话模型是DeepThink Flash（1017版本），构建的是一个“订单故障诊断客服助手”，面向消费者解答诸如“我这个订单为什么还没有出库”这类问题。这个场景看似简单，但背后需要智能体理解订单从下单、出库到交付的完整链路，以及每个环节出问题时的处理规则。

RAG（Retrieval-Augmented Generation，检索增强生成） 是当前智能体接入外部知识的常见范式：先由人工把文档切片、向量化存入向量库，用户提问时检索最相关的片段拼进提示词，再由大模型生成回答。它的瓶颈在于知识源依赖人工整理的高质量文档，切片粒度与召回质量高度依赖文档结构。LLM WIKI 把知识源换成了代码库与系统本身：代码中的状态机、条件分支、接口校验、异常处理天然具备结构化语义，且与线上行为严格一致。二者并不互斥——Wiki 可作为 RAG 的上游知识生产环节，把代码翻译成语义完整的条目后再做检索，从而绕开“没人写文档”的前置依赖。

仓库构建：从代码库抽取业务知识

构建LLM WIKI仓库的关键动作，是把代码库中的业务逻辑提炼成可被智能体检索的条目。结合案例，可以拆成三层：

实体与状态层：订单有哪些状态（待支付、已支付、待出库、已出库、运输中、已签收），状态之间如何流转，哪些流转是异常分支。
规则与边界层：什么条件下订单会被判定为“有问题”，比如超时未出库、库存锁定失败、支付回调异常，每种情况的处理动作是什么。
流程与角色层：客服在处理订单问题时需要了解交付过程，交付出问题该找谁、走什么流程。

这些信息在代码里往往是分散的——状态机定义在一个文件，异常处理在另一个文件，接口校验又在别处。LLM WIKI的价值就是把它们聚合成一个可读、可查、可更新的知识库，而不是让智能体每次从零去读整个代码库。

增量更新：让知识库跟上业务变化

业务代码天天在改，知识库如果只能一次性构建，很快就会过期。增量更新是LLM WIKI能长期可用的前提。

从案例的工程思路看，增量更新需要解决两个问题：一是识别变更，即代码提交后哪些文件、哪些函数影响了业务规则；二是局部重建，只更新受影响的知识条目，而不是全量重跑。这样既控制了成本，也保证了智能体拿到的业务规则和线上代码一致。

这一点在排障场景尤其重要——排障Agent给出的结论如果基于过时的规则，反而会把客服带偏。

增量更新在工程上通常依赖两类信号：一是版本控制系统的变更信息，如 git diff 给出的文件与函数级改动；二是代码的静态结构，如抽象语法树（AST）与调用关系图，用于判断某个函数被哪些业务条目引用。有了这层依赖映射，就能把“代码改了哪几行”转换为“哪几条业务规则受影响”，进而只重建受影响的 Wiki 条目。与之相对的全量重建成本随代码库规模线性增长，在业务高频迭代的团队里几乎不可持续。工程上还需处理幂等与版本对齐问题：同一条目多次重建应得到稳定结果，并记录其对应的代码提交版本，便于排障时追溯结论依据。

MCP服务端：把Wiki能力暴露给Agent

LLM WIKI构建完成后，需要一个标准化的通道让智能体调用。MCP（Model Context Protocol）服务端承担的就是这个角色：把Wiki的检索、查询能力封装成工具，智能体在排障时按需调用。

这样做的好处是解耦——知识库的构建和更新可以独立迭代，智能体只关心“问什么、拿什么”。UP主在演示中也提到，学员大多学过大模型、智能体和RAG技术，知道要定义工具、配上文、加短期和长期记忆，但真正卡住的是“智能体不明白业务具体做什么”。MCP服务端接上LLM WIKI，补的正是这块业务理解的短板。

理解业务是落地前提

MCP（Model Context Protocol） 是一套面向大模型应用的开放协议，用于把外部数据源与能力以标准化的“工具/资源”形式暴露给模型客户端。它采用客户端—服务端架构：MCP 服务端声明自己提供哪些工具及其入参出参结构，Agent 侧的客户端在运行时发现这些工具并按需调用，无需为每个数据源单独写适配代码。对 LLM WIKI 而言，这意味着检索条目、按实体查询状态流转、读取异常处理规则等能力可以被封装为若干工具，供不同 Agent 复用。其价值在于接口标准化带来的解耦：知识库的存储结构、更新策略可以独立演进，只要工具契约不变，Agent 侧无需改动。

排障实战：订单客服Agent如何工作

回到演示的订单故障诊断助手。用户提出“订单为什么还没出库”，Agent的工作链路大致是：

通过MCP调用LLM WIKI，检索订单状态流转规则和出库条件；
结合当前订单的实际状态，判断卡在哪个环节；
依据Wiki中的异常处理规则，给出对应的解释和下一步动作。

这个过程里，Agent不需要预先被“教会”所有业务细节，而是把Wiki当作可查询的业务手册。对于FD工程师来说，这意味着不必再依赖业务人员配合写文档——代码库本身就是知识源，LLM WIKI负责把它翻译成智能体能用的形式。

这套方案适合谁

从案例可以归纳出适用边界：业务逻辑主要沉淀在代码和系统中的团队，最适合用LLM WIKI补业务理解；如果业务规则大量存在于线下口头经验、且系统里几乎没有体现，那LLM WIKI能抽取的内容也有限，仍需配合人工梳理。

另一个现实约束是增量更新的工程质量——变更识别做得粗，知识库就会失真。这一点在视频中未展开细节，属于需要在落地中重点验证的环节。

总体来看，LLM WIKI给“智能体不懂业务”提供了一个可操作的工程路径：不依赖业务方写文档，而是从代码库反向构建知识，再用MCP接入排障Agent。对于正在被智能体准确率困扰的团队，这条链路值得动手跑一遍。