Multi-agent operation management and control method and electronic device

Abstract

The application provides a multi-agent running management and control method and an electronic device. The method comprises the following steps: receiving a user request, and determining a current task identifier, a target agent and a running resource bound to the target agent according to the user request; constructing a target running domain at a logic level; before calling the target agent, constructing a shadow running domain at a physical level, verifying whether the loaded resource entity in the running environment is consistent with the resource data defined by the target running domain; generating a resource binding proof, verifying whether the helper identifier transmitted by the business side has the binding relationship declared in the agent registry between the actually loaded agent and the resource thereof; if the verification passes, the target agent is called to execute model reasoning. The problem that the execution environment is difficult to uniformly represent and verify in multi-user, multi-session, multi-thread and multi-agent concurrent service is solved, and the stability and response effect of multi-agent running are improved.

Description

Technical Field

[0001] This application relates to the field of concurrent service technology for multi-agent systems, specifically to a multi-agent operation management method and electronic device. Background Technology

[0002] With the rapid development of Large Language Model (LLM) technology, Multi-Agent Systems have been widely applied in fields such as complex task processing, intelligent customer service, scientific research assistance, and code generation. In practical applications, the system typically needs to serve multiple users and multiple business sessions simultaneously, and coordinate multiple agents with different professional fields (such as medical, legal, and financial) to work collaboratively.

[0003] However, existing multi-agent systems have at least the following significant technical shortcomings when dealing with multi-user, multi-session, and multi-agent concurrent scenarios:

[0004] First, incomplete representation of the execution environment leads to the risk of resource mismatch. Existing technologies typically rely solely on user IDs or session IDs to manage requests. However, this approach cannot differentiate between the model configurations, personality prompts, code repository permissions, and toolsets required when the same user switches between different agents within the same session (e.g., switching from "general question answering" to "code generation"), thus easily leading to resource mismatch risks. Resource mismatch risks can trigger adverse chain reactions, such as domain adaptation failure causing output distortion. For example, in a medical consultation scenario, if the system incorrectly maps a "medical agent" to a "general large language model" configuration, it may lead to misdiagnosis suggestions or outputs that contradict medical common sense. Excessive privileges can lead to data leaks. For instance, if the code generation agent fails to isolate private code repository permissions for different projects when switching project contexts, it may lead to cross-project source code leaks or exposure of sensitive configurations. Misuse of tools can cause system crashes. For example, if a data analysis agent misuses an unverified external tool interface, it may lead to malicious script execution, accidental database deletion, or server resource exhaustion. (For example, in scenarios such as medical Q&A, code generation, or data analysis, resource mismatch may lead to output deviating from domain constraints, incorrect access to cross-project resources, misuse of external tools, or abnormal occupation of system resources.) Therefore, relying solely on user identifiers or session identifiers cannot fundamentally prevent the security risks caused by configuration mismatches mentioned above.

[0005] Second, there is the risk of memory contamination spreading. Multi-agent systems rely on long-term memory and summary memory for coherent dialogue. Once an erroneous output occurs in a round of dialogue due to tool overreach, contextual interference, or model illusion, and this error is written into long-term memory, it will continue to propagate in subsequent rounds of dialogue and even across agent collaborations. Existing systems lack effective mechanisms to trace the source of contamination and block its propagation path.

[0006] Third, there is a lack of consistency in streaming responses. To improve the interactive experience, agents commonly use streaming output protocols such as SSE (Server-Sent Events) and WebSocket. However, in high-concurrency scenarios, due to network jitter, interrupted resume, or system anomalies, old messages from previous rounds, response fragments from other agents, or repetitive and out-of-order fragments may be incorrectly concatenated into the current response. Existing deduplication methods (such as text hashing) cannot prove that a fragment belongs to the current running instance.

[0007] Fourth, there is a lack of pre-verification and traceability. Existing security mechanisms are mostly reactive. For example, sensitive word filtering is performed only after the model has generated an answer, or API calls are only recorded in the logs. There is a lack of pre-verification of resource binding relationships (whether the business assistant corresponds to the correct underlying model), and it is difficult to trace the specific memory node and context source after an anomaly occurs.

[0008] In view of the above, this application is hereby submitted. Summary of the Invention

[0009] This application aims to provide a method and electronic device for managing the operation of multiple agents, which solves the problem of difficulty in uniformly representing and verifying the execution environment in concurrent services involving multiple users, multiple sessions, multiple threads, and multiple agents, thereby improving the stability and response effect of multi-agent operation.

[0010] In a first aspect, embodiments of this application provide a multi-agent operation management method, including:

[0011] Receive user requests and determine the current task identifier, target intelligent agent, and the running resources bound to the target intelligent agent based on the user requests;

[0012] Based on the current task identifier, the target agent, and the running resources, a target running domain is constructed at the logical level, and resource data that the target agent is allowed to access is defined within the target running domain;

[0013] Before invoking the target intelligent agent, a physical-level shadow execution domain is constructed according to the definition of the target execution domain. The shadow execution domain is used to instantiate and load the specific resource entities defined by the target execution domain.

[0014] The system-side pre-run verification is performed on the resource entities within the shadow runtime domain. The system-side pre-run verification is used to verify whether the resource entities loaded in the runtime environment are consistent with the resource data defined by the target runtime domain.

[0015] Generate a resource binding certificate and perform business-side verification based on the resource binding certificate. The business-side verification is used to verify whether there is a binding relationship declared in the smart agent registry between the assistant identifier passed in by the business side and the underlying actually loaded smart agent and its resources.

[0016] If both the system-side pre-test and the business-side test pass, the target agent is invoked to perform model inference.

[0017] Secondly, embodiments of this application also provide an electronic device, the electronic device comprising:

[0018] Processor and memory;

[0019] The processor executes the steps of the multi-agent operation management method as described in any embodiment by calling the programs or instructions stored in the memory.

[0020] In summary, this application proposes a multi-agent operation management method that solves the problem of difficulty in uniformly representing and verifying the execution environment in concurrent services involving multiple users, multiple sessions, multiple threads, and multiple agents, thereby improving the stability and response performance of multi-agent operation. Specifically, it receives user requests and determines the current task identifier, target agent, and runtime resources bound to the target agent based on the user request. A logical-level target runtime domain is constructed based on the current task identifier, target agent, and runtime resources. Within the target runtime domain, resource data accessible to the target agent is restricted. Before invoking the target agent, a physical-level shadow runtime domain is constructed according to the definition of the target runtime domain. The shadow runtime domain is used to instantiate and load the specific resource entities restricted by the target runtime domain. System-side pre-verification is performed on the resource entities within the shadow runtime domain. This system-side pre-verification verifies whether the resource entities loaded in the runtime environment are consistent with the resource data restricted by the target runtime domain. Through the shadow runtime domain pre-verification mechanism, the system can detect issues such as agent resource mismatch, cross-domain context, skill overreach, and memory pollution before formal inference, reducing the risk of abnormal content entering model output or long-term memory. Generate a resource binding certificate and perform business-side verification based on the resource binding certificate. The business-side verification is used to verify whether there is a binding relationship declared in the agent registry between the assistant identifier passed by the business side and the underlying actual loaded agent and its resources. If both the system-side pre-verification and the business-side verification pass, the target agent is called to perform model inference. Attached Figure Description

[0021] Figure 1 This is the main flowchart of a multi-agent operation management and control method provided in an embodiment of this application;

[0022] Figure 2 This is a flowchart of a context fragment filtering process provided in an embodiment of this application;

