Remote session orchestration and streaming observable execution methods and systems for Agent CLI

Abstract

This invention provides a method and system for remote session orchestration and streaming observable execution for Agent CLIs. The caller does not directly adapt to a specific Agent CLI; instead, it sends a unified startup request to the Agent Runner. The Agent Runner creates a remote execution session based on the Agent type, task content, target resource identifier, and business serial number in the request, and selects the corresponding CLI adapter to launch Codex, Claude Code, or other Agent CLIs. During execution, the Agent Runner reads output streams from different sources in real time, including standard output, standard error, Runner internal events, and tool call results, and converts them into a unified log structure. Each log record includes a session identifier, business serial number, log sequence number, time, output source, and content. The Runner can asynchronously report logs to the backend platform, enabling the frontend dashboard to view the Agent execution process in real time; reducing the cost of multi-Agent CLI integration and improving the observability of the remote execution process.

Description

Technical Field

[0001] This invention relates to the field of AI agent technology, and in particular to a remote session orchestration and streaming observable execution method and system for Agent CLI. Background Technology

[0002] With the development of AI agent command-line tools, more and more business systems hope to use Agent CLIs (command-line tools designed specifically for AI agents), such as Codex (AI code generation training model) and Claude Code (AI programming assistant), to complete tasks such as automated analysis, code processing, remote tool invocation, desktop operation, test execution, and operation and maintenance. The caller can be a background service, desktop application, automation script, test platform, or other business system.

[0003] The current approach typically involves directly concatenating Agent CLI commands into specific business scripts or services and then reading the output after the CLI execution is complete. This method works in simple scenarios, but it has significant drawbacks in scenarios requiring remote triggering, long-running execution, and observable processes.

[0004] First, different Agent CLIs have different startup parameters, environment variables, access control methods, output formats, and result formats. For example, some CLIs output plain text, some output streaming JSON, some output token usage to the standard error stream, and some place the final result in a specific event. If callers need to adapt to each one, it will lead to redundant development and make it difficult to reuse between different business systems.

[0005] Second, the Agent CLI execution process can take a considerable amount of time, during which it generates various outputs such as inference text, tool invocation commands, tool return results, and error logs. Traditional invocation methods often only obtain the final output after the process ends, making it impossible to display the execution process in real time and difficult to detect problems such as freezing, exceptions, permission failures, or target tool invocation failures in a timely manner.

[0006] Third, the existing approach lacks unified management of remote execution session state. Callers find it difficult to accurately maintain whether a task is pending execution, in progress, successful, failed, timed out, or stopped, and it is also difficult to share state, logs, and final results among multiple callers.

[0007] Fourth, when multiple agent tasks operate on the same remote target resource simultaneously, such as the same test machine, the same desktop session, the same browser control service, or the same remote tool service, concurrency control conflicts may occur, leading to mutual interference in operations, unreproducible results, or abnormal status of the target resource.

[0008] Fifth, different Agent CLIs have different final output formats, making it difficult for business platforms to uniformly save execution results, summaries, failure reasons, S records, token usage and cost information, and also difficult to uniformly display and track them in a visualization panel.

[0009] Therefore, a remote session orchestration and streaming observable execution method for multi-type Agent CLIs is needed, enabling different business systems to trigger different Agent CLIs through a unified interface and to uniformly manage the execution process, logs, status, results, and target resource conflicts. Summary of the Invention

[0010] To overcome the above problems, the purpose of this invention is to provide a remote session orchestration and streaming observable execution method for Agent CLI, which reduces the cost of multi-Agent CLI access, improves the observability of the remote execution process, and reduces remote resource concurrency control conflicts.

[0011] This invention is implemented using the following scheme: a remote session orchestration and streaming observable execution method for Agent CLI, comprising the following steps: S1. Receive the remote agent execution request submitted by the caller; S2. Create a Runner session according to the request, generate or register a Runner session identifier, and record the Agent type, business serial number, target resource identifier, working directory, initial status, and creation time; the Runner session status can be set to pending after creation. S3. Query whether there is an active session in the pending or running state based on the target resource identifier. If the same target resource has been occupied by other Agent sessions, perform session conflict handling. S4. Select the corresponding CLI adapter based on the Agent type. Different adapters are responsible for handling their respective startup parameters, permission parameters, environment variables, and output format differences; and generate CLI startup commands and runtime environment; Runner can create an independent working directory for this session and set environment information such as PATH, temporary directory, timeout, and target tool address; S5. Start the Agent CLI process in the independent working directory, update the session status from pending to running, and record the process ID, start time, and summary of running parameters. S6. During the execution of Agent CLI, continuously read standard output, errors, and internal events of Runner, and convert them into unified log records according to session identifier, business serial number, log sequence number, log time, log source, and content; S7. Unified log records are written to an asynchronous reporting queue and sent to the backend platform or visualization panel by an independent reporting thread; if a reporting failure occurs, it can be retried according to a preset number of times and intervals to avoid network anomalies blocking the execution of the Agent CLI; S8. During execution or after the process ends, parse the final output, structured JSON, failure reason, execution time, token usage, and cost information according to the Agent type, and write the parsing results to a unified result object; update the session state according to the return code, final result, and timeout status. S9. Provide the caller or business platform with access to the session list, status query, log query, final result query, visualization page, and session termination interface, enabling the caller to continuously observe the remote agent's execution process and terminate the specified session when necessary.

