Task execution method, system, agent, electronic device, and program product

Abstract

The present disclosure provides a task execution method, system, agent, electronic device and program product. The execution method comprises: obtaining a target task and context information when the target task is executed; generating a target task graph of the target task according to a task semantic of the target task, determining a permission requirement set of a task node according to a node semantic of the task node, the context information and a dependency relationship; and executing the target task according to the permission requirement set and the target task graph. The target task obtained is parsed into a target task graph with a dependency relationship, and the permission requirement set of each task node in the target task graph is calculated based on the node semantic of the task node and the context, so as to realize accurate binding of the permission requirement set and the specific task node. This enables the allocation of permissions for different links as needed and dynamically when the target task is executed, thereby effectively avoiding the phenomenon of excessive grant of permissions in advance and abuse of permissions in the process of task execution.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence, and more particularly to a method, system, intelligent agent, electronic device, and program product for performing a task. Background Technology

[0002] With the development of large language models and intelligent agent technology, intelligent agents are no longer limited to generating text. Instead, they can autonomously formulate plans, call tools, access data, operate software, and control terminal devices according to user intentions. They can also complete complex tasks through collaboration among multiple intelligent agents.

[0003] For example, if a user inputs "Organize this week's customer meetings, generate a visit plan, and notify the sales team," the main intelligent agent might sequentially invoke calendar reading capabilities, customer relationship management system query capabilities, map route planning capabilities, document generation capabilities, and email sending capabilities. As another example, if a user inputs "I will turn off all lights and activate security mode after leaving home," the intelligent agent might invoke location awareness capabilities, lighting control capabilities, door lock status query capabilities, and camera security capabilities.

[0004] However, in existing technologies, agents are typically granted all permissions at once during user login, application installation, or agent deployment. This results in agents possessing far more permissions than are actually needed to complete the current task. Consequently, permissions cannot be dynamically adjusted according to actual task requirements during execution, potentially leading to the risk of permission abuse. Therefore, task execution methods still need improvement. Summary of the Invention

[0005] The technical problem this disclosure aims to solve is to overcome the shortcomings of existing technologies where the permissions possessed by intelligent agents far exceed the permissions actually needed to complete the current task. This makes it impossible to dynamically adjust permissions according to actual task requirements during task execution, potentially leading to permission abuse. The disclosure provides a task execution method, system, intelligent agent, electronic device, and program product.

[0006] This disclosure solves the above-mentioned technical problems through the following technical solution:

[0007] Firstly, this disclosure provides a method for executing a task, the method comprising:

[0008] Obtain the target task and the context information for executing the target task;

[0009] Based on the task semantics of the target task, a target task graph is generated, wherein the target task graph includes at least one task node and the dependencies between the task nodes;

[0010] Based on the node semantics of the task node, the context information, and the dependencies, determine the set of permission requirements for executing the task node;

[0011] Execute the target task based on the set of permission requirements and the target task graph.

[0012] Optionally, the step of determining the permission requirement set for executing the task node based on the node semantics of the task node, the context information, and the dependencies includes:

[0013] In response to the need to call external resources when executing the task node, obtain the resource information of the external resources;

[0014] Based on the node semantics of the task node, the context information, the dependencies, and the resource information, determine the set of permission requirements for executing the task node;

[0015] And / or, based on the node semantics of the task node, determine the risk level of executing the corresponding task node;

[0016] The set of permission requirements for executing the task node is determined based on the node semantics of the task node, the context information, the dependencies, and the risk level.

[0017] Optionally, the step of executing the target task based on the permission requirement set and the target task graph includes:

[0018] The permission requirement set of the task node is encapsulated to obtain the permission envelope of the task node;

[0019] The permission envelope is signed to generate the permission token for the task node;

[0020] In response to the execution of the task node, the permission token of the task node and the task node's request to call the external resource are obtained;

[0021] The permission token and the call request are verified according to preset verification rules, and the verification results are obtained.

[0022] If the verification result is successful, the target task is executed according to the permission requirement set and the target task graph.

[0023] Optionally, the task node includes a first task node and a second task node, wherein the execution of the second task node depends on the execution of the first task;

[0024] The step of signing the permission envelope to generate the permission token for the task node includes:

[0025] Obtain the first permission forwarding count from the permission token of the first task node;

[0026] Based on the number of times the first permission is forwarded, determine the number of times the second permission is forwarded for the second task node;

[0027] Based on the second permission forwarding count, the permission envelope of the second task node is signed to generate the permission token of the second task node.

[0028] Optionally, the step of executing the target task based on the permission requirement set and the target task graph includes:

[0029] In response to detecting an update to the target task, a new target task graph is regenerated based on the updated target task, and the permission requirement set of the task nodes in the new target task graph is redefined.

[0030] Based on the redefined set of permission requirements and the new target task graph, execute the updated target task.

[0031] Optionally, the execution method further includes:

[0032] In response to the completion of the target task, the permission request set is terminated;

[0033] And / or, in response to detecting that the target task is not executed according to the permission requirement set and the target task graph, the process is carried out according to a preset processing method.

[0034] Secondly, this disclosure provides a task execution system, the execution system comprising:

[0035] The acquisition module is used to acquire the target task and the context information when executing the target task;

[0036] A generation module is configured to generate a target task graph for the target task based on the task semantics of the target task, wherein the target task graph includes at least one task node and the dependencies between the task nodes;

[0037] The determination module is used to determine the set of permission requirements for executing the task node based on the node semantics of the task node, the context information, and the dependency relationship;

[0038] The execution module is used to execute the target task according to the permission requirement set and the target task graph.

[0039] Optionally, the determining module includes:

[0040] The first response unit, in response to the need to call external resources when executing the task node, obtains the resource information of the external resources;

[0041] The determining module is further configured to determine the permission requirement set for executing the task node based on the node semantics of the task node, the context information, the dependency relationship, and the resource information;

[0042] And / or, the determining module is further configured to determine the risk level of executing the corresponding task node based on the node semantics of the task node;

[0043] The determining module is further configured to determine the set of permission requirements for executing the task node based on the node semantics of the task node, the context information, the dependency relationship, and the risk level.

