Session control method, system, device and medium based on thread-level authorization lease

Abstract

The application provides a session control method, system, device and medium based on thread-level authorization lease, the method comprising: listening to a detection event in a session type graphical interface and generating a session thread identification; establishing an authorization lease for a target session thread based on the session thread identification; in response to detecting that there is pending session content in the target session thread, generating candidate reply content; performing risk determination on the candidate reply content, and determining an execution action on the current target session thread according to the result of the risk determination, the state of the authorization lease and the thread state of the target session thread; wherein the execution action is any one of automatic sending, draft generation, pre-filling or blocking; if automatic sending fails, the authorization lease of the target session thread is revoked, and a preset recovery operation is performed. The application can solve the problems of lack of thread-level authorization control, insufficient failure recovery and difficulty in managing model output risks in existing session automation.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence and graphical interface session technology, specifically relating to a session control method, system, device and medium based on thread-level authorization lease. Background Technology

[0002] With the development of AI assistants and graphical interface intelligent agents, systems can automatically generate replies, pre-fill content, and even send messages automatically in messaging, email, and collaboration platforms. Compared to conventional page navigation automation, conversational automation carries higher risks: accidental sending can directly output incorrect information, causing irreparable consequences; the same user often needs different automation permissions in different conversation threads, such as allowing automatic sending for internal collaborations and generating only drafts for customer communication; if permissions are not adjusted in time after a single sending failure, it can easily lead to continuous errors; continuous automatic sending at night, during quiet periods, or after exceeding sending limits will significantly increase business and compliance risks; relying solely on global switches, unified draft modes, or centralized manual confirmation makes it difficult to achieve an effective balance between security and efficiency.

[0003] Existing technologies generally lack a comprehensive governance mechanism that integrates authorization validity, failure revocation, sending cooldown, silent period control, sending volume limits, and AI context risk assessment at the session thread level. Especially in scenarios where large language models are introduced to automatically generate responses, there is still a lack of mature and feasible engineering solutions for incorporating model outputs into the thread-level risk management system.

[0004] Therefore, there is an urgent need for a technical solution that is designed for continuous conversation automation scenarios and balances the application capabilities of artificial intelligence with governance security. Summary of the Invention

[0005] This application provides a session control method, system, device, and medium based on thread-level authorization leases to solve the problems of lack of thread-level authorization control, insufficient failure recycling, and difficulty in managing model output risks in existing session automation.

[0006] In a first aspect, this application provides a session control method based on thread-level authorization leases, comprising: listening to detection events in a session-type graphical interface, extracting session feature information from the detection events, and generating a session thread identifier based on the session feature information; in response to receiving a user's approval operation instruction for a target session thread, establishing an authorization lease for the target session thread based on the session thread identifier; in response to detecting that there is pending session content in the target session thread, generating candidate response content; performing risk assessment on the candidate response content, and determining an action to be performed on the current target session thread based on the result of the risk assessment, the status of the authorization lease, and the thread-level governance status of the target session thread; wherein the action to be performed is any one of automatic sending, draft generation, pre-filling, or blocking; if automatic sending fails after executing the automatic sending action, revoking the authorization lease of the target session thread and performing a preset recycling operation.

[0007] In one implementation of the first aspect, the step of extracting session feature information from the detection event and generating a session thread identifier based on the session feature information includes: extracting interface metadata, session context information, and session input information from the detection event; concatenating the interface metadata, session context information, and session input information to form a feature string; performing hashing, structured encoding, or a combination thereof on the concatenated feature string to generate a session thread identifier for identifying the session thread; and when a conflict in the session thread identifier is detected, performing disambiguation processing based on the window instance identifier, message timestamp, or sequence number to obtain the session thread identifier.

[0008] In one implementation of the first aspect, the step of establishing an authorization lease for the target session thread based on the session thread identifier in response to receiving a user's approval operation instruction for the target session thread includes: in response to receiving a user's approval operation instruction for the target session thread, obtaining the session thread identifier corresponding to the target session thread; constructing an authorization lease based on the session thread identifier, wherein the authorization lease includes at least the session thread identifier, approval time, expiration time, associated task identifier, and revocation time, wherein the initial value of the revocation time is set to none, and the expiration time is calculated from the current time and a preset validity period; persistently storing and outputting the authorization lease.

[0009] In one implementation of the first aspect, generating candidate response content in response to detecting that there is unprocessed session content in the target session thread includes: in response to detecting that there is unprocessed session content in the target session thread, obtaining the associated information of the target session thread; the associated information includes at least one or more combinations of session history, current message content, user style preferences, and task context; invoking a pre-configured generative language model, inputting the associated information into the generative language model, and having the generative language model output the candidate response content.

[0010] In one implementation of the first aspect, the step of risk assessment of the candidate response content and determining the action to be performed on the current target session thread based on the risk assessment result, the status of the authorization lease, and the thread-level governance status of the target session thread includes: obtaining input information required for risk assessment, the input information including candidate response text, session context, and thread status of the target session thread; calculating a rule risk score through a rule engine and a model risk score through a large language model based on the input information, and performing a fusion calculation on the rule risk score and the model risk score, obtaining a fusion risk score by weighted summation based on a preset fusion coefficient, and using it as the result of risk assessment; and determining the action to be performed on the current target session thread based on the fusion risk score, the thread-level governance status of the target session thread, default configuration parameters, and the validity of the thread authorization lease.

[0011] In one implementation of the first aspect, the step of calculating the rule risk score through the rule engine includes: performing keyword matching and pattern detection on the candidate response text to obtain a keyword matching score and a pattern detection score, respectively; obtaining the historical failure count in the thread state of the target session thread, and calculating a historical failure weighted score based on the historical failure count; obtaining the maximum value between the keyword matching score and the pattern detection score, and adding the maximum value to the historical failure weighted score to obtain an initial rule risk score; and performing normalization or upper / lower limit pruning on the initial rule risk score so that the initial rule risk score is in the [0,1] interval to obtain the final rule risk score.

[0012] In one implementation of the first aspect, the step of calculating the model risk score through a large language model includes: constructing risk judgment prompt words based on the task objective, conversation summary, candidate reply text, and recent failure reason in the thread state of the target conversation thread of the conversation context; inputting the risk judgment prompt words into the large language model, and having the large language model output a model risk score in the range [0,1].

[0013] In one implementation of the first aspect, determining the action to be performed on the current target session thread based on the fusion risk score, the thread-level governance state of the target session thread, the default configuration parameters, and the validity of the thread authorization lease includes: checking whether the target session thread meets session constraints based on the thread-level governance state and default configuration parameters of the target session thread, wherein the session constraints include a first type of mandatory constraints and a second type of automatic sending restriction constraints; wherein the first type of mandatory constraints includes authorization expiration and the thread requiring re-approval, and the second type of automatic sending restriction constraints includes being in a silent period, reaching the daily automatic sending limit, and the thread being in cooldown; if the first type of mandatory constraints are met, the action to be performed is blocking; if the second type of automatic sending restriction constraints are met, the thread is prohibited. The system executes an automatic sending action, and determines the action as one of draft generation, pre-filling, or blocking according to the specific type of the session constraint. If no session constraint is met, it determines whether the fusion risk score is greater than or equal to a preset high-risk threshold: if yes, the action is blocked; if no, it checks whether the thread authorization lease is valid: if the thread authorization lease is invalid, the action is pre-filling; if the thread authorization lease is valid, it determines the relationship between the fusion risk score and the preset low-risk and high-risk thresholds: if the fusion risk score is less than the preset low-risk threshold, the action is automatic sending; if the fusion risk score is greater than or equal to the preset low-risk threshold and less than the preset high-risk threshold, the action is draft generation.

