A method, system, device and storage medium for range isolation, artificial-in-the-loop recovery and consistency snapshot processing of multi-role health intelligent agent conversation

Abstract

The application discloses a range isolation, artificial in-loop recovery and consistency snapshot processing method for multi-role health intelligent agent conversation. A mobile terminal generates a conversation type, a conversation identifier and a range key; a server isolates conversations, runs, to-be-done, memories and digital twin snapshots according to the range key. When artificial supplement information is needed, the system generates a recovery descriptor binding a running identifier, a to-be-done identifier, an agenda identifier and a snapshot version summary. After receiving artificial results or a recovery request, the system checks the descriptor, de-duplicates the identifier and accesses the relationship, only loads the current snapshot and the memory of the same range, conditionally updates the agenda and the snapshot version, and outputs the recovery result. The scheme reduces the probability of multi-role conversation state crosstalk, repeated recovery and obsolete snapshot coverage.

Description

Technical Field

[0001] This invention relates to the fields of health information processing, mobile terminal and server collaboration, session state management, access isolation, asynchronous event processing, and human-computer collaborative interaction. In particular, it relates to a method, system, device, and storage medium for range isolation, human-in-the-loop recovery, and consistent snapshot processing for multi-role health intelligent agent sessions. This invention deals with health management interactions and system states, and does not output disease diagnoses or treatment conclusions. Background Technology

[0002] Intelligent agents for health management typically have multiple interaction points, such as personal health assistant, family guardian, and service account. These different entry points may be logged in through the same mobile terminal, or they may correspond to different members of the same user, different service accounts, and different sessions. An interaction with an intelligent agent may also be paused because it requires supplementing measurement results, user confirmation, device-collected results, or manual information entry, and will continue after the user returns the results at a later time.

[0003] In existing technologies, saving temporary states solely using user identifiers or session identifiers can easily lead to the following problems: First, contexts related to family members, service accounts, and personal health assistants may be read in a mixed manner, resulting in cross-role state interference. Second, when the mobile terminal is in the background, the network is interrupted, or asynchronous events are repeatedly delivered, the user's recovery operation may be executed repeatedly, resulting in multiple replies or multiple state writes. Third, when there is a lack of unified correlation between tasks awaiting human interaction, activity agendas, agent operations, and digital twin snapshots, later recovery results may overwrite newer snapshots. Fourth, if the client only displays the local pending state without retrieving the server-side state by pressing the range key when recovering in the foreground, closed tasks may be displayed as incomplete, or the states of other role sessions may be displayed on the current screen.

[0004] The root cause of the aforementioned problems is not the generation of a single dialogue text, but rather the lack of a verifiable data flow bounded by range keys among mobile terminals, session services, asynchronous worker processes, memory services, and snapshot storage, as well as the lack of recovery control information that can correlate runs, to-dos, agendas, and snapshot versions. Therefore, a technical solution is needed that balances access boundaries, duplicate deliveries, obsolete writes, and client-side recovery. Summary of the Invention

[0005] Technical problems to be solved

[0006] This invention aims to solve the following technical problems:

[0007] 1. How to isolate messages, to-dos, memories, and snapshots across multiple roles such as personal health assistant, family guardian, and service account to avoid cross-role reads or writes;

[0008] 2. How to establish a verifiable association between to-dos, activity agendas, runs, and snapshot versions while the agent is waiting for human interaction, so as to restore the correct processing context after the user provides supplementary information;

[0009] 3. How to prevent duplicate replies and overwriting of old snapshots under network retries, duplicate message delivery, client foreground / background switching, and concurrent recovery scenarios;

[0010] 4. How to make the mobile terminal refresh the agent's running status and digital twin snapshot only under the corresponding range key, and identify outdated snapshots.

[0011] Technical solution

[0012] To address the aforementioned issues, this invention employs a data processing link comprised of session context, scope isolation, manual to-do list, recovery descriptor, scoped memory, versioned snapshot, idempotent events, and mobile terminal synchronization.

[0013] A session context includes at least the user identifier U, session type CT, session identifier CID, and range key SK, and can be represented as:

[0014] C = {U, CT, CID, SK}

