Agent Loop：AI Agent的核心循环与工程实践

最近技术圈里不少人在讨论一个词：Loop。热搜词里同时挂着“agent loop”“loop engineer和harness”，也挂着“谷歌浏览器下载”“谷歌账号注册”。如果你只看标题，可能以为谷歌又出了什么新功能或新服务。但实际上，技术圈讨论的 Loop，和浏览器、账号体系没有关系，它是 AI Agent 领域正在快速升温的一个核心概念。

标题里说“谷歌最重要的人，离职去做的 Loop”，这个信息本身有很强的故事性：一位在谷歌担任重要角色的技术人，离职后选择把创业方向押注在“循环”这件事上。这背后的判断其实是——当大模型的能力已经足够强时，真正决定一个 AI 应用上限的，不再是单次对话的智能程度，而是系统如何在一个又一个循环里，把“理解、行动、观察、再理解”串成一条可靠的链路。

作为一个写代码的人，我更关心的不是八卦本身，而是这个事件背后的工程信号：Agent Loop 到底是什么？它为什么能撑起一家公司？Loop Engineer 是一个真实的新岗位，还是又一个概念包装？Harness 在这个体系里又扮演了什么角色？这篇文章围绕这些问题展开，最后会落到可执行的工程实践上，帮助你真正理解 Agent 应用是怎么被“循环”驱动的。

1. 先从标题说起：这个 Loop 到底是什么

很多读者第一眼看到“谷歌最重要的人，离职去做的 Loop”，会默认这是一个谷歌官方项目，或者是某个浏览器插件。但实际上，当前技术语境下的 Loop，指的是Agent Loop，也就是 AI Agent 的执行循环。

要理解这个概念，可以先回到控制论的经典模型：闭环控制。一个恒温器为什么能维持房间温度？因为它不断执行“测量温度—对比目标—决定加热还是制冷—执行—再测量”的循环。这个循环一旦停止，系统就失去了调节能力，变成了一个一次性的输出设备。

Agent Loop 的逻辑完全一样。大模型本身只负责一次推理，而 Agent 应用必须把这次推理放进一个循环里：

• 接收用户的复杂任务。
• 大模型判断当前需要调用什么工具。
• 执行工具调用，拿到结果。
• 把结果反馈给大模型，再次判断。
• 如果任务没完成，重复上面的过程。
• 如果任务完成或达到终止条件，退出循环，返回最终答案。

换句话说，单次大模型调用是“思考”，Agent Loop 是“行动循环”。没有 Loop 的 AI 应用，本质是一个增强版聊天机器人；有 Loop 的 AI 应用，才有资格被称为 Agent。

理解了这个背景，再回看那个标题，就有意思了：一位谷歌核心人物离职创业，把公司或产品的名字定为 Loop，这恰恰说明，AI Agent 的商业价值和工程价值，正在从“模型能力”向“循环控制能力”迁移。

2. Agent Loop 为什么是 Agent 的“心脏”

很多人第一次接触 Agent 框架时，会误以为核心难点是“大模型怎么理解用户的意图”。实际上，大模型理解意图已经是很成熟的能力了。真正难的是：任务被拆解后，每一小步能不能被可靠地执行、验证和纠错。这个可靠性，恰恰由 Loop 决定。

传统开发中，我们写一个自动化脚本，流程是固定的：第一步查数据库，第二步调接口，第三步写结果。如果中间任何一步失败，脚本直接报错，由人来处理。Agent 场景下，任务不再是固定的，而是动态的。大模型在执行过程中，可能会遇到“工具返回数据不对”“需要额外信息”“用户的需求在过程中被澄清”等情况。这时，系统必须有能力回到循环的起点，重新判断、重新规划。

这里最关键的设计点是循环的退出条件。现实中有两类失败非常典型：

• 无限循环：Agent 反复调用同一个工具，拿到的结果始终不满足预期，又没有超时或最大轮次限制，导致 API 费用飙升。
• 过早退出：Agent 只执行了一步工具调用，就自作聪明地认为任务已经完成，返回一个不准确的结果。

