Multi-agent task processing method, device and equipment based on semantic index document

Abstract

Embodiments of the present application provide a multi-agent task processing method and device based on a semantic index document. The method comprises: obtaining a semantic index document of a target system and storing the semantic index document in a non-volatile storage medium; in response to a task request for the target system, distributing the semantic index document of version information matched with the target system to a plurality of agent instances; determining at least one task unit corresponding to the task request, each agent instance executing the task unit based on the semantic index document to obtain a task result corresponding to the agent instance; and integrating the plurality of task results to obtain a final result. The method is used to ensure that the understanding of the architecture information of the target system by the agent is uniform, thereby achieving the effect of improving the accuracy of the task processing of the multi-agent instance.

Description

Technical Field

[0001] This application relates to the field of intelligent agent technology, and in particular to a multi-agent task processing method, apparatus and device based on semantically indexed documents. Background Technology

[0002] In the field of computer science, multi-agent collaboration has become a key technology for improving the development efficiency of software development and related application scenarios.

[0003] In some technologies, each agent instance relies on dynamically exploring a codebase to process tasks when collaboratively performing a task. In these technologies, inconsistent exploration paths taken by agent instances while exploring the codebase can lead to discrepancies in the agents' understanding of the code files within the codebase.

[0004] Therefore, there is an urgent need for a solution that can ensure that intelligent agents have a unified understanding of the architectural information of the target system. Summary of the Invention

[0005] The multi-agent task processing method, apparatus, and device based on semantic indexed documents provided in this application are used to ensure that the agents have a unified understanding of the architecture information of the target system, thereby improving the accuracy of task processing for multi-agent instances.

[0006] In a first aspect, embodiments of this application provide a multi-agent task processing method based on semantically indexed documents, including:

[0007] Obtain the semantic index document of the target system and store it in a non-volatile storage medium. The semantic index document includes structured semantic description information of each content unit in the target system and version information of the target system. The structured semantic description information includes functional responsibility description and description of the relationship between content units.

[0008] In response to a task request for the target system, a semantic index document containing version information matching the target system is distributed to multiple agent instances;

[0009] At least one task unit corresponding to the task request is determined, and each agent instance executes the task unit based on the semantic index document to obtain the task result corresponding to the agent instance; wherein, the task unit is used to represent the processing object to be executed by the corresponding agent instance;

[0010] The final result is obtained by integrating the results of multiple tasks; where the task result is the processing result of the task unit, and the final result is the processing result of the task to be executed as indicated by the task request.

[0011] In one possible implementation, a semantic index document containing version information matching the target system is distributed to multiple agent instances, including:

[0012] The semantic index document containing version information matching the target system is stored in the target location; where the target location is a file system or database system shared and read by multiple agent instances; or,

[0013] The semantic index document containing version information matching the target system is sent to each agent instance based on a message notification mechanism.

[0014] In one possible implementation, in response to a task request for the target system, the method further includes:

[0015] Perform content inspection on the target system and obtain the content inspection results for the target system;

[0016] If it is determined that the content detection result represents a change in the content unit of the target system, then the step of updating the version of the semantic index document is triggered; wherein, the step of updating the version of the semantic index document is used to make full or partial modifications to the semantic index document.

[0017] In one possible implementation, if it is determined that the content detection result represents a change in the content unit of the target system, the method further includes:

[0018] Mark the version information of the semantic index documents of the target system as outdated.

[0019] In one possible implementation, the semantic index document stored in a non-volatile storage medium is used for reuse among multiple task units; or,

[0020] Semantic index documents stored in non-volatile storage media are used for reuse across multiple session units, where a session unit is a session instance between an AI model and a user; or,

[0021] Semantic index documents stored in non-volatile storage media are used for reuse among multiple agent instances.

[0022] In one possible implementation, the structured semantic description information in the semantic index document includes: the association relationship of content units, which represents the content units that need to be linked and verified in the task to be executed;

[0023] The final result is obtained by integrating the results of multiple tasks, including:

[0024] Identify the results of multiple tasks and determine the content unit corresponding to each task result;

[0025] Based on the association, if it is determined that there are content units that need to be linked for verification corresponding to multiple task results, then a consistency check is performed on the content units that need to be linked for verification.

[0026] If the consistency check passes, the results of multiple tasks are integrated to obtain the final result.

[0027] In one possible implementation, the method further includes:

[0028] Based on semantically indexed documents and task units, determine one or more of the following: the processing scope of the content unit corresponding to the task unit, the association relationship of the content unit, and the exclusion scope of the content unit.

[0029] The processing scope represents the content units involved in the task unit; the exclusion scope represents the content units not involved in the task unit.

[0030] In one possible implementation, the method further includes:

[0031] Based on the exclusion scope, determine the non-processing units corresponding to each task unit; where non-processing units are content units not involved in the task unit.

[0032] The non-processing unit is written into the task result corresponding to the task unit; the non-processing unit is used to perform modification verification when the task results are integrated to obtain the final result. The modification verification is used to check whether there are unnecessary modifications or the modification range is out of bounds in the task result.

[0033] In one possible implementation, the method further includes:

[0034] Extract the first version information and the second version information; where the first version information is the version information of the semantic index documents corresponding to the results of multiple tasks, and the second version information is the version information of the current semantic index document;

[0035] If it is determined that the information in the first version and the information in the second version are inconsistent, then perform at least one of the following:

[0036] Generate a prompt message; the prompt message is used to indicate a version conflict in the semantic index document;

[0037] The current semantic index document is invoked and distributed to multiple agent instances. Each agent instance executes the corresponding task unit based on the current semantic index document to obtain the task result corresponding to the agent instance.

[0038] In one possible implementation, the task unit includes: front-end development task, back-end development task, test writing task, and document update task.

[0039] In one possible implementation, the task result includes: first version information, and at least one of the following: a first set of content units and a second set of content units;

[0040] The first version information consists of the version information of the semantic index documents corresponding to the results of multiple tasks; the first content unit set includes the content units involved in the task to be executed, and the second content unit set includes the content units not involved in the task to be executed.

[0041] In one possible implementation, the task unit is generated based on one or more of the following:

[0042] The module includes a task scheduling module, a user input module, a main control program, and an agent management module.

[0043] Secondly, embodiments of this application provide a multi-agent task processing device based on semantically indexed documents, including:

[0044] The acquisition module is used to acquire the semantic index document of the target system and store the semantic index document in a non-volatile storage medium. The semantic index document includes the structured semantic description information of each content unit in the target system and the version information of the target system. The structured semantic description information includes the functional responsibility description and the relationship description between the content units.

[0045] The distribution module is used to distribute semantic index documents with version information matching the target system to multiple agent instances in response to task requests for the target system.

[0046] The processing module is used to determine at least one task unit corresponding to the task request. Each agent instance executes the task unit based on the semantic index document to obtain the task result corresponding to the agent instance. The task unit is used to represent the processing object to be executed by the corresponding agent instance.

[0047] The processing module is also used to integrate the results of multiple tasks to obtain the final result; wherein, the task result is the processing result of the task unit, and the final result is the processing result of the task to be executed indicated by the task request.

[0048] In one possible implementation, a semantic index document containing version information matching the target system is distributed to multiple agent instances. The distribution module is used to:

[0049] The semantic index document containing version information matching the target system is stored in the target location; where the target location is a file system or database system shared and read by multiple agent instances; or,

[0050] The semantic index document containing version information matching the target system is sent to each agent instance based on a message notification mechanism.

[0051] In one possible implementation, in response to a task request for the target system, the processing module is further configured to:

[0052] Perform content inspection on the target system and obtain the content inspection results for the target system;

[0053] If it is determined that the content detection result represents a change in the content unit of the target system, then the step of updating the version of the semantic index document is triggered; wherein, the step of updating the version of the semantic index document is used to make full or partial modifications to the semantic index document.

[0054] In one possible implementation, if it is determined that the content detection result represents a change in the content unit of the target system, the processing module is further configured to:

[0055] Mark the version information of the semantic index documents of the target system as outdated.

[0056] In one possible implementation, the semantic index document stored in a non-volatile storage medium is used for reuse among multiple task units; or,

[0057] Semantic index documents stored in non-volatile storage media are used for reuse across multiple session units, where a session unit is a session instance between an AI model and a user; or,

[0058] Semantic index documents stored in non-volatile storage media are used for reuse among multiple agent instances.

[0059] In one possible implementation, the structured semantic description information in the semantic index document includes: the association relationship of content units, which represents the content units that need to be linked and verified in the task to be executed;

[0060] The final result is obtained by integrating the results of multiple tasks. The processing module is used for:

[0061] Identify the results of multiple tasks and determine the content unit corresponding to each task result;

[0062] Based on the association, if it is determined that there are content units that need to be linked for verification corresponding to multiple task results, then a consistency check is performed on the content units that need to be linked for verification.

[0063] If the consistency check passes, the results of multiple tasks are integrated to obtain the final result.

[0064] In one possible implementation, the processing module is further configured to:

[0065] Based on semantically indexed documents and task units, determine one or more of the following: the processing scope of the content unit corresponding to the task unit, the association relationship of the content unit, and the exclusion scope of the content unit.

[0066] The processing scope represents the content units involved in the task unit; the exclusion scope represents the content units not involved in the task unit.

