Enterprise intelligent collaborative office system based on large model

Abstract

The application discloses an enterprise intelligent collaborative office system based on a large model, which comprises the following modules: an action pressing-in module, which is used for pressing-in candidate office actions to form an initial evolution branch and an evolution landing point; a source switching and trial module, which is used for switching and connecting an event source to form a replacement evolution branch; a virtual connection deduction module, which is used for screening out virtual connection candidate office actions; a reverse sequence back-rolling module, which is used for positioning a non-continuous closed position; a breakpoint turn-back module, which is used for supplementing a closed action; a closed solidification module, which is used for generating a collaborative task chain; and a feedback and continuation module, which is used for generating a continuation collaborative task chain. The application relates to the technical field of enterprise intelligent collaborative office and realizes reliable generation and dynamic continuation of a collaborative task chain, thereby improving office collaborative accuracy and execution efficiency.

Description

Technical Field

[0001] This invention relates to the field of intelligent collaborative office technology for enterprises, and in particular to an intelligent collaborative office system for enterprises based on a large model. Background Technology

[0002] Existing enterprise collaborative office systems mostly adopt a unified portal, workflow engine, role-based access control, and business module integration approach to streamline tasks in human resources, system management, training management, performance management, and administrative approvals. Some systems introduce large-scale models to analyze office events, generating candidate tasks, responsible parties, and processing sequences; some dynamic graph processing solutions use graph neural networks to describe the temporal changes between personnel, positions, permissions, and tasks, and update model parameters based on changes in the graph structure.

[0003] In existing solutions, candidate office actions generated by large models often directly enter the process in the order of generation, lacking trial runs and reverse verification to check the validity of the event source. If similar office events in the same company act on the same office object at similar times, candidate office actions are likely to reach the same processing position along fixed relationships, resulting in duplicate or spurious tasks. When EvolveGCN evolves parameters in chronological order, parameter overlaps, breakpoints, and erroneous connections between candidate office actions are difficult to identify locally. When the actual execution result deviates from the model's evolution result, existing systems often regenerate the complete task flow. Completed tasks are easily processed repeatedly, and incomplete tasks are difficult to continue evolving from the most recent valid position, affecting the accuracy and continuity of the collaborative task chain.

[0004] Therefore, how to provide an intelligent collaborative office system for enterprises based on a large model is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] One objective of this invention is to propose an intelligent collaborative office system for enterprises based on a large model. This invention utilizes a large model and EvolveGCN to generate collaborative task chains through source switching, virtual connection deduction, reverse rollback, breakpoint rewind, and feedback continuation. It has the advantages of accurate task identification, fewer repetitive tasks, stable abnormal continuation, and high collaborative efficiency.

[0006] An intelligent collaborative office system for enterprises based on a large model, according to an embodiment of the present invention, includes: The action push module is used to push the candidate office actions generated by the large model into the EvolveGCN evolution rounds according to the event source, forming the initial evolution branches and evolution landing points; The source-switching simulation module is used to switch the event source to a similar enterprise office event that does not affect the office object corresponding to the candidate office action, and form a replacement evolution branch along the parameter evolution order of the initial evolution branch; The virtual connection deduction module is used to compare the initial evolutionary branch with the replacement evolutionary branch and deduct candidate office actions that still reach the same evolutionary point as the initial evolutionary branch. The reverse rollback module is used to reverse rollback from the evolution landing point corresponding to the retained candidate office actions to the event source according to the parameters, mark the first non-continuous closure position, and retain the candidate office actions that are continuously closed. The breakpoint rewind module is used to rewind from the first non-continuously closed position to the previous continuously closed position, insert candidate office actions to complete the closure conditions, and repeat the candidate office actions after the previous continuously closed position; The closed-loop solidification module is used to solidify the EvolveGCN parameter updates corresponding to the candidate office actions that are closed consecutively after the replay, and to generate collaborative task chains in the order of consecutive closures. The feedback continuation module is used to lock the completed collaborative tasks in the collaborative task chain, determine the actual landing point according to the actual execution result, and deduct the unfinished collaborative tasks after the corresponding evolution landing point when the actual landing point is inconsistent with the corresponding evolution landing point. It then continues the evolution from the last completed collaborative task to generate a continuation collaborative task chain.

[0007] Optionally, the action push-in module forms initial evolutionary branches and evolutionary landing points, specifically including: Push the candidate office actions corresponding to the same event source into the same EvolveGCN base parameters, and isolate the EvolveGCN parameter updates corresponding to each candidate office action; Set the evolution point of the last candidate office action as the tail placeholder, and extract the candidate office actions in reverse order of generation. Replay the previous candidate office action. Stop replaying when the previous candidate office action reaches the first parameter update position of the next candidate office action. Insert the parameter update corresponding to the previous candidate office action before the parameter update corresponding to the next candidate office action. Repeat the process of replaying and inserting until the first candidate office action is inserted. The initial evolutionary branch is formed according to the parameter evolution order after insertion, and the tail position is determined as the evolution landing point.

[0008] Optionally, the reenactment of the previous candidate office action specifically includes: The first parameter update is located by following the parameter evolution order corresponding to the next candidate office action, and the position corresponding to the first parameter update is determined as the first parameter update position. Replay the previous candidate office action. When the previous candidate office action reaches the first parameter update position, capture the parameter update formed before the previous candidate office action reaches the first parameter update position. When the current candidate office action reaches the first parameter update position and the parameter updates corresponding to the two candidate office actions do not overlap, the intercepted parameter update is inserted before the parameter update corresponding to the next candidate office action. When the first candidate office action reaches the first parameter update position and the parameter updates corresponding to the two candidate office actions overlap, the parameter update corresponding to the previous candidate office action is truncated from the overlapping position, and the parameter update truncated before the overlapping position is inserted before the parameter update corresponding to the next candidate office action. If the current candidate office action has not reached the first parameter update position, cancel the parameter update corresponding to the previous candidate office action and do not include the previous candidate office action in the initial evolution branch.

[0009] Optionally, the step of truncating the parameter update corresponding to the previous candidate office action from the overlapping position specifically includes: The parameter updates corresponding to the previous candidate office action and the parameter updates corresponding to the next candidate office action are located in the same EvolveGCN graph convolutional layer; Starting from the first parameter update position of the next candidate office action, we trace back along the parameter evolution order to determine the overlapping position where the two parameter updates first act on the same parameter position. Remove the parameter update formed from the overlapping position to the corresponding evolution point of the previous candidate office action; Preserve the parameter updates prior to the overlapping positions, and insert the preserved parameter updates before the parameter updates corresponding to the next candidate office action.

[0010] Optionally, the replacement evolution branch formed in the source-switching trial module specifically includes: Starting with the EvolveGCN basic parameters before the formation of the initial evolutionary branch, retain the parameter updates in the initial evolutionary branch except for the parameter updates corresponding to the event source, and release the parameter update positions corresponding to the event source; Select similar enterprise office events that do not affect the corresponding office objects of the candidate office actions, and transfer the event source to similar enterprise office events; Replay the candidate office actions along the parameter evolution order of the initial evolution branch, and write the parameter updates formed after the switch into the released parameter update positions one by one; If a candidate office action fails to generate a parameter update at the corresponding released parameter update position, the subsequent replay will be truncated. The parameter updates written before the truncation will be connected in the parameter evolution order to form a replacement evolution branch.

