别只会改 Prompt：用 AI Loop 把大模型变成可验收的执行系统

一次 Prompt 得到不错的回答，不等于能稳定交付结果。

谈到 AI Loop，可以用三个问题快速建立认知：

是什么？ 在明确目标、验收标准和资源边界内运行的生成---评估---决策闭环。
为什么？ 单次 LLM 调用是概率输出，复杂任务需要反馈机制把它拉向可交付结果。
怎么做？ 用 Loop 推进任务，用 Harness（护栏/约束框架） 约束目标、执行、评估和资源。

真实任务里，我们经常在重复同一套人工操作：让 AI 生成代码或文案，检查格式和事实，发现问题，再补一条提示词让它重来。任务一旦涉及多步骤、外部工具、质量门槛或成本限制，这种"人盯着 AI 改"的方式很快失效。

更合适的思路不是无限加长 Prompt，而是把这套人工反馈过程编排为一个可观测、可停止、可回退的 AI Loop：生成 → 评估 → 决策 → 修复或退出。

本文以一个文案生成 Demo 为起点，拆解如何把它升级成可用于真实系统的闭环工作流。这里的 AI Loop 是通俗称呼；更准确地说，它是一种围绕目标、状态、反馈和资源边界构建的智能体工作流。

一、从"一次生成"到"可控闭环"

先看两种工作方式的差异。

text 复制代码

一次生成
用户 → Prompt → LLM → 输出

AI Loop
目标/约束 → 生成或执行 → 评估 → 决策 ──合格──→ 交付
                              │
                              ├──可修复──→ 携带失败证据进入下一轮
                              ├──高风险──→ 人工审批
                              └──触及预算→ 失败兜底

Prompt 解决的是"这一轮怎样表达需求"；Loop 解决的是"任务未达标时如何继续、何时停止、由谁承担风险"。

一个最小闭环至少要回答四个问题：

目标是什么？ 例如"输出可解析的招聘信息 JSON"，而不是模糊的"帮我整理一下"。
怎样算完成？ 例如字段完整、邮箱合法、来源可追溯、单元测试通过等等。
失败后做什么？ 重试、局部修复、切换策略、请求人工确认，还是直接失败。
何时必须停？ 最大轮数、Token/金额、超时、重复输出、风险阈值都需要成为硬边界。

这与控制论中的负反馈很相似：系统观察当前输出与目标之间的差距，再依据差距调整下一步动作。但在 LLM 系统中，评估信号可能来自程序规则、测试、检索证据、模型评审和用户反馈，不应只依赖模型"觉得自己做得对"。

AI Loop 不是什么

把边界说清楚，能避免很多误解：

不是无人监管的自主：AI 的策略空间由人为设计的目标、规则、工具白名单和预算框定。
不是无限调用模型：循环必须具备成功、失败、预算耗尽和人工接管等退出路径。
不是只靠模型自评：可确定的规则应优先由代码、测试、Schema 或检索结果验证。
不等于模型训练：训练是"前向计算---损失---反向传播---参数更新"的迭代优化；在线 AI Loop 是围绕任务输出的推理编排。

"Loop Engineering"适合做通俗说法，但工程交流中更宜明确为控制循环、智能体工作流或评估驱动工作流。

二、AI Loop 的核心架构

一个可落地的架构可以拆成六层：

text 复制代码

┌──────────────────────────────────────────────────────────────┐
│  目标与策略：成功标准、风险等级、预算、人工升级规则            │
├──────────────────────────────────────────────────────────────┤
│  上下文层：用户输入、知识检索、工具结果、权限过滤、数据脱敏    │
├───────────────┬───────────────────┬──────────────────────────┤
│  生成/规划器  │  执行器/工具调用  │  评估器                  │
│  LLM 生成候选 │  API、代码、检索  │  规则、测试、语义评审    │
├───────────────┴───────────────────┴──────────────────────────┤
│  决策与状态机：通过、修复、重试、降级、人工审批、失败退出      │
├──────────────────────────────────────────────────────────────┤
│  观测与治理：trace、指标、审计、限流、策略即代码、告警          │
└──────────────────────────────────────────────────────────────┘

其中最容易被忽略的是"决策与状态机"。如果只有 while 循环和一个 pass 布尔值，系统只能盲目重试；真正的决策器要根据失败原因选择动作：字段缺失就局部补齐，测试失败就把报错交回模型，权限不足就转人工，预算耗尽就返回明确的失败结果。

三种常用模式

模式	流程	适合的任务	注意点
闭环反馈式	生成 → 评估 → 修复	文案、信息提取、格式化	评估标准要明确
迭代优化式	产生候选 → 打分/搜索 → 保留最优	提示词优化、方案选择	评分函数决定上限
规划---执行式	计划 → 调工具 → 观察 → 再计划	工单、数据分析、研发助手	工具权限和副作用要受控

