Large model agent dynamic tool arrangement method, system, medium and equipment

Abstract

The invention discloses a large model intelligent agent dynamic tool arrangement method and system, a medium and equipment, and relates to the technical field of large models. The method comprises the following steps: acquiring interface metadata of an open platform, generating a standardized large model tool description based on the interface metadata, and registering the standardized large model tool description to a tool library; receiving a query request of a user, and determining a target tool based on the query request and the semantic similarity of each tool description in the tool library; mapping service parameters in the query request into interface calling parameters of the target tool; executing interface calling corresponding to the target tool based on the interface calling parameter, and preprocessing a calling result; and displaying the pre-processed calling result in a visual form. By implementing the technical scheme provided by the invention, the dynamic arrangement of the management tool can be realized, the adaptability of the system to the business scene change is improved, and the management efficiency of an enterprise is further improved.

Description

Technical Field

[0001] The present application relates to the field of large model technology, and in particular to a large model intelligent body dynamic tool arrangement method, system, medium and equipment. Background Art

[0002] With the rapid development of artificial intelligence (AI) technology, large-scale intelligent agents are increasingly being used in enterprise management. In workforce management scenarios, enterprises often need to access interfaces across 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 requirements using natural language, hoping that the system will automatically invoke the appropriate management tools to address these needs.

[0003] Currently, mainstream enterprise management systems typically utilize a pre-defined tool invocation process. 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 required when adding or replacing new management tools. Because the invocation process is fixed, the system cannot flexibly select and combine appropriate tools based on changing business scenarios. This results in inefficient system usage and impacts enterprise management efficiency. Summary of the Invention

[0004] This application provides a large-model intelligent body dynamic tool orchestration method, system, medium and equipment, which can realize the dynamic orchestration of management tools, improve the system's adaptability to changes in business scenarios, and thus improve the management efficiency of the enterprise.

[0005] In a first aspect, the present application provides a method for orchestrating dynamic tools for a large model agent, the method comprising: Obtaining interface metadata of the open platform, generating a standardized large model tool description based on the interface metadata, and registering the description in the tool library; receiving a query request from a user, and determining a target tool based on semantic similarity between the query request and descriptions of each tool in the tool library; Mapping the business parameters in the query request to interface call parameters of the target tool; Executing an interface call corresponding to the target tool based on the interface call parameters, and preprocessing the call result; The preprocessed call results are displayed in a visual form.

[0006] By adopting the above technical solution, automated access to management tools is achieved by obtaining interface metadata from the open platform and generating standardized tool descriptions that are registered in the tool library. When a user's query request is received, the target tool is determined based on the semantic similarity between the query request and the descriptions of each tool in the tool library. This eliminates the need for manual pre-configuration of call 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, executing the interface call and pre-processing the results, the system can accurately understand user needs and automatically complete the tool call. Finally, the call results are displayed visually, making it easier for users to understand the processing results. This achieves dynamic orchestration of management tools, improves the system's adaptability to changes in business scenarios, reduces manual configuration costs, and thus improves the management efficiency of the enterprise.

[0007] In a second aspect of the present application, a large-model intelligent agent dynamic tool orchestration system is provided, the system comprising: A tool library generation module is used to obtain the interface metadata of the open platform, generate a standardized large model tool description based on the interface metadata, and register it in the tool library; A target tool determination module is configured to receive a query request from a user and determine a target tool based on semantic similarity between the query request and the descriptions of each tool in the tool library; An interface parameter determination module, configured to map the business parameters in the query request to interface call parameters of the target tool; An interface call execution module, configured to execute an interface call corresponding to the target tool based on the interface call parameters and pre-process the call result; The call result display module is used to display the preprocessed call results in a visual form.

[0008] In a third aspect of the present application, a computer storage medium is provided. The computer storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by a processor and executing the above method steps.

[0009] In a fourth aspect of the present application, an electronic device is provided, comprising: a processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the above-mentioned method steps.

