Snapshot auditing and condition recovery method for industrial intelligent agent-human collaborative task

Abstract

The application discloses a kind of snapshot auditing and condition recovery methods of industrial intelligent man-machine collaborative task. When task reaches artificial collaborative suspension point, running engine freezes task context mode, controlled display template, auditing mode, result mode, auditing strategy, running version, mechanism evidence, task round and waiting state version, and writes in the same transaction according to original state version condition Waiting state and creating sending record. Collaborative desk idempotent receives task, instantiates review item according to frozen snapshot, receives item-by-item confirmation or structured modification, generates immutable final output object and final output reference, and writes in the same transaction Auditing result, audit record and result sending record. Running engine verifies round, waiting state version, snapshot hash, load hash and idempotent key after condition recovery task;Repeat, late or old round result does not change task state, and downstream node only reads final output reference. The application can reduce the risk of configuration drift, repeated effect, error round recovery and unreviewed output propagation in cross-system manual auditing.

Description

Technical Field

[0001] This invention relates to the fields of industrial intelligent agent operation control, distributed workflow, human-machine collaborative review and data consistency technology. Specifically, it relates to a method and system for safely restoring industrial intelligent agent tasks by freezing task review definitions, generating final output in a structured manner, and conditionally consuming manual results, under the condition that the running engine and the cooperating platform each hold local persistent data. Background Technology

[0002] Industrial intelligent agents can utilize workflows to invoke scripts, rules, mechanistic models, knowledge retrieval, general models, and business connectors to complete tasks such as generating processing parameters, diagnosing equipment anomalies, determining quality, and ensuring compliance with R&D expense regulations. Some task outputs will be further written into the enterprise's business systems or become inputs for subsequent process, financial, and control nodes; therefore, manual confirmation is required at designated nodes.

[0003] Existing human-machine collaboration solutions typically send model results to a human interface when model confidence is insufficient, allowing the automated process to continue after receiving confirmation or correcting the results. While this approach can supplement model judgment, it does not address the issue of how historical tasks should be displayed and processed semantically when changes occur during human review, such as changes in task definition, review strategy, underlying mechanisms, or operating version.

[0004] In systems where the runtime engine and the human collaboration system use separate databases, task suspension, human task creation, review result saving, and runtime task resumption cannot be directly overridden by a single database transaction. When using a synchronous interface, interface timeouts may result in the runtime engine being suspended but the collaborative task not being created, or the collaborative platform saving the results but the runtime engine not receiving them. When using at least one message delivery, duplicate messages, out-of-order messages, and late messages may occur.

[0005] If the manual review results are returned only as natural language comments or temporary form fields, the engine needs to reinterpret the reviewer's meaning, which can easily lead to ambiguity. If downstream nodes continue to read the original output before the manual review, they may even bypass manual correction. If the task round, waiting status version, and review definition version are not verified, old rounds or duplicate review results may incorrectly restore the current task.

[0006] Therefore, a technical solution is needed for human-machine collaborative tasks in industrial intelligent agents. This solution would freeze the definition, strategy, version, and evidence of a task when it enters human review, enable the collaborating platform to atomically generate structured results and unique final output references locally, and ensure that the runtime engine consumes results only when the task round, waiting state version, and frozen snapshot all match. This would solve the problems of configuration drift, duplicate activation, incorrect round recovery, and unreviewed output being read downstream during cross-system suspension and recovery processes. Summary of the Invention

[0007] The technical problem to be solved by this invention is: how to maintain the semantic stability of manual review under the conditions that the industrial intelligent agent's running engine and the co-working platform are deployed separately, persisted independently, and messages may be duplicated or delayed; how to make the review results into structured data that the running engine can directly verify and execute; and how to avoid the workflow being incorrectly restored due to old rounds, duplicate messages, or state conflicts.

[0008] To address the aforementioned technical problems, this invention provides a snapshot review and condition recovery method for human-machine collaborative tasks in industrial intelligent agents.

[0009] When the industrial intelligent agent workflow reaches the point of human collaboration suspension, the running engine obtains the human collaboration definition, review strategy, digital employee version, running release package version, mechanism evidence snapshot, input reference, and original output reference corresponding to the current task; determines the waiting state version corresponding to this suspension based on the current task state version, writes the task round and the waiting state version together into the task definition snapshot, and performs normalized serialization on the task definition snapshot to calculate the snapshot hash.

