Task processing method, device and equipment for multi-agent system

Abstract

The embodiment of the invention provides a task processing method, device and equipment for a multi-agent system. According to the scheme, the system comprises a planning agent, an execution agent, a context injection module and a memory storage module; wherein when a planning agent needs to perform task planning for a user request, a context acquisition request is sent to the context injection module, and the context acquisition request comprises task description information of the user request; afterwards, the context injection module responds to the context acquisition request and acquires a planning context related to the task planning from a memory storage module based on the task description information, and the memory storage module stores historical data generated when each agent in the multi-agent system executes a historical task; afterwards, the planning agent receives the planning context, and generates a calling instruction for calling the execution agent based on the task description information and the planning context;

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of artificial intelligence and data analysis technology, and particularly to a task processing method for multi-agent systems. This specification also relates to one or more embodiments of a task processing apparatus for multi-agent systems, and a computing device. Background Technology

[0002] With the development of artificial intelligence technology, multi-agent systems are increasingly being used in complex data analysis scenarios. These systems typically consist of multiple agents with specific functions working collaboratively. For example, a planning agent is responsible for task decomposition and process scheduling, while an execution agent is responsible for specific queries, calculations, or report generation. Through division of labor and collaboration, the system can handle complex analytical tasks that are difficult for a single agent to complete.

[0003] However, in the process of multi-agent collaborative execution of complex data analysis tasks, the system's context management faces severe challenges, which directly restricts the system's performance, efficiency, and intelligence level. Summary of the Invention

[0004] In view of this, one or more embodiments of this specification provide task processing methods, apparatus, and devices for improving the context management capabilities of multi-agent systems.

[0005] According to a first aspect of one or more embodiments of this specification, a task processing method is provided, the system including a planning agent, an execution agent, a context injection module, and a memory storage module; the method includes: When the planning agent needs to plan a task in response to a user request, it sends a context acquisition request to the context injection module; the context acquisition request contains the task description information of the user request. In response to the context acquisition request, the context injection module obtains the planning context related to the current task planning from the memory storage module based on the task description information; the memory storage module stores historical data generated by each agent in the multi-agent system when executing historical tasks. The planning agent receives the planning context and, based on the task description information and the planning context, generates a call instruction for invoking the execution agent.

[0006] According to a second aspect of one or more embodiments of this specification, a task processing apparatus is provided for use in a multi-agent system, comprising: The planning agent is configured to send a context acquisition request to the context injection module when task planning is required in response to a user request; the context acquisition request contains task description information of the user request. The context injection module is configured to, in response to the context acquisition request, acquire the planning context related to the current task planning from the memory storage module based on the task description information; The memory storage module is configured to store historical data generated by each agent in the multi-agent system when performing historical tasks. The planning agent is also configured to receive the planning context and, based on the task description information and the planning context, generate a call instruction for invoking the execution agent.

[0007] According to a third aspect of one or more embodiments of this specification, a computing device is provided, including a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor executes the computer instructions to implement the steps of the task processing method.

[0008] One embodiment of this specification achieves at least the following beneficial effects: By enabling the planning agent to proactively request a planning context that integrates relevant historical data from an independent context injection module before initiating planning, the planning decision-making function and the context information support function are decoupled and specialized. This allows the planning agent to make decisions in a cognitive environment enhanced by rich and accurate historical information, significantly improving the accuracy and rationality of task decomposition and planning. Furthermore, the dedicated module assembles the context on demand, optimizing information retrieval efficiency and reducing the processing burden on the planning agent, thereby improving the overall system response speed and quality. In addition, this architecture allows the system's planning capabilities to continuously learn and evolve from accumulated historical data and experience, laying the foundation for continuous improvement in the system's intelligence level and the scalability of the architecture. Attached Figure Description

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

[0010] Figure 1 A schematic diagram of a system framework for a multi-agent system provided in the embodiments of this specification; Figure 2A flowchart illustrating a task processing method for a multi-agent system provided in an embodiment of this specification; Figure 3 A schematic diagram of a planning context compression and structured summary scheme based on quality assessment provided in the embodiments of this specification; Figure 4 A schematic diagram illustrating a method for dynamic context construction and injection provided in an embodiment of this specification; Figure 5 A flowchart illustrating a method for compressing and storing the products of a multi-agent system, provided as an embodiment of this specification. Figure 6 A flowchart illustrating a method for storing and managing long-term memory, provided as an embodiment of this specification; Figure 7 This is a flowchart illustrating a task processing method for a multi-agent system in a practical application scenario provided by an embodiment of this specification. Figure 8 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a task processing device; Figure 9 This is a structural block diagram of a computing device provided as an embodiment of this specification. Detailed Implementation

[0011] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0012] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0013] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0014] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0015] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0016] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0017] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0018] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0019] 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, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0020] The following explains the terms and concepts used in one or more embodiments of this specification.

[0021] Large-scale artificial intelligence models (or simply "large models") refer to a class of artificial intelligence models with a large number of parameters built from artificial neural networks. Large models are also known as foundational models. They are pre-trained on large-scale unlabeled corpora, producing pre-trained models with hundreds of millions of parameters. These models can adapt to a wide range of downstream tasks and have good generalization ability. Examples include Large Language Models (LLMs) and multi-modal pre-training models.

[0022] Large Language Models (LLMs) are deep learning models trained on massive amounts of text data, enabling them to generate natural language text or understand the meaning of language text. LLMs can provide in-depth knowledge and language production on a wide range of topics through training on large datasets. They learn patterns and structures of natural language through large-scale unsupervised training, mimicking human language cognition and generation processes to some extent. LLMs employ a similar Transformer architecture and pre-training objectives as smaller models, with the main differences being increased model size, training data, and computational resources. Compared to traditional Natural Language Processing (NLP) models, LLMs can better understand and generate natural text, while also exhibiting some logical thinking and reasoning abilities. LLMs possess context learning capabilities. Context learning (LLM) capabilities enable learners to learn complex patterns in language and perform a wide range of tasks, including text summarization, translation, sentiment analysis, multi-turn dialogue, and more. For example, LLM can include the GPT series, T5 (Text Learning Model), and other related technologies. to Text Transfer Transformer (TTL) model, PaLM model, BERT, LLaMA (Large Language Model MetaAI) model, Tongyi Qianwen model, Bailing model, etc.

[0023] An intelligent agent is a proxy capable of perceiving its environment and taking actions to achieve specific goals. It can be software, hardware, or a system, possessing autonomy, adaptability, and interactivity. By perceiving changes in the environment (e.g., through sensors or data input), an intelligent agent makes judgments and decisions based on its learned knowledge and algorithms, and then executes actions to influence the environment or achieve predetermined goals. Typically, a large model (such as a large language model) serves as the "brain" of the intelligent agent, providing cognitive capabilities, while the agent integrates modules such as perception, planning, and action to achieve autonomous task execution.

[0024] A multi-agent system (MAS) is a computing system composed of multiple autonomous, interactive agents that can collaborate to accomplish specific tasks or solve complex problems. Each agent is an independent entity with its own goals, knowledge, and behavioral capabilities, and can communicate and coordinate with other agents without central control. MAS are characterized by autonomy, distribution, interactivity, heterogeneity, and adaptability, and have shown great potential in fields such as artificial intelligence, economics, transportation, healthcare, and environmental protection. However, MAS also faces challenges such as communication overhead, consistency, security, and scalability.

[0025] In traditional multi-agent system architectures, agents (including planning agents and execution agents) are typically isolated from their contexts. The planning agent attempts to embed all potentially relevant background information when distributing task instructions, while each execution agent often needs to independently retrieve and understand the context required for the task before execution. This pattern leads to severe redundant reasoning, wasted computational resources, and referential resolution errors due to information inconsistencies. The lack of a unified context-sharing mechanism prevents the effective reuse of historical conclusions and experiences among agents, resulting in low overall system efficiency, poor result consistency, and limited architectural scalability.

[0026] In the embodiments of this specification, a novel system architecture is proposed, constructing an independent context injection module as a dedicated service layer between the planning agent and the various execution agents. Specifically, this context injection module can be a centralized management tool for the system context. Through this design, the planning agent is freed from the burdensome responsibilities of context retrieval and encapsulation, allowing it to focus on its core task decomposition and process planning logic; simultaneously, each execution agent no longer needs to repeatedly retrieve background information.

[0027] Based on the embodiments described in this specification, the system achieves unified management, on-demand assembly, and precise injection of background information and runtime context through an independent context injection module. The system utilizes a combination of relational databases and vectorized semantic retrieval technology to support precise retrieval and fusion of information such as historical dialogues, business semantics, task outputs, and execution trajectories from multiple dimensions, forming a structured context for the required intelligent agents.

[0028] Based on the embodiments described in this specification, firstly, knowledge sharing among agents is achieved, fundamentally eliminating information silos. Context is uniformly prepared and distributed by the intermediate layer, avoiding repeated acquisition and reasoning of the same background knowledge by each agent, significantly reducing the overall system reasoning overhead, shortening the task execution cycle, and improving single-round execution efficiency. Secondly, the system modules have clear responsibilities and are highly decoupled. The planning agent focuses on decision-making, while the context injection module specializes in information supply. Both can evolve and be optimized independently. This design greatly enhances the system's maintainability and robustness, and lays a solid foundation for supporting more complex multi-agent collaboration and large-scale system expansion in the future.

[0029] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0030] Figure 1 This is a schematic diagram of the system framework of a multi-agent system provided in the embodiments of this specification.

[0031] like Figure 1 As shown, during the interaction between a user and a multi-agent system (MAS) via a terminal device, in response to a user request (101), the MAS can retrieve memory information from the memory storage module in response to the current request prompt (including the current task description information corresponding to the user request, etc.) or during the generation of the current request prompt (step 102). For example, it can perform vector retrieval, keyword matching, language model-based retrieval, etc. Furthermore, it can recall memory information from the database (including relational databases, vector databases, etc.) of the memory storage module (step 103); then, the MAS can generate response information based on the recalled memory information (step 104) and return the response information to the user (step 105).

[0032] The memory storage module stores historical data generated by each agent in the multi-intelligence system during the execution of user requests. Specifically, asynchronously with the aforementioned process of generating response information in response to user requests, the multi-intelligence system can store new memory information generated during the task execution process in response to user requests as short-term memory information (step a); furthermore, it can extract long-term memory information based on the short-term memory information (step b); and then, it can update the database (including relational databases, vector databases, etc.) based on the short-term memory information and long-term memory information (step c). In practical applications, the database update steps may include, but are not limited to, adding, deleting, and updating.

[0033] In such Figure 1In the described application scenario, the short-term memory submodule can receive information generated by the current session and recent tasks, filter, compress, and structure the planning-related context, session metadata, and intermediate products from the data analysis process, and write the results into the database for storage so that they can be quickly retrieved in subsequent requests. In practical applications, a quality-assessment-based compression mechanism can be introduced into the short-term memory submodule to actively control the scale of context terms while ensuring task execution effectiveness. Furthermore, a multi-level product compression strategy can be adopted, with hierarchical processing from format parsing and structure extraction to model summarization, enabling the system to select content of appropriate granularity for reuse under different context budgets and task requirements. Details are described in detail below.

[0034] In such Figure 1 In the application scenarios described, the long-term memory submodule can be used to store relatively stable information across sessions and tasks, such as user or team preferences and prior knowledge, typical task structures, and historical experience, and supports writing, updating, and deleting memory entries.

[0035] In such Figure 1 In the described application scenario, the memory search unit can work collaboratively using three methods: vector retrieval, keyword matching, and language model-based retrieval. It retrieves memory fragments relevant to the current task from both short-term and long-term memory, and accordingly completes the dynamic construction and injection of context based on the fusion of long and short-term memories. This allows each agent in a multi-agent system to operate based on the shared memory injected by the system, thereby alleviating problems such as insufficient memory sharing among multiple agents and repetitive reasoning on the same problem.

[0036] In such Figure 1 In the application scenarios shown, the memory storage module can be part of a multi-agent system. This multi-agent system can be deployed and run on a corresponding computing device. This computing device can include, but is not limited to, any device, equipment, platform, or cluster of devices with computing and processing capabilities. For example, the computing device may include smart wearable devices, smartphones, tablets, laptops, desktop computers, in-vehicle computers, servers, or server clusters or cloud computing service centers composed of multiple servers, etc., and this specification does not specifically limit this. The computing device running the multi-agent system can connect to one or more terminal devices via a local area network (LAN), wide area network (WAN), internet connection, or other types of data networks. Users can interact with the multi-agent system through user interfaces (such as graphical user interfaces) provided by these terminal devices.

[0037] Considering that multi-agent systems are built upon large models, which have a vast number of parameters, and that mobile terminals have limited computing resources, the task processing methods provided in the embodiments of this specification can generally be applied to server devices. It should be noted that, provided the terminal device's operating resources can meet the deployment and operation requirements of the large model, the embodiments of this specification can be performed on a terminal device.

[0038] In related technologies, planning agents in multi-agent systems often bear an excessive burden of responsibility. When generating instructions to be issued to the underlying execution agents, the planning agent needs to clarify and encapsulate all necessary background information and execution context. However, due to the multi-dimensionality, large volume, and complex relationships of this information, it is often impossible to express it concisely and completely through a single instruction prompt. Forcing the planning agent to complete this task independently would make its task processing logic exceptionally complex. Limited by the capabilities of the large model itself, it is difficult for it to reliably complete such complex context retrieval, filtering, and integration tasks in a single planning iteration.

[0039] To address the aforementioned issues, embodiments of this specification propose a separate context injection module. By introducing this module, embodiments of this specification separate the responsibilities of unified management of context information, cross-agent context sharing, and on-demand injection from the planning agent. The planning agent can then focus on its core decision-making and process decomposition logic, while the context injection module is specifically responsible for dynamically assembling and providing high-quality context information from system storage according to task requirements. This separation of responsibilities architecture allows each party to leverage its capabilities more efficiently and professionally, thereby improving the overall reliability and efficiency of the system in handling complex tasks.

[0040] In practical applications, the context injection module can be used as a system-driven tool dedicated to context management, without requiring the autonomous memory and proactive planning capabilities typically needed by intelligent agents.

[0041] The embodiments in this specification provide a task processing method. This application also relates to a task processing apparatus and a computing device, which will be described in detail in the following embodiments.

[0042] Figure 2 This is a flowchart illustrating a task processing method for a multi-agent system provided in an embodiment of this specification.

[0043] From a programming perspective, the entity executing the process can be a program hosted on a server or terminal. It can be understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities.

[0044] The multi-agent system includes a planning agent, an execution agent, a context injection module, and a memory storage module.

[0045] like Figure 2 As shown, the process may include the following steps: Step 202: When the planning agent needs to plan a task in response to a user request, it sends a context acquisition request to the context injection module; the context acquisition request contains the task description information of the user request.

