Prompt工程与循环工程，清晰解释

Prompt engineering & loop engineering, clearly explained!

At its core, an agent is a while loop:

• The model runs - It requests tool calls - The tool results return to the context - The model runs again until it stops requesting tools

ReAct described this form of loop back in 2022-23, and almost every agent/framework runs a similar implementation of this.

So loops aren't a new thing at all, and the above implementation of loops was solved a long time ago.

What wasn't solved is the loop around the above loop, and this is what Boris/Peter talked about recently.

In the most common setup, you are the loop around the loop.

• You write a prompt - Read the turns the agent runs - Write the next prompt - And repeat, catching failures as it runs

Now there are attempts to let the system run the outer loop too, so that you can eliminate yourself.

• It starts on a schedule or an event - It runs for many turns with no prompt in between - It decides on its own when it's done - It comes back only when something needs you

Consider a failing test in CI to understand this.

In the current way, you paste the error into the agent, read the fix, run the tests, and paste the next failure back in until they pass.

So every turn goes through you.

The loop runs those same turns on its own.

It triggers on a schedule, reads the failure, drafts a fix on a branch, runs the tests, and feeds a failure back in as the next turn, until they pass or it hits a turn limit.

A separate reviewer checks the fix, opens a PR if it's clean, and flags it for a human if it isn't.

So the inner loop was always automatic. The part being automated now is your involvement in that loop.

None of that comes for free though, as expected.

> Sitting in the outer loop gave you the flexibility to stop, possess project memory, and be the reviewer. But each of those now has to exist in the system.

> Also, while sitting in the loop was slow, you understood the system.

But one big downside of taking yourself out is that you keep the ownership, but would likely lose the understanding.

> Inherently, a loop doesn't know when to stop on its own either. It will take the agent's word that the work is done and stop on a fix while the tests still fail, so the stop has to be a real check, plus a turn or token cap to avoid infinite loops.

> The context grows every turn, and the model gets worse as its context fills up.

So the loop should trim it and keep summaries instead of full history, move large outputs to files, and split subtasks into separate runs.

> Lastly, the agent can't be the one to check its own work, since it will pass whatever it wrote.

A separate model or a binary/deterministic test should provide that signal.

And the cost for all this adds up fast since every turn sends the whole context again, so a long loop can spend many times what a single prompt would.

If you want to dive deeper, my co-founder wrote a full breakdown, from the loop above to a run that finishes on its own, with the code behind each part.

Read it below.