Instant messaging bot conversation and workspace decoupled routing method and system

Abstract

This invention belongs to the field of communication technology and discloses a method and system for decoupling the session and workspace routing of an instant messaging robot. The method includes: configuring a session key template and a workspace key template for each instant messaging channel; receiving message callback requests pushed by the instant messaging platform through a platform adapter; parsing the message callback requests to obtain structured messages and extracting context variables from the messages; obtaining a session identifier; obtaining a sandbox identifier; using the message, session identifier, and sandbox identifier as input, performing iterative reasoning using an agent, outputting streaming processing results, and using a message merging mechanism to buffer and merge the streaming processing results, pushing the merged results to the instant messaging platform. This invention breaks the technical limitation of the strong binding between session key templates and workspace key templates in traditional solutions by configuring mutually independent session key templates and workspace key templates.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method and system for decoupling the conversation and workspace of an instant messaging robot. Background Technology

[0002] With the rapid development of Large Language Model (LLM) technology, AI agents, acting as messaging robots integrated into instant messaging (IM) platforms, have become an important vehicle for improving enterprise collaboration efficiency. In practical applications, a single AI agent often needs to simultaneously handle complex environments with multiple users and multiple group chats. In this multi-tenant scenario, accurately maintaining each user's dialogue history (contextual memory) and isolating or sharing file execution environments (sandboxing) have become core indicators for measuring the service quality of AI agents.

[0003] Currently, mainstream IM bot development frameworks, such as Microsoft Bot Framework, Google Dialogflow, Rasa Open Source, and the official SDKs of major IM platforms, generally adopt a single dimension for session state management to isolate session states. These frameworks typically only support defining state boundaries based on a single dimension, either "user (sender_id)" or "session / group chat (chat_id)". When AI agents are deeply integrated with large language models, the states that need to be maintained include not only dialogue memory but also the file workspace (i.e., sandbox) required for execution tools and scripts. The granularity of sharing dialogue memory and workspace varies significantly across different product forms.

[0004] To ensure data security, existing technologies employ a "one-to-one binding of sessions and sandboxes" scheme. For example, the sandbox-LLM session bidirectional binding mechanism disclosed in patent application CN120723618A addresses this by establishing a distributed binding table between each large language model session identifier and a sandbox instance identifier, with the initial state being bound. This aims to prevent message interference between different sessions. However, in this exclusive binding mode, a sandbox always serves only one session and cannot be shared by multiple sessions, making it difficult to support scenarios requiring multiple sessions to access the same execution environment. In summary, existing technologies have the following shortcomings: First, single-dimensional state isolation cannot simultaneously satisfy two typical product models. In the personal assistant model, it is expected that the same user can share conversation memories across different group chats (e.g., background information introduced in group chat A can still be referenced in group chat B) and personal file workspace. In the team workspace model, it is expected that all members of the same group chat can share the file system and execution environment for collaboration. For example, a script uploaded by member A can be directly run by member B, but the conversation context of each member should remain independent to avoid crosstalk between replies. Existing single-dimensional isolation solutions can only choose one of these two models: if the user is the isolation dimension, the ability to share and collaborate as a team will be lost; if the group chat is the isolation dimension, the continuity of personal memory across group chats will be interrupted.

[0005] Second, adding new product forms requires modifying the source code. When a new product form needs to be introduced, such as the "enterprise single workspace" form, where the entire organization shares the same knowledge base and execution environment, but each member's dialogue remains independent, the existing robot system must hard-code the corresponding routing logic in the code, which cannot be flexibly implemented through configuration. This results in a version release and system redeployment being required for each new business form.

[0006] Third, there is redundant development in adapting to multiple instant messaging platforms. For each new instant messaging platform (such as Lark, DingTalk, WeChat, Telegram, etc.), developers need to reimplement the chatbot's conversation routing and state management logic for that platform. The core routing and isolation mechanisms cannot be reused across platforms, resulting in redundant investment of development resources and high maintenance costs.

[0007] Fourth, the streaming output of large models leads to frequent fragmented push notifications. When large language models generate response content in a streaming manner, they continuously produce multiple text fragments. If each fragment is pushed to the instant messaging platform in real time, it will generate a large number of dense short messages, which will not only reduce the user's reading experience, but also significantly increase the load and pressure on the push service.

[0008] Therefore, how to provide a routing method and system for decoupling the conversation and workspace of instant messaging robots is an urgent problem to be solved. Summary of the Invention

[0009] This invention provides a method and system for decoupling the session and workspace of an instant messaging robot to solve the aforementioned technical problems in the prior art.

[0010] According to a first aspect of the present invention, a method for decoupling the session and workspace routing of an instant messaging robot is provided.

[0011] In one embodiment, an instant messaging robot's session and workspace decoupling routing method includes: Configure a session key template and a workspace key template for each instant messaging channel. Receive message callback requests pushed by the instant messaging platform through the platform adapter. Parse the message callback requests to obtain structured messages and extract context variables from the messages. Based on the session key template and context variables, the key parsing function is called to generate the session key in order to obtain the session identifier; By combining the workspace key template, context variables, and session identifier, the key parsing function is called to generate the workspace key in order to obtain the sandbox identifier. Taking messages, session identifiers, and sandbox identifiers as inputs, the agent performs loop reasoning and outputs streaming processing results. The message merging mechanism is used to buffer and merge the streaming processing results, and the merged results are pushed to the instant messaging platform to achieve decoupled routing of the instant messaging robot's session and workspace.

[0012] According to a second aspect of the present invention, a session and workspace decoupling routing system for an instant messaging robot is provided.

[0013] In one embodiment, the instant messaging robot's session and workspace decoupling routing system includes: The configuration and extraction module is used to configure session key templates and workspace key templates for each instant messaging channel. It receives message callback requests pushed by the instant messaging platform through the platform adapter, parses the message callback requests to obtain structured messages, and extracts context variables from the messages. The session identifier acquisition module is used to generate a session key by calling the key parsing function based on the session key template and context variables, in order to obtain the session identifier; The sandbox identifier acquisition module is used to combine the workspace key template, context variables, and session identifier to call the key parsing function to generate a workspace key in order to obtain the sandbox identifier. The reasoning and push module takes messages, session identifiers, and sandbox identifiers as inputs, uses the agent to perform cyclical reasoning, outputs streaming processing results, and uses a message merging mechanism to buffer and merge the streaming processing results, and pushes the merged results to the instant messaging platform to achieve decoupling routing between the instant messaging robot's session and workspace.

[0014] According to a third aspect of the present invention, a computer device is provided.

[0015] In some embodiments, the computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method described above.

[0016] According to a fourth aspect of the present invention, a computer-readable storage medium is provided.

[0017] In one embodiment, a computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the above method.