[0046] The multi-agent system comprises multiple agents. These agents include a planning agent and an execution agent.

[0047] A planning agent, also known as a planning module, refers to the agent in a multi-agent system responsible for high-level task decomposition and process control. The planning agent can understand user requests, break them down into a series of ordered, executable subtasks, and determine the execution order and logic.

[0048] An executing agent refers to the agent in a multi-agent system responsible for implementing specific tasks. In practical applications, each executing agent has specific functions (such as data querying, code generation, and chart drawing), receives and executes instructions from the planning agent, and returns the execution results.

[0049] The context injection module can refer to a dedicated module independent of the planning and execution agents. As an information middleware layer of the system, the context injection module dynamically retrieves, integrates, and injects relevant historical information and background knowledge from various storage sources according to the needs of the planning or execution phase, thereby enhancing the context awareness capabilities of decision-making and execution.

[0050] A memory storage module refers to a storage system used to persistently store various types of data generated during the operation of the multi-agent system. The memory storage module can be a shared storage space among the agents in the multi-agent system. It can store historical task data generated by each agent in the multi-agent system during the execution of historical tasks. The data in the memory storage module can be used as context for each agent. For example, it can be used as planning context for the planning agent, or execution context for the executing agent (by injecting it into the calling instructions).

[0051] From the perspective of stored data content, the historical data stored in the memory storage module can include not only the final output but also complete records of the collaborative process, such as internal workflow instruction records, intermediate products, and structured summaries. From the perspective of stored data format, the memory storage module can include structured databases and vector databases. The context injection module can retrieve and fuse multi-dimensional relevant data from the memory storage module based on the current task description to generate a context for planning enhancement.

[0052] A user request, also known as a user instruction, can come directly from the user (using natural language) and is used to express the user's intent. User requests are characterized by being unstructured, ambiguous, and potentially unnecessarily clear. For example, "Analyze the sales volume of brand XX and predict the trend next month."

[0053] Task descriptions, generated by the system (such as the Planner Agent), guide the agent on what specific tasks to perform. Task descriptions are characterized by being structured, explicit, and executable. For example, "Call the sales API to retrieve Q1-Q2 data for 2024."

[0054] In practical applications, during the task understanding and planning phase, user instructions are input into the planning agent. The planning agent can then generate one or more task descriptions (potentially with dependencies). This allows the planning agent to parse ambiguous user instructions into a sequence of executable subtasks. For example, "analyze sales" can be broken down into {data acquisition, data cleaning, trend analysis, and prediction}. During the execution scheduling and context injection phase, the context can be retrieved based on the semantics or metadata (such as task type and dependency ID) in the task description, recalling historical artifacts related to the task description from shared memory.

[0055] A context acquisition request refers to an instruction initiated by the planning agent to request information from the context injection module. A context acquisition request can carry task description information, that is, a textual description of the task to be planned.

[0056] In this specification, when task planning is required in response to a user request, a decision point is defined where the planning agent is located—that is, the planning agent has received the task and determined that planning is needed, but has not yet started executing the specific planning algorithm. In the embodiments of this specification, at the task planning decision point, the planning agent actively sends a context acquisition request to an independent context injection module. For example, after the planning agent is invoked, its entry function can first determine the task complexity, whether it can directly map historical solutions, etc. If the conclusion is "yes", it can trigger the "planning is needed" state, and then execute the "request context" process. Step 202 can also be expressed as the planning agent sending a context acquisition request to the context injection module when starting task planning for the user request.

[0057] In practical applications, when the planning agent determines that a user request needs to be decomposed and planned, it can not start planning calculations immediately. Instead, it can first send a context acquisition request to the independent context injection module and pass the task description information of the current task to be planned as a parameter to the context injection module.

[0058] Step 204: In response to the context acquisition request, the context injection module obtains the planning context related to the current task planning from the memory storage module based on the task description information; the memory storage module stores historical data generated by each agent in the multi-agent system when executing historical tasks.

[0059] Planning context refers to the set of information dynamically generated by the context injection module in response to requests, used to assist in task planning decisions. Based on the current task description, planning context can extract relevant historical dialogues, past results, experience summaries, etc. from stored historical data, providing a reference for the planning agent's planning operations.

[0060] In practical applications, the context injection module can receive and respond to context retrieval requests. The module parses the task description information and proactively queries and retrieves various historical data related to the current planning decision from the memory storage module (e.g., how similar tasks were solved in the past, previous user preferences, and existing relevant results). Subsequently, the context injection module can fuse and assemble this retrieved information to generate a customized planning context information package.

[0061] In one or more embodiments of this specification, a specific scheme is further provided for the context injection module to obtain the planning context related to the current task planning.

[0062] Step 204, which involves obtaining the planning context related to the current task planning, specifically includes: obtaining the historical dialogue records and historical output data of the current session to which the user request belongs; the historical dialogue records are the internal workflow records generated by the multi-agent system during the execution of historical tasks; the historical output data are the substantive result data generated and output by the multi-agent system after the execution of historical tasks; and generating the planning context based on the historical dialogue records and the historical output data.

[0063] Historical dialogue records refer to the complete record of the internal workflow between the planning agent and the executing agents during a single task session. Typically, historical dialogue records include the user's original request, the logical instructions issued by the planning module to each executing agent, and the intermediate execution status and textual response summary returned by the executing agents to the planning module. Historical dialogue records the process of "how" the agents in a multi-agent system collaborate.

[0064] Historical output content refers to the substantial result data generated and ultimately output to the user or used for subsequent steps after the multi-agent system has executed historical tasks. Historical output content can include structured data results returned by database queries, or visual charts and analysis reports generated by the system. Examples include structured data tables directly returned by database queries (such as a list of the top 3 courier companies), automatically generated visual chart files, or final analysis report documents. Historical output content represents the result of "what was obtained."

[0065] In practical applications, when the planning agent (Planner) needs to plan tasks, the context injection module can perform the following actions: data query: The context injection module locates the session to which the current user request belongs, then queries all historical dialogue records generated within that session from the session database, and queries relevant historical output content from the output database; information assembly: The context injection module assembles these two types of data according to chronological order or logical relevance to form an information aggregate, which contains all the process and result backtracking information required for planning the next step; context generation: The context injection module performs necessary formatting processing on this assembled information aggregate to generate a planning context that can be directly received and processed by the planning agent.

[0066] For example, consider a user request to "find the three courier companies with the highest shipment volume".

[0067] The retrieved historical dialogue records may include user input, instructions issued by the planning agent, and responses returned by the executing agent. For example, the user input might be: "Please find the three courier companies with the highest shipment volumes." The instructions issued by the planning agent would be: "Agent1, query the 'xxx' table, group by 'courier_company' and summarize the 'volume' field, sort by the summarized value in descending order, retrieve the top 3, and return the results." The response returned by the executing agent would be: "Instruction received. Query complete, results ready." The retrieved historical output content may be: a table containing three rows of data, such as [["A Express", 150000], ["B Express", 120000], ["C Express", 90000]].

[0068] Furthermore, the planning context generated based on the above historical dialogue records and historical output content can provide the planning agent with a complete "user intent -> planning instruction -> execution feedback -> specific result" chain, so that the planning agent can decide the next operation (e.g., whether to return the result directly or continue to generate charts).

[0069] Based on the embodiments described in this specification, by systematically integrating historical dialogue records (processes) and historical output content (results), a complete and coherent task execution backtracking view is provided for the planning agent. This ensures that planning decisions are not based on fragmented or partial memories, but on a complete collaborative history, thereby significantly improving the accuracy and contextual coherence of subsequent planning steps and avoiding erroneous decisions or repeated executions due to missing information.

[0070] In one or more embodiments of this specification, a scheme for compressing context data is further provided.

[0071] Specifically, after generating the planning context based on the historical dialogue records and the historical product data, the process may further include: calculating the number of lexical units in the planning context; determining whether the number of lexical units is greater than or equal to a preset lexical unit threshold; if the number of lexical units is greater than or equal to the lexical unit threshold, then performing data compression processing on at least a portion of the data in the planning context to obtain summary data.

[0072] In this specification, the lexical count, in the embodiments, can represent the number of tokens after word segmentation by a specific Large Language Model (LLM) when the text content of the planning context is input into it. The lexical count is an important indicator for measuring the length of the context text and the consumption of computational resources.

[0073] The lexical count threshold can be a preset capacity warning line used to trigger the compression process. Typically, this threshold can be set based on the context window capacity and performance requirements of the large language model used. For example, it can be set to 70% of the model's maximum context capacity. When the number of lexical units in the planned context reaches or exceeds this threshold, it indicates that continued accumulation may affect the model's processing efficiency or stability.

[0074] Furthermore, based on the capacity monitoring and compression triggering mechanism for the generated planning context in the embodiments of this specification, after the context injection module generates the planning context, on the one hand, the system can return the planning context to the planning agent; on the other hand, the system can asynchronously execute capacity calculation, threshold judgment, and compression decision and triggering steps. In the capacity calculation step, the system calls the word segmenter or model pre-interface to quickly calculate the number of lexical units in the current planning context; in the threshold judgment step, the system can compare the calculated number of lexical units with a preset lexical unit threshold; in the compression decision and triggering step, if the number of lexical units is less than the threshold, it indicates that the current context is within a safe capacity and can be used directly; if the number of lexical units is greater than or equal to the threshold, it indicates that the context has been over-expanded and needs to be simplified. At this time, the system triggers a data compression process to compress at least a part of the planning context (usually the earlier part with potentially lower information density), with the goal of expressing similar semantics with fewer lexical units and generating a concise summary data.

[0075] For example, suppose the context window of the large language model is 8000 tokens, and the lexical number threshold is set to 5600 (70%). After multiple rounds of planning for a complex task, the assembled planning context has 6000 tokens. Since 6000 > 5600, the system triggers an asynchronous compression process. The compression module may summarize the detailed dialogue and intermediate products of the previous rounds, generating a summary data described using only 500 tokens (e.g., "The user initially requested to analyze express delivery data; Step 1 has been executed: the top three in terms of total volume are A Express, B Express, and C Express; Step 2: a comparison bar chart has been generated."). After compression, the new context used for actual planning may consist of "this summary data (500 tokens) + the complete record of the most recent one or two rounds (1000 tokens)," reducing the total lexical number to a safe range.

[0076] Based on the embodiments described in this specification, a preventative, capacity-based intelligent compression triggering mechanism is introduced. By monitoring the resource consumption of the context in real time, it proactively intervenes and initiates the compression process before problems occur (such as model overload, slow response, or errors). This effectively prevents system performance degradation or planning failures caused by the unlimited expansion of the context, ensuring the long-term stability and sustainability of multi-round complex task interactions, and achieving a dynamic balance between information integrity and processing efficiency.

[0077] In one or more embodiments of this specification, the step of compressing at least a portion of the data in the planning context to obtain summary data specifically includes: determining target round data in the planning context; the target round data is data corresponding to a dialogue round that is more than N rounds away from the current dialogue round; where N is a positive integer; and performing data compression on the target round data to obtain summary data.

[0078] The target round data refers to the portion of data in the planning context that is furthest from the current round in the multi-round dialogue and execution records. Specifically, it can be defined by a positive integer N: any record with an interval greater than N rounds from the current dialogue round is included in the target round data. N is a configurable parameter; for example, setting it to 2 means always retaining the latest two complete rounds of records.

[0079] Data compression processing refers to the semantic extraction and reconstruction process of data from a target round. The goal of data compression processing is to integrate and summarize detailed information (such as instructions, feedback, and product summaries from multiple steps) scattered across multiple rounds of records, generating a highly condensed and structured text description, i.e., a summary data.

[0080] In practical applications, the system first analyzes the structure of the planning context, identifies the "round" label corresponding to each round's record, and then calculates their distance from the latest round. Records with a distance greater than a preset value N are filtered out and categorized as target round data. Next, the filtered target round data (which may contain multiple rounds of user input, planning instructions, agent responses, and output summaries) is sent as input to a dedicated structured summary module (usually a large language model). This module's task is to understand these historical records and generate a shorter, more structured summary text that focuses on key facts and conclusions—the summary data. Meanwhile, records less than or equal to N rounds from the current round are fully preserved.