[0010] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: This application achieves automated access to management tools by acquiring the interface metadata of the open platform and generating standardized tool descriptions that are registered in the tool library. When a user's query request is received, the target tool is determined based on the semantic similarity between the query request and the descriptions of each tool in the tool library. This eliminates the need for manual pre-configuration of call rules, thereby increasing the flexibility of tool selection. By mapping the business parameters in the query request to the interface call parameters of the target tool, and executing the interface call and result preprocessing, the system can accurately understand user needs and automatically complete the tool call. Finally, the call results are displayed visually, making it easier for users to understand the processing results. This achieves dynamic orchestration of management tools, improves the system's adaptability to changes in business scenarios, reduces manual configuration costs, and thus improves the management efficiency of the enterprise. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 This is a flow chart of a large-model intelligent agent dynamic tool orchestration method provided in an embodiment of the present application; Figure 2 This is a schematic diagram of an open capability list of an open platform provided in an embodiment of the present application; Figure 3 This is a module diagram of a large-model intelligent agent dynamic tool orchestration system provided by an embodiment of the present application; Figure 4 This is a structural diagram of an electronic device provided in an embodiment of the present application.

[0012] Description of reference numerals: 300, electronic device; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. DETAILED DESCRIPTION

[0013] In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments.

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

[0015] In the description of the embodiments of the present application, the term "multiple" means two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals. In addition, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0016] The following will provide a clear and complete description of the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments.

[0017] Please refer to Figure 1 , a flowchart of a large-model intelligent agent dynamic tool arrangement method is proposed. The method can be implemented by a computer program, a single-chip microcomputer, or run on a large-model intelligent agent dynamic tool arrangement system. The computer program can be integrated into a computer device or run as an independent tool application. Specifically, the method includes steps 10 to 50, which are as follows: 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.

[0018] Among them, in the embodiment of the present application, the open platform refers to a third-party service platform that provides labor 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.

[0019] See Figure 2 , is a schematic diagram of an open capability list of an open platform provided in an embodiment of the present application, Figure 2 This section displays all business modules and their corresponding API counts for the open platform, including workforce management modules such as HR (31 APIs), Attendance (83 APIs), and Scheduling (14 APIs). This summary displays all available interfaces retrieved from the open platform via the API metadata parser, providing basic data support for subsequent tool configuration and agent invocation.

[0020] Interface metadata refers to data information that describes the characteristics of the open platform interface, including the interface call address, interface function description, request parameter format, response data structure and other information. These metadata define how to interact with the open platform.

[0021] The tool library refers to a data warehouse used to store and manage registered tool descriptions. The tool descriptions use a standardized format to record the functional characteristics and calling methods of each management tool, making it easier for the system to retrieve and call tools.

[0022] Specifically, the interface metadata provided by the open platform is first obtained through an HTTP request. This metadata contains information such as the interface's functional description, call address, and parameter definition. In order to facilitate the large model to understand and process this interface information, 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 of different open platforms, providing a basis for subsequent tool selection based on semantic similarity.

[0023] Based on the above embodiment, as another optional embodiment, the step of generating a standardized large model tool description based on the interface metadata and registering it in the tool library may further include the following steps: Step 101: Parse the interface description in the interface metadata and generate tool information including the tool name and function description.

[0024] Specifically, the interface description text is first extracted from the interface metadata. The text usually contains natural language descriptions such as the interface's functional description 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 combine actions and objects to generate standardized tool names based on preset tool naming rules. At the same time, the system retains information such as scenario descriptions and usage restrictions in the original description text as functional descriptions. Finally, the system integrates the tool name and functional description into structured tool information. This standardized tool information extraction method ensures the accuracy and consistency of the tool description.

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

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

[0027] Step 103: Combine the tool information and parameter definition into a tool description in JSON format, and register the tool description in the tool library.

[0028] Specifically, the system uses a preset JSON template to organize tool information and parameter definitions. The template contains key fields such as basic tool information, parameter list, and call configuration. The system first fills the tool information into the basic information part of the template, including the tool name, function description, etc. The standard parameter definitions are then organized into a parameter array and filled into the parameter list part of the template. The system also automatically adds management information such as the tool version number and creation time. After completing the generation of the JSON format tool description, the system calls the registration interface of the tool library, saves the tool description into the database, and creates a corresponding index to facilitate subsequent tool retrieval.

[0029] Step 20: Receive a query request from the user, and determine a target tool based on the semantic similarity between the query request and the descriptions of each tool in the tool library.

[0030] In this embodiment, a query request refers to a business requirement described by an enterprise manager in natural language, such as "Query Zhang San's attendance records for this month" or "Calculate the overtime hours in the R&D department." This query request contains the management operation the user wishes to perform and related business parameter information. The system needs to understand the business semantics and convert it into specific tool call instructions.

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

