Blueprint-driven agent generation method and apparatus, device, medium, and product

Abstract

This application discloses a blueprint-driven agent generation method, apparatus, device, medium, and product. The method includes: acquiring user input or intent information from an intent template; generating a dual-view blueprint consisting of a visual flowchart and a structured specification document, with the visual flowchart and structured specification document synchronized bidirectionally in real time; parsing the dual-view blueprint to obtain the node intents of each node; matching and binding capability units to each node intent to obtain a set of deterministic node intermediate representations; and generating an agent workflow based on the set of deterministic node intermediate representations, comprising a dual-form deliverable of an application chain graph and executable code. This solution, by capturing intents and generating a dual-view blueprint, drives the generation of an agent workflow using the dual-view blueprint and combines it with reusable capability units. While visualizing the agent generation, it effectively eliminates the semantic gap between business intents and code implementation, improving the reliability of the generated agent.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a blueprint-driven intelligent agent generation method, apparatus, device, medium and product. Background Technology

[0002] With the rapid maturation of Large Language Model (LLM) technology, intelligent agents, characterized by "autonomous planning, tool invocation, and multi-step execution," are increasingly widely used in scenarios such as long document understanding, multi-round task collaboration, and enterprise process automation. For AI agent development, there is a type of deterministic LLM workflow framework based on the "BlueprintFirst" principle. Its core idea is to pre-define the agent's execution logic as a source code blueprint written in programming languages ​​such as Python and Node.js. A deterministic engine executes this code blueprint, and the LLM is only invoked at specific nodes in the blueprint to handle complex subtasks (such as parsing logs and generating summaries), without participating in workflow path decisions. This framework has high reliability in rule-intensive scenarios (such as enterprise software troubleshooting), but it still has the following limitations: There is a semantic gap between business intent and code implementation: blueprint creation relies entirely on developers manually writing source code, lacking a structured intent capture mechanism; LLM generation is probabilistic and uncertain; business experts cannot directly participate in the design process; and requirements are inevitably distorted during transmission. The development and operation process is opaque and uncontrollable: Existing platforms generally adopt the "input requirements → black box generation → output results" model. The decision-making path, tool calling logic, and state transition process of the intelligent agent are not visible to developers and business personnel, which constitutes a compliance obstacle and makes it extremely difficult to troubleshoot and iteratively optimize. Summary of the Invention

[0003] This application provides a blueprint-driven agent generation method, apparatus, device, medium, and product to accurately capture intent, eliminate the semantic gap between business intent and code implementation, and visualize agent generation.

[0004] In a first aspect, embodiments of this application provide a blueprint-driven intelligent agent generation method, comprising: Acquire intent information, which is either input by the user or derived from an intent template converted from an external case. Based on the intent information, a dual-view blueprint consisting of a visual flowchart and a structured specification document is generated; wherein, the visual flowchart and the structured specification document are synchronized in real time through a node identifier association table; The node intent of each node is obtained by parsing the dual-view blueprint; The intent of each node is matched and bound to a capability unit from the capability unit knowledge base, and a set of deterministic node intermediate representations is obtained. Based on the set of intermediate representations of the deterministic nodes, an agent workflow for execution on the large language model operation and maintenance platform is generated. The agent workflow contains a dual-form deliverable of an application chain graph and executable code.

[0005] Secondly, embodiments of this application also provide a blueprint-driven intelligent agent generation device, comprising: The intent acquisition module is used to acquire intent information, which is either input by the user or comes from an intent template converted from an external case. The blueprint generation module is used to generate a dual-view blueprint consisting of a visual flowchart and a structured specification document based on the intent information; wherein the visual flowchart and the structured specification document are synchronized in real time through a node identifier association table. The intent parsing module is used to parse the dual-view blueprint to obtain the node intent of each node; The matching and binding module is used to match and bind capability units for each node intent from the capability unit knowledge base, and obtain a set of deterministic node intermediate representations; The agent generation module is used to generate an agent workflow for execution on the large language model operation and maintenance platform based on the deterministic node intermediate representation set. The agent workflow includes a dual-form deliverable of an application chain graph and executable code.

[0006] Thirdly, embodiments of this application provide an electronic device, including: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the blueprint-driven agent generation method as described in the first aspect.

[0007] Fourthly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the blueprint-driven agent generation method as described in the first aspect.

[0008] Fifthly, embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the blueprint-driven agent generation method as described in any of the above embodiments.

[0009] This application provides a blueprint-driven agent generation method, apparatus, device, medium, and product. The blueprint-driven agent generation method includes: acquiring intent information, which is either user input or an intent template derived from external cases; generating a dual-view blueprint based on the intent information, consisting of a visual flowchart and a structured specification document; wherein the visual flowchart and the structured specification document are synchronized in real-time through a node identifier association table; parsing the dual-view blueprint to obtain the node intents of each node; matching and binding capability units to the node intents from a capability unit knowledge base, and obtaining a set of deterministic node intermediate representations; and generating an agent workflow for execution on a large language model operation and maintenance platform based on the set of deterministic node intermediate representations, wherein the agent workflow includes a dual-form deliverable of an application chain graph and executable code. This technical solution, by capturing intent and generating a dual-view blueprint, drives the generation of agent workflows using the dual-view blueprint and combines reusable capability units. While visualizing agent generation, it effectively eliminates the semantic gap between business intent and code implementation, improving the reliability of the generated agent. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0011] Figure 1 A flowchart illustrating a blueprint-driven agent generation method provided in this application embodiment; Figure 2 This is a schematic diagram of a blueprint-driven, end-to-end AI agent generation architecture. Figure 3 A schematic diagram of a blueprint-driven intelligent agent generation device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present application are shown in the drawings, not all structures. Moreover, unless otherwise specified, the embodiments and features described in the present application can be combined with each other.

[0013] Before discussing the exemplary embodiments in more detail, it should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the steps as sequential processes, many of these steps can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the steps can be rearranged. The process can be terminated when its operation is complete, but may also have additional steps not included in the figures. The process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0014] It should be noted that the concepts of "first" and "second" mentioned in the embodiments of this application are only used to distinguish different devices, modules, units or other objects, and are not used to limit the order of functions performed by these devices, modules, units or other objects or their interdependencies.

[0015] In the embodiments of this application, "multiple" refers to at least two unless otherwise specified.

[0016] In the embodiments of this application, "A / B" refers to A and / or B when there is no conflict, and can refer to A or B when there is a conflict.

[0017] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0018] In the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the relevant content of the solution.

[0019] In this application embodiment, a computer-implemented full-link AI agent generation method based on blueprint-driven architecture is provided. This method takes blueprint as the origin of trusted design, uses computer program automation as the core means, and covers the entire link from external case collection to automatic compilation of production workflow.

[0020] Figure 1 This document provides a flowchart of a blueprint-driven agent generation method, applicable to the generation of AI agents. Specifically, this blueprint-driven agent generation method can be executed by a blueprint-driven agent generation device, which can be implemented through software and / or hardware and integrated into an electronic device. The electronic device includes, but is not limited to, devices with data processing capabilities such as computers, smartphones, or servers.

[0021] like Figure 1 As shown, the method specifically includes the following steps: S110. Obtain intent information, which is either input by the user or derived from an intent template converted from an external case.

[0022] For example, intent information can be used to describe what kind of agent workflow the user expects or requires to be generated. This includes describing the business scope of the agent workflow, its steps, functions, and processes. Intent information can be directly input by the user, such as using natural language, or it can reuse standardized intent templates abstracted from historical success cases. An intent template can be understood as a reusable agent workflow solution extracted and stored from historical success cases. It can serve as a source of intent information. When a user selects an intent template, the structured fields of that template can serve as intent information driving the generation of subsequent blueprints. This allows users to directly reuse and quickly start building the agent instead of describing the desired agent workflow from scratch.

[0023] S120. Generate a dual-view blueprint consisting of a visual flowchart and a structured specification document based on the intent information; wherein the visual flowchart and the structured specification document are synchronized in real time through a node identifier association table.

[0024] For example, a dual-view blueprint can refer to a dual-view data structure consisting of a visual flowchart (Draft) and a structured specification document (Spec), supporting direct participation of business experts in the design process and automatically transformed into an executable workflow through a compiler. In this embodiment, the dual-view blueprint serves as the unique trusted data contract during agent generation, execution, and auditing. A node identifier association table can be used to describe the association between nodes in the visual flowchart and entries in the structured specification document. The visual flowchart and the structured specification document can be bidirectionally bound and synchronized in real time through the node identifier association table. Based on this, unified trusted source management of the business semantic view and the technical contract view can be achieved, solving the fundamental problem of inconsistency between design documents and actual execution logic in existing methods.

[0025] S130. Analyze the dual-view blueprint to obtain the node intent of each node.

[0026] For example, by parsing the dual-view blueprint, the visualized business annotations can be paired with the structured text specifications based on the relationship between the nodes in the visualized flowchart and the items in the structured specification document, and then the explicit node intent of each node can be extracted.

[0027] For example, the semantic parsing engine's built-in "node-spec association reader" can be used to traverse each node on the Draft canvas and establish associations between each node and entries in the Spec using a node identifier association table. The unique identifier of a node (node_id) can be used to query and read the corresponding structured specification entry record in the Spec document, and the intent of each node can be assembled according to a standardized data structure. The core field representing the node's business intent (business_intent) can be determined by combining the business semantic tags of the Draft node (such as "customer qualification review" marked on the canvas) with the semantic description field (semantic_description) of the Spec entry.

[0028] S140. Match and bind capability units for each node intent from the capability unit knowledge base, and obtain a set of deterministic node intermediate representations.

[0029] For example, a skill can be understood as a reusable, encapsulated unit that can be invoked by an agent and stored in the form of a standardized description document. Specifically, it can include Application Programming Interfaces (APIs), function modules, and / or business process templates. A skill knowledge base is used to store skill units. For each node, a corresponding skill unit can be matched and bound from the skill knowledge base based on its node intent. Typically, each node (or node intent) can match one or more skill units, and each skill unit can match one or more nodes (or node intents). Different nodes (or node intents) match different skill units. For example, node intent A matches and binds skill units a and b, node intent B matches and binds skill unit c, and so on. These node intents constitute the initial set of Node Intermediate Representations (Node IRs). The deterministic set of Node Intermediate Representations can be understood as the deterministic product obtained by transforming the Node IR set from a probabilistic level during the dual-view blueprint compilation process.

[0030] S150. Based on the set of intermediate representations of the deterministic nodes, generate an agent workflow for execution on the Large Language Model Operation and Maintenance Platform (LLMOps), wherein the agent workflow contains a dual-form deliverable of an application chain graph and executable code.

[0031] For example, taking a deterministic set of Integrity Nodes (IRs) as input, two deliverables are generated in parallel: an application chain graph and executable code. For the application chain graph, an application chain graph generator can convert the deterministic IR set and the list of edges in a Directed Acyclic Graph (DAG) into a recognizable standard application chain graph schema. The flowchart drawn on the Draft canvas is essentially a DAG where nodes represent specific business operations (such as API calls, manual review, etc.), and edges represent execution order or conditional branches. For example, business nodes of type BUSINESS_LOGIC are mapped to Tool Nodes in the LLMOps platform, nodes of type CONDITION_BRANCH are mapped to Router Nodes, nodes of type HUMAN_IN_THE_LOOP are mapped to HITL Nodes, engineering nodes are mapped to log or monitoring nodes, edges in the DAG are mapped to data flow connections carrying strong type constraints (determined_output_schema→determined_input_schema), and parallel branches with data dependencies are mapped to the platform's parallel execution primitives, etc.

[0032] Based on this, the high-level business intent (Draft+Spec) in the user design state can be completely compiled into a technical artifact that can be scheduled and executed by the LLMOps platform, realizing the automated and seamless connection from business design to technical implementation.

[0033] In this embodiment, the application of real-time bidirectional synchronization of dual-form deliverables—chain diagrams (visualization) and executable code (code)—enables business and technical teams to collaborate based on the same workflow, eliminating the need for back-and-forth translation between documents and code.

[0034] Optionally, when acquiring intent information, multimodal input (text / hand-drawn / voice / screenshot) is supported, enabling business experts to express their design intent in the most natural way. With the combined effect of multimodal input eliminating semantic gaps and dual-view synchronization ensuring consistency in design execution, the rework cost caused by misunderstanding of requirements can be significantly reduced (the specific reduction depends on the complexity of the business scenario, the team collaboration mode, and the completeness of the specification document). The conversational design rule inspection engine further embeds professional knowledge (industry best practices, compliance requirements) into the design process, rather than relying on post-review.

[0035] Optionally, a unified intent intermediate representation (IR) data structure is defined, including a list of business entities (with entity type, confidence level, and source modality annotation), a list of business actions (with action type, triggering condition, and confidence level), an entity-action relationship graph (directed graph, with edge weights equal to confidence level), and a set of undetermined fields (recording fields that cannot be inferred due to incomplete input modality representation). Original inputs from various modalities, such as text, hand-drawn sketches, voice, and screenshots, are each converted into the aforementioned unified IR by their respective processors. Optionally, different confidence thresholds are used for different modality conversions (e.g., default confidence level of 0.85 for text descriptions, 0.70 for hand-drawn sketch recognition, 0.75 for voice descriptions, and 0.65 for screenshot comprehension). When undetermined or low-confidence fields exist in the unified IR, the system sends supplementary queries to the user instead of silently generating a potentially incorrect draft.

[0036] Optionally, every modification to the dual-view blueprint, every AI decision point (such as Skill matching results, alignment path descriptions, etc.), and every compliance verification result can be fully recorded in a versioned manner, forming an immutable design evolution chain that meets the compliance requirements of heavily regulated industries for the traceability of AI system decisions. This method's end-to-end "process visible, understandable, and controllable" design makes the dual-view blueprint simultaneously a design tool, an execution contract, and an audit credential, solving the problem of inefficient collaboration between business and technical personnel due to cognitive gaps in existing technologies. Automatic conversion of multimodal intents eliminates the dependency on manual blueprint creation; automatic Skill discovery avoids manual interface inventory; and formal verification in the design state moves error discovery from the runtime state to the design state. Based on this, the synergistic effect of these mechanisms can significantly shorten the overall cycle of an Agent project from prototype verification to production deployment.

[0037] This application provides a blueprint-driven agent generation method that captures intent and generates a dual-view blueprint. The dual-view blueprint drives the generation of agent workflows and combines reusable capability units. While visualizing agent generation, it can effectively eliminate the semantic gap between business intent and code implementation, and improve the reliability of the generated agents.

[0038] In one embodiment, the method further includes: S100, a multi-agent collaborative pipeline driven by a distributed state machine, transforms the external case into a parameterized intent template.

[0039] For example, at the intent transformation (IDEA Adapter) layer, a distributed state machine-driven multi-agent collaborative pipeline for AI Agent case lifecycle management can be provided, including a first agent (multi-source case acquisition agent), a second agent (deep understanding agent), a third agent (cross-source semantic normalization agent), and a fourth agent (quality assessment agent).

[0040] Specifically, the multi-agent collaborative pipeline driven by a distributed state machine transforms the external cases into parameterized intent templates, including: S1010, Collect cases from multiple external sources through the first intelligent agent; S1020. Through the second intelligent agent, the large language model is used to extract the structured data from the collected cases in order to obtain analysis records of business objectives, solutions and key component information. S1030. Through a third intelligent agent, the differentiated expressions of cases from different sources are mapped to a unified business semantic space based on the analysis records, common fields of cases from different sources are identified, and new intent templates are generated or merged into existing intent templates based on the common fields. For example, through a third-party intelligent agent, "order tracking" and "logistics tracking" can be unified into an example of "status query", and "status query" can be used as a common field to generate new or update existing intent templates.

