A multi-tool cooperative interaction method and system based on natural language instructions

Abstract

The application relates to the technical field of computers and provides a multi-tool cooperative interaction method and system based on a natural language instruction, which comprises the following steps: receiving an interaction request carrying a user input instruction through a unified interaction interface and generating an interaction session identifier; determining an intention type and a target entity based on the user input instruction, wherein the intention type comprises an editing intention and a generating intention; searching for a processing tool corresponding to the intention type in multiple processing tools, routing the interaction request to the corresponding processing tool, and enabling the processing tool to perform an operation, wherein the operation granularity of at least two processing tools is different; and continuously sending structured events to an interaction terminal in a streaming event channel, wherein each structured event carries the interaction session identifier and a stage identifier, and the stage identifier is used for indicating an execution stage in which the current interaction is located. The application realizes accurate analysis of a user natural language instruction and fine-grained tool linkage, guarantees the real-time performance and traceability of an interaction process, and improves interaction efficiency and reliability.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and specifically to a multi-tool collaborative interaction method and system based on natural language commands. Background Technology

[0002] Currently, in the field of document editing and intelligent interaction, especially in scenarios involving complex documents, users typically issue commands to the system using natural language to modify or generate documents. However, most existing interaction solutions treat the entire document as the editing unit, resulting in coarse-grained interaction that makes it difficult to precisely map natural language commands to specific paragraphs or chapters within the document. Furthermore, existing intelligent assistants often only generate text suggestions, lacking structured interaction with specific document objects and editing tools, forcing users to manually perform operations such as copying and pasting, leading to inefficiency. In addition, for high-risk operations such as full-text rewriting, existing technologies lack effective concurrency control mechanisms, easily resulting in repeated execution of operations and overwriting manually refined content in the event of network retries or user accidental touches. Moreover, when users input complex commands containing multiple intentions, existing systems lack conflict detection and orderly scheduling mechanisms, easily leading to chaotic execution logic. Therefore, there is an urgent need for an interaction solution that can accurately identify intentions, achieve fine-grained tool interaction, and possess high reliability. Summary of the Invention

[0003] To address the problems of existing technologies, such as the inability to accurately map natural language commands to document operations, low interaction efficiency, and lack of concurrency control mechanisms, this application proposes a multi-tool collaborative interaction method and system based on natural language commands, which achieves accurate intent recognition, orderly scheduling of tools, and reliable execution of high-risk operations.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: A multi-tool collaborative interaction method based on natural language commands, applied on a server side, includes: receiving an interaction request carrying user input commands through a unified interaction interface, and generating an interaction session identifier corresponding to the interaction request; determining the intent type and target entity based on the user input commands, wherein the intent type includes at least editing intent and generating intent, and the target entity is used to locate the target object of the operation; searching for a processing tool corresponding to the intent type among multiple processing tools, and routing the interaction request to the corresponding processing tool so that the processing tool performs the operation, wherein at least two of the multiple processing tools have different operation granularities, and the operation granularity refers to the scope of the operation performed by the processing tool on the document; and continuously sending structured events to the interactive terminal through a streaming event channel, each structured event carrying the interaction session identifier and a stage identifier, wherein the stage identifier is used to indicate the current execution stage of the interaction.

[0005] The above solution establishes the baseline for interaction by receiving requests and generating interaction session identifiers through a unified interaction interface; it achieves accurate parsing of user natural language commands by determining intent types and target entities; it enables fine-grained operations on documents by routing to processing tools with different granularities; and it ensures the real-time nature and traceability of the interaction process by feeding back structured events through a streaming event channel.

[0006] Preferably, determining the intent type and target entity based on the user input command specifically includes: in a first stage, performing semantic segmentation on the user input command to obtain at least one intent candidate and a corresponding target entity; in a second stage, performing domain verification on each intent candidate in conjunction with the structural semantic anchor of the target object type, and outputting intent parsing results, wherein the intent parsing results include intent type, target entity, and confidence score, and the structural semantic anchor corresponds to a preset semantic unit boundary in the target object, wherein the intent type further includes question-and-answer intent, security interception intent, and unknown intent; comparing the confidence score with at least two preset thresholds: when the confidence score is not lower than a first preset threshold, the intent parsing result is directly routed to the corresponding processing tool; when the confidence score is lower than the first preset threshold but not lower than a second preset threshold, a clarification query event is sent to the interactive terminal through the streaming event channel, and routing continues after receiving a confirmation command; when the confidence score is lower than the second preset threshold, the intent type is downgraded to an unknown intent and routed to a fallback processing flow; wherein the first preset threshold is greater than the second preset threshold.

[0007] This preferred solution effectively improves the accuracy of intent recognition through a two-stage identification and confidence threshold strategy, and provides clarification or fallback mechanisms for low confidence situations, thereby enhancing the robustness of the system.

[0008] Preferably, when multiple intent candidates are determined based on the user input command, the method further includes: performing conflict detection on the multiple intent candidates; sorting the mutually exclusive intents based on a preset priority rule and generating an ordered tool call queue; when both the editing intent and the generating intent exist for the same target object, they are determined to be mutually exclusive and conflicting, the editing intent is placed before the generating intent, and the generating intent is reconfirmed after the editing intent is executed; when the multiple intent candidates act on different target objects, they are determined to be non-conflicting, allowing the corresponding processing tools to execute in parallel.

[0009] Preferably, when the processing tool corresponding to the generation intent is routed and the operation is a full generation operation, the method further includes: generating an operation authorization token; binding the operation authorization token with a version status snapshot and storing it in a cache and setting an expiration date; the version status snapshot includes a version identifier and a target object content digest calculated based on a preset hash algorithm; sending a confirmation control event carrying the operation authorization token and the version status snapshot to the interactive terminal through the streaming event channel; upon receiving the confirmation instruction, performing the following checks in sequence: querying the cache to verify that the operation authorization token exists and is in an unconsumed state; comparing the target object content digest in the version status snapshot with the target object content digest of the current version in the persistent storage unit; and updating the state of the operation authorization token from unconsumed to consumed through a comparison and exchange atomic operation; performing the full generation operation after all checks pass; if the operation authorization token does not exist, has exceeded the expiration date, has been consumed, or the target object content digest does not match, then sending an error event carrying the corresponding error code to the interactive terminal through the streaming event channel and terminating the operation.

[0010] This preferred solution effectively prevents the full generation operation from being executed concurrently or mistakenly when versions are inconsistent by using dual verification of operation authorization tokens and version state snapshots, as well as an atomic operation consumption mechanism, thus ensuring data security.

[0011] Preferably, the streaming event channel supports breakpoint resumption, and the method further includes: maintaining an event buffer queue for each interaction session identifier, the event buffer queue being used to cache a preset number of sent structured events; when a connection request is received from the interactive terminal after a connection interruption, detecting the last received event identifier carried in the connection request, the last received event identifier corresponding to the last successfully received structured event by the interactive terminal; based on the last received event identifier, locating the corresponding position in the event buffer queue, and sequentially re-pushing the structured events that have not yet been received by the interactive terminal after the corresponding position.

[0012] Preferably, before determining the intent type, the method further includes: loading context data associated with the target object from a persistent storage unit based on the target object identifier carried in the interaction request, wherein the context data includes at least a content index mapping table and historical operation records of the target object; and the target object identifier includes at least an object type identifier, a version identifier, and a content type identifier.

[0013] Preferably, the content index mapping table adopts a hierarchical path addressing protocol. The method further includes: generating a hierarchical path addressing identifier for the target unit in the target object, wherein the hierarchical path addressing identifier is composed of an object type identifier, a chapter semantic key, and a unit number combined in a hierarchical path format, wherein the chapter semantic key corresponds to the semantic identifier of a preset chapter in the target object, and the unit number is a natural sequence number starting from zero within its respective chapter; maintaining the content index mapping table, using the hierarchical path addressing identifier as the key and the target unit content and its offset in the target object as the value; responding to the completion of the processing tool, performing a difference operation on the target object content before and after editing, incrementally updating the offset of the affected unit in the content index mapping table based on the difference result, and writing the update result back to the persistent storage unit.

