A hybrid routing and context-aware multi-agent cooperative scheduling method and system
Patent Information
- Application Number
- CN202611025730.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-10
- Publication Date
- 2026-10-23
AI Technical Summary
(1)纯规则路由延迟低但无法处理语义变体、维护成本高、业务词汇与代码耦合;
1. 延迟与成本优化:高频请求(如问候语、常用查询)由规则引擎在毫秒级内直接命中,完全避免大语言模型推理接口调用。按实际运行数据估算,半数以上的请求可由规则引擎处理,相比纯大语言模型路由方案降低大量的意图识别延迟和接口调用成本。
Smart Images

Figure CN122963719A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of multi-agent cooperative technology, and in particular to a multi-agent cooperative scheduling method and system that combines hybrid routing and context awareness. Background Technology
[0002] With the rapid development of large language models, the "gateway-orchestrator" architecture, which integrates multiple vertical domain agents into a single large model, has become an important direction. After a gateway service receives a user request, it needs to determine which business agent (e.g., meeting control agent, workflow building agent, code generation agent, etc.) should be routed to.
[0003] The existing technology has the following limitations: (1) Pure rule-based routing has low latency but cannot handle semantic variations, has high maintenance costs, and is coupled with business terms and code; (2) Pure large language models have strong routing semantic capabilities but high latency, high cost, and no deterministic gating; (3) The large language model priority strategy of the hybrid scheme results in unnecessary large language model call overhead for high-frequency simple requests; (4) Existing solutions lack effective context-aware degradation strategies when intent is ambiguous; (5) When the session identifier is unstable, the context of multi-turn dialogue is lost, resulting in interruption of business continuity. Summary of the Invention
[0004] The technical problem to be solved by this invention is to provide a multi-agent collaborative scheduling method and system with hybrid routing and context awareness. By constructing a hierarchical hybrid routing architecture of "rule priority, large language model as a backup, and multi-location context awareness fallback", it can achieve low-latency and low-cost routing for high-frequency simple requests, high-accuracy intent recognition for semantically complex requests, and maintain business continuity of multi-turn dialogues in deployment environments with unstable session identifiers.
[0005] In a first aspect, the present invention provides a hybrid routing and context-aware multi-agent cooperative scheduling method, comprising: Request processing: Obtain the user request and extract the message and session identifier; The rule engine matching process is as follows: a three-level cascaded sequential matching is performed through a declarative rule engine, and the first matching is executed to return the strategy; if a rule is matched, an intent structure is constructed from that rule and the decision matrix judgment process is entered; if no rule is matched, the context-aware backtracking routing process is entered. Context-aware fallback routing process: Triggering context-aware fallback routing first performs a one-stage follow message detection. If the first stage is not triggered or is not hit, the second stage of session persistence detection is performed. If either stage is hit, it is distributed to the target active agent. If the second stage is still not hit, the large language model intent classification interface is called to output the intent structure. Decision matrix determination process: The intent structure is fed into the decision matrix for multi-priority item-by-item determination, and the corresponding routing action type is output. When the output routing action type is backtracking, a three-stage classifier backtracking is performed through context-aware backtracking. If the hit is successful, it is distributed to the target active agent; otherwise, it backtracks to the general dialogue agent.
[0006] Furthermore, the three-level cascaded sequential matching includes exact matching, inclusion matching, and regular expression matching, and the matching keywords, intent tags, and target agent mappings related to the business domain are all defined in the declarative configuration file.
[0007] Furthermore, the first-stage follow-up message detection implements differentiated processing based on signal strength: strong signals trigger cross-session global search, while weak signals only perform precise matching within the same session.
[0008] Furthermore, the multiple priority order determinations include danger confirmation check, abnormal injection detection, confidence gating, domain range check, special intent processing, agent whitelist verification, and normal distribution.
[0009] Furthermore, the danger confirmation check specifically includes a two-round interactive process for danger confirmation. The first round is to initiate a dangerous operation, which includes: first checking whether the danger level field in the intent structure is a predefined high-risk identifier; if so, generating a danger operation confirmation prompt text, and storing the current intent structure, target agent identifier, and identity token information in a danger confirmation cache with time constraints, and returning a confirmation prompt text to the user; the second round is for user confirmation execution, which includes: obtaining the confirmation message sent by the user, matching a predefined set of confirmation keywords, and if a confirmation keyword is matched, retrieving the stored intent structure from the danger confirmation cache, verifying the validity of the identity token, and then distributing it to the original target business agent with a confirmation flag.
[0010] Secondly, the present invention provides a hybrid routing and context-aware multi-agent cooperative scheduling system, comprising: The declarative rule engine module is used to store and execute business-independent intent matching rules. It performs matching on each rule in the rule list in a three-level cascading order, and adopts a strategy of returning the first match. The agent context cache module is used to maintain the mapping relationship between session association identifiers and active agent identifiers in a key-value dictionary structure, and provides time-constrained writing, precise query, cross-session global search and expiration cleanup functions; The Large Language Model Intent Classifier interface is only called when the declarative rule engine module misses the target, and outputs structured intent information including intent label, target agent identifier, confidence score, and domain range judgment. The decision matrix module is used to receive the intent structure, perform multiple priority-order judgments, and output the corresponding routing action type. The context-aware fallback routing module is used when multiple pipeline fallback decision points are invoked. It adopts a cross-session matching strategy that differentiates between strong and weak signals, and uses a large language model intent classifier as a fallback when the decision matrix module makes a fallback call.
[0011] Furthermore, it also includes a pipeline orchestration module, which coordinates the execution of each module in a preset order and branch logic to form a complete request processing pipeline.
[0012] Furthermore, in the declarative rule engine module, the three-level cascading sequence matching includes exact matching, inclusion matching, and regular expression matching. The matching keywords, intent tags, and target agent mappings related to the business domain are all defined in the declarative configuration file.
[0013] Furthermore, the decision matrix module is used to sequentially perform danger confirmation checks, anomaly injection detection, confidence gating, domain range checks, special intent processing, agent whitelist verification, and normal distribution.
[0014] Furthermore, the danger confirmation check calls the danger confirmation module to manage the confirmation or cancellation status of dangerous operations, thereby realizing a two-round interactive mechanism for danger confirmation.
[0015] The technical solutions provided in the embodiments of the present invention have at least the following technical effects: 1. Latency and Cost Optimization: High-frequency requests (such as greetings and frequently used queries) are directly matched by the rule engine within milliseconds, completely avoiding API calls from the large language model inference interface. Based on actual operational data, it is estimated that more than half of the requests can be handled by the rule engine, significantly reducing intent recognition latency and API call costs compared to pure large language model routing solutions.
[0016] 2. Multi-turn dialogue continuity: In deployment environments where session identifiers are unstable, business continuity for multi-turn dialogues is maintained through cross-session context-aware fallback routes.
[0017] 3. Degradation Reliability: A four-level degradation strategy (rule engine hit → following message context matching → continuous session context matching → large language model intent classifier fallback) ensures that the system has reasonable fallback behavior under any abnormal conditions.
[0018] 4. Business independence: All business domain-related matching keywords, intent tags, and target agent mappings are defined in a declarative configuration file, which is completely decoupled from the routing processing code; different business scenarios can be adapted by changing the rule configuration file without modifying or redeploying the routing logic code.
[0019] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description
[0020] The present invention will be further described below with reference to the accompanying drawings and embodiments.
[0021] Figure 1 This is a schematic diagram of the system framework of the present invention; Figure 2 This is a flowchart illustrating the overall process of the method in Embodiment 1 of the present invention. Figure 3 This is a flowchart illustrating the execution of the method in Embodiment 1 of the present invention; Figure 4 This is a flowchart of the three-level matching process of the rule engine in Embodiment 1 of the present invention; Figure 5 This is a flowchart of the context-aware fallback routing in Embodiment 1 of the present invention; Figure 6 This is a flowchart of the decision matrix determination process in Embodiment 1 of the present invention; Figure 7 This is a flowchart of the two-round interaction process for hazard confirmation in Embodiment 1 of the present invention; Figure 8 This is a schematic diagram of the system architecture in Embodiment 2 of the present invention. Detailed Implementation
[0022] This invention provides a hybrid routing and context-aware multi-agent collaborative scheduling method and system. By constructing a hierarchical hybrid routing architecture of "rule priority, large language model as a backup, and multi-location context-aware fallback", it achieves low-latency and low-cost routing for high-frequency simple requests, high-accuracy intent recognition for semantically complex requests, and maintains business continuity for multi-turn dialogues in deployment environments with unstable session identifiers.
[0023] The overall concept of the technical solutions in the embodiments of the present invention is as follows: The core idea is to construct a layered hybrid routing architecture that prioritizes rules, uses a large language model as a fallback, and employs multi-location context-aware fallback. Upon receiving a user request, a declarative rule engine first matches the user message in a three-tiered cascading order of exact matching, inclusion matching, and regular expression matching, achieving fast routing with a rule-first approach. Only when the rule engine fails to match the request is the large language model intent classifier invoked for semantic fallback. Regardless of whether the intent information originates from the rule engine or the large language model classifier, a unified decision matrix is input, and judgments are executed according to seven priority items: danger confirmation, injection detection, confidence gating, domain-wide checks, special intent handling, and whitelist verification. When the rule engine fails to match the request, the large language model classifier malfunctions or has low confidence, or when the decision matrix falls back, cross-session context-aware fallback routing maintains business continuity across multiple rounds of dialogue, employing a differentiated cross-session matching strategy for strong and weak signals and a greeting isolation mechanism.
[0024] Thus, in multi-agent cooperative scheduling scenarios, the following can be achieved simultaneously: (1) Low-latency, low-cost routing for high-frequency, simple requests; (2) High-accuracy intent recognition for semantically complex requests; (3) Maintain business continuity of multi-turn dialogues in deployment environments where session identifiers are unstable.
[0025] Before introducing specific embodiments, the system framework corresponding to the method in the embodiments of this application will be introduced first, such as... Figure 1 As shown, the system includes the following seven functional modules, all of which are located in the gateway proxy layer: (1) Declarative rule engine module: Stores and executes business-independent intent matching rules, and performs matching on each rule in the rule list in a three-level cascading order of exact matching, inclusion matching and regular expression matching, and adopts the strategy of returning the first match; (2) Agent context cache module: Maintains the mapping relationship between session association identifier and active agent identifier in key-value dictionary structure, and provides time-constrained writing, precise query, cross-session global search and expiration cleanup functions; (3) Large Language Model Intent Classifier Interface: It is only called when the rule engine fails to hit the target, and outputs structured intent information containing intent label, target agent identifier, confidence score and domain range judgment. (4) Decision Matrix Module: Receives the intent structure, judges each of the seven priority items in the following order: danger confirmation check (D1), anomaly injection detection (D2), confidence gating (D3), domain range check (D4), special intent processing (D5), agent whitelist verification (D6), and normal distribution (D7), and outputs four types of routing actions (direct reply, rejection, fallback, and distribution). (5) Context-aware rollback routing module: When called at multiple pipeline rollback decision points, it adopts a cross-session matching strategy that differentiates between strong and weak signals; (6) Hazard Confirmation Module: Manages the confirmation or cancellation status of hazardous operations and implements a two-round interactive confirmation mechanism; (7) Pipeline orchestration module: coordinates the execution of the above modules in a preset order and branch logic to form a complete request processing pipeline.
[0026] Figure 1 In the system, the overall architecture includes: client layer (1) → gateway proxy layer (2 pipeline orchestration module, 3 declarative rule engine module, 4 agent context cache module, 5 danger confirmation module, 6 decision matrix module, 7 language model intent classifier interface, 8 context-aware fallback routing module) → multi-agent runtime layer (9 general dialogue agent, 10 intent enhancement agent, 11-13 various business agents). Example 1
[0027] This embodiment provides a hybrid routing and context-aware multi-agent cooperative scheduling method, such as... Figure 2 As shown, including; Request processing: Obtain the user request and extract the message and session identifier; The rule engine matching process is as follows: a three-level cascaded sequential matching is performed through a declarative rule engine, and the first matching is executed to return the strategy; if a rule is matched, an intent structure is constructed from that rule and the decision matrix judgment process is entered; if no rule is matched, the context-aware backtracking routing process is entered. Context-aware fallback routing process: Triggering context-aware fallback routing first performs a one-stage follow message detection. If the first stage is not triggered or is not hit, the second stage of session persistence detection is performed. If either stage is hit, it is distributed to the target active agent. If the second stage is still not hit, the large language model intent classification interface is called to output the intent structure. Decision matrix determination process: The intent structure is fed into the decision matrix for multi-priority item-by-item determination, and the corresponding routing action type is output. When the output routing action type is back off, a three-stage classifier back-off is performed through context-aware back-off routing (using a large language model as a fallback). If it hits, it is distributed to the target active agent; if it misses, it back-offs to the general dialogue agent.
[0028] The layered hybrid routing strategy of "rule priority, with large language model as a backup" enables high-frequency simple requests to be directly hit by the rule engine within milliseconds, without the need to call the large language model.
[0029] In one specific embodiment, the execution flow is as follows: Figure 3As shown: S1 Receive user request, extract message and session identifier → S2 Declarative rule engine three-level cascade matching → If a match is found, proceed to S4 Decision matrix determination; if no match is found, proceed to S6 Context-aware fallback routing (including P1 follow message detection and P2 session persistence detection) → S3 Large language model intent classifier → S4 Decision matrix seven-item priority determination → S5 Distribute to target business agent / fall back to general dialogue agent.
[0030] In one specific embodiment, the rule engine matching process includes a three-level cascading sequential matching process: exact matching, inclusion matching, and regular expression matching, employing a first-match-and-return strategy. Business domain-related matching keywords, intent tags, and target agent mappings are all defined in a declarative configuration file, completely decoupling rule definitions from routing code.
[0031] The three-level matching process of the rule engine is as follows: Figure 4 As shown, after the user enters a message, it sequentially goes through level one "exact match", level two "containment match", and level three "regular expression match". If any level matches successfully, the matched rule object is returned immediately; if none of the three levels match, an empty value is returned to proceed to the next step.
[0032] The following shows the declarative definitions of some rules in the declarative rule configuration file, which reflects the design principle of completely decoupling business vocabulary from routing logic—all business domain-related keywords, intent labels, and target agent mappings are declared in the configuration file, and the routing processing code does not contain any hard-coded business vocabulary.
[0033]
[0034] In one specific embodiment, the context-aware fallback routing process is as follows: Figure 5 As shown, there are three decision points: P1 (follow-up message detection), P2 (conversation persistence detection), and P3 (classifier rollback). P1 and P2 enter from entry point A when the decision matrix fails to detect a match, while P3 enters from entry point B when the large language model is abnormal or the decision matrix rollback occurs.
[0035] Decision point P1 (follow-up message detection phase): The pipeline calls the follow-up message detection component. This component first performs token prefix stripping preprocessing on the user message (removing authentication token prefix information), and then uses pre-compiled regular expressions to perform line-first anchor matching on the payload message. If the match is successful (e.g., the message "confirm" matches confirmation-related keywords), it is determined to be a strong signal. The pipeline then calls the context cache module to check the cache record corresponding to the current session association identifier while holding the lock: if there is an exact match, the target agent is returned directly; if there is no match but it is a strong signal, a cross-session global search is triggered—traversing all non-expired entries, selecting the record with the largest timestamp (e.g., business agent A corresponding to another session), outputting the cross-session matching log, and returning the agent identifier.
[0036] Decision point P2 (continuous session context detection phase): When no dispatch has occurred at position P1, the pipeline calls the session query interface in the context cache, checking only whether the main session key matches exactly, without relying on the results of follow-up message detection. If a match is found, the target agent identifier is returned. This position is used to overwrite long text continuation messages.
[0037] Decision point P3 (Large Language Model Classifier Backoff Decision Point): When the large language model intent classifier calls an exception or the decision matrix outputs a backoff action, the pipeline calls the global context backoff function. This function first retrieves the latest timestamp of the active agent record from the context cache; then it checks the backoff reason identifier—if it is the "greeting-only" identifier, it skips the context backoff and directly returns a null value to trigger the backoff for the general dialogue agent; if it is for other reasons (such as "low confidence" or "outside the domain"), it further verifies the authentication token requirement of the target agent. After the token verification is successful, it constructs a context backoff intent structure with a confidence of 0.70 and returns it.
[0038] Entry point A (P1+P2): Executed before the large language model classifier after a rule engine miss, aiming to skip unnecessary LLM calls. Entry point B (P3): Executed after a large language model exception or decision matrix rollback: includes greeting isolation and token verification. Both entry points share a common intelligent context caching module. P1 follows message detection and determines differentiated processing based on signal strength: strong signals (confirmation / rejection / execution keywords) trigger a cross-session global search, while weak signals (short messages) only perform exact matching within the same session, avoiding cross-session misrouting.
[0039] Suppose that there are two sessions in the system at the same time: (a) User A in session A is having a workflow building conversation with business intelligence agent A, and the mapping relationship between session A and business intelligence agent A is recorded in the intelligence agent context cache; (b) User B in session B initiates a new request and sends the message "hello".
[0040] Traditional solutions have the following risks in this scenario: if cross-conversation context search is executed unconditionally, the search may be routed to the most active business intelligence agent A in session A—that is, user B says "hello" but receives workflow building guidance from business intelligence agent A instead of a normal greeting reply from a general dialogue intelligence agent.
[0041] This invention avoids the above problems through two mechanisms. First, weak signals only trigger exact matching within the same session, without performing a cross-session global search—therefore, "Hello" from session B will not cross over into the business agent context of session A. Second, even if "Hello" is matched by the greeting rules of the rule engine, and the intent label in the constructed intent structure is of the greeting type, the decision matrix outputs a fallback action with a greeting-specific reason identifier after detecting this label in step D5; at the subsequent fallback decision point (position P3), the context-aware fallback routing function skips context fallback processing after checking the greeting-specific reason identifier, ensuring that the request is directly routed to the general dialogue agent.
[0042] In deployment environments where session identifiers are unstable, cross-session context-aware fallback routing maintains the mapping relationship between sessions and active agents through agent context caching and performs context-aware fallback at multiple pipeline locations.
[0043] The agent context cache is maintained in memory as a key-value dictionary structure, where the key is the session association identifier and the value is a record object containing a target agent identifier field and a timestamp field. The data structure is equipped with a thread lock to ensure safe concurrent access. The default expiration time of the cache is 300 seconds. Each time a request is successfully dispatched to the business agent and a valid response is received, the system writes or updates the identifier of the most recently active agent in that session and the current timestamp, using the current session association identifier as the key. When accessing the cache, all key-value pairs in the dictionary are first traversed. The timestamp field of each record is compared with the current time. If the difference exceeds the preset expiration time, the entry is deleted from the dictionary before the query or update operation is performed.
[0044] The table below compares the routing accuracy of the traditional solution (without context awareness) and the solution of this invention for four typical subsequent message types in a deployment environment with unstable session identifiers. Data was collected from actual system operation logs.
[0045]
[0046] In one specific embodiment, the decision matrix performs seven priority checks sequentially, including danger confirmation check, anomaly injection detection, confidence gating, domain range check, special intent handling, agent whitelist verification, and normal distribution. Figure 6As shown, starting from the "Input Intent Structure", it sequentially goes through D1 danger confirmation check, D2 abnormal injection detection, D3 confidence gating, D4 domain range check, D5 special intent processing, D6 whitelist verification, and finally reaches D7 normal distribution, outputting one of the four routing action types (direct reply, rejection, rollback, distribution).
[0047] D1 Danger Confirmation Check: Checks whether the danger level field in the intent structure is a predefined high-risk identifier; if so, it returns a routing result object with the routing action type "direct reply" and the reason "danger confirmation". Its message field contains a dangerous operation confirmation prompt text, prompting the user to reply with a confirmation keyword to continue execution.
[0048] D2 Anomaly Injection Detection: Checks whether the confidence field in the intent structure is equal to 0.0 and whether the intent label field is "unknown"; if both conditions are met, it returns a route result object with the route action type "reject" and the reason "anomaly injection".
[0049] D3 Confidence Gating: Checks whether the confidence value in the intent structure is less than the preset confidence threshold (0.8 in this embodiment); if so, it returns a routing result object with the routing action type "back" and the reason "low confidence"; this back action does not directly back to the general dialogue agent, but allows subsequent context-aware back routing steps to take over the processing.
[0050] D4 Intra-Domain Scope Check: Checks if the intra-domain scope judgment field in the intent structure is false; if so, it returns a route result object with the route action type "backoff" and the reason "outtra-domain", which also allows context-aware backoff takeover.
[0051] D5 Special Intent Processing: Checks whether the intent label field in the intent structure belongs to the predefined set of special intent types; if it is a greeting type, it returns a routing result object with the routing action type "back" and the reason "greeting-specific". This special reason identifier is used to notify the subsequent context backoff function to skip processing; if it is a token missing type, it returns a routing result object with the routing action type "direct reply", whose message field contains authentication prompt text; it outputs a greeting-specific reason identifier through special intent processing. The context backoff function skips processing after checking this identifier, ensuring that the greeting directly backs to the general dialogue agent.
[0052] D6 Whitelist Validation: Checks if the target agent identifier field in the intent structure exists in the pre-configured agent whitelist set; if it does not exist, it returns a routing result object with the routing action type "Reject" and the reason "Module does not support".
[0053] D7 Normal Distribution: If none of steps D1 to D6 are triggered, a routing result object with the routing action type "Distribution" is returned, and its target agent identifier field is the target agent identifier value in the intent structure.
[0054] By using a unified seven-priority decision matrix (D1-D7), regardless of whether the intent information comes from a rule engine or a large language model classifier, the same decision matrix is input to perform the judgment and output a standardized routing action.
[0055] Preferably, the D1 hazard confirmation check can specifically include a two-round interactive process for hazard confirmation. Round 1: User initiates a hazard operation → Rule engine hits a high-risk rule → Decision matrix triggers hazard confirmation → Confirmation information is stored in the cache → Confirmation prompt is returned. Round 2: User replies with confirmation keywords → Hazard confirmation cache is retrieved first → After verification, the original operation is distributed and executed.
[0056] like Figure 7 As shown, the first round of initiating a dangerous operation includes: firstly checking whether the danger level field in the intent structure is a predefined high-risk identifier; if so, generating a dangerous operation confirmation prompt text, and storing the current intent structure, target agent identifier, and identity token information in a time-constrained danger confirmation cache, and returning a confirmation prompt text to the user; the second round of user confirmation execution includes: obtaining the confirmation message sent by the user, matching it against a predefined set of confirmation keywords; if a confirmation keyword is matched, retrieving the stored intent structure from the danger confirmation cache, verifying the validity of the identity token, and then distributing it to the original target business agent with a confirmation flag.
[0057] Based on the same inventive concept, this application also provides a system corresponding to the method in Embodiment 1, as detailed in Embodiment 2. Example 2
[0058] This embodiment provides a hybrid routing and context-aware multi-agent cooperative scheduling system, such as... Figure 8 As shown, it includes: The declarative rule engine module is used to store and execute business-independent intent matching rules. It performs matching on each rule in the rule list in a three-level cascading order, and adopts a strategy of returning the first match. The agent context cache module is used to maintain the mapping relationship between session association identifiers and active agent identifiers in a key-value dictionary structure, and provides time-constrained writing, precise query, cross-session global search and expiration cleanup functions; The Large Language Model Intent Classifier interface is only called when the declarative rule engine module misses the target, and outputs structured intent information including intent label, target agent identifier, confidence score, and domain range judgment. The decision matrix module is used to receive the intent structure, perform multiple priority-order judgments, and output the corresponding routing action type. The context-aware fallback routing module is used when multiple pipeline fallback decision points are invoked. It adopts a cross-session matching strategy that differentiates between strong and weak signals, and uses a large language model intent classifier as a fallback when the decision matrix module makes a fallback call.
[0059] In one specific embodiment, it further includes: a pipeline orchestration module, used to coordinate the execution of each module in a preset order and branch logic to form a complete request processing pipeline.
[0060] In one specific embodiment, the declarative rule engine module includes three-level cascading sequence matching, which includes exact matching, inclusion matching, and regular expression matching. The matching keywords, intent tags, and target agent mappings related to the business domain are all defined in the declarative configuration file.
[0061] In one specific embodiment, the decision matrix module is used to sequentially perform danger confirmation checks, anomaly injection detection, confidence gating, domain range checks, special intent processing, agent whitelist verification, and normal distribution.
[0062] In one specific embodiment, the danger confirmation check calls the danger confirmation module to manage the confirmation or cancellation status of dangerous operations, thereby realizing a two-round interactive mechanism for danger confirmation.
[0063] like Figure 1 As shown, all of the above modules operate at the gateway proxy layer.
[0064] Since the system described in Embodiment 2 of this invention is a system used to implement the method of Embodiment 1 of this invention, those skilled in the art can understand the specific structure and variations of this system based on the method described in Embodiment 1 of this invention, and therefore will not be repeated here. All systems used in the method of Embodiment 1 of this invention fall within the scope of protection of this invention.
[0065] The technical solutions provided in the embodiments of the present invention have at least the following technical effects: 1. Latency and Cost Optimization: High-frequency requests (such as greetings and frequently used queries) are directly matched by the rule engine within milliseconds, completely avoiding API calls from the large language model inference interface. Based on actual operational data, it is estimated that more than half of the requests can be handled by the rule engine, significantly reducing intent recognition latency and API call costs compared to pure large language model routing solutions.
[0066] 2. Multi-turn dialogue continuity: In deployment environments where session identifiers are unstable, business continuity for multi-turn dialogues is maintained through cross-session context-aware fallback routes.
[0067] 3. Degradation Reliability: A four-level degradation strategy (rule engine hit → following message context matching → continuous session context matching → large language model intent classifier fallback) ensures that the system has reasonable fallback behavior under any abnormal conditions.
[0068] 4. Business independence: All business domain-related matching keywords, intent tags, and target agent mappings are defined in a declarative configuration file, which is completely decoupled from the routing processing code; different business scenarios can be adapted by changing the rule configuration file without modifying or redeploying the routing logic code.
[0069] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0070] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0071] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0072] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The steps of the function specified in one or more boxes.
[0073] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.
Claims
1. A hybrid routing and context-aware multi-agent cooperative scheduling method, characterized in that, include: Request processing: Obtain the user request and extract the message and session identifier; The rule engine matching process involves a three-level cascading sequential matching process using a declarative rule engine, with the first match executed and the strategy returned. If a rule is matched, an intent structure is constructed based on that rule, and the decision matrix determination process begins; if no rule is matched, the context-aware backtracking process begins. Context-aware fallback routing process: Triggering context-aware fallback routing first performs a one-stage follow message detection. If the first stage is not triggered or is not hit, the second stage of session persistence detection is performed. If either stage is hit, it is distributed to the target active agent. If the second stage is still not hit, the large language model intent classification interface is called to output the intent structure. Decision matrix determination process: The intent structure is fed into the decision matrix for multiple priority items to be determined one by one, and the corresponding routing action type is output; when the output routing action type is back off, the three-stage classifier back-off is performed through context-aware back-off routing. If a match is found, the message is sent to the target active agent; otherwise, it is reverted to the general dialogue agent.
2. The method according to claim 1, characterized in that: The three-level cascaded sequential matching includes exact matching, inclusion matching, and regular expression matching. The matching keywords, intent tags, and target intelligent agent mappings related to the business domain are all defined in the declarative configuration file.
3. The method according to claim 1, characterized in that: The first-stage follow message detection implements differentiated processing based on signal strength: strong signals trigger a cross-session global search, while weak signals only perform precise matching within the same session.
4. The method according to claim 1, characterized in that: The multiple priority items are determined sequentially, including danger confirmation check, abnormal injection detection, confidence gating, domain range check, special intent handling, agent whitelist verification, and normal distribution.
5. The method according to claim 4, characterized in that: The danger confirmation check specifically includes a two-round interactive process. The first round is to initiate a dangerous operation, which includes: firstly checking whether the danger level field in the intent structure is a predefined high-risk identifier; if so, generating a danger operation confirmation prompt text, and storing the current intent structure, target agent identifier, and identity token information in a danger confirmation cache with time constraints, and returning a confirmation prompt text to the user; the second round is for user confirmation execution, which includes: obtaining the confirmation message sent by the user, matching it with a predefined set of confirmation keywords; if a confirmation keyword is matched, retrieving the stored intent structure from the danger confirmation cache, verifying the validity of the identity token, and then distributing it to the original target business agent with a confirmation flag.
6. A hybrid routing and context-aware multi-agent cooperative scheduling system, characterized in that, include: The declarative rule engine module is used to store and execute business-independent intent matching rules. It performs matching on each rule in the rule list in a three-level cascading order, and adopts a strategy of returning the first match. The agent context cache module is used to maintain the mapping relationship between session association identifiers and active agent identifiers in a key-value dictionary structure, and provides time-constrained writing, precise query, cross-session global search and expiration cleanup functions; The Large Language Model Intent Classifier interface is only called when the declarative rule engine module misses the target, and outputs structured intent information including intent label, target agent identifier, confidence score, and domain range judgment. The decision matrix module is used to receive the intent structure, perform multiple priority-order judgments, and output the corresponding routing action type. The context-aware fallback routing module is used when multiple pipeline fallback decision points are invoked. It adopts a cross-session matching strategy that differentiates between strong and weak signals, and uses a large language model intent classifier as a fallback when the decision matrix module makes a fallback call.
7. The system according to claim 6, characterized in that, Also includes: The pipeline orchestration module is used to coordinate the execution of each module in a preset order and branch logic to form a complete request processing pipeline.
8. The system according to claim 6, characterized in that: In the declarative rule engine module, the three-level cascading sequence matching includes exact matching, inclusion matching, and regular expression matching. The matching keywords, intent tags, and target agent mappings related to the business domain are all defined in the declarative configuration file.
9. The system according to claim 6, characterized in that: The decision matrix module is used to sequentially perform danger confirmation checks, anomaly injection detection, confidence gating, domain range checks, special intent processing, agent whitelist verification, and normal distribution.
10. The system according to claim 9, characterized in that: The danger confirmation check calls the danger confirmation module, which manages the confirmation or cancellation status of dangerous operations, and implements a two-round interactive mechanism for danger confirmation.