[0067] In one possible implementation, the processing module is further configured to:

[0068] Based on the exclusion scope, determine the non-processing units corresponding to each task unit; where non-processing units are content units not involved in the task unit.

[0069] The non-processing unit is written into the task result corresponding to the task unit; the non-processing unit is used to perform modification verification when the task results are integrated to obtain the final result. The modification verification is used to check whether there are unnecessary modifications or the modification range is out of bounds in the task result.

[0070] In one possible implementation, the processing module is further configured to:

[0071] Extract the first version information and the second version information; where the first version information is the version information of the semantic index documents corresponding to the results of multiple tasks, and the second version information is the version information of the current semantic index document;

[0072] If it is determined that the information in the first version and the information in the second version are inconsistent, then perform at least one of the following:

[0073] Generate a prompt message; the prompt message is used to indicate a version conflict in the semantic index document;

[0074] The current semantic index document is invoked and distributed to multiple agent instances. Each agent instance executes the corresponding task unit based on the current semantic index document to obtain the task result corresponding to the agent instance.

[0075] In one possible implementation, the task unit includes: front-end development task, back-end development task, test writing task, and document update task.

[0076] In one possible implementation, the task result includes: first version information, and at least one of the following: a first set of content units and a second set of content units;

[0077] The first version information consists of the version information of the semantic index documents corresponding to the results of multiple tasks; the first content unit set includes the content units involved in the task to be executed, and the second content unit set includes the content units not involved in the task to be executed.

[0078] In one possible implementation, the task unit is generated based on one or more of the following:

[0079] The module includes a task scheduling module, a user input module, a main control program, and an agent management module.

[0080] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0081] The memory stores the instructions that the computer executes;

[0082] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0083] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0084] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0085] The multi-agent task processing method, apparatus, and device based on semantic indexed documents provided in this application obtain a semantic indexed document containing structured semantic description information of each content unit in the target system and version information of the target system. When responding to a task request, the semantic indexed document with version information matching the target system is distributed to multiple agent instances. At the same time, at least one task unit is assigned to the corresponding agent instance for execution. This enables each agent instance to complete the processing of the corresponding task unit on the basis of consistent semantic cognition of the target system and unified version. It reduces repeated exploration across agents and sessions and execution differences caused by cognitive biases, thereby improving the accuracy of task processing, resource utilization efficiency, and stability of final result integration in multi-agent collaborative scenarios. Attached Figure Description

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

[0087] Figure 1 A flowchart illustrating the multi-agent task processing method based on semantically indexed documents provided in this application. Figure 1 ;

[0088] Figure 2 A flowchart illustrating the multi-agent task processing method based on semantically indexed documents provided in this application. Figure 2 ;

[0089] Figure 3 A flowchart illustrating the multi-agent task processing method based on semantically indexed documents provided in this application. Figure 3 ;

[0090] Figure 4 A flowchart illustrating the multi-agent task processing method based on semantically indexed documents provided in this application. Figure 4 ;

[0091] Figure 5 A schematic diagram of the structure of the multi-agent task processing method device based on semantically indexed documents provided in this application;

[0092] Figure 6 A schematic diagram of the structure of the electronic device provided in this application.

[0093] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0094] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0095] In the field of software-aided development, multi-agent collaborative processing techniques are often employed. An exemplary application scenario involves code development, testing, maintenance, and refactoring through the collaborative participation of multiple agent instances. In this scenario, the target system typically comprises multiple code modules, interface relationships, and dependent units, with each agent undertaking different tasks and working collaboratively around the same target system.

[0096] In some embodiments, software development based on multi-agent instances typically employs a task allocation plus runtime code exploration approach. Specifically, upon receiving a development request, different subtasks are assigned to different agents. Each agent then forms an understanding of the target system within its own session by scanning code files, reading dependencies, and locating interface calls, and completes the corresponding task accordingly.

[0097] The above embodiments can support parallel processing, but each agent's cognitive establishment process of the target system depends on its own independent exploration path, which can easily lead to differences in the understanding of the boundaries, dependencies and modification scope of the same module.

[0098] In some situations, when a task spans multiple sessions or switches to different development tools or different agent frameworks, the existing knowledge is difficult to reuse directly, often requiring further exploration of the codebase, resulting in repetitive resource consumption.

[0099] In other cases, when the system is large in scale and the modules are complex, the above differences may further affect the stability of the integrated task results. For example, some agents may omit relevant content units, or different agents may process the data based on different versions of their cognition, ultimately leading to inconsistencies, conflicts, or incomplete modifications in the overall task results.

[0100] In view of this, how to improve the consistency of system cognition and reduce the resource consumption caused by repeated exploration in the software development scenario of multi-agent collaboration has become a technical problem that needs to be solved.

[0101] The multi-agent task processing method based on semantic indexed documents provided in this application first obtains a semantic indexed document containing structured semantic descriptions of each content unit and version information of the target system when a task request for the target system arrives. Then, the semantic indexed document matching the version information of the target system is distributed to multiple agent instances, and at least one task unit is assigned to each corresponding agent instance. Each agent instance executes its corresponding task unit based on the semantic indexed document with the same version information. Finally, the results of multiple tasks are integrated to obtain the final result. This method allows multiple agents to process data based on semantic indexed documents with the same version information, thereby forming a consistent understanding of the target system's architecture, improving the stability of collaborative processing, and reducing resource consumption caused by redundant exploration.

[0102] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0103] Figure 1 A flowchart illustrating the multi-agent task processing method based on semantically indexed documents provided in this application. Figure 1 ,like Figure 1 As shown, the method includes:

[0104] Step 101. Obtain the semantic index document of the target system and store the semantic index document in a non-volatile storage medium.

[0105] The semantic index document includes structured semantic description information of each content unit in the target system and version information of the target system. The structured semantic description information includes descriptions of functional responsibilities and descriptions of the relationships between content units.

[0106] For example, the target system is an object in which multiple intelligent agent instances perform collaborative processing around the same development goal. Specifically, it can be a code repository, project directory, service collection, or a software system containing multiple modules, interface relationships, and dependent units.

[0107] For example, a semantic index document is used to carry structured semantic description information and version information of each content unit in the target system. The content unit is the basic processing object in the target system, which can correspond to source code files, classes, functions, interface definitions, configuration files, test cases, script files or document fragments.

[0108] Furthermore, the structured semantic description information in the semantic index document is used to express the content unit in a structured way, and the version information is used to identify the target system version status corresponding to the semantic index document. It can be a combination of commit hash value, version number, build number, branch identifier and commit timestamp, or other data that can uniquely identify the code status.

[0109] The structured semantic description information also includes: descriptions of functional responsibilities and descriptions of the relationships between content units.

[0110] Functional responsibility descriptions can be in text form and are used to represent the function and responsibility of a content unit in the corresponding target system. For example, the execution logic of a code block, or the specific application scenario of a code block.

[0111] The relationships between content units can be described in text form, representing the associations and dependencies between content units in the corresponding target system. For example, the execution of a code block depends on the communication link of a certain interface.

[0112] Specifically, semantic index documents can be automatically generated by a large language model based on a pre-defined protocol framework after analyzing the target system. This protocol framework defines the structural specifications of the index entries in the semantic index document; for example, the structural specifications include the dimensional framework, semantic element format, and output format.

[0113] Optionally, the dimensional framework, tag system, and semantic elements in the semantically indexed document are automatically determined by the large language model based on the characteristics of the target system. These target system characteristics may include directory structure, technology stack, and code features.

[0114] Among them, the dimensional framework is used to define the classification dimensions of index entries, the semantic element format is used to standardize the description fields of content units, and the output format is used to unify the storage and parsing methods of index documents.

[0115] In one possible embodiment, structured index entries are generated for each content unit in the target code library. Each index entry contains a structured description of the semantic features of the content unit. The structured description includes at least the functional responsibilities of the content unit and its relationship with other content units.

[0116] For example, the generation of index entries is unit-independent; the index entry for each content unit can be generated and updated independently without reading other content units.

[0117] Furthermore, multiple index entries are organized into semantic index documents, which are used to inject into the context window of the large language model. This allows the large language model to obtain architectural information of the codebase in a single inference, significantly reducing context token consumption and improving architectural understanding accuracy compared to directly inputting the original code.

[0118] In another possible embodiment, the structured semantic description information in the semantic index document includes cognitive layer information and operational layer information.

[0119] The cognitive layer information includes index entries describing the structure of the target system (functional responsibilities, dependencies, interface paths, technical characteristics, etc. of each file). The operational layer information includes constraints that define the intelligent agent instances' operations (such as "the original file must be fully viewed before modifying it", "modifications should be performed by regenerating the entire file instead of differential editing", "viewing and modifying must be done in two separate interactions").

[0120] For example, in specific implementation, the executing entity can be a task processing server, an orchestration service in a collaborative development platform, or a task management process deployed in a local development environment. The executing entity first determines the location of the target system, specifically based on the repository address, project identifier, or system number carried in the task request, and locates the current snapshot of the target system in the code storage medium or cache directory.

