企业官网建设流程全解析

在实际构建智能体（AI Agent）应用时，最容易被低估的部分不是模型能力，而是如何让系统在多次调用之间形成闭环。很多初版智能体产品本质上是“包了一层接口的大模型调用”：用户提问，模型回答，调用结束。但真正的智能体需要感知环境、执行动作、观察结果、根据反馈调整下一步，并在多轮迭代中逼近目标。智能体时代把这种设计方式推到了前台，它有一个更工程化的名字：循环工程。

循环工程解决的核心问题不是“模型能不能回答”，而是“系统能不能在一个目标驱动下持续工作”。设计一个自主驱动的 AI 闭环系统，不能只关注提示词写得好不好，还要关注循环怎么启动、怎么终止、怎么防止卡死、怎么评估每一轮是否有效。这篇文章会从概念讲到最小可运行实现，再讲到生产环境必须考虑的排查路径和治理机制。读完可以照着代码跑通一个“生成-评审-修改-再评审”的闭环智能体，并知道如何把它扩展成更复杂的多智能体系统。

1. 先理解智能体闭环系统为什么不是“调用一次大模型”

1.1 单次调用和自主闭环的区别

普通 AI 应用最常见的形态是：用户输入一个问题，程序把问题拼进提示词，调用大模型接口，拿到结果后直接展示。这个流程对聊天助手、翻译工具、摘要工具是够用的，因为任务在模型输出那一刻就结束了。

智能体应用完全不同。智能体有一个需要持续完成的目标，这个目标往往不能靠一次推理完成。比如自动写一篇文章并修改到合格，自动检查一段代码并修复问题，自动完成数据分析并生成图表。这类任务需要模型输出一个中间结果，再由另一个环节验证结果，验证不通过就带着反馈重新生成，直到通过或达到上限。

这里的“闭环”指的是信息从系统流向模型，模型输出又回到系统，系统根据输出质量和任务目标决定是否继续迭代。没有闭环的智能体只是一个被装饰过的接口调用，有闭环的智能体才具备自主性。

下表是两种模式的核心差异：

1.2 循环工程的三层含义

循环工程不是一个具体的框架，而是一套设计方法。它包含三个从内到外的层次。

第一层是运行循环。系统按照“感知-决策-行动-反馈”的顺序运转。感知阶段接收外部输入和当前状态，决策阶段根据已有信息选择下一步动作，行动阶段调用模型或工具产生结果，反馈阶段把结果交给评估器判断是否达标。

第二层是优化循环。模型产生的结果并不是最终答案，而是待评估对象。评估器给出分数、通过状态和修改建议，系统把建议拼回上下文，让模型在下一次生成时参考。这个循环的价值在于让模型能够“反思”自己的输出，而不是一次性碰运气。

第三层是治理循环。工程环境里不能只关注功能，还要关注循环会不会失控。治理循环要求在循环之外建立日志、监控、人工审批、预算控制和熔断机制，确保系统在异常情况下可以被停止和恢复。

1.3 闭环系统需要哪些核心模块

一个可工作的闭环系统至少需要六个模块：感知模块、记忆模块、决策模块、执行模块、反馈模块和评估模块。

感知模块负责接收任务描述和外部数据。记忆模块保存历史上下文和执行状态，避免系统每次从零开始。决策模块根据当前目标和历史记忆选择下一步动作，可以是一个 LLM 调用，也可以是规则路由。执行模块调用工具、函数或内容生成器，真正产生结果。反馈模块收集执行后的现象和指标，比如访问结果、命令行输出、评分结果。评估模块判断当前结果是否满足任务要求，决定继续还是终止。

这六个模块并不是所有场景都要完整实现。最小闭环可以先省略工具调用，只保留“生成-评估-迭代”。后面扩展到生产系统时再逐步加入外部工具、知识库和多智能体协作。

2. 设计自主驱动 AI 闭环系统的核心架构

2.1 六模块的职责和输入输出

设计闭环系统之前，先要把每个模块的边界定义清楚。模块边界越清楚，后续排查问题越容易。

感知模块最常见的实现方式是先定义任务对象。任务对象包含任务 ID、指令内容、最大轮数、历史消息等字段。后续所有模块都围绕这个对象工作。

记忆模块容易被忽略。很多人会在循环里把每一轮的完整对话都拼进提示词，结果上下文越来越长，费用越来越高，模型反而丢失关键信息。更合理的做法是只把“上一轮评审意见”和“当前待修改文本”作为上下文来源，必要时使用摘要压缩历史。

