Low-code enterprise-level intelligent assistant development platform

Abstract

The invention provides a low-code enterprise-level intelligent assistant development platform, and relates to the field of intelligent assistant development. The low-code enterprise-level intelligent assistant development platform comprises an application layer, a platform layer, a capability layer and an underlying service. According to the low-code enterprise-level intelligent assistant development platform, a low-code enterprise-level intelligent assistant development platform is realized, and by means of the platform, a user can develop enterprise-level intelligent assistants suitable for various industries, thereby helping enterprises to realize cost reduction and benefit increase; a user can complete the creation of a knowledge base, a workflow and an intelligent agent only through simple configuration or arrangement, a low use threshold is achieved, enterprise internal services or third-party MCP services can be accessed by means of a plug-in tool and a platform, uploading and publishing of user-defined tools are supported at the same time, high expandability is achieved, and the method can be widely applied to the field of enterprise management. The platform supports high-order functions such as multi-person collaborative development, multi-modal knowledge base construction, multi-modal data interpretation and processing and construction of multiple types of agents, and can meet complex enterprise-level application scenes.

Description

Technical Field

[0001] This invention relates to the field of intelligent assistant development technology, specifically a low-code enterprise-level intelligent assistant development platform. Background Technology

[0002] With the rapid development of Artificial Intelligence (AI) technology, especially the significant improvement in Large Language Model (LLM) capabilities, intelligent assistants based on large models are being widely applied in various scenarios across industries and are becoming key tools for enterprises to reduce costs, increase efficiency, and achieve digital transformation. These intelligent assistants reduce enterprises' investment in human resources by replacing manual labor in repetitive and rule-based tasks. By analyzing user behavior and business data, they assist management in making more accurate decisions, thereby improving overall operational efficiency. More specifically, in customer service scenarios, intelligent assistants can provide 24 / 7 automated responses; in marketing scenarios, they can generate personalized recommendations based on user profiles; and in enterprise process automation, they can collaboratively complete complex tasks such as data extraction and process approval.

[0003] However, the development of current intelligent assistants still faces many challenges. Traditional intelligent assistant development typically relies on professional algorithm and development teams, requiring the writing of a large amount of code and deep customization of the underlying model, interface calls, and business logic according to specific application scenarios. This results in long development cycles and high maintenance costs. Consequently, it is difficult for SMEs and non-technical personnel to quickly build and deploy intelligent assistants that meet their business needs, severely limiting the wider application and popularization of AI technology. Summary of the Invention

[0004] The purpose of this invention is to provide a low-code enterprise-level intelligent assistant development platform, which solves the problems mentioned in the background art.

[0005] Technical solution

[0006] To achieve the above objectives, the present invention provides the following technical solution: a low-code enterprise-level intelligent assistant development platform, comprising an application layer, a platform layer, a capability layer, and underlying services. The core modules of the application layer, platform layer, capability layer, and underlying services include: RAG engine, workflow engine, intelligent agent engine, model service management, plug-in tool management, relational database management, cache database management, vector database management, object storage management, monitoring and logging, role allocation and permission management, historical session management, and environment configuration.

[0007] Furthermore, the platform supports two types of knowledge bases: plain text knowledge bases and multimodal knowledge bases. Plain text knowledge bases only support storing and retrieving text fragments, while multimodal knowledge bases not only support storing and retrieving text fragments, but also support storing and retrieving images and tables. When creating a new knowledge base, users can choose the knowledge base type according to their needs.

[0008] Furthermore, the knowledge base supports three retrieval methods: semantic retrieval, hybrid retrieval, and question rewriting.

[0009] Furthermore, the platform supports the construction of workflow and agent-type intelligent assistants, each with its own advantages and disadvantages, suitable for different application scenarios.

[0010] Furthermore, the platform provides a visual canvas where users can drag and drop nodes and connect them in a specific order to quickly build a workflow. Users can also debug individual nodes within the workflow or debug the entire workflow.

[0011] Furthermore, the platform supports four types of agents: ReAct single agent, Plan-and-Execute multi-agent, Hierarchical multi-agent, and user-defined multi-agent. Each type of agent can be assigned workflow or tool-type skills, meaning that agents can solve specific problems by invoking workflows or tools.

