Multi-agent dynamic adjustment method and device based on SSD architecture

Abstract

This invention relates to the field of tactile sensing technology, specifically to a method and apparatus for dynamic adjustment of multiple agents based on an SSD architecture. This dynamic adjustment method achieves role-level minimum permission isolation by constructing a multi-layered permission model for agent roles, including an identity layer, a capability layer, and a task layer; dynamically adjusts a whitelist based on delivery documents to restrict permissions; generates four-layer concatenated system prompts to control context input; and acquires real-time status change information and execution anomaly information for executed tasks, performing layered anomaly self-healing processing based on anomaly type. This application can solve the technical problems of lack of role-level permission isolation, unobservable execution status, and missing anomaly handling mechanisms in multi-agent collaboration.

Description

Technical Field

[0001] This invention relates to the field of multi-agent collaboration and software development automation technology, specifically to a method and apparatus for dynamic adjustment of multi-agents based on SSD architecture. Background Technology

[0002] In multi-agent collaborative systems based on large language models, multiple agents typically need to collaborate to complete a complex task. In existing technologies, agents often share the same or broad system permissions, lacking a fine-grained role-level permission isolation mechanism. This allows agents with different roles to potentially access or manipulate resources outside their scope of responsibility, especially at the file read / write level, easily leading to security risks and collaboration conflicts.

[0003] Meanwhile, existing systems typically employ uniform and simplistic handling methods (such as direct retries or abandonment) when faced with various anomalies during execution, lacking intelligent mechanisms for differentiated and hierarchical processing based on anomaly type. This not only reduces the success rate of task execution but also prevents the system from effectively repairing or protecting itself from business logic errors or persistent failures, leading to interruptions in automated processes and requiring frequent manual intervention.

[0004] Therefore, how to achieve role-based least privilege isolation in a multi-agent collaborative framework and build a mechanism that can intelligently analyze anomalies and execute corresponding repair strategies has become an urgent technical problem to be solved. Summary of the Invention

[0005] One of the objectives of this invention is to provide a method and apparatus for dynamic adjustment of multiple agents based on SSD architecture, in order to solve the technical problems of imprecise permission isolation and unintelligent exception handling mechanism in existing multi-agent systems, thereby realizing role-level dynamic permission control and system-level exception self-healing capability.

[0006] To solve the above-mentioned technical problems, the embodiments of the present invention are implemented as follows: Firstly, a method for dynamic adjustment of multi-agent systems based on an SSD architecture is provided, the steps of which include: Construct a multi-layered permission model for intelligent agent roles, wherein the multi-layered permission model includes an identity layer for the identity information of the intelligent agent, a capability layer for determining the permissions of the intelligent agent, and a task layer for determining the tasks of the intelligent agent; The delivery document is obtained, and the multi-layered permission model isolates the rights of each intelligent agent role according to the delivery document. The permission isolation is achieved by constraining identity through the identity layer, determining operation permissions through the capability layer, and determining the tasks to be executed through the task layer, so as to achieve the minimum permission isolation at the role level. Generate a four-layer concatenated system prompt based on isolation permissions, and execute the task based on the system prompt; Obtain real-time status change information and execution exception information of the task being executed, analyze the exception information, and execute corresponding repair strategies.

[0007] The second aspect also discloses a multi-agent dynamic adjustment device based on an SSD architecture, which includes: The model building module is used to construct a multi-layered permission model for intelligent agent roles. The multi-layered permission model includes an identity layer for the identity information of the intelligent agent, a capability layer for determining the permissions of the intelligent agent, and a task layer for determining the tasks of the intelligent agent. The rights isolation module is used to obtain delivery documents. The multi-layered permission model isolates the rights of each intelligent agent role according to the delivery documents. The permission isolation is achieved by using an identity layer to constrain identity, a capability layer to determine operation permissions, and a task layer to determine the tasks to be executed, so as to achieve the least-permission isolation at the role level. The task execution module is used to generate a four-layer concatenated system prompt based on isolation permissions, and execute tasks based on the system prompt. The anomaly repair module is used to obtain real-time status change information and execution anomaly information of the executed task, analyze the anomaly information, and execute corresponding repair strategies.

[0008] The beneficial effects of the above-described technical solutions provided in the embodiments of the present invention include at least the following: This invention discloses a method and apparatus for dynamic adjustment of multi-agent systems based on an SSD architecture. By constructing a multi-layered permission model comprising an identity layer, a capability layer, and a task layer, and isolating agent roles based on delivery files, the principle of least privilege at the role level is implemented from three levels: identity constraints, operational permissions, and task scope. This effectively prevents agents from exceeding their authority and solves the problem of permission chaos in existing technologies. Furthermore, through a mechanism for dynamically adjusting the whitelist, permissions can be dynamically adapted according to specific task objectives, achieving more refined permission control. By acquiring state changes and anomaly information in real time and triggering hierarchical repair strategies (such as retry, backflow, circuit breaking, etc.) based on anomaly types, the system can handle different types of faults in a differentiated and intelligent manner, significantly improving the system's robustness and self-healing ability in the face of various anomalies and reducing unnecessary manual intervention. In summary, this invention achieves precise dynamic isolation of permissions and intelligent hierarchical processing of anomalies, improving the security, reliability, and automation level of multi-agent systems.

[0009] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0010] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0011] Figure 1 A flowchart illustrating a multi-agent dynamic adjustment method based on an SSD architecture provided in this embodiment of the invention; Figure 2 This is a flowchart illustrating real-time dynamic modulation of the whitelist in an embodiment of the present invention; Figure 3 A flowchart for generating a whitelist in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the generation of a four-layer concatenated system prompt based on isolation permissions in an embodiment of the present invention. Figure 5 This is a flowchart illustrating real-time status change information in an embodiment of the present invention. Figure 6 This invention relates to a method and apparatus for dynamic adjustment of multiple agents based on an SSD architecture. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] In this application, the term "exemplary" is used to mean "used as an example, illustration, or illustration." Any implementation described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other implementations. The following description is provided to enable any person skilled in the art to implement and use this application. Details are listed in the following description for illustrative purposes. It should be understood that those skilled in the art will recognize that this application can be implemented without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the illustrated implementations, but rather to be consistent with the broadest scope of the principles and features disclosed in this application. In multi-agent collaborative systems based on Large Language Models (LLM), especially in automated software development pipelines, multiple agent roles with different responsibilities (such as requirements analysis, architecture design, coding, quality review, etc.) need to work collaboratively. However, since each agent essentially shares file access and API call permissions of the underlying system, it is easy for an agent of one role to exceed its authority by operating on files managed by other roles, leading to security risks and collaboration conflicts. Meanwhile, the system may encounter various types of exceptions during execution, such as API call failures, network anomalies, and business logic errors. Existing technologies lack targeted, layered automated handling mechanisms, often leading to task failures or requiring frequent manual intervention, resulting in insufficient robustness of the automated process. The technical solution provided in this application aims to solve the above problems.

[0014] Before describing the embodiments of the present invention in detail, the design concept of the present invention will be summarized below.

[0015] This invention provides a method for dynamic adjustment of multiple agents based on an SSD architecture, with the specific implementation details as follows. The core of this invention's concept includes: constructing a multi-layered permission model consisting of an identity layer, a capability layer, and a task layer, thereby achieving identity anchoring, permission convergence, and task focus for agent roles; using delivery documents as the basis for permission adjustment, ensuring both the capability layer whitelist and task layer inputs are dynamic and traceable; relying on a four-layer concatenated prompt mechanism, achieving role behavior constraints and task goal focus while ensuring contextual integrity; further combining real-time state probes and structured anomaly logs to form an observable foundation and anomaly response path; ultimately, without introducing new agents or changing the model itself, a secure, controllable, observable, and self-healing multi-agent collaborative execution environment is constructed, effectively solving the core defects of existing technologies such as ambiguous permission boundaries, chaotic context, invisible state, and coarse anomaly handling.

[0016] Based on the above inventive concept, please refer to the appendix for the first aspect. Figure 1 and 2The diagram also discloses a multi-agent dynamic adjustment method based on an SSD architecture, the steps of which include: steps S101, S102, S103 and S104.

[0017] Step S101: Construct a multi-layered permission model for agent roles. This multi-layered permission model includes an identity layer for agent identity information, a capability layer for determining agent permissions, and a task layer for determining agent tasks. This model provides a structured framework for subsequent permission isolation and behavioral constraints.

[0018] The Soul Layer can be defined as an identity constraint layer representing the essential attributes of an agent's role. It is a structured text file defining role positioning, behavioral guidelines, input / output specifications, and prohibitions. Its function is to establish an identity anchor for each agent role, ensuring that all subsequent operations use this identity as the logical starting point and that role behavior conforms to the preset positioning. The Skill Layer can be defined as an operation permission layer limiting the scope of operations an agent can perform. It is a set of read / write permissions implemented through a file path whitelist mechanism. Its function is to refine permission control to specific file paths, allowing agents to access only explicitly authorized resources within their scope of responsibility, thus supporting the principle of least privilege at the role level. The Directive Layer can be defined as a task input layer binding the agent's current pending task. It uses structured delivery files produced by upstream agents as the task input source. Its function is to cut off arbitrary cross-role call chains, ensuring that each agent only responds to upstream deliverables directly related to its responsibilities, achieving unidirectional task flow and decoupling of responsibilities.

