Multi-agent bypass management method and device, storage medium and electronic equipment

Abstract

The application provides a multi-agent bypass management method and device, a storage medium and an electronic device, and relates to the field of large models. The electronic device splits a target task into multiple sub-tasks, and configures a task agent for each sub-task; obtains the latest reply information and historical dialogue information of a target agent currently interacting with a user, wherein the latest reply information contains actual calling instructions for the remaining task agents; and verifies the actual calling instructions according to the historical dialogue information, and if the verification result indicates that the instructions are incorrect, controls the target agent to adopt correct target calling instructions. As can be seen, the method guarantees that the multi-agent system can still reliably promote the process in a complex dialogue through bypass verification and active correction.

Description

Technical Field

[0001] This application relates to the field of large language models, and more specifically, to a multi-agent bypass management method, apparatus, storage medium, and electronic device. Background Technology

[0002] While large language models excel at language generation, they often respond passively and cannot actively perform tasks. Therefore, the concept of an agent (also known as an intelligent agent) was proposed. The principle behind this is to add planning, memory, tool use, and action capabilities to the large language model, enabling it to autonomously complete complex tasks.

[0003] For complex tasks, the industry currently commonly uses a single agent to complete the process. Take, for example, scenarios requiring high-precision calculations such as vehicle depreciation and loan interest rate calculations. The current practice integrates the entire qualification review process—including identity verification, funding requirements, vehicle ownership, payment status, vehicle registration certificate, and city details—into a single prompt, managed entirely by a single agent from start to finish. While this approach achieves satisfactory results for simple tasks, its limitations become apparent as the number of review dimensions and the rules become more detailed.

[0004] Because single agents are prone to errors when handling complex tasks, related technologies have proposed multi-agent solutions. The core principle is to divide the responsibilities that would otherwise fall on a single agent into multiple relatively independent agent nodes based on business logic. Specifically, while each review node shares similar constraints or general response logic, the specific review content differs. Examples include agents for identity verification, funding requirements, vehicle ownership, payment status, vehicle registration, and city verification. Each agent has its own unique prompt template, tool namespace, and model inference parameter configuration, communicating with each other through tool calls. This allows for stable control of the prompt length for each agent, resulting in clean context, focused instructions, and simple rules. Large language models no longer need to perform multi-task mixed inference, and instruction compliance capabilities are significantly improved.

[0005] However, in practice, it was found that even with a multi-agent architecture, there may still be issues such as omissions of actions and process stalls under complex intents, making it difficult to complete the entire task. Summary of the Invention

[0006] To overcome at least one deficiency in the prior art, this application provides a multi-agent bypass management method, apparatus, storage medium, and electronic device, which can ensure that the multi-agent system can reliably advance the process in complex dialogues through bypass verification and active correction.

[0007] In a first aspect, this application provides a multi-agent bypass management method, wherein a target task is split into multiple subtasks, and a task agent is configured for each of the multiple subtasks, the method comprising: Obtain the latest response information of the target agent to the user and the historical dialogue information between the target agent and the user, wherein the latest response information includes the actual invocation instructions for other task agents, and the target agent is one of the multiple task agents; The actual invocation command is verified based on the historical dialogue information to obtain the verification result of the actual invocation command; If the verification result indicates that the actual invocation instruction is incorrect, then control the target agent to take the correct target invocation instruction.

[0008] Secondly, this application provides a multi-agent bypass management device, wherein a target task is split into multiple subtasks, and a task agent is configured for each of the multiple subtasks, the device comprising: The current agent module is used to obtain the latest response information of the target agent to the user and the historical dialogue information between the target agent and the user. The latest response information includes the actual invocation instructions for other task agents, and the target agent is one of the multiple task agents. The proxy supervision module is used to verify the actual invocation instruction based on the historical dialogue information and obtain the verification result of the actual invocation instruction; The proxy monitoring module is further configured to control the target proxy to take the correct target invocation instruction if the verification result indicates that the actual invocation instruction is incorrect.

[0009] Thirdly, this application provides a storage medium storing a computer program that, when executed by a processor, implements the multi-agent bypass management method.

[0010] Fourthly, this application provides an electronic device, which includes a processor and a memory, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements the multi-agent bypass management method.

[0011] Compared with the prior art, this application has the following beneficial effects: This application breaks down the target task into multiple subtasks and configures a task agent for each subtask. It obtains the latest response information and historical dialogue information from the currently interacting target agent, where the latest response information includes the actual invocation instructions for other task agents. The actual invocation instructions are verified based on the historical dialogue information; if the verification result indicates that the instruction is incorrect, the target agent is controlled to take the correct target invocation instruction. Therefore, this method, through bypass verification and proactive correction, ensures that the multi-agent system can reliably advance the process even in complex dialogues. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A flowchart illustrating the multi-agent bypass management method provided in this application embodiment; Figure 2 Comparison of measured performance indicators provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the multi-agent bypass management device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0015] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0016] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0017] In the description of this application, it should be noted that the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0018] Based on the above statement, as described in the background section, there are many limitations when using a single agent to accomplish complex tasks.

[0019] To address this, let's continue with the example of vehicle depreciation and loan interest rate calculations in intelligent outbound calling and online review scenarios. To cover multiple review nodes (identity verification, funding requirements, vehicle ownership, payment status, vehicle registration, city, etc.) and numerous rules, a single prompt often needs to cram a large amount of process logic, script rules, and abnormal scenario handling instructions into a single prompt. However, it should be understood that intelligent outbound calling and online review scenarios have high real-time requirements, and models with very high weights are often not used. Therefore, when the prompt is too long, rules conflict with each other, or priorities are unclear, attention is severely diluted, and the large model's ability to follow instructions decreases significantly. This can easily lead to node skipping, script confusion, and "selective blindness" to key constraints, resulting in situations where what should be blocked is not blocked, and what should be approved is not approved during the review process.

[0020] Furthermore, the current practice of cramming all nodes of the entire qualification review process into a single prompt often requires frequent adjustments to the wording and rules at each node in multi-business and multi-industry scenarios. However, existing technologies typically modify the entire prompt directly, adding or deleting content, or changing its structure. This can lead to significant fluctuations in the prompt's effectiveness and result in high iteration costs.

[0021] For example, if the prompt is adjusted in order to resolve Badcase B, then Badcase A, which was previously resolved, will no longer be able to be resolved.

