A method for maintaining consistency of heterogeneous AI capability resources in a double-layer gateway

Abstract

The application provides a kind of consistency maintenance method of heterogeneous AI capability resource in double-layer gateway in the technical field of artificial intelligence and distributed system, comprising the following steps: taking Agent identification as cross-gateway association anchor point, registering its dependent heterogeneous AI capability resource in Agent unit in the registration domain of business gateway and running gateway;By analyzing Agent dependency declaration, the dependency relationship between Agent and resource is obtained, and a directed dependency graph and a reverse index are constructed;When the resource in any registration domain changes, the affected Agent is located according to the reverse index, and the candidate resource view is generated by incremental updating the dependent subgraph;Then, based on the dependency strength and version constraint, the readiness state of the resource in the candidate view is verified, and if the condition is met, the atomic switch is switched to the current active resource view;In the access request stage of business gateway, access control is implemented according to the active view information.The application has the advantages that the resource dependency unified management is realized with business entity as anchor point in the whole life cycle of Agent.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and distributed systems technology, and in particular to a method for maintaining the consistency of heterogeneous AI capability resources in a two-layer gateway. Background Technology

[0002] With the rapid development of large language models and intelligent agent technologies, enterprise-level AI platforms commonly adopt a two-layer gateway architecture to support intelligent agent services. In this architecture, the business access gateway (closer to the caller) is responsible for managing business layer information such as applications, tenants, credentials, agent business identities, service addresses, and routing status; the model execution gateway (closer to the model execution side) is responsible for managing execution layer information such as AgentCard, runtime parameters, MCP (Model Context Protocol) servers and tools, Skill content, and runtime injection methods. Under this architecture, the Agent is the core business entity spanning both layers, while the MCP toolset and Skill runtime resources constitute the heterogeneous AI capability foundation upon which the Agent relies to execute specific tasks.

[0003] Since the aforementioned heterogeneous resources belong to different gateway management domains and each has its own independent lifecycle, version evolution logic, and state change mechanism, how to maintain the consistency and verifiability of the heterogeneous resource set between the two-layer gateways, and ensure that the resource combination that the Agent depends on at any time is complete and version aligned, has become a key technical bottleneck restricting the stability of the system.

[0004] Currently, existing engineering practices mainly adopt a maintenance strategy of "domain-specific autonomy and loose coupling". Specifically: the business access gateway maintains basic Agent attributes through a shared database table, and only verifies the existence of routing configurations before going live; the model running gateway maintains the MCP server registry, tool-level permissions, health status, and Skill database separately. The association between the Agent and the MCP is dynamically determined at runtime through the intersection operation of permission fields, and Skill resources are read on demand based on the identifier temporarily carried in the request context. When the MCP changes, the entire registry (new_registry) is rebuilt and assigned to the in-memory registry (registry) to avoid a half-updated state.

[0005] However, the aforementioned domain-based autonomy strategy suffers from the following structural technical defects when dealing with the dynamic evolution of heterogeneous resources. These defects are not simply a matter of superior or inferior engineering implementation, but rather stem from the fragmentation of the underlying data architecture: I. Missing semantics of resource versions and insufficient atomicity of snapshots Although the two gateways share the same Agent identifier, their routing configurations, MCP permissions, tool structures, and Skill content change independently, lacking a unified version association mechanism between the data sources. Timestamps alone cannot prove which version combination of resources a particular execution depends on, nor can they determine whether multiple resource reads originate from the same consistent point in time. Furthermore, while the MCP manager can guarantee atomic registry replacement for a single resource, Agent permissions, Skill versions, and routing states are not bound to the MCP registry as immutable resource snapshots. In concurrent scenarios, different requests can easily combine to create a mixed view of "old permissions + new MCP + old Skill + new route," failing to guarantee the global atomicity of the resource view at the Agent granularity.

[0006] II. Execution view uncertainty caused by non-persistent dependency relationships There is an indirect permission-based relationship between the Agent and the MCP, but there is a lack of persistent, version-constrained dependency records between the Agent and the running Skill. The method of temporarily carrying Skill identifiers in requests means that different requests may resolve to different versions of the Skill. Simultaneously, changes to permission groups or toolsets can cause unexpected "drifts" in the MCP toolset visible to the Agent, resulting in inconsistent and difficult-to-track resource views for the same Agent at different times. When a dependent Skill database record is missing, the existing mechanism only logs an alert and continues processing, resulting in a lack of ability to silence configuration errors and failing to meet the "fail-closed" security principle.

[0007] III. The ambiguous scope of the impact of the changes and the lack of safe convergence for high-risk operations When resources are added, deleted, or permissions are revoked, a full reload results in high network detection costs and significant latency. If only a single resource is refreshed, the system lacks a reverse index from resource to Agent and a mechanism for calculating affected closures, making it difficult to accurately locate the set of Agents requiring re-verification, potentially leading to missed updates. Particularly for high-risk changes such as resource deletion and permission revocation, in cases of duplicate or out-of-order event delivery, a simple "last-write-wins" strategy may make revoked resources visible again. Existing technologies lack a secure convergence mechanism for out-of-order change events.

[0008] In summary, there is currently a lack of a complete technical solution that can perform unified version tracking, persistent dependency management, incremental impact analysis, and atomic consistency switching of heterogeneous AI capability resources with Agent as the anchor point under a two-layer gateway architecture.

[0009] Therefore, how to provide a consistent maintenance method for heterogeneous AI capability resources in a two-layer gateway, and improve the atomic consistency, execution view determinism and traceability of heterogeneous AI capability resources in cross-management domain collaboration under the two-layer gateway architecture, as well as the accurate perception and secure convergence of the impact of changes, so as to achieve unified governance of resource dependencies anchored by business entities throughout the Agent's entire lifecycle, has become an urgent technical problem to be solved. Summary of the Invention

[0010] The technical problem to be solved by this invention is to provide a method for maintaining the consistency of heterogeneous AI capability resources in a two-layer gateway, thereby improving the atomic consistency, execution view determinism and traceability of heterogeneous AI capability resources in cross-management domain collaboration under the two-layer gateway architecture, as well as the ability to accurately perceive and securely converge the impact of changes, so as to achieve unified governance of resource dependencies anchored by business entities throughout the entire lifecycle of the Agent.

