Marketing data processing method based on multi-agent cooperation and related equipment

Abstract

The application discloses a marketing data processing method and related equipment based on multi-agent cooperation, which can be applied to the field of artificial intelligence technology. After obtaining the user request and the social customer relationship management message, the application performs intention recognition and business opportunity analysis, and then outputs target intention type and business opportunity label information, so as to effectively identify marketing business opportunities. Then, the target intention type and the business opportunity label information are used to determine a candidate agent instance list and a corresponding selection weight, to determine an execution agent instance, to generate a routing decision according to the target intention type, to select a target execution mode of the current agent according to the current application scene and the routing decision, to call the execution agent instance according to the target execution mode, to route the user request to the execution agent instance, and to execute the current workflow corresponding to the social customer relationship management message through the execution agent instance, so as to effectively improve the flexibility of workflow arrangement.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a marketing data processing method and related equipment based on multi-agent collaboration. Background Technology

[0002] In related technologies, intelligent customer service and marketing systems based on Large Language Models (LLMs) have been widely used in the enterprise service field. However, current enterprise-level AI marketing systems, due to their use of single AI solutions, fixed process orchestration schemes, and rule-based expert systems, are unsuitable for complex marketing scenarios. While multi-agent collaboration, intent recognition, and workflow automation have been applied, their application in enterprise-level marketing scenarios fails to effectively identify user intent and related business opportunities. Consequently, they cannot tailor processing strategies and resource matching based on business opportunity intents in marketing scenarios. Furthermore, the uniform heavy-duty processing mode for all user messages can lead to wasted computing resources on low-value messages, resulting in wasted resources and increased response latency. In addition, existing multi-agent methods typically employ hard orchestration, requiring source code modification and system redeployment when new marketing scenarios are introduced, increasing the workload for developers.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0004] The main objective of this application is to propose a marketing data processing method and related equipment based on multi-agent collaboration, which can effectively identify marketing opportunities and improve the flexibility of workflow orchestration.

[0005] To achieve the above objectives, one aspect of this application proposes a marketing data processing system based on multi-agent collaboration, the system comprising: The access layer is used to obtain user requests and social customer relationship management messages, which include user identifier, session identifier, message content and message timestamp; The intent recognition layer is used to perform intent recognition and opportunity analysis on the social customer relationship management message based on a multi-level progressive opportunity recognition method, and then output target intent type and opportunity tag information. The target intent type includes explicit opportunity, potential opportunity, inquiry, or no opportunity; the opportunity tag information includes opportunity level tag. A dynamic routing layer is used to query multiple candidate Agent instances from the Agent registry center based on the target intent type and the business opportunity tag information to form a candidate Agent instance list, determine the selection weight of each candidate Agent instance through a multi-factor scoring method, determine at least one execution Agent instance from the candidate Agent instance list based on the selection weight, and generate a routing decision based on the target intent type. The Agent execution layer is used to select the target execution mode of the current Agent according to the current application scenario and the routing decision. After calling the execution Agent instance according to the target execution mode, the user request is routed to the execution Agent instance so that the current workflow corresponding to the social customer relationship management message can be executed through the execution Agent instance. A data storage layer is used to store the workload template corresponding to the current workflow.

[0006] In some embodiments, the intent recognition layer includes an intent classification engine, which includes an edge filter, a lightweight intent classifier, a conversation aggregator, and a large language model filter. The multi-level progressive opportunity identification method performs intent recognition and opportunity analysis on the social customer relationship management messages, and outputs target intent type and opportunity tag information, including: The social customer relationship management messages are coarsely filtered using the edge filter to obtain the session messages to be processed. The lightweight intent classifier is used to classify the intent of the session message to be processed to obtain the target intent type. The session aggregator performs aggregation analysis on multiple rounds of pending session messages from the same user in the same session context based on the target intent type to obtain target candidate sessions, and calculates the session opportunity confidence of each target candidate session; The target candidate session is semantically analyzed using the large language model filter to determine the business opportunity tag information.

[0007] In some embodiments, the coarse filtering of the social customer relationship management messages to obtain the session messages to be processed includes: The social customer relationship management messages are filtered based on length filtering rules, modal word filtering rules, system message filtering rules, and duplicate message filtering rules to obtain the session messages to be processed.

[0008] In some embodiments, the step of aggregating and analyzing multiple rounds of pending session messages from the same user in the same session context according to the target intent type to obtain target candidate sessions, and calculating the session opportunity confidence of each target candidate session, includes: Based on the sliding window algorithm, the session ownership of the multiple rounds of unprocessed session messages is determined to obtain the session messages within each sliding time window; Calculate the intent strength of all session messages within each sliding time window based on the target intent type, and filter all session messages within each sliding time window based on the intent strength to obtain the target session message within each sliding time window; Based on the time window order, the target session messages within all the sliding time windows are integrated into the context to obtain the target candidate sessions; The session opportunity confidence of the target candidate session is calculated based on multiple factors.

[0009] In some embodiments, the edge filter, the lightweight intent classifier, the conversation aggregator, and the large language model filter all include early stopping conditions; The early stop condition in the edge filter, the lightweight intent classifier, and the session aggregator is used to directly output the target intent type.

[0010] In some embodiments, the target execution mode includes workflow compilation mode or stand-alone service deployment mode; The workflow compilation mode uses JSON format to standardize and declaratively define the current workflow, and uses a three-layer parsing engine to parse and execute the current workflow.

[0011] To achieve the above objectives, another aspect of this application proposes a marketing data processing method based on multi-agent collaboration, the method comprising the following steps: Obtain user requests and social customer relationship management messages, wherein the social customer relationship management messages include user identifier, session identifier, message content, and message timestamp; After performing intent recognition and opportunity analysis on the social customer relationship management messages based on a multi-level progressive opportunity identification method, the target intent type and opportunity tag information are output. The target intent type includes explicit opportunity, potential opportunity, inquiry, or no opportunity; the opportunity tag information includes opportunity level tag. Based on the target intent type and the business opportunity tag information, multiple candidate agent instances are retrieved from the agent registry center to form a candidate agent instance list; The selection weight of each candidate Agent instance is determined using a multi-factor scoring method; At least one execution agent instance is determined from the candidate agent instance list based on the selection weight, and a routing decision is generated based on the target intent type; Select the target execution mode for the current Agent based on the current application scenario and the routing decision; After invoking the execution agent instance according to the target execution mode, the user request is routed to the execution agent instance so that the current workflow corresponding to the social customer relationship management message can be executed through the execution agent instance.

[0012] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0013] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0014] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method.

