A multi-workbench AI programming collaborative system and method based on browser plugins

Abstract

This invention discloses a multi-workbench AI programming collaboration system and method based on a browser plugin. The browser plugin, acting as a lightweight sidebar shell, loads a remote panel provided by the target workbench gateway. The control plane maintains the enterprise workbench directory and session keys. The user's browser directly accesses each target workbench gateway to obtain a project list, which is then filtered based on the user's code repository permissions. The target workbench gateway uses short-lived encrypted session cookies for unified authentication of the remote panel, project list, project opening, and AI execution entry point. The remote panel invokes the AI ​​code executor through the target workbench gateway, executes code tasks in the project directory, and returns output, differences, status, and token usage. This invention is applicable to enterprise multi-workbench remote development and AI programming collaboration scenarios.

Description

Technical Field

[0001] This invention relates to the fields of browser plugins, remote development environments, identity authentication, distributed workbench management, and AI code execution, and particularly to a system and method for loading a remote panel via a browser sidebar plugin and performing project selection, session authorization, and AI programming task execution among multiple workbench gateways. Background Technology

[0002] Existing browser plugins typically implement the main business interface and logic locally, making plugin version updates, enterprise-specific configurations, access control, and remote development environment integration difficult. In scenarios with multiple development workstations within an enterprise, while user browsers can access each workstation, inter-workstation access is usually not guaranteed, and the control plane should not actively probe remote workstation gateways. Furthermore, traditional remote development entry points are prone to issues such as session information leakage via URLs or custom headers, the main workstation forwarding requests on behalf of the target workstation, inaccurate display of remote project permissions, and difficulty in auditing AI execution status and token usage. Therefore, a browser plugin collaboration solution is needed for multi-workstation network topologies. This solution should keep plugins lightweight, provide remote dashboards from the target workstation, verify sessions locally on the target workstation, allow user browsers to directly access the target workstation, and provide verifiable and auditable management of the AI ​​programming execution process. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a multi-workbench AI programming collaboration system and method based on browser plugins, so as to solve the problems of difficult plugin updates, unclear cross-workbench access paths, insufficient session security, inaccurate display of project permissions, and lack of auditing of the AI ​​execution process in a multi-workbench environment.

[0004] To solve the above technical problems, the present invention adopts the following technical solution: A multi-workbench AI programming collaboration method based on a browser plugin, comprising: the browser plugin loading a remote panel provided by the target workbench gateway in the sidebar; the plugin obtaining user authentication information; obtaining a set of available workbench for the enterprise from the control plane or equivalent authority directory based on the authentication result; the browser directly requesting the project list of each target workbench gateway according to the workbench set; filtering the project list of each workbench according to the user's code repository permissions; in response to the user selecting a project, the browser directly entering the remote panel of the target workbench gateway to which the project belongs; the target workbench gateway authenticating the remote panel, project list, project opening, and AI execution entry point based on a short-term encrypted session cookie; the remote panel calling the AI ​​code executor through the execution entry point of the target workbench gateway to execute tasks in the target project directory and returning execution output, difference results, status information, and token usage information.

[0005] The system comprises a browser plugin, a control plane, multiple workbench gateways, and multiple workbench proxies. The browser plugin, acting as a lightweight shell, is responsible for the sidebar, browser API bridging, identity and status maintenance, and remote panel loading. The control plane maintains enterprise information, plugin bindings, the workbench directory, user authorization summaries, and session key rings. Each workbench gateway provides a remote panel, project list, project opening, WebSocket execution entry point, and session verification. Each workbench proxy is responsible for outbound connections to the control plane, reporting status, and synchronizing session keys, runtime versions, and update packages.

[0006] The beneficial effects of this invention include: 1. The plugin remains lightweight, with the main interface provided by the target workbench gateway, reducing the cost of frequent plugin releases.

[0007] 2. Users' browsers directly access the target workbench, avoiding network dependencies and permission confusion caused by forwarding between workbenches.

[0008] 3. The target workbench uses the local gateway to verify short-term encrypted cookies, eliminating the need for backend session storage and reducing the risk of session leakage and state drift.

[0009] 4. The project list and user code repository permissions are intersected and displayed to improve the accuracy of multi-workbench project access control.

[0010] 5. AI execution is completed through a unified entry point on the target workbench gateway, which facilitates the collection of output, differences, status, and token usage, thus meeting audit requirements.

[0011] 6. The control plane obtains remote status and distributes keys / versions through the workbench agent, without relying on the control plane to actively access the remote workbench gateway, thus adapting to the enterprise intranet topology. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the system architecture of the present invention, including a browser plugin, a control plane, a workbench gateway, a workbench agent, and an AI code executor.

[0013] Figure 2 Flowchart for user authentication and short-lived session cookie issuance.

[0014] Figure 3 Flowchart for retrieving project lists from multiple workbench platforms, filtering permissions, and opening projects.

[0015] Figure 4 This is a flowchart illustrating how a remote panel calls the AI ​​executor via WebSocket and returns the execution result.