[0041] S1040. The new intent template or the existing intent template is scored and screened from three dimensions: feasibility, novelty and completeness, through the fourth intelligent agent.

[0042] For example, scoring thresholds (such as feasibility greater than 60%, novelty (cosine similarity) greater than 0.85, and completeness greater than 80%) are used for filtering. Based on the filtering results, the intent template library is added to the database, retrieved, and personalized recommendations are made (e.g., recommending 3 to 5 templates). During retrieval, a relevant template matching output mechanism based on vector retrieval can be used, enabling users to obtain an agent design starting point based on industry best practices within minutes. Compared to starting from a blank canvas, the feasibility reference level in the design initiation phase is significantly improved (the specific improvement depends on the coverage of the Skill library and the richness of the case library), and the design initiation time is shortened from several hours to minutes. This solves the cold start problem of agent design.

[0043] Furthermore, a case processing state machine is defined, and case records in the system exist in the following states: {RAW (collected and awaiting understanding), ANALYZED (understood and awaiting normalization), NORMALIZED (normalized and awaiting evaluation), ACCEPTED (evaluation passed and stored), REJECTED (evaluation failed and returned), RETRYING (returned and being extracted)}. Four types of dedicated agents—multi-source case collection agent, deep understanding agent, cross-source semantic normalization agent, and quality evaluation agent—can each subscribe to the task queue of their respective states. The state machine transitions drive task picking and flow without the need for a central scheduler. When the quality evaluation fails, the case record's state is simply rolled back to RAW with a failure reason label, triggering a precise local retry instead of a full rerun, significantly reducing the ineffective computational overhead of the case conversion pipeline. Based on this, the differentiated expressions of cases from different sources can be mapped to a unified business semantic space, stripping away the technical implementation noise that is strongly bound to the platform, identifying common patterns among cases and merging them into parameterized intent templates; in addition, the generated intent templates can be automatically scored and filtered from three dimensions: feasibility (skill coverage), novelty (duplicate with existing templates), and completeness (key field checks).

[0044] In one embodiment, obtaining intent information includes: Receive natural language text commands input by the user; The LLM is invoked to determine the classification and parameters of the intent in the natural language text instruction. The classification includes at least one of the following predefined operation types: insert node, delete node, modify node, merge node, add edge, add conditional branch, and update structured specification document field.

[0045] This embodiment allows for conversational interaction with the user. For example, it receives natural language text commands input by the user and calls the LLM to perform intent classification and parameter extraction on the natural language text commands. The intent classification result can be one or more from a predefined set of operation types, which can be: {INSERT_NODE (insert node), DELETE_NODE (delete node), MODIFY_NODE (modify node), MERGE_NODES (merge node), ADD_EDGE (add edge), ADD_BRANCH (add conditional branch), UPDATE_SPEC_FIELD (update Spec field)}. Furthermore, the intent parameters are extracted; for example, for the INSERT_NODE operation, the following parameters need to be extracted: the name of the reference node at the insertion position, the business semantic description of the new node, and the relationship type between the new node and the reference node.

[0046] Based on this, the intent information of user input can be accurately obtained, providing a foundation for the generation of dual-view blueprints and agent workflows.

[0047] In one embodiment, generating a dual-view blueprint consisting of a visual flowchart and a structured specification document based on the intent information includes: S1210. Based on intent information, generate visual flowcharts and structured specification documents; S1220. Real-time two-way synchronization between visual flowcharts and structured specification documents; Specifically, for the first change event of the structured specification document, the corresponding node identifier is obtained by querying the bound registry. Based on the node identifier, the first change event is converted into a visual annotation update instruction for the node in the visual flowchart, so as to update the visual annotation of the node in the visual flowchart. For the second change event in the visual flowchart, the entity identifier of the corresponding structured specification document is obtained by querying the binding registry. Based on the entity identifier and the second change event, a new entry is created in the storage area of ​​the structured specification document and written to the binding registry, or the corresponding entry in the structured specification document is updated according to the change.

[0048] For example, in the Blueprint Studio layer, a real-time two-way binding protocol between Draft and Spec is adopted: defining a real-time two-way synchronization mechanism between Draft (visual flowchart) and Spec (structured specification document) - when the user adds or modifies a node on the Draft canvas, the Spec document automatically updates the corresponding design description; when the user directly modifies the Spec document, the nodes on the Draft canvas automatically update the visual annotations, forming a "text-image interoperability" two-way synchronization protocol, so that the two views together constitute a unique and reliable source.

[0049] Optionally, nodes in Draft do not use technical abstract names (such as "LLM Call Node"), but are forced to be labeled with business domain language (such as "customer qualification review" and "inventory check"). Business entities and actions are extracted through structured intent parsing to form an entity-action relationship graph and convert it into DAG (directed acyclic graph) nodes.

[0050] Optionally, through conversational interaction optimization, the system can perform rule matching checks on the current blueprint state based on a pre-built design rule knowledge base and a domain best practice rule base, output a structured design problem report, and support users to directly drive the synchronous modification of Draft and Spec through natural language text commands.

[0051] In one embodiment, the method further includes: for the current visual flowchart and structured specification document, traversing the design rules in the design rule knowledge base; for each design rule, automatically loading the corresponding rule subset according to the compliance requirement field value in the structured specification document; and checking the current visual flowchart and structured specification document based on the rules; wherein the design rules in the design rule knowledge base are stored in an IF-THEN structure.

[0052] In this embodiment, design rule checks can be performed on the visual flowchart and structured specification document. These checks can be automatically triggered after each DAG change or initiated by the user. Design rules can be stored in an "IF-THEN" structure, where the condition describes the structural characteristics of the DAG, and the action describes the output problem description and remediation suggestions. For each rule, a condition judgment is performed; for rules where the condition is true, the violation node ID and violation description are extracted and assembled into a list of check result records. These check result records can be pushed to the user interface in the form of a structured report, and violation nodes are highlighted on the Draft canvas. The design rule knowledge base is organized by industry sector, and the system automatically loads the corresponding industry's rule subset based on the compliance requirements (compliance_requirements) field value in the specification document.

[0053] Based on this, the reliability and compliance of dual-view blueprints can be further guaranteed by synchronizing Draft and Spec, providing a basis for generating highly reliable intelligent agent workflows and achieving a balance between the determinism of design rule checks and industry adaptability.

[0054] In one embodiment, the method further includes: S1230. For the first change event and / or the second change event that hits the semantic conflict determination rule table, generate and push semantic conflict records.

[0055] The semantic conflict determination rule table is the core component of the semantic conflict detector. Through a predefined and extensible rule set, it can automatically identify business logic contradictions caused by design changes (such as adding, deleting, or modifying nodes).

[0056] Specifically, the semantic conflict determination rule table includes at least one of the following determination rules: If a node deletion event occurs in the visual flowchart and the constraint (preconditions / postconditions) field of the corresponding entry in the structured specification document is not empty, it means that the node carrying the incomplete constraint has been deleted, which is a constraint isolation conflict. The visual flowchart shows a node merging event, and the constraint fields of the merged nodes have semantically mutually exclusive descriptions, such as "locked" and "modifiable" being mutually exclusive, which is a postcondition mutual exclusion conflict. When a constraint is added to the structured specification document, and the added constraint contradicts the topology of the current visual flowchart, i.e., the specification adds a sequence constraint (such as "node A must be executed after node X"), but there is no corresponding path in the current DAG topology, it is a DAG structure contradiction conflict.

[0057] Based on this, the consistency issues between design documents and execution logic can be checked at the design stage instead of at runtime, reducing the cost of later fixes. In one embodiment, obtaining a deterministic node intermediate representation set includes: determining the execution type, execution conditions, and bound resources for each node intent sequentially based on the capability units bound to each node intent, in order to form the deterministic node intermediate representation set.

[0058] For example, the following three materialization operations are performed on the Node IR set: Type Determinism: Define ambiguous parameter type descriptions (such as "customer rating") in the Node IR set as specific strong type definitions (such as integer type with a value range of 0-1000). Condition specification: Transform natural language-described branch conditions (such as "the customer is a high-risk customer") into executable Boolean expressions (such as customer.risk_level == 'HIGH').

[0059] Resource binding specification: Clearly define the specific capability units that nodes are bound to.

[0060] Building upon this foundation, a vague graph (the drawn diagram) can be transformed into deterministic nodes (IRs) containing defined types, logic, and calling relationships. This eliminates the ambiguity and uncertainty that may arise when generating code directly from natural language or visual sketches, providing a basis for subsequent generation of executable intelligent agent workflows. The entire generation process becomes an interpretable, auditable, and verifiable directed transformation chain. When compilation or execution errors occur, the system can precisely trace back to the intent definition or resource binding stage of a specific node, greatly improving the engineering controllability of the intelligent agent generation system.

[0061] In one embodiment, matching and binding capability units for each node intent from the capability unit knowledge base includes: for each node intent: 1) Extract the keyword set of the node intent, and use inverted index and term frequency-inverse document frequency (TF-IDF) to recall the first number of candidate capability units from the capability unit knowledge base; for example, 50-100 preliminary candidate skills can be recalled. 2) Encode the node intent and the metadata of each candidate capability unit into a semantic vector, and reorder each candidate capability unit by calculating the cosine similarity between each candidate capability unit and the node intent; 3) Based on the re-ranking results, the top two number (Top-K) of candidate capability units are input into the pre-built knowledge graph. For example, based on semantic similarity (weight 0.7) and historical feedback scores (weight 0.3), the Top-K candidate Skills are selected to ensure compatibility with input and output types, business logic continuity and resource dependency consistency with upstream and downstream nodes, and to exclude candidate capability units that fail the verification. 4) Generate interpretable aligned output, which includes the following fields: Matching path: This describes the selection path and reasons for elimination for each candidate capability unit; Confidence interval: used to describe the matching confidence level and error range of the final bound capability unit; Counterexample illustration: Used to illustrate the counterexample constraint rules triggered in the knowledge graph; Multiple candidate comparison: Metadata used to compare the second number of candidate capability units.

[0062] Based on this, the interpretable Skill alignment method, while achieving precise matching (target accuracy greater than 90%), provides interpretable outputs such as matching path display, confidence interval annotation, and counterexample explanations, enabling users to understand and trust Skill matching decisions.

[0063] In one embodiment, the method further includes: S160. Continuously collect call data during operation through real-time APIs deployed in API gateways or service meshes; S170. Determine API candidates and capability unit candidates based on the call data; S180. Based on the candidate capability units and the candidate capability units, encapsulate new capability units and update the new capability units to the capability unit knowledge base.

[0064] For example, a continuous automatic skill discovery solution is adopted. By deploying lightweight probes on the enterprise API gateway / service mesh, API and skill candidates are continuously extracted from actual operation, thereby accumulating new skills into the database. This transforms the existing platform's model, which relies entirely on manual inventory of enterprise interfaces, into an automated knowledge accumulation driven by the operation process. This significantly reduces the proportion of enterprise IT integration costs in the total development cost. For instance, in an enterprise IT environment with a typical scale of 50 to 200 API interfaces, and with the skill discovery engine having been running stably for 30 days and accumulating sufficient call data, the workload of manual interface inventory during the integration phase can be reduced by more than 70%. The specific reduction depends on the completeness of the enterprise API interface documentation, the distribution of call frequency, and the degree of standardization of business semantics.

[0065] In one embodiment, the method further includes: S170. Perform at least one of the following checks on the dual-view blueprint: Type compliance verification is used to check the type consistency of data streams across nodes. Process compliance verification is used to detect path reachability, deadlock, and concurrency safety issues in the directed acyclic graph corresponding to the visualized flowchart; Business rule verification is used to check whether the dual-view blueprint meets predefined business integrity, sequence constraints and regulatory compliance requirements based on a pre-set compliance rule base. Performance constraint verification is used to estimate whether the end-to-end response time of the agent workflow meets the service level agreement based on the performance benchmark of the bound capability units.

[0066] For example, during the Draft to Workflow transformation phase, systematic verification is performed sequentially across four dimensions: type compliance, process compliance, business rule compliance, and performance constraint compliance. Business constraints can be overlaid on top of basic data types to define domain-specific types, and three constraint layers—preconditions, postconditions, and invariants—can be introduced to form the formalized foundational language for Spec-follow verification.

[0067] Building upon this foundation, through systematic design-state verification across four dimensions—type, process, business rules, and performance constraints—AI Agent error detection can be shifted from "post-runtime troubleshooting" to "proactive interception at design time." In heavily regulated industries (finance, healthcare, government), for compliance requirements that can be structured as type constraints, sequence constraints, and invariants, the design-state verification engine can automate full-scale testing of the constraint types covered by the rule base. This transforms the traditional compliance verification model, which relies on manual review, into a deterministic rule matching model, enabling the system to provide mathematical-level correctness guarantees for complex business constraints, rather than relying on test case coverage. This significantly reduces the abnormal behavior rate of agents in the production environment.

[0068] In one embodiment, the method further includes; S1810. Translate the operation semantics of the nodes in the intelligent agent workflow into SMT formulas to obtain an SMT formula set. S1820. Verify the satisfiability of the formulas in the SMT formula set using the Z3 SMT solver; S1830. If the satisfiability of the SMT formula set is satisfiable, then all invariants under all execution paths in the agent workflow are valid, and the satisfiability verification is passed. S1840. If the satisfiability of the formula set is unsatisfiable, then the agent workflow fails the satisfiability verification and returns a counterexample assignment that invalidates the invariant.

[0069] In this embodiment, by translating the operational semantics of the agent's workflow nodes into SMT formulas, the invariant maintenance proof and counterexample generation method based on the Z3SMT solver can be used. For complex constraints, the Z3SMT solver automatically proves the preservation of business invariants across all possible execution paths. When constraints cannot be satisfied, a minimum counterexample is automatically generated, accurately identifying the nodes violating the constraints and the input conditions, and recommending the minimum modification scheme that satisfies all constraints. Based on this, a comprehensive verification and modification mechanism is provided to improve the reliability of the agent's workload.

[0070] The method in this application embodiment uses a computer program to automate the natural language input of business experts through multi-modal intent unified intermediate representation transformation, blueprint compilation, formal compliance verification, and other multi-stage computer processes, generating an intelligent agent workflow that can be deployed in a production environment. This makes the entire intelligent agent generation process visible, understandable, and controllable. By automatically transforming multimodal intents, it eliminates the dependency of manual blueprint creation, performs formal verification during compilation, and automatically discovers and accumulates skills during runtime. This is a full-link systematic engineering solution that automates from the design origin to the front end of compliance verification. It not only solves the problems of semantic gap between business intent and code implementation and opaque development and operation processes, but also solves the problems of existing development frameworks lacking the ability to automatically discover and continuously accumulate capabilities (Skills) in enterprise IT environments, requiring all tool interfaces to be manually mounted by developers, failing to automatically identify which interfaces or data in the existing enterprise system can be used by intelligent agents, lacking compliance verification mechanisms, and only investigating after execution errors occur.

