OpenWiki实战:无文档让Agent读懂企业源码业务逻辑

让智能体直读企业源码,自动提炼业务规则构建知识库,再经MCP供Agent调用。
文章围绕企业智能体落地中业务知识缺失的痛点展开。许多项目功能跑通但回复不准,根源是业务描述未文字化、规则边界无人整理、流程讲不清、业务人员不配合。B站UP主展示的OpenWiki(LLM-Wiki)方案改换知识来源:不依赖业务文档,直接让LLM阅读企业源码,从状态机、校验逻辑和异常分支中归纳业务规则,形成结构化知识库,再通过MCP协议暴露给智能体按需检索,实现知识与Agent逻辑解耦、多业务线复用。文章同时指出该方案的边界:源码无法覆盖线下流程与人情判断,代码质量差会降低准确率,结果仍需业务方抽检,宜定位为冷启动阶段的业务知识加速器。
企业落地智能体时,最头疼的往往不是模型能力,而是业务知识散落在代码和口口相传的经验里,没有文档、没人配合。B站UP主在直播中展示了一个名为OpenWiki(LLM-Wiki)的实战案例:不依赖业务文档,让Agent直接阅读企业源码,自动提炼业务规则并构建知识库,再通过MCP协议供智能体调用。本文基于该分享,梳理问题本质、方案思路与可复用的落地要点。
企业智能体落地卡在哪:业务知识没有“文字版”
UP主提到一个普遍现象:不少已就业的学员反馈,给甲方做的智能体功能都跑通了,但回复准确性很差。追根溯源,问题不在RAG或工具调用,而在于智能体没有真正理解企业业务。
企业业务知识通常面临四个缺口:业务描述没有形成文字,往往是客服经理带几个新人手把手教会就完事;业务规则和业务边界没人整理,看到什么情况该怎么处理全靠经验;完整业务流程没人讲得清,只告诉你一部分;业务人员普遍不配合,觉得“事不关己”。指望临时拉几个业务权威逐条写规则、从头捋流程,在真实项目里几乎不可能。

这就引出了一个更现实的命题:既然拿不到文字,能不能让智能体自己去“读”企业已有的资产?而企业中唯一被强制维护、且相对完整的资产,恰恰是源码。
OpenWiki方案:从源码反向提炼业务规则
OpenWiki(LLM-Wiki)的核心思路,是把企业代码库当作业务知识的第一手来源。UP主模拟了一条订单客服业务线,同样没有提供任何业务文档,直接让系统去分析代码,自动提炼出订单维护、异常处理等业务规则,形成结构化知识库。
从工程视角看,这条路走通的关键在于三点。其一,源码里沉淀了状态机、校验逻辑、异常分支,这些正是业务规则的“硬约束”,比人口述更准确。其二,LLM擅长从代码中归纳意图,把if-else和状态流转翻译成自然语言规则。其三,提炼结果需要结构化存储,才能被后续检索和调用,而不是变成一堆散乱的摘要。

需要说明的是,UP主在直播中侧重演示整体流程与效果,未展开代码级实现细节。因此本文对该方案的描述以思路和结构为主,具体参数与提示词设计建议以原项目为准。
从源码归纳业务规则本质上是一种“逆向工程 + 意图推断”的组合。代码中的状态机(如订单从待支付到已发货的状态迁移)、参数校验、异常捕获和权限判断,构成了系统实际执行的业务约束;但代码表达的是“怎么实现”,而非“为什么这样规定”。LLM 的作用是把实现细节翻译为业务语义,这要求它对领域术语、框架约定和命名习惯有一定先验。实践中常见的难点包括:跨文件、跨模块的调用链追踪,隐式规则(如数据库默认值、配置项)的识别,以及避免把技术实现细节误写成业务规则。因此提炼结果通常需要按业务域组织成分层结构——领域概述、规则条目、触发条件与处理动作,才能兼顾可读性与可检索性。
结合MCP协议:让提炼出的知识被智能体调用
知识库建好只是第一步,真正产生价值要靠调用。该案例将OpenWiki产出的业务知识库通过MCP协议暴露给智能体,使Agent在对话或任务执行中能按需检索业务规则,而不是把全部内容塞进上下文。

这种分层设计有两个好处。一是知识更新与智能体逻辑解耦,代码变更后重新提炼即可,不必改Agent。二是MCP作为标准接口,同一份知识库可以被不同智能体复用,避免每个业务线重复建设。对于多业务线的企业,这能显著降低边际成本。
MCP(Model Context Protocol)是 Anthropic 于 2024 年底开源的一项标准化协议,用于在 LLM 应用与外部数据源、工具之间建立统一连接。它采用客户端-服务器架构:MCP Server 负责把数据源或能力(如数据库、文件系统、知识库、API)封装成带描述的资源与工具,MCP Client(通常是智能体运行时或 IDE)则按需发现并调用这些能力。相比为每个数据源单独写适配代码,MCP 让同一份知识库可以被不同模型、不同框架的智能体即插即用地访问,这也是原文强调“知识更新与智能体逻辑解耦”“多业务线复用”的技术基础。理解 MCP 的资源-工具抽象,有助于判断知识库应以检索接口还是工具调用的形式对外暴露。
对开发者的启示与边界
这个案例的价值不在于“又一个RAG项目”,而在于换了个知识获取的方向:过去是从文档到智能体,现在是从代码到规则再到智能体。对于文档缺失严重、业务人员难协调的企业场景,这条路具备现实可行性。

同时也要看到边界。源码能反映系统实现的规则,但反映不了系统之外的线下流程和人情判断;代码质量差、注释缺失的项目,提炼准确率会打折扣;提炼结果仍需要业务方抽检确认,不能完全替代人工。把它定位为“冷启动阶段的业务知识加速器”更为准确。
对正在做企业智能体落地的开发者来说,可以优先梳理核心业务模块的代码,尝试让LLM生成规则草案,再通过MCP接入智能体做小范围验证。这条路不要求业务方先写文档,启动阻力小,适合作为破局的第一刀。
相关推荐

Mistral Large 4开源万亿参数,微软6万员工自愿离职
Mistral Large 4 开源万亿参数多模态模型,编码智能体评测得分 48;闪迪财报显示 AI 推理重塑 NAND 需求;谷歌 Gemini 上线应用内文件编辑,OpenAI 上调 Codex 额度,微软向 6 万员工提供自愿离职方案。

Mistral Large 4开放权重,AI早报盘点模型与生态新动向
Mistral Large 4开放权重,1万亿参数MoE架构支持MacStudio本地运行;Meta测试生成技术进入生产环境;税务基准测试头名通过率仅10.8%;加拿大政府入股Cohere;豆包工作开放第三方模型调用。本期AI早报盘点模型、生态、资本与政策动向。

Mistral Large 4开源:1T参数欧洲版千问挑战DeepSeek
Mistral Large 4正式开源,1T总参数、52B激活参数,主打编程与网络安全,NVFP4量化版本权重约610G。本文解析其与DeepSeek V4 Flash的对比、API定价、Demo真实性与本地部署价值。