Intelligent agent platform plug-in debugging method and equipment based on cloud native and medium

Abstract

The invention discloses an agent platform plug-in debugging method and device based on cloud native and a medium, and the method comprises the steps that an agent platform marks a plug-in as a debugging mode, and generates a unique routing tag according to a unique identifier; the local client generates a unique identifier for the plug-in debugging session, and performs plug-in registration on the agent platform through long connection according to the unique identifier and the plug-in ID; associating the unique routing label with the plug-in debugging session identification information, and binding the unique routing label with the target instance; the plug-in debugging session identification information comprises a unique identifier, a plug-in ID and a target instance; analyzing the user calling request, and identifying a plug-in ID; when the unique routing tag is queried, judging whether the current instance is a target instance; and when the current instance is not the target instance, forwarding the user call request to the target instance so as to forward the user call request to the plug-in. And the debugging efficiency of the agent platform plug-in is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and particularly relates to an agent platform plug-in debugging method based on cloud native, equipment and medium. BACKGROUND

[0002] With the wide application of artificial intelligence agent (Agent) platform, the plug-in mechanism gradually becomes an important way for platform function expansion. The current plug-in development process usually has the following problems:

[0003] Low debugging efficiency: the traditional way requires the developer to deploy the plug-in to the platform environment for debugging. After each code modification, it needs to be repackaged, installed and deployed again, and the feedback cycle is long, which is not conducive to high-frequency iteration and complex logic debugging.

[0004] It is difficult to maintain the connection state under the cloud native environment: the agent platform is usually deployed in the cloud native architecture based on Kubernetes, and the platform service is usually stateless. Since the plug-in debugging depends on persistent connection (such as WebSocket), the calling request may be routed to a non-target service instance by the load balancing mechanism of Kubernetes, causing the connection to be disconnected or the debugging to fail. SUMMARY

[0005] The embodiments of the present application provide an agent platform plug-in debugging method based on cloud native, equipment and medium, which is used to solve the problems of easy disconnection and low efficiency of plug-in debugging.

[0006] The embodiments of the present application adopt the following technical solutions:

[0007] In one aspect, the embodiment of the present application provides a method for debugging an agent platform plug-in based on a cloud native, which comprises the following steps: after receiving a plug-in registration connection request, the agent platform marks the plug-in as a debugging mode, and generates a unique routing label for a plug-in debugging session according to a unique identifier; when starting a plug-in program to be debugged, the local client generates a unique identifier for the plug-in debugging session, registers the plug-in with the agent platform through a long connection according to the unique identifier and a plug-in ID, associates the unique routing label with plug-in debugging session identification information, and binds the unique routing label with a target instance; the plug-in debugging session identification information comprises the unique identifier, the plug-in ID, and the target instance holding the long connection; the received user call request is analyzed to identify the plug-in ID; when the plug-in current state is in the debugging mode, the unique routing label is queried according to the plug-in ID, and it is judged whether the current instance where the user call request is located is the target instance holding the long connection according to the unique routing label; when the current instance is not the target instance, the user call request is forwarded to the target instance; and the user call request is forwarded to the plug-in through the target instance and the long connection.

[0008] In one example, after the user call request is forwarded to the plug-in through the target instance and the long connection, the method further comprises the following steps: when the user call request is a first call request, a response result of the plug-in is received through the long connection and the target instance; the response result is forwarded to the current instance; the unique routing label is implicitly embedded in the response result to obtain a label injection response result, and the label injection response result is fed back to the user through the current instance.

[0009] In one example, after the unique routing label is implicitly embedded in the response result to obtain a label injection response result, and the label is fed back to the user through the current instance, the method further comprises the following steps: a received user re-call request is analyzed to obtain the unique routing label; when the plug-in current state is in the debugging mode, it is judged whether the current instance where the user re-call request is located is the target instance holding the long connection according to the unique routing label.

[0010] In one example, the judgment of whether the current instance where the user call request is located is the target instance holding the long connection according to the unique routing label specifically comprises the following steps: it is judged whether the binding routing label of the current instance is consistent with the unique routing label; when consistent, it is determined that the current instance is the target instance holding the long connection; and when inconsistent, the target instance in the associated plug-in debugging session identification information is compared to determine whether the current instance is the target instance.