[0023] Figure 3 This is a schematic diagram of the structure of a memory pollution propagation map provided in an embodiment of this application;

[0024] Figure 4 This is a flowchart of a response fragment causal watermark verification method provided in an embodiment of this application;

[0025] Figure 5 This is a schematic diagram of a causal watermark chain for a response fragment provided in an embodiment of this application;

[0026] Figure 6 This is a flowchart of a multi-mechanism collaborative closed-loop process provided in an embodiment of this application;

[0027] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0029] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0030] Example 1

[0031] Figure 1 This is the main flowchart of a multi-agent operation management method provided in an embodiment of this application. See also... Figure 1 The multi-agent operation and management method specifically includes the following steps:

[0032] S110. Receive user request and determine the current task identifier, target intelligent agent, and running resources bound to the target intelligent agent based on the user request.

[0033] The current task identifier includes one or more of the following: current input, user identifier, business session identifier, workflow thread identifier, running mode, business parameters, attachment information, and call source information.

[0034] Workflow thread identifiers are identifiers for concurrent execution units within a business workflow. A business session may contain multiple parallel or serial sub-task threads (e.g., a main thread for report generation + a sub-thread for data cleaning), used to distinguish collaborative links or task branches between different agents within the same session.

[0035] The operating mode describes the execution form and lifecycle strategy of the current intelligent agent call, such as general dialogue mode (typical business scenarios include general question answering and small talk), domain task mode (typical business scenarios include medical consultation), and independent intelligent agent mode (typical business scenarios include independently deployed dedicated agents).

[0036] Business parameters are the structured control data required for this agent call. They do not include the original input text, but they affect agent behavior, tool selection, and permission pruning. Typical business parameters include: language, output format, maximum length, whether to enable citations, report type, timeout, retry policy, and parallelism.

[0037] Attachment information refers to files uploaded or referenced by users or business systems upon request, serving as auxiliary context for intelligent agent reasoning.

[0038] The call source information describes who initiated the current request and through which channel it entered the system, and is used for auditing, isolation strategies, and risk control. For example, the call source information could be: user frontend, business system backend, workflow scheduler, third-party integration interface, or internal proxy collaboration.

