Data processing method and device, computer device, storage medium and program product

Abstract

The application relates to a data processing method and device, computer equipment, a storage medium and a program product, and relates to the technical field of computers. The method comprises the following steps: receiving a target request of a target account based on a target session, obtaining context information corresponding to the target request from a shared context of a target user group to which the target account belongs; the sessions corresponding to different accounts in the target user group are mutually isolated; generating reply information corresponding to the target request according to the context information; and feeding back the reply information to the target account through the target session. The method automatically synchronizes the context memory at the user group level between sessions, can eliminate the execution deviation caused by asynchronous information, and further improves the accuracy and context continuity of the reply of the intelligent agent. The method can provide a team-shared project memory and decision-making assistant for project management, and further improves the overall efficiency of project management.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] Currently, in enterprise-level project management and team collaboration scenarios, team members need to obtain information such as project progress, task status, and risk warnings through natural language interaction via AI agents. Current project management tools and AI agents generally employ a "one person, one conversation" model, where each user's conversation context is stored strictly independently. For example, in the same project, the project manager and team members each have completely isolated agent conversations. When the project manager confirms a technical decision, adjusts a milestone, or clarifies requirements in their conversation, this decision information only exists in the manager's conversation memory; the team members' conversations cannot automatically perceive this change in status. Due to the lack of shared memory, the AI ​​agent can only answer each member's questions based on isolated contexts, failing to generate accurate answers that require combining collective team decisions or the project's shared state. Summary of the Invention

[0003] Based on this, it is necessary to provide a data processing method, apparatus, computer device, computer-readable storage medium, and computer program product that can automatically synchronize user group-level context memory between sessions, eliminate execution deviations caused by information asynchrony, and thereby improve the accuracy and contextual coherence of agent responses.

[0004] In a first aspect, this application provides a data processing method, including:

[0005] Based on the target session, the target account receives the target request and obtains the context information corresponding to the target request from the shared context of the target user group to which the target account belongs; the sessions corresponding to different accounts in the target user group are isolated from each other;

[0006] Generate the response information corresponding to the target request based on the context information;

[0007] The system sends a response message to the target account through the target session.

[0008] Secondly, this application also provides a data processing method, including:

[0009] Based on the target session, the target account receives the target request and obtains the context information corresponding to the target request from the shared context of the target user group to which the target account belongs; the sessions corresponding to different accounts in the target user group are isolated from each other;

[0010] Invoke the AI ​​agent corresponding to the target account, and generate the response information corresponding to the target request based on the context information;

[0011] The system sends a response message to the target account through the target session.

[0012] Thirdly, this application also provides a data processing method, including:

[0013] In response to the target account entering a dialogue message in the conversation interface, a target request is sent to the agent corresponding to the target account based on the target session. This instructs the agent to obtain the context information corresponding to the target request from the shared context of the target user group to which the target account belongs, and to generate the response information corresponding to the target request based on the context information. Sessions corresponding to different accounts in the target user group are isolated from each other.

[0014] Receive response information from the intelligent agent through the target session;

[0015] The reply information is displayed on the conversation interface.

[0016] Fourthly, this application also provides a data processing apparatus, comprising:

[0017] The context scheduling module is used to receive target requests from target accounts based on the target session, and to obtain the context information corresponding to the target request from the shared context of the target user group to which the target account belongs; the sessions corresponding to different accounts in the target user group are isolated from each other;

[0018] The intelligent proxy module is used to generate response information corresponding to the target request based on context information; and to send the response information back to the target account through the target session.

[0019] Fifthly, this application 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 of the method described in the first, second, or third aspects above.

[0020] Sixthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the methods described in the first, second, or third aspects above.

[0021] In a seventh aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods described in the first, second, or third aspects above.

[0022] The aforementioned data processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product receive a target request from a target account based on a target session. They obtain context information corresponding to the target request from the shared context of the target user group to which the target account belongs. Sessions corresponding to different accounts within the target user group are isolated from each other. Response information corresponding to the target request is generated based on the context information. The response information is then fed back to the target account through the target session. By adding a shared context injection mechanism to the "one person, one session" isolation model, independent sessions of multiple accounts within the same user group share the same context memory, significantly improving team collaboration efficiency. The method generates response information corresponding to the target request based on the obtained context information, achieving response generation based on the shared context of the user group rather than the independent memory of a single session. Feedback of response information to the target account through the target session ensures that each target account receives responses within its own session that include relevant information from the shared context of the user group, thereby achieving context communication between multiple sessions within the same user group. This method automatically synchronizes user group-level context memory between sessions, eliminating execution deviations caused by information asynchrony, thereby improving the accuracy and contextual coherence of the agent's responses. Applying this method can provide team-shared project memories and decision-making assistance for project management, thereby improving the overall efficiency of project management. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a diagram illustrating the application environment of a data processing method in one embodiment.

[0025] Figure 2 This is a flowchart illustrating a data processing method in one embodiment;

[0026] Figure 3 This is a flowchart illustrating the data processing method in another embodiment;

[0027] Figure 4 This is a schematic diagram of the intelligent agent's conversation interface in one embodiment;

[0028] Figure 5 This is a flowchart illustrating a data processing method applied to a terminal in one embodiment;

[0029] Figure 6This is a schematic diagram illustrating the interaction between a terminal and a server in one embodiment;

[0030] Figure 7 This is a schematic diagram illustrating the interaction between the terminal and the server in another embodiment;

[0031] Figure 8 This is a structural block diagram of a data processing device in one embodiment;

[0032] Figure 9 This is a structural block diagram of the data processing apparatus in another embodiment;

[0033] Figure 10 This is a structural block diagram of a data processing device applied to a terminal in one embodiment;

[0034] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0036] Before describing the embodiments of this application, it should be noted that the term "in response to" used in the embodiments of this application refers to the state in which a corresponding event occurs or a condition is satisfied. It is understood that the timing of the execution of subsequent actions performed in response to such event or condition is not necessarily strongly correlated with the time when the event occurs or the condition is met. For example, in some cases, subsequent actions may be executed immediately upon the occurrence of the event or the fulfillment of the condition; while in other cases, subsequent actions may be executed some time after the occurrence of the event or the fulfillment of the condition.

[0037] In this application, the "intelligent agent" refers to a programmatic entity with natural language understanding, context awareness, and answer generation capabilities. It receives requests from a target account, retrieves relevant information from the shared context of the user group to which the target account belongs, and generates a natural language response based on the retrieval results. The intelligent agent can manifest as a large language model-driven dialogue proxy, a question-answering engine based on retrieval enhancement, a rule-and-model hybrid interaction system, or a combination of the above. The intelligent agent can parse the semantic intent in a user request, correlate multi-dimensional information such as project decisions and work item statuses in the shared context, and generate response content consistent with the current state of the user group and conforming to the granularity of the user request. The intelligent agent can be either an AI service deployed in the cloud, supporting concurrent access from multiple user groups, or a customized model running in a private environment, securely interacting with the user group's project management data source. Optionally, the intelligent agent and user group have a one-to-many mapping relationship; that is, multiple user groups can share the same intelligent agent definition, but each user group has an independently running pool of intelligent agent instances. The shared context of each user group is isolated from each other, and each intelligent agent instance dynamically reads the shared context of the corresponding group when processing requests from each user group. Optionally, a one-to-one mapping exists between agents and user groups, with each user group having its own dedicated pool of agent instances, serving only one user group. Alternatively, a one-to-one mapping exists between agent instances and accounts, with each account having its own dedicated agent instance, serving only one account. Agents interact with target accounts via a session interface, dynamically reading the shared context of the user group during each request processing to ensure the real-time nature and consistency of responses. An agent definition refers to the logical description of the agent, including prompts, toolsets, and model parameters, while an agent instance refers to the specific execution unit created at runtime based on this definition. The same agent definition can be instantiated multiple times, generating multiple independent agent instances, each serving a different user group or account, thus achieving a balance between logical reuse and runtime isolation.

[0038] In this application's embodiments, a "user group" refers to a collection of multiple accounts. User groups can correspond to real-world project teams, corporate departments, temporary collaboration groups, and other user groups with collaboration and information sharing needs. Each user group has a unique identifier and is associated with a dedicated shared context storage space. This shared context is used to aggregate key semantic information generated by each member within the user group during project collaboration, such as decision-making information, milestone changes, requirement clarifications, task assignments, and risk reporting. There is a one-to-many inclusion relationship between user groups and accounts; that is, one user group can contain multiple accounts. User groups can be dynamically created, disbanded, or have their members changed, and their shared context continuously accumulates throughout the project lifecycle.

[0039] In this application's embodiments, a "session" refers to a logical channel for single or continuous interaction between an account and an agent, used to carry a sequence of requests and responses. The lifecycle of a session can be independent of the shared context; even if a session is closed and then re-established, the new session can still recover user group-level memories from the shared context. Sessions support multi-turn dialogues, with each turn able to obtain the latest state of the shared context in real time, eliminating the need for the user to repeatedly state historical context.

[0040] In this application's embodiments, an "account" refers to a digital identity entity representing a specific user participating in project collaboration, used to identify the user's uniqueness, permissions, and user group affiliation. Accounts can correspond to different roles such as project leader, project member, department manager, and external collaborator. Each account belongs to at least one user group and is associated with one or more sessions. Accounts possess attribute information, including but not limited to account identifier, user group identifier, and role tags. When generating a response, the intelligent agent can obtain the target account's user group and access the shared context of that user group. For example, an account can initiate a session request through an application or web client on a terminal device (such as a computer, mobile phone, or tablet) and receive response information from the intelligent agent.

[0041] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0042] Understandably, current project management tools and AI-powered agents generally employ a "one person, one conversation" model, where each user's conversation context is stored strictly and independently. Due to the lack of shared memory, the agent can only answer each member's questions based on isolated contexts, failing to generate accurate responses that require combining team collective decision-making or the common state of the project.

[0043] To address this issue, this invention proposes a data processing method, apparatus, computer device, computer-readable storage medium, and computer program product. Based on a target session, it receives a target request from a target account. It then obtains context information corresponding to the target request from the shared context of the target user group to which the target account belongs. Sessions corresponding to different accounts within the target user group are isolated from each other. Based on the context information, it generates response information corresponding to the target request. Finally, it sends the response information back to the target account through the target session. By adding a shared context injection mechanism to the "one person, one session" isolation model, independent sessions of multiple accounts within the same user group share the same context memory, significantly improving team collaboration efficiency. The method generates response information corresponding to the target request based on the obtained context information, achieving response generation based on the shared context of the user group rather than the independent memory of a single session. The method sends response information back to the target account through the target session, ensuring that each target account's response within its own session includes relevant information from the shared context of the user group, thus achieving context communication between multiple sessions within the same user group. This method automatically synchronizes the user group-level context memory between sessions, eliminating execution deviations caused by information asynchrony, thereby improving the accuracy and contextual coherence of the agent's responses. Applying this method can provide team-shared project memories and decision-making assistance for project management, thereby improving the overall efficiency of project management.

[0044] The data processing method provided in this application embodiment can be applied to, for example... Figure 1 The application environment shown is as follows. Terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located in the cloud or on other network servers. Terminal 102 has an application installed, such as a project management collaboration application, an instant messaging tool, or team collaboration software integrated with intelligent agent capabilities; this application is logged into a target account.