[0081] Continuing the example above, we can set N=2. Assume we are currently in the 8th round of planning. The planning context contains all historical records from rounds 1 to 7. The system determines the target round data to be the records from rounds 1 to 5 (because it's more than 2 rounds away from round 8). The system sends the complete dialogue and output summaries (potentially several thousand tokens) from rounds 1-5 to the summary model. The summary model generates a summary: "At the beginning of the task (rounds 1-5), the user requested analysis of express delivery data. The system sequentially performed: 1) querying all data and confirming the data source; 2) cleaning records with abnormal dates; 3) calculating weekly delivery volume by company. Key intermediate conclusion: data quality is good, ready for in-depth analysis." In practical applications, this summary might only use a few hundred tokens. Ultimately, the context used for the 8th round of planning can consist of the above summary data and the complete records from rounds 6 and 7.

[0082] Based on the embodiments described in this specification, a balance between high-fidelity compression and continuous context is achieved. Specifically, through a preset compression strategy (compressing distant history and retaining recent history), the overall volume of the context is significantly reduced, solving the capacity problem, while ensuring the integrity and detail of the most recent interactions most likely directly related to the current decision. This strategy aligns with human cognitive habits in dialogue, enabling the planning agent to maintain a long-term overview of the task context without losing short-term dialogue continuity and precise referencing capabilities, thereby making more accurate next-step decisions.

[0083] In one or more embodiments of this specification, after obtaining the summary data, the process may further include: evaluating the summary data and determining the evaluation result; the evaluation includes at least one of the following dimensions: user message retention, structural integrity, and planning availability; if the evaluation result meets preset conditions, the summary data is stored in the memory storage module.

[0084] The evaluation process can refer to the quality verification of the summary data generated by the model. In the embodiments of this specification, the evaluation can be based on a multi-dimensional, comprehensive quality inspection system, aiming to ensure that the compressed summary meets the needs of subsequent planning tasks.

[0085] User message retention can be one of the evaluation dimensions to measure whether the summary data fully retains the core intent, key questions and constraints from the users in the original target round data, and can prevent the summary from being oversimplified and losing the original user needs.

[0086] Structural integrity, which can be one of the evaluation dimensions, is used to measure whether the presentation of summary data conforms to a predetermined structured format or logical framework (e.g., whether it clearly distinguishes between "steps performed", "results obtained", "problems to be solved"), and can ensure the parsability and usability of the summary information.

[0087] Planning availability can be one of the evaluation dimensions used to measure whether the summarized data retains key information. This key information includes historical planning steps and key decisions.

[0088] In practical applications, after generating summary data, the quality control process to ensure its quality can include multi-dimensional evaluation, quality judgment, and storage decision steps. In the multi-dimensional evaluation, the system can invoke an evaluator (which can be a rule set or a lightweight evaluation model) to score or judge the summary data from at least one of the aforementioned dimensions. For example, it can check whether the summary mentions the user's initial keywords (user message retention), whether it follows the "background-action-result" template (structural integrity), and whether it contains statements like "A completed, B to be done" (planning availability). In the quality judgment step, the evaluator generates an evaluation result indicating whether the summary data meets preset qualification standards (preset conditions). In the storage decision step, if the evaluation result indicates that the summary quality is qualified (meets preset conditions), the system writes the summary data as valuable memory information into a dedicated summary storage database, allowing it to be retrieved and reused in the future (such as in subsequent rounds of the same session). If it is unqualified, the optimization process begins (described in detail below).

[0089] Continuing with the example above, suppose the summary model generates summary data stating, "In the initial stage of the task, the data was cleaned and basic statistics were performed." During the evaluation, it was found that the summary failed to mention the user's core intent, "to analyze the company with the highest express delivery volume," indicating low user message retention. While actions were taken (cleaning and statistics), they lacked context and clear results, resulting in moderate structural completeness. Furthermore, the specific results of the basic statistics were not explained, leaving planners unable to decide whether to conduct in-depth analysis or simply return the results, resulting in low plan usability. In summary, the evaluation results do not meet the preset conditions (e.g., all three dimensions must achieve a passing grade). Therefore, this summary data will not be stored, and the system will trigger an optimization process to attempt to generate a better summary.

[0090] Based on the embodiments described in this specification, by introducing a multi-dimensional quality assessment process, it is ensured that only high-quality summaries that are valuable for supporting subsequent planning can be stored as memory information. This avoids the information loss or misleading risks that may be caused by data compression, which helps to improve the reliability and value density of the entire data memory storage module and improve the accuracy of the system's task processing.

[0091] In one or more embodiments of this specification, the summary data is obtained by summarizing the target round data by a summary generation model; the method further includes: if the evaluation result does not meet the preset conditions, then executing an optimization adjustment strategy; the optimization adjustment strategy includes adjusting the generation parameters or calling instructions of the summary generation model to optimize the evaluation results of the summary data in at least one evaluation dimension; and re-calling the summary generation model to generate new summary data.

[0092] Among these, the optimization and adjustment strategy refers to the iterative method used by the system to fine-tune the generated parameters and instructions when the summary data quality assessment fails. This involves directional adjustments to the inputs or model behavior to guide the next generation to produce results that better meet expectations.

[0093] Generative parameters refer to the internal or interface parameters of the model that affect the output style and content when the generative model is invoked. Examples include temperature (a temperature parameter that affects randomness), top_p (a kernel sampling parameter), and specific repetition penalty parameters.

[0094] Invocation instructions can refer to system prompts or task instructions submitted to the summary generation model. By modifying the instructions, you can explicitly instruct the model to focus on retaining user messages, following a specific structure, or emphasizing planning-related information.

[0095] In practical applications, the dynamic optimization closed loop when a quality assessment fails can include steps such as strategy formulation and execution, adjusting generation parameters, adjusting invocation instructions, regeneration, and iterative looping. In the strategy formulation and execution step, if the assessment fails, the system can analyze the results to determine the specific dimension where the deficiency lies (e.g., planning availability). Then, it executes optimization and adjustment strategies. In the step of adjusting generation parameters, for example, if the summary lacks key facts (low user message retention), the temperature might be lowered to make the output more deterministic and faithful to the original text. In the step of adjusting invocation instructions, for example, the instruction can be explicitly added such as, "Please be sure to clearly indicate which tasks have been completed in the summary and list their main results." In the regeneration step, the adjusted parameters and / or instructions can be used to re-invoke the same summary generation model, summarizing the same target round data again to generate a new summary. In the iterative loop step, this new summary data will re-enter the assessment process. If it fails, the strategy can be adjusted and regeneration continued until a summary that meets the quality requirements is produced.

[0096] Continuing with the example of failed evaluation above, if the evaluation results show low user message retention and planning availability, optimization and adjustment strategies need to be implemented. Optionally, the invocation command can be adjusted; for example, the original command "Please summarize the following dialogue history" can be changed to "Please summarize the following dialogue history, which must include: 1) What was the user's initial core request; 2) What specific steps and key results have been completed so far; 3) Are there any key pending issues?" Optionally, the generation parameters can be adjusted; for example, the temperature can be adjusted from 0.7 to 0.3 to make the generation more focused and less divergent. Furthermore, using the new instructions and parameters, the model can generate a new summary: "Initial User Request: Analyze the three courier companies with the highest shipment volume. Completed Steps and Results: 1) Data Query: Successfully retrieved all data from the 'xxx' table; 2) Data Cleaning: Processed 5 records with abnormal dates; 3) Preliminary Statistics: Calculated the total shipment volume of each company, with provisional results showing that Courier A, Courier B, and Courier C are at the top. Pending Issues: Final confirmation of the ranking and formatted output results are required." Further, if this new summary significantly improves its scores across all three dimensions, it passes evaluation and is stored.

[0097] Based on the embodiments described in this specification, a dynamic summary generation system with self-optimization capabilities has been established. Through a closed loop of "evaluation-feedback-adjustment," the reliability and consistency of high-quality summary generation are greatly improved, ensuring that the compression mechanism can stably produce valuable memories in actual operation and avoiding system malfunctions or quality fluctuations caused by the uncertainty of single model generation.

[0098] In one or more embodiments of this specification, obtaining the planning context related to the current task planning further includes: obtaining historical summary data of the current session to which the user request belongs, which has been stored in the memory storage module. Generating the planning context based on the historical dialogue records and the historical output data specifically includes: generating the planning context based on the historical dialogue records, the historical output data, and the historical summary data.

[0099] Historical summary data refers to summary data generated and successfully stored in earlier rounds of the current session by the compression and evaluation process described in the embodiments above in this specification. Historical summary data is a summary of earlier history (such as history before the previous N rounds), and is generally more concise and structured than the original dialogue and output records.

[0100] In practical applications, when planning is not a first-time event (i.e., the session has gone through multiple rounds), the planning context can also include historical summary data. Specifically, when assembling the planning context, in addition to obtaining the latest historical dialogue records and historical output content for the current round, the context injection module can also actively query the memory storage module (especially the summary storage database) to retrieve previously stored historical summary data belonging to the same session. Furthermore, the context injection module can integrate the currently obtained historical dialogue records and historical output content with the retrieved historical summary data. The historical summary data provides a snapshot / outline of the early stages of the session, while recent records provide details. Thus, based on the historical dialogue records, the historical output data, and the historical summary data, an enhanced planning context with richer information layers, containing both long-term context and recent details, can be generated.

[0101] For example, suppose we are currently in the 10th round of planning. The system retrieves historical dialogue records and outputs (recent details) from rounds 8 and 9. Simultaneously, the system retrieves historical summary data generated and stored at the end of round 7 from the database. This summary might read: "Conversation goal: Analyze the delivery performance of courier companies. Rounds 1-7 completed: Data source confirmation, full query, weekly data aggregation by company. Conclusion: Data quality is reliable; Courier A, Courier B, and Courier C rank highly in preliminary statistics." The final planning context can include this historical summary as well as details from rounds 8 and 9, thus providing a complete view of the 10th round of planning "from early goals to recent progress."

[0102] Based on the embodiments described in this specification, cross-round memory reuse and information hierarchicalization are achieved. By reintroducing high-quality, compressed summaries from the past as long-term background into the current context, it enables the planning agent to quickly review the overall goals and early key progress of the entire session without having to reread massive amounts of original historical records. This significantly reduces the pressure of relying on recent complete records, improves the overall efficiency and global consistency of planning decisions in long-term tasks, and ensures that the agent never deviates from the initial user intent and the important consensus reached.

[0103] In one or more embodiments of this specification, if the task is specifically an initial planning task for the user request, then obtaining the planning context related to the current task planning further includes: obtaining task planning knowledge and business semantic knowledge related to the user request; and generating the planning context based on the historical dialogue records, the historical output data, the task planning knowledge, and the business semantic knowledge.

[0104] Task planning knowledge can refer to experiential and patterned information related to how to decompose and plan specific types of tasks. In embodiments of this specification, the task planning knowledge can be stored in a task planning knowledge base of a memory storage module. This task planning knowledge base can represent a dedicated knowledge base for storing and managing structured task execution paths, storing general planning steps learned from a large number of historical successful tasks. For example, general planning knowledge for "analyzing business metrics" might include a sequence of steps such as "first performing anomaly detection, then performing dimensional drill-down, and finally attribution analysis."

[0105] Business semantic knowledge refers to background information related to the definitions and relationships of concepts, entities, indicators, and other elements within a specific business domain. Unlike temporary memory generated during a current session, business semantic knowledge is a more stable and general domain knowledge base. In the embodiments described in this specification, the business semantic knowledge can be stored in the business semantic memory library of the memory storage module. The business semantic memory library may include user-remembered entries and team-remembered entries. For example, in the financial field, this could include the definition of "foreign exchange exposure" or the calculation formula for "year-on-year change."

[0106] In practical applications, when planning a task for the first time in a completely new session, since there is no session history at this point (historical dialogue records and historical output content are empty or minimal), the context injection module instead retrieves two types of knowledge from a broader storage: task planning knowledge related to the semantics of the current request is retrieved from the task planning knowledge base; and business semantic knowledge related to keywords in the current request is retrieved from the business semantic memory. Then, this retrieved general task planning knowledge and business semantic knowledge can be used as background knowledge, along with the task description information of the current user request, to construct the planning context used for the initial planning.

[0107] For example, suppose a user's initial request is "Please analyze the perspective of xx public welfare business." On one hand, task planning knowledge can be obtained. The system matches the "business analysis" task and retrieves a general planning path: "Identify analysis dimensions -> Lock in the dataset -> Calculate core indicators -> Conduct comparison / trend analysis -> Produce insights." On the other hand, business semantic knowledge can be obtained. The system retrieves definitions related to "xx public welfare business" from the team's knowledge base, such as explanations of core indicators like "product visits," "xx user count," and "xx account activity." Therefore, the generated planning context can include: "Suggested planning path: Analysis can be performed sequentially from dimensions such as product visits, user behavior, and financial account activity. Relevant business concepts: 1) xx user refers to…; 2) xx account activity includes…. Current user request: Analyze the perspective of xx public welfare business." Based on the embodiments described in this specification, the problem of lack of contextual guidance in the cold start phase of multi-agent systems is effectively solved. By intelligently injecting general task planning knowledge and business semantic knowledge, the planning agent can generate reasonable and professional initial task decomposition schemes based on domain common sense and planning experience, even when faced with entirely new user requests without prior history. This significantly improves the system's initial response capability and professionalism in handling unfamiliar tasks, shortens the exploration process from scratch, provides users with an immediately usable intelligent experience, improves the accuracy of task processing results, and enhances the overall reliability of the system.

[0108] Figure 3 This is a schematic diagram of a planning context compression and structured summary scheme based on quality assessment, provided as an embodiment of this specification.

[0109] like Figure 3 As shown, the planning module can request the next step context; specifically, it can send a context retrieval request to the context injection module. The context injection module can construct a planning context in response to the context retrieval request. Specifically, it can first query historical information, such as historical dialogue records, historical output data, and historical summary data. Then, it can construct a planning context based on the queried historical information. Afterward, a token budget check can be performed (i.e., determining whether the current total number of tokens exceeds a preset token count threshold). If the check passes (i.e., it does not exceed the preset token count threshold), the constructed planning context can be directly returned to the planning module.

[0110] If the check fails (i.e., exceeds the preset threshold for the number of lexical units), a structured summary can be performed. Specifically, a summary context (such as the target round data mentioned above) can be constructed, and then a structured summary can be performed on the constructed summary context. Afterward, the structured summary data can be scored, for example, scoring dimensions such as structure (assessing structural integrity), message (assessing user message retention), and plan (assessing plan availability); furthermore, a comprehensive score can be calculated based on the scores of each dimension. If the comprehensive score meets the preset conditions, the current structured summary data is considered qualified and can be stored in the summary storage database (belonging to the memory storage module); if the comprehensive score does not meet the preset conditions, the current structured summary data is considered unqualified, and an optimization and adjustment strategy can be implemented, and a new structured summary can be performed to generate new structured summary data.

[0111] Step 206: The planning agent receives the planning context and generates a call instruction for invoking the execution agent based on the task description information and the planning context.

[0112] In this context, the invocation instruction refers to the command generated by the planning agent based on the planning context after receiving it, which drives the underlying execution agent to complete specific sub-tasks. The invocation instruction can be regarded as the output information of the planning phase and the input information of the execution phase.

[0113] Furthermore, the invocation instruction can be sent directly by the planning agent, intercepted and enhanced by the context injection module before forwarding, or distributed by other routing modules. For example, in practical applications, the planning agent can directly send the invocation instruction to the execution agent. Alternatively, in practical applications, the planning agent can output the invocation instruction to an intermediate queue or hand it over to the central scheduler, which is then responsible for sending it to the execution agent.

[0114] In practical applications, the planning agent can receive the planning context returned by the context injection module, and then combine it with the original task description information to make task planning decisions and generate specific, low-level execution agent invocation instructions.

[0115] In an optional embodiment, after generating the invocation instruction for the execution agent, the process may further include: the execution agent executing the invocation instruction and returning the execution result to the planning agent; after receiving the execution result, the planning agent determining whether replanning is required; if so, sending a new context acquisition request to the context injection module; in response to the new context acquisition request, the context injection module acquiring the replanning context related to the current replanning task from the memory storage module based on the task description information representing the replanning; and the planning agent generating a new invocation instruction based on the new planning context returned by the context injection module.

[0116] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps and does not represent the only possible execution order. The order of some steps may be adjusted according to actual needs, or some steps may be omitted. When the claims involve method steps, changes in the order of such steps, or parallel execution between steps, are also within the scope of protection of the claims.

[0117] Based on the embodiments of this specification, the two closely related but distinct functions of planning decision-making and decision information support are decoupled, and a professional and dynamic supply of decision information support is achieved through an independent service module (context injection module). In traditional multi-agent systems, planning agents either rely on their limited memory or need to embed complex information retrieval logic into their planning algorithms, which increases the complexity and uncertainty of planning. However, based on the embodiments of this specification, an independent context injection module is introduced, which is proactively invoked as a preprocessing step before the planning agent initiates planning. This context injection module is responsible for retrieving, filtering, and packaging the most relevant information (planning context) for the current specific planning scenario in real time from massive, multi-source historical data. This allows the planning agent to always operate in an information-rich and highly relevant cognitive environment, thereby making more informed and accurate planning decisions. This architecture of pre-planning request dynamic context injection based on the embodiments of this specification enables intelligent, adaptive, and experience-accumulating multi-agent systems.

[0118] Figure 2 The proposed method, through architectural innovation, achieves a qualitative leap in the planning capabilities of multi-agent systems, significantly improving the accuracy, efficiency, and context relevance of task planning. Firstly, the planning agent makes decisions based on a planning context rich in historical experience and relevant knowledge, reducing blind exploration and erroneous decomposition, resulting in more reasonable and professional planning schemes and improved planning quality. Secondly, the system delegates time-consuming information retrieval and integration tasks to dedicated modules for asynchronous processing, freeing up the core computing power of the planning agent, shortening the overall planning response time, and improving system efficiency. Thirdly, planning decisions can continuously learn from the system's accumulated historical data (processes and results), enabling the system to exhibit behavior characteristics similar to experience accumulation and becoming increasingly intelligent with use, allowing the overall intelligence level to continuously evolve.

[0119] based on Figure 2 In addition to the method described herein, this specification also provides some improved implementation methods, which will be described below.

[0120] In one or more embodiments of this specification, context injection enhancement can also be performed on invocation instructions targeting an executing agent. This will be described in detail below.

[0121] The task processing method of the multi-agent system may further include: the context injection module obtaining the invocation instruction; adding a task execution context to the invocation instruction based on the subtask description information of the invocation instruction to form an enhanced instruction; and sending the enhanced instruction to the execution agent.

[0122] In this context, a call instruction refers to a command generated by the planning agent to drive the execution agent to complete a specific operation. In practical applications, a call instruction is typically a structured request that may contain subtask descriptions.

[0123] Subtask description information can be a description of the specific tasks that the subtask needs to perform, written in natural or structured language. The subtask description information can include textual definitions of the subtask's goals, constraints, etc. For example: "Query all records in table 'sales_2024' where 'product_id' is 'P100'."

[0124] The task execution context can refer to a set of supplementary and auxiliary information that is dynamically constructed to ensure that the invocation instructions are executed accurately and efficiently.

[0125] An enhanced instruction can refer to a composite instruction body formed by integrating the original invocation instruction with the injected task execution context. Enhanced instructions enable the executing agent to perform operations with full knowledge of the context and related information.

[0126] In the embodiments of this specification, the knowledge and information support required for task execution is delayed and specialized from the instruction generation stage (planning time) to the instruction execution stage (pre-execution time) for dynamic construction. This decouples the context from the instructions, allowing for on-demand construction. Based on the embodiments of this specification, the planning agent can focus on logical decomposition and process control, generating concise "what to do" instructions. The information on "what needs to be known to do it well" can be calculated and bound in real-time by an independent context injection module just before execution, based on the specific content of the instructions and the current system state (memory, execution trajectory, etc.). This reduces the complexity of planning and improves the modularity and flexibility of the system. Based on the embodiments of this specification, the context injection module can act as an expert in domain knowledge (background information) and runtime state (execution trajectory), knowing where (what database) and how (e.g., vector retrieval, keyword matching, etc.) to obtain relevant information, and providing it to the execution agent in an effective structure (structured text). This specialized division of labor makes information retrieval and integration more accurate and efficient.

[0127] Based on the embodiments described in this specification, a refined "planning-enhancement-execution" pipeline is constructed by introducing an independent context injection step before the execution agent runs. Based on the embodiments described in this specification, the planning module is allowed to output concise atomic instructions, while a dedicated module constructs all necessary auxiliary information (such as historical conclusions, data semantics, and dependencies) in real time and on demand before instruction execution. This significantly reduces planning complexity and instruction transmission overhead. This mechanism fundamentally ensures that the execution agent obtains accurate and complete context support, greatly improving the accuracy, efficiency, and reliability of task execution, while making the system architecture more modular and easier to maintain.

[0128] In one or more embodiments of this specification, adding a task execution context to the invocation instruction specifically includes at least one of the following operations: injecting background information related to the subtask into the invocation instruction; and injecting an execution trajectory context into the invocation instruction based on the task execution trajectory corresponding to the user request.

[0129] Background information refers to static or semi-static domain knowledge and data descriptions related to the current subtask. Typically, background information itself does not directly describe the task execution process. Specifically, background information can mainly integrate business semantic definitions from long-term memory, user-defined terminology explanations from short-term sessions, and reusable data conclusions gleaned from previous tasks.

[0130] Execution trajectory context refers to dynamic information related to the execution process of the current subtask. It focuses on the intermediate products generated by each agent (including the agent to be invoked and other agents) in this macro-task (user request), as well as the dependencies of the current subtask on these products. Execution trajectory context reflects the task execution state and intermediate results.

[0131] Furthermore, injecting background information related to the subtask into the calling instruction may specifically include retrieving and assembling relevant business definitions, terminology explanations, dataset schemas, historical analysis conclusions, etc., from the memory (long-term / short-term) based on the subtask description information to form a static knowledge support layer.

[0132] Furthermore, injecting the execution trajectory context into the calling instruction may specifically include, based on the subtask description information and combined with the global task execution trajectory of this user request, analyzing the current subtask's dependence on the historical step products, performing referential resolution (for example, mapping "the above result" to a specific data table ID), and injecting the dependent product data or its essential version into the context.

[0133] Based on the embodiments in this specification, the task execution context is clearly divided into two categories: background information and execution trajectory context. This enables the systematic and refined use of execution support information. It not only solves the problem of the execution agent's understanding of the task itself by injecting background knowledge such as definitions and explanations, but also solves the problem of connection between steps in complex task flows by injecting trajectory information such as dependencies and products. Thus, it ensures the completeness and relevance of context injection, enabling the execution agent to understand not only "what to do", but also "what to rely on" and "how to connect", thereby exhibiting higher synergy, coherence and overall intelligence in complex, multi-step collaborative tasks.

[0134] In one or more embodiments of this specification, a specific scheme for injecting an execution trajectory context into the invocation instruction is further provided.

[0135] The step of injecting an execution trajectory context into the calling instruction based on the task execution trajectory corresponding to the user request specifically includes: inputting the subtask description information and the task execution trajectory into a dependency analysis model to obtain the dependency analysis result output by the dependency analysis model; if the dependency analysis result indicates that the calling instruction depends on a preceding subtask, then establishing a mapping relationship between the information to be parsed in the calling instruction and the historical subtasks it depends on.

[0136] The task execution trajectory refers to a sequence of key events organized in execution order and recorded in real time by the system during a complete user request processing process. The task execution trajectory is a structured log that can contain at least: the original user instructions, the overall task description, the instruction description for each execution step (subtask), and its corresponding product identifier or result summary. The task execution trajectory can comprehensively depict the macroscopic process and intermediate states of this multi-agent collaboration.

[0137] A dependency analysis model can refer to a trained, lightweight analysis module used to quickly determine dependencies between tasks. In this embodiment, the dependency analysis model can be a large language model (LLM) with reduced parameters or a specialized classification model. In practical applications, the input to the dependency analysis model can be the description information of the current subtask and the task execution trajectory of this request, and the output can be a concise dependency determination result (such as a boolean value "True" or "False").

[0138] The information to be parsed can be semantically ambiguous and referential phrases that exist in the subtask description information of the calling instruction and cannot be clearly understood without historical context. Common information to be parsed can include "the above result", "data from the previous step", "this table", "table XX", etc. Usually, the specific referent of the information to be parsed needs to be determined by analyzing the task execution trajectory.

[0139] Furthermore, the execution trajectory context injection process can include a dependency determination phase and a mapping establishment phase. In the dependency determination phase, when the context injection module needs to inject an execution trajectory context for a call instruction, it can first submit the subtask description information from the instruction along with the task execution trajectory of this user request to the dependency analysis model. This dependency analysis model can be designed to perform a fast inference (e.g., complete within 1 second) to determine whether the current subtask semantically depends on the output of one or more preceding subtasks recorded in the task execution trajectory. The model outputs the dependency analysis result (e.g., "dependency exists" or "no dependency"). During the mapping establishment phase, if the dependency analysis results indicate the existence of a dependency, the system initiates fine-grained parsing. Specifically, firstly, the subtask description information can be analyzed to identify the information to be parsed (i.e., the fuzzy reference part). Then, by combining the step sequence and product information recorded in the task execution trajectory, the information to be parsed can be mapped to one or more specific historical subtask nodes through semantic matching and contextual reasoning, and associated with the historical product data generated by these historical subtasks. For example, "that chart" in the instruction can be mapped to "the chart file with product ID 'chart_001' generated in step 2 of the task execution trajectory".

[0140] Based on the embodiments described in this specification, an intelligent perception of implicit dependencies in a task chain is achieved by introducing a fast and lightweight dependency determination step. This allows the system to accurately distinguish between independent tasks without dependencies and interconnected tasks with dependencies, providing a fast execution path for the former and triggering a fine-grained context construction process for the latter. This mechanism significantly reduces the overall task execution latency while ensuring the accuracy of dependency resolution, improving system response efficiency and guaranteeing a highly efficient and intelligent multi-step task pipeline.

[0141] In one or more embodiments of this specification, after dependency resolution is completed, in order to ensure the effectiveness of task execution, the task description may not be directly modified. Instead, structured dependency information of the task may be constructed and sent to the executing agent along with the task.

[0142] The step of establishing the mapping relationship between the information to be parsed in the calling instruction and the historical subtasks on which it depends specifically includes: determining the target product content on which the information to be parsed depends from the historical product data corresponding to the historical subtasks; generating structured dependency information based on the target product content; the dependency information includes the target product content and calling instruction interpretation information based on the target product content.

[0143] The target product content refers to the core data portion that, after determining dependencies, is precisely located and extracted from the historical product data corresponding to the dependent historical subtasks, based on the specific requirements of the current subtask. It is understood that the target product content is not always the complete original product, but rather a filtered fragment or subset relevant to the current instruction.

[0144] Structured dependency information refers to a data structure formed by standardizing and encapsulating the content of the target output and its semantic relationship with the current instruction. Typically, structured dependency information can contain two parts: <artifacts>The (product content) block is used to carry the actual dependent data;<instruction_explain> The (Instruction Explanation) block is used to explain in clear natural language what the vague references in the current instruction specifically refer to.

[0145] In one or more embodiments of this specification, after dependency resolution is completed, the system further analyzes the specific filtering requirements of the current task for the dependent data, thereby avoiding injecting all irrelevant data into the context and reducing the number of tokens in the context. For example, a previous product queried all express delivery data, but the instruction only needs the first three, and the rest is irrelevant data.

[0146] In practical applications, after determining dependencies, a mapping relationship is established between the information to be parsed in the invocation instruction and the historical subtasks it depends on. Specifically, this may include the steps of determining the target product content and generating structured dependency information. In the step of determining the target product content, the system can access the memory storage module to obtain the complete content of the historical product data based on the established mapping relationship (e.g., "depends on the product top10_list.csv from step 1"). Then, based on a deep understanding of the current subtask description information (e.g., "visualizing with a bar chart" implies the need for data and column names), the system extracts the part truly needed for this task from the complete product, i.e., the target product content. In the step of generating structured dependency information, the system can format and encapsulate the target product content (e.g., the company name and shipment volume columns in the top10_list.csv file) and place it into a structured... <artifacts>Within the tag, generate an explanatory text (e.g., "The 'results mentioned above' in the instruction refers to 'the list of Top 10 courier companies' shipping volumes generated in historical step 1'."), and place it in...<instruction_explain> Within the tag, these two parts are ultimately combined into a complete, self-explanatory, structured dependency information data block.

[0147] Based on the embodiments described in this specification, precise and structured encapsulation of dependency information is achieved. Specifically, by extracting the content of the target product from historical products, it is possible to avoid injecting large amounts of irrelevant complete data into the context, greatly reducing the burden of data processing and transmission. By generating structured dependency information containing explicit explanations, implicit and ambiguous dependencies are transformed into explicit descriptions that the executing agent can directly and unambiguously understand. This not only ensures the accuracy of data transfer between tasks but also greatly reduces the cognitive load on the executing agent in parsing complex contexts, enabling it to focus more intently and efficiently complete core operations.

[0148] In one or more embodiments of this specification, generating structured dependency information based on the target product content specifically includes: if the historical product data corresponding to the historical subtask contains text data, then recalling a text fragment matching the subtask description information from the vector database of the memory storage module to generate an execution trajectory context containing the text fragment; if the historical product data corresponding to the historical subtask contains tabular data, then retrieving a data subset matching the subtask description information from the structured database of the memory storage module to generate an execution trajectory context containing the data subset.

[0149] The vector database can be a database specifically designed for storing and retrieving high-dimensional vector data. In the embodiments of this specification, text content (such as paragraphs in analysis reports) in historical output data can be converted into vectors (embedded) and stored in the vector database, supporting fast semantic retrieval based on metrics such as cosine similarity.

[0150] A structured database can refer to a database capable of storing and querying structured data in a row-and-column format (such as a relational database or a database that supports SQL). In the embodiments of this specification, a structured database can be used to store tabular data from historical output data. A data subset can refer to a portion of the data extracted from the complete tabular data based on filtering criteria (such as specific rows, columns, or records that meet certain conditions).

[0151] In practical applications, different specific implementation methods can be adopted to generate execution trajectory contexts based on the different types of historical product data.

[0152] If the historical output data contains unstructured text (such as analysis reports or summary paragraphs), the system can employ a semantic retrieval strategy for this textual data. First, the current subtask description information is transformed into a query vector. Then, one or more text fragments (vectors) most similar to the query vector are retrieved from the vector database. These recalled text fragments, highly relevant to the current task, serve as the simplified text content and are used to generate the execution trajectory context.

[0153] If the historical output data it relies on contains structured tables (such as CSV files or database query results), the system can employ data query and filtering strategies for this tabular data. First, it can parse the current subtask description information and automatically generate corresponding data manipulation expressions (e.g., an SQL query or a pandas DataFrame filtering expression). Then, it can use this expression to query from the structured database or directly from the output data file, retrieving a subset of data that only meets the requirements of the current task (e.g., the first 5 records where "sales amount" is greater than 10,000). This subset of data is injected as the execution trajectory context.

[0154] Based on the embodiments described in this specification, intelligent context refinement is implemented based on data type and task requirements. Specifically, depending on whether the output is "text" or "table," distinct but optimized strategies are employed: semantically focused extraction is performed on text, recalling only the most relevant segments; and programmatically precise filtering is performed on tables, extracting only the data subset explicitly needed for the task. This approach maximally compresses redundant context information, significantly reducing the context size while ensuring the provision of critical dependencies. This effectively saves transmission bandwidth and reduces token consumption by large language models and other execution agents, improving processing speed and economy. It is a crucial optimization supporting the sustainable operation of complex task chains.

[0155] In one or more embodiments of this specification, specific implementation methods are further provided for injecting background information related to the subtask into the invocation instruction. These include adding business semantic content, terminology explanations, dataset metadata, etc., to the task execution context. These are described in detail below.

[0156] The step of injecting background information related to the subtask into the invocation instruction specifically includes: based on the subtask description information, retrieving business semantic content related to the subtask from the business semantic memory of the memory storage module; the business semantic memory stores structured business semantic entries and their corresponding vectorized representations; and adding the retrieved business semantic content to the task execution context.

[0157] The business semantic memory can be a dedicated database or knowledge base used for persistently storing structured business semantic entries and their vectorized representations. Each business semantic entry is a domain knowledge unit asynchronously extracted and condensed from historical human-computer dialogues, existing in a machine-readable standardized format (e.g., a JSON object containing fields such as id, name, description, and alias), used to define specific concepts, metrics, terms, or rules within a particular business scenario. During storage, these entries can be transformed from their key textual content (such as name and description) into high-dimensional vectors using an embedding model, forming a vectorized representation to support efficient semantic similarity retrieval.

[0158] Business semantic content can refer to the specific knowledge information carried by one or more business semantic entries retrieved from the business semantic memory. For example, a business semantic content about the definition of "active user" may be: "name: 'Number of active users on the day', description: 'Refers to the total number of unique users who have at least one access behavior on the day, usually counted by the user_id field'".

[0159] In practical applications, the process of retrieving relevant business semantic content from the business semantic memory based on the subtask description information can specifically include the following steps: a vectorized query step, i.e., inputting the current subtask description information into the same embedding model used when constructing the memory to obtain its query vector; a similarity retrieval step, i.e., performing an approximate nearest neighbor search in the vector index of the business semantic memory to find the vectorized representations of several business semantic entries with the highest cosine similarity to the query vector; an entry retrieval step, i.e., locating and returning the corresponding complete structured business semantic entry based on the retrieved vector; and a context injection step, i.e., assembling the key content (such as name and description) of one or more retrieved entries according to a preset template format to form a structured text, and inserting it as background information into the task execution context.

[0160] Based on the embodiments described in this specification, the system provides accurate and understandable business context and domain semantic supplementation for the task execution agent. Specifically, by retrieving business definitions and rules closely related to the current (sub)task from the long-term memory in real time, the system can eliminate ambiguity, clarify the meaning of non-standard or domain-specific terms that may exist in the task instructions, and ensure that the execution agent, planning agent, and user have a consistent understanding of key concepts; it can automatically inject business rules or domain common sense that are not explicitly mentioned in the task description but are necessary for execution, reducing the risk of execution errors or deviations due to lack of background knowledge; and it enables the execution agent to obtain condensed, highly relevant business guidance without relying on lengthy original dialogue history or additional knowledge queries, thereby improving the accuracy and efficiency of task execution.

[0161] In one or more embodiments of this specification, injecting background information related to the subtask into the invocation instruction specifically includes: identifying nouns related to the subtask description information from memory; the memory storing custom nouns preloaded for the user instruction and explanations of the custom nouns; and adding the explanations of the identified nouns to the task execution context.

[0162] The custom terms and their explanations stored in memory can be short-term knowledge sets pre-loaded into RAM during system operation to handle the current user session or specific task. These custom terms typically originate from the initial user-input instructions or the terminology explicitly provided in the task configuration; they are user-defined, non-generic business terms or entity aliases for this interaction. Each term is associated with a structured explanation to clarify its specific reference and calculation rules within the system's context of this task. This memory storage method features fast read and write speeds and is suitable for noun matching operations with high real-time requirements.

[0163] Keyword matching can refer to a retrieval technique based on string or pattern comparison. In the embodiments of this specification, keyword matching can be used to identify nouns related to the subtask description information from memory. Specifically, the system can treat the subtask description information as text and compare it with a pre-loaded list of custom nouns in memory. When a word in the description information is completely identical or highly similar to a certain noun, it is determined that the noun is related to the current (sub)task.

[0164] In practical applications, the system utilizes short-term memory to achieve real-time term parsing, which can be divided into a preloading phase, an identification phase, and an injection phase. In the preloading phase, at the start of a session or task planning, the system parses the custom term descriptions from the user's original request, loading the defined terms and their corresponding explanations into the server's memory as key-value pairs or similar data structures, forming a fast-access term knowledge base specific to this session. In the identification phase, when context needs to be injected for a specific call instruction, the system iterates through all custom terms in memory, using keyword matching algorithms (such as exact string matching or fuzzy matching with specific delimiters) to check if these terms appear in the text content of the subtask description information. All matched terms are identified as relevant terms. In the injection phase, for each identified relevant term, the system quickly retrieves the corresponding explanation text from its memory storage. Then, these explanation texts are assembled according to a predetermined format (e.g., "[term]:[explanation]") to form a clear term definition paragraph, which is then appended as background information to the task execution context.

[0165] For example, suppose the initial instruction input by the user (task flow description and custom terminology) is: "Analyze last week's sales data. Terminology: 'Key users' refers to customers who have spent more than 10,000 yuan in the past 30 days; 'Active DAU' refers to the number of unique users who logged in and completed at least one valid operation on the current day." Then, in the pre-loading phase, the system can load "Key users" and its explanation, and "Active DAU" and its explanation into memory. In the identification and injection phase, suppose a subsequent planning generates a sub-task instruction: "Calculate the active DAU trend of key users." The system can identify, through keyword matching, that the instruction contains the two pre-loaded terms "Key users" and "Active DAU." The system then retrieves the explanations of both from memory and constructs contextual content such as: "Key users: refers to customers who have spent more than 10,000 yuan in the past 30 days. Active DAU: refers to the number of unique users who logged in and completed at least one valid operation on the current day." This content can be injected into the task execution context of this sub-task and sent to the executing agent along with the instruction.

[0166] Based on the embodiments described in this specification, the system achieves immediate and accurate understanding and disambiguation of user-customized terms. Specifically, through preloading and real-time keyword matching, the system can conveniently and automatically convert user-defined special terms appearing in task instructions into their explicit definitions and provide them as context to the executing agent. This effectively solves the problem of instruction misunderstanding caused by terminological ambiguity or misalignment of domain knowledge, ensuring that the executing agent operates strictly within the semantic boundaries set by the user. This short-term memory mechanism, used in conjunction with a long-term memory mechanism (business semantic memory), greatly enhances the system's ability to handle temporary and session-specific tasks, and improves the accuracy and reliability of complex instruction execution.

[0167] In one or more embodiments of this specification, injecting background information related to the subtask into the calling instruction specifically includes: loading dataset dimension information related to the subtask based on the subtask description information; matching reusable product data related to the analysis object of the subtask from the memory storage module based on the subtask description information; and adding the matched dataset dimension information and the reusable product data to the task execution context.

[0168] Dataset dimension information refers to the structured description of the data source upon which the task relies; it is a type of session metadata. Dataset dimension information describes the form of the data, rather than the data content itself. Examples include the table name, list of fields (columns), data types of each field (e.g., string, integer, date), and summary statistics such as the size of the dataset. In practical applications, dataset dimension information is an implicit prerequisite for the executing agent to understand data patterns and generate correct query or analysis code.

[0169] An analysis object can refer to a specific entity or metric that is observed, measured, or evaluated in a data analysis task. For example, in business data analysis, "sales revenue," "user retention rate," "case connection rate," and "outliers" can all be analysis objects. The system uses the analysis object as a key dimension to classify and index historical execution outputs.

[0170] Reusable output data refers to structured conclusions or intermediate results generated by the multi-agent system after executing historical tasks and deemed to have potential reuse value. This output data undergoes compression and structuring (e.g., extracting core conclusions and associating them with analysis objects), and is indexed according to dimensions such as "analysis object" before being stored in a structured database. For example, an anomaly analysis of "case connection rate" could result in the conclusion "an anomaly occurred within time period X, containing Y outliers," which could be stored as a reusable output data entry bound to the analysis object of "case connection rate."

[0171] In practical applications, the system can automatically determine the information required for the execution of the current (sub)task based on the current (sub)task requirements. On one hand, it executes the step of loading dataset dimensional information. Specifically, the system can obtain the identification information of the target dataset from the dedicated field for the specified dataset corresponding to the call instruction or task description information. Subsequently, it retrieves and loads the dimensional information of the dataset (such as the header structure of the relevant data table) from the metadata management module or memory storage module, which is equivalent to providing the execution agent with a "data map" of the operation object. On the other hand, it executes the step of matching reusable product data. Specifically, the system can identify the analysis object of the current (sub)task from the sub-task description information (e.g., "user satisfaction" in "analyzing user satisfaction trends"), and then use the analysis object as the key to query the memory storage module whether there is any reusable product data (e.g., past anomaly detection conclusions, periodic fluctuation patterns, etc.) produced for the same or similar analysis object in the past. Next, the injection context step is executed. Specifically, the dataset dimension information and the matched reusable output data obtained in the above steps can be assembled according to a predetermined format, for example, forming the following context paragraph: "[Data Context] The target table 'user_feedback' contains the fields: id (int), satisfaction_score (float), date (date). [Related Historical Conclusions] This satisfaction index detected a short-term abnormal fluctuation last month due to system deployment." Finally, this paragraph can be added to the task execution context as background information.

[0172] Based on the embodiments described in this specification, by automating the construction of data "data maps" and domain experience, the level and depth of intelligence in executing complex data analysis tasks can be significantly improved. First, by automatically providing accurate dataset dimensional information, query errors caused by unclear table structures can be eliminated, ensuring the technical correctness of the analysis operations. Second, by intelligently matching and injecting historical conclusions related to the analysis object, past analytical insights can be transformed into pre-set knowledge and analytical clues for the current task, guiding the execution agent to focus on key points, avoid known pitfalls, or reuse verified analysis patterns. Thus, the execution agent can not only correctly execute instructions but also perform context-aware and insightful analysis, thereby significantly improving the quality and value of the task results.

[0173] Figure 4 This is a schematic diagram illustrating a method for dynamic context construction and injection provided in an embodiment of this specification.

[0174] like Figure 4 As shown, the task execution context can include two parts: background information and task execution information. The background information integrates business semantics from long-term memory with user-defined nouns and reusable conclusions from preceding tasks from short-term memory. The task execution information focuses on the outputs and dependencies of other executing agents in short-term memory.

[0175] like Figure 4 As shown, the injection of background information can include a business semantic search of long-term memory. Specifically, based on the description of the current task, vector retrieval can be performed from the team's and / or individual's business semantic knowledge base in long-term memory to recall business semantic content highly relevant to the current task. The recalled content can be added to the task metadata context in a structured form, providing business background and domain semantic supplementation for task execution.

[0176] like Figure 4 As shown, the injection of background information can include matching user-defined terms in the instructions and loading relevant explanatory information. In practical applications, for example, the description of user instructions in the data analysis field typically includes two parts: a task flow description and explanations of user-defined terms. The system can pre-load these user-defined terms and their explanations into memory. Thus, when a specific task for the agent arrives, keyword matching can be used to identify which terms are relevant to the current task, and the relevant terms and their explanations can be incorporated into the context of the current task.

[0177] like Figure 4 As shown, the injection of background information can include the injection of reusable conclusions. In practical applications, the task execution results of the executing agent may contain reusable conclusions that are needed in the execution of other tasks. Therefore, the system can organize reusable conclusions according to dimensions such as the analysis object and the dataset, and store them in a structured manner. Thus, when a specific task of the executing agent arrives, the system can load the dataset dimension information into the context, match the reusable conclusions in the analysis object dimension according to the task description, and incorporate the matched relevant metadata information into the context of the current task.

[0178] like Figure 4 As shown, task execution information injection can include task-level execution trajectory construction, lightweight dependency quick determination, fine-grained dependency resolution and structured background injection, and data filtering based on task requirements.

[0179] In the task-level execution trajectory construction stage: the system can assemble user instructions, task descriptions, execution steps of each agent and their output results according to the execution order in the multi-agent system to form a task execution trajectory.

[0180] In the lightweight dependency rapid determination phase: upon receiving a new task request, the system can perform a lightweight analysis based on the current task description and execution trajectory, calling a large model to determine whether the current task depends on historical outputs or steps. In practical applications, most dependency-free tasks can quickly enter the direct execution path.

[0181] In the fine-grained dependency resolution and structured background injection phase: For tasks identified as having dependencies, the system can combine the task execution trajectory to perform fine-grained resolution of fuzzy references appearing in the task, mapping them to specific historical task nodes and corresponding output entities. After completing dependency resolution, to ensure the effectiveness of task execution, instead of directly modifying the task description, the system can construct structured dependency information for the task and send it to the executing agent along with the task.

[0182] In the task-requirement-based data filtering phase: After dependency resolution is completed, the system can further analyze the specific filtering requirements of the current task for the dependent data, thereby avoiding the injection of all irrelevant data into the context. For example, for tabular data, the system can automatically generate corresponding pandas expressions based on the task description to perform row / column-level filtering of the dependent dataset, retaining only a subset of data that meets the task requirements, thus reducing data size and token consumption.

[0183] In one or more embodiments of this specification, the multi-agent system further includes a memory management module, and the task processing method of the multi-agent system further includes: the memory management module acquiring execution product data generated by the executing agent during the execution of the sub-task; and storing the execution product data in the memory storage module.

[0184] The memory management module, in this context, refers to a functional module within the multi-agent system used for post-processing and persistent management of data generated during execution. The memory management module captures, processes, and stores task outputs, providing a data foundation for building the system's long-term memory and knowledge base. In practical applications, the memory management module can also be implemented as part of the memory storage module.

[0185] Execution output data refers to the raw output data generated by the executing agent after completing a subtask. The form of execution output data can be diverse, including natural language text, structured data tables, charts, images, or composite documents containing multiple elements.

[0186] In practical applications, after the executing agent completes its task and generates results, the memory management module can capture or receive the execution product data. This allows results that might otherwise be scattered, temporarily stored within individual agents or temporary channels to be centrally processed. The memory management module can then store this product data in the memory storage module. This achieves centralized and persistent management of all system outputs, establishing a reliable data source for subsequent data mining, knowledge extraction, and reuse.

[0187] As an example, suppose a data analysis agent performs the subtask of "querying last week's sales figures". The resulting output data might be a JSON object containing a raw data table and a text summary. The memory management module can capture this JSON object and store it as a record in the system's persistent storage (memory storage module). Optionally, it can also generate multi-level compressed data or fragmented data for this JSON object and store it in the memory storage module.

[0188] Based on the embodiments in this specification, a standardized pipeline from task execution to knowledge accumulation is established by introducing a memory management module. The memory management module can centrally aggregate scattered and temporary task outputs, solving the data silo problem and providing a stable data foundation for subsequent advanced data processing (such as structured extraction, compression, and vectorization) and cross-task, cross-session knowledge reuse. It also provides a data foundation for building multi-agent systems with memory and learning capabilities.

[0189] In one or more embodiments of this specification, storing the execution product data in the memory storage module specifically includes: performing structured extraction on the execution product data to obtain extracted product data; performing standardization processing on the extracted product data to obtain structured product data; and storing the structured product data in the memory storage module.

[0190] Structured extraction refers to the process of identifying and separating information units with independent semantics or functions from unstructured or semi-structured raw execution output data. For example, extracting the "conclusion paragraph," "data table," and "figure description" from a report containing mixed text, tables, and charts.

[0191] Standardization refers to the process of converting extracted information units into a unified and standardized data format within the system. Standardization eliminates the heterogeneity in the format of the original data, making it suitable for storage, retrieval, and subsequent automated processing.

[0192] Structured output data refers to data entities organized in a unified and standardized format after structured extraction and standardization. Structured output data is a reorganization of the original output; the information content may remain unchanged, but readability and processability are significantly enhanced.

[0193] In practical applications, the raw execution output data can first be parsed to identify its logical components using rules or models. This includes separating text from tables, locating key conclusion sentences from the text, and parsing the column headers and data rows of tables. Each identified unit can be assigned a type label (e.g., type: "text_conclusion", type: "data_table"). Then, the extracted information units can be formatted. For example, the text conclusion can be encapsulated into Markdown-formatted paragraphs, and standardized JSON data from charts can be embedded as structured data blocks within the Markdown document. Finally, all standardized units are integrated into a complete, self-describing structured data object. Afterward, the generated structured output data object can be stored in a relational database or document database—a memory storage module suitable for storing structured data—for precise querying and management.

[0194] For example, suppose the original output is a sentence and a chart: "Sales increased by 20% this month, see the chart below [bar chart]." In the structured extraction stage, the text unit "Sales increased by 20% this month" (label: conclusion) and the chart unit (label: bar chart, containing image data and coordinates) can be extracted. Then, in the standardization stage, the text unit can be converted to {"type": "conclusion", "content": "Sales increased by 20% this month", "format": "markdown"}, and the chart unit can be converted to {"type": "bar_chart", "data": [...], "labels": [...], "title": "Monthly sales trend"}. The two are then merged into a structured object. After that, the structured object can be stored in the database.

[0195] Based on the embodiments described in this specification, by performing deep structured analysis and format normalization on the original product, the intelligent agent outputs high-quality knowledge fragments. On the one hand, this makes the data itself easier to manage and retrieve accurately; on the other hand, it provides clean, unified, and semantically clear input for downstream intelligent processing steps (such as compression, segmentation, vectorization, and reasoning), significantly reducing the complexity of subsequent processing and improving the reliability and efficiency of the entire knowledge processing pipeline.

[0196] In one or more embodiments of this specification, before storing the structured product data in the memory storage module, the method further includes: performing multi-level compression processing on the structured product data to generate multiple compressed versions of the product data; wherein the multiple compressed versions include at least two of the following: a full content version, a text conclusion version, and a conclusion summary version.

[0197] Among them, multi-level compression processing can refer to a processing strategy that generates multiple versions with different information densities and levels of detail simultaneously or sequentially for the same structured product data.

[0198] The full content version can be a compressed version that retains all or most of the information of the original structured product, including text, data, chart descriptions, etc., and is usually organized in a format that facilitates the model's complete understanding (such as Markdown with rich markup).

[0199] The text conclusion version can be another compressed version, removing non-textual details such as charts and large data tables, and retaining only the core textual conclusions, summaries, and key data points, aiming to convey key information with minimal information content.

[0200] The conclusion summary version can be another compressed version, obtained by abstracting and condensing the content of the original product. It is usually generated by a large model and consists of one or a few simple summary descriptions. It can be used for ultra-high-speed semantic matching or macro-level review.

[0201] In practical applications, firstly, different compression algorithms or models can be applied to the structured product data to generate the three compressed versions mentioned above in parallel or serially. For example, a complete content version can be generated using a template; a text conclusion version can be generated by removing relevant fields from charts; and a conclusion summary version can be generated by calling a summary model. Afterward, the generated multiple compressed versions of product data can be stored in association with the original structured data. In practical applications, they can be stored together in the structured database of the memory storage module.

[0202] For example, a structured output containing a "User Activity Analysis Report" (including detailed data tables, trend charts, and textual analysis) can undergo multi-level compression to obtain a full content version, a text conclusion version, and a conclusion summary version. The full content version can be a Markdown report containing all data summaries, chart descriptions, and detailed conclusions. The text conclusion version may only contain textual conclusions such as "Q4 active users increased by 15% quarter-over-quarter, with the main growth coming from channel X," without charts. The conclusion summary version can be a highly summarized statement, such as "User activity increased significantly in Q4." In one application scenario, the report generation agent needs the full content version to synthesize the final report. In another application scenario, the downstream analysis agent may only need the key conclusions from the text conclusion version as input for further calculations. In yet another application scenario, when reviewing history, the planning agent only needs the conclusion summary version to quickly understand "what was done before."

[0203] Based on the embodiments described in this specification, a one-data-multiple-views storage strategy is adopted. By pre-generating multiple compressed versions, the system can provide the most suitable information granularity for consumer agents with different scenarios and needs, avoiding the need for costly full-text processing or secondary summarization on a temporary basis each time it is used. Therefore, it can greatly improve the efficiency and accuracy of context matching, reduce the token consumption of large model processing, and significantly optimize system resource utilization, making the entire chain from detailed report generation to rapid decision support more efficient.

[0204] In one or more embodiments of this specification, storing the execution product data in the memory storage module specifically includes: dividing the execution product data into blocks according to the semantic structure of the execution product data to obtain multiple content blocks; and storing the multiple content blocks in the vector database of the memory storage module.

[0205] Semantic structure refers to the inherent organizational form of the execution output data, based on its logical relationships. In the field of data analysis, a typical characteristic of semantic structure is that "a conclusion paragraph corresponds to and describes a specific chart or subset of data," forming logically relatively independent semantic units.

[0206] Chunking refers to dividing data into multiple semantically relatively complete and independent segments (content blocks) based on its semantic structure. It is understood that the segmentation method based on the semantic structure of the execution product data provided in the optional embodiments of this specification differs from the traditional mechanical segmentation method based on fixed lengths or simple delimiters.

[0207] A vector database is a database specifically optimized for storing and retrieving high-dimensional vector (embedded) data. Unstructured data such as text is converted into vectors and stored in a vector database, supporting fast retrieval based on semantic similarity.

[0208] In practical applications, the first step is semantic segmentation. Specifically, the content of the execution output data can be analyzed. Following the principle of "semantic integrity," natural logical units are identified. For example, a report can be segmented into sub-analysis modules such as "sales analysis," "inventory alerts," and "user profiling." For each module, descriptive text is further bound to its corresponding chart or data table as a block (as shown in the text-text association block). Then, vectorized storage can be performed. Specifically, the text content of each content block can be transformed into a high-dimensional vector using an embedding model, and these vectors and their associated metadata (such as the task they belong to and the block type) can be stored in a vector database. In practical applications, the original complete data can remain in a structured database, with the vector database serving as its index for semantic retrieval.

[0209] For example, suppose a "monthly business report" product data contains three parts: Part A uses text and line charts to analyze sales trends; Part B uses text and bar charts to warn of inventory anomalies; and Part C uses text and pie charts to describe user demographics. Then, in the semantic segmentation stage, the system can divide this product data into three content blocks: Block 1 (Part A: text + line chart description), Block 2 (Part B: text + bar chart description), and Block 3 (Part C: text + pie chart description). In the vectorization storage stage, the text description of Block 1 can be converted into vector V1, Block 2 into vector V2, and Block 3 into vector V3, along with the block identifiers and source information, and stored in the vector database.

[0210] Based on the embodiments described in this specification, the knowledge retrieval quality of multi-agent systems can be significantly improved through semantic structure-based segmentation and vectorized indexing. Compared with traditional full-text vectorization or mechanical segmentation, semantic structure-based segmentation and vectorized indexing ensure the semantic focus and integrity of each retrieval unit (block), thereby enabling more accurate recall and query of the most relevant knowledge fragments during vector similarity search, effectively avoiding the information dilution problem (i.e., key information being buried in irrelevant text). This allows the system to support fine-grained, highly relevant contextual recall, greatly improving the quality and efficiency of subsequent task planning, question answering, and decision support.

[0211] Figure 5 This is a flowchart illustrating a method for compressing and storing the products of a multi-agent system, as provided in an embodiment of this specification.

[0212] like Figure 5 As shown in the embodiments of this specification, in a multi-agent system, after the execution agent is invoked and results are produced, the system can report the output to the backend storage system. Specifically, the complete original JSON output generated by the execution agent and its associated contextual metadata (such as execution agent information, tool information invoked by the execution agent, task information, etc.) can be stored. This allows analysis results originally scattered within various agents to be uniformly consolidated into a single storage system, providing a stable data foundation for subsequent content extraction, compression, and vectorization.

[0213] like Figure 5 As shown in the embodiments of this specification, before storing product data in the database, product parsing and content splitting can be performed, thereby enabling structured product storage, retrieval, and management. Specifically, before storing products in the database, the system can select the corresponding extraction method based on the product type to perform structured parsing of different types of data analysis products, thereby accurately extracting information such as conclusions, descriptions, and charts from the products. For example, for charts, a unified chart conversion method can be used to standardize the parsing of various chart data and output a unified data structure, facilitating subsequent format conversion and reuse in multiple scenarios.

[0214] like Figure 5 As shown in the embodiments of this specification, content compression can be performed hierarchically when storing product data in the database. Optionally, the system can convert the extracted conclusions and charts into a Markdown document, preserving information integrity while improving the model's understanding of the content, thus suitable for scenarios requiring complete content. Optionally, the system can remove chart-related information from the structured content, retaining only the text conclusion portion of the product to reduce token waste, thus suitable for scenarios requiring only text conclusions and not concerned with chart details. Optionally, the system can use a large model to highly compress the content, further condensing the original product content into concise conclusive descriptions, thus suitable for lightweight scenarios requiring only core conclusions, providing low-cost, high-density knowledge fragments for multi-turn dialogue planning, knowledge retrieval, etc.

[0215] like Figure 5 As shown in the embodiments of this specification, when storing product data in the database, content can also be segmented and vectorized based on structure. In practical applications, the system can segment content according to the product structure and semantic unit structure, such as dividing it into several content blocks according to conclusion paragraphs, chart descriptions, sub-analysis modules, etc., and attaching necessary meta-information to each block. The segmented content can be vectorized and written into a vector database to form searchable and recallable knowledge fragments, providing fine-grained knowledge support for subsequent similar question retrieval, contextual recall, and multi-agent collaboration.

[0216] In one or more embodiments of this specification, the multi-agent system further includes a memory management module, and the task processing method of the multi-agent system further includes: the memory management module asynchronously generating structured memory candidate entries based on continuous dialogue content with the user; the memory candidate entries containing business semantic information extracted from the dialogue content; and storing the memory candidate entries in the business semantic memory bank of the memory storage module.

[0217] Furthermore, the business semantic information belongs to domain-specific knowledge, referring to the user's private knowledge reserves in their domain, which is the foundation for the system's accurate execution. Specifically, the business semantic information may include definitions and explanations of entities, indicators, terms, their interrelationships, and calculation rules involved in the business scenario, and may also include experiential and methodological information extracted from dialogue that can be applied to specific problem domains.

[0218] The memory candidate entries refer to knowledge units that can be reused in the long term, formed by asynchronously analyzing, summarizing, and structuring the continuous dialogue between the user and the multi-agent system.

[0219] In one or more embodiments of this specification, the system retrieves the most recent rounds of dialogue based on a sliding window and calls a summary model to extract long-term memory information related to professional knowledge and business semantics. This information is typically proprietary knowledge or definitions of non-standard terms in the user's domain, and it forms the basis for the system to accurately execute tasks. For example, in a specific business context, "active tiered DAU" might be defined as "the result of grouping users who visited on the current day according to the level2_crowd_type field," and this information would be extracted as a candidate memory entry.

[0220] The memory candidate entries exist in a structured data format. For example, it can be represented as a JSON structure as follows: { "id": "dau", "name": "Number of active users on that day", "alias": ["DAU"], "description": "Total number of unique users who visited the site today" }

[0221] The `name` and `description` fields contain core business semantic information, the `alias` field records aliases for the term, and `id` is used for unique identification. Those skilled in the art will understand that this structure is merely an example, and candidate entries may also contain other attribute fields used to describe business entities.

[0222] Based on the embodiments in this specification, structured business knowledge is automatically extracted from dynamic dialogue streams, transforming fragmented and non-standard dialogue content into long-term memory that the system can persistently understand and reuse. This provides accurate business background support for subsequent tasks and improves the system's understanding and execution accuracy of domain-specific issues.

[0223] In one or more embodiments of this specification, the business semantic memory includes a user memory; the method further includes: before storing the candidate memory entry into the user memory, comparing the semantic similarity of the candidate memory entry with existing user memory entries in the user memory; if the comparison result is dissimilar, storing the candidate memory entry as a new user memory entry into the user memory; if the comparison result is similar, updating the metadata of the existing user memory entry.

[0224] Specifically, the semantic similarity comparison can refer to quantifying the semantic similarity between candidate entries and existing entries in the user's memory bank by calculating vector similarity (such as cosine similarity). "Dissimilar" and "similar" can be determined based on preset thresholds (e.g., similarity below 0.9 is considered dissimilar, and above 0.9 is considered similar).

[0225] Furthermore, updating metadata can include, but is not limited to, updating the recent use timestamp of an existing entry, increasing the number of uses, etc., without duplicate storage of the content entity.

[0226] Based on the embodiments described in this specification, by performing duplicate detection before storage, the storage of a large amount of semantically repetitive content in the user's memory bank is effectively avoided, significantly saving storage space. Simultaneously, updating metadata maintains the activity of knowledge, providing a data foundation for prioritizing knowledge retrieval based on popularity and freshness.

[0227] In one or more embodiments of this specification, the task processing method of the multi-agent system further includes: periodically clustering the entries in the user memory bank to obtain multiple cluster groups; and merging the entries in the cluster groups that meet the merging conditions.

[0228] Clustering refers to grouping semantically similar entries in the user's memory. Merging refers to rewriting and integrating multiple entries within the same cluster that are semantically highly similar (e.g., similarity greater than 0.6) by calling a model to generate a more comprehensive and refined new entry to replace the original multiple entries, thereby optimizing and de-redundanting the content of the memory.

[0229] Specifically, the system can periodically perform cluster analysis on the entries in the user's memory bank. This involves automatically grouping semantically similar entries into the same cluster group based on their vector representations. Further, the system can determine whether the entries within each cluster meet merging criteria (e.g., the average similarity between entries within the group is higher than a preset merging threshold). For cluster groups that meet these criteria, the system can invoke a model to merge and rewrite multiple entries, generating a more refined and comprehensive new entry to replace all entries in the original group, thereby optimizing and updating the user's memory bank.

[0230] Based on the embodiments in this specification, the system can automatically sort and integrate the user's continuously accumulated memories, aggregate and refine scattered and fragmented similar knowledge into higher-quality knowledge units, prevent the memory bank from expanding and becoming inefficient due to content redundancy and fragmentation, and continuously maintain the knowledge density and quality of the user's memory bank.

[0231] In one or more embodiments of this specification, the business semantic memory bank further includes a team memory bank; the task processing method of the multi-agent system further includes: updating the team memory bank based on the user memory bank; the update includes adding new team memory entries or updating the usage statistics of existing team memory entries.

[0232] Furthermore, the team memory bank can be updated synchronously based on updates to the user memory bank. Specifically, new memory entries, after deduplication at the user level, along with the usage dynamics of user memory entries, can be synchronized to the team-shared memory view. For example, for similar entries already existing in the team memory bank, statistical information such as the number of users can be updated primarily; while for entirely new knowledge, new team memory entries can be created.

[0233] Based on the embodiments in this specification, the transformation and accumulation of individual knowledge into collective team wisdom is realized, enabling the experience of individual team members to be shared and reused. At the same time, by statistically analyzing usage information such as the number of users, the universality and consensus of knowledge can be identified, which helps to discover and promote valuable practical knowledge within the team.

[0234] In one or more embodiments of this specification, the task processing method of the multi-agent system further includes: updating the metadata of team memory entries in the team memory bank according to the association between the user memory bank and the team memory bank; the metadata includes at least one of reference count, number of users, and recent usage time.

[0235] Specifically, the system can periodically scan the memory information of all user accounts under the team account, and statistically analyze the mapping and referencing between each user memory entry and the team memory entry. This mapping and referencing describes the aggregation and association from individual user knowledge (user memory) to collective team knowledge (team memory). In practical applications, when different users generate semantically identical or highly similar business knowledge (i.e., user memory entries) during their interactions with the system, this scattered individual knowledge will be aggregated and mapped onto the same team memory entry. This mapping relationship is dynamically established; a team memory entry can be referenced by multiple user memory entries from different users. By maintaining this mapping and referencing relationship, the system can statistically determine how many users use a particular piece of team knowledge and how frequently, thereby quantifying its collective consensus and practical value.

[0236] Furthermore, the metadata of team memory entries can serve as a dynamic indicator for comprehensively evaluating the importance, activity, and universality of entries.

[0237] The citation count, specifically, can be determined based on the number of user memory entries mapped to the corresponding team memory entry. The citation count count can be used to count how many different user memory entries are mapped to the current team memory entry through semantic similarity matching. The citation count reflects the prevalence and consensus of the corresponding knowledge entry within the team. A higher citation count indicates that the corresponding knowledge has been independently verified or used by more members, and its foundational nature is stronger. In practice, the citation count is updated by periodically scanning the mapping relationship between all user memories and team memories.

[0238] The number of users can be determined based on the number of different users who generated the corresponding team memory entry. The number of users can be deduplicated based on the citation count, recording the number of different users who referenced the current team memory entry. The number of users directly reflects the cross-user value and breadth of application of this knowledge. The more users, the more the knowledge transcends individual experience and becomes a shared practice within the team. In practice, the number of users can be calculated synchronously when updating the citation count.

[0239] Recent Use Time (RUT) records the time (timestamp) when any user's conversation hit this team memory entry (i.e., successfully retrieved through vector retrieval similarity matching). RUT reflects the freshness and current activity of knowledge. In practice, RUT can be refreshed in real time during each task planning or conversation, as the team memory is retrieved and used to build context.

[0240] In practical applications, the weight information of team memory items can be calculated based on multi-dimensional metadata such as citation count, number of users, and recent usage time. This weight information can dynamically reflect the popularity, consensus, and freshness of knowledge within the team.

[0241] Based on the embodiments described in this specification, by establishing and dynamically maintaining the metadata of team memory entries, the system can perform weight calculations based on the metadata when performing knowledge retrieval in subsequent tasks (such as vector recall), thereby prioritizing the recommendation of more authoritative, more commonly used, and more timely team knowledge, which greatly improves the accuracy of knowledge reuse and the efficiency of task execution.

[0242] In one or more embodiments of this specification, the task processing method of the multi-agent system further includes a task planning knowledge base construction scheme, which will be described in detail below.

[0243] Specifically, the task processing method of the multi-agent system further includes: maintaining multiple activity event records associated with the user based on the dialogue content with the user; extracting a structured task execution path from the activity event records; and storing the task execution path in the task planning knowledge base of the memory storage module.

[0244] In this context, "maintenance" refers to the continuous addition, deletion, and modification operations performed on dynamic data sets (such as lists or database records). In the embodiments described herein, "maintenance" refers to the management of activity event records.

[0245] Activity event logs represent units formed by the system categorizing continuous dialogues between users and the multi-agent system according to semantic relevance and by "event" logic. An event represents a complete interaction process centered around the same theme or goal and is linked to the user's account.

[0246] A task execution path represents a reusable task execution plan abstracted and summarized from historical events. In practical applications, a task execution path is a structured knowledge representation, whose elements may include the task name, a description of the task objectives and scenario, and step information for specific execution steps. In practice, the task execution path can be a task solution template recorded in a machine-readable standardized format (such as JSON or XML), whose structured characteristics facilitate accurate retrieval and parsing.

[0247] A task planning knowledge base can be represented as a dedicated knowledge base for storing and managing structured task execution paths. In practice, task planning knowledge bases support query methods such as vector retrieval and keyword matching.

[0248] In an optional embodiment, maintaining multiple activity event records associated with the user specifically includes: determining whether new dialogue content is a continuation of existing activity event records; if so, updating the new dialogue content to the corresponding existing activity event record; if not, creating a new activity event record based on the new dialogue content.

[0249] Furthermore, determining whether new dialogue content is a continuation of an existing activity event specifically includes: the system using an analysis model to semantically match the current dialogue fragment with the user's existing list of activity events; if the match is successful (belonging to the same event), the fragment content is merged into the corresponding event; otherwise, it is initialized as a new event.

[0250] In an optional embodiment, the extraction of the structured task execution path can be performed periodically.

[0251] In an optional embodiment, the task execution path may at least include a task name, task description, and step information. Specifically, extracting a structured task execution path from the activity event record may include: the system asynchronously analyzing completed or mature activity events, calling a model to summarize the core objectives, key decision points, and execution steps in the event, and standardizing them into a structured record containing fields such as name, description, and step list.

[0252] In practical applications, during the continuous interaction between the user and the multi-agent system, the system can automatically capture dialogue fragments based on the sliding window mechanism, start an asynchronous analysis process in the background, and construct a complete dialogue context; then, the analysis model will complete the summarization, compression, and structuring of the content.

[0253] Based on the embodiments in this specification, an automated transformation from raw, fragmented dialogue flows to structured, reusable knowledge is achieved. By intelligently clustering dialogues into "activity events," the system can understand the complete context of a transaction; furthermore, by extracting "task execution paths" from these events, the system distills specific interactive experiences into standardized operational procedures. This constructs a continuously growing user-specific task planning knowledge base (task planning knowledge base), laying a solid data foundation for the rapid and accurate planning of subsequent tasks.

[0254] In one or more embodiments of this specification, when the planning agent performs task planning, it retrieves relevant task execution paths from the task planning knowledge base to assist in generating the invocation instruction.

[0255] Furthermore, when the planning agent handles a new task, the system can convert the description of the current task into a vector and perform a similarity search in the task planning knowledge base (vector database) to find the historical task execution path with the closest semantics. The recalled task execution path can be provided to the planning agent as a verified operation template or background information, serving as an important reference for task decomposition and instruction generation, thereby improving the planning quality.

[0256] For example, the structured task execution path extracted from historical event data is shown below: Task Name: Analysis from a Business Perspective.

[0257] Task description: Used when exploring and analyzing data from the perspective of xx in the dataset of xx business.

[0258] Execution steps: 1) Analyze daily product visits and calculate the percentage of users in different active tiers; 2) Calculate the number of users exhibiting xx behavior and their percentage among all users; 3) Analyze transaction details related to xx, including specific data for xx and xx. In this example, the system primarily relies on the content of the name and description fields to perform retrieval and recall within the task planning knowledge base through a combination of vector similarity search and keyword matching.

