An agent engineering framework system for power industry scenarios

Abstract

The application discloses an intelligent agent engineering framework system for a power industry scene and relates to the technical field of intelligent operation and maintenance.The system comprises a power scene resource access and semantic modeling module, which accesses power business resources, encapsulates the power business resources and corresponding resource descriptions as component resources, a component library module, which encapsulates the component resources as standardized components containing component contracts and generates a component list, an intelligent agent design and version management module, which selects the standardized components for binding, generates a versioned running snapshot and a corresponding version number according to the bound standardized components, a runtime planning and controllable execution module, which receives a task request containing a target device identifier, calls the corresponding versioned running snapshot, and checks before executing any node, and a framework unified management module, which, when the action type belongs to a preset high-risk action and the risk level of the action type reaches a preset threshold, locates a current execution node, suspends execution, and outputs an artificial confirmation request.

Description

Technical Field

[0001] This invention relates to an intelligent agent engineering framework system for power industry scenarios, belonging to the field of intelligent operation and maintenance technology. Background Technology

[0002] With the advancement of digital and intelligent construction of power systems, a large amount of business data, knowledge documents, model services, workflows, and tool interfaces have been accumulated in scenarios such as dispatching and operation, secondary duty, intelligent substation inspection, energy storage operation and maintenance, ultra-high voltage equipment operation and maintenance, and power supply command. In recent years, large language models, intelligent agents, retrieval enhancement generation, workflow orchestration, and multimodal recognition capabilities have been gradually introduced into these scenarios for fault attribution, equipment status interpretation, operation report generation, decision support, and automatic tool invocation.

[0003] However, existing smart power applications are mostly built as single-point projects, with different projects employing different technical approaches in model invocation, knowledge access, tool encapsulation, access control, version release, session logging, and report output. Power production objects have strong domain constraints; the same tool invocation often requires simultaneous fulfillment of conditions such as plant / station, bay, voltage level, equipment type, primary topology, real-time operating status, dispatch jurisdiction, operation ticket or work ticket status, five-prevention interlocking status, and user permissions. Existing intelligent capabilities are typically embedded in project code, making it difficult to retrieve, authorize, reuse, and version-manage dedicated intelligent agents, general intelligent agents, workflows, tools, Model Communication Platform (MCP) services, Skills, knowledge bases, and memory capabilities across scenarios. More importantly, online runtime often directly reads the current configuration or component status, lacking component contracts, electrical safety constraints, version constraints, and permission boundaries fixed at the time of release. This leads to drift in tool versions, knowledge scope, model strategies, or security rules invoked by the same intelligent agent at different times, making the results difficult to reproduce.

[0004] In the power industry scenario, tasks such as dispatch alarm confirmation, remote operation suggestions, parameter modification, work order closure, and operation reports require controllable, recoverable, and auditable execution processes. Tool invocation in power production operations has high security requirements; mis-triggered operations such as remote control, parameter modification, alarm confirmation, and work order closure can affect equipment status, grid operation modes, or production responsibility loops, and cannot rely entirely on large-scale models for independent decision-making. Existing intelligent agent tool invocation typically focuses on semantic understanding and tool selection, lacking a pre-invocation verification mechanism linked to electrical safety rules, equipment operating status, operation permissions, operation ticket constraints, and risk classification. This easily leads to problems such as unauthorized invocation, parameter errors, scenario mismatch, uncontrollable risks, and difficulty in auditing the process. Therefore, an intelligent agent engineering framework for the power industry scenario is needed to form a technical closed loop encompassing intelligent agent deployment, component binding, runtime loading, pre-execution verification, electrical safety constraints, high-risk action control, and call chain auditing. Summary of the Invention

[0005] The purpose of this invention is to provide an intelligent agent engineering framework system for the power industry. By generating versioned runtime snapshots bound to component contracts to solidify the intelligent agent's runtime configuration, performing component contract verification and electrical safety constraint verification before execution nodes, and suspending execution and outputting a manual confirmation request when a high-risk action is triggered, the system achieves the technical effects of non-drifting intelligent agent runtime configuration, consistent component call versions, and controllable and auditable high-risk actions.

[0006] To achieve the above objectives, the present invention is implemented using the following technical solution.

[0007] This invention provides an intelligent agent engineering framework system for the power industry, comprising:

[0008] The power scenario resource access and semantic modeling module accesses power business resources and generates corresponding resource descriptions; it encapsulates each power business resource and its corresponding resource description into component resources.

[0009] The component library module encapsulates the component resources into standardized components containing component contracts, and generates a component list based on the standardized components; wherein, the component contract includes a component identifier, invocation constraints, and input / output contracts;

[0010] The agent design and version management module selects the standardized components for binding, and configures the component orchestration order, electrical safety constraints and governance strategies of the agent; based on the component contract, component list, component orchestration order, electrical safety constraints, governance strategies and the mapping relationship between standardized components and component identifiers of the bound standardized components, a versioned runtime snapshot and the corresponding version number are generated;

[0011] The runtime planning and controllable execution module receives a task request containing a target device identifier, calls the versioned runtime snapshot corresponding to the target device identifier, and verifies the called standardized components before executing any node. After the verification is passed, the node is executed, and the position identifier of the current execution node and the action type corresponding to the execution plan are output. The verification includes component availability verification, version consistency verification, input / output contract matching verification, call constraint verification, and electrical safety constraint verification.

[0012] When the action type belongs to a preset high-risk action and the risk level of the action type reaches a preset threshold, the unified governance module of the framework locates the current execution node and suspends execution; when the current execution node suspends execution, it outputs a manual confirmation request and records the report template and execution result;

[0013] The report processing module generates a power business report based on the report template and the execution results.

[0014] Furthermore, the power scenario resource access and semantic modeling module includes a business resource access unit, a metadata description unit, a power object semantic description unit, and a resource adaptation unit;

[0015] The business resource access unit is used to access the power business resources, which include data acquisition and monitoring control system SCADA, power management system EMS, distribution network energy management system DMS, power production management system PMS, dispatching and operation management system OMS, protection setting system, defect system, work order system, operation ticket system, equipment ledger, topology model, knowledge document, business interface, model service, workflow and external tools;

[0016] The metadata description unit and the power object semantic description unit generate corresponding resource descriptions based on the power business resources. Specifically:

[0017] The metadata description unit is used to generate corresponding resource names, resource types, input / output contracts, calling protocols, versions, statuses, and security levels for each of the power business resources.

[0018] The power object semantic description unit is used to configure power object identifier, substation, bay, voltage level, equipment type, topology location, operating status, protection area, dispatch jurisdiction, authority scope, operation ticket status, five-prevention interlock status, applicable scenarios and power business resource invocation rules for each power business resource.

