🧑💻 面试官：一个 Agent 收到任务以后，是怎么一步步执行的？
🙋♂️ 我：Agent 会先理解用户的目标，然后制定计划，再调用工具完成每一个步骤，最后把结果返回给用户。
🧑💻 面试官：模型会自己连接监控系统、查询日志吗？还是它只负责告诉程序要调用什么工具？
🙋♂️ 我：模型应该只负责选择工具和生成参数，真正的工具调用还是由后端程序完成。
🧑💻 面试官：那工具返回的结果放到哪里？模型怎么知道前面做过什么，又为什么会改变原来的计划？
🙋♂️ 我：工具结果会重新放进上下文，模型看到新的结果以后，再决定下一步怎么做。
🧑💻 面试官：如果工具一直超时，模型不停重试怎么办？如果服务中途重启，前面的执行状态还能不能恢复？模型说任务完成了，系统就直接相信它吗？
这道题抓住一个核心就好：「Agent Loop」——模型每完成一步，都会拿到新的状态，再决定下一步。而代码负责的是如何把这套循环安全地运行下去。
面试速答（60 秒版）
Agent 的核心工作方式，可以理解成一个不断重复的执行循环，也就是 Agent Loop。
任务开始以后，模型会读取用户目标和当前的任务状态，然后决定下一步做什么。如果它需要调用工具，那么模型会先生成一份结构化的工具调用请求，真正的工具调用则由后端执行器来完成。
工具执行完以后，返回结果会重新写回任务状态。模型看到新的结果，再判断是继续调用其他工具、调整处理方式，还是直接结束任务。这个过程会一直重复，直到任务完成或者触发停止条件。
在实际项目中，我们还需要为每次任务保存 run_id、当前状态、执行步骤和工具结果。同时限制最大执行步数、超时时间和 Token 预算。涉及删除数据、重启服务这类高风险操作时，还要等待人工确认。
所以，Agent 会循环调用工具还不够。我们还得知道它每一步做了什么，能够随时停下来，任务中断以后也能继续执行。
知识点详解：Agent Loop 到底是怎么运行的？
Agent 不是一次模型调用，而是一个执行循环
要理解 Agent 的工作原理，我们需要先把一件事说清楚：一次普通的大模型调用，通常只有一次输入和一次输出。
例如，我们向模型提出一个问题，模型根据当前上下文生成回答，这次调用也就结束了。
但是 Agent 面对的任务往往不是一次回答就能完成的。它可能需要先查询监控，再分析日志，然后根据查到的结果决定下一步做什么。
所以，Agent 系统还需要一段负责控制任务的程序，我们可以把它叫作 运行器。
运行器会不断重复下面这个过程：
此时，如果模型认为还需要更多信息，就继续调用工具。
反之，如果模型认为信息已经足够，就直接生成最终结果，结束这次任务。
这个不断 “判断、执行、拿到新结果、再次判断” 的过程，就是 Agent Loop。
用一次接口排查任务，完整跑一遍 Agent Loop
现在，咱们假设用户交给 Agent 一个任务：排查订单接口最近半个小时突然变慢的原因，并给出处理建议。
Agent 并不知道完成这个任务一共需要几步。它只能根据每一轮拿到的信息，决定接下来怎么做。
所以，整个的流程可能会涉及到很多轮，比如下面这样子：
| 轮次 | 模型当前知道什么 | 模型决定做什么 | 工具返回什么 |
|---|---|---|---|
| 第 1 轮 | 订单接口最近半小时变慢 | 查询接口监控指标 | 数据库查询耗时明显升高 |
| 第 2 轮 | 数据库可能存在性能问题 | 搜索最近的慢查询日志 | 发现一条频繁出现的慢 SQL |
| 第 3 轮 | 已经找到可疑的慢 SQL | 查询最近的发布记录 | 相关 SQL 在最近一次发布中被修改过 |
| 第 4 轮 | 监控、日志和发布记录已经能够互相对应 | 不再调用工具，整理原因和处理建议 | 任务结束 |
从这个过程里我们可以看到，Agent 并不是先把四个步骤全部确定好，再机械地执行下去的。
在每一轮执行时，他都会更具上一轮执行的结果，来动态的判断下一轮执行的逻辑。
这就是 Agent Loop 的执行特点：它会在 “判断 → 执行 → 获取结果 → 再次判断” 的循环中不断推进任务，直到任务完成或者触发停止条件。
一次 Agent Loop 背后有哪些模块
上面的执行过程看起来像是模型自己完成的，但是实际上至少需要四个部分配合。
- 大模型负责做判断。 它读取用户目标和当前信息，然后决定下一步是调用工具，还是直接输出最终结果。
- 运行器负责控制循环。 它负责调用模型、识别模型返回的是最终答案还是工具请求，并决定什么时候进入下一轮。
- 工具执行器负责调用具体的工具。 按照上面的例子，当模型决定查询监控指标时，它会返回
query_metrics和对应的查询参数。工具执行器收到这些信息以后，才会真正访问监控系统，并把查询结果交给运行器。 - 任务状态负责保存 Agent 已经知道和做过的事情。 它会记录用户目标、已经调用过的工具以及工具返回的结果。进入下一轮时，运行器会读取这些信息并交给模型，让模型能够接着上一轮的结果继续判断。
这里还有三个很容易混淆的概念：
- **任务状态 **：是系统保存的完整任务数据，例如当前步骤、工具结果、错误信息和剩余预算。
- 上下文：是运行器在这一轮真正发送给模型的信息，它通常来自任务状态，但不一定包含全部历史数据。
- Observation 是工具刚刚返回的新结果，例如“数据库查询耗时升高”。它会先写入任务状态，再成为模型下一轮判断的一部分。
所以，大模型负责选择下一步，运行器负责让这一步真正发生，再把执行结果带回下一轮。少了运行器、工具和任务状态，单独一个大模型并不能完成这套循环。
Agent 怎样知道应该继续还是结束
在最简单的情况下，模型每一轮只有两种选择：继续调用工具，或者 返回最终结果。
对于前面的接口排查任务，当模型认为监控、日志和发布记录已经能够说明问题时，就可以停止调用工具，生成排查结论。这是一次正常结束。
但是系统不能只等模型主动结束。模型可能反复查询同一个工具，也可能一直找不到足够的信息。因此，运行器还要设置最大执行步数、最长执行时间和 Token 预算。只要超过其中任何一个限制，即使模型还想继续，系统也应该停止这次任务。
另外，模型输出最终结果，也不一定代表业务任务真的成功了。如果 Agent 执行的是“重启服务”或者“提交退款”这类操作，系统还需要再次查询外部状态，确认服务已经恢复，或者退款确实已经提交成功。
换句话说，模型可以决定“不再继续调用工具”，但是任务是否成功，仍然需要代码和真实的执行结果来确认。
从能够运行到能够上线，还缺哪些东西
上面的循环已经可以让 Agent 跑起来，但是要放进真实项目里，还是差一点东西的。
- 首先，任务状态不能只放在当前进程的内存里。后端需要为每次任务生成一个
run_id，并保存当前步骤、工具调用和返回结果。这样即使 Worker 重启，也知道任务之前执行到了哪里。 - 其次，工具失败以后不能无限重试。网络超时这类临时错误，可以由执行器按照固定次数重试。如果是参数错误或者权限不足，就应该把明确的错误写回任务状态。涉及退款、发消息这类写操作时，还需要增加幂等控制，避免同一个动作被重复执行。
- 如果工具会删除数据、重启服务或者执行其他高风险操作，运行器不能收到模型请求以后就直接执行。它可以先把任务改成等待审批状态，只有人工确认以后才继续。
- 最后，每一轮模型判断、工具调用和状态变化都应该被记录下来。否则任务失败以后，我们只能看到最后一句回答，却不知道 Agent 是在哪一步选错了工具，也不知道错误为什么没有被后面的步骤纠正回来。
面试官继续追问
Agent 每次都要先生成一份完整计划吗？
不一定。
有些任务的步骤比较清楚，可以先生成计划，再按照计划执行。例如先收集监控指标，再查看日志，最后整理结论。
但是计划不应该把后面的步骤完全锁死。Agent 每拿到一个新的工具结果，都可以调整接下来的处理方式。对于路径很难提前确定的任务，也可以一次只决定下一步，执行完以后再继续判断。
实际项目中还可以把两种方式放在一起。先生成一个粗略计划，让任务有大概方向；执行过程中再根据新结果调整具体步骤。
工具调用失败以后，应该让模型自己重试吗？
要看失败的原因。
网络超时、服务临时不可用这类技术错误，更适合由执行器按照固定次数重试，并且加入退避时间。这样不会浪费一次模型调用，也更容易控制重试次数。
如果工具返回的是“没有查到数据”，或者模型传入的查询条件不合适，那么可以把结果交回模型，让它决定是否更换工具或者调整参数。
涉及写入数据的工具还要考虑重复执行。比如 Agent 提交了一次退款请求，接口超时以后不能直接再提交一次。系统需要使用幂等键，让同一个请求即使重复发送，也只会执行一次。
怎么判断这套 Agent Loop 是否真的可用？
判断 Agent Loop 设计得好不好，首先要看它能不能完成任务。
我们可以提前准备一批能够核对结果的测试任务，然后让 Agent 反复执行。如果 Agent 经常找不到正确结果，或者总是在中途停止，那么说明这套循环本身还不稳定。
但是，只看最终结果还不够。
比如 Agent 最后确实找到了导致接口变慢的 SQL，但是中间重复查询了十几次相同的监控数据，执行时间很长，还消耗了大量 Token。虽然结果是对的，但整个过程并不合理。
因此，我们还需要记录 Agent 每一轮做出的判断、调用的工具以及工具返回的结果。这些完整的执行记录叫作 Trace。有了 Trace，任务失败以后，我们才能知道 Agent 是在哪一步选错了工具，或者为什么一直重复相同的操作。
最后还要检查 Agent 有没有做出危险操作。例如，在没有人工确认的情况下重启服务、修改数据或者绕过工具权限。这类问题不能因为其他任务完成得不错就被忽略。只要 Agent 还可能越过安全边界，这套方案就不适合直接上线。
面试速记卡
- 核心循环：模型读取状态、选择动作、拿到结果，再根据新的状态继续判断。
- 模型职责：决定下一步做什么，并生成结构化的工具调用请求。
- 执行器职责：校验参数和权限，真正调用工具，并处理超时与重试。
- 状态记录：保存 run_id、执行步骤、工具结果、错误和 Token 用量。
- 停止条件：任务完成、最大步数、超时、预算耗尽、人工终止或执行失败。
