A large model intelligent agent dynamic tool orchestration method, system, medium and device

Abstract

A large model intelligent agent dynamic tool arrangement method, system, medium and equipment, relating to the technical field of large models. The method comprises: acquiring interface metadata of an open platform, generating standardized large model tool descriptions based on the interface metadata and registering them to a tool library; receiving a user's query request, determining a target tool based on the semantic similarity of the query request and each tool description in the tool library; mapping the business parameters in the query request to the interface call parameters of the target tool; executing the interface call corresponding to the target tool based on the interface call parameters, and preprocessing the call result; and displaying the preprocessed call result in a visual form. The technical solution provided by the present application can realize dynamic arrangement of management tools, improve the adaptability of the system to changes in business scenarios, and thus improve the management efficiency of enterprises.

Description

Technical Field

[0001] This application relates to the field of large model technology, specifically to a method, system, medium, and device for orchestrating dynamic tools for large model intelligent agents. Background Technology

[0002] With the rapid development of artificial intelligence technology, large-scale intelligent models are increasingly being used in enterprise management. In workforce management scenarios, enterprises typically need to call interfaces from multiple open platforms to complete tasks such as personnel scheduling, attendance management, and performance evaluation. To improve management efficiency, enterprise managers often describe specific business needs in natural language, hoping that the system can automatically call the corresponding management tools to handle these needs.

[0003] Currently, mainstream enterprise management systems typically employ pre-defined tool invocation processes, where the system binds user needs to specific management tools based on pre-configured rules. This approach requires enterprise managers to be familiar with the functions and usage of various tools, and manual reconfiguration is necessary when adding or replacing management tools. Because the invocation process is fixed, the system cannot flexibly select and combine appropriate tools according to changes in actual business scenarios, resulting in low system efficiency and impacting enterprise management efficiency. Summary of the Invention

[0004] This application provides a method, system, medium, and device for dynamic tool orchestration of large-scale intelligent agents, which enables dynamic orchestration of management tools, improves the system's adaptability to changes in business scenarios, and thus enhances enterprise management efficiency.

[0005] Firstly, this application provides a method for dynamic tool orchestration of large-scale intelligent agents, the method comprising:

[0006] Obtain the interface metadata of the open platform, generate a standardized large model tool description based on the interface metadata, and register it to the tool library;

[0007] Receive a user's query request and determine the target tool based on the semantic similarity between the query request and the descriptions of each tool in the tool library;

[0008] Map the business parameters in the query request to the interface call parameters of the target tool;

[0009] The interface call corresponding to the target tool is executed based on the interface call parameters, and the call result is preprocessed.

[0010] The preprocessed call results are displayed in a visual format.

[0011] By adopting the above technical solution, and by acquiring the interface metadata of the open platform and generating standardized tool descriptions for registration in the tool library, automated access to management tools is achieved. When a user query request is received, the target tool is determined based on the semantic similarity between the query request and the tool descriptions in the tool library. This eliminates the need for manual pre-configuration of calling rules, improving the flexibility of tool selection. By mapping the business parameters in the query request to the interface call parameters of the target tool, and performing interface calls and result preprocessing, the system can accurately understand user needs and automatically complete tool calls. Finally, the call results are visualized, making it easy for users to understand the processing outcome. This enables dynamic orchestration of management tools, improving the system's adaptability to changes in business scenarios, reducing manual configuration costs, and ultimately improving enterprise management efficiency.

[0012] A second aspect of this application provides a dynamic tool orchestration system for large-scale intelligent agents, the system comprising:

[0013] The tool library generation module is used to obtain the interface metadata of the open platform, generate standardized large model tool descriptions based on the interface metadata, and register them to the tool library;

[0014] The target tool determination module is used to receive a user's query request and determine the target tool based on the semantic similarity between the query request and the descriptions of each tool in the tool library;

[0015] The interface parameter determination module is used to map the business parameters in the query request to the interface call parameters of the target tool;

[0016] The interface call execution module is used to execute the interface call corresponding to the target tool based on the interface call parameters, and to preprocess the call results;

[0017] The call result display module is used to display the preprocessed call results in a visual format.

[0018] A third aspect of this application provides a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the method steps described above.