[0019] The resource adaptation unit encapsulates power service resources of different protocols and forms, along with their corresponding resource descriptions, into component resources that can be managed by the component library module and invoked at runtime.

[0020] Furthermore, the component library module encapsulates the resource components output by the power scenario resource access and semantic modeling module. The specific encapsulation process includes:

[0021] The component library module generates a component contract for each component resource. When an agent binds to a data source, knowledge base, MCP service, Skills, or workflow component, it also records the component's visibility scope, calling parameters, version constraints, and security constraints, so that the runtime can only execute calls within the component scope defined by the component list recorded in the versioned runtime snapshot. The component contract includes component identifier, component type, calling protocol, input / output contract, version number, health status, permission scope, security level, calling constraints, and applicable plant, interval, voltage level, equipment type, equipment status, scheduling jurisdiction, and operation ticket constraints. The input / output contract includes an input parameter structure and an output result structure.

[0022] Furthermore, the agent design and version management module includes an agent store management unit and a designer unit, specifically:

[0023] The intelligent agent store management unit is used to manage dedicated intelligent agents and general intelligent agents; the dedicated intelligent agents include intelligent operation and maintenance, equipment management and control, scheduling assistance, fault analysis and operation support intelligent agents; the general intelligent agents include intelligent question answering intelligent agents, report generation intelligent agents, voice interaction intelligent agents and tool calling intelligent agents; the intelligent agent store management unit is also used to record the template source, version number, applicable scenarios, input and output definitions and the list of bindable components for each intelligent agent;

[0024] The designer unit is used to provide an interface for selecting and binding the standardized components, configuring the orchestration order between components, configuring electrical safety constraints, and configuring governance strategies, and generates the versioned runtime snapshot in response to the release operation.

[0025] Furthermore, the runtime planning and controllable execution module includes an environment perception unit, an intelligent decision-making unit, a task execution unit, and a collaborative scheduling unit;

[0026] The environmental sensing unit is used to receive user requests, power alarm events, real-time measurement changes, equipment status changes, topology changes, image input or voice input, and generate a task context that includes user identity, organizational scope, target equipment, plant, interval, voltage level, equipment operating status, dispatch jurisdiction, operation ticket status and session identifier.

[0027] The intelligent decision-making unit is used to generate a node-based execution plan based on the task context, the standardized component set defined by the versioned runtime snapshot, governance strategies, and electrical safety constraints.

[0028] The task execution unit is used to execute each node in the nodeized execution plan in sequence and save the execution status of each node;

[0029] The collaborative scheduling unit is used to control the execution order of multiple agent tasks according to task priority, resource consumption, and concurrency quota.

[0030] Furthermore, the verification includes:

[0031] The component availability check is used to verify whether the target component called by the current node is deployed, online, and in a healthy state.

[0032] The version consistency check is used to verify whether the version of the target component called by the current node is consistent with the version number recorded in the versioned runtime snapshot;

[0033] The input-output contract matching verification is used to verify whether the input parameter structure called by the current node matches the input parameter structure defined in the component contract, and to verify whether the output result structure returned after the component execution matches the output result structure defined in the component contract.

[0034] The call constraint verification is used to verify whether the current user or the current intelligent agent has the permission to call the target component, whether the data or device involved in the target component is within the operator's jurisdiction, and whether the current call exceeds the preset call quota.

[0035] The electrical safety constraint verification includes:

[0036] Device object matching verification is used to verify whether the target device called by the current node belongs to the plant and interval range defined by the task context;

[0037] Voltage level matching verification is used to verify whether the voltage level of the target device matches the applicable voltage level of the standardized component;

[0038] The device operation status verification is used to verify whether the current operation status of the target device meets the preconditions of the current node action type;

[0039] Operation ticket status verification is used to verify whether the operation ticket or work ticket of the target device is in a valid and permitted operation state.

[0040] The five-prevention interlock status verification is used to verify whether the five-prevention interlock of the target device has been released;

[0041] The scheduling and jurisdiction permission verification is used to verify whether the current user or the current intelligent agent has scheduling and jurisdiction permission for the target device.

[0042] The parameter threshold verification is used to verify whether the parameter value to be modified by the current node is within the upper and lower limits of the safe operating parameters of the target device;

[0043] Action risk grading verification is used to determine the risk level based on the action type and the equipment level of the target device, and to determine whether the risk level reaches a preset threshold.

[0044] Furthermore, the runtime planning and controllable execution module also includes an intelligent agent tool invocation unit with electrical safety constraints;

[0045] The intelligent agent tool invocation unit is configured as follows:

[0046] Before the task execution unit executes remote control, parameter modification, alarm confirmation, work order closure, or tool call nodes that affect the power grid operation status, it parses the target device, action type, action parameters, and target status in the tool call request;

[0047] Based on the target equipment, the current status, topology location, scheduling jurisdiction, permitted operation status, interlocking status, and upper and lower limit of parameters are obtained from the equipment ledger, primary topology model, real-time operation data, protection setting system, operation ticket system, work ticket system, and five-prevention interlocking system, and an electrical safety context is generated.

[0048] The tool call request is matched and verified with the electrical safety context as an electrical safety constraint. The electrical safety constraint verification includes equipment object existence verification, equipment status matching verification, operation ticket effective status verification, five-prevention interlock release status verification, parameter threshold verification, and risk level verification.

[0049] If any of the matching checks fails, a decision to refuse execution or suspend execution is generated and a manual confirmation request is output; if all checks pass, the release tool is invoked; after the manual confirmation request is fed back, the runtime planning and controllable execution module resumes, terminates or reconstructs the subsequent execution plan according to the task request and feedback results.

[0050] Furthermore, the unified governance module of the framework is also used for fault tolerance and automatic recovery;

[0051] When the runtime planning and controllable execution module encounters a model call exception, tool call exception, data source interruption, or task execution timeout while executing any node, the framework unified governance module executes a recovery strategy based on the exception type and the power service level of the current node. The recovery strategy includes automatic retry, switching to a backup model, switching to a backup tool, recovering the failed task, or transferring to manual confirmation.

[0052] The automatic retry means re-execute the current node according to the preset number of retries and backoff interval;

[0053] The switch to the backup model refers to switching to the backup model service recorded in the versioned runtime snapshot and continuing to execute;

[0054] The switch to the backup tool means switching to the backup tool service recorded in the versioned runtime snapshot and continuing to execute;

[0055] The recovery of failed tasks involves saving the working memory of the current task and the list of completed nodes, and continuing execution from the next unexecuted node in the list of completed nodes after an abnormal recovery.