[0259] In the embodiments of this specification, the step of retrieving relevant task execution paths from the task planning knowledge base can be performed by the planning agent or the context injection module. When performed by the context injection module, in response to the context acquisition request of the planning agent, the relevant task execution paths can be retrieved from the task planning knowledge base of the memory storage module, and the retrieved task execution paths can be injected into the planning context and provided to the planning agent.

[0260] Based on the embodiments described in this specification, the system achieves precise empowerment of new task planning based on historical success experience. Through vector retrieval technology, the system can intelligently match the historical execution path most relevant to the current needs from the task planning knowledge base. This is equivalent to providing the planning agent with a preferred practice reference, enabling it to reuse verified task decomposition logic and execution strategies, thereby significantly reducing redundant analysis and improving planning speed, decision quality, and the consistency and stability of task execution results.

[0261] Figure 6 This is a flowchart illustrating a method for storing and managing long-term memory, as provided in an embodiment of this specification.

[0262] like Figure 6 As shown, during the continuous interaction between the user and the multi-agent system, the system can automatically capture dialogue fragments based on the sliding window mechanism, start an asynchronous analysis process in the background, summarize and compress the dialogue content, extract long-term memory information related to professional knowledge and business semantics, and organize it into structured memory candidate items.

[0263] Furthermore, for the generated memory candidate entries, the system can perform a vector similarity test at the user level: retrieve similar content in the user's memory, and if the vector similarity between the existing content and the candidate entry is greater than a preset similarity threshold (e.g., 0.9), it is considered that the candidate entry is a duplicate of the existing memory and will not be written again; only the metadata such as the most recent usage time of the same memory will be updated. For memory candidate entries with a similarity lower than the preset similarity threshold (e.g., 0.9), they will be written into the vector database as new user memory entries.

