A tool generation method and system based on cloud script dynamic registration

Abstract

The application discloses a tool generation method and system based on cloud script dynamic registration, and relates to the information technology field.The method comprises the following steps: obtaining cloud script records and analyzing and generating tool contract data, comparing the tool contract data with local effective contracts to obtain a contract degree, and matching and registering a migration mode; dynamically compiling the script to be generated, isolating and loading the script, and verifying a candidate instance, writing the candidate instance into a candidate registration table after consistency is achieved, generating a version route, switching a new call to the candidate instance, keeping an old call to an old instance, recycling the old instance after the old instance is closed, and generating a registration result. Through tool contract comparison, candidate call consistency verification, version route and old instance closed recycling, accurate migration, controlled release and smooth switching in the cloud script dynamic registration process are realized.

Description

Technical Field

[0001] This invention relates to the field of information technology, specifically to a method and system for generating tools based on cloud-based script dynamic registration. Background Technology

[0002] With the increasing integration of intelligent agents, business middleware, and production execution systems, the generation of business tools is gradually shifting from fixed plugin deployment to scripted configuration and unified cloud management. Cloud script repositories can centrally store script records from different business scenarios, describing tool entry points, call parameters, return structures, and runtime contexts through script declaration information, enabling local systems to acquire new tool capabilities without redeploying the main program. Existing systems typically use methods such as scheduled fetching, metadata parsing, dynamic compilation, reflection loading, or plugin registration to convert cloud scripts into locally callable tools, thereby improving tool expansion efficiency and business adaptation speed.

[0003] However, in environments where agents continuously invoke tools, updates to cloud-based scripts involve more than just changes in script content. They can also include synchronized changes to tool entry points, parameter fields, return structures, context resources, and script states. Current methods often rely on script version numbers, update times, or file content differences as the basis for updates, directly performing recompilation, reloading, and registration overwrites, lacking an understanding of the contractual relationship between the old and new tools. When there are changes in entry points, missing fields, or inconsistent context authorization between the new script and the locally active tool, the agent may still initiate calls according to the old contract, while the actual execution target has switched to the new script instance, leading to call failures, mismatched return structures, or abnormal resource access.

[0004] Meanwhile, existing dynamic registration methods typically focus on whether new tool instances can be loaded successfully, but lack constraints on whether candidate tool instances conform to the tool contract and whether they can complete contract call verification in a controlled context. If a candidate tool instance enters the visible tool list without verification, it may lead to abnormal scripts being released to the runtime environment. For calls to older versions that are currently being executed, conventional overriding registration is also prone to mixing newly initiated calls and calls in transit, resulting in inconsistencies in tool versions within the same session. In addition, after being replaced, old tool instances may still have session occupation, resource references, or unreleased isolated loading contexts. If only the registration item is deleted without completing the closed recycling, invalid instance residues and runtime resource consumption are likely to occur. Therefore, a cloud-based script dynamic registration tool generation method is needed that can coordinate tool contract acceptance, candidate call verification, version routing, and old instance recycling. Summary of the Invention

[0005] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a tool generation method and system based on cloud script dynamic registration to solve the above-mentioned technical problems.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a tool generation method based on cloud-based script dynamic registration, comprising: Retrieve script records from the cloud script repository, parse the tool declaration information and script status information in the script records to generate tool contract data; The tool contract data is compared with the locally effective tool contract data to generate the tool contract acceptance degree; The registration migration method is generated by matching registration migration rules based on tool contract acceptance and script status information; When registering the migration method corresponding to the tool generation path, the script records are dynamically compiled and isolated for loading to generate candidate tool instances. Based on the tool contract data, the candidate tool instances are verified by contract calls to generate candidate call consistency. When the consistency of candidate calls meets the release conditions, the candidate registration item corresponding to the candidate tool instance is written into the candidate registry, and a version routing relationship is generated based on the candidate registration item and the current call status. Based on the version routing relationship, newly initiated calls are switched to candidate tool instances, while calls that already occupy the old contract version are kept in the old tool instance; Based on the occupancy and release status of the old tool instance, generate the old instance closure degree. When the old instance closure degree meets the recycling conditions, deregister the old tool registration item and unload the old isolated loading context, generating the tool dynamic registration result.

[0007] The present invention is further configured such that obtaining script records from a cloud script repository and parsing the tool declaration information and script status information in the script records to generate tool contract data includes: The script records are read from the script index in the cloud script repository, and the fields of the script records are merged to obtain the script body, tool declaration section, status flags and reference dependencies; The tool declaration section is declaring boundaries and split into entry declaration, call declaration, and context declaration. The entry point declaration is processed to extract callable entry points and generate tool entry point data; the call declaration is processed to merge field direction, field type, and field constraints to generate call contract data; the context declaration is processed to merge resource category and scope to generate context contract data; and the status flags are processed to standardize status to generate script status data. The tool entry data, call contract data, context contract data, and script state data are bound together according to the script records to generate tool contract data.

[0008] The present invention is further configured such that the step of comparing the tool contract data with the locally effective tool contract data to generate the tool contract acceptance degree includes: Read the locally effective tool contract data corresponding to the script record from the local registration container, and align the tool contract data and the locally effective tool contract data to generate a correspondence between the old and new contracts; Based on the correspondence between the old and new contracts, the entry data of the tool is compared to identify the entry status of entry retention, entry mapping and entry missing, and the entry acceptance result is generated. Based on the correspondence between the old and new contracts, the fields of the call contract data are compared and identified to identify the retention status, compatible reception status and missing status of the old call fields in the new call contract, and call acceptance results are generated. Based on the correspondence between the old and new contracts, the authorization scope of the context contract data is compared, and the new context contract data is matched with the authorization resource scope of the current running environment to generate the context acceptance result. The entry acceptance results, call acceptance results, and context acceptance results are collected according to the corresponding script records to generate contract acceptance records. Based on the contract acceptance records, preset acceptance level rules are matched to generate the tool contract acceptance degree.

[0009] The present invention is further configured such that the step of generating a registration migration method by matching registration migration rules based on tool contract acceptance degree and script status information includes: Extract the contract acceptance level based on the tool contract acceptance degree, extract the script effectiveness status based on the script status data, and combine the contract acceptance level and script effectiveness status to generate a registration migration judgment record; The registration migration judgment record is prioritized for status identification. When the script's effective status is disabled or deleted, the offline recycling rule is matched to generate an offline recycling method. When the script is in the enabled state, the migration category is determined for the contract acceptance level; when the contract acceptance level corresponds to the complete acceptance state, the hot replacement rule or the compatible update rule is matched to generate the hot replacement method or the compatible update method. When the contract acceptance level corresponds to an incomplete acceptance state and the context acceptance result in the contract acceptance record is within the authorized scope, the shadow registration method is generated by matching the shadow registration rules. When the context acceptance result in the contract acceptance record exceeds the authorized scope, the blocking registration rule is matched to generate a blocking registration method; The registration migration methods include offline recycling, hot replacement, compatibility update, shadow registration, or blocking registration.

[0010] The present invention is further configured such that, when registering the migration method corresponding to the tool generation path, dynamically compiling and isolating the script records to generate candidate tool instances includes: When the registration migration method is hot replacement, compatibility update, or shadow registration, the corresponding script record will be marked as a script record to be generated; Extract the script body and reference dependencies from the script record to be generated, and encapsulate the script body, reference dependencies and tool contract data into a script compilation unit for compilation input. The script compilation unit dynamically compiles to generate candidate executable files and compilation diagnostic records; When the compilation diagnostic record meets the loading conditions, an isolated loading context corresponding to the candidate executable file is created, and the candidate executable file is loaded into the isolated loading context to generate a candidate executable object; Based on the tool entry data in the tool contract data, candidate execution objects are bound to the entry point to generate candidate tool instances.

[0011] The present invention is further configured such that the step of verifying the contract calls of candidate tool instances based on tool contract data to generate candidate call consistency includes: Generate contract sample call data based on the call contract and context contract in the tool contract data; Configure the controlled runtime context according to the context contract, and place the candidate tool instance into the controlled runtime context; Based on the contract example call data, candidate tool instances are called to generate candidate call records, and the actual call results and actual context access results are extracted from the candidate call records. The actual call result is compared with the call contract in the tool contract data to generate a call result consistency record. The actual context access results are compared with the context contract in the tool contract data to generate a context access consistency record. Candidate call consistency is generated by matching candidate call level rules with call result consistency records and context access consistency records.

[0012] The present invention is further configured such that, when the consistency of candidate calls meets the release conditions, the candidate registration item corresponding to the candidate tool instance is written into the candidate registry, and the version routing relationship is generated based on the candidate registration item and the current call status, including: When the consistency of candidate calls meets the preset release conditions, read the candidate tool instance and the corresponding tool contract data, mark the release status of the candidate tool instance, and generate candidate registration items; Write the candidate registration entries into the candidate version area of ​​the candidate registry, and retain the old tool registration entries in the locally effective registry; Generate candidate contract versions based on candidate registration items, and establish registration mappings between candidate contract versions and candidate tool instances; Get the current call status, identify the contract version occupation of the current call status, and generate in-transit call records and newly initiated call records; Configure the routing relationships of candidate registration items, in-transit call records, and newly initiated call records to generate version routing relationships; When the consistency of candidate calls does not meet the preset release conditions, keep the old tool registration entries in the local effective registry in an effective state, and stop writing to the candidate registration entries corresponding to the candidate tool instances.

[0013] The present invention is further configured such that, according to the version routing relationship, switching newly initiated calls to candidate tool instances and maintaining calls that already occupy the old contract version to the old tool instance includes: Obtain tool call requests, perform session identification on tool call requests, and generate call session records; The call session records are matched with the in-transit call records and newly initiated call records in the version routing relationship to generate call routing discrimination results; When a new call is initiated corresponding to the route determination result, a candidate tool instance is read from the candidate registry, and the route target of the tool call request is bound to the candidate tool instance to generate a candidate instance route record; When the call route determination result corresponds to a call that has occupied an old contract version, the old tool instance is read from the local effective registry, and the route target of the tool call request is kept as the old tool instance to generate an old instance route record; Update the version routing relationship based on the candidate instance routing record and the old instance routing record, and update the session occupancy status of the old tool instance based on the old instance routing record.

[0014] The present invention is further configured such that, in generating the old instance closure degree based on the old tool instance's occupancy and release status, and deregistering the old tool registration item and unloading the old isolated loading context when the old instance closure degree meets the recycling conditions, the generation of the tool dynamic registration result includes: Read the session usage status of the old tool instance based on the old instance routing record, and read the resource reference status corresponding to the old tool instance based on the runtime context management record; The session occupancy status and resource reference status are merged to generate an old tool instance occupancy and release record. The occupancy and release record is then matched for closure status to generate the old instance closure degree. When the closure of the old instance does not meet the reclamation conditions, the old tool instance is kept in a waiting reclamation state, and the occupation release record is written to the lifecycle record of the old tool instance; When the closure of the old instance meets the recycling conditions, the old tool registration entry is deregistered from the local effective registry, and the binding relationship between the old tool instance and the runtime context is released; Read the old isolated loading context based on the isolated loading context identifier corresponding to the old tool registration item, perform unloading processing on the old isolated loading context to generate old instance reclamation records; The tool generates dynamic registration results based on candidate registration items, updated version routing relationships, and old instance recycling records.

