Task adaptation and recoverable execution method and system for heterogeneous intelligent agent running framework

Abstract

The application provides a task adaptation and recoverable execution method and system of a heterogeneous intelligent agent running framework. The method provided by the application comprises the following steps: receiving a business task request, generating a unified task description decoupled from an intelligent agent running framework; determining a target intelligent agent running framework, converting the unified task description into a running task through an intelligent agent runtime adapter; when the target intelligent agent running framework executes a running task to trigger a tool call request, injecting a task scene context into the tool call request, generating a unified tool call envelope, and generating an idempotent key based on a task step feature, performing idempotent control on the tool call according to the idempotent key and executing the tool call to obtain a tool call execution result; extracting a portable core and a framework private state of the running task in a current execution state, and generating a combined checkpoint; when a running task fails or the target intelligent agent running framework is switched, incrementing a task generation number, freezing an old generation task instance, and performing a recovery operation.

Description

Technical Field

[0001] This application relates to the fields of intelligent agent operation, distributed workflow and sea trial information processing technology, and in particular to a method and system for task adaptation and recoverable execution of heterogeneous intelligent agent operation framework. Background Technology

[0002] With the widespread deployment of agent technology in complex business scenarios, business platforms often need to interface with various heterogeneous agent runtime frameworks. Different frameworks differ in their design of task definitions, state representations, tool call interfaces, and checkpoint formats: some use directed state graphs and node checkpoints, some use sessions and action loops, and some use queue-driven workflows or self-developed executors. Meanwhile, the tasks undertaken by agents are typically characterized by long execution times, multiple steps, cross-data channels, and high tool call costs. During execution, framework switching or resumption may be necessary due to runtime failures, framework upgrades, or strategy adjustments. In this context, if a business system directly depends on the node, session, or storage interfaces of a particular framework, framework replacement will affect the entire chain, including task services and front-end display. If a portable checkpoint mechanism is lacking when a task fails, it must be re-executed from the beginning, resulting in the repeated execution of completed tool calls. Therefore, how to achieve task adaptation and resumable execution between heterogeneous agent runtime frameworks has become an urgent technical problem to be solved.

[0003] Currently, existing solutions for accessing and restoring heterogeneous intelligent agent runtime frameworks typically adopt the following approaches: developing separate business interfaces for each framework, with the task status and checkpoints of each framework directly stored in the business database; or encapsulating the start and stop commands of different frameworks with a unified interface, but only unifying the interface form without unifying the task semantics; saving the complete dialogue history and re-executing the task when it fails, replacing state restoration with dialogue replay; the business scenario information for tool calls is generated by the intelligent agent model itself, and the platform does not intervene in context construction and call control; after task cancellation or framework switching, late events generated by the original running instance are not isolated.

[0004] The existing solutions described above have the following problems and shortcomings: First, the business system is deeply coupled with the specific framework. Task states and checkpoint storage depend on internal objects of a specific framework, and replacing the framework requires modifications to business services and the operation and maintenance system. Second, checkpoints are not portable; the saved internal states of the framework serialization can only be restored by the original framework and cannot be continued on another framework. Third, tool calls lack unified idempotency control, and high-cost tools may be repeatedly called when the network times out or the task is resumed, resulting in duplicate computations and duplicate data products. Fourth, fault recovery relies on rerunning from scratch; completed tool calls cannot be safely reused, prolonging recovery time. Fifth, the task scenario context is generated by the model itself, which can easily omit key information such as business domains and scenario scope, resulting in a lack of business scenario constraints for tool calls. Sixth, after task cancellation or framework switching, late events generated by the original running instance may still continue to update the task state or trigger tool calls, causing resource waste and state chaos. In summary, the above problems are concentrated on the incompatibility and portability of tasks between heterogeneous intelligent agent running frameworks and the inability to recover across frameworks after a fault.

[0005] Therefore, there is an urgent need for a method to solve the problem of incompatibility and portability of tasks between heterogeneous intelligent agent operating frameworks and the inability to recover across frameworks after a failure. Summary of the Invention

[0006] In view of this, this application provides a method and system for task adaptation and recoverable execution of heterogeneous intelligent agent runtime frameworks, in order to solve the problems of incompatibility and portability of tasks between heterogeneous intelligent agent runtime frameworks and the inability to recover across frameworks after failure.

[0007] Specifically, this application is implemented through the following technical solution:

[0008] The first aspect of this application provides a method for task adaptation and resumable execution of a heterogeneous intelligent agent runtime framework, the method comprising:

[0009] Receive business task requests and generate a unified task description decoupled from the intelligent agent's operating framework;

[0010] The target intelligent agent runtime framework is determined from multiple heterogeneous intelligent agent runtime frameworks, and the unified task description is converted into a runtime task that meets the requirements of the target intelligent agent runtime framework through an intelligent agent runtime adapter;

[0011] When the target intelligent agent's operating framework executes the running task and triggers the tool call request, the task scenario context is injected into the tool call request, a unified tool call envelope is generated, and an idempotent key is generated based on the task step characteristics. The tool call is then idempotently controlled and executed according to the idempotent key to obtain the tool call execution result.

[0012] At the trigger time of the combined checkpoint generation, the portable core and framework private states of the running task in the current execution state are extracted, a combined checkpoint is generated and stored;

[0013] When the running task fails or the target agent's running framework is switched, the task generation number is incremented, the old generation task instance is frozen, and a recovery operation is performed. In the recovery operation, the task context is reconstructed using the portable core in the stored combined checkpoints, and the tool call execution result corresponding to the successfully matched idempotent key is reused.

[0014] The second aspect of this application provides a task adaptation and recoverable execution system for a heterogeneous intelligent agent operating framework, the system comprising a generation module, a conversion module, a control module and a recovery module;

[0015] The generation module is used to receive business task requests and generate a unified task description that is decoupled from the intelligent agent operation framework.

[0016] The conversion module is used to determine the target intelligent agent runtime framework from multiple heterogeneous intelligent agent runtime frameworks, and convert the unified task description into a runtime task that meets the requirements of the target intelligent agent runtime framework through an intelligent agent runtime adapter.

[0017] The control module is used to inject a task scenario context into the tool call request when the target intelligent agent's running framework executes the running task and triggers the tool call request, generate a unified tool call envelope, generate an idempotent key based on the task step characteristics, perform idempotent control on the tool call according to the idempotent key and execute it, and obtain the tool call execution result.

[0018] The generation module is also used to generate a triggering time for the combined checkpoint, extract the portable core and framework private states of the running task in the current execution state, generate a combined checkpoint and store it.

[0019] The recovery module is used to increment the task generation number, freeze the old generation task instance, and perform a recovery operation when the running task fails or the target intelligent agent's running framework is switched; wherein, in the recovery operation, the task context is reconstructed using the portable core in the stored combined checkpoints, and the tool call execution result corresponding to the successfully matched idempotent key is reused.

