A heterogeneous channel-oriented distributed agent isolation and arrangement method and system

Abstract

The application discloses a kind of distributed Agent isolation and arrangement methods and systems for heterogeneous channel.The method includes the following steps: step S1: multi-channel access and standardized event conversion;Step S2: multi-channel runtime dynamic Agent arrangement and scheduling;Step S3: isolated knowledge base retrieval;Step S4: Skill arrangement and execution;Step S5: result adaptation and back transmission.The application can adapt the interaction characteristics and business requirements of different channels, realize channel dimension knowledge isolation, reduce the risk of improper cross-channel data isolation, meet the compliance requirements of different channel customization, support modular function arrangement, new business scenarios do not need to restructure core code, can form the closed-loop intelligent service from demand identification to instruction execution, adapt to the intelligent customer service application requirements in multi-channel heterogeneous scene.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence technology, specifically relating to a distributed agent isolation and orchestration method and system for heterogeneous channels. Background Technology

[0002] As enterprise customer service channels become increasingly diversified, with heterogeneous channels such as instant messaging, email, web-based customer service, SMS, and enterprise collaborative office coexisting, higher demands are placed on intelligent customer service systems, and existing technical solutions face significant limitations in multi-channel scenarios.

[0003] Current solutions only handle multimodal perception and emotion strategy coordination within a single session, without building a multi-channel access architecture. All channels share the same perception model and strategy generation logic, which makes it impossible to adapt to the differences in channel characteristics. For example, instant messaging channels require a concise and conversational style, while email channels require a formal and written style.

[0004] While some technologies collect data across all channels, they employ a globally unified knowledge base and quality assessment model, failing to achieve channel-level knowledge isolation and customized configuration. This makes it difficult to meet compliance requirements of different regional policies, regulations, or product versions. Furthermore, they lack agent-driven decision-making capabilities, remaining only at the service quality monitoring level and unable to drive after-sales business execution. Other existing technologies focus on single-session memory management, with their globally unified memory base not divided by channel, failing to support channel-specific memory strategy configurations. For example, different channels may have different session history retention durations, and their generative language models are only used for text response generation, lacking the ability to invoke external systems to perform device operations.

[0005] The aforementioned technical shortcomings are mainly manifested in the following ways: inconsistent channel messaging protocols lead to integration difficulties; service styles cannot dynamically adapt to channel interaction habits; knowledge base sharing causes risks of improper cross-channel data isolation; there is a lack of modular skill orchestration mechanisms to support atomic operations and composite workflow execution; core code needs to be refactored when adding new business scenarios; and the inability to form a closed-loop service from requirement identification to instruction execution. Especially in vertical fields such as IoT device management and eSIM remote configuration, existing systems struggle to achieve dynamic agent scheduling and knowledge retrieval with channel isolation.

[0006] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0007] In view of the above-mentioned deficiencies of the prior art, the first aspect of the present invention provides a distributed agent isolation and orchestration method for heterogeneous channels, comprising the following steps: Step S1: Multi-channel access and standardized event conversion; Receive customer messages from multiple heterogeneous channels, convert the message protocols of each heterogeneous channel into a unified standard event format, and attach a corresponding channel identifier to each standard event; The heterogeneous channels include at least one of the following: instant messaging channel, email channel, web customer service channel, SMS channel, and enterprise collaborative office channel; Step S2: Multi-channel runtime dynamic agent orchestration and scheduling; pre-configure independent agent instances for each access channel, dynamically load the agent configuration corresponding to the target channel according to the channel identifier, and instantiate the corresponding agent execution context; wherein, the independent agent configuration corresponding to different channels includes at least one or more of the following: system prompt words, basic model, toolset binding, memory strategy, and inference parameters; Step S3: Isolation knowledge base retrieval; The independent Agent instance responds to customer messages by accessing only the isolation knowledge base corresponding to the channel identifier to retrieve knowledge content related to the customer messages as inference context. Different channels correspond to different isolation knowledge bases. Step S4: Skill orchestration and execution; During the inference process, the Agent instance calls the corresponding Skill module to execute the target operation, wherein the Skill module is an independently encapsulated service function unit; Step S5: Result adaptation and feedback; Based on the inference results of the Agent instance and the execution results of the Skill module, generate reply content, adapt it to the message format requirements of the target channel, and then feedback it to the corresponding client.

[0008] In the previously described distributed agent isolation and orchestration method for heterogeneous channels, step S1 may optionally include: extracting the unique user identifier from the messages of each heterogeneous channel, mapping it to a globally unified customer ID, and establishing a cross-channel session association based on the unified customer ID; when the same customer initiates a request on different channels, its historical session context is associated through the unified customer ID.

[0009] In the previously described distributed agent isolation and orchestration method for heterogeneous channels, optionally, in step S2, the system prompts for different channels are configured differently to adapt to the user group characteristics, interaction habits and business rules of different channels; wherein, the system prompts for instant messaging channels are configured with a concise and colloquial style and an emoji usage strategy, and the system prompts for email channels are configured with a formal written style and a structured reply template.

[0010] In the previously described distributed agent isolation and orchestration method for heterogeneous channels, optionally, an independent agent instance is configured for each access channel through an agent development framework; when a channel event arrives, the scheduler loads the corresponding agent configuration according to the channel identifier in the event, instantiates the agent execution context, and injects the standardized event into the input queue of the agent; If the independent Agent instance of the current channel determines that the customer's problem is beyond its own capabilities, it calls upon the expert Agent instance configured within the channel to handle the problem collaboratively, and achieves continuous dialogue through the transmission of session context.

[0011] In the previously described distributed agent isolation and orchestration method for heterogeneous channels, optionally, in step S3, the isolation knowledge base is a vector knowledge base space independently configured for each channel, used to store knowledge documents specific to that channel; the isolation knowledge bases of different channels support customized document configuration according to the market area, product version or policies and regulations served by the channel; Access permissions for knowledge between different channels are restricted through namespace mechanisms or tenant identification mechanisms; wherein, the configuration of the isolated knowledge base includes: uploading documents by channel dimension, using the Embedding model for vectorized indexing, and configuring retrieval algorithms and similarity thresholds.

[0012] In the previously described distributed agent isolation and orchestration method for heterogeneous channels, optionally, in step S4, the execution logic of the Skill module includes at least one of the following: Atomic Skill: Directly calls the internal CLI command-line tool or API to complete a single customer service operation, including querying order status, resetting device password, creating work order, querying usage, or remotely activating device; Composite Skill: The workflow engine orchestrates the execution order, conditional branches, and exception handling of multiple atomic skills. LLM Skill: A text generation or analysis task autonomously completed by a large language model based on prompt word templates.

[0013] In the previously described distributed agent isolation and orchestration method for heterogeneous channels, the Skill module is optionally configured as an independent functional unit that can be reused and orchestrated in real time, and its definition includes at least: metadata, input parameter schema defined using JSON Schema, output schema, and fallback strategy; Updating the Skill module requires no modification to the core code; it can be deployed simply by configuring and binding the toolset to the target Agent. During inference, the Agent parses the name and parameters of the required Skill, calls the execution engine to obtain the results, and then integrates the results into the inference context for further processing or directly converts them into response content.

[0014] In the previously described distributed agent isolation and orchestration method for heterogeneous channels, the fallback strategy may optionally include: retrying when Skill execution fails, a degradation scheme, and transferring to human customer service.

[0015] To achieve the above objectives, a second aspect of the present invention provides a distributed agent isolation and orchestration system for heterogeneous channels, wherein implementing the distributed agent isolation and orchestration method for heterogeneous channels as described in any one of the first aspects includes: A multi-channel communication module is used to establish connections with at least two heterogeneous messaging channels, receive customer messages, and send replies. Intelligent customer service platform, the platform includes: The channel access gateway is used to convert the message protocols of various heterogeneous channels into a standard event format, attach a corresponding channel identifier to each standard event, and extract the user's unique identifier and map it to a globally unified customer ID. Multiple independent Agent instances, with at least one independent Agent instance corresponding to each access channel. Each Agent instance has independently configured system prompt words, basic models, toolset bindings, memory strategies, and inference parameters. Multiple isolated knowledge bases, with each channel corresponding to an independent vector knowledge base space, used to store knowledge documents specific to that channel; The Skill execution engine is used to store and execute multiple reusable Skill modules, each Skill module being an independently encapsulated service function unit. The scheduler is used to load the corresponding Agent instance according to the channel identifier in the standard event, inject the standardized event into the Agent input queue, and receive Skill call requests initiated by the Agent instance. After the Skill execution engine completes the operation, it returns the result. The channel access gateway is also used to adapt the response content generated by the Agent instance to the message format requirements of the target channel, and then send it back to the client through the multi-channel communication module.

[0016] In the previously described distributed agent isolation and orchestration system for heterogeneous channels, the isolation knowledge base optionally includes: Knowledge space isolation units are used to isolate knowledge base access permissions for different channels based on namespace mechanisms or tenant identification mechanisms. The semantic retrieval unit is used to retrieve knowledge content related to customer messages based on vectorized indexes and semantic similarity.

[0017] This application addresses the technical challenges in the existing multi-channel intelligent customer service field by implementing a complete process including standardized multi-channel message conversion, dynamic agent orchestration and scheduling, channel-specific isolated knowledge retrieval, modular skill execution, and result adaptation and feedback. These challenges include inconsistent channel protocols, inability to adapt to different channel interaction characteristics, security and compliance risks due to lack of knowledge isolation, and the need to refactor core code for new business scenarios due to a lack of modular orchestration. It can uniformly convert message protocols across heterogeneous channels, adapt to the interaction characteristics and business needs of different channels, achieve channel-level knowledge isolation, reduce the risk of improper cross-channel data isolation, meet the customized compliance requirements of different channels, support modular function orchestration, and eliminate the need to refactor core code for new business scenarios. It forms a closed-loop intelligent service from requirement identification to instruction execution, adapting to the application needs of intelligent customer service in multi-channel heterogeneous scenarios. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the concept, specific structure and technical effects of the present invention will be further explained below in conjunction with the accompanying drawings, so as to fully understand the purpose, features and effects of the present invention.

