A method of software development and electronic device

Abstract

The present disclosure provides a method for software development and an electronic device, which are used for realizing automation of a development task process by using an agent, improving the efficiency of software development, and saving labor costs. The method comprises the following steps: acquiring task data corresponding to at least one task type by using an RPA agent, wherein the RPA agent is used for realizing automation of a bottom-layer software development process, and different task types are used for representing different tasks in the bottom-layer software development process; determining a task agent corresponding to the task type; and executing task content corresponding to the task type according to the task data by using the task agent, so as to obtain a task execution result.

Description

A software development method and an electronic device Technical Field

[0001] This disclosure relates to the field of computer software technology, and in particular to a software development method and an electronic device. Background Technology

[0002] Low-level technology refers to the file system closely integrated with the hardware, used for computer power-on self-test (POST), hardware initialization, and operating system booting. The operating system here includes mainstream operating systems such as Windows, Linux, and iOS, and cross-platform development techniques are employed during its development. Taking Windows as an example, in a Windows-based x86 computer architecture, this primarily involves the BIOS (Basic Input / Output System) and EC (Embedded Controller). Low-level software development involves adding project-specific code modules to the basic codebase, based on hardware circuitry, peripheral interface design, power-on / off timings, and other design considerations.

[0003] Currently, low-level software development requires developers with fundamental technical skills, demanding a high level of expertise and involving manual operation. This makes the software design and development process cumbersome and challenging. Consequently, low-level software development is currently inefficient and inefficient in terms of human resources.

[0004] Summary of the Invention

[0005] This disclosure provides a software development method and electronic device for automating the development task process using intelligent agents, thereby improving software development efficiency and saving labor costs.

[0006] In a first aspect, the present disclosure provides a software development method, the method comprising:

[0007] Using RPA agents, task data corresponding to at least one task type is obtained. The RPA agents are used to automate the underlying software development process, and different task types are used to represent different tasks in the underlying software development process.

[0008] Determine the task agent corresponding to the task type;

[0009] Using the task agent, the task content corresponding to the task type is executed according to the task data to obtain the task execution result.

[0010] Secondly, an electronic device provided in this disclosure includes a processor and a memory, wherein the memory is used to store a program executable by the processor, and the processor is used to read the program in the memory and perform the following steps:

[0011] Using RPA agents, task data corresponding to at least one task type is obtained. The RPA agents are used to automate the underlying software development process, and different task types are used to represent different tasks in the underlying software development process.

[0012] Determine the task agent corresponding to the task type;

[0013] Using the task agent, the task content corresponding to the task type is executed according to the task data to obtain the task execution result.

[0014] Thirdly, embodiments of this disclosure also provide an apparatus for developing low-level software, the apparatus comprising:

[0015] The data acquisition unit is used to acquire task data corresponding to at least one task type using an RPA agent, wherein the RPA agent is used to automate the underlying software development process, and different task types are used to represent different tasks in the underlying software development process.

[0016] An agent determination unit is used to determine the task agent corresponding to the task type;

[0017] The task execution unit is used to utilize the task agent to execute the task content corresponding to the task type according to the task data, and obtain the task execution result.

[0018] Fourthly, embodiments of this disclosure also provide a computer storage medium having a computer program stored thereon, which, when executed by a processor, is used to implement the steps of the method described in any of the first aspects above.

[0019] Fifthly, this disclosure provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of the first aspects.

[0020] These or other aspects of this disclosure will become more apparent in the following description of embodiments. Attached Figure Description

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

[0022] Figure 1 is a flowchart illustrating the implementation of a software development method according to an embodiment of this disclosure;

[0023] Figure 2 is a schematic diagram of an automated software and hardware testing process provided in an embodiment of this disclosure;

[0024] Figure 3 is an automated flowchart of software and hardware simulation debugging, taking a blue screen as an example, provided by an embodiment of this disclosure;

[0025] Figure 4 is a schematic diagram of a UI interaction interface process management provided in an embodiment of this disclosure;

[0026] Figure 5 is a schematic diagram of a software development architecture provided in an embodiment of this disclosure;

[0027] Figure 6 is a schematic diagram of a system architecture for intelligent agent task processing provided in an embodiment of this disclosure;

[0028] Figure 7 is a schematic diagram of a software development model framework provided in an embodiment of this disclosure;

[0029] Figure 8 is a schematic diagram of a hardware framework for low-level software development provided in an embodiment of this disclosure;

[0030] Figure 9 is a schematic diagram of an electronic device provided in an embodiment of this disclosure;

[0031] Figure 10 is a schematic diagram of a device for developing low-level software according to an embodiment of this disclosure. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this disclosure clearer, the disclosure will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0033] In this disclosure, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0034] The application scenarios described in this disclosure are for the purpose of more clearly illustrating the technical solutions of this disclosure and do not constitute a limitation on the technical solutions provided in this disclosure. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided in this disclosure are also applicable to similar technical problems. In the description of this disclosure, unless otherwise stated, "multiple" means two or more.

[0035] Before introducing the software development method provided in the embodiments of this disclosure, for ease of understanding, the technical background of the embodiments of this disclosure will be described in detail below.

[0036] Low-level technology refers to the file system closely integrated with the hardware, used for computer power-on self-test, hardware initialization, and operating system booting. The operating system here includes mainstream operating systems such as Windows, Linux, and iOS, and cross-platform development techniques are often employed during development. Taking Windows as an example, in a Windows-x86 computer architecture, this mainly involves the BIOS (Basic Input / Output System) and EC (Embedded Controller). Low-level software development involves adding project-specific code modules to the basic codebase, making development and modifications based on hardware circuitry, peripheral interface design, power-on / off timings, etc. Currently, PC low-level software development requires developers with low-level technical capabilities, demanding a high level of expertise and requiring manual operation. The PC software design and development process is cumbersome and difficult. Therefore, low-level software development is currently inefficient and inefficient in terms of human resources.

[0037] To address the aforementioned technical problems, this embodiment provides a software development method, involving technological innovations in software development task design for laptops, desktops, all-in-one computers, etc. This embodiment utilizes RPA (Robotic Process Automation) agents within an agent set to automate the underlying software development process. Since the agent set includes RPA agents and task agents to implement different functions, the RPA agents can automatically call the APIs of different agents, automating both API and UI software, reducing manual operations, and implementing different development tasks based on different task agents. The task agents in this embodiment are built using AI models, deep learning technologies, etc., and can parse input data and generate accurate outputs. Based on deep learning technology, artificial intelligence, and process automation, the RPA Agent (intelligent agent) combining LLM (Large Language Model) and RPA can automate both API and UI software. The task agents in this embodiment possess the ability to think independently, call tools to gradually complete given goals, and have the ability to make autonomous decisions and execute actions.

[0038] The task agent in this embodiment has the following characteristics:

[0039] 1) Perception and comprehension abilities;

[0040] Intelligent agents can perceive information in their environment, such as images, sounds, and text, and understand the meaning and context of this information. This involves using technologies such as sensors, computer vision, speech recognition, and natural language processing to parse and understand input data.

[0041] 2) Decision-making and planning abilities;

[0042] Intelligent agents can make decisions and formulate action plans based on perceived information and stored knowledge. They can use logical reasoning, statistical analysis, planning algorithms or machine learning techniques to evaluate the possible outcomes and potential risks of different actions and select the best action strategy.

[0043] 3) Self-learning and adaptability;

[0044] Intelligent agents can continuously optimize their training datasets through data accumulation, learn from experience, and improve their performance based on feedback. They can utilize techniques such as supervised learning, reinforcement learning, and transfer learning to acquire new knowledge, adjust decision-making and action execution processes, and enhance their intelligence and adaptability.

