A resource calling method and device for an artificial intelligence scene and electronic equipment

Abstract

This disclosure provides a resource invocation method, apparatus, and electronic device for artificial intelligence scenarios, relating to the field of computer technology, particularly cloud computing and artificial intelligence, and applicable to scenarios such as intelligent agent resource invocation. The specific solution is as follows: In response to a current task request submitted by an intelligent agent, the current access control policy and the real-time status of backend resources are obtained; a candidate resource set is generated based on the semantic information of the current task request and the descriptive information of the backend resources; a backend resource list is obtained by filtering from the candidate resource set based on the current access control policy and the real-time status of the backend resources; the backend resource list is sent to the intelligent agent, which then generates a resource invocation request based on the backend resource list and the current task request; the resource invocation request sent by the intelligent agent is received, and the corresponding backend resources are invoked to execute the current task request. This solution improves the accuracy of resource matching and the success rate of invocation.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, particularly to cloud computing, artificial intelligence and other fields, and can be used in application scenarios such as intelligent agent resource mobilization. Specifically, it relates to a resource mobilization method, device and electronic device for artificial intelligence scenarios. Background Technology

[0002] In various information systems, cloud platforms, and intelligent service systems, there are typically numerous backend resources available for external tasks to invoke. These backend resources collectively constitute the system's fundamental capabilities for data processing, business execution, and functional collaboration. In related technologies, to enable external applications, automated programs, or intelligent agents to access these backend resources, they are usually encapsulated and exposed through Application Programming Interfaces (APIs), service gateways, resource proxies, or other invocation channels. Predefined description files or invocation rules specify the resource access methods, input / output requirements, and execution result return formats, thereby enabling the invocation and management of backend resources.

[0003] However, with the rapid development of intelligent agent technology, the task requests submitted by intelligent agents are often dynamic, ambiguous, and complex. Existing resource access methods based on fixed API calls are unable to understand the semantic meaning of task requests and cannot dynamically match the most suitable backend resources according to semantics. At the same time, traditional access control policies are mostly statically configured and cannot be dynamically filtered in combination with the real-time status of backend resources (such as load, availability, response latency, etc.), resulting in low efficiency and insufficient accuracy of resource calls, and even call failures due to resource overload or permission mismatch. Summary of the Invention

[0004] This disclosure provides a resource retrieval method, apparatus, and electronic device for artificial intelligence scenarios.

[0005] According to a first aspect of this disclosure, a resource invocation method for artificial intelligence scenarios is provided, applied to the resource end, comprising: responding to a current task request submitted by an intelligent agent, obtaining a current access control policy and a real-time status of backend resources; the current access control policy includes at least the permission information of the intelligent agent; generating a candidate resource set related to the current task request based on the semantic information of the current task request and the description information of the backend resources; filtering a backend resource list from the candidate resource set based on the current access control policy and the real-time status of the backend resources; sending the backend resource list to the intelligent agent, so that the intelligent agent generates a resource invocation request based on the backend resource list and the current task request; receiving the resource invocation request sent by the intelligent agent, and invoking the corresponding backend resources according to the resource invocation request to execute the current task request.

[0006] According to a second aspect of this disclosure, a resource invocation method for artificial intelligence scenarios is provided, applied to a client, comprising: sending a current task request; receiving a backend resource list, and generating a resource invocation request based on the backend resource list and the current task request; and sending the resource invocation request.

[0007] According to a third aspect of this disclosure, a resource invocation device for artificial intelligence scenarios is provided, applied to a resource end, comprising: an information acquisition module, used to acquire the current access control policy and the real-time status of backend resources in response to a current task request submitted by an intelligent agent; the current access control policy includes at least the permission information of the intelligent agent; a set generation module, used to generate a candidate resource set related to the current task request based on the semantic information of the current task request and the description information of the backend resources; a list filtering module, used to filter a backend resource list from the candidate resource set based on the current access control policy and the real-time status of the backend resources; a list sending module, used to send the backend resource list to the intelligent agent, so that the intelligent agent can generate a resource invocation request based on the backend resource list and the current task request; and a request execution module, used to receive the resource invocation request sent by the intelligent agent and invoke the corresponding backend resources according to the resource invocation request to execute the current task request.

[0008] According to the fourth aspect of this disclosure, a resource invocation device for artificial intelligence scenarios is provided, applied to a client, comprising: a task request sending module for sending a current task request; an invocation request generation module for receiving a backend resource list and generating a resource invocation request based on the backend resource list and the current task request; and an invocation request sending module for sending the resource invocation request.

[0009] According to a fifth aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform any of the methods described in the embodiments of this disclosure.

[0010] According to a sixth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0011] According to a seventh aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0012] Using the solution disclosed herein can improve the accuracy of resource matching and the success rate of resource invocation.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0014] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating a resource retrieval method for artificial intelligence scenarios according to an embodiment of this disclosure; Figure 2 This is another flowchart illustrating a resource retrieval method for artificial intelligence scenarios according to an embodiment of the present disclosure; Figure 3 This is a schematic diagram of the process for generating a backend resource list according to an embodiment of this disclosure; Figure 4 This is a schematic diagram of the structure of a resource retrieval system according to an embodiment of the present disclosure; Figure 5 This is a timing diagram of a resource retrieval method for an artificial intelligence scenario according to an embodiment of the present disclosure; Figure 6 This is a schematic diagram of the structure of a resource retrieval device for artificial intelligence scenarios according to an embodiment of the present disclosure; Figure 7 This is another structural schematic diagram of a resource retrieval device for artificial intelligence scenarios according to an embodiment of the present disclosure; Figure 8 This is a schematic diagram of a resource retrieval method for artificial intelligence scenarios according to an embodiment of this disclosure; Figure 9 This is a schematic diagram of another scenario of a resource retrieval method for artificial intelligence scenarios according to an embodiment of the present disclosure; Figure 10 This is a structural diagram of an electronic device used to implement a resource retrieval method for artificial intelligence scenarios according to an embodiment of this disclosure. Detailed Implementation

[0015] Before introducing the technical solutions of the embodiments of this disclosure, the technical terms that may be used in this disclosure will be further explained: Backend resources: Various server-side capability units that can be used to complete the current task request, including but not limited to application programming interfaces, database services, search engines, knowledge bases, computing resources, file processing services, workflow nodes, message services, and third-party platform capabilities.

[0016] While some related technologies can achieve unified exposure and access to backend resources to a certain extent, they still have shortcomings in practical applications. On the one hand, backend resources themselves are highly dynamic, and their availability, remaining quotas, inventory quantities, load conditions, permission boundaries, and operational health may change continuously over time. Existing resource description methods are usually static and cannot reflect the real resource status in a timely manner, leading to callers, especially intelligent agents, making it easy to make incorrect decisions based on outdated information. On the other hand, existing resource access mechanisms usually focus more on call paths and parameter matching, while lacking machine-understandable expressions for the current availability of backend resources, call restrictions, and failure correction criteria. This makes it difficult for intelligent agents to accurately determine which backend resources to choose, whether the call conditions are met, and the adjustment direction after a call failure during task execution, resulting in resource matching deviations, increased repeated attempts, and a decrease in overall task execution efficiency.

[0017] In order to at least partially solve one or more of the above-mentioned problems and other potential problems, this disclosure proposes a resource invocation method for artificial intelligence scenarios, which can improve the accuracy of resource matching and the success rate of invocation.

[0018] This disclosure provides a resource invocation method for artificial intelligence scenarios, applied to the resource side. Figure 1 This is a flowchart illustrating a resource retrieval method for artificial intelligence (AI) scenarios according to an embodiment of this disclosure. This resource retrieval method for AI scenarios can be applied to a resource retrieval device for AI scenarios. The resource retrieval device for AI scenarios is located in an electronic device. The electronic device includes, but is not limited to, fixed devices and / or mobile devices. For example, fixed devices include, but are not limited to, servers, which can be cloud servers or ordinary servers. For example, mobile devices include, but are not limited to, intelligent agent resource retrieval devices, which can be mobile phones, tablets, etc. In some possible implementations, this resource retrieval method for AI scenarios can also be implemented by a processor calling computer-readable instructions stored in memory. Figure 1 As shown, this resource allocation method for artificial intelligence scenarios includes: S101. In response to the current task request submitted by the intelligent agent, obtain the current access control policy and the real-time status of backend resources.

[0019] S102. Based on the semantic information of the current task request and the description information of the backend resources, generate a set of candidate resources related to the current task request.

[0020] S103. Based on the current access control policy and the real-time status of backend resources, select a list of backend resources from the candidate resource set.

[0021] S104. Send the backend resource list to the intelligent agent so that the intelligent agent can generate a resource call request based on the backend resource list and the current task request.

[0022] S105. Receive the resource call request sent by the intelligent agent, and call the corresponding backend resources according to the resource call request to execute the current task request.

[0023] Here, an intelligent agent refers to a program entity with the ability to understand tasks, perform semantic analysis, make decisions and plans, and invoke tools or resources. A current task request refers to the description of a task to be completed submitted by the intelligent agent in the current interaction round or current execution phase. The current access control policy refers to the effective control rules that constrain the scope of resources accessible to the intelligent agent, the types of operations that can be executed, and the invocation conditions at the moment the current task request is received. The real-time status of backend resources refers to the dynamic operating information and availability information of backend resources at the current moment.

[0024] In this embodiment, upon receiving a current task request submitted by an agent, the request is first processed for access control. Then, by combining the agent's relevant information, the security context corresponding to the current task execution is determined. Subsequently, the current access control policy effective for the agent at the current moment can be parsed from the security context and preset rules. Simultaneously, a query can be initiated to obtain real-time operational data of each backend resource at the current moment, thereby forming real-time status information of the backend resources corresponding to the current task request.

[0025] In this embodiment, semantic information can be extracted from the current task request by performing semantic parsing, intent recognition, and task decomposition. Simultaneously, description information of backend resources can be read, and methods such as keyword matching, rule mapping, vector retrieval, semantic similarity calculation, knowledge graph association, or model reasoning can be used to compare the task intent expressed in the current task request with the capability descriptions of each backend resource. One or more backend resources that may functionally satisfy the current task request are selected and preliminarily sorted according to relevance, coverage, or suitability, thereby obtaining a set of candidate resources related to the current task request.