[0011] This invention provides a method for maintaining consistency of heterogeneous AI capability resources in a two-layer gateway, comprising the following steps: Step S1: Using the Agent identifier as the cross-gateway association anchor point, in the registration domains corresponding to the business gateway and the operation gateway in the two-layer gateway, the heterogeneous AI capability resources on which the Agent depends are registered in separate domains, with the Agent corresponding to the Agent identifier as the unit, and a registration record containing resource identifier and version information is generated for each heterogeneous AI capability resource. Step S2: Obtain the dependency declaration of the Agent, and parse the dependency declaration into the dependency relationship between the Agent and each of the heterogeneous AI capability resources. The dependency relationship includes dependency strength information and version constraint information. Step S3: Based on the dependency relationship obtained by parsing, construct a directed dependency graph with the Agent as the starting point and each of the heterogeneous AI capability resources as nodes, and establish a reverse index from each of the heterogeneous AI capability resources to the Agent that depends on the resource. Step S4: When the heterogeneous AI capability resources in any registered domain change, determine the set of Agents affected by the change based on the reverse index, perform incremental update processing on the subgraph of the directed dependency graph corresponding to each Agent in the Agent set, and generate a candidate resource view; Step S5: Based on the dependency strength information and version constraint information of the dependency relationship, verify the readiness status of each heterogeneous AI capability resource that the Agent depends on in the candidate resource view, and obtain the readiness determination result of the candidate resource view. Step S6: When the readiness determination result meets the preset conditions, the Agent's current active resource view is atomically switched to the candidate resource view; Step S7: During the request admission phase of the business gateway, obtain the current activity resource view information of the Agent, and perform admission control on the request based on the activity resource view information.

[0012] Furthermore, in step S1, the heterogeneous AI capability resources include at least one of Agent business resources, Agent runtime resources, Model Context Protocol server resources, Model Context Protocol tool resources, Skill runtime resources, Routing resources, Permission resources, and runtime environment resources; The business gateway is the authoritative domain for registering Agent business resources and routing resources, and the runtime gateway is the authoritative domain for registering Agent runtime resources, Model Context Protocol server resources, Model Context Protocol tool resources, Skill runtime resources, Permission resources and runtime environment resources. Each of the registered domains sets up an event stream according to the resource category, and assigns a monotonic change sequence number to the addition, modification and deletion of the heterogeneous AI capability resources within the event stream. The deletion operation is marked with a tombstone. The registration record also includes the change sequence number and event stream attribution information.

[0013] Furthermore, in step S2, the dependency strength information includes required dependencies or optional dependencies; the access group dependencies and toolset dependencies in the dependency declaration are expanded into specific server dependencies and specific tool dependencies; heterogeneous AI capability resources that do not explicitly declare the dependency strength information are defaulted to required dependencies or set to a pending confirmation state according to the security policy. The version constraint information is represented by at least one of the following methods: precise version, semantic version range, content summary whitelist, or capability predicate; the content summary, permission summary, and routing summary of each heterogeneous AI capability resource participate in the unique identifier calculation of the candidate resource view.

[0014] Furthermore, in step S3, the node types in the directed dependency graph include at least Agent nodes, Model Context Protocol server nodes, Model Context Protocol tool nodes, skill nodes, routing nodes, permission nodes, and runtime environment nodes; the dependency relationship is determined by at least one of direct reference, access group resolution, toolset resolution, or capability predicate matching, and the dependency relationship obtained by indirect resolution is solidified as an edge carrying source proof.

[0015] Furthermore, in step S4, before the incremental update processing, a step of verifying the resource change event is also included: Acquire resource change events, wherein the resource change event includes an idempotency identifier, the domain to which it belongs, the event stream, the change sequence number, and the resource identifier; If the change sequence number is equal to the current event stream cursor plus one, then in the same transaction, write the new version or tombstone marker of the heterogeneous AI capability resource, advance the event stream cursor, persist the affected Agent set, and write the task to be recalculated or the transaction outer box record; after the transaction is committed, deliver the task to be recalculated; when the system restarts, scan and continue to process the unfinished task to be recalculated or the transaction outer box record. If the change sequence number is less than or equal to the current cursor, then the resource change event is ignored; If the change sequence number is greater than the current cursor plus one, the out-of-order resource change event will not be applied, the corresponding event flow cursor and consistency level will not be advanced, the affected Agent determined based on the resource identifier carried by the out-of-order resource change event and the existing reverse index will be marked as pending, and the corresponding candidate resource view will remain in a pending state. At the same time, missing events will be filled in. After the missing events are filled in, the set of affected Agents and the reverse impact closure will be recalculated based on the complete event sequence, and then the resource change events will be applied in sequence and the event flow cursor and consistency level will be advanced.

[0016] Furthermore, in step S4, the types of changes to the heterogeneous AI capability resources include normal updates, compatibility breaches, and security reversals; When the change of the heterogeneous AI capability resource is to be safely revoked, an revocation barrier is immediately established, the resource view containing the revoked resource is marked as revoked, new requests are prevented from fixing the revoked resource view, and in-transit requests that have fixed the resource view are processed in accordance with the revocation policy. When changes to the heterogeneous AI capability resources result in compatibility breaches, the incremental update processing priority of the affected Agents is increased.

[0017] Furthermore, in step S5, the readiness state verification includes verifying at least one of the following: the existence of heterogeneous AI capability resources, version matching, content summary, approval status, authorization status, health status, tool structure compatibility, routing configuration integrity, and runtime environment compatibility. The readiness determination result includes a ready state, a downgraded state, a blocked state, and a pending state. Specifically, a blocked state is determined when any required dependency verification fails; a downgraded state is determined when only optional dependency verification fails and the downgrade strategy allows it; and a pending state is determined when verification is incomplete or when data gaps exist. The priority of the ready state, degraded state, blocked state, and pending state is as follows: blocked state is higher than pending state, pending state is higher than degraded state, and degraded state is higher than ready state. Service activation state and route reachability are calculated independently during the admission phase of the service gateway and are not mixed into the ready determination result.

[0018] Furthermore, in step S6, the candidate resource view is constructed as an immutable object, which includes view version, consistency watermark vector, resource list and policy version information; If a change in the version or strategy version of a related heterogeneous AI capability resource is detected during the verification process, the current candidate resource view will be invalidated and reconstructed. The preset conditions include at least the readiness determination result being either a ready state or a downgraded state allowed by the policy; if the readiness determination result is a blocking state, then the candidate resource view is refused activation; when it is confirmed that a necessary dependency has failed, the running gateway updates the readiness projection of the current active resource view of the corresponding Agent to a blocking state, and the business gateway blocks new requests according to the blocking state; when the change type of the heterogeneous AI capability resource is security revocation, a revocation barrier is further set, and the resource view containing the revoked resource is marked as revocation state; The atomic switching is achieved through a comparison-swap operation, the conditions of which include at least that the current active resource view version is consistent with the expected version and the consistency level has not changed; if the comparison-swap operation fails, the incremental update process and candidate resource view generation are re-executed.

