Intelligent entity data processing method, system, device, and medium

Abstract

The application discloses an agent data processing method, system, device and medium, and is applied to the technical field of agents. The method comprises the following steps: encapsulating basic capabilities as reusable components and registering the components in a unified registry; analyzing a task request and matching a target component to generate an arrangement plan; calling the components to execute processing according to the arrangement plan and sharing the results among multiple agents to realize reuse; checking compliance based on a set of review strategies and supporting synchronous effect of strategy changes; collecting operation and business indexes to generate multi-dimensional performance evaluation data, and optimizing arrangement decisions of subsequent tasks based on the multi-dimensional performance evaluation data. The application realizes cross-scene data reuse and dynamic iteration of rules, solves the problem of data islands, and improves the efficiency of industry and financial data processing and system observability.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, system, device and medium for processing data of intelligent agents. Background Technology

[0002] Business and financial data processing is a core component of enterprise digital transformation, encompassing high-frequency scenarios such as expense reimbursement review, contract risk control auditing, invoice information extraction, and financial document comparison. Traditional business and financial data processing systems often employ a distributed, stacked-tool approach, requiring enterprises to deploy OCR recognition tools, rule engines, RPA scripts, and AI models trained for specific scenarios separately. These tools operate independently, lacking a unified task orchestration and data sharing mechanism, resulting in data flow heavily reliant on manual intermediaries and a typical "siloed" architecture. This existing technical architecture suffers from numerous technical shortcomings: First, cross-scenario data reuse is difficult. The same invoice needs to be extracted by OCR multiple times in different tools, resulting in resource waste and the risk of data inconsistency. Secondly, when compliance rules change, the corresponding audit rules for each tool need to be modified one by one, which results in a long response time and is prone to inconsistencies between the rules of different tools. Third, the system's operating status lacks unified observable indicators, and troubleshooting requires checking the operation logs of each tool separately, resulting in low operation and maintenance efficiency. Fourth, when adding new business systems, it is necessary to develop an adaptation interface for each tool separately, and the system integration complexity increases linearly with the number of tools.

[0003] The aforementioned problems severely restrict the level of intelligent processing of business and financial data, making it difficult to meet the growing demand of enterprises for efficient, compliant, and scalable intelligent processing. Summary of the Invention

[0004] This application provides a method, system, device, and medium for intelligent agent data processing, which addresses the problems of data silos, difficulty in rule maintenance, lack of operational observability, and high system integration complexity in existing technologies. The technical solution provided by this application is as follows: On the one hand, this application provides a method for processing intelligent agent data, including: The basic capabilities required for business and financial data processing are encapsulated into reusable tool components; each tool component registers its own capability type, input and output specifications, and applicable scenario tags in a unified tool registry. Receive task requests from business scenarios, parse the target intelligent agents and task parameters called by the task requests; query the tool registry according to the task parameters, match at least one target tool component that is suitable for the current task, and generate an orchestration plan that includes the tool call order and data flow path; According to the orchestration plan, the target tool component is invoked to perform data processing, and the execution results are shared among the target intelligent agents according to the data flow path, so that the execution results of the same target tool component can be reused by multiple target intelligent agents; The execution results are validated for compliance based on a pre-defined set of review strategies, and the validation results are output. Multi-dimensional performance evaluation data is generated based on the operational and business metrics of each target agent and target tool component, and the orchestration decisions for subsequent tasks are optimized based on the multi-dimensional performance evaluation data.

[0005] The above solution encapsulates basic capabilities into reusable tool components and establishes a unified orchestration and performance feedback mechanism, thereby achieving decoupling and reuse of tool capabilities, cross-agent data sharing, centralized management of compliance rules, and data-driven orchestration optimization. This effectively solves the problems of data silos and inefficient collaboration in distributed architectures.

[0006] Optionally, based on task parameters, the tool registry is queried to match at least one target tool component suitable for the current task, generating an orchestration plan that includes the tool invocation order and data flow path, including: Based on the task type, the system matches the target tool components in the tool registry and dynamically selects the optimal tool combination and tool invocation order by combining the precondition judgment of the rule engine and the result confidence evaluation. Data flow paths are generated based on the optimal tool combination and tool call order, and orchestration plans are generated based on the tool call order and data flow paths.

[0007] The above solution enables the orchestration plan to adaptively select tool combinations based on the specific characteristics of each business through a metadata-driven runtime decision-making mechanism, avoiding the rigidity problem caused by static configuration. At the same time, the combination of confidence assessment and precondition judgment enables the system to achieve a dynamic balance between accuracy, timeliness and stability.

[0008] Optionally, the execution results can be shared among the target agents according to the data flow path, including: Maintain a unified data cache; the execution results of tool components are written to the data cache in a standardized format and associated with the corresponding task identifier; When different target agents need the same type of execution result, the execution result is read from the data cache by task identifier or data type.

[0009] The above solution eliminates the waste of resources caused by redundant computing through unified caching and standardized data format, while decoupling the strong dependency between tool producers and consumers, enabling the system to dynamically replace or upgrade underlying capability components without interrupting business operations.

[0010] Optionally, the review policy set is maintained in the following manner: Establish review rules - agent dependency graph; When the review rules in the review strategy set are changed, the affected associated agents are analyzed based on the review rule-agent dependency graph, and a consistency check is triggered for all associated agents to ensure that the review results of each associated agent remain consistent after the review rules in the review strategy set are changed.

[0011] The above solution makes implicit and distributed dependencies explicit and computable through graph data structures, enabling the scope of impact of rule changes to be automatically traversed, analyzed, and verified, thus fundamentally ensuring the strict consistency of compliance logic in a multi-agent collaborative environment.

[0012] Optionally, changes to review rules in the review strategy set support a phased implementation mechanism: new versions of review rules in the review strategy set are first tested in designated agents or a specified proportion of tasks, and the differences in review results under the new and old review rules are compared. Once the comparison results confirm that there are no errors, the changes are fully implemented.

[0013] The above solution uses a dual-track parallel and shadow comparison mechanism to verify the correctness of the new rules while ensuring that the production environment is not disturbed, thus avoiding the risk of misjudgment of batch business due to rule defects in the direct replacement mode.

