An agent application method and system based on a data semantic layer and hierarchical hybrid architecture

Abstract

The application discloses an agent application method and system based on a data semantic layer and a hierarchical hybrid architecture. The method constructs a five-layer hierarchical hybrid architecture including an Agent arrangement layer, a Skills layer, a Tools layer, an Action layer and a data semantic layer, and clearly defines the responsibility boundaries and cross-layer calling constraints of each layer. The Agent arrangement layer receives tasks and completes intent understanding and classification. If a registered Skill is hit, it enters a fast channel for execution, and if it is not hit, it enters a slow channel for dynamic planning and Tool combination execution. The Skill is executed according to a deterministic directed acyclic graph step, and core business judgment is completed based on the production rules and attribute engine of the data semantic layer, and a large language model does not participate in conditional judgment. The method calculates a comprehensive confidence based on multiple factors and executes three-level task distribution. After receiving business feedback, data is written back to the data semantic layer, triggering rule review iteration, and realizing rule autonomous evolution.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence application technology, and in particular to an intelligent agent application method and system based on a data semantic layer and a hierarchical hybrid architecture. Background Technology

[0002] Current enterprise-level intelligent agent applications mostly employ end-to-end inference solutions using large language models, typically automating business processes through prompt word engineering and tool invocation capabilities. While these solutions offer some flexibility in handling open-domain dialogues and simple tasks, they often suffer from opaque judgment logic, untraceable results, and difficulty in controlling the illusions created by large language models when facing high-risk, highly compliant business scenarios such as medical insurance review, financial risk control, and compliance inspections. Consequently, they fail to meet the deterministic and auditable requirements of enterprise-level applications.

[0003] With the development of large language model technology and multi-agent systems, agent solutions with task decomposition and tool invocation capabilities are gradually being implemented in enterprise scenarios. By introducing human-in-the-loop mechanisms and tool orchestration frameworks, the reliability of agent output can be improved to a certain extent. At the same time, enterprise applications are increasingly emphasizing deterministic judgment, auditability, rule evolution, and data consistency, driving agent applications to evolve from general dialogue to domain-specific, controllable, reliable, and continuously evolving approaches.

[0004] Existing enterprise-level intelligent agent solutions are mostly preliminary explorations and have not yet formed a complete technical system. Specifically, this manifests in the following ways: a lack of clear layered architecture and capability boundary definitions; the conflation of atomic capabilities and decision-making capabilities leads to difficulties in auditing and rollback; core business judgments rely excessively on large language model reasoning, lacking a judgment mechanism based on deterministic rules, resulting in insufficient stability of judgment results; confidence assessment dimensions are singular, and the human-in-the-loop decoupling mechanism is crude, making it difficult to achieve a balance between automation rate and accuracy; there is a lack of a unified data semantic layer to support the world model, resulting in inconsistent interpretations of multi-source data, making it difficult to accumulate, reuse, and continuously evolve business rules, and failing to form a complete closed loop from execution to feedback. Summary of the Invention

[0005] The purpose of this application is to provide an intelligent agent application method and system based on a data semantic layer and a hierarchical hybrid architecture, which can provide deterministic business judgment logic, clarify the boundaries of architectural responsibilities, and realize intelligent task diversion and autonomous rule evolution.

[0006] Firstly, this application proposes an intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture, including: A five-layer hierarchical hybrid architecture consisting of Agent orchestration layer, Skills layer, Tools layer, Action layer and data semantic layer is constructed, and the responsibility boundaries of each layer and cross-layer call constraints are defined. The Agent orchestration layer receives task requests and completes intent understanding and task classification. It then performs type matching routing in the registered Skill library. If a match is found, the corresponding Skill is executed in the fast channel. Otherwise, the Skill is executed in the slow channel using dynamic programming tools. Skill internally calls Tools and Action to complete core business judgments according to a predefined deterministic directed acyclic graph step sequence. The core judgment logic is executed based on the concept set production rules and object derived attribute engine in the data semantic layer. The large language model does not participate in the condition judgment. The comprehensive confidence level is calculated by weighting three objective factors: historical success rate of rules, completeness of evidence, and data quality. Three-level diversion is then performed based on the two confidence level thresholds. High-confidence tasks are automatically executed with actions and then randomly checked according to a certain proportion; medium-confidence tasks are transferred to a manual simplified confirmation queue; and low-confidence tasks are transferred to a manual-led processing queue. Receive asynchronous feedback results from external systems for submitted operations, store the feedback data in association with the submission context, and write it back to the concept set library of the data semantic layer, triggering statistical updates, rule reviews, and version iterations of the concept set.

[0007] Optionally, a five-layer hierarchical hybrid architecture is constructed, consisting of an Agent orchestration layer, a Skills layer, a Tools layer, an Action layer, and a data semantics layer. The responsibilities of each layer and cross-layer call constraints are defined, including: The Agent orchestration layer is responsible for unstructured request parsing, task directed acyclic graph decomposition, Skill / Tool routing decision-making, confidence fusion calculation, and human-in-the-loop dynamic routing. It only calls the Skills layer or Tools / Action layer through standardized interfaces and prohibits direct access to the raw data interface of the data semantic layer. The Skills layer encapsulates a complete scenario-level workflow that has been validated by regression. Internally, it orchestrates the call sequence of multiple Tools and Actions according to deterministic steps, and externally exposes JSON Schema-compliant input and output interfaces for the Agent orchestration layer to call directly. The Action layer encapsulates decision-making operations involving business object state transitions and high compliance audit requirements. Each Action includes precondition assertions, state machine transition verification, immutable audit logs, and compensation rollback logic. The Tools layer encapsulates atomic, idempotent, and stateless operational capabilities, and exposes standardized calling interfaces through model context protocols or function call protocols; The data semantic layer, as a unified world model, provides object type and attribute management, real-time calculation of derived attributes, versioned storage of concept sets, and a unified data access interface for multiple protocols, while providing consistent data services to the Tools layer and Action layer above.

[0008] Optionally, the capabilities of the Action layer and Tools layer are implemented according to the five-dimensional boundary criterion, including: Operations that satisfy the following criteria are encapsulated as Actions: changing the persistent state of a business object, writing back to the production database of the business system, having a high compliance audit level, having clear pre- and post-state machine constraints, and sharing any two of the criteria across three or more Agents or Skills. Operations that only generate in-memory intermediate artifacts, read external resources only, have a medium to low audit level, have no state dependencies, and whose implementation logic can be deployed in a distributed manner are encapsulated as Tools. Before an Action is executed, it must pass fine-grained permission verification through the data semantic layer and generate an immutable audit record containing the operator, time, input parameters, and previous and subsequent states. If the execution fails, compensation and rollback logic will be automatically triggered. Object query operations in Tools must be relayed through the unified application programming interface of the data semantic layer and direct connection to the business system database is prohibited.

[0009] Optionally, the Agent orchestration layer receives task requests and performs intent understanding and task classification. It then performs type matching routing in the registered Skill library. If a match is found, the corresponding Skill is executed via the fast channel; otherwise, the Skill is executed via the slow channel using dynamic programming tools, including: Receive batches of structured tasks or a single natural language request, perform idempotency checks on each task item, and generate a globally unique task identifier; The large language model is invoked to perform few-shot intent recognition for each task item, and the normalized task type label and confidence score are output. The registered Skill set is traversed, and the cosine matching degree is calculated based on the task type label and the applicable scenario label in the Skill metadata. If the matching degree reaches the preset threshold and the Skill is in an available state, it is determined to be a hit. Once a task is successfully executed, it enters the fast track path, directly calling the standardized interface of the corresponding Skill to execute and pass through the task parameters. Unsuccessful tasks enter the slow path, where the large language model dynamically plans the directed acyclic graph sequence of tool calls based on the available tool list, tool descriptions, and task context, and schedules them for execution sequentially according to dependencies.

[0010] Optionally, Skill internally calls Tools and Actions according to a predefined deterministic directed acyclic graph step sequence to complete core business judgments. The core judgment logic is executed based on the production rules of the concept set in the data semantic layer and the object derived attribute engine, including: After receiving the structured task input, Skill performs Schema validation of the input parameters and executes the directed acyclic graph step by step according to the predefined steps. The full set of original attribute data and real-time calculated derived attribute values ​​of the target business object can be obtained in batches through the object query tool corresponding to the data semantic layer. Load the highest version concept set that matches the current task type, the concept set including payment condition production rules, mandatory diagnostic code set, time window constraints, optional evidence list and exclusion rules; The necessary condition conjunction check, time window constraint check, exclusion condition disjunction check, and optional evidence existence statistics are executed sequentially according to the production rules in the concept set to generate a Boolean-type deterministic judgment result and an evidence chain reference list. The large language model generates natural language output text that conforms to domain document specifications based on deterministic judgment results and structured evidence chains. The large language model does not participate in any conditional judgment logic.

[0011] Optionally, the comprehensive confidence level is calculated based on a weighted average of three objective factors: historical success rate of the rule, completeness of evidence, and data quality, including: Obtain the historical success rate of the Bayesian smoothing of the concept set version used in the current task, wherein the historical success rate is the ratio of the number of successful cases in the historical submissions of the concept set after Laplace smoothing to the total number of submissions; Calculate the evidence completeness factor, which is the ratio of the weighted number of optional evidence obtained in the current task to the total weighted number of optional evidence defined by the concept set, wherein the weight of key evidence is higher than that of ordinary evidence; Calculate the data quality factor, which is generated by weighting three sub-dimensions: the proportion of non-empty attributes of business objects, the offset between data timestamps and business time windows, and the consistency verification results of multi-source data. Configurable weights are assigned to the three objective factors, and a comprehensive confidence value is obtained by weighted summation and calibration with the Sigmoid function. The comprehensive confidence value ranges from 0 to 1.

