Hierarchical decoupling multi-agent lca accounting method, system and readable storage medium

Abstract

This invention relates to a layered and decoupled multi-agent LCA (Limited Action Computation) method, system, and readable storage medium. The method includes: monitoring the global state through a coordinating and management agent located in the core scheduling layer to generate structured scheduling intentions; using a workflow engine as a mandatory intermediary to parse the scheduling intentions into atomic task sequences and distribute them, with this engine constituting the sole source of instructions for business agents. Each business agent only responds to instructions to execute tasks, reports its status, and writes logs to the data storage module of the basic support layer. A specialized experience memory module located in the basic support layer precipitates knowledge from the logs to form experience rules, and performs fusion verification with the LCA basic knowledge base. Verified experience rules are stored as experience integration entries in the specialized experience memory module for the coordinating and management agent to call on demand. This invention solves the problems of disordered multi-agent collaboration and difficulty in experience reuse, improving the efficiency and stability of LCA calculation.

Description

Technical Field

[0001] This invention relates to the field of product lifecycle accounting technology, and in particular to a hierarchical decoupled multi-agent LCA accounting method, system, and readable storage medium. Background Technology

[0002] Product Life Cycle Assessment (LCA), as a core methodology for quantifying the environmental impact of products, directly determines the reliability and practicality of product carbon footprint results through its accuracy and efficiency. Traditional product LCA calculation and reporting are typically completed manually, from preliminary research, modeling and calculation, results analysis, to final report output and review. This process relies heavily on the vertical domain knowledge of industry experts and the research experience of LCA specialists, resulting in high barriers to entry and low efficiency.

[0003] To improve the level of automation, various improvement schemes have been proposed in existing technologies, but some limitations still exist:

[0004] For example, Chinese invention patent CN117974399A discloses a carbon footprint analysis system and method for cross-value chain collaborative suppliers based on LCA. By dividing the process into five modules—data extraction, carbon footprint calculation, correlation analysis, model adjustment, and report generation—it achieves task closure and full-process automation, significantly improving efficiency compared to traditional manual processes. However, this type of solution, based on fixed functional modules, often suffers from rigid business processes, poor scalability, and high maintenance costs due to strong coupling between data flow and logic.

[0005] For example, Chinese invention patent CN121094348A discloses a product carbon footprint analysis method based on intelligent agents. It mainly reduces the threshold and improves efficiency by constructing a single carbon footprint intelligent agent to execute multiple sub-tasks in the entire product LCA accounting process. However, the various business functions in the single intelligent agent architecture are highly coupled, and it lacks reusability and scalability in different scenario tasks.

[0006] In addition to the above-mentioned method for single agent to realize product LCA accounting, Chinese invention patent with publication number CN118940541A discloses a method for constructing a carbon calculation model with multi-agent division of labor and cooperation. It is naturally adapted to diverse demand scenarios and meets the dynamic addition of business links. However, the agents adopt a direct communication method, lack unified scheduling, and are prone to instruction conflicts and inconsistent states, making it difficult to trace and maintain.

[0007] Furthermore, due to the lack of centralized storage and management of historical execution data, existing technical solutions are more suitable for handling multiple unrelated tasks. When faced with multiple iterative adjustments or periodic repetitive calculations for the same task, they cannot perceive and utilize historical experience, making it difficult to achieve closed-loop control and adaptive optimization driven by historical experience data. In response, Chinese invention patent CN122287685A discloses an intelligent agent self-evolution system based on closed-loop evaluation feedback, which drives knowledge base updates through an independent evaluation and supervision agent cluster. However, this technical solution discloses a general technical path and lacks specific design for the structured logs, domain knowledge graphs, and complex verification rules unique to the LCA domain, making it unable to directly adapt to the complex scenarios of high precision and strong specifications in LCA calculations. Summary of the Invention

[0008] The purpose of this invention is to provide a hierarchical decoupled multi-agent LCA accounting method, system, and readable storage medium, aiming to solve the problems existing in the prior art such as rigid business processes, disordered agent collaboration, lack of experience accumulation mechanism, and insufficient adaptive optimization capability.

[0009] To achieve the above objectives, this invention provides a layered and decoupled multi-agent LCA accounting method, applied to a three-layer architecture including a core scheduling layer, a business execution layer, and a basic support layer, comprising:

[0010] The coordination and management agent located in the core scheduling layer continuously monitors and obtains the global system status information in the basic support layer, and generates a structured scheduling intention. The scheduling intention includes at least the task objective, execution progress, historical experience reuse strategy and task dependency constraints.

[0011] The workflow engine, located in the core scheduling layer, acts as a mandatory intermediary to parse the scheduling intent into an atomic task execution sequence and distribute it to each business agent located in the business execution layer; wherein, the workflow engine constitutes the sole source for the business agents to receive atomic task instructions;

[0012] Each business intelligence agent only responds to the received atomic task instructions to execute the corresponding business, feeds back the execution status information to the coordination and management intelligence agent, and writes the task log of the execution output into the data storage module of the basic support layer;

[0013] The specialized experience memory module located in the basic support layer responds to the execution process of the business intelligence agent, and extracts domain knowledge from the task logs stored in the data storage module to form experience rules;

[0014] The empirical rules are fused and verified with the LCA basic knowledge base, and the verified empirical rules are stored as experience integration entries in the specialized experience memory module, which is then called by the coordination and management agent as needed according to the task characteristics.

[0015] The coordination and management agent dynamically adjusts the scheduling intent of subsequent tasks based on the retrieved experience integration entries.

[0016] Optionally, the process by which the workflow engine parses the scheduling intent includes:

[0017] Read the task dependency constraints in the scheduling intent and construct a directed acyclic graph representing the current computation task dependencies;

[0018] Read the execution progress in the scheduling intention, remove the completed nodes and their associated edges from the directed acyclic graph, and use the remaining edges and nodes as the basis for scheduling the next task.

[0019] For an atomic task that has defined preconditions in the task dependency constraints, the start instruction of the atomic task is triggered only when all the preconditions in the execution progress are in a successful state.

[0020] Atomic tasks that do not have the preceding task are placed into the ready queue. They are prioritized based on the system resource usage status, the cumulative waiting time of subsequent dependent tasks, and the expected resource usage of the tasks to be executed, and the instantiation and distribution of atomic tasks are completed dynamically.

[0021] Optionally, the method further includes:

[0022] The coordination and management agent receives task execution events through a subscription-push mechanism and updates the historical experience reuse strategy in the scheduling intent based on the results pushed by the basic support layer.

[0023] When it is determined that the original historical experience reuse strategy is not suitable for the current task, the original historical experience reuse strategy and the reference experience integration entries are adjusted to generate an updated scheduling intent carrying a new intent ID and synchronize it to the workflow engine. The workflow engine then dynamically orchestrates the pending tasks that have not yet started based on the updated data and distributes new atomic task instructions.

[0024] The coordination and management agent manages the task lifecycle by monitoring the execution progress in the scheduling intent. When the overall status field in the execution progress is updated from in progress to any final state value such as successful, manually approved, terminated, or canceled, the resources occupied by this round of scheduling are released.

[0025] Optionally, the step of the specialized experience memory module accumulating domain knowledge and forming the experience rules includes:

[0026] Log collection and structuring transforms the semi-structured task logs written by the business execution layer into a structured experience carrier carrying semantic information. The structured experience carrier includes at least an LCA semantic context and structured execution records.

[0027] Experience extraction generates task experience summaries for individual tasks, and when the candidate pool composed of these task experience summaries accumulates to a threshold, a hybrid strategy of vector clustering and inductive reasoning using a large language model is used to mine common patterns across tasks and generate experience rules.

[0028] Optionally, the knowledge fusion verification step specifically includes:

[0029] The core fields of the empirical rules are concatenated into a unified text and encoded into a semantic vector;

[0030] The semantic vector is used to perform nearest neighbor retrieval in the LCA basic knowledge base with an explicit graph structure. The top K knowledge base nodes with the highest similarity are obtained as the initial hit set, and the set of verification nodes is obtained by expanding outward along the relation edges.

[0031] The content of each verification node is input into the large language model with the semantic vector for semantic comparison, and the judgment conclusion of consistency, contradiction or neutrality is output.

[0032] The confidence level of the empirical rule is calculated based on the judgment conclusion. When the confidence level is higher than the write threshold, it passes the verification. When it is between the write threshold and the review threshold, it enters the manual review queue. When it is lower than the review threshold, it is discarded, and all task experience summaries related to the empirical rule are triggered to flow back to the candidate pool.

[0033] Optionally, the method further includes:

[0034] During continuous operation, incremental update paths are executed on newly generated task experience summaries:

[0035] Calculate the similarity between the newly generated task experience summary and the existing experience integration entries;

[0036] When the similarity is not lower than the first threshold, the identifier of the newly generated task experience summary is added to the source identifier field of the existing experience integration entry;

[0037] When the similarity is between the second threshold and the first threshold, the large language model determines whether to extend the applicable conditions of the existing experience integration items or split them into multiple experience integration items according to different recommendation methods.

[0038] When the similarity is lower than the second threshold, the newly generated task experience summary is temporarily stored in the candidate pool, and when a new experience integration entry is created in the future, a reverse scan of the existing task experience summaries in the candidate pool is triggered.

[0039] Optionally, before dynamically adjusting the scheduling intent of subsequent tasks based on the experience-integrated entries, the method further includes:

[0040] Before key decision-making nodes in the task execution process, the coordination and management agent constructs retrieval conditions and initiates query requests;

