An AI agent-oriented multi-protocol interaction analysis method, device, medium and program product

Abstract

The application provides a multi-protocol interaction analysis method and device for an AI agent, a medium and a program product. The method comprises: loading a collection probe in the operating system kernel layer of a computing node where the AI agent runs; acquiring, by using the collection probe, multi-source data generated by the AI agent in the running process and the external system interaction, the multi-source data comprising network communication flow data and local pipeline communication flow data; performing data reorganization processing on the network communication flow data and the local pipeline communication flow data, restoring the streaming or fragmented interaction data to complete application layer protocol data; calling an analysis rule corresponding to the protocol type of the application layer protocol data to analyze and process the application layer protocol data, so as to extract interaction metadata and further construct an interaction link relationship corresponding to the AI agent. The application realizes full-link restoration of the multi-protocol and multi-path interaction behavior of the AI agent, and improves the overall observability and correlation analysis capability of the agent behavior.

Description

Technical Field

[0001] This application relates to the field of cloud-native security technology, and in particular to a multi-protocol interaction parsing method, device, medium and program product for AI intelligent agents. Background Technology

[0002] With the development of artificial intelligence technology, AI agents based on large language models are gradually being widely used in cloud-native environments. AI agents achieve a closed-loop process from task understanding, decision-making and planning to execution feedback by invoking large language models, external tools, and other agents. In this process, agents typically need to communicate with external systems through various interaction methods, including model invocation based on HTTP / HTTPS protocols, database access, and tool invocation via local commands or standard input / output pipes, thus forming a complex interaction system with multiple protocols and paths. To achieve effective management and security auditing of the agent's operational status, a comprehensive analysis and observation of the aforementioned interactive behaviors is urgently needed.

[0003] In existing technologies, the main methods for achieving system observability include application-layer software development kit (SDK)-based tracking schemes and network traffic-based monitoring schemes. Application-layer tracking relies on embedding specific components in business programs to collect interaction information, which has limitations such as strong intrusion into business code and difficulty in covering different implementation forms of intelligent agents. While network traffic-based monitoring can acquire some communication data, it struggles to parse the semantic content of encrypted communications such as HTTPS, resulting in the inability to obtain key information about model calls and tool interactions. Furthermore, in scenarios where AI agents call tools locally through standard input / output channels, existing network-based data acquisition methods cannot cover such interactive behaviors because this type of communication does not pass through the network protocol stack.

[0004] Therefore, data parsing of different protocol types usually adopts independent implementation methods, lacking a unified data modeling and association mechanism, which makes it difficult to establish effective correlation between multi-source interactive data, thus making it impossible to reconstruct the complete interaction link and resulting in obvious observation blind spots. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides a method, device, medium, and program product for parsing multi-protocol interaction of AI agents, which at least solves the problem that existing technologies are unable to uniformly parse the multi-protocol and multi-path interaction behavior of AI agents without intruding on business systems.

[0006] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0007] Firstly, some embodiments of this application provide a multi-protocol interaction parsing method for AI agents, including:

[0008] The acquisition probe is loaded into the kernel layer of the operating system of the computing node where the AI ​​agent runs;

[0009] The acquisition probe is used to acquire multi-source data generated by the AI ​​agent's interaction with external systems during operation. The multi-source data includes network communication stream data and local pipeline communication stream data.

[0010] Based on the kernel socket state or file descriptor attributes associated with the multi-source data, the transmission path type of the multi-source data is determined to identify whether the multi-source data belongs to a network communication path or a local pipe path. The network communication stream data and the local pipe communication stream data are then reassembled to restore the streaming or fragmented interactive data into complete application layer protocol data.

[0011] The protocol type of the application layer protocol data is identified, and the parsing rule corresponding to the protocol type is called to parse the application layer protocol data in order to extract the interaction metadata of the AI ​​agent;

[0012] Based on the interaction metadata, different interaction data are matched in time sequence and associated with calling relationships using preset association identifiers to construct an interaction link relationship corresponding to the AI ​​agent.

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

[0014] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform the multi-protocol interaction parsing method for AI agents as described above.

[0015] Thirdly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, wherein the computer program and / or instructions, when executed by a processor, implement the multi-protocol interaction parsing method for AI agents as described above.

[0016] Fourthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the multi-protocol interaction parsing method for AI agents as described above.

[0017] Compared with existing technologies, the solution provided in this application loads a collection probe at the operating system kernel layer to uniformly collect network communication data and local pipeline communication data generated during the operation of the AI ​​agent. This achieves non-intrusive acquisition of data from different interaction paths, avoiding the adaptation complexity and deployment cost issues caused by modifying business programs. Based on different transmission path types, multi-source data is reorganized in a targeted manner, restoring the originally scattered and fragmented streaming or segmented data into complete application layer protocol data. This overcomes the limitation of existing technologies that rely solely on network traffic analysis and cannot cover local inter-process communication. Furthermore, by optimizing the application layer protocol... The system performs unified protocol type identification and parsing on the data, transforming interactive data from different sources and formats into consistent interactive metadata. This enables unified modeling and semantic expression of multi-protocol data, enhancing the consistency and scalability of data processing. Furthermore, based on association identifiers, it performs time-series matching and call relationship association on various interactive metadata, constructing a complete intelligent agent interaction link relationship. This achieves full-link restoration of multi-protocol and multi-path interactive behaviors of AI agents, eliminating observation blind spots caused by fragmented data sources. It can also simultaneously reflect the interactive intent of the agent and its actual execution process, significantly improving the overall observability and correlation analysis capabilities of the agent's behavior. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other implementation methods can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a multi-protocol interaction parsing method for AI intelligent agents provided in an embodiment of this application;

[0020] Figure 2 This is a schematic diagram of a multi-protocol interaction logic for AI agents provided in an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0023] The following terms are used in this document.

[0024] AI agents are autonomous software entities based on artificial intelligence technology. They can perceive their environment by receiving input information and perform semantic understanding, decision-making, planning, and action execution based on that information to complete preset task objectives. AI agents are typically based on large language models or other intelligent models and possess a certain degree of autonomy and task execution capabilities. They can call external tools, access remote services, or interact with other intelligent agents, thereby forming a continuous task-oriented execution process.

[0025] The Extended Berkeley Packet Filter (eBPF) is a programmable technology mechanism that runs within the operating system kernel. This mechanism allows users to extend the functionality of the operating system kernel without modifying the kernel source code or loading kernel modules by loading a validated program into the kernel. eBPF programs typically execute in an event-driven manner and can be attached to critical locations such as system call paths, network protocol stacks, or kernel trace points, capturing and processing system behavior when relevant events are triggered. Based on this mechanism, efficient observation and data acquisition of the system's operation can be achieved in kernel space, making it widely applicable in scenarios such as system observability, performance analysis, and network monitoring.