决策模块和执行模块在最小闭环里可以合并。最简单的情况是系统不做复杂规划，直接调用 LLM 生成内容。更复杂的情况是决策模块先判断“这个任务需要调用搜索接口还是写文件”，再交给不同执行器。判断逻辑可以用 LLM + 结构化输出实现，也可以用规则实现。

反馈模块和评估模块是闭环能成立的关键。反馈模块负责把执行结果转成评估器可读的输入，评估模块负责产出可计算的结果。如果评估模块只用“好”或“不好”这种自然语言，系统很难稳定决定是否终止。建议评估模块输出结构化内容，例如 JSON 格式的分数、是否通过、修改建议。

2.2 循环机制的运转流程

一个最小闭环系统的运转流程可以用文字描述成下面的顺序：

1. 系统收到任务，创建 Task 对象，初始化空上下文。
2. 生成器按任务和历史上下文生成第一版结果。
3. 评估器检查结果是否满足任务要求。
4. 如果通过，系统输出结果并结束。
5. 如果未通过，评估器产生修改建议，系统把建议写回上下文。
6. 生成器基于上一版结果和修改建议生成新版结果。
7. 重复第 3 到第 6 步，直到通过或达到最大轮数。

这个流程的关键点在于结束条件。结束条件不能依赖模型“自己判断是否完成”，而应该由独立的评估环节判断。如果生成器和评估器是同一个模型，它们可以共用同一个模型接口，但提示词必须区分角色，避免生成器自说自话。

实际工程中，循环不会无限运行。必须设置最大轮数，防止模型反复生成但始终不达标。最大轮数要结合成本和效果来设定。学习环境可以设 3 轮，生产环境可以先设 5 轮，再根据线上数据调整。

2.3 为什么记忆和评估是闭环的关键

记忆和评估这两个模块决定了闭环系统的质量上限。

没有记忆，系统每一轮都是独立生成，修改建议无法被利用，循环就变成了重复生成。没有评估，系统无法判断任务是否完成，循环要么提前结束，要么永远不结束。评估模块尤其重要，它相当于给系统一个外部标准。评估标准越客观，循环越稳定。如果任务可以被规则量化，例如代码能编译、字数区间正确、包含必需关键词，建议先写规则判断。如果任务依赖语义质量，例如文章是否通顺、方案是否合理，再交给 LLM 评估。

LLM 评估并不是万无一失。同一个模型既当生成器又当评审器时，可能出现“自我认可”的倾向。缓解方法包括使用不同模型的评估接口、降低评估温度、要求输出结构化 JSON、增加人类抽查比例。在最小闭环示例里，为了跑通流程，可以先用同一个模型，但生产环境要按需调整。

3. 从零搭建一个最小闭环系统

3.1 项目依赖和目录结构

示例使用 Python 3.10+ 和两个依赖：requests 用于调用大模型 HTTP 接口，python-dotenv 用于加载本地环境变量。这里不绑定具体大模型 SDK，因为 OpenAI 兼容接口在很多服务上都能复用，换成其他服务时只需要调整 base_url。

pip install requests python-dotenv

项目目录按模块拆分，方便后面扩展。

agent-loop/ ├── .env ├── models.py ├── llm.py ├── agent.py └── main.py

各文件职责如下：

3.2 定义任务和上下文数据模型

数据模型要能表达任务 ID、任务指令、最大轮数和历史消息。使用 dataclass 可以让代码更简洁。

# models.py from dataclasses import dataclass, field from typing import Dict, List @dataclass class Task: id: str instruction: str max_rounds: int = 3 history: List[Dict] = field(default_factory=list) def to_messages(self, system_prompt: str) -> List[Dict]: messages = [{"role": "system", "content": system_prompt}] messages.extend(self.history) return messages

history 字段用来保存多轮交互记录。在最小闭环里，不要在每轮把全部历史都塞进去，通常只保存上一版文本和上一轮评审意见。否则上下文会迅速膨胀，模型也抓不住重点。

3.3 封装大模型接口

llm.py 只做一件事：通过 OpenAI 兼容的 /chat/completions 接口发送对话消息并返回文本内容。这样在后续切换模型服务时，只需要改动 base_url 和模型名。

# llm.py import requests from typing import Dict, List class LLMClient: def __init__(self, api_key: str, base_url: str, model: str, timeout: int = 60): self.api_key = api_key self.base_url = base_url.rstrip("/") self.model = model self.timeout = timeout def chat(self, messages: List[Dict], temperature: float = 0.7, max_tokens: int = 1024) -> str: url = f"{self.base_url}/chat/completions" headers = { "Authorization": f"Bearer {self.api_key}", "Content-Type": "application/json" } payload = { "model": self.model, "messages": messages, "temperature": temperature, "max_tokens": max_tokens } resp = requests.post(url, headers=headers, json=payload, timeout=self.timeout) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"]

