A multi-tenant enterprise intelligent agent closed-loop collaboration system and method

Abstract

The application discloses a multi-tenant enterprise intelligent agent closed-loop cooperation system and method, and relates to the technical field of distributed computing and multi-tenant data processing. The application generates a request context for a business request, which is bound with a tenant identifier, an identity version, a session revision number and a target resource revision number; an immutable capability snapshot is generated before model and tool calling, and permission and version review are performed on knowledge and memory candidates; task execution and fault recovery are controlled in combination with a business idempotent key, a lease and a barrier token; independent verification is performed after task completion, and only when the returned result matches the current state of the system, the knowledge candidate or the memory candidate is allowed to be generated and written. The application solves the technical problems of cross-tenant data pollution, misuse of expired state, repeated side effects caused by at least one time delivery of a message queue and direct pollution of enterprise knowledge base memory by model output in the multi-tenant enterprise intelligent agent scenario, and realizes safe, controllable and auditable closed-loop cooperation of intelligent agent tasks.

Description

Technical Field

[0001] This invention relates to the fields of distributed computing and multi-tenant data processing technology, specifically to a system and method for enterprise intelligent agents to perform consistency control on request context, evidence version, execution status, and result verification. Background Technology

[0002] Enterprise intelligent agent systems typically comprise multiple components, including knowledge retrieval, session memory, model inference, tool invocation, and front-end interaction. In existing solutions, each component is built independently. When the same business request is passed across components, there is a lack of unified tenant identifiers, identity versions, corpus versions, and task status constraints. Individual component success responses do not necessarily indicate overall business completion, nor do they confirm that the returned results are suitable for the current tenant, session, and business object.

[0003] In the knowledge retrieval stage, vector indexes are suitable for quickly recalling similar content, but the recalled candidates may correspond to deactivated documents, old version segments, or data accessed beyond authorized scopes. Directly using vector recall results as the basis for answers is prone to using expired or unauthorized data. Changes to the corpus during long-duration retrieval processes can also result in a single retrieval output coming from different versions of the corpus.

[0004] In the memory processing stage, directly rewriting historical dialogues by the model will result in the loss of limiting conditions, sources of evidence, and negation relationships; directly writing model summaries and tool outputs into long-term memory will solidify speculative content as corporate facts. Content from different tenants, different topics, and different sensitivity levels will be mixed during the context compression and candidate recall stages, causing information pollution.

[0005] In the task execution phase, message queues, scheduled tasks, and long-running worker nodes generally employ at least-once delivery semantics. Work node timeouts, restarts, and lease transfers can cause tasks to be retrieved repeatedly. Relying solely on successful network responses and task termination markers to determine business completion cannot prevent the repeated execution of external side effects such as creation, allocation, and notification.

[0006] Existing multi-agent collaborative architecture solutions mostly focus on optimizing the communication and interaction protocols between agents, primarily addressing communication layer issues such as agent calls and circular dependencies. They lack a comprehensive, closed-loop version and permission management mechanism covering the entire process—from request access and capability admission to knowledge memory acquisition, controlled task execution, independent result verification, and controlled candidate write-back—specifically for multi-tenant enterprise business scenarios. When users switch enterprises, identities, knowledge bases, or page filtering conditions, older requests often return later than newer requests, potentially causing page state inconsistencies. Furthermore, parsing rich text before streaming content is complete can lead to page instability and security risks. Current technologies lack a complete closed-loop management solution that spans the entire process from request access to capability admission, knowledge memory acquisition, controlled execution, result verification, and candidate write-back. Summary of the Invention Technical problems to be solved

[0007] The technical problem this invention aims to solve is to overcome the shortcomings of existing technologies and provide a multi-tenant enterprise intelligent agent closed-loop collaborative system and method. This ensures that when a business request crosses various components—interaction, operational control, knowledge, memory, and execution—it carries verifiable context and revision information throughout the entire process. For results with external side effects or knowledge memory accumulation, permission verification, version verification, and business completion verification are required before they can be applied, thus avoiding cross-tenant pollution, misuse of expired states, duplicate side effects, and model output pollution of the enterprise knowledge base. Technical solution

[0008] To solve the above technical problems, the present invention provides a multi-tenant enterprise intelligent agent closed-loop collaborative system, including an interactive access subsystem (110), an operation control subsystem (120), a knowledge base subsystem (130), a hierarchical memory subsystem (140), a task execution subsystem (150), and a result verification and candidate write-back subsystem (160); each subsystem completes collaboration by relying on a unified request context (201) and a business result object (206).

[0009] The interactive access subsystem (110) receives business requests and generates a request context (201). The request context (201) records at least the tenant identifier, subject identity version, session revision number, business scope, target resource identifier, request sequence number, and generation time; it may also record page information, filtering conditions, knowledge base, and attachment version. Subsequent returned results must carry the request context identifier and the corresponding revision information.

