Data processing method and electronic device

Abstract

The present disclosure provides a data processing method and an electronic device, comprising: obtaining tool calling information corresponding to an input task; the tool calling information comprising at least one tool and associated control parameters; determining a control strategy based on the control parameters; guiding at least one processing link according to the control strategy and performing corresponding operations according to the control strategy; the at least one processing link being a link capable of affecting the output corresponding to the tool calling result in the task execution process.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, and in particular to a data processing method and an electronic device. Background Technology

[0002] During the execution of the tool, the tool's output and subsequent processing logic cannot adapt to the task scenario, affecting task execution efficiency and user experience. Summary of the Invention

[0003] This disclosure provides a data processing method and an electronic device.

[0004] According to one aspect of this disclosure, a data processing method is provided, comprising: acquiring tool invocation information corresponding to an input task; the tool invocation information including at least one tool and associated control parameters; determining a control strategy based on the control parameters; guiding at least one processing step according to the control strategy, and performing a corresponding operation according to the control strategy; wherein the at least one processing step is a step that can affect the output corresponding to the tool invocation result during task execution.

[0005] Another aspect of this disclosure provides an electronic device, including: a processor and a memory communicatively connected to the processor; wherein the memory stores instructions executable by the processor, the instructions being executed by the processor to: acquire tool invocation information corresponding to an input task; the tool invocation information including at least one tool and associated control parameters; determine a control strategy based on the control parameters; guide at least one processing step according to the control strategy to perform a corresponding operation according to the control strategy; the at least one processing step is a step that can affect the output corresponding to the tool invocation result during task execution.

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

[0007] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0008] Figure 1 This is a flowchart of a data processing method according to an embodiment of the present disclosure;

[0009] Figure 2 This is a flowchart of a data processing method according to another embodiment of the present disclosure;

[0010] Figure 3(a) is a schematic diagram of stage identification according to an embodiment of the present disclosure;

[0011] Figure 3(b) is a schematic diagram of stage identification according to another embodiment of the present disclosure;

[0012] Figure 3(c) is a schematic diagram of stage identification according to yet another embodiment of the present disclosure;

[0013] Figure 4 This is a flowchart of a data processing method according to yet another embodiment of the present disclosure;

[0014] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure; and

[0015] Figure 6 This is a schematic block diagram of an example electronic device used to implement embodiments of the present disclosure. Detailed Implementation

[0016] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0017] In the technical solutions disclosed herein, the collection, storage, use, processing, transmission, provision, disclosure, and application of data (including but not limited to user personal information) comply with the provisions of relevant laws and regulations, necessary confidentiality measures have been taken, and they do not violate public order and good morals.

[0018] Figure 1 This is a flowchart of a data processing method according to an embodiment of the present disclosure.

[0019] like Figure 1 As shown, the data processing method of this embodiment includes operations S110-S130.

[0020] In operation S110, tool call information corresponding to the input task is obtained; the tool call information includes at least one tool and associated control parameters.

[0021] In embodiments of this disclosure, a tool refers to a logical unit or code module capable of performing a specific function, such as an Application Programming Interface (API), a script function, a command-line tool, or an executable program. For example, a file search tool is used to retrieve files, a document generation tool is used to create a Portable Document Format (PDF), and a database query tool is used to obtain data.

[0022] In the embodiments of this disclosure, tool invocation information refers to a set of data characterizing the resources and control instructions required for task execution. Tool invocation information includes at least one tool (the entity executing the input task) and control parameters (execution constraints).

[0023] In the embodiments of this disclosure, control parameters refer to identifying data used to constrain or guide tool execution and result processing. For example, control parameters may be a set of metadata embedded in tool invocation information, used to regulate the tool execution environment and result flow. It should be noted that, unlike the business parameters required for tool execution, control parameters do not directly affect the tool's internal algorithm logic, but rather act on the tool's external operating environment and subsequent processing flow.

[0024] In the embodiments of this disclosure, the input task can be a natural language command entered by the user through the interface (such as "query invoice status"), or it can be an API call request triggered internally by the system. The tool is the specific means of performing the input task, and the control parameters are labels attached to the tool.

[0025] In the embodiments of this disclosure, tool invocation information corresponding to the input task is obtained. The set of tools required to complete the task can be identified through parsing, and corresponding control parameters can be assigned to each tool.

[0026] For example, input tasks are fed into the model, and after parsing the task semantics, the model outputs planning results containing a list of tools to be called and associated control parameters.

[0027] For example, the system pre-stores task templates. When an input task matches the corresponding template, it directly calls the tools predefined in the template and configures the corresponding control parameters for each tool according to the template rules.

[0028] For example, the system searches for the corresponding tool and associated control parameters from a preset mapping relationship based on the feature identifier of the input task.

[0029] In operation S120, the control strategy is determined based on the control parameters.

[0030] In embodiments of this disclosure, the control strategy refers to guiding rules generated based on control parameters for coordinating the behavior of various processing stages.

[0031] In the embodiments of this disclosure, a control strategy is determined based on control parameters. The system reads the control parameters and generates a specific control strategy according to preset logical rules. The control strategy determines the flow, form, and importance level of data in subsequent processing stages.

[0032] In operation S130, at least one processing step is guided according to the control strategy to perform the corresponding operation; the at least one processing step is a step that can affect the output corresponding to the tool call result during the task execution process.

[0033] In the embodiments of this disclosure, the processing stage refers to a functional module in the task execution chain that can process, transfer, or present the output results of the tool. The processing stage covers, but is not limited to, data formatting modules, interface rendering modules, log writing modules, and system monitoring modules.

[0034] In the embodiments of this disclosure, at least one processing stage is guided by a control strategy to perform corresponding operations. The system acts as a scheduling hub, distributing the control strategy to at least one preset processing stage. Upon receiving the control strategy, each processing stage no longer operates independently based on default logic or local configuration, but instead uses the control strategy as the highest priority execution criterion. Specifically, each processing stage can parse the behavioral constraints and handling requirements contained in the control strategy and adjust its own processing logic for the tool invocation results accordingly.

[0035] For example, one processing stage may be guided to perform data pruning operations to reduce redundancy, another processing stage may be guided to adjust the data flow path to adapt to specific storage requirements, and other stages may be guided to change the external presentation intensity of the data to adapt to different interaction scenarios.

[0036] Through the embodiments of this disclosure, a global control strategy is generated by unified control parameters, guiding each processing stage to work collaboratively according to rules adapted to the task scenario. This solves the problem that the tool output and subsequent processing cannot adapt to the task scenario, effectively reduces redundant calculations, improves task execution efficiency, and optimizes the user interaction experience.

[0037] In some embodiments of this disclosure, at least one processing step is guided by a control strategy to perform corresponding operations according to the control strategy, including at least one of the following: configuring the output logic of the tool according to the control strategy to affect the output results after the tool is executed; configuring the display logic of the tool call results according to the control strategy to affect the presentation method of the output results after the tool is executed; configuring the log processing logic of the tool call results according to the control strategy to affect the logging method of the output results after the tool is executed; and configuring the monitoring processing logic of the tool call results according to the control strategy to affect the monitoring method of the output results after the tool is executed.

