Intelligent agent capability invocation system and method, electronic device

Abstract

The application discloses an agent capability calling system and method and an electronic device, and belongs to the technical field of artificial intelligence. The system comprises a capability registration center, a constraint module, an agent and a calling module. The capability registration center registers a capability identifier, a capability portrait, calling constraint information and a capability calling entry; the constraint module filters available capabilities based on a task context and generates capability constraint information; the agent generates a task item carrying a target capability identifier accordingly; and the calling module acquires calling constraint information and a capability calling entry based on the target capability identifier, and calls the corresponding capability when the task item meets the constraint. The application can reduce the inconsistency problem caused by the maintenance of multiple capability configurations, and can be applied to scenarios such as agent task arrangement, intelligent question answering, intelligent search, business automatic processing and multi-tool collaborative calling.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence technology, and in particular relates to an intelligent agent capability invocation system and method, and electronic device. Background Technology

[0002] With the development of artificial intelligence and large language model technology, multi-capability intelligent agent task processing technology is gradually being applied to scenarios such as intelligent question answering, business processing, and automated control. This technology typically involves an intelligent agent generating a task plan based on user input, and then an execution engine calling the corresponding backend capabilities according to the capability names in the task plan.

[0003] However, in current agent capability invocation methods, the capability information used by the agent to generate task items and the information used by the execution side to actually invoke capabilities are usually maintained separately. When the task context changes or capabilities are added, adjusted, or deactivated, the range of capabilities that the agent can select and the range of capabilities that the execution side can actually invoke are easily inconsistent, making it difficult for task items to be invoked and executed stably, thus affecting the reliability of agent task processing. Summary of the Invention

[0004] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes an intelligent agent capability invocation system and method, and an electronic device, to reduce the inconsistency between the task items generated by the intelligent agent and the actual capability invocation process, and to improve the reliability of intelligent agent capability invocation.

[0005] Firstly, this application provides an intelligent agent capability invocation system, comprising: A capability registration center is used to register the capability registration information corresponding to multiple capabilities; wherein, the capability registration information includes capability identifier, capability profile, invocation constraint information, and capability invocation entry point; The constraint module is used to respond to a task request sent by a user terminal, determine the task context corresponding to the task request, filter available capabilities from the capability registry based on the task context, and generate capability constraint information based on the capability profile corresponding to the available capabilities. An intelligent agent is used to generate a task item carrying a target capability identifier based on the task request and capability constraint information; The invocation module is used to obtain invocation constraint information and capability invocation entry associated with the target capability identifier from the capability registration center based on the target capability identifier, and invoke the corresponding capability through the capability invocation entry when the task item meets the invocation constraint information.

[0006] Secondly, this application provides a method for invoking intelligent agent capabilities, applied to a server. The server deploys a capability registration center and intelligent agents. The capability registration center registers capability registration information corresponding to multiple capabilities, and the capability registration information includes capability identifier, capability profile, invocation constraint information, and capability invocation entry point. The method includes: In response to a task request sent by a user terminal, determine the task context corresponding to the task request; Based on the task context, filter available capabilities from the capability registry; Based on the capability profile corresponding to the available capabilities, capability constraint information is generated; The intelligent agent is invoked to generate a task item carrying a target capability identifier based on the task request and the capability constraint information; Based on the target capability identifier, obtain the call constraint information and capability call entry associated with the target capability identifier from the capability registration center; If the task item satisfies the calling constraint information, the corresponding capability is invoked through the capability invocation entry point.

[0007] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the intelligent agent capability invocation method as described in the second aspect above.

[0008] Fourthly, this application provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the agent capability invocation method as described in the second aspect above.

[0009] Fifthly, this application provides a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the intelligent agent capability invocation method as described in the second aspect.

[0010] In a sixth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the agent capability invocation method as described in the second aspect above.

[0011] The above-described one or more technical solutions in the embodiments of this application have at least one of the following technical effects: By maintaining the association between capability profiles, invocation constraint information, and capability invocation entry points through a capability registration center, the capability information used by the agent to generate task items is consistent with the information used by the invocation module to actually invoke the capability. By filtering available capabilities through task context, the agent can avoid selecting capabilities that are unavailable or inapplicable in the current scenario. Furthermore, by invoking the corresponding capability only after the task item meets the invocation constraint information, task items that do not meet the constraints can be intercepted before capability invocation. This reduces the risk of invocation failures caused by capability additions, adjustments, decommissioning, or changes in task context, improving the stability and controllability of agent capability invocation.

[0012] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0013] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a schematic diagram of the structure of the intelligent agent capability invocation system provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the intelligent agent capability invocation method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments that can be directly obtained based on the embodiments of this application are within the scope of protection of this application.

[0015] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0016] Multi-capability intelligent agent task processing scenarios refer to scenarios where an intelligent agent needs to select and invoke one or more backend capabilities to complete a task based on user input, instructions, or business requests. Backend capabilities may include data querying, knowledge retrieval, diagnostic analysis, control operations, external service calls, or other processing capabilities that can be triggered by the intelligent agent.

