A dual end split cooperative system and method thereof

Abstract

The application relates to the technical field of software system architecture, and provides a double-end separation type collaborative system and a method thereof. The system adopts a double-end separation type architecture, and comprises a client and a middle platform management platform in communication connection with the client; the client carries AI application layer interaction, demand analysis and local tool arrangement, and a function manager thereof comprises multiple function instances, a middle platform access agent module and an environment detection module; the middle platform management platform carries centralized management and safety control of knowledge assets, and comprises an API gateway layer, a knowledge base service layer and a platform control service layer. When the system is running, all knowledge retrieval requests of the client must be subjected to identity authentication and permission verification of the middle platform management platform before being executed, and retrieval results and operation logs are recorded in a full-link structured manner. The application realizes hierarchical control of AI application and knowledge assets, the knowledge assets are uniformly managed by the middle platform and can be independently supplied to multiple clients for reuse, and knowledge access has user-level traceable safety control capability.

Description

Technical Field

[0001] This application relates to the field of software system architecture technology, specifically to a dual-end separated collaborative system and its method. Background Technology

[0002] In recent years, artificial intelligence (AI) technology has been widely applied in the field of research and development assistance. In various R&D scenarios, the use of large language models combined with domain knowledge retrieval enhancements to assist engineers in completing tasks such as code generation, solution design, specification checks, and test case generation has become an important means of improving R&D efficiency. A typical deployment method for these AI-assisted capabilities is to build and deploy the AI ​​model, domain knowledge base, and retrieval service as a complete system. The invocation of the AI ​​model and the retrieval of the knowledge base are completed within the same system, and the knowledge data exists as local files, embedded databases, or resource packages distributed with the system, attached to the AI-assisted tools.

[0003] Before the advent of AI-assisted technologies, in the traditional workflow of complex engineering research and development such as FPGAs, engineers used multiple independent tools to complete different stages of the work. Each tool had its own independent user interface, license management, and data format. Engineers had to switch back and forth between different tools and manually transfer design data files. Some EDA tools provided license servers for authorization management, but these license servers only implemented simple authorization verification functions and did not involve knowledge base management, user permission classification, or operation auditing. With the introduction of AI technology, existing R&D assistance systems continued the above-mentioned independent deployment mindset, binding AI capabilities to specific tools or specific knowledge bases to form functionally complete but fragmented independent systems. Knowledge data existed as local files or resource packages distributed with the system, attached to the AI-assisted tools.

[0004] However, the deployment methods of the aforementioned existing technologies have at least the following technical drawbacks: First, existing R&D support systems employ an integrated architecture for their AI capabilities and knowledge assets, with the execution logic of AI applications and the retrieval services of the knowledge base running within the same system. While some systems offer knowledge retrieval interfaces via APIs, their architecture is not designed with the separation and management of AI applications and knowledge assets in mind. They lack a collaborative architecture that supports independent execution of AI applications on the client side, unified management of knowledge assets in a central platform, and secure communication between the two. CN110659515B uses encrypted IP data, AI-assisted design service modules, and EDA tools to form a closed-loop cloud environment. The IP knowledge data is only available for internal use within the cloud platform and cannot be used as an independent knowledge asset by other AI support tools outside the platform. CN122046365A embeds a compliance knowledge base as a built-in component of the security and compliance layer, binding knowledge to the system and preventing independent accumulation and cross-system reuse.

[0005] Second, in existing solutions, some systems implement user authentication through JWT or CAS, some implement access control through RBAC or ABAC, and some implement operation traceability through log auditing. However, these functions usually exist as independent security mechanisms and have not been integrated into a unified management and control system that integrates user-level authentication, resource-level permission verification, and end-to-end auditing and traceability within the same system architecture. Existing EDA toolchains (Vivado / Quartus, etc.) license servers only verify the validity of licenses and do not involve permission mapping between user identity and knowledge base type; CN121144130A (FPGA simulation and testing system based on RAG) and US20260057184A1 (FPGA design context-aware retrieval system) do not involve client-server separation architecture design, nor do they involve unified management and permission control of multiple types of knowledge bases; CN119312758B (an open integrated circuit collaborative design cloud platform and method) adopts a centralized architecture of multi-agent collaboration, with all agents running under the same framework, without independent knowledge base services and access control; CN122046365A uses the CAS protocol to implement unified identity authentication, but after successful authentication, users can call all system resources, without setting permission verification for knowledge base access that is independent of system login. CN117972787A uses JWT for user authentication and combines it with MySQL for permission queries. However, its authentication and permission verification services are only applicable to general question-and-answer scenarios in large-scale knowledge bases. It does not address fine-grained permission control for various types of knowledge bases in the FPGA field (IP core libraries, design specification libraries, technical document libraries, project case libraries). Furthermore, in its front-end and back-end architecture, the front-end only acts as a request forwarder and lacks the ability for AI applications to execute independently on the client side. CN121786865A implements RBAC+ABAC permission control and hash chain auditing for AI knowledge bases, but it focuses on permission decision efficiency and policy optimization algorithms rather than the separation and collaborative working mode of AI applications and knowledge assets at the system architecture level.

[0006] Third, existing knowledge access auditing solutions are typically implemented as an additional, standalone security feature rather than an integral part of the system architecture. For example, CN110659515B records IP authorization and usage records via blockchain, requiring additional deployment of blockchain nodes and post-event query mechanisms; CN122046365A generates a compliance audit report at the pipeline exit, which is a phased inspection method. These auditing methods lack an architectural-level binding to the knowledge access process itself, making it impossible to synchronously collect structured audit logs every time a knowledge retrieval request passes through the security gateway. Summary of the Invention

[0007] To address the technical issues in the existing technologies where AI applications and knowledge assets are built in an integrated manner, lacking a collaborative architecture that supports independent execution of AI applications on the client side, unified management of knowledge assets in the middle platform, and secure interaction between the two, this application provides a dual-end separated collaborative system and method to achieve architectural decoupling of AI applications and knowledge assets, and ensure unified management of knowledge assets and secure and controllable knowledge access.

[0008] This dual-end discrete architecture is versatile and can be extended to AI-assisted scenarios in other R&D fields, such as industrial embedded development, automotive software, and EDA / CAD toolchain integration. This application uses the FPGA R&D scenario as a specific implementation scenario for detailed description.

[0009] The technical solution is as follows: Firstly, this application provides a dual-end separated collaborative system, which adopts a dual-end separated architecture and includes a client and a middleware management platform that communicates with the client: The client includes a function manager, which comprises multiple function instances, a middleware access proxy module, and an environment detection module. The function instances are used to execute internal logic operations of the AI ​​application layer locally on the client. These internal logic operations are independent operations that can be executed without the support of the middleware knowledge base, including at least one of multi-turn dialogue interaction, preliminary data processing based on local rules, and code framework generation based on a local model. The middleware access proxy module manages user identity tokens. When knowledge support is required during the execution of the internal logic operations by a function instance, it responds to the knowledge retrieval request issued by the function instance, encapsulates the knowledge retrieval request and the locally cached user identity token into a knowledge retrieval request, and sends it to the middleware management platform. The environment detection module detects external tools locally on the client when external tools need to be called during the execution of the function instances, and starts the external tools as a child process. The middleware management platform includes an API gateway layer, a knowledge base service layer, and a platform control service layer. The API gateway layer receives the knowledge retrieval request and performs identity authentication and permission verification on the request. The knowledge base service layer performs the retrieval operation after the permission verification is passed and returns the retrieval results to the functional instance. The platform control service layer provides user management, permission control, and security audit services. In this case, each access to the knowledge base service layer by the functional instance is executed through the middle platform access proxy module and the API gateway layer.

