A method, system, device and medium for active human-computer interaction based on domain object agentization

Abstract

The application discloses a kind of active human-computer interaction method, system, equipment and medium based on field object agentization.The method carries out standardization to the object data of multiple business systems, establishes object state atlas;Object event is generated according to object state change, the qualification of active speech of object is judged and intelligent contact person is instantiated;Candidate message containing object reference, trigger evidence and executable action descriptor is generated;Candidate message conflict relationship is constructed, and selection, merging, delay or inhibition is executed under the constraint of interactive resource budget;Target message is presented with contact person as subject, target service is called in response to user operation, and execution result is written back to original field object, to update object state, contact person life cycle and subsequent trigger strategy.The application can reduce repeated message and invalid calculation, shorten the interaction path from state discovery to action execution, and improve the consistency of message state and business state.

Description

Technical Field

[0001] This invention relates to the fields of computer human-computer interaction, event-driven software architecture, data state management, natural language generation, agent scheduling, and graphical user interface technology. In particular, it relates to a method, system, electronic device, computer-readable storage medium, and computer program product that dynamically transforms domain objects in a business system into intelligent contacts based on their state changes, and performs proactive message generation, conflict resolution, action execution, and state write-back under the constraints of interactive resources. Background Technology

[0002] Existing software typically uses menus, dashboards, cards, notification centers, or unified dialogue assistants to display the status of business objects. When a user discovers a change in an object, they often need to enter the corresponding business module, understand the status indicators, find the processing entry point, and switch to the target service to perform the operation, resulting in a long interaction path between status discovery and action execution.

[0003] As the number of data sources and business objects connected to an application increases, a single user may simultaneously encounter multiple constantly changing objects such as tasks, schedules, devices, accounts, health records, and project nodes. Traditional notification mechanisms are typically triggered independently by each business module, lacking joint scheduling across objects, which can easily lead to problems such as duplicate content, conflicting suggestions, excessive push notifications, expired statuses, and the repeated execution of the same action.

[0004] Existing multi-role dialogue systems typically have developers pre-define several fixed roles, and the real-time state, version, and lifecycle of these roles are not stably mapped to the underlying business objects. While existing proactive assistants can generate reminders or suggestions, these messages often lack traceable object references, trigger evidence, and write-back rules to the original business object. Furthermore, after a user performs an action, the result may not be written back to the original object that triggered the message, resulting in inconsistencies between the dialogue state, notification state, and business state.

[0005] Furthermore, when multiple objects simultaneously meet the triggering conditions, simply sorting them by time or single priority cannot handle semantic duplication, mutual exclusion of actions, competition for shared resources, and time conflicts among candidate messages. It also cannot simultaneously limit the number of messages, UI occupancy, push channels, model calls, and network transmission overhead.

[0006] Therefore, a computer implementation scheme is needed to unify the state representation of heterogeneous business objects, enabling objects to dynamically obtain contact identities based on state changes; generate structured messages with object references and executable action descriptors; perform message scheduling under the joint constraints of interaction resource budget and conflict relationships; and write the results back to the original domain object after the action is executed, so as to improve the traceability, execution consistency and computing resource utilization efficiency of multi-object proactive interaction. Summary of the Invention Technical problems to be solved

[0007] The present invention aims to solve at least the following technical problems: to unify the objectification and versioning of data from different business systems; to dynamically create or activate smart contacts based on changes in object status rather than just user queries; to reduce duplicate, contradictory, and terminal-exceeding messages when multiple objects are triggered simultaneously; to reliably bind natural language messages to executable operations in the target service; and to maintain consistency between message status, contact status, and the original business object status after the operation is completed. Technical solution

[0008] To address the aforementioned technical problems, this invention provides a proactive human-computer interaction method based on domain object proxying. The method acquires data from multiple domain objects in at least one business system, standardizes the data into object records, and establishes or updates an object state graph based on these records; detects changes in object state and generates object events; determines the proactive speaking qualification of a domain object based on object events, role constraints, and user context; instantiates domain objects with proactive speaking qualifications as candidate intelligent contacts; generates candidate messages containing object references and executable action descriptors; constructs conflict relationships between candidate messages and selects, merges, delays, or suppresses candidate messages under interaction resource budget constraints; presents the target message as the intelligent contact; verifies and executes the target action; and writes the execution result back to the original domain object.