[0012] Furthermore, the request includes Agent type, task content or prompt words, business serial number, target resource identifier, target tool address, and caller session identifier information.

[0013] Furthermore, the session conflict handling in S3 specifically involves: executing a conflict handling strategy, which includes: stopping the old session, rejecting the new session, and queuing the new session. The stopping of the old session involves recording that the old session was stopped because the new session occupied the same target resource; the rejection of the new session involves returning a message that the target resource is occupied; and the queuing of the new session involves waiting for the old session to end before executing the new session.

[0014] Furthermore, in S8, the session state is updated. The session state includes pending, running, success, failed, timeout, and stopped states. The pending state means that the session has been created but has not yet been actually started; the running state means that the Agent CLI has been started and is executing. Success status: The Agent CLI terminates normally, and a valid completed action and structured result are detected; Failed status: The Agent CLI exits abnormally, lacks a final result, or fails to complete as agreed; Timeout status: Execution exceeds the preset timeout period; Stopped status: The callee or conflict control strategy actively stops; Runner also records creation time, start time, end time, process ID, return code, error reason, execution time, final output, and final result; The caller can query the session progress in real time through the status interface, and can also terminate a specified session through the stop interface.

[0015] Furthermore, in S8, the parsing results are written to a unified result object. Specifically, the final results of different Agent CLIs can be located in different positions; the Runner can use different parsing methods according to the Agent type; for ordinary output CLIs, the Runner can summarize the standard output and parse the final JSON; for streaming event CLIs, the Runner can extract the final text, execution time, interaction rounds, token usage, and cost information from the result event; after parsing, the Runner generates a unified result object for the business platform to save; the unified result object may include: final_output: the Agent's final text output; final_result: the structured JSON result; token_usage: input token, output token, cached token, total token, and cost; error: the reason for failure; return_code: the process return code; and duration_ms: the execution time.

[0016] Furthermore, the Runner in S9 can provide the following query interfaces: sessions, status, logs, view, and stop. The sessions interface queries the session list; the status interface queries the status of a specified session; the logs interface queries the logs and results of a specified session; the view interface views the session log page; and the stop interface stops a specified session. Through these interfaces, the backend system, test platform, desktop application, or operation and maintenance platform can uniformly view the Agent execution status without directly reading remote processes or local log files.

[0017] This invention provides a remote session orchestration and streaming observable execution system for Agent CLI. The system includes a unified task access module, a session state management module, a target resource conflict control module, an Agent CLI adaptation module, a process execution and isolation module, a streaming log collection module, an asynchronous log reporting module, a result parsing module, and a visualization query module. The unified task access module receives remote agent execution requests submitted by the caller; The session state management module creates a Runner session based on the request, generates or registers a Runner session identifier, and records the Agent type, business serial number, target resource identifier, working directory, initial state, and creation time; after the Runner session is created, its state can be initially set to pending. The target resource conflict control module queries whether there are currently active sessions in a pending or running state based on the target resource identifier. If the same target resource has been occupied by other Agent sessions, session conflict handling is performed. The Agent CLI adaptation module selects the corresponding CLI adapter based on the Agent type. Different adapters are responsible for handling their respective startup parameters, permission parameters, environment variables, and output format differences; and generate CLI startup commands and runtime environment; Runner can create an independent working directory for this session and set environment information such as PATH, temporary directory, timeout, and target tool address; The process execution and isolation module starts the Agent CLI process in an independent working directory, updates the session status from pending to running, and records the process ID, start time, and summary of running parameters. The streaming log collection module continuously reads standard output, errors, and internal events of the Runner during the execution of the Agent CLI, and converts them into unified log records according to session identifier, business serial number, log sequence number, log time, log source, and content. The asynchronous log reporting module writes unified log records into an asynchronous reporting queue and sends them to the backend platform or visualization panel by an independent reporting thread. If reporting fails, it can retry according to a preset number of times and intervals to avoid network anomalies blocking the execution of the Agent CLI. The result parsing module, during execution or after process termination, parses the final output, structured JSON, failure reason, execution time, token usage, and cost information according to the Agent type, and writes the parsing results into a unified result object; it also updates the session state based on the return code, final result, and timeout status. The visualization query module provides callers or business platforms with access to session lists, status queries, log queries, final result queries, visualization pages, and a session termination interface, enabling callers to continuously observe the execution process of the remote agent and terminate a specified session when necessary.