[0071] Figure 2 This is a schematic diagram of a blueprint-driven, end-to-end AI agent generation architecture. (For example...) Figure 2 As shown, this architecture is a five-layer decoupled pipeline architecture: Layer 1: IDEA Adapter layer, corresponding to Phase 1: Automatic conversion of open source projects and industry cases (Case→Idea); Layer 2: Blueprint Studio layer, corresponding to Phase 2: Multimodal intent visualization and dual-view synchronization (Idea→Draft+Spec); Layer 3: Blueprint Compiler layer, corresponding to Phase 3: Blueprint compilation and agent generation (Draft+Spec→Workflow). Layer 4: LLMOps integration layer, responsible for model routing and skill storage, etc. Layer 5: Enterprise Deployment and Ecosystem Binding Layer, corresponding to Phase 4: Skill Auto-Discovery and Explainable Alignment; Phase 4 runs in parallel with Phase 3 as a continuously running background service, continuously providing candidate skills for the Skill binding steps in Phase 3.

[0072] In addition, Phase 5: Spec-follow formal compliance verification can be embedded at the end of Phase 3 as a quality gate before Workflow generation.

[0073] The AgentRuntime Engine, as the core execution layer in the AI ​​Agent architecture, is responsible for driving the agent's lifecycle management, state persistence, task planning, tool scheduling, and context optimization.

[0074] In one example, the automatic case conversion process includes: Step 101: Automatic collection of multi-source cases and initialization of state machine.

[0075] The multi-source case collection agent collects cases from multiple external content streams (GitHub Trending, HuggingFace Papers, ArXiv, Product Hunt, industry reports, enterprise technical blogs, etc.). For example, it continuously sends crawl requests to the above-mentioned multiple sources in a polling manner, writing the original content into the crawl buffer; it performs rule matching on the original content according to a pre-defined set of validity judgment rules (rule example: "the business goal description field and the technical implementation field appear simultaneously in the text"); content that matches is written to the processing queue (output), and content that does not match is written to the discard log; it extracts the content hash value (based on the joint hash of the original URL and the summary text) for each piece of content, and compares it with the set of hash values ​​already recorded in the case status database; if the hash value already exists, it skips it; if the hash value does not exist, it passes the verification and outputs a "new case" identifier.

[0076] The case status manager can receive new case content that has passed deduplication verification and create a case processing record for each piece of content. The record structure can be defined as {case_id (unique identifier), content_hash (content hash), source_type (source type), raw_url (original link), content_summary (content summary), status (current status, initialized to RAW), retry_count (number of retries, initialized to 0), failure_reason (failure reason, initially empty), last_agent_id (last processed Agent identifier), created_at (creation timestamp)}. The case processing record is written to the case status database, and the case_id is pushed into the RAW status queue for consumption by the deep understanding Agent in step 102.

[0077] The case state manager maintains a distributed state machine for the case lifecycle. The state transition path is RAW → ANALYZED → NORMALIZED → ACCEPTED (final state) or REJECTED → RAW (partial retry). When the quality assessment fails, the case state manager only writes the status field of the record back to RAW, writes the failure reason to the failure_reason field, increments the retry_count field by 1, and pushes it back into the RAW state queue. This mechanism achieves precise partial retries rather than full reruns, avoiding the duplicate calculation of other successfully processed cases.

[0078] Based on this, through a state machine-driven decentralized collaboration architecture, each Agent independently subscribes to / consumes queues, eliminating the single point of failure of the central scheduler; the local retry mechanism decouples the failure of a single case from the overall pipeline, enabling the pipeline to have adaptive robustness when facing noisy data.

[0079] Step 102: In-depth understanding and structured extraction of the case.

[0080] The deep understanding agent can receive raw case text content, call LLM to perform structured information extraction on project documents, README, and code comments, and assemble the extraction results into structured records according to the case analysis record schema. By uniformly extracting unstructured open source cases and industry reports into structured records with clear field schemas, a data foundation is laid for subsequent cross-source normalization; the function-semantic vector mapping of the code repository enables step 103 to perform cross-programming language capability analogy, breaking through the limitation of relying solely on natural language descriptions for normalization.

[0081] Step 103: Cross-source semantic normalization and Idea template generation. This can be performed by the cross-source semantic normalization agent.

[0082] Based on the "Business Action List" field in the case analysis record, for each business action description, calculate its semantic similarity with the prototype descriptions of each category (by calling the deployed semantic vector service). Take the category with the highest similarity that exceeds the threshold θ_class (default 0.65) as the normalization result (action category label). If no category exceeds the threshold, the action is written to the manual review queue. Based on the normalized action category labels of all cases in the current batch and the feature vectors of existing templates in the Idea template library, group the cases in the current batch according to action category combinations. When the number of cases in a group exceeds the threshold (e.g., default 3), extract the common fields of the group (e.g., take the intersection or weighted mode of the corresponding fields of each case) to generate candidate merged templates. If the similarity between the candidate merged template and the feature vectors in the existing Idea template library exceeds 0.85, merge it with the execution field of the most similar existing template (take the union of fields, use a new case coverage strategy for conflicting fields and retain historical values ​​in the version record); if the similarity is less than 0.85, generate a new template candidate.

[0083] Assemble template records according to the Idea template standard schema. The schema fields can be defined as {template_id (unique identifier), business_scene_name (business scene name), applicable_industries (list of applicable industries), complexity_level (complexity level), source_case_ids (list of source case IDs), business_goal_description (business goal description), core_workflow_patterns (list of core workflow patterns), required_skills (list of required key skills), reusability_score (reusability score, floating-point number), customization_hints (customization suggestion text), and feature_vector (template feature vector, used for subsequent similarity retrieval)}. After assembly, the template records are written to the Idea template candidate library. At the same time, the case status manager is called to update the status field of the corresponding case_id to NORMALIZED and push the case_id into the NORMALIZED status queue.

[0084] By using hierarchical classification graph-driven semantic normalization and platform-specific vocabulary stripping, cases from different platforms, technology stacks, and natural language expressions are uniformly mapped to a platform-independent business capability space, eliminating the heterogeneity of cross-source case expressions. The common pattern identification and merging mechanism further precipitates parameterizable idea templates, enabling each template to cover a type of scenario rather than a specific case, significantly improving the reusability of the templates.

[0085] Step 104: Multi-dimensional quality assessment and database entry of the Idea template. This can be performed by a quality assessment agent.

[0086] Feasibility Verification: Based on the required_skills field (list of required key capabilities) in the template candidate record, query the Skill registry of the LLMOps platform and check whether each required capability in the list has a corresponding implementation in the platform's registered Skills; calculate the coverage rate by dividing the number of corresponding capabilities already implemented on the platform by the total number of required capabilities; output the feasibility score (coverage rate value) and the list of uncovered capabilities; when the coverage rate is lower than the threshold (default 60%), the list of uncovered capabilities is also written into the Skill Gap Record for platform operation reference.

[0087] Novelty check: Based on the feature_vector field (template feature vector) in the template candidate record, initiate a nearest neighbor search request to the vector index of the Idea template library to obtain the top 5 existing templates with the highest similarity and their similarity values; if the highest similarity value exceeds the threshold (such as the default 0.85), it is determined to be a duplicate template; at this time, the "duplicate" identifier and the template_id of the most similar template are output.

[0088] Completeness verification: Based on all fields of the candidate records in the template, check each field against the pre-defined list of required fields (business_scene_name, business_goal_description, core_workflow_patterns, and required_skills are required fields) to ensure that they are not empty and conform to the format specifications; calculate the completeness rate as the number of required fields that pass the check divided by the total number of required fields; output the completeness score and a list of fields that are missing or have non-compliant formats.

[0089] If the completeness rate is lower than the threshold (default 80%), it is judged as "incomplete extraction". The case status manager is called to write the status back to RAW, write failure_reason to the missing field list, increment retry_count by 1, and push case_id back into the RAW queue (triggering step 102 to perform supplementary extraction for missing fields).

[0090] If the novelty check outputs a "duplicate" flag, then the fields of the current template candidate are merged with the fields of the most similar existing template (the union of source_case_ids and the weighted average of reusability_score are taken), the existing template record is updated, the case status manager is called to update the status to ACCEPTED, and no new template record is added.

[0091] If the feasibility score is below the threshold (default 60%) but the other validations pass, the template will be written to the Idea template library with the "low feasibility" label and its display priority will be reduced during recommendation. If all three validations pass and the feasibility meets the standard, the template will be written to the Idea template library and the case status manager will be called to update the status to ACCEPTED.

[0092] Template retrieval service (user-facing query interface): Receives user-inputted business requirement description text, calls the text vectorization service to convert the description text into vectors, initiates a nearest neighbor search against the vector index of the Idea template library, and returns the top 3 to 5 Idea template records with the highest semantic similarity. For each returned template record, it calculates the field-level differences between the record and the user input (field-by-field comparison, outputting a list of differing fields and a description of the differences), and returns this information, along with the `customization_hints` field, to the user interface. Users can choose to adopt, partially refer to, or ignore the information.

[0093] The division of labor between the three-dimensional parallel verification and the data entry decision controller enables the quality assessment process to simultaneously control three dimensions: "extraction quality" (completeness), "knowledge base redundancy" (novelty), and "platform implementation feasibility" (feasibility). The strategy of merging duplicate templates instead of discarding them allows multiple source cases of the same business scenario to corroborate each other and enrich the template content, rather than simply deduplicating them and causing information loss.

[0094] In the multimodal intent visualization and dual-view synchronization phase, the abstract ideas input by the user (which may come from the idea template in phase one or be a natural language description directly input by the user) are transformed into concrete and operable draft sketches and structured specification documents through multimodal input processing, structured intent parsing, automatic generation of draft sketches, synchronous generation of specification documents, and conversational interaction optimization. The two are bound together in real time to form a unique and credible Blueprint design origin.

[0095] For example, the multimodal intent visualization and dual-view synchronization process includes: Step 201: Multimodal intent input, unified intermediate representation conversion and structured parsing.

[0096] The system receives natural language text input, calls the dependency parsing service to perform syntactic parsing on the text, and extracts the subject-verb-object structure from the parsing results: the subject is mapped to business entity candidates, the predicate verb is mapped to business action candidates, and the object is mapped to an entity or data object; for each entity candidate, string similarity matching is performed with a pre-set entity type dictionary (a representative vocabulary set of personnel role class, data object class, and external system class) to determine the entity type classification; the source modality (TEXT) and default confidence (0.85) are labeled for each extracted entity and action record; the output is: the original entity record list and the original action record list.

[0097] Receive hand-drawn flowchart image files uploaded by users, call the graphic element recognition service (graphic recognition of rectangular nodes, arrow lines, and text annotations), and convert the recognition results into node-edge structure descriptions: text annotations in rectangular nodes are mapped to business action candidates, and arrow directions are mapped to the sequential dependencies between actions; label each record with the source modality (SKETCH) and default confidence (0.70); output: original node record list and original edge record list.

[0098] The system receives user voice input, calls the ASR service to convert speech to text, and the ASR service outputs the confidence score of each word segment. Word segments with a confidence score below 0.8 are marked with an uncertainty marker in the transcribed text. The transcribed text enters the text description adaptation submodule for processing. The source modality is labeled as VOICE with a default confidence score of 0.75.

[0099] The system receives screenshots of existing system interfaces uploaded by users, calls the Visual Language Model (VLM) to perform interface element recognition and operation process analysis on the screenshots, and outputs natural language description text of the interface operation steps; this text enters the text description adaptation submodule processing flow; the source modality is labeled as SCREENSHOT, and the default confidence level is 0.65.

[0100] The Intent IR builder assembles the original entity record list, action record list, and edge record list output by the aforementioned adaptation sub-modules according to a unified multimodal intent intermediate representation schema. The schema is defined as {entity_list (a list of business entities, each containing entity_name, entity_type, confidence, and source_modality), action_list (a list of business actions, each containing action_type, trigger_condition, confidence, and source_modality), relation_graph (a directed graph of entity-action relationships, with confidence weights on the edges), and undetermined_fields (a set of undetermined fields, recording the names of fields that could not be inferred due to incomplete input and the reasons for inference failure)}. After assembly, the multimodal intent intermediate representation data structure is output.

[0101] For example, using the IR confidence checker, based on the multimodal intent intermediate representation, the confidence field of all records in entity_list and action_list, as well as the undetermined_fields set, are traversed. If there is a record with a confidence score lower than 0.6 or the undetermined_fields set is not empty, the name of the corresponding field and the reason for the inference failure are extracted, a supplementary query request is generated, and displayed to the user through the user interface (e.g., "Unable to identify the operation trigger condition, please provide further explanation"). After the user replies with text, the text description adaptation submodule processes the reply and updates the extracted results to the confidence field of the corresponding record until all fields have a confidence score of 0.6 or higher, and outputs the multimodal intent intermediate representation with completed confidence check.

[0102] For example, the following processing is performed on the received multimodal intent intermediate representation after confidence checking: ① The entity and action nodes in the relation_graph are converted into nodes and directed edges of the DAG; ② A business semantic label is generated for each node from the action_type field (using domain terminology such as "customer qualification review" instead of technical abstract labels such as "LLMCall Node"), and the mapping relationship between business semantic labels and technical abstract labels is stored in a maintainable label mapping table; ③ The DAG structure is checked according to a pre-set set of engineering best practices rules, and corresponding engineering nodes are automatically inserted into the DAG for nodes lacking exception handling exits and external call nodes lacking timeout control; ④ For actions marked as condition judgment types in action_list, corresponding conditional branch edges are generated in the DAG, and the branch conditions are written in the condition_desc field of the edge in the form of probabilistic description (such as "go this branch when customer.type is a high-risk type"), and converted into executable Boolean expressions in step 303 type determinization stage; the initial draft in DAG format is output.

[0103] By defining a unified multimodal intent intermediate representation data structure and corresponding adaptation submodules for each of the four modalities, heterogeneous multimodal inputs are reduced to intermediate representations with a consistent schema, so that the subsequent draft generation engine does not need to be aware of the differences in input modalities. The introduction of the IR confidence checker enables the system to actively detect and complete incomplete intent expressions before generating drafts, rather than silently generating potentially erroneous sketches. The business semantic tagging mechanism decouples technical implementation details from business meanings, providing a design language that is readable by both business and technical personnel.

[0104] Step 202: Real-time bidirectional binding synchronization of Draft-Spec. This step is divided into two sub-phases: the initialization phase (generating the Spec for the first time and establishing the binding) and the continuous synchronization phase (responding to subsequent bidirectional changes).