[0010] In one embodiment, the environment detection module is configured to automatically perform the following operations in response to an external tool call request issued by the functional instance during the execution of the internal logic operation: Based on the tool type identifier field in the external tool call request, the corresponding executable program or application registration information is queried in the preset search path and environment variables of the local operating system; when the external tool is detected to be installed, the executable file path or startup command of the external tool is obtained, and the external tool is started as a subprocess; when the external tool is detected to be not installed, prompt data is returned to the function instance.

[0011] In one embodiment, taking JWT as an example, the user identity token is a JWT token (this application is not limited to this, and those skilled in the art can use other identity token mechanisms according to actual needs). The payload of the JWT token stores at least a user identifier field, a role identifier field, permission list data, and a token validity period timestamp. When the API gateway layer performs permission verification on the knowledge retrieval request, it directly extracts the permission list data from the payload of the JWT token, queries the current user's retrieval permissions on the target knowledge base type based on the permission list data, and blocks the knowledge retrieval request when the permission list data does not contain the retrieval permissions for the target knowledge base type.

[0012] In one embodiment, the functional instances include at least one of design assistance functions, coding assistance functions, verification assistance functions, and document generation functions; the external tools include at least one of integrated design tools, code editors, and simulation tools.

[0013] In one embodiment, the API gateway layer includes an authentication middleware, an authorization middleware, a logging middleware, and a rate limiting middleware connected in sequence. The knowledge retrieval request is sequentially processed by the authentication middleware (JWT token verification), the permission middleware (RBAC permission verification), the log middleware (structure recording), and the rate limiting middleware (request frequency control) in the API gateway layer before it can be processed by the knowledge base service layer.

[0014] In one embodiment, the knowledge base of the knowledge base service layer includes at least one or more of the following: FPGA IP core library, design specification library, technical document library, and project case library.

[0015] In one embodiment, the knowledge base service layer resides in the middle platform management platform. The functional instance has no right to directly access the underlying search engine of the knowledge base service layer. Each search request of the functional instance is forwarded to the knowledge base service layer through the middle platform access proxy module and the API gateway layer, and then executed uniformly by the knowledge base service layer.

[0016] In one embodiment, the platform management service layer includes a user management module, an RBAC permission control module, and a security log auditing module; the user management module is used to perform identity authentication on login credentials and generate a user identity token containing user permission data after successful authentication; the RBAC permission control module is used to configure the association between user roles and knowledge base access permissions; the security log auditing module is used to record the operation logs of knowledge retrieval requests initiated by the client.

[0017] Secondly, this application also provides a client-side collaboration method for a dual-end separated collaborative system. The client-side collaboration method includes: In response to the login command entered by the user, the login credentials are collected and sent to the middleware management platform; Receive the user identity token returned by the middle platform after successful authentication, and write the user identity token into the local token cache; In response to a user's input function call command, the corresponding function instance is loaded, and the function instance is controlled to execute internal logic operations locally on the client. The internal logic operations are operations that can be executed independently without the support of a middleware knowledge base. When the functional instance needs knowledge support during the execution of the internal logic operation, it reads the user identity token from the local token cache, encapsulates the user identity token and the knowledge retrieval requirement into a knowledge retrieval request, and sends the knowledge retrieval request to the middle platform management platform. The system receives the knowledge retrieval results returned by the knowledge base service layer and returns the knowledge retrieval results to the functional instance so that the functional instance can continue to execute the internal logic operation.

[0018] Thirdly, this application also provides a collaborative method for a middleware management platform in a dual-end separated collaborative system. The middleware management platform collaborative method includes: Receive login credentials sent by the client, perform identity authentication on the login credentials, generate a user identity token containing user permission data after successful authentication, and return the user identity token to the client; Receive a knowledge retrieval request sent by the client, wherein the knowledge retrieval request contains at least the user identity token; The system performs identity authentication and permission verification on the knowledge retrieval request, confirms the validity of the user identity token, and determines whether the current user has access to the requested knowledge base based on the user permission data in the user identity token. When the permission verification is successful, the knowledge base service layer of the middle platform management platform will uniformly perform the retrieval operation. The client does not have the right to directly access the underlying retrieval engine of the knowledge base service layer. The search results are returned to the client, and the log data of this knowledge retrieval operation is written to the security log audit module. The knowledge base service layer resides on the middleware management platform, and the client has no right to directly access the underlying search engine of the knowledge base service layer.

[0019] This application adopts a dual-end separation architecture of client and middleware management platform, decoupling AI-assisted capabilities from knowledge assets: the client focuses on the execution of AI-assisted capabilities, with internal logic running locally, resulting in fast response speed; at the same time, the client automatically detects the local R&D design toolchain environment and automatically calls external tools as needed; the middleware management platform focuses on knowledge asset management and security control, with domain knowledge assets uniformly stored and managed in the middleware; when the client needs knowledge enhancement, it must initiate a retrieval request to the middleware carrying the user's identity token. The middleware performs identity authentication and permission verification on each request, and after passing the verification, performs the retrieval within the limited knowledge base, returns the results, and records a full-link structured log, supporting abnormal behavior warnings and multi-dimensional audit traceability.

[0020] At least the following technical effects compared to existing technologies: AI-assisted capabilities are decoupled from knowledge assets, enabling centralized management and maintenance of knowledge. The same knowledge asset can be reused by multiple clients, avoiding duplicate storage and inconsistency. Knowledge access is upgraded from "no authentication / shared key" to "end-to-end user-level authentication and permission verification and structured audit logs," meeting the security and compliance requirements of classified R&D scenarios (including FPGA R&D scenarios). Knowledge is transferred from personal file systems and data silos of various tools to a unified management platform, allowing for real-time retrieval of knowledge support during the R&D process. Knowledge retrieval efficiency is improved from "manually browsing folders" to "second-level intelligent retrieval." Attached Figure Description

[0021] Figure 1 A structural block diagram of a dual-end split-type cooperative system provided in one embodiment. Figure 2 A block diagram of a dual-end discrete collaborative system for FPGA application scenarios; Figure 3 A flowchart of client user login and middleware identity authentication provided in one embodiment; Figure 4A flowchart illustrating a client-side collaboration method for a dual-end, separate collaborative system, as provided in one embodiment; Figure 5 This is a flowchart illustrating a collaborative method for a middleware management platform in a dual-end, separate collaborative system, as provided in one embodiment. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0023] This application provides a dual-end separated collaborative system. The system employs a dual-end separated architecture, where the client-side carries AI-assisted capabilities for local execution and automatically detects and calls to the local toolchain. The middleware management platform centrally manages knowledge assets and provides unified authentication, permission verification, and log auditing services. Clients must undergo authentication and permission verification by the middleware platform before accessing knowledge enhancement. This system decouples AI-assisted capabilities from knowledge assets, allowing knowledge assets to be reused across systems and tools as independent organizational assets. Furthermore, it enables user-level authentication for knowledge access, fine-grained permission verification at the knowledge base level, and end-to-end operation auditing and traceability. This fundamentally solves the technical problems of tight coupling between AI capabilities and knowledge, and the lack of secure control over knowledge access in existing technologies.