[0018] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: 1. This invention separates the granularity of dialogue history sharing and the granularity of execution environment sharing into two completely independent configurable dimensions by configuring mutually independent session key templates and workspace key templates. This breaks the technical limitation of the strong binding between the two in traditional solutions. The sharing rules can be flexibly configured by combining different placeholders, and it can fully cover various instant messaging robot product forms such as personal, team, and group chat.

[0019] 2. This invention completely abstracts the differences between different product forms into differences in key template configuration. Product form switching and expansion can be completed without modifying the core routing logic code. Only the key template configuration of the corresponding channel needs to be added or modified in the database, which shortens the product iteration cycle and reduces code maintenance costs and launch risks.

[0020] 3. This invention completely encapsulates the platform-related message receiving, parsing, and sending logic in a lightweight platform adapter layer. The core routing, key parsing, state management, agent reasoning, message merging, and other general logic are independent of the specific instant messaging platform. When using an instant messaging platform, only the corresponding platform adapter needs to be implemented, which reduces the development workload of the platform.

[0021] 4. This invention adopts a dual-timer message merging mechanism that combines soft triggering and hard triggering. This not only ensures the real-time nature of message push but also avoids message delays in extreme cases. It can intelligently merge multiple streaming fragmented messages generated by a large language model into a complete message before pushing it, thereby reducing the frequency of message pushes and reducing the call pressure on the instant messaging platform interface.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0024] Figure 1 This is a flowchart illustrating an exemplary embodiment; Figure 2 This is a principle block diagram illustrated according to an exemplary embodiment; Figure 3 This is a schematic diagram of a system structure according to an exemplary embodiment; Figure 4 This is a flowchart illustrating a routing method according to an exemplary embodiment; Figure 5 This is a timing diagram illustrating a message merging mechanism according to an exemplary embodiment; Figure 6 This is a flowchart illustrating the coordination loop according to an exemplary embodiment. Detailed Implementation

[0025] The following description and accompanying drawings fully illustrate specific embodiments described herein to enable those skilled in the art to practice them. Some portions and features of certain embodiments may be included in or replace portions and features of other embodiments. The scope of the embodiments herein includes the entire scope of the claims and all available equivalents thereof. The various embodiments described herein are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments; similar or identical parts between embodiments can be referred to interchangeably.

[0026] The modules in the apparatus or system of this application can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0027] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0028] Figure 1 An embodiment of the session and workspace decoupling routing method for the instant messaging robot of the present invention is shown.

[0029] In this optional embodiment, the instant messaging robot's session and workspace decoupling routing method includes: Step S101: Configure a session key template and a workspace key template for each instant messaging channel; receive message callback requests pushed by the instant messaging platform through the platform adapter; parse the message callback requests to obtain structured messages; and extract context variables from the messages. Step S102: Based on the session key template and context variables, call the key parsing function to generate a session key in order to obtain the session identifier; Step S103: Combine the workspace key template, context variables, and session identifier, call the key parsing function to generate the workspace key in order to obtain the sandbox identifier; Step S104: The message, session identifier, and sandbox identifier are taken as input. The agent performs loop reasoning and outputs the streaming processing result. The message merging mechanism is used to buffer and merge the streaming processing result. The merged result is pushed to the instant messaging platform to achieve decoupling routing between the instant messaging robot's session and workspace.

[0030] In this optional embodiment, extracting context variables from the message includes: Parse the message request body to obtain message metadata, and read the sender identifier and group chat identifier assigned to the message by the instant messaging platform from the message metadata; The routing layer determines the instant messaging channel to which the message belongs based on the message's access path and injects the corresponding channel identifier; By combining the sender identifier, group chat identifier, and channel identifier, a context variable containing multiple fields is constructed.

[0031] In this optional embodiment, based on the session key template and context variables, a key resolution function is called to generate a session key to obtain the session identifier, including: The session key template is used as the input template, and the context variable is used as the input parameter. The key parsing function is called to replace the strings in the input template in a preset order to generate the session key. Use the session key as the query key to query the session mapping table in the preset database; If a session mapping relationship is found, the corresponding session identifier is extracted; if no session mapping relationship is found, a universally unique identifier is generated as a new session identifier, and the session mapping table is updated through insertion technology to complete the acquisition of the session identifier.

[0032] In this optional embodiment, by combining the workspace key template, context variables, and session identifier, a key resolution function is called to generate a workspace key to obtain the sandbox identifier, including: The context variables and session identifiers are merged to generate a context dictionary; Using the workspace key template as the input template and the context dictionary as the input parameter, the key parsing function is called to replace the strings in the input template in a preset order to generate the workspace key; Use the workspace key as the query key to query the workspace sandbox mapping table in the preset database; If a workspace sandbox mapping relationship is found and the sandbox is alive, the corresponding sandbox identifier is extracted. If no workspace sandbox mapping relationship is found or the sandbox is alive, the sandbox allocation service is called to create a new sandbox and the workspace sandbox mapping table is updated using insertion technology to complete the acquisition of the sandbox identifier.

[0033] In this optional embodiment, when multiple concurrent requests create sandboxes for the same workspace at the same time, the later-arriving request will retrieve the existing sandbox identifier from the preset database and call the workspace sandbox mapping table to reclaim the sandbox allocated in this request.

[0034] In this alternative embodiment, the messages in the input agent do not contain extracted context variables.

[0035] In this optional embodiment, the process involves using an intelligent agent to perform loop reasoning, outputting streaming processing results, and employing a message merging mechanism to buffer and merge the streaming processing results before pushing the merged results to an instant messaging platform. After receiving the message, session identifier, and sandbox identifier, the intelligent agent calls the preset large language model to perform an inference loop until the inference loop meets the preset termination condition and outputs the streaming processing result. The streaming results are added to the message buffer of the corresponding session, and soft-trigger timers and hard-trigger timers are started simultaneously. When any trigger timer expires, a refresh operation is triggered, merging all messages in the message buffer according to preset rules, and pushing the merged result to the instant messaging platform.

[0036] In this optional embodiment, a preset large language model is invoked for inference loop until the inference loop meets a preset termination condition, and the output streaming processing results include: Based on the session identifier, the corresponding historical session is read from the preset session state storage, and the historical session is merged with the message to generate a message sequence; Instantiate a separate agent state object for the message callback request and write the message processing context into the agent state object; Based on the writing results, the agent calls the large language model to perform an inference loop and outputs the inference results. If the inference result contains a tool call request, the tool call request is sent to the sandbox endpoint corresponding to the sandbox identifier via the remote procedure call protocol for execution, and the execution result is sent back to the large language model as an observation for the next round of inference; If the inference result does not contain a tool call request, the inference loop terminates and the corresponding streaming result is output.