[0105] During the initialization phase, the Spec document initial generator receives the initial draft diagram, traverses the node list of the DAG, and generates a corresponding Spec entry for each node. The entry schema is defined as {Spec_entry_id (unique identifier of the Spec entry), bound_node_id (ID of the bound Draft node), semantic_description (semantic description of the node, automatically generated from the node's business semantic tags), input_schema_description (probability-level description of the input data type, from the corresponding record in IR), output_schema_description (probability-level description of the output data type), preconditions (list of preconditions, initially empty), postconditions (list of postconditions, initially empty), and invariants (list of invariants, initially empty)}. Simultaneously, Spec document-level fields (business_goal, user_stories, success_metrics, constraints, performance_sla, compliance_requirements, budget_limit, acceptance_criteria) are generated, and the system automatically fills in the initial draft based on the content of the intermediate representation of multimodal intents. The Spec document is then written to the Spec storage area.

[0106] During the initialization phase, a binding record is created for each pair (node_id, Spec_entry_id) and written to the binding registry based on the Draft node list and Spec entry list. The binding registry supports bidirectional queries: entering node_id will query the corresponding Spec_entry_id, and entering Spec_entry_id will query the corresponding node_id.

[0107] During the continuous synchronization phase, the event bus receives all change operations from the Draft canvas engine and the Spec editor. Each change operation is encapsulated as a change event record, with the record schema being {event_id, event_source (DRAFT or SPEC), event_type (ADD_NODE, MODIFY_NODE, DELETE_NODE, ADD_EDGE, MODIFY_SPEC_FIELD, etc.), target_id (node_id or Spec_entry_id of the change target), old_value (value before change), new_value (value after change), timestamp (change timestamp)}. The change event record is written to the event queue and simultaneously routed to the Draft-side synchronization processor and the Spec-side synchronization processor (routed separately according to event_source).

[0108] Draft-side synchronization processor: Receives change events with event_source=SPEC, queries the bound registry to obtain the corresponding node_id, converts the field changes of the Spec (such as semantic description modification, constraint addition) into visual annotation update instructions for Draft nodes (such as node label text update, constraint label display), and sends them to the visualization canvas engine to execute rendering updates (output).

[0109] Spec-side synchronization processor: Receives change events with event_source=DRAFT, queries the binding registry to obtain the corresponding Spec_entry_id; for ADD_NODE events, creates a new Spec entry in the Spec storage area and writes it to the binding registry; for MODIFY_NODE events, updates the semantic_description field of the corresponding Spec entry; for DELETE_NODE events, marks the corresponding Spec entry as "pending" instead of deleting it directly, and enters the semantic conflict detector for processing (output).

[0110] Semantic Conflict Detector: Receives change events pushed by the change event bus, maintains the following semantic conflict judgment rule table (the rule table is expandable), matches the current event rule by rule, generates semantic conflict records for events that match the rules, and pushes them to the conflict confirmation queue (output) in the user interface; concurrent write conflicts are handled by the underlying storage's optimistic locking mechanism; all change events are written to the version history, supporting rollback to any historical version. The current rule table contains the following three types of judgment rules: Rule 1 (Node Deletion - Constraint Isolation Conflict): Triggering condition: The Draft side sends a DELETE_NODE event, and the preconditions, postconditions, or invariants fields of the corresponding Spec entry are not empty (i.e., the deleted node carries an incomplete constraint description, and the related constraints will lose their anchor after deletion); Judgment conclusion: Semantic conflict; Prompt content: Display all incomplete constraint entries of the node and ask the user to choose from the following three processing methods: ① Discard all constraints and confirm the deletion of the node; ② Retain the constraints and restore the Draft node; ③ Migrate the constraints to the adjacent node specified by the user.

[0111] Rule 2 (Node Merging - Mutually Exclusive Postcondition Conflict): Triggering Condition: The Draft side sends a MERGE_NODES event (merging node A and node B into node C), and the postconditions fields of node A and node B each contain semantically mutually exclusive descriptions (by calculating the semantic similarity of the two postconditions texts, if the similarity is below a threshold and both contain opposing semantic patterns such as "locked / unmodifiable" and "modifiable / awaiting update", then they are determined to be mutually exclusive); Judgment Conclusion: Semantic conflict (the merged node C simultaneously carries semantically mutually exclusive postconditions); Prompt: Display the mutually exclusive postconditions fields and require the user to manually decide which one to keep, or modify it to a compatible description before the merge can be executed.

[0112] Rule 3 (Spec Constraint - DAG Structure Conflict): Triggering condition: The Spec side sends an UPDATE_SPEC_FIELD event, modifying the preconditions field of a node and adding a sequence constraint that "this node must be executed after node X". However, there is no directed path between this node and node X in the current DAG (i.e., the sequence constraint added by the Spec contradicts the current DAG topology); Judgment conclusion: Semantic conflict (the Spec constraint is inconsistent with the Draft topology); Prompt: Highlight the conflicting node pair on the Draft canvas and suggest adding a sequence dependency edge from node X to the current node in the DAG, providing an entry point for adding this dependency edge with one click.

[0113] The Spec document achieves precise bidirectional synchronization at the node granularity between the Draft canvas (visual view) and the Spec document (text view) through a combination of change event bus and node-entry binding registry design, eliminating the risk of semantic drift between the two views. The semantic conflict detector specifically handles the special conflict scenario of "deleting a node but not completing the constraint" at the business semantic level. Unlike concurrent conflicts at the format level, it provides users with conflict prompts with business meaning rather than technical errors, thereby moving the "consistency guarantee between design document and execution logic" from runtime checks to design-time confirmation.

[0114] Step 203: Optimize conversational interaction and check design rules.

[0115] The instruction parser receives natural language text instructions from the user and calls the LLM to classify the instruction text and extract parameters. The intent classification result is one of the predefined operation types: {INSERT_NODE (insert node), DELETE_NODE (delete node), MODIFY_NODE (modify node), MERGE_NODES (merge node), ADD_EDGE (add edge), ADD_BRANCH (add conditional branch), UPDATE_SPEC_FIELD (update Spec field)}. Simultaneously, operation parameters are extracted (e.g., for INSERT_NODE, the following need to be extracted: the name of the reference node at the insertion position, the business semantic description of the new node, and the relationship type between the new node and the reference node). The output is an operation instruction record containing the operation type and operation parameters. When the LLM's confidence in the instruction intent parsing is lower than the threshold (default 0.7), the instruction parser sends an ambiguity clarification request to the user, displaying candidate parsing results for the user to confirm before execution. DAG Operation Executor: Receives operation instruction records output by the instruction parser and executes corresponding graph operations on the current DraftDAG according to the operation type: INSERT_NODE operation inserts a new node at the successor position of the specified reference node, and marks the new node as "to be labeled" if there is no matching item in the new node's business semantic label and label mapping table; MERGE_NODES operation merges two nodes into a new node, with the new node's inbound and outbound edges being the union of the original two nodes' inbound and outbound edges, and sends a merge event to the Spec-side synchronization processor to trigger Spec entry merging; ADD_BRANCH operation inserts condition edges and branch nodes after the specified node, with the condition_desc field of the condition edge written with the user-described condition text (probabilistic level, to be determined in step 303); after all graph operations are completed, the corresponding change event is pushed through the change event bus in step 202, driving the Spec-side synchronization processor to synchronously update the Spec document (output: the updated DraftDAG and the change event that triggered synchronization). Design rule checking engine: Automatically triggered after each DAG change (can also be manually invoked by the user). It receives the current DraftDAG and Spec document, traverses the system's built-in design rule knowledge base; design rules are stored in an IF-THEN structure: the condition part describes the structural characteristics of the DAG (e.g., "There exists a set of nodes containing back edges AND this set of nodes has no exit edges pointing to the termination node"), and the action part describes the output problem description and remediation suggestions; the rule checker performs condition checks on each rule, extracts the violation node ID and violation description for rules with true conditions, and assembles them into a list of check result records (output); the check result records are pushed to the user interface in a structured report format, and violation nodes are highlighted on the Draft canvas; the design rule knowledge base is organized by industry sector, and the system automatically loads the corresponding industry's rule subset based on the compliance requirements (compliance_requirements) field value in the Spec document (e.g., if compliance_requirements contains "finance", the system loads the finance sector rule subset; if it contains "medical", the system loads the medical sector rule subset). Difference Detector: Executed periodically (can also be manually triggered by the user). It receives the current set of node IDs from the DraftDAG and all node_ids from the binding registry in step 202. The difference between the two sets is calculated: node_ids existing in the DraftDAG but without a corresponding Spec_entry_id in the binding registry are designated as "undescribed nodes," and Spec_entry_ids existing in the binding registry but no longer existing in the DraftDAG are designated as "orphaned Spec entries." The difference result is output to the user interface as a difference list (output).

[0116] Global Structure Analyzer: Responds to the user's global analysis request (input: request type, such as "Exception Handling Coverage Check"). Using the current DraftDAG as input, it performs the corresponding DAG traversal and check according to the request type: "Exception Handling Coverage Check" traverses all leaf nodes and all nodes labeled as external call types, checking if each has at least one outgoing edge labeled as "Exception Path"; the check results (a list of node IDs without configured exception handling and suggestions) are output in the form of a structured analysis report.

[0117] By parsing natural language modification instructions into explicit predefined graph operation types, the conversion process between the user's natural language expression and DAG data structure operations is standardized, eliminating ambiguity between natural language instructions and actual modification intentions. The rule inspection engine is designed to replace the subjective judgment of LLM with an IF-THEN structured rule base, making the rule inspection results deterministic and interpretable, and supporting dynamic loading of rule subsets by industry domain, thus achieving the maintainability of domain rules.

[0118] In the Blueprint compilation and Workflow generation phase, the lueprintCompiler layer transforms the probabilistic Blueprint (Draft + Spec) designed by the user on the canvas into a deterministic Workflow that can be officially run on the LLMOps platform. This deliverable includes two forms: application chain diagrams (visualization) and executable code (code). The entire process relies on the Skill alignment service in phase four and the Spec-follow compliance verification engine in phase five.

[0119] For example, the blueprint compilation and agent workflow generation process includes: Step 301: Semantic parsing and business intent extraction of Draft nodes Node-Spec Association Reader: Receives the node list of DraftDAG, queries the node-entry binding registry established in step 202 for each node node_id, obtains the corresponding Spec_entry_id, and then reads the corresponding Spec entry record from the Spec storage area; outputs the (node ​​record, Spec entry record) pair to the node IR constructor.

[0120] Node IR Constructor: Receives each pair (node ​​record, Spec entry record), assembles them according to the Node IR Schema: The Schema is defined as {node_id (unique node identifier), business_intent (business intent description, derived from the node's business semantic label and the semantic_description field of the Spec entry), input_schema (input data type probability level description, derived from the input_schema_description field of the Spec entry), output_schema (output data type probability level description, derived from the output_schema_description field of the Spec entry), preconditions (list of preconditions, derived from the Spec entry), postconditions (list of postconditions, derived from the Spec entry), invar...} The `iants` (a list of invariants from the Spec entry), `node_type` (node ​​type from the type annotation of the DAG node, optional values: `BUSINESS_LOGIC`, `CONDITION_BRANCH`, `ENGINEERING_NODE`, `HUMAN_IN_THE_LOOP`), `edge_in` (a list of source node IDs for all incoming edges), and `edge_out` (a list of target node IDs and edge types for all outgoing edges) are used. For nodes without a corresponding Spec entry (residual "undescribed nodes" not processed by the difference detector), the `input_schema` and `output_schema` fields of `node_ir` are marked as "to be inferred," and are inferred by the type conversion engine from the interface signature of the bound Skill during the type determination stage in step 303. The Node IR records of all nodes form a Node IR set, which is written to the compiler memory buffer.

[0121] By using a standardized Node IRSchema to uniformly represent the business semantics and Spec constraints of Draft nodes, a unified input format with defined types is provided for subsequent steps 302 to 305, eliminating the adaptation cost between the Draft canvas data format and the compiler's internal data format.

[0122] Step 302: Skill matching and binding with business nodes.

[0123] Skill Alignment Service: Initiates a Skill matching request for each Node IR in the Node IR set; receives a single Node IR, combines the business_intent field text and the input_schema / output_schema fields as the query description, and calls the three-layer funnel Skill Alignment Engine in Phase 4 (see steps 404 to 406) to perform Skill matching; receives the matching results returned by the three-layer funnel engine, which includes: the best matching Skill identifier best_skill_id, the total confidence of the match (a floating-point number including the confidence interval [conf_low, conf_high]), the score decomposition of each layer of the match (keyword layer score, vector layer score, knowledge graph layer score), and a list of candidate Skills (including the skill_id and confidence of each candidate Skill).

[0124] Low-confidence interceptor: Receives the matching results returned by the Skill alignment service and checks if the confidence level is lower than the interception threshold (default 0.7). If it is lower, it packages the node_id, best_skill_id, confidence level, candidate list, and score decomposition of each layer of the Node IR into a low-confidence notification record, pushes it to the pending confirmation queue in the user interface, and marks the compilation status of the node as PENDING_CONFIRMATION, pausing the subsequent compilation of the node. After the user selects or confirms the recommended result from the candidate list, it writes the user-selected skill_id into the PENDING_CONFIRMATION status record, updates the node's compilation status to CONFIRMED, and pushes it back into the processing queue. If the confidence level is higher than or equal to the threshold, it outputs directly to the Skill binding writer without user intervention.

[0125] Skill Binding Writer: Receives the matching results that have passed the confidence check (or user confirmation), adds binding information for the following fields to the Node IR and writes them back: {bound_skill_id (bound Skill identifier), skill_param_template (Skill parameter configuration template, read from the Skill knowledge base, including parameter name, type, whether required, and default value), match_confidence (final match confidence), match_explanation (text based on scores for each layer, used for interpretable output), alternative_skills (list of alternative Skills)}; the updated Node IR (including Skill binding information) is written to the compiler memory buffer (output); simultaneously, the matching results (node_id, business_intent, best_skill_id, confidence) are written to the matching history for consumption by the Phase 4 human-machine feedback closed-loop module.

[0126] By using a low-confidence interceptor, the manual confirmation step is precisely inserted into the node binding process where the confidence level is insufficient, rather than requiring manual confirmation for all nodes. This ensures that the compilation process maintains the efficiency of automatic binding with high confidence while preserving human decision-making power for uncertain matches. The output of the interpretable matching path (score decomposition at each level) allows users to understand the basis of the system's recommendations during the confirmation process, rather than passively accepting black-box results.

[0127] Step 303: Type determination and transformation from probability level to determinism.

[0128] The type conversion engine performs three types of processing on each Node IR in sequence: type determinization, condition specification, and resource binding specification.

[0129] Type determination processing (completed collaboratively by the type compatibility judgment unit, the value range intersection calculation unit, the runtime assertion generator, and the type conflict notify unit).

[0130] Type compatibility judgment unit: Receives the probability-level type description T_Spec for each parameter in the input_schema field of the Node IR, and the type definition T_skill for the corresponding parameter with the same name in the Skill interface signature read from the Skill knowledge base; reads the system's pre-set type inheritance relationship table from the Skill knowledge base (this table defines the parent-child relationship between business semantic types and basic types, such as CreditScore inheriting from Integer and having a value range constraint of [0,1000]); determines whether the value range of T_Spec is completely contained by the value range of T_skill (i.e., T_Spec is a subtype of T_skill); if so, directly uses T_Spec as the determined type of the parameter and outputs it to the determined_input_schema field of the Node IR; if not, outputs a "type incompatible" flag and a (T_Spec, T_skill) pair, and passes it to the value range intersection calculation unit.

[0131] The value domain intersection calculation unit receives (T_Spec, T_skill) pairs, reads the value domain descriptions of the two types (for numeric types, reads the interval [min, max]; for enumeration types, reads the set of enumeration values; for string types, reads the format pattern); calculates the intersection of the two value domains (for numeric types, the interval intersection; for enumeration types, the intersection of the enumeration value sets; for string types, the intersection of the format patterns); if the intersection is not empty, the value domain of the intersection is used as the determined type of the parameter, output to the determined_input_schema field of the Node IR, and a generation instruction is sent to the runtime assertion generator; if the intersection is empty (fundamental type incompatibility), a notification is sent to the type conflict notifyer.

[0132] Runtime assertion generator: Receives the generation instruction (including parameter name and original value range constraint of T_Spec) from the value range intersection calculation unit, generates the corresponding runtime assertion code snippet (e.g., generate assert 0≤value≤1000, "CreditScore exceeds the Spec definition range" for the CreditScore parameter), writes the code snippet to the runtime_assertions field of Node IR (output); and pushes a warning notification (including parameter name and constraint relaxation description) to the user interface.

[0133] Type Conflict Notifier: Receives notifications with empty value domain intersections (including conflict parameter name, T_Spec description, T_Skill description, and incompatibility reason), marks the compilation status of the node as TYPE_CONFLICT, generates a type conflict notification record, pushes it to the conflict processing queue in the user interface, and adds a conflict highlight mark to the node on the Draft canvas; after the user selects to correct the Spec type description or reselects the Skill, the compilation status of the node is restored to PENDING and re-enters step 302.

[0134] In addition to the basic three-level processing strategy mentioned above, the type conversion engine also performs special processing for the following boundary scenarios: Boundary Scenario 1 (Scalar / List Cardinality Mismatch): When the upstream node outputs a scalar (e.g., String type customer_id) while the downstream node's Skill interface expects a list type (e.g., List[String] type customer_ids), the type compatibility judgment unit identifies it as "cardinality mismatch," does not proceed to the value domain intersection calculation, and directly generates an Error-level conflict record by the type conflict notifier; at the same time, the fix suggestion automatically retrieves the encapsulated conversion class Skill from the Skill knowledge base where input_type is scalar and output_type is the corresponding list type. If the search is successful, a recommended insertion position is provided (it is recommended to insert this encapsulated Skill between the upstream and downstream nodes).

[0135] Boundary Scenario 2 (Many-to-One Merge Type Derivation): When multiple upstream nodes output different types of data (e.g., node A outputs CustomerID type and node B outputs GuestID type) and flow into the same downstream node, the type compatibility judgment unit searches for the nearest common ancestor (LCA) of all input types in the type inheritance table. If a common ancestor (e.g., UserIdentifier) ​​exists, the common ancestor is used as the determined type after merging and written into determined_input_schema. If no common ancestor exists (i.e., the input type sets are completely incompatible), the type conflict notifier generates an Error-level record, requiring the user to explicitly declare the accepted union type in the Spec for the merging node or resolve the issue by inserting a type adaptation skill.

[0136] Scenario 3 (Skill version upgrade interface change): Before compilation and startup, the type conversion engine performs a Skill version compatibility pre-check: It reads the current bound version number (skill_version) corresponding to bound_skill_id in each Node IR and compares it with the latest version number of the Skill in the Skill knowledge base; if there is a difference in the version number, it reads the interface signature difference field (changed field name, original type, new type) in the version change record; it performs a type compatibility judgment on the difference field: if the new interface type is compatible with the original bound type (the subtype relationship is valid), it automatically and silently upgrades; if it is incompatible, it generates a warning-level prompt (including a list of changed fields and suggested parameter migration methods) and provides two processing options: "continue to use the old version of Skill" and "upgrade to the new version and manually correct the parameter binding".

[0137] Condition specification processing (completed by the condition expression conversion unit): Receive records marked as condition edges in the edge_out field of the Node IR (each containing a condition_desc probability level description text); for each condition description text, extract available parameter identifiers from the preconditions field of the Spec and the parameter name list of the bound Skill; map the business terms (e.g., "high-risk customer") in the condition description text to the available parameter identifiers (the mapping relationship between business terms and parameter identifiers is extracted from the parameter comments of the Skill interface; if the mapping is unclear, a confirmation flag is generated); generate a Boolean expression string (e.g., customer.risk_level == 'HIGH'), and write it to the condition_expr field of the corresponding condition edge (output).

[0138] Resource binding concretization processing (completed by the resource invocation configuration generation unit): Receives the `bound_skill_id` and `skill_param_template` from the Node IR; reads the `determined_input_schema` field from the Node IR (input parameters of determined type); matches the field names of each parameter in `determined_input_schema` with the corresponding parameter slots in `Skill_param_template` (double matching by parameter name and type), generating parameter binding configurations (including the binding source for each parameter: from upstream node output fields, from user input, or using default values); writes the parameter binding configurations to the `param_binding` field of the Node IR (output).

[0139] By decomposing type determinization into the orderly collaboration of four functional units—"subtype compatibility judgment → value domain intersection calculation → runtime assertion generation → conflict notification"—the system can automatically determine most type ambiguities without requiring full user intervention (using constraint relaxation + runtime assertion guarantee), requiring manual decision-making only for fundamentally incompatible type conflicts. This mechanism advances the discovery of type errors from runtime to compile time, while minimizing the dependency of the compilation process on user intervention.

[0140] Step 304: Generate a dual-mode application of chain graph and executable code.

[0141] HITL Node Inserter (preceded by chain graph and code generation): Receives the list of preconditions fields and the Node IR set from the Spec document. Scans all precondition entries in the Spec document with the format "Manual review required when [condition]". For each entry that meets the format, extracts the trigger condition (e.g., "Credit amount > 500,000 yuan") and the trigger position (the corresponding node's node_id). Inserts a new HUMAN_IN_THE_LOOP type Node IR before the edge_in list of the corresponding node in the Node IR set. The preconditions field is written with the trigger condition, and the param_binding field is written with the reviewer's role and permissions (extracted from the compliance_requirements field of the Spec) and the timeout handling policy (automatic degradation if no response is received within 24 hours by default). Output: Supplements the complete Node IR set for HITL nodes.

[0142] Application Graph Generator: Receives a complete set of Node IRs and a list of DAG edges. Performs node type mapping according to the LLMOps platform's application graph schema: USINESS_LOGIC type nodes are mapped to Tool Nodes (bound_skill_id corresponds to the specific Skill implementation); CONDITION_BRANCH type nodes are mapped to Router Nodes (condition_expr writes the routing rules); HUMAN_IN_THE_LOOP type nodes are mapped to HITL Nodes; ENGINEERING_NODE type nodes are mapped to Log Nodes or Monitor Nodes; edge type mapping is used for data flow connections, with strong type constraints (determined_output_schema→determined_input_schema) appended to the connections; parallel branches in the DAG (sibling nodes without data dependencies) are mapped to the platform's parallel execution primitives; the generated result is an application graph schema document (JSON or YAML format) conforming to the LLMOps platform standard, written to the application graph storage area (output).

[0143] Exception handling code generator (preparing for executable code generation): Receives the complete Node IR set and the exception handling strategy field from the Spec document; for each BUSINESS_LOGIC type node, generates the corresponding exception handling code template parameters: number of retries (from the exception handling strategy in the Spec, default 3 times), retry interval strategy (exponential backoff base interval default 1 second), circuit breaker trigger threshold (number of consecutive failures default 5 times), and fallback scheme (checks whether fallback_skill_id is defined in the exception handling strategy in the Spec; if not, generates fallback logic that returns an empty result); Output: Exception handling parameter record for each node.

[0144] Executable code generator: Receives a complete set of Node IRs, a list of DAG edges, and records of exception handling parameters. It iterates through the Node IRs in topological order (starting from nodes with an in-degree of 0). For each node, it calls the code template corresponding to `bound_skill_id` from the Skill code template library (the template is a parameterized code snippet, with parameters populated using the template engine). It fills the template variable with the parameter binding configuration of the `param_binding` field and appends the assertion code of the `runtime_assertions` field to the end of the node code snippet. It generates corresponding if-elif-else branch code blocks for conditional edges (including the `condition_expr` field). For parallel edges (sibling nodes without dependencies), it generates concurrent execution code blocks using `asyncio.gather` (Python) or `Promise.all` (JavaScript). It concatenates the node code snippets in topological order, wrapping them with Workflow definition metadata (Workflow name, version number, description). It embeds observability acquisition code (calling the `span` record from the OpenTelemetry SDK) into each node code snippet. Finally, it generates a complete executable code file and writes it to the code storage area (output).

[0145] Dual-morph synchronization controller: Maintains consistency between the application chain graph storage area and the code storage area; when a user performs modification operations on the application chain graph in the Workflow editor of the LLMOps platform (receiving modification event input), the dual-morph synchronization controller converts the chain graph modification into the corresponding code change (node ​​addition / deletion maps to code snippet addition / deletion, parameter modification maps to template variable update), and updates the code storage area; reverse synchronization is similar; after the synchronization operation is completed, the Phase 5 Spec-follow compliance verification engine is triggered to perform incremental verification on the updated Workflow.

[0146] Building on this, the HITL node inserter automatically transforms the manually reviewed rules described in natural language in the Spec into executable HITL node configurations, eliminating the manual translation costs of converting business compliance requirements into technical implementations; the dual-morphology synchronization controller keeps the application chain graph and executable code consistent throughout the entire lifecycle, solving the fundamental problem of "disconnect between visual design and actual running code" in existing platforms.

[0147] The Skill Auto-Discovery and Explainable Alignment phase exists as a continuously running background service. Its purpose is to continuously discover, extract, and consolidate reusable skills by analyzing actual operational processes within the enterprise IT environment, building a dedicated enterprise skill knowledge base, and providing high-quality skill matching services for step 302 of Phase 3. This phase can run in parallel with the Blueprint compilation and Workflow generation phases without blocking the compilation process. For example, the Skill Auto-Discovery and Explainable Alignment process includes: Step 401: API runtime call pattern analysis and skill discovery Lightweight probes are deployed in sidecar mode on enterprise API gateways or service mesh nodes. They perform non-intrusive collection of API requests and responses, and push the collected data (including call endpoints, parameter key lists, response status codes, and time consumption) asynchronously to the call log receiver (output). The probe itself does not modify the request / response content.

[0148] Call Log Receiver: Receives call record streams pushed by probes, aggregates call records using a sliding time window (default window size 30 days), groups by call endpoint, and maintains the following statistical fields for each endpoint: {endpoint_id, call_count_daily (average daily call count), success_rate_30d (30-day success rate), avg_latency_ms (average latency), p95_latency_ms (p95 latency), p99_latency_ms (p99 latency)}; these statistical fields are written to the API call statistics table (output).

[0149] Call frequency statistics: Receives the API call statistics table, filters out endpoints with call_count_daily≥10 and success_rate_30d≥95%, marks these endpoints as "high-value API candidates" and writes them into the high-value candidate set (output); endpoints with call_count_daily<10 are written to the low-frequency API log (do not trigger Skill encapsulation); endpoints with success_rate_30d<95% are written to the unstable interface record and marked as requiring manual confirmation before encapsulation.

[0150] Parameter Distribution Analyzer: Receives a high-value candidate set. For each candidate endpoint, extracts the request parameter key-value pairs from the call logs for all call records within the past 30 days. For each parameter key, it calculates the distribution characteristics of its values: if the concentration of a parameter's value in all calls exceeds 80% (i.e., the frequency of the same value appears more than 80% of all calls), then the parameter is set as the default value parameter of the Skill template; otherwise, it is set as a user input parameter. Output: Parameter category records corresponding to each candidate endpoint (including a list of default value parameters and a list of user input parameters).

[0151] Composite Skill Constructor: Receives call sequence records from the API call statistics table. Based on a time window (default 5 minutes), it calculates the consecutive call conditional probability P(B|A) of any two endpoints (A, B) (i.e., the probability of calling B within 5 minutes after calling A). For (A, B) pairs where P(B|A) ≥ 70%, it extracts the response body field set of A and the request parameter field set of B, generates automatic mapping rules for fields with the same name (direct mapping when types are compatible, and writing a "manual confirmation of mapping required" flag when types are incompatible). It then packages the (A, B) pairs and their automatic mapping rules into composite capability unit candidate records (output).

[0152] The parameter distribution analyzer performs statistical analysis on the parameter value distribution of each API, automatically identifying stable parameters that can be fixed as default values ​​and dynamic parameters that need to be provided by the user. This ensures that the parameter specifications of the encapsulated Skill template are consistent with the actual usage pattern, avoiding the common problems of parameter omission or over-parameterization during manual inventory. The composite Skill builder automatically discovers implicit API dependency chains based on temporal conditional probability, and precipitates cross-system collaboration patterns that are difficult to identify manually into reusable composite Skills.

[0153] Step 402: Code execution trajectory mining and business process summarization.

[0154] The static code analyzer receives a set of code file paths from the enterprise code repository, calls the AST parsing library to perform syntax parsing on the code files, extracts function nodes from the AST, and reads the following attributes for each function node: function name, parameter list (including parameter names and type annotations), return type annotation, raise statement in the function body (extracting exception types), and call statement in the function body (extracting the called function name). Based on the extraction results, it constructs a function call graph (with function names as nodes and call relationships as directed edges), counts the in-degree (number of times each function is called), and writes the function attribute records and call graph into the code analysis result database (output).

[0155] Receive function attribute records from the code analysis result library and function execution logs from the APM system. The APM logs include function name, execution count (daily statistics), and average execution time. Associate the APM execution count data with the function list from the code static analysis (matching by function name), filter out functions with ≥10 daily execution counts and called by multiple (≥3) callers, and mark them as "high reusability function candidates" (output).

[0156] Receive the task execution history of the enterprise workflow engine (including task name, input parameters, output results, execution time, and dependent task list), and construct a task dependency directed graph using the dependent task list field of the task execution record; extract the triples "business process name (inferred from task group name) → execution task sequence → resources (endpoint or function name) called by each task" from the connected subgraphs (i.e., a complete business process instance) in the task dependency graph; deduplicate multiple process instances with the same task sequence (perform hash comparison based on the string representation of the task name list), and extract the task sequences that appear ≥3 times as business process Skill template candidates, and write them to the capability unit candidate library (output).

[0157] LLMOps Native Skill Synchronizer: Receives a list of skills from the LLMOps platform's native skill library. For each skill record in the list, it checks whether the skill_id already exists in the skill knowledge base. Skills that do not exist are directly written to the skill knowledge base (output). For existing skills, the version number is checked, and if the platform version number is updated, an overwrite update is performed.

[0158] By combining a static code analyzer with a dynamic execution frequency filter, "frequently called and reused across multiple callers" is used as the identification criterion for capability unit candidates, which is more accurate than relying solely on static analysis (which cannot determine the actual usage frequency) or relying solely on dynamic logs (which cannot obtain function signature and type information). The business process log parser transforms the execution history of the workflow engine into reusable process-level skill templates, capturing business process knowledge that API-level analysis cannot identify.

[0159] Step 403: Standardize Skill encapsulation and import knowledge base.

[0160] Skill Name Generator: Receives endpoint URLs or function names from capability unit candidates, calls LLM to generate human-readable skill business names based on the semantics of the endpoint path or function name (e.g., generating "Customer Credit Score Query" from / api / customer / credit-score / query); Output: Skill business name; Skill Wrapper: Receives candidate records of various capability units, business names output by the Skill name generator, and a set of skill_ids from existing records in the Skill knowledge base. It assembles Skill records according to the standard Schema of the Skill knowledge base. The Schema is defined as {skill_id (unique identifier, UUID format), skill_name (business name), skill_description (functional description, generated by LLM based on endpoint paths and parameter lists), applicable_industries (list of applicable industries, inferred from industry annotations in step 102), input_params (list of input parameter type signatures, including parameter name, type, whether required, and default value), output_schema (output data type signature), performance_baseline (performance... The baseline includes p50 / p95 / p99 delays, from call statistics in step 401, call_example (call example, populated by the wrapper selecting a successful call case from the historical call record), error_handling (exception handling description, from the raise statement type extracted by the code static analyzer, or the error code definition in the API documentation), feature_vector (Skill feature vector, generated by vectorizing the skill_name and skill_description texts, for use by the vector recall layer of the three-layer funnel), source_type (source type, enumeration values: API / FUNCTION / COMPOSITE_SKILL / WORKFLOW_PATTERN / LLMOPS_NATIVE), and created_at (encapsulation timestamp). Skill Knowledge Base Write Controller: Receives Skill records output by the Skill wrapper, checks the similarity between the feature_vector of the record and the feature_vector of existing Skill records in the knowledge base (vector nearest neighbor retrieval); if the highest similarity is ≥0.9, it is determined to be a duplicate Skill, and a field merging update is performed (merging the applicable_industries and error_handling fields, and overwriting the old value with the performance_baseline of the new record), without adding a new record; if the highest similarity is <0.9, it is added to the knowledge base, and the vector index is updated simultaneously (output). By defining a standard SkillSchema that includes semantic feature vectors (feature_vector), the Skill knowledge base can simultaneously support keyword retrieval (based on the Skill_name and applicable_industries fields) and semantic vector retrieval (based on feature_vector), providing a unified retrieval interface for the three-layer funnel alignment in steps 404 to 406. The deduplication and merging mechanism of the Skill knowledge base write controller enables the same capability description from different discovery channels (API probes, code analysis, process logs) to be aggregated into a single Skill record, avoiding recall noise caused by the existence of multiple redundant records for the same capability in the knowledge base.

[0161] Steps 404 to 406: The three-layer funnel can be used to interpret skill alignment. The three-layer funnel is executed sequentially, with each layer receiving the output of the previous layer as input, gradually narrowing down the candidate set.

[0162] Step 404: Keyword Recaller (First Layer): Receives the business_intent text from the query description, performs word segmentation on the text, and extracts a list of business semantic keywords; using the keyword list as the query condition, performs an inverted index retrieval on the skill_name, skill_description, and applicable_industries fields of the Skill knowledge base, and returns the top 50 to 100 Skill records with the highest relevance scores (output); at the same time, it records the keyword matching score of each returned Skill (for interpretable output in step 406).

[0163] Step 405: Semantic Vector Sorter (Second Layer): Receives 50 to 100 candidate capability units returned by the keyword recaller, converts the query description (concatenation of business_intent and input_schema fields) into a query vector (calls the vectorization service), calculates the cosine similarity between the feature_vector of each candidate capability unit and the query vector, reads the historical usage feedback data (user correct labeling rate, average user satisfaction) of each skill from the Skill historical usage record table, calculates the comprehensive score with a weight of 0.7 (semantic similarity) × 0.3 (historical feedback), sorts the comprehensive scores in descending order, and outputs the Top-K candidates (K value defaults to 5) and the semantic similarity score of each candidate (output).

[0164] Step 406: Knowledge Graph Validator (Third Layer): Receives the Top-K candidate Skill list output from Step 405, and the list of bound_skill_ids of other nodes already bound to the current Workflow (i.e., the context Skill set of the current Workflow); for each candidate Skill, queries the following relationships from the business domain knowledge graph: ① Whether there is an incompatible_with relationship between the skill_id node of this Skill and each node in the context Skill set (e.g., if two candidate Skills are marked as mutually exclusive in the knowledge graph, the confidence is reduced); ② The requirements relationship of this Skill (i.e., the requirements of this Skill). First, a prerequisite Skill is executed. Then, it is checked whether the prerequisite Skill exists in the upstream node of the current DAG (if it does not exist, the confidence is reduced and the missing prerequisite condition is noted in the output). For each candidate Skill, the knowledge graph compatibility coefficient is calculated (the value is 0 to 1, the coefficient is 1.0 when there is no incompatible_with and the requirements are met; the coefficient drops to 0.3 when there is incompatible_with; the coefficient drops to 0.5 when the requirements are missing). The comprehensive score in step 405 is multiplied by the knowledge graph compatibility coefficient to obtain the final confidence. The Skill with the highest confidence is selected as the recommendation result, and a confidence interval [final confidence - 0.05, final confidence 0.05] is generated (estimated based on the error range of historical data). Output: the skill_id and final confidence (including the confidence interval) of the best recommended Skill, and a list of candidate Skills (including the three-level score decomposition of each Skill).

[0165] Interpretable Output Generator: Receives intermediate results from each layer of the three-layer funnel (first layer keyword matching score, second layer semantic similarity score, third layer knowledge graph compatibility coefficient) and the optimal recommendation result, generating interpretable output records: {match_path_explanation (matching path description, text description of each score in the three layers and its recommendation basis), confidence_interval (confidence interval), counterexample_explanation (counterexample explanation: select the second highest-scoring Skill from the candidate Skills, explaining the specific reasons why its score is lower than the recommended result, such as "the semantic similarity score of this Skill (0.72) is lower than the recommended Skill (0.91), and the knowledge graph detects an incompatible_with relationship with the current context"), alternative_comparison (alternative comparison table: lists the skill_name, three-layer scores, p95 delay of performance_baseline, and applicable_industries of the Top-K candidate Skills in tabular format)}; Output: Interpretable output records; User Feedback Processor: Receives user feedback on matching results (input, operation type: CORRECT - correct labeling, WRONG - incorrect labeling, REPLACE - replace with another Skill); For CORRECT, writes (query description feature vector, recommended Skill_id) to the positive sample record; for WRONG, writes (query description feature vector, recommended Skill_id) to the negative sample record; for REPLACE, writes (query description feature vector, user-selected Skill_id) to the positive sample record and (query description feature vector, recommended Skill_id) to the negative sample record; when positive / negative samples accumulate to a threshold (default 100 new samples), triggers the vector sorter's model update task (incrementally updates weight parameters based on new samples); simultaneously, updates the applicable_industries field in the Skill record corresponding to the user-selected Skill_id (adds industry labeling for the current Workflow).

[0166] The knowledge graph validator introduces business domain compatibility constraints and precondition constraints on top of vector semantic similarity, enabling the same business intent to match semantically relevant and context-consistent Skills in different Workflow contexts. This solves the problem that pure vector similarity retrieval cannot perceive the business constraint relationships between Skills. The counterexample explanation mechanism of the interpretable output generator (actively explaining why suboptimal candidates are not recommended) allows users to understand the recommendation logic, rather than just seeing the ranking results, significantly reducing the user's verification cost for the recommendation results.

[0167] The output of Step 304 can be embedded in the Spec-follow formal compliance verification phase as a quality gate before Workflow deployment. The aim is to ensure that the outputs of the Draft→Workflow transformation strictly adhere to all specifications defined in the Spec document across four dimensions: type, process, business rules, and performance constraints. This shifts the traditional "runtime error detection" to "design-state compliance verification." For example, the Spec-follow formal compliance verification process includes: Step 501: Business Semantic Type System Initialization Spec type definition parser: Receives a Spec document, scans all input_schema_description and output_schema_description fields in the Spec document, and performs structured parsing on the type description text in each field: extracting the type name (e.g., "CreditScore"), basic type declaration (e.g., "Integer"), value range constraint description (e.g., "integers between 0 and 1000"), and format constraint description (e.g., "format is CUST-XXXXXXXX"); output: a list of type description records (each containing the type name, basic type, and constraint description text).

[0168] Type Inheritance Relationship Builder: Receives a list of type description records and a system-preset type inheritance relationship table. For each type description record, it matches the base type declaration with the parent type in the preset inheritance relationship table (exact string matching) to establish an inheritance relationship record of "business semantic type → base type". Simultaneously, it parses the constraint description text into structured constraint specifications: numeric range constraints (e.g., "0 to 1000" is parsed as {min: 0, max: 1000}), enumeration constraints (e.g., "low / medium / high" is parsed as {enum_values: ["low", "medium", "high"]}), and format constraints (e.g., "format is CUST-XXXXXXXX" is parsed as the regular expression pattern CUST-\d{8}). Output: Type definition record (including type name, parent type, and structured constraint specifications).

[0169] Constraint Extractor: Receives the preconditions, postconditions, and invariants fields from the Spec document. Performs structured parsing on each constraint text: extracts the constraint type (Precondition / Postcondition / Invariant), the Spec_entry_id of the node to which the constraint belongs, the variable names involved in the constraint, and the comparison operators (e.g., "account balance cannot be negative" is parsed as {variable: "account_balance", operator: ">=", value: 0}); writes the parsing results to the constraint record list (output); for natural language descriptions that cannot be automatically parsed into structured constraints (e.g., complex business rules), writes them to the "constraints awaiting manual confirmation" list, pushes them to the user interface, and marks the corresponding constraint as MANUAL_REVIEW, skipping the constraint in the Z3 verification in step 505.

[0170] Type signature registry writer: Receives a list of type definition records and a list of constraint records, assembles registry records according to the type signature registry schema, defined as {type_registry (type registration dictionary, key is type name, value is type definition object containing parent type and constraint specification), constraint_registry (constraint registration dictionary, key is Spec_entry_id, value is a list of all constraint records for this node)}; writes to the context storage area (output) of the verification engine, for each verification unit in steps 502 to 505 to query and call using Spec_entry_id.

[0171] By parseting the type constraints described in natural language in the Spec document (such as "integers between 0 and 1000") into structured constraint specification objects that can be compared programmatically, subsequent type compatibility checks can perform precise value range inclusion judgments, rather than fuzzy text similarity matching. The constraint extractor sets the MANUAL_REVIEW flag for constraints that cannot be automatically parsed, ensuring that automatic checks cover parsed constraints while preventing a few complex constraints from blocking the overall check process.

[0172] Step 502: Type compliance verification.

[0173] Data flow edge traverser: Receives a list of DAG edges, traverses each data flow edge in topological sorting order; for each edge, reads the determined_output_schema field of the source node and the determined_input_schema field of the target node, as well as the field mapping relationship defined on the edge (source field name → target field name); outputs the (source field type, target field type) pair and the field mapping relationship to the type compatibility judge (output).

[0174] Type compatibility checker: Receives a pair (source field type T_src, target field type T_dst), reads the type definition objects (including parent types and structured constraint specifications) of T_src and T_dst from the type_registry of the type signature registry; performs a compatibility check: if T_src and T_dst are the same, they are compatible; if the parent type chain of T_src contains T_dst (i.e., T_src is a subtype of T_dst), they are compatible; if the base types of T_src and T_dst are the same and T_src... If the value range constraint is a subset of the T_dst value range constraint (for numeric types, compare the range inclusion relationship; for enumeration types, compare the enumeration value set inclusion relationship), then it is compatible; otherwise, it is determined to be incompatible, and the incompatible record is output (including edge identifier, source field name, T_src description, target field name, T_dst description, and reason for incompatibility). The innovation of this step is to include the business semantic type layer (CreditScore, CustomerID, etc.) in the subtype relationship check, so that the type check scope is extended from the basic types of the programming language to the business domain constraint types.

[0175] Business semantic constraint validator: Receives compatible (T_src, T_dst) pairs and further checks whether there are semantic contradictions between the business semantic constraints of T_src and T_dst (e.g., if T_src is a RiskLevel enumeration type containing the value "extremely high", while T_dst is a RiskLevel enumeration type but does not contain the value "extremely high", then there is a semantic contradiction). For cases with semantic contradictions, a warning-level semantic constraint difference record (including a difference description and suggested handling method) is generated and pushed to the verification report; cases without contradictions are directly approved.

[0176] Type Validation Report Generator: Receives the incompatible record list from the Type Compatibility Judge and the Warning record list from the Business Semantic Constraint Validator. For each incompatible record, it generates an Error-level validation item, including: a problem description (format: "The output field [field_name] type [T_src] of node [node_id] is incompatible with the input field [field_name] type [T_dst] of downstream node [node_id]"), and correction suggestions (retrieves a conversion class Skill with input type T_src and output type T_dst from the Skill knowledge base; if it exists, it is recommended; otherwise, it is suggested to modify the Spec type definition). It writes the validation results to the type_check_results field of the compliance report and simultaneously sends a highlighting instruction to the Draft canvas (adding an Error highlight mark to the nodes involving incompatible records) (output).

[0177] By incorporating business semantic types (CreditScore, RiskLevel, etc.) into the subtype relationship checking system, type validation can detect type mismatches at the business semantic level (such as assigning a risk level field to a credit score field), rather than only detecting conflicts between basic types such as Integer and String. The correction suggestions proactively retrieve the appropriate conversion kill from the Skill knowledge base, directly linking the discovery of type errors with the repair path, thus reducing the troubleshooting cost for developers.

[0178] Step 503: Process compliance verification.

[0179] Path Reachability Checker: Receives a Directed Acyclic Graph (DAG), performs a graph traversal (BFS or DFS) starting from the set of initial nodes with an in-degree of 0, and records the set of all reachable nodes; takes the difference between the set of all nodes in the DAG and the set of reachable nodes, and the nodes in the difference set are unreachable nodes; for each unreachable node, traces the source node of its incoming edges, checks whether all incoming edges come from conditional edges (edges with non-empty condition_expr) and whether the conditions are mutually exclusive (by comparing whether the condition_expr string of the conditional edge covers all possible values); if the conditions are mutually exclusive, causing a node to be logically unreachable forever, a Warning-level "Logically Unreachable" check item is generated; if a node has neither incoming edges nor is it marked as a starting node, an Error-level "Orphaned Node" check item is generated (output: reachability check result record).

[0180] Deadlock and Termination Checker: Receives a Directed Acyclic Graph (DAG) and performs Strongly Connected Component (SCC) analysis. If an SCC contains a strongly connected component with more than one node (i.e., a cycle), the cycle is considered a potential deadlock or an infinite loop. For each strongly connected component containing a cycle, checks if there is at least one outgoing edge labeled "Cycle Exit" (i.e., an edge pointing from a node inside the cycle to a node outside the cycle, and this edge carries a cycle termination condition `condition_expr`). If a valid cycle exit edge exists, it is determined to be a bounded cycle, and an Info-level record "Contains Cyclic Structure, Termination Condition Verified" is generated. If no cycle exit edge exists, an Error-level "Cycle Without Termination Condition" check item (containing a list of cycle node IDs) is generated (output: Deadlock and Termination Check Result Record).

[0181] Concurrency Safety Analyzer: Receives write operation resource descriptions (i.e., the "external resource identifier to be written" declared by each Skill in its Skill record, such as database table name or message queue name) from the DAG and Skill knowledge base for each bound_skill_id; identifies all pairs of parallel execution nodes in the DAG (sibling nodes without data dependencies, determined by checking if a path exists between the two nodes); for each pair of parallel nodes, reads the write operation resource set corresponding to their respective bound_skill_id and calculates the intersection of the two sets; if the intersection is not empty (i.e., both parallel nodes are writing to the same external resource), generates a Warning-level "concurrent write conflict" check item and sends an instruction to the application chain graph generator to automatically insert a "resource lock control node" (Lock Node) between the two parallel nodes. The parameters of this Lock Node are configured as follows: lock resource identifier (resource name from the intersection), lock timeout (default 30 seconds). (Output: Concurrency safety check result record, and performs the following Lock Node insertion and deadlock prevention processing:) Single lock insertion: For each pair of parallel nodes that detects a write conflict, a command is sent to the application chain graph generator to automatically insert a "resource lock control node" (Lock Node) between the two parallel nodes; the parameters of the Lock Node are configured as follows: lock resource identifier (from the resource name in the intersection), lock timeout (the initial default value is 30 seconds, which is automatically adjusted proportionally with the depth of the lock dependency chain, doubling for each additional layer of dependency lock, with a maximum of 300 seconds); Multi-lock Deadlock Prevention: When multiple parallel node groups in a DAG involve different shared resources (e.g., node pair (A,B) shares resource R1, node pair (C,D) shares resource R2, and there is a data dependency between node A and node C), automatically inserting multiple Lock Nodes may introduce new deadlock risks (A holds lock R1 waiting for R2, C holds lock R2 waiting for R1, forming a circular wait). Therefore, the concurrency safety analyzer performs additional deadlock prevention checks before multi-lock insertion: ① Resource Dependency Graph Construction: Construct a resource dependency graph with lock resources as nodes and directed edges for "a node holding resource X needs to acquire resource Y before releasing X"; ② Cycle Detection: Perform a Strongly Connected Component (SCC) algorithm on the resource dependency graph; if a cycle exists, it is considered a multi-lock deadlock risk; ③ Resource Ordering Strategy: For scenarios where deadlock risk is detected, all Locks are required to... Nodes request locks in ascending order of resource identifiers (e.g., request lock R1 first, then lock R2), and write the resource request order into the lock_order field of each LockNode. The resource sorting strategy ensures that circular waits do not occur under the premise that the resource request order is globally consistent. It is a classic deterministic method for deadlock prevention (output: record of concurrency safety verification results, and a set of Lock Node insertion instructions (including the lock resource identifier, timeout, and lock_order field value of each Lock Node)).

[0182] Process Validation Report Generator: Summarizes the output records of the above three checkers, organizes the validation results according to severity level (Error / Warning / Info), and writes them into the flow_check_results field (output) of the compliance report.

[0183] The concurrency safety analyzer elevates concurrency conflict detection from the program variable level (which requires code analysis to identify) to the skill semantic level (which can be identified during the design phase) by reading the write operation resource descriptions declared in the Skill record. This allows developers to discover and eliminate concurrent write risks during the Blueprint design phase, rather than encountering data race errors at runtime. The mechanism of automatically inserting Lock Nodes further merges "discovering problems" and "fixing problems" into a single step, reducing the developer's fixing burden.

[0184] Step 504: Compliance Verification of Business Rules and Performance Constraints Integrity Checker: Receives the node_type and business semantic tags of each node in the DAG node list, as well as industry compliance requirements (such as "finance" and "healthcare") read from the compliance_requirements field of the Spec; queries the required node rule base for the corresponding industry (the rule base is stored with the industry tag as the key and "list of required business semantic tags" as the value, such as key="finance", value=["identity verification", "risk disclosure", "compliance audit"]); for each required business semantic tag in the rule base, searches the DAG node list for a node that matches the business semantic tag (exact string matching or synonym matching, the synonym dictionary is read from the domain knowledge graph); if it does not exist, generates an Error-level "missing required node" verification item (including the missing required node type and suggested insertion position—suggested insertion before the first data query type node in the middle DAG) (output: integrity verification result record).

[0185] Sequence Constraint Checker: Receives DAG topology and constraint records of type Precondition from the constraint registry; for each Precondition record containing a constraint of type "Node A must be executed after Node B" (parsed from the constraint text to obtain an ordered pair (A, B), meaning the execution of A depends on B being completed first), checks in the DAG whether a directed path from node B to node A exists (through BFS path search); if not, (i.e., A may be executed before B), generates an Error-level "Sequence Constraint Violation" check item (including constraint description, involved node ID pairs, and violation explanation); simultaneously reads industry-specific sequence constraints (such as "Payment node must be after inventory confirmation node") from the regulatory compliance rule base and performs the same path search check (output: sequence constraint check result record).

[0186] Regulatory compliance checker: Receives the compliance_requirements field value from the Spec, loads the corresponding compliance rule base (maintained separately by industry; rules are stored in IF-THEN structure; the condition part describes the structural features that the DAG must meet; the action part describes the violation and remediation suggestions; the rule base can be updated according to the compliance standard version); performs condition judgment on each compliance rule (checks whether the DAG structure meets the rule conditions); for rules with true conditions (violations), generates a verification item of corresponding severity (Error or Warning, determined by the rule definition) (output: regulatory compliance verification result record).

[0187] Performance latency estimator: Receives the bound_skill_id of each node in the deterministic node IR set, reads the performance_baseline field (including p50 / p95 / p99 latency) of each bound_skill_id from the Skill knowledge base; for sequential execution paths in the DAG, sums the p95 latency of each node on the path as the estimated end-to-end latency (worst-case estimate) for that path; for parallel execution nodes, takes the largest p95 latency among the parallel nodes as the latency contribution of that parallel segment; takes the path with the largest estimated latency among all paths from the start node to the end node as the critical path latency estimate of the Workflow; compares the estimated value with the performance_sla field (end-to-end latency SLA requirement) in the Spec document; if the estimated value exceeds the SLA requirement, generates a Warning-level "Performance Constraint Exceeded" check item, and identifies the node with the largest p95 latency on the critical path of the DAG as the bottleneck node, outputting optimization suggestions (suggesting that the bottleneck node be executed in parallel with other non-dependent nodes, or suggesting adding a caching layer for the frequently called bottleneck Skill) (output: performance latency estimation result record).

[0188] Resource Budget Verifier: Receives the bound_skill_id and param_binding of each node in the deterministic node IR set; reads the resource consumption estimation parameters for each skill from the Skill knowledge base (average token usage for LLM-type skills, and single-call billing for API-type skills); calculates the estimated total resource consumption (total token usage, total number of API calls) for a single Workflow execution based on the DAG execution path; compares the estimated value with the budget_limit field (resource budget ceiling) in the Spec document; if the budget is exceeded, generates a Warning-level "Resource Budget Exceeded" verification item and outputs a resource consumption breakdown list for each skill (sorted in descending order of consumption) for users to identify high-consumption nodes (output: resource budget verification result record).

[0189] The integrity checker reads "must-exist business semantic tags" from the domain knowledge graph and matches them with the business semantic tags of DAG nodes, transforming the verification of industry compliance requirements from relying on human expert review to an automated, structured check; the performance latency estimator provides end-to-end Workflow latency estimates based on historical performance benchmark data in the Skill knowledge base during the design phase, moving the discovery of performance issues from the post-deployment stress testing phase to the design phase, and directly associating specific bottleneck nodes and optimization paths.

[0190] Step 505: Workflow constraint translation, SMT solution verification, and repair suggestion generation.

[0191] The constraint translation module receives Invariant type constraint records and performs the following translation processing on each constraint record: It reads the structured constraint specification of the constraint (e.g., {variable: "account_balance", operator: ">=", value: 0}), translates the initial state declaration of the constraint variable (account_balance) into an SMT variable declaration (declared as an integer or real number, the type determined by the type definition of the corresponding variable in the type signature registry in step 501); it traverses all nodes in the DAG that perform write operations on this constraint variable (identifying output fields containing the variable name from the node's determined_output_schema field), reads the operation semantic description of the corresponding Skill for that node (extracting the operation type from the skill_description field of the Skill knowledge base, such as "deduction", "increase", "overwrite assignment"), and translates the operation semantics into an SMT state transition constraint expression (e.g., a deduction operation is translated as account_balance_after=account_balance_before - The `deduct_amount` function combines the initial state declaration, all state transition constraint expressions, and invariant constraint expressions (`account_balance_after≥0`) into an SMT formula set. For the following three special structures in the DAG, the constraint translation module performs specialized translation processing: Scenario 1 (Conditional Branch): When there are conditional branches in the DAG (e.g., if customer.type=='VIP', take path A; otherwise, take path B), the constraint translation module generates an independent SMT formula subset for each branch path and generates a Boolean guard variable for each branch edge. The verification of the invariant for each branch is transformed into an SMT implication formula: guard_A→(account_balance_after >= 0); Z3 performs joint verification on the implication formulas of all branches to ensure that the invariant holds true under any reachable branch. Scenario 2 (Concurrent Write): When nodes A and B in the DAG both perform write operations on the same constraint variable, the constraint translation module generates two intermediate state variables (variable_after_A, variable_after_B) for that variable. Simultaneously, it adds a final state uncertainty constraint for concurrent writes (variable_final = variable_after_A or variable_final = variable_after_B), and verifies the invariant's validity for both cases. If the verification fails, the counterexample contains the specific concurrent write order that caused the violation. Scenario 3 (Bounded Loop): When there is a bounded loop in the DAG that has passed the termination verification in step 503, the constraint translation module adopts a bounded unrolling strategy: the loop is unrolled up to K times (K defaults to 10, configurable), and independent SMT constraints are generated for each unrolled state; if an invariant is violated within the range of K unrolls, a counterexample is generated; if all K are satisfied, the compliance report will indicate that the invariant verification is a bounded guarantee (valid within the range of K unrolls) rather than a global conclusion; (Output: a set of SMT formulas, grouped by constraint variables, including conditional branch guard formulas, concurrent writing uncertainty formulas, and bounded unrolling formulas).

[0192] SMT Solver Engine: Receives a set of SMT formulas and calls the Z3 SMT solver to perform satisfiability verification on each set of formulas. The innovation of this step lies in the constraint translation module translating the operational semantics of Workflow nodes into the transformation process of SMT formulas, rather than the SMT solver itself. The solver returns two types of results: If the set of formulas is satisfiable (SAT), then all invariants under the execution path are valid, and the "Verification Passed" flag is output; if the set of formulas is not satisfiable (UNSAT), the solver returns a counterexample assignment that invalidates the invariants (a set of variable values ​​such that under these values, there exists a state transition after which the invariants are violated), and outputs a "Verification Failed" flag and the counterexample assignment (output: verification result and counterexample assignment).

[0193] Counterexample Converter: Receives counterexample assignments returned by the SMT solver engine and converts them from SMT variable assignment format into human-readable business semantic descriptions. Conversion rules: Maps SMT variable names back to constraint variable names (e.g., account_balance), maps SMT variable values ​​back to business meanings (e.g., deduct_amount=1500 is converted to "deduction amount is 1500 yuan"), extracts the node_id of the state transition node that invalidates the invariant (by querying the assignment records involving the node's operation variable in the counterexample assignments); generates human-readable counterexample description text (format: "When [triggering condition description], the [operation description] of node [node_id] ([business semantic label]) will cause [constraint variable name] to become [violation value], violating constraint [constraint description]") (output: human-readable counterexample description records).

[0194] Repair suggestion generator: Receives a list of violating node_ids and corresponding constraint variable names from the counterexample description record, and matches the most suitable verification capability unit candidate from the Skill knowledge base according to the following three-stage retrieval strategy: Phase 1 (Type Constraint Matching): Extract the type definitions of constraint variables from the determined_input_schema of the violating node (e.g., account_balance is of type NonNegativeInteger, with a value range constraint of [0, +∞)). Retrieve Skills from the Skill knowledge base that meet the following conditions: the input parameters contain fields with the same name as the constraint variables, and the output parameters contain a type declaration that the value range of the variable satisfies the invariant constraint after processing; these Skills are "type constraint satisfaction" verification Skills and have the highest priority. The second stage (semantic keyword matching): For cases where the first stage did not match, TF-IDF search is performed on the skill_name and skill_description fields of the Skill knowledge base using the constraint variable name (account_balance) and the semantic negation form of the operation (semantic patterns such as "not exceeding", "upper limit", "verification", "reject when insufficient") as keywords to recall semantically related verification capability unit candidates. The third stage (knowledge graph derivation): For cases where the first two stages fail to find the target, query the requirements relationship chain of the business concept to which the constraint variable belongs (e.g., account_balance belongs to the "account" concept) from the business domain knowledge graph, deduce the pre-validation capabilities that the business concept depends on (e.g., "balance adequacy verification"), and use the corresponding Skill as a repair candidate. After merging the three-stage results by priority, for each violating node, it is recommended to insert the selected verification Skill as a pre-verification node at the upstream position of its incoming edge; at the same time, check the preconditions field of the violating node. If there is a lack of range constraints on the constraint variables (such as "the deduction amount does not exceed the account balance"), it is recommended to add the corresponding preconditions constraints for the node in the Spec; combine the recommended insertion position (node_id), the recommended verification Skill (skill_id, skill_name, recommended according to the stage), and the suggested Spec modification (supplementing constraint description text) into a repair solution record (output).

[0195] Compliance Report Aggregator: Receives the output records of all verification units from steps 502 to 505, aggregates all verification items into a three-level classification of Error / Warning / Suggestion, and assembles them into a final structured compliance report: {type_check_results (output of step 502), flow_check_results (output of step 503), business_rule_check_results (output of step 504), performance_check_results (output of step 504), invariant_check_results (output of step 505)} SMT verification results, including pass / fail status, negative example description, and remediation plan; summary (total number of errors, total number of warnings, and total number of suggestions); overall_status (if the total number of errors is 0, it is PASSED; otherwise, it is FAILED); write the compliance report to the Blueprint quality archive (output); send a batch highlighting command to the Draft canvas (add corresponding color highlighting marks to all nodes involved in the error and warning level verification items); write the verification history to the Spec document (including verification timestamp, overall_status, and total number of errors); for Workflows with overall_status of PASSED, trigger the deployment process; for Workflows with FAILED, prevent deployment and require the user to handle all error level verification items before re-triggering the verification. The constraint translation module jointly translates the business invariants described in the Spec natural language (such as "account balance cannot be negative") with the operational semantics of Workflow nodes (operation types such as "deduct" and "increase" extracted from Skill descriptions) into SMT formulas, enabling the SMT solver to perform mathematical-level full-path verification of the business correctness of the Workflow. The repair suggestion generator directly maps the non-compliant nodes in the counterexample assignment to specific insertion positions and recommended Skills, merging "verifying and discovering problems" and "providing repair paths" into a single step, eliminating the understanding gap between developers from abstract error reports to specific repair actions.

[0196] In one embodiment, in the automatic generation of drafts in step 201 of phase two, a multi-candidate generation mechanism can be introduced: for the same idea input, the LLM-driven draft generation engine generates 3 to 5 candidate draft schemes in parallel, each scheme is accompanied by an explanation of its advantages and disadvantages (such as "Scheme A prioritizes processing speed and is suitable for high-concurrency scenarios; Scheme B adds a manual review node and is suitable for strong compliance scenarios"), which can be selected or combined by the user to avoid the uncertainty risk of a single generation result.

[0197] In one embodiment, in steps 401 to 402 of phase four, when a new API or a new code module is deployed in the enterprise environment, the Skill discovery engine automatically triggers the incremental Skill discovery process through an event-driven mechanism (listening for Kubernetes deployment events and CI / CD pipeline completion events). After the newly discovered Skill is encapsulated, it is injected into the Skill knowledge base through a hot update mechanism, without the need to restart the system, resulting in low update latency.

[0198] In one embodiment, during the AgentRuntime Engine's runtime phase, a semantic drift detection mechanism is introduced to continuously compare the output distribution differences between the old and new Agent versions: when the semantic drift metric (based on the business semantic evaluation dimension defined in the Spec) exceeds a preset threshold, an alarm is automatically triggered and pushed to BlueprintStudio, suggesting that the user start the Blueprint version review process; for critical business Agents, it is supported to configure automatic rollback trigger conditions, and when the semantic drift exceeds the severe threshold, it will automatically roll back to the previous stable version.

[0199] In one embodiment, during the Workflow generation phase of step 303 in phase three, cost prediction is performed during the design phase based on the Skill call chain and expected call volume defined in the Spec. This includes Token consumption estimation (based on the Prompt template size and expected call count of each LLM node), Skill call cost estimation (based on the pricing of each Skill and expected call frequency), and storage cost estimation (based on the data scale and query frequency of the vector database), generating a monthly / annual comprehensive cost range. When the estimated cost exceeds the budget constraints defined in the Spec, an alert is issued to the user during the design phase, and cost optimization suggestions are provided.

[0200] In one embodiment, after the AgentRuntime Engine completes a certain number of executions (the default cumulative execution count reaches 1000 times), the system automatically analyzes high-frequency optimization opportunities in the runtime data (such as caching can be introduced if 23% of the call results of a certain node are the same, or the process can be simplified if a certain branch path has never been triggered), and pushes them to BlueprintStudio in the form of a structured proposal, showing the data basis, estimated benefits and suggested specification modification schemes; after user confirmation, the Blueprint version update and a new round of Phase 3 compilation are automatically triggered, forming a continuous improvement closed loop of "design → execution → optimization → redesign".

[0201] In one embodiment, during the Workflow deployment phase, a canary release mechanism for Blueprint versions is supported: the new version of the Workflow runs in parallel with the old version, and requests are allocated proportionally through the traffic routing controller (initially 5% new version, gradually increasing); the canary release decision not only compares technical indicators (latency, error rate), but also compares semantic indicators based on the business semantic acceptance criteria defined in the Spec (such as whether the distribution of credit assessment results is abnormally offset); when the semantic indicators meet all the acceptance conditions defined in the Spec, the traffic ratio is automatically increased to 100%, the Blueprint version status is updated from "canary" to "full" and an audit log is triggered; when the semantic indicators exceed the allowable deviation threshold, a rollback is automatically triggered.

[0202] Figure 3 This is a schematic diagram of a blueprint-driven intelligent agent generation device provided in an embodiment of this application. Figure 3 As shown, the blueprint-driven intelligent agent generation device provided in this embodiment includes: The intent acquisition module 210 is used to acquire intent information, which is either input by the user or comes from an intent template converted from an external case. The blueprint generation module 220 is used to generate a dual-view blueprint consisting of a visual flowchart and a structured specification document based on the intent information; wherein the visual flowchart and the structured specification document are synchronized in real time through a node identifier association table. The intent parsing module 230 is used to parse the dual-view blueprint to obtain the node intent of each node; The matching and binding module 240 is used to match and bind capability units for each node intent from the capability unit knowledge base, and obtain a set of deterministic node intermediate representations; The agent generation module 250 is used to generate an agent workflow for execution on a large language model operation and maintenance platform based on the deterministic node intermediate representation set. The agent workflow includes a dual-form deliverable of an application chain graph and executable code.

[0203] Based on any of the above embodiments, the device further includes: The template conversion module is used to convert the external case into a parameterized intent template in a multi-agent collaborative pipeline driven by a distributed state machine.

[0204] Based on any of the above embodiments, the template conversion module is specifically used for: Cases are collected from multiple external sources through a first intelligent agent; Through the second intelligent agent, the collected cases are extracted in a structured manner using a large language model to obtain analysis records of business objectives, solutions, and key component information. Through a third intelligent agent, the differentiated descriptions of cases from different sources are mapped to a unified business semantic space based on the analysis records. Common fields of cases from different sources are identified, and new intent templates are generated or merged into existing intent templates based on the common fields. The new intent template or the existing intent template is scored and filtered based on three dimensions: feasibility, novelty, and completeness.

[0205] Based on any of the above embodiments, the intent to obtain module 210 is specifically used for: Receive natural language text commands input by the user; The Large Language Model (LLM) is invoked to determine the classification and parameters of the intent in the natural language text instruction. The classification includes at least one of the following predefined operation types: inserting a node, deleting a node, modifying a node, merging a node, adding an edge, adding a conditional branch, and updating a structured specification document field.

[0206] Based on any of the above embodiments, the blueprint generation module 220 is specifically used for: Based on the intent information, a visual flowchart and a structured specification document are generated; The visualized flowchart and the structured specification document are synchronized in real time in both directions. Specifically, for the first change event of the structured specification document, the corresponding node identifier is obtained by querying the binding registry. Based on the node identifier, the first change event is converted into a visual annotation update instruction for the node in the visualization flowchart, so as to update the visual annotation of the node in the visualization flowchart. For the second change event in the visualization flowchart, the entity identifier of the corresponding structured specification document is obtained by querying the binding registry. Based on the entity identifier and the second change event, a new entry is created in the storage area of ​​the structured specification document and written to the binding registry, or the corresponding entry in the structured specification document is updated according to the change.

[0207] Based on any of the above embodiments, the device further includes: a recording module, used to generate and push semantic conflict records for the first change event and / or the second change event that hit the semantic conflict determination rule table; The hit semantic conflict determination rule table includes at least one of the following determination rules: The visualization flowchart experiences a node deletion event, and the constraint field of the corresponding entry in the structured specification document is not empty; The visualized flowchart experiences a node merging event, and the constraint fields of the merged nodes contain semantically mutually exclusive descriptions. The structured specification document experiences a constraint addition event, and the added constraint contradicts the current topology of the visual flowchart.

[0208] Based on any of the above embodiments, the device further includes: an inspection module, configured to traverse the design rules in the design rule knowledge base for the current visual flowchart and structured specification document, and for each design rule, automatically load the corresponding rule subset according to the compliance requirement field value in the structured specification document, and inspect the current visual flowchart and structured specification document based on the rules; wherein the design rules in the design rule knowledge base are stored in an IF-THEN structure.

[0209] Based on any of the above embodiments, the matching and binding module 240 is specifically used for: The determination of the intermediate representation set of deterministic nodes includes: determining the execution type, execution conditions and bound resources of each node's intent in sequence according to the capability units bound to each node's intent, so as to form the intermediate representation set of deterministic nodes.

[0210] Based on any of the above embodiments, the step of matching and binding capability units for each node intent from the capability unit knowledge base includes: for each node intent: Extract the set of keywords of the node intent, and use an inverted index to recall the first number of candidate capability units from the capability unit knowledge base; The node intent and the metadata of each candidate capability unit are encoded into semantic vectors, and the candidate capability units are reordered by calculating the cosine similarity between each candidate capability unit and the node intent. Based on the reordering results, the second-ranked candidate capability units are input into the pre-built knowledge graph to verify the compatibility of input and output types with upstream and downstream nodes, the continuity of business logic, and the consistency of resource dependencies, and to exclude candidate capability units that fail the verification. Generate interpretable aligned output, which includes the following fields: Matching path: This describes the selection path and reasons for elimination for each candidate capability unit; Confidence interval: used to describe the matching confidence level and error range of the final bound capability unit; Counterexample illustration: Used to illustrate the counterexample constraint rules triggered in the knowledge graph; Multiple candidate comparison: Metadata used to compare the second number of candidate capability units.

[0211] Based on any of the above embodiments, the device further includes: an update module, used for: Continuously collect call data during operation through real-time APIs deployed in API gateways or service meshes; Based on the call data, API candidates and capability unit candidates are determined; Based on the candidate capability units and the new capability units, a new capability unit is encapsulated, and the new capability unit is updated in the capability unit knowledge base.

[0212] Based on any of the above embodiments, the device further includes: a verification module, used to perform at least one of the following verifications on the dual-view blueprint: Type compliance verification is used to check the type consistency of data streams across nodes. Process compliance verification is used to detect path reachability, deadlock, and concurrency safety issues in the directed acyclic graph corresponding to the visualized flowchart; Business rule verification is used to check whether the dual-view blueprint meets predefined business integrity, sequence constraints and regulatory compliance requirements based on a pre-set compliance rule base. Performance constraint verification is used to estimate whether the end-to-end response time of the agent workflow meets the service level agreement based on the performance benchmark of the bound capability units.

[0213] Based on any of the above embodiments, the device further includes: The translation module is used to translate the operational semantics of nodes in the intelligent agent workflow into SMT formulas, thereby obtaining a set of SMT formulas; The verification module is used to verify the satisfiability of the formulas in the SMT formula set through the Z3 SMT solver. If the satisfiability of the SMT formula set is satisfiable, then the invariants under all execution paths in the agent workflow are valid, and the satisfiability verification is passed. S1840, if the satisfiability of the formula set is not satisfiable, then the agent workflow fails the satisfiability verification, and a counterexample assignment that invalidates the invariants is returned.

[0214] The blueprint-driven agent generation device provided in this application can be used to execute the blueprint-driven agent generation method provided in any of the above embodiments, and has corresponding functions and beneficial effects.

[0215] Figure 4A schematic diagram of an electronic device 10, which can be used to implement embodiments of this application, is shown. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device 10 may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, user equipment, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0216] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0217] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks and wireless networks.

[0218] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above.

[0219] In some embodiments, the methods described above can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the methods of any of the embodiments described above by any other suitable means (e.g., by means of firmware).

[0220] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0221] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0222] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0223] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device 10, which includes: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device 10. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0224] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0225] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0226] This application also provides a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the blueprint-driven agent generation method as described in any of the above embodiments.

[0227] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0228] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A blueprint-driven agent generation method, characterized in that, include: Acquire intent information, which is either input by the user or derived from an intent template converted from an external case. Based on the intent information, a dual-view blueprint consisting of a visual flowchart and a structured specification document is generated; wherein, the visual flowchart and the structured specification document are synchronized in real time through a node identifier association table; The node intent of each node is obtained by parsing the dual-view blueprint; The intent of each node is matched and bound to a capability unit from the capability unit knowledge base, and a set of deterministic node intermediate representations is obtained. Based on the set of intermediate representations of the deterministic nodes, an agent workflow for execution on the large language model operation and maintenance platform is generated. The agent workflow contains a dual-form deliverable of an application chain graph and executable code.

