Agent experience construction, agent running and agent evaluation method

Abstract

Embodiments of the present specification provide an agent experience construction method, an agent running method and an agent evaluation method, wherein the agent experience construction method comprises: acquiring a tool interface definition, a skill module file, a call record and a historical execution trajectory of an agent; uniformly extracting and normalizing the tool interface definition, the skill module file, the call record and the historical execution trajectory to obtain a plurality of initial experiences; determining verifiable experiences from the plurality of initial experiences based on a current determinable state corresponding to a task target and a target determinable state; calling the agent to execute a state transition task between the current determinable state and the target determinable state according to the verifiable experiences, and obtaining target experiences confirmed through verification; and constructing a state experience graph taking the determinable states as nodes and the target experiences as edges. The efficiency, accuracy and reusability of the acquisition of the agent experience are overall improved, and the execution success rate and execution efficiency of the agent in a complex long-range task are improved.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of artificial intelligence technology, and in particular to a method for intelligent agent experience construction, intelligent agent operation, and intelligent agent evaluation. Background Technology

[0002] With the development of large-scale models and intelligent agent technology, intelligent agents are now able to autonomously complete complex multi-step tasks by relying on tool calls and skill modules. In such tasks, the performance of intelligent agents largely depends on whether they possess reusable and transferable experience accumulation capabilities.

[0003] Currently, agent experience is mainly obtained through methods such as manually configuring rule templates, saving and retrieving historical execution trajectories, or using historical data for model fine-tuning.

[0004] However, the above methods are difficult to effectively transform the various types of data generated during the execution of intelligent agents into reusable experience; the correctness and effectiveness of the obtained experience lack reliable judgment, and invalid or even erroneous operation modes are easily solidified and repeatedly referenced; at the same time, the experience is disconnected from the task execution process, making it difficult to continue to be applied when the task objective or intermediate state changes, and the cross-scenario reuse capability is insufficient, and its organizational form cannot support the combined invocation of experience for complex long-term tasks.

[0005] Therefore, there is an urgent need for a method for constructing agent experience to improve the efficiency, accuracy and reusability of agent experience acquisition, thereby increasing the success rate and efficiency of agent execution in complex tasks. Summary of the Invention

[0006] In view of this, embodiments of this specification provide a method for constructing intelligent agent experience. One or more embodiments of this specification also relate to an intelligent agent operation method, an intelligent agent evaluation method, an intelligent agent system, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0007] According to a first aspect of the embodiments of this specification, a method for constructing intelligent agent experience is provided, comprising: Obtain the tool interface definition, skill module files, call records, and historical execution trajectory of the intelligent agent; The tool interface definition, skill module file, call record and historical execution trajectory are uniformly extracted and normalized to obtain multiple initial experiences; Based on the current decisionable state corresponding to the task objective and the decisionable state of the objective, verifiable experience is determined from multiple initial experiences; Invoke the intelligent agent to perform the state transition task between the current decideable state and the target decideable state according to verifiable experience, and obtain the target experience that has been verified and confirmed. A state-experience graph is constructed using determineable states as nodes and target experiences as edges.

[0008] According to a second aspect of the embodiments of this specification, a method for operating an intelligent agent is provided, comprising: Obtain the state experience graph and task objective, and determine the current decisionable state and the decisionable state of the objective. The state experience graph uses decisionable states as nodes and verified objective experience as edges. Candidate paths are obtained by querying candidate experiences from the state experience graph where the starting state is consistent with the current decisionable state and the target state is consistent with the target decisionable state. Execute directional probes on candidate paths to obtain experimental results, and determine the winning path based on the experimental results; Freeze the winning path into a deterministic process and execute the task objective to obtain the execution result; The execution results are evaluated, and the evaluation results and actual test results are written back to the state experience map.

[0009] According to a third aspect of the embodiments of this specification, an agent evaluation method is provided, comprising: Obtain the execution results, task contract, and state experience graph. The state experience graph uses decidable states as nodes and verified target experiences as edges. Based on the execution results and task contract, multiple evaluation dimensions are determined, and each evaluation dimension is converted into a verifiable check item; Verifiable checks are performed using multiple evaluation units, and evaluation sub-results are obtained for each evaluation unit. The evaluation result is determined based on the evaluation sub-results. If there is a discrepancy among the evaluation sub-results, the discrepancy is routed to deterministic verification, evidence probe or manual adjudication according to whether the discrepancy corresponds to an external truth value, so as to obtain the adjudication result of the discrepancy. The verifiable check items corresponding to the evaluation results are frozen into the evaluation process, and the evaluation results are written back to the state experience map.

[0010] According to a fourth aspect of the embodiments of this specification, an intelligent agent system is provided, comprising: The basic capability layer provides common execution primitives, skill module files, and state experience graphs. The agent working layer is used to execute the steps of the aforementioned agent experience construction method, agent operation method, or agent evaluation method. The experience accumulation layer is used to freeze the winning path determined by the agent's working layer into a deterministic process and update the state experience graph.

[0011] According to a fifth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which implement the steps of the above method when executed by the processor.

[0012] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0013] According to a seventh aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0014] In one embodiment of this specification, by uniformly extracting and normalizing tool interface definitions, skill module files, call records, and historical execution trajectories, multi-source heterogeneous data generated during agent execution can be transformed into structurally consistent initial experience, thereby solving the problem of scattered experience sources and difficulty in transformation and reuse. Based on this, the initial experience is judged using the current decidable state corresponding to the task objective and the target decidable state, filtering out verifiable experiences that can effectively facilitate state transitions, avoiding the repeated use of invalid or erroneous operation patterns after they have been solidified. Furthermore, by calling the agent to actually execute state transition tasks between decidable states, the effectiveness of the experience is confirmed through the execution results, resulting in more credible target experience. Finally, a state experience graph is constructed using decidable states as nodes and target experiences as edges, organizing previously isolated experience items into structured data closely related to the task execution process, enabling the agent to combine and migrate experience as needed based on its current state. Therefore, the efficiency, accuracy, and reusability of agent experience acquisition are comprehensively improved, thereby increasing the success rate and efficiency of the agent in complex long-term tasks. Attached Figure Description

[0015] Figure 1 This is a flowchart of an agent experience construction method provided in one embodiment of this specification; Figure 2 This is a schematic diagram of a state experience map in an agent experience construction method provided in one embodiment of this specification; Figure 3 This is a flowchart illustrating an intelligent agent operation method provided in one embodiment of this specification; Figure 4 This is a flowchart of an agent evaluation method provided in one embodiment of this specification; Figure 5This is a schematic diagram of the bidirectional self-evolution of an agent operation method and an agent evaluation method provided in one embodiment of this specification; Figure 6 This is a flowchart illustrating an embodiment of an agent experience construction method, an agent operation method, and an agent evaluation method provided in this specification. Figure 7 This is a schematic diagram of the structure of an intelligent agent system provided in one embodiment of this specification; Figure 8 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0016] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0017] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims 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 in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0018] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, 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, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0019] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0020] Agent Harness: Located between the base model and the specific operation, it provides the agent with a runtime system for context organization, tool invocation, session persistence, task orchestration, runtime observation, and security control. In this specification, the framework provides the agent with general execution primitives, skill module files, and state experience graphs, and supports the agent in performing state transition tasks between the current decideable state and the target decideable state according to verifiable experience.

[0021] State: The state of a work object at a given moment, which can be determined by structural constraints or a state checker, such as "sample batch to be processed", "transcription with speaker timestamp has been formed", "order-level determination has been formed"; In this specification, states constitute nodes of the state experience graph in the form of decidable states.

[0022] Experience: A directed transition relationship connecting the source state and the target state, which at least describes how the target state is obtained from the source state, and may further carry tool / model recipes, preconditions, measured costs, failure modes, confidence levels, verification probes and sources of evidence; In this specification, verified experience constitutes the edges of the state experience graph in the form of target experience.

[0023] State-Experience Graph: A persistent cognitive structure with decidable states as nodes and verified target experiences as edges. This graph records the decidable states of the work object and what experiences can be used to transition from one decidable state to another, rather than simply recording a tool list or free text memory.

[0024] State Verifier: A deterministic check procedure, pattern constraint, or replayable verification step used to determine whether a work object satisfies a certain state form definition; in this specification, it is used to determine the current decisionable state and the target decisionable state corresponding to the task objective.

[0025] Directed Probe: When the candidate path is uncertain, a low-cost verification is performed on a subset of samples determined from the real data corresponding to the candidate path to obtain experimental results, and based on these results, the winning path is determined and the confidence of the candidate experience is updated, rather than directly running the complete process.

[0026] Search-then-Freeze: During the design phase, agents are allowed to determine the implementation path through candidate generation, pruning, directed probes, and backtracking exploration. After selecting the winning path, it is compiled or solidified into a deterministic process that no longer contains open agent decisions and executes the task objective.

[0027] Run design loop: A loop that designs, verifies, and selects candidate state transition paths with the goal of producing a run result that meets the task objectives. In this specification, it is manifested as the process of querying candidate experiences from the state experience map and combining them into candidate paths, executing directional probes on the candidate paths to determine the winning path, and then freezing the winning path into a deterministic process.

[0028] Evaluation Design Cycle: With the goal of determining whether the results of the operation have truly improved the situation, this cycle designs verifiable check items, evaluation units, disagreement handling strategies, and freezes the scoring process. In this specification, it is manifested as converting each evaluation dimension into verifiable check items, executing the verifiable check items using multiple evaluation units to obtain each evaluation sub-result, routing the disagreements when there are disagreements in the evaluation sub-results and obtaining the adjudication results, and then freezing the verifiable check items corresponding to the evaluation results into the evaluation process.

[0029] Heterogeneous evaluation unit: An evaluation unit that differs from the running generative model or other evaluation units in model family, training objective, input modality, or implementation mechanism, and is used to reduce the shared blind spots among multiple evaluation units; in this specification, it is one of multiple evaluation units, which performs verifiable checks and provides corresponding evaluation sub-results.

[0030] Divergence routing: When there are discrepancies in the evaluation sub-results given by multiple evaluation units, instead of eliminating the discrepancy through voting or averaging, the discrepancy is routed to deterministic verification, evidence probe, manual adjudication, or left as a disputed state based on whether the discrepancy corresponds to an external truth value.

[0031] Graph projection block: A compact view generated based on the current content of the state experience graph and the position of the current request in the session. It is attached to the current request and only added to the current model request. When the state experience graph is updated, the graph projection block corresponding to the next request is regenerated to ensure that the agent continuously sees the latest graph without accumulating old copies.

[0032] Collaborative self-evolution: Discoveries made on the operation side prompt the evaluation side to fill in blind spots, and discoveries made on the evaluation side in turn drive the improvement of the operation path. The operation side and the evaluation side jointly read and write the state experience map, and write the measured results, execution results and evaluation results back to the map, so that subsequent operations can reuse verified experience and reduce repeated exploration.

[0033] Message: Input provided to the agent in the runtime framework, where system prompts indicate system-level prompts and typically store system-level requests, and user prompts indicate user-level prompts and store the current user message; in this specification, the map projection block is attached to the current request, which is carried by the user prompt.

[0034] Large-scale intelligent agents are already capable of encoding, data processing, and multimodal understanding through tools, skill module files, memory, historical execution trajectories, and workflows. These mechanisms can respectively describe individual capabilities, save procedural schemes, maintain session facts, or reproduce specific processes; however, in complex, long-cycle, and cross-task applications, the following technical issues still require further resolution.

[0035] First, there is a lack of explicit combination relationships between skill module files. Skill module files typically store a set of processes and precautions as independent entries for specific tasks or scenarios, which can accumulate specific procedural experience. However, there is usually a lack of explicit state connections, applicable conditions, and combination rules between different skill module files. When a new task only needs to reuse some capabilities from the existing solution, or when the current decideable state, the target decideable state, and the applicable conditions change, the agent still needs to search and re-evaluate the applicability of skill module files item by item. It is difficult to directly combine candidate paths from the current decideable state to the target decideable state with experimental results and evidence.

[0036] Secondly, experience carriers are scattered and their expression structures are inconsistent. Tool interface definitions can describe individual capabilities, skill module files can save complete solutions, and memory and historical execution trajectories can record facts and processes. However, these carriers usually adopt different granularities and structures, making it difficult to uniformly express identifiable input states, output states, applicable conditions, execution costs, failure modes, confidence levels, verification probes, and evidence sources. Therefore, it is impossible to complete the comparison, combination, and reuse of experience in the same structure.

[0037] Third, there is a lack of a co-evolution mechanism between operation and evaluation. In practice, evaluation criteria can be established first, and then operational processes can be improved based on the evaluation results. However, new failure types, boundary samples, and discrepancies exposed during operation may not be promptly transformed into reusable, verifiable checklists or confirmed experiences for the evaluation side. Furthermore, problems identified during evaluation may not be appropriately used to guide subsequent operational design, and discrepancies lack a mechanism for routing based on the existence of external truth values. Therefore, it is difficult for the operation and evaluation sides to accumulate and evolve together during operation.

[0038] From existing implementations, the causes of the above problems vary. Existing fixed workflow or control flow graph solutions can predefine nodes, edges, roles, or handover relationships as execution graphs and support state persistence and recovery. However, the nodes of such execution graphs are usually functions, agents, or execution steps, and the edges represent pre-configured control flows. Their focus is on "who to execute next," not on "what decidable state the work object is currently in." An edge usually does not simultaneously carry execution cost, failure mode, confidence level, verification probe, and evidence source. While its state persistence solves the recovery problem, it does not equate to forming confirmed experience that can be reused across tasks. Existing execution trajectory, experiment, and evaluation platform solutions can collect execution trajectories, build datasets, and run evaluation units to compare different experiments. However, their evaluation units are mainly used to output scores for existing applications or models. The scores usually do not automatically translate into state transition experience from the current decidable state to the target decidable state that the execution design can follow. There is a lack of shared, executable capability cognitive structure between the execution design and the evaluation design. The disagreements generated by multiple evaluation units are not further routed into new evidence probes, new checks, or disputed states. Existing general-purpose intelligent agent operation frameworks offer model loops, tool calls, context and sessions, and extension capabilities. Tool interface definitions, sessions, memories, or skill module files can store capabilities, facts, and procedural schemes. However, they do not register this content as experience edges with initial states, target states, and verification attributes. Furthermore, they do not define "freezing into a deterministic process after probe selection" and "joint writing back the graph by the operation and evaluation sides" as formal steps within the same data loop. Evaluation often manifests as post-hoc analysis of safety barriers and operational trajectories, or external assessments, rather than a design loop that involves equal rights with the operation side and joint reading and writing of the graph. Existing free-text long-term memory or skill library schemes can store user preferences, historical conclusions, or operational procedures. However, free text makes it difficult to calculate paths and dominance relationships, and it is not easy to determine whether two descriptions point to the same decidable state. Facts, inferences, and assumptions in memory are easily mixed, and there is a lack of confidence and replayable verification probes, which may lead to corruption after long-term use.

[0039] The common problem with the above solutions is that they do not simultaneously provide the following combined mechanisms: constructing a state experience graph with decidable states as nodes and verified target experiences as edges; jointly querying and updating the graph by the operation and evaluation sides; exploring candidate paths and verifying them with directional probes during the design phase; freezing the winning path as a deterministic process during the execution phase; and triggering the formation of new evidence probes and new inspection items by evaluation disagreements.

[0040] Therefore, a persistent cognitive layer of capabilities is needed above tool interface definitions, skill module files, and memory to uniformly express schemes, operational results, and evaluation evidence from different sources as verifiable state transition experiences, construct a state experience graph, and have the operational and evaluation sides jointly query and update this graph, thereby forming a collaborative self-evolutionary mechanism for agent operation and evaluation.

[0041] In view of this, this specification provides a method for constructing agent experience. By obtaining the agent's tool interface definition, skill module file, call records, and historical execution trajectory, and performing unified extraction and normalization, multiple initial experiences are obtained. Based on the current decisionable state and the target decisionable state corresponding to the task objective, verifiable experiences are determined from the multiple initial experiences. The agent is invoked to execute the state transition task between the current decisionable state and the target decisionable state according to the verifiable experiences, and the verified target experience is obtained. Then, a state experience graph is constructed with decisionable states as nodes and target experiences as edges, providing a unified and persistent cognitive foundation for subsequent experience query reuse, candidate path search and freezing, evaluation closure, and collaborative self-evolution.

[0042] This specification also relates to an agent operation method, an agent evaluation method, an agent system, a computing device, a computer-readable storage medium, and a computer program product, which are described in detail in the following embodiments.

[0043] See Figure 1 , Figure 1 A flowchart illustrating an agent experience construction method according to an embodiment of this specification is shown, including: Step 102: Obtain the agent's tool interface definition, skill module file, call records, and historical execution trajectory.

[0044] An agent is an execution entity that uses a basic model as its decision-making core and invokes tools and loads skill module files to perform task objectives within the runtime environment provided by the agent's runtime framework. During task execution, the agent continuously generates invocation records and historical execution trajectories; therefore, the associated tool interface definitions, skill module files, invocation records, and historical execution trajectories collectively constitute raw material from which experience can be extracted. In some optional embodiments, the agent is a single agent. In other optional embodiments, the agent is a multi-agent system consisting of an orchestration agent and one or more sub-agents. For example, in vehicle recording and judgment tasks, the agent is an orchestration agent running within the agent runtime framework, with a large model as its decision-making core.

[0045] Tool interfaces are defined as interface descriptions of the input parameters, output structures, and invocation constraints of tools available to an agent. They correspond to general execution primitives that can be directly invoked by the agent, and are used to characterize the scope and invocation method of a single capability. For example, general execution primitives include basic execution primitives such as command execution, file reading, file writing, and file editing, as well as model primitives such as multimodal understanding and language model invocation. Each primitive has a corresponding interface definition.

[0046] Skill module files are documented formats used to store procedural solutions. They record a complete execution process and precautions in the form of items for specific tasks or scenarios, providing a referable operational paradigm for intelligent agents. For example, a module file might record procedural solutions such as speech-to-text and speaker separation processes, and violation judgment category mapping rules.

[0047] Call logs are discrete records generated by an agent calling tools or models during operation, reflecting the actual occurrence and results of each call. For example, the call log of a speech-to-text service records the call time, input audio, output text, time consumed, and return status.

[0048] Historical execution trajectories are multi-round sequences organized chronologically during the execution of past tasks by an intelligent agent, reflecting the complete process of a task from initiation to completion. For example, the execution trajectory of a past vehicle recording judgment task includes the task objective, model thinking, tool invocation, and return results.

[0049] For example, taking the task of judging responsibility for in-vehicle recording as an example, the interface definition of the general execution primitives available to the agent under this task, the skill module file that records the procedural schemes related to the judgment, the call records generated by the agent in calling the speech transcription and judgment model in previous operations, and the historical execution trajectory generated by the agent in previous judgment tasks are obtained as the raw materials for subsequent unified extraction and normalization.

[0050] Step 104: Extract and normalize the tool interface definition, skill module file, call record and historical execution trajectory to obtain multiple initial experiences.

[0051] Initial experience refers to experience entries obtained by uniformly extracting and normalizing the above four types of data sources, which have not yet been verified by a definite state. Their confidence level is assumed to be the hypothesis level. They at least record the input and output states corresponding to the experience, that is, the state of the working object before and after the experience is implemented. They can further record the applicable conditions, execution costs, and failure modes of the experience, so that materials from different sources and with different structures can be expressed as candidate experiences with a consistent structure. For example, an initial experience obtained by normalizing the interface definition and corresponding call records of a speech transcription tool has an input state of "batch of in-vehicle recordings to be processed" and an output state of "transcription with speaker timestamps has been formed".

[0052] The tool interface definition, skill module file, call records, and historical execution trajectory are uniformly extracted and normalized to obtain multiple initial experiences. One possible approach is to extract the values ​​of corresponding fields from the tool interface definition, skill module file, call records, and historical execution trajectory according to a preset field mapping relationship, and then map the extracted values ​​to a unified experience field to obtain multiple initial experiences. Another possible approach is to input the tool interface definition, skill module file, call records, and historical execution trajectory into a pre-trained extraction model to obtain multiple initial experiences output by the model that conform to a unified experience field structure. Yet another possible approach is to use a parsing method corresponding to the data form of the tool interface definition, skill module file, call records, and historical execution trajectory to obtain their respective intermediate representations, then convert these intermediate representations into a unified experience structure and merge semantically similar field values ​​to obtain multiple initial experiences. No specific limitations are imposed here.

[0053] For example, the interface definition of a speech-to-text tool is parsed to obtain that its input is audio data and its output is text with speaker and timestamp, thereby determining the input and output states of an initial experience. The skill module file recording the accountability process is parsed to obtain the applicable conditions and precautions for this process. The call records and past accountability execution trajectories of the speech-to-text service are parsed to obtain the actual execution time of the process and the failure scenarios that have occurred. The above parsing results are mapped to a unified experience field to obtain multiple initial experiences corresponding to speech-to-text, speaker separation, and violation determination stages.