[0032] Specifically, after receiving the user's query request, the system first calls the 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 semantic vector of fixed dimension. Then, all tool descriptions are obtained from the tool library, and each tool description is also converted into a corresponding tool vector. The system calculates the cosine similarity between the query vector and each tool vector, and selects tools with a similarity higher than the preset threshold as candidate tools. Finally, the system calculates indicators such as the success rate and response time of each candidate tool based on historical call records, and after comprehensive evaluation, selects the tool with the highest score as the target tool. This tool selection method based on semantic similarity improves the accuracy of the system's understanding of user needs.

[0033] Based on the above embodiment, 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: Step 201: Input the query request into the large model to extract the intent information and generate the corresponding query vector.

[0034] Specifically, the system first segmented and normalized the query request, removing stop words and unifying the text format. The large model then encodes the processed text using a multi-layer 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 a query vector that represents the query semantics. This large-model-based intent extraction method can accurately understand the user's query intent.

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

[0036] 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 organizes tool vectors using vector indexing technology. When calculating similarity, the system uses the cosine similarity formula to calculate the degree of similarity between the query vector and each tool vector, with similarity values ​​ranging from [0, 1]. Tools with a similarity greater than 0.8 are selected as candidate tools. If there are fewer than three candidate tools, the similarity threshold is adaptively lowered until the minimum number of candidates is met. This vector similarity-based screening mechanism ensures the relevance of candidate tools to user needs.

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

[0038] Specifically, the system calculates the availability score of candidate tools based on historical call records. The system collects statistics from the call logs for each candidate tool's recent call success rate, average response time, and error rate. The system then calculates a standard score for each metric based on pre-set scoring rules, with a weight of 0.4 for call success rate, 0.3 for response time, and 0.3 for error rate. The system sums these weighted scores to determine the availability score of the candidate tool. Finally, the system selects the tool with the highest availability score as the target tool and records the selection result in the call log. This historical data-based evaluation method improves the reliability of tool selection.

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

[0040] In the embodiment of the present application, the interface call parameters refer to the standardized parameters required by the open platform interface, and these parameters need to comply with the calling specifications of the interface.

[0041] Specifically, the system first uses a large model to extract business parameters from query requests. For example, in the query "Query Zhang San's attendance records for this month," it identifies the person "Zhang San" and the time range "this month." The system then retrieves the parameter definition of the target tool and specifies the parameter format required by the interface. For example, "employee_id" requires a uniform employee ID format, and "time_range" requires a standard timestamp format. The system then calls a parameter conversion module to standardize the extracted business parameters, including converting names into employee IDs and relative time descriptions into 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 approach resolves discrepancies between user natural language descriptions and interface specification requirements.

[0042] Based on the above embodiment, 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: Step 301: extract key business parameter information from the query request and generate a parameter list to be mapped.

[0043] Specifically, the system uses a large model to perform semantic analysis on query requests. First, it uses a named entity recognition model to identify business entities in the text, such as names of people, department names, and time. It then uses dependency parsing to determine the relationships between entities and extract corresponding modifiers and qualifiers. For example, from "Query Zhang San's attendance records in the R&D department last month", the system identifies entities such as the person "Zhang San", the time "last month", and the department "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. Each parameter item contains a parameter value and parameter type label. This semantic parameter extraction method ensures the integrity and semantic accuracy of business parameters.

[0044] Step 302: semantically match the parameter list to be mapped based on the parameter definition of the target tool to obtain a parameter mapping relationship.

[0045] 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 parameters to be mapped and the tool parameters. Specifically, the system uses the BERT model to encode the parameter description text and uses an attention mechanism to calculate the degree of matching between the parameters. 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 are presented, the system selects them based on the parameter type and business rules.

[0046] Step 303: Convert the parameter list to be mapped into target format parameters according to the parameter mapping relationship and preset mapping rules.

[0047] Specifically, the system uses the obtained parameter mappings to call the corresponding parameter converter to perform format conversion. For time parameters, the system converts relative time descriptions (such as "last month") into a standard time format. For personnel parameters, the system queries the personnel information database to convert names into employee numbers. For department parameters, the system converts department names into department codes based on the organizational structure tree. The system also handles unit conversion and format standardization to ensure that the converted parameters meet the format requirements of the target tool.

