“提示词已死”——这个标题听起来像是一个哗众取宠的宣言但如果你真的在尝试用大模型解决复杂任务比如生成一个完整的项目代码、分析一份几十页的报告或者进行多轮深度对话你很可能已经感受到了它的言外之意。你是否遇到过这样的情况精心设计了一个长达数百字的提示词要求模型“生成一个带用户认证的待办事项应用”结果它要么只给了你一个骨架要么在某个细节上比如密码加密反复出错。你不得不像“甲方”一样在后续对话中不断补充“不对这里要用JWT”“数据库表结构还没给”“前端页面需要响应式”…… 这个过程低效、琐碎且结果不可控。问题的核心在于传统的“单次提示词”范式试图用一份静态的“需求文档”去驱动一个动态的、有状态的智能体Agent。这就像试图用一张静态地图指挥一场实时变化的战役注定力不从心。“循环工程”Loop Engineering正是在这种背景下被提出的新范式。它不是一个具体的工具而是一套方法论和工程实践核心思想是将复杂任务拆解为可循环、可观测、可干预的步骤让AI在“执行-评估-调整”的闭环中自主或半自主地推进直至达成目标。本文将为你彻底拆解“循环工程”。我不会只告诉你概念而是会带你从零开始理解为什么“提示词”在复杂场景下会失效如何构建一个有效的“循环”并通过一个完整的“自动代码生成与迭代”项目实战展示其威力。读完本文你将能理解核心差异清晰把握“提示词工程”与“循环工程”的本质区别与适用场景。掌握设计模式学会设计任务分解、状态管理、评估反馈等核心循环组件。动手实现使用主流的AI应用框架如LangChain搭建一个具备自我迭代能力的代码生成Agent。规避实践陷阱了解在循环中如何设置检查点、防止漂移、控制成本等关键问题。如果你厌倦了与AI进行低效的“拉锯战”渴望构建真正能自动化处理复杂任务的智能工作流那么这篇文章正是为你准备的。1. 为什么说“提示词”在复杂任务中“已死”在讨论新范式之前我们必须先诊断旧范式的“病因”。提示词Prompt Engineering本身并没有错它在定义任务边界、提供上下文、调整输出风格等方面至关重要。但当任务复杂度超越某个阈值时它的局限性就会暴露无遗。局限性一信息过载与上下文遗忘大模型有上下文窗口限制如128K。一个复杂的任务描述、加上历史对话、加上生成的中间内容很容易逼近或超过这个限制。即使窗口足够大模型在生成长文本时也容易出现“遗忘”前半部分指令细节的情况。你需要在同一个提示词里塞进所有要求这本身就是反人性的。局限性二缺乏状态管理与渐进式推理复杂任务本质上是有状态的。上一步的输出是下一步的输入并且可能需要对中间结果进行评估和修正。单次提示词无法维护这个“状态”。你只能通过人工截取、复制、粘贴来模拟状态传递这个过程无法自动化且容易出错。局限性三评估与修正的缺失模型生成的内容质量如何是否符合所有约束条件传统的做法是人眼评估。这导致了两个问题1) 效率瓶颈永远在人这里2) 人的评估标准是主观且不一致的。一个自动化的智能体必须有能力或借助工具对自身产出的中间结果进行质量评估并基于评估进行修正。局限性四僵化的“计划-执行”模式很多高级提示技巧教导我们“让模型先列计划再执行”。这比没有计划好但计划往往是静态的。现实任务中执行一步后获取的新信息可能让原先的计划变得不再最优甚至完全错误。系统需要能够动态调整计划。“循环工程”正是为了克服这些局限性而生。它不再追求“一发入魂”的完美提示词而是承认任务的复杂性并设计一套系统化的流程来管理这种复杂性。2. 循环工程核心概念与设计模式循环工程不是某个特定的API或库它是一种架构思想。其核心是构建一个“感知-思考-行动”的循环并为其配备必要的工具和评估机制。2.1 核心组件一个典型的循环工程系统包含以下关键组件任务分解器Task Decomposer将用户输入的模糊高层目标如“开发一个博客系统”拆解成一系列具体的、可执行的子任务如“设计数据库Schema”、“实现用户注册API”、“编写前端文章列表组件”。这通常由一个大模型驱动。状态管理器State Manager维护整个任务的当前状态。这包括已完成的子任务列表、每个子任务的输入输出、当前的执行上下文、全局的约束条件如技术栈要求等。状态是循环推进的“记忆”。执行器Executor负责执行具体的子任务。它可能是一个调用大模型生成代码的模块也可能是一个调用外部API如执行Shell命令、调用数据库的工具。评估器Evaluator对执行器的输出进行评估。评估可以是规则型检查代码语法调用pylint、运行单元测试调用pytest、检查API规范是否符合OpenAPI。模型型用另一个大模型或同一模型的不同提示评估输出是否满足子任务要求、是否符合代码风格、是否存在安全隐患。控制器Controller/ 调度器Orchestrator这是系统的大脑。它根据当前状态和评估结果决定下一步做什么继续执行下一个子任务还是重新执行当前任务或是调整任务分解计划。2.2 关键设计模式规划-执行-评估-调整PEAS循环这是最基础的循环模式。规划基于当前状态决定下一个动作执行哪个子任务或如何修正。执行执行该动作产生结果。评估评估结果的质量。调整根据评估结果更新状态和后续计划。如果评估失败可能进入“修正”子循环。递归分解Recursive Decomposition任务分解本身也可以被放入循环。控制器发现某个子任务仍然太复杂时可以递归地调用任务分解器将其进一步拆解。工具增强循环Tool-Augmented Loop执行器不仅限于文本生成而是可以调用丰富的工具代码解释器、搜索引擎、文件系统、专业软件API。这让循环能处理真实世界任务。人类在环Human-in-the-Loop在关键决策点如评估结果置信度低、或涉及重大选择将控制权交给人类由人类提供反馈系统再继续运行。这平衡了自动化与可控性。理解了这些概念我们就可以开始动手搭建一个真实的系统了。3. 环境准备构建你的第一个循环工程实验场我们将使用Python和LangChain框架来构建示例。LangChain 提供了丰富的组件来构建Agent和循环工作流。同时我们需要一个强大的大模型作为“大脑”这里选择OpenAI GPT-4或Anthropic Claude 3通过API你也可以使用开源的DeepSeek或Qwen模型。3.1 基础环境与依赖确保你的Python版本在3.8以上。我们创建一个新的虚拟环境并安装核心依赖。# 创建并激活虚拟环境以conda为例 conda create -n loop_engineering python3.10 conda activate loop_engineering # 安装核心库 pip install langchain langchain-openai langchain-community langgraph # LangGraph是LangChain中用于构建有状态、多环节工作流即循环的库 # 可选安装代码执行与评估工具 pip install pytest pylint black # 用于评估生成的代码质量 # 安装Jupyter可选用于交互式实验 pip install jupyter3.2 配置API密钥你需要准备大模型服务的API密钥。这里以OpenAI为例将密钥设置为环境变量。# 在终端中设置临时 export OPENAI_API_KEYyour-api-key-here # 或者在代码中设置 import os os.environ[OPENAI_API_KEY] your-api-key-here如果你使用其他模型如Anthropic或本地部署的Ollama需要安装对应的LangChain集成包并配置相应的环境变量如ANTHROPIC_API_KEY或设置base_url。我们的目标是构建一个自动化的代码生成Agent它能够接收一个相对复杂的项目描述通过循环工程的方式逐步生成、测试并完善代码最终输出一个可运行的项目骨架。4. 实战构建一个自我迭代的代码生成Agent我们将构建一个名为CodeGenAgent的智能体它能够完成“生成一个具有用户登录和文章CRUD功能的Flask博客后端”这个任务。4.1 第一步定义状态与任务分解首先我们需要定义循环中要维护的状态State。我们使用LangGraph的StateGraph和MessagesState来管理。# 文件code_gen_agent.py from typing import TypedDict, List, Annotated import operator from langgraph.graph import StateGraph, END from langchain_core.messages import HumanMessage, SystemMessage, AIMessage from langchain_openai import ChatOpenAI # 1. 定义状态结构 class AgentState(TypedDict): 代理的全局状态 # 消息历史用于记录对话和任务上下文 messages: Annotated[List, operator.add] # 已完成的子任务列表 completed_tasks: List[str] # 当前聚焦的子任务 current_task: str # 生成的代码片段字典key为文件名value为代码内容 generated_code: dict # 任务执行结果或错误信息 task_result: str # 整体项目描述 project_description: str # 2. 初始化大模型 llm ChatOpenAI(modelgpt-4-turbo-preview, temperature0.1) # temperature调低使输出更稳定、可重复 # 3. 系统提示词 - 定义Agent的角色和能力 system_prompt SystemMessage(content你是一个资深的软件开发工程师擅长将复杂需求拆解为具体的开发任务并逐步实现。 你的工作方式是 1. 接收一个项目描述。 2. 将其拆解为一系列具体的、可顺序执行的开发子任务。 3. 针对每个子任务生成高质量、可运行的代码。 4. 在生成代码后会有一个评估步骤来检查代码质量。 5. 根据评估结果决定是继续下一个任务还是重新生成当前任务的代码。 请严格遵循这个流程。你的输出必须是结构化的便于程序解析。)4.2 第二步创建节点Node—— 循环中的各个功能模块我们将循环分解为几个核心节点decompose_task分解任务generate_code生成代码evaluate_code评估代码decide_next决策下一步。# 继续在 code_gen_agent.py 中 def decompose_task(state: AgentState): 节点1任务分解。将项目描述拆解为子任务列表。 project_desc state[project_description] # 构建提示词要求模型输出结构化的子任务列表 prompt f 项目描述{project_desc} 请将这个项目拆解为5-8个具体的、可顺序执行的软件开发子任务。 输出格式必须是严格的JSON列表每个元素是一个字符串描述一个子任务。 例如[1. 设计并创建用户表User的SQLAlchemy模型, 2. 实现用户注册的POST API端点] 请确保任务粒度适中一个任务对应一个可独立编码的功能点。 messages [system_prompt, HumanMessage(contentprompt)] # 注意这里我们简单地将历史消息也传入但在实际复杂任务中可能需要更精细的管理 response llm.invoke(messages) # 解析响应这里假设模型返回了有效的JSON字符串 import json try: # 尝试从响应内容中提取JSON部分 content response.content # 简单处理实际应用中可能需要更健壮的解析 if json in content: json_str content.split(json)[1].split()[0].strip() elif in content: json_str content.split()[1].split()[0].strip() else: json_str content.strip() sub_tasks json.loads(json_str) if not isinstance(sub_tasks, list): sub_tasks [解析失败使用默认任务列表] except json.JSONDecodeError: sub_tasks [1. 设置Flask应用基础结构, 2. 配置数据库连接, 3. 创建用户模型, 4. 实现用户注册登录API, 5. 创建文章模型, 6. 实现文章CRUD API, 7. 添加基础路由和错误处理] # 更新状态将子任务列表存入消息历史并设置第一个为当前任务 new_messages state[messages] [AIMessage(contentf任务分解完成。子任务列表{sub_tasks})] return { messages: new_messages, completed_tasks: [], current_task: sub_tasks[0] if sub_tasks else 无任务, generated_code: {}, task_result: , sub_tasks: sub_tasks, # 临时存储也可放入messages project_description: project_desc } def generate_code(state: AgentState): 节点2代码生成。针对当前子任务生成代码。 current_task state[current_task] project_desc state[project_description] completed_tasks state.get(completed_tasks, []) existing_code state.get(generated_code, {}) # 构建上下文告诉模型已经完成了哪些任务生成了哪些代码文件 context f已完成的子任务{completed_tasks}\n\n if existing_code: context 已生成的文件摘要\n for fname, code in existing_code.items(): # 只提供前几行作为上下文避免过长 context f- {fname}: {code[:200]}...\n prompt f 项目整体描述{project_desc} 当前需要完成的子任务{current_task} {context} 请仅为**当前这个子任务**生成必要的代码。输出要求 1. 首先用一句话说明你将为这个任务生成什么文件。 2. 然后以代码块形式输出完整的代码。每个文件一个独立的代码块并标注语言如python。 3. 如果任务涉及多个文件请按顺序生成。 4. 代码必须是完整、可运行的假设依赖已安装并遵循Flask和SQLAlchemy的最佳实践。 5. 确保与已生成代码的兼容性例如导入正确的模型。 messages state[messages] [HumanMessage(contentprompt)] response llm.invoke(messages) # 更新状态记录生成的代码这里简化处理实际需要解析响应提取多个文件 # 我们假设响应内容就是代码将其以当前任务名作为key暂存 new_messages state[messages] [AIMessage(contentf为任务【{current_task}】生成代码\n{response.content})] generated_code state.get(generated_code, {}) generated_code[current_task] response.content return { messages: new_messages, generated_code: generated_code, task_result: 代码生成完成等待评估。 } def evaluate_code(state: AgentState): 节点3代码评估。对刚生成的代码进行基础评估。 current_task state[current_task] generated_code state.get(generated_code, {}).get(current_task, ) if not generated_code: return {task_result: 无代码可评估。} # 评估策略1使用大模型进行逻辑和完整性评估 eval_prompt f 你是一个代码评审专家。请评估以下为任务【{current_task}】生成的代码。 代码 {generated_code[:3000]} # 截断避免过长 请从以下维度评估并给出“PASS”或“FAIL”的结论 1. 语法正确性代码是否有明显的语法错误 2. 任务符合度代码是否直接解决了当前子任务的要求 3. 完整性对于该子任务代码是否提供了关键实现例如是否定义了必要的函数/类 4. 与项目上下文兼容性代码是否可能与其他已生成模块冲突如重复定义 你的输出必须是严格的JSON格式 {{ syntax_check: PASS/FAIL, task_alignment: PASS/FAIL, completeness: PASS/FAIL, compatibility: PASS/FAIL, overall: PASS/FAIL, feedback: 具体的改进建议 }} 如果任何一项为FAIL则overall为FAIL。 eval_messages [HumanMessage(contenteval_prompt)] eval_response llm.invoke(eval_messages) # 解析评估结果 import json try: eval_result json.loads(eval_response.content) overall eval_result.get(overall, FAIL) feedback eval_result.get(feedback, 无反馈) except: overall UNKNOWN feedback 评估解析失败 # 评估策略2可选实际调用pylint或尝试导入进行语法检查更严格 # 此处省略在实际生产系统中强烈建议加入。 result_text f评估结果{overall}。反馈{feedback} new_messages state[messages] [AIMessage(contentf代码评估完成。{result_text})] return { messages: new_messages, task_result: result_text, evaluation: overall # 将评估结果存入状态供决策节点使用 } def decide_next(state: AgentState): 节点4决策下一步。根据评估结果决定是标记完成、重试还是结束。 evaluation state.get(evaluation, UNKNOWN) current_task state[current_task] sub_tasks state.get(sub_tasks, []) completed_tasks state.get(completed_tasks, []) # 决策逻辑 if evaluation PASS: # 当前任务通过标记为完成 completed_tasks.append(current_task) # 寻找下一个未完成的任务 remaining_tasks [t for t in sub_tasks if t not in completed_tasks] if remaining_tasks: next_task remaining_tasks[0] decision continue result_msg f任务【{current_task}】完成。接下来进行【{next_task}】 else: decision end result_msg 所有任务已完成项目生成结束。 else: # 评估失败重试当前任务可设置最大重试次数 decision retry result_msg f任务【{current_task}】评估未通过将重新生成代码。 new_messages state[messages] [AIMessage(contentf决策{result_msg})] update_state { messages: new_messages, completed_tasks: completed_tasks, current_task: next_task if decision continue else current_task, task_result: result_msg, } # 根据决策返回下一个要执行的节点名称 if decision continue: return update_state, generate_code # 继续生成下一个任务的代码 elif decision retry: return update_state, generate_code # 重新生成当前任务的代码 else: # end return update_state, END # 结束循环4.3 第三步组装工作流构建循环图现在我们将这些节点连接起来形成一个有向图定义循环的路径。# 继续在 code_gen_agent.py 中 # 初始化状态图 workflow StateGraph(AgentState) # 添加节点 workflow.add_node(decompose, decompose_task) workflow.add_node(generate, generate_code) workflow.add_node(evaluate, evaluate_code) workflow.add_node(decide, decide_next) # 设置入口点 workflow.set_entry_point(decompose) # 添加边定义流程 workflow.add_edge(decompose, generate) # 分解后直接生成第一个任务的代码 workflow.add_edge(generate, evaluate) # 生成后进行评估 workflow.add_edge(evaluate, decide) # 评估后进行决策 # decide节点返回下一个节点名所以这里用条件边 # 但LangGraph更优雅的方式是让decide节点返回next字段这里我们简化处理。 # 我们修改一下decide_next函数使其返回一个包含next键的字典。 # 为了简化示例我们调整上面的decide_next函数并改用条件边。 # 修改后的decide_next函数修正版 def decide_next_conditional(state: AgentState): 决策节点返回一个包含next键的字典指示下一步去哪个节点 evaluation state.get(evaluation, UNKNOWN) current_task state[current_task] sub_tasks state.get(sub_tasks, []) completed_tasks state.get(completed_tasks, []) if evaluation PASS: completed_tasks.append(current_task) remaining_tasks [t for t in sub_tasks if t not in completed_tasks] if remaining_tasks: next_task remaining_tasks[0] result_msg f任务【{current_task}】完成。接下来进行【{next_task}】 # 更新状态并指示下一步去generate节点但任务已更新 update_state { messages: state[messages] [AIMessage(contentresult_msg)], completed_tasks: completed_tasks, current_task: next_task, task_result: result_msg, } return {**update_state, next: generate} else: result_msg 所有任务已完成 update_state { messages: state[messages] [AIMessage(contentresult_msg)], task_result: result_msg, } return {**update_state, next: END} else: result_msg f任务【{current_task}】评估未通过将重新生成。 update_state { messages: state[messages] [AIMessage(contentresult_msg)], task_result: result_msg, } return {**update_state, next: generate} # 重试 # 更新节点 workflow.add_node(decide, decide_next_conditional) # 重新定义边decide节点后根据其返回的next值动态路由 workflow.add_conditional_edges( decide, # 路由函数从状态中取出next字段的值 lambda state: state.get(next, generate), { generate: generate, END: END } ) # 编译工作流 app workflow.compile()4.4 第四步运行与观察循环现在让我们运行这个Agent观察它如何循环工作。# 文件run_agent.py from code_gen_agent import app # 假设上面的代码保存在code_gen_agent.py from langchain_core.messages import HumanMessage # 1. 定义初始状态 initial_state { messages: [HumanMessage(content开始项目)], completed_tasks: [], current_task: , generated_code: {}, task_result: , project_description: 开发一个简单的Flask博客后端需要包含用户注册、登录使用JWT、以及文章的创建、读取、更新、删除CRUD功能。使用SQLAlchemy作为ORMSQLite作为数据库。, sub_tasks: [], # 初始为空由分解节点填充 evaluation: , next: # 用于路由 } # 2. 运行工作流设置最大步数防止无限循环 max_steps 15 current_state initial_state step 0 print( 开始循环工程代码生成 ) print(f项目{initial_state[project_description]}\n) for step in range(max_steps): print(f\n--- 步骤 {step1} ---) # 执行一步 output app.invoke(current_state) # 更新状态 current_state output # 打印当前步骤的关键信息 if current_task in output and output[current_task]: print(f当前任务{output[current_task]}) if task_result in output: print(f结果{output[task_result]}) # 检查是否结束 if output.get(next) END or step max_steps - 1: print(\n 工作流结束 ) print(f已完成任务{output.get(completed_tasks, [])}) print(f生成代码摘要) for task, code in output.get(generated_code, {}).items(): print(f - {task}: {len(code)} 字符) break print(\n 最终状态消息历史最后几条) for msg in current_state[messages][-5:]: # 打印最后5条消息 print(f{msg.type}: {msg.content[:200]}...)运行这个脚本你将看到Agent自动进行“分解 - 生成 - 评估 - 决策 - 生成...”的循环。如果代码评估失败它会自动重试如果通过则进入下一个子任务。5. 运行结果与效果验证运行上述run_agent.py脚本后你会在控制台看到类似以下的输出具体内容因模型生成结果而异 开始循环工程代码生成 项目开发一个简单的Flask博客后端... --- 步骤 1 --- 当前任务1. 设计并创建用户表User的SQLAlchemy模型 结果代码生成完成等待评估。 --- 步骤 2 --- 当前任务1. 设计并创建用户表User的SQLAlchemy模型 结果评估结果PASS。反馈模型定义完整包含必要字段... --- 步骤 3 --- 当前任务2. 设计并创建文章表Post的SQLAlchemy模型 结果任务【1. 设计并创建用户表...】完成。接下来进行【2. 设计并创建文章表...】 --- 步骤 4 --- 当前任务2. 设计并创建文章表Post的SQLAlchemy模型 结果代码生成完成等待评估。 ... --- 步骤 12 --- 当前任务6. 实现文章CRUD API 结果评估结果FAIL。反馈DELETE端点缺少身份验证和作者验证... --- 步骤 13 --- 当前任务6. 实现文章CRUD API 结果任务【6. 实现文章CRUD API】评估未通过将重新生成。 --- 步骤 14 --- 当前任务6. 实现文章CRUD API 结果代码生成完成等待评估。 --- 步骤 15 --- 当前任务6. 实现文章CRUD API 结果评估结果PASS。反馈代码已修正... 工作流结束 已完成任务[1. 设计并创建用户表..., 2. 设计并创建文章表..., ...] 生成代码摘要 - 1. 设计并创建用户表...: 1200 字符 - 2. 设计并创建文章表...: 1100 字符 ...效果验证自动化整个过程无需人工干预每个子任务的提示。系统自动推进。自我修正当评估器发现代码不符合要求如缺少身份验证时循环会触发“重试”模型会基于反馈重新生成代码。状态保持每个子任务生成的代码都保存在generated_code状态中为后续任务提供上下文确保了代码间的一致性例如后续任务生成的API能正确导入之前定义的模型。结构化输出最终current_state[generated_code]字典里包含了所有子任务对应的代码片段。你可以编写一个简单的后处理脚本将这些代码片段按照文件结构写入到实际的项目文件中。手动验证生成代码 你可以从最终状态中提取代码保存为文件并尝试运行。# 文件save_and_test.py import os final_code current_state[generated_code] # 从运行结束的状态中获取 project_dir generated_flask_blog os.makedirs(project_dir, exist_okTrue) # 简单处理将每个任务对应的代码保存为一个文件实际应根据内容解析文件名 for i, (task, code_content) in enumerate(final_code.items()): # 这里需要更智能的解析来获取文件名此处仅作演示 filename ftask_{i1}.py filepath os.path.join(project_dir, filename) with open(filepath, w, encodingutf-8) as f: f.write(code_content) print(fSaved: {filepath}) print(f\n项目文件已保存至 {project_dir} 目录。) print(请检查文件内容并运行 pip install flask sqlalchemy flask-jwt-extended 安装依赖。) print(随后可以尝试运行主应用文件如 app.py。)6. 常见问题与排查思路在构建和运行循环工程系统时你会遇到一些典型问题。下表列出了常见问题及其解决方法问题现象可能原因排查方式解决方案循环陷入无限重试评估标准过于严格或模糊导致模型永远无法生成“PASS”的代码。1. 检查评估器evaluate_code的提示词和逻辑。2. 查看失败任务的评估反馈。1. 优化评估提示词使其更具体、可衡量。2. 引入“最大重试次数”机制超过次数后转入人工审核或跳过。3. 在评估中加入更客观的检查如实际运行语法检查python -m py_compile。任务分解不合理模型拆解的子任务粒度不均或顺序有误导致依赖问题。查看decompose_task节点输出的子任务列表。1. 在系统提示词中更明确地要求任务拆解原则如“每个任务对应一个文件或一个API端点”。2. 在任务分解后加入一个“人工确认”或“模型复审”节点。3. 使用更强大的模型如GPT-4进行分解。生成代码质量低下模型能力不足或上下文已生成代码信息不够。检查generate_code节点接收的上下文context变量。1. 在上下文中提供更详细的已生成代码摘要或关键接口定义。2. 使用思维链Chain-of-Thought提示要求模型先解释思路再写代码。3. 切换或升级底层大模型。状态管理混乱generated_code字典结构过于简单无法管理多文件、多版本。观察状态在循环中的变化看信息是否丢失或错乱。1. 设计更精细的状态结构例如按文件名存储代码并记录版本。2. 使用LangGraph提供的State类或Pydantic模型来严格定义状态模式。API调用成本过高/速度慢循环中多次调用大模型尤其是评估步骤也使用大模型。统计每个循环的token消耗和API调用次数。1. 对于评估优先使用规则检查语法、测试代替大模型评估。2. 设置缓存层对相同输入的任务分解或代码生成结果进行缓存。3. 考虑使用小型、快速的模型处理简单评估。生成的代码无法整体运行各个子任务生成的代码拼凑在一起存在导入错误、接口不一致等问题。将所有生成代码保存后尝试运行并查看错误日志。1. 在generate_code节点的上下文中提供完整的项目文件树和关键导入关系。2. 增加一个最终的“集成与验证”节点专门检查跨文件的兼容性并生成统一的入口文件如app.py、requirements.txt。7. 最佳实践与工程建议将循环工程应用于生产级项目需要更严谨的设计。以下是一些关键建议设计可观测性在状态中增加execution_log字段记录每个节点的输入、输出、时间戳和耗时。这便于调试和性能分析。实现检查点Checkpoint与持久化循环可能很长。务必定期将状态State持久化到数据库或文件。LangGraph支持检查点机制允许工作流从中断处恢复。设置逃生舱Escape Hatch始终提供“人类在环”的接口。当循环达到最大重试次数、或评估置信度低于阈值时应暂停并通知人工介入。成本与速率限制在控制器中集成令牌计数和API调用频率监控。为不同的节点如生成 vs 评估设置不同的模型和配额以平衡成本与质量。模块化与可替换性将任务分解器、执行器、评估器设计为可插拔的组件。这样你可以轻松切换不同的模型如Claude for分解GPT-4 for生成CodeLLaMA for评估或评估工具如单元测试框架、安全扫描工具。测试循环本身为你的循环工作流编写单元测试和集成测试。模拟不同的任务描述和模型响应确保循环逻辑如决策路径在各种边界情况下都能正确工作。从简单循环开始不要一开始就设计一个包含几十个节点的复杂循环。从最基本的“生成-评估-重试”三元组开始验证可行性再逐步添加任务分解、工具调用等高级功能。8. 总结与后续学习方向通过本文的实战我们揭示了“提示词已死”这一说法的真实含义对于复杂、多步骤、有状态的任务依赖单一、静态的提示词是低效且脆弱的。循环工程通过引入系统化的状态管理、任务分解、执行评估和反馈调整将AI从“一次性的问答机”变成了“可自主推进项目的工作流引擎”。我们构建的代码生成Agent只是一个起点。你可以将这套模式应用到无数场景自动化测试生成输入需求文档循环生成测试用例、执行测试、分析覆盖率并补充用例。数据分析报告连接数据库循环执行数据查询、清洗、可视化、洞察总结。智能客服工单处理解析用户问题循环调用知识库、生成回复、确认用户理解、直至关闭工单。下一步你可以从以下几个方向深化探索更强大的框架深入研究LangGraph的StateGraph、Annotation、Checkpointer等高级特性。也可以了解AutoGen、CrewAI等多智能体框架它们提供了更成熟的循环和协作模式。集成真实工具让执行器不仅能生成文本还能真正执行命令。例如集成LangChain Tools来调用Git操作、执行Shell命令、运行Python代码、查询数据库让循环具备“动手能力”。优化评估体系用客观的、自动化的评估替代主观的模型评估。集成pytest、flake8、Bandit安全扫描等工具构建一个可靠的代码质量关卡。研究高级规划策略实现更智能的任务分解与动态重规划。例如让模型在遇到错误时不仅能重试当前任务还能判断是否需要回溯修改之前已完成的任务。循环工程不是要抛弃提示词而是将其降维为循环中的一个配置单元。它的崛起标志着AI应用开发正从“工匠手艺”走向“系统工程”。掌握它意味着你拥有了构建下一代自主智能应用的核心能力。