[0010] Within the same local transaction, the execution engine updates the task status to "awaiting human result" based on the original task status version and writes the "awaiting status version." Simultaneously, it writes a transactional sending record for the collaborative task creation, containing a snapshot of the task definition and its snapshot hash. The collaboration console receives the creation message through the receiving record and idempotent key, saves the task definition snapshot, and instantiates the review interface and review items based on the context mode, controlled display template, review mode, result mode, and local mechanism evidence snapshot.

[0011] Human reviewers perform approval actions at the collaborative desk, including approval after correction, rejection for redo, return to upstream, transfer to human intervention, or cancellation. For high-risk tasks, the submission interface verifies each item to confirm that all review items marked as true have independent human results; if not all are completed, the task is rejected or approved after correction. Corrections are represented as structured patches consisting of field paths and values, and are subject to frozen editable field ranges, data types, units, and cross-field constraints.

[0012] The co-processing desk validates the structured audit results based on the frozen result pattern, applies the validated manual corrections to the original output to generate the final output object, and generates a final output reference pointing to that object. The co-processing desk writes the task processing status, item-by-item audit results, structured result payload, final output reference, audit events, reflow candidates when needed, and result transactional dispatch records into the same local transaction.

[0013] The runtime engine receives structured result messages using receipt records and idempotent keys, and verifies the task identifier, the manual collaboration start point identifier, the task round, the current waiting state, the waiting state version, the snapshot hash, the result mode version, and the payload hash. Only when all items are consistent and the idempotent key has not been effectively consumed does the runtime engine write a valid output reference to the node, and update the task state based on the condition that the current task is still in the waiting state for manual results and the task state version is equal to the stated waiting state version; duplicate, late, old round, or inconsistent results do not change the task state. The recovered downstream nodes only read data from the final output reference.

[0014] When the review action is to reject and redo, the runtime engine creates a new execution round and writes the structured rejection reason and new constraints into the new round's input; the review results of the old round cannot be applied to the new round. Manual corrections and manual reasons can form reflow candidates, but reflow candidates only affect future tasks after subsequent review and release by the mechanism library, and do not change the mechanism snapshot frozen in the current task.

[0015] The present invention also provides an industrial intelligent human-machine collaborative control system, a computer device, and a computer-readable storage medium for implementing the above method.

[0016] Compared with existing technologies, this invention freezes task definition snapshots, ensuring that upgrades to skills, mechanisms, job responsibilities, or operational strategies during the review process do not alter the review semantics of already created tasks; it avoids half-finished states (where the status has changed but the result has not been sent, or the result has been sent but the final output has not been stored) by atomically submitting structured results, final output references, audit records, and result sending records through the collaborative platform; it prevents duplicate, late, and old round result errors from restoring tasks by jointly verifying rounds, waiting state versions, snapshot hashes, and idempotent keys through the runtime engine; and it prevents the continued propagation of unverified original outputs by forcing downstream users to only read final output references. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the overall system structure of the present invention.

[0018] Figure 2 A schematic diagram of the frozen snapshot structure defined for the task.

[0019] Figure 3 A diagram illustrating the instantiation of review items and the step-by-step confirmation of high-risk items.

[0020] Figure 4 This is a flowchart of the overall process of the method of the present invention.

[0021] Figure 5 This is a schematic diagram illustrating the submission of the review results from the co-organizing platform.

[0022] Figure 6This diagram illustrates the consumption and recovery of the running engine conditions.

[0023] Figure 7 This is a schematic diagram of the status of a human-assisted collaborative task and multiple rounds of control.

[0024] Figure 8 This is a schematic diagram illustrating the boundary between audit results and experience feedback. Detailed Implementation

[0025] The embodiments of the present invention will be further described below with reference to the accompanying drawings. These embodiments are for illustrative purposes only and are not intended to limit the scope of protection. The runtime engine and the co-working platform can be deployed on different processes, containers, or compute nodes within the same factory network, or on different services within the same compute node; both are written to their respective persistent databases and interact through local interfaces or messaging mechanisms.