[0019] Furthermore, in step S7, before and after the switch, admitted in-transit requests continue to use the old active resource view fixed before the switch, and new requests after the switch use the new active resource view after the switch; the resource list of the candidate resource view is fixed with the actual hit resource version or content summary; before the lease or reference count of any resource view referencing the corresponding resource version reaches zero and the reclamation condition is met, the corresponding resource version is retained, and it is ensured that resources can be located according to resource version or content summary; The in-transit request holds a lease or reference count for the old active resource view. When the reference count reaches zero and the reclamation conditions are met, the old active resource view is reclaimed. The access control specifically includes: Obtain a readiness receipt containing the view version, readiness determination result, and consistency watermark vector from the running gateway; The service gateway verifies the readiness receipt and calculates the final admission decision result by combining the service activation status and route reachability of the Agent; When the readiness receipt verification fails or the readiness determination result is blocking, the final admission determination result is blocking; when the readiness receipt expires or there are data gaps, the final admission determination result is pending; blocking takes precedence over pending.

[0020] Furthermore, the method also includes: Step S8: Record resource change events, dependency graph change summaries, candidate resource view verification results, atomic switch results, and ready receipts as audit evidence; When the system restarts, it restores the running state from the currently active resource view, each event stream cursor, and unfinished events; When the same view identifier is generated due to repeated event processing, the existing candidate resource view is reused.

[0021] The advantages of this invention are: 1. By versioning and registering all heterogeneous AI capability resources anchored by Agent identifiers and incorporating them into a unified event stream, a directed dependency graph and inverted index containing dependency strength and version constraints are constructed. This allows for precise identification of the affected Agent set and incremental updates when resources change, generating candidate resource views as immutable and consistent snapshots. After rigorous blocking priority readiness verification, the active view is switched through atomic comparison and exchange operations. Simultaneously, the monotonic change sequence number and cursor verification mechanism of the event stream ensure the orderly processing of change events and prevent out-of-order overwriting. Furthermore, an immediate barrier is established for safe rollback operations to mitigate convergence risks. This fundamentally eliminates the problem of mixed views and resource drift caused by domain autonomy, ensuring that each execution request is fixed to a clear, traceable, and fully compliant version-aligned resource combination. Audit logs and system restart recovery mechanisms ensure traceability and operational resilience throughout the entire process, thereby achieving unified governance of resource dependencies anchored by business entities throughout the Agent's entire lifecycle.

[0022] 2. By assigning registration records containing resource identifiers and version information to each heterogeneous AI capability resource, and constructing the candidate resource view as an immutable object containing view version, consistency watermark vector, and resource list, view switching is performed using atomic comparison and exchange operations. This mechanism binds all heterogeneous resources that the Agent depends on (including MCP servers, tools, skills, routes, permissions, etc.) into an immutable, logically timestamped snapshot, ensuring that the combination of resources that the Agent depends on at any given time has global atomicity and provability, fundamentally eliminating the risk of resource views being fragmented or mixed under concurrent changes.

[0023] 3. By obtaining the Agent's dependency declaration, the dependency relationships containing dependency strength information and version constraint information are parsed out, and a directed dependency graph starting from the Agent and a reverse index from the resource to the Agent are constructed accordingly. This mechanism elevates the Agent's dependency on heterogeneous resources from implicit, temporary resolution at runtime to explicit, persistent declaration at design time. Resource versions are solidified through constraints such as precise versioning, semantic version range, or content digests, ensuring that the same Agent can always resolve a deterministic resource view when faced with the same dependency declaration throughout its lifecycle. This effectively avoids unexpected behavior caused by permission drift or resource version updates, while providing a solid foundation for "failure shutdown" verification of the system.

[0024] 4. By establishing a reverse index pointing from heterogeneous AI capability resources to Agents that depend on those resources, the set of affected Agents can be accurately identified when resources change. Incremental updates are then performed only on the directed dependency graph subgraphs corresponding to these Agents to generate candidate resource views. Simultaneously, for changes requiring safe reversal, a reversal barrier is immediately established to prevent new requests from fixing the reversed view. A strict change sequence verification mechanism handles out-of-order events, preventing reversed resources from becoming visible again due to event reordering. This mechanism achieves precise, closed-loop impact path tracing from resource changes to affected Agents, avoiding both the high cost of full reload and the risk of omissions from single-item refreshes, providing deterministic convergence guarantees for high-risk changes.

[0025] 5. By constructing a complete defense line from readiness state verification to business gateway admission control, the readiness state verification rigorously checks necessary dependencies, and the failure of any necessary dependency results in a blocking state. In the admission phase, the business gateway independently calculates the final admission decision by comprehensively considering the candidate resource view verification results, Agent service activation status, and route reachability, and explicitly stipulates that blocking takes precedence over pending. This layered verification mechanism ensures that any view change that fails consistency verification cannot enter business traffic, achieving true "failure shutdown." At the same time, by isolating in-transit requests and new requests (old views continue to serve in-transit requests, and new requests use new views), system availability is ensured while maintaining consistency.

[0026] 6. By organizing resource changes according to event streams and monotonic change sequences, retaining deletion operations with tombstone markers, and solidifying intermediate results of dependency resolution as persistent edges with provenance, event processing possesses idempotent verification capabilities. Upon system restart, the system resumes its running state from the currently active resource view, event stream cursor, and incomplete events. This event sourcing architecture not only provides a complete audit evidence chain for every view switch and admission decision, but more importantly, it endows the system with the ability to deterministically rebuild a consistent state after a failure. Combined with a view identifier reuse mechanism, it effectively avoids redundant computation overhead, significantly improving the system's robustness and maintainability in a distributed environment.

[0027] 7. The heterogeneous elements such as Agent business resources, runtime resources, MCP servers, MCP tools, skill runtime resources, routing resources, permission resources, and runtime environment resources are uniformly incorporated into the resource governance model, and authoritative domains are divided between the business gateway and the runtime gateway according to their home domains. At the same time, the node types in the directed dependency graph fully cover the above resource elements, enabling this solution to completely depict the full-link dependency relationship of the Agent from "identity-permission-routing" to "runtime environment-tool capabilities-skill content". This achieves unified resource dependency governance with business entities as anchors throughout the Agent's entire lifecycle, providing a systematic and standardized technical solution for the management of heterogeneous AI capability resources under a two-layer gateway architecture. Attached Figure Description

[0028] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0029] Figure 1 This is a flowchart of a method for maintaining consistency of heterogeneous AI capability resources in a two-layer gateway according to the present invention. Detailed Implementation