[0048] Step 304: Perform data type verification and mandatory item check on the target format parameters, automatically complete the missing parameters, and generate the final interface call parameters.

[0049] Specifically, the system performs a comprehensive verification of the converted target format parameters. First, it checks whether the data type of each parameter complies with the interface definition, including constraints such as the value range and character length. Then, the integrity of the required parameters is verified. For missing required parameters, the system automatically completes them based on the preset default value rules or historical call records. For example, when the time zone parameter is missing, the system automatically fills in the default time zone based on the user's location. Finally, the system assembles the verified parameters into the final call parameters according to the data structure required by the interface. This strict parameter verification and completion mechanism ensures the reliability of interface calls.

[0050] Step 40: Execute the interface call corresponding to the target tool based on the interface call parameters, and pre-process the call result.

[0051] Specifically, an interface call request is initiated to the open platform corresponding to the target tool through the HTTP protocol, and the interface call parameters are encapsulated in the request body according to the format defined by the interface. The system adopts an asynchronous call method, sets a reasonable timeout time and retry mechanism, and automatically retries when a call failure is detected. After receiving the call response, the system first checks the response status code to confirm whether the call is successful. For successful calls, the system parses the response data, extracts valid business information, and performs data cleaning, including removing redundant fields, unifying data formats, sorting and grouping, and other operations. This standardized call and preprocessing mechanism ensures the stability of the interface call and the availability of the returned data.

[0052] Based on the above embodiment, 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: Step 4011: Generate a call request based on the call address and interface call parameters of the target tool.

[0053] Specifically, the system obtains the target tool's call configuration information from the tool library, including the call 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 interface's required data structure, and adds it to the request body. At the same time, the system generates a unique request identifier and adds security fields such as authentication information and a timestamp to the request header. For interfaces that require 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 call request.

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

[0055] Specifically, the system starts the performance monitoring module, records the start time of the call, and then sends the call request through the HTTP client. The system monitors the execution status of the request in real time, including indicators such as network latency, response time, and data transmission volume. When the response data is received, the system records the end time of the call and calculates the total time consumed. For timed-out or failed requests, the system triggers a retry mechanism and retries up to 3 times. The system saves the performance indicators collected during the call process, such as request duration, number of retries, response status, and other information, to the call log. This complete performance monitoring mechanism helps to evaluate and optimize the efficiency of interface calls.

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

[0057] Specifically, first check the status code of the response result to confirm whether the call is successful. For successful calls, the system parses the JSON structure of the response data and extracts the business data fields. The system standardizes the business data according to the preset data processing rules, including field name mapping, data type conversion, time format unification, etc. For numerical data, the system will perform unit conversion and precision processing; for text data, the system will perform encoding conversion and special character processing. This standardized data processing process ensures the consistency and availability of business data. Step 4014: Integrate the converted business data with the performance indicators to generate standardized call results.

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

[0059] Based on the above embodiment, as another optional embodiment, the step of preprocessing the call result may further include the following steps: Step 4021: Perform anomaly detection on the call result and generate an anomaly detection report.

[0060] Specifically, the response status code of the call result is first checked, and any status code other than 200 is marked as a call exception. The system then traverses the JSON structure of the response data, checks whether required fields exist, and records missing fields as integrity exceptions. For each field, the system performs format verification based on a predefined data format template, including data type matching, length restrictions, value ranges, etc., and marks fields that do not meet format requirements as format exceptions. Finally, the system integrates these exceptions into basic exception identification, which includes abnormal fields, abnormal descriptions, and abnormal location information. This multi-level basic anomaly detection mechanism ensures the basic availability of data.

[0061] Furthermore, the system loads a preset set of business rules, including numerical range limits, data association constraints, and timing logic. The system uses a rules engine to verify key business indicators in the call results, such as attendance time and the number of dispatched personnel. For example, it checks whether attendance time 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 exception flag, recording the offending metric, the reason for the violation, and relevant contextual information. This business rule-based verification method ensures the business legitimacy of the data.

[0062] Next, the system loads the anomaly classification rules and level determination criteria from the anomaly rule library. The system performs pattern matching on detected basic and business anomaly identifiers, categorizing the anomalies into predefined anomaly types, such as network anomalies, data anomalies, and business anomalies. The system then assesses the impact and severity of the anomaly and calculates the anomaly level based on pre-set scoring rules, categorizing it into warning, error, and severe error levels.