[0014] Optionally, the multi-dimensional performance evaluation data includes: agent health, including at least a comprehensive health score, operational status distribution, event classification, response latency, and task success rate within the most recently set time range; agent performance, including at least task completion rate, user satisfaction, and agent performance ranking. The intelligent agent data processing method also includes: when the response latency or task success rate of the target intelligent agent is detected to exceed a preset threshold, an automatic degradation strategy is triggered to adjust the tool calling scheme for subsequent tasks.

[0015] The above solution, through dual monitoring of technical and business dimensions and an automatic degradation mechanism, enables the system to maintain elastic operation when faced with sudden traffic or component failures, realizing a shift from passive operation and maintenance to proactive self-healing.

[0016] Optionally, the intelligent agent data processing method provided in this application further includes: providing a unified natural language entry point to receive business questions described by users in natural language; the system performs intent recognition in conjunction with a knowledge base; and guides users to the corresponding target intelligent agent or retrieves the answer from the knowledge base based on the recognition results.

[0017] The above solution transforms unstructured user expressions into structured instructions or precise knowledge feedback that can be executed by the backend by constructing a unified semantic interaction layer, thereby shielding the technical differences between multiple heterogeneous intelligent agents at the underlying level and reducing the operational threshold of the system.

[0018] On the other hand, this application also provides an intelligent agent data processing system, including: The tool component building layer is used to encapsulate the multiple basic capabilities required for business and financial data processing into reusable tool components. Each tool component registers its own capability type, input and output specifications, and applicable scenario tags in a unified tool registry. The intelligent agent orchestration layer is used to receive task requests from business scenarios, parse the target intelligent agents and task parameters called by the task requests, query the tool registry according to the task parameters, match at least one target tool component that is suitable for the current task, and generate an orchestration plan that includes the tool call order and data flow path. The data processing layer is used to call the target tool components to perform data processing according to the orchestration plan, and share the execution results among the target agents according to the data flow path, so that the execution results of the same target tool component can be reused by multiple target agents. The compliance verification layer is used to perform compliance verification on the execution results based on a pre-defined set of review strategies and output the verification results. The performance evaluation layer is used to generate multi-dimensional performance evaluation data based on the operational and business metrics of each target intelligent agent and tool component, and to optimize the orchestration decisions of subsequent tasks based on the multi-dimensional performance evaluation data.

[0019] The system described above uses a layered and decoupled modular architecture to materialize each logical step in the process into an independent functional component. The layers interact through standardized interfaces, which not only ensures functional integrity but also achieves a complete separation of concerns, reserving flexible expansion space for accessing more types of capabilities or adapting to new business scenarios.

[0020] On the other hand, this application also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described intelligent agent data processing method.

[0021] On the other hand, this application also provides a computer-readable storage medium storing computer instructions, which, when executed by a processor, implement the above-described intelligent agent data processing method.

[0022] The beneficial effects of this application are as follows: (1) By constructing a tool component layer and encapsulating basic capabilities into reusable standardized components, and using a unified tool registry for metadata management, the upper-layer orchestration logic does not need to concern itself with the specific implementation details of the underlying tools, thus achieving decoupling and reuse of technical capabilities. Compared with traditional distributed architecture, the execution results of the same tool component can be shared and reused among multiple agents, avoiding resource waste caused by repeated calls and reducing computational costs.

[0023] (2) By dynamically generating an orchestration plan containing the tool call order and data flow path through the intelligent agent orchestration layer, the system can adaptively match tool combinations according to the task parameters of different business scenarios, avoiding the rigidity problem caused by hard coding. At the same time, the orchestration plan clarifies the data mapping relationship between upstream and downstream tools, supports flexible scheduling of serial and parallel processes, and improves the overall processing efficiency.

[0024] (3) By centrally managing and reviewing the policy set and establishing a rule-agent dependency graph, when a compliance rule changes, only one modification is needed to make all agents referencing the policy take effect simultaneously. This solves the risk of inconsistency due to multiple versions caused by scattered rule configuration and reduces the maintenance cost and error probability of compliance rules. Combined with the canary activation mechanism, the security and controllability of rule changes are further ensured.

[0025] (4) By collecting multi-dimensional performance evaluation data and feeding it back to the intelligent agent orchestration layer, a data-driven closed-loop optimization mechanism is formed. When abnormal component performance is detected, the orchestration layer can automatically trigger the degradation strategy adjustment tool call scheme, enabling the system to have adaptive adjustment and self-healing capabilities, and continuously improve processing performance and service quality in long-term operation.

[0026] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description or may be learned by practicing this application. Attached Figure Description

[0027] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram outlining the data processing method for intelligent agents in the embodiments of this application; Figure 2 This is a schematic diagram of the composition structure of the intelligent agent data processing system in the embodiments of this application; Figure 3 This is a schematic diagram of the hardware structure of the electronic device in the embodiments of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and beneficial effects of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] Example 1 like Figure 1 As shown, this application provides an intelligent agent data processing method. The method constructs a complete processing link from the underlying capability encapsulation to the upper-layer performance feedback, mainly including steps S101 to S105.

[0030] Step S101: Encapsulate the multiple basic capabilities required for business and financial data processing into reusable tool components; among them, the tool components include at least a document parsing component, a rule engine component, and a large language model component; each tool component registers its own capability type, input and output specifications, and applicable scenario tags in a unified tool registry.

[0031] Specifically, the tool component layer forms the atomic capability foundation of the system. By standardizing and encapsulating previously scattered and heterogeneous business processing capabilities, it transforms them into independent units that can be uniformly scheduled. For example, the document parsing component may encompass various specific implementations such as OCR recognition and PDF structured extraction, but in the registry, they are all abstracted into the capability type of "document parsing." The rule engine component encapsulates various compliance verification logics, and the large language model component provides semantic understanding and generation capabilities. The tool registry, as the core metadata management center, defines the input parameter structure, output data format, and applicable business scenario tags (such as "expense reimbursement" and "contract review") for each tool. This abstract definition mechanism allows upper-layer orchestration logic to operate without needing to concern itself with the specific implementation details of the underlying tools, only needing to call them based on standardized interface specifications. This achieves decoupling and reuse of technical capabilities, laying the foundation for the subsequent construction of intelligent agents across various scenarios.

[0032] Step S102: Receive a task request from a business scenario, parse the target intelligent agents and task parameters called by the task request; query the tool registry according to the task parameters, match at least one target tool component that is suitable for the current task, and generate an orchestration plan that includes the tool call order and data flow path.