[0045] For example, a user inputs a natural language request in the application's intelligent agent conversation interface. The application encapsulates this request into a data packet, which includes at least: a target account identifier, a target session identifier, the request text content, and a necessary timestamp. Terminal 102 sends the request data packet to server 104 through the target session. After receiving the request from terminal 102, server 104 parses out the target account identifier and the target session identifier. Server 104 queries the account attribute database based on the target account identifier to obtain the user group identifier of the target user group to which the target account belongs.

[0046] Optionally, server 104 obtains relevant context information from the shared context of the target user group based on the content of the target request. Server 104 locates the corresponding agent based on the target account identifier, such as a dedicated large language model instance deployed in the cloud. Server 104 invokes the agent, taking the prompt information constructed based on the context information as input. After semantic understanding and reasoning, the agent generates a response in natural language.

[0047] Optionally, server 104 passes the target request and the user group identifier of the target user group to the intelligent agent corresponding to the target account; the intelligent agent obtains relevant context information from the shared context of the target user group according to the content of the target request, takes the prompt information constructed based on the context information as input, and generates natural language response information after semantic understanding and reasoning.

[0048] Server 104 encapsulates the response information generated by the agent into a response data packet and sends it back to terminal 102 through the target session. After receiving the response, terminal 102 renders and displays the response information in the application's session interface. Users can continue to ask follow-up questions or make new requests in the same session. Subsequent requests will use the same session identifier, and server 104 will combine the session's private history and the user group's shared context to generate a response.

[0049] Optionally, after each interaction, server 104 stores the request and response records of this session in the session history storage. In addition, the asynchronous knowledge accumulation mechanism scans all session records at preset intervals, extracts newly generated information fragments, performs deduplication, association, and compilation, writes them into the shared knowledge base of the target user group, and updates the index, so that subsequent sessions of other accounts can automatically perceive this new knowledge.