[0121] Furthermore, pre-analysis processing is performed on the target system, extracting each content unit according to a preset granularity and establishing a unique identifier for each content unit. After extraction, the above information is written into a semantic index document according to a unified field structure, and the corresponding version information is written simultaneously, so that the semantic index document can be directly used for subsequent processing in both the content semantics and version status dimensions.

[0122] In some cases, semantic index documents are pre-generated and persistently stored in a database, object storage, indexing service, or file system before a task request arrives. Upon receiving a task request, the executing entity directly retrieves the document using the target system identifier and version constraints and loads it.

[0123] It is understandable that the semantic index document can be reused in multiple development tasks, multiple sessions, and multiple agent instances of the target system, and there is no need to regenerate the semantic index document when the target system has not changed.

[0124] In other cases, if the pre-stored document does not exist, the version does not match, or the difference from the current state of the target system exceeds a preset difference threshold, the executing entity re-executes the analysis on the target system and generates a new semantic index document, and then stores the document in the index repository.

[0125] The data structure of a semantic indexed document can be stored in the form of structured text, binary index file, or graph structure. Each content unit record includes structured semantic fields that represent the content unit, and version information is recorded in the document header and bound to the document content.

[0126] When the semantic index document is stored in text format, it can be used without relying on a specific large language model or runtime environment. It can be ported and used between different large language models and different intelligent agent frameworks, and the difference in architectural question answering accuracy between different large language models when processing the same semantic index document is small.

[0127] Optionally, the semantic index document of the target system obtained above can also be stored in a non-volatile storage medium. Based on the semantic index document in the non-volatile storage medium, it is possible to allow intelligent agent instances or large models to call it, ensuring the persistent storage of the semantic index document, thereby enabling intelligent agent instances or large models to have a stable and reliable understanding of the architecture of the target system.

[0128] Exemplary non-volatile storage media include, but are not limited to: Solid State Drive (SSD), Hard Disk Drive (HDD), USB Flash Disk (USB flash drive), Compact Flash Card (CF card), Electrically Erasable Programmable Read-Only Memory (EEPROM), and other storage media whose data will not be lost after power failure.

[0129] By acquiring a semantic index document containing structured semantic descriptions and version information before task execution, subsequent instances of intelligent agents no longer rely on independently scanning code repositories to build cognition. Instead, they process data around the same pre-computed semantic foundation, thus enabling task splitting, execution, and integration to be based on a unified system view. It should be understood that the above example is merely illustrative and not limiting.

[0130] Step 102. In response to a task request for the target system, distribute the semantic index document containing version information matching the target system to multiple agent instances.

[0131] For example, a task request is used to trigger a collaborative processing flow for the target system, which may be a code generation request, a defect repair request, a test supplement request, a refactoring request, an interface adaptation request, or a cross-module maintenance request.

[0132] For example, an agent instance is a processing entity that executes task units and produces task results. It can be a large model agent process running in different sessions, an automated development agent in different containers, an execution node in different toolchains, or multiple processing instances with different responsibility labels under the same orchestration system.

[0133] For example, the semantic index document that matches the version information of the target system represents the semantic index document distributed to multiple agent instances, corresponding to the current version state of the target system, so that multiple agent instances can obtain a consistent cognitive benchmark of the target system.

[0134] For example, in a specific implementation, after receiving a task request, the executing entity first parses the target system identifier, task type, version constraints, and execution context in the task request.

[0135] In some cases, if the task request explicitly carries the version identifier of the target system, the executing entity uses that version identifier as a search criterion to select semantic index documents with consistent version information from the index repository.

[0136] In other cases, if the task request does not explicitly provide the version identifier of the target system, the executing entity reads the current working copy of the target system, the repository header pointer, or the most recently verified build version, generates a version identifier to be matched, and selects the corresponding semantic index document accordingly.

[0137] Furthermore, after selecting semantic index documents that match the target system, the executing entity establishes distribution sessions for multiple agent instances to be processed and distributes semantic index documents with version information matching the target system to these agent instances.

[0138] To ensure that the data actually loaded by multiple agent instances is completely consistent, the executing entity can attach a document digest value, document generation time, target system identifier, and version signature when distributing the data. After receiving the data, the agent instance performs an integrity check and only confirms successful loading if the document digest value matches and the version signature is consistent.

[0139] If an agent instance returns an inconsistent version, a missing document, or fails to load, the executing entity redistributes the semantic index document, or suspends the instance from participating in subsequent task unit processing and selects a replacement instance.

[0140] Furthermore, when agent instances run in different development tools, different session containers, or different agent frameworks, the executing entity still completes unified distribution with the same document identifier and the same version information, so that the underlying cognitive objects received by instances across environments remain consistent.

[0141] By uniformly distributing semantic index documents of the same version upon task request response, multiple agent instances possess the same content unit structure description and version state constraints before entering task execution. This ensures that their understanding of the target system remains consistent throughout task processing, thereby reducing inconsistencies in subsequent task results caused by differences in cognitive starting points. It should be understood that the above example is merely illustrative and not limiting.

[0142] Step 103. Determine at least one task unit corresponding to the task request. Each agent instance executes the task unit based on the semantic index document to obtain the task result corresponding to the agent instance.

[0143] The task unit is used to represent the processing object to be executed by the corresponding agent instance.

[0144] For example, a task unit is the object that an agent instance actually processes and executes; it is actually one or more tasks determined based on a task request. An agent instance executes its assigned task unit; in other words, a task unit is the processing object of the corresponding agent instance during actual execution.

[0145] Task units can be divided at the content unit granularity, module granularity, functional link granularity, test scope granularity, or change phase granularity, and an allocation relationship is established with the corresponding intelligent agent instance. The corresponding intelligent agent instance receives and executes the processing body of a certain task unit. This correspondence can be determined based on the intelligent agent instance's responsibility type, available resources, historical execution records, or degree of matching with the content unit.

[0146] In one possible scenario, the task units are obtained by breaking down the task to be executed as indicated by the task request.

[0147] For example, in a specific implementation, after completing the distribution of the semantic index document, the executing entity performs semantic parsing on the task request to identify the target action, involved modules, input constraints, output requirements and delivery form of the task to be executed.

[0148] For example, for a defect remediation task, the executing entity extracts the error location, related interfaces, scope of impact, and verification requirements from the task request. For a new feature addition task, the executing entity extracts the target feature description, dependent services, required new tests, and expected interface behavior.

[0149] Furthermore, the executing entity, combining the structured semantic description information in the semantic index document, breaks down the task to be executed. During this breakdown, the task is divided into multiple task units with clearly defined processing objects. Each task unit includes at least a task unit identifier, a set of target content units, a description of the processing actions, input context, output format, and version information references.

[0150] In one possible embodiment, the execution entity is divided according to module responsibilities, for example, interface modification, service logic adjustment, data model synchronization, and test code supplementation are formed into different task units.

[0151] In another possible embodiment, the execution entity is split according to the dependency chain, and the entry unit, core processing unit and peripheral adaptation unit in the same main functional chain are split into multiple interconnected task units, and the preceding dependency relationship is recorded between the task units.

[0152] After the split is completed, the executing entity performs the distribution based on the capability tags and task unit characteristics of the agent instance. For example, code generation task units are distributed to generative agent instances, test verification task units are distributed to test agent instances, and dependency analysis or conflict checking task units are distributed to review agent instances.

[0153] During distribution, the task unit description, the corresponding set of target content units, version information reference, and result return address are transmitted together, so that the agent instance can perform processing based on the given semantics.

[0154] By splitting tasks based on semantically indexed documents, the splitting results are constrained by the semantic content of the target system. The boundaries and connections between task units are defined before distribution. Multiple agent instances can thus work in parallel around different but combinable processing segments, reducing the likelihood of multiple instances repeatedly exploring the same scope or processing across boundaries. It should be understood that the above example is for demonstration purposes only and is not limiting.

[0155] Subsequently, each agent instance executes the corresponding task unit based on the semantic index document with version information matching the target system, thereby obtaining the task result.

[0156] For example, the task result is the processing result of the task unit, which may be a code modification snippet, patch file, test script, interface specification update, dependency revision suggestion, conflict annotation information or verification report, and the task result is associated with the task unit, content unit scope and semantic index document version information that executed the task.

[0157] It is understandable that multiple agent instances, during execution, jointly rely on the same semantic index document of the same version state. Therefore, their processing is not based on temporary understandings obtained through individual re-exploration, but rather on unified structured semantic description information. Based on this unified structured semantic description information, each agent instance obtains the target system's architecture-level information within the context window of a single inference.

[0158] Furthermore, each agent instance, based on the architecture-level information of the target system, possesses the following two key capabilities: (1) Cross-module understanding capability: understanding the overall architecture, module division, and dependencies of the target system, and not disrupting global consistency when executing local tasks. (2) Exclusionary judgment capability: when generating code modification schemes, determining the scope of modules that do not need to be modified, and generating modification content only for files that need to be modified, thereby avoiding redundant modifications to unrelated modules and reducing defects introduced by excessive modification scope.

[0159] For example, in a practical implementation, each agent instance, upon receiving a task unit, first verifies whether the version information of the locally loaded semantic index document is consistent with the version information referenced by the task unit. If they are inconsistent, a reload request is sent to the executing agent, and execution begins once the versions are consistent.

