Tool planning method, system and electronic device

Abstract

This application relates to the fields of artificial intelligence and tool invocation planning technology, and discloses a tool planning method, system, and electronic device. The method includes: acquiring standard operating procedure (SOP) samples and performing supervised fine-tuning of a pre-trained language model based on the SOP samples to obtain a tool planning model; vectorizing multiple SOP entries to construct a SOP vector library; acquiring user intent information, recalling a set of candidate SOPs from the SOP vector library based on the user intent information, and determining the target SOP; constructing model input based on tool constraint information and user intent information in the target SOP; and inputting the model input into the tool planning model to generate a tool invocation sequence corresponding to the target SOP. This solution can improve the consistency between tool planning results and business procedures, and enhance the planning accuracy and timeliness in procedure update scenarios.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent tool invocation and control technology, specifically to a tool planning method, system, and electronic device. Background Technology

[0002] As intelligent agent systems based on pre-trained language models are increasingly applied to scenarios such as business processing, information retrieval, and task execution, generating corresponding tool call sequences based on user intent has become a crucial factor affecting system availability. In such systems, tool call sequences are typically used to organize the execution order of multiple external interfaces, service components, or functional modules to complete complex tasks that cannot be covered by a single query. Therefore, tool planning not only affects the understanding of natural language requests but also ensures that subsequent processing links can execute stably according to predetermined constraints.

[0003] In scenarios such as finance, where strict requirements exist for execution order and processing conditions, tool planning cannot be completed solely based on the user's surface expression. For the same type of business intent, it is often necessary to follow a predefined standard operating procedure. This standard operating procedure can be manifested as a set of tools corresponding to a specific business intent, the sequence of steps, and execution constraints. Only when the generated tool call sequence is consistent with this standard operating procedure can subsequent processing more easily meet the consistency requirements of business processing.

[0004] One existing approach involves providing the names, functional descriptions, and parameter information of multiple available tools to a general pre-trained language model, which then directly generates a tool invocation plan based on user input. This approach has a relatively straightforward structure and can handle a certain degree of tool selection and step arrangement in typical open scenarios. However, this method heavily relies on the general language reasoning capabilities developed during the pre-training phase. For business tasks requiring explicit processing flows, the model typically generates invocation plans probabilistically based on explicit semantics in the user request, rarely incorporating constraints from essential steps within specific business procedures. Therefore, when the actual processing flow corresponding to the user's intent includes pre-validation, mandatory queries, or a fixed sequence of steps, the generated tool invocation sequence often struggles to reliably cover all necessary steps, easily leading to omissions, sequence deviations, or incomplete tool selection.

[0005] Furthermore, in complex tasks, user expressions are often concise, while the corresponding processing requirements in standard operating procedures are quite complete. Existing direct generation methods typically lack an explicit process of locating the target business procedure before generation, preventing the model from obtaining the standard operating procedure constraint information that best matches the current intent at the starting point of inference. As a result, when generating tool call sequences, the model is actually inferring under uncertain rule boundaries. For tasks requiring multiple tools to work together, this uncertainty accumulates gradually during multi-step planning, making it difficult for the generated result to balance the flexibility of intent understanding with the stability of the execution process.

[0006] Another approach attempts to mitigate these problems through search-based planning or post-generation correction mechanisms. For example, after the initial tool sequence is generated, the results are validated, supplemented, or rearranged based on external rules; or a more complex path search process is introduced to progressively evaluate possible tool combinations. While this approach enhances rule participation to some extent, its rule constraints typically occur after the initial planning or rely on iterative comparisons of a large number of candidate paths. The former struggles to constrain the model's planning direction from the generation source, while the latter easily increases the computational burden and processing latency of the inference process. For application environments requiring rapid response and consistent planning results, the above methods still have room for improvement.

[0007] Based on this, existing technologies generally have the following problems in the tool planning process oriented towards standard operating procedure constraints: before the model generates the tool call sequence, there is a lack of a mechanism for accurately recalling and explicitly injecting standard operating procedures that match the current user intent, which makes it difficult for the model to complete the planning in a constrained context, and thus difficult to stably generate tool call sequences that meet the requirements of the established business steps. Summary of the Invention

[0008] The purpose of this invention is to provide a tool planning method, system, and electronic device to solve the technical problem in the prior art where there is a lack of standard operating procedure constraint information that matches the user's intent before the tool call sequence is generated, making it difficult for the tool call sequence to stably meet the requirements of the predetermined business steps.

[0009] To achieve the above objectives, embodiments of the present invention provide a tool planning method. The method includes: supervising the fine-tuning of a pre-trained language model based on standard operating procedure (SOP) samples to obtain a tool planning model, wherein the output content of the SOP samples is a tool call sequence conforming to the requirements of the corresponding business procedures; vectorizing multiple SOP entries to construct a SOP vector library, wherein each SOP entry contains a business intent description and tool constraint information corresponding to the business intent; receiving user intent information and converting it into a query vector; searching the SOP vector library based on the query vector to obtain a candidate SOP set, and reordering the candidate SOP set in conjunction with the user intent information to determine the target SOP; constructing a model input based on the tool constraint information and user intent information in the target SOP; and inputting the model input into the tool planning model to generate a tool call sequence corresponding to the target SOP.

[0010] In some embodiments, the tool constraint information in the standard operating procedure entry includes at least one of the following: the required toolset and the tool invocation order.

[0011] In some embodiments, a search is performed in the standard operating procedure vector library based on the query vector to obtain a candidate standard operating procedure set, including: recalling a preset number of candidate standard operating procedure entries based on the semantic similarity between the query vector and the vector representation of each standard operating procedure entry.

[0012] In some embodiments, reordering the candidate standard operating procedure set based on user intent information to determine the target standard operating procedure includes: inputting user intent information and each candidate standard operating procedure item into a reordering model to obtain a relevance score for each candidate standard operating procedure item; sorting the candidate standard operating procedure set according to the relevance score; and selecting the standard operating procedure item whose sorting result meets the conditions as the target standard operating procedure.

[0013] In some embodiments, constructing model input based on tool constraint information and user intent information in the target standard operating procedure includes: organizing the business intent description, tool constraint information, and user intent information in the target standard operating procedure according to a preset structure to generate context input for constraining the output content of the tool planning model.

[0014] This invention also provides a tool planning system. The system includes: a model training module for supervised fine-tuning of a pre-trained language model based on standard operating procedure (SOP) samples to obtain a tool planning model; a knowledge base construction module for vectorizing multiple SOP entries to construct a SOP vector library; an intent processing module for receiving user intent information and converting it into query vectors; a procedure recall module for searching the SOP vector library based on the query vectors to obtain a candidate SOP set, and reordering the candidate SOP set based on the user intent information to determine the target SOP; an input construction module for constructing model input based on tool constraint information and user intent information in the target SOP; and a planning generation module for inputting the model input into the tool planning model to generate a tool invocation sequence corresponding to the target SOP.

[0015] This invention also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program executable by the processor, and the processor executes the computer program to implement the above-described tool planning method.

[0016] Compared with existing technologies, the embodiments of the present invention have at least the following beneficial effects: By retrieving, reordering, and injecting standard operating procedures that match the user's intent before the tool planning model generates the tool call sequence, the model input contains explicit tool constraint information corresponding to the current task, thereby enabling the tool planning model to generate the tool call sequence within a constrained context. Since the target standard operating procedure has been determined and written into the model input before generation, the generated result is more likely to cover the necessary tool steps corresponding to the business intent and maintain the established step relationships, thereby improving the consistency between the tool planning result and the standard operating procedure.

[0017] Furthermore, by first using standard operating procedure (SOP) samples to supervise and fine-tune the pre-trained language model, and then introducing SOP vector retrieval and reordering during the inference phase, this embodiment of the invention enables the tool planning model to possess both basic business paradigm capabilities and scenario-based procedural constraints. This preserves the ability to understand the user's natural language intent while reducing step omissions and sequence biases caused by relying solely on probability generation.

