A method and system for cooperative instruction parsing and multi-actuator task processing

Abstract

The application discloses a kind of collaborative instruction analysis and multi-actuator task processing method and system, the method includes: configuration Webhook and solidification server configuration, skill resource root directory is physically separated from business warehouse;With original byte stream reception request and sign, it is parsed into structured event by post;Extract text and match valid instruction, capture provider keyword and instruction text;Build basic context;Carry out intention recognition, route to corresponding branch and read skill description file, assemble complete prompt;Distribute independent working directory and clone code;According to the unique actuator execution task of provider keyword from mapping table;With single comment iterative update mode, present progress;Result is written back to topic or merged request.The application realizes multiple entry collaborative closed loop, skill and business decoupling, multi-actuator unified scheduling and progress visible execution.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and specifically to a method and system for cooperative instruction parsing and multi-executor task processing. Background Technology

[0002] Code hosting platforms (such as GitLab and GitHub) are widely used for version control, merge requests, and issue tracking. Webhooks (event notification mechanisms where the platform proactively sends HTTP requests to a pre-configured server address when issues, merge requests, comments, etc., occur) serve as entry points for triggering automated processes, enabling external services to detect and respond to collaborative events on the code hosting platform in real time. During team collaboration, developers want to trigger automated analysis, code reviews, or auxiliary processing tasks using natural language in issues, merge requests, or comments, and write the processing and results back to the same collaborative context.

[0003] The existing technology suffers from the following problems: First, multiple entry points and fragmented collaboration contexts. Multiple entry points such as topics, merge requests, and comments operate independently. After a task is triggered, it's difficult to inherit existing discussion threads and historical dialogues, requiring collaborators to cross pages to access information, reducing collaboration efficiency. Second, the execution engine and prompting strategy are too rigidly bound. Existing automated tasks typically hardcode prompts in scripts or release them with the business repository, making it difficult to switch specialized strategies according to different intentions (such as code review, task assignment, general Q&A) or flexibly replace the backend AI engine. Third, large merge requests are inefficient. When the number of files involved in a merge request is large, sending them all at once to the AI ​​model can easily time out or exceed the context window limit. Furthermore, the lack of a mechanism for reviewing by directory leads to insufficient coverage of large change reviews. Fourth, there's a lack of rule governance methods decoupled from business repositories. If review rules, security checklists, and output format templates are stored in user business repositories (such as the .github / directory), it's difficult for the platform to uniformly implement governance strategies. Rule updates require modification of each repository individually, hindering platform-level standardized management. Fifth, Webhook security is insufficient. Inadequate verification poses a risk of request forgery; lack of progress feedback during execution means collaborators cannot perceive the task status, resulting in a poor collaboration experience. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides a method and system for collaborative instruction parsing and multi-executor task processing.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A method for collaborative instruction parsing and multi-executor task processing includes the following steps: S1. Configure a Webhook on the code hosting platform and persist the configuration information on the server side. The configuration information includes the service address, subscription events, Webhook key, access token, platform root address, local working directory, and skill resource root directory; the skill resource root directory is physically separated from the user's cloned business repository; S2. Receive the Webhook request body as a raw byte stream and convert it into a raw request body string. Obtain the authentication string from the pre-defined request header. Verify the authentication string and the raw request body string using the corresponding verification method according to the format of the authentication string. If the verification is successful, parse the raw request body string into a structured event. If the verification fails, refuse service and terminate. S3. Extract the main text from the structured event, match valid instructions within the main text, capture the provider keywords and instruction text in the valid instructions, and terminate if no valid instructions are matched. S4. Assemble the underlying context based on the event types in the structured event; S5. Based on the basic context, perform intent recognition on the instruction text, and divide it into corresponding routing branches according to the recognition results. Each routing branch corresponds to an intent category and a skill subdirectory under the skill resource root directory. Each skill subdirectory contains the skill description file corresponding to the routing branch. Read the full text of the skill description file of the routing branch, and combine the basic context, instruction text, and skill description file into a complete prompt. S6. Assign an independent working directory for the structured event in the local working directory, perform a shallow clone of the working branch in the structured event using the business repository address with the embedded access token, configure the local user information, and obtain the working area path; if the business repository has no working branch, clone the default branch of the repository and then try to check out the working branch. S7. Establish a fixed mapping table between provider identifiers and executor instances; search for a unique corresponding executor instance from the mapping table based on the provider keyword in the valid instruction, and pass the complete prompt, workspace path and progress callback interface to the executor to execute the task; if not found, fall back to the default executor or return an error. S8. The executor sends back the progress through the progress callback interface, and the server presents the execution progress in a way that updates the progress of each comment iteratively. S9. Write the execution results back to the issue or merge request that triggered the task.