这两个问题，本质上都不是“模型智商不够”，而是Loop 的终止策略没有设计好。也就是说，Agent 应用的质量，并不完全取决于背后的模型是哪一款，更大程度上取决于你在循环里给 Agent 设下了哪些边界和判断规则。

所以，Agent Loop 的地位可以这样概括：模型负责生成候选动作，Loop 负责决定这些动作什么时候执行、执行后怎么处理、什么时候停止。没有 Loop，模型只是一台回答机器；有了 Loop，模型才成为能完成任务的执行体。

3. Loop Engineer：一个正在出现的新工程角色

热搜词里出现“loop engineer”，其实不是空穴来风。在 Agent 应用开发团队里，已经在分化出一种新的职责，专门负责设计、优化和维护 Agent 的执行循环。

这个角色和传统后端工程师有明显区别。传统后端工程师处理的是确定的业务流程：请求进来，校验参数，调用服务，返回结果，每一步都是确定的。Loop Engineer 处理的是不确定的流程：大模型每一步可能生成不同的动作，同一个问题在不同上下文里会走向完全不同的分支。所以，Loop Engineer 的核心工作不是写业务逻辑，而是：

• 定义循环的每一步状态，沉淀状态机。
• 设计工具的调用规范，让大模型更容易决定调用哪个工具。
• 设置循环终止条件，在“完成”和“最大轮次”之间找平衡。
• 建立错误恢复机制，比如工具调用失败后是重试、换个工具，还是直接询问用户。
• 做成本控制，监控每一轮循环消耗的 token，防止单个任务烧掉太多预算。
• 构建评测集，验证不同任务下循环的平均轮次和成功率。

你会发现，Loop Engineer 的工作内容，已经从传统意义上“写代码让程序跑起来”，变成了“设计一套规则，让模型在规则内自主跑完任务”。这更接近系统架构师和 SRE（站点可靠性工程师）的交叉地带。

从行业信号看，这个角色出现本身就说明：Agent 开发正在从“写 Prompt，看模型心情输出”走向“搭系统，用工程手段保证输出质量和成本可预期”。如果你正在用各类 Agent 框架做项目，即使不挂这个头衔，你实际做的事情也已经是 Loop Engineering 了。

4. Harness 是什么：给 Loop 戴上行为约束

Loop Engineer 负责设计规则，那规则由谁来强制执行？这就引出了另一个高频词：Harness。

Harness 在 AI Agent 里的含义，可以理解为“行为控制框架”或“循环的约束层”。它像汽车的安全带，也像自动化测试中的测试夹具，约束着 Agent 在每一步循环里“能做什么、不能做什么、按什么顺序做”。

举个例子。假设你的 Agent 需要操作一个数据库。如果没有 Harness，大模型可能为了完成用户任务，生成一句破坏性的 DELETE SQL。如果有 Harness，循环的每一步都必须经过它校验：工具白名单里没有“危险数据库操作”，或者对 SQL 做只读检查，一旦发现高危操作，直接拦截并转为人工审批。

Harness 在工程上通常承担这四类职责：

• 工具权限控制：可调用哪些工具，不可调用哪些工具。
• 参数校验：大模型生成的工具调用参数是否符合约束。
• 循环步骤审计：把每一次思考、动作、观察结果都记录下来。
• 终止条件强制执行：即使大模型还想继续循环，Harness 也可以按预设条件强制终止。

在实际项目里，Harness 的引入让 Agent 从“一个能写代码的模型”变成“一个受管制的执行系统”。很多安全问题，比如工具被滥用、参数越权、模型被注入恶意指令，都可以在 Harness 层拦截。

这里有一个很容易踩的坑：很多人以为 Harness 是某个框架独有的“高级功能”，于是先花大量时间研究框架，再研究 Harness。其实 Harness 的思想极其朴素，就是一个中间层：在大模型和外部工具之间，加一层代理，所有动作都过这一层。你完全可以自己用几十行代码实现一个最小可用的 Harness。

5. 从零实现一个最小 Agent Loop

理解了概念，下面用一个最小示例来跑通 Agent Loop 的核心流程。这个示例不依赖特定 Agent 框架，只展示循环最本质的结构：观察—推理—行动—观察结果，帮助你把记忆中的概念落成代码。