[0015] The range key SK is the primary state partitioning key in this invention. For a personal health assistant session, SK can be xiaoFu: user identifier or its equivalent; for a family guardian session, SK can be familyGuardian: target member identifier; for a service account session, SK can be serviceAccount: service account identifier. The session identifier CID is used to locate the message container, and the range key SK is used to isolate the running, activity agenda, snapshot, and display states. Both are used together for access verification and recovery verification.

[0016] When the agent requires manual input of results, the system creates a manual task T, an activity agenda A, and a run record R, and generates a recovery descriptor D. The recovery descriptor can be represented as:

[0017] D = {v, UHash, CT, CID, SK, RID, TID, AID, SV, SD, nonce, expiresAt,tag}

[0018] Where v is the descriptor version, UHash is the user identifier processed by hashing or other protection methods, RID is the run identifier, TID is the pending identifier, AID is the agenda identifier, SV is the current snapshot version, SD is the current snapshot digest value, nonce is the recovery random number, expiresAt is the expiration date, and tag is the integrity verification tag. The tag can be generated using message authentication codes, digital signatures, or other verification methods capable of verifying descriptor integrity. The recovery descriptor does not need to expose all internal fields to the client; in one implementation, the client only stores a protected reference used for the recovery request, while the server stores the complete descriptor.

[0019] The current snapshot summary value SD can be calculated from the following fields:

[0020] SD = H(SK || SV || AID || TID || agendaState || pendingTaskState)

[0021] Here, H is a hash function or equivalent digest function. Therefore, when the agenda pointed to by the recovery request has been closed, the pending task has been replaced, or the snapshot has been advanced, the server can detect that the state on which the request is based is inconsistent with the current state, reject stale writes, and return the latest state.

[0022] In one implementation, a digital twin snapshot includes a snapshot identifier, a user identifier, a range key, a snapshot version, summary data, a current flag, a source event identifier, and a creation time. For the same user and range key, writing a new snapshot is conditional on the old snapshot version SV: if the condition is met, the old snapshot's current flag is set to a non-current flag, and a new current snapshot with version SV+1 is written; if the condition is not met, no writing is performed, and a conflict is returned. This process can be completed within the same database transaction or with the aid of unique constraints and conditional updates, thereby preventing two concurrent recovery operations from simultaneously marking different snapshots as current.

[0023] Memory retrieval generates a memoryScope based on session type and range key. Family Guardian sessions use a memoryScope at the family member level, service account sessions use a memoryScope at the service account level, and personal health assistant sessions use a memoryScope at the individual level. The recovery process only queries candidate memories within the same memoryScope, using the range key as an additional filter or metadata validation condition. This ensures that even if multiple role sessions are opened sequentially on the same device, the health management context of one role will not be used as recovery input for another role.

[0024] For asynchronous processing, the server identifies duplicate requests using message deduplication keys, result deduplication keys, or recovery deduplication keys. If a record has already been generated for the same session, message role, and deduplication key, the server returns the existing record. Recovery events requiring asynchronous distribution are first placed in the outbox, which has pending, published, and failed states. The state is updated only after the event is successfully published; if publication fails, the reason for the failure is retained and retry is allowed. This design ensures that network timeouts or client retransmissions do not directly cause duplicate agent execution.

[0025] The mobile terminal requests both the snapshot and the running status simultaneously, using a range key as a parameter. The mobile terminal re-requests after returning to the foreground from the background, reaching the polling cycle, submitting a manual result, or receiving a recovery completion notification. The client displays the status as "processing," "awaiting manual intervention," or "completed" based on the running status and activity agenda status. When the snapshot's generation time exceeds a stale threshold from the current time, the client marks it as stale and continues to request a new status without using that snapshot as a recovery parameter.

[0026] Beneficial effects

[0027] Compared with solutions that save state only by user or only by session text, the present invention has at least the following technical advantages:

[0028] 1. By combining session type, session identifier, and range key partitioning, as well as family relationship verification and ranged memory mapping, the probability of read or write state crosstalk between multi-role sessions is reduced;

[0029] 2. By binding runs, to-dos, agendas, snapshot versions, and snapshot summary values ​​to recovery descriptors, it is possible to detect stale states such as task replacements, closed agendas, and updated snapshots before recovery;