[0012] Optionally, a three-level traffic split is performed based on a dual confidence threshold, including: Set two judgment thresholds: a high-confidence automatic execution threshold and a medium-confidence manual confirmation lower bound. When the overall confidence level is greater than or equal to the high confidence threshold, it is determined to be a high confidence task, and the corresponding Action is automatically executed and post-sampling verification is performed according to the preset sampling ratio; When the overall confidence level is greater than or equal to the lower bound of the medium confidence level and less than the high confidence level threshold, it is determined to be a medium confidence task and transferred to the manual simplified confirmation queue. The manual simplified confirmation queue only displays the core judgment basis and conclusion, and executes the corresponding Action after receiving a single confirmation instruction. When the overall confidence level is less than the lower bound of the medium confidence level or the task does not match any concept set, it is judged as a low confidence task and transferred to the human-led processing queue. The agent only performs auxiliary operations such as multi-source data retrieval, evidence chain organization, and document draft generation.

[0013] Optionally, the data semantic layer, as part of the unified world model, provides object type and attribute management, derived attribute computation, versioned storage of concept sets, and a unified data access interface across multiple protocols, including: The ontology modeling approach is used to define business object types, data attributes, object attributes and semantic relationships, and to maintain object multi-version chains and full-link data lineage. The incremental derived attribute engine calculates derived attribute values ​​in real time based on the original attributes and event stream. The derived attributes include sliding time window aggregation statistics, diagnostic code existence markers, test index threshold judgments, and composite business indicators. Maintain a versioned concept set library. Each concept set contains a globally unique rule identifier, applicable scenario label, production rule judgment conditions, evidence weight list, historical successful case feature vector, historical failed case feature vector, semantic version number and Bayesian statistical information. It provides Cohort queue definition and management, a distributed metric calculation engine, and supports filtering object sets by composite conditions and batch calculating time-series metrics. It also provides a unified application programming interface for three access protocols: RESTful, GraphQL, and SQL, and offers cross-source data query, object attribute reading, and semantic retrieval services for concept sets to the upper layer.

[0014] Optionally, it receives asynchronous feedback results from external systems for submitted operations, stores the feedback data in a structured manner, and writes it back to the concept set library of the data semantic layer, triggering statistical updates, rule reviews, and version iterations of the concept set, including: The system listens for asynchronous feedback results from external systems via an event bus. These feedback results include a binary acceptance / rejection flag, a structured feedback reason encoding, a free text feedback description, and a feedback timestamp. The feedback data is immutably associated and stored with the overall confidence level when the corresponding task was submitted, the concept set identifier used, the semantic version number of the concept set, the hash value of the evidence chain based on the judgment, and the feature vector at the time of submission. Based on the feedback results, the historical success rate or historical failure rate of the corresponding concept set version is atomically updated, and the posterior historical success rate of the concept set is recalculated using the Bayesian incremental update method. Check whether the rule review conditions are triggered. The rule review conditions include the number of consecutive failures of the same concept set version within the sliding time window reaching the failure threshold, or the new concept set version completing the feedback observation period of the preset sample size, or the historical success rate of the concept set being lower than the preset lower threshold. When the review conditions are triggered, a rule review task containing clustering results of failed case features is automatically generated and enters the domain expert review queue. The modified rules approved by the experts are received and a new semantic version number is generated. The old version is retained for retrospective comparison.

[0015] Optionally, the construction of the data semantic layer adopts a two-stage experience accumulation path, including: During the cold start phase, collect all historical business processing records within a preset time range and perform data cleaning processes such as entity alignment, field standardization, drug and diagnosis code mapping, and association of multi-source patient master indexes. Historical records are grouped and aggregated according to business entity type and violation type. A large language model is invoked to perform batch analysis of the feature vectors of successful cases and failure cases for each group based on a few sample prompts. A draft concept set containing production rules, evidence list and initial statistics is generated. Organizational domain professionals conduct centralized reviews of concept set drafts using a double-blind review process to confirm the logic of judgment conditions, the allocation of evidence weights, and the boundaries of rule application. Concept sets that pass the review are assigned an initial version number and enter the formal concept set library. During the operation phase, real-time business traffic from the production environment is accessed, and a conservative strategy is adopted to gradually increase the automation ratio. When a new business type flows in, new rules are triggered to extract skills and automatically generate a concept set draft, which is then reviewed and approved by experts before entering the official library. Based on the asynchronous feedback data generated during operation, the judgment rules, evidence weights, and threshold parameters of the existing concept set are continuously and incrementally optimized to achieve the autonomous evolution of the concept set library.

[0016] Optionally, the concept set includes rule identifiers, applicable scenarios, a list of required conditions, time constraint rules, a list of optional evidence, a list of exclusion conditions, feature vectors of historical successful cases, feature vectors of historical failed cases, version number, creation time, last update time, and statistical fields. The statistical fields include total number of submissions, number of successful submissions, number of failed submissions, and number of consecutive failures. When performing a judgment on a set of concepts, first check whether all necessary conditions are met, then check whether there are any exclusion conditions, and finally count the number of optional evidences that are met. A negative judgment result is generated when any essential condition is not met or when there is an exclusion condition; a positive judgment result is generated when all essential conditions are met and there is no exclusion condition.

[0017] Secondly, this application also proposes an intelligent agent application system based on a data semantic layer and a hierarchical hybrid architecture, including: The architecture building unit is used to construct a five-layer hierarchical hybrid architecture consisting of an Agent orchestration layer, a Skills layer, a Tools layer, an Action layer, and a data semantics layer, defining the responsibility boundaries of each layer and cross-layer call constraints; The task routing unit is used by the Agent orchestration layer to receive task requests and complete intent understanding and task classification. It performs type matching routing in the registered Skill library. If a match is found, it enters the fast channel to call the corresponding Skill for execution. If no match is found, it enters the slow channel to dynamically plan and combine tools for execution. The deterministic judgment unit is used to call Tools and Actions to complete core business judgments within Skill according to a predefined deterministic directed acyclic graph step sequence. The core judgment logic is executed based on the concept set production rules and object derived attribute engine in the data semantic layer. The large language model does not participate in the condition judgment. The confidence calculation unit is used to calculate the comprehensive confidence score based on three objective factors: historical success rate of rules, completeness of evidence, and data quality, and to perform three-level triage based on the dual thresholds of confidence score. The hierarchical execution unit is used to automatically execute Actions and perform proportional post-event sampling checks when the confidence level is high; when the confidence level is medium, it is transferred to the manual simplified confirmation queue; and when the confidence level is low, it is transferred to manual-led processing. The feedback evolution unit is used to receive asynchronous feedback results from external systems for submitted operations, store the feedback data in association with the submission context, and write it back to the concept set library of the data semantic layer, triggering statistical updates, rule reviews, and version iterations of the concept set.

[0018] Compared with the prior art, this application has the following advantages: This application provides an intelligent agent application method and system based on a data semantic layer and a hierarchical hybrid architecture. By constructing a five-layer hierarchical hybrid architecture, the responsibilities and calling constraints of each layer are clearly defined, enabling intelligent task routing and deterministic business judgment. Combined with confidence calculation based on objective factors and a three-level diversion mechanism, as well as feedback-driven autonomous rule evolution, it effectively solves the problems in existing technologies such as lack of transparency in judgment logic, ambiguous boundaries of architectural responsibilities, excessive reliance on large language models for core business judgment, single confidence evaluation dimension, and inability to continuously optimize the rule base. It has the advantages of improving the reliability of judgment in high-risk business scenarios, enhancing system auditability, and enabling autonomous evolution of the rule base. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating an intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture, as provided in an embodiment of this application.

[0020] Figure 2 This is a schematic diagram of the structure of an intelligent agent application system based on a data semantic layer and a hierarchical hybrid architecture, provided in an embodiment of this application. Detailed Implementation

[0021] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0023] Firstly, such as Figure 1 As shown, this application embodiment provides an intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture, including: S100. Construct a five-layer hierarchical hybrid architecture consisting of Agent orchestration layer, Skills layer, Tools layer, Action layer and data semantic layer, and define the responsibility boundaries of each layer and cross-layer call constraints. A modular design approach can be adopted, dividing different functional units into independent layers. The Agent orchestration layer is responsible for receiving and initially distributing tasks; the Skills layer encapsulates a series of predefined operation steps; the Tools layer provides atomic function interfaces; the Action layer executes operations that affect business status; and the data semantic layer serves as a unified data source. The layers communicate through simple interfaces, with basic restrictions on the call relationships. For example, it can be stipulated that the Agent orchestration layer cannot directly call all functions in the Tools layer, but can only call them indirectly through the Skills layer.

