Intelligent agent construction method based on large language model

Abstract

The invention relates to the technical field of agent construction, in particular to an agent construction method based on a large language model, and the method comprises the steps: S1, configuring a scenarized execution specification which comprises the steps: receiving constraint information of an execution component in a scene according to a preset scene; converting the constraint information into a structured cue language which can be understood by a large language model, and generating a standard verification rule base which can be analyzed by an execution component; and storing the structured prompt words and the standard verification rule base. According to the method, by configuring the scenarized execution specification, the constraint information of the execution component is converted into a structured cue which can be understood by a large language model and a specification verification rule base which can be analyzed by the execution component, and the problems of non-explicit constraint such as inconsistent parameter naming and non-standardized data type are solved.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of intelligent agent construction, and particularly relates to an intelligent agent construction method based on a large language model. BACKGROUND

[0002] With the deep penetration of large language models in natural language processing, dialogue systems and intelligent decision support, the technical path of intelligent agent construction driven by large language models as the cognitive core is becoming the mainstream direction of the development of artificial intelligence. Large language models have strong semantic understanding, context reasoning and instruction generation capabilities through massive corpus training, enabling them to perform semantic analysis and strategy deduction for complex tasks. Intelligent agent systems emphasize autonomous perception, path planning and action execution in dynamic environments, and their core value lies in behavior closed loop and environment interaction. Embedding a large language model into an intelligent agent architecture aims to integrate language intelligence and behavior intelligence, thereby realizing more natural human-machine collaboration and more accurate task execution in applications such as customer service response, office process automation and home scene control.

[0003] Among them, the key technical direction of constructing an intelligent agent based on a large language model is to realize semantic alignment and structural adaptation between reasoning output and execution components. The core goal of this direction is to enable the reasoning results generated by the large language model, including task step sequences, parameter assignments, condition judgments and priority orders, to be losslessly parsed and directly called by downstream execution modules, thereby constructing an end-to-end autonomous decision-execution path. Ideally, an intelligent agent should be able to automatically generate instruction structures that meet execution specifications based on environmental inputs, without the need for human intervention to complete the complete mapping from intent understanding to physical / digital action.

[0004] The existing technology generally has the problem of structural misalignment between reasoning results and execution requirements when achieving the above goal. Although large language models can generate reasoning texts with rich semantics and logical coherence, their output format lacks explicit constraints on the interface specifications of execution components, resulting in inconsistent task parameter naming, non-standardized data types, non-encoded priority of execution order, and non-bound trigger threshold of condition branches. Such output cannot be directly parsed by tool calling modules, action execution engines or state update interfaces, forcing the system to rely on manual rule mapping or post-processing scripts for format conversion, which not only significantly increases response delay, but also weakens the generalization ability and adaptive flexibility of intelligent agents in cross-scene and multi-task environments. Especially in complex application scenarios that require high-frequency interaction and real-time response, this structural fault has become a core bottleneck restricting the upper limit of intelligent agent performance and deployment efficiency, and an intelligent agent construction mechanism that can dynamically adapt reasoning semantics and execution structure is urgently needed. SUMMARY

[0005] To address the shortcomings of existing technologies, this invention provides a method for constructing intelligent agents based on large language models, which solves the problems of structural misalignment between inference results and execution requirements, the need for manual format conversion, response delays, and weak generalization ability in existing technologies.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for constructing an intelligent agent based on a large language model, comprising:

[0007] S1. Configure scenario-based execution specifications, which include:

[0008] Based on the preset scenario, receive the constraint information of the execution component in the scenario and perform integrity verification on the constraint information; for multi-component collaborative work scenarios, additionally capture the collaborative constraint information between components;

[0009] The constraint information is transformed into structured prompts that can be understood by the large language model, and a set of specification verification rules that can be parsed by the execution components is generated.

[0010] Store structured prompts and a standardized validation rule base;

[0011] S2. Optimize large language model inference generation, wherein the optimized large language model inference generation includes:

[0012] Receive environmental input and obtain the structured prompts corresponding to the environmental input;

[0013] The environmental input and structured prompts are fused together as input to the large language model. Before fusion, the task structure template corresponding to the scene is loaded to enhance the structure compliance capability of the large language model.

[0014] The large language model generates semantic-structural fusion text based on the fusion input. The semantic-structural fusion text contains task sequences, parameters, condition judgments, and priority information embedded according to structured prompts. The output format of the semantic-structural fusion text generated by the large language model is pre-validated.

[0015] S3. Adapting the semantic-structure fused text, wherein adapting the semantic-structure fused text includes:

[0016] Semantic verification is performed on the semantic-structure fusion text. The semantic verification includes determining whether the semantics of the parameters in the semantic-structure fusion text are consistent with the standard verification rule base based on the semantic similarity threshold preset for the current scene and the semantic mapping table in the standard verification rule base. The semantic mapping table contains scene-based synonym mapping relationships and corrects inconsistent parameter semantics.

[0017] Structural validation is performed on the semantic-structural fusion text. This validation includes checking the structural integrity and correctness of the semantic-structural fusion text according to the specification validation rule base. If the structural validation finds that the semantic-structural fusion text does not comply with the prompt format of the LLM, it will first be automatically corrected according to the specification validation rule base. If the automatic correction cannot meet the format requirements, a preset format repair template will be triggered for supplementary correction. If the structural validation encounters new situations not covered by the preset rules, a rollback mechanism will be triggered to feed the semantic-structural fusion text back to the large language model for regeneration, and the new situations will be recorded simultaneously to update the preset rules and correct incomplete or incorrect structures.