[0026] like Figure 1 As shown, the system includes a factory operation engine, a collaboration desk, local artifact and evidence storage, a mechanism snapshot package, and incoming and outgoing records for both the operation engine and the collaboration desk. The operation engine is the main body for executing tasks of the industrial intelligent agent; the collaboration desk is used to present human-assisted tasks and receive human operations; the local artifact and evidence storage is used to save immutable references to inputs, raw outputs, final outputs, and evidence.

[0027] Industrial intelligent agent workflows can be expressed using restricted directed acyclic graphs, state machines, or other persistent workflow representations. Each human collaboration endpoint must define at least the endpoint identifier, allowed actions, context mode, display template, review mode, result mode, backflow extraction mode, return target, upstream return target, and timeout policy. Once the task begins, the digital employee version, runtime release package, workflow, skills, mechanism snapshot, connector bindings, and model routing remain locked.

[0028] When the runtime engine reaches the point where manual collaboration is suspended, a task definition snapshot is generated. For example... Figure 2As shown, a task definition snapshot can include task_id, hitl_hook_id, round_no, wait_state_version, task_context_schema, task_context_view_template, hitl_review_schema, hitl_result_schema, hitl_policy_snapshot, da_version_id, runtime_release_bundle_id, mechanism_snapshot_package_id, input_refs, original_output_ref, evidence_snapshot, and mechanism_refs. Among these, wait_state_version represents the state version the task should have when it is in a state of waiting for human results after this suspension.

[0029] Among them, task_context_schema is used to specify the data structure of the review context; task_context_view_template is used to specify the controlled components and data binding; hitl_review_schema is used to specify the review items, mandatory confirmation flags, allowed actions and editable fields; hitl_result_schema is used to specify the result structure that the running engine can consume; hitl_policy_snapshot is used to record the effective risk level, human collaboration level, reviewer, return limit, time limit and field permissions when the task is created.

[0030] Task-defined snapshots do not directly copy large drawings, CNC programs, model files, or original sensor files. Instead, they preserve references to immutable objects, content summaries, and necessary preview references. Structured fields in the snapshot are normalized and serialized according to a predetermined key order, numeric representation, null value representation, and character encoding before calculating the snapshot_hash. When using the same semantic data, the same normalized byte sequence should be generated.

[0031] When the runtime engine creates a human collaboration task, it executes within a database transaction: Based on the task state version before suspension, it updates the node's running state to "awaiting human result" and writes it to `wait_state_version`; it writes a wait record; and it writes a human collaboration creation send record containing a snapshot of the task definition or its immutable reference, `snapshot_hash`, and `wait_state_version`. If the conditional update does not match the record, the transaction rolls back and no send record is created. After the transaction commits, the sender sends the message; if sending fails, it does not roll back the already persisted wait state, but instead retryes the send record.

[0032] After receiving the creation message, the collaboration desk queries the receipt record using the idempotency_key or a combination key consisting of task_id, hitl_hook_id, and round_no. If the task has been processed, it returns the identifier of the created task; otherwise, it creates the human collaboration task, saves a snapshot of the task definition, and the receipt record within a single transaction. This method allows messages to be delivered at least once, and only one valid task instance is generated for the same task on the collaboration desk.

[0033] The co-organizer does not query the skill library, cloud mechanism library, or operations management system in real time during the review process. The review interface and review semantics are based on a frozen snapshot saved when the task was created. If the skill version, mechanism version, job responsibilities, or review strategy changes subsequently, the interface may indicate a difference between the current version and the task version, but it must continue to display and verify according to the task snapshot.

[0034] The task context display template is only allowed to call key-value panels, tables, timelines, evidence cards, image previews, file references, and review item components that are on the component whitelist, and it is only allowed to read the task context according to the pre-validated data path. The template must not execute arbitrary scripts or unfiltered hypertext markup. When template parsing fails, the co-working desk uses a read-only key-value view and a structured data view for degraded display without changing the review data.

[0035] like Figure 3 As shown, the co-working desk instantiates review items based on the frozen hitl_review_schema and local mechanism evidence snapshots. A review item may include check_item_id, item_code, check_standard, check_method, risk_level, mechanism_ref, mechanism_version, evidence_refs, evidence_snapshot, context_hash, must_confirm, allowed_results, editable_paths, human_result, and human_comment.