[0030] 3. By using idempotent flags, conditional state transitions, and outbox retries, the probability of duplicate runs, duplicate replies, and duplicate snapshot writes caused by network retries and at least one event delivery is reduced;

[0031] 4. By versioning the current snapshot and refreshing the foreground and background based on a range key, the probability of stale writes being overwritten and the client displaying error states during concurrent recovery is reduced;

[0032] 5. This solution does not rely on fixed business rules to judge session content, but provides an implementable computer processing mechanism for data addressing, consistency verification and state synchronization issues in cross-terminal, cross-service and asynchronous recovery. Attached Figure Description

[0033] Figure 1 This is an overall architecture diagram of multi-role health agent sessions, range isolation, and human-in-the-loop recovery provided in embodiments of the present invention.

[0034] Figure 2 This is a schematic diagram illustrating the mapping relationship between session type, session identifier, range key, and memory range provided in an embodiment of the present invention.

[0035] Figure 3 This is a diagram illustrating the association structure of manual to-do lists, activity agendas, operation records, and recovery descriptors provided in embodiments of the present invention.

[0036] Figure 4 A flowchart illustrating the processing of submitting manual interaction results and explicit response requests provided in this embodiment of the invention.

[0037] Figure 5 A flowchart illustrating the conditional update process for a versioned digital twin snapshot provided in this embodiment of the invention.

[0038] Figure 6 This is a flowchart illustrating how to refresh snapshots and running status when switching between foreground and background on a mobile terminal, as provided in an embodiment of the present invention. Detailed Implementation

[0039] The present invention will be further described below with reference to the accompanying drawings and embodiments. The embodiments are used to illustrate the present invention and not to limit the scope of protection of the present invention. Unless otherwise stated, the term "current" snapshot refers to a snapshot with a current flag under the same user and the same range key.

[0040] Example 1: Scoped Session Context Generation and Access Verification

[0041] like Figure 1 and Figure 2 As shown, when a user enters the health agent interface or submits a message, the mobile terminal's session context generation module obtains the user identifier U, session type CT, session identifier CID, and range key SK. For the personal health assistant, the CID can be the user identifier or a session identifier stably generated by the client; for the family guardian, the CID can be a combination of the current user identifier and the protected member identifier in lexicographical order; for the service account, the CID can be a combination of the current user identifier and the service account identifier.

[0042] To avoid creating two sessions for the same family member due to different input orders, the client or server uses deterministic ordering for family guardian sessions. For example, when the current user is u001 and the target member is u002, the CID is uniformly u001_u002. The range key preserves the target context, such as familyGuardian:u002. In this way, the CID is used for stable addressing of message containers, and the SK is used for isolation of the operation, agenda, snapshot, and interface state related to the guardian member.

[0043] Upon receiving a request, the server first queries the session owner based on the CID. If the session owner is not the currently authenticated user, access is denied. For family guardian sessions, the server also parses the target member's identifier from the SK and queries the valid follow relationship between the current user and the target member. Only when both ownership and relationship verifications pass will the server allow reading session messages, activity agendas, running status, or snapshots. Service account sessions and personal health assistant sessions use corresponding account ownership or user ownership verification.

[0044] Example 2: Generating Manual To-Do Lists and Resume Descriptors

[0045] like Figure 3 As shown, when the agent runs R and handles health management interactions, it can request the user to supplement the results instead of assuming that the measurement results do not exist. The system creates a to-do item T, with the initial state being pending. Simultaneously, the system queries unclosed activity agendas using SK; if an agenda with the same topic exists, its AID is reused; otherwise, a new agenda is created. Agendas with human to-do items have the state waiting_human.

[0046] The system then generates a recovery descriptor D. For example, if the current snapshot version is 12, the activity agenda is `agenda_a`, the to-do list is `task_b`, and the run log is `run_c`, the server calculates:

[0047] SD = SHA-256("familyGuardian:u002|12|agenda_a|task_b|waiting_human|pending")

[0048] It also generates a nonce with a limited validity period and an integrity verification tag. The recovery descriptor allows subsequent requests to locate the recovery object not only with a confusing session identifier, but also by binding it to a specific run, to-do, agenda, and snapshot state.