这里没有使用 requests 的重试机制。生产环境需要增加超时重试、指数退避和错误码分类，否则接口抖动会直接中断整个闭环。第 5 章会展开说明。

3.4 实现生成器和评估器

agent.py 是核心文件。生成器负责按任务和评审意见生成文本，评估器负责判断结果是否合格。

生成器提示词需要说明两点：如果存在上一轮评审意见，必须按意见修改；输出正文内容，不要输出额外解释。这样可以减少模型输出“好的，我已经修改”这类无效内容。

评估器提示词要求输出 JSON，而且字段固定为 score、pass、reason、suggestions。结构化输出是评估模块能参与自动决策的前提。

# agent.py import json import re from typing import Dict from llm import LLMClient from models import Task GENERATOR_SYSTEM = ( "你是一个内容生成器。根据任务说明生成文本。" "如果上轮存在评审意见，必须严格按意见修改。" "只输出正文内容，不要输出解释。" ) EVALUATOR_SYSTEM = ( "你是一个评审器。检查文本是否满足任务要求。" "只输出JSON，格式为：" "{\"score\": 0-100, \"pass\": true/false, " "\"reason\": \"简要原因\", \"suggestions\": [\"修改建议\"]}" )

实现上要保持生成和评估的调用逻辑独立，这样后续可以把评估器换成规则引擎或其他模型。

def call_llm(client: LLMClient, messages, temperature=0.7): try: content = client.chat(messages, temperature=temperature) return content.strip() except Exception as e: print(f"[LLM调用异常] {e}") raise def generate(client: LLMClient, task: Task, context: str) -> str: user_content = f"任务：{task.instruction}\n\n评审意见和建议：\n{context}" messages = task.to_messages(GENERATOR_SYSTEM) messages.append({"role": "user", "content": user_content}) return call_llm(client, messages) def evaluate(client: LLMClient, task: Task, text: str) -> Dict: messages = [ {"role": "system", "content": EVALUATOR_SYSTEM}, { "role": "user", "content": f"任务：{task.instruction}\n\n待评审文本：\n{text}", }, ] content = call_llm(client, messages, temperature=0.0) return parse_evaluation(content) def parse_evaluation(content: str) -> Dict: try: return json.loads(content) except json.JSONDecodeError: match = re.search(r"\{.*\}", content, re.S) if match: return json.loads(match.group()) return { "score": 0, "pass": False, "reason": "评估器输出无法解析", "suggestions": [], }

评估温度要设置为 0，让评审结果尽可能稳定。如果评估器输出夹杂解释文字导致 JSON 解析失败，正则提取最外层的 JSON 片段可以提高容错性。

3.5 实现循环控制器

循环控制器是整个系统的中枢。它负责控制最大轮数、调用生成器和评估器、判断终止条件、记录每轮结果。

def run_loop(client: LLMClient, task: Task, min_score: int = 80) -> Dict: context = "暂无评审意见。请开始第一次生成。" result = { "task_id": task.id, "rounds": 0, "final_text": "", "evaluations": [], } rounds = 0 while rounds < task.max_rounds: rounds += 1 print(f"第 {rounds} 轮生成开始") text = generate(client, task, context) evaluation = evaluate(client, task, text) print( f"第 {rounds} 轮评分：{evaluation['score']}，" f"是否通过：{evaluation['pass']}" ) result["rounds"] = rounds result["final_text"] = text result["evaluations"].append(evaluation) if evaluation["pass"] or evaluation["score"] >= min_score: print("闭环结束：评分达标") break suggestions = evaluation.get("suggestions", []) context = "；".join(suggestions) if suggestions else evaluation.get("reason", "请继续优化") print(f"评审建议：{context}") else: print("达到最大轮次，闭环结束") return result

注意 exit 条件有两种：pass 为 true，或者 score 大于等于 min_score。实际项目中不要只依赖 pass，因为模型生成的 JSON 字段可能不稳定。加上分数阈值相当于多一道保险。另一个关键是使用 while 循环的 else 分支，只有循环正常耗尽轮次才会触发，这样能区分“达标退出”和“超限退出”。

3.6 配置和主入口

环境变量放在 .env 文件里，避免把密钥写进代码。

LLM_API_KEY=sk-demo LLM_BASE_URL=https://api.openai.com/v1 LLM_MODEL=gpt-4o-mini LLM_TIMEOUT=60