[0018] Furthermore, by constructing standard operating procedure (SOP) entries into a searchable vectorized knowledge base and determining the target SOP through recall and reordering during the inference phase, this embodiment of the invention separates the business procedure management from the tool planning model generation capability. When business procedures change, the planning constraint range can be adjusted by updating the SOP entries and their vector indices, thereby improving the system's adaptability to procedure changes. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 Here is an overall flowchart of the tool planning method in one embodiment; Figure 2 This is a flowchart of standard operating procedure sample construction and model training in one embodiment; Figure 3 A flowchart for constructing a standard operating procedure vector library in one embodiment; Figure 4 This is a flowchart of the inference phase procedure recall and reordering in one embodiment. Figure 5 A flowchart for building model inputs in one embodiment; Figure 6 A flowchart of tool call sequence generation and verification in one embodiment; Figure 7 A system architecture diagram for the tool planning in one embodiment; Figure 8 This is a hardware structure diagram of an electronic device in one embodiment. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0022] In one embodiment, Figure 1 This demonstrates the overall process of a tool planning method. Figure 2 This demonstrates the standard operating procedure sample construction and model training process. Figure 3 This illustrates the process of building the standard operating procedure vector library. Figure 4 This illustrates the procedural recall and reordering process during the inference phase. Figure 5 This illustrates the model input construction process. Figure 6 This shows the tool call sequence generation process. Figure 7 This shows a block diagram of the tool planning system. Figure 8A schematic diagram of the hardware structure of the electronic device is shown below. Figures 1 to 8 The implementation process of this scheme will be explained in more detail.

[0023] Figure 1 In this process, the entire method can be executed by the tool planning service 100. The tool planning service 100 can be deployed on the server side or in a distributed environment consisting of application servers and model inference servers. If the deployment environment has high requirements for real-time response, vector retrieval, reordering, and model inference are usually distributed across different processing nodes. This facilitates control over resource consumption in each processing stage and reduces load fluctuations on a single node under high concurrency scenarios. The training and online inference stages are typically deployed separately. The training stage focuses on developing the domain planning capability of the tool planning model 101, while the online inference stage focuses on generating a tool invocation sequence adapted to user intent under the constraints of current standard operating procedures.

[0024] Combination Figure 1 Step S110 may include obtaining standard operating procedure (SOP) samples and performing supervised fine-tuning of the pre-trained language model based on the SOP samples to obtain the tool planning model 101. The SOP samples here are not ordinary question-and-answer pairs, but rather structured samples constructed around the tool planning task. Each sample includes at least user intent information and a tool invocation sequence corresponding to that user intent information. The user intent information can be a natural language request directly input by the user, or a request expression obtained by compressing the context of a multi-turn dialogue. The tool invocation sequence corresponds to the target execution path that meets the requirements of the business procedures. In other words, the output part of the sample already contains constraint information regarding tool selection, invocation order, and step completeness.

[0025] Figure 2 This illustrates the process of building a sample of standard operating procedures. Figure 2 The system may include a sample source acquisition unit 201, a procedure parsing unit 202, a log alignment unit 203, a sequence atomization unit 204, and a training sample generation unit 205. The sample source acquisition unit 201 receives raw data. Raw data can come from standard operating procedure documents, historical manual operation records, business audit logs, and tool call logs. The granularity of data from different sources is not the same. Standard operating procedure documents often describe rules and constraints, while historical logs tend to record execution actions and results. Without intermediate processing, directly combining these data can lead to the same business action appearing with different names in different data sources, or the same task being recorded as a set of steps with different levels of detail.

[0026] The procedure parsing unit 202 can structurally decompose the standard operating procedure (SOP) document, extracting the content directly related to tool planning to form SOP entries 206. SOP entries 206 can include a description of business intent, a set of required tools, the order of tool calls, and execution constraints. These execution constraints can be expressed as pre-verification requirements, step dependencies, tool call triggering conditions, parameter application boundaries, or whether a step can continue execution even without preceding results. In financial scenarios, execution constraints are often not just sequential restrictions but may also involve eligibility assessments, status confirmations, and information completeness checks. If these contents are only retained in lengthy rule descriptions and not incorporated into structured entries, the model will find it difficult to reliably capture their constraining effects during training and inference.

[0027] Log alignment unit 203 can map historical operation logs to the standard tool set defined by standard operating procedure item 206. In engineering implementation, a business task often corresponds to multiple historical execution trajectories, some of which contain remedial actions, manual rollback actions, or repeated calls after anomalies. Such trajectories are meaningful for fault analysis, but are not suitable as stable planning labels to directly participate in model training. Log alignment unit 203 can first identify the main execution path according to standard operating procedure item 206, and then remove temporary actions that deviate from the main path from the supervision labels. One advantage of doing this is that the tool planning model 101 learns the path expected by the business procedures, rather than historical operation habits containing random noise.

[0028] Sequence atomization unit 204 can break down the aligned execution path into atomic tool call sequences 207. The key to atomization is not to break down the steps into the finest possible values, but to ensure that each sequence element stably corresponds to a recognizable tool action. If a label element contains multiple actions, the model can easily mix up the sequential dependencies and call boundaries between different actions during generation. Taking a task like analyzing the reasons for fund losses as an example, if the label is directly written as "reason analysis," the model may find it difficult to understand that the action requires first confirming the holdings, then querying the fund's basic information, and then obtaining relevant news and external public information. If it is broken down into holdings query, fund basic information query, news retrieval, and public information search, the dependencies between tools become clearer, and subsequent sequence generation is easier to converge.

[0029] The training sample generation unit 205 can output supervised fine-tuning samples 208. The input content of the supervised fine-tuning samples 208 can be the user's natural language intent, or it can further include a condensed context summary; the output content can be an atomic tool call sequence corresponding to the user's natural language intent. If the system mainly handles single-turn tasks, the request semantics are usually concentrated in the current input text, in which case the input side can remain concise. If the system needs to support continuous dialogue, the necessary historical context can be retained in the input to reduce the difference in input distribution between the training phase and the online inference phase.

[0030] Tool planning model 101 can be obtained from a pre-trained language model through supervised fine-tuning. The specific model type is not limited here; it can be a decoding language model primarily focused on text generation, or a dialogue model suitable for command-following tasks. Model selection is usually related to the deployment environment. If the system prioritizes concurrency and response latency, a model with a relatively moderate parameter size is easier to deploy; if the system values ​​complex planning capabilities under long contexts, a model with a larger context window can be selected. Regardless of the model structure used, the goal of supervised fine-tuning is not to have the model memorize every procedural text in isolation, but rather to allow the model to develop planning preferences oriented towards business tasks. That is, after receiving a certain type of user intent, it tends to output a tool call sequence that is structurally complete, logically structured, and close to standard operating procedures.

[0031] In one embodiment, supervised fine-tuning can minimize the conditional generation loss between the model output sequence and the target tool invocation sequence. Let the training sample set be... ,in, Indicates the first User intent information, This represents the sequence of target tool calls corresponding to the user's intent information. Let the length of the target tool call sequence be represented, then the training objective can be expressed as: In the above formula, This represents the trainable parameters of the tool planning model 101. Indicates the first The tool tag sequence that was generated before each position This represents the conditional probability of the current tool label output by the model, given user intent information and the generated prefix. By optimizing equation (1), the tool planning model 101 can gradually learn the correspondence between user intent information and the target tool call sequence. Here, it's not just the label itself that matters, but also the implicit sequential structure within the label. If a certain step always occurs after another tool step, the model will gradually develop corresponding conditional generation preferences during repeated training.

[0032] Relying solely on supervised fine-tuning is often insufficient to cover the continuous changes in business procedures. In actual deployments, standard operating procedures (SOPs) change with business policies, interface capabilities, and compliance requirements, while model parameter updates are often conducted through batch training and periodic releases, meaning the update rhythm may not be synchronized with the business procedures. If all procedure information is crammed into the parameters of the tool planning model 101, the model's knowledge will lag when procedures change rapidly. As a result, while the model possesses general domain planning capabilities, it may still perpetuate old path preferences when faced with recently updated SOPs. To mitigate the impact of this lag, the tool planning service 100 can separate some procedure constraints from the model parameters and instead construct an updatable external knowledge structure.

