Agent tool invocation knowledge optimization method based on empirical path graph evolution

Abstract

This invention provides a method for optimizing agent tool invocation knowledge based on the evolution of an experience path graph. The method includes: upon the agent's first successful task completion, recording the agent's tool invocation sequence, input / output parameters, and execution results to generate a structured invocation log, and converting the log into standardized invocation path knowledge units; performing structured and semantic representation on the invocation path knowledge units, storing the structured representation in a graph database and the semantic representation in a vector database; constructing an experience path knowledge graph using task intent, tool entities, and invocation paths as heterogeneous nodes. This graph records the multidimensional relationships between tasks, paths, and tools, and adds execution performance and feedback attributes to the path nodes, thus optimizing the agent's tool invocation knowledge. This aims to improve the efficiency and robustness of the agent's tool invocation in a multi-task environment.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence technology, and in particular relates to a method for optimizing the knowledge invocation of intelligent agent tools based on the evolution of experience path graphs. Background Technology

[0002] Large Language Model (LLM) driven agents have demonstrated great potential in accomplishing complex real-world tasks by invoking external tool APIs. However, existing technologies still face the following prominent challenges in managing and reusing the tool invocation experience of agents:

[0003] 1. Lack of Experience and Redundant Exploration: Current mainstream agent frameworks (such as ReAct and Chain-of-Thought) largely rely on a "real-time reasoning and trial-and-error" strategy, lacking a structured storage and transfer mechanism for historically successful invocation paths. When the agent faces a similar task again, it still needs to repeatedly explore the optimal tool combination, leading to low invocation efficiency and wasted inference resources. For example, when there are nine medical image analysis tools with similar functions, the agent may need to try them one by one, resulting in up to nine invocations, thus causing serious latency and resource waste. Such methods lack a mechanism for remembering and reusing historical successful experiences, and therefore often repeat redundant exploration processes when facing similar tasks.

[0004] 2. Call failure issues in dynamic environments: External tools often fail due to updates, replacements, or being taken offline, while existing systems lack the "self-healing" or alternative recommendation capabilities of the experience layer, causing call chain breaks and performance degradation. Due to the lack of "self-healing" capabilities, the agent cannot proactively seek alternative solutions, thus significantly weakening the system's robustness.

[0005] 3. Lack of long-term learning and path evolution mechanisms: Most systems only implement tool calls through static templates or manual rules, failing to combine user feedback, adaptive weights and path evolution models to achieve continuous optimization and updating of experiential knowledge. Summary of the Invention

[0006] To address the problems existing in the prior art, this invention provides a method for optimizing the knowledge invocation of intelligent agent tools based on the evolution of experience path graphs.

[0007] This disclosure provides an intelligent agent tool invocation knowledge optimization method based on experience path graph evolution, including:

[0008] When the agent successfully completes the task for the first time, it automatically records the agent's tool call sequence, input and output parameters and execution results, generates a structured call log, and transforms the call log into standardized call path knowledge units;

[0009] The knowledge unit of the calling path is simultaneously represented in both structured and semantic terms. The structured representation is stored in a graph database, and the semantic representation is stored in a vector database.

[0010] Based on graph databases and vector databases, an experience path knowledge graph is constructed with task intent, tool entity, and call path as heterogeneous nodes. The experience path knowledge graph is used to record the multidimensional relationships between tasks, paths, and tools, and to attach execution performance attributes and feedback attributes to the path nodes in the graph, thereby completing the optimization of agent tool call knowledge.

[0011] Optionally, after the step of constructing an experience path knowledge graph based on graph databases and vector databases, using task intents, tool entities, and invocation paths as heterogeneous nodes, the method further includes:

[0012] When the agent receives a new task, it recalls path knowledge units from the vector database through semantic similarity, and then performs structural screening and performance evaluation in the experience path knowledge graph to select the optimal candidate path for parameter mapping and transfer reuse.

[0013] Optionally, when the agent receives a new task, it recalls path knowledge units from the vector database based on semantic similarity, then performs structural screening and performance evaluation in the experience path knowledge graph, and selects the optimal candidate path for parameter mapping and transfer reuse, including:

[0014] The query is expanded and the data pattern is predicted for new task requests. The query semantic vector and pattern vector are generated. The vector database is searched in two channels. The results are merged by merging the results by the inverse ranking to obtain the candidate path set.

[0015] For each path in the candidate path set, tool status checks and data flow compatibility verification are performed based on the token ring graph traversal algorithm, and a score is calculated by combining the path's historical performance to determine the optimal path.

[0016] Optionally, the step of recalling path knowledge units from the vector database based on semantic similarity when the agent receives a new task, and then performing structural screening and performance evaluation in the experience path knowledge graph to select the optimal candidate path for parameter mapping and transfer reuse, further includes:

[0017] Analyze the semantics of new tasks to identify task intent, key entities, and input variables;

[0018] Select the optimal candidate path as a template and establish a mapping rule between the new task parameters and the template path parameters;

[0019] Generate a call path adapted to the new task based on the mapping rules, and perform logical integrity and data dependency consistency checks.

[0020] Optionally, after the step of constructing an experience path knowledge graph based on graph databases and vector databases, using task intents, tool entities, and invocation paths as heterogeneous nodes, the method further includes:

[0021] Continuously collect task execution feedback data, and adjust the weights of path nodes in the experience path knowledge graph based on the feedback data and time decay model to realize the self-evolution and path elimination of the experience path knowledge graph;

[0022] When a tool in the call path is detected to be faulty, the system searches for semantically similar alternative tools or path fragments through the experience path knowledge graph to dynamically repair the call chain and generate new call path knowledge units based on the repair results.

[0023] Optionally, the dynamic repair of the call chain includes:

[0024] When path verification fails, obtain the upstream and downstream tools and data pattern information of the failed path;

[0025] Perform shortest path search in the knowledge graph to find alternative path fragments with limited graph bridging length, consisting of active tools;

[0026] The original call chain is rewritten using the found alternative fragments to generate a temporary fix path;

[0027] If the repair path is successfully executed and positive feedback is obtained, a new call path knowledge unit is generated.

[0028] Optionally, the automatic recording of the intelligent agent tool call sequence, input / output parameters, and execution results generates a structured call log, and transforms the call log into standardized call path knowledge units, including:

[0029] By using an experience-based proxy in an aspect-oriented programming approach, data from the tool invocation process is collected at both the pre- and post-invocation aspects.

[0030] Once the task is marked as successfully completed, the collected call process data is aggregated and serialized into an execution trace;

[0031] The execution trace is abstracted by the path generalization service to identify and generalize key entities in the user request, and generate a standardized call path knowledge unit containing tool sequence, generalization parameters and data pattern information.

[0032] Optionally, the generation of the standardized call path knowledge unit includes:

[0033] The path generalization service collects raw trace logs generated by recording the successful task execution process of the agent by subscribing to a message queue;

[0034] Obtain the corresponding original user request text based on the session identifier in the original trace log;

[0035] The named entity recognition model is used to analyze the user request text and extract key entities and their values.

[0036] The input parameters of each tool call step in the original tracking log are traversed, and the parameter values ​​are matched with the key entity: if the match is successful, the parameter is generalized into a variable placeholder; if the match is unsuccessful, the parameter is retained as a fixed configuration value, thus completing the input parameter generalization.

[0037] Retrieve the output data profile information asynchronously extracted during the tool call and populate it into the output data pattern field;

[0038] Generate a hash value for a normalized path signature based on the tool call sequence and the parameter keys after generalization of the input parameters;

[0039] Based on the generalized parameters of the input parameters, the output data pattern field, and the hash value, a standardized call path knowledge unit is generated.

[0040] Optionally, the semantic representation is achieved by constructing a rich semantic description document containing task intent, trigger template, and tool description information, and generating corresponding semantic vectors using a sentence embedding model;

[0041] The structured representation maps input and output data patterns in the call path knowledge unit to a predefined global data pattern vocabulary and generates multi-hot encoded interface pattern vectors. The structured representation is used to describe inter-tool dependencies and data flow relationships.

[0042] Optionally, the construction of an experience path knowledge graph based on graph and vector databases, using task intent, tool entities, and invocation paths as heterogeneous nodes, includes:

[0043] Periodically cluster paths under the same task intent based on tool sequence similarity and merge similar paths;

[0044] Regularly clean up path nodes and their associated relationships whose weights are below the threshold or have not been used for a long time.

[0045] The present invention provides an intelligent agent tool calling knowledge optimization method based on experience path graph evolution. By structurally recording, semantically representing and storing the tool calling process in the agent's historical tasks in a knowledge graph, the accumulation of experience paths is achieved. It does not rely on real-time task scheduling or rule planning, but is based on the accumulation, reuse and evolution of historical experience knowledge, thereby improving the efficiency and robustness of the agent's tool calling in a multi-task environment. Attached Figure Description

[0046] The above and other objects, features and advantages of this disclosure will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.

[0047] Figure 1 A flowchart illustrating the knowledge optimization method for intelligent agent tools based on experience path graph evolution provided in this embodiment of the disclosure. Detailed Implementation

[0048] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0049] like Figure 1 As shown, this embodiment discloses a method for optimizing agent tool invocation knowledge based on the evolution of experiential path graphs, including:

[0050] Experience acquisition and standardization: When the agent successfully completes a task for the first time, the agent automatically records the tool call sequence, input and output parameters and execution results, generates a structured call log, and transforms the call log into standardized call path knowledge units;

[0051] Bimodal representation and storage of knowledge units: The knowledge units of the calling path are simultaneously represented in a structured manner and in a semantic manner. The structured representation is stored in a graph database and the semantic representation is stored in a vector database.

[0052] Construction and management of the experience knowledge graph: Based on graph databases and vector databases, an experience path knowledge graph is constructed using task intents, tool entities, and invocation paths as heterogeneous nodes. The experience path knowledge graph is used to record the multidimensional relationships between tasks, paths, and tools, and execution performance attributes and feedback attributes are attached to the path nodes in the graph to complete the optimization of agent tool invocation knowledge;

[0053] In the construction and management of the knowledge graph, the schema definition of the knowledge graph includes DataSchema nodes, Tool nodes, and CallPathUnit nodes. The DataSchema nodes form a type inheritance hierarchy through the "IS_A" edge, and record the compatibility relationship and conversion cost between data types through the "IS_COMPATIBLE_WITH" edge.

[0054] Path matching and reuse based on hybrid retrieval: When the agent receives a new task, it recalls path knowledge units from the vector database through semantic similarity, and then performs structural screening and performance evaluation in the experience path knowledge graph to select the optimal candidate path for parameter mapping and transfer reuse.

[0055] Hybrid retrieval-based path matching and reuse includes quantitative retrieval: query expansion and data pattern prediction are performed on new user task requests to generate query semantic vectors and pattern vectors, dual-channel retrieval is performed in the vector database, and the results are merged through inverse ranking fusion (RRF) to obtain a candidate path set;

[0056] Graph structure retrieval: For each path in the candidate path set, tool status checks and data flow compatibility verification are performed based on the token ring graph traversal algorithm. The final score is calculated by combining the path's historical performance to determine the optimal path.

[0057] Hybrid retrieval-based path matching and reuse also includes path mapping and migration:

[0058] Analyze the semantics of new tasks to identify task intent, key entities, and input variables;

[0059] Select the optimal candidate path as a template and establish a mapping rule between the new task parameters and the template path parameters;

[0060] Generate a call path adapted to the new task based on the mapping rules, and perform logical integrity and data dependency consistency checks.

[0061] Dynamic evolution and weight optimization mechanism: Continuously collect task execution feedback data, and adjust the weights of path nodes in the experience path knowledge graph based on the feedback data and time decay model to realize the self-evolution and path elimination of the experience path knowledge graph;

[0062] Dynamic evolution and weight optimization mechanisms include:

[0063] User interaction signals are collected through client-side telemetry and server-side interfaces to obtain feedback signals;

[0064] Different adjustment factors are assigned based on the type of feedback signal, and the weight adjustment value is calculated by combining the log-decay learning rate based on the number of uses.

[0065] The weights, usage counts, success counts, and last usage timestamps of corresponding path relationships in the knowledge graph are updated based on adjustment factors and weight adjustment values.