[0026] A data acquisition probe is a program unit loaded onto the operating system kernel or user-space execution path based on the eBPF mechanism. It is used to capture target behaviors and generate corresponding behavioral event data. Data acquisition probes can be deployed in different locations depending on the target being acquired. For example, they can be mounted on the system call path to capture process execution and system call events, on the network data processing path to capture network communication events, or on the user-space function execution path to obtain application-layer interaction data. Through the configuration and scheduling of data acquisition probes, selective acquisition of specific processes, network connections, or protocol behaviors can be achieved, thereby obtaining multi-dimensional data related to agent behavior while ensuring system stability.

[0027] Some embodiments of this application relate to a multi-protocol interaction parsing method for AI agents. This method is applicable to computing nodes deployed in cloud-native or distributed computing environments, and is used to uniformly parse and reconstruct the interaction behavior of AI agents running on computing nodes. During task execution, AI agents typically need to interact with external systems in multiple ways, including calling remote services via network protocols and calling tools or executing commands via local inter-process communication mechanisms, thus forming a multi-protocol, multi-path interaction process. Since data from different interaction paths is scattered across the network protocol stack and the operating system, and some data is transmitted in streaming or fragmented form, existing technologies struggle to uniformly acquire and correlate related interaction behaviors. Therefore, this embodiment achieves unified modeling and full-link reconstruction of AI agent interaction behavior by uniformly collecting multi-source interaction data at the operating system kernel layer and parsing and correlating data from different protocols. (Refer to...) Figure 1 As shown, the method may include the following steps:

[0028] Step S1: Load the acquisition probe into the kernel layer of the operating system of the computing node where the AI ​​agent is running.

[0029] A computing node refers to the basic computing environment that supports the operation of an AI agent. It includes resources such as processors, memory, and operating systems, and can run AI agent programs as processes or containers. During operation, the AI ​​agent interacts with external systems through the computing node's operating system, including remote communication via network protocols and local interaction via inter-process communication mechanisms. Since all interactive behaviors of the AI ​​agent are ultimately implemented through the operating system kernel execution path, deploying a data collection probe at the operating system kernel layer of the computing node allows for the unified collection of network communication data and local inter-process communication data generated by the AI ​​agent without modifying its business programs. This enables complete acquisition and monitoring of multi-path interactive behaviors.

[0030] Probe programs for data acquisition are pre-deployed on the compute nodes and dynamically loaded into the operating system kernel execution environment during system operation via a user-mode loading component. The acquisition probes can be implemented using kernel-mode programmable mechanisms, allowing them to run in the kernel execution path by loading the pre-compiled probe programs into the kernel space. The loading process can be completed through interfaces provided by the operating system, and security checks are performed on the probe programs during loading to ensure their execution behavior complies with kernel runtime constraints.

[0031] After loading, the acquisition probe can be attached to the critical execution path of the operating system kernel and monitor the relevant execution process in an event-triggered manner. In some implementations, the critical execution path may include system call processing paths, network data processing paths, and inter-process communication related paths, thereby enabling the acquisition probe to cover different types of interactive behaviors generated by the AI ​​agent during operation. When the corresponding execution path is triggered, the acquisition probe can acquire data related to the current execution context, including data content information, execution entity identifier, and time information.

[0032] Furthermore, when the acquisition probe performs data acquisition, it can limit the acquisition scope based on preset filtering conditions. For example, it can filter target processes related to AI agents based on process identifiers or container identifiers, and only collect the execution behavior generated by the target processes, thereby improving the relevance of the acquired data and reducing system resource overhead.

[0033] Step S2: Use the acquisition probe to acquire multi-source data generated by the AI ​​agent's interaction with external systems during operation. The multi-source data includes network communication flow data and local pipeline communication flow data.

[0034] After the acquisition probe is loaded and mounted in the operating system kernel layer, it performs real-time monitoring and data capture of the interactive behaviors generated during the operation of the AI ​​agent when triggered in the corresponding execution path. Specifically, when the AI ​​agent communicates with remote services through network protocols or interacts with tool subprocesses through local inter-process communication mechanisms, the acquisition probe can obtain the corresponding data stream information in the kernel execution path, thereby forming multi-source data.

[0035] Multi-source data includes network communication stream data. This data can be acquired by a probe within the relevant execution paths of the network protocol stack, such as capturing the corresponding data content and context information during connection establishment, data transmission, and reception. In scenarios involving encrypted communication, the probe can also acquire the corresponding plaintext data before or after encryption, ensuring that subsequent parsing is based on readable data content.

[0036] Multi-source data also includes local pipe communication stream data. Local pipe communication stream data can be acquired by a collection probe within the execution path related to inter-process communication, such as capturing the corresponding data stream content when pipe read / write operations occur. Specifically, the collection probe can identify pipe file descriptors associated with the AI ​​agent process and monitor the data stream transmitted based on the pipe file descriptors, thereby acquiring the communication data generated by the interaction between the AI ​​agent and the tool subprocesses.

[0037] While acquiring network communication stream data and local pipeline communication stream data, the acquisition probe can also simultaneously acquire contextual information related to the data stream, including but not limited to process identifiers, thread identifiers, timestamp information, and communication direction identifiers, thereby providing auxiliary information for subsequent data reconstruction and protocol parsing.

[0038] During the data acquisition process, the acquisition probe can send the raw data to the user-space processing module via the data transmission mechanism between the kernel and user space for subsequent data reconstruction and protocol parsing. The entire loading and running process of the acquisition probe does not require modification of the AI ​​agent or its business program, nor does it interrupt its operation, thus achieving non-intrusive monitoring of the AI ​​agent's interactive behavior.

[0039] Step S3: Based on the kernel socket state or file descriptor attributes associated with the multi-source data, determine the transmission path type of the multi-source data to identify whether the multi-source data belongs to the network communication path or the local pipe path, and perform data reassembly processing on the network communication stream data and the local pipe communication stream data respectively to restore the streaming or fragmented interactive data into complete application layer protocol data.

[0040] Multi-source data typically exists in streaming or fragmented form, with each acquisition containing only a portion of the content, making it difficult to directly use for protocol parsing. Therefore, this embodiment identifies the transmission path type based on the file descriptor (FD) attribute or kernel socket state associated with the data, and maintains independent reassembly states for network paths and local pipe paths respectively, performing differentiated reassembly processing on the data.

[0041] For network communication stream data, when the data originates from a network communication path (e.g., socket interaction based on the TCP / IP protocol stack), session classification can be performed on data fragments based on the connection quadruple (source address, destination address, source port, destination port) or socket identifier. Out-of-order packets can be reordered using the collected TCP sequence number to restore the continuous byte stream. In cases of packet loss or retransmission, the kernel protocol stack's retransmission mechanism can be used to complete the data. In scenarios involving streaming responses, such as data streams based on Server-Sent Events (SSE) or HTTP chunked encoding, a dynamic buffer can be maintained to incrementally concatenate continuously arriving data fragments. The boundaries of complete packets can be identified based on data delimitation features in the application layer protocol (e.g., the "data:" prefix or specific end markers such as "[DONE]"), thereby reconstructing the complete request or response data.