[0024] S200: The Agent orchestration layer receives task requests and completes intent understanding and task classification. It performs type matching routing in the registered Skill library. If a match is found, it enters the fast channel to call the corresponding Skill for execution. If no match is found, it enters the slow channel to dynamically plan and combine Tools for execution. Specifically, the Agent orchestration layer can receive natural language requests or structured data from user input. For natural language requests, keyword matching or pre-defined template recognition can be used for intent understanding and task classification. Subsequently, the Agent orchestration layer searches a pre-maintained Skill list for a Skill that matches the task type. If a matching Skill is found, the task is directly forwarded to that Skill for processing—this is the fast channel. If no matching Skill is found, the Agent orchestration layer can select and combine multiple Tools to complete the task based on the task description, using a simple rule engine or a manually configured process—this is the slow channel.

[0025] S300 and Skill internally call Tools and Action to complete core business judgments according to the predefined deterministic directed acyclic graph step sequence. The core judgment logic is executed based on the concept set production rules and object derived attribute engine in the data semantic layer. The large language model does not participate in the condition judgment. A Skill can contain a series of fixed operation steps, which are executed sequentially in a preset order, forming a directed acyclic graph. During execution, the Skill calls atomic capabilities provided by the Tools layer to obtain data or perform calculations, and calls the Action layer to perform decision-making operations. The core business logic can be stored in the data semantic layer, existing in the form of simple "if A and B then C" rules. When a judgment is needed, the Skill retrieves relevant data from the data semantic layer, and a simple rule interpreter executes these rules to arrive at a deterministic judgment result. The object derived attribute engine can pre-compute some derived attributes based on the original data for use in rule judgment.

[0026] S400 calculates the comprehensive confidence level based on three objective factors: historical success rate of rules, completeness of evidence, and data quality, and performs three-level diversion based on the dual threshold of confidence level; Specifically, a simple historical success count can be maintained for each rule used for judgment, and its success rate can be calculated. Evidence completeness can be determined by comparing the amount of evidence collected during task processing with a preset minimum amount of evidence. Data quality can be initially assessed based on the data field fill rate or the reliability of the data source. Subsequently, these three factors are assigned preset fixed weights and weighted summed to obtain a comprehensive confidence value. Based on this confidence value, two fixed thresholds can be set to classify the task into three confidence levels: high, medium, and low.

[0027] S500: High-confidence tasks automatically execute Actions and are sampled and checked afterward according to a certain proportion; medium-confidence tasks are transferred to the manual simplified confirmation queue; and low-confidence tasks are transferred to the manual-led processing queue. When a task's overall confidence level reaches the highest level, the system can directly trigger the Action layer to execute the corresponding business operation without human intervention. To ensure the quality of automated operations, a portion of high-confidence tasks can be randomly selected for human review. When a task's overall confidence level is at a medium level, the system can send the task to a human review interface, which displays only key information and awaits simple confirmation from a human operator. When a task's overall confidence level is low, the system completely transfers the task to a human operator for processing, with the agent only providing some auxiliary information retrieval functions.

[0028] S600 receives asynchronous feedback results from external systems for submitted operations, stores the feedback data in association with the submission context, and writes it back to the concept set library of the data semantic layer, triggering statistical updates, rule reviews, and version iterations of the concept set; Specifically, after an agent completes an action, the external business system may return an operation result, such as success or failure. This feedback result can be received by the system and stored in association with contextual information such as the task ID and rules used in that operation. Subsequently, the system can update the success or failure count of the corresponding concept set in the data semantic layer based on the feedback result. When the number of failures for a certain concept set reaches a certain number, the system can mark that concept set as requiring manual review. After the review, if the rules are modified, a new rule version can be manually created and the old version replaced.

[0029] In some possible embodiments, a five-layer hierarchical hybrid architecture is constructed, consisting of an Agent orchestration layer, a Skills layer, a Tools layer, an Action layer, and a data semantic layer. The responsibilities of each layer and cross-layer call constraints are defined, including: The Agent orchestration layer is responsible for unstructured request parsing, task directed acyclic graph decomposition, Skill / Tool routing decision-making, confidence fusion calculation, and human-in-the-loop dynamic routing. It only calls the Skills layer or Tools / Action layer through standardized interfaces and prohibits direct access to the raw data interface of the data semantic layer. As the core coordinator of intelligent agent applications, the Agent orchestration layer's primary responsibility is to receive and understand raw, unstructured task requests from users or external systems, transforming them into an internal representation that the system can process. This includes task intent recognition and classification, and decomposing complex tasks into a series of interdependent subtasks, forming a directed acyclic graph (DAG) to guide the task execution order. Based on the task type and the current system state, the Agent orchestration layer intelligently selects and routes tasks to appropriate Skills or Tools for processing. Simultaneously, it is responsible for integrating confidence information from different components, calculating the overall confidence score, and determining whether manual intervention is needed for dynamic task routing based on preset strategies. To ensure system modularity, security, and data consistency, the Agent orchestration layer is strictly limited to interacting only with the Skills layer or Tools / Action layer through standardized interfaces, and direct access to the raw data interfaces of the data semantic layer is strictly prohibited, thus avoiding the risk of unauthorized modification or improper access to underlying data.

[0030] The Skills layer encapsulates a complete scenario-level workflow that has been validated by regression. Internally, it orchestrates the call sequence of multiple Tools and Actions according to deterministic steps, and externally exposes JSON Schema-compliant input and output interfaces for the Agent orchestration layer to call directly. The Skills layer represents an end-to-end solution for specific business scenarios. Each Skill undergoes rigorous regression testing and verification to ensure the correctness and stability of its business logic within that specific scenario. A Skill contains a series of atomic Tools and Actions, which are orchestrated according to a predefined, deterministic sequence of steps to complete a full business process. For example, an "order processing" Skill might include a "query inventory" Tool, a "generate order" Action, and a "send notification" Action. To achieve seamless integration with the Agent orchestration layer, the Skills layer provides standardized input / output interfaces conforming to the JSON Schema specification. This not only ensures the uniformity and verifiability of the data exchange format but also enables the Agent orchestration layer to clearly understand and invoke the functionality of Skills, thereby improving the system's modularity and reusability.

[0031] The Action layer encapsulates decision-making operations involving business object state transitions and high compliance audit requirements. Each Action includes precondition assertions, state machine transition verification, immutable audit logs, and compensation rollback logic. The Action layer focuses on executing critical operations that have a real impact on the business system. These operations typically lead to persistent changes in the state of business objects and are often accompanied by high compliance audit requirements. Examples include operations such as "approving a loan" and "updating user information." To ensure the correctness, legality, and traceability of these operations, each Action undergoes strict precondition assertions before execution to verify whether the preconditions for the operation are met. During execution, state machine transition checks are also performed to ensure that the state transitions of business objects conform to preset business rules. Furthermore, the Action layer generates detailed, tamper-proof audit logs, recording the operator, time, input parameters, and the state before and after the operation to meet compliance requirements. To handle execution failures, each Action is also designed with robust compensation and rollback logic to ensure the consistency of business data and the robustness of the system, avoiding data incompleteness or errors caused by operation failures.

[0032] The Tools layer encapsulates atomic, idempotent, and stateless operational capabilities, and exposes standardized calling interfaces through model context protocols or function call protocols; The Tools layer provides the most basic and fine-grained operational capabilities in the system. These capabilities are atomic (indivisible), idempotent (multiple executions of the same operation produce the same result without introducing side effects), and stateless (independent of previous operation states). Examples include "querying user information" and "calculating discounts." Tools provides standardized calling interfaces through a unified protocol (such as a model context protocol or function call protocol), allowing upper-layer components (such as the Skills layer or Agent orchestration layer) to flexibly combine and invoke these atomic capabilities to achieve various complex functions. This design enhances the system's flexibility and scalability, enabling new business logic to be quickly built by combining existing Tools.

[0033] The data semantic layer, as a unified world model, provides object type and attribute management, real-time calculation of derived attributes, versioned storage of concept sets, and unified data access interface for multiple protocols, and provides consistent data services to the Tools layer and Action layer above. The data semantic layer is the core data management and knowledge base of the entire intelligent agent application. It is responsible not only for defining and managing the types, data attributes, object attributes, and semantic relationships between business objects, but also for calculating derived attribute values ​​in real time based on raw data and event streams; for example, calculating a user's credit score based on transaction records. Furthermore, the data semantic layer is responsible for storing and managing different versions of concept sets, which include business rules, judgment conditions, and evidence lists. To facilitate data access for upper-layer components, the data semantic layer provides a unified data access interface for various protocols (such as RESTful, GraphQL, and SQL). By providing consistent data services, the data semantic layer ensures that all upper-layer components adhere to the same semantics and specifications when accessing data, thereby guaranteeing the accuracy, consistency, and real-time performance of the data upon which the intelligent agent's decisions depend.

[0034] In some possible embodiments, the capabilities of the Action layer and Tools layer are implemented according to a five-dimensional boundary criterion, including: Operations that satisfy the following criteria are encapsulated as Actions: changing the persistent state of a business object, writing back to the production database of the business system, having a high compliance audit level, having clear pre- and post-state machine constraints, and sharing any two of the criteria across three or more Agents or Skills. Operations that only generate in-memory intermediate artifacts, read external resources only, have a medium to low audit level, have no state dependencies, and whose implementation logic can be deployed in a distributed manner are encapsulated as Tools. Before an Action is executed, it must pass fine-grained permission verification through the data semantic layer and generate an immutable audit record containing the operator, time, input parameters, and previous and subsequent states. If the execution fails, compensation and rollback logic will be automatically triggered. Object query operations in Tools must be relayed through the unified application programming interface of the data semantic layer and direct connection to the business system database is prohibited.