[0054] In one optional embodiment, parsing and extracting input states, output states, applicable conditions, execution costs, failure modes, and verification results is only one example. Unified extraction and normalization can also register only tool interface definitions, skill module files, call records, and historical execution trajectories as initial experience, retaining their original carriers as evidence sources, while other experiences are generated from candidate path exploration during the design phase and the write-back results of verified state transitions. The confidence level of the extracted initial experience is assumed to be at the hypothesis level, and it must be verified by the measured results collected by the directional probe and the write-back process before it can be upgraded to the verified level of experience.

[0055] Step 106: Based on the current decisionable state corresponding to the task objective and the decisionable state of the objective, determine verifiable experience from multiple initial experiences.

[0056] The task objective is the goal that the intelligent agent aims to achieve during its current operation, characterized by changes in the form of the work object. It specifies the form the work object should be transformed into. For example, determining violations based on the type, time range, speaker, and evidence text obtained from vehicle-mounted recordings.

[0057] The current decidable state corresponding to the task objective is the decidable state of the work object before the state transition, and it constitutes the starting endpoint of the state transition. The current decidable state describes the actual form of the work object rather than the steps to be executed, and its validity can be determined. For example, if the work object has already formed a transcription with the speaker's timestamp, then the current decidable state is "a transcription with the speaker's timestamp has been formed".

[0058] The target determineable state corresponding to a task objective is the determineable state that the work object is expected to reach after the state transition, and it constitutes the target endpoint of the state transition. For example, if the task objective requires the formation of an order-level violation determination, then the target determineable state is "order-level determination has been formed".

[0059] Verifiable experience is experience determined from multiple initial experiences based on the current decideable state and the target decideable state. Its state change endpoints correspond to the current decideable state and the target decideable state, thus possessing endpoint conditions that can be actually executed and verified, and can serve as the basis for invoking the agent to execute state transition tasks. For example, initial experience with the input state "transcription with speaker timestamp has been formed" and the output state "order-level decision has been formed" is determined to be verifiable experience when the current decideable state and the target decideable state are the aforementioned two states, respectively.

[0060] Based on the current decideable state and the target decideable state corresponding to the task objective, verifiable experiences are determined from multiple initial experiences. One possible approach is to identify initial experiences whose input state matches the current decideable state and whose output state matches the target decideable state as verifiable experiences. Another possible approach is to identify initial experiences whose input state is a generalization of the current decideable state and whose output state is the target decideable state or its generalization, when no initial experiences with completely identical endpoints exist, as verifiable experiences. Yet another possible approach is to determine the degree of matching between the state corresponding to each initial experience and the current decideable state and the target decideable state, and to select initial experiences whose matching degree meets preset conditions as candidate experiences. After verifying the endpoint states of these candidate experiences, they are then identified as verifiable experiences. No further limitations are specified here.

[0061] For example, the task objective is to obtain order-level violation determination from vehicle recordings. Its current determineable state is "transcription with speaker timestamp has been formed," and the target determineable state is "order-level determination has been formed." Multiple initial experiences are matched with these two states. Initial experiences whose input and output states correspond to the current and target determineable states, respectively, are identified as verifiable experiences. However, initial experiences with an input state of "vehicle recording batch to be processed" and an output state of "transcription with speaker timestamp has been formed" are not identified as verifiable experiences in this instance because their endpoint states do not correspond to the current state transition.

[0062] Step 108: Invoke the intelligent agent to perform the state transition task between the current decideable state and the target decideable state according to verifiable experience, and obtain the target experience that has been verified.

[0063] A state transition task is a morphological transformation task performed on a work object between a current decideable state and a target decideable state, in a manner described by verifiable experience. Its purpose is to actually transform the work object from the current decideable state to the target decideable state. For example, based on verifiable experience of obtaining a decision through transcription, a task might be performed to convert a transcription containing a speaker's timestamp into an order-level violation determination.

[0064] Verified and confirmed target experience refers to verifiable experience that has been actually executed by the agent, and the state transition has been verified by the execution result. It is different from initial experience and verifiable experience that have not yet been executed and verified, and can be directly used as an edge in the state experience graph. For example, experience obtained after the agent actually executes the state transition determined by the transcription and makes the work object reach the "order-level judgment has been formed" state, and the execution result confirms the validity of the transition.

[0065] The process involves invoking an agent to perform a state transition task between the current decideable state and the target decideable state based on verifiable experience, thereby obtaining the verified target experience. One possible approach is to invoking the agent to perform the state transition task once based on verifiable experience, and confirming the verifiable experience as the target experience if the execution result indicates that the work object has reached the target decideable state. Another possible approach is to invoking the agent to perform the state transition task on multiple work objects separately based on verifiable experience, and confirming the verifiable experience as the target experience if the execution result indicates that the proportion of work objects reaching the target decideable state reaches a preset proportion. Yet another possible approach is to invoking the agent to perform the state transition task based on verifiable experience, and comparing the execution result of this execution with the execution results obtained based on other verifiable experiences; if the comparison result indicates that the execution result corresponding to this verifiable experience is superior, then confirming this verifiable experience as the target experience. No further limitations are imposed on this approach.

[0066] For example, the calling agent executes a state transition task from "transcription with speaker timestamp formed" to "order-level judgment formed" according to the calling method recorded by the verifiable experience: the transcribed text is input into the judgment model, the judgment model outputs severity, object, and source tags, and then the code deterministically maps it to the corresponding violation category, obtaining a judgment result with category, time interval, speaker, and evidence text. If the execution result indicates that the working object has reached the "order-level judgment formed" state, and the state transition is verified by the execution result, the verifiable experience is confirmed as the target experience that has been verified.

[0067] Step 110: Construct a state-experience graph with the determineable states as nodes and the target experience as edges.

[0068] A node in a state experience graph exists in the form of a decidable state. It represents the data or task state that the work object is in at a certain moment, which can be determined, rather than the running steps to be executed. Each node corresponds to a decidable state. For example, "pending processing of vehicle recording batches", "transcription with speaker timestamps has been formed", and "order-level determination has been formed" each constitute a node in the state experience graph.

[0069] An edge is a directed edge in the state experience graph that exists in the form of a target experience. It points from the starting state to the target state, representing that the method described by the target experience can transition from one decidable state to another, and records that the transition has been verified and confirmed. For example, the target experience from "a transcription with speaker timestamp has been formed" to "an order-level decision has been formed" constitutes a directed edge in the state experience graph connecting the two nodes.

[0070] A state-experience graph is a persistent cognitive structure with decideable states as nodes and target experiences as edges. It records the decideable states of the work object and which experiences can be used to transition from one decideable state to another. This allows experiences to be queried, combined, and reused according to state relationships, rather than simply recording a tool list or free text memory. For example, a state-experience graph for in-vehicle recording judgment tasks can be constructed from the above three nodes and the target experiences connecting them.

[0071] Using decidable states as nodes and target experiences as edges, a state-experience graph is constructed. One possible approach is to store each decidable state as a state entry and each target experience as an experience entry, using the identifier of the state entry as the value of the starting state and target state in the experience entry to establish a relationship between the experience entries and the state entries, thus obtaining the state-experience graph. Another possible approach is to store the decidable states and target experiences as records in a data table, using the state identifier as a foreign key to establish a relationship between the target experience record and the decidable state record, thus obtaining the state-experience graph. Yet another possible approach is to use the decidable states as nodes in the graph structure, and the target experiences as directed edges from the starting state to the target state in the graph structure, writing them into the graph structure, and using the query and traversal results of this graph structure as the state-experience graph. No further limitations are imposed here.

[0072] For example, "pending vehicle recording batch," "transcribed with speaker timestamp," and "order-level judgment" are stored as decisionable states as nodes. Experiences confirmed as target experiences—obtained from "pending vehicle recording batch" as "transcribed with speaker timestamp" and from "transcribed with speaker timestamp" as "order-level judgment"—are represented as directed edges from their respective starting states to their target states. The nodes and edges corresponding to multiple target experiences are linked and integrated using the correspondence between the endpoint states of the edges and the nodes, constructing a state experience graph for vehicle recording judgment tasks. In this graph, each node represents the decisionable state of the work object, and each directed edge represents a verified experience that can transition from one state to another. Therefore, subsequent operations can query and combine the corresponding state transition methods from this graph based on the decisionable state of the work object.

[0073] In this embodiment, by uniformly extracting and normalizing tool interface definitions, skill module files, call records, and historical execution trajectories, multi-source heterogeneous data generated during agent execution can be transformed into structurally consistent initial experience, thus solving the problem of scattered experience sources and difficulty in transformation and reuse. Based on this, the initial experience is judged using the current decidable state corresponding to the task objective and the target decidable state, filtering out verifiable experiences that can effectively facilitate state transitions, avoiding the repeated use of invalid or erroneous operation patterns after they have been solidified. Furthermore, by calling the agent to actually execute state transition tasks between decidable states, the effectiveness of the experience is confirmed through the execution results, resulting in more credible target experience. Finally, a state experience graph is constructed using decidable states as nodes and target experiences as edges, organizing previously isolated experience items into structured data closely related to the task execution process, enabling the agent to combine and transfer experience as needed based on its current state. Therefore, the efficiency, accuracy, and reusability of agent experience acquisition are comprehensively improved, thereby increasing the success rate and efficiency of the agent in complex long-term tasks.

[0074] Optionally, the current decisionable state and the target decisionable state are obtained by the state checker judging the working object of the agent. The state checker is used to determine whether the working object satisfies the state form definition. Initial experience includes input state, output state, applicable conditions, execution cost, and failure mode. The confidence level of initial experience is the hypothesis level. Verifiable experience includes initial state, target state, applicable conditions, tools or skills used, verification probes, test results, confidence level, and source of evidence. The confidence level of verifiable experience includes hypothesis level, provisional level, verified level, and rejected level.

[0075] A state checker is a deterministic checking procedure, pattern constraint, or replayable verification step used to determine whether an agent's work object satisfies a state morphology definition. It takes the current actual state of the work object as input and outputs a determination result, thus allowing the machine to determine whether a state is valid, without relying on semantic comparison of text tags. For example, a script to check whether each sentence in the transcription product contains a speaker identifier and start and end timestamps, or a verification procedure to check whether the values ​​of each category in the determination result belong to a predetermined category vocabulary.

[0076] The working objects of an intelligent agent are the data or task entities that the agent processes during the execution of its task objectives, and whose forms change with state transitions. They present different forms at different times, and thus can be determined by a state checker to be in different decisionable states. For example, in a vehicle recording judgment task, there are batches of vehicle recordings to be judged, as well as the transcribed text and judgment results obtained from these recording batches at each stage.

[0077] A state form is defined as a description of the deterministic constraints that a certain decidable state should satisfy in terms of data structure, field values, or task completion. It constitutes the basis for the state checker to determine whether a work object is in that decidable state. For example, in one optional approach, the state form corresponding to the decidable state "order-level determination has been formed" is defined as follows: each determination record contains four fields: category, time interval, speaker, and evidence text, and the category value belongs to a predetermined category thesaurus.

[0078] The state checker determines the working objects of the intelligent agent. One possible approach is to validate the field structure and values ​​of the working objects using predefined structural or pattern constraints, and determine that the working objects satisfy the state form definition if the validation passes. Another possible approach is to perform checks on the working objects using pre-defined deterministic checks or replayable verification steps, and determine whether the working objects satisfy the state form definition based on the check results. Yet another possible approach is to use a rule engine, statistical thresholds, or model-assisted checks to determine the working objects, and when using model-assisted checks, to attach corresponding evidence and confidence levels to the determination results. No further limitations are specified here.

[0079] The input state is the state of the work object recorded in the initial experience before the initial experience was implemented. It is used to characterize the initial form to which the experience applies and serves as the basis for matching with the current determinate state. For example, the initial experience obtained by normalizing the interface definition of the speech transcription tool has the input state "batch of in-vehicle recordings to be processed".

[0080] The output state is the state of the work object after the initial experience is implemented, as recorded in the initial experience. It is used to characterize the form that the experience can achieve and serves as the basis for matching with the target's decidable state. For example, the output state of the above initial experience is "A transcription with speaker timestamps has been formed".

[0081] The applicable conditions are the pre-existing constraints upon which the experience can be established and implemented. They are used to characterize the work objects and task situations in which the experience is applicable and serve as the basis for screening the experience. For example, in one alternative approach, the initial experience obtained from parsing the skill module file is applicable if the sampling rate and duration of the audio to be processed are within the corresponding range and the number of speakers in the audio does not exceed a preset number.

[0082] Execution cost refers to the actual resource or time overhead incurred when the experience is implemented. It is obtained from measured data in the call log or historical execution trajectory and is used to characterize the actual cost of the experience. For example, in one alternative approach, the execution cost of the initial experience mentioned above is the average transcription time per audio file and the corresponding number of model calls.

[0083] Failure modes are the observed failure scenarios and their triggering conditions during the implementation of an experience. They are obtained from the precautions recorded in the skill module file or the failure records in the historical execution trajectory, and are used to characterize under what circumstances the experience is unusable. For example, in one alternative approach, the failure modes of the aforementioned initial experience are "long segment transcription truncation" and "unstable speaker source," triggered by the audio duration exceeding a preset duration and the presence of background playback sound in the audio, respectively.

[0084] The initial state is the decidable state recorded in verifiable experience from which the state transition begins. It corresponds to the current decidable state corresponding to the task objective and constitutes the starting endpoint of this state transition. For example, the initial state of the verifiable experience is "a transcription with speaker timestamps has been formed".

[0085] The target state is a decidable state recorded in verifiable experience that is expected to be reached during the state transition. It corresponds to the target decidable state corresponding to the task objective and constitutes the target endpoint of this state transition. For example, the target state of verifiable experience is "order-level decision has been formed".

[0086] The applicable conditions are the preconditions recorded in the verifiable experience, determined after verification of the initial and target states, which are the prerequisites for the application of the verifiable experience in this state transition. These conditions are further aligned with the current task objective than the applicable conditions in the initial experience. For example, in one alternative approach, the applicable conditions of the verifiable experience are that the transcription product covers the entire audio segment and the speakers are distinguishable from each other.

[0087] The invoked tools or skills are specific tool or skill modules recorded in verifiable experience that are required to complete the state transition, and they are the direct basis for invoking the agent to perform the state transition task. Here, a skill is a procedural scheme stored in a skill module file. For example, in one alternative approach, the invoked tools or skills recorded in the verifiable experience might involve invoking the severity, object, and source tags output by the decision model, and then invoking a category mapping program to deterministically map this output to the corresponding violation category.

[0088] A verification probe is a replayable verification step recorded in verifiable experience to check whether a state transition is valid. It can be executed on a small amount of real data to obtain experimental results reflecting the feasibility of the experience, without having to run the entire process. For example, in one alternative approach, the verification probe recorded in the verifiable experience is to capture a narrow audio window corresponding to the judgment instance and re-determine its source.

[0089] The measured results are the actual data collected after executing the verification probe. They reflect the actual effect achieved by the state transition and are the direct basis for determining whether the verifiable experience can be confirmed as the target experience. These measured results can come from previous verification results recorded in the historical execution trajectory, or they can be supplemented and updated after executing the verification probe. For example, the source determination accuracy and category consistency rate collected after executing the above verification probe on several sampled instances.

[0090] Confidence level is a graded value recorded in verifiable experience, representing the degree to which the experience can be accepted. It is updated accordingly as experimental results change, and is used to distinguish between directly reusable experiences and those requiring further verification within the same graph. Confidence levels include hypothesis level, provisional level, verified level, and rejected level: hypothesis level indicates that the experience is a candidate experience that has not been verified by directed probes; provisional level indicates that the experience has received preliminary evidence but still needs to accumulate independent evidence; verified level indicates that the experience has been verified by verification probes or state transition tasks; rejected level indicates that the experience has been falsified by experimental results. The upgrade from hypothesis level or provisional level to verified level is based on experimental results collected by probes capable of distinguishing competing hypotheses. For example, if the experience has been verified in multiple previous runs, its confidence level is recorded as verified.

[0091] Confidence levels can be represented in several ways: one option is to use discrete ranks; another option is to use numerical values, probability values, or counts based on the number of successes and failures; yet another option is to use a rating system with time decay. No specific method is specified here.

[0092] The source of evidence is traceable information recorded in verifiable experience that is used to trace the source of the experience. It associates the experience with the operational process, time, and sample on which it was based, making the experience reproducible and auditable. For example, in one alternative approach, the source of evidence is the operational identifier that generated the experience, the corresponding timestamp, and the sample recording number on which it was based.

[0093] For example, the agent's work objects are the batches of in-vehicle recordings to be judged, the transcribed text obtained from them, and the judgment results. A state form definition is set for "transcription with speaker timestamps has been formed": each statement has a speaker identifier and start and end timestamps, and the statement set covers the entire audio time period; a state form definition is set for "order-level judgment has been formed": each judgment record contains a category, time interval, speaker, and evidence text, and the category value belongs to a predetermined eleven-category vocabulary. The state checker verifies the work objects according to the above state form definitions. If the transcribed file meets the previous state form definition, the current judgeable state of the work object is determined to be "transcription with speaker timestamps has been formed," i.e., the current judgeable state; while the task objective requires outputting order-level violation judgments, the objective judgeable state is "order-level judgment has been formed."

[0094] Based on this, the initial experience obtained by normalizing the interface definition of the speech transcription tool, the skill module file recording the accountability process, the call records of the speech transcription service, and the previous accountability operation trajectory has the following input status: "batch of in-vehicle recordings to be processed", output status: "transcription with speaker timestamps has been formed", applicable conditions: the sampling rate and duration of the audio to be processed are within the corresponding range, execution cost is the average transcription time of a single audio and the corresponding number of model calls, and failure modes are "truncation of long segment transcription" and "unstable speaker source". Another initial experience obtained by normalizing the initial experience corresponding to the judgment stage has the following input status: "transcription with speaker timestamps has been formed", output status: "order-level judgment has been formed", applicable conditions: the transcription product covers all audio time periods and the speakers can be distinguished from each other, execution cost is the average time of a single judgment call, and failure modes are "inconsistent category names" and "differences in labeling".

[0095] Based on the current verifiable state "transcription with speaker timestamp has been formed" and the target verifiable state "order-level judgment has been formed", the latter initial experience is determined as verifiable experience. Its starting state is "transcription with speaker timestamp has been formed", the target state is "order-level judgment has been formed", the applicable conditions are that the transcription product covers the entire audio time period and the speakers can be distinguished from each other, the tools or skills called are to call the judgment model to output the severity, mark the object and source and call the category mapping program to deterministically map to the corresponding violation category, the verification probe is to capture the narrow audio window corresponding to the judgment instance and re-determine its source, the measured results are the category consistency rate and source judgment accuracy collected on the sampled instance, the confidence level is the corresponding level determined based on previous verification, and the evidence source is the operation identifier, timestamp and sample recording number on which the experience is based.

[0096] In the embodiments of this specification, the current determineable state and the target determineable state are determined by the state checker based on the state form definition of the work object, rather than relying on the semantic comparison of text labels. Therefore, the validity of the state can be determined by the machine, avoiding the problem that the same form is expressed as different text labels and cannot be matched with each other. The initial experience is expressed with a unified field structure of input state, output state, applicable conditions, execution cost and failure mode, so that heterogeneous content from tool interface definition, skill module file, call record and historical execution trajectory can be compared and filtered in the same structure. Verifiable experience further carries the starting state, target state, applicable conditions, called tool or skill, verification probe, test results, confidence level and evidence source, so that the selected experience not only has a clear endpoint state, but also has replayable verification means and traceable evidence source, thereby avoiding invalid or erroneous operation modes being directly solidified and repeatedly referenced without judgment, providing a determineable, reproducible and auditable experience foundation for subsequent execution of state transition tasks and construction of state experience map.

[0097] Optionally, step 104 includes: The parsing tool interface is defined to extract the input and output states. Analyze the skill module file to extract applicable conditions and failure modes; Analyze call records and historical execution paths to extract execution costs and verification results; Based on the input state, output state, applicable conditions, failure mode, execution cost, and verification results, multiple initial experiences are constructed.

[0098] The parsing of the tool interface definition extracts the input and output states. One possible approach is to determine the working object form corresponding to the input parameters as the input state and the working object form corresponding to the output structure as the output state, based on the input parameters and output structure declared in the tool interface definition. Another possible approach is to input the tool interface definition into a pre-trained semantic parsing model to obtain the input and output states output by the semantic parsing model that correspond to the tool interface definition. Yet another possible approach is to query a pre-defined type-state mapping relationship based on the tool type to which the tool interface definition belongs, and use the queried input and output states as the parsing results. No further limitations are specified here.