[0018] Furthermore, the request includes Agent type, task content or prompt words, business serial number, target resource identifier, target tool address, and caller session identifier information.

[0019] Furthermore, the session conflict handling in the target resource conflict control module specifically involves: executing a conflict handling strategy, which includes: stopping old sessions, rejecting new sessions, and queuing new sessions. Stopping old sessions involves recording that an old session was stopped because a new session occupied the same target resource; rejecting new sessions involves returning a message indicating that the target resource is occupied; and queuing new sessions involves waiting for the old session to end before executing the new session.

[0020] Furthermore, the result parsing module updates the session status, which includes pending, running, success, failed, timeout, and stopped states. The pending state means that the session has been created but has not yet been actually started; the running state means that the Agent CLI has been started and is executing. Success status: The Agent CLI terminates normally, and a valid completed action and structured result are detected; Failed status: The Agent CLI exits abnormally, lacks a final result, or fails to complete as agreed; Timeout status: Execution exceeds the preset timeout period; Stopped status: The callee or conflict control strategy actively stops; Runner also records creation time, start time, end time, process ID, return code, error reason, execution time, final output, and final result; The caller can query the session progress in real time through the status interface, and can also terminate a specified session through the stop interface.

[0021] Furthermore, the result parsing module writes the parsing results into a unified result object. Specifically, the final results of different Agent CLIs can be located in different positions; the Runner can use different parsing methods according to the Agent type; for ordinary output CLIs, the Runner can summarize the standard output and parse the final JSON; for streaming event CLIs, the Runner can extract the final text, execution time, interaction rounds, token usage, and cost information from the result event; after parsing, the Runner generates a unified result object for the business platform to save; the unified result object may include: final_output: the Agent's final text output; final_result: the structured JSON result; token_usage: input token, output token, cached token, total token, and cost; error: the reason for failure; return_code: the process return code; and duration_ms: the execution time.

[0022] Furthermore, the Runner in the visualization query module can provide the following query interfaces: sessions, status, logs, view, and stop. The sessions interface queries the session list; the status interface queries the status of a specified session; the logs interface queries the logs and results of a specified session; the view interface displays the session log page; and the stop interface stops a specified session. Through these interfaces, the backend system, test platform, desktop application, or operation and maintenance platform can uniformly view the Agent execution status without directly reading remote processes or local log files.

[0023] The beneficial effects of this invention are: 1. Reducing the cost of multi-Agent CLI access; The caller only needs to access the Runner's unified interface and does not need to adapt to the startup parameters, output formats, and result parsing rules of different CLIs such as Codex and Claude Code.

[0024] 2. Improve the observability of remote execution processes; Runner collects and normalizes stdout, stderr, tool call results, and internal events during Agent execution in real time, enabling the backend and dashboard to view the execution process in real time.

[0025] 3. Improve the accuracy of task status management; By maintaining the task lifecycle through a unified session state machine, the caller can accurately determine whether a task is pending execution, in execution, successful, failed, timed out, or stopped.

[0026] 4. Improve the consistency of result storage and display; By using a unified result parsing mechanism, the final output, structured JSON, token usage, and cost information of different Agent CLIs are converted into a consistent data structure, which facilitates backend storage and frontend display.

[0027] 5. Reduce conflicts in remote resource concurrency control; By employing target resource identification detection and conflict resolution mechanisms, we prevent multiple agents from simultaneously operating the same remote tool, device, desktop, or service, thereby improving the stability and reproducibility of execution results.

[0028] 6. Enhance system scalability; When adding other Agent CLIs, you only need to add the corresponding adapter to reuse the existing session management, log reporting, status query, result parsing and visualization capabilities. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the method flow of the present invention.

[0030] Figure 2 This is a schematic diagram of the system of the present invention. Detailed Implementation

[0031] The invention will now be further described with reference to the accompanying drawings.

[0032] This solution provides a remote session orchestration and streaming observable execution method for Agent CLI. The caller does not directly adapt to a specific Agent CLI, but instead sends a unified start request to the Agent Runner. The Agent Runner creates a remote execution session based on the Agent type, task content, target resource identifier, and business serial number in the request, and selects the corresponding CLI adapter to start Codex, Claude Code, or other Agent CLIs.

[0033] During execution, the Agent Runner reads output streams from various sources in real time, including standard output, standard error, internal Runner events, and tool call results, and converts them into a unified log structure. Each log entry includes a session identifier, business transaction number, log sequence number, time, output source, and content. The Runner can asynchronously report logs to the backend platform, enabling the frontend dashboard to view the Agent execution process in real time.