[0010] The operation control subsystem (120) obtains the allowed capability set by taking the intersection of the code capability registry, industry capability package, customer capability package, module permissions, risk constraints, evidence preconditions, and operating environment status, and generates an immutable capability snapshot (202). Capability access verification is performed before establishing task operation records (205), calling models, or calling tools; if any access element is missing, invalid, or inconsistent, further processing is refused.

[0011] The knowledge base subsystem (130) uses relational data storage to store documents, segments, versions, and permission status as authoritative states; object storage stores the original files; and vector indexes are used only for candidate recall. Before a candidate is used, it is re-verified according to the tenant, knowledge base, corpus revision number, document and segment status, access scope, and validity period.

[0012] The hierarchical memory subsystem (140) handles the current session context, compressed context view, and enterprise memory respectively. The original dialogue and valid enterprise memory are stored in the authoritative data store; the vector index is only used for candidate retrieval. The complete question-and-answer rounds are preserved when compressing the context; when quoting the original text, the message identifier, role, and continuous substring relationship are verified; enterprise memory needs to generate controlled source memory candidates first, and can only take effect after being reviewed for version, scope, sensitivity level, validity period, and conflict status.

[0013] The task execution subsystem (150) establishes a task execution record (205) for each executable request. The task execution record (205) includes at least the task type, business idempotent key, execution mode, number of attempts, lease expiration time, barrier token, deadline, and cancellation status. Before a worker node generates external side effects, the lease, barrier token, and business idempotent key are re-verified; when a task resumes, only actions that have not yet been completed are executed.

[0014] The result verification and candidate write-back subsystem (160) records the network call success, task termination status and business completion status separately; it obtains completion evidence by relying on preset business completion conditions or independent read-only verification; only business results that pass verification can generate knowledge candidates or memory candidates (207); the original output of the model and the original output of the tool cannot directly become effective knowledge or effective memory.

[0015] The present invention also provides a closed-loop collaborative method for multi-tenant enterprise intelligent agents, including request context generation, capability access verification, evidence and memory acquisition, task execution record establishment, controlled execution, independent verification, candidate generation, and current revision review steps. Beneficial effects

[0016] Compared with existing technologies, this invention has the following advantages: It blocks data pollution caused by cross-tenant issues, identity changes, and page expiration through a unified request context mechanism; it avoids the direct use of expired or unauthorized knowledge content due to vector index recall through authoritative state verification; it alleviates the repetitive external side effects of message queue at least-once delivery semantics through leases, barrier tokens, and business idempotent keys; it prevents unverified model outputs from directly polluting enterprise knowledge and memory through independent verification and candidate verification mechanisms; it avoids unnecessary model and tool calls in unauthorized scenarios through pre-configured capability access verification; it achieves secure recovery after task interruption by relying on checkpoints and replay of incomplete actions; and it makes all key operations auditable, adapting to enterprise multi-tenant business management requirements. Attached Figure Description

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

[0018] Figure 2This is a schematic diagram of the unified request context processing flow according to an embodiment of the present invention.

[0019] Figure 3 This is a schematic diagram of the knowledge entry and retrieval verification process according to an embodiment of the present invention.

[0020] Figure 4 This is a schematic diagram of the context and enterprise memory management process according to an embodiment of the present invention.

[0021] Figure 5 This is a schematic diagram of the task running status and recovery process according to an embodiment of the present invention.

[0022] Figure 6 This is a schematic diagram of the risk classification and confirmation execution process according to an embodiment of the present invention.

[0023] Figure 7 This is a schematic diagram of front-end request revision and streaming response processing according to an embodiment of the present invention.

[0024] Figure 8 This is a schematic diagram of result verification and candidate write-back closed loop according to an embodiment of the present invention. Figure Labels

[0025] Figure labeling: 110 Interactive access subsystem, 120 Operation control subsystem, 130 Knowledge foundation subsystem, 140 Hierarchical memory subsystem, 150 Task execution subsystem, 160 Result verification and candidate write-back subsystem, 170 Audit storage, 180 Model and tool gateway; 201 Request context, 202 Capability snapshot, 203 Evidence set, 204 Context set and memory set, 205 Task execution record, 206 Business result object, 207 Knowledge candidate or memory candidate. Detailed Implementation

[0026] The embodiments of the present invention will be further described below with reference to the accompanying drawings. These embodiments are intended to explain the invention and not to limit its scope. Without departing from the overall inventive concept of unified request context, controlled execution, and post-verification write-back, each subsystem can be deployed as an independent service, a module within the same process, or implemented jointly by multiple computing nodes. Example 1: Overall System Architecture (corresponding to) Figure 1 )

