A natural language driven intelligent agent workflow orchestration method and system

Abstract

The application discloses a natural language driven intelligent agent workflow arrangement method and system, comprising: responding to the user's workflow demand text, and constructing an initial context prompt word input into a large language model to identify the identification information of the target component; according to the identification information, obtaining port configuration details and usage guide from the component registration library as needed, and inputting them into the large language model again to generate a structured patch operation sequence, and applying each patch operation to the blueprint intermediate representation object; incrementally compiling the updated blueprint intermediate representation object into target workflow JSON data; calculating the incremental difference between the target workflow JSON data obtained this time and the previous result, and generating corresponding local rendering instructions to drive the front-end canvas to only update and render the changed part in real time. The application significantly improves the generation accuracy of LLM, reduces the context Token consumption, and realizes real-time visual collaboration.

Description

Technical Field

[0001] This application relates to the interdisciplinary field of artificial intelligence and software engineering, specifically to a method and system for orchestrating intelligent agent workflows based on natural language. Background Technology

[0002] An AI agent is a computational entity capable of perceiving its environment, autonomously planning, invoking tools, and executing complex goals. Unlike large language models that only perform single-round question-and-answer sessions, AI agents possess a closed-loop capability of "thinking-acting-observing": they can break down abstract tasks into multi-step plans, dynamically invoke external APIs, databases, or code interpreters to obtain information, and reflect on and adjust strategies based on execution results. By introducing long-term and short-term memory, AI agents can continuously optimize their behavior through iteration, thereby completing complex processes that previously required step-by-step human intervention, such as automated research, code generation, and cross-system business orchestration, in open and uncertain environments.

[0003] Currently, mainstream AI Agent workflow orchestration platforms (such as Dify, Coze, LangFlow, etc.) face the following core challenges:

[0004] 1. The Dilemma of Directly Manipulating Target Formats in LLM

[0005] Existing solutions typically allow the Large Language Model (LLM) to directly generate a complete workflow JSON structure. However, this JSON contains a large amount of UI information unrelated to business logic (such as node coordinates, UUIDs, port connection metadata, style attributes, etc.), which causes the LLM to generate a lot of redundant information and has low accuracy. At the same time, modifying a simple piece of logic requires developers to understand hundreds of lines of JSON structure, and since incremental modifications cannot be implemented, a full regeneration must be performed each time.

[0006] 2. The token explosion problem of component knowledge

[0007] Current technology injects the complete definitions (ports, configuration items, documentation) of all available components into the LLM context at once, resulting in massive token consumption. For example, with 40 components, the full JSON would consume approximately 30,000 tokens, while in practice, tasks typically only require detailed information for 3-5 components.

[0008] 3. Black-box experience of the generation process

[0009] In existing technologies, when LLM generates workflows, users have to wait for the "wait-all-time presentation" experience, which does not conform to the "director-style collaboration" interaction paradigm.

[0010] 4. Hard-coding issues in component systems

[0011] Existing solutions typically hardcode component knowledge (port definitions, configuration constraints) in the code, which requires code modification and redeployment when adding or modifying components, and cannot achieve runtime expansion of the component ecosystem. Summary of the Invention

[0012] To address this, this application provides a natural language-driven intelligent agent workflow orchestration method to solve the problems of low generation accuracy, high context token consumption, and lack of real-time visual feedback in the generation process caused by large language models directly manipulating complete workflow JSON in existing technologies.

[0013] To achieve the above objectives, this application provides the following technical solution:

[0014] Firstly, a natural language-driven intelligent agent workflow orchestration method includes:

[0015] Step S1: Obtain the workflow requirement text described by the user in natural language;

[0016] Step S2: In response to the workflow requirement text, construct initial context prompts and input them into the large language model; the initial context prompts contain at least the grammar rules required for workflow orchestration and a summary of the available components, so that the large language model outputs identification information of at least one target component identified in the workflow requirement text;

[0017] Step S3: Based on the identification information of the target component output by the large language model, retrieve the port configuration details and usage guide of the target component from the component registration library as needed, and input the port configuration details and usage guide as supplementary context back into the large language model so that the large language model generates a structured patch operation sequence for the workflow requirement text;

[0018] Step S4: Receive the structured patch operation sequence generated by the large language model, and apply each patch operation to a variable blueprint intermediate representation object in sequence, thereby driving the state change of the blueprint intermediate representation object; wherein, the blueprint intermediate representation object is a workflow abstraction independent of user interface rendering information, and at least includes node aliases, node types, node configurations, and connection relationships between nodes;

[0019] Step S5: Whenever a patch operation is successfully applied, immediately use the stability identification strategy to incrementally compile the updated blueprint intermediate representation object into target workflow JSON data containing complete user interface information and deterministic identifiers;

[0020] Step S6: Calculate the incremental difference between the target workflow JSON data obtained in this compilation and the previous compilation result. The incremental difference includes at least the addition of nodes, deletion of nodes, changes in node configuration, addition of connections, and deletion of connections.

[0021] Step S7: Generate corresponding local rendering instructions based on the incremental differences, and drive the front-end canvas to update and render only the parts that have changed in real time.

[0022] Preferably, the initial contextual cue words in step S2 are constructed using a multi-level progressive contextual disclosure mechanism, specifically including:

[0023] Level L0: Always provides the large language model with the syntax rules required for the workflow orchestration, including meta-information declaration syntax, node definition syntax, and connection syntax;

[0024] Level L1: Always provide the large language model with a directory summary of all available components. The directory summary of each component shall include at least the component name, component type identifier, one-line functional description, and summary information of the component’s connectable input ports and connectable output ports.

[0025] Level L2: After the large language model outputs the identification information of the target component, the port configuration details of the target component are loaded as needed. The port configuration details include at least a list of configured ports, a list of connectable input ports, and a list of connectable output ports. Each item includes a port key, data type, and field description.

[0026] Level L3: When the large language model needs to connect to a reference, the user guide of the target component is loaded as needed. The user guide includes at least port semantic descriptions, business meanings of key configurations, DSL code snippets for typical scenarios, standard connection modes with upstream and downstream components, and configuration tuning suggestions.

[0027] Preferably, the large language model interacts with the system using an autonomous agent architecture with a reasoning-action-observation loop pattern. This autonomous agent architecture provides the large language model with the following four callable utility functions:

[0028] A function to retrieve component details is used to trigger the loading of the L2 level information;

[0029] A function to retrieve component usage guidelines is used to trigger the loading of the L3 level information;

[0030] Apply patch operation functions to generate the structured patch operation sequence;

[0031] A completion marker function is used to indicate the end of the workflow building process;

[0032] The large language model autonomously determines the order and parameters of calling various tool functions within the loop, gradually acquiring component knowledge and building a workflow.