[0015] This invention also provides a tool generation system based on cloud-based script dynamic registration, the system comprising: Script contract generation module: Retrieves script records from the cloud script repository, parses the tool declaration information and script status information in the script records to generate tool contract data; Contract Acceptance Comparison Module: Compares the tool contract data with the locally effective tool contract data to generate the tool contract acceptance degree; Registration migration matching module: Generates registration migration methods by matching registration migration rules based on tool contract acceptance and script status information; Instance generation and verification module: When registering the migration method and corresponding tool generation path, dynamically compile and isolate the script records to generate candidate tool instances, and verify the contract calls of the candidate tool instances based on the tool contract data to generate candidate call consistency. Candidate registration module: When the consistency of candidate calls meets the release conditions, the candidate registration item corresponding to the candidate tool instance is written into the candidate registry, and version routing relationship is generated based on the candidate registration item and the current call status; Version routing module: Switches newly initiated calls to candidate tool instances according to version routing relationships, and keeps calls that have occupied the old contract version to the old tool instance; Old instance reclamation module: Generates old instance closure based on the occupancy and release status of old tool instances. When the old instance closure meets the reclamation conditions, the old tool registration item is deregistered and the old isolated loading context is unloaded, generating dynamic tool registration results.

[0016] This invention provides a tool generation method and system based on cloud-based dynamic script registration. The method obtains script records from a cloud script repository, parses tool declaration information and script status information from the script records to generate tool contract data; compares the tool contract data with locally effective tool contract data to generate a tool contract acceptance degree; matches registration migration rules based on the tool contract acceptance degree and script status information to generate a registration migration method; when the registration migration method corresponds to the tool generation path, dynamically compiles and isolates the script records to generate candidate tool instances; verifies the contract calls of the candidate tool instances based on the tool contract data to generate candidate call consistency; when the candidate call consistency meets the release conditions, writes the candidate registration item corresponding to the candidate tool instance into the candidate registry; generates a version routing relationship based on the candidate registration item and the current call status; switches newly initiated calls to candidate tool instances according to the version routing relationship, and keeps calls that have occupied the old contract version to the old tool instance; generates an old instance closure degree based on the old tool instance's occupation and release status; when the old instance closure degree meets the recycling conditions, cancels the old tool registration item and unloads the old isolated loading context, generating a dynamic tool registration result. The beneficial effects include: 1. Improve the accuracy of tool migration matching: By parsing cloud scripts into tool contract data and comparing them with locally effective tool contract data, the registration migration method is determined by both the contract inheritance relationship and the script status, avoiding direct overwriting of registration based solely on script version or update time. 2. Reduce the risk of abnormal release of candidate tools: By verifying the contract calls of candidate tool instances obtained through dynamic compilation and isolated loading, and verifying the consistency between the call results and context access before writing to the candidate registry, the call anomalies caused by the mismatch between the candidate tool instance and the tool contract are reduced. 3. Ensure a smooth transition between old and new tool instances: Differentiate between newly initiated calls and calls that have occupied the old contract version through version routing relationships, and control the unregistration of old tool registration items and the unloading of isolated loading contexts based on the closure of the old instance, thereby reducing interruptions in calls in transit and remnants of old instances.

[0017] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart illustrating a tool generation method based on cloud-based script dynamic registration is shown as an exemplary embodiment of the present invention. Figure 2 This is a schematic diagram illustrating the structure of a tool generation system based on cloud-based script dynamic registration, which is an exemplary embodiment of the present invention. Detailed Implementation

[0019] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0020] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0021] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0022] Example 1: A method for generating tools based on cloud-based script-driven dynamic registration, such as Figure 1 As shown, it includes: Retrieve script records from the cloud script repository, parse the tool declaration information and script status information in the script records to generate tool contract data; The tool contract data is compared with the locally effective tool contract data to generate the tool contract acceptance degree; The registration migration method is generated by matching registration migration rules based on tool contract acceptance and script status information; When registering the migration method corresponding to the tool generation path, the script records are dynamically compiled and isolated for loading to generate candidate tool instances. Based on the tool contract data, the candidate tool instances are verified by contract calls to generate candidate call consistency. When the consistency of candidate calls meets the release conditions, the candidate registration item corresponding to the candidate tool instance is written into the candidate registry, and a version routing relationship is generated based on the candidate registration item and the current call status. Based on the version routing relationship, newly initiated calls are switched to candidate tool instances, while calls that already occupy the old contract version are kept in the old tool instance; Based on the occupancy and release status of the old tool instance, generate the old instance closure degree. When the old instance closure degree meets the recycling conditions, deregister the old tool registration item and unload the old isolated loading context, generating the tool dynamic registration result.

[0023] The present invention is further configured such that obtaining script records from a cloud script repository and parsing the tool declaration information and script status information in the script records to generate tool contract data includes: The method reads script records from the script index in the cloud script repository, merges the fields of the script records, and obtains the script body, tool declaration section, status flag, and dependency references. Specifically, this method is applied to an intelligent agent tool service platform, which includes a cloud script repository, a script synchronization service, a local tool registration container, and a contract parsing component. The cloud script repository stores script records corresponding to different business tools. The script synchronization service reads the script index through an HTTP interface, a repository message subscription interface, or a timed polling interface. The script index identifies script records in the cloud script repository that have been added, modified, or have changed status. Its content includes the script identifier, script version, update time, script storage path, and script status field. During field merging, the script identifier and script version are used as the merging primary key, and the script body, tool declaration information, script status information, and dependency declaration information of the same script record are written into the same record to be parsed. For records that lack script body, lack tool declaration information, or have an empty script version, a field missing flag is generated, and the process stops proceeding to the subsequent contract parsing process. For records with complete fields, the script body, tool declaration section, status flag, and dependency references are output. The tool declaration section originates from the tool declaration information in the script record, the status marker originates from the script status information, and the reference dependencies originate from the dependency declaration information. This merging process ensures that the script body, declaration content, status information, and dependency information share the same data source identifier, providing complete input for subsequent tool contract data generation. In a specific implementation scenario, the script synchronization service accesses the cloud script repository in 60-second read cycles. When the cloud script repository supports event push, the script submission event, script enable event, or script disable event serves as the read trigger signal. The read script record includes the script body, tool declaration information, script status information, and dependency declaration information. Taking the order query tool as an example, the script identifier is tool_order_query, the version number is v2.1, the script body is the executable script code, the tool declaration information includes the entry name queryOrder, the input fields orderId and userToken, the output field orderStatus, the script status information is enabled, and the dependency declaration information is http-client-1.4. The tool declaration segment undergoes declaration boundary identification, splitting it into entry declarations, invocation declarations, and context declarations. Specifically, the tool declaration segment is structured or semi-structured declaration content extracted from script records, describing how the script can be invoked by the system. Tool declaration segments can be in JSON, YAML, comment-based declarations, or key-value pair declaration formats. Declaration boundary identification distinguishes the start and end positions of different declaration blocks within the tool declaration segment. During declaration boundary identification, the contract parsing component reads the tool declaration segment line by line, identifying preset declaration keywords such as `tool`, `entry`, `input`, `output`, `context`, `resource`, `permission`, and `timeout`, and recording the line number and level of the corresponding keyword. If the tool declaration segment is in JSON or YAML format, declaration boundaries are identified based on object key names and hierarchical indentation; if the tool declaration segment is a comment-based declaration, declaration boundaries are identified based on preset comment prefixes and the range of consecutive comments. When a new sibling declaration keyword is encountered, or the indentation level of the current line is lower than that of the previous declaration block, the previous declaration block is considered to have ended. After declaration boundary identification, declaration blocks containing entry names, entry function names, entry class names, or method names are classified as entry declarations; declaration blocks containing input fields, output fields, field types, and field constraints are classified as call declarations; and declaration blocks containing resource categories, access permissions, runtime timeouts, environment variables, or external service scopes are classified as context declarations. For example, in the tool_order_query tool declaration segment, entry:queryOrder is classified as an entry declaration, input:orderId:string:required and output:orderStatus:string are classified as call declarations, and context:database:order_db:read is classified as a context declaration. Through this processing, entry information, call field information, and runtime context information mixed in the same tool declaration segment are separated into data from different contract sources. The process involves extracting callable entry points from entry declarations to generate tool entry data; merging field direction, field type, and field constraints in call declarations to generate call contract data; merging resource category and scope in context declarations to generate context contract data; and standardizing status flags to generate script status data. Specifically, this process involves extracting callable entry points from entry declarations to generate tool entry data; merging field direction, field type, and field constraints in call declarations to generate call contract data; merging resource category and scope in context declarations to generate context contract data; and standardizing status flags to generate script status data. In this embodiment, when extracting callable entry points from entry declarations, the entry name, entry type, and entry location information are read. Entry location information includes function name, class name, method name, or script export name. The contract parsing component first cleans up whitespace characters and standardizes the naming format of the entry name, and then matches the entry location information with the executable definitions in the script body. When the entry point is declared as `queryOrder`, and a function with the same name, `exports.queryOrder`, exists in the script body, `queryOrder` is marked as a callable entry point, and tool entry data is generated. Tool entry data includes the script identifier, script version, entry point name, entry point location path, and entry point invocation method. If the entry point declaration exists but the corresponding function definition is not found in the script body, the entry point is marked as missing, and the generation of corresponding tool entry data stops. When merging call declarations, input fields are grouped into the input parameter field set according to field direction, and output fields are grouped into the output parameter field set; declared types such as string, number, boolean, object, and array are converted to local unified type identifiers according to field type; and declared contents such as required, optional, range, enum, and format are converted into field constraint items according to field constraints. For example, `orderId:string:required` is merged into the input parameter field `orderId`, with a field type of string and a field constraint of required; `orderStatus:string` is merged into the output parameter field `orderStatus`, with a field type of string. After merging, call contract data is generated. When merging context declarations, declarations such as database, http, file, cache, and message are converted into resource categories; permission declarations such as read, write, readwrite, and limited are converted into scopes; and content such as timeout, env, and serviceScope are converted into runtime context constraints. For example, database:order_db:read is merged into a database resource, with the resource identifier order_db and the scope read-only.After merging, context contract data is generated. During state standardization, enabled and active are merged into an enabled state, disabled and offline into a disabled state, and deleted and removed into a deleted state. If a state flag is empty, it is written to a pending confirmation state according to the default state rules of the cloud script repository. After state standardization, script state data is generated. Through the above processing, entry points, call fields, context resources, and script states are all converted into a unified data format that the local tool registration container can recognize. The tool entry data, call contract data, context contract data, and script status data are bound together according to the script records to generate tool contract data. Specifically, the script identifier and script version are used as the binding primary keys, and the tool entry data, call contract data, context contract data, and script status data generated from the same script record are written into the same tool contract object. The tool contract object includes the tool identifier, contract version, entry contract, call contract, context contract, script status, and reference dependencies. Taking tool_order_query version v2.1 as an example, the final generated tool contract data includes: tool identifier is tool_order_query, contract version is v2.1, entry contract is queryOrder, call contract includes input parameters orderId, userToken, and output parameter orderStatus, context contract includes the read-only access scope of order_db, script status is enabled, and reference dependency is http-client-1.4. After binding, the tool contract data is written to the local contract cache and then passed to the subsequent tool contract acceptance and comparison process. In this example, if dynamic registration is based solely on the script version number or update time, the local system can only identify script changes but cannot distinguish whether the changes pertain to entry point changes, field changes, context changes, or script state changes. By adopting the processing method in this embodiment, cloud script records are converted into structured tool contract data containing entry point contracts, call contracts, context contracts, and script states. This allows subsequent registration and migration methods to be matched based on contract content, improving data integrity and migration accuracy during the dynamic registration process of cloud scripts.