至于更加复杂的多智能体协作和多模态融合可以看作上述模式的扩展：前者用不同角色增强审阅与分工，后者把图像、语音、文本的感知与评估也放进反馈回路。它们不是"模型越多越好"，而是以额外成本换取覆盖度和鲁棒性。

用 Harness 把"自主"装进笼子

Loop + Harness 是让 Loop 从实验变成生产系统的关键。Harness 不是额外负担，而是对自主行为的必要约束。建议把约束拆成四层：

层级	约束对象	关键问题
目标层	任务定义	目标能否拆成可验收的子目标？成功标准是否可测？
执行层	生成/工具调用	工具白名单、参数校验、超时、幂等、副作用控制
评估层	质量校验	硬规则、事实验证、语义评审、业务指标如何分层组合
治理层	资源与风险	轮数、Token、预算、降级、审计、人工审批门

一个可用的 AI Loop，应该是 Loop 负责推进，Harness 负责刹车和改道。没有 Harness 的 Loop，只是"让模型反复猜"；没有 Loop 的 Harness，只是静态规则，无法处理长尾异常。

三、先设计评估器，再写循环

闭环的质量上限，通常不是由生成模型决定，而是由评估器决定。一个实用原则是：能用确定性程序判断的，绝不先花 Token 让模型判断。

以 Demo 的"小红书美妆文案"为例，原始规则包括"标题带数字""正文少于 300 字""结尾有行动号召"和"像爆款"。前 3 类可用本地代码、正则或字数统计校验；"像爆款"才是相对主观的语义判断，适合交给模型评审或人工抽检。

text 复制代码

评估层级
1. 硬规则：JSON Schema、长度、正则、权限、lint、单元测试
2. 事实规则：检索来源、工具返回值、引用可访问性
3. 语义规则：相关性、风格、一致性、有害性
4. 业务指标：解决率、人工转接率、时延、单位成功成本

评估输出也不能只写"失败"。它应该是机器可消费的反馈协议，例如：

json 复制代码

{
  "pass": false,
  "issues": [
    {
      "rule": "title_has_number",
      "evidence": "标题中未发现阿拉伯数字",
      "repair": "仅重写标题，并保留正文内容"
    }
  ]
}

有了失败证据，下一轮才能做局部修复，而不是把整段上下文和任务重新投给模型，既浪费成本，也更容易引入新错误。

四、从 Demo 升级一个安全的最小闭环

Demo 已有正确的雏形：生成文案、调用模型检查、设置最大轮数、总 Token 和重复输出三种刹车。它清楚展示了"生成---检查---退出"的骨架。

不过，如果直接用于生产，存在三个典型问题：校验结果直接 JSON.parse，模型输出 Markdown 就会中断；校验本身的 Token 没计入预算；失败原因没有反馈到下一轮生成。

下面给出一个不绑定特定模型服务商的核心伪代码。重点不在 API 名称，而在状态、预算和错误分支。

js 复制代码

const limits = { maxRounds: 5, maxTokens: 4000, timeoutMs: 20_000 };

async function runLoop(task) {
  const state = { round: 0, totalTokens: 0, lastHash: '', issues: [] };

  while (state.round < limits.maxRounds && state.totalTokens < limits.maxTokens) {
    state.round += 1;
    const candidate = await generate({ task, issues: state.issues, timeoutMs: limits.timeoutMs });
    state.totalTokens += candidate.tokens;

    if (hash(candidate.text) === state.lastHash) return fallback('重复输出，停止重试', state);
    state.lastHash = hash(candidate.text);

    const hardResult = validateLocally(candidate.text, task.rules);
    const semanticResult = hardResult.pass
      ? await evaluateSemantically(candidate.text, task.semanticRules)
      : { pass: false, issues: hardResult.issues };

    state.issues = [...hardResult.issues, ...semanticResult.issues];
    if (hardResult.pass && semanticResult.pass) return deliver(candidate.text, state);
    if (requiresHumanApproval(state.issues)) return escalate(candidate.text, state);
  }

  return fallback('达到资源边界，转人工处理', state);
}

这里有几个关键工程点：

预算按全链路累计：生成、评估、检索和工具调用都要记录耗时、Token/费用与失败率。
先硬后软：本地校验失败就无需发起语义评审，减少成本和延迟。
状态可回放：每轮记录模型版本、输入摘要、输出哈希、失败原因和停止原因，方便定位回归。
写操作可控：对于发邮件、修改数据库、下单等有副作用的工具，采用最小权限、参数校验、幂等键与人工审批。

如果服务商支持结构化输出，应使用 JSON Schema 约束评估结果，而不是只在 Prompt 中要求"仅输出 JSON"。OpenAI 的 Structured Outputs 文档明确区分了 JSON Mode 与 Schema 约束：前者仅保证 JSON 语法，后者才用于约束字段、类型和枚举。即便如此，业务层仍要处理拒答、超时和下游约束。

五、适用边界：不是每个任务都值得上 Loop

AI Loop 适合的是可验收的复杂任务，而不是所有复杂任务。

适合的

