Agent cooperation method based on intervening tool chain

Abstract

The invention discloses an agent cooperation method based on an intervening tool chain, and belongs to the field of computer task scheduling, and the method comprises the steps: generating tool chain description data corresponding to a demand description text according to the demand description text used for representing an agent scheduling behavior; according to the tool chain description data, generating an execution tool chain for achieving a proxy scheduling behavior; and executing the proxy scheduling behavior based on the execution tool chain. According to the method, by introducing an intervening tool chain structure and a semantic-driven tool chain generation mechanism, system response delay and resource waste caused by process stiffness or tool calling failure are reduced, and the problem that the stability and expansibility of the tool calling process are insufficient is solved.

Description

Technical Field

[0001] This application belongs to the field of computer task scheduling, and specifically relates to a proxy collaboration method, apparatus, device and storage medium based on an interventionist toolchain. Background Technology

[0002] With the widespread application of large-scale model-driven intelligent systems in various business scenarios, the interaction between users and systems is gradually shifting from traditional structured form operations to more flexible natural language interaction. In typical applications such as intelligent customer service, automated office, data analysis, and emergency dispatch, users often want to complete complex task processes through free expression, while the system can dynamically call appropriate tools to complete the task based on the context.

[0003] Among existing technologies, the Model Context Protocol (MCP) is a typical implementation scheme. MCP adopts a client-server architecture, integrating large models with external tools through standardized interfaces. Its core components include the MCP client, MCP server, and MCP host, supporting the model invoking external tools to complete tasks during inference. The MCP framework typically executes tasks in a linear toolchain manner, with the toolchain consisting of predefined steps. During execution, the model progressively calls tools based on the context to complete the task flow. This scheme has certain advantages in standardized integration and task execution, and is suitable for structured and predictable task scenarios.

[0004] However, the toolchain design of the MCP framework is relatively simple and lacks a flexible decision-making mechanism. It cannot dynamically adjust the task process based on real-time feedback, which results in limited existing toolchain management capabilities and affects overall stability and usability. Summary of the Invention

[0005] This application aims to provide a proxy collaboration method, apparatus, device, and storage medium based on an operable toolchain, which at least solves the problems of insufficient stability and scalability in the tool invocation process.

[0006] In a first aspect, embodiments of this application disclose a proxy collaboration method based on an operable toolchain, including: Based on the requirement description text used to characterize the agent scheduling behavior, generate toolchain description data corresponding to the requirement description text; Based on the toolchain description data, an execution toolchain is generated to achieve the proxy scheduling behavior; the execution toolchain includes sub-data of node type and edge type, the sub-data of node type is used to characterize multiple execution actions in the proxy scheduling behavior, and the sub-data of edge type is used to characterize the execution order among the multiple execution actions in the proxy scheduling behavior; The execution toolchain is used to perform proxy scheduling behavior.

[0007] Secondly, embodiments of this application also disclose an agent collaboration device based on an operable toolchain, comprising: The description module is used to generate toolchain description data corresponding to the requirement description text, based on the requirement description text used to characterize the agent scheduling behavior. The toolchain module is used to generate an execution toolchain to achieve the proxy scheduling behavior based on the toolchain description data; the execution toolchain includes sub-data of node type and edge type, the sub-data of node type is used to characterize multiple execution actions in the proxy scheduling behavior, and the sub-data of edge type is used to characterize the execution order among the multiple execution actions in the proxy scheduling behavior; The execution module is used to perform agent scheduling behavior based on the execution toolchain.

[0008] Thirdly, embodiments of this application also disclose an electronic device, including a processor and a memory, wherein the memory stores a program or instructions that can run on the processor, and the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0009] Fourthly, embodiments of this application also disclose a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the method described in the first aspect.

[0010] In summary, in this embodiment, by parsing the requirement description text of the proxy scheduling behavior, corresponding toolchain description data is generated, realizing semantic driving of the task scheduling process from the source. This not only improves the system's ability to understand natural language input but also lays the foundation for the dynamic construction of subsequent task processes, thereby enhancing the system's adaptability to complex tasks. Furthermore, based on the generated toolchain description data, an execution toolchain containing node types and edge types is constructed, so that each execution action is clearly represented, and the execution order between actions can be flexibly defined through edge types. This supports the dynamic adjustment and manual intervention of key nodes in the task process, enabling the system to select paths or reconstruct tasks based on real-time feedback during execution, thereby improving the flexibility and controllability of task scheduling. Finally, by executing proxy scheduling behavior based on the execution toolchain, while maintaining the semantic consistency of the task, automatic tool invocation and dynamic advancement of the task process are achieved, making the task execution process highly fault-tolerant and scalable, and maintaining stable operation in the face of task complexity, environmental changes, or user intervention. Therefore, the method based on the embodiments of this application, by introducing an interventionist toolchain structure and a semantically driven toolchain generation mechanism, reduces system response delays and resource waste caused by process rigidity or tool call failures, and solves the problem of limited existing toolchain management capabilities. Attached Figure Description

[0011] In the attached diagram: Figure 1 This is a flowchart illustrating the steps of an agent collaboration method based on an operable toolchain, as provided in an embodiment of this application. Figure 2 This is a flowchart illustrating the steps of another agent collaboration method based on an interventionist toolchain provided in this application embodiment; Figure 3 This is a prompt word assembly process under the embodiments of this application; Figure 4 This is a process of building a toolchain library under the embodiments of this application; Figure 5 This is an example illustration of an embodiment of this application; Figure 6 This is a proxy collaboration framework under the embodiments of this application; Figure 7 This is a session control process within the proxy collaboration framework of this application embodiment; Figure 8 This is a tool call prediction process within the proxy collaboration framework of this application embodiment; Figure 9 This is a block diagram of an agent collaboration device based on an operable toolchain provided in an embodiment of this application; Figure 10This is a block diagram of an electronic device provided in one embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

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

[0014] like Figure 1 The image shows an agent collaboration method based on an operable toolchain provided in an embodiment of this application.

[0015] The method may include the following steps: Step 101: Generate toolchain description data corresponding to the requirement description text based on the requirement description text used to characterize the agent scheduling behavior.

[0016] In some embodiments of this application, to achieve semantic-driven process construction for agent scheduling behavior, the system first generates toolchain description data corresponding to the requirement description text used to characterize the agent scheduling behavior. Specifically, it can receive natural language task requirements input by the user, convert them into a structured semantic representation, and generate toolchain description slices matching the requirements by retrieving a toolchain description vector library. The toolchain description data is an abstract expression of the toolchain's functionality, structure, and applicable scenarios, typically organized in JSON format, and includes fields such as toolchain ID, name, and detailed description. By generating toolchain description data, the system can establish a mapping relationship between semantics and tools in the initial stage of task scheduling, thereby improving the ability to parse natural language input and providing a semantic foundation for subsequent toolchain construction.

[0017] In a specific example, a user inputs "Please help me complete the map plotting task for the urban planning area." The system recognizes this request as a proxy scheduling behavior and processes the natural language text as a request description. The system uses vector retrieval to match a toolchain description slice related to "map plotting tool" in the toolchain description vector library. This slice contains the toolchain ID "tc001," the name "map plotting tool," and detailed descriptions of functions such as GIS map annotation, layer management, and data import / export. The toolchain description data generated according to this execution process will serve as the semantic basis for subsequent toolchain construction, enabling the system to automatically select an appropriate toolchain structure and prepare for scheduling based on the task semantics.

[0018] Step 102: Generate an execution toolchain to achieve the proxy scheduling behavior based on the toolchain description data.

[0019] The execution toolchain includes node type and edge type sub-data. The node type sub-data is used to represent multiple execution actions in the agent scheduling behavior, and the edge type sub-data is used to represent the execution order among the multiple execution actions in the agent scheduling behavior.

