Power grid dispatching fault handling method and system based on AI intelligent agent

Abstract

The invention discloses a power grid dispatching fault handling method and system based on an AI intelligent agent. The system comprises a multi-mode knowledge base, a large language model, an MCP service and an RPA platform. The multi-modal knowledge base fuses vectorized semantic understanding and mapping association reasoning, so that the fault disposal scheme generation quality in a complex fault scene is remarkably improved; the large language model generates a fault handling scheme based on RAG and KAG technologies, and safe and controllable connection of decision and execution is realized by introducing an MCP as a standardized interaction bridge between the large language model and an RPA platform; the MCP service is used for the large language model to call an external tool; the RPA platform provides an RPA process plug-in library and an RPA process executor, is responsible for plug-in management and process management, and interacts with the large language model through the MCP service, so that the AI intelligent agent can complete process deployment and scheduling only through a unified MCP tool interface, and the advantages of the system in the aspects of expansibility, maintainability and cross-platform adaptation are greatly improved.

Description

Technical Field

[0001] This invention relates to a power grid dispatch automation system, and more particularly to a power grid dispatch fault handling method and system based on an AI agent. Background Technology

[0002] AI agents represent the core form of next-generation AI applications. They transcend the traditional question-and-answer model of chatbots, endowing AI with the ability to understand, think, and use tools, enabling it to autonomously complete complex tasks and become powerful agents and executors for humans in the digital and physical worlds. Large language models provide AI agents with fundamental understanding, reasoning, and interaction capabilities, allowing them to communicate seamlessly with humans or other systems in natural language. The essence of large language models is probabilistic; their internal knowledge may be outdated, inaccurate, or even misleading. Knowledge bases, storing verified, structured proprietary knowledge, compensate for the inherent limitations of large language models, providing factual basis for the AI ​​agent's answers and greatly improving their reliability.

[0003] In the prior art, the invention patent with patent publication number CN119377360A discloses an AI Agent based on a large language model and a collaborative knowledge graph and its implementation method. It mainly solves the problem of the lack of professional knowledge and normative constraints of the large language model in the RPA process generation process by collaborating the large language model and the knowledge graph, thereby improving the accuracy and efficiency of the large language model in generating the RPA process. However, the above technology integrates the RPA module into the AI ​​agent, which is not flexible enough and lacks scalability and versatility. Summary of the Invention

[0004] Purpose of the invention: The purpose of this invention is to provide a system for automatically deploying and automatically executing fault handling in a power grid dispatch automation system. Another purpose of this invention is to provide a fault handling method.

[0005] Technical solution: The power grid dispatching fault handling system based on AI intelligent agents described in this invention includes:

[0006] A multimodal knowledge base includes a vectorized indexing unit and a knowledge graph unit; the vectorized indexing unit represents professional knowledge in a vectorized manner; the knowledge graph unit stores data in a graph structure.

[0007] Large Language Model: Receives fault handling requests in natural language, obtains relevant professional knowledge and fault knowledge by querying vectorized index units, rewrites the original fault handling request into a fault description, and performs association reasoning based on the fault description by retrieving knowledge graph units, and generates fault handling solutions using RAG and KAG technologies;

[0008] MCP Service: Provides the large language model with a way to call external tools. It registers the interfaces in the RPA platform with the MCP service as tools, and the large language model interacts with the RPA platform through the tools provided by the MCP.

[0009] RPA Platform: Provides an RPA process plugin library and RPA process executor, and is responsible for plugin management and process management. It interacts with the large language model through the MCP service.

[0010] The vectorized index unit stores standard and specification documents in the vertical field of power automation, including "Electrical Engineering Terminology", "Power Grid Dispatch Standard Terminology", "Power Safety Work Procedures", and "Power Automation Communication Networks and Systems", which assist the large language model in completing natural language understanding and standardized rewriting.

[0011] The knowledge graph unit stores the hardware topology, software architecture, operation and maintenance manuals, fault handling plans, RPA plug-in information, and RPA standard process documents of the power grid automation system in a graph structure. It integrates the originally scattered knowledge with different structures into a unified graph model for representation, and assists the large language model in generating RPA fault handling plans and RPA process documents.

[0012] The RPA plugin information includes the plugin name, ID, plugin function, plugin input parameters, and plugin return results.

[0013] The MCP service includes tools for saving RPA process files, tools for executing RPA processes, and tools for querying the execution status of RPA processes.

[0014] The input to the tool for saving RPA process files is a process file conforming to the RPA platform specifications. The execution logic is to call the RPA platform's save process file interface to save the process file to the RPA platform's process repository. The input to the tool for executing RPA processes is the process ID and runtime parameters. The execution logic is to call the RPA platform's execute RPA process interface to queue the specified process in the execution engine's execution queue and obtain the task ID. The input to the tool for querying the execution status of RPA processes is the task ID, and the tool queries the execution status of RPA processes, including the execution result.

[0015] The RPA process file defines the plug-in sequence for automated operations, plug-in parameter configurations, and logical judgments between steps.

[0016] The large language model calls the tool for saving RPA process files to save the generated RPA process files to the RPA platform; the large language model calls the tool for executing RPA processes to queue the specified process into the execution engine's execution queue and obtain the task ID; the large language model calls the tool for querying the execution status of the specified RPA process execution task through polling to query the execution status of the specified RPA process execution task until the task is completed and the task execution result is obtained.