[0030] The overall approach of the technical solution in this application is as follows: By using the Agent identifier as a unified association anchor point across gateways, heterogeneous AI capability resources originally belonging to business gateways and operation gateways are incorporated into a versioned and event-based registration management system. A directed dependency graph starting from the Agent and a corresponding reverse index are constructed using explicit dependency declaration parsing. This allows for precise identification of the affected scope and incremental updates when resources change, generating immutable candidate resource views. The switching of the active view is then completed through ready state verification and atomic comparison and exchange operations driven by dependency strength and version constraints. Finally, during the business gateway admission phase, access control with a blocking priority is implemented based on the view information. This is supplemented by event flow monotonic sequence number verification, revocation barrier, reference counting, and audit recovery mechanisms, forming a closed-loop consistency maintenance scheme from pre-declaration, in-process incremental verification to post-event security convergence.

[0031] To provide a basis for understanding and implementing the technical solution of this invention, the key data objects and terms involved in this specific embodiment are uniformly explained below.

[0032] In this invention, there are only two authoritative domains for domain-based registration: the business registration domain and the runtime registration domain. An event stream is an ordered partition of events within each registration domain. The business domain uses `basic.agent_route` to carry Agent business status and Route configuration events; the runtime domain uses `runtime.agent`, `runtime.mcp`, and `runtime.skill`. The consistency watermark vector is a vector composed of processed cursors from each event stream, with a format such as `{basic.agent_route:47,runtime.skill:81,runtime.mcp:82,runtime.agent:83}`. Resource versions can be monotonically increasing integers, semantic versions, or content summaries; `updated_at` is only used for display and auxiliary diagnosis and does not participate in any consistency determination logic.

[0033] The ResourceDescriptor is a unified structure for expressing various heterogeneous AI capability resources, containing the following fields: domain_id, event_stream, resource_type, resource_id, resource_version, content_digest, registration_status, health_state, approval_state, change_seq, and tombstone. The DependencyEdge contains the following fields: agent_id, target_ref, edge_type, requirement_level, version_constraint, capability_predicate, and fallback_group. The edge_type only describes the association semantics and can be BINDS_RESOURCE, PROVIDED_BY, AUTHORIZED_BY, ROUTED_TO, or RUNS_ON. The requirement_level can be either REQUIRED or OPTIONAL, and the two cannot be substituted for each other. The AgentRuntimeSnapshot contains the following fields: agent_id, snapshot_version, base_watermark, graph_root_hash, resolved_resources[], permission_digest, route_digest, policy_epoch, readiness, reason_codes[], and state, where state can be BUILDING, VALIDATED, ACTIVE, RETIRING, RETIRED, REJECTED, or REVOKED. The ResourceChangeEvent contains the following fields: event_id, domain_id, event_stream, change_seq, resource_ref, old_version, new_version, change_kind, and severity, where severity can be NORMAL_UPDATE, COMPATIBILITY_BREAK, or SECURITY_REVOCATION.

[0034] Resource symbols are uniformly defined as follows: A represents Agent, M represents MCP server, T represents MCP tool, S represents Skill runtime resource, R represents Route, P represents Permission, and E represents ExecutionEnvironment. Tools use the format "T1(search_order)@t10", where T1 is an immutable tool resource identifier, search_order is the tool name, and t10 is the tool architecture version. `policy_epoch` is the version of the monotonic policy set participating in the snapshot summary, increasing as health thresholds, degradation rules, reversal rules, and runtime environment constraints change. In `severity`, `NORMAL_UPDATE` is processed as a normal increment, `COMPATIBILITY_BREAK` increases recalculation priority, and `SECURITY_REVOCATION` immediately establishes a reversal barrier.

[0035] Please refer to Figure 1 As shown, a preferred embodiment of the method for maintaining consistency of heterogeneous AI capability resources in a two-layer gateway according to the present invention includes the following steps: Step S1: Using the Agent identifier as the cross-gateway association anchor point, in the registration domains corresponding to the business gateway and the operation gateway in the two-layer gateway, the heterogeneous AI capability resources on which the Agent depends are registered in separate domains, with the Agent corresponding to the Agent identifier as the unit, and a registration record containing resource identifier and version information is generated for each heterogeneous AI capability resource. Step S2: Obtain the dependency declaration of the Agent, and parse the dependency declaration into the dependency relationship between the Agent and each of the heterogeneous AI capability resources. The dependency relationship includes dependency strength information and version constraint information. After obtaining the Agent's dependency declarations, this step first normalizes them. An Agent's dependency declaration must at least specify the target resource, whether the dependency is required or optional, the allowed version range, the capability predicate, and the optional fallback group. For dependency declarations involving MCP access groups and toolsets, the access group needs to be expanded into specific MCP servers, and the toolset into specific tools, before establishing the dependency relationship. For Skill dependencies, the Skill runtime resource identifier and the descriptive skills field in the AgentCard need to be processed separately. The former is included in the dependency graph as an actual dependency, while the latter is only descriptive information and not included in dependency constraints.

[0036] When the dependency strength information is not explicitly declared in the dependency declaration (i.e., it is not specified whether it is REQUIRED or OPTIONAL), it will be defaulted to REQUIRED (required dependency) according to the security policy, or it will be set to PENDING (pending confirmation) status for manual confirmation, so as to avoid the loss of silent capability due to incomplete information.

[0037] Version constraint information can be represented in various ways, such as precise version (e.g., S1@3), semantic version range (e.g., [3,5)), content digest whitelist, or capability predicate. The parsed content digest, permission digest, and route digest all participate in the calculation of the unique identifier (e.g., graph_root_hash) of the candidate resource view.

[0038] Step S3: Based on the dependency relationship obtained by parsing, construct a directed dependency graph with the Agent as the starting point and each of the heterogeneous AI capability resources as nodes, and establish a reverse index from each of the heterogeneous AI capability resources to the Agent that depends on the resource. Step S4: When the heterogeneous AI capability resources in any registered domain change, determine the set of Agents affected by the change based on the reverse index, perform incremental update processing on the subgraph of the directed dependency graph corresponding to each Agent in the Agent set, and generate a candidate resource view; Step S5: Based on the dependency strength information and version constraint information of the dependency relationship, verify the readiness status of each heterogeneous AI capability resource that the Agent depends on in the candidate resource view, and obtain the readiness determination result of the candidate resource view. Step S6: When the readiness determination result meets the preset conditions, the Agent's current active resource view is atomically switched to the candidate resource view; Step S7: During the request admission phase of the business gateway, obtain the current activity resource view information of the Agent, and perform admission control on the request based on the activity resource view information.