[0020] In some embodiments of this application, to achieve a structured execution flow for proxy scheduling behavior, the system generates an execution toolchain to achieve the scheduling behavior based on toolchain description data. Specifically, the system can parse the functional and structural information in the toolchain description data to construct an execution toolchain containing node type and edge type sub-data. The node type sub-data is used to characterize each execution action in the scheduling behavior, such as tool invocation, data processing, or status feedback; the edge type sub-data is used to define the execution order between these execution actions, including sequential connections, branch jumps, or decision paths. Node types and edge types together constitute a directed graph structure of the task flow, enabling the system to clearly define the execution position of each tool and its upstream and downstream relationships, thereby supporting the automatic advancement and dynamic adjustment of the task flow.

[0021] In a specific example, the system receives toolchain description data related to "Map Plotting Tools." This data includes the toolchain ID "tc001," the name "Map Plotting Tools," and detailed descriptions of functions such as GIS annotation and layer management. Based on this description data, the system generates an execution toolchain containing multiple nodes such as "Data Importer," "Data Cleaner," and "Data Analyzer," each representing a specific execution action. Edge-type subdata defines the sequential connection from "Data Importer" to "Data Cleaner," and the manual intervention path from "Data Cleaner" to "Data Analyzer." After scheduling tasks according to this execution toolchain, the system can sequentially call each tool to complete the import, cleaning, and analysis of map data, supporting manual adjustments at key nodes to ensure the flexibility and stability of the task flow.

[0022] Step 103: Execute proxy scheduling behavior based on the execution toolchain.

[0023] In some embodiments of this application, to complete the actual execution of the proxy scheduling behavior, the system performs task flow scheduling operations based on a pre-constructed execution toolchain. Specifically, the system can call the functional interfaces corresponding to the tool nodes one by one according to the order defined by the node types and edge types in the execution toolchain, and update the context information after each node completes its task to determine whether to enter a decision point or intervention point. The execution toolchain serves as a structured carrier for task scheduling, with node types used to identify the functional attributes of each execution action and edge types used to control the progress logic of the task flow, including paths such as sequential execution, manual intervention, and status return. By executing proxy scheduling behavior based on the execution toolchain, the system can achieve automatic tool invocation and dynamic flow advancement while maintaining task semantic consistency, thereby improving the fault tolerance and scalability of the task execution process.

[0024] In a specific example, the system has constructed an execution toolchain containing three types of tool nodes: "Data Importer," "Data Cleaner," and "Data Analyzer," defining the edge type between the "Data Cleaner" and the "Data Analyzer" as manual intervention. The system sequentially calls the "Data Importer" to load data, the "Data Cleaner" to perform data quality processing, and pauses the process before entering the "Data Analyzer," waiting for user confirmation or adjustment of the cleaning results. After user intervention, the system continues by calling the "Data Analyzer" to complete statistical analysis and output the results. Throughout the execution process, the system automatically advances the task flow according to the toolchain structure and supports manual intervention at key nodes, thereby ensuring the stability and flexibility of task scheduling.

[0025] In summary, in this embodiment, by parsing the requirement description text of the proxy scheduling behavior, corresponding toolchain description data is generated, realizing semantic driving of the task scheduling process from the source. This not only improves the system's ability to understand natural language input but also lays the foundation for the dynamic construction of subsequent task processes, thereby enhancing the system's adaptability to complex tasks. Furthermore, based on the generated toolchain description data, an execution toolchain containing node types and edge types is constructed, so that each execution action is clearly represented, and the execution order between actions can be flexibly defined through edge types. This supports the dynamic adjustment and manual intervention of key nodes in the task process, enabling the system to select paths or reconstruct tasks based on real-time feedback during execution, thereby improving the flexibility and controllability of task scheduling. Finally, by executing proxy scheduling behavior based on the execution toolchain, while maintaining the semantic consistency of the task, automatic tool invocation and dynamic advancement of the task process are achieved, making the task execution process highly fault-tolerant and scalable, and maintaining stable operation in the face of task complexity, environmental changes, or user intervention. Therefore, the method based on the embodiments of this application, by introducing an interventionist toolchain structure and a semantically driven toolchain generation mechanism, reduces system response delays and resource waste caused by process rigidity or tool call failures, and solves the problem of limited existing toolchain management capabilities.

[0026] Figure 2 This is another agent collaboration method based on an operable toolchain provided in the embodiments of this application.

[0027] The method may include the following steps: Step 201: Generate toolchain description data corresponding to the requirement description text based on the requirement description text used to characterize the agent scheduling behavior.

[0028] The method shown in this step has been explained in step 101 and will not be repeated here.

[0029] Optionally, step 201 includes the following sub-steps: Sub-step 2011: Obtain the requirement description text and generate prompt word template data for agent scheduling behavior based on the requirement description text.

[0030] In some embodiments of this application, to achieve semantic guidance and structured generation of proxy scheduling behavior, the system first obtains the requirement description text and generates prompt word template data for proxy scheduling behavior based on the text. Specifically, after receiving the user's input of a natural language task requirement, the system uses it as the requirement description text and combines it with a preset prompt word template structure to generate prompt word template data for subsequent toolchain construction. The prompt word template data is a structured text framework used to guide the generation of toolchain descriptions by large models, typically including task fields, context fields, tool list fields, and execution chain example fields. By generating prompt word template data, the system can achieve standardized control over the toolchain generation process in subsequent steps, thereby improving the interpretability of the task scheduling process and the consistency of model output.

[0031] In a specific example, a user inputs "Please complete the map plotting task for the disaster area." The system processes this natural language text as a requirement description. Based on this text, the system generates prompt template data, where the task field is filled with "disaster area map plotting," the context field is filled with "need to mark the disaster area on the electronic map and plan rescue routes," the tool list field is preset to "GIS plotting tools, layer management tools, data import tools," and the execution chain example field is filled with "starting from data import, through plotting and layer management, finally generating map output." This prompt template data will serve as the basic structure for subsequent prompt data construction, providing a semantic framework and format constraints for the description of the toolchain for large model generation.

[0032] Sub-step 2012 involves selecting from the tool identifier list based on the prompt word template data and the requirement description text to determine the target tool identifier dataset from the tool identifier list.

[0033] In some embodiments of this application, to achieve precise control over the toolchain construction process, the system selects from a tool identifier list based on prompt template data and requirement description text to determine the target tool identifier dataset. Specifically, the system combines the task field, context field, and tool list field in the prompt template with the semantic information in the requirement description text, and filters out tool identifiers related to the current task from a preset tool identifier list. A tool identifier is a structured data item used to uniquely identify a callable tool in the system, typically including a tool ID, tool name, function description, and API address. By determining the target tool identifier dataset, the system can provide a clear tool scope during subsequent prompt generation and toolchain construction, thereby improving the relevance of tool selection and the accuracy of scheduling behavior.

[0034] In a specific example, when a user enters "Please complete the map plotting task for the urban planning area," the system generates a prompt template containing keywords such as "map plotting," "layer management," and "data import." Based on this template and the requirement description text, the system selects three tool icons from the tool icon list: "GIS map plotting tool," "layer management tool," and "map data import tool," and combines them into a target tool icon dataset. This dataset will serve as the basis for subsequent prompt supplementation and toolchain generation, enabling the system to call appropriate tools to complete the map annotation and data processing workflow around the urban planning task.

[0035] Sub-step 2013 supplements the prompt word template data based on the requirement description text and the target tool identifiers in the target tool identifier dataset to generate prompt word data for agent scheduling behavior.