[0017] The large language model, based on the Prompt constraints, summarizes the RPA process task execution results obtained in the previous step into a fault handling execution report and saves it as a Word document.

[0018] The power grid dispatching fault handling method based on AI intelligent agents described in this invention includes the following steps:

[0019] (1) Receive fault handling requests described in natural language;

[0020] (2) Use the large language model to query the vectorized index unit to obtain relevant professional knowledge and fault knowledge, and rewrite the original fault handling request into a structured and unambiguous fault description, including fault type, fault entity, fault time, fault level and fault phenomenon description.

[0021] (3) The large language model retrieves knowledge graph units based on structured and unambiguous fault descriptions;

[0022] (4) If the large language model can retrieve relevant knowledge in the fault description, then proceed to step (5); otherwise, return to step (1) and wait for the fault handling request again.

[0023] (5) The large language model performs association analysis and reasoning based on the retrieved relevant knowledge, and generates a fault handling plan including specific operation steps through RAG and KAG technology. Each operation step corresponds to an RPA plugin.

[0024] (6) The large language model converts the fault handling solution generated in the previous step into a standard process file in JSON format that can be executed by the RPA platform;

[0025] (7) The large language model calls the tool in MCP to save the RPA process file and saves the generated RPA process file to the RPA platform;

[0026] (8) The large language model calls the execution RPA process tool in MCP to queue the specified process into the execution engine's execution queue and obtain the task ID;

[0027] (9) The Big Prophet model calls the query execution status tool in the MCP service in a polling manner to query the execution status of the specified task ID until the task is completed and obtains the task execution result;

[0028] (10) Based on the Prompt prompt word constraint, the large language model summarizes the RPA process task execution results obtained in the previous step into a fault handling execution report and saves it as a Word document.

[0029] Beneficial effects: Compared with the prior art, the present invention has the following significant advantages: (1) By constructing a multimodal knowledge base that integrates vectorized index and knowledge graph, the large language model is endowed with dual cognitive capabilities. The two work together to enable the large language model to take into account both fuzzy semantic matching and precise relational deduction, significantly improving the ability to generate reliable and compliant handling solutions in a variable fault environment; (2) By using vectorized index to realize semantic retrieval and associative memory of unstructured professional text, the breadth of understanding of complex fault scenarios is improved; (3) By relying on knowledge graph to realize precise association and logical reasoning of structured knowledge, the rigor and interpretability of handling solution generation are enhanced; (4) By introducing Model Context Protocol (MCP) as a standardized interaction bridge between the large language model and the RPA platform, not only is the safe and controllable connection between decision-making and execution realized, but also decoupling is achieved at the architectural level. This design enables the AI ​​agent to complete process deployment and scheduling without relying on a specific RPA platform for implementation details, and only through a unified MCP tool interface, greatly improving the system's advantages in scalability, maintainability and cross-platform adaptability. Attached Figure Description

[0030] Figure 1 This is a diagram of the AI ​​agent architecture of the present invention;

[0031] Figure 2 This is a diagram showing the structural composition and internal data flow of the MCP module of the present invention;

[0032] Figure 3 This is a time-series data flow diagram of the AI ​​agent of the present invention calling the RPA platform interface through the MCP service. Detailed Implementation

[0033] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0034] Example 1

[0035] The fault handling method for power grid dispatch automation system based on AI intelligent agents described in this invention comprises three modules: a large language model, a multimodal knowledge base, and an MCP, as well as an external RPA platform, such as... Figure 1 As shown.

[0036] The multimodal knowledge base comprises two parts: a vectorized indexing unit, which uses vectorized indexes to index standard knowledge from vertical power industry business documents such as "Electrical Engineering Terminology," "Power Grid Dispatch Standard Terminology," "Power Safety Work Regulations," and "Power Automation Communication Networks and Systems," assisting the large language model in natural language understanding and standardized rewriting; and a knowledge graph unit, which stores the hardware topology, software architecture, operation and maintenance manuals, fault handling plans, RPA plugin information, and RPA standard process documents of the power grid automation system in a graph structure. This integrates previously scattered knowledge with different structures into a unified graph model for representation, providing associative reasoning support for the large language model modules and assisting the large language model in generating RPA fault handling plans and RPA process documents. The RPA plugin information includes the plugin name and ID, plugin function, plugin input parameters, and plugin return results.

[0037] To achieve secure and controllable integration, the Model Context Protocol (MCP) is introduced to enable interaction with the RPA platform. The MCP service allows the AI ​​large language model to call external tools, registering the interfaces in the RPA platform with the MCP service as tools. The AI ​​large model interacts with the RPA platform through the tools provided by the MCP. Furthermore, the RPA platform provides an RPA process plugin library and an RPA process executor, responsible for plugin management and process management, and interacts with the large language model through the MCP service, acting as the implementer of fault handling solutions.