[0037] In this optional embodiment, the agent invokes a large language model to perform an inference loop, and the output inference results include: The message sequence is serialized according to the Open AI Chat Completion Protocol format, and combined with the tool description of the agent registration, the model parameters in the version configuration, and the application interface key injected by the platform to complete the configuration of the large language model; Send a Hypertext Transfer Protocol request to the configured large language model endpoint, and receive the large language model response via an event stream sent by the server. Read each data frame in the sent event stream and aggregate them frame by frame to obtain the inference results.

[0038] In this optional embodiment, if a new message arrives while the soft-trigger timer is in the timing state, the timing period of the soft-trigger timer is reset.

[0039] Figure 2 An embodiment of the session and workspace decoupling routing system for the instant messaging robot of the present invention is shown.

[0040] In this optional embodiment, the instant messaging robot's session and workspace decoupling routing system includes: The configuration and extraction module 201 is used to configure the session key template and workspace key template for each instant messaging channel, receive message callback requests pushed by the instant messaging platform through the platform adapter, parse the message callback requests to obtain structured messages, and extract context variables from the messages. The session identifier acquisition module 202 is used to generate a session key by calling the key parsing function based on the session key template and context variables, so as to obtain the session identifier; The sandbox identifier acquisition module 203 is used to combine the workspace key template, context variables and session identifier, call the key parsing function to generate the workspace key, and obtain the sandbox identifier. The reasoning and push module 204 is used to take messages, session identifiers and sandbox identifiers as inputs, use the agent to perform cyclic reasoning, output streaming processing results, and use a message merging mechanism to buffer and merge the streaming processing results, and push the merged results to the instant messaging platform to realize the decoupling routing of the instant messaging robot's session and workspace.

[0041] To facilitate understanding of the above technical solutions of the present invention, the following further explains the above technical solutions of the present invention from the perspective of architecture and principle, as follows: like Figure 4As shown, this invention decouples the granularity of dialogue history sharing and the granularity of workspace sharing into two independent configurable dimensions, and configures them with templated key expressions. It supports a single gateway to serve multiple product forms without modifying the code. At the same time, it reduces fragmented push through message merging mechanism and realizes dynamic activation of configuration through coordination loop mechanism. In particular, this invention realizes a many-to-one (m:n) binding relationship between session_id and workspace_id, that is, multiple session_ids can be bound to the same workspace_id and share the underlying execution environment (sandbox). Based on this m:n relationship, it can flexibly support the following product forms: (1) Personal assistant form: The same user maintains independent dialogue history across multiple group chats, but shares the same file workspace to achieve state continuity; (2) Team workspace form: Multiple members in the same group chat share the same file workspace for collaboration, but each member maintains an independent dialogue context; (3) Enterprise single workspace form: All members in the organization share the same knowledge base and execution environment, but individual dialogues are independent. This m:n relationship is the core innovation of this invention, which is completely opposite to the existing one-to-one binding scheme in terms of design philosophy.

[0042] Step 1: Pre-configure two independent key template fields for each IM channel. The session_key_tpl controls the granularity of sharing conversation history, and the workspace_key_tpl controls the granularity of sharing the execution environment. Both templates consist of strings and support four placeholders: {sender_id}, {chat_id}, {channel_id}, and {session_id}.

[0043] Step 2: Receive messages from the IM platform and extract three context variables—sender_id, chat_id, and channel_id—from the message metadata. Specifically, the process of extracting context variables from message metadata is as follows: 2.1 The platform adapter receives message callback requests pushed by the IM platform (HTTP POST or long connection events) and parses the request body (JSON format or platform-specific format); 2.2 Read the sender_id field from the parsing result (the sender identifier provided by the IM platform for each message, such as Lark open_id or WeChat openid); 2.3 Read the chat_id field from the parsing result (the session or group chat identifier provided by the IM platform for each message); 2.4 Inject the channel_id (i.e., "which robot channel received this message") from the IM channel configuration of the current message, which is automatically determined by the routing layer based on the message callback path or callback signature); 2.5 The three context variables constitute dict{sender_id, chat_id, channel_id}, which serves as the input parameter for the subsequent key parsing engine.

[0044] Step 3: Using session_key_tpl as a template and the three context variables mentioned above as input parameters, call the key parsing function to obtain session_key. The key parsing function performs four replacements on the input template string, replacing one type of placeholder with the corresponding context variable value each time. The specific implementation of the key parsing function is sequential string replacement: the function accepts the template string tpl and the context variable dictionary ctx as input parameters, and initializes the result string result=tpl; it scans the four placeholders ({sender_id}, {chat_id}, {channel_id}, {session_id}) in a fixed order, replacing all occurrences of each placeholder in result with the corresponding string value in ctx at once; after the replacement is completed, it returns result as the parsing result. Example: tpl="{sender_id}:{chat_id}", ctx={sender_id:"ou_alice",chat_id:"oc_devops"}, after being replaced in sequence, result="ou_alice:oc_devops"; because the placeholders are replaced in a fixed order, the replacement result of the template is deterministic (same input, same output).

[0045] Step 4: Query the session mapping store using the session_key to obtain the session_id; if the mapping does not exist, create a new session_id and record the mapping relationship. Specifically, the process of retrieving session_id from session mapping storage using session_key is as follows: 4.1. Initiate a SELECT query on the sessions table (a PostgreSQL relational table) using session_key as the query key. The query statement is in the form of SELECT session_id FROM sessions WHERE session_key=$1 LIMIT 1, using prepared parameters to avoid SQL injection; 4.2. If 1 row is returned, take its session_id field value as the result; 4.3. If 0 rows are returned, generate a new session_id (using the UUIDv4 algorithm to ensure global uniqueness), and write it back to the database using INSERT...ON CONFLICT(session_key)DO NOTHING RETURNING session_id; this upsert semantics ensures that when multiple concurrent requests create session_id for the same session_key, only one row is actually inserted, and the remaining requests SELECT the same row to return results, avoiding distributed locks; 4.4. If INSERT returns 0 rows due to primary key conflict, re-initiate the SELECT in step 4.1 to retrieve the existing session_id.

[0046] Step 5: Using `workspace_key_tpl` as a template, and the three context variables mentioned above and `session_id` obtained in Step 4 as input parameters, call the key parsing function to obtain `workspace_key`. The process of calling the key parsing function to obtain `workspace_key` using `workspace_key_tpl` as a template in Step 5 is as follows: 5.1. Merge the three context variables extracted in Step 2 with the `session_id` obtained in Step 4 into a dictionary `ctx_with_sid`, i.e., `ctx_with_sid = {sender_id, chat_id, channel_id, session_id}`; 5.2. Call the same key parsing function defined in Step 3 above, using `workspace_key_tpl` and `ctx_with_sid` as input parameters; 5.3. The function sequentially scans the four placeholders ({sender_id}, {chat_id}, {channel_id}, {session_id}) in the `workspace_key_tpl` string and replaces them with the corresponding string values ​​from `ctx_with_sid`; 5.4. The string returned after the replacement is `workspace_key`. Example: tpl="ws_{channel_id}_{sender_id}", ctx_with_sid={channel_id:"fb_lark",sender_id:"ou_alice",...}, the parsed result is "ws_fb_lark_ou_alice"; this step reuses the same function from step 3, the only difference being that the input parameter dictionary additionally carries session_id to support product forms that share workspaces at the session level.