[0019] This application, for example, loads identity definitions from pre-defined role-specific files in the identity layer and combines them with global rule files to form unified identity constraints; this application, for example, intercepts unauthorized read / write requests at the file system call entry point based on a path whitelist configured in the capability layer; further, this application automatically parses and injects task context parameters based on the delivery file path specified in the task layer. Based on any of the above methods, this application achieves identity anchoring, permission convergence, and task focus for intelligent agent roles, thereby constructing a three-layer decoupled, layer-by-layer constrained permission model foundation.

[0020] For example, during the initialization phase of the software development pipeline, separate SSD three-tier permission models are built for the roles of requirements analyst, architecture designer, coder, and quality reviewer. The requirements analyst role's identity layer includes a ban on generating code, a capability layer whitelist allowing reading only the project requirements document directory, and a task layer bound to the PRD delivery file provided by the upstream product manager. Similarly, the architecture designer role's identity layer includes a ban on modifying source code, a capability layer whitelist allowing reading the PRD directory and writing to the architecture design document directory, and a task layer bound to the delivery files output by the requirements analyst role.

[0021] Step S102: Obtain the delivery document. The multi-layered permission model isolates the rights of each intelligent agent role based on the delivery document. This permission isolation is achieved through identity constraints at the identity layer, operational permissions at the capability layer, and tasks at the task layer, thus realizing the least privilege isolation at the role level. This step, through constraints at three levels, ensures that each intelligent agent role can only access resources within its scope of responsibility, thereby solving the problem of permission confusion.

[0022] The delivery file can be a structured text file produced by an upstream agent that describes the current task objectives and constraints. It may contain a `TASK_ALLOCATION` table or a JSON Schema definition. Its purpose is to serve as the basis for dynamic permission adjustment, ensuring that the downstream agent's capability layer whitelist and task layer inputs both originate from a trusted upstream source, avoiding permission rigidity caused by static configuration. The identity constraints refer to the first semantic verification of all operation requests initiated by the agent based on the behavioral rules and prohibitions defined in the identity layer. Their purpose is to filter behavioral instructions that clearly violate the role's positioning, such as a coding role attempting to call a requirements analysis-specific API. Operation permissions can refer to a file path read / write whitelist dynamically generated or updated by the capability layer based on the delivery file content. Their purpose is to map abstract permissions to operating system-executable access control policies, intercepting illegal I / O operations at the kernel or scheduling engine level. The tasks to be executed can refer to specific work items parsed from the delivery file by the task layer, such as class names to be generated, configuration items to be modified, or interface contracts to be verified. Their purpose is to ensure that the agent does not deviate from its current responsibility boundaries, and that all outputs strictly correspond to the objectives explicitly defined in the delivery file.

[0023] In one embodiment, based on the target file path extracted from the [TASK_ALLOCATION] block in the delivery file, a capability layer whitelist for downstream roles is generated, and the target path is compared with the whitelist in the file system call hook. Another embodiment verifies whether the intermediate artifacts submitted by downstream roles meet schema constraints according to the input data format specifications defined in the delivery file. Furthermore, this application automatically matches the corresponding identity layer file and loads its prohibition rules based on the role identifier field in the metadata of the delivery file header. This application achieves deliverable-driven dynamic permission isolation based on any of the above methods, enabling permission boundaries to update in real time as the task evolves, rather than relying on static settings at deployment time.

[0024] For example: After the architecture design role completes the output, a delivery file named arch_design_delivery.yaml is generated. The [TASK_ALLOCATION] table lists the three Java class paths that need to be implemented by the coding role. After the scheduling engine parses the file, it injects the three paths into the coding role's capability layer whitelist and uses the entire file as the coding role's task layer input. After that, the coding role can only write files to these three paths, and all outputs must conform to the package structure and interface signature agreed in the delivery file.

[0025] In a further embodiment, after determining the identity and role of the target intelligent agent at the identity layer, a path set is extracted from the delivery file, a whitelist is generated, and the whitelist is injected into the capability layer of the target intelligent agent role to determine the agent's permissions.

[0026] In a further embodiment, extracting the path set from the delivery file and generating a whitelist includes: parsing the delivery file and locating the task allocation block marked in the delivery file; extracting the file path of the target task from a predetermined column of the task allocation block to form a path set; and configuring the path set as a whitelist for the target intelligent agent role.

[0027] Step S103: Generate a four-layer concatenated system prompt based on isolation permissions, and execute the task according to the system prompt. The system prompt integrates project background, general specifications, role-specific constraints, and current task input, providing the agent with a precise and isolated context for task execution.

[0028] The four-layer concatenated system prompts refer to a complete sequence of prompts formed by combining structured text content from four levels in a fixed order. This sequence is obtained by sequentially concatenating the first-layer project context file, the second-layer global rules file, the third-layer agent identity / role file, and the fourth-layer upstream agent role delivery file. Its function is to inject the macro-level project background, general behavioral norms, role-specific constraints, and current task input layer by layer into the large language model's context window, avoiding information clutter and attention shifts. The project context file, in Markdown format (project_context.md), describes the overall technology stack, business domain, and historical evolution of the project. Its function is to provide the model with a domain-aware foundation, reducing illusionary output caused by a lack of context. The global rules file, in general, defines the basic behavioral norms that all agents must adhere to. It is a file containing clauses such as prohibiting fictitious API interfaces and prohibiting the generation of undeclared dependencies (global_rules.txt). Its function is to establish consistent behavioral guidelines across roles, preventing logical conflicts between different roles. The agent's identity and role file can refer to the agent's unique identity layer file, such as `coder_soul.md`, which explicitly specifies rules such as only modifying the source code in the delivery file's designated path and prohibiting the generation of test cases. Its purpose is to strengthen identity consistency, ensuring that the model output is always anchored to the role's positioning. The upstream agent's delivery file can refer to the structured task input file obtained above and produced by the preceding role. Its purpose is to accurately transmit specific task objectives to the current role, achieving end-to-end task flow.

[0029] This application, for example, uses the full text of the project context file as the first segment of the system message, the full text of the global guidelines file as the second segment, the full text of the agent identity and role file as the third segment, and the full text of the upstream delivery file as the fourth segment (i.e., the user message). This application, for example, adds hierarchical identifiers (such as [L1], [L2]) to the beginning of each of the four layers of content and then merges them into a single text stream. Furthermore, this application hashes and digests the content of the first three layers and embeds it into the prompt word header, placing the content of the fourth layer at the end as an independent block reference. Based on any of the above methods, this application obtains a clearly structured and clearly defined prompt word organization method, enabling large language models to accurately identify project background, behavioral boundaries, and the current task focus within a limited context window.

[0030] For example, when a coding role executes, the system prompt consists of the following four parts concatenated in sequence: the first layer is project_context.md (containing the Spring Boot version, database type, and microservice division), the second layer is global_rules.txt (containing 6 general prohibitions), the third layer is coder_soul.md (containing 3 coding role-specific rules), and the fourth layer is arch_design_delivery.yaml (containing the fully qualified names and interface definitions of 3 classes to be implemented). After word segmentation, this prompt is sent to the large language model API, and the model generates Java source code that conforms to the architecture constraints.

[0031] Step S104 involves acquiring real-time status change information and execution anomaly information for the executed task, analyzing the anomaly information, and executing corresponding repair strategies. This step, through real-time monitoring and intelligent layered anomaly handling, significantly improves the system's self-healing capability and reliability in the face of various faults.

[0032] The real-time state change information refers to state trajectory data reflecting the lifecycle of the intelligent agent role, which is an aggregation of process monitoring data, API response timing data, and file system event data. Its function is to persist transient execution states in memory to disk files, forming an observable baseline for continuous reading by manual or automated tools. Execution anomaly information refers to structured error records generated when the intelligent agent triggers error conditions during task execution. These are log entries containing timestamps, role names, error type identifiers, and error message text. Its function is to transform unstructured exception stacks into standardized events that are categorizable, routable, and responsive, supporting subsequent layered self-healing. Anomaly information analysis refers to pattern matching of error type identifiers in execution anomaly information to identify their respective anomaly levels. Its function is to establish a deterministic mapping relationship between anomaly types and handling strategies, avoiding resource waste caused by general retries. Corresponding repair strategies refer to differentiated response actions triggered based on the anomaly type, such as exponential backoff retries, status marking, task reflow, or circuit breaker termination. Their function is to achieve precise and automated fault handling, reducing the frequency of manual intervention.

[0033] The implementation example captures the start and termination events of the API call process corresponding to the intelligent agent through the operating system process monitoring interface, and records the round-trip delay of each API request in conjunction with the system call timer. Finally, the status value, start time, end time, and cumulative time are written into a structured status probe file. This application, for example, captures the creation / modification events of the delivery file through a file system event listening mechanism, using it as a key signal for task completion. Furthermore, this application serializes exception information according to a preset JSON Schema format and appends it to a log file, routing it to the corresponding self-healing module based on the error_type field value. Based on any of the above methods, this application achieves end-to-end observability of the execution process and structured attribution capabilities for exception events, providing a data foundation for closed-loop feedback and autonomous repair.

[0034] For example: The scheduling engine maintains two files, state_probe.json and error_log.jsonl, in the task unit directory. When the coding role is activated, the status field in state_probe.json is updated to RUNNING and the start time is recorded. When it successfully generates the delivery file, the status is updated to DONE and the end time is recorded. If it returns an HTTP 429 status code when calling the large language model API, a record is appended to error_log.jsonl, where error_type is RATE_LIMITED, role_name is coder, and timestamp is the current time. The scheduling engine then identifies this type and initiates an exponential backoff retry process.