[0024] The present invention is further configured such that the step of comparing the tool contract data with the locally effective tool contract data to generate the tool contract acceptance degree includes: This method reads locally effective tool contract data corresponding to script records from the local registration container, and aligns the tool contract data and locally effective tool contract data to generate a new and old contract correspondence. Specifically, this method is applied to the tool update scenario of the intelligent agent tool service platform. The input objects include newly generated tool contract data in the cloud script repository and locally effective tool contract data that is already in effect in the local registration container. The local registration container provides a list of effective tools through a local registry interface, and the reading frequency is consistent with the script synchronization cycle, for example, once every 60 seconds. When there is a change event in the local registry, the reading is triggered by the registry change event. The read data includes tool identifier, contract version, entry contract, calling contract, context contract, and effective status. When aligning contract objects, the same tool is first matched according to the tool identifier, and then the currently effective version is selected as the old contract object according to the effective time of the contract version. The newly generated tool contract data in the cloud is used as the new contract object. If the tool identifiers are consistent, a new and old contract correspondence is generated; if the new tool contract data does not have a corresponding tool identifier in the local registration container, it is marked as a new contract relationship; if the locally effective tool contract data does not have a corresponding object in the cloud script records, it is marked as a contract relationship to be taken offline. Taking the order query tool `tool_order_query` as an example, the local version is v2.0, while the cloud-based script-generated version is v2.1. Since both tools share the same identifier, a new and old contract correspondence of "v2.0—v2.1" is generated. This step ensures that subsequent entry points, fields, and context comparisons are limited to the same tool object, avoiding mismatches across tools. Based on the correspondence between the old and new contracts, an entry point acceptance comparison is performed on the tool entry data to identify the acceptance status of entry point retention, entry point mapping, and entry point absence, generating entry point acceptance results. Specifically, the entry point acceptance comparison is used to determine whether the old version tool call entry point can still be called in the new version tool contract. The entry point acceptance comparison reads the old entry contract and the new entry contract from the correspondence between the old and new contracts. The old entry contract comes from the locally effective tool contract data, and the new entry contract comes from the tool entry data obtained from cloud script parsing. During the comparison, the entry name and entry location path are compared first. When the old entry name and the new entry name are the same, and there is an executable entry in the new script corresponding to the old entry location path, an entry retention status is generated. If the old entry name and the new entry name are different, but there is an entry alias, entry mapping table, or compatible entry declaration in the new tool contract data, and the mapping relationship points to an executable entry point, an entry mapping status is generated. If the old entry name does not exist in the new entry contract, and no corresponding entry mapping relationship is found, an entry absence status is generated. For example, if the old version's entry point is `queryOrder`, and the new version still retains `queryOrder`, the entry point continuation result is "entry point retained"; if the old version's entry point is `queryOrder`, and the new version's entry point is changed to `queryOrderV2`, but `oldEntry=queryOrder` and `newEntry=queryOrderV2` are declared, the entry point continuation result is "entry point mapped"; if the new version deletes `queryOrder` and does not declare a mapping, the entry point continuation result is "entry point missing". The entry point continuation result is written to the entry field of the contract continuation record for subsequent continuation level determination. Based on the correspondence between the old and new contracts, a field acceptance comparison is performed on the call contract data to identify the retention status, compatible acceptance status, and missing status of old call fields in the new call contract, generating call acceptance results. Specifically, the call contract data includes a set of input parameter fields, a set of output parameter fields, field types, and field constraints. The field acceptance comparison searches the corresponding fields in the new call contract item by item based on the old call fields. For input parameter fields, if a required field from the old version still exists in the new call contract, the field type is consistent, and the field constraint has not changed from loose to strict, it is marked as retained. If the field name has changed, but there is a field alias, field mapping, or type compatible acceptance rule in the new call contract (e.g., the old field userId is mapped to accountId, and both fields are of string type), it is marked as compatible acceptance. If a required field from the old version does not exist in the new call contract and there is no corresponding mapping relationship, it is marked as missing. For output parameter fields, if the old version's output field is still output in the new calling contract, and the field type is consistent or compatible for conversion, it is marked as retained. If the output field is inherited through nested path changes, for example, the old field `orderStatus` is changed to `result.orderStatus`, and the new contract declares the output path mapping, it is marked as compatible for receiving. If the old version's key output field disappears, it is marked as missing. Taking `tool_order_query` as an example, the old version's input parameters are `orderId` and `userToken`. The new version continues to retain `orderId` and `userToken`, while adding an optional field `tenantId`. In this case, all old calling fields are retained, and adding an optional field does not reduce the inheritance of the old call. If the new version deletes `userToken` and requires `sessionKey` as a required field, and no mapping relationship is declared, then `userToken` is in a missing state. After the field inheritance comparison is completed, the states of each field are merged into the call inheritance result and written to the contract inheritance record. Based on the correspondence between the old and new contracts, the authorization scope of the context contract data is compared. The new context contract data is matched with the authorized resource scope of the current runtime environment to generate a context succession result. Specifically, the context contract data represents the resource categories and scopes that the candidate tool instance needs to access at runtime. The authorized resource scope of the current runtime environment comes from the resource authorization table, runtime security policy, and tenant permission configuration of the tool service platform. The resource authorization table is read through the local permission management interface, and the data includes resource category, resource identifier, access permission, scope, and validity status. During the authorization scope comparison, the resource categories and scopes in the new context contract data are first extracted and then matched with the authorized resource scope of the current runtime environment. When the resource category, resource identifier, and access permissions in the new context contract all fall within the scope of the authorized resource, an authorized acceptance state is generated. When the resource category remains the same but the access permissions are expanded (e.g., the old version only required `database:order_db:read`, while the new version requires `database:order_db:write`), and the current runtime environment has not granted write permissions, an over-authorization state is generated. When the new version adds a new resource category, such as adding `file:local_path:write`, but the runtime environment has not configured the corresponding resource authorization, a resource unauthorized state is generated. Taking the order query tool as an example, if the new version still accesses `order_db` with read permissions, the context acceptance result is authorized acceptance; if the new version adds write access to `payment_db`, and the current environment has not authorized this resource, the context acceptance result is out of authorization scope. The context acceptance result is used to prevent script updates from bypassing runtime authorization constraints and entering the candidate release process. The entry point acceptance results, call acceptance results, and context acceptance results are aggregated according to their corresponding script records to generate contract acceptance records. Based on these contract acceptance records, preset acceptance level rules are matched to generate the tool contract acceptance degree. Specifically, the contract acceptance record is a structured record formed by aggregating entry point acceptance results, call acceptance results, and context acceptance results according to script identifiers and contract versions. It is used to represent the acceptance status of the new tool contract over the old tool contract. Preset acceptance level rules are stored in the rule configuration table of the local registration container and are pre-configured by the platform administrator according to the tool's operating strategy. The rules include four levels: complete acceptance, compatible acceptance, restricted acceptance, and no acceptance. Specifically, when the entry point acceptance result is "entry point retained," the required input parameters and key output parameters of the old version are both retained, and the context acceptance result is "authorized acceptance," the full acceptance level is matched. When the entry point acceptance result is "entry point mapping," the required fields of the old version are received by the new calling contract through field mapping or type compatibility, and the context acceptance result is still within the authorized range, the compatible acceptance level is matched. When the entry point can accept the contract but there are newly added required fields, changes in key output paths, or some optional fields are missing, the restricted acceptance level is matched. When the entry point is missing, the required fields of the old version are missing, or the context acceptance result is in an over-authorized state, the non-acceptance level is matched. The tool contract acceptance degree is represented by the above level results. For example, when tool_order_query is upgraded from v2.0 to v2.1, the entry point is retained, orderId and userToken are both retained, tenantId is added as an optional field, and the order_db access permission is still read. Then the contract acceptance record matches the full acceptance level, and the tool contract acceptance degree is generated as full acceptance. If the entry point is renamed in another version but an entry point mapping is provided, and the fields continue to be received through the mapping while the context is still authorized, then the tool contract acceptance degree is generated as a compatible acceptance. Through this closed-loop process, the system can transform the changes in entry points, called fields, and context authorization between the old and new contracts into acceptance results that can be directly used by registration migration rules, providing a clear basis for subsequent hot replacement, compatible updates, shadow registration, or blocking registration.