[0033] Figure 1 Step S120 may include vectorizing multiple standard operating procedure entries 206 to construct a standard operating procedure vector library 102. Figure 3 The implementation process of this part is shown. Figure 3 The system may include an item organization unit 301, a text normalization unit 302, a vector encoding unit 303, an index construction unit 304, and a vector library storage unit 305. The item organization unit 301 can uniformly organize the fields of the standard operating procedure items 206. In addition to business intent descriptions and tool constraint information, item identifiers, applicable conditions, version markers, effective time, and expiration time can also be added. Adding these fields is not merely for formal enrichment, but rather for online procedure management considerations. If historical and current items coexist in the same business scenario, relying solely on semantic similarity retrieval may easily recall expired items, increasing the risk of subsequent planning deviations.

[0034] Text normalization unit 302 can organize standard operating procedure entries 206 into standardized text 3021 suitable for vector encoding. Standardized text 3021 can include a description of business intent, a set of necessary tools, the order of tool invocation, and execution constraints. If only the description of business intent is fed into the encoding model, while ignoring tool constraint information, the distinguishability of different procedure entries in the vector space is often insufficient. Especially in financial scenarios, the surface terms of multiple business intents may be very similar, but their execution paths are not the same. For example, viewing changes in returns and analyzing the reasons for losses may both involve keywords such as returns, funds, and holdings, but the latter usually involves a longer query chain. By encoding the tool constraint information together, the vector representation not only retains the semantics of the intent but also the information of the procedure path.

[0035] Vector encoding unit 303 can use an embedding model to semantically encode the standard text 3021, obtaining the standard operating procedure entry vector 3031. The embedding model here can be either a general text embedding model or an embedding model adapted to the domain corpus. If the business text contains many industry abbreviations, product abbreviations, and process terms, using a domain-adapted embedding model is usually more effective in maintaining the semantic differences between entries. This is because the same word may have different meanings in general contexts and specific business contexts, and a general model may not be able to reliably distinguish them. After the domain-adapted model maps these differences into the vector space, subsequent retrieval makes it easier to find the truly corresponding standard operating procedure entries.

[0036] In one embodiment, the initial similarity between the query vector generated from user intent information and the standard operating procedure entry vector 3031 can be calculated using cosine similarity. Let the query vector be... , No. The standard operating procedure entry vector is The corresponding similarity score It can be represented as: In the above formula, This represents the inner product between the query vector and the entry vector. Denotes the norm of the query vector. Indicates the first The norm of the vector of standard operating procedure entries. Similarity score. The higher the similarity score, the closer the current user intent information is to the standard operating procedure entry in the semantic space. This method of calculating initial similarity has a low computational cost and is suitable for quickly recalling candidates when the vector database is large.

[0037] The index building unit 304 can create a vector index 3041 based on the standard operating procedure entry vector 3031. The vector index 3041 can employ an approximate nearest neighbor index structure or a precise retrieval structure suitable for small to medium-sized data. If the number of standard operating procedure entries is small, directly scanning and calculating similarity can meet latency requirements; if the number of entries is large and the response time of online requests is limited, using a hierarchical graph index, clustered inverted index, or quantized index is more conducive to controlling retrieval time. When saving the vector index 3041, the vector library storage unit 305 can simultaneously save the entry text, tool constraint information, and version attributes corresponding to each entry vector. This allows for direct retrieval of the complete entry content after subsequent recall of candidate entry identifiers, eliminating the need for additional data association queries.

[0038] The standard operating procedure vector library 102 and the tool planning model 101 have different responsibilities. The tool planning model 101 is responsible for generating a sequence of tool calls given a context, while the standard operating procedure vector library 102 is responsible for sending procedural constraints that match the current user intent into the context before inference begins. Without the tool planning model 101, although the system can match procedural entries, it cannot naturally convert these entries into a sequence of task-oriented execution outputs. Without the standard operating procedure vector library 102, the system still needs to rely on the model's own memorization of procedures, which leads to decreased stability when encountering procedure updates, boundary intents, or ambiguous expressions. Combining the two allows the model's language understanding ability and the timeliness of external procedures to function simultaneously.

[0039] Figure 1 After steps S110 and S120 are completed, the tool planning service 100 has two basic conditions. First, the tool planning model 101 has acquired basic planning capabilities within the domain through supervised fine-tuning. Second, the standard operating procedure (SOP) vector library 102 stores the currently active SOP entries and their vector representations. Upon receiving an online request, the system no longer allows the tool planning model 101 to generate independently without procedural boundaries. Instead, it first retrieves candidate procedures from the SOP vector library 102 that match the current user's intent. After this processing, the subsequent generation stage does not face an unbounded set of tools, but rather a candidate space shrunk by the constraints of standard operating procedures. Under these input conditions, the tool planning model 101 can more easily generate a complete and logically ordered sequence of tool calls.

[0040] Combination Figure 1 , Figure 4 and Figure 5 The online inference phase can begin from step S130. At this point, the standard operating procedure vector library 102 has been completed, and the tool planning model 101 has the basic planning capabilities for the target business. After a user initiates a request, the system does not immediately generate a tool call sequence, but first processes the user's intent information. This is because user input and standard operating procedure entries are usually expressed differently. Users tend to use colloquial, simplified, or purpose-oriented expressions, while standard operating procedure entries are more structured rule descriptions. If there is no intermediate alignment between the two, relying solely on direct text matching can easily misjudge a request that points to a complex toolchain as a simple query task.

[0041] Figure 4In this context, the intent processing and procedure retrieval process may include an intent receiving unit 401, a text shaping unit 402, a query vector generation unit 403, a candidate retrieval unit 404, a fine-ranking evaluation unit 405, and a target procedure determination unit 406. The intent receiving unit 401 receives user intent information 4011. User intent information 4011 can be either a current round of natural language request or an intent expression formed by compressing the effective context from multiple rounds of dialogue. For single-round interaction tasks, the current round text is usually sufficient; for multi-round tasks, if only the current round text is retained, it is easy to lose the objects, time ranges, and business constraints determined in the preceding text. For example, a user might first say, "Let me see the medical fund I bought last month," and then in the next round, "Please help me see why it lost money." The latter round text itself does not contain the fund object. Without combining it with the preceding text, the standard operating procedure entries retrieved later may be biased towards general fund analysis rather than an analysis of the reasons for losses specific to a particular holding.

[0042] The text shaping unit 402 can perform lightweight shaping on the user intent information 4011. This shaping typically includes removing obviously irrelevant polite expressions, verbal redundancy, repetitive fragments, and formatting noise, while retaining as much limiting information as possible that is valuable for business judgment. If the input comes from speech recognition results, the text shaping unit 402 can also correct common homophone errors, phrasing errors, and terminology recognition biases. This correction process does not require the formation of a rigorous natural language understanding result, but rather aims to generate a more stable query vector subsequently. In engineering practice, vector retrieval is quite sensitive to the main semantics of the text, but it is also easily interfered with by irrelevant fragments, especially when the user input is short, a few irrelevant words can amplify semantic shifts.

[0043] The query vector generation unit 403 can input the shaped user intent information 4021 into the embedding model to obtain the query vector 4031. The embedding model used to generate the query vector 4031 can be consistent with the embedding model used when constructing the standard operating procedure vector library 102, or it can adopt a parameter-sharing or semantic space-aligned model. The reason for maintaining a consistent encoding space is quite straightforward. If the query vector 4031 and the standard operating procedure entry vector 3031 come from significantly different vector spaces, even if the text semantics are similar, the cosine similarity comparison results may be unstable. Especially when there are a large number of procedure entries, inconsistent encoding spaces can cause fluctuations in the candidate recall ranking.

[0044] After receiving the query vector 4031, the candidate recall unit 404 can perform a first-round search in the standard operating procedure vector library 102 to obtain a candidate standard operating procedure set 4041. This set typically consists of the top few items with the highest semantic similarity. The number of candidates should not be too small or too large. If it is too small, there is a risk of missing the real target items; if it is too large, the number of items that the subsequent re-ranking model needs to process will increase, which will increase the online inference latency. In most scenarios, an empirical value can be set first based on the scale of business items and the latency budget, and then adjusted according to the actual recall effect.

