A multi-agent system oriented capability management and calling method

Abstract

The application provides a multi-agent system-oriented capability management and calling method. The method constructs a hierarchical capability ontology definition multi-dimensional attribute space, converts the agent capability declaration into a structured attribute vector, maps the attribute vector to a fixed-length fingerprint vector through grouping normalization, weighted scaling and random projection, and normalizes it to a unit hypersphere. Based on the fingerprint vector, multiple independent hash indexes are constructed. When receiving a calling request, the request is converted into a query fingerprint, and after the candidate set is obtained through the multi-group hash index coarse screening, the matching result is generated by performing fine arrangement reasoning. According to the calling feedback, the dimension weight vector is updated to realize the adaptive improvement of the matching accuracy. The method reduces the capability matching delay from linear to sub-linear, eliminates the semantic ambiguity of the text description, and supports the constant-time hot plug of the agent.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, specifically to a method for capability management and invocation in multi-agent systems. Background Technology

[0002] With the development of artificial intelligence technology, multi-agent collaborative systems are widely used in fields such as natural language processing, data analysis, and code generation. In such systems, capability discovery and invocation are the core elements for achieving efficient collaboration among agents. Existing technologies typically employ capability description methods based on natural language text or key-value pairs, combined with centralized registry entries and full-text search mechanisms for capability discovery.

[0003] However, this approach faces three technical challenges when dealing with hundreds of agents and thousands of capability entries: First, capability discovery based on text semantic matching requires traversing the registry entry by entry, and the latency of a single match increases linearly with the number of capability entries, failing to meet the low-latency requirements of real-time collaboration scenarios. Second, natural language capability descriptions suffer from ambiguity due to synonymy and heterogeneity, and differences in descriptions of the same capability by different agents limit the matching recall rate. Third, the dynamic online and offline status of agents requires rebuilding the index, and the incremental update cost of traditional inverted indexes is proportional to the index size, making it unsuitable for the runtime requirements of high-frequency hot-swapping. Summary of the Invention

[0004] To address the shortcomings of existing technologies, such as the linear increase in capability discovery latency with scale based on text semantic matching, the limitation of matching recall due to synonymous and heterogeneous ambiguities in natural language capability descriptions, and the proportionality of index reconstruction costs to scale when agents dynamically go online and offline, this application provides a capability management and invocation method for multi-agent systems. This method transforms agent capability declarations into structured attribute vectors and maps them to fixed-length fingerprint vectors through weighted projection. Multiple independent indices based on locality-sensitive hashing are then constructed on the fingerprint vector space to achieve sublinear-time capability matching inference. This reduces the matching latency from a linear relationship with the number of capability entries to a sublinear relationship while maintaining matching accuracy, eliminates semantic ambiguity in text descriptions, and supports constant-time hot-plugging of agents. Specifically, this application provides the following technical solutions:

[0005] This application provides a method for capability management and invocation in multi-agent systems, including:

[0006] Construct a hierarchical capability ontology, define a multi-dimensional attribute space, specify the attribute type, value range and encoding function for each attribute dimension, and generate the capability ontology definition;

[0007] Receive capability declaration information submitted by the intelligent agent, perform structured verification on the capability declaration information according to the capability ontology definition, and generate a structured capability declaration record containing attribute vectors after the verification is passed;

[0008] The attribute vector is grouped and normalized to eliminate the difference in dimensions. The normalized vector and the dimension weight vector are then weighted and scaled dimension by dimension. The weighted vector is mapped to a fixed-length fingerprint vector through a random projection matrix. The fingerprint vector is then normalized to a unit hypersphere.

[0009] Based on the fingerprint vector, multiple independent hash indexes are constructed. Each hash index uses an independent family of random hyperplanes to divide the fingerprint vector space, and each fingerprint vector is mapped to a corresponding hash bucket.

[0010] When a call request is received, the call request is transformed into a query fingerprint in the same space as the fingerprint vector. A coarse screening is performed through the multiple sets of independent hash indexes to obtain a set of candidate capabilities. Fine ranking and reasoning are performed on each candidate in the set of candidate capabilities to generate a list of matching results.

[0011] The dimension weight vector is updated based on the call feedback information in the matching result list.

[0012] Optionally, the grouping normalization involves grouping the attribute vectors according to the ontology dimension, and performing L2 normalization on each group of encoded sub-vectors to make the contribution of each ontology dimension to the final vector equal.

[0013] Optionally, the random projection matrix is ​​a Gaussian random projection matrix, in which each element is independently sampled from a Gaussian distribution with a mean of zero and a variance equal to the reciprocal of the target dimension. The random projection matrix is ​​generated and fixed once during system initialization, and all agents share the same matrix. After projection, the fingerprint vector is L2 normalized to a unit hypersphere, such that the inner product of two fingerprint vectors is equal to the cosine similarity.

[0014] Optionally, the dimension of the fixed-length fingerprint vector is bounded by the Johnson-Lindenstrauss lemma, which is proportional to the logarithm of the effective degrees of freedom in the capability vector set and inversely proportional to the square of the distance preservation error tolerance.

[0015] Optionally, each hash function in the random hyperplane family generates a one-bit binary code by calculating the inner product sign of the fingerprint vector and the random hyperplane normal vector, and multiple hash functions in each hash index are combined to generate a multi-bit hash code as the bucket address.

[0016] Optionally, the multiple independent hash indexes support incremental updates. When an agent comes online, its fingerprint vector is inserted into the corresponding bucket of each hash index. When an agent goes offline, its fingerprint vector is deleted from the corresponding bucket of each hash index. The time complexity of a single incremental update is linearly related to the number of hash index groups.

[0017] Optionally, the fine-ranking inference includes: calculating the cosine similarity between the query fingerprint and each candidate fingerprint vector as a similarity component; calculating the proportion of constraint satisfaction in the call request as a constraint satisfaction component; obtaining the real-time load status of each candidate agent as an availability component; and weighting and summing the similarity component, the constraint satisfaction component, and the availability component to obtain a comprehensive score.

[0018] Optionally, before performing the fine-ranking inference, gating filtering is performed on the candidate capability set to discard candidates with negative cosine similarity and candidates with zero constraint satisfaction.

[0019] Optionally, the process of converting the call request into a query fingerprint includes two mutually exclusive modes: when the call request is submitted in a structured format, field mapping is directly performed according to the ontology dimension to generate a requirement attribute vector; when the call request is submitted in a semi-structured format, slot filling and structured constraints are injected into the task description based on the ontology dimension keyword dictionary to generate a requirement attribute vector.

[0020] Optionally, the dimensions that do not match the keywords in the slot filling are marked as wildcard dimensions. The method further includes calculating the proportion of wildcard dimensions. When the proportion of wildcard dimensions exceeds a preset threshold, the weights of all wildcard dimensions are temporarily set to zero. The weights of the remaining specified dimensions are renormalized and then fingerprinting and matching are performed.

[0021] Optionally, updating the dimension weight vector based on the call feedback information includes: aggregating the success status, response latency, and user satisfaction score in the call result into a single reward signal, updating the contribution index of each ontology dimension using an exponentially weighted moving average algorithm, and normalizing the updated contribution index to generate a new dimension weight vector.

[0022] Optionally, the update of the dimension weight vector further includes: performing a pruning constraint on the magnitude of a single weight adjustment, and then renormalizing the weight vector after pruning to satisfy the constraint that the sum of the weights of each dimension is equal to one.

[0023] Optionally, the method further includes: adaptively adjusting the matching threshold based on the call feedback information in the matching result list, wherein the matching threshold is updated based on the deviation between the recent average reward signal and the target satisfaction.

[0024] Optionally, the method further includes: initiating a capability call to the best-ranked agent based on the matching result list; and automatically downgrading to the second-best candidate agent according to an exponential backoff strategy when the call times out or fails, with a maximum downgrade depth of no more than three times.

[0025] Optionally, the structured validation includes three levels of validation: performing a type consistency check on each attribute value, performing a value range validity check on each attribute value, and performing a completeness check on the fill ratio of required attributes.

[0026] This application also provides a capability management and invocation system for multi-agent systems, comprising: a capability ontology management module, a capability registration center, a capability fingerprint encoding module, a multi-level hash index module, an inference matching engine, an invocation routing and execution module, and a feedback learning module. The capability ontology management module is used to construct and maintain a hierarchical capability ontology, defining a multi-dimensional attribute space and encoding rules. The capability registration center is used to receive capability declaration information from agents, perform structured verification, and generate capability declaration records containing attribute vectors. The capability fingerprint encoding module is used to perform grouping normalization, weighted scaling, and random projection on the attribute vectors to generate fixed-length fingerprint vectors normalized to a unit hypersphere. The multi-level hash index module is used to construct multiple independent hash indices based on the fingerprint vectors and supports incremental updates. The inference matching engine is used to convert invocation requests into query fingerprints, perform coarse screening through the multi-level hash index module, and perform fine-grained inference on the candidate capability set to generate a matching result list. The invocation routing and execution module is used to initiate capability invocations to target agents according to the matching result list and manage the invocation lifecycle. The feedback learning module is used to update the dimension weight vector and matching threshold based on invocation feedback information.

