Lightweight client-oriented service engine dynamic arrangement method and system

Abstract

The application relates to the technical field of computer software and artificial intelligence, and provides a business engine dynamic arrangement method and system for a lightweight client. The method receives user input through a dialogue window and converts the user input into a structured task object, queries a business engine register table after identifying a business intention according to a semantic model, screens a target business processor that is matched and in an activated state, automatically generates an arrangement plan according to the dependence relationship of the processor, executes a time-consuming task by using a state machine and returns progress to the client, performs source, completion state and format verification on a returned result, encapsulates the result into a structured card, and arranges evidence retrieval, deterministic processing, file matching and permission verification processors, returns an answer only when the evidence is valid and access is authorized, or returns a file when a unique target file is determined according to a preset rule and access is authorized, and auditable delivery is realized.

Description

Technical Field

[0001] This application relates to the fields of computer software and artificial intelligence technology, and in particular to a method and system for dynamic orchestration of business engines for lightweight clients. Background Technology

[0002] Currently, there are numerous AI assistant products on lightweight clients (such as mini-programs, H5, PWA, etc.) that can receive user input through dialogue windows and return natural language answers, summaries, or generated content. However, these products typically only handle question-and-answer and search tasks and cannot encapsulate enterprise backend business systems such as quoting, inventory, bill of materials, approval, and drawing generation into standardized service units. They also cannot orchestrate the collaborative execution of multiple business systems within a single dialogue. Adding new business capabilities often requires modifying front-end pages, back-end routes, and interface code, making it difficult to achieve hot-swappable expansion by tenant, version, or industry. Due to the inherent request duration limitations of lightweight clients, time-consuming tasks such as bill of materials calculation, quotation calculation, and drawing generation are prone to timeouts and lack progress feedback. Business data, configuration rules, and delivery documents between different tenants lack isolation mechanisms, and imported price and rule data can be accessed without review, leading to uncontrollable business results. AI may fabricate results when data such as price, inventory, and specifications are missing.

[0003] Because ordinary AI assistants cannot abstract business systems into service units that can be registered, discovered, and orchestrated, business capability expansion requires modification of the routing layer code and cannot be hot-swapped. The request duration limit of lightweight clients makes long-running business processes prone to timeouts and users cannot know the execution progress. In a multi-tenant environment, the lack of a data isolation mechanism makes business data between different tenants visible to each other. Unapproved configuration data is directly called by business systems, resulting in uncontrollable calculation results. AI may fabricate business results when prices, inventory, and approval status are missing.

[0004] Furthermore, in knowledge consultation and document retrieval scenarios, ordinary AI assistants typically only perform text retrieval or directly return file links, without abstracting evidence retrieval, deterministic computation, candidate file matching, permission verification, and result status verification into programmable processors with dependencies. Therefore, it is difficult to add traceable question-and-answer and controlled document delivery capabilities to different industries without modifying the routing code. Summary of the Invention

[0005] Therefore, it is necessary to provide a dynamic orchestration method and system for business engines for lightweight clients to solve the problems in the existing technology that business systems cannot be uniformly scheduled and collaboratively orchestrated through dialogue, business capability expansion requires modification of routing code, long tasks lack progress feedback, and artificial intelligence may fabricate business results.

[0006] Firstly, a method for dynamic orchestration of business engines for lightweight clients is provided. This method involves the lightweight client's dialog window receiving user input, verifying login credentials or platform identity on the server side to determine the authenticated tenant identifier, mapping user permissions and client context, and converting the user input into a structured task object. A semantic model is used to identify the business intent of the structured task object. When key fields are missing, a structured confirmation card is generated to receive supplementary information from the user, and this supplementary information is merged into the structured task object. Based on the intent identification result and the tenant identifier, the business engine registry is queried. Target business processors are filtered according to business intent, authenticated tenant identifier, permission scope, version status, and health status. The business engine registry records one or more of the following for each business processor: processor identifier, capability tag, version, activation status, health status, tenant applicable scope, permission scope, input data structure, output data structure, dependencies, constraint rule set, candidate solution data structure, result verification strategy, timeout strategy, and geographical routing strategy. When the business intent includes knowledge consultation or file acquisition, the business engine... The system filters one or more of the following in the registry: evidence retrieval processor, deterministic business processor, file matching processor, and permission verification processor. The processors, their input / output data structures, and dependencies are identified as nodes to be orchestrated. A task orchestration plan is generated based on the dependencies of the target business processor. The task orchestration plan is executed directly according to the timeout policy of the target business processor, or a task identifier is created and executed by the server-side task state machine. During task execution, the task status and stage progress are returned to the lightweight client. A true status verification is performed on the business results returned by the target business processor, and the format of the business results is verified according to the output data structure. The true status verification includes one or more of the following: data source verification, processing completion status verification, and deliverable accessibility status verification. If the verification fails, an incomplete status is returned. The business results that pass the true status verification are encapsulated into structured business cards or delivery files, and the task identifier, the identifier of the target business processor, and the status of the business results are written into the audit log.

[0007] When the business intent is knowledge consultation or document retrieval, the system can dynamically arrange evidence retrieval processors, deterministic business processors, document matching processors, permission verification processors, and result verification processors based on the registry. This ensures that knowledge responses are bound to valid evidence and deterministic processing results, and that documents are delivered only when the unique target document has been determined by a single candidate or preset selection rule and permission verification has passed.

[0008] Secondly, a dynamic orchestration system for a business engine for lightweight clients is provided. The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the aforementioned dynamic orchestration method for a business engine for lightweight clients.

[0009] Thirdly, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described dynamic orchestration method for a business engine for lightweight clients.

[0010] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described dynamic orchestration method for a business engine for lightweight clients.

[0011] This application utilizes a business engine registry to drive conversational business orchestration. The registry pre-records the input / output data structures, dependencies, and timeout policies of each business processor, enabling registration and discovery of new or modified business capabilities without altering the routing layer code, thus resolving the issue of modifying routing code for business capability expansion. The semantic model converts user input into structured task objects and automatically generates task orchestration plans based on dependencies in the registry. This ensures the execution order of multiple business processors is driven by dependencies, eliminating the need for manual orchestration and hard-coded call logic. During execution, tasks are routed according to timeout policies: short tasks are executed directly, while long tasks are driven by a state machine and return stage progress to the client, preventing task interruption due to request time limits. Business results undergo data source verification, processing completion status verification, and deliverable accessibility verification. The format is also verified based on the output data structure. Results are marked as complete only after all verifications pass, preventing the semantic model from fabricating business results such as prices and inventory. Simultaneously, processor identifiers and result statuses are written to audit logs, ensuring the traceability of each business result.