[0036] In some embodiments of this application, to improve the semantic completeness of prompt words and the relevance of toolchain generation, the system supplements the prompt word template data based on the requirement description text and the target tool identifiers in the target tool identifier dataset to generate prompt word data for proxy scheduling behavior. Specifically, the system integrates the task semantics in the requirement description text with the tool functions in the target tool identifier dataset and populates them into various fields of the prompt word template data, including task fields, context fields, tool list fields, and execution chain example fields. The prompt word data is the input content used to guide the large model in generating the toolchain structure. Its format is usually structured text or Markdown tables, containing content such as task objectives, background information, available tools, and execution chain requirements. By generating prompt word data, the system can provide a clear task context and tool scope for the large model, thereby improving the accuracy and semantic consistency of toolchain generation.

[0037] In a specific example, the system has obtained the requirement description text for the task "Mapping of Urban Planning Areas" and filtered out "GIS Mapping Tools," "Layer Management Tools," and "Map Data Import Tools" as target tool identifiers. The system fills these tool identifiers into the tool list field of the prompt template data, and supplements the context field with "requires marking urban planning areas and organizing layer structures on an electronic map," and the execution chain example field with "starting from data import, through layer management and plotting, and finally generating map output." The final generated prompt data will be provided as input to the toolchain description model to generate structured toolchain description data.

[0038] Sub-step 2014: Input the prompt word data into the toolchain description model to obtain toolchain description data.

[0039] In some embodiments of this application, to achieve structured toolchain generation for agent scheduling behavior, the system inputs prompt word data into a toolchain description model to obtain toolchain description data. Specifically, the system uses the constructed prompt word data as input and passes it to a toolchain description model with formatted output capabilities. This model generates toolchain description data matching the task requirements based on the task semantics, tool list, and execution chain requirements in the prompt words. The toolchain description data is a structured text, typically in JSON format, containing toolchain ID, name, functional description, and abstract information about tool nodes and execution paths. In this way, the system can leverage the semantic understanding and structure generation capabilities of the large model to automatically construct toolchain descriptions with execution logic, providing foundational data support for subsequent toolchain instantiation and scheduling execution.

[0040] In a specific example, the system has generated prompt data for the task "Mapping of Urban Planning Areas," including the task objective, background description, list of available tools, and an example execution chain. This prompt data is input into a large toolchain description model with structured generation capabilities. This model returns a JSON-formatted toolchain description, containing the toolchain ID "tc001," the name "Mapping Tools," and detailed descriptions of functions such as GIS annotation, layer management, and data import / export. This toolchain description data will serve as a semantic template for subsequent toolchain construction, enabling the system to automatically generate an executable toolchain structure and prepare for scheduling based on task requirements.

[0041] The data flow process described above can be based on, for example... Figure 3 Perform the steps shown: S1, Task Prompt Name Input: Receives the task name or task target text input by the user, which serves as the semantic starting point for subsequent prompt word construction. The system processes this input as requirement description text and uses it to drive the generation of prompt word templates and the initiation of the toolchain construction process. S2. Template path concatenation and template content retrieval: The system concatenates the task prompt name and template path according to the preset prompt word template management rules, locates the corresponding prompt word template file, and retrieves its content. The template content contains standardized prompt word structure fields, which are used to fill in the task semantics and tool information later. S3. Loading Prompt Templates: The system parses and loads the obtained prompt template content to form an editable prompt template data structure. This data structure includes task fields, context fields, tool list fields, and execution chain example fields, which are used to carry subsequent supplementary information and generate complete prompt data. S4. Context Preparation: Construct the context information required for the prompt words, including the semantic background of the current task, available server information, and tool list information. The system extracts relevant metadata from the service catalog and integrates it with the task semantics to form a complete context data structure. S5. Prompt Assembly: The system integrates the task prompt name, the loaded prompt template data, and the prepared context information to generate the final prompt data. This prompt data will be passed as input to the toolchain description model to generate toolchain description data and drive the subsequent scheduling process.

[0042] Furthermore, during the execution of a program, the data flow process can be referenced as follows: Figure 4 The process is shown, and a toolchain library is built using the established toolchain: R1: The controller receives a scheduling request from the business backend. The request contains the task objective and context information input by the user. This step is the starting point of the toolchain generation process and triggers the subsequent toolchain construction logic. R2: The system parses the received task objective into a query requirement and combines it with the context information of the current session (such as user intent, historical status, domain information, etc.) to form a complete toolchain call context for subsequent matching and generation; R3: The controller retrieves a list of currently available tools from the service catalog based on context information. This list includes tool identifiers, function descriptions, interface addresses, etc., and serves as a candidate resource pool for building toolchains. R4: The system inputs the query requirements and context information into the toolchain description vector library, retrieves similar toolchain description data, and generates toolchain data slices. The data slices are usually in JSON format and contain toolchain ID, name and function description, which are the semantic basis for building prompt words. R5: The system combines toolchain data slices, query requirements, context information, and a list of available tools into prompt word data. The prompt words are used to guide the large model to generate the toolchain structure. The format is usually structured text or Markdown template, which includes task objectives, background, tool list, and execution chain requirements. R6: The system inputs the prompt word data into a large model (LLM) with structured output capabilities. The large model generates toolchain description data, which includes structural information such as tool nodes, execution paths, and decision points. This data is the core basis for subsequent toolchain instantiation. R7: The system extracts the toolchain structure from the text returned by the large model, including toolchain ID, tool node list, edge type definition, etc. The extraction process ensures that the format is standardized and verifies the logical integrity of the toolchain. R8: The system generates a toolchain instance based on the extraction results. The instance contains a unique toolchain ID, node structure, execution path and initial state. This toolchain can be used for scheduled execution or further editing. R9: Updates the toolchain library and toolchain description vector library based on the extracted toolchain.

[0043] Step 202: Generate an execution toolchain to achieve the proxy scheduling behavior based on the toolchain description data.

[0044] The execution toolchain includes node type and edge type sub-data. The node type sub-data is used to represent multiple execution actions in the agent scheduling behavior, and the edge type sub-data is used to represent the execution order among the multiple execution actions in the agent scheduling behavior.

[0045] The method shown in this step has been explained in step 102 and will not be repeated here.

[0046] Optionally, step 202 includes the following sub-steps: Sub-step 2021: Extract all toolchain identifiers from the toolchain description data to characterize each step in the agent scheduling behavior.

[0047] Each toolchain identifier has corresponding step identifier information.

[0048] In some embodiments of this application, to construct a structured execution flow for proxy scheduling behavior, the system extracts all toolchain identifiers representing each scheduling step from the toolchain description data. Specifically, the system first parses the structure fields in the toolchain description data, identifies the tool node information, and extracts the toolchain identifier and step identifier information corresponding to each tool node. The toolchain identifier is used to uniquely identify each functional node in the toolchain, while the step identifier information indicates the execution position and logical order of the node in the overall task flow. The toolchain identifier typically includes fields such as tool ID, tool name, function description, and interface address, while the step identifier information includes structured content such as node sequence number, a list of preceding nodes, and a list of succeeding nodes. By completing this step, the system can establish the semantic mapping relationship of each execution action in the task flow, providing a structured foundation for subsequent toolchain instantiation and scheduling control.

[0049] In a specific example, the system has obtained the toolchain description data for the "Data Cleaning and Analysis Toolchain," which includes tool nodes such as "Data Importer," "Data Cleaner," and "Data Analyzer." When parsing this description data, the system extracts the toolchain identifier for each tool node, such as "t001-1," "t001-2," and "t001-3," and simultaneously extracts its corresponding step identifier information, including the list structure of predecessor and successor nodes. In this way, the system obtains a complete set of toolchain identifiers and a mapping of step identifiers, providing a structured node foundation and process sequence basis for subsequently building and executing the toolchain.

[0050] Sub-step 2022: Establish an execution toolchain based on the corresponding toolchain identifier and step identifier information.