[0014] This preferred solution solves the positioning drift problem caused by dynamic changes in document structure through hierarchical path addressing protocol and incremental update mechanism, and ensures the stability of cross-version paragraph positioning.

[0015] Furthermore, this invention also provides a multi-tool collaborative interaction method based on natural language commands, applied to an interactive terminal. The method includes: sending an interaction request carrying user input commands to a unified interaction interface of a server, and obtaining an interaction session identifier corresponding to the interaction request; receiving structured events continuously sent by the server through a streaming event channel, determining the event type based on the stage identifier in each structured event, and rendering the corresponding interactive interface element according to the event type; when receiving a confirmation control event carrying an operation authorization token and a version status snapshot, displaying a confirmation interaction control, and submitting the operation authorization token and the version status snapshot to the server in response to the user's confirmation operation; when a connection interruption with the server is detected, carrying the last received event identifier in the request to re-establish the connection, so as to continue receiving subsequent structured events from the breakpoint.

[0016] Furthermore, this invention also provides a multi-tool collaborative interaction system based on natural language commands. The system includes: a request receiving module configured to receive an interaction request carrying user input commands through a unified interaction interface and generate an interaction session identifier; an intent determination module configured to determine the intent type and target entity based on the user input commands, wherein the intent type includes at least editing intent and generating intent, and the target entity is used to locate the target object of the operation; a routing scheduling module configured to search for a processing tool corresponding to the intent type among multiple processing tools and route the interaction request to the corresponding processing tool so that the processing tool performs the operation, wherein at least two processing tools have different operation granularities, and the operation granularity refers to the range of operations performed by the processing tool on the document; a tool execution module configured to execute the operation corresponding to the processing tool; and a streaming interaction module configured to continuously send structured events to the interaction terminal through a streaming event channel, wherein each structured event carries the interaction session identifier and stage identifier.

[0017] In addition, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0018] Beneficial effects: This invention establishes a standardized interaction entry point through the generation of a unified interaction interface and interaction session identifier, facilitating end-to-end tracking. By combining two-stage intent recognition with a confidence threshold strategy, it can accurately identify various intents such as editing and generating, and proactively clarify when confidence is insufficient, significantly reducing the risk of misoperation. By combining operation authorization tokens with version state snapshots and utilizing compare-and-swap atomic operations for token consumption, it achieves concurrent isolation of high-risk operations at the server level, effectively preventing the repeated execution or overwriting of modified content by operations such as full-text rewriting. Through a hierarchical path addressing protocol and an incrementally updated content index mapping table, it achieves stable paragraph positioning across versions, solving the positioning drift problem under dynamic document structures. Through multi-intent conflict detection and priority sorting, it ensures the orderly execution of compound instructions, improving the system's intelligence level. Through streaming event channels and a breakpoint resume mechanism, it guarantees the real-time nature of the interaction process and high availability in the event of network interruptions. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of the method flow according to an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0023] Example 1: like Figure 1 As shown, this embodiment provides a multi-tool collaborative interaction method based on natural language commands, applied to the server side. This method receives user commands through a unified interaction interface, schedules processing tools of different granularities to perform operations, and finally feeds back the execution process and results to the interactive terminal through a streaming event channel, thereby achieving efficient mapping from natural language commands to document operations.

[0024] Specifically, the method includes the following steps: Step S100: Receive an interaction request carrying user input instructions through a unified interaction interface, and generate an interaction session identifier corresponding to the interaction request.

[0025] In this embodiment, the unified interaction interface serves as a single entry point provided by the server, shielding it from the protocol differences of various underlying processing tools. Users input natural language commands through interactive terminals (such as PC clients, mobile apps, or web browsers), for example, "Could you shorten paragraph 2 of Chapter 2 in the technical solution document?" The interactive terminal encapsulates this command into an interaction request, the request body containing parameters such as document identifier, version identifier, content type, and user input text. Upon receiving this request, the server generates a globally unique interaction session identifier, for example, in the format "{document identifier}-{timestamp}-{random suffix}". This interaction session identifier serves as the unique index key for this round of interaction, persisting throughout all subsequent stages such as intent recognition, tool scheduling, and event push, ensuring the traceability and consistency of the interaction process. Through the design of the unified interaction interface, the server can handle diverse user requests in a standardized manner, reducing system coupling and facilitating the subsequent expansion of new processing tools or interaction protocols.

[0026] Step S200: Determine the intent type and target entity based on the user input command. The intent type includes at least editing intent and generating intent.

[0027] After generating the interaction session identifier, the server calls the intent recognition module to parse the user input instructions. This process aims to extract structured operation instructions from unstructured natural language text. The intent type characterizes the category of operation the user expects to perform. For example, "editing intent" indicates that the user wants to modify, delete, or insert parts of the document's content; "generation intent" indicates that the user wants to regenerate all or part of the document's content based on specific conditions, such as "regenerate the summary section." The target entity is used to locate the specific object of the operation. For example, the target entity can be a specific paragraph, chapter, or the entire document. In this embodiment, the intent recognition module can combine contextual information (such as the current document structure and historical operation records) to improve the accuracy of recognition. For example, for the above user input, the intent recognition module parses it as an "editing intent," and the target entity is "the second paragraph of chapter 2 in the technical solution document." By clearly defining the intent type and target entity, the system can accurately understand user needs, providing a basis for subsequent tool routing decisions.

[0028] Step S300: Find the processing tool corresponding to the intent type among multiple processing tools, and route the interaction request to the corresponding processing tool so that the processing tool can perform an operation. Among the multiple processing tools, at least two processing tools have different operation granularities.

[0029] After determining the intent type and target entity, the server distributes the interaction request to the corresponding processing tool according to a preset routing strategy. The key to this embodiment is that the processing tools have different operational granularities to adapt to diverse user needs. Operational granularity refers to the scope of the document operations performed by the processing tool. For example, for an "editing intent," the system can route to a paragraph-level editing tool, which can precisely modify a paragraph or sentence in the document, exhibiting finer operational granularity. For a "generation intent," the system can route to a full-text generation tool, which can regenerate the entire document or a complete chapter based on context, exhibiting coarser operational granularity. By setting processing tools with different operational granularities, the system can flexibly respond to users' refined editing needs and macro-level generation needs, avoiding the problems of low operational efficiency or insufficient accuracy caused by a single-granularity tool. Specifically, the routing and scheduling module can maintain a mapping table between intent types and processing tools. Based on the parsed intent type, it queries this mapping table to determine the target processing tool and passes the parameters carried in the interaction request (such as the target entity and user requirement description) to that tool. Upon receiving a request, the processing tool executes specific business logic, such as calling the language model to generate modification suggestions or new content, and returns the execution result.

[0030] In step S400, structured events are continuously sent to the interactive terminal via a streaming event channel. Each structured event carries an interactive session identifier and a stage identifier. The stage identifier is used to indicate the current execution stage of the interaction.