[0012] Evidence retrieval, deterministic processing, file matching, and permission verification all participate in task orchestration as registrable business processors. Therefore, the same lightweight client can extend the knowledge Q&A and data delivery capabilities of different industries without changing the fixed route. Real-state verification of evidence validity, candidate uniqueness, and access permissions can prevent unsourced answers, erroneous files, and unauthorized files from being returned as completed results. Attached Figure Description

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

[0014] in: Figure 1 This is a flowchart of the dynamic orchestration method for a lightweight client-side business engine in an embodiment of this application; Figure 2 This is the overall architecture diagram of the dynamic orchestration system for a lightweight client-oriented business engine in this application embodiment; Figure 3 This is a flowchart illustrating the business engine registration and invocation process in this application embodiment; Figure 4 This is a schematic diagram of a long task state machine in an embodiment of this application; Figure 5 This is an example diagram of cross-service orchestration in the embodiments of this application; Figure 6 This is a schematic diagram of service routing based on geographic location context in an embodiment of this application; Figure 7 This is a structural block diagram of the server computer device in the embodiments of this application; Figure 8 This is a structural block diagram of the client computer device in an embodiment of this application. Detailed Implementation

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

[0016] Please see Figure 1 As shown, Figure 1 A flowchart illustrating the dynamic orchestration method for a lightweight client-side business engine provided in this application embodiment includes the following steps: Step 01: The lightweight client receives user input through its dialog window. After verifying the login credentials or platform identity on the server side, the server determines the authenticated tenant identifier, maps the user permissions and client context, and converts the user input into a structured task object. Step 02: Identify the business intent of the structured task object through a semantic model, generate a structured confirmation card to receive supplementary information from the user when key fields are missing, and merge the supplementary information into the structured task object; Step 03: Based on the intent recognition results and tenant identifiers, query the business engine registry. Filter target business processors according to business intent, certified tenant identifiers, permission scope, version status, and health status. The business engine registry records one or more of the following for each business processor: processor identifier, capability tag, version, activation status, health status, tenant applicable scope, permission scope, input data structure, output data structure, dependencies, constraint rule set, candidate solution data structure, result verification strategy, timeout strategy, and geographical routing strategy. When the business intent includes knowledge consultation or file acquisition, filter one or more of the following from the business engine registry: evidence retrieval processor, deterministic business processor, file matching processor, and permission verification processor. Then, determine the processors and their input / output data structures and dependencies as nodes to be orchestrated. Step 04: Generate a task orchestration plan based on the dependencies of the target business processor, and execute the task orchestration plan directly according to the timeout policy of the target business processor, or create a task identifier and drive the execution by the server-side task state machine. Step 05: Return the task status and stage progress to the lightweight client during task execution; Step 06: Perform a real status check on the business results returned by the target business processor, and check whether the format of the business results is correct according to the output data structure. The real status check includes one or more of the following: data source check, processing completion status check, and deliverable accessibility status check. If the check fails, return an incomplete status. Step 07: Encapsulate the business results that pass the real status verification into a structured business card or delivery document, and write the task identifier, the identifier of the target business processor, and the status of the business results into the audit log.

[0017] Specifically, in step 01, the lightweight client's dialog window receives user input, which includes one or more of text, voice, images, and file attachments. The client carries login credentials, session tokens, or platform identity information. The server verifies the authenticity and authorization relationship to determine the authenticated tenant identifier. The tenant field passed by the client is not directly used as the basis for tenant identity. Voice input is transcribed into text using Automatic Speech Recognition (ASR) service. Image input is extracted for text and visual features using Optical Character Recognition (OCR) service. File attachments are processed by calling the corresponding parser to extract structured data. All of the above multimodal inputs are uniformly converted into structured task objects, which include business target fields, business parameter fields, fields to be confirmed, and attachment index fields.

[0018] In one implementation, the present invention can interface with enterprise collaboration platforms such as WeChat Work. The enterprise collaboration platform connects to the lightweight client through a channel adapter, performs callback signature verification when receiving user input to verify the legitimacy of the message source; performs message decryption to decrypt the encrypted message body into plaintext; and performs event deduplication and idempotency processing to identify and deduplicate repeated pushes of the same event, preventing the same business request from being processed repeatedly.

[0019] Enterprise collaboration platforms map external contact identities to platform user identities. In one implementation, an external contact in WeChat Work initiates a conversation through a smart chatbot. The system obtains the corresponding platform user identity through the external contact's identifier and establishes a mapping relationship between the enterprise-side user identifier and the system's internal user identifier, ensuring that the same user's conversation history remains consistent between the enterprise collaboration platform and the lightweight client.

[0020] The enterprise collaboration platform binds the session identifier to structured task objects, task identifiers, and delivery documents. In one implementation, bills of materials, quotations, and proposals generated by users in external contact sessions are associated with the current session through the session identifier. When users continue the conversation in the enterprise collaboration platform, they can directly reference historical business results for modification, supplementation, or regeneration.

[0021] Business results are delivered to the enterprise collaboration platform via application messages, interactive cards, robot messages, or embedded web pages. In one implementation, the quotation generated by the quotation processor is sent to the conversation window of the enterprise collaboration platform in the form of an interactive card. The card carries a task identifier, processor identifier, result status, and operation items. Users can click the "View Details" operation item in the card to jump to the embedded web page to view the complete quotation details. The bill of materials generated by the bill of materials processor is sent in the form of application messages, supporting online preview and download by users. The approval card generated by the approval processor can be pushed to the approver via robot messages, allowing the approver to complete the approval operation without jumping to other pages.