[0056] The manual confirmation step is defined as follows: when the anomaly type cannot be automatically recovered or the power service level reaches a preset threshold, the current task is suspended and a manual intervention request is output. Execution resumes after manual intervention is completed.

[0057] Furthermore, the system also includes a memory management module;

[0058] The memory management module is used to manage short-term memory, long-term memory, and working memory;

[0059] The short-term memory is used to store multi-turn interaction messages in the current session, and is truncated or compressed when the context length exceeds a preset threshold.

[0060] The long-term memory is used to extract cross-session experiential information from historical sessions, including typical device defect patterns, user operation preferences, and common fault handling experience, and is loaded into the task context when a new task is started.

[0061] The working memory is used to store the intermediate execution status, candidate tool set, and list of completed nodes of each node during the execution of long-cycle tasks;

[0062] When the long-cycle task resumes execution after being suspended due to manual confirmation or abnormal interruption, the runtime planning and controllable execution module restores the corresponding versioned runtime snapshot and the working memory according to the task identifier, and continues execution from the next unexecuted node in the list of completed nodes.

[0063] Furthermore, the component library module also includes a resource access control list;

[0064] The resource access control table records the access permissions and resource scope of each subject to each component resource according to the component identifier;

[0065] When an agent calls any of the standardized components during runtime, the runtime planning and controllable execution module accesses the resource access control table according to the resource, verifies whether the agent has the right to call the standardized components and whether the resource scope is met. If any condition is not met, the execution of the current node is blocked and an unauthorized call log is recorded.

[0066] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0067] 1. In existing smart power applications, the business capabilities of different systems usually exist in their own independent interface forms. The data formats, calling protocols, and access methods of different systems are different, making it difficult for intelligent agents to identify and call power production objects across systems. In this embodiment, the power scenario resource access and semantic modeling module accesses various power business resources and encapsulates them into standardized components containing component contracts through the component library module. This enables intelligent agents to uniformly identify, select, and call power business capabilities from different sources at runtime, solving the technical problem of difficulty in cross-system calling caused by the fragmentation of power business resources.

[0068] 2. This invention, through the intelligent agent design and version management module, solidifies the component contracts, component lists, component arrangement order, electrical safety constraints, and governance strategies of the standardized components bound to the intelligent agent when the intelligent agent is released, generating a versioned runtime snapshot and the corresponding version number. This enables power intelligentization projects to not only read the current component status, but also to read the tool versions, knowledge scope, model strategies, or security rules called by the same intelligent agent at different times. This eliminates the problem of inconsistent running results caused by component version upgrades, configuration changes, or strategy adjustments, and makes the execution behavior of the intelligent agent reproducible.

[0069] 3. This invention uses a time-based planning and controllable execution module to perform multiple checks on the standardized components being called before executing any node, avoiding the weakness of a single check. This ensures that only calls that pass all checks are executed, thus preventing runtime failures caused by version drift, incorrect parameters, insufficient permissions, or security violations.

[0070] 4. This invention uses a unified governance module within a framework. When an action type is a preset high-risk action and the risk level reaches a preset threshold, the current execution node is located by its location identifier and execution is suspended. At the same time, a manual confirmation request is output. This avoids the model making completely free decisions and introduces manual confirmation to control key operations that affect the power grid's operating status, reducing the operational safety risks caused by model misjudgment or tool misuse. Attached Figure Description

[0071] Figure 1The diagram shown is a flowchart of an intelligent agent engineering framework system for the power industry scenario provided in this embodiment.

[0072] Figure 2 The figure shown is a schematic diagram of the architecture of an intelligent agent engineering framework system for the power industry scenario provided in this embodiment.

[0073] Figure 3 The diagram shown is a flowchart of the implementation of an intelligent agent engineering framework system for the power industry scenario provided in this embodiment.

[0074] Figure 4 The diagram shown is a versioned resource binding and execution trace data structure of an intelligent agent engineering framework system for the power industry scenario provided in this embodiment. Detailed Implementation

[0075] It should be noted that the technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present invention and the specific features in the embodiments are detailed descriptions of the technical solution of the present invention, rather than limitations on the technical solution of the present invention. In the absence of conflict, the embodiments of the present invention and the technical features in the embodiments can be combined with each other.

[0076] The term "and / or" simply describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0077] Example 1

[0078] See Figure 1 This embodiment proposes an intelligent agent engineering framework system for the power industry scenario. The system adopts a hierarchical structure consisting of a power scenario resource access and semantic modeling module, a component library module, an intelligent agent design and version management module, a runtime planning and controllable execution module, a unified framework governance module, and a report accumulation module.

[0079] In this embodiment, the intelligent agent refers to a software execution entity that, after binding model strategies, system instructions, input and output definitions, standardized components, memory strategies, and governance strategies, can generate an execution plan based on the power task context and call standardized components to complete the task.

[0080] See Figure 2 and Figure 3 The specific configurations of each module in the system are as follows:

[0081] 1. The power scenario resource access and semantic modeling module is configured to: access power business resources, generate corresponding resource descriptions based on each power business resource, and encapsulate each power business resource and its corresponding resource description into component resources.

[0082] As a specific implementation method, the power scenario resource access and semantic modeling module in this embodiment includes a business resource access unit, a metadata description unit, a power object semantic description unit, and a resource adaptation unit.

[0083] The business resource access unit is used to access power business resources, which include Supervisory Control and Data Acquisition (SCADA), Energy Management System (EMS), Distribution Management System (DMS), Power Production Management System (PMS), Operation Management System (OMS), protection setting system, defect system, work order system, operation ticket system, equipment ledger, topology model, knowledge document, business interface, model service, workflow, and external tools.

[0084] The system proposed in this embodiment can be connected to different power industry scenarios. However, different power scenarios require access to different power business resources. The access resources, intelligent agent execution content, and output results for five typical scenarios, namely secondary duty, dispatching zone three, intelligent inspection, energy storage operation and maintenance, and ultra-high voltage operation and maintenance, are shown in Table 1.

[0085] Table 1. Extended Examples of Power Scenarios

[0086] Second shift Protection settings, defect records, knowledge base Questions and Answers, Risk Warnings, and Handling Suggestions Duty Assistance Conclusion Dispatch Zone 3 Alarm database, topology, MCP service Alarm analysis, tool activation, and manual confirmation Scheduling Analysis Report Intelligent patrol Image results, equipment ledger, defect database Defect attribution, historical comparison, and report generation Inspection Defect Report Energy storage operation and maintenance BMS, PCS, Work Orders, Operational Indicators Anomaly detection, knowledge retrieval, and work order suggestions Daily Energy Storage Operation Report Ultra-high voltage operation and maintenance Equipment status, maintenance records, expert experience Status assessment, risk classification, and strategy recommendations Equipment Condition Assessment Report

