LLM WIKI架构解析：让智能体真正理解企业业务

企业想用大模型落地业务线，最头疼的问题往往不是技术选型，而是智能体根本不懂业务。B站UP主老肖（马式教育大模型主讲）在实操教程中，用LLM WIKI架构给出了一个值得参考的解题思路。

企业智能体落地的真正卡点：业务知识没有文字化

老肖在视频开场就抛出一个现实场景：不管是电商、物流、制造业还是银行，每条业务线都想结合大模型做降本增效。但落地时最难的环节是——让智能体理解企业业务。

问题出在业务知识的存在形态上。很多企业的业务规则、边界、流程只存在于老员工的大脑中，没有形成文字描述。一个客服经理带两个助手手把手教，教完就结束了，没有人把"看到什么情况该怎么处理"写成文档。更麻烦的是，业务人员往往不配合FDE工程师（Forward Deployed Engineer，前置部署工程师），觉得落地是工程师自己的事。

结果就是：智能体做出来了，但它并不真正理解业务。这个判断在多个技术社区的讨论中也能得到印证——企业AI项目的失败率居高不下，数据与知识治理的缺失是第一大原因。

FDE（Forward Deployed Engineer，前置部署工程师） 是一种源于Palantir等企业软件公司的角色模式，指工程师直接驻场到客户业务团队中，与业务人员共同工作，理解实际流程后再设计并落地技术方案。与传统“需求方提需求、研发方做交付”的甲乙关系不同，FDE强调工程师主动深入业务现场，把模糊的、口口相传的隐性知识转化为可执行的产品逻辑。在企业大模型落地场景中，FDE需要同时具备业务理解力与工程能力，是连接业务线与技术栈的关键桥梁。老肖提到业务人员不配合FDE，本质上反映的是组织协作机制缺失——业务方把AI落地视为IT部门的事，而FDE又缺乏足够权限和激励去推动知识外化，导致智能体项目在需求源头就断了链条。

LLM WIKI架构的核心思路

老肖给出的方案是LLM WIKI架构。虽然视频中他没有逐条展开架构图，但从他模拟订单客服业务线的实操可以反推出核心逻辑：不依赖业务人员主动提供文字，而是让智能体通过WIKI式的知识组织结构，自己沉淀、关联和检索业务知识。

具体来说，这套架构要解决三个层次的问题：

• 知识采集：从对话、操作记录、工单等非结构化数据中提取业务规则，而非等待人工编写文档。
• 知识组织：用WIKI的页面-链接结构组织知识条目，让规则之间可以相互引用、形成网络。
• 知识调用：智能体在处理任务时按需检索相关WIKI条目，作为上下文注入推理过程。

这套思路与业界主流的RAG（检索增强生成）方案一脉相承，但更强调知识的结构化沉淀，而非简单地把文档切片塞进向量库。

RAG（Retrieval-Augmented Generation，检索增强生成） 是目前企业大模型落地最主流的技术范式：先从外部知识库中检索与用户问题相关的文档片段，再把这些片段作为上下文拼接到提示词中，让大模型基于检索到的内容生成回答。它的核心价值在于缓解大模型“幻觉”和知识时效性问题，使模型能够引用企业私有数据。但标准RAG依赖文档切片与向量相似度检索，存在明显局限：切片会破坏文档的语义结构，向量检索难以表达规则之间的逻辑关系，且对“看到A情况应执行B操作”这类条件性业务规则召回效果不稳定。LLM WIKI强调的页面-链接式知识组织，正是对标准RAG“扁平切片”缺陷的一种结构性修正，让知识条目之间可以显式引用和跳转，更贴近业务规则的实际组织方式。

实操案例：模拟订单客服业务线

为了让理论不枯燥，老肖直接模拟了一条订单客服业务线——没有任何现成文字，维护规则、处理流程全靠智能体自己搞定。

对学过RAG和智能体开发的同学来说，常规做法并不陌生：定义几个工具，搭一个智能体，配上短期记忆和长期记忆，再接上MCP或SKILL之类的扩展机制。

但老肖强调，光把这些组件拼起来，你依然说不清楚这个订单客服具体要做什么。组件是骨架，业务知识才是血肉。LLM WIKI架构的价值就在于给骨架填上血肉——让智能体在处理订单时，能查到自己沉淀下来的处理规则，而不是每次都靠通用推理瞎猜。

MCP（Model Context Protocol，模型上下文协议） 是由Anthropic提出并开源的一种标准化接口协议，用于让大模型应用以统一方式连接外部工具、数据源和服务。可以把MCP理解为“AI应用的USB-C接口”：无论底层是数据库、CRM系统还是内部API，只要实现MCP服务端，智能体就能通过统一协议发现并调用这些能力，而不需要为每个工具单独写适配代码。SKILL机制则通常指在智能体框架中以声明式方式注册的可复用能力单元，描述“什么场景下调用什么工具、传什么参数”。两者结合，让智能体从“只会聊天”进化为“能执行操作”。老肖强调这些组件只是骨架，正是因为MCP和SKILL解决的是“能不能调用”的问题，而“该不该调用、按什么规则处理”仍取决于业务知识是否被有效沉淀。

对开发者的启示

老肖的分享提供了一个务实视角：企业智能体落地，工程能力只是一半，另一半是知识工程。与其抱怨业务人员不配合，不如设计一套能让智能体主动学习业务知识的架构。LLM WIKI的思路值得在真实项目中验证和迭代。