[0042] Regarding the piped communication stream data, when it is identified that the data originates from a local inter-process communication path (e.g., an AI agent interacts with a tool subprocess via a pipe using standard input / output), since the piped data appears as an unbounded continuous byte stream in kernel mode, the continuously acquired data can be cached, and the data stream can be merged using file descriptors. In one specific implementation, data blocks can be captured based on read / write behavior at the Virtual File System (VFS) layer (e.g., vfs_read and vfs_write calls), and fragmented data generated from multiple read / write operations can be concatenated by maintaining a buffer. Simultaneously, the structural characteristics of application layer protocols can be utilized for frame segmentation. For example, for JSON-RPC-based structured interactive data, by scanning the opening curly braces "{" and closing curly braces "}" in the byte stream and combining this with a bracket nesting depth counting algorithm, complete JSON objects can be segmented from the continuous byte stream, thereby reconstructing the independent call messages.

[0043] Furthermore, during the reassembly of network communication flow data and local pipeline communication flow data, data fragments can be sorted and aligned using time information or execution context information to ensure the temporal consistency of the reassembly results. Simultaneously, abnormal or incomplete data fragments can be filtered or marked to improve the accuracy of subsequent protocol parsing.

[0044] Step S4: Identify the protocol type of the application layer protocol data and call the parsing rules corresponding to the protocol type to parse and process the application layer protocol data in order to extract the interaction metadata of the AI ​​agent.

[0045] In a preferred embodiment, the protocol type includes at least one of the following: an interaction protocol between an agent and a large language model, an interaction protocol between an agent and a tool, an interaction protocol between agents, and a model context protocol.

[0046] In one specific embodiment, refer to Figure 2 As shown, the AI ​​agent, acting as the central node of interaction, runs on the computing node and establishes interactive relationships with various external resources, thus forming a multi-path, multi-protocol interactive system. Specifically, the AI ​​agent can interact with model resources, which may include Large Language Model (LLM) Sources, such as Public LLM Services and Private LLM Services. During this interaction, the AI ​​agent sends inference requests to the large language model and receives response results, thereby forming an interaction protocol between the agent and the large language model. The interaction data may include model input information and model output results.

[0047] AI agents can interact with tool resources, which may include infrastructure tools (InfraTool), data processing tools (Data Tool), third-party service interfaces (SaaS API), Model Context Protocol Server (MCP Server), and local execution environments (Sandbox). During this interaction, the AI ​​agent invokes external tools to perform specific operations, such as API calls, data processing, or command execution, thus forming an interaction protocol between the agent and the tool. The interaction data may include tool call identifiers, call parameters, and execution result information.

[0048] AI agents can communicate with other AI agents, which may include planner agents and executor agents. In multi-agent collaborative scenarios, different AI agents can distribute tasks, synchronize states, and transmit results, thereby forming an interaction protocol between agents.

[0049] The interaction between AI agents and tool resources can also be achieved based on the Model Context Protocol (MCP). In one specific implementation, the MCP can support both HTTP-based and standard input / output-based transmission methods (MCP over HTTP), enabling AI agents to interact with tool services through a unified protocol mechanism and achieve bidirectional transmission of tool call requests and execution results.

[0050] In actual operation, the types of protocols involved in the AI ​​agent can be dynamically determined based on the task complexity. In some scenarios, when the AI ​​agent's function is relatively simple, its interaction behavior may only involve any one of the aforementioned protocol types; however, in complex task scenarios, the AI ​​agent usually needs to trigger two or more protocol types sequentially or simultaneously within the same task flow. For example, in a scenario where reasoning is performed based on a large language model and tools are invoked to perform operations, the AI ​​agent can first obtain the decision result through the interaction protocol between the agent and the large language model, and then execute the specific operation through the interaction protocol between the agent and the tool; in multi-agent collaborative scenarios, task collaborative processing can be further achieved through the interaction protocols between agents.

[0051] Furthermore, multi-protocol interaction can also manifest as a combination of different protocols in the time dimension or system level. For example, in the time dimension, different protocols are triggered sequentially according to the task execution order; at the system level, AI agents can interact with remote model services through network communication, and at the same time interact with tool subprocesses through local inter-process communication, thus forming multi-protocol parallel interaction behavior on different transmission paths.

[0052] In a preferred embodiment, when the protocol type is an interaction protocol between an agent and a large language model, in step S4, the parsing rules corresponding to the protocol type are invoked to parse the application layer protocol data to extract the interaction metadata of the AI ​​agent, specifically including:

[0053] Step S4A101: Use the acquisition probe to attach the function entry and exit points of the target encryption library to capture plaintext data before or after the interactive data is encrypted.

[0054] Specifically, considering that the interaction between AI agents and large language models is usually completed through secure transmission connections, request data is encrypted by an encryption library before being sent, and response data is decrypted by the encryption library after being returned. Therefore, acquisition probes can be deployed at the boundaries of key functions in the user-space encryption library to intercept the plaintext request before entering the encryption process and the plaintext response after decryption. In one specific implementation, acquisition probes can be attached to the write function entry and read function exit of the target encryption library based on a user-space dynamic tracking mechanism, thereby obtaining the plaintext request data sent to the large language model and the plaintext response data returned by the large language model, respectively. Taking the OpenSSL library as an example, SSL_write is used to write data to the SSL connection, and SSL_read is used to read application data from the SSL connection. Uprobes-based tracing can be attached to the boundaries of user-space functions, thereby enabling dynamic observation of the relevant function call process. In this way, readable plaintext data required for subsequent protocol parsing can be obtained without breaking the encryption mechanism of the transmission link.

[0055] Step S4A102: Perform application layer protocol parsing on the plaintext data to obtain the corresponding request and response data.

[0056] Specifically, after obtaining plaintext data, it can be parsed according to the application layer protocol format used for interaction between the AI ​​agent and the large language model. In one implementation, for large language model calls based on HTTP or HTTPS, the request line, request header, and message body in the plaintext can be separated, and information such as the request method, access path, and content type can be identified to determine whether the current data is a request or response message for a large language model call. When the content type is identified as structured text, the corresponding request and response message bodies can be further extracted. In scenarios involving HTTP / 2 multiplexing or streaming, the response data can also be merged by combining stream identifiers or segment arrival order to restore logically complete response content. Through this step, the original plaintext data is converted into request and response data that can be directly used for semantic extraction.

[0057] Step S4A103: Perform structured parsing on the request data and response data, extract model input information from the request data, and extract model output information and tool call instruction information from the response data to form the interactive metadata of the AI ​​agent.