[0018] The semantic-structural fusion text, after semantic and structural validation, is used to generate an execution-ready instruction.

[0019] S4. Dynamically iterate the scenario-based execution specification, wherein the dynamic iteration of the scenario-based execution specification includes:

[0020] The system senses changes in the execution environment and execution components, performs frequency statistics on the sensed changes, and only proceeds to the next analysis step when the frequency of changes reaches a preset threshold.

[0021] Analyze the changes and determine whether the scenario-based execution specifications need to be updated. The determination is based on preset quantitative indicators, including the frequency of changes, the number of affected components, and the coverage of user needs. If there are specification conflicts in multi-scenario collaboration, the conflicts are resolved based on scenario priority and component dependencies.

[0022] Based on the judgment results, the scenario-based execution specifications are automatically updated.

[0023] Furthermore, in step S1, constraint information of the execution components in a preset scenario is received, and the integrity of the constraint information is verified. For multi-component collaborative work scenarios, additional collaborative constraint information between components is captured, specifically including:

[0024] It supports developers in inputting key constraint information of execution components in a given scenario. Key constraint information includes parameter naming rules, data type requirements, execution order priority identifiers, and conditional branch trigger threshold formats. It calls the execution component interface to obtain hidden parameter information and adds it to the constraint information. It performs integrity verification on the input key constraint information and the added hidden parameter information. For multi-component collaborative work scenarios, it captures the collaborative constraint information of execution order dependencies and parameter passing rules between components.

[0025] Furthermore, the process in S1, which involves converting constraint information into structured prompts that a large language model can understand and generating a canonical validation rule base that the execution component can parse, specifically includes:

[0026] Automatically convert constraint information into structured prompts that can be understood by a large language model;

[0027] Generate a standardized validation rule library that includes semantic mapping tables and structural validation logic.

[0028] Furthermore, the step S2 of receiving environmental input and obtaining a structured prompt corresponding to the environmental input specifically includes:

[0029] The intelligent agent receives environmental input, which includes user commands and scene state data.

[0030] The system dynamically matches scene identifiers based on environmental input and calls the structured prompts corresponding to the scene identifiers.

[0031] Furthermore, in S2, the large language model generates semantic-structural fusion text based on the fusion input. This semantic-structural fusion text includes task sequences, parameters, conditional judgments, and priority information embedded according to structured prompts. The output format of the semantic-structural fusion text generated by the large language model is pre-validated, specifically including:

[0032] The large language model is configured to embed task sequences, parameters, conditional judgments, and priority information into the semantic-structural fusion text in key-value pairs or label wrapping, in accordance with the structural requirements of the structured prompts.

[0033] Furthermore, in step S3, semantic verification is performed on the semantic-structure fused text. This semantic verification includes determining whether the semantics of the parameters in the semantic-structure fused text are consistent with the standardized verification rule base, based on a preset semantic similarity threshold for the current scene and a semantic mapping table in the standardized verification rule base. The semantic mapping table contains scene-specific synonym mapping relationships, and inconsistent parameter semantics are corrected. Specifically, this includes:

[0034] By calculating semantic similarity, it is determined whether the semantics of the parameters in the semantic-structural fusion text are consistent with the specifications in the semantic mapping table;

[0035] If there is a discrepancy, the inconsistent parameter semantics will be corrected to the parameter semantics in the specification.

[0036] Furthermore, in S3, the semantic-structure fusion text undergoes structural verification. This structural verification includes checking the structural integrity and correctness of the semantic-structure fusion text according to a standardized verification rule base, and correcting incomplete or incorrect structures. Specifically, this includes:

[0037] Perform data type validation on semantic-structural fused text;

[0038] Priority encoding verification is performed on semantic-structural fusion text;

[0039] Perform conditional branching validation on semantic-structural fusion text.

[0040] Furthermore, the data type validation of the semantic-structural fusion text specifically includes:

[0041] Identify non-numeric type parameters in semantic-structural fusion text;

[0042] Change non-numeric type parameters to numeric type parameters.

[0043] Furthermore, the priority encoding verification of the semantic-structural fusion text specifically includes:

[0044] If the semantic-structural fusion text does not specify the execution priority, the execution priority will be supplemented according to the default priority rules preset in the scenario specification.

[0045] Furthermore, the dynamic iterative scenario-based execution specification in S4 specifically includes:

[0046] By using at least one of the methods of interface listening and log analysis, at least one of the changes in the execution component interface update and environmental input feature changes is captured in real time. Frequency statistics are performed on the captured changes, and the subsequent steps are only taken when the frequency of changes reaches a preset threshold.

[0047] The captured changes are categorized, and it is determined whether the scenario-based execution specifications need to be updated. The determination of whether the scenario-based execution specifications need to be updated is based on preset quantitative indicators, including the frequency of changes, the number of affected components, and the coverage of user needs. If there are specification conflicts in multi-scenario collaboration, the conflicts are resolved based on scenario priority and component dependency relationships.

[0048] If an update is required, a specification update suggestion will be generated based on the changed content, and the structured prompts for the scenario and the specification verification rule base will be updated.

