Loop Engineering 是什么：让 AI Agent 从一次性回答变成可迭代执行

Loop Engineering描述的问题非常真实：很多 AI Agent 不是输在“模型不会回答”，而是输在只会回答一次，做错了不知道怎么继续；工具调用失败了只会重试；任务没有停止条件，越跑越乱。

如果说 Prompt Engineering 关注“怎么问模型”，Context Engineering 关注“给模型什么上下文”，那么 Loop Engineering 关注的是：如何把 AI Agent 设计成一个可以规划、执行、观察、评估、修正并安全停止的闭环系统。

Loop Engineering 视觉摘要：从一次性回答到反馈闭环

一、为什么需要 Loop Engineering

很多人第一次做 Agent，会把流程写成这样：

用户输入 → 大模型生成答案 → 返回结果

这适合问答，但不适合执行任务。真实业务里的 Agent 经常遇到这些情况：

所以 Agent 工程的关键，不是让模型“想得更多”，而是让它做完一步后知道下一步该干什么。

这就是 Loop Engineering 的价值。

二、Loop Engineering 的一句话定义

可以把 Loop Engineering 定义为：

面向 AI Agent 和自动化系统的反馈闭环设计方法，通过状态管理、工具执行、外部观察、评估信号、纠错策略和停止条件，让模型从“一次性生成”升级为“可迭代完成任务”。

它解决的不是“模型会不会说”，而是：

1. 任务怎么拆成多轮步骤；
2. 每一轮执行后如何判断结果；
3. 失败后应该重试、换策略、降级，还是问人；
4. 什么情况下必须停止；
5. 如何避免 Agent 自己陷入无限循环。

一个典型 Loop 长这样：

Goal → Plan → Act → Observe → Evaluate → Reflect/Fix → Stop or Continue

中文可以理解为：

目标 → 计划 → 执行 → 观察 → 评估 → 修正 → 停止或继续

三、别把 Loop Engineering 等同于“多试几次”

很多项目里的所谓 Agent Loop，本质上只是：

foriinrange(5):answer=llm(prompt)iflooks_good(answer):break

这不是 Loop Engineering，只是重复调用。

真正的 Loop 至少要回答四个问题：

Loop Engineering 的重点不是“循环”，而是有反馈、有状态、有边界的循环。

Loop 架构图：状态、工具、观察、评估和人工门禁

四、一个最小可用的 Agent Loop 模板

下面是一个工程上更容易落地的最小 Loop 模板：

fromdataclassesimportdataclass,fieldfromtypingimportAny@dataclassclassLoopState:goal:strplan:list[str]=field(default_factory=list)evidence:list[dict]=field(default_factory=list)actions:list[dict]=field(default_factory=list)errors:list[str]=field(default_factory=list)iteration:int=0status:str="running"# running / success / failed / need_humanMAX_ITERATIONS=6defagent_loop(state:LoopState):whilestate.status=="running":state.iteration+=1ifstate.iteration>MAX_ITERATIONS:state.status="need_human"state.errors.append("超过最大循环次数，停止自动执行")breakstep=plan_next_step(state)result=execute_step(step,state)state.actions.append({"step":step,"result":result})observation=observe_result(result)evaluation=evaluate_observation(observation,state)ifevaluation["passed"]:state.status="success"breakifevaluation["risk"]=="high":state.status="need_human"breakstate=repair_state(state,evaluation)returnstate

这个模板里有几个关键点：

• LoopState保存当前任务状态；
• MAX_ITERATIONS限制循环次数；
• evaluate_observation提供外部评估；
• 高风险情况进入need_human，而不是继续自动执行；
• 每一轮行动都记录下来，方便复盘。

五、Loop State：没有状态，就没有真正的闭环

很多 Agent 失败，是因为每一轮都像重新开始。

Loop State 至少要保存这些内容：

如果没有状态，Agent 很容易出现三类问题：

1. 重复尝试：同一个错误方案反复执行；
2. 证据丢失：前一轮查到的信息后一轮不用；
3. 目标漂移：修 A 问题时顺手改了 B 模块。

一个更完整的状态可以这样设计：

{"goal":"修复订单退款接口的单测失败","constraints":["不能改数据库结构","不能跳过测试"],"current_step":"分析失败日志","tried_actions":[{"action":"run_test","result":"failed","error":"status_code expected 200 got 409"}],"hypotheses":["退款状态机缺少处理中分支"],"evidence":["test_refund_pending_case","refund_state_machine.py"],"iteration":2,"status":"running"}

六、Observe：工具返回值不是结果，解释后的信息才是观察

Agent 调用工具后，不能只把原始输出塞回模型。比如运行测试后，工具返回的是一大段日志，但 Loop 需要的是结构化观察：

{"tool":"pytest","passed":false,"failed_cases":["test_refund_pending_order"],"error_type":"assertion_error","key_message":"expected 200 but got 409","suspected_module":"refund_state_machine"}