[0009] In one implementation, the object record includes at least one of object_id, object_type, state_vector, relations, evidence_refs, trigger_policy, permission_scope, object_version, lifecycle, and updated_at. Each domain object has a globally or business-domain unique object identifier. Object nodes in the object state graph store object records, and relationship edges store the relationship type, direction, weight, and update time between the object and users, other objects, and target services.

[0010] In one implementation, object state changes are triggered by the difference between the current object state and the previous object state, the arrival of a preset time, a change in location, the completion of external dependencies, the arrival of data, or the result of an action execution. Object events include at least an object identifier, an event type, a change field, a change magnitude, an event time, evidence references, and an object version.

[0011] In one implementation, the speaking eligibility determiner reads object events, object triggering policies, role constraints, permission scope, user silence settings, and recent message records, and outputs a eligibility value. The eligibility value can be obtained from rules, classification models, ranking models, or combinations thereof. Objects that meet the eligibility threshold enter the candidate set; objects that do not meet the threshold remain in an ungenerated or dormant state.

[0012] In one implementation, the proxying engine generates or reads contact configurations based on object type, current state, and object relationships. Contact configurations include at least one of agent_id, object_ref, display_identity, role_constraints, language_constraints, knowledge_scope, memory_ref, allowed_actions, and lifecycle. Contacts and domain objects are mapped through object_ref, thus messages sent by a contact can be traced back to the original domain object.

[0013] In one implementation, the candidate message includes at least one of message_id, object_ref, evidence, utterance, created_at, validity, priority_features, action_descriptor, writeback_rule, confidence, object_version, and message_fingerprint. The executable action descriptor includes at least one of action_type, target_service, endpoint_or_function, parameters, permission_level, confirmation_policy, timeout, version_token, idempotency_key, rollback_policy, and result_mapping.

[0014] In one implementation, the interaction resource budget is a constraint on message presentation and computational resources set by the system within a preset time window. It may include the number of messages allowed to be presented, total disturbance cost, interface occupancy, pop-up or audio channel occupancy, model call count, model token quantity, network request count, and network transmission volume. By representing the interaction resource budget as a computable constraint, message ordering that relies solely on subjective preferences can be avoided.

[0015] In one implementation, the conflict relationships between candidate messages include semantic duplication, contradictory suggestions, mutually exclusive actions, shared resource contention, and time conflicts. The system constructs a conflict graph, where nodes represent candidate messages and edges record conflict types and intensities. The scheduler selects the target message set while satisfying the interaction resource budget and conflict constraints, and delays, downgrades, or suppresses messages that are not selected.

[0016] In one implementation, before executing an action, the current state and version of the domain object are obtained, and the current object version is compared with the version token in the message. When the version is inconsistent, the message expires, permissions are insufficient, parameters are incomplete, or the action execution conditions are not met, the system blocks execution, requests supplementary parameters, or regenerates the message, thereby reducing the probability of erroneous operations caused by expired messages.

[0017] In one implementation, the action execution result is written back to the domain object through result mapping rules. The system uses idempotency flags to identify duplicate results, preventing the same result from being written repeatedly; and updates the object state, object version, contact lifecycle, trigger threshold, and message frequency based on the results of success, failure, partial success, timeout, cancellation, or user ignore.

[0018] The present invention also provides an active human-computer interaction system, electronic device, computer-readable storage medium and computer program product corresponding to the above method. Beneficial effects

[0019] Compared with existing technologies, this invention enables proactive messages to be traced back to specific business objects and state changes through object identification, object versioning, and evidence citation; it reduces the storage and computational overhead of maintaining a large number of intelligent agent instances by generating or activating contacts only when the object meets the speaking conditions through event-driven contact lifecycle; it reduces duplicate messages, contradictory messages, and invalid model calls through joint scheduling of interaction resource budgets and conflict graphs; it shortens the page jump path from state discovery to action execution by binding messages with executable action descriptors; and it improves the consistency between message state, contact state, and business object state through version verification, idempotent execution, and state write-back. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the overall architecture of an object proxy-based proactive human-computer interaction system in one embodiment of the present invention.