[0041] A hybrid query is performed using a dual-track indexing mechanism consisting of structured indexes and semantic vector indexes, and the top N results are taken as candidate experience integration entries.

[0042] For regular experience integration items, their content is formatted into natural language and input into the reasoning model within the business intelligence body along with the atomic task instructions to achieve context enhancement; for operational experience integration items, they are converted into structured parameters and embedded into the atomic task instructions to constrain the execution scope.

[0043] Optionally, the method further includes:

[0044] Each business intelligence agent is required to output the adoption status and decision basis of the recalled experience integration items during this execution after completing the task, and push it to the basic support layer;

[0045] For experience integration entries that were recalled but not adopted, update their rejection count and adoption rate fields, and narrow their scope of application based on the reasons for rejection;

[0046] For adopted experience integration items, update their adoption count, adoption rate, and most recent usage time fields. Score the task outputs produced after all adopted experience integration items. When the score is lower than the preset threshold, update the status of the experience integration items reused in the task to pending review and apply for manual review.

[0047] Based on the same inventive concept, this invention also provides a layered and decoupled multi-agent LCA accounting system, comprising a three-layer architecture of a core scheduling layer, a business execution layer, and a basic support layer, wherein:

[0048] The core scheduling layer includes a coordination and management agent and a workflow engine. The core scheduling layer is configured to continuously monitor and acquire global system state information from the basic support layer, and generate structured scheduling intentions. These scheduling intentions include at least task objectives, execution progress, historical experience reuse strategies, and task dependency constraints. The workflow engine, acting as a mandatory intermediary, is configured to parse the scheduling intentions into atomic task execution sequences and distribute them to each business agent located in the business execution layer. The workflow engine constitutes the sole source for the business agents to receive atomic task instructions.

[0049] The business execution layer includes multiple business intelligent agents with single responsibilities. Each business intelligent agent is configured to execute the corresponding business only in response to the received atomic task instructions and feed back the execution status information to the coordination and management intelligent agent.

[0050] The basic support layer includes a specialized experience memory module and a data storage module. The data storage module is configured to store task logs and LCA basic knowledge bases produced by the business execution layer. The specialized experience memory module is configured to, in response to the execution process of the business agent, extract domain knowledge from the task logs stored in the data storage module to form experience rules; and to perform knowledge fusion verification between the experience rules and the LCA basic knowledge base, and store the verified experience rules as experience integration entries for the coordination and management agent to retrieve and call as needed.

[0051] The coordination and management agent is also configured to dynamically adjust the scheduling intent of subsequent tasks based on retrieved experience integration entries.

[0052] Based on the same inventive concept, the present invention also provides a readable storage medium having a computer program stored thereon, which, when executed, can implement the hierarchical decoupled multi-agent LCA accounting method as described above.

[0053] The hierarchical decoupled multi-agent LCA accounting method, system, and readable storage medium provided by this invention have at least one of the following beneficial effects:

[0054] (1) This invention constructs a three-layer architecture consisting of a core scheduling layer, a business execution layer, and a basic support layer. A workflow engine supporting dynamic process orchestration is introduced as a mandatory intermediary between the decision-making and execution layers, achieving physical isolation between the decision flow and the business flow. Taking real-world data cleaning in LCA accounting as an example, whether it's standard parsing, parameter configuration, or model verification, all instructions are uniformly issued by the workflow engine, avoiding resource contention and state inconsistency issues caused by the data cleaning agent receiving multiple conflicting data reconfirmation requests simultaneously. This controllable communication path design ensures system state consistency in long-process LCA accounting scenarios, significantly improving system stability.

[0055] (2) In this invention, a coordinating and management agent acts as the sole global "decision-maker," and a workflow engine is used to achieve dynamic and intelligent scheduling of the entire LCA accounting process. The system can flexibly arrange workflows based on the historical execution trajectories stored in the basic support layer and the accumulated LCA basic knowledge base, avoiding the repeated execution of the same atomic tasks. This mechanism not only breaks through the limitations of functional coupling of traditional single agents and the easy conflict of direct communication between multiple agents, but also ensures the efficiency and simplification of the accounting process, effectively optimizing the utilization rate of system resources.

[0056] (3) This invention adopts a completely decoupled approach between control logic and business logic. Each agent in the business layer executes specific atomic tasks entirely according to the task sequence orchestrated by the workflow engine, without needing to be aware of other links in the process, thus achieving separation and independence between different business agents. When faced with accounting tasks of different depths or standard changes common in the LCA domain, the system only needs to adjust the orchestration logic of the workflow engine, or add, delete, or replace the corresponding business agents to quickly adapt. The business logic within each agent does not need to be adjusted, which significantly reduces maintenance costs and improves the scalability of the system.

[0057] (4) This invention designs the basic support layer as a proactive data memory hub, recording historical task data and key decisions through a specialized experience memory module, and transforming them into reusable experience within the context of product LCA accounting. The system uses a common LCA basic knowledge base as the "gold standard" to verify experience, avoiding the pollution of the experience base by decision-making biases in the business execution layer; at the same time, it continuously corrects and refines existing experience memory based on traceability and confidence update mechanisms. This not only significantly reduces the cost of repeated trial and error for similar tasks, shortens execution time, and improves output consistency, but also achieves efficient iteration based on experience memory, forming an effective quality closed loop of "accumulation-verification-reuse-feedback". Attached Figure Description

[0058] Those skilled in the art will understand that the accompanying drawings are provided to better understand the invention and do not constitute any limitation on the scope of the invention. Wherein:

[0059] Figure 1 This is an architecture diagram of a layered and decoupled multi-agent LCA accounting system provided in an embodiment of the present invention;

[0060] Figure 2 This is a flowchart illustrating the internal processing and global interaction of forming a specialized experience memory module, as provided in an embodiment of the present invention. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0062] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0063] In the description of this invention, it should be understood that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product is in use, or the orientation or positional relationship commonly understood by those skilled in the art. They are only used to facilitate the description of this invention and to simplify the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0064] Furthermore, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or apparatus that includes said element. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0065] Please refer to Figures 1-2 This invention provides a layered and decoupled multi-agent LCA accounting system and a corresponding LCA accounting method to automate the entire process of product LCA accounting and reporting. The multi-agent LCA accounting system mainly comprises a three-layer architecture: a core scheduling layer, a business execution layer, and a basic support layer. The LCA accounting method includes:

[0066] S100: The coordination and management agent located in the core scheduling layer continuously monitors and obtains the global system status information in the basic support layer, and generates a structured scheduling intention. The scheduling intention includes at least the task objective, execution progress, historical experience reuse strategy and task dependency constraints.

[0067] S200: The workflow engine located in the core scheduling layer acts as a mandatory intermediary, parsing the scheduling intent into an atomic task execution sequence and distributing it to each business agent located in the business execution layer; wherein, the workflow engine constitutes the sole source for business agents to receive atomic task instructions;

[0068] S300: Each business agent only responds to the received atomic task instructions to execute the corresponding business, feeds back the execution status information to the coordination and management agent, and writes the task logs produced by the execution into the data storage module of the basic support layer;

[0069] S400: The specialized experience memory module located in the basic support layer responds to the execution process of the business intelligence agent, and extracts domain knowledge from the task logs stored in the data storage module to form experience rules.

[0070] S500 performs knowledge fusion verification between the empirical rules and the LCA basic knowledge base, and stores the verified empirical rules as experience integration entries in the specialized experience memory module, so that the coordination and management intelligent agent can retrieve and call them as needed according to the task characteristics.

[0071] S600: The coordination and management agent dynamically adjusts the scheduling intent of subsequent tasks based on the retrieved experience integration entries.

[0072] This invention constructs a three-layer architecture consisting of a core scheduling layer, a business execution layer, and a basic support layer. A workflow engine supporting dynamic process orchestration is introduced as a mandatory intermediary between the decision-making and execution layers, achieving physical isolation between the decision flow and the business flow. This avoids state chaos caused by multiple decision sources acting simultaneously on the same business agent. Simultaneously, each business agent in the business execution layer executes specific atomic tasks entirely according to the task sequence orchestrated by the workflow engine, without needing to be aware of other links in the process, thus achieving separation and independence between different business agents. This invention employs a completely decoupled approach between control logic and business logic, ensuring that the system can quickly respond to LCA (Limited Accounting Computation) task requirements of varying depths and flexibly adapt to common LCA changes and database updates, significantly improving the system's maintainability and scalability. Furthermore, the specialized experience memory module in the basic support layer empowers the system to learn and iterate from its own usage history. By summarizing decision-making experience from historical tasks, it significantly reduces the cost of repeated trial and error for similar tasks, shortens the average execution time, and improves the consistency of system output to a certain extent. Moreover, it uses common LCA basic knowledge as the "gold standard" for verifying task execution experience, avoiding the pollution of the experience memory by decision-making biases in the business execution layer, thus preventing a vicious cycle. In this way, existing experience memory is continuously corrected and refined in actual application, forming an effective quality closed loop.

[0073] Specifically, S100 is executed first. The coordination and management agent located in the core scheduling layer continuously monitors and obtains the global system status information in the basic support layer, and generates a structured scheduling intention. The scheduling intention includes at least the task objective, execution progress, historical experience reuse strategy and task dependency constraints.

[0074] Next, S200 is executed, where the workflow engine located in the core scheduling layer acts as a mandatory intermediary to parse the scheduling intent into an atomic task execution sequence and distribute it to each business agent located in the business execution layer; among them, the workflow engine constitutes the sole source for business agents to receive atomic task instructions.