[0066] Path aggregation and self-healing mechanism: When a tool in the call path is detected to be ineffective, the system searches for semantically similar alternative tools or path fragments through the experience path knowledge graph to dynamically repair the call chain and generate new call path knowledge units based on the repair results.

[0067] Dynamic repair specifically includes:

[0068] When path verification fails, obtain the upstream and downstream tools and data pattern information of the failed path;

[0069] Perform K-shortest path search in the knowledge graph to find alternative path fragments with limited bridging length, consisting of active tools;

[0070] The original call chain is rewritten using the found alternative fragments to generate a temporary fix path;

[0071] If the repair path is successfully executed and positive feedback is obtained, it is standardized into a new Call Path Knowledge Unit (CPKU) and stored in the knowledge base.

[0072] This embodiment aims to provide a knowledge optimization method for agent tool invocation based on the evolution of experience path graphs. By modeling and managing the tool invocation experience formed in the agent's historical tasks, it achieves standardized storage, semantic representation, hybrid retrieval, and adaptive optimization of invocation paths, thereby constructing a continuously learning and self-evolving experience knowledge system. This solution does not rely on real-time task scheduling or rule planning, but rather on the "accumulation, reuse, and evolution" of historical experience knowledge, fundamentally improving the agent's invocation efficiency, reusability, and robustness. Based on this concept, this embodiment constructs a systematic technical framework and proposes the following technical solutions:

[0073] An intelligent agent tool invokes a self-optimization method, comprising the following steps:

[0074] Experience Acquisition and Standardization: When the agent successfully completes a task for the first time, it automatically records the sequence of tools it calls, input and output parameters, and results, generating a structured call log. The system transforms the log into a standardized "Call Path Knowledge Unit" (CPKU) for subsequent storage and reuse. The dual-modal representation and storage system of the knowledge unit simultaneously performs structured and semantic representation on the CPKU.

[0075] Structured representations are used to describe dependencies and data flow relationships between tools; semantic representations are generated based on language models to create call path summaries and then converted into high-dimensional semantic vectors; both are stored in graph databases and vector databases respectively, forming a bimodal knowledge storage.

[0076] Construction and management of the experience knowledge graph: An experience path knowledge graph is constructed using task intent, tool entity, and call path as heterogeneous nodes to record the multi-dimensional relationship of "task-path-tool"; each path node in the graph is accompanied by execution performance and feedback attributes for subsequent dynamic evolution.

[0077] Path matching and reuse based on hybrid retrieval: When the agent receives a new task, the system executes:

[0078] Semantic recall: Retrieving historical task paths based on semantic similarity;

[0079] Knowledge graph structure filtering: matching paths with reasonable structures and usable tools within the knowledge graph;

[0080] Performance evaluation: Based on the historical success rate of the path and the prediction of execution cost, the optimal candidate path is selected for parameter mapping and migration reuse.

[0081] Dynamic evolution and weight optimization mechanism: The system continuously collects task execution feedback, including call success rate, user satisfaction and execution latency, and adjusts the weight of path nodes accordingly; it uses time decay and regression models to update weights, realizing the self-evolution and path elimination mechanism of the knowledge graph.

[0082] Path aggregation and self-healing mechanism: When a path contains a failed tool, the system uses knowledge graph reasoning to automatically search for semantically similar alternative tools or path fragments to complete dynamic repair; at the same time, the repair results are solidified into new path units to further enrich the experience knowledge base.

[0083] Specifically as follows:

[0084] Experience acquisition and standardization: When an agent successfully solves a task for the first time (i.e., when there are no reusable experience paths available), it is responsible for recording and standardizing the tool-calling process for that task, forming reusable experience units. Its main steps include:

[0085] Call process monitoring and recording: In this embodiment, the "call process monitoring and recording" function is implemented by a core component called "Experience Tracer". This component is based on the Aspect-Oriented Programming (AOP) concept and is integrated with low intrusion into the agent's "Tool Scheduler". Built upon the core of "Dispatcher", Tracer is implemented as an `experience_tracer` decorator that wraps all registered utility functions. This agent collects data at two key "hook points": First, in the pre-invoke aspect, Tracer captures the session ID, step number, utility ID, and all input parameters. To avoid the performance overhead of copying large objects (such as DataFrames), it only immediately computes the hash value or memory address of the parameters as an identifier. Second, in the post-invoke aspect, Tracer captures the utility's return value or thrown exceptions. All this metadata is pushed in real-time to a memory buffer isolated by `session_id`. A key improvement is asynchronous metadata retrieval: when a return value is captured, Tracer does not block the main execution thread but instead starts an asynchronous task (e.g., using `asyncio.create_task` or submitting it to a `ThreadPoolExecutor`). This task is responsible for "data profiling" the return value. Profiling extracts information such as type, dimensions, key or column names, and data type. This "profile" result (e.g., {"type":"DataFrame","shape":[10,5]}) is then asynchronously written back to the corresponding session buffer for use in subsequent log generation and experience generalization.

[0086] Structured log generation: The process is initiated by a specific trigger: when the agent's "Planner" confirms that the task's final goal has been achieved, the task's state machine enters the SUCCESS state. This success signal notifies the "Tracer" that the session with the specified session_id has successfully ended. The Tracer then accesses the memory buffer it maintains for that session, extracts all call events sorted by step_number, and aggregates and serializes this complete event sequence into a JSON-formatted "Trace Log." To achieve decoupling and asynchronous processing, this Trace Log is then pushed to a message queue (such as the trace_log_queue in RabbitMQ) or persisted to the raw_traces collection in a NoSQL database (such as MongoDB), awaiting consumption by subsequent "path generalization services."

[0087] Trace Log Example:

[0088] {

[0089] "session_id":"sess-001",

[0090] "steps":[

[0091] {"tool_id": "load_ceph_image", "params_hash": "...", "output_summary": {"type":"Image","format":"DICOM"}},

[0092] {"tool_id": "calculate_sna_angle", "params_hash": "...", "output_summary": {"type":"float","unit":"degrees"}} ]

[0094] }