[0047] Step 6: Query the sandbox mapping storage using workspace_key to obtain sandbox_id; if the mapping does not exist, request the sandbox allocation service to create a new sandbox and record the mapping relationship. Specifically, the process of retrieving the sandbox_id from the sandbox mapping storage using workspace_key is as follows: 6.1. Initiate a SELECT query on the workspace_sandbox table using workspace_key as the query key. The query statement is in the form of SELECT sandbox_id, is_alive FROM workspace_sandbox WHERE workspace_key=$1 LIMIT 1; 6.2. If 1 row is returned and is_alive=true, then take the sandbox_id field value as the result; 6.3. If 0 rows are returned or is_alive=false (the sandbox has been reclaimed), initiate an AllocateSandbox(workspace_id, template_id) call to the sandbox allocation service, wait for the sandbox_id to be returned, and then write it back to the workspace_sandbox table via INSERT...ON CONFLICT(workspace_key)DO UPDATE SET sandbox_id=EXCLUDED.sandbox_id,is_alive=true; 6.4. If concurrent requests enter step 6.3 simultaneously, the later request will be processed in the database ON... The CONFLICT branch retrieves the existing sandbox_id and simultaneously calls ReleaseSandbox to reclaim the redundantly allocated sandbox instance, thus avoiding waste of sandbox resources due to concurrency.

[0048] Step 7: Pass the message content along with the session_id and sandbox_id obtained in Steps 4 and 6 to the agent runtime for processing. The specific process of message processing by the agent in step 7 is as follows: 7.1 After receiving the request, the Runtime reads the dialogue history from the session state storage based on the passed session_id and parses it into a message sequence; 7.2 Within the process, the Runtime instantiates an independent request-level agent state object for this request by the Agent SDK, and writes the message sequence, message content, sandbox_id, streaming output callback function, etc. into this object. Other concurrent requests within the same process each hold an independent request-level agent state object; 7.3 The Runtime enters the agent loop, calling the large language model API in each round to obtain the inference result; if the result contains a tool call instruction, the Runtime sends the tool call request to the sandbox endpoint corresponding to the sandbox_id for execution through the sandbox daemon gRPC protocol, and the execution result is returned to the LLM as an observation; 7.4 If the LLM returns a final natural language response without a tool call in a certain round, the loop terminates, and the Runtime proceeds to step 8 for streaming merging and pushing. In this step, "message content" refers to the original incoming message (message body text, excluding the sender_id, chat_id, and channel_id metadata extracted in step 2) received and parsed by the platform adapter from the IM platform. The two refer to the same thing.

[0049] Step 8: The streaming output generated during the operation of the intelligent agent is processed by the message merging module and then pushed to the IM platform; for example... Figure 5 As shown, the message merging steps include: 8.1 After receiving a message, add it to the message buffer corresponding to the session, and start the soft trigger timer T_soft (default 2000 milliseconds) and the hard trigger timer T_hard (default 10000 milliseconds); 8.2 If a new message arrives during the soft trigger timer, reset T_soft; 8.3 Either T_soft or T_hard timeout triggers a flush operation; 8.4 The flush operation merges all messages in the buffer into one message: if there is only one message, return directly; if multiple messages come from the same sender, concatenate them with a newline character; if they come from different senders, add the [sender identifier]: prefix to each message before concatenation; 8.5 The merged message is pushed to the IM platform.

[0050] Among them, sender_id refers to the unique identifier of the message sender (i.e., the IM platform user), abbreviated as sender identifier; chat_id refers to the unique identifier of the session or group chat, abbreviated as group chat identifier; channel_id refers to the unique identifier of the IM channel instance, abbreviated as channel identifier; session_id refers to the internal identifier of the dialogue history session within this system, abbreviated as session identifier; session_key_tpl refers to the session affinity template string, abbreviated as session affinity template (session key template); workspace_key_tpl refers to the workspace affinity template string, abbreviated as workspace affinity template (workspace key template); sandbox_id refers to the unique identifier of the sandbox instance, abbreviated as sandbox identifier; flush refers to the buffer data emptying operation; reconcile (coordination loop) refers to the process of periodically reconciling the running state with the configuration state and correcting the differences.

[0051] It should be noted that the key parsing engine receives a template string (tpl) and context variables (sender_id, chat_id, channel_id, session_id), and outputs the parsed key string. The specific steps are as follows: It receives the template string tpl (from the session_key_tpl or workspace_key_tpl field of the im_channels table) and four context variables; it performs string placeholder replacements on tpl in the following order: replacing "{sender_id}" with the actual value of sender_id; replacing "{chat_id}" with the actual value of chat_id; replacing "{channel_id}" with the actual value of channel_id; replacing "{session_id}" with the actual value of session_id. The replacements are performed in a fixed order, nested placeholders are not supported, and conditional expressions are not supported. The replacement results are used directly as the key without URL encoding or other conversions; the parsed key string is returned for subsequent queries on session_to_workspace_store or workspace_to_sandbox_store. Example: tpl="{sender_id}_{chat_id}", sender_id="u001", chat_id="g002", the parsed result is "u001_g002".

[0052] The Agent Loop is the main loop that drives the agent to execute after the Runtime receives an IM message. The specific steps are as follows: Initialization: Load the dialogue history (a list of historical user / assistant / tool ​​messages) corresponding to the session_id from the session state storage, and combine it with the current user message to form the current message sequence. Assemble the LLM request: Serialize the current message sequence according to the OpenAI Chat Completions protocol format: the messages field contains the list of historical messages and the current user message; the tools field contains the tool descriptions registered by the current agent (each item includes name, description, and parameters in JSON Schema format); model / temperature / max_tokens come from the version configuration; and the Authorization header carries the LLM API Key injected by the platform. Call the Large Language Model API: The Runtime sends an HTTP POST request to the configured LLM endpoint (base_url / chat / completions) and receives the response in a streaming manner using Server-Sent Events (SSE). Parse the LLM response: Read and aggregate each data frame in the SSE stream. If the finish_reason of the response is "stop", extract choices[0].delta.content to accumulate the assistant message for this round, append it to the dialogue history, and the loop ends. If the finish_reason is "tool_calls", extract the tool_calls array, each item containing {id, function:{name, arguments}}. Execute the tool: Call each tool in tool_calls, query the tool registry by name, deserialize arguments (JSON string) into a parameter dictionary, and send the tool execution request to the sandbox endpoint corresponding to sandbox_id through the sandbox daemon gRPC protocol to obtain the execution result. Append the tool result: Append the execution result of each tool to the dialogue history in the format {role:"tool",tool_call_id:id,content:result}, return to assemble the LLM request, and enter the next round of inference until finish_reason is "stop" or the maximum number of loops is reached. Persistence: After the agent loop ends, the newly added messages (user messages, assistant messages, tool messages) in this round are incrementally appended to the session state storage, thus completing the state persistence.

