不过，

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

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

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

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

使用者痛点：很多团队在实际项目中只能靠“写更长的 Prompt”来提高质量。却发现模型仍然时好时坏，导致交付不稳定、返工频繁，难以形成可预测的产品交付节奏。

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

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

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

一、从“一次生成”到“可控闭环”

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

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

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

使用者痛点：缺乏明确的成功标准和退出条件。使得项目在出现错误时陷入无限循环或被迫手动干预，导致成本失控。

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

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

This mirrors negative feedback in control ory: system observes gap 娱乐ween current output and goal,n adjusts its next action accordingly. In LLM workflows,evaluation signals can come from programmatic rules。tests,retrieval evidence,model reviews,and user feedback—not just model’s self‑assessment.

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

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

二、AI Loop 的主要架构

A production‑ready architecture can be split into six layers:

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

The most often overlooked layer is “Decision & State Machine”. A naive -loop with a single boolean flag only allows blind retries;话说回来，a real decision engine selects actions based on failure reasons .

三种常用模式

模式	流程	适合的任务	注意点
闭环反馈式 生成 → 评估 → 修复	文案 / 信息抽取 / 格式化 评估标准需明确迭代调整式产生候选 → 打分/搜索 → 保留最优 方案选择评分函数决定上限	需要严格结构化输出且可以局部修正的场景。	确保每轮都有确定性校验，否则会陷入无限循环。
规划—执行式 计划 → 调工具 → 观察 → 再计划	工单 / 数据分析 /研发助手 工具权限与副作用受控。	需要调度外部程序并根据实时观察调整计划。	要对工具调用设限。
多智能体协作 + 多模态融合	不同角色审阅与分工 + 图像·语音·文本感知纳入反馈回路	高复杂度业务，如客服机器人、多媒体内容审核。 成本上升，需要明确收益与治理策略。

用 Harness 把“自主”装进笼子

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

*目标层*:任务定义是否能拆成可验收子目标？成功标准是否可测，不过，*执行层*:生成/工具调用白名单；参数校验，超时；幂等，其实，副作用控制 *评估层*:硬规则、事实验证、语义审查还有业务指标分层组合 *治理层*:资源与风险，降级方法，审计日志。人工审批门槛

层级	约束对象

A usable AI Loop should have **Loop** driving progress while **Harness** provides brakes and rerouting. Without Harness loop is just “model guessing repeatedly”;without Loop Harness is static rule enforcement that cannot handle long‑tail anomalies.

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

The quality ceiling of a closed loop is usually set by evaluator rar than generator. Practical principle:

Taking demo of “Xiaohongshu beauty copy” as example,hard rules such as “title contains number”,“body ≤ N characters”,“ending CTA present” can be validated locally via regex or length checks. The subjective rule “looks viral” is best left to a semantic reviewer .

评估层级:
再看硬规则，JSON Schema / 长度 / 正则 / 权限 / lint / 单元测试.
再看事实规则，检索来源 / 工具返回值 / 引用可访问性.
说到语义规则，相关性 / 风格 / 一致性 / 有害性.
业务指标的观点是。解决率 / 人工转接率 / 时延 / 单位成功成本.

The evaluator should emit machine‑consumable feedback rar than a simple “fail”. Example JSON protocol:

{
从"pass"来看，false,"issues":
}

This structured evidence enables targeted repair in next round instead of re‑sending whole context to model – saving cost and reducing error propagation.

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

The demo already shows a skeleton: generate – check – exit with limits on rounds,total tokens and duplicate outputs.

The following pseudo‑code abstracts away any specific provider and focuses on state management,budgeting and branching logic.

const limits = { maxRounds: 5,maxTokens: 8000,timeoutMs: 20000 };async function runLoop {
const state = { round:0。totalTokens:0,lastHash:'',issues: };while {
state.round +=1;const candidate = await generate;state.totalTokens += candidate.tokens;if === state.lastHash) return fallback;state.lastHash = hash;const hardResult = validateLocally;老实说，const semanticResult = hardResult.pass
await evaluateSemantically
: { pass:false。issues:hardResult.issues };state.issues =;if return deliver;if ) return escalate;老实说，}
return fallback;}

• Total budget accounting: All token usage—including generation,evaluation and tool calls—is accumulated for stop‑conditions.
Hard‑first strategy:Local validation failures skip expensive semantic review. Replayable state:Each round logs model version,input summary,output hash,failure reason and stop cause for debugging. Controlled side‑effects:Writes are gated by least‑privilege APIs,schema validation。idempotency keys and optional human approval.

If your provider supports structured outputs,prefer Schema constraints so that fields are type‑checked before your business logic consumes m. Still handle refusals,timeouts and downstream violations gracefully.

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

适合的场景

• 输出有明确格式／规则要求​
• 失败后可以“可修复地重试”​
• 单轮结果不稳定，但多轮迭代能收敛​
• 重复性高、人盯盘耗时​
​ ​ ​ ​ ​ ​ ​​ ​

示例包括信息抽取､代码补丁生成､文案合规检查､测试用例生成､数据清洗等。

不适合或需谨慎使用

• 目标本身开放／审美／价值观敏感​
• 失败代价极高且无法回滚​
• 无法低成本验证对错​
• 实时性要求极低容忍延迟​
​​

“减少人的参与”并非让人消失，而是把人的角色从 每轮盯着 Prompt 调整 升级为 前置设计目标／验收标准＋异常兜底。

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

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

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

实施过程 ​

1. 定义完成条件 :目标测试全部通过；lint 为零，覆盖率≥基线；老实说，变更文件在白名单范围内且无敏感文件修改。
2. 限制执行环境 :在沙箱容器中运行测试；按理说，模型仅拥有读代码和写候选补丁权限，无直接合并或生产凭证访问权。按理说，
3. 构造反馈包 :返回失败测试名・精简堆栈・相关文件片段・上轮 diff。而非整个仓库上下文，
4. 设置止损条件 :最多 N 次补丁／最多 M 分钟／成本上限／相同错误指纹连续两次即停止。话说回来，
5. 交付与审计 :通过后仍以 Pull Request 提交给人审；保留每轮命令・结果・模型版本日志。

---