[0027] The technical solution provided in this application has the following beneficial effects:

[0028] By constructing a hierarchical capability ontology and specifying an encoding function for each attribute dimension, the capability declarations of agents are transformed from unstructured text into structured attribute vectors, eliminating the ambiguity of synonyms and heterogeneity in natural language descriptions, and enabling different agents to have a computable similarity relationship in the vector space for descriptions of the same capability.

[0029] By performing grouping normalization and weighted scaling on the attribute vectors and then mapping them to fixed-length fingerprint vectors through a random projection matrix, the attribute vectors are compressed to a compact dimension while maintaining the similarity ranking relationship between vectors, thus reducing the computational and storage overhead of subsequent indexing and matching.

[0030] By constructing multiple independent hash indexes based on fingerprint vectors and using a multi-table union query mechanism to perform coarse screening, the retrieval time for capability matching is reduced from a linear relationship with the number of capability entries to a sub-linear relationship, and the matching latency remains stable as the number of capability entries increases.

[0031] By constructing hash bucket indexes on the fingerprint vector space, when an agent goes online or offline, it only needs to perform insertion or deletion operations in the corresponding buckets of each hash index. The time complexity of a single incremental update is linearly related to the number of hash index groups and is independent of the total number of capability entries, supporting hot-plugging of agents at runtime. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the overall process of the capability management and invocation method provided in the embodiments of this application.

[0033] Figure 2 This is a schematic diagram of the capability ontology construction sub-process provided in an embodiment of this application.

[0034] Figure 3 This is a schematic diagram of the capability registration and verification sub-process provided in the embodiments of this application.

[0035] Figure 4 This is a schematic diagram of the capability fingerprint generation process provided in an embodiment of this application.

[0036] Figure 5 This is a schematic diagram of a multi-level hash index structure provided in an embodiment of this application.

[0037] Figure 6 This is a schematic diagram of a two-stage reasoning and matching process provided in an embodiment of this application.

[0038] Figure 7 This is a schematic diagram of the cascading call and degradation process provided in the embodiments of this application.

[0039] Figure 8 This is a schematic diagram of the feedback signal aggregation and weight update process provided in the embodiments of this application.

[0040] Figure 9 This is a schematic diagram of recall rate curves under different similarity levels provided in the embodiments of this application.

[0041] Figure 10 This is a schematic diagram of the capability management and invocation system architecture provided for an embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with the accompanying drawings and specific embodiments. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0043] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0044] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0045] like Figure 1 As shown, this application provides a capability management and invocation method for multi-agent systems. In a specific implementation, this method transforms the capability declarations of agents into structured attribute vectors by constructing a hierarchical capability ontology tree. The attribute vectors are then subjected to grouped L2 normalization, weighted scaling, and dimensionality reduction using a Gaussian random projection matrix to generate capability fingerprint vectors normalized to a unit hypersphere. A locality-sensitive hash multi-table index based on the SimHash function is constructed on the capability fingerprint vector space. When an invocation request is received, the request is transformed into a query fingerprint in the same space. After coarse screening using multi-table union query and fine ranking and inference using weighted cosine similarity, the matching result is output. Based on the invocation feedback, the dimension weight allocation is continuously optimized using the EWMA dimension weight update algorithm. This method addresses the technical problems in existing technologies, such as the linear increase in capability discovery latency based on text semantic matching with the number of capability entries, the limitation of matching recall due to synonymous heterogeneity ambiguity in natural language capability descriptions, and the proportionality of the cost of rebuilding the inverted index when agents are dynamically online or offline. It achieves the technical effects of reducing capability matching latency from a linear relationship to a sublinear relationship, eliminating semantic ambiguity in text descriptions, improving matching accuracy, and supporting constant-time hot-plugging of agents.

[0046] This method includes the following steps:

[0047] S000. Construct a hierarchical capability ontology, define a multi-dimensional attribute space, specify the attribute type, value range, and encoding function for each attribute dimension, and generate the capability ontology definition.

[0048] like Figure 2As shown, this stage constructs a hierarchical capability ontology tree through domain scanning and dimension filtering, defines attribute types and encoding functions for each dimension, and finally outputs a complete capability ontology definition file.

[0049] S010. Construct a hierarchical capability ontology and define a multi-dimensional attribute space.

[0050] Upon system startup, the system reads a predefined domain knowledge base defined by the administrator. This domain knowledge base includes a list of agent types, a list of task types, and a vocabulary of known capabilities. The capability ontology management module iterates through the agent type list, extracting a candidate set of all capability-related attribute dimensions. These attribute dimensions are sorted according to information gain, and the top-ranked dimensions are selected. Several dimensions are incorporated into the capability ontology definition, among which The range of values ​​is .when When the attribute space is less than 32, its expressive power is insufficient, and the high overlap of fingerprint vectors with different capabilities leads to a decrease in matching accuracy; when When the value is greater than 128, the disaster of dimensionality effect becomes apparent, the efficiency of locally sensitive hash indexes decreases, and a large number of dimensions exhibit sparse zero values.

[0051] Selected Each dimension is organized into a four-layer hierarchical capability ontology tree, whose tree structure follows the principle of mutual exclusion and exhaustiveness. The first layer is the capability domain layer, the second layer is the category layer, the third layer is the subcategory layer, and the fourth layer is the atomic capability layer. The depth of the ontology tree is constrained to no more than four layers to avoid attribute sparsity problems caused by excessive subdivision.

[0052] For example, in an implementation of an AI collaboration platform, the platform includes five types of intelligent agents: natural language processing, data analysis, code generation, knowledge retrieval, and multimodal. The capability ontology management module sets the number of ontology dimensions to... Its first eight dimensions are: Dimension D1 "Capability Domain" (Level 1, Type ENUM, Enumeration set is {NLP, DataAnalysis, CodeGen, KnowledgeRetrieval, Multimodal}, Coding width ), Dimension D2 "Input Modality" (Level 2, Type SET, Total set is {text,image,audio,video,structured_data}, Encoding width ), Dimension D3 "Output Modality" (Level 2, Type SET, Total Set {text,image,audio,code,structured_data}, Encoding Width) ), Dimension D4 "Maximum Input Length" (Level 3, Type CONT, Range) The unit is token, and the encoding width is... ), Dimension D5 "Response Latency Level" (Level 3, Type ENUM, Enumeration set is {realtime, fast, normal, batch}, Encoding width ), Dimension D6 "Supported Languages" (Level 3, Type SET, the complete set includes 15 languages ​​such as zh, en, ja, etc., encoding width) ), Dimension D7 "Concurrency processing capability" (Level 3, Type CONT, Value Range) Encoding width ), Dimension D8 "Whether streaming output is supported" (Level 4, Type BOOL, Value Range) Encoding width The total encoding width of the first 8 dimensions is... .

[0053] S020. Specify the attribute type, value range, and encoding function for each attribute dimension.

[0054] The coding engine in the capability ontology management module is for each dimension. Define a quintuple ,in Dimension name For attribute type, Define the range. For encoding functions, Indicates whether a dimension is required. Attribute types include four types: ENUM (enumeration), CONT (continuous), SET (set), and BOOL (boolean).

[0055] For enumeration type attributes (enumeration set) ), encoding function ,in For the first The number of sub-dimensions after encoding of a one-hot vector with 1 at each position. For continuous attributes (range) ), encoding function The output is Scalar of an interval, number of sub-dimensions after encoding For collection-type attributes (the entire set) ), encoding function Generate length is The multi-hot encoded vector, where the set belongs to . The corresponding position of an element is 1, and the position of an element that does not belong is 0. This results in the number of sub-dimensions after encoding. For Boolean attributes, the encoding function... Number of sub-dimensions after encoding .

[0056] Total dimensions after encoding of attribute space Its value range is This depends on the sum of the number of sub-dimensions after each dimension's encoding is expanded. When enumerating the number of categories for each dimension... When the value exceeds 20, one-hot encoding results in overly sparse vectors; alternatively, a low-dimensional dense vector representation based on embedding encoding can be used. The first 12 core dimensions in the capability ontology definition (including capability domain, input modality, output modality, and response latency level, etc.) Marked as The remaining dimensions are marked as .

[0057] For example, taking the D4 "maximum input length" dimension as an example, its encoding process is as follows: the original value of 50000 tokens is processed by a continuous encoding function. (Dimensionless). Taking the D6 "Supported Languages" dimension as an example, when an agent declares that it supports three languages ​​{zh,en,ja}, the encoding function generates multi-hot encoded vectors. The value of zh (the first position), en (the second position), and ja (the fourth position) is 1.