[0045] In one embodiment, the candidate recall unit 404 can recall a preset number of candidate standard operating procedure (SOP) entries based on the semantic similarity between the query vector 4031 and each SOP entry vector 3031. Assume that the SOP vector library 102 contains a total of... There are [number] entries, and the query vector is [value]. , No. The vector of each entry is Then, candidate recall unit 404 can calculate the initial score as follows: In the formula, Represents the query vector With the Vector of standard operating procedure entries Cosine similarity between them Represents the dot product of vectors. Represents the query vector norm, Represents the standard operating procedure entry vector The norm. According to each After sorting by size, the scores of the top-ranked candidates can be selected. The standard operating procedure entries for each bit are used as the candidate standard operating procedure set 4041, where... This indicates the preset recall quantity. This initial recall process mainly serves a filtering function, that is, to exclude obviously irrelevant items from the large-scale vector library first, rather than excessively pursuing absolute accuracy in the final ranking at this stage.

[0046] There are two practical reasons for retaining candidate set 4041 instead of directly selecting a single item. One reason is the ambiguity in user expressions. The same sentence, "Help me figure out why this fund has recently fallen so much," could correspond to either a market analysis procedure or a loss analysis procedure. The other reason is that vector retrieval itself is biased towards semantic proximity and may not fully utilize the structural constraints in standard operating procedure items. If a single item is immediately locked after the first round of retrieval, the probability of misselection increases if there are overlapping boundaries between semantically similar items. Therefore, the system first retains candidate set 4041, and then the fine-tuning evaluation unit 405 combines the original user intent information 4011 with the content of the candidate items for a second round of judgment.

[0047] The fine-grained ranking evaluation unit 405 can receive user intent information 4011 and a set of candidate standard operating procedures 4041, and call the re-ranking model 4051 to evaluate the relevance of each candidate item. The re-ranking model 4051 is used here instead of continuing with pure vector similarity because the second round of evaluation requires a more detailed comparison of the local correspondence between user intent and candidate items. Vector retrieval is better suited for large-scale recall, but it is often less stable than cross-coding evaluation when dealing with fine-grained differences such as negation, conditions, object limitations, and order restrictions. The re-ranking model 4051 can adopt a cross-coding structure or a discriminative model that can jointly encode the query text and candidate item texts. The model input typically includes user intent information 4011 and the canonical text of a single candidate item. The model output can be a relevance score.

[0048] In one embodiment, the reordering model 4051 can reorder the first... Output a refined score for each candidate standard operating procedure item. The final score is... It can be obtained from user intent information 4011 and the first The candidate entries are jointly encoded to obtain the final ranking score. If it is necessary to consider both the initial recall and the ranking results, a weighted fusion of the two can be performed to obtain the final ranking score. : In the formula, Indicates the first The final ranking score of each candidate standard operating procedure item. This indicates the initial recall similarity score for the entry. This represents the fine-grained ranking score output by the re-ranking model 4051. and This represents the corresponding weight coefficient, and , If the system places greater emphasis on the discriminative power of the fine-grained ranking model, it can increase... The value of ; if the system wants to retain the impact of the vector recall stage on the overall semantic proximity, it can be set to . Retain a certain weight. The settings for both can be obtained through offline validation set tuning, or they can be configured separately for different business domains.

[0049] Target procedure determination unit 406 can determine the final ranking score. Determine the target standard operating procedure 4061. If the score difference between the first and second ranked items in the ranking results is significant, the item with the highest score can be directly selected as the target standard operating procedure 4061. If the scores of the top items are close, the system can also introduce additional rules for further filtering. For example, filtering can be done by combining the version validity of the item, the adaptability to the user's current state, or the source of the business line. Here, we do not directly rely on the principle of maximizing the score, but add additional rules for filtering because in some scenarios, similar items only differ in their applicable conditions. For example, queries and pre-purchase checks for similar products may use similar sets of tools, but some items are only effective for users who meet the eligibility criteria. If filtering is not combined with applicable conditions, the constraint items obtained by the tool planning model 101 may be semantically similar, but not suitable for the current user.

[0050] Once the target standard operating procedure 4061 is determined, the system obtains an external procedural constraint that matches the current user intent information 4011. This constraint is not merely a label, but a set of structured information containing a description of the business intent, the necessary toolset, the order of tool invocation, and execution constraints. Retaining this information in subsequent input construction stages helps transform the standard operating procedure from a retrieval result into actual generated constraints. If only the entry identifier is retained at this location without the specific content of the entry, the tool planning model 101 still cannot obtain a usable inference boundary.

[0051] Figure 5 The corresponding step S140 is to construct the model input based on the tool constraint information and user intent information 4011 in the target standard operating procedure 4061. Figure 5 The system may include a procedure extraction unit 501, a template organization unit 502, a context assembly unit 503, and a model input generation unit 504. The procedure extraction unit 501 extracts the business intent description, essential toolset, tool call order, and execution constraints from the target standard operating procedure 4061. The extracted results can be organized into a structured procedure fragment 5011. A structured procedure fragment 5011 is used instead of directly concatenating the entire original text because the original text may contain a lot of background text, example text, or redundant explanatory content. After transcribing the procedure content into a structured fragment, the constraints received by the tool planning model 101 are more focused, and it is easier to identify which tools are mandatory, which steps have sequential relationships, and which conditions affect the generation boundary.

[0052] The template organization unit 502 can organize the structured procedure fragment 5011 and user intent information 4011 according to a preset structure to obtain the intermediate input template 5021. The preset structure does not need to be a fixed and unique template, but it usually includes a task description area, a procedure constraint area, and a user request area. The task description area is used to clarify that the current model needs to output a tool call sequence; the procedure constraint area is used to give the necessary tool set, sequence requirements, and execution conditions; the user request area retains the user's original expression. This organization method allows the tool planning model 101 to see both business rules and user semantics at the same time. If the rules and user requests are mixed in an unordered manner, the model is more susceptible to interference when extracting key information in a long context, especially when the user request itself is long and the entry text is also long, this effect will be more obvious.

[0053] In one embodiment, the template organization unit 502 can organize the business intent description, tool constraint information, and user intent information 4011 in the target standard operating procedure 4061 according to a preset structure to generate context input 5021 for constraining the output of the tool planning model 101. The constraint here does not mean hardcoding the tool call result, but rather giving the model a clear generation boundary. The model still undertakes the task of mapping fuzzy user expressions to specific tool sequences, but this mapping no longer occurs in a non-procedural context, but within the tool set and sequence boundaries explicitly defined by the target standard operating procedure 4061. In other words, the target standard operating procedure 4061 is equivalent to providing a standard operating manual before generation, and the tool planning model 101 completes the specific planning of the current task based on this manual.

[0054] The context assembly unit 503 can add necessary system-side context beyond the intermediate input template 5021, such as the current session identifier, user state summary, known object identifier, or summary of the previous round's tool execution result. Whether to add this additional information depends on the business scenario. If the target standard operating procedure 4061 is already sufficiently defined and the task is a single-round request, the additional information can be omitted to control the input length. If the task depends on objects or states confirmed in previous rounds, retaining this context helps the tool planning model 101 accurately reference existing information during generation, rather than repeating previous planning actions. The model input generation unit 504 finally outputs the complete model input 5041 and sends it to the tool planning model 101.

[0055] At this point, the system has completed the entire pre-processing from user natural language requests to target procedure localization, and then to the construction of model inputs constrained by the procedure. Compared to directly feeding user requests into the model, this processing link adds two more stages: recall and fine-tuning, and also adds intermediate steps to input organization, but the trade-off is a clearer generation boundary. For scenarios that require strict adherence to standard operating procedures, this pre-constraint approach is more likely to reduce path drift in the generation stage. Especially when user expressions are short, vague, or span multiple tool domains, the prior constraints obtained by the tool planning model 101 from external procedures will significantly affect the stability of subsequent sequence generation.

[0056] Combination Figure 1 , Figure 5 and Figure 6 Step S150 may include inputting model input 5041 into tool planning model 101 to generate tool call sequence 601 corresponding to target standard operating procedure 4061. Figure 6 The system may include a sequence generation unit 601, a sequence constraint verification unit 602, a result processing unit 603, and an output provision unit 604. After the model input 5041 enters the tool planning model 101, the tool planning model 101 does not simply repeat the tool names in the target standard operating procedure 4061, but rather combines the task object, time range, and analysis objective in the user intent information 4011 to output a specific tool call sequence 601 for the current task. This specificity is mainly reflected in the sequence having execution order, tool granularity, and task relevance, rather than remaining at the level of a general description.