[0058] Specifically, when parsing the request data, the model identifier corresponding to the model call can be identified from the request message body, and the input content representing the inference context can be extracted. In one specific embodiment, the model input information may include system prompts, user input, and historical dialogue information; when the request message body also contains tool definitions that can be called by the model, the relevant tool description information can also be extracted. When parsing the response data, the model output text can be extracted from the response message body, and it can be identified whether it contains tool call instructions; in some implementations, resource consumption information related to the call process, such as token statistics, can also be further extracted. For streaming response scenarios, incremental concatenation can be used to merge continuously returned data fragments before field extraction; for response content exceeding a preset threshold in length, only key information or statistical information used for behavior analysis can be retained, without having to retain all text content. Through the above parsing, the original large language model call data can be transformed into structured interaction metadata, which can include at least one or more of model input information, model output information, tool call instruction information, and resource consumption information, thereby providing a foundation for subsequent interaction association and link construction.

[0059] In a preferred embodiment, for long text data that may occur during the interaction between the AI ​​agent and the large language model, in addition to structured parsing, a long text processing strategy can be executed on the request data and response data to reduce data processing overhead and improve parsing efficiency while ensuring that key semantic information can be extracted.

[0060] Specifically, when the length of the requested data exceeds a preset threshold, only the initial portion of the requested data used to characterize the semantics of the model input can be retained. The request message body can be truncated, retaining only data within a preset length range, for example, prioritizing the retention of data segments containing system prompts and user input information, as a basis for subsequent semantic analysis.

[0061] When the interaction process corresponding to the response data involves long sessions or large amounts of data, the response data can be summarized. In one specific implementation, instead of saving the entire response text content, statistical information that reflects the model's execution process, such as indicators related to resource consumption, can be extracted and recorded as part of the interaction metadata.

[0062] When response data is returned in a streaming manner, incremental splicing can be performed on the data segments that arrive in segments. Specifically, a buffer can be maintained in user space to splice consecutively arriving data segments in the order of arrival. When a preset end marker is detected or the integrity judgment condition is met, the spliced ​​data is used as complete response data in subsequent structured parsing.

[0063] Furthermore, in the process of implementing the above long text processing strategy, the ratio of retained data content to statistical information can be dynamically adjusted according to different data types or parsing requirements, thereby achieving a balance between data integrity and processing efficiency.

[0064] By employing the aforementioned long text processing strategies, the consumption of system resources by large-scale text data can be effectively reduced without affecting the extraction of key semantic information, thereby improving the real-time performance and scalability of AI agent interaction data parsing.

[0065] In the technical solution provided in this embodiment, through steps S4A101 to S4A103, the plaintext interactive data is obtained before or after data encryption, and then subjected to application layer protocol parsing and semantic structuring processing. This restores the original transmitted data to request and response data with clear semantic boundaries, further extracting key content such as model input information, model output information, and tool call instructions, thereby forming computable and associative interactive metadata. Thus, semantic-level reconstruction of the agent's reasoning process can be achieved, establishing the correlation between model call intent and response results. This effectively solves the problem of semantic invisibility in the interaction process of large language models, significantly improving the parsing capability and observability of interactive behavior for this type of protocol.

[0066] In a preferred embodiment, when the protocol type is an interaction protocol between an agent and a tool, step S4 involves calling the parsing rules corresponding to the protocol type to parse the application layer protocol data and extract the AI ​​agent's interaction metadata, specifically including:

[0067] Step S4B101: Identify the tool interaction path corresponding to the application layer protocol data. The tool interaction path includes at least one of the following: remote interface access path, database communication protocol access path, and local system command path.

[0068] Specifically, the path type of the current interaction can be determined based on the transmission characteristics, message format characteristics, access target characteristics, and execution context characteristics in the application layer protocol data. When the interaction data contains characteristic information such as URL interface access address, HTTP request method, or interface parameters, it can be determined as a remote interface access path; when the interaction data presents a database communication protocol interaction format, or the parsed result contains SQL query statements and query parameters, it can be determined as a database communication protocol access path; when the interaction behavior corresponds to local process execution activity, and command call behavior can be identified in the execution context, it can be determined as a local system instruction path. Through this step, the category of tool interaction behavior can be determined in advance under a unified parsing framework, providing a basis for subsequent path-based differentiated parsing rules.

[0069] Step S4B102: In response to the identification of the remote interface access path, the application layer protocol data is parsed to determine the corresponding calling interface identifier and the interface calling information is extracted. The interface calling information includes: the request method, request parameters and response content associated with the calling interface identifier.

[0070] Specifically, API call behavior can be structurally parsed based on the request path, request method, request headers, and message body content in the application layer protocol data. In one specific implementation, the API endpoint being called can be identified from the request path as the API call identifier, the call action type (such as GET, POST, PUT, DELETE, etc.) can be identified from the request method, and the request parameters and response content associated with the API call identifier can be further extracted to form API call information. The API call information includes at least the API call identifier, request method type, request parameters, and response content.

[0071] In some implementations, anomaly detection of interface call behavior can also be performed based on interface call information. For example, high-risk operation interfaces, including deletion interfaces or resource modification interfaces, can be identified based on the interface call identifier; statistical analysis of interface call frequency can also be performed based on time windows to identify abnormally high-frequency call behavior. Through the above analysis and detection processing, not only can the interface call process of the AI ​​agent be reconstructed, but also potential risky operations can be identified, thereby enhancing the ability to analyze tool interaction behavior.

[0072] Step S4B103: In response to the identification of the database communication protocol access path, the application layer protocol data is parsed to extract database query information, which includes: query statement text and query parameters.

[0073] Specifically, the application-layer data transmitted during database communication protocol interactions can be parsed. Database communication protocols include MySQL or PostgreSQL, among others. In one implementation, SQL statement text can be extracted from the database request message, and the corresponding query parameters can be identified to form database query information. Simultaneously, the query results can be parsed in conjunction with the database response message to extract information such as the result set size, the number of returned records, or the result set size, further enriching the semantic expression of the database query information.

[0074] In some implementations, security checks can also be performed based on the SQL statement text, such as identifying dangerous statement patterns (including data-damaging operations such as DROP TABLE and TRUNCATE), detecting the risk of full table scans, and identifying SQL injection characteristics (such as query statements containing logical identity expressions), thereby achieving risk perception of database access behavior.

[0075] Through the above analysis and detection processes, not only can the structured extraction of database interaction semantics be achieved, but also potential risky operations can be identified, thereby enhancing the ability to analyze and perceive the database access behavior of AI agents.

[0076] Step S4B104: In response to the identification of the local system command path, the application layer protocol data is parsed based on the process execution behavior to extract command execution information, which includes: command identifier and execution parameters.