[0044] Optionally, the execution module includes:

[0045] An encapsulation unit is used to encapsulate the permission requirement set of the task node to obtain the permission envelope of the task node.

[0046] A generation unit is used to sign the permission envelope to generate the permission token for the task node;

[0047] The second response unit, in response to executing the task node, obtains the permission token of the task node and the task node's request to call the external resource;

[0048] The verification unit is used to verify the permission token and the call request according to the preset verification rules, and obtain the verification result;

[0049] The second response unit also responds that the verification result is successful, and executes the target task according to the permission requirement set and the target task graph.

[0050] Optionally, the task node includes a first task node and a second task node, wherein the execution of the second task node depends on the execution of the first task;

[0051] The generation unit includes:

[0052] The acquisition subunit is used to acquire the first permission forwarding count in the permission token of the first task node;

[0053] A subunit is defined to determine the second permission forwarding count of the second task node based on the first permission forwarding count;

[0054] The generation unit is further configured to sign the permission envelope of the second task node according to the number of second permission forwardings, so as to generate the permission token of the second task node.

[0055] Optionally, the second response unit further responds to detecting the target task update by regenerating a new target task graph based on the updated target task, and redetermining the permission requirement set of the task nodes in the new target task graph;

[0056] The execution module also executes the updated target task based on the redefined set of permission requirements and the new target task graph.

[0057] Optionally, the execution system further includes:

[0058] The response module terminates the permission request set in response to the completion of the target task.

[0059] And / or, the response module may further respond to the detection that the target task has not been executed according to the permission requirement set and the target task graph, by processing according to a preset processing method.

[0060] Thirdly, this disclosure provides an intelligent agent, which includes the task execution system described above.

[0061] Fourthly, this disclosure provides an electronic device, including a memory, a processor, and a computer program stored in the memory and used to run on the processor, wherein the processor executes the computer program to perform the above-described task execution method.

[0062] Fifthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the execution method of the task described above.

[0063] Sixthly, this disclosure provides a computer program product, including a computer program, which, when executed by a processor, performs an execution method for the tasks described above.

[0064] Based on common knowledge in the field, the above-mentioned preferred conditions can be combined arbitrarily to obtain various preferred embodiments of this disclosure.

[0065] The positive advancements of this disclosure lie in the following: by parsing the obtained target task into a target task graph with dependencies, and independently calculating the permission requirement set of each task node based on the node semantics and context of the target task graph, precise binding between the permission requirement set and specific task nodes is achieved. This enables the allocation of necessary permissions to different stages as needed during the execution of the target task, thereby effectively avoiding the premature and excessive granting of permissions and the abuse of permissions during task execution. Attached Figure Description

[0066] Figure 1 A flowchart illustrating a task execution method provided in Embodiment 1 of this disclosure;

[0067] Figure 2 This is a schematic diagram of the target task graph in a task execution method provided in Embodiment 1 of this disclosure;

[0068] Figure 3 A timing diagram for verifying a task execution method provided in Embodiment 1 of this disclosure;

[0069] Figure 4 This is a permission derivation graph in a task execution method provided in Embodiment 1 of this disclosure;

[0070] Figure 5 A schematic diagram of a task execution system provided in Embodiment 2 of this disclosure;

[0071] Figure 6 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of this disclosure. Detailed Implementation

[0072] The present disclosure is further illustrated below by way of embodiments, but the present disclosure is not limited to the scope of the embodiments described herein.

[0073] The prefixes such as "first" and "second" used in this disclosure are merely for distinguishing different descriptive objects and do not limit the position, order, priority, quantity, or content of the described objects. The use of ordinal numbers and other prefixes used to distinguish descriptive objects in this disclosure does not constitute a limitation on the described objects. The description of the described objects is given in the context of the embodiments, and the use of such prefixes should not constitute unnecessary restrictions. Furthermore, in the description of this embodiment, unless otherwise stated, "multiple" means two or more.

[0074] It should be noted that the steps in this embodiment are described in a specific order; however, this is only to increase the readability of the embodiment and not to limit the order of the steps. Furthermore, the order of the steps can be adjusted according to the actual situation.

[0075] Example 1

[0076] To prevent abuse of permissions by intelligent agents during task execution, this invention provides a task execution method. This method is implemented in an intelligent agent system, which includes a master intelligent agent and at least one executing intelligent agent. The master intelligent agent identifies user tasks, generates task graphs, allocates task nodes, and coordinates the execution process. The executing intelligent agent receives task nodes and invokes tools, services, models, or terminal devices to complete the corresponding task nodes. Figure 1 A flowchart of a task execution method provided in Embodiment 1 of this disclosure, the execution method including the following steps:

[0077] Step 101: Obtain the target task and the context information when executing the target task.

[0078] The target task refers to the task to be completed that the user expresses through natural language, interface operation, event triggering, or preset rules.

[0079] This contextual information can be obtained through sensors, system status, user devices, or third-party services. This contextual information may include at least one of the following: current user and their tenant information; current device, location, and network environment; current time, user preferences, and historical behavior; current session state, available agents, tools, services, and terminal devices; data sensitivity level; basic permissions already granted by the user; legal, organizational, or family management policies; and at least one of the following: the status and spatial relationships of surrounding terminal devices. The basic permissions represent the maximum scope of permissions that the user or organization allows the agent system to use. Subsequently generated permission request sets cannot exceed these basic permissions.

[0080] Step 102: Generate the target task graph based on the task semantics of the target task.

[0081] The target task graph includes at least one task node and the dependencies between task nodes.

[0082] This target task graph is a structured task representation generated based on the target, where nodes represent subtasks and edges represent execution order, data dependencies, conditional dependencies, or rollback dependencies. The task semantics is a structured description of the target task, operation objects, actions, constraints, expected results, and risk characteristics. This target task graph can be a directed acyclic graph, tree, state machine, workflow, event graph, or other data structure capable of expressing task dependencies.

[0083] Specifically, the master agent generates a task graph based on the target task. Each task node may include at least one of the following: node identifier; node target; input data; expected output; preceding task nodes; subsequent task nodes; candidate execution agents; candidate tools or devices; completion conditions; failure handling methods; and whether side effects are allowed.