[0075] In this embodiment, the core scheduling layer is responsible for the decision-making and routing of LCA (Limited Action Calculation) tasks, and mainly consists of a coordination and management agent and a workflow engine. The coordination and management agent is the only decision controller in the system, responsible for perceiving the global state of the system and making intelligent decisions by analyzing state information in real time, outputting structured scheduling intentions. The workflow engine, as a mandatory intermediary between decision-making and execution, is responsible for atomically parsing and dynamically orchestrating the workflow based on the scheduling intentions output by the coordination and management agent, and distributing it to the corresponding business execution nodes.

[0076] The working principle of this coordination and management agent is as follows: The agent continuously acquires global system status information from the basic support layer. Dynamic information such as newly input LCA accounting task requests from users, and the task execution status and result feedback of each business layer agent are instantly notified through a "subscribe-push" mechanism between the basic support layer and the core scheduling layer. Supporting information such as the LCA basic knowledge base and historical task data are directly accessed by the coordination and management agent according to task needs. The coordination and management agent analyzes the perceived information in real time and makes intelligent decisions, generating structured "scheduling intent" data to clarify task objectives, execution progress, priorities, historical experience reuse strategies, task dependency constraints, resource limitations, and exception handling contingency plans.

[0077] The coordination and management agent will automatically send the above-mentioned structured scheduling intent data to the workflow engine, which will then parse it into specific atomic task execution sequences and distribute them to the corresponding business execution agents.

[0078] When parsing intents, the workflow engine first constructs a directed acyclic graph (DAG) representing the dependencies of currently computed tasks by reading task dependency constraints. Simultaneously, it removes all completed nodes and their associated edges from the complete DAG, based on the execution progress in the scheduling intent. The remaining edges and nodes serve as the core basis for the next step of task orchestration. For atomic tasks with preconditions defined in the task dependency constraints, the workflow engine must first confirm the status of its preconditions through the execution progress information. Only when all preconditions are successful can the task start instruction be triggered. Furthermore, the workflow engine places all atomic tasks without any preconditions into a ready queue. By monitoring system resource usage and the cumulative waiting time of subsequent dependent tasks in the queue in real time, and combining this with the expected resource usage of the tasks to be executed, the engine prioritizes tasks and dynamically completes task instantiation and distribution.

[0079] Preferably, in the structured scheduling intent data, the specific content of the execution progress list is dynamically updated based on the execution status of atomic tasks pushed by the basic support layer. After each update, it needs to be synchronized to the workflow engine to complete the closed loop of the "perception-analysis-scheduling-execution-feedback" process. Specifically, after receiving the task execution event notification through the "subscription-push" mechanism, the coordination and management agent should obtain the result of the task and the latest global experience memory status from the basic support layer, check whether the experience referencing strategy of the previous version is consistent with the current task situation, and update the content in the historical experience reuse strategy. For example, initially, based on the Product Category Rules (PCR) required for user modeling and the existing content in the experience memory, the historical experience reuse strategy is atomic task reuse. However, analysis of the user-uploaded data list reveals that the experience memory does not contain results that are fully compatible. Therefore, it's impossible to continue reusing experience data from subsequent stages like data cleaning at the atomic task granularity. The coordination and management agent will then adjust the historical experience reuse strategy to non-reuse. Similarly, before executing the parameter matching task, the coordination and management agent compares the modeling results output from the preceding task with the experience memory content. If reusable experience integration entries exist in the experience memory, the historical experience reuse strategy is dynamically adjusted to configuration pair reuse (i.e., reuse by configuration, in a paired manner). Based on the above checks, the coordination and management agent generates a new version of the scheduling intent based on the original scheduling intent, with each version distinguished by its intent ID. The updated scheduling intent carrying the new intent ID is synchronized to the workflow engine via a dedicated message queue. The workflow engine dynamically orchestrates pending tasks based on the updated data and distributes new atomic task instructions.

[0080] The coordination and management agent needs to manage the task lifecycle by continuously monitoring and updating the execution progress field. When this field is updated from "in progress" to any final state value, the core scheduling layer completes the closed-loop control of this round and releases the relevant resources. The specific final state values ​​and judgment conditions are shown in Table 1 below:

[0081] Table 1

[0082]

[0083] Next, S300 is executed. Each business agent only responds to the received atomic task instructions to execute the corresponding business, feeds back the execution status information to the coordination and management agent, and writes the task logs produced by the execution into the data storage module of the basic support layer.

[0084] In this embodiment, the business execution layer consists of multiple LCA business agents with single responsibilities (such as PCR parsing agents, data cleaning agents, etc.). To completely avoid conflicts between multiple sources of instructions, there are no direct communication links between the agents, and they strictly follow the pattern of "passively receiving instructions - independently executing business - centrally feeding back results" during operation.

[0085] When the workflow engine sends structured atomic task instructions to the business agent specified in the "Task Execution Agent" field via the message middleware, the corresponding agent passively accepts the instructions and parses the core structured fields. The "Input" field in the task instruction uses data reference descriptors to define all the context required to execute the atomic task. Its content is differentiated according to the "Task Type." For example, the "Input" field for a data cleaning task includes the original data address and a reference to the cleaning rules output by PCR parsing; the "Input" field for a parameter matching task includes a list of stream entities to be matched and a reference to the target database specified by the user. These data reference descriptors point to structured resource locators of data already stored in the basic support layer. Detailed content in all relevant data files can be read through the unified data access interface provided by the basic support layer. When the "Input" field contains "Experience ID" (reusable historical experience), the business agent can query the specialized experience memory module of the basic support layer using the experience ID to obtain detailed data about the relevant experience.

[0086] Based on the acquired contextual data, the business intelligence agent will dynamically configure the runtime environment according to the constraints defined in the "Task Constraints" field, such as task timeout and maximum number of retries. This mainly includes: setting resource quotas such as CPU and memory for this task instance through resource control groups or container technology, and maintaining independent timers and task attempt counters to ensure that the task runs independently under controlled resource and time constraints.

[0087] The task instruction itself does not contain the specific logic for executing the current task; the actual execution process is entirely handled by specialized business intelligence agents. Each business intelligence agent can independently execute its professional function based on its internally encapsulated business algorithms. The following is a detailed explanation using a common business intelligence agent as an example:

[0088] 1) PCR analysis intelligent agent

[0089] The PCR parsing agent receives parsing tasks through the workflow engine. This atomic task instruction contains an extensible PCR identifier object, which consists of one required field and several optional fields: Product Category is a required field used to describe the product category name; optional fields include the issuing body (standard Body), PCR number (pcr Code), version number (in terms of last update time), and applicable region, for example: {product Category:"concrete", pcr Code:"PCR-EN 16757"}.

[0090] The PCR parsing agent uses the PCR identifier as the query condition and performs multi-field fuzzy matching in the existing knowledge base of the basic support layer. During the search, all fields in the PCR identifier are used for matching first. If a unique match is found, the process proceeds directly to the next parsing step. If multiple PCR original documents are matched, the applicability of each document needs to be further quantified according to preset scoring rules. Evaluation dimensions can include matching score, timeliness score, and authority score (this is just an example; evaluation dimensions can be added or removed according to actual needs). The document with the highest total score proceeds to the next parsing step. If no match is found, non-mandatory fields such as applicable region, version number, RCR number, and publishing organization are removed sequentially to broaden the search conditions until a match is found or only the mandatory field of product type remains. When a unique PCR original document is finally matched, the broadened search conditions and search result metadata are encapsulated into a query message and pushed to the coordination and management agent. After user confirmation, the parsing process begins. When multiple PCR original documents are matched during the search, the handling method is the same as when multiple matches are matched using full-field matching. If no local files are found even after the query criteria are broadened to include only product type, an external retrieval task should be triggered.

[0091] When performing external acquisition tasks, the appropriate method should be selected based on the task context:

[0092] ① When the publishing organization is known and the target publishing organization provides a public API, the PCR identifier field should first be converted into a request format accepted by the target API, such as structured parameters or search expressions, and then a request should be sent to the API. If the response directly returns the original PCR text (such as a PDF binary stream, HTML text, or XML document), the original text should be saved to the basic support layer for parsing; if the response returns JSON / XML metadata containing a download link, a second request should be made to the link to obtain the original text and then saved to the basic support layer for parsing. If the API return result does not contain a valid download link or the request fails, the process should automatically fall back to the next level of retrieval strategy.

[0093] ② When the publishing organization is unknown or the target publishing organization's website prohibits automated crawling, a query link for a general search engine can be generated based on the PCR identifier field to guide users to search, download and upload the original PCR document themselves, and the agent does not perform any automated search or crawling.

[0094] ③ When users cannot obtain the original PCR text through the query link provided by the intelligent agent, or when users already have a local document, they can also submit a PDF file directly through the upload interface;

[0095] ④ When the user confirms that the original PCR document cannot be provided, the error log should record "PCR document missing" and the task status should be marked as "failed".

[0096] After obtaining the original PCR file, a combination of rule templates and Natural Language Processing (NLP) can be used to accurately extract information including, but not limited to, scope of application, functional / declaration units, stage division methods, truncation principles, allocation rules, reporting indicators, data quality evaluation rules, uncertainty analysis, and sensitivity analysis requirements. The extracted results are converted into JSON format data objects via a structured output unit and written to the basic support layer, establishing an association index with the original PCR file. After completing the above parsing task, the task status is marked as "successful," and task completion information, including the storage path of the parsing results and a summary of key information, is fed back to the coordination and management agent.

