先说结论
最近 Loop 工程这个词很热，听起来像一门新手艺。我的看法是：思想是冷饭，但这碗冷饭现在才真正能吃上。
冷饭的部分：让系统自己迭代，用一套评价标准判断每一轮做得好不好，再根据反馈调整，直到达标。这就是机器学习最基础的训练循环，也是控制论里的反馈回路。
新的部分：以前循环里被调整的东西必须是数字（模型参数），现在被调整的可以是一段文字、一个文件、一份知识库，反馈也可以是一句人话。所以这个套路第一次能用在开放式的任务上。
下面先从机器学习最基础的训练讲起，再用三个真实的 Agent 任务把 Loop 工程拆开看。
一、先回到最熟悉的地方：训练一个识别狗的模型
假设要训练一个模型，判断图片里有没有狗。整个过程只有五个零件：
| 零件 | 在狗模型里是什么 |
|---|---|
| 目标 | 识别准确率达到 95% |
| 可调整的东西 | 模型的参数（几百万个数字） |
| 评价标准 | 损失函数：对比预测和标准答案，算出"错得有多离谱" |
| 反馈 | 梯度：告诉每个参数该往哪个方向调、调多少 |
| 停止条件 | 准确率达标，或训练了 N 轮，或连续几轮没进步 |
然后是一个循环：
text
while 没达标:
预测 = 模型(图片) # 做一轮
损失 = 损失函数(预测, 标准答案) # 评价这一轮
梯度 = 反向传播(损失) # 哪里不好、怎么调
参数 = 参数 - 学习率 * 梯度 # 调整注意分工：模型自己不知道自己对不对，是外面的损失函数在打分。模型只负责"做"，调整的方向由评价体系给出。
二、把同一个骨架套到 Agent 上
换成让 Agent 做事，零件一个不少，只是换了载体：
| 零件 | 训练狗模型 | Loop 工程 |
|---|---|---|
| 目标 | 准确率 95% | 类型检查和测试全部通过 / 评测集准确率 90% |
| 做一轮 | 模型做预测 | Agent 完成一部分任务，产出代码、答案或报告 |
| 评价 | 损失函数 | 编译器、测试、评测集、检查脚本、评分标准、另一个模型当裁判 |
| 反馈 | 梯度（数字） | 报错信息、失败用例、扣分说明（文字） |
| 可调整的东西 | 模型参数 | 工作区里的代码、提示词、外挂知识库、任务清单 |
| 停止条件 | 达标 / 轮数上限 / 早停 | 通过 / 迭代上限 / 预算上限 / 连续几轮没进步 |
画成一张图：
text
┌──────────── 目标 ────────────┐
▼ │
Agent 做一轮 ──▶ 评价体系打分 ──▶ 达标？──是──▶ 结束
▲ │否
│ ▼
└── 根据反馈调整 ◀── 哪里好、哪里不好先看一眼大模型的现状：今天的 Agent 单次对话已经相当能干，简单任务一次就对。Loop 工程真正解决的是另一类问题：
- 任务太大，一个对话的上下文装不下，做到后面越来越乱
- 任务太开放，一次做出来的结果质量不稳定，十次里有三次翻车
- 没人盯着，翻车了也没人发现，错误一路往下传
下面三个案例，分别对应这三类问题。
三、案例一：把几百个文件从 JavaScript 迁移到 TypeScript
任务和难点
团队有一个前端项目，300 多个 .js 文件，要全部迁移到 TypeScript，并且迁移后项目必须能编译、测试必须全部通过。
直接把这个任务丢给 Agent 一次做完，常见的结果是：
- 前四五十个文件做得不错，后面开始偷懒，大量使用
any - 上下文越来越长，前面定义的类型它忘了，后面又重新定义一遍
- 做到一半说"已完成"，实际还有几十个文件没动
- 最后的编译错误一次冒出几百条，没人知道从哪改起
这不是 Agent "傻"，是任务的体量超出了单次对话的承受范围。
用 Loop 怎么搭
1. 把大任务拆成一份清单，放在文件里
text
TODO.md
[x] src/utils/date.js
[x] src/utils/format.js
[ ] src/api/user.js
[ ] src/api/order.js
...清单是整个 Loop 的"记忆"，每一轮结束它都在，不依赖对话上下文。
2. 每一轮只做一小步，并且从全新的上下文开始
每一轮的指令很简单：读清单，挑一个没做的文件，迁移它，跑检查，通过就打钩并提交，然后结束。下一轮是一个全新的对话，没有前面累积的杂乱上下文，只有清单和代码库本身。
3. 评价体系是 Agent 改不了的编译器和测试
text
评价命令：
tsc --noEmit # 类型检查，不允许新增 any 之外的豁免注释
npm test # 全部测试
检查脚本：grep 出 @ts-ignore 和 as any 的数量，不得增加4. 反馈：把编译器的报错原样交给下一轮
编译器输出的 error TS2345: Argument of type 'string' is not assignable to parameter of type 'number' 就是精确的诊断，比任何总结都有用。
5. 停止条件：清单全部打钩且检查通过；或者最多跑 N 轮；或者连续两轮失败数没下降（说明卡住了，需要人介入）。
下面是这个循环的最小骨架。它只做三件事：调用 Agent、调用评价命令、判断要不要停。我用桩命令跑过它的控制流（达标退出、卡住退出两种情况都验证了），但没有接真实的 Agent：
bash
#!/usr/bin/env bash
# 骨架：做一轮 -> 外部评价 -> 反馈留给下一轮 -> 停止判断
# AGENT_CMD：让 Agent 做一轮（每轮全新上下文）
# EVAL_CMD ：评价命令，退出码 0 代表达标，Agent 无权修改它
MAX_ITERS=${MAX_ITERS:-10}
PATIENCE=${PATIENCE:-2}
best_fail=999999; stale=0
for i in $(seq 1 "$MAX_ITERS"); do
echo "== 第 $i 轮 =="
bash -c "$AGENT_CMD" # 1. Agent 做一轮
bash -c "$EVAL_CMD" > eval.log 2>&1 # 2. 外部评价
if [ $? -eq 0 ]; then echo "达标，停止"; exit 0; fi
fails=$(grep -c "FAIL" eval.log) # 3. 用失败数衡量进展
if [ "$fails" -lt "$best_fail" ]; then best_fail=$fails; stale=0; else stale=$((stale+1)); fi
if [ "$stale" -ge "$PATIENCE" ]; then echo "连续 $PATIENCE 轮没进步，停止"; exit 2; fi
cp eval.log feedback.txt # 4. 反馈留给下一轮读取
done
echo "达到轮数上限，停止"; exit 3社区里流行的 Ralph loop，本质上是这个骨架最朴素的写法：一个 while 循环，每次把同一份任务说明喂给 Agent，让它读文件里的进度继续干。区别只在于，生产环境里要给它加上预算上限和停止条件，否则就是在无限烧钱。
成功率为什么能提上去
| 一次性丢给 Agent | 用 Loop | |
|---|---|---|
| 上下文 | 越积越长，后期质量下降 | 每轮干净，只带清单和反馈 |
| 完成度 | 靠 Agent 自己说"做完了" | 靠编译器和测试判断 |
| 错误处理 | 最后一次性爆出几百个错误 | 每个文件当场发现、当场修 |
| 出问题时 | 不知道从哪回滚 | 每轮一次提交，可以精确回退 |
我没有对这个场景做过实测，所以不给具体的成功率数字。需要说明的是，这里面最关键的不是"多跑几次"，而是把"做完了没有"这件事，从 Agent 的自我感觉，换成了编译器的判断。
四、案例二：让客服 Agent 把工单处理得更准
任务和难点
公司有一个客服 Agent，负责把进来的工单分类（退款 / 物流 / 账户 / 其他），并给出建议回复。上线后发现：一部分工单分错类，导致转给了错误的团队。
这次要调整的不是一份代码，而是 Agent 自己的配置：提示词和它能检索的知识库。这和训练狗模型最像，因为是在"调参"，只是参数换成了文字。
用 Loop 怎么搭
1. 先准备评价集：一批已经人工标好正确答案的历史工单
比如 200 条。它就是狗模型里"带标准答案的图片"。再把其中的 40 条单独留出来，整个调整过程都不看，只在最后检验一次。这是机器学习里训练集和测试集分开的老规矩，不这么做，最后看到的高分只是"提示词背熟了这些题"。
2. 跑一轮，看成绩，更要看错在哪
下面的数字是我为说明而虚构的示意，不是真实实验：
text
第 1 轮 配置 v1 准确率 72%
错误分析（按类型归并）：
- "包裹显示已签收但没收到" 被分成"其他"（应为物流） × 17
- "想更换绑定手机号" 被分成"其他"（应为账户） × 12
- "退款到账慢" 被分成"物流"（应为退款） × 8
- 其余零散错误 × 73. 让另一个 Agent 读错误分析，提出配置修改
text
v2 的改动：
- 提示词增加规则：包裹异常（签收未收到、丢件、破损）一律归为物流
- 提示词增加规则：更换手机号、邮箱、密码都归为账户
- 知识库补充 12 条"退款 vs 物流"的区分例句4. 重跑评价集，确认涨了，而且没有把原本对的改错
text
第 2 轮 配置 v2 准确率 86%（训练部分）
第 3 轮 配置 v3 准确率 91%
第 4 轮 配置 v4 准确率 91%（没进步）→ 停
最终：用留出的 40 条检验一次 → 88%注意最后一行：留出集上的 88%，比调整过程中的 91% 低一点，这是正常的。这个差距恰恰是最诚实的数字。
成功率为什么能提上去
| 靠人拍脑袋改提示词 | 用 Loop | |
|---|---|---|
| 怎么知道改好了 | "感觉好像好一点" | 在同一批题上对比前后准确率 |
| 怎么知道改什么 | 凭印象猜 | 错误分析指出具体的错误类型 |
| 会不会改坏别处 | 不知道 | 每轮重跑整个评价集，退步马上看到 |
| 什么时候收手 | 改到不想改为止 | 连续几轮没进步就停 |
这个案例里，评价集本身就是资产：它能在你下次换模型、改流程的时候，立刻告诉你效果变好还是变差。
五、案例三：让 Agent 写竞品调研报告（评价变"软"的情况）
任务和难点
让 Agent 调研三个竞品，输出一份给产品经理看的对比报告。这类任务没有测试用例，"好不好"看起来全凭感觉。
一次生成的典型问题：
- 数字没有来源，或者来源页面里根本没有这个数字
- 对三个产品的描述篇幅、深度不一致
- 结论泛泛而谈，"各有千秋"
用 Loop 怎么搭
软任务的关键是：把"好"拆成能逐条检查的小问题，而且尽量让其中一部分检查是确定性的，不靠模型的主观判断。
| 检查项 | 怎么检查 | 硬 / 软 |
|---|---|---|
| 报告里每个数字都有来源链接 | 脚本提取数字和链接，逐个确认链接可访问 | 硬 |
| 数字在来源页面里真实存在 | 脚本抓取页面，搜索该数字 | 硬 |
| 三个竞品都覆盖了相同的维度 | 对照维度清单逐项勾选 | 半硬 |
| 结论是否给出明确建议 | 另一个模型按评分标准打分，并写出扣分理由 | 软 |
流程：
- Agent 写初稿
- 检查脚本跑硬指标，裁判模型跑软指标，合并成一份带具体位置的问题清单（例如"第 3 段的 '市占率 23%' 在引用页面中找不到"）
- Agent 只针对清单上的问题修改，不要整篇重写，避免改好的地方又被改坏
- 再检查，最多跑 3 到 4 轮
成功率为什么能提上去
最大的收益来自硬指标：没有来源的数字、编造的引用，被脚本当场拦住。这类错误人工审稿最容易漏，却最伤可信度。
但要老实说：这类 Loop 的天花板比案例一、二低。
- 裁判是模型，自己有偏差，同一篇报告两次打分可能不一样
- 模型裁判常常偏爱更长、更华丽的文字，Agent 会越改越啰嗦
- "达标"本身是个模糊的判断
所以软评价的 Loop 更适合抬高下限、过滤明显的问题，而不是自动产出终稿。关键报告最后仍需要人来把关。
六、三个案例的共同点
把三个案例并排看：
| 案例一：代码迁移 | 案例二：客服工单 | 案例三：调研报告 | |
|---|---|---|---|
| 单次做不好的原因 | 任务太大，上下文装不下 | 配置不准，凭感觉调 | 开放任务，质量不稳 |
| 评价者 | 编译器 + 测试 | 带标准答案的评价集 | 脚本 + 评分标准 + 裁判模型 |
| 反馈长什么样 | 编译报错 | 错误分析 | 带位置的问题清单 |
| 被调整的是什么 | 代码、清单 | 提示词、知识库 | 报告初稿 |
| 评价的"硬度" | 硬 | 较硬 | 软硬结合 |
共同的规律只有一条：Loop 的上限，由评价体系的质量决定。 评价越硬、越具体，Loop 越可靠；评价越软，越需要人。
七、几个容易误解的地方
1. Loop 里没有真正的"梯度"
狗模型的梯度是数学算出来的，方向精确。Loop 里的"梯度"是一段文字反馈，由大模型读懂以后自己决定怎么改。所以调整可能震荡：改好这一条，可能把另一条改坏；循环再多轮，也不保证收敛。这就是为什么必须有迭代上限、早停和回归检查。
2. 模型本身没变，变的是它周围的东西
训练会修改模型的权重，Loop 不会。大模型的参数从头到尾是冻结的，被调整的是工作区、上下文、提示词和知识库。案例一调整的是产出物，案例二调整的是 Agent 自己的配置，两者解决的问题不同：前者是"把这一件事做成"，后者是"让 Agent 以后做这类事都更准"。
3. 评价者不能由 Agent 自己控制
这是最重要的一条，也是和机器学习共通的最大教训。如果让被评价的一方决定怎么评价，它会学会"怎么拿高分"，而不是"怎么做对"。Agent 常见的作弊方式包括：删掉或改动失败的测试、针对测试用例硬编码答案、自己写测试自己通过然后宣布完成。
对应的做法：测试和评价脚本放在 Agent 没有写权限的地方；让写代码和写测试的由不同角色负责；保留一份 Agent 从没见过的验证集。社区里有句话说得到位：只对你能验证的东西做 Loop。
4. 评价要有"诊断"，不能只有"分数"
只有一个 72 分，Agent 只知道不够好，不知道往哪改。分数是损失值，具体的失败项和原因才是梯度。设计评价时，尽量让它输出"哪一项、哪个位置、为什么错"。
八、所以，是新技术还是冷饭？
冷饭的部分，占大头：
- 反馈回路：控制论里的恒温器，很早就是这个结构
- 迭代到达标：机器学习的训练循环、软件里"改了跑测试再改"
- 持续改进：PDCA（计划、执行、检查、改进）
- 评价集、早停、防止过拟合：机器学习的基本功
如果你已经懂这些，Loop 工程里八成的内容你一直在用，不必神化它。
新的部分，确实存在：
- 可调整的东西变了。 以前必须是能求导的数字，现在可以是一段文字、一个文件，开放式任务第一次能进入这个循环。
- 反馈可以是人话。 以前评价只能是数字，现在一条报错、一段点评就能直接驱动下一轮修改。
- "调整者"本身是个会推理的模型。 它能读懂反馈、总结教训，而不是沿着梯度机械地走。
- 新的风险。 评价者被钻空子、成本失控、裁判有偏差，这些在传统训练里没有这么突出。
另外要说明一下，这个词的边界目前还很模糊。 它和 Harness 工程（给 Agent 搭运行环境）、上下文工程有大量重叠，业内叫法仍在变化，不同文章里说的 Loop 工程范围并不完全一致。不必纠结词，抓住那五个零件就行。
更准确的说法是：新瓶装旧酒，但酒里加了一味新料，就是"调整"这一步，现在可以由一个能读懂文字反馈的模型来做。 这味新料让旧酒能用在以前够不着的地方，这就是它值得被重新讨论的原因。
九、动手之前的检查清单
想给自己的 Agent 加一个 Loop，先回答这六个问题：
- 目标是什么？ 能用一句话、最好能用一个数字说清楚吗？
- 谁来评价？ 评价者是不是 Agent 够不着的？有没有硬指标可用？
- 反馈里有诊断吗？ 失败时，Agent 能看到具体错在哪吗？
- Agent 能调什么？ 是改产出物，还是改自己的提示词和知识库？范围划好了吗？
- 什么时候停？ 有没有迭代上限、预算上限、连续几轮没进步就停？
- 怎么防退步？ 改好一处时，有回归检查保证没改坏别处吗？
一个简单的判断：答不上第 2 条，先别开 Loop。 没有可靠的评价，循环只会把错误更快、更自信地放大。
总结
- 本质：Loop 工程就是机器学习最基础的工程思维：目标、做一轮、评价、反馈、调整、再来，直到达标或停止。
- 解决的问题：任务太大装不下、任务太开放不稳定、没人盯着错误会传递。三个案例各对应一类。
- 上限由评价体系决定：编译器和测试最硬，评价集次之，模型裁判最软。
- 新与旧：思想是冷饭，新鲜的是"可调的东西可以是文字、反馈可以是人话"。
- 实践顺序：先找有硬评价的任务练手，再逐步尝试软评价；先把评价体系设计好，再让循环转起来。
说明：控制流骨架用桩命令验证过（达标退出、卡住退出），未接真实 Agent；案例二的数字为说明用的虚构示例；三个案例是对常见做法的归纳，案例一、三我没有做过完整实测，因此没有给出具体成功率；关于社区对 Loop 工程的描述来自公开文章，这个词的定义目前还不统一。
欢迎访问 PrimeSkills ------ 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
更多实用知识和有趣产品，欢迎访问我的个人主页