[0049] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0050] This invention addresses the lack of explicit constraints, such as inconsistent parameter naming and non-standardized data types, by configuring scenario-based execution specifications. It transforms the constraint information of execution components into structured prompts understandable by a large language model and a rule base for parsing specifications that the execution components can parse. Furthermore, it optimizes the large language model's inference generation, fusing environmental input with structured prompts to generate semantic-structural fusion text containing task sequences, parameters, conditional judgments, and priority information, avoiding chaotic inference output formats. Next, semantic verification corrects parameter semantic deviations, and structural verification refines the text structure, ensuring the output can be directly parsed by the execution components. Finally, it dynamically iterates the scenario-based execution specifications to adapt to changes in the execution environment and components. The entire process requires no manual intervention for format conversion, solving the structural misalignment between inference results and execution requirements in existing technologies, reducing response latency, improving the agent's cross-scenario generalization ability and adaptive resilience, and overcoming bottlenecks in execution and deployment efficiency. Attached Figure Description

[0051] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0053] Please see Figure 1 This invention provides a method for constructing an intelligent agent based on a large language model, comprising:

[0054] S1. Configure scenario-based execution specifications, which include:

[0055] Based on the preset scenario, receive the constraint information of the execution component in the scenario and perform integrity verification on the constraint information; for multi-component collaborative work scenarios, additionally capture the collaborative constraint information between components;

[0056] The constraint information is transformed into structured prompts that can be understood by the large language model, and a set of specification verification rules that can be parsed by the execution components is generated.

[0057] Store structured prompts and a standardized validation rule base;

[0058] S2. Optimize large language model inference generation. Optimization of large language model inference generation includes:

[0059] Receive environmental input and obtain the structured prompts corresponding to the environmental input;

[0060] The environmental input and structured prompts are fused together as input to the large language model. Before fusion, the task structure template corresponding to the scene is loaded to enhance the structure compliance capability of the large language model.

[0061] The large language model generates semantic-structural fusion text based on the fusion input. The semantic-structural fusion text contains task sequences, parameters, condition judgments, and priority information embedded according to structured prompts. The output format of the semantic-structural fusion text generated by the large language model is pre-validated.

[0062] S3. Adapting semantic-structural fusion text, which includes:

[0063] Semantic verification is performed on the semantic-structure fusion text. The semantic verification includes determining whether the semantics of the parameters in the semantic-structure fusion text are consistent with the standard verification rule base based on the semantic similarity threshold preset for the current scene and the semantic mapping table in the standard verification rule base. The semantic mapping table contains the scene-based synonym mapping relationship and corrects the inconsistent parameter semantics.

[0064] Structural validation is performed on the semantic-structural fusion text. This validation includes checking the structural integrity and correctness of the semantic-structural fusion text according to the specification validation rule base. If the structural validation finds that the semantic-structural fusion text does not comply with the prompt format of the LLM, it will first be automatically corrected according to the specification validation rule base. If the automatic correction cannot meet the format requirements, a preset format repair template will be triggered for supplementary correction. If the structural validation encounters new situations not covered by the preset rules, a rollback mechanism will be triggered to feed the semantic-structural fusion text back to the large language model for regeneration, and the new situations will be recorded simultaneously to update the preset rules and correct incomplete or incorrect structures.

[0065] The semantic-structural fusion text, after semantic and structural validation, is used to generate an execution-ready instruction.

[0066] S4. Dynamic Iterative Scenario-Based Execution Specifications, which include:

[0067] The system senses changes in the execution environment and execution components, performs frequency statistics on the sensed changes, and only proceeds to the next analysis step when the frequency of changes reaches a preset threshold.

[0068] Analyze the changes and determine whether the scenario-based execution specifications need to be updated. The determination is based on preset quantitative indicators, including the frequency of changes, the number of affected components, and the coverage of user needs. If there are specification conflicts in multi-scenario collaboration, the conflicts are resolved based on scenario priority and component dependencies.

[0069] Based on the judgment results, the scenario-based execution specifications are automatically updated.

[0070] Specifically, taking the office workflow automation scenario as an example, the preset scenario is first defined as "multi-component collaborative office task processing," and the execution components include a document generation component, an email sending component, and an attachment compression component. First, the constraint information of these execution components is received, and the integrity of the constraint information is verified to ensure that key constraints such as parameter naming rules and data type requirements are not missing. Simultaneously, the hidden parameter information of "default storage path" is obtained by calling the document generation component's interface and added to the constraint information. For multi-component collaborative work scenarios, additional collaborative constraint information between components is captured. For example, the email sending component needs to receive the document path parameter output by the document generation component, and the attachment compression component needs to execute collaborative rules after document generation and before email sending. For instance, the document generation component requires that the "document format" parameter name cannot be replaced by "file type," and the data type must be a string; the email sending component requires that the "recipient email address" data type be a string conforming to the email address format, and the execution order must be after document generation, with higher priority than document archiving; the attachment compression component requires that the "trigger threshold" be a numeric type and only activate when the attachment size exceeds this threshold.

[0071] Next, these constraints are transformed into structured prompts that the large language model can understand. These prompts must clearly define the task-related requirements, such as: "When generating a task sequence, the 'document format' parameter of the document generation component must not be replaced, and the data type must be a string; email sending must be performed after document generation, with a priority of 1, and document archiving priority is set to 2; compression is triggered when the attachment size exceeds a threshold, and the threshold parameter is a numeric type." Simultaneously, a specification validation rule base is generated. The semantic mapping table records the correspondence between "file type" and "document format," and the structure validation logic includes criteria for judging parameter naming compliance, data type matching, and execution order relevance. The structured prompts and the specification validation rule base are then stored in a dedicated database for easy access later.

