初识 Agent Loop

一句话理解：Agent 的本质不是“会思考”，而是一个不断“看结果 → 想下一步 → 动手 → 检查”的循环，直到任务完成或该停下来。

很多人第一次接触 Agent，会被“思考过程”吸引：模型写出一大段推理，看起来很聪明。但只会思考的系统仍然是 Chatbot。让 Agent 真正能干活的，是一个朴素的循环结构：每做一步，就看一眼结果，再决定下一步。

理解这个循环，你就能看懂几乎所有 Agent 产品的运行日志，也能判断一个“Agent”方案到底是不是真的 Agent。

四个环节

四个环节首尾相连，构成一个循环：

图 1 · Agent Loop：Observe → Reason → Act → Verify，直到完成或该停下

环节	在做什么	输入	输出
Observe 观察	获取当前状态：用户目标、已有信息、上一步的结果	上下文、工具返回	更新后的“我现在知道什么”
Reason 推理	判断离目标还差什么，选下一步动作	当前全部信息	一个决定：调用哪个工具、传什么参数，或直接回答
Act 行动	执行决定：调用工具、写文件、发请求	工具名与参数	工具执行结果
Verify 验证	检查动作是否成功、结果是否可信、任务是否完成	执行结果、完成标准	继续 / 调整 / 完成 / 求助

很多资料把循环描述成“Think → Act”两步，本课程特意把 Verify 单独拎出来，因为它是 Demo 与产品的分界线，详见为什么必须验证。

走一遍真实的循环：销售下滑分析

用户：“上周华东区销售额为什么下降？”

第 1 轮
  Observe：只有问题，没有数据
  Reason ：先确认下降幅度和范围
  Act    ：query_sales(region="华东", compare="上周 vs 前一周")
  Verify ：返回成功，华东下降 18%，数据完整 → 继续

第 2 轮
  Observe：知道下降 18%，但不知道原因
  Reason ：按渠道和品类拆解，找贡献最大的部分
  Act    ：query_sales(region="华东", group_by="category")
  Verify ：饮料品类下降 62%，其他品类基本持平 → 继续

第 3 轮
  Observe：饮料是主因
  Reason ：销量大幅下滑常见原因是缺货或价格变化，先查库存
  Act    ：get_inventory(category="饮料", region="华东")
  Verify ：3 个主力 SKU 连续 5 天库存为 0 → 找到直接原因，但还不知道为什么缺货

第 4 轮
  Observe：缺货
  Reason ：查补货与供应链记录
  Act    ：get_purchase_orders(sku=[...])
  Verify ：供应商交付延期 7 天 → 原因链条完整 → 可以停止

交付：
  结论：华东销售额下降 18%，主要由饮料品类 3 个主力 SKU 缺货导致，根因是供应商延期交付。
  证据：各步查询结果与数据截图
  建议：联系供应商确认到货时间；评估临时调货

注意第 2 轮之后的每一步，都依赖上一步的结果。如果查出来是价格变化而不是缺货，第 3 轮就会去查价格。这就是 Agent 与固定 Workflow 的根本区别：路径不是提前写好的。

把四轮之间的依赖画出来，就能看到路径是边走边定的：

图 2 · 四轮循环的依赖关系：结果不同，下一步就不同

用代码看循环长什么样

下面是一段伪代码，展示几乎所有 Agent 框架的核心结构（不对应任何具体 SDK）：

# 伪代码：Agent Loop 的最小骨架
messages = [system_instructions, user_goal]

for step in range(MAX_STEPS):                 # 停止条件 1：步数上限
    response = model.generate(messages, tools)   # Reason

    if response.is_final_answer:              # 停止条件 2：模型认为完成
        if verify_done(response):             # Verify：程序检查是否真的完成
            return response.answer
        messages.append("检查未通过：" + reason)  # 没通过，继续循环
        continue

    call = response.tool_call                 # Act
    if not permission_allowed(call):          # 护栏：程序决定能不能做
        messages.append("该操作需要人工确认")
        return ask_human(call)

    result = run_tool(call)                   # 执行
    messages.append(summarize_if_too_long(result))  # Observe：结果回到上下文

return escalate("超过步数上限仍未完成")          # 停止条件 3：兜底

这二十行代码里，只有 model.generate 一行是模型在工作，其余全是 Harness：步数上限、完成验证、权限检查、结果处理、兜底升级。这呼应了上一课模型与 Harness 的结论。想亲手实现一个真正可运行的版本，见实操：从零写一个最小 Agent。

循环什么时候该停

循环最危险的状态不是出错，而是 不知道该停：要么过早宣布完成，要么在原地打转烧钱。至少要设计四类停止条件：

停止类型	例子	应对
完成	找到了完整的原因链，且通过验证	交付结果与证据
需要人	下一步是退款、删除等高风险动作	暂停，请求确认
无法继续	缺少权限、数据不存在、工具持续报错	说明卡在哪、建议谁来处理
资源耗尽	达到最大步数、预算或时间上限	汇报已完成部分，停止

还有一种隐蔽情况是 死循环：同一个工具、同样的参数被反复调用。成熟的 Harness 会检测这种模式并强制中断。停止条件的系统设计见停止条件。

常见误区

“推理过程写得越长，Agent 越强。” 推理只是循环的一个环节。没有行动和验证，再长的思考也只是一份“建议”。
“模型说完成了，就是完成了。” 模型的自我报告不可靠。能用程序检查的（测试是否通过、工单是否真的创建），一定要用程序检查。
“步数越多越认真。” 步数多往往意味着工具不好用、上下文缺信息或目标不清晰。好的 Agent 用尽量少的步骤完成任务。

产品经理检查清单

评审一个 Agent 的循环设计时，逐项确认：

每一轮模型能看到什么？工具结果如何回到上下文？
完成的判定标准是什么？由模型判断还是由程序检查？
最大步数、最大花费、最长时间分别是多少？
哪些动作执行前必须暂停等待人确认？
同一操作重复多少次算异常？异常后怎么办？
停下来时，用户能看到什么：已完成部分、卡点、建议？

练习

用 30–45 分钟完成：

选一个 Agent 任务：“排查订单 A1234 为什么客户已付款、订单却仍显示未支付”。
模仿上面“销售下滑分析”的格式，写出你预期的 4–6 轮 Observe / Reason / Act / Verify。
为其中至少两轮写出“如果结果不同，下一步会怎么变”（例如支付接口报错 vs 支付记录正常但订单状态未更新）。
为这个任务写出四类停止条件各一条。

如果你发现某几轮无论结果如何下一步都一样，想一想：这一段是否更适合做成固定 Workflow？

下一步

知道了 Agent 如何运转，下一个问题是：什么时候值得做 Agent？下一课「什么时候值得做 Agent」给出四个判断条件和常见反例。

初识 Agent Loop