[0087] The metadata description unit and the power object semantic description unit generate corresponding resource descriptions based on power business resources. Specifically:

[0088] The metadata description unit is used to generate corresponding resource names, resource types, input / output contracts, calling protocols, versions, statuses, and security levels for each power business resource.

[0089] The power object semantic description unit is used to configure power object identifiers, substations, bays, voltage levels, equipment types, topology locations, operating status, protection zones, dispatch jurisdiction, authority scope, operation ticket status, five-prevention interlocking status, applicable scenarios, and power business resource invocation rules for each power business resource.

[0090] The resource adaptation unit encapsulates power service resources of different protocols and forms, along with their corresponding resource descriptions, into component resources that can be managed by the component library module and invoked at runtime.

[0091] 2. The component library module is configured to: encapsulate component resources into standardized components containing component contracts, and generate a component list based on the standardized components.

[0092] In this embodiment, the component resources output by the power scenario resource access and semantic modeling module are encapsulated into standardized components through the component library module, and a component list is generated. A standardized component refers to a power business capability unit that can be invoked by the intelligent agent at runtime. The standardized component includes power business capability units that can be invoked by the intelligent agent at runtime. The component list is a collection list of all standardized components bound to the current intelligent agent when it is published.

[0093] The specific encapsulation process of the component library module is as follows:

[0094] For business capabilities from different sources, the resource adaptation unit encapsulates them into component resources that can be managed by the component library module and invoked at runtime. The component library module records workflows, tools, knowledge bases, data sources, MCP services, Skills, memory, and report templates as unified component resources and generates a component contract for each component. When an agent binds to a knowledge base component, it can configure the recall quantity, threshold, reference information, and rearrangement parameters; when binding to an MCP or Skills component, it can limit the specific tool, input parameters, version, and security audit status; when binding to a workflow component, it can limit the process version, input parameter mapping, and rollback strategy; when binding to a report template component, it saves the YAML template content as resource metadata. This ensures that the runtime can only execute calls within the component scope defined by the component list recorded in the versioned runtime snapshot. Among them, the MCP service refers to the service that exposes the tool list, tool schema, call endpoint, and call results to the agent according to the model context protocol or equivalent tool context protocol. It is responsible for the synchronous interaction of the power grid model and parameters between EMS, DMS, and SCADA. The runtime can complete tool discovery, parameter assembly, and result reception according to its protocol description.

[0095] Skills refer to the task execution capabilities encapsulated as reusable skill packages, which include skill name, version, instructions, associated resources, input and output constraints, and lifecycle status. The difference between Skills and ordinary tools is that, in addition to interface calls, Skills can also include task step descriptions, context usage rules, and resource organization methods.

[0096] A component contract is a data structure that describes the boundaries of a component call. It includes at least the component identifier, component type, call protocol, input / output contract, version number, health status, permission scope, security level, call constraints, and applicable plant, interval, voltage level, equipment type, equipment status, scheduling jurisdiction, and operation ticket constraints. The input / output contract includes the input parameter structure and the output result structure.

[0097] The component library module in this embodiment also includes a resource access control table. This table records the permission types and resource scopes of each entity for each component resource according to the component identifier. Permission types include at least one of read permission, call permission, modify permission, and authorized management permission. Resource scopes include plant / station scope, voltage level scope, equipment type scope, and scheduling jurisdiction scope. When an agent calls any standardized component during runtime, the runtime planning and controllable execution module verifies whether the current user or agent has the permission to call that component based on the resource access control table. If not, it blocks the execution of that node and records an unauthorized call log.

[0098] 3. The agent design and version management module is configured to: select standardized components for binding, and configure the orchestration order, electrical safety constraints and governance strategies of the agent components; and generate versioned runtime snapshots and corresponding version numbers based on the component contracts, component lists, orchestration order, electrical safety constraints, governance strategies and the mapping relationship between standardized components and component identifiers of the bound standardized components.

[0099] The agent design and version management module in this embodiment includes an agent store management unit and a designer unit, specifically:

[0100] The Intelligent Agent Store Management Unit is used to manage dedicated intelligent agents and general intelligent agents. Dedicated intelligent agents include intelligent operation and maintenance agents, equipment management agents, scheduling assistance agents, fault analysis agents, and operation support agents. General intelligent agents include intelligent question-answering agents, report generation agents, voice interaction agents, and tool calling agents. The Intelligent Agent Store Management Unit is also used to record the template source, version number, applicable scenarios, input and output definitions, and list of bindable components for each intelligent agent.

[0101] The designer unit provides an interface for selecting and binding standardized components, configuring the orchestration order between components, configuring electrical safety constraints, and configuring governance strategies, and generates versioned runtime snapshots in response to release operations.

[0102] As a specific implementation method, engineers can first select an existing dedicated or general-purpose intelligent agent as a template in the intelligent agent store management unit, or create a new power business intelligent agent in the designer unit, setting the application type, data source mode, model name, temperature, maximum number of tokens, system prompt words, prompt word variables, knowledge base, MCP tools, skills, data source, memory strategy, and fallback response. For process-oriented scenarios, sequence, branches, concurrency, rollback, and retry nodes can be defined through low-code workflows; for complex scenarios, high-code services in Java or Python can be registered and referenced as tools, components, or intelligent agents.

[0103] When an agent is in the draft stage, the system allows debugging based on its current binding state. Once debugging is stable, the release module generates a release version and uploads the released agent to the agent store management unit or publishes it as a callable tool in the component library. Simultaneously, the application version entity stores the configuration snapshot, runtime configuration, system commands, input keys, output keys, tool configuration, component orchestration snapshot, and change summary. The application component binding entity stores the data source, knowledge base, MCP service, Skills, memory, and report template bound to this version. When calling the application, the version number parameter is carried, and the system loads the specified release version or the most recently released version, avoiding real-time binding changes from impacting production execution.

[0104] Before executing any node, the task execution unit also checks whether the current user or the current agent has the right to call the target component according to the resource access control table; if the current user or the current agent does not have the right to call, the execution of the node is blocked and an unauthorized call log is recorded; if the right to call is available, the component availability check, version consistency check, input / output contract matching check, call constraint check, and electrical safety constraint check are performed.