[0019] A fourth aspect of this application provides an electronic device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0020] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0021] This application achieves automated access to management tools by acquiring interface metadata from the open platform and generating standardized tool descriptions for registration in the tool library. Upon receiving a user query request, the system determines the target tool based on the semantic similarity between the query request and the tool descriptions in the tool library, eliminating the need for manual pre-configuration of calling rules and improving the flexibility of tool selection. By mapping business parameters in the query request to interface call parameters of the target tool and performing interface calls and result preprocessing, the system accurately understands user needs and automatically completes tool calls. Finally, the call results are visualized, facilitating user understanding of the processing outcomes. This enables dynamic orchestration of management tools, improving the system's adaptability to changes in business scenarios, reducing manual configuration costs, and ultimately enhancing enterprise management efficiency. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a dynamic tool orchestration method for large-scale intelligent agents provided in an embodiment of this application;

[0023] Figure 2 This is a schematic diagram illustrating the list of open capabilities of an open platform provided in an embodiment of this application;

[0024] Figure 3 This is a schematic diagram of a module of a dynamic tool orchestration system for large-scale intelligent agents provided in an embodiment of this application;

[0025] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0026] Explanation of reference numerals in the attached drawings: 300, electronic device; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. Detailed Implementation

[0027] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0028] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0029] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0030] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0031] Please refer to Figure 1 A flowchart illustrating a dynamic tool orchestration method for large-scale intelligent agents is presented. This method can be implemented using a computer program, a microcontroller, or run on a dynamic tool orchestration system for large-scale intelligent agents. The computer program can be integrated into a computer device or run as a standalone tool application. Specifically, the method includes steps 10 to 50, as follows:

[0032] Step 10: Obtain the interface metadata of the open platform, generate a standardized large model tool description based on the interface metadata, and register it to the tool library.

[0033] In this embodiment of the application, the open platform refers to a third-party service platform that provides workforce management functions to enterprises, such as personnel scheduling platforms, attendance management platforms, performance evaluation platforms, etc. These platforms allow external systems to call the management functions they provide through open interfaces.

[0034] Please see Figure 2 This is a schematic diagram illustrating an open capability list of an open platform provided in an embodiment of this application. Figure 2 This showcases all business modules of the open platform and their corresponding API counts, including functional modules in different workforce management domains such as the Human Resources module (31 APIs), Attendance module (83 APIs), and Scheduling module (14 APIs). This is a summary display of all available interfaces read from the open platform by the system through the API metadata parser, providing basic data support for subsequent tool configuration and agent invocation.

[0035] Interface metadata refers to data information that describes the characteristics of an open platform interface, including the interface's call address, interface function description, request parameter format, response data structure, and other information. This metadata defines how to interact with the open platform.

[0036] The tool library is a data warehouse used to store and manage descriptions of registered tools. The tool descriptions in the library record the functional characteristics and calling methods of each management tool in a standardized format, which facilitates the system to retrieve and call tools.

[0037] Specifically, the system first retrieves the interface metadata provided by the open platform via an HTTP request. This metadata includes information such as the interface's functional description, call address, and parameter definitions. To facilitate understanding and processing of this interface information by the large model, the system parses the functional description text in the interface metadata, extracts the tool name and functional features, and converts the request parameters into a standardized parameter definition format. Subsequently, the system combines the tool name, functional features, and parameter definitions to generate a standardized tool description in JSON format and registers it in the tool library. This standardized tool description method enables the system to uniformly manage interfaces from different open platforms, providing a foundation for subsequent tool selection based on semantic similarity.

[0038] Based on the above embodiments, as another optional embodiment, the step of generating a standardized large model tool description based on interface metadata and registering it to the tool library may further include the following steps:

[0039] Step 101: Parse the interface description in the interface metadata to generate tool information containing the tool name and function description.

[0040] Specifically, the system first extracts the interface description text from the interface metadata. This text typically contains natural language descriptions of the interface's functions and usage scenarios. The system uses a natural language processing model to segment and tag the description text, extracting keywords and phrases. The system can identify verb phrases in the description text as functional actions and noun phrases as processing objects, and combines these actions and objects with preset tool naming rules to generate standardized tool names. Simultaneously, the system retains information such as scenario descriptions and usage limitations from the original description text as functional descriptions. Finally, the system integrates the tool names and functional descriptions into structured tool information. This standardized tool information extraction method ensures the accuracy and consistency of the tool descriptions.

[0041] Step 102: Convert the request parameters in the interface metadata into standardized parameter definitions.