[0014] In one implementation of the first aspect, when an automatic sending failure is detected after the automatic sending action is performed, revoking the authorization lease of the target session thread and performing a preset recycling operation includes: when an automatic sending failure event is detected in the target session thread, setting the revocation time of the authorization lease associated with the target session thread to the current time, revoking the authorization lease of the target session thread, and performing any one or more combinations of the following preset recycling operations: incrementing the failure count in the thread state by 1 to update the failure count; recording the sending failure reason in the recent failure reason field of the thread state to retain the failure basis; calculating the cooldown end time based on a preset cooldown duration and setting the cooldown end time in the thread state to perform cooldown control on the target session thread; determining whether the failure count in the thread state has reached a preset maximum consecutive failure count; if so, marking the target session thread as needing re-approval in the thread state and recording the current time as the upgrade time; if not, not marking the target session thread as needing re-approval and retaining the updated failure count, the recent failure reason field, and the cooldown end time.

[0015] In one implementation of the first aspect, the method further includes determining whether to block the automatic sending operation of the target session thread, including: obtaining the thread state and default configuration parameters of the target session thread, wherein the default configuration parameters include the start time of the silent period, the end time of the silent period, and the daily automatic sending limit; the thread state includes the daily automatic sending count, the cooldown end time, and a re-approval flag; configuring multiple control conditions based on the thread state and the default configuration parameters, and performing condition judgment on the target session thread based on the multiple control conditions in sequence; if any condition is met, it is determined that the automatic sending operation of the target session thread needs to be blocked; if all conditions are not met, it is determined that the automatic sending operation of the target session thread does not need to be blocked.

[0016] Secondly, this application provides a session control system based on thread-level authorization leases, comprising: a detection event monitoring module for monitoring detection events in a session-type graphical interface; a thread identifier generation module for extracting session feature information from the detection events and generating a session thread identifier based on the session feature information; a lease authorization module for establishing an authorization lease for the target session thread based on the session thread identifier in response to receiving a user's approval operation instruction for the target session thread; a candidate reply content generation module for generating candidate reply content in response to detecting unprocessed session content in the target session thread; and a risk determination module for determining the risk of the candidate reply content. The action determination module is used to determine the action to be performed on the current target session thread based on the risk assessment result, the status of the authorized lease, and the thread-level governance status of the target session thread; wherein the action to be performed is any one of automatic sending, draft generation, pre-filling, or blocking; the governance constraint module is used to determine whether to block the automatic sending operation of the target session thread based on the start time of the silent period, the end time of the silent period, the daily automatic sending limit, the cooldown end time, and whether a re-approval flag is required; the recycling processing module, if an automatic sending failure is detected after the automatic sending action is performed, revokes the authorized lease of the target session thread and performs a preset recycling operation.

[0017] Thirdly, this application provides an electronic device, the electronic device comprising: a memory storing a computer program; and a processor communicatively connected to the memory, which executes the session control method based on thread-level license lease as described above when the computer program is invoked.

[0018] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the session control method based on thread-level license leases described above.

[0019] As described above, the session control method, system, device, and medium based on thread-level authorization leases described in this application can solve the problems of lack of thread-level authorization control, insufficient failure recycling, and difficulty in managing model output risks in existing session automation, and has the following beneficial effects:

[0020] First, this application enables precise automated permission control down to specific session threads, achieving one-to-one binding of permissions with a single session. This fundamentally avoids the abuse of permissions and the spread of risks across sessions caused by global delegation of permissions, and solves the technical defects of existing technologies, such as insufficient granularity of permission control and difficulty in isolating risks.

[0021] Second, this application establishes a closed loop of full-process governance by limiting the validity period of automatically sent permissions through an authorized lease, which enables dynamic control and real-time revoke of permissions. This ensures the efficiency of automated compliant sessions while eliminating the security risks of long-term permission persistence, thus solving the technical problems of existing technology's lack of a closed loop and insufficient dynamic control capabilities in permission governance.

[0022] Third, this application incorporates candidate responses generated by a large language model into a pre-risk assessment process. Only low-risk content with valid leases can be automatically sent, medium-risk content generates drafts, and high-risk content is directly blocked. This avoids model illusions and the unconditional direct output of illegal content, thus solving the technical problems of insufficient risk verification and inadequate security in existing automated responses.

[0023] Fourth, this application immediately revokes the authorization lease of the session thread after automatic transmission fails, and simultaneously performs recovery operations such as failure count accumulation, cooling control, and re-approval marking, quickly cutting off automation permissions, greatly reducing the probability of continuous error output, and solving the technical problem of lack of effective control after failure and continuous accumulation of error risk in the prior art.

[0024] Fifth, this application integrates multiple governance constraints such as silent periods, daily automatic sending limits, and thread cooldown states, and combines risk assessment results with lease status to execute differentiated action decisions. It can flexibly adjust the execution strategy according to the scenario, maximize automation efficiency while ensuring safety, and solve the technical problems of existing technologies having a single governance dimension and difficulty in balancing safety and efficiency.

[0025] Sixth, this application adopts a risk assessment mechanism that integrates a rule engine and a large language model. It ensures the accuracy of basic prevention and control through deterministic rules and enhances semantic understanding capabilities through a large language model. It takes into account both rule determinism and semantic analysis capabilities, and can be adapted to a variety of complex risk scenarios. It solves the technical problem that the existing technology has a single risk assessment capability and is difficult to deal with complex scenarios. Attached Figure Description

[0026] Figure 1The diagram shown is a flowchart illustrating the session control method based on thread-level authorization leases as described in an embodiment of this application.

[0027] Figure 2 The diagram shows a flowchart illustrating the process of generating a session thread identifier in the session control method based on thread-level authorization leases as described in this application embodiment.

[0028] Figure 3 This diagram illustrates the principle of generating a session thread identifier in the session control method based on thread-level authorization leases as described in this application embodiment.

[0029] Figure 4 The diagram shows a flowchart illustrating the process of determining the execution action for a thread in the session control method based on thread-level authorization leases as described in this application embodiment.

[0030] Figure 5 The diagram shows the principle of candidate response generation, risk assessment, and action decision-making in the session control method based on thread-level authorization leases described in this application embodiment.

[0031] Figure 6 The diagram shows a flowchart illustrating the automatic transmission failure recovery and cooling process in the session control method based on thread-level authorization leases described in this application embodiment.

[0032] Figure 7 This diagram illustrates the principle of degraded execution under silent periods and daily action limits in the session control method based on thread-level authorization leases described in this application embodiment.

[0033] Figure 8 This diagram illustrates the principle structure of the session control system based on thread-level authorization leases as described in an embodiment of this application.

[0034] Figure 9 This diagram shows a schematic representation of the electronic device described in an embodiment of this application.

[0035] Component labeling explanation

[0036] 10 electronic devices 101 Memory 102 processor 103 monitor 100 Session control system based on thread-level authorization lease 110 Event monitoring module 120 Thread identifier generation module 130 Lease Authorization Module 140 Candidate Reply Content Generation Module 150 Risk assessment module 160 Execution Action Determination Module 170 Governance constraint module 180 Recycling module S100~S500 step S110~S130 step S410~S430 step Detailed Implementation

[0037] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0038] The following embodiments of this application provide a session control method, system, device, and medium based on thread-level authorization leases, which are used to solve the technical problems of lack of thread-level authorization control, insufficient failure recycling, and difficulty in managing model output risks in existing session automation.