[0027] like Figure 1As shown, the closed-loop collaborative system includes an interactive access subsystem (110), an operation control subsystem (120), a knowledge foundation subsystem (130), a hierarchical memory subsystem (140), a task execution subsystem (150), a result verification and candidate write-back subsystem (160), an audit storage system (170), and a model and tool gateway (180). Each subsystem can communicate through certified application programming interfaces, message queues, or internal service calls.

[0028] The interactive access subsystem (110) can be implemented by a browser front-end, mobile terminal, desktop client or controlled external interface; the operation control subsystem (120) is responsible for the management of tenants, members, roles, capability packages and operating environment; the knowledge foundation subsystem (130) is responsible for the controlled entry and retrieval of enterprise data; the hierarchical memory subsystem (140) is responsible for the current context, compressed context and enterprise memory; the task execution subsystem (150) is responsible for planning, tool invocation and work node scheduling; the result verification and candidate write-back subsystem (160) is responsible for completing evidence verification, review summary and candidate governance.

[0029] The request context (201) is represented as an immutable record or an append-only version record. An example data structure includes contextId, tenantId, principalRevision, sessionRevision, businessScope, targetResourceId, resourceRevision, requestSequence, createdAt, and traceId. The contextId can be generated from a random identifier or from a combination of a normalized digest of the above fields and a random variable.

[0030] When receiving a request, each subsystem first verifies the contextId, tenantId, and principalRevision, and then verifies the revision fields relevant to its own processing. Subsystems must not directly use the tenantId passed in by the client as the basis for authorization; client fields can only narrow the tenant scope resolved by the server based on tokens, membership relationships, and role scopes, and cannot expand this scope. Cross-tenant data reference requests are processed at the interface layer as not found or without permission, and written to audit events.

[0031] The system adopts a failure shutdown strategy. When tenants are inconsistent, identity versions are invalid, permissions are revoked, capability snapshots (202) expire, corpus revisions change, leases are lost, fence tokens are outdated, approval snapshots are inconsistent, or completion evidence is insufficient, the system will not continue execution with the default value, will not automatically switch to the old link, and will not mark some results as business success. Example 2: Unified Request Context and Capability Admission (corresponding to) Figure 2 )

[0032] like Figure 2 As shown, after receiving a service request, the interactive access subsystem (110) establishes a request context (201) and submits it to the operation control subsystem (120). After completing the capability access, the operation control subsystem (120) returns a capability snapshot (202); the knowledge foundation subsystem (130) and the hierarchical memory subsystem (140) generate an evidence set (203) and a context set and a memory set (204) within the scope defined by the capability snapshot (202), respectively; the task execution subsystem (150) establishes a task execution record (205) and executes it; the result verification and candidate write-back subsystem (160) generates a service result object (206).

[0033] The business result object (206) records at least the business result status, completion evidence reference, independent verification status, user-visible summary, diagnostic information, usage information, and the corresponding contextId. The interactive access subsystem (110) rereads the current tenant, identity, session, and target resource status before applying the business result object (206); if any revised field is different from when the request was initiated, the result is marked as expired and returned without updating the current page.

[0034] The Operations Control Subsystem (120) maintains a registry of code capabilities. Each capability record includes a unique capability identifier, implementation version, allowed executors, input / output constraints, callable tools, risk level, required evidence type, applicable environment, and deactivated status. Industry capability packages and customer capability packages only reference registered capabilities and form an immutable snapshot with version number, content summary, and release time.

[0035] The allowed capability set is the intersection of capabilities permitted by code registration, industry capability packages, customer capability packages, module permissions, risk constraints, evidentiary conditions, and environmental status. Each access element forms a computable set or equivalent Boolean condition; the above intersection relationship is used to illustrate the hierarchical convergence of capabilities, without limiting the specific storage and calculation method of the set.

[0036] Capability package changes employ a preview, release, and rollback process. During release, the target tenant, current version, change summary, content summary, and operator are recorded. The database is locked or optimistic concurrency control is used to re-validate the current version. If validation passes, a new version is created without overwriting historical versions. Rollback similarly creates a new version pointing to the old content, maintaining the continuity of the historical audit chain.

[0037] When administrators need to view configurations across customers, the operations control subsystem (120) simultaneously verifies management permissions, the scope of customers visible to roles, and the target customer explicitly specified in the request. Query results are projected in read-only mode, preventing them from exceeding the server's scope due to customer identifiers passed from the front end. When switching customers, a customer revision number is added, and the results returned by requests from old customers must not be written to the new customer's page status. Example 3: Knowledge entry and retrieval verification (corresponding to) Figure 3 )