[0015] The embodiments of this application include at least the following beneficial effects: This application provides a marketing data processing method and related equipment based on multi-Agent collaboration. This solution, by setting up an access layer, an intent recognition layer, and a dynamic routing layer, obtains user requests and social customer relationship management messages at the access layer. Then, the intent recognition layer performs intent recognition and opportunity analysis on the social customer relationship management messages based on a multi-level progressive opportunity recognition method, outputting target intent type and opportunity tag information, thereby effectively identifying marketing opportunities. Finally, the dynamic routing layer queries the Agent registry center based on the target intent type and opportunity tag information to obtain multiple candidate Agent instances, forming candidate Agents. A list of agent instances is generated, and the selection weight of each candidate agent instance is determined through a multi-factor scoring method. Based on the selection weight, at least one execution agent instance is selected from the list of candidate agent instances. A routing decision is generated based on the target intent type. Then, the agent execution layer selects the target execution mode of the current agent according to the current application scenario and the routing decision. After the execution agent instance is invoked according to the target execution mode, the user request is routed to the execution agent instance. The execution agent instance executes the current workflow corresponding to the social customer relationship management message, thereby effectively improving the flexibility of workflow orchestration. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the structure of a marketing data processing system based on multi-agent collaboration provided in an embodiment of this application; Figure 2 This is a flowchart of the four-level progressive business opportunity identification process provided in the embodiments of this application; Figure 3 This is a schematic diagram of multi-Agent dynamic routing processing provided in an embodiment of this application; Figure 4 This is a flowchart of a marketing data processing method based on multi-agent collaboration provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of systems and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0018] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0019] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0021] Before providing a detailed description of the embodiments of this application, some of the nouns and terms used in the embodiments of this application will be explained first. The nouns and terms used in the embodiments of this application shall be interpreted as follows: An agent is an intelligent entity that can autonomously perceive its environment, make decisions, and execute actions. Through a closed-loop mechanism of "perception → reasoning → action," it can achieve specific goals without direct human intervention.

[0022] Among related technologies, multi-agent collaboration, intent recognition, and workflow automation have already been applied. However, the following issues remain when applying them in enterprise-level marketing scenarios: First, there is a confusion between intent recognition and opportunity recognition: Existing intent recognition technologies focus on general intent classification, such as categorizing user messages into queries, complaints, inquiries, and suggestions. However, in marketing scenarios, this coarse-grained intent classification cannot effectively distinguish the essential difference between "clear purchase intention" and "general inquiry." For example, both "How much does your product cost?" and "How is this different from our competitors?" fall under the category of inquiry intent, but the former contains significant purchase signals, while the latter is in the information gathering stage. This results in existing technologies failing to provide refined input for subsequent marketing decisions.

[0023] Second, resource utilization is inefficient: Existing technologies employ a uniform, heavy-duty processing model for all user messages, meaning that regardless of whether a message contains business opportunities, it calls upon a large-scale language model for deep semantic analysis. In enterprise-level SCRM scenarios, among the massive amounts of user messages processed daily, messages truly containing high-value business opportunities typically account for less than 20%. Processing all messages using heavyweight models results in a significant waste of computing resources on low-value messages, causing substantial computational cost waste, increasing system response latency, and negatively impacting user experience.

[0024] Third, rigid workflow orchestration: Existing technologies typically define workflows using hard-coding, resulting in a high degree of coupling between the business process's node definitions, connections, and execution logic and the underlying code. When business requirements change or new marketing scenarios need to be integrated, developers must modify the source code and redeploy the system, making dynamic configuration and hot updates of the workflow impossible. Furthermore, the lack of standardized data exchange interfaces and variable passing mechanisms between workflow nodes leads to low reusability and scalability of the workflow.

[0025] Fourth, there is a lack of conversational opportunity analysis capabilities: existing technologies mainly rely on single messages for intent recognition and classification analysis. However, in actual marketing scenarios, users' purchase intentions are usually revealed gradually through multiple rounds of dialogue, and a single message may only contain weak opportunity signals, causing some potential opportunities to be missed.

[0026] Fifth, the disconnect between dynamic routing and opportunity identification: Existing dynamic routing technologies primarily rely on matching intent tags with agent capabilities to distribute requests. However, in marketing scenarios, messages of different opportunity levels should be matched with different processing strategies and resources. For example, high-opportunity-level messages should be preferentially routed to experienced sales agents or human agents, while low-opportunity-level messages can be processed by automated processes. This disconnect between opportunity identification and dynamic routing in existing technologies prevents the system from selecting the optimal processing path based on opportunity level.

[0027] In view of this, this application provides a marketing data processing method and related equipment based on multi-agent collaboration, which can effectively identify marketing opportunities and improve the flexibility of workflow orchestration.

[0028] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0029] The embodiments of this application will be described in detail below with reference to the accompanying drawings: like Figure 1 As shown, this embodiment provides a marketing data processing system based on multi-agent collaboration. This system includes an access layer, an intent recognition layer, a dynamic routing layer, an agent execution layer, and a data storage layer. The access layer includes an API Gateway module, a unified authentication module, a rate limiting and circuit breaking module, and a load balancing module. The API Gateway module serves as the system's unified entry point, responsible for receiving HTTP / HTTPS requests from external systems such as SCRM systems, web applications, and mobile applications. The unified authentication module implements identity authentication and permission verification based on OAuth 2.0 and permission resource authentication. The rate limiting and circuit breaking module uses a token bucket algorithm to limit the request rate; the default configuration can be set to 1000 requests per second. The load balancing module implements reverse proxy and load balancing based on Nginx.

[0030] The intent recognition layer includes an intent classification engine (chinese-roberta-wwm-ext) and a confidence evaluation module. The intent classification engine can use a pre-trained language model of chinese-roberta-wwm-ext, deployed locally on ONNX Runtime, and the inference latency can be controlled within 50ms. The confidence evaluation module is used to score the confidence of the intent classification results. When the confidence is lower than a preset threshold, a manual review process is triggered or a clarification inquiry is returned.

[0031] The dynamic routing layer comprises an Agent selector, a routing decision engine, and an A2A protocol (Agent-to-Agent Protocol) + Nacos (Dynamic Naming and Configuration Service, a microservice management platform) registry. The Agent selector uses a multi-factor scoring algorithm to choose the most suitable Agent instance from a set of candidate Agents to handle the current request. The routing decision engine implements a routing decision function f(intent type, confidence, context, system load), comprehensively considering multiple factors to generate a routing decision. In this embodiment, the dynamic routing layer uses the A2A protocol standard to implement the Agent registry, with Nacos as the registry storage, achieving standardized Agent registration and dynamic discovery. Specifically, the A2A protocol components include an A2A Server, AgentCard, A2A Registry (based on Nacos), and AgentCardProvider. The A2A Server exposes the local ReactAgent as an A2A service, providing a standardized REST API endpoint; AgentCard is a standardized metadata document describing Agent capabilities, endpoint addresses, authentication information, and input / output schemas; A2A Registry (based on Nacos) stores and manages AgentCard information, supporting automatic Agent registration and subscription discovery; AgentCardProvider dynamically retrieves AgentCards from the registry center, supporting load balancing for Agent calls.