[0097] 2) Data Cleaning Intelligent Agent

[0098] The data cleaning agent receives data cleaning tasks through the workflow engine. The atomic task instruction contains the original data address and the cleaning rule address. The original data address points to the data to be cleaned in the basic support layer, and the cleaning rule address points to the structured rules (mainly involving truncation principles, data quality evaluation rules, etc.) and the preset general rule library (mainly involving the input format definition required for model building agents) output by the PCR parsing agent.

[0099] The data cleaning process includes initial screening of outliers, standardization of heterogeneous data, and fusion of multi-source data, among which:

[0100] The initial screening for outliers primarily targets missing essential fields, abnormal zero or negative values, duplicate primary keys, and outlier data points. After identifying outliers, the data cleaning agent first performs automatic repair operations: for example, for duplicate primary keys, it retains the record with the latest timestamp and deletes the rest; for outlier data points, it uses the interquartile range (IQR) method to identify them and replaces them with the median; for missing essential fields, it uses techniques such as pre-set mapping table transformation, association rule prediction, and machine learning imputation to infer or generate the missing essential field from other fields in the same record. All automatic repair trigger rules, processing methods, timestamps, and other information are written to the cleaning log and stored in the basic support layer. If automatic repair cannot be completed (e.g., for negative value records without adjacent data support), the error reason is recorded, and the corresponding data is isolated to the "pending review" partition, prompting the coordination and management agent to request manual intervention.

[0101] The standardization process for heterogeneous data mainly includes the unification of units of measurement and the alignment of statistical periods. The unification of units of measurement is mainly completed based on the pre-built conversion factor library in the basic support layer, and all data are measured based on the standard units of their respective physical attributes. The alignment of statistical periods can be achieved by using time resampling technology. Data with a source data frequency higher than the target period is downsampled and aggregated, while data with a source data frequency lower than the target period is upsampled by uniform distribution or interpolation according to auxiliary weights (such as output).

[0102] Multi-source data fusion primarily handles the mapping and selection between data from different sources. The data cleaning agent identifies the data to be fused based on the primary key mapping table stored in the foundational support layer. When the multi-source data information is consistent, the merging operation is automatically performed; when multi-source data information conflicts, a voting mechanism or selection based on preset data source priority (enterprise measurements > industry databases > literature values) is used, and conflict records, handling methods, and decision-making basis are written to the cleaning log. The primary key mapping table in the foundational support layer is initially built offline by human experts and supports semi-automatic expansion through string similarity calculation and NLP entity recognition.

[0103] The cleaned data is written to the basic support layer in Parquet or CSV format and its lineage is established with the original data, forming a lineage metadata table containing information such as the cleaned data ID, the original data ID, the list of cleaning rules, the cleaning task timestamp, and the storage path of the cleaning log. Upon completion, the data cleaning task status is updated to "success," and the status and summary of this cleaning task are pushed to the coordination and management agent. In addition to the cleaned data, the cleaning process must be recorded in a structured data cleaning report, mainly including the number of original data rows, the number of valid cleaned data rows, the number of abnormal data rows, and a classification and count of the reasons for and handling methods of the abnormalities, for subsequent traceability.

[0104] 3) Model building of intelligent agents

[0105] The model-building agent receives modeling tasks through the workflow engine. This atomic task instruction includes the storage path for the parsing results output by the PCR parsing agent and the storage path for the structured data output by the data cleaning agent. The model-building agent first loads the two inputs from the basic support layer: the former is a PCR rule object in JSON format, containing constraints such as stage division methods, truncation principles, functional units, and allocation rules; the latter is a structured list data set in Parquet or CSV format, where each data item includes at least the process identifier, flow direction (input or output), flow type (basic flow or intermediate flow), quantity, and unit of measurement.

[0106] The core task of model building is to transform the aforementioned flattened inventory data into a lifecycle model with a topological structure. The modeling process consists of four steps: phase division, topology construction, allocation processing, and traffic correlation and model validation.

[0107] In the stage division step, the model building agent maps each process to its corresponding lifecycle stage according to the stage division method in the PCR rule object. During mapping, semantic matching is performed between the process's own attribute tags (such as process type, description of the current stage, etc.) and the stage boundaries defined by PCR. If a process cannot be clearly assigned to any stage, it is temporarily marked as "pending assignment" and recorded in the exception log.

[0108] In the topology construction step, the model-building agent traverses the structured inventory data set to identify upstream and downstream relationships between processes. The specific identification rule is: when an intermediate flow is an output in process A and an input in process B, process A is determined to be an upstream of process B. Based on this, the model-building agent generates a directed graph structure, where nodes represent processes and directed edges represent the flow of materials or energy between processes. After generating the directed graph, the model-building agent performs topology validity checks: detecting the existence of isolated nodes (i.e., processes unrelated to any other processes) and unexpected circular dependencies. Isolated nodes are recorded in the anomaly log; for circular dependencies, it is determined whether they belong to a reasonable recycling situation in the industrial process (such as waste heat recovery and waste recycling). If it belongs to a reasonable cycle, it is retained and the cycle boundary is marked; otherwise, it is recorded in the anomaly log.

[0109] In the allocation process, the model building agent traverses the process nodes with multiple product outputs in the directed graph and determines the allocation method (such as quality allocation, economic allocation, or system expansion) according to the allocation rules specified in the PCR rule object. If the supplementary information required for allocation (such as the economic value ratio of each output product, physical attribute parameters, etc.) is missing in the existing structured inventory data, a request is sent to the coordination and management agent, which schedules the data cleaning agent or other relevant agents to supplement it. The allocation results are recorded in the model data object, including the allocation method, allocation coefficient, and source of allocation basis for each process.

[0110] In the flow association step, the model building agent assigns quantitative information to each edge in the directed graph. For upstream and downstream associations identified in the topology construction step, the number of output items corresponding to the upstream process and the number of input items corresponding to the downstream process are respectively associated with the two ends of the edge. If the sum of the upstream output quantities and the sum of the downstream input quantities of the same primary key are inconsistent, there may be losses, allocation, or data errors. The model building agent records the difference in the anomaly log and marks the difference ratio. In addition, for basic flow input items in all processes, they are identified as resource inputs directly from nature and marked; for basic flow output items in all processes, they are identified as emissions at the system boundary and marked; for intermediate flow output items in non-isolated nodes that are not associated with any downstream processes, they are identified as intermediate flows about to leave the system boundary and marked; for intermediate flow input items in non-isolated nodes that are not associated with any upstream processes, they are identified as external inputs from outside the system boundary and marked.

[0111] After completing the above steps, the model building agent summarizes and evaluates the anomaly log. If the anomaly log is empty or only contains records marked as reasonable cycle situations, the lifecycle model is written into the basic support layer in the form of a structured data object. This data object includes a set of nodes (each unit process and its attributes), a set of edges (inter-process relationships and flow information), a stage affiliation mapping, a basic flow input / output list, a system boundary output node list, an external input node list, etc., and the task status is marked as "successful," and completion information is fed back to the coordination and management agent. If there are unresolved anomalies in the anomaly log (such as the difference ratio exceeding a preset threshold, a process that cannot be classified into a stage, etc.), the model building agent encapsulates the anomaly list and the corresponding original data references into a feedback message and pushes it to the coordination and management agent. After receiving the message, the coordination and management agent prioritizes forwarding the issue to the data cleaning agent for further confirmation and supplementation; if the data cleaning agent still cannot resolve the anomaly, the coordination and management agent requests manual intervention, and the modeling task is retried after the anomaly data is corrected.

[0112] 4) Parameter matching agent

[0113] The parameter matching agent receives matching tasks through the workflow engine. This atomic task instruction includes the storage path for the lifecycle model output by the model building agent and the storage path for the parsing results output by the PCR parsing agent. The parameter matching agent first loads these two inputs from the basic support layer and extracts four types of data items to be matched from the lifecycle model: First, intermediate flow data items marked as external inputs, i.e., material or energy inputs from outside the system boundary; second, intermediate flow data items marked as leaving the system boundary, such as waste awaiting disposal or recyclable by-products for sale; third, data items marked as input / output basic flows, i.e., resources directly from nature or pollutants directly emitted into nature; and fourth, data items that require supplementation as direct emission factors based on the semantics of the data item name, such as fossil fuels and decomposable carbonates.

[0114] The parameter matching agent determines a unique search scope based on the database requirements in the PCR rule object and the user configuration. Database selection follows this priority: when the PCR explicitly specifies a required database, that database is used as a hard filter, and searches are performed only within it; when the PCR does not specify a database but the user specifies one through the coordination and management agent, the user-specified database takes precedence; when neither the PCR nor the user specifies a database, the system default database is used. If the user-specified database conflicts with the PCR requirements, the PCR requirements take precedence, and the conflict and the actual database used are recorded in the matching report. This mechanism ensures that parameter matching is always performed within a single database, avoiding mixed computation across multiple databases.

[0115] After determining the search scope, the parameter matching agent performs matching on the four types of data items respectively. For intermediate flow data items that are external inputs, it retrieves the corresponding upstream production process dataset in the target database; for intermediate flow data items that are outside the system boundary, it retrieves the corresponding downstream processing process dataset in the target database; for input / output basic flow data items, it retrieves the corresponding basic flow factors in the target database; and for data items that need to be supplemented with direct emissions, it retrieves the corresponding emission factor dataset in the target database.