[0072] When the agent receives environmental input, such as the user instruction "Generate last week's sales summary document and send it to the sales director; compress large attachments first," and simultaneously obtains the scenario status data "Last week's sales data has been summarized into the system," it dynamically matches the "Office Process Automation" scenario identifier and invokes the corresponding structured prompt. Before merging the environmental input and structured prompt, a task structure template for the "Multi-Component Collaborative Office Task Processing" scenario is loaded. This template defines a fixed framework for the task sequence, requiring it to include "Generate document → Compress attachments (if needed) → Send email → Archive," to enhance the structural compliance capability of the large language model. The environmental input and prompt are then input into the large language model. The large language model generates semantic-structural fusion text based on the fusion input. The text contains the task sequence "Generate last week's sales summary document → Check attachment size → Compress if necessary → Send email to sales director", with parameters "Document format = PDF, Recipient email = Sales director's email address, Attachment compression threshold = 20", conditional judgment "Execute compression if attachment size > 20", and priorities "Email sending = 1, Document generation = 2, Attachment compression = 3, Document archiving = 4". The output format of the semantic-structural fusion text generated by the large language model is pre-validated to check whether it conforms to the task structure template framework and parameter format requirements. If the pre-validation finds that the "Document archiving" task is missing, the large language model is returned to regenerate it.

[0073] Subsequently, semantic verification is performed on the fused text. Based on the semantic mapping table of the standard verification rule base, the semantic mapping table contains scenario-based synonym mapping relationships, such as "report format" and "file type" both mapping to "document format". According to the current scenario's preset semantic similarity threshold of 0.8, semantic similarity calculation is used to determine whether the parameters are semantically consistent. Here, the cosine similarity algorithm from the existing technology is used, and its calculation formula is shown in equation (1):

[0074]

[0075] In the formula, Represents the semantic vector of the parameter to be verified With the semantic vector of the canonical parameters The similarity value ranges from [0,1]. semantic vector of the parameter to be verified The Each dimension component; To standardize the parameter semantic vector The Each dimension component; This refers to the dimension of the semantic vector. It transforms semantic parameters such as "file type" from the fused text into vectors. The "document format" in the semantic mapping table is converted into a vector. Substitute into equation (1) to calculate the similarity. If the calculation result is lower than the preset threshold, such as 0.8, it is determined that the semantics are inconsistent and the "file type" is automatically corrected to "document format".

[0076] During structure verification, if the structure verification finds that the semantic-structure fusion text does not conform to the prompt format, such as the "attachment compression threshold" not specifying the unit, it will first automatically correct it according to the specification verification rule base, adding "unit is MB". If the automatic correction cannot meet the format requirements, such as the LLM not generating a conditional judgment statement, the preset format repair template will be triggered to supplement and correct it. The template will automatically add the condition "if the attachment size is greater than the threshold, then perform compression". If the "default storage path" parameter is found to be missing, the structure integrity will be checked according to the rule base, and "default storage path = C:\OfficeDocs\Sales" will be added. If the "document archive" does not specify the priority, the structure will be corrected according to the rule base, and the priority "4" will be added. If the structure verification encounters a new situation not covered by the preset rules, such as the LLM generating an "encrypted document" task without a corresponding verification rule, the rollback mechanism will be triggered. The semantic-structure fusion text will be fed back to the large language model for regeneration, and the "encrypted document" task status will be recorded simultaneously to update the preset rules. After the verification is completed, an execution-ready instruction will be generated, which can be directly parsed and executed by the document generation, attachment compression, and email sending components.

[0077] Subsequently, we monitor changes in the execution component's interface in real time using an interface monitoring tool. If we find that the email sending component has added a "CC recipient" parameter interface, and log analysis shows that the frequency of "CC recipient" requests in recent user commands has increased significantly and the daily average frequency has exceeded 5 times for 7 consecutive days, reaching the preset threshold, we perform frequency statistics on these changes. After confirming that the preset threshold has been reached, we proceed to the classification and analysis step. The captured changes are categorized into "execution component interface updates" and "environment input characteristic changes." A preset quantitative indicator is used to determine whether the scenario-based execution specification needs updating. This indicator includes a change frequency exceeding 5 times per day for 7 consecutive days, affecting one email sending component, and a user demand coverage rate exceeding 30% (35% or more). If multiple scenarios have specification conflicts, such as a conflict between the office workflow automation scenario and the customer service scenario regarding the mandatory "CC" parameter in the email sending component (the office workflow automation scenario requires "CC" to be optional, while the customer service scenario requires it to be mandatory), then based on scenario priority (office workflow automation scenario is higher than customer service scenario) and component dependencies (no other component dependencies resolve conflicts), the "CC" parameter is determined to be optional in the office workflow automation scenario. Based on the changes in content, the system generates specification update suggestions, adds parameter naming rules and data type requirements for "CC recipient emails" to the constraint information, synchronously updates the structured prompts, adds configuration requirements for "CC recipient emails," and updates the specification validation rule base, supplementing the semantic mapping and structural validation logic for "CC recipient emails," thereby enabling dynamic iteration of scenario-based execution specifications. Through this series of processes, the system effectively solves the problem of structural misalignment between inference results and execution requirements in existing technologies, eliminating the need for manual format conversion and improving the agent's response efficiency and cross-scenario adaptability.

[0078] Before deploying the intelligent agent, the effectiveness of the scenario-based specifications and the cross-scenario performance of LLM are verified through multi-scenario case tests. For each scenario, no less than 50 different task cases are selected for testing. The LLM output format compliance rate, constraint information capture accuracy rate, and cross-scenario migration adaptation rate are recorded. Deployment is completed only when the LLM output format compliance rate is not less than 95%, the constraint information capture accuracy rate is not less than 92%, and the cross-scenario migration adaptation rate is not less than 88%. This ensures that the intelligent agent can perform stably in different scenarios such as office process automation, customer service, and industrial control, and can quickly adapt to the constraint specifications of new scenarios, especially when migrating across scenarios.