[0025] The present invention is further configured such that the step of generating a registration migration method by matching registration migration rules based on tool contract acceptance degree and script status information includes: The contract acceptance level is extracted based on the tool contract acceptance degree, and the script effectiveness status is extracted based on the script status data. The contract acceptance level and script effectiveness status are combined to generate a registration migration judgment record. Specifically, this method is applied to the script update decision-making stage of the intelligent agent tool service platform. The input objects include the tool contract acceptance degree, script status data, and contract acceptance record generated in the previous process. The tool contract acceptance degree comes from the acceptance comparison result between the new tool contract data and the locally effective tool contract data, and is used to indicate whether the new script can inherit the entry point, call fields, and context resources of the old version tool. The script status data comes from the script status information in the cloud script repository, and after status standardization, it forms the enabled, disabled, or deleted status. The platform reads the above data in a 60-second script synchronization cycle; when the cloud script repository pushes an enable, disable, or delete event, it reads the data immediately according to the event triggering method. After reading, the tool contract acceptance degree, script status data, and contract acceptance record are first aligned according to the script identifier and contract version, and abnormal records with inconsistent script identifiers, empty version numbers, or missing status fields are removed. After alignment, contract acceptance levels (full acceptance, compatible acceptance, limited acceptance, or no acceptance) are extracted from the tool contract acceptance level. Script effectiveness status (enabled, disabled, or deleted) is extracted from the script status data. The script identifier, contract version, contract acceptance level, script effectiveness status, and context acceptance result are then written into the same registration migration judgment record. For example, if the new version of `tool_order_query` is v2.1, the contract acceptance level is full acceptance, the script effectiveness status is enabled, and the context acceptance result is within the authorized scope, then a corresponding registration migration judgment record is generated. This record serves as the unified input for registration migration rules, enabling subsequent judgment processes to consider both script status and contract acceptance simultaneously. The registration migration decision record is evaluated based on its status. When the script's effective status is disabled or deleted, the offline recycling rule is matched to generate an offline recycling method. Specifically, status priority means that when matching registration migration rules, the script's effective status is read first, followed by the contract acceptance level. Registration migration rules are stored in the rule configuration table of the local registration container. The rule configuration table includes status conditions, acceptance conditions, context conditions, and migration actions. When performing status priority evaluation on the registration migration decision record, the script's effective status field is read first. When the script's effective status is disabled or deleted, hot replacement, compatibility update, or shadow registration judgments are skipped, and the offline recycling rule is matched directly. The offline recycling rule is used to generate the offline recycling method. Its actions include marking the corresponding old tool registration item as pending offline, preventing the generation of new candidate tool instances for this script version, and transferring the existing old tool instance to the subsequent old instance to close the recycling process. Taking `tool_order_query` as an example, if the cloud script repository marks v2.1 as disabled, the script synchronization service will read this status, generate a disabled status, register migration judgment records to match the offline recycling rules, and output the offline recycling method. By prioritizing this status, disabled or deleted scripts will not continue to enter the candidate generation path, preventing scripts that have been revoked by the cloud management terminal from being compiled and loaded again. When the script's effective status is "Enabled," the contract acceptance level is used to determine the migration category. When the contract acceptance level corresponds to a complete acceptance status, a hot-replacement rule or a compatible update rule is matched to generate a hot-replacement method or a compatible update method. Specifically, when the script's effective status in the registration migration determination record is "Enabled," the registration migration matching component reads the contract acceptance level field and proceeds to migration category determination. A complete acceptance status indicates that the new tool contract can accept the entry contract, required input parameters, key output parameters, and context authorization scope from the old tool contract. In a complete acceptance status, the entry acceptance result, call acceptance result, and reference dependency changes in the contract acceptance record are read. When the entry acceptance result is "entry retained," the old version's required input parameters and key output parameters are both in a retained state, and the reference dependencies have not undergone runtime changes, a hot-replacement rule is matched to generate a hot-replacement method. The hot-replacement method is used to indicate that subsequent processes can dynamically compile and isolate the script record for loading, and directly switch to a newly initiated call after candidate verification. When the entry point remains and all old fields are retained, but optional fields are added, dependency versions are upgraded, or extended fields are added to the output fields, the compatibility update rules are matched to generate a compatibility update method. The compatibility update method is used to instruct subsequent processes to generate candidate tool instances while preserving the compatibility relationships of the old calls. Taking `tool_order_query` as an example, if only the internal query logic of the script is modified from v2.0 to v2.1, and the entry point `queryOrder`, input parameters `orderId` and `userToken`, and output parameter `orderStatus` remain unchanged, and the dependencies are unchanged, then a hot-replacement method is generated; if v2.1 adds an optional input parameter `tenantId` and the dependency is upgraded from `http-client-1.4` to `http-client-1.5`, then a compatibility update method is generated. This judgment process ensures that different update forms under the complete acceptance state enter the corresponding generation paths. When a contract acceptance level corresponds to an incomplete acceptance state and the context acceptance result in the contract acceptance record is within the authorized scope, a shadow registration method is generated by matching shadow registration rules. Specifically, incomplete acceptance states include compatible acceptance, restricted acceptance, and partial non-acceptance, manifested as changes in the entry name but the existence of a mapping relationship, changes in field paths but the existence of field mappings, the addition of required fields in the new version, and changes in key output parameter paths. After identifying an incomplete acceptance state, the registration migration matching component further reads the context acceptance result in the contract acceptance record. If the context acceptance result shows that the resource category, resource identifier, and access permissions of the new context contract data are all within the authorized scope of the current runtime environment, then a shadow registration method is generated by matching shadow registration rules. The shadow registration method is used to instruct subsequent processes to generate candidate tool instances and write them to the isolated candidate area of ​​the candidate registry, performing contract call verification and version routing configuration before formally exposing them to the agent for invocation. For example, the new version of tool_order_query changes the entry queryOrder to queryOrderV2 and provides an entry mapping; the old input parameter userToken is changed to accessToken and a field mapping is provided; the context remains order_db read-only access. This scenario falls under the category of incomplete acceptance but within the scope of contextual authorization. It matches the shadow registration rules and generates a shadow registration method. Through shadow registration, the new script can enter the controlled verification process without immediately overwriting the old tool instance, allowing tool updates with changed entry points or fields to obtain independent verification space. When the context acceptance result in the contract acceptance record exceeds the authorized scope, a blocking registration rule is matched to generate a blocking registration method. Specifically, an context acceptance result exceeding the authorized scope means that the resource category, resource identifier, or access permission requested by the new context contract data exceeds the authorized resource scope of the current runtime environment. The registration migration matching component reads the context acceptance result in the contract acceptance record. When it identifies an over-authorization state, an unauthorized resource state, or an unauthorized permission expansion state, it matches a blocking registration rule to generate a blocking registration method. The blocking registration method is used to instruct subsequent processes to stop performing dynamic compilation and isolated loading on the script record, keep the locally effective tool registration item unchanged, and mark the script version as pending authorization processing. For example, the old version tool_order_query only accesses database:order_db:read, while the new version v2.2 requests database:payment_db:write, but the current runtime environment has not granted write permission to payment_db. In this case, the context acceptance result is exceeding the authorized scope, and the system generates a blocking registration method. Even if the entry and call fields of this version can inherit the old version, it will still stop entering the tool generation path because the runtime context exceeds the authorized scope. This process ensures that the registration migration process is consistent with runtime authorization control, preventing unauthorized script resource access from entering the candidate tool generation process; The registration migration method uses offline recycling, hot replacement, compatibility update, shadow registration, or blocking registration as its registration migration method. Specifically, the registration migration method is the output result after the registration migration rules are matched, and it is used to pass the execution path to subsequent candidate instance generation, candidate verification, version routing, or old instance recycling processes. The registration migration matching component writes the matched offline recycling, hot replacement, compatibility update, shadow registration, or blocking registration method into the registration migration record. The registration migration record includes script identifier, contract version, script effective status, contract acceptance level, context acceptance result, and final registration migration method. For hot replacement, compatibility update, and shadow registration methods, the corresponding script record is passed to the tool generation path; for offline recycling methods, the corresponding old tool instance is passed to the old instance closure recycling process; for blocking registration methods, the generation of candidate tool instances is stopped, and the old tool registration entry in the local effective registry is retained. Three examples are used for verification: In version 2.1 of `tool_order_query`, the entry point, fields, and context are all fully inherited, outputting a hot-swap method; in version 2.2 of `tool_order_query`, the entry point and fields are mapped and the context is authorized, outputting a shadow registration method; and in version 3.0 of `tool_payment_sync`, an unauthorized request to write to resources is made, outputting a blocked registration method. Through this closed-loop process, the registration migration method can generate a clear output based on the script status, contract inheritance level, and context authorization status, allowing subsequent processes to select the generation, verification, routing, or recycling path accordingly.

[0026] The present invention is further configured such that, when registering the migration method corresponding to the tool generation path, dynamically compiling and isolating the script records to generate candidate tool instances includes: When the registration migration method is hot replacement, compatibility update, or shadow registration, the corresponding script record is marked as a script record to be generated. Specifically, this method is applied to the tool generation stage of the intelligent agent tool service platform, which includes a script synchronization service, a registration migration matching component, a dynamic compilation component, an isolated loading component, and a local tool registration container. The input objects are the registration migration method, script record, and tool contract data output from the previous process. The registration migration matching component writes the registration migration method into the registration migration record, and the dynamic compilation component reads the registration migration record according to the script synchronization cycle. When a script change event is pushed from the cloud script repository, the dynamic compilation component reads it immediately based on the event identifier. After reading, the registration migration record is first filtered for validity, and records with empty script identifiers, empty script versions, missing script text, or missing tool contract data are removed. If the registration migration method is hot-swap, compatibility update, or shadow registration, the corresponding script record is marked as a script record to be generated and written to the generation queue. If the registration migration method is offline recycling, the corresponding old tool instance is passed to the old instance recycling process. If the registration migration method is blocking registration, the locally effective registration items remain unchanged and the dynamic compilation process is stopped. For example, version v2.1 of tool_order_query corresponds to the hot-swap method. The script text, tool contract data, and reference dependencies are all complete. The system writes the script record to the generation queue and generates a script record to be generated. This step ensures that only scripts that meet the generation conditions enter the compilation path, preventing disabled, deleted, or over-authorized scripts from being loaded as candidate instances. The script body and dependencies are extracted from the script record to be generated. The script body, dependencies, and tool contract data are then encapsulated as compilation input to generate a script compilation unit. Specifically, the script compilation unit is the standard input object of the dynamic compilation component, consisting of the script body, dependencies, tool contract data, and compilation environment configuration. The dynamic compilation component reads the script body and dependencies from the script record to be generated and the corresponding tool contract data from the local contract cache. After reading, the script body is preprocessed, including removing non-executable declaration comments, standardizing character encoding, validating script syntax markers, and standardizing newline characters. Dependency resolution is performed on the dependencies, including reading the dependency name, dependency version, dependency source, and dependency loading scope. Contract digest extraction is performed on the tool contract data, including extracting the tool identifier, contract version, entry contract, calling contract, and context contract. Subsequently, the script body, dependencies, and contract digest are encapsulated according to the script identifier and contract version to generate the script compilation unit. Taking version 2.1 of tool_order_query as an example, the script body contains the queryOrder function, which references http-client-1.4. The tool contract data includes the entry point queryOrder, input parameters orderId and userToken, output parameter orderStatus, and the read-only access scope of the context resource order_db. After encapsulation, these are formed into the corresponding script compilation unit. This step ensures that the compilation input simultaneously includes executable code, dependency information, and contract constraints, facilitating subsequent compilation diagnostics to locate script errors, missing dependencies, or inconsistent entry points. The script compilation unit dynamically compiles to generate candidate executable files and compilation diagnostic records. Specifically, dynamic compilation refers to converting the script compilation unit into candidate executable files that can be loaded by the local runtime while the host service is continuously running. The dynamic compilation component selects the corresponding compiler or interpreter based on the script type. For example, JavaScript scripts use the Node.js runtime for syntax checking and module packaging, Python scripts use an interpreter for pre-compilation and dependency environment checks, and C# scripts use the Roslyn compiler to generate assemblies. During compilation, syntax parsing is performed first to identify syntax errors, unclosed structures, and illegal keywords; then dependency parsing is performed to check if reference dependencies exist, if their versions meet requirements, and if dependencies are allowed to be loaded in the current isolated environment; then entry point verification is performed to check if the entry point contract in the tool contract data can locate the callable object in the compilation artifacts. After compilation, if syntax parsing, dependency parsing, and entry point verification all pass, candidate executable files are generated, and compilation diagnostic records are generated. The diagnostic records include script identifier, contract version, compilation status, dependency parsing results, entry point verification results, and diagnostic information. If syntax errors, missing dependencies, or missing entry points exist, the compilation diagnostic record is written with a failure status, and the generation of candidate executable files is stopped. For example, if the script syntax of version 2.1 of `tool_order_query` is correct, `http-client-1.4` exists in the allowed dependency list, and the `queryOrder` entry point can be located, then a candidate executable file `tool_order_query_v2_1.bundle` is generated, along with a compilation diagnostic record indicating a pass / fail status. This step transforms script executableness, dependency availability, and entry point existence into explicit diagnostic results, providing a basis for isolating loading conditions. When the compilation diagnostic record meets the loading conditions, an isolated loading context corresponding to the candidate executable file is created, and the candidate executable file is loaded into the isolated loading context to generate a candidate executable object. Specifically, the loading conditions include a passed compilation status, passed dependency resolution, passed entry point verification, and the candidate executable file's script identifier and contract version being consistent with the tool contract data. The dynamic compilation component passes the compilation diagnostic record to the isolated loading component, which reads and determines the loading conditions. When the loading conditions are met, an isolated loading context is generated based on the candidate executable file. The isolated loading context is a runtime isolated space corresponding to the candidate tool instance, used to record the candidate executable file, dependency loading path, context resource binding, runtime permissions, and lifecycle identifier. For JavaScript scripts, the isolated loading context can be an independent runtime sandbox or an independent module scope; for .NET assemblies, an independent AssemblyLoadContext can be used; for Python scripts, an independent interpreter environment or virtual environment identifier can be used. After creating the isolated loading context, the candidate executable file is loaded into this context, and the executable object within it is resolved to generate a candidate executable object. Taking tool_order_query_v2_1.bundle as an example, the isolated loading component creates a context identifier ctx_tool_order_query_v2_1, loads http-client-1.4 into the dependency path of this context, and then loads the candidate executable file to obtain a candidate executable object containing the queryOrder executable function. This step isolates the candidate executable file from the existing tool instance of the host service, preventing the candidate script's dependencies, variables, or resource references from affecting the already effective tool instance. Based on the tool entry data in the tool contract data, candidate execution objects are bound to entry points to generate candidate tool instances. Specifically, the tool entry data originates from the entry contract in the tool contract data, including the entry name, entry location path, and entry invocation method. After the isolated loading component reads the candidate execution object, it locates the callable entry point within the candidate execution object based on the tool entry data. During entry binding, functions, methods, or exported objects in the candidate execution object are first retrieved according to the entry location path. Once the corresponding entry point is located, the entry name, candidate execution object, isolated loading context identifier, and invocation adapter are bound to generate a candidate tool instance. The invocation adapter is used to convert the platform's unified tool invocation request into a invocation format that the candidate execution object can receive. Its content originates from the input parameter fields, field types, and field constraints in the invocation contract data. If the tool entry data is queryOrder, the entry location path is exports.queryOrder, and the invocation method is a synchronous function call, then the entry binding process establishes a binding relationship between the platform invocation entry queryOrder and exports.queryOrder in the candidate execution object, generating a candidate tool instance candidate_tool_order_query_v2_1. Candidate tool instances include a tool identifier, contract version, candidate execution object, entry point binding relationship, isolated loading context identifier, and pending verification status. After generation, the candidate tool instance is passed to the contract call verification process. In this instance, the closed-loop path from script recording in the cloud to the candidate tool instance is as follows: the v2.1 script record enters the pending generation queue, is encapsulated into a script compilation unit, dynamically compiled to generate a candidate execution file, formed through isolated loading to create a candidate execution object, and finally generated as a candidate tool instance based on the queryOrder entry point binding. Compared to direct overriding loading, this process completes compilation diagnosis, isolated loading, and entry point binding before candidate release, giving the candidate tool instance a clear script source, contract source, runtime context, and lifecycle identifier.