[0063] Finally, anomaly detection results are organized using a standard report template. First, anomalies are grouped and sorted by level, with high-level anomalies prioritized. For each anomaly, the system records its type, level, location, and detailed description. Based on the anomaly type and level, the system also selects appropriate action suggestions from a library of pre-set handling strategies, such as retry, alert, and manual intervention. Finally, the system integrates this information into a structured anomaly detection report to facilitate subsequent anomaly handling and analysis.

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

[0065] Specifically, retry decisions are made based on the anomaly information in the anomaly detection report. The system first determines whether the anomaly type is retryable, such as a network timeout or temporary service unavailability. For retryable anomalies, the system checks whether the current number of retries exceeds the maximum limit (3 by default) and assesses the cost and success probability 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 result and records the decision basis. This intelligent retry decision-making mechanism improves the success rate of interface calls.

[0066] Step 4023: 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.

[0067] Specifically, when a retry is needed, the system directly returns to executing the interface call corresponding to the target tool based on the interface call parameters. The system retains the original interface call parameters and re-executes the step of calling the target tool, that is, re-initiating the interface call request to the call address of the target tool. This return-to-retry mechanism ensures that the original parameters can be reused for re-calling if the call fails, thereby improving the success rate of the interface call.

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

[0069] Specifically, when a retry is not required, the system loads pre-set data cleansing rules and processes call results that pass anomaly detection. The system first performs data filtering, removing duplicate records, records with empty values, and abnormal records that do not comply with business rules. The system then performs data completion, filling in missing values ​​in required fields according to pre-set rules, such as using default values, historical averages, or derived values ​​from related fields. For example, if information about an employee's department is missing, the system retrieves and supplements it from the employee's basic information. This data cleansing mechanism, based on pre-set rules, ensures data integrity and standardization.

[0070] Step 4025: perform index calculation and structural processing on the cleaned data to obtain the pre-processed call result.

[0071] Specifically, the system performs statistical analysis and structured processing on the cleaned data. First, it calculates key business indicators, such as total data volume, averages, and distribution characteristics. For multidimensional data, the system generates pivot tables to display summary results across different dimensions. The system also categorizes and aggregates the data to create a hierarchical data structure, facilitating display and analysis by higher-level applications. Finally, the system organizes the processed data into a standard format, generating a complete result set containing raw data, statistical indicators, and metadata.

[0072] Step 50: Display the pre-processed call results in a visual form.

[0073] Specifically, the system first identifies the business type of the call result, such as attendance data, shift scheduling data, and personnel scheduling data, and selects appropriate display templates for each type of data. For attendance data, the system uses a calendar heat map 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 schedules, distinguishing shift types by color. For personnel scheduling data, the system uses a Sankey diagram to display personnel flow relationships.

[0074] During presentation, the system supports multi-dimensional data pivoting, allowing users to switch data views by department, time, personnel, and other dimensions. For cross-module collaborative data, the system automatically correlates data, for example, comparing attendance anomalies with the shift schedule and highlighting any anomalies. The system also adds business-related annotations to charts, such as statutory holidays and schedule conflict notifications.

[0075] See Figure 3 , is a module diagram of a large-model intelligent agent dynamic tool orchestration system provided in an embodiment of the present application, wherein the system includes: A tool library generation module is used to obtain the interface metadata of the open platform, generate a standardized large model tool description based on the interface metadata, and register it in the tool library; A target tool determination module is configured to receive a query request from a user and determine a target tool based on semantic similarity between the query request and the descriptions of each tool in the tool library; An interface parameter determination module, configured to map the business parameters in the query request to interface call parameters of the target tool; An interface call execution module, configured to execute an interface call corresponding to the target tool based on the interface call parameters and pre-process the call result; The call result display module is used to display the preprocessed call results in a visual form.

[0076] Optionally, the tool library generation module is further configured to parse the interface description in the interface metadata and generate tool information including a tool name and a function description; Converting the request parameters in the interface metadata into standardized parameter definitions; The tool information and the parameter definition are combined into a tool description in JSON format, and the tool description is registered in a tool library.

[0077] Optionally, the target tool determination module is further configured to input the query request into the large model to extract intent information and generate a corresponding query vector; Calculating the similarity between the query vector and the vector descriptions of each tool in the tool library, and selecting tools with similarity greater than a preset threshold as candidate tools; The availability score of each candidate tool is calculated based on the historical call records, and the tool with the highest score is selected as the target tool.