[0039] This application provides a session control method, system, device, and medium based on thread-level authorization leases, belonging to the fields of artificial intelligence, session automation control, and computer security governance technology. It is applied to session-based graphical interfaces, including at least one of real-time messaging applications, email applications, collaboration platform applications, and social media applications, to achieve full-process security control of automated session operations in such scenarios. This embodiment uses thread-level authorization leases as its core, assigning a unique identifier to each session thread and establishing an authorization lease (approval before authorization). After generating candidate responses, risk assessment is performed through a fusion of a rule engine and a large language model. The execution action is determined by combining lease status, thread status, and multi-layered governance constraints. If automatic sending fails, the lease is immediately revoked, and cooling-off and re-approval operations are performed, forming a full-process governance loop. This embodiment enables fine-grained permission control at the session thread level, effectively avoiding the risk propagation caused by global delegation of permissions. It establishes a lifecycle-wide permission governance loop through authorization leases. Simultaneously, it incorporates large-model generated content into the risk assessment process, significantly improving the security of automated responses. After a sending failure, permissions can be quickly revoked and control cooled down, reducing continuous error output. Furthermore, by integrating multi-layered governance constraints, it improves operational efficiency while ensuring the security of automated sessions, adapting to various complex session scenarios. Therefore, this embodiment provides a session control method based on thread-level authorization leases that can significantly reduce the risk of missending and continuous error sending while improving the efficiency of automated sessions.

[0040] The following will refer to the appendices in the embodiments of this application. Figure 1 To be continued Figure 9 The technical solutions in the embodiments of this application will be described in detail.

[0041] like Figure 1 As shown, this embodiment provides a session control method based on thread-level authorization leases, the method including the following steps S100 to S500.

[0042] Step S100: Listen to the detection events in the session-type graphical interface, extract session feature information from the detection events, and generate a session thread identifier based on the session feature information;

[0043] Step S200: In response to receiving the user's approval operation instruction for the target session thread, establish an authorization lease for the target session thread based on the session thread identifier;

[0044] Step S300: In response to detecting that there is unprocessed session content in the target session thread, generate candidate reply content;

[0045] Step S400: Perform risk assessment on the candidate response content, and determine the action to be performed on the current target session thread based on the result of the risk assessment, the status of the authorized lease, and the thread-level governance status of the target session thread; wherein, the action to be performed is any one of automatic sending, draft generation, pre-filling, or blocking;

[0046] Step S500: If automatic sending fails after the automatic sending action is performed, the authorized lease of the target session thread is revoked and a preset recycling operation is performed.

[0047] This embodiment extracts session feature information and generates session thread identifiers by listening to events detected by the session-based graphical interface, enabling precise differentiation and independent management of different session threads. It establishes authorization leases based on user-approved operations, allowing for controllable granting of session processing permissions and avoiding security risks associated with unauthorized automatic operations. For the content of the session to be processed, it generates candidate response content and, based on risk assessment results, authorization lease status, and session thread status, determines whether to perform actions such as automatic sending, draft generation, pre-filling, or blocking. This ensures session processing efficiency while effectively avoiding risks such as unauthorized sending of sensitive content and misoperation. When automatic sending fails, it revokes the authorization lease and performs a preset recycling operation, promptly releasing session resources and terminating abnormal session processes. This prevents invalid authorizations from continuously occupying system resources or causing duplicate processing and information leakage. Overall, it solves the technical problems of lack of permission control, difficulty in controlling content risks, imperfect exception handling mechanisms, resource waste, and insufficient operational security and standardization in the automatic processing of traditional session-based graphical interfaces. It achieves the technical effects of improving session processing security, controllability, and stability, optimizing interactive execution logic, reducing the risk of unauthorized operations and system anomalies, and ensuring efficient and orderly session processing.

[0048] The following provides a detailed description of steps S100 to S500 in the session control method based on thread-level authorization leases in this embodiment.

[0049] Step S100: Listen for detection events in the session-type graphical interface, extract session feature information from the detection events, and generate a session thread identifier based on the session feature information.

[0050] In this embodiment, the detected event includes, but is not limited to, information such as session summary, session context, messages to be processed, interface parsing results, and input parameters. The session feature information includes, but is not limited to, interface metadata, session context information, and session input information.

[0051] In this embodiment, the session-based graphical interface is monitored in real time to capture various detection events generated during the interface operation. These detection events include session summaries, session contexts, messages to be processed, interface parsing results, and input parameters. By collecting and integrating the above multi-dimensional event information, the overall state and interaction information under the current session interaction scenario are comprehensively obtained.

[0052] Based on this, session feature information is extracted from the collected detection events. This session feature information specifically includes interface metadata, session context information, and session input information. The interface metadata is used to characterize the inherent features of the session-type graphical interface, such as layout attributes, control identifiers, and window states. The session context information is used to record continuous content such as session interaction history, associated business scenarios, and dialogue logic relationships. The session input information is used to carry interactive data such as user input commands, pending message content, and parameter configuration items.

[0053] The corresponding session feature information is extracted from the above-mentioned detection events: interface metadata is extracted from the interface parsing results, including the application type, window identifier, control structure, and interface hierarchy information of the current interface; session context information is extracted from the session summary and session context, including the session topic, session history summary, session creation time, session status, and session environment parameters; session input information is extracted from pending messages and input parameters, including pending content features, user input commands, and automation execution related parameters. After extraction, a unique session thread identifier is generated based on the session feature information. The session thread identifier is generated based on stable session features available before the generation of candidate response content, excluding candidate response content subsequently generated based on the target session thread.

[0054] Figure 2 This diagram illustrates the process of generating a session thread identifier in the session control method based on thread-level authorization leases described in this application. Figure 2 As shown, in one implementation of this embodiment, the step of extracting session feature information from the detection event and generating a session thread identifier based on the session feature information includes the following steps S110 to S130.

[0055] Step S110: Extract interface metadata, session context information, and session input information from the detected event;

[0056] Step S120: The interface metadata, the session context information, and the session input information are concatenated to form a feature string;

[0057] Step S130: Hash, structured encoding or a combination thereof on the concatenated feature string to generate a session thread identifier for identifying the session thread; and when a conflict of session thread identifiers is detected, disambiguation processing is performed based on the window instance identifier, message timestamp or sequence number, which is the session thread identifier.

[0058] In this embodiment, the session thread identifier is generated by extracting stable and unique features from the detected events, normalizing, sorting, concatenating features and hashing, and generating a session thread identifier with uniqueness, stability and scene distinguishability, which is used to uniquely identify an independent dialogue scene.

[0059] Figure 3 This diagram illustrates the principle of generating a session thread identifier in the session control method based on thread-level authorization leases described in this application. Figure 3 As shown, specifically, the session thread identifier is generated by performing a hash operation after normalizing the application identifier, session channel identifier, participant set, and session context feature signature, as shown in the following formula:

[0060] ThreadID = hash(normalize(appId, channelId, participantSet,contextSignature))

[0061] Wherein, ThreadID is the session thread identifier, appId is the application identifier, channelId is the session channel identifier, participantSet is the participant set, and contextSignature is the session context signature.

[0062] The application identifier is obtained from the interface metadata and is used to uniquely identify different conversational applications such as messaging, email, or collaboration software. The conversation channel identifier is extracted from the conversation context information and is used to distinguish different chat windows, groups, channels, or email conversation directories. The participant set is parsed from the conversation context information and includes all user identifiers, account information, or role identifiers participating in the current conversation. The system performs sorting, deduplication, and other normalization processes on the participants to ensure that the same combination of participants can generate stable and consistent features. The conversation context feature signature is generated based on the compressed conversation context information and conversation input information and is used to characterize the content features and context uniqueness of the current conversation.

[0063] In this embodiment, the aforementioned interface metadata, session context information, and session input information are fused and encoded. Based on the default identifier generation rules, a unique corresponding session thread identifier is generated for the current independent session interaction process. This session thread identifier can uniquely identify different session threads, enabling accurate differentiation and independent tracking of multiple concurrent sessions and multi-scenario sessions. This provides a unified and unique index for subsequent session license management, content risk assessment, and execution action scheduling, ensuring that the logic of each session thread is independent and does not interfere with each other.