[0011] Optionally, the comparison between the initial evolutionary branch and the replacement evolutionary branch in the virtual connection deduction module specifically includes: Align the initial evolutionary branches and the replacement evolutionary branches according to the parameter evolution order, and find the first difference parameter update position of the two evolutionary branches in reverse from the same evolutionary landing point; The parameter update corresponding to the first differential parameter update position is temporarily removed from the initial evolutionary branch. The parameter update position preceding the first differential parameter update position is determined as the direct continuation position. If there is no preceding parameter update position, the starting position of the initial evolutionary branch is determined as the direct continuation position. If there is a subsequent parameter update, the subsequent parameter update is continuated to the direct continuation position. Replay the candidate office action corresponding to the first difference parameter update position from the directly continuation position; If the same evolutionary point is reached after the replay, the corresponding candidate office action is deducted; if the same evolutionary point is not reached, the temporarily removed parameter update is restored, and the corresponding candidate office action is retained.

[0012] Optionally, the first non-continuous closure position is marked in the reverse roll-back module, specifically including: Parameters are extracted and updated in reverse order from the evolution points corresponding to the retained candidate office actions; The current parameter update is withdrawn item by item. If the current parameter update has a previous parameter update position, the candidate office action corresponding to the current parameter update is replayed starting from the parameter state corresponding to the previous parameter update position. If the current parameter update does not have a previous parameter update position, the candidate office action corresponding to the current parameter update is replayed starting from the EvolveGCN basic parameters before the formation of the initial evolution branch. When the current parameter update position is reached after replay, the current parameter update is resumed, and the current parameter update position is marked as a continuous closed position; If the current parameter update position is not reached after the replay, the reverse extraction stops. The current parameter update position is marked as the first non-continuous closure position. Candidate office actions that are continuously closed between the first non-continuous closure position and the evolution landing point are retained.

[0013] Optionally, the breakpoint rewind module inserts candidate office actions to complete the closure condition, specifically including: If the first non-continuously closed position does not have a previous continuously closed position, the starting position of the initial evolutionary branch is determined as the previous continuously closed position; Lock the parameter update before the previous consecutive closed position, and disconnect the candidate office actions between the first non-consecutive closed position and the evolutionary landing point; From the evolution point, the candidate office actions between the first non-continuously closed position and the evolution point are withdrawn in reverse order of parameter evolution. The currently withdrawn candidate office action is moved forward to after the previous continuous closed position. The parameter state corresponding to the previous consecutive closed position is used to replay the current forward candidate office action. The reverse withdrawal stops when the current forward candidate office action reaches the first non-consecutive closed position. Retain the currently moved candidate office actions and replay the remaining candidate office actions according to the parameter evolution order before disconnection; If the current forward-moving candidate office action does not reach the first non-continuously closed position, the current forward movement is canceled, and the candidate office action that has not yet been tested is withdrawn in reverse. If all candidate office actions between the first non-continuous closure position and the evolution landing point have been performed and none of them have reached the first non-continuous closure position, then the candidate office actions before the disconnection are restored, and the first non-continuous closure position is retained.

[0014] Optionally, the closed-loop solidification module generates a collaborative task chain, specifically including: Extract candidate office actions that are continuously closed after replay and their corresponding EvolveGCN parameter updates from the evolution point along the parameter evolution order; Following the continuous closing sequence, the EvolveGCN parameters corresponding to the current candidate office action are updated and temporarily written into the EvolveGCN basic parameters, and the next candidate office action is replayed with the temporarily written EvolveGCN basic parameters. If there is a subsequent candidate office action, if the subsequent candidate office action reaches the corresponding evolution landing point, the EvolveGCN parameter update corresponding to the current candidate office action is retained; if it does not reach the corresponding evolution landing point, the EvolveGCN parameter update corresponding to the current candidate office action is cancelled, and the temporary writing of subsequent EvolveGCN parameter updates is stopped. If there is no subsequent candidate office action, the EvolveGCN parameter update corresponding to the current candidate office action is retained. The candidate office actions corresponding to the continuously retained EvolveGCN parameter updates are sequentially connected to form a collaborative task chain.

[0015] Optionally, the feedback continuation module generates a continuation collaborative task chain, specifically including: By reverse matching the actual execution results from the end of the collaborative task chain, the last completed collaborative task is located, the actual landing point corresponding to the last completed collaborative task is determined, and the last completed collaborative task is locked. When the actual landing point of the last completed collaborative task is inconsistent with the corresponding evolution landing point, the incomplete collaborative tasks after the last completed collaborative task are deducted, the EvolveGCN parameter updates corresponding to the incomplete collaborative tasks are canceled, the EvolveGCN basic parameters are rolled back to the parameter state after the last completed collaborative task is completed, and the evolution landing point corresponding to the last completed collaborative task is used as the starting point for the continuation of the process. The source switching test, virtual link deduction, reverse rollback and breakpoint rewind are re-executed, and the candidate office actions that are continuously closed after the continuation of the process are connected to the last completed collaborative task to form a continuation collaborative task chain.

[0016] The beneficial effects of this invention are: (1) This invention replaces the event source of the candidate office action with the same type of enterprise office event that does not act on the current office object by changing the source trial and deducting the virtual connection. By comparing the evolution landing point before and after the replacement, the candidate office action that still maintains the same evolution result after deviating from the real event source can be deducted. It can identify false tasks formed by fixed organizational relationship or historical co-occurrence relationship, and reduce duplicate approval, erroneous push and invalid cross-module call.

[0017] (2) This invention uses reverse rollback and breakpoint rewind to withdraw parameter updates from the evolution landing point, locate the first non-continuous closed position, and move the subsequent candidate office actions forward for trial, only replaying the task segment after the breakpoint; when personnel, positions, and permissions change, the office tasks that have been continuously closed are not regenerated, and the unfinished tasks can continue from the most recent closed position, reducing the repeated execution and state coverage caused by the overall reconstruction of the process.

[0018] (3) This invention uses EvolveGCN parameter update isolation, reverse insertion, and closed-loop solidification to temporarily write the parameter updates corresponding to candidate office actions into the EvolveGCN basic parameters, and then uses the next candidate office action to verify the continuous succession of parameter updates, retaining only the parameter updates that can reach the evolution landing point. The model parameters are updated by actual closable collaborative relationships, which can suppress the cumulative interference of invalid candidate actions on the evolution of subsequent tasks and improve the stability of the collaborative task chain under continuous business events. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a module structure diagram of an intelligent collaborative office system for enterprises based on a large model, as proposed in this invention. Figure 2 This is a flowchart of the action input, source switching simulation, and virtual connection deduction proposed in this invention; Figure 3 This is a flowchart of the reverse roll-back, breakpoint return, closure solidification and feedback continuation process proposed in this invention. Detailed Implementation