[0045] 4) Interaction and communication skills;

[0046] Intelligent agents are capable of interacting and communicating with humans or other intelligent agents. They can understand natural language instructions, generate natural language responses, and communicate effectively with users using voice, text, or other means. This involves the application of technologies such as natural language processing, dialogue systems, and speech synthesis.

[0047] 5) Knowledge representation and storage capabilities;

[0048] Intelligent agents can organize and store knowledge, and effectively retrieve and utilize this knowledge to support decision-making and action. They can use symbolic logic, graphical models, vector representations, and other methods to represent and store knowledge, and use databases or other data structures to achieve efficient knowledge management.

[0049] 6) Context awareness and flexibility;

[0050] Intelligent agents have the ability to perceive different situations and can make corresponding adjustments according to changes in the situation. They can identify changes in the environment, adapt to new task requirements, and flexibly adjust decision-making and action strategies to adapt to different scenarios and needs.

[0051] As shown in Figure 1, the implementation flow of a software development method provided in this embodiment is as follows:

[0052] Step 100: Use RPA agents to obtain task data corresponding to at least one task type, wherein the RPA agents are used to automate the underlying software development process, and different task types are used to represent different tasks in the underlying software development process.

[0053] In practice, RPA (Robotic Process Automation) agents are an automation technology that uses software robots to simulate human operations and automatically execute repetitive, rule-based tasks. It can simulate various human actions, including mouse clicks, keyboard input, and information retrieval, making it suitable for highly repetitive and logically defined tasks. RPA agents interact with existing user systems through pre-programmed procedures to complete a series of tasks that would otherwise require manual intervention, such as data input, processing, application parsing, and communication with other systems. It does not require modification of program code; instead, it automates processes by mimicking human interaction with computers. For example, an RPA agent can automatically retrieve specific data from a webpage, copy related data, and log into a specified system. Compared to manual operations, RPA agents significantly reduce labor costs, automate task execution, and improve work efficiency. Because RPA agents are executed according to pre-programmed instructions, the possibility of human error is reduced. It is applicable to a variety of applications and systems, offering greater flexibility.

[0054] In some embodiments, before using the RPA agent to obtain task data corresponding to at least one task type, this embodiment also obtains the task type of the development task through any one or more of the following methods:

[0055] Method 1) Use RPA agents to obtain the task types of tasks in the development process;

[0056] Optionally, the development task and the task type of the development task can be obtained using an RPA agent; or, in response to the task information entered by the user through the UI interface, the development task can be determined and the task type of the development task can be obtained using an RPA agent.

[0057] Method 2) Respond to the task information entered by the user through the UI interface to obtain the task type in the development process.

[0058] Optionally, in response to task information entered by the user through the UI interface, the development task and the task type of the development task are determined.

[0059] In implementation, this embodiment can acquire development tasks and determine the task type of the development tasks. Optionally, the development tasks can be acquired and the task type of the development tasks can be determined using an RPA agent within the agent; alternatively, task instructions input by the user can be received to acquire the development tasks and their task types.

[0060] This embodiment utilizes an RPA agent to automatically acquire task data corresponding to a task type, thereby providing basic data for automatically executing development tasks of that type. For example, when executing software development tasks, it can automatically acquire development data such as basic code, hardware data, and circuit diagrams, facilitating code generation; when executing software and hardware testing, it can automatically acquire fault data, facilitating fault detection; and when executing driver configuration, it can automatically acquire driver data, facilitating the matching between the driver and the system.

[0061] Step 101: Determine the task agent corresponding to the task type;

[0062] Optionally, this embodiment can define different task types according to different tasks in the development process of the underlying software. The task types in this embodiment can be divided into different fine-grained categories according to the task requirements of the development process. The entire task of the development process can be divided into smaller tasks, thereby obtaining different task types. For example, the development process can be divided into software development, debugging, driver configuration, and other tasks, and the corresponding task types are software development task, debugging task, and driver configuration task, respectively.

[0063] Optionally, the task types in this embodiment include, but are not limited to, software development tasks, debugging tasks, and driver configuration tasks. Optionally, the task agents in this embodiment include, but are not limited to, a first agent corresponding to a debugging task, a second agent corresponding to a software development task, and a third agent corresponding to a driver configuration task.

[0064] It should be noted that in this embodiment, the RPA agent, first agent, second agent, and third agent can all be collectively referred to as agents, and agents with different names play different roles in the development process. Optionally, this embodiment utilizes an agent set to automate the development process. The agent set includes, but is not limited to, RPA agents, first agents, second agents, and third agents. The number of agents can be determined based on the number of task types. One agent corresponds to one task type and is used to execute tasks of that type. The corresponding task agent can be called according to the task type.

[0065] Step 102: Using the task agent, execute the task content corresponding to the task type according to the task data to obtain the task execution result.

[0066] In some embodiments, the task data corresponding to the software development task includes, but is not limited to, development data; the task agent corresponding to the software development task includes, but is not limited to, a second agent; and the task content corresponding to the software development task includes, but is not limited to, the generation of underlying software code.

[0067] In implementation, the software development phase of the development process requires the generation of low-level software code. This low-level software code is used to check the hardware design and circuit diagrams, thereby performing hardware initialization and ultimately booting the operating system. Therefore, a task type called "software development task" can be defined during the software development phase. When executing a software development task, low-level software code can be automatically generated based on different framework structures and functional modules. After generating the low-level software code, hardware initialization is performed, and the operating system is loaded into memory, enabling the normal startup of the operating system.

[0068] In some implementations, the task data corresponding to the debugging task includes, but is not limited to, fault data; the task agent corresponding to the debugging task includes, but is not limited to, the first agent; and the task content corresponding to the debugging task includes, but is not limited to, software and hardware simulation debugging and verification of fault solutions.

[0069] During implementation, the debugging phase of the development process requires verifying whether the hardware and software meet the requirements outlined in the specifications. This phase involves testing both hardware and software. Hardware testing includes, but is not limited to, functional testing, performance testing, reliability testing, compatibility testing, security testing, and manufacturing defect inspection. Software testing includes, but is not limited to, functional testing, usability testing, reliability testing, security testing, performance testing, compatibility testing, ease-of-use testing, installation and uninstallation testing, documentation testing, and memory leak testing. Therefore, the task type can be defined as a debugging task during the debugging phase.

[0070] In some embodiments, the task data corresponding to the driver configuration task includes driver data; the task agent corresponding to the driver configuration task includes a third agent; and the task content corresponding to the driver configuration task includes driver loading and adaptation.

[0071] During implementation, in the deployment phase of the development process, the software is deployed in the production environment, and necessary configurations and optimizations are performed to ensure stable operation and meet user-expected performance metrics. Therefore, in the deployment phase, a task type can be defined as a driver configuration task to load the driver into the loading system. During the loading process, the compatibility between the driver and the system is tested to ensure that the loaded driver and the system are compatible.

[0072] Optionally, this embodiment utilizes a task agent to execute the task content corresponding to the task type based on the task data in the following manner:

[0073] Using the RPA agent, the task agent corresponding to the task type is invoked; the task agent is triggered to execute the task content corresponding to the task type, and the task execution result is obtained.

[0074] In practice, the RPA agent in this embodiment can automatically call the API (Application Programming Interface) of different task agents. The RPA agent can automatically capture task information (such as development tasks and task types) and automatically call the software, compilation environment, UI interface, etc. of the task agent corresponding to the task type. It can automatically trigger different task agents to execute the corresponding development tasks. The RPA agent in this embodiment can call any one or more task agents to execute the corresponding development tasks, thereby automating the complex software development process.