[0064] Step S200: In response to receiving the user's approval operation instruction for the target session thread, establish an authorization lease for the target session thread based on the session thread identifier.

[0065] In one implementation of this embodiment, the step of establishing an authorization lease for the target session thread based on the session thread identifier in response to receiving a user's approval operation instruction for the target session thread includes:

[0066] 1) In response to receiving a user's approval operation instruction for the target session thread, obtain the session thread identifier corresponding to the target session thread;

[0067] 2) Construct an authorization lease based on the session thread identifier.

[0068] In this embodiment, after receiving a user's approval operation for a target session thread, an authorization lease is established for the target session thread. The authorization lease includes at least the session thread identifier, approval time, expiration time, associated task identifier, and revocation time. The revocation time is initially set to none, and the expiration time is calculated from the current time and a preset validity period. The authorization lease is persistently stored and output. For example, the default validity period is 3600 seconds, and the associated task identifier is an optional parameter that can be set or left blank according to actual needs.

[0069] This embodiment also includes a valid lease authorization check step, specifically including:

[0070] 1) Based on the session thread identifier to be checked, retrieve the corresponding authorized lease from persistent storage;

[0071] 2) If no corresponding authorized lease is found, the found authorized lease has a non-empty cancellation time, or the current time exceeds the expiration time of the authorized lease, then the authorized lease is deemed invalid;

[0072] 3) If the corresponding authorized lease is found, the authorized lease revocation time is empty, and the current time has not exceeded the expiration time, then the authorized lease is deemed valid.

[0073] In this embodiment, the following formula is used to check whether the current thread's license lease is valid:

[0074] LeaseValid(t) = (t.approvedAt ≠ null) ∧ (now < t.expiresAt) ∧(t.revokedAt = null)

[0075] Where t represents the authorized lease record corresponding to the target session thread; t.approvedAt is the approval time of the authorized lease, a non-empty value indicates that the lease has been approved by the user; now is the current system time; t.expiresAt is the expiration time of the authorized lease, calculated by adding the preset validity period to the approval time; t.revokedAt is the revocation time of the authorized lease, initially empty, set to the revocation time when the lease is revoked. The above formula means that an authorized lease is considered valid if and only if the authorized lease has been approved, the current time has not exceeded the expiration time, and the lease has not been revoked.

[0076] In this embodiment, session detection events are continuously monitored in messaging applications, email applications, or collaboration platforms. Detection events may include information such as session summaries, session context, pending messages, interface parsing results, and input parameters. The system generates session thread identifiers based on interface metadata and context normalization to distinguish different session threads.

[0077] Once a user explicitly approves automatic sending in a specific thread, an authorization lease is established for that thread. This authorization lease has an expiration period and is only valid for the corresponding thread. Subsequently, during the validity period of the authorization lease, when the system detects similar pending sessions in the same thread, it can directly enter the automatic sending decision process without requiring user confirmation for each sending request.

[0078] For example, when a user approves automatic sending in a Slack internal collaboration channel, the system generates a ThreadID for that channel and creates a one-hour authorization lease. During this hour, new messages in the same channel can be processed automatically. After the lease expires, the system automatically reverts to draft mode, and automatic sending can only resume after the user re-approves the request.

[0079] Step S300: In response to detecting that there is unprocessed session content in the target session thread, generate candidate reply content.

[0080] When unprocessed session content is detected in the target session thread, candidate response content is generated. This candidate response content can be generated by a large language model or a multimodal model based on session history, user style preferences, and task context.

[0081] Specifically, in one implementation of this embodiment, the step of generating candidate response content in response to detecting that there is unprocessed session content in the target session thread includes:

[0082] 1) In response to detecting that there is pending session content in the target session thread, obtain the associated information of the target session thread; the associated information includes at least one or more combinations of session history, current message content, user style preferences, and task context;

[0083] 2) Call the pre-configured generative language model, input the associated information into the generative language model, and have the generative language model output candidate response content.

[0084] In this embodiment, in the automated session management process, in response to the detection of unprocessed session content in the target session thread, the process of generating candidate response content is initiated. The specific process is as follows: this process is based on the session thread identifier, detection event, and session feature information mentioned above, to ensure that the generated response content accurately matches the target session thread and conforms to the actual interaction needs.

[0085] First, in response to the detection of pending session content in the target session thread, the session link corresponding to the target session thread is located using the session thread identifier generated earlier, and then the associated information of the target session thread is obtained. The pending session content originates from pending messages, input parameters, and other related information extracted from the detection event. After the process method determines that a corresponding response needs to be generated, the acquisition of associated information is triggered. The associated information includes, but is not limited to, at least one or more combinations of session history, current message content, user style preferences, and task context. The specific acquisition methods and functions of each piece of associated information are as follows:

[0086] 1) Session History: Retrieves all interaction records of the target session thread since its creation by associating it with the session thread identifier, including historical sent messages, historical received messages, message sending timestamps, message interaction subjects, and historical reply records, etc. This is used to ensure the contextual coherence of the session during the subsequent reply generation process, avoid generating reply content that is out of touch with the historical interactions, and ensure the consistency and rationality of the reply.

[0087] 2) Current message content: The pending session content extracted directly from the detected event, including the message text to be responded to, message type, message priority, and key instructions contained in the message, which serves as the core basis for generating subsequent responses and ensures that the responses accurately correspond to the current pending needs;

[0088] 3) User style preferences: Based on the participant set associated with the conversation thread identifier, retrieve the historical response style, language habits, common expression methods and preferred response length of each participating user. This information can be extracted from historical conversation records and stored after preprocessing to make the generated response fit the user's personalized expression habits and improve the adaptability of the response.

[0089] 4) Task Context: Combining the interface parsing results, input parameters, and session context information in the detection event, extract the task scenario, task objective, task progress, and related constraints corresponding to the target session thread. This is used to ensure that the response content meets the requirements of the current task scenario and that the response is targeted.

[0090] After acquiring and organizing the aforementioned related information, preprocessing operations are performed on each piece of related information, including format normalization, removal of redundant information, extraction of key information, and structured coding. This integrates the scattered related information into standardized data that conforms to the input format of the subsequent response generation model, laying the foundation for the generation of subsequent candidate response content.

[0091] Subsequently, a pre-configured generative language model is invoked, and the pre-processed related information is completely input into the generative language model. The generative language model can be obtained by training on a large language model or by configuring prompt words. It has the ability to understand conversational context, adapt to user style, and match task requirements. It can generate response content that fits the current conversational scenario and meets the user's preferences based on the input related information.

[0092] After receiving the associated information input, the generative language model first performs semantic parsing on the associated information such as the input conversation history and current message content to clarify the core needs, user expression habits, and task scenario constraints of the current conversation to be processed. Then, combined with the conversation response logic and language generation rules trained by itself, it generates one or more compliant response texts, which are the candidate response contents. The generated candidate response contents are synchronously transmitted to the subsequent risk assessment module 150 for risk verification. Only after ensuring that the response content is compliant and free of illegal information is the specific action to be determined.

[0093] Step S400: Perform risk assessment on the candidate response content, and determine the action to be performed on the current target session thread based on the result of the risk assessment, the status of the authorized lease, and the thread-level governance status of the target session thread; wherein the action to be performed is any one of automatic sending, draft generation, pre-filling, or blocking.

[0094] In this embodiment, risk assessment is performed on the candidate response content. The risk assessment combines one or more of the following information: task objective, completion conditions, conversation summary, conversation context, candidate response text, risk keywords, and historical failure information. The risk assessment is performed by a rule engine, a classification model, a large language model, or a combination thereof.