[0033] Preferably, the structured patch operation sequence includes at least one or more combinations of the following seven atomic operations: add node operation, delete node operation, update node configuration operation, rename node operation, add connection operation, delete connection operation, and update workflow metadata operation.

[0034] Preferably, the component registration library used in step S3 adopts a data-driven, zero-hard-coded component registration system, wherein: the component definition is loaded from the backend API at runtime, the port role of each component in the component registration library is determined by the type field in the data, the component registration library supports runtime extension of dynamic resources, the dynamic resources include custom tools, MCP protocol tools and sub-agents, and the dynamic resources automatically participate in the generation of component directory summary and context construction after being loaded at runtime, without the need for front-end code changes.

[0035] Preferably, the stable identification strategy in step S5 is as follows: node identifiers are generated using a deterministic hash function based on a combination of their corresponding component type and node alias; edge identifiers are generated using a deterministic concatenation function based on a combination of their source port identifier and target port identifier; the deterministic hash function and deterministic concatenation are used to generate identifiers during the incremental compilation process to ensure that two compilations of the same blueprint representing an object produce completely identical identifier sets; when the final exported target workflow JSON data is used for persistent storage, the deterministic identifiers are switched to random universally unique identifiers.

[0036] Preferably, in step S5, during the incremental compilation of the updated blueprint intermediate representation object into target workflow JSON data containing complete user interface information and deterministic identifiers, an automatic layout step is also included: constructing a directed acyclic graph based on the connection relationships in the blueprint intermediate representation object, determining the level of each node through topological sorting, arranging nodes at equal horizontal intervals within the same level, and arranging nodes at different levels vertically at fixed intervals, thereby automatically generating the coordinate information of each node.

[0037] Preferably, steps S4 and S5 are implemented using a streaming session engine, which maintains the following states: the current blueprint intermediate representation object, a snapshot of the target workflow JSON data obtained from the previous compilation, an operation step counter, a history stack for undoing operations, and a redo stack for redoing operations. The streaming session engine supports asynchronous stream integration and can directly consume the streaming form of the structured patch operation sequence output by the large language model through a network streaming protocol, apply patch operations one by one, and trigger incremental difference calculation and local rendering update after each patch application.

[0038] Preferably, the method also includes an incremental modification step for existing workflows: in response to the user's intention to modify existing workflows or the need to adjust the current workflow, the current target workflow JSON data is reverse-compiled into the corresponding blueprint intermediate representation object using a reverse compiler, the blueprint intermediate representation object is then serialized into domain-specific language text, and the domain-specific language text is injected into the context of the large language model as a representation of the current state of the workflow, so as to guide the large language model to generate an incremental patch operation sequence for the existing workflow.

[0039] Secondly, a natural language-driven intelligent agent workflow orchestration system includes:

[0040] The requirement elicitation module is used to obtain the workflow requirement text described by the user in natural language;

[0041] An initial context building module is used to construct initial context prompts in response to the workflow requirement text and input them into a large language model; the initial context prompts include at least the grammar rules required for workflow orchestration and a summary of the available components, so that the large language model outputs identification information of at least one target component identified in the workflow requirement text;

[0042] The supplementary context loading module is used to retrieve the port configuration details and usage guidelines of the target component from the component registry as needed based on the identification information of the target component output by the large language model, and input the port configuration details and usage guidelines as supplementary context back into the large language model so that the large language model can generate a structured patch operation sequence for the workflow requirement text;

[0043] The patch application module is used to receive the structured patch operation sequence generated by the large language model, and apply each patch operation to a variable blueprint intermediate representation object in sequence, thereby driving the state change of the blueprint intermediate representation object; wherein, the blueprint intermediate representation object is a workflow abstraction independent of user interface rendering information, and at least includes node aliases, node types, node configurations, and connection relationships between nodes;

[0044] The incremental compilation module is used to incrementally compile the updated blueprint intermediate representation object into target workflow JSON data containing complete user interface information and deterministic identifiers immediately after a patch operation is successfully applied, using a stable identification strategy.

[0045] The incremental difference calculation module is used to calculate the incremental difference between the target workflow JSON data obtained in this compilation and the previous compilation result. The incremental difference includes at least the addition of nodes, deletion of nodes, node configuration changes, addition of connections and deletion of connections.

[0046] The local rendering driver module is used to generate corresponding local rendering instructions based on the incremental differences, and drive the front-end canvas to update and render only the parts that have changed in real time.

[0047] Compared with the prior art, this application has at least the following beneficial effects:

[0048] 1. This application provides a natural language-driven intelligent agent workflow orchestration method, comprising: responding to the user's workflow requirement text and constructing initial context prompts, inputting them into a language model to identify the identification information of the target component; based on the identification information, retrieving the port configuration details and usage guidelines of the target component from the component registry as needed, and inputting them again into a large language model to generate a structured patch operation sequence, applying each patch operation to the blueprint intermediate representation object; whenever a patch operation is successfully applied, immediately incrementally compiling the updated blueprint intermediate representation object into target workflow JSON data containing complete user interface information and deterministic identifiers; calculating the incremental difference between the target workflow JSON data obtained in this compilation and the previous compilation result, and generating corresponding local rendering instructions to drive the front-end canvas to only update and render the changed parts in real time. This application significantly improves the generation accuracy of LLM and reduces the consumption of context tokens by introducing a blueprint intermediate representation layer to decouple UI information, adopting a multi-level progressive context to load component knowledge on demand, and combining a streaming conversation engine with incremental differential rendering, thereby realizing real-time visual collaboration.

[0049] 2. By adopting a data-driven, zero-hard-coded component registration system, the component ecosystem can be expanded arbitrarily. New components can be automatically integrated into the workflow orchestration system without modifying the front-end code.

[0050] 3. The streaming session engine achieves a low-latency, traceable, and highly interactive real-time workflow orchestration experience through patch streaming application, stable ID incremental compilation, and local differential rendering.

[0051] 4. This application allows for incremental modifications to existing workflows, avoiding information loss and token waste caused by full regeneration, and supports undo / redo, providing complete version management capabilities. Attached Figure Description

[0052] To more intuitively illustrate the prior art and this application, exemplary drawings are provided below. It should be understood that the specific shapes and structures shown in the drawings should not generally be regarded as limiting conditions for implementing this application; for example, based on the technical concept disclosed in this application and the exemplary drawings, those skilled in the art are able to easily make conventional adjustments or further optimizations to the addition / reduction / classification, specific shapes, positional relationships, connection methods, size ratios, etc. of certain units (components).

[0053] Figure 1 A flowchart of a natural language-driven intelligent agent workflow orchestration method provided in Embodiment 1 of this application;

[0054] Figure 2 This is an overall architecture diagram of a natural language-driven intelligent agent workflow orchestration method provided in Embodiment 1 of this application;