[0006] Furthermore, in S2, the verification methods include: Mode A (Plaintext Token): If the authentication string is a plaintext token, the authentication string is compared with the Webhook key for complete equality. If they are equal, the signature verification is successful. Mode B (Message Authentication Code Digest): If the authentication string is indicated by a predefined prefix as a digest type, the prefix is ​​removed to obtain the peer's hexadecimal digest. Using the Webhook key as the key, the original request body string is subjected to a hash-based message authentication code operation according to the predefined character encoding to obtain the local hexadecimal digest. If the two digests have the same length, a constant time comparison is used. If they are equal, the signature verification passes; otherwise, the signature verification fails.

[0007] Furthermore, in S3, the first valid instruction is matched in the body text using a formal pattern. The formal pattern is used to capture the provider keyword and instruction body text in the valid instruction. The provider keyword is limited to an enumerated set. The instruction body text is matched non-greedy, and the matching range ends at the next valid instruction in the body text or the end of the body text. Allows the insertion of an optional parameter segment between the provider keyword and the instruction body to specify the model identifier; if the provider keyword is a specific alias, it is mapped to a configurable default provider identifier.

[0008] Furthermore, in S3, the main text is extracted from the structured event. Specifically, the text is determined based on the event type field in the structured event. If the event type is an issue or a merge request, the text is extracted from the description. If it is a merge request, the source branch or the default branch is also extracted from the structured event as the working branch. If the event type is a comment, the text is extracted from the comment body, and the issue or merge request to which the comment is attached is obtained from the structured event.

[0009] Furthermore, in S4, the basic context includes at least the event number, title, branch information, and change scale; if the event type is a comment, the basic context also includes the discussion list and previous replies within the thread.

[0010] Furthermore, in S5, the routing branches include review branches, pending branches, and general assistance branches. For review branches, a reference set is maintained in the corresponding skill subdirectory: the list file in the skill subdirectory lists the filenames of the reference fragment files in line order, and supports skipping comment lines and missing files; the contents of the corresponding reference fragment files are read in the order they are listed and merged into a reference set, which belongs to the review skill system corresponding to the current route.

[0011] Furthermore, in S5, for review branches, the corresponding review template is read from the corresponding skill subdirectory. The placeholder items in the template are replaced with a summary of the description required for the effective instruction, the baseline and top references for the merged comparison, the requirement or plan references, and the batch scope description to obtain a filled review template. The basic context, instruction text, corresponding skill description document, filled review template, and reference reference set are then assembled in sequence into a complete prompt.

[0012] Furthermore, in S8, the execution progress is presented through iterative updates of individual comments, specifically including: When a task begins, a comment is created on the corresponding topic or merge request, and its comment identifier is recorded. If the discussion thread identifier is already included in the basic context, a progress comment is created in the form of a reply under that thread. If the reply interface of the code hosting platform is unavailable, it falls back to a top-level ordinary comment. During task execution, the server writes the received short texts with the agreed time zone timestamp into the memory queue, merges the short texts with duplicate content, and only retains the most recent short texts to be appended to the body of the progress comment. Each update targets the comment icon and overwrites the body of the update progress comment. If the update fails, it is downgraded to creating a new comment to carry the current progress. When the task is completed, write the completion status (success or failure) and the last update time in the body of the progress comment.

[0013] Furthermore, when the number of change files between the source and target branches in a merge request exceeds a threshold, a batch review is performed: Pull all change file paths between the source branch and the target branch, exclude conventionally generated directories, filter non-code files, dynamically calculate the batch number based on the number of change files and the configuration, aggregate into subtasks based on the directory where the change files are located, and merge with adjacent subtasks if the number of files contained in a subtask is less than the configured minimum value, and further split if it exceeds the configured maximum value. For each batch of subtasks, S7 is re-executed, and the prompts in the context of the corresponding executor are replaced with enhanced prompts that include the path range of the batch, the batch number, and the difference comparison reference. A hard reset is performed on the workspace and untracked files are cleaned up between each batch of subtasks.