[0011] In one example, after the user call request is forwarded to the plugin through the target instance and the long connection, the method further comprises: the local client executes the user call request, the plugin pauses execution and executes the code after the breakpoint line by line when the plugin execution reaches the breakpoint; when there is an exception code, after the exception code is modified, the modified new code is loaded and takes effect by using the hot reloading function; after the repair is completed, the plugin re-executes from the breakpoint to complete the user call request.

[0012] In one example, the method further comprises: generating a unique URL for the plugin when receiving a Webhook URL assignment request; the unique URL includes a plugin ID and a random verification credential; receiving a Webhook request of a third-party platform through a unified Webhook access point; the third-party platform registers the unique URL as a Webhook receiving address; parsing the unique URL to determine that the parsed plugin ID does not exist and / or the random verification credential is invalid; sending a Webhook request call failure notification to the third-party platform.

[0013] In one example, the method further comprises: the parsed plugin ID exists and the random verification credential is valid; if the current state of the plugin is in the debugging mode, when the unique route label is queried according to the plugin ID, it is judged according to the unique route label whether the current instance where the Webhook request is located is the target instance holding the long connection; when the current instance is not the target instance, the Webhook request is converted and the converted Webhook request is forwarded to the target instance.

[0014] In one example, the method further comprises: when the current instance is the target instance, the user call request is forwarded to the plugin through the current instance and the long connection.

[0015] In another aspect, the embodiments of the present application provide an agent platform plugin debugging device based on cloud native, comprising: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute any one of the above-mentioned agent platform plugin debugging methods based on cloud native.

[0016] In another aspect, the embodiments of the present application provide a non-volatile computer storage medium based on cloud native agent platform plugin debugging, which stores computer executable instructions, and the computer executable instructions can execute any one of the above-mentioned agent platform plugin debugging methods based on cloud native.

[0017] The at least one technical solution adopted by the embodiments of the present application can achieve the following beneficial effects:

[0018] The present application supports local hot debugging of plugins in a cloud-native environment, realizing stable connection and routable requests, as follows:

[0019] Local plugin initiates connection to platform: the life cycle of debugging is initiated and maintained by the local plugin. That is, the developer starts the plugin locally, the plugin generates a unique identifier, and initiates a long connection to the agent platform control plane, declaring that it is in debugging mode, thereby establishing a debugging channel.

[0020] Agent platform identifies debugging state and manages routing: debugging plugins can be identified based on plugin ID, and routing information of debugging sessions (which instance holds what connection) can be managed based on unique identifier and unique routing label. Thus, in a cloud-native environment, the platform internally communicates through routing labels to ensure that the call request reaches the instance holding the connection.

[0021] In summary, the feedback cycle is shortened: through the long connection and routing label mechanism, the developer does not need to frequently repack and deploy the plugin. After modifying the code, the hot reloading function can be used for quick verification, shortening the debugging feedback cycle from minutes to seconds, and greatly improving the high-frequency iteration efficiency.

[0022] Breakpoint debugging support: supports setting breakpoints on the local client, realizing line-by-line debugging of the code, conforming to the traditional debugging habits of developers, and reducing the difficulty of debugging complex logic.

[0023] Connection state preservation: through the unique routing label, the debugging request is routed to the target instance holding the long connection, solving the connection interruption problem caused by Kubernetes load balancing and ensuring the stability of the debugging session.

[0024] Stateless architecture compatible: without changing the stateless design of the platform, the debugging function is realized through an external routing mechanism, maintaining the advantages of cloud-native architecture. BRIEF DESCRIPTION OF DRAWINGS

[0025] In order to more clearly illustrate the technical solutions of the present application, some embodiments of the present application will be described in detail below with reference to the accompanying drawings, in which:

[0026] Figure 1 A flowchart of a cloud-native-based agent platform plugin debugging method provided by an embodiment of the present application;

[0027] Figure 2 A structural schematic diagram of a cloud-native-based agent platform plugin debugging device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0028] For the purposes of the present application, the technical solutions and advantages will be more apparent, the technical solutions of the present application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of protection of the present application.

[0029] Some embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0030] Figure 1 A flowchart of an intelligent agent platform plug-in debugging method based on cloud native provided by an embodiment of the present application. The method can be applied to different business fields, such as the Internet financial business field, the e-commerce business field, the instant messaging business field, the game business field, the public service business field, etc. Some input parameters or intermediate results in the flow allow manual intervention to adjust to help improve accuracy.