[0084] For example, for the objective task of "reading the emails sent by Zhang San today, generating a summary, and forwarding it to the project manager," a summary could be generated as follows: Figure 2 The target task diagram is shown.

[0085] The controlling agent can divide the target task into six task nodes, N1 to N6, based on the task semantics of the target task, and connect these six task nodes sequentially according to their dependencies.

[0086] Step 103: Determine the permission requirement set for executing the task node based on the node semantics, context information, and dependencies of the task node.

[0087] The semantics of this node can be represented as: <Subject, Action, Object, Data Scope, Parameter Constraints, Environmental Conditions, Expected Result, Side Effects, Time Scope>. This permission requirement set represents the set of operational permissions, data permissions, and environmental constraints actually required to execute a specific task node.

[0088] Suppose the task node is "send the meeting minutes to the participants of this meeting".

[0089] The semantics of this task node can be as follows: Subject: The agent responsible for sending the email; Action: Send email; Object: Participants in this meeting; Data range: Meeting minutes; Parameter constraints: Recipients must belong to the set of meeting participants, attachments are limited to meeting minutes; Environmental conditions: The meeting has ended and the minutes have been generated; Expected result: Participants receive the meeting minutes; Side effect: External communication is generated; Time range: Within two hours after task creation.

[0090] The semantic extraction of this node can be accomplished by a pre-trained large language model, or by a rule engine, classification model, knowledge graph, action ontology matching, or a combination of the above methods.

[0091] Furthermore, each node corresponds to its own set of permission tasks. For example, the agent executing task node N3 only needs permission to read emails and does not need permission to send emails; the agent executing task node N4 does not need permission to access the entire mailbox; and the agent executing task node N6 only needs permission to access the summary results and the project leader's address.

[0092] In addition, users can pre-set operations that are permanently prohibited from being performed by the agent, as the absolute upper limit of the task permission set.

[0093] Step 104: Execute the target task based on the permission requirement set and the target task graph.

[0094] In this embodiment, by parsing the obtained target task into a target task graph with dependencies, and independently calculating the permission requirement set of each task node based on the node semantics and context of each task node in the target task graph, precise binding between the permission requirement set and the specific task node is achieved. This enables the necessary permissions to be dynamically allocated to different stages as needed when executing the target task, thereby effectively avoiding the premature and excessive granting of permissions and the abuse of permissions during task execution.

[0095] In one embodiment, the step of determining the permission requirement set for executing a task node based on the node semantics, context information, and dependencies of the task node includes:

[0096] In response to the need to access external resources when executing a task node, the system retrieves the resource information of those external resources. Based on the task node's node semantics, context information, dependencies, and resource information, the system determines the set of permission requirements for executing the task node.

[0097] Assuming the external resource is an external tool, its information should include at least one of the following: the actions the tool can perform; the types of resources it can operate on; parameter definitions; parameter security scope; required basic permissions; side effect level; whether revocation is supported; and whether it can be sub-delegated by an agent.

[0098] In this embodiment, determining the permission requirement set of the task execution node based on resource information from external resources ensures that the calculated permission requirement set accurately matches the actual allowed execution boundaries of the external resource. This not only avoids invalid authorizations due to unavailable or mismatched external resources, but also enhances the security and compatibility of resource calls while ensuring task execution efficiency. Furthermore, determining the permission requirement set of the task execution node by combining resource information from external resources also avoids the permission requirement set relying entirely on the non-deterministic output of the large language model.

[0099] In one embodiment, the step of determining the permission requirement set for executing a task node based on the node semantics, context information, and dependencies of the task node includes:

[0100] Based on the node semantics of the task node, determine the risk level of executing the corresponding task node. Based on the node semantics, context information, dependencies, and risk level of the task node, determine the permission requirement set for executing the task node.

[0101] The risk factors affecting this task node include whether it reads personal information, trade secrets, or authentication credentials; whether it modifies or deletes data; whether it sends information to external entities; whether it generates payment, transfer, order placement, or contract signing behavior; whether it controls physical objects such as door locks, vehicles, robots, and industrial equipment; whether the operation is reversible; the number of users and resource scope affected by the operation; whether the parameters may exceed the normal usage range; whether it involves cross-tenant, cross-network, or cross-security domain; whether it involves unverified third-party intelligent agents or tools; and the semantic distance between this operation and the original task semantics.

[0102] The risk level of executing a corresponding task node can be determined based on the node semantics of the task node and the aforementioned risk influencing factors. Specifically, the more risk influencing factors involved in the node semantics of the task node, the higher the risk level.

[0103] Specifically, risk levels can be divided into low risk, medium risk, high risk, and prohibited from automatic execution, or they can be represented by continuous risk scores.

[0104] This risk level can be used to determine at least one of the following: whether automatic token issuance is allowed; whether secondary user confirmation is required; whether independent verification by an intelligent agent is required; token validity period and number of calls; whether sub-authorization is allowed; whether device status proof is required; and whether simulation is required before execution. Furthermore, high-risk tasks can be executed only after multiple verification agents have jointly signed off on them.

[0105] In this embodiment, the permission requirement set for executing task nodes is determined based on the risk level of each task node. This ensures that before assigning permissions, the system can dynamically assess the inherent risks of each task node based on its specific operation type (such as whether it involves sensitive data, physical control, or financial transactions). Based on the assessment results, the system can differentiate the strictness, validity period, sub-authorization restrictions, and whether manual review is required for each permission. This ensures the security of sensitive tasks while avoiding excessive control that could negatively impact the user experience.

[0106] In one embodiment, the permission requirement set for executing a task node can be determined by combining resource information from external resources and the risk level of the task node. This permission requirement set may include: resource scope: allowed access to files, records, email addresses, devices, database tables, or APIs; operation scope: read, create, modify, delete, send, control, or query; data scope: allowed access to fields, time intervals, record sets, or semantic sets; parameter scope: allowed parameter values, numerical ranges, or enumeration sets; context information: location, time, device status, preceding task status, or user online status; call limits: maximum number of calls, maximum number of returned records, or maximum data volume; validity period: start time, expiration time, or before the task node completes; sub-authorization restrictions: whether sub-authorization is allowed, the maximum allowed depth, and the scope of downstream agents; result flow restrictions: which task nodes, agents, or external entities the result can be passed to; and side effect restrictions: whether external communication, data modification, or physical actions are allowed.