[0033] Specifically, the intelligent agent orchestration layer acts as a translator and scheduler between business intent and underlying capabilities. When receiving a task request such as "Review this travel expense report," the orchestration layer first parses the task type as "expense review" and extracts key parameters such as the invoice image and the reimbursement amount. Subsequently, the orchestration layer dynamically queries the tool registry and matches the most suitable tool combination based on parameter characteristics. For example, it first calls the document parsing component to extract invoice information, then calls the rule engine component to verify travel standards, and finally calls the large language model component to generate a review summary. The generated orchestration plan not only specifies the sequential or parallel execution order of tools but also clearly defines the data flow path between upstream and downstream tools, i.e., how the output of the previous tool is mapped to the input of the next tool. This mechanism of dynamically generating orchestration plans enables the system to flexibly adapt to the differentiated needs of different business scenarios, avoiding the rigidity problems caused by traditional hard-coding methods.

[0034] Step S103: According to the orchestration plan, the target tool component is invoked to perform data processing, and the execution results are shared among the target agents according to the data flow path, so that the execution result of the same target tool component can be reused by multiple target agents.

[0035] Specifically, during the execution phase, the system strictly follows the orchestration plan to drive each tool component to complete data processing tasks. More importantly, this application establishes a cross-agent result-sharing mechanism. For example, in a cost audit scenario, the invoice recognition results from the document parsing component can not only be used by the current "cost audit agent," but also directly read by subsequent "accounting agents" or "tax declaration agents," without repeatedly calling the OCR service. This sharing mechanism is implemented through a pre-defined data flow path, ensuring data consistency and timeliness during multi-agent collaboration. In this way, the system effectively eliminates the data silos found in traditional siloed architectures, significantly reduces redundant consumption of computing resources, and improves overall processing efficiency.

[0036] Step S104: Perform compliance verification on the execution result based on the preset review strategy set, and output the verification result.

[0037] Specifically, the review strategy set serves as a digital carrier of business compliance requirements, encompassing various financial policies, risk control rules, and legal provisions. The system decouples the strategy set from specific agent instances, implementing centralized management. When a company adjusts its financial policies (such as changing travel and accommodation standards), operations personnel only need to update the corresponding rule entries in the strategy set management module, and the system will automatically push the change to all agents referencing that strategy set (such as expense review agents and budget control agents). This "one-stop modification, global effect" mechanism fundamentally solves the risk of inconsistencies caused by fragmented rule configurations in existing technologies, significantly reducing the maintenance cost and error probability of compliance rules, and ensuring the compliance and rigor of business processes.

[0038] Step S105: Based on the operational and business metrics of each target intelligent agent and target tool component, generate multi-dimensional performance evaluation data, and optimize the orchestration decisions of subsequent tasks based on the multi-dimensional performance evaluation data.

[0039] Specifically, the system incorporates a full-link observability mechanism, collecting real-time data on technical operational status (such as API response time and service availability) and business performance (such as document approval rate and average processing time). This multi-dimensional performance evaluation data is not only displayed on the monitoring dashboard but, more importantly, serves as feedback signals to the intelligent agent orchestration layer. For example, when the response latency of a large language model component consistently exceeds a threshold, the orchestration layer can automatically reduce the priority of that tool or switch to a backup model when generating subsequent orchestration plans; when the completion rate of a certain type of task is found to be low, it can trigger adjustments and optimizations to the orchestration strategy. This data-driven closed-loop optimization mechanism endows the system with the ability to self-evolve and adaptively adjust, enabling it to continuously improve processing efficiency and service quality over long-term operation.

[0040] It should be understood that, although Figure 1 The above steps illustrate a linear flow. However, in practical applications, the performance feedback in step S105 may influence the orchestration decision in step S102 in real time, forming a dynamic loop. Simultaneously, the construction of the tool component layer (step S101) is typically a preparatory step, but new tool components can be dynamically expanded during system operation. This embodiment establishes the basic framework for agent data processing through the above five-step main logic, providing a foundation and supporting environment for specific dynamic decision-making, caching mechanisms, and gray-scale strategies in subsequent embodiments.

[0041] Example 2 As an optional implementation, based on step S102 of embodiment 1, the specific method for querying the tool registry according to task parameters, matching at least one target tool component suitable for the current task, and generating an orchestration plan containing the tool call order and data flow path is as follows: The orchestration layer maintains the tool registry, and each tool component declares its capability type, input / output specifications (i.e., input / output schema), applicable scenario tags, and confidence weights when registering; when a task request arrives, the orchestration layer matches the target tool component in the tool registry according to the task type, and dynamically selects the optimal tool combination and tool call order by combining the precondition judgment and result confidence evaluation of the rule engine; a data flow path is generated based on the optimal tool combination and tool call order, and an orchestration plan is generated based on the tool call order and data flow path.

[0042] Specifically, this embodiment refines the abstract "matching" and "generation" processes in step S102 into a metadata-driven runtime decision-making mechanism, distinguishing it from the pre-hard-coded static process configuration in existing technologies. The input and output schemas in the tool registry define the structured contracts of the tool component interfaces. For example, for a document parsing component, its input schema can be defined as an object containing the file URL, file format (PDF / IMG), and resolution requirements, while the output schema is defined as a structured JSON object containing fields such as invoice code, amount, date, and buyer / seller names. For a large language model component, its input schema may contain the Prompt template ID, context window size, and temperature parameters, while the output schema is defined as summary text, risk labels, or classification results. Applicable scenario tags are used to quickly filter candidate toolsets, such as being labeled "travel expense reimbursement," "contract review," or "general OCR," enabling the orchestration layer to narrow the search space and improve matching efficiency when facing specific business tasks. The confidence weight is a quantitative indicator used to characterize the expected reliability of the tool's output in the current scenario. Its value is typically a floating-point number between 0 and 1, with higher values ​​indicating stronger expected reliability. This fine-grained metadata definition allows the orchestration layer to make complex scheduling decisions using only external declarative information without intruding on the tool's internal implementation, achieving complete decoupling between capability description and capability execution.