[0027] The present invention is further configured such that the step of verifying the contract calls of candidate tool instances based on tool contract data to generate candidate call consistency includes: This method generates sample call data based on the invocation contract and context contract in the tool contract data. Specifically, it is applied to the pre-release verification stage of candidate tools in the intelligent agent tool service platform. The input objects are the candidate tool instance and the corresponding tool contract data generated in the previous process. The tool contract data includes the invocation contract and the context contract. The invocation contract records the input parameter fields, output parameter fields, field types, and field constraints. The context contract records the resource categories, resource identifiers, and scopes that the candidate tool instance is allowed to access at runtime. The contract call verification component reads the tool contract data from the local contract cache and filters the fields of the invocation contract, removing undeclared fields, duplicate fields, and fields of empty type. It also filters the resource scope of the context contract, removing unauthorized resources and expired resources. Subsequently, sample call data is generated based on the type and constraints of the input parameter fields. The sample call data is a test call object used to verify whether the candidate tool instance can be called according to the tool contract. Its source is the tool contract data, not from manual random input. Taking the order query tool `tool_order_query` as an example, the call contract declares that the input parameters `orderId` and `userToken` are both strings and are required, and the output parameter `orderStatus` is a string; the context contract declares that read-only access to `order_db` is allowed. The contract call verification component generates sample call data: `orderId` is "ORD20240501001", `userToken` is "token_mock_001", and simultaneously generates a list of expected output parameter fields, `orderStatus`. This step ensures that candidate tool instances have explicit contract verification inputs before release; The controlled runtime context is configured according to the context contract, and the candidate tool instance is placed into the controlled runtime context. Specifically, the controlled runtime context is a temporary runtime environment created by the contract-invoking verification component to limit the range of resources that the candidate tool instance can access during the verification process. This context is configured according to the context contract and includes resource access proxies, permission boundaries, call timeouts, environment variables, and a context access logger. The resource access proxies are used to receive database, file, HTTP, cache, or message queue access requests from the candidate tool instance and allow or deny them according to the context contract. The context access logger is used to record the resource categories, resource identifiers, access permissions, and access times actually accessed by the candidate tool instance. Taking tool_order_query as an example, the context contract allows access to database:order_db:read, and the controlled runtime context is only configured with a read-only access proxy for order_db, prohibiting write operations and access to undeclared resources such as payment_db, file, and message. After the candidate tool instance candidate_tool_order_query_v2_1 is loaded into this controlled runtime context, all its external resource accesses are forwarded through the resource access proxies and recorded. This step enables contract call verification to simultaneously verify both the call result and runtime context access. Based on the contract sample call data, candidate tool instances are invoked to generate candidate call records. The actual call results and actual context access results are extracted from these records. Specifically, the contract call verification component initiates a sample call through the entry point binding relationship of the candidate tool instances. Before the call, the tool identifier, contract version, entry point name, and isolated loading context identifier in the candidate tool instance are read and verified to match the tool contract data. After successful verification, the contract sample call data is converted into a call format acceptable to the candidate tool instance entry point. During call execution, the call start time, call end time, entry point name, input parameter fields, return object, exception information, and context access log are recorded to generate candidate call records. The candidate call record is a complete record of the candidate tool instance after executing the contract sample call in a controlled runtime context. After the call is completed, the actual call results and actual context access results are extracted from the candidate call records. The actual call results include the return field name, return field type, return field level, return status, and exception information. The actual context access results include the resource category actually accessed, resource identifier, access permissions, and whether access was denied. Taking `tool_order_query` as an example, if a candidate tool instance returns `{orderStatus:"PAID"}` and actually accesses `database:order_db:read` without accessing other resources, the actual call result extracted from the candidate call record is the return object containing the `orderStatus` field, and the actual context access result is a read-only access to `order_db`. This step forms the test data required for subsequent consistency verification. The process involves verifying the consistency of the actual call result with the call contract in the tool contract data to generate a call result consistency record. Specifically, the call result consistency verification is used to determine whether the actual return of the candidate tool instance conforms to the call contract. The verification process is executed sequentially according to field existence, field type, field hierarchy, and exception status. First, the list of output parameter fields in the call contract is matched with the return fields in the actual call result. If the call contract requires the return of `orderStatus`, and `orderStatus` exists in the actual call result, the field existence is passed; if the field is missing, the field is recorded as missing. Second, the field type in the call contract is compared with the actual return field type. If the contract declares `orderStatus` as a string, and the actual return value is a string, the field type is passed; if the actual return value is an object or a number, the record type is inconsistent. Third, when the call contract declares that the return field is located at a specific path, the actual returned object is searched for the path; if the path matches, the field hierarchy is passed. Finally, exception information in the candidate call record is read; if no uncaught exceptions occur during the call, the exception status is passed. The verification results are written to the call result consistency record, which includes the tool identifier, contract version, sample call number, field existence result, field type result, field hierarchy result, and exception status result. Taking `tool_order_query` as an example, if the actual call result contains the string type `orderStatus` and there are no exceptions, the call result consistency record is in the "passed" state; if the returned field is `status` and no field mapping is declared, then `orderStatus` is recorded as missing. This step converts the business return of the candidate tool instance into determinate contract-consistent data. The actual context access results are compared with the context contracts in the tool contract data to generate context access consistency records. Specifically, the context access consistency verification is used to determine whether the resources actually accessed by the candidate tool instance during the verification process fall within the scope of the context contract. The verification process first reads the set of allowed resources in the context contract, and then reads the resource access list in the actual context access results. For each actual resource access, the resource category, resource identifier, and access permissions are compared sequentially. If the actual access is database:order_db:read, and the context contract contains the same resource category, the same resource identifier, and read-only permissions, then the access record passes; if the actual access is database:payment_db:read, but the context contract does not declare payment_db, then the resource is out of bounds is recorded; if the actual access is database:order_db:write, but the context contract only allows read, then the permission is out of bounds is recorded; if the candidate tool instance attempts to access the file system or external HTTP service, and the context contract does not declare the corresponding resource category, then the resource category is out of bounds is recorded. After verification, a context access consistency record is generated. This record includes the tool identifier, contract version, actual accessed resource list, allowed access resource list, out-of-bounds access flag, and permission out-of-bounds flag. Taking `tool_order_query` as an example, if the actual access is only read-only to `order_db`, the context access consistency record will show a "pass" status; if write access to `payment_db` is also granted, the context access consistency record will show a permission out-of-bounds status. This step ensures that the runtime resource behavior of candidate tool instances can be explicitly constrained before release. Candidate call consistency is generated by matching candidate call level rules based on call result consistency records and context access consistency records. Specifically, the candidate call consistency is candidate release judgment data generated based on the call result consistency and context access consistency of candidate tool instances, used to indicate whether a candidate tool instance meets the conditions for entering the candidate registry. Candidate call level rules are stored in the verification rule table of the local registration container, and its rule items include release level, isolation review level, and rejection level. Specifically, when both the call result consistency record and the context access consistency record are in a pass state, the release level is matched, and the candidate call consistency is generated as release consistent; when the call result consistency record has missing non-critical optional fields, and the context access consistency record is still in a pass state, the isolation review level is matched, and the candidate call consistency is generated as pending review consistent; when the call result consistency record has missing required output parameters, inconsistent field types, uncaught exceptions, or context access consistency records have resource out-of-bounds or permission out-of-bounds issues, the rejection level is matched, and the candidate call consistency is generated as inconsistent. Taking version 2.1 of `tool_order_query` as an example, the sample call returns the `orderStatus` string field. The actual access is only to the read-only resource `order_db`. Both the call result consistency record and the context access consistency record are in the "pass" state, and the candidate call consistency is generated as "release consistent" and passed to the candidate registry writing process. If another version returns an object lacking `orderStatus` or accesses an unauthorized `payment_db`, the candidate call consistency is generated as "inconsistent," and writing to the candidate registry stops. Through this closed-loop process, candidate tool instances complete dual verification of call results and context access before entering version routing, reducing release anomalies caused by mismatches between candidate tool instances and tool contracts.