[0026] In this embodiment, based on the candidate resource set, permissions are verified item by item according to the current access control policy to determine whether the agent has the relevant permissions. Furthermore, the availability of each candidate resource at the current moment is determined based on the real-time status of the backend resources. Next, candidate resources that do not meet the permission requirements or are currently unavailable are eliminated, while those that meet the permission requirements and are currently executable are retained, thus forming a backend resource list. Specifically, for each backend resource in the backend resource list, information such as its allowed operation scope, current callable conditions, dynamic parameter constraints, quota remaining space, and priority can be further added.

[0027] Here, a resource request refers to the structured request information generated by the agent, which is used to actually trigger the execution of backend resources.

[0028] In this embodiment of the disclosure, a filtered list of backend resources can be sent to the intelligent agent. For example, the backend resource list may include resource identifiers and resource names, as well as functional descriptions, executable actions, parameter specifications, and other content corresponding to each backend resource. This allows the intelligent agent to make decisions directly based on the current task request and the backend resource list without parsing the full interface documentation. Furthermore, after receiving the backend resource list, the intelligent agent can select one or more suitable backend resources, determine the calling order and parameter content, and generate a resource calling request accordingly.

[0029] In this embodiment of the disclosure, the received resource call request can be mapped to the corresponding backend resource access endpoint based on its specified target resource identifier, thereby invoking the corresponding backend resource to execute the current task request. In particular, if the current task request involves multiple backend resources, serial calls, parallel calls, or conditional calls can be performed according to the order or dependency relationship given in the resource call request, and the execution results of each stage can be summarized, transformed, and encapsulated to finally form the execution result output of the current task request.

[0030] The technical solution of this disclosure enables the intelligent agent to process only a list of backend resources that are directly related to the current task objective and are accessible and callable at the current moment. This effectively reduces context load and resource selection difficulty, and reduces invalid calls and repeated retries caused by static document lag, changes in permission restrictions, and real-time changes in resource status. Furthermore, by introducing a dynamic filtering and list feedback mechanism before resource calls, it helps improve the accuracy of resource selection, the determinism of calls, and the success rate of task execution. It also balances access security, resource availability, and execution efficiency, thereby reducing token consumption, shortening the task completion path, and enhancing the collaboration between the intelligent agent and backend resources, ultimately improving overall execution efficiency.

[0031] In some embodiments, invoking the corresponding backend resource according to the resource invocation request to execute the current task request includes: performing a validity check on the resource invocation request based on the current access control policy and the real-time status of the backend resource; and invoking the corresponding backend resource according to the resource invocation request that has passed the validity check to execute the current task request.

[0032] In this embodiment of the disclosure, after receiving a resource call request from the intelligent agent, the request can first be parsed, and its legitimacy can be verified based on the current access control policy. For example, the access control policy can be used to determine whether the resource call request has the necessary access permissions, whether the requested operation is allowed, whether there is unauthorized access, whether the data exceeds the allowed range, and whether the currently effective call rules are met. For resource call requests that do not comply with the current access control policy, execution can be refused, and a corresponding verification failure result can be returned.

[0033] Furthermore, after completing the access control policy-based verification, the resource call request can be further verified by combining the real-time status of the backend resources. For example, the latest status information of the backend resources corresponding to the resource call request can be obtained to determine whether each required backend resource is currently available, whether the quota is sufficient, whether the inventory is sufficient, or whether other dynamic conditions are met. Specifically, if a resource call request meets the access control policy in terms of permissions, but cannot be executed because the backend resource is currently unavailable, the quota is insufficient, the inventory is insufficient, or the dynamic conditions are not met, then the resource call request is determined to have failed the validity verification, and the call to the corresponding backend resource is terminated.

[0034] In this embodiment of the disclosure, for a resource call request that passes the validity check, the corresponding backend resource can be called to execute the current task request based on the target backend resource and operation intent indicated in the request.

[0035] Therefore, by combining the current access control policy with the real-time status of backend resources to perform a second validity check on resource call requests, erroneous execution caused by changes in permissions or resource status can be effectively avoided. Furthermore, by only initiating actual resource calls on resource call requests that pass the validity check, the security, accuracy, and determinism of resource calls can be significantly improved, reducing unnecessary retries and resource waste.

[0036] In some embodiments, before invoking the corresponding backend resource according to the resource invocation request, the method further includes: determining the interface operation corresponding to each backend resource based on the current task request and the backend resource list; classifying the intent of each interface operation and determining the risk level of each interface operation based on the intent classification result; when the risk level of any interface operation is high risk, sending a negotiation instruction to the agent so that the agent can perform negotiation processing according to the current task request, and generating an updated task request based on the negotiation processing result, and using the updated task request as the current task request.

[0037] Here, interface operation refers to the specific operational actions provided by backend resources, which can be actually triggered and executed. In this embodiment of the disclosure, interface operation can be the specific manifestation of backend resource capabilities at the invocation level. Negotiation instruction refers to the control instruction issued to the agent when a high-risk interface operation is identified during the current task execution process, which can be used to instruct the agent to execute the negotiation process.

[0038] In this embodiment, the interface operation corresponding to each backend resource can first be determined based on the current task request and the backend resource list. Then, the task intent expressed in the current task request can be matched item by item with the executable capabilities of each resource in the backend resource list, thereby determining one or more interface operations that may be used for each backend resource. Further, after determining the interface operations, each interface operation can be classified by intent, and the risk level of each interface operation can be determined based on the intent classification results. For example, a risk determination rule base or risk assessment model can be pre-built, and factors such as the intent category of the interface operation, resource sensitivity level, data impact scope, execution reversibility, required permission level, number of target objects, and whether cross-system propagation is involved can be comprehensively considered to determine the corresponding risk level for each interface operation.

[0039] In this embodiment of the disclosure, when the risk level of any interface operation is determined to be high-risk, a negotiation instruction can be sent to the agent to trigger the agent to perform negotiation processing on the current task request. After receiving the negotiation instruction, the agent can perform negotiation processing according to the current task request. After obtaining the negotiation processing result, the agent can reorganize the task description based on the confirmed execution intent, constraints, authorization information, or alternative solutions, generate an updated task request, and overwrite the original current task request with the updated task request to continue executing subsequent resource determination, resource call request generation, or backend resource call processes.

[0040] In this way, high-risk behaviors can be identified before execution, and when high-risk interface operations are detected, negotiation instructions can be sent to the agent to guide the agent to execute the negotiation process, which can effectively improve the security, controllability and compliance of the backend resource call process.

[0041] In some embodiments, before invoking the corresponding backend resource according to the resource invocation request, the method further includes: when the risk level of any interface operation is high risk, performing a no-run verification according to the current task request, and sending the verification result to the intelligent agent, so that the intelligent agent can generate an updated task request according to the verification result, and use the updated task request as the current task request.

[0042] Here, "empty run verification" refers to the process of simulating and refining the operation to be executed for the current task request without actually triggering the corresponding backend resources or making any substantial changes to the real business data, business status, or system resources.

[0043] In this embodiment, a shadow environment corresponding to the current task request can be constructed based on the current task request and the identified high-risk interface operations and their corresponding backend resources. The data, configuration, and structure in the shadow environment are consistent with or approximately mapped to the real environment, at least within the scope relevant to the current task request. Subsequently, the current task request can be validated in the shadow environment to obtain the expected impact and estimated cost after simulated execution, and the expected impact and estimated cost are then compiled to obtain the validation result. Exemplarily, the validation in the shadow environment includes at least one of the following: checking the completeness and legality of parameters in the current task request; checking the execution permissions corresponding to the current task request; checking the real-time status of the corresponding backend resources; checking the business rules that high-risk interface operations may trigger; calling the corresponding backend resources in the shadow environment according to the current task request to obtain a virtual execution result; and analyzing the virtual execution result to determine the expected impact and estimated cost. Further, after receiving the validation result, the agent can modify, supplement, or reconstruct the current task request based on the validation result to generate an updated task request. Finally, the updated task request can overwrite the original current task request.

[0044] In this way, execution risks can be identified in advance before high-risk operations actually trigger the corresponding backend resources, enabling the intelligent agent to make targeted corrections to the task request based on the verification results, thereby improving the clarity of the task request, the security of resource calls, and the controllability of the execution process.

[0045] In some embodiments, each interface operation is classified by intent, and the risk level of each interface operation is determined based on the intent classification result, including: extracting the intent semantics corresponding to each interface operation; classifying each interface operation into a preset semantic type based on the intent semantics; and determining the risk level corresponding to each interface operation based on the semantic type through a preset risk mapping relationship.

[0046] Here, intent semantics refers to the semantic expression of the actual execution intent, behavioral nature, or business objective embodied in the interface operation. Risk mapping relationship refers to the correspondence rules, mapping tables, decision models, or judgment logic used to map different semantic types to corresponding risk levels.

[0047] In this embodiment, the intent semantics corresponding to each interface operation can be extracted first. For example, for interface operations corresponding to backend resources, intent semantics reflecting the execution essence can be extracted from the explicit description and implicit features of the interface operation through methods such as keyword matching, semantic tag recognition, rule parsing, natural language understanding models, vector semantic matching, knowledge graph reasoning, or historical sample learning. Subsequently, the intent semantics can be matched with each type definition in a preset semantic type to determine the semantic type to which each interface operation belongs. For example, a rule-based classification method or a classification model can be used to automatically classify the interface operations and output the corresponding semantic type label and its confidence level to adapt to the diverse expression forms and inconsistent description methods of interface operations under different backend resource scenarios. Finally, a pre-established risk mapping relationship can be searched to map the semantic type to which the interface operation belongs to the corresponding risk level.

[0048] In this way, the risk misjudgment caused by non-standard interface naming, inconsistent expression of different backend resources, or bias in understanding based only on surface information by intelligent agents can be effectively reduced, thereby improving the accuracy, stability and interpretability of risk operation identification, and providing a more reliable basis for subsequent negotiation processing, empty run verification, approval control and resource call security protection.