[0105] Versioned runtime snapshots also save the component contracts, access control information, and governance policies of each bound component at the time of release. When called online, the runtime first reads the component list in the snapshot, and then pulls the corresponding component instance according to the component identifier and version number; when the component instance version, input / output structure, permission scope, or security status is inconsistent with the snapshot, the task execution unit blocks the execution of that node and writes the exception handling track.

[0106] Because versioned runtime snapshots record runtime configuration and resource binding details, when a certain version encounters an anomaly in a power fault analysis or inspection report scenario, the execution chain can be replayed according to the agent identifier, version number, task identifier, and step sequence number to pinpoint the specific problem in the underlying data source, MCP tool, knowledge base retrieval, model call, or report block.

[0107] The intelligent agent design and version management module also supports canary releases by specifying historical version numbers, deploying only the versioned runtime snapshots corresponding to the historical versions to a preset range of users or plants, and expanding the deployment scope after verification.

[0108] 4. The runtime planning and controllable execution module is configured to: receive a task request containing a target device identifier, call the versioned runtime snapshot corresponding to the target device identifier, and before executing any node, verify the called standardized components. After the verification is passed, the node is executed, and the position identifier of the current execution node and the action type corresponding to the execution plan are output. The verification includes component availability verification, version consistency verification, input / output contract matching verification, call constraint verification, and electrical safety constraint verification.

[0109] In this embodiment, the runtime planning and controllable execution module includes an environment perception unit, an intelligent decision-making unit, a task execution unit, a collaborative scheduling unit, and an intelligent agent tool invocation unit; the nodes in the execution plan can be knowledge retrieval nodes, workflow nodes, MCP tool nodes, Skills nodes, model inference nodes, memory read / write nodes, report generation nodes, or manual confirmation nodes.

[0110] The environmental sensing unit is used to receive user requests, power alarm events, real-time measurement changes, equipment status changes, topology changes, image input or voice input, and generate a task context that includes user identity, organizational scope, target equipment, plant, bay, voltage level, equipment operating status, dispatch jurisdiction, operation ticket status and session identifier.

[0111] The intelligent decision-making unit is used to generate node-based execution plans based on the task context, a standardized set of components defined by versioned runtime snapshots, governance strategies, and electrical safety constraints.

[0112] The task execution unit is used to execute each node in the nodeized execution plan in sequence and save the execution status of each node;

[0113] The collaborative scheduling unit is used to control the execution order of multiple agent tasks according to task priority, resource consumption, and concurrency quota;

[0114] The agent tool invocation unit is configured as follows:

[0115] The intelligent agent tool invocation unit is not directly triggered by the large model. Instead, it parses the target device, action type, action parameters and target status in the tool invocation request before the task execution unit executes the tool invocation node that performs remote control, parameter modification, alarm confirmation, work order closure or affects the power grid operation status.

[0116] Based on the target equipment, the current status, topology location, scheduling jurisdiction, permitted operation status, interlocking status, and parameter upper and lower limits of the equipment are obtained from the equipment ledger, primary topology model, real-time operation data, protection setting system, operation ticket system, work ticket system, and five-prevention interlocking system, an electrical safety context is generated.

[0117] The tool call request is matched and verified with the electrical safety context as an electrical safety constraint. If any item in the electrical safety constraint verification fails, a decision to refuse execution or suspend execution is generated and a manual confirmation request is output. If all verifications pass, the tool call is allowed. After the manual confirmation request is fed back, the runtime planning and controllable execution module resumes, terminates or reconstructs the subsequent execution plan according to the task request and feedback results.

[0118] As a specific implementation method, when the intelligent agent intends to call the "Confirm Alarm" tool based on the alarm analysis results, the system verifies the plant, bay, equipment, voltage level, and user scheduling permissions to which the alarm belongs; when it intends to call the "Modify Threshold Parameter" tool, the system verifies the parameter name, current value, target value, allowable upper and lower limits, equipment status, and approval documents; when it intends to call the "Work Order Closed-Loop" tool, the system verifies the defect level, handling evidence, confirmer role, and closed-loop responsibility scope. All release, suspension, rejection, and correction results are written to the tool call log and electrical safety verification record for subsequent audit playback.

[0119] Before executing any node, the task execution unit verifies the standardized components being called. In this embodiment, the verification includes component availability verification, version consistency verification, input / output contract matching verification, calling constraint verification, and electrical safety constraint verification.

[0120] Component availability verification is used to verify whether the target component called by the current node is deployed, online, and in a healthy state.

[0121] Version consistency check is used to verify whether the version of the target component called by the current node is consistent with the version number recorded in the versioned runtime snapshot;

[0122] Input / output contract matching verification is used to verify whether the input parameter structure called by the current node matches the input parameter structure defined in the component contract, and to verify whether the output result structure returned after the component execution matches the output result structure defined in the component contract;

[0123] Call constraint verification is used to verify whether the current user or the current intelligent agent has the permission to call the target component, whether the data or device involved in the target component is within the operator's jurisdiction, and whether the current call exceeds the preset call quota.

[0124] Electrical safety constraints refer to a set of power production safety rules used to restrict the invocation of standardized components by intelligent agents. Electrical safety constraint verification includes at least one or more of the following: equipment object matching, voltage level matching, substation interval range, primary topology relationship, equipment operating status, dispatching jurisdiction, operation ticket or work ticket status, five-prevention interlocking status, parameter threshold, and action risk classification. Specifically:

[0125] Device object matching verification is used to verify whether the target device called by the current node belongs to the plant and interval range limited by the task context;

[0126] Voltage level matching verification is used to verify whether the voltage level of the target device matches the applicable voltage level of the standardized components;

[0127] Equipment operation status verification is used to verify whether the current operation status of the target device meets the prerequisites for the current node action type;

[0128] Operation ticket status verification is used to verify whether the operation ticket or work ticket for the target equipment is in a valid and permitted operation state.

[0129] The five-prevention interlock status verification is used to verify whether the five-prevention interlock of the target equipment has been released;

[0130] The scheduling and jurisdiction permission verification is used to verify whether the current user or the current intelligent agent has scheduling and jurisdiction permission for the target device.

[0131] The parameter threshold verification is used to verify whether the parameter value to be modified in the current node is within the upper and lower limits of the safe operating parameters of the target device;

[0132] Action risk grading verification is used to determine the risk level based on the action type and the equipment level of the target device, and to determine whether the risk level reaches the preset threshold.

[0133] 5. The framework unified governance module is configured to: when the action type is a preset high-risk action and the risk level of the action type reaches a preset threshold, locate the current execution node with the location identifier and suspend execution; output a manual confirmation request when the current execution node is suspended; resume execution after manual intervention is completed, and record the report template and execution result.