[0014] A system for performing the above method includes the following modules: Access and Configuration Module: Used to configure Webhooks on the code hosting platform and persist configuration information on the server side. The configuration information includes service address, subscription events, Webhook key, access token, platform root address, local working directory, and skill resource root directory; the skill resource root directory is physically separated from the user's cloned business repository; The receiving and signature verification module is used to receive the Webhook request body as a raw byte stream and convert it into a raw request body string. It obtains the authentication string from the preset request header and verifies the authentication string and the raw request body string according to the format of the authentication string using the corresponding signature verification method. If the signature verification is successful, the raw request body string is parsed into a structured event. If the signature verification fails, the service is rejected and terminated. Instruction extraction module: used to extract the main text from structured events, match valid instructions within the main text, capture provider keywords and instruction text in valid instructions, and terminate if no valid instruction is matched; Context building module: Used to assemble the underlying context based on the event types in a structured event; The prompt building module is used to perform intent recognition on the instruction text based on the basic context, and divide it into corresponding routing branches according to the recognition results. Each routing branch corresponds to an intent category and a skill subdirectory under the skill resource root directory. Each skill subdirectory contains the skill description file corresponding to the routing branch. The module reads the full text of the skill description file of the routing branch and concatenates the basic context, instruction text, and skill description file into a complete prompt. Workspace Management Module: Used to allocate an independent working directory for structured events in the local working directory, perform a shallow clone of the working branch in the structured event using the business repository address with an embedded access token, configure local user information, and obtain the workspace path; if the business repository has no working branch, clone the default branch of the repository and then try to check out the working branch. Multi-executor scheduling module: used to establish a fixed mapping table between provider identifiers and executor instances; based on the provider keyword in the valid instruction, it searches the mapping table for a unique corresponding executor instance, passes the complete prompt, workspace path and progress callback interface to the executor to execute the task; if no instance is found, it falls back to the default executor or returns an error. Progress feedback module: Used to present the execution progress in the form of iterative updates of a single comment when the executor sends back progress through the progress callback interface; Result write-back module: Used to write back the execution results to the issue or merge request that triggered the task.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By uniformly configuring Webhooks at multiple entry points such as topics, merge requests, and comments on the code hosting platform, this invention can extract instructions from different event types and inherit discussion threads and previous replies, realizing a complete closed loop of task triggering, execution, and result writing. Collaborators do not need to check across pages, significantly improving team collaboration efficiency.

[0016] 2. Based on intent recognition, instructions are divided into different routing branches. Each routing branch corresponds to an independent skill subdirectory and skill description file. The routing branch corresponding to the review category can also load reference collections and review templates, so as to realize differentiated processing strategies for different task types, avoid the global sharing of a single role setting, and ensure the standardization of review rules and output formats.

[0017] 3. Skill description documents, reference collections, and review templates are all stored in the skill resource root directory on the server, physically isolated from the business repository cloned by the user. The platform can uniformly manage review rules and output formats in a versioned manner, and can promote standardized governance without intruding on the business repository. Rules can evolve independently and be released in a phased manner.

[0018] 4. When the system starts, a fixed mapping table between provider identifiers and executor instances is established, and the corresponding executor is uniquely scheduled according to the provider keyword in the valid instruction; the alias mechanism allows users to switch the underlying engine on the deployment side while keeping the trigger syntax unchanged, so as to achieve unified orchestration and replaceability of multiple backends.

[0019] 5. The original request body string is preserved for signature verification to avoid signature inconsistencies caused by JSON reserialization; it also supports both plaintext token and message authentication code digest modes, is compatible with different code hosting platforms, and constant time comparison effectively prevents time-series attacks and improves system security.

[0020] 6. When the number of changed files exceeds the threshold, the changes are dynamically batched according to the directory module. Each batch generates an enhanced prompt containing the path range and batch number independently. The workspace is hard reset and untracked files are cleaned up between batches. This avoids model timeouts and context bloat, and also prevents code modifications between batches from polluting each other, thus ensuring the quality of the review.

[0021] 7. Present the execution progress by updating the same comment over time, prioritize creating replies in the discussion thread that triggered the instruction, merge duplicate short texts in the memory queue, filter redundant prompts, avoid multiple comments flooding the screen, and make the execution process of asynchronous long tasks transparent and visible to collaborators. Attached Figure Description

[0022] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. 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.

[0024] like Figure 1 As shown, the present invention provides a method for cooperating instruction parsing and multi-executor task processing, comprising the following steps: S1. Configuration and Access: Configure the Webhook on the code hosting platform and persist the configuration information on the server side. The configuration information includes the service address, subscription events, Webhook key, access token, platform root address, local working directory, and skill resource root directory; the skill resource root directory is physically separated from the user's cloned business repository; S2. Request Receive and Source Verification: Receive the Webhook request body as a raw byte stream and convert it into a raw request body string. Obtain the authentication string from the pre-defined request header. Verify the authentication string and the raw request body string using the corresponding signature verification method according to the format of the authentication string. If the signature verification is successful, parse the raw request body string into a structured event. If the signature verification fails, refuse service and terminate. S3. Extract valid instructions: Extract the main text from the structured event, match valid instructions within the main text, capture the provider keywords and instruction text in the valid instructions, and terminate if no valid instructions are matched; S4. Constructing the Context: Assemble the base context based on the event types in the structured events; S5. Prompt Construction: Based on the basic context, the intent of the instruction text is identified, and the corresponding routing branch is divided according to the identification result. Each routing branch corresponds to an intent category and a skill subdirectory under the skill resource root directory. Each skill subdirectory contains the skill description file (Skill) corresponding to the routing branch. The full text of the skill description file of the routing branch is read, and the basic context, instruction text, and skill description file are concatenated into a complete prompt. S6. Workspace Management: Assign an independent work directory for structured events under the local work directory, perform a shallow clone of the work branch in the structured event using the business repository address with an embedded access token, configure local user information, and obtain the workspace path; if the business repository has no work branch, clone the default branch of the repository and then try to check out the work branch. S7. Multi-executor execution: Establish a fixed mapping table between provider identifiers and executor instances; search for a unique corresponding executor instance from the mapping table based on the provider keyword in the valid instruction, and pass the complete prompt, workspace path and progress callback interface to the executor to execute the task; if not found, fall back to the default executor or return an error. S8. Progress Feedback: The executor sends back the progress through the progress callback interface, and the server presents the execution progress in the form of iterative updates for each comment. S9. Result Writeback: Writes the execution result back to the issue or merge request that triggered the task.