[0043] In matching available tools, the orchestration layer doesn't simply list all tools that match the tags. Instead, it uses a rules engine to dynamically filter based on preconditions. Specifically, the system parses the business parameters in the task request in real time and substitutes them into preset conditional expressions for evaluation. For example, when processing expense reimbursement tasks, if the parsed reimbursement amount is greater than 50,000 yuan, the precondition is true, and the system will force the "advanced risk control model" into the candidate toolset, while excluding the "basic verification rules" which only apply to small reimbursements. Conversely, if the amount is less than or equal to 50,000 yuan, the advanced risk control model is skipped to save computing resources. Similarly, when the ticket type in the task parameters is "train ticket," the system automatically matches an OCR recognition tool specifically optimized for transportation tickets, while filtering out parsing components that only support VAT invoices. This conditional branching logic based on runtime parameters ensures that the orchestration plan can accurately adapt to the personalized characteristics of each business transaction, avoiding resource waste or risk control oversights caused by a "one-size-fits-all" approach.

[0044] After determining the candidate toolset, the orchestration layer further combines result confidence assessment to select the optimal tool combination. Confidence assessment can be implemented using various techniques. As a preferred implementation, confidence can be obtained through a weighted calculation formula, such as comprehensively considering multiple factors including the tool's historical accuracy, current load status, predicted response time, and business scenario matching, and deriving a real-time confidence score through a preset weighted algorithm. As another optional implementation, confidence can also be obtained through table lookup logic, i.e., a "scenario-tool-confidence" mapping matrix is ​​pre-built, and the orchestration layer directly retrieves the corresponding baseline confidence based on the current task scenario, and then dynamically adjusts it based on the actual performance of the most recent N calls. For example, if a large language model component has a baseline confidence of 0.92 in the "contract clause extraction" scenario, but fails to time out in 3 of the last 10 calls, the system automatically adjusts its confidence to 0.85; if the adjusted confidence of another backup model is 0.88, the orchestration layer will prioritize the backup model. This multi-dimensional confidence assessment mechanism enables the system to achieve a dynamic balance between accuracy, timeliness, and stability, rather than relying solely on a single indicator for decision-making.

[0045] The final orchestration plan is presented in structured data format, explicitly recording the topological relationships and data flow paths of tool calls. For example, a typical orchestration plan can be described in JSON format, containing a list of nodes and a list of edges: each element in the node list records the tool component ID, input parameter binding expression, timeout threshold, and retry strategy; each element in the edge list records the source node ID, target node ID, and data mapping rules, indicating how the output fields of the preceding node are transformed into the input fields of the subsequent node. In this structure, serial dependencies are implicitly expressed through the direction of the edges, while nodes without dependencies can be identified by the scheduler as parallel execution units. For example, in a travel expense reimbursement review scenario, the orchestration plan may contain three nodes: node A is a document parsing component, node B is a rule engine component, and node C is a large language model summarization component; edge AB indicates that the structured invoice data output by node A is passed to node B for compliance verification, and edge AC indicates that the raw text output by node A is passed to node C to generate a review summary; since nodes B and C only depend on the output of node A and have no dependencies on each other, the scheduler can trigger the execution of B and C in parallel, thereby significantly reducing the overall processing latency. It should be understood that the above JSON format is only an example. In other embodiments, the orchestration plan can also adopt any data format that can express the structure of a directed acyclic graph (DAG), such as XML, YAML, Protobuf or a custom binary protocol, as long as it can carry the semantic information of the tool call order and data flow path.

[0046] This embodiment transforms the generation of orchestration plans from static configuration to runtime calculation based on real-time parameters and multi-dimensional evaluation indicators through the aforementioned dynamic decision-making mechanism. The technical benefits of this transformation are twofold: First, the system can adaptively select the most suitable tool combination based on the specific characteristics of each business transaction, avoiding resource waste caused by over-configuration and under-utilization, as well as risk control failure caused by under-configuration and over-utilization. Second, the combination of confidence assessment and precondition judgment enables the system to cope with fluctuations in tool performance and changes in business rules, automatically avoiding abnormal tools or switching to a degradation scheme during runtime without manual intervention, thereby improving the robustness and intelligence of the overall data processing chain.

[0047] Example 3 As an optional implementation, based on step S103 of embodiment 1, the specific method for sharing the execution result among various target agents according to the data flow path is as follows: the orchestration layer maintains a unified data cache area, the execution result of the tool component is written into the data cache area in a standardized format and associated with the corresponding task identifier; when different target agents need the same type of execution result, the execution result is read from the data cache area through the task identifier or data type label to avoid repeatedly calling the same tool component.

[0048] Specifically, this embodiment implements the result sharing mechanism abstracted in step S103 as an entity caching architecture based on memory or distributed storage, distinguishing it from the inefficient solutions in existing technologies that rely solely on message queues for asynchronous notifications or persistent database storage. The unified data cache can be physically implemented using high-performance key-value storage systems such as Redis and Memcached. Its core data structure is designed as a composite primary key, where the Key is composed of a globally unique task identifier (TaskID) and a data type label (DataType), and the Value is a serialized standard data object. The task identifier is a global context ID that runs throughout the entire business processing chain, ensuring data isolation in multi-tenant or multi-task environments and preventing data crosstalk between different expense reports or contract review tasks. The data type label is a semantic classification of the tool's output, such as "Invoice_OCR_Result," "Contract_Risk_Score," or "LLM_Summary," allowing downstream agents to accurately retrieve the required data based solely on business semantics without needing to know which tool instance was specifically called upstream. This dual indexing mechanism based on "task + semantics" not only ensures the secure isolation of data, but also enables flexible addressing across tools and intelligent agents.

[0049] In the data writing process, the system enforces standardized format conversion, a key technical means to solve the data interoperability problem between heterogeneous tools. Because the tool component layer encapsulates basic capabilities from different vendors and technology stacks, their original output formats often vary greatly. For example, one OCR component might return XML, while another major model component might return unstructured text. Therefore, after receiving the tool execution results, the orchestration layer maps the original results to a unified JSON or Protobuf object based on the predefined output schema in the tool registry, and then serializes and writes it to the data cache. For example, regardless of which service provider's invoice recognition interface is called at the underlying level, the data written to the cache is standardized into a standard object containing fixed fields such as "invoice code," "invoice date," and "amount excluding tax." This process not only eliminates the complexity of downstream agents adapting to multiple data formats but also ensures that when changing underlying tool components, as long as the output conforms to the established schema, the upper-layer business logic requires no modification, thus significantly improving the system's maintainability and scalability.