[0116] The matching process employs a multi-dimensional comprehensive scoring mechanism. The parameter matching agent retrieves candidate entries from the target database based on the information of the data item to be matched, and scores them from dimensions such as semantic similarity, unit consistency, regional applicability, and technical effectiveness. After weighting the total score for each dimension, the candidate entry with the highest score is taken as the matching result. When a candidate entry in the target database highly matches the data item to be matched, a mapping relationship is directly established. When no highly matching candidate entry can be retrieved but similar entries exist, the similar entry with the highest comprehensive score is selected as a proxy dataset to establish a mapping relationship, and the mapping is marked as a proxy match in the matching report, recording the reason for the proxy and a description of the differences from the ideal dataset. When no usable candidate entry can be retrieved at all in the target database, the data item is marked as a failed match and recorded in the exception log.

[0117] After matching all data items, the parameter matching agent generates a matching report. The matching report includes the matching results for all data items, the source database of the selected dataset, the matching type (exact match or surrogate match), detailed scores for each dimension, and explanatory information for surrogate matching, for user review and verification.

[0118] If the anomaly log is empty, the parameter matching agent writes all mapping relationships and matching reports into the basic support layer in the form of structured data objects, establishes an association index with the lifecycle model, marks the task status as "successful," and sends completion information back to the coordination and management agent. If there are failed matching data items in the anomaly log, the parameter matching agent encapsulates the list of anomalies and the completed matching results into a feedback message and pushes it to the coordination and management agent. The coordination and management agent then requests manual intervention. After the user provides supplementary information or manually specifies the dataset, the failed matching is re-executed. After the re-matching is completed, the parameter matching agent records the matching decision made by the manual intervention as a manual matching log, which includes information such as the original data item characteristics, the reason for the matching failure, the manually specified target dataset, and the specified reason. In subsequent matching tasks, when the parameter matching agent encounters data items with characteristics similar to existing experience records, it can directly perform matching based on historical decisions in the experience memory bank and mark the mapping as an experience match and the identifier of the referenced experience integration entry in the matching report, without needing to request manual confirmation again.

[0119] 5) Computational analysis of intelligent agents

[0120] The computational analysis agent receives computational tasks through the workflow engine. These atomic task instructions include the storage path for the lifecycle model output by the model-building agent, the storage path for the mapping relationships output by the parameter-matching agent, and the storage path for the parsing results output by the PCR (Computational Processing) parsing agent. The computational analysis agent first loads these three inputs from the basic support layer: the lifecycle model provides the topology and flow information of each unit process; the mapping relationships provide the correspondence between each data item and the dataset in the target database; and the PCR rule objects provide requirements such as environmental impact assessment methods, uncertainty analysis, and sensitivity analysis.

[0121] The core tasks of computational analysis agents are divided into five steps: LCI (Life Cycle Inventory) calculation, LCIA (Environmental Impact Index) calculation, uncertainty analysis, sensitivity analysis, and conclusion generation.

[0122] In the LCI calculation step, the analytical agent constructs a technical coefficient matrix based on the topology and flow information of the lifecycle model, calculates the total consumption coefficient based on the functional unit of the final product, and combines the basic flow lists of each dataset in the mapping relationship to obtain the LCI result for each functional unit. The above calculation process can also be implemented by other equivalent methods such as process-by-process expansion and iterative accumulation, and the specific implementation method is not limited to matrix operations.

[0123] In the LCIA calculation step, the computational analysis agent multiplies each basic flow in the LCI results by the corresponding characteristic factor under the impact assessment method, and summarizes the characteristic results for each impact category. When the impact assessment method is specified in PCR, the calculation is performed using that method as a mandatory option; when the user specifies other impact assessment methods, the calculation results of multiple methods are executed simultaneously and output. The results for each impact category are statistically analyzed by life cycle stage and unit process to support subsequent contribution analysis.

[0124] In the uncertainty analysis step, the computational analysis agent performs the analysis according to the PCR rule object or the uncertainty analysis method specified by the user. If there is no explicit requirement, the Monte Carlo simulation method is used by default, and multiple iterations are performed based on the uncertainty distribution of each input parameter to obtain the confidence interval and probability distribution characteristics of the results for each influence category.

[0125] In the sensitivity analysis step, the computational analysis agent performs the analysis based on the PCR rule object or the perturbation object and perturbation magnitude specified by the user. If there are no explicit requirements, by default, all hot data items identified during the LCA calculation process (data items that contribute more than 10% to a certain LCI or LCIA result) are subjected to a perturbation of ±1%, and the change magnitude of the corresponding calculation results is observed to evaluate the sensitivity of each parameter to the final result.

[0126] In the conclusion generation step, the computational analysis agent performs a comprehensive analysis based on the above calculation results to generate a summary conclusion. The conclusion includes: results of the core environmental impact indicators of the target product, a list of hot-button stages / processes / data items, uncertainty analysis conclusions, sensitivity analysis conclusions, etc.

[0127] After completing all the above steps, the computational analysis agent writes the original matrix data (including the technical coefficient matrix, total consumption coefficient matrix, basic flow list matrix, and characteristic factor matrix, etc.), the sub-item results at each level, uncertainty and sensitivity analysis data, and summary analysis conclusions into the basic support layer in the form of structured data objects, and establishes an association index with the life cycle model and mapping relationship. The task status is marked as "successful," and completion information is fed back to the coordination and management agent, including the storage path of the calculation results and a summary of key conclusions. If an anomaly occurs during the calculation process (such as a singular matrix that cannot be solved), the anomaly information is encapsulated as a feedback message and pushed to the coordination and management agent for coordination and handling or manual intervention.

[0128] 6) Report generation agent

[0129] The report generation agent receives report tasks through the workflow engine. This atomic task instruction includes the storage paths for the parsing results output by the PCR parsing agent, the processing logs output by the data cleaning agent, the lifecycle model output by the model building agent, the matching report output by the parameter matching agent, and the calculation results output by the computational analysis agent. The report generation agent first loads the above inputs from the basic support layer, and simultaneously reads the requirements for report content and format from the PCR rule object.

[0130] The core tasks of the report generation agent are divided into five steps: structure planning, content assembly, chart generation, document rendering, and quality verification.

[0131] In the structural planning step, the report generation agent parses the necessary report content specified in the PCR rule object according to the report requirements (such as research objectives and scope, functional unit description, system boundary description, data source description, allocation method description, environmental impact assessment results, uncertainty analysis, sensitivity analysis, data quality assessment, etc.), and plans the chapter structure and arrangement order of the document accordingly.

[0132] In the content assembly step, the report generation agent extracts corresponding content from each input data and organizes it into report text according to the planned chapter structure. For example: it extracts information such as research objectives, functional unit definitions, system boundary descriptions, and impact assessment methods from the PCR rule objects, serving as the content foundation for the preceding chapters of the report; it extracts data source descriptions and special processing records (such as data completion, unit conversion, and outlier correction) from the processing logs of the data cleaning agent; it extracts specific descriptions of system boundaries, process flow relationships, allocation methods, and allocation coefficients from the model data objects of the model building agent; it extracts background data selection instructions and proxy matching status from the matching report of the parameter matching agent; and it extracts characteristic results for each impact category, contribution breakdowns for each stage and process, uncertainty analysis conclusions, and sensitivity analysis conclusions from the calculation results of the calculation and analysis agent. For the content of each chapter, the report generation agent transforms the structured data into natural language expressions that conform to the report context, ensuring the readability and professionalism of the report.

[0133] In the chart generation step, the report generation agent automatically generates visual charts based on the report content. Chart types include, but are not limited to: lifecycle flowcharts, stage contribution percentage charts for each impact category, contribution ranking charts for hot processes, sensitivity analysis result charts, and uncertainty analysis result charts. The generated charts are embedded into the corresponding chapters of the document.

[0134] In the document rendering step, the report generation agent renders the assembled chapter text and charts into a human-readable document format. The output format is selected as PDF or Word document based on user preference or PCR requirements. During rendering, the document is formatted, including setting headers and footers, generating a table of contents, numbering and cross-referencing figures and tables, formatting tables, and controlling page breaks, to ensure that the output document conforms to the formatting standards of professional reports.

[0135] In the quality verification step, the report generation agent performs a completeness check on the generated report, verifying item by item whether all the report content required by the PCR rule object has been reflected in the document. Items that have been covered are marked as "completed"; for items that were not covered due to insufficient input data, the reason for the missing items is noted in the report with a placeholder explanation and recorded in the anomaly log.

[0136] After completing the above steps, if the exception log is empty, the report generation agent will write the final document file to the basic support layer, establish an association index with the accounting results and lifecycle model, mark the task status as "successful," and send completion information, including the storage path of the report file and the report summary, to the coordination and management agent. If there are any missing necessary items in the exception log, the report generation agent will send the list of exceptions and the currently generated report to the coordination and management agent, which will then coordinate the supplementation of data or request manual intervention. After the data is supplemented, the report will be updated accordingly.

[0137] Next, S400-S600 are executed. The specialized experience memory module located in the basic support layer responds to the execution process of the business intelligence agent and extracts domain knowledge from the task logs stored in the data storage module to form experience rules.

[0138] The empirical rules are fused and validated with the LCA basic knowledge base, and the validated empirical rules are stored as experience integration entries in the specialized experience memory module for the coordination and management agent to retrieve and call upon as needed; and

[0139] The coordinating and management agent dynamically adjusts the scheduling intent of subsequent tasks based on the retrieved experience integration entries.