[0020] The method and system for task adaptation and recoverable execution of heterogeneous intelligent agent runtime frameworks provided in this application firstly lay the semantic foundation for cross-framework adaptation by generating a framework-independent unified task description; secondly, it converts the unified task description into a runtime task executable by the target framework through an adapter, realizing the adapted execution of the same task on different frameworks; thirdly, it ensures the safety and reusability of tool calls during the execution phase by injecting scene context and idempotent control, while idempotent keys provide an index basis for tool call reuse in subsequent checkpoints and recovery; furthermore, it saves the portable core and framework private state by combining checkpoints, providing a state snapshot for recovery, where the idempotent keys of completed tool calls recorded in the portable core provide a matching basis for result reuse during recovery; finally, it isolates old instances through a generational mechanism, reconstructs the context using the portable core, and reuses successful results through idempotent keys, achieving rapid recovery after failure or framework switching. The process forms a complete technical link between each step: decoupled definition, adaptation and conversion, controlled execution, state preservation, and generational recovery. The unified task description is the foundation of decoupling, the adapter is the conversion bridge, the idempotent key runs through execution and recovery to achieve result reuse, the portability core in the combined checkpoint is the only basis for cross-framework recovery, and the generation number is the guarantee for isolating old instances. The five steps are mutually supportive and inseparable, enabling the same task to be executed on different heterogeneous intelligent agent running frameworks without the business system needing to be aware of the internal structure of the framework. Tool calls do not miss business scenario information and do not produce repeated side effects during retries. Checkpoints can be interpreted across frameworks and can be recovered in the original framework. After a failure or framework switch, recovery can be made quickly without having to run it from scratch, and interference from late events of canceled or recovered tasks is rejected. Attached Figure Description

[0021] Figure 1 A flowchart of the task adaptation and resumable execution method for the heterogeneous intelligent agent operation framework provided in Embodiment 1 of this application;

[0022] Figure 2 This is a schematic diagram of the task adaptation and recoverable execution system of the heterogeneous intelligent agent operation framework provided in Embodiment 2 of this application. Detailed Implementation

[0023] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0024] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0025] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0026] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0027] Figure 1 This is a flowchart illustrating the task adaptation and resumable execution method for the heterogeneous intelligent agent runtime framework provided in Embodiment 1 of this application. Please refer to... Figure 1 The method provided in this embodiment may include:

[0028] S101. Receive business task requests and generate a unified task description decoupled from the intelligent agent's operating framework.

[0029] It should be noted that this application applies to a submersible sea trial platform. The submersible sea trial platform is a business system for managing submersible sea trial missions, covering business scenarios such as test data query, anomaly analysis, trajectory prediction, mission planning assistance, knowledge retrieval, and report generation. During submersible sea trials, a task often requires first parsing the user's objective, then querying mission and equipment information, reading telemetry or object data, calling traditional algorithms or large models for calculation, summarizing evidence, generating results, and submitting them for review. This process is characterized by long execution time, multiple steps, cross-data channels, high tool call costs, and the need for manual confirmation midway. To meet the differentiated requirements of different mission types for model capabilities, execution modes, and recovery strategies, the sea trial platform needs to interface with multiple intelligent agent runtime frameworks. However, different frameworks are incompatible in terms of mission definition, state expression, tool call interfaces, and checkpoint formats. Therefore, this application sets up a unified runtime adaptation layer between the sea trial business mission service and multiple intelligent agent runtime frameworks. By generating a unified mission description decoupled from the framework, the same sea trial mission can be executed on different frameworks.

[0030] Specifically, an intelligent agent runtime framework refers to the runtime environment that provides AI agents with task creation, execution control, state management, tool invocation, pause and resume, checkpoint storage, and result output. Different intelligent agent runtime frameworks express tasks and states differently, and they are incompatible with each other in terms of tool description formats, streaming output mechanisms, pause and resume interfaces, error handling strategies, and checkpoint serialization formats.

[0031] A unified task description (UCD) is a framework-independent task description object decoupled from the agent's runtime framework. It establishes semantic isolation between business task requests and the specific execution framework. A UCD must include at least the following: task identity (task identifier, task type, creation time, priority, and deadline); scenario context (business domain, stable scenario, project, trial task, entity scope, and context version); objectives and constraints (objectives, completion conditions, prohibited actions, maximum steps, resource budget, and manual confirmation points); data input (data product identifier, version, time envelope, object summary, and access purpose); tool authorization (allowed tools, parameter constraints, number of calls, data scope, and authorized snapshot); output contract (result type, schema version, quality requirements, and result submission interface); recovery strategy (maximum retries, recoverable errors, checkpoint cycle, and timeout and compensation strategies); and tracking information (parent task, associated tasks, tracking identifier, and audit level). The UCD does not store the binary entity content of data files; it only stores immutable data products or object references to avoid large objects entering the task state, which would increase memory and serialization overhead. The runtime adapter can convert the goals and constraints in the unified task description into system hints, state nodes, or session configurations required by the target framework, but it cannot remove the scenario context and tool authorization fields, thus ensuring that the task always carries complete business scenario constraints and security authorization information when executed across frameworks.

[0032] In practice, the system receives business task requests submitted from the sea trial business system or the user frontend. This request carries at least the task objective text, task type, priority, deadline, business domain identifier, scenario identifier, project identifier, sea trial task identifier, and entity scope identifier. A globally unique task identifier is assigned to this request, recording the task type, creation time, priority, and deadline, and written into the task identity field of the unified task description. The business domain, stable scenario, project, sea trial task, and entity scope are extracted from the business task request and written into the scenario context field of the unified task description, with a context version number assigned. The context version number is used to identify whether the scenario context has changed during task execution; if the scenario scope is adjusted during execution, the context version number is incremented. The task objective text in the business task request is parsed into a structured objective, and based on the task type, a preset completion condition template, a list of prohibited actions, a maximum number of steps, resource budget, and manual confirmation points are matched and written into the objective and constraint fields of the unified task description. The list of prohibited actions is determined based on the business domain; for example, the sea trial domain prohibits the use of equipment control tools. Manual confirmation points are set based on the task risk level; for example, manual confirmation points are set before result release and before high-risk operations. Based on the task objectives and entity scope, the data product catalog is queried to determine the required data product identifier, version, time envelope, and object summary, which are then written into the data input field of the unified task description. This field does not store the binary entity content of the data file, but only the reference information of immutable data products or objects. Based on the task type and business domain, the list of allowed tools, parameter constraints of each tool, maximum number of calls, and data scope restrictions are determined from the preset tool permission configuration, and the current authorization snapshot is obtained and written into the tool authorization field of the unified task description. The authorization snapshot records the authorization scope valid at the time of task creation and is used for intersection verification with the scenario context when subsequent tools are called. Based on the task type, a preset output contract template is matched to determine the result type, mode version, quality requirements, and result submission interface, which are then written into the output contract field of the unified task description. Based on the task type and resource budget, a preset recovery strategy template is matched to determine the maximum number of retries, the list of recoverable error types, the checkpoint cycle, the timeout threshold, and the compensation strategy, which are then written into the recovery strategy field of the unified task description. Based on the association information carried in the business task request, the parent task identifier, associated task identifier, and tracking identifier are determined, and the audit level is set according to the business domain requirements, which are then written into the tracking information field of the unified task description. Perform an integrity check on the generated unified task description to confirm that the scenario context and tool authorization fields are not empty and conform to the preset format, and to confirm that the data input fields do not contain binary entity content. After the check passes, store the unified task description in the task storage.