[0012] Furthermore, the intelligent agents of the platform all include a memory module, which plays a very important role in the design of the intelligent agent architecture. It stores information perceived from the environment, past plans and behaviors, and interactions and feedback with the environment. The intelligent agent performs task planning and execution based on the stored memory. The memory module helps the intelligent agent accumulate experience, evolve itself, and behave in a more consistent, reasonable and effective manner.

[0013] Furthermore, the platform's intelligent agent supports a reflection and self-correction mechanism. Users can choose whether to enable this function as needed. The reflection and self-correction mechanism simulates the human cognitive process of "post-event review - problem discovery - behavior adjustment," enabling the intelligent agent to no longer rely solely on preset rules or steps to perform tasks, but to dynamically evaluate its own behavior and proactively optimize its strategies. With the help of this mechanism, the intelligent agent can achieve continuous improvement and enhance its robustness and reliability.

[0014] This invention provides a low-code enterprise-level intelligent assistant development platform. It has the following beneficial effects:

[0015] This low-code enterprise-level intelligent assistant development platform enables users to develop enterprise-level intelligent assistants applicable to various industries, helping enterprises reduce costs and increase efficiency. Users can create knowledge bases, workflows, and intelligent agents through simple configuration or orchestration, making it easy to use. With the help of plug-in tools, the platform can connect to internal enterprise services or third-party MCP services, and also supports uploading and publishing user-defined tools, demonstrating high scalability. The platform supports advanced functions such as multi-person collaborative development, multimodal knowledge base construction, multimodal data interpretation and processing, and the construction of various types of intelligent agents, meeting the needs of complex enterprise-level application scenarios. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the platform architecture of the present invention;

[0017] Figure 2 A schematic diagram illustrating the creation of the knowledge base for this invention;

[0018] Figure 3 This is a schematic diagram of the ReAct single agent of the present invention;

[0019] Figure 4 This is a schematic diagram of the Plan-and-Execute multi-agent system of the present invention;

[0020] Figure 5 This is a schematic diagram of the hierarchical multi-agent system of the present invention. Detailed Implementation

[0021] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0022] Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the invention, and should not be construed as limiting the invention.

[0023] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0024] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0025] like Figure 1-5 As shown, this embodiment of the invention provides a low-code enterprise-level intelligent assistant development platform, including an application layer, a platform layer, a capability layer, and underlying services. The core modules of the application layer, platform layer, capability layer, and underlying services include: RAG engine, workflow engine, intelligent agent engine, model service management, plug-in tool management, relational database management, cache database management, vector database management, object storage management, monitoring and logging, role allocation and permission management, historical session management, environment configuration, etc.

[0026] The platform supports two types of knowledge bases: plain text knowledge bases and multimodal knowledge bases. Plain text knowledge bases only support storing and retrieving text snippets, while multimodal knowledge bases support storing and retrieving not only text snippets but also images and tables. When creating a new knowledge base, users can choose the type according to their needs.

[0027] For documents to be written into the knowledge base, the system selects different document parsers based on the type of knowledge base to be written. Plain text knowledge bases use ordinary document parsers to extract the text content, while multimodal knowledge bases use multimodal document parsers to extract text, images, and tables. After parsing, the text content needs to be segmented into shorter text fragments. Segmentation methods support fixed-length segmentation, segmentation based on document structure, and segmentation based on semantics, allowing users to choose their preferred method. After segmentation, the system selects different embedding models for feature vector extraction based on the type of knowledge base to be written. Plain text knowledge bases use text embedding models to embed the text fragments obtained in the previous step, while multimodal knowledge bases require multimodal embedding models to embed text fragments, images, and tables separately. Finally, the system writes the text fragments, images, tables, and their corresponding feature vectors into a vector library, completing the knowledge base creation process. The entire knowledge base creation process is as follows: Figure 2 As shown.

[0028] The knowledge base categorizes and stores data according to three levels: Collection, Partition, and Scene. The granularity of data division increases from Collection to Partition to Scene. For example, if a user wants to build a knowledge base encompassing knowledge in three fields—law, finance, and medicine—the user can create three separate collections for these fields. In the legal field, there are sub-fields such as criminal law, civil law, commercial law, and labor law. Users can then create partitions based on these sub-fields. Furthermore, in civil law, some clauses concern inheritance, while others concern marriage. Users can assign a scene tag to each segmented text fragment and store the scene as metadata in a vector library. During retrieval, users can use the scene field to filter and retrieve text fragments.