[0140] In this embodiment, the basic support layer serves as the data foundation of the entire system. Its regular functions consist of four modules: data access, data storage, interface services, and operation and maintenance monitoring. Together, they provide stable infrastructure support for the core scheduling layer and the business execution layer. The data access module is responsible for handling external dynamic input data during system operation, including user-submitted feedback, uploaded files, and data pushed by third-party systems. After format conversion and protocol adaptation using standardized data adapters, the data is uniformly introduced into the data storage module. The data storage module is responsible for handling various types of data. It adopts a hierarchical storage architecture to manage raw data, feature data, log data, and LCA basic knowledge in a hierarchical manner. It also introduces a vector database to encode and store task semantic information and retains data change history through a version management mechanism, providing reliable data asset support for upper-layer modules. The interface service module provides unified RESTful API and RPC interfaces internally, allowing the core scheduling layer and the business execution layer to call the underlying data assets. Externally, it achieves data interoperability with external databases, ERP systems, and supply chain management platforms through standardized interface encapsulation, and uniformly manages interface authentication, call rate limiting, and log recording. The operation and maintenance monitoring module collects and alerts on the health status and performance indicators of components at each layer of the system in real time. At the same time, it records and audits the task execution logs of each business intelligence agent with the help of full-link tracing technology. Its monitoring data can also be fed back to the core scheduling layer to assist in the dynamic adjustment of task scheduling strategies.

[0141] In addition to the aforementioned standard functions, the system's foundational support layer also includes a specialized experience memory module. When performing product LCA (Limited Accounting) calculation tasks, this specialized experience memory module has the ability to continuously accumulate domain knowledge from historical task execution logs, forming specialized experience memories. This memory data supports the system's autonomous optimization and intelligent evolution, continuously improving the reliability and consistency of results. The specialized experience memory module is mainly composed of five core parts connected in series: log collection and structuring, experience extraction, knowledge fusion, specialized experience storage, and experience retrieval and injection. Please refer to... Figure 2 The specific technical solutions for each part are detailed below.

[0142] The essence of log collection and structuring is to transform the semi-structured task logs stored in the business execution layer into structured experience carriers carrying semantic information. The structured experience carriers include at least LCA semantic context and structured execution records; providing a data foundation for subsequent experience extraction and integration, which can be further divided into two steps: collection and structuring.

[0143] The data collection step mainly involves filtering the log data in the data storage module according to information type, allowing data with higher value to proceed to the subsequent structured processing steps. One possible hierarchical release strategy is shown in Table 2 below:

[0144] Table 2

[0145]

[0146] Structured processing refers to transforming the aforementioned high-value logs into LogEvent Objects (LEOs) with a unified data structure. These typically include fields such as a unique task identifier (ID), timestamp, LCA task type, event type (decision handling / anomaly handling / human intervention, etc.), LCA semantic context, event content, event result (success / failure), and quality signals.

[0147] The "LCA semantic context" in the log event object is mainly used to describe the key retrieval features of the current log record. In addition to the common product category, system boundary, life cycle stage, and geographical area information, it may also contain different extended fields depending on the LCA task type. For example, the parameter matching task log will additionally contain database version information.

[0148] The "event content" in the log event object is the event processing record formed after the original log content has been structured and extracted. The structured extraction refers to the original log first being split into formatted fragments and free text fragments using regular expressions. The formatted fragments are quickly mapped using a preset rule template. The mapping result and the free text fragments are input into an LLM (Large Language Model), and after parsing, a complete structured execution record is output. It is important to note that the exact matching result obtained based on the preset rule template has higher priority than the content obtained through LLM inference. If a rule-based mapping result already exists for the same field, the parsing result from the LLM path is discarded by default.

[0149] Experience extraction is the core of the entire system, primarily responsible for transforming structured log events into reusable experiential knowledge. This includes single-task experience extraction and cross-task pattern mining. Single-task experience extraction is a necessary preliminary step for subsequent data accumulation. Specifically, upon completion of each LCA task (regardless of success), the LLM immediately performs an in-task experience summary on all log event objects for that task, generating a structured Task Experience Summary (TES), which is then stored in a candidate pool and marked as pending mining. The prompts driving the generation of the Task Experience Summary typically consist of role definitions, input descriptions, extraction tasks, output format descriptions, and precautions. Role definitions define the professional domain of the current task; input descriptions list the original basis for experience extraction, such as task metadata and log event object sequences; extraction tasks describe the standardized execution framework, such as requiring the LLM to extract task profiles, non-standard processing records, decision patterns, and task quality assessments from all input data; output format descriptions standardize the structure of the Task Experience Summary, such as defining the output format and providing a structural example; and precautions highlight common pitfalls. The prompt word templates are stored in the basic support layer, decoupled from the task data, and can be maintained and versioned independently according to the actual situation.

[0150] During the system cold start phase, when the number of task experience summaries accumulated in the candidate pool reaches a preset threshold, a cross-task pattern mining operation based on the full candidate pool data is automatically triggered. This process summarizes the common patterns from multiple task experiences into experience rules (ER) with stronger generalization ability. Cross-task pattern mining can employ a hybrid strategy of vector clustering and LLM inductive reasoning. The specific steps include:

[0151] ① Using a text embedding model fine-tuned with LCA corpus, the key fields in the task experience summary are encoded into 768-dimensional numerical vectors. The field combinations used for encoding focus on information such as "what problem was encountered, what decision was made under what conditions, how it was handled, and what the basis for the handling was".

[0152] ② Compress all task experience summary vectors that have been encoded into low-dimensional vectors using PCA (Principal Component Analysis) or UMAP (Uniform Manifold Approximation and Projection).

[0153] ③ Input all the dimensionality-reduced vectors into the HDBSCAN clustering algorithm, and divide them into multiple clusters and isolated points according to spatial distance. Vector clusters with similar features enter the next step, while isolated points are returned to the candidate pool for temporary storage.

[0154] ④ For each cluster of vectors with similar characteristics, extract the core fields from all original task experience summaries within the vector cluster, assemble them, and input them into LLM for inductive reasoning. The task is to summarize the common patterns exhibited by the current vector cluster, summarize the applicable scenario boundaries, and output the empirical rules for a specific cluster.

[0155] Before the rules of thumb are formally written into the experience memory, they must be validated through knowledge fusion with the LCA (Learning Principles of Capabilities) base knowledge base. This can be accomplished using knowledge graph alignment and confidence propagation. The steps are as follows:

[0156] ① After concatenating the core fields of the empirical rule to be verified (such as applicable scenarios, common processing modes, recommended execution schemes, etc.) into a unified text, it is encoded into a semantic vector through a text embedding model;

[0157] ② Perform nearest neighbor search on the above semantic vectors in the LCA basic knowledge base with a display graph structure, and obtain the top-K knowledge base nodes with the highest cosine similarity (K is set to 5 by default, and nodes with similarity less than 0.5 are not included) as the initial hit set;

[0158] ③ Expand the initial hit node outward along the relation edges. Strong relation edges (constraints, allowances, priorities, etc.) are expanded two layers, weak relation edges (references, categories, sources, etc.) are expanded one layer, and informational relation edges (examples, historical versions, etc.) are not expanded. All the expanded nodes are used as the set of verification nodes.

[0159] ④ Input the content of each verification node and the semantic vector obtained by encoding the empirical rule to be verified into the LLM for semantic comparison, and output the judgment conclusion of consistency, contradiction or neutrality.

[0160] ⑤ Based on the semantic comparison results, confidence is propagated. The initial confidence of the Consolidated Experience Entry (CEE) generated from the current empirical rule to be verified can be calculated using the following formula:

[0161]

[0162] in, It is the initial confidence level of the experience integration items; It is the basic confidence level of the empirical rule to be verified; The verification node represents the point at which the judgment conclusion is consistent; The verification point represents the conclusion that a contradiction has been reached; The confidence weight represents node i; Let be the cosine similarity between node i and the empirical rule to be verified; The coverage correction factor is determined according to the following rules:

[0163]

[0164] Where x represents the coverage of the verification node, which can be calculated according to... Calculate, where N is the total number of verification nodes.

[0165] ⑥ When the initial confidence score is higher than the write threshold When the default value is 0.75, the rule of thumb is considered to have passed the verification, an experience integration entry is generated and written to the experience memory for persistent storage, and the mining status of the experience summaries of all source tasks involved in the rule of thumb is updated to "mined"; when the initial confidence level is lower than the review threshold... When the default value is 0.5, it is considered that the LCA basic knowledge base cannot verify the rationality of the current empirical rule or that there is a contradiction. The empirical rule is directly discarded, and the mining status of all task experience summaries related to the empirical rule is rolled back to pending mining and returned to the candidate pool to wait for the next mining. When the initial confidence result is between the writing threshold, and review threshold In between, an experience integration entry is generated and its status is edited to pending review, and it is then entered into the manual review queue.

[0166] The experience integration entries generated through the above steps are stored in an experience memory in a structured form, typically including a unique identifier (ID), status identifier, title / summary, scope of application, experience type, injection type, core experience record, source tracing, and quality evaluation matrix. Specifically, the scope of application may include fields such as a list of applicable product categories, applicable lifecycle stages, applicable task types, and triggering conditions; the core experience record may include fields such as task scenario, processing solution, reference basis (related knowledge base entry ID), and exception description; the source tracing may include fields such as source type (full mining / split / recombination), a list of source task experience summaries, a list of source tasks, creation time, and last update time; and the quality evaluation matrix may include fields such as confidence level, number of adoptions, number of non-adoptions, adoption rate, average quality of task results after adoption, last adoption time, and time-depletion factor.