[0017] In related solutions, the intelligent agent typically uses a large language model to understand the user's natural language question and generate a task plan. The task plan can include the name of the capability to be invoked, a task description, and structured input parameters. Upon receiving the task plan, the execution engine invokes the corresponding backend capabilities based on the capability names in the task plan to obtain the execution result.

[0018] However, in the above processing methods, the planning side and the execution side typically maintain relevant information separately. For example, the planning side may maintain capability descriptions for large language models, the execution side may maintain capability routing rules, the verification side may maintain capability input parameter constraints, and the business side may also maintain capability start / stop status, tenant visibility range, scenario availability range, exception handling rules, and failure semantics respectively.

[0019] Because this information is scattered across different configurations, code, or services, the scope of capabilities visible on the planning side is easily inconsistent with the scope of capabilities that can actually be invoked on the execution side, causing the agent to generate capability names that cannot be executed or input parameters that do not meet the constraints.

[0020] In addition, when adding, deleting or adjusting a capability, the system usually needs to modify multiple parts such as capability description, routing rules, input constraints and permission policies simultaneously, which is costly to maintain and can easily lead to semantic inconsistencies between capability description, applicable scenarios, input constraints and execution logic due to omissions in modification.

[0021] When different tenants, sessions, roles, or business scenarios require dynamic tailoring of available capabilities, if the filtering criteria on the planning side and the routing criteria on the execution side are inconsistent, there may be issues such as capabilities that are allowed to be used in the planning phase being unavailable in the execution phase, or capabilities that are available in the execution phase not being correctly provided to the agent.

[0022] In view of this, embodiments of this application provide an intelligent agent capability invocation system and method, aiming to solve the problems of inconsistency between visible capabilities on the planning side and callable capabilities on the execution side, decentralized maintenance of capability configuration, and delayed detection of illegal capabilities or illegal inputs. By establishing a unified capability registration mechanism, the capability information visible to the intelligent agent, the capability invocation entry that can be parsed on the execution side, and the input constraints that need to be verified before invocation all originate from the same capability registration information. It can determine the range of available capabilities in the current task context before task planning, and complete the parsing of capability invocation entry and verification of input constraints based on the same capability identifier before task execution. This reduces the invocation failure problem caused by inconsistency between the planning side and the execution side, thereby improving the consistency, stability, and manageability of intelligent agent capability invocation.

[0023] The intelligent agent capability invocation system and method provided in this application will be described in detail below with reference to the accompanying drawings, through embodiments and application scenarios.

[0024] like Figure 1 As shown in the figure, this application provides an intelligent agent capability invocation system, which may include a capability registration center 101, a constraint module 102, an intelligent agent 103, and an invocation module 104.

[0025] The intelligent agent capability invocation system can be deployed on servers, intelligent agent platforms, cloud-based business systems, or other electronic devices with data processing capabilities, and communicate with user terminals. User terminals can be mobile phones, tablets, personal computers, vehicle terminals, maintenance terminals, or other electronic devices capable of initiating task requests.

[0026] Here, capability refers to the functional unit that can be invoked by the intelligent agent 103 to complete task processing.

[0027] Capabilities may include data query capabilities, knowledge retrieval capabilities, diagnostic analysis capabilities, control operation capabilities, external service invocation capabilities, file processing capabilities, database access capabilities, or other capabilities that can be triggered and executed by the intelligent agent 103.

[0028] Capabilities can be deployed within the intelligent agent capability invocation system, or they can be deployed in external business systems, third-party services, databases, plugin services, or other accessible execution environments.

[0029] Capability Registration Center 101 is used to register the capability registration information corresponding to multiple capabilities.

[0030] Capability registration information is a collection of data used to describe capabilities and control capability invocation. Capability registration information includes at least a capability identifier, capability profile, invocation constraint information, and capability invocation entry point.

[0031] The capability identifier is used to uniquely identify the corresponding capability, so that the task items generated by the intelligent agent 103 and the capability parsing executed by the calling module 104 can be matched based on the same identifier.

[0032] A capability profile is used to describe a capability and may include at least one of the following: capability description, applicable scenarios, inapplicable scenarios, invocation examples, required context, and policy attributes. The capability description describes the purpose of the capability; the applicable scenarios describe the business conditions under which the capability is suitable for invocation; the inapplicable scenarios describe the conditions under which the capability should not be invoked; the invocation examples assist the agent 103 in understanding the input and output methods of the capability; the required context describes the contextual information required before invoking the capability; and the policy attributes describe the permissions, tenants, environment, or security policies involved in the capability.

[0033] Invocation constraint information is used to limit the conditions that must be met when a capability is invoked, thereby determining whether a task item is allowed to invoke the corresponding capability. Invocation constraint information may include at least one of the following: input parameter constraints, applicable conditions, inapplicable conditions, permission conditions, scenario conditions, and policy conditions. For task items that carry capability input parameters, invocation constraint information may also include parameter constraint information.

[0034] The capability invocation entry point is used to point to the invocation path that actually executes the capability, and may include at least one of the following: local function entry point, remote service interface, workflow node, message queue consumption entry point, or external intelligent agent entry point.