[0024] like Figure 1 As shown, in one embodiment, a dual-end separated collaborative system is provided, employing a dual-end separated architecture. It includes a client and a middleware management platform, with the client communicating with the middleware management platform. Optionally, the client and the middleware management platform communicate via the HTTPS protocol. The client includes a function manager and a toolchain. The middleware management platform includes an API gateway layer, a knowledge base service layer, and a platform control service layer. This dual-end separated architecture has good versatility and can be extended to AI-assisted scenarios in other R&D fields, such as industrial embedded development, automotive software, and EDA / CAD toolchain integration.

[0025] The function manager includes multiple function instances, a middleware access proxy module, and an environment detection module. The function instances are used to execute internal logic operations of the AI ​​application layer locally on the client side. These internal logic operations are independent operations that can be executed without the support of a middleware knowledge base. They include at least one of multi-turn dialogue interaction, preliminary data processing based on local rules, and code framework generation based on a local model.

[0026] The middle platform access proxy module is used to manage user identity tokens. When the functional instance needs knowledge support during the execution of the internal logic operation, it responds to the knowledge retrieval request issued by the functional instance, encapsulates the knowledge retrieval request and the locally cached user identity token into a knowledge retrieval request, and sends it to the middle platform management platform. The environment detection module is used to detect the external tool locally on the client when the functional instance needs to call the external tool during the execution of the function, and start the external tool in the form of a child process.

[0027] The toolchain includes at least one external tool.

[0028] The middleware management platform includes an API gateway layer, a knowledge base service layer, and a platform control service layer. The API gateway layer receives the knowledge retrieval request and performs identity authentication and permission verification on the request. The knowledge base service layer performs the retrieval operation after the permission verification is passed and returns the retrieval results to the functional instance. The platform control service layer provides user management, permission control, and security audit services. In this case, each access to the knowledge base service layer by the functional instance is executed through the middle platform access proxy module and the API gateway layer.

[0029] Furthermore, the environment detection module is used to automatically perform the following operations in response to an external tool call request issued by the functional instance during the execution of the internal logic operation of the functional instance: Based on the tool type identifier field in the external tool call request, the corresponding executable program or application registration information is queried in the preset search path and environment variables of the local operating system; when the external tool is detected to be installed, the executable file path or startup command of the external tool is obtained, and the external tool is started as a subprocess; when the external tool is detected to be not installed, prompt data is returned to the function instance.

[0030] Furthermore, the functional examples include at least one of design assistance functions, coding assistance functions, verification assistance functions, and document generation functions; the external tools include at least one of integrated design tools, code editors, and simulation tools.

[0031] Furthermore, the API gateway layer includes an authentication middleware, an authorization middleware, a logging middleware, and a rate limiting middleware connected in sequence; the authentication middleware is used to perform token verification on the user's identity token; the authorization middleware is used to perform authorization verification on knowledge retrieval requests; the logging middleware is used to collect structured log data on requests passing through the API gateway layer; and the rate limiting middleware is used to control the frequency of requests from the same user within a unit of time.

[0032] The knowledge retrieval request is sequentially processed by the authentication middleware (JWT token verification), the permission middleware (RBAC permission verification), the log middleware (structure recording), and the rate limiting middleware (request frequency control) in the API gateway layer before it can be processed by the knowledge base service layer.

[0033] The platform management service layer provides user management, access control, and security auditing services; it includes a user management module, an access control module, and a security log auditing module. The user management module is used to perform identity authentication on login credentials and generate a user identity token containing user permission data after successful authentication. The access control module is used to configure the association between user roles and knowledge base access permissions; The security log auditing module is used to record the operation logs of knowledge retrieval requests initiated by the client.

[0034] In this embodiment, the API gateway layer, knowledge base service layer, and platform management service layer work together to integrate user-level authentication, knowledge base type-level permission verification, and end-to-end structured logging into a unified knowledge access control system. Specifically, the API gateway layer is responsible for real-time execution: each knowledge retrieval request passing through the API gateway layer sequentially undergoes authentication (verifying user identity), permission (verifying target knowledge base access permissions), and logging (collecting structured logs of requests and results). The knowledge base service layer is responsible for controlled retrieval: retrieval is only executed after permission verification is passed; clients have no direct access to the underlying retrieval engine. The platform management service layer is responsible for basic management: the user management module maintains user identity and permission data, the permission control module configures knowledge base access policies, and the security log auditing module stores audit logs and provides traceability queries. These three service layers are clearly hierarchical and complementary, forming a complete closed loop from policy configuration to request processing to controlled retrieval.

[0035] The dual-end separated collaborative system provided in this application has good versatility. The following description uses an FPGA R&D scenario as a specific embodiment, but those skilled in the art should understand that the dual-end separated architecture of this application is not limited to the FPGA scenario, and can also be extended to industrial embedded development scenarios (client-side detection of embedded toolchains such as Keil / IAR), EDA / CAD toolchain integration scenarios (automatic orchestration of design tools such as 3D / Ansys), automotive-grade chip and software R&D scenarios (unified security compliance management in confidential scenarios), and other R&D fields with collaborative needs of "AI assistance + knowledge base + multiple toolchains".

[0036] like Figure 2As shown, in one embodiment, the user identity token is a JWT token, and the payload of the JWT token stores at least a user identifier field, a role identifier field, permission list data, and a token validity period timestamp. The permission verification performed by the permission middleware includes: extracting the target knowledge base type field from the knowledge retrieval request; querying the current user's retrieval permission policy data for the target knowledge base type based on the role identifier field and the permission list data; if the permission list data does not contain retrieval permissions for the target knowledge base type, then blocking the knowledge retrieval request and triggering an unauthorized access warning.

[0037] The knowledge base service layer is used to perform a retrieval operation in the corresponding knowledge base according to the knowledge retrieval request and return the retrieval results after the permission verification is passed; the knowledge base of the knowledge base service layer includes at least one of the following: FPGA IP core library, design specification library, technical document library and project case library.

[0038] The knowledge base service layer resides in the middle platform management platform. The functional instance has no right to directly access the underlying search engine of the knowledge base service layer. Each search request of the functional instance is forwarded to the knowledge base service layer through the middle platform access proxy module and the API gateway layer, and then executed uniformly by the knowledge base service layer.

[0039] The platform management service layer includes a user management module, an RBAC permission control module, and a security log auditing module. The user management module is used to perform identity authentication on login credentials and generate a user identity token containing user permission data after successful authentication. The RBAC permission control module is used to configure the association between user roles and knowledge base access permissions. The security log auditing module is used to record the operation logs of knowledge retrieval requests initiated by the client.

[0040] Based on the same inventive concept, this application also provides a client-side collaboration method for a dual-end separated collaborative system, applied to the aforementioned dual-end separated collaborative system. The client-side collaboration method includes: In response to the login command entered by the user, the login credentials are collected and sent to the middleware management platform; Receive the user identity token returned by the middle platform after successful authentication, and write the user identity token into the local token cache; In response to a user's input function call command, the corresponding function instance is loaded, and the function instance is controlled to execute internal logic operations locally on the client. The internal logic operations are operations that can be executed independently without the support of a middleware knowledge base. When the function instance needs to call an external tool during execution, the corresponding external tool is detected in the local operating system and the external tool is started as a child process; When the function instance requires knowledge support during execution, it automatically reads the user identity token from the local token cache, encapsulates the user identity token and knowledge retrieval requirements into a knowledge retrieval request, and sends it to the knowledge base service layer of the middle platform management platform for retrieval after identity authentication and permission verification by the middle platform management platform. The system receives the knowledge retrieval results returned by the middle platform management platform and returns the knowledge retrieval results to the functional instance so that the functional instance can continue to execute the internal logic operation.