[0022] In step 02, the business intent of the structured task object is identified through a semantic model, business parameter fields are extracted from user input, and a list of fields to be confirmed and records of confirmed fields for the structured task object are maintained. When key fields are missing, a structured confirmation card is generated in the dialog window. The structured confirmation card contains field identifiers and a list of candidate options. Users can complete the field supplementation by clicking on candidate options or manually entering them, and the supplemented information is merged into the structured task object.

[0023] In step 03, the business engine registry is queried based on the intent recognition result and tenant identifier. The business engine registry records the processor identifier, capability tag, version, activation status, health status, tenant applicable scope, permission scope, input data structure, output data structure, dependency relationship, constraint rule set, candidate solution data structure, result verification strategy, timeout strategy, and geographical routing strategy for each business processor. The system filters target business processors according to business intent, authenticated tenant identifier, permission scope, version status, and health status. The input data structure is used to verify the parameter integrity of the structured task object, the output data structure is used for result format verification in subsequent steps, the dependency relationship is used to determine the calling order between processors, and the timeout strategy is used to determine whether the task should be executed synchronously or asynchronously.

[0024] In step 04, a task orchestration plan is generated based on the dependencies of the target business processor. The task orchestration plan includes the execution order and invocation relationship of multiple business processing nodes. The execution method is determined according to the timeout policy of the target business processor: when the estimated timeout of the task is lower than the synchronization threshold in the timeout policy, the task orchestration plan is executed directly and the result is returned synchronously; when the estimated timeout of the task exceeds the synchronization threshold, a task identifier is created, and the server-side task state machine marks the task status as executing and drives execution asynchronously. The task identifier is used to associate subsequent progress feedback and result callback.

[0025] In step 05, during task execution, the task status and stage progress corresponding to the task identifier are returned to the lightweight client through the Server-Sent Events (SSE) channel or polling method. The task status includes statuses such as executing, waiting for confirmation, completed, and failed.

[0026] In step 06, a truth status verification is performed on the business results returned by the target business processor. This truth status verification includes: data source verification (to verify that the business results come from a registered data source and are not fabricated by the semantic model); processing completion status verification (to verify that the business engine has completed processing normally); and deliverable accessibility status verification (to verify that the deliverable files have been generated and are accessible). Simultaneously, the format of the business results is verified based on the output data structure. If any verification fails, an incomplete status is returned, and the results of failed verifications are not marked as complete, thereby preventing the semantic model from fabricating business results when data such as price, inventory, and approval status is missing.

[0027] In step 07, the business results that pass the real-state verification are encapsulated into structured business cards or delivery documents. The structured business cards contain field labels, result data, and operation buttons. Users can click the operation buttons in the dialog window to trigger subsequent business actions. At the same time, the task identifier, the identifier of the target business processor, and the status of the business results are written into the audit log, making the generation source and verification path of each business result traceable.

[0028] Through the above steps, this application achieves dynamic orchestration of multiple business engines via a lightweight client dialog window. The business engine registry allows for registration and discovery of new business capabilities without modifying the routing layer code; dependency-driven orchestration plan generation automatically drives the execution order of multiple processors based on dependencies recorded in the registry, eliminating the need for manual orchestration and hard-coded call logic; real-state verification prevents the semantic model from fabricating business results when price, inventory, and approval status are missing; and audit logs ensure that the source and verification path of each business result are traceable.

[0029] Figure 2 This is a diagram illustrating the overall architecture of the dynamic orchestration system for a lightweight client-side business engine, as described in this application embodiment. Figure 2 As shown in the figure, this application also provides a business engine dynamic orchestration system for lightweight clients, which includes a five-layer architecture.

[0030] The first layer is the lightweight client access and dialogue interaction layer, running on the lightweight client platform, providing four input methods: text, voice, image, and file attachments. Voice is transcribed into text using Automatic Speech Recognition (ASR), images are extracted for text and visual features using Optical Character Recognition (OCR), and file attachments are processed by calling the corresponding parser to extract structured data. This layer also renders message streams, parameter confirmation cards, task status cards, and business result cards.

[0031] The second layer is the session context and intent recognition layer, which includes tenant identity verification, structured task object construction, business intent recognition, and pending confirmation field generation. Tenant identity verification performs format and permission checks on tenant identifiers, application identifiers, and user identifiers. Structured task object construction aggregates multimodal inputs into a unified task object. Business intent recognition outputs a list of candidate business processors. Pending confirmation field generation drives the rendering of parameter confirmation cards.

[0032] The third layer is the business engine dynamic orchestration layer, which includes the business engine registry, business processor selection, geolocation context area routing, dependency resolution, orchestration plan generation, and long-task state machine. The registry records the identifier, version number, tenant visibility, enabled status, input / output data structures, dependencies, timeout policies, call addresses, and result card types of each business processor. Processor selection filters matching, enabled target processors based on business intent and tenant identifier. Geolocation routing performs coverage filtering, service radius determination, and distance sorting when the task object contains location information. Dependency resolution determines the processor execution order. Orchestration plan generation generates serial, parallel, and conditional branch nodes. The long-task state machine manages the complete state transition of a task from creation to completion or failure.

[0033] The fourth layer is the business processor layer, which includes a bill of materials processor, a quotation processor, a computer-aided design processor, an inventory processor, an approval processor, an evidence retrieval processor, a deterministic business processor, a document matching processor, an access control processor, and a result verification processor. Each processor is deployed independently and interfaces with the orchestration layer through a unified interface.

[0034] The service processor layer may also include constraint-solving service processors. These constraint-solving service processors receive structured parameters output by preceding nodes, generate one or more candidate resource links, and perform capacity, interface, resource usage, and redundancy condition checks on the candidate resource links. For example, in an LED display engineering implementation, the control system link planning processor generates candidate connection links for receiving cards, transmitting devices or video processing devices, modular chassis and input / output boards, ports, and cables based on the screen layout and control requirements. This implementation is only used to illustrate the dynamic registration and orchestration of constraint-solving service processors and does not limit this method to the LED display industry.

[0035] The fifth layer is the multi-tenant data and audit layer, which includes tenant data isolation, draft / active dual-state configuration, file repository, and audit logs. Tenant data isolation implements isolated access to configuration, data, files, and logs based on tenant identifiers and role permissions. The draft / active dual-state configuration saves newly added or modified configurations as drafts, which are then switched to active status after review. The file repository stores delivery files in tenant isolation. Audit logs record input, intent recognition results, processor call chains, state changes, and exception information.