[0039] In step S1, the heterogeneous AI capability resources include at least one of Agent business resources, Agent operation resources, Model Context Protocol server resources, Model Context Protocol tool resources, Skill operation resources, Routing resources, Permission resources, and Operation environment resources. The business gateway is the authoritative domain for registering Agent business resources and routing resources, and the runtime gateway is the authoritative domain for registering Agent runtime resources, Model Context Protocol server resources, Model Context Protocol tool resources, Skill runtime resources, Permission resources and runtime environment resources. Each of the registered domains sets up an event stream according to the resource category, and assigns a monotonic change sequence number to the addition, modification and deletion of the heterogeneous AI capability resources within the event stream. The deletion operation is marked with a tombstone. The registration record also includes the change sequence number and event stream attribution information.

[0040] In this invention, the registration domain is configured with event flows based on resource categories, with the business gateway and the runtime gateway serving as the authoritative domains for different resource types. The authoritative domain affiliation, version triggering conditions, and prohibited cross-domain copying rules for each resource type are shown in the table below:

[0041] Each registration domain can set up an event stream under each resource category, and within that event stream, assign a monotonically increasing change_seq for the addition, modification, and deletion of heterogeneous AI capability resources. Deletion operations are marked with tombstones to prevent out-of-order replay from mistakenly reviving deleted resources. In addition to resource identifiers and version information, each registration record also contains change_seq and event stream attribution information, enabling each resource change event to be uniquely identified and systematically located globally.

[0042] In step S1, Agent business resources (such as tenant team affiliation, authorization activation status, service address, and route references) are registered on the business gateway, while Agent runtime resources (such as AgentCard, runtime parameters, and object permission references) are registered on the runtime gateway. MCP servers and tools, Skill packages and runtime environments, Permission resources, and ExecutionEnvironment resources are also registered on the runtime gateway, while Route resources are registered on the business gateway. Both registration domains use a non-reassignable agent_id as the cross-gateway association anchor for the same Agent.

[0043] In step S2, the dependency strength information includes required or optional dependencies; the access group dependencies and toolset dependencies in the dependency declaration are expanded into specific server dependencies and specific tool dependencies; heterogeneous AI capability resources that do not explicitly declare the dependency strength information are defaulted to required dependencies or set to a pending confirmation state according to the security policy. The version constraint information is represented by at least one of the following methods: precise version, semantic version range, content summary whitelist, or capability predicate; the content summary, permission summary, and routing summary of each heterogeneous AI capability resource participate in the unique identifier calculation of the candidate resource view.

[0044] In step S3, the node types in the directed dependency graph include at least Agent nodes, Model Context Protocol server nodes, Model Context Protocol tool nodes, skill nodes, routing nodes, permission nodes, and runtime environment nodes; the dependency relationship is determined by at least one of direct reference, access group resolution, toolset resolution, or capability predicate matching, and the dependency relationship obtained by indirect resolution is solidified as an edge carrying source proof.

[0045] A directed dependency graph must contain at least the following node types: Agent node (A), MCP server node (M), MCP tool node (T), Skill node (S), Route node (R), Permission node (P), and ExecutionEnvironment node (E). Dependencies can be determined in several ways: direct referencing (resolving directly by immutable IDs), access group resolution (expanding access groups into specific servers), toolset resolution (expanding toolsets into specific tools), or capability predicate matching. For dependencies obtained through indirect resolution, they must be solidified into concrete edges carrying proof of origin, i.e., recording the resolution path and source of the dependency to ensure the traceability of the dependency graph.

[0046] Let the dependency graph be G=(V,E). Establish a reverse adjacency function pred(v) pointing from each heterogeneous AI capability resource node to the Agent nodes that depend on that resource. The specific data structure of this reverse index is a set of all Agent identifiers that depend on the resource, with resource_ref as the key. Based on this reverse index, when a resource changes, the set of affected Agents can be calculated based on the set of changed resource nodes ΔV. Affected(ΔV) = {a ∈ V_agent | ∃v ∈ ΔV, there exists a dependency path from a to v} =reverse_closure(ΔV)∩V_agent In step S4, before the incremental update processing, there is also a step of verifying the resource change event: Acquire resource change events, wherein the resource change event includes an idempotency identifier, the domain to which it belongs, the event stream, the change sequence number, and the resource identifier; If the change sequence number is equal to the current event stream cursor plus one, then in the same transaction, write the new version or tombstone marker of the heterogeneous AI capability resource, advance the event stream cursor, persist the affected Agent set, and write the task to be recalculated or the transaction outer box record; after the transaction is committed, deliver the task to be recalculated; when the system restarts, scan and continue to process the unfinished task to be recalculated or the transaction outer box record. If the change sequence number is less than or equal to the current cursor, then the resource change event is ignored; If the change sequence number is greater than the current cursor plus one, the out-of-order resource change event will not be applied, the corresponding event flow cursor and consistency level will not be advanced, the affected Agent determined based on the resource identifier carried by the out-of-order resource change event and the existing reverse index will be marked as pending, and the corresponding candidate resource view will remain in a pending state. At the same time, missing events will be filled in. After the missing events are filled in, the set of affected Agents and the reverse impact closure will be recalculated based on the complete event sequence, and then the resource change events will be applied in sequence and the event flow cursor and consistency level will be advanced.

[0047] This step performs rigorous validation of resource change events before incremental update processing to prevent consistency issues caused by event duplication, out-of-order delivery, and gaps. Resource change events include information such as an idempotent identifier (event_id), the domain (domain_id), the event stream (event_stream), the change sequence number (change_seq), and the resource identifier (resource_ref).

[0048] The coordinator maintains a cursor for each (domain_id, event_stream) representing the maximum change sequence number that has been applied to that event stream. Upon receiving a resource change event, the following validation logic is executed: 1. If the event_id has already been applied, it is determined to be DUPLICATE_IGNORED and is ignored directly; 2. If change_seq is less than or equal to the current cursor, it is determined to be STALE_OR_DUPLICATE and is ignored directly; 3. If change_seq equals the current cursor plus one, then apply the event and advance the cursor atomically; 4. If change_seq is greater than the current cursor plus one, it indicates that there is an event gap (EVENT_GAP). At this time, the affected Agent is marked as pending (PENDING), and the missing event sequence (from cursor+1 to change_seq-1) is requested to be filled. Out-of-order events cannot be applied directly before the gap is filled.