[0041] The interaction flow of a dual-end separated collaborative system provided in this application is as follows: 1. The client serves as a unified operation entry point: The client is the main entry point for users to conduct R&D operations. Users invoke various AI-assisted capabilities through natural language commands in the terminal interface. The client acts as a unified operation hub, automatically scheduling and calling the R&D design toolchain in the local environment according to the actual needs during the execution process.

[0042] The specific interaction process is as follows: After entering a login command on the terminal and completing identity authentication, the user can access various AI-assisted capabilities. The user invokes a specific AI-assisted capability (such as design assistance or coding assistance) via natural language commands. Upon receiving the command, the client performs requirement analysis and task breakdown locally. When domain knowledge support is required during execution (e.g., IP core parameter query or design specification retrieval in FPGA scenarios), the client automatically sends a knowledge retrieval request carrying the user's identity token to the management platform. After identity verification and permission checks, the platform returns the retrieval results, which the client then integrates and presents to the user in text format. When external tools need to be invoked during execution (e.g., opening an editor after generating code or starting a simulation tool after generating test cases), the client automatically detects and opens the corresponding tools installed in the local environment, achieving fully automated integration from requirement input to tool invocation. The user completes all operations within the terminal, without manually switching between different tools or transferring data.

[0043] 2. Coding assistance and verification assistance interaction (taking FPGA R&D scenario as an example): After the user invokes the coding assistance capability in the terminal, the client loads the design scheme data (target FPGA device model, interface protocol definition, module division information) and automatically performs the following process: when IP core instantiation template or manufacturer coding specifications are required, knowledge is retrieved through the middle platform; based on the acquired knowledge, an HDL code framework is generated locally, and the client automatically detects code editors such as VS Code in the local environment, opens them, and loads the generated code framework into the editor for engineers to improve.

[0044] After completing code editing, engineers invoke verification assistance capabilities in the terminal. The client submits the code data, and the platform retrieves historical verification cases (searching for historical verification schemes of similar designs from the project case library) to assist in generating test cases. After the test cases are generated, the client automatically detects simulation tools such as ModelSim / VCS in the local environment, starts the simulation tools, and loads the test cases to execute verification. Issues discovered during verification are fed back to the client through the platform. Engineers then correct the code in the editor based on the feedback and invoke the verification capability again for iteration until verification passes.

[0045] 3. The middle platform management system is used for knowledge base management: The middleware management platform provides web-based knowledge base management functionality. Knowledge management personnel (or users with knowledge management permissions) can log in to the middleware management platform via a web browser and access the knowledge base management module. This module supports unified management of multiple types of knowledge bases. Taking FPGA R&D scenarios as an example, it includes unified management of four types of knowledge bases: FPGA IP core library, design specification library, technical document library, and project case library. This includes uploading new knowledge files or structured data, editing existing knowledge entries, searching and filtering knowledge content by category tags, and managing knowledge versions and review status. The content in the knowledge base is available for clients to retrieve and access in real time during runtime via a REST API, enabling "manage once, consume multiple times" of knowledge.

[0046] 4. The middleware management platform is used for user management and permission configuration: The middleware management platform provides web-based user management and permission configuration functions. System administrators log in to the platform via a web browser and access the user management module. This module supports creating user accounts, assigning organizational departments, and configuring role information. In the permission configuration interface, administrators can set function access permissions (i.e., which AI-assisted capabilities the user can access) and knowledge base access permissions (i.e., which knowledge bases the user can search) for each user or role. Every knowledge retrieval request initiated by the client undergoes permission verification by the middleware platform. The management platform also provides an operation log auditing interface, displaying all user operation records in a list format, supporting multi-dimensional filtering and querying by time, user, operation type, and other dimensions.

[0047] The specific implementation process of a dual-end separated collaborative system is as follows: Step S1: Client user login and middleware identity authentication, such as... Figure 3 As shown: Step S101: The user enters a login command (e.g., zhiqing login) on the terminal. The client interactively collects login credential data from the user. This login credential data includes at least a user account field and a user password field.

[0048] Step S102: The client's middleware access proxy module sends the login credential data to the middleware management platform's API gateway layer via an HTTPS request. The API gateway layer then forwards the login credential data to the user management module to perform authentication. The user management module receives login credential data and queries the corresponding user record data from the user account field in the preset user information database. When the user account field does not exist in the user information database, the system returns an "account does not exist" error response to the client, and the process terminates. When a user account exists but the password field does not match the password hash value stored in the database, an "incorrect password" error response is returned to the client, and the login failure record is written to the security log audit module, at which point the process terminates. When a user account exists and the password verification is successful, the user management module obtains the user's role identifier field and permission list data.

[0049] Step S103: The user management module generates a user identity token (using JWT as an example, but this application is not limited to this). The user identity token includes at least a user identifier field, a role identifier field, permission list data, a token validity period timestamp, and a token signature data.

[0050] Step S104: The user management module returns the user identity token to the middleware access proxy module on the client. The middleware access proxy module writes the user identity token to the local token cache and sets the local token expiration reminder time (earlier than the token validity period timestamp, automatically triggering a refresh operation when the token is about to expire).

[0051] Step S105: The client displays a login success message to the user, and the client's function call environment initialization is complete.

[0052] Step S2: Function Invocation and Local Execution. The specific steps are as follows: Step S201: The user enters a function call command (such as zhiqing design "..." or zhiqing code) in the terminal. The function manager of the client receives the function call request data entered by the user. The function call request data includes at least a function type identifier field (at least one of design / code / verify / docgen) and a request parameter field.

[0053] Step S202: The function manager loads the corresponding function instance from the preset function registry based on the function type identifier field. The function registry pre-stores the type identifier, version number, entry function, and dependency configuration data of each function.

[0054] Step S203: The function instance executes the internal logic operation of the function in the client's local environment. The internal logic operation is an operation that can be executed independently without the support of the middleware knowledge base, and includes at least one or more of the following: Engage in multi-round dialogues with users (such as collecting details of design requirements); Perform preliminary data processing (such as text formatting and keyword extraction) based on local rules or local lightweight models. Call the local LLM to perform basic code framework generation (when a local model is configured); Display and present the processing results to the user.

[0055] Step S204: When a functional instance needs FPGA knowledge support during the execution of internal logic operations (including but not limited to: design assistance functions need to retrieve IP core parameters for selection recommendation, coding assistance functions need to retrieve IP core instantiation templates, coding assistance functions need to retrieve manufacturer coding specifications for specification alignment check, and verification assistance functions need to retrieve historical verification cases to assist in test case generation), the functional instance sends the knowledge retrieval request to the middle platform access agent module.

[0056] Step S205: When a functional instance needs to call an external tool during the execution of its internal logic operations (including but not limited to: opening the generated code for engineers to edit in an editor after coding auxiliary functions, executing test cases in a simulation tool after verifying auxiliary functions, and creating a task in a project management tool after designing auxiliary function output schemes), the functional instance sends external tool call request data to the client's environment detection module. This request data includes at least a tool type identifier field (at least one of editor / simulator / synthesizer / project-manager) and a call parameter field.

