OpenWiki in Practice: Enabling Agents to Understand Enterprise Source Code Business Logic Without Documentation

Title

OpenWiki in Practice: Enabling Agents to Understand Enterprise Source Code Business Logic Without Documentation

Meta Description

Based on a Bilibili OpenWiki practice-sharing session, this article explains how to make an Agent read enterprise source code to automatically extract business rules and build a knowledge base without relying on business documentation, and expose it to agents via the MCP protocol. It also covers enterprise implementation challenges and the boundaries of the approach.

Article Content

When enterprises implement agents, the biggest headache is often not model capability, but that business knowledge is scattered across code and word-of-mouth experience—no documentation, no one to cooperate. A Bilibili creator demonstrated a practical case called OpenWiki (LLM-Wiki) in a livestream: without relying on business documentation, let an Agent directly read enterprise source code, automatically extract business rules and build a knowledge base, then expose it to agents via the MCP protocol. Based on that sharing, this article sorts out the essence of the problem, the solution approach, and reusable implementation points.

Where Enterprise Agent Implementation Gets Stuck: Business Knowledge Has No "Written Version"

The creator mentioned a common phenomenon: many already-employed trainees reported that the agent features they built for clients all worked, but response accuracy was poor. Tracing back, the problem is not RAG or tool calling, but that the agent does not truly understand the enterprise business.

Enterprise business knowledge usually faces four gaps: business descriptions are not written down, often just taught hands-on by a customer service manager to a few newcomers; business rules and boundaries are not organized by anyone, and how to handle various situations depends entirely on experience; the complete business process is not clearly explained by anyone, only part of it is told; and business personnel generally do not cooperate, feeling it is "none of their business." Expecting to temporarily pull a few business authorities to write rules one by one and sort out processes from scratch is almost impossible in real projects.

This leads to a more realistic proposition: since written text is unavailable, can the agent "read" the enterprise's existing assets by itself? The only asset in an enterprise that is mandatorily maintained and relatively complete is precisely the source code.

The OpenWiki Solution: Reverse-Engineering Business Rules from Source Code

The core idea of OpenWiki (LLM-Wiki) is to treat the enterprise codebase as the primary source of business knowledge. The creator simulated an order customer service business line, also without providing any business documentation, and directly let the system analyze the code to automatically extract business rules such as order maintenance and exception handling, forming a structured knowledge base.

From an engineering perspective, the key to making this path work lies in three points. First, the source code contains state machines, validation logic, and exception branches—these are the "hard constraints" of business rules, more accurate than human narration. Second, LLMs are good at inducing intent from code, translating if-else and state transitions into natural language rules. Third, the extraction results need to be stored in a structured way so they can be retrieved and invoked later, rather than becoming a pile of scattered summaries.

It should be noted that the creator focused on demonstrating the overall process and effects in the livestream, without elaborating on code-level implementation details. Therefore, this article's description of the solution is mainly based on ideas and structure; for specific parameters and prompt design, please refer to the original project.

Inducing business rules from source code is essentially a combination of "reverse engineering + intent inference." State machines in the code (such as order state transitions from pending payment to shipped), parameter validation, exception catching, and permission checks constitute the business constraints the system actually executes; but code expresses "how to implement," not "why it is stipulated this way." The role of the LLM is to translate implementation details into business semantics, which requires some prior knowledge of domain terminology, framework conventions, and naming habits. Common difficulties in practice include: tracing call chains across files and modules, identifying implicit rules (such as database default values and configuration items), and avoiding mistakenly writing technical implementation details as business rules. Therefore, extraction results usually need to be organized into a hierarchical structure by business domain—domain overview, rule entries, trigger conditions, and handling actions—to balance readability and retrievability.

Combining with the MCP Protocol: Letting Agents Invoke the Extracted Knowledge

Building the knowledge base is only the first step; real value comes from invocation. This case exposes the business knowledge base produced by OpenWiki to agents via the MCP protocol, so that the Agent can retrieve business rules on demand during conversations or task execution, instead of stuffing all content into the context.

This layered design has two benefits. First, knowledge updates are decoupled from agent logic: after code changes, re-extraction is enough, with no need to modify the Agent. Second, as a standard interface, MCP allows the same knowledge base to be reused by different agents, avoiding repeated construction for each business line. For enterprises with multiple business lines, this can significantly reduce marginal costs.

MCP (Model Context Protocol) is a standardized protocol open-sourced by Anthropic at the end of 2024, used to establish unified connections between LLM applications and external data sources and tools. It adopts a client-server architecture: the MCP Server is responsible for packaging data sources or capabilities (such as databases, file systems, knowledge bases, and APIs) into described resources and tools, while the MCP Client (usually an agent runtime or IDE) discovers and invokes these capabilities on demand. Compared with writing separate adapter code for each data source, MCP allows the same knowledge base to be accessed plug-and-play by agents of different models and frameworks, which is also the technical basis for the original article's emphasis on "decoupling knowledge updates from agent logic" and "reuse across multiple business lines." Understanding MCP's resource-tool abstraction helps determine whether the knowledge base should be exposed externally as a retrieval interface or as tool calls.

Implications and Boundaries for Developers

The value of this case is not "yet another RAG project," but that it changes the direction of knowledge acquisition: in the past it was from documentation to agent; now it is from code to rules and then to agent. For enterprise scenarios with severe documentation gaps and difficult-to-coordinate business personnel, this path is practically feasible.

At the same time, boundaries must be recognized. Source code can reflect rules implemented by the system, but cannot reflect offline processes and human judgment outside the system; for projects with poor code quality and missing comments, extraction accuracy will suffer; extraction results still need spot-check confirmation by the business side and cannot completely replace manual work. It is more accurate to position it as a "business knowledge accelerator for the cold-start phase."

For developers currently implementing enterprise agents, they can prioritize sorting out the code of core business modules, try letting the LLM generate draft rules, and then connect them to agents via MCP for small-scale validation. This path does not require the business side to write documentation first, has low startup resistance, and is suitable as the first cut to break through.

One-line Summary

Let agents read enterprise source code directly, automatically extract business rules to build a knowledge base, and then expose it to agents via MCP.

Paragraph Summary

The article focuses on the pain point of missing business knowledge in enterprise agent implementation. Many projects have working features but inaccurate responses; the root cause is that business descriptions are not written down, rule boundaries are not organized, processes are not clearly explained, and business personnel do not cooperate. The OpenWiki (LLM-Wiki) solution demonstrated by a Bilibili creator changes the knowledge source: without relying on business documentation, it directly lets the LLM read enterprise source code, induce business rules from state machines, validation logic, and exception branches, form a structured knowledge base, and then expose it to agents via the MCP protocol for on-demand retrieval, achieving decoupling of knowledge from agent logic and reuse across multiple business lines. The article also points out the boundaries of this solution: source code cannot cover offline processes and human judgment, poor code quality will reduce accuracy, results still need spot-checking by the business side, and it should be positioned as a business knowledge accelerator for the cold-start phase.