[0035] Therefore, by defining the specific content of the capability profile, call constraint information, and capability call entry point, the capability registration information can simultaneously cover the information required for the intelligent agent 103 to understand the capability, the constraints required for the capability call pre-call judgment, and the entry information required for the actual execution call. The capability registration center 101 can support capability selection, call verification, and execution routing under the same capability identifier, further improving the consistency between the planning and execution sides.

[0036] In some embodiments, the capability registry 101 may receive or load capability declaration information and register capability registration information based on the capability declaration information. The capability declaration information is used to declare the existence of a capability and its invocation conditions to the capability registry 101.

[0037] Capability declaration information can come from configuration files, databases, service discovery information, plugin declarations, code metadata, or build-time generated manifests. In addition, capability declaration information can also come from other equivalent sources that can characterize capability identifiers, capability profiles, call constraint information, and capability call entry points.

[0038] For example, in a plug-in intelligent agent platform, each plug-in can provide its own corresponding capability identifier, capability description, input parameter format, call entry point and permission conditions in the plug-in declaration; the capability registration center 101 reads the plug-in declaration when the plug-in is installed or loaded, and registers the plug-in capability as a capability that can be recognized and called by the system.

[0039] For example, in a service-oriented deployment scenario, backend services can expose capability call entry points to the capability registry 101 through service discovery information, and the capability registry 101 can generate corresponding capability registration information based on the service discovery results.

[0040] Therefore, the capability registry 101 registers capability registration information by receiving or loading capability declaration information, enabling capabilities to access the system from different sources such as configuration files, databases, service discovery information, plugin declarations, code metadata, or build-time generated manifests. This allows for adaptation to various capability access methods, including static configuration, plugin extensions, and service-oriented deployments, reducing reliance on fixed code or manual routing configuration when adding new capabilities and improving the flexibility of capability access.

[0041] The capability declaration information may include code metadata, which is provided by capability annotations on the capability executor.

[0042] A capability executor is a program object that actually carries the capability execution logic, such as a function, class, service processor, workflow node processor, or plug-in processor.

[0043] Capability annotations can be set on capability executors to declare capability identifiers, capability names, capability descriptions, input parameter definitions, output result definitions, permission conditions, scenario conditions, or call entry points.

[0044] When the application starts, the capability registry 101 scans capability executors carrying capability annotations and registers capability registration information based on the capability annotations to establish a routing relationship between capability identifiers and capability executors. For example, if a data query executor is annotated with the capability identifier "data_query", parameter fields "objectId" and "timeRange", and the corresponding processing function entry point, the capability registry 101 registers the executor as a data query capability during startup scanning, so that subsequent tasks carrying the target capability identifier "data_query" can be routed to that executor.

[0045] Therefore, by providing code metadata through capability annotations on capability executors and scanning capability executors carrying capability annotations at application startup, a direct correspondence can be established between capability execution logic and capability registration information. Consequently, the routing relationship between capability identifiers and capability executors can be automatically formed along with the code structure, reducing the workload of manually maintaining capability routing tables and lowering the risk of configuration errors at capability execution entry points.

[0046] In some embodiments, the capability registry 101 may update capability registration information in response to capability registration requests, capability update requests, or capability delisting requests. Capability registration requests can be used to add capabilities, capability update requests can be used to adjust capability profiles, call constraint information, or capability call entry points, and capability delisting requests can be used to remove a capability from the set of available capabilities or mark it as unavailable.

[0047] After the capability registration information is updated, the constraint module 102 and the invocation module 104 process the data based on the updated capability registration information. For example, if an external service invocation capability is taken offline for maintenance, the capability registration center 101 updates the availability status of the capability. The constraint module 102 will no longer filter the capability as an available capability in subsequent task requests, and the invocation module 104 will no longer execute invocations based on the capability invocation entry point.

[0048] Therefore, after a capability is added, adjusted, or deactivated, the range of capabilities that the agent 103 can select and the range of capabilities that the calling module 104 can actually call can change synchronously, reducing the call failure caused by inconsistencies in information between the two sides after the capability status changes.

[0049] In some embodiments, the capability registry 101 may receive, load, or update capability declaration information and register capability registration information during application startup, module loading, plugin installation, service discovery, configuration change, or build phases. Different registration times can be adapted to different system architectures.

[0050] For example, fixed deployment capabilities can be registered uniformly when the application starts; plug-in capabilities can be registered when the plug-in is installed or loaded; microservice capabilities can be registered during the service discovery phase; when capability invocation policies or permission conditions change, the registration can be updated during the configuration change phase; and static capability lists can also be generated during the build phase and loaded by the capability registry 101.

[0051] Therefore, the appropriate registration time can be selected according to different capability sources and deployment methods, enabling the capability registration center 101 to adapt to various capability sources such as static capabilities, dynamic plug-in capabilities, and service-oriented capabilities. This allows fixed capabilities, plug-in capabilities, service capabilities, and configuration-driven capabilities to be included in unified management, improving the system's adaptability to different operating architectures.