下面是一个使用 Python 写的最小示例，文件路径为agent_loop_demo.py：

# 文件路径：agent_loop_demo.py """ 最小 Agent Loop 演示： 1. 用大模型决定调什么工具 2. 执行工具调用 3. 把结果拼回上下文 4. 判断是否结束 """ import json from typing import Callable, Dict class MinimalAgentLoop: def __init__(self, llm_call: Callable, tools: Dict[str, Callable], max_iterations: int = 5): self.llm_call = llm_call self.tools = tools self.max_iterations = max_iterations self.history = [] def _build_tool_descriptions(self) -> str: """把工具注册信息转成模型可读的文本描述。""" lines = [] for name in self.tools: lines.append(f"- {name}: 可用的工具函数") return "\n".join(lines) def run(self, user_task: str) -> str: """执行一次完整的 Agent 循环。""" self.history.append({"role": "user", "content": user_task}) tool_desc = self._build_tool_descriptions() for step in range(1, self.max_iterations + 1): print(f"[Step {step}] 模型推理中...") response = self.llm_call( tool_desc=tool_desc, history=self.history ) if response.get("action") == "finish": print("[Loop] 任务完成，退出循环") return response.get("answer", "") tool_name = response.get("tool") tool_args = response.get("args", {}) if tool_name not in self.tools: print(f"[Loop] 未知工具: {tool_name}，本轮跳过") self.history.append({ "role": "system", "content": f"工具 {tool_name} 不存在，请重新选择可用工具" }) continue print(f"[Step {step}] 调用工具: {tool_name}, 参数: {tool_args}") try: tool_result = self.tools[tool_name](**tool_args) except Exception as e: tool_result = f"工具执行出错: {str(e)}" self.history.append({ "role": "system", "content": f"工具 {tool_name} 返回结果: {json.dumps(tool_result, ensure_ascii=False)}" }) print("[Loop] 达到最大迭代次数，强制退出") return "任务未在限定步骤内完成，请简化任务或检查工具调用逻辑"

这个示例里，llm_call是一个回调函数，用来模拟大模型根据历史上下文生成动作；tools是一个字典，key 是工具名，value 是工具函数。循环的核心逻辑在run方法里：

• 先让模型推理当前状态。
• 如果模型决定结束，就返回最终答案。
• 如果模型决定调用工具，执行工具并把结果追加到历史里。
• 如果模型生成了不存在的工具，就喂给模型一个纠错信号。
• 达到最大迭代次数后，强制退出，返回指定提示。

你可以用一个模拟的llm_call来验证这个循环：

# 文件路径：run_demo.py import random from agent_loop_demo import MinimalAgentLoop def mock_llm(tool_desc, history): """模拟大模型：前 2 轮调用工具，第 3 轮返回结束。""" step = random.randint(0, 2) if step == 0: return {"action": "call_tool", "tool": "add", "args": {"a": 1, "b": 2}} elif step == 1: return {"action": "call_tool", "tool": "multiply", "args": {"a": 3, "b": 4}} else: return {"action": "finish", "answer": "任务已完成"} def add(a: int, b: int) -> int: return a + b def multiply(a: int, b: int) -> int: return a * b if __name__ == "__main__": loop = MinimalAgentLoop( llm_call=mock_llm, tools={ "add": add, "multiply": multiply }, max_iterations=5 ) result = loop.run("计算 1+2 和 3*4") print("最终结果:", result)

运行命令如下：

python run_demo.py

预期输出会类似下面的结构：

[Step 1] 模型推理中... [Step 1] 调用工具: add, 参数: {'a': 1, 'b': 2} [Step 2] 模型推理中... [Step 2] 调用工具: multiply, 参数: {'a': 3, 'b': 4} [Step 3] 模型推理中... [Loop] 任务完成，退出循环 最终结果: 任务已完成

这个最小示例虽然简单，但它已经具备了一个 Agent Loop 的完整骨架：推理、行动、观察、终止。你可以把mock_llm替换成真实的大模型 API，把add、multiply替换成真实的搜索、数据库查询、HTTP 请求等工具，这就变成了一个可用的 Agent 雏形。