[0078] Optionally, the interface parameter determination module is further configured to extract key business parameter information from the query request and generate a parameter list to be mapped; Performing semantic matching on the parameter list to be mapped based on the parameter definition of the target tool to obtain a parameter mapping relationship; According to the parameter mapping relationship and the preset mapping rules, the parameter list to be mapped is converted into target format parameters; The target format parameters are checked for data type and required items, and the final interface call parameters are generated after automatically completing the missing parameters.

[0079] Optionally, the interface call execution module is further configured to generate a call request based on the call address of the target tool and the interface call parameters; Obtaining a response result of the target tool to the call request and recording performance indicators of the call process; Parsing the business data in the response result and converting the format according to the preset data processing rules; The converted business data is integrated with the performance indicators to generate standardized call results.

[0080] Optionally, the interface call execution module is further configured to perform anomaly detection on the call result and generate an anomaly detection report; Determine whether a retry is required based on the anomaly detection report; If a retry is required, returning to the step of executing the interface call corresponding to the target tool based on the interface call parameters; If retry is not 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 structural processing to obtain a pre-processed call result.

[0081] Optionally, the interface call execution module is further used to detect the response status code, data integrity and data format of the call result, and generate a corresponding basic exception identifier; Verify the validity of the key business indicators in the call result according to the preset business rules and generate a business exception mark; Based on a preset exception rule library, the basic exception identifier and the business exception identifier are analyzed to determine the exception type and exception level; The anomaly type, anomaly level and corresponding processing suggestions are integrated to generate an anomaly detection report.

[0082] It should be noted that the above embodiments provide systems that implement their functions using only the division of the above functional modules as an example. 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 are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0083] An embodiment of the present application also provides a computer storage medium, which can store multiple instructions. The instructions are suitable for being loaded by a processor and executing a large-model intelligent body dynamic tool orchestration method of the above embodiment. The specific execution process can be found in the specific description of the above embodiment and will not be repeated here.

[0084] Please refer to Figure 4 The present application also discloses an electronic device. Figure 4 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 .

[0085] The communication bus 302 is used to implement the connection and communication between these components.

[0086] The user interface 303 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0087] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0088] The processor 301 may include one or more processing cores. Using various interfaces and circuits, the processor 301 connects to various components within the server. It executes instructions, programs, code sets, or instruction sets stored in the memory 305, as well as accesses data stored in the memory 305, to perform various server functions and process data. Optionally, the processor 301 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 301 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing content displayed on the display screen; and the modem handles wireless communications. It is understood that the modem may not be integrated into the processor 301 but implemented as a separate chip.

[0089] Among them, the memory 305 may include a random access memory (RAM) or a read-only memory (Read-Only Memory). Optionally, the memory 305 includes a non-transitory computer-readable storage medium. The memory 305 can be used to store instructions, programs, codes, 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 a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 305 may also optionally be at least one storage device located away from the aforementioned processor 301. Refer to Figure 4 , as a computer storage medium, the memory 305 may include an operating system, a network communication module, a user interface module, and an application program of a large model intelligent agent dynamic tool orchestration method.

[0090] exist Figure 4In the electronic device 300 shown, the user interface 303 is mainly used to provide an input interface for the user and obtain the data input by the user; and the processor 301 can be used to call an application program stored in the memory 305 for a large model intelligent body dynamic tool arrangement method. When executed by one or more processors 301, the electronic device 300 executes one or more methods such as those in the above-mentioned embodiments. It should be noted that for the aforementioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should know that this application is not limited to the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required for this application.

[0091] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0092] In the several embodiments provided in this application, it should be understood that the disclosed devices can be implemented in other ways. For example, the device embodiments described above are merely schematic, such as the division of units, which is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some service interface, and the indirect coupling or communication connection of devices or units can be electrical or other forms.

[0093] Units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0094] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0095] 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 memory. Based on this understanding, the technical solution of this application, or the portion 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 for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the method of this application. The aforementioned memory includes various media that can store program code, such as USB flash drives, mobile hard drives, magnetic disks, or optical disks.

[0096] The above are merely exemplary embodiments of the present disclosure and are not intended to limit the scope of the present disclosure. In other words, any equivalent variations and modifications made in accordance with the teachings of the present disclosure are still within the scope of the present disclosure. Those skilled in the art will readily conceive of other embodiments of the present disclosure after considering the disclosure and the practical implications thereof.

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