[0038] like Figure 3 As shown, after receiving the file and the target knowledge base, the knowledge base subsystem (130) sequentially performs tenant and permission verification, actual file byte count verification, file header sampling, media type identification, and SHA-256 digest calculation. Files that pass the verification are written to the object path isolated by tenant, and a stable object reference is established; incomplete objects and intermediate records are cleaned up when uploading or parsing fails.

[0039] The parsing task establishes an independent task identifier and business version summary. The parser extracts text in a controlled manner according to file type, setting upper limits for page count, character count, decompression size, processing time, and output quantity. For external data obtained via HTTP or HTTPS, domain name resolution and target address verification are performed on each redirect to block access to local, reserved, or unauthorized network addresses.

[0040] The document is divided into multiple segments. Each segment records at least documentId, segmentId, sequence, textDigest, businessVersion, status, and sourceLocation. The document, segment, and version records in the relational data store constitute the authority state; the embedded vector is written to the vector index according to the stable segment identifier, and the successful vector write does not change the attribution of the authority state.

[0041] After calling the embedding service, the knowledge base subsystem (130) verifies the returned quantity, order, numerical validity, vector dimension, and usage information. When only a portion of a batch of segments is written to the vector index, the task remains replayable; upon re-execution, the completed portion is skipped based on the task identifier, business version summary, and segment summary.

[0042] Before the retrieval begins, the knowledge base subsystem (130) parses the authorized knowledge base scope and generates a corpus scope fingerprint, while simultaneously reading the monotonically increasing corpus revision number. The retrieval first retrieves segment identifiers from the vector index or other candidate indexes, and then verifies the tenant, knowledge base, document status, segment status, business version, and access scope in the authoritative data storage.

[0043] If the corpus revision number at the end of the retrieval task differs from that at the beginning, or if the corpus range fingerprint no longer corresponds to the current authorized range, then this candidate will be rejected as formal evidence output. Even if the corpus content changes and then recovers during the task, the change can still be identified as long as the monotonically increasing revision number changes.

[0044] Each evidence item in the evidence set (203) may include sourceType, sourceId, sourceLocation, corpusRevision, accessScope, validityStatus, contentDigest, and excerpt. When an evidence item is passed to the task execution subsystem (150), its source and scope are preserved, and model-generated paraphrases may not replace the original source references.

[0045] For suspected duplicate documents or new / old versions, the knowledge foundation subsystem (130) generates candidate relationships based on document summaries, text fingerprints, and similarity. When manually confirming merging, replacing, or coexisting, the relationship revision number and decision snapshot are bound; if the relationship revision number has changed at the time of submission, the old decision is rejected from overwriting the current state. Example 4: Context and Enterprise Memory Governance (corresponding) Figure 4 )

[0046] like Figure 4 As shown, the hierarchical memory subsystem (140) includes the original dialogue storage, the current context construction, the compressed context view, the enterprise memory candidate pool, and the effective enterprise memory storage. The original dialogue and the effective enterprise memory are stored in the authoritative data storage; the vector index only stores the vectors used for candidate recall and the stable memory identifiers.

[0047] The current context prioritizes the most recent complete user-assistant Q&A round, and does not append failed conversations with missing responses as completed conversations. New context boundaries are established when the topic changes significantly, or when the tenant or business scope changes. One non-limiting embodiment retains the four most recent complete rounds, a maximum of forty messages, or approximately four thousand eight hundred tokens. These parameters are merely illustrative and do not constitute a limitation on the scope of protection of this invention; those skilled in the art can adjust them according to actual business needs.

[0048] Compression is triggered when the expected amount of historical messages, current issues, and necessary evidence exceeds a preset proportion of the model window. One embodiment triggers compression when the expected amount exceeds 60% of the window. This parameter is merely illustrative and does not constitute a limitation on the scope of protection of this invention; those skilled in the art can adjust it according to actual business needs. The compression model is only responsible for selecting continuous original text fragments from the messages actually sent to the model or generating contextual hints that are not considered evidence; the server verifies the message identifier, role, and continuous substring relationships before saving quotable fragments.

[0049] Information containing access credentials, key-like content, or information explicitly prohibited from model use is not included in the compressed input. Compression boundaries can only be advanced to a complete, closed round. If compression fails, the original message is preserved and auxiliary memory is reduced. Unverified model summaries must not be substituted for Goals, Evidence, or permission facts.

[0050] Enterprise memory candidates can come from validated task debriefings, controlled enterprise data, or input from authorized personnel, but not directly from the assistant's free responses or the tool's raw output. Candidate records must include at least memoryKey, scope, sourceChain, sourceDigest, candidateVersion, sensitivity, validFrom, validTo, and status.