[0042] Specifically, the system analyzes the request parameters in the interface metadata, first extracting basic attributes such as the name, data type, and whether it is required for each parameter. Then, these raw parameter attributes are mapped to predefined standard parameter templates, including uniformly converting parameter types to system-supported data types and converting parameter constraints into standard validation rules. For parameter names containing business semantics, the system uses a semantic analysis model to extract the business meaning and adds semantic annotations to the standard parameter definition. Furthermore, the system generates example values ​​and parameter descriptions for each parameter to facilitate subsequent parameter mapping. This standardized parameter definition method achieves unified management of different interface parameter formats.

[0043] Step 103: Combine the tool information and parameter definitions into a JSON-formatted tool description, and register the tool description to the tool library.

[0044] Specifically, the system uses a pre-defined JSON template to organize tool information and parameter definitions. The template includes key fields such as basic tool information, parameter list, and call configuration. The system first populates the basic information section of the template with tool information, including tool name and function description. Then, it organizes the standard parameter definitions into a parameter array and populates the parameter list section of the template. The system also automatically adds management information such as the tool's version number and creation time. After generating the JSON-formatted tool description, the system calls the tool library's registration interface to save the tool description to the database and create a corresponding index for easy tool retrieval later.

[0045] Step 20: Receive the user's query request and determine the target tool based on the semantic similarity between the query request and the descriptions of each tool in the tool library.

[0046] In this embodiment, a query request refers to a business requirement described by enterprise managers using natural language, such as "query Zhang San's attendance records for this month" or "statistics on the overtime hours of the R&D department." This query request includes the management operation the user expects to perform and related business parameter information, requiring the system to understand the business semantics and convert it into specific tool call instructions.

[0047] The target tool refers to the management tool selected from the tool library that is most suitable for handling the current query request. This tool has functional characteristics that match the semantics of the query request and can accurately complete the management operations expected by the user.

[0048] Specifically, upon receiving a user's query request, the system first invokes a large model to convert the query request into an intent vector. The system uses a pre-trained language model to extract key information from the query request and generates a fixed-dimensional semantic vector. Then, it retrieves all tool descriptions from the tool library and converts each tool description into a corresponding tool vector. The system calculates the cosine similarity between the query vector and each tool vector, selecting tools with similarity scores higher than a preset threshold as candidate tools. Finally, the system calculates metrics such as success rate and response time for each candidate tool based on historical call records, and after comprehensive evaluation, selects the tool with the highest score as the target tool. This semantic similarity-based tool selection method improves the system's accuracy in understanding user needs.

[0049] Based on the above embodiments, as an optional embodiment, the step of determining the target tool based on the semantic similarity between the query request and the descriptions of each tool in the tool library may further include the following steps:

[0050] Step 201: Input the query request into the large model to extract intent information and generate the corresponding query vector.

[0051] Specifically, the system first performs word segmentation and standardization on the query request, removing stop words and unifying the text format. Then, a large-scale model encodes the processed text using a multi-layered Transformer structure, extracting key semantic information, including intent elements such as operation type, business object, and time range. The system organizes these intent elements into structured intent information and uses a pre-trained vectorization model to map the intent information into a 768-dimensional vector space, generating query vectors that represent the query semantics. This large-scale model-based intent extraction method can accurately understand the user's query intent.

[0052] Step 202: Calculate the similarity between the query vector and the vectors describing each tool in the tool library, and select tools with similarity greater than a preset threshold as candidate tools.

[0053] Specifically, the system reads all tool descriptions from the tool library and converts each tool description into a tool vector using the same vectorization model as the query request. To improve computational efficiency, the system employs vector indexing technology to organize the tool vectors. When calculating similarity, the system uses the cosine similarity formula to calculate the similarity between the query vector and each tool vector, with similarity values ​​ranging from [0,1]. The system filters tools with a similarity greater than 0.8 as candidate tools. If the number of candidate tools is less than three, the similarity threshold is adaptively lowered until the minimum number of candidates is met. This vector similarity-based filtering mechanism ensures the relevance of candidate tools to user needs.

[0054] Step 203: Calculate the availability score of each candidate tool based on historical call records, and select the tool with the highest score as the target tool.

[0055] Specifically, the system calculates the availability score of candidate tools based on historical call records. The system analyzes recent call success rate, average response time, and error rate for each candidate tool from the call logs. Then, the system calculates a standardized score for each metric according to preset scoring rules, with call success rate weighted at 0.4, response time at 0.3, and error rate at 0.3. The system sums these weighted scores to obtain the availability score for each candidate tool. Finally, the system selects the tool with the highest availability score as the target tool and records the selection in the call log. This historical data-based evaluation method improves the reliability of tool selection.