[0033] S102. Determine the target intelligent agent runtime framework from multiple heterogeneous intelligent agent runtime frameworks, and convert the unified task description into a runtime task that meets the requirements of the target intelligent agent runtime framework through an intelligent agent runtime adapter.

[0034] Specifically, the target intelligent agent operating framework refers to the operating framework selected from multiple heterogeneous intelligent agent operating frameworks connected to the sea trial platform, after capability negotiation and comprehensive scoring, for executing the current unified task description. The sea trial platform registers multiple heterogeneous intelligent agent operating frameworks, each with a capability description. This description includes the model types supported by the framework, state diagram format, parallel tool invocation capability, streaming event capability, pause and resume capability, manual confirmation capability, native checkpoint capability, maximum task time, maximum context length, structured output capability, and sandbox capability. During the selection process, based on the task requirements in the unified task description, the capability descriptions are divided into required capabilities and preferred capabilities. Frameworks that do not meet the required capabilities are first filtered out. Then, the remaining frameworks are comprehensively scored based on the preferred capability satisfaction, estimated resource cost, failure risk, and data locality indicators. The framework with the highest score is determined as the target intelligent agent operating framework.

[0035] The agent runtime adapter refers to the adaptation layer component set up between the sea trial business task service and the agent runtime framework, used for bidirectional conversion between the unified task protocol and the internal protocol of the specific framework. Each agent runtime framework corresponds to one runtime adapter, and the adapter implements at least the following logical interfaces: initialization interface, which maps the unified task description to the executable runtime task of the target framework; execution interface, which starts or continues task execution and outputs normalized runtime events; pause interface, which requests the framework to stop generating new actions and return to a stable point; export checkpoint interface, which extracts the portable core and framework private state; resume interface, which uses combined checkpoints to resume execution on the original framework or a compatible framework; cancel interface, which terminates the operation and releases temporary credentials; event normalization interface, which maps the framework's internal events to platform unified events; result normalization interface, which converts the framework output into a unified candidate result envelope according to the output contract; and health and capability interface, which reports the framework version, adapter version, and current capabilities. The adapter cannot directly pass any internal events of the framework to the formal business topic, and only allows the output of whitelisted events, including stage progress, tool requests, manual confirmation requests, evidence citations, warnings, candidate results, and termination status. The adapter can be deployed in the same process as the runtime framework, or it can be deployed as a standalone service.

[0036] A runtime task refers to a specific task instance that the target agent's runtime framework can recognize and execute. It is generated by the agent runtime adapter after transforming a framework-independent unified task description. The specific form of the runtime task depends on the type of the target framework. During the transformation process, the adapter can decompose the target in the unified task description into framework state nodes or action steps, map constraints to framework execution limitations, and map data input references to framework-accessible input handles. However, it must not delete the scenario context and tool authorization fields in the unified task description to ensure that the runtime task always carries business scenario constraints and security authorization information during execution. After the runtime task is generated, it is loaded by the target agent's runtime framework and enters the execution state. Its internal state during execution is mapped to platform unified events through the adapter's event normalization interface.

[0037] In specific implementation, determining the target intelligent agent operating framework from multiple heterogeneous intelligent agent operating frameworks includes: obtaining the capability descriptions of each heterogeneous intelligent agent operating framework according to the task requirements in the unified task description; screening each heterogeneous intelligent agent operating framework based on the required capabilities in the capability descriptions, filtering out intelligent agent operating frameworks that do not meet the required capabilities; and comprehensively scoring the remaining intelligent agent operating frameworks after screening based on the preferred capability satisfaction, estimated resource cost, failure risk, and data locality indicators in the capability descriptions, and determining the one with the highest score as the target intelligent agent operating framework.

[0038] Specifically, task type, objectives and constraints, resource budget, recovery strategy, and entity scope are extracted from the generated unified task description as task requirements. The task type is used to match required capabilities, the resource budget for cost assessment, the checkpoint cycle and maximum retries in the recovery strategy for failure risk assessment, and the entity scope for data locality assessment. Capability descriptions of all registered agent runtime frameworks are read from the runtime registry. Each capability description includes the model types supported by the framework, state diagram format, parallel tool invocation capabilities, streaming event capabilities, pause and resume capabilities, manual confirmation capabilities, native checkpoint capabilities, maximum task time, maximum context length, structured output capabilities, and sandbox capabilities, along with a version number for each capability. Based on the task type and recovery strategy in the unified task description, the set of required capabilities is determined. Required capabilities refer to those that the framework must possess to execute the task. For example, if a manual confirmation point is set in the unified task description, then manual confirmation capability is a required capability; if the recovery strategy requires a non-zero checkpoint period, then native checkpoint capability is a required capability; if the task type requires calling external tools, then tool invocation capability is a required capability; if the task constraints require structured output, then structured output capability is a required capability. The capability description of each agent's runtime framework is checked one by one to determine if it meets all required capability items. If a framework lacks any required capability, or if the support level of a required capability is lower than the minimum threshold specified by the task requirements, then the framework is filtered out of the candidate list, and the remaining frameworks constitute the candidate runtime set. The set of preferred capability items and their weights are determined from the task requirements. Preferred capabilities refer to capabilities that affect the task execution effect but are not essential. Preferred capability items include at least one of the following: structured output capability, parallel tool invocation capability, streaming event capability, and sandbox capability. The weights are read from a preset weight configuration according to the task type; different task types have different emphases on each preferred capability. For each framework r in the candidate runtime set, evaluate its satisfaction level ci(r) for the i-th preferred capability. The satisfaction level is a value between 0 and 1, determined by the support level of the capability in the framework capability description: 1 for full support, an intermediate value for partial support, and 0 for no support. Based on the resource budget in the unified task description and the capability descriptions of each framework, estimate the resource cost Cost(r) for each candidate framework r to execute the task. The resource cost includes the estimated cost of model calls, the estimated execution time, and the estimated memory usage, normalized to a dimensionless value using a preset conversion factor. Query historical execution records and calculate the historical failure rate of this task type on each candidate framework r, as the failure risk Risk(r). If there is no historical record, use the preset default risk value. The failure risk is also normalized to a dimensionless value. Evaluate the data locality index based on the data storage location pointed to by the entity scope in the unified task description and the deployment location of each framework.If the framework deployment location and the data storage location are close in network distance or within the same availability zone, a higher value is used for the data locality metric; if cross-zone access is required, a lower value is used. For each framework r in the candidate runtime set, the comprehensive score is calculated according to the following formula:

[0039] Score(r) = Σ wi × ci(r) - λ1 × Cost(r) - λ2 × Risk(r);

[0040] Where Score(r) is the overall score; wi is the weight of the i-th optimal capability; ci(r) is the satisfaction of the i-th optimal capability with framework r; Cost(r) is the estimated resource cost; Risk(r) is the failure risk; λ1 and λ2 are the preset cost penalty coefficient and risk penalty coefficient.

[0041] The overall scores of the candidate frameworks are compared, and the framework with the highest overall score is selected as the target agent's operating framework. If multiple frameworks have the same score and are all at the highest level, the one with the highest data locality index is selected; if they are still the same, the one with the earliest registration order is selected.