[0049] In some embodiments, the preset semantic types include at least one of the following: acquisition type, computation type, transaction type, communication type, and orchestration type. Based on the semantic type, a risk level corresponding to each interface operation is determined through a preset risk mapping relationship, including: when the semantic type is transaction type, the risk level of the corresponding interface operation is determined to be high risk.

[0050] In this embodiment of the disclosure, when classifying the intent of interface operations, a set of semantic types for risk identification can be pre-established. The pre-defined semantic types include at least one of the following: acquisition, calculation, transaction, communication, and orchestration. Specifically, the acquisition semantic type is used to characterize interface operations whose primary purpose is to query, read, retrieve, pull, browse, or extract information; the calculation semantic type is used to characterize interface operations whose primary purpose is to perform calculations, analysis, reasoning, evaluation, transformation, summarization, or model processing; the transaction semantic type is used to characterize interface operations involving fund transfers, asset allocations, order confirmations, payment settlements, equity changes, resource purchases, account deductions, or other operations that can cause changes in the actual business status, asset status, or equity relationships; the communication semantic type is used to characterize interface operations involving message sending, notification pushes, email delivery, SMS delivery, external interface feedback, or other information transmission to external objects; and the orchestration semantic type is used to characterize interface operations that organize, schedule, control in series and parallel, control conditional branches, or advance processes for multiple interface operations, multiple backend resources, or multiple processing stages.

[0051] In some embodiments, after identifying an interface operation as a transaction-related operation, the operation can be directly marked as a high-risk operation based on a preset risk mapping relationship, and the risk assessment result can be written into the risk analysis result of the current task request. Specifically, for transaction-related interface operations, the operation can also be marked as a high-risk operation if preset conditions are met. For example, preset conditions may include amounts exceeding a threshold, sensitive fields, sensitive operations, sensitive interfaces, etc.

[0052] This allows for the rapid identification of highly sensitive operations that may cause changes in the actual business status, asset rights, or critical resources before backend resources are actually invoked, thus avoiding misjudgments caused by relying solely on interface names or superficial parameters for risk assessment. It improves the accuracy and interpretability of identifying high-risk interface operations, enhances the security, controllability, and compliance of the resource invocation process, and reduces the risk of business losses due to erroneous execution of transaction-related operations.

[0053] In some embodiments, a no-load verification is performed based on the current task request, and the verification result is sent to the intelligent agent. The intelligent agent then generates an updated task request based on the verification result and uses the updated task request as the current task request. This includes: constructing a virtual execution state in an isolated virtual environment based on the current system state, the current task request, and a backend resource list; in the virtual execution state, calling the corresponding backend resources in the backend resource list to execute the current task request and generating a virtual execution result; verifying the current task request based on the virtual execution result and generating a verification result; when the verification result indicates that the current task request needs to be adjusted, sending the verification result to the intelligent agent, which then generates an updated task request based on the verification result and uses the updated task request as the current task request.

[0054] Here, the current system state refers to a set of state information that reflects the actual situation of the current operating environment and business environment. In this embodiment of the disclosure, the current system state characterizes the actual state of various internal and external resources, data objects, and execution conditions, so as to make the subsequently constructed simulated execution environment as close as possible to the real execution scenario. The isolated virtual environment refers to a pre-execution environment isolated from the real execution environment and capable of transaction rollback. The virtual execution state refers to the simulated running state constructed in the isolated virtual environment based on the current system state, the current task request, and the backend resource list.

[0055] In this embodiment, current system state information related to the current task request can be collected or acquired first. Then, combined with the current task request and the backend resource list, relevant resources, objects, and execution contexts are mapped and initialized in an isolated virtual environment to form a virtual execution state matching the current task request. Subsequently, based on the task content indicated by the current task request, the target backend resources and their interface operations related to the task request can be determined from the backend resource list. In the isolated virtual environment, the corresponding backend resources are simulated and called according to the call order, parameter passing relationship, and business logic constraints corresponding to the real execution process, thereby obtaining a virtual execution result corresponding to the current task request. For example, this simulated call can be implemented using methods such as interface simulation, read-only call, mirror data processing, transaction pre-execution rollback, rule deduction, or result prediction to make the execution process in the virtual environment logically reproduce the real execution process as much as possible.

[0056] Furthermore, the virtual execution results can be compared and analyzed with preset verification rules to generate verification results. These verification results can determine whether the current task request is suitable for entering the actual execution stage. For example, the preset verification rules may include at least one of the following: verifying whether the current task request has issues such as missing parameters, unclear objects, excessively large scope, or unreasonable execution order; verifying whether the current task request triggers restrictions such as insufficient permissions, unavailable resources, state conflicts, business rule conflicts, or insufficient quotas during virtual execution; verifying whether the impact range shown by the virtual execution results exceeds a preset threshold; and verifying whether the current task request may cause undesirable business consequences, abnormal propagation, or high-risk state changes after simulated execution. Finally, when the verification results indicate that the current task request needs adjustment, the abnormal information in the verification results can be sent to the intelligent agent, allowing the agent to make targeted corrections to the current task request based on the verification results. After generating an updated task request, the updated task request can overwrite the original current task request.

[0057] This can improve the security, controllability, and stability of high-risk task processing, while also enhancing the pertinence and basis of task request adjustments, improving the accuracy of the agent in generating subsequent task requests, and reducing system risks and business losses caused by misoperation, unauthorized calls, and irreversible business changes.

[0058] In some embodiments, the resource invocation method for artificial intelligence scenarios further includes: determining error information based on log information or virtual execution results during the execution of the current task request; performing attribution analysis on the error information to determine error characteristics; generating a repair instruction based on the error characteristics and sending the repair instruction to the intelligent agent; receiving the updated task request returned by the intelligent agent based on the repair instruction, and using the updated task request as the current task request.

[0059] Here, log information refers to procedural information used to record the execution status and results during the execution of the current task request. Error characteristics refer to the feature information extracted after attribution analysis of error information, which can characterize the essential attributes, triggering conditions, scope of impact, or direction of repair of the error. Repair instructions refer to the instruction information used to guide the agent to modify, supplement, reconstruct, or replace the current task request.

[0060] In this embodiment, after the current task request enters the execution phase, process log information corresponding to the task request can be continuously collected, or the corresponding virtual execution result can be directly obtained when the current task request undergoes a no-load verification. Subsequently, the log information or virtual execution result can be parsed to identify exception markers, failure returns, conflict prompts, timeout information, or rule hit results, thereby determining the error information related to the current task request. Specifically, the error information can be a single error or a combination of multiple errors, and can include the time, location, object, context, and related interface link information of the error occurrence. Further, after determining the error information, semantic parsing, pattern matching, and causal inference can be performed on the error information based on preset error attribution rules, error knowledge bases, log pattern recognition models, causal chain analysis models, or historical fault samples to identify the actual source and essential cause of the error, thereby extracting error features from the original error information that can be used for subsequent repair. After determining the error features, corresponding repair actions can be selected from a preset repair strategy library based on the currently identified error features, or repair instructions can be formed and sent to the intelligent agent through rule generation, template filling, inference generation, etc. After receiving the repair instruction, the agent can modify, supplement, or reconstruct the current task request based on the repair instruction, and overwrite the original current task request with the updated task request.

[0061] This can effectively improve the accuracy and efficiency of task request repair, reduce resource waste and system burden caused by repeated trial and error, reduce business risks caused by the continuous execution of erroneous requests, and enhance the robustness, continuity and adaptive optimization capabilities of the entire resource call process.

[0062] In some embodiments, attribution analysis of error messages includes: determining the target backend resource and target interface operation where the error occurred based on the error message; determining error characteristics based on the target backend resource and target interface operation; the error characteristics include at least conflict parameters related to the error message.

[0063] Here, the target backend resource refers to the backend resource that corresponds to the error message and is determined to have caused an error, triggered an error, or is directly related to the error result. The target interface operation refers to the interface operation that is actually called on the target backend resource and directly corresponds to the error message.

[0064] In this embodiment, after identifying the error message, the error message can first be located and analyzed. Then, based on the information carried in the error message and the resource call chain corresponding to the current task request, the backend resource directly associated with the error message can be determined and identified as the target backend resource. Specifically, the resource node most likely to cause the error can be located through call chain backtracking, exception propagation path analysis, request context mapping, or resource dependency inference, and this resource node can be identified as the target backend resource. Further, various interface operations associated with the target backend resource can be extracted, and the interface operation that actually triggered the error can be determined based on the error message. In particular, if the error message involves the linkage effect of multiple interface operations, the interface operation most directly related to the error result and having a decisive role in the formation of the error can be selected as the target interface operation according to the preset main cause determination rules.

[0065] After identifying the target backend resources and target interface operations, standard information related to these resources and operations can be retrieved and compared with error messages to identify the specific causes of the errors and thus obtain error characteristics. These error characteristics include at least conflicting parameters related to the error messages. Conflicting parameters refer to parameters that are incompatible, mismatched, unsatisfied, or contradictory to other parameters during the execution of the target interface operation. For example, conflicting parameters can be extracted from error messages through methods such as interface parameter rule validation, parameter semantic consistency analysis, object state comparison, constraint matching, historical error pattern recognition, or causal reasoning analysis. Specifically, error characteristics may also include error type, error location, target backend resource status characteristics, and permission or business rule constraint characteristics.

[0066] In this way, error messages that were originally just superficial descriptions of anomalies can be further refined into structured attribution results that are specific to specific resources, operations, and parameters, thereby significantly improving the accuracy of error localization and the relevance of the repair basis.

[0067] In some embodiments, generating a repair instruction based on error characteristics includes: extracting corresponding parameter constraint information and compliance examples from a metadata repository based on the error characteristics; constructing correction logic based on the difference between the current task request and the parameter constraint information; constructing a valid example based on the compliance example; determining the corresponding suggested action based on the correction logic and the valid example; constructing a structured feedback object based on the correction logic, the valid example, and the suggested action; and using the structured feedback object as a repair instruction.

[0068] Here, the metadata repository refers to a data management repository used to maintain basic descriptive information related to backend resources. Parameter constraint information refers to rule information associated with the target backend resource or target interface operation, used to limit the legality and executability of parameters. Compliance examples refer to specific task request examples that conform to parameter constraint information, business rules, and resource invocation requirements.