[0056] Step 30: Map the business parameters in the query request to the interface call parameters of the target tool.

[0057] In this embodiment of the application, the interface call parameters refer to the standardized parameters required by the open platform interface, and these parameters need to conform to the interface call specifications.

[0058] Specifically, the system first uses a large model to extract business parameters from the query request. For example, from the query "Query Zhang San's attendance records for this month," it identifies the person "Zhang San" and the time range "this month." Then, the system obtains the parameter definitions of the target tool, clarifying the parameter formats required by the interface, such as `employee_id` requiring a standardized employee ID format and `time_range` requiring a standard timestamp format. The system calls a parameter conversion module to standardize the extracted business parameters, including converting names to employee IDs and relative time descriptions to specific time ranges. Finally, the system assembles the converted parameters into interface call parameters according to the data structure defined by the interface. This intelligent parameter mapping method resolves the discrepancy between the user's natural language description and the interface specification requirements.

[0059] Based on the above embodiments, as an optional embodiment, the step of mapping the business parameters in the query request to the interface call parameters of the target tool may further include the following steps:

[0060] Step 301: Extract key business parameter information from the query request and generate a list of parameters to be mapped.

[0061] Specifically, the system utilizes a large model to perform semantic parsing of query requests. First, it identifies business entities in the text, such as names, department names, and times, using a named entity recognition model. Then, dependency parsing is used to determine the relationships between entities and extract corresponding modifiers and qualifiers. For example, from the query "Query Zhang San's attendance records in the R&D department last month," the system identifies entities such as "Zhang San," "last month," and "R&D department," and determines the association between these entities and the query operation. The system organizes the identified entities and their relationships into a structured parameter list, with each parameter item containing a parameter value and parameter type label. This semantic parameter extraction method ensures the completeness and semantic accuracy of business parameters.

[0062] Step 302: Based on the parameter definition of the target tool, perform semantic matching on the list of parameters to be mapped to obtain the parameter mapping relationship.

[0063] Specifically, the system loads the parameter definition of the target tool, which includes the name, description, and constraints of each parameter field. The system uses a semantic matching model to calculate the semantic similarity between the parameter to be mapped and the tool parameters. Specifically, it uses the BERT model to encode the parameter description text and calculates the degree of matching between parameters through an attention mechanism. For each parameter to be mapped, the system selects the tool parameter with the highest semantic similarity as the mapping target and records the mapping confidence. When multiple candidate mapping targets appear, the system will filter them based on parameter type and business rules.

[0064] Step 303: Based on the parameter mapping relationship and the preset mapping rules, convert the list of parameters to be mapped into the target format parameters.

[0065] Specifically, the system calls the corresponding parameter converter to perform format conversion based on the obtained parameter mapping relationship. For time-related parameters, the system converts relative time descriptions (such as "last month") into a standard time format; for personnel-related parameters, the system queries the personnel information database to convert names into employee IDs; for department-related parameters, the system converts department names into department codes through the organizational structure tree. The system also handles unit conversion and format standardization of the parameters to ensure that the converted parameters meet the format requirements of the target tool.

[0066] Step 304: Perform data type validation and mandatory field checks on the target format parameters, automatically complete missing parameters, and generate the final interface call parameters.

[0067] Specifically, the system performs a comprehensive validation of the converted target format parameters. First, it checks whether the data type of each parameter conforms to the interface definition, including constraints such as numerical range and character length. Then, it verifies the completeness of required parameters. For missing required parameters, the system automatically completes them based on preset default value rules or historical call records. For example, when the timezone parameter is missing, the system automatically fills in the default timezone based on the user's location. Finally, the system assembles the validated parameters into the final call parameters according to the data structure required by the interface. This rigorous parameter validation and completion mechanism ensures the reliability of the interface call.

[0068] Step 40: Execute the interface call corresponding to the target tool based on the interface call parameters, and preprocess the call results.