[0036] The mechanism references in the review items point to the mechanism snapshot package locked in the task, not to the latest mechanism version at the time of review. For the same task type, an applicable review item template can be selected based on the conditions and task context in the frozen review mode, but the template used, applicable conditions, and data bindings must be included in the task definition snapshot or its immutable reference, so as to be able to reproduce why the corresponding review item appears for that task.

[0037] High-risk tasks have their `hitl_level` set to strict item-by-item confirmation. The coordinating desk receives manual results for each review item with a `must_confirm` value of true, recording the operator, time, result, and necessary explanations for each confirmation. Before persisting the results, the submission interface checks each mandatory confirmation item against the set of review item identifiers in the task definition snapshot to ensure it has an independent result; if any mandatory confirmation item is missing, the task is rejected or approved after correction. Regular review tasks can be approved directly, approved after correction, returned, or transferred to manual review according to a freeze policy.

[0038] Manual corrections are represented using structured patches. A structured patch includes at least the field path, a summary of the original value, the new value, the data type, the unit, and the reason for the correction. The console verifies whether the field path is in `editable_paths` and checks required fields, data types, numerical ranges, units, and cross-field constraints according to `hitl_result_schema`. Natural language descriptions that fail schema validation cannot be considered valid results for the engine to recover.

[0039] For operations that pass through the source, the final output object can reference the original output object; for operations that pass through the source after correction, the co-working platform applies a validated structured patch to the correctable portion of the original output, generating a new immutable final output object. The final output object can store a content summary, creator, source original output reference, correction patch reference, schema version, and creation time, and is uniquely referenced by `final_output_ref`.

[0040] The structured human collaboration result payload may include task_id, hitl_hook_id, round_no, review_action, item_results, correction_patch, human_comment, snapshot_hash, result_schema_version, final_output_ref, expected_wait_state_version, idempotency_key, and payload_hash. The payload_hash is calculated based on the normalized result payload, excluding non-semantic fields such as transmission time.

[0041] like Figure 5As shown, when the collaboration desk submits the review results, it writes the following to a local transaction: the status of the manual collaboration task; the item-by-item confirmation results; the structured manual collaboration result payload; the final_output_ref; the review audit event; the reflow candidates when they meet the reflow policy; and the result transactional sending record. Any failure to write any of these items will cause the transaction to roll back, preventing situations where the task appears to have passed but the final output has not been created, or the result message has been sent but the audit record is missing.

[0042] The result sender processor sends a structured result message after the transaction is committed. The message can be resent, but the runtime engine ensures it only generates a valid state change once using the received record and `idempotency_key`. The message must contain at least the `task_id`, `hitl_hook_id`, `round_no`, `snapshot_hash`, `result_schema_version`, `review_action`, `final_output_ref`, `expected_wait_state_version`, `idempotency_key`, and `payload_hash`.

[0043] like Figure 6 As shown, after receiving the structured result message, the runtime engine verifies the following in sequence: task_id matches the waiting record; hitl_hook_id matches; the current task is still in the state of waiting for manual results; round_no matches the current execution round; the current task_state_version equals expected_wait_state_version; snapshot_hash matches the hash saved when the task was created; payload_hash recalculation matches; the result satisfies the frozen hitl_result_schema; and idempotency_key has not yet been effectively consumed.

[0044] After successful verification, the runtime engine writes the received record, the reference to the manual collaboration result, and the reference to the valid output of the node within a transaction or a persistent operation with compare-and-swap semantics, and updates the task state based on task_state_version. If the number of records affected by the conditional update is zero, it means that the task has been advanced by other operations or the round has changed, and this result is marked as invalid, without changing the task state.

[0045] For duplicate `idempotency_key`, the runtime engine returns the processing result of the first valid consumption and does not execute subsequent nodes. For results where `round_no` is less than the current round, `expected_wait_state_version` is inconsistent with the current version, `snapshot_hash` is inconsistent, or the current task has been terminated, the runtime engine records audit information and refuses to recover.