[0075] In some embodiments, the task agent in this embodiment is obtained by fine-tuning a large open-source model, such as the LoRa framework. After fine-tuning, a multi-model (text, logical reasoning, image analysis, etc.) collaboration approach is used to generate the task agent in this embodiment. The initial task agent is trained using a training dataset to obtain a trained task agent. The training dataset includes, but is not limited to: R&D data (code), design data (circuit diagrams, etc.), test data, etc. Specific training datasets include, but are not limited to: SOC platform design materials, BIOS (Basic Input Output System) architecture, EC (Embedded Controller) architecture, basic code, OS Policy learning, product requirements and functional design materials for Keyparts software configuration, and design-required materials such as output NUDD (New, Unique, Different, Difficult) (early risk management system for new product quality), etc.

[0076] In some embodiments, when the task type includes a software development task, the task data corresponding to the software development task includes development data; the task agent includes a second agent; this embodiment achieves software development automation through the following steps:

[0077] The development data is obtained using an RPA agent; a second agent is determined corresponding to the software development task; and the second agent is used to execute the software development task based on the development data.

[0078] Optional development data includes, but is not limited to: R&D data (code data) and design data (such as hardware data, circuit diagrams, etc.).

[0079] In some embodiments, the software development tasks include generating underlying software code; the second intelligent agent executes the software development tasks based on the development data through the following steps:

[0080] Using the second intelligent agent, underlying software code is generated based on the development data. This underlying software code is used to perform hardware initialization and guide the operating system to complete the startup process.

[0081] During implementation, the second intelligent agent reads the data required for software configuration from the circuit diagram, generating underlying software code. Based on hardware data, it migrates BIOS, EC, and firmware configurations, configures boot software according to customized requirements, configures boot software according to the design checklist, and summarizes the implementation of the NUDD solution. This automates the boot process. The hardware initialization process mainly includes the following steps: CPU initialization → memory initialization → hard disk initialization → peripheral device initialization.

[0082] In some embodiments, this example automates the acquisition of development data in the following manner:

[0083] The RPA agent invokes a large language model, triggering the large language model to perform semantic recognition on the development data, thereby obtaining hardware data and basic code; the hardware data and basic code are then identified as the development data.

[0084] In implementation, a Large Language Model (LLM) is used to analyze the user's development task requirements. Tasks are described using natural language or human-computer interaction, and the RPA agent, combined with contextual understanding, grasps the user's needs and goals. For example, during the code development phase, the RPA agent calls the LLM, inputting development data. The LLM identifies the development data, obtaining the corresponding hardware data and basic code. New code (i.e., development data) is generated using the basic code and hardware data, thereby executing hardware initialization and guiding the operating system to boot. The hardware data is used to check hardware design, circuit diagrams, etc. After power-on, the generated code loads the operating system from the hard drive into memory, facilitating interaction between the operating system and hardware during boot, thus enabling the operating system to start.

[0085] Optionally, the intelligent agent (including RPA agent and / or task agent) in this embodiment has a built-in AI dialogue interaction window, which pushes out R&D requirements based on LLM using AI model logical reasoning, statistical analysis, planning algorithms or machine learning technology; training data samples are made based on a large number of debug cases to gradually improve the reasoning ability of the AI ​​model in the current vertical field.

[0086] In some embodiments, when the task type includes software development tasks, software development automation is achieved in the following ways:

[0087] The RPA agent invokes the second agent, triggering the second agent to generate underlying software code based on the development data.

[0088] In implementation, the RPA agent automatically calls the API of the second agent, inputs the development data into the second agent, triggers the second agent to automatically generate the underlying software code based on the development data, uses the underlying software code to execute the initialization of the product device hardware, and guides the product device operating system to complete the startup, so as to realize the normal loading and startup of the product device operating system.

[0089] In some embodiments, when the task type includes a driver configuration task, the task data corresponding to the driver configuration task includes driver data; the task agent includes a third agent; this embodiment can also automate driver configuration in the following ways:

[0090] The RPA agent is used to acquire driver data; a third agent corresponding to the driver configuration task is determined; and the third agent is used to execute the task content corresponding to the driver configuration task according to the driver data.

[0091] In some embodiments, the driver data in this embodiment includes, but is not limited to, driver version, driver vendor, driver configuration file, etc.

[0092] In some embodiments, the task content corresponding to the driver configuration task includes driver loading and adaptation; this embodiment can also utilize the third intelligent agent to execute the task content corresponding to the driver configuration based on the driver data in the following manner:

[0093] Using the third intelligent agent, the adapted driver is loaded into the operating system based on the driver data.

[0094] In implementation, the driver acts as a bridge between the operating system and the hardware device, allowing the operating system to control the operation of the hardware device. If the device driver is not installed correctly, the device will not function properly. Different versions of the operating system have different compatibility requirements for drivers. Hardware manufacturers need to develop suitable drivers for their hardware devices when adapting to the operating system. This embodiment can utilize an RPA agent to automatically obtain driver data and a third agent to automatically load the driver adapted to the current operating system. Optionally, the driver data in this embodiment can be stored in a local database, which can also store information such as the operating system version and the operating system's driver adaptation files.

[0095] In some embodiments, this embodiment automates driver loading in the following manner:

[0096] The RPA agent invokes a third agent, which in turn triggers the third agent to load the adapted driver in the operating system based on the driver data.

[0097] In implementation, this embodiment utilizes an RPA agent to automatically call the API of a third agent, inputting driver data into the third agent. This triggers the third agent to load the appropriate driver into the operating system based on the driver data, thus automating driver loading. Optionally, the RPA agent can also acquire operating system data, inputting both operating system data and driver data into the third agent. The third agent then compares the operating system version and driver version to load the appropriate driver for the current operating system, automating driver loading and configuration.

[0098] In some embodiments, this embodiment can automate debugging, that is, automate software and hardware simulation debugging and verification. For example, it can automate the power-on debugging of surface mount technology (SMT), verify and debug the power-on configuration of GPIO (General Purpose Input / Output, an interface for digital signal interaction with external devices) and Sequence (a mechanism for generating test stimuli), generate power-on software re-flash in real time, analyze functional problem phenomena and provide solutions, record and output modified data, record probabilistic problems, analysis and suggested solutions, and can also directly output solutions for automatic verification.

[0099] In some embodiments, when the task type includes a debugging task, the task data corresponding to the debugging task includes fault data; the task agent includes a first agent; this embodiment automates the debugging task in the following way:

[0100] Step a: Obtain fault data using the RPA agent;

[0101] In practice, this embodiment can use an RPA agent to automatically acquire fault data. In this embodiment, fault data refers to the data that needs to be collected when a fault occurs. However, the fault data collected by the RPA agent may be data after a fault occurs or data collected when no fault occurs. The fault data is used to determine whether a fault has occurred.

[0102] Optionally, this embodiment can obtain fault data through any one or more of the following methods:

[0103] (1) The RPA agent is used to detect the occurrence of a fault and obtain the fault data of the current fault;

[0104] Optionally, the RPA agent can acquire fault data according to different fault types and determine whether a fault of that type has occurred based on the fault data. When a fault is determined to have occurred based on the fault data, the fault data of the current fault can be acquired.

[0105] (2) At a preset period, the RPA agent is used to acquire fault data of at least one type of fault;

[0106] In implementation, RPA agents can acquire fault data of different fault types according to different fault acquisition methods. Based on the acquired fault data, it can be determined whether a fault has occurred and what type of fault it is. It should be noted that the RPA agent in this embodiment can automatically acquire fault data, determine whether a fault has occurred based on the fault data, and, when fault data occurs, how to perform automated testing through the fault data to determine the cause and location of the fault and determine the method to resolve the fault.

[0107] (3) Respond to the fault information entered by the user through the UI interface and obtain fault data.