[0077] Specifically, in local command execution scenarios, AI agents typically trigger tool subprocesses or execute system commands as processes. Therefore, the interaction data can be parsed by combining the process execution context. In one implementation, corresponding execution information can be obtained through process behavior monitoring. For example, command execution behavior can be captured based on process-related system calls (including execve calls), and the command identifier and execution parameters of the executed command can be extracted from them.

[0078] Furthermore, by combining contextual information such as process identifiers, parent-child process relationships, and execution time, a correlation can be established between command execution behavior and the AI ​​agent, thereby forming complete command execution information. Through the above parsing and processing, the original low-level system call behavior can be transformed into structured operation data with clear semantic meaning, thus accurately reflecting the actual operation content of the AI ​​agent in the local execution environment.

[0079] Step S4B105: Determine at least one of the obtained interface call information, database query information, and command execution information as the interaction metadata of the AI ​​agent.

[0080] Specifically, when tool interaction involves only a single path, the information extracted from that path can be directly used as the AI ​​agent's interaction metadata. When tool interaction involves multiple paths, the interface call information, database query information, and command execution information extracted from different paths can be uniformly organized and merged to form a structured set of interaction metadata. Through this step, heterogeneous tool interaction data originally scattered across different interaction paths is uniformly converged into structured interaction metadata, providing data support for subsequent interaction link construction, behavior auditing, and anomaly detection.

[0081] In the technical solution provided in this embodiment, steps S4B101 to S4B105 are used to identify the interaction behavior between the AI ​​agent and the tool, achieving a unified classification of different interaction forms such as remote interface access, database access, and local command execution. Based on this, interface call parsing, database statement parsing, and process execution parsing are performed for different interaction paths, restoring the original heterogeneous interaction data into interface call information, database query information, and command execution information with clear semantic boundaries, thereby forming structured interaction metadata. Thus, not only is unified modeling of multi-path tool interaction behavior achieved, but high-risk interface calls, dangerous SQL statements, and abnormal command execution behavior can also be identified simultaneously during the parsing process, effectively improving the observability, parsability, and security analysis capabilities of AI agent tool call behavior.

[0082] Since a complete task in a multi-agent system typically corresponds to multiple consecutive interactions between multiple agents, it is necessary to correlate application-layer protocol data scattered across different interaction processes to generate interaction metadata that reflects the collaborative relationships between multiple agents. In a preferred embodiment, when the protocol type is an interaction protocol between agents, step S4 involves calling the parsing rules corresponding to the protocol type to parse the application-layer protocol data and extract the interaction metadata of the AI ​​agents, specifically including:

[0083] Step S4C101: Identify whether there is an association identifier used to identify the request link in the header information of the application layer protocol data.

[0084] Specifically, the header information of the application layer protocol data carrying interactions between intelligent agents can be examined to determine whether it contains an association identifier used for distributed tracing. When the interaction protocol is based on HTTP, the presence of a field identifying the call chain can be checked in the HTTP request header; when the interaction protocol is based on gRPC (a remote procedure call protocol based on HTTP / 2), the presence of the corresponding field can be checked in the metadata field of the request. The association identifier can be transmitted through header fields or metadata fields in the application layer protocol, continuously carried during request initiation and forwarding, thereby enabling multiple interaction processes in the same call chain to be associated based on the association identifier. Through this step, it is possible to identify whether the current interaction already carries an association identifier representing tracing information before the application layer protocol data enters the chain association processing.

[0085] Step S4C102: If an association identifier exists, extract the association identifier from the header information.

[0086] Specifically, when a field for identifying the request chain is detected in the application layer protocol data, its value can be extracted as the association identifier for the current interaction behavior and used as the basis for associating subsequent interaction data. In one implementation, the extracted association identifier can correspond to a global tracking identifier or a parent-child call relationship identifier in a certain call chain, thereby enabling the current request data and subsequent response data, as well as downstream forwarding request data, to establish a correspondence within the same logical chain.

[0087] Step S4C103: If the association identifier is missing, generate a globally unique association identifier and inject application layer protocol data, and establish a binding relationship between the association identifier and the current interaction behavior.

[0088] Specifically, in some multi-agent systems, requests may not carry a link tracing identifier when initiated, or the existing header information may be insufficient to support complete link association. In such cases, a globally unique association identifier can be generated by a user-space agent or intermediate processing component and written into the header information of the current application layer protocol data. The association identifier can be injected before forwarding the request, and the mapping relationship between the association identifier and the current interaction behavior can be recorded simultaneously, such as recording the corresponding source agent, target agent, request time, and request context information. Even if the original request does not carry a link identifier, the system can still establish a unified call link number for it, thereby ensuring that subsequent cross-agent interaction data can be continuously traced.

[0089] Step S4C104: Associate multiple application layer protocol data with the same association identifier to construct a cross-agent call chain relationship.

[0090] Specifically, request data, response data, and forwarded data carrying the same association identifier can be grouped into the same logical call chain, and related data can be aggregated and associated based on time sequence, request direction, or upstream and downstream call relationships. Multiple interaction data under the same association identifier can be sorted based on the request initiation time and response return time, and a cross-agent call chain topology can be generated according to the call relationship. For example, when the planning agent first sends a request to the execution agent, and the execution agent then initiates sub-requests to other agents, these multiple interactions can be chained into the same call chain based on the same association identifier. Through this step, the originally independent interaction data scattered among multiple agents is organized into a call chain relationship with a clear upstream and downstream relationship, thereby achieving a holistic reconstruction of the multi-agent collaboration process.

[0091] Step S4C105: Based on the header feature information in the application layer protocol data, perform fingerprint recognition on the intelligent agents participating in the interaction to determine the intelligent agent identifier, and generate interaction relationship data between intelligent agents based on the call link relationship and the intelligent agent identifier to form the interaction metadata of the AI ​​intelligent agent.

[0092] Specifically, feature fields with subject identification significance can be extracted from the header information of application layer protocol data, such as client identification information in standard header fields or frame identification information in custom headers. Based on these feature fields, the type of agent, agent frame, or agent instance identifier currently participating in the interaction can be identified. In one implementation, header features similar to User-Agent, or frame identification fields carried in custom headers, can be used to distinguish different agents. The identified agent identifiers are then mapped to the call chain relationship constructed in step S4C104, thereby generating interaction relationship data representing the mutual calls between agents. This interaction relationship data can be further organized into a session relationship graph or call topology to describe the collaboration mode of multiple agents in the same task. This not only reveals which interactions occurred in the chain but also clarifies the specific agent subject corresponding to each interaction node, thus forming interaction metadata that reflects the collaborative relationships of multiple agents.