[0022] Therefore, the effects of modified prompts require repeated verification, and there is a lack of an automatic evaluation mechanism to determine whether each change is truly effective and what impact it has on the pass / complaint rate. Furthermore, the prompts and process rules are highly coupled to specific projects, making it difficult to form a pluggable, configurable, platform-based multi-agent review framework, resulting in high migration costs.

[0023] Furthermore, the configuration of parameters for a single model inherently presents a contradiction between rigor and flexibility. Existing monolithic architectures force all process nodes to reuse the same large language model instance and the same set of inference parameters (e.g., Temperature, Top-P). This leads to irreconcilable engineering contradictions. To ensure the strict execution of the review process and the accuracy of state transitions, a low temperature (e.g., 0.1) is typically required to reduce model illusion; however, to achieve a natural, rich, and empathetic dialogue experience, a high temperature (e.g., 0.7-0.9) is needed to increase the flexibility and diversity of generation. In a monolithic architecture, it is impossible to balance both, often resulting in either rigidity like a robot (low temperature side effect) or erratic logic skipping nodes (high temperature side effect), severely degrading the user experience.

[0024] More problematic is that in scenarios requiring high-precision calculations, such as vehicle depreciation and loan interest rate calculations, the mathematical reasoning capabilities of large language models are often insufficient to support business requirements, necessitating reliance on external tools. However, in existing monolithic architectures, as the number of mounted tools increases, the context occupied by tool definitions expands dramatically. When faced with dozens of optional tools, the model is highly susceptible to "parameter illusion" or distraction due to excessive tool definitions, leading to tool misuse and preventing accurate execution of specialized tasks such as "complex vehicle price assessment based on residual value rates."

[0025] Therefore, a multi-agent solution has been proposed in related technologies. Continuing with the example of vehicle depreciation and loan interest rate calculation, this review task can be divided into the following multiple task agents: Agent_step_1: Identity Verification Agent (verify whether the person answering the call is the target customer); Agent_step_2: Funding Needs Agency (Assessing whether the client has funding needs or is willing to learn about the solutions); Agent_step_3: Car Owner Task Agent (Determines whether the customer owns a car); Agent_step_4: Payment Status Agent (determines whether the vehicle is fully paid for or the mortgage has been settled); Agent_step_5: Green Book Agent (Determine whether the green book is within the customer's actual control); Agent_step_6: City Agent (determines whether the customer's city is within the scope of the business and calls the add WeChat or subsequent business process when approved).

[0026] In this way, the review process is broken down into multiple independent task agents. Each task agent has a constant prompt and a short context. Adding a new node only requires hot-swapping configuration and does not consume the context window of the existing node.

[0027] For example, if a vehicle age verification node needs to be inserted between Step_3 (vehicle owned) and Step_4 (payment), simply add a new vehicle age verification agent. This agent queries the vehicle's year and uses tools to calculate the vehicle's age. If the vehicle's age is greater than 12 years, it rejects the request; otherwise, it calls the payment status agent to continue the review.

[0028] Therefore, in theory, it can support 10+, 20+ or ​​even more nodes without reducing the instruction compliance capability of a single node, making it easy for the platform to quickly adapt to multi-dimensional access scenarios such as vehicle age and vehicle price.

[0029] However, after practical experience, it was found that even with a multi-agent architecture, there may still be issues such as omissions of actions and process stalls under complex intents, making it difficult to complete the entire task.

[0030] For example, let's continue with the scenario of calculating vehicle depreciation and loan interest rates. Although the multi-agent architecture breaks down the review process into multiple single-responsibility agent nodes such as identity verification agent, funding requirement agent, vehicle ownership agent, payment status agent, vehicle registration agent, and city verification agent, each agent handles only a specific goal and is equipped with its own independent prompt word template, tool namespace, and model inference parameters, these agents still rely on the results generated by the large language model to drive the process in actual dialogue. The generation mechanism of the large language model is essentially probabilistic and context-sensitive, prioritizing the most prominent, emotionally charged, or easily associative information in the user's latest input.

[0031] In practice, it was found that in a multi-agent architecture, when a customer raises a new question while answering a question at the current node, the agent at the current node is easily attracted by the new question, only generating explanatory text and omitting tool calls for workflow transition, resulting in only answering without transitioning, and the dialogue going around in circles at the completed node.

[0032] For example, when a customer replies at the "Car Agent" stage, "I do have a car, but I have a previous overdue payment, can I still apply?", this statement contains both a clear affirmation of the current stage (whether or not they have a car) and a new question across stages (whether overdue payments affect eligibility). At this point, the word "overdue" carries a risk warning attribute and an urge to explain, easily activating the model to continue answering questions about credit, risk control, and compliance. This causes the model to focus entirely on generating a reassuring or explanatory statement, completely ignoring the fact that the customer's answer "I do have a car" means the "Car Agent" has completed their task at the current stage and needs to call upon the next agent to continue interacting with the user. Thus, the next round is still the "Car Agent" interacting with the customer again, asking, "Do you own a car?", creating an ineffective loop.

[0033] Therefore, due to the interference of complex intentions, a structural omission occurred in the model execution layer, which caused the entire review process to logically meet the jump conditions, but physically remain stagnant. This ultimately lengthened the dialogue rounds, slowed down the overall task completion speed, and brought a very bad interactive experience to the customer.

[0034] It should be noted that the defects in the solutions in the prior art are all the results of the inventors’ practice and careful research. Therefore, the discovery process of the above problems and the solutions proposed by the embodiments of this application in the following text should be the inventors’ contributions to this application in the process of invention and creation, and should not be understood as technical content known to those skilled in the art.

[0035] Based on the aforementioned technical problems, this embodiment provides a multi-agent bypass management method. In this method, the target task is split into multiple subtasks, and a task agent is configured for each subtask. It should be noted that the multi-agent bypass management method can also be implemented based on agent technology, and is referred to as a bypass monitoring agent. For example... Figure 1 As shown, the method includes: S1, obtain the target agent's latest response information to the user and the historical dialogue information between the agent and the user.

[0036] The latest response includes the actual invocation instructions for the remaining task agents, with the target agent being one of the multiple task agents.

[0037] S2, verify the actual call command based on the historical dialogue information, and obtain the verification result of the actual call command.

