Task processing method, device and storage medium

Abstract

Embodiments of the present application provide a task processing method and device and a storage medium, which belong to but are not limited to the technical field of artificial intelligence; the method is applied to a terminal device deployed with a first agent, and the method comprises: the first agent generates at least one level of sub-agents according to a target main task, to obtain multi-level agents; the task control authority of each sub-agent is determined in real time according to an assigned task, and the task assigned by the second agent is a distributable task; the third agent is assigned an atomic task; the third agent executes the corresponding atomic task according to the respective task control authority, to obtain a first execution result; the first execution result is subjected to operation authority purification processing by an authority management service, to obtain a second execution result; the second execution result of the next level is subjected to task acceptance processing by the second agent. The embodiments of the present application can improve the security of system access resources in the process of task processing by the agent.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a task processing method, device and storage medium. Background Technology

[0002] With the continuous development of multi-level, multi-agent architectures, they are not only widely used in software development, office automation, data analysis, and customer service, but are also gradually penetrating professional fields such as AI-assisted chip design. Correspondingly, the security requirements during agent task processing are increasing. Especially in AI-assisted chip design, agents call tools for file reading and writing, code generation, simulation, synthesis, and static analysis, as well as processing RTL code, constraint files, and tool reports. This results in different operation types, resource scopes, and permission strengths required for tasks assigned to different agents. If resource operations cannot be effectively controlled during multi-agent task collaboration, it can lead to illegal reading and writing or parameter tampering, potentially causing erroneous modifications to RTL code, constraint files, or verification scripts. This results in chip design rework, project delays, and a significant increase in chip design costs. Therefore, how to improve the security of system resource access during multi-agent collaborative task processing is a pressing technical problem that needs to be solved. Summary of the Invention

[0003] The main objective of this application is to propose a task processing method, device, and storage medium that can improve the security of system access to resources during multi-agent collaborative task processing.

[0004] To achieve the above objectives, a first aspect of this application proposes a task processing method applied to a terminal device, wherein the terminal device is equipped with a first intelligent agent, and the method includes: In response to receiving a task processing request for a target main task, the first agent generates at least one level of sub-agents based on the target main task, resulting in a multi-level agent; wherein, the task control authority of each agent is determined in real time according to the assigned task, and there is a second agent in the multi-level agent whose assigned task is a distributable task; there is a third agent in the multi-level agent whose assigned task is an atomic task. The third intelligent agent is controlled to execute the corresponding atomic task according to its respective task control authority, and a first execution result is obtained; The permission management service performs operation permission purification on the first execution result of the third intelligent agent, and sends the second execution result obtained from the operation permission purification process to the parent intelligent agent of the third intelligent agent. The second intelligent agent performs task acceptance processing on the second execution result of the third intelligent agent at the next level according to the corresponding distributable task; The first intelligent agent determines the execution result of the target main task based on the result of the task acceptance process.

[0005] To achieve the above objectives, a second aspect of the present application provides an electronic device, comprising: at least one processor; wherein at least one first intelligent agent is deployed on the processor, and each first intelligent agent executes the task processing method described in any one of the first aspects.

[0006] To achieve the above objectives, a third aspect of the present application provides a computer-readable storage medium, wherein the computer-executable instructions are configured to be executed by a processor using the task processing method described in any one of the first aspects.

[0007] The task processing method, device, and storage medium proposed in this application generate sub-agents at different levels based on the target main task on a first intelligent agent. The task permissions of each intelligent agent are determined in real-time according to the assigned task, ensuring that each intelligent agent's permissions are only sufficient to execute the assigned task. This reduces the scope of permission propagation along the derivation chain, thereby lowering the security risks associated with resource access. Simultaneously, during the process of the third intelligent agent (acting as a sub-agent) transmitting the first execution result upwards, the first execution result is purified through a permission management service, ensuring that the returned payload does not carry permission boundary information, thus reducing the risk of permission state backflow and information leakage. Therefore, compared with related technologies, the embodiments of this application can control the permissions of intelligent agents during task processing from multiple dimensions, ensuring that the target task operates on accessed resources within controlled access throughout the entire execution chain, thereby improving the security of system resource access during task processing. Attached Figure Description

[0008] Figure 1 This is a flowchart illustrating an embodiment of the task processing method provided in this application; Figure 2 This is a schematic diagram of the task processing process of one embodiment of the task processing method provided in this application; Figure 3 This is a schematic diagram illustrating the permission constraint relationship between various intelligent agents in one embodiment of the task processing method provided in this application; Figure 4 This is a schematic diagram of the purification process of the execution result sent by the third intelligent agent to the second intelligent agent in one embodiment of the task processing method provided in this application; Figure 5 This is a schematic diagram of the hardware structure corresponding to the task processing method provided in this application. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0010] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0011] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0012] With the continuous development of multi-level, multi-agent architectures, they are not only widely used in software development, office automation, data analysis, and customer service, but are also gradually penetrating into professional fields such as AI-assisted chip design. Correspondingly, the security requirements during agent task processing are increasing. Especially in AI-assisted chip design, agents call tools for file reading and writing, code generation, simulation, synthesis, and static analysis, as well as process RTL code, constraint files, and tool reports. This results in different operation types, resource scopes, and permission strengths required for tasks assigned to different agents. If resource operations cannot be effectively controlled during multi-agent task collaboration, it can lead to illegal reading and writing or parameter tampering, potentially causing erroneous modifications to RTL code, constraint files, or verification scripts. This results in chip design rework, project delays, and a significant increase in chip design costs. For example, existing solutions pre-configure restricted permissions for agents, but in AI-assisted chip design, the need for dynamic agent derivation means that the permissions of sub-agents cannot be pre-configured, easily leading to out-of-bounds access to resources. For example, in existing technologies, even if chip AI-assisted design employs a fixed multi-level, multi-agent architecture, enabling sub-agents at each level to predict and configure corresponding controlled permissions, in practical applications, sub-agents, due to their autonomous reasoning capabilities, may return results containing information about permission requirements and statuses when performing specific resource operations. When the sub-agent sends the execution result to the next-level agent, the next-level agent may learn the new permission or strengthen its own permission from the result, thus changing its own permissions and creating security risks when the sub-agent accesses resources in subsequent operations. Therefore, improving the security of system resource access during multi-agent collaborative task processing is a pressing technical problem. Based on this, embodiments of this application provide a task processing method, device, and storage medium that can improve the security of system resource access during multi-agent collaborative task processing.