[0042] Furthermore, after determining the target agent's runtime framework, the corresponding runtime adapter instance is obtained, and the adapter's initialization interface is called, passing the unified task description to the adapter. The adapter determines the conversion strategy based on the target framework type. The adapter reads the objective, completion conditions, prohibited actions, maximum steps, resource budget, and manual confirmation points from the unified task description, and converts them into execution instructions recognizable by the framework according to the target framework type. For directed state graph frameworks, the adapter decomposes the objective in the unified task description into state nodes, maps the completion conditions to termination node judgment conditions, maps manual confirmation points to blocking waiting nodes between nodes, and maps prohibited actions to node execution constraints. During framework execution, node entry into a state is mapped to the stage progress in the platform's unified events, and node-triggered tool calls are mapped to tool request events. For session action loop frameworks, the adapter combines the objective and constraints into system prompt text, maps the completion conditions to session end judgment rules, and maps manual confirmation points to session pause trigger conditions. During framework execution, the start of each session is mapped to the stage progress, and tool calls generated during the session are mapped to tool request events. The adapter reads the business domain, stable scenario, project, trial task, entity scope, and context version from the unified task description and converts them into a context injection format supported by the target framework. The scenario context must remain complete after conversion; no fields may be deleted or reduced. The adapter reads the list of allowed tools, parameter constraints, maximum number of calls, data range limits, and authorized snapshots from the unified task description. It registers allowed tools as framework-callable tool definitions, writes parameter constraints into the tool's parameter validation rules, and stores the authorized snapshots internally for subsequent validation. Tools corresponding to prohibited actions are not registered. The adapter reads the data product identifier, version, time envelope, and object summary from the unified task description and converts them into resource identifiers or data pointers recognizable by the target framework. It does not embed data file content; the framework reads these on demand during execution via the controlled tool gateway. The adapter reads the result type, mode version, quality requirements, and result submission interface from the unified task description. It writes the result type and mode version into the framework's output format constraints and registers the result submission interface as a callback target after framework completion. The adapter reads the maximum number of retries, the list of recoverable error types, the checkpoint cycle, the timeout threshold, and the compensation strategy from the unified task description. It writes the checkpoint cycle into the framework's checkpoint trigger configuration or sets the tool boundary checkpoint trigger internally within the adapter, and writes the list of recoverable error types into the adapter's fault classification configuration. The adapter verifies that the scenario context field and tool authorization field are fully preserved and have not been deleted or reduced. If any are found to be missing, the conversion is aborted and an error is returned. The adapter assembles the conversion result into a runnable task instance that the target framework can load, calls the framework's task creation interface to load it into the framework, and records the mapping relationship between the runnable task instance identifier and the task identifier within the framework internally within the adapter.The adapter sets the task's unified state to initialize, assigns an initial generation number and an initial state sequence number, and sends a task-initialized event to the platform through the event normalization interface.

[0043] S103. When the target intelligent agent's operating framework executes the running task triggering tool call request, a task scenario context is injected into the tool call request, a unified tool call envelope is generated, and an idempotent key is generated based on the task step characteristics. The tool call is then idempotently controlled and executed according to the idempotent key to obtain the tool call execution result.

[0044] Specifically, a tool invocation request refers to an invocation request generated by the target framework when it needs to call external tools during the execution of a task. This request includes the tool identifier and invocation parameters. It is generated internally by the framework, is not processed by the platform, and does not carry business scenario information. External tools include data querying, algorithm calculation, and result submission.

[0045] The task scenario context is business scope information extracted from the unified task description, including business domain, stable scenario, project, sea trial task, and entity scope. The scenario context is not generated freely by the model; instead, it is injected into the tool invocation request by the platform from the unified task description to constrain the business scope of the tool invocation.

[0046] A unified tool invocation envelope is a standardized invocation encapsulation generated by the adapter after injecting task scenario context and platform control information into the tool invocation request. It includes at least the task identifier, generation number, step identifier, tool identifier, tool mode version, business domain, stable scenario, project, trial task, entity scope, parameters, data reference, authorized snapshot, idempotent key, deadline, and tracking identifier. The tool gateway only accepts tool invocations in the form of unified tool invocation envelopes and does not accept raw invocations initiated directly by the framework.

[0047] A task step feature is a set of information uniquely identifying a tool invocation logical step, including the task identifier, logical step, tool identifier, normalized parameters, and input data version. Normalized parameters are serialized according to a fixed field order, unit, and numerical precision to ensure that parameters with the same semantics produce the same serialization result. A logical step refers to a semantic step decomposed from the goal in the unified task description; each logical step corresponds to an independent intent unit in task execution. For example, querying data and invoking an algorithm are two different logical steps. Logical steps are assigned by the adapter when transforming the unified task description, and the same logical step maintains the same step identifier in different execution attempts.

[0048] An idempotent key is a key-value pair generated by hashing the characteristics of task steps. The same task, the same logical steps, the same tool, the same parameters, and the same input version will result in the same idempotent key. The idempotent key is used to query the idempotent call record table before a tool call to determine whether the call has already been executed, thus deciding whether to execute, reuse, wait, or retry.

[0049] The tool call execution result is the output data generated after the tool is executed. For read-only query tools, the result cache is a versioned data reference; for product creation tools with side effects, the result includes the created product identifier and status. The tool call execution result is associated with the corresponding idempotent key and stored in the idempotent call record table. During task retries or cross-framework recovery, the result is directly reused through idempotent key matching, without being executed repeatedly.

[0050] In specific implementation, injecting the task scenario context into the tool call request and generating a unified tool call envelope includes: extracting the business domain, stable scenario, project, sea trial task, and entity scope from the unified task description as the task scenario context, and injecting the task scenario context into the tool call request to generate a unified tool call envelope; performing an intersection operation to verify the task scenario context in the unified tool call envelope with a pre-acquired authorization snapshot; if the task scenario context is detected to exceed the range allowed by the authorization snapshot, the tool call request is rejected.

[0051] Specifically, during the execution of a task, the target intelligent agent's runtime framework generates a tool invocation request based on the task's progress. This request is not sent directly to the tool execution end but is intercepted by the adapter. The business domain, stable scenario, project, sea trial task, and entity scope are read from the unified task description as the task scenario context. The task scenario context is merged with the tool identifier, parameters, and data references from the tool invocation request, and supplemented with the task identifier, generation number, step identifier, tool mode version, authorization snapshot, idempotent key, deadline, and tracking identifier, assembled into a unified tool invocation envelope. The authorization snapshot obtained at the time of task creation is read from the tool authorization field of the unified task description. The authorization snapshot records the valid data range and tool invocation permissions at the time of task creation. The task scenario context in the unified tool invocation envelope is intersected with the authorization snapshot to verify whether the business domain, scenario, project, sea trial task, and entity scope in the tool invocation request all fall within the range allowed by the authorization snapshot. If all fields in the task scenario context fall within the range allowed by the authorized snapshot, the verification passes, and the unified tool call envelope enters the subsequent idempotent control process; if fields exceeding the range allowed by the authorized snapshot are detected in the task scenario context, the tool call request is rejected, the tool call is not executed, and a rejection reason is returned.