[0108] In practice, fault information can be identified as fault data, or it can be obtained by semantic parsing of the fault information. When the fault information input by the user meets the requirements, the fault information is identified as fault data. When the fault information input by the user does not meet the requirements, the RPA agent calls the LLM (Large Language Model) to perform semantic parsing of the fault information to obtain the corresponding fault data.

[0109] Optionally, the storage location of the fault data in this embodiment is determined according to the fault type, and the storage location of fault data for different fault types is different; the RPA agent is used to obtain fault data from the storage location corresponding to at least one fault type.

[0110] It should be noted that the location and presentation of fault data may differ for different fault types, therefore the methods for obtaining fault data for different fault types are also different.

[0111] In some embodiments, fault data is acquired using an RPA agent in the following manner:

[0112] The RPA agent is used to obtain fault parameters, and the fault type is determined based on the fault parameters, wherein the location of the fault occurs in different locations for different fault types; the RPA agent is used to determine the location of the fault based on the fault type, and the fault data corresponding to the location is obtained.

[0113] In implementation, this embodiment can utilize an RPA agent to acquire fault parameters, automatically capture detailed debug information, and parameters that may affect debugging (i.e., fault parameters), such as event log (program time), BSOD dump (blue screen of death), EDID (Extended Display Identification Data), PCIE_Device (Peripheral Component Interconnect Express, a high-speed serial computer extension bus standard), PCI Express devices, devices conforming to the PCI Express standard, SMBIOS (System Management Basic Input / Output System), Shutdown ID (a unique identifier generated during system or device shutdown), specific hardware modules such as P80, IOdata (input / output data), and event log (program time), etc. In implementation, during task execution, the RPA agent can retrieve the data packet content of the corresponding task, collect parameters, and issue key instructions based on the collected fault parameters to determine whether a fault has occurred, perform fault detection, determine the cause of the fault, and output a solution to resolve the fault.

[0114] The following is a list of possible fault types:

[0115] Type 1) BSOD (Blue Screen of Death)

[0116] In this type, a BSOD occurs due to a violation of policy rules by the kernel or driver, or due to system protection. In this case, fault parameters such as 0x3 Driver IRP error: driver holding indicate no response. When the RPA agent obtains this fault parameter, it determines that the current fault type is BSOD, identifies the fault as occurring in the kernel or driver, and retrieves the corresponding fault data for the kernel or driver.

[0117] BSOD can be triggered by the following rules:

[0118] 1a) Protection rule: When low-privileged code directly accesses high-privileged code and data (such as when some security software modifies drivers through user space), a BSOD will be triggered;

[0119] 1b) Exception handling: When a program encounters an exception, if the program itself does not have a complete exception handling loop, the system will start the interrupt-first mechanism when it receives the exception. Therefore, if there is a problem with the program design, it may also trigger a blue screen (some blue screens caused by drivers are due to the lack of a proper exception handling loop).

[0120] 1c) IRQL: The SDK (Software Development Kit) and WDK (Windows Driver Kit) call kernel parameters that are only called at a specific IRQL (Interrupt ReQuest Level). That is, the kernel parameters called by the WDK can only be used when a specific CPU interrupt request occurs. If the call is initiated before the interrupt request occurs, BSOD will be triggered.

[0121] During implementation, you can determine whether a blue screen has occurred using the following methods:

[0122] Method 1a) Read the BOSD code based on the system status;

[0123] In practice, the BOSD code can be read by the RPA agent to determine whether a blue screen error has occurred.

[0124] Method 1b) can determine the current screen status by using an external camera in conjunction with OpenCV algorithms or OCR models.

[0125] In practice, the RPA agent can acquire images captured by an external camera, and use OpenCV algorithm or OCR model to perform image recognition to determine whether a blue screen has appeared on the current screen.

[0126] Type 2) Black Screen

[0127] In this type, fault parameters include, but are not limited to: processor parameters such as setup CPU speed (processor operating speed under specific conditions), BIOS code, etc. When the RPA agent obtains this fault parameter, it determines the current fault type as a black screen.

[0128] Type 3) Force shutdown of the computer (Shutdown, Auto S3 or S4). Auto S3 or S4 means that the computer automatically enters hibernation state S3 or suspension state S4 during the debugging process.

[0129] In this type, fault parameters include, for example, shutdown ID 0X06: EC power reset. When the RPA agent obtains this fault parameter, it determines that the current fault type is forced shutdown of the computer.

[0130] Type 4) Lag (frame skipping) / Hang up (the program or process stops responding or hangs during execution), Flickers (screen flickering) / Garbage (memory storing useless data);

[0131] In this type, for example, an RPA agent can check the task manager to determine if any process has stopped responding or has excessive CPU / RAM (Random Access Memory) usage. When it is determined that a process has stopped responding or has excessive CPU / RAM usage, the current fault type is determined to be Hang up.

[0132] Type 5) No Function (The program is missing one or more necessary function definitions);

[0133] In this type, the RPA agent can determine whether there is a scan code and whether the code value is correct by pressing the KB (computer hardware keyboard) key.

[0134] Type 6) Preload Error (An error occurred while preloading resources);

[0135] In this type of error, such as a missing Driver backup folder, the RPA agent can check c:\windows\process.log or BMOD.log to confirm whether the Driver backup was executed. If it was executed, check if it was accidentally deleted; if it was not executed, check if the backup script was written correctly. Based on the error parameters captured by the RPA agent, the current error type is determined to be Preload Error.

[0136] Step b: Determine the first intelligent agent corresponding to the debugging task;

[0137] Step c: Using the first intelligent agent, execute the task content corresponding to the debugging task based on the fault data, and output the debugging results.

[0138] In some embodiments, the task content corresponding to the debugging task includes software and hardware simulation debugging; the debugging result includes at least one fault solution; this embodiment can output the debugging result in the following manner:

[0139] Using the first intelligent agent, software and hardware simulation debugging is performed based on the fault data to verify the fault solution and output at least one fault solution that has passed the verification.

[0140] In implementation, when the task type is software and hardware simulation debugging, after acquiring fault data using RPA, when it is determined that a fault has occurred based on the fault data, the first intelligent agent can perform software and hardware simulation debugging and fault solution verification based on the fault data, thereby determining the cause of the fault and outputting the verified fault solution. Optionally, the debugging results in this implementation include, but are not limited to, information such as the cause of the fault, the location of the fault, and the solution to the fault.

[0141] In some embodiments, when the task type is a debugging task, this embodiment automates the debugging task through the following steps:

[0142] The RPA agent invokes a first agent, which in turn triggers the first agent to perform software and hardware simulation debugging based on the fault data and outputs the debugging results; wherein the debugging results include at least one fault solution.

[0143] In some embodiments, before the RPA agent calls the first agent to trigger the first agent to perform software and hardware debugging based on the fault data, this embodiment may also use the RPA agent to call the AI ​​model to trigger the AI ​​model to determine at least one fault solution based on the fault data; then the debugging result is determined through the following process:

[0144] The RPA agent invokes the first agent, triggering the first agent to perform software and hardware simulation debugging based on the fault solution.

[0145] In implementation, the first agent in this embodiment is used to perform software and hardware simulation debugging, thereby verifying fault solutions and outputting at least one verified fault solution. After acquiring fault data using the RPA agent, when it is determined that a fault has occurred based on the fault data, the RPA agent calls the AI ​​model, inputs the fault data into the AI ​​model, triggers the AI ​​model to parse the fault data, determines the fault type, the cause of the fault, and the solution to the fault, and outputs at least one fault solution.

[0146] In implementation, the RPA agent calls the AI ​​model, inputs fault data into the AI ​​model, outputs at least one fault solution, and the RPA agent calls the first agent, inputs the fault solution into the first agent for software and hardware simulation debugging, verifies the fault solution, and outputs the verified fault solution.