[0057] The tool call sequence 601 can include call identifiers for multiple tools and the execution order between them. The call identifier can be a tool name, interface identifier, service identifier, or tool number from a unified registry. If a tool registry has already been established within the system, outputting a unified registry identifier through the tool planning model 101 facilitates subsequent system parsing. If a unified numbering system has not yet been established, standardized tool names can be output, which are then mapped to the corresponding actual interfaces in the execution layer by the result processing unit 603. Regardless of the representation method used, the key is that the names of the same tool should be as consistent as possible in training samples, procedure entries, and the online execution phase; otherwise, even if the model-generated results are semantically correct, the execution layer may still be unable to directly call them due to inconsistent naming.

[0058] The sequence generation in step S150 does not require the tool planning model 101 to know the final values ​​of all tool parameters at once. The model's primary task is planning, i.e., determining which tools are needed, the order of their execution, and whether there are any pre-validation or intermediate query actions. Parameter filling can be further completed in subsequent execution layers based on contextual results. For example, if a user request mentions a fund but does not provide a unique code, the tool planning model 101 can first output the holdings query tool, then the fund basic information query tool, instead of forcibly constructing an incomplete target parameter during the planning phase. This division of labor better aligns with the actual system's responsibility allocation and reduces the probability of the model generating incorrect calls when parameter details are incomplete.

[0059] Figure 6 The sequence generation unit 601 can progressively output tool call sequences in an autoregressive manner. At each generation step, the currently generated prefix influences the probability distribution of the next tool tag. Since the model input 5041 already incorporates the tool constraint information of the target standard operating procedure 4061, the tool planning model 101 will tend to continue along the path allowed by the procedure constraints during generation. For example, if the target standard operating procedure 4061 explicitly states that holding confirmation should be performed first, followed by fund information query, then after the holding query identifier has been generated, the model's conditional probability for the fund information query tool will usually be higher than that of other tools that, while related to the fund topic, do not conform to the current procedure order.

[0060] In one embodiment, tool planning model 101 pairs lengths of The generation probability of the tool call sequence 601 can be expressed as the product of the conditional probabilities at each position: In the formula, This indicates that the tool call sequence is 601. This indicates user intent information 4011. This represents the context input 5021 constructed from the target standard operating procedure 4061. Indicates the first The tool tag sequence generated before each position This represents the model parameters of the tool planning model 101. Equation (5) shows that the result generated in the current step is not only determined by the user intent information 4011, but also by the procedural context. and preceding tool paths The combined influence of these factors means that external standard operating procedure constraints can genuinely affect the output path during the inference phase, rather than merely existing as supplementary explanatory text.

[0061] After the tool call sequence 601 is initially generated, the sequence constraint verification unit 602 can perform a rule consistency check on it. Verification unit 602 is included here because even if the model has received procedural constraints, there may still be omissions of essential steps, repeated steps, or order reversals in a few boundary cases. Especially when the user request expression contains multiple sub-objectives, or when the target standard operating procedure 4061 itself allows for a limited number of path variations, the model generation result may exhibit local instability. Sequence constraint verification unit 602 can verify the tool call sequence 601 based on the set of essential tools and the tool call order in the target standard operating procedure 4061. If a necessary tool is found to be missing, or a subsequent step appears before a preceding step, verification unit 602 can trigger a correction process.

[0062] There are several ways to perform correction processing. In one implementation, the sequence constraint verification unit 602 organizes the defects found during verification into feedback prompts, concatenates them with the original model input 5041, and sends them back to the tool planning model 101 for a constrained regeneration. The advantage of this method is that the corrected output is still generated by the same model in a complete context, resulting in a high degree of naturalness in the overall sequence. Another implementation is that the result processing unit 603 directly fills in missing steps or adjusts local sequences according to the target standard operating procedure 4061. This method is faster, but if too many adjustments are made, the final sequence may lose the local specificity originally obtained by refining the model according to the user's intent. In latency-sensitive scenarios, rule correction can be prioritized; in accuracy-priority scenarios, feedback regeneration can be prioritized. Both implementation methods can work; the main difference lies in whether the system prioritizes real-time performance or the consistency of the generation path.

[0063] The result processing unit 603 can convert the validated tool call sequence 601 into a unified output format 6031. The unified output format 6031 can include a sequence number field, a tool call identifier field, an execution order field, and an optional description field. The execution order field is included because some downstream execution engines support a mixture of parallel and serial calls. If only a linear list of tools is output without explicitly indicating which tools have sequential dependencies, the execution engine needs to make further inferences, which can easily introduce bias. By clearly defining the execution order of each tool in the unified output format 6031, and even marking the prerequisite dependencies of certain steps, downstream scheduling is more likely to align with the planning results.

[0064] In one embodiment, the tool call sequence 601 output by the result processing unit 603 may include not only the call identifiers of multiple tools, but also the execution order relationship between the tools. If there is no data dependency or sequence dependency between two tools, the system can also mark them as steps at the same level in the execution order field so that they can be concurrently scheduled during downstream execution. The significance of this approach is that tool planning itself is not just about selecting tools, but also about organizing the execution path. For complex tasks, reducing unnecessary serial waiting will also affect the overall response time. In other words, the tool planning result should not only be correct, but also be as suitable as possible for the execution layer to digest.

[0065] Output providing unit 604 can send the unified output format 6031 to the downstream tool execution service, or it can directly return it to the upper-layer business application as an intermediate planning result. If the system adopts a planning and execution separation architecture, output providing unit 604 returns a tool sequence description, and the downstream execution service then calls the actual tools item by item; if the system adopts an integrated planning and execution architecture, the tool planning service 100 can also continue to drive tool execution according to the unified output format 6031. The difference between these two architectures mainly lies in the division of system boundaries, without changing the aforementioned planning logic. More importantly, the tool call sequence 601 is already constrained by standard operating procedures when it is generated, so no matter which execution entity takes over later, it can proceed relatively stably along the path allowed by the business procedures.

[0066] In actual deployment, another situation may arise where the user intent information 4011 is highly similar to the target standard operating procedure 4061, but additional sub-requests are mixed into the user input. For example, a user might inquire about the reasons for losses while simultaneously requesting a comparison of the performance of similar funds. If only loss reason analysis procedures are recalled in the current round, the tool planning model 101 might prioritize outputting the main sequence around this procedure, without expanding on comparison-related actions. Faced with this situation, the system can adopt two processing methods. First, it can split the composite intent in the text shaping unit 402 stage and then execute procedure recall and tool planning separately. Second, it can allow the reordering stage to retain multiple highly relevant entries and provide constraints in the model input 5041 as multiple candidate procedures. The former method has clearer boundaries, while the latter has a more complex context organization but can preserve the integrity of the user's composite task. Which method to use depends on whether the business task allows for multi-objective concurrent planning.

[0067] There is another boundary case: the standard operating procedure vector library 102 may not find enough matching entries, or the scores of the top few entries may be too low. In this case, if the highest-scoring entry is forcibly selected, the tool planning model 101 may generate a seemingly reasonable but actually unsuitable tool call sequence under incorrect procedure boundaries. To address this, a minimum confidence threshold can be set for the target procedure determination unit 406. When the highest ranking score does not reach the threshold, the system can enter a degraded mode. The degraded mode can either return a manual confirmation request or adopt a more lenient general planning template. The general planning template does not require complete coverage of the standard operating procedure details, but it can first provide relatively safe general tool paths such as object recognition, basic queries, and information completion. While this reduces the degree of automation, it avoids outputting overly aggressive planning results when the procedure is unclear.

[0068] As can be seen from the embodiment consisting of steps S110 to S150, the system does not directly determine which tools to call using only a language model. Instead, it first trains a tool planning model 101 with domain planning capabilities using standard operating procedure samples, then constructs a standard operating procedure vector library 102 from the standard operating procedure entries 206, and retrieves the target standard operating procedure 4061 based on the user intent information 4011 during online inference. Subsequently, it constructs the model input 5041 based on the tool constraint information and user intent information 4011 in the target standard operating procedure 4061, and finally, the tool planning model 101 generates a tool call sequence 601 corresponding to the target standard operating procedure 4061. This processing chain ensures that model generation is based on current procedure constraints, rather than relying solely on historical memory in the model parameters. For business tasks with frequent procedure updates and strict step constraints, this structure is more likely to reduce tool selection bias caused by procedure lag and also helps to reduce the possibility of the model omitting pre-verification steps or skipping essential tools.