[0031] During or after the processing tool's operation, the server does not wait for all results to be generated before returning them all at once. Instead, it continuously pushes structured events to the interactive terminal through a streaming event channel. This streaming event channel can be, for example, a long-connection channel established based on server-side event sending technology or the WebSocket protocol. Structured events refer to event messages with a preset data format, such as JSON data packets. Each structured event carries an interaction session identifier so that the interactive terminal can associate it with the correct interaction session context. In addition, each event carries a stage identifier to indicate the current execution stage of the interaction. Stage identifiers can include states such as "Intent Recognition," "Tool Routing," "Execution," "Generation," and "Completed." For example, after intent recognition is complete, the server sends an event with the stage identifier "Intent Recognition Completed" to inform the user that the system has understood their request; during the processing tool's execution, the server can send events with the stage identifier "Generation" word by word or sentence by sentence, achieving real-time feedback like a typewriter effect. Through the combination of streaming event channels and stage identifiers, users can perceive the system's processing progress and status in real time, improving the transparency and experience of the interaction. Especially when dealing with time-consuming full generation operations, streaming feedback can effectively alleviate users' waiting anxiety and allow users to preview content in real time during the generation process, thus improving interaction efficiency.

[0032] In summary, this embodiment achieves standardized access to requests through a unified interaction interface, maps natural language commands to structured operations through intent recognition, achieves compatibility between fine-grained and macro-level operations through the scheduling of tools at different granularities, and achieves real-time feedback and state synchronization of the interaction process through a streaming event channel, thereby constructing an efficient, flexible, and user-friendly multi-tool collaborative interaction system.

[0033] Example 2: Based on the above embodiments, this embodiment provides a detailed description of the process for determining the intent type and target entity. Specifically, this process employs a two-stage identification mechanism, combined with a confidence threshold strategy, to improve the accuracy of intent recognition and the robustness of the system.

[0034] Step S201: In the first stage, the user input command is semantically segmented to obtain at least one intent candidate and its corresponding target entity.

[0035] In this stage, the server-side intent recognition module first preprocesses the natural language commands input by the user. Considering that user commands may contain multiple independent operational needs, such as "Please shorten the second paragraph and then regenerate the summary," the system needs to break it down into independent execution units. Specifically, the system uses preset connectives (such as "then," "in addition," "at the same time," etc.) as segmentation signals to semantically segment the user input commands, thereby obtaining at least one intent fragment. For each intent fragment, the system initially extracts its intent candidates and corresponding target entities. Intent candidates represent the type of operation the user may expect to perform, while target entities represent the specific object of the operation, such as a specific paragraph, chapter, or the entire document.

[0036] Step S202: In the second stage, the domain verification of each intent candidate is performed in combination with the structural semantic anchor points of the target object type, and the intent parsing result is output. The intent parsing result includes intent type, target entity and confidence score. The structural semantic anchor points correspond to the preset semantic unit boundaries in the target object. The intent type also includes question answering intent, security interception intent and unknown intent.

[0037] Since general semantic analysis often struggles to accurately adapt to the document structure of a specific domain, this embodiment introduces structural semantic anchors for domain validation. Structural semantic anchors refer to predefined semantic unit boundaries within the target object. For example, in a research and development document scenario, structural semantic anchors include the boundary positions of specific chapters such as "Technical Solution Chapter," "Test Report Chapter," and "Requirements Specification Chapter." The system matches and validates the intent candidates extracted in the first stage against the structural semantic anchors of the target object to determine whether the target entity exists within a valid semantic unit, thereby correcting the initial extraction results. For example, if a user command points to "paragraph 5 of chapter 3," but the structural semantic anchors show that the chapter contains only 3 paragraphs, the system can determine that the target entity is ambiguous or incorrect and adjust the confidence score accordingly. After validation, the system outputs intent parsing results containing the intent type, target entity, and confidence score. The intent type includes not only the aforementioned editing and generation intents but also question-and-answer intents, security interception intents, and unknown intents to cover a wider range of interaction scenarios.

[0038] Step S203: Compare the confidence score with at least two preset thresholds, and execute different processing paths based on the comparison results.

[0039] To balance the efficiency of automated execution with operational security, this embodiment sets at least two preset thresholds: a first preset threshold and a second preset threshold, with the first preset threshold being greater than the second preset threshold. As an example, the first preset threshold can be set to 0.85, and the second preset threshold can be set to 0.6. The system triggers different processing logic based on the confidence score's range. When the confidence score is not lower than the first preset threshold (e.g., a confidence score greater than or equal to 0.85), the system determines that the intent recognition result is highly reliable and directly routes the intent parsing result to the corresponding processing tool for execution. This path is suitable for scenarios where user instructions are clear and the target entity is well-defined, enabling millisecond-level rapid response and improving interaction efficiency.

[0040] When the confidence score is below a first preset threshold but not below a second preset threshold (e.g., a confidence score between 0.6 and 0.85), the system determines that the intent recognition result has a certain degree of uncertainty, and direct execution may lead to the risk of misoperation. In this case, the system sends a clarification query event to the interactive terminal via a streaming event channel. This event carries the system's inferred intent information and is presented to the user in the form of a query, such as "Do you mean modifying paragraph 2 of chapter 3 in the project document?". The system pauses subsequent routing and resumes execution only after receiving confirmation from the user via the interactive terminal. This mechanism effectively avoids misediting or misgeneration caused by semantic ambiguity, enhancing the system's fault tolerance.

[0041] When the confidence score falls below a second preset threshold (e.g., a confidence score less than 0.6), the system determines that the current instruction is beyond its comprehension or poses a high risk, downgrades the intent type to an unknown intent, and routes it to a fallback process. This fallback process could include transferring the user to a live agent, providing general help documentation, or guiding the user to re-enter the instruction. This design ensures system availability in extreme situations, preventing the system from becoming unresponsive or entering an infinite loop.

[0042] Through the two-stage identification and dual-threshold triage mechanism described above, this embodiment can accurately distinguish between high-confidence commands, ambiguous commands, and invalid commands, and adopt automatic execution, interactive confirmation, and fallback strategies respectively. This significantly reduces the risk of misoperation while ensuring operational efficiency, and improves the robustness and user experience of multi-tool collaborative interaction.

[0043] Example 3: Building upon the above embodiments, this embodiment provides a detailed explanation of the concurrency control mechanism for full-text generation operations. In document editing scenarios, full-text generation operations (such as full-text rewriting) are typically time-consuming and have a wide impact. If network latency causes users to click repeatedly, or if the system automatically retryes due to timeouts, concurrency issues can easily arise, resulting in the overwriting of manually refined content. To address this, this embodiment introduces an operation authorization token mechanism, employing two-phase confirmation and triple verification logic to ensure the security and idempotency of the operation.

[0044] Specifically, when the route is to the processing tool corresponding to the generation intent and the operation is a full generation operation, the method also includes the following steps: Step S301: Generate an operation authorization token, bind the operation authorization token to the version status snapshot, store it in the cache, and set the validity period. The version status snapshot includes a version identifier and a summary of the target object content calculated based on a preset hash algorithm.

[0045] In this phase, before officially executing the full generation operation, the server first generates a globally unique operation authorization token. This token can be generated in the format "{interaction session identifier}-rewrite-{timestamp}", for example, "msg-001-rewrite-1700000001". Subsequently, the server constructs a version state snapshot, which includes the current document's version identifier and a content digest of the target object calculated based on a preset hash algorithm (such as SHA-256). The content digest is a digital fingerprint of the document content; any slight change in content will cause the digest value to change. The server stores the operation authorization token as the key and the version state snapshot as the value in a cache (such as Redis), setting an expiration time (e.g., 5 minutes). The expiration time is designed to prevent the token from occupying storage resources for an extended period and also limits the time window for user confirmation, avoiding the risk of version conflicts due to prolonged delays in confirmation.

[0046] Step S302: Send a confirmation control event carrying an operation authorization token and a version status snapshot to the interactive terminal through the streaming event channel.

[0047] After issuing the token, the server does not immediately execute the generation operation. Instead, it pushes a confirmation control event to the interactive terminal via a streaming event channel. This event carries the operation authorization token and a version state snapshot, informing the user that a full generation operation is about to be performed and prompting for confirmation. Upon receiving this event, the interactive terminal renders a confirmation button or dialog box on the interface, awaiting the user's decision. This design returns the execution power of high-risk operations to the user, avoiding the irreversible consequences that might result from automatic system execution.