[0029] The knowledge base supports three retrieval methods: semantic retrieval, hybrid retrieval, and question rewriting.

[0030] For semantic retrieval, the system first uses an embedding model to convert user questions, requests, or instructions into corresponding feature vectors. It then uses these feature vectors to retrieve the specified knowledge base set and partitions, recalling the top_k entries with semantic similarity exceeding a certain threshold, and finally filtering out the desired entries based on the scenario. Here, the knowledge base set, partitions, scenario, similarity threshold, and top_k are all set by the user.

[0031] Hybrid retrieval is a method that combines semantic retrieval and keyword retrieval. During the retrieval process, semantic similarity and keyword matching are considered comprehensively. A final similarity score is calculated based on a weighted sum of these two scores, and the top_k entries with similarity scores exceeding a certain threshold are retrieved. Similar to semantic retrieval, the knowledge base set, partitions, scenarios, similarity threshold, and top_k are all user-defined. It's important to note that hybrid retrieval only supports plain text knowledge bases, as keyword retrieval only supports text-to-text matching.

[0032] Question rewriting retrieval first rewrites the user's question, request, or instruction into multiple semantically similar but differently expressed sentences. Then, each sentence is used to search the knowledge base. Finally, the results are combined to obtain the final retrieval result. This approach improves the precision of retrieval results by rewriting the user's original expression into a clearer and more accurate one, and improves the recall by adding relevant words or phrases.

[0033] To improve the recall rate of search results, users can decrease the similarity threshold and increase the top_k value. However, this inevitably reduces the precision of the search results, meaning that the search results will contain some entries that are irrelevant to the user's query. Feeding all these entries directly to the large model may exceed the context window limit of the large model. Even if it does not exceed the context window limit, excessively long prompts containing a large number of irrelevant contents will reduce the large model's context understanding and instruction compliance capabilities, thus affecting the accuracy of the large model's output. Therefore, reranking the search results after retrieval is a key step to improve the precision of search results and reduce redundant information irrelevant to the user's query. Generally, a larger top_k is set during the retrieval stage (e.g., 20), and a smaller top_k is set during the reranking stage (e.g., 5). Finally, the reranked entries are fed to the large model to improve the accuracy of the large model's output.

[0034] The platform supports building workflow-based and agent-based intelligent assistants, each with its own advantages and disadvantages, suitable for different application scenarios. A workflow is a series of tasks or steps executed according to predefined rules and sequence, achieving standardization and automation of the process and ensuring tasks are completed step-by-step. Workflows are rule-driven, with high determinism and controllability in their execution, suitable for relatively simple scenarios. An agent is an entity capable of perceiving its environment and autonomously taking actions to achieve a specific goal. Agents are goal-driven, possessing high autonomy, adaptability, and flexibility, suitable for relatively complex scenarios.

[0035] The platform provides a visual canvas where users can drag and drop nodes and connect them in a specific order to quickly build a workflow. Users can also debug individual nodes within the workflow or debug the entire workflow.

[0036] The basic building block of a workflow is the node, which is an independent component with a specific function. These nodes are responsible for processing data, executing tasks, and running algorithms, and they all have inputs and outputs. By connecting these nodes with specific functions in different ways, workflows capable of accomplishing various specific tasks can be built.

[0037] The workflow supports the following nodes: dialogue entry node, dialogue output node, large model dialogue node, knowledge base retrieval node, code node, selector node, text processing node, message output node, database node, plug-in tool node, intent recognition node, question-and-answer node, etc. Each workflow contains at least one dialogue entry node and one dialogue end node. Most node configurations consist of three parts: input parameters, function parameters, and output parameters. A few nodes are exceptions; for example, the dialogue entry node has no input or function parameters, and the dialogue output and message nodes have no output parameters. Each node's input parameters can be set to fixed values ​​or can reference the output of preceding nodes. Each node's function parameters are configuration parameters unique to that node, such as model selection, model parameters, prompt word templates, and output methods for large model nodes. Output parameters define the data structure of the node's output data (including parameter name, data type, and parameter description). The function and usage of each type of node are explained below.