[0099] Parsing skill module files to extract applicable conditions and failure modes can be done in several ways. One option is to perform text parsing on the skill module file, extracting the preconditions for implementation from the execution flow description as applicable conditions, and extracting the precautions or exception handling descriptions as failure modes. Another option is to input the skill module file into a pre-trained semantic parsing model to obtain the applicable conditions and failure modes corresponding to the skill module file, output by the model. Yet another option is to query a pre-defined scheme and condition mapping table based on the skill module file's identifier, and use the retrieved applicable conditions and failure modes as the parsing results. No further limitations are specified here.

[0100] The process involves parsing call records and historical execution trajectories to extract execution costs and verification results. One possible approach is to statistically analyze the time consumption and resource usage of each call recorded in the call records to obtain the execution cost, and then extract the conclusions obtained from verifying intermediate products or final results from the historical execution trajectories as the verification results. Another possible approach is to input the call records and historical execution trajectories into a pre-trained semantic parsing model to obtain the execution costs and verification results output by the semantic parsing model corresponding to the calls and trajectories. Yet another possible approach is to query a pre-defined task test information table based on the task identifier to which the call records and historical execution trajectories belong, and use the retrieved execution costs and verification results as the parsing results. No further limitations are specified here.

[0101] For example, the interface definition of the speech-to-text tool is parsed to obtain that its input is in-vehicle recording audio data and its output is text with speaker identifiers and start and end timestamps. Thus, the input status is extracted as "in-vehicle recording batch to be processed" and the output status is "transcription with speaker timestamps has been formed". The skill module file that records the accountability process is parsed to extract the applicable conditions of the process as the sampling rate and duration of the audio to be processed being within the corresponding range and the number of speakers in the audio not exceeding the preset number. The failure modes are extracted as "long segment transcription truncation" and "unstable speaker source". The call records of the speech-to-text service are statistically analyzed to obtain the average transcription time and corresponding model call volume of a single audio as the execution cost. The verification results obtained by verifying the transcription results are extracted from the previous accountability operation trajectory, such as the consistency verification conclusion of whether the transcribed text covers the entire audio segment in the long audio scenario. The extracted input states, output states, applicable conditions, failure modes, execution costs, and verification results are mapped to a unified experience field and associated with an initial experience corresponding to the speech-to-text stage. This initial experience at least records its input state, output state, applicable conditions, execution cost, and failure mode, and can further record its verification results. Similarly, the tool interface definition, skill module file, call records, and historical execution trajectory corresponding to the judgment stage are parsed and extracted to obtain another initial experience. Its input state is "transcription with speaker timestamp has been formed," its output state is "order-level judgment has been formed," its applicable conditions are that the transcription product covers all audio time periods and the speakers can be distinguished from each other, its execution cost is the average time taken for a single judgment call, and its failure modes are "inconsistent category names" and "differences in labeling standards." The corresponding verification results are recorded, thereby constructing multiple initial experiences.

[0102] In this embodiment, the input and output states are obtained by parsing the tool interface definition, the applicable conditions and failure modes are obtained by parsing the skill module file, and the execution cost and verification results are obtained by parsing the call records and historical execution trajectories. These elements are then linked based on a unified experience field to construct multiple initial experiences, transforming capability information from different carriers into initial experiences with a consistent field structure. The input and output states characterize the state change endpoints corresponding to the experience, the applicable conditions and failure modes characterize the preconditions for the experience's usability and the failure scenarios for its inability to be used, and the execution cost and verification results characterize the actual cost of the experience and its past verification status. Therefore, each initial experience can be compared and filtered within the same structure according to state endpoints, applicable conditions, execution cost, and verification status, avoiding the loss of effective information or the inability to compare due to differences in carrier structure and granularity. This provides a structurally unified and traceable initial experience foundation for subsequently determining verifiable experiences from multiple initial experiences based on the current and target verifiable states, further improving the efficiency and accuracy of agent experience acquisition.

[0103] Optionally, step 106 includes: Based on the current decideable state and the target decideable state, candidate experiences are matched from multiple initial experiences, where the input state is consistent with the current decideable state and the output state is consistent with the target decideable state. Based on the applicable conditions, execution costs, failure modes, and verification results of candidate experiences, the confidence level of the candidate experiences is determined. Candidate experiences whose confidence levels meet the preset threshold are identified as verifiable experiences. The initial state and target state of verifiable experiences are the input state and output state of the candidate experiences, respectively.

[0104] Candidate experiences are initial experiences matched from multiple initial experiences, whose input state matches the current decidable state and whose output state matches the target decidable state. These experiences serve as candidates for determining verifiable experiences and have not yet undergone confidence screening. For example, when the current decidable state is "transcription with speaker timestamp has been formed" and the target decidable state is "order-level determination has been formed," the initial experience with the input state "transcription with speaker timestamp has been formed" and the output state "order-level determination has been formed" is the candidate experience obtained in this matching.

[0105] The confidence level of a candidate experience is a quantitative or graded value representing the degree to which it can be adopted. It is determined by a combination of the candidate experience's applicable conditions, execution costs, failure modes, and verification results, and is used to judge whether the candidate experience is sufficient to be identified as verifiable experience. For example, if the applicable conditions of the candidate experience match the current work object, the execution cost is lower than the preset cost, the failure mode is not triggered in the current scenario, and the verification result is passed, then its confidence level is determined to be high; conversely, if its applicable conditions are not met or there is a triggered failure mode, then its confidence level is determined to be low.

[0106] Verifiable experience refers to candidate experience whose confidence level meets a preset threshold. Its initial state and target state are taken from the input state and output state of the candidate experience, respectively. That is, its initial state is the current decidable state and its target state is the target decidable state. Therefore, it has a clear state transition endpoint that corresponds to the actual task objective, which can be used by the calling agent to execute the state transition task. For example, when the aforementioned candidate experience meets the preset threshold, it is determined to be verifiable experience. Its initial state is "transcription with speaker timestamp has been formed" and its target state is "order-level decision has been formed".

[0107] Based on the applicable conditions, execution costs, failure modes, and validation results of candidate experiences, the confidence level of the candidate experience is determined. One possible approach is to score the degree of satisfaction of applicable conditions, the level of execution costs, the triggering of failure modes, and the pass rate of validation results according to preset weights, and then sum the weighted scores to obtain the confidence level of the candidate experience. Another possible approach is to query a preset confidence level mapping table based on the applicable conditions, execution costs, failure modes, and validation results, and determine the retrieved value as the confidence level of the candidate experience. Yet another possible approach is to input the applicable conditions, execution costs, failure modes, and validation results of the candidate experience into a pre-trained confidence prediction model to obtain the confidence level of the candidate experience output by the confidence prediction model. No further limitations are specified here.

[0108] For example, the current determineable state is "transcription with speaker timestamp has been formed" and the target determineable state is "order-level determination has been formed". From multiple initial experiences, we match initial experiences whose input state matches the current determineable state and whose output state matches the target determineable state. This yields candidate experiences with the input state "transcription with speaker timestamp has been formed" and the output state "order-level determination has been formed". The applicable conditions for these candidate experiences are: the transcription product covers all audio segments and the speakers are distinguishable; the execution cost is the average time of a single determination call; the failure modes are "inconsistent category names" and "differences in labeling"; and the verification result is the category consistency rate of this determination method on sampled instances in previous runs. Based on the above applicable conditions, execution costs, failure modes, and verification results, the confidence level of this candidate experience was determined as follows: Since the current transcription output covers all audio segments and speakers are distinguishable, the applicable conditions are met; the time consumed by a single judgment call is lower than the preset cost; the two failure modes, "inconsistent category names" and "differences in annotation caliber," have been avoided in the improvement of a unified category vocabulary and deterministic mapping by code; and previous verification results show a high category consistency rate. Therefore, the confidence level of this candidate experience was determined to be at a high level that meets the preset threshold, and thus it was determined to be a verifiable experience. Its initial state is "transcription with speaker timestamps has been formed," and its target state is "order-level judgment has been formed." The initial experience with an input state of "pending processing of vehicle recording batches" and an output state of "transcription with speaker timestamps has been formed" was not matched as a candidate experience because its output state is inconsistent with the target verifiable state "order-level judgment has been formed," and therefore did not participate in the determination of this verifiable experience.

[0109] In this embodiment, candidate experiences are obtained by endpoint matching of multiple initial experiences with the current and target decisionable states. Then, the confidence level of each candidate experience is determined based on its applicability, execution cost, failure mode, and verification results. Candidate experiences with confidence levels meeting a preset threshold are identified as verifiable experiences. This ensures that the identified verifiable experiences not only have state transition endpoints that strictly correspond to the current task objective, but also that their reliability is quantified by the experience's multidimensional attributes. This avoids mistakenly including experiences with unmet applicability, excessively high execution costs, or triggered failure modes in verifiable experiences simply based on endpoint matching. Simultaneously, the starting and target states of verifiable experiences directly inherit from the input and output states of candidate experiences, ensuring the consistency and traceability of state semantics from initial experience to verifiable experience. This provides a clear, reliable, and controllable empirical basis for subsequent calls to the agent to execute state transition tasks and generate target experiences, further improving the accuracy of agent experience determination and the success rate of subsequent state transitions. Optionally, step 108 includes: Invoke the tools or skills recorded in verifiable experience to perform state transitions from the starting state to the target state; Execute the verification probes recorded in the verifiable experience and collect the measured results; If the actual test results meet the preset evaluation criteria, the state transition is confirmed to have passed the verification, and the target experience is generated.

[0110] The state transition from the initial state to the target state is a process of actually transforming a work object from its initial state to its target state by invoking tools or skills recorded in verifiable experience. Its purpose is to achieve the expected change in the form of the work object, and it is the core component of performing state transition tasks. For example, by invoking a decision model recorded in verifiable experience and calling a category mapping program, a transcription with speaker timestamps can be converted into an order-level decision.

[0111] The measured results are the data collected after executing the verification probe recorded in the verifiable experience. They reflect the effect achieved by the state transition from the initial state to the target state after actual execution and are the direct basis for judging whether the state transition meets the preset evaluation criteria. For example, after executing the narrow audio window source re-judgment probe on several sampled judgment instances, the collected source judgment accuracy and category consistency rate are obtained.

[0112] The preset evaluation criteria are pre-defined standards used to determine whether the measured results indicate that the state transition has been verified. These standards specify the indicator requirements or conditions that the measured results should meet, and can be implemented by the corresponding evaluation process. For example, the criteria set for the accuracy of source identification and the consistency rate of category are both not lower than the corresponding proportion threshold.

[0113] The process involves invoking tools or skills recorded in verifiable experience to perform a state transition from the initial state to the target state. One possible approach is to sequentially invoke the corresponding tools or skills modules according to the recorded tools or skills and their invocation order to process the current work object, resulting in the work object in the target state. Another possible approach is to generate a corresponding sequence of execution instructions based on the recorded tools or skills and execute this sequence to complete the state transition from the initial state to the target state. Yet another possible approach is to input the recorded tools or skills and the work object in the initial state into the agent, which then autonomously orchestrates and executes the corresponding invocation process to complete the state transition. No further limitations are specified here.

[0114] The verification probes recorded in the verifiable experience are executed, and the measured results are collected. One possible approach is to perform verification on the work object obtained after the state transition according to the replayable verification steps corresponding to the verification probes recorded in the verifiable experience, and collect the corresponding result data as the measured results. Another possible approach is to select a sample from the real data corresponding to the verifiable experience, and use the verification probe to replay the state transition process on the sample to collect the measured results. Yet another possible approach is to call the evaluation program associated with the verification probe to examine the work object obtained after the state transition, and use the examination output data as the measured results. No limitation is imposed here.

[0115] If the measured results meet the preset evaluation criteria, the state transition is confirmed to have passed verification, and the target experience is generated. One possible approach is to compare the measured results with the indicator requirements set by the preset evaluation criteria. If all indicators meet the requirements, the state transition is confirmed to have passed verification, and this verifiable experience is generated as the target experience. Another possible approach is to associate the execution information of this state transition with the verifiable experience and generate the target experience carrying this execution information, provided that the measured results meet the preset evaluation criteria. Yet another possible approach is to update the corresponding fields in the verifiable experience based on the measured results of this execution, and confirm the updated experience as the target experience. No further limitations are specified here.

[0116] For example, the initial state of the verifiable experience is "transcription with speaker timestamp has been formed," and the target state is "order-level judgment has been formed." The recorded calling tools or skills involve calling the judgment model to output severity, object, and source tags, and then calling a category mapping program to deterministically map this output to the corresponding violation category. The calling agent, according to this verifiable experience, performs a state transition from the initial state to the target state: inputting the transcribed text into the judgment model, which outputs severity, object, and source tags, and then the category mapping program deterministically maps this to one of eleven violation categories, obtaining a judgment result containing category, time interval, speaker, and evidence text. This transforms the working object from "transcription with speaker timestamp has been formed" to "order-level judgment has been formed." Subsequently, the verification probe recorded in this verifiable experience is executed, i.e., the narrow audio window corresponding to the judgment instance is captured and its source is re-determined, collecting test results including source determination accuracy and category consistency rate. If the test results meet the preset evaluation criteria, that is, the accuracy of source determination and the consistency rate of category are not lower than the corresponding thresholds, the state transition is confirmed to have passed the verification and the target experience is generated. The target experience records the initial state "transcription with speaker timestamp has been formed", the target state "order-level judgment has been formed", the applicable conditions, the tools or skills called, the verification probe, the test results, the confidence level and the source of evidence, which can be used as the edges in the state experience graph.

[0117] In the embodiments of this specification, by invoking the calling tools or skills recorded in the verifiable experience to actually execute the state transition from the initial state to the target state, the experience is no longer a static description but is actually executed, thereby exposing whether the experience is effective in actual operation. By executing the verification probe recorded in the verifiable experience to collect actual test results, data reflecting the actual effect of the state transition is obtained through replayable verification steps, rather than directly running the complete operation process, thus obtaining a basis for judgment at a lower cost. By confirming that the state transition has passed verification and generating the target experience only when the test results meet the preset evaluation criteria, the final generated target experience is experience that has been confirmed by both actual execution and verification, rather than untested candidate experience, thereby ensuring that the experience written into the state experience map has executability and effectiveness, and avoiding invalid or erroneous operation modes from being solidified into experience. Therefore, the agent's experience is further transformed from verifiable experience into verified target experience, significantly improving the accuracy and credibility of the experience, and providing executed and verified edges for building a reliable state experience map.

[0118] Optionally, after collecting the measured results, the following may also be included: If the measured results do not meet the preset evaluation criteria, the verifiable experience will be marked as rejected experience, and the confidence level of the rejected experience will be updated based on the measured results. If the measured results meet the preset evaluation criteria, the verifiable experience is marked as verified experience, and the confidence level of the verified experience is updated based on the measured results. Write back verified or rejected experiences, carrying evidence sources and confidence levels, into the state experience graph.

[0119] Rejected experience refers to experience obtained from verifiable experience when the measured results do not meet the preset evaluation criteria. It records that the state transition failed verification, indicating the invalidity of the experience under the current conditions to prevent its continued reliance in subsequent operations. For example, if the source determination accuracy of a verifiable experience does not reach the threshold set by the preset evaluation criteria after execution, then the verifiable experience is marked as rejected experience.

[0120] The confidence level of rejected experience is the updated confidence level carried by the rejected experience based on the measured results that do not meet the preset evaluation criteria. It is lower than before it was rejected and is used to characterize the degree to which the experience has been falsified or is no longer credible. For example, a verifiable experience that originally had a high confidence level will have its confidence level downgraded to a lower level, such as the rejected level, after its corresponding measured results no longer meet the preset evaluation criteria.

[0121] Verified experience refers to experience obtained by marking verifiable experience when the actual test results meet the preset evaluation criteria. It records that the state transition has been verified and is used to indicate that the experience is valid and reusable under the current conditions. For example, the verifiable experience from "a transcription with speaker timestamps has been formed" to "an order-level judgment has been formed" is marked as verified experience after its source determination accuracy and category consistency rate both meet the preset evaluation criteria. This verified experience is the aforementioned generated target experience.

[0122] Updating the confidence level of rejected experiences based on actual test results can be approached in several ways. One option is to adjust the confidence level of the rejected experience by the appropriate amount based on the deviation between the actual test results and the preset evaluation criteria; the greater the deviation, the larger the adjustment. Another option is to directly set the confidence level of the rejected experience to the preset value representing rejection. Yet another option is to combine the previous number of verifications of the rejected experience with the current test results, and then adjust its confidence level using Bayesian updates or a scoring method with time decay. No specific limitations are specified here.

[0123] Updating the confidence level of validated experience based on experimental results can be approached in several ways. One option is to increase the confidence level by the appropriate margin, based on how well the experimental results meet the preset evaluation criteria; a higher degree of satisfaction results in a larger increase. Another option is to set the confidence level of the validated experience to a preset value representing validation and record the experimental results of this validation as supporting evidence. Yet another option is to combine the number of previous validations of the validated experience with the current experimental results, using either cumulative counting or probability value updates to increase its confidence level. No specific limitations are specified here.

[0124] To write verified or rejected experiences, carrying evidence sources and confidence levels, back into the state experience graph, one option is to append the verified or rejected experience, along with its updated confidence level and evidence source, as a new experience record to the corresponding experience file in the state experience graph. Another option is to locate the existing experience record corresponding to the verified or rejected experience in the state experience graph and incrementally update the existing experience record based on the updated confidence level and evidence source. Yet another option is to write the verified or rejected experience, its confidence level, and evidence source into an isolated area in the state experience graph, and then merge the experience record in the isolated area into the formal experience record after accumulating a preset number of independent corroborations or verification by probe replay on the sample. No further limitations are specified here.

[0125] For example, after obtaining the test results from the verification probe, if the test results do not meet the preset evaluation criteria, such as the category consistency rate of a certain verifiable experience in the sampled instances not reaching the preset threshold, then the verifiable experience is marked as rejected experience, and its confidence level is downgraded from the original higher level to the rejected level based on the test results. At the same time, the test results are recorded as the source of evidence for the rejected experience. If the test results meet the preset evaluation criteria, such as the source determination accuracy rate and category consistency rate not being lower than the corresponding thresholds, then the verifiable experience is marked as verified experience, and its confidence level is upgraded to the verified level based on the test results. At the same time, the operation identifier, timestamp, and sample recording number on which the experience was based are recorded as the source of evidence. Subsequently, verified or rejected experiences, carrying the aforementioned evidence sources and updated confidence levels, are written back into the state experience graph: For experiences marked as verified, those transitioning from "transcribing with speaker timestamps" to "order-level judgments" are written into the graph as confirmed edges, with the edge record carrying the verified confidence level and the corresponding evidence source; for experiences marked as rejected, they are also written into the graph but their confidence level is marked as rejected, recording that the path is infeasible under the current conditions, thus allowing for pruning or detours in subsequent queries. Therefore, regardless of whether an experience is verified or rejected, its verification conclusion and evidence are fully preserved and fed back into the graph, enabling the graph to simultaneously record feasible and disproven paths.

[0126] In one optional embodiment, the experience records of the write-back state experience map can also be graded and controlled according to the admission category: for falsifiable findings that can be verified by replaying on samples with probes, they are accepted and written into the formal experience record if the replay verification is successful, and their confidence level is recorded as the verified level; for statistical findings, they are first written into the isolation area, and after accumulating a preset number of independent corroborations, they are upgraded to the verified level and then merged into the formal experience record, and their confidence level before the upgrade is recorded as the provisional level; for subjective observations, they are not written into the state experience map, but are submitted to manual adjudication.

[0127] In this embodiment, when the measured results do not meet the preset evaluation criteria, verifiable experiences are marked as rejected experiences and their confidence level is lowered according to the measured results. This allows falsified results to be explicitly recorded instead of being directly discarded, thus preserving information about falsified paths in the graph. This allows subsequent operations to identify and bypass the failure mode, avoiding repeated attempts at rejected paths. When the measured results meet the preset evaluation criteria, verifiable experiences are marked as verified experiences and their confidence level is raised according to the measured results. This confirms and enhances the credibility of verified experiences, making them suitable for subsequent reuse. By writing verified or rejected experiences, carrying the source of evidence and the updated confidence level, back into the state experience graph, each experience in the graph not only includes the state transition method but also carries its confidence level and traceable source of evidence, thus forming an auditable and distinguishable record of experience credibility. The above processing enables the state experience graph to continuously accumulate both positive and negative empirical evidence with each execution and verification, which not only improves the credibility and reusability of the experience, but also avoids the repeated use of invalid or erroneous operation patterns after they are solidified by retaining rejected experience, thereby further enhancing the decision reliability and execution efficiency of the agent in subsequent state transitions.

[0128] Optionally, the state experience graph includes a task layer and a general layer; After writing verified or refuted experiences, carrying evidence sources and confidence levels, back into the state experience graph, the following is also included: Execute the state transition task corresponding to the verified experience on the heterogeneous task to obtain the verification result of the heterogeneous task; If the verification results of heterogeneous tasks meet the preset evaluation criteria, the verified experience will be updated from the task layer to the general layer.