[0107] Furthermore, the permission requirement set must satisfy the following constraints:

[0108] The permission requirement set satisfies the following constraints:

[0109]

[0110] Where: P_node represents the set of permission requirements for the task node; P_user represents the basic permissions already granted by the user; P_policy represents the permissions allowed by organizational, security, or device policies; and P_tool represents the scope of permissions that external resources can accept.

[0111] If the necessity of a certain permission cannot be derived from the semantics of the task, it will not be added to the permission requirement set.

[0112] In one embodiment, the steps for executing the target task based on the permission requirement set and the target task graph include:

[0113] S2-1: Encapsulate the permission requirement set of the task node to obtain the permission envelope of the task node.

[0114] It should be noted that this permission envelope not only indicates "allowed or not allowed to call", but also describes the permission boundaries of this task. The permission envelope can be expressed using a whitelist, or a combination of a whitelist and prohibited items.

[0115] The permission requirement set of a task node can be encapsulated using JSON, CBOR, Protocol Buffers, custom binary structures, or other data formats to obtain the permission envelope of the task node. JSON, CBOR, and Protocol Buffers are all data serialization formats.

[0116] S2-2: Sign the permission envelope to generate the permission token for the task node.

[0117] The signature method can be centralized signing, distributed signing, or local signing on the device.

[0118] The permission token may include at least one of the following: a unique token identifier, the identifier of the root task to which it belongs, the identifier of the task node to which it belongs, the identifier of the authorized agent, the tool gateway, service or device that is allowed to receive the token, the scope of resources that are allowed to be accessed, the scope of operations that are allowed to be performed, the scope of data that are allowed to be read, used and output, invocation parameter constraints, context information that must be satisfied when invoking, effective and expiration time, maximum number of uses, maximum sub-authorization depth, upstream token digest, task semantic digest, permission policy version, risk level, anti-replay random number, and digital signature of the token issuer.

[0119] The task token can be in JWT format, or at least one of the following formats: Macaroon, capability certificate, verifiable credential, or custom signed token. JWT and Macaroon are standards for task tokens.

[0120] S2-3: In response to the execution of a task node, obtain the task node's permission token and the task node's request to call external resources.

[0121] S2-4: Verify the permission token and call request according to the preset verification rules, and obtain the verification result.

[0122] Permission tokens and invocation requests can be sent to a permission enforcement gateway, which verifies the tokens and requests according to preset verification rules. This permission enforcement gateway can be deployed in API gateways, service meshes, operating system kernels, agent runtimes, device gateways, database proxies, or within terminal devices.

[0123] The permission execution gateway performs the following preset verification rules: verify the task token signature, issuer, and integrity; verify whether the task token has expired, been revoked, or exceeded its usage limit; verify whether the agent in the call request is consistent with the task token subject; verify whether the target tool or device in the call request is consistent with the task token recipient; verify whether the resources and operations in the call request are within the permission envelope; verify whether the request parameters of the call request meet the parameter constraints; verify whether the input data comes from a data source allowed by the task token; verify whether the task node is in an executable state; verify whether the preceding task has been completed; verify context information such as location, time, and device status; verify the consistency between the current call and the task semantics; and verify whether the parent task token and its derivative chain are still valid.

[0124] Furthermore, for terminal devices that can produce physical side effects, such as door locks, vehicles, robots, industrial equipment, and medical equipment, the permission enforcement gateway can be deployed in the device center, device gateway, or inside the terminal device.

[0125] Furthermore, for these types of terminal devices, in addition to the above verifications, the permission execution gateway can also verify: the terminal device's hardware identity and certificate; the device's current location; the device's current status; whether the operation parameters are within the device's safe zone; whether there are personnel nearby; whether the security interlock conditions are met; whether the user is in a permitted operation location; and whether confirmation from other devices is required.

[0126] For example, the target task is "Help me open the door when I come home at night." The system can generate an unlock token with the following conditions: it can only control the target door lock of the user's residence; it can only call the unlocking capability once; it is valid for two minutes after the user arrives at the door; the user's mobile phone or wearable device must be near the door lock; the door lock camera or other sensors confirm that the person outside the door matches the user's identity; and it is prohibited to sub-authorize the unlocking permission to other smart agents.

[0127] When the access control gateway verifies the call request, if any condition is not met, the door lock will refuse to perform the unlocking operation.

[0128] In addition, for older tools that do not support task tokens, they can be connected to the permission execution gateway via a proxy wrapper.

[0129] S2-5: If the response verification result is successful, execute the target task according to the permission requirement set and the target task graph.

[0130] If the response verification result is "verification failed," meaning the call request exceeds the current permission envelope, the permission execution gateway will not execute directly. It can perform at least one of the following actions based on the reason for exceeding the limit: reject the call request; adjust the parameters to the allowed range; return insufficient permission information; require the executing agent to replan; request supplementary authorization from the master agent; request user confirmation for high-risk permission requests; replace with a tool or execution path that does not require new permissions; or downgrade the high-risk action to at least one of read-only query or simulated execution. Supplementary authorization cannot be generated solely based on the executing agent's declaration. It is also necessary to associate the new permission with the original target task, the current task node, and changes in the task graph to confirm the necessity of the new permission before issuing a new token.

[0131] Figure 3 This is a timing diagram for verifying a task execution method provided in Embodiment 1 of this disclosure, combined with... Figure 3 This will further explain the verification process.

[0132] S201, the master control agent extracts the semantics of the task node, determines the executing agent, and obtains the context information, and sends it to the permission calculation and issuance service module.

[0133] S202, the permission calculation and issuance service module, calculates the minimum permissions and risk level, and issues the task token to the executing intelligent agent.

[0134] S203. The executing agent sends the call request and task token to the permission execution gateway for verification.