[0032] The Agent execution layer employs a hybrid deployment model. This model includes two modes: workflow compilation and stand-alone service deployment. Workflow compilation is based on declarative workflow definitions, executing complex business processes according to predefined nodes and edges. Stand-alone service deployment is designed for simple logic scenarios, where the Agent runs as an independent service, directly processing requests and returning results.

[0033] The data storage layer includes a relational database (MySQL), a document database (Elasticsearch), a vector database (Milvus), a caching service (Redis), and a message queue (RocketMQ). The relational database (MySQL) stores structured data such as agent definitions, workflow templates, and configuration information; the document database (Elasticsearch) stores unstructured data such as session history and execution logs; the vector database (Milvus) stores vectorized document data, raw file fragments, and metadata—all vectorized unstructured data; the caching service (Redis) implements hot data caching and distributed locks; and the message queue (RocketMQ) implements asynchronous message communication and task queues.

[0034] based on Figure 1 The system architecture shown in this embodiment involves data processing for each layer as follows: The access layer is used to obtain user requests and social customer relationship management messages, which include user identifier, session identifier, message content, and message timestamp; The intent recognition layer is used to perform intent recognition and opportunity analysis on social customer relationship management messages based on a multi-level progressive opportunity recognition method, and then output target intent type and opportunity tag information. The target intent type includes explicit opportunity, potential opportunity, inquiry, or no opportunity; the opportunity tag information includes opportunity level tag. The dynamic routing layer is used to query multiple candidate agent instances from the agent registry based on the target intent type and the business opportunity tag information to form a candidate agent instance list, and to determine the selection weight of each candidate agent instance through a multi-factor scoring method. Based on the selection weight, at least one execution agent instance is determined from the candidate agent instance list, and a routing decision is generated based on the target intent type. The Agent execution layer is used to select the target execution mode of the current Agent based on the current application scenario and routing decision. After calling the execution Agent instance according to the target execution mode, the user request is routed to the execution Agent instance so that the current workflow corresponding to the social customer relationship management message can be executed through the execution Agent instance. The data storage layer is used to store the workload templates corresponding to the current workflow.

[0035] It is understood that the intent classification engine in this embodiment includes an edge filter, a lightweight intent classifier, a conversation aggregator, and a large language model filter. The intent classification engine in this embodiment adopts a funnel-shaped progressive structure, filtering the input message stream step-by-step from coarse-grained to fine-grained, such as... Figure 2As shown, the four processing levels are, in order: Level 1 edge filter, Level 2 lightweight intent classifier, Level 3 session aggregator, and Level 4 LLM fine screening. Specifically, when performing intent recognition based on the intent classification engine structure of this embodiment, this embodiment can use an edge filter to perform coarse screening of the social customer relationship management messages to obtain the session messages to be processed; use a lightweight intent classifier to classify the session messages to be processed to obtain the target intent type; use a session aggregator to perform aggregation analysis on multiple rounds of session messages to be processed from the same user in the same session context according to the target intent type to obtain the target candidate sessions, and calculate the session opportunity confidence of each target candidate session; and use a large language model filter to perform semantic analysis on the target candidate sessions to determine the opportunity tag information.

[0036] Specifically, the Level 1 edge filter in this embodiment is the first processing stage of the four-level progressive opportunity identification method. It receives raw message input (social customer relationship management messages) from the access layer and performs fast rule filtering on the raw messages, eliminating invalid messages that clearly lack commercial value with minimal computational overhead. The edge filter employs four filtering rules executed sequentially. Messages blocked by any rule are output as non-opportunity results through an early-stop channel and do not proceed to subsequent processing levels. The four filtering rules in this embodiment include length filtering, modifier filtering, system message filtering, and duplicate message filtering.

[0037] The length filtering rule in this embodiment is based on the character length of the message text. The judgment condition is: the message length is less than MIN_LENGTH (default value 3) or greater than MAX_LENGTH (default value 5000). These thresholds can be dynamically adjusted through the configuration center. The length calculation uses character count based on UTF-8 encoding. Messages with a length of less than 3 characters are judged as very short messages (such as "OK" or "ok"), and messages with a length of more than 5000 characters are judged as very long messages (such as pasting an entire article). Such messages usually do not contain valid business opportunities. The code logic for length filtering is: if(msg.length<MIN_LENGTH||msg.length> MAX_LENGTH) return FILTERED;, with a time complexity of O(1).

[0038] The interjection filtering rule of this embodiment is used to identify messages whose main content consists of interjections. In this embodiment, an interjection library containing more than 200 commonly used interjections such as "um", "ah", "oh", "haha", and "hehe" is predefined. The judgment condition is: the ratio of the total character length of interjections in the message to the total character length of the message is greater than 70%, or the entire content of the message is composed of interjections. This embodiment adopts a data structure based on a Trie tree (prefix tree) for fast interjection matching. After the interjection library is constructed as a Trie tree index, the input message is matched character by character and the proportion of interjections is counted. The time complexity of Trie tree matching is O(n), where n is the character length of the message, and all detections can be completed with a single linear scan.

[0039] The system message filtering rule of this embodiment is used to identify automatic messages sent by system accounts or matching system message templates. The judgment conditions include two dimensions: first, the account identifier of the message sender matches a preset system account list (such as system assistant, group administrator); second, the message content matches a system message regular template. The regular templates include: ^Welcome.*join the group chat.* matching group joining welcome messages, ^@all.* matching system notifications, .*[System Auto-reply].* matching auto-replies, etc. System messages do not need to undergo business opportunity identification processing.

[0040] The duplicate message filtering rule of this embodiment is used to block screen-scraping or duplicate messages within a short period of time. The judgment condition is: the number of occurrences of identical or highly similar content in the latest N messages is greater than M times, where the sliding window size N=10 and the duplication threshold M=3. This embodiment adopts the SimHash (Locality Sensitive Hashing) algorithm for approximate duplication detection: a 64-bit SimHash fingerprint is calculated for each message, and the text similarity is measured by the Hamming distance. When the Hamming distance is less than or equal to 3, the content is determined to be approximately duplicate. SimHash converts similarity calculation into binary bit operation comparison, with a time complexity of O(1).

[0041] Specifically, after the four rules of this embodiment are executed in a sequential chain manner, the session messages to be processed are obtained. Once any rule is hit in the intermediate process, FILTERED is returned and subsequent checks are terminated. The filtering rate of this level is about 80%, and the average processing delay for a single message is less than 10 milliseconds.