[0079] In this embodiment, step S1 receives constraint information of the execution components according to a preset scenario and performs integrity verification on the constraint information; for multi-component collaborative work scenarios, additional collaborative constraint information between components is captured, specifically including:

[0080] It supports developers in inputting key constraint information of execution components in a given scenario. Key constraint information includes parameter naming rules, data type requirements, execution order priority identifiers, and conditional branch trigger threshold formats. It calls the execution component interface to obtain hidden parameter information and adds it to the constraint information. It performs integrity verification on the input key constraint information and the added hidden parameter information. For multi-component collaborative work scenarios, it captures the collaborative constraint information of execution order dependencies and parameter passing rules between components.

[0081] Specifically, in the pre-defined office workflow automation scenario, developers input key constraint information for the execution components through the constraint information input module of the intelligent agent configuration interface. For the document generation component, the parameter naming rules are clearly defined: "Document Format" cannot be replaced by names such as "Report Format" or "File Type"; data types require "Generation Time" to be a date and time type and "Document Pages" to be an integer type; execution order priority identifiers use a numerical code from 1 to 5, with "Document Generation" having a lower priority code than "Email Sending"; the conditional branch trigger threshold format specifies that "Attachment Size Threshold" must be expressed in the form of "numerical value + unit MB," such as "20MB," rather than vague descriptions like "very large" or "exceeds the limit." The hidden parameter information of "Default Storage Path" is obtained by calling the document generation component interface and added to the constraint information; the completeness of the input key constraint information and the added "Default Storage Path" parameter is verified to confirm that no key parameters such as "Generation Time" or "Document Pages" are missing; for multi-component collaborative work scenarios, the collaborative constraint information that the email sending component needs to receive the "Default Storage Path" parameter from the document generation component and that the attachment compression component needs to execute after document generation is captured. By clearly defining the content of key constraint information, we can ensure that the structured prompts and standardized verification rule bases for subsequent transformations accurately match the requirements of the execution components, thus avoiding deviations in subsequent reasoning generation and execution parsing due to ambiguity in constraint information.

[0082] In this embodiment, step S1, which involves converting constraint information into structured prompts that the large language model can understand and generating a canonical validation rule base that the execution component can parse, specifically includes:

[0083] Automatically convert constraint information into structured prompts that can be understood by a large language model;

[0084] Generate a standardized validation rule library that includes semantic mapping tables and structural validation logic.

[0085] Specifically, based on the constraint information entered by the developers in the previous embodiment, the intelligent agent's built-in prompt conversion module automatically transforms the constraint information into structured prompts that the large language model can understand. For example, "Document format parameter naming cannot be replaced by 'file type', and the data type is string" is transformed into "When generating task-related text, the 'document format' parameter naming of the document generation component cannot be replaced, and the data type must be string." Simultaneously, a standard validation rule base is generated. The semantic mapping table in the rule base includes the correspondence between all standard parameter names and common erroneous parameter names, such as mapping "file type" and "report format" to "document format." The structure validation logic includes logic modules such as parameter naming compliance judgment, data type matching check, execution order priority encoding verification, and conditional branch trigger threshold format verification, ensuring that subsequent semantic and structure validations have clear basis and improving validation accuracy and efficiency.

[0086] In this embodiment, receiving environmental input and obtaining the structured prompts corresponding to the environmental input in S2 specifically includes:

[0087] The intelligent agent receives environmental input, which includes user commands and scene state data.

[0088] The system dynamically matches scene identifiers based on environmental input and calls the structured prompts corresponding to the scene identifiers.

[0089] Specifically, the intelligent agent receives environmental input through a user interaction terminal. The user command is "Generate this month's financial report and send it to the CFO." Simultaneously, the agent retrieves scenario status data via the system data interface: "This month's financial data has been summarized; the storage path is the system's financial folder." The agent's scenario matching module extracts keywords from the environmental input, such as "financial report" and "CFO," and compares them with a pre-set scenario identifier library, dynamically matching the "financial office process" scenario identifier. Subsequently, it retrieves the structured prompts corresponding to the "financial office process" scenario identifier from the stored database, ensuring that the information from the subsequent input large language model accurately matches the current scenario's execution requirements, laying the foundation for generating fused text that meets the execution requirements.

[0090] In this embodiment, step S2 involves enabling the large language model to generate semantic-structural fusion text based on the fusion input. This semantic-structural fusion text includes task sequences, parameters, conditional judgments, and priority information embedded according to structured prompts. The output format of the semantic-structural fusion text generated by the large language model is pre-validated, specifically including:

[0091] The large language model is configured to embed task sequences, parameters, condition judgments, and priority information into semantic-structure fusion text in key-value pairs or tag-wrapped form, according to the structural requirements in the structured prompts and the task structure template of the corresponding scenario. The generated semantic-structure fusion text is pre-validated to check whether the task sequence conforms to the template framework, whether the parameters are complete, and whether the condition judgments are clear.