[0038] The dialogue entry node is the starting node of the workflow, used to set the input information required to start the workflow. The dialogue entry node only has output parameters, not input or function parameters. By default, the dialogue entry node has an output parameter USER_INPUT, representing the original content entered by the intelligent assistant user in this round of dialogue. Users can also add other parameters as needed.

[0039] The dialog end node is the final node in the workflow, used to return the results after the workflow has run. The dialog end node supports two return methods: returning variables and returning text. For the variable return mode, all input parameters are directly output in JSON format after the workflow has finished. For the text return mode, the dialog is replied to using a predefined template after the workflow has finished; the reply template can reference the input parameters. The dialog end node supports both streaming and non-streaming output methods.

[0040] Large model dialogue nodes can invoke large models to generate responses based on input parameters and prompt word templates. They are typically used for text generation tasks such as copywriting, text summarization, and knowledge-based question answering. Relying on the language understanding, image understanding, and generation capabilities of large models, large model nodes can handle complex natural language processing and multimodal tasks. Users can select different models based on their business needs and configure prompt words to define the model's persona and response style. To precisely control the model's generated results, users can also set model parameters (such as temperature, top_p, etc.) within the large model dialogue node. Large model dialogue nodes support both streaming and non-streaming output methods.

[0041] The knowledge base retrieval node is used to search a specified knowledge base based on user input, retrieve the most matching information, and return the search results in list format. Users can specify the knowledge base to search in two ways: 1. Directly select the documents needed for the actual application scenario from the documents already written to the knowledge base, click save and return, and the node will automatically populate the knowledge base set, partition, and scenario name; 2. Manually fill in the set name, partition name, and scenario name in the knowledge base set, partition, and scenario input text boxes. The knowledge base retrieval node supports three retrieval methods: semantic search, hybrid search, and question rewriting search. Users can choose the appropriate retrieval method to obtain the best search results. In addition, users can further improve the relevance and recall rate of the search results by adjusting the similarity threshold and top_k values, as well as setting relevant re-ranking parameters.

[0042] Code nodes support executing user-written code or code generated by large models to process input parameters and return results.

[0043] A selector node is a routing node used to design branching flows in a workflow. Users can add multiple branches. When the workflow reaches a selector node, it checks the conditions of each branch sequentially from top to bottom until a condition is met or all conditions are not met. If a condition is met, subsequent nodes of that branch are executed, and subsequent nodes of other branches are not executed. If all conditions are not met, subsequent nodes of the "other" branch are executed. For each branch, users can add multiple relational expressions, connecting them using AND and OR logical operators to form the condition of that branch.

[0044] The text processing node is used to process various types of input data into text of a specified format according to user-defined templates. It is suitable for scenarios such as secondary content summarization, text concatenation, and text escaping.

[0045] The message output node is used to output messages from the intermediate process, supporting both streaming and non-streaming output modes. Message output nodes have no output parameters and cannot be connected to any other nodes. Therefore, the output of a message output node is only used for display on the page; other nodes cannot reference its output.

[0046] The database node is used to perform database queries on a specified database. Users can enter a fixed SQL statement in the SQL content input text box, and the node will directly execute the SQL statement to perform the database query at runtime. Users can also enter a Jinja2-formatted SQL statement template that references input parameters in the SQL content input text box. At runtime, the node first uses the input parameters to populate the SQL statement template to obtain a complete SQL statement, and then executes the SQL statement to perform the database query.

[0047] The plugin tool node is used to invoke plugin tools within the workflow to extend the capabilities of the intelligent assistant. Currently, the platform supports three types of tools: remote APIs, functions, and MCP (Model Context Protocol). Remote API tools are primarily used to call services from the enterprise's business systems, enabling interaction between the intelligent assistant and these systems. Function tools are user-published tools used to handle specific tasks; for example, OCR tools are used to recognize text in images. MCP tools directly integrate with third-party MCP services, eliminating the burden of user-developed plugin tools.