[0135] For validations that can be performed using deterministic rules, rule-based validation should be prioritized. For situations requiring the understanding of natural language parameters or comparison of actual operations with task objectives, a semantic consistency model can be invoked.

[0136] S204. The authorization gateway verifies the call request and task token. If the verification is successful, the call request is sent to the tool / service / terminal device. This tool / service / terminal device is the external resource mentioned above.

[0137] For verifications that can be performed using the aforementioned preset verification rules, the preset verification rules should be used first. For situations requiring the understanding of natural language parameters or comparison of actual operations with task objectives, the semantic consistency model can be invoked.

[0138] S205: The tool / service / terminal device is invoked and the execution result is returned to the permission execution gateway. After receiving the result, the permission execution gateway returns the result and the number of times it was used to the execution agent.

[0139] It should be noted that both the minimum permission and the risk level belong to the permission requirement set mentioned above.

[0140] In this embodiment, by encapsulating the permission request set into a signable and verifiable permission task token, the integrity, immutability, and traceability of the permission declaration can be ensured. Furthermore, by setting up a verification step before actually calling external resources, the abuse of permissions by intelligent agents is effectively prevented.

[0141] In one embodiment, the task node includes a first task node and a second task node, and the execution of the second task node depends on the execution of the first task node.

[0142] The first task node is executed by the upstream agent, and the second task node is executed by the downstream agent. When the upstream agent delegates a task to the downstream agent, the downstream agent's permissions must satisfy the following:

[0143]

[0144] Where: P_child represents the permissions contained in the downstream task capability token; P_parent represents the sublicensable permissions currently held by the upstream agent; P_subtask represents the permissions actually required to complete the downstream subtask; and P_child_policy represents the permissions that the downstream agent, tool, or security domain is allowed to accept.

[0145] Downstream agents cannot automatically inherit all permissions from upstream agents simply because they are invoked by upstream agents.

[0146] The steps for signing the permission envelope to generate the permission task token for the task node include:

[0147] S3-1: Obtain the first permission forwarding count from the permission task token of the first task node.

[0148] S3-2: Determine the second permission forwarding count for the second task node based on the first permission forwarding count.

[0149] The number of times this permission can be forwarded is the number of times an agent can sub-authorize permissions. Each time an upstream agent sub-authorizes a permission, the remaining number of sub-authorizations in the downstream agent's task token decreases by one. When the remaining number of sub-authorizations is zero, the downstream agent can no longer sub-authorize permissions.

[0150] For high-risk actions such as transferring funds, unlocking doors, and deleting data, any form of sub-authorization can be prohibited.

[0151] S3-3: Based on the number of second permission forwardings, sign the permission envelope of the second task node to generate the permission task token of the second task node.

[0152] In this embodiment, a transferable number of permission forwarding attempts is introduced into the permission task token, and the forwarding limit of the downstream task token is dynamically calculated based on the remaining attempts of the upstream task token. This ensures that in multi-agent collaboration or multi-level task delegation scenarios, the permissions obtained by downstream nodes not only originate from valid authorization from the upstream, but their ability to derive further downwards is also strictly limited. With each level of transmission, the number of forwarding attempts decreases until it reaches zero, completely blocking further authorization. This design fundamentally avoids the risk of unlimited propagation of permissions in the call chain, thereby enabling precise control over the scope and depth of permission propagation. This effectively curbs the problem of permission abuse caused by excessive permission transfer while ensuring the flexibility of task collaboration.

[0153] In one embodiment, the steps for executing the target task based on the permission requirement set and the target task graph include:

[0154] In response to the detection of a target task update, a new target task graph is generated based on the updated target task, and the permission requirement set for the task nodes in the new target task graph is redefined. The updated target task is then executed based on the redefined permission requirement set and the new target task graph.

[0155] For example, a user's original task instruction was "organize all customer emails from the past month," which was later modified to "organize only Company A's emails from the past week." In this case, the task token allowing access to all customer emails from the past month should be immediately revoked, and a new task token allowing access only to Company A's emails from the past week should be issued.

[0156] Furthermore, the permission requirement set of the affected task node is also recalculated when the following events are detected: the master agent adds, deletes, or rearranges the task node; a task node completes, fails, times out, or rolls back; the executing agent is changed; the state of the tool, service, or terminal device changes; the sensitivity level changes; abnormal calls or semantic drift are detected; or the user leaves a specific location.

[0157] When a task node is detected to have changed its executing agent, the task token bound to the original agent is revoked, the security attributes of the new agent are reassessed, and a new task token is issued. The task token cannot be directly transferred from the old agent to the new agent.

[0158] When an upgrade to external resource information is detected that causes changes in parameter definitions or security scope, the permission envelope is recalculated based on the version of the external resource information. Task tokens from older policy versions may be rejected or trigger compatibility checks.

[0159] Preferably, affected task nodes can be determined based on the target task graph, and incremental permission updates can be performed only on the affected task nodes. When the permission scope of a task node narrows, the original task token should be revoked first, and a new task token with smaller permissions should be issued instead of retaining the original task token until it expires naturally. Specifically, the task token can be updated by re-signing after revocation, token decay, adding constraints, or updating online policies.

[0160] In this embodiment, when the target task changes, a new target task graph is generated and the permission requirement set is redefined. Based on the redefined permission requirement set and the new target task graph, the updated target task is executed. This way, when the target task changes, the original permission requirement set is no longer needed, and manual adjustment of the permission requirement set is unnecessary. The permission scope of the affected nodes can be shrunk or expanded as needed, ensuring that the optimal match between the permission requirement set and the node tasks is maintained throughout the task execution process.

[0161] In one embodiment, the execution method further includes: terminating the permission request set in response to the completion of the target task.

[0162] Methods for terminating permission requirements may include marking the corresponding task token as consumed or expired; prohibiting the agent from continuing to use the task token to access resources; deleting temporary data held by the executing agent according to the data minimization strategy; retaining the task semantic digest, task token digest, and call result digest for auditing; and for highly sensitive tasks, requiring the execution environment to destroy temporary keys, caches, and intermediate files.