[0069] From an implementation mechanism perspective, the supervised fine-tuning stage enables the tool planning model 101 to acquire the basic mapping capability from user intent to tool path, while the standard operating procedure vector library 102 plays the role of quickly injecting the latest business procedures into the online inference process. With the two parts combined, the model no longer needs to remember all business details separately, but can instead reference the currently recalled procedure entries during generation. This preserves the flexibility of the language model in processing natural language intents while shrinking the optional tool space through external knowledge constraints. For scenarios where different business procedures exist for the same intent at different times, only the standard operating procedure entry 206 and its vector index 3041 need to be updated, without frequent overall retraining of the tool planning model 101, allowing the online planning results to adjust according to the procedure changes.

[0070] In some implementations, the execution constraints in standard operating procedure entry 206 can be further refined into prohibitive and mandatory relationships. Prohibitive relationships indicate that certain tools cannot be called before a specific tool, or that certain tools are unavailable in the current business state; mandatory relationships indicate that a certain tool step must occur for a task to be successful. After explicitly writing these two types of relationships into the structured procedure fragment 5011, the sequence constraint verification unit 602 can not only check the order of execution but also check for prohibition conflicts and path gaps. In this way, the output tool call sequence 601 can undergo a structural consistency screening before entering the execution layer, reducing the probability of errors being exposed during subsequent execution.

[0071] In some implementations, the tool planning service 100 does not only handle single-round, single-objective task requests. In actual business scenarios, multi-round dialogues and complex intents are more common. Users may only identify the object in the first round and then propose the analysis objective in subsequent rounds; they may also express query, comparison, and interpretation needs simultaneously in a single request. If each round of input is still treated as an independent task, the accuracy of the procedure recall will decrease, and the tool call sequence 601 may easily cover only partial subtasks. To address this issue, Figure 4 The intent receiving unit 401 can read the session context cache simultaneously when receiving user intent information 4011. This cache can store the text of the most recent rounds of dialogue, the identifiers of confirmed objects, the summary of the previous round of tool execution, and the slots for tasks that have not yet been completed.

[0072] For multi-turn dialogue scenarios, text shaping unit 402 can first perform context compression. The focus of compression is not on retaining all original utterances, but on retaining key information that affects tool planning. For example, user objects, time ranges, product names, comparison dimensions, and action purposes should be retained first, while small talk, confirmatory echoes, and irrelevant follow-up questions can be compressed or deleted. The resulting context summary can reduce input length on the one hand, and avoid the tool planning model 101 mistakenly treating non-task information as planning conditions in lengthy dialogues on the other. If there are obvious omissions in the current user's expression, such as checking the reasons or comparing similar products, the context compression result can fill in these omissions, making the query vector 4031 consistent with the actual business intent.

[0073] For complex intent scenarios, the tool planning service 100 can use intent segmentation. Intent segmentation is not simply dividing by commas or conjunctions, but rather identifying multiple relatively independent task sub-items based on action type, target, and procedural differences. For example, "Help me see why this fund has recently fallen, and compare its performance with similar products" can be identified as a loss reason analysis sub-task and a similar comparison sub-task. If the standard operating procedures corresponding to the two sub-tasks differ significantly, the candidate recall unit 404 can perform retrieval separately, forming two candidate standard operating procedure sets 4041. The subsequent fine-tuning and evaluation unit 405 determines the corresponding target standard operating procedures 4061, and then the template organization unit 502 organizes multiple procedural constraints into the same model input 5041, or generates multiple tool call sequences 601. The former approach is more suitable for scenarios where the model has strong long-context planning capabilities, while the latter approach is more conducive to controlling the clarity of each planning link.

[0074] In one embodiment, when the composite intent is split into When dealing with multiple subtasks, the system can calculate the correlation between each subtask and each standard operating procedure item, and then combine the target procedures of each subtask. Let the first subtask be... The standard operating procedure for the final objective of each sub-task is expressed as follows: Then it can be expressed as: In the formula, Indicates the first The intent expression corresponding to each sub-task This represents the set of candidate standard operating procedures corresponding to this subtask. Indicates candidate standard operating procedures With sub-task intent The final ranking score between them. The most matching target procedure can be selected for each subtask by formula (6). If there are shared prerequisite steps between multiple subtasks, such as needing to confirm the current holding object first, the template organization unit 502 can merge the shared steps when assembling the model input 5041, so as to avoid the tool planning model 101 from repeatedly arranging the same query action in the final output.

[0075] Procedure version switching is also a stage where problems are easily exposed in actual deployment. The standard operating procedure vector library 102 may simultaneously retain entries for multiple versions to support historical tracking, canary releases, or parallel operation across different business lines. Without version status restrictions, the entry semantically closest to the user's intent may not be the one that should currently be in effect. Figure 3The entry organization unit 301 and vector library storage unit 305 can store version tags, business domain tags, effective start and end times, and status fields for each standard operating procedure entry 206. After the candidate recall unit 404 returns the candidate set 4041, before or after the fine-tuning evaluation unit 405, version filtering logic can be added to exclude entries that are invalid or not applicable to the current business domain before proceeding to the target procedure determination unit 406.

[0076] In some scenarios, older and newer versions of the procedure are semantically very similar, but there are subtle differences in the order in which tools are invoked. If relying solely on vector retrieval, both types of entries often appear at the top simultaneously. In this case, version validity can be introduced as part of the ranking score. Let the... The version validity score of each candidate entry is The final ranking score can also be expressed as: In the formula, This represents the final ranking score after incorporating version validity factors. This represents the initial recall similarity score. This represents the fine-grained ranking score output by the re-ranking model 4051. This represents the version validity score corresponding to the current time, business domain, and status field. , and These represent weighting coefficients, and all three are not less than zero. If an entry is currently active, A higher value can be taken; if an item has expired or does not belong to the current business domain, You can take a lower value or set it to zero. After this processing, entries that are semantically similar but do not match in version will be shifted to the end in the final sort.

[0077] Figure 7A tool planning system 700 is illustrated. The tool planning system 700 may include a model training module 701, a knowledge base construction module 702, an intent processing module 703, a procedure recall module 704, an input construction module 705, and a plan generation module 706. The model training module 701 is used to supervise and fine-tune a pre-trained language model based on standard operating procedure (SOP) samples to obtain a tool planning model 101. The knowledge base construction module 702 is used to vectorize multiple SOP entries 206 to construct a SOP vector library 102. The intent processing module 703 is used to receive user intent information 4011 and convert it into a query vector 4031. The procedure recall module 704 is used to search the SOP vector library 102 based on the query vector 4031 to obtain a candidate SOP set 4041, and then reorders the candidate SOP set 4041 in conjunction with the user intent information 4011 to determine the target SOP 4061. The input construction module 705 is used to construct the model input 5041 based on the tool constraint information and user intent information 4011 in the target standard operating procedure 4061. The planning generation module 706 is used to input the model input 5041 into the tool planning model 101 to generate the tool call sequence 601 corresponding to the target standard operating procedure 4061.

[0078] Figure 7 The modules within the system can be logical modules or further mapped to service units in a physical deployment. For example, the model training module 701 and the knowledge base construction module 702 are typically better suited for deployment in an offline processing environment because these two parts consume significant processing resources and do not require real-time completion per request; the intent processing module 703, procedure recall module 704, input construction module 705, and plan generation module 706 are usually deployed in an online service environment to respond to external requests. If the system adopts a microservice architecture, the modules can interact with each other through remote procedure calls, message queues, or shared storage. If the system deployment is small, several modules can be merged into the same service process. The physical splitting of modules does not change their logical functionality, but only affects the system's engineering implementation path.

[0079] Figure 8An electronic device 800 is shown. The electronic device 800 may include a processor 801, a memory 802, a communication interface 803, and a bus 804. The processor 801, memory 802, and communication interface 803 can be connected via the bus 804. The memory 802 may store a computer program 805. When the computer program 805 is executed by the processor 801, it enables the electronic device 800 to perform the aforementioned tool planning method. The processor 801 may be a general-purpose central processing unit, a graphics processing unit, a neural network accelerator, or other computing units suitable for model inference tasks. The memory 802 may include volatile and non-volatile memory for storing the tool planning model 101, the standard operating procedure vector library 102, the reordering model 4051, and intermediate data generated during operation. The communication interface 803 is used to receive user requests, access external tool services, and return planning results.