[0052] Furthermore, the step of generating idempotent keys based on task step features, and performing idempotent control and execution of tool calls based on the idempotent keys, includes: extracting task identifiers, logical steps, tool identifiers, normalized parameters serialized according to fixed field order and precision, and input data versions; generating idempotent keys through hash operations; querying the idempotent call record table before executing the tool call; if the idempotent key does not exist, creating an execution record and initiating the tool call; if the idempotent key exists and the status is successful, directly returning a reference to the original tool call execution result; if the idempotent key exists and the status is in execution, returning a waiting flag or subscribing to a completion event; if the idempotent key exists and the status is retryable failure, initiating a new attempt while keeping the idempotent key unchanged when the retry condition is met; if the idempotent key exists and the status is unknown, first querying the tool execution end or performing a compensation check to determine the success or failure status before processing; if the input data version or the normalized parameters change, generating a new idempotent key and a new call record. Among them, compensation check refers to the process of determining the success or failure status of a tool call whose status is unknown by querying the actual execution status of the call from the tool execution end or by performing a verification operation to confirm whether the call has produced side effects.

[0053] Specifically, the task identifier, logical steps, tool identifier, and input data version are extracted from the unified tool call envelope. The tool call parameters are serialized according to a fixed field order, unit, and numerical precision to obtain normalized parameters. These five items together constitute the task step characteristics. A hash operation is performed on the task step characteristics to generate an idempotent key K = Hash(task identifier + logical steps + tool identifier + normalized parameters + input data version). The idempotent call record table is queried using the idempotent key as an index. Based on the query result, six cases are processed, each yielding the corresponding tool call execution result: If the idempotent key does not exist, a record with an execution status is created in the idempotent call record table, and a tool call is initiated to the tool execution end. After the call is completed, the status is updated to success or failure, and the tool call execution result is stored. If the idempotent key exists and the status is success, the tool call is not initiated, and the reference to the original tool call execution result already stored in the idempotent call record table is directly returned. If the idempotent key exists and the status is in progress, the call is not initiated again, and a waiting flag is returned, or the caller subscribes to the completion event of the idempotent key and receives the result notification after the original call is completed. If the idempotent key exists and the status is retryable failure, the retry count and backoff strategy are checked to see if a new attempt is allowed. If allowed, a new attempt is initiated while keeping the idempotent key unchanged, and the retry count is updated; if not allowed, failure is returned. If the idempotent key exists and the status is unknown, the call is not blindly repeated. The actual execution status of the call is first queried from the tool execution end, or a compensation check is performed to determine success or failure before processing according to the success or failure branch. If the input data version or normalization parameters change, and the original idempotent key is no longer applicable, a new idempotent key is re-hash-generated based on the changed task step characteristics, a new call record is created in the idempotent call record table, and the case is processed as the first execution branch, i.e., the case where the idempotent key does not exist.

[0054] S104. At the trigger time of the combined checkpoint generation, extract the portable core and framework private states of the running task in the current execution state, generate a combined checkpoint and store it.

[0055] Optionally, the timing for generating the combined checkpoint includes: when the running task initialization is completed, before and after a tool call, before and after manual confirmation, when a verifiable sub-goal is completed, when a preset time or step cycle is reached, and before the running task is paused, malfunctions, or the target intelligent agent running framework is switched; wherein, when generating the combined checkpoint, the initiation of new tool calls is first prevented, and the status of in-transit tool calls is confirmed; if there are in-transit tool calls whose status cannot be confirmed in a timely manner, the in-transit tool calls are marked as unknown in the combined checkpoint, and when execution is resumed, the status query or compensation check of the in-transit tool calls in the unknown state is first performed.

[0056] Optionally, the portable core includes a framework-independent unified task description version, unified state, summary of completed steps, incomplete objectives, evidence references, idempotent keys of completed tool calls, data product references, manual confirmation records, and output draft constraints. The framework-private state stores the node states, session cursors, or internal checkpoint references required for the recovery of the target agent's runtime framework. Specifically, when recovering within the same agent's runtime framework, the framework-private state is preferentially invoked for continuation, and the portable core is used to verify the continuation result. When recovering across agent runtime frameworks, the task context is reconstructed using only the portable core, and the execution results of successfully executed tool calls are reused through idempotent key matching.

[0057] Specifically, a composite checkpoint refers to a snapshot of the task state generated periodically or triggered by events during the execution of a running task. It consists of three parts: a portable core, framework-private state, and a content summary, denoted as CP =<PortableCore,RuntimePrivate,Digest> Here, CP stands for Combinatorial Checkpoint, PortableCore for Portable Core, RuntimePrivate for Framework Private State, and Digest for Content Summary. The Combinatorial Checkpoint simultaneously stores cross-framework interpretable portable information and the private information required for recovery of the original framework, enabling tasks to be accurately continued in the original framework and reconstructed and recovered on heterogeneous frameworks.

[0058] The generation trigger timing refers to the preset timing during which the system automatically triggers the generation of combined checkpoints during task execution. This includes: when the task initialization is complete, before and after a tool call, before and after manual confirmation, when a verifiable sub-goal is completed, when a preset time or step cycle is reached, and before the task is paused, malfunctions, or the target framework is switched. When triggering generation, new tool calls are prevented from being initiated, and status data is read only after an in-transit tool call enters a confirmed state. If the status of an in-transit tool call cannot be confirmed in time, it is marked as an unknown state and written into the combined checkpoint for later querying and confirmation upon recovery. Verifiable sub-goals refer to intermediate goals generated during task execution that can be determined to be complete based on preset conditions. For example, acquiring telemetry data within a specified time range is a verifiable sub-goal, whose completion condition is successful data return and data coverage of the entire time range.

[0059] The Portable Core is the framework-independent state portion of the composite checkpoint, containing a unified task description version, unified state, a summary of completed steps, incomplete goals, evidence references, idempotent keys of completed tool calls, data product references, human confirmation records, and output draft constraints. The Portable Core's internal object format is independent of any framework and can be read and understood by adapters from any framework, serving as the sole basis for reconstructing the task context during cross-framework recovery.

[0060] A unified state is an abstract representation of the execution status of running tasks on the platform, independent of any framework's internal state definition. Unified states include the following values: Pending Scheduling, Initializing, Running, Waiting for Tool, Waiting for Manual Confirmation, Paused, Resuming, Success, Recoverable Failure, Unrecoverable Failure, and Cancelled. The adapter maps the target framework's internal state to these unified states through an event normalization interface. For example, in a state graph framework, the "Executing" state of a node is mapped to "Running," and the "Waiting for External Response" state of a node is mapped to "Waiting for Tool." In a session-loop framework, "Waiting for User Input" is mapped to "Waiting for Manual Confirmation." The same framework's internal state may be mapped to different unified states at different execution stages; the mapping rules are recorded in the adapter configuration.

[0061] Framework-private state is the frame-specific state portion stored in the composite checkpoint required for target frame recovery, including node state, session cursors, or internal checkpoint references. Framework-private state can only be recognized and used by the original or compatible framework; the platform does not depend on its business semantics. During intra-frame recovery, the adapter prioritizes calling the framework-private state for precise continuation and utilizes the portable core to verify the continuation result. During cross-frame recovery, framework-private state is not used; only the portable core is used to rebuild the task context, and the results of successfully executed tool calls are reused through idempotent key matching.