[0025] This invention employs the following processing chain: configuration and access, receiving requests and source verification, extracting instructions from events, building context, prompt construction, preparing the workspace, multi-executor scheduling and execution, progress feedback, and result writing back. The prompt construction uses a Skill-driven approach: intent routing, selecting a Skill, reviewing the class and reassembling the reference set, assembling with context and instructions, and multi-executor execution, forming a fixed chain.

[0026] In S1 of this invention, a Webhook is configured on the code hosting platform, and the address of this service and the events to be subscribed to (including at least topics, merge requests, and comments) are filled in.

[0027] Meanwhile, server-side configuration information, including access tokens, webhook keys, platform root addresses, listening ports, local working directories, and skill resource root directories, is pre-written into the deployment environment. This configuration is read once upon application startup and permanently set to read-only, preventing dynamic modification during runtime. Specifically, the access token and platform root address are used to create HTTP clients for accessing the code hosting platform; the webhook key is dedicated to request verification; and the skill resource root directory stores skill description files and reference collections for this service, physically isolated from the subsequently cloned user business repository. This configuration management method applies uniformly to physical machines, containers, and container orchestration environments.

[0028] The embodiments of this invention are illustrated using the GitLab platform as an example: subscription events include Issue, Mergerequest, Comments (Note), etc., and the agreed request header is X-Gitlab-Token. Other platforms (such as GitHub's issues / pull_request / issue_comment and X-Hub-Signature-256 request header) are equivalent alternative embodiments.

[0029] In S2 of this invention, after the Webhook route receives an HTTP request, it first reads the request body in raw byte stream form and converts it into a raw request body string. During the signature verification process, it obtains the authentication string from the preset agreed request header, and then selects the corresponding signature verification method according to the format of the authentication string (based on message authentication code digest, with plaintext tokens as a compatibility): Mode A (Plaintext Token): If the authentication string is a plaintext token, it is directly compared with the configured Webhook key for complete equality. If they are equal, the signature verification is successful. Mode B (Message Authentication Code Digest): If the authentication string uses a predefined prefix (e.g., sha256=) to indicate a digest type, the prefix is ​​removed to obtain the peer's hexadecimal digest. Using the configured Webhook key as the key, the original request body string is processed using a hash-based message authentication code operation according to a predefined character encoding (e.g., UTF-8) to obtain the local hexadecimal digest. If the two digests are of the same length, a constant-time comparison is used (to avoid timing bypass); if they are equal, the signature verification passes; otherwise, the signature verification fails.

[0030] If signature verification fails, an unauthorized response is returned and business processing is terminated; if signature verification passes, the original request body string is parsed into a structured event for use in subsequent steps.

[0031] In S3 of this invention, the text source is determined according to the event type field in the structured event: if the event type is an issue or a merge request, the main text is extracted from the description; if it is a merge request, the source branch or the default branch is also extracted from the structured event as the working branch; if the event type is a comment, the text is extracted from the comment text, and the issue or merge request to which the comment is attached is obtained from the structured event.

[0032] Among them, the default branch is defined by the platform field default_branch, which is commonly main / master; in MapReduce scenarios, source_branch is preferred.

[0033] Within the extracted text, valid instructions are matched using a formal pattern. The formal pattern captures provider keywords and instruction text, with provider keywords limited to an enumerated set. During matching, the instruction text is used in a non-greedy manner, with the matching range ending at the next valid instruction within the text or the end of the text. If an optional parameter segment is inserted between the provider keyword and the instruction text, it is parsed as a model identifier. If the provider keyword is a specific alias, it is mapped to a configurable default provider identifier, ensuring that the user-visible trigger syntax remains unchanged while the deployment side switches the underlying engine. Processing terminates if no valid instruction is matched; if a match is successful, the provider keyword, instruction text, and corresponding model are obtained, and in merge request scenarios, a working branch is also obtained.

[0034] In one embodiment, valid instructions begin with the @ symbol and are structured in three segments: @[Provider Keyword][Optional Model Parameter Segment][Blank][Instruction Body], such as: @fe-cr Please review the security risks of this change; @claude[model=claude-sonnet-4-20250514] Explain the login process of AuthService.

[0035] Using regular expressions for capture: / @(claude|codex|fe-cr)(?:\[model=([^\]]+)\])?\s+([\s\S] ?)(?=@\w+|$) / i. Capture group 1 is the provider's keyword, capture group 2 is the optional model=model identifier, and capture group 3 is the instruction body (non-greedy, ending at the next @ word or the end of the text).