[0038] S3, if the verification result indicates that the actual invocation instruction is incorrect, then control the target agent to take the correct target invocation instruction.

[0039] This embodiment can be understood as follows: the target task is broken down into multiple subtasks, and a task agent is configured for each subtask; the latest response information and historical dialogue information of the target agent currently interacting with the user are obtained, where the latest response information includes the actual invocation instructions for other task agents; the actual invocation instructions are verified based on the historical dialogue information, and if the verification result indicates that the instruction is incorrect, the target agent is controlled to take the correct target invocation instruction. Therefore, this method, through bypass verification and active correction, ensures that the multi-agent system can reliably advance the process in complex dialogues.

[0040] It should be understood that the multi-agent bypass management method provided in this embodiment can be implemented in real time via electronic devices such as mobile terminals, tablet computers, laptop computers, desktop computers, and servers. When implemented with a server, the server can be a single server or a group of servers. The server group can be centralized or distributed (e.g., the server can be a distributed system). In some embodiments, the server can be local or remote relative to the user terminal. In some embodiments, the server can be implemented on a cloud platform; by way of example only, the cloud platform can include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, inter-cloud, multi-cloud, etc., or any combination thereof. In some embodiments, the server can be implemented on an electronic device having one or more components.

[0041] To make the solution provided in this embodiment clearer, a server is used as an example below, and in conjunction with... Figure 1 Each step of the method is described in detail. However, it should be understood that the operations in the flowchart may not be implemented in sequence, and steps without logical contextual relationships may be reversed in order or performed simultaneously. Furthermore, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowchart, or remove one or more operations from the flowchart. See also... Figure 1 The method includes: S1, obtain the target agent's latest response information to the user and the historical dialogue information between the agent and the user.

[0042] The latest response information includes the actual invocation instructions for the remaining task agents, with the target agent being one of multiple task agents. Furthermore, the latest response information includes both natural language response content and structured tool invocation instructions.

[0043] Therefore, this embodiment can be understood as follows: during the operation of the multi-agent dialogue system, the server synchronously collects two types of key input data to support bypass verification and correction actions. Specifically, the server obtains the latest response information from the target agent to the user. This latest response information refers to the complete response content generated by the target agent in the current round and intended to be output to the user. It includes the target response text in natural language form and the actual invocation instructions for other task agents used to trigger process jumps.

[0044] In practical applications, after receiving the inference output from the target agent, the server parses it into two logically coexisting but functionally separate parts. One part is the user-facing natural language response content (Text), i.e., the conversational dialogue generated by the model; the other part is the structured tool call instructions (Tool) used for flow control, such as function call instructions like "transfer_to_agent_step_3". This output format follows a preset Text+Tool synchronous output protocol, and the specific behavior pattern is pre-defined by the prompt word template bound to the target agent. For example, when the customer inputs a short affirmative statement (e.g., "Yes, it's me"), the target agent can output only the Tool without generating Text; this is the silent transfer mode. When the customer affirms their identity while asking a question (e.g., "I am, but how do you know my information?"), the target agent can output a short explanatory Text and the corresponding Tool simultaneously; this is the speech-driven transfer mode.

[0045] In this way, the server obtains the latest response information from the target agent through standardization, which can truly reflect the model's ability to coordinate the dual goals of responding to customers and advancing the process in a single round of interaction.

[0046] For example, let's continue with the scenario of calculating vehicle depreciation and loan interest rates. When a user replies in the "Car Task Agent" section, "I have a car, but I have a history of overdue payments, can I still do this?", the latest reply generated by the task agent will be: Text: Hello, we will comprehensively evaluate the overdue payment situation based on your credit report. It also includes an actual calling instruction (also known as function_call): "Tool:transfer_to_agent_step_4" It should be noted that the actual call instruction will be presented differently in different stages of the dialogue. For example, when the review of the current node is not completed, the actual call instruction should theoretically be empty or specially marked, indicating that there is no need to jump to the next node. Conversely, when the review of the current node is completed, the actual call instruction should theoretically be the target call instruction for the next review stage. Therefore, when a call instruction is given when no jump is needed, or when a jump should be given but a call instruction is not given or an incorrect call instruction is given, it is considered that the actual call instruction has been omitted or is incorrectly formatted.

[0047] In addition, the server also obtains historical dialogue information between the target agent and the user. This historical dialogue information refers to a continuous context fragment consisting of several rounds of customer inquiries, responses from various task agents, and corresponding review conclusions that occurred before the target agent participated in this round of interaction. The target agent is one of multiple task agents, each corresponding to a sub-task in the qualification review process, such as an identity verification agent, a funding requirement agent, or a vehicle-related task agent. During this process, the server verifies both types of information.

[0048] As an optional implementation, each task agent has an independent toolspace, which provides invocation tools that can only be used by the corresponding task agent.

[0049] In practical applications, when initializing each task agent, the server dynamically loads an independent toolspace for it. This toolspace contains only the function tools necessary for the current review node and their simplified definitions. For example, in the toolspace of the "car price estimation" task agent, only the tool "calculate_car_depreciation" and its corresponding parameter model (including fields such as vehicle model, registration year, mileage, and city code) are pre-set, while tools for all other nodes (such as credit inquiry, traffic violation verification, and credit limit calculation) are hidden. The server does not provide the task agent with any tool description information beyond the scope of its toolspace, so that it cannot perceive or generate call requests for unrelated tools during the inference process.

[0050] In this process, the tool spaces used by each task agent are logically isolated from each other, without sharing tool definitions or parameter contexts. When the server constructs the prompt input for the task agent, it only injects the tool descriptions within its own tool space into the model context, thereby significantly compressing the total amount of tool semantics it needs to process. Since the model only needs to understand a small number of highly relevant tool interfaces each time, its accuracy in recognizing parameter names, types, and value ranges is greatly improved, thus ensuring the determinism of tool invocation behavior and the reliability of business execution, and reducing the risk of parameter illusion and mis-invocation in scenarios where multiple tools coexist.

[0051] Based on the descriptions of the latest response information and historical dialogue information in the above embodiments, the following will continue to discuss... Figure 1 Step S2 will be explained below: S2, verify the actual call command based on the historical dialogue information, and obtain the verification result of the actual call command.

