Karpathy 预警：ReAct 上下文膨胀，Plan-and-Act 解法

Karpathy warned about this months ago:

"If agents had less knowledge or less memory, maybe they would be better."

His point was that everything already inside the model's input competes with the task for attention.

A standard ReAct loop is built that way, since everything that goes into the prompt is never removed from it.

For more context, the ReAct pattern runs one model in a single loop.

The model generates a thought about what to do next, takes one action, reads the observation that comes back, appends all three to the same prompt, and repeats until it decides the task is over.

So a failed search from step three is still retained and accessible at subsequent steps, competing with the original objective for the model’s attention.

Plan-and-Act is one answer to that, and it is aimed at agents that run long enough that context management becomes an actual engineering problem that cannot be directly solved with prompt-tuning.

It splits the loop into two sub-tasks.

The authors of the Plan-and-Act paper experimented on web navigation, so the observation coming back after every action is the raw HTML of the page the agent is currently on.

A planner reads the user query and the initial page and writes high-level steps.

An executor reads the plan, the task, its own past actions, and the current HTML, then emits one grounded action.

After each action, the executor strips the HTML it no longer needs before taking the next one, so the execution context does not grow the way a ReAct trace does.

Whether this is helpful is determined by plan granularity.

A good step covers one unit of work, like searching for the product in the search box.

An individual click is too small to be a step, and “analyze the search results” is not a step at all, because it pushes the reasoning back onto the executor.

A step must also name the actual values it needs.

The paper’s planner instructions ask for “input New York as the arrival city” instead of “input the arrival city”, because the second version leaves the executor to guess which city goes in the box.

The executor’s job is picking the right element and typing into it, not filling in the blanks the planner left open.

They also found that a badly trained planner makes things worse than no planner at all.

On WebArena-Lite, a ReAct-style executor with no planner scored 36.97%.

But the same executor with a naively finetuned planner scored just 20.60%.

The planner had never seen those sites, so it wrote steps that read fine but matched nothing on the page, and the executor followed them anyway.

A properly trained planner reached 43.63%.

A plan written once and never revised has its own problem. For instance, if the search for “library at CMU” gives no results, the executor will still hold a step that cannot work anymore, and it will keep trying it anyway.

Replanning after every action is necessary to recover from that.

For instance, in the paper, the planner saw the current state, the previous plans, and the actions taken, and rewrote the step to “libraries near CMU”, which increased the score to 53.94%.

As a result, the failed attempt got replaced in the plan rather than accumulated in the context.

The cost is one planner call per executor step. The authors flag this directly and suggest letting the executor decide when a replan is required.

Here's the paper → https://arxiv.org/pdf/2503.09572

Under the hood, this is all part of the harness design rather than model choice.

If you want to see this in practice, my co-founder rebuilt Claude Code's harness in CrewAI layer by layer, adding planning, delegation, sandboxing, and memory one layer at a time.

Read it below.