[0050] Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0051] A method according to an embodiment of the present invention, such as Figure 2 As shown, a data processing method is provided, which can be applied to the device where the intelligent agent is located (or Figure 1 The following explanation uses the server shown as an example, including:

[0052] Step 202: Receive the target request of the target account based on the target session, and obtain the context information corresponding to the target request from the shared context of the target user group to which the target account belongs; the sessions corresponding to different accounts in the target user group are isolated from each other.

[0053] It is understood that in this embodiment, the execution subject of the data processing method can be an intelligent agent instance (referred to as "intelligent agent" in this embodiment) or an application deployed on a server that is associated with the intelligent agent. This application can act as an intermediary layer between the intelligent agent and the terminal. This embodiment uses the intelligent agent instance as the execution subject for illustration. For example, the server routes the target request of the target account sent by the terminal through the target session to the intelligent agent instance of the target account, and the intelligent agent instance executes the steps of the data processing method of this embodiment. For example, the server routes the target request of the target account sent by the terminal through the target session to the intelligent agent endpoint corresponding to the target user group, and the intelligent agent endpoint determines the intelligent agent instance corresponding to the target session from the instance pool, and the intelligent agent instance executes the steps of the data processing method of this embodiment.

[0054] A target request refers to a natural language query or instruction issued by a user logged into the target account through the session interface. These queries can take forms including, but are not limited to, text messages, voice input, or structured commands. Target requests may contain intents to query project status, decision information, task assignments, risk warnings, etc. A target session is a logical channel established between the target account and the agent to carry a sequence of request and response messages. Each session is uniquely associated with one account. Different accounts within the same user group have independent session instances, but these session instances can share the same user group-level context data.

[0055] In one optional implementation, users can trigger agent conversations and input natural language requests through various visual scenarios, including but not limited to the following: Users can mention the assistant (e.g., "@assistant") or enter a pre-defined agent name in an instant messaging group with their project team, followed by a question, to trigger an agent conversation and input a natural language request. A floating AI assistant icon (such as a robot avatar or speech bubble) is displayed on the application's project details page, work item dashboard, or dashboard interface; clicking this AI assistant icon displays the agent conversation interface associated with the current project. Users can also press a preset shortcut key in any interface of the application to display the agent conversation interface associated with the current project. The input methods for the target request include text input and voice input, with voice input being recognized and converted into text as a natural language request.

[0056] The shared context involved in this application refers to a global semantic memory storage belonging to the same user group and readable by agent instances of all accounts within that user group. The shared context is used to aggregate key information generated during project collaboration, including but not limited to project decisions, milestone changes, requirement clarifications, task assignments, risk reporting, and meeting conclusions. The shared context can be stored in various data formats, such as vector databases, graph databases, key-value pair storage, structured relational tables, or combinations thereof. Optionally, the shared context may include at least one of the following: user group data obtained by calling the group agent corresponding to the target user group, where the user group data includes session records between each account in the target user group and the group agent; real-time context fragments pulled from multiple heterogeneous data sources and refined through a real-time direct read path; and structured knowledge data compiled and written to the shared knowledge base periodically through an asynchronous knowledge accumulation mechanism. Information written to the shared context takes effect immediately after being written, and other accounts in the same user group can retrieve this information in subsequent session requests.

[0057] In one optional implementation, the server responds to a target request received based on the target session, and parses the target account identifier and target session identifier from the request. The server queries the account attribute database based on the target account identifier to obtain the user group identifier of the target user group to which the target account belongs. The user group identifier is used to uniquely identify a user group and its associated shared context storage space. The server accesses the shared context storage corresponding to the user group identifier and retrieves context information related to the request based on the content of the target request.

[0058] In one optional implementation, obtaining context information from the shared context can be achieved through various retrieval methods. For example, the server vectorizes the natural language text of the target request, performs a similarity search in the vector database of the shared context, and recalls several context records most semantically relevant to the request as context information. For example, the server pre-establishes a keyword index for each piece of information in the shared context and performs matching retrieval by parsing keywords in the target request. For example, the server can combine time range filtering to retrieve only context information written within a recent period to meet the user's query needs for the latest developments. For example, the server can combine explicit instructions in the request for timestamp positioning and precise reading. In another optional implementation, if the amount of information stored in the shared context is large, the server can first sort the retrieved candidate context information by relevance and select the top-ranked entries as the final context information provided to the agent to control input length and improve response speed.

[0059] It's important to note that sessions corresponding to different accounts within the target user group are isolated from each other. This can be understood as each session associated with a different account maintaining its own independent private context, such as conversation history and temporary state. These private contexts are not visible to or shared with each other. However, these sessions can share the same user group-level shared context, thus achieving the effect of private isolation and shared collaboration.

[0060] In one alternative implementation, the target request may involve contextual dependencies in multi-turn dialogues. In addition to retrieving information from the user group's shared context, the agent instance can also use the private history of the current target session (i.e., the historical question-and-answer records between the user and the agent in this session) as supplementary context. The session's private history and the user group's shared context have different scopes: the session's private history is only visible to the current session and is used to maintain the coherence of the dialogue; the user group's shared context is visible to all sessions within the same user group and is used to maintain collective memory at the user group level.

[0061] Understandably, the agent definitions can be the same or different across different user groups. However, each session is bound to its own independent agent instance. From each account's session perspective, requests are routed to the agent instance corresponding to the logic of that user group, and this agent instance dynamically reads the shared context of the current user group, making the shared context visible across sessions within the same user group and ensuring that responses are based on the latest collective memory. For example, a project leader confirms a technical decision through their session, and this decision is written into the shared context of the target user group; subsequently, a project member queries the technical decision through their own session, and the agent instance retrieves the decision information from the shared context, generates a response, and returns it to the project member. The entire process requires no manual information synchronization by members.

[0062] In an optional implementation, the method further includes: if it is identified that the content of the target request includes triggering information associated with the target user group, performing the step of obtaining the context information corresponding to the target request from the shared context of the target user group to which the target account belongs.

[0063] Upon receiving a target request, the server or agent instance parses the request's content to identify whether it contains triggering information associated with the target user group. Triggering information refers to keywords, phrases, instructions, or semantic intents that indicate the current request requires a shared context at the user group level for effective processing. For example, triggering information may include the target user group's name, group members' nicknames, project names, team-specific terminology, or queries involving collective memory, such as our group's decisions, project progress, or last meeting minutes. If the target request contains any one or more of these triggering information, the triggering condition is met, and subsequent steps are executed, namely retrieving the context information corresponding to the target request from the shared context of the target user group to which the target account belongs. Conversely, if the target request does not contain any triggering information associated with the target user group, such as a private greeting or personal inquiry, the agent instance generates a response based on the target session's private history or default configuration, thus saving computational resources and avoiding the introduction of irrelevant group-level information.

[0064] In practical implementation, various technical means can be used to identify trigger information, including but not limited to: rule engines based on keyword matching, pattern matching based on regular expressions, word segmentation and part-of-speech tagging based on natural language processing, text classification models based on machine learning, or determining whether the request intent belongs to the group collaboration category based on semantic similarity calculation. The server can pre-configure a trigger lexicon or trigger rule set, which can be customized according to the business characteristics of different user groups.

[0065] By judging the above triggering conditions, this embodiment can intelligently determine when to introduce user group sharing context, which not only ensures information sharing in team collaboration scenarios, but also avoids invalid retrieval of shared storage in unnecessary scenarios.

[0066] Step 204: Generate the response information corresponding to the target request based on the context information.

[0067] In this process, after obtaining the context information corresponding to the target request, the agent instance generates a response to the target request based on that context information. For example, the agent instance can be a general-purpose agent service instance deployed in the cloud, where an independent dialogue strategy or model parameters are maintained for each target account; or it can be a customized agent specific to a target user group, such as a language model fine-tuned based on the user group's historical dialogue data. Optionally, the mapping relationship between agent instances and accounts is maintained in the server through a binding record between account identifiers and agent endpoint identifiers.

[0068] In one optional implementation, the agent instance concatenates or structurally combines the original text of the target request with the acquired context information to form an input prompt. The context information may contain multiple records from a shared context. For example, the input prompt includes the original text of the target request, context records retrieved from the shared context, role instructions, conversation background, output format constraints, and response style. After receiving the input, the agent instance uses its internal semantic understanding and text generation capabilities to output a natural language response to the target request. For example, the server maintains an independent agent definition for each user group, including but not limited to model parameters, system prompts, response styles, and callable external tools. When the server determines the user group to which the target account belongs, it loads the configuration parameters of that user group, creates an agent instance, or calls an idle agent instance from a pool of agent instances created based on the agent definition of that user group. The created or called agent instance executes the steps of the data processing method of this embodiment.

[0069] In one alternative implementation, the process of the agent instance generating response information can be streamed. The agent instance generates response content word by word or sentence by sentence, and the server feeds back the generated portion of the content to the client in real time through the target session. The client can instantly display the response being generated, reducing the user's perceived waiting time.

[0070] Understandably, the response information generated by the agent instance can be plain text or contain structured data. For example, for a request to list pending tasks, the agent instance can generate a multi-line text list containing task titles, deadlines, and priorities. For example, for a request to display the distribution of project risks, the agent instance can generate descriptive text along with a simplified table. Upon receiving the response information, the client can render it into a rich text format or further parse it into a visual chart.

[0071] In one alternative implementation, after the agent instance generates the response information, it determines whether the shared context needs to be updated based on the content of the response to the target request. For example, if the agent instance recognizes decision information during the response generation process, it automatically writes this decision information into the shared context of the target user group, allowing other members to perceive it subsequently. This enables the shared context to be continuously enriched as the dialogue evolves naturally, without requiring the user to explicitly perform a save operation.

[0072] Step 206: Send a response message to the target account through the target session.

[0073] After the agent instance generates a response, the server sends the response to the client corresponding to the target account through the target session. The response can be synchronous, completed within the same request and response cycle, or asynchronous. For example, if the agent instance generation process is time-consuming, the server can first generate a temporary placeholder response, and then push the complete response through the target session once it is complete. The response can be in the form of text, rich text, structured data, or a combination of these. After receiving the response, the client renders it and displays it in the session interface for the user corresponding to the target account to read or interact with further.

[0074] In one alternative implementation, when the server sends a response to the client, it also includes an identifier of the context upon which the response is based. For example, each response may include a list of metadata referencing the context, containing references to relevant records retrieved from the shared context. When displaying the response, the client can present these references as clickable badges or footnotes. After the user clicks a reference marker, the client can display detailed information about that context record in a pop-up window or similar format, thereby enhancing the credibility and traceability of the response. This approach allows users not only to receive the answer but also to understand its source, facilitating verification when necessary.

[0075] In one alternative implementation, the response information can include various media types. For example, the agent-generated response may include not only text descriptions but also visual elements such as tables, lists, progress bars, and diagrams. The server can return these elements in a structured format (such as JSON), and the client can convert them into corresponding native controls or charts according to predefined rendering rules. For example, for a request to display the completion status of project milestones, the agent-generated response information could be a table containing milestone names, planned completion dates, and actual completion status. After receiving this structured data, the client renders it as a sortable, lightweight table in the conversation bubble, allowing the user to perform simple filtering or sorting operations on the table.

[0076] Understandably, the target session, acting as a container for requests and responses, maintains a complete message history. When the server responds, it associates the response with the corresponding target request and stores it in the session history (i.e., the session record). The session history can be stored on the server side or synchronously cached locally on the client. When a user subsequently asks questions within the same session, the server can read the session's historical messages as supplementary context, inputting them along with the user group shared context into the agent instance to maintain the continuity of multi-turn dialogues. The session history and the user group shared context have different lifecycles; the session history typically expires when the session closes or is cleaned up, while the user group shared context is persistent and valid across sessions and accounts for a long time.

[0077] In one alternative implementation, the server can post-process the original response generated by the agent before providing feedback. Post-processing operations may include, but are not limited to, filtering sensitive words, formatting, truncating length, and adding interactive guidance. The post-processed response is more adapted to the client's display capabilities and user habits.

[0078] In one alternative implementation, the response information can be filtered based on the target account's permissions. Although the agent generates the response based on the user group's shared context, some information within that shared context may not be visible to certain roles within the user group. Before providing the response, the server can perform a secondary anonymization process on the response information based on the target account's permission tags. This ensures cross-account visibility of the shared context while improving data security within the user group.

[0079] In one alternative implementation, after receiving a response, the client can provide the user with a control to evaluate the quality of the response. For example, two buttons, "Useful" and "Useless," are displayed near each response. After clicking the "Useless" button, the user can further select a reason (such as incorrect information, irrelevant context, or omission of important information). The client reports the evaluation data to the server, which can then optimize subsequent context retrieval strategies or agent generation parameters. This helps to continuously improve the accuracy of responses and user satisfaction.

[0080] In the aforementioned data processing method, based on the "one person, one session" isolation model, a shared context injection mechanism is added. This allows independent sessions of multiple accounts within the same user group to share the same context memory, significantly improving team collaboration efficiency. The method generates response information corresponding to the target request based on the acquired context information, achieving response generation based on the shared context of the user group rather than the independent memory of a single session. The response information is fed back to the target account through the target session, ensuring that each target account receives responses within its own session that include relevant information from the shared context of the user group, thus achieving context interoperability between multiple sessions within the same user group. This method automatically synchronizes user group-level context memory between sessions, eliminating execution deviations caused by information asynchrony, thereby improving the accuracy and contextual coherence of agent responses. Applying this method can provide team-shared project memory and decision-making assistance for project management, thereby improving the overall efficiency of project management.

[0081] According to an embodiment of the present invention, the shared context includes at least one of the following: user group data obtained by invoking a group agent corresponding to the target user group; the user group data includes session records between each account in the target user group and the group agent; data read in real time from multiple data sources corresponding to the target user group; and data retrieved from knowledge data pre-stored in a shared knowledge base corresponding to the target user group; the knowledge data includes session records between each account in the target user group and the corresponding agent.

[0082] Optionally, the shared context includes user group data obtained by invoking the group agent corresponding to the target user group; the user group data includes session records between each account in the target user group and the group agent;

[0083] It is understood that the shared context described in this application embodiment is not limited to static project documents or knowledge bases, but may also include user group data dynamically obtained by calling the group agent corresponding to the target user group. A group agent refers to an agent instance or logical endpoint specifically serving the target user group (e.g., a project team, enterprise department, or collaboration group). This group agent can access the shared storage space dedicated to the user group and record the interaction history between the group agent and all accounts within the user group. User group data refers to a dynamic set of information reflecting the collective activities, collaboration status, and communication content of the target user group, including conversation records between each account in the target user group and the group agent. Optionally, conversation records do not refer to a complete, continuous message sequence between each account and the group agent, but rather to fragments with independent semantics or key information extracted from these original dialogues. These fragments may be single-turn question-and-answer pairs, representative subsequences after truncation, summarization, or deduplication in multi-turn dialogues, or local content marked as important or related to the user group's shared topics in the conversation. Since the group agent serves the entire user group, it can uniformly collect and store all the interaction records between the group members and itself, thus forming a cross-account, cross-session group-level dialogue corpus.

[0084] For example, when any account initiates a request to the group agent through its session and receives a response, the server automatically writes the complete record or key information fragments of that round of question-and-answer as user group data into the shared storage corresponding to the target user group. This ensures that key information fragments of each dialogue between the group agent and its members are stored in the group-level shared context.

[0085] When a target account in a target user group initiates a target request to the corresponding agent instance via a session, the agent instance proactively calls the relevant query interface of the group agent to read the session records of the target user group from shared storage. During the read, various filtering conditions can be applied, such as retrieving the most recent N records, retrieving records within a specific time range, or retrieving records involving certain keywords. These session records are organized into structured text or vector format and provided to the agent instance as part of the shared context for generating a response.

[0086] Optionally, the shared context includes data read in real time from multiple data sources corresponding to the target user group; obtaining context information corresponding to the target request from the shared context of the target user group to which the target account belongs includes: reading the original data corresponding to the target request from multiple data sources corresponding to the target user group; and refining the original data corresponding to the target request to obtain the context information corresponding to the target request.

[0087] It is understood that the shared context in this embodiment refers to the original data set corresponding to the target user group, distributed across multiple heterogeneous data sources. For example, referring to Table 1, the multiple data sources may include, but are not limited to: project meeting minutes, project document space, project group chat, project member private chat, work items and milestones, etc.

[0088] Table 1:

[0089]

[0090] In practice, each data source independently maintains its original data. The shared context of the target user group is represented on the server side as a set of access capabilities to each data source. Operations such as fetching and format normalization are implemented through pre-registered adapters. The server does not need to fully synchronize the original data of all data sources to local storage, but instead fetches data on demand according to requests, thereby reducing storage costs and ensuring data real-time performance.

[0091] In one optional implementation, the target user group registers the data source through a configuration interface during creation or initialization. For example, the configuration interface displays all currently supported data source types. Users with administrator privileges provide access credentials for each data source and set the retrieval scope (such as a specific group chat identifier, project space identifier, etc.). The server stores this registration information in the data source registry and binds a corresponding adapter to each data source. The adapter is a pluggable data source access module that encapsulates the details of raw data retrieval and format conversion from different data sources through a unified access interface, providing consistent reading capabilities. For example, the instant messaging group chat adapter retrieves message records from a specified group chat within a certain time range via the instant messaging server API and returns normalized message objects. The meeting minutes adapter queries meeting minutes text that meet certain conditions through the meeting transcription application programming interface and returns normalized meeting minutes objects.

[0092] In one optional implementation, upon receiving a target request, the context scheduler intelligently filters relevant data sources based on the semantic intent of the request. Optionally, the context scheduler performs semantic analysis on the target request, extracting keywords, intent categories, and time ranges. After determining the list of data sources related to the intent based on pre-configured intent-data source mapping rules, the scheduler calls the adapter corresponding to each data source to retrieve the raw data related to the keywords and time ranges.

[0093] Optionally, the context scheduler employs a parallel fetching approach to reduce overall wait time. For example, an asynchronous task is created for each data source, containing access parameters such as time range, filtering conditions, and maximum number of records to return. All tasks execute concurrently, and the results are merged after completion or timeout. For slow-responding data sources, a timeout can be selected to abandon the data source and log an error, while continuing to wait for responses from other data sources to ensure the overall request is not blocked. Optionally, if the data source does not support keyword filtering, the server-side filtering is performed after the adapter fetches all data.

[0094] In one alternative implementation, for data sources with a data volume exceeding a set threshold, the context scheduler employs a tiered fetching strategy: first, it fetches summary information (such as work item identifier, title, and status), and then determines whether to fetch further details based on the relevance of the summary. This strategy significantly reduces data transfer volume.

[0095] For example, the raw data pulled from various data sources is often redundant, unstructured, or semi-structured. Directly inputting it into an agent instance can lead to problems such as excessively long input, noise interference, or the burying of key information. The server needs to refine the raw data to generate concise, structured fragments of contextual information. Optionally, this refinement can be performed using a lightweight large language model (LLM).

[0096] For example, the refinement process includes the following steps: removing irrelevant noise from the original data through data cleaning; generating a summary using LLM for the cleaned data; structuring the refined information fragments according to a unified data model; calculating the semantic relevance score of each refined fragment to the target request, sorting them from high to low scores, and retaining fragments with scores higher than a preset threshold, or retaining the top N fragments with the highest scores.

[0097] Understandably, after the extraction is complete, the server receives one or more structured context information fragments. These fragments are returned as context information corresponding to the target request. The server then merges these fragments into context information for the agent to generate a response. Context information can be passed to the agent's calling module in list form or directly concatenated into natural language paragraphs. Optionally, when passing it to the agent, the server attaches metadata about the context fragments, such as the source data source, timestamp, and credibility score, so that the agent can reference the source or the age of the information when generating a response.

[0098] In the current framework of project management tools and AI-powered agents, project-related information is typically scattered across multiple heterogeneous systems, such as meeting transcription systems, instant messaging group chats, online document libraries, and work item tracking systems. When users obtain project progress information through the agent, they need to manually search and integrate information across systems, a process that is inefficient and prone to missing crucial information. Furthermore, the context of existing AI agents mainly comes from the history of the current conversation, lacking the ability to dynamically aggregate project context from multiple heterogeneous systems. Specifically, when a user asks a question to the agent, the agent can only answer based on the existing conversation history, unable to proactively perceive project decisions, group chat discussions, document updates, or work item status changes stored in other systems. This forces users to re-enter or describe information scattered across various systems to the agent in a conversational format before the agent can incorporate it into the context; otherwise, the agent's response will heavily rely on the incomplete background provided by the user, making it difficult to form an accurate answer that integrates information from multiple sources. Furthermore, due to the different data formats, update frequencies, and access interfaces of different systems, traditional solutions lack a unified data retrieval and extraction mechanism, making it impossible to efficiently extract information related to the current request from multiple data sources while ensuring real-time performance.

[0099] To address this issue, this embodiment reads and refines raw data from multiple data sources corresponding to the target user group, achieving unified acquisition and refinement of scattered, heterogeneous, and dynamic project information. It transforms raw noisy data into high-density contextual information fragments, overcoming the shortcomings of fragmented context and single source in traditional solutions. This lays a solid foundation for agents to generate accurate, timely responses that integrate collective memory.

[0100] In one alternative implementation, the shared context includes data retrieved from knowledge data pre-stored in the shared knowledge base corresponding to the target user group; the knowledge data includes session records between each account in the target user group and the corresponding intelligent agent; obtaining context information corresponding to the target request from the shared context of the target user group to which the target account belongs includes: retrieving context information corresponding to the target request from the knowledge data pre-stored in the shared knowledge base corresponding to the target user group.

[0101] In this embodiment, the shared context includes data retrieved from the knowledge data pre-stored in the shared knowledge base corresponding to the target user group. The shared knowledge base is a unified knowledge storage system that persistently stores the knowledge data of multiple user groups. The shared knowledge base is logically or physically partitioned according to user group identifiers. Each user group has an independent knowledge data storage space, and the knowledge data between user groups is strictly isolated and mutually invisible. The knowledge data includes at least: conversation records between each account in the target user group and its corresponding intelligent agent. The corresponding intelligent agent refers to the intelligent agent instance corresponding to each account. Conversation records refer to the message sequence generated when each account converses with an intelligent agent. These records can include complete historical question-and-answer sessions, or key fragments extracted from them, such as decision records, milestone change conclusions, requirement clarifications, and risk escalation judgment criteria extracted from historical conversations. The knowledge data corresponding to the target user group in the shared knowledge base is visible to all accounts belonging to the target user group and their conversations.

[0102] Optionally, obtaining context information corresponding to the target request from the shared context of the target user group to which the target account belongs may specifically include: retrieving context information that is semantically related to or matches keywords of the target request from the knowledge data corresponding to the target user group in the shared knowledge base.

[0103] In one alternative implementation, the shared knowledge base employs a hybrid storage approach combining a vector database and a full-text search engine. The vector database stores the semantic vectors of knowledge fragments, supporting semantic retrieval based on cosine similarity; the full-text search engine stores the original text of the knowledge fragments and keyword indexes, supporting exact matching and Boolean queries.

[0104] Optionally, the server converts the text of the target request into a vector using an embedding model, and retrieves the K most similar knowledge fragments to this vector from the vector database of the shared knowledge base. K is a configurable parameter, such as 10. Semantic retrieval can capture the potential semantic associations between the request and the knowledge fragments, even if the original words in the knowledge fragments do not appear in the request.

[0105] Optionally, the server extracts keywords from the target request and uses these keywords to match the title, body, or metadata of knowledge fragments in a full-text search engine.

[0106] Optionally, the server performs semantic search and keyword search simultaneously, and merges and sorts the two search results according to preset weights (e.g., semantic search weight is 0.6 and keyword search weight is 0.4), returning the top N segments with the highest scores after deduplication. This hybrid search can take into account both semantic generalization and exact matching.

[0107] To improve retrieval accuracy, the server can apply various filters during the retrieval process to narrow the search scope. Filters can be dynamically generated based on implicit conditions in the target request or user account attributes. Optionally, if the target request contains an explicit time indication, the server extracts the time range and retains knowledge fragments with timestamps within that range during retrieval. Optionally, each knowledge fragment in the shared knowledge base is tagged with a type field; the server determines the required knowledge type based on the request intent and retains knowledge fragments matching the knowledge type during retrieval. Optionally, if the request specifies an information source, the server can filter out knowledge fragments originating from a specific data source.

[0108] Optionally, after the retrieval is complete, the server obtains a set of candidate knowledge fragments, each with a relevance score. The server sorts these fragments from highest to lowest score and performs truncation or compression summaries based on the agent's input length limit. For example, if the agent supports a maximum of 4096 tokens of input, and each knowledge fragment occupies an average of 200 tokens, the server selects the top 20 fragments. For example, if the total number of tokens for the top 20 fragments still exceeds the limit, the server can further compress the summary of each fragment.

[0109] In one optional implementation, the server also performs deduplication on the search results. If multiple knowledge fragments are different versions of the same information, the server retains the latest fragment or merges them into a single composite fragment. Optionally, deduplication is achieved by calculating text similarity (such as Jaccard similarity or vector similarity) between fragments and merging fragments with similarity scores higher than a threshold.

[0110] Optionally, if the number of knowledge fragments retrieved from the shared knowledge base is zero, or if the relevance scores of all fragments are below a preset threshold (e.g., 0.5), the server assumes that there is no knowledge in the shared knowledge base related to the target request. The context scheduler can then switch to a real-time direct read path, pulling raw data from multiple data sources and refining it online to obtain context information.

[0111] In one alternative implementation, knowledge fragments retrieved from a shared knowledge base are sorted and truncated, then output as context information to the agent. Optionally, the server converts each knowledge fragment into a natural language sentence or a structured key-value pair, attaches metadata, and assembles them into a complete contextual prompt. Upon receiving the context information, the agent can generate an accurate response based on this knowledge data.

[0112] In this embodiment, through a multi-user group storage and isolated retrieval mechanism, the shared knowledge base can strictly protect the privacy and security of each user group's data while centrally managing knowledge resources, and provide each user group with exclusive and efficient knowledge retrieval services.

[0113] According to an embodiment of the present invention, a method for obtaining context information corresponding to a target request from the shared context of a target user group to which the target account belongs includes: determining the request type of the target request based on the semantic features of the target request; if the request type is a first type, reading the original data corresponding to the target request from multiple data sources corresponding to the target user group; refining the original data to obtain the context information corresponding to the target request; if the request type is a second type, retrieving the context information corresponding to the target request from the knowledge data pre-stored in the shared knowledge base corresponding to the target user group.

[0114] The shared context comprises two components. The first is raw data from multiple data sources corresponding to the target user group. These data sources may include, but are not limited to, project meeting minutes, project document spaces, project group chats, private chats among project members, work items, and milestones. Each data source independently maintains its real-time raw data. The second component is the knowledge data corresponding to the target user group in the shared knowledge base. This knowledge data is structured knowledge units generated by an asynchronous knowledge accumulation mechanism during system off-peak hours after compiling historical conversations and documents. Together, these two components constitute the complete shared context for the target user group, serving requests with different timeliness and granularity requirements.

[0115] In one optional implementation, the request type of the target request is determined based on the semantic features of the target request, including: determining whether the target request includes preset time-sensitive keywords or preset drill-down keywords based on the semantic features of the target request; if the target request includes preset time-sensitive keywords or preset drill-down keywords, the request type of the target request is determined to be the first type; if the target request does not include preset time-sensitive keywords or preset drill-down keywords, the request type of the target request is determined to be the second type.

[0116] The request type is determined based on the semantic features of the target request and executed by the context scheduler. The request type determines the path used to retrieve information from the shared context: the first type corresponds to a real-time direct-read path that reads raw data from multiple data sources and extracts it online, while the second type corresponds to a path that retrieves accumulated knowledge from a shared knowledge base.

[0117] The context scheduler determines the request type by analyzing whether the target request contains preset time-sensitive keywords or preset drill-down keywords. Preset time-sensitive keywords are words used to determine whether the user is requesting the latest or real-time information, including but not limited to "latest," "just now," "today," "at this moment," "real-time," and "current." Preset drill-down keywords are words used to determine whether the user is requesting in-depth viewing of details or expansion of specific content, including but not limited to "drill down," "take a closer look," "what exactly," "explain in detail," and "why."

[0118] The scheduler extracts keywords and phrases from the target request for matching. If the target request contains any word from the preset time-sensitive keywords or preset drill-down keywords, the request type is determined to be Type 1. Type 1 includes real-time requests (triggered by time-sensitive keywords) and drill-down requests (triggered by drill-down keywords). If the target request contains neither the preset time-sensitive keywords nor the preset drill-down keywords, the request type is determined to be Type 2, i.e., a regular request. Real-time requests refer to users wanting to obtain information generated at the current or most recent point in time, while drill-down requests refer to users wanting to further expand on existing information, view details, or understand the reasons behind it.

[0119] In one optional implementation, the matching of time-sensitive keywords and drill-down keywords supports fuzzy matching and synonym expansion to improve the scheduler's tolerance and coverage of users' natural language expressions. The scheduler has a built-in thesaurus that maps colloquial, variant, or near-synonymous expressions to standard keywords, such as mapping "now" to "current". For example, the scheduler performs word segmentation and normalization on the target request, searching each word or phrase in the thesaurus. If a match is found, it is replaced with the corresponding standard keyword before type determination. The scheduler supports regular expression matching, ignoring case sensitivity and differences in punctuation between Chinese and English. For example, the scheduler performs word segmentation and normalization on the target request, performing precise matching based on the standard keyword library; if no match is found, synonym mapping is performed before matching; if still no match is found, regular expression rules are applied to the request text. Matching stops at any stage, and the match type (time-sensitive keyword or drill-down keyword) is recorded.

[0120] In one alternative implementation, the administrator account of the target user group can customize time-sensitive keywords and drill-down keywords through the configuration page. The configuration takes effect in real time without requiring a service restart.

[0121] Through the request type determination mechanism based on keyword matching, the context scheduler can quickly and lightweightly divert user requests to different context retrieval paths, avoiding the latency overhead caused by complex models and ensuring the interpretability and configurability of the determination.

[0122] Specifically, when the request type is the first type, the context scheduler triggers the real-time direct read path. The specific process of the real-time direct read path can be referred to in the previous embodiment for reading and refining data from multiple data sources corresponding to the target user group, and will not be repeated here.

[0123] For example, the context scheduler performs semantic analysis on the target request, extracting keywords, intent categories, and time ranges. Based on pre-configured intent-to-data source mapping rules, the scheduler determines a list of data sources related to the intent, then calls the adapter corresponding to each data source to retrieve raw data related to the keywords and time ranges. The retrieved raw data is then refined; after refinement, a list of context information fragments is returned.

[0124] Specifically, when the request type is type two, the context scheduler triggers the shared knowledge base retrieval path. The specific process of the shared knowledge base retrieval path can be referred to in the previous embodiment for retrieving context information from the knowledge data corresponding to the target user group in the shared knowledge base, and will not be repeated here.

[0125] Optionally, the first type of path and the second type of path can work together. For example, if a request with an unclear intent is triggered by both paths simultaneously, the real-time refinement results and the knowledge base retrieval results are merged, deduplicated, and then uniformly sorted. For example, if the number of knowledge fragments retrieved from the shared knowledge base is zero, or the relevance scores of all fragments are below a preset threshold (e.g., 0.5), it is determined that there is no knowledge related to the target request in the shared knowledge base; the context scheduler can then switch to the real-time direct read path, pulling raw data from multiple data sources and refining it online to obtain context information.

[0126] Current project management tools and AI-powered agent frameworks face a trade-off between real-time performance and retrieval efficiency when handling contextual information. On one hand, project collaboration generates a large amount of high-frequency dynamic data, requiring the agent to answer questions based on the latest information. If a real-time retrieval solution is adopted, each request retrieves data from the original data source, leading to high API call costs and significant response latency, especially in concurrent scenarios where retrieval efficiency drops sharply. On the other hand, while writing all dynamic data to a knowledge base before retrieval can improve regular query speed, it suffers from update delays, failing to meet real-time requirements. Existing solutions employ a uniform context retrieval strategy for all requests, failing to differentiate processing based on users' varying timeliness needs, resulting in an inability to maintain efficient response while ensuring data freshness.

[0127] To address this issue, this embodiment utilizes a context scheduler to dynamically determine the request type based on the semantic features of the target request, achieving differentiated context retrieval paths: For the first type of request containing time-sensitive keywords or drill-down keywords, raw data is read and refined in real time from multiple data sources to ensure users receive the latest and most detailed information; for the second type of request not containing the aforementioned keywords, structured knowledge data already stored in the shared knowledge base is retrieved, avoiding repeated fetching of raw data sources. In scenarios with high real-time requirements, the real-time path ensures data accuracy, while the knowledge base retrieval path ensures low-latency responses for regular queries, achieving an optimal balance between timeliness and retrieval efficiency.

[0128] According to an embodiment of the present invention, a shared knowledge base includes a public layer and a working area layer. The public layer is configured to store knowledge data shared by multiple user groups, and the working area layer is configured to store private knowledge data of each user group. The method retrieves context information corresponding to a target request from the pre-stored knowledge data of the target user group in the shared knowledge base, including: retrieving knowledge data corresponding to the target request in the public layer using a preset semantic similarity retrieval algorithm; if no knowledge data is found, retrieving the knowledge data status of the target user group in the working area layer; if the knowledge data status indicates that the knowledge data of the target user group is invalid, reading the original data corresponding to the target request from multiple data sources corresponding to the target user group; and refining the original data to obtain the context information corresponding to the target request.

[0129] In one optional implementation, the shared knowledge base uses Git and Markdown as the primary storage solution. Git serves as the underlying storage and version control tool, with all knowledge data stored as files in the Git repository. Git's distributed version control capabilities are leveraged to record the author, time, and changes for each modification, supporting operations such as branching, merging, and rolling back. This enables the knowledge base to feature multi-user collaboration, traceable changes, and recoverable errors. Markdown is used as the format for writing knowledge content. Markdown is a lightweight markup language that supports common formatting elements such as headings, lists, tables, code blocks, and citations. Plain text facilitates version comparison and program parsing, while also being easy for human reading and editing. Logically, the shared knowledge base is divided into a public layer and a working area layer, further refined into a five-layer knowledge structure: methodology layer, decision tree layer, case study layer, terminology specification layer, and project archive layer. The public layer includes the methodology layer, decision tree layer, case study layer, and terminology specification layer, while the working area layer includes the project archive layer. Optionally, each knowledge unit in the five-layer knowledge structure (methodology layer, decision tree layer, case layer, terminology standardization layer, and project archive layer) is stored in the form of a .md file.

[0130] For example, the methodology layer stores content including but not limited to: Key Objective (KO) specifications, weekly report templates, risk matrix templates, stakeholder identification methods, etc. This layer is located in the methods directory of the shared knowledge base, and its content is visible to all agent instances of all projects. It is updated infrequently, usually on a monthly cycle, and is manually maintained by users with administrative privileges or system administrators.

[0131] The decision tree layer stores content including, but not limited to, risk escalation judgment rules and project scale management strategies. This layer is located in the `decision-trees` directory and is visible to all agent instances across all projects (or user groups). It is updated quarterly and maintained manually. Rules in the decision tree layer can be invoked by agents when generating responses for logical reasoning and judgment based on contextual information.

[0132] The case layer stores content including, but not limited to, good cases, bad cases, and pitfall records. This layer is located in the cases directory and is visible to all agent instances of all projects (or user groups). It is updated weekly and is automatically extracted and compiled from historical sessions and documents by the asynchronous knowledge accumulation mechanism (Auto Dream) of this application embodiment. It can be manually reviewed and supplemented.

[0133] The terminology specification layer stores content including, but not limited to: internal company terminology definitions, process terminology explanations, and cross-project common concept descriptions. This layer is located in the glossar directory and is visible to agent instances across all projects (or user groups). It is updated infrequently and is maintained manually. The terminology specification layer helps agents unify semantics when understanding user requests, avoiding inaccurate responses due to terminology ambiguity.

[0134] The project archive layer is the core storage area of ​​the shared knowledge base, strictly isolated by project, with each project having its own independent workspace. This layer is located under the `projects` directory, with each project (or user group) corresponding to a subdirectory (e.g., `project-A`, `project-B`). Each subdirectory contains a `workspace` folder, used to store the project's dynamic knowledge files. For example, the `workspace` may include `progress.md` to record real-time project progress, `risks.md` to register a risk list, `members.md` to record member information and role assignments, and `decisions.md` to store project decision records. The data update frequency of the project archive layer is daily or higher, and the update methods include compilation and writing via the AutoDream asynchronous knowledge accumulation mechanism of this application embodiment, and real-time writing, such as automatic writing triggered after a user confirms a decision in a session. The data in this layer is only visible to the agent instance of the current project (or user group), and the workspace layer data between different projects (or user groups) is strictly isolated.

[0135] Understandably, the shared knowledge base employs a two-tier visibility design to isolate multiple projects (or user groups). The public layer includes a methodology layer, a decision tree layer, a case layer, and a terminology specification layer. Agent instances from all projects (or user groups) can read the knowledge data in the public layer to answer general questions or as a decision-making reference. The working area layer is only visible to agent instances of the corresponding project (or user group); agent instances from other projects (or user groups) cannot access it. When an agent needs to retrieve contextual information from the shared knowledge base, the accessible knowledge scope is determined based on the identifier of the target user group to which the current request belongs: the public layer is fully readable, while the working area layer is limited to the current project (or user group).

[0136] Optionally, the hierarchical update strategy employs different update frequencies and methods based on the characteristics of each knowledge layer. For example, the methodology layer is updated monthly and maintained manually. The decision tree layer is updated quarterly and maintained manually. The case study layer is updated weekly, primarily through AutoDream asynchronous accumulation, supplemented by manual review. The terminology specification layer is updated infrequently and maintained manually. The project archive layer is updated daily or more frequently, using a combination of AutoDream asynchronous compilation and real-time writing to ensure the timely accumulation and sharing of dynamic information.

[0137] In one alternative implementation, the shared knowledge base can simultaneously build vector and full-text indexes to support semantic and keyword retrieval. When a Markdown file in the Git repository is modified, a trigger automatically invokes the embedding model to vectorize the file content and update the vector database, while simultaneously updating the full-text search engine. This process can be performed in real time, enabling newly written knowledge data to be retrieved quickly.

[0138] Through the aforementioned five-layer knowledge structure, multi-project isolation mechanism, and hierarchical update strategy, the shared knowledge base not only ensures the efficient reuse of common knowledge across projects, but also achieves strict isolation of private project data. At the same time, it balances the freshness of knowledge with maintenance costs through differentiated update frequencies and methods.

[0139] In one optional implementation, when retrieving knowledge data corresponding to a target user group from a shared knowledge base, a pre-defined semantic similarity retrieval algorithm is used to retrieve knowledge data semantically matching the target request in the public layer. For example, the target request text is converted into a high-dimensional vector using an embedding model, and cosine similarity is calculated in the vector database of the public layer. The vectors are then sorted by score, and a relevance threshold (e.g., 0.75) is set. If a knowledge fragment has a score higher than the threshold, it is returned as contextual information; if no fragment reaches the threshold, it is considered that no knowledge data was retrieved.

[0140] If no relevant knowledge data is found in the public layer, the process proceeds to the work area layer. Instead of directly retrieving specific knowledge content, the process first checks the knowledge data status of the target user group within the work area layer. The knowledge data status refers to a flag in the work area layer metadata table that describes the overall validity of the user group's private knowledge data, including whether it is valid, outdated, empty, or pending review. This status is maintained by the asynchronous knowledge accumulation mechanism (Auto Dream). Knowledge data invalidation means that the target user group does not have any usable valid knowledge data in the work area layer, specifically manifested as an outdated status (expired or not synchronized with the latest changes) or an empty status (no knowledge data has been created). If the knowledge data status is valid, knowledge fragments related to the target request are retrieved from the work area layer as context information.

[0141] If the knowledge data representing the target user group's status becomes invalid, a degradation strategy is triggered: instead of retrieving from the work area layer, the original data corresponding to the target request is read from multiple data sources corresponding to the target user group, and the original data is refined to obtain context information.

[0142] In one alternative implementation, when a degradation strategy is triggered due to outdated or empty knowledge data, the context information fragments obtained in this real-time extraction are temporarily written into the working area layer. Alternatively, an incremental compilation task is triggered (instead of waiting for a pre-set daily midnight scheduled task) to quickly compile the new information into the database and update the index, thereby shortening the knowledge accumulation delay and preventing the same user group from repeatedly triggering degradation in a short period of time.

[0143] In this embodiment, a multi-layered design, including priority retrieval of the public layer, state checking of the work area layer, and degradation strategy, achieves a balance between the comprehensiveness, timeliness, and resource efficiency of knowledge retrieval: the public layer provides general knowledge that can be reused across user groups, reducing the cost of repeated compilation; the work area layer provides user group-private accumulated knowledge; and the state-driven degradation strategy ensures that even when knowledge becomes invalid, users can still obtain the latest information through real-time data sources.

[0144] According to an embodiment of the present invention, step 204 includes: determining a context template corresponding to a role based on the role of a target account in a target user group; constructing a prompt message based on the context template and context information; and generating a response message corresponding to the target request based on the prompt message.

[0145] When generating responses, the intelligent agent combines the target account's role within the target user group with differentiated context templates. This allows the same question to elicit responses with varying granularities and focuses from different role perspectives. A role refers to the functional label assigned to the target account within the target user group, including but not limited to project manager, project member, department manager, product manager, development engineer, test engineer, and external collaborator. Role information is stored in the account attribute database and is configured by the user group administrator when the account is created or added to the user group, or obtained synchronously from a third-party authentication system.

[0146] The server (or the device where the agent resides) maintains a role-template mapping table, which can be configured independently for user groups or use the system default template. Each role corresponds to a preset context template. Optionally, the current user's project role, including administrator, project leader, and project member, is retrieved from the project master data. The corresponding context template is selected based on the role: the administrator template highlights departmental project portfolio health, cross-project risks, and overall milestone achievement; the project leader template highlights key milestones, overall progress, risk registration, and upgrade requirements; and the project member template highlights module work items, deadlines, technical risks, and dependency blocking. If the target account has no configured role or the role is not in the mapping table, the default template is used without special restrictions.

[0147] The context template is a predefined prompt structure stored as a string template, containing replaceable placeholders such as user group names, context information, and user requests. Optionally, the context template includes: role instructions (determining the answer perspective and focus based on the user role), conversation background (the project or user group environment in which the current dialogue takes place), output format constraints, and response style, used to guide the agent to generate responses according to the specific role's perspective, output format, and response style based on the acquired context information. Optionally, the context template guides the agent on how to organize, filter, and present context information. For example, the context template includes information scope, information granularity, data aggregation rules, and ignore rules, used to guide the extraction of a subset of information relevant to the current user role from the context information. For instance, a manager might focus on cross-project risks and departmental health, a project leader on milestones and global risks, and project members on personal work items and deadlines.

[0148] Optionally, when determining the context template based on the role, the server (or the device where the agent resides) queries the account attribute database to find the target account's role in the target user group. If the account has multiple roles, the most matching role can be selected according to priority rules, such as administrators having higher priority than project leaders, and project leaders having higher priority than members.

[0149] The agent assembles the selected role template, acquired context information, and relevant data from the project file into a context block. This context block is dynamically injected into the system prompt of the current session, serving as the context basis for the agent to generate a response. The agent generates the response information corresponding to the target request based on the injected system prompt.

[0150] For example, in a project, project leader A, member B, and manager C each ask the agent: "How is the project progressing?" The server identifies A as the project leader, selects a project leader template, and filters a subset of information relevant to the project leader from the context. The project leader template specifies that it should be from a holistic project perspective, highlighting key milestones and overall risks, and output in natural language paragraphs. The filtered information is then filled into template placeholders, and the agent is invoked to generate a response corresponding to A's role, describing the overall project progress.

[0151] The server identifies B as a project member, selects a project member template, filters out context related to B, fills the filtered information into template placeholders, and calls the agent to generate a response corresponding to B's role, describing personal work items, deadlines, associated risks, etc.

[0152] The server identifies role C as a department manager, selects a manager template, filters out cross-project summary information, fills the filtered information into template placeholders, and calls the agent to generate the corresponding response for role C, describing the health of the department-level project set and the risk distribution across projects.

[0153] Through the aforementioned role-aware differential injection, dynamic adaptation of context templates and personalized information presentation are achieved, enabling the same request to receive responses with different granularities and attention dimensions under different roles.

[0154] For the same question, different roles expect completely different levels of information granularity and focus. Current project management tools and AI agent frameworks lack the ability to automatically perceive user roles, typically injecting all project information or using fixed templates into the context, failing to automatically filter and reorganize information based on the questioner's role. This leads to two problems: first, full injection results in wasted tokens, with a large amount of information useless to the current role occupying the context window; second, the answers are off-focused, with the agent's generated responses failing to highlight what the role truly cares about, requiring the user to ask follow-up questions or manually specify a perspective.

[0155] To address this issue, this embodiment achieves differentiated context injection based on role awareness by identifying the target account's role within the target user group and matching it with the corresponding context template. Different templates are selected based on the role, and the role template, along with the retrieved context information, is used to construct a prompt message. A response is then generated based on this prompt message. This ensures that the output response automatically matches the information dimensions relevant to the user role, avoiding unfocused or redundant responses due to a lack of role awareness. Under the same context window and computational resource consumption, the relevance and accuracy of the response are improved. Furthermore, the context template supports user group-level custom configuration, flexibly adapting to the collaboration standards and reporting requirements of different teams, enhancing the practicality and scalability of the agent in complex multi-role environments.

[0156] In one optional implementation, step 202 includes: in response to receiving a target request based on a target session, determining the target account associated with the target session and the target user group to which the target account belongs; and if an association relationship is detected among the target user groups, obtaining context information corresponding to the target request from the shared context of the target user group and the shared context of the collaborating user groups that are associated with the target user group.

[0157] In this context, the relationship refers to the information sharing needs between two user groups in areas such as project collaboration, technical dependence, or business dealings. This allows members of a user group to simultaneously obtain relevant information from the shared context of both their own user group and related user groups when querying through an intelligent agent. Relationships can be configured by system administrators or accounts with cross-user group collaboration permissions in the user group management interface. They support one-to-one, one-to-many, or many-to-many relationships and can be configured with direction (e.g., unidirectional or bidirectional sharing) and sharing scope (e.g., sharing only risk information, milestone information, or full sharing).

[0158] Specifically, when a target request is received based on a target session, and the target user group and collaborating user group are associated, the server obtains the context information corresponding to the target request from both the shared context of the target user group and the shared context of the collaborating user group. Optionally, the target user group administrator enters the collaborating user group identifier and selects the association type and sharing strategy through the cross-user group collaboration configuration interface. The server records the association record in the relational database, including fields such as target user group identifier, collaborating user group identifier, association direction, sharing strategy, effective time, and validity period. Optionally, the association relationship can be temporary (e.g., valid within the joint project period) or automatically bound based on a common project identifier.

[0159] The server determines the target user group based on the target account and checks for any association relationships. If an association exists, it retrieves the associated collaborating user groups. Access is then determined based on the direction of the association: mutual access is allowed in bidirectional sharing; only the initiator is allowed access in unidirectional sharing. Optionally, the server can automatically determine whether cross-user group retrieval is necessary based on the semantic features of the request. For example, a cross-user group retrieval is triggered if the request explicitly mentions keywords related to the collaborating user group; otherwise, contextual information is retrieved only from the shared context of the target user group to improve efficiency.

[0160] After determining the list of user groups requiring access, the server independently executes the context acquisition process for each user group in parallel. This includes request type determination, path selection, data source reading or knowledge base retrieval, and data refinement, merging the context information fragments acquired by each user group. During merging, a source user group identifier is added to each fragment, relevance scores are retained, and the fragments are uniformly sorted across user groups. If duplicate or conflicting information exists, it is processed according to a preset priority, such as prioritizing target user group information or timestamp-updated information, while complementary information is merged and retained. Optionally, shared scope filtering can be applied to retrieve only information of a predetermined type.

[0161] Optionally, when the target user group needs to retrieve information from the shared context of the collaborating user group, the collaborating user group has set up a data security policy, meaning not all information is open to the target user group. The server uses a restricted service account or API key generated by the collaborating user group for this relationship, and the permissions of the restricted service account or API key are strictly limited to the scope of the shared policy agreed upon by both parties. If certain data sources or knowledge fragments are not visible to the target user group, they will naturally not be found during the retrieval phase or will be filtered before the results are returned. If an access request is explicitly denied due to insufficient permissions, the system will log a security message and skip that data source.

[0162] The context information fragments obtained from multiple user groups are merged, deduplicated, and sorted to form a final context information set, which maintains the same format as the context information in a single user group scenario. Optionally, each piece of context information is appended with a user group source field to indicate which user group the information belongs to. Optionally, before being passed to the agent, a prompt message can be made to explicitly inform the agent of the existence of cross-user group context, enabling the agent to accurately reflect the information's attribution and enhancing the transparency and credibility of the response.

[0163] In this embodiment, by employing a cross-user group shared context acquisition mechanism, the agent can integrate relevant information from multiple user groups across user group boundaries in user group association scenarios, and generate responses based on the integrated information. Users can obtain accurate responses that incorporate the collective memories of multiple teams without manually switching user groups or repeating queries, significantly reducing information barriers and communication costs in cross-user group collaboration and improving the collaborative efficiency of cross-user group projects.

[0164] A method according to an embodiment of the present invention, such as Figure 3 As shown, a data processing method is provided, which can be applied to... Figure 1 Taking server 104 as an example, the explanation includes:

[0165] Step 302: Receive the target request of the target account based on the target session, and obtain the context information corresponding to the target request from the shared context of the target user group to which the target account belongs; the sessions corresponding to different accounts in the target user group are isolated from each other.

[0166] The terminal has an application installed, such as a project management collaboration application, an instant messaging tool, or team collaboration software integrating intelligent agent capabilities. A server-side application corresponding to this application is deployed on the server. This server-side application is used to maintain the shared context of each user group, manage the invocation of intelligent agents, and handle backend tasks such as session requests. The data processing method provided in this embodiment can be implemented through this application. The terminal's application client is logged into with a target account (e.g., the account of the project leader or a project member), and the terminal communicates with the server based on this target account.

[0167] It is understood that, in this embodiment, the execution subject of the data processing method can be an intelligent agent instance (referred to as "intelligent agent" in this embodiment) or an application deployed on a server that is associated with the intelligent agent. This application can serve as an intermediary layer between the intelligent agent and the terminal. This embodiment uses the application as the execution subject for illustration.

[0168] The explanation of step 302 can be found in the explanation of step 202 above, and will not be repeated here. It should be noted that in this embodiment, the context information acquisition step is performed by an application deployed on the server.

[0169] In one alternative implementation, the shared context includes at least one of the following: user group data obtained by invoking the group agent corresponding to the target user group; the user group data includes session records between each account in the target user group and the group agent; data read in real time from multiple data sources corresponding to the target user group; and data retrieved from the knowledge data pre-stored in the shared knowledge base corresponding to the target user group; the knowledge data includes session records between each account in the target user group and the corresponding agent.

[0170] In one optional implementation, the context information corresponding to the target request is obtained from the shared context of the target user group to which the target account belongs. This includes: determining the request type of the target request based on the semantic features of the target request; if the request type is a first type, reading the original data corresponding to the target request from multiple data sources corresponding to the target user group; refining the original data to obtain the context information corresponding to the target request; and if the request type is a second type, retrieving the context information corresponding to the target request from the knowledge data pre-stored in the shared knowledge base corresponding to the target user group.

[0171] In one optional implementation, the request type of the target request is determined based on the semantic features of the target request, including: determining whether the target request includes preset time-sensitive keywords or preset drill-down keywords based on the semantic features of the target request; if the target request includes preset time-sensitive keywords or preset drill-down keywords, the request type of the target request is determined to be the first type; if the target request does not include preset time-sensitive keywords or preset drill-down keywords, the request type of the target request is determined to be the second type.

[0172] In one optional implementation, the shared knowledge base includes a public layer and a working area layer. The public layer is configured to store knowledge data shared by multiple user groups, and the working area layer is configured to store private knowledge data for each user group. The process involves retrieving context information corresponding to the target request from the pre-stored knowledge data of the target user group in the shared knowledge base. This includes: retrieving knowledge data corresponding to the target request in the public layer using a pre-defined semantic similarity retrieval algorithm; if no knowledge data is found, retrieving the knowledge data status of the target user group in the working area layer; if the knowledge data status indicates that the knowledge data of the target user group is invalid, reading the original data corresponding to the target request from multiple data sources corresponding to the target user group; and refining the original data to obtain the context information corresponding to the target request.

[0173] In an optional implementation, the method further includes: if it is identified that the content of the target request includes triggering information associated with the target user group, performing the step of obtaining the context information corresponding to the target request from the shared context of the target user group to which the target account belongs.

[0174] Step 304: Invoke the smart agent corresponding to the target account and generate the response information corresponding to the target request based on the context information.

[0175] The explanation of step 304 can be found in the explanation of step 204 above, and will not be repeated here. In an optional implementation, step 304 includes: determining a context template corresponding to the role of the target account in the target user group; constructing prompt information based on the context template and context information; and invoking the intelligent agent corresponding to the target account to generate a response information corresponding to the target request based on the prompt information.

[0176] Understandably, the application running on the server acts as a central invocation mechanism, dynamically selecting the agent instance matching the target account from multiple pre-deployed or dynamically created instances based on the account identifier, user group identifier, session identifier, and context information carried in the target request. Specifically, the application can maintain a routing table or instance pool containing dedicated instances corresponding to different accounts. Upon receiving a target request, the application first parses out the target account, determines the corresponding agent instance from the instance pool, activates that instance, and passes the integrated context information as input to the agent instance to generate the final response. This application deployed on the server can achieve flexible and accurate agent routing in a multi-instance environment, meeting the concurrent needs of multiple users.

[0177] Step 306: Send a response message to the target account through the target session.

[0178] For an explanation of step 306, please refer to the explanation of step 206 above, which will not be repeated here.

[0179] In this embodiment, based on the "one person, one session" isolation model, a shared context injection mechanism is added, enabling independent sessions of multiple accounts within the same user group to share the same context memory, significantly improving team collaboration efficiency. Response information corresponding to the target request is generated based on the acquired context information, achieving response generation based on the shared context of the user group rather than the independent memory of a single session. The response information is fed back to the target account through the target session, ensuring that each target account receives responses within its own session that include relevant information from the shared context of the user group, thereby achieving context interoperability between multiple sessions within the same user group. This method automatically synchronizes user group-level context memory between sessions, eliminating execution deviations caused by information asynchrony, thus improving the accuracy and contextual coherence of agent responses. Applying this method can provide team-shared project memory and decision-making assistance for project management, thereby improving the overall efficiency of project management.

[0180] According to an embodiment of the present invention, the method further includes: acquiring conversation records between each account and the corresponding intelligent agent in each user group within a preset period; extracting information fragments from the conversation records and performing knowledge compilation processing on the information fragments to obtain updated knowledge data for each user group; storing the updated knowledge data of each user group in a shared knowledge base, and updating the index data of the shared knowledge base according to the updated knowledge data.

[0181] In this system, an asynchronous knowledge accumulation mechanism (such as Auto Dream's automated batch processing tasks) automatically extracts new information from the conversation history (i.e., conversation records) of each user group during off-peak hours. After compilation and processing, this information is written into the shared knowledge base, thereby achieving continuous accumulation and updating of knowledge. This mechanism requires no manual intervention, ensuring that each user's every conversation contributes to the knowledge base of the entire user group, forming a positive knowledge accumulation flywheel.

[0182] For example, the server is configured with a scheduled task scheduler, such as configuring a scheduled task based on a Cron expression on the server. The preset period refers to the time interval between the trigger times of two adjacent asynchronous knowledge accumulation tasks. For example, each time a scheduled task (such as 2 AM every day) is triggered, the system will use the interval from the timestamp of the previous task completion to the timestamp of the current task trigger as the time range for retrieving session records. For example, the preset period can be set to once every 6 hours.

[0183] For example, the corresponding agent refers to the agent instance that actually interacts with each account; it can be an agent instance exclusive to an account or a group agent instance. The process involves obtaining the conversation records between each account and the corresponding agent in each user group within a preset period, including: determining the time range from the completion timestamp of the last knowledge accumulation task to the current trigger time; filtering active user groups and processing user groups with agent conversation interaction records within the time range; and retrieving the conversation history from the conversation history repository, querying all historical records of conversations associated with all accounts under each active user group within the time range, including user request text, agent response text, and metadata such as timestamps, conversation IDs, and account IDs. The server can retrieve data in batches and pages to avoid memory overflow. Optionally, conversation records marked as containing potential knowledge are retrieved. The marking is determined in real-time by the agent when generating a response. Unmarked records can be skipped or handled lightly, for example, marking conversation records where the user confirms a decision.

[0184] This involves extracting information fragments from historical records. The goal of extraction is to extract reusable knowledge units with long-term value from natural language dialogues, filtering out casual conversation and content devoid of substance. Optionally, the extraction process employs a large language model combined with a rule engine, including: text cleaning to remove irrelevant content such as system prompts, formatting tags, and special characters; information type identification, using classification models or large language models to determine the information type of each round of dialogue, including decisions, risks, milestone changes, task assignments, requirement clarifications, technical solution selections, meeting conclusions, etc.; and key information extraction, extracting structured fields based on information type, such as decision content, decision time, decision-maker, risk description, responsible person, task name, and deadline.

[0185] The extracted information fragments undergo knowledge compilation processing, specifically using a large language model to deduplicate, associate, and structure the fragments. Deduplication involves identifying and merging semantically repetitive or highly similar information fragments to avoid redundancy in the knowledge base. Association involves linking newly extracted fragments with existing knowledge entries in the shared knowledge base through semantic matching and keyword matching, forming a knowledge network. Structured compilation involves organizing fragmented natural language information into knowledge entries in a unified format according to a predefined knowledge model. Each knowledge entry contains preset fields, such as knowledge identifier, user group identifier, knowledge type, content summary, detailed description, timestamp, source session identifier, source account identifier, associated knowledge identifier, and version number. Optionally, the compilation process also includes conflict detection, comparing key attributes (such as date, status, and responsible person) under the same topic, and marking older knowledge as obsolete based on the fragment with the newer timestamp. If automatic judgment is not possible, it is marked as pending review and requires manual intervention, or multiple versions are retained along the timeline. Optionally, access permissions are marked for knowledge fragments based on the account role and session context of the information source.

[0186] The updated knowledge data for each user group is stored in a shared knowledge base, and the index data is updated synchronously. The shared knowledge base is partitioned according to user group identifiers, and the updated knowledge data belongs to the user group's private data and is stored in the working area layer. Optionally, the write operation adopts transactional write: the main content of the knowledge fragment, metadata and its calculated vector embedding, and full-text index data are written to the corresponding vector database and full-text search engine together. During the write process, incremental index updates are automatically triggered to ensure that the data can be retrieved immediately after being written. If any step fails, the entire process is rolled back to ensure data consistency. Optionally, for updated fragments, the old index is deleted first and then the new index is inserted; for newly added fragments, only incremental index construction is performed to avoid the overhead of full reconstruction.

[0187] In this embodiment, through an asynchronous knowledge accumulation mechanism, valuable information generated by each user's conversation can be automatically accumulated into shared knowledge of the user group, eliminating the need for manual organization and input, significantly reducing knowledge management costs, and ensuring that the knowledge base continues to grow automatically as the project progresses.

[0188] According to an embodiment of the present invention, referring to Figure 4This embodiment is applied to a company's project management system. The company's project team (hereinafter referred to as the "target user group") is executing an iterative development project for a mobile application. The target user group includes multiple members such as the project leader, front-end developers, back-end developers, and test engineers, each with their own independent platform account. All members' accounts belong to the target user group. The target user group's shared context has pre-stored historical information related to the project, including the risk matrix methodology, the risk list in the project file, and risk escalation thresholds confirmed in past meetings.

[0189] 1. The project manager logs into the client using their account and enters a natural language request in the intelligent agent conversation interface: "What risks need to be upgraded this week?" The client encapsulates this request into a data packet, carrying the target account identifier (project manager's account ID) and the target session identifier, and the terminal sends the data packet to the server. After receiving the request, the server parses out the target account identifier and the request text.

[0190] 2. The server has an internal context scheduler module. This module performs semantic parsing on the request text to extract key intents: risk, escalation, and the time-limited keyword "this week." The context scheduler determines whether the request contains preset time-sensitive keywords or drill-down keywords. Analysis shows that "this week" is not a preset time-sensitive keyword, therefore it is determined to be a regular request, and there is no need to trigger a full scan of the real-time data source.

[0191] 3. The server queries the account attribute database based on the target account identifier to obtain the user group identifier of the target user group to which the account belongs. The server accesses the storage space corresponding to the target user group in the shared knowledge base. Based on the keywords "risk," "escalation," and the time range "this week" in the request, the server performs multi-level searches in the public layer of the shared knowledge base and the workspace layer corresponding to the target user group. At the methodology layer, the server performs vectorized search and hits the pre-stored risk matrix, which records the scoring rules and threshold standards related to risk escalation judgment. At the project archive layer, the server hits the risk list file through keyword matching. This file records the description of known risks in the project, risk reporting messages, etc. The server sorts all the recalled relevant context information by relevance, merges them to form a context information list, and adds metadata such as information source, timestamp, and writing account.

[0192] 4. The server has multiple preset context templates. Assuming the target account's role is project manager, determine the corresponding overall project perspective template. Assemble the retrieved context information and the user's original request according to the overall project perspective template. A system prompt example is: "You are the project management agent for the target user group. The current user is the project manager. Please answer the user's question based on the following shared context information. Context information includes: risk matrix methodology, risk list file. User question: 'What risks need to be escalated this week?' Please output a structured risk report."

[0193] 5. Based on the target account identifier, the server locates the corresponding agent endpoint, invokes the agent, and inputs the assembled prompt. After receiving the input, the agent performs semantic understanding and reasoning to generate a structured risk report, which is then returned to the server.

[0194] 6. After receiving the response information generated by the agent, the server pushes the information to the project manager's client through the target session. The client displays the response content in the session interface, and each risk item is accompanied by a clickable reference marker. Clicking on the marker allows viewing the original record of that risk in the shared context. After reading the response, the project manager can ask follow-up questions or confirm escalation actions.

[0195] 7. To enrich the shared context, the server employs an asynchronous mechanism: During system downtime after the current dialogue concludes, a background task analyzes the question-and-answer pairs of the session to determine if any new information fragments (such as an upgraded conclusion) have been generated. If so, the server performs knowledge compilation on the newly generated information fragments, stores the updated knowledge data in the shared knowledge base, and updates the index data of the shared knowledge base. This way, when other members ask similar questions later, they can directly reuse this conclusion without recalculating it.

[0196] A method according to an embodiment of the present invention, such as Figure 5 As shown, a data processing method is provided, which can be applied to... Figure 1 Taking terminal 102 as an example, the explanation includes:

[0197] Step 202: In response to the target account entering a dialogue message in the conversation interface, a target request is sent to the agent corresponding to the target account based on the target conversation. This instructs the agent to obtain the context information corresponding to the target request from the shared context of the target user group to which the target account belongs, and to generate the response information corresponding to the target request based on the context information. Conversations corresponding to different accounts in the target user group are isolated from each other.

[0198] In this context, the target account refers to a uniquely identified user account logged into on the client side of the terminal. The conversation interface refers to the graphical user interface on the terminal used to display the dialogue content with the agent. For example, the conversation interface includes a message input box, a send button, and a historical message display area. When the target account types text or speech-to-text messages in the input box of the conversation interface and clicks the send button or presses the Enter key, the terminal detects the input operation and triggers the request sending process. Based on the trigger, the terminal determines the target conversation to which the dialogue belongs. The target conversation refers to the specific dialogue channel between the target account and the agent, and each conversation has a unique conversation identifier. The target account can have multiple conversations simultaneously, such as different chat windows or different topic discussions. For example, when the conversation interface is opened, it loads or creates a conversation and saves its conversation identifier in memory. When the user inputs a message, the terminal automatically packages the conversation identifier along with the message content and account information, and sends the target request to the agent corresponding to the target account. The agent corresponding to the target account refers to an agent instance or agent server endpoint that has a mapping relationship with that account. This mapping relationship can be pre-configured by the server: for example, each account is assigned a dedicated agent instance during registration. The terminal sends the target request to the server by calling the API interface provided by the server. The server then routes the request to the smart agent corresponding to the target account based on the account and session information in the request.

[0199] The specific processing procedures of the intelligent agent are explained in the embodiments of this application and will not be repeated here.

[0200] Step 202: Receive the response information from the agent through the target session.

[0201] Step 202: Display the reply information on the conversation interface.

[0202] For example, refer to Figure 6 A data interaction method is provided, comprising: 1. A terminal sending a target request to a server based on a target session; 2. The server sending the target request to an agent corresponding to the target account; 3. The agent obtaining context information corresponding to the target request from the shared context of the target user group to which the target account belongs; 4. The agent generating response information corresponding to the target request based on the context information; 5. The agent feeding back the response information to the server; 6. The server feeding back the response information to the terminal based on the target session.

[0203] According to an embodiment of the present invention, a data processing method applied to a terminal includes the following steps: in response to a target account inputting a dialogue message in a conversation interface, sending a target request to a server based on the target conversation, instructing the server to obtain context information corresponding to the target request from the shared context of the target user group to which the target account belongs, invoking the intelligent agent corresponding to the target account, and generating response information corresponding to the target request based on the context information; the conversations corresponding to different accounts in the target user group are isolated from each other; receiving the response information fed back by the intelligent agent through the target conversation; and displaying the response information on the conversation interface.

[0204] For example, refer to Figure 7 A data interaction method is provided, comprising: 1. A terminal sending a target request to a server based on a target session; 2. The server obtaining context information corresponding to the target request from the shared context of the target user group to which the target account belongs; 3. The server sending the context information corresponding to the target request to the agent corresponding to the target account; 4. The agent generating a response message corresponding to the target request based on the context information; 5. The agent sending the response message back to the server; 6. The server sending the response message back to the terminal based on the target session.

[0205] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0206] Based on the same inventive concept, this application also provides a data processing apparatus for implementing the data processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more data processing apparatus embodiments provided below can be found in the limitations of the data processing method described above, and will not be repeated here.

[0207] An apparatus according to an embodiment of the present invention, such as Figure 8 As shown, a data processing apparatus is provided, comprising:

[0208] The context scheduling module 802 is used to receive the target request of the target account based on the target session, and obtain the context information corresponding to the target request from the shared context of the target user group to which the target account belongs; the sessions corresponding to different accounts in the target user group are isolated from each other;

[0209] The intelligent agent module 804 is used to generate response information corresponding to the target request based on context information; and to send the response information back to the target account through the target session.

[0210] In the aforementioned data processing device, based on the "one person, one session" isolation model, a shared context injection mechanism is added, enabling independent sessions of multiple accounts within the same user group to share the same context memory, significantly improving team collaboration efficiency. The device generates response information corresponding to the target request based on the acquired context information, achieving response generation based on the shared context of the user group rather than the independent memory of a single session. The response information is fed back to the target account through the target session, ensuring that each target account receives responses within its own session that include relevant information from the shared context of the user group, thus achieving context interoperability between multiple sessions within the same user group. This method automatically synchronizes user group-level context memory between sessions, eliminating execution deviations caused by information asynchrony, thereby improving the accuracy and contextual coherence of agent responses. Applying this method can provide team-shared project memory and decision-making assistance for project management, thereby improving the overall efficiency of project management.

[0211] According to an embodiment of the present invention, the shared context includes at least one of the following: user group data obtained by invoking a group agent corresponding to a target user group; the user group data includes session records between each account in the target user group and the group agent; data read in real time from multiple data sources corresponding to the target user group; and data retrieved from knowledge data pre-stored in a shared knowledge base corresponding to the target user group; the knowledge data includes session records between each account in the target user group and the corresponding agent.

[0212] According to an embodiment of the present invention, the context scheduling module 802 is further configured to determine the request type of the target request based on the semantic features of the target request; if the request type is a first type, then read the original data corresponding to the target request from multiple data sources corresponding to the target user group; refine the original data to obtain the context information corresponding to the target request; if the request type is a second type, then retrieve the context information corresponding to the target request from the knowledge data corresponding to the target user group pre-stored in the shared knowledge base.

[0213] According to an embodiment of the present invention, the context scheduling module 802 is further configured to determine whether the target request includes preset time-sensitive keywords or preset drill-down keywords based on the semantic features of the target request; if the target request includes preset time-sensitive keywords or preset drill-down keywords, the request type of the target request is determined to be a first type; if the target request does not include preset time-sensitive keywords and preset drill-down keywords, the request type of the target request is determined to be a second type.

[0214] According to an embodiment of the present invention, the shared knowledge base includes a public layer and a working area layer. The public layer is configured to store knowledge data shared by multiple user groups, and the working area layer is configured to store knowledge data private to each user group. The context scheduling module 802 is further configured to use a preset semantic similarity retrieval algorithm to retrieve knowledge data corresponding to a target request in the public layer; if no knowledge data is retrieved, the knowledge data status corresponding to the target user group is retrieved in the working area layer; if the knowledge data status indicates that the knowledge data of the target user group is invalid, the original data corresponding to the target request is read from multiple data sources corresponding to the target user group; and the original data is refined to obtain the context information corresponding to the target request.

[0215] According to an embodiment of the present invention, the intelligent agent module 804 is further configured to determine a context template corresponding to a role based on the role of the target account in the target user group; construct a prompt message based on the context template and context information; and generate a response message corresponding to the target request based on the prompt message.

[0216] According to an embodiment of the present invention, the context scheduling module 802 is further configured to, if it is identified that the content of the target request includes trigger information associated with the target user group, execute the step of obtaining the context information corresponding to the target request from the shared context of the target user group to which the target account belongs.

[0217] An apparatus according to an embodiment of the present invention, such as Figure 9 As shown, a data processing apparatus is provided, comprising:

[0218] The scheduling module 902 is used to receive the target request of the target account based on the target session, and obtain the context information corresponding to the target request from the shared context of the target user group to which the target account belongs; the sessions corresponding to different accounts in the target user group are isolated from each other;

[0219] The agent invocation module 904 is used to invoke the agent corresponding to the target account, generate the response information corresponding to the target request based on the context information, and send the response information back to the target account through the target session.

[0220] According to an embodiment of the present invention, the shared context includes at least one of the following: data obtained by invoking a group agent corresponding to a target user group; data read in real time from multiple data sources corresponding to the target user group; data retrieved from knowledge data pre-stored in a shared knowledge base corresponding to the target user group; the knowledge data includes session records between each account and agent in the target user group.

[0221] According to an embodiment of the present invention, the data processing apparatus further includes an update module, which is configured to acquire conversation records between each account and the corresponding intelligent agent in each user group within a preset period; extract information fragments from the conversation records and perform knowledge compilation processing on the information fragments to obtain updated knowledge data for each user group; store the updated knowledge data of each user group in a shared knowledge base, and update the index data of the shared knowledge base according to the updated knowledge data.

[0222] An apparatus according to an embodiment of the present invention, such as Figure 10 As shown, a data processing apparatus is provided, comprising:

[0223] The sending module 1002 is used to respond to the target account entering a dialogue message in the conversation interface, and send a target request to the intelligent agent corresponding to the target account based on the target conversation, so as to instruct the intelligent agent to obtain the context information corresponding to the target request from the shared context of the target user group to which the target account belongs, and generate the response information corresponding to the target request based on the context information; the conversations corresponding to different accounts in the target user group are isolated from each other;

[0224] The receiving module 1004 is used to receive the response information fed back by the intelligent agent through the target session;

[0225] Display module 1006 is used to display reply information on the conversation interface.

[0226] Each module in the aforementioned data processing device 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, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0227] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 11As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores knowledge data, etc. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a data processing method.

[0228] Those skilled in the art will understand that Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0229] In one embodiment, a computer device is also provided, 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.