[0051] Candidate merging employs a decision of creating, merging, replacing, or ignoring. Upon submission for review, currently valid memories under the same memoryKey and scope are locked or reread; if the current version differs from the review snapshot, the old review result is rejected. Valid enterprise memories are represented by explicit states such as ACTIVE; successful processing of a work node does not equate to the enterprise memory being reviewed and effective.

[0052] When retrieving enterprise memories, tenants, scope, status, and time are first filtered using structured conditions, and then vector indexes can be used to enhance candidate recall. After recall, the current status, usage permissions, applicable business, model availability flag, sensitivity level, and conflict status are verified again. Any candidate that fails the verification is not included in the context set and memory set (204).

[0053] When constructing the model context, allocate the budget according to the objective, evidence, current problem, effective memory, and historical rounds. If the budget is insufficient, omit auxiliary memory first, then omit earlier complete rounds, without truncating the current objective and key evidence; if the core content still exceeds the limit, return a diagnosable error before calling the model. Example 5: Task Execution and Recovery (corresponding) Figure 5 )

[0054] like Figure 5 As shown, the task execution subsystem (150) maps task types to unique runtimes through a unified scheduling entry point. The runtime registry specifies the executor, version, timeout, toolset, and risk contract for each task type, and prohibits silent rollback to the old execution chain that is not constrained by the current capability snapshot (202) after the new runtime fails.

[0055] The task execution log (205) may include taskRunId, taskType, businessIdempotencyKey, runtimeVersion, executionMode, attempt, leaseOwner, leaseExpiresAt, fencingToken, deadlineAt, cancelRequestedAt, status, summary, and diagnostics. businessIdempotencyKey is generated from the stable business objective, operation type, and confirmed parameter summary.

[0056] Worker nodes acquire pending tasks through short transactions, writing the lease owner, lease expiration time, and incrementing fence token. Renewal, state transition, and result writing all come with the current fence token as a condition; worker nodes with lagging tokens cannot commit to the final state or trigger new external side effects, even if they continue to run.

[0057] Task recovery employs at-least-once delivery semantics. The system does not claim strict exactly-once execution at the infrastructure level, but instead utilizes business idempotent keys, action states, and stability identifiers returned by external systems to control business side effects. Checkpoints store completed actions, remaining actions, evidence summaries, capability snapshot identifiers, and encrypted necessary request data.

[0058] Before executing the tool, the task execution subsystem (150) sequentially verifies the code tool registration, executor binding, customer capability package, module permissions, business scope, risk contract, parameter whitelist, output cleanup rules, and audit requirements. Providing the model with arbitrary SQL, arbitrary database writes, or unregistered high-risk tools is prohibited. Content returned by read-only business data tools is still treated as evidence with source and scope.

[0059] Task understanding, capability selection, and tool authorization are handled in a hierarchical manner. The model can suggest task types or actions, but the final capability selection is determined by the operations control subsystem (120) and the task execution subsystem (150) according to structured rules. A single prompt word cannot simultaneously determine permissions, tool availability, and the final business outcome.

[0060] For controlled execution requiring multi-step reasoning, one embodiment employs a loop of planning, action, observation, reflection or replanning, and verification. Each round calls at most one currently permitted low-risk tool, and sets the total number of rounds, the number of tool calls, and the upper limit of execution time. For example, a maximum of three rounds, three tool calls, and fifteen seconds of foreground execution time can be set. These parameters are merely illustrative and do not constitute a limitation on the scope of protection of this invention. Those skilled in the art can adjust them according to actual business needs. When the upper limit is exceeded, it is converted into a persistent working node or returns to a controlled incomplete state.

[0061] Actions that have been completed and passed idempotency verification are removed from subsequent plans. When there are changes to the capability contract, failure to ensure evidence integrity, loss of the lease, the cancellation request taking effect, or independent verification failing to complete, the task stops and diagnostic information is saved; completion results are not automatically generated. Model input / output and technical scenario correlation

[0062] In embodiments involving model reasoning, the model input received by the model and tool gateway (180) is determined by the task execution subsystem (150) based on the request context (201) and capability snapshot (202), and includes at least a normalized target description, evidence items verified by permissions and version, memory items verified by lifecycle, allowed output modes, and constraint information corresponding to the current task type; the tenant scope, tool permissions, risk level, and approval conclusion are not determined by the model input text.

[0063] The normalized target description originates from the current business request and is associated with contextId, sessionRevision, and resourceRevision; the evidence item retains sourceId, sourceLocation, corpusRevision, and contentDigest; the memory item retains scope, candidateVersion, and sourceDigest. The model receives content trimmed within the current capability snapshot (202) and does not accept unauthorized knowledge bases, data from other tenants, access credentials, or instructions that can directly expand tool permissions.