[0051] In some embodiments of this application, to construct a task flow structure with scheduling capabilities, the system establishes an execution toolchain based on each toolchain identifier and its corresponding step identifier information. Specifically, the system can structurally combine the extracted toolchain identifiers and step identifier information, construct connection paths between tool nodes according to the relationships between preceding and succeeding nodes defined by the step identifiers, and generate an execution toolchain containing node types and edge types. The execution toolchain is a task scheduling-oriented flow structure. Node types represent the functional actions of each tool, and edge types define the execution order and logical relationships between tools, including paths such as sequential execution, manual intervention, and status return. By establishing the execution toolchain, the system can transform the abstract toolchain description into an executable task flow structure, providing logical support for subsequent tool calls and task advancement.

[0052] In a specific example, the system has extracted the toolchain identifiers and step identifiers for three tool nodes: "Data Importer," "Data Cleaner," and "Data Analyzer." The "Data Importer" is identified as "t001-1," with an empty preceding node and a "t001-2" following node; the "Data Cleaner" is identified as "t001-2," with an empty preceding node and a "t001-1" following node and a "t001-3" following node; and the "Data Analyzer" is identified as "t001-3," with an empty preceding node and a "t001-2" following node. Based on this identifier information, the system constructs an execution toolchain, forming a directed graph structure containing three nodes and two edges, setting the edge types to sequential execution and manual intervention paths, respectively. This execution toolchain will serve as the foundational structure for subsequent task scheduling, enabling the system to invoke tools in a predefined order and supporting manual intervention at key nodes.

[0053] Step 203: Generate a display diagram of the execution toolchain according to the sub-data of node type and edge type in the execution toolchain.

[0054] In some embodiments of this application, to enhance the visual management capabilities of task flows, the system generates a display graph of the execution toolchain based on the sub-data of node and edge types in the execution toolchain. Specifically, after reading the attribute information of each node in the execution toolchain and the connection relationships between nodes, the system constructs task nodes in the graph based on node types, constructs directed connections between nodes based on edge types, and renders the overall structure as a graphical display graph. The display graph is typically presented in a graph structure form, which can intuitively reflect the execution order, branch paths, and decision point locations of the task flow. Node types are used to represent multiple execution actions in the agent scheduling behavior, such as tool calls, data processing, or status feedback; edge types are used to represent the execution order between these actions, including sequential execution, manual intervention, or status return paths. By generating the display graph, the system can provide users or operations personnel with a clear view of the task flow, facilitating understanding, monitoring, and subsequent adjustments.

[0055] In a specific example, the system has generated an execution toolchain containing nodes such as "Data Importer," "Data Cleaner," and "Data Analyzer," and defined sequential connection edges from "Data Importer" to "Data Cleaner," as well as manual intervention edges from "Data Cleaner" to "Data Analyzer." Based on these node and edge types, the system constructs a visualization diagram, representing each tool node with rectangles, execution paths with arrows, and allowing users to label "intervention points" on manual intervention edges. This visualization diagram provides users with a clear view of the task's execution flow and key node locations, offering a direct basis for subsequent process modifications or interventions.

[0056] Step 204: In response to the modification operation on the display diagram, update the execution toolchain.

[0057] In some embodiments of this application, to enable interactive adjustment and dynamic evolution of the task flow, the system updates the execution toolchain in response to modifications to the display graph. Specifically, based on user modifications to the display graph interface, such as adding, deleting, or adjusting the structure of nodes and edges, the system maps these modifications to update the execution toolchain structure. The display graph, as a visual representation of the execution toolchain, maintains a structure consistent with the node and edge types in the toolchain; user modifications to the display graph represent adjustments to the task flow logic. By updating the execution toolchain, the system can dynamically adjust the task execution path without interrupting the current task context, thereby improving the flexibility and controllability of task scheduling.

[0058] In a specific example, a user noticed that the original toolchain in the visualization interface lacked a "Layer Manager" node. They then inserted this node between the "Data Cleaner" and "Data Analyzer" via the graphical interface, setting the connection edge type to a manually intervened path. Upon receiving this modification, the system automatically updates the execution toolchain's data structure, inserting the "Layer Manager" node into the existing node sequence and adjusting the connection relationships and types of relevant edges. The updated execution toolchain will serve as the basis for subsequent task scheduling, enabling the system to invoke the newly added tool during execution and support manual judgment, thereby better meeting the user's personalized adjustment needs for the task flow.

[0059] Optionally, step 204 includes the following sub-steps: Sub-step 2041: In response to the operation of adding a node in the display graph, add sub-data of the node type corresponding to the added node in the execution toolchain, and add sub-data of the corresponding edge type to the sub-data of the added node type according to the position of the added node in the display graph.

[0060] In some embodiments of this application, to achieve structural synchronization between the display graph and the execution toolchain, the system, in response to the addition of a node in the display graph, adds sub-data of the node type corresponding to the added node to the execution toolchain, and adds corresponding edge type sub-data to the sub-data of the node type according to the position of the added node in the display graph. Specifically, after the user adds a node on the display graph interface, the system identifies the tool identifier and task semantics of the newly added node and inserts it as new node type sub-data into the execution toolchain structure; simultaneously, the system identifies its predecessor and successor nodes according to the connection position of the node in the display graph and generates corresponding edge type sub-data to define the execution order between the newly added node and other nodes. By completing this step, the system can dynamically expand the execution toolchain structure based on user interaction, thereby improving the editability and scheduling flexibility of the task flow.

[0061] In a specific example, a user adds a node named "Outlier Detector" to the visualization interface and inserts it between the "Data Importer" and "Data Cleaner". The system identifies the newly added node as "t004", with the task semantics of "detecting and marking outliers in the data", and inserts it as a new node type sub-data into the execution toolchain. Simultaneously, based on the node's position in the visualization, the system generates two edge type sub-data, connecting "Data Importer" to "Outlier Detector" and "Outlier Detector" to "Data Cleaner", respectively, with both edge types set to sequential execution. After this execution process is completed, the execution toolchain structure is expanded into a directed graph containing four nodes and three edges, which the system can use for subsequent scheduling and tool invocation.

[0062] Sub-step 2042, in response to the deletion operation of a node in the display graph, deletes the sub-data of the node type corresponding to the deleted node in the execution toolchain, and modifies the association relationship of the sub-data of the edge type corresponding to the deleted node type sub-data according to the position of the deleted node in the display graph.

[0063] In some embodiments of this application, to maintain structural consistency between the display graph and the execution toolchain, the system, in response to a deletion operation on a node in the display graph, deletes the sub-data of the node type corresponding to that node in the execution toolchain, and modifies the association relationship of the sub-data of the corresponding edge type based on the node's position in the display graph. Specifically, after identifying the node deleted by the user in the display graph, the system extracts the tool identifier corresponding to that node and removes the node type sub-data matching that identifier from the execution toolchain. Subsequently, based on the node's connection position in the display graph, the system identifies its predecessor and successor nodes and adjusts the original edge type sub-data, including deleting edge connections related to that node and, if necessary, reconstructing new connection paths between predecessor and successor nodes. Node type sub-data is used to represent the execution actions in the scheduling behavior, and edge type sub-data is used to represent the flow relationship between actions. The synchronous update of both ensures the logical closure and structural integrity of the task flow. By completing this step, the system can dynamically shrink the execution toolchain structure based on user interaction, thereby improving the controllability and editing flexibility of the task flow.

[0064] In a specific example, a user deletes a node named "Outlier Detector" in the graphical interface. This node was originally located between "Data Importer" and "Data Cleaner". The system identifies the tool identifier of this node as "t004" and removes the corresponding node type sub-data from the execution toolchain. Simultaneously, the system identifies the original connections of this node, deletes the edge type sub-data between "Data Importer" and "Outlier Detector" and between "Outlier Detector" and "Data Cleaner", and reconstructs the sequential execution edge between "Data Importer" and "Data Cleaner". After this execution process is completed, the execution toolchain structure is updated to a directed graph containing three nodes and two edges, which the system can then use for task scheduling and tool invocation.

[0065] Step 205: Input the execution toolchain into the toolchain correction model to update the execution toolchain.