[0038] The large language model first understands the fault handling request by retrieving vector index units from the multimodal knowledge base, rewriting the original fault handling request into a structured, unambiguous fault description, including fault type, fault time, fault level, and fault symptom description. Second, based on the rewritten standardized fault description, the large language model retrieves knowledge graph units from the multimodal knowledge base, utilizing RAG (Retrieval Enhanced Generation) and KAG (Knowledge Graph Enhanced Generation) techniques to generate a fault handling plan, which is then converted into a standard JSON format process file executable by the RPA platform. Finally, the large language model calls the RPA process file saving tool (rpa_flow_deploy) in the MCP module to save the generated RPA process file. The PA process file is saved to the RPA platform. Then, the large language model calls the RPA process execution tool (rpa_flow_execute) in the MCP module to queue the specified process into the execution engine's execution queue and obtain the task ID (jobId). The large language model calls the execution status query tool (rpa_flow_query) in the MCP module in a polling manner to query the execution status of the specified RPA process execution task until the task is completed and the task execution result is obtained. Finally, based on the Prompt constraint, the large language model summarizes the RPA process task execution results obtained in the previous step into a fault handling execution report and saves it as a Word document.

[0039] Example 2

[0040] This embodiment illustrates the specific implementation steps of the system fault handling method as follows:

[0041] (1) Receive fault handling requests described in natural language;

[0042] (2) The large language model queries the vectorized index unit to obtain relevant professional knowledge and fault knowledge, and rewrites the original fault handling request into a structured and unambiguous fault description, including fault type, fault entity, fault time, fault level, and fault phenomenon description.

[0043] (3) The large language model retrieves knowledge graph units based on structured and unambiguous fault descriptions;

[0044] (4) If the large language model can retrieve relevant knowledge in the fault description, then proceed to step five; otherwise, the large language model returns to step one and waits for the fault handling request again.

[0045] (5) The large language model performs association analysis and reasoning based on the retrieved relevant knowledge, and uses RAG and KAG technology to generate a fault handling plan containing specific operation steps, wherein each operation step corresponds to an RPA plugin;

[0046] (6) The large language model converts the fault handling solution generated in the previous step into a standard process file in JSON format that can be executed by the RPA platform;

[0047] (7) The large language model calls the tool (rpa_flow_deploy) in the MCP module to save the generated RPA process file to the RPA platform;

[0048] (8) The large language model calls the RPA process execution tool (rpa_flow_execute) in the MCP module to put the specified process into the execution queue of the execution engine and obtain the task ID (jobId).

[0049] (9) The large language model calls the query execution status tool (rpa_flow_query) in the MCP module in a polling manner to query the execution status of the specified RPA process execution task until the task is completed and the task execution result is obtained;

[0050] (10) Based on the Prompt prompt word constraint, the large language model summarizes the RPA process task execution results obtained in the previous step into a fault handling execution report and saves it as a Word document.

[0051] Example 3

[0052] This embodiment illustrates the method for constructing a vectorized indexed knowledge base, including the following steps:

[0053] (1) Use technologies such as OCR and PDF parsing to convert the original document into plain text;

[0054] (2) Use natural language processing technology to segment, denoise, and clean paragraphs;

[0055] (3) Use pre-trained language models (text2vec, BGE) to convert the processed text fragments into high-dimensional vectors to achieve text embedding and capture deep semantic information in the text;

[0056] (4) Store the generated vectors and their corresponding original text fragments into a dedicated vector database and create an index.

[0057] Example 4

[0058] This embodiment illustrates the method for constructing a knowledge graph knowledge base, including the following steps;

[0059] (1) Abstract entities, including at least physical equipment (such as substations, current transformers, circuit breakers, etc.), computer hardware (CPU, memory, disk, etc.), automation systems (SCADA, DMS, OMS, etc.), applications (scada_area, public_service, file_srv, etc.), faults, handling procedures, RPA plugins (such as logging into DMI, checking server time synchronization, manual confirmation, generating operation tickets, etc.);

[0060] (2) Define entity relationships, including at least "belongs to" (e.g., equipment and station), "connected to" (e.g., equipment and line), "collected from" (e.g., SCADA meter and equipment), "cause" (e.g., the application exits due to the host disk being full), "has a handling plan" (e.g., there are fault handling cases or operating procedures for a certain type of fault phenomenon), and "is automated as" (the steps in the fault handling case and the corresponding RPA plugin);

[0061] (3) Use ontology modeling tools to define the types and hierarchical structure of the above entities and relationships to form the schema of the knowledge graph;

[0062] (4) Extract the call chain between the power grid topology and equipment parameters, the software and hardware topology of the automation system and the application through ETL tools to form entities and connection relationships;

[0063] (5) Utilize the information extraction capability of the large language model to extract entities such as faulty equipment and fault type from historical fault records, and align and merge them with the equipment entities in the topology;

[0064] (6) Extract operation steps and safety measures from standardized work instructions and fault handling cases using LLM, and establish a "with handling plan" relationship between them and the corresponding fault type and equipment type;

[0065] (7) Import the plugins of the RPA platform (plugin name and ID, plugin function, input parameters, return results) as entities and establish a "automated implementation" relationship with the manual operation steps that it can replace in the knowledge graph.

[0066] (8) Store the merged knowledge in a graph database (Neo4j).

[0067] Example 5

[0068] This embodiment illustrates the implementation steps of the MCP module:

[0069] (1) The MCP module includes two core components: MCP Client and MCP Server;

[0070] (2) The MCP Client is integrated into the AI ​​agent and is responsible for establishing a connection with the MCP Server, discovering available tools, and acting as an agent for the large language model to initiate tool invocation requests;

[0071] (3) MCP Server is an independently deployed service process that serves as a dedicated proxy bridge between the Big Oracle model and the RPA platform, providing callable "tools".

[0072] Example 6

[0073] This embodiment illustrates how, upon startup, the MCP Server registers the RPA platform interface as an MCP standard tool for discovery and invocation by large language models through the following steps:

[0074] (1) The MCP Server obtains all callable RPA platform interfaces by reading the local configuration file;

[0075] (2) For each interface, generate the corresponding MCP tool metadata, including: tool name (name): a unique identifier, such as rpa_flow_deploy, rpa_flow_execute, rpa_flow_query; tool description (description): a clear description of the tool's function, input parameters, and output parameters; input schema (inputSchema): a strictly defined JSON schema of the parameters required to call the tool.

[0076] Example 7

[0077] This embodiment illustrates the internal core modules of the MCP Server and the data interaction relationships between them, as shown in the attached diagram. Figure 1 As shown, the MCP Server includes the following internal modules:

[0078] (1) JSON-RPC communication interface: responsible for establishing a connection with the MCP Client, receiving JSON-RPC requests and returning responses;

[0079] (2) Tool Registration Manager: Responsible for providing the MCP Client with a list of available tools after the MCP Server starts up;

[0080] (3) Protocol converter: As the core module of MCP Server, it is responsible for parsing the received general MCP call requests and converting them into RPA platform-specific HTTP API call instructions;

[0081] (4) RPA platform API client: encapsulates the details of interaction with the specific RPA platform and is responsible for executing HTTP calls;

[0082] (5) Result Standardizer: Responsible for converting the raw, potentially heterogeneous result data returned by the RPA platform into a response format that conforms to the MCP protocol standard.

[0083] Example 8

[0084] This embodiment illustrates the timing data flow diagram of an AI agent calling an RPA platform interface (taking the execution of an RPA process interface as an example), as shown in the attached diagram. Figure 2 As shown, the process includes:

[0085] (1) Faults in the AI ​​agent's reception of user reports;

[0086] (2) The LLM in the AI ​​agent analyzes, reasons, and makes decisions based on the knowledge base, and generates instructions to call the rpa_flow_execute tool. The instructions include the tool name (rpa_flow_execute) and parameters (flowId, etc.).

[0087] (3) The MCP Client inside the AI ​​intelligent body encapsulates the LLM instructions into JSON-RPC requests and sends them to the MCPServer;

[0088] (4) The MCP Server receives the request, performs authentication and protocol conversion, and generates a command (HTTP POST) to call the RPA platform's RPA process execution interface.

[0089] (5) The MCP Server calls the execution flow interface of the RPA platform;

[0090] (6) When the RPA platform receives the request, it puts the process into the execution queue and returns the original call result, including information such as jobId; if the queue is empty, the process is executed directly.

[0091] (7) After receiving the original call result returned by the RPA platform, the MCP Server standardizes it and returns it to the MCPClient to inform that the RPA process execution request has been received;

[0092] (8) Based on the returned result information (jobId, etc.), the LLM generates a call instruction to call the rpa_flow_query tool. The call instruction includes the tool name (rpa_flow_query) and parameters (jobId, etc.). The MCP Client starts to call the tool in a loop. The MCP Client encapsulates the call instruction into a JSON-RPC request and sends it to the MCP Server.

[0093] (9) The MCP Server receives the request, performs authentication and protocol conversion, generates a command (HTTP POST) to call the RPA platform to query the RPA process execution result, and calls the RPA platform's query RPA process execution result interface;

[0094] (10) The RPA platform receives the request, queries and returns the process execution result;

[0095] (11) After receiving the original call result returned by the RPA platform, the MCP Server standardizes it and returns it to the MCP Client;

[0096] (12) If the LLM parsing returns a result, and the process is still in progress, the rpa_flow_query tool will continue to be called until the process is completed; if the process has been completed, the execution result of the process will be parsed and a fault handling report will be generated.

[0097] Example 9

[0098] This embodiment aims to illustrate the implementation of the main modules in the fault handling method of the power grid dispatch automation system based on AI agents. The AI ​​agent adopts a microservice architecture and mainly includes the following modules:

[0099] Large Language Model Module: Employs the pre-trained large language model Qwen2.5-72B-Instruct based on the Transformer architecture, deployed on an NVIDIA GPU server cluster, and provides services through API;

[0100] Multimodal knowledge base module: The vector database uses Chroma to store vectorized representations of documents related to power industry expertise and automated operation and maintenance expertise; the graph database uses Neo4j to store knowledge graphs of knowledge such as the hardware and software topology of automated systems, fault handling cases, and RPA plugin information.

[0101] MCP module: Developed in Python, deployed as an independent HTTP service, providing an interface for RPA tools to call;

[0102] RPA module: Provides process designer, executor, process repository, plugin repository and interaction interface, wherein the interaction interface includes at least process file saving interface, process execution interface and process execution result query interface.

[0103] The knowledge base module includes a vectorized indexing unit, which is constructed in the following manner:

[0104] (1) Data acquisition and preprocessing: The enterprise’s internal document management system acquires standard documents such as “Electrical Engineering Terminology” and “Power Grid Dispatch Standard Terminology”, and uses OCR, PDF parsing and other technologies to convert the original documents into plain text, and performs segmentation, noise reduction and standardization processing.

[0105] (2) Text embedding in index: The pre-trained language model (text2vec, BGE-large-en-v1.5) is used to convert the processed text fragments into high-dimensional vectors (1024 dimensions) to capture deep semantic information in the text, and Chroma is used to build an index to support similarity retrieval.