[0048] Step S303: After receiving the confirmation instruction, perform the following verifications in sequence: query the cache to verify that the operation authorization token exists and is in an unconsumed state; compare the target object content digest in the version state snapshot with the target object content digest of the current version in the persistent storage unit; and update the state of the operation authorization token from unconsumed to consumed through a comparison and exchange atomic operation.

[0049] When the user clicks the confirmation button on the interactive terminal, the client submits the operation authorization token and version status snapshot to the server. Upon receiving the confirmation command, the server triggers a triple verification logic to ensure the legitimacy of the operation: The first layer of verification is token existence verification. The server queries the cache to verify whether the operation authorization token exists. If the token does not exist, it means that the token has been cleared or was never issued; if the token exists but its status is "consumed," it means that the operation has already been executed. Both of these situations are considered verification failures, and the server will refuse to execute subsequent operations. This verification effectively prevents the same operation from being submitted repeatedly.

[0050] The second layer of verification is version consistency comparison. The server extracts a summary of the target object's content from the version state snapshot and compares it with the summary of the target object's content in the current version in persistent storage (such as a database). If they do not match, it means that the document content has been modified by other operations (such as editing by other users or automatic saving) during the user's confirmation period. If a full generation is forced at this time, the latest modifications will be overwritten. Therefore, the server will terminate the operation and report the version conflict to the user. This verification mechanism solves the "ABA problem," that is, the document state changes after the token is issued, ensuring data consistency.

[0051] The third layer of verification involves atomic consumption via comparison and swap. After passing the first two layers of verification, the server uses a CAS (Compare And Swap) atomic operation to attempt to update the state of the operation authorization token from unconsumed to consumed. CAS is a lock-free concurrency control mechanism that ensures that in a multi-threaded or distributed environment, only one request can successfully update the token state. If multiple requests carrying the same token arrive concurrently within a very short time window, only one request will successfully execute the CAS operation; other requests will fail because the state has already changed. This mechanism fundamentally eliminates the possibility of concurrent duplicate execution.

[0052] Step S304: The full generation operation can only be performed after all verifications pass. If the operation authorization token does not exist, has expired, has been consumed, or the content digest of the target object does not match, an error event carrying the corresponding error code is sent to the interactive terminal through the streaming event channel and the operation is terminated.

[0053] Only when all three verifications pass will the server actually invoke the processing tool to perform the full generation operation. Conversely, if any verification fails, the server will immediately terminate the operation and send an error event to the interactive terminal via a streaming event channel. The error event carries the corresponding error code, such as "TOKEN_NOT_FOUND" (token does not exist), "TOKEN_EXPIRED" (token has expired), "TOKEN_CONSUMED" (token has been consumed), or "VERSION_CONFLICT" (version mismatch). The interactive terminal displays the corresponding prompts based on the error code, guiding the user to re-initiate the request or check the document status.

[0054] Through the aforementioned two-stage confirmation and triple verification mechanism, this embodiment achieves fine-grained concurrency control over the full generation operation. This mechanism not only builds a reliable isolation barrier at the server level, effectively preventing duplicate execution issues caused by network retries, user accidental touches, or concurrent requests, but also ensures the integrity of document content through version consistency comparison, thereby improving the security and robustness of the multi-tool collaborative interaction system.

[0055] Example 4: Building upon the above embodiments, this embodiment provides a detailed explanation of the breakpoint resumption mechanism for streaming event channels. In real-world applications, network environments are often unstable, and users may experience connection interruptions due to network jitter, network switching, or other reasons while receiving streaming events. Without an effective recovery mechanism, users will lose event data during the interruption and may even need to re-initiate requests, causing the server to repeatedly execute time-consuming tool calls (such as large language model inference), resulting in resource waste and a degraded user experience. Therefore, this embodiment introduces a breakpoint resumption mechanism to ensure the continuity of the interaction process.

[0056] Specifically, the method of this embodiment includes the following steps: Step S401: The server maintains an event buffer queue for each interactive session identifier. The event buffer queue caches a preset number of sent structured events.

[0057] In this embodiment, when the server sends structured events through the streaming event channel, it simultaneously writes the events into an event buffer queue bound to the current interaction session identifier (such as the aforementioned message_id). This queue uses a first-in, first-out (FIFO) data structure and has a preset cache capacity, for example, caching the 100 most recently sent events. This design ensures the data source for resuming interrupted transmissions while avoiding unlimited memory resource consumption by limiting the queue length. Each structured event carries a sequence number when sent, used to uniquely identify the event's position in the session stream for easy subsequent location.

[0058] Step S402: When a connection request is received from the interactive terminal after the connection was interrupted, the last received event identifier carried in the connection request is detected. The last received event identifier corresponds to the last structured event successfully received by the interactive terminal.

[0059] When a connection is interrupted, the interactive terminal detects the connection error and attempts to re-establish the connection. In the reconnection HTTP request, the interactive terminal includes a last received event identifier in the request header (such as the Last-Event-ID field) or request parameters. This identifier records the sequence number of the last successfully received and processed event before the connection was lost. Upon receiving the reconnection request, the server parses the request to obtain the last received event identifier, thereby determining the client's current reception progress breakpoint.

[0060] Step S403: Based on the last received event identifier, locate the corresponding position in the event buffer queue, and re-push the structured events that have not yet been received by the interactive terminal after the corresponding position.

[0061] After obtaining the last received event identifier, the server searches for the corresponding event position in the event buffer queue. If the search is successful, it means the event is still in the buffer queue and has not been evicted. The server will skip that position and all events before it, and directly start from the next event at that position, sequentially pushing subsequent structured events back to the interactive terminal. If the search fails (e.g., due to excessive interruption time causing the event to exceed the cache capacity and be cleared), the server can notify the interactive terminal to start receiving from the beginning or execute other fallback strategies. Through this mechanism, the server does not need to re-execute pre-processing steps such as intent recognition and tool invocation, nor does it need to re-invoke the language model to generate content. It only needs to read data from the memory queue and send it, achieving zero-retry cost for breakpoint resumption. This not only improves the system's adaptability and availability in weak network environments, but also avoids the repeated consumption of server computing power, ensuring the integrity and consistency of interactive data.

[0062] Example 5: Building upon the above embodiments, this embodiment provides a detailed explanation of the context data loading mechanism and the target object addressing protocol. In complex document interaction scenarios, accurately loading context information related to the current operation and achieving stable cross-version positioning are fundamental to ensuring the accuracy of intent recognition and the reliability of operation execution.

[0063] Specifically, before determining the intent type, the method further includes: loading context data associated with the target object from a persistent storage unit based on the target object identifier carried in the interaction request; the context data includes at least the content index mapping table and historical operation records of the target object; the target object identifier includes at least the object type identifier, version identifier and content type identifier.

[0064] In this embodiment, in addition to the natural language instructions input by the user, the interaction request must also carry a clear target object identifier. The target object identifier is a unique index for the server to locate the operation object. The object type identifier distinguishes different types of documents, such as "project requirements document," "technical solution document," or "test report"; the version identifier distinguishes different iterative versions of the same document, ensuring that the operation is based on the correct historical snapshot; and the content type identifier further refines the content classification within the document, such as "body text," "figure description," or "summary." Upon receiving the request, the server loads the corresponding context data from a persistent storage unit (such as a distributed database or object storage system) based on this composite identifier. The context data includes not only the current content of the document but also a content index mapping table, which records the correspondence between the document's structured units and specific content locations; and historical operation records, which reflect the user's past modification history, helping the intent recognition module understand the user's potential needs. By preloading this context information, the system can quickly locate the target entity in subsequent processing, avoiding frequent disk I / O operations and improving response speed.