如果使用的是本地大模型服务或兼容 OpenAI 的网关，base_url 换成对应的服务地址。模型名也要按实际部署的模型调整，不要照搬示例。

# main.py import os from dotenv import load_dotenv from agent import run_loop from llm import LLMClient from models import Task load_dotenv() def main(): client = LLMClient( api_key=os.getenv("LLM_API_KEY", ""), base_url=os.getenv("LLM_BASE_URL", "https://api.openai.com/v1"), model=os.getenv("LLM_MODEL", "gpt-4o-mini"), timeout=int(os.getenv("LLM_TIMEOUT", "60")) ) task = Task( id="demo-001", instruction="写一段介绍智能体闭环系统的文字，120字左右。", max_rounds=3 ) result = run_loop(client, task, min_score=80) print("最终结果：") print(result["final_text"]) if __name__ == "__main__": main()

运行命令：

python main.py

这个最小系统已经能完成一次“生成-评估-迭代”的闭环过程，适合用来理解循环的基本逻辑。注意示例里的任务和模型都需要按真实环境调整，不要直接在业务中使用。

4. 运行验证：让系统自主完成一个小任务

4.1 准备环境变量和接口连通性

运行前先确认三件事：API Key 是否有访问权限，base_url 是否能连通，模型名是否真实存在。这三项最容易出错。

常见的检查方式是先通过 curl 或 Python 脚本直接调用一次接口，确认能拿到正常响应，再去跑闭环。不要在闭环运行后才开始排错，那样会把接口问题误判成循环逻辑问题。

curl -X POST "$LLM_BASE_URL/chat/completions" \ -H "Authorization: Bearer $LLM_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"test"}]}'

如果接口返回 200，说明基础连通性正常。

4.2 运行过程和预期输出

配置好 .env 后，直接运行 main.py。以“写一段介绍智能体闭环系统的文字”为例，预期日志类似下面的形式：

第 1 轮生成开始 第 1 轮评分：65，是否通过：False 评审建议：内容缺少具体例子；字数不足；开头不够直接 第 2 轮生成开始 第 2 轮评分：85，是否通过：True 闭环结束：评分达标 最终结果： 智能体闭环系统是目标驱动的多轮迭代系统。它在执行中持续感知结果、评估质量、调整动作，直到达成目标。与单次模型调用不同，闭环系统依靠反馈循环提升稳定性，是工程化智能体的核心形态。

如果第一轮就通过，说明任务简单或评估标准宽松。可以在实际运行中把任务调难一些，例如要求“必须包含代码示例”“必须给出对比表”，这样更容易看到循环迭代的过程。

4.3 验证闭环是否真正有效

程序能跑通不代表闭环设计合理。至少要检查三个点。

第一，每一轮是否基于上一轮反馈进行修改。把第一轮文本和最后一轮文本对比，如果内容完全相同，说明生成器没有消费评审建议，循环只是在空转。

第二，终止条件是否符合预期。如果任务明显不合格，系统却因为 score 超过阈值提前退出，说明评估器评分不严格。此时应该降低评估器的“自我认可”倾向，或引入更明确的规则校验。

第三，最大轮数是否真正起到保护作用。把 max_rounds 改成 1，确认系统只调用一次生成和一次评估。再改成 100，确认系统不会因为任务长期不达标而无限运行。

5. 关键参数和配置说明

5.1 循环控制参数表

闭环系统的行为主要由参数决定。参数调不好，模型再好也跑不稳。

在最小示例中，生成温度和评估温度要分开控制。生成端可以保留 0.7 让内容有变化，评估端建议固定为 0 或极低值，保证评分可复现。

5.2 提示词设计对闭环效果的影响

提示词不是“越复杂越好”，而是要明确角色、输出格式和参考信息。

生成器提示词需要告诉模型三件事：它是什么角色，当前任务是什么，上轮修改意见是什么。如果缺少角色设定，模型可能输出与任务无关的说明。如果缺少修改意见，模型无法理解为什么要改。

评估器提示词需要明确评分标准。建议把任务要求和评审维度都放进提示词，而不是只写“请评估以下文本”。例如要求“技术文章必须包含代码示例、参数表格、排错方法”，评估器就会在 JSON 的 reason 中给出更具针对性的建议。

如果模型不支持严格的 JSON 输出，最好在提示词末尾加上“只输出 JSON，不要包含解释文字”的约束，并在代码里做正则解析兜底。更可靠的方式是使用支持 JSON Mode 的接口参数，但要确认所调用的模型服务支持这个特性。

5.3 LLM 接口调用的容错处理

