An ontology matrix-based autonomous finance and tax intelligent agent system and method

Abstract

The application provides an autonomous finance and tax intelligent agent system based on an ontology matrix and an implementation method. The system comprises: a dispatching hub module for receiving a finance and tax task request, generating a task context comprising a task identifier, an enterprise identifier and an accounting period, and arranging a task execution process; an ontology service module for storing and managing the ontology matrix; a decision service module for storing and executing a decision model, the decision model comprising finance and tax business rules and human-machine collaboration boundary rules; an audit service module for generating, storing and verifying a full-process decision evidence chain, the decision evidence chain being implemented by a hash chain to prevent tampering; and an execution layer module for executing specific finance and tax operations according to the output of the decision service module. The application separates the ontology matrix and the DMN decision model, so that the finance and tax rules are independently stored and dynamically updated in the form of standardized decision models, and the policy changes can be quickly responded without modifying the code, thereby greatly reducing the maintenance cost.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to an autonomous financial and tax intelligent agent system and method based on ontology matrix. Background Technology

[0002] In the field of financial and tax automation, with the deepening of enterprise digital transformation, the demand for intelligent processing capabilities in services such as bookkeeping, tax filing, and compliance auditing is increasing. Currently, mainstream financial and tax automation technology solutions mainly include traditional financial software, RPA financial and tax robots, and AI financial and tax assistants.

[0003] Existing traditional accounting software primarily focuses on processing accounting vouchers, providing functions such as bookkeeping, reporting, and asset management. However, the technical drawback of such systems lies in the fact that tax and financial rules are hard-coded into the program, resulting in a high degree of coupling between business logic and code. When tax laws or accounting standards change, developers need to intervene and modify the code, with response times ranging from weeks to months. Furthermore, cross-industry adaptation relies on customized development, leading to high implementation costs and long development cycles.

[0004] RPA (Robotic Process Automation) financial and tax robots simulate human operations through a "record-playback" model to perform tasks such as invoice collection, bank reconciliation, and tax filing. However, its technical shortcomings lie in the fact that the rules are fixed in the script, making it extremely sensitive to changes in the user interface and resulting in high maintenance costs. More importantly, RPA lacks semantic understanding capabilities and cannot understand the business relationships between different data sources. For example, it cannot automatically determine whether a certain invoice and a certain bank transaction correspond to the same sales transaction.

[0005] Finally, while AI-powered tax and accounting assistants combine OCR recognition with large language models for answering tax-related questions and providing auxiliary processing, their technical limitations include a black-box decision-making process, a lack of interpretability, and the inability to form a complete chain of audit evidence. This makes it difficult to meet the regulatory requirements of the "Tax Collection and Administration Law" and the "Electronic Accounting Archives Management Measures" regarding the verifiability and traceability of electronic vouchers. Furthermore, semantic silos exist between multi-source data (invoices, bank statements, contracts, expense reports), preventing the system from establishing semantic connections across data sources, thus limiting the accuracy of intelligent accounting.

[0006] In summary, existing technologies generally suffer from several limitations, including strong coupling between rules and procedures leading to invisible rules, difficulty in maintenance, black-box decision-making processes resulting in untraceability and difficulty in meeting audit requirements, strong binding between business logic and industry characteristics leading to high cross-industry adaptation costs, unclear boundaries of human-machine collaboration leading to difficulty in balancing automation efficiency and risk control, and semantic silos of multi-source data leading to insufficient intelligent accounting capabilities. Summary of the Invention

[0007] This invention is made to solve the above problems, and aims to provide an autonomous financial and tax intelligent agent system and method based on ontology matrix.

[0008] This invention provides an autonomous financial and tax intelligent agent system based on an ontology matrix, characterized by the following features: The scheduling hub module is used to receive financial and tax task requests, generate task contexts containing task identifiers, enterprise identifiers and accounting periods, and orchestrate task execution processes. The ontology service module is used to store and manage the ontology matrix. The ontology matrix includes a root ontology and multiple business ontology. The root ontology defines a common semantic layer, and the business ontology defines the semantic model of different business domains. Each business ontology is associated with the root ontology through semantic mapping. The decision service module is used to store and execute decision models, which include financial and tax business rules and human-machine collaboration boundary rules. The audit service module is used to generate, store, and verify the entire decision-making evidence chain, which uses a hash chain to prevent tampering. The execution layer module is used to perform specific financial and tax operations based on the output of the decision service module. In response to a financial and tax task request, the scheduling center module calls the ontology service module to instantiate the ontology matrix corresponding to the current task, performs human-machine collaboration boundary determination and business decision-making through the decision service module, calls the execution layer module to perform financial and tax operations, and generates and stores the decision evidence chain by the audit service module.