[0019] Figure 1 This is a flowchart illustrating an embodiment of a distributed agent isolation and orchestration method for heterogeneous channels provided by the present invention; Figure 2 This is a schematic diagram of the information flow path of a distributed agent isolation and orchestration system for heterogeneous channels provided by the present invention. Detailed Implementation

[0020] In this document, to make the technical means, inventive features, achieved objectives and effects of the invention readily understandable, the invention is further described below with reference to specific illustrations. However, the invention is not limited to the embodiments described below.

[0021] It should be noted that the structures, proportions, sizes, etc., illustrated in the accompanying drawings of this specification are only used to complement the content disclosed in the specification for those skilled in the art to understand and read, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0022] Terms such as “comprising” and “including” indicate that, in addition to the components that are directly and explicitly stated in the specification and claims, the technical solution of the present invention does not exclude the presence of other components that are not directly or explicitly stated.

[0023] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0024] In traditional intelligent customer service system architectures, when handling customer interaction requests from multiple heterogeneous channels, the lack of channel-level differentiated service configuration and architectural isolation mechanisms prevents the system from adapting to the different business rules, interaction habits, and compliance requirements of each channel. Specifically, existing technical solutions use a globally unified perception model and strategy generation logic to process data from all channels, resulting in a lack of channel-level knowledge isolation, insufficient modular orchestration capabilities, and a lack of agent-level autonomous business operation capabilities, thus affecting service accuracy, system reliability, and compliance. Furthermore, this problem stems from the fact that multimodal fusion is limited to the perception layer rather than the channel layer architecture; all channels share the same knowledge base and execution logic, failing to meet the differentiated needs of various heterogeneous channels in terms of protocol specifications, language styles, and data privacy.

[0025] For example, in an enterprise customer service deployment scenario, both WhatsApp instant messaging and email channels are integrated. WhatsApp's interaction protocol requires informal language and real-time response, while email requires formal language structure and asynchronous processing mechanisms. The existing system uses a globally unified knowledge base and agent configuration strategy, causing replies generated for WhatsApp to use the formal language format of email, which is inconsistent with the channel interaction specifications. Furthermore, the knowledge base retrieval process does not implement channel isolation, resulting in promotional content retrieved in email that is only applicable to WhatsApp, violating data privacy regulations and causing service anomalies. As a preferred implementation, this scenario involves heterogeneous channels including instant messaging, email, web customer service, SMS, and enterprise collaborative office channels. Differences in their business rules directly lead to user interaction mismatches and service process interruptions.

[0026] If the above issues are not addressed, the system will be unable to accurately adapt to multi-channel services, resulting in a degraded user experience and an increased failure rate in service request processing. Specifically, the lack of knowledge isolation may lead to the accumulation of compliance risks, insufficient modularity extends the system iteration cycle, and the lack of agent execution capabilities limits the service scope, confining service processes to text-based interactions and failing to form a complete after-sales service loop. Consequently, the application of intelligent customer service in vertical business scenarios such as IoT device management and eSIM remote configuration is restricted, and the overall system service capabilities cannot meet the actual needs of enterprises for multi-channel customer service.

[0027] Addressing the fragmented after-sales service challenges faced by enterprises in global operations across multiple channels: When customers initiate after-sales requests through different channels such as WhatsApp, Line, email, web chat, SMS, and proprietary platforms, existing solutions typically employ a unified processing logic, resulting in highly homogenized service experiences across channels and an inability to adapt to the interaction habits and business rules of users on different channels. Simultaneously, a globally shared knowledge base struggles to meet the differentiated needs of various channels in terms of policies, regulations, product versions, and service timeliness. Furthermore, after-sales service capabilities are implemented using hard-coding, leading to high costs for expanding into new scenarios. This application proposes a distributed agent isolation and orchestration method for heterogeneous channels, such as... Figure 1 As shown, the specific steps may include the following: Step S1: Multi-channel access and standardized event conversion. Heterogeneous channels refer to multiple communication methods with different messaging protocols, interaction methods, user group characteristics, and business rules. For example, instant messaging channels may focus on rapid, conversational communication, while email channels may require formal, structured written communication. Web-based customer service channels are usually integrated into websites, while SMS channels are limited by text length. Enterprise collaborative office channels may involve internal processes and specific application integration.

[0028] In this step, heterogeneous channels may include: instant messaging channels, email channels, web customer service channels, SMS channels, enterprise collaborative office channels, etc.