[0264] Furthermore, memory entries that have undergone duplicate detection at the user level can be synchronously incorporated into the team memory view. The system can then perform duplicate detection again at the team level, adding a record of the number of users for duplicate memories, while new memories are written into the vector database as new team memories.

[0265] Furthermore, the system can periodically merge highly similar content in the user's memory, aggregating all entries in the memory with a similarity greater than another preset similarity threshold (such as 0.6). For example, it can call a large model to rewrite the content in the cluster, merge the content of similar entries, and output the merged user memory content.

[0266] Furthermore, the system can periodically scan all user memories under the team, count the mapping and reference between each user memory and the team memory, and update the reference count, number of users, and recent usage time of team memory entries, so that the team memory can continuously evolve with the aggregation results of user memories and achieve dynamic updates of team memory.

[0267] like Figure 6 As shown, during the continuous interaction between the user and the multi-agent system, the system can automatically capture dialogue fragments based on the sliding window mechanism, start an asynchronous analysis process in the background, construct a complete dialogue context, and then hand it over to the analysis model to complete the summary, compression and structuring of the content, thereby achieving context summary and structuring.

[0268] Furthermore, an analytical model can be used to maintain recent activity events and determine whether the current content is a continuation of an existing event. If it is a continuation, the dialogue content is added to the corresponding historical event; if not, a new event entry is created.