[0048] Like selector nodes, intent recognition nodes are also routing nodes, used to understand and identify user intents such as questions, requests, and commands. This allows for further routing to different branches based on the identified user intent category. For example, in an intelligent customer service scenario, user questions are mainly divided into two categories: pre-sales consultation and after-sales service. The processing methods and processes for these two types of questions are not entirely the same. Therefore, when configuring intent recognition nodes, two intent categories can be defined: pre-sales consultation and after-sales service, each corresponding to a different processing branch. At runtime, the intent recognition node identifies the user's intent using a large model. If the identified intent is pre-sales consultation, the subsequent nodes of the pre-sales consultation branch are executed; if the identified intent is after-sales service, the subsequent nodes of the after-sales service branch are executed; if the identified intent does not belong to either of these two categories, the subsequent nodes of the other intent branches are executed.

[0049] Question-and-answer nodes are used to proactively collect user information, understand user intent, and confirm user authorization, representing a Human-in-the-Loop (HITL) mechanism. Some nodes in a workflow rely on user input, explicit intent, and permission granting. Question-and-answer nodes can collect this information using natural language or forms to ensure smooth workflow execution. When the workflow reaches a question-and-answer node, it will ask the user a specific question or display a form for them to fill out, then wait for the user to answer the question or complete the form. For example, in a weather query workflow, when a user sends a request to "check the weather for me," the question-and-answer node could ask, "Which day and city do you want to check the weather for?" or provide a text input box with both date and city fields for the user to fill in. The workflow will only continue after the user answers the question or completes the form and clicks "confirm."

[0050] The platform supports four types of agents: ReAct single agent, Plan-and-Execute multi-agent agent, Hierarchical multi-agent agent, and user-defined multi-agent agent. Each type of agent can be assigned workflow or tool-type skills, meaning that agents can solve specific problems by invoking workflows or tools. Each type of agent will be described in detail below.

[0051] ReAct agents are an advanced design concept for intelligent agents that combine reasoning and acting to enable agents to solve complex problems. The core idea of ​​ReAct agents is to simulate the human problem-solving process: first, analyze the given problem and reason about the appropriate behavior or strategy; then, take specific actions based on the reasoning results; observe the results of the actions; and then reason again based on the given problem and the action results, repeating this process until the problem is solved. This method helps overcome the problems of factual illusion and error propagation that may occur in traditional Chain of Thought (CoT) because the agent can interact with external knowledge sources to obtain additional information to verify or correct reasoning steps.

[0052] In specific implementations, ReAct agents typically follow the following workflow:

[0053] 1. Thinking: The intelligent agent first analyzes the current task or problem and formulates a preliminary strategy or plan.

[0054] 2. Action: Based on the preceding thought process, the intelligent system can perform specific actions, such as searching for relevant information on the Internet, calling an API to obtain data, or operating a physical device.

[0055] 3. Observation: The agent collects feedback after its actions, which may be content found on the Internet, data returned by APIs, or changes in the physical world.

[0056] 4. Repetition: The agent integrates the new information observed above into its cognitive framework and repeats this process until the task is completed or the preset goal is achieved.

[0057] This model makes agents more flexible and effective in handling complex tasks because it not only relies on an internal knowledge base but also dynamically adjusts its strategies in real time based on external feedback. The topology of the platform's ReAct agents is as follows: Figure 3 As shown. If the agent needs to invoke a tool or workflow, the program flow will jump to the tool or workflow node, and after invoking the tool or workflow, it will return to the agent node. The agent can invoke multiple tools or a single workflow at a time, and perform further reasoning based on the execution results of multiple tools or workflows. The agent can also repeatedly invoke tools or workflows until it believes it has obtained sufficient information to solve the problem. If the agent no longer needs to invoke tools or workflows, it will directly output the final result, and the program flow will jump to the end node.

[0058] Plan-and-Execute is a multi-agent architecture that handles complex tasks by first planning and then executing. It consists of a planning agent and an execution agent. It overcomes the limitations of the traditional ReAct (reasoning-action alternation) model, achieving efficient and accurate task closure through global task decomposition and dynamic adjustment. The planning and execution agent typically follows this workflow:

[0059] 1. Planning: The planning agent analyzes the questions, requests or instructions sent by the user, decomposes the objectives, generates a multi-step execution plan, and clarifies the task priorities and dependencies.