[0160] Furthermore, the agent instance reads the set of target content units specified in the task unit and extracts the structured semantic description information of the corresponding content units from the semantic index document. Based on this structured information, the agent instance establishes a task execution context and performs targeted reading of source files, configuration items, or test files involved in the task unit, without performing an unbounded scan of the entire target system.

[0161] In some cases, if a task unit needs to modify its code, the agent instance generates a modification plan within the corresponding task context.

[0162] In other cases, if a task unit needs to add or adjust tests, the agent instance generates test cases that match the target modification based on the task unit's requirements.

[0163] In other cases, if the task unit needs to output analysis conclusions, the agent instance forms localization results and processing suggestions based on the structured semantic description information in the semantic index document.

[0164] After the task is completed, the agent instance generates the task result along with metadata. This metadata includes at least the task unit identifier, agent instance identifier, version information of the referenced semantic index document, the set of content units actually processed, a list of files that were modified, and a result summary value.

[0165] For example, for modification tasks, the differences before and after modification and the verification status can be further recorded; for verification tasks, the verification input, execution log and pass or fail indicators can be recorded.

[0166] The agent instance sends the task results back to the result collection channel specified by the executing subject, and the executing subject registers the receipt status and associates it with the corresponding task unit.

[0167] By requiring each agent instance to consistently use semantic index documents with identical version information as the basis for processing during execution, the task results are kept consistent in terms of processing scope, dependency awareness, and version. Multiple task results can then be compared and combined under the same system view, thus supporting stable integration. It should be understood that the above example is merely illustrative and not limiting.

[0168] Step 104. Integrate the results of multiple tasks to obtain the final result.

[0169] Among them, the task result is the processing result of the task unit, and the final result is the processing result of the task to be executed as indicated by the task request.

[0170] For example, the final result is the overall output to the original task request, which may be a complete set of patches, merged code changes, unified test packages, a set of documents updated in conjunction with the changes, a comprehensive analysis report, or a composite deliverable containing multiple of the above.

[0171] It is understandable that the results of multiple tasks have been associated with task unit identifiers, content unit scopes, and semantic index document version information before integration. Therefore, the integration process includes not only simple summarization, but also consistency confirmation, scope verification, dependency connection, and conflict handling.

[0172] For example, in practical implementation, after collecting multiple task results, the executing entity first establishes a result mapping table according to the task unit identifier, and checks whether the version information carried by each task result is consistent with the version information of the semantic index document corresponding to this task request. For task results with inconsistent versions, the executing entity marks them as invalid results or re-triggers the execution of the corresponding task unit.

[0173] Furthermore, the executing entity verifies the content involved in the results of multiple tasks based on the structured semantic description information in the semantic index document, and determines whether there are inconsistencies or conflicts between the results of different tasks. If there are no conflicts, the merging is performed according to a preset integration order; this integration order can be determined based on the prerequisite dependencies between task units, the hierarchical relationship between modules, or the target delivery structure.

[0174] For example, first merge the data structure definition results, then merge the business logic adjustment results, and finally merge the test supplement results and document update results, so that subsequent results can reference the determined content in the preceding results.

[0175] In some cases, if multiple task results are detected to provide different processing results for the same content during the integration process, the executing entity can make a decision based on the priority of the task unit, the responsibility type of the agent instance, conflict rules, or overall processing consistency.

[0176] In one possible implementation, the executing agent sends the conflicting fragments back to the designated agent instance for secondary coordination processing and reintegrates the coordination results into the integration process. After completing conflict checking and result merging, the executing agent generates the final result and outputs it along with target system version information, integration logs, task unit coverage, and necessary verification status. If the final result is a set of code changes, the executing agent can further generate an applicable patch, merge request, or change package; if the final result is an analysis conclusion, a unified structured report is generated.

[0177] By continuing to use the structured semantic description information and version information from the semantic index document during the integration phase to uniformly verify and correlate the results of multiple tasks, the processing outputs of multiple agent instances can be concatenated on the same version semantic baseline, ultimately yielding a processing result that corresponds to the task request and is internally consistent. It should be understood that the above example is merely illustrative and not limiting.

[0178] The multi-agent task processing method based on semantic index documents provided in this application pre-establishes and reuses semantic index documents bound to the target system version. Multiple agent instances perform collaborative processing around the same version state and the same structured content view. Task splitting, execution, and integration are all based on unified content unit boundaries and version information, thereby achieving a consistent system cognitive foundation in multi-agent software development scenarios, reducing repetitive code exploration, and enabling stable integration of task results formed across instances on the same semantic baseline.

[0179] In the foregoing embodiments, the process of distributing semantic index documents with the same version information to multiple agent instances in step 102 can be implemented in one of the following examples.

[0180] In one example, a semantic index document containing version information matching the target system is distributed to multiple agent instances, including:

[0181] The semantic index document containing version information matching the target system is stored in the target location. The target location is a file system or database system shared and accessed by multiple agent instances.

[0182] For example, when the document is stored in the target location, the semantic index document can be written to the shared storage address first, and version information, verification identifier and access control information can be written synchronously. Before executing the corresponding task unit, multiple agent instances can read the document content in the same target location and complete the local loading.

[0183] For example, when using a database system, document content can be written into a data table as records or stored in a document collection as large fields. Then, an agent instance can retrieve the same record based on version information to obtain consistent document content.

[0184] In the shared file system scenario, semantic index documents are stored in a preset path, and multiple agent instances access the same document through file handles or database connections, avoiding version conflicts caused by inconsistent local caches.

[0185] It should be noted that the target location can be a file system path or a database table. The file system path supports multiple agent instances to read the data through file handle sharing, while the database table synchronizes the index content through the SQL (Structured Query Language) query interface to ensure version consistency.

[0186] In one example, a semantic index document containing version information matching the target system is distributed to multiple agent instances, including:

[0187] The semantic index document containing version information matching the target system is sent to each agent instance based on a message notification mechanism.

[0188] For example, when using a message notification mechanism, the message body carries at least the document identifier and version information. After receiving the notification, the agent instance accesses the preset storage location or obtains the corresponding document through the interface to ensure that each instance reads the semantic index document with the same version.

[0189] In the message notification mechanism scenario, the executing entity sends document identifiers and version information to each agent instance via a message queue, and the agent instances retrieve the document from a preset storage location accordingly. This method ensures that the semantic indexed document content loaded by all agent instances is completely consistent, thereby improving the stability of task execution.

[0190] In the above embodiments, multiple agent instances retrieve semantic index documents around the same shared location or the same notification event. The document versions are constrained by a unified identifier, thus ensuring that the semantic index content relied upon by each agent instance remains consistent. Consequently, when multiple agent instances process different task units, they share the same cognitive basis regarding the module boundaries, dependencies, and processing scope of the target system. This leads to more stable integration of task results and reduces resource consumption caused by repeated retrieval or version inconsistencies.

[0191] Figure 2 A flowchart illustrating the multi-agent task processing method based on semantically indexed documents provided in this application. Figure 2 ,like Figure 2 As shown, in this embodiment... Figure 1 Based on the illustrated embodiment, in response to a task request for the target system, the method further includes:

[0192] Step 201. Perform content inspection on the target system and obtain the content inspection results of the target system.

[0193] Step 202. If it is determined that the content detection result represents a change in the content unit of the target system, then the step of updating the version of the semantic index document is triggered.

[0194] The step of updating the version of the semantic index document is used to make full or partial modifications to the semantic index document.

[0195] For example, version updates for semantic indexed documents can be performed by making all changes or by making only partial changes.

[0196] In some cases, when all modifications are made, the system re-extracts the structured semantic description information of all content units in the target system and generates a new semantic index document to replace the old version.

[0197] In other cases, when partial modifications are made, the system only adds, deletes, or rewrites the index entries corresponding to the content units that have been changed, while keeping the version content of the unchanged entries unchanged.

[0198] For example, in specific implementation, in order to achieve partial modification, the system can establish a mapping relationship between the content detection results and the index entries, locate the affected index area according to the change type, and then make synchronous adjustments to the corresponding structured semantic fields, version fields and related fields.

[0199] Optionally, for semantic index documents that use a specific version identifier, a new version can be formed by incrementing the version number, timestamp, or hash identifier. In practical applications, other types of identifiers can also be selected, and this application does not limit this.

[0200] Optionally, in actual operation, after receiving a task request, the system first performs content detection, and then decides whether to update the semantic index document based on the content detection results, so that the index content distributed and used by multiple agent instances is consistent with the target system.

[0201] Furthermore, in step 202 above, if it is determined that the content detection result represents a change in the content unit of the target system, the method further includes:

[0202] Mark the version information of the semantic index documents of the target system as outdated.

[0203] For example, in a specific implementation, after obtaining the content detection results, the system can determine whether the content unit of the target system has changed based on the file hash value, interface signature, dependency differences, or change submission identifier recorded in the content detection results.

[0204] In some cases, if the detection results indicate that at least one content unit has been added, deleted, or modified, the version management module will read the version record corresponding to the current semantic index document and update the status field of the version record to obsolete.

[0205] This update can be performed atomically to ensure that the obsolescence of the old version can be identified in a timely manner when concurrent tasks request to read it. If the semantic index document is stored in multiple copies, the status flags in each copy can also be updated synchronously, so that each agent instance obtains a consistent obsolescence flag when sharing reads or receiving messages.