[0052] In this embodiment, the verification results can be generated by a pre-trained side-channel supervision model. It should be noted that since the side-channel supervision model needs to continuously and in real-time participate in every user interaction in the background, using a model of the same size as the task agent would result in excessive consumption of server computing resources, increased response latency, and impact on the real-time performance of the main dialogue stream. Therefore, the model parameters of the side-channel supervision model are smaller than the parameters of the model used by each task agent.

[0053] Specifically, the bypass supervision model deployed on the server only needs to complete logical truth judgments, such as verifying whether "the client has clearly confirmed the current node" and "the actual call instruction exists". It does not need to generate natural language or complex reasoning. Therefore, a lightweight model with fewer parameters and faster reasoning can be used.

[0054] The verification result can include intervention instructions in text form (hint_text), which can take the following form: { "signal_type": "force_handoff", "reason": "user_confirmed_vehicle", "hint_text": "[System prompt: The system has detected that the customer already owns a vehicle. Please do not ask again. After answering the customer's questions, immediately call transfer_to_agent_step_4 to proceed to the next step.]" } It's worth noting that due to the small size of this bypass supervision model, its inference ability is generally limited. In practice, it was found that the text-based intervention instructions it generates might return to calling task agents that have already completed their tasks, creating an infinite loop between multiple task agents and preventing the completion of the entire target task. Therefore, the server also obtains the current historical call chain, which records the task agents that have been called and their call relationships. The bypass supervision model is then used to process the historical dialogue information, the latest response information, and the historical call chain to obtain the verification results of the actual call instructions.

[0055] This embodiment can be understood as introducing an independent bypass monitoring agent as a logical judge through the server. This agent analyzes historical dialogues and the latest responses in real time to determine whether the current node has completed its task but has not triggered the invocation of the next task agent. This bypass monitoring agent can adopt a fast-response, low-parameter model. Its system prompt is set to be a pure logical judge, not responsible for dialogue. The input to the bypass monitoring agent includes the current dialogue history and the user's latest response. In addition to the above two types of information, it also provides the current historical call chain, which records the task agents that have been invoked and the call relationships between them. The purpose of introducing the historical call chain is to prevent the bypass monitoring agent from generating incorrect intervention instructions due to limited reasoning capabilities, such as calling back a task agent that has already completed its review and exited the process, thus causing an infinite loop. Therefore, when generating verification results, the bypass monitoring agent uses the historical call chain as a key constraint to ensure that its output text-based intervention instructions only point to subsequent task agents that have not yet been executed or completed.

[0056] The bypass supervision model, based on the input information, needs to check whether the target agent has logically answered the core question affirmatively and whether the target agent's output includes a tool call to the next task agent point. If the core question has been answered, but the tool call to the next task agent point is empty or the called task agent is incorrect, then the actual call instruction is determined to be erroneous.

[0057] Based on the above explanation of the verification results, we will continue with the following... Figure 1 Step S3 will be explained below: S3, if the verification result indicates that the actual invocation instruction is incorrect, then control the target agent to take the correct target invocation instruction.

[0058] As an optional implementation, the server does not directly modify the target agent's output. Instead, it transforms the verification result into a high-priority natural language intervention instruction and seamlessly embeds it into the user's input information before the next round of dialogue begins. During the next round of inference, the target agent treats this instruction as an indispensable contextual constraint, thus proactively triggering the correct target invocation instruction while generating a response. Based on this concept, this embodiment provides the following optional implementation for step S3: S3-1A: Obtain input information for the user to conduct the next round of dialogue with the target agent.

[0059] S3-2 A, add the intervention instructions to the input information to obtain the input information after intervention.

[0060] It should be understood that the input information includes the system prompts for the target agent and the prompts entered by the user in the next round of dialogue. Therefore, the server can append intervention instructions to the system prompts or prompts to obtain the input information after intervention.

[0061] S3-3 A: Input the interventioned input information into the target agent so that the target agent can take the target invocation instruction in the next round of dialogue with the user.

[0062] Optionally, in this embodiment, the verification result is converted into an intervention instruction in natural language form by the server, and embedded into the inference context of the target agent before the next round of dialogue is initiated, so as to guide the user to complete the missing actions in a way that is imperceptible to the user.

[0063] Continuing with the example of the verification results above, which includes three fields: signal_type, reason, and hint_text. In practical applications, after receiving the verification results generated by the bypass monitoring agent, the server extracts the content of the hint_text field, which is a text-based intervention instruction with clear behavioral guidance. This instruction is designed as a prompt that conforms to human reading habits, for example, "[System prompt: It has been detected that the customer has a vehicle registered under their name. Please do not ask repeatedly. After answering the customer's concerns, immediately call transfer_to_agent_step_4 to proceed to the next step.]".

[0064] The server then determines the input structure for the current round. If the input for the next round has not yet been generated, the intervention instruction is appended to the end of the system prompt for the target agent. If the user has submitted a new question, it is inserted before the user prompt. In either case, the intervention instruction is sent to the target agent's reasoning process as a high-priority context.

[0065] During this process, the target agent is unaware that the instruction comes from an external correction mechanism. Instead, it treats it as part of the task constraints and actively matches and triggers the corresponding target invocation instruction while generating a natural language response. Since the instruction directly affects the model's attention focus, it avoids the forced overwriting of historical outputs or backend rule intervention, thus ensuring both dialogue coherence and reliable action completion.

[0066] This demonstrates that by implementing lightweight, non-intrusive instruction injection at the server level and cleverly leveraging the strong responsiveness of large language models to explicit prompts, the problem of only answering without turning around in complex intent scenarios can be solved without interrupting the dialogue flow.

[0067] As another optional implementation, after determining that the actual invocation instruction contained in the latest response information of the target agent is incorrect, the server does not rely on its regeneration, but directly parses the target invocation instruction to be executed based on the intervention instruction in text form, and replaces it into the original response structure at the output layer; this replacement operation occurs after the model output and before it is presented to the user, ensuring that the final executed action meets the business logic requirements. Based on this concept, this embodiment also provides the following optional implementation of step S3: S3-1B generates target invocation instructions based on intervention instructions.

[0068] S3-2B replaces the actual invocation instruction in the latest response information with the target invocation instruction, so that the target agent executes the target invocation instruction.