[0035] As an implementation approach, the capabilities of the Action and Tools layers are assigned according to the five-dimensional boundary criterion, which refers to establishing a structured classification method for various operational capabilities in intelligent agent applications. This "five-dimensional boundary criterion" provides a systematic framework for evaluating and determining whether an operation should belong to the Action or Tools layer, thereby ensuring architectural consistency and clear responsibilities. This criterion can serve as a guiding principle during the system design and development phases. Through configuration management or metadata definition, the classification results of each operation can be solidified and enforced during system runtime.

[0036] Specifically, operations that meet any two of the following criteria are encapsulated as Actions: changing the persistent state of a business object, writing back to the production database of the business system, having a high compliance audit level, having explicit pre- and post-state machine constraints, and sharing a common understanding across three or more Agents or Skills. "Changing the persistent state of a business object" means the operation modifies core data stored long-term in the business system, such as updating user profiles or order status. "Writing back to the production database of the business system" means the operation directly affects the core data storage of the business system. "High compliance audit level" indicates that the operation involves sensitive data or critical business processes, requiring strict auditing and traceability. "Explicit pre- and post-state machine constraints" means the operation will migrate a business object from one defined state to another with strict conditions. "Sharing a common understanding across three or more Agents or Skills" emphasizes the high reusability and criticality of the operation within the system. When an operation meets any two of the above conditions, it is considered a high-risk, high-impact operation and should be encapsulated as an Action to leverage the strict control and protection mechanisms provided by the Action layer.

[0037] Accordingly, operations that produce only in-memory intermediate artifacts, are read-only external resources, have a low to medium audit level, are stateless, and whose implementation logic can be distributed are encapsulated as Tools. "Produces only in-memory intermediate artifacts" means the operation's output is temporary and not persistently stored. "Read-only external resources" means the operation only retrieves information from external systems without modifying it. "Low to medium audit level" implies relatively low compliance requirements. "Stateless" means the operation does not depend on or change any persistent state and can be executed independently. "Distributable implementation logic" means the operation's logic is self-contained and easily deployed and expanded independently in a distributed environment. Operations that meet these conditions are categorized as Tools to achieve their atomicity, idempotency, and statelessness characteristics, thereby improving the system's flexibility and scalability.

[0038] Furthermore, before an Action is executed, it must undergo fine-grained permission verification through the data semantic layer and generate an immutable audit log containing the operator, time, input parameters, and the state before and after the operation. In case of execution failure, compensation and rollback logic is automatically triggered. Before Action execution, the system utilizes the permission management capabilities provided by the data semantic layer to perform fine-grained permission verification on the entity requesting the Action, ensuring that only authorized entities can perform specific operations. Simultaneously, each Action execution generates a detailed, immutable audit log containing the executor of the operation, execution time, input parameters, and the state of the business object before and after the operation, ensuring traceability and compliance. If an Action fails during execution, the system will automatically initiate preset compensation or rollback logic to undo the executed portion of the operation or restore the system to its state before the operation, thereby ensuring the consistency of business data and the robustness of the system.

[0039] Meanwhile, object query operations within the Tools layer must be routed through the unified application programming interface (API) of the data semantic layer, prohibiting direct connections to the business system database. This means that when the Tools layer needs to query business object data, it cannot directly access the underlying business system database but must access the data through the unified API provided by the data semantic layer. As a unified data model and access point, the data semantic layer ensures that all data queries adhere to consistent definitions and semantics, applies data governance rules, calculates derived attributes in real time, and performs necessary access control. This mechanism effectively isolates the Tools layer from the underlying database, enhancing system security and data consistency.

[0040] In some possible embodiments, the Agent orchestration layer receives the task request and performs intent understanding and task classification. It then performs type matching routing in the registered Skill library. If a match is found, the corresponding Skill is executed via the fast channel; otherwise, the Skill is executed via the slow channel using dynamic programming tools. Receive batches of structured tasks or a single natural language request, perform idempotency checks on each task item, and generate a globally unique task identifier; The large language model is invoked to perform few-shot intent recognition for each task item, and the normalized task type label and confidence score are output. The registered Skill set is traversed, and the cosine matching degree is calculated based on the task type label and the applicable scenario label in the Skill metadata. If the matching degree reaches the preset threshold and the Skill is in an available state, it is determined to be a hit. Once a task is successfully executed, it enters the fast track path, directly calling the standardized interface of the corresponding Skill to execute and pass through the task parameters. Tasks that are not hit enter the slow path, where the large language model dynamically plans the directed acyclic graph sequence of tool calls based on the available tool list, tool descriptions, and task context, and schedules them for execution in sequence according to their dependencies.

[0041] As an implementation approach, this method can accept various forms of task input. For example, batch structured tasks can flow into the system via file uploads (such as CSV and JSON formats) or API calls, and the system will parse their predefined data structures. Single natural language requests typically originate from unstructured text submitted by users through text input boxes, speech recognition, or chat interfaces. To ensure the reliability of task processing, the system performs idempotency checks on each received task item. This is achieved by calculating the hash value of the task content, combining it with a unique combination of request parameters, or using a transaction ID provided by the source system to determine whether the task has already been processed, thus avoiding duplicate operations. Simultaneously, the system generates a globally unique task identifier for each task. This identifier remains unique throughout the entire system lifecycle, facilitating task tracking, auditing, and the correlation of subsequent processing results.

[0042] Upon receiving a task request, the system invokes a pre-trained large language model to perform few-shot intent recognition for each task. Specifically, by learning from a small number of task examples (i.e., few-shot learning), the large language model can understand the deep semantics of the task and output a normalized task type label. This label maps the task intent to a predefined standard classification system. Simultaneously, the large language model also outputs a confidence score, representing its confidence level in the intent recognition result. Subsequently, the system iterates through all registered Skills. Each Skill, upon registration, includes metadata describing its function and scope of application, including applicable scenario tags. The system vectorizes the task type label and the applicable scenario tags in the Skill's metadata and calculates their cosine similarity to quantify their semantic similarity. When the calculated matching score reaches a preset threshold, and the corresponding Skill is in an available state (e.g., not under maintenance, overload, or faulty), the system determines that the task matches one or more Skills.

[0043] For tasks that have successfully matched a specific Skill, the system routes them to the fast track path. The fast track represents an efficient and deterministic processing flow that bypasses complex dynamic programming. The Agent orchestration layer directly calls the standardized interfaces exposed by the corresponding Skill. These interfaces typically follow unified protocol specifications (such as RESTful APIs or gRPC), ensuring ease of use and compatibility. During the call, the relevant parameters in the original task request are passed directly to the called Skill after necessary format conversion, allowing it to execute its core business logic.

[0044] When a task cannot directly match any registered Skill, the system routes it to the slow channel. The slow channel is designed to handle complex, non-standard tasks or those requiring flexible composition capabilities. In this channel, the Agent orchestration layer leverages the powerful reasoning capabilities of a large language model, combined with the system's maintained list of available Tools, detailed descriptions of each Tool (including functionality, inputs, outputs, limitations, etc.), and the contextual information of the current task (such as the original request, identified partial intents, intermediate processing states, etc.), to dynamically plan a sequence of Tool invocations. This sequence is typically represented as a Directed Acyclic Graph (DAG), clearly defining the dependencies and execution order between Tools. The Agent orchestration layer then parses this DAG and, according to the defined dependencies, schedules the execution of the corresponding Tools sequentially, using the output of one Tool as the input of the next, until the task is completed.

[0045] In some possible embodiments, Skill internally calls Tools and Actions according to a predefined deterministic directed acyclic graph step sequence to complete core business judgments. The core judgment logic is executed based on the concept set production rules and object derived attribute engine in the data semantic layer, including: After receiving the structured task input, Skill performs Schema validation of the input parameters and executes the directed acyclic graph step by step according to the predefined steps. This step aims to ensure that the input data for Skill processing tasks conforms to the expected format and specifications, thereby avoiding subsequent processing failures or logical deviations due to incorrect data formatting. Schema validation can be implemented using JSON Schema, XML Schema, or other data validation frameworks to rigorously check the field types, value ranges, and required fields of the input data. The predefined directed acyclic graph (DAG) clarifies the execution order and dependencies of various operations within the Skill, ensuring the determinism and controllability of business logic. For example, a Skill processing medical diagnoses might have inputs including patient ID, symptom description, and test report URLs. Schema validation ensures the existence and correct format of these fields, while the DAG specifies the order of querying patient history, retrieving test results, and finally performing rule checks.

[0046] The full set of original attribute data and real-time calculated derived attribute values ​​of the target business object can be obtained in batches through the object query tool corresponding to the data semantic layer. This step aims to provide comprehensive, accurate, and real-time foundational data for core business decisions. The data semantic layer, acting as a unified world model, integrates business object data from different source systems and provides a consistent access interface. The object query tool interacts with the data semantic layer, batch retrieving all original attributes of the target business object (such as basic patient information and medical history) and derived attribute values ​​calculated in real-time by the derived attribute engine (such as the number of visits in the past 30 days, the average value of specific indicators, and the existence of diagnostic codes). Batch acquisition improves data retrieval efficiency, while real-time calculation ensures the timeliness of the judgment criteria.