[0053] The sandbox command execution daemon is a gRPC service running within the sandbox Pod (listening on port 49983). The runtime sends tool call requests to the sandbox through the following steps: Establishing a connection: The runtime retrieves the sandbox daemon endpoint (format: http(s): / / {sandbox_domain}:49983; the scheme can be http or https depending on the deployment configuration; https is used when terminated via ingressTLS in production, and http is used for direct connections within the cluster) and access token (access_token, a sandbox-level access token generated by SandboxManager when allocating the sandbox (bound to sandbox_id, reused throughout the sandbox's lifecycle)) from the request-level agent state object. Authentication: An Authorization:Bearer{access_token} header is appended to the gRPC connection metadata. The sandbox daemon server verifies the token's validity, binding the token to the sandbox_id. If verification fails, a UNAUTHENTICATED error is returned. The `Process.StartRPC` method is called. The `Process` service of the sandbox command execution daemon provides the `Start(StartRequest) → streamStartResponseRPC` method. The `Runtime` constructs `StartRequest`: `ProcessConfig.cmd` is the path to the executable command, `ProcessConfig.args` is the list of command arguments, `ProcessConfig.envs` is the environment variable key-value pairs required for tool execution, and `ProcessConfig.cwd` is the working directory. Output is received in a streaming manner. The sandbox command execution daemon returns stdout / stderr data frames of the process in a streaming manner (each frame contains byte content and an output type identifier). The `Runtime` aggregates all frames until it receives the process exit code frame (containing the `exit_code` field). The result is returned. If `exit_code` is 0, the aggregated stdout content is returned to the agent loop as the tool execution result; if `exit_code` is not 0, the stderr content is returned as the tool execution error information, and the agent loop decides whether to retry or report an error.

[0054] like Figure 6As shown, at the beginning of each cycle, the coordination loop reads all channel records with enabled=true from the configuration store (im_channels database table). The steps to derive the desired state mapping are as follows: Execute the SQL query SELECT * FROM im_channels WHERE enabled=true to obtain the list of channel configurations to be run (desired_list). For each record in desired_list, construct a hash map (desired_map:Map) using channel_id as the key.<channel_id,ChannelConfig> For each record in `desired_map`, calculate the channel's configuration hash (`config_hash`). The calculation method is as follows: concatenate the channel's six fields: `platform` (platform type string), `platform_config` (serialized using `.to_string()`), `environment_id`, `memory_context`, `access_key`, and `secret_key`, and then use the Rust standard library's `DefaultHasher` to calculate a 64-bit hash value. The `config_hash` is only stored in the service process's running map (`DashMap`) and is not persisted to the database. The coordination loop recalculates the hash value for the data loaded from the database each round; if it differs from the `config_hash` in memory, the channel configuration is considered to have changed. Extract the key set (`desired_ids`: Set) from `desired_map`.<channel_id> ), and the current memory running table (running:Map)<channel_id,ChannelHandle> By comparing the key sets, three types of difference sets are obtained.

[0055] The coordination loop identifies three types of discrepancies by comparing desired_ids (the set of channel IDs expected to run) and running_ids (the set of channel IDs currently running in memory): 1. New channels (the difference between desired_ids and running_ids): Identification criteria: If the `channel_id` exists in `desired_ids` but not in `running_ids`, it indicates that the channel is newly configured and has not yet been started. Handling method: Start an independent asynchronous task for this channel. Specifically, in the Rust asynchronous runtime (tokio), call `tokio::spawn` to create a background `Future`. This `Future` continuously runs the platform adapter's main loop (receiving IM platform messages, calling the `Runtime`, and replying to messages). `tokio::spawn` returns a `JoinHandle`, from which the `AbortHandle` (termination handle) is extracted and stored along with the `config_hash` in the `running` memory mapping (`running.insert(channel_id, ChannelHandle{abort_handle, config_hash})`).

[0056] 2. Delete the channel (the difference between running_ids and desired_ids): Identification criteria: If the channel_id exists in running_ids but not in desired_ids, it indicates that the channel has been disabled or deleted. Handling method: Retrieve the corresponding ChannelHandle from running, call its abort_handle.abort() method to send a cancellation signal to the asynchronous task of that channel (Tokio's Abort mechanism). The task exits after receiving the cancellation at the next await point. Then, remove the channel_id from the running mapping and update the channel's status field in the database to "stopped".

[0057] 3. Change channel (running_ids∩desired_ids and config_hash are inconsistent): Identification condition: The channel_id exists in both running_ids and desired_ids, but the config_hash stored in running is not equal to the new config_hash calculated in desired_map, indicating that the channel's configuration (such as platform key, environment configuration, etc.) has been updated. Handling method: First, perform a deletion operation (abort the old task, remove it from running), then perform an addition operation (spawn a new task, store the new config_hash in running), achieving an in-place restart of the channel (restarttask). The brief message loss during restart is an acceptable cost of eventual consistency, which can be compensated for by the IM platform's message retransmission mechanism.

[0058] Step 1 of this invention is the configuration phase, which strictly precedes any of the execution steps 2 through 8 in terms of timing. Its output (two template strings, session_key_tpl and workspace_key_tpl) is written into the channel configuration storage, providing input for key parsing in steps 3 and 5. The three context variables extracted in step 2 (sender_id, chat_id, channel_id) are simultaneously used as input parameters for key parsing in steps 3 and 5. Step 3 only uses the first three (source information related to the session), while step 5 additionally carries the session_id generated in step 4 on top of the first three (to support the form of shared workspace at the session level). The session_key generated in step 3 and the workspace_key generated in step 5 are conceptually independent and can be generated by two independent key parsing function calls, reflecting the core proposition of two shared granularities that are independently configurable. Steps 4 (session mapping query / creation) and 6 (workspace mapping query / creation) The execution of steps 4, 5, and 6 consists of two independent branches that can be executed sequentially or in parallel. At the data storage layer, upsert semantics ensure idempotency. Step 6's input depends on step 5, and step 5's input depends on step 4 (because the workspace_key expression may contain {session_id}). Therefore, there is a strict order relationship between steps 4, 5, and 6. Step 7 is the convergence point of steps 4 and 6: it carries both session_id (the location of the conversation history) and sandbox_id (the location of the execution environment) as input parameters to the Runtime. The Runtime loads the conversation history according to these two parameters and routes the tool to the sandbox. Step 8 (streaming merge push) is nested with step 7 (Runtime processing) in sequence: when the Runtime generates streaming segments in the loop, each segment is processed by the merging module in step 8 before being pushed to the IM platform. The overall sequence of steps forms a directed data stream of configuration, metadata extraction, dual-key parsing, dual-mapping query, convergence forwarding, and streaming merge push. The dependencies between steps cannot be arbitrarily changed.

[0059] By designing two independent key templates (session_key_tpl and workspace_key_tpl) in step 1, the problem that single-dimensional isolation cannot simultaneously satisfy two typical product forms is solved: since the two templates can be independently configured as any combination of {sender_id}, {chat_id}, and {channel_id}, multiple product forms such as personal assistant form (session_key_tpl={sender_id}), team workspace form (session_key_tpl={chat_id}, workspace_key_tpl={channel_id}), and enterprise single workspace form (session_key_tpl={sender_id}, workspace_key_tpl={channel_id}) can be supported by the same set of gateway services at the same time. By using `session_key_tpl` and `workspace_key_tpl` as database configuration items, and coordinating a loop to detect configuration changes and automatically restart channel tasks every `T_reconcile` cycle, the problem of needing to modify source code for product form expansion is solved: operations and maintenance personnel only need to modify the template field values ​​in the database and mark the enabled status. This invention can complete the configuration and take effect within 10 seconds by default, without redeployment or service restart. By decoupling the core routing logic (key parsing, session / sandbox mapping query, message merging) from the IM platform protocol into platform-independent modules, the platform adapter only needs to implement two interfaces: message receiving and message sending. This solves the problem of repetitive development for multi-IM platform adaptation: the development workload of adding a new IM platform is reduced by about 80% compared to building an independent robot service from scratch, and bug fixes for the core routing logic can automatically benefit all platforms. The message merging mechanism in step 8 (soft-triggered T_soft debouncing and hard-triggered T_hard upper limit) solves the problem of frequent fragmented pushes caused by streaming output of large models: In typical dialogue scenarios, 3 to 10 fragmented messages generated by streaming output are merged into one complete message before being pushed, reducing the push frequency by 30% to 60%. At the same time, the hard-triggered T_hard upper limit ensures that active group chats will not be indefinitely delayed due to continuous new messages. Through a coordinated loop incremental start-stop mechanism (based on config_hash comparison), channel configuration changes are automatically applied without restarting the entire service, demonstrating cloud-native deployment friendliness. By introducing the {session_id} placeholder in the key template, more granular isolation strategies such as single session single sandbox can be further supported within the same channel, preserving scalability for future product form expansion.By configuring session_key_tpl and workspace_key_tpl independently, this invention achieves a many-to-one (m:n) binding between session_id and workspace_id, meaning that multiple session_ids can be bound to the same workspace_id and share the same sandbox. This m:n relationship is completely opposite in design philosophy to the existing one-to-one binding scheme. The former seeks exclusivity to prevent packet cross-referencing, while this invention seeks sharing for collaboration, and the technical effects are also completely different. The m:n relationship of this invention is the foundation for supporting product forms such as multi-user shared IM group workspaces, cross-terminal personal assistants, and team workspaces.

[0060] In addition, the instant messaging robot's session and workspace decoupling routing system specifically includes: a channel management module, a platform adapter, a key parsing engine, a message buffer, session mapping storage, and a sandbox mapping storage. The channel management module reads channel configurations from the configuration storage and performs incremental start / stop operations through a coordination loop. The platform adapter adapts protocols for different IM platforms. The key parsing engine receives template strings and context variables and returns the replaced key string. The message buffer maintains an independent message queue for each session and merges them based on soft / hard trigger timers. The session mapping storage persists the mapping from session_key to session_id. The sandbox mapping storage persists the mapping from workspace_key to sandbox_id.

[0061] The channel management module operates in a coordinated loop mode; the platform adapter supports at least one instant messaging platform such as Lark, DingTalk, WeChat, and Telegram; the key parsing engine supports four placeholders: {sender_id}, {chat_id}, {channel_id}, and {session_id}. The channel management module, platform adapter, key parsing engine, message buffer, session mapping storage, and sandbox mapping storage are the physical execution carriers of steps 1 to 8; conversely, the sequence of method steps (key template configuration, message reception, key parsing, mapping query, runtime forwarding, and message merging) determines the collaboration sequence and data flow of each component in the system.

[0062] The channel management module employs a coordinated cyclical approach, with the following steps: Reconciliation operations are performed cyclically at a fixed interval of T_reconcile (default 10 seconds); the configurations of all currently enabled channels are read from the configuration storage to obtain the desired state map (desired_map); the current running state map (running_map) is compared with the desired_map to identify three types of differences: newly added channels, deleted channels, and configuration changes; an independent asynchronous task is started for newly added channels; the task for deleted channels is terminated by calling the termination handle; the task for changed channels is restarted; and each channel's independent task is responsible for establishing a long connection with the IM platform and periodically reporting its heartbeat status. `session_key_tpl` and `workspace_key_tpl` can be the same or different; the value range of `T_soft` is 500 milliseconds to 5000 milliseconds, the value range of `T_hard` is 2000 milliseconds to 30000 milliseconds, and the value range of `T_reconcile` is 5 seconds to 60 seconds. In product scenarios where multiple sessions share the same workspace (i.e., the m:n binding collaboration scenario described in steps 5 to 7), this invention deliberately avoids introducing session-level mutex locks or waiting queue mechanisms at the workspace layer. The design choice adopted is to decentralize the handling of concurrency conflicts to the tool layer, where each specific tool handles conflicts independently according to its semantics. For example, file writing tools use file system-level advisory locks, database writing tools use optimistic concurrency control (CAS / version number), and state modification tools use idempotent design or precondition checks. This design choice is based on the following technical trade-offs: First, locking at the workspace layer forces multiple sessions within the same workspace to execute serially, directly degrading the concurrency capabilities of collaborative scenarios and negating the core benefits of shared workspaces; Second, the waiting latency of session-level locks significantly impacts the human-computer collaboration experience (a tool call in one session may block the entire response chain of another session), while tool-level conflict handling only applies to resources that actually conflict and does not affect unrelated concurrency; Third, tool-level handling can adopt the most appropriate strategy (strong consistency / eventual consistency / idempotency) based on the semantic differences of different tools, while workspace-level locks can only adopt a one-size-fits-all pessimistic strategy; Fourth, the file system semantics within the workspace of this invention are similar to a team-shared project directory, which is consistent with the design judgment that concurrency should be the norm rather than an anomaly in collaborative scenarios. Therefore, concurrency handling should be undertaken by the resource holder (tool) rather than the session scheduler (routing layer).

[0063] like Figure 3As shown, the system of this invention includes the following components and their connections: Instant Messaging Platform 1: an external IM platform, such as Lark, DingTalk, WeChat, Telegram, etc.; Platform Adapter 2: connected to Instant Messaging Platform 1, converting platform-specific message protocols into standard message objects; Channel Management Module 3: connected to Configuration Storage 8, coordinating and managing the lifecycle of multiple Platform Adapters 2; Key Parsing Engine 4: receiving template strings and context variables, and returning the replaced key; Message Buffer 5: each session maintains an independent buffer, connected to Key Parsing Engine 4; Session Mapping Storage 6: persisting the mapping from session_key to session_id; Sandbox Mapping Storage 7: persisting the mapping from workspace_key to sandbox_id; Configuration Storage 8: storing all channel configurations, such as the database im_channels table; Agent Runtime 9: externally dependent Agent execution service, receiving merged messages and processing them. The data flow relationship of each component is as follows: the message is converted into a standard message from the instant messaging platform 1 through the platform adapter 2 and then handed over to the key parsing engine 4. The session_id and sandbox_id are then obtained by querying the session mapping storage 6 and sandbox mapping storage 7, and then submitted to the agent runtime 9 along with the message.

[0064] The database table structure of this invention is shown in the following example: im_channels table fields: `channel_id` is a VARCHAR(64) primary key, a unique identifier for the channel. platform VARCHAR(32), the platform type can be feishu / telegram / dingtalk / wechat, etc.; session_key_tpl VARCHAR(255), session affinity template, defaults to '{sender_id}'; workspace_key_tpl VARCHAR(255), workspace affinity template, defaults to '{sender_id}'; Enabled BOOLEAN; created_at TIMESTAMP; updated_at TIMESTAMP.

[0065] Fields in the channel_sandboxes table: channel_id VARCHAR(64); workspace_key VARCHAR(255); sandbox_id VARCHAR(64); Composite primary key (channel_id, workspace_key).

[0066] Fields in the channel_sessions table (optional, or can be shared with the global sessions table): channel_id VARCHAR(64); session_key VARCHAR(255); session_id VARCHAR(64); Composite primary key (channel_id, session_key).

[0067] The pseudocode example of the key parsing engine of this invention is as follows: function resolve_key_tpl(tpl,sender_id,chat_id,channel_id,session_id): result=tpl result=result.replace('{sender_id}',sender_id) result=result.replace('{chat_id}',chat_id) result=result.replace('{channel_id}',channel_id) result=result.replace('{session_id}',session_id) return result The following is an example of the pseudocode for message merging in this invention: function on_message_received(msg): buffer=get_or_create_buffer(msg.session_key) buffer.append(msg) if buffer.soft_timer is None or buffer.soft_timer.active: buffer.soft_timer.reset(2000) if buffer.hard_timer is None: buffer.hard_timer.start(10000) function on_timer_fired(buffer): messages=buffer.drain() merged=merge_messages(messages) forward_to_agent(merged) function merge_messages(messages): if len(messages) == 1: return messages[0] senders=set(m.sender for m in messages) if len(senders) == 1: return newline_join([m.text for m in messages]) else: return newline_join([f"[{m.sender}]: {m.text}" for m in messages])。

[0068] The pseudo-code example of the coordination loop of the present invention is as follows: function reconcile_loop(): while True: desired=load_enabled_channels_from_db() running=get_running_handles() for channel_id,config in desired.items(): if channel_id not in running: handle=spawn_channel_task(config) running[channel_id]=handle else: if running[channel_id].config_hash != config.hash: running[channel_id].abort() handle=spawn_channel_task(config) running[channel_id]=handle for channel_id in list(running.keys()): if channel_id not in desired: running[channel_id].abort() del running[channel_id] sleep(10).

[0069] Example 1, Personal Assistant Mode: A company deploys an AI agent as a Lark robot to serve approximately 1,000 employees. The channel configuration is platform=feishu, session_key_tpl='{sender_id}', and workspace_key_tpl='{sender_id}'.

[0070] Scenario 1: Employee Alice (sender_id=ou_alice) asks the bot "What changes have been made to the Kubernetes cluster recently?" in the "Technical Discussion" group (chat_id=chat_tech). The system executes the following steps: Step 1: Extract sender_id=ou_alice, chat_id=chat_tech, and channel_id=channel_xyz from the message; Step 2: resolve_key_tpl('{sender_id}',ou_alice,chat_tech,channel_xyz,null) returns 'ou_alice'; Step 3: Query with session_key='ou_alice' and find that the mapping session_id=sess_001 already exists, so continue using it; Step 4: The workspace_key also returns 'ou_alice', and the sandbox_id=sbx_001 is found; Step 5: The message, along with sess_001 and sbx_001, is submitted to the agent's runtime; Step 6: The agent's reply is appended to Alice's session history.

[0071] Scenario 2: Alice then asked in the "Product Feedback" group (chat_id=chat_product) "What is the reason for that change?" Since the session_key is still calculated as 'ou_alice', the sess_001 session is reused, and the agent can understand in the existing context that "that change" refers to the change in the K8s cluster.

[0072] Example 2, Team Workspace Format: A research and development team of 10 people forms a "DevOps Automation" group, with the channel configuration as platform=feishu, session_key_tpl='{chat_id}', and workspace_key_tpl='{channel_id}'.

[0073] Scenario: Member Alice uploads the deploy.sh script to the group and requests the bot to save it; the system calculates session_key='chat_devops' (shared conversation throughout the group) and workspace_key='channel_devops_bot' (shared sandbox throughout the channel); the bot saves the file to / workspace / deploy.sh in the sandbox sbx_devops; later, member Bob requests "run deploy.sh" in the same group. Since the session_key is still 'chat_devops' (shared conversation history) and the workspace_key is still 'channel_devops_bot' (routed to the same sandbox sbx_devops), Bob can directly access the script uploaded by Alice.

[0074] Example 3, Message Merging: The large model generates streaming output in response to the user's question "Introduce the Kubernetes architecture," producing 5 fragmented messages in chronological order: t=0ms receives "Kubernetes is a..."; t=200ms receives "An open-source container orchestration platform"; t=600ms receives "Open-sourced by Google"; t=1200ms receives "Main components include..."; t=1800ms receives "Master nodes and Worker nodes." System processing: At t=0ms, a buffer is created and T_soft=2000ms and T_hard=10000ms are started; T_soft is reset each time a new message arrives; at t=3800ms (2000ms after the last message), T_soft times out and triggers flush; since the 5 messages belong to the same agent sender, they are concatenated with newlines to form a complete message and pushed at once; ultimately, the user receives one complete message instead of 5 fragments.

[0075] Example 4: Coordination Loop Implements Configuration: The system administrator adds a Lark channel through the management interface: inserting channel_id=c_new, platform=feishu, session_key_tpl='{sender_id}', workspace_key_tpl='{channel_id}', enabled=true into im_channels; the coordination loop detects that c_new is in desired but not running in the next 10-second cycle, starts an independent asynchronous task, establishes a long WebSocket connection with Lark, and subsequently reports status='connected' every 30 seconds via heartbeat; the administrator then temporarily disables the channel (enabled=false), and the next coordination cycle detects the status change, retrieves abort_handle from running and calls abort(), the WebSocket task receives the cancellation signal, disconnects and reports status='stopped'; the entire process does not require restarting any services.

[0076] In addition, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0077] In addition, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0078] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0079] This invention is not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this invention is limited only by the appended claims.