[0046] When the audit action is approved or approved after correction, the runtime engine sets `final_output_ref` as a valid output reference for the manually coordinated node and continues execution of downstream nodes. Downstream nodes' input mappings can only read this valid output reference and must not fall back to `original_output_ref`. This ensures that even if the original output is still retained for audit purposes, manual correction will not be bypassed.

[0047] like Figure 7 As shown, when the audit action is to rework, the runtime engine creates a new execution round based on the frozen rework_target_node_id, and writes the structured rework reason, constraint patch, and previous round identifier into the new round input. The new round regenerates the task definition snapshot, round_no, and wait_state_version. Messages from the old round cannot be recovered for the new round due to round inconsistencies.

[0048] When the audit action is to roll back upstream, the runtime engine rolls back to the specified node based on the frozen upstream_target_node_id and sets the affected downstream intermediate outputs to be unusable. When the audit action is to transfer to manual control, the task remains paused and a manual recovery item is created; when the audit action is to cancel, the task is terminated only if the freeze policy allows it.

[0049] like Figure 8 As shown, manual corrections, reasons for rejection, manual explanations, and relevant mechanism references can be generated as `reflow_candidate` in the collaborative review process. Reflow candidates are anonymized and written to a local buffer, ensuring that local review and engine recovery are not affected when the factory loses network access; they are then synchronized to the mechanism library's extraction pool after network recovery. The mechanism library performs deduplication, clustering, professional review, and version release on reflow candidates; the release results only affect subsequent tasks that load new mechanism snapshots.

[0050] In one embodiment of CNC machining parameter review, the runtime engine generates parameter suggestions based on part material, equipment model, cutting tool, process, and CNC program, and reaches the high-risk manual collaboration hang point. The task definition snapshot locks the machining parameter review mode, equipment capability mechanism reference, collision simulation evidence, and runtime release package version; the collaboration table instantiates five mandatory review items: spindle speed, feed rate, depth of cut, safety height, and collision simulation.

[0051] The auditors corrected the cutting depth from 0.8 mm to 0.5 mm and confirmed each item. The co-processing unit validated the unit, range, and associated fields based on the result pattern, generated a new final parameter object and `final_output_ref`, and atomically wrote them to the audit results and result dispatch record. After the running engine verified the round, status version, and snapshot hash, it used `final_output_ref` as the sole input for subsequent CNC program generation nodes.

[0052] In one implementation of R&D expense allocation auditing, the task definition snapshot locks the R&D project, expense details, allocation rule version, evidence citation, and result schema. If the auditor finds that an equipment depreciation allocation object does not conform to the rules, they choose to return it for redo and submit a structured reason and constraints. After the running engine verifies the results, a new round is created, requiring a re-determination of the allocation object; even if the pass or correction message for the old round arrives subsequently, it will not take effect due to the inconsistency between round_no and task_state_version.

[0053] Even when the factory's external network is disconnected, but the engine, collaboration platform, local database, product storage, and mechanism snapshot package are all available, manual task creation, task review, structured result submission, and task recovery are all completed locally at the factory. Only cloud synchronization, backhaul uploads, and new version retrieval are affected. Frozen review definitions and mechanism evidence are not recalculated based on the external network.

[0054] In a duplicate delivery example, a manually created collaborative message is delivered twice due to a lost send acknowledgment. The collaboration platform uses `task_id`, `hitl_hook_id`, and `round_no` to form unique constraints, and establishes a receipt record using `idempotency_key`. The second delivery only returns the identifier of the manually created collaborative task from the first delivery, without creating a new valid task. Consequently, when a message is delivered repeatedly, the runtime engine returns the first valid consumption result in the same way, without further advancing the downstream nodes.

[0055] In a concurrent submission example, two reviewers submit the same collaborative task almost simultaneously. The collaboration desk updates the submission of the processing transaction with the task processing version or equivalent conditions. Only one transaction can update the task from the pending review status to the processed status and write it into the final output and result dispatch record; the other transaction is rolled back due to the failure of the condition update and indicates that the task has been processed.

[0056] In one example of a delayed result, after the first round of review is rejected, a second execution round is generated, and then the pass message from the first round reaches the execution engine. Because the round_no, snapshot_hash, and expected_wait_state_version in the message are inconsistent with the waiting records for the second round, the execution engine records the message as a failed result, does not update the task status, and does not overwrite the valid output of the second round.