观察层的作用是把原始结果变成可决策信息。

常见观察类型包括：

没有 Observe 层，Agent 很容易把“看见了输出”误当成“理解了结果”。

评估与纠错闭环：失败不是重试，而是分类处理

七、Evaluate：不要让模型自己宣布自己成功

Loop Engineering 里最重要的一点是：评估信号要尽量外部化。

比如写代码不能只问模型：

你觉得代码修好了吗？

而应该运行：

pytest tests/test_refund.py-q

RAG 问答不能只看答案是否流畅，而要检查：

• 是否引用了证据；
• 证据是否真的支持结论；
• 是否出现无证据断言；
• 证据之间是否冲突；
• 高风险问题是否触发确认。

一个评估结果可以设计成：

{"passed":false,"score":0.72,"failed_rules":["missing_evidence_for_refund_policy","tool_call_without_confirmation"],"risk":"high","next_action":"ask_human"}

评估层决定 Loop 是继续、修正、失败还是人工接管。

八、Repair：失败后不是重试，而是分类纠错

失败后的处理策略，决定了 Loop 是工程系统还是随机游走。

推荐把失败分成几类：

可以写成一个简单的修复路由器：

defchoose_repair_strategy(evaluation):error_type=evaluation.get("error_type")risk=evaluation.get("risk")ifrisk=="high":return"ask_human"iferror_typein["timeout","rate_limit"]:return"retry_with_backoff"iferror_type=="bad_argument":return"fix_arguments"iferror_type=="missing_evidence":return"retrieve_more"iferror_type=="permission_denied":return"stop_and_request_auth"return"stop_with_reason"

这比“失败就再来一次”可靠得多。

停止条件检查卡：成功、失败、风险和预算

九、Stop Condition：Loop 最大的风险是停不下来

Loop Engineering 一定要把停止条件写清楚。

常见停止条件有四类：

建议每个 Agent Loop 至少配置：

loop_policy:max_iterations:6max_tool_calls:20max_minutes:15stop_on_high_risk:truerequire_human_for:-payment-deletion-publish-restart_service-external_message

如果没有停止条件，Agent 可能会：

• 一直重试同一个错误；
• 为了完成任务越权调用工具；
• 把小问题扩大成大范围改动；
• 消耗大量 token 和 API 费用。

十、三个真实场景下的 Loop 设计

1. 写代码 Loop

读取需求 → 定位相关文件 → 修改代码 → 运行测试 → 分析失败日志 → 修复 → 再测试 → 通过后总结变更

关键评估信号：测试结果、lint、类型检查、代码 diff。

停止条件：测试通过；超过次数；改动范围超出预期；需要产品确认。

2. RAG 幻觉治理 Loop

用户问题 → 风险识别 → 检索证据 → 生成带引用答案 → 校验证据是否支持结论 → 不支持则重新检索/拒答/追问

关键评估信号：证据召回率、引用准确率、无证据断言比例。

停止条件：证据足够；证据冲突；问题超出知识库；高风险动作需要确认。

3. 内容质量优化 Loop

生成初稿 → 检查标题、结构、案例、代码、图表 → 找出薄弱项 → 局部重写 → 再评分 → 达标后保存草稿

关键评估信号：结构完整度、原创洞察、工程可复现、读者收益、平台质量分。

停止条件：达到目标分；多轮无提升；主题本身平台识别弱；需要人工反馈。

十一、Loop Engineering 和 Prompt Engineering 的区别

Prompt Engineering 仍然重要，但它只是 Loop 里的一个组件。

一个成熟 Agent 往往需要：

Prompt Engineering + Context Engineering + Tool Engineering + Loop Engineering + Evaluation Engineering

其中 Loop Engineering 负责把这些能力串成可执行闭环。

十二、落地检查清单

如果你正在做一个 Agent，可以用下面这张清单自检：

如果这些问题大部分是“否”，那这个 Agent 还只是一个会调用工具的聊天机器人。

十三、最容易踩的 5 个坑

1. 把 Loop 写成无限 while：没有次数、时间和成本上限，迟早会失控。
2. 失败只会重试：参数错、权限错、证据不足，不能用同一种策略处理。
3. 让模型自己判断成功：没有测试、评分、证据校验，成功只是幻觉。
4. 不保存尝试历史：Agent 会忘记自己刚刚失败过，又走回老路。
5. 高风险动作不设门禁：Loop 一旦能调用真实工具，安全边界比回答质量更重要。

一句话结论

Loop Engineering 的核心不是“让 Agent 多跑几轮”，而是设计一套有目标、有状态、有观察、有评估、有纠错、有停止条件的反馈闭环。只有这样，AI Agent 才能从一次性回答问题，走向可验证、可复盘、可安全交付的任务执行系统。