[0167] After the system cold start is completed and it enters the continuous operation phase, the new task experience summary generated in the single-task experience extraction step is automatically added to the incremental update path. The new task experience summary is vectorized and compared with the existing experience integration item vector library for similarity. Different processing strategies are selected based on the relationship between the similarity result and a preset judgment threshold, as detailed below:

[0168] When the similarity is not lower than the first threshold, it indicates that the new task experience summary is highly similar to the existing experience integration entries. Therefore, a strategy to strengthen the existing experience integration entries should be adopted, that is, the ID of the new task experience summary is directly added to the "Source Task Experience Summary List" field of the original experience integration entry, and the "Mining Status" of the task experience summary is marked as mined.

[0169] When the similarity is between the second threshold (inclusive) and the first threshold, with the first threshold being greater than the second threshold, it indicates that there are both commonalities and differences between the new task experience summary and the existing experience integration entries. In this case, LLM is needed to help determine whether the new task experience summary supplements the application scenarios of the original experience integration entries or adopts different processing methods under similar application scenarios. For the former, the "applicable scope" of the original experience integration entries can be directly expanded, and the confidence value is updated after performing local knowledge fusion verification on the newly added part. For the latter, the original experience integration entries need to be split into two new experience integration entries with different "processing schemes", and knowledge fusion verification is performed on each based on the LCA basic knowledge base. A "split source traceability" field is added to the original experience integration entries to record the ID information of the split experience integration entries to support source traceability. Finally, the "status identifier" of the original experience integration entries is updated to archived and archived. After the expansion or split is completed, the mining status of the task experience summary is marked as mined.

[0170] It is important to note that when the similarity between a new task experience summary and multiple existing experience integration entries falls between the second threshold (inclusive) and the first threshold, it indicates that the task experience summary is at the intersection of multiple existing experience integration entries. In this case, a reorganization process needs to be triggered. The LLM redefines the scenario boundaries between these experience integration entries and the new task experience summary, generating multiple new experience rules to be verified. After each experience rule to be verified completes the verification process based on the LCA knowledge base, a new experience integration entry is generated. A "reorganization record" field is added to the original experience integration entry, recording the ID information of the new task experience summary that triggered the reorganization, the ID information of other experience integration entries that participated in the reorganization, the triggering reason, the reorganization time, and the ID information of the reorganized new experience integration entry, etc., supporting traceability. Finally, the "status identifier" of the original experience integration entry is updated to "archived" and archived.

[0171] When the similarity is below the second threshold, it indicates that the new task experience summary and the existing experience integration entries do not have enough commonality, and a single task experience summary cannot be generalized into a general rule. The new task experience summary can be temporarily stored in the candidate pool and its "mining status" is marked as pending mining. When a new experience integration entry is written to the experience memory, the existing task experience summaries temporarily stored in the candidate pool are actively scanned in reverse, and task experience summaries with similarity not lower than the second threshold are included in the incremental update path.

[0172] Besides the experience memory update triggered by adding new task experience summaries, node updates in the basic LCA knowledge graph may also trigger experience integration entry updates. By identifying the "reference basis" field in the experience integration entries, all experience integration entries strongly related to the updated node are precisely filtered out. A consistency judgment is then made between the updated knowledge node content and the existing content of the experience integration entry: if the judgment conclusion remains unchanged, only the confidence level of the experience integration entry needs to be updated according to the new node weight; if the judgment conclusion changes from consistent to contradictory, a "reason for deprecation" field is added to the corresponding experience integration entry, recording the conflicting knowledge base node ID and deprecation timestamp, and its "status identifier" is updated to deprecated; if the judgment conclusion changes from contradictory to consistent, the automatic verification process is re-triggered, and after passing the verification, its "status identifier" is updated to valid.

[0173] Experience retrieval and injection serve as a crucial bridge for experience memory to participate in task decision-making. Memory retrieval occurs before key decision nodes in the task execution process, with the coordinating and managing agent constructing retrieval conditions and initiating query requests. Retrieval conditions typically include task features, such as the structured context of the current task and the natural language description of the current decision point, which are jointly queried through a dual-track indexing mechanism of the experience memory bank. The dual-track indexing mechanism includes a structured index and a semantic vector index. The structured index track uses a relational database or document database to store the structured fields of the experience integration entries, supporting multi-dimensional filtering queries. The semantic vector index track uses a vector database to store dense vectors formed by triggering conditions and task context encoding in the experience integration entries, supporting nearest-neighbor semantic retrieval. Following the steps of first using structured fields for coarse screening and then using semantic vectors for fine screening, the top-N results are selected as candidate experience integration entries. For experience integration items with a regularity type (i.e., regular experience integration items), their "core experience record" field needs to be formatted into natural language and input into the LLM of the relevant intelligent body in the business execution layer along with the task instruction information issued by the workflow engine, so as to realize context enhancement based on the system's internal experience memory; for experience integration items with an operational type (i.e., operational experience integration items), they can be transformed into structured parameters that can be directly consumed by the business intelligent body in the execution layer, and embedded with atomic task instructions, which are issued by the workflow engine to the corresponding business intelligent body to achieve precise constraints on the parameter selection range.

[0174] To achieve effective attribution and quality feedback of experience memory, a structured traceability chain output specification needs to be embedded in the LLM system prompts at the execution layer. Each business agent is required to automatically output the adoption status and decision basis (including reasons for adoption and reasons for rejection) of all recalled experience integration items during the execution process after completing the task, and push this information to the basic support layer. After receiving the above information, the experience memory module updates the quality evaluation matrix of all relevant experience integration items according to the following rules: For experience integration items that were recalled but not adopted, the "Number of times not adopted" and "Adoption rate" fields should be updated according to the actual situation, and the "Scope of application" of the current experience integration item should be updated based on the rejection reasons output by the business execution layer to avoid being mistakenly recalled in subsequent tasks; For adopted experience integration items, the "Number of adoptions", "Adoption rate", "Average quality of task results after adoption" and "Last adoption time" fields should be updated according to the actual situation. When the result score of the task output after adopting the experience integration item is greater than the preset threshold, the "Time-decrease factor" is reset to 1.0. When the result score of the output is less than the preset threshold, it indicates that adopting the current experience integration item may lead to the deterioration of the task result. The "Status identifier" of the experience integration item needs to be updated to pending review, and a manual review should be requested from the basic support layer.

[0175] Based on the same inventive concept, this invention also proposes a hierarchically decoupled multi-agent LCA accounting system, comprising:

[0176] The core scheduling layer, comprising a coordination and management agent and a workflow engine, is configured to continuously monitor and acquire global system status information from the foundational support layer, generating structured scheduling intentions. These intentions include at least task objectives, execution progress, historical experience reuse strategies, and task dependency constraints. The workflow engine, acting as a mandatory intermediary, is configured to parse scheduling intentions into atomic task execution sequences and distribute them to various business agents located in the business execution layer. The workflow engine constitutes the sole source for business agents to receive atomic task instructions.

[0177] The business execution layer includes multiple business agents with single responsibilities. Each business agent is configured to execute the corresponding business only in response to received atomic task instructions and feed back the execution status information to the coordination and management agent.

[0178] The basic support layer includes a specialized experience memory module and a data storage module. The data storage module is configured to store task logs and LCA basic knowledge bases produced by the business execution layer. The specialized experience memory module is configured to, in response to the execution process of the business intelligence agent, extract domain knowledge from the task logs stored in the data storage module to form experience rules; and to perform knowledge fusion verification between the experience rules and the LCA basic knowledge base, and store the verified experience rules as experience integration entries for the coordination and management intelligence agent to retrieve and call on demand.

[0179] The coordinating and management agent is also configured to dynamically adjust the scheduling intent of subsequent tasks based on retrieved experience integration entries.

[0180] The various parts of the multi-agent LCA accounting system have been discussed in detail above and will not be repeated here. Since the hierarchical decoupled multi-agent LCA accounting system provided by this invention belongs to the same inventive concept as the hierarchical decoupled multi-agent LCA accounting method described above, the hierarchical decoupled multi-agent LCA accounting system provided by this invention possesses all the advantages of the hierarchical decoupled multi-agent LCA accounting method described above. Therefore, the beneficial effects of the hierarchical decoupled multi-agent LCA accounting system provided by this invention will not be elaborated upon here.

[0181] Based on the same inventive concept, this invention also proposes a readable storage medium on which a computer program is stored, which, when executed, can realize the hierarchical decoupled multi-agent LCA accounting method as described above.

[0182] A readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device, such as, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer programs described herein can be downloaded from the readable storage medium to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. Networks can include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. Each computing / processing device's network adapter card or network interface receives and forwards a computer program from the network for storage on a readable storage medium within the respective computing / processing device. The computer program used to perform the operations of this invention can be execution instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as "C" or similar languages. The computer program can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing state information from a computer program. These electronic circuits can execute computer-readable program instructions, thereby realizing various aspects of the present invention.

[0183] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, systems, and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by a computer program. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. These computer programs can also be stored in a readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the readable storage medium storing the computer program comprises an article of manufacture including instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams.

[0184] A computer program may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the computer program executing on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0185] Since the readable storage medium provided by this invention belongs to the same inventive concept as the hierarchical decoupled multi-agent LCA accounting method described above, the readable storage medium provided by this invention has all the advantages of the hierarchical decoupled multi-agent LCA accounting method described above. Therefore, the beneficial effects of the readable storage medium provided by this invention will not be described in detail here.