[0095] Standardized Knowledge Unit Generation: The "Standardized Call Path Knowledge Unit Generation (CPKU)" is handled by a separate "Path Generalization Service" (typically a microservice or backend worker). This service consumes raw Trace Logs by subscribing to the `trace_log_queue`. Its core logic is to perform "Variable Abstraction": the service first obtains the original user request context (e.g., "Please analyze... / uploads / ceph.dcm...SNA angle") based on the `session_id` in the Trace Log. Then, it analyzes the request using a NER (Named Entity Recognition) model, extracting key entities such as `{"FILE_PATH":" / uploads / ceph.dcm","METRIC":"SNA angle"}`. Subsequently, the service iterates through the input parameters of each step in the Trace Log: if a parameter value (e.g., " / uploads / ceph.dcm") matches an entity extracted by NER, it is generalized to a variable (e.g., "{VAR_FILE_PATH}"); if a parameter value (e.g., {"precision":0.01}) does not find a match in the entity, it is retained as a fixed configuration. Finally, the service integrates the asynchronously extracted "data profile" from the first step to populate the output_data_schema field, and generates a SHA256 hash (path_hash) of a "normalized path signature" based on the tool sequence and the generalized parameter keys for fast deduplication. The final generated CPKU (JSON) is pushed to the vector database and graph database. An example of its standardized data structure is as follows:

[0096] {

[0097] "path_id": "uuid-12345",

[0098] "user_intent": "Calculate SNA angle",

[0099] "triggering_question_example": "Please analyze and calculate the SNA angle in a lateral cephalometric radiograph".

[0100] "tool_sequence": [

[0101] {

[0102] "step": 1,

[0103] "tool_id": "load_ceph_image",

[0104] "input_params": {"file_path": "{VAR_image_path}"},

[0105] "output_var": "image_object"

[0106] },

[0107] {

[0108] "step": 2,

[0109] "tool_id": "calculate_sna_angle",

[0110] "input_params": {"image_data": "{VAR_image_object}"},

[0111] "output_var": "final_result

[0112] } ]

[0114] "success_flag": true,

[0115] "feedback_score": 4.8

[0116] }

[0117] Bimodal Representation and Storage of Knowledge Units: This section is responsible for performing semantic and structural bimodal representations of call path knowledge units (CPKUs) and storing them in a heterogeneous database to form a searchable knowledge foundation. The main steps are as follows:

[0118] Semantic Representation: Semantic representation aims to capture the task intent and toolchain semantics of CPKU. The system first constructs a "Rich Semantic Document," whose content is composed of the intent field (user_intent_normalized), the triggering template (triggering_question_template), and the tool identifiers and descriptions of the tool sequence, forming a structured text input block.

[0119] [INTENT]: {user_intent_normalized}

[0120] [TRIGGER_EXAMPLE]: {triggering_question_template}

[0121] [TOOLS_SEQUENCE]:

[0122] Step 1: {tool_id_1} - Description: {tool_1_description}

[0123] Step 2: {tool_id_2} - Description: {tool_2_description}

[0124] During the encoding process, a "metadata-weighted encoding" strategy is adopted:

[0125] The system calculates the vector embeddings for the task intent block and the tool sequence block respectively:

[0126] Vintent=SBERT.encode([INTENT]),

[0127] Vtools=SBERT.encode([TOOLS_SEQUENCE]),

[0128] Then, the mixture is aggregated using a weighted average:

[0129] Vfinal=normalize(1.2 Vintent +0.8 Vtools),

[0130] Where normalize represents the L2 normalization operation, which ensures that the vector magnitude is 1, facilitating subsequent cosine similarity retrieval.

[0131] Finally, an SBERT model such as all-MiniLM-L6-v2 is used to generate 384-dimensional float32 semantic vectors. This vector preserves both task semantic information and tool functional semantics, providing a highly discriminative semantic index for hybrid recall in Module 4.

[0132] Structured Representation: Structured representation is used to capture the tool dependencies and data interface pattern features of CPKUs. The system maintains a globally fixed-length DataSchema vocabulary (e.g., 128 dimensions), with terms including common data patterns such as Image, Text, JSON, DICOM, NIFTI, float, and int. For each CPKU, the system iterates through the input_data_schema and output_data_schema fields in its tool_sequence, mapping the data types that appear to the vocabulary positions and generating a multi-hot encoding sparse vector. For example, when a path uses both "Image[DICOM]" and "float[degrees]" data types, the value at the corresponding index position is set to 1, generating a vector like [1,0,0,1,0,1,0,…]. This vector is called the "Interface Schema Vector" and is used to perform fast compatibility filtering at the data schema level in the first stage of path retrieval, thereby significantly improving recall efficiency and data flow consistency.

[0133] Dual-modal storage: To support hybrid retrieval of semantics and structure, this module adopts a "dual-modal storage architecture", that is, writing to both the vector database and the graph database simultaneously, maintaining the hierarchical consistency between functional indexes and relational semantics.

[0134] (1) The core fields of the vector database storage (such as Weaviate or Milvus) CPKU include path_id, path_hash, intent_normalized, schema_vector and semantic vector V_final.

[0135] Here is an example of storage in Weaviate:

[0136] {

[0137] "class": "CallPath",

[0138] "properties": [

[0139] {"name": "path_id", "dataType": ["string"]},

[0140] {"name": "path_hash", "dataType": ["string"]},

[0141] {"name": "intent_normalized", "dataType": ["string"]},

[0142] {"name": "schema_vector", "dataType": ["number[]"]}

[0143] ],

[0144] "vectorIndexConfig": {"distance": "cosine"},

[0145] "vectorizer": "none"

[0146] }

[0147] The system simultaneously appends a 384-dimensional semantic vector V_final and a 128-dimensional schema_vector during writing to achieve a dual-vector joint index.

[0148] (2) Graph database storage (e.g., Neo4j): In a graph database, the system uses the MERGE statement to ensure that CPKU nodes are created idempotently with their associated Intent, Tool, and DataSchema nodes. For example:

[0149] MERGE (p:CallPathUnit {path_id: $cpku.path_id})

[0150] SET p.path_hash = $cpku.path_hash, p.success_rate = $cpku.success_rate, p.avg_latency_ms = $cpku.avg_latency_ms

[0151] MERGE (i:Intent {name: $cpku.user_intent_normalized})

[0152] MERGE (i)-[r:HAS_PATH]->(p)

[0153] ON CREATE SET r.weight = 1.0, r.usage_count = 1, r.created_at =datetime()