2. The method according to claim 1, characterized in that, Also includes: A multi-agent collaborative pipeline driven by a distributed state machine transforms the external cases into parameterized intent templates. The multi-agent collaborative pipeline driven by a distributed state machine transforms the external cases into parameterized intent templates, including: Cases are collected from multiple external sources through a first intelligent agent; Through the second intelligent agent, the collected cases are extracted in a structured manner using a large language model to obtain analysis records of business objectives, solutions, and key component information. Through a third intelligent agent, the differentiated descriptions of cases from different sources are mapped to a unified business semantic space based on the analysis records. Common fields of cases from different sources are identified, and new intent templates are generated or merged into existing intent templates based on the common fields. The new intent template or the existing intent template is scored and filtered based on three dimensions: feasibility, novelty, and completeness.

3. The method according to claim 1, characterized in that, The acquisition of intent information includes: Receive natural language text commands input by the user; The Large Language Model (LLM) is invoked to determine the classification and parameters of the intent in the natural language text instruction. The classification includes at least one of the following predefined operation types: inserting a node, deleting a node, modifying a node, merging a node, adding an edge, adding a conditional branch, and updating a structured specification document field.

4. The method according to claim 1, characterized in that, The generation of a dual-view blueprint consisting of a visual flowchart and a structured specification document based on the intent information includes: Based on the intent information, a visual flowchart and a structured specification document are generated; The visualized flowchart and the structured specification document are synchronized in real time in both directions. Specifically, for the first change event of the structured specification document, the corresponding node identifier is obtained by querying the binding registry. Based on the node identifier, the first change event is converted into a visual annotation update instruction for the node in the visualization flowchart, so as to update the visual annotation of the node in the visualization flowchart. For the second change event in the visualization flowchart, the entity identifier of the corresponding structured specification document is obtained by querying the binding registry. Based on the entity identifier and the second change event, a new entry is created in the storage area of ​​the structured specification document and written to the binding registry, or the corresponding entry in the structured specification document is updated according to the change.