[0013] Understandably, referring to Figure 1 As shown, a task processing method according to an embodiment of this application is applied to a terminal device, the terminal device being equipped with a first intelligent agent, the method comprising: Step S100: In response to receiving a task processing request for the target main task, the first intelligent agent generates at least one level of sub-intelligent agents according to the target main task, resulting in a multi-level intelligent agent; wherein, the task control authority of each intelligent agent is determined in real time according to the assigned task, and there is a second intelligent agent in the multi-level intelligent agent and the assigned task is a distributable task; there is a third intelligent agent in the multi-level intelligent agent and the assigned task is an atomic task. Step S200: Control the third intelligent agent to execute the corresponding atomic task according to its respective task control authority, and obtain the first execution result; Step S300: Perform operation permission purification on the first execution result of the third intelligent agent through the permission management service, and send the second execution result obtained by the operation permission purification to the first-level intelligent agent of the third intelligent agent; Step S400: Each second agent performs task acceptance processing on the second execution result of its next-level third agent according to the corresponding distributable task. Step S500: The first intelligent agent determines the execution result of the target main task based on the result of the task acceptance process.

[0014] Therefore, by generating sub-agents at different levels based on the target main task on the first agent, and ensuring that the task permissions of each agent are determined in real time according to the assigned task, the permissions of each agent are only sufficient to execute the assigned task, reducing the scope of permission propagation along the derivation chain and thus reducing the security risk of accessing resources. Simultaneously, during the process of the third agent (as a sub-agent) sending the first execution result back upwards, the first execution result is purified through a permission management service, ensuring that the returned payload does not carry permission boundary information, thereby reducing the risk of permission state backflow and information leakage. Therefore, this embodiment can control the permissions of agents during task processing from multiple dimensions, ensuring that the target task operates on accessed resources within controlled access throughout the entire execution chain, thereby improving the security of system access to resources during task processing.

[0015] The second and third intelligent agents are logically classified based on the task type of the assigned task, and belong to logical intelligent agents. The first intelligent agent is a physically deployed (or instantiated on a terminal device) intelligent agent that receives the target task. The same instantiated intelligent agent can logically be identified as either the second or third intelligent agent, or simultaneously as both. For example, taking the first intelligent agent as an example, if there are subdivided tasks in the target main task that are distributed to the next level intelligent agent, that is, if there are distributable tasks on the first intelligent agent that are executed by the next level sub-intelligent agents, then the first intelligent agent can be identified as the second intelligent agent. If some subdivided tasks in the target main task are not distributed to the next level intelligent agent, that is, if there are atomic tasks on the first intelligent agent that need to be executed by the first intelligent agent, then the first intelligent agent can also be identified as the third intelligent agent. This application embodiment will not elaborate on these points one by one.

[0016] Different first intelligent agents perform different functions, and multiple first intelligent agents with different functions can be deployed on the terminal device. This application will not elaborate on these differences in its embodiments. In some embodiments, the first intelligent agent can be a code management intelligent agent used for quality control of code. Correspondingly, the first execution result may include quality data from calling tools to perform quality control of code files, or response data from writing back the quality data. In other embodiments, the first intelligent agent can be an operation and maintenance management intelligent agent used for operation and maintenance monitoring of equipment. The first execution result may include monitoring data from equipment monitoring. In still other embodiments, the first intelligent agent is a chip quality control intelligent agent used for quality control of the chip design process. The first execution result may include the chip's code detection results. This application will not elaborate on these differences in its embodiments.

[0017] Distributable tasks are tasks that can be further broken down to derive the next level of agents, while atomic tasks are tasks that do not require further breakdown and are executed directly by the current agent. Distributable tasks and atomic tasks belong to two different task types. For example, if the main target task is broken down into task 1, task 2, and task 3 in the first agent, and agents 1 and 2 are generated accordingly, with task 1 assigned to agent 1 and task 2 assigned to agent 2, then for the first agent, task 3 is an atomic task. If task 1 can also be broken down by agent 1 into task 4 and task 5, and agent 3 corresponding to task 5 is derived, then for agent 1, task 1 is a distributable task, and task 4 is an atomic task.

[0018] This application does not limit the hierarchy of sub-agents. In practical applications, the hierarchy of sub-agents is related to the access resources required by the target task, and those skilled in the art can selectively set it according to actual needs.

[0019] In this embodiment, the task control permissions of each intelligent agent are set to be determined in real time according to the assigned task. This can strongly bind the intelligent agent's operation process and task control permissions for system resources, thereby improving the security of system access to resources.

[0020] This application embodiment does not limit how the task processing request is triggered. It can be triggered manually, by a script, or automatically by the device. This application embodiment will not elaborate on these points.

[0021] This application does not restrict how the third agent starts executing the atomic task. It can be that the first agent triggers the start command, causing each third agent to be triggered, or it can be that the agent is derived from the target main task and starts actively. This application does not restrict this.

[0022] Operation permission purification is used to prevent higher-level agents from being aware of the boundary permissions of lower-level agents. Operation permission purification can involve deletion, replacement, or setting identifiers; these will not be elaborated upon in the embodiments of this application.

[0023] In some embodiments, the first execution result can be directly and separately sent to the permission management service, where it undergoes operation permission purification before being sent to the next-level intelligent agent. The second execution result is then the purified information from the first execution result. In other embodiments, when a derived intelligent agent contains both atomic tasks and distributable tasks, the first execution result can be sent to the permission management service along with the execution results of the distributable tasks. The corresponding second execution result is the purified information from both. This application will not elaborate on these details in its embodiments. In practical applications, the returned execution result is adjusted according to the execution dependencies between tasks assigned to intelligent agents instantiated at the same level.

[0024] Task acceptance processing refers to whether the task assigned to the third intelligent agent has been completed and the processing of business data summarization of the second execution result. This application embodiment will not elaborate on these aspects.

[0025] In this application, there is no restriction on whether the sub-intelligent agents are all derived from the same first intelligent agent or from the first intelligent agent and its corresponding branched intelligent agents. Those skilled in the art can selectively set this according to actual needs.

[0026] The embodiments of this application do not limit the type of terminal device, which can be a server, workstation or other electronic device.