[0066] In some embodiments of this application, to improve the adaptability and semantic consistency of the execution toolchain, the system inputs the execution toolchain into a toolchain correction model for updating. Specifically, the system passes the currently constructed execution toolchain structure, including tool nodes, edge types, execution order, and context information, as input to the toolchain correction model. The toolchain correction model is a model with structural optimization and semantic adjustment capabilities, capable of adding, deleting, modifying, or reconstructing the toolchain based on its logical structure, task objectives, and context state. Toolchain correction models are typically built based on large model fine-tuning or rule-driven approaches, possessing the ability to perform semantic completion, structural optimization, or intervention point insertion for the execution flow. In this way, the system can dynamically optimize the toolchain structure without destroying the original task semantics, thereby improving the flexibility of task scheduling and execution stability.

[0067] In a specific example, the system has built an execution toolchain containing three nodes: "Data Importer," "Data Cleaner," and "Data Analyzer," and has set up sequential execution and manual intervention paths. During task execution, the system discovers that the "Data Cleaner" node lacks outlier handling capabilities, which may affect subsequent analysis results. The system inputs the current toolchain structure and context information into the toolchain correction model. The model identifies the gap in the cleaning process and automatically inserts an "Outlier Detector" node between the "Data Importer" and the "Data Cleaner," while adjusting the edge type to sequential execution. The updated toolchain structure is returned to the system to replace the original toolchain and continue the task scheduling process.

[0068] Optionally, in this application, for the purpose of updating the execution toolchain, the sub-data of the added node type can be divided into four types according to the decision type, as shown in Table 1: Table 1. Decision Classification Table for Adding Nodes

[0069] In some embodiments of this application, to support the dynamic updating and structural expansion of the execution toolchain, the system can insert node type sub-data with decision-making functions into the execution toolchain based on semantic judgments or user interaction behaviors during task scheduling. To standardize the functional classification and behavioral logic of the inserted nodes, the system categorizes the added node type sub-data according to decision type. Table 1 shows four types of insertable decision type nodes: "Toolchain Update," "Manual Intervention," "Decision Return," and "Reservation," where: The decision point for toolchain update type (decision point code: C) is used to determine whether the current toolchain structure needs to be updated. The system decides whether to trigger toolchain replacement or reconstruction based on the tool's return result and tool linkage status, and generates a new toolchain that matches the current task. Decision points with manual intervention (decision point code: I) indicate that the toolchain has entered a paused state during execution, waiting for manual operation or confirmation. This type of node is usually used to guide users to review, adjust or make decisions on intermediate results. The decision point (decision point code: E) of the decision return type is used to return the tool execution result to the business backend service through the controller. This node serves as the output interface of the task flow and supports result feedback and status synchronization. The reserved type decision point (decision point code: O) is a reserved type preset by the system extension. It does not participate in the specific scheduling logic at present, but can be used as a structural placeholder or interface preset for future functional expansion.

[0070] Step 206: Execute proxy scheduling behavior based on the execution toolchain.

[0071] The method shown in this step has been explained in step 103 and will not be repeated here.

[0072] Specifically, during execution, step 206 will complete the execution actions represented by the sub-data of each node type in the execution toolchain according to the execution order represented by the sub-data of each edge type in the execution toolchain, so as to complete the proxy scheduling behavior.

[0073] In some embodiments of this application, to automate the scheduling and execution of task flows, the system, during execution, will follow the execution order represented by the sub-data of each edge type in the execution toolchain, and complete the execution actions represented by the sub-data of each node type in the execution toolchain, thereby completing the proxy scheduling behavior. Specifically, the system can determine the execution order of each tool node based on the connection relationships defined by the sub-data of each edge type in the execution toolchain, and sequentially trigger the tool calls, data processing, or control operations corresponding to the sub-data of each node type. In this way, the system can automatically advance the task flow without manual intervention, realizing proxy scheduling behavior based on the toolchain structure.

[0074] In a specific example, the system has constructed an execution toolchain containing three nodes: a "data importer," a "data cleaner," and a "data analyzer," and has set the edge type sub-data as the sequential execution path. Based on the connection order of the edge types, the system first calls the "data importer" to complete the data loading operation, then triggers the "data cleaner" to perform format standardization and missing value handling, and finally executes the "data analyzer" to complete model inference and result generation. After completing this execution process, the system completes the entire scheduling flow from data access to analysis output, realizing the automated execution of proxy scheduling behavior within the toolchain structure.

[0075] In some embodiments of this application, to clarify the functional roles and scheduling positions of each node in the execution toolchain, the system divides the sub-data of node types into three types of execution actions: first endpoint execution actions to initiate proxy scheduling behavior, second endpoint execution actions to terminate proxy scheduling behavior, and third endpoint execution actions as relay execution actions. This division helps the system identify the task start point, end point, and intermediate processing flow when building and executing the toolchain, thereby achieving logical closure of the process structure and orderly advancement of the scheduling path.

[0076] The first endpoint executes an action to identify the starting node of the toolchain, typically corresponding to task initialization operations such as data access, parameter loading, or environment preparation. The second endpoint executes an action to identify the ending node of the toolchain, typically corresponding to result output, status feedback, or process termination. The third endpoint executes an action to connect all intermediate nodes between the start and end points, undertaking core task functions such as data processing, model inference, and control judgment.

[0077] exist Figure 5 In the structure shown, three execution software programs represent toolchain processes of different scales. Each process begins with a "start" node as the first endpoint and executes actions with an "end" node as the second endpoint. The intermediate nodes, "Tool 1" to "Tool N," then serve as the third endpoints, forming a complete scheduling path. This structural division allows the system to clearly define the scheduling role of each node during execution and to perform path control, state management, and exception handling accordingly.

[0078] Furthermore, in the process of completing the proxy scheduling behavior, step 206 completes the actual proxy scheduling process according to the following execution logic: Sub-step 2061: If the first execution action represented by the first sub-data of the node type is the first endpoint execution action, execute the first execution action and use the output data generated according to the first execution action as the input data of the second sub-data corresponding to the first sub-data.

[0079] The first endpoint execution action is the execution action used to initiate the agent scheduling behavior; the second sub-data is the sub-data of the subsequent steps of the first sub-data.

[0080] In some embodiments of this application, in order to initiate proxy scheduling behavior and establish the initial data transmission path of the task flow, the system executes the first execution action when the first execution action represented by the first sub-data of the node type is a first endpoint execution action, and uses the output data generated according to the first execution action as the input data of the second sub-data corresponding to the first sub-data. Specifically, after identifying the starting node in the current execution toolchain, the system uses its corresponding first sub-data as the scheduling starting point and triggers the first endpoint execution action represented by that node; subsequently, the system structures the output data generated by the execution action and passes it to the second sub-data logically connected to the first sub-data as the input parameters for subsequent nodes. In this way, the system can establish the initial execution state of the toolchain and ensure that data is transmitted in an orderly manner between the starting point of the process and subsequent nodes, thereby laying the foundation for the advancement of the subsequent scheduling path.

[0081] In a specific example, when the system executes the "Tool 1" node in the "First Execution Software," it identifies this node as the first endpoint execution action, whose function is to load the raw data file submitted by the user. The system triggers the execution action of this node, completes data reading and format parsing, and passes the parsed structured data as the output to the second sub-data corresponding to the "Tool 2" node. After completing this execution process, the system successfully establishes a data transmission path from the task entry point to the second tool node, providing the input foundation for subsequent data cleaning and processing, and realizing the initiation of agent scheduling behavior and the establishment of the initial data stream.

[0082] Sub-step 2062: If the second execution action represented by the second sub-data of the node type is the second endpoint execution action, obtain the output data of the third sub-data corresponding to the second sub-data as the input data of the second sub-data, and execute the second execution action according to the input data.