5. The method according to claim 4, characterized in that, Also includes: For the first change event and / or the second change event that hits the semantic conflict determination rule table, generate and push semantic conflict records; The hit semantic conflict determination rule table includes at least one of the following determination rules: The visualization flowchart experiences a node deletion event, and the constraint field of the corresponding entry in the structured specification document is not empty; The visualized flowchart experiences a node merging event, and the constraint fields of the merged nodes contain semantically mutually exclusive descriptions. The structured specification document experiences a constraint addition event, and the added constraint contradicts the current topology of the visual flowchart.

6. The method according to claim 4, characterized in that, Also includes: For the current visual flowchart and structured specification document, the design rules in the design rule knowledge base are traversed. For each design rule, the corresponding rule subset is automatically loaded according to the compliance requirement field value in the structured specification document. Based on the rules, the current visual flowchart and structured specification document are checked by itself. The design rules in the design rule knowledge base are stored in an IF-THEN structure.

7. The method according to claim 1, characterized in that, The obtained set of intermediate representations of deterministic nodes includes: Based on the capability units bound to each node's intent, the execution type, execution conditions, and bound resources are determined sequentially for each node's intent to form the deterministic node intermediate representation set.

8. The method according to claim 1, characterized in that, The process of matching and binding capability units for each node intent from the capability unit knowledge base includes: for each node intent: Extract the set of keywords of the node intent, and use an inverted index to recall the first number of candidate capability units from the capability unit knowledge base; The node intent and the metadata of each candidate capability unit are encoded into semantic vectors, and the candidate capability units are reordered by calculating the cosine similarity between each candidate capability unit and the node intent. Based on the reordering results, the second-ranked candidate capability units are input into the pre-built knowledge graph to verify the compatibility of input and output types with upstream and downstream nodes, the continuity of business logic, and the consistency of resource dependencies, and to exclude candidate capability units that fail the verification. Generate interpretable aligned output, which includes the following fields: Matching path: This describes the selection path and reasons for elimination for each candidate capability unit; Confidence interval: used to describe the matching confidence level and error range of the final bound capability unit; Counterexample illustration: Used to illustrate the counterexample constraint rules triggered in the knowledge graph; Multiple candidate comparison: Metadata used to compare the second number of candidate capability units.