[0027] For example, taking the case where all sub-agents are derived from the first agent, refer to... Figure 2 The general flow of the task processing method according to the embodiments of this application is described as follows: S1. Determine the current permission status of the parent agent: The first agent obtains the target main task and determines the parent permission item of the first agent according to the target main task: Among them, at least one parent permission item is set, and each parent permission item includes operation type (such as read, write and execute, etc.), resource range (that is, the resources that the operation type can operate on) and strength value; S2. Generate Derived Agents: For example, based on the target main task, at least one candidate derived task is generated. For each candidate derived task, the following steps are performed through the permission management task to obtain the task control permissions of the candidate derived task: determine the intersection of the task requirement permissions corresponding to its task requirements and the parent permissions of the parent agent to obtain the inherited permissions, and attenuate the inherited permissions based on the attenuation coefficient, and determine the task control permissions of the candidate derived task based on the attenuation result. The permission items included in the task requirement permissions may include all or some of the parent permission items. In some embodiments, the permission items included in the task requirement permissions also include permissions other than the parent permission items. In other embodiments, some permissions in the task requirement permissions may be permissions in the parent permission items. In other embodiments, the task requirement permissions may also have no intersection with the permissions of the parent agent. Therefore, when it is determined that the inherited permissions of a candidate derived task are empty, it is not necessary to derive an agent for that derived task. Among them, the derived intelligent agent (i.e. the aforementioned sub-intelligent agent) can run on the operating system in the form of a process or a service embedded in the framework; for example, if the parent intelligent agent has parent permissions 1, 2 and 3, and the task requirement permissions of the derived task 1 of the derived intelligent agent include permissions 2 and 4; then, the strength attenuation calculation is performed on permission 2 to obtain inherited permission 2. Since the inherited permissions of the derived task 1 are not empty, then the derived intelligent agent 2 is created. At this time, the task assigned to the derived intelligent agent 2 is the derived task 1, and the task control permissions of the derived task 1 include inherited permission 2. S3. Derived agents perform specific resource operations: For example, when the task assigned to a derived agent by the parent agent is an atomic task, the resource operations contained in that atomic task are executed. S4. Does the derived agent determine whether the permissions required for the resource operation exist? Here, the resource operation is the operation required to complete the atomic task. For example, the derived agent matches the permissions required for the specific resource operation with the task control permissions of the derived agent to determine whether the permission item exists; if yes, then execute S5; if no, then refuse the operation. S5. Determine if the strength value of the permission item required for the resource operation is greater than or equal to the strength threshold. If it is, proceed to S6; otherwise, proceed to S7. S6. Execute directly, which means there is no need to perform real-time verification of the current resource operation; S7. Single confirmation operation and no write-back, that is, real-time verification of the current resource operation, which can be based on the confirmation of the user interface or other methods. This application embodiment will not elaborate on these in detail. S8. Return the first execution result; S9. Perform operation permission purification processing on the first execution result.

[0028] In summary, according to steps S1 to S9 of the above embodiments, in the entire execution chain of the target main task, the task control permissions at each level tighten downwards as they derive; if a resource operation on a certain level of agent is insufficient in strength, only confirmation is requested for the single operation; after confirmation, only this resource operation is allowed to be executed and no write-back is allowed; after the operation is completed, the confirmation request for the single operation becomes invalid, and no permission write-back will cause permission elevation; in some embodiments, if the task is divided into multiple branches during the allocation of agents, each branch starts from the state at the moment of fork and changes independently; finally, when the results are returned upwards by each sub-agent, the information that exposes the permission boundary in the returned execution results is deleted, replaced, truncated, or rewritten as a restricted marker. In this way, subsequent agents cannot obtain a higher level of permission than their derived calculations simply because a confirmation is passed or permission information is included in the returned result. Since forked agents can only obtain a snapshot of the permission state at the time of forking, in this embodiment, each level of agent can only manage resource operations with the task control permissions at the time of agent creation, so that agents will only perform resource operations around the assigned tasks, resulting in higher resource security.

[0029] The operation permission purification process described in the above embodiments of this application is performed by an independent permission management service.

[0030] Understandably, the first agent generates at least one level of sub-agents based on the target main task, including: The first intelligent agent takes itself as a candidate parent intelligent agent and the target main task as a task to be split and executes the child intelligent agent derivation process to generate child intelligent agents. For each sub-agent generated by the sub-agent derivation process, when the candidate derivation task assigned to the sub-agent is a distributable task, the sub-agent will take itself as the candidate parent agent, take the candidate derivation task as the task to be split, and execute the sub-agent derivation process. The sub-agent derivation process includes the following steps: The candidate parent agent splits the task to be split into at least one candidate derived task. If the inherited permission of the candidate derived task is determined to be a non-empty permission through the permission management service, the task control permission corresponding to the candidate derived task is obtained by the permission management service. Here, the inherited permission represents the intersection of the parent agent's task control permission and the corresponding task requirement permission of the candidate derived task. The task control permission of the candidate derived task includes the permission obtained by attenuating the corresponding inherited permission based on the derivation attenuation coefficient. Based on the task control permissions of the candidate derived tasks, sub-agents corresponding to the candidate derived tasks are derived.

[0031] When the inheritance permission is empty, it means that the corresponding candidate derived task is an atomic task and no corresponding sub-agent is derived.

[0032] The derivation decay coefficient is used to attenuate inherited permissions. In some embodiments, the inherited permissions can be weighted based on the derivation decay coefficient to obtain the task inheritance control permissions. The derivation decay coefficients corresponding to sub-agents at different levels can be the same or different. In some embodiments, the derivation decay coefficient λ satisfies 0 < λ < 1.

[0033] Therefore, by first performing intersection calculation and obtaining inheritance permissions in the sub-agent derivation process, and then weakening the inheritance permissions to obtain the actual inheritance permissions of the derived agent for the derived task, it can be ensured that subsequent sub-agents will not acquire permissions not held by the parent agent, and that the availability of inherited permissions will not be higher than the availability of permissions of the parent agent. At this time, with each additional hop down the derivation chain, the permission boundary of the entire target main task will be tightened once, so that the permission boundary of the entire execution chain of the target main task can be continuously converged, thereby ensuring the security of access resources involved in the execution of the target main task.