[0039] Specifically, the access request and identity resolution module receives requests from the front-end, business systems, third-party interfaces, or workflow schedulers, and obtains the current input (i.e., the content of the user's request, such as "What's the weather like today?"), user identifier, business session identifier, workflow thread identifier, running mode, business parameters, attachment information, and call source information. The current input can be submitted directly by the user; the user identifier, business session identifier, workflow thread identifier, running mode, business parameters, attachment information, and call source information can be explicitly passed in by the front-end, or automatically generated or completed by the login status, token, server-side session table, gateway request headers, or workflow scheduler.

[0040] The target agent parsing module is used to determine the target agent based on the assistant_id, field_assistant_id, standalone_assistant_id, agent_name, or operating mode in the request. Among them, assistant_id is a higher-level concept for business-side assistant identification, while field_assistant_id and standalone_assistant_id are specific forms of assistant_id in different business scenarios. If the request includes an assistant_id, the system queries the corresponding agent_name (i.e., the target agent) based on the agent mapping table, registry, or configuration center. If the request directly includes the agent_name, the system verifies its validity and then determines the target agent. If the request does not include a valid assistant identifier, the system can determine the target agent using any of the following methods: a default routing strategy, selecting a preset default assistant identifier as the target agent entry point based on the tenant, business domain, operating environment, or system pre-configuration rules; or an agent scoring routing mechanism, calculating a comprehensive score for each candidate agent based on user input semantic features, candidate agent capability descriptions, user permission policies, agent operating load, and historical call success rates, and selecting the agent with the highest score as the target agent.

[0041] The runtime resources bound to the target intelligent agent include one or more of the following: model configuration, personality hints, skill catalog, toolset, permission policy, and memory version information.

[0042] Optionally, the target agent and its registry can be used to obtain its bound model configuration, personality hints, skill catalog, toolset, permission policy, and memory version information.

[0043] Model configuration refers to the settings of the large model type, inference parameters, and operating environment that the target intelligent agent relies on during the inference process.

[0044] Personality cues are used to define the role, behavioral boundaries, expression style, and constraint rules of an agent. They are "system prompts" for model reasoning. For example, for a medical assistant, the personality cues would be "You are an endocrinologist at a top-tier hospital. Your answers must be based on the latest clinical guidelines and no diagnostic conclusions will be provided."

[0045] A skills catalog is a structured collection of capabilities that an agent can invoke. A toolset is an atomic capability interface that an agent can execute at runtime.

[0046] The permission policy defines the resources, tools, memories, and operations that an agent is allowed to access within a given runtime domain. Memory versions are used to identify snapshots of the memory space that the current runtime domain depends on.

[0047] S120. Construct a target operating domain at the logical level based on the current task identifier, the target intelligent agent, and the operating resources. Within the target operating domain, there are resource data that the target intelligent agent is allowed to access.

[0048] For example, a runtime domain fingerprint is generated based on the current task identifier, the target intelligent agent, and the representation information of the runtime resources. The runtime domain fingerprint is used to identify the execution environment that responds to user requests and serves as a unified verification basis for memory access, resource binding, context injection, tool invocation, streaming response verification, exception rollback, and result writeback. The target runtime domain is constructed based on the runtime domain fingerprint.

[0049] The current task identifier includes one or more of the following: current input, user identifier, business session identifier, workflow thread identifier, running mode, business parameters, attachment information, and call source information.

[0050] Runtime resources include one or more of the following: model configuration, personality hints, skill catalog, toolset, permission policy, and version information.

[0051] In other words, within the target operating domain, the memory space, model configuration, personality hints, skill catalog, toolset, permission policy, context fragment set, response fragment set, and result write-back path that the current request can access are limited.

[0052] After identifying the target agent, the system generates a runtime fingerprint corresponding to the current request. The runtime fingerprint is used to characterize the complete trusted execution environment of the current request.

[0053] Alternatively, the runtime domain fingerprint can be represented as:

[0054]

[0055] in, Indicates the domain fingerprint; U represents the user identifier; S represents the business session identifier; T represents the workflow thread identifier; A represents the target agent identifier; M represents the operating mode; V represents the running domain fingerprint; U represents the user identifier; S represents the business session identifier; T represents the workflow thread identifier; A represents the target agent identifier; M represents the running ... c Represents a summary of the model configuration or configuration file; V p Indicates a personality cues or a summary of a personality document; V s This represents a summary of the skills catalog; V represents a summary of the permission policy; m Indicates the version number; Q h H1 represents the current input digest; H1 represents the hash function, digest function, or equivalent mapping function.

[0056] In one optional implementation, the runtime domain fingerprint can also incorporate tenant_id, organization_id (within the tenant, a further subdivided organizational unit, such as a subsidiary, department, or team), security_level (indicating the security sensitivity level of the current request or agent), business_domain (identifying the business domain or industry scenario to which the current request belongs), model_version, policy_version (the version of the permission policy, security policy, or compliance policy used by the current runtime domain), or deployment_region to support enterprise-level multi-tenant deployment, permission level isolation, model version isolation, or cross-region deployment.

[0057] In another alternative implementation, agent resources can be uniformly declared through an agent_manifest description file. The agent_manifest may include agent_name, model configuration path, personality file path, skill directory path, tool permission policy, memory space policy, risk level, and write-back policy.

[0058] Among them, the model configuration summary can be generated based on the configuration file config.yaml bound to the target agent, database configuration records, configuration center version number, or model parameter set; the personality file summary can be generated based on the personality file SOUL.md, system prompt word template, or role configuration; the skill catalog summary can be generated based on the skill catalog structure, skill list, or plugin package version; the permission policy summary can be generated based on the tool whitelist, tool blacklist, permission level, data access policy, or policy engine output; and the memory version number can be generated based on the version field, update timestamp, or event sequence number of the current running domain memory space.

[0059] Runtime domain fingerprints are used not only to locate memory space or result write-back paths, but also to verify whether the configuration, personality, skills, permissions, and memory version actually loaded in the current request are consistent with the resources declared by the target agent. Thus, the system can integrate users, sessions, threads, agents, and resource states into the same trusted execution environment.

[0060] Target runtime domain construction mechanism. The system constructs the target runtime domain corresponding to the current request based on the runtime domain fingerprint. The target runtime domain can be represented as:

[0061]

[0062] in, Indicates runtime domain fingerprint The corresponding target operating domain; A represents the target intelligent agent; This represents the model configuration and runtime parameters of the target intelligent agent; This indicates the personality cues or role settings of the target intelligent agent; This represents the isolated memory space located by the runtime domain fingerprint; This represents the set of authorized skills for the target intelligent agent; This represents the set of authorized tools for the target intelligent agent; Indicates the permission policy; This represents the set of context fragments that are allowed to enter the model input; This represents the set of response fragments that passed the verification. This refers to logs and audit records.

[0063] in, , , , and It can be determined by the agent's registry, configuration center, or database resource table; It can be obtained by mapping the runtime domain fingerprint to a file path, a database composite index, a cache namespace, or a vector database; This can be determined by mapping the runtime domain fingerprint to the corresponding audit log.

[0064] During the current request processing, the system only allows reading and writing to the target runtime domain. The memory, configuration, personality, tools, skills, context fragments, and response fragments bound within. If a request attempts to access something that does not belong to the target runtime domain. For resources that are restricted, the system can deny access, trigger security downgrades, or log abnormal audits.

[0065] By using domain fingerprinting, the current request is uniformly represented by user identifier, business session identifier, workflow thread identifier, target agent identifier, operating mode, model configuration, personality prompts, skill resources, permission policies, memory version, and current input content. Compared with methods that only distinguish the context scope by user identifier, session identifier, or thread identifier, this implementation can not only determine "which user or session the current request belongs to," but also further determine "under what agent, configuration, personality, skill, permission, and memory version the current request is executed."

[0066] In one alternative implementation, the isolated memory space can be implemented using local files, relational databases, key-value databases, vector databases, object storage, caching systems, or distributed file systems. The system can implement runtime domain-level memory access control through file paths, database composite indexes, cache namespaces, vector database sets, or metadata filtering conditions.

[0067] Furthermore, an isolation memory management and version control mechanism is proposed, with the system based on runtime domain fingerprints. Establish isolated memory space The current request only allows reading and writing of the runtime domain fingerprint. Matches or is authorized by permission policies for the content being stored.

[0068] Optionally, memory nodes can be abstractly represented based on memory content, runtime domain fingerprint, memory source type, message role, write version, timestamp, permission tag, and pollution status. The memory source type identifies the origin of the memory, including: direct user input, agent-generated, or returned by external tools. The message role defines the memory's functional positioning in the current session or workflow, including: user requests or instructions, system responses or commitments, system-level constraints or background, observation results, etc. The permission tag specifies the memory's visibility and read / write permissions to prevent sensitive information leakage or erroneous agent reading, including: public (open to all agents and users), private (open only to specific users), and read-only (read-only, no modification allowed). The pollution status indicates whether the memory belongs to a polluted message. For example, if the memory's generation references historical messages that are marked as polluted, then this memory also belongs to a polluted message.

[0069] Optionally, memory access constraints It can be represented as:

[0070]

[0071] Among them, owner( ) represents memory The domain to which it belongs, Permit( , This indicates that the permission policy allows the current runtime domain to read this memory. If... If the value is 0, the system prevents that memory from entering the current context. For runtime domain fingerprints.

[0072] To prevent concurrent writes from overwriting memory, the system can set a version number for each runtime domain memory space. Before writing, the system checks whether the current version number is consistent with the version read; if the versions are consistent, the write is committed and the version number is updated; if the versions are inconsistent, a retry, merge, lock, or event append strategy is triggered.

[0073] Optionally, a tool and skill permission control mechanism is proposed. The system determines the set of tools and skills available in the current operating domain based on the target intelligent agent, current user permissions, business scenario, data security level, and tool risk level. Optionally, the skill or tool permission judgment can be expressed as:

[0074]

[0075] Where A represents the target intelligent agent; R represents the tool or skill resource. Indicates the running domain fingerprint, This indicates the result of the permission judgment. This indicates that the target intelligent agent A has a fingerprint in the operating domain. Within the associated operational domain, tools or skill resources R can be used. Scope(A) represents the scope of resources authorized to the target agent; level( This indicates the target intelligent agent's fingerprint in the runtime domain. The permission level within the associated runtime domain; level(R) represents the permission level required by the tool or skill; Policy( ) represents the result of the strategy engine's judgment; I represents the indicator function.

[0076] The risk level of a tool can be determined based on factors such as whether it accesses external networks, writes to databases, executes code, sends messages, deletes files, accesses sensitive data, or performs irreversible operations. For high-risk tools, the system may require a higher level of isolation, shadow domain rehearsal, explicit authorization, read-only mode, or manual auditing.

[0077] Through this mechanism, medical question-answering agents, technical document writing agents, scientific research assistance agents, and general question-answering agents can each load tools and skills within their authorized scope, avoiding output misalignment, data leakage, erroneous execution, permission overreach, and auditing difficulties caused by mixing tools.

[0078] S130. Before calling the target intelligent agent, construct a physical-level shadow execution domain according to the definition of the target execution domain. The shadow execution domain is used to instantiate and load the specific resource entities defined by the target execution domain.

[0079] S140. Perform system-side pre-run verification on resource entities within the shadow runtime domain. The system-side pre-run verification is used to verify whether the resource entities loaded in the runtime environment are consistent with the resource data defined by the target runtime domain.

[0080] Resource entities include at least model configuration files, personality hint files, skill catalogs, and tool files.

[0081] Perform system-side pre-verification of resource entities within the shadow runtime domain, including:

[0082] Verify whether the model configuration files, personality hint files, skill catalogs, and tool files actually loaded in the shadow runtime domain can be initialized normally, and whether they belong to the resource data limited by the target runtime domain.

[0083] The shadow runtime domain is used to perform the following pre-run verifications:

[0084] First, verify whether assistant_id, agent_name, and the target agent's registration information are consistent.

[0085] Specifically, the `assistant_id` is determined based on the user request. Then, the agent registry is queried to obtain the corresponding target agent. This target agent is then compared with the target agent in the shadow runtime domain to confirm their similarity. This process can prevent issues such as incorrect `assistant_id` and incorrect target agent loading.

[0086] Second, verify that the model configuration, personality prompts, skill catalog, and permission policies exist and are consistent with the binding relationship of the target agent. This can prevent issues such as modified configuration files, replaced personality files, and mismatched skill target versions.

[0087] Third, verify whether the memories to be read are all within the memory range allowed by the runtime domain fingerprint.

[0088] Specifically, it confirms whether the memory node to be read in the shadow runtime domain falls within the memory read range defined by the target runtime domain. This can prevent memory crosstalk issues.

[0089] Fourth, verify whether the skills and tools to be loaded meet the current user permissions, agent permissions, and business scenario requirements.

[0090] Fifth, verify whether the fragment to be injected into the context has cross-domain, expired, low-trust, or polluted markers.

[0091] Sixth, verify whether the write-back path, audit path, and memory version number are available.

[0092] When the shadow runtime domain pre-simulation passes, the system executes according to the target runtime domain; when the shadow runtime domain pre-simulation fails, the system can abort the request, roll back the default agent, enable read-only memory, disable high-risk tools, reselect the target agent, or enter the manual audit process.

[0093] Through the shadow domain pre-simulation mechanism, the system can detect problems such as agent resource mismatch, context cross-domain, skill overreach and memory pollution before formal inference, reducing the risk of abnormal content entering the model output or long-term memory.

[0094] S150. Generate a resource binding certificate and perform business-side verification based on the resource binding certificate. The business-side verification is used to verify whether there is a binding relationship declared in the smart agent registry between the assistant identifier passed in by the business side and the underlying actually loaded smart agent and its resources.

[0095] For example, the actual model configuration summary, personality prompt summary, skill catalog summary, and permission policy summary loaded in the shadow runtime domain are calculated and compared with the corresponding declaration summary recorded in the agent registry. If there are inconsistent summaries, the business-side verification is deemed to have failed.

[0096] The system generates a resource binding certificate for the target agent and its actual loaded resources. Optionally, the resource binding certificate is obtained by calculating the hash value or digest of the resource, which includes the business-side assistant identifier, the underlying agent name, model configuration, personality hints, skill set, tool set, permission policy, and memory version number.

[0097] The generated resource binding certificate is checked for consistency with the runtime domain fingerprint and the declared resources in the agent registry. If the check passes, it indicates that there is a consistent binding relationship between the business-side assistant identifier, the underlying target agent, and the actual loaded resources. If the check fails, it indicates that there may be mapping errors, configuration mismatches, personality file errors, inconsistent skill directories, invalid tool permissions, or memory version conflicts. The system may trigger abnormal freezing, security downgrade, or reconfiguration.

[0098] The resource binding verification mechanism differs from simple file existence checks. Its verification objects include not only whether the resource exists, but also whether the resource belongs to the current target agent, whether the resource digest is consistent with the registration statement, whether the permission policy meets the current request, and whether the memory version is consistent with the running domain.

[0099] S160. If both the pre-test on the system side and the test on the business side pass, then the target agent is invoked to perform model inference.

[0100] Specifically, during the process of calling the target agent to perform model inference, the system reads the memory content that is allowed to be accessed according to the resources limited by the target operating domain, constructs the model invocation context based on the current input, personality prompts, tool set, business parameters, etc., calls tools and skills according to the permission policy, and performs task inference according to the target agent or multi-agent workflow.

[0101] During or after the target agent is invoked to perform model inference, the model context fragments, response fragments, and memory update content are verified based on the target operating domain, and the verified content and corresponding audit information are written into the target operating domain.

[0102] The multi-agent operation management method provided in this application uses a unified representation of the current requesting user, session, thread, target agent, model configuration, personality prompts, skill resources, permission policies, memory version, and current input content through operation domain fingerprints, enabling the execution environment of multi-agent requests to have identifiable, verifiable, and traceable capabilities.

[0103] By using shadow runtime domain pre-simulation and resource binding verification mechanisms, the consistency of the target agent and its runtime resources is verified before the model is officially invoked. When the configuration, persona, skills, tool permissions or memory version actually loaded by the system are inconsistent with the resources declared by the target agent, the anomaly can be detected by runtime domain fingerprinting, thereby reducing the risk of agent resource mismatch, unclear context boundaries and incorrect resources participating in inference.

[0104] The shadow runtime domain pre-running mechanism enables the system to detect potential anomalies before formal inference, rather than processing them after the model has generated an answer or the anomaly has been written into memory. For requests that fail the pre-running verification, the system can take measures such as suspending execution, reverting to the default agent, enabling read-only memory, disabling high-risk tools, or triggering manual auditing, thereby reducing the probability of erroneous output, unauthorized calls, and abnormal memory writes.

[0105] The resource binding verification mechanism associates and verifies the business assistant identifier, underlying agent name, model configuration summary, personality file summary, skill catalog summary, tool permission summary, and remembered version information. This mechanism goes beyond simply checking the existence of resource files; it further verifies whether the actually loaded resource belongs to the target agent, whether the resource summary matches the registration statement, whether the permission policy satisfies the current request, and whether the remembered version matches the current runtime domain.

[0106] Therefore, this embodiment can avoid inconsistencies between the assistant identifier passed in by the business system and the actual target agent name loaded at the underlying level, prevent domain agents from mistakenly loading general agent configurations, prevent general agents from mistakenly calling domain-specific skills, prevent mismatched personality files leading to output role offsets, and prevent permission policies from failing, resulting in tool overreach. This advantage is reflected in verifiable control over agent resource binding relationships, rather than simply isolating different resource directories.

[0107] Example 2

[0108] Based on the above embodiments, this embodiment adds a "target context fragment screening" step before step S160 to address the problem of cross-domain memory, expired memory, low-reliability tool results, or suspected contaminated fragments being injected into the model input during context construction. Specifically, refer to... Figure 2 As shown, it includes the following steps:

[0109] S210. Receive user request and determine the current task identifier, target intelligent agent, and running resources bound to the target intelligent agent based on the user request.

[0110] S220. Construct a target operating domain at the logical level based on the current task identifier, the target intelligent agent, and the operating resources. Within the target operating domain, there are resource data that the target intelligent agent is allowed to access.

[0111] S230. Before invoking the target intelligent agent, construct a shadow execution domain at the physical level according to the definition of the target execution domain. The shadow execution domain is used to instantiate and load the specific resource entities defined by the target execution domain.

[0112] S240. Perform system-side pre-run verification on resource entities within the shadow runtime domain. The system-side pre-run verification is used to verify whether the resource entities loaded in the runtime environment are consistent with the resource data defined by the target runtime domain.

[0113] S250. Generate a resource binding certificate and perform business-side verification based on the resource binding certificate. The business-side verification is used to verify whether there is a binding relationship between the assistant identifier passed in by the business side and the underlying actually loaded smart agent and its resources as declared in the smart agent registry.

[0114] S260. If both the pre-run verification on the system side and the verification on the business side pass, perform structured labeling and quantitative scoring on each candidate context segment entering the model context; determine the candidate context segment whose quantitative score reaches the preset threshold as the target context segment.

[0115] The quantitative score is determined from at least the following four dimensions: the relevance of the candidate context fragment to the user request, whether the candidate context fragment belongs to the allowed access fragments defined by the target operating domain, the credibility value of the candidate context fragment, and the risk value.

[0116] Specifically, based on the source type, generation method, verification mechanism, and operating domain fingerprint of the candidate context fragment, a preset credibility mapping table is queried to obtain the corresponding credibility value; based on the sensitivity level, pollution mark, permission status, expiration status, and abnormal characteristics of the candidate context fragment, a weighted sum is performed according to preset risk weights to obtain the risk value of the candidate context fragment.

[0117] For example, context fragments It can be represented as:

[0118]

[0119] in, Indicates fragment content; Indicates the source type, including current user input, historical memory, summary content, tool results, personality tips, or business parameters; Indicates the runtime domain fingerprint to which the fragment belongs; Indicates the source character of the clip; Indicates the sensitivity level; Indicates credibility; Indicates pollution label; Indicates an expired status; Indicates access permissions.

[0120] The system calculates a context fragment score based on a comprehensive consideration of relevance, credibility, permissions, and risk. Optionally, the context fragment score... It can be represented as:

[0121]

[0122] in, This indicates the relevance of the segment to the current input; Indicates the credibility of a segment; Indicates whether the current runtime domain allows the use of this fragment; This indicates the risk value of the segment.

[0123] When the context fragment score If the preset threshold is reached, and the operating domain, permission status, and pollution status of the fragment meet the requirements, the system allows the fragment to enter the current model input; otherwise, the system filters, downgrades, compresses the summary, or writes it to the audit log.

[0124] By structurally tagging fragments such as user input, historical memories, summary content, tool results, business parameters, and personality prompts entering the model context, and recording the fragment's source, operating domain, permission tag, sensitivity level, credibility, expiration status, and contamination status, the system determines whether to allow a fragment to enter the context based on its relevance to the current input, its operating domain, permission fulfillment, credibility, and contamination risk when constructing the model input. This mechanism reduces the probability of irrelevant memories, cross-domain memories, expired memories, low-credibility tool results, or suspected contamination fragments entering the current model input. Compared to methods that only concatenate historical contexts chronologically or retrieve memories solely based on relevance, this implementation simultaneously considers "relevance," "authorization," "credibility," "contamination," and "belonging to the current operating domain" during the context construction phase, thereby improving the security and consistency of the model input content.

[0125] Furthermore, a memory contamination propagation graph construction mechanism is proposed. The system abstracts user input, agent output, tool call results, summary memory, and long-term memory as memory propagation nodes, and constructs a memory contamination propagation graph based on citation relationships, summary relationships, tool call relationships, and write relationships. Optionally, the memory contamination propagation graph... It can be represented as:

[0126]

[0127] in, Represents the set of propagation nodes. This represents the set of propagation edges. Propagation nodes can include user input nodes, agent output nodes, tool result nodes, summary nodes, and long-term memory nodes; propagation edges can represent relationships such as "an output is generated from an input", "a response is supported by a tool result", "a summary is generated from several historical memories", and "a response is written into long-term memory".

[0128] When the system detects an anomaly in a node, such as resource binding failure, tool privilege escalation, broken response fragment watermark chain, cross-domain context fragment conflict, or memory version conflict, the system marks that node as an anomaly and calculates the set of affected nodes along the propagation graph. Optionally, the set of affected nodes... It can be represented as:

[0129]

[0130] in, Represents an abnormal node, Reachable( () indicates the memory of the pollution transmission map The middle is due to abnormal nodes The set of reachable subsequent nodes.

[0131] Affected nodes can include summary memories that directly reference the anomalous node, long-term memories generated by the anomalous node, context fragments that used the anomalous node in subsequent calls, and output results inherited from the anomalous node in cross-agent collaboration. The system can perform freeze, demotion, isolation, rollback, or re-summarization processing on affected nodes. Through this mechanism, the system can not only detect single anomalies but also trace the propagation path of anomalous content in multi-turn dialogues and cross-agent collaborations. This addresses the problem of difficulty in locating the propagation scope and rolling back after anomalous responses, unauthorized tool results, or erroneous summaries are written to long-term memory.

[0132] In one alternative implementation, the memory contamination propagation graph can be implemented using a graph database, relational database tables, event logs, a link tracing system, or a memory graph structure.

[0133] refer to Figure 3The diagram illustrates the structure of a memory contamination propagation graph. User input, agent output, tool call results, summary memory, and long-term memory are abstracted as memory propagation nodes. Different nodes are connected by directed edges, representing generation, referencing, summarizing, tool call, and writing relationships. For example, current user input can generate agent output; agent output can reference several historical memories and tool call results; multiple historical memories can be compressed into a summary memory; agent output or summary content can be further written into long-term memory; a certain long-term memory may be reread in a subsequent request and enter a new context. Each propagation node records its domain fingerprint, source agent, source type, write version, timestamp, permission tag, trustworthiness, and contamination status. When the system detects an anomaly in a node, such as the node originating from an incorrect agent, using an unauthorized tool, having an inconsistent domain with the current request, a broken watermark chain in the response fragment, or a failed resource binding proof, the system marks the node as an abnormal node or a contaminated node. Subsequently, the system traces the set of subsequent nodes affected by the anomalous node along the memory contamination propagation graph, including summary memories referencing the anomalous node, long-term memories written by the anomalous node, fragments in subsequent contexts that used the anomalous node, and output results inheriting the anomalous content in cross-agent collaboration. For affected nodes, the system can perform freeze, demotion, isolation, rollback, or re-summarization processing based on the degree of contamination and business risk. Figure 3 As shown, this structure can not only identify anomalous content in a single request, but also track the propagation path of anomalous content in multi-turn dialogues, summary updates, long-term memory, and cross-agent collaboration, thereby suppressing the continued spread of memory contamination.

[0134] S270. Use the target context fragment as the input element of the target agent and call the target agent to perform model inference.

[0135] By constructing a memory contamination propagation graph, user input, agent output, tool call results, summary memory, and long-term memory are abstracted as propagation nodes, and propagation edges are established based on reference relationships, summary relationships, tool call relationships, and write relationships. Each node records its domain fingerprint, source agent, source type, write version, timestamp, and contamination status. When the system detects resource mismatch, tool overreach, response misalignment, context contamination, or memory version conflict, it can locate the set of affected memory nodes along the memory contamination propagation graph and perform freezing, demotion, isolation, rollback, or re-summarization processing on the relevant nodes. This not only handles abnormal output in a single request but also further suppresses the continuous spread of abnormal content in subsequent multi-turn dialogues, summary memory updates, long-term memory retrieval, and cross-agent collaboration.

[0136] Example 3

[0137] Based on the above embodiments, this embodiment adds a step of "generating a causal watermark for each response fragment generated by the target agent" after step S160, to solve the problem of historical round content, fragments from other agents, fragments not currently requested, duplicate fragments, or out-of-order fragments incorrectly entering the current output in the streaming response. Specifically, refer to... Figure 4 As shown, it includes the following steps:

[0138] S410: Receive user request and determine the current task identifier, target agent, and running resources bound to the target agent based on the user request.

[0139] S420. Construct a target runtime domain at the logical level based on the current task identifier, the target agent, and the runtime resources. Within the target runtime domain, there are resource data that the target agent is allowed to access.

[0140] S430. Before invoking the target intelligent agent, construct a physical-level shadow execution domain according to the definition of the target execution domain. The shadow execution domain is used to instantiate and load the specific resource entities defined by the target execution domain.

[0141] S440. Perform system-side pre-run verification on resource entities within the shadow runtime domain. The system-side pre-run verification is used to verify whether the resource entities loaded in the runtime environment are consistent with the resource data defined by the target runtime domain.

[0142] S450. Generate a resource binding certificate and perform business-side verification based on the resource binding certificate. The business-side verification is used to verify whether there is a binding relationship between the assistant identifier passed in by the business side and the underlying actually loaded smart agent and its resources as declared in the smart agent registry.

[0143] S460. If both the system-side pre-test and the business-side test pass, the target agent is invoked to execute model inference.

[0144] S470. Generate a causal watermark for each response fragment generated by the target intelligent agent, verify each response fragment based on the causal watermark, and provide the verified response fragments to the user and collect them into the response set.

[0145] The causal watermark of the i-th response fragment is represented as follows:

[0146]

[0147] in, This represents the causal watermark of the i-th response fragment. Indicates the running domain fingerprint, Indicates the identifier of the currently running instance. Indicates the current round number. This represents the segment number of the i-th response segment. This represents the i-th response fragment. This represents the causal watermark of the (i-1)th response fragment. Indicates the current input; This represents a mapping function (e.g., a function that specifically calculates a hash value or digest).

[0148] Each response fragment is validated based on causal watermarking, including one or more of the following:

[0149] Verify whether the runtime domain fingerprint carried in the response fragment is consistent with the current runtime domain fingerprint;

[0150] Verify whether the current round number corresponding to the response fragment is consistent with the current round;

[0151] Verify whether the sequence number of the response segment is consecutive and not repeated with the sequence number of the preceding response segment;

[0152] Verify that the current input digest matches the digest requested by the user in this round;

[0153] Verify whether the current segment watermark and the previous segment watermark form a continuous chain;

[0154] Verify whether the fragment character belongs to the allowed intelligent agent response characters.

[0155] Only response fragments that pass the above verification are allowed to be output to the client and enter the final response set. If a fragment comes from a historical round, another agent, another operating domain, or has duplicates, out-of-order sequences, rollbacks, or abnormal first-frame aggregation, its operating domain fingerprint, round number, fragment sequence number, or watermark chain will fail the verification. The system will filter the fragment and record the reason for the filtering.

[0156] For example, refer to Figure 5 The diagram illustrates a causal watermarking chain for response fragments. During SSE (Server-Sent Event), WebSocket, HTTP chunked transmission, gRPC streaming, or message queue streaming consumption, the system splits the current response into multiple response fragments. For the i-th response fragment, the system generates a causal watermark containing the runtime domain fingerprint, runtime instance identifier, round number, fragment sequence number, current input digest, current fragment digest, and previous fragment digest. The watermark of the previous fragment participates in the generation of the watermark of the next fragment, forming a continuous watermark chain across multiple response fragments.

[0157] Before outputting each response fragment to the client, the system performs the following checks on the fragment: It checks if the fragment's runtime domain fingerprint matches the target runtime domain; it checks if the fragment round number matches the current request round; it checks if the fragment sequence number is consecutive and not repeated; it checks if the current input digest matches the input of this round's request; it checks if the current fragment watermark can form a continuous chain with the watermarks of previous fragments; and it checks if the fragment's role belongs to an agent response role that is allowed to be output. Only response fragments that pass the above checks are allowed to be output to the client and enter the final response set.

[0158] If a segment originates from a historical round, another agent, another operational domain, is not part of the current request, or exhibits duplication, out-of-order formatting, rollback, or anomalies in the first frame aggregation, its operational domain fingerprint, round number, segment sequence number, current input summary, or preceding watermark relationship will fail verification. The system will filter this segment and record the reason for the filtering. Figure 5 This is used to illustrate how chain-like causal relationships between response fragments verify the attribution and order consistency of streaming output, thereby reducing the probability of problems such as historical response interference, cross-agent response mixing, repetitive incremental splicing, and out-of-order output. Figure 5 In this context, F_D represents the runtime domain fingerprint. Indicates the running instance identifier, Let Q_t represent the round number, which can be represented by a timestamp t. Let Q_t represent the current input. Let y1, y2, y3, and y4 represent the sequentially generated response fragment numbers. Let seq_i (seq_1, seq_2, seq_3, seq_4) represent the fragment sequence number. Let y_i (e.g., y_1, y_2, y_3, y_4) represent the i-th response fragment. Let W_i (e.g., W_0, W_1, W_2, W_3) represent the causal watermark of the i-th response fragment. Let W_prev represent the causal watermark of the previous response fragment. Let H(Q_t) represent the summary of the current input, and H(y_i) represent the summary of the i-th response fragment. This indicates an abnormal response segment; This indicates the abnormal cause-effect watermark corresponding to the abnormal response segment; Indicates the segment number or the position of the exception insertion corresponding to the exception response segment; This represents the set of valid response segments within the target runtime domain. The causal watermark W_i of the i-th response segment is generated based on the runtime domain fingerprint, runtime instance identifier, round number, segment sequence number, current input digest, current response segment digest, and the causal watermark of the previous response segment, and is represented as: W_1 = H(F_D, , , seq_1, H (y_1), W_0, H (Q_t)); W_2=H (F_D, , , seq_2, H (y_2), W_1, H (Q_t)); W_3=H (F_D, , , seq_3, H (y_3), W_2, H (Q_t)); W_4=H (F_D, , , seq_4, H(y_4), W_3, H(Q_t)). “role=AI?” indicates that the agent role may be incorrect.

[0159] This embodiment improves the consistency of streaming response segment attribution and output reliability. Specifically, through a causal watermarking mechanism, a causal watermark is generated for each response segment in the streaming output, containing a runtime domain fingerprint, runtime instance identifier, round number, segment sequence number, current input summary, current segment summary, and previous segment summary. Before outputting segments to the client, the system verifies runtime domain attribution, round number attribution, segment sequence number continuity, current input consistency, and watermark chain integrity. This mechanism reduces the probability of historical round content, responses from other agents, non-currently requested segments, duplicate segments, out-of-order segments, rollback segments, or abnormal aggregation of the first frame content entering the current output. Compared to methods that rely solely on text hash deduplication, message role judgment, or single message identifier filtering, this embodiment verifies the causal continuity between response segments through chain watermark relationships, enabling a more accurate determination of whether a segment belongs to the current runtime domain, current round, and current input.

[0160] Based on the above embodiments, a dynamic isolation level adjustment mechanism is also proposed. The system can calculate the operational risk based on the data sensitivity level of the current request, the tool risk level, the complexity of cross-agent calls, the risk of memory contamination, historical anomalies, and streaming output anomalies, and determine the isolation level accordingly.

[0161] Optionally, operational risks It can be represented as:

[0162]

[0163] in, This indicates a risk of data sensitivity. Indicates instrumental risk; This indicates the risk of cross-agent invocation; This indicates a risk of memory contamination. This represents the risk of abnormality in the streaming response; α, β, γ, δ, and η represent the weighting parameters, respectively.

[0164] When the operational risk is low, the system can adopt basic operational domain isolation; when the operational risk increases, the system can enable strategies such as strong verification of operational domain fingerprints, shadow operational domain rehearsal, tool whitelist, long-term memory read-only, response fragment causal watermark verification, abnormal memory freezing, and audit enhancement; when the operational risk exceeds a preset threshold, the system can terminate the current request, roll back the default agent, or prompt manual inspection, thereby improving security.

[0165] Through a dynamic isolation level adjustment mechanism, the system calculates operational risks based on the data sensitivity level, tool risk level, cross-agent call complexity, memory contamination risk, historical anomalies, and streaming output anomalies of the current request, and determines the isolation strategy for the current request based on these risks. For low-risk requests, the system can use basic operational domain isolation; for medium- to high-risk requests, the system can further enable strategies such as shadow operational domain rehearsal, tool whitelisting, long-term memory read-only, strong verification of causal watermarks for response fragments, anomaly memory freezing, and enhanced auditing. This mechanism avoids the problems of insufficient security capabilities or excessive system overhead caused by using a fixed isolation strategy for all requests, enabling the multi-agent system to adaptively adjust the security control strength according to the business scenario and operational status. In scenarios involving medical care, scientific research, report generation, external tool calls, or sensitive data access, this mechanism can significantly improve the system's control capabilities for high-risk tasks.

[0166] Furthermore, an abnormal memory freezing and runtime domain rollback mechanism is proposed. When the system detects runtime domain fingerprint inconsistency, resource binding proof failure, context fragment pollution, skill unauthorized invocation, response fragment watermark chain breakage, memory write version conflict, or model service anomaly, the system triggers an abnormal freezing and runtime domain rollback process. This process may include: First, terminating the current abnormal output and stopping the continued sending of unverified fragments to the client; Second, freezing the newly added memories, tool results, and context summaries in this round to prevent them from entering long-term memory; Third, locating the set of affected nodes along the memory pollution propagation graph; Fourth, freezing, demoting, isolating, or deleting pending confirmation markers for affected nodes; Fifth, rolling back to the most recent trusted memory version or regenerating the summary based on unpolluted nodes. The regenerated summary is used to remove or weaken the impact of polluted memory nodes on subsequent context construction, reducing the risk of subsequent rounds of inference continuing to reference abnormal memories; Sixth, selecting to roll back the default agent, enter read-only memory mode, close high-risk tools, or re-execute shadow runtime domain pre-play according to the anomaly type; Seventh, writing the anomaly type, scope of impact, processing actions, and rollback results to the runtime domain-level audit log. Through this mechanism, the system can not only prevent abnormal responses from continuing to be output, but also reduce the lasting impact of abnormal memories on subsequent agent calls and multi-turn dialogues.

[0167] Furthermore, a result write-back and runtime domain-level audit trail mechanism is proposed. After the current request is completed, the system will write the effective response, context summary, tool call record, memory update record, exception handling result, and audit information to the storage location corresponding to the current runtime domain.

[0168] Optionally, write-back records are generated based on the runtime domain fingerprint, current input, target agent, context summary, set of valid response fragments verified by causal watermarking, tool call records, memory update records, exception handling records, audit trail records, and timestamps.

[0169] Runtime domain-level audit logs can record at least the following: target agent parsing results, runtime domain fingerprint, resource binding proof, shadow runtime domain verification results, actually loaded configuration and personality files, actually activated tools and skills, source of the fragment entering the context, filtered fragments and reasons for filtering, response fragment watermark chain, memory contamination propagation relationships, anomaly freeze and rollback operations, and the final result write-back location. Through this mechanism, the system can trace the complete processing chain based on the runtime domain fingerprint when memory contamination, response misalignment, resource mismatch, or skill overreach occurs, pinpointing the anomaly's occurrence and scope of impact. This solves the problem that traditional log auditing struggles to correlate the entire process of agent parsing, resource binding, context fragments, response fragments, memory contamination propagation, and anomaly rollback.

[0170] Optionally, the abnormal freeze and runtime domain rollback policy can be set to automatic mode, semi-automatic mode, or manual confirmation mode to adapt to different security levels and business scenarios.

[0171] This embodiment can perform memory freezing and runtime rollback after an anomaly occurs. When runtime fingerprint inconsistency, resource binding proof failure, context fragment contamination, unauthorized skill calls, broken response fragment watermark chains, or memory write version conflicts are detected, the anomaly memory freezing and runtime rollback mechanism can be triggered. The system can terminate the current anomaly output, freeze the newly added memories, tool results, and context summaries, identify affected nodes along the memory contamination propagation graph, and roll back to the most recent trusted memory version or regenerate the summary based on uncontaminated nodes.

[0172] Therefore, the solution in this embodiment not only prevents the continued output of abnormal content when an anomaly occurs, but also reduces the risk of abnormal content being written into long-term memory and repeatedly used in subsequent tasks. This mechanism enables multi-agent systems to have anomaly recovery capabilities, limiting the impact of erroneous responses, contaminated memory, and unauthorized tool results to a controllable range.

[0173] Example 4

[0174] For reference Figure 5 The flowchart shown below illustrates a multi-mechanism collaborative closed-loop process, which includes the following steps:

[0175] S1. Receive the request and parse the identity information.

[0176] S2, Target Agent Analysis.

[0177] S3. Obtain the target intelligent agent's bound resources.

[0178] S4. Generate runtime domain fingerprint.

[0179] S5. Construct the target runtime domain.

[0180] S6, Shadow Run Domain Preview and Resource Binding Proof.

[0181] S7. Isolate the loaded memory and build a security context.

[0182] S8. Schedule target intelligent agents and authorized tools or skills.

[0183] S9. Verify the causal watermark of the response fragment and filter out abnormal fragments.

[0184] S10, Result Writeback, Memory Contamination Propagation Records and Operational Domain-Level Audit Tracking.

[0185] This embodiment improves the audit tracing and problem localization capabilities of multi-agent systems. Using runtime fingerprints as indexes, it records target agent parsing results, resource binding proofs, shadow runtime pre-simulation results, context fragment sources, tool and skill call records, response fragment causal watermark chains, memory contamination propagation relationships, abnormal freeze and rollback operations, and the final result write-back location. Through this mechanism, when the system experiences memory crosstalk, response misalignment, resource mismatch, skill overreach, or abnormal write-back, the complete processing chain can be traced based on the runtime fingerprint. Unlike ordinary logs that only record interface calls, error messages, or tool call results, the audit logs in this embodiment can associate processes such as "how the target agent was determined," "which resources were loaded," "which fragments entered the context," "which response fragments were output or filtered," "which memory nodes were affected," and "what freeze or rollback operations were taken" with the same runtime domain, thereby improving the efficiency of problem localization and operational controllability in complex and abnormal scenarios.

[0186] This embodiment is compatible with existing multi-agent systems and supports incremental upgrades. This embodiment can be incrementally introduced onto existing multi-agent service frameworks. For existing default agent invocation logic, the system can retain default routes and default resource loading methods; for newly added domain agents, independent agents, or multi-agent workflows, the system can gradually incorporate them into trusted runtime domain management through agent registry, agent description files, business assistant identifier mapping relationships, runtime domain fingerprints, and resource binding verification mechanisms.

[0187] Therefore, this embodiment does not require a complete reconstruction of the entire business system and is compatible with existing session management, workflow scheduling, tool invocation, and memory storage solutions. Furthermore, as business scenarios expand, the system can continue to introduce new target agents, new skill catalogs, new permission policies, new storage media, and new auditing policies, thereby improving engineering scalability and deployment flexibility.

[0188] This embodiment achieves a closed-loop control effect through multi-mechanism collaboration. The technical effectiveness of this embodiment does not solely stem from the static isolation of memory spaces for different users, sessions, or agents, but rather from the synergistic effect of multiple technical mechanisms: runtime fingerprinting is used to uniformly represent and verify the current execution environment; shadow runtime domains are used to detect resource mismatches and contextual risks before formal execution; resource binding proofs are used to verify the consistency between the business-side assistant identifier and the underlying agent resources; context taint marking is used to control the range of fragments entering model input; memory contamination propagation graphs are used to trace the impact path of abnormal memories; response fragment causal watermarking is used to verify the attribution and continuity of streaming output; anomaly freezing and runtime rollback are used to limit the subsequent spread of abnormal content; and runtime-level auditing is used to form a traceable processing chain. Therefore, compared to simple multi-agent routing, ordinary session memory storage, conventional access control, or simple streaming deduplication schemes, this embodiment has a more complete technical chain and a more clearly defined collaborative technical effect. The improvement focuses on enabling multi-agent systems to have comprehensive capabilities such as "verifiable execution environment, verifiable context source, traceable contamination propagation, verifiable streaming segments, and rollback of abnormal states," rather than simply achieving resource isolation in the ordinary sense.

[0189] In summary, the solution presented in this embodiment can uniformly represent and verify the complete execution environment of multi-agent requests; detect resource mismatches and context risks before formal model invocation; verify the binding relationship between the business-side assistant identifier and the underlying agent resources; determine the source, permissions, credibility, and contamination status of context fragments; track the propagation path of abnormal memories and suppress contamination spread; improve the consistency of ownership and output reliability of streaming response fragments; dynamically adjust the isolation strength according to operational risks; perform memory freezing and runtime domain rollback after an anomaly occurs; improve audit tracing and problem localization capabilities; and be compatible with existing multi-agent systems and support incremental upgrades.

[0190] This embodiment of the solution can improve the system's context security, resource binding reliability, response consistency, memory pollution suppression capability, anomaly recovery capability, and engineering maintainability in multi-user, multi-session, multi-domain, and multi-agent concurrent service scenarios.

[0191] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 7 As shown, the electronic device 500 includes one or more processors 501 and memory 502.

[0192] The processor 501 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 500 to perform desired functions.

[0193] The memory 502 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 501 may execute the program instructions to implement the multi-agent operation control method of any embodiment of this application described above, and / or other desired functions. Various contents such as initial extrinsic parameters and thresholds may also be stored in the computer-readable storage medium.

[0194] In one example, the electronic device 500 may further include an input device 503 and an output device 504, these components being interconnected via a bus system and / or other forms of connection mechanisms (not shown). The input device 503 may include, for example, a keyboard, a mouse, etc. The output device 504 may output various information to the outside. The output device 504 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0195] Of course, for the sake of simplicity, Figure 7 Only some of the components of the electronic device 500 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 500 may include any other suitable components depending on the specific application.

[0196] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. The above descriptions are only preferred embodiments of this application. It should be noted that due to the limitations of written expression, while there are objectively infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this invention, and can also combine the above technical features in an appropriate manner. These improvements, modifications, changes, or combinations, or the direct application of the inventive concept and technical solution to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A method for managing and controlling the operation of multiple agents, characterized in that, include: Receive user requests and determine the current task identifier, target intelligent agent, and the running resources bound to the target intelligent agent based on the user requests; Based on the current task identifier, the target agent, and the running resources, a target running domain is constructed at the logical level, and resource data that the target agent is allowed to access is defined within the target running domain; Before invoking the target intelligent agent, a physical-level shadow execution domain is constructed according to the definition of the target execution domain. The shadow execution domain is used to instantiate and load the specific resource entities defined by the target execution domain. The system-side pre-run verification is performed on the resource entities within the shadow runtime domain. The system-side pre-run verification is used to verify whether the resource entities loaded in the runtime environment are consistent with the resource data defined by the target runtime domain. Generate a resource binding certificate and perform business-side verification based on the resource binding certificate. The business-side verification is used to verify whether there is a binding relationship declared in the smart agent registry between the assistant identifier passed in by the business side and the underlying actually loaded smart agent and its resources. If both the pre-run verification on the system side and the verification on the business side pass, the target intelligent agent is invoked to perform model inference. During or after the invocation of the target intelligent agent to perform model inference, the model context fragment, response fragment, and memory update content are verified based on the target operating domain, and the verified content and corresponding audit information are written into the target operating domain.

2. The multi-agent operation control method according to claim 1, characterized in that, The resource entities include at least model configuration files, personality hint files, skill catalogs, and tool files; The pre-run verification of resource entities within the shadow runtime domain on the system side includes: Verify whether the model configuration file, personality hint file, skill directory and tool file actually loaded in the shadow running domain can be initialized normally, and whether they belong to the resource data limited by the target running domain.

3. The multi-agent operation control method according to claim 1, characterized in that, The process of generating a resource binding certificate and performing business-side verification based on the resource binding certificate includes: Calculate the actual loaded model configuration summary, personality prompt summary, skill catalog summary, and permission policy summary in the shadow running domain, and compare them with the corresponding declaration summaries recorded in the agent registry. If there are inconsistent summaries, the business-side verification is deemed to have failed.

4. The multi-agent operation control method according to claim 1, characterized in that, The step of constructing the target runtime domain at the logical level based on the current task identifier, the target agent, and the runtime resources includes: A runtime domain fingerprint is generated based on the current task identifier, the target intelligent agent, and the representation information of the runtime resources. The runtime domain fingerprint is used to identify the execution environment that responds to the user request. The target runtime domain is constructed based on the runtime domain fingerprint.

5. The multi-agent operation control method according to claim 1, characterized in that, Before invoking the target agent to perform model inference, the method further includes: Each candidate context fragment entering the model context is structurally labeled and quantitatively scored; Candidate context segments whose quantitative scores reach a preset threshold are identified as target context segments; The target context fragment is used as an input element for the target agent to assist the target agent in performing model inference. The quantitative score is determined from at least the following four dimensions: the relevance of the candidate context fragment to the user request, whether the candidate context fragment belongs to the allowed access fragments defined by the target operating domain, the credibility value of the candidate context fragment, and the risk value. Specifically, based on the source type, generation method, verification mechanism, and operating domain fingerprint of the candidate context fragment, a preset credibility mapping table is queried to obtain the corresponding credibility value; Based on the sensitivity level, pollution marker, permission status, expiration status, and abnormal characteristics of the candidate context fragments, a weighted sum is accumulated according to preset risk weights to obtain the risk value of the candidate context fragment.

6. The multi-agent operation control method according to claim 1, characterized in that, After invoking the target agent to perform model inference, the method further includes: generating a causal watermark for each response fragment generated by the target agent, wherein the causal watermark of the i-th response fragment is represented as: in, This represents the causal watermark of the i-th response fragment. Indicates the running domain fingerprint, Indicates the identifier of the currently running instance. Indicates the current round number. This represents the segment number of the i-th response segment. This represents the i-th response fragment. This represents the causal watermark of the (i-1)th response fragment. Indicates the current input; Represents a mapping function; Each response fragment is validated based on causal watermarks, and the validated response fragments are provided to the user and added to the response set.

7. The multi-agent operation control method according to claim 6, characterized in that, The verification of each response fragment based on causal watermarking includes one or more of the following: Verify whether the runtime domain fingerprint carried in the response fragment is consistent with the current runtime domain fingerprint; Verify whether the current round number corresponding to the response fragment is consistent with the current round; Verify whether the sequence number of the response segment is consecutive and not repeated with the sequence number of the preceding response segment; Verify that the current input digest matches the digest requested by the user in this round.

8. The multi-agent operation control method according to claim 1, characterized in that, Also includes: User input, response fragments, tool call results, context summaries, and memory update content are written into the target operating domain, and the memory pollution propagation graph is updated based on user input, response fragments, tool call results, context summaries, and memory update content; the memory pollution propagation graph is used to track the propagation path of anomalous content in multi-turn dialogues and cross-agent collaborations.

9. The multi-agent operation control method according to claim 1, characterized in that, Also includes: User input, response fragments, tool call results, summary memory, and long-term memory are abstracted into memory propagation nodes, and a memory pollution propagation graph is constructed based on citation relationships, summary relationships, tool call relationships, and writing relationships; Memory pollution transmission map Represented as: in, Represents the set of propagation nodes. This represents the set of propagation edges; propagation nodes include user input nodes, agent output nodes, tool result nodes, summary nodes, and long-term memory nodes; propagation edges represent the logical relationships between nodes; When an anomaly is detected in a node, the node is marked as an anomaly node, and the set of affected nodes is determined along the memory contamination propagation graph.

10. An electronic device, characterized in that, The electronic device includes: Processor and memory; The processor executes the steps of the multi-agent operation management method as described in any one of claims 1 to 9 by calling the program or instructions stored in the memory.

Images