[0049] In the implementation of mobile terminal network interruption, the mobile terminal can cache protected recovery references, CID, SK, TID, and generation time, instead of caching the original health data or complete memory content. During recovery, the state is reread from the server and the descriptor is verified, reducing the risk of local cache being modified and directly driving recovery execution.

[0050] Example 3: Manual Result Submission and Explicit Reply

[0051] like Figure 4 As shown, the present invention can provide two types of recovery entry points.

[0052] The first category is the result entry point. The mobile terminal submits structured resultData, such as user-confirmed results, equipment measurement summaries, or manually entered results, along with CT, CID, SK, a result deduplication key, and an optional recovery descriptor reference. The server saves messages with the user role and the message type "result," creates a run record with the trigger type "result," and places the result summary into the run context for subsequent processing by asynchronous worker processes.

[0053] The second type is explicit recovery entry. The mobile terminal submits the RID, TID, SK, and recovery descriptor reference. The server reads the original execution based on the RID and compares its U, CID, and SK. After verification, the asynchronous worker process loads the current activity agenda, scoped memory, and current snapshot under the SK, constructing a recovery context including resumeAfterHuman, RID, TID, AID, and whether new results exist. Recovery processing does not recreate irrelevant human tasks; when no new human results exist, the recovery context explicitly indicates the lack of new facts, avoiding writing unacquired data to the response or snapshot.

[0054] Both types of entry points can suppress duplicate calls using the recovery deduplication key. For the same recovery deduplication key, the system returns the already created run or the already generated recovery response. If a recovery event fails to be sent on the message bus, the sender retains the event's state and the reason for failure, and the publisher retryes in a subsequent cycle instead of requiring the mobile terminal to generate another manual result.

[0055] Example 4: Ranged Memory Read and Retrieval Execution

[0056] Before resuming execution, the system calculates the memoryScope based on CT and SK. The Personal Health Assistant uses `self`; the Family Guardian uses `family:target member identifier`; and the Service Account uses `service:service account identifier`. When retrieving candidate memories, database queries and sorting are limited to `U` and `memoryScope`, and the SK in the record's metadata can be further verified.

[0057] Suppose a user has personal schedule-related memories in their personal health assistant and device-related memories in their family guardian session. When a restore request is received for familyGuardian:u002, the system only retrieves candidate memories under family:u002, without using the personal schedule memory as the restore context for that member's pending task. This mechanism is a data addressing and access isolation mechanism that does not rely on the presence of identical keywords in natural language.

[0058] The recovery processing module inputs the current memory, current activity agenda, result summary, and current snapshot into the agent processing component. The processing component generates a recovery response and its structured metadata. Subsequently, the system creates a recovery processing step record, updates the running status, and updates the activity agenda from waiting_human to closed or another completed status. If result verification fails, the run does not exist, or agent processing fails, the system retains the pending task or marks the run as failed, without writing the failed result into a new current snapshot.

[0059] Example 5: Versioned Snapshot Conditional Update

[0060] like Figure 5 As shown, snapshot writing uses conditional updates. Upon initiation of recovery, the system reads the current snapshot S12, which is version 12. The SV in the recovery descriptor is also 12, and the SD matches the server-computed value. The system executes within a transaction or an operation with equivalent atomicity:

[0061] 1. Check if (U, SK, currentSnapshotVersion, agendaState) is still equal to (U, SK, 12, waiting_human);

[0062] 2. Mark S12 as non-current;

[0063] 3. Insert a new snapshot S13 of version 13, which includes the current running status, agenda, pending status, source event identifier, and recovery time;

[0064] 4. Submit the status transition.

[0065] If another recovery operation has already written to S13, and the version check of the subsequent operation fails, the system will not overwrite S13. Instead, it will return the conflict code and the current version 13, allowing the mobile terminal to reacquire its running state. To improve database-level guarantees, a unique constraint can be established for (user_id, scope_key, is_current) allowing only one current snapshot, or an equivalent constraint can be implemented through a dedicated current pointer table and version field.

[0066] Example 6: Mobile Terminal Status Refresh