[0034] For example, taking agent A as the first intelligent agent, then refer to... Figure 3 The execution process of the derived intelligent agent chain is as follows: Step 1: Determine the permission state P of agent A based on the target main task. For example, assuming the target main task indicates that file reading is required on R1, record writing is required on R2, and tool invocation is required on R3, then the permission state P of agent A is P = {{read, R1, 1.0}, {write, R2, 1.0}, {execute, R3, 0.6}}, where read, write, and execute represent the operation type of the permission item, R1, R2, and R3 represent the resource scope of the operation, and 1 and 0.6 represent the strength of the permission item. Step 2: Based on Task 1, which is decomposed from the main target task, agent B is derived. Task 1 needs to read files from R1 and write records to R2. It inherits the read and write permissions from agent A. Therefore, assuming the derivation attenuation coefficient is 0.8, the effective permissions of the derived agent B are {{read, R1, 0.8}, {write, R2, 0.8}}. Step 3: Agent B, based on Task 2 derived from Task 1, derives Agent C. Task 2 also requires reading files from subdirectories under R1 and writing records to subdirectories under R2. Assuming the derivation decay coefficient between Agent C and Agent B is 0.6, then Agent C's effective permissions are {{read, R1, 0.48}, {write, R2, 0.48}}. Figure 2As shown, if the strength threshold is assumed to be 0.5, then when agent C performs the atomic task 2, each resource operation requires a single confirmation. Step 4: When the target main task needs to be executed using a different strategy, agent A can be forked to create agent A', and the permission state snapshot of agent A at the time of forking can be assigned to the forked agent A'; at this time, if Figure 3 As shown, the permission state of agent A' is {{read, R1, 1.0}, {write, R2, 1.0}, {execute, R3, 0.6}}. Agents A and A' then evolve independently in their respective permission states; a change in the permission state of one does not alter the permission state of the other.

[0035] Therefore, in summary Figure 3 As shown, in this embodiment, a child agent is derived only when the derived task on the parent agent contains the permissions currently held by the parent agent. Furthermore, the strength of the inherited permissions is weakened by a derivation decay coefficient, which allows the inherited permissions to accumulate along the execution chain of the target main task. The longer the execution chain of the target main task, the weaker the strength of the inherited permissions. This reduces the out-of-bounds handling of access to resources caused by permission diffusion and improves the security of accessing resources.

[0036] in, Figure 3 The permission status in the example can be described using structured language or natural language. This application embodiment will not elaborate on these details. The structured language description can also be presented using lists, template identifiers, or other methods. When permission template identifiers are used, the corresponding operation type and resource scope can be obtained by parsing a preset template mapping table. This application embodiment will not elaborate on these details.

[0037] Understandably, an atomic task includes at least one resource operation. A third-party intelligent agent executes the corresponding atomic task according to its respective task control authority to obtain a first execution result, including: For each resource operation, if the third agent determines that the configured task control permissions do not include the permission item corresponding to the resource operation, it refuses to execute the resource operation. For each resource operation, when the third agent determines that the configured task control permissions include the permission items corresponding to the resource operation and the strength of the permission items is greater than or equal to the preset strength threshold, the resource operation is executed directly. For each resource operation, when the third agent determines that the configured task control permissions include the permission items corresponding to the resource operation and the strength of the permission items is less than the strength threshold, a single sub-threshold operation confirmation process is executed.

[0038] Therefore, by considering the strength threshold and the presence or absence of permission items, the system determines whether the current resource operation request should be executed directly, enter a single-threshold operation confirmation, or be directly rejected. This allows permission strength to directly participate in task execution control, further enhancing the constraint on resource operations on the target main task.

[0039] Resource operations can be read operations, write operations, or operations involving accessing resources, such as calling tools. This application will not elaborate on these operations in detail, but those skilled in the art can configure the corresponding resource operations according to actual task requirements.

[0040] The strength threshold indicates that the permission strength is low, and the corresponding resource operation can only be performed after real-time permission confirmation. Real-time permission confirmation can be performed by popping up a user confirmation interface. In other embodiments, real-time permission confirmation can also be performed by a third party. This application does not limit this.

[0041] The intensity threshold can be adaptively adjusted based on the risk level of the task or the role information of the sub-agent.

[0042] Understandably, the single sub-threshold operation confirmation process includes: The third agent generates a one-to-one correspondence between a single confirmation request and a resource operation, and obtains a one-time execution token generated by the single confirmation request. The one-time execution token is generated when the single confirmation request is confirmed within a preset time. The third agent executes the corresponding resource operation based on the one-time execution token, and invalidates the one-time execution token and enables the no-write-back constraint after the resource operation is completed or the validity period of the one-time execution token expires.

[0043] Since the single confirmation request in the single sub-threshold operation confirmation process only generates a one-time execution ticket (i.e., a one-time execution token) bound to the current resource operation, and does not enable write-back constraints, the first execution result of the current agent completing the task will not write back to improve its own permission strength, nor will it expand the resource scope or change the subsequent derivation basis.

[0044] The expiration of a one-time execution token constrains the validity period of the execution credential. If the resource operation is completed or the validity period expires, the one-time execution token cannot be used for other resource operations. This application embodiment also configures a non-write-back constraint for the third agent executing the one-time execution token, ensuring that the confirmation result does not affect the agent's persistent permission state. Therefore, after successful confirmation, the strength value of the corresponding permission item is neither increased nor the scope of accessible resources is expanded. Furthermore, the confirmation result cannot be used as the source of subsequent derived permissions for the agent. Therefore, by using the one-time execution token combined with the non-write-back constraint in this application embodiment, the permission strength of the third agent remains at its decayed value even after multiple successful confirmations, and will not increase with the accumulation of confirmations.

[0045] "A single confirmation request is approved within a preset time" indicates confirmation of whether the current resource operation is allowed to execute. The single confirmation request can be initiated directly through the interaction channel. In other embodiments, it can also be initiated along the agent's call chain from the nearest confirmation node on the call chain. If no confirmation node exists or confirmation fails, a one-time execution token cannot be obtained. In some embodiments, the confirmation node is set to a node with a user interface. When a single confirmation request is approved, only a one-time execution token bound to the current resource operation is generated, and the current resource operation is executed accordingly. If confirmation times out, it is treated as a failed confirmation. The confirmation result does not change the current task control permissions, nor does it serve as a source of subsequent derived permissions.

