AI Agent Loop 深度解析：为什么它突然巨火，如何实战，什么样的 Loop 真正可用
先把本文里的 “Loop” 说清楚：它不是编程语言里的 for/while 循环，也不是增长黑客里的用户增长飞轮，而是 AI Agent / LLM 应用中的执行闭环。
可以先不用技术词，直接想一个人类协作场景：你让一个人写方案、排查问题、整理资料、修一段代码，他第一次给出的结果通常只是 50% 左右的草稿质量。不是因为他不会做，而是因为第一次输入里一定缺东西：目标不够清楚、约束没说完、证据没查全、边界条件没暴露。
真正让质量上去的，是后面的过程：
初稿 -> 追问 -> 补上下文 -> 查证据 -> 修正 -> 再评估 -> 继续收敛
每一轮可能只提升 10%、8%、6%、5%，越到后面越慢，但结果会从“能看”逐渐接近“可发布、可上线、可交付”。这就是 Loop 最朴素的直觉：不是一次生成奇迹，而是用反馈持续减少不确定性。
普通 LLM 应用通常是：
用户输入 -> 模型回答 -> 结束
而 Agent Loop 更接近：
目标 -> 装载上下文 -> 模型规划 -> 调用工具 -> 观察结果 -> 评估状态 -> 继续或停止
把上面的人类协作过程翻译成系统结构，就是这张图：用户的追问变成目标澄清，人的查证变成工具调用，人的复盘变成评估器，人的“先别发出去”变成人工审批和护栏。
它看起来只是多了几步，实际改变很大：模型不再只是“生成文本”，而是在一个被工程系统约束的环境里持续做决策、拿证据、修正路径，直到任务完成、失败、超预算、触发人工审批，或者到达最大轮数。
这也是它最近巨火的原因。过去大家主要把 LLM 当成“回答引擎”，现在越来越多产品开始把它当成“任务执行器”：写代码、查资料、跑 SQL、改文档、处理客服、调浏览器、编排内部系统、跨工具完成工作。真正的能力不只来自模型本身，而来自 模型 + 工具 + 状态 + 反馈 + 退出条件 组成的闭环。
但我会先给一个比较尖锐的判断：
Loop 的价值不是让 AI 无限自治，而是把“不确定任务”变成可观测、可中断、可评估、可恢复的控制系统。
没有目标、没有观测、没有停止条件、没有权限边界的 Loop，不是智能，是昂贵且危险的自动重试。
一、Loop 为什么突然变热？
Agent Loop 不是 2026 年才出现。ReAct 论文早在 2022 年就把推理和行动交替起来：模型一边思考，一边调用外部环境获得新信息，再基于观察结果更新后续动作。今天的热度来自另外几件事叠加：
- 模型的工具调用能力更稳定，可以生成结构化参数，不只是聊天；
- 上下文窗口变大，模型能携带更多任务状态；
- 代码、浏览器、文件、数据库、企业 API、MCP 等工具逐渐标准化；
- LangGraph、OpenAI Agents SDK、Claude Agent SDK 等运行时开始把循环、状态、handoff、human review、tracing 变成工程能力；
- AI coding、深度研究、客服自动化、运营自动化这些场景证明了“多步执行”比“一次回答”更有价值。
OpenAI 的 Agents SDK 文档把 agent 描述为会规划、调用工具、跨专家协作，并保留足够状态来完成多步工作的应用。OpenAI 的 agent 构建指南也强调，编排通常需要一个 run loop：系统持续运行，直到出现工具调用、结构化最终输出、错误或最大轮数等退出条件。
Anthropic 在《Building effective agents》中给了一个非常重要的区分：workflow 是 LLM 和工具沿着预定义代码路径执行；agent 则是模型动态决定自己的过程和工具使用。这个区分非常关键，因为很多团队一听 Loop 就想做“全自主智能体”，但真实落地里，更多问题应该先用 workflow，而不是 agent。
LangGraph 的定位也说明了这件事：它关注持久化执行、流式输出、human-in-the-loop、记忆和可观测性。换句话说，生产级 Loop 的难点不是写一个 while，而是让循环在失败、暂停、恢复、审批和审计时仍然可靠。
二、Loop 到底解决什么问题？
一句话：Loop 解决的是一次模型调用无法完成的、需要根据中间反馈不断调整路径的问题。
更具体地说，它解决五类问题。
| 问题 | 单次调用为什么不够 | Loop 如何解决 |
|---|---|---|
| 信息不完整 | 模型不知道最新状态，也不能自己查证 | 每轮调用搜索、数据库、文档或浏览器，观察结果再决定下一步 |
| 路径不确定 | 任务不能提前写死步骤 | 模型根据反馈动态选择工具、分支和下一步 |
| 结果需要验证 | 生成结果可能错，但可通过工具验证 | 执行测试、跑查询、做对比、读取日志，失败后修正 |
| 任务跨度较长 | 需要多轮上下文、子任务和状态 | 通过短期工作记忆、checkpoint、任务列表维护进度 |
| 需要人类判断 | 某些动作风险高或标准主观 | 在关键节点暂停，交给人审批、补充信息或改目标 |
这就是为什么 Loop 特别适合“做事”，不只是“说话”。比如：
- 让模型写一份行业报告：需要检索、提纲、取证、写作、校验引用；
- 让模型修一个 bug：需要读代码、定位、改动、运行测试、处理失败；
- 让模型处理客服工单：需要识别意图、查订单、判断政策、必要时转人工；
- 让模型做数据分析：需要理解指标、写 SQL、跑查询、画图、解释异常；
- 让模型操作浏览器：需要观察页面、点击、等待、纠错、确认状态。
这些任务的共同点是：下一步不能完全在任务开始前确定，必须看中间结果。
三、一个可用 Loop 的最小结构
最小 Agent Loop 不复杂，它通常只需要七个元素：
| 元素 | 作用 | 失败时的典型症状 |
|---|---|---|
| Goal | 明确要完成什么 | 模型跑偏，做了很多无关工作 |
| State | 当前任务状态 | 重复做同一件事，忘记已完成步骤 |
| Context | 模型可用信息 | 幻觉、误判、无法引用证据 |
| Policy | 允许和禁止什么 | 越权调用工具，泄露数据，误操作 |
| Tools | 能改变外部世界的能力 | 只能空谈，不能验证或执行 |
| Evaluator | 判断是否更接近目标 | 失败后继续失败，无法自我纠偏 |
| Stop | 退出条件 | 无限循环、成本失控、反复调用工具 |
伪代码大概是这样：
type AgentState = {
goal: string;
messages: Message[];
facts: string[];
plan: string[];
budget: { maxTurns: number; maxCostUsd: number };
risk: "low" | "medium" | "high";
};
async function runAgentLoop(state: AgentState) {
for (let turn = 0; turn < state.budget.maxTurns; turn++) {
const decision = await callModel({
goal: state.goal,
messages: state.messages,
facts: state.facts,
plan: state.plan,
tools: availableToolsFor(state.risk),
});
if (decision.type === "final") {
return decision.answer;
}
if (decision.type === "needs_approval") {
return pauseForHumanReview(state, decision);
}
const toolResult = await runToolWithGuardrails(decision.toolCall);
state.messages.push(toolResultToMessage(toolResult));
const evaluation = await evaluateProgress(state, toolResult);
if (evaluation.shouldStop) {
return evaluation.finalAnswer;
}
state = updateState(state, evaluation);
}
throw new Error("Agent stopped because maxTurns was reached.");
}
注意这里最重要的不是 for 循环，而是：
- 每轮都带着当前状态；
- 工具调用受权限和风险控制；
- 有评估器判断是否继续；
- 有最大轮数作为硬停止；
- 高风险动作会暂停给人；
- 所有中间结果都能记录、追踪、复现。
如果没有这些，所谓 Agent Loop 往往只是：
模型猜一个动作 -> 工具报错 -> 模型再猜一个动作 -> 工具再报错
这种循环在 demo 里看起来很聪明，在生产里会变成成本、延迟和安全问题。
四、什么样的 Loop 真正可用？
我建议按“不确定性”而不是“炫酷程度”选 Loop。很多任务根本不需要 Agent，只需要一个更干净的 workflow。
1. Level 0：单次调用
适合输入清楚、输出可直接验收的任务。
典型场景：
- 文本分类；
- 翻译、改写、摘要；
- 从文本里抽取结构化字段；
- 根据固定模板生成邮件草稿；
- 判断某个内容是否违反规则。
这种场景不要硬上 Loop。单次调用更便宜、更快、更容易测试。很多团队的第一个误区，就是把原本一个函数能解决的任务做成了 Agent。
2. Level 1：链式工作流
适合步骤固定，但每一步需要 LLM 参与的任务。
例子：
用户需求
-> 分类
-> 检索相关资料
-> 生成草稿
-> 校验格式
-> 输出最终结果
典型场景：
- 固定格式报告生成；
- 内容审核流水线；
- 合同条款初筛；
- 数据清洗说明生成；
- 内部知识库问答，先检索再回答。
它的核心优势是可预测。你知道每一步会发生什么，也可以单独替换某一步。Anthropic 提到的 prompt chaining、routing、parallelization 等模式，本质上都属于更可控的 workflow 组合。
3. Level 2：路由 Loop
适合“先判断任务类型，再交给不同路径”的系统。
典型场景：
- 客服工单：退款、物流、发票、技术问题走不同 agent 或 workflow；
- 邮件助理：紧急邮件、待回复邮件、FYI 邮件分流；
- 企业内部助理：HR、财务、IT、法务请求分流；
- 开发助手：bug、需求、重构、测试补充走不同策略。
路由 Loop 的关键不是让模型做所有事，而是让模型把事情送到正确地方。这个模式非常实用，因为它把开放问题变成多个更窄的问题。
4. Level 3：评估优化 Loop
这是最容易落地、也最被低估的 Loop。
结构如下：
生成者 produce
-> 评估者 critique
-> 如果不达标，带着反馈重做
-> 如果达标，输出
典型场景：
- 文案打磨；
- SQL 生成后检查字段、口径、性能；
- 代码生成后跑 typecheck/test；
- 报告生成后检查引用、数字和逻辑；
- 前端页面生成后截图检查布局问题。
这个 Loop 的关键是：评估器必须比生成器更可靠，或者至少拥有更强证据。
例如“让另一个 LLM 说这篇文章好不好”不一定可靠；但“运行测试、检查 schema、对比快照、校验引用链接、截图检测文字重叠”更可靠。优秀的评估优化 Loop 应该尽量把主观评价转成可执行检查。
5. Level 4：工具行动 Loop
这才是很多人说的 Agent Loop：模型选择工具，工具改变外部状态，模型观察结果后继续行动。
典型场景：
- 研究型任务：搜索、阅读、对比、引用、综合；
- 编码任务：读文件、修改、运行测试、根据错误修复；
- 运维排障：查监控、读日志、执行诊断命令、生成处理建议；
- 数据分析：查 schema、写 SQL、跑查询、画图、解释结果；
- 浏览器任务：打开页面、填写表单、下载文件、确认状态。
这类 Loop 的收益很大，风险也更大。因为工具可能产生副作用，比如发邮件、删数据、改配置、下单、发布代码。所以它必须有权限系统、审批节点、幂等设计和审计日志。
6. Level 5：多 Agent 协作 Loop
多 Agent 很容易被过度使用。它适合任务天然跨领域，或者需要不同角色互相制衡。
典型结构：
- manager agent 拆任务；
- researcher agent 找资料；
- coder agent 实现；
- reviewer agent 审查；
- critic agent 质疑；
- specialist agent 处理某个领域；
- human owner 决策和验收。
它适合：
- 跨部门客服系统；
- 复杂代码迁移；
- 大型报告或投研；
- 多语言、多市场、多规则的企业流程；
- 安全、合规、质量需要互相校验的任务。
但我的观点是：多 Agent 不是能力放大器，首先是复杂度放大器。
如果一个 Agent 没有清晰输入输出、工具边界和验收标准，拆成五个 Agent 只会得到五倍不可控。多 Agent 的前提是角色边界足够硬，交接协议足够清楚，责任归属不能消失。
五、Loop 适合解决哪些真实业务问题？
下面这些场景很适合从 Loop 思维开始设计。
1. 知识工作：从“回答问题”到“完成研究”
传统 RAG 常见问题是：检索一次，回答一次。如果问题复杂，第一次检索很可能不够。Agent Loop 可以让系统：
- 先理解问题；
- 生成检索计划；
- 多轮搜索和阅读；
- 对冲突信息做交叉验证；
- 发现缺口后继续查；
- 最后带证据生成结论。
适合场景：
- 行业分析；
- 竞品调研；
- 技术选型；
- 法规政策初步解读；
- 公司内部知识库深度问答。
这里的关键指标不是“回答得像不像”，而是：
- 引用是否可追溯；
- 是否覆盖关键反例；
- 是否标出不确定性；
- 是否区分事实、推断和观点；
- 是否在证据不足时停下，而不是编。
2. 软件工程：从“生成代码”到“闭环修复”
AI 编程最有价值的不是一次生成很多代码，而是能进入工程闭环：
理解目标 -> 读代码 -> 定位影响面 -> 修改 -> typecheck/test -> 读错误 -> 再改 -> 总结
这类 Loop 解决的问题是：代码正确性不能只靠模型自信，必须靠编译器、测试、类型系统、静态分析、截图、运行日志来验证。
好用的 coding loop 一定有几个特征：
- 工具能读写真实仓库；
- 每次修改范围可见；
- 能运行局部测试和全量检查；
- 能根据错误日志收敛；
- 不会乱改无关文件；
- 高风险命令需要确认；
- 最终能解释改了什么、为什么、怎么验证。
Claude Code、Codex、Cursor、Devin 这类工具真正改变工作方式的地方，不是“它会写代码”，而是它们逐渐把编辑器、终端、文件系统、测试和代码审查放进同一个执行闭环。
3. 客服与运营：从“聊天机器人”到“任务办理”
客服机器人过去最大的问题是：它能说，但不能办。Agent Loop 能把对话接到订单、库存、CRM、工单系统和审批流。
典型 Loop：
识别用户意图
-> 查询订单/账户/政策
-> 判断是否符合规则
-> 低风险自动处理
-> 高风险转人工
-> 写入工单和用户可见结果
适合自动化的任务：
- 查询订单状态；
- 修改预约时间；
- 创建售后工单；
- 生成退款建议；
- 汇总用户问题；
- 把复杂诉求路由给对应团队。
不适合完全自动化的任务：
- 高金额退款；
- 合同或法律承诺；
- 医疗、金融等高风险建议；
- 用户身份不明确时的敏感信息查询；
- 品牌声誉风险较高的投诉处理。
这里的原则是：让 Loop 自动处理低风险、规则明确、高频重复的部分，把判断和例外留给人。
4. 数据分析：从“一条 SQL”到“分析过程”
真实数据分析往往不是写一条 SQL：
理解业务问题
-> 找指标定义
-> 查表结构
-> 写查询
-> 检查数据质量
-> 分层对比
-> 解释原因
-> 给出建议
Agent Loop 在这里的价值是把 analyst 的探索过程显性化。它能不断根据中间结果改查询、补维度、查异常、验证假设。
但这类 Loop 风险也高，因为模型很容易：
- 误解指标口径；
- 写出看似合理但错误的 SQL；
- 混淆相关和因果；
- 忽略数据缺失和样本偏差；
- 对小样本过度解释。
所以数据分析 Loop 必须有 metric definition、schema introspection、query log、结果采样、可视化检查和人工复核。不要让模型直接从 SQL 结果跳到业务结论，中间需要证据链。
5. 个人生产力：从“助手”到“可托付的小流程”
对个人来说，最实用的 Loop 不是科幻式全自动，而是小范围托付：
- 每天汇总邮件和 Slack；
- 根据日程准备会议材料；
- 把录音整理成行动项；
- 跟踪某个项目的公开信息；
- 把资料变成文章提纲；
- 自动生成初稿，再由你审。
个人场景的关键是边界感。不要一开始就让 Agent 直接发送、删除、购买、发布。先让它“读、整理、草拟、提醒”，等稳定后再逐步开放写操作。
六、反过来看：什么 Loop 不可用？
Loop 很火，但不可用的 Loop 也很多。
1. 没有明确目标的 Loop
坏例子：
你自己想办法优化一下我们的系统。
这会导致模型四处探索，成本高、结果散、无法验收。
好例子：
请定位登录接口 P95 延迟从 300ms 上升到 900ms 的主要原因。
约束：只能读取日志和监控，不能修改线上配置。
输出：列出最可能的 3 个原因、证据、下一步人工验证建议。
最多运行 8 轮工具调用。
Loop 不是为了替你定义目标，而是为了在目标明确后处理路径不确定性。
2. 没有外部观测的 Loop
如果模型每轮只是继续“想”，没有新证据输入，那么它很可能只是把同一组假设重新包装。
可用 Loop 必须有观察来源：
- 测试结果；
- 搜索结果；
- 数据库查询；
- 页面截图；
- 日志；
- 用户反馈；
- 静态检查；
- 人工审批意见。
没有观察，循环不会变聪明，只会变长。
3. 没有退出条件的 Loop
必须有硬停止：
- 最大轮数；
- 最大成本；
- 最大运行时间；
- 连续失败次数；
- 工具错误阈值；
- 置信度不足时停止；
- 遇到高风险动作停止；
- 用户要求停止。
OpenAI Agents SDK 的运行机制里也有 max turns 这一类限制。生产系统不要把停止条件只交给模型自己判断，因为模型最容易在“再试一下”里消耗预算。
4. 工具定义含糊的 Loop
Anthropic 在 agent 实践建议里提到，工具定义要像给初级开发者写好 docstring：参数、边界、示例、错误情况都要清楚。这个建议非常实用。
坏工具：
search(query: string): string
更好的工具：
searchInternalDocs(input: {
query: string;
productArea: "billing" | "auth" | "infra" | "unknown";
maxResults: number;
freshness: "any" | "last_30_days" | "last_12_months";
}): SearchResult[]
工具越模糊，模型越需要猜。模型越需要猜，Loop 越容易发散。
5. 权限过大的 Loop
任何能改变外部世界的工具都应该最小权限：
- 读权限和写权限分开；
- 草稿和发送分开；
- 预览和执行分开；
- 沙箱和生产分开；
- 低风险和高风险工具分开；
- 个人数据、企业数据、公开数据分开。
一个常见设计是：
默认：只读工具
低风险：可写草稿、可创建待审核记录
中风险：需要人工批准后执行
高风险：只给建议，不允许自动执行
这不是保守，而是让 Loop 能进生产的前提。
七、如何实战：从 0 到 1 设计一个可用 Agent Loop
下面给一套我认为最稳的落地顺序。
第一步：先写任务合约，而不是先写 Prompt
任务合约至少包含：
| 字段 | 示例 |
|---|---|
| 目标 | “把用户的退款请求处理到可执行状态” |
| 成功标准 | “输出退款资格、金额、依据、下一步动作” |
| 允许动作 | “查询订单、查询政策、创建退款草稿” |
| 禁止动作 | “不能直接退款，不能承诺法律责任” |
| 需要人审 | “金额超过 500 元、政策冲突、用户身份不确定” |
| 停止条件 | “最多 6 轮工具调用，连续 2 次工具失败停止” |
| 输出格式 | “结构化 JSON + 用户可读摘要” |
Prompt 是实现细节，任务合约才是系统边界。
第二步：从 workflow 开始，不要直接全自主
推荐路径：
单次调用
-> 固定链路 workflow
-> 加入评估器
-> 加入少量工具
-> 加入状态和审批
-> 再考虑多 Agent
这是因为 workflow 更容易收集数据。你需要先知道模型在哪些步骤稳定、哪些步骤不稳定，再决定哪里需要 Loop。
第三步：把工具做窄、做硬、做可恢复
工具设计最好遵守这些原则：
- 一个工具只做一类动作；
- 参数强类型，枚举优于自由文本；
- 返回结构化结果，不只返回一段文字；
- 错误信息对模型可理解；
- 写操作默认产生草稿或计划，不直接执行；
- 所有工具调用都有 trace id；
- 写操作支持幂等和回滚；
- 生产凭证不直接暴露给模型。
例如客服退款工具可以拆成：
getOrder(orderId)
getRefundPolicy(productType, region)
draftRefundCase(orderId, reason, amount)
requestHumanApproval(caseId)
executeRefund(approvalId)
不要给一个万能工具：
doCustomerServiceAction(anything)
万能工具会让模型误解边界，也让审计变得困难。
第四步：设计状态，而不是堆聊天记录
很多 Loop 的状态管理只有一串 messages，这会带来两个问题：
- 上下文越来越长，成本越来越高；
- 模型很难区分事实、假设、计划和历史废话。
更好的状态应该分层：
type TaskState = {
goal: string;
facts: string[];
assumptions: string[];
openQuestions: string[];
completedSteps: string[];
nextSteps: string[];
toolEvidence: ToolEvidence[];
riskFlags: string[];
};
每轮都让模型基于结构化状态行动，而不是把全部聊天记录塞回去。LangGraph 强调的 stateful、long-running、persistence，本质上就是让这个状态在多轮、失败和恢复时仍然可靠。
第五步：把退出条件写成代码
不要只在 Prompt 里说“不要无限循环”。应该在运行时硬编码：
const stopPolicy = {
maxTurns: 8,
maxToolErrors: 2,
maxCostUsd: 0.8,
maxRuntimeMs: 90_000,
stopWhenNoNewEvidenceForTurns: 2,
requireHumanForRisk: ["payment", "delete", "external_send"],
};
模型可以建议继续，但运行时必须有最终裁决权。
第六步：先做离线评估集，再做线上自动化
不要拿真实用户当评估集。先收集 30 到 100 个典型任务：
- 简单成功样本；
- 边界样本；
- 工具失败样本；
- 信息不足样本；
- 恶意输入样本；
- 高风险样本；
- 多轮复杂样本。
然后记录指标：
| 指标 | 含义 |
|---|---|
| Task success rate | 最终是否完成任务 |
| Tool accuracy | 工具选择和参数是否正确 |
| Turn count | 平均需要几轮 |
| Cost per success | 每个成功任务成本 |
| Human escalation rate | 转人工比例是否合理 |
| Unsafe action rate | 是否尝试越权操作 |
| Evidence quality | 结论是否可追溯 |
| Recovery rate | 工具失败后能否恢复 |
一个 Loop 不是 demo 成功一次就可用，而是要在一组真实分布任务上稳定。
第七步：上线时从只读、草稿、低风险开始
生产上线顺序建议：
- 只读总结：模型只能读，不能写；
- 草稿模式：模型能创建草稿，但人点击确认；
- 低风险自动化：小金额、可回滚、高频任务自动执行；
- 审批自动化：高风险动作必须人工批准；
- 自适应路由：根据风险、置信度、历史表现动态决定自动或人工；
- 持续评估：线上抽样、回放、回归测试、策略更新。
这条路径看起来慢，但它能让你真正知道 Loop 在哪里可靠，而不是被一个漂亮 demo 迷惑。
八、Human-in-the-loop 不是倒退，而是能力设计
很多人把 human-in-the-loop 理解成“AI 不够强，所以需要人”。这个理解太浅了。
更准确地说，人类在 Loop 中承担四种职责：
| 人的职责 | 什么时候需要 |
|---|---|
| 目标澄清 | 任务模糊、成功标准不清楚 |
| 风险审批 | 涉及钱、隐私、删除、外发、法律承诺 |
| 价值判断 | 产品品味、品牌语气、业务取舍 |
| 例外处理 | 规则冲突、证据不足、模型不确定 |
一个成熟系统不会追求“完全无人参与”，而是追求 把人的注意力放在最有价值、最不可自动化的节点上。
好的 human-in-the-loop 设计应该满足：
- 人看到的是摘要、证据和可选动作，不是完整噪声；
- 人能修改状态，而不是只能批准或拒绝；
- 被拒绝的原因能回到模型，帮助它继续；
- 审批记录可审计；
- 系统能学习哪些任务应该提前转人工。
LangGraph、OpenAI Agents SDK 等运行时都强调 human review / human-in-the-loop，不是因为它们“不够 agent”，而是因为生产系统必须允许暂停、审查、修改和恢复。
九、正向价值：Loop 真正带来的改变
我认为 Agent Loop 的正向价值主要有五个。
1. 把 AI 从内容工具变成任务系统
单次 LLM 调用主要生成内容。Loop 让模型能和外部系统交互，开始完成任务。它把 AI 从“会说”推向“会做”。
2. 把不确定性显性化
好的 Loop 会暴露中间步骤、工具结果、失败原因和决策路径。它不会让模型一次性给出貌似确定的答案，而是让系统呈现“我查了什么、发现什么、还不确定什么”。
3. 把验证前置
在 coding、data、research 等场景，Loop 可以让验证成为过程的一部分，而不是最后才发现错误。测试、查询、引用、截图、日志都可以成为每轮反馈。
4. 把人的判断力用在关键节点
Loop 不是取代人，而是把大量重复探索交给机器，把风险、价值、例外留给人。对组织来说，这比“让 AI 自动做一切”更现实。
5. 形成可复用的能力资产
一旦你把工具、状态、评估、审批、trace 做好，它们会成为组织资产。下一个 Agent 不必从零开始，而是复用同一套运行时。
十、反向风险：Loop 为什么也会制造新问题？
1. 成本和延迟非线性增长
一次调用 2 秒、0.01 美元，10 轮就不是简单乘以 10。中间还会有工具调用、检索、浏览器等待、失败重试、长上下文成本。Agent Loop 的体验常常被尾延迟拖垮。
2. 错误会沿着状态传播
如果第一轮读错需求，第二轮会基于错误需求写计划，第三轮会执行错误计划，第四轮还可能“合理化”错误结果。Loop 能纠错，也能放大错误。
3. 工具副作用比文本幻觉更危险
文本回答错了可以改；工具调用错了可能发错邮件、删错数据、泄露信息、产生财务损失。Agent 的风险从“说错”升级为“做错”。
4. 可观测性不足会让调试变难
当系统包含模型、工具、状态、审批、检索、路由、多 Agent，问题可能出在任何地方。没有 trace，你只能看到“最后答案错了”，不知道是哪一轮、哪个工具、哪个状态污染导致。
5. 过度自治会稀释责任
“Agent 自己决定的”不能成为工程系统的责任出口。任何生产 Agent 都必须有 owner，有权限边界，有审计记录，有事故处理流程。
十一、实战模板：一个客服退款 Agent Loop
下面用一个小例子把前面的原则串起来。
任务合约
goal: 判断用户退款请求是否可进入退款草稿
allowed_tools:
- get_order
- get_refund_policy
- calculate_refund_amount
- draft_refund_case
- request_human_approval
forbidden_actions:
- execute_refund_without_approval
- reveal_internal_policy_notes
- change_order_status
human_review:
- refund_amount > 500
- policy_conflict == true
- identity_confidence < 0.9
stop:
max_turns: 6
max_tool_errors: 2
output:
- eligibility
- evidence
- next_action
- user_visible_message
Loop 流程
1. 读取用户消息，识别订单号和诉求
2. 查询订单状态
3. 查询对应地区和商品类型的退款政策
4. 判断是否满足条件
5. 计算建议退款金额
6. 如果低风险，创建退款草稿
7. 如果高风险，请求人审
8. 输出用户可读说明和内部证据
为什么它可用？
它可用不是因为模型“聪明”，而是因为边界清楚：
- 工具只覆盖退款任务；
- 不能直接执行退款；
- 高金额必须人审；
- 每个判断都有订单和政策证据；
- 最多 6 轮，失败会停止；
- 输出结构化，方便接后续系统。
为什么它比普通聊天机器人强？
普通机器人只能说：
您可能符合退款条件，请联系客服。
Agent Loop 可以说：
根据订单状态、购买时间和商品类型，你符合退款草稿创建条件。
系统已生成退款草稿，预计金额为 128 元。
因为该订单不涉及高风险规则，不需要人工审批。
当然，真正执行退款仍然可以放在人审或明确确认之后。
十二、实战模板：一个代码修复 Agent Loop
代码场景更能体现 Loop 的价值，因为它天然有外部验证器。
最小工具集
| 工具 | 权限 |
|---|---|
| read_file | 只读 |
| search_code | 只读 |
| apply_patch | 写入，但只允许工作区 |
| run_typecheck | 执行，只读 |
| run_tests | 执行，只读 |
| git_diff | 只读 |
Loop 流程
用户目标
-> 搜索相关代码
-> 读取上下文
-> 提出修改计划
-> 应用补丁
-> 运行 typecheck/test
-> 如果失败，读取错误并修复
-> 输出 diff 摘要和验证结果
可用性的关键
- 不允许随意重构无关文件；
- 每轮修改后看 diff；
- 测试失败必须基于错误信息修；
- 连续失败要停下并报告；
- 不确定时问人，而不是猜业务规则；
- 最终必须说明验证命令和结果。
这就是为什么 coding agent 的 Loop 比普通代码生成更有价值：它把“写代码”和“证明代码能工作”放进同一条闭环。
十三、Agent Loop 和 RAG、Workflow、ReAct、LangGraph 的关系
这几个词容易混。
| 概念 | 核心问题 | 和 Loop 的关系 |
|---|---|---|
| RAG | 如何给模型补充外部知识 | RAG 可以是 Loop 的某一类工具或上下文装载方式 |
| Workflow | 如何按固定路径编排模型和工具 | Workflow 是更确定、更可控的低自治 Loop |
| ReAct | 如何让模型交替推理和行动 | ReAct 是 Agent Loop 的经典思想来源 |
| LangGraph | 如何构建有状态、可持久化的 agent 编排 | LangGraph 是 Loop 的一种生产运行时 |
| Agents SDK | 如何定义 agent、工具、handoff、guardrails 和 run loop | SDK 把 Loop 的常见机制工程化 |
| Human-in-the-loop | 如何让人在关键节点参与 | 它是生产 Loop 的安全和质量机制 |
最好的理解方式是：
RAG 提供知识
Workflow 提供确定路径
ReAct 提供推理-行动范式
LangGraph / Agents SDK 提供运行时
Human-in-the-loop 提供风险控制
Agent Loop 把它们组合成一个会推进任务的系统
十四、我的判断：未来有价值的不是“更长 Loop”，而是“更短反馈”
很多人把 Agent 的进步想象成：让模型连续跑 100 轮，自己完成越来越大的任务。
我不太认同。
真正有价值的方向不是更长的 Loop，而是更短、更可靠、更有证据的反馈闭环：
- 更快知道下一步是否有效；
- 更早发现目标不清楚；
- 更准确识别风险；
- 更低成本地验证假设；
- 更自然地把人带入关键节点；
- 更稳定地从失败中恢复。
未来好的 Agent 产品，不会让用户盯着一个黑盒跑很久，而会像一个透明的任务控制台：
我正在做什么
为什么这么做
已经拿到什么证据
下一步有什么风险
哪里需要你决定
什么时候会自动停止
这也是我对 Loop 的最终观点：
Agent Loop 不是 AI 自主性的浪漫叙事，而是软件工程重新引入反馈控制、状态管理和责任边界的过程。
当你能把它设计成一个可验证系统，它就能解决真实问题；当你只是把它当成“让模型自己多试几次”，它就会制造更多问题。
十五、落地检查清单
最后给一份可以直接用的清单。
| 检查项 | 问题 |
|---|---|
| 目标 | 任务是否有明确成功标准？ |
| 适用性 | 这个任务真的需要 Loop，还是单次调用/固定 workflow 就够？ |
| 状态 | 系统是否显式维护事实、计划、假设、证据和风险？ |
| 工具 | 每个工具是否强类型、窄职责、可审计？ |
| 权限 | 读、写、外发、删除、支付是否分级？ |
| 观察 | 每轮是否能拿到新的外部证据？ |
| 评估 | 是否有自动检查或人类验收标准？ |
| 停止 | 是否有最大轮数、成本、时间、失败阈值？ |
| 恢复 | 中断后是否能从 checkpoint 继续？ |
| 审计 | 是否记录模型输入、工具调用、结果和审批？ |
| 安全 | 高风险动作是否默认暂停？ |
| 指标 | 是否衡量成功率、成本、延迟、转人工率和 unsafe action？ |
如果这张表里有一半答不上来，先别上生产 Agent。先做一个小 workflow，把评估和工具边界打磨好。
参考资料
- OpenAI Agents SDK 文档：关于 agent、工具、状态、运行时和 handoff 的官方说明。
- OpenAI Agents SDK：Running agents：描述 Runner 的 agent loop、final output、tool calls、handoff 和 max turns。
- OpenAI: A practical guide to building agents：关于 run loop、退出条件、handoff、guardrails 的实践指南。
- Anthropic: Building effective agents：区分 workflow 与 agent，并强调简单、可组合、可调试的模式。
- LangGraph Overview：关于 long-running、stateful agents、durable execution、human-in-the-loop、memory 和 tracing 的官方介绍。
- ReAct: Synergizing Reasoning and Acting in Language Models：将 reasoning traces 与 task-specific actions 交替结合的经典论文。