[0047] Load the highest version concept set that matches the current task type. The concept set includes payment condition production rules, required diagnostic code set, time window constraints, optional evidence list and exclusion rules. This step forms the knowledge foundation for core business judgments. The concept set is a structured representation of domain knowledge, encapsulating the judgment logic and required evidence for specific business scenarios. Loading the "highest version" ensures that the latest, validated business rules are always used. The concept set includes: payment condition production rules, defining the logical expressions required to satisfy specific payment or business processing conditions; a set of essential diagnostic codes, specifying the diagnostic codes necessary for a particular judgment or processing; time window constraints, defining the conditions under which certain events or data must occur within a specific timeframe; a list of optional evidence, listing evidence items that can support the judgment but are not mandatory, each potentially weighted for subsequent confidence calculations; and exclusion rules, defining the conditions under which the judgment result should be directly rejected.

[0048] The necessary condition conjunction check, time window constraint check, exclusion condition disjunction check, and optional evidence existence statistics are executed sequentially according to the production rules in the concept set to generate a Boolean-type deterministic judgment result and an evidence chain reference list. This step is the execution process for core business judgments. The system will strictly follow the rules defined in the concept set to perform logical reasoning: check whether all "essential conditions" are met; verify whether all conditions involving time constraints are within the specified range; check whether any "exclusion rule" has been triggered, which will directly lead to a negative judgment; and count the number of pieces of evidence and their weights obtained in the "optional evidence list" to provide a basis for subsequent confidence calculations. Finally, these checks will generate a clear Boolean judgment result (true / false) and a detailed list of evidence chain references, recording all data and rules involved in the judgment, ensuring the transparency and traceability of the judgment process.

[0049] The large language model is invoked to generate natural language output text that conforms to the domain document specifications based on the deterministic judgment results and the structured evidence chain. The large language model does not participate in any conditional judgment logic. This step clarifies the supporting role of the large language model in this method. After completing the aforementioned deterministic, rule-driven core business judgments, the large language model is used to transform the structured judgment results and evidence chains into human-readable natural language text that conforms to the document norms of specific fields (such as medical, legal, and financial). For example, "diagnosed with hypertension, meeting reimbursement conditions, evidence: patient age 65, diagnosis code ICD-10 I10" is transformed into a standardized medical report or approval opinion. The emphasis on "the large language model not participating in any conditional judgment logic" is to ensure the accuracy, compliance, and interpretability of the core business judgments, and to avoid the illusions or uncertainties that the large language model might introduce.

[0050] In some possible implementations, the overall confidence level is calculated based on a weighted average of three objective factors: historical success rate of the rule, completeness of evidence, and data quality, including: Get the Bayesian smoothing historical success rate of the concept set version used in the current task. The historical success rate is the ratio of the number of successful cases in the historical submissions of the concept set after Laplace smoothing to the total number of submissions. The application of Bayesian smoothing (such as Laplace smoothing) can effectively avoid extreme values ​​in the historical success rate caused by accidental factors when the number of historical submissions in the concept set is small, thus providing a more stable and representative rule performance indicator. This historical success rate is the ratio of the number of historical successful cases in the concept set to the total number of submissions. After smoothing, it can more accurately reflect the inherent reliability of the rule.

[0051] Calculate the evidence completeness factor, which is the ratio of the weighted number of optional evidence obtained in the current task to the total weighted number of optional evidence defined by the concept set, where key evidence has a higher weight than ordinary evidence; The evidence completeness factor quantifies the completeness of evidence by comparing the weighted number of available alternative evidence for the current task with the weighted number of available alternative evidence predefined in the concept set. Key evidence is given a higher weight to reflect its decisive role in business judgment and to ensure that the absence of important evidence significantly reduces confidence.

[0052] The data quality factor is calculated based on a weighted average of three sub-dimensions: the proportion of non-empty attributes of business objects, the offset between data timestamps and business time windows, and the consistency verification results of multi-source data. The data quality factor comprehensively considers multiple sub-dimensions, including the proportion of non-empty attributes of business objects (reflecting data fillability), the offset between data timestamps and business time windows (reflecting data timeliness), and the results of multi-source data consistency verification (reflecting data accuracy and reliability). By weighting these sub-dimensions, the quality of input data can be comprehensively evaluated, thereby avoiding judgment bias caused by data quality issues.

[0053] Configurable weights are assigned to the three objective factors, and the comprehensive confidence value is obtained by weighted summation and calibration with the Sigmoid function. The comprehensive confidence value ranges from 0 to 1. The system allows for flexible adjustment of the relative importance of historical success rate, evidence completeness, and data quality in the overall confidence score calculation based on different business scenarios, risk preferences, or domain expert experience. This configurability enhances the system's adaptability and flexibility. Through weighted summation, these three independent but complementary factors are integrated into a unified confidence score. Subsequently, the result of the weighted summation is calibrated using a sigmoid function, mapping it to a standardized range of 0 to 1. This makes the overall confidence score probabilistically interpretable, facilitating subsequent threshold judgments and tiered decision-making.

[0054] In some possible embodiments, three-level traffic splitting is performed based on a dual confidence threshold, including: Set two judgment thresholds: a high-confidence automatic execution threshold and a medium-confidence manual confirmation lower bound. The "high-confidence auto-execution threshold" defines the lower limit of confidence at which the system can execute tasks completely autonomously. It is typically set at a high level to ensure the accuracy and security of automated operations. The "medium-confidence human confirmation lower bound" distinguishes between tasks requiring simplified human confirmation and those requiring manual intervention; its value is lower than the high-confidence threshold. These two thresholds together divide the overall confidence space into three intervals, providing clear decision boundaries for the subsequent three-level triage. These thresholds are usually configurable, allowing system administrators or business experts to dynamically adjust them based on the risk appetite, compliance requirements, and automation goals of the actual business scenario.

[0055] When the overall confidence level is greater than or equal to the high confidence threshold, it is determined to be a high confidence task, and the corresponding Action is automatically executed and post-sampling verification is performed according to the preset sampling ratio; The system classifies the task as a high-confidence task and directly triggers the corresponding Action execution. This automated execution mode greatly improves processing efficiency. To further ensure the quality of automated operations and continuous model optimization, the system also performs post-execution sampling verification on the automatically executed Actions according to a preset sampling ratio. Post-execution sampling verification can include manual review, comparison with data from external systems, etc., aiming to discover potential anomalies or model deviations, providing a basis for subsequent concept set optimization and rule review.

[0056] When the overall confidence level is greater than or equal to the lower bound of the medium confidence level and less than the high confidence level threshold, it is determined to be a medium confidence task and transferred to the manual simplified confirmation queue. The manual simplified confirmation queue only displays the core judgment basis and conclusion, and executes the corresponding Action after receiving a single confirmation instruction. While these tasks don't reach full automation, their confidence level is relatively high, requiring only limited human intervention to complete the decision. Therefore, these tasks are transferred to a dedicated "simplified human confirmation queue." In this queue, the system intelligently extracts and presents only the core judgment criteria and final conclusion to the human operator, avoiding redundant information and significantly reducing the time required for human confirmation. After a quick review, the operator only needs to receive a simple confirmation command (e.g., clicking the "confirm" button), and the system will execute the corresponding action. This model maximizes the efficiency of human review while ensuring decision accuracy.

[0057] When the overall confidence level is less than the lower bound of the medium confidence level or the task does not match any concept set, it is judged as a low confidence task and transferred to the human-led processing queue. The agent only performs auxiliary operations such as multi-source data retrieval, evidence chain organization, and document draft generation.

[0058] The system classifies the task as a low-confidence task and transfers it to the "human-led processing queue." In this mode, the human operator becomes the decision-maker, while the intelligent agent plays a supporting role. The intelligent agent proactively performs multi-source data retrieval, collecting task-related evidence from different data sources; it organizes the retrieved evidence to form a clear chain of evidence; and based on the existing information, it generates a draft document, providing the human operator with decision-making references and a working basis. This support mode ensures that complex or highly uncertain tasks can be handled professionally by humans, while reducing repetitive work for human operators.

[0059] In some possible embodiments, the data semantic layer, as a unified world model, provides object type and attribute management, derived attribute computation, versioned storage of concept sets, and a unified data access interface across multiple protocols, including: The ontology modeling approach is used to define business object types, data attributes, object attributes and semantic relationships, and to maintain object multi-version chains and full-link data lineage. Ontology modeling is a formal knowledge representation method that constructs a domain knowledge graph by defining concepts, attributes, and relationships, enabling machines to clearly understand and process business objects and their interrelationships. For example, a "patient" can be defined as a business object type, containing data attributes such as "name" and "age," as well as associations with object attributes such as "medical records." Maintaining a multi-version chain of objects means that any changes to the definition of a business object are recorded and versioned, ensuring that historical data can be correctly parsed and understood at different points in time. End-to-end data lineage provides a complete traceability path for data from its source to its final use, which is crucial for data quality auditing, problem investigation, and compliance requirements.

[0060] The incremental derived attribute engine calculates derived attribute values ​​in real time based on the original attributes and event stream. The derived attributes include sliding time window aggregation statistics, diagnostic code existence marking, test index threshold judgment and composite business indicators. Derived attributes are those attributes that are not directly stored but are dynamically calculated based on other original attributes or events. Incremental computation means that the engine only processes changed data or newly incoming events, rather than recalculating the entire dataset, thus significantly improving computational efficiency and real-time performance. For example, derived attributes can include aggregated statistics on specific indicators within a sliding time window (such as "average body temperature over the past 24 hours"), diagnostic code presence markers based on specific codes (such as ICD codes) (such as "whether a diabetes diagnosis exists"), threshold judgments on test indicators (such as "whether blood glucose is excessive"), and composite business indicators composed of multiple indicators (such as "patient risk score").