[0154] FOREACH (step IN $cpku.tool_sequence |

[0155] MATCH (t:Tool {id: step.tool_id})

[0156] MERGE (p)-[:EXECUTES_TOOL {step: step.step_num}]->(t)).

[0157] The system employs an eventual consistency strategy: a successful write to the graph database serves as the main transaction commit flag; if a write to the vector database fails, the transaction enters a compensation retry queue. Since the retrieval in Module 4 uses vector database recall as its entry point, short-term inconsistencies only temporarily render the path unrecoverable and do not affect global consistency.

[0158] Construction and Management of Experience Knowledge Graph: This section focuses on establishing and maintaining a CPKU-based knowledge graph structure, enabling the systematic organization, visualization, and dynamic updating of experience retrieval. Its main components are as follows:

[0159] Schema Definition: The schema is the structural foundation of the entire knowledge system, used to define the relationships and hierarchies of various objects in the call path. Core nodes include DataSchema, Tool, and CallPathUnit. Among them, the DataSchema node forms a multi-level type inheritance structure, which is the key mechanism for implementing "data compatibility" checks. For example, (ImagePNG:DataSchema)-[:IS_A]->(Image:DataSchema) indicates that the PNG image is a subclass of the general image type, while (Image:DataSchema)-[:IS_A]->(FileObject:DataSchema) includes the image in the higher-level category of file objects.

[0160] The system's "Type System Analyzer" calculates compatibility relationships between different data types offline and records the feasibility and cost of conversion via the IS_COMPATIBLE_WITH edge (e.g., cost: 1 indicates a one-step conversion is required). Meanwhile, Tool nodes store core metadata about the tools, including attributes such as id, status, version, api_endpoint, and description. The status field (Active / Inactive / Deprecated) provides the foundation for the self-healing mechanism of subsequent modules. The HAS_PATH relationship connects intents and paths (CallPathUnits) and includes dynamic attributes such as weight, usage_count, success_count, last_used_at, and created_at, providing quantitative basis for path optimization and feedback updates. This schema design ensures the knowledge graph possesses clear structure, scalability, and traceability.

[0161] Path attribute and metadata management: Each path node has associated attributes such as success rate, average latency, user rating, usage frequency, and weight. Dynamic management of path attributes and metadata is handled by the "Path Analyzer" component, which can run periodically (e.g., hourly) via Airflow DAG or Cron scheduled tasks. The system retrieves nearly one hour's worth of runtime data from execution log databases (such as ELK, Prometheus, and InfluxDB) and aggregates the average latency and success rate for each path.

[0162] SELECT path_id, AVG(latency) AS latency, COUNT(status='success') / COUNT(*) AS success_rate

[0163] FROM execution_logs

[0164] WHERE timestamp>now() - 1h

[0165] GROUP BY path_id.

[0166] The aggregation results are written back to the graph database using a smoothed moving average method to prevent indicator anomalies caused by short-term fluctuations. The update logic is implemented using Cypher transactions, for example:

[0167] UNWIND $R as row

[0168] MATCH (p:CallPathUnit {path_id: row.path_id})

[0169] SET p.avg_latency_ms = (p.avg_latency_ms * 0.9) + (row.latency *0.1),

[0170] p.success_rate = (p.success_rate * 0.9) + (row.success_rate * 0.1).

[0171] Through this mechanism, path nodes in the graph can reflect the system performance status in real time, realizing closed-loop management of knowledge units from static description to dynamic evolution.

[0172] Evolutionary Update Mechanism: The evolutionary update mechanism of the knowledge graph ensures that the system remains simple, accurate, and efficient during long-term operation. The evolutionary process mainly includes two types: path clustering and fusion, and low-weight elimination.

[0173] The path clustering and fusion mechanism is triggered weekly, aiming to identify semantically equivalent paths with minor implementation differences. The system implements this through the following process: First, it collects all paths under the same intent (MATCH (i:Intent)-[r:HAS_PATH]->(p:CallPathUnit)), obtains their tool sequences, and calculates the normalized edit distance between each pair to construct a distance matrix. Then, it automatically clusters these paths using the DBSCAN algorithm, resulting in multiple similar path clusters. For each cluster, the system can choose to automatically fuse them (creating a virtual path P_fused and aggregating the edge weights of the original paths) or submit them for manual review to ensure the accuracy of knowledge evolution.

[0174] A low-weight eviction mechanism is executed daily to clean up paths that have been inactive for a long time or are performing poorly. The system uses Cypher queries to mark nodes that meet certain criteria.

[0175] MATCH (i:Intent)-[r:HAS_PATH]->(p:CallPathUnit)

[0176] WHERE r.weight<0.1

[0177] AND p.status<>'Deprecated'

[0178] AND (r.last_used_at<(datetime() - duration('P90D')) OR r.usage_count>100)

[0179] SET p.status = 'Deprecated'

[0180] DETACH DELETE r.

[0181] This mechanism ensures that the knowledge graph continues to converge, evolve, and optimize, achieving dynamic growth and healthy maintenance of "experience knowledge".

[0182] Path matching and reuse based on hybrid retrieval: When the agent receives a new task, this module is responsible for retrieving historical similar paths from the knowledge graph and semantic database to achieve experience transfer and reuse. The main process is as follows:

[0183] Step 1: Semantic Vector Retrieval (Recall):

[0184] Semantic vector retrieval is the first stage of path matching, aiming to efficiently recall semantically relevant candidate paths within a large-scale CPKU (Content Knowledge Base). The system first performs query preprocessing on the user request Qnew, including two sub-steps: query expansion and data pattern prediction. Query expansion rewrites the user input using LLM (Limited Language Modeling) to make its semantic expression more closely match the tool path corpus in the knowledge base. For example, "Please analyze and calculate the SNA angle in the lateral cephalometric radiograph / uploads / ceph.dcm" is transformed into "Tool path for calculating the SNA angle in a lateral cephalometric image". Subsequently, the system uses a schema prediction model to identify the implicit data types (such as DICOM images, file paths, etc.) in the request, obtaining structural labels ["FilePath", "Image", "DICOM"].