[0206] By combining this marking mechanism with the version update management of semantic index documents, the system can identify when changes are detected in the target system's content. It can first mark the old version as unusable for collaborative processing, and then trigger the regeneration or redistribution of a new semantic index document. Consequently, subsequent agent instances based on this document can directly recognize their state changes and switch to the latest version, thus maintaining consistency in the semantic foundation upon which multi-agent collaborative processing relies.

[0207] In the above embodiments, the index version is refreshed in a timely manner when the content of the target system changes, and the changes are adapted to different scales of change scenarios by making full or partial modifications, so that the task processing foundation remains effective and the parsing deviation and repeated exploration caused by using outdated indexes are reduced.

[0208] In one possible embodiment, in some cases, the semantic index document stored in a non-volatile storage medium is used for reuse among multiple task units; in other cases, the semantic index document stored in a non-volatile storage medium is used for reuse among multiple session units, where a session unit is a session instance between an artificial intelligence model and a user; and in still other cases, the semantic index document stored in a non-volatile storage medium is used for reuse among multiple agent instances.

[0209] For example, since the semantic index document containing version information matching the target system is stored in a non-volatile storage medium, different task units, different session units, and different agent instances can all read and call the semantic index document stored in the aforementioned storage medium.

[0210] It is understandable that when different task units process the task results, they can reuse the same version of the semantic index document stored in the same storage medium on the same path.

[0211] It is understandable that different conversation units can reuse conversation instances between an artificial intelligence model (such as a large language model) and a user by calling the same version of the semantic index document stored in the same storage medium.

[0212] It is understandable that different agent instances can reuse semantic index documents by calling the same version of the semantic index document stored in the same storage medium when performing tasks.

[0213] It should be noted that the non-volatile storage medium indicated above can be an independent non-volatile storage component in some cases, and this application embodiment does not limit this.

[0214] In the above embodiments, by storing the semantic index document on a non-volatile storage medium, different tasks, different sessions, and different agents can reuse the same version of the semantic index document. On the one hand, this reduces the amount of data access and improves processing efficiency; on the other hand, based on the stored semantic index document, it ensures that the processing results of different processing objects are processed based on the same version of the target system's architecture information, thereby improving the accuracy of the results.

[0215] Based on the foregoing embodiments, in one example, the structured semantic description information in the semantic index document includes: the association relationship of content units.

[0216] Among them, the association relationship represents the content units that need to be linked and verified in the task to be executed.

[0217] For example, in specific implementations, semantic index documents can be stored in the form of JSON (JavaScript Object Notation), XML (Extensible Markup Language), or database records. Each field can be set as a single value, an array, or a collection to adapt to the description requirements of single content units, multiple content units, and hierarchically nested content units.

[0218] The structured semantic description information in the semantic index document includes the relationships between content units.

[0219] It is understandable that semantically indexed documents can make dependencies explicit and filter irrelevant content units, thereby improving the cognitive consistency of multiple agent instances towards the same target system, reducing the resource consumption of repeated parsing and invalid processing, and improving the consistency and completeness of task results integration.

[0220] Based on the above example, in the process of integrating multiple task results in step 105, integration can be carried out according to the relationships in the structured semantic description.

[0221] Figure 3 A flowchart illustrating the multi-agent task processing method based on semantically indexed documents provided in this application. Figure 3 ,like Figure 3 As shown, the final result is obtained by integrating the results of multiple tasks, including:

[0222] Step 301. Identify the results of multiple tasks and determine the content unit corresponding to each task result.

[0223] Step 302. Based on the association relationship, if it is determined that there are content units that need to be linked for verification for multiple task results, then perform consistency verification on the content units that need to be linked for verification.

[0224] Step 303. If the consistency check is successful, the results of multiple tasks are integrated to obtain the final result.

[0225] For example, in a specific implementation, after receiving multiple task results, the system first parses the text fragments, code fragments, configuration items, or interface descriptions in each task result, and then matches the parsed objects with the content unit identifiers in the semantic index document to determine the content unit corresponding to each task result.

[0226] Furthermore, based on the pre-recorded relationships between content units, the system determines whether there are any objects in these content units that require linkage verification.

[0227] In some cases, when there are objects that require linkage verification, the system performs consistency verification on the version tags, interface definitions, parameter values, call directions, or processing scope of the relevant content units to confirm that they logically meet the linkage conditions.

[0228] If the verification passes, the system will then perform concatenation, deduplication, or overwriting of multiple task results according to task priority, content unit order, or preset merging rules to generate a final result that can be submitted directly.

[0229] Specifically, the consistency verification process mentioned above can include conflict detection, range completion, or manual review.

[0230] For example, the system parses the content unit identifiers (such as file paths) in the results of each task and checks for conflicts based on the relationships (such as interface dependencies) in the semantic index documents.

[0231] For example, if the front-end Agent modifies views / login.jsx and the back-end Agent modifies controllers / auth.js, the system checks whether the interface paths of the two match (e.g., / api / auth / login).

[0232] If a conflict exists, the system will send the conflicting fragment back to the designated agent instance for secondary coordination processing, and then reintegrate the coordination result into the integration process. This verification mechanism ensures the logical consistency of multi-agent task results and avoids system-level defects caused by dependency mismatches.

[0233] In the above embodiments, when multiple task results enter the integration stage, the mapping from results to content units is completed first. Then, objects requiring linkage verification are screened out based on the correlation relationship, and integration is performed only when consistency is satisfied, thereby ensuring that the integration process remains consistent with the content association in the target system. Since the final result is formed after the relevant content units have passed verification, the logical consistency and output stability of the multi-agent collaborative results can be improved.

[0234] In one possible embodiment, the method further includes:

[0235] Based on semantically indexed documents and task units, determine one or more of the following: the processing scope of the content unit corresponding to the task unit, the association relationship of the content unit, and the exclusion scope of the content unit.

[0236] The processing scope represents the content units involved in the task unit; the exclusion scope represents the content units not involved in the task unit.

[0237] For example, the processing scope can be encoded by directory, package name, class name, function name, or interface identifier; the association can be encoded by dependency edge, calling edge, implementation edge, or synchronous update edge; and the exclusion scope can be encoded by blacklist identifier, filtering rule, or non-participation in verification identifier.

[0238] In one possible embodiment, the processing scope field identifies the content unit involved in the task through directory path, file name or interface identifier, the association field guides the agent instance to identify the module that needs to be linked for verification through dependency edges, and the exclusion scope field avoids redundant modification through blacklist identifier.

[0239] For example, after the encoded information of the above-mentioned structured semantic description information is read by the agent instance, it can be directly mapped to the set of objects to be processed, the set of linked verification objects, and the set of excluded objects. In practical applications, other formats can also be selected for this encoding method, and this application does not limit it.

[0240] Furthermore, based on the index entries contained in the semantic index document and the task unit, one or more of the processing scope, association relationship and exclusion scope of the content unit corresponding to the task unit are determined.

[0241] For example, based on the index entries contained in the semantic index document, the processing scope, associations, and exclusion scope are determined according to the specific task requirements of the task unit.

[0242] It is understandable that the execution of this task unit involves processing content units included in the processing scope; however, the execution of this task unit does not involve processing content units included in the exclusion scope.

[0243] Understandably, by identifying the relationships between task units during the execution of this task unit, we can determine which task units have dependencies on each other, which can be used for consistency verification when integrating the task results to obtain the final result.

[0244] By defining the above fields, the agent instance can accurately locate the processing range when executing tasks, reduce erroneous operations on irrelevant modules, and ensure logical consistency between modules through relational verification.

[0245] In the above example, by defining the processing scope, relationships, and exclusion scope, the agent instance can obtain consistent content unit boundaries, dependency relationships, and exclusion object constraints based on the specific needs of the task unit, while maintaining unified version information. This allows for a consistent processing objective when executing task units, and enables matching verification of relevant content units during the result integration phase. Consequently, the task results more closely reflect the actual relationship structure in the target system and reduce misprocessing of irrelevant content units.

[0246] In one possible embodiment, the method further includes:

[0247] Based on the exclusion criteria, determine the non-processing units corresponding to each task unit. Non-processing units are content units not involved in the task unit.

[0248] The non-processing unit is written into the task result corresponding to the task unit. The non-processing unit is used to perform modification verification when the task results are integrated to obtain the final result. The modification verification is used to check whether there are unnecessary modifications or modifications that exceed the limit in the task result.

[0249] For example, as can be seen from the foregoing embodiments, the exclusion range is used to indicate content units that are not involved in the execution of a task unit. Based on the scheme of the foregoing embodiments, the exclusion range corresponding to each task unit can be determined, and thus the non-processing unit corresponding to each task unit can be determined.

[0250] Non-processing units are those included in the exclusion scope corresponding to the task unit, and are not processed when the task unit is executed.

[0251] Then, the content unit identifier of the non-processing unit is written into the task result corresponding to the task unit. After the task unit finishes execution and the task result corresponding to the task unit is obtained, the task result is modified and verified based on the content unit identifier of the non-processing unit in the task result.

[0252] It is understandable that the task result is the result obtained by the agent instance executing the task unit, while the non-processing unit should not be processed when the task unit is executed. Processing can be understood as modifying the content of the content unit.