[0020] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0021] refer to Figures 1-3 A large-scale intelligent collaborative office system for enterprises includes: The action push module is used to push the candidate office actions generated by the large model into the EvolveGCN evolution rounds according to the event source, forming the initial evolution branches and evolution landing points; The source-switching simulation module is used to switch the event source to a similar enterprise office event that does not affect the office object corresponding to the candidate office action, and form a replacement evolution branch along the parameter evolution order of the initial evolution branch; The virtual connection deduction module is used to compare the initial evolutionary branch with the replacement evolutionary branch and deduct candidate office actions that still reach the same evolutionary point as the initial evolutionary branch. A virtual connection is a candidate office action whose event source is switched to a similar enterprise office event, and the candidate office action still reaches the same evolutionary endpoint as the initial evolutionary branch; a candidate office action that meets the above conditions is a virtual connection candidate office action. The reverse rollback module is used to reverse rollback from the evolution landing point corresponding to the retained candidate office actions to the event source according to the parameters, mark the first non-continuous closure position, and retain the candidate office actions that are continuously closed. When rolling back to the event source, the first parameter update formed by the event node input is extracted in reverse order of parameter evolution, and the event node corresponding to the first parameter update is determined as the event source; The breakpoint rewind module is used to rewind from the first non-continuously closed position to the previous continuously closed position, insert candidate office actions to complete the closure conditions, and repeat the candidate office actions after the previous continuously closed position; The closure condition is that the current candidate office action moves forward and then replays the parameter state corresponding to the previous consecutive closed position, reaching the first non-consecutive closed position; the current candidate office action that satisfies the closure condition is a candidate office action that completes the closure condition. The closed-loop solidification module is used to solidify the EvolveGCN parameter updates corresponding to the candidate office actions that are closed consecutively after the replay, and to generate collaborative task chains in the order of consecutive closures. When updating EvolveGCN parameters, if there is a subsequent candidate office action, the temporary result verified by replaying the subsequent candidate office action will be retained in the EvolveGCN basic parameters; if there is no subsequent candidate office action, the temporary result corresponding to the current candidate office action will be retained in the EvolveGCN basic parameters; the retained EvolveGCN parameter updates will not be revoked during the current collaborative task chain generation process. The feedback continuation module is used to lock the completed collaborative tasks in the collaborative task chain, determine the actual landing point according to the actual execution result, and deduct the unfinished collaborative tasks after the corresponding evolution landing point when the actual landing point is inconsistent with the corresponding evolution landing point. It then continues the evolution from the last completed collaborative task to generate a continuation collaborative task chain.

[0022] In this embodiment, the initial evolutionary branch and evolutionary landing point are formed in the action push-in module, specifically including: Push the candidate office actions corresponding to the same event source into the same EvolveGCN base parameters, and isolate the EvolveGCN parameter updates corresponding to each candidate office action; The EvolveGCN base parameters are model parameters saved before the start of the current evolution round, including the weights of each EvolveGCN graph convolutional layer, the weights of the recurrent neural network used to update the graph convolutional layer weights, and the biases. Each candidate office action evolves from the same EvolveGCN base parameters, and the resulting EvolveGCN parameter updates are saved separately. The EvolveGCN base parameters are not written before the parameter update is completed and inserted. In this embodiment, parameter updates without a specific name are all EvolveGCN parameter updates. In this embodiment, the EvolveGCN parameter updates are the graph convolutional layer weight updates formed within the current evolution round. The recurrent neural network weights and biases remain unchanged during the evolution, replay, insertion, cancellation, and solidification of candidate office actions. Candidate office actions are office processing actions to be executed generated by the big model based on enterprise office events; the big model reads the processing items, office objects and execution order in the enterprise office events, generates corresponding candidate office actions for each executable item, and records the enterprise office events that generate candidate office actions as event sources; The processing items are coded as event node features according to the category of office items, and the office objects are coded as office object node features according to the job category and permission category. The action type and execution order of the candidate office actions are coded as action edge features. The event node features, office object node features and action edge features are represented by fixed-dimensional vectors. If the dimension is insufficient, zeros are padded. The adjacency relationship of the current evolution round is constructed according to the connection relationship between event nodes, office object nodes and action edges. When pushing into an EvolveGCN evolution round, the event source is established as an event node, the office object is established as an office object node, and the candidate office actions are established as action edges connecting the event node and the office object node; the processing items are written into the action type field of the action edge, the execution order is written into the order field of the action edge, and the event node, office object node, and action edge are written into the graph structure corresponding to the current evolution round according to the generation order of the candidate office actions; An EvolveGCN evolution round is a parameter evolution process executed after a candidate office action corresponding to the same event source enters EvolveGCN; each time the system reads an enterprise office event, it establishes an EvolveGCN evolution round and processes the candidate office actions generated by the enterprise office event within the current EvolveGCN evolution round; Set the evolution point of the last candidate office action as the tail placeholder, and extract the candidate office actions in reverse order of generation. The evolution landing point is the position corresponding to the last parameter update of the candidate office action in the current EvolveGCN evolution round; the system records the convolutional layer number and the row and column position of the weight matrix of the EvolveGCN graph where the last parameter update is located, and determines the recorded position as the evolution landing point corresponding to the candidate office action; The tail position is the position corresponding to the last parameter update after the last candidate office action has completed its evolution; the system searches for the last parameter update according to the parameter evolution order of the last candidate office action, records the corresponding position, and forms the tail position. Replay the previous candidate office action. Stop replaying when the previous candidate office action reaches the first parameter update position of the next candidate office action. Insert the parameter update corresponding to the previous candidate office action before the parameter update corresponding to the next candidate office action. Replay involves restoring the parameter state to the replay starting point corresponding to the candidate office action, re-entering the same candidate office action, and executing parameter updates again according to the original parameter evolution order; the replay starting point uses the parameter state corresponding to the previous parameter update position; if there is no previous parameter update position, the EvolveGCN basic parameters before the formation of the initial evolution branch are used; When the previous candidate office action reaches the first parameter update position of the next candidate office action, it means that the last parameter update formed by the replay of the previous candidate office action and the first parameter update of the next candidate office action are located in the same EvolveGCN graph convolutional layer and act on the same row and column position in the graph convolutional layer weight matrix; when the above conditions are met, the replay stops and parameter update pre-insertion is performed. Repeat the process of replaying and inserting until the first candidate office action is inserted. The initial evolutionary branch is formed according to the parameter evolution order after insertion, and the tail position is determined as the evolution landing point.

[0023] The parameter evolution order is as follows: after the candidate office action enters the EvolveGCN evolution round, the parameters of each EvolveGCN are updated in the order of their formation. The system records the sequence number according to the formation time of the parameter update. When the formation time is the same, the order is determined according to the data transmission order of the EvolveGCN graph convolutional layer. When they are in the same EvolveGCN graph convolutional layer, the order is determined according to the row and column numbers of the weight matrix.