[0009] Furthermore, it also includes a semantic mapping module, which is used to convert ontology instances in the ontology service module into input contexts that the decision service module can recognize; the semantic mapping module performs the conversion using a declarative mapping configuration file, which defines the correspondence between ontology classes and decision input fields and the data type conversion.

[0010] Furthermore, the decision evidence chain generated by the audit service module includes a decision identifier, a task tracking identifier, an input data hash value, an output data hash value, a hit rule identifier, a policy basis, a timestamp, and an execution entity identifier; the hash value of the current evidence chain is associated with the hash value of the previous evidence chain to form an anti-tampering chain; the audit service module is used to perform integrity verification and detect tampering by comparing the hash values ​​of adjacent evidence chains.

[0011] Furthermore, the decision service module has a multi-version control function for decision models, including assigning a unique version number to each decision model and building a rule execution unit for the corresponding version; the scheduling hub module binds the selected decision model version when the task is created and uses the bound version to execute the decision during task execution; when the decision model is dynamically updated, the new version and the old version coexist, and tasks with bound versions continue to use the old version.

[0012] Furthermore, the decision service module also has a canary release function, which distributes the new version of the decision model to some tasks according to a preset ratio or preset enterprise, industry or business scenario, and applies it to all tasks after verification; the decision service module also supports version rollback by task, which is achieved by modifying the bound version of the task and re-executing the task.

[0013] Furthermore, the scheduling hub module also has an exception handling mechanism, which includes automatically retrying retryable exceptions a preset number of times, switching the task status to manual review and saving a snapshot of the scene for non-retryable exceptions, and recording failure details and executing compensation transactions for partial failures in batch operations.

[0014] This invention also provides a method for implementing an autonomous financial and tax intelligent agent based on an ontology matrix, applicable to any of the aforementioned autonomous financial and tax intelligent agent systems, and characterized by the following steps: S1. Receive financial and tax task requests, generate task context, and initialize task status; S2. Instantiate the ontology matrix according to the task context. The ontology matrix includes the root ontology and multiple business ontology. Each business ontology is associated with the root ontology through semantic mapping. S3. Collect data from multiple sources, map the data to ontology instances, and establish semantic relationships across data sources; S4. Perform human-machine collaboration boundary determination. If the determination result is that automatic execution is allowed, proceed to step S5; otherwise, switch the task to manual review. S5. Execute the decision model corresponding to the current task and generate decision results; S6. Generate a chain of decision evidence, using a hash chain to record the input data, output data, and hit rules of the current decision; S7. Based on the decision results, call the execution layer to perform financial and tax operations and update the task status; S8. Return the execution result and archive the chain of evidence for the decision.

[0015] Furthermore, in step S5, before executing the decision model, the corresponding version of the rule execution unit can be loaded according to the version number of the decision model bound to the current task; when the decision model is dynamically updated, the new version and the old version coexist, and the task that has been bound to the old version continues to use the original version.

[0016] Furthermore, the decision evidence chain generated in step S6 includes a decision identifier, a task tracking identifier, an input data hash value, an output data hash value, a hit rule identifier, a policy basis, a timestamp, and an execution entity identifier. The hash value of the current evidence chain is calculated and linked with the hash value of the previous evidence chain to form an anti-tampering chain.

[0017] Furthermore, it also includes integrity verification steps and exception handling steps. The integrity verification process involves reading all evidence chains corresponding to the same task tracking identifier in the order of their generation, verifying the hash links of adjacent evidence chains one by one, and determining that the data has been tampered with if any inconsistency is found. The exception handling steps are as follows: when the execution of a decision or financial and tax operation fails, determine the exception type, automatically retry retry for retryable exceptions such as network timeout or service unavailability, change the task status to manual review and save a snapshot of the scene for non-retryable exceptions such as data verification failure or missing rules, and record the failure details and execute compensation transactions for partial failures in batch operations.