[0057] Step S206: The client's environment detection module receives external tool call request data and performs automatic local environment detection operations: The environment detection module queries the corresponding executable program or application registration information in the local operating system's preset search path and environment variables based on the tool type identifier field. When the corresponding external tool is detected to be installed, the environment detection module obtains the executable file path or startup command of the tool, starts the external tool as a subprocess, and passes the output data of the functional instance (such as code file path, test case file path, and solution document path) as parameters to the started external tool. When the corresponding external tool is not detected to be installed, the environment detection module returns the prompt data "No corresponding tool detected, please install manually" to the functional instance. The functional instance displays the prompt data to the user and the process continues to execute (the functional instance can still output the results in text form in the terminal).

[0058] Step S3: The client initiates a knowledge retrieval request and permission verification to the middleware platform. The specific steps are as follows: Step S301: The middleware access agent module receives knowledge retrieval request data sent by the functional instance. This knowledge retrieval request data includes at least the retrieval query text field, the target knowledge base type field, and the maximum retrieval quantity field. Taking the FPGA R&D scenario as an example, the target knowledge base type field includes at least one of the following: FPGA IP core library, design specification library, technical document library, and project case library.

[0059] Step S302: The middleware access proxy module reads the user identity token from the local token cache and checks whether the token is valid. When there is no user identity token in the local token cache or the token has expired, the middle platform access proxy module returns the prompt data "Not logged in or login has expired, please execute the login command first" to the function instance. The function instance displays the prompt data to the user and the process terminates. When the token is valid, the middleware access agent module continues to execute step S303.

[0060] Step S303: The middle platform access proxy module encapsulates the user identity token and knowledge retrieval requirement data into knowledge retrieval request data, and sends it to the API gateway layer of the middle platform management platform via HTTPS request.

[0061] Step S304: The API gateway layer extracts the user identity token field from the HTTPS request and sends the user identity token to the authentication middleware to perform token verification. The authentication middleware performs signature verification on the user's identity token to ensure that the token has not been tampered with; The authentication middleware checks the token's expiration timestamp to ensure the token has not expired. When the token is invalid or expired, the authentication middleware returns authentication failure response data to the client. After receiving the response, the client's middleware access proxy module clears the local token cache and returns the message "Login expired, please log in again" to the function instance, and the process terminates. When the token verification is successful, the authentication middleware parses the user identifier field, role identifier field, and permission list data from the token and injects the identity data into the request context.

[0062] Step S305: The authentication middleware passes the verified identity data to the authorization middleware. The authorization middleware extracts the user identity data, the target knowledge base type field (from the knowledge retrieval requirement data), and the retrieval operation type identifier from the request context, and performs the authorization verification operation. The permission middleware queries the user's retrieval permission policy data for the target knowledge base type based on the user role identifier field and permission list data. When a user's permission list does not contain retrieval permissions for the target knowledge base, the permission middleware returns insufficient permission response data to the client and writes the record of this unauthorized access operation (including user ID, target knowledge base, timestamp, and request source IP) to the security log audit module. The client displays the message "You do not have permission to access this knowledge base" to the user, and the process terminates. When the permission verification passes, the permission middleware forwards the knowledge retrieval request data to the knowledge base service layer.

[0063] Step S4: Knowledge base retrieval and result return. The specific steps are as follows: Step S401: The knowledge base service layer receives knowledge retrieval request data that has passed the permission verification, and extracts the target knowledge base type field and the retrieval query text field from the request data.

[0064] Step S402: The knowledge base service layer determines the scope of the sub-knowledge base to be searched based on the target knowledge base type field, performs the search operation on the search query text field, and obtains the final search result list.

[0065] Step S403: The knowledge base service layer encapsulates the final search result list into knowledge retrieval response data. This knowledge retrieval response data includes at least a list of search result entries (each entry includes a title field, a summary field, a content fragment field, a relevance score field, and a knowledge source identifier field) and a search time field.

[0066] Step S404: The knowledge base service layer returns the knowledge retrieval response data to the client's middleware access proxy module via the API gateway layer. At the same time, it writes the timestamp field, user identifier field, retrieval query text field (de-sensitized), target knowledge base type field, and number of retrieval results field of this knowledge retrieval operation to the security log audit module.

[0067] Step S405: The middle platform access proxy module receives the knowledge retrieval response data and returns the retrieval results to the function instance that initiated the request.

[0068] Step S406: The functional instance uses the received knowledge retrieval results as context reference data and continues to execute subsequent logical processing (such as filling IP core parameters into the scheme in the design auxiliary function and filling IP core instantiation template into the code in the coding auxiliary function), and continues to execute steps S205 and S206 to call external tools to complete subsequent operations when necessary.

[0069] Step S5: The middleware management platform is used for user management and RBAC permission configuration. The specific steps are as follows: Step S501: The administrator performs the user creation operation through the web interface of the middle platform management platform, and enters the user creation form data. The user creation form data includes at least the user account field, user name field, department field, role identifier field and initial password field.

[0070] Step S502: The user management module of the middle platform receives the user creation form data, performs a uniqueness check on the user account field, and returns a "Account already exists" prompt when the account already exists; when the account is unique, it performs a hash encryption operation on the password field, writes the user information into the user information database, and generates a user identifier field.

[0071] Step S503: The administrator configures knowledge base access permissions for specified users or roles through the permission configuration function of the Web interface. The knowledge base access permissions include at least a list of accessible knowledge base types (FPGA IP core library / design specification library / technical document library / project case library) and function type access permissions (design assistance / coding assistance / verification assistance / document generation).

[0072] Step S504: The user management module associates the configured permission data with the user role identifier and writes the permission data into the RBAC permission policy database.

[0073] Step S505: When a user subsequently logs in via the client (step S103), the user management module queries the permission data associated with the user from the RBAC permission policy database and encodes the permission list data into the payload of the user identity token. The knowledge retrieval request initiated by the client (step S304) uses this token to perform permission verification.

[0074] Step S6: The middle platform management platform is used for knowledge base management and knowledge accumulation. The specific steps are as follows: Step S601: Knowledge management personnel (or users with knowledge management permissions) perform the knowledge upload operation through the web interface of the middleware management platform, selecting the knowledge type, filling in the knowledge metadata, and uploading the knowledge content file. Taking the FPGA R&D scenario as an example, knowledge types include IP cores, design specifications, technical documents, and project cases. The knowledge metadata should at least include a title, category tags, applicable FPGA device types, and a keyword list.

[0075] Step S602: The knowledge base service layer of the middle platform management platform receives the uploaded knowledge data and performs structured processing operations on the knowledge content according to the knowledge type: When the knowledge type is IP core, the structured parameter fields of the IP core (interface protocol, clock frequency, resource consumption, compatible device list) are parsed, the structured parameters are written into the relational database, and the functional description text is vectorized and written into the vector database. When the knowledge type is a design specification or technical document, text extraction and segmentation operations are performed on the document content, the text paragraphs are vectorized and written into the vector database, and the full text content is written into the full text search engine. When the knowledge type is a project case, extract the project's design scheme summary, code snippets, and verification conclusions. Vectorize the summary and conclusions and write them into a vector database, and write the complete document into a full-text search engine.

[0076] Step S603: The knowledge base service layer creates vector indexes and full-text indexes for the newly added knowledge data, so that the newly added knowledge can be immediately retrieved by the client's search request.

[0077] Step S604: The knowledge base service layer records the knowledge entry operation log (operation time, operator, knowledge type, number of knowledge items), and writes the record to the security log audit module.