[0062] In practice, the execution progress of the running task is monitored, and a combined checkpoint is triggered when any of the following conditions are met: completion of running task initialization, before tool call, after successful tool call, before manual confirmation, after manual confirmation, completion of verifiable sub-goals, reaching a preset time period or step period, before the running task is paused, when a fault occurs, or before switching target frameworks. After the combined checkpoint is triggered, the target framework is immediately prevented from initiating new tool call requests to ensure that the task status does not change due to new calls during the combined checkpoint generation period. All currently initiated but not yet completed tool calls in transit are queried to confirm their execution status. If an in-transit tool call has been completed, it is recorded as successful or failed; if an in-transit tool call is still in execution, it is waited for its completion or timeout. If there are in-transit tool calls whose status cannot be confirmed in a timely manner, the call is marked as an unknown status and is not blindly judged as successful or failed. Framework-independent status information is extracted from the current execution status, including unified task description version, unified status, summary of completed steps, uncompleted goals, evidence references, idempotent keys and result references of completed tool calls, data product references, manual confirmation records, and output draft constraints. The adapter's exported checkpoint interface is invoked to extract the private state required for target framework recovery, including node state, session cursor, or internal checkpoint references. The current runtime type, framework version, and adapter version are also recorded. The portable core, framework private state, and information on in-transit tool calls marked as unknown are assembled into a composite checkpoint. A content summary is calculated for the entire composite checkpoint, and the last valid composite checkpoint is registered as the parent checkpoint, establishing a checkpoint chain. The composite checkpoint is stored in the composite checkpoint store, the block on new tool calls is lifted, and the running task continues execution. During execution resumption, for in-transit tool calls marked as unknown, the idempotent call management module is queried or a compensation check is performed to confirm the status before processing.

[0063] Optionally, the combined checkpoint stores the data product identifier, version, spatiotemporal envelope, and content summary, but not the binary entity content of the data file. When the target intelligent agent's runtime framework needs to read the data file during the execution of the runtime task, the controlled tool gateway verifies the current authorization and issues a Uniform Resource Identifier carrying a validity period certificate for reading. After the validity period certificate expires, it is reissued as needed, and the identifier using the content summary as the same input data remains unchanged in the combined checkpoint and the idempotent key.

[0064] Specifically, when generating composite checkpoints, the data input only stores the data product identifier, version, spatiotemporal envelope, and content digest, without storing the binary entity content of the data file. When the framework needs to read the data file during execution, it initiates a read request to the controlled tool gateway. After verifying the current authorization, the controlled tool gateway issues a Uniform Resource Identifier (URI) carrying a validity period credential. The framework uses this identifier to read the data file. After the validity period credential expires, a new identifier is reissued as needed. In composite checkpoints and idempotent keys, the data content digest is always used as the identifier for the same input data, and it does not change due to changes in the access address. By excluding large objects from composite checkpoints, the storage volume and serialization overhead of composite checkpoints are significantly reduced, making the generation and recovery of composite checkpoints faster. Issuing access addresses on demand using short-term credentials avoids long-term exposure of data access permissions, improving security. Using an immutable content digest as the data identifier ensures that after the access address expires and is reissued, the data references in the idempotent key and composite checkpoint remain unchanged, preventing misjudgments of input data version changes due to address changes, thus avoiding redundant calculations and repeated tool calls.

[0065] S105. When the running task fails or the target intelligent agent's running framework is switched, increment the task generation number, freeze the old generation task instance, and perform a recovery operation.

[0066] In the recovery operation, the task context is reconstructed using the portable core in the stored combined checkpoints, and the tool call execution results corresponding to the successfully matched idempotent keys are reused.

[0067] Specifically, the task generation number is the version number that identifies the currently active execution instance of a task. An initial generation number is assigned when a task is first executed, and the state sequence number within the same generation increments sequentially. When a task is rebuilt from a composite checkpoint or the target framework is changed, the generation number increments, generating a new generation. Task instances in older generations are frozen, and their runtime events and tool call requests are rejected because the generation number they carry does not match the current generation number, preventing canceled or restored older instances from continuing to update task status or trigger tool calls.

[0068] In specific implementation, the incrementing of the task generation number and freezing of old generation task instances includes: incrementing the task generation number when the running task is initialized, reconstructed from the combined checkpoint, or the target agent running framework is replaced, and generating a state sequence number sequentially within the same generation; when a running event or tool call request is received, verifying the generation number carried by the running event or tool call request; if the generation number is inconsistent with the currently valid task generation number, determining that the corresponding running event or tool call request belongs to an old generation task instance that has been frozen, and refusing to process the running event or tool call request.

[0069] Specifically, when a running task fails or the target framework needs to be switched, the task generation number is incremented to generate a new generation. Within the new generation, the status sequence number is incremented sequentially from the initial value. The task instance corresponding to the original generation number is marked as frozen. Subsequently, running events and tool call requests carrying the original generation number undergo generation number verification upon receipt. If the generation number is inconsistent with the currently valid generation number, it is determined to be an event or request generated by the old generation instance and is rejected. The nearest valid combined checkpoint to the failure is read from the combined checkpoint storage, its content digest is verified, and the checkpoint is confirmed to be complete and intact. Each tool call in transit and tool call marked as unknown in the combined checkpoints is queried, and the actual execution status is checked with the idempotent call management module to determine success, failure, or need for compensation. For successful tool calls, their idempotent keys and result references are recorded for reuse; for failed tool calls, they are marked as pending retry; for tool calls requiring compensation, compensation checks are performed. The availability and health of the original target framework are checked. If the original framework is available, perform same-frame recovery; if the original framework is unavailable and the task allows framework switching, perform cross-frame recovery. During same-frame recovery, the recovery interface of the original framework adapter is called, passing in the framework's private state from the composite checkpoint. The adapter uses this private state for precise continuation and verifies the continuation result using the portable core. Successful tool call results are directly reused via idempotent key matching, without being executed repeatedly. After recovery, the task continues execution in the new generation. During cross-frame recovery, based on the required capabilities in the unified task description, a suitable backup framework is selected as the new target framework from the candidate frameworks. The recovery interface of the new target framework adapter is called, reconstructing the task context using only the portable core from the composite checkpoint, without using the original framework's private state. Completed tool call idempotent keys and result references from the portable core are injected into the new framework, along with manual confirmation records. Unfinished steps are replanned by the new framework. Successful tool call results with idempotent key matching are directly reused, without being executed repeatedly. The new generation number takes effect, and the new framework begins execution from the unfinished targets in the portable core. Subsequent runtime events and tool call requests will carry the new generation number, and late events and requests generated by old generation instances will be rejected due to generation number mismatch.

[0070] It should be noted that the following types of failures may occur during task execution: runtime transient failures, referring to temporary unavailability caused by framework process abnormalities or network fluctuations; tool transient failures, referring to tool call timeouts or returned errors; input invalidation, referring to expired data product versions or inaccessible data; authorization invalidation, referring to expired authorization snapshots or changed permissions; unrecoverable mode errors, referring to the framework entering a state where execution cannot continue; and user cancellation, referring to the user actively terminating the task. For runtime and tool transient failures, recovery is performed within the same framework; for input invalidation, data input references are updated to a valid version before recovery; for authorization invalidation, authorization snapshots are re-acquired before recovery; for unrecoverable mode errors, cross-framework recovery is performed; and for user cancellation, the current generation is frozen and not recovered.