[0069] In this embodiment, parameter constraint information and compliance examples matching the error characteristics can be extracted from the metadata repository. Specifically, candidate rules and examples in the metadata repository can be filtered and sorted in conjunction with the current task request to extract the parameter constraint information and compliance examples most relevant to the current error scenario. Subsequently, the existing content in the current task request can be compared item by item with the legal requirements specified in the parameter constraint information to identify inconsistencies. After identifying the differences, these differences can be transformed into executable correction rules and organized into correction logic. For example, the correction logic can explicitly indicate which parameters need to be supplemented, which parameter values ​​need to be modified, which parameters need to be deleted, which parameter combinations need to be reorganized, and under what preconditions execution can continue. Specifically, the constructed correction logic can be subjected to secondary verification using parameter constraint information to ensure that the correction logic conforms to the constraints. Furthermore, one or more samples most similar to the current task request scenario can be selected from multiple compliance examples, retaining the core parts that reflect the correct parameter structure, correct parameter value method, and correct calling relationship, thereby forming an effective example applicable to the current error scenario.

[0070] After constructing the correction logic and valid examples, suggested actions can be dynamically generated based on the pre-established mapping relationship between correction logic types and suggested actions, or based on rule-based reasoning. When the correction logic indicates missing parameters, the suggested action can be to supplement the specified parameters; when the correction logic indicates invalid parameter values, the suggested action can be to replace them with valid values; when the correction logic indicates that the task scope is too large or the target object is unclear, the suggested action can be to narrow the scope, add filtering conditions, or split the task steps; when the correction logic indicates that the call path does not match or the resource status is not satisfied, the suggested action can be to adjust the execution order, change the interface operation, switch backend resources, or supplement pre-validation. In particular, for determined suggested actions, secondary validation can be performed using the correction logic and valid examples to ensure that the suggested actions comply with constraints.

[0071] After determining the corresponding suggested actions, a structured Executable Feedback Object (EFO) can be constructed based on the correction logic, valid examples, and suggested actions. This structured feedback object serves as the repair instruction. Specifically, the EFO may include error location information, error characteristic information, parameter constraint summary, a description of the differences between the current task request and the constraints, a description of the correction logic, valid example content, and suggested action content. Then, after sending this structured feedback object as a repair instruction to the agent, the agent can modify, supplement, or reconstruct the current task request based on the structured rules, reference examples, and suggested actions contained within it, generating an updated task request that overwrites the original current task request.

[0072] In this way, by integrating the correction logic, effective examples, and suggested actions into a structured feedback object as a repair instruction, the originally scattered error causes, rule requirements, and repair experience can be uniformly organized into an executable, interpretable, and reusable repair basis.

[0073] In some embodiments, a candidate resource set related to the current task request is generated based on the semantic information of the current task request and the description information of the backend resources, including: obtaining description information corresponding to multiple backend resources; parsing the current task request to determine the semantic information of the current task; traversing the description information and determining the candidate resource set based on the matching result between the semantic information of the current task and the description information.

[0074] In this embodiment, descriptive information corresponding to multiple backend resources can be obtained first. For example, the descriptive information may include resource name, resource function description, interface capability description, supported business object types, executable operation categories, input / output parameter characteristics, applicable scenarios, permission requirements, call restrictions, tag information, and semantic keywords. Subsequently, semantic analysis can be performed on the current task request to extract key information reflecting the task intent. For example, the current task semantic information may include task objective, operation type, target object, constraints, time range, execution scope, priority, and semantic tags related to the business scenario. Next, the current task semantic information can be compared one by one with the descriptive information of each backend resource to determine the degree of matching in terms of functional semantics, operational semantics, object semantics, scenario semantics, and constraint semantics. For example, the matching process can be implemented based on keyword matching, tag matching, rule matching, vector similarity calculation, semantic retrieval model reasoning, or a combination thereof. When the matching result between the descriptive information of a certain backend resource and the semantic information of the current task meets preset conditions, the corresponding backend resource can be included in the candidate resource set.

[0075] In this way, a correspondence can be established between the semantic intent in the user's task request and the backend resource capabilities, thereby avoiding the problem of insufficient adaptation caused by relying solely on fixed mapping relationships or manual specification.

[0076] In some embodiments, a backend resource list is obtained by filtering from a candidate resource set based on the current access control policy and the real-time status of backend resources, including: projecting permissions onto the candidate resource set according to the current access control policy to obtain a subset of available resources; and dynamically pruning the subset of available resources according to the real-time status of backend resources to obtain a list of backend resources.

[0077] In this embodiment, permissions are first verified for each backend resource in the candidate resource set according to the current access control policy. For example, the actual access permissions possessed by the agent in the current task scenario can be mapped onto the candidate resource set to identify which candidate resources can be accessed, invoked, or operated under the current conditions. Backend resources that meet the access control policy requirements are retained in the available resource subset; those that do not meet the permission requirements are removed from the candidate resource set. Subsequently, the real-time status of the backend resources is compared with preset resource availability judgment rules, and each backend resource in the available resource subset is evaluated item by item. When a backend resource passes the permission verification but is currently unavailable, abnormal, overloaded, rate-limited, under maintenance, or does not meet the current task's timeliness requirements, the backend resource can be pruned from the available resource subset; backend resources that are running normally, meet performance requirements, and have the conditions for invocation are retained. In particular, priority sorting or multi-dimensional scoring mechanisms can be introduced during the dynamic pruning process. For example, if multiple backend resources meet the permission and real-time status requirements, the retained backend resources can be further sorted based on response speed, historical success rate, resource stability, call cost, or business priority to form a backend resource list that is more suitable for subsequent scheduling.

[0078] In this way, both authorization compliance and operational availability can be taken into account during the resource screening process, thereby avoiding the inclusion of resources that are not authorized to be accessed or currently unavailable in the scope of subsequent calls.

[0079] In some embodiments, the candidate resource set is projected with permissions according to the current access control policy to obtain an available resource subset, including: obtaining the access rule corresponding to each backend resource in the candidate resource set; traversing the access rules and determining the available resource subset based on the matching result between the permission information and the access rules.

[0080] Here, access rules refer to predefined or dynamically activated access constraints for a specific backend resource, which limit what kind of subject can perform what type of access or operation on the backend resource under what conditions.

[0081] In this embodiment, the access rules corresponding to each backend resource in the candidate resource set can be obtained first. The access rule information for each backend resource can be retrieved based on the candidate resource set, and a mapping relationship between resources and access rules can be established. For example, the access rules can be statically configured rules or dynamically generated or loaded rules based on the current time, current environment state, organizational structure changes, approval results, or risk strategies. Subsequently, the permission information can be matched against the access rules corresponding to each backend resource in the candidate resource set one by one. If the access rule corresponding to a backend resource matches the current permission information, it indicates that the current executing entity has the right to access the backend resource in the current scenario, and the backend resource can be retained; if the match fails, the backend resource is excluded from the candidate resource set. Specifically, when traversing access rules, multi-level access rules can be processed according to a preset priority. For example, when the same backend resource has global rules, tenant-level rules, organization-level rules, and resource-level rules simultaneously, the final effective access rule can be determined comprehensively based on rule priority, top-down inheritance relationship, or conflict resolution mechanism, and permission matching can be performed accordingly. In particular, if a backend resource corresponds to multiple interface operations, the access rule matching can be further refined to the interface level or operation level to improve the accuracy of the process of determining the subset of available resources.

[0082] In this way, the abstract access control policy can be concretely implemented on each backend resource in the candidate resource set, so that the resource selection process is based on clear and verifiable permission criteria.

[0083] In some embodiments, dynamically pruning the available resource subset based on the real-time status of backend resources to obtain a backend resource list includes: determining the available resource status corresponding to each backend resource in the available resource subset based on the real-time status of backend resources; determining the current availability of each backend resource in the available resource subset based on the available resource status; and adding backend resources whose current availability meets preset conditions to the backend resource list.

[0084] In this embodiment, real-time status information of each backend resource in the available resource subset can be obtained, summarized, standardized, and mapped to generate a corresponding available resource status for each backend resource. Subsequently, based on pre-defined availability judgment rules or scoring mechanisms, different types of available resource statuses can be mapped to different levels of current availability results, such as callable, cautiously callable, degraded callable, or uncallable. Specifically, multiple status indicators can be weighted and calculated to form an availability score reflecting the resource's real-time service capability, and the score can be used to determine whether the resource meets subsequent call requirements. Further, after determining the current availability of each backend resource, backend resources whose current availability meets preset conditions can be added to the backend resource list. For example, the preset conditions can be binary judgment conditions, threshold conditions, level conditions, or a combination of conditions. Backend resources that do not meet the preset conditions can be removed; backend resources that meet the preset conditions are retained in the backend resource list. Specifically, before adding backend resources to the backend resource list, backend resources that meet the conditions can be sorted according to availability score, stability indicators, historical success rate, or response performance to make the subsequent resource selection and scheduling process more efficient.

[0085] In this way, the real-time operation status of resources can be incorporated into the screening process, so that the backend resources that are ultimately retained are not only legally accessible at the permission level, but also have actual callability at the operational level.

[0086] In some embodiments, before sending the backend resource list to the agent, the method further includes: comparing the list capacity occupied by the backend resource list with the window capacity of the agent; when the list capacity exceeds the window capacity, performing adaptive compression on the backend resource list to generate a dynamic query handle; and updating the backend resource list according to the dynamic query handle.

[0087] Here, list capacity refers to the information carrying capacity or content representation overhead occupied by the backend resource list when it is sent to the agent. It characterizes the extent to which the backend resource list occupies the input space after entering the agent's input context. Window capacity refers to the upper limit of input content that the agent can accommodate in the current interaction round, current task context, or current inference phase. Dynamic query handle refers to a structured placeholder object associated with the compressed content, used to locate, extract, or expand resource details as needed later.

[0088] In this embodiment, the backend resource list can first be converted into a format to be sent, and its corresponding character length, byte length, number of tokens, or other representation overhead can be calculated to determine the list capacity. Simultaneously, the window capacity available for the agent to receive the resource list in this task processing can also be obtained. The window capacity can be derived from the agent's preset context window parameters or dynamically calculated by the task scheduling module based on the context space already occupied in the current session. Subsequently, the list capacity is compared with the window capacity to determine whether the backend resource list can be completely loaded and transmitted to the agent.