[0050] In the data reading process, when subsequent agents execute the orchestration plan, they first initiate a query request to the unified data cache. The query strategy supports two modes: exact match mode and fuzzy search mode. In exact match mode, the agent provides the complete TaskID and DataType, and the system directly locates and returns the cached value, suitable for deterministic scenarios where the output of preceding nodes is known. In fuzzy search mode, the agent only provides the DataType or combines it with wildcards for querying, and the system returns the latest data of all matching types in the current task context, suitable for analysis scenarios that require aggregating information from multiple sources. If the cache is hit, the system directly injects the deserialized standard object into the input parameters of the current agent, skipping the actual tool call step; if the cache is not hit, a source-following mechanism is triggered, automatically scheduling the corresponding tool component to perform data processing, and the newly generated results are backfilled into the cache according to the aforementioned writing process for reuse by downstream nodes. It should be understood that although this embodiment uses key-value pair storage as a preferred example, in other embodiments, the unified data cache can also adopt any storage medium that can support fast read and write based on identifiers, such as document database, graph database or shared memory file system, as long as it can realize the functions of temporary storage and cross-component sharing of execution results.

[0051] This embodiment achieves spatiotemporal reuse of computing resources at the technical level through the aforementioned caching mechanism. On the one hand, for time-consuming or expensive tool components (such as high-precision OCR or large model inference), the result of a single execution can be repeatedly read in multiple processing stages of the same task, avoiding resource waste and cost increases caused by redundant computation. On the other hand, the standardized data exchange format decouples the strong dependency between tool producers and consumers, enabling the system to dynamically replace or upgrade underlying capability components without interrupting business operations. More importantly, the task-identifier-based isolation mechanism ensures the accuracy and security of data flow in high-concurrency scenarios, providing reliable data infrastructure support for building complex multi-agent collaborative networks.

[0052] Example 4 As an optional implementation, based on step S104 of embodiment 1, the specific method for unified maintenance of the review strategy set is as follows: establish a review rule-agent dependency graph. When the review rules in the review strategy set are changed, the system automatically analyzes the affected associated agents based on the review rule-agent dependency graph and triggers consistency verification for all associated agents so that the review results of each associated agent remain consistent after the review rules in the review strategy set are changed.

[0053] Specifically, this embodiment transforms the functional description of "one modification takes effect simultaneously" in step S104 into a deterministic technical solution based on a graph data structure. The rule-agent dependency graph is a directed acyclic graph (DAG) or heterogeneous information network, whose nodes contain at least three types of entities: rule nodes (representing atomic compliance clauses, such as "travel and accommodation standards"), policy set nodes (representing a combination container of rules, such as "domestic travel review policy"), and agent nodes (representing specific business execution units, such as "expense review agent"). Edges between nodes define two core relationships: a reference edge connects a rule node and a policy set node, indicating that a rule is included in a policy set; an invocation edge connects a policy set node and an agent node, indicating that an agent loads and executes the policy set at runtime. This explicit topology makes the dependencies, originally implicitly scattered in various configuration files or code, visible and computable, providing a precise data foundation for subsequent automated impact analysis. It should be understood that although this embodiment uses three types of nodes as examples for illustration, in other implementations, the dependency graph can also be extended to include "business scenario nodes", "data source nodes" or "tool component nodes", as long as it can express the relationship between the rules and the execution subject.

[0054] When a rule change is detected, the system does not simply broadcast an update notification. Instead, it uses a backward graph traversal algorithm based on the dependency graph to automatically analyze the scope of the impact. Specifically, starting from the rule node that has been changed, the system searches backward along the referencing edges for all directly related policy set nodes, and then continues searching backward along the calling edges for all agent nodes that reference these policy sets, thus constructing a complete subgraph of the change's impact. For example, when finance personnel modify the underlying rule "average limit for entertainment expenses," the system can identify, within milliseconds, the "Business Entertainment Approval Policy Set," the "Executive Reimbursement Policy Set," and the "Expense Approval Agent," "Budget Control Agent," and "Compliance Audit Agent" that further call these policy sets. The system then highlights the list of affected policy sets and agents on the front-end management interface, allowing operations personnel to intuitively confirm the scope of the change and avoiding the risk of omissions due to opaque dependencies in traditional models.

[0055] After determining the affected scope, the system triggers a consistency check on all related agents, a crucial closed-loop action to ensure the secure implementation of the change. The consistency check involves three levels of specific operations: First, hot configuration reloading: the system sends a configuration refresh command to the runtime instances of the affected agents, enabling them to fetch the latest policy set definition without restarting the service, eliminating the old version cache in memory. Second, cache invalidation handling: for the unified data cache mentioned in Example 3, the system proactively clears the cache of historical verification results related to the rule, preventing downstream agents from reading expired data generated based on the old rule. Finally, regression testing verification: the system automatically selects a standard sample set (such as expense reports containing boundary values) covering the rule change from a pre-built test case library, re-executes the review process using the new rule in a sandbox environment, and compares the new results with the expected benchmark. Only when the regression test pass rate meets a preset threshold (e.g., 100%) does the system mark the change as "verified" and officially take effect; if the test fails, the change is automatically rolled back or an alarm is triggered to block the release. This embodiment transforms rule changes from a high-risk manual operation into a verifiable and traceable automated engineering process through the aforementioned technical chain of "graph modeling - traversal analysis - multi-dimensional verification". This fundamentally ensures the strict consistency of compliance logic and the stability of system operation in a multi-agent collaborative environment.

[0056] Example 5 As an optional implementation, based on the unified maintenance of the review strategy set described in Example 4, the changes to the review rules in the review strategy set support a gray-scale activation mechanism: the new version of the review rules in the review strategy set is first tested in a specified agent or a specified proportion of tasks, the differences in the review results under the new and old review rules are compared, and the full version is activated after the comparison results are confirmed to be correct.

[0057] Specifically, this canary rollout mechanism is not a simple traffic splitting approach, but rather employs a combination of dual-track parallel processing and shadow comparison techniques to mitigate the risk of misjudgment of batch business processes due to rule deficiencies in the traditional direct replacement model. During implementation, the orchestration layer incorporates a traffic distributor. When a new version of a review policy is detected to be awaiting verification, the distributor marks some task requests as canary traffic based on a preset canary strategy (such as hashing by tenant ID, by document amount range, or random sampling). For canary traffic, the system simultaneously loads the old and new version rules for parallel computation, but only the execution results of the old version rules are returned as formal business output to the downstream, while the execution results of the new version rules are written as shadow data to a separate comparison log library. This design ensures that actual business processing is not subject to any potential interference during the verification of new rules, maintaining absolute stability of the production environment.