[0134] As a specific implementation method, the high-risk actions preset in this embodiment are actions that may affect the power grid operation status, equipment control status, alarm closed-loop status, or production work order closed-loop status, including remote control, parameter modification, alarm confirmation, work order closed-loop, and protection setting adjustment suggestions to be executed.

[0135] Specifically, when performing verification in the runtime planning and controllable execution module, if any verification fails, execution will be rejected and the current node will be terminated.

[0136] When all checks pass during runtime planning and controllable execution, and the action type is a preset high-risk action with a risk level reaching a preset threshold, the current execution node is located by its location identifier and execution is suspended. While the current execution node is suspended, a manual confirmation request is output, and the task, execution steps, component call logs, electrical safety check results, and exception handling traces are recorded. After the manual confirmation request is received, the framework's unified governance module, based on the task request and feedback, issues instructions to the runtime planning and controllable execution module to resume, terminate, or reconstruct the subsequent execution plan. Execution resumes if the manual confirmation is approved, terminates if it is rejected, and regenerates new steps for reconstructing the subsequent execution plan according to the corrected content.

[0137] If all checks pass during runtime planning and controllable execution, and the action type does not belong to the preset high-risk actions, then the tool call is directly allowed.

[0138] Furthermore, when the runtime planning and controllable execution module encounters a model call exception, tool call exception, data source interruption, or task execution timeout while executing any node, the framework's unified governance module executes a recovery strategy based on the exception type and the current node's power service level. The recovery strategies include automatic retry, switching to a backup model, switching to a backup tool, recovering failed tasks, or requesting manual confirmation.

[0139] Automatic retry means re-execute the current node according to the preset number of retries and backoff interval;

[0140] Switching to the standby model means switching to the standby model recorded in the versioned runtime snapshot and continuing service execution;

[0141] Switch the backup tool to the backup tool service recorded in the versioned runtime snapshot and continue execution;

[0142] To recover a failed task, the working memory of the current task and the list of completed nodes are saved, and execution continues from the next unexecuted node in the list of completed nodes after an abnormal recovery.

[0143] When the abnormal type cannot be automatically recovered or the power service level reaches a preset threshold, the current task is suspended and a manual intervention request is output. Execution is resumed after manual intervention is completed.

[0144] The framework's unified governance module implements unified access control and auditing for models, tools, knowledge bases, data sources, and agents. The operations and maintenance monitoring module collects metrics such as request volume, response latency, failure count, first-packet latency, resource usage, and QPS by application, tool, high-code service, and version. The fault tolerance module performs automatic retries, backup model switching, service takeover, or manual confirmation when models fail, tools malfunction, or data sources are interrupted. The high-concurrency processing module performs rate limiting, queuing, and concurrency quota allocation for multi-user, multi-agent, and high-frequency tool calls.

[0145] See Figure 3 The framework's unified governance module also maintains task tables, execution step tables, and call logs during system operation. The task table records input data, output data, final results, error codes, and status. The execution step table records each step according to the task identifier and step number. The call log records input summaries, output summaries, time consumption, and exception information for model calls, tool calls, MCP service calls, or data source calls. Simultaneously, the system maintains a session master table, session message table, operation indicator table, and memory hit record table during operation to support session management and operational monitoring.

[0146] When users or auditors query a task, they can replay the input summary, output summary, component version, time consumption, and exception information of each execution node according to the task identifier and agent version number, thereby realizing the reproducibility, auditability, and recoverability of power business tasks.

[0147] The unified governance module of the framework is also used to write the verification results of electrical safety constraint verification into the call log table or a separate safety verification record table to support the execution of call chain auditing; whereby call chain auditing refers to a data processing mechanism that records a replayable trajectory according to task identifier, agent version number, execution steps, standardized component calls, model calls, manual confirmation, exception handling and output results.

[0148] 6. The report accumulation module is configured to generate power business reports based on report templates and execution results.

[0149] As a specific implementation method, in this embodiment, the report accumulation module receives the YAML report template and user issues. It first parses the inputSchema, globals, and blocks in the template, and then extracts input parameters such as report number, device range, time range, and fault type from the user issues and session history. The system merges the extracted parameters with the manually entered parameters and validates the required fields.

[0150] Each report block can be configured with an MCP data source, a BLOCK data source, and prompt words. For example, in a fault analysis report, the preceding block can obtain basic fault information through the MCP service or workflow component, and subsequent blocks can reference the results of the preceding block, knowledge base retrieval results, and manual confirmation information to generate a fault overview, cause analysis, and handling suggestions. During block execution, the system outputs events such as status, param_extracted, block_start, mcp_call_start, mcp_call_complete, llm_call_start, llm_call_complete, block_complete, markdown_rendered, word_rendered, and complete, facilitating front-end streaming display.

[0151] Once the report is generated, the system renders both Markdown and Word files and saves the report results as a session message. The message metadata records the report type, data source, template version, and download address. For scenarios such as power supply guarantee summaries, defect inspections, daily energy storage operation reports, and ultra-high voltage equipment status assessments, users can directly review the report text through the session or obtain the Word file through the download interface.

[0152] In addition, the intelligent agent engineering framework system for the power industry scenario provided in this embodiment also includes a memory management module;

[0153] The memory management module is used to manage short-term memory, long-term memory, and working memory.

[0154] Short-term memory is used to store multi-turn interaction messages in the current session and is truncated or compressed when the context length exceeds a preset threshold.

[0155] Long-term memory is used to extract cross-session experiential information from historical sessions, including typical device defect patterns, user operating preferences, and common fault handling experience, and is loaded into the task context when a new task is started.

[0156] Working memory is used to store the intermediate execution states, candidate tool sets, and lists of completed nodes for long-cycle tasks during execution.

[0157] When a long-cycle task is suspended due to manual confirmation or abnormal interruption and then resumes execution, the runtime planning and controllable execution module restores the corresponding versioned runtime snapshot and working memory based on the task identifier, and continues execution from the next unexecuted node in the list of completed nodes.

[0158] Example 2

[0159] This embodiment, based on Embodiment 1, takes the intelligent substation inspection defect analysis task as an example. The power scenario resource access and semantic modeling module accesses inspection image recognition results, equipment ledgers, historical defect databases, maintenance records, defect handling procedures, defect dispatch interfaces, and inspection report templates. The system encapsulates the above resources into image result data source components, equipment ledger data source components, defect knowledge base components, maintenance record query MCP services, defect handling skills, work order workflow components, and report template components, and generates a component contract for each component. For example, the component contract for the maintenance record query MCP service limits the input to equipment code and time range, and the output to a list of maintenance records; the component contract for the work order workflow component limits the input to defect level, equipment code, handling suggestions, and confirmer identifier, and the security level is high.