[0034] Meanwhile, Agent Runner maintains a unified session state machine, maintaining states such as pending, running, success, failed, timeout, and stopped for each task, and provides interfaces for starting, stopping, querying status, querying logs, querying session lists, and viewing visualization pages.

[0035] At the end of execution, Agent Runner extracts the final result based on the output format of different Agent CLIs. For example, for plain text output, it can parse the final JSON from the standard output; for streaming JSON output, it can extract the final result, execution time, rounds, token usage, and cost information from the result event. After parsing, a unified result object is formed for the backend system to save and display.

[0036] In addition, Agent Runner performs conflict control based on the target resource identifier. If a session already exists that is pending or in progress for the same target resource, it can stop the old session, reject the new session, or queue it according to a policy to prevent multiple agents from controlling the same remote resource simultaneously.

[0037] This solution is not limited to specific business scenarios. The remote target resource can be the Airtest tool service, desktop automation service, browser control service, backend script service, CI execution service, operation and maintenance tool service, or other remote tools that can be invoked by the Agent. Airtest is only one optional implementation.

[0038] See Figure 1 As shown, a remote session orchestration and streaming observable execution method for Agent CLI includes the following steps: S1. Receive the remote agent execution request submitted by the caller; the request includes information such as agent type, task content or prompt words, business serial number, target resource identifier, target tool address and caller session identifier.

[0039] The caller can submit tasks to the Runner through a unified interface. Request fields may include: runner_session_id: Runner session identifier, which can be passed in by the caller or automatically generated by the Runner; agent_provider: Agent type, such as codex, claude; task or prompt: The task content that the Agent needs to execute; target_resource_id or target_tool_url: Target resource identifier or remote tool address; flow_id, task_id, session_id: Business flow number or task identifier in the business system.

[0040] When the caller only passes in the task without the complete prompt, the Runner can generate a default prompt template based on the target tool type; when the caller passes in the complete prompt, the Runner can directly use the prompt provided by the caller.

[0041] S2. Create a Runner session according to the request, generate or register a Runner session identifier, and record the Agent type, business serial number, target resource identifier, working directory, initial status, and creation time; the Runner session status can be set to pending after creation. S3. Query whether there is an active session in the pending or running state based on the target resource identifier. If the same target resource has been occupied by other Agent sessions, perform session conflict handling. When multiple agent sessions operate on the same target resource simultaneously, it may lead to mutual state contamination. For example, two agents may simultaneously control the same test machine, the same desktop, the same browser instance, or the same remote tool service.

[0042] To address this issue, when creating a new session, the Runner queries the currently active sessions based on the target resource identifier. If a session with a pending or running status is found for the same target resource, a conflict resolution strategy is executed. Specifically, session conflict resolution in S3 involves executing a conflict resolution strategy, which includes: stopping the old session, rejecting the new session, and queuing the new session. Stopping the old session involves recording that the old session was stopped because a new session occupied the same target resource; rejecting the new session involves returning a message indicating that the target resource is occupied; and queuing the new session involves waiting for the old session to finish before executing the new session.

[0043] S4. Select the corresponding CLI adapter based on the Agent type. Different adapters are responsible for handling their respective startup parameters, permission parameters, environment variables, and output format differences; and generate CLI startup commands and runtime environment; Runner can create an independent working directory for this session and set environment information such as PATH, temporary directory, timeout, and target tool address; in order to avoid mutual interference between files, logs, or contexts of different tasks.

[0044] The Runner selects the corresponding adapter based on the agent_provider field.

[0045] Taking Codex CLI as an example, Runner can load a specified environment file, set the PATH, and generate Codex execution commands, while disabling color output to make the output more suitable for log collection and parsing.

[0046] Taking Claude Code CLI as an example, the Runner can generate execution commands that include permission skip parameters, session-free persistence parameters, and streaming JSON output parameters, and perform event-level parsing on its stream-json output.

[0047] Command construction and output parsing for different CLIs are handled by their respective adapters, but a unified session, unified log, and unified results are exposed to the caller.

[0048] S5. Start the Agent CLI process in a separate working directory and update the session status from pending to running, while recording the process ID, start time, and summary of running parameters.

[0049] S6. During the execution of Agent CLI, continuously read standard output, errors, and internal events of Runner, and convert them into unified log records according to session identifier, business serial number, log sequence number, log time, log source, and content; After the CLI process starts, the Runner reads the standard output and standard error streams. Each line or streaming event read is converted into a unified log entry. Log entries may include: session_id: Runner session identifier; flow_id: Business transaction number; seq: Incrementing sequence number within the session; agent_time: Log time; stream: Log source, such as stdout, stderr, runner; content: Log content.