[0055] Figure 3 This is a schematic diagram of the four-level context content structure and data source provided in Embodiment 1 of this application;

[0056] Figure 4 A schematic diagram comparing the four-level progressive context disclosure and token consumption provided in Embodiment 1 of this application;

[0057] Figure 5 This is a flowchart of the ReAct autonomous agent workflow provided in Embodiment 1 of this application;

[0058] Figure 6 The Blueprint intermediate presentation layer and bidirectional compilation pipeline provided in Embodiment 1 of this application;

[0059] Figure 7 This is a schematic diagram of the closed transformation loop of the bidirectional compiler system provided in Embodiment 1 of this application;

[0060] Figure 8 This is a schematic diagram of the streaming session engine and incremental Delta rendering provided in Embodiment 1 of this application;

[0061] Figure 9 This is a schematic diagram of the incremental Delta calculation process provided in Embodiment 1 of this application. Detailed Implementation

[0062] The present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0063] In the description of this application: unless otherwise stated, "a plurality of" means two or more. The terms "first," "second," "third," etc., in this application are intended to distinguish the objects referred to and do not have any special meaning in terms of technical connotation (e.g., they should not be construed as an emphasis on importance or order). Expressions such as "including," "comprising," and "having" also mean "not limited to" (certain units, components, materials, steps, etc.).

[0064] The terms used in this application, such as "upper," "lower," "left," "right," and "middle," are generally used to indicate the general relative positional relationship for the purpose of intuitive understanding by referring to the accompanying drawings, and are not absolute limitations on the positional relationship in the actual product.

[0065] The definitions of the terms used in this invention are shown in Table 1:

[0066] Table 1

[0067]

[0068] Example 1

[0069] Please see Figure 1 and Figure 2 This embodiment provides a natural language-driven intelligent agent workflow orchestration method, including:

[0070] S1: Obtain the user's workflow requirements text described in natural language;

[0071] S2: In response to the workflow requirement text, construct initial contextual cue words and input them into the large language model; the initial contextual cue words contain at least the grammar rules required for workflow orchestration and a summary of the available components, so that the large language model outputs identification information of at least one target component identified in the workflow requirement text;

[0072] Specifically, the initial contextual clues in this step are constructed using a multi-level progressive contextual disclosure mechanism, including levels L0, L1, L2, and L3, such as... Figure 3 As shown.

[0073] Level L0: Always provides the grammar rules required for workflow orchestration to the large language model. The grammar rules include meta-information declaration syntax, node definition syntax, and connection syntax.

[0074] More specifically, Level 0 is a fixed, always-loaded DSL (Domain-Specific Language) syntax specification (i.e., reference) that provides the DSL text format syntax rules, enabling the LLM to understand how to write valid workflow descriptions. Its structure consists of three parts:

[0075] Metadata syntax: Metadata declaration methods such as @workflow "name";

[0076] The node definition syntax is: `node <alias> = <component type> {configuration}`, which follows the declaration structure and configuration value rules.

[0077] Connection syntax: <alias>.<port> -> <alias>.<port> port connection rules and type constraints.

[0078] L0 is a fixed text that does not change with the number of components, approximately 200 tokens.

[0079] In this embodiment, the domain-specific language (DSL) optimized for large language models has the following characteristics:

[0080] 1. The syntax structure is as follows:

[0081] Plain Text

[0082] @workflow "workflow name"

[0083] @intro "Function Description"

[0084] @guides ["Guiding Question 1", "Guiding Question 2"]

[0085] node <alias> = <component type> {

[0086] Configuration item: Value

[0087] Multiline text: """

[0088] Long text content

[0089] """

[0090] }

[0091] <source alias>.<output port> -> <destination alias>.<input port>

[0092] 2. LLM-friendly design

[0093] The declarative structure, with each line containing a meaningful semantic unit, reduces the difficulty of understanding and generating the LLM structure; only non-default configuration items need to be written, reducing the amount of LLM generated; using human-readable short aliases (such as chat, kb) instead of UUIDs can improve the semantic understanding capability of the LLM; port connections use the intuitive alias.port -> alias.port syntax, which can be directly mapped to directed graph semantics; and internationalization tags ([i18n]) are supported to guide the LLM to generate multilingual data on the correct fields.

[0094] 3. Internationalized field tagging system

[0095] In DSL, configuration fields are distinguished into two types of values ​​by the [i18n] flag:

[0096] For user-visible text that needs to be localized, such as systemPrompt, text, and label, the LLM should generate it using the user's conversational language.

[0097] System identifiers, such as moduleType, port key, and model, should always retain their original values ​​and not be translated.

[0098] This tagging system enables LLM to accurately determine which fields require multilingual adaptation, avoiding two common errors: "translating identifiers that should not be translated" or "missing user text that should be translated".

[0099] 4. DSL parsing fault tolerance mechanism

[0100] Because the DSL text generated by LLM may contain syntax errors (mismatched brackets, missing quotation marks, formatting deviations, etc.), the DSL parser adopts a best-effort parsing strategy, which includes: parsing line by line, where errors in one line do not affect the parsing of other lines; parsing identified metadata, node definitions, and connections independently; reporting the error location and suggested corrections while returning the parsing results; and feeding back error information to LLM for automatic correction and retry.

[0101] 5. Bidirectional serialization

[0102] Lossless bidirectional conversion between DSL text and Blueprint:

[0103] serialize(Blueprint) → DSL Text: Converts a Blueprint to an LLM-readable and writable text format;

[0104] deserialize(DSL text) → Blueprint: Parses and restores the DSL text generated by LLM into a Blueprint object.

[0105] Level L1: Always provide a catalog summary of all available components to the large language model. The catalog summary of each component includes at least the component name, component type identifier, one-line functional description, and summary information of the component's connectable input ports and connectable output ports.

[0106] More specifically, L1 level—component directory summary (all components, always loaded): L1 level is automatically generated by the system from the component registry, listing all available components by category. Each component entry contains:

[0107] Component name and component type identifier (moduleType);

[0108] A one-line feature description (intro);

[0109] Connectable Port Summary: List of input ports (key:valueType format) and list of output ports (key:valueType format). Only connectable ports (type=target / source) are listed, excluding configuration ports.

[0110] Example structure:

[0111] Plain Text

[0112] ## Module

[0113] - Intelligent Dialogue (`aiChat`): Utilizes a large language model for multi-turn dialogue.

[0114] in=[switch:boolean,text:string,knSearch:search]

[0115] out=[answerText:string, finish:boolean]

[0116] - Knowledge base search: Retrieves similar content from related knowledge bases.

[0117] in=[switch:boolean,text:string]

[0118] out=[isEmpty:boolean, unEmpty:boolean, quoteQA:search]

