设计一个自行驱动 Agent 的多步任务循环

In this article, we will learn about how to design a loop that prompts your agent - what the loop really is, why a single prompt is not enough, and the five parts we need to build a loop that keeps prompting the agent on its own until the job is done. We will also see where loops came from, what they really cost to run, and the skills that make them powerful.

We will cover the following:

• The Five Parts of the Loop
• Step 1: Define What "Done" Looks Like
• Step 2: Build the Context, Not the Instruction
• Step 3: Let the Agent Act and Capture Everything
• Step 4: Close the Loop with Feedback
• Step 5: Set the Stop Conditions
• The Full Loop in Code
• Let's Walk Through One Run
• Cost of Running the Loop
• Reusable Skills
• Common Mistakes I am Amit Shekhar, Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.

I teach AI and Machine Learning at Outcome School.

Let's get started.

Before we go into the details, let's understand the big picture.

Most people think working with an AI agent means writing one really good prompt. We type our request, the agent replies, and we are done. This works for a quick question. It does not work for a real job that needs many steps.

A real job looks like this. Write the code. Run the tests. The tests fail. Read the error. Fix the code. Run the tests again. Repeat until everything passes.

We do not want to type each of those prompts by hand. That is slow, and it does not scale. So, here comes the loop to the rescue. Instead of us typing each prompt, we build a small system that writes those prompts for us, turn after turn, until the job is finished.

The new skill is not writing one perfect prompt. The new skill is building the system that keeps prompting the agent for us.

That system is the loop. In this blog, we will learn how to design it.

Let's start with the most important idea in this whole blog.

Think of a game of chess. A single prompt is a single move. You look at the board, you make one move, and your turn ends. If you only ever make one move, you can never win a full game.

A loop is different. A loop is a strategy. It is the set of rules that decides every move, checks the board after each move, and keeps playing until the game is won.

A prompt is a single move. A loop is a strategy.

We are no longer playing the game turn by turn, typing each prompt ourselves. We are designing the rules that the agent plays inside. We set up the rules once, and then we let the agent play the full game on its own.

So, how do we design these rules?

Let's learn the five parts of the loop.

A loop that prompts the agent has five parts. Do not worry, we will learn about each of them in detail.

• Define "done" - the check that tells the loop when to stop.
• Build the context - the fresh information we feed the agent each turn.
• Act and capture - run the step and grab the result.
• Close the loop with feedback - turn the result into the next prompt.
• Set the stop conditions - the guardrails that keep the loop safe. Here is how these five parts fit together, as below:

        +--------------------------------------------------+
        |                     The Loop                     |
        |                                                  |
        |   Build Context  --->  +-------+                 |
        |                        | Agent |                 |
        |                        +-------+                 |
        |                            |                     |
        |                            | acts                |
        |                            v                     |
        |                    Capture Result                |
        |                            |                     |
        |                            v                     |
        |                    Check "Done"? ----- Yes ---> Stop
        |                            |                     |
        |                            | No (feedback)       |
        |                            |                     |
        |                            +---------------------+
        |                       (next turn)                |
        +--------------------------------------------------+
                    Stop conditions wrap the whole loop

Here, we can see the cycle. We build the context, the agent acts, we capture the result, and we check if we are done. If yes, we stop. If no, we feed the result back as the next prompt and go around again. The stop conditions sit around the whole thing to keep it safe.

Now, let's understand each part one by one.

Before anything runs, we must answer one question: how will the loop know it has finished?

This is the first step, and it is the most important one. If we cannot describe "done", the agent has nothing to loop toward. It will keep going forever, or it will stop too early.

So, we write the success check first, before we write anything else. This check must be in code, not in our head. Let's say we are building an agent that fixes a bug. For us, "done" means the tests pass. A few more examples of "done", as below:

• The tests pass.
• The output matches a schema.
• A score clears a threshold. Let's see this as a simple function, as below:

def is_done(result):
    # done means all tests passed
    return result.tests_passed

Here, we have written a small function that returns True when the work is finished and False when it is not. The loop will call this function after every turn.

This check becomes the heartbeat of our loop. Every turn, the loop checks the heartbeat. If the heart says done, the loop stops. If it says not yet, the loop goes around again.

So we must always start here, with the check. Everything else in the loop is built on top of it.

This is how we define done. Now, let's move to the context.