[0031] The implementation of the analysis method related to the embodiments of the present application can be a terminal device or a server, and the present application does not make special limitations on this. For the convenience of understanding and description, the following embodiments are described in detail with the server as an example.

[0032] It should be noted that the server can be a single device, or a system composed of multiple devices, i.e., a distributed server, and the present application does not make specific limitations on this.

[0033] Figure 1 The flow in the server includes the following steps:

[0034] S101: After receiving the plug-in registration connection request, the intelligent agent platform marks the plug-in as a debugging mode, generates a unique routing tag for the plug-in debugging session according to the unique identifier; the local client generates a unique identifier for the plug-in debugging session when starting the plug-in program to be debugged, and registers the plug-in with the intelligent agent platform through a long connection according to the unique identifier and the plug-in ID.

[0035] In some embodiments of the present application, a plug-in local hot debugging mechanism is provided, and a plug-in developer can start a plug-in process locally as a debugging service. A local plug-in runtime generates a unique identifier (debug_session_id), and registers with the intelligent agent platform control plane through a long connection. After the connection is established, the intelligent agent platform will perform the following operations: 1. Mark the plug-in as a debugging mode. 2. All call requests from users will be forwarded to the local plug-in in real time via the long connection. 3. The plug-in response content is returned to the platform, realizing fast verification. 4. Support for local breakpoint debugging and code hot update, without installation or deployment to take effect immediately.

[0036] In addition, in a Kubernetes-based cloud-native deployment architecture, the intelligent agent platform is composed of multiple stateless service instances, and user requests may be routed to any instance. To ensure that requests from users can accurately reach the target instance that establishes a debugging connection with the plug-in, a connection session maintenance and request forwarding mechanism in a cloud-native environment is provided as follows:

[0037] To solve the connection inconsistency problem in stateless architectures such as Kubernetes, the system designs the following mechanism:

[0038] 1. Traffic label injection: When the local plug-in registers with the intelligent agent platform, a routing mark (unique routing label) is added when the request reaches the Ingress of the intelligent agent platform.

[0039] 2. After all user call requests reach any instance of the intelligent agent platform, the built-in routing decision engine in the instance determines whether the current instance is not the long connection holder based on the obtained routing mark, and if so, the user call request is forwarded to the target instance through internal platform communication (such as service mesh).

[0040] 3. In the target instance, the user call request is sent to the local plug-in through the established debugging long connection.

[0041] 4. The plug-in response is returned to the user via the original path.

[0042] In summary, this mechanism can ensure that user call requests are always routed to the correct processing path when the plug-in is in a local hot debugging state.

[0043] Based on this, the specific explanation is as follows:

[0044] First, the developer starts the plug-in program to be debugged on the local client, and the plug-in process generates a unique identifier (debug_session_id) when it starts, which is used for identification and tracking of local debugging sessions.

[0045] Then, the plug-in initiates a registration request to the control plane of the agent platform through a long connection protocol such as WebSocket or gRPC, carrying the debug_session_id and plug-in meta information (such as plug-in ID, developer information, capability description, etc.).

[0046] Then, the agent platform marks the plug-in as a debugging mode after receiving the registration connection request. In this mode, the platform does not require the plug-in to complete the installation or deployment formal online process, but maintains real-time communication with the local plug-in.

[0047] Then, the agent platform injects a routing label when the plug-in registers: when the local plug-in registers the connection, the control plane generates a unique routing label and injects the label in the long connection path through a service gateway (such as Ingress).

[0048] It should be noted that the internal instance has a built-in routing engine, and all platform instances have a built-in lightweight routing decision engine. After receiving a user call request, in a non-first call, the instance parses the routing label carried, or in a first call, the instance parses the plug-in ID and queries the corresponding routing label, and judges whether the current instance has a long connection with the plug-in.

[0049] S102: associate the unique routing label with plug-in debugging session identification information, and bind the unique routing label with the target instance; the plug-in debugging session identification information includes a unique identifier, a plug-in ID, and a target instance holding the long connection.

[0050] Among them, by binding the unique routing label with the target instance, it can be judged whether the routing label bound by the current instance is the parsed routing label when the unique routing label is parsed, and further whether the current instance is the target instance.

[0051] In addition, by constructing plug-in debugging session identification information, the corresponding routing label and target instance can be retrieved according to the plug-in ID.