[0106] The knowledge base module also includes a knowledge graph unit, which is constructed in the following manner:

[0107] (1) Entity and Relationship Definition: The ontology is defined using the Protege tool. The core entity types include: Device, System, Service, Fault, Procedure, and RPAPlugin. The relationship types include: belongTo, connectedFrom, collectedFrom, cause, hasSolution, and automatedBy.

[0108] (2) Data extraction and fusion: Use a large language model to extract information from historical fault reports, identify faulty equipment, fault type, handling steps, etc., and align them to existing entities in the knowledge graph through entity linking technology;

[0109] (3) Graph database storage: Use Cypher statements to import entities and relations into the Neo4j graph database and create indexes to support efficient queries.

[0110] The MCP module includes an MCP Client and an MCP Server. The MCP Client is responsible for communicating with the MCP Server via the JSON-RPC 2.0 protocol. Its core functions include establishing connections, discovering available tools, and proxying tool invocation requests from the large language model. The specific implementation steps are as follows:

[0111] (1) Connection initialization: The MCP Client establishes a connection with the MCP Server through Stdio (standard input / output); after completing the initial handshake, the MCP Client sends an initialize request to negotiate the protocol version;

[0112] (2) Tool discovery: The MCP Client calls the MCP Server tool discovery method tools / list via the JSON-RPC protocol to obtain a list of all available tools registered by the MCP Server; it parses the tool metadata (tool name, tool description, tool input mode) for use by the large language model for decision-making;

[0113] (3) Tool call: When the large language model decides to call a specific tool after analysis, the MCP Client constructs a JSON-RPC request; the request body contains the method name tools / call and the tool call parameters; after sending the request, it waits for the MCPServer to respond and processes the synchronization results.

[0114] The main implementation code for the MCP Client is as follows:

[0115] import json

[0116] import asyncio

[0117] from mcp import ClientSession, StdioServerParameters

[0118] from mcp.client.stdio import stdio_client

[0119] class MCPClient:

[0120] def __init__(self, server_script_path: str):

[0121] self.server_params = StdioServerParameters(

[0122] command="python",

[0123] args=[server_script_path] )

[0125] self.session = None

[0126] async def connect(self):

[0127] """1. Connect initialization"""

[0128] self.session = await stdio_client(self.server_params)

[0129] await self.session.initialize() # Send

[0130] async def list_tools(self) -> list:

[0131] """2. Tool discovery"""

[0132] response = await self.session.list_tools()

[0133] return response.tools

[0134] async def call_tool(self, tool_name: str, arguments: dict) ->dict:

[0135] """3. Call the specified tool"""

[0136] response = await self.session.call_tool(tool_name, arguments)

[0137] return {

[0138] "content": response.content,

[0139] "is_error": response.isError

[0140] }

[0141] # Usage Example

[0142] async def main():

[0143] client = MCPClient("mcp_server.py")

[0144] await client.connect()

[0145] # Discover available tools

[0146] tools = await client.list_tools()

[0147] print("Available tools:", [tool.name for tool in tools])

[0148] # Call the RPA process deployment tool

[0149] result = await client.call_tool(

[0150] "rpa_flow_deploy",

[0151] {

[0152] "flow_json": {

[0153] ... # RPA process document

[0154] }

[0155] } )

[0157] print("Result of the call:", result)

[0158] if __name__ == "__main__":

[0159] asyncio.run(main())

[0160] The MCP Server runs as an independent service process. Its core component is the protocol converter, which is responsible for converting the tool call requests of the MCPClient into HTTP API calls to the RPA platform. The implementation steps are as follows:

[0161] (1) Tool Registration: Develop a tool registration manager, mainly by writing tool discovery functions for MCP Clients to call and obtain tool information. The tool discovery function returns three tool information items: rpa_flow_deploy (saves RPA process files), rpa_flow_execute (executes a specified RPA process), and rpa_flow_query (queries the execution status and results of RPA process execution tasks). Each tool information item includes three attributes: name (tool name), description (tool description), and inputSchemas (input schema). The main implementation code is as follows:

[0162] import Tool from mcp.types

[0163] from mcp.server import Server

[0164] # MCP Server Main Program

[0165] server = Server("agent-mcp-server")

[0166] @server.list_tools()

[0167] async def handle_list_tools():

[0168] Register available MCP tools.

[0169] return [

[0170] Tool

[0171] name="rpa_flow_deploy",

[0172] description="Save RPA process files",

[0173] inputSchema={

[0174] "type": "object",

[0175] "properties": {

[0176] "flow_json": {

[0177] "type": "object",

[0178] "description": "A JSON object defining a process that conforms to the RPA platform specifications"

[0179] }

[0180] },

[0181] "required": ["flow_json"]

[0182] }

[0183] ),

[0184] Tool

[0185] name="rpa_flow_execute",

[0186] description="Execute the specified RPA process",

[0187] inputSchema={

[0188] "type": "object",

[0189] "properties": {

[0190] "flow_id": {"type": "string", "description": "process ID"},

[0191] "parameters": {"type": "object", "description": "runtime parameters"}

[0192] },

[0193] "required": ["flow_id"]

[0194] }

[0195] ),

[0196] Tool

[0197] name="rpa_flow_query",

[0198] description="Query the execution status and results of RPA process tasks",