[0018] The role and effect of invention This invention utilizes a separate architecture between the ontology matrix and the DMN decision model, enabling tax and financial rules to be independently stored and dynamically updated using a standardized decision model. This allows for rapid response to policy changes without code modification, significantly reducing maintenance costs. A hash-chain-based decision evidence chain fully records the input, output, hit rules, and policy basis of decisions, supporting one-click restoration of the decision path. Any tampering can be detected, meeting audit compliance requirements. The ontology matrix encapsulates industry characteristics within an industry-adaptive ontology. When integrating a new industry, only the ontology and a few industry-specific rules need to be extended, significantly shortening the implementation cycle. By defining human-machine collaboration boundary rules through the DMN, high-risk operations are converted to manual processes, while low-risk operations are fully automated, effectively controlling compliance risks while ensuring automation efficiency. Multi-version control of the decision model and task-level version binding support canary releases and task-level rollback, achieving seamless upgrades with zero downtime. An exception handling mechanism is configured in the scheduling center, covering retryable exceptions, non-retryable exceptions, and partial failure scenarios in batch operations, ensuring stable system operation. The ontology matrix establishes semantic relationships between multi-source data, enabling automatic matching and calculation based on business substance, solving the "semantic silo" problem of traditional systems. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the structure of the autonomous financial and tax intelligent agent system based on ontology matrix in this invention; Figure 2 This is a flowchart illustrating the implementation method of the autonomous financial and tax intelligent agent based on ontology matrix in this invention. Detailed Implementation

[0020] To make the technical means, creative features, objectives and effects of this invention easier to understand, the following embodiments are described in detail with reference to the accompanying drawings.

[0021] like Figure 1As shown, the autonomous financial and tax intelligent agent system based on ontology matrix provided in this embodiment includes a scheduling hub module, an ontology service module, a decision service module, an audit service module, an execution layer module, and a semantic mapping module. The modules communicate with each other via RESTful API or gRPC, supporting independent deployment and horizontal scaling.

[0022] In this embodiment, the scheduling hub module is the core control layer of the system. Internally, it maintains a finite state machine, defining all states of a task from creation to completion, as well as the transition conditions between states. Upon receiving a financial and tax task request, this module generates a globally unique task identifier and task tracking identifier, encapsulates a task context including the enterprise identifier, accounting period, task type, tenant identifier, and user permission level, and initializes the task state to "initialized" before persisting it to the relational database. Throughout the task execution process, the scheduling hub module sequentially calls other modules according to the flow defined by the state machine and handles exceptions and timeouts at each stage.

[0023] In this embodiment, the ontology service module is responsible for storing and managing the ontology matrix. This ontology matrix is ​​a mesh semantic structure, consisting of a root ontology and multiple business ontology ontologies. The root ontology defines the common semantic layer of the financial and tax domain, including core classes such as enterprise, taxpayer, accounting period, amount, and state enumeration. The business ontology ontologies define semantic models for different financial and tax business domains, including accounting ontology, invoice management ontology, bank funds ontology, tax declaration ontology, asset management ontology, cost and expense ontology, compliance and risk control ontology, and industry-adaptive ontology. Each business ontology is associated with the root ontology through semantic mapping (e.g., equivalence classes, subclasses, or attribute mappings in OWL). All ontology ontologies can be stored in a graph database in RDF format and support SPARQL queries. The ontology service module provides interfaces for creating, reading, updating, and deleting ontology instances, as well as a semantic query interface.

[0024] In this embodiment, the decision service module stores and executes decision models conforming to the DMN standard, including financial and tax business processing rules and human-machine collaboration boundary determination rules. This module integrates a DMN engine, supporting the parsing, compilation, and execution of decision models. The decision service module also implements multi-version management; each decision model is assigned a unique version number, and each version corresponds to an independent rule execution unit. These rule execution units reside simultaneously in memory, forming a version pool.