[0024] In this embodiment, repeating the previous candidate's office action specifically includes: The first parameter update is located by following the parameter evolution order corresponding to the next candidate office action, and the position corresponding to the first parameter update is determined as the first parameter update position. Replay the previous candidate office action. When the previous candidate office action reaches the first parameter update position, capture the parameter update formed before the previous candidate office action reaches the first parameter update position. When the current candidate office action reaches the first parameter update position and the parameter updates corresponding to the two candidate office actions do not overlap, the intercepted parameter update is inserted before the parameter update corresponding to the next candidate office action. When the first candidate office action reaches the first parameter update position and the parameter updates corresponding to the two candidate office actions overlap, the parameter update corresponding to the previous candidate office action is truncated from the overlapping position, and the parameter update truncated before the overlapping position is inserted before the parameter update corresponding to the next candidate office action. If the current candidate office action has not reached the first parameter update position, cancel the parameter update corresponding to the previous candidate office action and do not include the previous candidate office action in the initial evolution branch.

[0025] When canceling parameter updates, delete the parameter updates generated by the previous candidate office action in this replay, and restore the parameter status to the replay starting point used in this replay.

[0026] In this embodiment, the parameter update corresponding to the previous candidate office action is truncated from the overlapping position, specifically including: The parameter updates corresponding to the previous candidate office action and the parameter updates corresponding to the next candidate office action are located in the same EvolveGCN graph convolutional layer; The EvolveGCN graph convolutional layer is a network layer in EvolveGCN that aggregates information about connected nodes and updates node features. Each EvolveGCN graph convolutional layer is assigned a layer number according to the data transmission order, and each layer is configured with corresponding graph convolutional layer weights. This implementation adopts the EvolveGCN-H structure. After the event node, office object node, and action edge are written into the graph structure corresponding to the current evolution round, the graph convolutional layer aggregates node features and action edge features according to the node connection relationship to form the node state of the current evolution round. The recurrent neural network receives the node state of the current evolution round and the graph convolutional layer weights of the previous evolution round, and outputs the graph convolutional layer weights of the current evolution round. Starting from the first parameter update position of the next candidate office action, we trace back along the parameter evolution order to determine the overlapping position where the two parameter updates first act on the same parameter position. During the reverse lookup, starting from the first parameter update position of the next candidate office action, the parameter updates corresponding to the previous and next candidate office actions are read in reverse order of parameter evolution. The convolutional layer number and weight matrix row and column positions of the EvolveGCN graph are compared in turn, and the positions that match the first comparison are determined as the overlapping positions. Remove the parameter update formed from the overlapping position to the corresponding evolution point of the previous candidate office action; Preserve the parameter updates prior to the overlapping positions, and insert the preserved parameter updates before the parameter updates corresponding to the next candidate office action.

[0027] In this embodiment, the replacement evolution branch formed in the source replacement trial module specifically includes: Starting with the EvolveGCN basic parameters before the formation of the initial evolutionary branch, retain the parameter updates in the initial evolutionary branch except for the parameter updates corresponding to the event source, and release the parameter update positions corresponding to the event source; When forming the initial evolutionary branch, the parameter update generated by the event node input is marked as the parameter update corresponding to the event source, and the event source, the convolutional layer number of the EvolveGCN graph and the row and column positions of the weight matrix are recorded; when releasing the parameter update position corresponding to the event source, the parameter update content marked as the parameter update corresponding to the event source is deleted, and the convolutional layer number of the EvolveGCN graph and the row and column positions of the weight matrix are retained; Select similar enterprise office events that do not affect the corresponding office objects of the candidate office actions, and transfer the event source to similar enterprise office events; Similar enterprise office events are those with the same processing items, the same order of candidate office actions, and different office objects. The system compares the processing items, office objects, and order of candidate office actions in the office event records and selects enterprise office events that meet the above conditions. The enterprise office events used for comparison are read from the office event records saved on the enterprise collaborative office platform. The office event records include processing items, office objects, and order of candidate office actions. When the source of an event is changed, the source of the candidate office action record will be rewritten from the original enterprise office event to the selected similar enterprise office event; Replay the candidate office actions along the parameter evolution order of the initial evolution branch, and write the parameter updates formed after the switch into the released parameter update positions one by one; If a candidate office action fails to generate a parameter update at the corresponding released parameter update position, the subsequent replay will be truncated. The parameter updates written before the truncation will be connected in the parameter evolution order to form a replacement evolution branch.

[0028] In this embodiment, the comparison between the initial evolutionary branch and the replacement evolutionary branch in the virtual connection deduction module specifically includes: Align the initial evolutionary branches and the replacement evolutionary branches according to the parameter evolution order, and find the first difference parameter update position of the two evolutionary branches in reverse from the same evolutionary landing point; When aligning the initial evolutionary branch with the replacement evolutionary branch, the same evolutionary endpoint is used as the common endpoint. The parameter updates in the two evolutionary branches are read one by one in reverse order of parameter evolution. The convolutional layer number, row and column position of the weight matrix and parameter update content of the EvolveGCN graph are compared. The position where the first comparison is inconsistent is determined as the first difference parameter update position. When comparing parameter update content, calculate the absolute difference between the parameter update values ​​corresponding to the row and column positions of the same EvolveGCN graph convolutional layer and the same weight matrix; if the absolute difference is not greater than 0.000001, the parameter update content is determined to be consistent; if the absolute difference is greater than 0.000001, the parameter update content is determined to be inconsistent. The parameter update corresponding to the first differential parameter update position is temporarily removed from the initial evolutionary branch. The parameter update position preceding the first differential parameter update position is determined as the direct continuation position. If there is no preceding parameter update position, the starting position of the initial evolutionary branch is determined as the direct continuation position. If there is a subsequent parameter update, the subsequent parameter update is continuated to the direct continuation position. When temporarily removing a parameter update, save the parameter update corresponding to the first differential parameter update position and delete the corresponding parameter update from the initial evolutionary branch; Replay the candidate office action corresponding to the first difference parameter update position from the directly continuation position; If the same evolutionary point is reached after the replay, the corresponding candidate office action is deducted; if the same evolutionary point is not reached, the temporarily removed parameter update is restored, and the corresponding candidate office action is retained.

[0029] When deducting the corresponding candidate office action, remove the corresponding candidate office action and the corresponding EvolveGCN parameter update from the initial evolution branch.

[0030] In this embodiment, marking the first non-continuously closed position in the reverse roll-back module specifically includes: Parameters are extracted and updated in reverse order from the evolution points corresponding to the retained candidate office actions; The current parameter update is withdrawn item by item. If the current parameter update has a previous parameter update position, the candidate office action corresponding to the current parameter update is replayed starting from the parameter state corresponding to the previous parameter update position. If the current parameter update does not have a previous parameter update position, the candidate office action corresponding to the current parameter update is replayed starting from the EvolveGCN basic parameters before the formation of the initial evolution branch. When withdrawing the current parameter update, save the current parameter update and delete the current parameter update from the initial evolution branch; When the parameter update generated by the replay is located in the same EvolveGCN graph convolutional layer as the current parameter update and acts on the same row and column position in the graph convolutional layer weight matrix, it is determined that the replay has reached the current parameter update position. When extracting in reverse order of parameter evolution, the position where the parameter update generated by the replay does not reach the current parameter update position is the first non-continuous closure position. When the current parameter update position is reached after replay, the current parameter update is resumed, and the current parameter update position is marked as a continuous closed position; If the current parameter update position is not reached after the replay, the reverse extraction stops. The current parameter update position is marked as the first non-continuous closure position. Candidate office actions that are continuously closed between the first non-continuous closure position and the evolution landing point are retained.