[0036] Non-greedy matching combined with regular expression lookahead (?=@\w+|$) can split the same text into multiple candidate instructions. This implementation executes the first one; an extended approach can iterate through the entire text using matchAll / exec to obtain an instruction queue, and schedule them sequentially or concurrently.

[0037] The provider keyword is limited to the enumeration set {claude, codex, fe-cr}, which can be configured and extended. Optional parameter segments are formatted as [model=claude-sonnet-4-20250514]. Specific aliases, such as fe-cr, map to the value of the configuration item AI_DEFAULT_PROVIDER. Users always write @fe-cr ... (the syntax remains unchanged). Changing the underlying layer only requires modifying the deployment configuration; there's no need to change user commenting habits. If the deployment side wants to use other start characters (such as / ), equivalent replacement can be achieved by modifying the regular expression.

[0038] In step S4 of this invention, a basic context is assembled based on the event type. This context includes at least the event number, title, branch information (including the source branch and the target branch), and change scale. The change scale is the number of changed files (path entries) between the source and target branches of the merge request. It may include a summary of the number of added, deleted, and modified files, used to determine the threshold for triggering a review. If the event type is a comment, the discussion list for the current topic or merge request is retrieved via the code hosting platform interface. The identifier of the thread containing the comment and the preceding replies within that thread are then included in the basic context. The basic context is output in structured data format for use in subsequent prompt construction.

[0039] In S5 of this invention, all skill resources are read from the skill resource root directory and do not come from the cloned user repository.

[0040] First, intent is identified based on the instruction text and basic context, and the instruction text is then divided into corresponding routing branches (e.g., review routing branch, pending routing branch, general assistance routing branch). Each routing branch corresponds to a skill subdirectory under the skill resource root directory, and each subdirectory contains the skill description file corresponding to that branch, realizing differentiated strategies under different intents and avoiding the global sharing of a single role setting.

[0041] The specific operation of intent recognition involves keyword / rule routing of the instruction text, which can be expanded into a classification model. For example, instructions containing keywords like "review" or "examination" are assigned to the "review" routing branch, those containing keywords like "to-do" or "assignment" are assigned to the "to-do" routing branch, and the rest are assigned to the general assistance routing branch. Each routing branch corresponds to a skill subdirectory under the skill resource root directory, and each skill subdirectory contains the skill description file corresponding to that routing branch.

[0042] Skill description documents are recommended to be named SKILL.md and should use the YAML front matter + body guidelines format.

[0043] After determining the routing branch, read the full text of the skill description file for that branch, which will serve as the guiding principle for subsequent prompts. For review branches, read the corresponding review template from the skill subdirectory of that routing branch, and replace the placeholders ({BASE_SHA}, {HEAD_SHA}, etc.) in the template with the summary of the description required for the valid instruction, the baseline and top references for merging comparisons, the requirement or plan references, and the batch scope description to obtain the filled review template. The description summary is a brief description of the user instruction or task; the baseline reference is the comparison starting commit, such as the target branch tip or the last reviewed tip; the top reference is the current MR source branch tip; the requirement or plan reference is such as an Issue / plan link or summary; and the batch scope description is such as "Batch 2 / 5, path: src / services / ". 。

[0044] Meanwhile, for review branches, a reference set is maintained in the skill subdirectory of that route branch: the filenames of reference fragment files are listed line by line in the manifest file in the skill subdirectory, supporting skipping of comment lines and missing files; the contents of the corresponding reference fragment files are read sequentially in the listed order and merged into a reference set, which is used to carry independently evolving content such as safety check items, review items, and output formats. Non-review branches do not load the reference set, but only load the corresponding skill descriptions to reduce irrelevant constraints.

[0045] Finally, the basic context, instruction text, skill description document, pre-filled review template (if applicable), and reference set (if enabled) are sequentially assembled into a complete prompt for subsequent executor calls.

[0046] In step S6 of the present invention, an independent working directory is allocated for the current structured event under the local working directory, so as to ensure no interference between different events. A shallow clone is performed on the working branch obtained in S3 by using a service repository address embedded with an access token. If there is no working branch in the service repository, the default branch of the repository is cloned and then an attempt is made to check out the working branch. After cloning is completed, local user information is configured, for example, user.name = "Big Frontend CR Assistant", user.email = "gitlab-ai-cr@example.com", and a working directory path is obtained for use in subsequent steps.

[0047] In step S7 of the present invention, when the system starts, a fixed mapping table of provider identifiers and executor instances is established. Each executor exposes a unified asynchronous calling interface to the outside, and input parameters include a task instruction, a working directory path, an execution context (including complete prompts, branches, event information, optional models, etc.), a progress callback interface and an error callback interface.