[0078] Step S7: The middle platform management system is used for operation auditing and log traceability. The specific steps are as follows: Step S701: The security log auditing module registers a global log interceptor at the API gateway layer to automatically collect structured log data for all requests passing through the API gateway (including client knowledge retrieval requests and web interface management operation requests). This log data includes at least the request timestamp field, operation user identifier field, request source type field (client / web), operation type field (knowledge retrieval / knowledge management / user management / permission configuration), target resource field, operation result status code field, and response duration field.

[0079] Step S702: The security log auditing module performs real-time abnormal behavior detection on the log data: When the frequency of knowledge retrieval requests initiated by the same user within a short period of time exceeds a preset threshold, "high-frequency retrieval" warning data is generated; When a user is detected to be making consecutive unauthorized access requests to the knowledge base (authorization verification fails), an "unauthorized access" warning is generated. When it is detected that a user is exporting knowledge data in batches outside of working hours, an "abnormal export" warning is generated. Abnormal alert data is sent to the administrator via web interface notification or email.

[0080] Step S703: The administrator enters query conditions (at least one of time range, user ID, operation type, and target resource) through the log audit interface of the middle platform management platform. The security log audit module retrieves matching structured log data from the log storage according to the query conditions and returns a list of query results.

[0081] Step S704: The log audit interface supports exporting query results as audit report files (PDF or CSV format) for use by external auditors or compliance reviewers.

[0082] Application scenarios: The dual-end separated collaborative system provided in this application is not only applicable to the above-mentioned FPGA R&D scenarios, but its dual-end separated architecture also has domain-independent versatility and can be extended to AI-assisted scenarios in the following technology R&D fields: Industrial embedded development scenario: The client automatically detects embedded development toolchains such as Keil, IAR, and ARM GCC. The middle platform manages knowledge assets such as embedded chip model parameter library, RTOS configuration specification library, peripheral driver code library, and historical project case library, assisting engineers in completing R&D tasks such as embedded code writing, peripheral configuration, and driver generation.

[0083] EDA / CAD toolchain integration scenario: The client automatically detects 3D design tools (SolidWorks, CATIA), CAE simulation tools (Ansys, Abaqus), etc., while the middle platform manages knowledge assets such as material parameter library, design specification library, and simulation case library in a unified manner, assisting engineers in completing R&D tasks such as parametric modeling, simulation analysis, and design optimization.

[0084] Automotive-grade chip and software R&D scenario: The client automatically detects the automotive electronics R&D toolchain, and the middle platform manages knowledge assets such as the AUTOSAR specification library, functional safety standard library (ISO 26262), and automotive-grade chip parameter library. When the client needs knowledge enhancement, it can obtain it after authentication and authorization by the middle platform, which meets the security and compliance requirements in confidential scenarios.

[0085] The above-mentioned extended application scenarios are all based on the core inventive concept of this application: deploying AI-assisted capabilities for local execution on the client side, centrally managing knowledge assets through a unified middleware management platform, and requiring the client to obtain knowledge enhancement only after identity verification and permission checks by the middleware platform; these can be achieved by configuring and adapting the toolchain type and knowledge asset type according to different fields, and all fall within the protection scope of this application.

[0086] Based on the same inventive concept, this application also provides a client-side collaboration method for a dual-end separated collaborative system, applied to the aforementioned dual-end separated collaborative system. For example... Figure 4 As shown, the client collaboration method includes: In response to the login command entered by the user, the login credentials are collected and sent to the middleware management platform; Specifically, the user enters a login command on the terminal, and the client interactively collects login credential data from the user. This login credential data includes at least a user account field and a user password field. The client's middleware access proxy module sends the login credential data to the middleware management platform's API gateway layer via an HTTPS request, where the middleware management platform performs authentication. The interactive input method for collecting login credentials avoids displaying passwords in plaintext or storing them on disk, ensuring the security of user credentials.

[0087] Receive the user identity token returned by the middle platform after successful authentication, and write the user identity token into the local token cache.