[0050] For plain text output, Runner can log stdout line by line. For Claude Code's stream-json output, Runner can convert assistant text events to stdout, tool call events to stderr, tool return events to runner logs, and result events to final output and usage information.

[0051] This mechanism allows the execution process of different Agent CLIs to be displayed in a consistent manner in both the backend and frontend dashboards.

[0052] S7. Unified log records are written to the asynchronous reporting queue and sent to the backend platform or visualization panel by an independent reporting thread. When reporting fails, it can be retried according to the preset number of times and intervals to avoid network abnormalities blocking the Agent CLI execution. Asynchronous reporting avoids network jitter or temporary backend unavailability from blocking the Agent CLI execution process, while ensuring that the execution process can be tracked and audited by the platform.

[0053] S8. During execution or after the process ends, parse the final output, structured JSON, failure reason, execution time, token usage, and cost information according to the Agent type, and write the parsing results to a unified result object; update the session state according to the return code, final result, and timeout status. In S8, the session state is updated. The session state includes pending, running, success, failed, timeout, and stopped states. The pending state means that the session has been created but has not yet been started; the running state means that the Agent CLI has been started and is executing. Success status: The Agent CLI terminates normally, and a valid completed action and structured result are detected; Failed status: The Agent CLI exits abnormally, lacks a final result, or fails to complete as agreed; Timeout status: Execution exceeds the preset timeout period; Stopped status: The callee or conflict control strategy actively stops; Runner also records creation time, start time, end time, process ID, return code, error reason, execution time, final output, and final result; The caller can query the session progress in real time through the status interface, and can also terminate a specified session through the stop interface.

[0054] In S8, the parsing results are written to a unified result object. Specifically, the final results of different Agent CLIs can be located in different positions; the Runner can use different parsing methods according to the Agent type; for ordinary output CLIs, the Runner can summarize the standard output and parse the final JSON; for streaming event CLIs, the Runner can extract the final text, execution time, interaction rounds, token usage, and cost information from the result event; after parsing, the Runner generates a unified result object for the business platform to save; the unified result object may include: final_output: the Agent's final text output; final_result: the structured JSON result; token_usage: input token, output token, cached token, total token, and cost; error: the reason for failure; return_code: the process return code; and duration_ms: the execution time.

[0055] S9. Provide the caller or business platform with access to the session list, status query, log query, final result query, visualization page, and session termination interface, enabling the caller to continuously observe the remote agent's execution process and terminate the specified session when necessary.

[0056] The Runner in S9 provides the following query interfaces: sessions, status, logs, view, and stop. The sessions interface queries the session list; the status interface queries the status of a specified session; the logs interface queries the logs and results of a specified session; the view interface views the session log page; and the stop interface stops a specified session. Through these interfaces, the backend system, test platform, desktop application, or operation and maintenance platform can uniformly view the Agent execution status without directly reading remote processes or local log files.

[0057] Application examples of this invention are as follows: Example 1: Automated Testing Scenario The testing platform submits tasks to the Runner, which then launches Codex or the Claude Code CLI. The Agent observes and operates the test machine through the remote Airtest tool service. The Runner transmits back the Agent's thought process text, tool call commands, tool return results, and final test conclusions in real time.

[0058] Example 2: Backend automated processing scenario The backend system submits code analysis or configuration processing tasks to the Runner. The Runner starts the specified AgentCLI, completes the analysis or modification in the isolated working directory, and sends the process logs and final JSON results back to the backend.

[0059] Example 3: Desktop Automation Scenario The desktop application passes the address of the local or remote desktop control service as the target resource to the Runner. After the Runner starts the Agent CLI, the Agent performs operations such as clicking, inputting, and screenshot analysis through this service. The Runner controls session conflicts for the same desktop resource to prevent multiple Agents from operating the same desktop simultaneously.

[0060] Example 4: CI or Operations Scenario The CI platform or operations platform submits diagnostic tasks to the Runner. The Runner selects the corresponding Agent CLI to execute analysis, invoke tools, output diagnostic results, and uniformly send the streaming logs and final results back to the platform panel.

[0061] like Figure 2 As shown, this invention provides a remote session orchestration and streaming observable execution system for Agent CLI. The system includes a unified task access module, a session state management module, a target resource conflict control module, an Agent CLI adaptation module, a process execution and isolation module, a streaming log collection module, an asynchronous log reporting module, a result parsing module, and a visualization query module. The unified task access module receives a remote agent execution request submitted by the caller; the request includes agent type, task content or prompt words, business serial number, target resource identifier, target tool address and caller session identifier information.