[0038] In the embodiments of this disclosure, the multi-dimensional implementation of control strategies in specific processing stages is described, aiming to customize behaviors differently based on the characteristics of different stages. The system reads the determined control strategy and maps it to specific configuration parameters for each processing stage, thereby achieving refined process control.

[0039] In the embodiments of this disclosure, output logic refers to the data organization rules and format specifications followed by the tool when generating execution results, which determines the composition and level of detail of the output content. For example, output logic can be defined as returning the complete dataset or only returning the index identifiers of the data.

[0040] In embodiments of this disclosure, the output logic of the tool is configured according to a control strategy to influence the output results after the tool is executed. This embodiment intervenes in the execution behavior of the tool itself. The system can adjust the data packaging method within the tool based on the processing requirements implied in the control strategy.

[0041] For example, when the control strategy indicates that the current process needs to be efficient, the output logic of the configuration tool is to generate only lightweight structured data and remove redundant descriptive information, thereby reducing data transmission overhead and adapting to downstream processing needs.

[0042] In the embodiments of this disclosure, display logic refers to the rendering rules used by the front-end interface or other interactive terminal to visualize the output results of the tool. For example, display logic can be defined as pop-up display or display in the form of collapsed items.

[0043] In embodiments of this disclosure, the display logic of tool call results is configured according to a control strategy to influence the presentation of the output results after tool execution. This embodiment focuses on regulating the user-facing interactive interface. The system can adjust the rendering mode of the front-end interface based on the presentation intensity requirements implied in the control strategy.

[0044] For example, when the control strategy indicates that the current result is only of reference value, the configuration display logic is to simplify rendering to avoid occupying too much visual space on the main interface, thereby reducing interface noise and improving interaction focus.

[0045] In the embodiments of this disclosure, log processing logic refers to the storage rules followed by the background system when persistently recording the output results of the tool, involving the filtering of recorded content and the retention period. For example, log processing logic can be defined as full recording or recording only error stack information.

[0046] In the embodiments of this disclosure, the log processing logic for tool call results is configured according to the control policy to influence the logging method for the output results after tool execution. This embodiment sets up a background data retention mechanism. The system can adjust the log system's writing strategy based on the storage priority requirements implied in the control policy.

[0047] For example, when the control policy indicates that the current operation is of low importance, the log processing logic is configured to reduce the granularity of recording and retain only the key status codes, thereby saving storage resources and improving log retrieval efficiency.

[0048] In the embodiments of this disclosure, monitoring and processing logic refers to the analysis rules followed by the operation and maintenance system when monitoring the status of tool output results and issuing anomaly alarms. For example, monitoring and processing logic can be defined as triggering real-time alarms or simply performing periodic statistical analysis.

[0049] In the embodiments of this disclosure, the monitoring and processing logic for tool call results is configured according to the control strategy to influence the monitoring method for the output results after tool execution. This embodiment defines a perception mechanism for system operating status. The system can adjust the sampling and analysis frequency of the monitoring system based on the monitoring level requirements implied in the control strategy.

[0050] For example, when the control policy indicates that the current operation is a normal process, the monitoring and processing logic is configured to be silent monitoring to avoid unnecessary alarm interference, thereby ensuring that the operations and maintenance team focuses on core abnormal events.

[0051] Through the embodiments disclosed herein, multi-dimensional logical configuration enables precise penetration of control strategies into each link of the processing chain, optimizes resource allocation, and improves the targeting and management efficiency of system operation.

[0052] In some embodiments of this disclosure, the output logic of the configuration tool is configured according to the control strategy to affect the output result after the tool is executed, including: determining the corresponding encapsulation rule from multiple output encapsulation rules according to the control strategy; generating the corresponding tool invocation configuration based on the corresponding encapsulation rule; and invoking the tool using the tool invocation configuration to obtain the output result corresponding to the corresponding encapsulation rule.

[0053] In the embodiments of this disclosure, the output encapsulation rule refers to a predefined logical template used to standardize the data structure and content granularity returned by the tool. The output encapsulation rule specifies the data fields, organization format, and level of detail that the output result should include.

[0054] For example, one output encapsulation rule can be defined as outputting a rich text structure containing complete descriptive information and data entities, while another output encapsulation rule can be defined as outputting a lightweight structure that only outputs data indexes or critical paths.

[0055] In the embodiments of this disclosure, a corresponding encapsulation rule is determined from multiple output encapsulation rules according to the control strategy. This embodiment can establish a mapping relationship between the control strategy and specific execution templates. The system has a pre-set rule set containing multiple encapsulation rules, each rule corresponding to a typical data output mode. The system parses the processing requirements contained in the control strategy, matches and compares them with each encapsulation rule in the rule set, and selects the rule that best suits the current task scenario.

[0056] For example, if the control policy indicates that the amount of data transmission should be reduced, the system selects an encapsulation rule from the rule set that tends to output concise, structured data.

[0057] In the embodiments of this disclosure, the tool invocation configuration refers to a specific set of parameters generated according to the selected encapsulation rules for injecting into the tool execution context. The tool invocation configuration is an executable carrier of the encapsulation rules.

[0058] In the embodiments of this disclosure, corresponding tool invocation configurations are generated based on the relevant encapsulation rules. This embodiment transforms abstract encapsulation rules into execution instructions that the tool can recognize. The system reads the encapsulation rules selected in the previous step, parses the data structure requirements and content restrictions defined therein, and converts them into specific key-value pair parameters or environment variables.

[0059] In the embodiments of this disclosure, the output result refers to the data set generated and returned by the tool according to the configuration requirements after receiving and executing the configuration call. For example, the output result can be a detailed report for user reading, or a structured data packet for internal system circulation.

[0060] In the embodiments of this disclosure, a tool invocation configuration is used to invoke the tool to obtain output results corresponding to the encapsulation rules. In this embodiment, the system passes the generated invocation configuration as a parameter to the tool execution entry point. When the tool starts execution, it reads and parses the configuration, dynamically adjusts its own data generation logic, and generates results strictly according to the format and granularity defined in the tool invocation configuration.

[0061] For example, a tool configured with the "simplified output" parameter will skip the process of generating natural language descriptions and visualizations after execution, and only return the identification information or core data required by the downstream process, thereby ensuring that the output results are consistent with the expectations of the encapsulation rules.

[0062] Through the embodiments disclosed herein, by dynamically matching encapsulation rules and precisely injecting call configurations, deep adaptation between tool output content and task scenarios is achieved. This effectively reduces transmission and processing overhead while ensuring data availability, thereby improving the overall operating efficiency of the system.

[0063] In some embodiments of this disclosure, determining a corresponding encapsulation rule from multiple output encapsulation rules according to a control strategy includes: determining a first encapsulation rule in response to tool invocation information including a single tool, to output information containing a description of the tool execution result; determining a second encapsulation rule in response to tool invocation information including multiple tools and the currently invoked tool being an intermediate step, to output structured data for use by subsequent tools; and determining a third encapsulation rule in response to tool invocation information including multiple tools and the currently invoked tool being a final step, to output result data formed based on the execution results of multiple tools.