[0057] The database products, message brokers, hash algorithms, and serialization formats used in this invention can be replaced. Transactional sender and receiver records can be implemented using relational database tables, persistent logs, or mechanisms with equivalent atomicity and idempotency; conditional state updates can be implemented using database version fields, compare-and-swap operations, or equivalent optimistic concurrency control.

[0058] The field names used in the above implementation are logical names for ease of explanation. In actual implementation, field names may be changed or multiple fields may be stored together, but the technical relationships of frozen review definitions, atomic generation of final output and result messages by the co-working platform, condition restoration after verification rounds and status versions by the running engine, and downstream only reading references to the final output should be maintained. Appendix: Examples of Main Data Objects

[0059] Task definition snapshot task_id, hook_id, round_no, wait_state_version, each schema, strategy, version, snapshot_hash Semantics for displaying, reviewing, and delivering results of fixed tasks Structured result load review_action, item_results, correction_patch, final_output_ref, expected_wait_state_version, payload_hash Provided for direct verification and consumption by the running engine Transactional sending records event_type, aggregate_id, payload_ref, idempotency_key, send_status Reliable sending of fact messages across databases Receipt records message_id, idempotency_key, payload_hash, processed_at, result_ref To prevent duplicate messages from being applied repeatedly Final output object source_output_ref, correction_patch_ref, schema_version, content_hash Downstream unique trusted output

Claims

1. A snapshot review and condition recovery method for human-machine collaborative tasks in industrial intelligent agents, applied to a computer system in which the industrial intelligent agent's operating engine and the cooperating platform respectively hold locally persistent data, characterized in that... include: When the industrial intelligent agent's operation engine executes a task to the point of human collaboration suspension, it obtains the task context mode, controlled display template, audit mode, result mode, and audit strategy corresponding to the current task, as well as the digital employee version identifier, runtime release package identifier, mechanism evidence snapshot identifier, input reference, and original output reference; it determines the waiting state version based on the task state version before suspension, and writes the above data, along with the task identifier, human collaboration suspension point identifier, task round, and the waiting state version, into the task definition snapshot, and performs normalized serialization on the task definition snapshot to calculate the snapshot hash; The industrial intelligent agent running engine updates the current task to a state of waiting for human results and writes the waiting state version in the same local transaction, based on the task state version before suspension. At the same time, it writes a transactional message record for the creation of human collaborative tasks containing the task definition snapshot and its snapshot hash. The co-processing platform uses the receiving record and idempotent key to receive the creation message corresponding to the transactional sending record, saves the task definition snapshot, and instantiates the review interface and review items according to the task context mode, controlled display template, review mode and mechanism evidence snapshot; The coordinating desk receives review actions, item-by-item manual results, and structured correction patches. It verifies the review items and editable fields that must be confirmed according to the review mode, verifies the structured review results according to the result mode, applies the verified structured correction patches to the original output pointed to by the original output reference to generate an immutable final output object, and generates a final output reference pointing to the final output object. The collaborative work platform writes the processing status of the manual collaboration task, item-by-item manual results, structured audit result payload, the final output reference, audit events, and result transactional sending records into the same local transaction. The structured audit result payload includes at least the task identifier, the manual collaboration start point identifier, the task round, the snapshot hash, the result mode version, the audit action, the final output reference, the waiting status version, the idempotent key, and the payload hash; and The industrial intelligent agent operation engine uses the receiving record and the idempotent key to receive the result message corresponding to the result transactional sending record. When the current task is in the waiting state for human results, and the human collaboration start point identifier, task round, current task status version, snapshot hash, result mode version, and payload hash all match the structured audit result payload, the current task status version is equal to the waiting state version, and the idempotent key has not been effectively consumed, a valid output reference of the human collaboration node is written, and the task status is updated to restore the task based on the condition that the current task is still in the waiting state for human results and the current task status version is equal to the waiting state version. Duplicate, late, old round, or conditionally mismatched result messages do not change the task status, and the downstream node after restoration only obtains the output data through the final output reference.

