Xingyao Wang 8b1f207d39
feat: support remote runtime (#3406)
* feat: refactor building logic into runtime builder

* return image name

* fix testcases

* use runtime builder for eventstream runtime

* have runtime builder return str

* add api_key to sandbox config

* draft remote runtime

* remove extra if clause

* initialize runtime based on box class

* add build logic

* use base64 for file upload

* get runtime image prefix from API

* replace ___ with _s_ to make it a valid image name

* use /build to start build and /build_status to check the build progress

* update logging

* fix exit code

* always use port

* add remote runtime

* rename runtime

* fix tests import

* make dir first if work_dir does not exists;

* update debug print to remote runtime

* fix exit close_sync

* update logging

* add retry for stop

* use all box class for test keep prompt

* fix test browsing

* add retry stop

* merge init commands to save startup time

* fix await

* remove sandbox url

* support execute through specific runtime url

* fix file ops

* simplify close

* factor out runtime retry code

* fix exception handling

* fix content type error (e.g., bad gateway when runtime is not ready)

* add retry for wait until alive;
add retry for check image exists

* Revert "add retry for wait until alive;"

This reverts commit dd013cd2681a159cd07747497d8c95e145d01c32.

* retry when wait until alive

* clean up msg

* directly save sdist to temp dir for _put_source_code_to_dir

* support running testcases in parallel

* tweak logging;
try to close session

* try to close session even on exception

* update poetry lock

* support remote to run integration tests

* add warning for workspace base on remote runtime

* set default runtime api

* remove server runtime

* update poetry lock

* support running swe-bench (n=1) eval on remoteruntime

* add a timeout of 30 min

* add todo for docker namespace

* update poetry loc
2024-08-29 15:53:37 +00:00
..
2024-08-29 15:53:37 +00:00
2024-08-26 08:16:49 -06:00
2024-08-26 01:31:37 -06:00
2024-08-22 13:16:27 +02:00

OpenHands Architecture

This directory contains the core components of OpenHands.

This diagram provides an overview of the roles of each component and how they communicate and collaborate. OpenHands System Architecture Diagram (July 4, 2024)

Classes

The key classes in OpenHands are:

  • LLM: brokers all interactions with large language models. Works with any underlying completion model, thanks to LiteLLM.
  • Agent: responsible for looking at the current State, and producing an Action that moves one step closer toward the end-goal.
  • AgentController: initializes the Agent, manages State, and drive the main loop that pushes the Agent forward, step by step
  • State: represents the current state of the Agent's task. Includes things like the current step, a history of recent events, the Agent's long-term plan, etc
  • EventStream: a central hub for Events, where any component can publish Events, or listen for Events published by other components
    • Event: an Action or Observeration
      • Action: represents a request to e.g. edit a file, run a command, or send a message
      • Observation: represents information collected from the environment, e.g. file contents or command output
  • Runtime: responsible for performing Actions, and sending back Observations
    • Sandbox: the part of the runtime responsible for running commands, e.g. inside of Docker
  • Server: brokers OpenHands sessions over HTTP, e.g. to drive the frontend
    • Session: holds a single EventStream, a single AgentController, and a single Runtime. Generally represents a single task (but potentially including several user prompts)
    • SessionManager: keeps a list of active sessions, and ensures requests are routed to the correct Session

Control Flow

Here's the basic loop (in pseudocode) that drives agents.

while True:
  prompt = agent.generate_prompt(state)
  response = llm.completion(prompt)
  action = agent.parse_response(response)
  observation = runtime.run(action)
  state = state.update(action, observation)

In reality, most of this is achieved through message passing, via the EventStream. The EventStream serves as the backbone for all communication in OpenHands.

flowchart LR
  Agent--Actions-->AgentController
  AgentController--State-->Agent
  AgentController--Actions-->EventStream
  EventStream--Observations-->AgentController
  Runtime--Observations-->EventStream
  EventStream--Actions-->Runtime
  Frontend--Actions-->EventStream

Runtime

Please refer to the documentation to learn more about Runtime.