[0064] This embodiment uses the task topology features contained in the tool invocation information to perform scenario-based precise matching of encapsulation rules, ensuring that the tool's output content highly matches its role in the execution stage. The system adaptively switches rules by analyzing the number of tools and the node attributes of the current tool.

[0065] In the embodiments of this disclosure, the first encapsulation rule refers to an output template applicable to scenarios where a single tool is executed independently. Its characteristic is that while outputting core data, it includes easily understandable descriptive information or status prompts. For example, when performing only a single query operation, the rule can be defined as returning a structure containing data entities and a "query successful" message.

[0066] In embodiments of this disclosure, in response to tool call information including a single tool, a first encapsulation rule is determined to output information containing a description of the tool execution result. This embodiment is optimized for independent task scenarios. When the system parses the tool call information and determines that only a single tool needs to be called to complete the user task, it determines to adopt the first encapsulation rule. At this time, since the tool execution result will be directly presented as the final deliverable, the system guides the tool to add necessary natural language descriptions or status indicators while outputting core data.

[0067] For example, when the weather query tool is invoked, the system applies the first encapsulation rule so that the output results include not only core data fields such as temperature and humidity, but also explanatory text such as "Today's weather is sunny and suitable for travel" that is easy for users to understand, thereby saving additional format conversion steps and improving interaction efficiency.

[0068] In the embodiments of this disclosure, the second encapsulation rule refers to the output template applicable to non-final steps in multi-tool collaboration scenarios. Its characteristic is the removal of redundant descriptive information, retaining only high-purity structured data necessary for downstream tools to perform logical processing or data flow. For example, after generating intermediate files, the rule can be defined as returning only the file index ID or storage path.

[0069] In embodiments of this disclosure, in response to tool invocation information including multiple tools and the currently invoked tool being an intermediate step, a second encapsulation rule is determined to output structured data for use by subsequent tools. This embodiment optimizes the workflow in multi-step tasks. When the system determines that the current tool is in the middle of a multi-tool chain (i.e., there are subsequent dependent tools), the second encapsulation rule is adopted. At this time, the tool's output does not need to consider readability, but should maximize its compatibility with downstream tools. The system guides the tool to remove all decorative content and output only standardized structured data.

[0070] For example, in a document processing pipeline, after the "format conversion tool" has completed its intermediate step, the system applies a second encapsulation rule, causing it to output only the converted file handle or temporary storage address, rather than the complete file content or preview information. This significantly reduces data transmission bandwidth consumption and avoids downstream processing failures due to format incompatibility.

[0071] In the embodiments of this disclosure, the third encapsulation rule refers to the output template applicable to the final step in a multi-tool collaborative scenario. Its characteristic is the aggregation, cleaning, and enhancement of multi-source data generated in the task chain to form a comprehensive result for the end user or business system. For example, after summarizing the results of multiple sub-tasks, the rule can be defined as returning a data package containing a complete analysis report, associated files, and an execution summary.

[0072] In the embodiments of this disclosure, in response to tool invocation information including multiple tools and the current invocation tool being the final step, a third encapsulation rule is determined to output result data based on the execution results of multiple tools. This embodiment optimizes the delivery stage in multi-step tasks. When the system determines that the current tool is the endpoint of the entire execution chain (i.e., no downstream dependent tools), the third encapsulation rule is adopted. At this time, the system guides the tool to assume the responsibility of result aggregation and presentation. The tool needs to integrate the output data of all the aforementioned intermediate steps and perform unified formatting, beautification, or compression packaging.

[0073] For example, in the complete data collection-cleaning-analysis-report generation chain, when the final step of "report generation" is executed, the system applies the third encapsulation rule to guide the tool to integrate the collected raw data, cleaned intermediate tables, and key indicators derived from the analysis into a comprehensive report containing charts, conclusions, and data appendices to meet the business needs of the end user.

[0074] Through the embodiments of this disclosure, by adapting the role positioning of different stages in single-step and multi-step tasks and dynamically switching the output encapsulation rules, the transmission and processing overhead of intermediate stages is significantly reduced while ensuring the quality of the final delivery, thereby improving the efficiency of system resource scheduling and user experience.

[0075] In some embodiments of this disclosure, the display logic for tool call results is configured according to a control policy, including at least one of the following: configuring a first display logic to fully display the call results according to the control policy; configuring a second display logic to display a summary of the tool call results according to the control policy; configuring a third display logic to hide the tool call results according to the control policy; configuring a fourth display logic to display the tool call results in the form of progress information according to the control policy; configuring a fifth display logic to display the tool call results after confirmation according to the control policy; and configuring a sixth display logic to display the tool call results after de-identification processing according to the control policy.

[0076] In the embodiments of this disclosure, the first display logic refers to the rule of presenting all information output by the tool on the interactive interface without omissions. For example, the generated complete report text, related charts, and data appendices are all loaded into the main display area.

[0077] In the embodiments of this disclosure, a first display logic is configured to fully display the call results according to a control strategy. This embodiment can be configured for high-value or final delivery type output results. When the control strategy indicates that the current result is a core focus for the user, the system activates the first display logic.

[0078] For example, after a single-step task is completed, the system determines the result as the final deliverable based on the strategy, and then calls the first display logic to display the report generated by the tool, which includes detailed text and graphics, in the center of the interface to ensure the completeness of the information obtained by the user.

[0079] In embodiments of this disclosure, the second display logic refers to a rule that extracts only the core elements or key conclusions from the tool's output and presents them in a simplified manner. For example, only the summary values ​​of data statistics, the final status code of task execution, or key prompts in a collapsed state are displayed.

[0080] In embodiments of this disclosure, a second display logic is configured to summarize the results of the display tool invocation, based on a control strategy. This embodiment can be configured for output results that are of reference value but not the core focus. The system activates the second display logic when the control strategy indicates that the current result only needs to be viewed in general.

[0081] For example, for the initial check step in a multi-step task, the system determines that the result does not need to be examined in detail based on the strategy, and then calls the second display logic to display a summary message of "Environment check passed" in the corner of the interface in the form of a label, which effectively avoids the situation of the interface being flooded with redundant logs.

[0082] In embodiments of this disclosure, the third display logic refers to rules that prevent the rendering of tool output content in the regular user viewport or interactive interface, typically allowing it to be viewed only in debug mode or background logs. For example, setting the raw return values ​​of underlying API calls and temporary file generation records to be invisible.

[0083] In embodiments of this disclosure, a third display logic for hidden tool call results is configured according to a control strategy. This embodiment can be configured for purely internal flow or low-value output results. The system activates the third display logic when the control strategy indicates that the current result is for internal system use only or is completely unnecessary for user awareness.

[0084] For example, for intermediate data transformation steps in a multi-step task, the system determines that the process is transparent to the user based on a strategy, and then calls the third display logic to keep the intermediate data of this step silent on the front-end interface, exposing only the back-end debugging interface to the developers.