[0129] The task layer is the part of the state experience graph that contains decidable states and experiences organized for a specific task. The decidable states and experiences belong to that specific task and are used to record the verified state transition methods under that task. For example, the state experience graph constructed for the vehicle recording judgment task records verified experiences from "pending processing of vehicle recording batches" to "transcription with speaker timestamps formed" and from "transcription with speaker timestamps formed" to "order-level judgment formed".

[0130] The general layer comprises the decidable states and experiences in the state-experience graph, organized for cross-task general capabilities. These decidable states and experiences are not limited to a single task and can be queried and reused by multiple different tasks. For example, there is experience recording the complete transcription of long audio files, which is applicable to in-vehicle recording judgment tasks as well as other tasks that require transcription of long audio files.

[0131] In an optional embodiment, state merging can also be performed before writing back the state experience graph: query whether a decisionable state consistent with the decisionable state to be written already exists in the state experience graph; if it exists, reuse the decisionable state; if it does not exist, create a new state record for the decisionable state; if the decisionable state to be written is a task-level state, query whether a general state corresponding to the task-level state exists in the general layer; if it exists, attach the task-level state to the general state with a specialization relationship, so that the same working object form corresponds to one decisionable state in the graph, avoiding state duplication and dangling references.

[0132] Heterogeneous tasks are those that differ from the current task in terms of task objectives, data modalities, or operational scenarios. They are used to test whether validated experience can continue to be applied beyond the scope of the original task, thus providing a basis for updating the experience from the task layer to the general layer. For example, compared to the task of judging responsibility for in-vehicle audio recordings, the task of generating background music for e-commerce short videos has the task objective of generating audio, the data modality of text prompts and audio, and the operational scenario is also different, thus constituting a heterogeneous task.

[0133] A state transition task corresponding to verified experience is a task that transforms a work object in its initial state into a work object in its target state according to the tools or skills recorded in the verified experience. When executed on a heterogeneous task, the work object processed is the work object corresponding to the heterogeneous task. For example, applying verified experience of obtaining complete transcribed text from long audio to the processing of long audio material in a background music generation task is equivalent to executing the state transition task corresponding to the verified experience.

[0134] The validation result for a heterogeneous task is the result obtained after performing a state transition task corresponding to a validated experience on a heterogeneous task. It reflects whether the state transition achieved the expected effect in the heterogeneous task and is used to determine whether the validated experience has cross-task applicability. For example, in the background music generation task, after performing the experience of long audio overlapping slicing and repairing the truncated tail segment, the validation result is whether the resulting transcribed text covers the entire audio segment.

[0135] The preset evaluation criteria are pre-defined standards used to determine whether the verification results of heterogeneous tasks indicate that the verified experience still holds true for heterogeneous tasks. These criteria specify the indicator requirements or conditions that the verification results of heterogeneous tasks should meet. For example, a criterion set for the coverage of transcribed text is that it should not be lower than the corresponding percentage threshold.

[0136] To obtain the verification results of heterogeneous tasks, one option is to execute the state transition task corresponding to the verified experience on the heterogeneous task. This can be done in three ways: 1) Apply the calling tools or skills recorded in the verified experience to the working object of the heterogeneous task, execute the state transition from the initial state to the target state of the verified experience, and execute a verification probe on the transition result to collect the verification result of the heterogeneous task. 2) Input the calling tools or skills recorded in the verified experience and the working object of the heterogeneous task into the agent, which then executes the state transition task on the heterogeneous task and outputs the corresponding verification result. 3) Select a sample from the real data of the heterogeneous task, replay the state transition corresponding to the verified experience on the sample, and collect the verification result of the sample as the verification result of the heterogeneous task. No further limitations are specified here.

[0137] If the verification results of heterogeneous tasks meet the preset evaluation criteria, the verified experience is updated from the task layer to the general layer. One possible approach is to change the layer of the verified experience in the state experience graph from the task layer to the general layer, and record the verification result of the heterogeneous task as supporting evidence. Another possible approach is to create a new general experience record corresponding to the verified experience in the general layer, and retain the original record of the verified experience in the task layer as a link to the general experience record. Yet another possible approach is to copy the verified experience along with its verification results on the heterogeneous task to the general layer, and mark the original record in the task layer as having been overwritten by the general layer experience. No further limitations are specified here.

[0138] For example, in the vehicle recording judgment task, the method of overlapping slicing and repairing truncated segments of long audio has been executed and verified, and is marked as verified experience and written into the task layer of the state experience graph. The initial state of this verified experience is "vehicle recording batch to be processed" and the target state is "transcription with speaker timestamp has been formed". Its calling tool or skill is to overlap slicing long audio and repairing truncated segments before performing speech transcription and speaker separation. This verified experience is applied to a heterogeneous task, namely the task of generating background music for e-commerce live-streaming short videos. On this heterogeneous task, the state transition task corresponding to this verified experience is executed, that is, overlapping slicing and repairing truncated segments of long audio materials in the background music generation task, to obtain the corresponding audio processing results. The verification probe recorded by this verified experience is executed to collect the verification results of the heterogeneous task, that is, the consistency verification conclusion of whether the transcription and slicing results cover the entire audio segment. If the verification result of the heterogeneous task meets the preset evaluation criteria, i.e. the coverage is not lower than the corresponding threshold, it is confirmed that the verified experience is still valid for the heterogeneous task. Then, the verified experience is updated from the task layer to the general layer, so that it is retained in the task layer of the vehicle recording judgment task for continued use by the task, and in the general layer, it forms a general experience record that can be queried and reused by other tasks, including the background music generation task. The verification result of this heterogeneous task verification, together with the corresponding operation identifier and timestamp, is recorded as the source of evidence for the general experience record.

[0139] In the embodiments of this specification, by setting up a task layer and a general layer in the state experience graph, the experience is first verified within its respective task and then deposited in the task layer, avoiding the direct generalization and failure of experience that has not been verified across tasks. By executing the state transition task corresponding to the verified experience on heterogeneous tasks and obtaining the verification results of the heterogeneous tasks, the verified experience is cross-task verified by tasks that are different from the original task in terms of task objectives, data modalities, or operating scenarios. This allows the determination of whether the experience has cross-task applicability based on actual execution evidence, rather than relying on the similarity judgment of the experience text. By updating the verified experience from the task layer to the general layer only when the verification results of the heterogeneous tasks meet the preset evaluation criteria, the experience in the general layer is verified and confirmed by at least two different tasks, ensuring the credibility and reusability of the experience in the general layer. Therefore, the experience in the state experience graph can gradually evolve from task-specific to cross-task general, which not only preserves the adaptability of task-level experience to specific tasks, but also enables cross-task verified experience to be directly reused in subsequent different tasks, reducing the overhead of repeated exploration and verification in new heterogeneous tasks, and further improving the reusability and transferability of agent experience.

[0140] Optionally, step 110 includes: Extract the initial state and target state from the target experience, treat the initial state and target state as decisionable states, and store the decisionable states as a state file; Based on the initial state, target state, applicable conditions, tools or skills used, verification probes, test results, confidence level, and source of evidence in the target experience, an experience record is generated and stored as an experience file. By using the decisionable states in the state file as nodes and the experience records in the experience file as edges, the nodes and edges corresponding to multiple target experiences are associated and integrated to construct a state-experience graph.

[0141] A state file is a carrier that persistently stores decidable states in file form. It records the identifier, semantic description, state form definition, and state checker of the decidable state, serving as the source for generating state experience graph nodes. For example, the state file corresponding to "a transcription with speaker timestamps has been formed" records the identifier, semantic description, state form definition, and state checker used to determine the state.

[0142] An experience file is a persistent storage medium for the experience records corresponding to a target experience in file form. It records the initial state, target state, applicable conditions, tools or skills used, verification probes, test results, confidence level, and source of evidence for the target experience, serving as the source for generating edges in the state experience graph. For example, an experience file generated corresponding to the target experience from "a transcription with speaker timestamps has been formed" to "an order-level judgment has been formed" records various fields of the experience and their two endpoints.

[0143] Based on the starting state, target state, applicable conditions, tools or skills used, verification probes, test results, confidence level, and source of evidence in the target experience, an experience record is generated. One possible approach is to organize the aforementioned fields in the target experience into a single experience record according to a preset record structure, using the starting state and target state of this experience record as its endpoints. Another possible approach is to organize the aforementioned fields in the target experience into a single experience record, assign a unique identifier to this experience record, and then associate this unique identifier with the identifiers of its starting state and target state. Yet another possible approach is to serialize the aforementioned fields in the target experience into structured data or readable text in a preset format to obtain the experience record, and record the identifiers of its starting state and target state as an index within this experience record. No further limitations are specified here.

[0144] For example, for a target experience that has been verified, its initial state "transcription with speaker timestamp has been formed" and its target state "order-level judgment has been formed" are extracted. The initial state and the target state are taken as the decidable states, and corresponding state files are generated and persistently stored. The state files record the identifier, semantic description, state form definition and state checker of the corresponding decidable state. Based on the initial state "transcription with speaker timestamp has been formed", the target state "order-level judgment has been formed", the applicable conditions are that the transcription product covers the entire audio period and the speakers can be distinguished from each other, the tool or skill called is to call the judgment model to output the severity, the object and source are marked and the category mapping program is called to deterministically map to the corresponding violation category, the verification probe is to capture the narrow audio window corresponding to the judgment instance and re-determine its source, the measured results are the source judgment accuracy and category consistency rate collected on the sampled instance, the confidence level is the verified level, the source of evidence is the operation identifier, timestamp and sample recording number on which the experience is based, an experience record is generated and stored as an experience file. Subsequently, the decisionable states "transcription with speaker timestamp formed" and "order-level decision formed" in the status file are used as nodes. The experience records in the experience file are used as edges pointing from "transcription with speaker timestamp formed" to "order-level decision formed". Based on the correspondence between the endpoint states of the edges and the nodes, the edges are associated and integrated with the edges corresponding to another target experience in the speech transcription stage to construct a state experience graph for vehicle recording judgment tasks.

[0145] In the embodiments of this specification, by extracting the initial state and target state from the target experience into decidable states and storing them as state files, the decidable states constituting the graph nodes have independent persistent carriers. Their state morphology definitions and state checkers can be saved along with the states, thus allowing nodes to be referenced repeatedly without needing to be redefined. This also avoids the same decidable state being represented by different text labels, resulting in duplicate nodes. Furthermore, by organizing the various fields of the target experience into experience records and storing them as experience files, the experiences constituting the graph edges have independent persistent carriers. Their applicable conditions, calling tools or skills, verification probes, experimental results, and settings are all documented. Reliability and evidence sources are saved along with the edges, so each edge can be independently queried, updated, and audited. By using the decidable states in the state file as nodes and the experience records in the experience file as edges, and by associating and integrating the nodes and edges corresponding to multiple target experiences based on the correspondence between the endpoint states of the edges and the nodes, a relationship is formed between the nodes and edges with state identifiers as the link. This constructs a queryable and traversable state experience graph, enabling subsequent operations to locate the corresponding nodes in the graph based on the decidable state of the work object and query the available state transition methods along the edges, thus improving the organization and reusability of experience.

[0146] Optionally, after step 110, the method further includes: In response to the agent's current request, a graph projection block corresponding to the current request is generated based on the current content of the state experience graph and the position of the current request in the session; The graph projection block is attached to the current request, and if the state experience graph is updated, the graph projection block corresponding to the next request is regenerated based on the updated state experience graph.

[0147] A current request is a call request initiated by an agent to the model during its current operation, requesting the model to provide output. This request is carried in a message and can be supplemented with corresponding graph information as graph projection blocks are added. For example, in a vehicle recording judgment task, an agent initiates a call request to the model to determine the judgment method; the user prompt contains the specific content of this request.

[0148] The current content of the state experience graph represents the latest content of the nodes and edges actually existing in the graph and their carried fields at the time of responding to the current request. This content changes as experiences are written, updated, and their layer changes, rather than being a historical snapshot of the graph. For example, if a target experience was written before this request, from "a transcription with speaker timestamps has been formed" to "an order-level judgment has been formed," the actual node and edge existing in the graph, along with their carried confidence level and source of evidence, would be considered.

[0149] The position of the current request within a session refers to its order or stage in the message sequence of its respective session. It reflects the progress the agent has made when the request occurs and is used to determine the graph content related to this request. For example, if the current request is in the stage where transcription has been completed and a decision is about to be made, then its position corresponds to after transcription and before decision.

[0150] The graph projection tile corresponding to the current request is a compact view generated based on the current content of the state experience graph and the position of the current request in the session. It reflects the relevant part of the graph at the time of the request and is appended to the current request. For example, a compact text view containing the current decidable state, available experience edges from that state, and a summary of key failure modes.

[0151] The graph projection block corresponding to the next request is the graph projection block corresponding to another request initiated after the current request. It is regenerated based on the updated state experience graph when the state experience graph is updated, and thus can reflect the latest content of the graph. For example, after writing new verified experience in this request, the graph projection block corresponding to the next request will contain the newly written experience edge.

[0152] Based on the current content of the state experience graph and the position of the current request in the session, a graph projection block corresponding to the current request is generated. One possible approach is to determine the relevant decidable state based on the position of the current request in the session, read the neighborhood subgraph centered on the decidable state from the state experience graph, and render the neighborhood subgraph as a compact view as a graph projection block. Another possible approach is to filter the state experience graph by its layer to obtain relevant subgraphs, and render these subgraphs as a compact text view containing a state list, an edge list, and a summary of key failure modes as a graph projection block. Yet another possible approach is to render the entire state experience graph as a compact view as a graph projection block when the size of the state experience graph is smaller than a preset size, and to obtain relevant subgraphs by filtering by the current state neighborhood, reverse target retrieval, or tags when the size is not smaller than the preset size, and then render these as graph projection blocks. No further limitations are specified here.

[0153] For example, after completing speech transcription, the agent initiates a current request to determine how to obtain an order-level decision from the transcribed data. This current request is located in the session at a stage where transcription is complete but decision-making has not yet begun. The current content of the state experience graph includes three nodes: "Pending Vehicle Recording Batch," "Transcription with Speaker Timestamp Completed," and "Order-Level Decision Completed," as well as experience edges pointing from "Transcription with Speaker Timestamp Completed" to "Order-Level Decision Completed." These experience edges carry their applicable conditions, invoked tools or skills, verification probes, test results, confidence levels, and evidence sources. Based on the current content and the current request's location in the session, a neighborhood subgraph centered on "Transcription with Speaker Timestamp Completed" is read from the state experience graph and rendered as a compact text view containing the state, available experience edges originating from that state, and summaries of key failure modes such as "inconsistent category names" and "differences in labeling." This compact text view serves as the graph projection block corresponding to the current request. This graph projection block is then appended to the current request before being sent out. If, during the execution of this request, the agent writes newly discovered failure patterns or newly verified experiences back to the state experience graph, then in the next request, the graph projection block corresponding to the next request will be regenerated based on the updated state experience graph. This next request's graph projection block will contain the newly written experience edges or updated failure patterns, but will not contain stale copies of the graph projection block from the current request. Therefore, the graph projection block attached to each request reflects the current content of the graph, and this graph projection block only exists in the current request and is not written to the session's message history.

[0154] In the embodiments of this specification, a graph projection block is generated by responding to the current request and based on the current content of the state experience graph and the position of the current request in the session. This ensures that the graph information attached to each request corresponds to the stage of the current request and the actual content of the graph, rather than unconditionally injecting the entire graph or a fixed copy of the graph. This allows the injected content to be kept within an acceptable range even as the graph size grows. By attaching the graph projection block to the current request, the agent can know its decisionable state and available state transition experience at the time of decision-making, without needing to retrieve it through multiple rounds of retrieval, reducing round-trip overhead in the decision-making process. When the state experience graph is updated, the graph projection block corresponding to the next request is regenerated based on the updated state experience graph. This allows the experience just written into the graph to be read immediately by the next request, ensuring that the agent always sees the current content of the graph. At the same time, since the graph projection block only exists in the current request and is not written to the message history of the session, it avoids the accumulation of multiple graph copies in the history as the session progresses. This prevents outdated graph information from interfering with subsequent decisions and also avoids the context overhead of repeatedly carrying graph content in historical messages. Thus, it balances the freshness of graph information, the controllability of context overhead, and the reliability of decisions.

[0155] Optionally, the tool interface definition is the interface definition of the general execution primitive, and the skill module file is used to store the procedural scheme; Step 108 includes: Based on verifiable experience records, the execution primitives required for performing state transition tasks are determined from general execution primitives. The intelligent agent is invoked to perform the state transition task using the required execution primitives. Once the state transition task is verified, the target experience is generated and associated with the corresponding procedural scheme in the skill module file.

[0156] The interface definition of a general execution primitive describes the input parameters, output structure, and calling constraints of the general execution primitive that can be directly invoked by an agent. It is not set for a specific task, but rather provides common basic execution capabilities for various tasks. For example, there are interface definitions for basic execution primitives such as command execution, file reading, file writing, and file editing, as well as model primitives such as multimodal understanding and language model invocation.

[0157] A procedural solution is a complete execution flow and precautions stored in the skill module file, geared towards a specific task or scenario. It records the operational paradigms required to achieve a certain goal in a way that can be called upon and referenced. For example, a solution may record the speech transcription and speaker separation process, as well as the rules for mapping violation judgment categories.

[0158] The execution primitives required for a state transition task are selected from general execution primitives that must be invoked to complete the task. They constitute the basic set of capabilities for performing the task. For example, to complete the state transition from the decision obtained through transcription, the required execution primitives include language model invocation and file writing. The former is used to output the severity, object, and source tags, while the latter is used to write the decision result to disk.

[0159] The procedural schemes corresponding to the generated target experience are stored in the skill module file and correspond to the target experience in terms of function or implementation. After establishing a link between them and the target experience, the source scheme of the experience can be traced. For example, a procedural scheme that records the violation judgment category mapping rules corresponding to the target experience judged by transcription.

[0160] Based on verifiable experience records of calling tools or skills, the execution primitives required for executing the state transition task are determined from general execution primitives. One possible approach is to map the calling tools or skills recorded in the verifiable experience to corresponding general execution primitives according to a pre-defined mapping relationship between calling tools or skills and execution primitives, thus obtaining the execution primitives required for the state transition task. Another possible approach is to search for matching execution primitives in the general execution primitives based on the interface information declared by the calling tools or skills recorded in the verifiable experience, and then determine the found execution primitives as the execution primitives required for the state transition task. Yet another possible approach is to input the descriptions of the calling tools or skills and the state transition task recorded in the verifiable experience into the agent, which then selects the required execution primitives from the general execution primitives. No further limitations are specified here.

[0161] For example, the tool interface is defined as the interface definition of general execution primitives, including basic execution primitives such as command execution, file reading, file writing, and file editing, as well as the interface definitions of model primitives such as multimodal understanding and language model invocation. The skill module file stores the procedural scheme that records the speech transcription and speaker separation process and the violation judgment category mapping rules. For verifiable experience from "transcription with speaker timestamp has been formed" to "order-level judgment has been formed", the recorded calling tool or skill calls the judgment model to output severity, object, and source markers, and calls the category mapping program to deterministically map the output to the corresponding violation category. Based on the calling tool or skill, according to the preset mapping relationship, the execution primitives required to perform this state transition task are determined from the general execution primitives as the language model invocation primitive and the file writing primitive, whereby the language model invocation primitive is used to output severity, object, and source markers, and the file writing primitive is used to write the judgment result to disk. The intelligent agent is invoked to perform a state transition task using the aforementioned execution primitives: The transcribed text is input into the judgment model via the language model's primitives, which outputs severity, object, and source tags. Then, a category mapping procedure definitively maps the text to one of eleven violation categories. Finally, a file-writing primitive stores the judgment result, including category, time interval, speaker, and evidence text, on disk, transforming the work object from "transcribed text with speaker timestamp" to "order-level judgment." Once this state transition task is verified, a corresponding target experience is generated and associated with the corresponding procedural scheme recorded in the skill module file, which contains violation judgment category mapping rules. This establishes a traceable link between the target experience and its source procedural scheme.

[0162] In the embodiments of this specification, by explicitly defining the tool interface as the interface definition of a general execution primitive, the execution of state transition tasks is based on basic execution capabilities independent of specific tasks. The differences between tasks are expressed by the calling tools or skills recorded in verifiable experience and the procedural schemes stored in the skill module files. Therefore, it is not necessary to add dedicated tools or dedicated interfaces for each specific operation, thus controlling the growth of task-specific interfaces. By determining the execution primitives required to execute state transition tasks from general execution primitives based on the calling tools or skills recorded in verifiable experience, the calling methods recorded in experience can be converted into actual callable basic capabilities, ensuring the executability of experience. By calling the agent to execute the state transition task using the required execution primitives, and generating the target experience after the state transition task is verified and confirmed, the generation of target experience is based on actual execution and verification. By associating the target experience with the corresponding procedural scheme in the skill module files, a traceable association is maintained between the target experience and the procedural scheme from which it originates. This not only preserves the reusability value of existing skill module files, but also allows the executed and verified experience to be queried and combined independently of the original scheme. Therefore, the general execution primitives, procedural schemes, and verified experience form a hierarchical relationship, allowing capabilities to be continuously accumulated without adding task-specific interfaces or discarding existing skill module files, further improving the reusability of experience and the scalability of the system.