Claims

1. A large-scale intelligent agent dynamic tool arrangement method, characterized in that: The method comprises: Obtaining interface metadata of the open platform, generating a standardized large model tool description based on the interface metadata, and registering the description in the tool library; receiving a query request from a user, and determining a target tool based on semantic similarity between the query request and descriptions of each tool in the tool library; Mapping the business parameters in the query request to interface call parameters of the target tool; Executing an interface call corresponding to the target tool based on the interface call parameters, and preprocessing the call result; The preprocessed call results are displayed in a visual form.

2. The large model agent dynamic tool arrangement method according to claim 1 is characterized in that: The step of generating a standardized large model tool description based on the interface metadata and registering the description in the tool library includes: Parsing the interface description in the interface metadata to generate tool information including a tool name and a function description; Converting the request parameters in the interface metadata into standardized parameter definitions; The tool information and the parameter definition are combined into a tool description in JSON format, and the tool description is registered in a tool library.

3. The large model agent dynamic tool arrangement method according to claim 1 is characterized in that: The determining of the target tool based on the semantic similarity between the query request and the descriptions of each tool in the tool library includes: Input the query request into the big model to extract intent information and generate a corresponding query vector; Calculating the similarity between the query vector and the vector descriptions of each tool in the tool library, and selecting tools with similarity greater than a preset threshold as candidate tools; The availability score of each candidate tool is calculated based on the historical call records, and the tool with the highest score is selected as the target tool.

4. The large model agent dynamic tool arrangement method according to claim 1, characterized in that: Mapping the business parameters in the query request to interface call parameters of the target tool includes: Extracting key business parameter information from the query request and generating a parameter list to be mapped; Performing semantic matching on the parameter list to be mapped based on the parameter definition of the target tool to obtain a parameter mapping relationship; According to the parameter mapping relationship and the preset mapping rules, the parameter list to be mapped is converted into target format parameters; The target format parameters are checked for data type and required items, and the final interface call parameters are generated after automatically completing the missing parameters.

5. The large model agent dynamic tool arrangement method according to claim 1 is characterized in that: The executing the interface call corresponding to the target tool based on the interface call parameter includes: Generate a call request based on the call address of the target tool and the interface call parameters; Obtaining a response result of the target tool to the call request and recording performance indicators of the call process; Parsing the business data in the response result and converting the format according to the preset data processing rules; The converted business data is integrated with the performance indicators to generate standardized call results.

6. The large model agent dynamic tool arrangement method according to claim 1 is characterized in that: The preprocessing of the call result includes: Performing anomaly detection on the call result and generating an anomaly detection report; Determine whether a retry is required based on the anomaly detection report; If a retry is required, returning to the step of executing the interface call corresponding to the target tool based on the interface call parameters; If retry is not 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 structural processing to obtain a pre-processed call result.

7. The large model agent dynamic tool arrangement method according to claim 6 is characterized in that: The performing anomaly detection on the call result and generating an anomaly detection report includes: Detect the response status code, data integrity and data format of the call result, and generate a corresponding basic exception identifier; Verify the validity of the key business indicators in the call result according to the preset business rules and generate a business exception mark; Based on a preset exception rule library, the basic exception identifier and the business exception identifier are analyzed to determine the exception type and exception level; The anomaly type, anomaly level and corresponding processing suggestions are integrated to generate an anomaly detection report.

8. A large-scale intelligent agent dynamic tool arrangement system, characterized in that: The system comprises: A tool library generation module is used to obtain the interface metadata of the open platform, generate a standardized large model tool description based on the interface metadata, and register it in the tool library; A target tool determination module is configured to receive a query request from a user and determine a target tool based on semantic similarity between the query request and the descriptions of each tool in the tool library; An interface parameter determination module, configured to map the business parameters in the query request to interface call parameters of the target tool; An interface call execution module, configured to execute an interface call corresponding to the target tool based on the interface call parameters and pre-process the call result; The call result display module is used to display the preprocessed call results in a visual form.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by a processor and executing the method according to any one of claims 1 to 7.

10. An electronic device, characterized in that: The electronic device comprises a processor, a memory, a user interface and a network interface, wherein 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 so that the electronic device executes the method according to any one of claims 1 to 7.

Images