有一个细节值得强调：示例中“工具不存在”的处理方式，是把这个错误信息作为系统消息放回历史，让模型重新决策。这一步在真实项目中非常重要，因为它给循环提供了自我纠错能力，而不是遇到错误就崩溃。

6. 让 Loop 可控：可观测性与安全护栏

上面的最小示例能跑通，但距离生产环境还很远。真实 Agent 应用必须回答三个问题：循环为什么这么走？循环花了多少钱？循环有没有越权动作？这三个问题都指向同一个工程方向：可观测性和安全护栏。

可观测性首先体现在日志上。一个生产级的 Agent Loop，不能只打印 “Step 1” 这样的提示，而应该记录每一次完整动作的上下文：用户意图、模型思考、工具名、工具参数、工具返回结果、耗时、token 消耗、循环轮次。下面是一个增强日志版本的核心片段：

# 文件路径：agent_loop_with_logging.py import json import time from dataclasses import dataclass, field from typing import Callable, Dict, List @dataclass class LoopRecord: step: int action: str tool: str args: dict result: str duration_ms: int token_usage: int class LoggedAgentLoop: def __init__(self, llm_call: Callable, tools: Dict[str, Callable], max_iterations: int = 5): self.llm_call = llm_call self.tools = tools self.max_iterations = max_iterations self.records: List[LoopRecord] = [] def _verify_tool_call(self, tool_name: str, args: dict) -> bool: """Harness 层白名单校验：只允许注册过的工具，且参数必须为 dict。""" if tool_name not in self.tools: return False if not isinstance(args, dict): return False return True def run(self, user_task: str) -> str: history = [{"role": "user", "content": user_task}] for step in range(1, self.max_iterations + 1): start = time.time() response = self.llm_call(history=history) duration_ms = int((time.time() - start) * 1000) if response.get("action") == "finish": answer = response.get("answer", "") self.records.append( LoopRecord(step, "finish", "", {}, answer, duration_ms, 0) ) return answer tool_name = response.get("tool", "") tool_args = response.get("args", {}) if not self._verify_tool_call(tool_name, tool_args): warning = "工具调用未通过安全校验，请检查工具名与参数格式" history.append({"role": "system", "content": warning}) self.records.append( LoopRecord(step, "blocked", tool_name, tool_args, warning, duration_ms, 0) ) continue try: result = self.tools[tool_name](**tool_args) except Exception as e: result = f"工具执行异常: {e}" history.append({ "role": "system", "content": f"{tool_name} 返回: {json.dumps(result, ensure_ascii=False)}" }) self.records.append( LoopRecord(step, "call_tool", tool_name, tool_args, json.dumps(result, ensure_ascii=False), duration_ms, 0) ) return "达到最大循环次数，停止执行"

这个版本的核心变化是加入了_verify_tool_call方法，它就是在模拟 Harness 的行为：在工具调用进入真实执行前，先做一次白名单和参数校验。即使大模型被恶意提示词引导去调用一个未注册工具，这个校验也能把它拦下来。

在生产环境里，你还需要考虑人工审批机制。对于高危工具（比如删除资源、发送邮件、执行支付），比较稳妥的做法是：当 Agent 希望调用这些工具时，循环进入“等待人工确认”状态，挂起当前轮次，等运营或用户批准后再继续执行。这个机制可以用一个简单的状态字段实现：

PENDING_APPROVAL = "pending_approval" APPROVED = "approved" REJECTED = "rejected"

每次循环开始前，如果检测到某个工具需要审批，就先不调用大模型，而是把控制权交给人。这意味着你的 Loop 不只是“模型—工具”之间的循环，而是“模型—人—工具”三方协作的循环。引入人在回路（Human-in-the-Loop）虽然会增加延迟，但能显著降低高危操作的风险。

7. Agent Loop 常见问题与排查方法

在实践 Agent Loop 时，下面这些问题是出现频率最高的，整理成表格供保存参考：