[0064] The model output is returned according to a predefined structure, which may include a draft answer, candidate task types, candidate tool actions, candidate parameters, evidence references, and confidence information. The server sequentially verifies the output structure, field lengths, whether candidate actions belong to the tool whitelist, whether parameters conform to the field whitelist, and whether the referenced evidence identifiers come from the current evidence set (203). If any verification fails, the model output is saved as an unexecutable draft or rejected directly.

[0065] For read-only answers, the interactive access subsystem (110) displays the cleaned-up answer draft only when the request context (201) and revision information are still consistent; for tool action candidates, the task execution subsystem (150) re-executes the verification of capabilities, permissions, risks, parameters, business idempotent keys, leases and fence tokens; for content that may form knowledge or memory, the result verification and candidate write-back subsystem (160) generates candidates based on independent completion evidence, and the model output cannot directly change the authoritative business status.

[0066] This embodiment does not limit the specific model structure or training method. When the model provider or model version changes, the model and tool gateway (180) still use the same input pruning rules, output mode and validation contract; when the new model cannot meet the output mode, context budget, data range or security constraints, the processing is terminated before the call or during the parsing stage, thereby maintaining the deterministic association between model inference and multi-tenant enterprise task scenarios. Example 6: Risk Classification and Execution Confirmation (corresponding to) Figure 6 )

[0067] This embodiment classifies operations into risk levels R0 to R3. R0 is a controlled read-only operation; R1 is a revocable draft or preview operation; R2 is an operation that creates, assigns, or changes the status of a business object and requires explicit confirmation; R3 is an operation prohibited by policy, such as financial instructions, critical deletions, or large-scale external transmissions. Risk levels and operation examples can be configured according to tenant policies.

[0068] like Figure 6 As shown, the R2 operation first generates an operation draft and preview. An immutable operation snapshot records at least the target object, the target's current revision number, the approver, the responsible person, a summary of normalized parameters, a capability snapshot identifier, and the creation time. After receiving explicit confirmation, the system re-verifies the above fields and executes only if the confirmed object, version, and summary are completely consistent.

[0069] When retrying the R2 operation, the stable business idempotent key corresponding to the original approver, target version, and parameter summary is used, and the new target state is not interpreted as a continuation of the old approval. If the target object changes after approval, the original approval becomes invalid and a conflict message is returned.

[0070] After the task is completed, the result verification and candidate write-back subsystem (160) selects an independent verifier based on the task type. For example, after creating a business object, the object identifier, key fields, and version are read back through a read-only interface; after generating a document, the file summary, page number, and openability are verified; after sending a notification, the controlled delivery receipt is verified. An HTTP status code of success only constitutes the call information and does not constitute separate evidence of business completion. Example 7: Front-end Request Revision and Streaming Response Processing (corresponding to) Figure 7 )

[0071] like Figure 7 As shown, the interactive access subsystem (110) maintains independent or combined revision numbers for identity, session, tenant, knowledge base, customer, page, filter conditions, and target resource. Each asynchronous request captures a snapshot at the time of initiation and associates it with a cancellation controller; a new request can cancel an old request, but the end callback of the old request cannot close the loading state of the new request.

[0072] For server-sent event-based streaming responses, the interactive access subsystem (110) saves data incrementally in plain text during reception and merges page updates within a fixed cooling window to reduce high-frequency document object model operations. Markup language parsing and whitelist-based node cleanup are only performed after a normal termination event is received and the request context (201) is still valid.

[0073] When the streaming response is abnormally interrupted, unfinished content is retained as plain text or marked as incomplete and is not considered a verified business result. Scrolling operations are merged in animation frames or equivalent scheduling mechanisms to avoid triggering independent layout calculations for each increment.

[0074] File uploads and status polling use the target revision number and tombstone status. When a user deletes an attachment or switches the target resource, the revision number is incremented and a tombstone is set; late upload receipts or polling results, even if they show successful processing, cannot clear the tombstone or make the old attachment reappear on the current page.

[0075] For real-time meetings or long file uploads, one embodiment retains the complete record locally as a source for recovery, while recording the server confirmation level during chunked uploads. Before closing the page or ending the meeting, it waits for the local chunks to be written to disk and for necessary server confirmation; the official text result is generated only from the complete uploaded file or verifiable server record, and local recovery data is not deleted if closing the page fails.

[0076] The interactive access subsystem (110) can maintain enterprise user terminal tokens and operation management terminal tokens separately, and set different audiences for the two. An unauthorized response from one terminal only clears the authentication status of the corresponding terminal and must not clear the valid session of the other terminal. Example 8: Result Verification and Candidate Write-back Closed Loop (corresponding to) Figure 8 )