[0092] Specifically, the large language model receives the fused environmental input and structured prompts, and generates semantic-structure fused text according to the structural requirements in the prompts and the task structure template of the "financial office process" scenario. The text content is organized in key-value pairs, such as "Task sequence: Generate this month's financial report → Check attachment size → Compress if necessary → Send email to CFO; Parameters: Document format = Excel, Recipient email = CFO's email address, Attachment compression threshold = 20; Condition judgment: Attachment size > 20, then compress; Priority: Send email = 1, Generate this month's financial report = 2, Attachment compression = 3, Document archiving = 4". The generated semantic-structure fused text is pre-validated to check whether the task sequence conforms to the template framework of "Generate document → Compress attachment (if necessary) → Send email → Archive", confirm that the "Financial report archiving" task is not missing, the parameters such as "default storage path" and "attachment compression threshold" are not missing, and the condition judgment "Attachment size > 20" is clearly stated. After the pre-validation passes, the subsequent validation steps are performed. This organizational structure enables the execution components to quickly identify task sequences, parameters, conditional statements, and priority information, avoiding parsing difficulties caused by messy text formats and improving the parsing efficiency of the execution components for fused text.

[0093] In this embodiment, S3 performs semantic verification on the semantic-structure fused text. This semantic verification includes determining whether the semantics of the parameters in the semantic-structure fused text are consistent with the standardized verification rule base based on a preset semantic similarity threshold for the current scene and a semantic mapping table in the standardized verification rule base. The semantic mapping table contains scene-specific synonym mapping relationships, and inconsistent parameter semantics are corrected. Specifically, this includes:

[0094] By calculating semantic similarity, it is determined whether the semantics of the parameters in the semantic-structural fusion text are consistent with the specifications in the semantic mapping table;

[0095] If there is a discrepancy, the inconsistent parameter semantics will be corrected to the parameter semantics in the specification.

[0096] Specifically, in the semantic verification stage, the semantic mapping table of the standard verification rule base is called, and the semantic similarity is calculated to determine whether the semantics of the parameters are consistent with the standard. Here, the cosine similarity algorithm used in the above embodiment is adopted, and Equation (1) is used for calculation. The semantics of the parameters to be verified in the fused text, such as "report format", are converted into vectors. Standardize parameter semantics, such as "document format," into vectors. Substitute into equation (1) to calculate the similarity value between the two. If the calculated similarity value is lower than a preset threshold, such as 0.8, the parameter semantics are determined to be inconsistent with the specification. The inconsistent parameter semantics "report format" are automatically corrected to the parameter semantics "document format" in the specification. In this way, it is ensured that the parameter semantics in the fused text meet the requirements of the execution component, avoiding the execution component's inability to recognize parameters due to semantic deviations, and ensuring the smooth execution of instructions.

[0097] In this embodiment, S3 performs structural verification on the semantic-structural fusion text. Structural verification includes checking the structural integrity and correctness of the semantic-structural fusion text according to the standard verification rule base, and correcting incomplete or incorrect structures. Specifically, this includes:

[0098] Perform data type validation on semantic-structural fused text;

[0099] Priority encoding verification is performed on semantic-structural fusion text;

[0100] Perform conditional branching validation on semantic-structural fusion text.

[0101] Specifically, during structure validation, three core validations are performed based on the standard validation rule base. First, data type validation is performed to check if the data types of each parameter in the merged text meet the requirements. For example, "attachment compression threshold" must be a numeric type; if a non-numeric expression like "attachment compression threshold = large" appears, it should be corrected to "attachment compression threshold = 25". Second, priority coding validation is performed to check if each task is marked with a priority. If "financial statement archive" is not marked, the code should be added according to the rules. Finally, conditional branch validation is performed to check if the condition judgment includes a clear trigger threshold. For example, "compress large attachments" should be corrected to "compress attachments > 20". If structure validation finds that the LLM does not comply with the prompt format, such as "recipient email" not being marked in the format of "email address + name", the name information is automatically added according to the standard validation rule base, correcting it to "recipient email = CFO's email address (CFO)". If automatic correction cannot meet the format requirements, such as the LLM not generating an "attachment compression" task step, a preset format repair template is triggered, and the template automatically inserts the "check attachment size → compress if needed" step. If the structural verification encounters new situations not covered by the preset rules, such as an LLM-generated "financial statement encryption" task without corresponding verification rules, a fallback mechanism is triggered. The semantic-structural fused text is fed back to the large language model for regeneration, and information such as the parameter requirements and execution order of the "financial statement encryption" task is recorded simultaneously to update the preset rules. Through these three verifications, the integrity and correctness of the fused text structure are ensured, meeting the parsing standards of the execution components and reducing execution failures caused by structural issues.

[0102] In this embodiment, data type validation is performed on the semantic-structural fusion text, specifically including:

[0103] Identify non-numeric type parameters in semantic-structural fusion text;

[0104] Change non-numeric type parameters to numeric type parameters.

[0105] Specifically, during data type validation, the agent's parameter type recognition module scans all parameters in the semantic-structural fusion text. When it finds non-numeric parameters such as "attachment size = very large" or "generation time = recent," it corrects these parameters to numeric types by combining the default execution standard of the current scenario with historical execution data. For example, "attachment size = very large" is corrected to "attachment size = 30 MB," a value determined based on the common large attachment threshold in the scenario; "generation time = recent" is corrected to "generation time = 2024-10-08," a date taken from the day before the current validation date, conforming to the semantics of "recent." This correction method ensures that the parameter data type meets the requirements of the execution component, preventing the execution component from failing to process instructions correctly due to data type errors.

[0106] In this embodiment, priority encoding verification is performed on the semantic-structural fusion text, specifically including:

[0107] If the semantic-structural fusion text does not specify the execution priority, the execution priority will be supplemented according to the default priority rules preset in the scenario specification.