2. The method according to claim 1, characterized in that, The task definition snapshot also includes digital employee instances and job responsibility snapshots, runtime release package versions, mechanism snapshot package versions, evidence references, allowed audit actions, rejection limits, and field permissions; the task definition snapshot is calculated by normalizing and serializing it according to a predetermined key order, numerical representation, null value representation, and character encoding. Upgrades to skills, mechanisms, job responsibilities, or audit strategies that occur during the audit do not change the task definition snapshot used by the created task.

3. The method according to claim 1, characterized in that, The review items are instantiated by the frozen review mode and the mechanism evidence snapshot. Each review item includes review criteria, mechanism asset identifier, mechanism version, evidence citation, mandatory confirmation flag, allowed manual results, and manual results. For high-risk tasks, the submission interface of the co-working platform checks each review item with a mandatory confirmation flag of true according to the review item identifier set in the task definition snapshot to see if it has an independent manual result. If any mandatory confirmation review item is not completed, the submission is rejected or approved after correction.

4. The method according to claim 1, characterized in that, The structured correction patch includes the field path, original value summary, new value, data type, unit, and reason for correction; The co-working platform verifies the field path, data type, numerical range, unit, and cross-field constraints based on the frozen editable field range and result mode; the final output object includes the original output reference, the structured correction patch that passes the verification, the result mode version, and the content summary.

5. The method according to claim 1, characterized in that, The same local transaction of the co-working platform also writes backflow candidates that meet the backflow strategy; the result transactional sending record is sent after the transaction is committed, and is retained and retried if the sending fails, and if any write fails in the same transaction, the task handling status, structured audit result payload, final output reference, audit event, backflow candidate and result transactional sending record will not take effect.

6. The method according to claim 1, characterized in that, The industrial intelligent agent's operating engine writes receipt records, structured audit result payload references, and valid output references of human collaboration nodes in the same local transaction or persistent operation with comparison and exchange semantics. It updates the task status based on the condition that the current task is still in the waiting state for human results and the current task status version is equal to the waiting state version. If the condition update fails, the result message is marked as an invalid result without changing the task status. For idempotent keys that have been effectively consumed, the first consumption result is returned.

7. The method according to claim 1, characterized in that, When the review action is to reject and redo, the industrial intelligent agent running engine creates a new execution round, writes the structured rejection reason and new constraints into the new round input, and generates a new task definition snapshot and waiting state version for the new round; the result message of the previous round cannot change the task state of the new round due to mismatch of task round, snapshot hash or waiting state version; the return candidate is used to generate the future mechanism version after being de-identified and manually reviewed, without changing the mechanism evidence snapshot locked by the current task.

8. A snapshot review and condition recovery system for human-machine collaborative tasks in industrial intelligent agents, characterized in that, include: The runtime engine suspension module is used to determine the waiting state version based on the task status version before suspension when the task reaches the human collaboration suspension point, generate a task definition snapshot and snapshot hash including task context mode, controlled display template, audit mode, result mode, audit strategy, version identifier, task round and the waiting state version, and update the task to the waiting result state in the same local transaction based on the task status version before suspension, write the waiting state version and write the human collaboration task creation transactional sending record; The collaborative task receiving module is used to receive creation messages using receipt records and idempotent keys, save task definition snapshots, and instantiate the review interface and review items based on the task definition snapshots and mechanism evidence snapshots. The audit result generation module is used to receive audit actions, item-by-item manual results, and structured correction patches. It performs verification based on the frozen audit mode and result mode, generates immutable final output objects, final output references, and structured audit result payloads, and writes task processing status, item-by-item manual results, structured audit result payloads, final output references, audit events, and result transactional sending records in the same local transaction. as well as The engine recovery module is used to receive result messages using receipt records and idempotent keys, verify the task identifier, human collaboration start point identifier, task round, waiting status, waiting status version, snapshot hash, result mode version, and payload hash, and write a valid output reference of the human collaboration node when the verification is successful. It also recovers the task on the condition that the task is still in the waiting state for human results and the task status version is equal to the waiting state version, so that the downstream nodes after recovery can obtain the output data only through the final output reference.

9. A computer device comprising a processor and a memory, the memory storing a computer program, characterized in that, When the computer program is executed by the processor, it causes the computer device to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images