[0080] In one embodiment, when the processor 801 in the electronic device 800 executes the computer program 805, it can first call the embedded model to convert the user intent information 4011 into a query vector 4031, then access the standard operating procedure vector library 102 to obtain a set of candidate standard operating procedures 4041, and call the reordering model 4051 to determine the target standard operating procedure 4061. Subsequently, the processor 801 constructs a model input 5041 based on the tool constraint information in the target standard operating procedure 4061, and calls the tool planning model 101 to generate a tool call sequence 601. If the electronic device 800 itself also undertakes execution scheduling functions, the processor 801 can also control the calling order of external tool services based on the tool call sequence 601. If the electronic device 800 only undertakes planning functions, the tool call sequence 601 can be sent to an independent execution service.

[0081] From an engineering perspective, another issue to consider is that the standard operating procedure vector library 102 and the tool planning model 101 may not be updated simultaneously in an online environment. For example, if a procedure update only involves adding new tool sequence constraints without changing the overall task semantics, then updating the standard operating procedure vector library 102 is sufficient. Another scenario is that a completely new type of task is added to the business domain; in this case, simply updating the vector library is insufficient, and the supervised fine-tuning samples 208 of the tool planning model 101 also need to be expanded. To ensure compatibility between the two update rhythms, external procedure constraints can always be retained in the model input 5041, allowing the model to generate constrained procedures during the inference phase, even if it hasn't fully learned the new procedures. This reduces the risk of asynchronous model and procedure updates.

[0082] In another implementation, the tool planning service 100 can be deployed in a collaborative mode between edge computing nodes and a central node. Edge nodes with limited resources can perform text shaping, query vector generation, and candidate retrieval, while the central node performs reordering and tool planning model inference. This division of labor is because the vector retrieval process typically requires relatively light computation, while the reordering model 4051 and the tool planning model 101 require significantly more computing power for inference. In scenarios sensitive to network conditions, preprocessing can be moved closer to the user to reduce the round-trip transmission of the original long text, and then the compressed candidates and input templates can be sent to the central node. This implementation does not change the overall process flow; it simply distributes different stages to different computational locations.

[0083] At this point, the relationship between the method embodiment, the system embodiment, and the electronic device embodiment is relatively clear. The method embodiment illustrates the complete processing chain from training to online planning, the system embodiment provides the data flow and functional division between each functional module, and the electronic device embodiment describes the execution entity of the method in the hardware environment. In terms of overall implementation, this scheme does not rely on a specific language model or vector index structure. What truly matters is the coordination between the standard operating procedure samples, the standard operating procedure vector library 102, online procedure retrieval and reordering, and the generation of tool call sequences constrained by the procedures. As long as this relationship is preserved, the specific encoding model, indexing method, deployment location, and execution engine can be adaptively adjusted.

[0084] In one embodiment, the tool constraint information in the target standard operating procedure 4061 can also be organized using a relational diagram, rather than being limited to a linear step description. For some business tasks, the tools are not in a single serial relationship, but rather have branching, merging, or conditional triggering relationships. If only a linear sequence is used to express this, the model input 5041, while constraining the main process, will be weak in expressing branching conditions. Therefore, the procedure extraction unit 501 can organize the tool constraint information into a directed relational structure, where nodes represent tools and edges represent dependencies, prohibitions, or conditional triggering relationships. When constructing the intermediate input template 5021, the template organization unit 502 can transcribe this relational structure into structured text, including preceding tools, subsequent tools, triggering conditions, and exception conditions. In this way, when the tool planning model 101 generates the tool call sequence 601, it not only knows what to call first, but also knows under what conditions to switch to another path.

[0085] For tasks involving branching relationships, the sequence constraint verification unit 602 can further check whether the generated path satisfies the dependency closure requirement. The dependency closure requirement can be understood as follows: if a tool appears in the tool call sequence 601, then all necessary prerequisite tools corresponding to that tool should also appear in the sequence, and precede it. Let the tool set be... A certain tool The set of prerequisite tools is denoted as Then for the generated sequence You can request: In the formula, Indicated in tools The set of tools that has previously appeared in tool call sequence 601 Representation tools The set of prerequisite tools on which it depends. If equation (8) does not hold, it means that at least one tool in the generated sequence is invoked prematurely in the absence of necessary prerequisite tools. The sequence constraint verification unit 602 can identify path gaps based on this and process them through feedback regeneration or rule correction.

[0086] Exception handling and degradation strategies are also important in practical systems. The procedure recall module 704 sometimes encounters two types of exceptions: one is the inability to recall highly relevant entries, and the other is the recall of several semantically similar but conflicting procedures. The former often occurs with new tasks, overly simplistic user expressions, or when the standard operating procedure vector library 102 does not yet cover the task; the latter is often related to overlapping business boundaries, parallel entry versions, or mixed use of multiple business domains. For the first type, the target procedure determination unit 406 can directly output an unlocated status when the ranking score is below a threshold, and the input construction module 705 can be changed to use a general planning template. The general planning template can prioritize more reliable tool steps such as object identification, basic query, information completion, and risk verification. For the second type, the system can introduce conflict resolution rules, such as prioritizing entries with newer versions and matching business domains, or prioritizing entries with more complete sets of essential tools.

[0087] In one embodiment, if the difference between the highest and second-highest ranking scores obtained by the target procedure determination unit 406 is less than a difference threshold, the system can extract the difference field of the top two candidate items and send it to the tool planning model 101 for reference. The difference field typically includes different required tools, different order requirements, or different applicable conditions. This is because, in some scenarios, simply relying on the ranking result is insufficient to reliably distinguish two similar items. However, by explicitly feeding the difference points into the model, the model has the opportunity to process the differences by incorporating fine-grained expressions of user intent. Compared to directly making mandatory decisions on the system side, this approach is more gentle on boundary tasks and also helps preserve the language model's ability to discriminate complex semantics.

[0088] Negative sample constraints can also be introduced during the sample construction phase to prevent the tool planning model 101 from only learning positive paths and lacking exclusion capabilities. Specifically, in addition to the supervised fine-tuning samples 208, some erroneous tool sequences that are semantically close to the user's intent but do not conform to standard operating procedures can be constructed. During training, the difference between correct and erroneous sequences can be widened using ranking loss or contrastive learning loss. In this way, the model not only knows which sequences should be generated, but also more easily learns which tool combinations, although seemingly related, should not appear under the current procedure. If this approach is adopted, the training objective can include a contrastive term in addition to the conditional generation loss. However, this is an optional enhancement; even without it, the aforementioned processing chain based on vector retrieval and procedure constraint input can work independently.

[0089] In other implementations, the vectorized representation of standard operating procedure entry 206 can also be encoded field-by-field. For example, the business intent description can be encoded as a first sub-vector, the tool constraint information as a second sub-vector, and then the two can be concatenated or weighted together to form the final entry vector. This approach is typically used when the system wants to retain different sensitivities to intent semantics and tool paths during the recall phase. Let the business intent description vector be... The tool constraint information vector is The component in the query vector that corresponds to the business intent is The components corresponding to the path features are Then the overall similarity can also be expressed as: In the formula, Indicates the first The overall field-level similarity score of each standard operating procedure item. This represents the weighting coefficient, which can range from 0 to 1. If the current task places greater emphasis on user semantic expression, this value can be increased appropriately. If the differentiation of similar intentions in the current business relies more on differences in tool paths, then the frequency can be appropriately reduced. This approach still falls within the technical framework of vectorizing standard operating procedure entries and building a vector library, but with finer coding granularity.

[0090] Feedback from the execution side can also be considered, but this does not require a closed-loop dependency. That is, after the tool execution service is actually invoked, it can return the successful or failed execution trace to the log alignment unit 203 for subsequent sample updates or procedure verification. If a standard operating procedure consistently exhibits sequence defects, parameter gaps, or excessively long paths at the execution layer, maintenance personnel can revise the standard operating procedure entry 206 or rebuild the supervised fine-tuning sample 208 accordingly. This feedback mechanism helps maintain consistency between the procedure and the real execution environment, but even without its introduction, the aforementioned method implementation can still independently achieve tool planning functionality.

