[控场AI]
· 4 分钟阅读· 2,246 字

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

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接入智能体做小范围验证。这条路不要求业务方先写文档,启动阻力小,适合作为破局的第一刀。

#OpenWiki#LLM-Wiki#企业知识库#MCP协议#智能体#源码分析#业务规则提炼
分享:

相关推荐