[0016] Figure 5 A flowchart illustrating the reporting process of token usage from the workbench gateway, local queue, workbench proxy to the control plane.

[0017] Detailed Implementation: In one embodiment, the user installs an enterprise-specific browser plugin. This plugin opens a local shell page in the browser sidebar. The shell page reads the plugin version, enterprise binding information, and current gateway configuration, and displays a login entry. The user completes authentication using their code hosting platform account, OAuth, or access token. After obtaining the user's authentication digest, the plugin requests the control plane or a directory interface authorized by the control plane to retrieve the set of currently available workbenches for the enterprise.

[0018] Each workbench in the workbench set includes a workbench identifier, workbench name, gateway access address, availability status, and binding information. Plugins do not request one workbench gateway from another; instead, the user's browser initiates separate project list requests to each workbench gateway. If one workbench is unavailable, only that workbench group is marked as failed, and the other workbench groups continue to be displayed.

[0019] During the project demonstration, the plugin uses the currently logged-in user's code hosting platform credentials to obtain the set of projects the user can access. This set is then matched against the local project sets returned by each workbench gateway, displaying only the projects the user has permission to access. Matching fields can include repository paths, project namespaces, remote repository addresses, or normalized project identifiers.

[0020] When a user clicks on an item, the plugin generates a remote panel address pointing to the target workbench gateway of that item, carrying the intention to open the item. The target workbench gateway reads this opening intention during the remote panel startup phase and directly enters the corresponding item's workspace, instead of returning to the main workbench or relying on other workbench intermediaries.

[0021] Regarding session security, the target workbench gateway uses a key ring synchronized by the workbench agent via the control plane to generate or decrypt short-lived encrypted session cookies. These cookies include at least the necessary fields: enterprise identifier, plugin binding identifier, user authentication digest, target workbench identifier, authorized scope, and expiration time. The remote panel, project list, project opening, runner HTTP interface, and WebSocket handshake all reuse the same session verification entry point. Regular business requests do not transmit the panel session identifier via URL query parameters or custom headers, thereby reducing the risk of session leakage.

[0022] In terms of AI programming execution, the remote panel submits tasks through the execution entry point of the target workbench gateway. The task content can include natural language instructions, target project, working directory, context file, execution mode, and client request identifier. The target workbench gateway calls the AI ​​code executor in the corresponding project directory and returns the execution start, execution progress, output fragments, errors, completion status, and code differences to the remote panel via WebSocket.

[0023] In terms of execution process management, the workbench gateway determines whether the AI ​​executor is stuck based on output activity: as long as the execution process continues to generate standard output, standard error, or progress events, the task is considered to still be executing; the task is only terminated and an idle timeout error is returned when there is absolutely no output within the configured idle window. This can prevent tasks that have been running for a long time but are still making progress from being mistakenly killed due to a fixed total duration.

[0024] For usage auditing, the workbench gateway extracts token usage from the structured output of the AI ​​code executor, including at least input tokens, cached input tokens, output tokens, and inference output tokens. The gateway first writes the usage event to a local queue to be reported, and then the workbench agent reports it to the control plane through the established outbound channel. After the control plane confirms the write, the corresponding event is deleted from the workbench's local queue. This process makes AI execution usage traceable, retryable, and auditable.

[0025] Regarding versioning and distribution, enterprise plugin packages can be instantly packaged and signed by the gateway based on the enterprise plugin's identity. Different enterprise bindings correspond to different plugin identities, ensuring the stability of plugin IDs, OAuth callback URLs, and enterprise binding relationships. Plugins can also obtain the latest version, update notes, and download address through a version check interface, and prompt users to update when version inconsistencies are detected.

Claims

1. A multi-workbench AI programming collaboration method based on browser plugins, characterized in that, include: The browser plugin loads a remote panel provided by the target workbench gateway in the sidebar; the browser plugin obtains user authentication information and authenticates with the control plane or gateway; The system retrieves the directory of available workbenches for the enterprise based on the authentication results; users' browsers then directly access the gateways of each target workbench to obtain the corresponding project lists. The project list is filtered according to the user's code repository permissions; in response to the user selecting a project, a remote panel address pointing to the target workbench gateway of the project is generated and the project is opened; The AI ​​code executor is invoked through the execution entry point of the target workbench gateway to perform code generation, modification, or review tasks in the corresponding project directory, and the execution output, difference results, and status information are returned to the remote panel.

2. The method according to claim 1, characterized in that, The browser plugin is a lightweight plugin shell, mainly used to carry the sidebar, bridge browser extension APIs, maintain identity status and load remote panels, while project management, task execution and the main interface are completed by the remote panel provided by the target workbench gateway.

3. The method according to claim 1, characterized in that, The enterprise available workbench directory is maintained by the control plane as the authoritative data source, and the workbench directory includes at least one of the following: workbench identifier, gateway access address, workbench status, enterprise binding relationship, and plugin binding relationship.