[0025] The scheduling hub module selects the current decision model version during task creation and records the version number in the task status. During task execution, the decision service module loads the corresponding rule execution unit based on this version number to execute the decision. When the decision model is dynamically updated, the new version of the rule execution unit is built and added to the version pool, while the old version is retained, and tasks bound to the old version are unaffected. Furthermore, the decision service module supports canary releases. System administrators can configure canary release strategies to allocate the new version of the decision model to a subset of tasks according to a preset ratio or based on specific enterprises, industries, or business scenarios, and then deploy it to all tasks after successful verification. The decision service module also supports task-level version rollback; administrators can modify the bound version number of a specified task to make it revert to using the old version.

[0026] In this embodiment, the audit service module is used to generate, store, and verify the entire decision-making evidence chain. After each decision is executed, the module collects the decision identifier, task tracking identifier, input data (serialized to JSON format), output data, hit rule identifier, policy basis (citing specific legal provisions), timestamp, and execution entity identifier. Then, based on the task tracking identifier, it queries the database for the hash value of the most recent evidence chain for that task (if it is the first one, the previous hash value is set to a fixed initial value). After concatenating the key fields of the current evidence chain, the SHA256 algorithm is used to calculate the hash value, and all fields of the current evidence chain, along with the previous hash value and the current hash value, are stored in the evidence chain table of the relational database, forming a chain structure. The audit service module also provides an integrity verification interface, which reads all evidence chains corresponding to the same task tracking identifier in the order of evidence chain generation, and verifies one by one whether the previous hash value stored in each evidence chain is equal to the current hash value of the previous evidence chain. If an inconsistency is found, it is determined that the data has been tampered with and the location of the tampering is output.

[0027] In this embodiment, the execution layer module invokes the appropriate executor to complete atomic operations of financial and tax business based on the decision result. This module adopts the adapter pattern and internally registers multiple executors: an RPA executor to simulate manual operations in systems without official APIs, such as tax bureaus and banks; an API adapter to call the official interfaces of systems such as e-tax bureaus and banks; a tool invoker to call the native interfaces of internal enterprise systems; and a smart contract invoker for financial and tax operations on the blockchain. The scheduling hub module dynamically selects the corresponding executor based on the operation type and target system in the decision result. The execution layer module is also responsible for recording operation logs and returning the execution results to the scheduling hub module.

[0028] In this embodiment, the semantic mapping module is used to convert ontology instances in the ontology service module into input contexts recognizable by the decision service module. This module uses a declarative semantic mapping configuration file (YAML or JSON format), which defines the correspondence between ontology classes and DMN input types, the correspondence between ontology attributes and DMN input fields, and data type conversion rules. Upon system startup, the semantic mapping module scans all mapping configuration files in a specified directory, parses them, constructs in-memory mapping metadata, and supports dynamic hot updates of the configuration files (via monitoring file changes or push notifications from the configuration center). When the scheduling hub module requests to execute a decision, the semantic mapping module receives the ontology instance identifier and the decision identifier, constructs a SPARQL query statement based on the mapping metadata to query the specified attribute values ​​of the ontology instance from the graph database, and then converts the query results into the input context object required by the DMN engine according to the mapping rules, performing necessary data type conversions.

[0029] like Figure 2 As shown, the present invention also provides a method for implementing an autonomous financial and tax intelligent agent based on an ontology matrix, applicable to any of the above-mentioned systems, comprising the following steps: S1. Receive financial and tax task requests, generate task context, and initialize task status; S2. Instantiate the ontology matrix according to the task context. The ontology matrix includes the root ontology and multiple business ontology. Each business ontology is associated with the root ontology through semantic mapping. S3. Collect data from multiple sources, map the data to ontology instances, and establish semantic relationships across data sources; S4. Perform human-machine collaboration boundary determination. If the determination result is that automatic execution is allowed, proceed to step S5; otherwise, switch the task to manual review. S5. Execute the decision model corresponding to the current task and generate decision results; S6. Generate a chain of decision evidence, using a hash chain to record the input data, output data, and hit rules of the current decision; S7. Based on the decision results, call the execution layer to perform financial and tax operations and update the task status; S8. Return the execution result and archive the chain of evidence for the decision.

[0030] In this embodiment, in step S5, before executing the decision model, the corresponding version of the rule execution unit can be loaded according to the version number of the decision model bound to the current task; when the decision model is dynamically updated, the new version and the old version coexist, and the task that has been bound to the original version continues to use the original version.