[0069] In practical applications, after receiving the text-based intervention instructions contained in the verification results, the server first performs semantic parsing to extract the target invocation instruction to be executed. This parsing process can be based on preset rules or lightweight structured matching without relying on large language models for re-inference. For example, it can directly identify the function name "transfer_to_agent_step_4" and its necessary parameter placeholders from "immediately invoke transfer_to_agent_step_4". The server locates the actual invocation instruction that already exists in the latest response information and replaces it in place with the target invocation instruction. If the original response does not contain any tool invocation, the target invocation instruction is inserted to form a complete Text+Tool output structure. This replacement operation does not affect the internal inference logic of the target agent, nor does it change the natural language part of its original generated content.

[0070] Throughout this process, the server prioritizes ensuring the continuity and determinism of the business process, ensuring that the final response delivered to the user retains the wording generated by the target agent while strictly meeting the business rules requirements for node flow.

[0071] In practice, it was found that the original response text generated by the target agent may contain sensitive content such as customer identity information, contact information, and financial data. Directly outputting this information to users would violate relevant personal information protection regulations. If the server relies solely on its own model to avoid sensitive words, omissions or misjudgments are likely, leading to compliance risks. Therefore, the latest response information also includes the target response text provided to the user, and provides... Figure 1 The following are optional implementations of step S1: S1-1, Obtain the original response information generated by the target agent in response to the user.

[0072] The original response information includes the original response text.

[0073] S1-2, Extract the original response text from the original response information.

[0074] S1-3 If the original response text contains sensitive information, the sensitive information in the original response text is adjusted to obtain the target response text.

[0075] Optionally, in this embodiment, after the server obtains the original response information from the target agent, it performs extraction, recognition, and adjustment operations step by step to ensure that the target response text provided to the user not only meets the requirements of natural language dialogue but also satisfies the output specifications for data security.

[0076] In practical applications, the server receives the original response information generated by the target agent in response to the user. This original response information is a complete structured response natively output by the model, explicitly including the original response text (i.e., user-facing natural language content) and any possible tool call instructions (function_call). The server then precisely extracts the original response text from this original response information. Based on preset general security and compliance rules, the server performs dual verification on the original response text. On the one hand, it detects and replaces prohibited words; on the other hand, it identifies and de-identifies sensitive information, such as ID card numbers, mobile phone numbers, specific amounts, and internal technical terms, to avoid exposing implementation details or unauthorized personal information to the user. This adjustment process is strictly limited to the scope of the original response text and does not modify any call instructions, thereby ensuring the integrity and executability of the tool call instructions.

[0077] Thus, this embodiment decouples the adjustment of sensitive information from the protection of tool calls, preventing the accidental deletion of key parameters during the cleaning operation and ensuring that all user-facing text content is filtered for compliance.

[0078] In practice, it was found that in multi-task agent dialogue systems, there may be a semantic disconnect between the natural language response text output by the target agent to the user (i.e., the target response text) and the actual process action executed (i.e., the target invocation instruction, such as transfer_to_agent_step_3). For example, the model might reply to the customer, "Okay, we'll arrange the next step for you right away," but without triggering any target invocation instruction. Or it might reply, "Let me check the green book status for you," but incorrectly invoke the payment status verification tool. This inconsistency of "saying one thing and doing another" not only confuses the user but can also lead to system process malfunction.

[0079] Therefore, as an optional implementation, the server can also obtain the semantic similarity between the target response text and the target call instruction; if the semantic similarity is less than the threshold, the target response text is adjusted according to the target call instruction to obtain the optimized response text; the optimized response text is then used to replace the target response text to obtain the optimized reply information.

[0080] In practical applications, after obtaining the latest response information generated by the target agent, the server simultaneously extracts the target response text and the target invocation command, and calculates the semantic similarity between them using a lightweight semantic matching model (e.g., based on sentence vector cosine similarity). This similarity is used to measure whether the user's understanding of what will happen next from the text matches the actual action to be performed. If the calculated semantic similarity is lower than a preset threshold (e.g., 0.4), it indicates a significant discrepancy between the two; in this case, the server does not directly discard or resend the response, but instead optimizes the target response text using the target invocation command as a semantic anchor.

[0081] For example, if the instruction is transfer_to_agent_step_4 (enter payment status verification), and the original response is "Let me double-check your other information," it can be optimized to "Okay, we'll verify the vehicle payment status for you right away." The optimized response text more accurately reflects the action to be taken and maintains a natural, conversational tone. Finally, the server replaces the original target response text with this optimized response text, forming a semantically consistent and reliable final reply.

[0082] The study also found that when a target agent triggers a target invocation instruction and transfers the dialogue flow to a downstream task agent due to a customer's complex intent, if the cross-node intent expressed by the user in the current round (e.g., how much interest?, can I use my car as collateral?) is not conveyed, the downstream task agent lacks contextual basis, is prone to asking the same question repeatedly or missing answers, and causes the user to have to repeat the same question multiple times, reducing review efficiency and user experience.

[0083] In view of this, as an optional implementation, the latest response information also includes the user's intent recognition result. The server will also obtain the agent summary of the target agent and add the intent recognition result and agent summary as prior information to the context of the task agent invoked by the target invocation instruction.

[0084] In essence, this embodiment uses the server to inject the user's cross-node intent identified by the preceding task agent and the summary of the review conclusion generated by the task agent itself as structured prior information into the context of the prompt words of the next task agent called by the target invocation instruction during the multi-agent orchestration process. This allows the subsequent task agent to accurately inherit the process and proactively respond to any unresolved questions raised by the customer that are related to the current node, without increasing the complexity of single inference.

[0085] In practical applications, when the target agent completes the current round of interaction and outputs a response containing natural language content and tool calls, the server first extracts the user's intent recognition result from it. For example, in the "funding need agent" stage, the user answers, "Yes, I have a need, but the car is still under loan and the vehicle registration certificate is with the bank. Can you do it?" This sentence contains multiple sub-intents, including "funding need" (strongly related to the current node), "the car is still under loan" (corresponding to the payment status agent), and "vehicle registration certificate controllability" (corresponding to the vehicle registration certificate agent). Among these, only the "funding need" is determined by the current target agent and forms the review conclusion, while the other sub-intents are marked as cross-node intents and written into the pending intent queue.

