AI Agent 循环工程实战：为什么纯提示词不够，还需要 Agent 框架

2026年6月，Claude Sonnet 4.5 把 Agent 的连续自主运行时间推到了30小时。这个能力的背后，不是提示词写得多巧妙，而是一套"执行→观察→反思→再执行"的循环工程。

本文讲清楚三个问题：循环工程是什么、纯提示词能不能实现、提示词和 Agent 框架各自的分工。

一、循环工程解决什么问题

AI Agent 的根本困境：单次调用不可靠。

大模型做概率预测。第一次输出可能有代码bug、推理跳步、参数格式错误、理解偏差。如果直接交付结果，用户拿到的可能是半成品。

循环工程的核心思想：不指望一次做对，而是让 Agent "做→看→改→再做"，循环往复直到任务完成或触发终止条件。

一个标准的循环包含4个阶段：

规划（Plan）→ 执行（Execute）→ 观察（Observe）→ 反思（Reflect）
     ↑                                              │
     └──────────── 未完成则回到规划 ←────────────────┘

规划：根据目标拆解当前要做的子任务
执行：调用工具（写代码、搜索、调用API）
观察：收集执行结果、报错信息、输出内容
反思：判断是否完成，分析失败原因，生成新的执行计划

二、纯提示词能实现循环吗

可以写一段提示词让模型"模拟"循环：

你是一个编程助手。请按以下步骤工作：
1. 写出代码
2. 自己检查代码是否有错误
3. 如果有错误，修正后再检查
4. 重复直到你认为代码无误
5. 输出最终版本

简单任务能跑通。但存在四个根本缺陷：

1. 没有真实执行。模型在"想象"代码运行结果，不是真正运行。很多bug只有跑起来才会暴露——边界条件、环境差异、依赖版本。

2. 没有真实反馈。错误信息是模型自己编的，不是终端或编译器返回的真实stderr。模型可能检查不出自己认知盲区内的错误。

3. 上下文长度限制。一次API调用有几万token上限进入第二轮思考，上下文就爆了。

4. 无法调用外部工具。模型不能真正去搜索网页、读本地文件、跑测试用例。一切全靠模型"凭记忆"。

这种模式叫"思考上的循环"，不是"行动上的循环"。看起来在迭代，实际上是一个封闭系统内的自说自话。

三、Agent 框架补上了什么

循环工程的核心不是"思考多次"，而是行动加观察的真实闭环。Agent 框架提供的是纯提示词做不到的四件事：

能力	纯提示词	Agent 框架
执行代码	不能	能（终端/沙箱真实运行）
捕获报错	不能（只能编造）	能（真实stderr/返回值）
读写文件搜索	不能（凭记忆）	能（工具调用返回真实数据）
跨轮次状态	无（单次会话）	有（持久化上下文和记忆）

简单说：提示词管 Agent 怎么想，Agent 框架管 Agent 怎么做。

四、一个具体例子：修复一个报错的脚本

用户指令：帮我修好这个报错的 Python 脚本

纯提示词的输出

分析：代码可能在字符串拼接处有类型问题。
修改如下：
（输出一段代码）
检查完毕，应该没有问题了。

（能不能跑？不知道。模型停了。）

Agent 循环的执行过程

第1轮：

规划：读取报错 TypeError: can only concatenate str to str
执行：用 str() 包裹变量，写入文件
观察：终端运行，新报错 IndexError: list index out of range
反思：类型问题修了，但列表访问越界，需要继续

第2轮：

规划：检查循环条件
执行：发现 range(len(data)+1) 多了一个1，修正为 range(len(data))
观察：终端运行，输出正确结果
反思：任务完成，退出循环

整个过程可能花5分钟、3轮循环。每一轮的"观察"来自真实执行反馈，不是模型自己编的。最终交付的是经过验证的代码。

五、循环工程的三个关键设计

1. 终止条件

不能无限循环。常见策略：

最大轮次限制（如10轮）
成功检测（测试通过/用户确认）
成本上限（token消耗超过阈值自动停止）
死锁检测（连续3轮没有新进展则退出）

2. 上下文管理

每轮循环产生大量中间信息（错误日志、代码diff、思考过程）。不做管理的话上下文窗口很快爆掉。

常见做法：

只保留最近N轮的完整信息
对早期轮次做摘要压缩
把关键状态（当前代码版本、最新错误）结构化存储，而非塞进对话历史

3. 反思质量

循环能不能收敛，取决于反思是否靠谱。低质量反思会让 Agent 原地打转。

提升反思质量的方法：

把完整错误信息喂给 Agent（不能截断）
要求 Agent 先复述"我认为错在哪"再动手修改
引入外部验证器（测试用例、类型检查、lint工具）代替纯靠模型自检

六、主流框架的循环机制对比

框架	循环方式	特点
Claude Sonnet 4.5 Agent	原生工具调用循环	单次调用可持续30小时，内部自动循环
LangGraph	状态机 + 条件边	开发者定义节点和跳转逻辑，显式控制循环
AutoGen	多 Agent 对话循环	多个 Agent 互发消息，直到达成共识
OpenAI Assistants	工具调用 + 轮次限制	内置 function calling 循环，最多128轮
Hermes Agent	工具调用 + 推理	每轮工具返回后重新推理，支持 watch_patterns

七、什么场景需要循环工程

场景	是否需要循环	原因
写一段文案	不需要	单次输出即可验证
回答一个问题	不需要	用户自己判断对错
写一段能跑的代码	需要	只有执行才知道对不对
多步骤任务（调研→整理→发布）	需要	前一步输出是后一步输入，可能传递错误
数据处理pipeline	需要	格式错误在下游才会暴露
自动化运维操作	需要	操作结果必须确认，不能凭猜测

判断标准：如果任务需要"验证"才算是完成，就需要循环工程。 如果结果是即时可见且可人工判断的，提示词就够了。

八、总结

循环工程的本质是把"一次生成"变成"生成→验证→修正"的迭代过程，用计算量换可靠性。

提示词和 Agent 框架不是替代关系，是分工关系：

提示词解决"怎么想"：分析策略、反思角度、输出格式
Agent 框架解决"怎么做"：真实执行、真实反馈、状态保持

只靠提示词是在纸上谈兵。只有两者结合，才能让 Agent 从"生成内容的工具"进化成"完成任务的系统"。

如果你觉得本文有用，请点赞，收藏，转发

你有什么问题，请留言，我来帮你解答。