[0108] Specifically, during priority encoding verification, if the task "Financial Statement Archiving" in the semantic-structural fusion text is found to lack an execution priority label, the default priority rule preset in the scenario specification is invoked. This rule stipulates that "archiving tasks have lower priority than sending and generating tasks." Given that "Sending this month's financial statements" has a priority of 1 and "Generating this month's financial statements" has a priority of 2, priority code 3 is added to "Financial Statement Archiving" according to the rule. After this addition, the task execution order is clearly defined as "Generate this month's financial statements → Send this month's financial statements → Financial Statement Archiving," preventing task execution chaos due to missing priorities and ensuring the orderly collaborative execution of multiple tasks.

[0109] In this embodiment, the dynamic iterative scenario-based execution specification in S4 specifically includes:

[0110] By using at least one of the methods of interface listening and log analysis, at least one of the changes in the execution component interface update and environmental input feature changes is captured in real time. Frequency statistics are performed on the captured changes, and the subsequent steps are only taken when the frequency of changes reaches a preset threshold.

[0111] The captured changes are categorized, and it is determined whether the scenario-based execution specifications need to be updated. The determination of whether the scenario-based execution specifications need to be updated is based on preset quantitative indicators, including the frequency of changes, the number of affected components, and the coverage of user needs. If there are specification conflicts in multi-scenario collaboration, the conflicts are resolved based on scenario priority and component dependency relationships.

[0112] If an update is required, a specification update suggestion will be generated based on the changed content, and the structured prompts for the scenario and the specification verification rule base will be updated.

[0113] Specifically, the system uses an interface monitoring tool to capture changes in the execution component's interface in real time. If a new "watermark setting" parameter interface is added to the document generation component, and if a log analysis tool is used to analyze recent user commands and finds that the frequency of requests to "add company watermark" has exceeded 8 times per day for 10 consecutive days, reaching a preset threshold, frequency statistics are performed on these two types of changes. Once it is confirmed that both have reached the preset threshold, the system proceeds to the next step. These two types of changes are categorized as "addition of execution component parameters" and "changes in environmental input characteristics." Based on preset quantitative indicators, it is determined whether the scenario-based execution specifications need to be updated. These indicators include a change frequency exceeding 8 times per day for 10 consecutive days, affecting one document generation component, and a user demand coverage rate exceeding 30% (42%). If multiple scenarios have specification conflicts, such as a conflict between the office workflow automation scenario and the external audit scenario regarding the display position of the "watermark settings" parameter (the office workflow automation scenario requires the watermark to be displayed in the upper left corner, while the external audit scenario requires the watermark to be displayed in the middle), then based on the scenario priority (external audit scenario is higher than office workflow automation scenario) and component dependency relationships (no other component dependencies resolve conflicts for the document generation component), it is determined that the "watermark settings" parameter in the office workflow automation scenario can support both "upper left corner" and "middle" display positions. Based on the change content generation specification update suggestions, it is recommended to add a parameter naming rule for "watermark settings" in the constraint information, namely, "watermark configuration" cannot be used as a substitute, and the data type requirement is string type, such as "company LOGO watermark (upper left corner)" and "text watermark (middle)". Based on the recommendations, the structured prompts for the scenario are automatically updated, the configuration requirements for "watermark settings" are added, and the standard verification rule base is updated. The semantic mapping and structural verification logic of "watermark settings" are supplemented to achieve dynamic optimization of scenario-based execution standards and improve the agent's adaptability to changes in the execution environment and components.

[0114] In summary, this invention, by configuring scenario-based execution specifications, transforms the constraint information of execution components into structured prompts understandable by a large language model and a specification verification rule base parsable by the execution components, solving problems such as inconsistent parameter naming and non-standardized data types due to the lack of explicit constraints. It then optimizes the large language model's inference generation, fusing environmental input with structured prompts to generate semantic-structural fusion text containing task sequences, parameters, conditional judgments, and priority information, avoiding chaotic inference output formats. Next, semantic verification corrects parameter semantic deviations, and structural verification improves the text structure, ensuring the output can be directly parsed by the execution components. Finally, it dynamically iterates the scenario-based execution specifications to adapt to changes in the execution environment and components. The entire process requires no manual intervention in format conversion, solving the structural misalignment between inference results and execution requirements in existing technologies, reducing response latency, improving the agent's cross-scenario generalization ability and adaptive elasticity, and overcoming bottlenecks in execution and deployment efficiency.