[0077] like Figure 8 As shown, the result verification and candidate write-back subsystem (160) generates a business result object (206) after receiving the task's final state, and obtains completion evidence from the task execution record (205), external system readback, file digest, or other read-only verifiers. The verifier uses a different permission path than the executor or at least uses independent read-only operations to reduce misjudgments caused by the executor's self-verification of completion.

[0078] Upon successful verification, a knowledge candidate or memory candidate is generated (207). The candidate retains sourceChain, sourceDigest, contextId, taskRunId, scope, candidateVersion, sensitivity, and verificationResult. The knowledge base subsystem (130) or the hierarchical memory subsystem (140) performs source, scope, current version, and conflict verification based on the candidate type.

[0079] A new authoritative version is created or the stored state is updated to valid only after a candidate has passed review. In case of review failure, version conflict, or permission revocation, the candidate and the reason for failure are retained, without overwriting existing authoritative records. This creates an auditable closed loop while preventing the direct interpretation of a single model inference output as business fact.

[0080] When a task is cancelled during execution, the interactive access subsystem (110) records the cancellation request, and the task execution subsystem (150) checks the cancellation status before model invocation, tool invocation, external side effects, checkpoint submission, and final state writing. External actions that have occurred and cannot be automatically undone are recorded as partially completed, and the result verification and candidate write-back subsystem (160) generates diagnostic results that require manual processing.

[0081] When a worker node loses its lease, the new node recovers based on the task execution record (205) and encrypted checkpoints, reacquires the current capability snapshot (202), evidence set (203), and context set and memory set (204), and compares their summaries. If a critical contract or source version has changed, the old plan is not continued; instead, a replanning state is created or reconfirmation is required.

[0082] The audit storage (170) records capability access, evidence selection, memory selection, model call summary, tool call summary, approval snapshot, lease change, completion verification, and candidate state migration in an append-only manner. Sensitive parameters in the audit logs are stored using summaries, anonymization, or encryption, and the query scope is controlled based on the tenant and role. Other implementation methods

[0083] In another embodiment, the knowledge base subsystem (130), the hierarchical memory subsystem (140), and the task execution subsystem (150) may be deployed in the same service, and the operation control subsystem (120) provides capability snapshots (202) in the form of a configuration center and permission service; the above subsystems may also be deployed on different computing nodes, as long as they maintain the constraints through the request context (201), capability snapshots (202), and business result objects (206).

[0084] The processor described in this invention may be a general-purpose processor, a graphics processor, a dedicated accelerator, or a combination thereof; the storage medium may be magnetic storage, solid-state storage, optical storage, or other non-transitory computer-readable media; each step may be implemented by a computer program, a containerized service, a function computing task, or a combination of hardware and software.

[0085] The above embodiments are used to illustrate the technical solution of the present invention. Those skilled in the art can make equivalent adjustments to the module deployment method, field names, thresholds, model providers, database types, message middleware, or tool executors without changing the technical concept of request context consistency verification, controlled execution, and write-back after verification.

Claims

1. A multi-tenant enterprise intelligent agent closed-loop collaborative system, characterized in that, It includes an interactive access subsystem, an operation control subsystem, a knowledge foundation subsystem, a hierarchical memory subsystem, a task execution subsystem, and a result verification and candidate write-back subsystem; the interactive access subsystem is used to receive business requests and generate a request context that binds the current tenant, subject identity, session, and target resource. The request context includes at least the tenant identifier, subject identity version, session revision number, target resource identifier, and target resource revision number. The operation control subsystem is used to parse the request context to obtain the set of allowed capabilities and generate a capability snapshot; The knowledge base subsystem is used to output a set of evidence carrying source citations, corpus revision numbers, and validity status within the permission limits defined by the set of allowed capabilities. The hierarchical memory subsystem is used to output a context set and a memory set carrying the source chain, memory revision number, and lifecycle state; The task execution subsystem is used to establish a task execution record associated with the request context and capability snapshot, and execute tasks based on the evidence set and memory set; before model invocation, tool invocation, and the generation of external side effects, the current system state is reread and compared item by item, and if any state is inconsistent, the corresponding processing is terminated or the processing result is rejected; the result verification and candidate write-back subsystem is used to independently verify the task execution result based on preset business completion conditions; when the verification is passed, knowledge candidates or memory candidates carrying source chain, scope of application, and version information are generated; the data exchanged between the subsystems all carry the request context identifier and the corresponding revision number.

2. The system according to claim 1, characterized in that, The request context also includes the business scope and request sequence number; when the interactive access subsystem receives the asynchronous return result, it compares the tenant identifier, subject identity version, session revision number, target resource identifier, and request sequence number carried in the return result with the current system state snapshot item by item; the page state is updated only when all the comparisons are consistent; if the comparisons are inconsistent, the return result is discarded directly, and the return result of the old request is prohibited from maintaining or creating the loading state corresponding to the new request.