[0042] Specifically, the Level 2 lightweight intent classifier in this embodiment is the second processing stage of the four-level progressive opportunity recognition method. It receives messages remaining after being filtered by the Level 1 edge filter and uses a locally deployed lightweight deep learning classification model to classify the intent of the messages, determining whether they contain opportunity signals and their degree of explicitness. Specifically, the lightweight intent classifier in this embodiment uses chinese-roberta-wwm-ext as the pre-trained language model architecture. This pre-trained language model is based on a Transformer encoder structure, containing 12 Transformer Blocks, a hidden layer dimension of 768, 12 attention heads, and approximately 102 million parameters. A fully connected classification layer (Linear layer) is added on top of the pre-trained language model to map the 768-dimensional [CLS]-labeled hidden states to a 4-dimensional classification output space. The pre-trained language model is deployed using the ONNX Runtime local inference engine, exporting the trained PyTorch model to ONNX format for accelerated inference. ONNX Runtime supports adaptive switching between GPU and CPU: when the inference server is equipped with an NVIDIA GPU and has sufficient video memory, it automatically uses CUDAExecutionProvider for GPU acceleration; otherwise, it switches to CPUExecutionProvider for CPU inference. The inference batch size is set to 32, allowing a maximum of 32 messages to be processed simultaneously per inference iteration to improve throughput.

[0043] The lightweight intent classifier in this embodiment classifies the input session messages into four categories: the first category, EXPLICIT_OPPORTUNITY, refers to messages in which the user explicitly expresses their intention to buy, such as "How to buy", "How much", "I want to place an order", etc., which contain strong purchase signals; the second category, POTENTIAL_OPPORTUNITY, refers to messages in which the user shows interest but no explicit purchase signal, such as "What features does it have?", "How does it compare to XX", etc., which are in the information gathering stage; the third category, GENERAL_INQUIRY, refers to general inquiries that do not contain explicit purchase intent, such as "What does your company do?", etc., which have weaker opportunity signals; and the fourth category, NO_OPPORTUNITY, refers to messages that do not contain any commercial intent, such as polite replies like "Thank you" or "Okay".

[0044] Specifically, the lightweight intent classifier in this embodiment can be fine-tuned on a marketing scenario-annotated dataset. This dataset contains approximately 8,000 manually annotated samples derived from real marketing scenarios, divided into training, validation, and test sets in an 8:1:1 ratio. Training employs the AdamW optimizer with a learning rate of 2e-5, a batch size of 32, and 5 training epochs, using an early stopping strategy to prevent overfitting. On the test set, the F1-score is greater than 0.90, the macro-average F1 score is greater than 0.88, and the accuracy for all four intent classification classes is greater than 90%.

[0045] The output of the lightweight intent classifier in this embodiment is in JSON format, which includes intent_type (intent type), confidence (confidence, a floating-point number from 0 to 1), and top_2_intents (the top two intents and their probabilities).

[0046] Specifically, the Level 3 conversation aggregator in this embodiment is the third processing stage of the four-level progressive opportunity identification method. It receives messages and their intent types after being classified by the Level 2 lightweight intent classifier, and uses a sliding window algorithm to aggregate and analyze multiple rounds of messages from the same user within the same conversation context. It calculates the conversation-level intent strength, integrates multi-turn dialogue context information, and outputs the aggregated conversation opportunity evaluation result. Specifically, the processing procedure in this embodiment includes the following steps: Based on the sliding window algorithm, the session ownership of the pending session messages in multiple rounds is determined to obtain the session messages in each sliding time window; Calculate the intent strength of all session messages within each sliding time window based on the target intent type, and filter all session messages within each sliding time window based on the intent strength to obtain the target session message within each sliding time window; Based on the time window order, the target session messages within all sliding time windows are integrated into the context to obtain the target candidate sessions; The session opportunity confidence of the target candidate session is calculated based on multi-factor calculation.

[0047] Specifically, the time window width of the sliding window algorithm in this embodiment can be set to 10 minutes (600 seconds). For the same user (identified by user_id) in the same chat scenario (identified by chat_id), all messages with a time interval within the window width belong to the same session. The session identifier (session_id) is generated as follows: session_id = hash(user_id + "_" + chat_id + "_" + floor(timestamp / 600)), where timestamp is the message timestamp (in seconds). Messages are bucketed in 10-minute increments, and messages within the same bucket belong to the same session. When the interval between adjacent messages exceeds 10 minutes, subsequent messages are assigned to a new session. To avoid unlimited context growth, each session retains a maximum of the last 5 rounds of dialogue context; any messages exceeding this limit are discarded in chronological order, prior to the earliest message.

[0048] This embodiment calculates the intent strength of all session messages within the sliding window using the formula: intent_strength = (EXPLICIT_count × 2 + POTENTIAL_count × 1) / total_count. Here, EXPLICIT_count represents the number of explicit opportunity messages, POTENTIAL_count represents the number of potential opportunity messages, and total_count represents the total number of messages. This embodiment assigns a weight of 2 to explicit opportunities, 1 to potential opportunities, and 0 to general inquiries and no-opportunity messages. When intent_strength is greater than or equal to 0.3, the session is determined to have sufficient opportunity signal strength, triggering Level 4 LLM fine-tuning; if it is less than 0.3, it is downgraded to a general session and does not enter the Level 4 Large Language Model filter for processing.

[0049] In this embodiment, after obtaining the target session messages within each sliding time window, context integration is performed on the target session messages that pass the intent strength threshold. Multiple rounds of target session messages are concatenated into a unified text format in chronological order. For example, [User] Does your product support API integration? \n[User] Approximately how much? \n[Customer Service] The enterprise version supports the full API, and the price is… During the integration process, key entities are extracted based on predefined rules, including product name (matching the product thesaurus), price information (matching the amount regular expression), and time information (matching the date and time thesaurus). The extracted entity list is passed as structured information along with the session text to the Level 4 large language model filter. In some embodiments, to further compress the context length of long sessions, a lightweight text summarization model can be used to generate a core summary of the concatenated session text. This lightweight text summarization model can use a small network based on Transformer Encoder (such as DistilBERT or a distilled version of Chinese BERT-wwm-ext), outputting a core summary of no more than 100 characters with a latency controlled within 30 milliseconds.

[0050] The session aggregator in this embodiment also integrates multiple factors to evaluate opportunity confidence, including intent_strength (intent strength, 0 to 1), message_rounds (message rounds, more rounds indicate higher engagement), user_activity (user activity, calculated based on historical message frequency), and entity_richness (entity richness, the number of identified key entities), outputting a floating-point number between 0 and 1, opportunity_confidence. The average processing latency for a single session at this level is less than 100 milliseconds.

[0051] Specifically, the Level 4 large language model filter in this embodiment is the final processing stage of the four-level progressive opportunity identification method. It receives high-value sessions aggregated by the Level 3 session aggregator as target candidate sessions, calls the large language model to perform deep semantic analysis on the content of the target candidate sessions, and outputs a structured opportunity evaluation result. This stage only processes high-value candidate sessions, which account for about 5% to 8% of the total original messages, reducing the number of large language model calls by about 95% while ensuring identification accuracy.

