从静态提示词到动态循环工程：构建可靠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-dotenv

2.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, model="gpt-4o", temperature=0.1): """ 初始化LLM客户端。 :param model: 使用的模型名称，如 gpt-4o, gpt-3.5-turbo :param temperature: 生成结果的随机性，0-1之间，值越低输出越确定。 """ self.client = OpenAI( api_key=OPENAI_API_KEY, base_url=OPENAI_BASE_URL ) self.model = model self.temperature = temperature def chat_completion(self, messages, **kwargs): """发起聊天补全请求""" try: response = self.client.chat.completions.create( model=self.model, messages=messages, temperature=self.temperature, **kwargs ) return response.choices[0].message.content except Exception as e: print(f"LLM API调用失败: {e}") return None # 创建全局客户端实例 client = LLMClient()

3. 循环工程的核心模式与架构拆解

循环工程不是一种固定的技术，而是一种设计模式。我们可以将其分解为几种常见的实现模式。

3.1 基础反馈循环模式

这是最简单的循环：执行 -> 检查 -> 调整。

1. 执行：向LLM发送提示词，获得输出。
2. 检查：使用规则或另一个LLM调用来评估输出质量（如检查格式、内容完整性、是否包含敏感词）。
3. 调整：如果检查不通过，则修改提示词（例如，增加约束、提供反例）或直接要求模型重试，然后回到步骤1。

3.2 链式思考与分解模式

对于复杂问题，要求模型按步骤思考，并将中间结果反馈给后续步骤。

1. 分解：要求模型将一个大任务分解为一系列子任务。
2. 序列执行：按顺序处理每个子任务，将上一个任务的结果作为下一个任务的上下文。
3. 汇总：最后，要求模型基于所有子任务的结果生成最终答案。

3.3 智能体（Agent）模式

这是最复杂的循环模式，模拟了一个具有工具使用能力的自主智能体。

1. 感知：智能体接收用户请求和当前环境状态。
2. 思考：模型决定下一步该做什么（是直接回答，还是调用某个工具/函数）。
3. 行动：如果决定调用工具，则执行相应的函数（如查询数据库、调用API、执行计算）。
4. 观察：获取工具执行的结果。
5. 循环：将“行动”的结果作为新的“感知”输入，重复“思考-行动-观察”循环，直到模型认为可以给出最终答案。

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_factory=list, 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, start=1): 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 smells

4.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_loops=5): 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(indent=2)} 请确保你的输出可以被直接解析为这个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, indent=2, ensure_ascii=False) # 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": f"Authentication failed for user {user_id}. Invalid password provided."} # 一个非常长的行，超过了通常的风格指南限制 result = process_user_data(12345, "guess") ; print(f"Result: {result}") # 这一行太长了，而且用了分号 """ context = "这是一个处理用户认证的示例函数，可能用于一个Web后端服务。" print("开始代码审查智能体演示...") print("待审查代码：") print(sample_code) print("-" * 50) agent = CodeReviewAgent(max_loops=3) 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）并将哈希值存储在环境变量或安全的配置管理服务中。认证应通过调用安全的身份提供商（IdP）API来完成。 2. [行12] [security-medium] 认证失败的错误信息过于详细，可能被用于用户枚举攻击。 建议: 返回通用的错误信息，如“用户名或密码错误”，避免透露用户ID是否存在或具体是密码错误。 3. [行4] [performance-medium] 使用 time.sleep(5) 模拟阻塞操作，在实际Web服务中会严重损害并发性能。 建议: 如果只是占位符，请添加注释说明。如果是真实逻辑，应改为异步操作（如使用 asyncio.sleep）或使用后台任务队列，避免阻塞主线程。 4. [行15] [style-low] 行过长且使用分号，违反PEP 8风格指南，影响可读性。 建议: 将打印语句拆分成独立的一行。保持每行代码简洁。 ==================================================

5. 常见问题与排查思路

在实现和应用循环工程模式时，你可能会遇到以下典型问题。

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应用开发从“炼金术”般的提示词调试，提升到了“软件工程”式的系统设计层面。它通过引入状态、循环、工具和验证，构建出更强大、更可靠、更可控的智能系统。

本文核心要点回顾：

1. 范式转变：从追求“终极提示词”转向设计“稳健的交互循环”。
2. 核心模式：掌握反馈循环、任务分解、智能体三种基本模式，并能根据场景选用。
3. 工程化基石：使用Pydantic等工具进行结构化输出解析，这是连接LLM非确定性输出与确定性程序逻辑的桥梁。
4. 工具集成：将LLM与专用工具（函数）结合，极大扩展了其能力边界。
5. 可控循环：必须设置循环终止条件（最大次数、超时、明确结束信号），防止无限循环。

下一步可以深入探索的方向：

• 框架运用：学习使用LangChain、LlamaIndex、Semantic Kernel等成熟框架，它们封装了智能体、记忆、工具集成等常用模式，能加速开发。
• 高级规划：研究更复杂的规划算法，如Tree of Thoughts (ToT)、Graph of Thoughts (GoT)，让模型能进行更深入的探索性推理。
• 强化学习：考虑使用人类反馈或规则奖励来微调智能体的决策策略，使其行为更符合预期。
• 多智能体协作：设计多个具有不同专长的智能体相互协作、辩论，共同解决复杂问题。

循环工程不是银弹，它增加了系统的复杂性。但对于那些需要可靠性、复杂交互和深度集成的AI应用来说，它是不可或缺的架构思想。希望这篇指南能为你打开一扇门，助你构建出下一代真正智能的应用程序。