[0036] Figure 3 This is a flowchart illustrating the business engine registration and invocation process in this application embodiment.

[0037] like Figure 3 As shown, when adding a new business processor, the business developer fills in the processor configuration information, which includes the processor's unique identifier, version number, tenant visibility scope, input and output data structures, dependencies, timeout policy, and result card type.

[0038] After submission, the configuration is saved in the registry as a draft and is not detected by the routing layer while in draft state.

[0039] The reviewer corresponding to the tenant's permissions reviews the draft configuration. Once approved, the configuration is switched to active status, and the reviewer and review time are recorded.

[0040] Once activated, the configuration is automatically discovered by the routing layer and loaded into the dynamic registry, without requiring modification of the routing layer code.

[0041] When a user triggers a call through dialogue input, the semantic model identifies the business intent and matches the processor identifier. After the routing layer verifies the tenant's permissions and parameter format, it calls the processor to perform business calculations.

[0042] Figure 4 This is a schematic diagram of the long task state machine in an embodiment of this application.

[0043] like Figure 4As shown, after a task is created, it enters the "created" state, indicating that the task object has been generated but has not yet been submitted to the execution queue. The task then enters the "queued" state, indicating that it has been submitted to the execution queue and is awaiting resource allocation. When the task is scheduled for execution, it enters the "running" state, and the processor begins executing the business logic.

[0044] The "Executing" state has two branches: When user confirmation of parameters or selection of a solution is required during task execution, it enters the "waiting_confirm" state, returning to the "Executing" state after user confirmation; when interim results are generated during task execution, it enters the "streaming" state and sends the interim results back to the client, returning to the "Executing" state after the send-back is complete. Once the task is completed and the delivery file is generated, it enters the "artifact_ready" state, followed by the "completed" state. At any point during the "Executing" or "Queued" states, the task may enter the "failed" state due to a processor error, the "cancelled" state due to user cancellation, or the "expired" state due to exceeding the preset validity period.

[0045] Figure 5 This is an example diagram of cross-service orchestration in the embodiments of this application.

[0046] like Figure 5 As shown, after the user inputs "Help me generate a quote and plan for this project," the system converts the user input into a structured task object (TaskSpec). This task object contains the business objective (quote and plan generation), business parameters (project information), and a list of fields to be confirmed.

[0047] The system queries the business engine registry based on the business objectives of the task object. The registry records the dependencies of each business processor. The Bill of Materials (BOM) processor has no pre-dependencies; the price matching processor depends on the output data of the BOM processor; the quotation processor depends on the output data of the price matching processor; and the proposal processor depends on the output data of the quotation processor. The system determines the execution order based on these dependencies: the BOM processor executes first, the price matching processor executes after the BOM is completed, the quotation processor executes after the price matching is completed, and the proposal processor executes after the quotation is completed.

[0048] In the knowledge consultation implementation method, the output data structure of the evidence retrieval processor includes the evidence text, source identifier, version, content location, validity status, and access permissions. The deterministic business processor relies on the output of the evidence retrieval processor and the structured task object to perform calculations, constraint solving, or compatibility judgments. The result verification processor relies on the output of the aforementioned two types of processors to check the consistency of facts, calculation results, and generated content. A knowledge response card is generated only when the verification passes.

[0049] In the file acquisition implementation, the file matching processor filters candidate files based on the product, region, language, version, configuration, or adaptation fields in the structured task object, and the permission verification processor performs verification based on the tenant identifier, user permissions, file authorization scope, and validity status. When there is only one candidate file, or when multiple candidate files determine a unique target file based on preset version priority, validity, and adaptation rules, a file delivery card is generated after the permission verification is passed. When there are multiple candidates and a unique target file cannot be determined according to the rules, a selection card is generated. When there are no candidates, a source to be supplemented status is generated, and when there is no permission, an undeliverable status is generated.

[0050] Each of the aforementioned processors records its independent capability tags, input / output data structures, dependencies, version, and tenant applicability in the business engine registry. When replacing a knowledge base, file repository, or deterministic business engine, only the corresponding processor configuration or version is updated; the task orchestrator still generates execution plans based on the registry dependencies.

[0051] In another implementation, the parameter parsing processor outputs the screen structure parameters and control requirements, the control system link planning processor generates candidate links based on the structure parameters and control requirements, the bill of materials processor generates an equipment list based on the candidate links that have been confirmed and verified by the user, and the price matching processor then performs price matching based on the equipment list; if any candidate link has unconfirmed parameters or fails constraint verification, the orchestration plan enters a waiting confirmation state without calling subsequent processors.

[0052] After the Bill of Materials (BOM) processor completes its work, the Price Matching processor receives the BOM output from the BOM processor and matches the price of each material one by one. Branches with matched prices proceed to the Quotation processor for price calculation, while branches without matched prices generate a pending quote card and return it to the user for confirmation or supplementation before re-entering the Quotation processor. The Quotation processor generates a complete quote based on the matched prices and the user-confirmed pending quote items. The Proposal Processing processor receives the complete quote, fills in the proposal template, and generates the delivery document. Finally, the quote and proposal are returned in the form of an artifact card.

[0053] The following describes the dynamic orchestration method for lightweight client-oriented business engines provided in this application, with reference to specific embodiments: In some implementations, the method further includes a step of involving geographic location context in the selection of service processors: When a structured task object contains location information, a geographic location context is generated, which includes latitude and longitude information and administrative division information. Based on the geographic location context, the target service processor is filtered for coverage range to determine whether the service radius or coverage area of ​​the candidate service resources associated with the target service processor covers the location information; Candidate service processors are sorted by distance based on geographic location context, and the service area of ​​the target service processor is determined to match the location information based on geographic location context. Use geographic location context as the basis for task orchestration planning.

[0054] Specifically, when a structured task object contains location information, a geographic location context is generated. The geographic location context is generated from one or more of the following: user-authorized location information, user-inputted address information, project-related address information, warehouse address information, and service area information configured by the tenant. In one implementation, the user enters in a dialog, "I have a project in Bao'an, Shenzhen, and I need to find a nearby service provider that can provide on-site installation." The system asks the user if they authorize location access. After authorization, the system parses the location information into latitude, longitude, and administrative division information, generating a geographic location context.