[0163] Corresponding to at least one of the above embodiments, Figure 2 This diagram illustrates a state experience map in an agent experience construction method according to an embodiment of this specification, as shown below. Figure 2 As shown: The state experience graph uses decidable states as nodes and verified target experiences as edges. Decidable states include pending vehicle recording batches, transcriptions with speaker timestamps, and order-level judgments with inconsistent category names. Target experiences starting with pending vehicle recording batches and targeting transcriptions with speaker timestamps are speech transcription experiences. Target experiences starting with transcriptions with speaker timestamps and targeting order-level judgments are judgment and category mapping experiences. Direct judgment experiences starting with transcriptions with speaker timestamps and targeting inconsistent category names are rejected experiences. The experience records in the experience file include the starting state, target state, applicable conditions, tools or skills used, verification probes, test results, confidence level, evidence source, failure mode, and layer. The layers include the task layer and the general layer.

[0164] See Figure 3 , Figure 3A flowchart of an agent operation method provided in one embodiment of this specification is shown, including: Step 302: Obtain the state experience graph and the task objective, and determine the current decisionable state and the target decisionable state corresponding to the task objective. The state experience graph uses decisionable states as nodes and verified target experiences as edges.

[0165] A state experience graph is a persistent cognitive structure with decideable states as nodes and verified target experiences as edges. It records the decideable states of the work object and the experience used to transition from one decideable state to another. In this operational method, this state experience graph is a pre-constructed graph that serves as the cognitive basis for querying candidate paths and executing task objectives. For example, the state experience graph constructed for the aforementioned vehicle recording judgment task includes nodes such as "vehicle recording batch to be processed," "transcription with speaker timestamp formed," and "order-level judgment formed," and its edges include verified target experiences obtained from the former two to derive the latter.

[0166] The task objective is the goal that the intelligent agent aims to achieve during its current operation, characterized by changes in the form of the work object. It specifies the form the work object should be transformed into. For example, determining violations based on the type, time range, speaker, and evidence text obtained from vehicle-mounted recordings.

[0167] The current determineable state corresponding to the task objective is the determineable state of the work object before the start of the current operation or the state transition to be advanced in this operation. It constitutes the overall starting endpoint of the candidate path. For example, in the vehicle recording judgment task, the work object is initially the vehicle recording to be processed, so the current determineable state is "vehicle recording batch to be processed".

[0168] The decisionable state corresponding to a task objective is the decisionable state that the work object is expected to reach through the current operation, which constitutes the overall target endpoint of the candidate path. For example, if the task objective requires the output of order-level violation judgment, then the decisionable state of the objective is "order-level judgment has been formed".

[0169] Determining the current decideable state and the target decideable state corresponding to the task objective can be done in several ways. One option is for a state checker to determine the work object's current decideable state based on the corresponding state form definition, and then determine the target decideable state based on the output form required by the task objective. Another option is to parse the task contract corresponding to the task objective, extract the initial form and target form of the work object from the parsing results, and use them as the current decideable state and the target decideable state, respectively. Yet another option is to input the work object and the task objective into the agent, which then determines the current decideable state and the target decideable state from the decideable states recorded in the state experience graph. No further limitations are specified here.

[0170] For example, a completed state experience graph for this task is obtained. This graph uses "pending vehicle recording batch," "transcribed with speaker timestamps," and "order-level judgment formed" as nodes, and "transcribing with speaker timestamps" as edges, with the experience of obtaining "transcribed with speaker timestamps" from "pending vehicle recording batch" and the experience of obtaining "order-level judgment formed" from "transcribed with speaker timestamps." The task objective is to obtain violation judgments with category, time interval, speaker, and evidence text from vehicle recordings. Based on this, the current verifiable state is determined to be "pending vehicle recording batch," and the target verifiable state is "order-level judgment formed." Thus, the current problem to be solved is determined as: finding a feasible state transition method from "pending vehicle recording batch" to "order-level judgment formed" in this state experience graph.

[0171] Step 304: Query candidate experiences from the state experience graph where the starting state is consistent with the current decisionable state and the target state is consistent with the target decisionable state to obtain candidate paths.

[0172] Candidate experiences are confirmed experiences obtained from the state experience map whose starting state matches the current decisionable state and whose target state matches the target decisionable state. They are the basic units constituting candidate paths. When there is no directly corresponding single experience in the state experience map, candidate experiences also include experiences whose starting state matches the current decisionable state and can be combined with other experiences according to state connection relationships to reach the target decisionable state. For example, experiences with "pending processing of vehicle recording batches" as the starting state and "transcription with speaker timestamps has been formed" as the target state, and experiences with "transcription with speaker timestamps has been formed" as the starting state and "order-level decision has been formed" as the target state.

[0173] A candidate path is a path composed of one or more candidate experiences connected by state relationships. Its overall starting endpoint is consistent with the current decisionable state, and its overall target endpoint is consistent with the target decisionable state. When it contains multiple candidate experiences, it is internally connected through at least one intermediate decisionable state. For example, a path from "pending vehicle recording batch" through "transcribed with speaker timestamp" to "order-level decision formed".

[0174] To retrieve candidate experiences and obtain candidate paths from the state experience graph, one possible approach is to search the state experience graph for endpoints that match the current decideable state and the target decideable state, and directly use the retrieved single candidate experience as a candidate path, or combine multiple connected candidate experiences into a candidate path. Another possible approach is to perform a forward traversal of the state experience graph starting from the current decideable state and a reverse search ending at the target decideable state, using the intersection of the forward traversal and the reverse search as a candidate path. Yet another possible approach is to filter the state experience graph by task layer and general layer, and then search for endpoints that match candidate experiences on the filtered subgraphs and combine them into a candidate path. No further limitations are specified here.

[0175] For example, in the state experience graph, candidate experiences are queried whose starting state is consistent with the current decidable state "Pending Vehicle Recording Batch" and whose target state is consistent with the target decidable state "Order-level Determination Formed". Since there is no single experience in the graph that directly connects these two states, candidate experiences starting with "Pending Vehicle Recording Batch" (whose target state is "Transcription with Speaker Timestamp Formed") and candidate experiences connected to this target state starting with "Transcription with Speaker Timestamp Formed" and targeting "Order-level Determination Formed" are retrieved. These candidate experiences are combined according to their state connection relationships to obtain a candidate path from "Pending Vehicle Recording Batch" to "Order-level Determination Formed". This candidate path is connected internally via the intermediate decidable state "Transcription with Speaker Timestamp Formed". The specific implementation of combining multiple candidate experiences into a candidate path is further described in the optional embodiments below.

[0176] Step 306: Execute directional probes on candidate paths to obtain test results, and determine the winning path based on the test results.

[0177] Directional probes are low-cost verification performed on a subset of samples determined from the real data corresponding to the candidate paths when the candidate paths are still uncertain. They are used to obtain experimental results and determine the winning path and update the confidence of the candidate experience involved, rather than directly running the complete process.

[0178] The measured results are the data collected after performing directional probes on candidate paths. They reflect the actual feasibility of candidate paths on real data and are the direct basis for determining the winning path. For example, the transcription coverage, category consistency rate, and source determination accuracy are collected after performing transcription and judgment on sampled recordings.

[0179] The winning path is the path selected from multiple candidate paths based on actual test results and chosen for freezing as a deterministic process. It is the state transition path that has been confirmed to be practically feasible in the current operation. For example, it is the candidate path that has the highest transcription coverage and classification consistency rate on the sampled samples, as verified by probes.

[0180] A directional probe is executed on candidate paths to obtain test results, and the winning path is determined based on these results. One possible approach is to execute the directional probe on the real data corresponding to the candidate path, obtain test results, rank the candidate paths according to the quality of the test results, and determine the winning path based on the best test results. Another possible approach is to execute the directional probe on the real data corresponding to the candidate path, obtain test results, compare the test results with preset evaluation criteria, and determine the winning path based on the preset evaluation criteria. Yet another possible approach is to execute the directional probe on the candidate path, and if the test results do not meet expectations, reflect on the test results, regenerate candidate paths, and execute the directional probe again until a winning path is determined. No further limitations are specified here.

[0181] For example, for the candidate paths obtained from "pending vehicle recording batches" to "order-level judgments formed," a directional probe is executed on the corresponding real recording data. That is, transcription and judgment are performed on a small number of real samples corresponding to the path, and corresponding verification probes are executed (e.g., re-verifying the source by extracting a narrow audio window corresponding to the judgment instance, and checking the consistency between the judgment category and the established category vocabulary). The measured results are collected, including transcription coverage, source judgment accuracy, and category consistency rate. If the measured results show that the candidate path is feasible on real samples, it is determined as the winning path; if there are multiple candidate paths, the measured results of each candidate path are compared, and the candidate path with the better measured results is determined as the winning path.

[0182] Step 308: Freeze the winning path as a deterministic process and execute the task objective to obtain the execution result.

[0183] A deterministic process is a repeatable, executable process obtained by compiling or solidifying the winning path, which no longer involves open-ended agent decisions. It can be directly scheduled to execute the task objective, so that the execution period no longer depends on the open-ended exploration of agents. For example, the winning path, which is first transcribed and then decided, can be solidified into a decision script or a directed acyclic graph.

[0184] The execution result is the output of a deterministic process after executing a task objective. It reflects the actual achievement of the task objective and is the object of subsequent evaluation. For example, the violation determination results of each order, corresponding to the category, time range, speaker, and evidence text, output by the verification collection.

[0185] The winning path is frozen into a deterministic process, and the task objective is executed to obtain the execution result. One possible approach is to compile the winning path into a script or directed acyclic graph, record its version number and source of evidence, and run the script or directed acyclic graph to execute the task objective and obtain the execution result. Another possible approach is to solidify the winning path into a container image, workflow directed acyclic graph, or function orchestration, schedule the solidified product to execute the task objective, and obtain the execution result. Yet another possible approach is to solidify the winning path into an executable plan, which is then executed step by step by the agent without introducing open-ended decisions, and the execution result is obtained. No further limitations are imposed here.

[0186] For example, the winning candidate path is frozen into a deterministic judgment process. This process solidifies the following steps: first, overlapping segments are applied to long audio files and the truncated ends are repaired; then, speech transcription and speaker separation are performed; finally, the severity, object, and source tags output by the judgment model are deterministically mapped from the code to the corresponding violation category. The version number of this deterministic process and the source of the evidence on which it is based are recorded. This deterministic judgment process is run on the verification data to obtain the execution results, namely, the violation judgment results for each order, including category, time interval, speaker, and evidence text.

[0187] Step 310: Evaluate the execution results and write the evaluation results and actual test results back to the state experience map.

[0188] Evaluation involves verifying the execution results according to established evaluation requirements or criteria to determine whether the task objectives have been truly achieved. For example, the evaluation results may include checking whether the category belongs to the established eleven-category vocabulary, whether the time interval and speaker are complete, and whether the evidence text matches the evaluation.

[0189] The evaluation results are conclusions obtained after the evaluation, reflecting whether the execution results meet the requirements of the task objectives. These results, along with the measured results, can be written back into the state experience map as empirical evidence for this operation. For example, conclusions regarding whether each category's judgment passed or whether the judgment results reached the acceptance threshold.

[0190] Write-back involves adding the evaluation and measured results as new empirical evidence to the state experience graph to update the corresponding empirical edges, confidence levels, and sources of evidence. For example, the measured and evaluation results of this execution are written into the corresponding empirical edges in the state experience graph, carrying the source of evidence for the current operation.

[0191] The execution results are evaluated, and the evaluation results and measured results are written back to the state experience graph. One possible approach is to verify the execution results according to predetermined evaluation requirements, obtain the evaluation results, and write the evaluation results and measured results together into the state experience graph to update the confidence and evidence source of the corresponding experience edges. Another possible approach is to have the execution results verified manually or externally to obtain the evaluation results, and write the evaluation results and measured results back into the state experience graph. Yet another possible approach is to write the evaluation results and measured results as new empirical evidence into the state experience graph, or to add new experience edges and update the failure modes and evidence sources of existing experience edges. No specific limitations are imposed here.

[0192] For example, continuing from the previous example, the execution results output by the deterministic judgment process are evaluated. This involves verifying whether the category of each judgment record belongs to the predetermined category vocabulary, whether the time interval and speaker are complete, and whether the evidence text matches. The evaluation result reflects whether the execution result meets the acceptance criteria required by the task objective. The evaluation result and the measured results collected by the aforementioned directional probe are written back to the state experience graph: for the experience edge corresponding to the judgment stage, its confidence level is increased based on the current evaluation result, and the current operation identifier, timestamp, and sample recording number are recorded as the source of evidence; for the problems exposed in the evaluation, the corresponding failure modes are added to the failure modes of the corresponding experience edge. Therefore, both positive and negative evidence obtained in the current operation are fed back to the state experience graph for subsequent operation queries and reuse.

[0193] In the embodiments of this specification, by using the constructed state experience graph as the basis for persistent capability cognition during the runtime phase, candidate paths are obtained by querying and combining the current identifiable state corresponding to the task objective and the target identifiable state. This allows the reuse of experience to be based on state associations, rather than searching and re-evaluating the applicability of skill module files item by item. By executing targeted probes on candidate paths, experimental results are obtained at low cost on a small amount of real data, and the winning path is determined accordingly. This ensures that path selection is based on reproducible verification evidence, rather than blindly trying and failing on the complete runtime process. By freezing the winning path as a deterministic process and executing the task objective, the exploration is focused on the design phase, and the execution phase no longer relies on open agent decisions, thus balancing open design and stable execution. By evaluating the execution results and writing the evaluation results and experimental results back to the state experience graph, the runtime evidence from the runtime side continuously flows back to the graph, providing a higher-level capability cognition starting point for subsequent tasks.

[0194] Optionally, step 304 includes: From the state experience map, determine the first candidate experience starting from the current decisionable state and the second candidate experience starting from the target state of the first candidate experience; The first and second candidate experiences are combined according to their state connection relationship to obtain multiple candidate paths; Based on the applicable conditions, execution costs, failure modes, combinatorial constraints, and dominance relationships contained in the candidate experiences of each candidate path, multiple candidate paths are pruned to obtain candidate paths; among them, the current decisionable state and the target decisionable state are determined by the state checker based on the state morphology definition of the agent's working object.

[0195] The first candidate experience is a candidate experience determined from the state experience map, starting from the current decideable state, with its target state being a certain intermediate decideable state. It constitutes the first segment of the candidate path and is used to advance from the current decideable state to that intermediate decideable state. For example, an experience starting from "batch of in-vehicle recordings to be processed" and targeting "transcription with speaker timestamps has been formed".

[0196] The second candidate experience is a candidate experience determined from the state experience map, starting with the target state of the first candidate experience. Its target state is either the target decidable state or an intermediate decidable state that is closer to the target decidable state. It is used to connect with the first candidate experience to continue to advance towards the target decidable state. For example, an experience starting with "a transcription with speaker timestamps has been formed" and aiming at "an order-level decision has been formed".

[0197] Multiple candidate paths are obtained by combining first and second candidate experiences according to their state connection relationships. The overall starting endpoint is the current decidable state, and the overall target endpoint is the target decidable state. Internally, they are connected through at least one intermediate decidable state. When there are multiple optional first candidate experiences or multiple optional second candidate experiences, multiple candidate paths can be obtained. For example, when there are experiences corresponding to multiple transcription methods or multiple determination methods in the graph, multiple candidate paths can be obtained from "pending processing of vehicle recording batches" to "order-level determination has been formed".

[0198] Pruning is the process of narrowing down the candidate pool and retaining candidate paths by removing those that do not meet constraints or are not feasible, based on the applicable conditions, execution costs, failure modes, combination constraints, and dominance relationships contained in the candidate experiences included in each candidate path. For example, it may remove candidate paths that contain candidate experiences whose applicable conditions do not meet the current working object, or remove candidate paths whose execution costs exceed a preset cost limit.

[0199] Determining the first and second candidate experiences from the state experience graph can be done in several ways. One option is to select the first candidate experience from the outgoing edges corresponding to the current decidable state, and the second candidate experience from the outgoing edges corresponding to the target state of that first candidate experience. Another option is to retrieve experiences from the state experience graph that start from the current decidable state as the first candidate experience, and retrieve experiences that start from the target state of that first candidate experience as the second candidate experience. A third option is to input the current decidable state and the state experience graph into the agent, allowing the agent to autonomously determine the first and second candidate experiences. No further limitations are specified here.

[0200] Multiple candidate paths are obtained by combining the first and second candidate experiences according to their state connection relationships. One possible approach is to connect the first and second candidate experiences sequentially according to their endpoint states, and combine them when the target state of the first candidate experience matches the starting state of the second candidate experience. Another possible approach is to combine multiple first and second candidate experiences when multiple first and second candidate experiences exist, retaining those combinations where the endpoint states can be connected, to obtain multiple candidate paths. Yet another possible approach is to perform a finite-depth traversal of the state experience graph starting from the current decisionable state, and use the paths that can reach the target decisionable state during the traversal as multiple candidate paths. No further limitations are specified here.

[0201] Based on the applicable conditions, execution costs, and failure modes of the candidate experiences contained in each candidate path, multiple candidate paths are pruned to obtain candidate paths. One possible approach is to remove candidate paths whose applicable conditions do not meet the current working object. Another possible approach is to remove candidate paths whose sum of execution costs exceeds a preset cost limit. Yet another possible approach is to remove candidate paths whose failure modes have been triggered and cannot be avoided in this scenario, as well as candidate paths that conflict with composite constraints and candidate paths whose applicable conditions, execution costs, and failure modes are dominated by other candidate paths. No further limitations are imposed here.

[0202] For example, in the state experience graph, the first candidate experience is determined as the experience that starts with the current determineable state "pending processing of vehicle recording batches" and targets "transcription with speaker timestamps has been formed," which records the execution method of separating speech transcription from the speaker; and using the target state "transcription with speaker timestamps has been formed" of the first candidate experience as the starting state, the second candidate experience is determined as the experience that targets "order-level judgment has been formed," which records the execution method of deterministically mapping the judgment model output to the violation category. The first and second candidate experiences are combined according to the state connection relationship to obtain a candidate path from "pending processing of vehicle recording batches" through "transcription with speaker timestamps has been formed" to "order-level judgment has been formed." If the graph also records candidate experiences corresponding to other transcription methods (e.g., transcription experiences with different slicing strategies) or other judgment methods (e.g., judgment experiences with different category mapping strategies), multiple candidate paths can be combined to obtain them. Subsequently, based on the applicable conditions (such as whether the duration and sampling rate of the audio to be processed are within the corresponding range, whether the transcription product covers all audio time periods and the speakers can be distinguished from each other), execution costs (such as transcription time and judgment call volume), failure modes (such as long segment transcription truncation, inconsistent category names, and differences in annotation standards), combination constraints, and dominance relationships contained in each candidate path, multiple candidate paths are pruned: candidate paths whose applicable conditions do not meet the current working object are removed, candidate paths whose execution costs exceed the preset cost limit are removed, candidate paths that contain failure modes that have been triggered and cannot be avoided in this scenario are removed, and candidate paths that conflict with combination constraints or are dominated by other candidate paths are removed, thereby obtaining the retained and feasible candidate paths.

[0203] In this embodiment, by determining a first candidate experience starting from the current determinable state in the state experience graph, and determining a second candidate experience starting from the target state of the first candidate experience, and then combining the first and second candidate experiences according to their state connection relationships, experiences that were originally isolated and only described single-segment state transitions can be automatically spliced ​​into candidate paths that span multiple state transitions according to state endpoints. This solves the problem that skill module files lack explicit state connection relationships and are difficult to combine and reuse. By combining multiple candidate paths, a set of candidates for comparison is provided for path selection, rather than only using a single fixed process. By pruning multiple candidate paths according to the applicable conditions, execution costs, and failure modes of the candidate experiences contained in each candidate path, obviously infeasible candidate paths can be removed in advance without consuming model calls, narrowing the verification scope of subsequent directional probes. This ensures the quality of candidate paths while controlling verification overhead, further improving the efficiency of path selection and subsequent execution.

[0204] Optionally, in step 306, a directional probe is performed on the candidate path to obtain the measured results, including: A predetermined number of samples are determined from the real data corresponding to the candidate paths to obtain a sample subset; Execute state transitions in candidate paths using a subset of samples and collect measured results; The confidence level of the candidate experience included in the candidate path is updated based on the measured results.

[0205] The sample subset consists of a predetermined number of samples determined from the real data corresponding to the candidate path. This subset is smaller than the full dataset and is used to reflect the actual feasibility of the candidate path while controlling verification costs. For example, several recordings selected from real vehicle recording data would be far fewer than the full dataset.