[0095] In this embodiment, the specific meanings of draft generation, pre-filling, and blocking in the execution actions are as follows: Draft generation refers to saving the candidate reply content as a draft record in the conversation platform, email platform, or collaboration platform, but without triggering automatic sending. The candidate reply content is sent after the user confirms or modifies it in draft mode; pre-filling refers to filling the candidate reply content into the conversation input box or reply area, waiting for user confirmation, editing, or manual sending, without creating an independent draft record; blocking refers to not executing automatic sending, not creating a draft record, not pre-filling the input box, and outputting a risk warning or triggering an approval / review request.

[0096] like Figure 4 As shown, in one implementation of this embodiment, the step of risk assessment of the candidate response content and determining the action to be performed on the current target session thread based on the result of the risk assessment, the status of the authorized lease and the thread-level governance status of the target session thread includes the following steps S410 to S430.

[0097] Step S410: Obtain the input information required for risk determination. The input information includes candidate reply text, session context, and thread state of the target session thread.

[0098] Step S420: Based on the input information, calculate the rule risk score through the rule engine, calculate the model risk score through the large language model, and perform a fusion calculation on the rule risk score and the model risk score. Based on the preset fusion coefficient, obtain the fusion risk score by weighted summation and use it as the result of risk judgment.

[0099] In this embodiment, risk assessment employs a weighted fusion of the rule engine score and the large language model score. The rule risk score and model risk score are fused and calculated. Based on a preset fusion coefficient, the weighted summation method is used to obtain the fused risk score using the following formula:

[0100] R_final =β×R_rule + (1-β)×R_llm

[0101] Where R_rule is the risk score calculated by the rule engine based on keywords, pattern matching, and historical failure information, R_llm is the risk score calculated by the large language model based on conversational semantics and task context, and β is the fusion coefficient.

[0102] In one implementation of this embodiment, the step of calculating the rule risk score through the rule engine includes:

[0103] 1) Perform keyword matching and pattern detection on the candidate response text to obtain keyword matching scores and pattern detection scores, respectively;

[0104] 2) Obtain the historical failure count in the thread state of the target session thread, and calculate the historical failure weighted score based on the historical failure count;

[0105] 3) Obtain the maximum value between the keyword matching score and the pattern detection score, and add the maximum value to the historical failure weighted score to obtain the initial rule risk score;

[0106] 4) Normalize or prune the initial rule risk score so that it falls within the range of [0,1], thus obtaining the final rule risk score.

[0107] In one implementation of this embodiment, the step of calculating the model risk score using a large language model includes:

[0108] 1) Based on the task objective, session summary, candidate reply text, and most recent failure reason in the target session thread state of the session context, construct risk judgment prompt words;

[0109] 2) Input the risk assessment prompts into the large language model, and the large language model outputs the model risk score in the range [0,1].

[0110] Step S430: Based on the fusion risk score, the thread-level governance status of the target session thread, the default configuration parameters, and the validity of the thread authorization lease, determine the action to be performed on the current target session thread.

[0111] In one implementation of this embodiment, determining the action to be performed on the current target session thread based on the fusion risk score, the thread-level governance state of the target session thread, the default configuration parameters, and the validity of the thread authorization lease includes:

[0112] 1) Based on the thread-level governance status and default configuration parameters of the target session thread, check whether the target session thread meets the session constraints. The session constraints include a first type of mandatory constraint and a second type of automatic sending restriction constraint. The first type of mandatory constraint includes expired authorization and the thread requiring re-approval. The second type of automatic sending restriction constraint includes being in a silent period, reaching the daily automatic sending limit, and the thread being in cooldown. If the first type of mandatory constraint is met, the execution action is determined to be blocking. If the second type of automatic sending restriction constraint is met, the automatic sending action is prohibited, and the execution action is determined to be one of draft generation, pre-filling, or blocking according to the specific type of the session constraint. The thread-level governance status of the target session thread includes any one or more combinations of the following: valid authorization, expired authorization, thread in cooldown, thread requiring re-approval, silent period restriction, and daily automatic action limit exceeded.

[0113] 2) If any session constraint condition is not met, determine whether the fusion risk score is greater than or equal to the preset high-risk threshold: if so, determine the action to be blocked.

[0114] 3) If not, check if the thread authorization lease is valid: if the thread authorization lease is invalid, determine that the action to be performed is pre-filling.

[0115] 4) If the thread authorization lease is valid, determine the relationship between the fusion risk score and the preset low-risk threshold and the preset high-risk threshold: if the fusion risk score is less than the preset low-risk threshold, determine that the action to be performed is automatic sending; if the fusion risk score is greater than or equal to the preset low-risk threshold and less than the preset high-risk threshold, determine that the action to be performed is to generate a draft.

[0116] Figure 5 This diagram illustrates the principles of candidate response generation, risk assessment, and action decision-making in the session control method based on thread-level authorization leases described in this application. Figure 5 As shown, in this embodiment, a large language model is first used to generate candidate response drafts based on conversation history, current message content, user style preferences, and task context. Subsequently, risk assessment is performed based on task objectives, completion conditions, conversation summary, conversation context, candidate response text, and risk keywords. This risk assessment is accomplished by a combination of a rule engine, a classification model, and / or a large language model.

[0117] For example, when a candidate response contains price promises, payment confirmations, contract terms, sensitive personal information, or content that clearly deviates from the semantics of the thread, the risk assessment module 150 can identify it as a high-risk context. For high-risk contexts, even if the current thread license lease is still valid, the system will not send it automatically directly, but will instead downgrade to draft generation or block it.

[0118] Specifically, the rule engine detected keywords such as "confirm payment" and "agree to contract" in the reply, outputting R_rule = 0.8; the large language model, combined with the conversation context, determined that the reply involved a financial commitment, outputting R_llm = 0.85. The combined calculation R_final = 0.5×0.8 + 0.5×0.85 = 0.825 (rounded to 0.83), exceeding the high-risk threshold of 0.7, thus triggering a blocking action.

[0119] Step S500: If automatic sending fails after the automatic sending action is performed, the authorized lease of the target session thread is revoked and a preset recycling operation is performed.

[0120] In one implementation of this embodiment, when an automatic sending failure is detected after the automatic sending action is performed, revoking the authorized lease of the target session thread and performing a preset recycling operation includes:

[0121] When an automatic sending failure event is detected in the target session thread, the revocation time of the authorized lease associated with the target session thread is set to the current time, the authorized lease of the target session thread is revoked, and any one or more combinations of the following preset recycling operations are performed:

[0122] 1) Increment the failure count in the thread state by 1 to update the failure count;

[0123] 2) Record the reason for the failure to send the message in the most recent failure reason field of the thread status to retain evidence of the failure;

[0124] 3) Calculate the cooling end time based on the preset cooling duration, and set the cooling end time to the thread state to perform cooling control on the target session thread;

[0125] 4) Determine whether the failure count in the thread state has reached the preset maximum consecutive failure count. If yes, mark the target session thread as needing to be re-approved in the thread state and record the current time as the upgrade time. If no, do not mark the target session thread as needing to be re-approved, and retain the updated failure count, the most recent failure reason field, and the cooldown end time.

[0126] In this embodiment, the failure recovery method includes: clearing the thread authorization lease, increasing the failure count, setting the cooldown end time, recording the upgrade time, and restoring to a non-automatic sending state. When the consecutive failure count reaches the preset upper limit, the thread is marked as requiring re-approval, and the automatic sending function can only be restored after the user explicitly re-approves.

[0127] Figure 6This diagram illustrates the automatic transmission failure recovery and cooling process in the session control method based on thread-level authorization leases described in this application embodiment. Figure 6 As shown, exemplarily, in this embodiment, if automatic sending fails in a certain thread—for example, the send button cannot be located, an error is returned after sending, the candidate reply is inconsistent with the thread context, or an external rule rejects sending—then failure recycling is immediately performed.

[0128] (1) Clear the authorized lease of the thread and set revoked_at to the current time.

[0129] (2) Increment the failure count of the thread by 1.