[0031] In this embodiment, the decision evidence chain generated in step S6 includes a decision identifier, a task tracking identifier, an input data hash value, an output data hash value, a hit rule identifier, a policy basis, a timestamp, and an execution entity identifier. The hash value of the current evidence chain is calculated and linked with the hash value of the previous evidence chain to form an anti-tampering chain.

[0032] In this embodiment, the implementation method provided by the present invention further includes an integrity verification step and an exception handling step. The integrity verification process involves reading all evidence chains corresponding to the same task tracking identifier in the order of their generation, verifying the hash links of adjacent evidence chains one by one, and determining that the data has been tampered with if any inconsistency is found. The exception handling steps are as follows: when the execution of a decision or financial and tax operation fails, determine the exception type, automatically retry retry for retryable exceptions such as network timeout or service unavailability, change the task status to manual review and save a snapshot of the scene for non-retryable exceptions such as data verification failure or missing rules, and record the failure details and execute compensation transactions for partial failures in batch operations.

[0033] The following example uses a corporate user initiating a "verify invoices and automatically record entries" task, combined with... Figure 2 The flowchart illustrates the method steps of the present invention in detail.

[0034] In step S1, the user uploads a VAT invoice image through the front-end interface and selects the "Verify and Record" task. After authentication, multi-tenant isolation, and rate limiting, the API gateway forwards the request to the scheduling hub module. The scheduling hub module generates a globally unique task identifier and task tracking identifier, encapsulates a task context containing the enterprise identifier, accounting period, task type, tenant identifier, and user permission level, and then initializes the task status to "initialized" and persists it to the task status table in the relational database.

[0035] In step S2, the scheduling hub module calls the instantiation interface of the ontology service module, passing in the enterprise identifier. The ontology service module loads the corresponding ontology matrix instance from the graph database based on the enterprise identifier, including the fundamental ontology, invoice management ontology, accounting ontology, etc. The instantiation process includes loading the ontology schema and the enterprise's existing instance data, such as the enterprise's historical invoice records and accounting subject system. After loading is complete, the ontology service module returns an instantiation success flag.

[0036] In step S3, the execution layer module recognizes the invoice image using an optical character recognition adapter, extracting fields such as invoice code, invoice number, invoice date, total amount including tax, tax rate, buyer's name, and seller's name. The ontology service module maps these fields to invoice ontology instances, generating unique instance identifiers. Simultaneously, the ontology service module queries the company's bank statement ontology instance for the current month, associating the invoice instance with the bank statement instance using semantic association rules (e.g., matching the invoice buyer's name with the bank statement payer's name, similar amounts and times, etc.) to form a semantic relationship of "sales transactions that have been received," and storing this association as an object attribute instance in the ontology.

[0037] In step S4, the scheduling center module calls the human-machine collaboration boundary determination DMN model of the decision service module, inputting the current operation type, the total amount of invoice and tax, and the user's permission level. This DMN model contains a rule table: for example, if the operation type is invoice verification, the amount is less than 10,000 yuan, and the permission level is high, then the output is "Fully automatic is possible"; if the amount is greater than 100,000 yuan, then the output is "Absolutely prohibited from automatic operation"; otherwise, the output is "Automatic operation is possible but requires secondary confirmation." In this embodiment, the amount is 8,500 yuan and the permission is high, therefore the output boundary type is "Fully automatic is possible," and the task continues to execute step S5. If the output is "Absolutely prohibited from automatic operation," then the scheduling center module changes the task status to "Manual review in progress," saves the current task context and a snapshot of the collected data, pushes the manual review task to the pending queue, and ends the current automatic execution process.

[0038] In step S5, the scheduling center module calls the decision service module, passing in the decision identifier "invoice verification" and the decision model version number bound to the task. The decision service module loads the corresponding rule execution unit from the version pool according to the version number. The semantic mapping module automatically converts the invoice ontology instance into a DMN input context based on the pre-configured invoice verification mapping file, which includes fields such as invoice code, total price including tax, and tax rate. The decision engine executes the DMN decision, matching the rules: first, it verifies whether the invoice code format conforms to the specification; second, it verifies whether the total price including tax is equal to the amount excluding tax multiplied by the tax rate. In this embodiment, both verifications pass, matching the rules "invoice code format verification passed" and "invoice amount matches tax rate," and the output decision result is "verification passed, invoice valid." Subsequently, the scheduling center module continues to call the automatic accounting decision model, matching the accounting subjects according to the commodity category, amount and tax rate in the invoice information, generating the debit and credit entries for the accounting voucher, and outputting the decision results as follows: debit "Inventory" account for 7,699.12 yuan, debit "Taxes Payable - Value-Added Tax Payable (Input Tax)" account for 800.88 yuan, and credit "Accounts Payable" account for 8,500 yuan.