[0206] The measured results are the data collected after performing state transitions in candidate paths using a subset of samples. They reflect the actual execution effect of the candidate path on the subset of samples and are the direct basis for updating the empirical confidence of the candidates involved. For example, the transcription coverage, source determination accuracy, and category consistency rate collected after performing transcription and judgment on several sampled recordings.

[0207] Updating the confidence level of candidate experiences included in a candidate path involves adjusting the confidence level of each candidate experience included in the candidate path based on the experimental results, so that the credibility of the experience changes with the experimental evidence. For example, if the experimental results meet the preset evaluation criteria, the confidence level of the candidate experience involved is increased; if they do not meet the criteria, the confidence level is decreased.

[0208] A predetermined number of samples are determined from the real data corresponding to the candidate paths to obtain a sample subset. One possible method is to randomly select a predetermined number of samples from the real data corresponding to the candidate paths to obtain a sample subset. Another possible method is to select samples that meet predetermined risk characteristics or coverage boundary conditions from the real data corresponding to the candidate paths to obtain a sample subset. Yet another possible method is to select samples covering different categories or different scenarios from the real data corresponding to the candidate paths using stratified sampling to obtain a sample subset. No specific limitations are imposed here.

[0209] Using a subset of samples to execute state transitions in candidate paths and collect experimental results, one possible approach is to sequentially execute each segment of the candidate path using the subset of samples, and execute the corresponding verification probe after each segment to collect experimental results. Another possible approach is to replay the verification probes corresponding to the candidate path in the empirical data on the subset of samples, and use the output of the verification probes as the experimental results. Yet another possible approach is to input the subset of samples into the execution process corresponding to the candidate path, and collect the output and intermediate products of the execution process on the subset of samples as experimental results. No specific limitations are imposed here.

[0210] The confidence level of candidate experiences included in candidate paths is updated based on the measured results. One possible approach is to increase the confidence level of the candidate experiences if the measured results meet the preset evaluation criteria, and decrease the confidence level if they do not. Another possible approach is to update the confidence level of the candidate experiences by the corresponding magnitude according to the deviation of the quantitative indicators of the measured results from the preset threshold. Yet another possible approach is to update the confidence level of the candidate experiences by combining the previous number of verifications of the candidate experiences with the results of this test, using methods such as count accumulation, probability value update, or time decay scoring. No specific limitations are imposed here.

[0211] For example, for a candidate path from "batch of in-vehicle recordings to be processed" through "transcription with speaker timestamps" to "order-level judgment", a preset number of samples are determined from the real recording data corresponding to the candidate path to obtain a sample subset, such as selecting several in-vehicle recordings covering different durations and different numbers of speakers. This sample subset is used to perform state transitions in the candidate path, that is, on this sample subset, speech transcription and speaker separation are first performed, followed by violation judgment. During this process, corresponding verification probes are executed, such as re-verifying the source of the judgment instance by extracting a narrow audio window, checking the consistency between the judgment category and the predetermined category vocabulary, and collecting actual test results, including transcription coverage, source judgment accuracy, and category consistency rate. Subsequently, the confidence levels of the candidate experiences included in the candidate path are updated based on the experimental results: if the experimental results meet the preset evaluation criteria, i.e., the transcription coverage, source determination accuracy, and category consistency rate are all not lower than the corresponding thresholds, then the confidence levels of the candidate experiences corresponding to the speech transcription stage and the violation determination stage are increased; if any experimental result does not meet the preset evaluation criteria, then the confidence level of the candidate experience corresponding to that stage is decreased accordingly, and the failure modes exposed this time are added to the failure modes of the candidate experience. Therefore, the confidence level of the candidate experiences included in the candidate path is updated with the experimental evidence from the small sample probe, enabling subsequent queries and pruning to be performed based on the latest confidence levels.

[0212] In this embodiment, a sample subset is obtained by determining a preset number of samples from the real data corresponding to the candidate path. This sample subset is then used to execute state transitions in the candidate path to collect measured results. This ensures that path verification is performed on only a small number of samples, thereby obtaining measured evidence reflecting the feasibility of the candidate path at a cost far lower than running the entire process, avoiding full-scale trial and error without evidence. By updating the confidence level of the candidate experience contained in the candidate path based on the measured results, the confidence level of the experience in the graph is no longer a static label, but can dynamically rise and fall with each probe verification. This distinguishes between repeatedly verified experience and experience verified by only a few samples in the same graph. By combining small-sample probes with confidence level updates, the selection of candidate paths and the maintenance of experience form a unified data closed loop. This not only improves the reliability of the winning path in this task, but also allows the state experience graph to continuously accumulate evidence-based experience with each run, further reducing the need for repeated exploration in subsequent tasks.

[0213] Taking vehicle-mounted audio recording for liability assessment as an example, the final freezing solution achieved a precision (P) of 0.857, a recall (R) of 0.818, and an F1 score of 0.837 (True Positive (TP) = 18, False Positive (FP) = 3, and False Negative (FN) = 4) in the verification process. This meets the acceptance threshold of a precision and recall rate of no less than 0.8, representing a significant improvement over the initial version (P = 0.286, R = 0.500, F1 = 0.364). The manual labor input was also reduced from approximately 5 person-days to approximately 0.5 person-days. The above values ​​are merely examples of this embodiment and do not constitute a limitation on the scope of protection of this specification. Therefore, the overall success rate, determinism, and efficiency of complex long-term tasks are improved.

[0214] Optionally, after writing the evaluation results and measured results back to the state experience map, the following steps are also included: Based on the evaluation results, the failure modes and boundary samples corresponding to the execution results are determined, and the failure modes and boundary samples are written into the state experience map; Based on failure modes and boundary samples, update the applicable conditions, failure modes and confidence levels of the corresponding target experiences in the state experience map, and make the failure modes and boundary samples written into the state experience map available for generating new verifiable check items when evaluating the execution results. In response to the next round of task objectives, candidate experiences are queried based on the updated state experience graph, and pruning or detours are performed on the candidate experiences corresponding to the failure modes to obtain updated candidate paths.

[0215] The failure mode corresponding to the execution result is the failure cause identified through evaluation that leads to the execution result not meeting the task objective requirements. This failure mode may be the same as or different from the original failure modes in the corresponding objective experience. Under the same circumstances, the evidence and confidence level of the original failure mode are updated accordingly; under different circumstances, it is recorded as a new failure mode in the objective experience. For example, in vehicle recording judgment tasks, a discrepancy between the category identified through evaluation and the established category vocabulary constitutes a failure mode corresponding to the execution result.

[0216] Boundary samples are those found during the evaluation that are near the decision boundaries of existing verifiable checks. They are prone to giving inconsistent evaluation sub-results across multiple evaluation units and are therefore used to supplement evaluation dimensions or verifiable checks. For example, in a background music generation task, a roll call sound effect where the rhythm point is near the upper or lower limit of the required duration; or in a vehicle recording decision task, a decision instance where the speaker's source is between the ambient sound in the vehicle and the background playback sound.

[0217] The next round of task objectives refers to new task objectives received after the completion of this run and subsequent evaluations. These objectives may be the same as or different from the current round's objectives. If the evaluation results of this round have been written back to the state experience graph, the corresponding candidate paths are obtained by querying the updated state experience graph. For example, after completing the accountability assessment of a batch of vehicle recordings, a task objective is received to perform accountability assessment on another batch of vehicle recordings.

[0218] Based on the evaluation results, the failure modes and boundary samples corresponding to the execution results can be determined in several ways. One option is to determine the failure modes corresponding to the execution results based on the verifiable checks that failed in each evaluation sub-result and their corresponding samples, and to identify the samples near the decision boundary as boundary samples. Another option is to compare the evaluation results with the failure modes recorded in the state experience map, confirm the matching failure modes as the failure modes corresponding to the execution results, and identify the samples not covered by existing failure modes as boundary samples. Yet another option is to input the evaluation results and execution results into an agent, which will then summarize the failure modes corresponding to the execution results and select the boundary samples. No further limitations are specified here.

[0219] Based on failure modes and boundary samples, the applicable conditions, failure modes, and confidence levels of the corresponding target experiences in the state experience map are updated. One possible approach is to add failure modes to the failure modes of the corresponding target experience and lower the confidence level of the target experience based on the evaluation results. Another possible approach is to narrow the applicable conditions of the corresponding target experience based on the boundary samples, so that the target experience is no longer directly reused on samples outside its applicable conditions. Yet another possible approach is to write the verifiable check items corresponding to the failure modes and boundary samples into the state experience map together and update the confidence level of the corresponding target experience to the level corresponding to the current evaluation results. No specific limitations are imposed here.

[0220] In response to the next round's task objective, candidate experiences are queried based on the updated state experience graph to obtain updated candidate paths. One possible approach is to use the current decideable state and the target decideable state corresponding to the next round's task objective to re-query candidate experiences in the updated state experience graph and combine them into candidate paths, so that the supplemented failure modes are bypassed during pruning. Another possible approach is to remove candidate paths containing recorded failure modes from the re-queried candidate paths, so that the updated failure modes directly affect the selection of candidate paths in the next round. Yet another possible approach is to project the updated state experience graph onto the next round's request, and have the agent re-query candidate experiences and combine them into candidate paths based on this projection. No further limitations are specified here.

[0221] For example, taking the judgment of vehicle recordings as an example, in the execution results output by the deterministic judgment process on the verification collection, some judgment records have categories that are inconsistent with the established category vocabulary. The evaluation results confirm that the failure mode of "inconsistent category name" was triggered in this run. At the same time, judgment instances where the speaker source is between the in-vehicle ambient sound and the background playback sound gave inconsistent evaluation sub-results among multiple evaluation units. This instance constitutes a boundary sample. The above failure modes and boundary samples are written into the state experience graph: for the target experience corresponding to the judgment stage, the failure mode confirmed in this run is added to its failure mode, and its confidence is lowered according to the evaluation results; at the same time, its applicable conditions are narrowed according to the boundary sample, so that this type of instance no longer directly uses the original judgment method. When the next batch of judgment tasks for vehicle recordings is received, the candidate experience is re-queried and the candidate path is combined according to the updated state experience graph. The candidate path containing the failure mode is removed during pruning, while the verifiable check items added for the boundary sample are included in this round of evaluation, so that the findings of this round of evaluation directly affect the path selection of the next run.

[0222] In this embodiment, by determining the failure modes and boundary samples corresponding to the execution results based on the evaluation results and writing them into the state experience graph, the findings of the evaluation side can be transformed into evidence-based experience records in the graph, rather than remaining at the conclusion of a single evaluation. By updating the applicable conditions, failure modes, and confidence levels of the corresponding target experience, subsequent queries and pruning can be performed based on the updated evidence, avoiding the repeated reference of exposed failure modes. By responding to the next round of task objectives by re-querying candidate experiences based on the updated state experience graph, the findings of the evaluation side can change the candidate paths for the next round of execution. This, together with the action of the execution side writing the evaluation results and measured results back into the state experience graph, forms a closed loop. Therefore, the execution side and the evaluation side mutually drive and jointly accumulate on the same state experience graph, enabling subsequent tasks to be carried out from a higher level of cognitive ability, further reducing the overhead of repeated exploration and verification.

[0223] See Figure 4 , Figure 4 A flowchart of an agent evaluation method provided in one embodiment of this specification is shown, including: Step 402: Obtain the execution result, task contract, and state experience graph. The state experience graph uses determineable states as nodes and verified target experiences as edges.

[0224] The execution result is the output of the agent after executing the task objective, and it is the object of this evaluation. In some optional embodiments, the execution result is the output of the deterministic process in the aforementioned agent operation method after executing the task objective. In other optional embodiments, the execution result is the output of the agent after executing the state transition task. For example, in the task of generating background music for e-commerce live-streaming short videos, the execution result is the generated background music audio that includes background music and scene sound effects, and is purely instrumental with no vocals.

[0225] A state-experience graph is a persistent cognitive structure of capabilities, with decideable states as nodes and verified target experiences as edges. It records the decideable states of the work object and the experiences used to transition from one decideable state to another. In this evaluation method, the state-experience graph serves as both a basis for querying existing failure modes and verification conclusions, and a carrier for the evaluation side to write back and share with the operation side. For example, a state-experience graph constructed and continuously updated for a background music generation task records the experience edges and failure modes corresponding to mixing, sound effect generation, and other stages.

[0226] To obtain the execution result, task contract, and state experience graph, one possible approach is to retrieve the execution result from the output of the agent's running method, obtain the task objective and acceptance criteria from the task contract, and read the constructed state experience graph. Another possible approach is to read the execution result from the storage medium or the runtime output directory and load the persistent state experience graph. Yet another possible approach is to receive the execution result from an external system and obtain the state experience graph corresponding to the task to which the execution result belongs. No further limitations are specified here.

[0227] For example, taking the background music generation task as an example, the execution result and task contract of the task are obtained. The execution result is the finished background music audio product generated by the agent for each e-commerce live-streaming short video, which includes background music and scene sound effects described by prompt words and has no human voice. The task contract records the task objectives and acceptance criteria of the task. At the same time, the state experience graph for the task and including the general layer is obtained. The graph records the failure modes confirmed in the past operation, such as "the duplication of mixing filter map labels caused the entire batch of finished products to be damaged", "the judge of the whole song missed short transient sound effects", and "the human voice screening tool falsely reported the electronic timbre", which serve as a reference for designing verifiable check items in this evaluation.

[0228] Step 404: Determine multiple evaluation dimensions based on the execution results and task contract, and convert each evaluation dimension into a verifiable check item.

[0229] Evaluation dimensions are different aspects considered when evaluating performance results. They characterize whether the performance results meet the task objectives from multiple, distinct perspectives, avoiding the use of a single, general score to mask specific shortcomings. For example, in a background music generation task, evaluation dimensions include four aspects: sound quality, sound effect chain, rhythmic timing, and absence of vocals.

[0230] Verifiable check items are those derived from evaluation dimensions, executed by the evaluation unit, and that provide evaluation sub-results. They have definite judgment methods and criteria, rather than relying on subjective descriptions. For example, a check item derived from the evaluation dimension of "no human voice" that uses a human voice screening tool to detect whether the finished audio contains human voice components.

[0231] Based on the execution results and task contract, multiple evaluation dimensions are determined, and each evaluation dimension is converted into verifiable check items. One possible approach is to determine multiple aspects to be examined in the execution results as evaluation dimensions according to the task objectives or task contract, and map each evaluation dimension to a verifiable check item with a defined judgment method. Another possible approach is to query a preset dimension table to obtain multiple evaluation dimensions based on the task type to which the execution results belong, and convert each evaluation dimension into a verifiable check item according to the preset dimension-check item mapping relationship. Yet another possible approach is to input the execution results into an agent, which then autonomously determines multiple evaluation dimensions and generates corresponding verifiable check items. No further limitations are specified here.

[0232] For example, the execution result is the generated background music audio product, which is evaluated across multiple dimensions: sound quality, sound effect chain, rhythmic timing, and the absence of vocals. Each of these evaluation dimensions is then converted into verifiable checks: the "sound quality" dimension is converted into a check for spectral analysis and distortion detection of the generated audio; the "sound effect chain" dimension is converted into a check for the presence of the tag-mark sound effect described by the prompt throughout the entire track; the "rhythmic timing" dimension is converted into a check for whether the timing of the tag-mark sound effect aligns with the rhythm and duration required by the prompt; and the "no vocals" dimension is converted into a check for the presence of vocal components in the generated audio using a vocal screening tool. Therefore, the previously general assessment of "quality of generation" is transformed into four independently executable and assessable checks.

[0233] In one optional embodiment, multiple evaluation dimensions can be determined from three sources: first, the pre-defined goals and acceptance criteria in the task contract, such as the evaluation dimension corresponding to the accuracy lower limit agreed upon in the acceptance criteria; second, the evaluation blind spots exposed by the actual execution results, including new failure types, boundary samples, and judgment discrepancies, which are supplemented as new evaluation dimensions in the collaborative self-evolution; and third, the evaluation dimensions corresponding to the reusable checks that have been frozen in the state experience graph. Furthermore, regardless of the source of the evaluation dimension, it must first be converted into a verifiable check item before it can be frozen into the evaluation process along with the evaluation results. Evaluation dimensions that cannot be converted into verifiable check items do not participate in the determination of the evaluation results.

[0234] Step 406: Perform verifiable checks using multiple evaluation units to obtain the evaluation sub-results for each evaluation unit.

[0235] An evaluation unit is a unit that performs verifiable checks and provides evaluation sub-results. Multiple evaluation units can perform the same set of verifiable checks, which can be implemented by deterministic procedures, dedicated classifiers, models, or manually. Examples include deterministic testing procedures for spectral and distortion analysis of finished audio, evaluation models for determining whether a name tag effect is on the chain, and voice screening tools for detecting human voice components.

[0236] Heterogeneous evaluation units are evaluation units that differ from the running generative model or other evaluation units in model family, training objective, input modality, or implementation mechanism. They are used to reduce the shared blind spots among multiple evaluation units. As one of multiple evaluation units, each unit performs verifiable checks and provides corresponding evaluation sub-results. Examples include multimodal evaluation models that differ from the audio generation model used to generate background music in model family, training objective, and input modality, and classifiers based on deterministic signal processing procedures that differ from the evaluation model in implementation mechanism.

[0237] The evaluation sub-result is the result given after a single evaluation unit performs verifiable checks, and the differences between multiple evaluation sub-results constitute discrepancies. For example, the evaluation model gives a "on the chain" or "not on the chain" conclusion for the "sound effect on the chain" check, and the voice screening tool gives a "contains voice components" or "does not contain voice components" conclusion for the "no voice" check.

[0238] Multiple evaluation units are used to execute verifiable checks separately, obtaining evaluation sub-results for each evaluation unit. One possible approach is to distribute each verifiable check to multiple evaluation units for parallel execution and collect the evaluation sub-results returned by each unit. Another possible approach is to sequentially assign each verifiable check to multiple evaluation units in a preset order, obtaining the evaluation sub-results for each unit. Yet another possible approach is to assign each verifiable check to multiple evaluation units for execution, and introduce checks prone to shared blind spots into heterogeneous evaluation units, obtaining evaluation sub-results for each evaluation unit, including those from the heterogeneous evaluation unit. No specific limitations are imposed here.

[0239] For example, the four verifiable checks mentioned above are performed by multiple evaluation units: a sound quality detection program based on deterministic signal processing is used to perform the sound quality check; a full-track evaluation model is used to perform the sound effect on-chain check; a rhythm analysis program is used to perform the rhythm placement check; and a voice screening tool is used to perform the voiceless check. The full-track evaluation model and the audio generation model used to generate the background music differ in model family, training objective, and input modality, constituting heterogeneous evaluation units; the sound quality detection program and the voice screening tool differ from the evaluation model in their implementation mechanisms, also constituting heterogeneous evaluation units. Each evaluation unit provides an evaluation sub-result. For example, the full-track judge provides an evaluation sub-result of "no named sound effects detected" for a certain finished product, the rhythm analysis program provides an evaluation sub-result of "rhythm placement aligned," and the voice screening tool provides an evaluation sub-result of "vocal components detected."

[0240] Step 408: Determine the evaluation result based on each evaluation sub-result, and if there is a discrepancy among the evaluation sub-results, route the discrepancy to deterministic verification, evidence probe or manual adjudication according to whether the discrepancy corresponds to an external truth value, and obtain the adjudication result of the discrepancy.

[0241] The evaluation result is determined by combining the results of multiple evaluation sub-results, reflecting whether the execution results meet the task objectives. For example, the conclusion determined by combining the evaluation sub-results of each verifiable check item whether the batch of background music products meets the delivery requirements.

[0242] Discrepancy occurs when multiple evaluation units give inconsistent evaluation sub-results for the same verifiable check item, indicating the existence of evaluation blind spots or bias in a particular evaluation unit. For example, for the "sound effect on the chain" check item, the full-track evaluation model gives an evaluation sub-result of "not on the chain," while the single-event isolation detection program gives an evaluation sub-result of "on the chain."

[0243] External truth values ​​are objective bases for determining the conclusions to which disagreements point, and are available independently of the evaluation unit. Their existence or absence determines how the disagreements should be routed. For example, objective conclusions obtained by replaying the generation process and directly checking whether the sound effects fall into the final product, or conclusions drawn by manual annotations on disputed instances.

[0244] Deterministic verification is a process of verifying discrepancies in a deterministic manner to obtain a decision when there is an external truth value for the discrepancy. For example, a deterministic procedure can be used to replay the generation and mixing process of the sound effect to check whether it actually falls into the final product.

[0245] Evidence probes are used in the divergent routing process to supplement divergent points with reproducible evidence to assist in obtaining a ruling. Examples include probes that capture a narrow audio window corresponding to the disputed sound effect and re-evaluate it multiple times within that window, or blind A / B testing implemented by scrambling labels.