4. The method according to claim 1, characterized in that, When the browser plugin retrieves the project list, it does not forward access to one workbench gateway through another; instead, the user's browser concurrently and directly requests each target workbench gateway.

5. The method according to claim 1, characterized in that, When a request from one of multiple workbenches fails, only the project group corresponding to that workbench is marked as failed, without blocking the display of project groups from other workbenches.

6. The method according to claim 1, characterized in that, The filtering of the project list based on user code repository permissions includes: the browser plugin uses the code hosting platform credentials of the currently logged-in user to obtain the set of projects that the user can access, and calculates the intersection of this set with the local project set returned by the target workbench, and only displays the projects in the intersection.

7. The method according to claim 1, characterized in that, Before providing remote panels, project lists, project opening and execution entry points, the target workbench gateway verifies the short-term encrypted session cookie issued or renewed by the target workbench gateway.

8. The method according to claim 7, characterized in that, The short-term encrypted session cookie is generated and decrypted by the target workbench gateway based on the key ring synchronized with the control plane, and the target workbench gateway does not establish backend session storage for this session.

9. The method according to claim 7, characterized in that, The short-term encrypted session cookie contains only the minimum fields required for authentication and authorization, including at least one of the following: enterprise identifier, plugin binding identifier, user authentication digest, target workbench identifier, authorization scope, and expiration time.

10. The method according to claim 7, characterized in that, Regular remote panel API requests only transmit session context via same-origin encrypted cookies, and do not transmit panel session identifiers via URL query parameters or custom request headers.

11. The method according to claim 1, characterized in that, When a project is opened, the browser plugin generates a direct address to the remote panel of the target workbench gateway to which the project belongs, and carries the intention to open the project in the address, so that the target remote panel can directly enter the corresponding project workspace during the startup phase.

12. The method according to claim 1, characterized in that, The AI ​​code executor communicates with the remote panel through the WebSocket execution entry point of the target workbench gateway. The WebSocket handshake reuses the same short-term encrypted session verification mechanism as the remote panel's HTTPAPI.

13. The method according to claim 12, characterized in that, When a WebSocket session needs to be renewed, the target workbench gateway returns a session cookie renewal instruction via a WebSocket protocol message, and the browser plugin or remote panel writes the cookie back.

14. The method according to claim 1, characterized in that, The browser plugin maintains a shared WebSocket connection and matches multiple execution requests with their corresponding responses based on request identifiers. Once the execution request is completed and the connection is idle, the shared WebSocket connection is closed.

15. The method according to claim 1, characterized in that, The execution timeout judgment of the AI ​​code executor is based on output activity. When the execution process continuously generates standard output, standard error or progress messages, it is not truncated according to the fixed total time. It is judged as stuck only when there is no output within the preset idle window.

16. The method according to claim 1, characterized in that, The target workbench gateway collects token usage from the structured output of the AI ​​code executor and writes the token usage into a local reporting queue, which is then reported to the control plane by the workbench agent.

17. The method according to claim 16, characterized in that, The token usage includes at least one of the following: input token, cached input token, output token, and inference output token.

18. The method according to claim 1, characterized in that, Each workbench deploys a local agent, which is used to report workbench status to the control plane, synchronize session key rings, synchronize runtime versions, pull update packages, and perform workbench local checks.

19. The method according to claim 18, characterized in that, The control plane does not actively access the remote workbench gateway via HTTP. Instead, it obtains the status of the remote workbench through the workbench proxy's heartbeat, remote procedure calls, or the actual request results from the user's browser.

20. The method according to claim 1, characterized in that, Browser plugins periodically or on demand request a version check interface to obtain the latest version of the plugin, update notes, and download address, and prompt users to update when a version mismatch is detected.

21. The method according to claim 1, characterized in that, Enterprise plugin packages are packaged and signed by the gateway in real time according to the enterprise plugin identity. Different enterprises use different plugin identities or private keys to bind, thereby keeping the relationship between plugin identifier and enterprise binding stable.

22. A multi-workbench AI programming collaborative system based on a browser plugin, characterized in that, include: The system comprises a browser plugin, a control plane, multiple workbench gateways, and multiple workbench proxies. The browser plugin loads remote panels, maintains user identities, retrieves workbench directories, and directly accesses each target workbench gateway. The control plane maintains enterprise information, plugin bindings, workbench directories, and session key rings. The workbench gateways provide remote panels, project lists, project opening entry points, WebSocket execution entry points, and short-term encrypted session verification. The workbench proxies report status to the control plane and synchronize keys, versions, and runtime configurations.

23. The system according to claim 22, characterized in that, The workbench gateway is configured to provide remote dashboards, project lists, and execution entry points only to requests carrying valid short-lived encrypted session cookies.

24. The system according to claim 22, characterized in that, The browser plugin is configured to perform intersection processing on the set of user-accessible projects returned by the code hosting platform and the set of local projects returned by each workbench gateway, and then display the filtered projects by workbench group.

25. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 21.

Images