[0115] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0116] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for constructing an agent based on a large language model, characterized in that, The method comprises the following steps: S1, configuring a scenario execution specification, wherein the configuration scenario execution specification comprises: According to the preset scene, the constraint information of the execution component in the scene is received, and the integrity of the constraint information is checked. For the multi-component collaborative work scene, the inter-component collaborative constraint information is additionally captured; The constraint information is converted into a structured prompt understandable by the large language model, and a specification verification rule library that can be parsed by the execution component is generated; The structured prompt and the specification verification rule library are stored; S2, optimizing the large language model inference generation, comprising: Receiving environmental input and obtaining the structured prompt corresponding to the environmental input; Fusing the environmental input and the structured prompt as the input of the large language model, and loading the task structure template of the corresponding scene before fusing the environmental input and the structured prompt, so as to enhance the structure following ability of the large language model; The large language model generates semantic-structure fusion text according to the fused input, and the semantic-structure fusion text contains task sequence, parameters, conditional judgment and priority information embedded according to the structured prompt. The output format of the semantic-structure fusion text generated by the large language model is pre-verified; S3, adapting the semantic-structure fusion text, comprising: Performing semantic verification on the semantic-structure fusion text, which includes judging whether the semantics of the parameters in the semantic-structure fusion text are consistent with the specification verification rule library according to the semantic similarity threshold preset according to the current scene and the semantic mapping table in the specification verification rule library, the semantic mapping table contains scene-based near-synonymous mapping relationship, and the inconsistent parameter semantics is corrected; Performing structure verification on the semantic-structure fusion text, which includes checking the structure integrity and correctness of the semantic-structure fusion text according to the specification verification rule library. If the structure verification finds that the semantic-structure fusion text does not comply with the prompt format, the automatic correction is performed according to the specification verification rule library first. If the automatic correction cannot meet the format requirement, a preset format repair template is triggered for supplementary correction. If the structure verification encounters a new situation that is not covered by the preset rule, a rollback mechanism is triggered to feed back the semantic-structure fusion text to the large language model for re-generation, and the new situation is recorded synchronously to update the preset rule, and the incomplete or incorrect structure is corrected; Generating execution ready instructions from the semantic-structure fusion text after semantic verification and structure verification; S4, dynamically iterating the scenario execution specification, comprising: Sensing the changes of the execution environment and the execution component, and statistically analyzing the frequency of the sensed changes. Only when the frequency of the changes reaches a preset threshold, the subsequent analysis step is entered; Analyzing the changes and judging whether the scenario execution specification needs to be updated. The scenario execution specification is updated according to the preset quantitative index, which includes the change frequency, the number of affected components and the user demand coverage rate. If there is a specification conflict in the multi-scene collaboration, the conflict is resolved according to the scene priority and the component dependency relationship; According to the judgment result, the scenario execution specification is automatically updated.

2. The method of claim 1, wherein the method further comprises: The constraint information of the execution component under the preset scene is received in S1, and integrity check is performed on the constraint information; for the multi-component collaborative work scene, additional inter-component collaborative constraint information is captured, specifically including: Supporting the developer to enter the key constraint information of the execution component under the scene, the key constraint information including parameter naming rules, data type requirements, execution order priority identification, and condition branch trigger threshold format, calling the execution component interface to obtain hidden parameter information, and supplementing to the constraint information; performing integrity check on the entered key constraint information and the supplemented hidden parameter information; for the multi-component collaborative work scene, capturing the inter-component execution order dependency and parameter passing rule collaborative constraint information.

3. The method of claim 1, wherein the method further comprises: In S1, the constraint information is converted into structured prompt language understandable by the large language model, and a specification verification rule library that can be parsed by the execution component is generated, specifically including: The constraint information is automatically converted into structured prompt language understandable by the large language model; Generating a specification verification rule library containing a semantic mapping table and structure verification logic.

4. The method of claim 1, wherein the method further comprises: In S2, the environment input is received, and the structured prompt corresponding to the environment input is obtained, specifically including: The agent receives the environment input, which includes user instructions and scene state data; According to the environment input, the scene identifier is dynamically matched, and the structured prompt corresponding to the scene identifier is called.

5. The method of claim 1, wherein the method further comprises: In S2, the large language model generates semantic-structure fusion text according to the fusion input, and the semantic-structure fusion text contains task sequence, parameter, condition judgment, and priority information embedded according to the structured prompt, specifically including: The large language model embeds the task sequence, parameter, condition judgment, and priority information in the semantic-structure fusion text in the form of key-value pair or label wrapping according to the structure requirements in the structured prompt.

6. The method of claim 1, wherein the method further comprises: In S3, the semantic-structure fusion text is subjected to semantic verification, which includes judging whether the semantics of the parameters in the semantic-structure fusion text are consistent with the specification verification rule library according to the semantic similarity threshold preset for the current scene and the semantic mapping table in the specification verification rule library, which contains scene-based near-synonymous mapping relationships, and correcting the inconsistent parameter semantics, specifically including: Through semantic similarity calculation, it is judged whether the semantics of the parameters in the semantic-structure fusion text are consistent with the specification in the semantic mapping table; If not, the inconsistent parameter semantics is corrected to the parameter semantics in the specification.

7. The method of claim 1, wherein the method further comprises: In S3, the semantic-structure fusion text is subjected to structure verification, which includes checking the structural integrity and correctness of the semantic-structure fusion text according to the specification verification rule library, and correcting the incomplete or incorrect structure, specifically including: Performing data type verification on the semantic-structure fusion text; Performing priority encoding verification on the semantic-structure fusion text; Performing condition branch verification on the semantic-structure fusion text.

8. The method of claim 7, wherein the method further comprises: The data type verification on the semantic-structure fusion text specifically includes: Identifying non-numeric type parameters in the semantic-structure fusion text; Correcting the non-numeric type parameters to numeric type parameters.

9. The method of claim 7, wherein the method further comprises: The priority coding verification on the semantic-structure fusion text specifically comprises the following steps. If the semantic-structure fusion text is not marked with the execution priority, the default priority rule in the scene specification is used to supplement the execution priority.

10. The method of claim 1, wherein the method further comprises: The dynamic iteration scene specification in S4 specifically comprises the following steps. At least one of the interface listening and the log analysis is used to capture at least one of the interface update of the execution component and the change of the environmental input feature in real time, and the frequency of the captured change is counted. Only when the frequency reaches a preset threshold, the subsequent step is entered. The captured change is classified, and it is determined whether the scene specification needs to be updated. Whether the scene specification needs to be updated is determined according to a preset quantitative index. The quantitative index includes the change frequency, the number of affected components, and the user demand coverage rate. If there is a specification conflict in the multi-scene cooperation, the conflict is resolved according to the scene priority and the component dependency relationship. If the update is needed, the specification update suggestion is generated based on the change content, and the structured prompt of the scene and the specification verification rule library are updated.

Images