[0071] Optionally, the method further includes: during the execution of the running task, shielding the internal thought text generated by the target intelligent agent running framework, and displaying the stage progress, tool requests, and warning events during the running process through a channel independent of the result publishing interface; after the running task is completed, the intelligent agent runtime adapter converts the execution result of the running task into a unified candidate result envelope and submits it to the unified result verification pipeline; the unified result verification pipeline performs spatiotemporal verification, data lineage verification, and quality verification on the unified candidate result envelope, and after the unified candidate result envelope passes the verification and approval, publishes the execution result of the running task to the target business system.

[0072] Specifically, during task execution, the framework-generated internal thought text is neither saved, broadcast, nor displayed. The adapter simply normalizes framework events into whitelisted events such as stage progress, tool requests, and warnings, and pushes them to the front end for display through a runtime event channel independent of the result publishing interface. After task execution, the adapter converts the framework's output into a unified candidate result envelope, containing context, result type, model version, input data version, model or algorithm version, tool call reference, spatiotemporal envelope, and quality summary, and submits it to the unified result verification pipeline. The verification pipeline sequentially performs spatiotemporal verification, data lineage verification, and quality verification. Upon successful verification, the result enters the review process, which includes at least one of manual review and rule-based review. Manual review involves authorized business personnel confirming the content of the candidate results, while rule-based review involves the system automatically verifying the candidate results according to preset business rules, including result format compliance checks and key indicator threshold checks. After approval, the result is published to the target business system. Candidate results are not directly written to the official database or official business topic. By shielding internal thought processes, unverified preliminary conclusions are prevented from contaminating the formal business system. Progress events and result releases use different channels, ensuring that a successful front-end task only indicates that a candidate result has been submitted, not released, thus avoiding confusion between intermediate outputs and formal results. All framework results are uniformly entered into the validation pipeline to ensure that results from different frameworks are consistent in terms of time and space, data lineage, and quality standards, preventing unqualified results from bypassing validation and directly entering the business system.

[0073] The method provided in this embodiment, in its first aspect, generates a unified task description decoupled from the intelligent agent's runtime framework. This decouples the expression of business tasks from the internal protocols of specific frameworks, making task definitions independent of any framework's node, session, or queue structure. When a framework needs to be replaced or upgraded, the business system only needs to maintain this unified task description interface, without modifying downstream links such as business services, tool services, and front-end display, thereby achieving decoupling between the business system and the framework. Simultaneously, the unified task description embeds scenario context and tool authorization fields, ensuring that tasks always carry complete business scenario constraints and security authorization information when executed across frameworks, preventing loss due to framework conversion.

[0074] Secondly, a runtime adapter transforms the framework-independent unified task description into a runtime task that the target framework can recognize and execute. This allows the same unified task description to adapt to different types of heterogeneous frameworks, achieving a single definition that can be executed across multiple frameworks. During the transformation process, the adapter preserves the scenario context and tool authorization fields, ensuring that runtime tasks are subject to the same business scenario constraints when executed on different frameworks. Internal events of different frameworks are normalized into platform-unified events through the adapter, eliminating the need for the platform to be aware of the framework's internal implementation.

[0075] Thirdly, by intercepting tool call requests generated by the framework and injecting task scenario context into the platform to generate a unified tool call envelope, the problem of missing key information such as business domain and entity scope due to the model's self-generated scenario context is avoided, ensuring that tool calls are always executed within the correct business scope. Intersection verification between authorized snapshots and scenario context prevents tool calls from exceeding the authorized scope. By generating idempotent keys based on task step characteristics and performing idempotency control, tool calls with the same task, logical steps, tools, parameters, and input versions are executed only once. Successful results are directly reused during network timeout retries or task recovery, avoiding redundant computations and data products caused by repeatedly calling high-cost tools.

[0076] Fourthly, by simultaneously storing portable core and framework-private state in the combined checkpoints, the checkpoints contain both framework-independent information that can be interpreted across frameworks and the private state required for precise continuation of the original framework. This supports both precise continuation within the same framework and cross-framework reconstruction and recovery modes. When generating checkpoints, new tool calls are prevented and the status of in-transit tool calls is confirmed. Calls with uncertain status are marked as unknown rather than blindly determined, ensuring that the status recorded by the checkpoint is consistent with the actual execution status and avoiding duplicate or missed executions during recovery due to uncertain status.

[0077] Fifthly, by incrementing the task generation number and freezing old generation task instances, late-running events and tool call requests generated by old instances are rejected due to generation number mismatches, preventing canceled or resumed tasks from interfering with current execution. By utilizing the portable core in the combined checkpoint to rebuild the task context, tasks can continue execution from the most recently valid state instead of rerunning from scratch; by reusing the execution results of successful tool calls through idempotent key matching, completed tool calls are not executed repeatedly during recovery, significantly shortening recovery time. When recovering within the same framework, framework-private state is prioritized for precise continuation; when recovering across frameworks, only the portable core is used for reconstruction. Both modes reuse the results of successful tool calls, achieving rapid recovery after a failure and seamless framework switching.

[0078] Corresponding to the aforementioned embodiment of a task adaptation and resumable execution method for a heterogeneous intelligent agent runtime framework, this application also provides an embodiment of a task adaptation and resumable execution system for a heterogeneous intelligent agent runtime framework.

[0079] Figure 2 This is a schematic diagram of the task adaptation and recoverable execution system of the heterogeneous intelligent agent operation framework provided in Embodiment 2 of this application. Please refer to... Figure 2 The system provided in this embodiment includes a generation module 210, a conversion module 220, a control module 230, and a recovery module 240;

[0080] The generation module 210 is used to receive business task requests and generate a unified task description that is decoupled from the intelligent agent operation framework.

[0081] The conversion module 220 is used to determine the target intelligent agent running framework from multiple heterogeneous intelligent agent running frameworks, and convert the unified task description into a running task that meets the requirements of the target intelligent agent running framework through an intelligent agent runtime adapter;

[0082] The control module 230 is used to inject a task scenario context into the tool call request when the target intelligent agent's running framework executes the running task triggering the tool call request, generate a unified tool call envelope, generate an idempotent key based on the task step characteristics, perform idempotent control on the tool call according to the idempotent key and execute it, and obtain the tool call execution result.

[0083] The generation module 210 is also used to generate a triggering time for the combined checkpoint, extract the portable core and framework private states of the running task in the current execution state, generate a combined checkpoint and store it.

[0084] The recovery module 240 is used to increment the task generation number, freeze the old generation task instance, and perform a recovery operation when the running task fails or the target intelligent agent running framework is switched; wherein, in the recovery operation, the task context is reconstructed using the portable core in the stored combined checkpoints, and the tool call execution result corresponding to the successfully matched idempotent key is reused.

[0085] The system in this embodiment can be used to execute Figure 1 The steps of the method embodiment shown are similar in principle and process, and will not be repeated here.