[0046] One-time execution tokens are used to record the type, object, and validity period of an operation. When the validity period expires or the corresponding resource operation is completed, the one-time execution token becomes invalid. This ensures that every resource operation requiring a certain permission on the agent will trigger a sub-threshold single confirmation, even if the strength of the permission item is less than the strength threshold. Once the one-time execution token expires, it cannot be used for other resource operations.

[0047] For example, such as Figure 2 As shown, assuming the preset threshold is Then when the intensity value is greater than or equal to the threshold If the condition is met, the operation will proceed directly; otherwise, a single confirmation operation will be performed, and the operation will only be executed this time without writing back.

[0048] This application embodiment achieves one-time clearance without write-back through a single subthreshold operation confirmation process. In high-frequency autonomous operation scenarios, it further reduces the probability of write-back leading to increased permission strength, while also reducing the probability of resource scope expansion. For example, in a high-frequency autonomous operation scenario for an agent, assuming the first execution result carries permission information that can update the authorization status, compared to the single-execution write-back technical solution in this application embodiment, the prior art's single-execution write-back technical solution gradually offsets the attenuation effect under repeated confirmation. If the initial strength is s, after N hops of derivation, the strength attenuates to... Let the threshold be θ, and assume the write-back boost amount for each confirmation is δ. Then, for the existing technical solution, after k confirmations, does it satisfy the following condition? In such cases, the permission item on the same intelligent agent will return to above the threshold, and subsequent similar operations will bypass confirmation and be executed directly. Therefore, the above technical solution of this application embodiment can further improve the security of accessing resources.

[0049] Understandably, the method also includes: When the candidate parent agent determines that the assigned task has multiple execution strategies, agent fork construction is performed on the candidate parent agent to obtain the forked agent; Obtain a snapshot of the permission state of the candidate parent agent at the time of agent fork construction, and assign the permission state snapshot to the forked agent. The forked agent is used to generate a child agent corresponding to the forked agent based on the permission state snapshot.