Claims

1. A method for decoupling the session and workspace routing of an instant messaging robot, characterized in that, The method includes: Configure a session key template and a workspace key template for each instant messaging channel. Receive message callback requests pushed by the instant messaging platform through the platform adapter. Parse the message callback requests to obtain structured messages and extract context variables from the messages. Based on the session key template and context variables, the key parsing function is called to generate the session key in order to obtain the session identifier; By combining the workspace key template, context variables, and session identifier, the key parsing function is called to generate the workspace key in order to obtain the sandbox identifier. Taking messages, session identifiers, and sandbox identifiers as inputs, the agent performs loop reasoning and outputs streaming processing results. The message merging mechanism is used to buffer and merge the streaming processing results, and the merged results are pushed to the instant messaging platform to achieve decoupled routing of the instant messaging robot's session and workspace.

2. The session and workspace decoupling routing method for instant messaging robots according to claim 1, characterized in that, The extraction of context variables from the message includes: Parse the message request body to obtain message metadata, and read the sender identifier and group chat identifier assigned to the message by the instant messaging platform from the message metadata; The routing layer determines the instant messaging channel to which the message belongs based on the message's access path and injects the corresponding channel identifier; By combining the sender identifier, group chat identifier, and channel identifier, a context variable containing multiple fields is constructed.