[0039] In step S6, the audit service module detects the decision execution completion event and triggers the generation of the evidence chain. First, the audit service module collects the following information: decision identifier, task tracking identifier, JSON serialized string of input data, JSON serialized string of output data, list of hit rule identifiers, policy basis (citing Article 11 of the Provisional Regulations on Value-Added Tax and related announcements), current timestamp, and executing entity identifier. Then, it queries the database for the hash value of the most recent evidence chain for this task based on the task tracking identifier. If it is the first evidence chain, the previous hash value is set to the fixed string "0". Next, the task tracking identifier, decision identifier, input data string, output data string, previous hash value, and timestamp are concatenated into a single string, and the hash value is calculated using the SHA256 algorithm. Finally, all the above fields, along with the previous hash value and the calculated current hash value, are stored in the evidence chain table of the relational database.

[0040] In step S7, the scheduling hub module sends the decision result to the execution layer module. The execution layer module parses the decision result: first, it calls the RPA executor to simulate logging into the electronic tax bureau system, inputs the invoice code and number for verification, and obtains the official verification result ("genuine invoice" in this embodiment). Then, it calls the API adapter to call the accounting interface of the enterprise ERP system, passes in the generated debit and credit entries, and creates an accounting voucher. The ERP system returns the voucher number. After successful operation, the execution layer module returns the operation result (successful verification, voucher number) to the scheduling hub module. The scheduling hub module updates the task status to "completed" and persists it to the database.

[0041] In step S8, the scheduling hub module converts the execution result into natural language through the large language model interaction module: "Invoice verification completed, invoice valid; one accounting voucher generated, voucher number 'VOU-20260414-001'." The system archives the entire process decision evidence chain to object storage, supporting the subsequent one-click generation of audit reports conforming to the National Audit Office's standards through task tracking identifiers.

[0042] The role and effect of the embodiments This invention establishes a semantic association between invoices and bank statements through an ontology matrix, enabling automatic matching based on business substance. Human-machine collaboration boundary determination automatically decides the automation level based on amount and permissions, transferring high-risk operations to manual intervention. Multi-version control and task-level version binding ensure that running tasks are unaffected when rules are dynamically updated, supporting canary releases and rollbacks. An exception handling mechanism covers various failure scenarios, ensuring stable system operation. A hash chain anti-tampering mechanism enhances the judicial validity of evidence. This embodiment fully demonstrates that this invention can effectively solve problems in existing technologies such as rule-program coupling, untraceable decision-making, difficulties in cross-industry adaptation, blurred human-machine boundaries, and semantic silos, demonstrating significant technological progress and practical value.

[0043] The above embodiments are preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An autonomous financial and tax intelligent agent system based on ontology matrix, characterized in that, include: The scheduling hub module is used to receive financial and tax task requests, generate task contexts containing task identifiers, enterprise identifiers and accounting periods, and orchestrate task execution processes. The ontology service module is used to store and manage the ontology matrix, which includes a base ontology and multiple business ontology. The base ontology defines a common semantic layer, and the business ontology defines semantic models for different business domains. Each business ontology is associated with the base ontology through semantic mapping. The decision service module is used to store and execute decision models, which include financial and tax business rules and human-machine collaboration boundary rules. The audit service module is used to generate, store, and verify the entire process decision evidence chain, which uses a hash chain to prevent tampering. The execution layer module is used to perform specific financial and tax operations based on the output of the decision service module; In response to a financial and tax task request, the scheduling central module calls the ontology service module to instantiate the ontology matrix corresponding to the current task, performs human-machine collaboration boundary determination and business decision-making through the decision service module, calls the execution layer module to perform financial and tax operations, and generates and stores the decision evidence chain by the audit service module.