[0269] Furthermore, the system can periodically summarize recent events, extract reusable task execution paths from the events, organize these into structured execution paths (achieving experience extraction), and then store them in the task map (task vector library).

[0270] Furthermore, during the next task execution, the system (task execution engine) can recall the most relevant task execution path through vector retrieval, providing guidance and assistance for subsequent tasks, making task execution more efficient and stable.

[0271] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0272] Figure 7 This is a flowchart illustrating a task processing method for a multi-agent system in a practical application scenario provided by an embodiment of this specification.

[0273] like Figure 7 As shown, the data analysis scenario is used as an example.

[0274] Step 1: You can receive conversational information from the user in natural language through the user interface (UI).

[0275] Step 2: Based on the user's dialogue information in natural language form, the user's data analysis request can be determined; specifically, the task description information can be determined.

[0276] Step 3: The planning agent can retrieve the planning context related to the data analysis request from the memory storage module based on the task description information. The memory storage module stores short-term memory data and long-term memory data. The short-term memory data may include historical session records and session output data of the current session to which the user's dialogue information belongs. The long-term memory data may include at least one of the business knowledge and task execution path information corresponding to the user.

[0277] Specifically, when the planning agent needs to plan to determine the next operation, it can request a context from the independent context injection module (step 3-1); the planning agent can query historical information related to the current round (including historical summaries, historical dialogue records, and historical product data) from the memory storage module, assemble it into a planning context for this call, and send it to the planning agent (step 3-2).