[0163] In this embodiment, the permission request set is terminated when the target task is completed. This allows the corresponding permission request set to be actively revoked after the target task is completed, so that the permissions held by the agent become invalid immediately upon the termination of the task, avoiding the risk of permissions remaining valid after the task ends in traditional solutions.

[0164] In one Figure 4 This is a permission derivation graph in a task execution method provided in Embodiment 1 of this disclosure; according to Figure 4 This explains the derivation relationship between the task tokens of each node. Figure 4 The system is divided into three layers from top to bottom, with the next layer containing the sub-task tokens of the previous layer.

[0165] When a parent task token becomes invalid, is revoked, or its scope of permissions is reduced, all child task tokens are checked according to this derivation graph:

[0166] If the subtask token depends entirely on the revoked permission, then revoke the subtask token.

[0167] If only a portion of the subtask token is affected, recalculate and reduce permissions;

[0168] If the subtask token has been completed and cannot be used again, only the revocation event is recorded.

[0169] In one embodiment, the execution method further includes: in response to detecting that the target task is not executed according to the permission requirement set and the target task graph, processing is performed according to a preset processing method.

[0170] When a deviation from the permission requirement set and the target task graph is detected, it indicates that the agent's actual actions may deviate from the original target task during task execution. For example, if the target task is "summarize the contract," the agent may attempt to upload the contract to an external service; if the target task is "query the door lock status," the agent may attempt to unlock the door.

[0171] Whether an agent executes the target task based on the permission requirement set and the target task graph can be detected through the following dimensions. For example: whether the actual action is consistent with the node action type in the permission requirement set; whether the actual operation object belongs to the node target object in the permission requirement set; whether the call parameters match the expected results in the permission requirement set; whether the actual data used exceeds the node input in the permission requirement set; whether the new tool call has task dependencies in the permission requirement set; whether the call result flows to the expected agent or external subject in the permission requirement set; whether the call reason explained by the agent can be verified by the target task graph; and whether the semantic distance between the current call and the original target task exceeds a threshold.

[0172] When it is detected that the target task is not executed according to the permission requirement set and the target task graph, the handling methods may include: blocking the current call of the agent; freezing all task tokens held by the current agent; revoking the downstream task tokens derived from it; migrating the task to a backup agent; independently verifying the agent's review; requesting user confirmation; adding at least one of the following to the relevant input data:

[0173] In this embodiment, a mechanism for proactively detecting abnormal execution and handling it using preset methods ensures that when the actual task execution process deviates from the constraints of the permission requirement set and the target task graph, a rapid response can be initiated according to the preset methods, such as blocking the call, triggering an alarm, automatically rolling back, or requesting manual intervention. This ensures that even during abnormal execution, the system still possesses autonomous fault tolerance and risk mitigation capabilities, preventing erroneous operations or unauthorized behaviors from degrading the user experience.

[0174] In one embodiment, the aforementioned intelligent agent may include:

[0175] Task parsing module: Used to parse the target task and generate a task graph.

[0176] Semantic extraction module: used to extract actions, objects, data, parameters, conditions and expected results from task nodes.

[0177] Risk assessment module: used to determine the data risk, business risk, physical risk, and irreversibility of task nodes.

[0178] Permission calculation module: used to calculate the permission requirement set based on task semantics, risk level and candidate agent capabilities.

[0179] Token issuance module: Used to generate task tokens based on permission requirement sets.

[0180] Permission Execution Gateway: Used to verify task tokens and invocation requests before actual operations occur.

[0181] Task Status Management Module: Used to maintain the status of task nodes, such as waiting, execution, completion, cancellation, failure, and rollback.

[0182] Sub-authorization management module: Used to control the delegation of permissions among multiple agents.

[0183] Dynamic adjustment module: Used to update, shrink, or revoke permissions when the target task graph or context changes.

[0184] Audit module: Used to record the basis for permission generation, token derivation relationship, actual call and verification results.

[0185] In one embodiment, the method for performing the tasks of this disclosure is illustrated with several practical examples.

[0186] For example: email summaries and targeted delivery.

[0187] Objective / Task: "Summarize the project emails sent by Zhang San today and send the summary to the project manager."

[0188] Based on the task semantics of the target task, a corresponding target task graph is generated. This target task graph includes at least five types of task nodes: email query, email reading, summary generation, responsible person query, and email sending.

[0189] Issue task tokens for email query tasks that only allow queries on the current day and whose sender is Zhang San.

[0190] Issue task tokens to email reading task nodes that only allow reading the body of the matching result from the previous step;

[0191] Grant the digest agent that performs the digest generation task permission to read intermediate data, but not mailbox permission;

[0192] Issue task tokens to the task nodes queried by the responsible person, allowing only the reading of the target project responsible person's name and email field;

[0193] Issue a task token to the task node that sends the email only once to the responsible person, and immediately invalidate the task token after the email is sent.

[0194] If the sending agent attempts to add other recipients, add BCC, read other emails, or send a second message, the permission execution gateway denies the request.

[0195] For example: enterprise data analysis.

[0196] Objective: "Analyze the sales trends in East China last quarter, without displaying specific customer names."

[0197] Based on this objective, the generated set of permission requirements includes: access only to the East China region; access only to the previous quarter; only allowing reading of sales amount, date, and product category fields; prohibiting reading of customer name, contact information, and contract attachments; output results must be aggregated; and prohibiting the passing of raw records to the chart generation agent.

[0198] The permission execution gateway can directly perform field pruning and row-level filtering on queries. Even if the execution agent generates an SQL statement to retrieve national data or customer names, the gateway will reject or rewrite the statement.

[0199] For example: smart home control.

[0200] Objective: "After I leave home, I will turn off the living room devices and activate the security mode."

[0201] The context information in the generated task token includes: the user's location has left the home area; the door lock is closed; only living room lights, TV, air conditioner, and security camera are allowed to be controlled; the air conditioner is only allowed to be turned off or put into energy-saving mode; control of bedroom safe, door lock, or other unrelated devices is not allowed; after security mode is activated, the relevant control task token becomes invalid.

[0202] If an agent attempts to unlock a device due to a malicious device description, and the unlocking action is not within the task permission envelope, the gateway will refuse to execute it.

[0203] For example: multi-agent travel planning.