[0061] Maintain a versioned concept set library. Each concept set contains a globally unique rule identifier, applicable scenario label, production rule judgment conditions, evidence weight list, historical successful case feature vector, historical failed case feature vector, semantic version number and Bayesian statistical information. A globally unique rule identifier ensures the uniqueness and traceability of each rule. Applicable scenario tags are used for rule matching and routing. Production judgment conditions are the core logic of the rule, typically expressed in "IF-THEN" form. An evidence weight list is used to evaluate the completeness and importance of the evidence required for rule judgment. Historical success case feature vectors and historical failure case feature vectors record the rule's performance in historical executions, providing a data foundation for rule optimization and confidence calculation. Semantic version numbers are used to manage rule iteration and evolution. Bayesian statistics are used to dynamically evaluate the reliability of the rules.

[0062] It provides Cohort queue definition and management, a distributed metric calculation engine, and supports filtering object sets by composite conditions and batch calculating time-series metrics. Cohort queues allow users to group business objects based on specific business criteria (such as age, diagnosis, treatment plan, etc.) for targeted analysis. The distributed metrics calculation engine can efficiently process large-scale data, batch-calculating various time-series metrics on objects in these Cohort queues, such as the long-term effects of specific treatment plans and the recurrence rate of a certain disease.

[0063] It also provides a unified application programming interface for three access protocols: RESTful, GraphQL, and SQL, and provides cross-source data query, object attribute reading, and semantic retrieval services for concept sets to the upper layer; This interface provides cross-source data querying, object attribute reading, and semantic retrieval services for concept sets to the upper layers. By providing multiple mainstream access protocols, the data semantic layer can adapt to the data access needs of different upper-layer components (such as the Tools layer and the Action layer), achieving flexible and efficient data interaction. The RESTful API is suitable for simple resource operations, the GraphQL API allows clients to retrieve data on demand to reduce network overhead, while the SQL interface facilitates complex data analysis and reporting. This unified interface design effectively shields the complexity of the underlying heterogeneous data sources, ensuring that upper-layer applications can access and utilize data with a consistent approach.

[0064] In some possible embodiments, asynchronous feedback results from external systems on submitted operations are received, the feedback data is structured, stored, and written back to the concept set library of the data semantic layer, triggering statistical updates, rule reviews, and version iterations of the concept set, including: The system listens for asynchronous feedback results from external systems via the event bus. The feedback results include a binary acceptance / rejection flag, a structured feedback reason code, a free text feedback description, and a feedback timestamp. As a decoupled communication mechanism, the event bus can efficiently collect asynchronous feedback from different external systems, ensuring the real-time nature and completeness of the feedback information. Specifically, binary accept / rejection flags clearly indicate the final result of the operation, structured feedback reason encoding provides standardized classification of failure reasons, free text feedback descriptions supplement more detailed contextual information, and feedback timestamps record the precise moment the feedback occurred. All of this information together constitutes a comprehensive evaluation of the agent's operational results.

[0065] The feedback data is immutably associated and stored with the overall confidence level when the corresponding task was submitted, the concept set identifier used, the semantic version number of the concept set, the hash value of the evidence chain based on the judgment, and the feature vector at the time of submission. This immutable, associated storage mechanism, typically implemented through blockchain technology or cryptographic hash chains, ensures a strong binding between feedback data and the original decision context, preventing data tampering and providing a reliable foundation for subsequent rule auditing, review, and traceability. The overall confidence level reflects the system's confidence level during decision-making; the concept set identifier and semantic version number indicate the specific rule version used at the time; the hash value of the evidence chain solidifies all evidence relied upon for the decision; and the feature vector at the time of submission records the original input state of the task. This metadata is crucial for understanding the causes of the feedback results.

[0066] Based on the feedback results, the historical success rate or historical failure rate of the corresponding concept set version is atomically updated, and the posterior historical success rate of the concept set is recalculated using the Bayesian incremental update method. Atomic updates ensure the integrity of data operations and avoid data inconsistencies caused by concurrent updates. Bayesian incremental updates are a statistical method that smoothly and gradually adjusts the historical success rate of a concept set based on new feedback data, making it more accurately reflect the actual performance of the current rules. This dynamic update mechanism makes rule evaluation no longer static, but capable of continuously learning and adapting to new business scenarios and data distributions.

[0067] Check whether the rule review conditions are triggered. The rule review conditions include the number of consecutive failures of the same concept set version within the sliding time window reaching the failure threshold, or the new concept set version completing the feedback observation period of the preset sample size, or the historical success rate of the concept set being lower than the preset lower threshold. These review conditions are crucial for the system's self-monitoring and self-optimization. For example, if a version of a concept set fails consecutively within a short period, it indicates potential defects or changes in its applicability; new version rules require an observation period to accumulate sufficient feedback data before comprehensive evaluation; and a historical success rate below a preset threshold directly indicates a severe decline in rule performance. These conditions collectively constitute the "health monitoring" mechanism of the agent's rule base.

[0068] When the debriefing conditions are triggered, a rule review task containing clustering results of failed case features is automatically generated and enters the domain expert review queue. The modified rules that have been approved by experts are received and a new semantic version number is generated. The old version is retained for retrospective comparison. Failure case feature clustering results help domain experts quickly pinpoint the root cause of rule failures, such as specific input patterns, data anomalies, or defects in the rule logic itself. Domain experts then manually intervene and optimize the rules in the review queue, revising them based on their expertise. The revised rules generate new semantic version numbers to distinguish between different versions, while older versions are retained to support historical review, performance comparison, and risk control, ensuring the manageability and traceability of rule evolution.

[0069] In some possible embodiments, the construction of the data semantic layer is performed using a two-stage experience-accumulation path, including: During the cold start phase, collect all historical business processing records within a preset time range and perform data cleaning processes such as entity alignment, field standardization, drug and diagnosis code mapping, and association of multi-source patient master indexes. First, the system collects all historical business processing records within a preset time range. These records may come from different data sources, have different formats, and contain redundancy or missing information. Therefore, a rigorous data cleaning process is necessary, including but not limited to: unifying the identification of identical entities across different systems (entity alignment), ensuring consistency in data format and meaning across different fields (field standardization), mapping domain-specific codes (such as drug and diagnostic codes) to a unified terminology system, and linking patient information from different data sources to form a complete patient master index. These cleaning steps aim to eliminate data heterogeneity, improve data quality and consistency, and provide reliable input for subsequent rule extraction and concept set generation.

[0070] Historical records are grouped and aggregated according to business entity type and violation type. A large language model is invoked to perform batch analysis of the feature vectors of successful cases and failure cases for each group based on a few sample prompts. A draft concept set containing production rules, evidence list and initial statistics is generated. For each group, the system invokes a large language model to perform batch analysis of the feature vectors of successful and failed cases for each group based on few-sample prompts. Leveraging its powerful semantic understanding and pattern recognition capabilities, the large language model identifies key feature patterns leading to success or failure by providing a small number of examples, and extracts these patterns into preliminary production rules, a list of required evidence, and relevant initial statistics. This generates a draft concept set containing production rules, a list of evidence, and initial statistics. These outputs collectively constitute the draft concept set, laying the foundation for subsequent expert review and formal release.

[0071] Organizational domain professionals conduct centralized reviews of concept set drafts using a double-blind review process to confirm the logic of judgment conditions, the allocation of evidence weights, and the boundaries of rule application. Concept sets that pass the review are assigned an initial version number and enter the formal concept set library. The draft concept set generated by the large language model is not immediately put into use but undergoes rigorous manual verification. A double-blind review process reduces subjective bias and improves objectivity and accuracy. Experts carefully examine the logic of the decision conditions in the draft to ensure they align with business realities and compliance requirements, assess the appropriate weighting of various pieces of evidence, and clarify the applicable boundaries of each rule. Once approved, the concept set is assigned an initial version number and added to the official concept set repository, thus qualifying it for use in the production environment.

[0072] During the operation phase, real-time business traffic from the production environment is accessed, and a conservative strategy is adopted to gradually increase the automation ratio. When a new business type flows in, new rules are triggered to extract skills and automatically generate a concept set draft, which is then reviewed and approved by experts before entering the official library. The goal of this phase is to continuously validate, adjust, and expand the concept set using real-time business traffic and feedback data, enabling it to adapt to constantly changing business needs and data patterns, and achieving autonomous evolution of the concept set. During this phase, the system will connect to real-time business traffic from the production environment and gradually increase the automation rate using a conservative strategy. Initially, a conservative strategy will be adopted, gradually increasing the proportion of automated processing to avoid large-scale errors caused by incomplete initial rules. When a new business type enters the system, the system will trigger a new rule extraction skill to automatically generate a draft concept set. This skill can automatically analyze the characteristics of the new business and generate a draft concept set for the new business using a method similar to the cold start phase. These drafts also need to be reviewed and approved by experts before entering the official repository, allowing the system to quickly respond to and adapt to new business needs.