[0253] The task results are verified based on the non-processing unit to determine whether the non-processing unit was modified during the execution of this task unit, or whether the scope of modification was exceeded during the execution of this task unit.

[0254] In some cases, if a non-processing unit is modified, it indicates that the agent instance has modified something that should not have been modified.

[0255] In other cases, modifications to non-processing units can also indicate that the agent instance has exceeded the scope of the modification while executing task units.

[0256] By excluding non-processing units and writing them into the task results, the modification and verification of the task results can reduce the need for intelligent agent instances to make changes to content units that do not require modification, thus ensuring the accuracy of modification processing of the target system, that is, ensuring the accuracy of the execution of the task to be processed and the accuracy of the final result.

[0257] Based on any of the foregoing embodiments, during the process of generating task results from multiple agent instances, there may be a situation where the semantic index document is updated. In this case, the semantic index document on which the task result depends is an outdated index document, and the task result may be inaccurate.

[0258] Figure 4 A flowchart illustrating the multi-agent task processing method based on semantically indexed documents provided in this application. Figure 4 ,like Figure 4 As shown, in one possible implementation, the method further includes:

[0259] Step 401. Extract the first version information and the second version information.

[0260] The first version information consists of the version information of the semantic index documents corresponding to the results of multiple tasks, while the second version information consists of the version information of the current semantic index document.

[0261] Step 402. If it is determined that the first version information and the second version information are inconsistent, then perform at least one of the following:

[0262] Generate a warning message. This message indicates a version conflict in the semantic indexed document.

[0263] The current semantic index document is invoked and distributed to multiple agent instances. Each agent instance executes the corresponding task unit based on the current semantic index document to obtain the task result corresponding to the agent instance.

[0264] For example, in the event of version inconsistency, the system can generate a prompt message and output it to the interface, log file, or message queue. The prompt message is used to identify the version conflict between the current task result and the current indexed document, so as to facilitate subsequent integration or review.

[0265] Furthermore, the system can also call the current semantic index document and redistribute it to multiple agent instances. Each agent instance re-executes the corresponding task unit based on the same current version of the semantic index document to obtain new task results.

[0266] The current semantic index document can be stored in a shared file system, database or caching service, and can be accessed by reading handles, message notifications or object references. In practical applications, the document can also be stored and distributed in other ways, which are not limited in this application.

[0267] In one possible implementation, when a version conflict is detected, the executing agent sends a version update notification to all agent instances via a message queue, along with the storage path of the current semantic index document.

[0268] Each agent instance reloads the document according to the notification and executes the task unit based on the latest version. If an agent instance cannot reload, task execution is paused and the update is waited for to complete. This process ensures that all agent instances always execute tasks based on the latest version of the semantic index document, avoiding execution errors caused by version inconsistencies.

[0269] In the above embodiments, when the system detects a version conflict, it explicitly records the version inconsistency by providing a prompt message. It then redistributes the semantic index document of the current version, enabling each agent instance to recalculate the task results based on a unified version. This ensures that subsequent task results remain consistent with the current target system state. Because the basis for generating task results is realigned, result conflicts between multiple agent instances can be detected and corrected in a timely manner, thereby improving the consistency and stability of result integration.

[0270] In one example, the task units include: front-end development tasks, back-end development tasks, test writing tasks, and document update tasks.

[0271] For example, in specific implementation, after the task request is split, the task management unit can, based on the structured semantic description information in the semantic index document regarding the processing scope, correlation, and exclusion scope, assign the UI layer modification content as a front-end development task, the service layer and data processing content as a back-end development task, the verification content corresponding to the new function as a test writing task, and the interface change, usage change, or version description as a document update task.

[0272] Furthermore, each agent instance reads the content unit information corresponding to its task unit, combines it with the semantic index document with the same version information to complete code generation, test case generation, or document revision, and outputs the corresponding task results. If the task involves front-end and back-end linkage, the front-end development task and the back-end development task can share the same interface definition. The test writing task generates interface test or regression test content based on this definition, and the document update task synchronously writes the interface fields, calling methods, and change descriptions.

[0273] It is understandable that when task units are subdivided in this way, agent instances can process the front-end, back-end, test, and document content separately around the same version of the semantic index document, thereby forming task results that can be executed in parallel and have clear boundaries. Since each task unit corresponds to a clear content scope, the results can be summarized directly based on the relationship during integration, and the front-end modifications, back-end modifications, test content, and document content can be kept consistent.

[0274] In the above example, by dividing tasks into different types, multiple agent instances can handle different development objects separately, reducing the cross-contamination of the same task request between the interface, service, test and documentation, and reducing the resource consumption caused by repeatedly exploring the code repository, while ensuring that the generated results are consistent in terms of function implementation, verification content and documentation.

[0275] In one example, the task result includes: first version information, and at least one of the following: a first set of content units and a second set of content units;

[0276] The first version information consists of the version information of the semantic index documents corresponding to the results of multiple tasks; the first content unit set includes the content units involved in the task to be executed, and the second content unit set includes the content units not involved in the task to be executed.

[0277] For example, in a specific implementation, when an agent instance executes a task unit based on the same semantic index document, it will write the content units that are hit by the current task into the first content unit set and write the content units that are not hit into the second content unit set.

[0278] In some cases, if the task result only needs to express the processing scope, it can carry only the first version information and the first content unit set.

[0279] In other cases, if the task result also needs to express the exclusion range, a second set of content units can be carried at the same time.

[0280] In some other cases, when the system needs to support both range verification and difference checking simultaneously, all three can be encapsulated together as a structured result object for output.

[0281] It should be noted that the above result objects can be stored in JSON, key-value pairs or database record format. In practical applications, other data encapsulation formats can also be selected, and this application does not limit them.

[0282] In the above example, the system determines whether the task results come from the same index version based on the first version information, and confirms the scope of objects covered and excluded by each task result based on the first content unit set and the second content unit set, so that the processing boundaries of the outputs of different intelligent agent instances are kept consistent, thereby improving the accuracy and traceability of task result integration.

[0283] In one example, the task unit is generated based on one or more of the following: a task scheduling module, user input, a master program, and an agent management module.

[0284] For example, the task scheduling module is a coordinating component that is responsible for receiving batches of tasks and automatically breaking down the tasks to be executed into independent task units that can be run serially or in parallel, based on rules such as resource load, priority, execution time limit, and device status. At the same time, it manages task queuing, distribution, retry, and execution progress.

[0285] For example, user input refers to the human-computer interaction entry point, which is used to receive text instructions, form parameters, batch file uploads, checkbox operations, and other tasks submitted by external users that contain complete business requirements and are to be executed. After preprocessing, these tasks are split into multiple independent task units.

[0286] For example, the main control program refers to the overall control program, whose function is to connect all functional modules, receive tasks to be executed, divide the tasks to be executed by combining hardware computing power and program execution logic boundaries, generate standardized task units that can be recognized by each execution component, and uniformly schedule and process them.

[0287] For example, the agent management module refers to a management component responsible for managing multiple automated agent instances. Its function is to receive a task to be executed, break it down into task units adapted to each agent instance based on the capability boundaries of each agent instance, assign them to the corresponding agent instances for independent execution, and simultaneously collect the task results corresponding to the task units executed by each agent instance and integrate them to obtain the final result.

[0288] It is understandable that in any of the above scenarios, the task to be executed as indicated by the task request can be split and processed to generate one or more task units.

[0289] By generating task units through multiple implementation methods, the channels for receiving tasks to be executed can be expanded, improving the applicability and compatibility of the proposed solution. Furthermore, the computational power of the task processing splitting process can be distributed, reducing the computational power pressure on the actual execution of tasks in the system.

[0290] The multi-agent task processing method based on semantic indexed documents provided in this application pre-computes the architecture-level information of the codebase into a structured semantic indexed document. Multi-agent instances always process tasks based on a consistent version of the architecture information, avoiding module comprehension biases caused by differences in exploration paths. Furthermore, since multi-agent instances process tasks based on semantic indexed documents, there is no need to explore the target codebase multiple times, reducing computational consumption and improving task processing efficiency.

[0291] In one possible implementation, after multiple agent instances complete their corresponding task units, they persistently store the modifications made to the semantic index document during execution (adding or updating entries). Subsequent new agent instances load the updated semantic index document upon startup, enabling cross-session transmission of architectural-level information.

[0292] It should be noted that the semantic index document will not be lost when the session ends. When a new developer or agent takes over the project, they only need to load the stored semantic index document to gain a complete architectural understanding of the target system.

[0293] In one possible embodiment, the physical form of the semantic indexed document includes at least one of a text file, a collection of database records, a memory object, or serialized data.

[0294] The semantic index document contains content unit identifiers, functional responsibility descriptions, and descriptions of the relationships between content units.

[0295] It should be noted that the logic of the above semantic index document includes at least one or more of the following: content unit identifier, functional responsibility description, description of the relationship between content units, source status signature, and index version identifier.