[0278] Step 4: The system can enhance the invocation instructions. Specifically, after the planning agent generates the original invocation instructions for the execution agent, the context injection module can intercept the original invocation instructions (Step 4-1). Then, the context injection module can obtain the task execution context and send it to the planning agent (Step 4-2).

[0279] Step 5: The planning agent generates enhanced instructions and sends them to the executing agent.

[0280] Step 6: The executing agent can provide feedback on the execution results to the planning agent. Steps 3 to 6 can be executed multiple times.

[0281] In steps 7 and 8, after the planning agent obtains the execution results (such as a data analysis report), it can return the execution results to the user through the user interface (UI).

[0282] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods.

[0283] Figure 8 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a task processing device.

[0284] like Figure 8 As shown, this device, applied to a multi-agent system, may include: The planning agent 802 is configured to send a context acquisition request to the context injection module when task planning is required in response to a user request; the context acquisition request includes task description information of the user request. The context injection module 804 is configured to, in response to the context acquisition request, acquire the planning context related to the current task planning from the memory storage module based on the task description information. The memory storage module 806 is configured to store historical data generated by each agent in the multi-agent system when performing historical tasks. The planning agent 802 is also configured to receive the planning context and generate a call instruction for invoking the execution agent based on the task description information and the planning context.

[0285] based on Figure 8 The embodiments of this specification also provide some specific implementation schemes of the method, which are described below.

[0286] Optionally, obtaining the planning context related to this task planning specifically includes: The system acquires the historical dialogue records and historical output data of the current session to which the user request belongs; the historical dialogue records are internal workflow records generated by the multi-agent system during the execution of historical tasks; the historical output data are the substantive result data generated and output by the multi-agent system after the execution of historical tasks. The planning context is generated based on the historical dialogue records and the historical output data.