[0083] The second endpoint execution action is the execution action used to end the agent scheduling behavior; the third sub-data is the sub-data of the preceding step of the second sub-data.

[0084] In some embodiments of this application, in order to complete the termination process of the proxy scheduling behavior and achieve the output or feedback of the task result, when the second execution action represented by the second sub-data of the node type is a second endpoint execution action, the system obtains the output data of the third sub-data corresponding to the second sub-data as the input data of the second sub-data, and executes the second execution action according to the input data. Specifically, after identifying the termination node in the current execution toolchain, the system takes its corresponding second sub-data as the scheduling endpoint and extracts the output data from the third sub-data corresponding to its preceding step; subsequently, the system passes this data as an input parameter to the second sub-data and triggers the second endpoint execution action represented by it. In this way, the system can achieve data closure and task completion flag at the end of the process, thereby ensuring that the proxy scheduling behavior has the termination condition in structure and completes the task objective semantically.

[0085] In a specific example, when the system executes the "Tool 3" node in the "First Execution Software," it identifies this node as the second endpoint execution action. Its function is to write the analysis results to the database and notify the business backend. The system extracts the analysis result data from the third sub-data corresponding to the "Tool 2" node and passes it as input to the "Tool 3" node. The system then triggers the execution action of this node to complete the data writing and status feedback operations. In this way, the system completes the termination process of the proxy scheduling behavior and synchronizes the final result to the business system, realizing task closure and process completion.

[0086] Sub-step 2063: If the third execution action represented by the third sub-data of the node type is a relay execution action, obtain the output data of the fourth sub-data corresponding to the third sub-data as the input data of the third sub-data, execute the third execution action according to the input data, and use the output data generated according to the third execution action as the input data of the fifth sub-data corresponding to the third sub-data.

[0087] The fourth sub-data is the sub-data of the preceding step of the third sub-data, and the fifth sub-data is the sub-data of the following step of the third sub-data.

[0088] In some embodiments of this application, to achieve intermediate process advancement and data transfer in proxy scheduling behavior, when the third execution action represented by the third sub-data of the node type is a relay execution action, the system obtains the output data of the fourth sub-data corresponding to the third sub-data as the input data of the third sub-data, executes the third execution action according to the input data, and uses the output data generated according to the third execution action as the input data of the fifth sub-data corresponding to the third sub-data. Specifically, after identifying the intermediate node in the current execution toolchain, the system uses its corresponding third sub-data as a relay node in the scheduling process and extracts the output data from the fourth sub-data corresponding to its preceding step; subsequently, the system passes this data as an input parameter to the third sub-data and triggers the third execution action it represents; after execution, the system passes the output data generated by the node to the fifth sub-data corresponding to its subsequent step. In this way, the system can achieve continuous data flow and functional connection in the toolchain, thereby ensuring the stable advancement and semantic consistency of proxy scheduling behavior in the intermediate stage.

[0089] In a specific example, when the system executes the "Tool 4" node in the "Second Execution Software," it identifies this node as a relay execution action, whose function is to extract features from the cleaned data. The system extracts the cleaned result data from the fourth sub-data corresponding to the "Tool 3" node and passes it as input to the "Tool 4" node. The system then triggers the execution action of this node, completes feature calculation and structured processing, and passes the generated feature data as output to the fifth sub-data corresponding to the "Tool 5" node. In this way, the system realizes a continuous process from data cleaning to feature extraction and then to subsequent analysis, ensuring the logical closure and data integrity of the agent scheduling behavior in the relay stage.

[0090] like Figure 6 As shown, based on the method provided in the embodiments of this application, a scheduling system under the agent collaboration framework is provided. It organically integrates the business service backend, toolchain management module, container scheduling mechanism and cloud environment resources to form a system with intelligent decision-making capability and elastic execution capability.

[0091] In this architecture, the business service backend, acting as the origin of tasks, transmits task requests to the scheduling core via the controller. The controller coordinates the invocation order of the toolchain and interacts with the service catalog to obtain available tool resources. The decision-maker, during task execution, determines whether to update the toolchain or trigger manual intervention nodes based on the tool's return results and linkage status. The executor undertakes the specific tool invocation tasks, executing the node type sub-data in the toolchain one by one, completing the proxy scheduling behavior.

[0092] The toolchain library plays a role in the system's structure storage and reuse, storing pre-built toolchain instances for the controller to schedule. The agent collaboration framework and agent verification framework server constitute the system's intelligent assurance mechanism; the former enables task collaboration and state synchronization among multiple agents, while the latter verifies the legitimacy of agent actions and the accuracy of execution results.

[0093] The entire system runs on a container management platform, achieving dynamic allocation and elastic scheduling of resources through load management and automatic scaling mechanisms. The underlying cloud environment provides computing and storage support for the system, enabling the scheduling system to have high availability and scalability.

[0094] This architecture not only supports the automated execution of complex tasks, but also has flexible update capabilities and manual intervention interfaces, making it suitable for business process scheduling scenarios involving multiple stages, tools, and roles.

[0095] Optional, such as Figure 7 As shown, based on the above architecture, the progress and status of the session can be tracked, and the decision-maker and executor can work together according to the decision points executed by the toolchain to achieve session control. T1: The system receives a task request from the business backend or user frontend, triggering the start of the scheduling process. This request usually includes the task objective, input parameters, and context identifier. T2: The system creates an independent session instance for each request and initializes the session state structure for state tracking and data isolation in subsequent processes; T3: The system performs semantic parsing and type identification on the received requests to determine whether they belong to query, generation, control, or mixed tasks, so as to select the appropriate processing path; T4: The system searches for available tool resources and service modules in the service catalog based on the request type and task objective to form a candidate tool set; T5: The system matches candidate toolsets with currently available server resources, filters out tool nodes with execution capabilities, and establishes a tool directory mapping relationship; T6: The system selects an appropriate decision-maker module based on the task type and toolchain structure for subsequent toolchain generation, updating, and control logic judgment. T7: The system integrates request parameters, historical session data and toolchain structure to build complete context information for prompt word generation and scheduling logic reasoning; T8: The system loads a preset prompt word template based on the context and task type to guide the generation of the toolchain structure or decision path of the large model; T9: The system distributes the constructed prompts and context data to the matched decision-makers, who then complete the toolchain generation or update judgment. T10: The system receives the toolchain structure data returned by the decision maker, including node type, execution path, decision point identifier, etc., and stores it in the session structure; T11: The system triggers the execution actions of each node sequentially according to the toolchain structure, and controls the execution order, state transmission and manual intervention according to the edge type; T12: The system monitors the status changes of the toolchain execution process in real time, including execution success, abnormal interruption, manual confirmation, etc., and updates the session status. T13: The system determines whether to continue, terminate, or update the session flow based on the current session status and execution result, and returns to the session management module after the process ends or jumps, forming a closed-loop control.

[0096] The above process design supports multi-round task scheduling and dynamic toolchain updates, and has the characteristics of semantic-driven, state-aware, and structural closed-loop, making it suitable for intelligent agent scheduling systems in complex business scenarios.

[0097] Optional, such as Figure 8 As shown, based on the proxy verification framework in the above architecture, a corresponding tool call prediction function can also be designed. By monitoring the tool execution status and using the tool call logs, the tool usage and resource usage can be predicted, enabling automatic scaling and pre-creation of tool instances. U1: The system registers server nodes with tool execution capabilities to the unified management module, forming a schedulable resource pool, and marks the tool types and container specifications they support; U2: Based on the resource requirements and execution environment requirements of the tool's call request, the system matches available nodes among the registered servers to ensure that the tool instance has the conditions to run; U3: The system determines whether a reusable tool instance already exists. If it does, it will be reused first to reduce resource consumption and startup delay. U4: If the tool instance already exists, the system will forward the call request directly to that instance and start the corresponding execution process; U5: After the tool is executed, the system will send the result data or status information back to the scheduling control module or business backend for use in subsequent processes; U6: If the tool instance does not already exist, the system will create a new container instance through the tool image library and update the configuration of the new instance to the image library when necessary to optimize subsequent creation efficiency; U7: The system continuously monitors the running status of tool instances through the container management interface, including metrics such as execution progress, resource usage, and exception feedback; U8: The system automatically adjusts the number of containers and resource allocation strategies based on changes in operating status and task load to achieve elastic scheduling and resource optimization; U9: Based on historical call logs, current status data, and task trends, the system predicts future tool usage frequency and resource requirements, and prepares instances and pre-allocates resources in advance.