[0185] The system then generates a semantic vector `Vquery=SBERT.encode(Result_A)` and a pattern vector `Vschema=MultiHotEncode(Result_B)`, respectively, and performs a dual-channel retrieval in the vector database. The semantic vector uses cosine similarity to search for similar paths, while the pattern vector uses multi-hot encoding-based structural matching for data compatibility recall. The two results are merged using Reciprocal Rank Fusion (RRF) to balance semantic similarity and data pattern consistency. The final output is a Top-K (e.g., 5) candidate path sorted by comprehensive score, providing input for subsequent graph structure refinement.

[0186] Step Two: Graph Structure Retrieval (Fine Ranking):

[0187] Within the candidate set of semantic recall, the system needs to further verify the executability and structural matching of each path, a process completed by a "Path Validator". A validation algorithm based on token-ring graph traversal is implemented, which is passed step by step in the graph in the form of "validation tokens".

[0188] Initially, the input data schema (such as an Image[PNG]) extracted from user input is encapsulated as a token and injected into the first node of the path. The system then iterates through each tool node in the path, checking them step by step:

[0189] Tool status check – If the tool is in an Inactive or Deprecated state, immediately stop it and mark it with penalty points;

[0190] Data compatibility verification – By querying the edge relationship between IS_A and IS_COMPATIBLE_WITH through the graph database, it is determined whether the data type carried by the current token meets the input requirements of the downstream tools;

[0191] Token passing – If the verification is successful, the token's current_schema_node is updated to the tool's output schema and passed to the next node.

[0192] If any step fails, the system records the error message and penalty score, and triggers the self-healing process in Module 5. After completing the traversal, the final score is calculated by weighting the success rate and penalty score for all paths:

[0193] FinalScore = (r.weight × 0.8) (penalty_score×0.2),

[0194] The path with the highest score is selected as the final execution plan. This process ensures that the system balances structural correctness and execution feasibility during the fine-tuning phase.

[0195] Path Mapping and Migration: After determining the optimal call path template, the system starts the path mapping and migration module to automatically adapt and migrate the new task semantics to the template path. This process includes the following steps:

[0196] Task semantic parsing: The system performs semantic parsing on the natural language description of the current task to identify the task intent, key entities, and input variables.

[0197] Template path selection: The optimal call path knowledge unit (CPKU) obtained in the fine ranking stage is selected as the template path input. This template contains standardized fields such as tool_sequence, input_params, output_vars, etc.

[0198] Based on the task semantic parsing results and template path structure, the system automatically establishes parameter mapping rules. The mapping relationships can be determined using semantic similarity calculation methods, defined as follows:

[0199] Map(Varnew)=f(semantic_similarity(Varnew,Vartemplate)),

[0200] Path adaptation and migration generation: Based on the above mapping rules, the system generates a migrated call path template (Adapted Path), retains the tool topology of the original path, and replaces it with parameters that match the new task.

[0201] Consistency verification: The system automatically performs consistency verification to ensure the logical integrity of the migration path, including:

[0202] Input / output variable definition integrity check;

[0203] Are the data dependencies between tools correct?

[0204] Graph node status and topology validity verification.

[0205] Validated migration paths are marked as "Validated Path" and can be stored in the knowledge base for future reuse.

[0206] Interpretable Output: After path mapping is complete, the system generates corresponding interpretable output to support manual review, model debugging, and enhanced system transparency. This step includes the following processes:

[0207] Semantic summary generation: Based on the transferred call path template, the system calls a large language model (LLM) to generate a natural language semantic summary, which describes the path function, tool call order and expected results.

[0208] For example: "This path reuses the experience of calling the historical task 'Head Image Angle Analysis', which includes two steps of tool calling: first, loading the image file, then calculating the SNA angle, and outputting the measurement results."

[0209] Structured flowchart generation: The system automatically generates a call flowchart based on the path topology. Nodes represent tools, input or output variables, and edges represent call dependencies. For example:

[0210] [Load_Ceph_Image]→[Calculate_SNA_Angle]→[Output_Angle_Result].

[0211] Execution relationship annotation and attribute appending: Each node is appended with its semantic tags, historical success rate, average execution time, and other attributes. The system can present these attributes in the interface as heatmaps or tags.

[0212] Load_Ceph_Image(Success Rate: 0.97)

[0213] Calculate_SNA_Angle(Avg Time: 1.2s).

[0214] Explainability report output: The system automatically generates a path explanation report, which includes a semantic summary, tool call sequence and dependency topology, parameter mapping rule table, and path performance metric statistics.

[0215] The report can be exported as JSON, HTML, or PDF for developers to review and archive.

[0216] Feedback closed-loop connection (optional implementation): Preferably, the system can receive feedback signals (such as confirmation / negation) from users on the rationality of the path or the execution effect in the report interface, and pass the feedback to module six to update the path weights in the knowledge graph, thereby forming a continuous optimization closed loop.

[0217] Dynamic Graph Maintenance and Self-Healing of Call Paths: This module aims to dynamically maintain the knowledge graph of the calling experience and ensure the robustness of the call path execution to cope with real-time changes in the tool library. Its main functions include:

[0218] Knowledge Graph Dynamic Updates: This component acts as the system's "immune perception layer," ensuring real-time consistency between the knowledge graph and external tool libraries. Its core is the "Tooling Harvester," integrated into the Continuous Integration and Continuous Deployment (CI / CD) pipeline and executed automatically during the post-merge phase. This component scans updated source code files, using language parsing techniques (such as Python's AST or Javadoc for Java) to identify newly added or modified tool definitions and extract their parameter signatures. The system then compares these signatures with the signatures of the corresponding tool nodes in the existing knowledge graph: if there are no differences, no update is needed; if it's a non-destructive modification (such as adding optional parameters), only the tool node's version number is updated; if it's a destructive modification (such as a change in parameter type), the tool node's state (potentially set to "Inactive"), associated schema relationships, and a verification flag is triggered. The system automatically marks all path nodes (CallPathUnits) using this tool as "Requires_Validation" via Cypher queries, ensuring they are detected in the next round of path validation. Through this mechanism, the knowledge graph can be automatically and dynamically updated and maintained in a consistent manner during the evolution of the tool library, ensuring that the knowledge network structure evolves synchronously with the real calling environment.