[0049] The pseudocode representation of the above verification logic is as follows: on_resource_change(event): if event.event_id already_applied: return DUPLICATE_IGNORED cursor = stream_cursor[event.domain_id, event.event_stream] impacted = reverse_closure(event.resource_ref) if event.change_seq <= cursor: return STALE_OR_DUPLICATE if event.change_seq > cursor + 1: mark_impacted_agents(PENDING, EVENT_GAP) request_missing_range(cursor + 1, event.change_seq - 1) return GAP_WAIT apply_event_and_advance_cursor_atomically(event) enqueue_rebuild(impacted, event.change_seq, event.severity) After verification, the set of Agents affected by the change is determined based on the inverted index, and the dependency subgraph corresponding to each Agent in the set is incrementally recalculated. The candidate resource view candidate_graph(a) is generated by reading resource descriptors at the event stream sequence number boundaries specified by base_watermark, and writing the parsed resources (MCP server, tools and their schema_version, Skill version, permission digest, route digest, and policy epoch) into an immutable candidate snapshot. candidate_graph(a)=normalize(resolve(declaration(a),registry_at(base_watermark))) The graph_root_hash is calculated as follows: graph_root_hash=H(Canon(sorted(nodes))||Canon(sorted(edges))|| permission_digest||route_digest||policy_epoch) The severity of an event affects the priority of incremental update processing: When the change type is NORMAL_UPDATE (normal update), it is processed in the normal incremental order; When the change type is COMPATIBILITY_BREAK, increase the recalculation priority of the affected Agent; When the change type is SECURITY_REVOCATION, a revocation barrier is immediately established, marking all resource views containing the revoked resource as REVOKED, preventing new requests from fixing the revoked resource view, and canceling, isolating, or restricting any pending requests that have fixed the resource view according to the revocation policy.

[0050] In step S4, the types of changes to the heterogeneous AI capability resources include normal updates, compatibility violations, and security reversals. When the change of the heterogeneous AI capability resource is to be safely revoked, an revocation barrier is immediately established, the resource view containing the revoked resource is marked as revoked, new requests are prevented from fixing the revoked resource view, and in-transit requests that have fixed the resource view are processed in accordance with the revocation policy. When changes to the heterogeneous AI capability resources result in compatibility breaches, the incremental update processing priority of the affected Agents is increased.

[0051] In step S5, the readiness verification includes verifying at least one of the following: the existence of heterogeneous AI capability resources, version matching, content summary, approval status, authorization status, health status, tool structure compatibility, routing configuration integrity, and runtime environment compatibility. The readiness determination result includes a ready state, a downgraded state, a blocked state, and a pending state. Specifically, a blocked state is determined when any required dependency verification fails; a downgraded state is determined when only optional dependency verification fails and the downgrade strategy allows it; and a pending state is determined when verification is incomplete or when data gaps exist. The priority of the ready state, degraded state, blocked state, and pending state is as follows: blocked state is higher than pending state, pending state is higher than degraded state, and degraded state is higher than ready state. Service activation state and route reachability are calculated independently during the admission phase of the service gateway and are not mixed into the ready determination result.

[0052] In this step, the dependency readiness determination of the candidate resource view does not reuse the Agent's ONLINE / OFFLINE status, but instead performs independent multi-dimensional verification. Verification items include the existence (including tombstone checking) of heterogeneous AI capability resources, version matching, content digest consistency, approval status, authorization status, health status, tool structure compatibility, routing configuration integrity, and runtime environment compatibility. The definition of the ready(e,r) predicate is: ready(e,r)=exists(r)∧¬r.tombstone∧version_ok(e,r) ∧digest_verified(r)∧approved(r)∧authorized(e,r) ∧health_ok(e,r)∧route_config_ok(e,r)∧runtime_compatible(r) The table below shows the behavior and typical reason codes for each check item when verification fails:

[0053] Based on the above verification, the readiness determination logic for readiness(a) is as follows: readiness(a) = BLOCKED if any confirmed required edge fails PENDING if no blocker and watermark / verification incomplete DEGRADED if required edges pass and optional edge fails READY otherwise Specifically, a blocked state (BLOCKED) is determined when any required dependency verification fails; a degraded state (DEGRADED) is determined when optional dependency verification fails but the degradation strategy allows it; a pending state (PENDING) is determined when verification is incomplete or there is an event gap; and a ready state (READY) is determined when all verifications pass. When multiple conditions coexist, the priority is BLOCKED > PENDING > DEGRADED > READY. `effective_runnable` is calculated independently by the business gateway during the admission phase and is not mixed into the dependency ready state. effective_runnable=business_enabled∧route_reachable ∧readiness∈{READY,policy_allowed(DEGRADED)} ∧active_snapshot.state=ACTIVE In step S6, the candidate resource view is constructed as an immutable object, which includes view version, consistency watermark vector, resource list and policy version information; If a change in the version or strategy version of a related heterogeneous AI capability resource is detected during the verification process, the current candidate resource view will be invalidated and reconstructed. The preset conditions include at least the readiness determination result being either a ready state or a downgraded state allowed by the policy; if the readiness determination result is a blocking state, then the candidate resource view is refused activation; when it is confirmed that a necessary dependency has failed, the running gateway updates the readiness projection of the current active resource view of the corresponding Agent to a blocking state, and the business gateway blocks new requests according to the blocking state; when the change type of the heterogeneous AI capability resource is security revocation, a revocation barrier is further set, and the resource view containing the revoked resource is marked as revocation state; The atomic switching is achieved through a comparison-swap operation, the conditions of which include at least that the current active resource view version is consistent with the expected version and the consistency level has not changed; if the comparison-swap operation fails, the incremental update process and candidate resource view generation are re-executed.

[0054] The candidate resource view, AgentRuntimeSnapshot, is constructed as an immutable object containing fields such as snapshot_version, base_watermark, graph_root_hash, resolved_resources[], permission_digest, route_digest, and policy_epoch. During candidate snapshot verification, if any related event stream cursor or policy_epoch changes, the current candidate snapshot is invalidated and reconstructed.

[0055] An atomic switch operation is performed when the candidate snapshot's state is VALIDATED and its readiness is READY or DEGRADED as allowed by the policy. The atomic switch is implemented through a compare-and-swap (CAS) operation. CAS(agent_id,expected_active=v_old,validated_candidate=v_new, expected_watermark,policy_epoch) The conditions for CAS (Compare-and-Swap) include: the current active resource view version is consistent with the expected version, the base_watermark has not expired, and the policy_epoch has not changed. After a successful switch, the active pointer moves from the old snapshot to the new snapshot in one go. If CAS fails, it indicates concurrent updates, requiring re-execution of incremental update processing and candidate resource view generation. If the candidate snapshot's readiness = BLOCKED, its state is set to REJECTED and a blocking state is issued, preventing activation.