[0069] Specifically, the system initiates an API call request to the open platform corresponding to the target tool via the HTTP protocol, encapsulating the API call parameters in the request body according to the format defined by the API. The system employs an asynchronous call approach, setting reasonable timeouts and retry mechanisms to automatically retry when a call failure is detected. Upon receiving the call response, the system first checks the response status code to confirm whether the call was successful. For successful calls, the system parses the response data, extracts valid business information, and performs data cleaning, including removing redundant fields, standardizing data formats, and sorting and grouping. This standardized call and preprocessing mechanism ensures the stability of the API call and the availability of the returned data.

[0070] Based on the above embodiments, as another optional embodiment, the step of executing the interface call corresponding to the target tool based on the interface call parameters may further include the following steps:

[0071] Step 4011: Generate a call request based on the target tool's call address and interface call parameters.

[0072] Specifically, the system retrieves the target tool's invocation configuration information from the tool library, including the invocation address, authentication method, and request header format. Based on this configuration information, the system constructs an HTTP request object, serializes the interface call parameters into JSON format according to the data structure required by the interface, and adds it to the request body. Simultaneously, the system generates a unique request identifier and adds authentication information and timestamps, among other security fields, to the request header. For interfaces requiring signature verification, the system also generates a request signature based on a preset encryption algorithm. This standardized request generation mechanism ensures the legitimacy and traceability of the invocation request.

[0073] Step 4012: Obtain the response result of the target tool to the call request and record the performance indicators of the call process.

[0074] Specifically, the system initiates a performance monitoring module, records the call start time, and then sends the call request via an HTTP client. The system monitors the execution status of the request in real time, including metrics such as network latency, response time, and data transfer volume. Upon receiving the response data, the system records the call end time and calculates the total time consumed. For timeout or failed requests, the system triggers a retry mechanism, retrying a maximum of three times. The system saves performance metrics collected during the call process, such as request time, number of retries, and response status, to the call log. This comprehensive performance monitoring mechanism helps to evaluate and optimize API call efficiency.

[0075] Step 4013: Parse the business data in the response result and perform format conversion according to the preset data processing rules.

[0076] Specifically, the system first checks the status code of the response to confirm whether the call was successful. For successful calls, the system parses the JSON structure of the response data and extracts the business data fields. The system then standardizes the business data according to preset data processing rules, including field name mapping, data type conversion, and time format standardization. For numeric data, the system performs unit conversion and precision handling; for text data, the system performs encoding conversion and special character handling. This standardized data processing flow ensures the consistency and availability of business data.

[0077] Step 4014: Integrate the transformed business data with performance metrics to generate standardized call results.

[0078] Specifically, the processed business data is organized using a standard result template, which includes fields such as data content, statistical information, and status indicators. Performance metrics are added to the metadata section of the result template, and statistical characteristics of the data, such as the number of records and numerical range, are calculated. For paginated data, the system adds pagination information and navigation links. Finally, the system generates a verification code for the call results and serializes the complete result data into a unified JSON format. This standardized result integration method facilitates data display and analysis by upper-layer applications.

[0079] Based on the above embodiments, as another optional embodiment, the step of preprocessing the call result may further include the following steps:

[0080] Step 4021: Perform anomaly detection on the call result and generate an anomaly detection report.

[0081] Specifically, the system first checks the response status code of the call result, marking any non-200 status code as a call exception. Then, the system iterates through the JSON structure of the response data, checking for the existence of required fields and recording any missing fields as integrity exceptions. For each field, the system performs format validation according to a predefined data format template, including data type matching, length limits, and value ranges, marking fields that do not meet the format requirements as format exceptions. Finally, the system integrates these exceptions into a basic exception identifier, including the exception field, exception description, and exception location information. This multi-layered basic exception detection mechanism ensures the basic availability of the data.

[0082] Furthermore, the system loads a pre-defined set of business rules, including numerical range limits, data association constraints, and timing logic. For key business metrics in the call results, such as attendance duration and the number of dispatched personnel, the system uses a rule engine for verification. For example, it checks whether attendance duration exceeds a reasonable range and whether the number of dispatched personnel meets departmental staffing requirements. When a metric is found to violate business rules, the system generates a business anomaly flag, recording the violating metric, the reason for the violation, and relevant contextual information. This business rule-based verification method ensures the business rationality of the data.

[0083] Then, the system loads anomaly classification rules and level determination criteria from the anomaly rule base. For detected basic anomaly identifiers and business anomaly identifiers, the system performs pattern matching to classify the anomalies into predefined anomaly types, such as network anomalies, data anomalies, and business anomalies. The system then assesses the scope and severity of the anomaly's impact and calculates the anomaly level according to preset scoring rules, categorizing it into warning, error, and critical error levels.