[0130] (3) Record the end time of the thread entering the cooldown state, for example, the current time plus 300 seconds.

[0131] (4) If the consecutive failure count reaches the upper limit (e.g., 3 consecutive times), record the upgrade time and mark the thread as needing to be re-approved.

[0132] (5) When the same thread detection event arrives again, even if the task is similar to the previous one, it is not allowed to send it automatically directly.

[0133] This avoids the continuous sending of erroneous data due to maintaining automatic sending privileges after a single failure.

[0134] In one implementation of this embodiment, the method further includes determining whether to block the automatic sending operation of the target session thread, including:

[0135] 1) Obtain the thread status and default configuration parameters of the target session thread. The default configuration parameters include the start time of the silent period, the end time of the silent period, and the daily automatic sending limit. The thread status includes the daily automatic sending count, the cooldown end time, and a re-approval flag. The silent period is a preset time interval during which automatic sending is prohibited. The daily automatic sending limit is the maximum number of automatic sending operations allowed per day.

[0136] 2) Configure multiple control conditions based on the thread state and the default configuration parameters, and perform condition judgment on the target session thread in sequence based on the multiple control conditions. If any condition is met, it is determined that the automatic sending operation of the target session thread needs to be blocked. If all conditions are not met, it is determined that the automatic sending operation of the target session thread does not need to be blocked.

[0137] Figure 7 This diagram illustrates the principle of degraded execution under silent periods and daily action limits in the session control method based on thread-level authorization leases described in this application. Figure 7As shown, in this embodiment, it may also include monitoring rule-level governance parameters, such as silent period, daily automatic sending limit, maximum consecutive failure count, and reply approval window length.

[0138] 3) If the current time is during a quiet period (e.g., from 22:00 to 8:00 the next day), actions that were originally allowed to be sent automatically will be downgraded to draft generation; if the daily limit for automatic actions is reached (e.g., 50 times per day), new automatic sending will also be stopped, and only draft or pre-filled actions will be retained. This implementation method allows the system to maintain controllable and recyclable automated behavior even under long-term continuous operation.

[0139] To more clearly illustrate the specific process of risk assessment and action decision-making in this embodiment, a complete set of numerical calculation examples is given below.

[0140] Scenario: A new message is detected in a Slack internal collaboration channel. The thread authorization lease is valid, and candidate replies are generated, as shown in Table 1 below. The rule engine fusion coefficient β = 0.5, the low-risk threshold θ_low = 0.3, and the high-risk threshold θ_high = 0.7.

[0141] Table 1

[0142] serial number Candidate Response Summary R_rule R_llm R_final decision making illustrate A Received, I will process it as soon as possible. 0.05 0.08 0.07 AUTO_SEND Low risk and valid lease B Okay, we agree to this plan. 0.15 0.35 0.27 AUTO_SEND Low risk C Payment confirmed: ¥30,000 0.80 0.85 0.83 BLOCK Exceeding the high-risk threshold D Personnel verification is underway; a response is expected tomorrow. 0.10 0.30 0.22 AUTO_SEND After fusion, it is lower than θ_low E Option B is recommended; the attached document is a draft contract. 0.55 0.60 0.58 DRAFT Medium risk → Draft

[0143] Taking number A in Table 1 as an example, the calculation is as follows: The rule engine did not detect any risky keywords, there was no pattern matching, the historical failure count was 0, and R_rule = 0.05 (baseline score). The large language model judges the reply as a regular confirmation with no risky content, and R_llm = 0.08. The fusion calculation R_final = 0.5×0.05 + 0.5×0.08 = 0.065, rounded to 0.07.

[0144] If R_final = 0.07 < θ_low = 0.3, and the thread authorization lease is valid with no governance constraints, the system determines to execute the AUTO_SEND action.

[0145] Comparing with number C in Table 1, the rule engine detected a confirmation payment keyword and amount pattern, R_rule = 0.80; the large language model determined that financial commitment was involved, R_llm = 0.85. The fusion calculation R_final = 0.5 × 0.80 + 0.5 × 0.85 = 0.825, rounded to 0.83. R_final = 0.83 ≥ θ_high = 0.7, so the system executes a BLOCK action to protect the user from the risk of accidental sending.

[0146] Table 2 shows the changes in the authorized lease status of the same thread at different times and the corresponding governance decisions:

[0147] Table 2

[0148] time event Lease status Failure count Cooling state R_final Execute action T0 User approved automatic sending Valid (1 hour remaining) 0 none - Authorized lease generation T1 New message detected Valid (45 minutes remaining) 0 none 0.12 AUTO_SEND successful T2 New message detected Valid (30 minutes remaining) 0 none 0.07 AUTO_SEND successful T3 Send button not found Revoked 1 Cooling (5 min) - Failed recycling → downgraded to draft T4 New message detected Revoked 1 Cooling (3 min) 0.09 DRAFT (Disable auto-battle while cooling) T5 Cooling complete + User re-approval Valid (1 hour remaining) 0 (Reset) none - New lease generated T6 50 automatic messages sent that day efficient 0 none 0.05 DRAFT (Daily limit reached)

[0149] As shown in Table 2, after the transmission failure at time T3, the system immediately cancels the lease and enters a cooling-off state. Even though the risk score is only 0.09 (low risk) at time T4, the system still downgrades to draft mode because the thread is in a cooling-off state. Time T6 demonstrates the constraint effect of the daily action limit: even if the lease is valid and the risk is low, it automatically downgrades after exceeding the daily limit of 50 actions. This mechanism ensures the controllability and security of the system during long-term operation.

[0150] The session control method based on thread-level authorization leases described in this embodiment addresses the technical problems in existing technologies, such as coarse-grained session automation permission control, lack of risk prevention mechanisms, and difficulty in balancing automation and security. Through session thread-level authorization leases, integrated risk assessment, multi-layered governance constraints, and failure recovery mechanisms, it achieves refined control over the entire session automation process. Compared with existing technologies, it has the following significant advantages:

[0151] First, the method in this embodiment controls automated permissions down to specific session threads, avoiding the risk spread caused by global delegation of permissions. This embodiment abandons the coarse-grained management model of global unified authorization in existing technologies, and precisely binds automated operation permissions to specific session threads. By assigning a unique identifier to each independent session thread, a one-to-one correspondence between permissions and session threads is achieved. This allows for precise control of automated permissions in a single session, fundamentally avoiding problems such as permission abuse and risk spread across sessions caused by global delegation of permissions. It also solves the technical defects of existing technologies, such as insufficient granularity of permission control and difficulty in isolating risks.

[0152] Second, the method in this embodiment limits the validity period of automatically sent permissions through authorization leases, achieving a control loop of approval first, authorization later, and expiration revocation. This method establishes an authorization lease with a validity period for the target session thread, clearly defining core attributes such as the lease's approval time, expiration time, and revocation status. It achieves end-to-end loop governance of "granting permissions after user approval, automatic lease expiration, and real-time revocation in abnormal states." Compared to the shortcomings of existing technologies where permissions are granted for extended periods and lack dynamic revocation mechanisms, this method dynamically manages automatically sent permissions, ensuring the automation efficiency of compliant sessions while eliminating security risks caused by long-term permission persistence. It solves the technical problems of existing permission governance lacking an infinite loop and insufficient dynamic control capabilities.

[0153] Third, the method in this embodiment incorporates candidate responses generated by the large language model into the risk assessment process, rather than sending them directly and unconditionally. This method addresses the technical shortcomings of existing technologies that directly send content generated by the large language model and lack risk verification. After candidate response content is generated, a fusion-based risk assessment is performed on the candidate response content. Only low-risk content with valid leases can be automatically sent; medium-risk content generates drafts; and high-risk content is directly blocked. This incorporates the content generated by the large language model into the entire process of risk management, avoiding the risks of model illusion and direct output of illegal content, and solving the technical problems of insufficient risk verification and inadequate security in existing automated responses.

