如果你还在为 AI 大模型生成的内容“不听话”而烦恼——比如让它写个代码它却给你一堆注释让它分析数据它却开始写诗——那么你很可能已经掉进了“一次性提示词”的陷阱。“提示词已死”这个说法并非要否定提示词的价值而是宣告了一种更高效、更可靠的工程化思维正在成为主流循环工程。过去我们习惯于精心雕琢一个“完美”的提示词然后祈祷模型能一次给出正确答案。这就像把需求一次性扔给一个实习生然后指望他交出一份完美的报告结果往往需要反复沟通、打回重做。循环工程的核心思想正是将这种“反复沟通”的过程自动化、系统化。它不再依赖单次“魔法咒语”而是构建一个可迭代、可评估、可优化的反馈循环系统。对于开发者而言这意味着从“玄学调参”转向“工程化构建”从“碰运气”转向“可预期”。本文将为你彻底拆解循环工程。你将了解到为什么“完美提示词”是个伪命题以及循环工程如何从根本上解决LLM应用的不确定性。循环工程的完整架构与核心组件包括规划器、执行器、评估器和优化器。一个从零搭建的、可运行的代码示例手把手教你实现一个用于代码生成的智能循环系统。在实际项目中落地循环工程的最佳实践与避坑指南帮你节省大量调试时间。无论你是想构建一个稳定的AI辅助编程工具还是希望将大模型更可靠地集成到你的数据分析、内容创作流程中理解并应用循环工程都将是你从“玩具演示”走向“生产级应用”的关键一步。1. 循环工程要解决的根本问题告别“提示词赌博”在深入技术细节之前我们必须先理解问题的本质。传统的提示词工程Prompt Engineering为什么在复杂任务中常常失灵痛点一单次交互的“黑盒”与不确定性。你给模型一个复杂的任务描述它返回一个结果。这个结果可能很好也可能完全跑偏。你无法在单次交互中了解模型的“思考过程”更无法中途纠正。这导致调试成本极高你只能不断修改提示词进行大量“A/B测试”效率低下。痛点二缺乏状态与记忆。一次对话结束后上下文就消失了。如果你想基于上一个结果进行细化或修正必须把整个历史对话都塞进新的提示词中不仅消耗大量Token而且随着上下文窗口变长模型性能还会下降。真正的复杂任务往往是多步骤、有状态的。痛点三评估与优化的闭环缺失。如何判断模型输出的好坏传统方式靠人眼判断。但对于批量任务或需要客观标准如代码能否编译、答案是否准确的场景人工评估不可扩展。没有自动化的评估就无法实现自动化的优化。循环工程的破局思路它将一次性的“祈祷式”交互拆解为一个可管理的工作流Workflow规划Plan将大任务分解为可执行的子步骤。执行Execute调用模型或工具完成每个子步骤。评估Evaluate用预设标准自动检查结果质量。优化Optimize根据评估结果调整策略或重试。这个循环可以自动运行多次直到产出满足质量要求或达到重试上限。这本质上是在用系统的确定性去对抗模型输出的不确定性。2. 核心概念循环工程的四层架构一个完整的循环工程系统通常包含以下四个核心层它们共同构成了一个自治的智能体Agent系统。层级组件核心职责类比控制层规划器 (Planner)任务分解、步骤规划、策略选择。相当于项目的“项目经理”或“架构师”。接到“建一座桥”的任务先画出设计图、列出材料清单、安排施工顺序。执行层执行器 (Executor)具体执行规划器制定的每一步操作。可以是调用LLM生成文本也可以是调用API、运行代码等工具。施工队按照图纸进行打桩、浇筑混凝土等具体操作。评估层评估器 (Evaluator)对执行器的产出进行质量评估。可以是规则匹配、模型打分、代码测试等。监理工程师检查混凝土强度、桥面平整度是否达标。优化层优化器 (Optimizer)根据评估结果决定下一步动作继续、重试、回退还是终止。并可能调整规划器的策略。项目总控根据监理报告决定是继续下一阶段还是返工甚至修改设计方案。这四层并非总是线性执行而是一个动态的循环。例如评估器发现代码编译失败优化器可能决定让执行器在原步骤重试也可能指示规划器换一种实现思路。3. 环境准备构建你的第一个循环工程实验场我们将使用Python和OpenAI API来构建一个演示系统。选择它们是因为生态成熟、文档丰富但循环工程的思想是模型和框架无关的你可以轻松迁移到 Claude、DeepSeek 或 LangChain 等框架。前置条件Python 3.8 或更高版本。一个有效的 OpenAI API 密钥或其他你选择的 LLM API 密钥。基础的 Python 编程知识。安装依赖我们主要需要openai库来调用模型以及pytest用于后续的自动化评估测试代码。# 创建并进入项目目录 mkdir loop-engineering-demo cd loop-engineering-demo # 创建虚拟环境推荐 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 安装核心依赖 pip install openai pytest项目结构规划一个清晰的结构有助于管理循环中各个组件。loop-engineering-demo/ ├── agents/ # 智能体组件 │ ├── __init__.py │ ├── planner.py # 规划器 │ ├── executor.py # 执行器 │ ├── evaluator.py # 评估器 │ └── optimizer.py # 优化器 ├── tasks/ # 任务定义与上下文 │ └── __init__.py ├── utils/ # 工具函数如API调用 │ └── __init__.py ├── main.py # 主循环入口 └── requirements.txt4. 核心流程拆解实现一个代码生成与验证循环我们以一个实际场景为例“生成一个Python函数计算斐波那契数列的第n项并确保生成的代码可通过单元测试。”这个任务看似简单但用一次性提示词模型可能会生成忽略边界条件n0的代码或者使用低效的递归实现。我们将用循环工程来保证代码质量。4.1 第一步实现规划器Planner规划器的输入是用户原始任务输出是一个步骤计划。对于代码生成任务计划可以相对固定。# agents/planner.py class CodeGenerationPlanner: 针对代码生成任务的简单规划器 def plan(self, task_description: str) - list: 为代码生成任务制定计划。 计划步骤 1. 理解需求确定函数签名和边界条件。 2. 生成初始代码实现。 3. 对生成的代码进行静态检查可选本例中由评估器完成。 4. 运行单元测试验证功能。 plan_steps [ { step_id: 1, action: clarify_requirements, description: 分析任务需求明确函数输入、输出、边界条件和复杂度要求。 }, { step_id: 2, action: generate_initial_code, description: 根据澄清后的需求生成初始的Python函数代码。 }, { step_id: 3, action: static_analysis, description: 对生成的代码进行初步评估如语法、是否存在明显错误。 }, { step_id: 4, action: run_unit_tests, description: 编写并运行单元测试验证代码功能是否正确。 } ] print(f[Planner] 为任务 {task_description} 生成计划共 {len(plan_steps)} 个步骤。) return plan_steps这个规划器目前是静态的。更高级的规划器可以根据任务类型动态生成步骤甚至调用LLM来分析任务并制定计划。4.2 第二步实现执行器Executor执行器负责执行计划中的每一个“动作”。这里的关键是区分不同类型的动作并调用相应的处理器。# agents/executor.py import openai import os from typing import Dict, Any class CodeGenerationExecutor: 代码生成任务的执行器 def __init__(self, api_key: str None): self.client openai.OpenAI(api_keyapi_key or os.getenv(OPENAI_API_KEY)) self.model gpt-3.5-turbo # 可根据需要切换为 gpt-4 def execute(self, step: Dict[str, Any], context: Dict[str, Any]) - Dict[str, Any]: 执行单个步骤并更新上下文 action step.get(action) result {success: False, output: None, error: None} if action clarify_requirements: result self._clarify_requirements(context.get(original_task)) elif action generate_initial_code: result self._generate_code(context.get(clarified_requirements)) elif action static_analysis: result self._static_analysis(context.get(generated_code)) elif action run_unit_tests: result self._run_tests(context.get(generated_code)) else: result[error] f未知动作: {action} print(f[Executor] 执行步骤 {step[step_id]} ({action}) 结果: {result[success]}) return result def _clarify_requirements(self, task: str) - Dict[str, Any]: 调用LLM澄清需求 try: response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: 你是一个资深的软件工程师擅长精确分析需求。}, {role: user, content: f 请分析以下编程任务并输出一个清晰、无歧义的需求说明。 任务{task} 需求说明需要包含 1. 函数签名包括函数名、参数、返回值类型。 2. 输入参数的边界条件和有效性检查例如n必须是正整数。 3. 期望的时间或空间复杂度如果有。 4. 需要处理的特殊案例例如n0, n1。 请直接输出需求说明不要添加其他解释。 } ], temperature0.1 # 低温度保证输出稳定 ) clarified response.choices[0].message.content return {success: True, output: clarified} except Exception as e: return {success: False, output: None, error: str(e)} def _generate_code(self, requirements: str) - Dict[str, Any]: 根据澄清后的需求生成代码 try: response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: 你是一个Python编程专家编写高效、健壮且符合PEP 8规范的代码。}, {role: user, content: f 请根据以下需求编写一个Python函数 {requirements} 要求 1. 只输出完整的函数代码不要包含任何解释、注释或Markdown代码块标记(如python)。 2. 确保包含必要的输入验证。 3. 为函数和参数起有意义的名字。 } ], temperature0.3 ) code response.choices[0].message.content.strip() # 清理可能的代码块标记 if code.startswith(python): code code[9:] if code.endswith(): code code[:-3] return {success: True, output: code} except Exception as e: return {success: False, output: None, error: str(e)} def _static_analysis(self, code: str) - Dict[str, Any]: 简单的静态分析检查语法和导入 try: # 尝试编译代码检查语法错误 compile(code, string, exec) # 简单检查是否有明显的危险操作这是一个非常基础的示例 dangerous_patterns [os.system, subprocess.run, __import__, eval(] for pattern in dangerous_patterns: if pattern in code: return {success: False, output: None, error: f代码中可能包含危险操作: {pattern}} return {success: True, output: 静态分析通过语法正确未发现明显危险操作。} except SyntaxError as e: return {success: False, output: None, error: f语法错误: {e}} except Exception as e: return {success: False, output: None, error: f静态分析异常: {e}} def _run_tests(self, code: str) - Dict[str, Any]: 动态执行测试在实际项目中应更安全地隔离执行 # 这是一个简化的演示。生产环境应使用沙箱。 try: # 动态创建测试模块 test_module_code f {code} def test_fibonacci(): \\\测试生成的斐波那契函数\\\ # 测试正常情况 assert fibonacci(1) 1 assert fibonacci(2) 1 assert fibonacci(3) 2 assert fibonacci(10) 55 # 测试边界/错误情况 assert fibonacci(0) 0 # 通常定义 fib(0) 0 try: fibonacci(-1) assert False, 应抛出异常 except ValueError: pass try: fibonacci(1.5) assert False, 应抛出异常 except ValueError: pass print(所有测试通过) # 在一个新的命名空间中执行代码 namespace {} exec(test_module_code, namespace) # 运行测试 namespace[test_fibonacci]() return {success: True, output: 单元测试全部通过。} except AssertionError as e: return {success: False, output: None, error: f测试失败: {e}} except Exception as e: return {success: False, output: None, error: f运行测试时异常: {e}}4.3 第三步实现评估器Evaluator评估器需要客观判断执行结果的好坏。在我们的场景中_run_tests本身已经是一种评估。但我们还可以有一个更通用的评估器用于评估“需求澄清”和“代码生成”步骤的输出质量。# agents/evaluator.py import re class CodeGenerationEvaluator: 评估代码生成各阶段产出的质量 def evaluate(self, step_action: str, result: Dict[str, Any], context: Dict[str, Any]) - Dict[str, Any]: 评估单个步骤的执行结果 evaluation {score: 0, passed: False, feedback: } if step_action clarify_requirements: evaluation self._evaluate_requirements(result.get(output, )) elif step_action generate_initial_code: evaluation self._evaluate_generated_code(result.get(output, )) elif step_action in [static_analysis, run_unit_tests]: # 这些步骤的成功与否已由执行器直接给出 evaluation[passed] result.get(success, False) evaluation[feedback] result.get(output) or result.get(error, 未知结果) evaluation[score] 100 if evaluation[passed] else 0 else: evaluation[feedback] f未知步骤类型: {step_action} print(f[Evaluator] 评估步骤 {step_action} 通过: {evaluation[passed]}) return evaluation def _evaluate_requirements(self, requirements_text: str) - Dict[str, Any]: 评估需求澄清的完整性 if not requirements_text: return {score: 0, passed: False, feedback: 需求澄清输出为空} criteria [ (函数签名, rdef\s\w\s*\(|函数名.*参数), (边界条件, r边界|有效.*性|检查|验证), (特殊案例, rn\s*\s*[01]|特殊|案例), ] score 0 feedback_parts [] for name, pattern in criteria: if re.search(pattern, requirements_text, re.IGNORECASE): score 25 feedback_parts.append(f包含{name}) else: feedback_parts.append(f缺失{name}) passed score 75 # 至少满足3条标准 return { score: score, passed: passed, feedback: f需求澄清评估: {, .join(feedback_parts)}. 总分: {score} } def _evaluate_generated_code(self, code: str) - Dict[str, Any]: 评估生成代码的基本质量 if not code: return {score: 0, passed: False, feedback: 生成的代码为空} criteria [ (包含函数定义, rdef\s\w\s*\(), (包含输入验证, rif.*raise|assert|try.*except|isinstance), (有返回值, rreturn\s), ] score 0 feedback_parts [] for name, pattern in criteria: if re.search(pattern, code, re.MULTILINE): score 30 feedback_parts.append(f包含{name}) else: feedback_parts.append(f缺失{name}) # 检查代码长度避免过于简单或复杂 lines code.strip().split(\n) if 5 len(lines) 50: score 10 feedback_parts.append(代码长度适中) else: feedback_parts.append(代码长度可能不合适) passed score 70 return { score: min(score, 100), passed: passed, feedback: f代码质量评估: {, .join(feedback_parts)}. 总分: {score} }4.4 第四步实现优化器Optimizer优化器是循环的大脑它根据评估结果决定下一步做什么继续、重试当前步骤、回退到上一步还是彻底失败。# agents/optimizer.py from typing import Dict, Any, List class SimpleOptimizer: 一个基于规则的简单优化器 def decide_next_action(self, current_step: Dict[str, Any], step_result: Dict[str, Any], step_evaluation: Dict[str, Any], execution_history: List[Dict[str, Any]]) - Dict[str, Any]: 决定下一步动作。 返回一个动作指令例如 - {action: proceed, next_step_id: X} # 继续下一步 - {action: retry, retry_step_id: X, feedback: ...} # 重试当前步骤 - {action: rollback, rollback_to_step_id: X} # 回退到某一步 - {action: fail, reason: ...} # 终止任务 step_id current_step.get(step_id) step_action current_step.get(action) # 规则1如果执行器本身失败如网络错误直接重试最多3次 if not step_result.get(success, False): retry_count self._count_retries(execution_history, step_id) if retry_count 3: print(f[Optimizer] 步骤{step_id}执行失败准备重试 (第{retry_count 1}次)。原因: {step_result.get(error)}) return { action: retry, retry_step_id: step_id, feedback: f执行失败请重试。错误信息: {step_result.get(error)} } else: print(f[Optimizer] 步骤{step_id}重试超过3次任务失败。) return {action: fail, reason: f步骤{step_id}多次执行失败} # 规则2如果评估未通过根据步骤类型决定 if not step_evaluation.get(passed, False): # 对于“需求澄清”和“生成代码”步骤提供反馈并重试 if step_action in [clarify_requirements, generate_initial_code]: retry_count self._count_retries(execution_history, step_id, only_failedTrue) if retry_count 2: # 最多重试2次 print(f[Optimizer] 步骤{step_id}评估未通过准备重试。反馈: {step_evaluation.get(feedback)}) return { action: retry, retry_step_id: step_id, feedback: step_evaluation.get(feedback, 评估未通过请改进。) } else: # 重试多次仍失败可能需要回退到上一步或失败 if step_action generate_initial_code: # 代码生成失败回退到需求澄清重新开始 print(f[Optimizer] 代码生成多次失败回退到需求澄清步骤。) return {action: rollback, rollback_to_step_id: 1} else: return {action: fail, reason: f步骤{step_id}多次评估未通过} # 对于“静态分析”和“单元测试”步骤失败即终止 else: print(f[Optimizer] 关键验证步骤{step_id}失败任务终止。) return {action: fail, reason: f关键验证步骤{step_id}失败: {step_evaluation.get(feedback)}} # 规则3一切正常继续下一步 print(f[Optimizer] 步骤{step_id}成功继续下一步。) return {action: proceed, next_step_id: step_id 1} def _count_retries(self, history: List[Dict], step_id: int, only_failed: bool False) - int: 计算某个步骤的重试次数 count 0 for record in history: if record.get(step_id) step_id: if only_failed: if not record.get(evaluation, {}).get(passed, True): count 1 else: count 1 return max(0, count - 1) # 减去第一次执行4.5 第五步组装主循环Main Loop现在我们将所有组件串联起来形成完整的自治循环。# main.py import os from agents.planner import CodeGenerationPlanner from agents.executor import CodeGenerationExecutor from agents.evaluator import CodeGenerationEvaluator from agents.optimizer import SimpleOptimizer class CodeGenerationLoop: 代码生成任务的主循环 def __init__(self, api_key: str): self.planner CodeGenerationPlanner() self.executor CodeGenerationExecutor(api_key) self.evaluator CodeGenerationEvaluator() self.optimizer SimpleOptimizer() self.execution_history [] # 记录每一步的执行历史 def run(self, task: str, max_iterations: int 20): 运行主循环 print(f 开始处理任务: {task} ) # 1. 规划 plan self.planner.plan(task) context {original_task: task} current_step_index 0 iteration 0 while current_step_index len(plan) and iteration max_iterations: iteration 1 print(f\n--- 迭代 {iteration}, 执行步骤 {current_step_index 1} ---) current_step plan[current_step_index] # 2. 执行 step_result self.executor.execute(current_step, context) # 3. 评估 step_evaluation self.evaluator.evaluate( current_step[action], step_result, context ) # 记录历史 history_record { iteration: iteration, step_id: current_step[step_id], step_action: current_step[action], result: step_result, evaluation: step_evaluation, context_snapshot: context.copy() } self.execution_history.append(history_record) # 4. 优化决策 decision self.optimizer.decide_next_action( current_step, step_result, step_evaluation, self.execution_history ) # 5. 处理决策 if decision[action] proceed: # 更新上下文继续下一步 if step_result[success] and step_result[output]: context_key self._get_context_key(current_step[action]) context[context_key] step_result[output] current_step_index decision.get(next_step_id, current_step_index 1) elif decision[action] retry: # 重试当前步骤反馈信息会通过context传递给执行器在更复杂的实现中 feedback decision.get(feedback, ) print(f重试反馈: {feedback}) # 当前简单实现中我们只是循环重试更高级的实现会修改context或提示词 continue # 不增加current_step_index下次循环仍执行本步骤 elif decision[action] rollback: # 回退到指定步骤 rollback_to_id decision[rollback_to_step_id] # 找到要回退到的步骤索引 for i, step in enumerate(plan): if step[step_id] rollback_to_id: current_step_index i print(f回退到步骤 {rollback_to_id}) # 可以清理回退点之后的context keys_to_remove [] for key in context.keys(): if key not in [original_task]: keys_to_remove.append(key) for key in keys_to_remove: context.pop(key, None) break continue elif decision[action] fail: print(f任务失败: {decision.get(reason)}) return {status: failed, reason: decision.get(reason), history: self.execution_history} else: print(f未知决策: {decision}) return {status: error, reason: 未知优化决策, history: self.execution_history} # 循环结束检查 if current_step_index len(plan): print(f\n 任务成功完成 ) print(f最终生成的代码:\n{context.get(generated_code, 无)}) return {status: success, final_code: context.get(generated_code), history: self.execution_history} else: print(f\n 达到最大迭代次数 {max_iterations}任务未完成 ) return {status: timeout, history: self.execution_history} def _get_context_key(self, action: str) - str: 根据动作类型映射到context中的键名 mapping { clarify_requirements: clarified_requirements, generate_initial_code: generated_code, static_analysis: static_analysis_result, run_unit_tests: test_result } return mapping.get(action, action) if __name__ __main__: # 设置你的OpenAI API Key api_key os.getenv(OPENAI_API_KEY) # 建议通过环境变量设置 if not api_key: # 仅为演示生产环境切勿硬编码密钥 api_key your-api-key-here # 请替换为你的实际密钥或使用环境变量 loop CodeGenerationLoop(api_key) # 定义任务 task 编写一个Python函数计算斐波那契数列的第n项。要求处理非正整数输入并考虑性能。 # 运行循环 final_result loop.run(task) # 打印简要总结 print(f\n最终状态: {final_result[status]}) if final_result[status] success: print(成功生成并通过测试的代码已保存在上下文中。)5. 运行结果与效果验证如何运行将上述所有代码文件按项目结构保存。在main.py中设置你的 OpenAI API 密钥强烈建议通过环境变量OPENAI_API_KEY设置。在项目根目录下运行python main.py预期输出你将看到控制台打印出循环的每一步执行过程类似于 开始处理任务: 编写一个Python函数计算斐波那契数列的第n项... [Planner] 为任务 ... 生成计划共 4 个步骤。 --- 迭代 1, 执行步骤 1 --- [Executor] 执行步骤 1 (clarify_requirements) 结果: True [Evaluator] 评估步骤 clarify_requirements 通过: True [Optimizer] 步骤1成功继续下一步。 --- 迭代 2, 执行步骤 2 --- [Executor] 执行步骤 2 (generate_initial_code) 结果: True [Evaluator] 评估步骤 generate_initial_code 通过: True [Optimizer] 步骤2成功继续下一步。 ... 任务成功完成 最终生成的代码: def fibonacci(n: int) - int: if not isinstance(n, int): raise ValueError(Input must be an integer) if n 0: raise ValueError(Input must be a non-negative integer) if n 0: return 0 elif n 1: return 1 a, b 0, 1 for _ in range(2, n 1): a, b b, a b return b效果验证自动化整个过程无需人工干预系统自动完成了需求澄清、代码生成、静态检查、测试验证。健壮性如果生成的代码第一次测试失败优化器会触发重试或回退机制。可追溯性execution_history记录了完整的决策和执行链路便于调试和复盘。6. 常见问题与排查思路在实际运行中你可能会遇到以下问题问题现象可能原因排查方式解决方案API调用失败网络问题、API密钥无效、额度不足。检查step_result中的error字段查看OpenAI返回的具体错误信息。1. 验证API密钥和环境变量。2. 检查网络连接。3. 在OpenAI后台查看额度与账单。循环卡在重试评估标准过于严格或LLM生成能力达到瓶颈始终无法产出合格结果。查看execution_history分析是哪个步骤反复失败以及评估器的反馈。1. 调整评估器evaluator.py的通过阈值。2. 为执行器executor.py的LLM调用提供更详细的反馈feedback参数。3. 设置合理的最大重试次数避免无限循环。生成的代码有安全风险提示词约束不足模型可能生成包含危险操作如os.system的代码。检查执行器中_static_analysis方法的日志。1. 强化静态分析规则。2. 在系统提示词中明确禁止危险操作。最重要永远不要在无沙箱的环境中外执行不可信的AI生成代码。单元测试逻辑错误测试用例本身可能有误或与模型对需求的理解不一致。手动检查_run_tests方法中嵌入的测试逻辑。1. 将测试用例设计得更清晰、无歧义。2. 可以考虑让LLM也参与生成测试用例但需额外循环验证。上下文管理混乱回退rollback后上下文清理不干净导致后续步骤使用了过期数据。打印每个步骤开始前的context内容。优化_get_context_key映射和回退时的上下文清理逻辑确保状态一致性。7. 最佳实践与工程建议将循环工程应用到生产环境需要注意以下要点1. 设计可观测性Observability结构化日志不要只使用print集成像logging或structlog这样的库将每一步的输入、输出、评估结果、决策原因记录到文件或监控系统。可视化流水线对于复杂循环可以考虑将execution_history输出为JSON或可视化图表方便复盘分析瓶颈所在。2. 实现安全的代码执行示例中的exec()是极不安全的仅用于演示。生产环境必须使用沙箱Sandbox例如 Docker 容器、pysandbox、或专门的安全代码执行服务如 AWS Lambda, Google Cloud Functions严格限制网络、文件系统和系统调用。3. 优化提示词与上下文管理循环中每次调用LLM的提示词都应包含历史反馈。示例中简化了这一点你需要将优化器提供的feedback传递给执行器并构造到下一次LLM调用的消息中。避免上下文膨胀。定期总结或过滤历史信息只保留对当前步骤最关键的部分。4. 评估器的多元化与分层不要只依赖一种评估方式。结合使用规则评估如代码风格、语法。模型评估用另一个LLM给输出打分。工具评估编译器、测试框架、静态分析工具。人工评估对于关键任务设置人工审核环节。实施分层评估先进行快速、低成本的检查如语法通过后再进行高成本检查如运行测试。5. 设定明确的终止条件除了最大迭代次数还应设定质量阈值和成本预算。例如当评估分数连续三次无法提升时应提前终止而不是无意义重试。6. 模块化与可扩展性将规划器、执行器、评估器、优化器设计为插件化接口。这样你可以轻松更换不同的LLM提供商、测试框架或决策算法。定义清晰的数据交换格式context确保各组件之间松耦合。8. 总结与后续学习方向循环工程不是要完全抛弃提示词而是将“如何与模型沟通”这个单一问题升级为“如何设计一个能自动与模型协作并解决问题的系统”。它带来的最大转变是从追求一次性完美的“咒语”转变为构建一个容错、可进化的工作流。通过本文的实践你已经掌握了循环工程的核心架构与实现方法。你可以在此基础上进行扩展更智能的规划器尝试用LLM本身来动态分解复杂任务而不是使用静态计划。多工具执行器让执行器不仅能调用LLM还能调用搜索引擎、数据库、API等外部工具构建更强大的智能体Agent。学习型优化器引入强化学习RL或贝叶斯优化让优化器能从历史任务中学习自动调整重试策略或提示词。应用于其他领域将本框架应用于文本摘要、数据清洗、报告生成等任何需要多次LLM调用的场景。提示词作为“启动指令”依然重要但循环工程才是让AI智能体可靠完成复杂任务的“自动驾驶系统”。开始用循环的思维去设计你的下一个AI应用你会发现可控性和可靠性将得到质的提升。
循环工程：构建AI大模型自动化反馈系统，告别提示词赌博
如果你还在为 AI 大模型生成的内容“不听话”而烦恼——比如让它写个代码它却给你一堆注释让它分析数据它却开始写诗——那么你很可能已经掉进了“一次性提示词”的陷阱。“提示词已死”这个说法并非要否定提示词的价值而是宣告了一种更高效、更可靠的工程化思维正在成为主流循环工程。过去我们习惯于精心雕琢一个“完美”的提示词然后祈祷模型能一次给出正确答案。这就像把需求一次性扔给一个实习生然后指望他交出一份完美的报告结果往往需要反复沟通、打回重做。循环工程的核心思想正是将这种“反复沟通”的过程自动化、系统化。它不再依赖单次“魔法咒语”而是构建一个可迭代、可评估、可优化的反馈循环系统。对于开发者而言这意味着从“玄学调参”转向“工程化构建”从“碰运气”转向“可预期”。本文将为你彻底拆解循环工程。你将了解到为什么“完美提示词”是个伪命题以及循环工程如何从根本上解决LLM应用的不确定性。循环工程的完整架构与核心组件包括规划器、执行器、评估器和优化器。一个从零搭建的、可运行的代码示例手把手教你实现一个用于代码生成的智能循环系统。在实际项目中落地循环工程的最佳实践与避坑指南帮你节省大量调试时间。无论你是想构建一个稳定的AI辅助编程工具还是希望将大模型更可靠地集成到你的数据分析、内容创作流程中理解并应用循环工程都将是你从“玩具演示”走向“生产级应用”的关键一步。1. 循环工程要解决的根本问题告别“提示词赌博”在深入技术细节之前我们必须先理解问题的本质。传统的提示词工程Prompt Engineering为什么在复杂任务中常常失灵痛点一单次交互的“黑盒”与不确定性。你给模型一个复杂的任务描述它返回一个结果。这个结果可能很好也可能完全跑偏。你无法在单次交互中了解模型的“思考过程”更无法中途纠正。这导致调试成本极高你只能不断修改提示词进行大量“A/B测试”效率低下。痛点二缺乏状态与记忆。一次对话结束后上下文就消失了。如果你想基于上一个结果进行细化或修正必须把整个历史对话都塞进新的提示词中不仅消耗大量Token而且随着上下文窗口变长模型性能还会下降。真正的复杂任务往往是多步骤、有状态的。痛点三评估与优化的闭环缺失。如何判断模型输出的好坏传统方式靠人眼判断。但对于批量任务或需要客观标准如代码能否编译、答案是否准确的场景人工评估不可扩展。没有自动化的评估就无法实现自动化的优化。循环工程的破局思路它将一次性的“祈祷式”交互拆解为一个可管理的工作流Workflow规划Plan将大任务分解为可执行的子步骤。执行Execute调用模型或工具完成每个子步骤。评估Evaluate用预设标准自动检查结果质量。优化Optimize根据评估结果调整策略或重试。这个循环可以自动运行多次直到产出满足质量要求或达到重试上限。这本质上是在用系统的确定性去对抗模型输出的不确定性。2. 核心概念循环工程的四层架构一个完整的循环工程系统通常包含以下四个核心层它们共同构成了一个自治的智能体Agent系统。层级组件核心职责类比控制层规划器 (Planner)任务分解、步骤规划、策略选择。相当于项目的“项目经理”或“架构师”。接到“建一座桥”的任务先画出设计图、列出材料清单、安排施工顺序。执行层执行器 (Executor)具体执行规划器制定的每一步操作。可以是调用LLM生成文本也可以是调用API、运行代码等工具。施工队按照图纸进行打桩、浇筑混凝土等具体操作。评估层评估器 (Evaluator)对执行器的产出进行质量评估。可以是规则匹配、模型打分、代码测试等。监理工程师检查混凝土强度、桥面平整度是否达标。优化层优化器 (Optimizer)根据评估结果决定下一步动作继续、重试、回退还是终止。并可能调整规划器的策略。项目总控根据监理报告决定是继续下一阶段还是返工甚至修改设计方案。这四层并非总是线性执行而是一个动态的循环。例如评估器发现代码编译失败优化器可能决定让执行器在原步骤重试也可能指示规划器换一种实现思路。3. 环境准备构建你的第一个循环工程实验场我们将使用Python和OpenAI API来构建一个演示系统。选择它们是因为生态成熟、文档丰富但循环工程的思想是模型和框架无关的你可以轻松迁移到 Claude、DeepSeek 或 LangChain 等框架。前置条件Python 3.8 或更高版本。一个有效的 OpenAI API 密钥或其他你选择的 LLM API 密钥。基础的 Python 编程知识。安装依赖我们主要需要openai库来调用模型以及pytest用于后续的自动化评估测试代码。# 创建并进入项目目录 mkdir loop-engineering-demo cd loop-engineering-demo # 创建虚拟环境推荐 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 安装核心依赖 pip install openai pytest项目结构规划一个清晰的结构有助于管理循环中各个组件。loop-engineering-demo/ ├── agents/ # 智能体组件 │ ├── __init__.py │ ├── planner.py # 规划器 │ ├── executor.py # 执行器 │ ├── evaluator.py # 评估器 │ └── optimizer.py # 优化器 ├── tasks/ # 任务定义与上下文 │ └── __init__.py ├── utils/ # 工具函数如API调用 │ └── __init__.py ├── main.py # 主循环入口 └── requirements.txt4. 核心流程拆解实现一个代码生成与验证循环我们以一个实际场景为例“生成一个Python函数计算斐波那契数列的第n项并确保生成的代码可通过单元测试。”这个任务看似简单但用一次性提示词模型可能会生成忽略边界条件n0的代码或者使用低效的递归实现。我们将用循环工程来保证代码质量。4.1 第一步实现规划器Planner规划器的输入是用户原始任务输出是一个步骤计划。对于代码生成任务计划可以相对固定。# agents/planner.py class CodeGenerationPlanner: 针对代码生成任务的简单规划器 def plan(self, task_description: str) - list: 为代码生成任务制定计划。 计划步骤 1. 理解需求确定函数签名和边界条件。 2. 生成初始代码实现。 3. 对生成的代码进行静态检查可选本例中由评估器完成。 4. 运行单元测试验证功能。 plan_steps [ { step_id: 1, action: clarify_requirements, description: 分析任务需求明确函数输入、输出、边界条件和复杂度要求。 }, { step_id: 2, action: generate_initial_code, description: 根据澄清后的需求生成初始的Python函数代码。 }, { step_id: 3, action: static_analysis, description: 对生成的代码进行初步评估如语法、是否存在明显错误。 }, { step_id: 4, action: run_unit_tests, description: 编写并运行单元测试验证代码功能是否正确。 } ] print(f[Planner] 为任务 {task_description} 生成计划共 {len(plan_steps)} 个步骤。) return plan_steps这个规划器目前是静态的。更高级的规划器可以根据任务类型动态生成步骤甚至调用LLM来分析任务并制定计划。4.2 第二步实现执行器Executor执行器负责执行计划中的每一个“动作”。这里的关键是区分不同类型的动作并调用相应的处理器。# agents/executor.py import openai import os from typing import Dict, Any class CodeGenerationExecutor: 代码生成任务的执行器 def __init__(self, api_key: str None): self.client openai.OpenAI(api_keyapi_key or os.getenv(OPENAI_API_KEY)) self.model gpt-3.5-turbo # 可根据需要切换为 gpt-4 def execute(self, step: Dict[str, Any], context: Dict[str, Any]) - Dict[str, Any]: 执行单个步骤并更新上下文 action step.get(action) result {success: False, output: None, error: None} if action clarify_requirements: result self._clarify_requirements(context.get(original_task)) elif action generate_initial_code: result self._generate_code(context.get(clarified_requirements)) elif action static_analysis: result self._static_analysis(context.get(generated_code)) elif action run_unit_tests: result self._run_tests(context.get(generated_code)) else: result[error] f未知动作: {action} print(f[Executor] 执行步骤 {step[step_id]} ({action}) 结果: {result[success]}) return result def _clarify_requirements(self, task: str) - Dict[str, Any]: 调用LLM澄清需求 try: response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: 你是一个资深的软件工程师擅长精确分析需求。}, {role: user, content: f 请分析以下编程任务并输出一个清晰、无歧义的需求说明。 任务{task} 需求说明需要包含 1. 函数签名包括函数名、参数、返回值类型。 2. 输入参数的边界条件和有效性检查例如n必须是正整数。 3. 期望的时间或空间复杂度如果有。 4. 需要处理的特殊案例例如n0, n1。 请直接输出需求说明不要添加其他解释。 } ], temperature0.1 # 低温度保证输出稳定 ) clarified response.choices[0].message.content return {success: True, output: clarified} except Exception as e: return {success: False, output: None, error: str(e)} def _generate_code(self, requirements: str) - Dict[str, Any]: 根据澄清后的需求生成代码 try: response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: 你是一个Python编程专家编写高效、健壮且符合PEP 8规范的代码。}, {role: user, content: f 请根据以下需求编写一个Python函数 {requirements} 要求 1. 只输出完整的函数代码不要包含任何解释、注释或Markdown代码块标记(如python)。 2. 确保包含必要的输入验证。 3. 为函数和参数起有意义的名字。 } ], temperature0.3 ) code response.choices[0].message.content.strip() # 清理可能的代码块标记 if code.startswith(python): code code[9:] if code.endswith(): code code[:-3] return {success: True, output: code} except Exception as e: return {success: False, output: None, error: str(e)} def _static_analysis(self, code: str) - Dict[str, Any]: 简单的静态分析检查语法和导入 try: # 尝试编译代码检查语法错误 compile(code, string, exec) # 简单检查是否有明显的危险操作这是一个非常基础的示例 dangerous_patterns [os.system, subprocess.run, __import__, eval(] for pattern in dangerous_patterns: if pattern in code: return {success: False, output: None, error: f代码中可能包含危险操作: {pattern}} return {success: True, output: 静态分析通过语法正确未发现明显危险操作。} except SyntaxError as e: return {success: False, output: None, error: f语法错误: {e}} except Exception as e: return {success: False, output: None, error: f静态分析异常: {e}} def _run_tests(self, code: str) - Dict[str, Any]: 动态执行测试在实际项目中应更安全地隔离执行 # 这是一个简化的演示。生产环境应使用沙箱。 try: # 动态创建测试模块 test_module_code f {code} def test_fibonacci(): \\\测试生成的斐波那契函数\\\ # 测试正常情况 assert fibonacci(1) 1 assert fibonacci(2) 1 assert fibonacci(3) 2 assert fibonacci(10) 55 # 测试边界/错误情况 assert fibonacci(0) 0 # 通常定义 fib(0) 0 try: fibonacci(-1) assert False, 应抛出异常 except ValueError: pass try: fibonacci(1.5) assert False, 应抛出异常 except ValueError: pass print(所有测试通过) # 在一个新的命名空间中执行代码 namespace {} exec(test_module_code, namespace) # 运行测试 namespace[test_fibonacci]() return {success: True, output: 单元测试全部通过。} except AssertionError as e: return {success: False, output: None, error: f测试失败: {e}} except Exception as e: return {success: False, output: None, error: f运行测试时异常: {e}}4.3 第三步实现评估器Evaluator评估器需要客观判断执行结果的好坏。在我们的场景中_run_tests本身已经是一种评估。但我们还可以有一个更通用的评估器用于评估“需求澄清”和“代码生成”步骤的输出质量。# agents/evaluator.py import re class CodeGenerationEvaluator: 评估代码生成各阶段产出的质量 def evaluate(self, step_action: str, result: Dict[str, Any], context: Dict[str, Any]) - Dict[str, Any]: 评估单个步骤的执行结果 evaluation {score: 0, passed: False, feedback: } if step_action clarify_requirements: evaluation self._evaluate_requirements(result.get(output, )) elif step_action generate_initial_code: evaluation self._evaluate_generated_code(result.get(output, )) elif step_action in [static_analysis, run_unit_tests]: # 这些步骤的成功与否已由执行器直接给出 evaluation[passed] result.get(success, False) evaluation[feedback] result.get(output) or result.get(error, 未知结果) evaluation[score] 100 if evaluation[passed] else 0 else: evaluation[feedback] f未知步骤类型: {step_action} print(f[Evaluator] 评估步骤 {step_action} 通过: {evaluation[passed]}) return evaluation def _evaluate_requirements(self, requirements_text: str) - Dict[str, Any]: 评估需求澄清的完整性 if not requirements_text: return {score: 0, passed: False, feedback: 需求澄清输出为空} criteria [ (函数签名, rdef\s\w\s*\(|函数名.*参数), (边界条件, r边界|有效.*性|检查|验证), (特殊案例, rn\s*\s*[01]|特殊|案例), ] score 0 feedback_parts [] for name, pattern in criteria: if re.search(pattern, requirements_text, re.IGNORECASE): score 25 feedback_parts.append(f包含{name}) else: feedback_parts.append(f缺失{name}) passed score 75 # 至少满足3条标准 return { score: score, passed: passed, feedback: f需求澄清评估: {, .join(feedback_parts)}. 总分: {score} } def _evaluate_generated_code(self, code: str) - Dict[str, Any]: 评估生成代码的基本质量 if not code: return {score: 0, passed: False, feedback: 生成的代码为空} criteria [ (包含函数定义, rdef\s\w\s*\(), (包含输入验证, rif.*raise|assert|try.*except|isinstance), (有返回值, rreturn\s), ] score 0 feedback_parts [] for name, pattern in criteria: if re.search(pattern, code, re.MULTILINE): score 30 feedback_parts.append(f包含{name}) else: feedback_parts.append(f缺失{name}) # 检查代码长度避免过于简单或复杂 lines code.strip().split(\n) if 5 len(lines) 50: score 10 feedback_parts.append(代码长度适中) else: feedback_parts.append(代码长度可能不合适) passed score 70 return { score: min(score, 100), passed: passed, feedback: f代码质量评估: {, .join(feedback_parts)}. 总分: {score} }4.4 第四步实现优化器Optimizer优化器是循环的大脑它根据评估结果决定下一步做什么继续、重试当前步骤、回退到上一步还是彻底失败。# agents/optimizer.py from typing import Dict, Any, List class SimpleOptimizer: 一个基于规则的简单优化器 def decide_next_action(self, current_step: Dict[str, Any], step_result: Dict[str, Any], step_evaluation: Dict[str, Any], execution_history: List[Dict[str, Any]]) - Dict[str, Any]: 决定下一步动作。 返回一个动作指令例如 - {action: proceed, next_step_id: X} # 继续下一步 - {action: retry, retry_step_id: X, feedback: ...} # 重试当前步骤 - {action: rollback, rollback_to_step_id: X} # 回退到某一步 - {action: fail, reason: ...} # 终止任务 step_id current_step.get(step_id) step_action current_step.get(action) # 规则1如果执行器本身失败如网络错误直接重试最多3次 if not step_result.get(success, False): retry_count self._count_retries(execution_history, step_id) if retry_count 3: print(f[Optimizer] 步骤{step_id}执行失败准备重试 (第{retry_count 1}次)。原因: {step_result.get(error)}) return { action: retry, retry_step_id: step_id, feedback: f执行失败请重试。错误信息: {step_result.get(error)} } else: print(f[Optimizer] 步骤{step_id}重试超过3次任务失败。) return {action: fail, reason: f步骤{step_id}多次执行失败} # 规则2如果评估未通过根据步骤类型决定 if not step_evaluation.get(passed, False): # 对于“需求澄清”和“生成代码”步骤提供反馈并重试 if step_action in [clarify_requirements, generate_initial_code]: retry_count self._count_retries(execution_history, step_id, only_failedTrue) if retry_count 2: # 最多重试2次 print(f[Optimizer] 步骤{step_id}评估未通过准备重试。反馈: {step_evaluation.get(feedback)}) return { action: retry, retry_step_id: step_id, feedback: step_evaluation.get(feedback, 评估未通过请改进。) } else: # 重试多次仍失败可能需要回退到上一步或失败 if step_action generate_initial_code: # 代码生成失败回退到需求澄清重新开始 print(f[Optimizer] 代码生成多次失败回退到需求澄清步骤。) return {action: rollback, rollback_to_step_id: 1} else: return {action: fail, reason: f步骤{step_id}多次评估未通过} # 对于“静态分析”和“单元测试”步骤失败即终止 else: print(f[Optimizer] 关键验证步骤{step_id}失败任务终止。) return {action: fail, reason: f关键验证步骤{step_id}失败: {step_evaluation.get(feedback)}} # 规则3一切正常继续下一步 print(f[Optimizer] 步骤{step_id}成功继续下一步。) return {action: proceed, next_step_id: step_id 1} def _count_retries(self, history: List[Dict], step_id: int, only_failed: bool False) - int: 计算某个步骤的重试次数 count 0 for record in history: if record.get(step_id) step_id: if only_failed: if not record.get(evaluation, {}).get(passed, True): count 1 else: count 1 return max(0, count - 1) # 减去第一次执行4.5 第五步组装主循环Main Loop现在我们将所有组件串联起来形成完整的自治循环。# main.py import os from agents.planner import CodeGenerationPlanner from agents.executor import CodeGenerationExecutor from agents.evaluator import CodeGenerationEvaluator from agents.optimizer import SimpleOptimizer class CodeGenerationLoop: 代码生成任务的主循环 def __init__(self, api_key: str): self.planner CodeGenerationPlanner() self.executor CodeGenerationExecutor(api_key) self.evaluator CodeGenerationEvaluator() self.optimizer SimpleOptimizer() self.execution_history [] # 记录每一步的执行历史 def run(self, task: str, max_iterations: int 20): 运行主循环 print(f 开始处理任务: {task} ) # 1. 规划 plan self.planner.plan(task) context {original_task: task} current_step_index 0 iteration 0 while current_step_index len(plan) and iteration max_iterations: iteration 1 print(f\n--- 迭代 {iteration}, 执行步骤 {current_step_index 1} ---) current_step plan[current_step_index] # 2. 执行 step_result self.executor.execute(current_step, context) # 3. 评估 step_evaluation self.evaluator.evaluate( current_step[action], step_result, context ) # 记录历史 history_record { iteration: iteration, step_id: current_step[step_id], step_action: current_step[action], result: step_result, evaluation: step_evaluation, context_snapshot: context.copy() } self.execution_history.append(history_record) # 4. 优化决策 decision self.optimizer.decide_next_action( current_step, step_result, step_evaluation, self.execution_history ) # 5. 处理决策 if decision[action] proceed: # 更新上下文继续下一步 if step_result[success] and step_result[output]: context_key self._get_context_key(current_step[action]) context[context_key] step_result[output] current_step_index decision.get(next_step_id, current_step_index 1) elif decision[action] retry: # 重试当前步骤反馈信息会通过context传递给执行器在更复杂的实现中 feedback decision.get(feedback, ) print(f重试反馈: {feedback}) # 当前简单实现中我们只是循环重试更高级的实现会修改context或提示词 continue # 不增加current_step_index下次循环仍执行本步骤 elif decision[action] rollback: # 回退到指定步骤 rollback_to_id decision[rollback_to_step_id] # 找到要回退到的步骤索引 for i, step in enumerate(plan): if step[step_id] rollback_to_id: current_step_index i print(f回退到步骤 {rollback_to_id}) # 可以清理回退点之后的context keys_to_remove [] for key in context.keys(): if key not in [original_task]: keys_to_remove.append(key) for key in keys_to_remove: context.pop(key, None) break continue elif decision[action] fail: print(f任务失败: {decision.get(reason)}) return {status: failed, reason: decision.get(reason), history: self.execution_history} else: print(f未知决策: {decision}) return {status: error, reason: 未知优化决策, history: self.execution_history} # 循环结束检查 if current_step_index len(plan): print(f\n 任务成功完成 ) print(f最终生成的代码:\n{context.get(generated_code, 无)}) return {status: success, final_code: context.get(generated_code), history: self.execution_history} else: print(f\n 达到最大迭代次数 {max_iterations}任务未完成 ) return {status: timeout, history: self.execution_history} def _get_context_key(self, action: str) - str: 根据动作类型映射到context中的键名 mapping { clarify_requirements: clarified_requirements, generate_initial_code: generated_code, static_analysis: static_analysis_result, run_unit_tests: test_result } return mapping.get(action, action) if __name__ __main__: # 设置你的OpenAI API Key api_key os.getenv(OPENAI_API_KEY) # 建议通过环境变量设置 if not api_key: # 仅为演示生产环境切勿硬编码密钥 api_key your-api-key-here # 请替换为你的实际密钥或使用环境变量 loop CodeGenerationLoop(api_key) # 定义任务 task 编写一个Python函数计算斐波那契数列的第n项。要求处理非正整数输入并考虑性能。 # 运行循环 final_result loop.run(task) # 打印简要总结 print(f\n最终状态: {final_result[status]}) if final_result[status] success: print(成功生成并通过测试的代码已保存在上下文中。)5. 运行结果与效果验证如何运行将上述所有代码文件按项目结构保存。在main.py中设置你的 OpenAI API 密钥强烈建议通过环境变量OPENAI_API_KEY设置。在项目根目录下运行python main.py预期输出你将看到控制台打印出循环的每一步执行过程类似于 开始处理任务: 编写一个Python函数计算斐波那契数列的第n项... [Planner] 为任务 ... 生成计划共 4 个步骤。 --- 迭代 1, 执行步骤 1 --- [Executor] 执行步骤 1 (clarify_requirements) 结果: True [Evaluator] 评估步骤 clarify_requirements 通过: True [Optimizer] 步骤1成功继续下一步。 --- 迭代 2, 执行步骤 2 --- [Executor] 执行步骤 2 (generate_initial_code) 结果: True [Evaluator] 评估步骤 generate_initial_code 通过: True [Optimizer] 步骤2成功继续下一步。 ... 任务成功完成 最终生成的代码: def fibonacci(n: int) - int: if not isinstance(n, int): raise ValueError(Input must be an integer) if n 0: raise ValueError(Input must be a non-negative integer) if n 0: return 0 elif n 1: return 1 a, b 0, 1 for _ in range(2, n 1): a, b b, a b return b效果验证自动化整个过程无需人工干预系统自动完成了需求澄清、代码生成、静态检查、测试验证。健壮性如果生成的代码第一次测试失败优化器会触发重试或回退机制。可追溯性execution_history记录了完整的决策和执行链路便于调试和复盘。6. 常见问题与排查思路在实际运行中你可能会遇到以下问题问题现象可能原因排查方式解决方案API调用失败网络问题、API密钥无效、额度不足。检查step_result中的error字段查看OpenAI返回的具体错误信息。1. 验证API密钥和环境变量。2. 检查网络连接。3. 在OpenAI后台查看额度与账单。循环卡在重试评估标准过于严格或LLM生成能力达到瓶颈始终无法产出合格结果。查看execution_history分析是哪个步骤反复失败以及评估器的反馈。1. 调整评估器evaluator.py的通过阈值。2. 为执行器executor.py的LLM调用提供更详细的反馈feedback参数。3. 设置合理的最大重试次数避免无限循环。生成的代码有安全风险提示词约束不足模型可能生成包含危险操作如os.system的代码。检查执行器中_static_analysis方法的日志。1. 强化静态分析规则。2. 在系统提示词中明确禁止危险操作。最重要永远不要在无沙箱的环境中外执行不可信的AI生成代码。单元测试逻辑错误测试用例本身可能有误或与模型对需求的理解不一致。手动检查_run_tests方法中嵌入的测试逻辑。1. 将测试用例设计得更清晰、无歧义。2. 可以考虑让LLM也参与生成测试用例但需额外循环验证。上下文管理混乱回退rollback后上下文清理不干净导致后续步骤使用了过期数据。打印每个步骤开始前的context内容。优化_get_context_key映射和回退时的上下文清理逻辑确保状态一致性。7. 最佳实践与工程建议将循环工程应用到生产环境需要注意以下要点1. 设计可观测性Observability结构化日志不要只使用print集成像logging或structlog这样的库将每一步的输入、输出、评估结果、决策原因记录到文件或监控系统。可视化流水线对于复杂循环可以考虑将execution_history输出为JSON或可视化图表方便复盘分析瓶颈所在。2. 实现安全的代码执行示例中的exec()是极不安全的仅用于演示。生产环境必须使用沙箱Sandbox例如 Docker 容器、pysandbox、或专门的安全代码执行服务如 AWS Lambda, Google Cloud Functions严格限制网络、文件系统和系统调用。3. 优化提示词与上下文管理循环中每次调用LLM的提示词都应包含历史反馈。示例中简化了这一点你需要将优化器提供的feedback传递给执行器并构造到下一次LLM调用的消息中。避免上下文膨胀。定期总结或过滤历史信息只保留对当前步骤最关键的部分。4. 评估器的多元化与分层不要只依赖一种评估方式。结合使用规则评估如代码风格、语法。模型评估用另一个LLM给输出打分。工具评估编译器、测试框架、静态分析工具。人工评估对于关键任务设置人工审核环节。实施分层评估先进行快速、低成本的检查如语法通过后再进行高成本检查如运行测试。5. 设定明确的终止条件除了最大迭代次数还应设定质量阈值和成本预算。例如当评估分数连续三次无法提升时应提前终止而不是无意义重试。6. 模块化与可扩展性将规划器、执行器、评估器、优化器设计为插件化接口。这样你可以轻松更换不同的LLM提供商、测试框架或决策算法。定义清晰的数据交换格式context确保各组件之间松耦合。8. 总结与后续学习方向循环工程不是要完全抛弃提示词而是将“如何与模型沟通”这个单一问题升级为“如何设计一个能自动与模型协作并解决问题的系统”。它带来的最大转变是从追求一次性完美的“咒语”转变为构建一个容错、可进化的工作流。通过本文的实践你已经掌握了循环工程的核心架构与实现方法。你可以在此基础上进行扩展更智能的规划器尝试用LLM本身来动态分解复杂任务而不是使用静态计划。多工具执行器让执行器不仅能调用LLM还能调用搜索引擎、数据库、API等外部工具构建更强大的智能体Agent。学习型优化器引入强化学习RL或贝叶斯优化让优化器能从历史任务中学习自动调整重试策略或提示词。应用于其他领域将本框架应用于文本摘要、数据清洗、报告生成等任何需要多次LLM调用的场景。提示词作为“启动指令”依然重要但循环工程才是让AI智能体可靠完成复杂任务的“自动驾驶系统”。开始用循环的思维去设计你的下一个AI应用你会发现可控性和可靠性将得到质的提升。