[0160] Engineers create a "Substation Inspection Defect Analysis Agent" in the Agent Store Management Unit, bind the aforementioned standardized components in the Designer Unit, configure system commands to generate defect attribution, risk level, and handling suggestions based on inspection image results, equipment ledgers, and historical defect knowledge, and set the work order closed-loop action as a high-risk action. Upon release, the Agent Design and Version Management module generates a versioned runtime snapshot with version number V1.0. This snapshot solidifies the model strategy, prompt word variables, bound component identifiers, component versions, component contracts, component orchestration order, access control information, and high-risk action strategy.

[0161] Upon receiving the task request "Analyze the defects inspected at a 220kV substation on xx / xx / 202x and generate a report," the environmental perception unit parses out the site, equipment range, time range, user identity, and output format. The runtime planning and controllable execution module loads the V1.0 version runtime snapshot and generates a node-based execution plan: the first node reads the inspection image recognition results; the second node calls the equipment ledger data source to complete the equipment name and operating interval; the third node calls the defect knowledge base to search for similar defects; the fourth node calls the maintenance record query MCP service to obtain maintenance records for the past year; the fifth node calls the defect handling skills to generate risk classification and handling suggestions; the sixth node generates the inspection defect report; and the seventh node decides whether to trigger the work order workflow based on the user confirmation result.

[0162] Before executing each node, the task execution unit performs component availability verification, version consistency verification, input / output contract matching verification, call constraint verification, and electrical safety constraint verification based on the component contracts and electrical safety constraints in the snapshot. If the current version of the MCP service queried in the maintenance record is inconsistent with the snapshot version, the system blocks the node and switches to the compatible instance specified in the snapshot. If a work order workflow node is identified as a high-risk action, the framework's unified governance module suspends the execution plan and outputs a manual confirmation request. If the user agrees, the work order continues to be created; if the user refuses, the node is terminated. After the user modifies the handling suggestion, the system writes the modified content to the working memory and reconstructs subsequent reports and work order nodes.

[0163] Upon completion of the task, the report processing module generates a Word report based on the inspection report template. The report includes a defect list, associated equipment, historical defect comparisons, maintenance record summaries, risk levels, handling recommendations, and manual confirmation records. The system also saves the task table, execution step table, call logs, model call logs, manual confirmation records, anomaly handling traces, and report file addresses. When users or auditors query the task, they can replay the input summary, output summary, component version, time consumption, and anomaly information for each execution node according to the task identifier and agent version number, thus achieving reproducibility, auditability, and recoverability of the defect analysis task.

[0164] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0165] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0166] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0167] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0168] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A smart agent engineering framework system for power industry scenarios, characterized in that, include: The power scenario resource access and semantic modeling module accesses power business resources and generates corresponding resource descriptions; Each power business resource and its corresponding resource description are encapsulated as component resources; The component library module encapsulates the component resources into standardized components containing component contracts, and generates a component list based on the standardized components; wherein, the component contract includes a component identifier, invocation constraints, and input / output contracts; The agent design and version management module selects the standardized components for binding, and configures the component orchestration order, electrical safety constraints and governance strategies of the agent; based on the component contract, component list, component orchestration order, electrical safety constraints, governance strategies and the mapping relationship between standardized components and component identifiers of the bound standardized components, a versioned runtime snapshot and the corresponding version number are generated; The runtime planning and controllable execution module receives a task request containing a target device identifier, calls the versioned runtime snapshot corresponding to the target device identifier, and verifies the called standardized components before executing any node. After the verification is passed, the node is executed, and the position identifier of the current execution node and the action type corresponding to the execution plan are output. The verification includes component availability verification, version consistency verification, input / output contract matching verification, call constraint verification, and electrical safety constraint verification. When the action type belongs to a preset high-risk action and the risk level of the action type reaches a preset threshold, the unified governance module of the framework locates the current execution node and suspends execution; when the current execution node suspends execution, it outputs a manual confirmation request and records the report template and execution result; The report processing module generates a power business report based on the report template and the execution results.

2. The intelligent agent engineering framework system for the power industry scenario according to claim 1, characterized in that, The power scenario resource access and semantic modeling module includes a business resource access unit, a metadata description unit, a power object semantic description unit, and a resource adaptation unit. The business resource access unit is used to access the power business resources, which include data acquisition and monitoring control system SCADA, power management system EMS, distribution network energy management system DMS, power production management system PMS, dispatching and operation management system OMS, protection setting system, defect system, work order system, operation ticket system, equipment ledger, topology model, knowledge document, business interface, model service, workflow and external tools; The metadata description unit and the power object semantic description unit generate corresponding resource descriptions based on the power business resources. Specifically: The metadata description unit is used to generate corresponding resource names, resource types, input / output contracts, calling protocols, versions, statuses, and security levels for each of the power business resources. The power object semantic description unit is used to configure power object identifier, substation, bay, voltage level, equipment type, topology location, operating status, protection area, dispatch jurisdiction, authority scope, operation ticket status, five-prevention interlock status, applicable scenarios and power business resource invocation rules for each power business resource. The resource adaptation unit encapsulates power service resources of different protocols and forms, along with their corresponding resource descriptions, into component resources that can be managed by the component library module and invoked at runtime.

3. The intelligent agent engineering framework system for the power industry scenario according to claim 1, characterized in that, The component library module encapsulates the resource components output by the power scenario resource access and semantic modeling module. The specific encapsulation process includes: The component library module generates a component contract for each component resource. When an agent binds to a data source, knowledge base, MCP service, Skills, or workflow component, it also records the component's visibility scope, calling parameters, version constraints, and security constraints, so that the runtime can only execute calls within the component scope defined by the component list recorded in the versioned runtime snapshot. The component contract includes component identifier, component type, calling protocol, input / output contract, version number, health status, permission scope, security level, calling constraints, and applicable plant, interval, voltage level, equipment type, equipment status, scheduling jurisdiction, and operation ticket constraints. The input / output contract includes an input parameter structure and an output result structure.

4. The intelligent agent engineering framework system for the power industry scenario according to claim 1, characterized in that, The agent design and version management module includes an agent store management unit and a designer unit, specifically: The intelligent agent store management unit is used to manage dedicated intelligent agents and general intelligent agents; the dedicated intelligent agents include intelligent operation and maintenance agents, equipment control agents, scheduling assistance agents, fault analysis agents, and operation support agents; the general intelligent agents include intelligent question-answering agents, report generation agents, voice interaction agents, and tool invocation agents; The intelligent agent store management unit is also used to record the template source, version number, applicable scenarios, input and output definitions, and list of bindable components for each intelligent agent; The designer unit is used to provide an interface for selecting and binding the standardized components, configuring the orchestration order between components, configuring electrical safety constraints, and configuring governance strategies, and generates the versioned runtime snapshot in response to the release operation.