Here is where most people go wrong. They keep hand-feeding the agent. They type a new instruction every time, by hand, and they paste in the files and the errors themselves.

We must stop doing this. Instead of typing the instruction, we build the context.

What does context mean here? It means everything the agent needs to make a good decision this turn, as below:

• The files it is working on.
• The tools it can use.
• The error logs from the last run.
• The past attempts it has already made. So, the prompt is no longer typed by us. The prompt is put together from the current state of the system.

Let's see this as code, as below:

def build_prompt(state):
    return f"""
    Goal: {state.goal}
    Files: {state.files}
    Last error: {state.last_error}
    Past attempts: {state.past_attempts}

    Decide the next step and make the change.
    """

Here, we can see that the prompt is built from state. We do not type the error by hand. We read it from the state and drop it into the prompt automatically. When the state changes, the prompt changes with it. That is the whole point.

So, the loop stays the same on every turn. Only the context changes. The same build_prompt function gives a different prompt each time, because the state behind it has moved forward.

This is how we build the context. Now, it's time to let the agent act.

Now we run the step. We send the prompt we built to the agent, and the agent does its work. It writes code, it calls a tool, it changes a file.

But the action is only half the job. The other half is to capture everything that came out of it, as below:

• The diff of what changed.
• The standard output from running the code.
• The failure message, if it failed.
• The new state of the system. Let's see this as code, as below:

def act_and_capture(prompt, state):
    output = agent.run(prompt)   # the agent does the work
    result = run_checks(output)  # run tests, grab logs, get the diff
    return result

Here, we have run the agent and then captured the result. The result holds the diff, the output, and whether the checks passed.

Now, here is the key idea. This output is not the finish line. It becomes the raw material for the next prompt. The failure we just captured is exactly what we will feed back to the agent so it can fix the problem. So we must capture all of it, and not throw it away.

This is how we act and capture. Now, let's close the loop.

We have a result. Now we feed that result back through the "done" check from Step 1. This is what makes it a loop and not just a single move.

There are only two paths, as below:

• Passed? Stop. The job is done.
• Failed? Turn the failure into the next prompt, automatically. This second path is the magic. When the work fails, we do not give up. We take the failure and turn it into the next instruction. Something like: "Tests failed with this error. Fix it."

The agent then re-prompts itself using what just happened. We did not type that new prompt. The loop built it from the failure.

Let's see this as code, as below:

def loop(state):
    while True:
        prompt = build_prompt(state)      # Step 2: build context
        result = act_and_capture(prompt, state)  # Step 3: act and capture

        if is_done(result):               # Step 1: check done
            return result                 # passed, so we stop

        # failed, so turn the failure into the next prompt
        state.last_error = result.error
        state.past_attempts.append(result)

Here, we can see the loop close on itself. If we are done, we return and stop. If we are not done, we save the error into the state, and the next turn's build_prompt will include that error automatically. The agent re-prompts itself using the failure. The loop feeds itself.

This is how we close the loop with feedback. But we have one problem left. Look at the code above. There is no exit if the agent keeps failing forever. Let's solve that next.

A loop with no way out is not a system. It is a cost that never stops. If the agent keeps failing and the loop keeps running, it will burn time and money with no end. So we must design the guardrails.

We set the stop conditions once, and then we let the loop run safely. A few important guardrails, as below:

• Cap the retries. Stop after a fixed number of turns, even if the job is not done.
• Watch the cost. Stop if we cross a budget for time or money.
• Add a human checkpoint. For the calls that matter, pause and ask a person before doing something risky. Let's add these guardrails to our loop, as below:

def loop(state, max_turns=10, max_cost=5.0):
    turns = 0
    cost = 0.0

    while turns < max_turns and cost < max_cost:
        turns += 1
        prompt = build_prompt(state)
        result = act_and_capture(prompt, state)
        cost += result.cost

        if is_done(result):
            return result   # success

        state.last_error = result.error
        state.past_attempts.append(result)

    return "stopped: hit a guardrail"   # safe exit

Here, we have wrapped the loop with two of these guardrails - the retry cap and the cost cap. The loop stops when the job is done, or when it runs out of turns, or when it crosses the budget. There is always an exit. The loop can never run forever.

This is how we keep the loop safe.

Note: The human checkpoint matters most for actions that are hard to undo. Deleting a file, sending money, or pushing to production are good examples. For these, we must pause the loop and let a person say yes before the agent acts.