[0230] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0231] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0232] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0233] 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 above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0234] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0235] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A data processing method, characterized in that, The method includes: Based on the target session, the target account receives the target request, and obtains the context information corresponding to the target request from the shared context of the target user group to which the target account belongs; the sessions corresponding to different accounts in the target user group are isolated from each other; Based on the context information, generate the response information corresponding to the target request; The response information is sent back to the target account through the target session.

2. The method according to claim 1, characterized in that, The shared context includes at least one of the following: User group data is obtained by calling the group agent corresponding to the target user group; the user group data includes the session records between each account in the target user group and the group agent. Data read in real time from multiple data sources corresponding to the target user group; Data retrieved from the knowledge data pre-stored in the shared knowledge base corresponding to the target user group; the knowledge data includes the conversation records between each account and the corresponding agent in the target user group.

3. The method according to claim 2, characterized in that, The step of obtaining the context information corresponding to the target request from the shared context of the target user group to which the target account belongs includes: Based on the semantic features of the target request, determine the request type of the target request; If the request type is the first type, then read the original data corresponding to the target request from multiple data sources corresponding to the target user group; refine the original data to obtain the context information corresponding to the target request; If the request type is the second type, then the context information corresponding to the target request is retrieved from the knowledge data pre-stored in the shared knowledge base corresponding to the target user group.