[0084] Finally, the anomaly detection results are organized using a standard report template. First, anomalies are grouped and sorted according to their severity level, with higher-level anomalies displayed first. For each anomaly, the system records its type, level, location, and detailed description. The system also selects appropriate handling suggestions from a pre-defined handling strategy library based on the anomaly type and level, such as retry, alarm, or manual intervention. Finally, the system integrates this information into a structured anomaly detection report for easy processing and analysis in the future.

[0085] Step 4022: Determine whether a retry is needed based on the anomaly detection report.

[0086] Specifically, the system makes retry decisions based on the anomaly information in the anomaly detection report. First, it determines whether the anomaly is retryable based on its type, such as network timeout or temporary service unavailability. For retryable anomalies, the system checks if the current number of retries exceeds the maximum limit (default 3) and assesses the cost and probability of success of the retry. The system also considers the real-time load status of the service, appropriately reducing the retry frequency when the load is high. Based on these factors, the system generates a retry decision and records the decision basis. This intelligent retry decision mechanism improves the success rate of API calls.

[0087] Step 4023: If a retry is required, return to the step of executing the corresponding interface call of the target tool based on the interface call parameters.

[0088] Specifically, when a retry is required, the system directly returns to the steps of executing the corresponding API call to the target tool based on the API call parameters. The system keeps the original API call parameters unchanged and re-executes the steps of calling the target tool, that is, it re-sends the API call request to the calling address of the target tool. This return and retry mechanism ensures that the original parameters can be reused for re-calling when the call fails, thereby improving the success rate of API calls.

[0089] Step 4024: If no retry is required, the call results that pass the anomaly detection are filtered and completed based on the preset data cleaning rules to obtain the cleaned data.

[0090] Specifically, when retries are not required, the system loads preset data cleaning rules to process call results that pass anomaly detection. The system first performs data filtering, deleting duplicate records, null records, and abnormal records that do not conform to business rules. Then, the system performs data completion, filling in missing values ​​for necessary fields according to preset rules, such as using default values, historical averages, or derived values ​​from related fields. For example, when employee department information is missing, the system will retrieve and supplement it from the employee's basic information. This data cleaning mechanism based on preset rules ensures the integrity and standardization of the data.

[0091] Step 4025: Perform index calculation and structured processing on the cleaned data to obtain the preprocessed call results.

[0092] Specifically, the system performs statistical analysis and structured processing on the cleaned data. First, it calculates key business indicators, such as total data volume, average value, and distribution characteristics. For multidimensional data, the system generates pivot tables to display summary results from different dimensions. The system also categorizes and aggregates the data, generating a hierarchical data structure to facilitate display and analysis by upper-level applications. Finally, the system organizes the processed data according to a standard format, generating a complete result set containing the original data, statistical indicators, and metadata.

[0093] Step 50: Display the preprocessed call results in a visual format.

[0094] Specifically, the system first identifies the business type of the call results, such as attendance data, shift scheduling data, and personnel dispatch data, and selects an appropriate display template for each type of data. For attendance data, the system uses a calendar heatmap to display attendance distribution and a stacked bar chart to display the percentage of each attendance status. For shift scheduling data, the system uses a Gantt chart to display the distribution of personnel shift times and distinguishes shift types by different colors. For personnel dispatch data, the system uses a Sankey diagram to display personnel flow relationships.

[0095] During the presentation, the system supports multi-dimensional data pivoting, allowing users to switch data views by department, time, personnel, and other dimensions. For collaborative data across modules, the system automatically performs data correlation, such as comparing attendance anomalies with scheduling plans to highlight anomalies. The system also adds business-related annotations to charts, such as marking statutory holidays and indicating scheduling conflicts.

[0096] Please see Figure 3 This is a schematic diagram of a module of a large-scale intelligent agent dynamic tool orchestration system provided in an embodiment of this application, wherein the system includes:

[0097] The tool library generation module is used to obtain the interface metadata of the open platform, generate standardized large model tool descriptions based on the interface metadata, and register them to the tool library;

[0098] The target tool determination module is used to receive a user's query request and determine the target tool based on the semantic similarity between the query request and the descriptions of each tool in the tool library.

[0099] The interface parameter determination module is used to map the business parameters in the query request to the interface call parameters of the target tool;