[0073] Based on the asynchronous feedback data generated during operation, the judgment rules, evidence weights and threshold parameters of the existing concept set are continuously and incrementally optimized to achieve the autonomous evolution of the concept set library; The system continuously receives asynchronous feedback data (such as success, failure, and rejection reasons) from external systems regarding submitted operations. This feedback data is a valuable learning resource. The system uses this feedback to incrementally update and optimize the judgment rules, weights of various pieces of evidence, and related threshold parameters in the existing concept set. For example, if the historical failure rate of a certain concept set increases, the system may trigger a rule review and adjust the rules or evidence weights based on the characteristics of failed cases. This continuous optimization mechanism based on real-time feedback enables the concept set library to evolve autonomously.

[0074] In some possible embodiments, the concept set includes rule identifiers, applicable scenarios, a list of required conditions, time constraint rules, a list of optional evidence, a list of exclusion conditions, feature vectors of historical successful cases, feature vectors of historical failed cases, version numbers, creation time, last update time, and statistical fields. The statistics fields include total number of submissions, number of successful submissions, number of failed submissions, and number of consecutive failures. When performing a judgment on a set of concepts, first check whether all necessary conditions are met, then check whether there are any exclusion conditions, and finally count the number of optional evidences that are met. A negative judgment result is generated when any essential condition is not met or when there is an exclusion condition; a positive judgment result is generated when all essential conditions are met and there is no exclusion condition.

[0075] Specifically, the constituent elements of a concept set aim to comprehensively describe all aspects of a business judgment rule. The rule identifier is a unique code used to identify the concept set, which can take the form of a globally unique identifier (UUID), a business domain-specific encoding rule, or a hash value, ensuring the traceability of each rule. The applicable scenarios clarify the business context or task type to which the concept set applies. For example, its application scope can be limited through tags, keywords, or structured descriptions, allowing the Agent orchestration layer to perform precise matching during task routing. The list of mandatory conditions contains a set of conditions that must be met; these conditions are mandatory prerequisites for business judgments. For example, in a payment approval scenario, it might require "sufficient user account balance" or "transaction amount within limits." Each mandatory condition can be defined as a specific attribute value of a business object in the data semantic layer meeting a preset range, or a specific logical relationship existing between multiple attributes. Time constraint rules are used to limit the time window or sequence requirements for business judgments, such as "applications must be submitted on working days" or "an event must be completed within 24 hours of another event occurring." This can be implemented by defining an absolute time range, a relative time offset, or the order of event occurrence. The optional evidence list contains a set of non-mandatory but helpful evidence items that enhance the confidence level of the judgment. For example, in medical diagnosis, in addition to the required test results, there may be "patient's past medical history" or "family genetic history" as optional evidence. Each piece of evidence can be assigned a different weight to reflect its importance in the confidence calculation. The exclusion criteria list contains a set of high-priority conditions. Once any one of these conditions is met, regardless of the other conditions, it will directly lead to a negative judgment result. For example, "the user is blacklisted" or "the transaction has fraud risk characteristics." The historical success case feature vector and historical failure case feature vector are used to store key feature data of successful or failed cases of this concept set in historical execution. This feature data can be used for subsequent rule review and optimization, as well as as input for training machine learning models to achieve adaptive rule evolution. The version number, creation time, and last update time are used to manage the lifecycle of the concept set, supporting rule version iteration, backtracking, and auditing.

[0076] The statistical fields are quantitative indicators of the performance of the concept set. Total submissions record the total number of times the concept set has been used for judgment, reflecting its activity level. Success counts record the number of times the concept set's judgment result was positive and subsequent business operations were confirmed as successful by an external system; this is a key indicator of rule effectiveness. Failure counts record the number of times the concept set's judgment result was positive but subsequent business operations failed, or the judgment result was negative but should have been positive; this is used to identify rule defects or deficiencies. Consecutive failure counts record the number of consecutive judgment failures for the concept set; when a preset threshold is reached, a rule review mechanism can be triggered, alerting domain experts to intervene and review the rule.

[0077] When performing judgments on the concept set, this embodiment employs a clear priority and logically rigorous judgment process. First, the system checks if all necessary conditions are met. If any necessary condition is not met, the judgment process terminates immediately, generating a negative judgment result without further evaluation of other conditions. This ensures strict adherence to the mandatory requirements of business rules. Second, assuming all necessary conditions are met, the system further checks for any exclusionary conditions. If any exclusionary condition is met, the judgment process also terminates immediately, generating a negative judgment result. This demonstrates the high priority and rapid rejection capability of exclusionary conditions. Finally, only when all necessary conditions are met and no exclusionary conditions exist will the system count the number of satisfied optional evidence. The statistical results of these optional evidence will be used for subsequent comprehensive confidence calculations but will not directly affect the generation of affirmative or negative judgment results. Ultimately, the system generates an affirmative judgment result only when all necessary conditions are met and no exclusionary conditions exist; conversely, a negative judgment result will be generated if any necessary condition is not met or if an exclusionary condition exists.

[0078] It should be noted that the above description describes some embodiments of the present invention. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than that shown in the above embodiments and still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0079] Secondly, based on the same inventive concept, corresponding to any of the above-described embodiments, such as... Figure 2 As shown in the embodiments of this application, an intelligent agent application system based on a data semantic layer and a hierarchical hybrid architecture is also provided, including: Architecture building unit 100 is used to build a five-layer hierarchical hybrid architecture consisting of Agent orchestration layer, Skills layer, Tools layer, Action layer and data semantic layer, and to define the responsibility boundaries of each layer and cross-layer call constraints; The task routing unit 200 is used by the Agent orchestration layer to receive task requests and complete intent understanding and task classification. It performs type matching routing in the registered Skill library. If a match is found, it enters the fast channel to call the corresponding Skill for execution. If no match is found, it enters the slow channel to dynamically plan and combine tools for execution. The deterministic judgment unit 300 is used to call Tools and Action to complete the core business judgment within Skill according to the predefined deterministic directed acyclic graph step sequence. The core judgment logic is executed based on the concept set production rules and object derived attribute engine in the data semantic layer. The large language model does not participate in the condition judgment. The confidence calculation unit 400 is used to calculate the comprehensive confidence based on three objective factors: historical success rate of rules, completeness of evidence and data quality, and to perform three-level diversion based on the dual threshold of confidence. The graded execution unit 500 is used to automatically execute Actions and perform proportional post-event sampling checks when the confidence level is high; when the confidence level is medium, it is transferred to the manual simplified confirmation queue; and when the confidence level is low, it is transferred to manual-led processing. Feedback Evolution Unit 600 is used to receive asynchronous feedback results from external systems for submitted operations, store the feedback data in association with the submission context, and write it back to the concept set library of the data semantic layer, triggering statistical updates, rule reviews, and version iterations of the concept set.

[0080] The system described above is used to implement the corresponding methods in the foregoing embodiments and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0081] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for applying intelligent agents based on a data semantic layer and a hierarchical hybrid architecture, characterized in that, include: A five-layer hierarchical hybrid architecture consisting of Agent orchestration layer, Skills layer, Tools layer, Action layer and data semantic layer is constructed, and the responsibility boundaries of each layer and cross-layer call constraints are defined. The Agent orchestration layer receives task requests and completes intent understanding and task classification. It then performs type matching routing in the registered Skill library. If a match is found, the corresponding Skill is executed in the fast channel. Otherwise, the Skill is executed in the slow channel using dynamic programming tools. Skill internally calls Tools and Action to complete core business judgments according to a predefined deterministic directed acyclic graph step sequence. The core judgment logic is executed based on the concept set production rules and object derived attribute engine in the data semantic layer. The large language model does not participate in the condition judgment. The comprehensive confidence level is calculated by weighting three objective factors: historical success rate of rules, completeness of evidence, and data quality. Three-level diversion is then performed based on the two confidence level thresholds. High-confidence tasks are automatically executed with actions and then randomly checked according to a certain proportion; medium-confidence tasks are transferred to a manual simplified confirmation queue; and low-confidence tasks are transferred to a manual-led processing queue. Receive asynchronous feedback results from external systems for submitted operations, store the feedback data in association with the submission context, and write it back to the concept set library of the data semantic layer, triggering statistical updates, rule reviews, and version iterations of the concept set.

2. The intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture according to claim 1, characterized in that, Construct a five-layer hierarchical hybrid architecture consisting of an Agent orchestration layer, Skills layer, Tools layer, Action layer, and data semantic layer, defining the responsibility boundaries of each layer and cross-layer call constraints, including: The Agent orchestration layer is responsible for unstructured request parsing, task directed acyclic graph decomposition, Skill / Tool routing decision-making, confidence fusion calculation, and human-in-the-loop dynamic routing. It only calls the Skills layer or Tools / Action layer through standardized interfaces and prohibits direct access to the raw data interface of the data semantic layer. The Skills layer encapsulates a complete scenario-level workflow that has been validated by regression. Internally, it orchestrates the call sequence of multiple Tools and Actions according to deterministic steps, and externally exposes JSON Schema-compliant input and output interfaces for the Agent orchestration layer to call directly. The Action layer encapsulates decision-making operations involving business object state transitions and high compliance audit requirements. Each Action includes precondition assertions, state machine transition verification, immutable audit logs, and compensation rollback logic. The Tools layer encapsulates atomic, idempotent, and stateless operational capabilities, and exposes standardized calling interfaces through model context protocols or function call protocols; The data semantic layer, as a unified world model, provides object type and attribute management, real-time calculation of derived attributes, versioned storage of concept sets, and a unified data access interface for multiple protocols, while providing consistent data services to the Tools layer and Action layer above.