这里面最值得注意的一个问题是“上下文越来越长”。Agent Loop 的设计天然会让历史消息不断增长，因为每一次工具返回值都存放在上下文里。当循环轮次达到一定数量，模型会逐渐“遗忘”最早的信息，甚至开始忽略一些工具返回结果。常见做法是对工具返回内容做裁剪：比如只把关键字段写入上下文，详细结果放在外部文件或数据库里，需要时再检索。这也是为什么很多 Agent 框架会强调“记忆管理”，它和 Loop 是配套的。

8. Agent Loop 的工程化建议

结合前面讲的原理和实践，下面整理几条 Agent Loop 落地的工程建议。这些建议不针对特定框架，适用于你在任何项目里设计 Agent 应用。

第一，把“单次调用”思维改成“循环 + 状态机”思维。很多 Agent 项目失败，不是模型选得不好，而是开发者依然按照传统接口的方式设计：用户请求进入，一次模型调用返回结果。这个模式处理简单问答没问题，但处理多步任务一定会出问题。你需要显式定义状态：初始状态、工具调用中、等待人工确认、已终止。循环的每一步，都应该知道当前状态是什么。

第二，工具全量白名单化，并在 Harness 层校验。不要信任大模型生成的工具名和参数，所有外部调用必须经过一层校验。白名单工具是底线，参数校验是常态。高危操作一律走人工审批。这不仅是安全要求，也是成本控制手段——拦截非法调用，能避免很多无效 token 消耗。

第三，给循环加预算。预算分两层：时间预算和 token 预算。时间预算指单个 Agent 任务最多允许跑多少秒；token 预算指单个任务最多允许消耗多少 token。在循环的每一步，检查预算是否超限，超限则强制优雅退出。这个做法能避免“Agent 跑飞了”带来的经济损失。

第四，用审计日志替代事后猜测。生产环境的 Agent 循环，每一步都必须留下结构化日志：时间戳、模型请求、模型响应、工具名、工具参数、工具结果、耗时、状态。这样一旦线上出现奇怪结果，你能快速回放整个循环，知道是模型判断错了，还是工具执行错了，还是终止条件没有生效。没有审计日志的 Agent 系统，等于盲人摸象。

第五，千万不能用“超长 Prompt”代替循环。有一种常见误区：为了不让 Agent 分多步执行，把所有可能的步骤和判断规则都塞进一个 Prompt，希望模型一次输出完整结果。这样做在小任务上也许可行，但任务稍微复杂一点，模型输出质量会急剧下降，而且单次 API 的成本会飙升。更合理的做法是：让模型每次只决策一步，然后用循环织起整个执行过程。这正是 Agent Loop 的价值所在。

第六，评测不能只测“答案对不对”，还要测“循环省不省”。给 Agent 系统建立评测集时，除了关注最终结果质量，还要统计平均循环轮次、平均工具调用数、工具调用失败率、非正常退出率。这些指标决定了系统在生产环境里的成本和稳定性。如果一个任务原本只需 2 轮循环就能完成，但实际平均跑了 8 轮，说明你的提示词或工具描述还有很大的优化空间。

9. 总结：Loop 不只是热词，它是 Agent 工程的底层框架

扯回标题：谷歌那位重要人物离职去做的 Loop 到底有多重要？从技术演进的视角看，真正重要的不是某一款叫 Loop 的产品，而是“循环执行”这件事在整个 AI 应用体系里的地位正在被重新定义。

过去二十年，我们写程序的方式是“顺序执行”：一行代码执行完，再执行下一行。遇到分支，用 if/else 判断。遇到循环，用 for/while 控制。LLM 出现之后，很多应用的开发方式变成“单次生成”：写一个 Prompt，拿一次输出。Agent Loop 把这两种模式融合到了一起：用传统工程的方式控制循环，用大模型的方式生成每一步的动作。这可能是 AI 应用走向工程化的一个关键转折点。

如果你想真正理解 “Agent Loop”“Loop Engineer”“Harness” 这些词的份量，建议亲手写下第一节里的最小循环，跑通一次“推理—调用工具—观察结果—再推理”的过程，然后再去思考：如果这个循环要支撑真实业务，需要加多少控制逻辑。你会发现，从“模型能回答”到“Agent 能可靠完成任务”，中间隔着的就是 Loop 里那些看似不起眼的工程细节。

这些细节，才是 Agent 应用真正值钱的地方。