[0060] 2. Execution: The execution agent calls tools or workflows to execute a step according to the execution plan and feeds back the execution result to the planning agent.

[0061] 3. Loop: The planning agent dynamically adjusts its strategy based on the final goal, the execution plan, and the execution result of the previous execution agent, updates the execution plan, and the execution agent executes one step according to the updated execution plan. This process is repeated until the planning agent determines that the final goal has been achieved and directly outputs the final result.

[0062] The topology of the platform's planning and execution agents is as follows: Figure 4 As shown.

[0063] Hierarchical multi-agent architecture is a classic multi-agent architecture. It borrows the hierarchical concept from human organization and social structures, organizing agents into different levels according to their functions, responsibilities, permissions, or levels of abstraction. Higher-level agents supervise, guide, coordinate, and control lower-level agents in some form, while lower-level agents are responsible for executing specific, localized tasks assigned by higher-level agents. By introducing a hierarchical structure, strategic planning, tactical coordination, and specific execution are distributed to agents at different levels. The coordination, control, guidance, and information flow between levels are used to organize the behavior of large-scale agents, reducing the overall complexity of the system, improving decision-making efficiency, ensuring consistency of global goals, and enhancing the manageability and scalability of the system.

[0064] The platform's hierarchical multi-agent architecture employs a two-layer agent design. The higher-layer agent is the supervisory agent, responsible for goal decomposition and task allocation. The lower-layer agents are multiple execution agents, responsible for executing the specific tasks assigned by the supervisory agent. Similar to the planning agent in the planning-execution agent, the supervisory agent also decomposes the user's questions, requests, or instructions into multiple executable subtasks and assigns each subtask to the most suitable execution agent. Each execution agent has a task queue for storing and retrieving subtasks assigned by the supervisory agent. Upon receiving a subtask, the execution agent executes the subtasks in the task queue sequentially and returns the execution result to the supervisory agent. If there are dependencies between subtasks, the supervisory agent must wait for the previous subtask to complete before sending the result of the previous subtask and the next subtask to the most suitable agent. If there are no dependencies between subtasks, the supervisory agent can assign multiple subtasks to execution agents simultaneously. The same execution agent can only execute received subtasks sequentially; different execution agents can execute subtasks in parallel. The topology of the platform's hierarchical multi-agent architecture is as follows: Figure 5 As shown.

[0065] If the platform's built-in inference-action agents, planning-execution multi-agents, and hierarchical multi-agents still cannot meet the user's needs, the user can customize personalized multi-agents through the platform's agent visual orchestration engine. Similar to workflow orchestration, users only need to drag and drop nodes onto the canvas and connect them in a certain order to build personalized multi-agents. Unlike workflows, the agent visual orchestration engine adds agent nodes, where users can configure the agent's skills, including tool skills and workflow skills.

[0066] All agents on the platform include a memory module. The memory module plays a crucial role in the agent's architecture design, storing information perceived from the environment, past plans and behaviors, interactions and feedback with the environment, and so on. The agent uses this stored memory for task planning and execution. The memory module helps the agent accumulate experience, evolve, and behave in a more consistent, rational, and efficient manner.

[0067] The platform's agent memory module is designed with the principles and mechanisms of human memory processes in mind. Human memory can be categorized into sensory memory, short-term memory, and long-term memory based on its retention time in the brain. Short-term memory is similar to the model's context window; while long-term memory is like an external vector storage that can be quickly retrieved when needed. The platform's memory module supports the storage of both short-term and long-term memory. Short-term memory primarily stores the dialogue history and behavior records between the user and the agent, stored according to the dialogue dimension. During interactions with the user, the agent makes decisions, plans, and takes actions based on the context of the dialogue history and behavior records. Long-term memory primarily stores personalized information about the user, such as frequently asked questions, areas of interest, and personal preferences, stored according to the user dimension. The accumulation of long-term memory helps build user profiles, thereby providing more personalized services and improving the user experience.

[0068] The platform's intelligent agent supports a reflection and self-correction mechanism, which users can choose to enable or disable as needed. This mechanism simulates the human cognitive process of "post-event review - problem identification - behavior adjustment," enabling the agent to move beyond simply relying on pre-set rules or steps to perform tasks. Instead, it allows for dynamic evaluation of its own behavior and proactive strategy optimization. Through this mechanism, the agent can achieve continuous improvement, enhancing its robustness and reliability.