[0093] In the technical solution provided in this embodiment, through steps S4C101 to S4C105, multiple application layer protocol data with the same association identifier are associated to construct a cross-agent call chain relationship, thereby reconnecting and restoring the originally scattered interaction process. By fingerprinting the header feature information in the application layer protocol data, the identifiers of the intelligent agents participating in the interaction are determined, and the interaction relationship data between intelligent agents is generated in combination with the call chain relationship. Thus, not only is the complete restoration of the multi-agent call chain achieved, but the intelligent agent subject corresponding to each interaction node can also be clearly identified, effectively improving the observability, traceability, and relationship analysis capabilities of the multi-agent collaboration process.

[0094] In a preferred embodiment, when the protocol type is a model context protocol and is based on HTTP transmission, step S4 involves calling the parsing rules corresponding to the protocol type to parse the application layer protocol data and extract the interaction metadata of the AI ​​agent, specifically including:

[0095] Step S4D1101: Perform HTTP protocol parsing based on application layer protocol data to obtain the corresponding first remote call message body.

[0096] Server-Sent Events (SSE) is a one-way streaming communication mechanism based on the HTTP protocol, used by a server to continuously push data to a client. Under this mechanism, the server establishes a persistent HTTP connection and sends data to the client in segments as an event stream using a preset data format. The client can continuously receive data without repeatedly initiating requests.

[0097] During SSE transmission, the response data returned by the server is typically identified using the text / event-stream type and output as a text stream segment by segment. Each data segment is usually identified by a preset prefix, such as "data:" as the start marker of the data field, and different data segments are separated by newline characters, thus forming a continuous data stream structure. At the end of the data transmission, the termination of the streaming response can be indicated by a preset end marker (such as a specific end character).

[0098] In this embodiment, when the model context protocol is based on HTTP transmission and uses a streaming return method, the application layer protocol data can be carried in SSE format. Since this type of data is returned continuously in segments, each data segment is distinguished by a preset separator and contains field information used to identify the data content. Therefore, during the parsing process, it is necessary to incrementally concatenate the received multiple data segments and identify the complete message boundaries based on the structural features in the data segments, thereby reconstructing the complete remote call message body.

[0099] Furthermore, it identifies whether the message content meets the JSON format requirements and determines the message content that meets the conditions as the first remote call message body.

[0100] Step S4D1102: Perform structured parsing on the first remote call message body to obtain the corresponding remote call request data and remote call response data.

[0101] Specifically, the first remote call message body can be parsed at the field level to identify its semantic role in the remote call process. When the first remote call message body contains a call method field and a parameter field, it can be identified as remote call request data; when the first remote call message body contains a call result field, it can be identified as remote call response data.

[0102] Step S4D1103: Extract the tool call identifier and call parameters from the remote call request data, and extract the tool execution result from the remote call response data to form the interactive metadata of the AI ​​agent.

[0103] Specifically, when parsing remote call request data, a method identifier representing the tool call behavior can be extracted, along with the corresponding parameter information. When the method identifier represents a tool call, the tool name and input parameters can be further extracted from the parameter information. When parsing remote call response data, the tool execution result can be extracted from the response message to reflect the execution status of the tool call.

[0104] In the technical solution provided in this embodiment, through steps S4D1101 to S4D1103, for HTTP communication scenarios based on server-sent events, the model context protocol interaction data based on HTTP and expressed in JSON format is gradually restored from the original transmitted data into structured interaction metadata with clear call semantic boundaries. This enables accurate parsing and unified representation of the tool call behavior initiated by the AI ​​agent through the model context protocol, improving the observability, parsability, and subsequent correlation analysis capabilities of this type of protocol interaction process.

[0105] In a preferred embodiment, when the protocol type is a model context protocol and is based on standard input / output transmission, since this type of interaction transmits data through the standard input / output channel between the agent process and the tool subprocess, and the relevant data does not pass through the network protocol stack, it is difficult to obtain it through network packet capture. Therefore, this embodiment restores and parses this type of interaction process by identifying the pipe file descriptor, collecting pipe read / write data, and performing frame reassembly. In step S4, the parsing rules corresponding to the protocol type are called to parse the application layer protocol data to extract the interaction metadata of the AI ​​agent, specifically including:

[0106] Step S4D1201: Identify the inter-process communication pipe associated with the AI ​​agent process and determine the file descriptor corresponding to the inter-process communication pipe.

[0107] Specifically, in scenarios where an AI agent launches a tool subprocess via a pipe, the AI ​​agent process and the tool subprocess typically establish a data transmission channel through standard input and standard output. In this case, the pipe object corresponding to the inter-process communication process can be identified, and the file descriptor corresponding to the pipe object can be further determined. In a specific example, the target pipe file descriptor connecting the AI ​​agent parent process and the tool subprocess can be determined by monitoring system events related to pipe creation or by reading the process file descriptor mapping relationship. The standard input file descriptor used to send requests and the standard output file descriptor used to receive responses can be used as file descriptors, thus providing a location basis for subsequent data acquisition.

[0108] Step S4D1202: Based on file descriptors, collect data read and write behavior in the inter-process communication pipe to obtain streaming data generated by the interaction between the AI ​​agent and the tool subprocess.

[0109] Specifically, after identifying the file descriptor, a data acquisition probe can be mounted on the read / write path of the virtual file system layer to monitor data read / write behavior related to the file descriptor. A system call probe can be set at the file system read / write interface; when the file descriptor corresponding to the current read / write operation is detected, and the current process belongs to a process related to the AI ​​agent, data acquisition is triggered. In this way, request data sent by the AI ​​agent to the tool subprocess via standard input and response data returned by the tool subprocess to the AI ​​agent via standard output can be obtained from the continuous pipeline read / write process. Since this type of data usually arrives in segments as a byte stream, the data acquired in this step can be represented as streaming data.

[0110] Step S4D1203: Perform frame reassembly processing on the streaming data to restore the complete second remote call message body from the streaming data.

[0111] Specifically, since data transmitted via standard input / output is represented as a continuous byte stream in kernel space, and a single read / write operation does not necessarily correspond to a complete call message, it is necessary to buffer, concatenate, and identify boundaries of multiple data segments. In one implementation, a buffer corresponding to a file descriptor can be maintained in user space. Continuously acquired data segments are incrementally concatenated according to their arrival order, and the boundaries of the complete message are identified based on preset framing parsing rules. For the JSON-RPC message format commonly used in model context protocols, boundary determination can be performed using the structural characteristics of JSON objects. For example, by identifying the object's start and end markers and combining this with bracket level counting, multiple data blocks in the continuous byte stream can be segmented to reconstruct the complete JSON object, which is then identified as the second remote call message body.

[0112] Step S4D1204: Perform structured parsing on the second remote call message body to extract the tool call identifier, call parameters, and tool execution results to form the interactive metadata of the AI ​​agent.