[0067] like Figure 6As shown, when a mobile terminal enters a session, returns to the foreground from the background, or reaches a polling cycle, it uses the same U, CT, CID, and SK to request digital twin snapshots and running status in parallel. The display layer maps an activity agenda of waiting_human or a running status of waiting_human to waiting for human intervention, a running status of running to processing, and an agenda of closed or a running status of completed to completed.

[0068] The mobile terminal also compares the snapshot generation time with the current time. If the interval exceeds the configured staleness threshold, the terminal marks the snapshot as stale and continues to refresh instead of using the stale snapshot to drive the recovery. If the manual result submission is successful, the terminal updates the local display using the RID, AID, SK, and new snapshot version returned by the server; if a conflict is returned, the terminal discards the locally stored recovery state and retrieves the server state again by pressing SK.

[0069] Example 7: System, Device, and Storage Medium

[0070] This invention can also be implemented as a system consisting of a mobile terminal, a session service, an asynchronous worker process, a database, a caching service, and a messaging service. The mobile terminal can be a mobile phone, tablet, or other terminal with network communication capabilities; the server can be implemented by one or more physical servers, virtual machines, or containerized services. The session service is responsible for authentication, session and message persistence; the asynchronous worker process is responsible for agent operation, task creation, recovery processing, and snapshot updates; the database is responsible for storing sessions, agendas, tasks, memories, and snapshots; and the messaging service is responsible for transmitting run requests and recovery events.

[0071] Electronic devices include processors, memory, and communication interfaces. When a program stored in memory is executed by the processor, it can perform tasks such as session context generation, range verification, recovery descriptor verification, memory retrieval, snapshot condition updating, event retrieval, and mobile terminal synchronization. Computer-readable storage media can be non-volatile memory, flash memory, solid-state memory, magnetic disk, optical disk, or other media capable of storing program instructions.

Claims

1. A method for range isolation, human-in-the-loop recovery, and consistent snapshot processing in multi-role health agent sessions, characterized in that, include: The mobile terminal or access gateway obtains the user identifier, session type (conversationType), session identifier (conversationId), and scope key (scopeKey), wherein the session type includes at least a personal health assistant session, a family guardian session, and a service account session; the session identifier and scope key are normalized according to the session type and the target member identifier or service account identifier; the server performs session ownership verification and access relationship verification based on the user identifier, session type, session identifier, and scope key, and associates the session message, agent operation record, activity agenda, manual tasks, memory items, and digital twin snapshot to the scope key respectively; when the agent operation requires manual supplementation of measurement results, confirmation results, or other interaction results, a task record is created, the activity agenda corresponding to the task record enters a waiting state for manual intervention, and a recovery descriptor is generated; the recovery descriptor includes at least the run identifier (runId), task identifier (taskId), agenda identifier (agendaId), scope key, current snapshot version, current snapshot digest value, and validity period; The system receives a result request carrying the result of a human interaction or a recovery request carrying a running identifier and a to-do identifier, and verifies the user affiliation, range key, recovery descriptor, idempotency identifier, and validity period of the request. Upon successful verification, it retrieves the current memory item only within the memory range corresponding to the range key and reads the current digital twin snapshot corresponding to the range key. A recovery context is generated based on the human interaction result or recovery request. The system performs agent recovery processing according to the recovery context, conditionally updates the status of the activity agenda and to-do records, generates a recovery response, and writes a new digital twin snapshot version with the current snapshot version as the preceding version. The system returns the recovery response, activity agenda status, and new digital twin snapshot version to the mobile terminal, enabling the mobile terminal to refresh the interface status under the corresponding range key.

2. The method according to claim 1, characterized in that, The standardization of session identifiers and range keys includes: When the session type is a family guardian session, concatenating the current user identifier and the target member identifier in a predetermined order to form the session identifier, and using "familyGuardian:target member identifier" or a range key containing an equivalent target member identifier; When the session type is a service account session, generating a session identifier based on the combination of the current user identifier and the service account identifier, and using "serviceAccount:service account identifier" or a range key containing an equivalent service account identifier; When the session type is a personal health assistant session, generating a range key using the current user identifier or a specified personal session identifier; and mapping the memory ranges of family guardian sessions, service account sessions, and personal health assistant sessions to family:target member identifier, service:service account identifier, and self, respectively, to prevent mixed retrieval of memory candidates between different session types.