[0219] Call chain self-healing: The call chain self-healing mechanism is the system's "immune response layer," automatically repairing the call path when a failed link is detected during path execution. This function is implemented by the "Path Healer" component. When the path matching and reuse verification result based on hybrid retrieval returns an invalid path (e.g., the tool status is "Inactive" or the data type does not match), the healer obtains the upstream and downstream tools and data schemas (InputSchema and OutputSchema) of the failed path and executes the "Graph Bridging" algorithm. This algorithm searches for alternative paths composed of "Active" tools in the graph based on K-Shortest-Path search, limiting the bridging length to no more than three steps and prioritizing the shortest feasible sequence. For example, when Tool_B in the path fails, the system can automatically retrieve an alternative path (Image[DICOM]→dicom_to_nifti→nifti_to_mesh→Mesh[STL]) and rewrite the original call chain accordingly, generating a temporary repair sequence. The new sequence is executed in memory as a temporary CallPathUnit (CPKU_Repaired). If execution is successful and positive feedback is received, module one will generalize it into a new formal path node and store it in the knowledge graph. Through this closed-loop self-healing mechanism, the system can automatically bridge the data flow when faced with changes or failures of external tools, ensuring the continuity of the task chain and the long-term stability of the knowledge system.

[0220] Path weight optimization based on closed-loop feedback aims to continuously optimize the priority of call paths through user interaction feedback, thereby achieving self-learning and performance improvement of the agent. The main steps are as follows:

[0221] 1. Feedback Collection: Feedback collection is the entry point for the closed-loop optimization mechanism, used to capture user interaction signals during actual use, thereby measuring the actual performance of the CallPathUnit. The system achieves this through a two-level collaboration between the front-end telemetry (Client-Side Telemetry) and the server-side telemetry ingestion endpoint. The front-end is embedded in UI components (such as React), automatically recording behavioral events through hook functions: when a result is rendered, onResultRendered() is triggered to record the rendering time; if a user initiates a new query within a short period of time (less than 3 seconds), it is considered an "Implicit Negative"; if the user clicks the copy button, it is considered an "Implicit Positive"; and clicking the thumbs-up button is considered "Explicit Positive Feedback." All events are reported to the telemetry ingestion endpoint through a unified interface POST / api / feedback. This endpoint is a lightweight API service (based on FastAPI or Flask) that does not directly modify the database. Instead, it asynchronously pushes standardized messages to the feedback_topic of a message queue (Kafka or RabbitMQ) to achieve reliable collection and decoupling under high concurrency.

[0222] 2. Weight Adjustment: The weight adjustment mechanism is implemented by a separate "Weight Updater" service, which continuously listens to the feedback_topic as a Kafka consumer and performs learning calculations on the feedback. Each feedback message is assigned a different adjustment factor based on its type, for example: explicit positive feedback (Thumb Up) +1.5, explicit negative feedback (Thumb Down) -2.0, implicit adoption (Copy / Adopt) +0.5, FastCorrection -1.0, normal execution success +0.1, execution failure -0.2. The system introduces a logarithmic decay learning rate based on usage count: learning_rate = 0.1 / log(usage_count + 2), to ensure that new paths can learn quickly and mature paths tend to stabilize. The final weight adjustment value is calculated according to the formula AdjustmentValue=FeedbackFactor*learning_rate, forming a refined dynamic adjustment signal for a single path edge (HAS_PATH), providing input for the next graph update.

[0223] 3. Knowledge Graph Update: Knowledge graph updates are performed by the "weight updater" at the database layer using read-modify-write transactions, ensuring that feedback signals are safely and atomically reflected in the knowledge graph. The transaction first uses Cypher to match the target relation (i:Intent) - [r:HAS_PATH] -> (p:CallPathUnit{path_id:$path_id}), reading basic data such as the current weight, usage count, and success count. Then, it performs incremental updates based on the AdjustmentValue calculated in the previous step and the execution result status (success or failure). Update rules include: weight values ​​are clamped within the range [0.01, 1.0]; usage_count is incremented by 1; success_count is accumulated based on the feedback result; and last_used_at is updated to the current timestamp. All operations are committed within a single transaction to ensure consistency and prevent concurrent write conflicts. If the target path no longer exists (MATCH failure), the feedback message is safely transferred to the Dead-Letter Queue (DLQ) for subsequent manual analysis and data cleaning. Through this mechanism, the knowledge graph can be continuously optimized under the drive of real user behavior, gradually increasing the weight of high-quality paths, and ultimately achieving adaptive evolution and intelligent convergence of the system.

[0224] This implementation has the following effects:

[0225] 1. The Proposal and Standardized Structure Design of CPKU: The concept of CPKU is proposed, which uses a unified schema to perform structured abstraction of the agent's historical tool calls, thereby realizing the reusability and retrieval of experience layer knowledge.

[0226] 2. Dual-modal knowledge representation and heterogeneous storage mechanism: The dual-modal joint storage method of "structured graph + semantic vector" is adopted. The topological and semantic layer information of the knowledge to be called is maintained in the graph database and the vector database respectively, forming a retrieval and evolution mechanism driven by semantics and structure, which is a breakthrough of the traditional single-modal knowledge base.

[0227] 3. Hybrid retrieval and semantic transfer mechanism: By combining semantic vector retrieval with knowledge graph structure fine ranking, cross-task migration of historical call paths and automatic parameter mapping are realized, thereby enabling the agent to have the ability to transfer experience and reuse calls.

[0228] 4. Path self-healing and knowledge evolution mechanism: When a tool in the call path fails, the system automatically discovers alternative tools or path fragments with similar functions through knowledge graph reasoning, and generates a new path after repair, realizing automatic repair of the call chain and continuous knowledge expansion, which significantly enhances the robustness and long-term adaptive performance of the system.

[0229] 5. A closed-loop feedback-based weight update and continuous optimization mechanism: By introducing user feedback signals, execution results, and a time decay model, a dynamic adjustment mechanism for knowledge graph weights is formed, enabling the elimination and reinforcement of experiential knowledge and constructing a continuously self-learning knowledge evolution system. This mechanism allows the agent to achieve "self-improvement" rather than static storage.

Claims