5. The intelligent agent engineering framework system for the power industry scenario according to claim 1, characterized in that, The runtime planning and controllable execution module includes an environment perception unit, an intelligent decision-making unit, a task execution unit, and a collaborative scheduling unit; The environmental sensing unit is used to receive user requests, power alarm events, real-time measurement changes, equipment status changes, topology changes, image input or voice input, and generate a task context that includes user identity, organizational scope, target equipment, plant, interval, voltage level, equipment operating status, dispatch jurisdiction, operation ticket status and session identifier. The intelligent decision-making unit is used to generate a node-based execution plan based on the task context, the standardized component set defined by the versioned runtime snapshot, governance strategies, and electrical safety constraints. The task execution unit is used to execute each node in the nodeized execution plan in sequence and save the execution status of each node; The collaborative scheduling unit is used to control the execution order of multiple agent tasks according to task priority, resource consumption, and concurrency quota.

6. The intelligent agent engineering framework system for the power industry scenario according to claim 3, characterized in that, The verification includes: The component availability check is used to verify whether the target component called by the current node is deployed, online, and in a healthy state. The version consistency check is used to verify whether the version of the target component called by the current node is consistent with the version number recorded in the versioned runtime snapshot; The input-output contract matching check is used to check whether the input parameter structure called by the current node matches the input parameter structure defined in the component contract, and to check whether the output result structure returned after the component is executed matches the output result structure defined in the component contract. The call constraint verification is used to verify whether the current user or the current intelligent agent has the permission to call the target component, whether the data or device involved in the target component is within the operator's jurisdiction, and whether the current call exceeds the preset call quota. The electrical safety constraint verification includes: Device object matching verification is used to verify whether the target device called by the current node belongs to the plant and interval range defined by the task context; Voltage level matching verification is used to verify whether the voltage level of the target device matches the applicable voltage level of the standardized component; The device operation status verification is used to verify whether the current operation status of the target device meets the preconditions of the current node action type; Operation ticket status verification is used to verify whether the operation ticket or work ticket of the target device is in a valid and permitted operation state. The five-prevention interlock status verification is used to verify whether the five-prevention interlock of the target device has been released; The scheduling and jurisdiction permission verification is used to verify whether the current user or the current intelligent agent has scheduling and jurisdiction permission for the target device. The parameter threshold verification is used to verify whether the parameter value to be modified by the current node is within the upper and lower limits of the safe operating parameters of the target device; Action risk grading verification is used to determine the risk level based on the action type and the equipment level of the target device, and to determine whether the risk level reaches a preset threshold.

7. The intelligent agent engineering framework system for the power industry scenario according to claim 5, characterized in that, The runtime planning and controllable execution module also includes an intelligent agent tool invocation unit with electrical safety constraints; The intelligent agent tool invocation unit is configured as follows: Before the task execution unit executes remote control, parameter modification, alarm confirmation, work order closure, or tool call nodes that affect the power grid operation status, it parses the target device, action type, action parameters, and target status in the tool call request; Based on the target equipment, the current status, topology location, scheduling jurisdiction, permitted operation status, interlocking status, and upper and lower limits of parameters are obtained from the equipment ledger, primary topology model, real-time operation data, protection setting system, operation ticket system, work ticket system, and five-prevention interlocking system, and an electrical safety context is generated. The tool call request is matched and verified with the electrical safety context as an electrical safety constraint. The electrical safety constraint verification includes equipment object existence verification, equipment status matching verification, operation ticket effective status verification, five-prevention interlock release status verification, parameter threshold verification, and risk level verification. If any of the matching checks fails, a decision to refuse execution or suspend execution is generated and a manual confirmation request is output; if all checks pass, the release tool is invoked; after the manual confirmation request is fed back, the runtime planning and controllable execution module resumes, terminates or reconstructs the subsequent execution plan according to the task request and feedback results.

8. The intelligent agent engineering framework system for the power industry scenario according to claim 1, characterized in that, The unified governance module of the framework is also used for fault tolerance and automatic recovery; When the runtime planning and controllable execution module encounters a model call exception, tool call exception, data source interruption, or task execution timeout while executing any node, the framework unified governance module executes a recovery strategy based on the exception type and the power service level of the current node. The recovery strategy includes automatic retry, switching to a backup model, switching to a backup tool, recovering the failed task, or transferring to manual confirmation. The automatic retry means re-execute the current node according to the preset number of retries and backoff interval; The switch to the backup model refers to switching to the backup model service recorded in the versioned runtime snapshot and continuing to execute; The switch to the backup tool means switching to the backup tool service recorded in the versioned runtime snapshot and continuing to execute; The recovery of failed tasks involves saving the working memory of the current task and the list of completed nodes, and continuing execution from the next unexecuted node in the list of completed nodes after an abnormal recovery. The manual confirmation step is defined as follows: when the anomaly type cannot be automatically recovered or the power service level reaches a preset threshold, the current task is suspended and a manual intervention request is output. Execution resumes after manual intervention is completed.

9. The intelligent agent engineering framework system for the power industry scenario according to claim 1, characterized in that, The system also includes a memory management module; The memory management module is used to manage short-term memory, long-term memory, and working memory; The short-term memory is used to store multi-turn interaction messages in the current session, and is truncated or compressed when the context length exceeds a preset threshold. The long-term memory is used to extract cross-session experiential information from historical sessions, including typical device defect patterns, user operation preferences, and common fault handling experience, and is loaded into the task context when a new task is started. The working memory is used to store the intermediate execution status, candidate tool set, and list of completed nodes of each node during the execution of long-cycle tasks; When the long-cycle task resumes execution after being suspended due to manual confirmation or abnormal interruption, the runtime planning and controllable execution module restores the corresponding versioned runtime snapshot and the working memory according to the task identifier, and continues execution from the next unexecuted node in the list of completed nodes.

10. The intelligent agent engineering framework system for the power industry scenario according to claim 1, characterized in that, The component library module also includes a resource access control table; The resource access control table records the access permissions and resource scope of each subject to each component resource according to the component identifier; When an agent calls any of the standardized components during runtime, the runtime planning and controllable execution module accesses the resource access control table according to the resource, verifies whether the agent has the right to call the standardized components and whether the resource scope is met. If any condition is not met, the execution of the current node is blocked and an unauthorized call log is recorded.

Images