[0052] This embodiment's large language model filter supports flexible switching between multiple large language models. The system connects to external large model services through a unified LLM adapter interface, supporting mainstream models such as GPT-4, Wenxin Yiyan, and Tongyi Qianwen. The LLM filter encapsulates the differentiated APIs of each model into a unified calling interface, including three interface types: text generation, structured output, and streaming output. System administrators can dynamically specify the currently used model provider (the party providing the intelligent agent service) through the configuration center; switching between different models requires no modification to the business code. For high-value business opportunity sessions, the model with the strongest capabilities is prioritized for in-depth analysis.

[0053] This embodiment's large language model filter uses a designed Prompt engineering-guided model to output structured results. The System Prompt is defined as a "Marketing Opportunity Analysis Expert," instructing users to examine the conversation from a professional marketing analyst's perspective. The User Prompt contains analysis instructions and the text of the conversation to be analyzed, requiring in-depth analysis from the following dimensions: urgency of user needs (assessing time-sensitive words such as "urgently needed" and "as soon as possible"), strength of purchase intention (judging the degree of determination from language patterns), budget sensitivity (whether price is proactively mentioned), and competitor attention (whether competing products are compared). The Prompt explicitly requires output in a strict JSON Schema format, prohibiting additional text.

[0054] The output of the large language model filter in this embodiment is a structured opportunity tag in JSON Schema format, containing: has_opportunity (boolean, indicating whether an opportunity exists), opportunity_level (enumeration: high / medium / low), opportunity_type (enumeration: purchase / inquiry / complaint / other), customer_intent (string, core intent), recommended_action (string, recommended action), confidence (floating-point, 0 to 1), and key_entities (array, a list of key entities including type and value fields). The output is validated for JSON format and numerical range before being used as the final result. If the output format is incorrect or key fields are missing, a retry is automatically initiated, up to a maximum of two retries. This level achieves an accuracy greater than 80%, with an average latency of less than 2000 milliseconds per call.

[0055] It is understood that early stopping conditions are included in the edge filter, lightweight intent classifier, conversation aggregator, and large language model filter of this embodiment; the early stopping conditions in the edge filter, lightweight intent classifier, and conversation aggregator are all used to directly output the target intent type. Specifically, all the early stopping conditions in this embodiment form a four-level early stopping mechanism, which can terminate the subsequent processing of messages with no commercial value as early as possible and reduce the consumption of computing resources.

[0056] Regarding the early stopping condition of the edge filter, this embodiment directly outputs messages that are blocked by any of the rules of length filtering, modifier filtering, system message filtering, or duplicate message filtering in the Level 1 edge filter as non-business opportunity results through the early stopping channel, without proceeding to subsequent levels. This level is a hard interception, and the message is permanently discarded after being triggered. In actual operation, approximately 80% of input messages are intercepted at this stage.

[0057] For the early stopping conditions of the lightweight intent classifier, this embodiment sets two conditions: Condition 1, the classifier is classified as NO_OPPORTUNITY and confidence is greater than 0.85, indicating that the model has a high degree of certainty in determining that the message does not contain commercial intent, and the non-business opportunity result is directly output through the early stopping channel; Condition 2, the classifier is classified as EXPLICIT_OPPORTUNITY and confidence is greater than 0.9, indicating that the model has a high degree of certainty in determining a strong buying signal, and the message skips the Level 3 session aggregator and directly enters the Level 4 LLM fine screening. This level of early stopping interception accounts for approximately 10% of the total message volume.

[0058] Regarding the early termination conditions for the conversation aggregator, this embodiment sets two conditions: Condition 1, intent_strength is less than 0.3, indicating insufficient overall business opportunity signals in the conversation, and the termination process will not enter the Level 4 large language model filter; Condition 2, the conversation round is 1 and classified as GENERAL_INQUIRY, indicating a lack of follow-up interaction in a single round of general consultation, and the process will be terminated.

[0059] Regarding the early stopping condition of the large language model filter, this embodiment, after processing by the large language model filter, is divided according to opportunity_level: high (high opportunity) is immediately pushed to the sales agent to trigger real-time follow-up; medium (medium opportunity) is added to the follow-up queue for orderly processing; low (low opportunity) is only persisted to the opportunity record storage and does not trigger active follow-up.

[0060] The four-level early stop mechanism set up in this embodiment is distributed as follows in a typical enterprise-level SCRM scenario: Level 1 filters approximately 80%, Level 2 early stop approximately 10%, Level 3 early stop approximately 2% to 5%, and finally only about 5% to 8% enter Level 4 to call the large language model. Compared with the solution where all messages directly call the large model, this mechanism reduces the number of large model calls by approximately 95%, significantly reducing operating costs.

[0061] It is understood that, after the intent recognition layer completes the processing in this embodiment, the dynamic routing layer queries the Agent registry to obtain multiple candidate Agent instances based on the target intent type and opportunity tag information, forming a candidate Agent instance list. A multi-factor scoring method is used to determine the selection weight of each candidate Agent instance. Based on the selection weight, at least one execution Agent instance is determined from the candidate Agent instance list, and a routing decision is generated based on the target intent type. Specifically, the calculation formula for the selection weight in this embodiment is as follows: Selection Weight = Historical Success Rate × 0.3 + (1 - Current Load) × 0.3 + (1 - Average Response Time / Maximum Threshold) × 0.2 + Session Continuity × 0.2.

[0062] It is understood that, in this embodiment, after obtaining the execution agent instance and routing decision, the agent execution layer selects the target execution mode of the current agent based on the current application scenario and routing decision. After invoking the execution agent instance according to the target execution mode, the user request is routed to the execution agent instance, so that the current workflow corresponding to the social customer relationship management message is executed through the execution agent instance. The target execution mode in this embodiment can be either a workflow compilation mode or an independent service deployment mode.

[0063] Specifically, the workflow compilation mode in this embodiment can use JSON format to standardize the declarative definition of the workflow, support 14 node types and rich conditional routing capabilities, and realize the dynamic parsing and efficient execution of the workflow through a three-layer parsing engine composed of parser, scheduler and executor. In addition, it can realize the flexible deployment and dynamic update of the workflow with version management and hot reloading mechanism.

[0064] In the JSON Schema definition specification, the top-level structure of a workflow definition (JSON definition input) includes the following required fields: "workflow_id" field, a string, uniquely identifies a workflow within the same namespace and cannot be duplicated; "version" field, a string using semantic versioning (major.minor.patch), used to identify the workflow's version information; "name" field, a string providing a human-readable name for the workflow; "description" field, a string describing the workflow's business purpose and functional specifications; and "nod" field. The "es" field is an array containing all node definitions for this workflow, with each element being a node definition object; the "edges" field is an array containing the connection relationships between nodes, with each element being an edge definition object; the "variables" field is an object used to declare workflow-level global variables and their initial values ​​and types; and the "config" field is an object containing workflow-level configuration parameters, such as global timeout (default 300 seconds), default retry strategy (maximum number of retries, backoff strategy), execution mode preference (synchronous or asynchronous priority), and log level settings.