[0154] Fourth, the method in this embodiment immediately revokes permissions and enters a cooling-off or re-approval state after automatic transmission failure, reducing the probability of continuous erroneous output. When automatic transmission failure is detected, the method in this embodiment immediately revokes the authorization lease of the target session thread and simultaneously performs default recycling operations such as failure count accumulation, cooling-off time setting, and re-approval marking. Compared to the shortcomings of existing technologies that fail to manage failures in a timely manner and easily lead to continuous erroneous output, this method can quickly cut off automation permissions after a single failure, restrict continuous operations through a cooling-off period, and block unauthorized permissions through re-approval, significantly reducing the probability of continuous erroneous output. This solves the technical problem of existing technologies lacking effective management after failure and causing continuous accumulation of error risks.

[0155] Fifth, the method in this embodiment can comprehensively manage multiple layers, including silent periods, daily automatic sending limits, and thread risk states, achieving a better balance between security and automation efficiency. This method integrates multiple governance constraints such as silent period control, daily automatic sending limits, thread cooldown states, and re-approval requirements. It combines risk assessment results with lease status to execute differentiated action decisions (automatic sending, draft generation, pre-filling, and blocking). Compared to the shortcomings of existing technologies with single-dimensional control and difficulty in balancing security and efficiency, this method can flexibly adjust execution strategies according to different constraint scenarios, maximizing automation efficiency while ensuring session security. This solves the technical problems of existing technologies having a single governance dimension and difficulty in balancing security and efficiency.

[0156] Sixth, the method in this embodiment employs a risk assessment mechanism that integrates a rule engine and a large language model, taking into account both deterministic rules and semantic understanding capabilities, and adapting to various complex risk scenarios. The risk assessment method in this embodiment uses a fusion scoring mechanism of a rule engine and a large language model. Deterministic rules such as keyword matching and pattern detection ensure the accuracy of basic risk prevention and control, while the semantic understanding capabilities of the large language model are introduced to address scenarios such as complex semantic risks and contextual risks. The final risk score is obtained through weighted fusion. Compared to the shortcomings of existing technologies where a single rule engine lacks sufficient semantic understanding and a single model lacks sufficient determinism, this method balances the determinism of rules with the semantic understanding capabilities of the model, making it adaptable to various complex risk scenarios and solving the technical problems of existing technologies having limited risk assessment capabilities and being unable to cope with complex scenarios.

[0157] The protection scope of the session control method based on thread-level authorization lease described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, deleting, or replacing steps in the prior art based on the principles of this application is included within the protection scope of this application.

[0158] This application also provides a session control system 100 based on thread-level authorization leases. The session control system 100 based on thread-level authorization leases can implement the session control method based on thread-level authorization leases described in this application. However, the implementation device of the session control method based on thread-level authorization leases described in this application includes, but is not limited to, the structure of the session control system 100 based on thread-level authorization leases listed in this embodiment. All structural modifications and substitutions of the prior art made in accordance with the principles of this application are included within the protection scope of this application.

[0159] like Figure 8 As shown, this embodiment provides a session control system 100 based on thread-level authorization leases. The session control system 100 based on thread-level authorization leases includes at least an event detection listening module 110, a thread identifier generation module 120, a lease authorization module 130, a candidate reply content generation module 140, a risk judgment module 150, an execution action determination module 160, a governance constraint module 170, and a recycling processing module 180.

[0160] In this embodiment, the detection event monitoring module 110 is used to monitor detection events in the session-based graphical interface; the thread identifier generation module 120 is used to extract session feature information from the detection events and generate a session thread identifier based on the session feature information; the lease authorization module 130, in response to receiving a user's approval operation instruction for the target session thread, establishes an authorization lease for the target session thread based on the session thread identifier; the candidate reply content generation module 140, in response to detecting unprocessed session content in the target session thread, generates candidate reply content; the risk judgment module 150 is used to perform risk judgment on the candidate reply content; the execution action determination module 160 is used to determine the execution action for the current target session thread based on the result of the risk judgment, the status of the authorization lease, and the thread-level governance status of the target session thread; wherein, the execution action is any one of automatic sending, draft generation, pre-filling, or blocking. The governance constraint module 170 is used to determine whether to block the automatic sending operation of the target session thread based on multiple control conditions such as the start time of the silent period, the end time of the silent period, the daily automatic sending limit, the cooldown end time, and whether a re-approval flag is required. If the recycling processing module 180 detects an automatic sending failure after performing the automatic sending action, it revokes the authorization lease of the target session thread and performs a preset recycling operation.

[0161] It should be noted that the functions or operations of the event detection listening module 110, thread identifier generation module 120, lease authorization module 130, candidate reply content generation module 140, risk judgment module 150, execution action determination module 160, governance constraint module 170, and recycling processing module 180 described in this embodiment correspond one-to-one with the steps in the session control method based on thread-level authorization leases described above, and therefore will not be repeated here.

[0162] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0163] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / units in the various embodiments of this application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0164] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0165] In this embodiment, the implementation principle of each module of the session control system 100 based on thread-level authorization lease is the same as the implementation principle of each step of the session control method based on thread-level authorization lease described above. The implementation principle and specific implementation method of the session control system 100 based on thread-level authorization lease will not be described again here.

[0166] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the session control method based on thread-level license lease provided in any embodiment of this application.

[0167] In the embodiments of this application, any combination of one or more storage media can be used. The storage medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, RAM, ROM, an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), optical memory, magnetic memory, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0168] This application also provides an electronic device. Figure 9 The diagram shown is a structural schematic of the electronic device 10 provided in an embodiment of this application. In some embodiments, the electronic device may be a mobile phone, tablet computer, wearable device, in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), or other terminal device. Furthermore, the session control method based on thread-level license leases provided in this application can also be applied to databases, servers, and service response systems based on terminal artificial intelligence. This application does not impose any limitations on the specific application scenarios of the session control method based on thread-level license leases.

[0169] like Figure 9 As shown, the electronic device 10 provided in this application embodiment includes a memory 101 and a processor 102.

[0170] The memory 101 is used to store computer programs; preferably, the memory 101 includes various media that can store program code, such as ROM, RAM, disk, USB flash drive, memory card or optical disc.

[0171] Specifically, memory 101 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. Electronic device 10 may further include other removable / non-removable, volatile / non-volatile computer system storage media. Memory 101 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0172] The processor 102 is connected to the memory 101 and is used to execute the computer program stored in the memory 101 so that the electronic device 10 executes the session control method based on thread-level license lease provided in any embodiment of this application.

[0173] Optionally, the processor 102 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0174] Optionally, in this embodiment, the electronic device 10 may further include a display 103. The display 103 is communicatively connected to the memory 101 and the processor 102, and is used to display the relevant GUI interaction interface of the session control method based on thread-level license lease.

[0175] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes a plurality of computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0176] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0177] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A session control method based on thread-level authorization leases, characterized in that, include: Listen for detection events in the session-based graphical interface, extract session feature information from the detection events, and generate a session thread identifier based on the session feature information; In response to receiving a user's approval operation instruction for a target session thread, an authorization lease is established for the target session thread based on the session thread identifier; In response to the detection that there is unprocessed session content in the target session thread, candidate reply content is generated; The candidate response content is risk-assessed, and the action to be performed on the current target session thread is determined based on the result of the risk assessment, the status of the authorized lease, and the thread-level governance status of the target session thread; wherein the action to be performed is any one of automatic sending, draft generation, pre-filling, or blocking. If automatic sending fails after the automatic sending action is performed, the authorized lease of the target session thread is revoked, and a preset recycling operation is performed.