[0050] Because agent forking uses a snapshot of the permission state at the moment of agent forking construction, it creates two independent parallel branches between the forking agent and the parent agent. These two parallel branches can evolve independently from defined boundaries, and state changes on one branch will not pollute the other. Simultaneously, combined with the purification processing of execution permission-related information (including information related to the agent's own permissions and restricted permissions) during the return phase, bidirectional permission constraints can be formed along the complete execution chain of the target main task. This ensures that even if the next level agent in each layer of the target main task's execution chain has completed the task under controlled conditions, it cannot bring its permission state, one-time execution ticket, forking identifier, or restricted path traces back to the upper layer through the return result. This reduces the risk of permission boundaries being reconstructed along the return channel, further ensuring that the permissions of each level of agent are maintained and updated at the time of derivation, thereby ensuring the security of accessed resources during the execution of the target main task.

[0051] The permission state snapshot records the tasks assigned by the parent agent at the time of agent fork construction and the permissions required for those tasks; the parent agent can be the first agent or any child agent at any level, and this application embodiment does not impose any restrictions on this.

[0052] The execution strategy indicates that there are multiple ways to combine the agents required to perform the task. For example, taking the target main task as performance scoring, one scoring method is to average the scores based on indicators 1 to 5, and another scoring method is to perform a weighted calculation based on indicators 2 to 7. The first agent can be used to construct branch agents to execute different strategies for the same task, and then the results are summarized by the first agent.

[0053] For each forked agent, its usage can be referenced to that of the parent agent constructed by the fork. This application's embodiments will not elaborate on this further.

[0054] Understandably, the operation permission is purified on the first execution result of the third intelligent agent, and the second execution result obtained after the operation permission purification is sent to the parent intelligent agent of the third intelligent agent, including: Based on the predefined execution permission information objects and system-level tags in the third intelligent agent, the execution permission information objects contained in the first execution result are identified to obtain the first permission execution information; Based on the tag propagation chain and the preset encoded value, the first execution result is used for permission tracing and identification to obtain the second permission execution information; Based on the tag propagation chain and preset structured fields, the first execution result is used for permission tracing and identification to obtain the third permission execution information; Based on the execution information of the first, second, and third permissions, the operation permissions are purified to obtain the second execution result.

[0055] The tag propagation chain is used to track and trace the source of system-level tags corresponding to permission-related information, determine the target encoded value / target structured field of the source of the permission-related information, and thus determine whether the target encoded value / target structured field matches the preset encoded value / structured field, thereby enabling permission tracing and tracking.

[0056] The execution permission information object is the object to be cleaned.

[0057] The first permission execution information indicates information related to the execution permission information object written in a non-fixed format; the third permission execution information indicates information related to the execution permission information object embedded using structured fields; and the second permission execution information indicates information related to the execution permission information object obtained after encoding conversion. The first, second, and third permission execution information are all identified objects to be purified. In some embodiments, the objects to be purified may include at least one of permission status information, confirmation and branch status information, and restricted processing identification information. The permission status information is used to characterize the permission type, resource scope, permission strength, attenuation coefficient, and threshold comparison result corresponding to a single confirmation at the threshold. The confirmation and branch status information is used to record whether a single confirmation request has been initiated, whether a one-time execution token has been generated, and whether a status identifier corresponding to a permission status snapshot exists. The restricted processing identification information is used to record restricted content, restricted paths, etc. This application embodiment does not limit the form in which these types of information are recorded in the first execution result.

[0058] This application does not restrict the numerical format of the second and third permission execution information. For example, the second permission execution information may be a converted value formed by encoding transformation and / or string concatenation of the object to be purified; the third permission execution information may be a converted value formed by assigning values ​​to the structured fields of the object to be purified after encoding transformation. The encoding transformation includes Base64 encoding, hexadecimal encoding, and URL encoding. This application will not elaborate on these aspects in detail.

[0059] Understandably, the method also includes: performing operation permission purification processing on the first execution result of the third intelligent agent, and sending the second execution result obtained from the operation permission purification processing to the next-level intelligent agent of the third intelligent agent; it also includes: performing permission boundary identification on the data area not covered by the permission propagation chain in the first execution result according to the preset permission keywords and encoding features, and obtaining the fourth permission execution information; Based on the execution information of the first, second, and third permissions, the operation permissions are purified to obtain the second execution result, including: The operation permissions of the first permission execution information, the second permission execution information, the third permission execution information, and the fourth permission execution information are purified to obtain the second execution result.

[0060] By using the keywords and features of the object to be cleaned as rule parameters, the complete information of the parameters containing the supplementary rule conditions defined in the first execution result can be extracted during the permission boundary identification process to obtain the fourth permission execution information.

[0061] By using rule matching, the remaining permission-related information can be identified as much as possible, thereby further improving the security of accessing resources.

[0062] In practical applications, the extraction order of the first permission execution information, the second permission execution information, the third permission execution information, and the fourth permission execution information can be set. Then, the information extracted for each type is purified before the purification process of the next type of information is performed. Alternatively, all information can be obtained and the purification process can be performed at once. This application embodiment will not elaborate on these points.

[0063] For example, see below. Figure 4 The purification process described in this application embodiment is as follows: S1. Adding System-Level Tags During Operation: During operation, the third agent adds tag metadata fields to the corresponding execution permission information objects in the permission status record, confirmation request record, token record, fork permission status snapshot record, or returned payload metadata to identify the execution permission information object as a cleansing object. In some embodiments, the payload metadata includes parameters for three types of objects to be cleaned: the first is permission status information, including permission items, resource scope, permission strength value, attenuation coefficient, and threshold comparison result; the second is confirmation and branch status information, including one-time execution tickets (i.e., the aforementioned one-time execution token related information), the internal identifier of the permission status snapshot at the fork time, and a single confirmation request; the third is restricted structure residue information, including restricted content identifiers representing the source of restricted results or restricted processing processes, subthreshold acquisition markers, and restricted path traces. The system-level tags for the objects to be cleaned can be written directly or after encoding transformation or embedding into structured fields and then written into the payload metadata. In some embodiments, the permission management service can write the objects to be cleaned into the corresponding data according to a specific format and assign corresponding system-level tags. In some embodiments, the permission management service calls one of the preset payload construction interface, encoding processing interface, and structured field writing interface to convert the object to be cleaned into the corresponding format, write it into the corresponding data, and assign the corresponding system-level label. S2. In the detection phase, the execution results returned by the third agent are used to identify objects to be cleaned: Based on system-level tags and predefined execution permission information objects, the execution permission-related information directly contained in the returned payload is identified to obtain the first permission execution information. Secondly, the objects to be cleaned are traced along the tag propagation chain, following the transformation values ​​formed by encoding transformation, string concatenation, or structured field assignment in the execution results; where encoding transformation includes Base64 encoding, hexadecimal encoding, and URL encoding. Finally, for data areas not covered by the tag propagation chain, supplementary rule matching is performed according to permission keywords and encoding features. At this point, the embodiments of this application can identify objects to be cleaned in three forms: direct inclusion, encoding transformation, and structured field embedding, thus enabling the identification of objects to be cleaned from multiple dimensions. S3. For the identified objects to be purified, purification is performed by deleting, replacing, truncating, or using at least one of the following methods: restricted processing identifier. Specifically, based on the embodiments of this application, the objects to be purified can be identified as at least one of permission status information, confirmation request and branch status information, and restricted processing identifier information. In some embodiments, the payloads returned by each operation under the task assigned by the intelligent agent include business payload data and payload metadata. The business payload data records parameters related to the task execution process and results, while the payload metadata records permission-related parameters. Through the above steps, payload metadata can be identified, thereby reducing the probability of a third-party intelligent agent writing back permissions contained in permission states, threshold single-confirmation results, or one-time execution tokens, leading to permission escalation and thus improving the security of resource access.

[0064] Understandably, the operation permission purification process includes at least one of the following: deletion, replacement, truncation, and setting a restricted processing flag.

[0065] In some embodiments, different purification operations can be selected for different types of purification objects. For example, some objects to be purified may be purified by deletion, some by replacement, some by truncation, and some by setting a restricted processing flag. In this embodiment, these operations will not be described in detail, and those skilled in the art can selectively set them according to the actual situation.

[0066] For example, taking the main objective of code review for project A as an example, assume that the first agent has "write permissions to the output directory of project A", which overrides the build artifact directory build / output / and the report directory / That is, the resource scope is the directory "build / output / " "and the directory "reports / "", corresponding to an intensity value of 1.0. The specific process is as follows: Step 1: The first intelligent agent receives the task processing request "Project A undergoes code review"; Step 2: The first agent derives downwards to build agents, and the built agents derive downwards to obtain code review agents. The code review agents are used to review the directory "build / output / ". "and the directory "reports / The code under "build / output / " undergoes pre-review, and an agent is built to target the "build / output / " directory. "and the directory "reports / The reviewed code is then compiled and built. Assuming the derivation decay coefficient between the building agent and the first agent is 0.8, and the derivation decay coefficient between the code review agent and the building agent is 0.6, then the tasks assigned to the building agent will target the directory "build / output / ". "and the directory "reports / The write permission for the directory "build / output / " is 0.8. Correspondingly, the code review agent has write permissions for the directory "build / output / ". "and the directory "reports / The write permission for "" is 0.48; In some embodiments, when the building agent determines that it needs to try two building strategies simultaneously based on the assigned task, a building branch agent (i.e., the forked agent in the other embodiments above) can be branched out before the derived code review agent. This building branch agent holds a snapshot of the building agent's permission state at the time of the fork. In this case, the building agent and the code review agents derived from each building branch agent are independent of each other. Furthermore, due to the use of permission state snapshots, the building agent and the building branch agent do not share permission states, making the task processing flow traceable. In practical applications, the number of building branch agents can be adjusted according to the number of building strategies. The two building strategies in this embodiment are merely examples. Step 3: During the code review process, the code review agent needs to initiate multiple file write operations. These operations write the review results to reports / audit.log, reports / summary.md, and reports / issues.json, respectively, multiple times. Since the code review agent's write permission is 0.48, which is less than the preset threshold of 0.5, each file write operation requires an independent single confirmation request. For example, if the code review agent does not have an interactive interface but the first agent does, an operation confirmation request is sent along the call chain to the first agent for single confirmation. After the first agent confirms the single confirmation request, a one-time execution ticket is obtained. The operation confirmation request sent along the call chain can be bound to the operation object (i.e., the agent performing the operation) and the parameter digest. After this write request is completed, if another write is needed, the above steps of threshold judgment -> single confirmation -> execution of the write operation are repeated. If the operation confirmation request is rejected, a one-time execution ticket will not be generated, and resource operations cannot be performed. Therefore, the task processing method of this application embodiment can enable the code review agent to always perform permission control of each operation in the task with an intensity value of 0.48 when writing again or continuing to derive a successor agent, thereby improving the security of accessing resources. Step 4: The code review agent completes the confirmation write and returns the first execution result. For example, the first execution result might contain the natural language description, "The review of the build / output directory has been completed. The write to audit.log has undergone the confirmation process (current write permission strength is 0.48, below the threshold of 0.5), summary.md has also been confirmed for write, and the write to issues.json has been rejected." The JSON structure issues.json also embeds "ticket_ref": "dGlja2V0LTIwMjYwNTEy" (Base64 encoding of the one-time execution ticket identifier). Therefore, "current write permission strength is 0.48, below the threshold of 0.5," "issues.json," and "the write to audit.log has undergone the confirmation process, summary.md has also been confirmed for write, and the write to issues.json has been rejected" all contain permission-related data. The "write permission strength" and "confirmation process" are consistent with the keywords defined in the rule supplementary conditions. Furthermore, by scanning and identifying the returned execution result through the permission management service, the objects to be cleaned can be identified. If we trace the Base64 encoded fields through the tag propagation chain and identify that "0.48" and "0.5" originate from a one-time execution token, we can obtain the second permission execution information. For example, we can identify "dGlja2V0LTIwMjYwNTEy" (which is the third permission execution information that matches the structured field) by identifying the structured field "ticket_ref". If we supplement the rules with keywords, we can identify "the writing of audit.log has gone through the confirmation process, summary.md has also been confirmed to be written, and the writing of issues.json has been rejected" as the fourth permission execution information. Taking the cleanup operation as an example, we can replace the above-identified content with "see the attachment for review results". At this time, we can obtain the second execution result as "the review of the build / output directory has been completed, and the review results are in the attachment".

[0067] The method described in this application embodiment can enable task-based autonomous derivation and autonomous forking of intelligent agents with logical reasoning capabilities (such as intelligent agents based on large language models) in multi-strategy execution scenarios. It can also be adapted to high-frequency operation application scenarios. Furthermore, it can identify and purify permission boundary information embedded in the content returned by the intelligent agent, forming a closed-loop constraint on the entire execution process of the target main task, thereby ensuring the security of access to resources during the execution of the target main task.

[0068] Understandably, the derived attenuation factor is determined by at least one of the following methods: Risk level of derived tasks; The role information of the parent agent and its child agents at the next level; The hierarchical depth of sub-agents.

[0069] Role information indicates whether the agent is a top-level master agent, a subordinate agent, or a forked parallel execution agent. For example, parent agents with the same role derive child agents with different roles, resulting in different derivation decay coefficients; conversely, parent agents with different roles derive child agents with the same role, resulting in the same derivation decay coefficient.

[0070] The risk level of a derived task can be determined based on a pre-configured task list.

[0071] The hierarchy depth characterizes the level of the sub-agent's derivation from the first agent.

[0072] In some embodiments, when at least two of the following information are available simultaneously: risk level, role information, and hierarchy depth, a weighted calculation method can be used to determine the attenuation intensity of the derived attenuation coefficient, thereby obtaining the derived attenuation coefficient based on the attenuation intensity.

[0073] Understandably, the operation permission purification process includes at least one of the following: deletion, replacement, truncation, and setting a restricted processing flag.

[0074] In some embodiments, this application also provides an intelligent agent terminal device, which includes: The agent generation module is used to receive the current permission set of the parent agent and the permission requirements corresponding to the derived task description during derivation, calculate and output the child permission status, and determine whether to derive a child agent based on the child permission status. The execution path selection module is responsible for selecting one of the following as the execution path when the sub-agent executes the corresponding atomic task: direct execution, rejection, or sub-threshold confirmation, based on the existence of permission items and the comparison results between the strength value and the threshold value. The single confirmation module is responsible for sending the sub-threshold confirmation request to the confirmation node when selecting the sub-threshold confirmation execution path, and generating a one-time execution ticket after the confirmation node confirms the success, so that the sub-agent can execute according to the one-time execution ticket; The fork snapshot isolation module is responsible for generating a permission state snapshot when a fork occurs and providing an independent copy of the permission state to subsequent branches. The return purification module is responsible for receiving the execution results returned by the sub-agents, processing the first execution result, and then outputting it to the next-level agent.

[0075] The intelligent agent terminal device in this embodiment forms a closed-loop control system around five execution stages—derivation, execution, confirmation, forking, and return—using the aforementioned five modules. These modules are connected sequentially according to the event triggering order within the task to achieve task management. Specifically, the derivation decay coefficient takes effect when the sub-agent is created, the sub-threshold confirmation takes effect when the corresponding operation is triggered, the forking snapshot is generated when a fork occurs, and the return purification is performed when the sub-agent returns a result. In this way, the processing result of any module will not retroactively modify the permission state already determined by the preceding module, thereby enabling secure control over the execution process of each target main task and improving the security of accessed resources.

[0076] In some embodiments, the intelligent agent terminal device further includes a link audit module and a link recording module. The link audit module is responsible for aggregating derivation, confirmation, fork, and cleanup events to verify permission boundary information. The link recording module is responsible for synchronously recording derivation events, decay calculations, confirmation requests and results, fork snapshot generation, and return cleanup events to form a verifiable permission boundary audit record.

[0077] Therefore, this application embodiment achieves security for resource access during the execution of the target main task by configuring continuous constraints on the permission boundaries of the entire closed loop for the complete execution chain of each target main task.

[0078] It is understood that embodiments of this application also provide an electronic device, including: At least one processor; At least one memory is provided for storing the program corresponding to at least one first intelligent agent; The above task processing method is implemented when at least one program is executed by at least one processor.

[0079] For example, please refer to Figure 5 , Figure 5 The hardware structure of an electronic device according to another embodiment is illustrated, wherein the main control device includes: The processor 701 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application; at least one first intelligent agent is deployed on the processor 701; The memory 702 can be a NAND flash, and the relevant program code is stored in the memory 702 and called by the processor 701 to execute the task processing method of the embodiment of this application. The input / output interface 703 is used to implement information input and output; The communication interface 704 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 705 transmits information between various components of the device (e.g., processor 701, memory 702, input / output interface 703, and communication interface 704); The processor 701, memory 702, input / output interface 703, and communication interface 704 are connected to each other within the device via bus 705.

[0080] This application also provides a computer-readable storage medium that stores a computer program that, when executed by a processor, implements the above-described task processing method.

[0081] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0082] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0083] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0084] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0085] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0086] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0087] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0088] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0089] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0090] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0091] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0092] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A task processing method, characterized in that, Applied to a terminal device, wherein the terminal device is equipped with a first intelligent agent, the method includes: In response to receiving a task processing request for a target main task, the first agent generates at least one level of sub-agents based on the target main task, resulting in a multi-level agent; wherein, the task control authority of each agent is determined in real time according to the assigned task, and there is a second agent in the multi-level agent whose assigned task is a distributable task; there is a third agent in the multi-level agent whose assigned task is an atomic task. The third intelligent agent is controlled to execute the corresponding atomic task according to its respective task control authority, and a first execution result is obtained; The permission management service performs operation permission purification on the first execution result of the third intelligent agent, and sends the second execution result obtained from the operation permission purification process to the parent intelligent agent of the third intelligent agent. The second intelligent agent performs task acceptance processing on the second execution result of the third intelligent agent at the next level according to the corresponding distributable task; The first intelligent agent determines the execution result of the target main task based on the result of the task acceptance process.