[0035] Furthermore, in the embodiment, the permission isolation also requires dynamically adjusting the whitelist according to the delivery file to restrict permissions. The real-time whitelist dynamic modulation is to determine the source code file of the task target according to the delivery file, dynamically provide the whitelist according to different tasks, and verify the target path against the whitelist when performing operations.

[0036] In this embodiment, the permission isolation also requires dynamically adjusting the whitelist based on the delivery documents to restrict permissions.

[0037] The dynamically adjusted whitelist refers to a whitelist whose content is not pre-fixed in the system configuration, but is parsed and extracted from the upstream delivery file and generated in real time each time a task starts. Its content strictly corresponds to the target source code file specified by the current task. This mechanism gives the whitelist task-level timeliness and context relevance, avoiding the risk of unauthorized access or insufficient permissions caused by long-term reuse of static whitelists. In this embodiment, the whitelist only applies within the lifecycle of the current task unit and becomes invalid when the task ends, without being persisted across tasks.

[0038] The aforementioned access restrictions can refer to imposing mandatory constraints on the file system access behavior of intelligent agents through a whitelist. When an intelligent agent initiates a file read / write request, the scheduling engine intercepts the request, matches and verifies the target path in the request against the currently effective whitelist, and only allows access if the target path exists in the whitelist; otherwise, access is denied and an interception log is recorded. This restriction directly applies to operating system-level file I / O interface calls and is a runtime mandatory control that does not rely on the model's own understanding or prompt words.

[0039] The implementation can generate a whitelist by extracting a set of paths from the task allocation block in the delivery file; it can also generate a whitelist by identifying the target scope of the source code based on structured marker fields in the delivery file; further, this application can also generate a whitelist by extracting a list of file paths from the YAML / JSON format task description block embedded in the delivery file. This application obtains a task-specific, context-sensitive, and lifecycle-limited whitelist based on any of the above methods, thereby supporting the dynamic implementation of role-based least privilege isolation.

[0040] The real-time whitelist dynamic modulation steps described in the embodiment include: Step S501: Determine the source code files of the task objectives based on the delivery documents, and dynamically provide a whitelist according to different tasks.

[0041] Specifically, determining the source code files for the task objectives based on the delivery documents refers to delivering documents containing explicitly identified task objective information. This information, in a structured form such as tables, key-value pairs, or marked text blocks, specifies the paths to one or more source code files that the task needs to process. This path information is not a generalized description, such as all files under the src / directory, but rather precise down to the specific filename and relative path, for example, src / main / java / com / example / service / UserService.java, forming the original input source for the whitelist. This determination process is automatically completed by the scheduling engine during the task activation phase, without relying on manual intervention or model output parsing.

[0042] Dynamically providing whitelists based on different tasks means that the whitelist content obtained by the same intelligent agent role (such as the coding role) is different in different tasks. The difference depends entirely on the changes in the task objectives contained in the upstream delivery file. For example, the architecture design role specifies the modification of 3 Java classes in the delivery file in task A, and specifies the modification of 2 Python scripts and 1 configuration file in task B. The scheduling engine generates two different whitelists for the coding role accordingly. This dynamism is reflected in the fact that the whitelist content is updated in real time as the content of the delivery file changes, rather than a fixed set preset by role.

[0043] The embodiment locates the target source code file of the task based on the [TASK_ALLOCATION] block marked in the delivery file; this application may also extract the source code file path from the YAML list under the target_files: key in the delivery file; furthermore, this application may also parse the source code file path from the files_to_modify array field in JSON format in the delivery file. This application obtains a set of source code file paths strongly bound to the current task based on any of the above methods, thereby ensuring that the whitelist accurately reflects the task intent.

[0044] Step S502: Verify the target path against the whitelist during the operation.

[0045] Among them, the execution operation can refer to the file system write operation initiated by the intelligent agent role during the task execution process (such as saving the generated code, modifying the configuration file, overwriting the build script, etc.). This operation is driven by the inference result of the large language model and forwarded to the operating system by the scheduling engine. This operation has a clear target path parameter, and the path format is consistent with the format of the entries in the whitelist (all are relative paths, uniformly separated by forward slashes, without wildcards or regular expressions).

[0046] Verification can refer to the scheduling engine performing a deterministic string matching judgment before forwarding the write request: comparing the target path in the request with all path entries in the whitelist one by one, and only if there is an entry that is completely equal to the target path is the verification considered successful; if the target path is a directory path (such as src / main / java / com / example / ), then there must be a directory entry with the same name in the whitelist or its subpaths must be explicitly listed, otherwise the verification is considered to have failed; this verification process does not involve path normalization (such as not expanding...), does not perform symbolic link resolution, and does not support fuzzy matching, ensuring that the judgment logic is concise, verifiable, and unambiguous.

[0047] This application can, for example, perform an exact string lookup with O(1) time complexity after indexing the whitelist path set using a hash table; it can also perform verification by traversing the whitelist path list and performing string equality comparisons item by item; furthermore, it can load the whitelist paths into a memory cache and use a prefix tree structure to accelerate batch verification of multiple paths. Based on any of the above methods, this application achieves deterministic verification of the target path and the whitelist in milliseconds, ensuring low latency and high reliability of access control.

[0048] For example, in a software development task, the deliverables produced by the architecture design role may include a [TASK_ALLOCATION] block, in which the target file column explicitly lists three paths: src / main / java / com / example / controller / OrderController.java, src / main / resources / application.yml, and docs / api-spec / openapi.yaml. After parsing the block, the scheduling engine injects the three paths into the coding role's capability layer, forming a write whitelist specific to this task. When the coding role attempts to write to src / main / java / com / example / service / PaymentService.java, the scheduling engine checks and finds that the path is not in the whitelist, immediately intercepts the write request, records the error log entry: [ERROR][CODER] Write access denied to / src / main / java / com / example / service / PaymentService.java — not in write whitelist, and updates the role status to FAILED. However, when it attempts to write to src / main / resources / application.yml, the verification passes, and the request is normally forwarded to the file system for saving.

[0049] This application achieves context awareness, task-level adaptability, and runtime enforceability of the permission isolation mechanism by dynamically extracting the target source code file based on the delivery documents, generating a dedicated whitelist in real time according to different tasks, and performing deterministic verification of the target path and whitelist before performing write operations. On this basis, it effectively prevents intelligent agents from unauthorizedly modifying files not designated by the task, strengthens the precise constraint capability of the Skill layer in the SSD architecture on operation permissions, and enables permission control to truly serve the pipeline execution logic driven by deliverables. This solves the problems of lack of role-level permission isolation and lack of structured role behavior constraint mechanisms in the background technology.

[0050] In a further embodiment, determining operation permissions through the capability layer involves: after determining the identity and role of the target agent at the identity layer, extracting a path set from the delivery file, generating a write whitelist, and injecting the write whitelist into the capability layer of the target agent role to determine agent permissions. In multi-agent collaborative software development pipelines, achieving role-level dynamic file read / write permission isolation is a key technical issue. Current technical solutions lack fine-grained control over agent role operation permissions, easily leading to unauthorized access and chaotic task execution.

[0051] This application proposes that, after determining the identity and role of the target intelligent agent at the identity layer, a path set is extracted from the delivery file, a write whitelist is generated, and the write whitelist is injected into the capability layer of the target intelligent agent's role to determine the intelligent agent's permissions.

[0052] This technical solution implements operational permission management for intelligent agent roles through a multi-layered permission control mechanism. The identity layer, serving as the identity identification system for intelligent agent roles, includes core information such as role name, job description, and input / output specifications, providing a basic framework for permission configuration. The capability layer precisely limits the range of files that intelligent agents can operate on through a whitelist mechanism. Delivery files, as the core carrier of task-driven processes, directly determine the content written to the whitelist based on their set of paths. The whitelist is stored using in-memory path hash sets or key-value maps, ensuring efficient permission verification. The injection process is completed collaboratively by a configuration loader, role context manager, and permission registration service, guaranteeing the dynamic nature and accuracy of permission configuration.

[0053] Specifically, the identity layer's construction includes loading and parsing role location files, which can be achieved through a predefined structured text format. The capability layer's whitelist generation supports parsing various delivery file formats. For example, for table-formatted delivery files, the system can match column names to locate target file columns and extract paths row by row; for YAML / JSON formats, it can extract string arrays from paths; for tagged paragraph formats, the system can identify specific tags (such as [TASK_ALLOCATION]) and extract subsequent strings that conform to the path format. These paths, after deduplication and normalization, form the final whitelist set.

[0054] Through the above technical solution, this application achieves fine-grained management of agent role permissions. In practical applications, after the architecture design role completes the output of the delivery file, the scheduling engine automatically parses the task allocation block, extracts the target file path set, and injects it into the capability layer of the coding role. During subsequent execution, the system performs real-time verification on each file write request, allowing only path requests within the whitelist, effectively preventing unauthorized operations. This dynamic permission management mechanism based on task context not only ensures the accuracy of permission configuration but also enables adaptive adjustment of permissions as tasks evolve, solving the problem that traditional static permission configuration is difficult to adapt to complex task scenarios.

[0055] In a further embodiment, the path set is extracted from the delivery file and a whitelist is generated. The steps include: Step S201: Parse the delivery file and locate the task allocation block marked in the delivery file; The task allocation block refers to a structured data segment in the delivery file enclosed by a predefined marker, such as [TASK_ALLOCATION] which begins with [TASK_ALLOCATION] and ends with [END_TASK_ALLOCATION]. This segment is used to explicitly declare the target files and their associated task attributes that downstream roles need to process. This block can be in tabular, key-value pair, or nested YAML / JSON format, and its existence indicates that the upstream role has completed task decomposition and resource allocation. In this embodiment, the block, as part of the metadata of the delivery file, is generated by an upstream intelligent agent, such as an architecture design role, according to task requirements, and serves as a trusted input source for the dynamic configuration of the scheduling engine's execution permissions. The scheduling engine identifies the marker through text scanning or a structured parser, thereby anchoring the starting position of the block and providing the scope boundary for subsequent column extraction.