[0031] In this embodiment, the breakpoint rewind module inserts candidate office actions to complete the closure condition, specifically including: If the first non-continuously closed position does not have a previous continuously closed position, the starting position of the initial evolutionary branch is determined as the previous continuously closed position; Lock the parameter update before the previous consecutive closed position, and disconnect the candidate office actions between the first non-consecutive closed position and the evolutionary landing point; When updating parameters before locking the previous consecutive closed position, the parameter evolution order and parameter content of the corresponding parameter updates remain unchanged, and the locked parameter updates are not deleted or rewritten during the breakpoint rewind. When disconnecting the candidate office action between the first non-contiguous closed position and the evolution landing point, the original position, parameter evolution order, and parameter update of the corresponding candidate office action are saved. The connection between the previous continuous closed position and the first non-contiguous closed position is removed, and the original connection between the candidate office actions between the first non-contiguous closed position and the evolution landing point is retained. When canceling the current forward movement or restoring the candidate office action before disconnection, the corresponding connection is restored according to the saved original position and parameter evolution order. From the evolution point, the candidate office actions between the first non-continuously closed position and the evolution point are withdrawn in reverse order of parameter evolution. The currently withdrawn candidate office action is moved forward to after the previous continuous closed position. When reversing the withdrawal of candidate office actions, the connection between the candidate office actions and the original positions is removed in reverse order of parameter evolution, the parameter updates corresponding to the candidate office actions are saved, and the candidate office actions and parameter updates are not deleted. The parameter state corresponding to the previous consecutive closed position is used to replay the current forward candidate office action. The reverse withdrawal stops when the current forward candidate office action reaches the first non-consecutive closed position. Retain the currently moved candidate office actions and replay the remaining candidate office actions according to the parameter evolution order before disconnection; If the current forward-moving candidate office action does not reach the first non-continuously closed position, the current forward movement is canceled, and the candidate office action that has not yet been tested is withdrawn in reverse. If all candidate office actions between the first non-continuous closure position and the evolution landing point have been performed and none of them have reached the first non-continuous closure position, then the candidate office actions before the disconnection are restored, and the first non-continuous closure position is retained.

[0032] In this embodiment, the generation of a collaborative task chain in the closed-loop solidification module specifically includes: Extract candidate office actions that are continuously closed after replay and their corresponding EvolveGCN parameter updates from the evolution point along the parameter evolution order; Following the continuous closing sequence, the EvolveGCN parameters corresponding to the current candidate office action are updated and temporarily written into the EvolveGCN basic parameters, and the next candidate office action is replayed with the temporarily written EvolveGCN basic parameters. The continuous closure order is the parameter evolution order formed by the continuous closure between the first non-continuous closure position and the evolution landing point. After the reverse extraction is completed, the candidate office actions and the corresponding EvolveGCN parameters are rearranged according to the parameter evolution order. When temporarily updating EvolveGCN parameters, the parameter state before writing the basic EvolveGCN parameters is saved, and the EvolveGCN parameter update corresponding to the current candidate office action is written to the corresponding EvolveGCN graph convolutional layer and weight matrix row and column positions; when canceling the EvolveGCN parameter update corresponding to the current candidate office action, the basic EvolveGCN parameters are restored using the saved parameter state before writing. If there is a subsequent candidate office action, if the subsequent candidate office action reaches the corresponding evolution landing point, the EvolveGCN parameter update corresponding to the current candidate office action is retained; if it does not reach the corresponding evolution landing point, the EvolveGCN parameter update corresponding to the current candidate office action is cancelled, and the temporary writing of subsequent EvolveGCN parameter updates is stopped. If there is no subsequent candidate office action, the EvolveGCN parameter update corresponding to the current candidate office action is retained. The candidate office actions corresponding to the continuously retained EvolveGCN parameter updates are sequentially connected to form a collaborative task chain.

[0033] In this embodiment, the feedback continuation module generates a continuation collaborative task chain, specifically including: By reverse matching the actual execution results from the end of the collaborative task chain, the last completed collaborative task is located, the actual landing point corresponding to the last completed collaborative task is determined, and the last completed collaborative task is locked. The actual execution result is the execution data returned by the enterprise collaborative office platform after the collaborative task is executed, including the collaborative task identifier, completion status, actual processing object, and actual execution order; the completion status includes completed and incomplete; the system matches the actual execution result with the collaborative tasks in the collaborative task chain according to the collaborative task identifier; When determining the actual landing point, the actual processing object and the actual execution order in the actual execution result are written into the candidate office action corresponding to the last completed collaborative task. Starting from the parameter state before the candidate office action is executed, the candidate office action is replayed. The convolutional layer number and weight matrix row and column position of the EvolveGCN graph where the last parameter update is generated by the replay are recorded. The recorded position is determined as the actual landing point. When the convolutional layer number and weight matrix row and column position of the EvolveGCN graph are the same as those of the corresponding evolutionary landing point, the actual landing point is determined to be consistent with the corresponding evolutionary landing point. If either item is different, the actual landing point is determined to be inconsistent with the corresponding evolutionary landing point. Read the collaborative tasks from the end of the collaborative task chain in reverse order of their connection order, and determine the first collaborative task with the completed status as the last completed collaborative task. When locking the last completed collaborative task, retain the last completed collaborative task and the parameter state formed after completion. Do not delete or rewrite the last completed collaborative task and the corresponding EvolveGCN parameter update during feedback replay. When the actual landing point of the last completed collaborative task is inconsistent with the corresponding evolution landing point, the incomplete collaborative tasks after the last completed collaborative task are deducted, the EvolveGCN parameter updates corresponding to the incomplete collaborative tasks are canceled, the EvolveGCN basic parameters are rolled back to the parameter state after the last completed collaborative task is completed, and the evolution landing point corresponding to the last completed collaborative task is used as the starting point for the continuation of the process. The source switching test, virtual link deduction, reverse rollback and breakpoint rewind are re-executed, and the candidate office actions that are continuously closed after the continuation of the process are connected to the last completed collaborative task to form a continuation collaborative task chain.

[0034] When deducting incomplete collaborative tasks, remove the incomplete collaborative tasks after the last completed collaborative task from the collaborative task chain and the succession relationship between adjacent collaborative tasks.

[0035] Example 1: To verify the feasibility of this invention in practice, it was applied to a collaborative office environment in a company. Office tasks covered contract review, procurement approval, meeting scheduling, document circulation, seal application, and equipment maintenance application. The verification data included 240 company office events. The large model generated 1680 candidate office actions based on these 240 events, with each event generating 5-9 candidate actions. When office staff used the traditional direct generation method, the candidate actions were directly connected according to the output order of the large model. This easily led to problems such as actions with similar event sources but different target audiences being connected to the same task chain, actions modifying the same parameter positions before and after, actions in the middle of the task chain failing to return from the previous parameter state, and unfinished tasks continuing along the original task chain after the actual execution result changed. The verification records showed 73 instances of mismatched event sources, 58 instances of untrunculated overlapping parameter updates, and 17 instances of incorrect continuation after actual landing point deviation. Office staff needed to manually check the approval target, notification target, and document distribution scope item by item, resulting in a significant amount of manual correction.