2. The task processing method according to claim 1, characterized in that, The first intelligent agent generates at least one level of sub-intelligent agents based on the target main task, including: The first intelligent agent takes itself as a candidate parent intelligent agent and the target main task as a task to be split and executes a sub-intelligent agent derivation process to generate the sub-intelligent agent; For each of the sub-agents generated by the sub-agent derivation process, when the candidate derivation task assigned to the sub-agent is a distributable task, the sub-agent takes itself as a candidate parent agent, takes the candidate derivation task as a task to be split, and executes the sub-agent derivation process. The sub-agent derivation process includes the following steps: The candidate parent agent performs task splitting on the task to be split, and obtains at least one candidate derived task. If the inherited permission of the candidate derived task is determined to be a non-empty permission through the permission management service, the task control permission corresponding to the candidate derived task is obtained by the permission management service. The inherited permission represents the intersection of the parent agent's task control permission and the corresponding task requirement permission of the candidate derived task. The task control permission of the candidate derived task includes the permission obtained by attenuating the corresponding inherited permission based on the derivation attenuation coefficient. Based on the task control permissions of the candidate derived task, the sub-agent corresponding to the candidate derived task is derived.

3. The task processing method according to claim 1, characterized in that, The atomic task includes at least one resource operation. The control of the third intelligent agent executes the corresponding atomic task according to its respective task control authority to obtain a first execution result, including: For each resource operation, if the third agent determines that the configured task control permissions do not include the permission item corresponding to the resource operation, it refuses to execute the resource operation. For each of the resource operations, when the third agent determines that the configured task control permissions include the permission item corresponding to the resource operation and the strength of the permission item is greater than or equal to a preset strength threshold, the resource operation is executed directly. For each of the resource operations, when the third agent determines that the configured task control permissions include the permission items corresponding to the resource operation and the strength of the permission items is less than the strength threshold, a single sub-threshold operation confirmation process is executed.