[0048] The uniquely corresponding executor instance is found from the mapping table according to the provider keyword obtained in S3, and the complete prompt, the working directory path and the progress callback interface are passed into the executor to execute the task, the unified execution method thereof is called, and the process enters a subsequent writing-back or error handling flow according to the returned result. If the executor instance cannot be found, the process falls back to the default executor or returns an error.

[0049] In step S8 of the present invention, the execution progress is presented in a manner of iterative updating through a single comment, which specifically includes: When a task starts, a comment is created on the corresponding issue or merge request, and the comment identifier thereof is recorded; if a discussion thread identifier (discussionId) is already included in the basic context, a discussion reply interface (such as Issue / MRDiscussion Notes) is called first, and a progress comment is preferentially created in the form of a reply under this thread, so that the progress and the triggering comment are in the same thread; if the reply interface of the code hosting platform (such as the open interface provided by the gitlab platform) is unavailable, the process falls back to a top-level ordinary comment, that is, the ordinary comment creation interface of the issue or MR is called instead to send the top-level note, which still carries the progress / result, and only does not force binding to the original thread.

[0050] During the execution of the task, the executor calls the progress callback interface for multiple times and passes a short copy each time, the server writes the received short copy with a timestamp in the agreed time zone (Asia / Shanghai, [17:01:05], ) into a memory queue, and appends the last update time (Beijing time) to the end of the copy, short copies with repeated content are merged, and short copies with no information increment can be filtered, only the last several (such as the last 5) short copies are spliced into the text of the progress comment to control message flooding.

[0051] Each update targets a comment and overwrites the update progress comment text via the code hosting platform's interface. If the update fails, it is downgraded to creating a new comment to represent the current progress.

[0052] The above describes how to create a new progress comment for a task and record its commentId; during the process, the comment text is PUT / updated. If the update fails, a new comment is created with the current progress text (downgrade) to avoid losing progress. When the task ends, the progress comment text is written with the completion status (update successful or failed) and the last update time.

[0053] In S9 of this invention, the execution result is written back to the issue or merge request that triggered the task through the interface of the code hosting platform, and presented in the form of comments or description updates, so that collaborators can view the processing result on the same collaboration page.

[0054] When the number of change files between the source and target branches in a merge request exceeds a threshold (e.g., 15), a batch review will be performed: Pull all change file paths between the source branch and the target branch, excluding conventionally generated directories (such as dist / , build / , node_modules / ), filtering non-code files (such as images, binary files), dynamically calculating the batch number based on the number of change files and the configuration (batch number = number of change files / number of files per batch (e.g., 8) and rounding up), aggregating the change files into subtasks based on their directories. If a subtask contains fewer files than the configured minimum, it is merged with adjacent subtasks; if it exceeds the configured maximum, it is further split. For each batch of subtasks, S7 is re-executed, and the prompts in the context of the corresponding executor are replaced with enhanced prompts that include the path range of the batch, the batch number, and the difference comparison reference. Between each batch of subtasks, a hard reset of the working directory is performed (e.g., `git reset --hard HEAD`) and untracked files are cleaned up (e.g., `git clean -fd`) to prevent code modifications between batches from polluting each other. After all batches are completed, the review results of each batch are summarized, merged into a final report, and written back to the merge request.

[0055] After execution, the working directory can be compared with the baseline to count the number of modified files, which can be used for subsequent documentation, pushes, branch creation, etc. The baseline is the HEAD (clean snapshot of the working directory) of the working branch that was checked out at the start of the task, usually the MR source branch tip, not the target branch. The number of modified files is obtained by summarizing the additions, deletions, and modifications relative to HEAD using `git status`. When there are local modifications and `changes.length > 0`, the following can be executed: create a new branch `crassistant-{timestamp}-{random}` based on the working branch; commit and push; create an MR from this branch to the original working branch (baseBranch); and attach a link to the MR in the comments. If it fails, the comment will indicate "Local changes already exist, but MR creation failed," without blocking the result write-back.