[0021] Figure 2 This is a flowchart illustrating the object proxying and proactive message orchestration method in one embodiment of the present invention.

[0022] Figure 3This is a schematic diagram illustrating the data structure relationship between domain object records, smart contact instances, candidate messages, action descriptors, and action results in one embodiment of the present invention.

[0023] Figure 4 This is a schematic diagram of the lifecycle state transition of a smart contact in one embodiment of the present invention.

[0024] Figure 5 This is a schematic diagram illustrating the joint scheduling of candidate message conflict relationships and interactive resource budgets in one embodiment of the present invention.

[0025] Figure 6 This is a timing diagram illustrating the execution of the target action and the writing back of the object state in one embodiment of the present invention.

[0026] Figure labels: 101, Data access module; 102, Object state graph module; 103, Event detection module; 104, Proxy engine; 105, Candidate message generation module; 106, Interactive resource scheduling module; 107, Contact-style presentation module; 108, Action binding module; 109, Action execution module; 110, Feedback writing module; 201, Domain object record; 202, Smart contact instance; 203, Candidate message record; 204, Executable action descriptor; 205, Action result record; 206, State return. Write rules; 301, Ungenerated state; 302, Candidate state; 303, Active state; 304, Waiting to execute state; 305, Dormant state; 306, Archived state; 401 to 404, Candidate messages; 405, Conflict graph; 406, Interaction resource budget; 407, Scheduler; 408, Rendering process; 409, Merging process; 410, Delay process; 411, Suppression process; 501, User terminal; 502, Contact-based interface; 503, Action validator; 504, Target service; 505, Object state graph. Detailed Implementation

[0027] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. It should be understood that the described embodiments are only for explaining the present invention and are not intended to limit the scope of protection of the present invention. Where there is no contradiction, the technical features of the various embodiments can be combined with each other. I. Terminology and Overall Structure

[0028] A domain object is a digital entity in a business system that has a stable object identifier, a changeable state, and the ability to perform actions. Domain objects can be tasks, projects, schedules, devices, accounts, bills, orders, health records, meal times, learning goals, or combinations thereof. Domain objects are not required to correspond to real-world people, nor are they required to be displayed as contacts indefinitely.

[0029] Object proxying refers to the system generating or activating smart contact instances for domain objects based on their state, relationships, permissions, and triggering policies. This enables domain objects to generate messages and provide action entry points with a constrained identity. Object proxying is not merely adding avatars or text to objects; rather, it establishes a computable mapping between object identifiers, contact instances, candidate messages, action execution, and result write-back.

[0030] like Figure 1 As shown, the system includes a data access module 101, an object state graph module 102, an event detection module 103, a proxy engine 104, a candidate message generation module 105, an interaction resource scheduling module 106, a contact-based presentation module 107, an action binding module 108, an action execution module 109, and a feedback write-back module 110. These modules can be deployed on the same electronic device or distributed across clients, application servers, model services, and third-party target services.

[0031] The data access module 101 receives data through database change streams, message queues, application programming interfaces (APIs), sensor interfaces, file imports, user input, or third-party authorized interfaces. Each data adapter converts the raw data into a unified object update format, which includes at least source_id, object_id, object_type, changed_fields, current_values, timestamp, evidence_refs, and permission_tags.

[0032] The object state graph module 102 receives a unified object update format, reads object records by object_id, writes changed_fields to state_vector, increments object_version, and saves a snapshot or difference record of the previous version. Relationship edges can include relationships such as belongs_to, depends_on, conflicts_with, uses_service, owned_by, and derived_from. II. Object Event Detection and Speaking Qualification Determination

[0033] like Figure 2 As shown, in step S101, the system accesses and standardizes domain object data. In step S102, the system establishes or updates the object state map. In step S103, the event detection module 103 compares the current object state with the previous object state, or checks time, location, and dependency conditions to generate object events.

[0034] For numeric fields, events can be generated based on absolute change, relative change rate, or exceeding a threshold; for discrete fields, events can be generated based on state transition tables; for time-based fields, events can be generated based on time intervals from the deadline; and for relational fields, events can be generated based on relation additions, deletions, or weight changes.