[0036] When applying this invention, the enterprise collaborative office platform reads the processing items, office objects, and execution order from enterprise office events and sends the read content to the large model. The large model generates candidate office actions for each individual executable item and records the enterprise office events that generate candidate office actions as event sources. Event sources are established as event nodes, office objects are established as office object nodes, and candidate office actions are established as action edges connecting event nodes and office object nodes. Processing items are written into the action type field of the action edge, and execution order is written into the order field of the action edge. Event nodes, office object nodes, and action edges are written into the graph structure corresponding to the current EvolveGCN evolution round according to the generation order of candidate office actions.

[0037] Candidate office actions corresponding to the same event source all evolve from the same EvolveGCN basic parameters. The EvolveGCN parameter updates generated by each candidate office action are saved separately, and are not written to the EvolveGCN basic parameters before pre-insertion after the parameter update is completed. The system sets the last parameter update position after the last candidate office action completes its evolution as a placeholder, and extracts candidate office actions in reverse order of generation, starting from the last candidate office action. When the replay of a previous candidate office action reaches the first parameter update position of the next candidate office action, the system stops replaying and pre-inserts the parameter update generated by the previous candidate office action before the first parameter update position to the position before the parameter update corresponding to the next candidate office action. The system repeats the replay and pre-insertion process until the first candidate office action completes its pre-insertion, forming the initial evolutionary branch.

[0038] In contract review scenarios, a corporate office event includes extracting key contract points, reviewing risk clauses, confirming responsible personnel, approval workflow, and archiving notification. In traditional direct generation methods, the responsible personnel confirmation action can easily become intertwined with similar office objects in another contract office event. This invention reads similar corporate office events from the office event records stored on the corporate collaborative office platform, which have the same processing items, the same candidate office action generation order, and different office objects. It then switches the current event source to a similar corporate office event and re-enacts the candidate office actions along the parameter evolution order of the initial evolutionary branch. Candidate office actions that still reach the same evolutionary point after switching event sources are identified as virtual connected candidate office actions. The system deletes the virtual connected candidate office actions and corresponding EvolveGCN parameter updates from the initial evolutionary branch, preventing approval actions unrelated to the original office objects from entering the collaborative task chain.

[0039] In procurement approval scenarios, both price review and budget allocation actions update parts of the weight matrix positions within the same EvolveGCN graph convolutional layer. Starting from the first parameter update position of the subsequent candidate office action, the system reads the parameter updates corresponding to the preceding and subsequent candidate office actions in reverse order of parameter evolution, comparing the EvolveGCN graph convolutional layer numbers and the row and column positions of the weight matrix sequentially. Positions where the initial comparison matches are identified as overlapping positions. The system deletes the parameter updates from the overlapping position to the corresponding evolutionary endpoint of the preceding candidate office action, retains the parameter updates before the overlapping position, and inserts the retained parameter updates before the parameter updates corresponding to the subsequent candidate office action. After this processing, the price review action will not overwrite the parameter states required for the continued evolution of the budget allocation action.

[0040] After the initial evolutionary branch is formed, the system starts from the evolutionary endpoint corresponding to the retained candidate office actions and extracts parameter updates in reverse order according to the parameter evolution sequence. The system removes the current parameter update item by item and replays the candidate office action corresponding to the current parameter update from the parameter state corresponding to the previous parameter update position. When the replayed parameter update reaches the current parameter update position, the system resumes the current parameter update and marks the current parameter update position as a continuous closed position. When the replayed parameter update does not reach the current parameter update position, the system stops reverse extraction and marks the current parameter update position as the first non-continuous closed position. In the document flow scenario, the original task chain includes document verification, responsible person confirmation, sending range confirmation, and document distribution. When the responsible person confirmation action lacks a valid preceding parameter state, the sending range confirmation and document distribution can still form the latter part of the closure, creating a breakpoint in the middle of the task chain.

[0041] After the breakpoint rewind process begins, the system locks the parameter updates before the previous consecutive closed position, maintaining the parameter evolution order and content unchanged. The system disengages the connection between the previous consecutive closed position and the first non-consecutive closed position, and withdraws candidate office actions in reverse order of parameter evolution starting from the evolution landing point, moving the currently withdrawn candidate office action forward to after the previous consecutive closed position. The system replays the currently moved candidate office action with the parameter state corresponding to the previous consecutive closed position. When the currently moved candidate office action reaches the first non-consecutive closed position, the system retains the currently moved candidate office action and then replays the remaining candidate office actions according to the parameter evolution order before the disconnection. In the document flow scenario, after the sending range confirmation action is moved forward to supplement the missing closing condition of the responsible person confirmation action, the document distribution action regains the pre-parameter state that can reach the corresponding parameter position. When the closed condition cannot be supplemented by any of the trial candidate office actions, the system restores the candidate office actions before the disconnection, retaining the first non-consecutive closed position.

[0042] After a series of closed-loop candidate office actions are replayed, the system updates the EvolveGCN parameters corresponding to the current candidate office action and temporarily writes them into the EvolveGCN base parameters according to the sequence of consecutive closures. The system then uses these temporarily written EvolveGCN base parameters to replay the next candidate office action. When the next candidate office action reaches its corresponding evolutionary endpoint, the system retains the EvolveGCN parameter updates corresponding to the current candidate office action. If the next candidate office action does not reach its corresponding evolutionary endpoint, the system cancels the EvolveGCN parameter updates corresponding to the current candidate office action, restores the EvolveGCN base parameters to their state before being written, and stops temporarily writing subsequent EvolveGCN parameter updates. The consecutively retained candidate office actions are then linked together to form a collaborative task chain.

[0043] After a collaborative task is executed, the enterprise collaborative office platform returns the collaborative task identifier, completion status, actual processing object, and actual execution order. The completion status is set to "completed" or "incomplete." The system reads collaborative tasks in reverse order from the end of the collaborative task chain, identifying the first collaborative task with a "completed" status as the last completed collaborative task. The system writes the actual processing object and actual execution order into the candidate office action corresponding to the last completed collaborative task, and replays the candidate office action starting from the parameter state before its execution. The position of the last parameter update formed by the replay is determined as the actual landing point. If the actual landing point is inconsistent with the corresponding evolution landing point, the system locks the last completed collaborative task, deletes the continuation relationship between subsequent incomplete collaborative tasks and adjacent collaborative tasks, cancels the EvolveGCN parameter update corresponding to the incomplete collaborative task, and reverts the EvolveGCN basic parameters to the parameter state after the last completed collaborative task is completed. The system re-executes source switching trial, virtual connection deduction, reverse rollback, and breakpoint rewind from the evolution landing point corresponding to the last completed collaborative task to generate a continuation collaborative task chain.