[0065] Furthermore, to address the location drift problem caused by dynamic changes in document content, this embodiment proposes a hierarchical path addressing protocol. The content index mapping table adopts the hierarchical path addressing protocol, specifically including: generating hierarchical path addressing identifiers for target units in the target object. The hierarchical path addressing identifier is composed of an object type identifier, a chapter semantic key, and a unit number combined according to the hierarchical path format. The chapter semantic key corresponds to the semantic identifier of a preset chapter in the target object, and the unit number is a natural sequence number starting from zero within its respective chapter.

[0066] Traditional document location often relies on character offsets or paragraph numbers. However, when a document undergoes insertion or deletion, the offsets of subsequent content change, causing the original location identifiers to become invalid, resulting in location drift. This embodiment solves this problem through a semantic path structure using a hierarchical path addressing protocol. Specifically, the hierarchical path addressing identifier adopts a three-level format: "object type identifier.chapter semantic key.unit number". The object type identifier corresponds to the document type, such as tech_doc representing a technical solution document; the chapter semantic key corresponds to the logical chapter within the document, such as chapter_3 representing chapter 3. This key value is preset based on the document's semantic structure and is unaffected by paragraph additions or deletions; the unit number indicates the order of specific paragraphs or units within that chapter, using a natural numbering system starting from zero. For example, the identifier tech_doc.chapter_3.para_2 represents the third paragraph of chapter 3 in the technical solution document. Even if a new paragraph is inserted before this chapter, as long as the chapter affiliation of that paragraph remains unchanged, its hierarchical path addressing identifier remains stable, thus achieving precise location across versions.

[0067] In addition, to maintain the effectiveness of the addressing protocol, the method also includes: maintaining a content index mapping table with hierarchical path addressing identifiers as keys and target cell content and its offset in the target object as values; in response to the completion of the processing tool, performing a difference operation on the target object content before and after editing, incrementally updating the offset of the affected cell in the content index mapping table based on the difference result, and writing the update result back to the persistent storage unit.