[0058] After acquiring the shadow data, the system automatically performs a difference comparison analysis. The comparison dimensions include not only the final review conclusion (pass / rejection) but also delve into intermediate process data, such as the number and type of risk hits, confidence score distribution, and rule triggering paths. For example, if the pass rate of the old and new rules for the same batch of expense reports deviates by more than a preset safety threshold (e.g., 5%), or if the new rule triggers an unknown risk label that the old rule has never triggered, the system will determine that the gray-scale verification has failed and automatically generate a diagnostic report containing details of the differences, which will be pushed to the administrator. Only when the differences between the shadow data and the baseline data in N consecutive batches or within a specified time window are all within the allowable range will the system automatically transition the status of the new version rule to official effectiveness and gradually expand the gray-scale ratio until a full switch is achieved. It should be understood that although this embodiment uses rule changes as an example to illustrate the gray-scale mechanism, in other implementations, this mechanism is also applicable to version upgrades of underlying tool components or iterative optimization of large language model Prompt templates. As long as logical changes that affect business results are involved, they can be included in this gray-scale control system, thereby building a security defense line for pre-change verification.

[0059] Furthermore, to ensure the system's robustness during operation, the multi-dimensional performance evaluation data collected in step S105 includes: agent health status in the technical dimension, including at least a comprehensive health score, operational status distribution, event classification, and task success rate over the past 24 hours; agent performance in the business dimension, including at least task completion rate, user satisfaction, and agent performance ranking; when agent response latency or task success rate exceeds a preset threshold, the orchestration layer automatically triggers a degradation strategy, adjusting the tool invocation scheme for subsequent tasks. Specifically, the health indicators in the technical dimension are collected in real-time by probes deployed on each service node. The comprehensive health score is a normalized value calculated based on weighted averages of basic indicators such as CPU utilization, memory usage, GC frequency, and API error rate, used to intuitively reflect the system load status; the operational status distribution statistics show the percentage of instances in four states: normal, alert, warning, and fault; the event classification divides anomalies into levels P0 to P3 based on the scope and duration of the fault impact, facilitating the priority handling of critical issues. Business-level performance indicators are obtained through streaming computation of business logs. For example, task completion rate reflects the smoothness of the end-to-end process, user satisfaction can be calculated based on the user's acceptance rate of the review results or explicit feedback scores, and the intelligent agent performance ranking integrates a multi-factor model of processing timeliness, accuracy and resource consumption to provide a quantitative basis for operational optimization.

[0060] When the aforementioned performance evaluation data reflects system anomalies, the orchestration layer automatically triggers a degradation strategy—a self-healing mechanism requiring no manual intervention. The triggering condition for the degradation strategy can be configured as a single metric exceeding its limit or a combination of multiple metrics exhibiting anomalies. For example, if the average response latency of a large language model component exceeds 3 seconds for 30 consecutive seconds, or if the task success rate is below 90% for the past minute, the triggering condition is met. Specific degradation actions are executed in stages based on the severity of the anomaly: In mild anomaly scenarios, the orchestration layer can dynamically adjust tool selection weights, switching requests from the high-performance but currently unstable primary tool to a faster but less accurate backup tool, or adding retry nodes and timeout wait times to the orchestration plan; in moderate anomaly scenarios, the system can skip non-core auxiliary verification steps (such as semantic summary generation and similar case recommendation), retaining only critical paths such as compliance review, sacrificing some user experience for the availability of core business operations; in severe anomaly scenarios, if automated tools are completely unavailable, the orchestration layer can directly route tasks to a manual review queue or return a friendly service busy message, avoiding exposing underlying technical errors to users. For example, during peak travel expense reimbursement periods, if an OCR recognition service timeout is detected, the system automatically downgrades to a logic rule mode that only verifies invoice codes and numbers, temporarily skipping the extraction of invoice details. The information is then asynchronously completed once the service is restored. This dynamic adjustment capability based on real-time performance feedback enables the system to remain resilient in the face of sudden traffic surges or component failures, achieving a technological leap from passive maintenance to proactive self-healing.

[0061] Example 6 As an optional implementation, this application also provides a unified natural language entry point, which receives business questions described by users in natural language. The system combines the knowledge base to perform intent recognition and guides the user to the corresponding target agent or retrieves the answer from the knowledge base based on the recognition results.

[0062] Specifically, this unified natural language entry point constitutes a semantic gateway for system-user interaction. Its core technological value lies in transforming unstructured user expressions into structured instructions or precise knowledge feedback that can be executed by the backend, thereby shielding the technical differences between multiple heterogeneous intelligent agents at the underlying level (such as expense review agents, contract comparison agents, and intelligent form-filling agents). In the processing chain, the intent recognition model first performs semantic parsing and classification on the natural language text input by the user. This model is not a simple keyword matching, but a semantic understanding engine built on a pre-trained language model or a large language model, capable of mapping user input to a predefined intent space. For example, when a user inputs "Help me check the travel accommodation standards," the model classifies it as a "knowledge consultation intent"; while when a user inputs "I want to reimburse the expenses for my business trip to Shanghai last week," the model classifies it as a "business processing intent." This binary or multi-dimensional intent routing mechanism ensures that the system can accurately distinguish between the two distinct needs of "asking for knowledge" and "processing business," avoiding the erroneous triggering of query requests as business processes or the mistreatment of business requests as ordinary question-and-answer requests.

[0063] When the intent recognition result is "business processing intent", the system further performs parameter extraction and task construction operations, which is a key step in realizing natural language-driven intelligent agent orchestration. The system utilizes Named Entity Recognition (NER) or the information extraction capabilities of large models to extract key business parameters (i.e., slot filling) from the user's natural language expression. For example, from the statement "reimburse expenses for last week's business trip to Shanghai", the system automatically extracts structured parameters such as "business type = travel reimbursement", "time range = last week", and "destination = Shanghai". Subsequently, the system encapsulates these extracted parameters according to the task request specification defined in step S102 of Example 1, constructs a standard task request object, and forwards it to the intelligent agent orchestration layer. Upon receiving the request, the orchestration layer can process it like a traditional form submission, matching tool components based on parameters and generating an orchestration plan. This approach eliminates the need for users to remember complex menu paths or fill out cumbersome form fields; they can trigger complex intelligent agent collaboration processes in the background simply with everyday language, significantly reducing the system's operational threshold.

