An agent-based permission automation processing method and device
By using an agent-based approach, permission requests are structured into micro-tasks and parsed and planned using a Large Language Model (LLM). This solves the problem of efficient parsing and configuration of non-standard permission request forms, and achieves high-accuracy and traceable enterprise-level permission management.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 中电建新能源集团股份有限公司
- Filing Date
- 2025-12-30
- Publication Date
- 2026-05-29
AI Technical Summary
Existing technologies cannot efficiently parse and configure enterprise-level permissions when processing non-standard permission request forms, resulting in parsing errors, low efficiency, and security risks. Furthermore, existing intelligent agent systems have failed to effectively apply task decomposition and optimization.
An agent-based approach is adopted to structure permission requests into micro-tasks through perception and preprocessing, and to parse and plan them using a large language model (LLM). Combined with persistent queue management, the task flow is ensured to guarantee accuracy and traceability.
It reduces the permission processing cycle from days to hours, achieves a parsing accuracy of 99%, eliminates configuration errors, has dynamic exception handling capabilities, and supports intelligent reasoning and decision-making for complex business rules.
Smart Images

Figure CN122113151A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of robotic process automation, artificial intelligence, and large language model applications, and particularly to a method and apparatus for automated permission processing based on intelligent agents. Background Technology
[0002] In recent years, Robotic Process Automation (RPA) technology has been widely used in enterprise operations, but its execution capabilities are highly dependent on structured and standardized input data. When faced with non-standardized permission request forms (such as PDFs, scanned copies, or free-format Excel files), traditional RPA systems cannot parse them directly, still requiring manual review and data cleaning, leading to process breaks and inefficiency. To overcome this deficiency, the industry has begun to explore using Large Language Models (LLMs) as the "intelligent hub," leveraging their natural language understanding capabilities to generate automated instructions that work in conjunction with RPA executors, initially forming a "perception-decision-execution" link.
[0003] However, in high-risk scenarios such as access control, direct table parsing by LLM is prone to creating illusions of fact—such as fabricating user roles, mismatching resource permissions, or omitting key fields—seriously threatening system security. Although some solutions attempt to introduce document intelligence models (such as LayoutLM) to assist in table recognition, existing methods are mostly limited to single-page table processing and are not deeply coupled with LLM decision-making logic, making it difficult to meet the requirements of high accuracy and robustness for enterprise-level access control configuration.
[0004] Furthermore, permission-related tables typically involve large amounts of data, complex fields, and tight semantic relationships, making end-to-end processing by a single model prone to errors due to context overload. Although task decomposition has been shown to improve the reliability of complex reasoning, existing intelligent agent systems have not yet effectively applied it to the entire process of table parsing and permission mapping, and still lack systematic optimization for high-precision business scenarios.
[0005] In summary, current technologies have shortcomings in areas such as end-to-end automation loop, suppression of table illusion, and high-precision task decomposition. Summary of the Invention
[0006] To address the problems existing in the prior art, this disclosure provides an automated permission processing method and system for enterprise business systems based on intelligent agents. It integrates high-precision multi-page table structuring, LLM intelligent decision-making, and RPA automatic execution, and ensures accurate end-to-end intelligent permission configuration through a task splitting mechanism, thereby achieving an end-to-end closed loop.
[0007] The agent-based automated permission processing method disclosed herein mainly includes the following steps: S1, Perception and Preprocessing: Convert a permission adjustment request into an LLM-friendly format and cut it into structured micro-tasks, then push them into a persistent queue; S2, Structured Extraction: After micro-tasks are pushed into the persistent queue, they are parsed using a large model to extract key permission fields. The extracted data conforms to the predefined schema standard. S3, LLM planning: Based on extracted structured data, and according to business rules, a large model is used to generate an execution sequence plan for each micro-task; S4, Automated Execution and Result Feedback: Executes the planned steps and maps the operation results back to the original Excel cell coordinates to generate a visual execution report; All tasks are processed through a persistent queue.
[0008] Furthermore, step S1 specifically includes: S11, Excel file reception and preprocessing, creating content matrix and format matrix respectively; S12, Structural anchor point recognition and intelligent compression: Traverse the preprocessed matrix, mark anchor points, and extract cell content; S13, Anchor point neighborhood extraction: Expand around the set anchor point to extract core business data; S14, establish a bidirectional mapping between the original space and the compressed space, and reconstruct the compressed content matrix and the compressed format matrix based on the new coordinate system; S15, Traverse the compressed content matrix and construct an inverted index; S16 serializes two-dimensional tabular data into a text format that is easy for the Large Language Model (LLM) to understand, while preserving the structured features of the data; S17 divides the full data into micro-task fragments carrying complete metadata, preparing them for formatting in subsequent processing.
[0009] Furthermore, step S17 specifically includes: Integrity verification and cleaning: Receive the JSON data output from step S16, first verify the validity of ticket_id, parse the coordinate string of each cell, extract the row number and column index, filter out non-data rows, and count the total number of valid data rows; Metadata injection and lineage establishment: Add metadata to each piece of data, including work order number, data source type, processing timestamp, batch index, and total number of batches; The cleaned row data dictionary is divided into N small batches in sequence; Update the global data splitting statistics table to record the total number of rows and the total number of batches; The packaged batch data is pushed into a queue for persistent storage, and a query interface is provided to support the tracking of the processing status of any batch at any time by work order number.
[0010] Furthermore, in step S2, a persistent message queue is used to manage the extraction task, ensuring that data is not lost under high concurrency and system failure conditions, and LLM is used for accurate information extraction, including: Specifically, this includes: encapsulating the segmented batch data into messages, pushing them into the extraction queue, and immediately serializing and persistently writing the queue status to a disk file to prevent data loss due to memory overflow or power failure. Before reading from the queue, the worker acquires the file lock; Check if the "In Progress Queue" is empty, read the "Extract Queue", move the first batch to the "In Progress Queue", update the disk file, release the lock, and ensure that the same batch is not processed repeatedly in a multi-process environment; The worker loads batch data from memory, combines it with extracted prompts, and submits it to the LLM. After obtaining the LLM return result, validate the data format; If the format is incorrect, a retry mechanism will be triggered; if multiple failures occur, an error log will be logged. Once the verification is successful, the batch is removed from the in-process queue, the results are archived to the history, and output to the planning queue for the next stage; every change in the queue status is immediately persisted to disk. Furthermore, step S3 specifically includes: The worker listens to the planning queue, and when it detects a new extraction result, it locks the queue file and moves the task to the in-progress queue of the planning phase. Submit the extracted permission requirement data to the LLM, requesting the model to output a standardized list of plans containing specific actions; After LLM returns the planning results, it performs a strong correlation matching between the plan ID and the batch data ID to ensure that the planning instructions accurately correspond to the original data rows.
[0011] Furthermore, step S4 specifically includes: Start the executor, initialize the browser instance, and establish an employee account mapping dictionary for quick retrieval of employee records; Parse the plan data packet, reverse load the original data record from persistent storage based on the Data ID contained therein, and verify the validity of the record; Parse the plan data packet generated by LLM and use dictionary mapping to dynamically map the step names in the plan to specific processor functions; Collect the execution results of each step, and logically merge multiple operation results for the same data to avoid state overwriting; Based on the coordinate mapping relationship established in step S14, the execution result is written back to the corresponding cell in the original Excel file; Generate a CSV execution report containing complete status information and push it into the output result queue to complete the closed loop.
[0012] Furthermore, the persistent queue serves as a channel for transmitting task data, and its management method includes: State persistence: Every state of a task as it flows through the queue, such as "pending", "processing", "completed" or "failed", will be persistently stored. Operational atomicity and data consistency: Through the mutex lock mechanism, it is ensured that only one work unit can process the same task at any given time, avoiding data conflicts in concurrent scenarios; Fully traceable logs: Every access operation in the queue, including enqueueing and dequeueing, and every change in task status, is recorded in the log and strongly associated with the business work order number identifier, forming a complete data flow history and achieving full traceability.
[0013] An agent-based automated permission processing device applying the above method mainly includes: Preprocessing module: Converts a permission adjustment request into an LLM-friendly format and breaks it down into structured microtasks, which are then pushed into a persistent queue; LLM Information Extraction Module: After micro-tasks are pushed into the persistent queue, they are parsed using the large model to extract key permission fields. The extracted data conforms to the predefined schema standard. LLM planning module: Based on the extracted structured data and according to business rules, it uses a large model to generate an execution sequence plan for each micro-task; The automated execution and result feedback module executes the planned steps, maps the operation results back to the original Excel cell coordinates, and generates a visual execution report.
[0014] Compared with the prior art, the beneficial effects of this disclosure are: ① Improved efficiency: shortening the permission processing cycle from days to hours, realizing automated processing, and reducing the workload of business personnel; ② Improved accuracy: The accuracy of LLM parsing reaches over 99%, eliminating permission configuration errors caused by misreading information or manual input errors, and avoiding data leakage, business interruption or compliance risks; ③ Traceability: Provides extremely fine-grained operation records, fully covering all aspects such as application information, analysis, planning, and execution, and realizes complete recording of timestamps, parameters, and results, supporting internal control review and compliance management; ④ Intelligentization: Enables intelligent understanding and processing of non-standardized data, possesses dynamic anomaly handling and autonomous recovery capabilities, and supports intelligent reasoning and decision-making for complex business rules. Attached Figure Description
[0015] The above and other objects, features and advantages of this disclosure will become more apparent from the more detailed description of exemplary embodiments of this disclosure taken in conjunction with the accompanying drawings, in which the same reference numerals generally represent the same components.
[0016] Figure 1 This is a flowchart of an automated permission processing method for an enterprise business system based on intelligent agents, according to the present disclosure. Detailed Implementation
[0017] Preferred embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art.
[0018] This disclosure provides a method and apparatus for automated permission processing based on intelligent agents. The overall process is shown in the attached figure. Figure 1 As shown, the main steps include: Perception and preprocessing: Convert a permission adjustment request into an LLM-friendly format and cut it into structured microtasks, then push them into a persistent queue; Structured extraction: After microtasks are pushed into the persistent queue, they are parsed using a large model to extract key permission fields. The extracted data conforms to the predefined schema standard. LLM planning: Based on the extracted structured data, and according to business rules, a large model is used to generate an execution sequence plan for each micro-task; Automated execution and result feedback: Execute the planned steps and map the operation results back to the original Excel cell coordinates to generate a visual execution report; All tasks are processed through a persistent queue.
[0019] In one exemplary implementation: The complex permission processing task is deconstructed into four highly cohesive, loosely coupled specialized subsystems: a preprocessing subsystem, an LLM information extraction subsystem, an LLM planning subsystem, and an automated execution and result feedback subsystem. This architecture effectively separates functions at different levels, such as "perception and understanding," "analysis and decision-making," and "execution and feedback," thereby improving the system's controllability and scalability.
[0020] Perception and Preprocessing Stage (Preprocessing Subsystem): The system first reads complex-formatted table attachments using structural anchor point recognition technology, and then removes redundant noise using anchor point neighborhood extraction and coordinate remapping techniques to generate a high-density compression matrix. Subsequently, the DataSplitter algorithm splits the full data into micro-task fragments carrying complete metadata, preparing them for subsequent processing.
[0021] Structured Extraction Phase (LLM Information Extraction Subsystem): After microtasks are pushed into the persistent queue, this subsystem uses a large model to perform semantic analysis on the compressed text. It is not only responsible for extracting key permission fields from natural language, but also introduces a format validation mechanism to ensure that the extracted data conforms to predefined schema standards, achieving accurate "cognition" of business information.
[0022] Intelligent Planning Phase (LLM Planning Subsystem): Based on extracted structured data, this subsystem acts as the "decision-making brain." According to business rules, it uses a large model to generate specific execution sequence plans. Each plan is broken down into a series of executable atomic steps, clearly defining the operation objects and actions, thus solving the problem of automated orchestration of complex business logic.
[0023] Execution and Closed-Loop Feedback Phase (Automated Execution and Result Feedback Subsystem): The executor parses the planned steps and uses the Function Calling mechanism to drive the browser instance to perform headless operations. During execution, the subsystem uses inverted index technology to accurately map the operation results (success, failure, exception) back to the original Excel cell coordinates, generating a visual execution report, thus completing a full closed loop from input to output.
[0024] The system processes a permission adjustment request as follows: First, the preprocessing subsystem converts the data into an LLM-friendly format and cuts it into structured microtasks; Next, the LLM information extraction subsystem parses it and manages the task through a persistent queue; Then, the LLM planning subsystem generates an execution plan for each microtask and manages the tasks through a persistent queue; Finally, the automated execution subsystem precisely executes the plan and records and feeds back the results and process.
[0025] All tasks are processed through a persistent queue, ensuring the reliability and traceability of the process.
[0026] Each step is explained in further detail below: 1. Pretreatment Step 1: Receiving and Preprocessing Excel Files This step primarily addresses the issues of accessing and uniquely tracking complex file formats. The system establishes a monitoring mechanism to standardize and clean the input multi-source heterogeneous files, providing a clean data foundation for subsequent core processing.
[0027] Specific technical implementation: File monitoring and retrieval: The system initiates a monitoring process to scan the input_excel / directory in real time. Once a new attachment is detected, a unique tracking code is immediately generated using a file hash algorithm for subsequent end-to-end data tracing.
[0028] Loading and Initialization: The system calls the ExcelReceiver module to load the Excel file, creating a content matrix and a format matrix in memory. The content matrix stores the text data, and the format matrix stores visual information such as font and background color.
[0029] Noise cleaning: For merged cells commonly found in Excel, the system performs a split-fill operation to ensure that each logical cell has an independent value. Simultaneously, it iterates through all rows and automatically filters out meaningless blank rows, decorative rows, and duplicate header rows based on the row content's entropy or repetition rate, completing the initial data cleaning.
[0030] Step 2: Structural anchor point identification and intelligent compression (core of attachment parsing and conversion) To address the limitations of traditional parsing methods in handling complex headers and multi-level nested structures, this paper analyzes the table's topological structure to compress a large, sparse table into a high-density semantic table.
[0031] Specific technical implementation: Difference Calculation and Anchor Point Marking: The system traverses the preprocessed matrix and calculates the semantic difference between adjacent rows (Row_i and Row_i+1) and adjacent columns. When the difference exceeds a preset threshold or a specific format change is detected (such as bolding the font or changing the background color), the system marks that position as an anchor point.
[0032] Semantic formatting: While identifying anchor points, the system extracts the metadata of cells in parallel.
[0033] Number format extraction: Extracts the number format string.
[0034] Visual semantic mapping: Detect cell background color and convert it into semantic labels (e.g., map green background to {status: "SUCCESS"} and red background to {status: "FAIL"}), enabling large models to understand the meaning of colors.
[0035] Type detection: Infer the data type (e.g., String, Integer, Date) of each cell's content to improve data characteristics.
[0036] Step 3: Anchor point neighborhood extraction By using a neighborhood expansion algorithm, only local regions containing valid information are extracted, thus achieving preliminary dimensionality reduction for sparse large tables.
[0037] Specific technical implementation: Neighborhood scanning: Using each "structural anchor point" identified in step 2 as the center, expand the scan to the front, back, left and right directions to scan a preset number of rows and columns.
[0038] Boolean mask generation: Based on the scan results, the system constructs a Boolean mask matrix in memory with the same dimensions as the original table. Coordinates falling within the anchor point and its neighborhood are marked as True, while other irrelevant background areas are marked as False. This process removes a large number of blank or irrelevant decorative areas from the table, retaining only the core business data.
[0039] Step 4: Coordinate Remapping Since compression changes the physical location of the data, this step establishes a two-way mapping mechanism between the original space and the compressed space to ensure that the processing results can be accurately written back to the original file.
[0040] Specific technical implementation: Mapping matrix construction: The system scans the Boolean mask matrix and records the original coordinates of all retained cells. A bidirectional mapping table is then built from the original coordinates to the new coordinates.
[0041] Matrix reconstruction: Based on the new coordinate system, the compressed content matrix and the compressed format matrix are reconstructed.
[0042] Results saving: The compressed structured data and its mapping relationships are saved as intermediate files to provide input for subsequent steps.
[0043] Step 5: Inverted Index To quickly locate specific data within the original table during processing, the system has built an efficient index structure.
[0044] Specific technical implementation: Index Construction: Traverse the compressed content matrix and construct an inverted index. The key of the index is the specific content of the cell (such as employee name, permission name), and the value is a list of all coordinates of that content appearing in the original Excel.
[0045] Region merging: For consecutive occurrences of the same content (such as merged cells), the algorithm will automatically merge consecutive row or column addresses into a region representation, further optimizing the index size.
[0046] Step 6: Data Format Aware Aggregation This step aims to serialize two-dimensional tabular data into a text format that is easy for Large Language Models (LLMs) to understand, while preserving the structured features of the data.
[0047] Specific technical implementation: Role index reorganization: To facilitate permission queries, the system identifies columns containing personnel roles and moves them to the front index position of the check table.
[0048] JSON serialization: Converts each row in the compressed matrix into a JSON object, where the key represents the table header and the value represents the cell content and its status flag.
[0049] Step 7: Task Splitting (Data Cutting and Sharding Algorithm Innovation) To address the contextual limitations and system stability requirements of LLM processing of long texts, this step introduces the DataSplitter module to precisely split large-scale datasets into micro-batches.
[0050] Specific technical implementation: Integrity verification and cleaning: Upon receiving the output JSON data, first verify the validity of ticket_id. Parse the coordinate string of each cell, extract the row number and column index, filter out non-data rows (such as pure header or sample rows), and count the total number of valid data rows.
[0051] Metadata injection and lineage establishment: Add metadata to each piece of data, including work order number, data source type, processing timestamp, batch index, and total number of batches.
[0052] Sharding strategy: Divide the cleaned row data dictionary into N small batches in sequence.
[0053] Statistics: Update the global data segmentation statistics table to record the total number of rows and the total number of batches.
[0054] Persistent queuing: The packaged batch data is pushed into a queue for persistent storage, and a query interface is provided to support the tracking of the processing status of any batch at any time by work order number.
[0055] 2. LLM Information Extraction (Processing Based on Persistent Message Queues) Step 8: Use a persistent message queue (PersistentQueue) to manage retrieval tasks, ensuring that data is not lost in the event of high concurrency and system failure, and use LLM for accurate information retrieval.
[0056] Specific technical implementation: Enqueue operation: DataSplitter encapsulates the split batch data into messages and pushes them into the retrieval queue. The queue state is immediately serialized and persistently written to a disk file to prevent data loss due to memory overflow or power failure.
[0057] Mutex lock mechanism (core): Before a worker can read from the queue, it must first acquire the file lock.
[0058] Atomic operation: Check if the "In-Process Queue" is empty, read from the "Fetch Queue", move the first batch to the "In-Process Queue", update the disk file, and release the lock. This ensures that the same batch is not processed repeatedly in a multi-process environment.
[0059] Model interaction: The worker loads batch data from memory, combines it with extracted prompts, and submits it to the LLM.
[0060] Verification and Archiving: After obtaining the LLM return result, the system immediately verifies the data format.
[0061] Error handling: If the format is incorrect, trigger the retry mechanism; if multiple failures occur, log the error.
[0062] Confirmation upon successful verification: Once verified, the batch is removed from the in-progress queue, the results are archived to the history, and simultaneously output to the planning queue for the next stage. Every change in the queue status is immediately persisted to disk.
[0063] Step 9: Validate and post-process the content of the LLM output to make it usable data to pass on to the next relief.
[0064] Format Extraction: Receives the output of a large language model, filters the thought chain, and extracts JSON format data.
[0065] Structure parsing and validation: Parse JSON data and validate required fields to build structured objects containing employee information, organizational information, and role permissions.
[0066] Filtering and Status Analysis: Filter data based on field processing status, and count the number of part-time units, departments, and roles to be processed.
[0067] Transformation and Result Formatting: Parses Excel coordinates and transforms status indicators to generate user-readable formatted results and statistical reports.
[0068] Exception handling and system monitoring: Capture and record various exceptions during the processing, and update system status information.
[0069] 3. LLM planning tasks Based on the extracted permission information, a specific sequence of execution actions is generated using LLM, which also relies on a persistent queue to ensure the reliability of the process.
[0070] Specific technical implementation: Queue connection: The logic is the same as in step 7. The worker listens to the planned queue. When a new extraction result is detected, the queue file is locked and the task is transferred to the in-progress queue of the planning phase.
[0071] Planning and Reasoning: Submit the extracted permission requirement data to the LLM, requiring the model to output a standardized list of plans containing specific actions.
[0072] Plan matching: After LLM returns the planning results, the system performs a strong correlation matching between the plan ID and the batch data ID to ensure that the planning instructions accurately correspond to the original data rows.
[0073] 4. Perform operations according to the plan. By using actuators to transform text plans into actual system operations, automation is achieved in the "last mile."
[0074] Specific technical implementation: Execution environment initialization: Start the executor and initialize the browser instance. Establish an employee account mapping dictionary for quick retrieval of employee records.
[0075] Data loading and validation: Parse the plan data packet, reverse load the original data records from persistent storage based on the Data ID contained therein, and verify the validity of the records.
[0076] Dynamic function mapping: Parses the plan data package generated by LLM. Using dictionary mapping, it dynamically maps step names in the plan to specific processor functions.
[0077] State aggregation: Collect the execution results (success / failure / abnormality) of each step, and logically merge multiple operation results for the same data to avoid state overwriting.
[0078] Result write-back and feedback: Based on the coordinate mapping relationship established in step 4, the execution result (success marker or error message) is accurately written back to the corresponding cell in the original Excel file. A CSV execution report containing complete status information is generated and pushed into the output result queue, completing the closed loop.
[0079] The key point of the above method is: 1) Attachment preprocessing method to overcome the "table illusion" problem in LLM: The preprocessing subsystem receives raw, non-standardized Excel permission requests submitted by users. It employs an innovative attachment parsing and conversion technology (based on the engineering implementation and optimization of the Spreadsheet Language Model (LLM) theory) to accurately convert complex tables with varying formats into a standardized, structured data format that is easily understood and processed by the Large Language Model (LLM). This method ensures the accuracy of information input from the data source, laying a reliable foundation for all subsequent intelligent processing.
[0080] 2) Task dimensionality reduction and fragmentation methods: To address the scenario where a single application may contain numerous change items, this embodiment employs a self-developed data splitting and sharding algorithm (DataSplitter) during the information extraction phase. This algorithm intelligently divides a large permission adjustment task into multiple independent "micro-task" batches. This dimensionality reduction approach significantly reduces the complexity of a single LLM call, improves processing speed, and achieves more refined error isolation, ensuring that the failure of a single micro-task does not affect the continued execution of other tasks.
[0081] 3) Separate "cognition" from "decision": Two-stage LLM processing flow: Phase 1 (Information Extraction / Recognition): The LLM information extraction subsystem receives the preprocessed data. Leveraging LLM's powerful natural language understanding capabilities, it focuses on accurately identifying and extracting key information entities related to permission requests from the data, which are then processed to form structured data.
[0082] Phase Two (Planning / Decision-Making): The LLM planning subsystem receives the structured information output from the previous phase. It utilizes LLM's logical reasoning and planning capabilities, combined with pre-defined business rules, to generate a detailed, ordered, and directly executable operational plan for downstream systems.
[0083] 4) A traceable asynchronous communication method based on persistent queues: To achieve reliable communication and end-to-end traceability between subsystems, this embodiment designs and implements a persistent message queue (PersistentQueue). This queue not only serves as a channel for task data transmission, but its core mechanism lies in: State persistence: Every state of a task as it flows through the queue (such as "pending", "processing", "completed", "failed") is persistently stored (e.g., written to the file system). This ensures that even if the system is unexpectedly interrupted or restarted, it can be accurately restored to the state before the interruption, without any task or data loss.
[0084] Operational atomicity and data consistency: Through mechanisms such as file locks, it is ensured that only one work unit can process the same task at any given time, effectively avoiding data conflicts in concurrent scenarios.
[0085] Fully traceable logs: Every access operation (enqueue, dequeue) and every change in task status is recorded in detail and strongly associated with identifiers such as business work order numbers. This constitutes a complete, highly granular data flow history that can be audited by internal controls, achieving true full traceability.
[0086] Application Examples Intelligent processing of complex Excel permission request forms Step 1: Excel File Reception and Preprocessing. Users upload complex Excel files containing employee permission application information to the system's input_excel / directory. These Excel files contain multiple worksheets with complex formats, including merged cells, various font formats, and background colors. The system automatically monitors the directory using the ExcelReceiver module, identifies the file, and generates a unique ticket_id tracking code.
[0087] Step 2: Structural anchor point identification and intelligent compression The system calls the core algorithm in the sheet_compressor module, uses structural anchor point recognition technology to analyze the structure of the table file, and identifies heterogeneous rows and columns as structural anchor points.
[0088] Identifying heterogeneous lines: based on content and format differences; Check for differences in content between adjacent rows; Check for formatting differences (font, background color, borders); If the difference exceeds the threshold, it is considered a structural anchor point.
[0089] Step 3: Anchor point neighborhood extraction The system uses anchor point neighborhood extraction technology to preserve anchor points and expands outwards by a preset number of rows and columns centered on the anchor points. Create a Boolean matrix and mark the cells that need to be retained; Mark the area around the row anchor point.
[0090] Step 4: Coordinate Remapping The system uses coordinate remapping technology to remap and preserve the coordinates of the cells, creating a compressed spreadsheet: Create a mapping between rows and columns; Create the compressed matrix; Fill the compressed matrix.
[0091] Step 5: Inverted Index Technology The system constructs an inverted index to facilitate fast searching and locating, including: Create an inverted index dictionary; Iterate through all non-empty cells; Skip empty cells; Add cell addresses to the list of corresponding content.
[0092] Step 6: Data Format Aware Aggregation The system uses data format-aware aggregation technology to identify different types of data and perform intelligent aggregation. Year detection; Integer detection; Floating-point number detection; Date detection.
[0093] Step 7: Task Splitting Technique The system uses the `DataSplitter` class to split the compressed data into small batches for easier subsequent processing; Step 8: LLM Information Extraction The system uses LLM technology to extract permission information and verify results based on input prompts and LLM-friendly data, and manages the extraction tasks using a persistent message queue (PersistentQueue). Step 9: Output Processing Verify the output of the previous step to see if it meets the standard, and then perform post-processing to enable subsequent steps to recognize the data; Step 10: LLM Planning Task The system uses LLM technology to intelligently plan and adjust tasks based on permissions, verify the plan, and also relies on persistent queues to ensure the reliability of the process. A browser initialization tool used to create a browser instance and log in to the system; Part-time organization adjustment tool, used to handle employees' part-time organization adjustments; Use Function Calling to generate an execution plan; Generate prompt words; Invoking the LLM uses Function Calling; Call the API to initiate the first round of dialogue; Enable parallel tool calls; Lowering the temperature to increase certainty; Check if any tools are being called; Fallback to JSON format output; Processing tool call; Convert the data into a serializable list; Step 11: Perform the operation according to the plan. The system uses Function Calling technology to execute the plan: Implement the specific plan; Create a mapping between employee accounts and records for later identification; Iterate through each step in the execution plan.
[0094] The above technical solutions are merely exemplary embodiments of the present invention. For those skilled in the art, based on the application methods and principles disclosed in the present invention, it is easy to make various types of improvements or modifications, and not limited to the methods described in the specific embodiments of the present invention. Therefore, the methods described above are merely preferred and not restrictive.
Claims
1. A method for automated permission processing based on intelligent agents, characterized in that, Includes the following steps: S1, Perception and Preprocessing: Convert a permission adjustment request into an LLM-friendly format and cut it into structured micro-tasks, then push them into a persistent queue; S2, Structured Extraction: After micro-tasks are pushed into the persistent queue, they are parsed using a large model to extract key permission fields. The extracted data conforms to the predefined schema standard. S3, LLM planning: Based on extracted structured data, and according to business rules, a large model is used to generate an execution sequence plan for each micro-task; S4, Automated Execution and Result Feedback: Executes the planned steps and maps the operation results back to the original Excel cell coordinates to generate a visual execution report; All tasks are processed through a persistent queue.
2. The method according to claim 1, characterized in that, Step S1 specifically includes: S11, Excel file reception and preprocessing, creating content matrix and format matrix respectively; S12, Structural anchor point recognition and intelligent compression: Traverse the preprocessed matrix, mark anchor points, and extract cell content; S13, Anchor point neighborhood extraction: Expand around the set anchor point to extract core business data; S14, establish a bidirectional mapping between the original space and the compressed space, and reconstruct the compressed content matrix and the compressed format matrix based on the new coordinate system; S15, Traverse the compressed content matrix and construct an inverted index; S16 serializes two-dimensional tabular data into a text format that is easy for the Large Language Model (LLM) to understand, while preserving the structured features of the data; S17 divides the full data into micro-task fragments carrying complete metadata, preparing them for formatting in subsequent processing.
3. The method according to claim 2, characterized in that, Step S17 specifically includes: Integrity verification and cleaning: Receive the JSON data output from step S16, first verify the validity of ticket_id, parse the coordinate string of each cell, extract the row number and column index, filter out non-data rows, and count the total number of valid data rows; Metadata injection and lineage establishment: Add metadata to each piece of data, including work order number, data source type, processing timestamp, batch index, and total number of batches; The cleaned row data dictionary is divided into N small batches in sequence; Update the global data splitting statistics table to record the total number of rows and the total number of batches; The packaged batch data is pushed into a queue for persistent storage, and a query interface is provided to support the tracking of the processing status of any batch at any time by work order number.
4. The method according to claim 2, characterized in that, In step S2, a persistent message queue is used to manage the extraction task, ensuring that data is not lost under high concurrency and system failure conditions, and LLM is used for accurate information extraction, including: Specifically, this includes: encapsulating the segmented batch data into messages, pushing them into the extraction queue, and immediately serializing and persistently writing the queue status to a disk file to prevent data loss due to memory overflow or power failure. Before reading from the queue, the worker acquires the file lock; Check if the "In Progress Queue" is empty, read the "Extract Queue", move the first batch to the "In Progress Queue", update the disk file, release the lock, and ensure that the same batch is not processed repeatedly in a multi-process environment; The worker loads batch data from memory, combines it with extracted prompts, and submits it to the LLM. After obtaining the LLM return result, validate the data format; If the format is incorrect, a retry mechanism will be triggered; if multiple failures occur, an error log will be logged. Once the verification is successful, the batch is removed from the in-process queue, the results are archived to the history, and output to the planning queue for the next stage; every change in the queue status is immediately persisted to disk.
5. The method according to claim 2, characterized in that, Step S3 specifically includes: The worker listens to the planning queue, and when it detects a new extraction result, it locks the queue file and moves the task to the in-progress queue of the planning phase. Submit the extracted permission requirement data to the LLM, requesting the model to output a standardized list of plans containing specific actions; After LLM returns the planning results, it performs a strong correlation matching between the plan ID and the batch data ID to ensure that the planning instructions accurately correspond to the original data rows.
6. The method according to claim 2, characterized in that, Step S4 specifically includes: Start the executor, initialize the browser instance, and establish an employee account mapping dictionary for quick retrieval of employee records; Parse the plan data packet, reverse load the original data record from persistent storage based on the Data ID contained therein, and verify the validity of the record; Parse the plan data packet generated by LLM and use dictionary mapping to dynamically map the step names in the plan to specific processor functions; Collect the execution results of each step, and logically merge multiple operation results for the same data to avoid state overwriting; Based on the coordinate mapping relationship established in step S14, the execution result is written back to the corresponding cell in the original Excel file; Generate a CSV execution report containing complete status information and push it into the output result queue to complete the closed loop.
7. The method according to any one of claims 1-6, characterized in that, The persistent queue serves as a channel for transmitting task data, and its management methods include: State persistence: Every state of a task as it flows through the queue, such as "pending", "processing", "completed" or "failed", will be persistently stored. Operational atomicity and data consistency: Through the mutex lock mechanism, it is ensured that only one work unit can process the same task at any given time, avoiding data conflicts in concurrent scenarios; Fully traceable logs: Every access operation in the queue, including enqueueing and dequeueing, and every change in task status, is recorded in the log and strongly associated with the business work order number identifier, forming a complete data flow history and achieving full traceability.
8. A smart agent-based automated permission processing apparatus applying the method of any one of claims 1-7, characterized in that, include: Preprocessing module: Converts a permission adjustment request into an LLM-friendly format and breaks it down into structured microtasks, which are then pushed into a persistent queue; LLM Information Extraction Module: After micro-tasks are pushed into the persistent queue, they are parsed using the large model to extract key permission fields. The extracted data conforms to the predefined schema standard. LLM planning module: Based on the extracted structured data and according to business rules, it uses a large model to generate an execution sequence plan for each micro-task; The automated execution and result feedback module executes the planned steps, maps the operation results back to the original Excel cell coordinates, and generates a visual execution report.