[0085] In embodiments of this disclosure, the fourth display logic refers to rules that transform the tool's output into dynamic status indicators for presentation. For example, a detailed log of batch file processing might be transformed into a percentage progress bar or dynamic text such as "Processing item N".

[0086] In embodiments of this disclosure, a fourth display logic is configured to present tool call results in the form of progress information, according to a control strategy. This embodiment can be configured for output results of long-running or asynchronous executions. The system activates the fourth display logic when the control strategy indicates that the current task is in a continuous running state.

[0087] For example, when performing a large-scale file archiving task, the system determines that it needs to provide real-time progress feedback to the user based on the strategy, and then calls the fourth display logic to integrate the fragmented processing records generated in the background into a progress bar view of "50 / 100 files archived".

[0088] In the embodiments of this disclosure, the fifth display logic refers to the direct presentation of the interception tool's output, where an interactive confirmation interface pops up first, and the full content is only displayed after the user authorizes it. For example, before performing a high-risk or irreversible operation, a pop-up window displays the operation details and requires the user to click "Confirm Execution".

[0089] In embodiments of this disclosure, a fifth display logic is configured to show the tool call result after confirmation, according to a control policy. This embodiment can be configured for output results involving high risk or requiring accountability. The system activates the fifth display logic when the control policy indicates that the current operation is potentially destructive.

[0090] For example, before performing system cleanup or permission change operations, the system determines that secondary authorization from the user is required based on the policy, and then calls the fifth display logic to intercept the detailed change list returned by the tool. The interception is lifted and the list is displayed only after the user clicks the "confirm" button.

[0091] In the embodiments of this disclosure, the sixth display logic refers to the rule of transforming, masking, or replacing sensitive fields in the tool output before presenting the processed content. For example, replacing the middle segment of the ID number in the output result with asterisks before displaying it.

[0092] In embodiments of this disclosure, a sixth display logic is configured to present the results of tool invocation after anonymization, according to a control policy. This embodiment can be configured for output results containing private data or trade secrets. When the control policy indicates that the current result involves a risk of sensitive information disclosure, the system activates the sixth display logic.

[0093] For example, when displaying query results containing users' personal information, the system determines that privacy needs to be protected based on the policy, and then calls the sixth display logic to automatically identify and mask sensitive fields such as mobile phone numbers and email addresses, displaying only the de-identified secure text.

[0094] Through the embodiments disclosed herein, dynamic adaptation of interface presentation intensity and security level is achieved by configuring multi-dimensional display logic. While ensuring effective information delivery, interface noise is significantly reduced, privacy protection is strengthened, and interaction security and reliability are effectively improved.

[0095] In some embodiments of this disclosure, the log processing logic for the tool call results is configured according to the control policy, including: configuring at least one of the following: recording content, recording granularity, storage method, and visibility range of the log corresponding to the output result, according to the control policy.

[0096] In the embodiments of this disclosure, the recorded content refers to the raw data written to the log file, which determines which specific fields should be included in the log. For example, the recorded content can be configured to include only execution status and timestamps, or it can be configured to include complete input / output parameters, stack traces, and environment variables. This embodiment can filter the data composition of the log, and the system can parse the requirements in the control strategy to dynamically adjust the set of data fields written to the log.

[0097] For example, when the control policy indicates that the current operation is a routine business process, the system configuration log only includes the task ID and the final status code, excluding intermediate variables that consume storage. If the control policy indicates that the current operation involves troubleshooting, the system configuration log includes a complete parameter snapshot and context information, providing sufficient evidence for subsequent analysis.

[0098] In the embodiments of this disclosure, recording granularity refers to the level of detail achieved by the log recording. Fine-grained logs contain line-by-line debugging information, while coarse-grained logs only record key milestone events. Recording granularity can correspond to log levels, which are used to identify the importance and urgency of log information and can include debug level (DEBUG), information level (INFO), warning level (WARN), and error level (ERROR). This embodiment can classify the level of detail in the logs, and the system parses the monitoring level in the control strategy to dynamically adjust the output level threshold of the logs.

[0099] For example, during normal system operation, control policies can guide the logging system to record only summary information at the INFO level and above, shielding a large amount of DEBUG-level debug logs to conserve read and write resources. During system upgrades or canary releases, control policies can guide the logging system to enable full DEBUG logging mode, capturing subtle execution fluctuations for analysis.

[0100] In the embodiments of this disclosure, the storage method refers to the strategy for organizing and retaining log data on physical media. For example, the storage method can be defined as local file circular writing, database persistent storage, or remote log service delivery, and compression and encryption attributes can be set. This embodiment can plan for the physical retention of logs, and the system analyzes the compliance and cost requirements in the control strategy to dynamically adjust the log disk writing and circulation strategy.

[0101] For example, for the final output steps involving core business processes, the control strategy can guide the system to use a highly reliable database storage method and set a longer retention period. For transient intermediate output steps, the control strategy can guide the system to use temporary file storage and automatically trigger a cleanup mechanism to release disk space after the task is completed.

[0102] In the embodiments of this disclosure, visibility refers to the personnel roles or system modules authorized to access the log information. For example, visibility can be limited to being visible only to system administrators, operations and maintenance teams, or completely hidden from front-end users, existing only as backend audit data. This embodiment can limit access control for logs, with the system parsing the privacy and permission requirements in the control policy and dynamically adjusting the log query permission boundaries.

[0103] For example, for tool call results containing sensitive data or high-risk operations, control policies can guide the system to strictly limit the visibility of this part of the logs to senior administrators or specific audit accounts, prohibiting ordinary operation and maintenance personnel or front-end users from querying them, thereby meeting data security requirements.

[0104] Through the embodiments disclosed herein, by configuring log policies in multiple dimensions, a precise match between log resource investment and operation and maintenance needs is achieved. While ensuring the security and traceability of critical information, storage overhead is effectively reduced, and the compliance and maintainability of the system are improved.

[0105] In some embodiments of this disclosure, the monitoring and processing logic of the tool call result is configured according to the control policy, including: configuring at least one of the alarm level, sampling policy, statistical method, and processing priority of the monitoring event corresponding to the output result according to the control policy.

[0106] In the embodiments of this disclosure, alarm levels refer to response levels classified according to the importance and urgency of monitored events, used to distinguish system states of different severity. For example, they can be classified into levels such as Emergency (P0), Important (P1), Warning (P2), and Informational (P3), with higher levels indicating greater impact on business operations. This embodiment can define the response intensity of monitored events, and the system analyzes the assessment of task importance in the control strategy to assign differentiated alarm levels to different types of tool call results.

[0107] For example, when the control policy indicates that the current tool is in the final step of a multi-step task, the system configures its failure event as a high alarm level (such as P0), triggering an alarm in the instant messaging tool and a telephone call. If the current tool is in an intermediate step and has a retry mechanism, the system can configure it as a low alarm level (such as P3), simply logging the event without triggering manual intervention, thereby avoiding alarm events.