3. The session and workspace decoupling routing method for instant messaging robots according to claim 1, characterized in that, The step of generating a session key by calling a key resolution function based on the session key template and context variables to obtain the session identifier includes: The session key template is used as the input template, and the context variable is used as the input parameter. The key parsing function is called to replace the strings in the input template in a preset order to generate the session key. Use the session key as the query key to query the session mapping table in the preset database; If a session mapping relationship is found, the corresponding session identifier is extracted; if no session mapping relationship is found, a universally unique identifier is generated as a new session identifier, and the session mapping table is updated through insertion technology to complete the acquisition of the session identifier.

4. The session and workspace decoupling routing method for instant messaging robots according to claim 1, characterized in that, The step of combining the workspace key template, context variables, and session identifier to call the key resolution function to generate the workspace key in order to obtain the sandbox identifier includes: The context variables and session identifiers are merged to generate a context dictionary; Using the workspace key template as the input template and the context dictionary as the input parameter, the key parsing function is called to replace the strings in the input template in a preset order to generate the workspace key; Use the workspace key as the query key to query the workspace sandbox mapping table in the preset database; If a workspace sandbox mapping relationship is found and the sandbox is alive, the corresponding sandbox identifier is extracted. If no workspace sandbox mapping relationship is found or the sandbox is alive, the sandbox allocation service is called to create a new sandbox and the workspace sandbox mapping table is updated using insertion technology to complete the acquisition of the sandbox identifier.