[0056] Step S202: Extract the file path of the target task from the predetermined column of the task allocation block to form a path set; Among them, the predefined column (e.g., the target file column) can refer to a field column with fixed semantic identifiers within the task allocation block, which is used to carry the specific file path information that the downstream role is authorized to write; This column can be a header column with a specified column name (such as target_file, file_path, output_path), or it can be the Nth column arranged in a preset order (such as the second column in the table), and its content is a string that conforms to the operating system path specification; In this embodiment, the scheduling engine selects the corresponding parsing strategy based on the delivery file format type: if it is a table format, it locates the column by matching the column name and reads the cell content row by row; if it is a key-value pair format, it extracts all values ​​with the key target_file; if it is a YAML / JSON format, it extracts the string array with the key path task_allocation.target_files. After all successfully extracted path strings are deduplicated and normalized (e.g., converted to absolute paths and eliminated redundant separators), they form an ordered or unordered set of paths, which is the basis of the original path data for the capability layer to be injected.

[0057] Step S203: Configure the path set as a whitelist for the target agent role.

[0058] Among them, writing to the whitelist can refer to an access control list used to restrict the target intelligent agent role to only initiate file write operations to a specified path during the execution process; The whitelist can be a set of hashes maintained in memory, a text file persisted on disk, or a read-only variable embedded in the runtime environment context of the role. For example, this application can construct a memory-level path hash set by parsing the path set obtained by allocating blocks and extracting predetermined columns from the parsing task, and bind it to the capability layer instance of the target intelligent agent role; this application can also generate a plain text file (e.g., whitelist.txt) with one path per line based on the same path set, and register the path of this file to the access verification interface of the capability layer; further, this application can also serialize the path set into a JSON object and inject it into the third-level (Soul file) extended field of the system prompt words of the target intelligent agent role for verification during local sandbox runtime; This application obtains precise path-level constraints on the writing behavior of the target intelligent agent role based on any of the above methods, ensuring that it can only modify files explicitly defined in the task allocation block, thereby ensuring that the permission configuration and task intent are consistent. Figure 1 To.

[0059] For example, in this application, when the delivery file output by the architecture design role contains a [TASK_ALLOCATION] block, and this block is organized in a table format with the table header being Task Number | Target File | Description, where the Target File column is the second column; after the scheduling engine recognizes this tag, it traverses each row of the table, extracts all non-empty strings in the second column (such as src / main / java / com / example / Service.java, config / application.yml), and forms a path set containing two elements after path normalization; this set is written into the memory whitelist structure and loaded into the capability layer of the coding role in real time; subsequently, when the coding role attempts to write to pom.xml, it is intercepted by the scheduling engine because the path does not appear in the whitelist, and a rejection log is recorded; execution is only allowed if the target of its write operation is one of the aforementioned two paths.

[0060] This application parses the task allocation blocks marked in the delivery file, extracts the target file paths carried by predetermined columns, forms a path set, and configures it to be written into a whitelist. This achieves an automated, structured, and verifiable mapping from upstream deliverables to downstream permissions. By leveraging the explicit marking mechanism of the task allocation blocks and the semantic binding relationship with predetermined columns, it ensures that the path source is traceable, the extraction process is reproducible, and the whitelist content is auditable. On this basis, the path set is directly injected into the capability layer, making the permission constraints and task definitions fully aligned at the logical and execution levels. This supports the implementation of the technical action of extracting the path set from the delivery file and generating the whitelist as described in Example 3, achieving the engineering implementation of role-level least privilege isolation.

[0061] Furthermore, this application also provides a system prompt word that generates a four-layer concatenation based on isolation permissions, including: Step S301: The four-layer concatenation prompt words are generated by extracting the prompt word information from the delivery document, placing it into an isolated four-layer structure, and concatenating it in hierarchical order to generate system prompt words for the intelligent agent performing the task. The delivery file can refer to the structured output file generated by the upstream agent after completing the task. Its content includes the task result, metadata identifier, timestamp, and consistency summary. This file serves as the task input for the current agent and is injected into the fourth layer of the four-layer structure. A project context file can be a text file that describes the overall architecture of a project, the selection of technology stacks, dependencies, and historical evolution path, and is used to enable agents to understand the macro background of the development environment they are in. A Global Directive File can be a text file that defines the common behavioral boundaries, safety red lines, compliance requirements, and output format specifications that all intelligent agent roles must follow. For example, it may prohibit the generation of executable binaries, prohibit hard-coded keys, and require adherence to the PEP8 coding style. The Agent Identity Role File can be a text file that defines the Soul layer attributes of a specific agent role, including role positioning (such as architect, coder), input and output contracts, positive behavior rules (such as the microservice splitting strategy should be adopted first) and negative prohibition rules (such as not modifying existing API interface definitions). The upstream agent's delivery file can be a structured file that is directly produced by the preceding agent, verified by signature and integrity, and its content constitutes a trusted input source for the current agent's task execution. This application organizes the above four types of files in a fixed hierarchical order to form a logically isolated and semantically focused prompt word structure, avoiding the indiscriminate injection of all project information into a single model call. Thus, without reducing information completeness, it significantly compresses the length of prompt words and improves the accuracy of the large language model in understanding key instructions.

[0062] This application can, for example, determine / obtain / obtain the complete prompt word to be sent to the large language model by sequentially concatenating the project context file, global rule file, agent identity role file, and upstream agent role delivery file; this application can also determine / obtain / obtain the complete prompt word to be sent to the large language model by merging the first three layers of files into a system message and constructing the request body separately as a user message; furthermore, this application can also determine / obtain / obtain the complete prompt word to be sent to the large language model by performing templated concatenation with identifiers based on the metadata tags of each layer of files (such as [CONTEXT], [GLOBAL_RULES], [ROLE_CONSTRAINTS], [TASK_INPUT]), and inserting delimiters after concatenation to strengthen the hierarchical boundaries.

[0063] This application obtains system prompts that are customized for the current intelligent agent role, context-focused, and permission-controlled based on any of the above methods, ensuring that the agent only receives information input that matches its identity, capabilities, and tasks, thus supporting the implementation of role-level least privilege isolation.

[0064] For example, in a software development pipeline, when a quality review agent needs to perform compliance checks on the source code files produced by a coding agent, the scheduling engine first loads the project context file (containing a description of the technology stack used by the project: Spring Boot 3.2 and PostgreSQL 15), then loads the global guidelines file (containing mandatory specifications such as all review conclusions must cite OWASP ASVS standard clauses), next loads the identity and role file of the quality review agent (containing Soul-level constraints such as only being able to read .java files in the src / main / java directory and not being able to modify any files), and finally loads the delivery file just produced by the coding agent (containing CheckResult.json and ModifiedFiles.list). These four layers of content are concatenated in sequence and submitted as a complete prompt to the large language model API, which then generates a structured review report. This process does not introduce any technical elements not limited in this application, and all file types, hierarchical order, and uses strictly correspond to the original description in this application.

[0065] Step S302: The four-layer structure includes a first-layer project context file, which provides project background knowledge; a second-layer global guidelines file, which provides general behavioral norms; a third-layer agent identity and role file, which provides role-specific identity and behavioral constraints; and a fourth-layer delivery file for upstream agent roles.