[0052] The constraint module 102 is used to respond to a task request sent by the user terminal and determine the task context corresponding to the task request. The task request can be a natural language question, a business processing instruction, a data query request, an analysis request, or a control request. The task context can include at least one of the following: user identity, tenant information, session information, role permissions, business scenario, operating environment, security policy, or other contextual information related to this task request.

[0053] User identity can be used to identify the user who initiated the task request; tenant information can be used to identify the tenant to which the current request belongs; session information can be used to characterize the current multi-round task processing process; role permissions can be used to limit the scope of capabilities that users can use; business scenarios can be used to distinguish scenarios such as intelligent question answering, operation and maintenance processing, data analysis, and automated control; runtime environment can be used to distinguish between production environment, test environment, or gray-scale environment; security policies can be used to limit the conditions for calling sensitive capabilities, control capabilities, or external service call capabilities.

[0054] In some embodiments, the task context may further include device type. Device type can be used to distinguish between user terminal type, service device type, access device type, or operated object type, so that constraint module 102 can filter the capabilities allowed under the current task request based on device type.

[0055] For example, when a user initiates a control request for an energy storage device through an operation and maintenance terminal, the device type in the task context can include "operation and maintenance terminal" and "energy storage device". The constraint module 102 can filter the status query capabilities, fault diagnosis capabilities, or parameter configuration capabilities permitted for energy storage device scenarios based on this device type, and filter out capabilities applicable only to vehicle terminals, production equipment, or other business equipment. Similarly, when a user initiates a vehicle status analysis request through an in-vehicle terminal, the constraint module 102 can, based on the device type corresponding to "in-vehicle terminal" or "vehicle", only provide the intelligent agent 103 with vehicle data query, vehicle diagnostic analysis, and other capabilities.

[0056] Therefore, by limiting the specific content of the task context and capability constraint information, the constraint module 102 can generate capability constraint information that is more suitable for the current task based on factors such as user identity, tenant, session, role permissions, business scenario, operating environment, and security policies. The intelligent agent 103 can generate task items under clear capability identifiers, capability descriptions, input parameter requirements, and invocation restrictions, reducing the risk of capability misselection and unauthorized invocation.

[0057] The constraint module 102 filters available capabilities from the capability registry 101 based on the task context. For example, if the current user does not have permission for a certain control operation, the constraint module 102 will not determine that control operation capability as an available capability; if the current business scenario only allows knowledge retrieval and data query, the constraint module 102 can filter only capabilities related to knowledge retrieval and data query.

[0058] In some embodiments, the constraint module 102 can filter multiple capabilities registered in the capability registry 101 according to the task context to obtain available capabilities, and generate capability constraint information based on the capability identifier and capability profile corresponding to the available capabilities. The filtering process can be based on tenant, role, session, business scenario, operating environment, security policy, or other conditions.

[0059] For example, in an operation and maintenance scenario, ordinary users can only use status query capabilities and knowledge retrieval capabilities, while administrator users can also use control operation capabilities; the constraint module 102 filters multiple capabilities registered in the capability registry 101 according to user roles, and converts the filtered available capabilities into capability constraint information, so that the intelligent agent 103 can only select capabilities within the allowed range.

[0060] This allows the range of capabilities provided to agent 103 to match the current task context, reducing the probability that agent 103 will select capabilities that are unavailable under the current user, scenario, or policy, and improving the effectiveness of task item generation.

[0061] The constraint module 102 is also used to generate capability constraint information based on the capability profile corresponding to the available capabilities. The capability constraint information is a capability selection boundary provided to the intelligent agent 103 to limit the range of capabilities that the intelligent agent 103 can select when processing task requests.

[0062] Capability constraint information may include the capability identifier corresponding to the available capability, capability description, input parameter requirements, calling restrictions, applicable scenarios, or calling examples.

[0063] Thus, before generating task items, agent 103 can know the capabilities allowed in the current task context, rather than selecting capabilities based on fixed prompts or static capability documents.

[0064] The intelligent agent 103 is used to generate task items carrying target capability identifiers based on task requests and capability constraint information.

[0065] Agent 103 can be implemented by a large language model, a rule arranger, a multi-agent cooperative unit, or other task planning units.

[0066] A task item is the data of tasks to be executed generated by agent 103 in response to a task request. A task item carries at least a target capability identifier, which indicates the capability that agent 103 expects to invoke. A task item may also carry capability input parameters, task description, execution order information, task dependencies, or parallel execution identifiers.

[0067] For example, when a user requests to query the historical status of a certain business object and generate analysis conclusions, the intelligent agent 103 can generate data query task items and diagnostic analysis task items based on capability constraint information, and carry the corresponding target capability identifier in each task item.

[0068] The invocation module 104 is used to obtain the invocation constraint information and capability invocation entry point associated with the target capability identifier from the capability registration center 101 based on the target capability identifier. After obtaining the invocation constraint information, the invocation module 104 determines whether the task item meets the invocation constraint information.

[0069] For task items that carry capability input parameters, the calling module 104 can validate the capability input parameters based on the parameter constraint information in the calling constraint information. This validation includes, but is not limited to, at least one of the following: field structure validation, field type validation, required field validation, value range validation, or cross-field validation.