[0108] In the embodiments of this disclosure, the sampling strategy refers to the rules for selectively collecting monitoring events in scenarios with limited resources or excessive data volume. For example, full sampling (collecting every event) or proportional sampling (such as collecting only 1% of events) can be used to balance monitoring accuracy and system overhead. This embodiment can control the scale of monitoring data collection. The system analyzes the data accuracy requirements in the control strategy and the current system load, and dynamically adjusts the sampling rate.

[0109] For example, during periods of stable daily system operation, the control strategy can guide the monitoring system to use a low sampling rate (e.g., 10%) for the results of frequently executed intermediate tool calls, significantly reducing storage and computational pressure. During new feature deployments or fault recovery, the control strategy can guide the monitoring system to switch to full sampling mode to ensure that no abnormal clues are missed.

[0110] In the embodiments of this disclosure, statistical methods refer to the methods for aggregating, calculating, and presenting the collected raw monitoring data. For example, the frequency of events can be statistically analyzed according to time windows, or the average, peak, and trough values ​​of specific indicators can be calculated to reflect the overall operating trend of the system. This embodiment can set the value extraction method for monitoring data, and the system can analyze the business analysis requirements in the control strategy to define the aggregation dimensions and calculation methods of the data.

[0111] For example, for user-facing, single-step tasks, control policies can guide the monitoring system to calculate success rates and average execution times on a minute-by-minute basis to measure user experience. For background, multi-step tasks, control policies can guide the monitoring system to calculate the overall success rate and total execution time of the entire process to evaluate system throughput performance.

[0112] In the embodiments of this disclosure, processing priority refers to the order in which the operation and maintenance process responds to and handles an alarm after the monitoring system generates an alarm. For example, alarms on critical business links can be prioritized over alarms in background batch processing tasks to ensure the stability of core services. This embodiment can optimize the operation and maintenance response process after an alarm is generated. The system parses the business continuity requirements in the control policy and establishes the work order dispatch order for different alarms.

[0113] For example, when the monitoring system captures both "final step output failure" and "intermediate step output delay" events at the same time, the control policy will guide the operation and maintenance platform to prioritize the work orders related to "final step output failure" and mark them as the highest priority, while the work orders for "intermediate step output delay" will be downgraded or the elastic scaling mechanism will be triggered, thereby ensuring that operation and maintenance resources are focused on solving the most critical business bottlenecks.

[0114] Through the embodiments disclosed herein, the precise allocation of operation and maintenance resources and the effective suppression of alarm noise are achieved by fine-grained configuration of monitoring dimensions. While ensuring the stability of core business, the efficiency of fault detection and location is significantly improved, and the operation and maintenance complexity of the system is reduced.

[0115] Figure 2 This is a flowchart of a data processing method according to another embodiment of the present disclosure.

[0116] like Figure 2 As shown, in this embodiment, obtaining tool call information corresponding to the input task includes operations S210-S240.

[0117] During operation S210, the input task is obtained.

[0118] In the embodiments of this disclosure, an input task refers to a business objective request initiated by a user or external system that the system is expected to complete. Input tasks can exist in the form of structured or unstructured data.

[0119] For example, a user-input natural language command such as "compile this month's sales data and send it via email", or a request from an external API to "batch process images".

[0120] In the embodiments of this disclosure, an input task is obtained. The system captures requests initiated by the user or an external system through a preset receiving interface. The input task can take various forms, including natural language text, voice signals, and structured API request parameters.

[0121] For example, the system obtains user input such as "Book me a flight to Beijing tomorrow" through a chatbot's text input box, or receives a data packet containing query conditions and callback addresses sent by a third-party system through an API interface. The system performs preliminary format validation and normalization on these raw inputs to prepare for subsequent model parsing.

[0122] In operation S220, the input task is fed into the model, enabling the model to parse the user's intent regarding the input task and generate task planning results based on the user's intent.

[0123] In the embodiments of this disclosure, a model refers to a reasoning module with semantic understanding and task planning capabilities, capable of parsing the deep meaning of the input task and transforming it into executable steps. For example, the model may be a large language model or a decision engine integrating planning algorithms.

[0124] In the embodiments of this disclosure, user intent refers to the core demand or goal orientation implicit behind the input task, which is the key semantic information extracted after model parsing. For example, the intent of "system performance optimization" can be extracted from "computer is running slowly", or the intent of "logistics status query" can be extracted from "check express delivery".

[0125] In the embodiments of this disclosure, the task planning result refers to a set of metadata generated by the model based on user intent, describing how to complete the task step by step, including tool call sequence, dependencies and execution logic.

[0126] For example, the result of task planning can be defined as including three steps: "Step 1: Query the database; Step 2: Generate a chart; Step 3: Send an email".

[0127] In the embodiments of this disclosure, an input task is fed into a model, enabling the model to parse the user's intent and generate a task planning result based on that intent. The system passes the input task to the model. The model performs deep semantic analysis on the input task, extracting key entities, action requirements, and constraints to accurately identify the user's intent. Based on its internally trained knowledge and logic, the model decomposes the user's intent into a series of ordered, feasible operational steps, clarifies the dependencies between these steps, and ultimately outputs a structured task planning result.

[0128] For example, after receiving the message "Book a flight to Beijing tomorrow", the model parses the user's intent as "flight booking" and further plans the task planning result, which includes multiple sub-steps such as "checking flight availability", "filtering suitable flights", "filling in passenger information", "initiating payment" and "sending e-ticket".

[0129] When operating S230, at least one tool must be identified based on the task planning results.

[0130] In embodiments of this disclosure, at least one tool is determined based on the task planning results. The system parses the task planning results output by the model to identify the specific functional modules, i.e., tools, required to complete each planning step. Tools can be determined by matching, instantiating, or parameter binding from a pre-built tool library.

[0131] For example, based on the "Check Flight Availability" step in the planning results, the system determines that the "Flight Inquiry" tool needs to be called. Based on the "Send E-Ticket" step, the system determines that the "Email Sending" tool needs to be called. The system compiles these tools into a list of tools required to complete the entire input task.

[0132] In operation S240, at least one phase identifier and / or display identifier corresponding to a tool shall be determined based on the task planning results; the control parameters include the phase identifier and / or display identifier, the phase identifier affecting the output results after the tool is executed, and the display identifier affecting the presentation of the output results after the tool is executed.

[0133] In the embodiments of this disclosure, a stage identifier refers to a label in the task planning results used to characterize the position of the tool in the execution chain, providing a basis for subsequent control strategies. For example, stage identifiers may include types such as "start", "intermediate", "final" or "single-step unique".

[0134] In embodiments of this disclosure, a display identifier refers to a label in the task planning results used to guide the front-end interface on how to present the tool's output. For example, display identifiers may include types such as "full display," "summary display," "hidden," or "anonymized display."

[0135] In embodiments of this disclosure, at least one stage identifier and / or display identifier corresponding to a tool is determined based on the task planning results. The system performs in-depth analysis of the topological structure and logical relationships in the task planning results, and assigns a corresponding stage identifier and / or display identifier to each determined tool.