[0147] It should be noted that after the AI ​​model outputs a fault solution, the fault solution still needs to be debugged and verified to determine whether the fault solution can truly solve the fault. When the fault solution can solve the fault, the fault solution is verified and the fault solution at this time is output as the optimal solution.

[0148] In some embodiments, fault solutions are automated in the following ways:

[0149] The RPA agent is used to call the RAG (Retrieval-Augmented Generation) model, which uses the RAG model to convert the fault data into prompts required for the AI ​​model input.

[0150] The RPA agent invokes an AI model to determine at least one fault solution corresponding to the prompt word.

[0151] Optionally, based on the RAG knowledge base, the fault data is converted into fault prompt information using the RAG model; wherein the RAG knowledge base is obtained by updating the fault data.

[0152] In implementation, the RPA agent calls the RAG model to generate the prompts required for AI model inference. The RAG model stores fault data in vector form in the database, converting the fault data into a format easily processed by the AI ​​model. The converted fault prompts are then input into the AI ​​model for matching, and corresponding fault solutions are output.

[0153] Optionally, this embodiment also provides a RAG knowledge base based on RAG technology. This knowledge base can convert fault data into fault indication information and store fault data or key fault parameters involved in the software and hardware simulation debugging process into the RAG knowledge base (vector database) for subsequent reference by the RAG model (deep learning). The database of the intelligent agent is updated based on the RAG knowledge base, and the updated database is used to improve the learning capabilities of the RAG model and the first intelligent agent. That is, the database includes, but is not limited to, the RAG knowledge base. For example, in the software and hardware simulation debugging process for blue screen faults, when the fault type is determined to be a blue screen fault, the fault parameters corresponding to the blue screen fault, such as the blue screen code, graphics card model, and corresponding driver data, are updated in the RAG knowledge base.

[0154] In some embodiments, this embodiment may also trigger the first intelligent agent to perform software and hardware simulation debugging according to the fault solution through the following steps:

[0155] Using the first intelligent agent, the fault solution is divided into multiple sub-solutions according to the execution steps of the fault solution, and the multiple sub-solutions are simulated and debugged in software and hardware in sequence.

[0156] In practice, to facilitate rapid verification of fault solutions during debugging, fault solutions can be broken down and verified sequentially according to the debugging process of each sub-solution. This facilitates the implementation, debugging, and verification of fault solutions and improves the efficiency of debugging and verification.

[0157] In practical applications, the root cause of a fault can be quickly located based on the acquired fault data, solutions can be provided from multiple perspectives, and a complete list of process steps for the solution can be generated. With sufficient permissions, the operating status of each module of the system can also be monitored, truly forming a closed-loop intelligent debugging chain of monitoring, discovery, analysis, location, solution and summary.

[0158] In implementation, when a device malfunctions (such as test interruption), the RPA agent can first determine if a BSOD (Blue Screen of Death) has occurred, with the blue screen code being 0x9F BSOD. This can be determined by checking for keywords like "bugcheck" in the event log and the existence of a BSOD dump. The RPA agent then uses WinDbg Tool (a user-space and kernel-space debugging tool) to obtain fault data. For example, the RPA agent can use the `!analyze -v` command to obtain detailed dump information. Importantly, the command `!devnode ffffe0000741ac70` pushes device anomaly information. The RPA agent can further examine the detailed error device using this command. Based on the path pushed by amdkmdap, the RPA agent can see that it points to a specific PCI 4ID device. At this point, the RPA agent can confirm that it is an AMD device blue screen error. In implementation, the RPA agent can also use the RAG model to convert the fault data into prompt words, confirming the fault type as BSOD.

[0159] When a blue screen occurs, the RPA agent first searches for a dump file (a memory image of the process) at a specified location. It then calls the Windbg tool (a user-mode and kernel-mode debugging tool) to search the database for and extract parameters based on different BSOD codes, obtaining the most reliable pointing file. Next, using known cases in the database and the pointing file, the RPA agent calls the AI ​​model and the first agent to obtain and output the final fault solution. The RPA agent can call the Windbg tool, using commands such as `analyze -v` to obtain detailed dump information. It also retrieves AI model information (i.e., the large input model) from its own uploaded database and associated websites such as ";SRV*d:\Symbols*http: / / msdl.microsoft.com / download / symbols", and can call tools to obtain fault data, outputting the approximate fault range, for example, indicating a kernel fault.

[0160] Windbg, a source-level debugging tool released by Microsoft, can be used for kernel-mode and user-mode debugging, and can also debug dump files. Windbg is a crucial diagnostic and debugging tool from Microsoft, allowing users to view source code, set breakpoints, view variables, and examine the call stack and memory usage. A dump file is a memory image of a process; the debugger saves the program's execution state to a dump file. When Windows encounters a crash, it uses the dump system to create a dump file (*.dmp), which can be found, for example, in C:\\windows\system32.

[0161] Optionally, this embodiment may also provide a UI interface, which responds to the debugging information input by the user in the UI interface, uses a large language model in the intelligent agent to identify the debugging information input by the user, and obtains fault data based on the identification results.

[0162] It should be noted that the software development method provided in this embodiment is based on a system architecture of multiple intelligent agents and at least one deep learning model. In this embodiment, RPA agents are used to invoke different task agents, which in turn implement the functions of different tasks in the development process. An AI model is used to reason about fault data to obtain at least one fault solution. A large language model is used to perform semantic recognition on the input data (text, images, or speech, etc.), outputting data (such as binary data) that can be recognized by the task agents, RPA agents, or devices. This embodiment's method for automating the development process requires the use of RPA agents, task agents, AI models, and large language models. It integrates image recognition, speech recognition, or natural language processing, utilizing advanced algorithms and AI models to parse input data and generate accurate output. Based on deep learning technology, artificial intelligence, and process automation, the different roles of AI models, large language models, RPA agents, and task agents are used to jointly achieve the automation of the development process.

[0163] As shown in Figure 2, this embodiment provides a schematic diagram of an automated software and hardware testing process. The intelligent agent includes a UI interface, through which users can input debugging tasks. For example, users can input debugging tasks through command-line mode or interactive window mode. The RPA intelligent agent calls a large language model to parse the user-input debugging tasks, obtains fault data based on the parsing results, and uses RAG technology to convert the fault data into fault prompt information. When using RAG technology for data conversion, data in a vector database can be referenced to improve the accuracy of data conversion. For example, the vector database stores open-source materials, internal materials, and specified databases. The output debugging results can also be stored in the vector database; for example, data such as the inference process, execution steps, and debugging results can be updated in the vector database to improve the accuracy of large model inference. The RAP agent calls the AI ​​model's API, inputting fault prompts into the first agent. This triggers the AI ​​model to perform large-scale inference, yielding the inference result (fault solution). The inference result is broken down into multiple execution processes, for example, inference result A → inference result B → inference result C. The RAP agent then calls the first agent to debug and provide feedback based on the inference result. On one hand, the analysis results, inference results, and execution processes of the debugging task are recorded in a vector database (which can be local or cloud-based). On the other hand, based on the inference result, the RAP agent calls the first agent to perform debugging and verification on the debugging device. The first agent provides feedback on the execution results, including analysis of certain issues during the debugging and verification process, experimental results, and user-inputted debugging parameters via a UI interface, updating the inference result (i.e., the fault solution). The first agent executes the inference results sequentially until a correct result is determined, at which point the verified fault solution is output.

[0164] As shown in Figure 3, this embodiment provides an automated process for software and hardware simulation debugging, taking a blue screen as an example, as follows:

[0165] Step 300: Use the RPA agent to obtain the blue screen code;