[0070] The parameter constraint information may include at least one of structured schemas, field rules, expressions, function validators, and remote validation services. The calling module 104 performs pre-call validation on the capability input parameters based on the parameter constraint information, and determines that the task item satisfies the call constraint information if the capability input parameters satisfy the parameter constraint information.

[0071] Parameter constraint information may further include at least one of the following: field structure constraints, field type constraints, required field constraints, value range constraints, and cross-field constraints. For example, a data query capability requires input parameters to include a business object identifier and a time range. The business object identifier is a string type, and the start time of the time range must not be later than the end time. Before calling this data query capability, the calling module 104 performs field structure, field type, required field, and cross-field validation on the capability input parameters in the task item. Only after the validation passes can the capability be called.

[0072] Therefore, issues such as incorrect field structure, field type, required fields, value range, or cross-field relationships can be detected before capability invocation, preventing illegal input from entering the actual capability execution process and improving the stability of capability invocation.

[0073] In some embodiments, when there are correctable type or format differences in the capability input parameters, the calling module 104 can normalize the capability input parameters and perform pre-call validation based on the normalized capability input parameters. Type differences may include converting string-formatted numbers to numeric types, converting single objects to array formats, etc. Format differences may include inconsistent date formats, case sensitivity of enumeration values, inconsistent field naming conventions, or inconsistent unit expressions, etc.

[0074] For example, if the time field in the capability input parameters generated by agent 103 is "2026 / 05 / 01", while the parameter constraint information requires the time field to be in the format "2026-05-01", the calling module 104 can first normalize the time field to the target format and then perform pre-call validation. For capability input parameters that cannot be normalized or still do not meet the parameter constraint information after normalization, the calling module 104 can generate a call failure message and not call the corresponding capability.

[0075] Therefore, minor format deviations commonly found in the output of agent 103 can be automatically corrected, reducing false failures caused by differences in date format, field format, or type expression, while still maintaining the effectiveness of pre-call constraint validation.

[0076] If the task item meets the calling constraint information, the calling module 104 calls the corresponding capability through the capability calling entry. For example, the calling module 104 can send an interface request to an external service based on the capability calling entry, or call a local function to execute data processing logic, or trigger a workflow node to execute the corresponding processing flow.

[0077] After the corresponding capability is executed, the calling module 104 can obtain the capability call result and directly provide it to the intelligent agent 103, the reflection module, the result organization module, the replanning module, the monitoring module, or other subsequent processing modules, or provide it after writing it into the task result. The task result may include the capability call status, capability output data, call time, failure reason, intermediate evidence, or context reference information corresponding to the task item. The reflection module can determine whether the current task item has satisfied the task request or whether it is necessary to call other capabilities based on the task result; the replanning module can adjust the capability selection, execution order, or input parameters of subsequent task items based on the task result.

[0078] For example, in an equipment operation and maintenance analysis scenario, after the calling module obtains equipment operation data through data query capabilities, it can write the operation data and query status into the task results. The reflection module can determine whether the current data is sufficient to support anomaly analysis based on the task results; if the data lacks key time periods or fields, the replanning module can generate new data to supplement the query task items; if the data is complete, the replanning module can continue to trigger the anomaly diagnosis capability or the result organization module to generate analysis conclusions for the user terminal. In this embodiment, the capability registry 101 associates capability profiles, call constraint information, and capability call entry points under the same capability identifier. The constraint module 102 generates capability constraint information for use by the agent 103 based on the capability registry 101, and the call module 104 parses the call constraint information and capability call entry point corresponding to the target capability identifier based on the same capability registry 101. Therefore, the capability range visible to the agent 103, the capability entry points that the call module 104 can parse, and the call constraints that the task items need to satisfy all originate from the capability registry 101, which can reduce the inconsistency caused by the decentralized maintenance of capability descriptions on the planning side, call entry points on the execution side, and call constraint information.

[0079] By employing the aforementioned intelligent agent capability invocation system, when adding, updating, or decommissioning capabilities, the capability registration information in the capability registration center 101 can be updated, enabling the constraint module 102 and the invocation module 104 to process based on the updated capability registration information. Consequently, the capability constraint information used by the intelligent agent 103 to generate task items is consistent with the capability invocation entry point and invocation constraint information used by the invocation module 104 to execute capability invocations. This reduces the probability of the intelligent agent 103 generating unexecutable task items or illegal capability invocation requests, improving the stability and manageability of the intelligent agent 103's capability invocation process.

[0080] In some embodiments, the calling module 104 may also generate calling failure information corresponding to the task item if it fails to obtain the capability calling entry associated with the target capability identifier from the capability registration center 101, or if the task item does not meet the calling constraint information.

[0081] Call failure information is used to characterize why a task item cannot be executed normally. Call failure information can trigger at least one of the following actions: rescheduling, degraded call, manual confirmation, monitoring alerts, and audit logging. Call failure information can include at least one failure type: unregistered capability, input validation failure, capability unavailable, policy rejection, and capability call entry point unavailable.