[0119] L1 enables LLM to view the names, functions, and port summaries of all components at a very low token cost, thereby determining which components a task requires. Each component costs approximately 30 tokens, and 40 components cost approximately 1,200 tokens.

[0120] Level L2: After the large language model outputs the identification information of the target component, the port configuration details of the target component are loaded as needed. The port configuration details include at least a list of configured ports, a list of connectable input ports, and a list of connectable output ports. Each item includes a port key, data type, and field description.

[0121] More specifically, L2 level—component port / configuration details (specific components, loaded on demand): When the LLM decides to use certain components, it loads the L2 details of those components on demand. L2 is also automatically generated from the component registry and contains the complete structured definition of the component.

[0122] Configuration port list: Each item includes a key, data type, default value, whether it is required, and field description;

[0123] List of connectable input ports: Each item includes a key, data type, and field description;

[0124] List of connectable output ports: Each item includes a key, data type, and field description.

[0125] Example structure:

[0126] Plain Text

[0127] ## Intelligent Dialogue (aiChat)

[0128] Multi-turn dialogue using a large language model

[0129] Config:

[0130] - model: string [required] / / Model selection

[0131] - systemPrompt: string = "" / / System prompt

[0132] - temperature: number = 0 / / Creativity 0~1

[0133] - maxToken: number = 3000 / / Maximum number of reply tokens

[0134] Inputs (connectable):

[0135] - switch: boolean / / AND activate

[0136] - text: string / / Input information

[0137] - knSearch: search / / Knowledge base search results

[0138] Outputs (connectable):

[0139] - answerText: string / / AI reply content

[0140] - finish: boolean / / Execution complete

[0141] L2 enables the LLM to know the exact key, type, and meaning of each port, thereby correctly generating node configurations and connection statements, approximately 150 tokens per component.

[0142] Level L3: When a large language model needs to connect to a reference, load the user guide for the target component on demand. The user guide should include at least the port semantics, the business meaning of key configurations, DSL code snippets for typical scenarios, standard connection modes with upstream and downstream components, and configuration tuning suggestions.

[0143] More specifically, Level 3—Component Usage Guide (Specific Component, Loaded on Demand): Level 3 is the most detailed level, with content derived from structured component usage documentation. Each document uses a consistent hierarchical format.

[0144] Document header (metadata area): Contains component identifier name and functional description summary, used for L1 level indexing and AI component discovery and matching;

[0145] Document body (body area): Organized according to a fixed chapter structure, including:

[0146] Port description: More detailed port semantic descriptions than L2, including service relationships between ports;

[0147] Key configurations: Business meanings, suggested values, and data structure descriptions for configuration fields;

[0148] DSL Examples: Complete DSL code snippets for 2-3 typical scenarios (e.g., "Basic Search", "High-Precision Search", "Multi-Knowledge Base Search");

[0149] Common connection patterns: Standard connection combinations and explanations with upstream and downstream components (such as the three-node pattern of "knowledge base search + AI dialogue + fallback response").

[0150] Best practices: Configuration tuning recommendations and common pitfalls.

[0151] Level 3 document format allows the same document to serve two purposes simultaneously:

[0152] After the metadata area is extracted by the system, it participates in the generation of the L1 level component directory (discovery phase).

[0153] The text area is loaded as an L3 context (consumption phase) on demand when AI needs it.

[0154] This "one document, layered extraction" design avoids maintaining multiple documents with different granularities while ensuring the consistency of information at all levels.

[0155] This embodiment is implemented using a streaming API through a context builder:

[0156] Plain Text

[0157] context = contextBuilder()

[0158] .dslSyntax() / / L0: DSL Syntax

[0159] .catalog('summary') / / L1: Component

[0160] .componentDetail('aiChat') / / L2: Port configuration

[0161] .componentUsage('aiChat') / / L3: Usage Guide

[0162] .existingWorkflow(currentDSL) / / Current workflow context

[0163] .dynamicResources() / / Dynamic resource directory

[0164] .build()

[0165] Taking a 40-component platform and a task involving 4 components as an example, the token consumption of this mechanism is as follows: Figure 4 As shown in Table 2:

[0166] Table 2

[0167]

[0168] In this embodiment, please refer to Figure 5 When the large language model interacts with the system, it adopts an autonomous agent architecture based on the Reason-Act-Observe (ReAct) loop. The autonomous agent architecture provides the large language model with the following four callable utility functions, as shown in Table 3:

[0169] Table 3

[0170]

[0171] Among them, the function to get component details (get_component_detail) is used to trigger the loading of L2 level information; the function to get component usage guidelines (get_component_usage) is used to trigger the loading of L3 level information; the function to apply patch operations (apply_patches) is used to generate a structured patch operation sequence; the function to mark completion (finish) is used to indicate the end of the workflow construction process; the large language model autonomously determines the order and parameters of calling each tool function in the loop, gradually acquiring component knowledge and building the workflow.

[0172] Example of a self-planning and execution cycle:

[0173] Plain Text

[0174] Input: User's natural language requirements

[0175] System prompt: DSL syntax (L0) + component directory (L1)

[0176] cycle{

[0177] Think: LLM analyzes the current state and determines the next action.

[0178] Act: LLM selects utility functions and provides parameters.

[0179] Observe: Executes utility functions and returns the results to the LLM.

[0180] If the LLM calls finish → exit the loop

[0181] }

[0182] Example of a progressive knowledge acquisition process:

[0183] In a typical generative session, the knowledge acquisition path driven by the LLM's self-driving mechanism is as follows:

[0184] Plain Text

[0185] Round 1: Think("requires questionInput, aiChat, knowledgesSearch, confirmreply")

[0186] →Act(get_component_detail(["questionInput", "aiChat", ...])) / / L2

[0187] → Observe (port and configuration details) Round 2: Think ("Need to understand the connection modes of aiChat and knowledgesSearch")

[0188] →Act(get_component_usage(["aiChat", "knowledgesSearch"])) / / L3

[0189] → Observe (Usage Guide and Wiring Examples)

[0190] Round 3: Think("Start building, first set metadata")

[0191] → Act(apply_patches([{op: 'updateMeta', ...}]))

[0192] →Observe("Step0: Update workflow information")

[0193] / / → Session DeltaRound 4-N: Think → Act(apply_patches) → Observe → Session Delta → UI Rendering

[0194] ...Add nodes and connections gradually...

[0195] Round N+1: Think("All nodes and connections are in place")

[0196] → Act(finish())

[0197] → Session.complete() → Final workflow export

[0198] Each apply_patches call triggers a Delta event through the session engine to notify the front-end canvas, enabling a real-time collaborative experience of "AI thinking one step → canvas updating one step".