[0028] The present invention is further configured such that, when the consistency of candidate calls meets the release conditions, the candidate registration item corresponding to the candidate tool instance is written into the candidate registry, and the version routing relationship is generated based on the candidate registration item and the current call status, including: When the candidate call consistency meets the preset release conditions, the candidate tool instance and its corresponding tool contract data are read, the candidate tool instance is marked with a release status, and a candidate registration item is generated. Specifically, this method is applied to the candidate release phase of the intelligent agent tool service platform, which includes a candidate tool instance management component, a contract verification component, a candidate registry, a locally effective registry, and a tool call gateway. Input objects include the candidate tool instance, tool contract data, and candidate call consistency generated in the previous process. The candidate call consistency, derived from the contract call verification process, indicates whether the actual call result and actual context access result of the candidate tool instance conform to the tool contract data. The preset release conditions are stored in the candidate release rule table, specifically: the call result consistency record is in a passed state, the context access consistency record is in a passed state, the candidate tool instance is in a pending release state, and the corresponding isolated loading context is in an available state. The candidate release component reads the candidate tool instance using the candidate call consistency generation event as a trigger signal; when no event trigger is configured, it scans the pending release candidate instance queue at 30-second intervals. After reading, the candidate tool instances and tool contract data are checked for consistency based on the tool identifier, contract version, and isolated loading context identifier. Records with inconsistent tool identifiers, inconsistent contract versions, or missing context identifiers are removed. If the candidate call consistency meets the preset release conditions, a release status flag is written to the candidate tool instance. The release status flag includes the pending routing, candidate effective time, and candidate version identifier. Subsequently, the candidate tool instance identifier, tool identifier, contract version, entry binding relationship, isolated loading context identifier, call contract summary, context contract summary, and release status flag are encapsulated into a candidate registration item. Taking version v2.1 of tool_order_query as an example, the candidate call consistency is release consistent. After the candidate tool instance candidate_tool_order_query_v2_1 passes the verification, the candidate registration item reg_candidate_tool_order_query_v2_1 is generated. The candidate registration entries are written to the candidate version area of ​​the candidate registry, while the old tool registration entries in the locally effective registry are retained. Specifically, the candidate registry is a registration data table in the local tool registration container used to store candidate tool instances that have not yet completed the formal switch. The candidate version area is a storage area in the candidate registry divided according to the tool identifier and contract version, used to store candidate registration entries. Before writing candidate registration entries, the candidate release component first reads the old tool registration entries corresponding to the same tool identifier in the locally effective registry. The old tool registration entries include the old tool instance identifier, the old contract version, the old entry binding relationship, and the old isolated loading context identifier. During writing, the tool identifier and the candidate contract version are used as the index keys of the candidate version area to write the candidate registration entries to the candidate registry; at the same time, the old tool registration entries in the locally effective registry are kept in an effective state and are not overwritten or deleted. If the candidate version area already contains candidate registration entries with the same tool identifier and the same contract version, the latest candidate registration entry is retained according to the candidate instance generation time, and the old candidate registration entries are marked as candidate expired. Taking `tool_order_query` as an example, the old tool registration entry in the local registry is `reg_active_tool_order_query_v2_0`. After `reg_candidate_tool_order_query_v2_1` is written to the candidate registry, the old tool registration entry remains effective. Through this process, the candidate release process forms a data structure where old and new registration entries coexist, providing a registration basis for the subsequent separation of old and new calls. Candidate contract versions are generated based on candidate registration entries, and a registration mapping is established between the candidate contract versions and candidate tool instances. Specifically, the candidate contract version is the version identifier used by the candidate registration entry in the version routing process, derived from the tool identifier, contract version, and candidate effective time in the candidate registration entry. When generating a candidate contract version, the candidate release component reads the tool identifier `tool_order_query`, contract version `v2.1`, and candidate effective time from the candidate registration entry, combining them into a candidate contract version identifier, such as `tool_order_query@v2.1`. Subsequently, a registration mapping between candidate contract versions and candidate tool instances is established in the candidate registry. The registration mapping includes the candidate contract version, candidate tool instance identifier, entry point binding relationship, isolation loading context identifier, and candidate status. The entry point binding relationship indicates the specific entry point that should be bound when a tool invocation request enters a candidate tool instance, such as `queryOrder`; the isolation loading context identifier indicates the runtime isolation space corresponding to the candidate tool instance, such as `ctx_tool_order_query_v2_1`. After the registration mapping is completed, the tool invocation gateway can retrieve the candidate tool instance through the candidate contract version, but the candidate tool instance has not yet directly replaced the old tool instance. Taking tool_order_query as an example, the candidate contract version tool_order_query@v2.1 is mapped to candidate_tool_order_query_v2_1, the entry point is queryOrder, and the isolated loading context is ctx_tool_order_query_v2_1; The system obtains the current call status and identifies the contract version occupancy of the current call status to generate in-transit call records and newly initiated call records. Specifically, the current call status is provided by the tool call gateway, sourced from the session table, request routing table, and tool instance occupancy table. The tool call gateway records the session identifier, request identifier, tool identifier, contract version occupancy, occupying tool instance, call start time, and call status each time an agent initiates a tool call. The call status includes started, executing, waiting for callback, and completed. The current call status can be read immediately by the candidate release component after generating candidate registration items, or it can be refreshed to the local call status cache by the tool call gateway at 1-second intervals. After reading, the current call status is preprocessed, including filtering call records of tools with the same tool as the candidate registration items according to the tool identifier, removing completed and released historical records, deduplicating duplicate request identifiers, and merging consecutive call records within the same session according to the session identifier. When identifying contract version occupancy, if a session or request occupying an old contract version exists in the call status record, the call is written to the in-transit call record; if the tool call request is not yet bound to a contract version, or belongs to a new session request after the candidate registration item is written, it is written to the newly initiated call record. The in-transit call record includes the session identifier, request identifier, old contract version, old tool instance identifier, and occupancy status; the newly initiated call record includes the session identifier, request identifier, target tool identifier, and pending allocation status. Taking tool_order_query as an example, if session S1001 already occupies v2.0 and is executing before the candidate release, an in-transit call record is generated; if session S1002 requests tool_order_query for the first time after the candidate registration item is written, a newly initiated call record is generated. Version routing relationships are generated by configuring routing relationships among candidate registration items, in-transit call records, and newly initiated call records. Specifically, the version routing relationship is the data structure used by the tool call gateway to determine whether a tool call request should enter a candidate tool instance or an old tool instance. During version routing configuration, the candidate contract version and candidate tool instance identifier are first read from the candidate registration items, then the old contract version and old tool instance identifier are read from the in-transit call records, and then routing rules are generated. Routing rules include the tool identifier, candidate contract version, old contract version, newly initiated call target, in-transit call target, and activation conditions. For newly initiated call records, the routing target is configured as the candidate tool instance; for in-transit call records, the routing target remains the old tool instance; for subsequent requests within the same session that already occupy the old contract version, the old tool instance continues to be bound until the session's occupancy is released. Taking `tool_order_query` as an example, the version routing relationship is configured as follows: the tool identifier `tool_order_query`, the candidate contract version v2.1 corresponds to `candidate_tool_order_query_v2_1`, and the old contract version v2.0 corresponds to `active_tool_order_query_v2_0`; newly initiated calls in session S1002 are routed to the v2.1 candidate tool instance, while in-transit calls in session S1001 remain routed to the v2.0 old tool instance. After configuration, the version routing relationship is written to the routing table of the tool call gateway, and the status of the candidate registration item is updated from pending routing to route effective. This step ensures that the candidate tool instance enters a controlled callable state after publication, while maintaining the continuity of calls occupied by the old contract version; When the candidate call consistency does not meet the preset release conditions, the old tool registration entry in the local effective registry remains active, and the writing of the candidate registration entry corresponding to the candidate tool instance is stopped. Specifically, situations where the candidate call consistency does not meet the preset release conditions include missing required output parameters, inconsistent field types, uncaught exceptions in the call result consistency record, or resource or permission out-of-bounds errors in the context access consistency record. After the candidate release component reads the candidate call consistency, if it does not match the release conditions, it does not generate a candidate registration entry, does not write it to the candidate version area of ​​the candidate registry, and keeps the old tool registration entry in the local effective registry active. For candidate tool instances that have been generated but not written to the candidate registry, their status is marked as release stopped, and the candidate tool instance identifier, failed verification item, and corresponding contract version are written to the candidate release log for retrieval during subsequent recompilation or reverification. Taking version v2.2 of `tool_order_query` as an example, if a candidate tool instance returns a field lacking `orderStatus`, and the candidate call consistency is inconsistent, then the candidate registration item is not written to the candidate registry, the old tool registration item `reg_active_tool_order_query_v2_0` remains effective, and the tool call gateway still calls the old tool instance according to the original route. Comparing this processing result with version v2.1, which meets the release conditions, v2.1 can generate candidate registration items and version routing relationships, while v2.2 stops candidate writing and keeps the old registration item effective. Through this closed-loop process, the candidate release process can form a clear release or stop release result based on the candidate call consistency, preventing candidate tool instances that have not passed contract verification from entering the call route.

[0029] The present invention is further configured such that, according to the version routing relationship, switching newly initiated calls to candidate tool instances and maintaining calls that already occupy the old contract version to the old tool instance includes: This method involves acquiring tool invocation requests and performing session identification to generate invocation session records. Specifically, this method is applied to the tool invocation gateway of the intelligent agent tool service platform. The tool invocation gateway is responsible for receiving tool invocation requests initiated by intelligent agents and selecting candidate tool instances or old tool instances as routing targets based on version routing relationships. Tool invocation requests originate from the intelligent agent execution engine, business process orchestrator, or external application interfaces, and the request access methods include HTTP interfaces, RPC interfaces, and message queue interfaces. When receiving a tool invocation request, the tool invocation gateway extracts the tool identifier, session identifier, request identifier, invocation time, invocation entry point, request parameters, and invocation source from the request. When the request does not carry a session identifier, a temporary session identifier is generated based on the invocation source, user identifier, and request link identifier. Before session identification, basic preprocessing is performed on the tool invocation request, including verifying whether the tool identifier is empty, removing duplicate request identifiers, standardizing the invocation time format, filtering timed-out requests, and requests lacking necessary entry fields. After preprocessing, the tool identifier, session identifier, request identifier, invocation entry point, request time, and request status are written into the invocation session record. For example, in session S1002, the agent requests to invoke the tool_order_query tool, with the entry point being queryOrder and the request identifier being REQ-002. The tool invocation gateway generates an invocation session record: tool identifier tool_order_query, session identifier S1002, request identifier REQ-002, invocation entry point queryOrder, and request status "pending routing". This step ensures that each tool invocation request forms identifiable and traceable session-level data, providing input for routing matching in subsequent versions. The call session records are matched with the in-transit call records and newly initiated call records in the version routing relationship to generate call routing discrimination results. Specifically, the version routing relationship is stored in the routing table of the tool call gateway, derived from the routing configuration results of candidate registration items, in-transit call records, and newly initiated call records. The version routing relationship includes the tool identifier, candidate contract version, candidate tool instance identifier, old contract version, old tool instance identifier, in-transit session set, newly initiated call conditions, and route effective status. After reading the call session records, the tool call gateway first retrieves the corresponding version routing relationship according to the tool identifier; if no version routing relationship exists, the original route is executed according to the currently effective tool instance in the local effective registry. If a version routing relationship exists, the session identifier and request identifier in the call session records are compared. When the session identifier already exists in the in-transit call record of the version routing relationship, or the session has occupied the old contract version and the occupation status has not been released, a call routing discrimination result for the occupied old contract version is generated; when the session identifier does not belong to the in-transit call record and the request status is pending routing, a call routing discrimination result for the corresponding newly initiated call is generated. Taking `tool_order_query` as an example, the version routing record shows that session S1001 occupies the old contract version v2.0, and the candidate contract version is v2.1. When the call session record is S1001, the result is that the call already occupies the old contract version; when the call session record is S1002 and the session does not occupy the old version, the result is that a new call is initiated. Through this matching process, the tool call gateway can distinguish between new and old call paths based on the session occupancy status. When the call routing determination result corresponds to a newly initiated call, a candidate tool instance is read from the candidate registry, and the route target of the tool call request is bound to the candidate tool instance to generate a candidate instance route record. Specifically, a newly initiated call refers to a tool call request that has not yet occupied the old contract version after the candidate registration item has been written to the candidate registry and the version routing relationship has taken effect. When the call routing determination result is a newly initiated call, the tool call gateway reads the candidate registry according to the candidate contract version in the version routing relationship. The candidate registry stores candidate registration items, which include the candidate tool instance identifier, candidate contract version, entry binding relationship, isolated loading context identifier, and candidate status. After reading the candidate registration item, it verifies whether the candidate status is that the route is effective and whether the isolated loading context corresponding to the candidate tool instance is in an available state; if the verification passes, the route target of the tool call request is bound to the candidate tool instance. Route target binding means writing the target contract version, target tool instance identifier, and entry binding relationship from the call session record into the request route cache of the tool call gateway, so that the request will subsequently enter the entry corresponding to the candidate tool instance. After binding is complete, a candidate instance route record is generated. The record includes the session identifier, request identifier, tool identifier, candidate contract version, candidate tool instance identifier, entry name, and route binding time. For example, when session S1002 requests `tool_order_query`, the tool call gateway reads `candidate_tool_order_query_v2_1` from the candidate registry, binds the target contract version of the request to `v2.1`, binds the target tool instance to `candidate_tool_order_query_v2_1`, and generates a candidate instance route record. This step enables the published candidate tool instance to accept newly initiated calls. When the call routing determination result corresponds to a call that uses an old contract version, the old tool instance is read from the local effective registry. The route target of the tool call request is maintained as the old tool instance, and an old instance route record is generated. Specifically, a call that uses an old contract version refers to a tool call that started execution before the candidate registration item was written, or a tool call that has been bound to an old contract version in the same session and has not been released from its occupied state. When the call routing determination result is a call that uses an old contract version, the tool call gateway reads the local effective registry based on the old contract version in the version routing relationship. The local effective registry stores old tool registration items, which include the old tool instance identifier, old contract version, old entry binding relationship, and old isolated loading context identifier. After reading the old tool registration item, it verifies whether the old tool instance is still in a callable or waiting-to-be-reclaimed state. When the old tool instance is still occupied by a session, the route target of the tool call request is maintained as the old tool instance, and its old contract version is retained. After binding is completed, an old instance route record is generated, and the record content includes the session identifier, request identifier, tool identifier, old contract version, old tool instance identifier, entry name, occupied state, and route retention time. For example, if session S1001 already uses version v2.0 of tool_order_query before the candidate release, and subsequently initiates a query request in the same session, the tool call gateway will continue to bind the request to active_tool_order_query_v2_0 and generate an old instance route record. This step ensures that calls using the old contract version maintain the original tool instance path, preventing subsequent requests in the same session from entering different contract versions. The version routing relationship is updated based on candidate instance routing records and old instance routing records. Specifically, after generating candidate instance routing records and old instance routing records, the tool invocation gateway writes both types of routing records back to the version routing relationship. For candidate instance routing records, they are written to the new call route set of the candidate contract version, and the number of route receptions and the most recent route time for the candidate tool instance are recorded. For old instance routing records, they are written to the in-transit call set of the old contract version, and the occupancy status of the corresponding session is updated. The session occupancy status of the old tool instance includes three states: occupied, releasing, and released, derived from old instance routing records, call completion callbacks, and timeout release records. When an old instance routing record is generated, the corresponding session is marked as occupied. When the tool invocation gateway receives the call completion callback for that session, and there are no incomplete requests under the same session, the occupancy status is updated to releasing. When the releasing status has been maintained for a preset time and no new old version requests appear, it is updated to released. The preset maintenance time can be set to 30 seconds to cover short delays in asynchronous callbacks or continuous requests. Taking `tool_order_query` as an example, the newly initiated call of S1002 is written into the v2.1 candidate route set, and the old version call of S1001 is written into the v2.0 in-transit call set. When the S1001 call is completed and no further requests for the old version tool are made within 30 seconds, the session occupancy status of the old tool instance `active_tool_order_query_v2_0` is updated to "released" and passed to the old instance closure generation process. Through this closed-loop process, the version routing relationship can continuously reflect the distribution status of newly initiated calls and old version occupied calls, and the occupancy release status of the old tool instance can be accurately read by the subsequent recycling process.