[0056] In step S7, before and after the switch, admitted in-transit requests continue to use the old active resource view fixed before the switch, and new requests after the switch use the new active resource view after the switch; the resource list of the candidate resource view is fixed with the actual hit resource version or content summary; before the lease or reference count of any resource view referencing the corresponding resource version reaches zero and the reclamation condition is met, the corresponding resource version is retained, and it is ensured that resources can be located according to the resource version or content summary; The in-transit request holds a lease or reference count for the old active resource view. When the reference count reaches zero and the reclamation conditions are met, the old active resource view is reclaimed. The access control specifically includes: Obtain a readiness receipt containing the view version, readiness determination result, and consistency watermark vector from the running gateway; The service gateway verifies the readiness receipt and calculates the final admission decision result by combining the service activation status and route reachability of the Agent; When the readiness receipt verification fails or the readiness determination result is blocking, the final admission determination result is blocking; when the readiness receipt expires or there are data gaps, the final admission determination result is pending; blocking takes precedence over pending.

[0057] During the request admission phase of the business gateway, a readiness receipt is first obtained from the running gateway. This receipt contains information such as agent_id, snapshot_version, graph_root_hash, readiness, reason_codes, base_watermark, and validity period. Upon receiving the readiness receipt, the business gateway verifies it. If verification is successful, the final admission decision is calculated based on the agent's business-enabled status (business_enabled) and route reachability (route_reachable). The admission decision follows these rules: When the readiness receipt verification fails, or the readiness determination result is BLOCKED, the final determination is blocking; When a ready receipt expires, or there is an event gap, or the verification is not completed, it is ultimately determined to be PENDING. Blocked states take precedence over pending states.

[0058] Before and after a snapshot switch, admitted requests in transit continue to use the old active resource view that was fixed before the switch, while new requests after the switch use the new active resource view after the switch. Specifically, the business gateway obtains the snapshot_version of the activity during admission and passes it to the running gateway along with the request; the running gateway atomically increments the lease or reference count of the snapshot, and the entire execution process can only parse the MCP and Skill from this snapshot. After the new snapshot is activated, the old snapshot changes from ACTIVE to RETIRING; old requests continue to use the old version until the lease is released after completion, timeout, or cancellation; when the reference count reaches zero and exceeds the retention window, the old snapshot changes to RETIRED and is reclaimed.

[0059] The method further includes: Step S8: Record resource change events, dependency graph change summaries, candidate resource view verification results, atomic switch results, and ready receipts as audit evidence; When the system restarts, it restores the running state from the currently active resource view, each event stream cursor, and unfinished events; When the same view identifier is generated due to repeated event processing, the existing candidate resource view is reused.

[0060] The system records resource change events, dependency graph change summaries, candidate resource view verification results, CAS switching results, snapshot leases, and ready receipts as audit evidence, but does not save plaintext MCP credentials or Skill file text. Upon system restart, the system resumes operation from the currently active resource view pointer, event stream cursors, and incomplete events. When the same graph_root_hash is generated due to duplicate event processing, existing candidate resource views can be reused to avoid redundant calculations.

[0061] To more clearly illustrate the technical effects of the present invention, a typical embodiment is given below: Assume Agent A's current activity snapshot is v12, and it depends on Route R1, tool T1 (search_order) in MCP server M1, and Skill S1@3, where the requirement_level of R1, M1, T1, and S1 is all REQUIRED. The business gateway displays A as ONLINE, and the v12 ready status of the running gateway is READY.

[0062] The administrator upgrades S1 to v4 and changes the schema_version of T1(search_order) from t9 to t10, creating runtime.skill stream change_seq=81 and runtime.mcp stream change_seq=82 respectively. The coordinator selects the set of Agents that depend on S1 or T1 based on the inverted index, with A entering recalculation. The parser constructs a candidate snapshot v13 on base_watermark={basic.agent_route:47,runtime.skill:81,runtime.mcp:82,runtime.agent:82}, finding that S1@4 satisfies the version range [3,5), but the new input structure of T1(search_order)@t10 is incompatible with the capability predicate declared by A. Therefore, v13 has readiness=BLOCKED, state=REJECTED, and the activity pointer still points to v12. Because the event severity is COMPATIBILITY_BREAK instead of SECURITY_REVOCATION, the in-transit request Q1 for fixed v12 can continue to complete.

[0063] The administrator then updates the tool constraints of A, resulting in a runtime.agent flow change_seq=83. The coordinator recalculates candidate snapshot v14 on base_watermark={basic.agent_route:47,runtime.skill:81,runtime.mcp:82,runtime.agent:83}, all necessary dependencies pass, and graph_root_hash=h14. CAS checks that the current active version is still v12 and the watermark vector has not changed, atomically switching to v14 while setting v12 to RETIRING. Before the switch, request Q1 continues to use S1@3 and T1(search_order)@t9; after the switch, request Q2 only uses S1@4 and T1(search_order)@t10. If M1 subsequently experiences SECURITY_REVOCATION, a reversal barrier is established, and the snapshot containing M1 is marked as REVOKED.

[0064] The event sequence and request processing status of the above process are shown in the table below:

[0065] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for maintaining consistency of heterogeneous AI capability resources in a two-layer gateway, characterized in that, Includes the following steps: Step S1: Using the Agent identifier as the cross-gateway association anchor point, in the registration domains corresponding to the business gateway and the operation gateway in the two-layer gateway, the heterogeneous AI capability resources on which the Agent depends are registered in separate domains, with the Agent corresponding to the Agent identifier as the unit, and a registration record containing resource identifier and version information is generated for each heterogeneous AI capability resource. Step S2: Obtain the dependency declaration of the Agent, and parse the dependency declaration into the dependency relationship between the Agent and each of the heterogeneous AI capability resources. The dependency relationship includes dependency strength information and version constraint information. Step S3: Based on the dependency relationship obtained by parsing, construct a directed dependency graph with the Agent as the starting point and each of the heterogeneous AI capability resources as nodes, and establish a reverse index from each of the heterogeneous AI capability resources to the Agent that depends on the resource. Step S4: When the heterogeneous AI capability resources in any registered domain change, determine the set of Agents affected by the change based on the reverse index, perform incremental update processing on the subgraph of the directed dependency graph corresponding to each Agent in the Agent set, and generate a candidate resource view; Step S5: Based on the dependency strength information and version constraint information of the dependency relationship, verify the readiness status of each heterogeneous AI capability resource that the Agent depends on in the candidate resource view, and obtain the readiness determination result of the candidate resource view. Step S6: When the readiness determination result meets the preset conditions, the Agent's current active resource view is atomically switched to the candidate resource view; Step S7: During the request admission phase of the business gateway, obtain the current activity resource view information of the Agent, and perform admission control on the request based on the activity resource view information.