[0069] The platform uses external tools and evaluation models to verify and analyze the execution results of key steps in the agent's task execution. For example, the compiler is used to verify the code generated by the agent for syntax errors, and the evaluation model is used to evaluate the rationality of the task plan generated by the agent. When the external tools pass the verification or the evaluation model gives a positive evaluation, the agent continues to execute; otherwise, the agent needs to adjust its strategy based on the feedback from the verification tools or evaluation model and redo the task planning and execution.

[0070] The key technical points of this invention mainly include: 1. A multimodal knowledge base, including multimodal document parsing, multimodal data embedding, and multimodal data retrieval; 2. A workflow visualization orchestration engine, supporting users to quickly build workflows and perform real-time debugging through node drag-and-drop and connection; 3. A plug-in tool development component, supporting users to develop and publish custom plug-in tools and access enterprise internal services and MCP services; 4. An automated intelligent agent building engine, supporting users to build various predefined types of intelligent agents through simple configuration and to build custom multi-intelligent agents in a workflow-like orchestration manner; 5. One-click intelligent assistant publishing, supporting users to publish intelligent assistants to enterprise business systems or third-party platforms.

[0071] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A low-code enterprise-level intelligent assistant development platform, comprising an application layer, a platform layer, a capability layer, and underlying services, characterized in that: The core modules of the application layer, platform layer, capability layer, and underlying services include: RAG engine, workflow engine, intelligent agent engine, model service management, plug-in tool management, relational database management, cache database management, vector database management, object storage management, monitoring and logging, role assignment and permission management, historical session management, and environment configuration.

2. The low-code enterprise-level intelligent assistant development platform according to claim 1, characterized in that: The platform supports two types of knowledge bases: plain text knowledge bases and multimodal knowledge bases. Plain text knowledge bases only support storing and retrieving text fragments, while multimodal knowledge bases not only support storing and retrieving text fragments, but also support storing and retrieving images and tables. When creating a new knowledge base, users can choose the knowledge base type according to their needs.

3. The low-code enterprise-level intelligent assistant development platform according to claim 1, characterized in that: The knowledge base supports three retrieval methods: semantic retrieval, hybrid retrieval, and question rewriting.

4. The low-code enterprise-level intelligent assistant development platform according to claim 1, characterized in that: The platform supports building workflow and agent-type intelligent assistants, each with its own advantages and disadvantages, and suitable for different application scenarios.

5. The low-code enterprise-level intelligent assistant development platform according to claim 1, characterized in that: The platform provides a visual canvas where users can drag and drop nodes and connect them in a specific order to quickly build a workflow. Users can also debug individual nodes within the workflow or debug the entire workflow.

6. The low-code enterprise-level intelligent assistant development platform according to claim 1, characterized in that: The platform supports four types of agents: ReAct single agent, Plan-and-Execute multi-agent, Hierarchical multi-agent, and user-defined multi-agent. Each type of agent can be assigned workflow or tool skills, meaning that agents can solve specific problems by invoking workflows or tools.

7. The low-code enterprise-level intelligent assistant development platform according to claim 1, characterized in that: All agents on the platform contain a memory module, which plays a very important role in the design of the agent architecture. It stores information perceived from the environment, past plans and behaviors, and interactions and feedback with the environment. The agent uses the stored memory to plan and execute tasks. The memory module helps the agent accumulate experience, evolve itself, and behave in a more consistent, reasonable and effective manner.

8. The low-code enterprise-level intelligent assistant development platform according to claim 1, characterized in that: The platform's intelligent agent supports a reflection and self-correction mechanism. Users can choose whether to enable this function as needed. The reflection and self-correction mechanism simulates the human cognitive process of "post-event review - problem discovery - behavior adjustment". This enables the intelligent agent to no longer rely solely on preset rules or steps to perform tasks, but to dynamically evaluate its own behavior and proactively optimize its strategies. With the help of this mechanism, the intelligent agent can achieve continuous improvement and enhance its robustness and reliability.

Images