[0296] Furthermore, the physical form includes, but is not limited to: natural language text, tagged text, JSON or YAML (Ain't Markup Language) key-value pairs, database record sets, memory objects, protobuf (protocol buffer), or other serialized objects.

[0297] It should also be noted that the tag format in the semantic index document mentioned above is not limited in this embodiment of the application. Specific tag formats can be exemplified as follows: using letters as the encoding values ​​for tags of different dimensions; key-value pairs, hierarchical objects, relational tables, graph structures, or other equivalent structures can also be used.

[0298] For example, index entries in a semantically indexed document may not use discrete multi-dimensional tag encoding, but instead use a nested key-value pair structure to represent the semantic features of content units.

[0299] An example index entry is as follows: {"file": "auth.go", "function": "JWT authentication middleware","dependencies": ["pkg / jwt", "model / user"], "apis": [" / api / auth / login"], "notes": "Bearer token parsing, expiration check, API Key alternative authentication"}.

[0300] The above index entries satisfy unit independence, meaning that each index entry is generated only by the corresponding source file, and also satisfy architecture-level information injection, meaning that multiple entries are organized and injected into the large language model context.

[0301] In one possible implementation, after the agent instance determines the range of files that need to be modified based on the semantic index document, it performs a full content regeneration for each file instead of differential editing.

[0302] Specifically, this ensures that as the large language model processes each line of code, any omissions such as incomplete files will be directly reflected in the output. Moreover, each rewrite is a completely new generation, so early defects will not be carried over to subsequent tasks.

[0303] In one specific embodiment, the target system is a microservice system in a cross-technology stack microservice system refactoring scenario. This microservice system includes a Node.js frontend module (156,454 lines of code), a Go backend service (56,000 lines of code), and a TypeScript database layer (247,499 lines of code). The enterprise needs to migrate this microservice system to a unified Go language technology stack.

[0304] For example, the system first obtains the semantic index document of the target system. The semantic index document contains structured semantic description information of each content unit of the target system and corresponding version information. The structured semantic description information includes one or more of the following: the processing scope of the content unit, the association relationship of the content unit, and the exclusion scope of the content unit.

[0305] The processing scope is used to characterize the content units involved in the task to be executed, the association relationship is used to characterize the content units involved in the task to be executed that require linkage verification, and the exclusion scope is used to characterize the content units not involved in the task to be executed.

[0306] Optionally, the system analyzes the target system's codebase using a large language model based on a preset protocol framework, generating a structured semantic index document containing the functional responsibilities, dependencies, and exclusions of each module, including index entries for Node.js front-end modules. For example, this index entry includes a functional description, dependencies, and exclusions. Specifically, it might be: "User login page interaction logic, depends on the ` / api / auth / login` interface call, excludes the third-party library 'lodash' which requires no modification." Optionally, the semantic index document is persistently stored in JSON format with a version identifier "v1.0".

[0307] Upon receiving a task request for the target system (the task request is a technology stack migration task), the system performs content detection on the target system and obtains the content detection results. When processing the task request, the system selects a semantic index document with the same version information and distributes the semantic index document of that version to multiple agent instances.

[0308] Multiple agent instances include a front-end agent, a back-end agent, and a document agent. The front-end agent is responsible for refactoring Node.js modules, the back-end agent is responsible for adapting Go services, and the document agent generates migration documents.

[0309] When the semantic index document is distributed, the system writes the semantic index document with the version identifier "v1.0" to a shared storage path in the file system or database system that is shared and read by multiple agent instances. The front-end agent, back-end agent and document agent automatically read the semantic index document of this version from the target location when they start up.

[0310] Alternatively, in another possible implementation, a message notification mechanism can be used to send semantic index documents of the same version to each agent instance. After the front-end agent loads the index, it identifies the Node.js module scopes that need to be refactored, "views / login.jsx" and "services / auth.js", and excludes the "node_modules" directory, which does not need to be modified.

[0311] The system then breaks down the task to be executed indicated by the task request into one or more task units and distributes them to the corresponding agent instances according to the task type. The task units include front-end development tasks, back-end development tasks, test writing tasks, and document update tasks.

[0312] In this scenario, the actual subtasks assigned are: the front-end agent is responsible for refactoring the Node.js module into Go code, the back-end agent adapts the Go service and the new database interface, and the documentation agent generates migration documents.

[0313] For example, the front-end agent receives the task unit "Refactor 'views / login.jsx' into a Go module", and the back-end agent receives the task unit "Update the ' / api / auth / login' interface to adapt to the new database structure".

[0314] Each agent instance executes the corresponding task unit based on the received semantic index document of the same version, determines the content unit involved by combining the processing scope, excludes the content unit not involved by combining the exclusion scope, identifies the content unit that needs to be processed in conjunction with the relationship, and outputs the corresponding task result.

[0315] For example, the front-end agent generates complete Go module code based on the relationship 'views / login.jsx' in the index that depends on 'services / auth.js', ensuring that the refactored code is consistent with the back-end interface; the back-end agent, based on the exclusion scope 'database / models.go' in the index, does not require modification, only updating the interface logic; the documentation agent generates migration documentation based on the functional responsibility description in the index, which details the functionality and dependencies of the refactored module.

[0316] Furthermore, the task results returned by each agent instance carry first version information, which is "v1.0" or the index version information corresponding to the execution time. It may also carry a first content unit set and a second content unit set. The first content unit set includes content units involved in the task to be executed, and the second content unit set includes content units not involved in the task to be executed.

[0317] Taking the front-end agent as an example, the task results submitted by the front-end agent involve 'views / login.jsx' and 'services / auth.js', while the task results submitted by the back-end agent involve ' / api / auth / login'.

[0318] When integrating task results, the system first identifies multiple task results to determine the content units corresponding to each task result, and then determines whether there are any content units that need to be linked for verification based on the correlation.

[0319] In some cases, when there are content units that require linked verification, consistency checks are performed on the relevant content units. This consistency check performs compatibility checks on the refactored code of the front-end agent and the interface updates of the back-end agent based on the relationships in the semantic index documents, including checking whether the interface paths match.

[0320] If a conflict is detected, such as the front-end Agent not updating the dependency 'services / auth.js', the system will trigger a dependency completion prompt, requiring the front-end Agent to make the necessary changes. After the consistency check passes, the results of multiple tasks will be integrated into the final result corresponding to the task request.

[0321] When the content detection results represent changes in the content units of the target system, the system triggers a version update of the semantic index document, performs full or partial modifications to the semantic index document, and marks the version information of the original semantic index document as outdated.

[0322] In this scenario, the system detects that the refactored 'views / login.jsx' of the front-end Agent has been submitted, indicating that the content unit of the target system has changed. This triggers an incremental update of the semantic index document, which performs some modifications to the semantic index document. The index document version is upgraded from "v1.0" to "v1.1", and a new entry is added to describe the functions and dependencies of the refactored Go module. At the same time, the original version information "v1.0" of the semantic index document is marked as obsolete.

[0323] During the result integration or result retrieval process, the system also extracts the first version information of the semantic index documents corresponding to multiple task results, and extracts the second version information of the current semantic index document; when the first version information and the second version information are inconsistent, it is determined that there is a version conflict in the semantic index document.

[0324] In this scenario, if the backend agent executes the task based on the old version "v1.0", while the second version information of the current semantic index document is already "v1.1", the system determines that there is a version conflict and generates a prompt message indicating that there is a semantic index document version conflict during the current task processing.

[0325] Specifically, the backend Agent is prompted to re-execute the interface adaptation task based on the latest version "v1.1"; or the system directly calls the current semantic index document "v1.1" and redistributes it to multiple agent instances, so that the multiple agent instances re-execute their respective corresponding task units based on the current semantic index document and obtain the corresponding task results again.

[0326] Throughout the process, the semantic index document in JSON format is applicable to Node.js, Go, and TypeScript modules, and is parsed and processed jointly by the front-end agent, back-end agent, and document agent.

[0327] Figure 5 A schematic diagram of the structure of the multi-agent task processing device based on semantically indexed documents provided in this application is shown below. Figure 5 As shown, the multi-agent task processing device 50 based on semantically indexed documents provided in this embodiment includes:

[0328] The acquisition module 501 is used to acquire the semantic index document of the target system and store the semantic index document in a non-volatile storage medium; wherein, the semantic index document includes the structured semantic description information of each content unit in the target system and the version information of the target system, and the structured semantic description information includes the functional responsibility description and the relationship description between the content units.

[0329] The distribution module 502 is used to distribute a semantic index document containing version information matching the target system to multiple agent instances in response to a task request for the target system.

[0330] The processing module 503 is used to determine at least one task unit corresponding to the task request. Each agent instance executes the task unit based on the semantic index document to obtain the task result corresponding to the agent instance. The task unit is used to represent the processing object to be executed by the corresponding agent instance.

[0331] The processing module 503 is also used to integrate the results of multiple tasks to obtain the final result; wherein, the task result is the processing result of the task unit, and the final result is the processing result of the task to be executed indicated by the task request.

[0332] In one possible implementation, a semantic index document containing version information matching the target system is distributed to multiple agent instances, and the distribution module 502 is used for:

[0333] The semantic index document containing version information matching the target system is stored in the target location; where the target location is a file system or database system shared and read by multiple agent instances; or,

[0334] The semantic index document containing version information matching the target system is sent to each agent instance based on a message notification mechanism.

[0335] In one possible implementation, in response to a task request for the target system, the processing module 503 is further configured to:

[0336] Perform content inspection on the target system and obtain the content inspection results of the target system;

[0337] If it is determined that the content detection result represents a change in the content unit of the target system, then the step of updating the version of the semantic index document is triggered; wherein, the step of updating the version of the semantic index document is used to make full or partial modifications to the semantic index document.

[0338] In one possible implementation, if it is determined that the content detection result represents a change in the content unit of the target system, the processing module 503 is further configured to:

[0339] Mark the version information of the semantic index documents of the target system as outdated.

[0340] In one possible implementation, the semantic index document stored in a non-volatile storage medium is used for reuse among multiple task units; or,

[0341] Semantic index documents stored in non-volatile storage media are used for reuse across multiple session units, where a session unit is a session instance between an AI model and a user; or,

[0342] Semantic index documents stored in non-volatile storage media are used for reuse among multiple agent instances.

[0343] In one possible implementation, the structured semantic description information in the semantic index document includes: the association relationship of content units, which represents the content units that need to be linked and verified in the task to be executed;

[0344] The processing module 503 integrates the results of multiple tasks to obtain the final result, and is used for:

[0345] Identify the results of multiple tasks and determine the content unit corresponding to each task result;

[0346] Based on the association, if it is determined that there are content units that need to be linked for verification corresponding to multiple task results, then a consistency check is performed on the content units that need to be linked for verification.

[0347] If the consistency check passes, the results of multiple tasks are integrated to obtain the final result.

[0348] In one possible implementation, the processing module 503 is further configured to:

[0349] Based on semantically indexed documents and task units, determine one or more of the following: the processing scope of the content unit corresponding to the task unit, the association relationship of the content unit, and the exclusion scope of the content unit.

[0350] The processing scope represents the content units involved in the task unit; the exclusion scope represents the content units not involved in the task unit.

[0351] In one possible implementation, the processing module 503 is further configured to:

[0352] Based on the exclusion scope, determine the non-processing units corresponding to each task unit; where non-processing units are content units not involved in the task unit.

[0353] The non-processing unit is written into the task result corresponding to the task unit; the non-processing unit is used to perform modification verification when the task results are integrated to obtain the final result. The modification verification is used to check whether there are unnecessary modifications or the modification range is out of bounds in the task result.

[0354] In one possible implementation, the processing module 503 is further configured to:

[0355] Extract the first version information and the second version information; wherein, the first version information is the version information of the semantic index document corresponding to the results of multiple tasks, and the second version information is the version information of the current semantic index document;

[0356] If it is determined that the information in the first version and the information in the second version are inconsistent, then perform at least one of the following:

[0357] Generate a prompt message; the prompt message is used to indicate a version conflict in the semantic index document;

[0358] The current semantic index document is retrieved and distributed to multiple agent instances. Each agent instance executes the corresponding task unit based on the current semantic index document, and the task result corresponding to the agent instance is obtained.

[0359] In one possible implementation, the task unit includes: front-end development task, back-end development task, test writing task, and document update task.

[0360] In one possible implementation, the task result includes: first version information, and at least one of the following: a first set of content units and a second set of content units;

[0361] The first version information consists of the version information of the semantic index documents corresponding to the results of multiple tasks; the first content unit set includes the content units involved in the task to be executed, and the second content unit set includes the content units not involved in the task to be executed.

[0362] In one possible implementation, the task unit is generated based on one or more of the following:

[0363] The module includes a task scheduling module, a user input module, a main control program, and an agent management module.

[0364] The multi-agent task processing device based on semantic indexed documents provided in this embodiment can execute the methods provided in the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0365] Figure 6 A schematic diagram of the structure of the electronic device provided in this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the electronic device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0366] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0367] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0368] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0369] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0370] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

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