输出有明确格式/规则要求（JSON Schema、字段完整性、字数、测试通过）
失败后可以"可修复地重试"（字段补全、报错修复、局部重写）
单轮结果不稳定，但多轮迭代能收敛
重复性高、人工盯盘耗时

例如：信息抽取、代码补丁生成、文案合规检查、测试用例生成、数据清洗。

不适合或需要谨慎的

目标本身就是开放的、审美的、价值观敏感的（"写一首打动人心的诗"）
失败代价极高且无法回滚（自动转账、医疗诊断、法律裁决）
无法低成本验证结果对错（某些研究推理、未来预测）
实时性要求极低容忍延迟

所以"减少人的参与、解放人的时间"是对的，但更准确的说法是：把人的参与从"每一轮盯盘改 Prompt"转移到" upfront 设计目标、验收标准和异常兜底"。人在 Loop 里不是消失，而是升级成了规则设计者和最终裁决者。

六、实战案例：代码修复闭环比"文案重写"更有说服力

文案场景适合入门；对技术团队而言，自动修复代码更能体现 AI Loop 的价值，因为"是否成功"有明确的外部信号。

text 复制代码

Issue / 失败测试
        ↓
LLM 分析并生成最小补丁
        ↓
隔离环境执行 format → lint → test → 安全扫描
        ↓
  通过 ─────────→ 创建候选变更 → 人工审查/合并
    │
  失败：收集报错、覆盖率变化、diff 摘要
    ↓
将可控上下文反馈给 LLM，进入下一轮或切换策略

实施过程

定义完成条件：目标测试通过、lint 为零、覆盖率不低于基线、变更文件在允许范围内、无敏感文件变动。
限制执行环境：在沙箱容器运行测试；模型只有读代码和写候选补丁的权限，不能直接合并或访问生产凭证。
构造反馈包：返回失败测试名、精简堆栈、相关文件片段和上轮 diff，而不是把整个仓库塞回上下文。
设置止损条件：例如最多 3 次补丁、最多 10 分钟、成本上限、相同失败指纹连续两次即停止。
交付与审计：通过后仍以 Pull Request 交给人审；保留每轮命令、结果和模型版本。

在这个案例中，LLM 的价值是理解自然语言 Issue、关联代码和提出修复方案；测试框架的价值是给出可信的硬反馈；状态机的价值是让失败可以被控制，而不是让模型在错误路径里无限"反思"。

七、生产环境最常见的坑

1. 模型自评不等于真实质量

同一个模型既出题又判卷，容易产生偏差。解决办法是把硬规则交给程序，语义评估使用固定评测集持续校准；对高风险决策增加人工抽检或独立评估器。

2. 只关注成功率，忽略"静默退化"

模型和 Prompt 没改，输入分布、检索内容、上游模型版本也可能变化。传统模型服务中，漂移监控会比较线上输入/输出与基线分布，并在阈值越界后触发复评或再训练；LLM 工作流同样需要监控任务分布、拒答率、Schema 失败率、质量分数和业务指标。

3. 多轮调用导致成本和时延失控

解决顺序通常是：前置本地规则 → 缓存可复用结果 → 并行无副作用任务 → 缩小反馈上下文 → 限制轮数与预算 → 必要时降级到模板或人工。不要把"重试"当成质量保证。

4. 工具调用扩大安全边界

当 Loop 能访问数据库、浏览器或支付系统时，提示注入可能从"生成错误文字"升级成"执行错误动作"。应将外部内容视为不可信数据；隔离指令与数据，采用工具白名单、最小权限、参数 Schema、审批门和可撤销操作。

八、AI Loop 的未来：LLM 负责智能，系统负责控制

未来的 AI 系统不会只靠更强大的模型，也不会只靠更复杂的 Agent 框架。更可靠的形态是分层协作：

LLM 擅长理解非结构化需求、生成候选方案和处理长尾异常。
规则引擎、状态机和类型系统保证确定性流程。
评测、监控、回滚和治理机制提供持续反馈。
在边缘环境中，轻量模型和本地规则处理敏感、低时延任务，云端承担复杂推理；通过量化、缓存、异步队列和断网降级控制资源。

这也是为什么评估驱动开发会越来越重要：先写清楚任务的验收集、风险阈值与回归指标，再选择模型和设计 Prompt。没有测量，Loop 只是在重复；有了可靠反馈，循环才是在逼近目标。

总结

AI Loop 的本质不是"让模型多想几轮"，而是用状态、评估、决策与边界，把概率性的模型输出纳入确定性的工程系统。

开始实践时，不必一上来就构建多智能体平台。选一个验收标准明确、失败可观测、风险可控的任务，先实现：一次生成 + 一次确定性校验 + 有限重试 + 明确兜底。等指标和失败样本积累起来，再加入语义评估、工具调用、漂移监控与人工审批。

让模型负责创造，让系统负责刹车和验收，才是把 AI 从聊天窗口带进生产流程的关键一步。

别只会改 Prompt：用 AI Loop 把大模型变成可验收的执行系统