[0113] Specifically, the request and response portions of the second remote call message body can be parsed separately. When the second remote call message body corresponds to a request message, the method identifier representing the tool call behavior can be extracted, and further, the call parameters related to the method identifier, such as the tool name and tool input parameters, can be extracted. When the second remote call message body corresponds to a response message, the tool execution result can be extracted. Through the above processing, the originally fragmented local standard input / output interaction data can be transformed into structured interaction metadata. The interaction metadata can include at least one or more of the following: tool call identifier, call parameter information, and tool execution result information, thereby providing basic data for subsequent interaction link construction and behavior analysis.

[0114] In the technical solution provided in this embodiment, through steps S4D1201 to S4D1204, the local pipeline interaction process that does not go through the network protocol stack can be identified, collected, reassembled and parsed, the originally invisible standard input and output interaction data can be restored into a remote call message body with clear semantic boundaries, and further extracted to form structured interaction metadata, thereby realizing effective perception and unified representation of the local tool call behavior of AI intelligent agents.

[0115] Step S5: Based on the interaction metadata, use the preset association identifier to match the time sequence of different interaction data and associate the calling relationship to construct the interaction link relationship corresponding to the AI ​​agent.

[0116] Interaction metadata can originate from parsing results under different protocol types and transmission paths, including but not limited to model input information, model output information, and tool call command information generated between the agent and the large language model; interface call information, database query information, and command execution information generated between the agent and the tool; and call chain information and agent identification information generated between agents. To facilitate subsequent chain construction, interaction metadata from different sources can be merged and stored according to a unified data organization method, and each piece of interaction metadata can be recorded with its corresponding timestamp information, source subject information, target subject information, interaction direction information, and associated identifier.

[0117] Multiple pieces of interactive metadata can be categorized based on association identifiers, identifying data sets with the same association identifier as belonging to the same request link or the same task context. This method allows data originally scattered across network communication, local pipeline communication, and multi-party interactions to be consolidated into a unified link.

[0118] After classification, time sequence matching can be performed on data sets belonging to the same associated identifier. Specifically, the interaction metadata can be sorted according to the order of occurrence based on the timestamp information carried by each interaction metadata, thereby determining the execution sequence of each interaction event in the same request chain. In one implementation, the sending time of the model inference request can be used as the starting point of the chain, and the model response return time, tool call initiation time, tool execution completion time, and multi-agent forwarding time can be arranged sequentially to obtain an interaction sequence with a time sequence relationship. If multiple concurrent branches exist within the same time window, they can be further grouped in parallel by combining the source subject and target subject information to reflect the concurrent call structure in the task execution process.

[0119] Based on time sequence matching, call relationship associations can be performed on interactive metadata under the same association identifier. Specifically, the upstream and downstream call relationships between different interactive events can be determined based on the source subject information, target subject information, call type, and input-output correspondence in the interactive metadata. For example, when a model output contains a tool call instruction, and subsequently, corresponding interface call information, database query information, or command execution information appears under the same association identifier, it can be determined that the latter is a downstream execution behavior triggered by the former. When interactive metadata between agents indicates that the planning agent sends a task request to the execution agent, and subsequent interactive metadata shows the execution agent calling a tool or accessing a model, it can be determined that these downstream interactions belong to the subsequent operations of the execution agent after receiving the task. In this way, the originally scattered interactive events can be further elevated from simple time series into a link structure with clear causal and call relationships.

[0120] To more clearly characterize the link relationships, interaction link relationship data can be constructed based on the time sequence matching results and the call relationship association results. The interaction link relationship data can be represented in the form of link nodes and edge relationships, where nodes represent a single interaction event or a single interaction subject, and edges represent call relationships, trigger relationships, or forwarding relationships between preceding and subsequent events. For example, "the agent initiates an inference request to the large language model" can be identified as the first node, "the model returns a tool call instruction" as the second node, and "the agent accesses an external interface according to the tool call instruction" as the third node. Sequential trigger relationships can then be established between the first node and the second node, and between the second node and the third node, respectively, thereby generating a complete interaction link relationship.

[0121] In a specific example, after receiving user input, the AI ​​agent first sends an inference request to the large language model, forming the first piece of interaction metadata. The large language model returns a response containing a tool invocation instruction, forming the second piece of interaction metadata. Subsequently, the AI ​​agent sends a call request to an external service interface based on the tool invocation instruction, forming the third piece of interaction metadata. The interface returns the execution result, forming the fourth piece of interaction metadata. If all four pieces of interaction metadata carry the same association identifier, they can be sorted based on timestamps, and then, based on the semantic relationship that "the model response contains a tool invocation instruction," a call relationship can be established between the second and third pieces of interaction metadata, ultimately forming a complete interaction chain relationship of "user input → model inference → tool invocation → result return."

[0122] In another specific example, in a multi-agent system, the planning agent first generates a task plan and sends the subtasks to the execution agent, forming the first interaction metadata. The execution agent then calls a local tool subprocess to execute the command, forming the second interaction metadata. After the command is executed, the execution agent returns the processing result to the planning agent, forming the third interaction metadata. If these three interaction metadata carry the same association identifier, they can be merged into the same link, and an interaction link relationship of "planning agent → execution agent → local tool → execution agent → planning agent" can be constructed based on the source agent, target agent, and time sequence.

[0123] In some implementations, abnormal nodes or edges in the link can be marked when constructing the interaction link relationship. For example, when there is a model output tool call instruction under the same association identifier but no corresponding tool execution information is detected, the position can be marked as an execution breakpoint; when an interface call returns an error code or a command execution information in the same link indicates execution failure, the relevant node can also be marked as an abnormal node, thereby providing a basis for subsequent anomaly analysis and auditing.

[0124] By introducing association identifiers to merge multiple interaction data belonging to the same task or request chain, and sorting each interaction event based on time sequence, while combining the source subject, target subject, and interaction type information in the interaction metadata to establish the calling relationship between events, the originally independent interaction data is linked into a complete interaction chain with temporal and causal relationships. Through this step, not only is the overall behavioral trajectory of the AI ​​agent in the execution of complex tasks restored, but the upstream and downstream relationships and cross-subject collaboration relationships between different interaction links are also clarified, providing a unified and complete data foundation for subsequent behavior analysis, anomaly detection, and security auditing.

[0125] In summary, the multi-protocol interaction parsing method for AI agents provided in this application loads a collection probe at the operating system kernel layer to uniformly collect network communication data and local pipeline communication data generated during the operation of the AI ​​agent. This achieves non-intrusive acquisition of data from different interaction paths, avoiding the adaptation complexity and deployment cost issues caused by modifying business programs. Based on different transmission path types, it performs targeted reorganization processing on multi-source data, restoring the originally scattered and fragmented streaming or segmented data into complete application layer protocol data, thus overcoming the limitation of existing technologies that rely solely on network traffic analysis and cannot cover local inter-process communication. Furthermore, it enables... By uniformly identifying and parsing application layer protocol data, interactive data from different sources and in different formats are transformed into structurally consistent interactive metadata, achieving unified modeling and semantic expression of multi-protocol data and enhancing the consistency and scalability of data processing. Furthermore, based on association identifiers, various interactive metadata are matched in sequence and associated with call relationships to construct a complete intelligent agent interaction link relationship. This enables the full-link restoration of multi-protocol and multi-path interactive behaviors of AI agents, eliminating the observation blind spots caused by fragmented data sources, and simultaneously reflecting the interactive intent of the agent and its actual execution process, significantly improving the overall observability and correlation analysis capabilities of the agent's behavior.