[0204] Objective: "Based on my calendar, schedule a business trip to Beijing next week and generate an itinerary without directly booking tickets."

[0205] The master agent delegates tasks to the calendar agent, flight agent, hotel agent, and route planning agent.

[0206] The calendar agent can only read the busy / slack times for the following week; it cannot read historical calendar details.

[0207] The flight agent only receives the departure city, destination, and available dates; it does not receive the complete calendar.

[0208] The hotel agent only obtains the destination, dates, and budget;

[0209] All agents only have query permissions;

[0210] Permissions to perform actions such as booking tickets, making payments, and sending confirmation emails will not be granted.

[0211] Even if an execution agent decides on its own that "it is more convenient for users to book directly," it cannot complete the order or payment through the permission execution gateway.

[0212] For example: changes made midway through the task.

[0213] The initial objective is to "send the report to all members of the project team." The system has already generated mass sending permissions, but this has not yet been implemented.

[0214] The revised objective is: "Send it only to the project manager for confirmation initially."

[0215] If a narrowed recipient range is detected, immediately revoke the original bulk mailing task token and reissue a task token that can only be sent to the project manager once. The old task token, even if it has not yet expired, cannot be used anymore.

[0216] In this embodiment, the task execution method disclosed herein has at least the following technical effects: (1) The permission task set is directly bound to each node of the target task, avoiding the agent from holding excessive permissions that are not needed to complete the task for a long time. (2) Natural language targets are converted into structured permission boundaries, enabling permission control to adapt to the agent's autonomous planning and dynamic tool calls. (3) Permission accuracy is improved through multi-dimensional constraints such as objects, fields, parameters, times, time and state conditions. (4) Unauthorized behavior is prevented before side effects actually occur through task tokens and permission execution gateways. (5) Permissions are prevented from continuously expanding in the multi-agent call chain through permission intersection and deep control of sub-authorization. (6) All related downstream permissions are quickly blocked when the task is canceled or risks are discovered through permission derivation graph and cascading revocation. (7) Permissions change in real time with user targets, task graphs and environmental states through incremental permission adjustment. (8) The risks caused by prompt word injection, model illusion and incorrect planning are reduced through semantic drift detection. (9) Permission invalidation and temporary data cleanup after task completion reduce permission and sensitive data residue. (10) Form a closed loop by connecting user objectives, task nodes, authorization basis and actual calls to improve system auditability and fault location capabilities.

[0217] In this embodiment, the task execution method avoids directly granting long-term permissions based on the agent's fixed role. Instead, it dynamically calculates the minimum permission requirement set for each task node in the task graph based on the task semantics corresponding to the target task, and generates a task token bound to the task node, the executing agent, and the current context. This prevents the agent from directly using its own long-term identity credentials to call tools, services, or terminal devices with side effects; instead, it must send the task token to the permission execution gateway. The permission execution gateway performs joint verification based on the task token content, task graph state, real-time context, and current call parameters, allowing execution only if the current call falls within the permission envelope.

[0218] Example 2

[0219] Corresponding to the aforementioned embodiments of the task execution method, this disclosure also provides embodiments of the task execution system. Figure 5 A schematic diagram of a task execution system 50 is provided for an exemplary embodiment of this disclosure. The task execution system 50 includes:

[0220] Module 51 is used to acquire the target task and the context information when executing the target task;

[0221] The generation module 52 is used to generate a target task graph of the target task based on the task semantics of the target task, wherein the target task graph includes at least one task node and the dependencies between task nodes;

[0222] The determination module 53 is used to determine the set of permission requirements for executing the task node based on the node semantics, context information and dependencies of the task node.

[0223] Execution module 54 is used to execute the target task based on the permission requirement set and the target task graph.

[0224] In one embodiment, the determining module 53 includes:

[0225] The first response unit responds to the need to call external resources when executing a task node and obtains the resource information of the external resources;

[0226] The determination module 53 is also used to determine the permission requirement set for executing the task node based on the node semantics, context information, dependency relationship and resource information of the task node;

[0227] And / or, the determining module 53 is also used to determine the risk level of executing the corresponding task node based on the node semantics of the task node;

[0228] The determination module 53 is also used to determine the set of permission requirements for executing the task node based on the node semantics, context information, dependencies and risk level of the task node.

[0229] In one embodiment, the execution module 54 includes:

[0230] The encapsulation unit is used to encapsulate the permission requirement set of the task node to obtain the permission envelope of the task node.

[0231] The generation unit is used to sign the permission envelope to generate the permission task token for the task node.

[0232] The second response unit, in response to the execution of the task node, obtains the task node's permission token and the task node's request to call external resources;

[0233] The verification unit is used to verify the permission task token and the call request according to the preset verification rules, and to obtain the verification result.

[0234] The second response unit also responds with a verification result indicating that the verification passed, and executes the target task based on the permission requirement set and the target task graph.

[0235] In one embodiment, the task node includes a first task node and a second task node, and the execution of the second task node depends on the execution of the first task node;

[0236] The generation unit includes:

[0237] The sub-unit is used to obtain the first permission forwarding count in the permission task token of the first task node;

[0238] The sub-unit is determined to determine the second permission forwarding count of the second task node based on the first permission forwarding count;

[0239] The generation unit is also used to sign the permission envelope of the second task node according to the number of second permission forwardings, so as to generate the permission task token of the second task node.

[0240] In one embodiment, the second response unit further responds to detecting a target task update by regenerating a new target task graph based on the updated target task and redetermining the permission requirement set of the task nodes in the new target task graph.

[0241] The execution module 54 also executes the updated target tasks based on the redefined set of permission requirements and the new target task graph.

[0242] In one embodiment, the execution system further includes:

[0243] The response module terminates the permission request set upon completion of the target task.

[0244] And / or, if the response module detects that the target task has not been executed according to the permission requirement set and the target task graph, it shall handle the situation according to the preset processing method.

[0245] For the system embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components 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 modules can be selected to achieve the purpose of this disclosure according to actual needs.

[0246] Example 3

[0247] This disclosure provides an intelligent agent that includes an execution system for the tasks described above.