[0136] In embodiments of this disclosure, the determination of stage identifiers is typically based on the tool's position in the planning results (such as a start node, intermediate node, or end node), while the determination of display identifiers may take into account factors such as the tool's output type, importance, and user attention.

[0137] For example, for the "Send Electronic Ticket" tool, which is at the terminal node in the planning results, the system determines its stage identifier as "Final" and its display identifier as "Full Display". For the "Check Flight Availability" tool, which is at an intermediate node, the system determines its stage identifier as "Intermediate" and its display identifier as "Hidden". These identifiers are then encapsulated into the tool's control parameters, directly guiding the tool's output behavior and interface presentation logic in subsequent steps.

[0138] In the embodiments of this disclosure, this embodiment is the core link in generating control parameters. After obtaining the task planning results, the system can determine the basic values ​​of the stage identifier and / or display identifier based on the tool dependency relationship in the planning results. Then, it can dynamically calibrate the identifier by combining the multidimensional inherent attributes of the tool and historical operation characteristics. The final stage identifier and display identifier are the core components of the control parameters.

[0139] For example, the identifier can be adjusted based on the tool's output type information, risk level information, sensitivity level information, user role information, and historical feedback information.

[0140] In the embodiments of this disclosure, output type information refers to the functional attribute classification of the data returned after the tool has completed execution, which is used to define the purpose of the output content. For example, output types can be divided into finished product delivery types (such as generated PDF reports, exported Excel spreadsheets), intermediate flow types (such as database query result indexes, temporary file paths), debugging assistance types (such as execution logs, error stacks), etc.

[0141] In the embodiments of this disclosure, risk level information refers to the degree to which the operation performed by the tool may negatively impact system stability and business continuity. For example, risk levels can be divided into low risk (such as data query, format conversion), medium risk (such as email sending, file moving), and high risk (such as file deletion, system configuration modification), etc.

[0142] In the embodiments of this disclosure, sensitivity level information refers to the degree of sensitivity of the tool's output content in terms of user privacy, trade secrets, or compliance requirements. For example, sensitivity levels can be divided into low sensitivity (such as public news, weather information), medium sensitivity (such as internal corporate notices, general business data), and high sensitivity (such as employee identity information, financial statements, user privacy data), etc.

[0143] In the embodiments of this disclosure, user role information refers to the permission and identity classification of the user who initiates the input task, used to adapt to the management and control needs of different roles. For example, user roles can be divided into ordinary users (who can only view their own task results), operation and maintenance administrators (who can view all task logs), auditors (who can only view compliance-related data), etc.

[0144] In the embodiments of this disclosure, historical feedback information refers to user operation records and system operation data accumulated during the execution of similar tasks in the past, which are used to optimize the identification logic. For example, historical feedback information may include statistical data such as the expansion rate, ignore rate, and error rate of user output for a certain type of tool.

[0145] In the embodiments disclosed herein, the system parses the task planning results, identifies the upstream and downstream dependencies of each tool node, and determines the basic values ​​of the stage identifier and the display identifier. Subsequently, the system incorporates the multidimensional inherent attributes of the tools and historical operational characteristics to calibrate the basic identifiers.

[0146] For example, if the tool's output type is a finished product delivery, the priority of the display identifier can be appropriately increased to avoid the final result being mistakenly hidden. If the tool's risk level is high, the display identifier needs to be adjusted to show only after confirmation to prevent the risk of accidental operation. If the tool's output sensitivity level is high, regardless of the stage identifier, the display identifier needs to be adjusted to anonymized display, and the visibility of logs should be narrowed. If the user role is an operations and maintenance administrator, the display restrictions on intermediate steps can be appropriately relaxed to facilitate troubleshooting. If historical feedback shows that the user expansion rate of a certain type of tool output is high, the corresponding display identifier should be changed from hidden to summary; conversely, if the ignore rate is high, the display identifier should be changed from full display to summary, achieving dynamic optimization of control strategies. By combining multi-dimensional attributes to dynamically calibrate stages and display identifiers, control parameters can better fit the needs of actual scenarios, balancing task execution efficiency, user experience, and data security.

[0147] Through the embodiments of this disclosure, the semantic parsing and planning capabilities of the model enable the accurate transformation from unstructured user needs to structured tool call information, thereby improving the reliability of subsequent data processing and significantly enhancing the intelligence and accuracy of task execution.

[0148] In some embodiments of this disclosure, determining a stage identifier for at least one tool based on the task planning results includes: constructing a corresponding directed graph based on the task planning results; determining the stage identifier as the final stage of a single tool in response to the directed graph including one tool node; determining the stage identifier as the starting stage in response to the directed graph including multiple tool nodes and the current tool node not having an upstream tool node; determining the stage identifier as the final stage in response to the directed graph including multiple tool nodes and the current tool node not having a downstream tool node; and determining the stage identifier as an intermediate stage in response to the current tool node having both upstream and downstream tool nodes.

[0149] In the embodiments of this disclosure, a directed graph refers to a topological structure composed of nodes and directed edges, used to intuitively represent the dependencies and flow directions between various operation steps in the task planning result. Nodes represent operation units (such as tool calls), and directed edges represent the execution order or data flow direction of operations.

[0150] For example, a planning result that includes "data acquisition, data cleaning, and report generation" can be constructed as three nodes and two directed edges from front to back.

[0151] In the embodiments of this disclosure, a tool node refers to a vertex unit in a directed graph that represents a specific tool call operation; it is the smallest granularity entity for task execution. For example, in a directed graph, "calling a database query interface," "executing a cleaning script," and "generating a PDF file" can all exist as independent tool nodes.

[0152] In the embodiments of this disclosure, an upstream tool node refers to the predecessor node of the current node in a directed graph, which is pointed to by a directed edge. It represents the operation that must be completed before the current tool is executed. For example, in the relationship of "data cleaning report generation", "data cleaning" is the upstream tool node of "report generation".

[0153] In the embodiments of this disclosure, a downstream tool node refers to the successor node that the current node points to through a directed edge in a directed graph, representing an operation that can only be started after the current tool is executed. For example, in the relationship of "data cleaning report generation", "report generation" is a downstream tool node of "data cleaning".

[0154] In the embodiments of this disclosure, a stage identifier refers to a logical role label assigned based on the positional characteristics of a tool node in a directed graph, used to define the execution location of the tool in the overall task chain. For example, a stage identifier may include a start stage, an intermediate stage, a final stage, etc.

[0155] In the embodiments of this disclosure, a corresponding directed graph is constructed based on the task planning results. The system parses the tool list and dependencies contained in the task planning results, maps each tool to an independent node in the directed graph, and maps the execution order or data dependencies between tools to directed edges.

[0156] For example, if the planning result shows "Tool B can only be executed after Tool A is completed", the system will create node A and node B in the directed graph and add a directed edge from A to B.

[0157] Figure 3(a) is a schematic diagram of stage identifiers according to an embodiment of the present disclosure.