[0100] The interface call execution module is used to execute the interface call corresponding to the target tool based on the interface call parameters, and to preprocess the call results;

[0101] The call result display module is used to display the preprocessed call results in a visual format.

[0102] Optionally, the tool library generation module is also used to parse the interface description in the interface metadata and generate tool information containing tool name and function description;

[0103] Convert the request parameters in the interface metadata into standardized parameter definitions;

[0104] The tool information and parameter definitions are combined into a JSON-formatted tool description, and the tool description is registered to the tool library.

[0105] Optionally, the target tool determination module is also used to input the query request into a large model to extract intent information and generate a corresponding query vector;

[0106] Calculate the similarity between the query vector and the vectors describing each tool in the tool library, and select tools with a similarity greater than a preset threshold as candidate tools;

[0107] Based on historical call records, the availability score of each candidate tool is calculated, and the tool with the highest score is selected as the target tool.

[0108] Optionally, the interface parameter determination module is also used to extract key business parameter information from the query request and generate a parameter list to be mapped.

[0109] Based on the parameter definition of the target tool, semantic matching is performed on the list of parameters to be mapped to obtain the parameter mapping relationship;

[0110] Based on the parameter mapping relationship and the preset mapping rules, the list of parameters to be mapped is converted into target format parameters;

[0111] The target format parameters are validated for data type and checked for required fields. Missing parameters are automatically filled in to generate the final interface call parameters.

[0112] Optionally, the interface call execution module is also used to generate a call request based on the call address of the target tool and the interface call parameters;

[0113] Obtain the response result of the target tool to the call request, and record the performance indicators of the call process;

[0114] The business data in the response result is parsed and converted according to preset data processing rules;

[0115] The transformed business data is integrated with the performance metrics to generate standardized call results.

[0116] Optionally, the interface call execution module is also used to perform anomaly detection on the call result and generate an anomaly detection report;

[0117] Determine whether a retry is needed based on the anomaly detection report;

[0118] If a retry is required, return to the step of executing the interface call corresponding to the target tool based on the interface call parameters;

[0119] If no retry is required, the call results that pass the anomaly detection are filtered and completed based on the preset data cleaning rules to obtain the cleaned data;

[0120] The cleaned data is subjected to index calculation and structured processing to obtain the preprocessed call results.

[0121] Optionally, the interface call execution module is also used to detect the response status code, data integrity, and data format of the call result, and generate the corresponding basic exception identifier;

[0122] The validity of key business indicators in the call results is verified according to preset business rules, and a business anomaly identifier is generated.

[0123] Based on a preset exception rule base, the basic exception identifiers and the business exception identifiers are analyzed to determine the exception type and exception level;

[0124] The anomaly type, anomaly level, and corresponding handling suggestions are integrated to generate an anomaly detection report.

[0125] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0126] This application also provides a computer storage medium that can store multiple instructions. The instructions are adapted to be loaded and executed by a processor. The above-described method for orchestrating dynamic tools for large-scale intelligent agents is described above. For details of the execution process, please refer to the specific description of the above-described embodiments, which will not be repeated here.

[0127] Please refer to Figure 4 This application also discloses an electronic device. Figure 4 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. The electronic device 300 may include: at least one processor 301, at least one network interface 304, a user interface 303, a memory 305, and at least one communication bus 302.

[0128] The communication bus 302 is used to enable communication between these components.

[0129] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0130] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0131] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0132] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory 305 may include a non-transitory computer-readable storage medium. The memory 305 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. (Refer to...) Figure 4 The memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a dynamic tool orchestration method for large-scale intelligent agents.

[0133] exist Figure 4 In the illustrated electronic device 300, the user interface 303 is mainly used to provide an input interface for the user and acquire user input data; while the processor 301 can be used to call an application program stored in the memory 305 that represents a dynamic tool orchestration method for a large model intelligent agent. When executed by one or more processors 301, the electronic device 300 performs one or more methods as described in the above embodiments. It should be noted that, for the foregoing method embodiments, for the sake of simplicity, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0134] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0135] In the various embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

[0136] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0137] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0138] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0139] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will readily conceive of those skilled in the art upon consideration of the specification and the disclosure of practical truths.