[0055] Based on the geographic location context, the system performs coverage filtering on the target service processor and its associated candidate service resources to determine whether the service radius or coverage area of ​​the candidate service resources associated with the target service processor covers the location information. In one implementation, the system queries the service provider matching processor that supports regional services in the service engine registry. Based on the service coverage radius (50 km) and regional coverage area (Shenzhen, Dongguan) in the geographic routing policy configured for the processor, the system determines whether the service radius of the candidate service provider covers the location information of Bao'an District, Shenzhen, and only returns the service provider processor that covers that location.

[0056] The system sorts the target service processor and its associated candidate service resources by distance based on the geographic location context, and determines whether the service area of ​​the target service processor matches the location information. In one implementation, the system sorts the candidate service providers in ascending order by distance, and simultaneously checks whether the service provider's service categories match the project requirements; if they match, they are retained, and if they do not, they are excluded.

[0057] The geographic location context is used as the basis for task orchestration planning. In one implementation, the routing layer prioritizes calling the warehouse processor closest to the project address to match inventory based on the service radius and distance sorting results in the geographic location context, and then calls the service provider processor covering the project address to arrange on-site installation. If there is no coverage, a status of no available service is returned.

[0058] Figure 6 This is a schematic diagram of service routing based on geographic location context in an embodiment of this application.

[0059] like Figure 6 As shown, after the user enters the project address or authorizes a location, the system generates a geolocation context. The geolocation context is generated from one or more of the following: user-authorized location information, address information manually entered by the user, project-related address information, warehouse address information, and service area information configured by the tenant. It includes latitude and longitude information, administrative division information, location accuracy information, service radius threshold, and address source information.

[0060] The system queries the business engine registry for the geographic routing policy (handler.geo_policy) of each business processor. The geographic routing policy is used to mark whether the processor can be called only when location information is available, and to set the distance range that the processor can serve, the list of administrative divisions that the processor can cover, the distance sorting method of candidate objects, the matching rules of regional service providers, and the regional price calculation rules.

[0061] The system routes traffic based on geographic context and geographic routing strategy. When the service radius of a candidate warehouse covers the project address, the system routes to the inventory processor or delivery processor to perform inventory matching or delivery arrangements. When the service radius of a candidate service provider covers the project address, the system routes to the installation processor or after-sales processor to perform on-site installation or after-sales service arrangements. When the regional pricing rule matches the administrative region where the project address is located, the system routes to the freight processor or on-site fee processor to perform cost calculation. When none of the candidate processors meet the coverage criteria, a "manually required" card is returned, indicating to the user that no service is available and transferring the request to manual processing.

[0062] In some implementations, the true state verification includes: Verify one or more of the following in the business results: price, inventory quantity, specifications, approval conclusion, order status, and document generation status; Returns a non-matched status when no data is found, an expired status when the data has expired, a pending confirmation status when the data is in an unapproved state, a running, pending confirmation, or incomplete status when the task has not been completed, and an inaccessible status when the deliverable is inaccessible. The business result is marked as completed when all verifications pass.

[0063] Specifically, the real-state verification checks the price values, inventory quantities, specifications, approval conclusions, order status, and document generation status in the business results. Taking the LED engineering mini-program business orchestration as an example, after the bill of materials processor outputs the bill of materials, the price matching processor matches the quotations for each material one by one. If a certain model of module has no quotation record in the price database, the material returns an unmatched status and is marked as pending quotation in the dialog window, and is not entered into the quotation calculation process.

[0064] During inventory queries, if the inventory data returned by the inventory system has expired (e.g., price validity expired, inventory snapshot expired), an expired status is returned. In the approval process, if the approval form corresponding to the approval conclusion has not yet completed the approval process and is in a pending review state, a pending confirmation status is returned. During document generation, if the task of generating the delivery document has not yet been completed, the status is returned as executing, awaiting confirmation, or incomplete, depending on the current task status; only when the business processor explicitly returns a failure result or the failure judgment condition is exceeded will an execution failure status be returned. During deliverable access, if the generated delivery document cannot be accessed (e.g., the file has been deleted, storage service is unavailable), an inaccessible status is returned.

[0065] The system only marks a business result as completed when all checks pass—that is, price data exists and is valid, inventory data exists and is not expired, approval conclusion is confirmed, task execution is completed, and files are accessible. Taking the advertising production and signage engineering mini-program as an example, if a user inputs "Make a 5-meter storefront sign with acrylic illuminated lettering, please provide a quote and work order," the system will call the quote processor and work order processor. If the inventory or price does not match, the real-world access control will return to a pending state, preventing AI-generated data from being fabricated.

[0066] In some implementations, the business results verified through real-state validation are encapsulated into structured business cards, including: Write machine-resolvable fields into the structured business card. Machine-resolvable fields include task identifier, target business processor identifier, result status, data source, and triggerable operation items. Each structured business card is rendered as an interactive structured unit and displayed in the message stream of the dialog window; The system receives user clicks through triggerable action items and triggers subsequent business actions based on those clicks.

[0067] Specifically, machine-resolvable fields are written into the structured business cards, including task identifier, target business processor identifier, result status, data source, and triggerable operation items. Taking the quotation result card as an example, the task identifier is written as "task_20260731_001", the processor identifier is written as "quote.generate", the result status is written as "completed", the data source is written as "supplier_library / quote_v2.1", and the operation items are written as "view details", "download quotation", and "modify parameters". The operation items are clickable buttons or links, which users can directly click to operate in the dialog window without manually entering commands.

[0068] Each structured business card is rendered as an interactive structured unit and displayed in the message flow of the dialog window. Taking the LED engineering mini-program business orchestration as an example, after the BOM processor returns the bill of materials, the system renders the bill of materials card. The material name, specifications, quantity, unit price, and total price in the card are presented in a table format, with each material as an independent row. Users can click on the material row to view details.

[0069] The system receives user clicks through triggerable action items and triggers subsequent business actions based on these clicks. Taking a cross-business orchestration example, the BOM card contains a "Generate Quote" action item; clicking it triggers the quote processor to calculate the quote. The quote card contains a "Generate Proposal" action item; clicking it triggers the proposal processor to generate the proposal. Subsequent business actions triggered by clicks reuse the existing processor call chain, returning a new structured business card in the dialog window's message flow.