[0035] An example of an object event is: event_id=E1024, object_id=meal_next_20260806, event_type=nutrition_gap_available, changed_fields=[protein_gap,dinner_status], evidence_refs=[lunch_record_88], object_version=12, event_time=2026-08-06T17:30:00+08:00.

[0036] In step S104, the eligibility determiner calculates the subject's eligibility to speak voluntarily. An optional eligibility score is Q(i) = a1 × Significance of Change + a2 × Actionability + a3 × Timeliness + a4 × Completeness of Evidence - a5 × Silence Penalty - a6 × Recent Repetition, where a1 to a6 are configuration parameters. This expression is only one implementation; eligibility determination can also use a trained classification model or a ranking model.

[0037] The inputs for qualification determination include the object event, triggering policy, permission scope, recent speaking history of the contact, the user's current time window, terminal availability status, and silence rule; the outputs include eligible, eligibility_score, reason_codes, and recommended_lifecycle. reason_codes is used to record the reasons why the object has obtained or not obtained speaking qualification. III. Smart Contact Instantiation and Lifecycle

[0038] In step S105, the proxy engine 104 queries whether a reusable smart contact instance exists based on the object_id. If it does not exist, it generates an agent_id based on the object template and establishes a mapping between agent_id and object_id; if it already exists, it updates the object state reference, role constraints, and lifecycle.

[0039] The displayed identity of a contact can come directly from an object, such as "roadshow tomorrow afternoon," "this month's budget," "next meal," or "client awaiting a reply." The displayed identity can change with the event phase, but the internal object_id remains unchanged, or a mapping from multiple displayed identities to the same object_id can be maintained.

[0040] like Figure 4 As shown, the contact lifecycle includes the following states: Ungenerated (301), Candidate (302), Active (303), Waiting to Execute (304), Dormant (305), and Archived (306). After an object generates an event and gains speaking privileges, it moves from Ungenerated (301) to Candidate (302); after the target message is scheduled and presented, it enters Active (303); when the action bound to the message requires user confirmation or external dependency, it enters Waiting to Execute (304); when the event does not temporarily meet the speaking conditions, it enters Dormant (305); and when the object is completed, deleted, or becomes permanently invalid, it enters Archived (306).

[0041] Lifecycle transition rules are stored in `lifecycle_policy`. Example rules are: set to `active` when a message is presented and its validity has not expired; set to `waiting_execution` when the user confirms an action but the target service has not yet returned; set to `archived` when execution succeeds and the object enters the completed state; set to `dormant` and increase the silence time when a message is ignored three times consecutively. IV. Generation of Constrained Candidate Messages

[0042] In step S106, the candidate message generation module 105 reads the object state snapshot, object events, evidence references, contact role constraints, user context, and action registry to generate structured candidate messages. Message generation can be accomplished by rule templates, retrieval-enhanced generation models, large language models, or a combination thereof.

[0043] When using a large language model, the model input should include at least: object_snapshot, representing the current object fact; state_diff, representing the change compared to the previous version; evidence_refs, restricting citationable evidence; role_constraints, restricting contact position and language range; user_context, providing time, device, and reception status; available_action_schemas, limiting output actions; and conflict_hints, hinting at known conflicts.

[0044] The model output uses a preset structure, including preview_text, evidence_refs, action_id, arguments, validity_end, confidence, and fallback_text. preview_text is a message preview in the contact list; action_id and arguments must match the action pattern in the action registry; validity_end is used to prevent expired execution; when confidence is below a threshold, fallback_text is used or manual confirmation is initiated.

[0045] After generation, the structure validator checks the integrity and type of the fields; the fact validator checks whether the key facts in the preview_text can be supported by object_snapshot or evidence_refs; the permission validator checks whether action_id is located in allowed_actions; the parameter validator checks whether arguments are consistent with the action pattern; and the validity validator checks validity_end. If any validation fails, the candidate message is not entered into the scheduling queue, or it is regenerated using a deterministic template.