2. The autonomous financial and tax intelligent agent system based on ontology matrix according to claim 1, characterized in that, Also includes: A semantic mapping module is used to convert ontology instances in the ontology service module into input contexts that the decision service module can recognize; The semantic mapping module uses a declarative mapping configuration file to perform the transformation. The mapping configuration file defines the correspondence between ontology classes and decision input fields, as well as the data type conversion.

3. The autonomous financial and tax intelligent agent system based on ontology matrix according to claim 1, characterized in that: The decision evidence chain generated by the audit service module includes a decision identifier, a task tracking identifier, an input data hash value, an output data hash value, a hit rule identifier, a policy basis, a timestamp, and an execution entity identifier. The hash value of the current evidence chain is stored in association with the hash value of the previous evidence chain to form an anti-tampering chain. The audit service module is used to perform integrity verification and detect tampering by comparing the hash values ​​of adjacent evidence chains.

4. The autonomous financial and tax intelligent agent system based on ontology matrix according to claim 1, characterized in that: The decision service module has a multi-version control function for decision models, including assigning a unique version number to each decision model and constructing a rule execution unit for the corresponding version; the scheduling center module binds the selected decision model version when the task is created and uses the bound version to execute the decision during task execution; when the decision model is dynamically updated, the new version and the old version coexist, and tasks with bound versions continue to use the old version.

5. The autonomous financial and tax intelligent agent system based on ontology matrix according to claim 4, characterized in that: The decision service module also has a canary release function, which distributes the new version of the decision model to some tasks according to a preset ratio or preset enterprise, industry or business scenario, and applies it to all tasks after verification; the decision service module also supports version rollback by task, which is achieved by modifying the bound version of the task and re-executing the task.

6. The autonomous financial and tax intelligent agent system based on ontology matrix according to claim 1, characterized in that: The scheduling hub module also has an exception handling mechanism, which includes automatically retrying retryable exceptions a preset number of times, switching the task status to manual review and saving a snapshot of the scene for non-retryable exceptions, and recording failure details and executing compensation transactions for partial failures in batch operations.

7. A method for implementing an autonomous financial and tax intelligent agent based on an ontology matrix, applied to the system described in any one of claims 1 to 6, characterized in that, Includes the following steps: S1. Receive financial and tax task requests, generate task context, and initialize task status; S2. Instantiate the ontology matrix according to the task context. The ontology matrix includes a fundamental ontology and multiple business ontology, and each business ontology is associated with the fundamental ontology through semantic mapping. S3. Collect multi-source data, map the data to ontology instances, and establish semantic relationships across data sources; S4. Perform human-machine collaboration boundary determination. If the determination result is that automatic execution is allowed, proceed to step S5; otherwise, switch the task to manual review. S5. Execute the decision model corresponding to the current task and generate decision results; S6. Generate a chain of decision evidence, using a hash chain to record the input data, output data, and hit rules of the current decision; S7. Based on the decision result, invoke the execution layer to perform financial and tax operations and update the task status; S8. Return the execution result and archive the chain of evidence for the decision.

8. The method according to claim 7, characterized in that: In step S5, before executing the decision model, the corresponding version of the rule execution unit can be loaded according to the version number of the decision model bound to the current task; when the decision model is dynamically updated, the new version and the old version coexist, and the task that has been bound to the old version continues to use the original version.

9. The method according to claim 7, characterized in that: The decision evidence chain generated in step S6 includes a decision identifier, a task tracking identifier, an input data hash value, an output data hash value, a hit rule identifier, a policy basis, a timestamp, and an execution entity identifier. The hash value of the current evidence chain is calculated and linked with the hash value of the previous evidence chain to form an anti-tampering chain.

10. The method according to claim 7, characterized in that, Also includes: Integrity verification steps and exception handling steps, The integrity verification step involves reading all evidence chains corresponding to the same task tracking identifier in the order of evidence chain generation, verifying the hash links of adjacent evidence chains one by one, and determining that the data has been tampered with if an inconsistency is found. The exception handling steps are as follows: when the execution of a decision or financial and tax operation fails, the exception type is determined, and retryable exceptions such as network timeout or service unavailability are automatically performed. For non-retryable exceptions such as data verification failure or missing rules, the task status is changed to manual review and a snapshot of the scene is saved. For partial failures in batch operations, failure details are recorded and compensation transactions are executed.

Images