[0070] In some implementations, the method also includes draft review of service processor configurations and multi-tenant isolation steps: Save newly added or modified business processor configurations as drafts, and prevent task orchestration plans from reading configurations while in draft state; After the configuration is approved by the tenant's permission-related review process, the configuration will be switched from draft to active status. When switching to active status, record the operator, operation time, change summary, and rollback version; In a multi-tenant environment, business processor configuration information, business data, delivery documents, and audit logs are isolated and access controlled based on one or more of the tenant identifier, application identifier, user identifier, and role permissions.

[0071] Specifically, newly added or modified business processor configurations are saved in draft state. Taking price library import as an example, after a user uploads a supplier price list, the price library importer parses the file and verifies the cost price, specifications, and supplier name of each material line by line. All materials that pass the verification are written to the price library in draft state. While in draft state, they are not read by the bill of materials processor and do not participate in quotation calculation. Users can edit and modify price data or perform rollback operations in draft state.

[0072] After the configuration is approved by the tenant's permission-related review process, it switches from draft to active status. Reviewers confirm each price item in the draft status; once approved, they click "Activate," switching all draft price data to active status. The activated price data is then read by the bill of materials processor and retrieved and used during quotation matching.

[0073] When switching to active status, the system records the operator, operation time, change summary, and rollback version. Taking price import as an example, the audit log for a certain price record shows the import time as 14:30 on July 29, 2026, the operator as the current user ID, the source file as "supplier_a_2026Q2.xlsx", the activation time as 09:15 on July 30, 2026, and the rollback version pointing to the snapshot before activation. If price data issues arise, the system can restore the system to its pre-activation state based on the rollback version.

[0074] In a multi-tenant environment, based on one or more of tenant identifiers, application identifiers, user identifiers, and role permissions, isolated storage and access control are implemented for business processor configuration information, business data, delivery documents, and audit logs. Tenant A's price database directory is data / tenants / tenantA / prices / , and Tenant B's directory is data / tenants / tenantB / prices / . Tenant A's pricing processor only reads price data from Tenant A's directory. Tenant A's business processor configuration is only visible to Tenant A; users of Tenant A cannot access Tenant B's business data, delivery documents, and audit logs.

[0075] In some implementations, generating a task orchestration plan based on the dependencies of the target service processor includes: Dependency checks are performed based on the output data structure of the previous business processing node and the input data structure of the next business processing node. When the dependency verification passes, a task orchestration plan containing the previous business processing node and the next business processing node is generated. If dependency verification fails, perform one or more of the following operations: parameter supplementation, manual confirmation, alternative business processor selection, failure retry, or rollback.

[0076] Specifically, dependency validation is performed based on the output data structure of the previous business processing node and the input data structure of the next business processing node. Taking cross-business orchestration as an example, the output data structure of the bill of materials processor includes the item list field (items), the model field (model), the quantity field (quantity), and the specification parameter field (spec). The input data structure of the price matching processor requires the model field (model) and the quantity field (quantity). The system validates whether the output data structure of the bill of materials processor contains all the fields required by the price matching processor; if so, the dependency validation passes.

[0077] Upon successful dependency validation, a task orchestration plan is generated, including the preceding and following business processing nodes. The bill of materials (BOM) processor's output data structure satisfies the input requirements of the price matching processor. The system prioritizes the BOM processor node first, followed by the price matching processor node, generating a task orchestration plan for sequential execution. In another implementation, the quotation processor's output data structure simultaneously satisfies the input requirements of both the proposal processor and the approval processor. The system then arranges the proposal processor node and the approval processor node in parallel after the quotation processor node.

[0078] If dependency verification fails, perform one or more of the following operations: parameter supplementation, manual confirmation, alternative business processor selection, failure retry, or rollback.

[0079] In one implementation, the price matching processor requires a supplier field as input, but the bill of materials processor's output data structure lacks this field. Instead of generating a scheduling plan, the system performs a parameter supplementation operation, generating a parameter confirmation card that requires the user to supplement supplier information.

[0080] In another implementation, if the bill of materials processor outputs data that is missing several fields, the system performs a manual confirmation operation, suspends the generation of the orchestration plan, and waits for the user to manually complete all the missing fields through a confirmation card.

[0081] In another implementation, a substitute processor exists in the registry, whose input data structure matches the output data structure of the bill of materials processor. The system performs a substitute processor selection operation, replacing the processor that failed the dependency check with the substitute processor. If the dependency check fails and there is no substitute processor, the system performs a failure retry operation or a rollback operation. After three retries, it rolls back to the initial state and returns an error message.

[0082] In some implementations, the server-side task state machine includes: a created state (meaning the task orchestration plan has been created but not yet entered the execution queue); a queued state (meaning the task orchestration plan has entered the execution queue and is waiting for resource allocation); an executing state (meaning the target business processor is executing the task orchestration plan); a waiting-for-confirmation state (meaning the target business processor needs user confirmation of parameters or selection options); a streaming output state (meaning the phased results generated during the execution of the target business processor are being transmitted back to the lightweight client); a delivery file generation state (meaning the task orchestration plan has been completed and the delivery file has been generated); a completed state (meaning the task orchestration plan has been fully executed); a failed state (meaning the target business processor failed to execute); a canceled state (meaning the user actively canceled the task orchestration plan); and an expired state (meaning the execution time of the task orchestration plan has exceeded a preset validity period). Specifically, taking cross-business orchestration as an example, after a user inputs "Generate a quotation and proposal for this project," the system creates a task orchestration plan, and the task enters the created state. The task orchestration plan is submitted to the execution queue to await processor resource allocation, entering the queued state. Once processor resources are ready, the bill of materials processor begins execution, and the task enters the executing state.

[0083] During the execution of the bill of materials (BOM) processor, if the price matching processor finds that multiple suppliers have quoted prices for a certain material with significant price differences, the system will pause the task execution and generate a selection card, waiting for the user to select a supplier before resuming execution. The task will then enter a pending confirmation state. After the user confirms the selection, the task will return to the in-process state and continue execution.