[0046] To reduce duplicate model calls, the system generates a message fingerprint based on object_id, object_version, event_type, evidence_refs, and action_id. When the same fingerprint exists in the cache and the message is still valid, the cached message is reused; when the object version changes, evidence is revoked, or the action mode changes, the corresponding cache is invalidated. V. Conflict Diagrams and Interactive Resource Budget Scheduling

[0047] In step S107, the interactive resource scheduling module 106 extracts the urgency, timeliness, actionability, user acceptability, evidence credibility, semantic redundancy, disturbance cost, interface occupancy, model call overhead, and network transmission overhead for each candidate message.

[0048] Semantic repetition relationships can be obtained through text vector similarity, shared object references, shared evidence references, and action identifier comparisons; conflicting relationship relationships can be obtained through action effect labels, rule matrices, or natural language inference models; mutual exclusion relationship relationships can be obtained through the mutex_group in the action registry; shared resource competition relationship relationships can be obtained through the resource_lock field; and time conflict relationships can be obtained through overlapping action time windows.

[0049] like Figure 5As shown, candidate messages 401 to 404 constitute conflict diagram 405. The interaction resource budget 406 can be set as follows: a maximum of three unread messages can be displayed within a fifteen-minute window, a maximum of one high-intrusion push can be made, the total number of tokens generated by the model cannot exceed a preset value, and the number of network requests cannot exceed a preset number. The scheduler 407 selects the target message set under this budget.

[0050] An optional comprehensive score is P(i) = w1 × urgency + w2 × timeliness + w3 × actionability + w4 × user acceptability + w5 × evidence credibility - w6 × semantic redundancy - w7 × disturbance cost - w8 × computational overhead. The scheduler aims to maximize the total score of the target message under constraints such as the total resource consumption of the target message not exceeding the budget and messages at both ends of a mutual exclusion edge not being selected simultaneously. This problem can be solved using greedy algorithms, dynamic programming, integer programming, or heuristic search.

[0051] In step S108, the scheduling results include presentation processing 408, merging processing 409, delay processing 410, and suppression processing 411. For highly repetitive messages or messages pointing to the same action, the system generates an aggregated message and retains multiple object_refs and multiple writeback_rules; for messages with mutually exclusive actions, the one with the higher score is retained and the other message is delayed, or a clarification message is generated; for low-priority messages, high-disturbance pushes are downgraded to ordinary unread items; messages that are invalid, lack evidence, or have no action value are suppressed. VI. Contact-based presentation

[0052] In step S109, the contact-based presentation module 107 displays the target message as a contact list item or a session item. The list item can display the contact identifier, message preview, unread status, object status, message validity period, and action entry point. The display order is determined by the scheduling result and is not necessarily equivalent to the message generation time.

[0053] The contact-based interface is just one way to present the target message. The core technology of this invention lies in the closed loop between object references, dynamic contact instances, conflict and budget scheduling, action descriptors, and state write-back. The target message can also be presented in a voice interface, in-vehicle terminal, wearable device, or other conversational interface. VII. Action verification, execution, and status write-back

[0054] In step S110, after the user selects an action entry point, the action binding module 108 reads the executable action descriptor. The action validator 503 checks the message validity period, permission level, parameter integrity, object version token, action execution conditions, and target service availability. For sensitive or irreversible actions, the confirmation_policy requires secondary confirmation.

[0055] like Figure 6 As shown, user terminal 501 submits object_ref, action_descriptor, and version_token through contact-style interface 502. Action validator 503 reads the current object version and state snapshot from object state graph 505. When the current object version is inconsistent with version_token, it indicates that the object has changed since the message was generated, and the system blocks execution and re-evaluates candidate messages.

[0056] After successful verification, action execution module 109 calls the target service (504). The target service returns status_code, business_result, and timestamp. The action execution module generates an idempotency_key, which the target service or this system uses to prevent the same action from being executed repeatedly due to network retries. For target services that support transactions or compensation actions, a rollback_policy is executed upon failure.

[0057] In step S111, the feedback write-back module 110 maps the execution result to changes in object fields based on result_mapping. For example, after the action "Create Interview Task" is successful, project.core_validation_task_count is incremented, project.last_progress_time is updated, and object_version is incremented; when the action fails, failure_reason and retry_after are recorded.