[0082] For example, if the task item generated by the intelligent agent 103 carries an unregistered target capability identifier, and the calling module 104 cannot obtain the corresponding capability call entry, then a call failure message corresponding to the unregistered capability will be generated; or if the input parameters carried by the task item do not meet the parameter constraint information of the capability, then a call failure message corresponding to invalid input parameters will be generated.

[0083] Therefore, by generating call failure information before the actual call to the capability, capability call exceptions can be converted into identifiable and processable task-level failure information, preventing exceptions from entering deeper backend call chains and causing them to be exposed out of order in the backend call chains, thus improving fault location and task recovery capabilities.

[0084] In some embodiments, the intelligent agent 103 can also re-plan the task request based on the call failure information, or generate task response information to return to the user terminal. When the call failure information indicates that the target capability is unavailable but an alternative capability exists, the intelligent agent 103 can combine the call failure information and capability constraint information to regenerate the task item and call other available capabilities to complete the task. When the call failure information indicates that the current task cannot continue to be executed, the intelligent agent 103 can generate task response information for the user terminal, indicating the reason why the task cannot be completed, the information that needs to be supplemented, or the possible processing methods. For example, when the target capability is denied access due to insufficient permissions of the current role, the intelligent agent 103 can generate task response information prompting the user to switch permissions or contact the administrator.

[0085] Therefore, when the target capability is unavailable, permissions are insufficient, or the input is invalid, the agent 103 can adjust the subsequent processing method based on the reason for the failure, instead of directly interrupting the task, thereby improving the continuity of task processing and the clarity of user-side feedback.

[0086] In some embodiments, the intelligent agent capability invocation system may further include a recording module. The recording module is used to record at least one of the following: the screening process of available capabilities, the generation process of capability constraint information, the generation result of task items, the acquisition result of capability invocation entry points, and the invocation result of corresponding capabilities. The recording module may also write the recorded information to at least one of the following: a log, an event stream, a link tracing system, an auditing system, and task results.

[0087] For example, during a task processing process, the recording module can record the capabilities that are filtered out in the context of this task, the capability constraint information finally provided to the agent 103, the target capability identifier generated by the agent 103, the capability call entry point obtained by the calling module 104, and the capability call result.

[0088] Therefore, by recording the above information, the key intermediate states in the process of intelligent agent 103's capability selection and invocation can be fully preserved, which facilitates subsequent problem localization, invocation tracking, audit verification and operation monitoring.

[0089] The intelligent agent capability invocation system provided in this application embodiment maintains the association between capability profiles, invocation constraint information, and capability invocation entry points through a capability registration center. This ensures that the capability information upon which the intelligent agent generates task items is consistent with the information upon which the invocation module actually invokes the capabilities. By filtering available capabilities through task context, the system avoids the intelligent agent selecting capabilities that are unavailable or inapplicable in the current scenario. Furthermore, by invoking the corresponding capability only after the task item meets the invocation constraint information, task items that do not meet the constraints can be intercepted before capability invocation. Therefore, the system reduces the risk of invocation failures caused by capability additions, adjustments, decommissioning, or changes in task context, and improves the stability and controllability of intelligent agent capability invocation.

[0090] This application also provides a method for invoking intelligent agent capabilities. This method can be applied to servers, intelligent agent platforms, cloud-based business systems, or other electronic devices with data processing capabilities. The server deploys a capability registry and intelligent agents. The capability registry registers the capability registration information corresponding to multiple capabilities.

[0091] like Figure 2 As shown, the method for invoking the agent's capabilities includes the following steps: Step 210: In response to the task request sent by the user terminal, determine the task context corresponding to the task request; Step 220: Based on the task context, filter available capabilities from the capability registry; Step 230: Generate capability constraint information based on the capability profile corresponding to the available capabilities; Step 240: Invoke the intelligent agent to generate a task item carrying the target capability identifier based on the task request and capability constraint information; Step 250: Based on the target capability identifier, obtain the call constraint information and capability call entry point associated with the target capability identifier from the capability registry center; Step 260: If the task item meets the calling constraint information, call the corresponding capability through the capability calling entry.

[0092] In step 210, the server responds to the task request sent by the user terminal and determines the task context corresponding to the task request. After receiving the task request, the server can combine one or more of the following information carried by the user terminal: user identity, tenant identifier, session identifier, role permissions, business entry point, operating environment, or security policy, to form the task context.

[0093] For example, if a user enters "Query the operating status of energy storage device A in the last 24 hours and analyze the cause of the anomaly" through the operation and maintenance terminal, the server can determine the current user's tenant, user role, session identifier, and business scenario as the device operation and maintenance analysis scenario based on the request, and form a task context by combining the current operating environment and security policies.

[0094] In step 220, the server filters available capabilities from the capability registry based on the task context. The server can filter multiple capabilities registered in the capability registry based on one or more of the following factors in the task context: tenant information, role permissions, business scenario, operating environment, or security policy. The server then determines the capabilities that are allowed and available in the scenario corresponding to the current task request as available capabilities.

[0095] For example, in a device operation and maintenance analysis scenario, if the current user has device status query and anomaly analysis permissions but not remote control permissions, the server can determine the device data query capability, knowledge retrieval capability, and anomaly diagnosis capability as available, but not the remote control capability. Therefore, the agent will not select capabilities that the current user does not have permission to access in subsequent task processing.

