# How to design a loop that prompts your agent?
**作者**: Amit Shekhar
**日期**: 2026-06-08T13:57:01.000Z
**来源**: [https://x.com/amitiitbhu/status/2063983640535847093](https://x.com/amitiitbhu/status/2063983640535847093)
---
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.
## 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.
## Step 1: Define What "Done" Looks Like
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.
## Step 2: Build the Context, Not the Instruction
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.
## Step 3: Let the Agent Act and Capture Everything
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.
## Step 4: Close the Loop with Feedback
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.
## Step 5: Set the Stop Conditions
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.
## The Full Loop in Code
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.
## Let's Walk Through One Run
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.
## Cost of Running the Loop
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.
## Reusable Skills
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.
## Common Mistakes
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.
This way we can design a loop that prompts our agent to solve real, multi-step problems in a very simple way.
That's it for now.
Thanks
Amit Shekhar
Founder @Outcome School
## 相关链接
- [Amit Shekhar](https://x.com/amitiitbhu)
- [@amitiitbhu](https://x.com/amitiitbhu)
- [24K](https://x.com/amitiitbhu/status/2063983640535847093/analytics)
- [Outcome School](https://outcomeschool.com/)
- [AI and Machine Learning](https://outcomeschool.com/program/ai-and-machine-learning)
- [Outcome School](https://outcomeschool.com/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:57 PM · Jun 8, 2026](https://x.com/amitiitbhu/status/2063983640535847093)
- [24.6K Views](https://x.com/amitiitbhu/status/2063983640535847093/analytics)
- [View quotes](https://x.com/amitiitbhu/status/2063983640535847093/quotes)
---
*导出时间: 2026/6/9 13:30:29*
---
## 中文翻译
# 如何设计一个能够提示你的代理的循环？
**作者**: Amit Shekhar
**日期**: 2026-06-08T13:57:01.000Z
**来源**: [https://x.com/amitiitbhu/status/2063983640535847093](https://x.com/amitiitbhu/status/2063983640535847093)
---
在本文中，我们将学习如何设计一个能够提示你的代理的循环——包括循环到底是什么，为什么单一提示是不够的，以及构建一个能够自主持续提示代理直到任务完成的循环所需的五个部分。我们还将了解循环的由来、运行它的真正成本是什么，以及是什么技能让它们变得强大。
我们将涵盖以下内容：
- 循环的五个部分
- 第 1 步：定义“完成”的样子
- 第 2 步：构建上下文，而非指令
- 第 3 步：让代理行动并捕获一切
- 第 4 步：通过反馈闭环
- 第 5 步：设置停止条件
- 完整的代码循环
- 让我们走查一次运行
- 运行循环的成本
- 可复用的技能
- 常见错误
我是 Amit Shekhar，Outcome School 的创始人。我指导和 mentoring 了许多开发者，他们的努力让他们获得了高薪的技术工作，帮助许多科技公司解决了他们独特的问题，并创建了许多顶级公司正在使用的开源库。我热衷于通过开源、博客和视频分享知识。
我在 Outcome School 教授 AI 和机器学习。
让我们开始吧。
在深入细节之前，让我们先了解大局。
大多数人认为与 AI 代理合作就是写一个非常好的提示。我们输入请求，代理回复，我们就完成了。这对于快速提问有效。对于需要许多步骤的实际工作来说，这行不通。
实际的工作看起来是这样的：编写代码，运行测试，测试失败，阅读错误，修复代码，再次运行测试，重复直到一切通过。
我们不想手动输入每一个提示。那很慢，而且无法扩展。所以，循环来救场了。我们构建一个小系统，代替我们逐个输入提示，这个系统会为我们编写这些提示，一轮接一轮，直到任务完成。
> 新的技能不是写一个完美的提示。新的技能是构建一个能持续为我们提示代理的系统。
这个系统就是循环。在这篇博客中，我们将学习如何设计它。
让我们从整篇博客中最重要的概念开始。
想象一盘国际象棋。一个提示就是一步棋。你看棋盘，走一步，然后你的回合结束。如果你只走一步，你永远无法赢下整盘棋。
循环是不同的。循环是一种策略。它是一套规则，决定每一步棋，在每一步之后检查棋盘，并持续下棋直到获胜。
提示是一步棋。循环是策略。
我们不再是逐回合玩游戏，自己输入每个提示。我们正在设计代理在其中运行的规则。我们要设置一次规则，然后让代理自己玩完整场游戏。
那么，我们要如何设计这些规则？
让我们学习循环的五个部分。
## 循环的五个部分
一个提示代理的循环有五个部分。别担心，我们将详细了解它们中的每一个。
- 定义“完成”——告诉循环何时停止的检查。
- 构建上下文——我们在每一轮提供给代理的新信息。
- 行动并捕获——运行步骤并获取结果。
- 通过反馈闭环——将结果转化为下一个提示。
- 设置停止条件——保持循环安全的护栏。
这五个部分组合在一起，如下所示：
```
+--------------------------------------------------+
| The Loop |
| |
| Build Context ---> +-------+ |
| | Agent | |
| +-------+ |
| | |
| | acts |
| v |
| Capture Result |
| | |
| v |
| Check "Done"? ----- Yes ---> Stop
| | |
| | No (feedback) |
| | |
| +---------------------+
| (next turn) |
+--------------------------------------------------+
Stop conditions wrap the whole loop
```
在这里，我们可以看到这个周期。我们构建上下文，代理行动，我们捕获结果，然后我们检查是否完成。如果是，我们就停止。如果否，我们将结果作为下一个提示反馈回去，再次循环。停止条件包裹着整个过程以确保安全。
现在，让我们逐一理解每个部分。
## 第 1 步：定义“完成”的样子
在运行任何东西之前，我们必须回答一个问题：循环怎么知道它已经完成了？
这是第一步，也是最重要的一步。如果我们无法描述“完成”，代理就没有循环的目标。它会永远运行下去，或者过早停止。
所以，我们要先编写成功检查，然后编写其他任何东西。这个检查必须在代码中，而不是在我们的脑子里。假设我们正在构建一个修复错误的代理。对我们来说，“完成”意味着测试通过。以下是“完成”的几个例子：
- 测试通过。
- 输出符合模式。
- 分数超过阈值。
让我们把它看作一个简单的函数，如下所示：
```
def is_done(result):
# done means all tests passed
return result.tests_passed
```
在这里，我们编写了一个小函数，当工作完成时返回 True，未完成时返回 False。循环会在每一轮之后调用这个函数。
这个检查成为了我们循环的心跳。每一轮，循环都会检查心跳。如果心跳说完成了，循环就停止。如果还说没，循环就再转一圈。
所以我们必须总是从这里开始，从检查开始。循环中的其他一切都是建立在这个基础之上的。
这就是我们定义完成的方式。现在，让我们进入上下文。
## 第 2 步：构建上下文，而非指令
这是大多数人容易出错的地方。他们一直在手动喂代理。每次都输入一条新指令，然后手动粘贴文件和错误本身。
我们必须停止这样做。我们不再输入指令，而是构建上下文。
这里的上下文是什么意思？它意味着代理在这一轮做出正确决定所需的一切，如下所示：
- 它正在处理的文件。
- 它可以使用的工具。
- 上一轮运行产生的错误日志。
- 它已经尝试过的过去记录。
所以，提示不再由我们输入。提示是根据系统的当前状态组合而成的。
让我们把它看作代码，如下所示：
```
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.
"""
```
在这里，我们可以看到提示是根据 state 构建的。我们不手动输入错误。我们从 state 中读取它，并自动将其放入提示中。当状态改变时，提示也随之改变。这就是重点。
因此，循环在每一轮都保持不变。只有上下文改变。同一个 build_prompt 函数每次给出不同的提示，因为它背后的状态已经向前推进了。
这就是我们构建上下文的方式。现在，是时候让代理行动了。
## 第 3 步：让代理行动并捕获一切
现在我们运行这一步。我们将构建好的提示发送给代理，代理开始工作。它编写代码，调用工具，修改文件。
但行动只是工作的一半。另一半是捕获从中产生的一切，如下所示：
- 发生变更的差异。
- 运行代码的标准输出。
- 失败时的错误信息。
- 系统的新状态。
让我们把它看作代码，如下所示：
```
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
```
在这里，我们运行了代理，然后捕获了结果。结果保存了差异、输出以及检查是否通过。
现在，这是关键的想法。这个输出不是终点。它成为了下一个提示的原始材料。我们刚刚捕获的失败正是我们将反馈给代理以修复问题的内容。所以我们必须捕获所有这些，而不是丢弃它。
这就是我们行动并捕获的方式。现在，让我们闭环。
## 第 4 步：通过反馈闭环
我们有了结果。现在我们将该结果反馈给第 1 步中的“完成”检查。这就是使它成为一个循环而不仅仅是一步棋的原因。
只有两条路径，如下所示：
- 通过了？停止。工作完成。
- 失败了？将失败转化为下一个提示，自动地。
第二条路径是神奇之处。当工作失败时，我们不放弃。我们要把这个失败转化为下一个指令。比如：“测试失败，出现了这个错误。修复它。”
然后代理利用刚刚发生的事情重新提示自己。我们没有输入那个新的提示。循环是根据失败构建它的。
让我们把它看作代码，如下所示：
```
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)
```
在这里，我们可以看到循环自我封闭。如果我们完成了，我们就返回并停止。如果我们没有完成，我们将错误保存到 state 中，下一轮的 build_prompt 将自动包含那个错误。代理利用失败重新提示自己。循环自我供料。
这就是我们通过反馈闭环的方式。但我们还剩一个问题。看上面的代码。如果代理一直失败下去，就没有出口。让我们在接下来解决这个问题。
## 第 5 步：设置停止条件
没有出口的循环不是系统。它是永不停止的成本。如果代理一直失败，循环一直运行，它会无休止地消耗时间和金钱。所以我们必须设计护栏。
我们要设置一次停止条件，然后让循环安全地运行。几个重要的护栏，如下所示：
- 限制重试次数。即使工作未完成，在固定轮数后停止。
- 监控成本。如果我们超过了时间或金钱的预算，就停止。
- 增加人工检查点。对于重要的调用，在做有风险的事情之前暂停并询问一个人。
让我们将这些护栏添加到我们的循环中，如下所示：
```
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
```
在这里，我们用其中的两个护栏——重试上限和成本上限——包裹了循环。当工作完成、轮数用完或超出预算时，循环停止。总有一个出口。循环永远不会永远运行。
这就是我们保持循环安全的方式。
注意：人工检查点对于难以撤销的操作最为重要。删除文件、汇款或推送到生产环境都是很好的例子。对于这些，我们必须暂停循环，并让一个人在代理行动前说“是”。
## 完整的代码循环
既然我们已经了解了所有五个部分，让我们把它们放在一个地方，如下所示：
```
# 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"
```
在这里，我们可以看到全貌。五个部分作为一个系统协同工作。我们定义完成，我们构建上下文，代理行动，我们捕获结果，我们反馈它，护栏保持一切安全。
我们只写了一次。现在代理可以自己完成一个多步骤的工作。它完美运行。
## 让我们走查一次运行
学习这一点的最好方法是举个例子。假设目标是“修复登录失败的 bug”。让我们逐轮走查这个循环。
第 1 轮：状态有目标和文件，但还没有错误。我们构建提示并发送它。代理修改了代码。我们捕获结果。测试仍然失败，提示“密码检查对于空密码返回 true”。我们还没完成，所以我们把这个错误保存到状态中。
第 2 轮：现在 build_prompt 包含了来自第 1 轮的新错误。代理读到“密码检查对于空密码返回 true”并修复了那一行。我们捕获结果。测试通过了。
第 3 轮：没有第 3 轮。在第 2 轮 is_done 检查返回了 True，所以循环自动停止了。
在这里，我们可以注意到最重要的事情。在这次运行中，我们没有输入一个提示。第 1 轮的错误自动成为了第 2 轮的提示。循环代替我们提示了代理，并在任务完成的那一刻停止了。
## 运行循环的成本
这里有件事让人们感到惊讶。编写代码很便宜。一次又一次地运行编写它的循环并不便宜。
让我们理解为什么。模型在几秒钟内编写一段代码，成本很低。但是循环一次又一次地运行该模型，一轮接一轮，有时会持续几个小时。每一轮都要花一点钱。一个运行整晚的循环可能会运行数千轮。所以真正的成本不在于一次生成代码。而在于循环到达那里的所有轮次。
这就是为什么第 5 步的停止条件如此重要。一个不停止的循环不仅仅是一个 bug。它是我们在睡觉时不断增长的账单。
所以，我们最重要的工作已经改变了。不再是关于写一个聪明的提示。而是关于确保循环停止。我们必须限制轮数，监控成本，并在工作完成的瞬间停止。
## 可复用的技能
现在，让我们进入从长远来看最重要的部分。循环本身只是接线。真正的价值在于它调用的技能。
这里的技能是什么？技能是一个小的、可复用的工具，能很好地完成一项工作。与其要求模型每一轮都从头开始解决同一件事，不如我们将这些重复的工作变成一个命名工具，循环可以直接调用。
这是我们必须遵循的规则。当我们发现自己一直在做同样的（此处原文中断）