[0158] In embodiments of this disclosure, in response to the directed graph including a tool node, the stage identifier is determined to be the single tool final stage. As shown in Figure 3(a), the system detects the total number of nodes in the constructed directed graph. If the statistical result is 1, that is, the entire task contains only a single tool node (node ​​1) with no upstream or downstream dependencies, then it is determined that this node undertakes all the functions of the entire task. At this time, the system determines the stage identifier of this node as "single tool final stage".

[0159] For example, when a user's request is simply "to query the current time", the task planning result contains only one node, "clock query tool". Based on this, the system constructs a directed graph containing only one node and directly determines that the tool is in the final stage of the single tool. Its output is the final delivery result.

[0160] Figure 3(b) is a schematic diagram of stage identifiers according to another embodiment of the present disclosure.

[0161] In embodiments of this disclosure, in response to a directed graph comprising multiple tool nodes and the current tool node having no upstream tool node, a stage identifier is determined as the "starting stage". As shown in Figure 3(b), the system traverses all nodes in the directed graph and calculates the in-degree of each node (i.e., the number of directed edges pointing to that node). If the in-degree of the current node is 0 (as shown by node 1 in Figure 3(b)), it indicates that the node does not depend on the output of any other node and is the trigger point for task execution. The system determines its stage identifier as the "starting stage".

[0162] For example, in the multi-step task of "reading files, parsing data, and storing the results in the database", the "reading files" node has no upstream dependencies, so the system determines it as the initial stage, which is mainly responsible for initializing resources and obtaining raw input.

[0163] In embodiments of this disclosure, in response to a directed graph comprising multiple tool nodes and the current tool node having no downstream tool nodes, a stage identifier is determined as the final stage. The system calculates the out-degree of each node (i.e., the number of directed edges pointing from the node to other nodes). If the out-degree of the current node is 0 (as shown in node 2 in Figure 3(b)), it indicates that the output of this node does not need to be passed to other tools and is the endpoint of the task chain. The system determines its stage identifier as the "final stage".

[0164] For example, in the aforementioned multi-step task, the "results entry" node has no downstream dependencies, so the system determines it as the final stage, and its output is usually presented to the user as the final result of the entire task.

[0165] Figure 3(c) is a schematic diagram of stage identifiers according to yet another embodiment of the present disclosure.

[0166] In the embodiments of this disclosure, in response to the existence of both upstream and downstream tool nodes for the current tool node, the stage identifier is determined to be an intermediate stage. The system detects the in-degree and out-degree of the node. If the in-degree of the current node is greater than 0 and the out-degree is greater than 0 (as shown in node 2 in Figure 3(c)), it indicates that the node depends on the input of the preceding node and needs to provide output to the following node, thus occupying a pivotal position. The system determines its stage identifier as "intermediate stage".

[0167] For example, in the task of "file reading, data parsing, and data entry", the "data parsing" node has both upstream "file reading" as input and downstream "data entry" as output. The system determines it to be an intermediate stage, mainly responsible for data conversion and processing, and its output is usually not directly faced by the user.

[0168] Through the embodiments of this disclosure, based on the topology analysis of directed graphs, the automated and precise determination of the tool execution role is realized, providing an objective and reliable structured basis for the generation of control strategies, thereby improving the accuracy and reliability of the data processing method of this embodiment.

[0169] Figure 4 This is a flowchart of a data processing method according to yet another embodiment of the present disclosure.

[0170] In embodiments of this disclosure, such as Figure 4 As shown, a specific implementation process of a data processing method is disclosed. By dynamically generating control parameters, it achieves precise control over the tool's output logic and intelligent adaptation of the tool's result display logic to the user. This embodiment is an engineering improvement and specific implementation of the scheme described in some of the foregoing claims.

[0171] In embodiments of this disclosure, such as Figure 4As shown, the user submits a request. The user can input natural language commands or API requests through the interactive interface, such as "Help me analyze this sales report and send it to the manager." The LLM (Large Language Model) parses the intent; the system calls the Large Language Model (LLM) to perform semantic analysis on the natural language to obtain the user's intent. The Hybrid Planner plans the task. The planner receives the user's intent and breaks it down into specific execution steps. This step corresponds to the core element in claim 8, namely, generating the task planning result. The planner's output is a structured plan that determines which tools need to be called subsequently and in what order. It should be noted that the Hybrid Planner is the core planning module in the system, responsible for transforming the user's input task into a structured tool call chain (task graph). The Stage Tagger, after the Hybrid Planner generates the task graph, is an engineered annotation module based on rule-based and attribute-based joint decision-making. It is the core module used to determine the stage of each tool node in the task graph and generate display strategies.

[0172] In the embodiments disclosed herein, the Hybrid Planner constructs a corresponding task graph (DAG) based on the task planning results, i.e., the directed graph in the aforementioned embodiments. The system analyzes the topology of the task graph and assigns a specific stage label to each tool node. For task graph node determination, the system first checks the number of independent steps included in the planning results. Single-node scenario (equal to 1): If the task contains only one tool call, the system directly marks it as a single-step task. In this case, the control parameter `is_single_step` is set to `true`, and its display strategy `display_hint` defaults to `show` (i.e., direct display). Multi-node scenario (greater than 1): If the task contains multiple steps, the system marks it as a multi-step task and submits it to the StageTagger module for in-depth analysis.

[0173] In the embodiments of this disclosure, Stage Tagger analyzes the in-degree and out-degree of the DAG: by calculating the in-degree (upstream dependency) and out-degree (downstream dependency) of each node (tool) in the graph, its logical position in the task flow is accurately determined. Nodes with an in-degree of 0 are marked as initial, indicating that the tool has no preceding dependencies and is the starting stage of the task. Nodes with an out-degree of 0 are marked as final, indicating that the tool has no subsequent steps and is the final stage of the task. Other nodes are marked as intermediate, indicating that the tool has both upstream inputs and downstream outputs and is in the middle stage of the task flow.

[0174] Furthermore, a display strategy (display_hint) is generated. Based on the determined stage type of the node, StageTagger generates the corresponding control parameter display_hint. For example, the initial stage may correspond to summary, the intermediate stage to hidden, and the final stage to show.

[0175] In the embodiments disclosed herein, the Execution Context management module generates a context, and the system encapsulates the planned task steps, generated stage identifiers, and display strategies into a unified Execution Context.

[0176] In the embodiments disclosed herein, the tool execution module reads the Execution Context. After obtaining the context, the backend execution engine begins to invoke specific tools according to the plan. The system checks the is_single_step flag in the Execution Context. Single-step task branch (yes): If determined to be a single-step task, after the tool completes execution, the system directly passes the raw result to the frontend. The frontend UI directly renders detailed output results based on display_hint (show). Multi-step task branch (no): If determined to be a multi-step task, the system enters a complex stage processing flow, executing different backend logic and frontend instructions according to the stage type of the node.

[0177] Furthermore, in multi-step task scenarios, the system performs refined process control based on stage identifiers. For example, Intermediate stage. Backend processing: After the tool executes, the system outputs only minimal structured data for downstream use, while compressing detailed logs (e.g., retaining only key status codes) to avoid generating a large amount of redundant data. Frontend display: After the UI layer reads the hidden or summary control parameters, it chooses to collapse the detailed output of the intermediate step, or displays a summary log in a very small font at the bottom of the interface, ensuring a clean main interface.

