feature: Condenser Interface and Defaults

[csmith49]

End-user friendly description of the problem this fixes or functionality that this introduces

• Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

---

Give a summary of what the PR does, explaining any non-trivial design decisions

This PR adds an abstract memory condenser interface, provides a few default condenser implementations, and updates the CodeActAgent to use the configured condenser during inference.

Condensers exist to reduce the size of the state that must be considered during an agent's step function. They provide a condense: list[Event] -> list[Event] function that can perform an arbitrary transformation on the history of a state before it is seen by an agent, including:

• Summarizing the history in a new event (as in the LLMCondenser),
• Removing old events (as in the `RecentEventsCondenser), or
• Returning the history as-is (as in the NoOpCondenser).

This does not change the underlying state, but can be used by agents as a form of attention and to manage the size of the context in long-running jobs. For an example, see the implementation in CodeActAgent -- the default condenser is the NoOpCondenser, so while the agent is "using the condenser" there is no visible change unless otherwise configured. Currently, condensers must be set by manually initializing an AgentConfig object.

The intent of this PR is to lay the groundwork for an evaluation framework that will let us assess the efficacy of different condenser implementations and, if warranted, support switching between condensers with simple configuration options.

Link of any specific issues this addresses

#5715

[enyst]

Just a small detail, you may want to check this bit, the other config classes are dataclasses instead of BaseModel. Some bunch of utility code works with them as dataclasses and assumes they all are, I think - stuff like ensure that their values are loaded correctly etc, e.g.

OpenHands/openhands/core/config/utils.py

Line 42 in f0ca223

for field_name, field_type in sub_config.__annotations__.items():

[csmith49]

I'll double-check. Easy enough to change to data classes if needed!

[enyst]

As it currently is, will this config class read its attributes from env? The other config instances read from env > then from toml > then fallback to the default values set in the dataclass.

Why is it a BaseModel, can it be a dataclass and still do what was useful in the BaseModel?

[csmith49]

This config is not currently read from the environment. Until we've got a condenser that we want on by default, the only way to set up anything besides the NoOpCondenser is to programmatically build the config object.

Why is it a BaseModel, can it be a dataclass and still do what was useful in the BaseModel?
Not so compactly. The BaseModel implementation is there for two reasons:

1. Easy field validation, notably for setting bounds on numerical values and ensuring the type field is instantiated with the literal.
2. Easy serialization. The type field sets up the configuration objects as a discriminated union, so there's trivial conversion to JSON and back with config.model_dump_json() and CondenserConfig.model_validate_json().

I can re-implement 1 and 2 over dataclass objects if you want to avoid the dependency here. But we don't lose access to, e.g., __annotations__.

[enyst]

Alternatively, we can make an issue for this, and we can merge this PR as it is working in the development mode?

I do see at least two reasons why this matters:

• people usually run with docker run, where they pass settings via env, so this feature is unavailable basically, for now
• inconsistency in code design, for us even, and more so for external contributors, to understand, follow and work with the code.

If we make an issue, we can discuss there if maybe there are benefits to go the other way around, make them all BaseModel. I am seeing this kind of thing (mix of dataclass with BaseModel) in other parts of the code too, and it is IMHO more complexity when we have two different ways, rather than whichever of them. 😅

[csmith49]

people usually run with docker run, where they pass settings via env, so this feature is unavailable basically, for now

That's true, and something I want to fix. I had OpenHands make a pass at extending the config pipeline (env + toml) to support condensers and it made a big mess that I couldn't seem to fix without blowing up the size of this PR.

One thing that made integration tricky was actually the discriminated union -- different condensers have different but overlapping config, and I couldn't see how to extend the env + toml implementation to support "recursive" configuration.

inconsistency in code design, for us even, and more so for external contributors, to understand, follow and work with the code.

I'd be happy to make an issue and we can get some more discussion there!

[csmith49]

See #6015 for the issue.

[enyst]

This is exciting and beautiful ❤️

[neubig]

When this has no merge conflicts, passing tests, and is ready for review could you re-request my review through github by pressing the "cycle" button? Thanks!

[enyst]

@openhands-agent
IMPORTANT:
In CI, we get this error:

Run poetry install --without evaluation,llama-index
Installing dependencies from lock file
pyproject.toml changed significantly since poetry.lock was last generated. Run poetry lock [--no-update] to fix the lock file.
Error: Process completed with exit code 1

Please run poetry lock --no-update

Don't do anything else.

[openhands-agent]

OpenHands started fixing the pr! You can monitor the progress here.

[enyst]

This is very exciting, it will allow us to experiment with greater ease and let everyone try approaches! Just plug in and play ❤️

[xingyaoww]

Love seeing this coming into shape! I think the next step would be improving the condensation summarization prompt & get it to work - so we can at least have about the same perf on SWE-Bench

btw, we also need to do poetry lock --no-update. It seems we changed a lot here

nvm it seems ok