[0098] The above process constitutes a tool invocation system with predictive capabilities and elastic management mechanisms, which is suitable for scheduling scenarios with high concurrency, multiple tools, and multiple tasks.

[0099] In summary, in this embodiment, by parsing the requirement description text of the proxy scheduling behavior, corresponding toolchain description data is generated, realizing semantic driving of the task scheduling process from the source. This not only improves the system's ability to understand natural language input but also lays the foundation for the dynamic construction of subsequent task processes, thereby enhancing the system's adaptability to complex tasks. Furthermore, based on the generated toolchain description data, an execution toolchain containing node types and edge types is constructed, so that each execution action is clearly represented, and the execution order between actions can be flexibly defined through edge types. This supports the dynamic adjustment and manual intervention of key nodes in the task process, enabling the system to select paths or reconstruct tasks based on real-time feedback during execution, thereby improving the flexibility and controllability of task scheduling. Finally, by executing proxy scheduling behavior based on the execution toolchain, while maintaining the semantic consistency of the task, automatic tool invocation and dynamic advancement of the task process are achieved, making the task execution process highly fault-tolerant and scalable, and maintaining stable operation in the face of task complexity, environmental changes, or user intervention. Therefore, the method based on the embodiments of this application, by introducing an interventionist toolchain structure and a semantically driven toolchain generation mechanism, reduces system response delays and resource waste caused by process rigidity or tool call failures, and solves the problem of limited existing toolchain management capabilities.

[0100] refer to Figure 9 It illustrates an agent collaboration device 30 based on an interventionist toolchain provided in an embodiment of this application, comprising: Description module 301 is used to generate toolchain description data corresponding to the requirement description text based on the requirement description text used to characterize the agent scheduling behavior; Toolchain module 302 is used to generate an execution toolchain to achieve proxy scheduling behavior based on toolchain description data; the execution toolchain contains sub-data of node type and edge type, the sub-data of node type is used to represent multiple execution actions in proxy scheduling behavior, and the sub-data of edge type is used to represent the execution order between multiple execution actions in proxy scheduling behavior; Execution module 303 is used to execute proxy scheduling behavior based on the execution toolchain.

[0101] Optionally, the description module 301 includes: The template submodule is used to obtain the requirement description text and generate prompt word template data for the agent scheduling behavior based on the requirement description text; The extraction submodule is used to select from the tool identifier list based on the prompt word template data and the requirement description text, so as to determine the target tool identifier dataset from the tool identifier list; The prompt word submodule is used to supplement the prompt word template data based on the requirement description text and the target tool identifiers in the target tool identifier dataset to generate prompt word data for agent scheduling behavior; The description submodule is used to input prompt word data into the toolchain description model to obtain toolchain description data.

[0102] Optionally, toolchain module 302 includes: The parsing submodule is used to extract all toolchain identifiers from the toolchain description data to characterize each step in the agent scheduling behavior; each toolchain identifier has corresponding step identifier information. The toolchain submodule is used to build an execution toolchain based on the corresponding toolchain identifier and step identifier information.

[0103] Optionally, the agent collaboration device 30 based on an interventionist toolchain also includes: The display graph module is used to generate a display graph of the execution toolchain according to the sub-data of node type and edge type in the execution toolchain; The graph update module is used to update the execution toolchain in response to modifications to the displayed graph.

[0104] Optionally, the graph update module includes: The addition submodule is used to respond to the operation of adding nodes in the display graph. It adds sub-data of the node type corresponding to the added node in the execution toolchain, and adds sub-data of the corresponding edge type to the added node type sub-data according to the position of the added node in the display graph. The delete submodule is used to respond to the deletion operation of a node in the display graph. It deletes the sub-data of the node type corresponding to the deleted node in the execution toolchain, and modifies the association relationship of the sub-data of the edge type corresponding to the deleted node type based on the position of the deleted node in the display graph.

[0105] Optionally, the agent collaboration device 30 based on an interventionist toolchain also includes: The model correction module is used to input the execution toolchain into the toolchain correction model in order to update the execution toolchain.

[0106] Optionally, execution module 303 includes: The execution submodule is used to complete the execution actions represented by the sub-data of each node type in the execution toolchain according to the execution order represented by the sub-data of each edge type in the execution toolchain, so as to complete the proxy scheduling behavior.

[0107] Optionally, the execution submodules include: The starting execution unit is used to execute the first execution action when the first execution action represented by the first sub-data of the node type is the first endpoint execution action, and to use the output data generated according to the first execution action as the input data of the second sub-data corresponding to the first sub-data; the first endpoint execution action is the execution action used to start the agent scheduling behavior; the second sub-data is the sub-data of the subsequent steps of the first sub-data; The endpoint execution unit is used to obtain the output data of the third sub-data corresponding to the second sub-data when the second execution action represented by the second sub-data of the node type is the second endpoint execution action, and to use it as the input data of the second sub-data, and to execute the second execution action according to the input data; the second endpoint execution action is the execution action used to end the proxy scheduling behavior; the third sub-data is the sub-data of the preceding step of the second sub-data; The relay execution unit is used to obtain the output data of the fourth sub-data corresponding to the third sub-data when the third execution action represented by the third sub-data of the node type is a relay execution action, and use it as the input data of the third sub-data. The unit then executes the third execution action based on the input data and uses the output data generated based on the third execution action as the input data of the fifth sub-data corresponding to the third sub-data. The fourth sub-data is the sub-data of the preceding step of the third sub-data, and the fifth sub-data is the sub-data of the following step of the third sub-data.

[0108] In summary, in this embodiment, by parsing the requirement description text of the proxy scheduling behavior, corresponding toolchain description data is generated, realizing semantic driving of the task scheduling process from the source. This not only improves the system's ability to understand natural language input but also lays the foundation for the dynamic construction of subsequent task processes, thereby enhancing the system's adaptability to complex tasks. Furthermore, based on the generated toolchain description data, an execution toolchain containing node types and edge types is constructed, so that each execution action is clearly represented, and the execution order between actions can be flexibly defined through edge types. This supports the dynamic adjustment and manual intervention of key nodes in the task process, enabling the system to select paths or reconstruct tasks based on real-time feedback during execution, thereby improving the flexibility and controllability of task scheduling. Finally, by executing proxy scheduling behavior based on the execution toolchain, while maintaining the semantic consistency of the task, automatic tool invocation and dynamic advancement of the task process are achieved, making the task execution process highly fault-tolerant and scalable, and maintaining stable operation in the face of task complexity, environmental changes, or user intervention. Therefore, the method based on the embodiments of this application, by introducing an interventionist toolchain structure and a semantically driven toolchain generation mechanism, reduces system response delays and resource waste caused by process rigidity or tool call failures, and solves the problem of limited existing toolchain management capabilities.

[0109] Reference Figure 10 The electronic device 500 may include one or more of the following components: processing component 502, memory 504, power supply component 506, multimedia component 508, audio component 510, input / output (I / O) interface 512, sensor component 514, and communication component 516.

[0110] Processing component 502 typically controls the overall operation of electronic device 500, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 502 may include one or more processors 520 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 502 may include one or more modules to facilitate interaction between processing component 502 and other components. For example, processing component 502 may include a multimedia module to facilitate interaction between multimedia component 508 and processing component 502.