[0166] In practice, Windows experiences a Blue Screen of Death (BSOD) with the blue screen code "DRIVER_POWER_STATE_FAILURE". A blue screen error (sometimes called a black screen error or termination code error) occurs when a failure causes Windows to shut down or restart unexpectedly. You might see a message stating "Windows has shut down to prevent damage to your computer" or something similar. In practice, when a blue screen occurs, the system stores a log in a fixed location within the operating system, which the RPA agent can automatically retrieve.

[0167] Step 301: The RPA agent locates the current fault type based on the captured current fault parameters;

[0168] For example, the RPA agent can identify the current fault type as a power failure based on the captured current fault parameters "0x9F" or "DRIVER_POWER_STATE_FAILURE".

[0169] Step 302: The RPA agent locates the location of the fault based on the current fault type;

[0170] During implementation, the Windbg tool is used to view the dump file based on the current fault type, and the location of the fault is located based on the dump file;

[0171] For example, if the input fault parameter is DRIVER_POWER_STATE_FAILURE, it indicates that the fault type is power supply-related, meaning there is a power supply failure. In this case, the RPA agent calls the corresponding processing tool Windbg to view the dump file. The dump file contains system kernel information and dump user information (indicating the operations performed by the user before the fault occurred). The dump information cannot be viewed directly; it requires the use of Windbg. Based on the output fault data (such as debugging parameters and commands) from the dump file, the location of the fault can be determined.

[0172] Optionally, the fault type in this embodiment is determined based on the kernel type. For example, the fault type includes, but is not limited to, power failure, kernel failure, and device failure.

[0173] The relevant kernel functions are listed below:

[0174] nt! lnbvResetDisplay

[0175] nt! lnbvSolidColorFill

[0176] nt! lnbvSetTextColor

[0177] InbvDisplayString

[0178] Step 303: The RPA agent calls the first agent, inputs the fault data into the first agent for task parsing, and obtains the fault to be solved and key information.

[0179] For example, the first intelligent agent analyzes the fault data and finds that the fault with the blue screen code "0x9F" is resolved. The key information is "IRP_MN_SET_POWER" (power-related fault) and "Physical Device Object" (physical device fault).

[0180] Step 304: Based on the parsed content, the RPA agent calls the RAG model to generate prompts for model inference;

[0181] In implementation, RAG technology outputs prompts based on the RAG knowledge base. The RAG knowledge base stores user-uploaded interface commands, model training records, or training records using help commands, such as `!analyze`, `!action`, and `!running`. The RAG knowledge base stores at least one optimal debugging result output by the first agent. Optionally, specific requirements can be obtained via `!Mex.help`. Known commands are categorized and embedded in the RAG knowledge base for prompts to use. The RAG knowledge base can retrieve and generate prompts from data commands and other information, improving the accuracy of AI model inference. This achieves production and delivery standards, considering accuracy, resource utilization, and other factors.

[0182] The complete RAG application process mainly includes two stages, as shown below:

[0183] (1) Data accuracy stage;

[0184] The specific steps performed at this stage are: data extraction → chunking → embedding → data storage.

[0185] (2) Retrieval generation stage;

[0186] The specific steps at this stage are as follows: Question vectorization → Query matching data based on the question → Obtain index data → Inject the data into the Prompt (hint word) → LLM generates the answer.

[0187] Step 305: Use the RPA agent to call the AI ​​model for large-scale model inference, input the prompt words into the AI ​​model, and output one or more corresponding fault solutions;

[0188] Step 306: Use the RPA agent to call the first agent, triggering the first agent to break down the fault solution into multiple sub-solutions according to the operation steps, implement the multiple sub-solutions, and verify the multiple sub-solutions after debugging.

[0189] Step 307: Determine whether the verified fault solution is effective through automatic or human-computer interaction. If it is effective, stop or continue to select a better fault solution. If it is ineffective, continue to verify the next fault solution.

[0190] Step 308: Record and store the key processes of fault judgment, first agent analysis, reasoning and output of fault solutions in the database for analysis when faults occur in the future.

[0191] Optionally, key processes include, but are not limited to, the contents of steps 300-307 above. Optionally, the database includes the RAG knowledge base, which can be deployed on a local server or a cloud server.

[0192] This embodiment allows for the updating and accumulation of the RAG knowledge base, improving the effectiveness of deep learning. It stores information related to new platforms, industry standards, and project releases in the RAG knowledge base. For example, BIOS project development is based on a large codebase, which is frequently upgraded, sometimes bringing new functional modules and architectural updates. This code needs to be stored in the RAG knowledge base for AI model learning. Some software tools are continuously iterated and updated, or upgraded based on new projects and platforms; these updates can also be stored in the RAG knowledge base. This pre-training and deep learning need to be completed before development. When EC chips are changed, new industry standards are released, or new projects are launched, the changes are added to the RAG knowledge base for AI model deep learning. The basic codebase of the same EC chip remains largely unchanged; using the AI ​​model and RAG knowledge base, new feature development and customized modifications can be achieved. Furthermore, customization, integration, and release based on Microsoft operating systems, language packs, device drivers, and applications are possible; continuous learning of Windows Policy, continuous driver updates, and version control are supported; driver and app installation and uninstallation verification, and log capture are also possible.

[0193] This embodiment can solve a series of problems in traditional equipment debugging, such as complicated tool interfaces, time-consuming environment setup, insufficient manufacturer support, and heavy reliance on experience for a large amount of new industry information, standards and platforms before development.

[0194] The training data for the agent in this embodiment includes, but is not limited to, R&D data (code), design data (circuit diagrams, etc.), and test data. The agent in this embodiment is obtained by fine-tuning an open-source large model, such as fine-tuning based on the LoRa framework. After fine-tuning, a multi-model (text, logical reasoning, image analysis, etc.) collaboration approach is adopted.

[0195] In some embodiments, the intelligent agent in this embodiment includes an RPA intelligent agent and a task intelligent agent, which can be deployed in any of the following ways:

[0196] The agent is deployed locally; or,

[0197] The intelligent agent is deployed on a cloud server; or,

[0198] Some agents are deployed locally, while the others are deployed on cloud servers.

[0199] In some embodiments, this embodiment can obtain task data in any of the following ways:

[0200] Retrieve task data corresponding to the task type from the local database; or,

[0201] Retrieve task data corresponding to the task type from the cloud server; or,

[0202] Retrieve partial task data corresponding to the task type from the local database, and retrieve other task data besides the partial task data from the cloud server.

[0203] Optionally, a combined edge-cloud approach can be adopted. Small models for simple tasks are deployed locally, connected to the task machines via a server and a local area network for task distribution and management. The server architecture uses a client-server (CS) and web-server (BS) architecture, with a middleware server providing security protection. The client sets up a small edge-side model. The RPA agent sends a server (service) to the client at the start of the task, and debug (first agent) and other edge-side tools are used. The APIs of each agent and the edge-side model are utilized to achieve automated software development. The cloud (server) supplements local computing power and provides support for design modules. Optionally, small models for simple tasks, such as RPA agents, can be deployed locally, while larger models, such as AI models or large language models, can be deployed in the cloud.

[0204] The intelligent agent in this embodiment can also produce and provide services, such as providing production testing, interfacing with MES (Manufacturing Execution System), recording and analyzing production testing issues, and deploying random AI problem analysis models. It can perform testing, data management, and problem analysis. It can also collect user experience data, output suggested solutions, produce software user manuals and other documents, and conduct post-production reviews of product design and debugging (collecting feedback from clients).