1. A knowledge-based optimization method for intelligent agent tools based on the evolution of experiential path graphs, characterized in that, include: When the agent successfully completes the task for the first time, it automatically records the agent's tool call sequence, input and output parameters and execution results, generates a structured call log, and transforms the call log into standardized call path knowledge units; The call path knowledge unit is simultaneously represented in both structured and semantic terms. The structured representation is stored in a graph database, and the semantic representation is stored in a vector database, forming a dual-modal knowledge storage. The dual-modal representation and storage are responsible for performing semantic and structural dual-modal representations on the call path knowledge unit and storing them in a heterogeneous database to form a searchable knowledge base. Based on graph databases and vector databases, an experience path knowledge graph is constructed using task intent, tool entity, and invocation path as heterogeneous nodes. The experience path knowledge graph is used to record the multidimensional relationship between tasks, paths, and tools, and to add execution performance attributes and feedback attributes to the path nodes in the graph, thereby completing the optimization of agent tool invocation knowledge. The automatic recording of the intelligent agent tool call sequence, input / output parameters, and execution results generates a structured call log, which is then transformed into standardized call path knowledge units, including: By using an experience-based proxy in an aspect-oriented programming approach, data from the tool invocation process is collected at both the pre- and post-invocation aspects. Once the task is marked as successfully completed, the collected call process data is aggregated and serialized into an execution trace; The execution trace is abstracted by the path generalization service to identify and generalize key entities in the user request, and generate a standardized call path knowledge unit containing tool sequence, generalization parameters and data pattern information.

2. The intelligent agent tool invocation knowledge optimization method based on experience path graph evolution according to claim 1, characterized in that, Following the step of constructing an experience path knowledge graph based on graph and vector databases, using task intent, tool entities, and invocation paths as heterogeneous nodes, the following further includes: When the agent receives a new task, it recalls path knowledge units from the vector database through semantic similarity, and then performs structural screening and performance evaluation in the experience path knowledge graph to select the optimal candidate path for parameter mapping and transfer reuse.

3. The intelligent agent tool invocation knowledge optimization method based on experience path graph evolution according to claim 2, characterized in that, When the agent receives a new task, it recalls path knowledge units from the vector database based on semantic similarity, then performs structure screening and performance evaluation in the experience path knowledge graph, and selects the optimal candidate path for parameter mapping and transfer reuse, including: The query is expanded and the data pattern is predicted for new task requests. The query semantic vector and pattern vector are generated. The vector database is searched in two channels. The results are merged by merging the results by the inverse ranking to obtain the candidate path set. For each path in the candidate path set, tool status checks and data flow compatibility verification are performed based on the token ring graph traversal algorithm, and a score is calculated by combining the path's historical performance to determine the optimal path.

4. The intelligent agent tool invocation knowledge optimization method based on experience path graph evolution according to claim 3, characterized in that, When the agent receives a new task, it recalls path knowledge units from the vector database based on semantic similarity, then performs structural screening and performance evaluation in the experience path knowledge graph, and selects the optimal candidate path for parameter mapping and transfer reuse. This also includes: Analyze the semantics of new tasks to identify task intent, key entities, and input variables; Select the optimal candidate path as a template and establish a mapping rule between the new task parameters and the template path parameters; Generate a call path adapted to the new task based on the mapping rules, and perform logical integrity and data dependency consistency checks.

5. The intelligent agent tool invocation knowledge optimization method based on experience path graph evolution according to claim 1, characterized in that, Following the step of constructing an experience path knowledge graph based on graph and vector databases, using task intent, tool entities, and invocation paths as heterogeneous nodes, the following further includes: Continuously collect task execution feedback data, and adjust the weights of path nodes in the experience path knowledge graph based on the feedback data and time decay model to realize the self-evolution and path elimination of the experience path knowledge graph; When a tool in the call path is detected to be faulty, the system searches for semantically similar alternative tools or path fragments through the experience path knowledge graph to dynamically repair the call chain and generate new call path knowledge units based on the repair results.

6. The intelligent agent tool invocation knowledge optimization method based on experience path graph evolution according to claim 5, characterized in that, The dynamic repair of the call chain includes: When path verification fails, obtain the upstream and downstream tools and data pattern information of the failed path; Perform shortest path search in the knowledge graph to find alternative path fragments with limited graph bridging length, consisting of active tools; The original call chain is rewritten using the found alternative fragments to generate a temporary fix path; If the repair path is successfully executed and positive feedback is obtained, a new call path knowledge unit is generated.

7. The intelligent agent tool invocation knowledge optimization method based on experience path graph evolution according to claim 1, characterized in that, The generation of the standardized call path knowledge unit includes: The path generalization service collects raw trace logs generated by recording the successful task execution process of the agent by subscribing to a message queue; Obtain the corresponding original user request text based on the session identifier in the original trace log; The named entity recognition model is used to analyze the user request text and extract key entities and their values. The input parameters of each tool call step in the original tracking log are traversed, and the parameter values ​​are matched with the key entity: if the match is successful, the parameter is generalized into a variable placeholder; if the match is unsuccessful, the parameter is retained as a fixed configuration value, thus completing the input parameter generalization. Retrieve the output data profile information asynchronously extracted during the tool call and populate it into the output data pattern field; Generate a hash value for a normalized path signature based on the tool call sequence and the parameter keys after generalization of the input parameters; Based on the generalized parameters of the input parameters, the output data pattern field, and the hash value, a standardized call path knowledge unit is generated.

8. The intelligent agent tool invocation knowledge optimization method based on experience path graph evolution according to claim 1, characterized in that, The semantic representation is achieved by constructing a rich semantic description document containing task intent, trigger template and tool description information, and using a sentence embedding model to generate corresponding semantic vectors. The semantic representation maps input and output data patterns in the call path knowledge unit to a predefined global data pattern vocabulary and generates multi-hot encoded interface pattern vectors. The structured representation is used to describe inter-tool dependencies and data flow relationships.

9. The intelligent agent tool invocation knowledge optimization method based on experience path graph evolution according to claim 1, characterized in that, The aforementioned knowledge graph of experience paths, constructed based on graph and vector databases and using task intent, tool entities, and invocation paths as heterogeneous nodes, includes: Periodically cluster paths under the same task intent based on tool sequence similarity and merge similar paths; Regularly clean up path nodes and their associated relationships whose weights are below the threshold or have not been used for a long time.

Images