3. The system according to claim 1, characterized in that, The operation control subsystem obtains the allowed capability set by taking the intersection of the code capability registry, industry capability packages, customer capability packages, module permissions, risk constraints, evidence prerequisites, and operating environment status; it then solidifies the capability package version, permission scope, risk level, environment identifier, and content summary to generate an immutable capability snapshot; capability access verification is performed before establishing task execution records, calling models, or calling tools; if any access element is missing, invalid, or inconsistent, subsequent tasks are refused.

4. The system according to claim 1, characterized in that, The knowledge base subsystem uses relational data storage to store documents, segments, and their version status as authoritative states, and vector indexes are only used for candidate recall. The candidate segments retrieved by the vector index are re-verified according to tenant, knowledge base, corpus revision number, document status, segment status, and access range. A retrieval task is bound to a retrieval snapshot composed of corpus range fingerprint and monotonically increasing revision number. If the corpus revision number changes during the retrieval process, the retrieval result is rejected.

5. The system according to claim 1, characterized in that, The hierarchical memory subsystem stores the original dialogue and enterprise memory in the authoritative data storage, and the vector index is only used for candidate retrieval; when constructing the context, the complete question-and-answer round with time closure is retained; when context compression is triggered, continuous original text segments are selected from the sent messages, and the server verifies the message identifier, message role, and continuous substring relationship; before the enterprise memory takes effect, memory candidates with source chain and version information are generated. Only after the memory candidates have passed the verification of scope of application, validity period, access permissions, sensitivity level, and conflict status can they become valid enterprise memories.

6. The system according to claim 1, characterized in that, The task execution record shall at least store the task type, business idempotent key, execution mode, number of attempts, lease expiration time, fence token, deadline, and cancellation status; The task execution subsystem delivers semantic acquisition tasks at least once based on a message queue; before generating external side effects, it re-verifies the lease, fence token, and business idempotent key. When a task resumes execution, only incomplete actions are executed based on encrypted checkpoints and barrier tokens; the task status and checkpoints are updated based on the barrier tokens; and the business completion status, network request success status, and task termination status are recorded separately.

7. The system according to claim 1, characterized in that, The operation control subsystem and task execution subsystem classify risk levels based on operational reversibility, scope of impact, and external side effects. For operations requiring confirmation, an immutable operation snapshot is generated. This snapshot includes at least the operation objective, the current revision number of the objective, the approver, the responsible person, a standardized parameter summary, a capability snapshot identifier, and a summary of the operation snapshot content. After completing the preview and receiving the confirmation instruction, the capability snapshot, personnel status, objective revision number, and standardized parameter summary are re-verified. If all verifications are consistent, the operation is executed using a stable business idempotent key. If the verification fails, execution will be refused.

8. The system according to claim 2, characterized in that, During the streaming response process, the interactive access subsystem saves incremental content as plain text and merges page updates according to a preset time window; after receiving a termination event, it then performs markup language parsing and whitelist cleanup. For file uploads, status polling, or pagination requests, set a tombstone status for deleted or invalidated targets; late polling or pagination results cannot make deleted or invalidated targets reappear and be displayed.

9. The system according to claim 1, characterized in that, The result verification and candidate write-back subsystem constructs a business result object for the task result; the business result object includes result status, completion evidence, independent verification result, and debriefing summary; knowledge candidates or memory candidates are only allowed to be generated based on the debriefing summary when independent verification is passed; candidates are written into authoritative data storage only after being reviewed by source summary, scope of application, sensitivity level, current version, and conflict status. The raw output of the model, the raw output of the tool, and the unverified task termination state cannot be directly used as effective knowledge or effective memory.

10. A closed-loop collaborative method for multi-tenant enterprise intelligent agents, characterized in that, include: Receive business requests and generate a request context that binds the current tenant, principal identity, session, and target resource; Based on the intersection of capability registration information, capability packages, module permissions, risk constraints, and operating environment, capability access verification is performed to generate a capability snapshot. Within the scope of the capability snapshot's limited permissions, an evidence set carrying source citations and corpus revision numbers is obtained from the knowledge base, and a context set and memory set carrying source chains and memory revision numbers are obtained from the hierarchical memory. A task execution record containing business idempotent keys, leases, and barrier tokens is established. The task is executed under controlled conditions based on the evidence set and memory set. The task results are independently verified according to the business completion conditions. After the independent verification is passed, knowledge candidates or memory candidates are generated. The request context and revision number carried in the returned result are compared item by item with the current system state, and the returned result is applied only when the comparison is consistent.

11. An electronic device comprising a processor and a memory, characterized in that, The memory stores a computer program, which, when executed by a processor, implements the method of claim 10.

12. 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 claim 10.

Images