[0044] The verification used the same 240 enterprise office events, the same 1680 candidate office actions, and the same EvolveGCN basic parameters, running both the traditional direct generation method and the processing method of this invention. Each method was repeated 60 times. Recorded data included the number of mismatched actions at the event source, the number of overlapping and untrunculated parameter updates, the percentage of consecutive closed candidate office actions, the success rate of generating collaborative task chains on the first attempt, the number of manual corrections per 100 enterprise office events, the number of times collaborative tasks were repeatedly executed, the number of incorrect continuations after deviation from the actual landing point, the accuracy rate of retaining completed collaborative tasks, the average time for anomaly recovery, and the average generation time for a single enterprise office event task chain.

[0045] Table 1: Comparison of Task Chain Generation and Feedback Continuation Effects in Enterprise Collaborative Office

[0046] Each processing method in the table above is repeated 60 times; the quantity indicators in the table are the arithmetic mean of the measurement results of 60 rounds, rounded to the nearest integer; the ratio indicators and time consumption indicators are the arithmetic mean of the measurement results of 60 rounds; the proportion of continuous closed candidate office actions is determined according to the proportion of the number of continuous closed candidate office actions to the total number of candidate office actions; the success rate of generating collaborative task chains on the first attempt is determined according to the proportion of the number of collaborative task chains that do not require manual modification after the first generation to the total number of collaborative task chains; the accuracy rate of retaining completed collaborative tasks is determined according to the proportion of the number of completed collaborative tasks that are correctly retained after feedback and replay to the total number of completed collaborative tasks that should be retained. The comparative results show that the present invention has a significant inhibitory effect on event source mismatch and parameter update overlap. The number of events with mismatched sources decreased from 73 to 11, a reduction of 84.9%. The number of parameters with overlapping and untrunculated updates decreased from 58 to 6, a reduction of 89.7%. The source-switching test verifies the replacement of event sources for candidate office actions. Virtual connections deduct and delete candidate office actions that maintain the same evolutionary landing point after the event source is changed. The overlapping position is truncated to retain the parameter update formed by the previous candidate office action before the overlapping position, reducing the mixing of office objects and the overlap of parameters between actions.

[0047] The percentage of consecutively closed candidate office actions increased from 86.1% to 97.4%, and the success rate of generating collaborative task chains on the first attempt increased from 82.5% to 95.8%. Reverse rollback, by sequentially unwinding parameters and replaying the corresponding candidate office actions, can locate the first non-consecutive closed position in the task chain. Breakpoint rewinding reverses the evolutionary landing point to attempt candidate office actions, moving those that can reach the first non-consecutive closed position forward to the previous consecutive closed position, thus filling in the parameter states required for intermediate breakpoints.

[0048] The number of manual corrections decreased from 31 per 100 enterprise office events to 8; the number of repeated executions of collaborative tasks decreased from 22 to 4; and the number of erroneous continuations after deviations from the actual landing point decreased from 17 to 2. The accuracy rate of retaining completed collaborative tasks improved from 91.8% to 99.1%, and the average time for anomaly recovery was shortened from 41.7 seconds to 15.2 seconds. Feedback continuation locks the last completed collaborative task, deducting only subsequent incomplete collaborative tasks, and continues from the evolution landing point corresponding to the completed collaborative task, reducing repeated executions caused by backtracking the entire collaborative task chain.

[0049] The average generation time for a single enterprise office event task chain using the processing method of this invention is 2.68 seconds, compared to 2.31 seconds for the traditional direct generation method, an increase of 0.37 seconds. The increased processing time comes from source switching trials, parameter overlap comparisons, reverse rollback, and breakpoint rewinding. After the 0.37-second increase, the number of events with mismatched sources, parameter overwriting, manual corrections, and erroneous continuations all significantly decrease, improving the stability of task chain generation and feedback recovery efficiency.

[0050] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. An intelligent collaborative office system for enterprises based on a large model, characterized in that, include: The action push module is used to push the candidate office actions generated by the large model into the EvolveGCN evolution rounds according to the event source, forming the initial evolution branches and evolution landing points; The source-switching simulation module is used to switch the event source to a similar enterprise office event that does not affect the office object corresponding to the candidate office action, and form a replacement evolution branch along the parameter evolution order of the initial evolution branch; The virtual connection deduction module is used to compare the initial evolutionary branch with the replacement evolutionary branch and deduct candidate office actions that still reach the same evolutionary point as the initial evolutionary branch in the replacement evolutionary branch. The reverse rollback module is used to reverse rollback from the evolution landing point corresponding to the retained candidate office actions to the event source according to the parameters, mark the first non-continuous closure position, and retain the candidate office actions that are continuously closed. The breakpoint rewind module is used to rewind from the first non-continuously closed position to the previous continuously closed position, insert candidate office actions to complete the closure conditions, and repeat the candidate office actions after the previous continuously closed position; The closed-loop solidification module is used to solidify the EvolveGCN parameter updates corresponding to the candidate office actions that are closed consecutively after the replay, and to generate collaborative task chains in the order of consecutive closures. The feedback continuation module is used to lock the completed collaborative tasks in the collaborative task chain, determine the actual landing point according to the actual execution result, and deduct the unfinished collaborative tasks after the corresponding evolution landing point when the actual landing point is inconsistent with the corresponding evolution landing point. It then continues the evolution from the last completed collaborative task to generate a continuation collaborative task chain.

2. The enterprise intelligent collaborative office system based on a large model according to claim 1, characterized in that, The action push-in module forms the initial evolutionary branch and the evolutionary landing point, specifically including: Push the candidate office actions corresponding to the same event source into the same EvolveGCN base parameters, and isolate the EvolveGCN parameter updates corresponding to each candidate office action; Set the evolution point of the last candidate office action as the tail placeholder, and extract candidate office actions in reverse order of generation. Replay the previous candidate office action. Stop replaying when the previous candidate office action reaches the first parameter update position of the next candidate office action. Insert the parameter update corresponding to the previous candidate office action before the parameter update corresponding to the next candidate office action. Repeat the process of replaying and inserting until the first candidate office action is inserted. The initial evolutionary branch is formed according to the parameter evolution order after insertion, and the tail position is determined as the evolution landing point.

3. The enterprise intelligent collaborative office system based on a large model according to claim 2, characterized in that, The reenactment of the previous candidate's office actions specifically includes: The first parameter update is located by following the parameter evolution order corresponding to the next candidate office action, and the position corresponding to the first parameter update is determined as the first parameter update position. Replay the previous candidate office action. When the previous candidate office action reaches the first parameter update position, capture the parameter update formed before the previous candidate office action reaches the first parameter update position. When the current candidate office action reaches the first parameter update position and the parameter updates corresponding to the two candidate office actions do not overlap, the intercepted parameter update is inserted before the parameter update corresponding to the next candidate office action. When the first candidate office action reaches the first parameter update position and the parameter updates corresponding to the two candidate office actions overlap, the parameter update corresponding to the previous candidate office action is truncated from the overlapping position, and the parameter update truncated before the overlapping position is inserted before the parameter update corresponding to the next candidate office action. If the previous candidate office action has not reached the first parameter update position, cancel the parameter update corresponding to the previous candidate office action and do not include the previous candidate office action in the initial evolution branch.

