在AI应用开发领域我们常常陷入一个误区认为只要精心设计一个完美的“提示词”就能一劳永逸地让大语言模型LLM输出理想结果。然而在实际项目中无论是构建智能客服、代码生成工具还是内容创作助手单次、静态的提示词往往难以应对复杂、多变的真实需求。模型可能会“跑偏”、输出不完整或者无法进行多轮、递进式的思考。本文将深入探讨一种更强大、更工程化的范式——循环工程并提供一个从理论到实践的完整指南帮助你构建真正可靠、可控的AI应用。本文适合所有正在或计划将大语言模型集成到产品中的开发者、产品经理和技术决策者。无论你是想优化现有基于提示词的简单交互还是设计需要多步骤推理的复杂智能体文中的理念和代码都将为你提供一套可落地的解决方案。1. 核心概念从静态提示词到动态循环工程在深入循环工程之前我们有必要厘清几个核心概念并理解为何单纯的“提示词工程”存在天花板。1.1 什么是提示词工程及其局限提示词工程是指通过精心设计和优化输入给大语言模型的文本指令以引导模型生成更准确、更符合预期的输出。这包括使用特定的格式、提供示例Few-shot Learning、设定角色等技巧。然而其局限性非常明显单次交互传统提示词通常是一次性的“提问-回答”模式缺乏状态记忆和上下文演进能力。脆弱性对提示词的措辞极其敏感微小的改动可能导致输出质量大幅波动。复杂度有限难以让模型执行需要多个步骤、条件判断或自我验证的复杂任务。难以调试当输出不理想时很难定位是提示词的哪个部分出了问题调整过程像“黑盒”调参。1.2 循环工程的定义与核心思想循环工程是一种系统性的方法论它将与大语言模型的交互视为一个可编程的、多步骤的循环过程。其核心思想是不让模型一次性完成所有工作而是将其嵌入到一个由代码控制的流程中在这个流程里模型的输出会被分析、验证并作为下一次输入的依据如此循环直至达成目标。循环工程的关键特征包括状态管理显式地维护对话或任务的状态如历史记录、中间结果、目标进度。流程控制使用条件判断、循环等编程逻辑来驱动与模型的交互流程。输出解析与验证对模型的输出进行结构化解析如转为JSON并设计规则或使用模型自身进行验证。迭代优化基于上一次输出的质量动态调整下一次请求的提示内容。1.3 为什么说“提示词已死”“提示词已死”并非指提示词不再有用而是强调仅依赖静态提示词来构建复杂应用的时代已经过去。在循环工程的范式下提示词从一个“魔法咒语”降级为一个可配置、可动态生成的模板组件。它的价值依然存在但不再是应用架构的核心。核心变成了设计整个循环流程的状态机和控制逻辑。2. 环境准备与核心工具为了实践循环工程我们需要选择合适的工具链。本文将使用 Python 作为主要编程语言因为它拥有最丰富的AI开发生态。2.1 基础环境与依赖确保你的 Python 版本在 3.8 及以上。我们将使用openai官方库或兼容的库如litellm来调用大模型并使用pydantic来定义和验证结构化数据。首先创建项目并安装依赖# 创建项目目录 mkdir loop-engineering-demo cd loop-engineering-demo # 创建虚拟环境可选但推荐 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # Mac/Linux: source venv/bin/activate # 安装核心依赖 pip install openai pydantic python-dotenv2.2 配置API密钥创建一个.env文件来安全地存储你的API密钥切勿提交到版本控制# .env OPENAI_API_KEY你的OpenAI API密钥 OPENAI_BASE_URL你的API基础地址如果使用第三方兼容服务在代码中加载配置# config.py import os from dotenv import load_dotenv load_dotenv() # 加载 .env 文件中的环境变量 OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) # 默认OpenAI官方2.3 初始化模型客户端创建一个统一的客户端模块便于后续调用# llm_client.py from openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL class LLMClient: def __init__(self, modelgpt-4o, temperature0.1): 初始化LLM客户端。 :param model: 使用的模型名称如 gpt-4o, gpt-3.5-turbo :param temperature: 生成结果的随机性0-1之间值越低输出越确定。 self.client OpenAI( api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL ) self.model model self.temperature temperature def chat_completion(self, messages, **kwargs): 发起聊天补全请求 try: response self.client.chat.completions.create( modelself.model, messagesmessages, temperatureself.temperature, **kwargs ) return response.choices[0].message.content except Exception as e: print(fLLM API调用失败: {e}) return None # 创建全局客户端实例 client LLMClient()3. 循环工程的核心模式与架构拆解循环工程不是一种固定的技术而是一种设计模式。我们可以将其分解为几种常见的实现模式。3.1 基础反馈循环模式这是最简单的循环执行 - 检查 - 调整。执行向LLM发送提示词获得输出。检查使用规则或另一个LLM调用来评估输出质量如检查格式、内容完整性、是否包含敏感词。调整如果检查不通过则修改提示词例如增加约束、提供反例或直接要求模型重试然后回到步骤1。3.2 链式思考与分解模式对于复杂问题要求模型按步骤思考并将中间结果反馈给后续步骤。分解要求模型将一个大任务分解为一系列子任务。序列执行按顺序处理每个子任务将上一个任务的结果作为下一个任务的上下文。汇总最后要求模型基于所有子任务的结果生成最终答案。3.3 智能体Agent模式这是最复杂的循环模式模拟了一个具有工具使用能力的自主智能体。感知智能体接收用户请求和当前环境状态。思考模型决定下一步该做什么是直接回答还是调用某个工具/函数。行动如果决定调用工具则执行相应的函数如查询数据库、调用API、执行计算。观察获取工具执行的结果。循环将“行动”的结果作为新的“感知”输入重复“思考-行动-观察”循环直到模型认为可以给出最终答案。4. 完整实战案例构建一个代码审查智能体让我们通过一个具体案例——一个能自动审查Python代码并提出改进建议的智能体来完整实践循环工程。这个智能体将能理解代码上下文、识别潜在问题如性能、安全、风格并进行多轮交互式提问以澄清模糊点。4.1 项目结构与设计code_review_agent/ ├── .env ├── config.py ├── llm_client.py ├── agents/ │ ├── __init__.py │ └── code_reviewer.py # 核心智能体逻辑 ├── tools/ │ ├── __init__.py │ └── code_analyzer.py # 模拟的代码分析工具 ├── schemas/ │ ├── __init__.py │ └── models.py # Pydantic数据模型 └── main.py # 应用入口4.2 定义结构化数据模型Pydantic使用Pydantic确保LLM的输出是结构化的便于程序处理。# schemas/models.py from pydantic import BaseModel, Field from typing import List, Optional, Literal class CodeIssue(BaseModel): 代码问题模型 type: Literal[bug, security, performance, style, best_practice] severity: Literal[low, medium, high] line_number: Optional[int] Field(None, description问题所在行号可选) description: str Field(..., description问题的详细描述) suggestion: str Field(..., description修复建议) class CodeReviewResult(BaseModel): 代码审查结果模型 summary: str Field(..., description审查总结) issues: List[CodeIssue] Field(default_factorylist, description发现的问题列表) needs_clarification: bool Field(False, description是否需要向用户澄清) clarification_question: Optional[str] Field(None, description需要向用户提问的内容) class ClarificationResponse(BaseModel): 用户澄清响应模型 answer: str Field(..., description用户对澄清问题的回答)4.3 实现模拟工具工具是智能体能力的延伸。这里我们模拟一个简单的静态分析工具。# tools/code_analyzer.py def detect_simple_smells(code: str) - List[dict]: 一个简单的代码异味检测工具示例。 在实际应用中这里可以集成pylint、bandit等真实工具。 smells [] lines code.split(\n) for i, line in enumerate(lines, start1): line_lower line.lower() # 简单的规则检测 if password in line_lower and hardcode in line_lower: smells.append({ line: i, type: security, message: 发现可能硬编码的密码凭证。 }) if sleep( in line: smells.append({ line: i, type: performance, message: 使用 sleep 可能导致性能问题考虑使用异步或事件驱动。 }) if len(line) 120: smells.append({ line: i, type: style, message: 行过长建议保持代码行在120字符以内以提高可读性。 }) return smells4.4 构建核心智能体这是循环工程的核心实现了“思考-行动-观察”的循环。# agents/code_reviewer.py from typing import List, Dict, Any from llm_client import client from schemas.models import CodeReviewResult, CodeIssue, ClarificationResponse from tools.code_analyzer import detect_simple_smells import json class CodeReviewAgent: def __init__(self, max_loops5): self.max_loops max_loops # 最大循环次数防止无限循环 self.conversation_history [] # 维护对话历史 def _call_llm_with_schema(self, prompt: str, response_model): 调用LLM并强制其输出符合Pydantic模型的结构化数据 # 构造系统提示要求模型以指定JSON格式回复 system_msg { role: system, content: f你是一个专业的代码审查助手。请严格以JSON格式回复JSON必须符合以下Schema定义 {response_model.schema_json(indent2)} 请确保你的输出可以被直接解析为这个JSON Schema。不要输出任何额外的解释或Markdown格式。 } user_msg {role: user, content: prompt} messages [system_msg, user_msg] self.conversation_history[-4:] # 保留最近4条历史作为上下文 response_text client.chat_completion(messages) if not response_text: return None try: # 尝试从响应中提取JSON模型有时会在JSON外加json 标记 if json in response_text: json_str response_text.split(json)[1].split()[0].strip() elif in response_text: json_str response_text.split()[1].split()[0].strip() else: json_str response_text.strip() data json.loads(json_str) return response_model(**data) except (json.JSONDecodeError, KeyError) as e: print(f解析LLM响应为JSON失败: {e}\n原始响应:\n{response_text}) # 优雅降级如果解析失败尝试让模型修复 repair_prompt f你之前的回复无法被解析为有效的JSON。请根据以下Schema重新生成正确的JSON。 Schema: {response_model.schema_json()} 请只输出JSON不要有其他内容。 return self._call_llm_with_schema(repair_prompt, response_model) def review(self, code: str, context: str ) - CodeReviewResult: 主审查循环。 :param code: 待审查的代码字符串 :param context: 代码的上下文描述如功能、依赖等 :return: 最终的审查结果 loop_count 0 needs_clarification True user_clarification # 初始审查 review_result self._perform_initial_review(code, context) self.conversation_history.append({role: assistant, content: f初始审查完成。总结{review_result.summary}}) while needs_clarification and loop_count self.max_loops: loop_count 1 print(f\n 循环迭代 {loop_count} ) if review_result.needs_clarification and review_result.clarification_question: # 模拟这里应该向真实用户提问。本例中我们模拟一个简单回答。 print(f[Agent提问]: {review_result.clarification_question}) # 模拟用户输入实际应用中替换为真实用户交互 simulated_answer input([模拟用户输入回答]: ).strip() or 我没有更多信息了请基于现有信息继续。 user_clarification simulated_answer # 将澄清结果融入下一轮审查 review_result self._review_with_clarification(code, context, user_clarification, review_result) else: needs_clarification False break # 更新是否需要进一步澄清 needs_clarification review_result.needs_clarification print(f\n审查循环结束共进行 {loop_count} 轮迭代。) return review_result def _perform_initial_review(self, code: str, context: str) - CodeReviewResult: 执行初始代码审查结合LLM和工具分析 # 1. 调用工具进行初步静态分析 tool_findings detect_simple_smells(code) tool_findings_str json.dumps(tool_findings, indent2, ensure_asciiFalse) # 2. 构造给LLM的提示词 prompt f 请对以下Python代码进行全面的审查包括潜在的错误、安全漏洞、性能问题、代码风格和最佳实践。 代码上下文/功能描述{context} 待审查的代码 python {code}自动化工具初步分析结果供参考 {tool_findings_str}请基于你的知识和以上工具结果生成详细的审查报告。 如果代码的意图或某些部分非常模糊导致你无法准确判断某些问题请明确指出你需要澄清什么。 return self._call_llm_with_schema(prompt, CodeReviewResult)def _review_with_clarification(self, code: str, context: str, clarification: str, previous_result: CodeReviewResult) - CodeReviewResult: 基于用户的澄清进行新一轮审查 prompt f继续审查以下代码。之前的一轮审查中我们提出了一个澄清问题现在用户给出了回答。用户澄清回答{clarification}原始代码上下文{context} 原始代码{code}之前的审查总结{previous_result.summary}请结合用户的澄清更新你的审查报告。如果澄清已经解决了模糊点请给出更确定的结论如果仍有疑问可以提出新的澄清问题。 return self._call_llm_with_schema(prompt, CodeReviewResult)### 4.5 运行与验证 创建一个主程序来运行我们的智能体。 python # main.py from agents.code_reviewer import CodeReviewAgent def main(): # 示例代码一个存在一些潜在问题的函数 sample_code import time def process_user_data(user_id, password): # 模拟一个耗时操作 time.sleep(5) # 这里可能阻塞主线程 # 硬编码密码比较安全风险示例 hardcoded_password admin123 if password hardcoded_password: return {status: authenticated} else: # 错误信息可能泄露过多信息 return {error: fAuthentication failed for user {user_id}. Invalid password provided.} # 一个非常长的行超过了通常的风格指南限制 result process_user_data(12345, guess) ; print(fResult: {result}) # 这一行太长了而且用了分号 context 这是一个处理用户认证的示例函数可能用于一个Web后端服务。 print(开始代码审查智能体演示...) print(待审查代码) print(sample_code) print(- * 50) agent CodeReviewAgent(max_loops3) final_result agent.review(sample_code, context) print(\n *50) print(最终审查报告) print(f总结: {final_result.summary}) print(f共发现 {len(final_result.issues)} 个问题) for i, issue in enumerate(final_result.issues, 1): print(f {i}. [行{issue.line_number or N/A}] [{issue.type}-{issue.severity}] {issue.description}) print(f 建议: {issue.suggestion}) print(*50) if __name__ __main__: main()预期输出示例开始代码审查智能体演示... 待审查代码 ...代码略... -------------------------------------------------- 循环迭代 1 [Agent提问]: 函数 process_user_data 中的 time.sleep(5) 是模拟什么操作在实际生产环境中这样的阻塞调用是否可接受用户认证通常涉及数据库或外部服务调用您能确认这里的 sleep 只是占位符吗 [模拟用户输入回答]: 这个sleep只是用来模拟网络延迟的占位符实际生产环境会调用一个外部的认证API。 循环迭代 2 [Agent提问]: 我看到错误信息中直接返回了 user_id 和 “Invalid password provided”。在生产环境中返回如此详细的错误信息是否存在安全风险如用户枚举攻击您希望错误信息详细到什么程度 [模拟用户输入回答]: 是的应该返回更通用的错误信息比如“认证失败”。 审查循环结束共进行 2 轮迭代。 最终审查报告 总结: 代码存在安全、性能和代码风格问题。用户澄清后确认了部分设计意图并给出了针对性改进建议。 共发现 4 个问题 1. [行7] [security-high] 硬编码密码进行比对存在严重安全风险。 建议: 密码不应硬编码在代码中。应使用安全的密码哈希算法如bcrypt并将哈希值存储在环境变量或安全的配置管理服务中。认证应通过调用安全的身份提供商IdPAPI来完成。 2. [行12] [security-medium] 认证失败的错误信息过于详细可能被用于用户枚举攻击。 建议: 返回通用的错误信息如“用户名或密码错误”避免透露用户ID是否存在或具体是密码错误。 3. [行4] [performance-medium] 使用 time.sleep(5) 模拟阻塞操作在实际Web服务中会严重损害并发性能。 建议: 如果只是占位符请添加注释说明。如果是真实逻辑应改为异步操作如使用 asyncio.sleep或使用后台任务队列避免阻塞主线程。 4. [行15] [style-low] 行过长且使用分号违反PEP 8风格指南影响可读性。 建议: 将打印语句拆分成独立的一行。保持每行代码简洁。 5. 常见问题与排查思路在实现和应用循环工程模式时你可能会遇到以下典型问题。问题现象常见原因解决思路循环陷入无限或次数过多1. 循环终止条件设计有误如needs_clarification永远为 True。2. LLM 对同一问题反复要求澄清。1. 设置硬性最大循环次数 (max_loops)。2. 在提示词中明确“如果信息不足请基于最佳假设给出建议而非必须提问”。3. 实现超时机制。LLM输出无法解析为JSON1. 提示词中系统指令不够强硬。2. 模型忽略了格式要求。3. 响应中包含额外解释文本。1. 使用response_format{ type: json_object }参数如果API支持。2. 在系统提示中更严格地要求“只输出JSON”。3. 实现如_call_llm_with_schema中的解析和修复逻辑。智能体决策效率低下1. 每次循环都携带全部历史导致上下文过长、成本高、速度慢。2. 工具调用选择不准。1. 有选择地裁剪历史只保留最近几轮或关键信息。2. 为工具提供清晰、具体的描述并使用函数调用Function Calling让模型更准确地选择工具。工具调用结果处理失败1. 工具返回的数据格式与LLM期望不符。2. 工具执行出错。1. 在将工具结果注入提示词前先将其转换为清晰、自然的语言描述。2. 对工具调用进行健壮性包装try-catch并设计备选方案或错误信息。状态管理混乱多个对话或任务的状态相互干扰。1. 为每个会话或任务实例创建独立的智能体对象。2. 使用明确的数据结构如Pydantic模型来封装状态避免使用全局变量。6. 最佳实践与工程建议将循环工程应用于生产环境需要遵循以下工程化实践以确保其可靠性、可维护性和成本效益。6.1 提示词模板化与管理不要将提示词硬编码在业务逻辑中。使用模板引擎如Jinja2将提示词定义为模板动态注入变量如用户输入、历史记录、工具结果。集中管理将不同任务、不同阶段的提示词模板放在统一的配置文件或数据库中便于维护和A/B测试。# 示例使用字典管理提示词模板 PROMPT_TEMPLATES { code_review_initial: 请审查以下代码 {code} 上下文{context} 工具发现{tool_findings} ... , code_review_with_clarify: 基于澄清{clarification}重新审查... }6.2 成本与延迟优化LLM API调用是主要成本和时间开销来源。缓存对具有确定性的查询如解析固定格式的数据结果进行缓存。上下文长度管理积极裁剪对话历史只保留对当前决策最关键的信息。考虑使用向量数据库进行长期记忆的存储和检索。异步处理对于不要求实时响应的任务使用异步队列进行处理。模型分级对不同的子任务使用不同能力的模型。例如用低成本模型如gpt-3.5-turbo进行初步过滤或格式化只用高性能模型如gpt-4处理核心推理。6.3 可观测性与调试循环系统的调试比单次调用复杂得多。结构化日志记录每一次LLM调用输入、输出、工具调用、状态变更。为每个会话或任务分配唯一的correlation_id。可视化工具考虑集成像LangSmith这样的平台可以可视化跟踪智能体的整个决策链条。评估体系建立自动化评估流程例如用一组标准测试用例验证智能体的最终输出质量监控循环次数、成功率等指标。6.4 安全与合规输入输出过滤对所有用户输入和LLM输出进行安全检查防止注入攻击或生成有害内容。权限控制智能体使用的工具如数据库查询、API调用必须遵循最小权限原则。审计追踪确保所有AI做出的决策、调用的工具都有完整的日志可供审计满足合规要求。6.5 设计模式选择简单任务使用“基础反馈循环”即可避免过度设计。复杂多步任务“链式思考与分解”模式非常有效如复杂计算、长篇内容生成。需要与外部系统交互“智能体”模式是唯一选择如客服系统、自动化运维机器人。7. 总结与进阶方向通过本文的探讨和实战我们可以看到循环工程将AI应用开发从“炼金术”般的提示词调试提升到了“软件工程”式的系统设计层面。它通过引入状态、循环、工具和验证构建出更强大、更可靠、更可控的智能系统。本文核心要点回顾范式转变从追求“终极提示词”转向设计“稳健的交互循环”。核心模式掌握反馈循环、任务分解、智能体三种基本模式并能根据场景选用。工程化基石使用Pydantic等工具进行结构化输出解析这是连接LLM非确定性输出与确定性程序逻辑的桥梁。工具集成将LLM与专用工具函数结合极大扩展了其能力边界。可控循环必须设置循环终止条件最大次数、超时、明确结束信号防止无限循环。下一步可以深入探索的方向框架运用学习使用LangChain、LlamaIndex、Semantic Kernel等成熟框架它们封装了智能体、记忆、工具集成等常用模式能加速开发。高级规划研究更复杂的规划算法如Tree of Thoughts (ToT)、Graph of Thoughts (GoT)让模型能进行更深入的探索性推理。强化学习考虑使用人类反馈或规则奖励来微调智能体的决策策略使其行为更符合预期。多智能体协作设计多个具有不同专长的智能体相互协作、辩论共同解决复杂问题。循环工程不是银弹它增加了系统的复杂性。但对于那些需要可靠性、复杂交互和深度集成的AI应用来说它是不可或缺的架构思想。希望这篇指南能为你打开一扇门助你构建出下一代真正智能的应用程序。
从静态提示词到动态循环工程：构建可靠AI应用的工程化范式
在AI应用开发领域我们常常陷入一个误区认为只要精心设计一个完美的“提示词”就能一劳永逸地让大语言模型LLM输出理想结果。然而在实际项目中无论是构建智能客服、代码生成工具还是内容创作助手单次、静态的提示词往往难以应对复杂、多变的真实需求。模型可能会“跑偏”、输出不完整或者无法进行多轮、递进式的思考。本文将深入探讨一种更强大、更工程化的范式——循环工程并提供一个从理论到实践的完整指南帮助你构建真正可靠、可控的AI应用。本文适合所有正在或计划将大语言模型集成到产品中的开发者、产品经理和技术决策者。无论你是想优化现有基于提示词的简单交互还是设计需要多步骤推理的复杂智能体文中的理念和代码都将为你提供一套可落地的解决方案。1. 核心概念从静态提示词到动态循环工程在深入循环工程之前我们有必要厘清几个核心概念并理解为何单纯的“提示词工程”存在天花板。1.1 什么是提示词工程及其局限提示词工程是指通过精心设计和优化输入给大语言模型的文本指令以引导模型生成更准确、更符合预期的输出。这包括使用特定的格式、提供示例Few-shot Learning、设定角色等技巧。然而其局限性非常明显单次交互传统提示词通常是一次性的“提问-回答”模式缺乏状态记忆和上下文演进能力。脆弱性对提示词的措辞极其敏感微小的改动可能导致输出质量大幅波动。复杂度有限难以让模型执行需要多个步骤、条件判断或自我验证的复杂任务。难以调试当输出不理想时很难定位是提示词的哪个部分出了问题调整过程像“黑盒”调参。1.2 循环工程的定义与核心思想循环工程是一种系统性的方法论它将与大语言模型的交互视为一个可编程的、多步骤的循环过程。其核心思想是不让模型一次性完成所有工作而是将其嵌入到一个由代码控制的流程中在这个流程里模型的输出会被分析、验证并作为下一次输入的依据如此循环直至达成目标。循环工程的关键特征包括状态管理显式地维护对话或任务的状态如历史记录、中间结果、目标进度。流程控制使用条件判断、循环等编程逻辑来驱动与模型的交互流程。输出解析与验证对模型的输出进行结构化解析如转为JSON并设计规则或使用模型自身进行验证。迭代优化基于上一次输出的质量动态调整下一次请求的提示内容。1.3 为什么说“提示词已死”“提示词已死”并非指提示词不再有用而是强调仅依赖静态提示词来构建复杂应用的时代已经过去。在循环工程的范式下提示词从一个“魔法咒语”降级为一个可配置、可动态生成的模板组件。它的价值依然存在但不再是应用架构的核心。核心变成了设计整个循环流程的状态机和控制逻辑。2. 环境准备与核心工具为了实践循环工程我们需要选择合适的工具链。本文将使用 Python 作为主要编程语言因为它拥有最丰富的AI开发生态。2.1 基础环境与依赖确保你的 Python 版本在 3.8 及以上。我们将使用openai官方库或兼容的库如litellm来调用大模型并使用pydantic来定义和验证结构化数据。首先创建项目并安装依赖# 创建项目目录 mkdir loop-engineering-demo cd loop-engineering-demo # 创建虚拟环境可选但推荐 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # Mac/Linux: source venv/bin/activate # 安装核心依赖 pip install openai pydantic python-dotenv2.2 配置API密钥创建一个.env文件来安全地存储你的API密钥切勿提交到版本控制# .env OPENAI_API_KEY你的OpenAI API密钥 OPENAI_BASE_URL你的API基础地址如果使用第三方兼容服务在代码中加载配置# config.py import os from dotenv import load_dotenv load_dotenv() # 加载 .env 文件中的环境变量 OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) # 默认OpenAI官方2.3 初始化模型客户端创建一个统一的客户端模块便于后续调用# llm_client.py from openai import OpenAI from config import OPENAI_API_KEY, OPENAI_BASE_URL class LLMClient: def __init__(self, modelgpt-4o, temperature0.1): 初始化LLM客户端。 :param model: 使用的模型名称如 gpt-4o, gpt-3.5-turbo :param temperature: 生成结果的随机性0-1之间值越低输出越确定。 self.client OpenAI( api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL ) self.model model self.temperature temperature def chat_completion(self, messages, **kwargs): 发起聊天补全请求 try: response self.client.chat.completions.create( modelself.model, messagesmessages, temperatureself.temperature, **kwargs ) return response.choices[0].message.content except Exception as e: print(fLLM API调用失败: {e}) return None # 创建全局客户端实例 client LLMClient()3. 循环工程的核心模式与架构拆解循环工程不是一种固定的技术而是一种设计模式。我们可以将其分解为几种常见的实现模式。3.1 基础反馈循环模式这是最简单的循环执行 - 检查 - 调整。执行向LLM发送提示词获得输出。检查使用规则或另一个LLM调用来评估输出质量如检查格式、内容完整性、是否包含敏感词。调整如果检查不通过则修改提示词例如增加约束、提供反例或直接要求模型重试然后回到步骤1。3.2 链式思考与分解模式对于复杂问题要求模型按步骤思考并将中间结果反馈给后续步骤。分解要求模型将一个大任务分解为一系列子任务。序列执行按顺序处理每个子任务将上一个任务的结果作为下一个任务的上下文。汇总最后要求模型基于所有子任务的结果生成最终答案。3.3 智能体Agent模式这是最复杂的循环模式模拟了一个具有工具使用能力的自主智能体。感知智能体接收用户请求和当前环境状态。思考模型决定下一步该做什么是直接回答还是调用某个工具/函数。行动如果决定调用工具则执行相应的函数如查询数据库、调用API、执行计算。观察获取工具执行的结果。循环将“行动”的结果作为新的“感知”输入重复“思考-行动-观察”循环直到模型认为可以给出最终答案。4. 完整实战案例构建一个代码审查智能体让我们通过一个具体案例——一个能自动审查Python代码并提出改进建议的智能体来完整实践循环工程。这个智能体将能理解代码上下文、识别潜在问题如性能、安全、风格并进行多轮交互式提问以澄清模糊点。4.1 项目结构与设计code_review_agent/ ├── .env ├── config.py ├── llm_client.py ├── agents/ │ ├── __init__.py │ └── code_reviewer.py # 核心智能体逻辑 ├── tools/ │ ├── __init__.py │ └── code_analyzer.py # 模拟的代码分析工具 ├── schemas/ │ ├── __init__.py │ └── models.py # Pydantic数据模型 └── main.py # 应用入口4.2 定义结构化数据模型Pydantic使用Pydantic确保LLM的输出是结构化的便于程序处理。# schemas/models.py from pydantic import BaseModel, Field from typing import List, Optional, Literal class CodeIssue(BaseModel): 代码问题模型 type: Literal[bug, security, performance, style, best_practice] severity: Literal[low, medium, high] line_number: Optional[int] Field(None, description问题所在行号可选) description: str Field(..., description问题的详细描述) suggestion: str Field(..., description修复建议) class CodeReviewResult(BaseModel): 代码审查结果模型 summary: str Field(..., description审查总结) issues: List[CodeIssue] Field(default_factorylist, description发现的问题列表) needs_clarification: bool Field(False, description是否需要向用户澄清) clarification_question: Optional[str] Field(None, description需要向用户提问的内容) class ClarificationResponse(BaseModel): 用户澄清响应模型 answer: str Field(..., description用户对澄清问题的回答)4.3 实现模拟工具工具是智能体能力的延伸。这里我们模拟一个简单的静态分析工具。# tools/code_analyzer.py def detect_simple_smells(code: str) - List[dict]: 一个简单的代码异味检测工具示例。 在实际应用中这里可以集成pylint、bandit等真实工具。 smells [] lines code.split(\n) for i, line in enumerate(lines, start1): line_lower line.lower() # 简单的规则检测 if password in line_lower and hardcode in line_lower: smells.append({ line: i, type: security, message: 发现可能硬编码的密码凭证。 }) if sleep( in line: smells.append({ line: i, type: performance, message: 使用 sleep 可能导致性能问题考虑使用异步或事件驱动。 }) if len(line) 120: smells.append({ line: i, type: style, message: 行过长建议保持代码行在120字符以内以提高可读性。 }) return smells4.4 构建核心智能体这是循环工程的核心实现了“思考-行动-观察”的循环。# agents/code_reviewer.py from typing import List, Dict, Any from llm_client import client from schemas.models import CodeReviewResult, CodeIssue, ClarificationResponse from tools.code_analyzer import detect_simple_smells import json class CodeReviewAgent: def __init__(self, max_loops5): self.max_loops max_loops # 最大循环次数防止无限循环 self.conversation_history [] # 维护对话历史 def _call_llm_with_schema(self, prompt: str, response_model): 调用LLM并强制其输出符合Pydantic模型的结构化数据 # 构造系统提示要求模型以指定JSON格式回复 system_msg { role: system, content: f你是一个专业的代码审查助手。请严格以JSON格式回复JSON必须符合以下Schema定义 {response_model.schema_json(indent2)} 请确保你的输出可以被直接解析为这个JSON Schema。不要输出任何额外的解释或Markdown格式。 } user_msg {role: user, content: prompt} messages [system_msg, user_msg] self.conversation_history[-4:] # 保留最近4条历史作为上下文 response_text client.chat_completion(messages) if not response_text: return None try: # 尝试从响应中提取JSON模型有时会在JSON外加json 标记 if json in response_text: json_str response_text.split(json)[1].split()[0].strip() elif in response_text: json_str response_text.split()[1].split()[0].strip() else: json_str response_text.strip() data json.loads(json_str) return response_model(**data) except (json.JSONDecodeError, KeyError) as e: print(f解析LLM响应为JSON失败: {e}\n原始响应:\n{response_text}) # 优雅降级如果解析失败尝试让模型修复 repair_prompt f你之前的回复无法被解析为有效的JSON。请根据以下Schema重新生成正确的JSON。 Schema: {response_model.schema_json()} 请只输出JSON不要有其他内容。 return self._call_llm_with_schema(repair_prompt, response_model) def review(self, code: str, context: str ) - CodeReviewResult: 主审查循环。 :param code: 待审查的代码字符串 :param context: 代码的上下文描述如功能、依赖等 :return: 最终的审查结果 loop_count 0 needs_clarification True user_clarification # 初始审查 review_result self._perform_initial_review(code, context) self.conversation_history.append({role: assistant, content: f初始审查完成。总结{review_result.summary}}) while needs_clarification and loop_count self.max_loops: loop_count 1 print(f\n 循环迭代 {loop_count} ) if review_result.needs_clarification and review_result.clarification_question: # 模拟这里应该向真实用户提问。本例中我们模拟一个简单回答。 print(f[Agent提问]: {review_result.clarification_question}) # 模拟用户输入实际应用中替换为真实用户交互 simulated_answer input([模拟用户输入回答]: ).strip() or 我没有更多信息了请基于现有信息继续。 user_clarification simulated_answer # 将澄清结果融入下一轮审查 review_result self._review_with_clarification(code, context, user_clarification, review_result) else: needs_clarification False break # 更新是否需要进一步澄清 needs_clarification review_result.needs_clarification print(f\n审查循环结束共进行 {loop_count} 轮迭代。) return review_result def _perform_initial_review(self, code: str, context: str) - CodeReviewResult: 执行初始代码审查结合LLM和工具分析 # 1. 调用工具进行初步静态分析 tool_findings detect_simple_smells(code) tool_findings_str json.dumps(tool_findings, indent2, ensure_asciiFalse) # 2. 构造给LLM的提示词 prompt f 请对以下Python代码进行全面的审查包括潜在的错误、安全漏洞、性能问题、代码风格和最佳实践。 代码上下文/功能描述{context} 待审查的代码 python {code}自动化工具初步分析结果供参考 {tool_findings_str}请基于你的知识和以上工具结果生成详细的审查报告。 如果代码的意图或某些部分非常模糊导致你无法准确判断某些问题请明确指出你需要澄清什么。 return self._call_llm_with_schema(prompt, CodeReviewResult)def _review_with_clarification(self, code: str, context: str, clarification: str, previous_result: CodeReviewResult) - CodeReviewResult: 基于用户的澄清进行新一轮审查 prompt f继续审查以下代码。之前的一轮审查中我们提出了一个澄清问题现在用户给出了回答。用户澄清回答{clarification}原始代码上下文{context} 原始代码{code}之前的审查总结{previous_result.summary}请结合用户的澄清更新你的审查报告。如果澄清已经解决了模糊点请给出更确定的结论如果仍有疑问可以提出新的澄清问题。 return self._call_llm_with_schema(prompt, CodeReviewResult)### 4.5 运行与验证 创建一个主程序来运行我们的智能体。 python # main.py from agents.code_reviewer import CodeReviewAgent def main(): # 示例代码一个存在一些潜在问题的函数 sample_code import time def process_user_data(user_id, password): # 模拟一个耗时操作 time.sleep(5) # 这里可能阻塞主线程 # 硬编码密码比较安全风险示例 hardcoded_password admin123 if password hardcoded_password: return {status: authenticated} else: # 错误信息可能泄露过多信息 return {error: fAuthentication failed for user {user_id}. Invalid password provided.} # 一个非常长的行超过了通常的风格指南限制 result process_user_data(12345, guess) ; print(fResult: {result}) # 这一行太长了而且用了分号 context 这是一个处理用户认证的示例函数可能用于一个Web后端服务。 print(开始代码审查智能体演示...) print(待审查代码) print(sample_code) print(- * 50) agent CodeReviewAgent(max_loops3) final_result agent.review(sample_code, context) print(\n *50) print(最终审查报告) print(f总结: {final_result.summary}) print(f共发现 {len(final_result.issues)} 个问题) for i, issue in enumerate(final_result.issues, 1): print(f {i}. [行{issue.line_number or N/A}] [{issue.type}-{issue.severity}] {issue.description}) print(f 建议: {issue.suggestion}) print(*50) if __name__ __main__: main()预期输出示例开始代码审查智能体演示... 待审查代码 ...代码略... -------------------------------------------------- 循环迭代 1 [Agent提问]: 函数 process_user_data 中的 time.sleep(5) 是模拟什么操作在实际生产环境中这样的阻塞调用是否可接受用户认证通常涉及数据库或外部服务调用您能确认这里的 sleep 只是占位符吗 [模拟用户输入回答]: 这个sleep只是用来模拟网络延迟的占位符实际生产环境会调用一个外部的认证API。 循环迭代 2 [Agent提问]: 我看到错误信息中直接返回了 user_id 和 “Invalid password provided”。在生产环境中返回如此详细的错误信息是否存在安全风险如用户枚举攻击您希望错误信息详细到什么程度 [模拟用户输入回答]: 是的应该返回更通用的错误信息比如“认证失败”。 审查循环结束共进行 2 轮迭代。 最终审查报告 总结: 代码存在安全、性能和代码风格问题。用户澄清后确认了部分设计意图并给出了针对性改进建议。 共发现 4 个问题 1. [行7] [security-high] 硬编码密码进行比对存在严重安全风险。 建议: 密码不应硬编码在代码中。应使用安全的密码哈希算法如bcrypt并将哈希值存储在环境变量或安全的配置管理服务中。认证应通过调用安全的身份提供商IdPAPI来完成。 2. [行12] [security-medium] 认证失败的错误信息过于详细可能被用于用户枚举攻击。 建议: 返回通用的错误信息如“用户名或密码错误”避免透露用户ID是否存在或具体是密码错误。 3. [行4] [performance-medium] 使用 time.sleep(5) 模拟阻塞操作在实际Web服务中会严重损害并发性能。 建议: 如果只是占位符请添加注释说明。如果是真实逻辑应改为异步操作如使用 asyncio.sleep或使用后台任务队列避免阻塞主线程。 4. [行15] [style-low] 行过长且使用分号违反PEP 8风格指南影响可读性。 建议: 将打印语句拆分成独立的一行。保持每行代码简洁。 5. 常见问题与排查思路在实现和应用循环工程模式时你可能会遇到以下典型问题。问题现象常见原因解决思路循环陷入无限或次数过多1. 循环终止条件设计有误如needs_clarification永远为 True。2. LLM 对同一问题反复要求澄清。1. 设置硬性最大循环次数 (max_loops)。2. 在提示词中明确“如果信息不足请基于最佳假设给出建议而非必须提问”。3. 实现超时机制。LLM输出无法解析为JSON1. 提示词中系统指令不够强硬。2. 模型忽略了格式要求。3. 响应中包含额外解释文本。1. 使用response_format{ type: json_object }参数如果API支持。2. 在系统提示中更严格地要求“只输出JSON”。3. 实现如_call_llm_with_schema中的解析和修复逻辑。智能体决策效率低下1. 每次循环都携带全部历史导致上下文过长、成本高、速度慢。2. 工具调用选择不准。1. 有选择地裁剪历史只保留最近几轮或关键信息。2. 为工具提供清晰、具体的描述并使用函数调用Function Calling让模型更准确地选择工具。工具调用结果处理失败1. 工具返回的数据格式与LLM期望不符。2. 工具执行出错。1. 在将工具结果注入提示词前先将其转换为清晰、自然的语言描述。2. 对工具调用进行健壮性包装try-catch并设计备选方案或错误信息。状态管理混乱多个对话或任务的状态相互干扰。1. 为每个会话或任务实例创建独立的智能体对象。2. 使用明确的数据结构如Pydantic模型来封装状态避免使用全局变量。6. 最佳实践与工程建议将循环工程应用于生产环境需要遵循以下工程化实践以确保其可靠性、可维护性和成本效益。6.1 提示词模板化与管理不要将提示词硬编码在业务逻辑中。使用模板引擎如Jinja2将提示词定义为模板动态注入变量如用户输入、历史记录、工具结果。集中管理将不同任务、不同阶段的提示词模板放在统一的配置文件或数据库中便于维护和A/B测试。# 示例使用字典管理提示词模板 PROMPT_TEMPLATES { code_review_initial: 请审查以下代码 {code} 上下文{context} 工具发现{tool_findings} ... , code_review_with_clarify: 基于澄清{clarification}重新审查... }6.2 成本与延迟优化LLM API调用是主要成本和时间开销来源。缓存对具有确定性的查询如解析固定格式的数据结果进行缓存。上下文长度管理积极裁剪对话历史只保留对当前决策最关键的信息。考虑使用向量数据库进行长期记忆的存储和检索。异步处理对于不要求实时响应的任务使用异步队列进行处理。模型分级对不同的子任务使用不同能力的模型。例如用低成本模型如gpt-3.5-turbo进行初步过滤或格式化只用高性能模型如gpt-4处理核心推理。6.3 可观测性与调试循环系统的调试比单次调用复杂得多。结构化日志记录每一次LLM调用输入、输出、工具调用、状态变更。为每个会话或任务分配唯一的correlation_id。可视化工具考虑集成像LangSmith这样的平台可以可视化跟踪智能体的整个决策链条。评估体系建立自动化评估流程例如用一组标准测试用例验证智能体的最终输出质量监控循环次数、成功率等指标。6.4 安全与合规输入输出过滤对所有用户输入和LLM输出进行安全检查防止注入攻击或生成有害内容。权限控制智能体使用的工具如数据库查询、API调用必须遵循最小权限原则。审计追踪确保所有AI做出的决策、调用的工具都有完整的日志可供审计满足合规要求。6.5 设计模式选择简单任务使用“基础反馈循环”即可避免过度设计。复杂多步任务“链式思考与分解”模式非常有效如复杂计算、长篇内容生成。需要与外部系统交互“智能体”模式是唯一选择如客服系统、自动化运维机器人。7. 总结与进阶方向通过本文的探讨和实战我们可以看到循环工程将AI应用开发从“炼金术”般的提示词调试提升到了“软件工程”式的系统设计层面。它通过引入状态、循环、工具和验证构建出更强大、更可靠、更可控的智能系统。本文核心要点回顾范式转变从追求“终极提示词”转向设计“稳健的交互循环”。核心模式掌握反馈循环、任务分解、智能体三种基本模式并能根据场景选用。工程化基石使用Pydantic等工具进行结构化输出解析这是连接LLM非确定性输出与确定性程序逻辑的桥梁。工具集成将LLM与专用工具函数结合极大扩展了其能力边界。可控循环必须设置循环终止条件最大次数、超时、明确结束信号防止无限循环。下一步可以深入探索的方向框架运用学习使用LangChain、LlamaIndex、Semantic Kernel等成熟框架它们封装了智能体、记忆、工具集成等常用模式能加速开发。高级规划研究更复杂的规划算法如Tree of Thoughts (ToT)、Graph of Thoughts (GoT)让模型能进行更深入的探索性推理。强化学习考虑使用人类反馈或规则奖励来微调智能体的决策策略使其行为更符合预期。多智能体协作设计多个具有不同专长的智能体相互协作、辩论共同解决复杂问题。循环工程不是银弹它增加了系统的复杂性。但对于那些需要可靠性、复杂交互和深度集成的AI应用来说它是不可或缺的架构思想。希望这篇指南能为你打开一扇门助你构建出下一代真正智能的应用程序。