5. The session and workspace decoupling routing method for instant messaging robots according to claim 4, characterized in that, When multiple concurrent requests create sandboxes for the same workspace at the same time, the later-arriving request will retrieve the existing sandbox identifier from the preset database and call the workspace sandbox mapping table to reclaim the sandbox allocated for this request.

6. The session and workspace decoupling routing method for instant messaging robots according to claim 1, characterized in that, The process of using an intelligent agent for loop reasoning, outputting streaming processing results, and using a message merging mechanism to buffer and merge the streaming processing results before pushing the merged results to an instant messaging platform includes: After receiving the message, session identifier, and sandbox identifier, the agent calls the preset large language model to perform an inference loop until the inference loop meets the preset termination condition and outputs the streaming processing result. The streaming results are added to the message buffer of the corresponding session, and soft-trigger timers and hard-trigger timers are started simultaneously. When any trigger timer expires, a refresh operation is triggered, merging all messages in the message buffer according to preset rules, and pushing the merged result to the instant messaging platform.

7. The session and workspace decoupling routing method for instant messaging robots according to claim 6, characterized in that, The process involves calling a preset large language model for inference loops until the inference loop meets a preset termination condition. The output streaming results include: Based on the session identifier, the corresponding historical session is read from the preset session state storage, and the historical session is merged with the message to generate a message sequence; Instantiate a separate agent state object for the message callback request and write the message processing context into the agent state object; Based on the writing results, the agent calls the large language model to perform an inference loop and outputs the inference results. If the inference result contains a tool call request, the tool call request is sent to the sandbox endpoint corresponding to the sandbox identifier via the remote procedure call protocol for execution, and the execution result is sent back to the large language model as an observation for the next round of inference; If the inference result does not contain a tool call request, the inference loop terminates and the corresponding streaming result is output.

8. The session and workspace decoupling routing method for instant messaging robots according to claim 7, characterized in that, The agent invokes a large language model to perform inference loops, and outputs inference results including: The message sequence is serialized according to the Open AI Chat Completion Protocol format, and combined with the tool description of the agent registration, the model parameters in the version configuration, and the application interface key injected by the platform to complete the configuration of the large language model; Send a Hypertext Transfer Protocol request to the configured large language model endpoint, and receive the large language model response via an event stream sent by the server. Read each data frame in the sent event stream and aggregate them frame by frame to obtain the inference results.

9. The session and workspace decoupling routing method for instant messaging robots according to claim 8, characterized in that, If a new message arrives while the soft-trigger is in the timing state, the timing period of the soft-trigger will be reset.

10. A decoupled routing system for the conversation and workspace of an instant messaging robot, characterized in that, The system includes: The configuration and extraction module is used to configure session key templates and workspace key templates for each instant messaging channel. It receives message callback requests pushed by the instant messaging platform through the platform adapter, parses the message callback requests to obtain structured messages, and extracts context variables from the messages. The session identifier acquisition module is used to generate a session key by calling the key parsing function based on the session key template and context variables, in order to obtain the session identifier; The sandbox identifier acquisition module is used to combine the workspace key template, context variables, and session identifier to call the key parsing function to generate a workspace key in order to obtain the sandbox identifier. The reasoning and push module takes messages, session identifiers, and sandbox identifiers as inputs, uses the agent to perform cyclical reasoning, outputs streaming processing results, and uses a message merging mechanism to buffer and merge the streaming processing results, and pushes the merged results to the instant messaging platform to achieve decoupling routing between the instant messaging robot's session and workspace.

11. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images