[0086] At the same time, the server also generates a proxy summary for the target proxy, which includes the current node's review conclusion (e.g., "Funding needs = Yes") and its key evidence (e.g., "The customer clearly stated that there is a need, and subsequent inquiries about the amount and interest constitute a logically positive signal"), and compares it with the aforementioned cross-node intention. Figure 1 This information is then encapsulated as a handover message. When the server activates the next task agent based on the target call instruction, it adds this handover message to the task agent's prompt as a structured variable or special tag, so that the agent knows which judgments the preceding node has completed, which related questions the user has asked, and which questions are still pending a response before generating a reply.

[0087] In practice, this handover message can be manifested as follows:<CONVERSATION HISTORY> ...structured fields embedded in the fragment, for example: <CONVERSATION HISTORY> { "prior_intentions": ["Car is still under loan", "Green book controllability"], "agent_summary": { "node": "funding requirements", "result": "Yes", "reason": "The customer proactively inquired about credit limits and interest rates." } } < / CONVERSATION HISTORY> During this process, the task agent invoked by the target invocation instruction simultaneously obtains the aforementioned prior information when receiving input, thereby enabling it to respond to customer concerns in a targeted manner while meeting the core review requirements of this node.

[0088] For example, when a user replies in the Funds Request Agent (Agent_step_2) step: "Yes, there is a need. The car is still under loan and the vehicle registration certificate is with the bank. Can you do that?" After identifying the intent, the server determined that it contained three sub-intents: (1) Funding needs that are strongly correlated with the current node; (2) Payment status across nodes (the car is still under mortgage); (3) Green book status across nodes (green book at the bank).

[0089] The server uses the latter two as intent recognition results and injects them as prior information into the context of the payment status agent (Agent_step_4) activated by the target invocation command "transfer_to_agent_step_4". When this agent responds for the first time, its prompt already contains structured information similar to the following: [The car is still under loan, and the vehicle registration certificate is with the bank.] Based on this, Agent_step_4 can naturally follow up in the first round of dialogue: "You mentioned that the car is still under loan and the vehicle registration certificate is with the bank. This will not affect the processing at all. We support pre-approval before the loan is fully repaid. Next, I will help you confirm the specific repayment details, okay?" In this way, unlike the traditional method of mechanically asking "Is your car paid for in full or financed?", there is no need to wait for the customer to bring up the green book again.

[0090] It should also be noted that when the target task is broken down into multiple subtasks and executed by independently configured task agents, different task agents may use different large language models in actual operation, or they may use the same model but set different inference parameters (such as temperature coefficient) to adapt to the characteristics of their corresponding subtasks.

[0091] For example, in the multi-agent qualification review system provided in this embodiment, logical decision-making nodes such as "payment status verification" and "vehicle price calculation" have extremely high requirements for reasoning accuracy, rule compliance, and tool call determinism. Therefore, they are configured to run on a model base with large parameters and strong logical reasoning capabilities, such as Qwen-72B or GPT-4-Turbo, and are uniformly set with low temperature (Temperature=0.1) and low kernel sampling (Top-P=0.1) parameters to suppress randomness, eliminate illusions, and ensure that the tool call output strictly conforms to the predefined parameter structure.

[0092] Correspondingly, for emotionally interactive nodes such as "opening remarks, retention techniques, and requests to add each other on WeChat," the focus is on naturalness, response speed, and diversity of language. Therefore, a lightweight, highly humanized model (such as GPT-4o-mini) or a dedicated Chat model with dialogue fine-tuning is selected. A parameter combination of high temperature (Temperature=0.8) and moderate presence penalty (Presence Penalty=0.6) is used to stimulate rich expression, enhance the persuasiveness of spoken language, and avoid mechanical repetition.

[0093] This allows each agent to achieve a high degree of matching between capabilities and tasks under a unified architecture, ensuring zero deviation in key review processes and raising the upper limit of user experience.

[0094] While the aforementioned differentiated model configuration enhances the professionalism and user experience of each node, it also leads to a lack of consistency in the language style among task agents. For example, if one agent confirms the customer's identity in a concise and formal tone, but the next agent suddenly switches to an enthusiastic and conversational tone to inquire about funding needs, it can easily create a disconnect for the user, affecting the overall credibility of the conversation and the sense of professionalism of the service.

[0095] In related technologies, when the target agent triggers the target invocation command, the server can analyze the interaction process between the target agent and the user in real time and extract several performance indicators reflecting the dialogue state, including but not limited to whether the customer uses interrogative words multiple times in the current or recent rounds of dialogue, whether there are long pauses, whether the same question is asked repeatedly, whether the number of words in a single round of reply is significantly reduced, and whether the anxiety / impatience score output by the emotion recognition model exceeds the threshold.

[0096] Based on these metrics, the server makes conditional, minor adjustments to the inference parameters of the large language model invoked by the next task agent that will be activated, such as the model's temperature coefficient, kernel sampling threshold, and frequency penalty factor, so that the speech generated by the next task agent is consistent with the language style of the target agent.

[0097] For example, if it is detected that a user has asked "How did you know my information?" twice in a row during the identity verification process, indicating a clear lack of trust, then when transferring the case to the funding request agent, the model's temperature coefficient will be gently increased from the default 0.1 to 0.35, and the frequency penalty factor will be slightly reduced simultaneously. This makes the model more inclined to generate explanatory and empathetic opening statements (e.g., "We understand your concern about the source of information. We obtained the basic information through the channels you previously authorized. Next, we will only focus on helping you assess whether you meet the funding support conditions"), rather than mechanically repeating standard statements. Conversely, if the customer is concise and affirmative throughout the process without any follow-up questions, the model's temperature coefficient can be maintained at a low level to ensure that the process proceeds efficiently and without redundancy.

[0098] However, practical experience revealed fundamental differences in the requirements for model behavior across different sub-tasks. For instance, the identity verification node requires zero illusion and strong determinism, necessitating a low temperature coefficient to ensure rigid rule execution; while the funding requirement stage demands high anthropomorphism to persuade users to mortgage as much as possible, relying on a higher temperature coefficient. If, due to slight hesitation from the customer in the preceding node, the agent parameter, which should rigorously determine payment status, is temporarily increased, it is highly likely to introduce vague statements (e.g., "It should be almost paid off") when verifying the crucial fact of whether the mortgage is settled, leading to distorted audit conclusions. In other words, while maintaining a consistent language style, it comes at the cost of sacrificing the accuracy of core business logic.