[0205] This embodiment involves product development and design training: database training of project development data, boot software and porting modules, checklist data and development, protection of hardware and software simulation debugging modules, SMT boot debugging, verification and debugging of GPIO and other boot configurations, real-time generation of boot software re-flashing, data training of production and service-oriented problem recording modules, deployment of random AI problem analysis models and other data feeding, output of corresponding design requirements, and resolution of process issues such as training fine-tuning. This embodiment uses natural language or interactive description of the goal, and the AI ​​model, combined with the intelligent agent and context, can understand the requirements and goals of the development task; for example, it can find input differences (modifying power-on / power-down codes based on hardware timing diagram changes) and modify the corresponding BIOS / EC codes; it can directly generate computer preload packages by changing drivers. It can also perform corresponding code management, online debugging and other tasks, and provide corresponding results for engineers' reference.

[0206] As shown in Figure 4, this embodiment provides a UI interactive interface process management diagram. Development tasks can be input into the RPA agent through the UI interactive interface. After receiving the development task, the RPA agent calls the tool library to parse the development task, obtaining the corresponding task data. The RPA agent then calls the agent corresponding to the development task to parse the task data and obtain the parsed content. Based on the RAG knowledge base, the parsed content is converted into prompt words, which are then input into the AI ​​model (large model) for inference, outputting the inference results. Users can feed data through the interactive interface, following the transform (large model) architecture rules, and output user-required design / verification results according to the prompt words.

[0207] Optionally, users can also input rules, actions, goals, and other information corresponding to the development task through the UI interface, utilize the RPA agent to call the LLM for semantic parsing, and input the parsing results into the agent. Below is an example of inputting a development task:

[0208] (1) Configure GPIO 3 as Input;

[0209] (2) Change PCIe Port2 in Intel ME to USB Gen3.2;

[0210] (3) Modify Audio to support BT and USB offlod;

[0211] (4) Configure GPIO and power-on timing;

[0212] (5) Create a system package that supports Chinese and English languages;

[0213] (6) Analysis of problems such as black screen and blue screen in the scene.

[0214] The tool library represents the collection of vendor tools used in the design, including tools for design, coding, and verification; examples include IBV editing tools, IBV compilation environments, SOC vendor tools such as Intel, VBIOS (Video BIOS), GOP (Graphics Output Protocol) tools, SVN (Subversion) code tools, burning tools, and preload creation tools. The RAG knowledge base stores data such as hardware and software specifications, software design manuals, code repositories, hardware design materials, product specifications, testing standards, PC industry standards, and OS design strategies.

[0215] As shown in Figure 5, this embodiment also provides a software development architecture diagram, including an intelligent agent set, an interaction management module, a tool library, and a development resource module. In implementation, after the user inputs a development task (rules, actions, goals, etc.), a parser is used to perform semantic parsing to create a parser object. Parameters are added, parsed, and redundant events are removed. The result is then output, allowing developers to quickly identify and fix problems, improving the system's reliability and stability. It should be noted that the user-input development task can also be an automatically generated task by an RPA intelligent agent. The RPA intelligent agent determines the current development task based on the acquired task data. The intelligent agent set includes an RPA intelligent agent and at least one task intelligent agent.

[0216] In implementation, following the parser usage architecture, the Python input / output paths are set. The argparse module provides an easily written command-line interface, where the constructor calls keywords to push parameters to the argument function, which parses the parameters (generally, an object is first created to parse the command line into the information required by Python data types). argparse automatically generates notices; when the user passes invalid parameters, an error is reported, and the Python interpreter also calls pring_help(). The intelligent agent set can intelligently switch between and call intelligent agents, including intelligent agents with different functions such as BIO (Basic Input / Output System), EC (Programming Language), drivers, preload systems, debug, and hardware porting on the development side. The tool library represents the collection of vendor tools used in the design, including design, code, and verification tools. The development resource module represents the development and debugging machine's connection to the database server interface according to its physical address; the database has an interface for adding and uploading documents.

[0217] As shown in Figure 6, this embodiment also provides a system architecture for intelligent agent task processing, including a storage module, an execution module, a task creation module, a task confirmation module, and a task priority determination module. In implementation, development tasks can be sent through a UI interface or actively acquired by an RPA agent. After acquiring a development task, the execution logic is as follows: Send development task → Task creation module → Add task → Execution module executes task → Task execution completes → Retrieve task matching degree from the database of the storage module based on context semantics → Task confirmation module confirms task. Alternatively, the following process can be executed: User submits task to be processed → Add task → Task confirmation → Task priority (task priority determination module) → Task confirmation.

[0218] As shown in Figure 7, this embodiment also provides a software development model framework based on the deep learning transform framework. It can utilize Microsoft API interfaces to link different configurations, fine-tune training based on open-source models according to user needs, debug data content via database links, and utilize a hardware NPU (Neural Processing Unit) accelerator without consuming system resources. The Debug(name, program, $file, args, pickArgs, specify virtual environment) function in VS Code (Software Developer Tools) has the following parameters: env = lmdb.open(), indicating the creation of an lmdb environment; Txn = env.begin(), indicating the establishment of a transaction; Configurations, an array containing all debug configurations; Name, the name of the debug configuration, distinguishing different debug configurations in VS Code; Program, the path to the program to be debugged; args, an array of command-line arguments passed to the program; and Type, the type of debugger (e.g., phthon or debugpy). For example, in the debug case, specifying the "program" keyword means that debugging directly targets the train.py file, while the "python" keyword directly specifies the path to the Python file being used.

[0219] As shown in Figure 8, this embodiment also provides a schematic diagram of the hardware framework for underlying software development, including a storage subsystem, a processor, a network interface, a user interface / output device, and a user interface / input device. Developed using the deep learning transform framework, it can connect to different configurations via Microsoft API interfaces. The model is fine-tuned and trained according to user needs using open-source models. Database connections allow for data content debugging, and the hardware NPU accelerator does not consume system resources. The test device connects to the server via the network interface. The processor calls the SOC NPU accelerator. Erasable data is stored in ROM, while non-erasable data, including resource calls, task processing priority flows, and large model scheduling interfaces, is stored in RAM. The file storage subsystem can be switched according to different intelligent agents.

[0220] This embodiment can perform fine-tuning training of open-source models based on training data, and automate the boot software and porting modules. It can also automate the software and hardware simulation debugging, including SMT boot debugging, verification and debugging of boot configurations such as GPIO / Sequence, and real-time generation of boot software for re-flashing. It can also record problems in production and service, such as product testing, MES system integration, production testing problem recording and analysis, and deployment of random AI problem analysis models.

[0221] Based on the same inventive concept, this disclosure also provides an electronic device. Since this electronic device is the same as the electronic device in the method of this disclosure, and the principle of solving the problem by this electronic device is similar to that of this method, the implementation of this electronic device can refer to the implementation of the method, and the repeated parts will not be described again.

[0222] As shown in Figure 9, the electronic device includes a processor 900 and a memory 901. The memory 901 is used to store programs executable by the processor 900. The processor 900 is used to read the programs in the memory 901 and perform the following steps:

[0223] Using RPA agents, task data corresponding to at least one task type is obtained. The RPA agents are used to automate the underlying software development process, and different task types are used to represent different tasks in the underlying software development process.

[0224] Determine the task agent corresponding to the task type;

[0225] Using the task agent, the task content corresponding to the task type is executed according to the task data to obtain the task execution result.

[0226] Based on the same inventive concept, this disclosure also provides an apparatus for low-level software development. Since this apparatus is the same as the apparatus in the software development method, and the principle of the apparatus in solving the problem is similar to that of the method, the implementation of the apparatus can refer to the implementation of the method, and the repeated parts will not be described again.

[0227] As shown in Figure 10, the device includes:

[0228] The data acquisition unit 1000 is used to acquire task data corresponding to at least one task type using an RPA agent, wherein the RPA agent is used to automate the underlying software development process, and different task types are used to represent different tasks in the underlying software development process.

[0229] The agent determination unit 1001 is used to determine the task agent corresponding to the task type;

[0230] The task execution unit 1002 is used to execute the task content corresponding to the task type according to the task data using the task agent, and obtain the task execution result.

[0231] Based on the same inventive concept, this disclosure provides a computer storage medium comprising: computer program code, which, when executed on a computer, causes the computer to perform any of the software development methods described above. Since the principle by which the computer storage medium solves the problem is similar to that of the software development method, the implementation of the computer storage medium can be referred to the implementation of the method, and repeated details will not be elaborated further.

[0232] In specific implementation, computer storage media can include: Universal Serial Bus Flash Drive (USB), portable hard drive, Read-Only Memory (ROM), Random Access Memory (RAM), magnetic disk or optical disk, and other storage media that can store program code.

[0233] Based on the same inventive concept, this disclosure also provides a computer program product, which includes computer program code that, when run on a computer, causes the computer to execute any of the software development methods discussed above. Since the principle by which the above-described computer program product solves the problem is similar to that of the software development method, the implementation of the above-described computer program product can be referred to the implementation of the method, and repeated details will not be elaborated further.

[0234] Computer program products may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable 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 thereof.

[0235] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

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

[0237] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction device that implements the functions specified in one or more flowcharts and / or one or more block diagrams.

[0238] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0239] Obviously, those skilled in the art can make various modifications and variations to this disclosure without departing from its spirit and scope. Therefore, if such modifications and variations fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include such modifications and variations.

Claims

1. A software development methodology, wherein, The method includes: Using RPA agents, task data corresponding to at least one task type is obtained. The RPA agents are used to automate the underlying software development process, and different task types are used to represent different tasks in the underlying software development process. Determine the task agent corresponding to the task type; Using the task agent, the task content corresponding to the task type is executed according to the task data to obtain the task execution result.

2. The method according to claim 1, wherein, The method also includes: Use RPA agents to obtain the task types of tasks in the development process; and / or, In response to task information entered by the user through the UI, obtain the task type of the task in the development process.

3. The method according to claim 1, wherein, The step of using the task agent to execute the task content corresponding to the task type according to the task data includes: Using the RPA agent, the task agent corresponding to the task type is invoked; The task agent is triggered to execute the task content corresponding to the task type, and the task execution result is obtained.

4. The method according to claim 1, wherein, The task types include debugging tasks; The task data corresponding to the debugging task includes fault data; The task agent includes a first agent; the method includes: The RPA agent is used to acquire fault data; Determine the first intelligent agent corresponding to the debugging task; Using the first intelligent agent, the task content corresponding to the debugging task is executed according to the fault data, and the debugging result is output.

5. The method according to claim 4, wherein, Fault data can be obtained through one or more of the following methods: The RPA agent detects a fault and acquires the fault data for the current fault; or, According to a preset cycle, the RPA agent acquires fault data for at least one type of fault; or, It retrieves fault data in response to fault information entered by the user through the UI interface.

6. The method according to claim 4, wherein, The storage location of the fault data is determined according to the fault type; different fault types have different storage locations. The process of acquiring fault data using the RPA agent includes: The RPA agent is used to retrieve fault data from storage locations corresponding to at least one fault type.

7. The method according to claim 4, wherein, The process of acquiring fault data using the RPA agent includes: The RPA agent is used to acquire fault parameters, and the fault type is determined based on the fault parameters, wherein the location of the fault occurs in different fault types; The RPA agent is used to determine the location of the fault based on the fault type, and the fault data corresponding to the location is obtained.

8. The method according to claim 4, wherein, The debugging task includes software and hardware simulation debugging; the debugging result includes at least one fault solution. The step of utilizing the first intelligent agent to execute the task content corresponding to the debugging task based on the fault data and output the debugging result includes: Using the first intelligent agent, software and hardware simulation debugging is performed based on the fault data to verify the fault solution and output at least one fault solution that has passed the verification.

9. The method according to claim 8, wherein, The step of using the first intelligent agent to perform software and hardware simulation debugging based on the fault data includes: The RPA agent invokes the AI ​​model, triggering the AI ​​model to determine at least one fault solution based on the fault data. The RPA agent invokes the first agent, triggering the first agent to perform the following actions based on the fault. The troubleshooting solution performs software and hardware simulation debugging.

10. The method according to claim 9, wherein, The step of using the RPA agent to invoke the AI ​​model, triggering the AI ​​model to determine at least one fault solution based on the fault data, includes: The RPA agent invokes the RAG model, and the RAG model converts the fault data into prompts required for the AI ​​model input. The RPA agent invokes an AI model to determine at least one fault solution corresponding to the prompt word.

11. The method according to claim 9, wherein, The step of triggering the first intelligent agent to perform software and hardware simulation debugging according to the fault solution includes: Using the first intelligent agent, the fault solution is divided into multiple sub-solutions according to the execution steps of the fault solution, and the multiple sub-solutions are simulated and debugged in software and hardware in sequence.

12. The method according to claim 1, wherein, The task type includes software development tasks; the task data corresponding to the software development tasks includes development data; the task agent includes a second agent; the method includes: Use RPA agents to acquire development data; Determine the second intelligent agent corresponding to the software development task; The second intelligent agent is used to execute the software development tasks based on the development data.

13. The method according to claim 12, wherein, The software development tasks include generating underlying software code; the execution of the software development tasks using the second intelligent agent based on the development data includes: Using the second intelligent agent, underlying software code is generated based on the development data. This underlying software code is used to perform hardware initialization and guide the operating system to complete the startup process.

14. The method according to claim 13, wherein, The step of using the second intelligent agent to generate underlying software code based on the development data includes: The RPA agent invokes the second agent, triggering the second agent to generate underlying software code based on the development data.

15. The method according to claim 12, wherein, The acquisition of development data using RPA agents includes: The RPA agent is used to invoke a large language model, which triggers the large language model to perform semantic recognition on the development data, thereby obtaining hardware data and basic code. The hardware data and basic code are identified as the development data.

16. The method according to claim 1, wherein, The task type includes driver configuration tasks; the task data corresponding to the driver configuration tasks includes driver data. The task agent includes a third agent; the method includes: The RPA agent is used to acquire driving data; Determine the third agent corresponding to the drive configuration task; The third intelligent agent is used to execute the task content corresponding to the driver configuration task based on the driver data.

17. The method according to claim 16, wherein, The task content corresponding to the driver configuration task includes driver loading and adaptation; the step of using the third intelligent agent to execute the task content corresponding to the driver configuration according to the driver data includes: Using the third intelligent agent, the adapted driver is loaded into the operating system based on the driver data.

18. The method according to claim 17, wherein, The step of using the third intelligent agent to load the adapted driver in the operating system according to the driver data includes: The RPA agent invokes a third agent, which in turn triggers the third agent to load the adapted driver in the operating system based on the driver data.

19. The method according to claim 1, wherein, Intelligent agents include RPA intelligent agents and task intelligent agents; the method also includes: The agent is deployed locally; or, The intelligent agent is deployed on a cloud server; or, Some of the intelligent agents are deployed locally, while others are deployed on cloud servers.

20. The method according to claim 1, wherein, The step of obtaining the task data corresponding to the task type includes: Retrieve task data corresponding to the task type from the local database; and / or, Retrieve task data corresponding to the task type from the cloud server.

21. An electronic device, wherein, The electronic device includes a processor and a memory, the memory being used to store a program executable by the processor, and the processor being used to read the program in the memory and execute the steps of the method according to any one of claims 1 to 20.

22. A computer storage medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1 to 20.

Images