Now that we have learned about all five parts, let's put them together in one place, as below:

# Step 1: define done
def is_done(result):
    return result.tests_passed

# Step 2: build the context from state
def build_prompt(state):
    return f"""
    Goal: {state.goal}
    Files: {state.files}
    Last error: {state.last_error}
    Past attempts: {state.past_attempts}

    Decide the next step and make the change.
    """

# Step 3: act and capture
def act_and_capture(prompt, state):
    output = agent.run(prompt)
    return run_checks(output)

# Step 4 and 5: close the loop with feedback, inside the guardrails
def loop(state, max_turns=10, max_cost=5.0):
    turns = 0
    cost = 0.0

    while turns < max_turns and cost < max_cost:
        turns += 1
        prompt = build_prompt(state)
        result = act_and_capture(prompt, state)
        cost += result.cost

        if is_done(result):
            return result

        state.last_error = result.error
        state.past_attempts.append(result)

    return "stopped: hit a guardrail"

Here, we can see the full picture. The five parts work together as one system. We define done, we build the context, the agent acts, we capture the result, we feed it back, and the guardrails keep it all safe.

We wrote this once. Now the agent can finish a multi-step job on its own. It works perfectly.

The best way to learn this is by taking an example. Let's say the goal is "fix the failing login bug". Let's walk through the loop turn by turn.

Turn 1: The state has the goal and the files, but no error yet. We build the prompt and send it. The agent changes the code. We capture the result. The tests still fail with "password check returns true for empty password". We are not done, so we save this error into the state.

Turn 2: Now build_prompt includes the new error from Turn 1. The agent reads "password check returns true for empty password" and fixes that exact line. We capture the result. The tests pass.

Turn 3: There is no Turn 3. The is_done check returned True on Turn 2, so the loop stopped on its own.

Here, we can notice the most important thing. We did not type a single prompt during this run. The error from Turn 1 became the prompt for Turn 2, automatically. The loop prompted the agent for us, and it stopped the moment the job was done.

Here is something that surprises people. Writing the code is cheap. Running the loop that writes it, again and again, is not.

Let's understand why. The model writes a piece of code in seconds, for a tiny cost. But the loop runs that model again and again, turn after turn, sometimes for hours. Every turn costs a little. A loop that runs all night can run thousands of turns. So the real cost is not in producing the code once. It is in all the turns the loop takes to get there.

This is why the stop conditions from Step 5 matter so much. A loop that does not stop is not just a bug. It is a charge that keeps growing while we sleep.

So, our most important job has changed. It is no longer about writing one clever prompt. It is about making sure the loop halts. We must cap the turns, watch the cost, and stop the moment the job is done.

Now, let's get to the part that matters most in the long run. The loop itself is just the wiring. The real value is in the skills it calls.

What is a skill here? A skill is a small, reusable tool that does one job well. Instead of asking the model to work out the same thing from scratch every turn, we turn that repeated work into a named tool the loop can call directly.

Here is the rule we must follow. When we find ourselves doing the same step again and again, we pull it out and make it a skill. When we crack a hard problem, we save that solution as a skill too. After that, the loop gets it for almost no cost on every later run.

A loop that has no skills inside it asks the model to solve the same problems all over again on every turn. A loop that calls a set of sharp, tested skills gets stronger every time we add one. This is what makes a loop grow more valuable over time instead of just burning money.

Most of the time, we do mistakes while designing the loop. Let's learn the common ones so we can avoid them, as below:

• No "done" check. Without a check in code, the loop never knows when to stop. Always write Step 1 first.
• Hand-feeding the prompt. If we type each prompt by hand, it is not a loop, it is just us doing the work. Build the prompt from state.
• Throwing away the output. The failure is the next prompt. If we do not capture it, we have nothing to feed back.
• No stop conditions. A loop with no way out keeps running and keeps charging us. Always cap the retries and watch the cost.
• Forcing a loop on a one-off task. A loop only pays off when the work repeats and can be checked. For a one-time job, a plain prompt is better.
• No skills inside the loop. If the loop works out the same thing from scratch every turn, it wastes time and tokens. Turn the repeated work into reusable skills. So, we stop playing the game move by move. We design the loop once, give it a way to check itself and a way to stop, and then we let it run.

That's it for now.

Thanks

Amit Shekhar

Founder @Outcome School