[0058] In step S112, the system updates the contact lifecycle and subsequent policies based on the write-back results. When the object's objective is successfully completed, the contact can be archived; if partially successful, the contact can remain in a waiting state and generate remaining actions; if the user ignores the contact, the message frequency can be reduced; if the user cancels, the object state is restored and the relevant objects are updated according to the rollback_policy. VIII. Data Structure Examples

[0059] like Figure 3 As shown, the domain object record 201, smart contact instance 202, candidate message record 203, executable action descriptor 204, action result record 205, and state write-back rule 206 form a closed loop.

[0060] An example of domain object record 201 is: object_id=project_alpha, object_type=project, state_vector={last_core_validation_time:2026-08-01, slide_edit_count_5d:23, interview_count_5d:0}, relative ons=[owned_by:user_1], evidence_refs=[edit_log_1, task_log_9], trigger_policy=execution_deviation_v2, permission_scope=[task_create, calendar_read], object_version=37.

[0061] An example of candidate message record 203 is: message_id=M9001, object_ref=project_alpha, evidence=[interview_count_5d=0, slide_edit_count_5d=23], utterance=“This project has not made progress in core validation for five days, so create three user interview tasks first”, validity=24 hours, action_descriptor={action_type:create_tasks, target_service:task_service, parameters:{count:3, template:user_interview}, version_token:37}, writeback_rule=project_task_mapping_v1.

[0062] The natural language text in the above example is only a message preview. The actual execution by the system is determined by the action_descriptor. Therefore, modifying the message wording will not change the action type, permission verification, and status write-back logic. IX. Example 1: Application of Youthful State Management

[0063] The system receives user-authorized diet records, sleep records, exercise records, schedules, and user input, and establishes domain objects such as "next meal," "sleep tonight," and "weekly activities." For example, if the lunch record shows insufficient protein intake and dinner has not yet been recorded, the "protein_gap" field of the "next meal" object exceeds a threshold, and the event detection module generates a "nutrition_gap_available" event.

[0064] The proxy engine activates the contact "Next Meal," and the candidate message generation module generates a message based on dietary evidence and available action patterns. Available actions include recording dinner choices, generating a shopping list, and creating a dinner reminder. If the "Sleep Tonight" object also suggests avoiding eating too late, the conflict detection module identifies a time conflict, and the scheduler merges the two messages into a nutritional supplement plan to be completed before bedtime, while retaining references to both objects. After the user makes a selection, the action results are written back to the "Next Meal" and "Sleep Tonight" objects respectively.

[0065] In this embodiment, the system does not make differentiated decisions directly based on age tags. The collection and processing of health data should be authorized by the user and can adopt local processing, field minimization, and permission isolation. 10. Example 2: Project Management Application

[0066] The system establishes projects, milestones, to-do items, customer responses, and deadlines as domain objects. When a project fails to advance core validation for five consecutive days while the number of presentation edits continues to increase, the project object generates an `execution_deviation` event. The proxy engine dynamically generates a contact named "Your Project," and messages are bound to actions such as "Create three user interview tasks," "Adjust today's task order," and "Open interview template."

[0067] After a user clicks "Create three user interview tasks," the action validator checks the project version and task service permissions. The action execution module calls the task service, and the feedback write-back module writes the new task identifier to the project object and updates the project progress. If the user has manually created a task after the message is generated and the project version has changed, the system prevents the old message from creating a task again and regenerates the status description. XI. Example 3: Personal Finance Application

[0068] The system establishes budget categories, bills, subscriptions, and funding goals as domain objects. When a subscription amount changes, the object generates an `amount_changed` event and gains the right to speak. Candidate messages are bound to actions such as viewing historical deductions, marking for retention, creating due date reminders, or redirecting to the service management page. If multiple subscriptions change simultaneously, the scheduler aggregates them into a "Subscription Changes This Month" contact under the message count budget, while retaining references to each subscription object and their respective write-back rules. 12. Example 4: Cross-application software development kit

[0069] Developers register object_schema, event_policy, agent_template, and action_schema using a software development kit (SDK). The application or server side writes business data into the object state graph, the scheduling service returns the target contact and message structure, and the client presents this information through a unified component. After the action is executed, the SSD sends a status code and business result back to the object state graph.