[0096] In step 230, the server generates capability constraint information based on the capability profiles corresponding to available capabilities. The server can extract information from the capability profiles of available capabilities for the agent to understand and select capabilities, and organize the extraction results into capability constraint information.

[0097] For example, for the device data query capability, the capability constraint information may include the capability identifier, the applicability to query device operation data, the required input device identifier and time range, etc.; for the anomaly diagnosis capability, the capability constraint information may include the capability identifier, the applicability to generate anomaly cause analysis based on operation data, the required input operation data or data query results, etc.

[0098] In step 240, the server invokes the agent to generate task items based on the task request and capability constraint information. When generating task items, the agent uses the task request as the task target and the capability constraint information as the capability selection boundary, selecting the target capability from available capabilities and generating a task item carrying the target capability identifier. The task item may also carry capability input parameters, task description, execution order information, or task dependencies.

[0099] For example, for a task request to "query the operating status of energy storage device A over the past 24 hours and analyze the cause of the anomaly," the agent can first generate a first task item carrying a device data query capability identifier, and include the device identifier and time range in the first task item; then, it can generate a second task item carrying an anomaly diagnosis capability identifier, and use the query result of the first task item as the input source for the second task item. Thus, all task items generated by the agent correspond to the available capabilities in the capability constraint information.

[0100] In step 250, the server retrieves the call constraint information and capability call entry point associated with the target capability identifier from the capability registry center based on the target capability identifier in the task item. The server can use the target capability identifier as an index to query the corresponding capability registration information in the capability registry center and obtain the call constraint information and capability call entry point from the capability registration information.

[0101] For example, when the target capability identifier carried by a task item is a device data query capability identifier, the server can obtain the corresponding parameter constraint information and data query service interface address from the capability registry center. The parameter constraint information can specify that the device identifier is a required field, the time range must conform to a preset format, and the query time span must not exceed a preset upper limit.

[0102] In step 260, if the task item meets the invocation constraints, the server invokes the corresponding capability through the capability invocation entry point. The server can perform pre-invocation checks on the task item based on the invocation constraints. If the task item carries capability input parameters, the server can perform field structure validation, field type validation, required field validation, value range validation, or cross-field validation on the capability input parameters based on the parameter constraints in the invocation constraints. If the task item meets the invocation constraints, the server invokes the corresponding capability through the capability invocation entry point and obtains the capability invocation result.

[0103] For example, after confirming that the device data query task item includes the device identifier and time range, that the time range format is valid, and that the query span does not exceed the limit, the server calls the device data query capability through the data query service interface to obtain the operating data of device A for the most recent 24 hours. If the task item lacks required fields, the target capability identifier is not registered, the current task context does not meet the calling strategy, or the capability calling entry is unavailable, the server may not call the corresponding capability and will generate corresponding call failure information for use in replanning, downgrading calls, manual confirmation, monitoring alarms, or audit records.

[0104] Through the above steps, the server limits the range of available capabilities based on the task context before the agent generates a task item, and obtains the call constraint information and capability call entry point based on the same capability registry center before the capability is called to control the call, so that the capability selection on the agent side is consistent with the capability call on the execution side, reducing the risk that the task item cannot be executed stably.

[0105] The agent capability invocation method provided in this embodiment is based on the same concept as the agent capability invocation system embodiment described above. For the specific implementation process, terminology meanings and beneficial effects, please refer to the relevant content in the above system embodiment, which will not be repeated here.

[0106] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0107] In some embodiments, such as Figure 3 As shown, this application embodiment also provides an electronic device 300, including a processor 301, a memory 302, and a computer program stored in the memory 302 and executable on the processor 301. When the program is executed by the processor 301, it implements the various processes of the above-described intelligent agent capability invocation method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0108] This application provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described intelligent agent capability invocation method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0109] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-storable media, such as computer read-only memory (ROM), random-access memory (RAM), magnetic disks, or optical disks.

[0110] The computer-readable storage medium may include: read-only memory (ROM), random-access memory (RAM), magnetic disk or optical disk, etc.

[0111] This application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described intelligent agent capability invocation method.

[0112] This application provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described intelligent agent capability invocation method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0113] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0114] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0115] From the above description of the embodiments, it is clear that the methods described in the embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases, the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0116] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the above-described embodiments. The above-described embodiments are merely illustrative and not restrictive. Under the guidance of this application, many other forms can be made without departing from the spirit and scope of the claims, and all of them are within the protection scope of this application.

[0117] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0118] Although embodiments of this application have been shown and described, it is understood that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

Claims

1. A system for invoking the capabilities of an intelligent agent, characterized in that, include: A capability registration center is used to register the capability registration information corresponding to multiple capabilities; wherein, the capability registration information includes capability identifier, capability profile, invocation constraint information, and capability invocation entry point; The constraint module is used to respond to a task request sent by a user terminal, determine the task context corresponding to the task request, filter available capabilities from the capability registry based on the task context, and generate capability constraint information based on the capability profile corresponding to the available capabilities. An intelligent agent is used to generate a task item carrying a target capability identifier based on the task request and capability constraint information; The invocation module is used to obtain invocation constraint information and capability invocation entry associated with the target capability identifier from the capability registration center based on the target capability identifier, and invoke the corresponding capability through the capability invocation entry when the task item meets the invocation constraint information.