3. The intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture according to claim 2, characterized in that, The capabilities of the Action and Tools layers are implemented based on the five-dimensional boundary criteria, including: Operations that satisfy the following criteria are encapsulated as Actions: changing the persistent state of a business object, writing back to the production database of the business system, having a high compliance audit level, having clear pre- and post-state machine constraints, and sharing any two of the criteria across three or more Agents or Skills. Operations that only generate in-memory intermediate artifacts, read external resources only, have a medium to low audit level, have no state dependencies, and whose implementation logic can be deployed in a distributed manner are encapsulated as Tools. Before an Action is executed, it must pass fine-grained permission verification through the data semantic layer and generate an immutable audit record containing the operator, time, input parameters, and previous and subsequent states. If the execution fails, compensation and rollback logic will be automatically triggered. Object query operations in Tools must be relayed through the unified application programming interface of the data semantic layer and direct connection to the business system database is prohibited.

4. The intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture according to claim 1, characterized in that, The Agent orchestration layer receives task requests and performs intent understanding and task classification. It then performs type matching routing in the registered Skill library. If a match is found, the corresponding Skill is executed via the fast track; otherwise, the Skill is executed via the slow track using dynamic programming tools. Receive batches of structured tasks or a single natural language request, perform idempotency checks on each task item, and generate a globally unique task identifier; The large language model is invoked to perform few-shot intent recognition for each task item, and the normalized task type label and confidence score are output. The registered Skill set is traversed, and the cosine matching degree is calculated based on the task type label and the applicable scenario label in the Skill metadata. If the matching degree reaches the preset threshold and the Skill is in an available state, it is determined to be a hit. Once a task is successfully executed, it enters the fast track path, directly calling the standardized interface of the corresponding Skill to execute and pass through the task parameters. Unsuccessful tasks enter the slow path, where the large language model dynamically plans the directed acyclic graph sequence of tool calls based on the available tool list, tool descriptions, and task context, and schedules them for execution sequentially according to dependencies.

5. The intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture according to claim 1, characterized in that, Internally, Skill calls Tools and Actions according to a predefined deterministic directed acyclic graph step sequence to complete core business judgments. The core judgment logic is executed based on the production rules of the concept set in the data semantic layer and the object derived attribute engine, including: After receiving the structured task input, Skill performs Schema validation of the input parameters and executes the directed acyclic graph step by step according to the predefined steps. The full set of original attribute data and real-time calculated derived attribute values ​​of the target business object can be obtained in batches through the object query tool corresponding to the data semantic layer. Load the highest version concept set that matches the current task type, the concept set including payment condition production rules, mandatory diagnostic code set, time window constraints, optional evidence list and exclusion rules; The necessary condition conjunction check, time window constraint check, exclusion condition disjunction check, and optional evidence existence statistics are executed sequentially according to the production rules in the concept set to generate a Boolean-type deterministic judgment result and an evidence chain reference list. The large language model generates natural language output text that conforms to domain document specifications based on deterministic judgment results and structured evidence chains. The large language model does not participate in any conditional judgment logic.

6. The intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture according to claim 1, characterized in that, The overall confidence level is calculated based on a weighted average of three objective factors: historical success rate of the rule, completeness of evidence, and data quality. This includes: Obtain the historical success rate of the Bayesian smoothing of the concept set version used in the current task, wherein the historical success rate is the ratio of the number of successful cases in the historical submissions of the concept set after Laplace smoothing to the total number of submissions; Calculate the evidence completeness factor, which is the ratio of the weighted number of optional evidence obtained in the current task to the total weighted number of optional evidence defined by the concept set, wherein the weight of key evidence is higher than that of ordinary evidence; Calculate the data quality factor, which is generated by weighting three sub-dimensions: the proportion of non-empty attributes of business objects, the offset between data timestamps and business time windows, and the consistency verification results of multi-source data. Configurable weights are assigned to the three objective factors, and a comprehensive confidence value is obtained by weighted summation and calibration with the Sigmoid function. The comprehensive confidence value ranges from 0 to 1.

7. The intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture according to claim 1, characterized in that, Three-level traffic splitting is performed based on a dual confidence threshold, including: Set two judgment thresholds: a high-confidence automatic execution threshold and a medium-confidence manual confirmation lower bound. When the overall confidence level is greater than or equal to the high confidence threshold, it is determined to be a high confidence task, and the corresponding Action is automatically executed and post-sampling verification is performed according to the preset sampling ratio; When the overall confidence level is greater than or equal to the lower bound of the medium confidence level and less than the high confidence level threshold, it is determined to be a medium confidence task and transferred to the manual simplified confirmation queue. The manual simplified confirmation queue only displays the core judgment basis and conclusion, and executes the corresponding Action after receiving a single confirmation instruction. When the overall confidence level is less than the lower bound of the medium confidence level or the task does not match any concept set, it is judged as a low confidence task and transferred to the human-led processing queue. The agent only performs auxiliary operations such as multi-source data retrieval, evidence chain organization, and document draft generation.

8. The intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture according to claim 1, characterized in that, Receive asynchronous feedback results from external systems for submitted operations, store the feedback data in a structured manner, and write it back to the concept set library of the data semantic layer, triggering statistical updates, rule reviews, and version iterations of the concept set, including: The system listens for asynchronous feedback results from external systems via an event bus. These feedback results include a binary acceptance / rejection flag, a structured feedback reason encoding, a free text feedback description, and a feedback timestamp. The feedback data is immutably associated and stored with the overall confidence level when the corresponding task was submitted, the concept set identifier used, the semantic version number of the concept set, the hash value of the evidence chain based on the judgment, and the feature vector at the time of submission. Based on the feedback results, the historical success rate or historical failure rate of the corresponding concept set version is atomically updated, and the posterior historical success rate of the concept set is recalculated using the Bayesian incremental update method. Check whether the rule review conditions are triggered. The rule review conditions include the number of consecutive failures of the same concept set version within the sliding time window reaching the failure threshold, or the new concept set version completing the feedback observation period of the preset sample size, or the historical success rate of the concept set being lower than the preset lower threshold. When the review conditions are triggered, a rule review task containing clustering results of failed case features is automatically generated and enters the domain expert review queue. The modified rules approved by the experts are received and a new semantic version number is generated. The old version is retained for retrospective comparison.

9. The intelligent agent application method based on a data semantic layer and a hierarchical hybrid architecture according to claim 1, characterized in that, The construction of the data semantic layer adopts a two-stage experience accumulation path, including: During the cold start phase, collect all historical business processing records within a preset time range and perform data cleaning processes such as entity alignment, field standardization, drug and diagnosis code mapping, and association of multi-source patient master indexes. Historical records are grouped and aggregated according to business entity type and violation type. A large language model is invoked to perform batch analysis of the feature vectors of successful cases and failure cases for each group based on a few sample prompts. A draft concept set containing production rules, evidence list and initial statistics is generated. Organizational domain professionals conduct centralized reviews of concept set drafts using a double-blind review process to confirm the logic of judgment conditions, the allocation of evidence weights, and the boundaries of rule application. Concept sets that pass the review are assigned an initial version number and enter the formal concept set library. During the operation phase, real-time business traffic from the production environment is accessed, and a conservative strategy is adopted to gradually increase the automation ratio. When a new business type flows in, new rules are triggered to extract skills and automatically generate a concept set draft, which is then reviewed and approved by experts before entering the official library. Based on the asynchronous feedback data generated during operation, the judgment rules, evidence weights, and threshold parameters of the existing concept set are continuously and incrementally optimized to achieve the autonomous evolution of the concept set library.

10. An intelligent agent application system based on a data semantic layer and a hierarchical hybrid architecture, characterized in that, include: The architecture building unit is used to construct a five-layer hierarchical hybrid architecture consisting of an Agent orchestration layer, a Skills layer, a Tools layer, an Action layer, and a data semantics layer, defining the responsibility boundaries of each layer and cross-layer call constraints; The task routing unit is used by the Agent orchestration layer to receive task requests and complete intent understanding and task classification. It performs type matching routing in the registered Skill library. If a match is found, it enters the fast channel to call the corresponding Skill for execution. If no match is found, it enters the slow channel to dynamically plan and combine tools for execution. The deterministic judgment unit is used to call Tools and Actions to complete core business judgments within Skill according to a predefined deterministic directed acyclic graph step sequence. The core judgment logic is executed based on the concept set production rules and object derived attribute engine in the data semantic layer. The large language model does not participate in the condition judgment. The confidence calculation unit is used to calculate the comprehensive confidence score based on three objective factors: historical success rate of rules, completeness of evidence, and data quality, and to perform three-level triage based on the dual thresholds of confidence score. The hierarchical execution unit is used to automatically execute Actions and perform proportional post-event sampling checks when the confidence level is high; when the confidence level is medium, it is transferred to the manual simplified confirmation queue; and when the confidence level is low, it is transferred to manual-led processing. The feedback evolution unit is used to receive asynchronous feedback results from external systems for submitted operations, store the feedback data in association with the submission context, and write it back to the concept set library of the data semantic layer, triggering statistical updates, rule reviews, and version iterations of the concept set.

Images