[0070] Example action registry entries include action_id, parameter_schema, permission_level, mutex_group, resource_lock, confirmation_policy, and result_mapping. Through the action registry, the message generation model can only select from registered actions and cannot construct unknown interfaces on its own. XIII. Deployment and Performance Optimization Examples

[0071] In a distributed deployment, the data access module and object state graph module can be deployed on the business server, the candidate message generation module can be deployed on the model service, and the contact-based presentation module can be deployed on the terminal. Object updates are transmitted via a message queue, and event_id and idempotency_key are used for deduplication.

[0072] The system can segment the object state graph by object_id and maintain interaction resource budgets by user or terminal. Recently active objects are kept in a hot cache, while dormant or archived objects are moved to cold storage. Candidate messages are cached via message_fingerprint, and the cache is synchronized with business state and invalidated using object version tokens.

[0073] In one test implementation, the number of candidate messages before scheduling, the number of messages displayed after scheduling, the number of model calls, the number of network requests, the number of page jumps, the action success rate, and the state consistency rate can be recorded. The above data can be used to adjust budget parameters and triggering strategies, but does not constitute a limitation on the scope of protection of this invention. XIV. Other Implementation Methods

[0074] Domain objects can be pre-registered by developers or automatically created by the object recognition module based on database schema, application interface description, event logs, or user selection. A contact can correspond to a single object or multiple objects that meet aggregation criteria.

[0075] Determining speaking eligibility, message generation, and scheduling can all be based on deterministic rules, or partially on machine learning models. This invention can be implemented as long as the system maintains the technical relationships of object references, structured actions, conflict and resource constraints, and result write-back.

[0076] Any equivalent substitutions or modifications made by those skilled in the art to the above embodiments without departing from the spirit and essence of the present invention shall fall within the protection scope of the present invention.

Claims

1. A proactive human-computer interaction method based on domain object proxying, characterized in that, Executed by at least one processor, the method includes: acquiring data of multiple domain objects in at least one business system; standardizing the data into object records that respectively contain object identifiers, object types, and object states; and establishing or updating an object state graph based on the object records; detecting changes in object states in the object state graph; generating corresponding object events based on the object state changes; and determining the domain object's eligibility to speak proactively based on the object events, the corresponding domain object's role constraints, and the user context; instantiating the domain object with the eligibility to speak proactively as a candidate smart contact; and generating a candidate message corresponding to the candidate smart contact based on the object records, wherein the candidate message includes at least an object reference pointing to the domain object and a method for invoking a target. The service generates an executable action descriptor; it acquires the scheduling characteristics of multiple candidate messages, constructs conflict relationships among the candidate messages, and performs at least one of the following processes—selection, merging, delay, and suppression—on the multiple candidate messages under the constraints of the interaction resource budget and the conflict relationships to obtain a target message; it presents the target message in a conversational user interface with the corresponding smart contact as the main body; in response to the user's operation on the target message, it verifies the current state of the executable action descriptor and the domain object, and calls the target service to execute the target action when the verification passes; it writes back the execution result of the target action to the domain object pointed to by the object reference to update the object state graph, the lifecycle of the corresponding smart contact, and the triggering strategy of subsequent object events.

2. The method according to claim 1, characterized in that, The object record also includes at least one of the following: state vector, object relationship, evidence index, update time, triggering strategy, permission scope, object version, and lifecycle; the object state graph includes object nodes representing domain objects and relationship edges representing the relationships between domain objects and users, other domain objects, or target services. Detecting changes in the object state includes calculating the difference between the current object state and the previous object state, or detecting the arrival of preset time, location, external dependency, data arrival, or action execution conditions, and generating an object event containing at least one of the following when the difference value or condition meets the triggering strategy: object identifier, change field, change magnitude, event time, evidence reference, and object version.

3. The method according to claim 1, characterized in that, Instantiating the domain object as a candidate smart contact includes: generating or reading at least one of the following: contact identifier, role position, language constraints, knowledge scope, memory reference, set of callable actions, and lifecycle state of the candidate smart contact based on the object type, current object state, object relationship, and permission scope of the domain object, so that the candidate smart contact maintains a mapping relationship with the object identifier of at least one domain object; and switching the lifecycle state between at least two of the following states: ungenerated state, candidate state, active state, waiting to be executed state, dormant state, and archived state, based on the result of object event, message presentation, action waiting, object completion, event invalidation, or user ignore.