[0140] This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for dynamic tool orchestration of large-scale intelligent agents, characterized in that, The method includes: Obtain the interface metadata of the open platform, generate a standardized large model tool description based on the interface metadata, and register it to the tool library; Receive a user's query request and determine the target tool based on the semantic similarity between the query request and the descriptions of each tool in the tool library; Map the business parameters in the query request to the interface call parameters of the target tool; The interface call corresponding to the target tool is executed based on the interface call parameters, and the call result is preprocessed. The preprocessed call results are displayed in a visual format; The step of mapping the business parameters in the query request to the interface call parameters of the target tool includes: Using a large model to perform semantic parsing of query requests, firstly, business entities in the text are identified through a named entity recognition model, then dependency parsing is used to determine the relationships between entities, extract the corresponding modifiers and qualifiers, and determine the association between these entities and the query operation. The identified entities and their relationships are organized into a structured parameter list, with each parameter item containing parameter value and parameter type label. Based on the parameter definition of the target tool, semantic matching is performed on the list of parameters to be mapped to obtain the parameter mapping relationship; Based on the parameter mapping relationship and the preset mapping rules, the list of parameters to be mapped is converted into target format parameters; The target format parameters are validated for data type and checked for required fields. The missing parameters are automatically filled in to generate the final interface call parameters. The step of executing the interface call corresponding to the target tool based on the interface call parameters includes: A call request is generated based on the call address of the target tool and the interface call parameters; Obtain the response result of the target tool to the call request, and record the performance indicators of the call process; The business data in the response result is parsed and converted according to preset data processing rules; The transformed business data is integrated with the performance metrics to generate standardized call results.

2. The method for dynamic tool orchestration of large-scale intelligent agents according to claim 1, characterized in that, The process of generating standardized large model tool descriptions based on the interface metadata and registering them to the tool library includes: Parse the interface description in the interface metadata to generate tool information containing tool name and function description; Convert the request parameters in the interface metadata into standardized parameter definitions; The tool information and parameter definitions are combined into a JSON-formatted tool description, and the tool description is registered to the tool library.

3. The method for dynamic tool orchestration of large-scale intelligent agents according to claim 1, characterized in that, The step of determining the target tool based on the semantic similarity between the query request and the descriptions of each tool in the tool library includes: The query request is input into the large model to extract intent information and generate a corresponding query vector; Calculate the similarity between the query vector and the vectors describing each tool in the tool library, and select tools with a similarity greater than a preset threshold as candidate tools; Based on historical call records, the availability score of each candidate tool is calculated, and the tool with the highest score is selected as the target tool.

4. The method for dynamic tool orchestration of large-scale intelligent agents according to claim 1, characterized in that, The preprocessing of the call results includes: Perform anomaly detection on the call results and generate an anomaly detection report; Determine whether a retry is needed based on the anomaly detection report; If a retry is required, return to the step of executing the interface call corresponding to the target tool based on the interface call parameters; If no retry is required, the call results that pass the anomaly detection are filtered and completed based on the preset data cleaning rules to obtain the cleaned data; The cleaned data is subjected to index calculation and structured processing to obtain the preprocessed call results.

5. The method for dynamic tool orchestration of large-scale intelligent agents according to claim 4, characterized in that, The step of performing anomaly detection on the call result and generating an anomaly detection report includes: The system detects the response status code, data integrity, and data format of the call result and generates the corresponding basic exception identifier. The validity of key business indicators in the call results is verified according to preset business rules, and a business anomaly identifier is generated. Based on a preset exception rule base, the basic exception identifiers and the business exception identifiers are analyzed to determine the exception type and exception level; The anomaly type, anomaly level, and corresponding handling suggestions are integrated to generate an anomaly detection report.

6. A dynamic tool orchestration system for large-scale intelligent agents, characterized in that, The system is used to execute the dynamic tool orchestration method for large-model intelligent agents as described in claim 1, the system comprising: The tool library generation module is used to obtain the interface metadata of the open platform, generate standardized large model tool descriptions based on the interface metadata, and register them to the tool library; The target tool determination module is used to receive a user's query request and determine the target tool based on the semantic similarity between the query request and the descriptions of each tool in the tool library; The interface parameter determination module is used to map the business parameters in the query request to the interface call parameters of the target tool; The interface call execution module is used to execute the interface call corresponding to the target tool based on the interface call parameters, and to preprocess the call results; The call result display module is used to display the preprocessed call results in a visual format.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted to be loaded by a processor and executed as described in any one of claims 1-5.

8. An electronic device, characterized in that, It includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-5.

Images