[0088] Specifically, the user management module of the middleware management platform performs identity authentication on login credentials. Upon successful authentication, a user identity token containing user permission data (using JWT as an example, but this application is not limited to this) is generated and returned to the client. The middleware access proxy module on the client receives the token and writes it to the local token cache. At the same time, it sets a local token expiration reminder time (earlier than the token's expiration timestamp). When the token is about to expire, a refresh operation is automatically triggered to ensure that subsequent knowledge retrieval requests always carry a valid token. If authentication fails, the client receives error response data returned by the middleware management platform (including incorrect account or password) and displays the corresponding error message to the user.

[0089] In response to a user's input function call command, the corresponding function instance is loaded, and the function instance is controlled to execute internal logic operations locally on the client.

[0090] Specifically, the user inputs a function call command (such as "zhiqing design "..." or "zhiqing code"). The client's function manager receives the function call request data input by the user. This function call request data includes at least a function type identifier field (at least one of design / code / verify / docgen) and a request parameter field. The function manager loads the corresponding function instance from a pre-built function registry based on the function type identifier field. This function registry pre-stores the type identifier, version number, entry function, and dependency configuration data for each function. The function instance executes internal logic operations locally on the client. These internal logic operations are operations that can be executed independently without the support of a central knowledge base, including but not limited to: multi-turn dialogue interaction with the user (collecting design requirement details), performing preliminary data processing based on local rules or a local lightweight model (text formatting, keyword extraction), calling the local LLM to execute basic code framework generation (when a local model is configured), and displaying and presenting the processing results to the user.

[0091] When the function instance needs to call an external tool during execution, the corresponding external tool is detected in the local operating system and the external tool is started as a child process.

[0092] Specifically, during the execution of internal logic operations, when a functional instance needs to call an external tool, it sends an external tool call request to the environment detection module. This request data includes at least one tool type identifier field (editor / simulator / synthesizer / project-manager) and a call parameter field. The environment detection module, based on the tool type identifier field, queries the local operating system's preset search paths (PATH environment variable, Windows registry, macOS Applications directory, etc.) for the corresponding executable program or application registration information. When the corresponding external tool is detected as installed, the environment detection module obtains the tool's executable file path or startup command, launches the external tool as a subprocess, and passes the functional instance's output data (such as code file path, test case file path, and solution document path) as parameters to the launched external tool. When the corresponding external tool is detected as not installed, the environment detection module returns a "No corresponding tool detected, please install manually" prompt to the functional instance. The functional instance displays this prompt to the user, the process continues, and the functional instance can still output results in text form in the terminal.

[0093] When the function instance requires knowledge support during execution, it reads the user identity token from the local token cache, encapsulates the user identity token and knowledge retrieval requirements into a knowledge retrieval request, and sends it to the middle platform management platform.

[0094] Specifically, when a functional instance requires knowledge support during internal logic operations, it sends a knowledge retrieval request to the middle platform access proxy module. This request must include at least the query text field, the target knowledge base type field, and the maximum number of retrievals field. The middle platform access proxy module reads the user's identity token from its local token cache and checks its validity. If no user identity token is found in the local cache or the token has expired, the middle platform access proxy module returns a "Not logged in or login expired, please execute the login command first" message to the functional instance. The functional instance displays this message to the user, and the process terminates. When the token is valid, the middle platform access proxy module encapsulates the user's identity token and the knowledge retrieval request into a knowledge retrieval request and sends it to the API gateway layer of the middle platform management platform via HTTPS.

[0095] The system receives the knowledge retrieval results returned by the middle platform management platform and returns the knowledge retrieval results to the functional instance so that the functional instance can continue to execute the internal logic operation.

[0096] Specifically, the client receives knowledge retrieval response data returned by the middleware management platform via the API gateway layer. This response data includes at least a list of retrieval result entries (each entry contains a title field, a summary field, a content fragment field, a relevance score field, and a knowledge source identifier field) and a retrieval time field. The client returns the retrieval results to the function instance that initiated the request. The function instance uses the received knowledge retrieval results as context reference data to continue executing subsequent logical processing (such as filling IP core parameters into the scheme in the design assistance function, and filling IP core instantiation templates into the code in the coding assistance function), and continues to call external tools to complete subsequent operations when necessary.

[0097] In the client-side collaboration method provided in this application, the client acts as the user's operating terminal, carrying out the local execution of various AI-assisted capabilities. It also automatically detects and invokes the local toolchain. When knowledge enhancement is required, it must undergo authentication and permission verification by the platform before access can be obtained, thus achieving localized deployment of AI-assisted capabilities and unified management of knowledge assets. Users complete the entire process—from requirement input, knowledge retrieval, code generation to tool invocation—within the terminal, eliminating the need for manual switching and data transfer between different tools, significantly improving development efficiency and user experience.

[0098] Based on the same inventive concept, this application also provides a collaborative method for a middleware management platform in a dual-end separated collaborative system, applied to the aforementioned dual-end separated collaborative system. For example... Figure 5 As shown, the collaboration methods of the middle platform management platform include: The system receives login credentials sent by the client, performs identity authentication on the login credentials, generates a user identity token containing user permission data after successful authentication, and returns the user identity token to the client.

[0099] Specifically, the API gateway layer of the middleware management platform receives login credentials sent by the client and forwards them to the user management module. The user management module extracts the user account and password fields from the login credentials, queries the corresponding user record data in the pre-configured user information database, and verifies the password hash value. If the user account field does not exist in the user information database, it returns an "Account Not Found" error response to the client and writes the login failure record to the security log audit module, terminating the process. If the user account exists but the password field does not match the password hash value stored in the database, it returns an "Incorrect Password" error response to the client and writes the login failure record to the security log audit module, terminating the process. When the user account exists and the password verification passes, the user management module obtains the user's role identifier field and permission list data, and generates a user identity token (using JWT as an example, but this application is not limited to this). This user identity token includes at least a user identifier field, a role identifier field, permission list data, a token validity period timestamp, and token signature data. The user management module returns the user identity token to the client via the API gateway layer.

[0100] The system receives a knowledge retrieval request sent by the client, the knowledge retrieval request including at least the user identity token, the retrieval query text field, and the target knowledge base type field.

[0101] Specifically, when a client-side function instance requires knowledge support during execution, the middleware access proxy module encapsulates the user's identity token and knowledge retrieval request into a knowledge retrieval request and sends it to the API gateway layer. The API gateway layer receives this knowledge retrieval request, extracts the user identity token field, the retrieval query text field, and the target knowledge base type field from the HTTPS request, and prepares to execute subsequent authentication and verification processes. The target knowledge base type field indicates the scope of the knowledge base the user intends to retrieve, including at least one of the following: IP core library, design specification library, technical document library, and project case library.

[0102] Perform a token verification operation on the user identity token to confirm its validity.

[0103] Specifically, the authentication middleware at the API gateway layer extracts the user identity token field from the HTTPS request and performs token verification. First, the middleware performs signature verification on the user identity token, using a pre-configured public key to verify the token's signature data, ensuring the token has not been tampered with. Second, the middleware checks the token's expiration timestamp to confirm its validity. When the token is invalid (signature verification failed) or has expired, the middleware returns an authentication failure response to the client. Upon receiving this response, the client's middleware access proxy module clears its local token cache and returns a "Login expired, please log in again" message to the functional instance, terminating the process. When token verification succeeds, the middleware parses the user identifier field, role identifier field, and permission list data from the token, injects the identity data into the request context, and passes it to the permission middleware.

[0104] Based on the user permission data in the user identity token, perform permission verification on the target knowledge base type field.

[0105] Specifically, the authentication middleware passes the verified identity data to the permission middleware. The permission middleware extracts the user's identity data (including role identifier field and permission list data), target knowledge base type field, and retrieval operation type identifier from the request context, and performs a permission verification operation. Based on the user's role identifier field and permission list data, the permission middleware queries the permission policy database for the user's retrieval permission policy data for the target knowledge base type. If the user's permission list data does not contain retrieval permissions for the target knowledge base type, the permission middleware returns insufficient permissions response data to the client and writes the record of this unauthorized access operation (including user identifier, target knowledge base, timestamp, and request source IP) to the security log audit module, triggering an unauthorized access warning. The client displays the message "You do not have permission to access this knowledge base" to the user, and the process terminates. When the permission verification passes, the permission middleware forwards the knowledge retrieval request data to the knowledge base service layer.

[0106] When the permission verification is successful, a retrieval operation is performed in the knowledge base corresponding to the target knowledge base type field, based on the retrieval query text field, to obtain the knowledge retrieval results.

[0107] Specifically, the knowledge base service layer receives knowledge retrieval request data that has passed permission verification, and extracts the target knowledge base type field and the retrieval query text field from the request data. First, the knowledge base service layer determines the scope of the sub-knowledge base to be retrieved based on the target knowledge base type field (e.g., if the user specifies a retrieval IP core, the retrieval will only be performed within that knowledge base). Second, it performs a retrieval operation on the retrieval query text field to obtain the final retrieval result list.

[0108] The knowledge retrieval results are returned to the client, and the log data of this knowledge retrieval operation is written to the security log audit module.

[0109] Specifically, the knowledge base service layer encapsulates the final search result list into knowledge retrieval response data. This response data includes at least a list of search result entries (each entry contains a title field, a summary field, a content fragment field, a relevance score field, and a knowledge source identifier field) and a search time field. The knowledge base service layer returns the knowledge retrieval response data to the client's middleware access proxy module via the API gateway layer. Simultaneously, the security log auditing module writes the log data of this knowledge retrieval operation to the security log storage. This log data includes at least a request timestamp field, an operation user identifier field, a request source type field (client), an operation type field (knowledge retrieval), a target resource field (target knowledge base type), a search query text field (anonymized), an operation result status code field, and a response duration field.

[0110] In the collaborative method of the middle platform management platform proposed in this application, the middle platform management platform acts as a centralized hub for knowledge assets and security control. It performs end-to-end identity authentication, permission verification, log recording (structured log collection), and anomaly detection (unauthorized access warning) for every knowledge retrieval request, ensuring the security and controllability of knowledge assets. This method overcomes the shortcomings of the existing technology's coarse-grained control approach of "all knowledge resources can be accessed once authentication is passed" by introducing independent user-level identity authentication, knowledge base type-level permission verification, and end-to-end log auditing. It achieves accurate identity recognition, fine-grained permission verification, and traceable auditing for every knowledge retrieval request.

[0111] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps: receiving a login credential sent by a client, performing identity authentication on the login credential, and generating a user identity token containing user permission data after successful authentication, and returning the user identity token to the client; receiving a knowledge retrieval request sent by the client, the knowledge retrieval request including at least a user identity token, a search query text field, and a target knowledge base type field; performing a token verification operation on the user identity token to confirm its validity; performing a permission verification operation on the target knowledge base type field based on the user permission data in the user identity token; when the permission verification is successful, performing a retrieval operation in the knowledge base corresponding to the target knowledge base type field based on the search query text field to obtain the knowledge retrieval result; returning the knowledge retrieval result to the client, and writing the log data of this knowledge retrieval operation to a security log audit module.

[0112] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0113] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0114] In summary, the core inventive concept of this application lies in breaking the traditional architectural inertia of "integrated binding of AI capabilities and knowledge assets" in AI-assisted R&D systems, and constructing a dual-end separated collaborative architecture where AI applications are executed independently on the client side, knowledge assets are centrally managed in a unified platform, and the two interact in a controlled manner through a secure channel of "token authentication + permission verification + full-link auditing". The essence of this architecture is to systematically separate the "AI-assisted execution surface" from the "knowledge asset management surface". The client side handles the interaction of AI applications and the orchestration of local tools, while the platform handles the unified storage, retrieval, and security management of knowledge assets. This allows knowledge assets to be reused by multiple clients as independently organized assets, and each knowledge access can be traced back to a specific user, specific knowledge base type, and specific operational behavior.