[0089] When the comparison result indicates that the list capacity does not exceed the window capacity, the original backend resource list can be directly retained and sent to the agent, allowing the agent to perform subsequent inference, resource selection, or interface call decisions based on complete resource information. When the comparison result indicates that the list capacity exceeds the window capacity, adaptive compression is performed on the backend resource list to generate a dynamic query handle. For example, the content in the backend resource list can be selectively retained, summarized, folded, replaced, or externalized based on the current task request, resource priority, field importance, call relevance, and agent usage requirements. Furthermore, a unique corresponding dynamic query handle can be generated for resource details that are not directly retained in the list body after compression. For example, the dynamic query handle can carry a resource range identifier, task context identifier, compression batch identifier, resource category identifier, validity period information, or permission verification information, thereby ensuring that when the agent or intermediate control module subsequently calls the handle, it can recover, query, or supplement relevant resource content within the correct context. Next, some lengthy, low-frequency, or extended detail fields in the original backend resource list can be replaced with corresponding dynamic query handle descriptions. The updated backend resource list will retain necessary main resource entries, core summary information, and handle reference relationships. Specifically, the compression strategy can be dynamically adjusted based on different agent types, task complexities, or dialogue rounds. For example, for scenarios requiring rapid response, the compression ratio can be increased, retaining only the most essential candidate resource summaries; for high-precision decision-making scenarios, the compression ratio can be appropriately reduced, and more fine-grained dynamic query handles can be generated so that the agent can gradually expand the detailed information.

[0090] In this way, the process of transmitting resource information can be adapted to the context carrying capacity of the agent, thereby avoiding problems such as input truncation, key information coverage, excessive inference burden, or decreased response performance caused by excessively long resource lists.

[0091] This disclosure provides a resource invocation method for artificial intelligence scenarios, applied to a client-side application. Figure 2This is a flowchart illustrating a resource retrieval method for artificial intelligence (AI) scenarios according to an embodiment of this disclosure. This resource retrieval method for AI scenarios can be applied to a resource retrieval device for AI scenarios. The resource retrieval device for AI scenarios is located in an electronic device. The electronic device includes, but is not limited to, fixed devices and / or mobile devices. For example, fixed devices include, but are not limited to, servers, which can be cloud servers or ordinary servers. For example, mobile devices include, but are not limited to, intelligent agent resource retrieval devices, which can be mobile phones, tablets, etc. In some possible implementations, this resource retrieval method for AI scenarios can also be implemented by a processor calling computer-readable instructions stored in memory. Figure 2 As shown, this resource allocation method for artificial intelligence scenarios includes: S201, Send the current task request.

[0092] S202. Receive the backend resource list and generate a resource call request based on the backend resource list and the current task request.

[0093] S203, Send a resource request.

[0094] In this embodiment of the disclosure, when a user input instruction is received, the intelligent agent can receive the input content and organize it into a current task request. Subsequently, the current task request can be encapsulated to form a standardized request message and sent to the resource end.

[0095] In this embodiment of the disclosure, the backend resource list can be parsed first, and then the backend resource list can be jointly analyzed with the current task request. Backend resources with high semantic matching degree, accessible permissions and available current status can be selected from the backend resource list. Combined with the current task request, the interface name, operation type, input parameters, return requirements and execution order to be called are determined, thereby forming a structured resource call request.

[0096] In this embodiment of the disclosure, the resource call request can be encapsulated to form a standardized request message and sent to the resource end.

[0097] The technical solution of this disclosure can effectively connect user task requirements, resource selection results, and actual resource invocation actions, thereby forming a complete closed-loop processing link from task proposal to resource execution. By automatically mapping the original task request into structured invocation instructions for specific backend resources, the complexity of resource selection and invocation parameter assembly is reduced. Moreover, it can fully utilize the accessible and available resource information already selected in the backend resource list, improving the accuracy of resource selection and the success rate of invocation execution.

[0098] In some embodiments, the resource invocation method for artificial intelligence scenarios further includes: in response to receiving a negotiation instruction, generating corresponding proposal information based on the current task request and the backend resource list, and interacting with the negotiation object using the proposal information; the proposal information includes at least one of the following: invocation target, resource requirements, constraints, and expected results; when receiving adjustment feedback from the negotiation object, adjusting the proposal information according to the adjustment feedback, and interacting with the negotiation object based on the adjusted proposal information; when receiving acceptance feedback from the negotiation object, generating an updated task request based on the proposal information corresponding to the acceptance feedback, and interacting with the negotiation object based on the updated task request; when receiving confirmation feedback from the negotiation object, using the updated task request as the current task request; and sending the current task request.

[0099] Here, proposal information refers to the negotiation content carrier generated by the intelligent agent based on the current task request and backend resource list during the negotiation process and sent to the negotiation object. It is used to express the initial execution plan, resource configuration plan, or task achievement path of a task to be negotiated. In this embodiment of the disclosure, proposal information includes at least one of the following: invocation target, resource requirements, constraints, and expected results. The invocation target indicates the business purpose to be achieved or the target capability to be invoked; the resource requirements indicate the type, quantity, or capability of the backend resources required to complete the task; the constraints indicate the permissions, time limits, costs, order, dependencies, quality requirements, or security requirements that must be met during task execution; and the expected results indicate the business outcome expected to be achieved through negotiation. Adjustment feedback refers to the adjustment opinions proposed by the negotiation object after receiving the proposal information. Acceptance feedback refers to the feedback information indicating that the negotiation object accepts a certain version of the proposal information, indicating that the negotiation object agrees to proceed with the subsequent task execution according to that version of the proposal information. Confirmation feedback refers to the feedback information indicating that the negotiation object makes a final confirmation after receiving the updated task request. The negotiation object refers to the object that participates in the negotiation process and can respond to the proposed information. It can be a user, a collaborative intelligent agent, a scheduling system, or other entities that can participate in task negotiation.

[0100] In this embodiment of the disclosure, upon receiving a negotiation instruction, corresponding proposal information can be generated based on the current task request and the backend resource list, and the proposal information can be used to interact with the negotiation object. For example, when generating the proposal information, the current task request can first be parsed, and then combined with the backend resource list to form a candidate execution plan for the negotiation object, which serves as the proposal information. Subsequently, the proposal information can be sent to the negotiation object for evaluation and response.

[0101] If the negotiation partner returns adjustment feedback, the proposed information can be adjusted based on the feedback, and the adjusted proposed information can be used to interact with the negotiation partner. For example, the adjustment feedback can be semantically or structurally parsed to identify the adjustment items involved, and the corresponding fields in the original proposed information can be modified accordingly. After the adjustment is completed, a new version of the proposed information can be generated and sent to the negotiation partner again for the next round of interaction. This allows for a multi-round iterative negotiation process until the negotiation partner returns acceptance of the proposed information, a preset number of rounds is reached, or a preset stop time is reached.

[0102] Upon receiving feedback from the negotiation partner accepting the proposal, an updated task request can be generated based on the proposal information corresponding to the acceptance feedback. The updated task request is then used to interact with the negotiation partner. For example, the proposal information accepted by the negotiation partner can be used as the basis for revising the task request, replacing, supplementing, refining, or reorganizing relevant content in the original task request to form an updated task request. Subsequently, the updated task request can be sent to the negotiation partner for final confirmation.

[0103] Upon receiving confirmation feedback from the negotiation partner, the updated task request can be used as the current task request and sent. For example, the original current task request can be replaced with this updated task request and used as formal input in subsequent resource invocation processes. Afterward, the current task request can be sent to the resource provider according to the established resource invocation process.

[0104] In this way, task requests can be fully evaluated, modified, and confirmed by the negotiating parties before entering the formal resource invocation chain, thereby making the final task requests more in line with the actual resource capabilities, execution conditions, and constraints of the negotiating parties.

[0105] In some embodiments, the resource invocation method for artificial intelligence scenarios further includes: receiving a verification result, which is obtained by performing a no-load verification in an isolated virtual environment based on the current task request; generating an updated task request based on the verification result and the current task request, and using the updated task request as the current task request; and sending the current task request.

[0106] In this embodiment of the disclosure, after receiving the verification result, the result can be parsed to identify anomalies indicating problems with the task request. Subsequently, based on the information returned in the verification result, the current task request can be completed, corrected, replaced, deleted, or reorganized. Next, the updated task request can overwrite the original current task request. Finally, the current task request can be sent to the resource end.

[0107] In this way, before officially initiating a resource call, problems such as parameter errors, resource mismatches, permission conflicts, unmet constraints, or unreasonable execution paths in the current task request can be detected in advance. Based on this, the task request can be modified and optimized in a targeted manner, thereby effectively reducing the risk of failure, anomaly, and resource waste caused by directly calling without verification.

[0108] In some embodiments, the resource invocation method for artificial intelligence scenarios further includes: receiving a repair instruction; generating an updated task request based on the repair instruction and the current task request, and using the updated task request as the current task request; and sending the current task request.

[0109] In this embodiment, upon receiving a repair instruction, the instruction can be parsed to identify its corresponding repair scope, repair object, and specific repair rules, thereby determining the parts of the current task request that need to be modified, supplemented, deleted, or reorganized. Subsequently, based on the current task request and the repair content indicated in the repair instruction, adjustments can be made to the task objective, resource requirements, calling parameters, constraints, execution order, return requirements, or context information. Next, the updated task request can overwrite the original current task request. Finally, the current task request can be sent to the resource end.

[0110] In this way, errors in the current task request can be corrected in a targeted manner before the formal resource call, making the task request more accurate, complete and in line with the actual execution requirements.

[0111] Figure 3 This illustration shows a flowchart of the process for generating a backend resource list in an embodiment of this disclosure, such as... Figure 3 As shown, this resource call method for artificial intelligence scenarios can adopt a multi-dimensional constraint fusion generation algorithm to dynamically generate an interface list that matches the current task request based on the agent's permissions, real-time resource status, economic cost constraints, and the semantics of the current task. The interface list can be a specific expression of the backend resource list at the interface operation granularity.