4. The method according to claim 3, characterized in that, Determining the request type of the target request based on its semantic features includes: Based on the semantic features of the target request, determine whether the target request includes preset time-sensitive keywords or preset drill-down keywords; If the target request includes preset time-sensitive keywords or preset drill-down keywords, then the request type of the target request is determined to be the first type; If the target request does not include preset time-sensitive keywords and preset drill-down keywords, then the request type of the target request is determined to be the second type.

5. The method according to claim 3, characterized in that, The shared knowledge base includes a public layer and a working area layer. The public layer is configured to store knowledge data shared by multiple user groups, and the working area layer is configured to store the private knowledge data of each user group. The step of retrieving the context information corresponding to the target request from the knowledge data pre-stored in the shared knowledge base corresponding to the target user group includes: Using a preset semantic similarity retrieval algorithm, knowledge data corresponding to the target request is retrieved in the public layer; If no knowledge data is found, the knowledge data status corresponding to the target user group is retrieved in the work area layer; If the knowledge data status indicates that the knowledge data of the target user group is invalid, then the original data corresponding to the target request is read from multiple data sources corresponding to the target user group; the original data is refined to obtain the context information corresponding to the target request.

6. The method according to any one of claims 1 to 5, characterized in that, The step of generating the response information corresponding to the target request based on the context information includes: Based on the role of the target account in the target user group, determine the context template corresponding to the role; Based on the context template and the context information, construct the prompt message; Generate a response to the target request based on the prompt information.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: If the content of the target request is found to include triggering information associated with the target user group, the step of obtaining the context information corresponding to the target request from the shared context of the target user group to which the target account belongs is executed.