[0056] A Webhook-based collaborative instruction parsing and multi-executor task processing system, used to implement the above method, includes the following modules: Access and Configuration Module: Used to configure Webhooks on the code hosting platform and persist configuration information on the server side. The configuration information includes service address, subscription events, Webhook key, access token, platform root address, local working directory, and skill resource root directory; the skill resource root directory is physically separated from the user's cloned business repository; The receiving and signature verification module is used to receive the Webhook request body as a raw byte stream and convert it into a raw request body string. It obtains the authentication string from the preset request header and verifies the authentication string and the raw request body string according to the format of the authentication string using the corresponding signature verification method. If the signature verification is successful, the raw request body string is parsed into a structured event. If the signature verification fails, the service is rejected and terminated. Instruction extraction module: used to extract the main text from structured events, match valid instructions within the main text, capture provider keywords and instruction text, and terminate if no valid instruction is matched; Context building module: Used to assemble the underlying context based on the event types in a structured event; The prompt building module is used to perform intent recognition on the instruction text based on the basic context, and divide it into corresponding routing branches according to the recognition results. Each routing branch corresponds to an intent category and a skill subdirectory under the skill resource root directory. Each skill subdirectory contains the skill description file corresponding to the routing branch. The module reads the full text of the skill description file of the routing branch and concatenates the basic context, instruction text, and skill description file into a complete prompt. Workspace Management Module: Used to allocate an independent working directory for structured events in the local working directory, perform a shallow clone of the working branch in the structured event using the business repository address with an embedded access token, configure local user information, and obtain the workspace path; if the business repository has no working branch, clone the default branch of the repository and then try to check out the working branch. Multi-executor scheduling module: used to establish a fixed mapping table between provider identifiers and executor instances; search for a unique corresponding executor instance from the mapping table based on the provider keyword, and pass the complete prompt, workspace path and progress callback interface to the executor to execute the task; if not found, fall back to the default executor or return an error. Progress feedback module: Used to present the execution progress in the form of iterative updates of a single comment when the executor sends back progress through the progress callback interface; Result write-back module: Used to write back the execution results to the issue or merge request that triggered the task.

[0057] Finally, it should be noted that the above embodiments are merely preferred embodiments of the present invention used to illustrate the technical solutions of the present invention, and are not intended to limit the invention, nor are they intended to limit the patent scope of the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention. That is to say, any changes or refinements made to the main design concept and spirit of the present invention that are not of substantial significance, but whose technical problems are still consistent with the present invention, should be included within the protection scope of the present invention. In addition, the direct or indirect application of the technical solutions of the present invention to other related technical fields are similarly included within the patent protection scope of the present invention.

Claims

1. A method for cooperating instruction parsing and multi-executor task processing, characterized in that, Includes the following steps: S1. Configure a Webhook on the code hosting platform and persist the configuration information on the server side. The configuration information includes the service address, subscription events, Webhook key, access token, platform root address, local working directory, and skill resource root directory; the skill resource root directory is physically separated from the user's cloned business repository; S2. Receive the Webhook request body as a raw byte stream and convert it into a raw request body string. Obtain the authentication string from the pre-defined request header. Verify the authentication string and the raw request body string using the corresponding verification method according to the format of the authentication string. If the verification is successful, parse the raw request body string into a structured event. If the verification fails, refuse service and terminate. S3. Extract the main text from the structured event, match valid instructions within the main text, capture the provider keywords and instruction text in the valid instructions, and terminate if no valid instructions are matched. S4. Assemble the underlying context based on the event types in the structured events; S5. Based on the basic context, perform intent recognition on the instruction text, and divide it into corresponding routing branches according to the recognition results. Each routing branch corresponds to an intent category and a skill subdirectory under the skill resource root directory. Each skill subdirectory contains the skill description file corresponding to the routing branch. Read the full text of the skill description file for this route branch, and combine the basic context, instruction text, and skill description file into a complete prompt; S6. Assign an independent working directory for the structured event in the local working directory, perform a shallow clone of the working branch in the structured event using the business repository address with the embedded access token, configure the local user information, and obtain the working area path; if the business repository has no working branch, clone the default branch of the repository and then try to check out the working branch. S7. Establish a fixed mapping table between provider identifiers and executor instances; search for a unique corresponding executor instance from the mapping table based on the provider keyword in the valid instruction, and pass the complete prompt, workspace path and progress callback interface to the executor to execute the task; if not found, fall back to the default executor or return an error. S8. The executor sends back the progress through the progress callback interface, and the server presents the execution progress in a way that updates the progress of each comment iteratively. S9. Write the execution results back to the issue or merge request that triggered the task.

2. The method according to claim 1, characterized in that, In S2, the verification methods include: If the authentication string is a plaintext token, the authentication string is compared with the Webhook key for complete equality. If they are equal, the signature verification is successful. If the authentication string is indicated by a predefined prefix as a digest type, the prefix is ​​removed to obtain the peer's hexadecimal digest. Using the Webhook key as the key, the original request body string is processed by hash-based message authentication code operation according to the predefined character encoding to obtain the local hexadecimal digest. If the lengths of the two digests are the same, a constant time comparison is used. If they are equal, the signature verification passes; otherwise, the signature verification fails.

3. The method according to claim 1, characterized in that, In S3, the first valid instruction is matched in the body text using a formal pattern. The formal pattern is used to capture the provider keyword and instruction body in the valid instruction. The provider keyword is limited to an enumerated set. The instruction body is matched non-greedy, and the matching range ends at the next valid instruction in the body text or the end of the body text. Allows the insertion of an optional parameter segment between the provider keyword and the instruction body to specify the model identifier; if the provider keyword is a specific alias, it is mapped to a configurable default provider identifier.