[0065] The node definition schema includes the following fields: "node_id" is a string type, uniquely identifying a node within the same workflow, with a naming convention of uppercase and lowercase letters, numbers, and underscores, and a length not exceeding 64 characters; "node_type" is a string enumeration value, taking one of 14 predefined node types; "config" is an object type, containing configuration parameters specific to this node type, with different config structures for different node types; "inputs" is an object type, defining the input variable mapping relationship for this node, supporting three assignment methods: constant values ​​(directly written values), global variable references ("{{var_name}}" syntax), and upstream node output references ("{{#nodeId.field#}}" syntax); "outputs" is an object type, defining the output variable names and their data types (string, number, boolean, object, array) for this node.

[0066] The edge definition schema describes the connection relationship and control flow between nodes, and includes the following fields: the "source" field is a string type and its value is the node_id of the source node; the "target" field is a string type and its value is the node_id of the target node; the "condition" field is a string or null. When it is null, it means there is no conditional connection. Otherwise, it is a conditional expression string. Control flow is only passed along the edge to the downstream node when the expression evaluates to true.

[0067] The variable system supports three referencing formats: global variables use double curly braces "{{variable_name}}", referencing global variable values ​​declared in workflows.variables or dynamically set at runtime; node output references use the syntax "{{#nodeId.field#}}", used to reference the value of a specific output field of a node, where nodeId is the target node's node_id, and field is the field name defined in the node's outputs; the expression syntax supports comparison operations (==, !=, >, <, >=, <=), logical operations (&&, ||, !), and regular expression matching (=~). Expressions are dynamically parsed and evaluated at runtime, used for branch judgments in ifelse nodes and dynamic calculations in variable_assigner nodes. Variable scope is workflow-level global scope; all nodes share the same variable context. The output of any node is automatically written to the global context after execution, for reference by downstream nodes.

[0068] This embodiment's declarative workflow programming pattern supports 13 node types, covering process control, AI capability invocation, and external system integration. The 13 node types are as follows: (1) start node: The type identifier "start" is the workflow entry node, and there is only one. The config contains the "input_schema" parameter, which defines the input parameter field names, types, whether they are required, and their default values ​​in JSON Schema format. If there is no upstream input, the outputs content is written to the global context as an initial variable.

[0069] (2) end node: The type identifier is "end", which is the workflow exit node and can contain multiple nodes. The config contains the "output_schema" parameter, which defines the format of the returned result. The inputs reference upstream outputs or global variables to assemble the final result. The workflow terminates when this node is reached, and the variable status is returned as the execution result.

[0070] (3) llm node: The type identifier is "llm", which calls the large language model. The config contains: "model_name" specifies the model name; "prompt_template" defines the prompt word template that supports variable embedding; "temperature" controls the generation randomness (0 to 2); "max_tokens" limits the maximum number of tokens. inputs provides the prompt word filling content, and outputs defines the generated results and token consumption. Retry according to the retry policy when an execution error occurs.

[0071] (4) ifelse node: The type identifier is "ifelse", a conditional routing node. The config contains an array of "branches", each element of which contains the "condition" conditional expression and the "target" target node ID. The first branch that meets the condition is evaluated and executed in order. The "default" default branch is supported.

[0072] (5) `code` node: The type identifier is "code", which executes a Python or JavaScript code snippet. The `config` contains: "language" specifies the language ("python" or "javascript"); "code" is the code string; and "timeout" specifies the maximum execution time (default 5 seconds). The code executes in an isolated sandbox, allowing only access to the `inputs` variable and restricted standard libraries. `outputs` defines the execution results.

[0073] (6) variable_assigner node: The type identifier "variable_assigner" is the variable assignment node. The config contains an array of "assignments", each element of which contains the target variable name "target", the source_type (which can be "constant", "expression" or "node_output") and the corresponding value "source_value". It is used for unified handling of variables after different branches are merged.

[0074] (7) The `iteration` node: Identified by the type "iteration", it's the loop execution node, supporting both for-each and while modes. The config includes: "loop_mode" ("for_each" or "while"); "iteration_source" (the array variable in for-each mode); "condition" (the loop condition in while mode); and "max_iterations" (the maximum number of iterations, defaulting to 100). Loop output can be appended to the result array or aggregated.

[0075] (8) model_service node: The type identifier is "model_service", which calls external ML model services (such as sentiment analysis, NER model, etc.). The config contains "service_endpoint", "model_version" and "request_format". The difference between this node and the llm node is that this node is used for traditional ML model service calls.

[0076] (9) knowledge_retrieval node: Type identifier "knowledge_retrieval", knowledge base retrieval node. The config includes: "knowledge_base_id" knowledge base identifier; "retrieval_mode" ("vector" vector retrieval, "keyword" keyword retrieval, "hybrid" hybrid retrieval); "top_k" number of results to return (default 5). Returns relevant segments and similarity scores.

[0077] (10) mcp node (MCP tool node, for external SCRM data interface integration): Type identifier "mcp", SCRM data source node. config includes: "data_type" ("customer_profile", "order_history", "interaction_log", etc.); "query_condition" query conditions; "data_fields" list of returned fields. Obtain customer data through the SCRM data interface.

[0078] (11) edge_filter node: The type identifier is "edge_filter", which integrates Level 1 edge filtering capabilities. The config contains an array of "filter_rules", which defines the list of filtering rules to be executed. It receives raw messages and outputs the filtering results and hit rule information. It enables edge filtering capabilities to be orchestrated as a standard node into any process.

[0079] (12) `session_aggregator` node: Type identifier "session_aggregator", integrates Level 3 session aggregation capabilities (203). The configuration includes: "window_size" sliding window duration (default 10 minutes); "max_turns" maximum number of rounds to retain (default 5 rounds); "aggregation_mode" aggregation mode ("intent_strength" intent strength aggregation or "confidence_merge" confidence fusion). Calculates session-level intent strength and opportunity confidence.

[0080] (13) Agent Node: Type identifier "agent", calls other agents (141-14N) via A2A protocol. The config contains: "target_agent_id" target agent identifier (supports dynamic specification via variable reference); "action" action name; "timeout" timeout; "fallback_agent_id" fallback agent in case of failure. Inputs assemble the call parameters, and outputs receive the return results. This node is the core node for multi-agent collaboration.

[0081] Specifically, the workflow orchestration mode in this embodiment parses and executes the current workflow through a three-layer parsing engine. The three-layer parsing engine includes a parser, a scheduler, and an executor. The parser is responsible for syntax validation and semantic parsing, and includes a schema validation module, a node type parsing module, and a dependency extraction module. The schema validation module checks required fields, field types, the validity of enumerated values, and the uniqueness of `node_id`. The node type parsing module loads the corresponding processor based on `node_type` and verifies whether the `config` parameter conforms to the node type specification. The dependency extraction module traverses the `edges` array to construct an adjacency list dependency graph and records the in-degree information.