8. A data processing method, characterized in that, The method includes: Based on the target session, the target account receives the target request, and obtains the context information corresponding to the target request from the shared context of the target user group to which the target account belongs; the sessions corresponding to different accounts in the target user group are isolated from each other; The agent corresponding to the target account is invoked to generate the response information corresponding to the target request based on the context information. The response information is sent back to the target account through the target session.

9. The method according to claim 8, characterized in that, The shared context includes at least one of the following: Data obtained by calling the group agent corresponding to the target user group; Data read in real time from multiple data sources corresponding to the target user group; Data retrieved from the knowledge data pre-stored in the shared knowledge base corresponding to the target user group; the knowledge data includes conversation records between each account and the agent in the target user group.

10. The method according to claim 9, characterized in that, The method further includes: Acquire the conversation records between each account and the corresponding agent in each user group within a preset period; Information fragments are extracted from the session records, and knowledge compilation processing is performed on the information fragments to obtain updated knowledge data for each user group; The updated knowledge data for each user group is stored in the shared knowledge base, and the index data of the shared knowledge base is updated according to the updated knowledge data.

11. A data processing method, characterized in that, The method includes: In response to the target account entering a dialogue message in the conversation interface, a target request is sent to the agent corresponding to the target account based on the target conversation. This instructs the agent to obtain the context information corresponding to the target request from the shared context of the target user group to which the target account belongs, and to generate the response information corresponding to the target request based on the context information. The conversations corresponding to different accounts in the target user group are isolated from each other. Receive the response information fed back by the intelligent agent through the target session; The response information is displayed on the conversation interface.

12. A data processing apparatus, characterized in that, The device includes: The context scheduling module is used to receive target requests from target accounts based on target sessions, and to obtain context information corresponding to the target requests from the shared context of the target user group to which the target account belongs; sessions corresponding to different accounts in the target user group are isolated from each other; The intelligent proxy module is used to generate response information corresponding to the target request based on the context information; and to send the response information back to the target account through the target session.

13. 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 11.

14. 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 11.

15. A computer program product, comprising a computer program, 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 11.

Images