[0199] S3: Based on the identification information of the target component output by the large language model, retrieve the port configuration details and usage guidelines of the target component from the component registry as needed, and input the port configuration details and usage guidelines as supplementary context back into the large language model so that the large language model can generate a structured patch operation sequence for the workflow requirement text;

[0200] Specifically, the component registration library used in this step adopts a data-driven, zero-hard-coded component registration system, in which: component definitions are loaded from the backend API at runtime; the port role of each component in the component registration library is determined by the type field in the data; the component registration library supports runtime extension of dynamic resources, including custom tools, MCP protocol tools, and sub-agents; after being loaded at runtime, dynamic resources automatically participate in the generation of component directory summaries and context construction without requiring changes to the frontend code.

[0201] More specifically, this step employs a fully data-driven component system, where component definitions are loaded from the backend at runtime, and the SDK does not contain any hard-coded component knowledge.

[0202] 1. Component Registry

[0203] Plain Text

[0204] Component registry = {

[0205] Static components: Loaded from the backend API (utility components, module components)

[0206] Dynamic resources: loaded at runtime (custom tools, MCP server, sub-agents)

[0207] User Guide: Load on Demand

[0208] }

[0209] 2. Port Role Recognition

[0210] The role determination of a component port is entirely driven by the type field in the data:

[0211] type = "target" → Allows connection to input ports;

[0212] type = "source" → Allows connection to output ports (including the targets connection array);

[0213] Other values ​​→ Configure input port (user-entered value).

[0214] 3. Connection validity verification

[0215] Port connections require three levels of verification:

[0216] Redirection verification: The source port must be of type = "source", and the destination port must be of type = "target", otherwise the connection will be rejected;

[0217] Type compatibility check: The valueType of the source port and the valueType of the destination port must be compatible (the same type can be connected, and any can be connected to any type).

[0218] Duplicate detection: Duplicate connections are not allowed between the same source-destination ports.

[0219] 4. Dynamic resource expansion

[0220] Three types of dynamic resources (custom tools, MCP tools, and sub-agents) are loaded into the registry at runtime and automatically participate in directory generation and context construction without requiring any code modification.

[0221] Specifically, the structured patch operation sequence includes at least one or more combinations of the following seven atomic operations: add node operation, delete node operation, update node configuration operation, rename node operation, add connection operation, delete connection operation, and update workflow metadata operation, as shown in Table 4:

[0222] Table 4

[0223]

[0224] S4: Receives the structured patch operation sequence generated by the large language model, and applies each patch operation to a mutable blueprint intermediate representation object in turn, thereby driving the state change of the blueprint intermediate representation object; wherein, the blueprint intermediate representation object is a workflow abstraction independent of user interface rendering information, and at least includes node aliases, node types, node configurations and connection relationships between nodes;

[0225] Specifically, this step introduces Blueprints as an intermediate representation layer for the workflow and defines a ternary structure:

[0226] Plain Text

[0227] Blueprint = {

[0228] meta: Workflow metadata (name, description, guiding questions, etc.)

[0229] nodes: A dictionary of nodes (alias → {moduleType, config})

[0230] connections: An array of connections ({from: "alias.port", to: "alias.port"})

[0231] }

[0232] Blueprint is completely decoupled from the UI and does not contain rendering information such as node coordinates, UUIDs, and port metadata. Based on this intermediate layer, this embodiment constructs a bidirectional compilation pipeline, such as... Figure 6 As shown:

[0233] Forward compilation (Compile), i.e. Blueprint → target workflow JSON: The compiler automatically completes the port definition, generates node UUIDs and layout coordinates, and builds the edge data structure based on the component registry;

[0234] Reverse compilation, i.e., target workflow JSON → Blueprint: The reverse compiler strips away the UI information, extracts the logical structure, and restores the UUID to a human-readable short alias through alias mapping.

[0235] This bidirectional compiler architecture implements a closed transformation loop, such as Figure 7 As shown, LLM only needs to manipulate lightweight Blueprint or DSL text, while the compiler is responsible for restoring the complete target format. During forward compilation, the compiler constructs a directed acyclic graph (DAG) based on the connection relationships of the Blueprint, determines the node hierarchy through topological sorting, arranges nodes at equal horizontal intervals within the same layer, and arranges nodes at fixed intervals between layers vertically. This automatic layout algorithm ensures that the workflow generated by AI has a clear visual hierarchy on the canvas, eliminating the need for manual adjustment of node positions.

[0236] S5: Whenever a patch operation is successfully applied, immediately use the stability identification strategy to incrementally compile the updated blueprint intermediate representation object into target workflow JSON data containing complete user interface information and deterministic identifiers;

[0237] Specifically, the stable identifier strategy is as follows: node identifiers are generated using a deterministic hash function based on a combination of the corresponding component type and the node alias; edge identifiers are generated using a deterministic concatenation function based on a combination of the source port identifier and the target port identifier; during incremental compilation, deterministic hash functions and deterministic concatenation are used to generate identifiers to ensure that two compilations of the same blueprint representing an object produce the exact same set of identifiers; when the final exported target workflow JSON data is used for persistent storage, the deterministic identifiers are switched to random universally unique identifiers.

[0238] This step, which incrementally compiles the updated blueprint intermediate representation object into target workflow JSON data containing complete user interface information and deterministic identifiers, also includes an automatic layout step: constructing a directed acyclic graph based on the connection relationships in the blueprint intermediate representation object, determining the hierarchy of each node through topological sorting, arranging nodes at equal horizontal intervals within the same hierarchy, and arranging nodes at different levels vertically at fixed intervals, thereby automatically generating the coordinate information of each node.

[0239] For more details, please see Figure 8 Steps S4 and S5 are implemented through a streaming session engine, which maintains the following states: the current blueprint intermediate representation object, a snapshot of the target workflow JSON data obtained from the previous compilation, an operation step counter, a history stack for undoing operations, and a redo stack for redoing operations. The streaming session engine supports asynchronous stream integration and can directly consume the streaming form of the structured patch operation sequence output by the large language model through the network streaming protocol, apply the patch operations one by one, and trigger incremental difference calculation and local rendering update after each patch application.

[0240] The streaming session engine maintains the following states: the current blueprint state, the workflow snapshot of the previous compilation (used for incremental Delta calculation), the operation step counter, the operation history stack (used for Undo), and the redo stack (used for Redo).

[0241] S6: Calculate the incremental difference between the target workflow JSON data obtained in this compilation and the previous compilation result. The incremental difference includes at least the addition of nodes, deletion of nodes, changes in node configuration, addition of connections and deletion of connections.

[0242] Specifically, after each apply (patch) operation, the session engine executes the following process: incremental differential calculation (Delta), such as... Figure 9 As shown:

[0243] Plain Text