[0030] The present invention is further configured such that, in generating the old instance closure degree based on the old tool instance's occupancy and release status, and deregistering the old tool registration item and unloading the old isolated loading context when the old instance closure degree meets the recycling conditions, the generation of the tool dynamic registration result includes: This method reads the session occupancy status of the old tool instance based on the old instance routing record and the resource reference status corresponding to the old tool instance based on the runtime context management record. Specifically, this method is applied to the recycling phase after the switch between old and new tool instances in the intelligent agent tool service platform. The platform includes a tool invocation gateway, a local effective registry, a runtime context manager, and an instance lifecycle management component. Input objects include the old instance routing record generated in the previous process, the session occupancy status maintained by the tool invocation gateway, and the resource reference status maintained by the runtime context manager. The old instance routing record originates from the version routing process and records the session identifier, request identifier, old tool instance identifier, old contract version, and route retention time of the occupied old contract version. The session occupancy status is updated by the tool invocation gateway at the start of the call, the completion of the call, the return of an exception, and the timeout release, with statuses including occupied, releasing, and released. The runtime context management record is written by the isolated loading component during instance loading, resource binding, event subscription, scheduled task creation, and callback registration, and includes the isolated loading context identifier, resource reference identifier, reference category, reference status, and last access time. The instance lifecycle management component reads the above records every 5 seconds; when the tool invocation gateway sends an old instance call completion event, the reading is triggered immediately. Before reading, the old instance routing records are deduplicated and chronologically organized, retaining the last old instance routing record under the same session; the runtime context management records are filtered for valid states, removing released resources and expired references. Taking tool_order_query as an example, the old tool instance active_tool_order_query_v2_0 corresponds to the old contract version v2.0, and its session S1001 is in the process of being released. The runtime context ctx_tool_order_query_v2_0 still contains database connection references and callback listener references, which are read as session occupancy status and resource reference status respectively, providing input for subsequent closure judgment; The process involves merging session occupancy and resource reference states to generate an occupancy-release record for the old tool instance. This record is then used to perform closure matching to generate the old instance's closure degree. Specifically, the occupancy-release record is a structured record formed by merging whether the old tool instance is still occupied by sessions and resource references. The instance lifecycle management component first reads the session occupancy state. If a session is still occupying the same old tool instance, the release result is recorded as "not released." If no session is occupying the instance but a session is being released, the release result is recorded as "pending confirmation release." If all associated sessions are released, the release result is recorded as "released." Next, the resource reference state is read. If the runtime context still contains unclosed database connections, unregistered event subscriptions, unfinished scheduled tasks, uncompleted asynchronous callbacks, or unreleased file handles, the resource release result is recorded as "not released." If a resource reference has entered the closing process but has not yet received closing confirmation, the resource release result is recorded as "pending confirmation release." If all resource references have completed closing confirmation, the resource release result is recorded as "released." After merging, a release record is generated, containing the old tool instance identifier, old contract version, call release result, resource release result, list of unreleased sessions, and list of unreleased resources. During closure matching, if both the call release result and resource release result are released, the old instance closure is considered closed; if either result is pending confirmation of release, the old instance closure is considered pending closure; if either result is not released, the old instance closure is considered unclosed. For example, with `tool_order_query`, if S1001 has completed the call, but `ctx_tool_order_query_v2_0` still contains a callback listener reference, the resource release result is considered not released, and the old instance closure is considered unclosed. This process transforms the reclaimability of the old instance into a definite state jointly defined by session release and resource release. When the closure of an old instance does not meet the reclamation conditions, the old tool instance remains in a waiting-for-reclamation state, and the occupation and release record is written to the old tool instance's lifecycle record. Specifically, the reclamation conditions are stored in the reclamation rule table of the instance lifecycle management component, namely: the old instance closure is closed, there are no sessions occupying or releasing the old tool instance, the isolated loading context has no unclosed resource references, and the old tool registration item is not occupied by newly initiated calls. When the old instance closure is not closed or is pending closure, the instance lifecycle management component does not perform registration item deregistration and context unloading, and keeps the old tool instance in a waiting-for-reclamation state. The waiting-for-reclamation state indicates that the old tool instance has stopped receiving newly initiated calls, but still retains the occupation relationship of the old contract version or runtime resource references. Subsequently, the occupation and release record is written to the old tool instance's lifecycle record, which includes the instance creation time, candidate replacement time, waiting-for-reclamation start time, most recent occupation and release record, reason for not releasing, and next check time. The next check time can be set to 5 seconds after the current time; when the unreleased resource belongs to an asynchronous callback or scheduled task, the next check time can be set according to the timeout time of that resource. Taking `tool_order_query` as an example, the old instance `active_tool_order_query_v2_0` has stopped receiving new sessions, but a callback listener reference still exists. The system keeps it in a state waiting to be reclaimed and writes the unreleased resource as `callback_listener_01` in the lifecycle record. The next check time is 5 seconds later. This step prevents the old tool instance from being prematurely unloaded before the resources are closed. When the closure of the old instance meets the recycling conditions, the old tool registration entry is deregistered from the local effective registry, releasing the binding relationship between the old tool instance and the runtime context. Specifically, when the instance lifecycle management component reads that the old instance closure is closed and all recycling conditions in the recycling rule table are met, the old tool registration entry deregistration begins. Before deregistration, the old tool registration entry is read from the local effective registry. The old tool registration entry includes the old tool instance identifier, old contract version, old entry binding relationship, old isolated loading context identifier, and registration status. After reading, the registration status of the old tool registration entry is updated from "effective" or "awaiting recycling" to "deregistering," and the tool call gateway is stopped from generating new route bindings through the old contract version. Subsequently, the binding relationship between the old tool instance and the runtime context is released, including releasing the entry binding relationship, removing the index relationship from the tool instance to the isolated loading context, and deleting the route mapping from the old contract version to the old tool instance. Taking `tool_order_query` as an example, when S1001 has been released and there are no unclosed resource references in `ctx_tool_order_query_v2_0`, the system reads `reg_active_tool_order_query_v2_0` from the local registry, updates its status to "unregistering", and unbinds `active_tool_order_query_v2_0` from `ctx_tool_order_query_v2_0`. This process removes the old tool registration item from the routable scope, providing a prerequisite for unloading the isolated loading context. The old isolated loading context is read based on the isolated loading context identifier corresponding to the old tool registration item. An unloading process is then performed on the old isolated loading context to generate an old instance recycling record. Specifically, the old isolated loading context is the isolated runtime space used during the execution of the old tool instance, and its identifier comes from the isolated loading context identifier in the old tool registration item. The runtime context manager reads the corresponding context object based on this identifier, first performing a pre-unloading check to confirm that the entry point binding relationship has been released, resource references are in a released state, there are no incomplete asynchronous callbacks, and dependency handles are not closed. After the check passes, the unloading process is executed. For scripts using independent module scopes, the unloading process includes removing module caches, releasing dependency references, and cleaning up environment variables; for assemblies using independent AssemblyLoadContexts, the unloading process includes triggering context unloading, cleaning up assembly references, and waiting for unloading confirmation; for scripts using virtual environments or independent interpreter environments, the unloading process includes closing the interpreter session, releasing temporary files, and deleting the temporary environment identifier. After unloading is complete, an old instance recycling record is generated, containing the old tool instance identifier, old contract version, old isolated loading context identifier, deregistration time, unloading result, and resource release confirmation result. Taking `tool_order_query` as an example, the runtime context manager reads the old isolated loading context based on `ctx_tool_order_query_v2_0`, confirms that all resource references have been released, and then performs context unloading, generating an old instance recycling record `recycle_tool_order_query_v2_0`. This step completes the closed-loop release of the old tool instance from the registry, routing relationships, and runtime context. The tool dynamic registration result is generated based on candidate registration items, updated version routing relationships, and old instance recycling records. Specifically, the tool dynamic registration result is the final output data of this round of cloud script dynamic registration process, used to record the completion status of candidate tool instance release, new and old version routing switching, and old instance recycling. The instance lifecycle management component reads candidate registration items to obtain the new tool instance identifier, candidate contract version, and candidate registration status; reads the updated version routing relationships to obtain the candidate tool instance to which the newly initiated call points, the in-transit call release status of the old contract version, and the routing activation status; and reads old instance recycling records to obtain the old tool registration item cancellation result and the old isolated loading context unloading result. Subsequently, using the tool identifier and this round of migration batch number as the primary key, the above data is written into the tool dynamic registration result. The tool dynamic registration result includes the tool identifier, old contract version, new contract version, candidate registration item status, version routing status, old instance recycling status, and final registration status. Taking `tool_order_query` as an example, the candidate registration item `reg_candidate_tool_order_query_v2_1` for the new contract version v2.1 has been routed and taken effect. The old instance recycling record for the old contract version v2.0 shows that the registration item has been deregistered and `ctx_tool_order_query_v2_0` has been uninstalled. Therefore, the tool's dynamic registration result is recorded as v2.1 registration complete and v2.0 recycling complete. If the old instance closure condition is not met, the tool's dynamic registration result is recorded as the candidate version has been routed and taken effect, and the old version is awaiting recycling. Through this closed-loop process, the cloud script forms a traceable final result from candidate release to old instance recycling, facilitating subsequent auditing, fault location, and re-registration / migration.