[0062] The caller can submit tasks to the Runner through a unified interface. Request fields may include: runner_session_id: Runner session identifier, which can be passed in by the caller or automatically generated by the Runner; agent_provider: Agent type, such as codex, claude; task or prompt: The task content that the Agent needs to execute; target_resource_id or target_tool_url: Target resource identifier or remote tool address; flow_id, task_id, session_id: Business flow number or task identifier in the business system.

[0063] When the caller only passes in the task without the complete prompt, the Runner can generate a default prompt template based on the target tool type; when the caller passes in the complete prompt, the Runner can directly use the prompt provided by the caller.

[0064] The session state management module creates a Runner session based on the request, generates or registers a Runner session identifier, and records the Agent type, business serial number, target resource identifier, working directory, initial state, and creation time; after the Runner session is created, its state can be initially set to pending. The target resource conflict control module queries whether there are currently active sessions in a pending or running state based on the target resource identifier. If the same target resource is already occupied by another Agent session, session conflict handling is performed. Specifically, the session conflict handling in the target resource conflict control module involves executing a conflict handling strategy, which includes: stopping the old session, rejecting the new session, and queuing the new session. Stopping the old session involves recording that the old session was stopped because the new session occupied the same target resource; rejecting the new session involves returning a message indicating that the target resource is occupied; and queuing the new session involves waiting for the old session to finish before executing the new session.

[0065] The Agent CLI adaptation module selects the corresponding CLI adapter based on the Agent type. Different adapters are responsible for handling their respective startup parameters, permission parameters, environment variables, and output format differences; and generate CLI startup commands and runtime environment; Runner can create an independent working directory for this session and set environment information such as PATH, temporary directory, timeout, and target tool address; The Runner selects the corresponding adapter based on the agent_provider field.

[0066] Taking Codex CLI as an example, Runner can load a specified environment file, set the PATH, and generate Codex execution commands, while disabling color output to make the output more suitable for log collection and parsing.

[0067] Taking Claude Code CLI as an example, the Runner can generate execution commands that include permission skip parameters, session-free persistence parameters, and streaming JSON output parameters, and perform event-level parsing on its stream-json output.

[0068] Command construction and output parsing for different CLIs are handled by their respective adapters, but a unified session, unified log, and unified results are exposed to the caller.

[0069] The process execution and isolation module starts the Agent CLI process in an independent working directory, updates the session status from pending to running, and records the process ID, start time, and summary of running parameters. The streaming log collection module continuously reads standard output, errors, and internal events of the Runner during the execution of the Agent CLI, and converts them into unified log records according to session identifier, business serial number, log sequence number, log time, log source, and content. The asynchronous log reporting module writes unified log records into an asynchronous reporting queue and sends them to the backend platform or visualization panel by an independent reporting thread. If reporting fails, it can retry according to a preset number of times and intervals to avoid network anomalies blocking the execution of the Agent CLI. The result parsing module, during execution or after process termination, parses the final output, structured JSON, failure reason, execution time, token usage, and cost information according to the Agent type, and writes the parsing results into a unified result object; it also updates the session state based on the return code, final result, and timeout status. The visualization query module provides callers or business platforms with access to session lists, status queries, log queries, final result queries, visualization pages, and a session termination interface, enabling callers to continuously observe the execution process of the remote agent and terminate a specified session when necessary.

[0070] The result parsing module updates the session status, which includes pending, running, success, failed, timeout, and stopped states. The pending state means that the session has been created but has not yet been started; the running state means that the Agent CLI has been started and is executing. Success status: The Agent CLI terminates normally, and a valid completed action and structured result are detected; Failed status: The Agent CLI exits abnormally, lacks a final result, or fails to complete as agreed; Timeout status: Execution exceeds the preset timeout period; Stopped status: The callee or conflict control strategy actively stops; Runner also records creation time, start time, end time, process ID, return code, error reason, execution time, final output, and final result; The caller can query the session progress in real time through the status interface, and can also terminate a specified session through the stop interface.

[0071] The result parsing module writes the parsing results into a unified result object. Specifically: the final results of different Agent CLIs can be located in different positions; the Runner can use different parsing methods according to the Agent type; for ordinary output CLIs, the Runner can summarize the standard output and parse the final JSON; for streaming event CLIs, the Runner can extract the final text, execution time, interaction rounds, token usage, and cost information from the result event; after parsing, the Runner generates a unified result object for the business platform to save; the unified result object may include: final_output: the Agent's final text output; final_result: the structured JSON result; token_usage: input token, output token, cached token, total token, and cost; error: the reason for failure; return_code: the process return code; and duration_ms: the execution time.

[0072] The Runner in the visualization query module provides the following query interfaces: sessions, status, logs, view, and stop. The sessions interface queries the session list; the status interface queries the status of a specified session; the logs interface queries the logs and results of a specified session; the view interface displays the session log page; and the stop interface stops a specified session. Through these interfaces, the backend system, test platform, desktop application, or operations and maintenance platform can uniformly view the Agent execution status without directly reading remote processes or local log files.