[0068] After the processing tool completes editing or generating operations, the document content may change, and the original offset information may no longer be accurate. In this case, the server will not re-index the entire document but will trigger an incremental update mechanism. The system uses a differential algorithm (such as Myers' differential algorithm) to compare the document content before and after editing and calculate the specific areas of change. Based on the differential results, the system only needs to update the offset values ​​of the affected units in the content index mapping table. For example, if a new piece of content is inserted after paragraph 1 of Chapter 3, the system only needs to update the offsets of subsequent paragraphs within that chapter, without updating the indexes of other chapters or the entire document. This incremental update method greatly reduces the computational overhead of index maintenance, ensuring system performance in high-frequency interaction scenarios. The updated index mapping table will be written back to persistent storage as a context reference for the next interaction, thus ensuring the positioning accuracy of subsequent operations.

[0069] Example 6: Building upon the above embodiments, this embodiment details the implementation of multi-intent conflict detection and ordered scheduling for scenarios where user input commands contain multiple intent candidates. In actual interaction, users often express multiple operational needs in a single natural language sentence, such as "Please shorten the second paragraph and then regenerate the summary." If the system lacks an effective conflict resolution mechanism, arbitrarily executing these intents may lead to overlapping operation results or logical confusion. Therefore, this embodiment introduces a conflict detection and priority ranking mechanism to ensure the logical rationality and data security of compound command execution.

[0070] Specifically, when multiple intent candidates are determined based on user input instructions, the method further includes: performing conflict detection on the multiple intent candidates, sorting the intents with mutual exclusion relationships based on preset priority rules, and generating an ordered tool call queue.

[0071] In this embodiment, when the server-side intent recognition module outputs the intent parsing results, if it detects that the user input command contains multiple independent intent fragments (such as identifying the fragments "modify" and "generate" through semantic sentence segmentation), it constructs an intent candidate list. Subsequently, the conflict detection module traverses this list and analyzes the logical relationships between each intent candidate. The core basis for conflict detection is the combination relationship between intent type and target entity. The system presets conflict determination rules, the most typical of which is mutual exclusion conflict.

[0072] When both edit intent and generate intent exist for the same target object, it is determined to be a mutual exclusion conflict. The edit intent is placed before the generate intent, and the generate intent is reconfirmed after the edit intent is executed.

[0073] Specifically, editing intents typically refer to modifications, deletions, or insertions of partial content within a document, with a relatively small scope. Generation intents, especially full generation intents, often involve rewriting the entire document or large sections. If both types of intents exist simultaneously for the same target object (such as a project document), and generation precedes editing, the generated content will overwrite the original document structure, causing subsequent editing intents to lose their target entity. Conversely, if editing precedes generation, the edited results will be overwritten by subsequent generation operations, rendering the user's refined modifications futile. Therefore, these two intents are logically mutually exclusive. This embodiment enforces a priority rule, mandating that editing intents have a higher priority than generation intents. When generating an ordered tool call queue, the system places the processing tool corresponding to the editing intent at the front of the queue for priority execution. More importantly, after an editing intent is executed, the system does not immediately and automatically execute the generation intent; instead, it triggers a secondary confirmation mechanism. This is because editing operations may change the document's context, and the user may need to reassess whether to still perform the generation operation based on the new document state, or adjust the generation parameters. This design effectively avoids the risk of data loss caused by automated execution, demonstrating the system's deep understanding and protection of user operational intentions.

[0074] In another scenario, when multiple intent candidates act on different target objects, they are determined to be non-conflicting, allowing the corresponding processing tools to execute in parallel.

[0075] For example, a user command might be "Modify paragraph 2 of the project document and regenerate the summary section." In this case, the target object of the editing intent is the "project document," while the target object of the generation intent is the "summary section." These two are independent and their operations do not affect each other. For such non-conflicting relationships, to improve processing efficiency, the system can distribute these two intents to different processing tools, allowing them to be executed in parallel by different threads or service instances. The execution progress and results are then pushed separately through a streaming event channel. This parallel execution mechanism fully utilizes the system's computing resources, shortens the overall response time of compound instructions, and improves the user experience.

[0076] Furthermore, the generation process of the ordered tool invocation queue specifically includes: the system assigns a priority weight to each intent candidate. The weight calculation is based not only on the intent type (e.g., security interception intents have the highest weight, followed by editing intents, then generation intents, and finally question-and-answer intents have the lowest weight), but also dynamically adjusted in conjunction with the overlap of target objects. For intents with mutual exclusion conflicts, the system arranges them in descending order of priority weight; for non-conflicting intents, the system can maintain their original order or optimize the sorting based on estimated processing time. The final generated ordered tool invocation queue is a structured task list, where each task item contains intent type, target entity, processing tool identifier, and execution parameters. The scheduling engine calls tools sequentially according to the queue order, or triggers parallel calls when a non-conflicting condition is determined, thereby achieving intelligent and orderly processing of complex instructions. Through the above mechanism, this embodiment enables the system to understand and rationally plan complex operation instructions like a human assistant, avoiding logical errors caused by mechanical execution and improving the reliability and intelligence level of multi-tool collaborative interaction.

[0077] Example 7: This embodiment provides a multi-tool collaborative interaction method based on natural language commands, applied to an interactive terminal. Corresponding to the aforementioned server-side embodiment, this method describes the complete interaction process from the user side, including request initiation, streaming data reception and rendering, and exception recovery, thereby jointly constructing an end-to-end collaborative interaction closed loop with the server.

[0078] Specifically, the method includes the following steps: Step S700: Send an interaction request carrying user input instructions to the unified interaction interface of the server, and obtain the interaction session identifier corresponding to the interaction request.

[0079] In this embodiment, the interactive terminal is a hardware device operated by the user, such as a personal computer, smartphone, or tablet. The user inputs natural language commands through an input interface (such as a text box or voice input interface) provided by the interactive terminal. The interactive terminal encapsulates this command into an HTTP request conforming to a unified interactive interface protocol and sends it to the server over the network. Parameters carried in the request include document identifier, version identifier, and the text content entered by the user. Upon receiving the request, the server generates a globally unique interactive session identifier and returns it to the interactive terminal. The interactive terminal stores this identifier in its local session context, serving as a unique index key for subsequently receiving streaming events, sending confirmation commands, or resuming interrupted downloads. This step establishes a session contract between the client and the server, ensuring the traceability of subsequent interactions.

[0080] Step S701: Receive structured events continuously sent by the server through the streaming event channel, determine the event type based on the stage identifier in each structured event, and render the corresponding interactive interface elements according to the event type.

[0081] After sending a request, the interactive terminal establishes a streaming event channel with the server, such as a long connection based on the Server-Sent Events (SSE) protocol. During processing, the server continuously pushes structured events. The interactive terminal listens to this channel and receives event data in real time. Each structured event contains a stage identifier, which the interactive terminal parses to determine the interface rendering strategy. Specifically, if the stage identifier is "Intent Recognition," the interactive terminal can display a loading animation on the interface, indicating to the user that the system is understanding the instruction; if the stage identifier is "Generation," the interactive terminal appends the text fragments carried by the event to the document editing area in real time, achieving a typewriter effect streaming rendering; if the stage identifier is "Completed," the interactive terminal closes the loading state and saves the final result. Through this stage identifier-driven dynamic rendering mechanism, users can perceive the system's processing progress in real time, improving the transparency and experience of the interaction.

[0082] Step S702: When a confirmation control event carrying an operation authorization token and a version status snapshot is received, a confirmation interaction control is displayed. In response to the user's confirmation operation, the operation authorization token and the version status snapshot are submitted to the server.

[0083] This step addresses the confirmation process for high-risk operations (such as full generation). When the server determines that the current operation requires user confirmation, it sends a confirmation control event. The interactive terminal parses this event, extracts the operation authorization token and version status snapshot carried within, and renders a confirmation interaction control on the interface, such as a dialog box containing "Confirm Execution" and "Cancel" buttons, while simultaneously displaying risk warning information about the operation. If the user clicks "Cancel," the interactive terminal sends a cancellation command to the server, terminating the current operation. If the user clicks "Confirm Execution," the interactive terminal encapsulates the operation authorization token and version status snapshot in a confirmation request and sends it back to the designated interface on the server. The server will then perform token verification and version consistency comparison based on these parameters (as in Example 3). This design returns the final decision-making power for high-risk operations to the user and ensures the security of the operation through a token mechanism.

[0084] Step S703: When an interruption is detected in the connection with the server, the last received event identifier is carried in the request to re-establish the connection so as to continue receiving subsequent structured events from the point of interruption.

[0085] In real-world network environments, connections may be interrupted due to signal fluctuations or other reasons. The interactive terminal has connection status monitoring capabilities, and automatically triggers a reconnection mechanism when a streaming event channel is detected to be disconnected. When re-initiating a connection request, the interactive terminal reads the last received event identifier recorded locally. This identifier corresponds to the sequence number of the last structured event successfully received and processed by the interactive terminal. The interactive terminal sends this identifier to the server in the HTTP request header (such as the Last-Event-ID field) or request parameters. Based on this identifier, the server locates the breakpoint in its maintained event buffer queue and re-pushes any events that were not sent after the breakpoint. Through this mechanism, the interactive terminal can seamlessly resume the interaction progress before the interruption without resending the original user input commands or requiring the server to re-execute intent recognition and tool calls, ensuring the integrity of data transmission and the continuity of the user experience.

[0086] In summary, this embodiment describes the specific process of working collaboratively with the server from the perspective of the interactive terminal. Through streaming event-driven dynamic rendering, confirmation interaction for high-risk operations, and a breakpoint resume mechanism based on event identifiers, it achieves high efficiency, security, and robustness in natural language command interaction.

[0087] Example 8: This embodiment provides a multi-tool collaborative interaction system based on natural language commands. This system is used to execute the multi-tool collaborative interaction method of the aforementioned embodiment. Through the collaborative work of various functional modules, it achieves accurate parsing and efficient execution of natural language commands.

[0088] Specifically, the system includes: a request receiving module, an intent determination module, a route scheduling module, a tool execution module, and a streaming interaction module.

[0089] The request receiving module is configured to receive interactive requests carrying user input instructions through a unified interactive interface and generate an interactive session identifier.

[0090] This module serves as the system's entry point, responsible for establishing communication connections with the interactive terminal. At the hardware level, the request receiving module can manifest as a network interface card or API service gateway, listening on a specific port or endpoint to receive interactive requests in protocols such as HTTP and WebSocket. Specifically, upon receiving a request, the request receiving module parses the parameters in the request body and calls the identifier generation unit to generate a globally unique interactive session identifier. This identifier not only identifies the current session but also serves as an index key for subsequent modules to perform context loading and logging. The request receiving module encapsulates the generated interactive session identifier and the original request parameters into an internal message and passes it to the intent determination module.

[0091] The intent determination module is configured to determine the intent type and target entity based on user input instructions. The intent type includes at least editing intent and generating intent, and the target entity is used to locate the target object of the operation.

[0092] This module is the "brain" of the system, responsible for understanding the user's natural language commands. At the hardware level, the intent determination module can consist of a processor running Natural Language Processing (NLP) algorithms and a memory storing relevant model parameters. The intent determination module receives messages from the request receiving module and invokes a pre-built intent recognition model (such as a classification model based on the Transformer architecture) to perform semantic analysis on the user's input commands. Specifically, the intent determination module not only identifies the intent type (such as edit, generate, question answer, etc.) but also extracts the target entity (such as document paragraph identifiers, chapter names, etc.). Furthermore, the intent determination module can integrate the two-stage recognition logic and confidence threshold judgment logic from the aforementioned embodiments, outputting an intent parsing result with a confidence score, and sending this result to the routing and scheduling module.

[0093] The routing and scheduling module is configured to find the processing tool corresponding to the intent type among multiple processing tools, and route the interaction request to the corresponding processing tool so that the processing tool can perform the operation. Among the multiple processing tools, at least two processing tools have different operation granularities.

[0094] This module acts as the system's "traffic hub," responsible for distributing parsed intents to the correct execution units. At the hardware level, the routing and scheduling module can function as a service router or message queue scheduler in a microservice architecture. Internally, the routing and scheduling module maintains a mapping table between intent types and processing tools. Upon receiving the intent parsing result from the intent determination module, the routing and scheduling module queries this mapping table to determine the address or identifier of the target processing tool. For example, if the intent type is editing, the routing and scheduling module will route the request to a paragraph-level editing tool; if the intent type is generating, it will route to a full-text generating tool. For complex instructions containing multiple intents, the routing and scheduling module also performs conflict detection and priority sorting logic, generating an ordered tool call queue and passing the request parameters to the tool execution module in sequence.

[0095] The tool execution module is configured to perform the operations corresponding to the processing tool.

[0096] This module is the system's "execution unit," responsible for specific document processing tasks. At the hardware level, the tool execution module can include multiple service instances or containers running different business logics. For example, it can include a paragraph editor service, a document generator service, etc. When the tool execution module receives a task distributed by the routing and scheduling module, it loads the corresponding processing logic. For editing operations, the tool execution module locates the document position based on the target entity and performs content replacement, insertion, or deletion; for generation operations, it calls the large language model interface to generate new content based on the context. During execution, the tool execution module also triggers security mechanisms such as operation authorization token verification and version consistency comparison as described in the previous embodiments to ensure operational security. Execution results or intermediate state data are sent to the streaming interaction module.

[0097] The streaming interaction module is configured to continuously send structured events to the interactive terminal via a streaming event channel. Each structured event carries an interaction session identifier and a stage identifier.

[0098] This module serves as the system's "feedback channel," responsible for pushing the system's internal processing status to the user in real time. At the hardware level, the streaming interaction module can function as a push server supporting server-sent events or the WebSocket protocol. It maintains a persistent connection with the interactive terminal and subscribes to state change events from the tool execution module and other modules. When internal system state changes occur (e.g., intent recognition complete, tool execution begins, content generation in progress, operation complete), the streaming interaction module encapsulates these states into structured events. Each event carries an interaction session identifier for client association and a stage identifier (e.g., "intent recognition in progress," "execution in progress") for client rendering. Furthermore, the streaming interaction module integrates an event buffer queue to store sent events, supporting breakpoint resumption based on the last received event identifier after a connection interruption.

[0099] Through the coordinated operation of the above modules, this embodiment constructs a complete end-to-end interactive system. The request receiving module ensures standardized request access, the intent determination module achieves accurate understanding of natural language, the routing scheduling module enables flexible scheduling of tools at different granularities, the tool execution module ensures reliable operation execution, and the streaming interaction module enables real-time feedback and breakpoint resumption during the interaction process. The modules interact with each other through well-defined interfaces, ensuring high cohesion and low coupling of the system while facilitating subsequent functional expansion (such as adding intent types or processing tools). It should be understood that the above module division is only a logical functional division. In actual deployment, the functions of multiple modules can be integrated into the same physical device or the same software process, or they can be distributed and deployed on different server nodes, as long as the corresponding functions can be achieved.

[0100] Example 9: This embodiment uses an interactive modification scenario of R&D project documents as an example to specifically illustrate the multi-tool collaborative interaction method of the aforementioned embodiments. In this scenario, the user triggers both document editing and content generation operations simultaneously through natural language commands. The system achieves automated execution of complex commands through intent recognition, conflict resolution, tool scheduling, and streaming feedback.

[0101] Specifically, the method of this embodiment includes the following steps: Step S901: Receive an interaction request carrying user input instructions through a unified interaction interface, and generate an interaction session identifier corresponding to the interaction request.

[0102] In this scenario, the user enters the command in the dialog box of the interactive terminal: "Please shorten paragraph 2 of Chapter 3 in the project document and then regenerate the summary section." The interactive terminal encapsulates this natural language text into an interactive request. The request body contains a document identifier (e.g., doc_123), a current version identifier (e.g., version_2), and a target object type (e.g., tech_doc). After receiving this request, the unified interactive interface on the server side generates a globally unique interactive session identifier, such as msg_doc_123-1700000001-abc. This identifier will serve as the index key for all subsequent streaming events, logging, and context management.

[0103] Step S902: Determine the intent type and target entity based on the user input command. The intent type includes at least editing intent and generating intent.

[0104] The server-side intent recognition module parses user input commands. First, in the first stage, the command is semantically segmented to identify two independent intent fragments: fragment A "shorten paragraph 2 of chapter 3 in the project document" and fragment B "regenerate the summary section".

[0105] Next, in the second stage, domain verification is performed on each intent candidate based on the structural semantic anchor points of the target object type. For fragment A, the system identifies it as an editing intent and requires locating the specific paragraph. The system uses a hierarchical path addressing protocol to generate the identifier of the target entity. Specifically, the target object type is a technical solution document, and its object type identifier is tech_doc; the target chapter is Chapter 3, and the chapter semantic key is chapter_3; the user instruction points to the second paragraph within this chapter, and since the unit number starts from zero, its unit number is para_1. The system combines the above three-level paths to generate the hierarchical path addressing identifier tech_doc.chapter_3.para_1. At the same time, the system queries the actual content offset corresponding to this identifier from the content index mapping table loaded from the persistent storage unit to complete the target entity location. For fragment B, the system identifies it as a generation intent, and the target entity is a summary document, with its object type identifier being summary_doc. Finally, the intent recognition module outputs a list containing two intent candidates, and both of their confidence scores are higher than the first preset threshold (e.g., 0.85), so no clarification query is required.

[0106] Step S903: Perform conflict detection on multiple intent candidates, sort the intents with mutual exclusion relationships based on preset priority rules, and generate an ordered tool call queue.

[0107] The server-side conflict resolution module analyzes the two intent candidates mentioned above. The target object of the edit intent is `tech_doc` (technical solution document), and the target object of the generate intent is `summary_doc` (summary document). Since the two intents act on different target objects, the system determines that they are non-conflicting. Although determined to be non-conflicting, considering that the user command contains the temporal connective "then", the system generates an ordered tool call queue according to semantic order: the edit operation on `tech_doc.chapter_3.para_1` is executed first, followed by the generate operation on `summary_doc`. If the user command does not contain an explicit temporal connective, the system can also determine that they are non-conflicting, allowing the corresponding processing tools to execute in parallel to improve processing efficiency.

[0108] Step S904: Based on the intent type, the interaction request is routed to the corresponding processing tool and the operation is performed.

[0109] First, the editing intent is executed. The routing and scheduling module distributes the task to the paragraph-level editing tool. The tool execution module, based on the hierarchical path addressing identifier `tech_doc.chapter_3.para_1`, reads the content of the corresponding paragraph from the persistent storage unit and calls the language model to execute the "shorten it a bit" instruction. After execution, the tool execution module performs a difference operation on the target object content before and after editing, and incrementally updates the offset of the affected unit in the content index mapping table based on the difference result. For example, if the content of the paragraph is reduced, the system will automatically update the offset of all subsequent paragraphs and write the update result back to the persistent storage unit to ensure the positioning accuracy of subsequent operations.

[0110] Step S905: Continuously send structured events to the interactive terminal via a streaming event channel. Each structured event carries an interactive session identifier and a stage identifier.

[0111] After editing is complete, the system continues with the generation intent. The routing and scheduling module distributes the task to the full-text generation tool. During generation, the server continuously pushes structured events to the interactive terminal via a streaming event channel. Events carry stage identifiers, such as "Executing" or "Generating." Upon receiving an event, the interactive terminal renders interface elements in real time, for example, displaying the generated content word by word in the summary document area using a typewriter effect. If a network interruption occurs during generation, the interactive terminal carries the last received event identifier upon reconnection, and the server resumes the transmission based on the event buffer queue, ensuring the integrity of the generated content.

[0112] Through the above process, this embodiment demonstrates how the system handles complex instructions containing multiple intentions. It achieves precise cross-version positioning through a hierarchical path addressing protocol, ensures the logical rationality of operations through conflict detection and ordered scheduling, and enables real-time feedback during the interaction process through a streaming event channel. Thus, in the professional scenario of modifying R&D project documents, it achieves efficient, accurate, and robust human-computer collaborative interaction.

[0113] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A multi-tool collaborative interaction method based on natural language commands, applied to the server side, characterized in that, The method includes: The system receives interaction requests carrying user input commands through a unified interaction interface and generates an interaction session identifier corresponding to the interaction request. Based on the user input command, the intent type and target entity are determined. The intent type includes at least editing intent and generating intent, and the target entity is used to locate the target object of the operation. Find the processing tool corresponding to the intent type among multiple processing tools, and route the interaction request to the corresponding processing tool so that the processing tool can perform an operation. Among the multiple processing tools, at least two processing tools have different operation granularities, where the operation granularity refers to the range of operations that the processing tool performs on the document. Structured events are continuously sent to the interactive terminal via a streaming event channel. Each structured event carries the interactive session identifier and a stage identifier. The stage identifier is used to indicate the current execution stage of the interaction. The process of determining the intent type and target entity based on the user input command specifically includes: In the first stage, the user input command is semantically segmented to obtain at least one intent candidate and its corresponding target entity; In the second stage, the domain verification of each intent candidate is performed by combining the structural semantic anchor points of the target object type, and the intent parsing result is output. The intent parsing result includes intent type, target entity and confidence score. The structural semantic anchor points correspond to the preset semantic unit boundaries in the target object. The intent type also includes question answering intent, security interception intent and unknown intent. The confidence score is compared with at least two preset thresholds: when the confidence score is not lower than the first preset threshold, the intent parsing result is directly routed to the corresponding processing tool; when the confidence score is lower than the first preset threshold but not lower than the second preset threshold, a clarification query event is sent to the interactive terminal through the streaming event channel, and routing continues after receiving a confirmation instruction; when the confidence score is lower than the second preset threshold, the intent type is downgraded to an unknown intent and routed to the fallback processing flow. Wherein, the first preset threshold is greater than the second preset threshold.

2. The method according to claim 1, characterized in that, When multiple intent candidates are determined based on the user input command, the method further includes: Conflict detection is performed on the multiple intent candidates, and the intents with mutual exclusion relationships are sorted according to the preset priority rules to generate an ordered tool call queue; When both the editing intent and the generating intent exist for the same target object, it is determined to be a mutual exclusion conflict. The editing intent is then placed before the generating intent, and the generating intent is reconfirmed after the editing intent is executed. When the multiple intent candidates act on different target objects, they are determined to be non-conflicting, allowing the corresponding processing tools to execute in parallel.

3. The method according to claim 1, characterized in that, When the routing is to the processing tool corresponding to the generation intent and the operation is a full generation operation, the method further includes: Generate an operation authorization token, bind the operation authorization token to the version status snapshot, store it in the cache and set the validity period. The version status snapshot includes a version identifier and a target object content summary calculated based on a preset hash algorithm. A confirmation control event carrying the operation authorization token and the version status snapshot is sent to the interactive terminal through the streaming event channel; Upon receiving the confirmation instruction, the following verifications are performed sequentially: querying the cache to verify that the operation authorization token exists and is in an unconsumed state; comparing the target object content digest in the version state snapshot with the target object content digest of the current version in the persistent storage unit; and updating the state of the operation authorization token from unconsumed to consumed through a comparison and exchange atomic operation. After all verifications pass, perform the full data generation operation. If the operation authorization token does not exist, has expired, has been consumed, or the content digest of the target object does not match, an error event carrying the corresponding error code is sent to the interactive terminal through the streaming event channel, and the operation is terminated.

4. The method according to claim 1, characterized in that, The streaming event channel supports breakpoint resumption, and the method further includes: An event buffer queue is maintained for each of the interaction session identifiers, and the event buffer queue is used to cache a preset number of sent structured events; When a connection request is received from the interactive terminal after a connection interruption, the last received event identifier carried in the connection request is detected. The last received event identifier corresponds to the structured event that the interactive terminal successfully received for the last time. Based on the last received event identifier, the corresponding position is located in the event buffer queue, and the structured events that have not yet been received by the interactive terminal after the corresponding position are pushed back sequentially.

5. The method according to claim 1, characterized in that, Before determining the intent type, the method further includes: Based on the target object identifier carried in the interaction request, context data associated with the target object is loaded from the persistent storage unit. The context data includes at least the content index mapping table and historical operation records of the target object. The target object identifier includes at least the object type identifier, the version identifier, and the content type identifier.

6. The method according to claim 5, characterized in that, The content index mapping table adopts a hierarchical path addressing protocol, and the method further includes: A hierarchical path addressing identifier is generated for the target unit in the target object. The hierarchical path addressing identifier is composed of an object type identifier, a chapter semantic key and a unit number combined in a hierarchical path format. The chapter semantic key corresponds to the semantic identifier of a preset chapter in the target object, and the unit number is a natural number starting from zero within the chapter. Maintain the content index mapping table, using the hierarchical path addressing identifier as the key and the target unit content and its offset in the target object as the value; In response to the completion of the processing tool, a difference operation is performed on the target object content before and after editing. Based on the difference result, the offset of the affected unit in the content index mapping table is incrementally updated, and the update result is written back to the persistent storage unit.

7. A multi-tool collaborative interaction method based on natural language commands, applied to an interactive terminal, characterized in that, The method includes: Send an interaction request carrying user input instructions to the unified interaction interface of the server, and obtain the interaction session identifier corresponding to the interaction request; The system receives structured events continuously sent by the server through a streaming event channel, determines the event type based on the stage identifier in each structured event, and renders the corresponding interactive interface elements according to the event type. When a confirmation control event carrying an operation authorization token and a version status snapshot is received, a confirmation interaction control is displayed, and in response to the user's confirmation operation, the operation authorization token and the version status snapshot are submitted to the server. When a connection interruption with the server is detected, the last received event identifier is carried in the request to re-establish the connection so as to continue receiving subsequent structured events from the point of interruption. The user input instructions are used to determine the intent type and target entity, specifically including: In the first stage, the user input command is semantically segmented to obtain at least one intent candidate and its corresponding target entity; In the second stage, the domain verification of each intent candidate is performed by combining the structural semantic anchor points of the target object type, and the intent parsing result is output. The intent parsing result includes intent type, target entity and confidence score. The structural semantic anchor points correspond to the preset semantic unit boundaries in the target object. The intent type also includes question answering intent, security interception intent and unknown intent. The confidence score is compared with at least two preset thresholds: when the confidence score is not lower than the first preset threshold, the intent parsing result is directly routed to the corresponding processing tool; when the confidence score is lower than the first preset threshold but not lower than the second preset threshold, a clarification query event is sent to the interactive terminal through the streaming event channel, and routing continues after receiving a confirmation instruction; when the confidence score is lower than the second preset threshold, the intent type is downgraded to an unknown intent and routed to the fallback processing flow. Wherein, the first preset threshold is greater than the second preset threshold.

8. A multi-tool collaborative interaction system based on natural language commands, characterized in that, The system includes: The request receiving module is configured to receive interactive requests carrying user input instructions through a unified interactive interface and generate an interactive session identifier. The intent determination module is configured to determine the intent type and target entity based on the user input command. The intent type includes at least editing intent and generating intent, and the target entity is used to locate the target object of the operation. The routing and scheduling module is configured to find a processing tool corresponding to the intent type among multiple processing tools, and route the interaction request to the corresponding processing tool so that the processing tool can perform an operation. Among the multiple processing tools, at least two processing tools have different operation granularities, and the operation granularity refers to the range of operations that the processing tool performs on the document. The streaming interaction module is configured to continuously send structured events to the interactive terminal via a streaming event channel. Each structured event carries the interaction session identifier and the stage identifier, and the stage identifier is used to indicate the current execution stage of the interaction. The process of determining the intent type and target entity based on the user input command specifically includes: In the first stage, the user input command is semantically segmented to obtain at least one intent candidate and its corresponding target entity; In the second stage, the domain verification of each intent candidate is performed by combining the structural semantic anchor points of the target object type, and the intent parsing result is output. The intent parsing result includes intent type, target entity and confidence score. The structural semantic anchor points correspond to the preset semantic unit boundaries in the target object. The intent type also includes question answering intent, security interception intent and unknown intent. The confidence score is compared with at least two preset thresholds: when the confidence score is not lower than the first preset threshold, the intent parsing result is directly routed to the corresponding processing tool; when the confidence score is lower than the first preset threshold but not lower than the second preset threshold, a clarification query event is sent to the interactive terminal through the streaming event channel, and routing continues after receiving a confirmation instruction; when the confidence score is lower than the second preset threshold, the intent type is downgraded to an unknown intent and routed to the fallback processing flow. Wherein, the first preset threshold is greater than the second preset threshold.

9. A computer-readable storage medium, characterized in that, It stores a computer program thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

Images