[0052] S103: parse the received user call request to identify the plug-in ID.

[0053] It should be noted that the current user call request can be a first call or a non-first call, that is, in a non-first call, even if the routing label is carried, the routing label can be queried based on the plug-in ID. However, in general, when the routing label is carried, the routing label carried is directly used.

[0054] S104: If the current state of the plug-in is in the debugging mode, when the unique routing label is queried according to the plug-in ID, it is judged whether the current instance where the user call request is located is the target instance holding the long connection according to the unique routing label.

[0055] In some embodiments of the present application, whether the current instance where the user call request is located is the target instance holding the long connection is judged as follows:

[0056] First, it is judged whether the binding routing label of the current instance is consistent with the unique routing label.

[0057] When consistent, it is determined that the current instance is the target instance holding the long connection.

[0058] When inconsistent, the target instance in the associated plug-in debugging session identification information is compared to determine whether the current instance is the target instance.

[0059] S105: When the current instance is not the target instance, the user call request is forwarded to the target instance.

[0060] Among them, the service mesh forwarding mechanism is set: if the current instance is not the connection holder, the request is transparently forwarded to the target instance through the service mesh (such as Istio) or the platform internal communication module.

[0061] It should be noted that when the current instance is the target instance, the user call request is forwarded to the plug-in through the current instance and the long connection.

[0062] S106: The user call request is forwarded to the plug-in through the target instance and the long connection.

[0063] In some embodiments of the present application, when the agent platform receives a user request to call the plug-in, the call request content is forwarded to the local plug-in through the previously established long connection.

[0064] After the local plug-in completes processing, the response result is returned to the agent platform through the connection, and then fed back to the user by the agent platform.

[0065] That is, the target instance forwards the request to the local plug-in using the long connection, and the plug-in returns the response result to the user via the original path after processing.

[0066] It should be noted that since the plug-in runs locally, developers can use local tools such as breakpoint debugging and hot reloading to perform real-time debugging and repair, greatly improving development efficiency.

[0067] Based on this, the process of debugging and repairing is as follows:

[0068] The local client executes the user invocation request, and when the plug-in execution reaches the breakpoint, the plug-in program pauses the execution and executes the code after the breakpoint line by line.

[0069] When there is an exception code, after modification of the exception code, the modified new code is loaded and takes effect by using the hot reloading function.

[0070] After the repair is completed, the plug-in program re-executes from the breakpoint to complete the user invocation request.

[0071] In some embodiments of the present application, when the user first interacts with the plug-in, the agent platform injects a routing label in the response (such as hidden in Cookie / HTTP Header), and the subsequent request automatically carries the label. Thus, the following technical effects are achieved:

[0072] Reduce routing table query: the subsequent request is directly routed by the label, without the need to access the central storage, especially suitable for high concurrency scenarios.

[0073] Precise routing: even if the service instance is scaled up or down, the routing label always points to the correct target.

[0074] User is not aware: the routing label transfer is automatically completed by the platform.

[0075] It should be noted that the initial request of the user only carries business parameters and plug-in ID, and does not contain a routing label (the user cannot predict the location of the debugging session).

[0076] Based on this, after forwarding the user invocation request to the plug-in, the following operations are performed:

[0077] When the user invocation request is the first invocation request, the agent platform receives the response result of the plug-in through a long connection with the target instance.

[0078] Then, the response result is forwarded to the current instance.

[0079] The routing label is implicitly embedded in the response result to obtain a label injection response result, which is fed back to the user through the current instance.

[0080] It should be noted that when the user invokes again, the received user invocation request is parsed to obtain a unique routing label. If the current state of the plug-in is in the debugging mode, it is judged whether the current instance of the user invocation request is the target instance holding the long connection according to the unique routing label. When the current instance is not the target instance, the user invocation request is forwarded to the target instance; the user invocation request is forwarded to the plug-in through the target instance and the long connection.

[0081] In some embodiments of the present application, the Webhook access is complex: when the plug-in needs to receive the HTTP request sent by the external platform (such as Discord, Slack, Lark, etc.), the developer needs to deploy a public network accessible service for the plug-in, which increases the development and operation burden and also brings potential security risks. That is, when the plug-in is in the debugging process and needs to receive HTTP requests from third-party platforms, the traditional way usually requires the plug-in to expose a public service, which has problems such as complex configuration and security risks. Therefore, in order to simplify the integration process, the present application introduces a unified Webhook access endpoint mechanism, which reuses the debugging channel to process Webhook, that is, after the Webhook request is received and verified by the platform, it is sent to the local plug-in by reusing the existing debugging long connection, without the need for the plug-in to expose a public IP, as follows:

[0082] Webhook URL allocation: after the plug-in is installed or registered successfully, the agent platform generates a unique Webhook URL for the plug-in, wherein the format is as follows:

[0083] https: / / platform.com / webhook / {plugin_id} / {random_token}. Wherein, plugin_id is used to identify the plug-in (plug-in ID), and random_token is used to verify the security of the source.

[0084] External third-party platform registers Webhook: the plug-in provides the generated URL to the third-party platform to complete the Webhook access configuration.

[0085] Unified request receiving and verification: when the external platform triggers the Webhook request, the request is received by the agent platform. The agent platform parses the URL, verifies whether the plugin_id exists, and whether the random_token is valid.

[0086] Request forwarding to plug-in: after verification, the agent platform decides the forwarding path according to the current state of the plug-in (local debugging or formal deployment), and if it is in the debugging state, it is forwarded to the local plug-in according to the plug-in ID through the long connection.

[0087] Response result return: after the plug-in is processed, the response is returned, and the platform returns the response content to the external platform, realizing a complete closed loop.

[0088] Based on this, the agent platform generates a unique URL for the plug-in when receiving a Webhook URL allocation request. The unique URL includes the plug-in ID and a random verification credential.

[0089] Then, webhook requests from third-party platforms are received through a unified webhook access point. Each third-party platform registers a unique URL as its webhook receiving address.

[0090] Then, the unique URL is parsed to determine if the parsed plugin ID does not exist and / or the random verification credential is invalid.

[0091] Send a Webhook request call failure notification to the third-party platform.

[0092] Furthermore, if the parsed plugin ID exists and the random verification credential is valid, and the plugin is currently in debug mode, when a unique route label is found based on the plugin ID, the system will determine whether the current instance where the Webhook request is located is the target instance holding the long connection based on the unique route label.

[0093] If the current instance is not the target instance, the Webhook request is transformed and forwarded to the target instance. This allows the Webhook request to be forwarded to the plugin via a persistent connection to the target instance.

[0094] It should be noted that, although the embodiments in this application are based on... Figure 1 Steps S101 to S106 will be described sequentially, but this does not mean that steps S101 to S106 must be performed in a strict order. The reason this embodiment follows this order is... Figure 1 The order in which steps S101 to S106 are described is provided to facilitate understanding of the technical solutions of the embodiments of this application by those skilled in the art. In other words, in the embodiments of this application, the order of steps S101 to S106 can be appropriately adjusted according to actual needs.

[0095] pass Figure 1 This paper proposes a plugin connection mechanism that supports local hot debugging of plugins, and based on this mechanism, a plugin integration solution that supports Webhook request forwarding from external platforms. This solution enables local hot debugging of plugins in cloud-native environments, achieving stable connections, routable requests, simplified integration with external platforms, and improved flexibility and development efficiency for plugin extensions in debugging mode. The concept is as follows:

[0096] By introducing the local hot debugging mechanism, connection maintenance and request routing mechanism in the cloud-native environment, and unified Webhook access and forwarding scheme, the efficiency and experience of plug-in development and debugging are significantly improved. Developers can achieve what you see is what you get code verification without repeated deployment, while taking advantage of the built-in routing engine and service mesh capabilities to achieve stable connection and accurate request forwarding in stateless architectures such as Kubernetes, ensuring service consistency during debugging.

[0097] In addition, the agent platform automatically assigns a secure Webhook access endpoint to the plug-in, avoiding the tediousness and risks of developers building public services, greatly simplifying the integration process of plug-ins and external platforms.

[0098] In summary, the overall solution not only improves the platform's expansion capabilities and development efficiency, but also has good universality and generalizability, suitable for building agent platforms that support plug-in ecosystems, RPA tool integration platforms, AIAgent services, and other scenarios, with high application value and industrial landing potential.

[0099] The technical solution is as follows:

[0100] Local plug-in initiates connection to the platform: the life cycle of debugging is initiated and maintained by the local plug-in. That is, the developer starts the plug-in locally, the plug-in generates a unique identifier, and initiates a long connection to the agent platform control surface, declaring itself in debugging mode, thereby establishing a debugging channel.