3. The method according to claim 1, characterized in that, The session ownership verification and access relationship verification include: querying the owner user ID, session type, and range key in the session record; when the session type is a family guardian session, querying the follow relationship in a valid state based on the current user ID and the target member ID parsed from the range key; when the session owners are inconsistent or the follow relationship is invalid, refusing to read session messages, running status, activity agenda, digital twin snapshots, and memory items.

4. The method according to claim 1, characterized in that, The recovery descriptor also includes a recovery random number, a descriptor version, and an integrity verification tag; wherein, the current snapshot digest value is calculated from the range key, snapshot version, activity agenda identifier, to-do identifier, and status digest of the current digital twin snapshot; the integrity verification tag is calculated by the server based on the recovery descriptor; the verification includes comparing the range key, running identifier, to-do identifier, current snapshot version, and current snapshot digest value in the recovery request with the values ​​saved by the server, and verifying the integrity verification tag and validity period.

5. The method according to claim 1, characterized in that, The conditional update includes: for the same range key, using the snapshot version and event agenda status as conditions, performing a state transition from a waiting-for-human interaction state to a restored or closed state; when the to-do identifier, snapshot version, or event agenda status is inconsistent with the current record on the server, the human interaction result is refused to be written to the digital twin snapshot, and a conflict state and the current snapshot version are returned; when the state transition is successful, the previous digital twin snapshot is marked as not the current snapshot, and a new current digital twin snapshot containing the new snapshot version, running identifier, event agenda status, to-do status, source event identifier, and recovery timestamp is written; wherein, only one current digital twin snapshot is retained for the same user and the same range key at any given time.

6. The method according to claim 1, characterized in that, The idempotency identifier includes at least one of message deduplication key, recovery deduplication key, or result deduplication key; before writing a message or recovery result, the server queries existing records with the same session identifier, the same role, and the same idempotency identifier; when an existing record is found, the existing record is returned without recreating the run record, to-do record, activity agenda, recovery reply, or digital twin snapshot; when asynchronous distribution of a recovery event fails, the recovery event is saved in the outbox and its pending, published, or failed status is recorded for retrying distribution.

7. The method according to claim 1, characterized in that, The mobile terminal refresh interface status includes: pressing the range key to acquire the digital twin snapshot and the agent's running status in parallel; reacquiring the digital twin snapshot and the agent's running status when the mobile terminal switches from the background to the foreground, reaches the polling cycle, or completes the recovery request; determining the display status as idle, processing, waiting for manual intervention, or completed based on the activity agenda status, running status, and snapshot generation time; and marking the snapshot as outdated and not using it as the current recovery context when the snapshot exceeds a preset staleness threshold.

8. A system for range isolation, human-in-the-loop recovery, and consistent snapshot processing for multi-role health intelligent agent sessions, characterized in that: include: The session context generation module is used to generate or normalize user identifiers, session types, session identifiers, and range keys; The access isolation module is used to perform access relationship verification based on session owner, session type, range key, and family attention relationship; the operation and agenda module is used to create agent operation records, human to-do records, and activity agendas, and to put activity agendas with human to-dos into a waiting human state; The recovery descriptor module is used to generate and verify recovery descriptors that include run identifier, to-do identifier, agenda identifier, range key, snapshot version, snapshot digest value, validity period, and integrity verification tags; the ranged memory and snapshot module is used to retrieve memory items by range key and memory range, and maintain the current digital twin snapshot of the same user and the same range key; The recovery execution module is used to receive the results of manual interaction or recovery requests, generate recovery context and recovery response after successful verification, and conditionally update the activity agenda, to-do list and digital twin snapshot version. The idempotency and event dispatch module is used to avoid duplicate processing based on idempotency identifiers and to save recovery events that are to be dispatched, dispatched, or dispatched but failed through a stateful sender box; the mobile terminal synchronization module is used to return snapshots, running status, activity agenda status, and recovery results by pressing the range key.

9. An electronic device, characterized in that, The device includes a processor, a memory, and a communication interface. The memory stores a computer program, and the communication interface is used to communicate with a mobile terminal, a messaging service, or a database. When the computer program is executed by the processor, the electronic device enables the electronic device to implement the method described in 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 described in any one of claims 1 to 7.

Images