[0066] The Project Context File can refer to the project_context.md file stored in the root directory of the task unit. Its content is manually configured during the project initialization phase or automatically generated by the early requirements analysis agent, covering a glossary of business domain terms, a core entity relationship diagram, and a summary of key interface contracts. A global directive file can refer to the global_rules.yaml file, which is uniformly deployed in the system configuration directory. It declares behavioral constraints shared by all roles in the form of key-value pairs, such as max_output_tokens: 2048 and forbidden_patterns: [eval(, os.system()]; Agent Identity Role File can refer to the file located in roles / that is bound to each role.<role_name> The content of the soul.md file in the / soul / subdirectory is constructed and persisted by the SSD model building module in step S1, which clearly defines the role's responsibilities and operational restrictions. The upstream agent's delivery file can be a JSON file with the .delivery extension that is automatically routed to the current agent's working directory by the Directive router module based on task dependencies. Its structure includes fields such as task_id, generated_at, file_paths, and digest_sha256 to ensure that the source is trustworthy and the content is complete. This application constructs a basic structure of prompt words that supports accurate reasoning by having four types of files that carry constraint information in different dimensions: the project context provides horizontal breadth, the global criteria provide vertical depth, the identity and role files provide role-specific precision, and the upstream delivery files provide task timeliness.

[0067] This application can, for example, determine / obtain / obtain the semantic division of labor of layered prompt words by using project context files to provide project background knowledge, global guidelines files to provide general behavioral norms, agent identity and role files to provide role-specific identity and behavioral constraints, and delivery files from upstream agent roles to provide current task input. This application can also, for example, determine / obtain / obtain a prompt word organization method that balances information integrity and token efficiency by dynamically adjusting the content density of each layer of files based on the proportion of characters in the prompt words (e.g., a project context layer limited to 512 characters, a global guidelines layer limited to 384 characters, an identity and role layer limited to 256 characters, and a delivery file layer with no length limit but with streaming truncation enabled). Furthermore, this application can also determine / obtain / obtain a flexible prompt word structure adapted to different risk scenarios by configuring an independent enable / disable flag for each layer of files, and dynamically enabling or disabling a certain layer based on the current role's security level at runtime (e.g., disabling the project context layer for high-risk operation roles to reduce interference information).

[0068] This application obtains a four-layer prompt word system with structural stability, semantic interpretability, and permission auditability based on any of the above methods, so that the system prompt words themselves become the externalized carrier of permission isolation strategy, rather than a simple language model input interface.

[0069] For example, in a front-end component development task, after the UI design agent completes the Figma design draft to code, it generates a delivery file ui_delivery.delivery, which includes component names, Props interface definitions, and CSS variable mapping tables. The scheduling engine uses this as the fourth-layer injection prompt. At the same time, it loads the project context file (indicating that the project uses the React 18 + TypeScript + Tailwind CSS technology stack), the global guidelines file (stipulating that all components must pass Jest unit tests with a coverage of ≥80%), and the UI implementation agent's identity and role file (limiting the generation of only .tsx and .css files and prohibiting the introduction of third-party UI libraries). After the four layers are concatenated, they are submitted to the large language model, which generates React component code that conforms to project specifications, is type-safe, and has consistent styles. The entire process does not introduce any technical features outside of this application, and all file names, paths, formats, and functions are completely consistent with step S2: the isolation and concatenation of the four-layer prompt.

[0070] This application achieves structured layering and decoupling of responsibilities for prompt content by injecting the delivery document as the fourth layer into a four-layer structure and splicing it with the other three layers in a fixed order: the project context layer ensures the agent's coherent understanding of the overall engineering context, the global rules layer unifies the behavioral baseline for multi-role collaboration, the identity role layer solidifies role-specific behavioral paradigms, and the upstream delivery layer ensures the accuracy and timeliness of task input; on this basis, there is no semantic overlap or functional redundancy between the layers, but rather a progressive information enhancement relationship is formed—the first three layers construct who I am, where I am, and what I should do, and the fourth layer clarifies what I need to do now; thus, without increasing the model burden, it significantly improves the consistency of role behavior, the accuracy of task execution, and the verifiability of access control, effectively solving the dual problems pointed out in the background technology of lack of structured role behavior constraint mechanism and model comprehension bias caused by excessively long prompts.

[0071] Furthermore, this application also provides methods for obtaining real-time status change information and execution exception information of the executed task, including: The real-time status change information is: Step S401: Obtain the underlying monitoring data by acquiring the state changes of the intelligent agent role in real time, and establish a real-time state probe file based on the underlying monitoring data. The real-time state probe file includes process monitoring data, API response timing data and file system event data. Among them, Process Monitoring Data refers to process lifecycle event data exposed by the operating system kernel, which can be information such as process start time, termination time, and running status (e.g., R running, S sleeping, Z zombie state) obtained by calling the / proc / [pid] / stat interface or the psutil library. This data is used to characterize the activation, continuous running, and termination process of the API call process corresponding to the agent role. In this embodiment, it serves as the basis for determining whether the role has entered the RUNNING state or has completed execution and transitioned to the DONE state. API Response Timing Data refers to the time interval data experienced from initiating an HTTP request to the large language model service to receiving a complete response. It can be the latency per call and the cumulative latency. This data is used to evaluate the performance bottleneck of the model service call. In this embodiment, it serves as the input basis for determining API call layer anomalies (such as TIMEOUT, RATE_LIMITED) and triggering exponential backoff retry strategies. File System Event Data. Data can refer to event data such as the creation (IN_CREATE), modification (IN_MODIFY), or renaming (IN_MOVED_TO) of delivery files captured by the operating system's file system listening mechanism. It can be structured event records obtained through the inotify (Linux) or ReadDirectoryChangesW (Windows) interface. This data is used to confirm whether the agent role has successfully produced the delivery file. In this embodiment, it serves as the direct basis for determining task completion (DONE) or triggering downstream nodes to rerun.

[0072] This application can, for example, determine the start and termination events of the process corresponding to the agent role based on process monitoring data; it can also determine the single and cumulative time consumption of the agent role's model call based on API response timing data; further, it can determine the creation or modification events of the delivery file based on file system event data. This application obtains observability support for the agent role's execution lifecycle, call performance, and output results based on any of the above methods.

[0073] For example, this application may, after the scheduling engine activates the coding role, immediately call the operating system process monitoring interface to capture the associated Python child process PID, and continuously poll the / proc / [pid] / stat status field corresponding to the PID; when the status field changes from S to R, it is determined as a startup event and written to the start time field of the status probe file; when the status field subsequently changes to Z or the process disappears, it is determined as a termination event and written to the end time field; at the same time, before each request to the large language model API is made, the start timestamp is recorded, and after receiving the response, the difference is calculated and accumulated to the cumulative time field; when a newly generated deliverable.json file appears in the task unit directory, the status is updated to DONE, and the last modification timestamp of the file is written to the status probe file.

[0074] Step S402: Execution exception information is: when an exception occurs during execution, the exception information is written to the execution log file in a structured format; The structured format refers to a predefined and fixed-order set of fields in the log record, such as timestamp, role name, error level, model provider name, model version, HTTP status code, error type identifier, and error message text. This format supports automated log parsing and categorized alerts, and in this embodiment, it serves as the data foundation for the layered exception self-healing module to identify exception types and trigger corresponding repair strategies. The error type identifier refers to a standardized string after classifying exception semantics, such as RATE_LIMITED, AUTH_FAILED, NETWORK_ERROR, TIMEOUT, CONTEXT_OVERFLOW, PROVIDER_ERROR, and FILE_ACCESS_ERROR. This identifier is used to distinguish the technical level at which the exception occurs (API call layer, authentication layer, business logic layer, file access layer), and in this embodiment, it serves as the direct matching basis for layered exception self-healing processing.

[0075] This application can, for example, extract error type identifiers based on HTTP response status codes and exception stack traces, and append fields such as timestamp, role name, and error level to the error.log file in CSV format; alternatively, it can map the error.code field in the JSON error body returned by the model service to standard error type identifiers, and write all fields line by line to the log file in JSON Lines format; furthermore, it can generate local error records based on operating system signals (such as SIGSEGV, SIGPIPE) or timeout interrupt events, and inject them uniformly into the same log file. This application obtains an exception information carrier that can be automatically identified, classified, and responded to by a machine based on any of the above methods.

[0076] For example, in this application, when a quality review role calls the large language model API and receives an HTTP 429 response, the scheduling engine parses the Retry-After field in the response header and the error.code field in the response body, identifies the error type as RATE_LIMITED, and then appends a line to error.log: 2025-04-01T10:23:45Z,reviewer,ERROR,openai,gpt-4o,429,RATE_LIMITED,Rate limit exceeded for model; this record is then read by the hierarchical exception self-healing module and triggers an exponential backoff retry strategy.

[0077] This application accurately captures the start and end points of the lifecycle of intelligent agent roles through process monitoring data, quantifies model call performance using API response timing data, and objectively verifies task delivery results using file system event data. Simultaneously, it persistently writes exception information into log files in a structured format with clearly defined fields and semantics, enabling accurate identification and classification of exception types. Based on this, state probe files and structured logs together constitute an observability infrastructure, providing consistent, reliable, and reproducible data input for state updates, exception analysis, and hierarchical self-healing. This solves the problem of silent failures caused by invisible states and difficulty in locating exceptions in multi-agent collaboration, improving the transparency and controllability of the pipeline execution process.

[0078] Furthermore, this application also provides an update status probe file based on underlying monitoring data, including: Step S411: Determine the start and termination events of the process corresponding to the agent role based on process monitoring data; Among them, process monitoring data can refer to the underlying system event stream that the scheduling engine continuously collects through the operating system process interface, reflecting the life cycle of the API call process associated with the intelligent agent role; A startup event can be a system notification signal indicating that a process has been successfully created and entered the ready queue, which is used to identify that the agent role has been activated and has started executing tasks; Termination events can be system events that indicate that the task execution of the agent role has ended, such as normal process exit, forced termination, or reclaimed by the kernel due to resource overrun. In this embodiment, the start event serves as the trigger for the agent to enter the RUNNING state, and the termination event serves as the basis for determining whether the agent transitions from the RUNNING state to the final state such as DONE, FAILED, or TIMEOUT. This application can identify process startup events, for example, by extracting the `state` field and `starttime` field from the ` / proc / [pid] / stat` file provided by the operating system kernel; it can also identify process termination events by capturing the `SIGCHLD` signal and the return value of the `waitpid()` system call; furthermore, it can indirectly infer startup and termination events by monitoring the creation and deletion of the PID file in the temporary working directory of the process through the Linux inotify or Windows ReadDirectoryChangesW interface. This application obtains accurate identification of the lifecycle of the intelligent agent process based on any of the above methods, providing a time anchor for subsequent state modeling.

[0079] For example, this application can record the time as the start timestamp when the scheduling engine detects that the PID file of the model calling process corresponding to the coding role is created under the path / tmp / agent_coder_XXXX / pid, and set the status field in the status probe file to RUNNING; when the PID file is deleted and / proc / [pid] / stat fails to be read, the system combines the process exit code to determine whether it is a normal termination. If the exit code is 0, it is set to DONE, otherwise it is set to FAILED.

[0080] Step S412: Determine the single-time and cumulative time consumption for the intelligent agent role to make model calls based on API response timing data; Among them, API response timing data can refer to the timestamp of request initiation recorded by the scheduling engine before each HTTP request is sent to the large language model server, and the timestamp of response reception recorded after a complete HTTP response is received. The difference between the two is the time consumed in a single call. Single-transaction time can be the time interval from when a single model inference request is sent to when a complete response is received, used to evaluate the instantaneous performance of the current call chain; The cumulative time can be the sum of the time spent on all successful model calls since the intelligent agent role was started, which is used to characterize its overall computational load and task complexity; In this embodiment, the single-time consumption is used to dynamically adjust the retry waiting window and the circuit breaker threshold determination, and the cumulative consumption is one of the key fields of the structured table in the status probe file, supporting the timeout monitor to perform real-time load assessment. This application can calculate the single-transaction time by inserting high-precision timestamps (time.perf_counter()) before and after the send() method of an HTTP client library (such as requests or httpx). Alternatively, it can extract the single-transaction time from the $request_time field in the logs of a proxy layer (such as Nginx or a self-developed gateway). Furthermore, this application can capture HTTP request / response packet timestamps at the kernel network stack level through an eBPF program, achieving non-intrusive timing. This application obtains single-transaction and cumulative time data based on any of the above methods, providing a quantitative basis for state inference and anomaly decision-making.

[0081] For example, in this application, the quality review role may initiate three model calls during execution, with each call taking 1245ms, 1872ms, and 963ms respectively, for a total of 4080ms. This value is written into the cumulative time column of the status probe file and used to determine whether it exceeds a preset threshold (such as 5000ms), thereby triggering the TIMEOUT state transition.

[0082] Step S413: Determine the creation or modification event of the delivered file based on file system event data; Among them, file system event data can refer to kernel-level events such as IN_CREATE, IN_MOVED_TO, or IN_MODIFY that the scheduling engine captures through the operating system's file system event listening mechanism regarding the delivery files in the task unit directory; A creation event can be an atomic operation completion event where an upstream role first produces a delivery file and writes it to a specified path; Modification events can be events where the content of the delivered file changes or metadata (such as timestamps or permission bits) is updated; In this embodiment, the creation or modification of events serves as the core criterion for the intelligent agent to complete its task output, and is used to drive the state activation and dirty mark propagation of downstream agents. This application can, for example, monitor the IN_MOVED_TO event (corresponding to the completion of atomic write by the upstream role) of the delivery.json file in the task unit directory based on the Linux inotify subsystem; it can also monitor the IN_CLOSE_WRITE event after the file content is written based on the fanotify mechanism; further, this application can also identify logical layer modification events by polling changes in the file's mtime field and comparing the SHA-256 digest. This application obtains reliable signals of delivery file changes based on any of the above methods, ensuring the accuracy and consistency of task completion determination.

[0083] For example, this application may generate a new file in the path / workspace / task_001 / delivery.json after the architecture design role completes the output; the scheduling engine listens for the IN_MOVED_TO event in this path through inotify, immediately triggers the coding role's state to migrate from WAITING to RUNNING, and synchronously updates the creation or modification event timestamp field of the corresponding role in the state probe file.

[0084] Step S414: Determine the current state of the agent role based on the start event, termination event, cumulative time, and creation or modification event; The current state can refer to the discrete semantic labeling of the operational stage of the intelligent agent role in the task pipeline after integrating the aforementioned four types of underlying monitoring signals. The current state can be one of the following: WAITING, RUNNING, DONE, STAGING, FAILED, TIMEOUT, RETRY, CIRCUIT_BREAK. Each state corresponds to a specific triggering condition and business meaning. In this embodiment, the current state is used to drive the scheduling engine to execute differentiated control strategies: such as disabling resource allocation in the WAITING state, enabling the timeout timer in the RUNNING state, triggering downstream activation in the DONE state, and starting the abnormal self-healing process in the FAILED / TIMEOUT state. This application can determine the state as WAITING based on the absence of a start event and a delivery file creation event; it can also determine the state as RUNNING based on the occurrence of a start event but the absence of a termination event and the cumulative time being below a threshold; further, it can determine the state as DONE based on the occurrence of a termination event and the confirmation of a delivery file creation event, with a non-zero cumulative time and an exit code of 0. This application obtains an accurate assignment of the current state based on any of the above methods, constituting the core semantic output of the observability probe.

[0085] For example, in this application, if the process start event of the coding role has been captured, the current cumulative time is 3210ms, no termination event has occurred, and the delivery file / workspace / task_001 / coder_output.py has not been created, then the current status field of the role in the status probe file is set to RUNNING.

[0086] Step S415: Write the current state, start time, end time and cumulative time into the state probe file in the form of a structured table, and update the global timestamp of the state probe file each time it is written.

[0087] Among them, the state probe file can refer to a physical disk file with a fixed field structure and format specification maintained by the scheduling engine in each task unit directory, and the file name is state_probe.csv or state_probe.json; The structured table format can be CSV, containing a header row for role name, current state, start time, end time, and cumulative time (ms), with each row being a snapshot of the state of an agent role; A global timestamp can be a separate field located in the header of a status probe file, formatted as an ISO 8601 standard time string (e.g., 2025-04-01T10:23:45.678Z), representing the absolute moment when the write operation occurred; In this embodiment, the structured table supports direct parsing by command-line tools (such as csvkit), scripting languages ​​(such as Python pandas), and front-end visualization components; the global timestamp is used to verify the timing consistency of state writing for multiple roles, avoiding state view corruption caused by concurrent writing; This application could, for example, append state data in CSV format to state_probe.csv, and write #GLOBAL_TIMESTAMP:2025-04-01T10:23:45.678Z in the first line of the file; it could also serialize the state data into a JSON array and embed it in the structure {global_timestamp:2025-04-01T10:23:45.678Z,roles:[{...}]}; furthermore, this application could use an SQLite database file to store state snapshots, updating the last_updated field in the meta table before each write. This application achieves persistence, structuring, and synchronization of state data based on any of the above methods.

[0088] For example, this application may generate a state_probe.csv file under the task unit directory / workspace / task_001 / , with the following content: #GLOBAL_TIMESTAMP:2025-04-01T10:23:45.678Z Character Name, Current Status, Start Time, End Time, Total Time Spent (ms) coder,RUNNING,2025-04-01T10:22:10.123Z,,3210 reviewer, waiting,, This file can be pulled and rendered into a pipeline Kanban board in real time by the CI / CD platform.

[0089] This application accurately captures the start and end boundaries of agent roles through process monitoring data, quantifies their model call load using API response timing data, verifies task output results using file system event data, and infers the current state with clear business semantics by integrating the above multi-source signals. Then, this state, along with time and time consumption dimensions, is persisted to a state probe file in a structured table format, while maintaining a global timestamp to ensure the consistency of the state view. This achieves millisecond-level, parsable, and synchronized real-time observability assurance for the multi-agent collaborative pipeline execution process, solving the problems of missing pipeline-level real-time state synchronization and difficulty in locating silent failures in the background technology.

[0090] Furthermore, this application also provides a method for analyzing and executing corresponding repair strategies based on anomaly information, including: Step S421: Obtain exception information, analyze the exception type to trigger the corresponding layered exception self-healing process. The exception types include API call layer exception, authentication layer exception, business logic layer exception and file access layer exception.

[0091] Among them, the abnormal information can refer to the operational failure data captured and structured by the scheduling engine during the execution of the agent. Its content comes from the execution abnormal information defined in this application, that is, the abnormal entries written to the log file in a structured format. The abnormal information includes at least a timestamp, role name, error level, model provider name, HTTP status code, error type identifier and error message text. API call layer exceptions can refer to transient or temporary faults returned by the large language model server that are directly related to the interface call process. The technical focus is on the communication and response links in the model service call chain. In this embodiment, this exception type is used to trigger an exponential backoff retry strategy as an adaptive recovery mechanism for scenarios such as network jitter, rate limiting response, or temporary unavailability of the server. An authentication layer exception can refer to a situation where an API request is rejected due to invalid identity credentials, expired keys, or missing permission configuration. Technically, this refers to the identity authentication process for accessing the model service. In this embodiment, this exception type is used to directly terminate the execution process of the current role and mark it as a failure, avoiding unnecessary retries that consume resources. Business logic layer anomalies can refer to judgment-type anomalies caused by the intelligent agent's output content not meeting the preset quality rules or task target requirements. Technically, these anomalies refer to the semantic-level verification results performed by downstream roles (such as quality review roles) based on the content of the delivered documents. In this embodiment, this anomaly type is used to trigger task backflow to upstream roles and increment the backflow count to achieve on-site closed-loop repair of problems. File access layer anomalies can refer to the failure of an intelligent agent when reading or writing to the file system due to reasons such as non-existent path, insufficient permissions, locked file occupation, or full disk. The technical point of this anomaly is the file I / O execution stage of the operating system. In this embodiment, this anomaly type is used to directly mark the failure status and record the affected file path, providing a precise location basis for manual troubleshooting.

[0092] This application can, for example, determine the exception level by matching the error type identifier field contained in the exception information with a preset exception classification rule table; it can also identify the location of the exception through a rule engine based on the combined characteristics of the HTTP status code and error message text in the exception information; further, it can distinguish between server-side exceptions and client-side configuration exceptions by jointly judging the model provider name and error level field in the exception information. This application achieves accurate identification of the exception type based on any of the above methods, thereby providing a decision-making basis for subsequent layered self-healing actions.

[0093] For example, this application can determine an API call layer exception when the scheduling engine reads an exception record from the error log file, with the error type identifier being RATE_LIMITED and the HTTP status code being 429; an authentication layer exception when the error type identifier is AUTN_FAILED and the error message text contains the phrase "invalid API key"; a business logic layer exception when the error type identifier is FAIL_BACK_TO_CODER and the role name is quality_reviewer; and a file access layer exception when the error type identifier is FILE_ACCESS_ERROR and the error message text explicitly states "Permission denied on / src / main.py".

[0094] Step S422: The corresponding protection strategy is to set a maximum execution time for the agent role, and to perform a timeout circuit breaker operation if no delivery document is detected from the agent role within the maximum execution time.

[0095] The maximum execution time can refer to the time threshold that the scheduling engine configures independently for each intelligent agent role. The unit is seconds, which is used to constrain the maximum allowable time from the start of the role's activation to the successful production of the delivery file. This time threshold does not depend on a globally unified setting, but is dynamically configured according to the role's task complexity, historical execution performance, and team operation and maintenance strategies. The delivery file may refer to the structured output file defined in this application, which is generated by the intelligent agent role after performing the task according to the isolation permission. Its naming and format are agreed by the Directive layer task input specification, and it must exist in the specified path under the task unit directory. The timeout circuit breaker operation refers to the scheduling engine actively terminating the process corresponding to the role, releasing related resources, updating the status field of the role to TIMEOUT in the status probe file, and appending a structured log record containing a timestamp, role name, and timeout flag to the error log file when it has not observed the creation or modification event of the delivery file before the maximum execution time has elapsed. This operation does not trigger retry or reflow, but only performs forced termination and status archiving.

[0096] This application can, for example, calculate the deadline based on the system timestamp recorded when the scheduling engine starts the role and the preset maximum execution time, and continuously poll the timestamp changes of the delivery files in the task unit directory; this application can also, for example, be based on the operating system file system event listening mechanism, immediately triggering a status update when a delivery file creation or modification event occurs; furthermore, this application can also combine process monitoring data and API response timing data to initiate an early warning check when the accumulated time approaches the maximum execution time threshold. This application obtains the ability to determine the output status of delivery files in real time based on any of the above methods, thereby ensuring the timeliness and accuracy of timeout circuit breaker operations.

[0097] For example, this application may configure the maximum execution time for the coding role to be 300 seconds by the scheduling engine; when the role is activated, the engine records the start time t0; then continuously listens for file system events in deliverables / coder_output.json in the task unit directory; if the file creation event or mtime update event is not captured before t0+300 seconds, the engine calls the operating system kill command to terminate its associated process, sets the status field of the coder line in the status probe file to TIMEOUT, and writes the following to the error log: [2025-04-01T10:30:45Z] coder ERROR OPENAI v1.2408 TIMEOUT timeout after 300s.

[0098] This application achieves differentiated responses to different failure modes in a multi-agent collaborative pipeline by identifying anomaly types and triggering corresponding layered anomaly self-healing processes, combined with setting maximum execution time for agent roles and implementing circuit breaking operations when no delivery document is produced within the timeout period. For API call layer anomalies, convergent exponential backoff retries are used; for authentication layer anomalies, invalid waiting is avoided; for business logic layer anomalies, closed-loop backflow repair is supported; and for file access layer anomalies, precise path localization is provided. Simultaneously, the timeout circuit breaker mechanism prevents single-point blockages from affecting the timeliness of the entire pipeline, ensuring that the system as a whole has deterministic response boundaries and a controllable fault propagation range, thereby effectively improving the robustness, observability, and operational efficiency of multi-agent software development tasks.

[0099] In a further embodiment, the corresponding hierarchical anomaly self-healing operation is triggered based on the anomaly type, and the specific steps to be executed include: Step S431: When the exception type is an API call layer exception, execute the exponential backoff retry strategy.

[0100] Among them, API call layer exception can refer to transient communication or resource limitation exceptions that occur when an agent calls the large language model service interface, including but not limited to rate limit (RATE_LIMITED), network interruption (NETWORK_ERROR), request timeout (TIMEOUT) and server error (PROVIDER_ERROR). In the relevant technical field, this anomaly typically represents fluctuations in the availability of remote services or temporary overloads, and its inherent technical attributes are time dependence and recoverability. In this embodiment, the anomaly serves as the input for hierarchical anomaly self-healing processing, triggering the retry mechanism and determining the retry interval time strategy. This application, for example, can determine an API call layer exception based on the detected HTTP status code 429 or connection timeout signal, and initiate a retry after an initial wait of 60 seconds. Alternatively, it can determine a TIMEOUT-type exception based on API response timing data showing a single latency exceeding a preset threshold and two consecutive failures, and initiate a retry after an initial wait of 60 seconds. Furthermore, it can determine an API call layer exception based on error log entries marked as RATE_LIMITED, NETWORK_ERROR, TIMEOUT, or PROVIDER_ERROR, and initiate an exponential backoff retry process. This application achieves adaptive recovery capability against transient service anomalies based on any of the above methods, avoiding overall task failure due to short-term fluctuations.

[0101] For example, an implementation could involve the scheduling engine reading the latest log record from the error log file and parsing its error type identifier field. If the value of this field is RATE_LIMITED, it is determined that there is an API call layer exception, and an exponential backoff retry strategy is initiated. That is, the engine waits 60 seconds before the first retry, 120 seconds for the second, and 240 seconds for the third. Before each retry, the status of the corresponding role in the status probe file is updated to RETRY, and the global timestamp is refreshed. After three retries fail, the status is set to FAILED, and the execution of that role is terminated.

[0102] Step S432: When the exception type is an authentication layer exception, directly mark the agent role as a failure state; Among them, authentication layer exception refers to the failure of identity verification caused by invalid, missing or expired identity credentials before or during the initiation of an API call by the intelligent agent. It is typically manifested as HTTP status code 401 (Unauthorized) and error type identifier AUTH_FAILED. In the relevant technical field, this anomaly typically indicates an incorrect access key configuration or invalid permissions, and its inherent technical attributes are non-recoverable and highly deterministic. In this embodiment, the exception serves as one of the termination conditions for the hierarchical exception self-healing process, allowing all retry logic to be skipped, the failure status registration process to be entered immediately, and a manual intervention prompt to be triggered simultaneously. This application, for example, can determine an authentication layer exception based on an HTTP status code of 401 recorded in the error log and an error message containing the phrase "invalid API key," and immediately update the status of the corresponding role in the status probe file to FAILED. Alternatively, it can determine an authentication layer exception based on the scheduling engine capturing an authentication failure signal during API client initialization, and skip any subsequent retry actions. Furthermore, it can determine an authentication layer exception based on the error type identifier field value being AUTH_FAILED, and write a failure reason description in the status probe file. This application, based on any of the above methods, achieves the ability to quickly identify and block permanent authentication failures, preventing invalid retries from consuming system resources and delaying manual intervention.

[0103] For example, this application could involve the scheduling engine performing a key validity pre-check before calling the large language model API. If the pre-check fails (e.g., invalid key format, signature verification fails), no actual request is initiated, the role status is directly set to FAILED, and AUTH_FAILED: invalid API key format is written to the error log. If the pre-check passes but a 401 response is returned in the first request, it is also marked as FAILED, and the log entry AUTH_FAILED: server rejected provided credentials is appended.

[0104] Step S433: When the exception type is a business logic layer exception, the task is returned to the corresponding intelligent agent role, and the return count is incremented. When the return count reaches a preset threshold, the circuit breaker is triggered. Among them, Business Logic Layer Exception can refer to the failure of semantic consistency or functional compliance triggered by the intelligent agent's output content failing the downstream quality review. Its typical error type is identified as FAIL_BACK_TO_CODER. In the relevant technical field, this anomaly typically indicates a semantic deviation or rule violation between the model output and the task objective. Its inherent technical attributes are iterative correction and contextual dependency. In this embodiment, the anomaly serves as the trigger for the task closed-loop repair mechanism, driving the establishment of the deliverable feedback path, and achieving quantitative control of the number of repair attempts through backflow counting. This application, for example, can determine a business logic layer anomaly based on the presence of the `review_status:REJECTED` field and the explanation "reason: inconsistent with architecture spec" in the delivery file output by the quality review role, and then encapsulate the original task instructions and review feedback into a new delivery file, which is then sent back to the coding role. Alternatively, this application can determine a business logic layer anomaly based on the scheduling engine comparing the content hash values ​​of the upstream delivery file and the downstream review result file, finding that the difference exceeds a threshold, and then activate the reflow process. Furthermore, this application can determine a business logic layer anomaly based on the error type identifier "FAIL_BACK_TO_CODER" recorded in the error log, and update the reflow count field in the status probe file. Based on any of the above methods, this application obtains structured feedback and controllable iterative repair capabilities for semantic-level errors, supporting closed-loop quality evolution.

[0105] For example, this application could involve a quality review role generating a structured delivery document containing review conclusions after verifying the delivery document from the coding role. This document would explicitly indicate `review_status: REJECTED` and `feedback: missing null-check in function X`. Upon detecting this delivery document, the scheduling engine would parse its content, confirm an anomaly in the business logic layer, and inject the document as a new Directive into the coding role's task layer. The `retry_count` field in the status probe file would be incremented from 0 to 1. If the coding role produces another rejected delivery document, the scheduling engine would continue incrementing the count to 2. When the count reaches a preset threshold of 3, the scheduling engine would no longer initiate a retry, but instead set the role status to `CIRCUIT_BREAK` and record in the error log: `CIRCUIT_BREAK: retry count reached threshold3 for role coder`.

[0106] Step S434: When the exception type is a file access layer exception, directly mark the agent role as a failure state and record the affected file path; Among them, File Access Layer Exception refers to the failure of operating system-level I / O due to insufficient permissions, non-existent path, full disk, or file lock conflict during the execution of file read and write operations by the agent. Its typical error type is marked as FILE_ACCESS_ERROR. In the relevant technical field, this anomaly typically represents a mismatch between the underlying file system constraints and the role capability layer whitelist, and its inherent technical attributes are local determinism and path traceability. In this embodiment, the exception serves as a real-time verification signal for the effectiveness of the permission isolation mechanism, used to synchronize the failure status and specific path information, supporting permission policy auditing and debugging. This application can, for example, determine a file access layer exception based on the EACCES or ENOENT error codes returned by the operating system when the scheduling engine intercepts a write operation, and extract the target path where access is denied. Alternatively, it can determine a file access layer exception based on the access denied event and its accompanying path parameters reported by the file system event listening module, and write the path to the error log. Furthermore, it can determine a file access layer exception based on the Skill executor returning a negative result when verifying whether the target path is within the write whitelist, and synchronously record the path. Based on any of the above methods, this application achieves the ability to instantly intercept, accurately locate, and auditably record permission violations.

[0107] For example, this application could involve a coding role attempting to write code to the path / src / main / java / com / example / Service.java. When the skill executor of the scheduling engine checks whether the path belongs to the current role's write whitelist, it returns no, and then intercepts the operation, sets the role's status to FAILED, and appends the following record to the error log: FILE_ACCESS_ERROR: write access denied to / src / main / java / com / example / Service.java — not in skill-layer write whitelist.

[0108] This application alleviates instantaneous server pressure and improves recovery probability by triggering exponential backoff retries through API call layer exceptions; it directly marks failures through authentication layer exceptions to quickly expose key configuration problems and guide timely manual replacement; it drives task reflow and circuit breaking through counting through business logic layer exceptions to prevent infinite loops while allowing limited iterations; and it synchronizes failure status and specific paths through file access layer exceptions to support traceability verification and debugging optimization of permission policies. The handling strategies for each exception type are independent, have clear boundaries, and respond accurately, collectively forming a layered self-healing system covering multi-dimensional fault scenarios. This significantly improves the robustness and maintainability of the multi-agent collaborative pipeline without increasing the frequency of manual intervention.

[0109] In summary, by constructing a three-layer SSD permission model and combining it with mechanisms such as dynamic whitelists, four-layer prompt word isolation, real-time status probes, and layered anomaly self-healing, the embodiment achieves fine-grained and dynamic control of permissions and intelligent and differentiated handling of anomalies in a multi-agent collaborative system, effectively improving the system's security, reliability, and automation level.

[0110] Based on the same inventive concept, a second aspect also discloses a dynamic adjustment device for multiple agents based on an SSD architecture, comprising: The model building module 100 is used to build a multi-layered permission model for intelligent agent roles. The multi-layered permission model includes an identity layer for the identity information of the intelligent agent, a capability layer for determining the permissions of the intelligent agent, and a task layer for determining the tasks of the intelligent agent. The rights isolation module 200 is used to obtain delivery documents. The multi-layered permission model isolates the rights of each intelligent agent role according to the delivery documents. Permission isolation is achieved by using the identity layer to constrain identity, the capability layer to determine operation permissions, and the task layer to determine the task to be executed, so as to achieve the least permission isolation at the role level. The task execution module 300 is used to generate a four-layer concatenated system prompt based on isolation permissions and execute tasks according to the system prompt. The anomaly repair module 400 is used to obtain real-time status change information and execution anomaly information of the executed task, analyze the anomaly information, and execute corresponding repair strategies.

[0111] The modules in the aforementioned SSD-based multi-agent dynamic adjustment device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the computer device's memory as software, so that the processor can invoke and execute the corresponding operations of each module.

[0112] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. This disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims. Thus, if these modifications and variations of the invention fall within the scope of the claims of the invention and their equivalents, the invention is also intended to include these modifications and variations.

Claims

1. A method for dynamic adjustment of multiple agents based on SSD architecture, characterized in that the steps include... include: Construct a multi-layered permission model for intelligent agent roles, wherein the multi-layered permission model includes an identity layer for the identity information of the intelligent agent, a capability layer for determining the permissions of the intelligent agent, and a task layer for determining the tasks of the intelligent agent; The delivery document is obtained, and the multi-layered permission model isolates the rights of each intelligent agent role according to the delivery document. The permission isolation is achieved by constraining identity through the identity layer, determining operation permissions through the capability layer, and determining the tasks to be executed through the task layer, so as to achieve the minimum permission isolation at the role level. Generate a four-layer concatenated system prompt based on isolation permissions, and execute the task based on the system prompt; Obtain real-time status change information and execution exception information of the task being executed, analyze the exception information, and execute corresponding repair strategies.

2. The dynamic adjustment method according to claim 1, characterized in that, The permission isolation also requires dynamic adjustment of the whitelist based on the delivery documents to restrict permissions. The real-time whitelist dynamic modulation determines the source code file of the task target based on the delivery documents, dynamically provides a whitelist according to different tasks, and verifies the target path against the whitelist during operation.

3. The dynamic adjustment method according to claim 1, characterized in that, The process of determining operation permissions through the capability layer involves: after determining the identity and role of the target intelligent agent at the identity layer, extracting a set of paths from the delivery file, generating a whitelist, and injecting the whitelist into the capability layer of the target intelligent agent's role to determine the agent's permissions.

4. The dynamic adjustment method according to claim 3, characterized in that, The path set is extracted from the delivery file and used to generate a whitelist, including: Parse the delivery file and locate the task allocation block marked in the delivery file; The file paths of the target tasks are extracted from the predetermined columns of the task allocation block to form a path set; Configure the set of paths as a whitelist for the target intelligent agent role.

5. The dynamic adjustment method according to claim 1, characterized in that, The system prompt message generated based on isolation permissions and consisting of four layers is: The four-layer concatenation of prompt words involves extracting prompt word information from the delivery document, placing it into an isolated four-layer structure, and concatenating them in hierarchical order to generate system prompt words for the intelligent agent performing the task. The four-layer structure includes a first-layer project context file, which provides project background knowledge; a second-layer global guidelines file, which provides general behavioral norms; a third-layer agent identity and role file, which provides role-specific identity and behavioral constraints; and a fourth-layer delivery file for upstream agent roles.

6. The dynamic adjustment method according to claim 1, characterized in that, The process of obtaining real-time status change information and execution exception information of the task being executed is as follows: The real-time state change information is: real-time acquisition of the state changes of the intelligent agent role to obtain underlying monitoring data, and establishment of a real-time state probe file based on the underlying monitoring data. The real-time state probe file includes process monitoring data, API response timing data and file system event data. The execution exception information is: when an execution exception occurs, the exception information is written to the execution log file in a structured format.

7. The dynamic adjustment method according to claim 6, characterized in that, The update of the status probe file based on the underlying monitoring data includes: Based on the process monitoring data, the start and termination events of the process corresponding to the intelligent agent role are determined; Based on the API response timing data, determine the single time and cumulative time of the intelligent agent role in making model calls; The creation or modification event of the delivered file is determined based on the file system event data; Based on the start event, the termination event, the cumulative time consumed, and the creation or modification event, determine the current state of the intelligent agent role; The current state, start time, end time, and cumulative time are written into the state probe file in the form of a structured table, and the global timestamp of the state probe file is updated each time it is written.

8. The dynamic adjustment method according to claim 1, characterized in that, The step of analyzing and executing corresponding repair strategies based on abnormal information is as follows: obtaining abnormal information, analyzing the abnormal type to trigger corresponding layered abnormal self-healing processing, wherein the abnormal types include API call layer abnormalities, authentication layer abnormalities, business logic layer abnormalities, and file access layer abnormalities; The corresponding protection strategy is to set a maximum execution time for the agent role, and to perform a timeout circuit breaker operation if no delivery document is detected from the agent role within the maximum execution time.

9. The dynamic adjustment method according to claim 8, characterized in that, The step of triggering the corresponding hierarchical exception self-healing processing operation based on the exception type includes: When the exception type is an API call layer exception, an exponential backoff retry strategy is executed. When the exception type is an authentication layer exception, the agent role is directly marked as a failure. When the exception type is a business logic layer exception, the task is returned to the corresponding intelligent agent role, and the return count is incremented. When the return count reaches a preset threshold, the circuit breaker is triggered. When the exception type is a file access layer exception, the agent role is directly marked as a failure and the affected file path is recorded.

10. A dynamic adjustment device for multiple agents based on SSD architecture, characterized in that, include: The model building module is used to construct a multi-layered permission model for intelligent agent roles. The multi-layered permission model includes an identity layer for the identity information of the intelligent agent, a capability layer for determining the permissions of the intelligent agent, and a task layer for determining the tasks of the intelligent agent. The rights isolation module is used to obtain delivery documents. The multi-layered permission model isolates the rights of each intelligent agent role according to the delivery documents. The permission isolation is achieved by using an identity layer to constrain identity, a capability layer to determine operation permissions, and a task layer to determine the tasks to be executed, so as to achieve the least-permission isolation at the role level. The task execution module is used to generate a four-layer concatenated system prompt based on isolation permissions, and execute tasks based on the system prompt. The anomaly repair module is used to obtain real-time status change information and execution anomaly information of the executed task, analyze the anomaly information, and execute corresponding repair strategies.

Images