[0086] The implementation process of the functions and roles of each unit in the above system is detailed in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0087] 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, and 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 modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0088] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for task adaptation and resumable execution of a heterogeneous intelligent agent runtime framework, characterized in that, The method includes: Receive business task requests and generate a unified task description decoupled from the intelligent agent's operating framework; The target intelligent agent runtime framework is determined from multiple heterogeneous intelligent agent runtime frameworks, and the unified task description is converted into a runtime task that meets the requirements of the target intelligent agent runtime framework through an intelligent agent runtime adapter; When the target intelligent agent's operating framework executes the running task and triggers the tool call request, the task scenario context is injected into the tool call request, a unified tool call envelope is generated, and an idempotent key is generated based on the task step characteristics. The tool call is then idempotently controlled and executed according to the idempotent key to obtain the tool call execution result. At the trigger time of the combined checkpoint generation, the portable core and framework private states of the running task in the current execution state are extracted, a combined checkpoint is generated and stored; When the running task fails or the target agent's running framework is switched, the task generation number is incremented, the old generation task instance is frozen, and a recovery operation is performed. In the recovery operation, the task context is reconstructed using the portable core in the stored combined checkpoints, and the tool call execution result corresponding to the successfully matched idempotent key is reused.

2. The method according to claim 1, characterized in that, The step of determining the target agent's operating framework from multiple heterogeneous agent operating frameworks includes: Based on the task requirements in the unified task description, obtain the capability descriptions of the operating frameworks of each heterogeneous intelligent agent. Based on the required capabilities in the capability description, the operation frameworks of each heterogeneous intelligent agent are screened, and those intelligent agent operation frameworks that do not meet the required capabilities are filtered out. Based on the preferred capability satisfaction, estimated resource cost, failure risk, and data locality indicators in the capability description, the remaining intelligent agent operation frameworks after screening are comprehensively scored, and the one with the highest score is determined as the target intelligent agent operation framework.

3. The method according to claim 1, characterized in that, The incrementing task generation number, freezing old generation task instances, includes: When the running task is initialized, the target agent running framework is rebuilt or replaced from the combined checkpoint, the task generation number is incremented, and the state sequence number is generated sequentially within the same generation. Upon receiving a runtime event or tool call request, verify the generation number carried in the runtime event or tool call request; If the generation number is inconsistent with the currently valid task generation number, the corresponding running event or tool call request is determined to belong to an old generation task instance that has been frozen, and the running event or tool call request is refused to be processed.

4. The method according to claim 1, characterized in that, The portable core includes a framework-independent unified task description version, unified state, summary of completed steps, incomplete objectives, evidence references, idempotent keys of completed tool calls, data product references, manual confirmation records, and output draft constraints. The framework-private state stores the node states, session cursors, or internal checkpoint references required for the recovery of the target agent's runtime framework. Specifically, when recovering within the same agent's runtime framework, the framework-private state is preferentially invoked for continuation, and the portable core is used to verify the continuation result. When recovering across agent runtime frameworks, the task context is reconstructed using only the portable core, and the execution results of successful tool calls are reused through idempotent key matching.

5. The method according to claim 1, characterized in that, The combined checkpoint generation triggering timings include: when the running task initialization is completed, before and after a tool call, before and after manual confirmation, when a verifiable sub-goal is completed, when a preset time or step cycle is reached, and before the running task is paused, malfunctions, or the target intelligent agent running framework is switched; wherein, when generating the combined checkpoint, the initiation of new tool calls is first prevented, and the status of in-transit tool calls is confirmed; if there are in-transit tool calls whose status cannot be confirmed in a timely manner, the in-transit tool calls are marked as unknown in the combined checkpoint, and when execution resumes, the status query or compensation check of the in-transit tool calls in the unknown state is first performed.

6. The method according to claim 1, characterized in that, The process of generating idempotent keys based on task step features, and then performing idempotent control and execution of tool calls based on these idempotent keys, includes: Extract the task identifier, logical steps, tool identifier, normalized parameters serialized according to a fixed field order and precision, and input data version, and generate idempotent keys through hash operation; Before executing the tool call, the idempotent call record table is queried. If the idempotent key does not exist, an execution record is created and the tool call is initiated. If the idempotent key exists and the status is successful, a reference to the original tool call execution result is directly returned. If the idempotent key exists and the status is in execution, a waiting flag or a subscription completion event is returned. If the idempotent key exists and the status is retryable failure, a new attempt is initiated when the retry condition is met, and the idempotent key remains unchanged. If the idempotent key exists and the status is unknown, the tool execution end is queried or a compensation check is performed to determine the success or failure status before processing. If the input data version or the normalization parameter changes, a new idempotent key and a new call record are generated.

7. The method according to claim 1, characterized in that, The step of injecting the task scenario context into the tool invocation request and generating a unified tool invocation envelope includes: The business domain, stable scenario, project, sea trial task, and entity scope are extracted from the unified task description as the task scenario context, and the task scenario context is injected into the tool call request to generate a unified tool call envelope; The task scenario context in the unified tool call envelope is compared with the pre-acquired authorization snapshot using an intersection operation for verification; if the task scenario context is detected to be outside the range allowed by the authorization snapshot, the tool call request is rejected.

8. The method according to claim 1, characterized in that, Both the unified task description and the combined checkpoints store the data product identifier, version, spatiotemporal envelope, and content summary, but do not store the binary entity content of the data file. When the target intelligent agent's runtime framework needs to read the data file during the execution of the runtime task, the controlled tool gateway verifies the current authorization and issues a Uniform Resource Identifier carrying a validity period certificate for reading; after the validity period certificate expires, it is reissued as needed, and the identifier that uses the content digest as the same input data remains unchanged in the combined checkpoint and the idempotent key.

9. The method according to claim 1, characterized in that, The method further includes: During the execution of the task, the internal thought text generated by the target agent's operating framework is blocked, and the progress of each stage, tool requests, and warning events during the operation are displayed through a channel independent of the result publishing interface. After the execution of the running task is completed, the agent runtime adapter converts the execution result of the running task into a unified candidate result envelope and submits it to the unified result verification pipeline. The unified result verification pipeline performs spatiotemporal verification, data lineage verification, and quality verification on the unified candidate result envelope. After the unified candidate result envelope passes the verification and approval, the execution result of the running task is published to the target business system.

10. A task adaptation and recoverable execution system for a heterogeneous intelligent agent runtime framework, characterized in that, The system includes a generation module, a conversion module, a control module, and a recovery module; The generation module is used to receive business task requests and generate a unified task description that is decoupled from the intelligent agent operation framework. The conversion module is used to determine the target intelligent agent runtime framework from multiple heterogeneous intelligent agent runtime frameworks, and convert the unified task description into a runtime task that meets the requirements of the target intelligent agent runtime framework through an intelligent agent runtime adapter. The control module is used to inject a task scenario context into the tool call request when the target intelligent agent's running framework executes the running task and triggers the tool call request, generate a unified tool call envelope, generate an idempotent key based on the task step characteristics, perform idempotent control on the tool call according to the idempotent key and execute it, and obtain the tool call execution result. The generation module is also used to generate a triggering time for the combined checkpoint, extract the portable core and framework private states of the running task in the current execution state, generate a combined checkpoint and store it. The recovery module is used to increment the task generation number, freeze the old generation task instance, and perform a recovery operation when the running task fails or the target intelligent agent's running framework is switched; wherein, in the recovery operation, the task context is reconstructed using the portable core in the stored combined checkpoints, and the tool call execution result corresponding to the successfully matched idempotent key is reused.

Images