[0084] After all processors have completed their execution, the task enters the completed state. If the price matching processor times out querying the price database, the task enters the failed state and the reason for failure is recorded. If the user clicks the stop generation button during execution, the task enters the canceled state. If the task's timeout period exceeds the preset validity period from its creation time, the state machine automatically marks the task as expired and releases resources.

[0085] In some implementations, the method further includes a business result continuation step: Maintain the context information of the current session in the dialog window. The context information includes confirmed structured task objects, completed business results, and archived delivery document indexes. The dialog window receives the user's continuation input, which can be one of the following: modification instruction, supplementary instruction, recalculation instruction, or newly generated instruction. Based on the continuation input, read the corresponding structured task object or completed business result from the context information, perform modification, supplementation, recalculation or new generation operations, and archive the new business result to the audit record.

[0086] Specifically, taking the LED engineering mini-program as an example, after the user enters "build a 4-meter by 2.5-meter P2.5 screen on the front wall of the conference room" for the first time, the system completes the bill of materials calculation, quotation calculation and proposal generation, and saves the confirmed structured task objects (including screen width of 4000 mm, height of 2500 mm, pixel pitch of 2.5 mm, and installation method of wall mounting), the completed business results (bill of materials, quotation) and the archived delivery document index (storage path of the proposal PDF) in the context information of the current session.

[0087] The user subsequently entered "Change the height to 2.8 meters and recalculate" in the dialog window, which was recognized as a recalculation command. The system reads the confirmed structured task object from the context information, changes the height field from 2500 mm to 2800 mm, keeps other fields unchanged, and calls the Bill of Materials processor, Quotation processor, and Proposal processor to re-execute the calculation. The Bill of Materials processor recalculates the number of module rows and the total number of modules based on the new height. After the recalculation is completed, the new business results (updated Bill of Materials, Quotations, and Proposals) are archived in the audit log, forming a version comparison with the first generated results.

[0088] In another implementation, the user inputs "supplement a steel structure drawing", which is recognized as a supplementary instruction. The system reads the confirmed structured task object from the context information, calls the computer-aided design processor to perform the new generation operation, generates the steel structure drawing, and archives it together with the original result.

[0089] In some implementations, the lightweight client includes one or more of the following: a mini-program, a web application, a progressive web application, a mobile application, a desktop client, or an enterprise collaboration platform client. When user input is received by the lightweight client through a dialog window, application message, interactive card, or intelligent robot, additional client capability information is added for each user input. The client capability information includes one or more of the following: an application identifier, a user identifier, a session identifier, and a message identifier. In the session corresponding to the session identifier, a historical structured task object list, a confirmed parameter field list, a parameter field list to be supplemented, and a delivered file index are maintained.

[0090] Specifically, when the lightweight client dialog window receives user input, the system attaches four identifying pieces of information to each user input: an application identifier to distinguish different mini-program applications, a user identifier to distinguish different users, a session identifier to identify the current dialog session, and a message identifier to uniquely identify the current message. These pieces of information, together with the tenant identifier, constitute the complete identity context for each request.

[0091] Maintain four lists within the session corresponding to the session identifier: the historical structured task object list records all task objects generated in this session; the confirmed parameter field list records parameters confirmed by the user; the pending parameter field list records parameters that have not yet been added; and the delivered file index records all delivered files generated in this session.

[0092] Taking the LED project mini-program as an example, when a user first enters "Build a 4m x 2.5m P2.5 screen on the front wall of the conference room," the system creates a session identifier and generates a task object. The screen width (4000mm), height (2500mm), pixel pitch (2.5mm), and installation method (wall-mounted) are written into the confirmed parameter field list. When the user second enters "Change the height to 2.8 meters and recalculate," the system searches for the current session based on the session identifier, reads the first generated task object from the historical structured task object list, modifies the height field from 2500mm to 2800mm, and calls the processor to recalculate. When the user third enters "This project also needs a steel structure drawing," the system reads all parameters of the current project from the confirmed parameter field list, calls the computer-aided design processor to perform a new generation operation, generates the steel structure drawing, and writes the drawing file index into the delivered file index list.

[0093] like Figure 7 As shown, in one embodiment, a server-side computer device is provided, which can be a server. The computer device includes a processor, memory, network interface, and database connected via a system bus; when the computer program is executed by the processor, it implements the functions or steps of the aforementioned dynamic orchestration method for a lightweight client-oriented business engine on the server side.

[0094] like Figure 8 As shown, in one embodiment, a client computer device is provided, which can be a client. The computer device includes a processor, memory, network interface, display screen, and input device connected via a system bus; when the computer program is executed by the processor, it implements the functions or steps of the aforementioned dynamic orchestration method for a lightweight client's business engine on the client side.

[0095] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0096] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0097] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0098] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A dynamic orchestration method for a business engine for lightweight clients, characterized in that, Includes the following steps: The lightweight client receives user input through its dialog window. After verifying login credentials or platform identity on the server side, it determines the authenticated tenant identifier and maps user permissions and client context. The user input is then converted into a structured task object. The business intent of the structured task object is identified by a semantic model. When key fields are missing, a structured confirmation card is generated to receive supplementary information from the user, and the supplementary information is merged into the structured task object. Based on the intent recognition results and the tenant identifier, the business engine registry is queried. Target business processors are filtered according to business intent, certified tenant identifier, permission scope, version status, and health status. The business engine registry records one or more of the following for each business processor: processor identifier, capability tag, version, activation status, health status, tenant applicable scope, permission scope, input data structure, output data structure, dependency relationship, constraint rule set, candidate solution data structure, result verification strategy, timeout strategy, and geographical routing strategy. When the business intent includes knowledge consultation or file acquisition, one or more of the following are filtered from the business engine registry: evidence retrieval processor, deterministic business processor, file matching processor, and permission verification processor. The processor and its input / output data structure and dependency relationship are determined as nodes to be orchestrated. A task orchestration plan is generated based on the dependencies of the target service processor. The task orchestration plan is executed directly according to the timeout policy of the target service processor, or a task identifier is created and executed by the server-side task state machine. During task execution, the task status and stage progress are returned to the lightweight client. Perform a real status verification on the business result returned by the target business processor, and verify whether the format of the business result is correct according to the output data structure. The real status verification includes one or more of the following: data source verification, processing completion status verification, and deliverable accessibility status verification. If the verification fails, return an incomplete status. The business results that pass the real status verification are encapsulated into structured business cards or delivery documents, and the task identifier, the identifier of the target business processor, and the status of the business results are written into the audit log.