[0112] Specifically, the system can obtain in real-time the agent's permission information in the current task scenario, the real-time operating status of each backend resource, the economic cost constraints related to resource calls, and the task semantics corresponding to the current task request. Based on this information, candidate interfaces can be jointly processed. For example, permission projection can be performed on candidate interfaces based on access control policies to filter out a subset of legitimate interfaces that the agent has access to. Subsequently, dynamic pruning can be performed on the legitimate interface subset based on the real-time resource status. Interfaces that are currently unavailable, unstable, or do not meet execution conditions, along with their corresponding execution paths, can be removed based on the resource's real-time load, inventory status, quota balance, health status, or current availability. Furthermore, cost rationality analysis can be performed on the remaining interfaces based on economic cost constraints to avoid prioritizing interfaces with excessively high call costs, excessive resource consumption, or those that do not meet budget constraints in subsequent calls. Building upon this, and considering the window capacity of the agent, adaptive compression processing can be performed on the retained interface information. Core interface descriptions highly relevant to the current task objective are retained through semantic abstraction, while secondary parameters are implicitly encapsulated or transformed into dynamic query handles. This reduces the contextual burden and expressive complexity of the interface list, thereby generating an interface list that balances permission compliance, resource availability, cost constraints, and semantic adaptability for the agent to use for subsequent task planning and resource invocation. Specifically, economic cost constraints may include at least one of the following: resource invocation fees, token consumption, computation time costs, bandwidth usage costs, third-party service billing, budget caps, or unit task cost thresholds.

[0113] In some implementations, a closed-loop self-healing instruction generation protocol can be used to replace traditional text error reports with EFO, providing the agent with executable, interpretable and reusable repair basis when resource call anomalies or empty run verification fails.

[0114] Specifically, when backend resources return exception, failure, or conflict messages, the attribution analysis module can parse the backend error, locate the source of the error by combining the current task request, resource call chain, target backend resource, and target interface operation, and extract conflict parameters that characterize the nature of the error from the error message. Further, it can extract parameter constraint information and compliance examples corresponding to the parameter from the metadata repository. For example, parameter constraint information may include parameter format constraints, value range constraints, composite dependency constraints, regular expression constraints, or business rule constraints; compliance examples may include task request examples or parameter configuration examples that conform to interface specifications and business rules. Subsequently, correction logic can be constructed based on the differences between the current task request and the parameter constraint information, and an effective example adapted to the current error scenario can be generated by combining the compliance examples. Simultaneously, corresponding suggested actions are determined based on the correction logic. For example, suggested actions may include supplementing parameters, replacing parameter values, deleting conflicting fields, adjusting parameter combination relationships, narrowing the task scope, or switching the calling method. Finally, the correction logic, valid examples, and suggested actions can be structurally encapsulated to form a repair instruction package, which is then sent to the agent in the form of an EFO. This enables the agent to make targeted corrections, supplements, or reconstructions to the current task request based on the structured feedback object, thereby achieving closed-loop self-repair in the resource call process.

[0115] In some implementations, an intent verb classification and negotiation mechanism can be established to perform semantic hierarchical management of interface operations corresponding to backend resources and to implement pre-control of high-risk operations.

[0116] Specifically, the intent semantics of interface operations related to the current task request can be extracted, and these operations can be categorized into five major categories of metaverbs based on preset classification rules: acquisition, calculation, transaction, communication, and orchestration. The acquisition category represents interface operations that query, retrieve, or read information; the calculation category represents interface operations that analyze, reason, transform, or evaluate; the transaction category represents interface operations that cause actual changes in funds, assets, orders, rights, or business status; the communication category represents interface operations that send messages, push notifications, or transmit external information; and the orchestration category represents interface operations that organize and schedule multiple resources, multiple interfaces, or multiple processing stages. After completing the intent classification, the risk level of each interface operation can be determined based on a preset risk mapping relationship, and transaction-type interface operations are identified as high-risk operations. For high-risk operations, a "proposal-reverse offer-confirmation" negotiation process can be forcibly triggered before formal execution. This involves the intelligent agent generating a proposal containing the call target, resource requirements, constraints, and expected results based on the current task request and the backend resource list, and sending it to the negotiation partner. Upon receiving a reverse offer or adjustment feedback from the negotiation partner, the agent modifies, supplements, or reorganizes the proposal information and initiates negotiation again until acceptance and confirmation feedback are received, thus generating and confirming the updated task request. Simultaneously, before the high-risk operation enters actual execution, a virtual state projection can be constructed based on the current system state, the current task request, and the backend resource list. This allows for a virtual test run of the transaction-type operation in an isolated virtual environment to pre-assess parameter legality, resource availability, permission fulfillment, expected impact scope, and estimated costs. The current task request can then be further revised based on the test results. Through this approach, semantic recognition, negotiation confirmation, and virtual verification can be completed before the actual triggering of high-risk transaction-type interface operations, thereby improving the security, controllability, and compliance of the resource call process and reducing the risks of mis-execution and irreversible business changes.

[0117] Figure 4 A schematic diagram of the structure of the resource retrieval system in an embodiment of this disclosure is shown, such as... Figure 4 As shown, a resource invocation system architecture for intelligent agents can be constructed based on the technical solutions of this disclosure. This resource invocation system includes at least a client and a resource terminal. The client deploys an intelligent agent, and the resource terminal deploys an intelligent gateway. The intelligent gateway serves as a unified access and control hub between the intelligent agent and the backend API.

[0118] Specifically, the intelligent gateway may include a protocol interface, a semantic engine, a backend resource inventory generation module, a repair instruction generation module, a no-load verification module, and a pass-through module. The protocol interface receives handshake requests, task requests, resource call requests, and related feedback information initiated by the intelligent agent, and returns a backend resource inventory, negotiation packet, verification result, or repair instruction packet. The semantic engine connects to the protocol interface and performs semantic parsing, intent recognition, parameter understanding, and interface mapping on the task requests submitted by the intelligent agent. Based on the parsing results, it calls the backend resource inventory generation module, repair instruction generation module, no-load verification module, and pass-through module respectively. The backend resource inventory generation module dynamically filters and generates a list of resources that match the current access control policy, real-time resource status, economic constraints, and task semantics. The architecture consists of a minimal backend resource list adapted to the task objectives; a repair instruction generation module that performs attribution analysis on backend errors when execution exceptions, parameter conflicts, or rule non-compliance occur, extracts conflicting parameters, and generates an EFO-formatted repair instruction package; a no-load verification module that simulates the proposed execution request in a shadow environment before the formal execution of high-risk operations, and outputs verification results such as expected impact, scope of impact, and estimated cost; and a pass-through module that maps and forwards structured call requests to the corresponding backend API after the task request passes permission verification, semantic negotiation, and trial run verification, and receives the execution results returned by the backend API. Based on this architecture, the agent in the client interacts with the resource end through a protocol interface. Within the resource end, the semantic engine coordinates all functional modules to complete resource selection, negotiation correction, trial run verification, exception repair, and actual invocation, thus forming a closed-loop interaction link between the agent and the backend API, improving the accuracy, security, and execution success rate of resource invocation.

[0119] Figure 5 This illustration shows a timing diagram of a resource retrieval method for an artificial intelligence scenario according to an embodiment of the present disclosure, as follows: Figure 5 As shown, a standardized closed-loop calling process can be achieved through the time-series interaction between intelligent agents, intelligent gateways, and backend resources.

[0120] Specifically, in the capability handshake phase, the agent first sends a current task request to the intelligent gateway. The intelligent gateway, combining the current access control policy, real-time resource status, economic cost constraints, and task semantics, dynamically filters available backend interfaces and returns a semantically anchored list of backend resources to the agent, preferably a minimal list of interfaces matching the current task. Subsequently, in the semantic negotiation phase, the agent forms a resource call request based on the backend resource list and sends it to the intelligent gateway. If the intelligent gateway identifies a high-risk interface operation in the resource call request, it returns a negotiation instruction to the agent to guide the agent in executing the negotiation process strategy. In the execution phase, after executing the negotiation process, the agent sends the finally confirmed resource call request to the intelligent gateway. The intelligent gateway then performs a simulated operation based on the confirmed resource call request, assessing the expected impact, scope, and estimated cost of the proposed operation, and feeds back the corresponding verification results to the agent. After the agent confirms, the intelligent gateway forwards the actual instruction to the backend resources. Furthermore, during the autonomous error correction phase, if the backend resource returns the original error after actual execution, the intelligent gateway can perform attribution analysis on the error, identify conflicting parameters or failure causes, and generate a repair instruction package in EFO format. It then returns structured repair suggestions to the agent. After parsing the constraints, correction logic, valid examples, and suggested actions contained within, the agent can automatically correct the parameters, use the updated task request as the current task request, and re-initiate the request. This forms a standardized closed-loop interaction mechanism to improve the accuracy, security, and execution success rate of the agent when calling backend resources.

[0121] It should be understood that Figures 3 to 5 The schematic diagrams shown are merely illustrative and not limiting, and are scalable; those skilled in the art can use them as a basis. Figures 3 to 5 Even with various obvious changes and / or substitutions to the examples, the resulting technical solutions still fall within the scope of this disclosure.

[0122] This disclosure provides a resource allocation device for artificial intelligence scenarios, such as... Figure 6As shown, the device may include: an information acquisition module 601, used to acquire the current access control policy and the real-time status of backend resources in response to a current task request submitted by the agent; the current access control policy includes at least the agent's permission information; a set generation module 602, used to generate a set of candidate resources related to the current task request based on the semantic information of the current task request and the description information of the backend resources; a list filtering module 603, used to filter the backend resource list from the candidate resource set based on the current access control policy and the real-time status of the backend resources; a list sending module 604, used to send the backend resource list to the agent, so that the agent can generate a resource call request based on the backend resource list and the current task request; and a request execution module 605, used to receive the resource call request sent by the agent and call the corresponding backend resources according to the resource call request to execute the current task request.

[0123] In some embodiments, the request execution module 605 includes: a legality verification submodule, used to perform legality verification on resource call requests based on the current access control policy and the real-time status of backend resources; and a resource call submodule, used to call the corresponding backend resources based on resource call requests that have passed legality verification, and execute the current task request.