[0073] The above description is only a preferred embodiment of the present invention. All equivalent changes and modifications made within the scope of the claims of the present invention should be included in the scope of the present invention.

Claims

1. A remote session orchestration and streaming observable execution method for Agent CLI, characterized in that: Includes the following steps: S1. Receive the remote agent execution request submitted by the caller; S2. Create a Runner session according to the request, generate or register a Runner session identifier, and record the Agent type, business serial number, target resource identifier, working directory, initial status, and creation time; the Runner session can be set to pending status after creation. S3. Query whether there is an active session in the pending or running state based on the target resource identifier. If the same target resource has been occupied by other Agent sessions, perform session conflict handling. S4. Select the corresponding CLI adapter according to the Agent type. Different adapters are responsible for handling their respective startup parameters, permission parameters, environment variables and output format differences. It generates CLI startup commands and runtime environment; Runner can create a separate working directory for this session and set environment information such as PATH, temporary directory, timeout, and target tool address; S5. Start the Agent CLI process in the independent working directory, update the session status from pending to running, and record the process ID, start time, and summary of running parameters. S6. During the execution of Agent CLI, continuously read standard output, errors, and internal events of Runner, and convert them into unified log records according to session identifier, business serial number, log sequence number, log time, log source, and content; S7. Unified log records are written to an asynchronous reporting queue and sent to the backend platform or visualization panel by an independent reporting thread; if a reporting failure occurs, it can be retried according to a preset number of times and intervals to avoid network anomalies blocking the execution of the Agent CLI; S8. During execution or after the process ends, parse the final output, structured JSON, failure reason, execution time, token usage, and cost information according to the Agent type, and write the parsing results to a unified result object; update the session state according to the return code, final result, and timeout status. S9. Provide the caller or business platform with access to the session list, status query, log query, final result query, visualization page, and session termination interface, enabling the caller to continuously observe the remote agent's execution process and terminate the specified session when necessary.

2. The remote session orchestration and streaming observable execution method for Agent CLI as described in claim 1, characterized in that: The request includes Agent type, task content or prompt words, business serial number, target resource identifier, target tool address, and caller session identifier information.

3. The remote session orchestration and streaming observable execution method for Agent CLI as described in claim 1, characterized in that: The specific steps for handling session conflicts in S3 are as follows: Execute a conflict handling strategy, which includes: stopping the old session, rejecting the new session, and queuing the new session. Stopping the old session means recording that the old session was stopped because the new session occupied the same target resource; rejecting the new session means returning that the target resource is occupied; queuing the new session means waiting for the old session to end before executing the new session.

4. The remote session orchestration and streaming observable execution method for Agent CLI as described in claim 1, characterized in that: In S8, the session state is updated. The session state includes pending, running, success, failed, timeout, and stopped states. The pending state means that the session has been created but has not yet been started; the running state means that the Agent CLI has been started and is executing. Success status: The Agent CLI terminates normally, and a valid completed action and structured result are detected; Failed status: The Agent CLI exits abnormally, lacks a final result, or fails to complete as agreed; Timeout status: Execution exceeds the preset timeout period; Stopped status: The callee or conflict control strategy actively stops; Runner also records creation time, start time, end time, process ID, return code, error reason, execution time, final output, and final result; The caller can query the session progress in real time through the status interface, and can also terminate a specified session through the stop interface.

5. The remote session orchestration and streaming observable execution method for Agent CLI as described in claim 1, characterized in that: In S8, the parsing results are written to a unified result object. Specifically, the final results of different Agent CLIs can be located in different positions; the Runner can use different parsing methods according to the Agent type. For standard output CLIs, Runner can aggregate the standard output and parse the final JSON; for streaming event CLIs, Runner can extract the final text, execution time, interaction rounds, token usage, and cost information from the result event. After parsing, the Runner generates a unified result object for the business platform to save. The unified result object may include: final_output: the final text output of the Agent; final_result: the structured JSON result. token_usage: input token, output token, cached token, total tokens, cost; error: reason for failure; return_code: process return code; and duration_ms: execution time.

6. The remote session orchestration and streaming observable execution method for Agent CLI as described in claim 1, characterized in that: The Runner in S9 provides the following query interfaces: sessions, status, logs, view, and stop. The sessions interface queries the session list; the status interface queries the status of a specified session; the logs interface queries the logs and results of a specified session; the view interface views the session log page; and the stop interface stops a specified session. Through these interfaces, the backend system, test platform, desktop application, or operation and maintenance platform can uniformly view the Agent execution status without directly reading remote processes or local log files.