[0244] 1. Record a snapshot of the blueprint before the change → Push it into the history stack

[0245] 2. Apply the patch to the current blueprint to obtain the new blueprint.

[0246] 3. Compile the new blueprint using the stable ID strategy to obtain the new target workflow.

[0247] 4. Perform a differential comparison with the previous target workflow and calculate Delta:

[0248] - addedNodes: List of newly added nodes

[0249] - removedNodeIds: List of deleted node IDs

[0250] - updatedNodes: List of nodes with configuration changes

[0251] - addedEdges: List of newly added edges

[0252] - removedEdgeIds: List of removed edge IDs

[0253] 5. Emit a change event, carrying {patch, step, blueprint, workflow, delta, description}.

[0254] The front-end canvas subscribes to the change event and performs local rendering updates based on Delta to achieve gradual animation effects: node fade-in, flowing line drawing, and configuration change highlighting.

[0255] However, incremental Delta calculation relies on the premise that two compilations of the same blueprint must produce identical node IDs and edge IDs. Normal compilations generate random UUIDs each time, making differential comparison impossible. Therefore, this embodiment proposes a "stable ID strategy": during compilation within the session engine, node IDs are generated based on a deterministic hash of moduleType + alias, and edge IDs are generated based on a deterministic concatenation of sourceHandle + targetHandle. This ensures that: two compilations of the same blueprint state produce completely identical ID sets; two compilations before and after a blueprint change can precisely match nodes and edges through IDs; and Delta calculations can be efficiently completed through the difference operation of the ID sets. Finally, during export (export()), the strategy switches back to the real UUID strategy to meet backend persistence requirements.

[0256] S7: Generates corresponding local rendering instructions based on incremental differences and drives the front-end canvas to only update and render the parts that have changed in real time.

[0257] Specifically, the session engine supports direct integration with AI streaming interfaces, i.e., asynchronous stream integration:

[0258] Plain Text

[0259] session.feedStream(aiPatchStream) / / Consume AsyncIterable <patch>

[0260] AI outputs patch operations one by one via SSE / WebSocket, and the session engine applies them one by one and triggers Delta events, achieving a real-time collaborative experience where "AI generates a node, and the canvas immediately renders a node".

[0261] The following example further illustrates the natural language-driven intelligent agent workflow orchestration method (generating a knowledge base question-answering workflow from natural language) provided in this embodiment:

[0262] The user inputs: "Help me create a knowledge-based intelligent customer service that can automatically search product documents to answer user questions and provide friendly prompts when no results are found."

[0263] Step 1, Initialization: Load component definitions from the backend API, create a WorkflowDSL instance and component registry; build prompt words, including L0 (DSL syntax) and L1 (component catalog summary), approximately 1,400 tokens.

[0264] Step 2, AI analyzes intent and obtains component details (L2): AI analyzes user intent and identifies the following components needed: questionInput (user input), knowledgesSearch (knowledge base search), aiChat (AI dialogue), and confirmreply (fallback reply). The get_component_detail function is called to obtain the port and configuration details of these four components.

[0265] Step 3, AI obtains key component usage guidelines (L3): AI further calls get_component_usage to obtain the connection mode guidelines between aiChat and knowledgesSearch, and understands key connection modes such as kb.quoteQA → chat.knSearch and kb.unEmpty → chat.switch.

[0266] Step 4, AI gradually builds the workflow: AI issues the following patch operations in sequence, and each operation triggers a real-time canvas update through the session engine:

[0267] Plain Text

[0268] Step 0: updateMeta → Set the workflow name "Intelligent Customer Service Assistant", description, and guiding question.

[0269] Step 1: addNode "input" (questionInput) → Render the input node on the canvas.

[0270] Step 2: addNode "kb" (knowledgesSearch) → Render the knowledge base node on the canvas.

[0271] Step 3: addNode "chat" (aiChat) → Render AI Dialogue Node on Canvas

[0272] Step 4: addNode "fallback" (confirmreply) → Canvas rendering fallback reply node

[0273] Step 5: addConnection input.userChatInput → kb.text → Connection animation

[0274] Step 6: addConnection input.userChatInput → chat.text → Connection animation

[0275] Step 7: addConnection kb.unEmpty → chat.switch → Connection Animation

[0276] Step 8: addConnection kb.quoteQA → chat.knSearch → Connection Animation

[0277] Step 9: addConnection kb.isEmpty → fallback.switch → Connection animation

[0278] Step 10: finish() → Full image blinking confirms completion

[0279] Step 5: Export the final workflow.

[0280] Calling session.export() generates a target workflow JSON containing the real UUID, complete port definition, and layout coordinates, which can be directly used for platform saving and execution.

[0281] This embodiment provides a natural language-driven intelligent agent workflow orchestration method, which further includes the step of incrementally modifying existing workflows: in response to the user's intention to modify existing workflows or the need to adjust the current workflow, the current target workflow JSON data is reverse-compiled into the corresponding blueprint intermediate representation object by a reverse compiler, and then the blueprint intermediate representation object is serialized into domain-specific language text. The domain-specific language text is injected into the context of the large language model as a representation of the current state of the workflow, so as to guide the large language model to generate an incremental patch operation sequence for the existing workflow.

[0282] Specifically, this embodiment supports structured incremental modifications to existing workflows, rather than full regeneration, including:

[0283] 1. Reverse pipeline from workflow to context:

[0284] Plain Text

[0285] The existing workflow is: JSON → decompile → Blueprint → serialize → DSL text → AI context.

[0286] LLM sees a complete DSL representation of the current workflow in context, enabling a precise understanding of the existing structure.

[0287] 2. Incremental Patch Generation: Based on the current DSL and the user's modification intentions, LLM generates a structured patch list (rather than a complete new workflow) to achieve precise local modifications.

[0288] 3. Blueprint Differential Algorithm: The system can compare two blueprint versions and automatically calculate the minimum patch set.

[0289] Plain Text

[0290] diff(beforeBlueprint, afterBlueprint) → patches[]

[0291] The differential algorithm detects the following change types: newly added / deleted nodes (based on alias matching), nodes with configuration changes (based on configuration field depth comparison), newly added / deleted connections (based on port signature matching), and metadata changes.

[0292] The following example illustrates how to incrementally modify an existing workflow.

[0293] Scenario: The user already has the above knowledge base question-and-answer workflow, and now requests "add an online search node, so that if the knowledge base cannot be found, the user searches online first and then answers the question".

[0294] Step 1, reverse compile to obtain the current DSL: convert the current workflow JSON into DSL text using decompile + serialize, and inject it into the AI ​​context.

[0295] Step 2, AI generates incremental patches: Based on the current DSL and the user's modification intent, the AI ​​generates the following patches (not a full regeneration):