[0248] In this embodiment, the intelligent agent can use the task execution system to parse the acquired target task into a target task graph with dependencies. Based on the node semantics and context of each task node in the target task graph, it independently calculates the permission requirement set for each task node, achieving precise binding between the permission requirement set and specific task nodes. This allows for the on-demand and dynamic allocation of necessary permissions to different stages during target task execution, effectively avoiding premature and excessive granting of permissions and permission abuse during task execution.

[0249] Example 4

[0250] Figure 6 This is a schematic diagram of the structure of an electronic device according to Embodiment 4 of this disclosure. The electronic device includes a memory, a processor, and a computer program stored in the memory and used to run on the processor. When the processor executes the computer program, it implements the execution method of the task described in any of the above embodiments. Figure 6 The electronic device 60 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0251] like Figure 6 As shown, the electronic device 60 can be manifested as a general-purpose computing device, such as a server device. The components of the electronic device 60 may include, but are not limited to: at least one processor 61, at least one memory 62, and a bus 63 connecting different system components (including memory 62 and processor 61).

[0252] Bus 63 includes a data bus, an address bus, and a control bus.

[0253] The memory 62 may include volatile memory, such as random access memory (RAM) 621 and / or cache memory 622, and may further include read-only memory (ROM) 623.

[0254] The memory 62 may also include a program tool 625 (or utility) having a set (at least one) program module 624, such program module 624 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0255] The processor 61 executes various functional applications and data processing, such as the task execution methods provided in any of the above embodiments, by running computer programs stored in the memory 62.

[0256] Electronic device 60 can also communicate with one or more external devices 64 (e.g., keyboard, pointing device, etc.). This communication can be performed through input / output (I / O) interface 65. Furthermore, electronic device 60 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public network, such as the Internet) via network adapter 66. As shown, network adapter 66 communicates with other modules of electronic device 60 via bus 63. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 60, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (disk array) systems, tape drives, and data backup storage systems.

[0257] It should be noted that although several units / modules or sub-units / modules of the electronic device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0258] Example 5

[0259] This disclosure also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the execution method of the task provided in any of the above embodiments.

[0260] The readable storage medium may be more specifically adopted, including but not limited to: portable disk, hard disk, random access memory, read-only memory, erasable programmable read-only memory, optical storage device, magnetic storage device, or any suitable combination thereof.

[0261] Example 6

[0262] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the execution method of any of the tasks described above.

[0263] The program code for executing the computer program product of this disclosure can be written in any combination of one or more programming languages, and the program code can be executed entirely on a user device, partially on a user device, as a stand-alone software package, partially on a user device and partially on a remote device, or entirely on a remote device.

[0264] While specific embodiments of this disclosure have been described above, those skilled in the art should understand that these are merely illustrative examples, and the scope of protection of this disclosure is defined by the appended claims. Those skilled in the art can make various changes or modifications to these embodiments without departing from the principles and essence of this disclosure, but all such changes and modifications fall within the scope of protection of this disclosure.

Claims

1. A method for executing a task, characterized in that, The execution method includes: Obtain the target task and the context information for executing the target task; Based on the task semantics of the target task, a target task graph is generated, wherein the target task graph includes at least one task node and the dependencies between the task nodes; Based on the node semantics of the task node, the context information, and the dependencies, determine the set of permission requirements for executing the task node; Execute the target task based on the set of permission requirements and the target task graph.

2. The execution method as described in claim 1, characterized in that, The step of determining the permission requirement set for executing the task node based on the node semantics of the task node, the context information, and the dependencies includes: In response to the need to call external resources when executing the task node, obtain the resource information of the external resources; Based on the node semantics of the task node, the context information, the dependencies, and the resource information, determine the set of permission requirements for executing the task node; And / or, Based on the node semantics of the task node, determine the risk level of executing the corresponding task node; The set of permission requirements for executing the task node is determined based on the node semantics of the task node, the context information, the dependencies, and the risk level.

3. The execution method as described in claim 2, characterized in that, The step of executing the target task based on the permission requirement set and the target task graph includes: The permission requirement set of the task node is encapsulated to obtain the permission envelope of the task node; The permission envelope is signed to generate the permission token for the task node; In response to the execution of the task node, the permission token of the task node and the task node's request to call the external resource are obtained; The permission token and the call request are verified according to preset verification rules, and the verification results are obtained. If the verification result is successful, the target task is executed according to the permission requirement set and the target task graph.

4. The execution method as described in claim 3, characterized in that, The task node includes a first task node and a second task node, and the execution of the second task node depends on the execution of the first task. The step of signing the permission envelope to generate the permission token for the task node includes: Obtain the first permission forwarding count from the permission token of the first task node; Based on the number of times the first permission is forwarded, determine the number of times the second permission is forwarded for the second task node; Based on the second permission forwarding count, the permission envelope of the second task node is signed to generate the permission token of the second task node.

5. The execution method as described in claim 1, characterized in that, The step of executing the target task based on the permission requirement set and the target task graph includes: In response to detecting an update to the target task, a new target task graph is regenerated based on the updated target task, and the permission requirement set of the task nodes in the new target task graph is redefined. Based on the redefined set of permission requirements and the new target task graph, execute the updated target task.

6. The execution method as described in claim 1, characterized in that, The execution method further includes: In response to the completion of the target task, the permission request set is terminated; And / or, In response to the detection that the target task is not executed according to the permission requirement set and the target task graph, the process is carried out according to the preset processing method.

7. A task execution system, characterized in that, The execution system includes: The acquisition module is used to acquire the target task and the context information when executing the target task; A generation module is configured to generate a target task graph for the target task based on the task semantics of the target task, wherein the target task graph includes at least one task node and the dependencies between the task nodes; The determination module is used to determine the set of permission requirements for executing the task node based on the node semantics of the task node, the context information, and the dependency relationship; The execution module is used to execute the target task according to the permission requirement set and the target task graph.

8. An intelligent agent, characterized in that, The intelligent agent includes the task execution system described in claim 7.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and for running on the processor, characterized in that, When the processor executes the computer program, it implements the method for executing the task according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method for executing the task as described in any one of claims 1 to 6.

Images