[0101] Agent platform recognizes debugging state and manages routing: can recognize debugging plug-ins based on plug-in ID, manage routing information of debugging sessions (which instance holds what connection) based on unique identifier and unique routing label. Thus, in a cloud-native environment, the platform ensures that the call request reaches the instance holding the connection through routing labels and internal communication.

[0102] Transparent request forwarding: user requests and Webhook requests are ultimately forwarded to the local plug-in through the same debugging long connection.

[0103] Reuse debugging channel to handle Webhook: After the Webhook request is received and verified by the platform, it is sent to the local plug-in using the existing debugging long connection, without the need for the plug-in to expose a public IP.

[0104] Local development experience: developers run, debug, and fix code in the local IDE throughout the development process, use breakpoints and hot reloading to see the modification effect immediately, and achieve high efficiency.

[0105] In summary, the feedback cycle is shortened: through the long connection and routing label mechanism, developers do not need to frequently repack and deploy plugins. After modifying the code, the hot reloading function can be used for quick verification, reducing the debugging feedback cycle from minutes to seconds, and greatly improving the high-frequency iteration efficiency.

[0106] Breakpoint debugging support: support setting breakpoints on local clients, realize line-by-line debugging of code, conform to the traditional debugging habits of developers, and reduce the debugging difficulty of complex logic.

[0107] Connection state retention: through a unique routing label, the debugging request is routed to the target instance holding the long connection, solving the connection interruption problem caused by Kubernetes load balancing, and ensuring the stability of the debugging session.

[0108] Stateless architecture compatible: without changing the stateless design of the platform, the debugging function is realized through the external routing mechanism, maintaining the advantages of cloud-native architecture.

[0109] Unified access point design: through the unified webhook access point of the agent platform, plugin developers do not need to deploy public services themselves, reducing development and operation and maintenance costs.

[0110] Multi-platform compatible: the unified webhook access point supports multiple third-party platforms such as Discord, Slack, and Lark, improving the cross-platform adaptation ability of plugins.

[0111] Security verification mechanism: random verification credentials in unique URLs effectively prevent unauthorized access, and combined with plugin ID verification, further enhance the security of webhook access.

[0112] Local priority development: developers can complete most of the debugging work in the local environment, reducing dependence on remote environments and reducing environment configuration costs.

[0113] Error repair efficiency: the combination of breakpoint recovery and hot reloading functions enables developers to quickly fix problems and continue debugging, avoiding starting from scratch to execute test cases.

[0114] Based on the same idea, some embodiments of the present application also provide a device and a non-volatile computer storage medium corresponding to the above method.

[0115] Figure 2 A structure diagram of an agent platform plugin debugging device based on cloud native provided by an embodiment of the present application, comprising:

[0116] At least one processor; and,

[0117] The memory is in communication connection with the at least one processor; wherein,

[0118] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the cloud-native intelligent entity platform plug-in debugging method described in any one of the above.

[0119] Some embodiments of the present application provide a cloud-native intelligent entity platform plug-in debugging nonvolatile computer storage medium, which stores computer executable instructions, and the computer executable instructions can execute the cloud-native intelligent entity platform plug-in debugging method described in any one of the above.

[0120] Each of the embodiments in the present application is described in a progressive manner, and the same or similar parts of each of the embodiments can be referred to each other. Each of the embodiments mainly describes the differences from other embodiments. In particular, the device and medium embodiments are basically similar to the method embodiments, and thus are described more simply, and the relevant parts are referred to the part of the method embodiments.

[0121] The device and medium provided by the embodiments of the present application correspond to the method, and thus the device and medium also have the similar beneficial technical effects as the method. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the device and medium will not be described here.

[0122] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0123] The present application is described with reference to flowcharts and / or block diagrams of the method, device (system), and computer program product according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to produce a machine, so that the instructions executed by the computer or other programmable data processing devices produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in one flow or multiple flows and / or blocks Figure 1 The device that implements the functions specified in one flow or multiple flows and / or blocks.

[0124] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0125] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0126] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0127] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory, etc. The memory is an example of computer readable media.

[0128] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