9. The method according to claim 1, characterized in that, Also includes: Continuously collect call data during operation through real-time APIs deployed in API gateways or service meshes; Based on the call data, API candidates and capability unit candidates are determined; Based on the API candidates and capability unit candidates, new capability units are encapsulated, and the new capability units are updated in the capability unit knowledge base.

10. The method according to any one of claims 1-7, characterized in that, Also includes: Perform at least one of the following checks on the dual-view blueprint: Type compliance verification is used to check the type consistency of data streams across nodes. Process compliance verification is used to detect path reachability, deadlock, and concurrency safety issues in the directed acyclic graph corresponding to the visualized flowchart; Business rule verification is used to check whether the dual-view blueprint meets predefined business integrity, sequence constraints and regulatory compliance requirements based on a pre-set compliance rule base. Performance constraint verification is used to estimate whether the end-to-end response time of the agent workflow meets the service level agreement based on the performance benchmark of the bound capability units.

11. The method according to any one of claims 1-7, characterized in that, Also includes; The operational semantics of the nodes in the intelligent agent workflow are translated into Satisfiability Modulus Theory (SMT) formulas to obtain a set of SMT formulas. The satisfiability of the formulas in the SMT formula set was verified using the Z3 SMT solver. If the satisfiability of the SMT formula set is satisfiable, then the invariants under all execution paths in the agent workflow are valid, and the satisfiability verification is passed. If the satisfiability of the formula set is unsatisfiable, then the agent workflow fails the satisfiability verification and returns a counterexample assignment that invalidates the invariant.

12. A blueprint-driven intelligent agent generation device, characterized in that, include: The intent acquisition module is used to acquire intent information, which is either input by the user or comes from an intent template converted from an external case. The blueprint generation module is used to generate a dual-view blueprint consisting of a visual flowchart and a structured specification document based on the intent information; wherein the visual flowchart and the structured specification document are synchronized in real time through a node identifier association table. The intent parsing module is used to parse the dual-view blueprint to obtain the node intent of each node; The matching and binding module is used to match and bind capability units for each node intent from the capability unit knowledge base, and obtain a set of deterministic node intermediate representations; The agent generation module is used to generate an agent workflow for execution on the large language model operation and maintenance platform based on the deterministic node intermediate representation set. The agent workflow includes a dual-form deliverable of an application chain graph and executable code.

13. An electronic device, characterized in that, include: At least one processor; A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the blueprint-driven agent generation method as described in any one of claims 1-11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the blueprint-driven agent generation method as described in any one of claims 1-11.

15. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the blueprint-driven agent generation method as described in any one of claims 1-11.

Images