[0124] In some embodiments, the resource invocation device for artificial intelligence scenarios further includes: an operation determination module 606. Figure 6 (Not shown in the image), used to determine the interface operation corresponding to each backend resource based on the current task request and the backend resource list; Risk determination module 607 ( Figure 6 (Not shown in the image), used to classify the intent of each interface operation and determine the risk level of each interface operation based on the intent classification results; Negotiation instruction module 608 ( Figure 6 (Not shown in the image) is used to send a negotiation instruction to the agent when the risk level of any interface operation is high risk, so that the agent can perform negotiation processing according to the current task request, generate an updated task request according to the negotiation processing result, and use the updated task request as the current task request.

[0125] In some embodiments, the resource retrieval device for artificial intelligence scenarios further includes: an idle verification module 609 ( Figure 6 (Not shown in the image) is used to perform a no-load verification based on the current task request when the risk level of any interface operation is high risk, and send the verification result to the agent so that the agent can generate an updated task request based on the verification result and use the updated task request as the current task request.

[0126] In some embodiments, the risk determination module 607 includes: an intent extraction submodule, used to extract the intent semantics corresponding to each interface operation; an intent classification submodule, used to classify each interface operation into a preset semantic type according to the intent semantics; and a risk mapping submodule, used to determine the risk level corresponding to each interface operation according to the semantic type through a preset risk mapping relationship.

[0127] In some embodiments, the preset semantic types include at least one of the following: acquisition type, calculation type, transaction type, communication type, and orchestration type; the risk mapping submodule is used to determine the risk level of the corresponding interface operation as high risk when the semantic type is transaction type.

[0128] In some embodiments, the no-load verification module 609 includes: a virtual state construction submodule, used to construct a virtual execution state in an isolated virtual environment based on the current system state, the current task request, and the backend resource list; a virtual execution submodule, used to execute the current task request by calling the corresponding backend resources in the backend resource list in the virtual execution state and generating a virtual execution result; a virtual verification submodule, used to verify the current task request based on the virtual execution result and generate a verification result; and a no-load adjustment submodule, used to send the verification result to the intelligent agent when the verification result indicates that the current task request needs to be adjusted, so that the intelligent agent can generate an updated task request based on the verification result and use the updated task request as the current task request.

[0129] In some embodiments, the resource retrieval device for artificial intelligence scenarios further includes: an error extraction module 610 ( Figure 6 (Not shown in the image), used to determine error information based on log information or virtual execution results during the execution of the current task request; Attribution analysis module 611 ( Figure 6 (Not shown in the image), used for attribution analysis of error messages to determine error characteristics; Repair instruction module 612 ( Figure 6 (Not shown in the image) is used to generate repair instructions based on error characteristics and send the repair instructions to the agent; the attribution adjustment submodule is used to receive the updated task request returned by the agent based on the repair instructions and use the updated task request as the current task request.

[0130] In some embodiments, the attribution analysis module 611 includes: a target localization submodule, used to determine the target backend resource and target interface operation where the error occurred based on the error information; and a feature extraction submodule, used to determine error features based on the target backend resource and target interface operation; the error features include at least conflict parameters related to the error information.

[0131] In some embodiments, the repair instruction module 612 includes: a metadata extraction submodule, used to extract corresponding parameter constraint information and compliance examples from a metadata repository based on error characteristics; a correction logic submodule, used to construct correction logic based on the difference between the current task request and the parameter constraint information; a valid example submodule, used to construct valid examples based on compliance examples; a suggested action submodule, used to determine corresponding suggested actions based on the correction logic and valid examples; and an instruction construction submodule, used to construct a structured feedback object based on the correction logic, valid examples, and suggested actions, and use the structured feedback object as a repair instruction.

[0132] In some embodiments, the set generation module 602 includes: a description acquisition submodule, used to acquire description information corresponding to multiple backend resources; a semantic parsing submodule, used to parse the current task request and determine the semantic information of the current task; and a semantic matching submodule, used to traverse the description information and determine the candidate resource set based on the matching result between the semantic information of the current task and the description information.

[0133] In some embodiments, the list filtering module 603 includes: a permission projection submodule, used to project permissions onto the candidate resource set according to the current access control policy to obtain an available resource subset; and a dynamic pruning submodule, used to dynamically prune the available resource subset according to the real-time status of the backend resources to obtain a backend resource list.

[0134] In some embodiments, the permission projection submodule is used to: obtain the access rules corresponding to each backend resource in the candidate resource set; traverse the access rules, and determine the available resource subset based on the matching results between permission information and access rules.

[0135] In some embodiments, the dynamic pruning submodule is configured to: determine the available resource status corresponding to each backend resource in the available resource subset based on the real-time status of the backend resources; determine the current availability of each backend resource in the available resource subset based on the available resource status; and add backend resources whose current availability meets preset conditions to the backend resource list.

[0136] In some embodiments, the resource allocation device for artificial intelligence scenarios further includes: a capacity comparison module 613. Figure 6 (Not shown in the image), used to compare the list capacity occupied by the backend resource list with the window capacity of the agent; list compression module 614 ( Figure 6 (Not shown in the image), used to perform adaptive compression on the backend resource list and generate a dynamic query handle when the list capacity exceeds the window capacity; List update module 615 ( Figure 6 (Not shown in the image), used to update the backend resource list based on the dynamic query handle.

[0137] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0138] The resource invocation device for artificial intelligence scenarios in this embodiment of the present disclosure improves the accuracy of resource selection, the determinacy of invocation, and the success rate of task execution by introducing a dynamic filtering and list feedback mechanism before resource invocation. It can also take into account access security, resource availability, and execution efficiency, thereby reducing token consumption, shortening the task completion path, and improving the collaboration between the intelligent agent and backend resources.

[0139] This disclosure provides a resource allocation device for artificial intelligence scenarios, such as... Figure 7 As shown, the device may include: a task request sending module 701, used to send a current task request; a call request generation module 702, used to receive a backend resource list and generate a resource call request based on the backend resource list and the current task request; and a call request sending module 703, used to send the resource call request.

[0140] In some embodiments, the resource allocation device for artificial intelligence scenarios further includes: a negotiation proposal module 704. Figure 7 (Not shown in the image), used to respond to a received negotiation instruction, generate corresponding proposal information based on the current task request and the backend resource list, and interact with the negotiation object using the proposal information; the proposal information includes at least one of the following: the call target, resource requirements, constraints, and expected results; the negotiation adjustment module 705 ( Figure 7 (Not shown in the image), used to adjust the proposal information according to the adjustment feedback returned by the negotiation object when receiving the adjustment feedback, and to interact with the negotiation object according to the adjusted proposal information; Negotiation confirmation module 706 ( Figure 7 (Not shown in the image), used to generate an updated task request based on the proposal information corresponding to the acceptance proposal feedback received from the negotiation object, and to interact with the negotiation object based on the updated task request; the first request overriding module 707 ( Figure 7 (Not shown in the image), used to take the updated task request as the current task request when receiving confirmation feedback from the negotiation object; the first update request sending module 708 ( Figure 7 (Not shown in the image), used to send the current task request.

[0141] In some embodiments, the resource invocation device for artificial intelligence scenarios further includes: a verification result receiving module 709. Figure 7 (Not shown in the image), used to receive the verification result, which is obtained by performing a no-load verification in an isolated virtual environment according to the current task request; the second request coverage module 710 ( Figure 7 (Not shown in the image), used to generate an updated task request based on the verification result and the current task request, and to use the updated task request as the current task request; the second update request sending module 711 ( Figure 7 (Not shown in the image), used to send the current task request.

[0142] In some embodiments, the resource invocation device for artificial intelligence scenarios further includes: a repair instruction receiving module 712 ( Figure 7 (not shown in the image), used to receive repair instructions; third request overwrite module 713 ( Figure 7 (not shown in the image), used to generate an updated task request based on the repair instructions and the current task request, and to use the updated task request as the current task request; the third update request sending module 714 ( Figure 7 (Not shown in the image), used to send the current task request.

[0143] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0144] The resource invocation device for artificial intelligence scenarios in this embodiment simplifies the invocation process by automatically mapping the original task request into a structured invocation instruction for a specific backend resource, and makes full use of the available information in the backend resource list to improve the accuracy of resource selection and the success rate of execution.

[0145] This disclosure provides a scenario diagram illustrating a resource retrieval method for artificial intelligence scenarios, such as... Figure 8 As shown. As previously described, the resource retrieval method for artificial intelligence scenarios provided in this disclosure is applied to electronic devices. The electronic devices are intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers.

[0146] Specifically, the electronic device may perform the following operations: in response to a current task request submitted by an agent, obtain the current access control policy and the real-time status of backend resources; the current access control policy includes at least the agent's permission information; generate a set of candidate resources related to the current task request based on the semantic information of the current task request and the description information of the backend resources; filter the backend resources from the set of candidate resources based on the current access control policy and the real-time status of the backend resources; send the backend resource list to the agent so that the agent can generate a resource invocation request based on the backend resource list and the current task request; receive the resource invocation request sent by the agent, and invoke the corresponding backend resources according to the resource invocation request to execute the current task request.

[0147] It should be understood that Figure 8 The scene diagrams shown are merely illustrative and not restrictive; those skilled in the art can interpret them based on... Figure 8 Even with various obvious changes and / or substitutions to the examples, the resulting technical solutions still fall within the scope of this disclosure.

[0148] This disclosure provides another scenario illustration of a resource retrieval method for artificial intelligence scenarios, such as... Figure 9 As shown. As previously described, another resource mobilization method for artificial intelligence scenarios provided in this disclosure is applied to electronic devices. The electronic devices are intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers.

[0149] Specifically, the electronic device may perform the following operations: send a current task request; receive a backend resource list and generate a resource call request based on the backend resource list and the current task request; and send the resource call request.

[0150] It should be understood that Figure 9 The scene diagrams shown are merely illustrative and not restrictive; those skilled in the art can interpret them based on... Figure 9 Even with various obvious changes and / or substitutions to the examples, the resulting technical solutions still fall within the scope of this disclosure.

[0151] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0152] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0153] Figure 10 A schematic block diagram of an example electronic device 1000 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0154] like Figure 10As shown, device 1000 includes a computing unit 1001, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 1002 or a computer program loaded from storage unit 1008 into random access memory (RAM) 1003. The RAM 1003 may also store various programs and data required for the operation of device 1000. The computing unit 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. An input / output (I / O) interface 1005 is also connected to bus 1004.

[0155] Multiple components in device 1000 are connected to I / O interface 1005, including: input unit 1006, such as keyboard, mouse, etc.; output unit 1007, such as various types of monitors, speakers, etc.; storage unit 1008, such as disk, optical disk, etc.; and communication unit 1009, such as network card, modem, wireless transceiver, etc. Communication unit 1009 allows device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0156] The computing unit 1001 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 performs the various methods and processes described above, such as a resource retrieval method for an artificial intelligence scenario. For example, in some embodiments, a resource retrieval method for an artificial intelligence scenario can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1008. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1000 via ROM 1002 and / or communication unit 1009. When the computer program is loaded into RAM 1003 and executed by computing unit 1001, one or more steps of a resource retrieval method for an artificial intelligence scenario described above can be performed. Alternatively, in other embodiments, computing unit 1001 can be configured to execute a resource retrieval method for an artificial intelligence scenario by any other suitable means (e.g., by means of firmware).

[0157] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0158] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0159] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM), flash memory, optical fiber, compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0160] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0161] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0162] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0163] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0164] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A resource invocation method for artificial intelligence scenarios, applied to the resource side, including: In response to the current task request submitted by the intelligent agent, obtain the current access control policy and the real-time status of backend resources; The current access control policy includes at least the permission information of the agent; Based on the semantic information of the current task request and the description information of the backend resources, a set of candidate resources related to the current task request is generated. Based on the current access control policy and the real-time status of the backend resources, a list of backend resources is obtained by filtering from the candidate resource set; The backend resource list is sent to the intelligent agent, so that the intelligent agent can generate a resource call request based on the backend resource list and the current task request; The system receives the resource request sent by the intelligent agent and calls the corresponding backend resources according to the resource request to execute the current task request.

2. The method according to claim 1, wherein, The step of invoking the corresponding backend resource according to the resource invocation request and executing the current task request includes: The legality of the resource call request is verified based on the current access control policy and the real-time status of the backend resources. Based on the resource call request that has passed the validity check, the corresponding backend resource is invoked to execute the current task request.

3. The method according to claim 1, wherein, Before invoking the corresponding backend resource according to the resource invocation request, the method further includes: Based on the current task request and the backend resource list, determine the interface operation corresponding to each backend resource; Each interface operation is classified by intent, and the risk level of each interface operation is determined based on the intent classification results. When the risk level of any of the interface operations is high, a negotiation instruction is sent to the agent so that the agent can perform negotiation processing according to the current task request, generate an updated task request based on the negotiation processing result, and use the updated task request as the current task request.

4. The method according to claim 3, wherein, Before invoking the corresponding backend resource according to the resource invocation request, the method further includes: When the risk level of any of the interface operations is high, a no-run verification is performed according to the current task request, and the verification result is sent to the agent so that the agent can generate an updated task request based on the verification result and use the updated task request as the current task request.

5. The method according to claim 3, wherein, The step of classifying the intent of each interface operation and determining the risk level of each interface operation based on the intent classification results includes: Extract the intent semantics corresponding to each of the aforementioned interface operations; Based on the intent semantics, each interface operation is classified into a preset semantic type; Based on the semantic type, the risk level corresponding to each interface operation is determined through a preset risk mapping relationship.

6. The method according to claim 5, wherein, The preset semantic types include at least one of the following: acquisition type, calculation type, transaction type, communication type, and orchestration type; The step of determining the risk level corresponding to each interface operation based on the semantic type and through a preset risk mapping relationship includes: When the semantic type is transaction-related, the risk level of the corresponding interface operation is determined to be high risk.

7. The method according to claim 4, wherein, The step of performing a no-load verification based on the current task request and sending the verification result to the agent, so that the agent can generate an updated task request based on the verification result and use the updated task request as the current task request, includes: Based on the current system state, the current task request, and the backend resource list, a virtual execution state is constructed in an isolated virtual environment; In the virtual execution state, the corresponding backend resources in the backend resource list are invoked to execute the current task request and generate a virtual execution result; The current task request is verified based on the virtual execution result, and a verification result is generated. When the verification result indicates that the current task request needs to be adjusted, the verification result is sent to the intelligent agent, so that the intelligent agent can generate an updated task request based on the verification result and use the updated task request as the current task request.

8. The method according to claim 7, further comprising: The error message is determined based on the log information during the execution of the current task request or the virtual execution result; Attribution analysis is performed on the error messages to determine the error characteristics; A repair instruction is generated based on the error characteristics, and the repair instruction is sent to the intelligent agent; Receive the updated task request returned by the intelligent agent based on the repair instruction, and use the updated task request as the current task request.

9. The method according to claim 8, wherein, The attribution analysis of the error message includes: Based on the error message, determine the target backend resource and target interface operation where the error occurred; The error characteristics are determined based on the target backend resources and the target interface operation; the error characteristics include at least conflict parameters related to the error message.

10. The method according to claim 8, wherein, The step of generating repair instructions based on the error characteristics includes: Based on the error characteristics, extract the corresponding parameter constraint information and compliance examples from the metadata repository; Based on the difference between the current task request and the parameter constraint information, construct correction logic; Based on the compliance example described, construct a valid example; Based on the correction logic and the valid examples, determine the corresponding suggested actions; Based on the correction logic, the valid examples, and the suggested actions, a structured feedback object is constructed, and the structured feedback object is used as the repair instruction.

11. The method according to claim 1, wherein, The step of generating a candidate resource set related to the current task request based on the semantic information of the current task request and the description information of the backend resources includes: Obtain the description information corresponding to the multiple backend resources; The current task request is parsed to determine the semantic information of the current task; The description information is traversed, and the candidate resource set is determined based on the matching result between the current task semantic information and the description information.

12. The method according to claim 1, wherein, The step of filtering the candidate resource list from the candidate resource set based on the current access control policy and the real-time status of the backend resources includes: Based on the current access control policy, the candidate resource set is subjected to permission projection to obtain a subset of available resources; The available resource subset is dynamically pruned based on the real-time status of the backend resources to obtain the backend resource list.

13. The method according to claim 12, wherein, The step of projecting permissions onto the candidate resource set according to the current access control policy to obtain a subset of available resources includes: Obtain the access rules corresponding to each backend resource in the candidate resource set; The access rules are traversed, and the available resource subset is determined based on the matching results between the permission information and the access rules.

14. The method according to claim 12, wherein, The step of dynamically pruning the available resource subset based on the real-time status of the backend resources to obtain the backend resource list includes: Based on the real-time status of the backend resources, determine the available resource status corresponding to each backend resource in the available resource subset; Based on the available resource status, determine the current availability of each backend resource in the available resource subset; Add backend resources whose current availability meets the preset conditions to the backend resource list.

15. The method according to claim 1, wherein, Before sending the backend resource list to the agent, the method further includes: Compare the list capacity occupied by the backend resource list with the window capacity of the agent; When the list capacity exceeds the window capacity, adaptive compression is performed on the backend resource list to generate a dynamic query handle; Update the backend resource list based on the dynamic query handle.

16. A resource invocation method for artificial intelligence scenarios, applied to a client, comprising: Send the current task request; Receive the backend resource list and generate a resource call request based on the backend resource list and the current task request; Send the resource request.

17. The method of claim 16, further comprising: In response to receiving a negotiation instruction, based on the current task request and the backend resource list, corresponding proposal information is generated, and the proposal information is used to interact with the negotiation object; the proposal information includes at least one of the following: the call target, resource requirements, constraints, and expected results; When the adjustment feedback is received from the negotiation object, the proposal information is adjusted according to the adjustment feedback, and the negotiation object is interacted with according to the adjusted proposal information; When the negotiation object receives a response accepting the proposal, an updated task request is generated based on the proposal information corresponding to the response accepting the proposal, and the negotiation object is interacted with based on the updated task request. When a confirmation response is received from the negotiation object, the updated task request is used as the current task request; Send the current task request.

18. The method of claim 16, further comprising: Receive the verification result, which is obtained by performing a no-load verification in an isolated virtual environment based on the current task request; Based on the verification result and the current task request, an updated task request is generated, and the updated task request is used as the current task request. Send the current task request.

19. The method of claim 16, further comprising: Receive repair instructions; Based on the repair instruction and the current task request, an updated task request is generated, and the updated task request is used as the current task request; Send the current task request.

20. A resource retrieval device for artificial intelligence scenarios, applied at the resource end, comprising: The information acquisition module is used to respond to the current task request submitted by the intelligent agent and obtain the current access control policy and the real-time status of backend resources. The current access control policy includes at least the permission information of the agent; The set generation module is used to generate a set of candidate resources related to the current task request based on the semantic information of the current task request and the description information of the backend resources. The list filtering module is used to filter and obtain a list of backend resources from the candidate resource set based on the current access control policy and the real-time status of the backend resources. The list sending module is used to send the backend resource list to the intelligent agent, so that the intelligent agent can generate a resource call request based on the backend resource list and the current task request; The request execution module is used to receive the resource call request sent by the intelligent agent, and call the corresponding backend resources according to the resource call request to execute the current task request.

21. A resource retrieval device for artificial intelligence scenarios, applied to a client, comprising: The task request sending module is used to send the current task request; The request generation module is used to receive a backend resource list and generate a resource call request based on the backend resource list and the current task request. The request sending module is invoked to send the resource request.

22. An electronic device, comprising: At least one processor; as well as A memory that is communicatively connected to at least one processor; wherein, The memory stores instructions that can be executed by at least one processor to enable the at least one processor to perform the method of any one of claims 1-19.

23. A non-transitory computer-readable storage medium storing computer instructions, wherein, Computer instructions are used to cause a computer to perform the method according to any one of claims 1-19.

24. A computer program product comprising a computer program stored on a storage medium, wherein the computer program, when executed by a processor, implements the method according to any one of claims 1-19.

Images