[0372] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0373] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0374] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0375] The division of units is merely 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. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0377] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0378] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0379] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0380] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A multi-agent task processing method based on semantically indexed documents, characterized in that, include: Obtain the semantic index document of the target system and store the semantic index document in a non-volatile storage medium; wherein, the semantic index document includes structured semantic description information of each content unit in the target system and version information of the target system, and the structured semantic description information includes functional responsibility description and description of the relationship between content units; In response to a task request for the target system, a semantic index document containing version information matching the target system is distributed to multiple agent instances; At least one task unit corresponding to the task request is determined, and each agent instance executes the task unit based on the semantic index document to obtain the task result corresponding to the agent instance; wherein, the task unit is used to characterize the processing object to be executed by the corresponding agent instance; The final result is obtained by integrating the results of multiple tasks; wherein, the task result is the processing result of the task unit, and the final result is the processing result of the task to be executed indicated by the task request.

2. The method according to claim 1, characterized in that, The semantic index document containing version information matching the target system is distributed to multiple agent instances, including: The semantic index document containing version information matching the target system is stored in the target location; wherein, the target location is a file system or database system shared and read by the multiple intelligent agent instances; or, The semantic index document containing version information matching the target system is sent to each of the agent instances based on a message notification mechanism.

3. The method according to claim 1, characterized in that, In response to a task request for the target system, the method further includes: Content detection is performed on the target system to obtain the content detection results of the target system. If it is determined that the content detection result indicates a change in the content unit of the target system, then the step of updating the version of the semantic index document is triggered; wherein, the step of updating the version of the semantic index document is used to make full or partial modifications to the semantic index document.

4. The method according to claim 3, characterized in that, If it is determined that the content detection result indicates a change in the content unit of the target system, the method further includes: The version information of the semantic index documents of the target system is marked as outdated.

5. The method according to claim 1, characterized in that, Semantic indexed documents stored in non-volatile storage media are used for reuse across multiple task units; or, Semantic index documents stored in non-volatile storage media are used for reuse among multiple session units, which are session instances between users based on artificial intelligence models; or, Semantic index documents stored in non-volatile storage media are used for reuse among multiple agent instances.

6. The method according to claim 1, characterized in that, The structured semantic description information in the semantic index document includes: the association relationship of content units, wherein the association relationship represents the content units involved in the task to be executed that need to be linked for verification; The process of integrating the results of multiple tasks to obtain the final result includes: Identify the results of the multiple tasks and determine the content unit corresponding to each task result; Based on the aforementioned association, if it is determined that there are content units that need to be linked for verification among the content units corresponding to multiple task results, then a consistency verification is performed on the content units that need to be linked for verification. If the consistency check passes, the results of the multiple tasks are integrated to obtain the final result.

7. The method according to claim 6, characterized in that, The method further includes: Based on the semantic indexed document and task unit, determine one or more of the following: the processing scope of the content unit corresponding to the task unit, the association relationship of the content unit, and the exclusion scope of the content unit. Wherein, the processing range represents the content units involved in the task unit; the exclusion range represents the content units not involved in the task unit.

8. The method according to claim 7, characterized in that, The method further includes: Based on the exclusion range, determine the non-processing unit corresponding to each task unit; wherein, the non-processing unit is a content unit not involved in the task unit; The non-processing unit is written into the task result corresponding to the task unit; wherein, the non-processing unit is used to perform modification verification when the task results are integrated to obtain the final result, and the modification verification is used to verify whether there are unnecessary modifications or the modification range is out of bounds in the task result.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: Extract first version information and second version information; wherein, the first version information is the version information of the semantic index document corresponding to the results of the multiple tasks, and the second version information is the version information of the current semantic index document; If it is determined that the first version information and the second version information are inconsistent, then at least one of the following shall be performed: Generate a prompt message; wherein the prompt message is used to indicate a version conflict in the semantic index document; The current semantic index document is invoked and distributed to multiple agent instances. Each agent instance executes the corresponding task unit based on the current semantic index document to obtain the task result corresponding to the agent instance.

10. The method according to any one of claims 1-8, characterized in that, The task units include: front-end development tasks, back-end development tasks, test writing tasks, and document update tasks.

11. The method according to any one of claims 1-8, characterized in that, The task results include: first version information, and at least one of the following: a first set of content units and a second set of content units; Wherein, the first version information is the version information of the semantic index documents corresponding to the results of the multiple tasks; the first content unit set includes the content units involved in the task to be executed, and the second content unit set includes the content units not involved in the task to be executed.

12. The method according to any one of claims 1-8, characterized in that, The task unit is generated based on one or more of the following: The module includes a task scheduling module, a user input module, a main control program, and an agent management module.

13. A multi-agent task processing device based on semantically indexed documents, characterized in that, include: An acquisition module is used to acquire the semantic index document of the target system and store the semantic index document in a non-volatile storage medium; wherein, the semantic index document includes structured semantic description information of each content unit in the target system and version information of the target system, and the structured semantic description information includes functional responsibility description and description of the relationship between content units; The distribution module is used to distribute semantic index documents containing version information matching the target system to multiple agent instances in response to a task request for the target system. A processing module is used to determine at least one task unit corresponding to the task request, and each agent instance executes the task unit based on the semantic index document to obtain the task result corresponding to the agent instance; wherein, the task unit is used to characterize the processing object to be executed by the corresponding agent instance; The processing module is further configured to integrate multiple task results to obtain a final result; wherein the task result is the processing result of the task unit, and the final result is the processing result of the task to be executed indicated by the task request.

14. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-12.

16. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-12.

Images