[0058] S030, Definition of Generative Capability Ontology.

[0059] The version controller in the capability ontology management module assembles all dimension definitions into a capability ontology definition structure. This structure includes a version number, a dimension definition array, and the total number of encoded dimensions. The system creates timestamps and SHA-256 checksums. Before generating the ontology definition, it performs a consistency check to ensure no redundancy between dimensions. The check uses a normalized mutual information metric. ,in For mutual information, Information entropy. When the normalized mutual information value between any two dimensions is less than 0.3, the two dimensions are considered not redundant. 0.3 is an empirical threshold for moderate relevance. Simultaneously, the coverage of known capability types is checked to see if it exceeds 95%.

[0060] For example, in the implementation of the aforementioned AI collaboration platform, the normalized mutual information of D1 "capability domain" and D2 "input modality" Although some correlation exists, it does not reach the redundancy threshold, and the verification passed. The known capabilities of all five types of agents can be described in the 64-dimensional ontology, achieving 100% coverage, exceeding the 95% threshold. The storage size of a single-dimensional definition structure is 108 bytes (bare structure), totaling 124 bytes including a 16-byte record header. The total storage size of the 64-dimensional ontology definition is approximately... The size is approximately 7.8KB. After successful verification, the ontology definition file is broadcast to all agents via a message queue in a publish-subscribe pattern.

[0061] S100: Receive capability declaration information submitted by the intelligent agent, perform structured verification on the capability declaration information according to the capability ontology definition, and generate a structured capability declaration record containing attribute vectors after successful verification.

[0062] like Figure 3 As shown, this stage completes capability registration through four sub-processes: attribute extraction, default filling, three-level verification, and record generation.

[0063] S110, Receive capability declaration information submitted by the intelligent agent.

[0064] The capability registry receives capability self-description information submitted by agents in JSON format via a RESTful API. The capability registry is deployed as a stateless microservice cluster containing at least two service instances. The declaration parser in the capability registry parses the received JSON document into an internal data structure and extracts attribute values ​​one by one according to the dimensions defined in the capability ontology. For optional attributes not provided by the agent, the declaration parser performs default filling: continuous attributes are filled with the median value, enumerated attributes are filled with the "unknown" flag, and set attributes are filled with an empty set. A single agent can register no more than 50 capability entries to prevent malicious registration from causing index bloat.

[0065] For example, a code generation agent "CodeBot-v2" submits the following self-description information to the capability registry via a POST request: the agent identifier is "agent-codegen-001", the declared capability name is "Python code generation", the capability domain is "CodeGen", the input modality is {text}, the output modality is {code,text}, the maximum input length is 8000 tokens, the response latency level is "fast", the supported languages ​​are {zh,en}, the concurrency processing capacity is 50 (dimensionless), and streaming output is supported. The declaration parser maps each of the above JSON fields to the corresponding dimension of the 64-dimensional ontology.

[0066] For example, in the AI ​​collaboration platform, the declaration parser of the capability registry handles the registration request of a multimodal agent "VisionBot-v1". This agent declares its capability domain as "Multimodal", its input modality as {image, text}, its output modality as {text, structured_data}, its maximum input length as 2000 tokens (text portion), its response latency level as "normal", its supported languages ​​as {zh, en, ja}, its concurrent processing capacity as 20 (dimensionless), and it does not support streaming output. The declaration parser encodes the input modality {image, text} into a multi-hot vector. (Text corresponds to the 1st position, image corresponds to the 2nd position), the output modality {text, structured_data} is encoded as follows: (text corresponds to the 1st position) (Corresponding to the 5th bit). D4 maximum input length encoding is: (Dimensionless). The D7 concurrent processing capability is encoded as follows: (Dimensionless).

[0067] The agent does not provide optional attribute values ​​for D9 through D64. The declaration parser performs default padding for these dimensions: D9 "Maximum Output Length" (CONT type) is filled with the median. After encoding, it is 0.5; D10 "Model Version" (ENUM type) is filled with "unknown" markers and encoded as an all-zero vector (not matching any known enumeration value); D11 "API Protocol Version" (SET type) is filled with an empty set and encoded as an all-zero vector. Attribute vectors after default padding. It contains concatenated encoded values ​​from 64 dimensions, with a total dimension of [missing information]. .

[0068] Regarding the high availability design of the capability registry, the stateless microservice cluster distributes requests through a load balancer, and traffic automatically switches to the surviving instance when any instance fails. Capability declaration records are persisted to a distributed key-value store, employing an eventual consistency model. Write operations return success immediately after confirmation by the primary replica and are asynchronously replicated to the secondary replicas. In network partition scenarios, the system prioritizes availability (AP mode), allowing for brief data inconsistencies, which are automatically merged through a version number conflict resolution mechanism after the partition is recovered.

[0069] S120. Perform structured verification on the capability declaration information according to the capability ontology definition.

[0070] The validation engine in the capability registry performs three levels of validation on the parsed capability declarations. The first level is a type consistency check, verifying that the data type of each attribute value matches the type declaration of the corresponding dimension in the capability ontology definition. The second level is a value range validity check, verifying that each attribute value falls within the value range of the corresponding dimension in the capability ontology definition. The third level is a mandatory field completeness check, calculating the fill rate of mandatory dimensions. ,in This represents the number of dimensions marked as required in the ontology. The fill rate must be no less than 80%. Completeness is calculated only for required dimensions; optional dimensions are not included in the denominator, thus avoiding setting excessively high registration thresholds for newly connected agents.

[0071] In addition, the validation engine performs consistency constraint checks. For dimension pairs with logical dependencies, the system verifies the cross-consistency of their values. The validity of a declaration is determined by the logical AND operation of four rules: .

[0072] For example, a three-level validation is performed on the aforementioned capability declaration of "CodeBot-v2". Type check results: The capability domain "CodeGen" is of type ENUM, belonging to the enumeration set {NLP,DataAnalysis,CodeGen,KnowledgeRetrieval,Multimodal}, passing; the maximum input length of 8000 is a numeric type, passing; the supported languages ​​{zh,en} are array types corresponding to the SET type, passing. Value domain check results: Maximum input length... Through; concurrent processing capabilities Passed. Completeness check results: 11 of the filled dimensions are required dimensions; total number of required dimensions: [Total number of required dimensions not specified]. , Passed. Consistency check: The output modality contains "code", the capability domain is "CodeGen", and the logical dependencies are satisfied; passed. Overall judgment: .