4. The task processing method according to claim 3, characterized in that, The single-operation subthreshold confirmation process includes: The third intelligent agent generates a single confirmation request that corresponds one-to-one with the resource operation, and obtains a one-time execution token generated by the single confirmation request. The one-time execution token is generated when the single confirmation request is confirmed within a preset time. The third agent executes the corresponding resource operation based on the one-time execution token, and invalidates the one-time execution token and enables the no-write-back constraint after the resource operation is completed or the validity period of the one-time execution token expires.

5. The task processing method according to claim 2, characterized in that, The method further includes: If the candidate parent agent determines that the assigned task has multiple execution strategies, the candidate parent agent is subjected to agent fork construction to obtain a forked agent; Obtain a snapshot of the permission state of the candidate parent agent at the time of agent fork construction, and assign the snapshot of the permission state to the forked agent, wherein the forked agent is used to generate a child agent corresponding to the forked agent based on the snapshot of the permission state.

6. The task processing method according to any one of claims 1 to 5, characterized in that, The step of performing operation permission purification processing on the first execution result of the third intelligent agent and sending the second execution result obtained from the operation permission purification processing to the parent intelligent agent of the third intelligent agent includes: Based on the predefined execution permission information object and system-level tag in the third intelligent agent, the execution permission information object contained in the first execution result is identified to obtain the first permission execution information; Based on the tag propagation chain and the preset encoded value, the first execution result is used for permission tracing and identification to obtain the second permission execution information; Based on the tag propagation chain and the preset structured fields, the first execution result is used for permission tracing and identification to obtain the third permission execution information; Based on the first permission execution information, the second permission execution information, and the third permission execution information, operation permission purification processing is performed to obtain the second execution result.

7. The task processing method according to claim 6, characterized in that, The step of performing operation permission purification processing on the first execution result of the third intelligent agent and sending the second execution result obtained from the operation permission purification processing to the next-level intelligent agent of the third intelligent agent further includes: performing permission boundary identification on the data area not covered by the tag propagation chain in the first execution result according to preset permission keywords and encoding features to obtain fourth permission execution information; The step of performing operation permission purification processing based on the first permission execution information, the second permission execution information, and the third permission execution information to obtain the second execution result includes: The first permission execution information, the second permission execution information, the third permission execution information, and the fourth permission execution information are subjected to operation permission purification processing to obtain the second execution result.

8. The task processing method according to claim 2, characterized in that, The derived attenuation coefficient is determined by at least one of the following methods: The risk level of the derived task; The role information of the candidate parent agent and the child agent at the next level; The hierarchical depth of the sub-agents.

9. The task processing method according to claim 7, characterized in that, The operation permission purification process includes at least one of the following: deletion, replacement, truncation, and setting a restricted processing flag.

10. An electronic device, characterized in that, include: At least one processor; at least one first agent is deployed on the processor, each of the first agents executing the task processing method as described in any one of claims 1 to 9.

11. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used by a processor to execute the task processing method as described in any one of claims 1 to 9.

Images