4. The enterprise intelligent collaborative office system based on a large model according to claim 3, characterized in that, The step of truncating the parameter update corresponding to the previous candidate office action from the overlapping position specifically includes: The parameter updates corresponding to the previous candidate office action and the parameter updates corresponding to the next candidate office action are located in the same EvolveGCN graph convolutional layer; Starting from the first parameter update position of the next candidate office action, we trace back along the parameter evolution order to determine the overlapping position where the two parameter updates first act on the same parameter position. Remove the parameter update formed from the overlapping position to the corresponding evolution point of the previous candidate office action; Preserve the parameter updates prior to the overlapping positions, and insert the preserved parameter updates before the parameter updates corresponding to the next candidate office action.

5. The enterprise intelligent collaborative office system based on a large model according to claim 1, characterized in that, The replacement evolution branch formed in the source switching trial module specifically includes: Starting with the EvolveGCN basic parameters before the formation of the initial evolutionary branch, retain the parameter updates in the initial evolutionary branch except for the parameter updates corresponding to the event source, and release the parameter update positions corresponding to the event source; Select similar enterprise office events that do not affect the corresponding office objects of the candidate office actions, and transfer the event source to similar enterprise office events; Replay the candidate office actions along the parameter evolution order of the initial evolution branch, and write the parameter updates formed after the switch into the released parameter update positions one by one; If a candidate office action fails to generate a parameter update at the corresponding released parameter update position, the subsequent replay will be truncated. The parameter updates written before the truncation will be connected in the parameter evolution order to form a replacement evolution branch.

6. The enterprise intelligent collaborative office system based on a large model according to claim 5, characterized in that, The virtual connection deduction module compares the initial evolutionary branch with the replacement evolutionary branch, specifically including: Align the initial evolutionary branches and the replacement evolutionary branches according to the parameter evolution order, and find the first difference parameter update position of the two evolutionary branches in reverse from the same evolutionary landing point; The parameter update corresponding to the first differential parameter update position is temporarily removed from the initial evolutionary branch. The parameter update position preceding the first differential parameter update position is determined as the direct continuation position. If there is no preceding parameter update position, the starting position of the initial evolutionary branch is determined as the direct continuation position. If there is a subsequent parameter update, the subsequent parameter update is continuated to the direct continuation position. Replay the candidate office action corresponding to the first difference parameter update position from the directly continuation position; If the same evolutionary point is reached after the replay, the corresponding candidate office action is deducted; if the same evolutionary point is not reached, the temporarily removed parameter update is restored, and the corresponding candidate office action is retained.

7. The enterprise intelligent collaborative office system based on a large model according to claim 6, characterized in that, The first non-continuously closed position is marked in the reverse roll-back module, specifically including: Parameters are extracted and updated in reverse order from the evolution points corresponding to the retained candidate office actions; The current parameter update is withdrawn item by item. If the current parameter update has a previous parameter update position, the candidate office action corresponding to the current parameter update is replayed starting from the parameter state corresponding to the previous parameter update position. If the current parameter update does not have a previous parameter update position, the candidate office action corresponding to the current parameter update is replayed starting from the EvolveGCN basic parameters before the formation of the initial evolution branch. When the current parameter update position is reached after replay, the current parameter update is resumed, and the current parameter update position is marked as a continuous closed position; If the current parameter update position is not reached after the replay, the reverse extraction stops. The current parameter update position is marked as the first non-continuous closure position. Candidate office actions that are continuously closed between the first non-continuous closure position and the evolution landing point are retained.

8. The enterprise intelligent collaborative office system based on a large model according to claim 7, characterized in that, The breakpoint rewind module inserts candidate office actions to complete the closure conditions, specifically including: If the first non-continuously closed position does not have a previous continuously closed position, the starting position of the initial evolutionary branch is determined as the previous continuously closed position; Lock the parameter update before the previous consecutive closed position, and disconnect the candidate office actions between the first non-consecutive closed position and the evolutionary landing point; From the evolution point, the candidate office actions between the first non-continuously closed position and the evolution point are withdrawn in reverse order of parameter evolution. The currently withdrawn candidate office action is moved forward to after the previous continuous closed position. The parameter state corresponding to the previous consecutive closed position is used to replay the current forward candidate office action. The reverse withdrawal stops when the current forward candidate office action reaches the first non-consecutive closed position. Retain the currently moved candidate office actions and replay the remaining candidate office actions according to the parameter evolution order before disconnection; If the current forward-moving candidate office action does not reach the first non-continuously closed position, the current forward movement is canceled, and the candidate office action that has not yet been tested is withdrawn in reverse. If all candidate office actions between the first non-continuous closure position and the evolution landing point have been performed and none of them have reached the first non-continuous closure position, then the candidate office actions before the disconnection are restored, and the first non-continuous closure position is retained.

9. The enterprise intelligent collaborative office system based on a large model according to claim 8, characterized in that, The closed-loop solidification module generates a collaborative task chain, specifically including: Extract candidate office actions that are continuously closed after replay and their corresponding EvolveGCN parameter updates from the evolution point along the parameter evolution order; Following the continuous closing sequence, the EvolveGCN parameters corresponding to the current candidate office action are updated and temporarily written into the EvolveGCN basic parameters, and the next candidate office action is replayed with the temporarily written EvolveGCN basic parameters. If there is a subsequent candidate office action, if the subsequent candidate office action reaches the corresponding evolution landing point, the EvolveGCN parameter update corresponding to the current candidate office action is retained; if it does not reach the corresponding evolution landing point, the EvolveGCN parameter update corresponding to the current candidate office action is cancelled, and the temporary writing of subsequent EvolveGCN parameter updates is stopped. If there is no subsequent candidate office action, the EvolveGCN parameter update corresponding to the current candidate office action is retained. The candidate office actions corresponding to the continuously retained EvolveGCN parameter updates are sequentially connected to form a collaborative task chain.

10. The enterprise intelligent collaborative office system based on a large model according to claim 9, characterized in that, The feedback continuation module generates a chain of collaborative tasks, specifically including: By reverse matching the actual execution results from the end of the collaborative task chain, the last completed collaborative task is located, the actual landing point corresponding to the last completed collaborative task is determined, and the last completed collaborative task is locked. When the actual landing point of the last completed collaborative task is inconsistent with the corresponding evolution landing point, the incomplete collaborative tasks after the last completed collaborative task are deducted, the EvolveGCN parameter updates corresponding to the incomplete collaborative tasks are canceled, the EvolveGCN basic parameters are rolled back to the parameter state after the last completed collaborative task is completed, and the evolution landing point corresponding to the last completed collaborative task is used as the starting point for the continuation of the process. The source switching test, virtual link deduction, reverse rollback and breakpoint rewind are re-executed, and the candidate office actions that are continuously closed after the continuation of the process are connected to the last completed collaborative task to form a continuation collaborative task chain.

Images