2. The intelligent agent capability invocation system according to claim 1, characterized in that, The capability registry is also used for: Receive or load capability declaration information; Register the capability registration information based on the capability declaration information; The capability declaration information is derived from at least one of the following: configuration file, database, service discovery information, plugin declaration, code metadata, or build-time generated manifest.

3. The intelligent agent capability invocation system according to claim 2, characterized in that, The capability declaration information includes code metadata, which is provided by capability annotations on the capability executor; The capability registry is also used for: When the application starts, it scans for capability executors carrying the capability annotations and establishes a routing relationship between capability identifiers and capability executors based on the capability annotation level and the capability registration information.

4. The intelligent agent capability invocation system according to claim 1 or 2, characterized in that, The capability registry is also used for: In response to a capability registration request, capability update request, or capability decommissioning request, the capability registration information is updated so that the constraint module and the invocation module process the data based on the updated capability registration information.

5. The intelligent agent capability invocation system according to claim 1 or 2, characterized in that, The capability registration center receives, loads, or updates capability declaration information and registers capability registration information during application startup, module loading, plugin installation, service discovery, configuration change, or build phases.

6. The intelligent agent capability invocation system according to claim 1, characterized in that, The calling module is also used for: If no capability call entry associated with the target capability identifier is obtained from the capability registry, or if the task item does not meet the call constraint information, call failure information corresponding to the task item is generated; The call failure information is used to trigger at least one of the following processes: rescheduling, downgraded call, manual confirmation, monitoring alarm, and audit log.

7. The intelligent agent capability invocation system according to claim 6, characterized in that, The intelligent agent is also used for: Based on the call failure information, the task request is re-planned; or Generate task response information to be returned to the user terminal.

8. The intelligent agent capability invocation system according to claim 1, characterized in that, The constraint module is used for: Based on the task context, multiple capabilities registered in the capability registry are filtered to obtain the available capabilities; Based on the capability identifier and capability profile corresponding to the available capabilities, the capability constraint information is generated.

9. The intelligent agent capability invocation system according to claim 1, characterized in that, The task item also carries capability input parameters; the call constraint information includes parameter constraint information, which includes at least one of structured schema, field rules, expressions, function validators, and remote validation services; The calling module is also used for: The capability input parameters are validated before being invoked based on the parameter constraint information. If the capability input parameters satisfy the parameter constraint information, it is determined that the task item satisfies the call constraint information; The parameter constraint information includes at least one of the following: field structure constraints, field type constraints, required field constraints, value range constraints, and cross-field constraints.

10. The intelligent agent capability invocation system according to claim 9, characterized in that, The calling module is also used for: If there are correctable type or format differences in the capability input parameters, the capability input parameters are normalized, and pre-call verification is performed based on the normalized capability input parameters.

11. The intelligent agent capability invocation system according to claim 1, characterized in that, The system also includes: The recording module is used to record at least one of the following: the screening process of the available capabilities, the generation process of the capability constraint information, the generation result of the task item, the acquisition result of the capability call entry, and the call result of the corresponding capability; The recording module is also used to write the recorded information into at least one of a log, event stream, tracing system, auditing system, and task results.

12. The intelligent agent capability invocation system according to claim 1, characterized in that, The capability profile includes at least one of the following: capability description, applicable scenarios, inapplicable scenarios, invocation examples, required context, and strategy attributes; The call constraint information includes at least one of the following: input parameter constraints, applicable conditions, inapplicable conditions, permission conditions, scenario conditions, and strategy conditions. The capability invocation entry point includes at least one of the following: local function entry point, remote service entry point, workflow node entry point, message queue consumption entry point, and external intelligent agent entry point.

13. The intelligent agent capability invocation system according to claim 1, characterized in that, The task context includes at least one of user identity, tenant information, session information, role permissions, business scenario, operating environment, and security policy; the capability constraint information includes at least one of capability identifier, capability description, input parameter requirements, and invocation restrictions corresponding to the available capability.

14. A method for invoking the capabilities of an intelligent agent, characterized in that, Applied to a server, the server deploys a capability registration center and an intelligent agent. The capability registration center registers capability registration information corresponding to multiple capabilities. The capability registration information includes capability identifier, capability profile, invocation constraint information, and capability invocation entry point. The method includes: In response to a task request sent by a user terminal, determine the task context corresponding to the task request; Based on the task context, filter available capabilities from the capability registry; Based on the capability profile corresponding to the available capabilities, capability constraint information is generated; The intelligent agent is invoked to generate a task item carrying a target capability identifier based on the task request and the capability constraint information; Based on the target capability identifier, obtain the call constraint information and capability call entry associated with the target capability identifier from the capability registration center; If the task item satisfies the calling constraint information, the corresponding capability is invoked through the capability invocation entry point.

15. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the agent capability invocation method as described in claim 14.

Images