[0029] First, the system receives customer messages from multiple heterogeneous channels. For example, a separate communication adapter or listening service can be deployed for each heterogeneous channel. One adapter receives messages from instant messaging applications, another from email servers, and yet another processes data submitted by the web-based customer service frontend. These adapters pass the raw messages to a central processing unit. Subsequently, the heterogeneous message protocols from each channel (such as WhatsApp's Graph API format, WeChat Work's XML message format, and email's MIME format) are uniformly converted into standard JSON event objects. This process can be achieved through predefined conversion rules or mapping tables. For example, for instant messaging messages, fields such as text content, sender identifier, and timestamp are mapped to corresponding fields in the standard event format; for emails, information such as subject, sender, and body is also mapped to a unified structure. Thus, messages from different sources have a consistent representation within the system. Furthermore, a corresponding channel identifier is appended to each standard event. During message conversion, a unique identifier is added based on the message's original source channel, such as "IM," "Email," or "WebChat." This identifier will circulate throughout the subsequent processing flow alongside standard events, serving as the basis for distinguishing and matching channel-specific configurations. The aforementioned heterogeneous channels can include one or more of the following: instant messaging channels, email channels, web-based customer service channels, SMS channels, or enterprise collaborative work channels. For example, for instant messaging channels, APIs of mainstream instant messaging platforms can be integrated; for email channels, standard SMTP / POP3 service interfaces can be configured; for web-based customer service channels, an embedded JavaScript SDK can be provided; for SMS channels, SMS gateway services can be integrated; and for enterprise collaborative work channels, APIs of internal enterprise collaboration platforms can be integrated.

[0030] Step S2: Dynamic Agent Orchestration and Scheduling during Multi-Channel Runtime.

[0031] In this step, an independent Agent instance is pre-configured for each access channel. Based on the channel identifier, the Agent configuration corresponding to the target channel is dynamically loaded, and the corresponding Agent execution context is instantiated. The independent Agent configuration for different channels includes at least one or more of the following: system prompt words, basic model, toolset binding, memory policy, and inference parameters.

[0032] Specifically, the channel identifier is a unique tag attached to each standard event. This identifier explicitly indicates the original source channel of the message, allowing the system to perform precise channel matching throughout the processing flow, enabling differentiated configuration loading and logical processing for specific channels. The Agent execution context refers to the environment and state information of the Agent instance at runtime. It includes the specific channel configuration loaded by the current Agent instance, session state, available toolsets, and other runtime variables. Instantiating the Agent execution context means preparing all the necessary environment and resources for the Agent's operation.

[0033] First, pre-configuring independent Agent instances for each access channel can be achieved by pre-loading a generic Agent template for each known channel during system initialization and assigning it a unique logical identifier. These Agent templates can share the core inference logic, but their configuration parameters are stored and managed independently. Then, based on the aforementioned channel identifier, the Agent configuration corresponding to the target channel is dynamically loaded, and the corresponding Agent execution context is instantiated. When the system receives a standard event with a specific channel identifier, the scheduler will look up and load the channel-specific Agent configuration from the pre-set configuration library based on that identifier. Based on the loaded configuration, the system creates a new Agent execution context, which contains all the state information and resources required for Agent operation, such as the current session state and available toolsets. For example, a simple Agent configuration can be a JSON file containing the Agent's name, version, and some basic parameters. The independent Agent configurations for different channels include at least one or more of the following: system prompt words, base model, toolset bindings, memory policies, and inference parameters. These configuration items can be stored in the form of structured data (e.g., JSON or YAML files). For example, system prompts can be a simple text string used to guide the agent's dialogue style; the base model can specify a generic language model ID; the toolset bindings can be a list of tools that the agent can invoke; and the memory policy can be a simple rule, such as "retain the last five rounds of dialogue".

[0034] Step S3: Isolate knowledge base retrieval.

[0035] In this step, the independent Agent instance responds to customer messages by accessing only the isolated knowledge base corresponding to the channel identifier to retrieve knowledge content related to the customer message as the inference context. Different channels correspond to different isolated knowledge bases.

[0036] Specifically, an Agent instance refers to a pre-configured intelligent agent program for a specific access channel. Each Agent instance is designed to run independently, responsible for processing customer messages for its corresponding channel. It performs inference, decision-making, and executes corresponding operations based on its own configuration to provide customized services. An isolated knowledge base refers to a knowledge storage space maintained independently for each channel. Each isolated knowledge base is only accessible to its corresponding channel's Agent instance and is used to store channel-specific knowledge documents, frequently asked questions, business rules, and other content. This isolation mechanism ensures the exclusivity of knowledge and strict control over access permissions.

[0037] Inference context refers to all relevant information that an Agent instance relies on when making decisions, understanding customer intent, and generating responses. This typically includes current customer messages, historical session records, relevant knowledge retrieved from an isolated knowledge base, and the Agent's own configuration information.

[0038] When an independent Agent instance responds to a customer message, it only accesses the isolated knowledge base corresponding to the aforementioned channel identifier. This can be achieved by creating an independent logical partition or directory for each channel within the knowledge base system. When an Agent instance needs to retrieve knowledge, it includes its channel identifier as part of the query. The knowledge base system then restricts the query to the corresponding partition based on this identifier. For example, the knowledge base could be a file system, with each channel having its own independent folder, and the Agent can only access documents within its corresponding folder. Thus, knowledge content related to the customer message is retrieved as the reasoning context. The retrieved knowledge content can be directly appended to the customer message to form a longer input text, serving as the basis for the Agent's reasoning. For example, if a customer asks "How to activate the device," and the knowledge base retrieves the document "Device activation steps," the Agent's input could become "Customer message: How to activate the device. Related knowledge: Device activation steps are as follows:...". Different channels correspond to different isolated knowledge bases. This can be achieved by manually uploading and managing the dedicated knowledge documents for each channel. For example, Channel A's knowledge base contains frequently asked questions about product A, while Channel B's knowledge base contains after-sales policies for product B.

[0039] Step S4: Skill orchestration and execution.

[0040] In this step, during the inference process, the Agent instance calls the corresponding Skill module to execute the target operation. The Skill module is an independently encapsulated service function unit.

[0041] Specifically, a Skill module refers to an independently encapsulated service function unit. During inference, if an Agent instance recognizes the need to execute a specific business operation, it can call the corresponding Skill module. This abstracts complex service functions into reusable units, decoupling the functionality from the Agent's core orchestration logic and improving the system's scalability and flexibility.

[0042] After receiving a customer message and performing inference, if the Agent instance determines that an external operation needs to be performed, it can generate an instruction containing a Skill name and parameters. Upon receiving this instruction, the system locates and executes the corresponding Skill module. For example, if the Agent recognizes that a user wants to query orders, it generates "Call Skill: Query Orders, Parameter: Order Number=XXX". Here, a Skill module is an independently encapsulated service function unit. Skill modules can be implemented as independent functions, microservices, or scripts. Each Skill module has clearly defined input and output interfaces and can be deployed and updated independently. For example, a Skill module could be a Python function used to call an external API to query a database.

[0043] Step S5: Result adaptation and feedback.

[0044] In this step, the response content is generated based on the inference results of the Agent instance and the execution results of the Skill module, and then adapted to the message format requirements of the target channel before being sent back to the corresponding client.

[0045] The inference result of the Agent instance can be a text-based response suggestion, while the execution result of the Skill module may be structured data (such as order details). The system can integrate these two pieces of information to generate the final response content. For example, the Agent suggests "Your order status is shipped," and the Skill returns the order number and logistics information, which the system integrates into "Your order XXX has been shipped, logistics information: YYY." Subsequently, after format adaptation according to the message format requirements of the target channel, it is sent back to the corresponding client. The generated response content needs to be formatted according to the specific requirements of the target channel. For example, for instant messaging channels, it may be necessary to support emojis or Markdown format; for email channels, it may be necessary to generate an HTML email body; for SMS channels, it is necessary to ensure that the content is concise and meets the character limit. After adaptation, the response is sent to the customer through the corresponding communication interface.

[0046] The following example will provide a more detailed explanation of the above technical solution: Suppose a company needs to provide intelligent customer service across multiple channels for its global customers, including instant messaging (such as WhatsApp), email, and internal collaborative work platforms.

[0047] In step S1, when user A sends a message via instant messaging about "how to activate a newly purchased IoT device," the multi-channel communication module receives the message. The channel access gateway converts the instant messaging message protocol into a standard event format and adds an "IM" channel identifier to the standard event. Similarly, when user B sends an email via email about "checking the product warranty policy," the channel access gateway also converts it into a standard event format and adds an "Email" channel identifier.

[0048] In step S2, upon receiving a standard event with an "IM" channel identifier, the scheduler dynamically loads the configuration of a pre-configured independent Agent instance for the instant messaging channel. This configuration may include a concise, conversational system prompt, a general base model, a "device activation" toolset, and a short-term memory policy. The corresponding Agent execution context is then instantiated. Similarly, when the scheduler receives a standard event with an "Email" channel identifier, it dynamically loads the configuration of a pre-configured independent Agent instance for the email channel. This configuration may include a formal, written system prompt, a domain-specific base model, a "warranty inquiry" toolset, and a long-term memory policy. The corresponding Agent execution context is then instantiated.

[0049] In step S3, the IM Agent instance responds to user A's device activation message. During knowledge retrieval, this IM Agent instance only accesses the isolated knowledge base corresponding to the "IM" channel identifier. This isolated knowledge base may specifically store documents such as activation manuals and common troubleshooting guides for IoT devices. The IM Agent retrieves knowledge content related to "device activation" from this knowledge base and uses it as the inference context. Simultaneously, the Email Agent instance responds to user B's warranty inquiry message. This Email Agent instance only accesses the isolated knowledge base corresponding to the "Email" channel identifier. This isolated knowledge base may specifically store documents such as product warranty terms and service agreements. The Email Agent retrieves knowledge content related to "product warranty policy" from this knowledge base and uses it as the inference context.

[0050] In step S4, the IM Agent instance, combining the customer message and inference context, determines that user A's intent is to activate the device. Therefore, the IM Agent instance invokes the "Device Activation" skill module pre-bound to its toolset. This skill module is an independently encapsulated service function unit responsible for interacting with the external device management system and performing the device activation operation. Simultaneously, the Email Agent instance, combining the customer message and inference context, determines that user B's intent is to inquire about the warranty policy. Therefore, the Email Agent instance invokes the "Inquire Warranty" skill module pre-bound to its toolset. This skill module is responsible for retrieving product warranty information from the enterprise's internal database.

[0051] In step S5, the IM Agent instance generates a conversational response, such as "Your device has been successfully activated. Please check the device status," based on the execution result of the "Device Activation" Skill module (e.g., the status code indicating successful or failed device activation) and its own inference results. The channel access gateway adapts the response to the message format requirements of the instant messaging channel (e.g., adding emoticons or links) and sends it back to user A's instant messaging client via the multi-channel communication module. Simultaneously, the Email Agent instance generates a formal written response, such as "According to your product information, this device has a two-year warranty. Please refer to the attachment for specific terms." The channel access gateway adapts the response to the message format requirements of the email channel (e.g., generating an HTML-formatted email body) and sends it back to user B's email client via the multi-channel communication module.

[0052] As the above example demonstrates, this method uses channel identifiers throughout the entire service process, ensuring that each step can be isolated and customized for a specific channel. Agent instances, knowledge bases, and Skill modules are all dynamically matched and invoked around the channel identifier, forming a complete, channel-differentiated service loop.

[0053] This application presents a distributed agent mesh architecture, where each channel has an independent agent brain, an independent knowledge base, and an independent skill toolkit. Agents autonomously decide when to retrieve knowledge, when to invoke skills, and how to orchestrate workflows, addressing the issues of service differentiation, knowledge precision, and capability scalability.

[0054] In an optional embodiment, step S1 further includes: extracting the user's unique identifier from the messages of each heterogeneous channel, mapping it to a globally unified customer ID, and establishing a cross-channel session association based on the unified customer ID; when the same customer initiates a request on different channels, associating its historical session context through the unified customer ID.

[0055] Specifically, extracting unique user identifiers from messages across heterogeneous channels refers to identifying and retrieving specific information from received customer messages from different heterogeneous channels that uniquely identifies the user. For example, for instant messaging channels, the user's Open ID or User ID on the platform can be extracted; for email channels, the sender's email address can be extracted; for SMS channels, the mobile phone number that sent the SMS can be extracted; and for web-based customer service channels, the user's login ID or Session ID can be extracted. This process can be automatically completed by the access gateways of each channel according to preset parsing rules or message protocol specifications.

[0056] Mapping to a globally unified customer ID refers to converting unique user identifiers extracted from various heterogeneous channels into a unique customer identity identifier across the entire system through a unified identity recognition mechanism. This can be achieved by maintaining a customer identity mapping table, which stores the correspondence between unique user identifiers from different channels and globally unified customer IDs. When a new unique user identifier is received, the system queries the mapping table. If a corresponding globally unified customer ID already exists, it is used directly; otherwise, a new globally unified customer ID is generated and bound to the original unique user identifier. Another implementation method is to use an identity resolution service to perform fuzzy matching or rule matching based on shared user attributes (such as phone number and email address) to merge identifiers from different channels under the same globally unified customer ID.

[0057] Establishing cross-channel session relationships based on a unified customer ID refers to integrating and associating all historical session records under the same globally unified customer ID. This can be achieved by binding the metadata of each session (including session ID, channel identifier, timestamp, etc.) with the corresponding globally unified customer ID and storing it in a unified session history database. When a new session begins, the system will automatically query and load the customer's historical session records across all channels based on the identified globally unified customer ID, thereby forming a complete view of customer interactions.

[0058] When the same customer initiates requests through different channels, associating their historical session context with the unified customer ID means that when a customer switches from one channel to another for consultation, the system can automatically retrieve and provide the customer's session content across all historical channels as the inference context for the current Agent instance using the established globally unified customer ID. This implies that the Agent already possesses all relevant communication information from other channels before processing the current request, eliminating the need for the customer to repeat themselves.

[0059] The following is a concrete example. Suppose a customer first inquires about a product via an instant messaging channel (such as WeChat). In step S1, the system receives the WeChat message, converts it to a standard event format, and attaches a WeChat channel identifier. Simultaneously, the system extracts the customer's WeChat Open ID from the WeChat message as a unique user identifier and maps it to a globally unified customer ID, such as "CUST_XYZ". The history of this WeChat conversation is then associated and stored with "CUST_XYZ". Several hours later, the same customer sends an email via an email channel, inquiring about another issue with the same product. In step S1, the system receives this email, converts it to a standard event format, and attaches an email channel identifier. The system extracts the sender's email address from the email as a unique user identifier and recognizes that this email address also corresponds to the previously established globally unified customer ID "CUST_XYZ". At this point, the system associates its historical conversation context with "CUST_XYZ", including previous inquiries via WeChat. When the Agent execution context is dynamically loaded and instantiated for an email channel, the Agent not only obtains the independent configuration for the email channel but also loads all historical session contexts of "CUST_XYZ" in both WeChat and email channels. This allows the Agent to clearly understand the questions the customer previously asked on WeChat when processing the email, thus providing a more coherent and comprehensive response and avoiding the customer repeating information already provided.

[0060] This application's solution establishes a unified user identity to connect session data across different heterogeneous channels, resolving the issue of broken session context when the same customer inquires across channels. This not only improves the customer's consultation experience but also helps the agent handling the request obtain more complete interaction information, enhancing the accuracy of responses. This mechanism ensures that even if a customer switches channels, the agent can still obtain a complete user interaction history, thereby providing more consistent and accurate service, significantly improving service quality and user experience.

[0061] In an optional embodiment, in step S2, the system prompts for different channels are configured differently to adapt to the user group characteristics, interaction habits, and business rules of different channels. Specifically, the system prompts for instant messaging channels are configured with a concise, conversational style and an emoji usage strategy, while the system prompts for email channels are configured with a formal, written style and a structured reply template.

[0062] System prompts are a set of instructions or contexts that guide the behavior, tone, role, and response format of a large language model or agent. They define the agent's role, constraints, and goals. They can be represented as plain text strings containing instructions, rules, and examples; structured data formats containing fields such as role, tone, prohibited topics, and required response elements; or a template system with dynamically inserted variables. Differentiated configuration refers to setting different parameters or values ​​for the same type of component (such as system prompts) based on specific criteria (e.g., different channels). This can be achieved by storing channel-specific prompt templates indexed by channel identifier in a configuration database, by modifying rules based on detected channels using a rule engine, or by maintaining independent configuration files for each channel. Instant messaging channels refer to communication platforms designed for real-time, informal text conversations, characterized by fast-paced interaction and a user preference for relaxed and friendly communication. A concise, conversational style and emoji usage strategy aims to make the agent's response language short and informal, appropriately using emojis to convey tone and emotion, simulating natural conversation. This can be achieved by explicitly instructing the Agent to adopt this style in the prompt text, providing examples to guide its generation, or even integrating a post-processing module to assist in the insertion of emojis. Email channels are primarily used for formal or semi-formal written communication and can involve structured content. Formal written language style and structured reply templates require the Agent's replies to have precise grammar, complete sentences, formal vocabulary, and follow a specific format or template structure, such as including salutations, clear paragraphs, and closing remarks. This can be achieved by explicitly instructing the Agent to follow a formal tone and standard email structure in the prompt text, or by providing specific templates for it to fill in.

[0063] As a preferred embodiment, the system utilizes the OpenClaw framework for channel-customized agent initialization and scheduling. In this embodiment, the open-source OpenClaw framework serves as the foundation for agent development and execution. The OpenClaw framework provides core capabilities for agent definition, tool registration, memory management, inference orchestration, and scheduler, enabling developers to quickly build intelligent agent applications with autonomous decision-making and tool invocation capabilities.

[0064] For each heterogeneous messaging channel accessed (such as WhatsApp, email, web IM), the operations and maintenance personnel create a separate Agent instance for it through the OpenClaw framework's management interface or configuration file, and configure it as follows: System Prompt: For WhatsApp, the system prompt should read: "You are an intelligent customer service assistant for overseas users. Please reply in a concise and conversational style, use emojis appropriately to build rapport, and avoid lengthy written expressions." For email channels, set the system prompt to: "You are a formal customer service agent facing corporate clients. Please reply using standardized, formal, and structured written language, following business email etiquette, and include your signature and contact information at the end." Basic model configuration: Configure the WhatsApp Agent with a lightweight large language model (such as GPT-3.5 Turbo) that offers faster response times and lower costs to meet the needs of high concurrency and real-time interaction; configure the Email Agent with a more advanced model (such as GPT-4) that offers stronger reasoning capabilities and higher accuracy to handle complex after-sales service tickets and contract terms interpretation.

[0065] Toolset binding: Each Agent declares its set of callable tools, which uniformly includes: knowledge base retrieval tools (for accessing the channel-isolated knowledge base), skill execution tools (for invoking atomic / composite / LLM Skills), and external API tools (such as order systems, device management platforms, and eSIM configuration interfaces).

[0066] Memory strategies: For instant messaging channels such as WhatsApp, configure the conversation history to retain the most recent 20 rounds of dialogue and enable the long-term memory summary function to support cross-day context association; for email channels, configure the retention of complete historical email exchanges and disable automatic summarization to ensure content integrity.

[0067] Inference parameters: Set Temperature=0.8 and Top P=0.9 for the WhatsApp Agent to allow some randomness for more engaging responses; set Temperature=0.2 and Top P=0.5 for the Email Agent to ensure highly specific, consistent, and rigorous responses.

[0068] Runtime scheduling and event injection: When a customer sends a message through any channel, the webhook of that channel pushes the message to the system's channel access gateway. After the gateway performs protocol conversion and identity normalization, it generates a standard JSON event object and attaches a channel identifier (such as `channel: "whatsapp"`). This event is then forwarded to the scheduler built into the OpenClaw framework.

[0069] The scheduler internally maintains a mapping table between channel identifiers and agent configurations. Upon receiving an event, the scheduler performs the following operations: Based on the channel identifier `whatsapp` in the event, find the corresponding Agent configuration snapshot from the mapping table; Call OpenClaw's `AgentFactory` to instantiate an independent Agent execution context (including loading system prompt words, model clients, toolset references, and memory storage objects) based on the configuration snapshot. The standardized event object is serialized into the `AgentInput` message format defined by the OpenClaw framework and pushed into the input queue (`input_queue`) of the Agent instance.

[0070] The Agent instance then retrieves messages from the queue and enters the inference loop: deciding whether to retrieve the knowledge base, which skill to invoke, how to combine tools, etc., and finally generating a response or executing an operation. Throughout the process, the Agent instances for each channel are completely isolated in memory and storage, and do not interfere with each other.

[0071] The above embodiments fully demonstrate the entire process of implementing channel-customized agent initialization, differentiated configuration, runtime dynamic scheduling, and event injection based on the OpenClaw framework, fully reflecting the technical advantages of the present invention.

[0072] After a customer message is received with a channel identifier via multi-channel access and standardized event conversion step S1, in step S2, the system dynamically loads the Agent configuration corresponding to the target channel based on the channel identifier. The system prompts included in this Agent configuration are specifically tailored for that channel. For example, if the message comes from an instant messaging channel, the loaded Agent configuration will include a system prompt instructing the Agent to reply in a concise, conversational style using emojis. If the message comes from an email channel, the loaded Agent configuration will include a system prompt instructing the Agent to reply in a formal, written style following a structured reply template. This mechanism of loading channel-specific system prompts during Agent instantiation ensures that the Agent's generation logic fundamentally follows the interaction rules and user expectations of the corresponding channel during subsequent inference. This ensures that the Agent's output naturally adapts to the user group characteristics, interaction habits, and business rules of different channels, avoiding the awkwardness and misalignment that might result from post-processing adjustments after generating a generic reply. In this way, the Agent can output more natural and compliant responses from the source, thereby significantly improving the user interaction experience across different channels.

[0073] In an optional embodiment, an independent Agent instance is configured for each access channel using an Agent development framework. When a channel event arrives, the scheduler loads the corresponding Agent configuration based on the channel identifier in the event, instantiates the Agent execution context, and injects the standardized event into the Agent's input queue. If the independent Agent instance of the current channel determines that the customer's problem is beyond its own capabilities, it calls upon the expert Agent instance configured within the channel for collaborative processing, and achieves continuous dialogue through session context passing.

[0074] An Agent development framework is a software platform that provides standardized components, libraries, and toolsets to simplify the construction, deployment, and management of intelligent agents. It can include modules such as Agent templates, configuration management, lifecycle management, and communication mechanisms, abstracting the underlying complexity of Agent development and allowing developers to focus on the business logic implementation of the Agent. For example, customized development can be based on open-source Agent frameworks (such as OpenClaw, LangChain, and LlamaIndex), providing unified APIs and configuration interfaces to manage Agent instances from different channels; alternatively, enterprises can develop their own Agent development framework based on their business needs. This framework can include an Agent definition language, runtime environment, and monitoring tools to achieve highly customized Agent management. When a channel event arrives, the scheduler loads the corresponding Agent configuration based on the channel identifier in the event, instantiates the Agent execution context, and injects the standardized event into the Agent's input queue. The scheduler is the core component of the system, responsible for receiving standardized events from multi-channel communication modules and performing intelligent routing and Agent instance lifecycle management based on the channel identifier in the event. Its role is to ensure that each standardized event is correctly distributed to the corresponding independent Agent instance for processing. The scheduler can adopt an event-driven architecture, for example, by listening to the event stream in a message queue (such as Apache Kafka or RabbitMQ), and triggering the subsequent Agent loading and instantiation process when a new channel event is received; or, the scheduler can act as part of an API gateway, receiving external HTTP requests and forwarding them to the corresponding Agent service instance through a service discovery mechanism based on the channel identifier in the request header or request body. Loading the corresponding Agent configuration means that the scheduler retrieves and reads the running parameters and behavior definitions related to the Agent for that channel from a pre-set configuration store based on the received channel identifier. These configurations are the basis for Agent instantiation and determine the Agent's behavior pattern under a specific channel. The configuration can be stored in a distributed configuration center (such as Alibaba Nacos or HashiCorp Consul), which the scheduler dynamically retrieves by calling the configuration center's API; or, the configuration can be stored in a file system or object storage (such as Amazon S3) in the form of structured files (such as YAML or JSON format), which the scheduler reads on demand. Instantiating an Agent execution context refers to creating a separate and complete working environment for the Agent instance that is about to run. This context contains all the runtime information that the Agent needs to process the current event, such as the Agent's internal state, session history, current user ID, bound toolset references, and inference parameters.This instantiation can be done by creating an Agent object in a separate process or thread and initializing its internal state and dependencies; or by starting an Agent instance in a lightweight container (such as a Docker container), allocating it independent computing resources and an isolated runtime environment to ensure that different Agent instances do not interfere with each other.

[0075] Injecting standardized events into the Agent's input queue means that the scheduler places customer messages, after standardized format conversion, into a list of pending events maintained internally by a specific Agent instance. This mechanism allows the Agent to process received events asynchronously and sequentially, effectively handling sudden traffic surges and avoiding system overload. This input queue can be an in-memory queue (e.g., using Java's `BlockingQueue` or Python's `queue` module), with the Agent retrieving events from the head of the queue for processing; alternatively, it can be a lightweight message queue (such as Redis Streams or ZeroMQ), supporting distributed Agent deployment and more flexible event consumption patterns. If an independent Agent instance in the current channel determines that a customer problem is beyond its capabilities, it invokes an expert Agent instance configured within the channel for collaborative processing, achieving continuous dialogue through session context passing. Determining that a customer problem is beyond its capabilities is a key introspective capability of an independent Agent instance. The Agent assesses its ability to independently resolve the problem by analyzing the semantic content and complexity of the customer message, as well as its own configured knowledge base and toolset. This judgment can be based on a preset rule engine. For example, when a customer message contains specific keywords (such as "troubleshooting" or "advanced settings") or matches a predefined problem pattern, a judgment beyond its capabilities is triggered. Alternatively, the agent can integrate a lightweight intent recognition model or classification model to classify customer problems into "simple consultation", "complex fault", "expert help", etc. If the classification result points to a complex or professional problem, it is judged to be beyond its own capabilities.

[0076] The collaborative processing via an expert agent instance configured within the channel refers to an internal collaboration mechanism triggered when an independent agent instance determines its own capabilities are insufficient to resolve a customer's issue. This mechanism forwards the request to a pre-configured expert agent instance within the same channel, possessing more specialized knowledge or stronger processing capabilities. This ensures that the problem receives more professional handling without breaking channel isolation. Expert agents can act as sub-agents or plugins of regular agents, collaborating through internal API calls or inter-process communication (IPC) mechanisms. Alternatively, the scheduler can maintain an agent registry; when a regular agent issues a collaboration request, the scheduler routes the request to the corresponding expert agent service instance based on the channel identifier and problem type. Continuous dialogue through session context passing refers to the complete transmission of all relevant session data, including dialogue history, user state, identified intents, and collected information, between regular and expert agents throughout the collaborative processing process. This ensures that expert agents can seamlessly take over the dialogue without requiring users to repeatedly provide information, thus guaranteeing a continuous and smooth user experience. Session context can be encapsulated as structured data objects (such as JSON or Protocol Buffers) and transmitted via an internal message bus or remote procedure call (RPC); alternatively, session context can be stored in a shared, high-performance in-memory database (such as Redis), which agents access and update in real time using a unique session ID.

[0077] The following example illustrates this. Suppose an IoT device manufacturer's customer service system integrates three heterogeneous channels: WeChat Official Account, corporate email, and official website customer service. When a customer sends a message via WeChat Official Account, asking, "My smart lock cannot be unlocked remotely, indicating a network connection error. I need to check the device status and try to remotely restart it," first, the multi-channel communication module receives this WeChat message. The channel access gateway converts it into a standard event format, attaches a "WeChat" channel identifier, and extracts the user's unique identifier, mapping it to a globally unified customer ID. Next, the scheduler receives this standardized event. Based on the "WeChat" channel identifier in the event, the scheduler loads a preset WeChat channel Agent configuration from the configuration center. This configuration may include concise, conversational system prompts, a basic model optimized for WeChat scenarios, and a bound smart lock management toolset. Subsequently, the scheduler instantiates an independent WeChat Agent execution context and injects the standardized event into the WeChat Agent's input queue. The WeChat Agent retrieves the event from the queue and processes it. It analyzes customer messages and identifies keywords such as "smart door lock cannot be unlocked remotely," "network connection error," and "remote restart," concluding that this is a complex issue involving device fault diagnosis and remote operation, exceeding its basic consulting capabilities.

[0078] At this point, the WeChat Agent will not directly reply "Unable to handle," but will instead, based on its internal configuration, invoke a pre-defined "Smart Lock Expert Agent" instance within the WeChat channel for collaborative processing. During this invocation, the WeChat Agent will pass the complete context of the current session to the Smart Lock Expert Agent, including the customer's initial question, previous conversation history (if any), customer ID, and identified device type. Upon receiving the context, the Smart Lock Expert Agent can take over the conversation without requiring the customer to repeat their description. It may utilize its more specialized knowledge base (e.g., containing various lock fault codes and solutions) and more powerful toolset (e.g., directly calling IoT platform APIs to query device real-time status and send remote restart commands) to engage in continuous dialogue with the customer, guiding them through troubleshooting or directly performing remote operations to ultimately resolve the customer's smart lock problem.

[0079] Through the above technical solution, this application effectively solves the problems of unclear independent agent instance scheduling, insufficient ability to handle complex problems, and poor dialogue continuity in traditional solutions. By uniformly configuring and managing independent agent instances through the agent development framework, and combining the scheduler to dynamically load and instantiate agents based on channel identifiers, on-demand resource allocation and precise event routing are achieved, significantly improving system operating efficiency and response speed. More importantly, when an independent agent instance determines that a customer's problem is beyond its own capabilities, it can intelligently call upon expert agent instances configured within the channel for collaborative processing, and ensure dialogue continuity through seamless transmission of session context. This not only effectively improves the system's ability to handle complex and professional problems while maintaining channel isolation characteristics, preventing users from experiencing service interruptions due to unresolved issues, but also greatly optimizes the user experience, enabling customers to receive more professional and seamless after-sales service.

[0080] In an optional embodiment, in step S3, the isolated knowledge base is a vector knowledge base space independently configured for each channel, used to store knowledge documents specific to that channel; the isolated knowledge bases for different channels support customized document configurations based on the market region, product version, or policies and regulations served by that channel. Knowledge access permissions between different channels are restricted through namespace mechanisms or tenant identification mechanisms; wherein, the configuration of the isolated knowledge base includes: uploading documents by channel dimension, using an embedding model for vectorized indexing, and configuring retrieval algorithms and similarity thresholds.

[0081] This independent configuration ensures that the knowledge content from different channels is physically or logically isolated. Each channel's Agent instance can only access its own dedicated knowledge set, thus avoiding knowledge confusion and interference from irrelevant information, and guaranteeing the accuracy and professionalism of responses. For example, physical isolation can be achieved using independent database instances, independent storage buckets (such as S3bucket), or by partitioning independent tablespaces within the same database; or logical isolation can be achieved by adding channel identifiers to the knowledge base and filtering queries. Customized document configuration means that the knowledge content in the isolated knowledge base can be flexibly adjusted and optimized according to the service needs of specific channels. This means that the knowledge base is not only independent, but its content is also highly targeted, reflecting the user groups, business scenarios, and compliance requirements served by different channels. For example, channels targeting the European market can be configured with privacy policy documents compliant with GDPR (General Data Protection Regulation), while channels targeting the North American market can be configured with documents compliant with CCPA (California Consumer Privacy Act); or, for after-sales channels targeting specific product models, detailed user manuals and troubleshooting guides for that model can be configured. This customization capability ensures that when processing customer requests, the Agent can obtain the most relevant, accurate, and channel-specific knowledge. Namespace mechanisms, or tenant identification mechanisms, are access control strategies designed to enforce knowledge isolation at a logical level. Namespace mechanisms create an independent logical area for each channel within a shared storage or computing environment, ensuring that data and resources do not interfere with each other. Tenant identification mechanisms embed an identifier in data records, indicating which channel or tenant the data belongs to; all queries are automatically filtered using this identifier. These two mechanisms effectively prevent an agent instance from one channel from unauthorized accessing or mismanaging the knowledge base of other channels, thereby ensuring data security and compliance and avoiding unauthorized access to knowledge.

[0082] The configuration process for an isolated knowledge base is a crucial step in building and maintaining it. First, documents are uploaded by channel, emphasizing the channel specificity of the knowledge source. Documents can be in various formats, such as PDF, Word, Markdown, and HTML, covering content like product descriptions, FAQs, terms of service, and troubleshooting guides. Second, vectorized indexing is performed using an embedding model. Uploaded document content needs to be converted into high-dimensional vector representations using an embedding model (such as BERT, GPT-3's embedding API, Sentence-BERT, etc.). These vectors capture the semantic information of the text, making semantically similar texts closer together in the vector space. The establishment of a vectorized index is fundamental to achieving efficient semantic retrieval. Finally, the retrieval algorithm and similarity threshold are configured. The retrieval algorithm (such as Faiss, Annoy, HNSW, etc.) is used to quickly find the document vectors most similar to the query vector in the vector knowledge base. The similarity threshold is used to filter search results, ensuring that only sufficiently relevant knowledge content is returned. For example, cosine similarity can be configured as the retrieval algorithm, and a similarity threshold of 0.7 or 0.8 can be set to balance the recall and precision of the retrieval. These configuration parameters can be adjusted according to the knowledge characteristics and retrieval needs of different channels to optimize retrieval results.

[0083] The following example illustrates this. Suppose a company has customer service channels targeting three different market regions: China, the United States, and Europe, and offers two products, A and B. First, during the isolation knowledge base configuration phase, the company creates a separate vector knowledge base space for each channel (e.g., "China Channel," "US Channel," and "European Channel"). For the "China Channel" knowledge base, operations personnel upload documents such as product descriptions, after-sales policies, and frequently asked questions that comply with Chinese laws and regulations. For example, this includes relevant clauses of the Consumer Rights Protection Law and descriptions of the unique features of products A and B in the Chinese market. These documents are then vectorized using a pre-trained Chinese embedding model (e.g., a Chinese model based on ERNIE or BERT) and a vector index is built. The retrieval algorithm can be configured as a K-nearest neighbor search based on cosine similarity, with a similarity threshold set to 0.75. For the "US Channel" knowledge base, documents such as privacy policies that comply with US federal and state laws (e.g., CCPA), the specific version feature differences of products A and B in the US market, and local after-sales service procedures are uploaded. These documents are vectorized and indexed using an English embedding model (e.g., an English model based on RoBERTa or GPT-3). The retrieval algorithm can also be configured for cosine similarity, but the similarity threshold may be adjusted to 0.7 based on the query habits of US users. For the knowledge base of the "European channel," a GDPR-compliant privacy statement, EU CE certification documents, specific version features of Product A and Product B in the European market, and after-sales support documents in multiple languages ​​(e.g., English, German, French) will be uploaded. These documents are vectorized and indexed using a multilingual embedding model (e.g., XLM-R or LaBSE). The retrieval algorithm and similarity threshold will also be configured based on the characteristics of the European market. At runtime, when the independent Agent instance of the "China channel" receives a customer query about Product A, it will initiate a retrieval request only to the isolated knowledge base of the "China channel" based on its channel identifier. The system ensures that the Agent can only access knowledge content exclusive to the China channel through a namespace mechanism or tenant identification mechanism. For example, if a namespace mechanism is used, the agent's knowledge retrieval request will be routed to the namespace "cn_channel_kb" for querying. The vectorized customer query is then compared with the document vectors in the knowledge base, and knowledge fragments with a similarity higher than 0.75 are returned as inference context. Similarly, when the "US channel" agent receives a query, it will only access the isolated knowledge base of the "US channel" and obtain knowledge content tailored to the US market. This mechanism ensures that each channel's agent obtains the most relevant, accurate, and compliant knowledge, thereby providing highly customized services.

[0084] In other optional embodiments, in addition to similarity retrieval, the retrieval strategy can also be configured with hybrid retrieval (combining keywords and vectors), re-ranking (re-ranking the initial search results to improve relevance), and setting the number of Top-K results returned and the similarity threshold to balance the recall and precision of the retrieval.

[0085] Through the above technical solution, this application effectively addresses the problems of unclear implementation methods, inability to meet customized needs, and insufficient knowledge access security in traditional solutions regarding isolated knowledge bases. By defining the isolated knowledge base as a vector knowledge base space independently configured for each channel, and supporting customized document configuration based on market region, product version, or policies and regulations, each channel's Agent instance can obtain highly relevant, accurate knowledge content that conforms to its specific business rules and compliance requirements, greatly improving the accuracy and professionalism of responses. Simultaneously, by restricting knowledge access permissions between different channels through namespace mechanisms or tenant identification mechanisms, the risk of unauthorized access to knowledge is completely eliminated at the logical level, significantly enhancing the security and compliance of knowledge access. Furthermore, the clear configuration process, including uploading documents by channel dimension, using an embedding model for vectorized indexing, and configuring retrieval algorithms and similarity thresholds, simplifies the construction and maintenance of the knowledge base and allows for optimization of retrieval results based on channel characteristics, ensuring the efficiency and accuracy of knowledge retrieval. Combined with the architecture of independent Agent instances in the basic solution, this finely crafted isolated knowledge base design enables the entire distributed Agent system to provide a more personalized, secure, and efficient service experience when processing customer messages from heterogeneous channels.

[0086] Furthermore, in optional embodiments, this system also establishes a Skill Marketplace (Skill Repository), supporting Skill publishing, subscription, version updates, and canary releases. Different channels can flexibly select Skill combinations according to business needs and independently manage the lifecycle of Skills. Based on channel isolation, the system supports configuring cross-channel knowledge base federated retrieval strategies to handle complex problems requiring the integration of knowledge from multiple channels. During federated retrieval, cross-channel access permissions must be verified through an authorization mechanism, and multi-source retrieval results are merged as the inference context.

[0087] In an optional embodiment, in step S4, the execution logic of the Skill module includes at least one of the following: Atomic Skill: Directly calls the internal CLI command-line tool or API to complete a single customer service operation, including querying order status, resetting device password, creating work order, querying usage, or remotely activating device; Composite Skill: The workflow engine orchestrates the execution order, conditional branches, and exception handling of multiple atomic skills. LLM Skill: A text generation or analysis task autonomously completed by a large language model based on prompt word templates.

[0088] It should be noted that the knowledge base provides static factual knowledge for retrieval enhancement generation, while Skill encapsulates executable business logic to complete specific operations.

[0089] Specifically, an atomic skill is a basic and indivisible skill unit, its core being the execution of a single, clearly defined customer service action. This skill can be implemented by directly calling a pre-defined command-line interface (CLI tool) or application programming interface (API) within the system. For example, a CLI tool can be a script or program provided by the system to execute specific commands, while an API can be a RESTful API, RPC interface, or other form of programming interface used for data interaction or function calls with backend services. Atomic skills are designed to efficiently complete simple tasks such as querying database records, modifying system configurations, and triggering specific events.

[0090] Composite skills are a more advanced unit of skill, integrating and orchestrating multiple atomic skills to complete more complex, multi-step business processes. Their implementation relies on a workflow engine, which is responsible for defining and managing the execution order, conditional branches, and exception handling logic between atomic skills. Workflow engines can be implemented using various technologies, such as BPMN (Business Process Model and Symbol)-based process definitions, state machine models, or custom script orchestration frameworks. Through composite skills, a series of interrelated atomic operations can be combined into a complete business process, thereby automating the processing of complex customer requests.

[0091] An LLM Skill is a skill unit that leverages the capabilities of a Large Language Model (MLM). Its primary function is to autonomously complete text generation or analysis tasks based on a given prompt word template. This skill does not involve direct calls to external systems; instead, it fully utilizes the capabilities of the Large Language Model in natural language understanding, generation, summarization, and classification. The prompt word template is a pre-designed text structure used to provide the Large Language Model with task instructions, contextual information, and the desired output format, guiding the model to generate text content that meets the requirements or to perform text analysis.

[0092] When an Agent instance receives a customer message and combines it with relevant knowledge retrieved from the isolated knowledge base, it intelligently selects and invokes the most suitable Skill type based on the customer's intent and the current session context. For simple, direct customer requests, the Agent can quickly invoke atomic Skills to complete the operation through direct API or CLI tool calls, such as querying order status or resetting device passwords, thus achieving efficient response. For complex requests involving multiple steps and requiring logical judgment and process control, the Agent will invoke composite Skills, with the workflow engine coordinating the execution of multiple atomic Skills to ensure the correctness and integrity of the business process, such as handling device fault troubleshooting and deciding whether to create a work order based on the results. For tasks requiring natural language understanding, generation, or analysis, such as summarizing customer emails or drafting replies, the Agent will invoke LLM Skills, leveraging the powerful capabilities of the large language model to complete the task autonomously, without the need for pre-setting complex rules. This hierarchical and categorized execution logic allows the Agent to flexibly handle diverse business needs, from single operations to complex processes and even native text processing tasks from the large language model, effectively avoiding chaotic execution logic and enabling the orderly integration of new features. Meanwhile, by combining multi-channel runtime dynamic agent orchestration and scheduling with isolated knowledge base retrieval, each independent agent instance can configure and invoke customized skill combinations according to the characteristics and business rules of the channel it serves, thereby achieving channel-level differentiated services. For example, an agent for instant messaging channels may focus more on atomic skills for fast response, while an agent for email channels may make more use of LLM skills for understanding and generating long texts.

[0093] In an optional embodiment, the Skill module is configured as a reusable, real-time orchestrated independent functional unit, the definition of which may include: metadata, input parameter schema defined using JSON Schema, output schema, and fallback strategy, etc.

[0094] Its reusability means that the same Skill module can be invoked multiple times in different Agent instances, different business scenarios, or different channels without repeated development. Real-time orchestration refers to the ability of Skill modules to be dynamically combined, adjusted, or updated at runtime to adapt to changing business needs or Agent inference logic. This can be achieved through configuration centers, service registration and discovery mechanisms, or workflow engines. Independent functional units emphasize that Skill modules have clear boundaries and single responsibilities. They do not depend on the core logic of the Agent but serve as external services that the Agent can invoke. This can be achieved through microservice architecture, Function as a Service (FaaS), or plug-in design.

[0095] In this embodiment, metadata describes the attributes of the Skill module itself, such as the Skill's name, function description, version number, author, scope of application, and tags. This information helps the system and developers better understand and manage the Skill module. The input parameter schema is defined using JSON Schema. JSON Schema, a standard for defining JSON data structures based on JSON format, explicitly specifies the name, data type, required status, value range, and default value of each parameter. This ensures that the Agent provides compliant input when calling the Skill and supports automated parameter validation. The output schema defines the data structure of the results returned after successful Skill module execution, clarifying the fields, types, and meanings of the return values. This allows the Agent to correctly parse and utilize the Skill's execution results, which can also be implemented using JSON Schema or other structured data definition languages. The fallback strategy refers to the pre-defined handling scheme that the system should take when the Skill module fails, times out, or encounters other abnormal situations. This can include retry mechanisms, degradation schemes, or transferring to human customer service.

[0096] In this embodiment, updating the Skill module does not require modification of the core code; it can be deployed simply by configuring and binding it to the toolset of the target Agent. This means that the business logic of the Skill module is decoupled from the core code of the Agent platform. Updating, adding, or deleting a Skill will not affect the code of core components such as the Agent scheduler and message processing. This can be achieved by deploying the Skill as an independent service, loading it through a plugin mechanism, or executing it via dynamic scripts. The registration, binding, and updating of the Skill module are mainly accomplished by modifying configuration files, database records, or the configuration management interface, rather than through code compilation and deployment. During inference, the Agent parses the name and parameters of the required Skill, calls the execution engine to obtain the results, and then integrates the results into the inference context for further processing or directly converts them into response content.

[0097] During inference, the agent parses the name and parameters of the required skill. Based on the current session context and user intent, the agent identifies the skill module to be invoked and its required input parameters. The agent then calls an execution engine to obtain the result. Once the agent determines the skill and parameters to be invoked, it passes this information to a skill execution engine. This engine is responsible for actually invoking the corresponding service or executing the relevant logic according to the skill's definition and awaits the return result. The result is then integrated into the inference context for further processing. After successful skill execution, the returned result is received by the agent and added as new information to the current inference context. The agent can use this new information for further inference, decision-making, or to generate a more accurate response. In some cases, the skill's execution result can be directly converted into a response to the user.

[0098] The above technical solution configures the Skill module as a reusable, real-time orchestrated independent functional unit, clearly defining it including metadata, input / output schema, and fallback strategy. This highly decouples the Skill module from the Agent's core logic. This solves the problem of traditional solutions where Skill functionality is tightly coupled with core code, requiring modifications to the core code when adding or adjusting Skill functionality, resulting in long development and deployment cycles and potential impacts on system stability. Specifically, Skill modules can be defined and bound without modifying the core code, significantly improving the system's responsiveness and flexibility to business changes, and reducing the cost and risk of feature iteration. During inference, the Agent can parse the required Skill name and parameters according to standardized definitions and call the execution engine to obtain results, ensuring the accuracy and reliability of Skill calls. Simultaneously, integrating the results into the inference context or directly converting them into response content allows the Agent to more intelligently utilize Skill capabilities, providing more accurate and efficient services. Furthermore, the introduction of fallback strategies significantly enhances the system's robustness. When Skill execution fails, the system can retry, downgrade, or transfer to human intervention according to preset strategies, effectively avoiding service interruptions and improving user experience. This modular and configurable design allows agents from different channels to flexibly bind and orchestrate the required skill sets according to their specific business needs and user interaction habits, thereby achieving highly customized and differentiated service capabilities and further improving the overall performance and maintainability of the distributed agent system for heterogeneous channels.

[0099] Furthermore, fallback strategies may include: retrying when Skill execution fails, downgrade options, and transferring to human customer service.

[0100] Retry refers to the system automatically attempting to execute a Skill module again after its initial failure. This can be used to handle transient errors, such as network jitter, temporary unavailability of external services, or momentary resource shortages. The retry mechanism can be configured with the number of retries, retry intervals, and retry strategies (such as exponential backoff). Retrying can effectively improve the success rate of Skill module execution and prevent service interruptions due to occasional problems. Degradation solutions refer to alternative or simplified handling methods provided by the system when a Skill module fails and the retry mechanism fails to recover. Degradation solutions may include providing users with preset fallback responses, guiding users to try other self-service options, providing partial functionality instead of full functionality, or providing a simplified alternative process. The aim is to still provide valuable information or services to users when a complete or ideal operation cannot be completed, maintaining the continuity of the conversation and avoiding direct service interruption or immediate transfer to human assistance. Transfer to human customer service means that when a Skill module fails and neither retries nor degradation solutions can effectively resolve the issue, the system seamlessly transfers the current session to a human customer service representative for handling. This can occur in scenarios where the problem is complex, exceeds the agent's autonomous processing capabilities, or requires human intervention. The human customer service mechanism ensures that users can still obtain a final solution when automated services cannot meet their needs, thus guaranteeing the final service quality and user satisfaction.

[0101] As a specific implementation, imagine an Agent instance handling a customer's request to "query order status," which requires invoking an atomic Skill called `QueryOrderStatus`. This Skill interacts with an external order system via an API interface. When a customer message arrives, the Agent parses the intent and decides to invoke the `QueryOrderStatus` Skill. The Skill execution engine attempts to invoke this Skill. Suppose that on the first invocation, the Skill execution fails due to a momentary timeout in the external order system's API interface. At this point, the retry mechanism in the fallback strategy is activated. The system will automatically re-invoke the `QueryOrderStatus` Skill according to a preset configuration (e.g., 3 retries, each with a 5-second interval). If the second invocation succeeds, the Agent will retrieve the order status and generate a response; the entire process is seamless for the user, and the service continues. If, after 3 retries, the `QueryOrderStatus` Skill still fails to execute successfully due to a persistent failure in the external system, the retry mechanism is exhausted, and the system will trigger a fallback mechanism. The degradation strategy can be configured as follows: The Agent replies to the user, "Sorry, the order query system is currently busy and we are unable to check your order status at this time. You can try again later or call our customer service hotline for assistance." Simultaneously, the system may record this degradation event for later analysis. This approach avoids direct service interruption and provides users with an alternative. If, after the degradation strategy is triggered, the user still finds it unacceptable, or the degradation strategy itself does not provide sufficient information (e.g., the user urgently needs a solution and the degradation strategy cannot provide an effective alternative), or the system determines that the current problem is beyond the scope of automated processing (e.g., a serious external system failure requiring human intervention), a transfer to a human customer service representative will be triggered. In this case, the Agent will package the complete context of the current session (including the customer's original request, the Agent's reasoning process, the Skill's execution failure logs, and attempted retries and degradations) and seamlessly transfer the call to a human customer service representative. The human representative can immediately view all relevant information, thus efficiently taking over and resolving the customer's problem.

[0102] Through the above technical solutions, this application introduces a layered and progressive fallback strategy during the execution of the Skill module, effectively solving the problem of service interruption or unnecessary transfer to human agents when Skill execution fails. Specifically, the retry mechanism can automatically recover from occasional and transient Skill execution failures, significantly improving the success rate and efficiency of automated services, reducing service interruptions caused by temporary problems, and thus ensuring the continuity of user experience. The degradation scheme provides an intelligent alternative service when retries fail, avoiding direct service interruption or immediate transfer to human agents when the target operation cannot be completed, effectively balancing service quality and operating costs, and ensuring that the Agent can still provide valuable feedback when some functions are limited. Finally, transferring to human customer service as a fallback strategy ensures that when the automated service cannot solve the problem, the user's problem can be properly handled by a human, thereby guaranteeing the final service quality and user satisfaction. This layered fallback strategy, combined with the characteristic of the Skill module as an independent functional unit, gives the Agent strong fault tolerance when calling the Skill module to execute atomic Skills, composite Skills, or LLM Skills. It not only improves the execution reliability of individual Skill modules, but more importantly, in the distributed Agent isolation and orchestration method for heterogeneous channels, it ensures that Agent instances can provide stable, efficient and user-friendly automated services when processing customer messages from different channels, even in the face of complex external system interactions or uncertainties. This avoids the rigidity or interruption of the entire service process due to Skill execution failure, thereby significantly enhancing the robustness and availability of the entire intelligent customer service system.

[0103] To achieve the above objectives, this application also provides a distributed agent isolation and orchestration system for heterogeneous channels, wherein implementing the method as described in any of the preceding embodiments includes: A multi-channel communication module is used to establish connections with at least two heterogeneous messaging channels, receive customer messages, and send replies. Intelligent customer service platform, the platform includes: The channel access gateway is used to convert the message protocols of various heterogeneous channels into a standard event format, attach a corresponding channel identifier to each standard event, and extract the user's unique identifier and map it to a globally unified customer ID. Multiple independent Agent instances, with at least one independent Agent instance corresponding to each access channel. Each Agent instance has independently configured system prompt words, basic models, toolset bindings, memory strategies, and inference parameters. Multiple isolated knowledge bases, with each channel corresponding to an independent vector knowledge base space, used to store knowledge documents specific to that channel; The Skill execution engine is used to store and execute multiple reusable Skill modules, each Skill module being an independently encapsulated service function unit. The scheduler is used to load the corresponding Agent instance according to the channel identifier in the standard event, inject the standardized event into the Agent input queue, and receive Skill call requests initiated by the Agent instance. After the Skill execution engine completes the operation, it returns the result. The channel access gateway is also used to adapt the response content generated by the Agent instance to the message format requirements of the target channel, and then send it back to the client through the multi-channel communication module.

[0104] As a specific implementation, this solution designs a four-dimensional architecture of channel-agent-knowledge base-skill, as follows: Channel access layer: Establish standardized adaptation interfaces to achieve unified access and protocol conversion of messages across all channels, and normalize the message formats, user identity systems and session mechanisms of different channels into a standard event stream; Agent Orchestration Layer: Based on the OpenClaw framework, a customized AI Agent is deployed independently for each channel. Each Agent has an independent System Prompt, inference strategy, toolset configuration, and memory context to realize channel-level differentiated service personality and decision logic; Knowledge base configuration layer: Each channel can be configured with its own dedicated knowledge base, supporting document uploads, vector indexing, retrieval strategies and permission isolation by channel, ensuring that the Agent can only access knowledge content within the authorized scope of that channel; Skill Orchestration Layer: After-sales service capabilities are encapsulated into reusable and orchestratable Skill modules. Each Skill defines input parameters, execution steps, exception handling, and output format. Agents combine Skills as needed through a tool calling mechanism to complete complex after-sales tasks.

[0105] In such Figure 2In the illustrated embodiment, the overall system interaction logic is as follows: Customers initiate customer feedback through various heterogeneous channels, and these customer messages are uniformly integrated into the multi-platform communication (multi-channel communication module); the multi-channel communication module transfers customer messages to the intelligent customer service system (intelligent customer service platform); the intelligent customer service platform connects to the knowledge base (isolated knowledge base) on the one hand, retrieves channel-specific knowledge content to support intelligent response reasoning, and on the other hand, connects to the after-sales skill (Skill execution engine), receives business capability call instructions from its own platform CLI (Command-Line Interface), and completes the corresponding after-sales business operations; the response content output by the intelligent customer service platform is adapted by the multi-channel communication module and then sent back to the corresponding heterogeneous channel. At the same time, the intelligent customer service platform can deposit the business interaction process into the knowledge base to achieve iterative knowledge updates.

[0106] In the knowledge processing stage, each channel corresponds to an independent vector knowledge base space. Independent Agent instances only access the isolated knowledge base corresponding to the channel identifier, retrieving channel-specific knowledge documents as inference context. For example, the isolated knowledge base for instant messaging channels stores IoT device activation guidelines, while the isolated knowledge base for email channels stores product warranty policies, thus avoiding compliance risks caused by knowledge misuse. When an Agent instance recognizes the need to perform an external operation, it sends a request to the Skill execution engine through the scheduler, calling independently encapsulated service function units—Skill modules—to complete the specific business. The Skill execution engine stores and executes multiple reusable Skill modules, such as device activation or eSIM remote configuration modules, enabling modular orchestration and expansion of business capabilities. After the operation result is returned, the channel access gateway adapts the format of the response content generated by the Agent instance according to the message format requirements of the target channel (such as adding emojis to instant messaging or generating HTML format for emails), and sends it back to the client through the multi-channel communication module.

[0107] Through the above technical solution, the system achieves end-to-end channel-level isolation and customization from message access to result feedback. Channel identification runs through the entire event processing lifecycle, ensuring that each stage can dynamically match exclusive resources based on channel characteristics; the combination of independent Agent instances and isolated knowledge bases solves the problem of unauthorized access to knowledge, meeting the compliance requirements of different channels; the independent encapsulation of the Skill module and the coordination mechanism of the scheduler enable the system to autonomously execute device operations, forming a complete service loop of "requirement identification - instruction execution - result feedback". Compared with existing technologies, this solution not only adapts to the interaction differences of heterogeneous channels, but also significantly improves the system's scalability through modular design, enabling rapid deployment of new after-sales scenarios without refactoring the core architecture.

[0108] In an optional embodiment, the aforementioned isolated knowledge base may include: a knowledge space isolation unit, used to isolate knowledge base access permissions corresponding to different channels based on a namespace mechanism or a tenant identification mechanism; and a semantic retrieval unit, used to retrieve knowledge content related to customer messages based on vectorized indexes and semantic similarity.

[0109] The knowledge space isolation unit is responsible for logically or physically dividing and managing knowledge storage areas for different channels to ensure the independence and security of knowledge across channels. This unit protects the exclusivity and compliance of knowledge by preventing improper data isolation or unauthorized access between different channels. As a specific implementation, an independent namespace can be created for each channel in a database, file system, or distributed storage. All knowledge data related to that channel is stored under this namespace, and access to specific namespaces is restricted through access control lists or role-based access control. Furthermore, each channel can be assigned a unique tenant identifier, with all knowledge data associated with this identifier. During data access, the system automatically filters and isolates data based on the currently accessing channel's tenant identifier, ensuring that only data belonging to that channel can be accessed.

[0110] The semantic retrieval unit is responsible for performing semantic analysis on customer messages and searching for the most semantically relevant knowledge content in an isolated knowledge base. This unit aims to improve the accuracy and efficiency of knowledge retrieval, providing the agent with high-quality reasoning context. Specifically, document content in the knowledge base can be converted into high-dimensional vectors using a pre-trained embedding model, and a vector index can be built. When a customer message is received, it is similarly converted into a vector, and then the most similar knowledge vector is quickly retrieved from the index using vector similarity calculation. Alternatively, this unit can combine keyword matching and semantic understanding techniques. First, keyword matching is performed to narrow down the search scope. Then, deep semantic analysis is conducted on the matched documents to calculate their semantic similarity to the customer message, and the most relevant results are returned based on the similarity ranking.

[0111] This application's solution refines the isolated knowledge base into knowledge space isolation units and semantic retrieval units, enabling the distributed agent isolation and orchestration method for heterogeneous channels to achieve higher security, accuracy, and efficiency at the knowledge management level. When customer messages from a specific channel are standardized and tagged with channel identifiers, the corresponding independent agent instance, when responding to customer messages and needing to access the knowledge base, first utilizes the knowledge space isolation unit. This unit, based on a pre-defined namespace mechanism or tenant identifier mechanism, strictly restricts agent instances to accessing only the isolated knowledge base space corresponding to their channel identifier. This mechanism prevents cross-access and unauthorized behavior of knowledge between different channels, ensuring the independence and data compliance of each channel's proprietary knowledge. Once an agent instance is authorized to access its proprietary knowledge space, the semantic retrieval unit begins operation. It utilizes pre-built vectorized indexes and semantic similarity algorithms to perform deep semantic analysis of customer messages and efficiently and accurately retrieves the knowledge content most semantically relevant to the customer message within the isolated knowledge space. This retrieved knowledge content is then provided as a reasoning context to the agent instance, enabling the agent to reason and respond based on accurate and interference-free channel-specific knowledge. This collaborative working mechanism not only ensures strict isolation of knowledge from different channels and effectively solves the problem of knowledge access security, but also significantly improves the accuracy and efficiency of knowledge retrieval through the introduction of semantic retrieval, ensuring that the Agent can provide high-quality services that conform to the characteristics of each channel in multi-channel scenarios.

[0112] Other specific implementation methods have been described in detail above and will not be repeated here.

[0113] To achieve the above objectives, the present invention also provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor runs the program, it can implement the steps of the distributed agent isolation and orchestration method for heterogeneous channels as described in any of the foregoing embodiments.

[0114] Processors and memory can be configured separately or integrated together, for example, integrated into a system-on-chip (SOC) of the terminal device.

[0115] To achieve the above objectives, the present invention also provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when processed and executed, implement the previously described method for distributed agent isolation and orchestration for heterogeneous channels.

[0116] The computer-readable storage medium is, for example, memory. Memory can be volatile or non-volatile, or it can include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM).

[0117] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0118] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A distributed agent isolation and orchestration method for heterogeneous channels, characterized in that, Includes the following steps: Step S1: Multi-channel access and standardized event conversion; Receive customer messages from multiple heterogeneous channels, convert the message protocols of each heterogeneous channel into a standardized event format, and attach a corresponding channel identifier to each standardized event; The heterogeneous channels include at least one of the following: instant messaging channels, email channels, web-based customer service channels, SMS channels, and enterprise collaborative office channels; Step S2: Multi-channel runtime dynamic agent orchestration and scheduling; pre-configure independent agent instances for each access channel, dynamically load the agent configuration corresponding to the target channel according to the channel identifier, and instantiate the corresponding agent execution context; wherein, the independent agent configuration corresponding to different channels includes at least one or more of the following: system prompt words, basic model, toolset binding, memory strategy, and inference parameters; Step S3: Isolation knowledge base retrieval; The independent Agent instance responds to customer messages by accessing only the isolation knowledge base corresponding to the channel identifier to retrieve knowledge content related to the customer messages as inference context. Different channels correspond to different isolation knowledge bases. Step S4: Skill orchestration and execution; During the inference process, the Agent instance calls the corresponding Skill module to execute the target operation, wherein the Skill module is an independently encapsulated service function unit; Step S5: Result adaptation and feedback; Based on the inference results of the Agent instance and the execution results of the Skill module, generate reply content, adapt it to the message format requirements of the target channel, and then feedback it to the corresponding client.

2. The distributed agent isolation and orchestration method for heterogeneous channels according to claim 1, characterized in that, Step S1 further includes: extracting the user's unique identifier from the messages of each heterogeneous channel, mapping it to a globally unified customer ID, and establishing a cross-channel session association based on the unified customer ID; when the same customer initiates a request on different channels, the unified customer ID is used to associate its historical session context.

3. The distributed agent isolation and orchestration method for heterogeneous channels according to claim 1, characterized in that, In step S2, the system prompts for different channels are configured differently to adapt to the user group characteristics, interaction habits and business rules of different channels; among them, the system prompts for instant messaging channels are configured with a concise and colloquial style and an emoji usage strategy, while the system prompts for email channels are configured with a formal written style and a structured reply template.

4. The distributed agent isolation and orchestration method for heterogeneous channels according to claim 3, characterized in that, The Agent development framework configures an independent Agent instance for each access channel. When a channel event arrives, the scheduler loads the corresponding Agent configuration based on the channel identifier in the event, instantiates the Agent execution context, and injects the standardized event into the Agent's input queue. If the independent Agent instance of the current channel determines that the customer's problem is beyond its own capabilities, it calls upon the expert Agent instance configured within the channel to handle the problem collaboratively, and achieves continuous dialogue through the transmission of session context.

5. The distributed agent isolation and orchestration method for heterogeneous channels according to claim 1, characterized in that, In step S3, the isolated knowledge base is a vector knowledge base space configured independently for each channel, used to store knowledge documents specific to that channel; the isolated knowledge bases of different channels support customized document configuration according to the market area, product version or policies and regulations served by that channel; Access permissions for knowledge between different channels are restricted through namespace mechanisms or tenant identification mechanisms; wherein, the configuration of the isolated knowledge base includes: uploading documents by channel dimension, using the Embedding model for vectorized indexing, and configuring retrieval algorithms and similarity thresholds.

6. The distributed agent isolation and orchestration method for heterogeneous channels according to claim 1, characterized in that, In step S4, the execution logic of the Skill module includes at least one of the following: Atomic Skill: Directly calls the internal CLI command-line tool or API to complete a single customer service operation, including querying order status, resetting device password, creating work order, querying usage, or remotely activating device; Composite Skill: The workflow engine orchestrates the execution order, conditional branches, and exception handling of multiple atomic skills. LLM Skill: A text generation or analysis task autonomously completed by a large language model based on prompt word templates.

7. The distributed agent isolation and orchestration method for heterogeneous channels according to claim 6, characterized in that, The Skill module is configured as a reusable, real-time orchestration-enabled independent functional unit, and its definition includes at least: metadata, input parameter schema defined using JSON Schema, output schema, and fallback strategy; Updating the Skill module requires no modification to the core code; it can be deployed simply by configuring and binding the toolset to the target Agent. During inference, the Agent parses the name and parameters of the required Skill, calls the execution engine to obtain the results, and then integrates the results into the inference context for further processing or directly converts them into response content.

8. The distributed agent isolation and orchestration method for heterogeneous channels according to claim 7, characterized in that, The fallback strategy includes: retrying when Skill execution fails, a downgrade plan, and transferring to human customer service.

9. A distributed agent isolation and orchestration system for heterogeneous channels, characterized in that, Implementing the method as described in any one of claims 1 to 8, comprising: A multi-channel communication module is used to establish connections with at least two heterogeneous messaging channels, receive customer messages, and send replies. Intelligent customer service platform, the platform includes: The channel access gateway is used to convert the message protocols of various heterogeneous channels into a standard event format, attach a corresponding channel identifier to each standard event, and extract the user's unique identifier and map it to a globally unified customer ID. Multiple independent Agent instances, with at least one independent Agent instance corresponding to each access channel. Each Agent instance has independently configured system prompt words, basic models, toolset bindings, memory strategies, and inference parameters. Multiple isolated knowledge bases, with each channel corresponding to an independent vector knowledge base space, used to store knowledge documents specific to that channel; The Skill execution engine is used to store and execute multiple reusable Skill modules, each Skill module being an independently encapsulated service function unit. The scheduler is used to load the corresponding Agent instance according to the channel identifier in the standard event, inject the standardized event into the Agent input queue, and receive Skill call requests initiated by the Agent instance. After the Skill execution engine completes the operation, it returns the result. The channel access gateway is also used to adapt the response content generated by the Agent instance to the message format requirements of the target channel, and then send it back to the client through the multi-channel communication module.

10. The distributed agent isolation and orchestration system for heterogeneous channels according to claim 9, characterized in that, The isolation knowledge base includes: Knowledge space isolation units are used to isolate knowledge base access permissions for different channels based on namespace mechanisms or tenant identification mechanisms. The semantic retrieval unit is used to retrieve knowledge content related to customer messages based on vectorized indexes and semantic similarity.

Images