[0296] Plain Text

[0297] 1. addNode "search" (webSearch) { engine: "bing", maxCount: 5}

[0298] 2. removeConnection kb.isEmpty → fallback.switch

[0299] 3. addConnection kb.isEmpty → search.switch

[0300] 4. addConnection input.userChatInput → search.text

[0301] 5. addConnection search.result → chat.text

[0302] 6. addConnection search.isEmpty → fallback.switch

[0303] Step 3, Apply Patches and Render in Real Time: Each patch is applied through the session engine, and the canvas displays newly added nodes and changes in connections in real time. Users can undo unsatisfactory modifications at any time.

[0304] The natural language-driven intelligent agent workflow orchestration method provided in this embodiment has the following beneficial effects:

[0305] 1. Significantly improved generation efficiency and accuracy: By stripping away redundant UI information through Blueprint IR, the effective generation volume of LLM is reduced by approximately 80%. The DSL text format allows LLM to focus only on business logic semantics, and the workflow can achieve a first-run generation success rate of over 80%.

[0306] 2. Context Token Consumption Reduced by Approximately 90%: The four-level progressive disclosure mechanism reduces token consumption from approximately 30,000 (full) to approximately 3,000 (on demand). In production scenarios where API call costs are critical, this optimization has significant economic value.

[0307] 3. Real-time streaming collaboration experience: The streaming conversation engine enables real-time feedback from "AI generation step to canvas rendering step," breaking the traditional black-box experience of "waiting—one-time presentation." Users can observe, intervene, and correct during the AI ​​generation process.

[0308] 4. Supports any component ecosystem: The data-driven, zero-hard-coding design allows the system to be extended with any component type through backend configuration, including dynamic resources such as custom tools, MCP protocol tools, and sub-agents, without requiring changes to the frontend code.

[0309] 5. Incremental modification instead of full regeneration: The structured patching mechanism allows AI to make precise local modifications to existing workflows, avoiding information loss and token waste caused by full regeneration. It supports undo / redo and has complete version management capabilities.

[0310] 6. Observable and explainable generation process: Each patching operation has a human-readable description, and the complete operation history is traceable and replayable. Combined with Delta events, users can precisely understand what the AI ​​did at each step.

[0311] The performance comparison between the natural language-driven intelligent agent workflow orchestration method provided in this embodiment and traditional methods is shown in Table 5:

[0312] Table 5

[0313]

[0314] In summary, this method introduces a Blueprint Intermediate Representation Layer (Blueprint IR) as a decoupling abstraction between the workflow logic and the rendering layer. It utilizes a Domain-Specific Language (DSL) to enable the Large Language Model (LLM) for efficient generation and understanding of the workflow structure. A multi-level progressive context disclosure mechanism (L0-L3) is employed to inject component knowledge into the AI ​​on demand, significantly reducing context token consumption while ensuring generation quality. A streaming conversation engine is designed to support AI's incremental patching operations, and incremental differential (Delta) drives real-time dynamic rendering of the front-end canvas. A data-driven, zero-hard-coded component registration system and dynamic resource loading mechanism are proposed, enabling adaptation to any component ecosystem and achieving a closed loop of "natural language description of requirements → AI autonomous planning and construction → real-time visualization." Experiments show that this method can reduce AI context token consumption by approximately 90%, reduce generated data volume by approximately 87%, and control incremental rendering latency to within 50ms.

[0315] Example 2

[0316] This embodiment provides a natural language-driven intelligent agent workflow orchestration system, including:

[0317] The requirement elicitation module is used to obtain the workflow requirement text described by the user in natural language;

[0318] An initial context building module is used to construct initial context prompts in response to the workflow requirement text and input them into a large language model; the initial context prompts include at least the grammar rules required for workflow orchestration and a summary of the available components, so that the large language model outputs identification information of at least one target component identified in the workflow requirement text;

[0319] The supplementary context loading module is used to retrieve the port configuration details and usage guidelines of the target component from the component registry as needed based on the identification information of the target component output by the large language model, and input the port configuration details and usage guidelines as supplementary context back into the large language model so that the large language model can generate a structured patch operation sequence for the workflow requirement text;

[0320] The patch application module is used to receive the structured patch operation sequence generated by the large language model, and apply each patch operation to a variable blueprint intermediate representation object in sequence, thereby driving the state change of the blueprint intermediate representation object; wherein, the blueprint intermediate representation object is a workflow abstraction independent of user interface rendering information, and at least includes node aliases, node types, node configurations, and connection relationships between nodes;

[0321] The incremental compilation module is used to incrementally compile the updated blueprint intermediate representation object into target workflow JSON data containing complete user interface information and deterministic identifiers immediately after a patch operation is successfully applied, using a stable identification strategy.

[0322] The incremental difference calculation module is used to calculate the incremental difference between the target workflow JSON data obtained in this compilation and the previous compilation result. The incremental difference includes at least the addition of nodes, deletion of nodes, node configuration changes, addition of connections and deletion of connections.

[0323] The local rendering driver module is used to generate corresponding local rendering instructions based on the incremental differences, and drive the front-end canvas to update and render only the parts that have changed in real time.

[0324] For details on the specific implementation of each module in a natural language-driven intelligent agent workflow orchestration system, please refer to the above description of the limitations of a natural language-driven intelligent agent workflow orchestration method, which will not be repeated here.

[0325] The technical features of the above embodiments can be combined in any way (as long as there is no contradiction in the combination of these technical features). For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described; these embodiments not explicitly written should also be considered to be within the scope of this specification.< / patch>

Claims

1. A natural language-driven intelligent agent workflow orchestration method, characterized in that, include: Step S1: Obtain the workflow requirement text described by the user in natural language; Step S2: In response to the workflow requirement text, construct initial context prompts and input them into the large language model; the initial context prompts contain at least the grammar rules required for workflow orchestration and a summary of the available components, so that the large language model outputs identification information of at least one target component identified in the workflow requirement text; Step S3: Based on the identification information of the target component output by the large language model, retrieve the port configuration details and usage guide of the target component from the component registration library as needed, and input the port configuration details and usage guide as supplementary context back into the large language model so that the large language model generates a structured patch operation sequence for the workflow requirement text; Step S4: Receive the structured patch operation sequence generated by the large language model, and apply each patch operation to a variable blueprint intermediate representation object in sequence, thereby driving the state change of the blueprint intermediate representation object; wherein, the blueprint intermediate representation object is a workflow abstraction independent of user interface rendering information, and at least includes node aliases, node types, node configurations, and connection relationships between nodes; Step S5: Whenever a patch operation is successfully applied, immediately use the stability identification strategy to incrementally compile the updated blueprint intermediate representation object into target workflow JSON data containing complete user interface information and deterministic identifiers; Step S6: Calculate the incremental difference between the target workflow JSON data obtained in this compilation and the previous compilation result. The incremental difference includes at least the addition of nodes, deletion of nodes, changes in node configuration, addition of connections, and deletion of connections. Step S7: Generate corresponding local rendering instructions based on the incremental differences, and drive the front-end canvas to update and render only the parts that have changed in real time.