[0111] Memory 504 is used to store various types of data to support the operation of electronic device 500. Examples of this data include instructions for any application or method operating on electronic device 500, contact data, phonebook data, messages, pictures, multimedia, etc. Memory 504 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0112] Power supply component 506 provides power to various components of electronic device 500. Power supply component 506 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 500.

[0113] Multimedia component 508 includes an interface that provides an output interface between electronic device 500 and user. In some embodiments, the interface may include a liquid crystal display (LCD) and a touch panel (TP). If the interface includes a touch panel, the interface may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may not only sense the boundaries of touch or swipe actions but also detect the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 508 includes a front-facing camera and / or a rear-facing camera. When electronic device 500 is in an operating mode, such as shooting mode or multimedia mode, the front-facing camera and / or rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0114] Audio component 510 is used to output and / or input audio signals. For example, audio component 510 includes a microphone (MIC) used to receive external audio signals when electronic device 500 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 504 or transmitted via communication component 516. In some embodiments, audio component 510 also includes a speaker for outputting audio signals.

[0115] Input / output (I / O) interface 512 provides an interface between processing component 502 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0116] Sensor assembly 514 includes one or more sensors for providing state assessments of various aspects of electronic device 500. For example, sensor assembly 514 may detect the on / off state of electronic device 500, the relative positioning of components such as the display and keypad of electronic device 500, changes in position of electronic device 500 or a component of electronic device 500, the presence or absence of user contact with electronic device 500, orientation or acceleration / deceleration of electronic device 500, and temperature changes of electronic device 500. Sensor assembly 514 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 514 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 514 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0117] Communication component 516 facilitates wired or wireless communication between electronic device 500 and other devices. Electronic device 500 can access wireless networks based on communication standards, such as WiFi, carrier networks (such as 2G, 3G, 4G, or 5G), or combinations thereof. In one exemplary embodiment, communication component 516 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 516 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0118] In an exemplary embodiment, the electronic device 500 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to implement the methods provided in the embodiments of this application.

[0119] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 504 including instructions, which can be executed by a processor 520 of an electronic device 500 to perform the above-described method. For example, the non-transitory storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0120] In an exemplary embodiment, the electronic device 500 may also be provided as a server, including a processing component 502, which further includes one or more processors, and memory resources represented by memory 504 for storing instructions, such as applications, that can be executed by the processing component 502. The applications stored in memory 504 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 502 is configured to execute instructions to perform the methods provided in the embodiments of this application.

[0121] Electronic device 500 may also include a power supply component 506 configured to perform power management of electronic device 500, a wired or wireless communication component 516 configured to connect electronic device 500 to a network, and an input / output (I / O) interface 512. Electronic device 500 may operate on an operating system stored in memory 504, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or similar.

[0122] It should be noted that, for the sake of simplicity, the method embodiments of this application are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily essential to the embodiments of this application.

[0123] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0124] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A proxy collaboration method based on an interventionist toolchain, characterized in that, include: Based on the requirement description text used to characterize the agent scheduling behavior, generate toolchain description data corresponding to the requirement description text; Based on the toolchain description data, an execution toolchain is generated to achieve the proxy scheduling behavior; the execution toolchain includes sub-data of node type and edge type, the sub-data of node type is used to characterize multiple execution actions in the proxy scheduling behavior, and the sub-data of edge type is used to characterize the execution order among the multiple execution actions in the proxy scheduling behavior; The execution toolchain is used to perform proxy scheduling behavior.

2. The proxy collaboration method based on an operable toolchain as described in claim 1, characterized in that, The step of generating toolchain description data corresponding to the requirement description text, which characterizes the agent scheduling behavior, includes: Obtain the requirement description text, and generate prompt word template data for the agent scheduling behavior based on the requirement description text; Based on the prompt word template data and the requirement description text, select from the tool identifier list to determine the target tool identifier dataset from the tool identifier list; The prompt word template data is supplemented based on the requirement description text and the target tool identifiers in the target tool identifier dataset to generate prompt word data for the agent scheduling behavior; The prompt word data is input into the toolchain description model to obtain the toolchain description data.

3. The proxy collaboration method based on an operable toolchain as described in claim 1, characterized in that, The step of generating an execution toolchain to achieve the agent scheduling behavior based on the toolchain description data includes: Extract all toolchain identifiers from the toolchain description data to characterize each step in the agent scheduling behavior; each toolchain identifier has corresponding step identifier information. The execution toolchain is established based on the corresponding toolchain identifier and step identifier information.

4. The proxy collaboration method based on an operable toolchain as described in claim 1, characterized in that, The agent collaboration method based on an operable toolchain also includes: Generate a diagram of the execution toolchain based on the sub-data of node and edge types in the execution toolchain; In response to the modification operation on the display diagram, the execution toolchain is updated.

5. The proxy collaboration method based on an operable toolchain as described in claim 4, characterized in that, The step of updating the execution toolchain in response to a modification operation on the display diagram includes: In response to the operation of adding a node in the display graph, sub-data of the node type corresponding to the added node is added to the execution toolchain, and sub-data of the corresponding edge type is added to the sub-data of the added node type according to the position of the added node in the display graph; In response to the deletion operation of a node in the display graph, the sub-data of the node type corresponding to the deleted node in the execution toolchain is deleted, and the association relationship of the sub-data of the edge type corresponding to the deleted node type is modified according to the position of the deleted node in the display graph.

6. The proxy collaboration method based on an operable toolchain as described in claim 1, characterized in that, The execution proxy scheduling behavior based on the execution toolchain includes: According to the execution order represented by the sub-data of each edge type in the execution toolchain, the execution actions represented by the sub-data of each node type in the execution toolchain are completed to complete the proxy scheduling behavior.

7. The proxy collaboration method based on an operable toolchain as described in claim 6, characterized in that, The step of completing the proxy scheduling behavior by following the execution order represented by the sub-data of each edge type in the execution toolchain, and performing the execution actions represented by the sub-data of each node type in the execution toolchain, includes: When the first execution action represented by the first sub-data of the node type is a first endpoint execution action, the first execution action is executed, and the output data generated according to the first execution action is used as the input data of the second sub-data corresponding to the first sub-data; the first endpoint execution action is the execution action used to start the agent scheduling behavior; the second sub-data is the sub-data of the subsequent steps of the first sub-data; When the second execution action represented by the second sub-data of the node type is a second endpoint execution action, the output data of the third sub-data corresponding to the second sub-data is obtained as the input data of the second sub-data, and the second execution action is executed according to the input data; the second endpoint execution action is an execution action used to end the proxy scheduling behavior; the third sub-data is the sub-data of the preceding step of the second sub-data; When the third execution action represented by the third sub-data of the node type is a relay execution action, the output data of the fourth sub-data corresponding to the third sub-data is obtained as the input data of the third sub-data, and the third execution action is executed according to the input data. The output data generated according to the third execution action is used as the input data of the fifth sub-data corresponding to the third sub-data. The fourth sub-data is the sub-data of the preceding step of the third sub-data, and the fifth sub-data is the sub-data of the subsequent step of the third sub-data.

8. A proxy collaboration device based on an operable toolchain, characterized in that, include: The description module is used to generate toolchain description data corresponding to the requirement description text, based on the requirement description text used to characterize the agent scheduling behavior; The toolchain module is used to generate an execution toolchain to achieve the proxy scheduling behavior based on the toolchain description data; the execution toolchain includes sub-data of node type and edge type, the sub-data of node type is used to characterize multiple execution actions in the proxy scheduling behavior, and the sub-data of edge type is used to characterize the execution order among the multiple execution actions in the proxy scheduling behavior; The execution module is used to perform agent scheduling behavior based on the execution toolchain.

9. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the agent collaboration method based on an interventionist toolchain as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the agent collaboration method based on any one of claims 1 to 7.

Images