[0082] The scheduler is responsible for constructing the DAG (Directed Acyclic Graph) and generating execution plans. It includes a DAG construction module, a topology sorting module, and a variable passing module. The DAG construction module builds the DAG data structure based on an adjacency list and an in-degree list. The topology sorting module uses the Kahn algorithm: nodes with an in-degree of 0 are added to the execution queue, and each node is removed from the execution plan and its downstream nodes' in-degree is decremented by 1. Nodes with an in-degree of 0 are added to the queue, and this process is repeated until the queue is empty. If the number of nodes in the execution plan is less than the total number of nodes, a cycle exists, and an exception is thrown, terminating the process. Parallel nodes (with an in-degree of 0 at the same time) are marked as a group that can be executed in parallel. The variable passing module analyzes the inputs of each node to build a variable reference graph and provides hints for unresolved variable references.

[0083] The executor is responsible for node scheduling and execution, and includes a node execution engine with synchronous and asynchronous execution modes, as well as a status monitoring module. The node execution engine schedules execution according to topological order, using a thread pool for concurrent execution of parallel groups. Synchronous execution mode uses HTTP calls and blocks to wait for results, with a default timeout of 30 seconds. Asynchronous execution mode uses a message queue (MQ) for asynchronous communication. Before execution, variable references in the inputs are resolved from the global variable context and replaced with actual values; after execution, outputs are written to the global context. The status monitoring module records the start and end times, execution time, and results of each node, and provides a status query interface.

[0084] In this embodiment, during execution, the retry strategy is limited to a maximum of 3 times, with an exponential backoff interval (1s / 2s / 4s). Failure branch handling supports specifying a fallback node for critical nodes, and after a retry failure, the process jumps to the fallback to execute the degradation logic. Timeout handling supports configuring a timeout for each node, and after the timeout, the node can choose to terminate, jump to the timeout branch, or continue with the default value.

[0085] Specifically, in this embodiment, the workflow definition is stored in the Git repository as a JSON file, managed by directory by workflow_id. Version numbers use a semantic versioning format (major.minor.patch): incrementing major version numbers indicate incompatible interface changes (such as changes to node input / output fields); incrementing minor version numbers indicate backward-compatible feature additions (such as adding optional configuration parameters); and incrementing patch numbers indicate bug fixes or configuration tweaks. Each change commit to Git retains a complete history, including the change author, time, and summary. At runtime, a version number is specified for invocation; different versions coexist in memory, supporting version comparison to view differences.

[0086] During system startup, all JSON workflows are scanned and loaded from the directory. After verification by the parser, they are loaded into the in-memory workflow registry. At runtime, administrators submit new definitions or updates via the management API. Hot updates employ a verification-before-replacement strategy: first, schema validity is checked (field types, required fields, enumeration values). If the verification passes, the scheduler is invoked to resolve dependencies and detect cycles, ensuring the new definition can correctly construct a DAG. After successful verification, the in-memory definition is replaced with an atomic operation, without affecting currently running instances, achieving hot updates without service interruption.

[0087] Specifically, the workflow verification in this embodiment includes four layers of checks: the schema verification layer checks whether the syntax structure and field types conform to the specifications; the connectivity verification layer checks that all nodes can be reached from the start node and there are no dead-end nodes; the type verification layer checks the type compatibility of variable references (whether the output type of the source node matches the input type of the target node); and the cycle detection layer calls the topology sorting module to ensure that the DAG is acyclic, and if a cycle exists, it refuses to load and provides the cycle path information.

[0088] In the event of an update failure, a rollback mechanism automatically restores the system to the previous stable version, recording the rollback event log (rollback reason, version number, timestamp). Running instances employ a read-time replication strategy, binding the instance to the version at startup; updates do not affect instances currently in operation. Administrators can view the version list via API and manually roll back to a specified historical version.

[0089] It is understood that in the independent service mode of this embodiment, the Agent is deployed as an independent service and directly processes requests; it is suitable for scenarios with simple logic and sensitivity to latency; and has the advantages of fast response (<100ms), low resource consumption, and easy horizontal scaling. In the workflow orchestration mode of this embodiment, the Agent runs as a workflow node and is uniformly scheduled by the workflow engine; it is suitable for complex business processes that require multi-node collaboration; and has the advantages of process visualization, ease of maintenance, and support for dynamic adjustment.

[0090] Understandably, based on Figure 1 The system architecture shown is as follows: Figure 3 As shown, the execution process of this embodiment includes the following steps: Receiving user requests: The API Gateway receives requests and extracts metadata such as user identifier, session identifier, message content, and timestamp; Intent recognition: The intent recognition layer performs semantic analysis on the content of the conversation messages and outputs the intent type and confidence score; Get the candidate Agent list: Query the Agent registry center based on the intent type to get all candidate Agents that can handle that intent type, and then query the Agent instance list and return the Agent information; Calculate the selection weights: Calculate the selection weights for each candidate Agent; Select the optimal Agent: The Agent with the highest weight will be selected as the execution Agent; Request routing: Routes user requests to the Agent instance corresponding to the Agent to execute business logic; Monitor execution status: Monitor the execution status of the Agent in real time and return the execution results to respond to user requests.

[0091] The beneficial effects shown in Table 1 can be obtained by comparing the system of this application embodiment with the existing method: Table 1

[0092] Please see Figure 4 This application also provides a marketing data processing method based on multi-agent collaboration, which includes the following steps: Step S110: Obtain user requests and social customer relationship management messages, wherein the social customer relationship management messages include user identifier, session identifier, message content and message timestamp; Step S120: Based on the multi-level progressive opportunity identification method, after performing intent identification and opportunity analysis on social customer relationship management messages, the target intent type and opportunity tag information are output. The target intent type includes explicit opportunity, potential opportunity, inquiry or no opportunity; the opportunity tag information includes opportunity level tag. Step S130: Based on the target intent type and business opportunity tag information, query the Agent registry to obtain multiple candidate Agent instances and form a candidate Agent instance list; Step S140: Determine the selection weight of each candidate Agent instance using a multi-factor scoring method; Step S150: Determine at least one execution agent instance from the candidate agent instance list according to the selection weight, and generate a routing decision based on the target intent type; Step S160: Select the target execution mode for the current Agent based on the current application scenario and routing decision; Step S170: After invoking the execution agent instance according to the target execution mode, the user request is routed to the execution agent instance so that the current workflow corresponding to the social customer relationship management message can be executed through the execution agent instance.

[0093] It is understood that the content of the above system embodiments is applicable to this method embodiment. The specific functions implemented in this method embodiment are the same as those in the above system embodiments, and the beneficial effects achieved are also the same as those achieved in the above system embodiments.