[0287] Optionally, after generating the planning context based on the historical dialogue records and the historical output data, the method further includes: Calculate the number of lexical units in the planning context; Determine whether the number of lexical units is greater than or equal to a preset lexical unit threshold; If the number of lexical units is greater than or equal to the lexical unit threshold, then at least a portion of the data in the planning context is compressed to obtain summary data.

[0288] Optionally, the step of compressing at least a portion of the data in the planning context to obtain summary data specifically includes: Determine the target round data in the planning context; the target round data is the data corresponding to the rounds of dialogue that are more than N rounds away from the current round; where N is a positive integer; The target round data is compressed to obtain summary data.

[0289] Optionally, obtaining the planning context related to this task planning also includes: Obtain historical summary data of the current session to which the user request belongs, which has been stored in the memory storage module; The generation of the planning context based on the historical dialogue records and the historical output data specifically includes: The planning context is generated based on the historical dialogue records, the historical output data, and the historical summary data.

[0290] Optionally, the task processing device further includes: The context injection module obtains the invocation instruction; Based on the subtask description information of the invocation instruction, a task execution context is added to the invocation instruction to form an enhanced instruction; The enhanced instructions are sent to the executing agent.

[0291] Optionally, adding a task execution context to the invocation instruction specifically includes at least one of the following operations: Inject background information related to the subtask into the invocation instruction; Based on the task execution trajectory corresponding to the user request, an execution trajectory context is injected into the calling instruction.

[0292] Optionally, injecting an execution trajectory context into the invocation instruction based on the task execution trajectory corresponding to the user request specifically includes: The subtask description information and the task execution trajectory are input into the dependency analysis model to obtain the dependency analysis results output by the dependency analysis model. If the dependency analysis result indicates that the invocation instruction depends on the preceding subtask, then a mapping relationship is established between the information to be parsed in the invocation instruction and the historical subtask it depends on.

[0293] Optionally, establishing the mapping relationship between the information to be parsed in the invocation instruction and the historical subtasks on which it depends specifically includes: From the historical product data corresponding to the historical sub-tasks, determine the target product content on which the information to be parsed depends; Based on the target product content, structured dependency information is generated; the dependency information includes the target product content and invocation instruction interpretation information based on the target product content.

[0294] Optionally, injecting background information related to the subtask into the invocation instruction specifically includes: Based on the subtask description information, business semantic content related to the subtask is retrieved from the business semantic memory of the memory storage module; the business semantic memory stores structured business semantic entries and their corresponding vectorized representations. The recalled business semantic content is added to the task execution context.

[0295] Optionally, injecting background information related to the subtask into the invocation instruction specifically includes: Identify nouns related to the subtask description information from memory; the memory stores custom nouns preloaded for the user instructions and explanations of the custom nouns; The interpretation of the identified nouns is added to the task execution context.

[0296] Optionally, injecting background information related to the subtask into the invocation instruction specifically includes: Based on the subtask description information, load the dataset dimension information related to the subtask; Based on the subtask description information, reusable product data related to the analysis object of the subtask is matched from the memory storage module; The matched dataset dimension information and the reusable product data are added to the task execution context.

[0297] Optionally, the system further includes a memory management module, and the device is further used for: The memory management module acquires the execution product data generated by the executing agent during the execution of the sub-task; The execution product data is stored in the memory storage module.

[0298] Optionally, storing the execution product data in the memory storage module specifically includes: The execution product data is subjected to structured extraction to obtain the extracted product data; The extracted product data is standardized to obtain structured product data; The structured product data is stored in the memory storage module.

[0299] Optionally, before storing the structured product data in the memory storage module, the method further includes: The structured product data is subjected to multi-level compression processing to generate multiple compressed versions of the product data; wherein, the multiple compressed versions include at least two of the following: a full content version, a text conclusion version, and a conclusion summary version.

[0300] Optionally, storing the execution product data in the memory storage module specifically includes: Based on the semantic structure of the execution product data, the execution product data is divided into blocks to obtain multiple content blocks; The multiple content blocks are stored in the vector database of the memory storage module.

[0301] Optionally, the system further includes a memory management module, and the device is further used for: The memory management module asynchronously generates structured memory candidate entries based on continuous dialogue content with the user; the memory candidate entries contain business semantic information extracted from the dialogue content. The memory candidate entries are stored in the business semantic memory library of the memory storage module.

[0302] Optionally, the business semantic memory includes a user memory; the apparatus is further configured to: Before storing the candidate memory entries into the user memory bank, the candidate memory entries are compared with the existing user memory entries in the user memory bank in terms of semantic similarity. If the comparison result is dissimilar, the candidate memory entry will be stored as a new user memory entry in the user memory bank. If the comparison result is similar, then the metadata of the existing user memory entry is updated.

[0303] Optionally, the device is further used for: The entries in the user memory are periodically clustered to obtain multiple cluster groups; Merge entries in clusters that meet the merging criteria.

[0304] Optionally, the business semantic memory further includes a team memory; the device is also used for: Based on the user memory bank, update the team memory bank; the update includes adding new team memory entries or updating the usage statistics of existing team memory entries.

[0305] Optionally, the device is further used for: Based on the association between the user memory bank and the team memory bank, update the metadata of the team memory entries in the team memory bank; the metadata includes at least one of reference count, number of users, and most recent usage time.

[0306] Optionally, the device is further used for: Based on the content of the conversation with the user, maintain multiple activity event records associated with the user; Extract the structured task execution path from the activity event records; The task execution path is stored in the task planning knowledge base of the memory storage module.

[0307] Optionally, when the planning agent performs task planning, it retrieves relevant task execution paths from the task planning knowledge base to assist in generating the invocation instruction.

[0308] It is understood that the modules mentioned above refer to computer programs or program segments used to perform one or more specific functions. Furthermore, the distinction between these modules does not imply that the actual program code must also be separate.

[0309] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0310] The above is an illustrative scheme of a task processing device according to this embodiment. It should be noted that the technical solution of this task processing device and the technical solution of the task processing method described above belong to the same concept. For details not described in detail in the technical solution of the task processing device, please refer to the description of the technical solution of the task processing method described above.

[0311] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0312] Figure 9 This is a structural block diagram of a computing device provided as an embodiment of this specification.

[0313] The computing device 900 includes: Memory 910 and processor 920; The memory 910 is used to store computer programs / instructions, and the processor 920 is used to execute the computer programs / instructions, which, when executed by the processor 920, implement the steps of the task processing method.

[0314] Specifically, the components of the computing device 900 include, but are not limited to, a memory 910 and a processor 920. The processor 920 is connected to the memory 910 via a bus 930, and a database 950 is used to store data.

[0315] The computing device 900 also includes an access device 940, which enables the computing device 900 to communicate via one or more networks 960. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 940 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0316] In one embodiment of this specification, the above-described components of the computing device 900 and Figure 9 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 9 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0317] The computing device 900 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 900 can also be a mobile or stationary server.

[0318] The processor 920 implements the task processing method when executing the computer instructions.

[0319] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the task processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the task processing method described above.

[0320] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the task processing method as described above.

[0321] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the task processing method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the task processing method described above.

[0322] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described task processing method.

[0323] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the above-described task processing method belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the above-described task processing method.

[0324] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the apparatus and device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The apparatus, device and method provided in the embodiments of this specification are corresponding to each other, and therefore the apparatus and device also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding apparatus and device will not be repeated here.

[0325] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0326] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0327] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0328] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0329] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0330] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0331] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0332] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0333] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0334] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0335] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0336] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0337] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0338] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.< / artifacts> < / artifacts>

Claims

1. A task processing method for a multi-agent system, the system comprising a planning agent, an execution agent, a context injection module, and a memory storage module; the method comprising: When the planning agent needs to plan tasks in response to user requests, it sends a context acquisition request to the context injection module. The context retrieval request includes the task description information requested by the user; In response to the context acquisition request, the context injection module acquires the planning context related to the current task planning from the memory storage module based on the task description information. The memory storage module stores historical data generated by each agent in the multi-agent system when performing historical tasks. The planning agent receives the planning context and, based on the task description information and the planning context, generates a call instruction for invoking the execution agent.

2. The method as described in claim 1, wherein obtaining the planning context related to the current task planning specifically includes: The system acquires the historical dialogue records and historical output data of the current session to which the user request belongs; the historical dialogue records are internal workflow records generated by the multi-agent system during the execution of historical tasks; the historical output data are the substantive result data generated and output by the multi-agent system after the execution of historical tasks. The planning context is generated based on the historical dialogue records and the historical output data.

3. The method as described in claim 2, further comprising, after generating the planning context based on the historical dialogue records and the historical output data: Calculate the number of lexical units in the planning context; Determine whether the number of lexical units is greater than or equal to a preset lexical unit threshold; If the number of lexical units is greater than or equal to the lexical unit threshold, then at least a portion of the data in the planning context is compressed to obtain summary data.

4. The method as described in claim 3, wherein the step of performing data compression processing on at least a portion of the data in the planning context to obtain summary data specifically includes: Determine the target round data in the planning context; The target round data is the data corresponding to a round of dialogue that is more than N rounds away from the current round; where N is a positive integer. The target round data is compressed to obtain summary data.

5. The method as described in claim 2, wherein obtaining the planning context related to the current task planning further includes: Obtain historical summary data of the current session to which the user request belongs, which has been stored in the memory storage module; The generation of the planning context based on the historical dialogue records and the historical output data specifically includes: The planning context is generated based on the historical dialogue records, the historical output data, and the historical summary data.

6. The method of claim 1, further comprising: The context injection module obtains the invocation instruction; Based on the subtask description information of the invocation instruction, a task execution context is added to the invocation instruction to form an enhanced instruction; The enhanced instructions are sent to the executing agent.

7. The method as described in claim 6, wherein adding a task execution context to the invocation instruction specifically includes at least one of the following operations: Inject background information related to the subtask into the invocation instruction; Based on the task execution trajectory corresponding to the user request, an execution trajectory context is injected into the calling instruction.

8. The method as described in claim 7, wherein injecting an execution trajectory context into the invocation instruction based on the task execution trajectory corresponding to the user request specifically includes: The subtask description information and the task execution trajectory are input into the dependency analysis model to obtain the dependency analysis results output by the dependency analysis model. If the dependency analysis result indicates that the invocation instruction depends on the preceding subtask, then a mapping relationship is established between the information to be parsed in the invocation instruction and the historical subtask it depends on.

9. The method as described in claim 8, wherein establishing the mapping relationship between the information to be parsed in the invocation instruction and the dependent historical subtasks specifically includes: From the historical product data corresponding to the historical sub-tasks, determine the target product content on which the information to be parsed depends; Based on the content of the target product, structured dependency information is generated; The dependency information includes the content of the target product and the interpretation information of the calling instructions based on the content of the target product.

10. The method of claim 7, wherein injecting background information related to the subtask into the invocation instruction specifically includes: Based on the subtask description information, retrieve the business semantic content related to the subtask from the business semantic memory of the memory storage module; The business semantic memory stores structured business semantic entries and their corresponding vectorized representations; The recalled business semantic content is added to the task execution context.

11. The method of claim 7, wherein injecting background information related to the subtask into the invocation instruction specifically includes: Identify nouns related to the subtask description information from memory; The memory stores custom terms preloaded for the user instructions and explanations of those custom terms; The interpretation of the identified nouns is added to the task execution context.

12. The method of claim 7, wherein injecting background information related to the subtask into the invocation instruction specifically includes: Based on the subtask description information, load the dataset dimension information related to the subtask; Based on the subtask description information, reusable product data related to the analysis object of the subtask is matched from the memory storage module; The matched dataset dimension information and the reusable product data are added to the task execution context.

13. The method of claim 6, wherein the system further comprises a memory management module, and the method further comprises: The memory management module acquires the execution product data generated by the executing agent during the execution of the sub-task; The execution product data is stored in the memory storage module.

14. The method of claim 13, wherein storing the execution product data in the memory storage module specifically includes: The execution product data is subjected to structured extraction to obtain the extracted product data; The extracted product data is standardized to obtain structured product data; The structured product data is stored in the memory storage module.

15. The method of claim 14, further comprising, before storing the structured product data in the memory storage module: The structured product data is subjected to multi-level compression processing to generate multiple compressed versions of the product data; wherein, the multiple compressed versions include at least two of the following: a full content version, a text conclusion version, and a conclusion summary version.

16. The method of claim 13, wherein storing the execution product data in the memory storage module specifically includes: Based on the semantic structure of the execution product data, the execution product data is divided into blocks to obtain multiple content blocks; The multiple content blocks are stored in the vector database of the memory storage module.

17. The method of claim 1, wherein the system further comprises a memory management module, and the method further comprises: The memory management module asynchronously generates structured memory candidate entries based on continuous dialogue content with the user; the memory candidate entries contain business semantic information extracted from the dialogue content. The memory candidate entries are stored in the business semantic memory library of the memory storage module.

18. The method of claim 17, wherein the business semantic memory includes a user memory; the method further includes: Before storing the candidate memory entries into the user memory bank, the candidate memory entries are compared with the existing user memory entries in the user memory bank in terms of semantic similarity. If the comparison result is dissimilar, the candidate memory entry will be stored as a new user memory entry in the user memory bank. If the comparison result is similar, then the metadata of the existing user memory entry is updated.

19. The method of claim 18, further comprising: The entries in the user memory are periodically clustered to obtain multiple cluster groups; Merge entries in clusters that meet the merging criteria.

20. The method of claim 18, wherein the business semantic memory further includes a team memory; the method further includes: Based on the user memory bank, update the team memory bank; the update includes adding new team memory entries or updating the usage statistics of existing team memory entries.

21. The method of claim 20, further comprising: Based on the association between the user memory bank and the team memory bank, update the metadata of the team memory entries in the team memory bank; The metadata includes at least one of the following: reference count, number of users, and most recent usage time.

22. The method of claim 1, further comprising: Based on the content of the conversation with the user, maintain multiple activity event records associated with the user; Extract the structured task execution path from the activity event records; The task execution path is stored in the task planning knowledge base of the memory storage module.

23. The method of claim 22, wherein when the planning agent performs task planning, it retrieves relevant task execution paths from the task planning knowledge base to assist in generating the invocation instruction.

24. A task processing apparatus, applied to a multi-agent system, comprising: The planning agent is configured to send a context retrieval request to the context injection module when task planning is required in response to a user request. The context retrieval request includes the task description information requested by the user; The context injection module is configured to, in response to the context acquisition request, acquire the planning context related to the current task planning from the memory storage module based on the task description information; The memory storage module is configured to store historical data generated by each agent in the multi-agent system when performing historical tasks. The planning agent is also configured to receive the planning context and, based on the task description information and the planning context, generate a call instruction for invoking the execution agent.

25. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 23.

Images