[0178] For example, the Initial stage. Backend processing: Task initiation, typically involving environment initialization or data retrieval. Frontend presentation: Usually informing the user with a lightweight prompt (such as "Task started..."), without displaying complex internal details.

[0179] For example, in the Final stage: Backend processing: Summarize all intermediate results and generate the final deliverables (such as a complete analysis report and generated file links). Frontend display: After the UI layer reads the control parameters of the show, it uncollapses the display and presents the final results to the user with strong highlighting, centering, and rich text effects.

[0180] In the embodiments disclosed herein, a monitoring module is also provided, which records the call data with Execution Context. Throughout the entire task execution process, the monitoring system records the current Execution Context (including stage identifiers and display strategies).

[0181] Furthermore, data from the health module can be used for feedback optimization. The system supports feeding user interaction behavior (such as whether the user actively expanded hidden steps) and monitoring data back to Stage Tagger. Through machine learning or a rules engine, the system can dynamically adjust the display_hint generation strategy for different task types, achieving adaptive optimization of the UI display logic.

[0182] Through the embodiments of this disclosure, unified scheduling via Execution Context and precise control of the output form at each stage based on the topology structure ensure the stability and accuracy of complex task execution, and significantly improve the smoothness of interaction and monitoring efficiency.

[0183] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure.

[0184] In this embodiment of the disclosure, the electronic device 500 includes a processor 510 and a memory 520 communicatively connected to the processor 510; wherein the memory 520 stores instructions executable by the processor 510, and the instructions are executed by the processor 510 to implement the steps of the method of the foregoing embodiments.

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

[0186] Figure 6 This is a schematic block diagram of an example electronic device used to implement embodiments of the present disclosure.

[0187] like Figure 6As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory 602 or a program loaded from a storage portion 608 into a random access memory 603. The processor 601 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0188] Random access memory 603 stores various programs and data required for the operation of electronic device 600. Processor 601, read-only memory 602, and random access memory 603 are interconnected via bus 604. Processor 601 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 602 and / or random access memory 603. It should be noted that programs may also be stored in one or more memories other than read-only memory 602 and random access memory 603. Processor 601 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0189] According to embodiments of this application, the electronic device 600 may further include an input / output interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card, such as a local area network card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0190] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0191] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 602 described above, and / or random access memory 603, and / or one or more memories other than read-only memory 602 and random access memory 603.

[0192] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0193] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0194] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by processor 601, it performs the functions defined in the system of embodiments of this application. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0195] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0196] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0197] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A data processing method, comprising: Retrieve tool call information corresponding to the input task; The tool invocation information includes at least one tool and its associated control parameters; The control strategy is determined based on the control parameters; At least one processing step is guided to perform corresponding operations according to the control strategy. The at least one processing step is a step that can affect the output corresponding to the tool call result during task execution.

2. The method according to claim 1, wherein at least one processing step is guided according to the control strategy, and a corresponding operation is performed according to the control strategy, comprising at least one of the following: Configure the output logic of the tool according to the control strategy to affect the output results after the tool is executed; The display logic of the tool call results is configured according to the control strategy to affect the presentation of the output results after the tool is executed; The log processing logic for the tool call results is configured according to the control strategy, so as to affect the logging method of the output results after the tool is executed; The monitoring and processing logic for the tool call results is configured according to the control strategy, so as to affect the monitoring method for the output results after the tool is executed.

3. The method according to claim 2, wherein the output logic of the tool is configured according to the control strategy to influence the output result after the tool is executed, comprising: The corresponding encapsulation rule is determined from multiple output encapsulation rules according to the control strategy; Generate the corresponding tool call configuration based on the relevant encapsulation rules; The tool is invoked using the configuration to obtain the output results corresponding to the encapsulation rules.

4. The method according to claim 3, wherein determining the corresponding encapsulation rule from multiple output encapsulation rules according to the control strategy includes: In response to the tool invocation information including a single tool, a first encapsulation rule is determined to output information containing a description of the tool execution results; In response to the fact that the tool invocation information includes multiple tools and the currently invoked tool is an intermediate step, a second encapsulation rule is determined to output structured data for use by subsequent tools; In response to the fact that the tool invocation information includes multiple tools and the currently invoked tool is the last step, a third encapsulation rule is determined to output result data based on the execution results of multiple tools.

5. The method according to claim 2, wherein the display logic of the control strategy configuration tool invocation result includes at least one of the following: Based on the control strategy, configure the first display logic to fully display the call results; According to the control strategy, configure the second display logic for the summary of the display tool call results; According to the control strategy, configure the third display logic for hiding the tool call results; According to the control strategy, configure a fourth display logic to show the tool call results in the form of progress information; According to the control strategy, a fifth display logic is configured to show the tool call result after confirmation; According to the control strategy, a sixth display logic is configured to display the tool call results after they have been anonymized.

6. The method according to claim 2, wherein the log processing logic for the control policy configuration tool invocation result includes: According to the control strategy, configure at least one of the following for the log recording content, recording granularity, storage method, and visibility range corresponding to the output result:

7. The method according to claim 2, comprising the monitoring and processing logic of the control strategy configuration tool invocation result, including: According to the control strategy, configure at least one of the following for the monitoring event corresponding to the output result: alarm level, sampling strategy, statistical method, and processing priority.

8. The method according to any one of claims 1 to 7, wherein obtaining tool invocation information corresponding to the input task includes: Obtain the input task; The input task is fed into the model, which then parses the user's intent regarding the input task and generates a task planning result based on that intent. At least one tool should be determined based on the task planning results; At least one stage identifier and / or display identifier corresponding to a tool shall be determined based on the task planning results; the control parameters include the stage identifier and / or the display identifier, wherein the stage identifier affects the output results after the tool is executed, and the display identifier affects the presentation method of the output results after the tool is executed.

9. The method according to claim 8, wherein at least one stage identifier corresponding to a tool is determined based on the task planning result, including: Construct the corresponding directed graph based on the task planning results; In response to the directed graph including a tool node, the stage identifier is determined to be the single-tool final stage; In response to the fact that the directed graph includes multiple tool nodes and the current tool node has no upstream tool node, the stage identifier is determined to be the starting stage; In response to the directed graph including multiple tool nodes and the current tool node having no downstream tool nodes, the stage identifier is determined to be the final stage; In response to the existence of both upstream and downstream tool nodes at the current tool node, the stage is identified as an intermediate stage.

10. An electronic device, comprising: A processor and a memory communicatively connected to the processor; The memory stores instructions that can be executed by the processor, and the processor executes the instructions to achieve the following: Obtain tool invocation information corresponding to the input task; the tool invocation information includes at least one tool and associated control parameters; The control strategy is determined based on the control parameters; At least one processing step is guided to perform corresponding operations according to the control strategy. The at least one processing step is a step that can affect the output corresponding to the tool call result during task execution.

Images