[0199] inputSchema={

[0200] "type": "object",

[0201] "properties": {

[0202] "job_id": {"type": "string", "description": "task ID"}

[0203] },

[0204] "required": ["job_id"]

[0205] } ) ]

[0208] (2) Protocol Conversion: To implement the three registered tools mentioned above, the request from the MCP Client to call the tool is converted into an HTTP call from the MCP Server to the RPA platform interface. The main implementation code is as follows:

[0209] import httpx

[0210] from mcp.types import TextContent

[0211] class RPAProtocolConverter:

[0212] Protocol Converter: Converting MCP Tool Calls to RPA Platform HTTP API Calls

[0213] def __init__(self, rpa_base_url: str, api_key: str):

[0214] self.rpa_base_url = rpa_base_url

[0215] self.headers = {

[0216] "Authorization": f"Bearer {api_key}",

[0217] "Content-Type": "application / json"

[0218] }

[0219] async def deploy_flow(self, flow_json: dict) -> dict:

[0220] """The request to save the workflow file is converted and calls the RPA platform's workflow saving interface.""

[0221] async with httpx.AsyncClient() as client:

[0222] response = await client.post(

[0223] f"{self.rpa_base_url} / api / v1 / flows / save",

[0224] json=flow_json,

[0225] headers = self.headers )

[0227] return self._handle_response(response)

[0228] async def execute_flow(self, flow_id: str, parameters: dict) ->dict:

[0229] """Transform the execution flow request and call the RPA platform's execution flow interface.""

[0230] async with httpx.AsyncClient() as client:

[0231] response = await client.post(

[0232] f"{self.rpa_base_url} / api / v1 / flows / {flow_id} / execute",

[0233] json={"parameters": parameters},

[0234] headers = self.headers )

[0236] return self._handle_response(response)

[0237] async def query_execution(self, execution_id: str) -> dict:

[0238] """Transform the query execution status request, and call the RPA platform to query the execution status and results of the task in the process execution.""

[0239] async with httpx.AsyncClient() as client:

[0240] response = await client.get(

[0241] f"{self.rpa_base_url} / api / v1 / jobs / {job_id}",

[0242] headers = self.headers )

[0244] return self._handle_response(response)

[0245] def _handle_response(self, response: httpx.Response) -> dict:

[0246] "Unified handling of HTTP responses"

[0247] if response.status_code == 200:

[0248] return response.json()

[0249] else:

[0250] Raise an exception(f"RPA platform API call failed: {response.status_code} - {response.text}")

[0251] converter = RPAProtocolConverter(

[0252] rpa_base_url="https: / / rpa-platform.example.com",

[0253] api_key="api-key" )

[0255] @server.call_tool()

[0256] async def handle_call_tool(name: str, arguments: dict) -> list[TextContent]:

[0257] """Process tool call requests - perform protocol conversion, and call the RPA platform interface""

[0258] try:

[0259] if name == "rpa_flow_deploy":

[0260] # Protocol Conversion: MCP Call → RPA Platform HTTP API

[0261] result = await converter.deploy_flow(arguments["flow_json"])

[0262] return [TextContent(type="text", text=f"RPA process saved successfully:{result['flow_id']}")]

[0263] elif name == "rpa_flow_execute":

[0264] parameters = arguments.get("parameters", {})

[0265] result = await converter.execute_flow(arguments["flow_id"], parameters)

[0266] return [TextContent(type="text", text=f"The process has been queued for execution: {result['job_id']}")]

[0267] elif name == "rpa_flow_query":

[0268] result = await converter.query_execution(arguments["job_id"])

[0269] status = result["status"]

[0270] output = result.get("output", "")

[0271] return [TextContent(type="text", text=f"Process task execution status:{status}\nExecution result: {output}")]

[0272] else:

[0273] raise Exception(f"Unknown tool: {name}")

[0274] Example 10

[0275] This embodiment aims to illustrate the overall implementation method of the fault handling method for a power grid dispatch automation system based on AI agents. This method uses the large language model module, multimodal knowledge base module, and MCP module described in Embodiment 1, and includes the following implementation steps:

[0276] The first step is for the AI ​​agent to receive a fault handling request described in natural language by the user. Example:

[0277] Host18 experienced an application C offline failure on September 20, 2025. The failure level is critical. Please take action.

[0278] The second step involves the large language model querying vectorized index units to obtain relevant professional knowledge and fault knowledge. This rewrites the original natural language description of the fault request into structured, unambiguous fault information, including fault type, fault entity, fault time, fault level, and fault phenomenon description. Example:

[0279] Fault Type: Application Anomaly Fault Entity: Application C Fault Time: 2025-09-20 Fault Level: Medium Fault Description: Host 18 experienced an offline failure for Application C.

[0280] The third step involves the large language model retrieving knowledge graph units based on structured and unambiguous fault information.

[0281] Fourth, if the large language model can retrieve relevant knowledge from the fault information, then proceed to the fifth step; otherwise, the large language model returns to the first step and waits for the fault handling request again.

[0282] The fifth step involves the large language model performing association analysis and reasoning based on the retrieved relevant knowledge. Using RAG (Retrieval Augmentation) and KAG (Knowledge Graph Augmentation) technologies, it generates a fault handling plan containing specific operational steps. Each operational step details the RPA plugin used, including the plugin name, input parameters, and return results. Example:

[0283] Troubleshooting plan:

[0284] Step 1: Initiate the troubleshooting process. The RPA plugin used in this step is "Start". Plugin details are as follows:

[0285] Plugin Name Input parameters Return results start none none

[0286] Step 2: Check the network connectivity status of host18. This step uses the "Check Network Status" RPA plugin. Plugin details are as follows:

[0287] Plugin Name Input parameters Return results checkNetwork hostName:host18 checkNetworkOutput 1 - Network connected 2 - Network not connected

[0288] Step 3: Conditional check. If the network connection is normal, proceed to Step 4; otherwise, output the processing result and proceed to Step 11. This step uses the "Conditional Branching" RPA plugin. Plugin details are as follows:

[0289] Plugin Name Input parameters Return results conditionalBranch Condition:@{checkNetWorkOutput}==1 True - Network connected False - Network not connected

[0290] Step 4: Check application status. This step uses the "Check Application Status" RPA plugin. Plugin details are as follows:

[0291] Plugin Name Input parameters Return results checkSceneStatus sceneName: Application A, hostName: host18 checkSceneStatusOutput 1 - Online 2 - Offline

[0292] Step 5: Conditional check. If the application status is "Exit," proceed to Step 6; otherwise, proceed to Step 7. This step uses the "Conditional Branching" RPA plugin. Plugin details are as follows:

[0293] Plugin Name Input parameters Return results conditionalBranch condition: @{checkSceneStatusOutput}==1 True - Online False - Offline

[0294] Step 6: Start the application. The RPA plugin used in this step is "Execute Command". Plugin details are as follows:

[0295] Plugin Name Input parameters Return results executeCommand Command: The command to launch the application. executeCommandOutput 1 - Execution successful 2 - Execution failed

[0296] Step 7: Check Process Status. This step uses the "Check Process Status" RPA plugin. Plugin details are as follows:

[0297] Plugin Name Input parameters Return results checkProcStatus procName: Process Name checkProcStatusOutput 1 - Process is running 2 - Process is not running

[0298] Step 8: Conditional check. If the process is not running, proceed to step 9; otherwise, proceed to step 10. This step uses the "Conditional Check" RPA plugin. Plugin details are as follows:

[0299] Plugin Name Input parameters Return results conditionalBranch condition:@{checkProcStatusOutput}==1 True - The process is running. False - The process is not running.

[0300] Step 9: Start the process. Troubleshooting complete. Proceed to Step 11. The RPA plugin used in this step is "Execute Command". Plugin details are as follows:

[0301] Plugin Name Input parameters Return results executeCommand command: The command to start the process executeCommandOutput 1 - Execution successful 2 - Execution failed

[0302] Step 10: Manual intervention. Troubleshooting complete. Proceed to Step 11. This step uses the "Manual Intervention" RPA plugin. Plugin details are as follows:

[0303] Plugin Name Input parameters Return results manual Handle none none

[0304] Step 11: Process complete.

[0305] Step 6: The large language model converts the fault handling solution generated in the previous step into a standard JSON format process file executable by the RPA platform. The process file constructs the plugin execution sequence according to the steps in the fault handling solution using a DAG (Directed Acyclic Graph). Example (only one plugin and its execution sequence are shown):

[0306] {

[0307] "flowId": "3bdf846473824b36b769166f23ebcfb0",

[0308] "flowName": "SCADA Application Anomaly Handling",

[0309] "flowInfo": {

[0310] "procedures": [

[0311] ...,

[0312] {

[0313] "id": "1a843bde-3ddc-4f90-a4f1-dd9c1f5dead4",

[0314] "type": "base-node",

[0315] "typeL": "executeCommand",

[0316] "label": "Check application status",

[0317] "plugin": {

[0318] "pluginId": "49759c9b85b643e6b3ad535b14e8cb8f",

[0319] "pluginBaseInfo": {

[0320] "pluginName": "checkSceneStatus",

[0321] "pluginDescribe": "Check application status",

[0322] "groupName": "newgenop"

[0323] },

[0324] "input": {

[0325] "sceneName": "Application A"

[0326] },

[0327] "output": {

[0328] "result": [

[0329] {

[0330] "code": "1",

[0331] "message": "online"

[0332] },

[0333] {

[0334] "code": "2",

[0335] Message: "Offline"

[0336] }

[0337] ],

[0338] "outputVariable": "checkSceneStatusOutput"

[0339] }

[0340] }

[0341] }, ...

[0343] ],

[0344] "edges": [

[0345] ...,

[0346] {

[0347] "id": "edge-de81c499-6bee-44be-9c59-ead066ae03a3",

[0348] "type": "polyline",

[0349] "label": "True",

[0350] "source": "0b083d9f-998e-4dfa-8310-dd78ffb3e0fb",

[0351] "target": "aa03973d-34b5-4bf4-9bc1-ee7a6f8dfd86",

[0352] }, ... ]

[0355] }

[0356] }

[0357] Among them, procedures is a list of plugins, which stores information about all plugins in the fault handling plan; edges is a list of plugin execution sequences, where each plugin identifies its preceding and following plugins through source and target.

[0358] Step 7: The large language model calls the RPA process file saving tool (rpa_flow_deploy) in the MCP module to save the generated RPA process file to the RPA platform;

[0359] Step 8: The large language model calls the RPA process execution tool (rpa_flow_execute) in the MCP service to queue the specified process into the execution engine's execution queue and obtain the task ID (jobId).