2. The method according to claim 1, characterized in that, The method also includes a step where geographic location context is involved in the service processor selection: When the structured task object contains location information, a geographic location context is generated, which includes latitude and longitude information and administrative division information; Based on the geographic location context, perform coverage filtering on the target service processor and its associated candidate service resources, and determine whether the service radius or coverage area of ​​the candidate service resources associated with the target service processor covers the location information; Based on the geographic location context, the target service processor and its associated candidate service resources are sorted by distance, and based on the geographic location context, it is determined whether the service area of ​​the target service processor matches the location information; The geographic location context is used as the basis for the scheduling of the task orchestration plan.

3. The method according to claim 1, characterized in that, The real state verification includes: Verify one or more of the following in the business results: price value, inventory quantity, specifications, approval conclusion, order status, and document generation status; When the data is not found, return a non-matched status; when the data has expired, return an expired status; when the data is in an unapproved status, return a pending confirmation status; when the task has not been completed, return a status of executing, waiting for confirmation, or not completed; when the deliverable is inaccessible, return an inaccessible status. When all verifications pass, the business result is marked as a completed result.

4. The method according to claim 1, characterized in that, The step of encapsulating the business results verified by the real state into a structured business card includes: Machine-resolvable fields are written into the structured business card. These machine-resolvable fields include the task identifier, the identifier of the target business processor, the result status, the data source, and the triggerable operation items. Each of the structured business cards is rendered as an interactive structured unit and displayed in the message stream of the dialog window; The system receives user clicks through the triggerable action items and triggers subsequent business actions based on those clicks.

5. The method according to claim 1, characterized in that, The method also includes draft review of business processor configurations and multi-tenant isolation steps: The newly added or modified business processor configuration is saved as a draft. When it is in draft state, the task orchestration plan is prohibited from reading the configuration. After the configuration is approved by the tenant's permission, the configuration will be switched from draft to active state. When switching to active status, record the operator, operation time, change summary, and rollback version; In a multi-tenant environment, based on one or more of the tenant identifier, application identifier, user identifier, and role permissions, isolated storage and access control are implemented for business processor configuration information, business data, delivery documents, and audit records.

6. The method according to claim 1, characterized in that, The step of generating a task orchestration plan based on the dependencies of the target service processor includes: Dependency checks are performed based on the output data structure of the previous business processing node and the input data structure of the next business processing node. When the dependency verification passes, a task orchestration plan containing the previous business processing node and the next business processing node is generated. When the dependency verification fails, perform one or more of the following operations: parameter supplementation, manual confirmation, alternative business processor selection, failure retry, or rollback. When the target service processor is a constraint-solving service processor, multiple candidate solutions are generated based on the structured parameters provided by the preceding service processing node. The capacity, interface, resource consumption, and redundancy conditions in the constraint rule set are verified for each candidate solution. The candidate solutions that pass the verification are submitted to the subsequent service processing node or the node waiting for confirmation.

7. The method according to claim 1, characterized in that, The server-side task state machine includes: a created state (meaning the task orchestration plan has been created but has not yet entered the execution queue); a queued state (meaning the task orchestration plan has entered the execution queue and is waiting for resource allocation); an executing state (meaning the target business processor is executing the task orchestration plan); a waiting-for-confirmation state (meaning the target business processor needs user confirmation of parameters or selection of a scheme); a streaming output state (meaning the phased results generated during the execution of the target business processor are being transmitted back to the lightweight client); a delivery file generation state (meaning the task orchestration plan has been completed and the delivery file has been generated); a completed state (meaning the task orchestration plan has been fully executed); a failed state (meaning the target business processor failed to execute); a canceled state (meaning the user actively canceled the task orchestration plan); and an expired state (meaning the execution time of the task orchestration plan has exceeded the preset validity period).

8. The method according to claim 1, characterized in that, The method also includes a business result continuation step: The dialog window maintains the context information of the current session, which includes confirmed structured task objects, completed business results, and archived delivery file indexes. The dialog window receives the user's continuation input, which is one of the following: modification instruction, supplementary instruction, recalculation instruction, or newly generated instruction. Based on the continuation input, the corresponding structured task object or completed business result is read from the context information, and modification, supplementation, recalculation or new generation operations are performed, and the new business result is archived in the audit record.

9. The method according to claim 1, characterized in that, The lightweight client includes one or more of the following: mini-program, web application, progressive web application, mobile application, desktop client, or enterprise collaboration platform client. When user input is received by the lightweight client through its dialog window, application message, interactive card, or intelligent robot, additional client capability information is added for each user input. The client capability information includes one or more of the following: application identifier, user identifier, session identifier, and message identifier. In the session corresponding to the session identifier, a historical structured task object list, a confirmed parameter field list, a parameter field list to be supplemented, and a delivered file index are maintained.

10. The method according to claim 1, characterized in that, When the business intent is knowledge consultation or document retrieval, the task orchestration plan includes: the evidence retrieval processor retrieving evidence units with source identifiers, versions, validity status, and access permissions based on the structured task object; when the consultation content involves calculations, constraints, or compatibility judgments that can be processed by the deterministic business processor, passing the evidence units and the structured task object to the deterministic business processor; the result verification processor performing consistency verification between the retrieved evidence, the deterministic processing results, and the content generated by the semantic model; when the business intent is document retrieval, the file matching processor filtering candidate files based on file metadata and the structured task object, and the permission verification processor verifying the access permissions of the current tenant and user; returning a knowledge response card only when the evidence used for knowledge consultation is valid and the access permission verification passes; returning a file delivery card only when there is only one candidate file used for document retrieval, or when multiple candidate files determine a unique target file through preset version priority, validity, and compatibility rules, after the target file is valid and the access permission verification passes; otherwise, returning a status of pending supplementation, pending selection, pending confirmation, or undeliverable.

11. A dynamic orchestration system for a business engine for lightweight clients, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 10.

Images