2. The natural language-driven intelligent agent workflow orchestration method according to claim 1, characterized in that, The initial contextual cue words in step S2 are constructed using a multi-level progressive contextual disclosure mechanism, specifically including: Level L0: Always provides the large language model with the syntax rules required for the workflow orchestration, including meta-information declaration syntax, node definition syntax, and connection syntax; Level L1: Always provide the large language model with a directory summary of all available components. The directory summary of each component shall include at least the component name, component type identifier, one-line functional description, and summary information of the component's connectable input ports and connectable output ports. Level L2: After the large language model outputs the identification information of the target component, the port configuration details of the target component are loaded as needed. The port configuration details include at least a list of configured ports, a list of connectable input ports, and a list of connectable output ports. Each item includes a port key, data type, and field description. Level L3: When the large language model needs to connect to a reference, the user guide of the target component is loaded on demand. The user guide includes at least port semantic descriptions, business meanings of key configurations, DSL code snippets for typical scenarios, standard connection modes with upstream and downstream components, and configuration optimization suggestions.

3. The natural language-driven intelligent agent workflow orchestration method according to claim 2, characterized in that, When the large language model interacts with the system, it adopts an autonomous agent architecture with a reasoning-action-observation loop pattern. The autonomous agent architecture provides the large language model with the following four callable utility functions: A function to retrieve component details is used to trigger the loading of the L2 level information; A function to retrieve component usage guidelines is used to trigger the loading of the L3 level information; Apply patch operation functions to generate the structured patch operation sequence; A completion marker function is used to indicate the end of the workflow building process; The large language model autonomously determines the order and parameters of calling various tool functions within the loop, gradually acquiring component knowledge and building a workflow.

4. The natural language-driven intelligent agent workflow orchestration method according to claim 1, characterized in that, The structured patch operation sequence includes at least one or more combinations of the following seven atomic operations: add node operation, delete node operation, update node configuration operation, rename node operation, add connection operation, delete connection operation, and update workflow metadata operation.

5. The natural language-driven intelligent agent workflow orchestration method according to claim 1, characterized in that, The component registration library used in step S3 adopts a data-driven, zero-hard-coded component registration system, wherein: the component definition is loaded from the backend API at runtime, the port role of each component in the component registration library is determined by the type field in the data, the component registration library supports runtime extension of dynamic resources, the dynamic resources include custom tools, MCP protocol tools and sub-agents, and the dynamic resources automatically participate in the generation of component directory summary and context construction after being loaded at runtime, without the need for front-end code changes.

6. The natural language-driven intelligent agent workflow orchestration method according to claim 1, characterized in that, The stable identification strategy in step S5 is as follows: node identifiers are generated by a deterministic hash function based on the combination of their corresponding component type and node alias; edge identifiers are generated by deterministic concatenation based on the combination of their source port identifier and target port identifier; the deterministic hash function and deterministic concatenation are used to generate identifiers during the incremental compilation process to ensure that two compilations of the same blueprint representing an object produce completely identical identifier sets. When the final exported target workflow JSON data is used for persistent storage, the deterministic identifier is switched to a random universally unique identifier.

7. The natural language-driven intelligent agent workflow orchestration method according to claim 1, characterized in that, In step S5, during the incremental compilation of the updated blueprint intermediate representation object into target workflow JSON data containing complete user interface information and deterministic identifiers, an automatic layout step is also included: constructing a directed acyclic graph based on the connection relationships in the blueprint intermediate representation object, determining the level of each node through topological sorting, arranging nodes at equal horizontal intervals within the same level, and arranging nodes at different levels vertically at fixed intervals, thereby automatically generating the coordinate information of each node.

8. The natural language-driven intelligent agent workflow orchestration method according to claim 1, characterized in that, Steps S4 and S5 are implemented through a streaming session engine, which maintains the following states: the current blueprint intermediate representation object, a snapshot of the target workflow JSON data obtained from the previous compilation, an operation step counter, a history stack for undoing operations, and a redo stack for redoing operations. The streaming session engine supports asynchronous stream integration and can directly consume the streaming form of the structured patch operation sequence output by the large language model through a network streaming protocol, apply patch operations one by one, and trigger incremental difference calculation and local rendering update after each patch application.

9. The natural language-driven intelligent agent workflow orchestration method according to claim 1, characterized in that, It also includes the step of incrementally modifying existing workflows: in response to the user's intention to modify existing workflows or the need to adjust the current workflow, the current target workflow JSON data is reverse-compiled into the corresponding blueprint intermediate representation object by a reverse compiler, and then the blueprint intermediate representation object is serialized into domain-specific language text. The domain-specific language text is injected into the context of the large language model as a representation of the current state of the workflow, so as to guide the large language model to generate an incremental patch operation sequence for the existing workflow.

10. A natural language-driven intelligent agent workflow orchestration system, characterized in that, include: The requirement elicitation module is used to obtain the workflow requirement text described by the user in natural language; An initial context building module is used to construct initial context prompts in response to the workflow requirement text and input them into a large language model; the initial context prompts include at least the grammar rules required for workflow orchestration and a summary of the available components, so that the large language model outputs identification information of at least one target component identified in the workflow requirement text; The supplementary context loading module is used to retrieve the port configuration details and usage guidelines of the target component from the component registry as needed based on the identification information of the target component output by the large language model, and input the port configuration details and usage guidelines as supplementary context back into the large language model so that the large language model can generate a structured patch operation sequence for the workflow requirement text; The patch application module is used to receive the structured patch operation sequence generated by the large language model, and apply each patch operation to a variable blueprint intermediate representation object in sequence, thereby driving the state change of the blueprint intermediate representation object; wherein, the blueprint intermediate representation object is a workflow abstraction independent of user interface rendering information, and at least includes node aliases, node types, node configurations, and connection relationships between nodes; The incremental compilation module is used to incrementally compile the updated blueprint intermediate representation object into target workflow JSON data containing complete user interface information and deterministic identifiers immediately after a patch operation is successfully applied, using a stable identification strategy. The incremental difference calculation module is used to calculate the incremental difference between the target workflow JSON data obtained in this compilation and the previous compilation result. The incremental difference includes at least the addition of nodes, deletion of nodes, node configuration changes, addition of connections and deletion of connections. The local rendering driver module is used to generate corresponding local rendering instructions based on the incremental differences, and drive the front-end canvas to update and render only the parts that have changed in real time.

Images