[0115] Compared with the prior art, this application has the following significant technical effects: Firstly, it achieves complete decoupling of AI applications and knowledge assets at the architectural level. In contrast, CN110659515B (An Open Integrated Circuit Collaborative Design Cloud Platform) forms a closed-loop cloud environment by integrating encrypted IP data with AI-assisted design service modules and EDA tools. The IP knowledge data is only available for internal use within the cloud platform and cannot be used as an independent knowledge asset by other AI-assisted tools outside the platform. CN122046365A (An R&D Toolchain Integration System and Its Integration R&D Method) embeds a compliance knowledge base as a built-in component of the security and compliance layer, binding knowledge to the system and preventing independent accumulation and cross-system reuse. This application, through a dual-end separation architecture, enables knowledge assets to be deployed and maintained independently and reused by multiple clients, effectively avoiding the problems of duplicate storage and inconsistency of knowledge.

[0116] It should be noted that the user information (including but not limited to user account information, user personal information, etc.) and data (including but not limited to knowledge base data, search record data, audit log data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0117] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0118] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0119] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0120] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A dual-end separated cooperative system, characterized in that, It adopts a dual-end separated architecture, which includes a client and a middleware management platform that communicates with the client: The client includes a function manager, which comprises multiple function instances, a middleware access proxy module, and an environment detection module. The function instances are used to execute internal logic operations of the AI ​​application layer locally on the client. These internal logic operations include at least one of multi-turn dialogue interaction, preliminary data processing based on local rules, and code framework generation based on a local model. The middleware access proxy module manages user identity tokens. When knowledge support is required during the execution of the internal logic operations by the function instances, in response to the knowledge retrieval request issued by the function instances, the module encapsulates the knowledge retrieval request and the locally cached user identity token into a knowledge retrieval request and sends it to the middleware management platform. The environment detection module is used to detect the external tool locally on the client and start the external tool as a subprocess when the external tool needs to be called during the execution of the function instance. The middleware management platform includes an API gateway layer, a knowledge base service layer, and a platform control service layer. The API gateway layer is used to receive the knowledge retrieval request and perform identity authentication and permission verification on the knowledge retrieval request; the knowledge base service layer is used to perform the retrieval operation after the permission verification is passed and return the retrieval result to the function instance. The platform management service layer is used to provide user management, access control, and security audit services; The platform management service layer includes a user management module, an RBAC permission control module, and a security log auditing module; the user management module is used to perform identity authentication on login credentials and generate a user identity token containing user permission data after successful authentication; The RBAC permission control module is used to configure the association between user roles and knowledge base access permissions; the security log auditing module is used to record the operation logs of knowledge retrieval requests initiated by the client. Each access to the knowledge base service layer by the functional instance is executed through the middle platform access proxy module and the API gateway layer; The environment detection module is used to automatically perform the following operations in response to an external tool call request issued by the functional instance during the execution of the internal logic operation: Based on the tool type identifier field in the external tool call request, the corresponding executable program or application registration information is queried in the local operating system's preset search path and environment variables; When the external tool is detected to be installed, obtain the executable file path or startup command of the external tool, start the external tool as a subprocess, and pass the output data of the function instance as a parameter to the started external tool; When it is detected that the external tool is not installed, a prompt data is returned to the function instance.

2. The dual-end separated cooperative system according to claim 1, characterized in that, The user identity token is a JWT token, and the payload of the JWT token stores at least a user identifier field, a role identifier field, permission list data, and a token validity period timestamp. When performing permission verification on the knowledge retrieval request, the API gateway layer directly extracts the permission list data from the payload of the JWT token, queries the current user's retrieval permissions for the target knowledge base type based on the permission list data, and blocks the knowledge retrieval request when the permission list data does not contain retrieval permissions for the target knowledge base type.

3. The dual-end separated cooperative system according to claim 1, characterized in that, The functional examples include at least one of design assistance functions, coding assistance functions, verification assistance functions, and document generation functions; the external tools include at least one of integrated design tools, code editors, and simulation tools.

4. The dual-end separated cooperative system according to claim 1, characterized in that, The API gateway layer includes an authentication middleware, an authorization middleware, a logging middleware, and a rate limiting middleware connected in sequence. The knowledge retrieval request is processed by the knowledge base service layer only after the authentication middleware performs JWT token verification, the permission middleware performs RBAC permission verification, the logging middleware performs structured log recording, and the rate limiting middleware performs request frequency control in the API gateway layer.

5. The dual-end separated cooperative system according to claim 1, characterized in that, The knowledge base of the knowledge base service layer includes at least one or more of the following: FPGA IP core library, design specification library, technical document library, and project case library.

6. A dual-end separated cooperative system according to claim 5, characterized in that, The knowledge base service layer resides in the middle platform management platform. The functional instance has no right to directly access the underlying search engine of the knowledge base service layer. Each search request of the functional instance is forwarded to the knowledge base service layer through the middle platform access proxy module and the API gateway layer, and then executed uniformly by the knowledge base service layer.

7. A client-side collaboration method for a dual-end separated collaborative system, employing a dual-end separated collaborative system as described in any one of claims 1 to 6, characterized in that, include: In response to the login command entered by the user, the login credentials are collected and sent to the middle platform management platform; Receive the user identity token returned by the middle platform after successful authentication, and write the user identity token into the local token cache; In response to a user's input function call command, load the corresponding function instance and control the function instance to execute internal logic operations locally on the client. When the functional instance needs knowledge support during the execution of the internal logic operation, it reads the user identity token from the local token cache, encapsulates the user identity token and the knowledge retrieval requirement into a knowledge retrieval request, and sends the knowledge retrieval request to the middle platform management platform. The system receives the knowledge retrieval results returned by the knowledge base service layer and returns the knowledge retrieval results to the functional instance so that the functional instance can continue to execute the internal logic operation.

8. A collaborative method for a middleware management platform in a dual-end separated collaborative system, employing a dual-end separated collaborative system as described in any one of claims 1 to 6, characterized in that... include: Receive login credentials sent by the client, perform identity authentication on the login credentials, generate a user identity token containing user permission data after successful authentication, and return the user identity token to the client; Receive a knowledge retrieval request sent by the client, wherein the knowledge retrieval request contains at least the user identity token; The system performs identity authentication and permission verification on the knowledge retrieval request, confirms the validity of the user identity token, and determines whether the current user has access to the requested knowledge base based on the user permission data in the user identity token. When the permission verification is successful, the knowledge base service layer of the middle platform management platform will uniformly perform the retrieval operation. The client does not have the right to directly access the underlying retrieval engine of the knowledge base service layer. The search results are returned to the client, and the log data of this knowledge retrieval operation is written to the security log audit module.

Images