[0064] When the intent recognition result is "knowledge consultation intent," the system initiates a knowledge-based retrieval augmented generation (RAG) process. The system first converts the user's question into a vector representation and performs a semantic similarity search in a pre-built business and financial knowledge base, recalling relevant policy documents, operation manuals, or historical question-and-answer pairs. Subsequently, the system inputs the recalled contextual information along with the user's original question into a generative model. The model then generates an accurate and coherent answer based on solid evidence, along with source citation links. For example, for a question about "travel and accommodation standards," the system not only returns the specific monetary limit but also lists links to the corresponding chapters of the "Travel Management Regulations" for the user to access the original text. This mechanism effectively overcomes the problem of general-purpose large models easily generating illusions in vertical domains, ensuring the authority and traceability of business consultation responses.

[0065] It should be understood that although this embodiment uses text input as an example, in other embodiments, this unified natural language entry point can also be extended to support multimodal interaction forms such as voice input and image upload. For example, a user can directly take a photo of an invoice and ask "Can this invoice be reimbursed?" via voice. The system first identifies the invoice information through the document parsing component, and then makes a comprehensive judgment based on the voice intent. In addition, the granularity of intent recognition can be dynamically adjusted according to the complexity of the business. It can be a coarse-grained three-level classification of "reimbursement / contract / inquiry", or a fine-grained multi-level classification such as "domestic travel reimbursement / international travel reimbursement / entertainment expense reimbursement", as long as it can achieve the function of mapping natural language to the corresponding backend capabilities. By constructing this unified semantic interaction layer, this embodiment not only improves the user experience, but also provides a flexible and low-friction task trigger source for the intelligent agent orchestration layer, enabling the system's intelligent capabilities to empower business personnel in a more natural way.

[0066] Example 7 This embodiment provides an intelligent agent data processing system, such as Figure 2 As shown, the intelligent agent data processing system 200 provided in this embodiment includes at least: The tool component construction layer 201 is used to encapsulate the multiple basic capabilities required for business and financial data processing into reusable tool components; each tool component registers its own capability type, input and output specifications, and applicable scenario tags in a unified tool registry; The intelligent agent orchestration layer 202 is used to receive task requests from business scenarios, parse the target intelligent agents and task parameters called by the task requests, query the tool registry according to the task parameters, match at least one target tool component that is suitable for the current task, and generate an orchestration plan that includes the tool call order and data flow path. The data processing layer 203 is used to call the target tool component to perform data processing according to the orchestration plan, and share the execution results among the target intelligent agents according to the data flow path, so that the execution results of the same target tool component can be reused by multiple target intelligent agents; The compliance verification layer 204 is used to perform compliance verification on the execution results based on a pre-defined set of review strategies and output the verification results. The performance evaluation layer 205 is used to generate multi-dimensional performance evaluation data based on the operational and business metrics of each target intelligent agent and tool component, and to optimize the orchestration decisions of subsequent tasks based on the multi-dimensional performance evaluation data.

[0067] In one possible implementation, the intelligent agent orchestration layer 202 is used to match target tool components in the tool registry according to the task type, and dynamically select the optimal tool combination and tool calling order by combining the precondition judgment and result confidence evaluation of the rule engine; generate a data flow path based on the optimal tool combination and tool calling order, and generate an orchestration plan based on the tool calling order and data flow path.

[0068] In one possible implementation, the data processing layer 203 is used to maintain a unified data cache; wherein the execution results of the tool components are written to the data cache in a standardized format and associated with the corresponding task identifier; when different target agents need the same type of execution result, the execution result is read from the data cache through the task identifier or data type.

[0069] In one possible implementation, the compliance verification layer 204 is used to maintain the review strategy set in the following manner: establishing a review rule-agent dependency graph; when the review rules in the review strategy set are changed, analyzing the affected associated agents based on the review rule-agent dependency graph, and triggering consistency verification for all associated agents, so as to ensure that the review results of each associated agent remain consistent after the review rules in the review strategy set are changed.

[0070] In one possible implementation, the compliance verification layer 204 is also used to adopt a gray-scale activation mechanism for the review rules changed in the review strategy set: the new version of the review rules in the review strategy set is first tested in a specified agent or a specified proportion of tasks, the differences in the review results under the new and old review rules are compared, and the full version is activated after the comparison results are confirmed to be correct.

[0071] In one possible implementation, the multi-dimensional performance evaluation data includes: agent health, including at least a comprehensive health score, operational status distribution, event classification, response latency, and task success rate within the most recently set time range; agent performance, including at least task completion rate, user satisfaction, and agent performance ranking. The agent orchestration layer 202 is also used to automatically trigger a degradation strategy and adjust the tool calling scheme for subsequent tasks when the agent response latency or task success rate exceeds a preset threshold.

[0072] In one possible implementation, the data processing layer 203 is also used to provide a unified natural language entry point, receive business questions described by users in natural language, perform intent recognition in conjunction with a knowledge base, and guide users to the corresponding target agent or retrieve answers from the knowledge base based on the recognition results.

[0073] It should be noted that the principle of the intelligent agent data processing system 200 provided in this embodiment to solve the technical problem is similar to that of the intelligent agent data processing method described above. Therefore, the implementation of the intelligent agent data processing system 200 provided in this embodiment can refer to the implementation of the intelligent agent data processing method described above, and the repeated parts will not be described again.

[0074] Example 8 This embodiment provides an electronic device, which may be, but is not limited to, a computer, mobile phone, tablet computer, etc. Figure 3 As shown, the electronic device 300 provided in this embodiment includes at least a processor 301, a memory 302, and a computer program stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program, it implements the above-described intelligent agent data processing method.

[0075] In one possible implementation, processor 301 can be a single processing element or a collective term for multiple processing elements. For example, processor 301 can be a central processing unit (CPU) or one or more integrated circuits configured to implement the aforementioned intelligent agent data processing method. Specifically, processor 301 can be a general-purpose processor, including but not limited to CPUs, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0076] In one possible implementation, memory 302 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 3021 and / or cache memory 3022, and may further include read-only memory (ROM) 3023; memory 302 may also include a program tool 3025 having a set (at least one) of program modules 3024, including but not limited to: operating subsystem, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0077] In one possible implementation, the electronic device 300 may further include a bus 303 connecting different components (including the processor 301 and the memory 302). The bus 303 represents one or more types of bus structures, including a memory bus, a peripheral bus, a local area bus, etc.