[0099] Therefore, as an optional implementation, the server can obtain the language style description information of the target agent based on historical dialogue information; and add the language style description information as constraint information to the context of the task agent invoked by the target invocation instruction.

[0100] This embodiment can be understood as follows: during the task agent switching process, the server does not directly modify the inference parameters such as the temperature coefficient of the large language model called by the next task agent. Instead, it extracts the language expression features of the previous target agent based on historical dialogue information and adds the language style description information as a constraint prompt to the prompt word context of the task agent called by the target call instruction. In this way, the natural connection of cross-agent dialogue styles can be achieved without interfering with its original functional logic and business accuracy.

[0101] In practical applications, when the current target agent completes the interaction and triggers the target invocation command, the historical dialogue information between it and the user is analyzed first to summarize style description information that can characterize its language behavior pattern, for example: "Use short sentences more often, tend to end with affirmative sentences, and avoid technical jargon." "Make good use of rhetorical questions to guide the response, often paired with modal particles such as 'ya' and 'ne,' and include at least one analogy in the reply."

[0102] Therefore, this language style description does not interfere with the model's internal parameters, but rather constitutes a clear and semantically explicit natural language constraint. For example: "Please keep your answers concise and clear, with each sentence not exceeding 15 characters; all conclusive statements should begin with explicit words such as 'yes,' 'can,' or 'confirmed'; do not use vague adverbs such as 'maybe,' 'probably,' or 'should.'"

[0103] During this process, the server does not change the default model parameters of the agent, but only provides lightweight expression guidance to keep the rhythm and tone of the speech consistent with the previous agent, thus avoiding a sense of discontinuity in language style after switching task agents.

[0104] In summary, the multi-agent bypass management method provided in this embodiment was compared with the traditional single-agent solution, specifically involving indicators such as pass rate (the proportion of all nodes that complete the review and enter the WeChat / subsequent process), average number of dialogue rounds, mid-term hang-up rate, node skipping / repeated questioning rate, average GPU inference time and cost.

[0105] like Figure 2 As shown, the multi-agent bypass management method provided in this embodiment reduces node chaos and computing power costs while maintaining or improving the approval rate and customer experience, and improves the system's engineering maintainability and platformization.

[0106] Based on the same inventive concept as the multi-agent bypass management method provided in this embodiment, this embodiment also provides a multi-agent bypass management device. This device includes at least one software functional module that can be stored in memory or embedded in an electronic device. The processor in the electronic device executes the executable module stored in the memory. For example, the software functional module and computer program included in this multi-agent bypass management device. Please refer to... Figure 3 Functionally, the device may include: The current agent module 11 is used to obtain the latest response information of the target agent to the user and the historical dialogue information between the target agent and the user. The latest response information includes the actual calling instructions for other task agents. The target agent is one of the multiple task agents. The proxy supervision module 12 is used to verify the actual call command based on the historical dialogue information and obtain the verification result of the actual call command. The agent supervision module 12 is also used to control the target agent to take the correct target invocation instruction if the verification result indicates that the actual invocation instruction is incorrect.

[0107] In this embodiment, the current proxy module 11 is used to implement Figure 1 In step S1, the agent supervision module 12 is used to implement Figure 1Steps S2 and S3 in the above steps. Therefore, for a detailed description of each of the above modules, please refer to the implementation method of the corresponding step.

[0108] Optionally, the verification results include intervention instructions in text form, and the agent supervision module 12 controls the target agent to take the correct target invocation instructions in the following ways: Obtain input information from the user for the next round of dialogue with the target agent; The intervention instructions are appended to the input information to obtain the input information after the intervention; The intervention-input information is fed into the target agent so that the target agent can take the target invocation instruction in the next round of dialogue with the user.

[0109] Optionally, the input information includes the target agent's system prompts and prompts entered by the user in the next round of dialogue; The agent monitoring module 12 appends intervention instructions to the input information, and the methods for obtaining the post-intervention input information include: The intervention command is appended to the system prompt or message to obtain the input information after the intervention.

[0110] Optionally, the verification results include intervention instructions in text form, and the agent supervision module 12 controls the target agent to take target invocation instructions in the following ways: Based on the intervention instructions, generate the target invocation instructions; Replace the actual invocation instruction in the latest response information with the target invocation instruction so that the target agent executes the target invocation instruction.

[0111] Optionally, the validation results are generated by a pre-trained side-channel supervision model, the model parameters of which are smaller than the parameters of the model used by each task agent. The agent supervision module 12 is also used for: Get the current historical call chain, which records the task proxies that have been called and their call relationships; The proxy supervision module 12 verifies the actual invocation command based on historical dialogue information, and obtains the verification result of the actual invocation command in the following ways: By using a bypass supervision model to process historical dialogue information, latest response information, and historical call chains, the verification results of the actual call instructions are obtained.

[0112] Optionally, the latest response information also includes the target response text provided to the user. The current agent module 11 obtains the latest response information from the target agent to the user in the following ways: Obtain the original response information generated by the target agent in response to the user, wherein the original response information includes the original response text; Extract the original response text from the original response information; If the original response text contains sensitive information, the sensitive information in the original response text will be adjusted to obtain the target response text.

[0113] Optionally, the latest response information also includes the user's intent recognition results, and the agent supervision module 12 is further used for: Obtain the proxy summary of the target proxy; The intent recognition results and agent summary are added as prior information to the context of the task agent invoked by the target invocation instruction.

[0114] Optionally, the agent supervision module 12 is also used for: Based on historical dialogue information, obtain the target agent's language style description information; The language style description information is added as constraint information to the context of the task agent invoked by the target invocation instruction.

[0115] Optionally, the latest response information also includes the target response text provided to the user, and the proxy supervision module 12 is further used for: Obtain the semantic similarity between the target response text and the target invocation command; If the semantic similarity is less than the threshold, the target response text is adjusted according to the target invocation instruction to obtain the optimized response text; Replace the target response text with the optimized response text to obtain the optimized reply information.

[0116] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0117] It should also be understood that if the above embodiments are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0118] Therefore, this embodiment also provides a storage medium storing a computer program. When the computer program is executed by a processor, it implements the multi-agent bypass management method provided in this embodiment. The storage medium can be any medium capable of storing program code, such as a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0119] This embodiment provides an electronic device that implements a multi-agent bypass management method. For example... Figure 4 As shown, the electronic device may include a processor 22 and a memory 21. The memory 21 stores a computer program, and the processor 22 implements the multi-agent bypass management method provided in this embodiment by reading and executing the computer program in the memory 21 corresponding to the above embodiments.