[0246] Human adjudication is a process in which disagreements are resolved by humans during the routing of disputed audio. For example, disputed audio may be submitted to humans for listening and identification to determine whether it contains human voices.

[0247] The ruling is a conclusion reached after deterministic verification, evidence probes, or manual adjudication of a disagreement, and it is used to determine the evaluation result. For example, the conclusion that the named sound effect is actually on the chain after multiple rounds of voting in a narrow window and blind A / B testing.

[0248] The evaluation result is determined based on each evaluation sub-result. One possible approach is to aggregate the evaluation sub-results according to a preset aggregation rule. Another possible approach is to directly determine the evaluation result when the evaluation sub-results are consistent, and to first obtain a decision through a divergence route when the evaluation sub-results are divergent, and then determine the evaluation result accordingly. Yet another possible approach is to weight each evaluation sub-result according to the weight corresponding to its evaluation unit to obtain the evaluation result. No specific limitations are imposed here.

[0249] When discrepancies exist among the evaluation sub-results, the discrepancies are routed to deterministic verification, evidence probes, or manual adjudication based on whether they correspond to an external truth value. One possible approach is: if the discrepancy corresponds to an external truth value and can be determined deterministically, it is routed to deterministic verification; if the discrepancy does not correspond to an external truth value but can be distinguished by supplementing reproducible evidence, it is routed to evidence probes; if the discrepancy cannot be resolved by deterministic verification or evidence probes, it is routed to manual adjudication. Another possible approach is: if the conclusion corresponding to the discrepancy can be confirmed by replaying the execution process, it is routed to deterministic verification; if the discrepancy requires supplementary evidence on a sample or narrow window, it is routed to evidence probes; if the discrepancy involves subjective judgment, it is routed to manual adjudication. Yet another possible approach is: based on whether the check item corresponding to the discrepancy is a falsifiable check item, falsifiable discrepancies are routed to deterministic verification, discrepancies requiring supplementary evidence are routed to evidence probes, and other discrepancies are routed to manual adjudication. No further limitations are imposed here.

[0250] For example, regarding the verifiable check item "sound effect on the chain," the full-track evaluation model gives an evaluation sub-result of "no detected named sound effect," while the detection program based on single-event isolation gives an evaluation sub-result of "the sound effect is already on the chain." This discrepancy constitutes a disagreement. Since the conclusion corresponding to this disagreement can be objectively determined through playback generation and mixing processes, meaning this disagreement corresponds to an external truth value, the disagreement is routed to an evidence probe: a narrow audio window corresponding to the named sound effect is captured, and within this window, the evaluation model performs multiple rounds of re-judgment. A blind A / B test with scrambled labels is used to distinguish between the two disputed instances, thereby collecting reproducible evidence that can differentiate between "on the chain" and "not on the chain." Based on this evidence, it is confirmed that the short transient sound effect has actually been included in the final product, and the original "not on the chain" conclusion was due to the full-track judge missing the short transient sound effect. Therefore, the two false alarms are ruled as false negatives, resulting in the disagreement's ruling. Combining the evaluation sub-results and this ruling, the evaluation result of this execution is determined.

[0251] Step 410: Freeze the verifiable check items corresponding to the evaluation results into the evaluation process, and write the evaluation results back to the state experience map.

[0252] The evaluation process is a deterministic, repeatable process obtained by freezing the verifiable check items corresponding to the evaluation results. It solidifies the check items, judgment thresholds, call order, and evaluation units used to ensure that the evaluation criteria remain consistent across multiple runs. For example, the evaluation script or directed acyclic graph obtained by solidifying the set of check items "sound quality detection - sound effect on-chain detection - rhythm landing point detection - no voice detection" along with its judgment thresholds and evaluation units used.

[0253] The verifiable checks corresponding to the evaluation results are frozen into evaluation processes, and the evaluation results are written back to the state experience graph. One possible approach is to compile the verifiable checks and their decision methods corresponding to the evaluation results into a deterministic script or a directed acyclic graph to obtain the evaluation process, and then write the evaluation results into the corresponding experience edges and state nodes in the state experience graph. Another possible approach is to solidify the verifiable checks corresponding to the evaluation results into evaluation processes and record their version numbers and evidence sources, while simultaneously adding the evaluation results as new experience evidence to the state experience graph to update the failure modes and evidence sources of the corresponding experience edges. Yet another possible approach is to freeze the corresponding verifiable checks into evaluation processes when the evaluation results indicate that the execution results meet the task objective requirements, and write the evaluation results along with the corresponding evidence sources back to the state experience graph. No further limitations are specified here.

[0254] For example, the four verifiable check items corresponding to the current evaluation results—"sound quality detection, sound effect on-chain detection, rhythmic landing detection, and no-voice detection"—along with their judgment thresholds, calling order, and evaluation units used, are frozen into a repeatable evaluation process. The version number of this evaluation process and the source of the evidence are recorded, allowing subsequent evaluations of similar tasks to directly reuse this process without redesign, thus ensuring consistency in evaluation criteria across multiple runs. Simultaneously, the evaluation results are written back into the state experience graph: conclusions confirmed during the evaluation, such as "the generated model does not follow the precise rhythm and duration of the named sound effects," "the judge missed short transient sound effects throughout the song," "the voice screening tool falsely reports electronic timbre," and "duplicate mixing filter map labels cause damage to the entire batch of finished products," are written into the failure modes of the corresponding experience edges. The run identifier, timestamp, and sample references used in this evaluation are also written as sources of evidence. Therefore, the findings from the evaluation side flow back into the state experience graph, allowing subsequent runs to identify and bypass the aforementioned failure modes when querying candidate paths and performing pruning.

[0255] In the embodiments of this specification, by obtaining execution results on the evaluation side and using a state experience graph as a shared and persistent cognitive foundation for both the evaluation and operation sides, evaluation findings can be embedded in the same graph as operational experience. By determining multiple evaluation dimensions based on the execution results and converting each evaluation dimension into verifiable check items, subjective judgments of the execution results are transformed into determinate and reproducible checks, avoiding evaluations that remain at a general scoring level without being able to pinpoint specific defects. By utilizing multiple evaluation units to execute verifiable check items separately, and introducing heterogeneous evaluation units that differ from the running generative model or other evaluation units in model family, training objectives, input modalities, or implementation mechanisms, the interaction between evaluation units is utilized. Differences reduce shared blind spots and prevent systematic biases of a single evaluation unit from being directly taken as conclusions; by not eliminating discrepancies through voting or averaging when there are disagreements among the evaluation sub-results, but instead routing them to deterministic verification, evidence probes, or manual adjudication based on whether the discrepancy corresponds to an external truth value, discrepancies become a source of new evidence and new checks rather than masked noise, preserving a few but potentially correct anomalous signals; by freezing the verifiable checks corresponding to the evaluation results into the evaluation process, the evaluation criteria remain consistent across multiple runs and can be directly reused; by writing the evaluation results back to the state experience map, the failure modes and evidence confirmed by the evaluation side can feed back into the candidate path selection and pruning on the operation side.

[0256] Optionally, the multiple evaluation units include heterogeneous evaluation units, which differ from the model that generates the execution results in terms of model family, training objective, input modality, or implementation mechanism. Verifiable checks are performed using multiple evaluation units to obtain evaluation sub-results for each evaluation unit, including: Perform verifiable checks using heterogeneous evaluation units to obtain the evaluation sub-results corresponding to the heterogeneous evaluation units.

[0257] Model family, training objective, input modality, and implementation mechanism are four aspects used to determine whether an evaluation unit is different from the model that generates the execution result: Model family refers to the type of model on which the evaluation unit is based, such as generative models and discriminative models belonging to different model families; Training objective refers to the goal that the evaluation unit optimizes during training, such as generating audio and determining whether the audio meets the requirements, which are different training objectives; Input modality refers to the type of input received by the evaluation unit, such as receiving only audio and receiving both audio and text prompts, which are different input modalities; Implementation mechanism refers to the way the evaluation unit is implemented, such as implementation based on model inference and implementation based on deterministic signal processing programs, which are different implementation mechanisms.

[0258] To obtain evaluation sub-results for heterogeneous evaluation units by executing verifiable checks, one option is to issue the same verifiable check to the heterogeneous evaluation unit and the other evaluation units, execute them separately, and collect their respective evaluation sub-results. Another option is to prioritize the execution of verifiable checks that are prone to shared blind spots by the heterogeneous evaluation unit, which then provides the evaluation sub-results, before the other evaluation units execute the same verifiable check. Yet another option is to record the model family, training objective, input modality, and implementation mechanism of each evaluation unit in the state experience graph, and select an evaluation unit that is different from the model that generated the execution result when executing the verifiable check. No further limitations are specified here.

[0259] For example, continuing from the previous example, the multiple evaluation units include heterogeneous evaluation units: the full-track evaluation model and the audio generation model used to generate the background music differ in model family, training objective, and input modality, thus constituting a heterogeneous evaluation unit. This unit performs the verifiable check "sound effects on the chain" and provides an evaluation sub-result. The sound quality detection program, implemented based on a deterministic signal processing program, differs from the aforementioned evaluation model in its implementation mechanism, also constituting a heterogeneous evaluation unit. This unit performs the verifiable check "sound quality" and provides an evaluation sub-result. After each of these heterogeneous evaluation units performs the verifiable check, they obtain their respective corresponding evaluation sub-results. For example, the full-track evaluation model might provide an evaluation sub-result of "no named sound effects detected" for a given track, while the sound quality detection program might provide an evaluation sub-result of spectral distortion in the given track.

[0260] In the embodiments of this specification, by limiting the multiple evaluation units to include heterogeneous evaluation units that differ from the model generating the execution result in terms of model family, training objective, input modality, or implementation mechanism, the evaluation units performing the same verifiable check item do not originate from the same model, thereby reducing the shared blind spots among multiple evaluation units. By utilizing heterogeneous evaluation units to perform verifiable checks and obtain their corresponding evaluation sub-results, the evaluation results are based on independent judgments from different sources, rather than repeated judgments of different checks by the same model. This also ensures that the discrepancies faced by subsequent divergent routing come from real differences in judgments. Therefore, the evaluation results reflect the execution results more comprehensively, further improving the accuracy, reproducibility, and driving ability of evaluation findings to improve operation.

[0261] Optionally, after step 408, the method further includes: If no corresponding external truth value is found for the disagreement, the disagreement is retained as a disputed state; New inspection items and new evidence probes are generated based on the disputed state, and the disputed state, new inspection items, and new evidence probes are written into the state experience graph.

[0262] A disputed state is a decidable state that is retained when a disagreement has not yet yielded a corresponding external truth value. It is used to indicate that the disagreement cannot be determined yet and to trigger the generation of new checks and new evidence probes, rather than being forcibly categorized as pass or fail. For example, in a background music generation task, the "whether a certain type of sparse transient sound effect is on the chain" state is retained as disputed when there is a lack of external truth values ​​to determine it and it cannot be distinguished by existing evidence.

[0263] The newly added inspection items are verifiable inspection items generated based on the disputed state to fill the evaluation blind spots. After being written into the state experience map, they can be directly reused in subsequent evaluations. For example, the two-layer sound effect audit inspection items "full bus cross-correlation" and "single event isolation" were added to fill the evaluation blind spot of "the judge missed short transient sound effects in the whole piece".

[0264] The newly added evidence probes are generated based on the disputed state and are used to collect evidence needed to distinguish different judgments. After being written into the state experience graph, they can be directly called in subsequent similar disputes. For example, a narrow-window probe is added to distinguish between "on the chain" and "not on the chain" in this disputed instance, which captures a narrow audio window and performs multiple rounds of re-judgment.

[0265] When a disagreement cannot be resolved by obtaining a corresponding external truth value, it can be left as a disputed state. One possible approach is to mark and retain disagreements that cannot be resolved by deterministic verification or evidence probes as disputed states. Another approach is to associate the check item corresponding to the disagreement with the sample identifier and record it as a disputed state, ensuring that this disputed state is neither judged as pass nor fail in this evaluation. Yet another possible approach is to mark the identifiable state corresponding to the disagreement as a disputed state and record the check items involved in this disputed state and the evaluation sub-results of each evaluation unit in the state experience graph. No further limitations are specified here.

[0266] Based on the disputed state, new inspection items and new evidence probes are generated. One possible approach is to generate new inspection items and new evidence probes that can distinguish the different judgments pointed to by the dispute, based on the inspection items involved in the disputed state and the results of each evaluation sub-result. Another possible approach is to add inspection items specifically for detecting the evaluation blind spots corresponding to the disputed state, and add evidence probes for collecting discriminative evidence on the samples. Yet another possible approach is to use the samples corresponding to the disputed state as boundary samples, and design inspection items that can distinguish competing hypotheses and replayable evidence probes to obtain new inspection items and new evidence probes. No specific limitations are imposed here.

[0267] Incorporating disputed states, new inspection items, and new evidence probes into the state experience graph can be approached in several ways. One option is to write the disputed state, new inspection items, and new evidence probes together into the corresponding experience edges and state nodes in the state experience graph, allowing them to be queried and reused in subsequent evaluations. Another option is to append the disputed state, new inspection items, and new evidence probes as new experience records to the state experience graph, and associate the new inspection items with the corresponding evaluation process. A third option is to write the disputed state into the state experience graph, and then associate the new inspection items and new evidence probes with this disputed state and write them together, allowing the disputed state to be re-adjudicated when external truth values ​​or new evidence are subsequently obtained. No specific limitations are imposed here.

[0268] For example, for a certain type of sparse transient sound effect, there is a discrepancy between the evaluation sub-results given by the full-track evaluation model and the single-event isolation detection program. This discrepancy cannot be determined through the playback generation process, nor can a corresponding external truth value be obtained. Therefore, this discrepancy is retained as a disputed state, and the relevant check item is recorded as "sound effect on the chain," and the relevant sample is the finished product instance corresponding to this type of sparse transient sound effect. This evaluation does not make a pass or fail judgment on it. Based on this disputed state, new check items and new evidence probes are generated: the new check item is a two-layer "full bus cross-correlation" and "single-event isolation" sound effect on-chain audit, that is, detecting whether the overall sound effect falls into the finished product using cross-correlation on the full mixing bus, and isolating and replaying individual sound effect events to exclude the obscuring of the sound effect by other audio tracks; the new evidence probe is a narrow window probe, that is, capturing the narrow audio window corresponding to the sound effect and re-judging multiple times within this window to collect evidence that can distinguish between "on the chain" and "not on the chain." Write the disputed state, new check items, and new evidence probes into the state experience graph, so that the disputed state and the new check items and new evidence probes it triggers become evaluation-side experiences in the graph that can be queried and called later: subsequent similar tasks can directly reuse the new check items and new evidence probes to cover the on-chain determination of this type of sparse transient sound effects during evaluation, and make a new decision based on the new external truth value or evidence obtained in the subsequent disputed state.

[0269] In this embodiment, when a disagreement fails to yield a corresponding external truth value, it is retained as a disputed state, rather than forcibly eliminated by majority vote or average. This preserves a few potentially correct anomalous signals, preventing blind spots in the evaluation from being masked or erroneous conclusions from becoming reusable experience. By generating new check items and new evidence probes based on the disputed state, the evaluation blind spot can be explicitly converted into executable checks and replayable evidence collection methods in the next round of evaluation, thereby driving the growth of the evaluation side's own capabilities. By writing the disputed state, new check items, and new evidence probes into the state experience graph, the evaluation side's discoveries and the operation side's experiences are deposited on the same graph. Subsequent operations can identify and bypass corresponding failure modes based on the disputed state, and subsequent evaluations can directly reuse the new check items and new evidence probes, and make a new decision when new external truth values ​​or evidence are obtained in the disputed state. Therefore, the operation side and the evaluation side form a mutually driving and co-depositing collaborative self-evolutionary mechanism on the same state experience graph, enabling the system to carry out subsequent tasks with a higher cognitive starting point after multiple runs, continuously reducing the overhead of repeated exploration and verification.

[0270] Taking the background music generation task as an example, the final frozen solution achieved a score of 0.75 in the empirical data collection, which is similar to the human solution (0.762), and the manual input was reduced from about 7 person-days to about 1 person-day. The above values ​​are only examples of this embodiment and do not constitute a limitation on the scope of protection of this specification. Therefore, the operation side and the evaluation side drive each other and jointly accumulate on the same state experience map, and the accuracy, reproducibility and driving ability of the evaluation are improved as a whole.

[0271] Corresponding to the embodiments of the above-described agent experience construction method, agent operation method, and agent evaluation method, Figure 5 This document illustrates a flowchart of a bidirectional self-evolutionary process for an agent operation method and an agent evaluation method provided in one embodiment of this specification. Figure 5 As shown: The agent operation method forms an operation design loop, which includes deterministic processes such as determining decidable states, generating candidate paths, pruning candidate paths, directional probes, and freezing. The agent evaluation method forms an evaluation design loop, which includes evaluation dimension verifiability, heterogeneous evaluation, divergent routing, adding new check items and new evidence probes, and freezing. The execution results, failure modes, and execution costs generated by the operation design loop constitute the operation evidence on the operation side, while the failure types, boundary samples, and divergences generated by the evaluation design loop constitute the findings on the evaluation side. The operation evidence on the operation side is used to expose evaluation blind spots, and the findings on the evaluation side are used to drive the improvement of the operation path. Together, they are written back into the state experience graph and provide a higher-level cognitive starting point for subsequent tasks.

[0272] Corresponding to the embodiments of the above-described agent experience construction method, agent operation method, and agent evaluation method, Figure 6 The diagram illustrates a flowchart of an agent experience construction method, an agent operation method, and an agent evaluation method according to an embodiment of this specification. Figure 6 As shown: The agent experience construction method, agent operation method, and agent evaluation method include a basic capability layer, an agent working layer, and an experience accumulation layer. The basic capability layer provides tool interface definitions, skill module files, and graph projection blocks. Tool interface definitions are interface definitions for general execution primitives. Skill module files are used to store procedural schemes. Graph projection blocks are compact views generated based on the current content of the state experience graph and the position of the current request in the session. The basic capability layer provides candidate experiences to the agent working layer. The agent working layer carries the operation design loop and the evaluation design loop. The operation design loop includes generating candidate paths, pruning candidate paths, directional probes, and the winning path. The evaluation design loop includes verifiable checks, heterogeneous evaluation, branching routes, and evaluation results. The operation design loop and the evaluation design loop promote each other. The experience accumulation layer freezes the winning path into a deterministic process, freezes the verifiable checks into an evaluation process, and updates the state experience graph. The state experience graph uses decideable states as nodes and target experiences as edges, where experiences belong to the task layer and the general layer.

[0273] The embodiments of the above-mentioned agent experience construction method, agent operation method, and agent evaluation method unify the registration of reusable knowledge in tool interface definitions, skill module files, call records, and historical execution trajectories as experience edges with starting state, target state, applicable conditions, called tools or skills, verification probes, test results, confidence level, and evidence source. The state experience graph is constructed with the decidable state as the node, which unifies different experience carriers. This scheme does not negate existing carriers such as tool interface definitions, skill module files, workflows, or memories. Instead, it registers verifiable solution fragments as experience edges with source state, target state, conditions, and evidence, so that complete skill module files can continue to be reused and local capabilities can be recombined across tasks.

[0274] In this state experience map, the state is determined by the state checker according to the state morphology definition. The experience distinguishes between observations, hypotheses, verified and rejected conclusions, and retains verification probes and evidence sources. Therefore, path queries, condition filtering, confidence updates and failure detours can be performed to form searchable and verifiable capability relationships.

[0275] Since the implementation only retains general execution primitives (including basic execution primitives and model primitives) and graph interfaces, the differences between tasks are expressed by the procedural schemes or recipes on the experience side saved in the skill module files. Therefore, the growth of task-specific interfaces is controlled, and the need to add special tools just to solidify a single operation process is reduced.

[0276] The exploration during the design phase focuses on the generation of candidate paths and the verification of directional probes, with costs controlled by small-sample probes. During the execution phase, the winning path is frozen into a deterministic process. The above effect comes from the combination of determinable states, target experience, probe evidence, and frozen steps, rather than just advocating the ability to generate scripts, thus taking into account both open design and stable execution.

[0277] The operation side and the evaluation side read and write the same state experience map. Operation failure can trigger the evaluation blind spot repair. Evaluation findings can change the candidate path for the next round of operation, so that subsequent tasks can read the updated capability knowledge, thereby connecting the experience updates of operation and evaluation.

[0278] The assessment side introduces heterogeneous assessment units and performs divergence routing, transforming divergences into new evidence, new inspection items, disputed states, or necessary rulings, without using majority votes to cover up minority but potentially correct abnormal signals, thereby preserving and utilizing assessment divergences.

[0279] In this implementation, the current graph projection block is regenerated for each request and is not written to the session's message history. This allows the experience just written to the graph to be read in the next call and avoids the accumulation of multiple graph copies in the history, thus ensuring that the dynamic graph writing is visible in subsequent requests. This is a specific context engineering implementation and is not a common defect of other frameworks.