2. The session control method based on thread-level authorization leases according to claim 1, characterized in that, The step of extracting session feature information from the detected event and generating a session thread identifier based on the session feature information includes: Extract interface metadata, session context information, and session input information from the detected events; The interface metadata, the session context information, and the session input information are concatenated to form a feature string; The concatenated feature string is hashed, structured encoded, or a combination thereof to generate a session thread identifier for identifying the session thread; and when a conflict in the session thread identifier is detected, disambiguation is performed based on the window instance identifier, message timestamp, or sequence number, which is the session thread identifier.

3. The session control method based on thread-level authorization leases according to claim 1, characterized in that, The step of establishing an authorization lease for the target session thread based on the session thread identifier in response to receiving a user's approval operation instruction for the target session thread includes: In response to receiving a user's approval operation instruction for a target session thread, the session thread identifier corresponding to the target session thread is obtained; Based on the session thread identifier, an authorization lease is constructed. The authorization lease includes at least the session thread identifier, approval time, expiration time, associated task identifier, and revocation time. The initial value of the revocation time is set to none, and the expiration time is calculated from the current time and the preset validity period. Persistently store and output the authorized lease.

4. The session control method based on thread-level authorization leases according to claim 1, characterized in that, The response to detecting unprocessed session content in the target session thread, generating candidate response content includes: In response to detecting that there is pending session content in the target session thread, the associated information of the target session thread is obtained; the associated information includes at least one or more combinations of session history, current message content, user style preferences, and task context; The pre-configured generative language model is invoked, the associated information is input into the generative language model, and the generative language model outputs candidate response content.

5. The session control method based on thread-level authorization leases according to claim 1, characterized in that, The step of assessing the risk of the candidate response content and determining the action to be performed on the current target session thread based on the result of the risk assessment, the status of the authorized lease, and the thread-level governance status of the target session thread includes: Obtain the input information required for risk assessment, including candidate response text, session context, and thread state of the target session thread; Based on the input information, the rule risk score is calculated by the rule engine, the model risk score is calculated by the large language model, and the rule risk score and the model risk score are fused together. Based on the preset fusion coefficient, the fused risk score is obtained by weighted summation and used as the result of risk judgment. Based on the fusion risk score, the thread-level governance status of the target session thread, the default configuration parameters, and the validity of the thread authorization lease, the action to be performed on the current target session thread is determined.

6. The session control method based on thread-level authorization leases according to claim 5, characterized in that: The calculation of rule risk scores through the rule engine includes: The candidate response texts are subjected to keyword matching and pattern detection to obtain keyword matching scores and pattern detection scores, respectively. Obtain the historical failure count in the thread state of the target session thread, and calculate the historical failure weighted score based on the historical failure count; Obtain the maximum value between the keyword matching score and the pattern detection score, and add the maximum value to the historical failure weighted score to obtain the initial rule risk score; The initial rule risk score is normalized or subjected to upper and lower limit pruning so that the initial rule risk score is in the range of [0,1], thus obtaining the final rule risk score.

7. The session control method based on thread-level authorization leases according to claim 5, characterized in that: The calculation of the model risk score using a large language model includes: Based on the task objective, session summary, candidate reply text, and recent failure reason in the thread state of the target session thread of the session context, risk judgment prompt words are constructed. The risk assessment prompts are input into a large language model, which then outputs a model risk score in the range [0,1].

8. The session control method based on thread-level authorization leases according to claim 5, characterized in that, The determination of the action to be performed on the current target session thread based on the fusion risk score, the thread-level governance status of the target session thread, the default configuration parameters, and the validity of the thread authorization lease includes: Based on the thread-level governance state and default configuration parameters of the target session thread, check whether the target session thread meets the session constraints. The session constraints include a first type of mandatory constraints and a second type of automatic sending restriction constraints. The first type of mandatory constraints includes expired authorization and the thread requiring re-approval. The second type of automatic sending restriction constraints includes being in a silent period, reaching the daily automatic sending limit, and the thread being in cooldown. If the first type of mandatory constraint is satisfied, then the action to be performed is determined to be blocking; If the second type of automatic sending restriction constraint is met, the automatic sending action is prohibited, and the execution action is determined to be one of draft generation, pre-filling, or blocking according to the specific type of the session constraint condition; If any session constraint condition is not met, then determine whether the fusion risk score is greater than or equal to a preset high-risk threshold: If so, then the action to be performed is to block. If not, then check whether the thread authorization lease is valid: If the thread authorization lease is invalid, then the action to be performed is pre-filling; If the thread authorization lease is valid, then determine the relationship between the fusion risk score and the preset low-risk threshold and preset high-risk threshold: If the fusion risk score is less than the preset low-risk threshold, then the action to be performed is automatic sending; If the fusion risk score is greater than or equal to the preset low-risk threshold and less than the preset high-risk threshold, then the action to be performed is to generate a draft.

9. The session control method based on thread-level authorization leases according to claim 1, characterized in that, If an automatic sending failure is detected after the automatic sending action is executed, the authorized lease of the target session thread is revoked, and a preset recycling operation is performed, including: When an automatic sending failure event is detected in the target session thread, the revocation time of the authorized lease associated with the target session thread is set to the current time, the authorized lease of the target session thread is revoked, and any one or more combinations of the following preset recycling operations are performed: Increment the failure count in the thread state by 1 and update the failure count; The reason for the failure will be recorded in the most recent failure reason field of the thread status to preserve evidence of the failure. Based on the preset cooling duration, the cooling end time is calculated and set to the thread state to perform cooling control on the target session thread; Determine whether the failure count in the thread state has reached the preset maximum consecutive failure count. If yes, mark the target session thread as needing to be re-approved in the thread state and record the current time as the upgrade time. If no, do not mark the target session thread as needing to be re-approved, and retain the updated failure count, the most recent failure reason field, and the cooldown end time.

10. The session control method based on thread-level authorization leases according to claim 1, characterized in that, It also includes determining whether to block the automatic sending operation of the target session thread, including: Obtain the thread status and default configuration parameters of the target session thread. The default configuration parameters include the start time of the silent period, the end time of the silent period, and the daily automatic sending limit. The thread status includes the daily automatic sending count, the cooldown end time, and whether re-approval is required. Based on the thread state and the default configuration parameters, multiple control conditions are configured, and the target session thread is judged in turn based on the multiple control conditions. If any condition is met, it is determined that the automatic sending operation of the target session thread needs to be blocked. If none of the conditions are met, it is determined that the automatic sending operation of the target session thread does not need to be blocked.

11. A session control system based on thread-level authorization leases, characterized in that, include: The event listening module is used to listen for detection events in the session-based graphical interface. The thread identifier generation module is used to extract session feature information from the detection event and generate a session thread identifier based on the session feature information; The lease authorization module, in response to receiving a user's approval operation instruction for a target session thread, establishes an authorization lease for the target session thread based on the session thread identifier; The candidate reply content generation module generates candidate reply content in response to detecting that there is unprocessed session content in the target session thread; The risk assessment module is used to assess the risk of the candidate response content. The action determination module is used to determine the action to be performed on the current target session thread based on the result of the risk assessment, the status of the authorized lease, and the thread-level governance status of the target session thread; wherein the action to be performed is any one of automatic sending, draft generation, pre-filling, or blocking; The governance constraint module is used to determine whether to block the automatic sending operation of the target session thread based on the start time of the silent period, the end time of the silent period, the daily automatic sending limit, the end time of the cooldown period, and whether a re-approval flag is required. If the automatic sending action fails after being executed, the recycling processing module revokes the authorization lease of the target session thread and performs a preset recycling operation.

12. An electronic device, characterized in that, include: Memory stores a computer program; The processor, which is connected to the memory, executes the session control method based on thread-level license lease as described in any one of claims 1 to 10 when calling the computer program.

13. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the processor of an electronic device, implements the session control method based on thread-level license leases as described in any one of claims 1 to 10.

Images