[0120] See also Figure 4 The electronic device also includes a communication unit 23. The memory 21, processor 22 and communication unit 23 are electrically connected to each other directly or indirectly through system bus 24 to realize data transmission or interaction.

[0121] The memory 21 can be an information recording device based on any electronic, magnetic, optical, or other physical principles, used to record execution instructions, data, etc. In some embodiments, the memory 21 can be, but is not limited to, volatile memory, non-volatile memory, memory drive, etc.

[0122] In some embodiments, the volatile memory may be random access memory (RAM); in some embodiments, the non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, etc.; in some embodiments, the storage drive may be a disk drive, solid-state drive, any type of storage disk (such as optical disc, DVD, etc.), or similar storage media, or a combination thereof.

[0123] The communication unit 23 is used to send and receive data over a network. In some embodiments, the network may include a wired network, a wireless network, a fiber optic network, a telecommunications network, an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a public switched telephone network (PSTN), a Bluetooth network, a ZigBee network, or a near field communication (NFC) network, or any combination thereof. In some embodiments, the network may include one or more network access points. For example, the network may include wired or wireless network access points, such as base stations and / or network switching nodes, through which one or more components of the service request processing system can connect to the network to exchange data and / or information.

[0124] The processor 22 may be an integrated circuit chip with signal processing capabilities, and the processor 22 may include one or more processing cores (e.g., a single-core processor or a multi-core processor). By way of example only, the processor 22 may include a Central Processing Unit (CPU), an Application-Specific Integrated Circuit (ASIC), an Application-Specific Instruction-set Processor (ASIP), a Graphics Processing Unit (GPU), a Physics Processing Unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computing (RISC) computer, or a microprocessor, or any combination thereof.

[0125] Understandable. Figure 4The structure shown is for illustrative purposes only. Electronic devices may also have more advanced features. Figure 4 Showing more or fewer components, or having with Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof.

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

[0127] The above descriptions are merely various embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A multi-agent bypass management method, characterized in that, The target task is broken down into multiple subtasks, and task agents are configured for each of the subtasks. The method includes: Obtain the latest response information of the target agent to the user and the historical dialogue information between the target agent and the user, wherein the latest response information includes the actual invocation instructions for other task agents, and the target agent is one of the multiple task agents; Obtain the current historical call chain, wherein the historical call chain records the task agents that have been called and the call relationships; The historical dialogue information, the latest response information, and the historical call chain are processed using a pre-trained side-channel supervision model to obtain the verification result of the actual call instruction. The model parameters of the side-channel supervision model are smaller than the parameters of the model used by each task agent. If the verification result indicates that the actual invocation instruction is incorrect, then control the target agent to take the correct target invocation instruction.

2. The multi-agent bypass management method according to claim 1, characterized in that, The verification result includes intervention instructions in text form, controlling the target agent to take the correct target invocation instructions, including: Obtain the input information from the user for the next round of dialogue with the target agent; The intervention instruction is appended to the input information to obtain the input information after intervention; The intervention-related input information is input into the target agent so that the target agent can take the target invocation instruction in the next round of dialogue with the user.

3. The multi-agent bypass management method according to claim 2, characterized in that, The input information includes the system prompts from the target agent and the prompts entered by the user in the next round of dialogue; The intervention instruction is appended to the input information to obtain the post-intervention input information, including: The intervention instruction is appended to the system prompt or the prompt message to obtain the input information after the intervention.

4. The multi-agent bypass management method according to claim 1, characterized in that, The verification result includes intervention instructions in text form, controlling the target agent to take the target invocation instructions, including: Generate the target invocation instruction based on the intervention instruction; The target invocation instruction is used to replace the actual invocation instruction in the latest response information, so that the target agent executes the target invocation instruction.

5. The multi-agent bypass management method according to claim 1, characterized in that, The latest response information also includes the target response text provided to the user, and the latest response information from the target agent to the user, including: Obtain the original response information generated by the target agent responding user, wherein the original response information includes the original response text; Extract the original response text from the original response information; If the original response text contains sensitive information, the sensitive information in the original response text is adjusted to obtain the target response text.

6. The multi-agent bypass management method according to claim 5, characterized in that, The latest response information also includes the user's intent recognition result, and the method further includes: Obtain the proxy summary of the target proxy; The intent recognition result and the agent summary are added as prior information to the context of the task agent invoked by the target invocation instruction.

7. The multi-agent bypass management method according to claim 1, characterized in that, The method further includes: Based on the historical dialogue information, the language style description information of the target agent is obtained; The language style description information is added as constraint information to the context of the task agent invoked by the target invocation instruction.

8. The multi-agent bypass management method according to claim 1, characterized in that, The latest response information also includes the target response text provided to the user, and the method further includes: Obtain the semantic similarity between the target response text and the target invocation instruction; If the semantic similarity is less than the threshold, the target response text is adjusted according to the target invocation instruction to obtain the optimized response text; The optimized response text is used to replace the target response text to obtain the optimized reply information.

9. A multi-agent bypass management device, characterized in that, The target task is broken down into multiple subtasks, and a task agent is configured for each of the multiple subtasks. The device includes: The current agent module is used to obtain the latest response information of the target agent to the user and the historical dialogue information between the target agent and the user. The latest response information includes the actual invocation instructions for other task agents, and the target agent is one of the multiple task agents. The proxy supervision module is used to obtain the current historical call chain, wherein the historical call chain records the task proxies that have been called and the call relationships; The proxy supervision module is also used to obtain the current historical call chain, wherein the historical call chain records the task proxies that have been called and the call relationships; The historical dialogue information, the latest response information, and the historical call chain are processed using a pre-trained side-channel supervision model to obtain the verification result of the actual call instruction. The model parameters of the side-channel supervision model are smaller than the parameters of the model used by each task agent. The proxy monitoring module is further configured to control the target proxy to take the correct target invocation instruction if the verification result indicates that the actual invocation instruction is incorrect.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the multi-agent bypass management method according to any one of claims 1-8.

11. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing a computer program that, when executed by the processor, implements the multi-agent bypass management method according to any one of claims 1-8.

Images