Agent Loop 5 大模式:Agent 怎么 step-by-step 跑
写在 Harness 系列第三篇。前两篇:9-16 Harness 工程(抽象层)、9-17 AI Coding 工程(系统层)。
今天讲"算法层":Agent Loop 怎么 step-by-step 跑。
关键字:4 阶段循环 / 5 大核心组件 / 5 大主流 AgentLoop / 4 大痛点 + 双重保险 / 5 大选择原则。
📌 一句话核心
"Agent Loop = 人类认知的工程化实现。选 loop 模式 = 选权衡,不是选最优。"
📌 为什么写这篇
昨天(9-17)讲了 AI Coding 工程的 4 大组件 / 3 级成熟度 / 多 Agent / Hook,但少了一个维度——Agent Loop 本身。
Agent 跑起来,要怎么"想 → 做 → 检查 → 再想"地循环?5 大模式各有什么优劣?怎么选?
今天补这一块。
💎 观点 1:Agent Loop 的 4 阶段循环
[感知] → [思考] → [行动] → [反馈]
↑ │
└──────────────────────────┘
(反馈作为下一轮感知)1.1 4 阶段详解
| 阶段 | 输入 | 输出 | 实现 |
|---|---|---|---|
| 感知 | 用户指令 / 环境状态 | 当前上下文 | 读取消息 / RAG 检索 / Tool 结果 |
| 思考 | 感知结果 | 决策(下一步 / 结束) | LLM 推理 |
| 行动 | 思考结果 | 调用结果 | 外部 API / Tool / 数据库 |
| 反馈 | 行动结果 | 新感知信息 | 结果解析 / 异常处理 / 日志 |
1.2 与人类思维类比
| Agent Loop | 人类思维 | 例子 |
|---|---|---|
| 感知 | "老板让我写个 PPT" | 听指令 |
| 思考 | "先列大纲,再写每页" | 思考策略 |
| 行动 | "打开 PowerPoint 开始写" | 动手做 |
| 反馈 | "第一页写完了,继续下一页" | 自我检查 |
| 再次感知 | "第一页内容不够好,要改" | 重新评估 |
关键洞察:Agent Loop = 人类认知的工程化实现。一次循环 = 一次完整思考。
1.3 Agent Loop 是 Agent 的运行引擎
Agent = Harness + Model
AgentLoop = Agent 的"心脏"(运行机制)- 没有 AgentLoop → Model 只是个问答机器
- 没有 Harness → AgentLoop 跑起来也没用(失控)
- AgentLoop 是"Model 跟外部世界怎么对话"
💎 观点 2:Agent Loop 的 5 大核心组件
2.1 5 组件总览
┌─────────────────────────────────────────┐
│ Agent Loop 核心 │
│ ┌──────────┐ ┌──────────┐ │
│ │ ① 状态管理 │ ←→│ ② 决策引擎 │ ← (核心) │
│ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ │
│ │ ③ 工具执行 │ ←→│ ④ 记忆模块 │ │
│ └──────────┘ └──────────┘ │
│ ↓ │
│ ┌──────────┐ │
│ │ ⑤ 终止校验 │ │
│ └──────────┘ │
└─────────────────────────────────────────┘2.2 5 组件详解
| # | 组件 | 作用 | 关键挑战 | 失败会怎样 |
|---|---|---|---|---|
| ① | 状态管理器 | 维护对话 / 任务 / 流程状态 | 状态一致性 / 序列化 | 状态错乱 |
| ② | 决策引擎(核心) | 决定下一步动作 | 上下文完整 / 推理正确 | 跑偏 / 卡死 |
| ③ | 工具执行器 | 调用外部 API / 数据库 / 文件 | 参数正确 / 异常处理 | Tool 调用失败 |
| ④ | 记忆模块 | 短期 + 长期记忆 | 短期压缩 / 长异步持久 | 失忆 / 重复问 |
| ⑤ | 终止校验器 | 判断"该结束了" | 成功条件 / 最大轮次 | 无限循环 |
2.3 核心原理
"AgentLoop 的本质 = 上下文驱动的状态延续。"
含义:
- Agent 没有"自身状态",只有"context + tool"
- 每一轮的状态 = 之前的 context + tool 调用历史
- "延续"靠 context 拼接(ReAct)或显式状态存储(Plan/反思)
💎 观点 3:5 大主流 AgentLoop
3.1 总览表
| # | 模式 | 复杂度 | 轮次 | 核心思想 | 适用场景 |
|---|---|---|---|---|---|
| 1 | 基础工具调用 | ⭐ | 1-3 | LLM 直接调函数 | 简单查询 / 操作 |
| 2 | ReAct | ⭐⭐ | 中 | 迭代规划调整 | 动态任务 / 通用 |
| 3 | Plan-and-Execute | ⭐⭐⭐ | 长 | 全局规划 | 长程复杂 / 流程明确 |
| 4 | 反思迭代 | ⭐⭐⭐ | 长 | 执行 → 反思 → 修正 | 高容错 / 代码审查 |
| 5 | 多智能体协作 | ⭐⭐⭐⭐⭐ | 长 | 跨领域涌现 | 跨领域极高复杂度 |
3.2 模式 1:基础工具调用(1-3 轮)
最简单的模式:LLM 直接调函数。
User: "查一下今天天气"
LLM: 调 weather_api
LLM: 回复 "今天 25 度,晴"适用:简单查询 / 操作 / ChatGPT Function Calling / 大部分场景。
3.3 模式 2:ReAct(迭代规划调整)
ReAct = Reasoning + Acting(思考 + 行动交替)
[思考] 思考下一步
↓
[行动] 调用工具
↓
[观察] 拿到结果
↓
回到 [思考]核心机制:上下文拼接实现记忆延续——所有历史堆到 context 里。
# ReAct 伪代码
context = []
while not done:
thought = llm.think(context)
context.append({"role": "assistant", "content": thought})
tool, args = llm.decide_action(thought)
result = execute_tool(tool, args)
observation = f"Tool {tool} returned: {result}"
context.append({"role": "user", "content": observation})
done = llm.is_done(thought)优缺点:
| 优点 | 缺点 |
|---|---|
| 动态性好——每步根据最新结果调整 | 长任务目标容易漂移 |
| 通用性好——适用各种任务 | 缺全局视野(只看眼前) |
| 实现简单——上下文堆就行 | Token 消耗增加较快 |
类比:下棋——想一步走一步。
3.4 模式 3:Plan-and-Execute(全局规划)
先计划,再执行——默认人的思维模式。
[Plan] 规划整体任务
↓
[Execute] 逐步执行(每步可以是 ReAct)
↓
[Re-Plan] 必要时调整计划
↓
[Execute] 继续执行核心思想:任务拆解 = 任务降维。
优缺点:
| 优点 | 缺点 |
|---|---|
| 稳定性强——有全局计划,不会跑偏 | 计划错了后面全错 |
| 适合长任务——任务明确时好分解 | 初期规划成本高 |
| 目标清晰——用户能看清楚整个计划 | 不灵活 |
类比:写代码——先设计再写。
3.5 ReAct vs Plan-and-Execute 核心区分
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 本质 | 迭代规划调整 | 全局规划 |
| 稳定 | ⭐⭐ | ⭐⭐⭐⭐ |
| 灵活 | ⭐⭐⭐⭐ | ⭐⭐ |
| 类比 | 下棋 | 写代码 |
最佳实践:ReAct + Plan 混合 = 防漂移的标准组合——先用 Plan 定目标,再用 ReAct 做执行。
3.6 模式 4:反思迭代(执行 → 反思 → 修正)
[执行] 完成一个动作
↓
[反思] 检查结果
↓
[修正] 如果不行,重做
↓
回到 [执行]三层反思(关键结构):
| 层次 | 反思什么 | 谁来做 |
|---|---|---|
| 结果校验层 | 这次执行的结果对吗? | 自动(代码 / 测试) |
| 过程复盘层 | 这次的执行过程合理吗? | LLM |
| 策略优化层 | 整体策略要调整吗? | LLM + 人类(关键决策) |
优缺点:
| 优点 | 缺点 |
|---|---|
| 幻觉少(多层校验) | Token 消耗量很大 |
| 鲁棒性强(自我纠错) | 响应慢(多轮反思) |
| 质量稳定 | 可能反思错误(LLM 也可能错) |
适用场景:代码审查、法律文书、医疗诊断、金融决策。
类比:写论文——写完反复改。
3.7 模式 5:多智能体协作(慎用)
| 子模式 | 结构 | 协调方式 | 适用场景 |
|---|---|---|---|
| 主从模式 | Orchestrator + SubAgent | Orchestrator 调度 | 任务明确、需要问责 |
| 对等协商 | 平级 Agent | 投票 / 协商 / 互相 review | 探索性、需要涌现 |
| 维度 | 评价 |
|---|---|
| 优点 | 跨领域 + 高复杂度 / 涌现 / 鲁棒 |
| 缺点 | 稳定性较低 / Token 消耗极高 / 速度很慢 |
适用场景:开发全流程、头脑风暴、跨领域极高复杂度任务。
"多智能体协作是 5 大循环中成本最高的——慎用。"
3.8 5 大循环对比
| 维度 | 基础工具调用 | ReAct | Plan-and-Execute | 反思迭代 | 多智能体协作 |
|---|---|---|---|---|---|
| 响应速度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ | ⭐ | ⭐ |
| 稳定性 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| Token 消耗 | 低 | 中 | 低 | 极高 | 极高 |
| 容错能力 | ⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 可解释性 | ⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| 适用复杂度 | 单步 | 中 | 高 | 高 | 极高 |
💎 观点 4:Agent Loop 的 4 大痛点 + 双重保险
4.1 双重终止保险(鲁棒性核心)
| 维度 | 任务完成 | 异常状态 |
|---|---|---|
| 触发条件 | LLM 判断"做完了" | 超时 / 错误 / 异常 |
| 动作 | 优雅退出 | 强制停止 + 错误返回 |
| 关键作用 | 正常完成 | 防止无限循环 / 资源耗尽 |
关键洞察:"双重保险"是 AgentLoop 鲁棒性的核心——没有它,Agent 跑飞了都不知道。
4.2 4 大痛点 + 防御
痛点 1:无限循环
| 措施 | 作用 | 配置 |
|---|---|---|
| 最大迭代次数 | 硬性终止 | max_iters = 10-20 |
| 超时时间 | 时间维度硬性终止 | timeout = 60s |
| 进度检测 | 没进展就停 | "同一状态重复 N 次" |
| 异常终止 | 出错就停 | Tool 失败率 > 50% |
"无限循环 = AgentLoop 的'心脏病';双重保险是'心脏起搏器'。"
痛点 2:目标漂移
| 措施 | 作用 |
|---|---|
| Plan-and-Execute | 提前固化目标 |
| 定期 Re-Plan | 每 N 轮回顾"我现在还在主线吗?" |
| 用户 Confirm | 关键节点用户确认 |
"目标漂移 = AgentLoop 的'阿尔茨海默';规划是'指南针'。"
痛点 3:上下文溢出
| 措施 | 作用 |
|---|---|
| 关键信息压缩 | LLM 做摘要 |
| 下沉长期记忆 | 老的对话存到 PG / Mem0 |
| 滑动窗口 | 只保留最近 N 轮 |
| 结构化状态 | 不存对话,存结构化数据 |
"上下文溢出 = AgentLoop 的'记忆饱和';压缩 + 下沉是'大脑'。"
痛点 4:性能瓶颈
| 优化 | 作用 | 收益 |
|---|---|---|
| Prompt 缓存 | 同样 prompt 不重复算 | 50%+ 加速 |
| Tool 调用缓存 | 同样 tool 不重复调 | 30%+ 加速 |
| 并行执行 | 不依赖的 tool 并发调 | 2-5x 加速 |
| 模型分层 | 简单任务用小模型 | 成本 80%+ |
"性能瓶颈 = AgentLoop 的'动脉硬化';缓存是'血管支架'。"
4.3 痛点的元规则
"AgentLoop 的所有痛点,本质都是'无限资源约束下做有限任务'。"
"防御不是'避免',是'提前知道怎么停'。"
💎 观点 5:loop 模式的选择 — 5 大原则
5.1 4 维度判断
| 维度 | 选项 |
|---|---|
| 复杂度 | 单步 / 多步 |
| 问题确定性 | 固定 / 动态 |
| 质量要求 | 低 / 高 |
| 协作需求 | 单 Agent / 多 Agent |
5.2 完整决策树
任务复杂度?
├─ 单步 → 基础工具调用(LLM + 1 个 Tool,直接出结果)
│
├─ 多步:
│ ├─ 问题固定 / 目标清晰?
│ │ ├─ 是 → Plan-and-Execute(稳定 + 可解释)
│ │ └─ 否 → ReAct(动态探索)
│ │
│ ├─ 高质量要求(代码 / 法律 / 医疗)?
│ │ └─ 是 → 反思迭代(鲁棒 + 多层校验)
│ │
│ └─ 需要多领域协作 / 涌现?
│ └─ 是 → 多智能体协作(成本高,慎用)5.3 5 大选择原则
| # | 原则 | 含义 |
|---|---|---|
| 1 | 够用原则 | 不选最复杂的,选能满足需求的 |
| 2 | 成本匹配 | Token 消耗要跟任务价值匹配 |
| 3 | 渐进升级 | 先简单,出问题再升级 |
| 4 | 可控优化 | 可控和稳定性最优先 |
| 5 | 场景适配 | 没有最好,只有最合适 |
5.4 元洞察
"90% 的场景,ReAct + Plan-and-Execute 混合就够了" —— 不需要上一上多智能体。
"先跑起来,再迭代" —— 跟昨天的"Harness 是迭代出来的"呼应。
💎 观点 6:Agent Loop vs Loop Engine(架构区分)
"Agent Loop = 业务逻辑(像 React);Loop Engine = 跑这些逻辑的容器(像 ReactDOM)。"
6.1 概念区分
| 维度 | Agent Loop | Loop Engine |
|---|---|---|
| 本质 | 抽象逻辑 / 业务逻辑 | 稳定容器 / 生产级引擎 |
| 类比 | React(描述 UI 长什么样) | ReactDOM / 历史版本(把 UI 真正跑起来) |
| 关注 | "LLM 应该怎么思考" | "把思考真正跑起来 + 管控" |
| 谁负责 | Agent 框架设计者 | 工程基础设施 |
| 例子 | ReAct / Plan-and-Execute | LangChain AgentExecutor / Claude Code Runtime |
关键洞察:Agent Loop 是抽象逻辑,Loop Engine 是工程基础设施。
Agent Loop(描述逻辑)
"LLM 应该先想,再调工具,然后看结果"
↓
Loop Engine(翻译成生产系统)
"把上面那段逻辑包装成:状态管理 + 异常恢复 + 重试 + 监控 + 限流 + ..."
↓
上线运行6.2 Loop Engine 提供的"生产级管控能力"
| 能力 | 作用 |
|---|---|
| 状态管理 / 持久化 | 让 Agent 不丢失上下文 |
| 异常恢复 / 重试 | 出错不挂,可恢复 |
| 监控 / 日志 | 可观测 |
| 限流 / 熔断 | 保护下游 |
| 灰度 / 回滚 | 渐进式发布 |
| 权限 / 安全 | 不越权 |
| 资源管理 | Token / 时间预算 |
| 多 Agent 通信 | SubAgent 协调 |
6.3 跟前面内容的关联
| 内容 | Agent Loop 视角 | Loop Engine 视角 |
|---|---|---|
| 5 大模式(本文观点 3) | 业务逻辑怎么设计 | 框架怎么实现这些模式 |
| 4 大痛点(本文观点 4) | 抽象逻辑的局限 | 引擎的防御机制 |
| 双重保险(观点 4.1) | 终止条件怎么设计 | 引擎强制执行 |
| Hook 系统(9-17 观点 4) | 业务规则定义 | 引擎提供 Hook 机制 |
关键洞察:没有 Loop Engine,Agent Loop 只是一个想法;没有 Agent Loop,Loop Engine 只是个空壳。
6.4 元洞察
"Agent Loop 定义'做什么',Loop Engine 决定'能不能做'。"
"一个优秀的 Loop Engine,能让糟糕的 Agent Loop 跑起来;一个糟糕的 Loop Engine,会让优秀的 Agent Loop 翻车。"
💎 观点 7:工程师的 3 重责任(角色转变)
"Loop 场景下,改变了工作方式,但没改变'人把控方向'。"
"AI 是加速器,但方向盘在人手里。"
7.1 工作方式已变
| 过去(无 AI) | 现在(Loop + AI) |
|---|---|
| 工程师写代码 | 工程师审 AI 代码 |
| 工程师调试 Bug | 工程师调试 AI 行为 |
| 工程师写测试 | 工程师设计测试架构 |
| 工程师是"实施者" | 工程师是"决策者" |
7.2 3 重责任详解
责任 1:验证者(Verifier)
"识别场景是实现价值的前提。"
含义:
- AI 不知道"做什么"是有价值的
- 工程师必须验证:"这个任务该不该做?""这个任务价值多大?"
- 如果场景选错,AI 做得越好,浪费越大
反例:AI 写了一堆代码,但这个功能根本没人用。
责任 2:债务管理者(Debt Manager)
"人的理解需要跟上 AI 的代码生成速度。"
含义:
- AI 写代码快,但人必须懂代码
- 否则会积累"技术债 + 理解债"
- "理解债"指:代码在那里,但没人懂,改不动
反例:AI 写了 10 万行代码,新人 + 老人都看不懂,谁都不敢改。
责任 3:决策者(Decision Maker)
"不作为也是一种风险。"
含义:
- AI 给出建议 → 工程师必须独立判断
- "让 AI 决定" = 放弃责任
- 沉默 / 默认接受 = 失职
反例:AI 推荐了一个"看似正确"的方案,但工程师没仔细看 → 上线后出事 → 责任在谁?
7.3 3 重责任的相互关系
验证者(场景识别)
↓
"该不该做这个?"
↓
决策者(独立判断)
↓
"AI 这个建议对吗?"
↓
债务管理者(理解跟进)
↓
"AI 写的代码我懂吗?"3 者缺一不可:
- 没有验证 → 做错事
- 没有决策 → 被 AI 绑架
- 没有债务管理 → 越写越乱
7.4 三重责任 vs 昨天的洞察
昨天 9-17 / 9-20 我说:"人从'软件开发'变成'审核员'"。3 重责任 是这句话的具体化:
| 角色转变 | 具体责任 |
|---|---|
| 验证者 | 审核"做什么" |
| 决策者 | 审核"对不对" |
| 债务管理者 | 审核"看不看得懂" |
3 重责任 = 审核员的 3 个标准动作。
7.5 元洞察
"Loop 改变了'怎么做事',没改变'为什么做事'。"
"工程师的核心价值 = 把控技术的理解和方向。"
"AI 让你写代码变快,但不会让你变得更重要——除非你承担这 3 重责任。"
📌 总结:Agent Loop 5 大模式的 3 句话
- 本质:Agent Loop = 上下文驱动的状态延续,5 大核心组件构成最小可行 Agent。
- 选择:90% 场景用 ReAct + Plan 混合;代码审查用反思迭代;跨领域用多智能体(慎用)。
- 运维:双重保险 + 4 大防御 让 Agent 不跑飞。
💬 最后一句话
"Agent Loop 5 大模式,5 种思维模式。"
"ReAct 像下棋,Plan 像写代码,反思像写论文,多智能体像交响乐,基础调用像点菜。"
"没有最好的 loop,只有最合适的 loop。"
跟昨天(9-17)讲的"Harness 是迭代出来的"呼应——Agent Loop 模式不是一开始就要选对,是先跑起来再迭代。
🛡️ 致良知 + 参考
| 项 | 内容 |
|---|---|
| 写作动机 | 补 Harness 系列的算法层缺口(9-16/9-17 偏系统/抽象,本篇讲算法) |
| 致良知 | 所有洞察都来自公开学习材料 + 个人工程实践,无任何夸大 |
| 隐私 | 所有工作单位 / 职级 / 团队规模 等敏感信息已脱敏 |
| 个人经历 | "我的连接"段引用的是公开实践(AgentScope 4 PR / 8 周 commit),非内部信息 |
参考与延伸
- Anthropic:Building Effective Agents(2024)
- LangChain:LangGraph 多 Agent 框架
- 阿里:AgentScope 2.0(笔者贡献过 4 个 PR)
- ReAct 论文:Reasoning + Acting(Yao et al., 2022)
- Self-Refine 论文:Self-Refine(Madaan et al., 2023)
关联 blog
- 9-16 Harness 工程 — 抽象层
- 9-17 AI Coding 工程 — 系统层
- 9-18 Agent Loop 5 大模式 — 算法层(本文)
- 9-20 Harness 全家福 — 综述
作者注:本文是 Harness 系列的第 3 篇短文,跟 9-16 / 9-17 / 9-20 形成完整体系。读完后你应该能回答:"Agent 怎么跑?跑飞了怎么办?怎么选最合适的 loop 模式?" 这 3 个问题。
本文首发于 sunrong.site,Mr.Sun,2026-09-18。