[0360] The ninth step involves the Big Prophet model using a polling method to call the execution status query tool (rpa_flow_query) in the MCP service to query the execution status of the specified task ID until the task is completed and the task execution result is obtained.

[0361] Step 10: Based on the Prompt constraints, the large language model summarizes the RPA process task execution results obtained in the previous step into a fault handling execution report and saves it as a Word document.

Claims

1. A power grid dispatching fault handling system based on AI intelligent agents, characterized in that, include: A multimodal knowledge base includes a vectorized indexing unit and a knowledge graph unit; the vectorized indexing unit represents professional knowledge in a vectorized manner; the knowledge graph unit stores data in a graph structure. Large Language Model: Receives fault handling requests in natural language, obtains relevant professional knowledge and fault knowledge by querying vectorized index units, rewrites the original fault handling request into a fault description, and performs association reasoning based on the fault description by retrieving knowledge graph units, and generates fault handling solutions using RAG and KAG technologies; MCP Service: Provides the large language model with a way to call external tools. It registers the interfaces in the RPA platform with the MCP service as tools, and the large language model interacts with the RPA platform through the tools provided by the MCP. RPA Platform: Provides an RPA process plugin library and RPA process executor, and is responsible for plugin management and process management. It interacts with the large language model through the MCP service.

2. The power grid dispatching fault handling system based on AI intelligent agents according to claim 1, characterized in that, The vectorized index unit stores standard and specification documents in the vertical field of power automation, including "Electrical Engineering Terminology", "Power Grid Dispatch Standard Terminology", "Power Safety Work Procedures", and "Power Automation Communication Networks and Systems", which assist the large language model in completing natural language understanding and standardized rewriting.

3. The power grid dispatching fault handling system based on AI intelligent agents according to claim 1, characterized in that, The knowledge graph unit stores the hardware topology, software architecture, operation and maintenance manuals, fault handling plans, RPA plug-in information, and RPA standard process documents of the power grid automation system in a graph structure. It integrates the originally scattered knowledge with different structures into a unified graph model for representation, and assists the large language model in generating RPA fault handling plans and RPA process documents.

4. The power grid dispatching fault handling system based on AI intelligent agents according to claim 3, characterized in that, The RPA plugin information includes the plugin name, ID, plugin function, plugin input parameters, and plugin return results.

5. The power grid dispatching fault handling system based on AI intelligent agents according to claim 1, characterized in that, The MCP service includes tools for saving RPA process files, tools for executing RPA processes, and tools for querying the execution status of RPA processes.

6. The power grid dispatching fault handling system based on AI intelligent agents according to claim 5, characterized in that, The input to the tool for saving RPA process files is a process file conforming to the RPA platform specifications. The execution logic is to call the RPA platform's save process file interface to save the process file to the RPA platform's process repository. The input to the tool for executing RPA processes is the process ID and runtime parameters. The execution logic is to call the RPA platform's execute RPA process interface to queue the specified process in the execution engine's execution queue and obtain the task ID. The input to the tool for querying the execution status of RPA processes is the task ID, and the tool queries the execution status of RPA processes, including the execution result.

7. The power grid dispatching fault handling system based on AI intelligent agents according to claim 6, characterized in that, The RPA process file defines the plug-in sequence for automated operations, plug-in parameter configurations, and logical judgments between steps.

8. The power grid dispatching fault handling system based on AI intelligent agents according to claim 6, characterized in that, The large language model calls the tool for saving RPA process files to save the generated RPA process files to the RPA platform; the large language model calls the tool for executing RPA processes to queue the specified process into the execution engine's execution queue and obtain the task ID; the large language model calls the tool for querying the execution status of the specified RPA process execution task through polling to query the execution status of the specified RPA process execution task until the task is completed and the task execution result is obtained.

9. The power grid dispatching fault handling system based on AI intelligent agents according to claim 1, characterized in that, The large language model, based on the Prompt prompt constraints, summarizes the RPA process task execution results obtained in the previous step into a fault handling execution report, and saves it as a Word document.

10. A method for handling power grid dispatching faults based on AI intelligent agents, characterized in that, include: (1) Receive fault handling requests described in natural language; (2) Use the large language model to query the vectorized index unit to obtain relevant professional knowledge and fault knowledge, and rewrite the original fault handling request into a structured and unambiguous fault description, including fault type, fault entity, fault time, fault level and fault phenomenon description. (3) The large language model retrieves knowledge graph units based on structured and unambiguous fault descriptions; (4) If the large language model can retrieve relevant knowledge in the fault description, then proceed to step (5); otherwise, return to step (1) and wait for the fault handling request again. (5) The large language model performs association analysis and reasoning based on the retrieved relevant knowledge, and generates a fault handling plan including specific operation steps through RAG and KAG technology. Each operation step corresponds to an RPA plugin. (6) The large language model converts the fault handling solution generated in the previous step into a standard process file in JSON format that can be executed by the RPA platform; (7) The large language model calls the tool in MCP to save the RPA process file and saves the generated RPA process file to the RPA platform; (8) The large language model calls the execution RPA process tool in MCP to queue the specified process into the execution engine's execution queue and obtain the task ID; (9) The Big Prophet model calls the query execution status tool in the MCP service in a polling manner to query the execution status of the specified task ID until the task is completed and obtains the task execution result; (10) Based on the Prompt prompt word constraint, the large language model summarizes the RPA process task execution results obtained in the previous step into a fault handling execution report and saves it as a Word document.

Images