[0094] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0095] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0096] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0097] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0098] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0099] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0100] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0101] The marketing data processing method and related equipment based on multi-agent collaboration provided in this application have the following beneficial effects: The accuracy of intent recognition has been significantly improved. This is due to the adoption of the Chinese-roberta-wwm-ext model optimized for Chinese and the local deployment solution. The model has been optimized for Chinese semantic understanding and can accurately identify user intent in complex marketing scenarios. Combined with the confidence assessment module, manual review or clarification is triggered when the confidence level is lower than the preset threshold. The accuracy of intent recognition has increased from 82% to over 95%. First, response latency is significantly reduced: For simple queries, the independent service mode and lightweight model bypass complex workflow orchestration; the response latency in the independent service mode is less than 100ms; the response time is reduced from 500ms to less than 100ms. Second, improved coverage in handling complex scenarios: Through multi-agent dynamic routing and declarative workflow orchestration, it supports 14 node types; the execution path can be dynamically determined according to business logic; and the coverage in handling complex scenarios has increased from 60% to 100%. Third, the new scenario access cycle is shortened: Through the declarative workflow orchestration mechanism, new scenarios only need to define workflows in JSON format; no modification to the underlying code is required, and business process adjustments take effect immediately; the new scenario access cycle is shortened from 2-4 weeks to less than 1 week. Fourth, improved system throughput: Through a four-level progressive processing mechanism, Level 1 and Level 2 adopt lightweight local inference; the early stopping mechanism significantly reduces invalid computation; the system throughput has increased from 1000 TPS to 5000 TPS. Fifth, the cost of large model calls is significantly reduced: Through a four-level progressive processing mechanism and an early stop mechanism, Level 1 filters 80% of invalid messages; the Level 2 early stop mechanism returns directly when NO_OPPORTUNITY is identified, without proceeding to subsequent levels; the number of large model calls is reduced by 95%, significantly reducing operating costs; Sixth, improved efficiency and accuracy of opportunity identification: Through a four-level progressive opportunity identification method, progressing step by step from edge filtering to LLM fine screening; the conversation aggregator integrates multi-turn dialogue context to improve the accuracy of intent understanding; the efficiency of opportunity identification is greatly improved, while the accuracy remains at a high level; Seventh, enhanced system flexibility and maintainability: Through the declarative workflow orchestration mechanism, adjustments to business processes do not require code modification; it supports multi-version storage and version switching of workflow definitions; the system's flexibility and maintainability are significantly enhanced.

[0102] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0103] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0104] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0105] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0106] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0107] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0108] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0109] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0110] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0111] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A marketing data processing system based on multi-agent collaboration, characterized in that, The system includes: The access layer is used to obtain user requests and social customer relationship management messages, which include user identifier, session identifier, message content and message timestamp; The intent recognition layer is used to perform intent recognition and opportunity analysis on the social customer relationship management message based on a multi-level progressive opportunity recognition method, and then output target intent type and opportunity tag information. The target intent type includes explicit opportunity, potential opportunity, inquiry, or no opportunity; the opportunity tag information includes opportunity level tag. A dynamic routing layer is used to query multiple candidate Agent instances from the Agent registry center based on the target intent type and the business opportunity tag information to form a candidate Agent instance list, determine the selection weight of each candidate Agent instance through a multi-factor scoring method, determine at least one execution Agent instance from the candidate Agent instance list based on the selection weight, and generate a routing decision based on the target intent type. The Agent execution layer is used to select the target execution mode of the current Agent according to the current application scenario and the routing decision. After calling the execution Agent instance according to the target execution mode, the user request is routed to the execution Agent instance so that the current workflow corresponding to the social customer relationship management message can be executed through the execution Agent instance. A data storage layer is used to store the workload template corresponding to the current workflow.

2. The system according to claim 1, characterized in that, The intent recognition layer includes an intent classification engine, which includes an edge filter, a lightweight intent classifier, a conversation aggregator, and a large language model filter. The multi-level progressive opportunity identification method performs intent recognition and opportunity analysis on the social customer relationship management messages, and outputs target intent type and opportunity tag information, including: The social customer relationship management messages are coarsely filtered using the edge filter to obtain the session messages to be processed. The lightweight intent classifier is used to classify the intent of the session message to be processed to obtain the target intent type. The session aggregator performs aggregation analysis on multiple rounds of pending session messages from the same user in the same session context based on the target intent type to obtain target candidate sessions, and calculates the session opportunity confidence of each target candidate session; The target candidate session is semantically analyzed using the large language model filter to determine the business opportunity tag information.

3. The system according to claim 2, characterized in that, The coarse filtering of the social customer relationship management messages to obtain the session messages to be processed includes: The social customer relationship management messages are filtered based on length filtering rules, modal word filtering rules, system message filtering rules, and duplicate message filtering rules to obtain the session messages to be processed.

4. The system according to claim 3, characterized in that, The step of aggregating and analyzing multiple rounds of pending session messages from the same user within the same session context based on the target intent type to obtain target candidate sessions, and calculating the session opportunity confidence score for each target candidate session, includes: Based on the sliding window algorithm, the session ownership of the multiple rounds of unprocessed session messages is determined to obtain the session messages within each sliding time window; Calculate the intent strength of all session messages within each sliding time window based on the target intent type, and filter all session messages within each sliding time window based on the intent strength to obtain the target session message within each sliding time window; Based on the time window order, the target session messages within all the sliding time windows are integrated into the context to obtain the target candidate sessions; The session opportunity confidence of the target candidate session is calculated based on multiple factors.

5. The system according to claim 4, characterized in that, The edge filter, the lightweight intent classifier, the conversation aggregator, and the large language model filter all have early stopping conditions. The early stop condition in the edge filter, the lightweight intent classifier, and the session aggregator is used to directly output the target intent type.

6. The system according to claim 1, characterized in that, The target execution mode includes workflow compilation mode or independent service deployment mode; The workflow compilation mode uses JSON format to standardize and declaratively define the current workflow, and uses a three-layer parsing engine to parse and execute the current workflow.

7. A marketing data processing method based on multi-agent collaboration, characterized in that, The method includes the following steps: Obtain user requests and social customer relationship management messages, wherein the social customer relationship management messages include user identifier, session identifier, message content, and message timestamp; After performing intent recognition and opportunity analysis on the social customer relationship management messages based on a multi-level progressive opportunity identification method, the target intent type and opportunity tag information are output. The target intent type includes explicit opportunity, potential opportunity, inquiry, or no opportunity; the opportunity tag information includes opportunity level tag. Based on the target intent type and the business opportunity tag information, multiple candidate agent instances are retrieved from the agent registry center to form a candidate agent instance list; The selection weight of each candidate Agent instance is determined using a multi-factor scoring method; At least one execution agent instance is determined from the candidate agent instance list based on the selection weight, and a routing decision is generated based on the target intent type; Select the target execution mode for the current Agent based on the current application scenario and the routing decision; After invoking the execution agent instance according to the target execution mode, the user request is routed to the execution agent instance so that the current workflow corresponding to the social customer relationship management message can be executed through the execution agent instance.

8. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor performs the method as described in claim 7.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of claim 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of claim 7.

Images