[0126] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0127] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices.

[0128] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform a multi-protocol interaction parsing method for AI agents as provided in any one or more of the above embodiments. Figure 3An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0129] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.

[0130] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0131] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0132] In this embodiment, a computer-readable medium stores a computer program / instruction, which, when executed by a processor, implements a multi-protocol interaction parsing method for AI agents provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The computer-readable medium carries one or more computer-readable instructions.

[0133] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0134] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0135] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0136] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0137] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0138] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0139] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0140] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0141] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. Terms such as "first," "second," etc., are used only to distinguish descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0142] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology 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, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A multi-protocol interaction parsing method for AI intelligent agents, characterized in that, include: The acquisition probe is loaded into the kernel layer of the operating system of the computing node where the AI ​​agent runs; The acquisition probe is used to acquire multi-source data generated by the AI ​​agent's interaction with external systems during operation. The multi-source data includes network communication stream data and local pipeline communication stream data. Based on the kernel socket state or file descriptor attributes associated with the multi-source data, the transmission path type of the multi-source data is determined to identify whether the multi-source data belongs to a network communication path or a local pipe path. The network communication stream data and the local pipe communication stream data are then reassembled to restore the streaming or fragmented interactive data into complete application layer protocol data. The protocol type of the application layer protocol data is identified, and the parsing rule corresponding to the protocol type is called to parse the application layer protocol data in order to extract the interaction metadata of the AI ​​agent; Based on the interaction metadata, different interaction data are matched in time sequence and associated with calling relationships using preset association identifiers to construct an interaction link relationship corresponding to the AI ​​agent.

2. The multi-protocol interaction parsing method for AI intelligent agents according to claim 1, characterized in that, The protocol types include at least one of the following: interaction protocols between agents and large language models, interaction protocols between agents and tools, interaction protocols between agents, and model context protocols.

3. The multi-protocol interaction parsing method for AI intelligent agents according to claim 1 or 2, characterized in that, When the protocol type is an interaction protocol between an agent and a large language model, the step of calling the parsing rules corresponding to the protocol type to parse the application layer protocol data and extract the interaction metadata of the AI ​​agent includes: The acquisition probe is used to attach the function entry and exit points of the target encryption library to capture plaintext data before or after the interactive data is encrypted. The plaintext data is parsed using an application layer protocol to obtain the corresponding request and response data; The request data and response data are structured and parsed to extract model input information from the request data and model output information and tool call instruction information from the response data, so as to form the interactive metadata of the AI ​​agent.

4. The multi-protocol interaction parsing method for AI intelligent agents according to claim 1 or 2, characterized in that, When the protocol type is an interaction protocol between an agent and a tool, the step of calling the parsing rule corresponding to the protocol type to parse the application layer protocol data to extract the interaction metadata of the AI ​​agent includes: Identify the tool interaction path corresponding to the application layer protocol data, wherein the tool interaction path includes at least one of the following: remote interface access path, database communication protocol access path, and local system command path; In response to the identification of the remote interface access path, the application layer protocol data is parsed to determine the corresponding call interface identifier and the interface call information is extracted. The interface call information includes: the request method, request parameters and response content associated with the call interface identifier. In response to the identification of the database communication protocol access path, the application layer protocol data is parsed to extract database query information, which includes: query statement text and query parameters; In response to the identification of the local system instruction path, the application layer protocol data is parsed based on the process execution behavior to extract command execution information, which includes: command identifier and execution parameters; At least one of the obtained interface call information, database query information, and command execution information is determined as the interaction metadata of the AI ​​agent.

5. The multi-protocol interaction parsing method for AI intelligent agents according to claim 1 or 2, characterized in that, When the protocol type is an interaction protocol between intelligent agents, the step of calling the parsing rule corresponding to the protocol type to parse the application layer protocol data to extract the interaction metadata of the AI ​​intelligent agent includes: Identify whether the header information of the application layer protocol data contains an associated identifier used to identify the request link; If the association identifier exists, then extract the association identifier from the header information; If the association identifier is missing, a globally unique association identifier is generated and injected into the application layer protocol data, and a binding relationship is established between the association identifier and the current interaction behavior. Associate multiple application layer protocol data with the same association identifier to construct cross-agent call chain relationships; Fingerprint recognition is performed on the intelligent agents participating in the interaction based on the header feature information in the application layer protocol data to determine the intelligent agent identifier, and interaction relationship data between intelligent agents is generated based on the call link relationship and the intelligent agent identifier to form the interaction metadata of the AI ​​intelligent agent.

6. The multi-protocol interaction parsing method for AI intelligent agents according to claim 1 or 2, characterized in that, When the protocol type is a model context protocol and is based on HTTP transmission, the step of calling the parsing rule corresponding to the protocol type to parse the application layer protocol data to extract the interaction metadata of the AI ​​agent includes: Based on the application layer protocol data, HTTP protocol parsing is performed to obtain the corresponding first remote call message body; The first remote call message body is structured and parsed to obtain the corresponding remote call request data and remote call response data; The tool call identifier and call parameters are extracted from the remote call request data, and the tool execution result is extracted from the remote call response data to form the interactive metadata of the AI ​​agent.

7. The multi-protocol interaction parsing method for AI intelligent agents according to claim 1 or 2, characterized in that, When the protocol type is a model context protocol and is based on standard input / output transmission, the step of calling the parsing rule corresponding to the protocol type to parse the application layer protocol data to extract the interaction metadata of the AI ​​agent includes: Identify the inter-process communication pipe associated with the AI ​​agent process, and determine the file descriptor corresponding to the inter-process communication pipe; Based on the file descriptor, data read and write behaviors in the inter-process communication pipe are collected to obtain streaming data generated by the interaction between the AI ​​agent and the tool subprocess; The streaming data is subjected to frame reassembly processing to restore the complete second remote call message body from the streaming data; The second remote call message body is structured and parsed to extract the tool call identifier, call parameters and tool execution results to form the interactive metadata of the AI ​​agent.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions, which, when executed, cause the processors to perform the multi-protocol interaction parsing method for AI agents as described in any one of claims 1-7.

9. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the multi-protocol interaction parsing method for AI agents as described in any one of claims 1-7.

10. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the multi-protocol interaction parsing method for AI agents as described in any one of claims 1-7.

Images