Methods and apparatus for processing code development tasks
By synchronizing local session files to remote storage in a distributed environment, the robustness and fault tolerance issues of code development tasks are solved, enabling seamless task continuation and efficient execution.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING BAIDU NETCOM SCI & TECH CO LTD
- Filing Date
- 2026-02-06
- Publication Date
- 2026-06-30
Smart Images
Figure CN122309036A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and more particularly to methods and apparatus for processing code development tasks in the field of artificial intelligence technology. Background Technology
[0002] The rapid iteration pace, large-scale interaction pressures, and complex technology stacks inherent in the internet industry create a stark contrast with the efficiency, cost, and quality bottlenecks of traditional manual coding. Therefore, automated code development using large language models is becoming a future trend. However, code development often involves long cycles and multiple steps, making it crucial to address the issue of ensuring robustness and fault tolerance in distributed development environments. Summary of the Invention
[0003] This disclosure provides a method, apparatus, electronic device, non-transitory computer-readable storage medium, and computer program product for processing code development tasks, in order to improve the robustness and fault tolerance of code development.
[0004] According to a first aspect of this disclosure, a method for processing code development tasks is provided, comprising: In response to establishing the first subtask of the code development task, the local session file corresponding to the code development task is detected, and the session file includes the session content generated by the first executor instance calling the coding agent to execute the first subtask; In response to detecting a change in the local session file, the modified local session file is synchronized to the remote storage space; In response to obtaining the second subtask of the code development task, the second subtask is sent to the second executor instance, and the second executor instance obtains the session file corresponding to the code development task from the remote storage space and executes the second subtask based on the session file obtained from the remote storage space; The first subtask is the preceding subtask of the second subtask.
[0005] According to a second aspect of this disclosure, a processing apparatus for code development tasks is provided, comprising: The session management module is configured to, in response to the establishment of a first subtask of a code development task, detect the local session file corresponding to the code development task, the session file including the session content generated by the first executor instance calling the coding agent to execute the first subtask; and in response to detecting that the local session file has been changed, synchronize the changed local session file to the remote storage space. The scheduler module is configured to, in response to obtaining a second subtask of the code development task, send the second subtask to a second executor instance, and, through the second executor instance, obtain the session file corresponding to the code development task from the remote storage space and execute the second subtask based on the session file obtained from the remote storage space.
[0006] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect above.
[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the method described in the first aspect above.
[0008] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in the first aspect above.
[0009] As can be seen from the above technical solutions, this disclosure detects changes to the local session file and synchronizes it to the remote storage space, and can retrieve the session file from the remote storage space when executing subsequent subtasks of the code development task. By remotely synchronizing the session content corresponding to the code development task, the continuity and recoverability of the task execution process are ensured. Even if different subtasks of the same code development task are assigned to different executor instances, the subtasks can continue to be executed based on a unified session context, thus improving robustness and fault tolerance.
[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description
[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure.
[0012] Figure 1 This is an exemplary system architecture diagram to which embodiments of this disclosure can be applied.
[0013] Figure 2 This is a schematic flowchart illustrating a method for processing code development tasks according to an embodiment of the present disclosure.
[0014] Figure 3 A schematic block diagram of a processing apparatus for code development tasks provided in an embodiment of this application.
[0015] Figure 4 This is a block diagram of an electronic device used to implement the code development task processing method of the embodiments of this disclosure. Detailed Implementation
[0016] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.
[0017] Traditional code development mainly includes two approaches: One approach relies on developers manually writing code, supplemented by intelligent code completion from the integrated development environment (IDE). This method is obviously labor-intensive and inefficient.
[0018] Another approach is to use intelligent programming assistants to generate local code suggestions based on code context or comments. While this method reduces manual costs to some extent, it only focuses on specific parts of the development process, providing fragment-level suggestions. A significant amount of work still requires manual execution and cannot achieve automated code generation.
[0019] To reduce labor costs and improve development efficiency, various development service providers are committed to increasing the automation and intelligence of code development. However, code development involves long-cycle, multi-step agent task collaboration, and the conversation content is easily lost, making it difficult to resume the task after interruption, resulting in poor robustness and fault tolerance.
[0020] In view of this, this disclosure provides a completely new approach. To facilitate understanding of the embodiments of this disclosure, the system architecture on which this disclosure is based will first be described. Figure 1 Exemplary system architectures that can be applied to embodiments of this disclosure are shown, such as Figure 1 As shown, the system architecture may include: a user-side and a processing device for code development tasks set up on the server side.
[0021] The server side and the client side are the two main components of an application service. The server side uses a server as its primary hardware infrastructure and may include one or more software service modules. The server side and the client side form a collaborative front-end and back-end.
[0022] The client can be set on the terminal device. In this embodiment of the disclosure, the client can be a local application, a mini-program, or a web application running through a browser on the terminal device.
[0023] A server can be a single server, a server cluster consisting of multiple servers, or a cloud server. A cloud server, also known as a cloud computing server or cloud host, is a hosting product in the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) services, such as high management difficulty and weak service scalability.
[0024] In this embodiment, the user client can submit development requirement information input by the user to the server. The server-side code development task processing device automatically generates code based on the development requirement information. In this embodiment, the code development task processing device has at least the functions of managing session files, generating, scheduling, and executing subtasks of code development tasks. During the code generation process, the code development task processing device may access remote storage space, specification databases, code repositories, etc., and may also involve invoking coding agents.
[0025] It should be understood that Figure 1 The number of client terminals, code development task processing devices, remote storage spaces, specification databases, code repositories, and coding agents shown in the diagram is merely illustrative. Depending on implementation needs, any number of client terminals, code development task processing devices, remote storage spaces, specification databases, code repositories, and coding agents can be included.
[0026] In distributed, long-cycle, multi-iterative code development scenarios, to optimize task execution flexibility and resource utilization, the code development environment needs to support distributed task scheduling and dynamic start / stop of executor instances. However, the session-based interaction between the coding agent and executor instances has a strong state dependency. Specifically, in a cluster environment with multiple executor instances, if an executor instance fails while processing a code development task, or if the task needs to continue iterating while waiting for user feedback due to user feedback or code review, switching to another executor instance will result in the loss of the session history generated by the previous interaction between the executor instance and the coding agent. The new executor instance lacks the necessary context and cannot seamlessly continue the task. This either requires the user to repeatedly input information or forces the process to start from scratch, leading to interruptions in the automated code development process and reduced efficiency.
[0027] Through in-depth analysis, the inventors discovered that traditional session content management is tightly coupled with task execution logic. Session files reside in the memory of the executor instance or in local temporary storage, lacking a persistence mechanism that separates them from the task's lifecycle, and the context cannot be migrated between different executor instances. Furthermore, traditional solutions lack a mechanism to restore the preceding context when code development tasks need to be reassigned—that is, when a subtask needs to be assigned to a different executor instance than its predecessor—leading to a break in the automation chain.
[0028] To address the aforementioned issues, this disclosure proposes a processing method using a different technical approach. Figure 2 This is a schematic flowchart illustrating a method for processing code development tasks according to embodiments of the present disclosure. The method can be... Figure 1 The processing device for the code development task shown is executed. For example... Figure 2 As shown, the method may include the following: Step 201: In response to establishing the first subtask of the code development task, detect the local session file corresponding to the code development task. The session file includes the session content generated by the first executor instance calling the coding agent to execute the first subtask.
[0029] Step 203: In response to the detection of changes to the local session file, synchronize the changed local session file to the remote storage space.
[0030] Step 205: In response to obtaining the second subtask of the code development task, send the second subtask to the second executor instance, obtain the session file corresponding to the code development task from the remote storage space through the second executor instance, and execute the second subtask based on the session file obtained from the remote storage space; wherein, the first subtask is the preceding subtask of the second subtask.
[0031] As can be seen, this disclosure detects changes to the local session file and synchronizes it to the remote storage space, and can retrieve the session file from the remote storage space when executing subsequent subtasks of the code development task. By remotely synchronizing the session content corresponding to the code development task, the continuity and recoverability of the task execution process are improved. Even if different subtasks of the same code development task are assigned to different executor instances, the subtasks can continue to be executed based on a unified session context, thus improving robustness and fault tolerance.
[0032] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments. It should be noted that the terms "first," "second," etc., used in this disclosure do not have limitations in terms of size, order, or quantity, but are only used to distinguish them by name. For example, "first subtask" and "second subtask" are only used to distinguish two subtasks at different stages of the same code development task by name.
[0033] First, in conjunction with the embodiments, the above step 201, namely "in response to establishing the first subtask of the code development task, detecting the local session file corresponding to the code development task, the session file including the session content generated by the first executor instance calling the coding agent to execute the first subtask", will be described in detail.
[0034] The term "code development task" as used in the public context refers to a complete automated processing request initiated by a user (e.g., a developer) within a development system (or automated coding system). This request is based on user-inputted development requirements, which include core business requirements, technology stack and architectural constraints, functional details, and boundary conditions. A code development task must at least include a unique task identifier, development requirements information, the product line or project to which it belongs, and a configured workspace path.
[0035] In this embodiment of the disclosure, the execution of code development tasks involves multiple sub-tasks corresponding to different stages. Some of these sub-tasks involve invoking coding agents, such as invoking a first coding agent to generate execution planning information based on user-inputted development requirements; or invoking a second coding agent to generate code based on the development requirements and execution planning information. If the invocation of the coding agent is executed by a first executor instance, the first executor instance will generate a session file during the invocation and interaction with the coding agent, and this session file will be stored locally.
[0036] It should be noted that the first coded agent and the second coded agent involved in the embodiments of this disclosure can be the same coded agent or different coded agents.
[0037] A task management interface can be provided to users, displaying a component that triggers and displays session information. If a user triggers this component, a window will be displayed on the task management interface, showing the session information generated during the execution of the development task.
[0038] The term "coding agent" as used in this disclosure refers to an intelligent coding agent built on a large language model, capable of understanding development requirements and generating execution specifications or code. Its core function is to understand and execute coding-related processing logic.
[0039] The term "executor instance" as used in this disclosure refers to any process, container, or computing unit capable of hosting and running the execution logic of a code development task.
[0040] In this embodiment, the session file may include, but is not limited to, globally unique identifiers (typically uniquely corresponding to code development tasks), user-provided raw input (e.g., user-inputted development requirements, user feedback on execution planning information, user feedback on code review results, etc.), the coding agent's thought records, and the coding agent's output content, among other contextual content. The session file corresponds to the code development task; for example, the task identifier of the code development task is maintained and stored in correspondence with the identifier in the session file. Subtasks at each stage of the code development task share the same task identifier, thereby distinguishing the code development task to which they belong.
[0041] In this embodiment of the disclosure, a session listener can periodically detect the local session file corresponding to the code development task. The session listener can be bound to the code development task identifier. The interval of periodic detection can be flexibly configured, for example, set to 30 seconds, 1 minute, or a shorter or longer time interval, to capture changes in session content.
[0042] One possible approach is for the session listener to periodically check the most recent modification timestamp of the session file and determine whether the local session file has been changed by comparing the modification timestamp with the timestamp of the last time the session file was synchronized to the remote storage space.
[0043] Besides this method, other methods can be used to detect whether local session files have changed, such as listening for file modification events through the operating system's file system monitoring interface.
[0044] The following describes step 203, namely "in response to detecting a change in the local session file, synchronizing the changed local session file to the remote storage space", in detail with reference to the embodiments.
[0045] This step is used to transfer session content from a volatile local environment to a persistent, shareable remote environment. The purpose is to build a session context backup that is independent of the executor instance, providing a basis for context recovery across executor instances.
[0046] The aforementioned synchronization operation may include reading the modified session file and uploading it to a specified path in a remote storage space (such as cloud storage) via a network protocol. For example, it may involve creating an export directory structure, parsing the session content in the session file, organizing and converting the session content according to a predefined format to generate a viewable document, and then uploading it to the specified path in the remote storage space. This path is associated with the task identifier of the code development task for storage, ensuring that the session content of each code development task can be accurately stored and retrieved, and guaranteeing the security and accessibility of the session content. If the upload is successful, the timestamp of the session file synchronized to the remote storage space is updated.
[0047] Synchronization can take the form of, but is not limited to, full synchronization and incremental synchronization. Full synchronization refers to uploading the entire session file every time a change is detected in the local session file. Incremental synchronization refers to appending only the newly added lines or data blocks from the local session file to the session file in the remote storage space.
[0048] The following describes in detail step 205, namely, "in response to obtaining the second subtask of the code development task, sending the second subtask to the second executor instance, obtaining the session file corresponding to the code development task from the remote storage space through the second executor instance, and executing the second subtask based on the session file obtained from the remote storage space; wherein, the first subtask is the preceding subtask of the second subtask", with reference to the embodiments.
[0049] In a code development task, achieving automatic code generation typically involves multiple stages of processing, which are then divided into several related subtasks. Executing these multiple stages, or related subtasks, may involve one or more executor instances.
[0050] As one possible implementation, a preferred code development task may include: after obtaining development requirement information input by the user, invoking a first programming intelligence agent to generate execution plan information based on the development requirement information, and sending the execution plan information to the user terminal. If feedback from the user terminal regarding the execution plan information indicates rejection, then obtaining at least one of the rejection reason and modification suggestion returned by the user terminal, and invoking the first coding intelligence agent to regenerate the execution plan information based on at least one of the rejection reason and modification suggestion, as well as the development requirement information. If feedback from the user terminal regarding the execution plan information indicates confirmation, then invoking a second coding intelligence agent to generate code based on the development requirement information and the execution plan information. Submitting the code for review, if the review result indicates rejection, then invoking the second coding intelligence agent to optimize the code based on the development requirement information, the execution plan information, and the review feedback information for the code; then resubmitting the optimized code for review until the review result is approval.
[0051] Besides the methods described above, in the code development task, instead of sending the execution plan information to the user end, the second coding agent can be directly invoked to generate code based on the development requirements information and the generated execution plan information. Alternatively, the code development task can be terminated directly after code generation without submitting the code for review.
[0052] Therefore, based on the aforementioned code development tasks, in some scenarios, the first subtask executed by the executor instance may include: invoking the first coding agent to generate execution plan information based on development requirement information, and sending the execution plan information to the user terminal. The second subtask is generated in response to the user terminal's feedback confirmation of the execution plan information; the first subtask is a prerequisite task for the second subtask. When the executor instance executes the second subtask, it invokes the second coding agent to generate code based on the development requirement information and the execution plan information. The development requirement information and execution plan information can be the context obtained from the session file when the executor instance executes the second subtask.
[0053] In this scenario, reliable context guarantees can be provided for the processing of both the planning and coding stages. Through the synchronization mechanism disclosed herein, when executing the second subtask corresponding to coding, if a switch of executor instance occurs, session content (such as development requirement information, execution planning information, etc.) can be obtained from the remote storage space, effectively avoiding deviations or omissions in requirement understanding and planning execution due to lack of context, thereby improving robustness and fault tolerance.
[0054] In other scenarios, the first subtask executed by the executor instance may include: invoking a first coded agent to generate execution plan information based on development requirement information, and sending the execution plan information to the user terminal. The second subtask arises in response to a rejection indication from the user terminal regarding the execution plan information; the first subtask is a prerequisite for the second subtask. When the executor instance executes the second subtask, it obtains at least one of the rejection reason and modification suggestion returned by the user terminal, and invokes the first coded agent to regenerate the execution plan information based on at least one of the rejection reason and modification suggestion (also returned by the user terminal) and the development requirement information. The development requirement information and execution plan information can be context obtained from a session file when the executor instance executes the second subtask.
[0055] This scenario introduces closed-loop iterative capabilities into the code development process. When the generated execution plan information does not meet user requirements, even if the executor instance is switched, the switched executor instance can still obtain session content from remote storage, such as development requirements information and the initial execution plan. This ensures that the iteration process is based on accurate information, and the first coding agent can regenerate the execution plan information based on a full understanding of the context, significantly improving the targeting and accuracy of iterative optimization.
[0056] In other scenarios, the first subtask executed by the executor instance may include: invoking a second coding agent to generate code based at least on development requirements information, and submitting the code for review. The second subtask arises in response to a rejection indicated by the review result, and the first subtask is a prerequisite for the second subtask. When the executor instance executes the second subtask, it invoking the second coding agent to optimize the code based at least on development requirements information and review feedback information on the code (and may further be based on execution planning information).
[0057] This scenario implements context inheritance in the code quality optimization process. When code needs optimization due to review rejection, the second subtask, the code optimization subtask, can access the context from when the code was generated (including development requirements information, execution planning information, etc.). This allows the second coding agent to optimize the code not only based on review feedback but also to gain a deeper understanding of the original development intent, thereby performing more accurate and reasonable optimizations and improving the efficiency and quality of the closed-loop optimization process in the code review process.
[0058] In addition to the scenarios mentioned above, other scenarios, as well as other first and second sub-tasks, can be generated based on the specific process of code generation tasks, which will not be listed here.
[0059] As one possible approach, in response to obtaining the second subtask of the code development task, if the first executor instance executing the preceding first subtask fails, the second subtask is assigned to the second executor instance, that is, the second subtask is sent to the second executor instance, and the second executor instance retrieves the session file corresponding to the code development task from the remote storage space and executes the second subtask based on the session file retrieved from the remote storage space.
[0060] When assigning a second subtask to a second executor instance, an executor instance can be selected from among multiple live executor instances based on their load status. For example, by maintaining all live and idle executor instances in an executor resource pool, an idle executor instance can be obtained from the pool as the second executor instance, and the second subtask can be sent to that second executor instance. After executing the received subtask, the executor instance returns to the executor resource pool.
[0061] In response to the acquisition of the second subtask of the code development task, if the first executor instance that executed the preceding first subtask is still alive, the second subtask will still be assigned to the first executor instance, that is, the second subtask will be sent to the first executor instance, and the first executor instance will execute the second subtask based on the local session file.
[0062] This method of deciding subtask allocation based on the state of the first executor instance prioritizes assigning subsequent subtasks to the original executor instance that is still alive. This fully utilizes the existing local session files of that executor instance, avoids unnecessary remote storage access operations, reduces network overhead, and improves the consistency and efficiency of task execution. A new executor instance is only enabled and the context is restored remotely when the original executor instance fails, thus achieving an effective balance between reliability and efficiency.
[0063] The scheduling and allocation of subtasks within the code development task (i.e., sending subtasks to executor instances) can be handled by scheduler instances included in the scheduler module. Scheduler instances can use a periodic heartbeat mechanism to detect the status of executor instances, i.e., whether an executor instance is alive or invalid. Typically, when an executor instance becomes invalid, the resources it occupies are cleaned up and reclaimed; for example, local session files are cleaned up.
[0064] It should be noted that, in the embodiments disclosed herein, the failure of an executor instance is not limited to an executor instance crash or stop running, but can also be due to excessive load, insufficient resources, etc.
[0065] Besides using a distributed cluster approach for executor instances, scheduler instances can also be used in a distributed cluster, comprising multiple scheduler instances. Each scheduler instance can concurrently retrieve the target event from the event queue that caches various event types, obtain the subtask of the code development task corresponding to the target event, and assign the subtask to the executor instance. To ensure that an event can only be retrieved and its corresponding subtask assigned by one scheduler instance at a time, a distributed lock mechanism can be used. For example, a scheduler instance can request a queue-level lock for the queue containing the target event or request an event-level lock for the target event; after retrieving the target event from the event queue, it releases the queue-level lock or event-level lock. While the queue is locked, no other scheduler instance can access the event queue except for the scheduler instance that requested the queue-level lock.
[0066] For example, before attempting to retrieve a target event from an event queue, a scheduler instance first requests a lock from a distributed lock service, identified by the queue's name. Only a scheduler instance that successfully acquires the lock can retrieve an event from the queue, and immediately release the lock after the operation is complete. This approach uses the entire queue as the lock granularity, is simple to implement, and can quickly process events in the queue with minimal lock contention overhead.
[0067] As an alternative approach, a scheduler instance can acquire an event-level lock for a target event, retrieve the target event from its target queue, and then release the event-level lock. While the event is locked, no other scheduler instance can access it except for the one that acquired the lock.
[0068] For example, a scheduler instance first determines the identifier of the target event, and then uses that identifier as the key to request a distributed lock. Only a scheduler instance that successfully acquires the lock can retrieve the target event from the event queue, and immediately release the lock after the operation is complete. This approach uses a single event as the lock granularity, resulting in higher precision, and allows multiple scheduler instances to process different events in the same queue simultaneously, further improving system throughput.
[0069] In this disclosure, the term "target event" refers to a single event message retrieved from the event queue and currently awaiting processing. It typically carries information necessary to trigger subsequent processing. The autocoding system can maintain multiple types of event queues to categorize and store different types of events. For example, four event queues could be used to store events such as new code development tasks, events confirming execution plans returned by the client, events rejecting execution plans returned by the client, and events indicating rejection returned by the code review system.
[0070] In some cases, the second executor instance and the first executor instance may reside on the same physical node and have the same access permissions to local storage. Therefore, when executing the second subtask, the second executor instance can first determine whether the local session file corresponding to the code development task exists and is accessible. If it determines that the local session file corresponding to the code development task does not exist or is inaccessible, the second executor instance retrieves the session file corresponding to the code development task from the remote storage space and executes the second subtask based on the session file retrieved from the remote storage space. If it determines that the local session file corresponding to the code development task exists and is accessible, the second executor instance executes the second subtask using the local session file.
[0071] This mechanism prioritizes using locally accessible session files for code development tasks when executing tasks on a new executor instance. If a session file for a code development task is not available locally or is inaccessible, it is then retrieved from remote storage. This approach minimizes network overhead and improves execution efficiency while ensuring the robustness and reliability of code development.
[0072] In addition to the methods described above, the second executor instance can also directly obtain the session file corresponding to the code development task from the remote storage space and execute the second subtask based on the session file obtained from the remote storage space.
[0073] The second executor instance can retrieve the session file from remote storage in several ways. For example, when the second executor instance executes the second subtask, it actively retrieves the session file corresponding to the task identifier from the remote storage based on the task identifier of the code development task to which the second subtask belongs (this task identifier is shared by all subtasks of the code development task). Another example is that when the scheduler instance allocates the second subtask, it determines the storage path of the session file in the remote storage based on the task identifier and passes this storage path as a parameter to the second executor instance.
[0074] To further improve the manageability and queryability of session files, in this embodiment of the disclosure, the correspondence between the task identifier of the code development task and the session file in the remote storage space can be further maintained; in response to receiving a session file query request containing the task identifier, if there is a local session file corresponding to the task identifier, the local session file corresponding to the task identifier is queried and the query result is returned; otherwise, the session file in the remote storage space is queried based on the task identifier and the query result is returned.
[0075] This approach provides users (such as operations and maintenance personnel, developers, etc.) with an entry point to view session content, enhancing transparency and maintainability. For example, a task management interface can be displayed to users, including entries for created code development tasks. These entries can include operation components for the code development tasks, and these operation components can include components that trigger the display of session content. If the user triggers this component, the user's client sends a query request to the server. In response to this query request, the server can first check if a local session file corresponding to the code development task exists. If it exists, it directly reads and returns the query result, resulting in a faster response time. If the local session file corresponding to the code development task does not exist, it queries the remote storage space for the corresponding session file.
[0076] By adding the aforementioned session query and management functions, the entire automated code development process becomes more transparent and easier to trace, thereby enhancing the system's credibility and maintainability.
[0077] The following example of a specific application scenario illustrates the implementation process of the above-described method embodiments of this disclosure.
[0078] Developers create code development tasks through the development interface, filling in development requirements. A task ID is automatically generated for each task. The newly created task event, carrying this task ID, is sent to the event queue. The scheduler instance uses a distributed lock mechanism to retrieve the event from the event queue, obtains its corresponding subtask, and, based on a load balancing strategy, assigns executor instance A to execute the subtask. Executor instance A invokes the coding agent to generate execution plan information based on the development requirements and sends it to the user client, displaying it to developers through the development interface. The session file generated by executor instance A invoking the coding agent is stored locally and associated with the task ID. A session listener checks for changes to this session file every 30 seconds and synchronizes it to cloud storage upon detecting a change.
[0079] If the developers confirm the execution plan information, the client sends the confirmation feedback to the server, and the event confirming the execution plan information is added to the event queue. The scheduler instance uses a distributed lock mechanism to retrieve the event from the event queue, obtains its corresponding subtask, and determines that the executor instance A executing its preceding subtask is still alive. If so, it assigns the subtask to executor instance A. Executor instance A uses the local session file corresponding to the task ID to execute the subtask, that is, it continues to execute the code generated based on the development requirements information and the confirmed execution plan information, and submits the code for review. During this process, the session content generated by executor instance A calling the coded agent will still be updated in the local session file and synchronized to the cloud storage space.
[0080] At this point, executor instance A malfunctions and fails.
[0081] After code submission for review, the code review system reviews the code and indicates rejection. This rejection event is sent to the event queue. The scheduler instance uses a distributed lock mechanism to retrieve the event from the event queue and obtain its corresponding subtask. If it's determined that executor instance A, which executed the preceding subtask, has failed, a load balancing strategy can be used to allocate another executor instance B to execute the subtask. The cloud storage path of the session file obtained based on the task ID is then passed to executor instance B. Executor instance B pulls the session file corresponding to the task ID from the cloud, obtaining development requirements information, execution planning information, and the context of the code previously generated by executor instance A. Based on this session file, it executes the subtask, optimizing the code previously generated by executor instance A based on the review feedback, development requirements, and execution planning information. The optimized code is then submitted for review again.
[0082] As can be seen, the entire process requires no manual intervention for context transfer. The system can execute the context inheritance and continuation of each subtask in a code development task, thus ensuring that the coding agent's understanding and execution of the code development task are seamless, improving the reliability and fault tolerance of the entire task execution. Furthermore, all session content is traceable, facilitating subsequent traceability and maintenance.
[0083] Figure 3 A schematic block diagram of a processing apparatus for code development tasks provided in the embodiments of this application, such as... Figure 3 As shown, the processing device 300 may include a session management module 301 and a scheduler module 302. The main functions of each component are as follows: The session management module 301 is configured to detect the local session file corresponding to the code development task in response to the establishment of the first subtask of the code development task. The session file includes the session content generated by the first executor instance calling the coding agent to execute the first subtask. In response to the file detection unit detecting that the local session file has been changed, the modified local session file is synchronized to the remote storage space.
[0084] The scheduler module 302 is configured to send the second subtask to the second executor instance in response to obtaining the second subtask of the code development task, and to obtain the session file corresponding to the code development task from the remote storage space through the second executor instance and execute the second subtask based on the session file obtained from the remote storage space.
[0085] The first subtask is the preceding subtask of the second subtask.
[0086] As one possible implementation, when the scheduler module 302 sends the second subtask to the second executor instance in response to obtaining the second subtask of the code development task, it can be specifically configured to send the second subtask to the second executor instance in response to obtaining the second subtask of the code development task and the first executor instance becoming invalid.
[0087] As one possible implementation, when the second executor instance obtains the session file corresponding to the code development task from the remote storage space and executes the second subtask based on the session file obtained from the remote storage space, in response to determining that the local session file corresponding to the code development task does not exist or is inaccessible, the second executor instance obtains the session file corresponding to the code development task from the remote storage space and executes the second subtask based on the session file obtained from the remote storage space; in response to determining that the local session file corresponding to the code development task exists and is accessible, the second executor executes the second subtask using the local session file.
[0088] In some scenarios, the first subtask may include: calling the first coding agent to generate execution plan information based on development requirements information, and sending the execution plan information to the user terminal; the second subtask is generated in response to the user terminal's feedback result indicating confirmation of the execution plan information, and the second subtask may include: calling the second coding agent to generate code based on development requirements information and execution plan information.
[0089] In other scenarios, the first subtask may include: invoking a first coded intelligent agent to generate execution plan information based on development requirement information, and sending the execution plan information to the user terminal. The second subtask arises in response to a rejection indication from the user terminal regarding the execution plan information. The second subtask may include: obtaining at least one of the rejection reason and modification suggestion returned by the user terminal regarding the execution plan information, and invoking the first coded intelligent agent to regenerate the execution plan information based on at least one of the rejection reason and modification suggestion, as well as the development requirement information.
[0090] In some scenarios, the first subtask may include: invoking a second coding agent to generate code based at least on the development requirements information, and submitting the code for review. The second subtask arises in response to a rejection indicated by the review result. The second subtask includes: invoking a second coding agent to optimize the code based at least on the development requirements information and the review feedback information.
[0091] Furthermore, the session management module 301 can also maintain the mapping between task identifiers of code development tasks and session files in the remote storage space. Upon receiving a session file query request containing a task identifier, and finding that a local session file corresponding to the task identifier exists, the module queries the local session file corresponding to the task identifier and returns the query result. Conversely, upon receiving a session file query request containing a task identifier, and finding that a local session file corresponding to the task identifier does not exist, the module queries the session file in the remote storage space based on the task identifier and returns the query result.
[0092] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.
[0093] This disclosure also provides an electronic device, including: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed, enable the at least one processor to perform the processing method for the code development task described in any of the foregoing method embodiments.
[0094] This disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to perform a processing method for the code development task described in any of the foregoing method embodiments.
[0095] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the method for processing code development tasks described in any of the foregoing method embodiments.
[0096] Figure 4 A schematic block diagram of an example electronic device 400 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.
[0097] like Figure 4 As shown, device 400 includes a computing unit 401, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 402 or a computer program loaded from storage unit 408 into random access memory (RAM) 403. RAM 403 may also store various programs and data required for the operation of device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.
[0098] Multiple components in device 400 are connected to I / O interface 405, including: input unit 406, such as keyboard, mouse, etc.; output unit 407, such as various types of monitors, speakers, etc.; storage unit 408, such as disk, optical disk, etc.; and communication unit 409, such as network card, modem, wireless transceiver, etc. Communication unit 409 allows device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0099] The computing unit 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above, such as methods for processing code development tasks. For example, in some embodiments, methods for processing code development tasks may be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program may be loaded and / or installed on device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by the computing unit 401, one or more steps of the methods for processing code development tasks described above may be performed. Alternatively, in other embodiments, the computing unit 401 may be configured to perform methods for processing code development tasks by any other suitable means (e.g., by means of firmware).
[0100] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0101] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0102] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0103] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0104] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.
[0105] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.
[0106] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.
[0107] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.
Claims
1. A method of processing a code development task, characterized by, include: In response to establishing the first subtask of the code development task, the local session file corresponding to the code development task is detected, and the session file includes the session content generated by the first executor instance calling the coding agent to execute the first subtask; In response to detecting a change in the local session file, the modified local session file is synchronized to the remote storage space; In response to obtaining the second subtask of the code development task, the second subtask is sent to the second executor instance, and the second executor instance obtains the session file corresponding to the code development task from the remote storage space and executes the second subtask based on the session file obtained from the remote storage space; The first subtask is the preceding subtask of the second subtask.
2. The method of claim 1, wherein, The step of sending the second subtask to the second executor instance in response to obtaining the second subtask of the code development task includes: In response to obtaining the second subtask and determining that the first executor instance has failed, the second subtask is sent to the second executor instance.
3. The method of claim 1, wherein, The step of retrieving the session file corresponding to the code development task from the remote storage space through the second executor instance and executing the second sub-task based on the session file retrieved from the remote storage space includes: In response to determining that the local session file corresponding to the code development task does not exist or is inaccessible, the second executor instance retrieves the session file corresponding to the code development task from the remote storage space and executes the second subtask based on the session file retrieved from the remote storage space. In response to determining that the local session file corresponding to the code development task exists and is accessible, the second subtask is executed by the second executor using the local session file.
4. The method of claim 1, wherein, The first subtask includes: invoking a first coded intelligent agent to generate execution plan information based on the development requirement information, and sending the execution plan information to the user terminal; The second subtask is generated in response to the feedback result confirmation of the execution planning information returned by the user terminal. The second subtask includes: invoking the second coding agent to generate code based on the development requirement information and the execution planning information.
5. The method of claim 1, wherein, The first subtask includes: invoking the first coded intelligent agent to generate execution plan information based on development requirement information, and sending the execution plan information to the user terminal; The second subtask is generated in response to the user terminal's feedback result indicating rejection of the execution planning information. The second subtask includes: obtaining at least one of the rejection reason and modification suggestion returned by the user terminal for the execution planning information, and invoking the first coding agent to regenerate the execution planning information based on at least one of the rejection reason and modification suggestion and the development requirement information.
6. The method of claim 1, wherein, The first subtask includes: invoking the second coded agent to generate code based at least on development requirements information, and submitting the code for review; The second subtask is generated in response to the result of the review indicating rejection, and the second subtask includes: invoking the second coding agent to optimize the code based at least on the development requirements information and the review feedback information on the code.
7. The method according to any one of claims 1 to 6, further comprising: Maintain the correspondence between the task identifier of the code development task and the session file in the remote storage space; In response to receiving a session file query request containing the task identifier, and if a local session file corresponding to the task identifier exists, the system queries the local session file corresponding to the task identifier and returns the query result. In response to receiving a session file query request containing the task identifier, and finding that no local session file exists corresponding to the task identifier, the system queries the session file in the remote storage space based on the task identifier and returns the query result.
8. A processing device for code development tasks, characterized in that, include: The session management module is configured to detect the local session file corresponding to the code development task in response to the establishment of the first subtask of the code development task. The session file includes the session content generated by the first executor instance calling the coding agent to execute the first subtask. In response to detecting a change in the local session file, the modified local session file is synchronized to the remote storage space; The scheduler module is configured to, in response to obtaining a second subtask of the code development task, send the second subtask to a second executor instance, and, through the second executor instance, obtain the session file corresponding to the code development task from the remote storage space and execute the second subtask based on the session file obtained from the remote storage space.
9. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.
10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.
11. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.