4. The method according to claim 1, characterized in that, In S3, extracting the main text from structured events involves: determining the text based on the event type field in the structured event; if the event type is an issue or a merge request, extracting the text from the description; if it is a merge request, also extracting the source branch or the default branch from the structured event as the working branch. If the event type is a comment, extract the text from the comment body and obtain the issue or merge request to which the comment is attached from the structured event.

5. The method according to claim 1, characterized in that, In S4, the basic context includes at least the event number, title, branch information, and change scale; if the event type is a comment, the basic context also includes the discussion list and previous replies within the thread.

6. The method according to claim 1, characterized in that, In S5, routing branches include review branches, to-do branches, and general assistance branches. For review branches, a set of references is maintained in the corresponding skill subdirectory: the list file in the skill subdirectory lists the filenames of the reference fragment files in line order, and supports skipping comment lines and missing files. Read the contents of the corresponding reference fragment files in the order listed, merge them into a reference set, and the reference set belongs to the review skill system corresponding to the current route.

7. The method according to claim 6, characterized in that, In S5, for review branches, the corresponding review template is read from the corresponding skill subdirectory. The placeholder items in the template are replaced with the summary of the description required for the effective instruction, the baseline and top references for the merged comparison, the requirement or plan references, and the batch scope description to obtain the filled review template. The basic context, instruction text, corresponding skill description document, filled review template and reference reference set are then assembled in sequence into a complete prompt.

8. The method according to claim 1, characterized in that, In S8, the execution progress is presented through iterative updates of individual comments, specifically including: When a task begins, a comment is created on the corresponding topic or merge request, and the comment identifier is recorded. If the discussion thread identifier is already included in the basic context, a progress comment is created in the form of a reply under that thread. If the reply interface of the code hosting platform is unavailable, it falls back to a top-level ordinary comment. During task execution, the server writes the received short texts with the agreed time zone timestamp into the memory queue, merges the short texts with duplicate content, and only retains the most recent short texts to be appended to the body of the progress comment. Each update targets the comment icon and overwrites the body of the update progress comment. If the update fails, it is downgraded to creating a new comment to carry the current progress. When the task is completed, write the completion status (success or failure) and the last update time in the body of the progress comment.

9. The method according to claim 1, characterized in that, When the number of change files between the source and target branches in a merge request exceeds a threshold, a batch review will be performed: Pull all change file paths between the source branch and the target branch, exclude conventionally generated directories, filter non-code files, dynamically calculate the batch number based on the number of change files and the configuration, aggregate into subtasks based on the directory where the change files are located, and merge with adjacent subtasks if the number of files contained in a subtask is less than the configured minimum value, and further split if it exceeds the configured maximum value. For each batch of subtasks, S7 is re-executed, and the prompts in the context of the corresponding executor are replaced with enhanced prompts that include the path range of the batch, the batch number, and a reference to the difference comparison. A hard reset is performed on the workspace and untracked files are cleaned up between each batch of subtasks.

10. A system for performing the method according to any one of claims 1-9, characterized in that, Includes the following modules: Access and Configuration Module: Used to configure Webhooks on the code hosting platform and persist configuration information on the server side. The configuration information includes service address, subscription events, Webhook key, access token, platform root address, local working directory, and skill resource root directory; the skill resource root directory is physically separated from the user's cloned business repository; The receiving and signature verification module is used to receive the Webhook request body as a raw byte stream and convert it into a raw request body string. It obtains the authentication string from the preset request header and verifies the authentication string and the raw request body string according to the format of the authentication string using the corresponding signature verification method. If the signature verification is successful, the raw request body string is parsed into a structured event. If the signature verification fails, the service is rejected and terminated. Instruction extraction module: used to extract the main text from structured events, match valid instructions within the main text, capture provider keywords and instruction text in valid instructions, and terminate if no valid instruction is matched; Context building module: Used to assemble the underlying context based on the event types in a structured event; The prompt building module is used to perform intent recognition on the instruction text based on the basic context, and divide it into corresponding routing branches according to the recognition results. Each routing branch corresponds to an intent category and a skill subdirectory under the skill resource root directory. Each skill subdirectory contains the skill description file corresponding to the routing branch. Read the full text of the skill description file for this route branch, and combine the basic context, instruction text, and skill description file into a complete prompt; Workspace Management Module: Used to allocate independent working directories for structured events under the local working directory, perform shallow cloning of the working branches in the structured events using the business repository address with embedded access tokens, configure local user information, and obtain the workspace path; If the business repository has no working branch, clone the repository's default branch and then try to check out the working branch again; Multi-executor scheduling module: used to establish a fixed mapping table between provider identifiers and executor instances; based on the provider keyword in the valid instruction, it searches the mapping table for a unique corresponding executor instance, passes the complete prompt, workspace path and progress callback interface to the executor to execute the task; if no instance is found, it falls back to the default executor or returns an error. Progress feedback module: Used to present the execution progress in the form of iterative updates of a single comment when the executor sends back progress through the progress callback interface; Result write-back module: Used to write back the execution results to the issue or merge request that triggered the task.

Images