7. A remote session orchestration and streaming observable execution system for Agent CLI, characterized in that: The system includes a unified task access module, a session state management module, a target resource conflict control module, an Agent CLI adaptation module, a process execution and isolation module, a streaming log collection module, an asynchronous log reporting module, a result parsing module, and a visualization query module. The unified task access module receives remote agent execution requests submitted by the caller; The session state management module creates a Runner session based on the request, generates or registers a Runner session identifier, and records the Agent type, business serial number, target resource identifier, working directory, initial state, and creation time; after the Runner session is created, its state can be initially set to pending. The target resource conflict control module queries whether there are currently active sessions in a pending or running state based on the target resource identifier. If the same target resource has been occupied by other Agent sessions, session conflict handling is performed. The Agent CLI adaptation module selects the corresponding CLI adapter according to the Agent type. Different adapters are responsible for handling their respective startup parameters, permission parameters, environment variables, and output format differences. It generates CLI startup commands and runtime environment; Runner can create a separate working directory for this session and set environment information such as PATH, temporary directory, timeout, and target tool address; The process execution and isolation module starts the Agent CLI process in an independent working directory, updates the session status from pending to running, and records the process ID, start time, and summary of running parameters. The streaming log collection module continuously reads standard output, errors, and internal events of the Runner during the execution of the Agent CLI, and converts them into unified log records according to session identifier, business serial number, log sequence number, log time, log source, and content. The asynchronous log reporting module writes unified log records into an asynchronous reporting queue and sends them to the backend platform or visualization panel by an independent reporting thread. If reporting fails, it can retry according to a preset number of times and intervals to avoid network anomalies blocking the execution of the Agent CLI. The result parsing module, during execution or after process termination, parses the final output, structured JSON, failure reason, execution time, token usage, and cost information according to the Agent type, and writes the parsing results into a unified result object; it also updates the session state based on the return code, final result, and timeout status. The visualization query module provides callers or business platforms with access to session lists, status queries, log queries, final result queries, visualization pages, and a session termination interface, enabling callers to continuously observe the execution process of the remote agent and terminate a specified session when necessary.

8. The remote session orchestration and streaming observable execution system for Agent CLI as described in claim 7, characterized in that: The request includes Agent type, task content or prompt words, business serial number, target resource identifier, target tool address, and caller session identifier information.

9. The remote session orchestration and streaming observable execution system for Agent CLI as described in claim 7, characterized in that: The specific process of handling session conflicts in the target resource conflict control module is as follows: Execute a conflict handling strategy, which includes: stopping old sessions, rejecting new sessions, and queuing new sessions. Stopping old sessions involves recording that the old session was stopped because the new session occupied the same target resource; rejecting new sessions involves returning a message indicating that the target resource is occupied; and queuing new sessions involves waiting for the old session to end before executing the new session.

10. The remote session orchestration and streaming observable execution system for Agent CLI as described in claim 7, characterized in that: The result parsing module updates the session status, which includes pending, running, success, failed, timeout, and stopped states. The pending state means that the session has been created but has not yet been started; the running state means that the Agent CLI has been started and is executing. Success status: The Agent CLI terminates normally, and a valid completed action and structured result are detected; Failed status: The Agent CLI exits abnormally, lacks a final result, or fails to complete as agreed; Timeout status: Execution exceeds the preset timeout period; Stopped status: The callee or conflict control strategy actively stops; Runner also records creation time, start time, end time, process ID, return code, error reason, execution time, final output, and final result; The caller can query the session progress in real time through the status interface, and can also terminate a specified session through the stop interface.

11. The remote session orchestration and streaming observable execution system for Agent CLI as described in claim 7, characterized in that: The result parsing module writes the parsing results into a unified result object. Specifically, the final results of different Agent CLIs can be located in different positions; the Runner can use different parsing methods according to the Agent type. For standard output CLIs, Runner can aggregate the standard output and parse the final JSON; for streaming event CLIs, Runner can extract the final text, execution time, interaction rounds, token usage, and cost information from the result event. After parsing, the Runner generates a unified result object for the business platform to save. The unified result object may include: final_output: the Agent's final text output; final_result: the structured JSON result. token_usage: input token, output token, cached token, total tokens, cost; error: reason for failure; return_code: process return code; and duration_ms: execution time.

12. The remote session orchestration and streaming observable execution system for Agent CLI as described in claim 7, characterized in that: The Runner in the visualization query module provides the following query interfaces: sessions, status, logs, view, and stop. The sessions interface queries the session list; the status interface queries the status of a specified session; the logs interface queries the logs and results of a specified session; the view interface displays the session log page; and the stop interface stops a specified session. Through these interfaces, the backend system, test platform, desktop application, or operations and maintenance platform can uniformly view the Agent execution status without directly reading remote processes or local log files.

Images