[0186] In summary, this invention provides a layered and decoupled multi-agent LCA accounting method, system, and readable storage medium. It constructs a layered and decoupled architecture of "core scheduling layer + business execution layer + basic support layer," introducing a workflow engine as a mandatory intermediary to achieve physical isolation between decision flow and business flow, avoiding multi-source instruction conflicts and state inconsistencies, and significantly improving system stability. The coordination and management agent, as the globally unique decision-maker, dynamically orchestrates the process based on historical trajectories and knowledge base accumulation, overcoming the limitations of single-agent coupling and chaotic multi-agent communication, effectively simplifying the accounting process. Through the decoupling design of control and business logic, the system can quickly respond to changes in LCA standards, adapting to new requirements simply by adjusting the orchestration logic or replacing the business agent, significantly reducing maintenance costs. Crucially, the specialized experience memory module uses a public LCA knowledge base as the "gold standard," achieving system self-evolution through a closed-loop mechanism of "accumulation-verification-reuse-feedback." This reduces the cost of repeated trial and error while ensuring output consistency and reliability, providing an efficient and stable intelligent solution for LCA accounting in complex scenarios.

[0187] The above description is merely a description of preferred embodiments of the present invention and is not intended to limit the scope of the invention in any way. Any changes or modifications made by those skilled in the art based on the above disclosure are within the protection scope of the present invention. Obviously, those skilled in the art can make various modifications and variations to the present invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the present invention and its equivalents, the present invention also intends to include these modifications and variations.

Claims

1. A layered and decoupled multi-agent LCA accounting method, applied to a three-layer architecture including a core scheduling layer, a business execution layer, and a basic support layer, characterized in that, include: The coordination and management agent located in the core scheduling layer continuously monitors and obtains the global system status information in the basic support layer, and generates a structured scheduling intention. The scheduling intention includes at least the task objective, execution progress, historical experience reuse strategy and task dependency constraints. The workflow engine, located in the core scheduling layer, acts as a mandatory intermediary to parse the scheduling intent into an atomic task execution sequence and distribute it to each business agent located in the business execution layer; wherein, the workflow engine constitutes the sole source for the business agents to receive atomic task instructions; Each business intelligence agent only responds to the received atomic task instructions to execute the corresponding business, feeds back the execution status information to the coordination and management intelligence agent, and writes the task log of the execution output into the data storage module of the basic support layer; The specialized experience memory module located in the basic support layer responds to the execution process of the business intelligence agent, and extracts domain knowledge from the task logs stored in the data storage module to form experience rules; The empirical rules are fused and verified with the LCA basic knowledge base, and the verified empirical rules are stored as experience integration entries in the specialized experience memory module, which can be retrieved and called as needed by the coordination and management agent according to the task characteristics. The coordination and management agent dynamically adjusts the scheduling intent of subsequent tasks based on the retrieved experience integration entries.

2. The hierarchical decoupled multi-agent LCA accounting method according to claim 1, characterized in that, The process by which the workflow engine parses the scheduling intent includes: Read the task dependency constraints in the scheduling intent and construct a directed acyclic graph representing the current computation task dependencies; Read the execution progress in the scheduling intention, remove the completed nodes and their associated edges from the directed acyclic graph, and use the remaining edges and nodes as the basis for scheduling the next task. For an atomic task that has defined preconditions in the task dependency constraints, the start instruction of the atomic task is triggered only when all the preconditions in the execution progress are in a successful state. Atomic tasks that do not have the preceding task are placed into the ready queue. They are prioritized based on the system resource usage status, the cumulative waiting time of subsequent dependent tasks, and the expected resource usage of the tasks to be executed, and the instantiation and distribution of atomic tasks are completed dynamically.

3. The hierarchical decoupled multi-agent LCA accounting method according to claim 1, characterized in that, The method further includes: The coordination and management agent receives task execution events through a subscription-push mechanism and updates the historical experience reuse strategy in the scheduling intent based on the results pushed by the basic support layer. When it is determined that the original historical experience reuse strategy is not suitable for the current task, the original historical experience reuse strategy and the reference experience integration entries are adjusted to generate an updated scheduling intent carrying a new intent ID and synchronize it to the workflow engine. The workflow engine then dynamically orchestrates the pending tasks that have not yet started based on the updated data and distributes new atomic task instructions. The coordination and management agent manages the task lifecycle by monitoring the execution progress in the scheduling intent. When the overall status field in the execution progress is updated from in progress to any final state value such as successful, manually approved, terminated, or canceled, the resources occupied by this round of scheduling are released.

4. The hierarchical decoupled multi-agent LCA accounting method according to claim 1, characterized in that, The steps of the specialized experience memory module in accumulating domain knowledge and forming the experience rules include: Log collection and structuring transforms the semi-structured task logs written by the business execution layer into a structured experience carrier carrying semantic information. The structured experience carrier includes at least an LCA semantic context and structured execution records. Experience extraction generates task experience summaries for individual tasks, and when the candidate pool composed of these task experience summaries accumulates to a threshold, a hybrid strategy of vector clustering and inductive reasoning using a large language model is used to mine common patterns across tasks and generate experience rules.

5. The hierarchical decoupled multi-agent LCA accounting method according to claim 4, characterized in that, The knowledge fusion verification step specifically includes: The core fields of the empirical rules are concatenated into a unified text and encoded into a semantic vector; The semantic vector is used to perform nearest neighbor retrieval in the LCA basic knowledge base with an explicit graph structure. The top K knowledge base nodes with the highest similarity are obtained as the initial hit set, and the set of verification nodes is obtained by expanding outward along the relation edges. The content of each verification node is input into the large language model with the semantic vector for semantic comparison, and the judgment conclusion of consistency, contradiction or neutrality is output. The confidence level of the empirical rule is calculated based on the judgment conclusion. When the confidence level is higher than the write threshold, it passes the verification. When it is between the write threshold and the review threshold, it enters the manual review queue. When it is lower than the review threshold, it is discarded, and all task experience summaries related to the empirical rule are triggered to flow back to the candidate pool.

6. The hierarchical decoupled multi-agent LCA accounting method according to claim 4, characterized in that, The method further includes: During continuous operation, incremental update paths are executed on newly generated task experience summaries: Calculate the similarity between the newly generated task experience summary and the existing experience integration entries; When the similarity is not lower than the first threshold, the identifier of the newly generated task experience summary is added to the source identifier field of the existing experience integration entry; When the similarity is between the second threshold and the first threshold, the large language model determines whether to extend the applicable conditions of the existing experience integration items or split them into multiple experience integration items according to different recommendation methods. When the similarity is lower than the second threshold, the newly generated task experience summary is temporarily stored in the candidate pool, and when a new experience integration entry is created in the future, a reverse scan of the existing task experience summaries in the candidate pool is triggered.

7. The hierarchical decoupled multi-agent LCA accounting method according to claim 1, characterized in that, Before dynamically adjusting the scheduling intent of subsequent tasks based on the experience integration entries, the method further includes: Before key decision-making nodes in the task execution process, the coordination and management agent constructs retrieval conditions and initiates query requests; A hybrid query is performed using a dual-track indexing mechanism consisting of structured indexes and semantic vector indexes, and the top N results are taken as candidate experience integration entries. For regular experience integration items, their content is formatted into natural language and input into the reasoning model within the business intelligence body along with the atomic task instructions to achieve context enhancement; for operational experience integration items, they are converted into structured parameters and embedded into the atomic task instructions to constrain the execution scope.

8. The hierarchical decoupled multi-agent LCA accounting method according to claim 1, characterized in that, The method further includes: Each business intelligence agent is required to output the adoption status and decision basis of the recalled experience integration items during this execution after completing the task, and push it to the basic support layer; For experience integration entries that were recalled but not adopted, update their rejection count and adoption rate fields, and narrow their scope of application based on the reasons for rejection; For adopted experience integration entries, update their adoption count, adoption rate, and most recently used time fields; The task outputs generated after adopting all experience integration items are scored. When the score is lower than the preset threshold, the status of the experience integration items used in the task is updated to pending review, and a manual review is requested.

9. A hierarchical decoupled multi-agent LCA accounting system, characterized in that, The architecture comprises a three-layer structure: a core scheduling layer, a business execution layer, and a basic support layer. The core scheduling layer includes a coordination and management agent and a workflow engine. The core scheduling layer is configured to continuously monitor and acquire global system state information from the basic support layer, and generate structured scheduling intentions. These scheduling intentions include at least task objectives, execution progress, historical experience reuse strategies, and task dependency constraints. The workflow engine, acting as a mandatory intermediary, is configured to parse the scheduling intentions into atomic task execution sequences and distribute them to each business agent located in the business execution layer. The workflow engine constitutes the sole source for the business agents to receive atomic task instructions. The business execution layer includes multiple business intelligent agents with single responsibilities. Each business intelligent agent is configured to execute the corresponding business only in response to the received atomic task instructions and feed back the execution status information to the coordination and management intelligent agent. The basic support layer includes a specialized experience memory module and a data storage module. The data storage module is configured to store task logs and LCA basic knowledge bases produced by the business execution layer. The specialized experience memory module is configured to, in response to the execution process of the business agent, extract domain knowledge from the task logs stored in the data storage module to form experience rules; and to perform knowledge fusion verification between the experience rules and the LCA basic knowledge base, and store the verified experience rules as experience integration entries in the specialized experience memory module for the coordination and management agent to call on demand. The coordination and management agent is also configured to dynamically adjust the scheduling intent of subsequent tasks based on retrieved experience integration entries.

10. A readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed, it can implement the hierarchical decoupled multi-agent LCA accounting method according to any one of claims 1-8.

Images