2. The method according to claim 1, characterized in that, In step S1, the heterogeneous AI capability resources include at least one of Agent business resources, Agent operation resources, Model Context Protocol server resources, Model Context Protocol tool resources, Skill operation resources, Routing resources, Permission resources, and Operation environment resources. The business gateway is the authoritative domain for registering Agent business resources and routing resources, and the runtime gateway is the authoritative domain for registering Agent runtime resources, Model Context Protocol server resources, Model Context Protocol tool resources, Skill runtime resources, Permission resources and runtime environment resources. Each of the registered domains sets up an event stream according to the resource category, and assigns a monotonic change sequence number to the addition, modification and deletion of the heterogeneous AI capability resources within the event stream. The deletion operation is marked with a tombstone. The registration record also includes the change sequence number and event stream attribution information.

3. The method according to claim 1, characterized in that, In step S2, the dependency strength information includes required or optional dependencies; the access group dependencies and toolset dependencies in the dependency declaration are expanded into specific server dependencies and specific tool dependencies; heterogeneous AI capability resources that do not explicitly declare the dependency strength information are defaulted to required dependencies or set to a pending confirmation state according to the security policy. The version constraint information is represented in at least one of the following ways: precise version, semantic version range, content summary whitelist, or capability predicate; the content summary, permission summary, and routing summary of each heterogeneous AI capability resource participate in the unique identifier calculation of the candidate resource view.

4. The method according to claim 1, characterized in that, In step S3, the node types in the directed dependency graph include at least Agent nodes, Model Context Protocol server nodes, Model Context Protocol tool nodes, skill nodes, routing nodes, permission nodes, and runtime environment nodes; the dependency relationship is determined by at least one of direct reference, access group resolution, toolset resolution, or capability predicate matching, and the dependency relationship obtained by indirect resolution is solidified as an edge carrying source proof.

5. The method according to claim 2, characterized in that, In step S4, before the incremental update processing, there is also a step of verifying the resource change event: Acquire resource change events, wherein the resource change event includes an idempotency identifier, the domain to which it belongs, the event stream, the change sequence number, and the resource identifier; If the change sequence number is equal to the current event stream cursor plus one, then in the same transaction, write the new version or tombstone marker of the heterogeneous AI capability resource, advance the event stream cursor, persist the affected Agent set, and write the task to be recalculated or the transaction outer box record; after the transaction is committed, deliver the task to be recalculated; when the system restarts, scan and continue to process the unfinished task to be recalculated or the transaction outer box record. If the change sequence number is less than or equal to the current cursor, then the resource change event is ignored; If the change sequence number is greater than the current cursor plus one, the out-of-order resource change event will not be applied, the corresponding event flow cursor and consistency level will not be advanced, the affected Agent determined based on the resource identifier carried by the out-of-order resource change event and the existing reverse index will be marked as pending, and the corresponding candidate resource view will remain in a pending state. At the same time, missing events will be filled in. After the missing events are filled in, the set of affected Agents and the reverse impact closure will be recalculated based on the complete event sequence, and then the resource change events will be applied in sequence and the event flow cursor and consistency level will be advanced.

6. The method according to claim 1, characterized in that, In step S4, the types of changes to the heterogeneous AI capability resources include normal updates, compatibility violations, and security reversals. When the change of the heterogeneous AI capability resource is to be safely revoked, an revocation barrier is immediately established, the resource view containing the revoked resource is marked as revoked, new requests are prevented from fixing the revoked resource view, and in-transit requests that have fixed the resource view are processed in accordance with the revocation policy. When changes to the heterogeneous AI capability resources result in compatibility breaches, the incremental update processing priority of the affected Agents is increased.

7. The method according to claim 1, characterized in that, In step S5, the readiness verification includes verifying at least one of the following: the existence of heterogeneous AI capability resources, version matching, content summary, approval status, authorization status, health status, tool structure compatibility, routing configuration integrity, and runtime environment compatibility. The readiness determination result includes a ready state, a downgraded state, a blocked state, and a pending state. Specifically, a blocked state is determined when any required dependency verification fails; a downgraded state is determined when only optional dependency verification fails and the downgrade strategy allows it; and a pending state is determined when verification is incomplete or when data gaps exist. The priority of the ready state, degraded state, blocked state, and pending state is as follows: blocked state is higher than pending state, pending state is higher than degraded state, and degraded state is higher than ready state. Service activation state and route reachability are calculated independently during the admission phase of the service gateway and are not mixed into the ready determination result.

8. The method according to claim 1, characterized in that, In step S6, the candidate resource view is constructed as an immutable object, which includes view version, consistency watermark vector, resource list and policy version information; If a change in the version or strategy version of a related heterogeneous AI capability resource is detected during the verification process, the current candidate resource view will be invalidated and reconstructed. The preset conditions include at least the readiness determination result being either a ready state or a downgraded state allowed by the policy; If the readiness determination result is a blocked state, then the candidate resource view is not activated; When it is confirmed that a necessary dependency has failed, the running gateway updates the ready projection of the current active resource view of the corresponding Agent to the blocked state, and the business gateway blocks new requests according to the blocked state; when the change type of the heterogeneous AI capability resource is security revocation, a revocation barrier is further set, and the resource view containing the revoked resource is marked as revocation state. The atomic switching is achieved through a comparison-swap operation, the conditions of which include at least that the current active resource view version is consistent with the expected version and the consistency level has not changed; if the comparison-swap operation fails, the incremental update process and candidate resource view generation are re-executed.

9. The method according to claim 1, characterized in that, In step S7, before and after the switch, the admitted in-transit requests continue to use the old active resource view that was fixed before the switch, and the new requests after the switch use the new active resource view after the switch. The resource list of the candidate resource view is fixed with the actual hit resource version or content summary; the corresponding resource version is retained until the lease or reference count of any resource view referencing the corresponding resource version reaches zero and the reclamation condition is met, and the resource can be located according to the resource version or content summary. The in-transit request holds a lease or reference count for the old active resource view. When the reference count reaches zero and the reclamation conditions are met, the old active resource view is reclaimed. The access control specifically includes: Obtain a readiness receipt containing the view version, readiness determination result, and consistency watermark vector from the running gateway; The service gateway verifies the readiness receipt and calculates the final admission decision result by combining the service activation status and route reachability of the Agent; When the readiness receipt verification fails or the readiness determination result is blocking, the final admission determination result is blocking; when the readiness receipt expires or there are data gaps, the final admission determination result is pending; blocking takes precedence over pending.

10. The method according to claim 1, characterized in that, The method further includes: Step S8: Record resource change events, dependency graph change summaries, candidate resource view verification results, atomic switch results, and ready receipts as audit evidence; When the system restarts, it restores the running state from the currently active resource view, each event stream cursor, and unfinished events; When the same view identifier is generated due to repeated event processing, the existing candidate resource view is reused.

Images