[0078] In one possible implementation, the electronic device 300 can also communicate with one or more external devices 304. These external devices 304 include, but are not limited to: devices that enable a user to interact with the electronic device 300 (e.g., mobile phones, computers, etc.), and / or devices that enable the electronic device 300 to communicate with one or more other electronic devices (e.g., routers, modems, etc.). This communication can be performed through an input / output (I / O) interface 305. Furthermore, the electronic device 300 can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 306. Figure 3 As shown, network adapter 306 communicates with other modules of electronic device 300 via bus 303.

[0079] It should be understood that, despite Figure 3 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 300, including but not limited to microcode, device drivers, redundant processors, external disk drive arrays, Redundant Arrays of Independent Disks (RAID) subsystems, tape drives, and data backup storage subsystems.

[0080] It should be noted that, Figure 3 The electronic device 300 shown is merely an example and should not impose any limitations on the functionality and scope of use of this embodiment.

[0081] Furthermore, this embodiment also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the aforementioned intelligent agent data processing method. Specifically, the computer instructions may be built into or installed in a processor, enabling the processor to implement the aforementioned intelligent agent data processing method by executing the built-in or installed computer instructions.

[0082] In addition, this embodiment also provides a program product, which includes program code that, when executed by a processor, implements the above-described intelligent agent data processing method.

[0083] The program product provided in this embodiment can be any combination of one or more readable media. The readable media can be a readable signal medium or a readable storage medium. The readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or any combination thereof. Specifically, more specific examples of readable storage media (a non-exhaustive list) include: electrical connections with one or more wires, portable disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM), optical fibers, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0084] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0085] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0086] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0087] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

Claims

1. A method for processing data from an intelligent agent, characterized in that, include: The basic capabilities required for business and financial data processing are encapsulated into reusable tool components; each tool component registers its own capability type, input and output specifications, and applicable scenario tags in a unified tool registry. Receive task requests from business scenarios, parse the target intelligent agents and task parameters called by the task requests; query the tool registry according to the task parameters, match at least one target tool component that is suitable for the current task, and generate an orchestration plan that includes the tool call order and data flow path; According to the orchestration plan, the target tool component is invoked to perform data processing, and the execution results are shared among the target agents according to the data flow path, so that the execution results of the same target tool component can be reused by multiple target agents; The execution results are validated for compliance based on a pre-defined set of review strategies, and the validation results are output. Multi-dimensional performance evaluation data is generated based on the operational and business metrics of each target intelligent agent and target tool component, and the orchestration decisions for subsequent tasks are optimized based on the multi-dimensional performance evaluation data.

2. The intelligent agent data processing method as described in claim 1, characterized in that, Based on the task parameters, the tool registry is queried to match at least one target tool component suitable for the current task, and an orchestration plan containing the tool call order and data flow path is generated, including: Based on the task type, the target tool components are matched in the tool registry, and the optimal tool combination and tool invocation order are dynamically selected by combining the precondition judgment of the rule engine and the result confidence evaluation. The data flow path is generated based on the optimal tool combination and the tool call order, and the orchestration plan is generated based on the tool call order and the data flow path.

3. The intelligent agent data processing method as described in claim 1, characterized in that, The execution results are shared among the target agents according to the data flow path, including: Maintain a unified data cache; wherein, the execution results of tool components are written to the data cache in a standardized format and associated with the corresponding task identifier; When different target agents require the same type of execution result, the execution result is read from the data cache through the task identifier or data type.

4. The intelligent agent data processing method as described in claim 1, characterized in that, The review strategy set is maintained in the following manner: Establish review rules - agent dependency graph; When the review rules in the review strategy set are changed, the affected associated agents are analyzed based on the review rule-agent dependency graph, and a consistency check is triggered for all associated agents to ensure that the review results of each associated agent remain consistent after the review rules in the review strategy set are changed.

5. The intelligent agent data processing method as described in claim 4, characterized in that, The changes to the review rules in the review strategy set support a phased implementation mechanism: the new version of the review rules in the review strategy set is first tested in a specified agent or a specified proportion of tasks, and the differences in the review results under the new and old review rules are compared. Once the comparison results are confirmed to be correct, the changes are fully implemented.

6. The intelligent agent data processing method as described in claim 1, characterized in that, The multi-dimensional performance evaluation data includes: agent health, including at least a comprehensive health score, operational status distribution, event classification, response latency, and task success rate within the most recent set time range; agent performance, including at least task completion rate, user satisfaction, and agent performance ranking. The intelligent agent data processing method further includes: when the response latency or task success rate of the target intelligent agent is detected to exceed a preset threshold, an automatic degradation strategy is triggered to adjust the tool invocation scheme for subsequent tasks.

7. The intelligent agent data processing method as described in claim 1, characterized in that, Also includes: It provides a unified entry point for natural language, receives business questions described by users in natural language, performs intent recognition in conjunction with a knowledge base, and guides users to the corresponding target agent or retrieves the answer from the knowledge base based on the recognition results.

8. A smart agent data processing system, characterized in that, include: The tool component building layer is used to encapsulate the multiple basic capabilities required for business and financial data processing into reusable tool components. Each tool component registers its own capability type, input and output specifications, and applicable scenario tags in a unified tool registry. The intelligent agent orchestration layer is used to receive task requests from business scenarios, parse the target intelligent agents and task parameters called by the task requests, query the tool registry according to the task parameters, match at least one target tool component that is suitable for the current task, and generate an orchestration plan that includes the tool call order and data flow path. The data processing layer is used to call the target tool component to perform data processing according to the orchestration plan, and share the execution results among the target agents according to the data flow path, so that the execution results of the same target tool component can be reused by multiple target agents. The compliance verification layer is used to perform compliance verification on the execution results based on a preset set of review strategies and output the verification results. The performance evaluation layer is used to generate multi-dimensional performance evaluation data based on the operational and business metrics of each target intelligent agent and tool component, and to optimize the orchestration decisions of subsequent tasks based on the multi-dimensional performance evaluation data.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the intelligent agent data processing method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the intelligent agent data processing method as described in any one of claims 1-7.

Images