[0073] As a counterexample, if another agent submits a declaration with the capability domain "InvalidDomain", a maximum input length of -100, and a supported language field that is the string "zh" instead of an array, then the validation result is: Rule 1 fails. Type mismatch (should be SET type but actually String type), Rule 2 failed (capability domain not in enumeration set, maximum input length - 100 is less than lower bound 100), Rule 3 failed ( The system returns a rejection status and a list of error details.

[0074] S130. After successful verification, a structured capability declaration record containing attribute vectors is generated.

[0075] After successful verification, the version manager in the capability registry assigns a system-level unique identifier to the capability and assembles a structured capability declaration record. This record includes the agent identifier, capability identifier, version number, original attribute vector values, completeness, change type, timestamp, and extended metadata. Original attribute vector values It is formed by the encoding engine encoding the original values ​​of each dimension according to the encoding function defined by S000 and then concatenating them.

[0076] The capability registry uses an append-only version log to manage the change history of capability declarations. Each capability update does not overwrite the old record; instead, a new version is appended and a timestamp is added. The current valid version is retrieved using the latest timestamp index. Agents only need to submit the changed dimension values ​​(differential updates), and the system automatically merges them with the previous version to generate a complete record.

[0077] Regarding conflict handling in version control, when the same agent submits multiple capability updates consecutively within a short period, the version manager employs an optimistic concurrency control strategy. Each update request carries the current version number known to the client. The version manager compares the requested version number with the latest version number on the server: if they match, the update is executed and the version number is incremented; if they do not match, a version conflict status code is returned, and the client needs to obtain the latest version and retry. This strategy avoids the introduction of distributed locks and in low-conflict scenarios (where agent update frequency is typically less than once per minute), it incurs almost no additional overhead.

[0078] Regarding the handling of sparsity in attribute vectors, , In this configuration, approximately 40% to 60% of the components in a single attribute vector are zero (from the empty set encoding of the undeclared optional SET dimension and the all-zero encoding of the default-padded ENUM dimension). The capability registry uses a compact and sparse format to store attribute vectors—only storing index-value pairs of non-zero components, with an average storage size ranging from... Bytes dropped to approximately The sparse format (including a 2-byte index and a 4-byte floating-point value) saves approximately 25% of storage space. When transmitted to the S200 capability fingerprint encoding module, the sparse format is automatically expanded into a dense vector to adapt to matrix projection operations.

[0079] Once the record is generated, the event publisher in the capability registry publishes the capability change event to downstream modules through the message queue, triggering the capability fingerprint encoding module to generate the fingerprint and the multi-level hash index module to perform incremental updates.

[0080] For example, after the aforementioned "CodeBot-v2" passes verification, the system generates the following capability declaration record: agent identifier "agent-codegen-001", capability identifier "cap-py-gen-001" (system-assigned), version number 1, and the encoding process of key components in the original value of the attribute vector is D4 maximum input length. (Dimensionless), D7 concurrent processing capability (Dimensionless), the multi-hot encoding of the D3 output modality {code,text} is as follows: (Text corresponds to the 1st character, code corresponds to the 4th character), completeness 0.917, change type CREATE. The storage size of a single capability declaration record is... The raw data structure is approximately 473 bytes, plus a 32-byte header, totaling 505 bytes. With 1000 agents and an average of 10 capabilities per agent, the total storage is approximately... Bytes (approximately 4.8MB).

[0081] S200. Perform grouping normalization on the attribute vector to eliminate the difference in dimensions, perform dimension-wise weighted scaling on the normalized vector and the dimension weight vector, map the weighted vector to a fixed-length fingerprint vector through a random projection matrix, and normalize the fingerprint vector to a unit hypersphere.

[0082] like Figure 4 As shown, this stage uses a four-step pipeline to transform the original attribute vector values ​​into capability fingerprint vectors normalized to a unit hypersphere.

[0083] S210. Perform grouping normalization on the attribute vector.

[0084] The capability fingerprint encoding module receives the raw values ​​of the attribute vector output by S100. Then, perform L2 normalization on it, grouping it according to the ontology dimension. Specifically, According to ontological dimension Encoding width Split into Subvectors ,in Perform L2 normalization on each subvector:

[0085]

[0086] When a subvector is a zero vector (i.e., the original value of that dimension is 0 or the empty set encoding result is a vector of all zeros), the normalization result remains a zero vector, and this dimension does not participate in subsequent similarity calculations. The purpose of group normalization is to eliminate the unequal contribution of dimensions with different encoding widths to the final vector. If this step is not performed, the "supporting language" dimension with an encoding width of 15 occupies a much larger component in the concatenated vector than the "maximum input length" dimension with an encoding width of 1, causing the former to dominate the similarity determination during cosine similarity calculation.

[0087] For example, in the aforementioned attribute vector of "CodeBot-v2", the D6 "Supported Languages" subvector is: (Supports zh and en), its L2 norm is After normalization The D4 "maximum input length" subvector is a scalar. The L2 norm is After normalization (After scalar normalization, it is always 1.0 or -1.0, which does not affect the directional information and only preserves the existence of this dimension).

[0088] S220. Perform a dimension-wise weighted scaling on the normalized vector and the dimension weight vector.

[0089] The capability fingerprint encoding module normalizes the vector after grouping. with dimension weight vector Perform dimension-wise weighted scaling. The weight vector is initialized to a uniform distribution. Satisfying normalization constraints And lower bound constraint The weighting operation will apply to each dimension. normalized subvectors Multiply by the corresponding weight :

[0090]

[0091] The weighted and concatenated results The purpose of weighted scaling is to provide the system with an adjustable knob for the importance of dimensions. The S600 feedback learning module updates... Dimensions with high matching success rates are given greater weight, while dimensions with low matching contribution are weighted less. (Initial stage) To ensure uniform distribution, all dimensions participate in the matching with equal weight.

[0092] For example, in In the initial stage, The normalized subvector of D1 "capability domain" is: (CodeGen is ranked 3rd), after weighting After the S600 weight update, if the weight of D1 is increased to... ,but The influence of the capability domain dimension in subsequent similarity calculations increased by approximately 60%.

[0093] S230. The weighted vector is mapped to a fixed-length fingerprint vector through a random projection matrix.

[0094] The capability fingerprint encoding module uses a Gaussian random projection matrix. The weighted high-dimensional vector Projected onto low-dimensional fingerprint space:

[0095]

[0096] in The fingerprint vector dimension is [dimension number]. Each element of the Gaussian random projection matrix is ​​independently sampled from [data source]. The mean is zero to ensure that the projection has no directional bias, and the variance is... This ensures that the magnitude of the projected vector components is independent of the dimension. The Gaussian random projection matrix is ​​generated once and stored in a fixed manner by the projection matrix generator in the capability fingerprint encoding module during system initialization using a deterministic random seed. Subsequently, all agents share the same matrix for fingerprint generation and query fingerprint generation, ensuring the consistency of the fingerprint space.

[0097] fingerprint dimension The selection is based on the Johnson-Lindenstrauss lemma. This lemma states that when... Time (of which) It is a constant. The effective degrees of freedom of the capability vector set, To maintain an error tolerance for distance, random projection preserves the pairwise distances between the original vectors with high probability. In a dimensional capability ontology, effective degrees of freedom (Due to the existence of sparse coding and related dimensions), take At that time, according to the Achlioptas simplification condition, the lower bound of the projected dimension required to preserve the dimension order is approximately The system will Setting it to 128, which is greater than the lower bound, ensures that the similarity ranking relationship between vectors after projection is preserved in a probabilistic sense. The storage size of the projection matrix is... bytes (approximately 128KB), in typical Storage overhead is negligible under this configuration.

[0098] Alternatively, a sparse random projection matrix (such as an Achlioptas matrix, whose elements are probabilistically...) can be used. Zero probability for or It replaces the Gaussian random projection matrix, reducing the projection computation by about 66% while maintaining the same accuracy at the same distance.

[0099] For example, suppose , Projection matrix The first row is a 128-dimensional random vector. Each component is sampled independently from The first component of the fingerprint vector When the cosine similarity of the weighted attribute vectors of two NLP translation agents is 0.95, the cosine similarity of their projected fingerprint vectors is... Keep below The probability within the range exceeds 99%.

[0100] S240. Normalize the fingerprint vector to a unit hypersphere.

[0101] The capability fingerprint encoding module performs L2 normalization (spherical normalization) on the projected fingerprint vector:

[0102]

[0103] After normalization All fingerprint vectors are located in On a unit hypersphere. This normalization makes the inner product of the two fingerprint vectors... Equivalent to cosine similarity, the subsequent SimHash function of S300 and the fine-grained ranking score of S400 can directly use inner product operations without additional norm calculations. The storage size of a single capability fingerprint vector is... Bytes. With 10,000 capability entries, the total storage size of all fingerprint vectors is... Bytes (approximately 4.9MB).

[0104] The end-to-end latency of fingerprint encoding is determined by a four-step pipeline. Group normalization requires... L2 norm calculation, weighted scaling requires Sub-floating-point multiplication, matrix projection requires Sub-floating-point multiplication and addition, spherical normalization is required. Floating-point operations. Approximately [number] in total. This is a floating-point operation.

[0105] For example, in Under the aforementioned configuration, the projected vector of "CodeBot-v2" The L2 norm is assumed to be Then the normalized fingerprint vector Each component is magnified approximately 2.21 times. After normalization The end-to-end delay is approximately (Based on the FLOPS estimate of a 2GHz single-core CPU), it is much smaller than the 5ms constraint of the S300.

[0106] In actual system deployment, the four-step pipeline can be further optimized to improve throughput. In the grouping normalization step, when the original encoding of a certain SET type dimension is an empty set (all-zero vector), the system skips the L2 norm calculation for that dimension and directly sets the normalization result to a zero vector—this dimension remains a zero vector after subsequent weighted scaling, not affecting the projection result but saving approximately 30% of the normalization computation. In the weighted scaling step, the dimension weight vector... The scaling factor remains unchanged between update cycles, so the scaling factor for each dimension can be pre-computed and cached, avoiding repeated reading of the weight vector each time a fingerprint is generated.

[0107] Regarding storage optimization of the projection matrix, when When the value is large (over 512), the storage overhead of the Gaussian random projection matrix may exceed 1MB. In this case, structured random matrices (such as random projections based on the fast Walsh-Hadamard transform) can be used to reduce the time complexity of matrix multiplication from... Reduce to Meanwhile, the matrix does not need to be explicitly stored—only a random sign-flipped vector needs to be stored. byte) and subsample index ( (bytes). , With this configuration, the storage of structured projection only requires The number of bytes (approximately 1KB) is 99.6% less than the 262KB of a Gausian matrix.

[0108] Regarding the fingerprint update strategy, when S600 updates the dimension weight vector Afterwards, the fingerprint vectors of all registered capabilities need to be regenerated (due to the S220 weighted scaling dependency). With 10,000 capability entries, the time to batch regenerate all fingerprints is approximately... It can be executed asynchronously in the background without blocking the real-time query path. During the regeneration process, the query request still uses the old fingerprint for matching. After all fingerprints are updated, it atomically switches to the new version, using a read-write lock mechanism to ensure consistency.

[0109] For example, in a weight update scenario, suppose S600 changes the weight of the D1 capability domain from... Upgraded to For the aforementioned CodeBot-v2 subvector D1 The contribution of this component in the old fingerprint is The new fingerprint becomes After projection, the influence of dimension D1 on each component of the fingerprint vector increased by approximately 60%, raising the cosine similarity of two capabilities belonging to the CodeGen domain in the new fingerprint space from 0.92 to 0.95—the system learned that the capability domain is the key dimension for distinguishing capabilities. Meanwhile, the weight of D7 concurrency processing capability decreased from 0.015625 to 0.00814, reducing its influence on matching by approximately 48%, reflecting the relatively small contribution of concurrency capability to the matching success rate in actual calls.

[0110] Regarding throughput optimization for batch fingerprint generation, when the system starts, initial fingerprint generation needs to be performed on all registered capabilities (cold start scenario). The capability fingerprint encoding module assembles multiple attribute vectors into a batch matrix. Through matrix multiplication The projection operation for all vectors is performed in one step. , , Under this configuration, the floating-point computation cost of batch projection is The multiply-add operation takes approximately 3.3ms on a modern CPU (supporting the AVX-512 instruction set, approximately 100 GFLOPS per core) to complete the generation of all 10,000 fingerprints. This is significantly faster than processing each fingerprint sequentially. The batch mode achieves approximately 48x throughput improvement by eliminating loop overhead and leveraging SIMD parallelism. After the cold start is complete, subsequent incremental fingerprint generation (single capability registration or update) still uses the line-by-line mode to reduce latency.

[0111] To verify the semantic preservation of fingerprint encoding, the ranking consistency of the cosine similarity of the original attribute vectors and the cosine similarity of the fingerprint vectors was calculated for both intra-domain and cross-domain capability pairs. The intra-domain preservation rate was defined as the proportion of intra-domain capability pairs that remain nearest neighbors in the fingerprint space, while the cross-domain preservation rate was defined as the proportion of capability pairs from different domains that do not remain nearest neighbors in the fingerprint space. , , With this configuration, the intra-domain retention rate is 96.5% (greater than the 75% threshold), and the cross-domain retention rate is 86.7% (greater than the 75% threshold).

[0112] S300. Based on the fingerprint vector, construct multiple independent hash indexes. Each hash index uses an independent family of random hyperplanes to divide the fingerprint vector space, and maps each fingerprint vector to the corresponding hash bucket.

[0113] like Figure 5As shown, this stage constructs a local sensitive hash multi-table index structure to achieve sublinear nearest neighbor retrieval of the capability fingerprint vector space.

[0114] S310. The fingerprint vector space is partitioned using an independent family of random hyperplanes.

[0115] The hash function manager in the multi-level hash index module generates A family of independent random hyperplanes, each containing A family of random hyperplanes. Each hash function in the family of random hyperplanes generates a one-bit binary code by calculating the sign of the inner product of the fingerprint vector and the normal vector of the random hyperplane. Specifically, the first... The first in the group A hash function is defined as:

[0116]

[0117] in For the first Group 1 A random hyperplane normal vector, each component of which is independently sampled from a standard Gaussian distribution. The normal vectors are generated and fixed once by a deterministic random seed during system initialization, and the same set of normal vectors is used for subsequent queries and updates. This hash function utilizes the core property of SimHash: the probability that two unit vectors lie on the same side of the same random hyperplane is positively correlated with the cosine of their angle, i.e. Vector pairs with higher cosine similarity have a greater probability of colliding on a single hash function.

[0118] In each set of hash indexes A combination of hash functions generates Bit-bin encoding as bucket address:

[0119]

[0120] The integer encoding of the bucket address is Each set of hash indices contains There are buckets. The probability that two fingerprint vectors collide in the same set of indices is... , The larger the value, the lower the probability of collision (higher precision but lower recall).

[0121] Group-independent indexes employ a multi-table union query mechanism: during the query, all tables are used for the query. Search each index separately and take the union of the candidate sets. The probability of at least one collision (i.e., being recalled) in each index is:

[0122]

[0123] This formula shows that, The increase in causes the probability of missed detection to decrease exponentially.

[0124] parameter and The value of needs to be balanced between recall, precision, and resource overhead. The range of values ​​is , The range of values ​​is . When the size is too large (greater than 16), each barrel contains an average of only a vector, when , At that time, each bucket contained only 0.15 vectors, and most buckets were empty, resulting in a sharp drop in recall. When it is too small (less than 8), Each bucket contains approximately 39 vectors; an excessively large candidate set increases the overhead of fine-sorting. The system will... Set to 16 Set it to 10 as a balanced configuration.

[0125] For example, in , Under the given configuration, the recall rate of capability pairs with different cosine similarities is calculated as follows: When the cosine similarity is 0.95, the single-table collision probability is... The probability of at least one collision in Table 16 is... When the cosine similarity is 0.85, the single-table collision probability is... The recall rate for Table 16 is... When the cosine similarity is 0.70, the single-table collision probability is... The recall rate for Table 16 is... When the cosine similarity is greater than 0.85, the recall rate is greater than 91.6%, which meets the system accuracy requirements.

[0126] S320. Map each fingerprint vector to its corresponding hash bucket.

[0127] The bucket storage engine in the multi-level hash index module performs a process on each capability fingerprint vector output by the S200. The bucket address is calculated and the insertion operation is performed in the group index. Internally, the bucket storage engine uses an in-memory hash mapping structure to store bucket data, with each bucket being a hash set of capability identifiers.

[0128] The multiple independent hash indexes support incremental updates. When an agent comes online, the incremental updater in the multi-level hash index module subscribes to capability change events and inserts the new fingerprint vector into the corresponding bucket of each hash index. When an agent goes offline, its fingerprint vector is deleted from the corresponding bucket of each hash index. A single incremental update requires computation. 1 hash value (each hash value needs 1) (second inner product operation), plus The second-order bucket operation (insertion or deletion in the hash set) has a time complexity of O(n log n). , and the total number of ability items Irrelevant.

[0129] For example, with , , A simplified parameter demonstration of the index building process. Hash table. The three hyperplane normal vectors are , , Capability cap-A (NLP translation, fingerprinting) Calculate the hash value: ; ; . Bucket number .

[0130] Capability cap-B (NLP summary, fingerprint) Perform the same calculation. The two NLP capabilities have the same bucket number of 5. Their fingerprints are semantically similar and fall into the same bucket, which reflects the local sensitivity property of the hash function.

[0131] During the execution of the multi-table union query, the query executor sequentially calculates the bucket address of the query fingerprint in each group of indexes and reads the list of capability identifiers within the bucket, merging all lists into a deduplicated hash set. Since each group of indexes uses an independent family of random hyperplanes, a capability not colliding with the query in one group of indexes (missed detection) does not affect its probability of being recalled in other groups of indexes. Assuming the cosine similarity of the true nearest neighbor is 0.90, the single-table collision probability is... The probability of at least one collision in Table 16 is... —With each additional set of indexes, the probability of a missed detection is approximately multiplied by [percentage missing]. It decays exponentially to a negligible level.

[0132] like Figure 9As shown, the recall curve exhibits a distinct S-shaped characteristic: in regions where the cosine similarity is below 0.5, the recall rate rapidly drops to below 25%, effectively filtering out candidates with weak semantic relevance to the query and reducing the computational cost of the fine-grained ranking stage; in regions where the cosine similarity is above 0.85, the recall rate stabilizes above 91%, ensuring that truly similar vectors are recalled with a high probability. This S-shaped characteristic is precisely the theoretical guarantee of Locality Sensitive Hashing—vector pairs with high similarity are recalled with a much higher probability than vector pairs with low similarity.

[0133] For the memory layout of bucket data, the bucket storage engine uses open-address hash mapping instead of linked-list hash mapping to improve CPU cache hit rate. The capability identifier within each bucket is stored as a 36-byte UUID string in a compact array. When the number of capabilities in a single bucket exceeds 50 (i.e., a hot bucket), the system logs an alert and recommends that the administrator increase the number of capabilities. The value is to reduce the average size per bucket. In a typical configuration ( , , Under these conditions, each barrel contains an average of Each ability item has a very low probability of appearing in the hotspot bucket.

[0134] Regarding the index persistence strategy, the multi-level hash index module keeps the index data entirely resident in memory during normal operation to ensure query latency. Every 300 seconds, the system asynchronously snapshots the index data in memory to persistent storage (serialization format is binary compact encoding) to quickly restore the index upon node restart without having to rebuild it from all capability fingerprints. The snapshot size is approximately equal to the total index memory (7.3MB), and the write latency to disk is approximately 2ms, which does not affect the real-time query path.

[0135] Total memory estimate for index: Hash function storage Bytes (approximately 80KB), bucket data storage (36 bytes per capability identifier, totaling...) Each entry is approximately 5.5MB, plus 30% metadata overhead, totaling about 7.2MB. The total index memory is approximately 7.3MB, far less than the system constraint of 100MB.

[0136] Regarding the management of random seeds for the hash function family, the system generates a 64-bit master seed during initialization and persists it. Each hyperplane normal vector is derived from the master seed using a deterministic pseudo-random number generator, ensuring that the same family of hash functions can be accurately reconstructed after a system restart or node migration. Changing the master seed is equivalent to rebuilding the entire index; the hash values ​​of all registered capabilities need to be recalculated and redistributed to new buckets. Therefore, the master seed remains unchanged throughout the system's lifetime, only changing when the index structure parameters ( or It only needs to be regenerated when changes are made.

[0137] Regarding parallel query optimization with multiple indexes, in a multi-core processor environment, the query executor can... The hash calculations and bucket read operations for the grouped indexes are distributed across multiple threads for parallel execution. Query operations for each grouped index are independent (without data dependencies), naturally suited for parallelization. On a 16-core server, the latency of parallel queries for 16 groups of indexes is reduced from serial queries. Reduce to single-group query latency Including thread scheduling overhead Approximately This represents an improvement of approximately 11 times compared to the serial mode. Even in a single-core environment, serial querying is still used, and the 0.8ms latency accounts for only 1.6% of the total 50ms budget, not constituting a bottleneck.

[0138] Incremental update latency estimation when a new intelligent agent goes live: Group index, each group needs to be calculated The inner product ( (Wei), total The total time is approximately 0.02ms for the first floating-point operation and 16 bucket insertion operations (approximately 0.001ms), which is far less than the 5ms real-time constraint.

[0139] S400. When a call request is received, the call request is converted into a query fingerprint in the same space as the fingerprint vector. A coarse screening is performed through the multiple sets of independent hash indexes to obtain a set of candidate capabilities. Fine ranking and reasoning are performed on each candidate in the set of candidate capabilities to generate a list of matching results.

[0140] like Figure 6 As shown, this stage completes capability matching reasoning through three steps: request fingerprinting, coarse screening, and fine ranking.

[0141] S410. The call request is converted into a query fingerprint in the same space as the fingerprint vector.

[0142] The request parser in the inference matching engine receives the call request. The process of converting the call request into a query fingerprint involves two mutually exclusive modes, which are automatically determined by the format of the request.

[0143] When the call request is submitted in a structured format (i.e., the requester fills in the required attribute values ​​one by one in JSON format according to the ontology dimension), the fingerprinter in the inference matching engine directly performs field mapping according to the ontology dimension to generate a required attribute vector:

[0144]

[0145] in The encoding function defined for S000. Unfilled dimensions are marked as wildcard dimensions, and wildcard values ​​will be filled in later (median for continuous types, and the entire set for set types).

[0146] When the invocation request is submitted in a semi-structured format (providing only a natural language task description and structured constraints), the inference matching engine uses an ontology-based keyword dictionary. The task description slots are populated. The keyword dictionary is used for each ontology dimension in phase S000. Construct a mapping table from keywords to attribute values Each dictionary entry is configured synchronously by the system administrator when defining the ontology. The slot filling process segments the task description text and fills it dimension by dimension. The system matches keywords; if a match is found, the corresponding attribute value is entered; otherwise, it is marked as a wildcard dimension. (Structured constraints) Directly overwriting the value of the corresponding dimension in the slot fill result has higher priority than keyword matching.

[0147]

[0148] The dimensions that do not match keywords in the slot filling are marked as wildcard dimensions. The inference matching engine calculates the proportion of wildcard dimensions before fingerprinting. And perform tiered processing according to this ratio: when When the wildcard dimension uses the default fill strategy, it directly enters the fingerprinting process; when When it executes normally, a low-confidence flag is appended to the matching results; when At that time, the weights of all wildcard dimensions are... Temporarily set the weights to zero, then renormalize the weights for the remaining specified dimensions. Then fingerprinting and matching are performed. If the specified number of dimensions is less than 3 (i.e. The system returned an error code. And reject this match.

[0149] The generation of query fingerprints uses the same coding pipeline as the S200 capability fingerprint:

[0150]

[0151] For example, a user requests "translate a Chinese technical document into English, supporting streaming output with a fast latency level," submitted in semi-structured mode. Slot filling process: The keyword "translation" hits D1. Mapped to the capability domain "NLP"; the keywords "Chinese" and "English" hit D6. Mapped to the supporting languages ​​{zh,en}; constraint injection: In the D8 region, "streaming" is true, and "latency" is "fast" across D5. The keyword "translation" also hits D2. Mapped to the input modality {text}; hit D3. This is mapped to the output modality {text}. The slot filling and constraint injection specified six dimensions: D1, D2, D3, D5, D6, and D8. The remaining 58 dimensions (D4, D7, and D9 to D64) did not match the keywords and were marked as wildcard dimensions. Wildcard dimension ratio. The trigger weight reset to zero mode temporarily sets the weights of the 58 wildcard dimensions to zero, and then re-normalizes the weights of the 6 specified dimensions before performing fingerprinting. The query fingerprint is generated via the S200 process. .

[0152] The design considerations for the wildcard filling strategy are as follows: After taking the entire set for the set-type dimension, its multi-hot encoding is a vector of all 1s. After being grouped and L2 normalized by S200, it becomes a uniformly distributed vector. Its cosine similarity to any set encoding containing only a few elements is . —A lower but non-zero value expresses the semantics of "unspecified is equivalent to no restriction, which means equal acceptance of all values." Continuous dimensions take the median of 0.5, similarly expressing no preference. In typical invocation scenarios, the requester usually explicitly specifies core dimensions (capability domain, input / output modality, and latency level, etc.), while unspecified dimensions are mostly auxiliary attributes (such as the specific list of supported languages ​​and concurrency), accounting for approximately 30% to 50%. Since the weights of unspecified dimensions in the S220 weighted scaling step remain uniform, the weights are not uniform. (Non-amplified value), and the S300 multi-table union query mechanism will recall the target as long as it collides with any set of indexes, and the directional influence of the wildcard component is effectively diluted by the multi-table voting mechanism.

[0153] Regarding the parameter sensitivity of the fine-ranking scoring function, Control the weight of semantic matching in the scoring. When Increasing the value from the default 0.5 to 0.7 makes candidates with high semantic similarity but slightly lower constraint satisfaction more likely to achieve high scores, suitable for scenarios with strict functional matching requirements but relaxed constraints. When the value is increased from 0.3 to 0.5, the satisfaction of hard constraints becomes the dominant factor in the scoring. Only candidates that fully satisfy all constraints can get high scores, which is suitable for safety-critical call scenarios. It mainly plays a differentiating role when the candidate capabilities are similar. Among two candidates with similar scores, the idle node gets a higher overall score, thus achieving load balancing.

[0154] S420. Perform coarse screening using the multiple sets of independent hash indexes to obtain a set of candidate capabilities.

[0155] The coarse-screen executor in the inference matching engine will query fingerprints. Input the multi-level hash index module of S300, for The group index calculates the bucket address and retrieves the capability identifier from the bucket, then merges all of them. The search results of the group index are deduplicated to obtain a candidate capability set. The size of the candidate set is limited to [number]. Any excess will be truncated in descending order of frequency of occurrence within the bucket.

[0156] For example, querying fingerprints exist The data falls into bucket number 5, which contains {cap-NLP-001,cap-NLP-002}; The candidate set falls into bucket number 3, which contains {cap-NLP-001, cap-NLP-003}. This is the merged, deduplicated candidate set. There are 3 candidates in total. Coarse screening delay: Union query of 16 indexes. .

[0157] S430. Perform fine-grained reasoning on each candidate in the candidate capability set to generate a matching result list.

[0158] The fine-ranking scorer in the inference matching engine calculates a comprehensive score for each candidate in the candidate set. Before performing fine-ranking, the fine-ranking scorer performs gating filtering on the candidate capability set, discarding candidates with negative cosine similarity (opposite semantic direction) and candidates with zero constraint satisfaction (not satisfying any hard constraints). After gating, the fine-ranking score function is:

[0159]

[0160] The similarity component (The inner product is the cosine similarity, since both vectors are unit vectors), the range after gating. Constraint satisfaction components ,in For hard constraint quantity, For the state of satisfying a single constraint, the range Available components ,range Weight parameters (Semantic matching is the core objective) (Hard constraints are necessary conditions) (Load balancing is a secondary objective) to satisfy ,therefore .

[0161] Only when At that time, ability Included in the final matching results. Matching threshold. The default value is 0.6, which is adjusted online by the S600. The fine-ranking scorer sorts all candidates that pass the threshold in descending order of score and outputs a list of matching results. .

[0162] The purpose of gated filtering is to reduce unnecessary computations in the fine-grained ranking stage. A negative cosine similarity value indicates that the angle between the query fingerprint and the candidate fingerprint on the hypersphere exceeds 90 degrees, meaning they have opposite semantic directions and cannot be a reasonable match. A constraint satisfaction value of zero indicates that all hard constraints are not satisfied, and even if the semantic similarity is extremely high, the call cannot be completed. Under typical configurations, approximately 15% to 25% of the candidates returned from the coarse-grained selection are discarded by gated filtering, allowing the fine-grained ranking stage to process only 75% to 85% of the candidates, effectively reducing the computational overhead of fine-grained ranking.

[0163] Regarding the real-time guarantee of availability, the load collector in the inference matching engine collects current load data (current concurrent requests and maximum concurrent capacity) from each agent via a heartbeat mechanism at 1-second intervals. Load data is cached in local memory, and during fine-grained ranking, the cached value is read directly instead of being queried in real time, ensuring that fine-grained ranking latency is not affected by network round-trip time. When an agent does not respond for more than 3 heartbeat cycles (3 seconds), the load collector marks its availability as 0 (fully loaded), and this candidate is included in the fine-grained ranking. A component with zero value is not discarded by the gating (because the gating only filters candidates with negative cosine similarity and zero constraint satisfaction), and only receives a lower ranking in the overall score.

[0164] Alternatively, it can be , , Replace with dynamic weights based on request priority—higher priority requests are increased. (Strict constraints) Low-priority requests increase (Prefers idle nodes).

[0165] For example, fine ranking is performed on the three candidates for the aforementioned translation request. Hard constraint definition ( ): Supported languages {zh,en}、 Streaming output true、 Latency level fast. Candidate cap-NLP-001 (Translation Agent-A): All constraints are satisfied , , Candidate cap-NLP-002 (Translation Agent-B): , , , Candidate cap-NLP-003 (Summary Agent): , Not satisfied (streaming output not supported). , , All ratings are greater than or equal to All results are included. Matching results list. End-to-end latency: Request parsing 2ms + fingerprinting 0.7ms + coarse filtering 0.8ms + fine sorting 0.3ms 3.8ms, much less than the 50ms constraint.

[0166] S500: Initiate a capability call to the agent with the best ranking based on the matching result list.

[0167] like Figure 7 As shown, this stage involves the execution of capabilities through cascading calls and exponential backoff / degradation strategies.

[0168] S510: Initiate a capability call to the agent with the best ranking.

[0169] The routing decision-maker in the routing and execution module is invoked from the list of matching results. The candidate with the highest score (Top-1) is selected as the primary target. The RPC client pool in the routing and execution module sends a call request (including task parameters) to the target agent and starts a timeout timer with a single call timeout threshold. .

[0170] S520: When a call times out or fails, it automatically degrades to a suboptimal candidate agent using an exponential backoff strategy.

[0171] The degradation controller in the call routing and execution module automatically downgrades to the second-best candidate using an exponential backoff strategy when the primary target call times out or returns an error. The waiting time for the next retry is:

[0172]

[0173] in , , The maximum degradation depth is no more than three times (including the first call, a total of Top-3 candidates are tried). When the availability component of a candidate agent is zero (fully loaded), the degradation controller skips that candidate and directly tries the next one.

[0174] After the call is completed, the call routing and execution module will send the call record (including request identifier, target agent identifier, score, call status, actual delay, number of retries and final executor identifier) ​​to the S600 feedback learning module through a message queue.

[0175] For example, continuing with the S400 example. The routing decision-maker selects Top-1 Agent-A ( The Agent-A sends a call request. In a typical scenario, Agent-A returns the translation result within 1200ms. Degradation scenario: Agent-A network failure causes a 5000ms timeout, and the degradation controller waits. Select Top-2Agent-B ( Agent-B returned success within 1200ms. Total latency .

[0176] Regarding the fault tolerance analysis of the cascading degradation strategy, in the extreme scenario where all three degradation attempts fail (all Top-3 candidates are unavailable), the routing and execution module returns... The status code is sent and the failure record is sent to the S600. The feedback learning module will record such failures. Set to 0, Set as (Maximum value) Set to 0 to generate the minimum reward signal. The zero-reward signal, updated via EWMA, causes the contribution of all dimensions to decrease uniformly, without systematically biasing or penalizing any particular dimension, because the failure is due to unavailable candidates (runtime failure) rather than inaccurate matching (dimensional weighting issues).

[0177] The call routing and execution module also maintains a short-term circuit breaker state table. When an agent fails three times consecutively within the last 60 seconds, the circuit breaker marks that agent as in a circuit-broken state, and automatically skips that agent in the matching results for the next 30 seconds (even if it has the highest score). After the circuit breaker expires, the system attempts a probe call in a half-open state; if successful, normal operation resumes; otherwise, the circuit breaker remains in effect. This mechanism avoids repeated invalid calls to known faulty nodes, reducing the average response latency perceived by the user.

[0178] S600. Update the dimension weight vector according to the call feedback information in the matching result list.

[0179] like Figure 8 As shown, this stage completes the adaptive adjustment of dimension weights through two steps: feedback signal aggregation and EWMA dimension weight update.

[0180] S610, aggregate the call feedback information into a reward signal.

[0181] The feedback collector in the feedback learning module receives call logs and optional user satisfaction ratings sent by the S500. The reward calculator in the feedback learning module aggregates the multi-dimensional feedback signals into a single reward signal. :

[0182]

[0183] in To indicate a successful call to the function, Actual call latency (in milliseconds). Rate user satisfaction (default 0.5 if no rating is given). , , (Weight sum is 1). The range of all three components is... ,therefore .

[0184] For example, Agent-A successfully called ( , , ), .

[0185] S620: Update the dimension weight vector using the exponentially weighted moving average algorithm.

[0186] The contribution accumulator in the feedback learning module applies to each ontology dimension. ( Maintain a contribution metric for one dimension. Initial contribution value Consistent with the initial weights. When a match is successful (high reward), the smaller the difference between the normalized attribute sub-vectors of the query vector and the hit vector in that dimension, the greater the contribution of that dimension to the successful match. The EWMA update formula for contribution is:

[0187]

[0188] in EWMA attenuation factor and The query and hit capabilities are respectively in the second place. Grouped L2 normalized subvectors of dimension. Since the normalized subvectors are unit vectors. Therefore, the product factor ,and The product is always non-negative, ensuring that the product is not negative. It will not accumulate into a negative value.

[0189] Feedback learning module cumulative A batch weight update is performed after the feedback from the next call. The update process consists of three steps: first, the normalized weights are calculated. Then, a clipping constraint is applied to the single adjustment range. Finally, the clipped vectors are renormalized. To meet Constraints. Simultaneously enforce a lower bound on the weights. This prevents any dimension from being completely ignored. After the system starts, once the first [dimension] is full... Before the cycle, Keep the initial uniform value unchanged.

[0190] The feedback learning module synchronously performs adaptive adjustment of the matching threshold:

[0191]

[0192] in For the most recent Average reward per call , If the average reward is higher than the target, the threshold is raised (more stringent); if it is lower than the target, the threshold is lowered (more lenient).

[0193] Once the update is complete, the weight publisher in the feedback learning module broadcasts the new weight vector to all capability fingerprint encoding modules and inference matching engine instances via a message queue.

[0194] For example, the weights are updated after 500 calls. The initial weights are uniform. Average reward The D1 capability domain, after being accumulated by EWMA, D7 concurrency capability The remaining 62 dimensions ,sum Step (a) Normalization: , Step (b) Cutting: , Not triggered. ; Not triggered. Step (c) Renormalization: , , .verify: , Threshold update: .

[0195] Regarding EWMA attenuation factor The selection, This means that new feedback signals only account for 1% of the contribution in each update, while historical accumulation accounts for 99%. This setting makes the changes in the weight vector smooth and stable, avoiding excessive disturbances to the weights from single abnormal feedback (such as timeouts caused by network jitter). In the early stages of system operation (the first 1000 calls), due to the limited number of feedback samples, It can be temporarily set to 0.05 to accelerate convergence; it will automatically drop back to 0.01 after the system enters steady state. The range of values ​​is If the value is too small, the convergence will be too slow (it will take tens of thousands of calls to observe the weight change), and if it is too large, the weight will oscillate and become unstable.

[0196] Regarding the lower bound constraint of the weight The design intent is to prevent the weights of any dimension from decaying to zero. If the weight of a dimension is zero, then the component of that dimension after weighted scaling is a zero vector, which contributes nothing to the fingerprint vector after projection, equivalent to permanently deleting that dimension from the capability description. This is an irreversible loss of information, and cannot be recovered even if the dimension becomes important later. The lower bound of 0.001 ensures that each dimension retains at least a minimum expressive power, allowing the system to have room for adjustment when the environment changes.

[0197] For example, in an extreme scenario, suppose the D8 "whether streaming output is supported" dimension has never been a key factor in successful matching in the first 500 calls; that is, the difference between the query and the hit in this dimension is the maximum value of 2 in all successful matches. In this case, the contribution of this dimension will continue to decline. After 500 updates... (The omitted term represents the cumulative sum of EWMA increment contributions from each iteration). After normalization... It just touched the lower bound constraint. Even if it continues to decay thereafter, the weight is still clamped at 0.001, preserving the minimum expressive power of this dimension. When a large number of calls requiring streaming output occur subsequently, the contribution of this dimension will rise again, and the weight will recover accordingly.

[0198] System Implementation Examples

[0199] like Figure 10 As shown, this application also provides a capability management and invocation system for multi-agent systems. The system includes a capability ontology management module, a capability registration center, a capability fingerprint encoding module, a multi-level hash index module, an inference matching engine, an invocation routing and execution module, and a feedback learning module. The above modules achieve asynchronous decoupled communication through message queues.

[0200] The capability ontology management module runs on the management node and is responsible for building and maintaining a hierarchical capability ontology tree, defining a multi-dimensional attribute space and its encoding rules, and broadcasting update notifications to all downstream modules via a message queue when the ontology changes. This module comprises four sub-components: a domain scanner, a dimension filter, an encoding engine, and a version controller. The capability ontology management module can be implemented by the processor executing instructions from memory.

[0201] The capability registry is deployed as a stateless microservice cluster, containing at least two service instances to achieve high availability. It is responsible for receiving capability declaration information from agents and performing structured validation. Internally, this module includes four sub-components: a declaration parser, a validation engine, a version manager, and an event publisher. The capability registry communicates with agents via a RESTful API and with downstream modules via a message queue. The capability registry can be implemented by a processor executing instructions from memory.

[0202] The capability fingerprint encoding module runs on the query service node and is responsible for performing grouped L2 normalization, weighted scaling, and Gaussian random projection matrix dimensionality reduction on the attribute vector to generate a capability fingerprint vector normalized to a unit hypersphere. This module internally comprises four sub-components: a normalizer, a weighted scaler, a projection matrix generator, and a spherical normalizer. It also subscribes to weight update messages published by the feedback learning module to synchronize the dimension and weight vectors in real time. The capability fingerprint encoding module can be implemented by the processor executing instructions from memory.

[0203] The multi-level hash index module runs on the query service node, with index data residing in memory, and is responsible for constructing indexes based on fingerprint vectors. It creates independent SimHash indexes and supports incremental updates. Internally, this module comprises four sub-components: a hash function manager, a bucket storage engine, a query executor, and an incremental updater. The hash function manager stores and manages... Each level contains a random hyperplane normal vector, and the bucket storage engine uses an in-memory hash map structure to store bucket data. The multi-level hash index module can be implemented by the processor executing instructions from memory.

[0204] The inference matching engine runs on the query service node and is deployed on the same machine as the multi-level hash index module to reduce communication latency. It is responsible for converting call requests into query fingerprints and performing a two-stage inference matching process (coarse screening plus fine ranking). This module internally comprises five sub-components: a request parser, a fingerprinter, a coarse screening executor, a fine ranking scorer, and a load collector. The load collector collects real-time load data from each agent at 1-second intervals via a heartbeat mechanism. The inference matching engine can be implemented by the processor executing instructions from memory.

[0205] The call routing and execution module is deployed as a stateless service, horizontally scalable, and communicates with the agent via a remote procedure call (RPC) protocol. It is responsible for initiating capability calls to the target agent based on a matching result list and managing the call lifecycle (including timeout detection and cascading degradation). Internally, this module comprises four sub-components: a routing decision maker, an RPC client pool, a timeout manager, and a degradation controller. The call routing and execution module can be implemented by the processor executing instructions from memory.

[0206] The feedback learning module runs on the management node, processing feedback data asynchronously to avoid impacting the real-time query path. It is responsible for updating the dimension weight vector and matching threshold using the EWMA algorithm based on the feedback information. This module internally comprises four sub-components: a feedback collector, a reward calculator, a contribution accumulator, and a weight publisher. After updating, the weight publisher broadcasts the new weight vector to all capability fingerprint encoding modules and inference matching engine instances via a message queue. The feedback learning module can be implemented by the processor executing instructions from memory.

[0207] It should be noted that in actual deployment, each of the above modules can be implemented by one or more processors executing program instructions stored in memory, and communication between modules can be accomplished through mechanisms such as message queues, remote procedure calls, or shared memory.

[0208] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit described above can be implemented in hardware.

[0209] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for capability management and invocation in a multi-agent system, characterized in that, include: Construct a hierarchical capability ontology, define a multi-dimensional attribute space, specify the attribute type, value range and encoding function for each attribute dimension, and generate the capability ontology definition; Receive capability declaration information submitted by the intelligent agent, perform structured verification on the capability declaration information according to the capability ontology definition, and generate a structured capability declaration record containing attribute vectors after the verification is passed; The attribute vector is grouped and normalized to eliminate the difference in dimensions. The normalized vector and the dimension weight vector are then weighted and scaled dimension by dimension. The weighted vector is mapped to a fixed-length fingerprint vector through a random projection matrix. The fingerprint vector is then normalized to a unit hypersphere. Based on the fingerprint vector, multiple independent hash indexes are constructed. Each hash index uses an independent family of random hyperplanes to divide the fingerprint vector space, and each fingerprint vector is mapped to a corresponding hash bucket. When a call request is received, the call request is transformed into a query fingerprint in the same space as the fingerprint vector. A coarse screening is performed through the multiple sets of independent hash indexes to obtain a set of candidate capabilities. Fine ranking and reasoning are performed on each candidate in the set of candidate capabilities to generate a list of matching results. The dimension weight vector is updated based on the call feedback information in the matching result list.

2. The method according to claim 1, characterized in that, The grouping normalization involves grouping the attribute vectors according to the ontology dimension, and performing L2 normalization on each group of encoded sub-vectors to make the contribution of each ontology dimension to the final vector equal.

3. The method according to claim 2, characterized in that, The random projection matrix is ​​a Gaussian random projection matrix, in which each element is independently sampled from a Gaussian distribution with a mean of zero and a variance equal to the reciprocal of the target dimension. The random projection matrix is ​​generated and fixed once during system initialization, and all agents share the same matrix. The fingerprint vector is L2 normalized to a unit hypersphere after projection, so that the inner product of two fingerprint vectors is equal to the cosine similarity.

4. The method according to claim 3, characterized in that, The dimension of the fixed-length fingerprint vector is bounded by the Johnson-Lindenstrauss lemma, which is proportional to the logarithm of the effective degrees of freedom in the capability vector set and inversely proportional to the square of the distance preservation error tolerance.

5. The method according to claim 1, characterized in that, Each hash function in the random hyperplane family generates a one-bit binary code by calculating the inner product sign of the fingerprint vector and the random hyperplane normal vector; multiple hash functions in each hash index are combined to generate a multi-bit hash code as the bucket address.

6. The method according to claim 5, characterized in that, The multiple independent hash indexes support incremental updates. When an agent comes online, its fingerprint vector is inserted into the corresponding bucket of each hash index. When an agent goes offline, its fingerprint vector is deleted from the corresponding bucket of each hash index. The time complexity of a single incremental update is linearly related to the number of hash index groups.

7. The method according to claim 1, characterized in that, The refined sorting reasoning includes: The cosine similarity between the query fingerprint and each candidate fingerprint vector is calculated as a similarity component. The proportion of constraints satisfied in the call request is calculated as a constraint satisfaction component. The real-time load status of each candidate agent is obtained as an availability component. The similarity component, the constraint satisfaction component, and the availability component are weighted and summed to obtain a comprehensive score.

8. The method according to claim 7, characterized in that, Before performing the fine-ranking inference, gating filtering is performed on the candidate capability set to discard candidates with negative cosine similarity and candidates with zero constraint satisfaction.

9. The method according to claim 1, characterized in that, The process of converting a call request into a query fingerprint includes two mutually exclusive modes: When the call request is submitted in a structured format, the field mapping is directly performed according to the ontology dimension to generate the required attribute vector; When the call request is submitted in a semi-structured format, the task description execution slots are filled based on the ontology dimension keyword dictionary, and structured constraints are injected to generate a requirement attribute vector.

10. The method according to claim 9, characterized in that, The dimensions that do not match the keywords in the slot filling are marked as wildcard dimensions. The method also includes calculating the proportion of wildcard dimensions. When the proportion of wildcard dimensions exceeds a preset threshold, the weights of all wildcard dimensions are temporarily set to zero. The weights of the remaining specified dimensions are renormalized and then fingerprinting and matching are performed.

Images