[0129] It should also be noted that the terms "comprising", "comprises", "including", "includes" or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises a... " does not, without more constraints, exclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0130] The above description is only the preferred embodiment of the present application, and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, and the like made within the technical principles of the present application should be within the scope of the present application.

Claims

1. A cloud-native agent platform plugin debugging method, characterized in that, The method comprises: After receiving the plug-in registration connection request, the intelligent agent platform marks the plug-in as a debugging mode, generates a unique routing label for the plug-in debugging session according to a unique identifier; the local client generates a unique identifier for the plug-in debugging session when starting the plug-in program to be debugged, and registers the plug-in with the intelligent agent platform according to the unique identifier and the plug-in ID through a long connection; The unique routing label is associated with plug-in debugging session identification information, and the unique routing label is bound to a target instance; the plug-in debugging session identification information comprises a unique identifier, a plug-in ID, and a target instance holding the long connection; The received user call request is parsed to identify the plug-in ID; If the current state of the plug-in is in the debugging mode, when the unique routing label is queried according to the plug-in ID, whether the current instance where the user call request is located is the target instance holding the long connection is judged according to the unique routing label; When the current instance is not the target instance, the user call request is forwarded to the target instance; The user call request is forwarded to the plug-in through the target instance and the long connection.

2. The method of claim 1, wherein, After the user call request is forwarded to the plug-in through the target instance and the long connection, the method further comprises: When the user call request is a first call request, the response result of the plug-in is received through the long connection and the target instance; The response result is forwarded to the current instance; The routing label is implicitly embedded in the response result to obtain a label injection response result, and the label injection response result is fed back to the user through the current instance.

3. The method of claim 2, wherein, After the unique routing label is implicitly embedded in the response result to obtain a label injection response result, and the label is fed back to the user through the current instance, the method further comprises: The received user re-call request is parsed to obtain the unique routing label; If the current state of the plug-in is in the debugging mode, whether the current instance where the user re-call request is located is the target instance holding the long connection is judged according to the unique routing label.

4. The method of claim 1, wherein, The judgment of whether the current instance where the user call request is located is the target instance holding the long connection according to the unique routing label specifically comprises: Whether the bound routing label of the current instance is consistent with the unique routing label is judged; When consistent, it is determined that the current instance is the target instance holding the long connection; When inconsistent, the target instance in the associated plug-in debugging session identification information is compared to determine whether the current instance is the target instance.

5. The method of claim 1, wherein, After the user call request is forwarded to the plug-in through the target instance and the long connection, the method further comprises: The local client executes the user call request, and the plug-in program pauses execution and executes the code after the breakpoint line by line when the plug-in executes to the breakpoint; When there is an abnormal code, after the abnormal code is modified, the modified new code is loaded and takes effect by using the hot reloading function; After the repair is completed, the plug-in re-executes from the breakpoint to complete the user call request.

6. The method of claim 5, wherein, The method further comprises: generating a unique URL for the plug-in upon receiving a Webhook URL assignment request; the unique URL comprises a plug-in ID and a random verification credential; receiving a Webhook request of a third-party platform through a unified Webhook access point; the third-party platform registers the unique URL as a Webhook receiving address; parsing the unique URL to determine that the parsed plug-in ID does not exist and / or the random verification credential is invalid; sending a Webhook request call failure notification to the third-party platform.

7. The method of claim 6, wherein, The method further comprises: the parsed plug-in ID exists and the random verification credential is valid; if the current state of the plug-in is in the debugging mode, when the unique route label is queried according to the plug-in ID, it is determined whether the current instance where the Webhook request is located is the target instance holding the long connection according to the unique route label; when the current instance is not the target instance, the Webhook request is converted, and the converted Webhook request is forwarded to the target instance.

8. The method of claim 1, wherein, The method further comprises: when the current instance is the target instance, the user call request is forwarded to the plug-in through the current instance and the long connection.

9. A cloud-native-based agent platform plugin debugging device, characterized in that, comprises: at least one processor; and a memory connected in communication with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the intelligent agent platform plug-in debugging method based on cloud native of any one of claims 1-8. 10.A cloud-native intelligent agent platform plugin debugging non-volatile computer storage medium storing computer executable instructions, characterized in that, The computer executable instructions can perform the intelligent agent platform plug-in debugging method based on cloud native of any one of claims 1-8. The computer executable instructions can perform the intelligent agent platform plug-in debugging method based on cloud native of any one of claims 1-8.

Images