[0031] Example 2: Please see Figure 2 This exemplary tool generation system based on cloud-based script dynamic registration includes: Script contract generation module: Retrieves script records from the cloud script repository, parses the tool declaration information and script status information in the script records to generate tool contract data; Contract Acceptance Comparison Module: Compares the tool contract data with the locally effective tool contract data to generate the tool contract acceptance degree; Registration migration matching module: Generates registration migration methods by matching registration migration rules based on tool contract acceptance and script status information; Instance generation and verification module: When registering the migration method and corresponding tool generation path, dynamically compile and isolate the script records to generate candidate tool instances, and verify the contract calls of the candidate tool instances based on the tool contract data to generate candidate call consistency. Candidate registration module: When the consistency of candidate calls meets the release conditions, the candidate registration item corresponding to the candidate tool instance is written into the candidate registry, and version routing relationship is generated based on the candidate registration item and the current call status; Version routing module: Switches newly initiated calls to candidate tool instances according to version routing relationships, and keeps calls that have occupied the old contract version to the old tool instance; Old instance reclamation module: Generates old instance closure based on the occupancy and release status of old tool instances. When the old instance closure meets the reclamation conditions, the old tool registration item is deregistered and the old isolated loading context is unloaded, generating dynamic tool registration results.

[0032] It should be noted that the tool generation system based on cloud script dynamic registration provided in the above embodiments and the tool generation method based on cloud script dynamic registration provided in the above embodiments belong to the same concept. The specific methods of execution of each module and unit have been described in detail in the method embodiments and will not be repeated here. In practical applications, the tool generation system based on cloud script dynamic registration provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0033] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for generating tools based on cloud-based script dynamic registration, characterized in that, include: Retrieve script records from the cloud script repository, parse the tool declaration information and script status information in the script records to generate tool contract data; The tool contract data is compared with the locally effective tool contract data to generate the tool contract acceptance degree; The registration migration method is generated by matching registration migration rules based on tool contract acceptance and script status information; When registering the migration method corresponding to the tool generation path, the script records are dynamically compiled and isolated for loading to generate candidate tool instances. Based on the tool contract data, the candidate tool instances are verified by contract calls to generate candidate call consistency. When the consistency of candidate calls meets the release conditions, the candidate registration item corresponding to the candidate tool instance is written into the candidate registry, and a version routing relationship is generated based on the candidate registration item and the current call status. Based on the version routing relationship, newly initiated calls are switched to candidate tool instances, while calls that already occupy the old contract version are kept in the old tool instance; Based on the occupancy and release status of the old tool instance, generate the old instance closure degree. When the old instance closure degree meets the recycling conditions, deregister the old tool registration item and unload the old isolated loading context, generating the tool dynamic registration result.

2. The tool generation method based on cloud-based script dynamic registration according to claim 1, characterized in that, Retrieve script records from the cloud script repository, parse the tool declaration information and script status information in the script records to generate tool contract data, including: The script records are read from the script index in the cloud script repository, and the fields of the script records are merged to obtain the script body, tool declaration section, status flags and reference dependencies; The tool declaration section is declaring boundaries and split into entry declaration, call declaration, and context declaration. The entry point declaration is processed to extract callable entry points and generate tool entry point data; the call declaration is processed to merge field direction, field type, and field constraints to generate call contract data; the context declaration is processed to merge resource category and scope to generate context contract data; and the status flags are processed to standardize status to generate script status data. The tool entry data, call contract data, context contract data, and script state data are bound together according to the script records to generate tool contract data.

3. The tool generation method based on cloud-based script dynamic registration according to claim 2, characterized in that, The tool contract compliance score is generated by comparing the tool contract data with the locally effective tool contract data, including: Read the locally effective tool contract data corresponding to the script record from the local registration container, and align the tool contract data and the locally effective tool contract data to generate a correspondence between the old and new contracts; Based on the correspondence between the old and new contracts, the entry data of the tool is compared to identify the entry status of entry retention, entry mapping and entry missing, and the entry acceptance result is generated. Based on the correspondence between the old and new contracts, the fields of the call contract data are compared and identified to identify the retention status, compatible reception status and missing status of the old call fields in the new call contract, and call acceptance results are generated. Based on the correspondence between the old and new contracts, the authorization scope of the context contract data is compared, and the new context contract data is matched with the authorization resource scope of the current running environment to generate the context acceptance result. The entry acceptance results, call acceptance results, and context acceptance results are collected according to the corresponding script records to generate contract acceptance records. Based on the contract acceptance records, preset acceptance level rules are matched to generate the tool contract acceptance degree.

4. The tool generation method based on cloud-based script dynamic registration according to claim 3, characterized in that, The registration migration method is generated by matching registration migration rules based on tool contract acceptance and script status information, including: Extract the contract acceptance level based on the tool contract acceptance degree, extract the script effectiveness status based on the script status data, and combine the contract acceptance level and script effectiveness status to generate a registration migration judgment record; The registration migration judgment record is prioritized for status identification. When the script's effective status is disabled or deleted, the offline recycling rule is matched to generate an offline recycling method. When the script is in the enabled state, the migration category is determined for the contract acceptance level; when the contract acceptance level corresponds to the complete acceptance state, the hot replacement rule or the compatible update rule is matched to generate the hot replacement method or the compatible update method. When the contract acceptance level corresponds to an incomplete acceptance state and the context acceptance result in the contract acceptance record is within the authorized scope, the shadow registration method is generated by matching the shadow registration rules. When the context acceptance result in the contract acceptance record exceeds the authorized scope, the blocking registration rule is matched to generate a blocking registration method; The registration migration methods include offline recycling, hot replacement, compatibility update, shadow registration, or blocking registration.

5. The tool generation method based on cloud-based script dynamic registration according to claim 4, characterized in that, When registering the migration method and corresponding tool generation path, the script records are dynamically compiled and isolated for loading to generate candidate tool instances, including: When the registration migration method is hot replacement, compatibility update, or shadow registration, the corresponding script record will be marked as a script record to be generated; Extract the script body and reference dependencies from the script record to be generated, and encapsulate the script body, reference dependencies and tool contract data into a script compilation unit for compilation input. The script compilation unit dynamically compiles to generate candidate executable files and compilation diagnostic records; When the compilation diagnostic record meets the loading conditions, an isolated loading context corresponding to the candidate executable file is created, and the candidate executable file is loaded into the isolated loading context to generate a candidate executable object; Based on the tool entry data in the tool contract data, candidate execution objects are bound to the entry point to generate candidate tool instances.

6. The tool generation method based on cloud-based script dynamic registration according to claim 5, characterized in that, Based on tool contract data, contract call verification is performed on candidate tool instances to generate candidate call consistency, including: Generate contract sample call data based on the call contract and context contract in the tool contract data; Configure the controlled runtime context according to the context contract, and place the candidate tool instance into the controlled runtime context; Based on the contract example call data, candidate tool instances are called to generate candidate call records, and the actual call results and actual context access results are extracted from the candidate call records. The actual call result is compared with the call contract in the tool contract data to generate a call result consistency record. The actual context access results are compared with the context contract in the tool contract data to generate a context access consistency record. Candidate call consistency is generated by matching candidate call level rules with call result consistency records and context access consistency records.

7. The tool generation method based on cloud-based script dynamic registration according to claim 6, characterized in that, When the consistency of candidate calls meets the release conditions, the candidate registration entry corresponding to the candidate tool instance is written to the candidate registry. Version routing relationships are generated based on the candidate registration entry and the current call status, including: When the consistency of candidate calls meets the preset release conditions, read the candidate tool instance and the corresponding tool contract data, mark the release status of the candidate tool instance, and generate candidate registration items; Write the candidate registration entries into the candidate version area of ​​the candidate registry, and retain the old tool registration entries in the locally effective registry; Generate candidate contract versions based on candidate registration items, and establish registration mappings between candidate contract versions and candidate tool instances; Get the current call status, identify the contract version occupation of the current call status, and generate in-transit call records and newly initiated call records; Configure the routing relationships of candidate registration items, in-transit call records, and newly initiated call records to generate version routing relationships; When the consistency of candidate calls does not meet the preset release conditions, keep the old tool registration entries in the local effective registry in an effective state, and stop writing to the candidate registration entries corresponding to the candidate tool instances.

8. The tool generation method based on cloud-based script dynamic registration according to claim 1, characterized in that, Based on version routing, newly initiated calls will be switched to candidate tool instances, while calls already using the old contract version will be retained in the old tool instance. Obtain tool call requests, perform session identification on tool call requests, and generate call session records; The call session records are matched with the in-transit call records and newly initiated call records in the version routing relationship to generate call routing discrimination results; When a new call is initiated corresponding to the route determination result, a candidate tool instance is read from the candidate registry, and the route target of the tool call request is bound to the candidate tool instance to generate a candidate instance route record; When the call route determination result corresponds to a call that has occupied an old contract version, the old tool instance is read from the local effective registry, and the route target of the tool call request is kept as the old tool instance to generate an old instance route record; Update the version routing relationship based on the candidate instance routing record and the old instance routing record, and update the session occupancy status of the old tool instance based on the old instance routing record.

9. The tool generation method based on cloud-based script dynamic registration according to claim 1, characterized in that, Based on the occupancy and release status of the old tool instance, an old instance closure degree is generated. When the old instance closure degree meets the recycling conditions, the old tool registration item is deregistered and the old isolated loading context is unloaded. The generated tool dynamic registration results include: Read the session usage status of the old tool instance based on the old instance routing record, and read the resource reference status corresponding to the old tool instance based on the runtime context management record; The session occupancy status and resource reference status are merged to generate an old tool instance occupancy and release record. The occupancy and release record is then matched for closure status to generate the old instance closure degree. When the closure of the old instance does not meet the reclamation conditions, the old tool instance is kept in a waiting reclamation state, and the occupation release record is written to the lifecycle record of the old tool instance; When the closure of the old instance meets the recycling conditions, the old tool registration entry is deregistered from the local effective registry, and the binding relationship between the old tool instance and the runtime context is released; Read the old isolated loading context based on the isolated loading context identifier corresponding to the old tool registration item, perform unloading processing on the old isolated loading context to generate old instance reclamation records; The tool generates dynamic registration results based on candidate registration items, updated version routing relationships, and old instance recycling records.

10. A tool generation system based on cloud-based script dynamic registration, used to implement the tool generation method based on cloud-based script dynamic registration as described in any one of claims 1-9, characterized in that, include: Script contract generation module: Retrieves script records from the cloud script repository, parses the tool declaration information and script status information in the script records to generate tool contract data; Contract Acceptance Comparison Module: Compares the tool contract data with the locally effective tool contract data to generate the tool contract acceptance degree; Registration migration matching module: Generates registration migration methods by matching registration migration rules based on tool contract acceptance and script status information; Instance generation and verification module: When registering the migration method and corresponding tool generation path, dynamically compile and isolate the script records to generate candidate tool instances, and verify the contract calls of the candidate tool instances based on the tool contract data to generate candidate call consistency. Candidate registration module: When the consistency of candidate calls meets the release conditions, the candidate registration item corresponding to the candidate tool instance is written into the candidate registry, and version routing relationship is generated based on the candidate registration item and the current call status; Version routing module: Switches newly initiated calls to candidate tool instances according to version routing relationships, and keeps calls that have occupied the old contract version to the old tool instance; Old instance reclamation module: Generates old instance closure based on the occupancy and release status of old tool instances. When the old instance closure meets the reclamation conditions, the old tool registration item is deregistered and the old isolated loading context is unloaded, generating dynamic tool registration results.

Images