[0280] The aforementioned combined mechanism reduces full-scale trial and error without evidence, and improves the reusability of the state transition scheme, the certainty of formal execution, and auditability. In a low-intervention autonomous spiral iteration of a certain vehicle recording responsibility task, the final freezing scheme achieved a precision (P) of 0.857, a recall (R) of 0.818, and an F1 score of 0.837 (True Positive (TP) = 18, False Positive (FP) = 3, False Negative (FN) = 4) in the verification collection, meeting the acceptance threshold that both precision and recall are not lower than 0.8. Compared with the first version, P = 0.286, R = 0.500, F1 = 0.364 (TP = 2, FP = 5, FN = 2), P improved by 0.571, R improved by 0.318, and F1 improved by 0.473; this indicator only represents this embodiment.

[0281] The key technological innovation of this solution lies in: First, the capability cognition representation of the state experience graph: taking the determineable state as the node and the state transition experience with recipe, applicable conditions, execution cost, failure mode, confidence level, verification probe and evidence source as the edge, the reusable knowledge in the tool interface definition, skill module file, call record, historical execution trajectory and evaluation evidence is unified into a queryable, verifiable and evolvable graph structure, while retaining its original carrier and evidence source; Second, the collaborative self-evolution mechanism of the shared map of operation and evaluation: during operation, evaluation blind spots are discovered, and evaluation discoveries drive changes in the operation path. Both parties write the verification results back to the same state experience map, so that the system accumulates reusable capability knowledge as it runs. Third, the path selection and freezing mechanism based on graph evidence: during the design phase, candidate paths are selected based on state connection, applicable conditions, execution costs, failure modes and directional probe results. During the execution phase, the verified winning path is frozen as a deterministic process. Its protection focuses on the combined relationship with the state experience graph and the operation-evaluation write-back, rather than advocating the process solidification capability alone. Fourth, an evidence routing mechanism for assessing disagreements: based on whether the disagreement can be falsified by external truth values, the disagreement is routed to deterministic verification, directional probes, manual adjudication, or dispute retention, and the adjudication is solidified into a reusable check for the future. Fifth, dynamic graph projection mechanism during request: The latest graph is rendered as a one-time request tail projection, which separates the stored state from the online context of the model, allowing the agent to see the newly written experience immediately, while avoiding the repeated accumulation of old graphs with the session history. Sixth, a hierarchical mechanism for tools, skills, and experience graphs: general execution primitives provide basic execution capabilities, skill module files store candidate procedural solutions, and experience edges record verified state transitions and their evidence. The three are hierarchically linked, so that capability accumulation does not depend on continuously adding task-specific tools, nor does it require discarding the existing skill module file system.

[0282] Corresponding to the embodiments of the above-described agent operation method and agent evaluation method, Figure 7 This specification shows a schematic diagram of the structure of an intelligent agent system according to an embodiment of the present specification. The intelligent agent system includes: The basic capability layer 702 is used to provide general execution primitives, skill module files, and state experience graphs; The agent working layer 704 is used to execute the steps of the above-mentioned agent experience construction method, agent operation method or agent evaluation method; The experience accumulation layer 706 is used to freeze the winning path determined by the agent's working layer into a deterministic process and update the state experience graph.

[0283] The basic capability layer 702 is a layer in the intelligent agent system that provides general execution primitives, skill module files and state experience maps. As a capability cognition foundation that is persistent across sessions and runs, it provides the intelligent agent working layer 704 with executable basic capabilities, referable procedural solutions and queryable experience cognition, so that the capability accumulation is not lost with the end of a single run.

[0284] The agent working layer 704 is a layer in the agent system used to execute the steps of the aforementioned agent experience construction method, agent operation method, or agent evaluation method. It is the processing layer for the agent to actually execute the task objectives and evaluation, and is responsible for querying candidate paths, executing directional probes, determining and executing the winning path, evaluating the execution results, and performing branching routes.

[0285] The experience accumulation layer 706 is a layer in the intelligent agent system used to freeze the winning path determined by the intelligent agent working layer 704 into a deterministic process and update the state experience graph. It solidifies the verification conclusions obtained during the design phase into products that can be directly called during the execution phase, and makes the discoveries from the operation side and the evaluation side continuously flow back to the graph.

[0286] For example, the intelligent agent system includes a basic capability layer 702, an intelligent agent working layer 704, and an experience accumulation layer 706. The basic capability layer 702 provides basic execution primitives such as command execution, file reading, file writing, and file editing, as well as model primitives such as multimodal understanding and language model invocation. It provides skill module files that record the speech transcription and speaker separation process and violation judgment category mapping rules, and provides a state experience graph for the task that includes a task layer and a general layer. This graph uses "pending processing vehicle recording batch", "transcription with speaker timestamp formed", and "order-level judgment formed" as nodes, and the verified target experience obtained from the former two as edges. The steps of the agent operation method executed by the agent working layer 704 are as follows: Obtain the state experience graph and task objective; determine the current decisionable state corresponding to the task objective as "pending processing of vehicle recording batches" and the target decisionable state as "order-level decision formed"; determine from the state experience graph a first candidate experience starting from the current decisionable state (its target state is "transcription with speaker timestamp formed") and a second candidate experience starting from the target state of the first candidate experience (its target state is "order-level decision formed"); combine the first and second candidate experiences according to their state connection relationships to obtain multiple candidate paths, and based on each path... The applicable conditions, execution costs, and failure modes of the candidate experiences included in the candidate paths are pruned; directional probes are executed on the candidate paths, that is, a preset number of samples are determined from the real recording data corresponding to the candidate path to obtain a sample subset, and the state transition in the candidate path is executed using the sample subset and the test results (including transcription coverage, source determination accuracy, and category consistency rate) are collected to determine the winning path, and the confidence of the candidate experiences included in the candidate path is updated based on the test results; then the winning path is frozen as a deterministic process and the task objective is executed to obtain the execution result, that is, the violation determination result of each order with category, time interval, speaker, and evidence text. The agent working layer 704 also performs the steps of the agent evaluation method: based on the execution result, it determines multiple evaluation dimensions and converts each evaluation dimension into verifiable check items. It uses multiple evaluation units (including heterogeneous evaluation units that are different from the running generative model in terms of model family, training objectives, input modalities, or implementation mechanisms) to perform the verifiable check items respectively, obtains the evaluation sub-results corresponding to each evaluation unit, and in the case of discrepancies among the evaluation sub-results, it routes the discrepancies to deterministic verification, evidence probes, or manual adjudication according to whether the discrepancies correspond to external truth values, obtains the adjudication results of the discrepancies, and determines the evaluation result accordingly.In addition, the agent working layer 704 also executes the steps of the agent experience construction method: the initial experience is obtained by normalizing the above call records and historical execution trajectories, the verifiable experience is determined by matching the current decidable state with the target decidable state, and the verification probe is executed to collect the actual test results. If the actual test results meet the preset evaluation criteria, the target experience is generated and the target experience is written as a new edge into the state experience graph. The experience accumulation layer 706 freezes the winning path determined by the agent working layer 704 into a deterministic process, that is, it solidifies the judgment script or directed acyclic graph of overlapping slices, speech transcription and speaker separation, and category deterministic mapping, and records the version number of the deterministic process and the source of the evidence on which it is based. At the same time, the experience accumulation layer 706 writes the actual test results, execution results and evaluation results of this run back to the state experience graph, and updates the confidence, failure mode and source of evidence of the corresponding experience edges accordingly. It also updates the verified experience that has been verified on the heterogeneous task of generating background music for e-commerce live streaming short videos from the task layer to the general layer, so that different subsequent tasks can directly query and reuse this general experience.

[0287] In the embodiments of this specification, by dividing the agent system into a basic capability layer, an agent working layer, and an experience accumulation layer, the persistent capability cognition foundation composed of general execution primitives, skill module files, and state experience graphs is decoupled from the processing layer that handles the agent's actual task execution objectives and evaluation results. Capability cognition is no longer lost after a single run, and there is no need to add dedicated tools or interfaces for each specific run. Through the steps of the agent's operating method executed by the agent working layer, the querying, combination, pruning, and directional probe verification of candidate paths are all performed on the accumulated state experience graph. Path selection is based on reproducible verification evidence, rather than blindly trying and failing on the complete running process. Through the steps of the agent's evaluation method executed by the agent working layer, the evaluation dimensions are... The evaluation process transforms the results into verifiable checks, which are then executed by multiple evaluation units. When there are discrepancies in the evaluation results, the process routes to deterministic verification, evidence probes, or manual adjudication based on whether the discrepancy corresponds to an external truth value. This avoids masking discrepancies with voting or averaging, preserves a few potentially correct abnormal signals, and drives the filling of evaluation blind spots. By freezing the winning path into a deterministic process and updating the state experience graph through the experience accumulation layer, the exploration results during the design phase are solidified into deterministic products that can be directly invoked during the execution phase and no longer contain open agent decisions. At the same time, the measured results and execution results on the operation side are read and written together with the evaluation results, disputed states, new checks, and new evidence probes on the evaluation side, forming a collaborative self-evolutionary mechanism in which the operation side and the evaluation side drive each other and jointly accumulate data.

[0288] Taking vehicle-mounted audio recording for liability assessment as an example, the final freezing solution achieved a precision (P) of 0.857, a recall (R) of 0.818, and an F1 score of 0.837 (True Positive (TP) = 18, False Positive (FP) = 3, and False Negative (FN) = 4) in the verification and collection process. This meets the acceptance threshold that both precision and recall should not be lower than 0.8. Compared with the first version, P = 0.286, R = 0.500, and F1 = 0.364, this represents a significant improvement, and the manual input has also been reduced from about 5 person-days to about 0.5 person-days.

[0289] Taking the background music generation task as an example, the final frozen solution achieved a score of 0.75, which is similar to the human solution (0.762), and the manual input was reduced from about 7 person-days to about 1 person-day; the above values ​​are only examples of this embodiment and do not constitute a limitation on the scope of protection of this specification.

[0290] As a result, the reusability and transferability of experience, the determinism and auditability of execution period, the reproducibility of evaluation, and the driving force for operational improvement are all enhanced in the use of intelligent agent systems in complex, long-term and cross-task applications, thereby improving the success rate and efficiency of intelligent agents in complex long-term tasks.

[0291] Figure 8 This specification illustrates a structural block diagram of a computing device according to one embodiment. The components of the computing device 800 include, but are not limited to, a memory 810 and a processor 820. The processor 820 is connected to the memory 810 via a bus 830, and a database 850 is used to store data.

[0292] The computing device 800 also includes an access device 840, which enables the computing device 800 to communicate via one or more networks 860. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 840 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0293] In one embodiment of this specification, the above-described components of the computing device 800 and Figure 8 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 8 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0294] The computing device 800 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 800 can also be a mobile or stationary server.

[0295] The processor 820 is used to execute the following computer program / instruction, which, when executed by the processor, implements the steps of the above-mentioned agent experience construction method, agent operation method, or agent evaluation method.

[0296] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device belongs to the same concept as the technical solutions of the above-mentioned agent experience construction method, agent operation method, and agent evaluation method. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solutions of the above-mentioned agent experience construction method, agent operation method, or agent evaluation method.

[0297] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described agent experience construction method, agent operation method, or agent evaluation method.

[0298] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solutions of the above-described agent experience construction method, agent operation method, and agent evaluation method. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solutions of the above-described agent experience construction method, agent operation method, or agent evaluation method.

[0299] An embodiment of this specification also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described agent experience construction method, agent operation method, or agent evaluation method.

[0300] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product belongs to the same concept as the technical solutions of the above-mentioned agent experience construction method, agent operation method, and agent evaluation method. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solutions of the above-mentioned agent experience construction method, agent operation method, or agent evaluation method.

[0301] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0302] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0303] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0304] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0305] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for constructing an agent's experience, comprising: Obtain the agent's tool interface definition, skill module files, call records, and historical execution trajectory; The tool interface definition, the skill module file, the call record, and the historical execution trajectory are uniformly extracted and normalized to obtain multiple initial experiences; Based on the current determineable state and the determineable state of the target corresponding to the task objective, verifiable experience is determined from the multiple initial experiences. The intelligent agent is invoked to perform a state transition task between the current determineable state and the target determineable state according to the verifiable experience, thereby obtaining the target experience that has been verified and confirmed. A state experience graph is constructed using the determineable states as nodes and the target experiences as edges.

2. The method according to claim 1, wherein the current determinate state and the target determinate state are obtained by a state checker judging the working object of the agent, and the state checker is used to determine whether the working object satisfies the state form definition; The initial experience includes input state, output state, applicable conditions, execution cost, and failure mode, and the confidence level of the initial experience is a hypothesis level; the verifiable experience includes starting state, target state, applicable conditions, tools or skills invoked, verification probes, test results, confidence level, and source of evidence, and the confidence level of the verifiable experience includes hypothesis level, provisional level, verified level, and rejected level.

3. The method according to claim 2, wherein the unified extraction and normalization of the tool interface definition, the skill module file, the call record, and the historical execution trajectory to obtain multiple initial experiences includes: Parse the tool interface definition to extract the input and output states; Parse the skill module file to extract applicable conditions and failure modes; Analyze the call records and historical execution trajectories to extract execution costs and verification results; Based on the input state, the output state, the applicable conditions, the failure mode, the execution cost, and the verification result, multiple initial experiences are constructed.

4. The method according to claim 2, wherein determining verifiable experience from the plurality of initial experiences based on the current decidable state corresponding to the task objective and the target decidable state includes: Based on the current decidable state and the target decidable state, candidate experiences are matched from the multiple initial experiences, where the input state is consistent with the current decidable state and the output state is consistent with the target decidable state. Based on the applicable conditions, execution costs, failure modes, and verification results of the candidate experiences, the confidence level of the candidate experiences is determined. Candidate experiences whose confidence levels meet a preset threshold are determined as verifiable experiences. The starting state and the target state of the verifiable experiences are the input state and the output state of the candidate experiences, respectively.

5. The method according to claim 4, wherein invoking the agent to perform a state transition task between the current decidable state and the target decidable state according to the verifiable experience, and obtaining the verified target experience, includes: Invoke the tools or skills recorded in the verifiable experience to perform the state transition from the initial state to the target state; Execute the verification probes recorded in the verifiable experience and collect the measured results; If the measured results meet the preset evaluation criteria, the state transition is confirmed to have passed the verification, and the target experience is generated.

6. The method according to claim 5, further comprising, after collecting the measured results: If the measured results do not meet the preset evaluation criteria, the verifiable experience is marked as rejected experience, and the confidence level of the rejected experience is updated based on the measured results. If the measured results meet the preset evaluation criteria, the verifiable experience is marked as verified experience, and the confidence level of the verified experience is updated based on the measured results. The verified experience or the rejected experience, carrying the source of the evidence and the confidence level, is written back into the state experience map.

7. The method according to claim 6, wherein the state experience map comprises a task layer and a general layer; After writing the verified experience or the rejected experience, carrying the source of the evidence and the confidence level, back into the state experience map, the method further includes: Execute the state transition task corresponding to the verified experience on the heterogeneous task to obtain the verification result of the heterogeneous task; If the verification results of the heterogeneous task meet the preset evaluation criteria, the verified experience is updated from the task layer to the general layer.

8. The method according to claim 2, wherein constructing a state experience graph using the determineable state as nodes and the target experience as edges includes: Extract the initial state and the target state from the target experience, treat the initial state and the target state as decidable states, and store the decidable states as a state file; Based on the initial state, target state, applicable conditions, tools or skills used, verification probes, test results, confidence level, and source of evidence in the target experience, an experience record is generated and stored as an experience file. The decisionable states in the state file are used as nodes, and the experience records in the experience file are used as edges. The nodes and edges corresponding to multiple target experiences are associated and integrated to construct the state experience graph.

9. The method according to any one of claims 1 to 8, further comprising, after constructing the state experience map: In response to the agent's current request, a map projection block corresponding to the current request is generated based on the current content of the state experience map and the position of the current request in the session; The map projection block is attached to the current request, and if the state experience map is updated, the map projection block corresponding to the next request is regenerated based on the updated state experience map.

10. The method according to any one of claims 1 to 8, wherein the tool interface is defined as an interface definition of a general execution primitive, and the skill module file is used to store procedural schemes; The step of invoking the intelligent agent to perform a state transition task between the current decidable state and the target decidable state according to the verifiable experience, and obtaining the verified target experience, includes: Based on the verifiable experience records of the calling tools or skills, determine the execution primitives required to perform the state transition task from the general execution primitives; The agent is invoked to execute the state transition task using the required execution primitives. If the state transition task is verified and confirmed, the target experience is generated and associated with the corresponding procedural scheme in the skill module file.

11. A method for operating an intelligent agent, comprising: Obtain a state experience graph and a task objective, and determine the current decisionable state and the target decisionable state corresponding to the task objective. The state experience graph has decisionable states as nodes and verified target experiences as edges. From the state experience map, candidate experiences that are consistent with the starting state and the current determinate state, and the target state and the target determinate state are consistent, are queried to obtain candidate paths; A directional probe is executed on the candidate path to obtain the test results, and the winning path is determined based on the test results; The winning path is frozen into a deterministic process, and the task objective is executed to obtain the execution result; The execution results are evaluated, and the evaluation results and the measured results are written back to the state experience map.

12. The method according to claim 11, wherein querying candidate experiences from the state experience map where the starting state is consistent with the current decidable state and the target state is consistent with the target decidable state to obtain candidate paths includes: From the state experience map, determine a first candidate experience starting from the current determineable state and a second candidate experience starting from the target state of the first candidate experience; The first candidate experience and the second candidate experience are combined according to the state connection relationship to obtain multiple candidate paths; Based on the applicable conditions, execution costs, failure modes, combinatorial constraints, and dominance relationships contained in the candidate experiences of each candidate path, the multiple candidate paths are pruned to obtain the candidate paths; wherein, the current decidable state and the target decidable state are determined by the state checker based on the state morphology definition of the agent's working object.

13. The method according to claim 11, wherein performing a directional probe on the candidate path to obtain the measured results includes: A preset number of samples are determined from the real data corresponding to the candidate paths to obtain a sample subset; The state transitions in the candidate paths are executed using the sample subset, and the measured results are collected. The confidence level of the candidate experiences included in the candidate path is updated based on the measured results.

14. The method according to claim 11, further comprising, after writing the evaluation results and the measured results back to the state experience map: Based on the evaluation results, the failure modes and boundary samples corresponding to the execution results are determined, and the failure modes and boundary samples are written into the state experience map. Based on the failure modes and the boundary samples, update the applicable conditions, failure modes and confidence levels of the corresponding target experiences in the state experience map, so as to generate new verifiable check items when evaluating the execution results; In response to the next round of task objectives, candidate experiences are queried based on the updated state experience graph, and pruning or detours are performed on the candidate experiences corresponding to the failure modes to obtain updated candidate paths.

15. A method for evaluating an agent, comprising: Obtain the execution result, task contract, and state experience graph, wherein the state experience graph has determineable states as nodes and verified target experiences as edges. Based on the execution results and the task contract, multiple evaluation dimensions are determined, and each evaluation dimension is converted into a verifiable check item. The verifiable check item is executed using multiple evaluation units to obtain the evaluation sub-results corresponding to each evaluation unit. The evaluation result is determined based on each evaluation sub-result. If there is a discrepancy among the evaluation sub-results, the discrepancy is routed to deterministic verification, evidence probe or manual adjudication according to whether the discrepancy corresponds to an external truth value, so as to obtain the adjudication result of the discrepancy. The verifiable check item corresponding to the evaluation result is frozen as an evaluation process, and the evaluation result is written back to the state experience map.

16. The method according to claim 15, wherein the plurality of evaluation units includes a heterogeneous evaluation unit, the heterogeneous evaluation unit being different from the running generation model that generates the execution result in terms of model family, training objective, input modality, or implementation mechanism; The step of using multiple evaluation units to execute the verifiable check item respectively, and obtaining the evaluation sub-result corresponding to each evaluation unit, includes: The verifiable check item is executed using the heterogeneous evaluation unit to obtain the evaluation sub-result corresponding to the heterogeneous evaluation unit.

17. The method of claim 15, further comprising, after obtaining the decision on the dispute: If no corresponding external truth value is found for the disagreement, the disagreement is retained as a disputed state. Based on the disputed state, new inspection items and new evidence probes are generated, and the disputed state, the new inspection items, and the new evidence probes are written into the state experience map.

18. An intelligent agent system, comprising: The basic capability layer provides common execution primitives, skill module files, and state experience graphs. An agent working layer for performing the steps of the method as described in any one of claims 1 to 17; An experience accumulation layer is used to freeze the winning path determined by the agent's working layer into a deterministic process and update the state experience graph.

19. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 17.

20. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 17.

21. A computer program product comprising computer-executable instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 17.

Images