[0091] The embodiment consisting of steps S110 to S150 yields the following technical results: the tool planning model 101, through supervised fine-tuning of standard operating procedure (SOP) samples, can acquire the basic mapping capability from user intent information to tool call sequences; the SOP vector library 102 transforms the business intent descriptions and tool constraint information in the business procedures into a searchable and updatable external knowledge structure; during online inference, the system first retrieves a candidate SOP set 4041 based on the user intent information 4011, then determines the target SOP 4061 based on the reordering results, subsequently constructs the model input 5041 based on the tool constraint information in the target SOP 4061, and the tool planning model 101 generates a tool call sequence 601 corresponding to the target SOP 4061. This processing chain enables tool planning to no longer rely solely on static knowledge in the model parameters, but to introduce currently effective SOP constraints during inference.

[0092] From a processing mechanism perspective, this structure can mitigate two common types of biases. One type of bias occurs when the model's semantic understanding is correct, but it omits preliminary steps or skips essential tools. Since the tool constraint information of the target standard operating procedure 4061 is explicitly included in the model input 5041, and the model is checked by the sequence constraint verification unit 602 after generation, this type of bias is more easily detected and corrected during or after generation. The other type of bias occurs when the business procedure changes, but the model still uses the old path planning. The standard operating procedure vector library 102 can be updated independently, and procedure changes do not need to wait for the entire tool planning model 101 to be retrained before they can be applied to the online inference process. Therefore, the timeliness of the business procedure is more easily transmitted to the final planning result.

[0093] From a system resource perspective, placing a portion of the procedural knowledge into the standard operating procedure vector library 102, rather than simply increasing the parameter burden on the tool planning model 101, is more conducive to system maintenance in engineering. Procedural changes typically manifest as the addition of new entries, the invalidation of existing entries, or adjustments to the partial order. These changes are better handled through knowledge base updates and index reconstruction, rather than necessarily triggering a full model retraining each time. This shortens the path from procedural updates to online effectiveness and reduces the impact of frequent model version switching on service stability.

[0094] From the perspective of execution-level collaboration, tool call sequence 601 contains call identifiers for multiple tools and the execution order relationships between them. Downstream execution services can directly arrange serial or parallel calls based on this structure without needing to parse the step relationships from the free text again. For business chains with multiple intermediate query actions, conditional judgment actions, and final execution actions, this structured output is more suitable for engineering integration and facilitates auditing and problem backtracking.

[0095] It should be noted that the model structure, vector indexing method, scoring function form, module division method, and deployment location involved in the above embodiments are merely examples provided for the purpose of illustrating the technical solution. Other implementation methods can also be adopted without deviating from the core idea of ​​this solution. For example, the re-ranking model 4051 can be replaced by a lightweight discriminative model, the vector retrieval structure can use different approximate indexes according to the item size, and the tool planning model 101 can be deployed in a central node, edge node, or hybrid environment. As long as the technical relationship of training the tool planning model based on standard operating procedure samples, constructing a vector library based on standard operating procedure items, retrieving and determining the target standard operating procedure based on user intent, constructing model input based on tool constraint information and user intent information in the target standard operating procedure, and generating a tool call sequence corresponding to the target standard operating procedure is still maintained, all of these can fall within the scope of this solution.

[0096] It should be understood that the method steps in the foregoing embodiments can be implemented by program instructions controlling related hardware, or by dedicated circuits, programmable logic devices, or a combination thereof. Correspondingly, the systems, devices, modules, units, or components in the foregoing embodiments can be implemented in software, hardware, or a combination of both. The division of modules, units, or components is merely a logical division for the purpose of illustrating the technical solution; in actual implementation, they can be combined, split, or integrated as needed.

[0097] In one embodiment, the electronic device may include a processor, a memory, and a communication interface, wherein the memory is used to store program instructions, and the processor is used to call and execute the program instructions to implement all or part of the steps in the foregoing method embodiments. The electronic device may be a server, a terminal device, an edge computing node, a cloud computing device, or other device with data processing capabilities.

[0098] In one embodiment, this application may also be implemented in the form of a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, causes the processor to implement all or part of the steps in the foregoing method embodiments. The computer-readable storage medium may be a read-only memory, random access memory, flash memory, hard disk, solid-state drive, optical disk, or other non-transitory storage medium.

[0099] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0100] Furthermore, the terms "including," "comprising," and "having" used in the specification are all non-exclusive inclusions; the terms "first," "second," etc., are only used to distinguish technical features and do not indicate limitations on order, quantity, or importance. The execution order of each step in the method embodiments is also not absolutely limited. Without departing from the technical concept of this application, the steps can be adjusted in order, executed in parallel, combined, or split for execution.

Claims

1. A tool planning method, comprising: Obtain a standard operating procedure sample, which includes user intent information and a tool call sequence that conforms to the requirements of the corresponding business procedures; The pre-trained language model is supervised and fine-tuned based on the standard operating procedure samples to obtain the tool planning model. Multiple standard operating procedure (SOP) entries are vectorized to construct a SOP vector library. The SOP entries include business intent descriptions and tool constraint information corresponding to the business intents. Receive user intent information and convert the user intent information into a query vector; Based on the query vector, a search is performed in the standard operating procedure vector library to obtain a set of candidate standard operating procedure entries. The set of candidate standard operating procedure entries is then reordered in conjunction with the user intent information to determine the target standard operating procedure entry. The model input is constructed based on the tool constraint information in the target standard operating procedure entry and the user intent information; The model input is fed into the tool planning model to generate a tool call sequence corresponding to the target standard operating procedure item.

2. The tool planning method as described in claim 1, wherein, The user intent information is the user's natural language intent, and the tool invocation sequence is an atomic tool invocation sequence corresponding to the user's natural language intent.

3. The tool planning method as described in claim 1, wherein, The tool constraint information in the standard operating procedure entry includes at least one of the following: required tool set, tool call order, and execution constraint conditions.

4. The tool planning method as described in claim 1, wherein, Based on the query vector, a search is performed in the standard operating procedure vector library to obtain a set of candidate standard operating procedures, including: Based on the semantic similarity between the query vector and the vector representation of each standard operating procedure (SOP) entry, a preset number of candidate SOP entries are recalled as the candidate SOP set.

5. The tool planning method as described in claim 1, wherein, The candidate standard operating procedure set is reordered based on the user intent information to determine the target standard operating procedure, including: The user intent information and each candidate standard operating procedure (SOP) item are input into the reordering model to obtain the relevance score of each candidate SOP item. The candidate standard operating procedures (SOPs) are sorted according to the relevance score, and the SOP entries that meet the sorting criteria are selected as the target SOPs.

6. The tool planning method as described in claim 1, wherein, The model input is constructed based on the tool constraint information in the target standard operating procedure and the user intent information, including: The business intent description, tool constraint information, and user intent information in the target standard operating procedure are organized according to a preset structure to generate context input for constraining the output of the tool planning model.

7. The tool planning method as described in claim 1, wherein, The standard operating procedure sample is built based on the standard operating procedure document and historical operation logs.

8. The tool planning method as described in any one of claims 1 to 7, wherein, The tool call sequence generated by the tool planning model includes the call identifiers of multiple tools and the execution order of the multiple tools.

9. A tool planning system, comprising: The model training module is used to supervise and fine-tune the pre-trained language model based on standard operating procedure samples to obtain a tool planning model. The output content in the standard operating procedure samples is a tool call sequence that conforms to the requirements of the corresponding business procedures. The knowledge base construction module is used to vectorize multiple standard operating procedure items and construct a standard operating procedure vector library. The standard operating procedure items include business intent descriptions and tool constraint information corresponding to the business intents. The intent processing module is used to receive user intent information and convert the user intent information into a query vector; The procedure recall module is used to search the standard operating procedure vector library based on the query vector to obtain a set of candidate standard operating procedures, and to reorder the set of candidate standard operating procedures in combination with the user intent information to determine the target standard operating procedure. An input construction module is used to construct a model input based on the tool constraint information in the target standard operating procedure and the user intent information. The planning generation module is used to input the model input into the tool planning model and generate a tool call sequence corresponding to the target standard operating procedure.

10. An electronic device comprising a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the tool planning method of any one of claims 1 to 8.

Images