闭环系统比单次调用更容易触发接口错误，因为它会在短时间内连续调用多次。常见错误包括限流、超时、上下文过长和临时性 5xx。

requests 库默认不会重试。生产环境建议增加重试逻辑，对不同的错误码做不同处理。

重试不能无限进行。每次重试之间要增加间隔，通常采用指数退避，例如 1 秒、2 秒、4 秒。同时要给整体循环设定预算上限，例如“单任务最多花费 5000 token”或“单任务最多调用 20 次接口”，避免模型反复生成导致费用失控。

6. 常见问题排查：循环卡死、重复输出、反馈失效

6.1 故障现象和排查方向表

闭环系统的问题通常集中在循环控制、输出解析和接口调用三个层面。

6.2 通过日志和追踪定位问题

排查闭环问题最有效的方式是给每一轮加上可追踪的日志。每轮日志至少包含以下字段：

• 轮次
• 生成器输入消息摘要
• 生成器输出前 100 个字符
• 评审 JSON
• 当前累计成本和 Token 数
• 循环退出原因

示例日志模板：

round=2 status=generated input_len=320 output_prefix="闭环系统是..." round=2 status=evaluated score=85 pass=true reason="内容完整，字数达标" round=2 status=exit reason=score_ok cost_tokens=1800

在多模块闭环里，建议为每次任务生成 trace_id。循环开始前生成一个 UUID，所有日志、评估记录、埋点数据都带上这个 ID，后面把日志接入日志平台时能直接按任务聚合。

6.3 防止失控循环的安全机制

防止失控不能只靠 max_rounds。生产环境至少要有四道保护。

第一道是轮次限制，main 循环里必须判断最大轮数。第二道是金额或 Token 预算，在每次调用前累加消耗，超过预算就终止。第三道是人工审批，当任务连续多次不达标或评估分数低于某条线时，转人工处理。第四道是熔断机制，当接口错误率超过阈值时，暂停循环并告警，避免持续调用加重服务负担。

安全机制应该配置化，而不是写死在代码里。配置文件需要区分开发、测试和生产环境，分别指定不同的预算和超时阈值。

7. 生产环境落地的最佳实践

7.1 学习环境与生产环境的差异

最小闭环系统适合理解原理，但不适合直接上线。生产环境要在很多地方做额外加固。

最小示例里的评估器输出只存在内存里。生产环境要把每一轮的生成文本、评审结果、修改建议、耗时和 Token 数保存到数据库，方便复盘和调优。

7.2 发布前检查清单

上线一个闭环智能体前，建议按这份清单逐项确认。

• [ ] 所有外部接口地址和密钥来自配置中心，不写死在代码仓库。
• [ ] 每个任务都设置了 max_rounds 和预算上限。
• [ ] 生成器和评估器在不同情况下都能稳定输出预期格式。
• [ ] 所有 LLM 调用都支持超时重试，且不会无限重试。
• [ ] 日志中能通过 trace_id 还原一次任务的完整执行过程。
• [ ] 存在人工审批入口，至少可以在任务异常时终止。
• [ ] 评估结果经过人工抽查，准确率符合业务要求。
• [ ] 定义了退出原因编码，能区分达标退出、超轮退出和异常退出。
• [ ] 对敏感信息做了过滤，不会把密钥或用户隐私拼进提示词。
• [ ] 有回滚方案，模型或接口异常时可以降级到旧版本逻辑。

7.3 从最小闭环到完整智能体平台的扩展方向

最小闭环运行稳定后，可以向三个方向扩展。

第一个方向是多智能体协作。把生成器和评估器拆成独立 Agent，甚至让多个 Agent 分别负责写作、检查、数据补充和最终汇总。多智能体之间通过消息队列通信，每个 Agent 都有自己的循环和终止条件。

第二个方向是工具调用。执行模块从“只调用模型”扩展成“调用搜索、数据库、文件系统、代码执行器”。这时候感知模块和反馈模块要处理更多外部状态，例如工具返回的错误码、执行耗时、数据 schema。

第三个方向是记忆持久化和知识管理。把历史任务、常见评审意见、长期偏好保存到向量数据库，让系统在跨任务场景中复用经验。记忆从“单轮上下文”升级为“长期记忆”后，闭环的迭代起点会明显提高。

无论往哪个方向扩展，核心都要守住循环工程的三个原则：运行闭环要能自主迭代，评估闭环要能控制质量，治理闭环要能保障安全和可观测。先把最小闭环跑通，再逐步增加复杂度，比一开始就搭建庞大框架更容易形成可维护的智能体系统。