4. The method according to claim 1, characterized in that, Generating the candidate message includes: taking an object state snapshot, object state changes, evidence references, role constraints, user context, and available action patterns as input to a message generation model, and making the message generation model output a natural language preview, evidence references, action identifiers, action parameters, message validity period, and confidence level that conform to a preset structure; using a rule validator or another model to verify whether the output references real object facts, whether it is within the permission scope, whether it is consistent with the action parameters, and whether it meets the message validity period, and using the output that passes the verification as the candidate message; generating a message fingerprint based on the object identifier, object version, trigger evidence, and action identifier, reusing the message when a message matching the message fingerprint exists in the cache and is still valid, and invalidating the corresponding cache when the object version changes.

5. The method according to claim 1, characterized in that, The scheduling features include at least two of the following: urgency, timeliness, actionability, user acceptability, evidence credibility, semantic redundancy, disturbance cost, interface occupancy, model invocation overhead, and network transmission overhead; the interaction resource budget includes at least one of the following: the number of messages allowed to be presented within a preset time window, total disturbance cost, interface occupancy, push channel occupancy, model invocation resources, and network transmission resources; the conflict relationships include at least one of the following: semantic redundancy relationship, suggestion contradiction relationship, action mutual exclusion relationship, shared resource competition relationship, and time conflict relationship, and are represented by a conflict graph; the merging process for the multiple candidate messages includes aggregating at least two candidate messages that have semantic redundancy relationship, share trigger evidence, or point to the same target action into a single target message, and retaining multiple object references pointing to corresponding domain objects and state write-back rules applicable to the multiple object references in the target message.

6. The method according to claim 1, characterized in that, The executable action descriptor includes at least one of the following: action type, target service, interface or function identifier, action parameters, permission level, confirmation policy, timeout, object version token, idempotent identifier, failure rollback policy, and result mapping rule. The verification of the executable action descriptor and the current state of the domain object includes: verifying whether the target message is within the message validity period, whether the object version token matches the current object version of the domain object, whether the user has the corresponding permissions, whether the action parameters are complete, and whether the target action meets the execution conditions of the current object state; if any verification fails, execution is blocked, the user is requested to supplement parameters, or the target message is regenerated based on the updated object state.

7. The method according to claim 1, characterized in that, Writing the execution result back to the domain object includes: mapping the execution status code, business result, user confirmation result, user ignore result, timeout result, or cancellation result to a new object state of the domain object according to the result mapping rules; avoiding repeated writing back of the same execution result based on idempotency identifiers; updating the lifecycle, trigger threshold, message frequency, or silence time of the smart contact according to the new object state; the conversational user interface includes a smart contact list, each list item in the smart contact list corresponds to at least one domain object, and displays at least one of the following: smart contact identifier, message preview, unread status, object status, message validity period, and executable action entry point, the order of the list items is determined by the scheduling feature and the interaction resource budget.

8. A proactive human-computer interaction system based on domain object proxying, characterized in that, include: The data access module is used to acquire and standardize data from multiple domain objects; the object state graph module is used to establish or update an object state graph containing object identifiers and object states. The event detection module is used to detect changes in the state of an object and generate object events; The proxy engine is used to determine the eligibility of domain objects to speak proactively and to instantiate domain objects with such eligibility into candidate smart contacts. The candidate message generation module is used to generate candidate messages that include at least an object reference and an executable action descriptor. An interactive resource scheduling module is used to construct conflict relationships between candidate messages and obtain the target message under the constraints of the interactive resource budget and the conflict relationships. The contact-based presentation module is used to present the target message as the corresponding smart contact in a conversational user interface; The action execution module is used to verify the current state of the executable action descriptor and the domain object, and to call the target service to execute the target action; It also includes a feedback write-back module, which writes back the execution result of the target action to the domain object pointed to by the object reference, so as to update the object state graph, the smart contact lifecycle and subsequent triggering strategies.

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

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

Images