先交代一个背景。上个月我们接了一个内容生成引擎的优化项目客户年度预算只批下来 11K隔壁团队却在同一件事上拿到了 60K。放到多数公司里这种预算差基本就意味着认输——你拿什么跟别人比但最后盲评环节我们这边赢了客户给的评语是你们的第一版不是最惊艳的但每一版都在变好终稿和初稿几乎不像同一个东西。这句话不是我编的它对应的其实是我们把管线里的一个关键环节换掉了传统的大规模生成加筛选被我们换成了基于 ToolLoop 的精修循环。这篇就把这次对比的完整过程写出来包括钱花在哪、循环怎么搭、以及几个只有真正跑过才会踩到的坑。无论你是在做大模型应用、内容生产还是自动化工作流这套思路应该都有参考价值。1. 先拆解一下11K 与 60K 的钱分别花在了哪里很多人在听到这个对比时第一反应是是不是 60K 的团队不会花钱不是。他们的方案非常标准标准到几乎所有团队都会这么做。问题不在执行而在结构。1.1 60K方案的典型花法60K 团队的策略概括起来就是四个字广撒网。每一个需求进来他们调用大模型批量生成 50 到 100 个候选版本然后用一个稍便宜的模型做打分筛选或者直接让初级编辑人工挑。这个流程在大模型应用刚火的那两年堪称黄金标准管理简单、逻辑直观、开发成本低。但钱花在哪里花在生成次数上。做一个需求假设生成 50 个候选每个候选消耗 2000 token一次需求就是 100K token 的消耗。一个月下来需求一多预算自然冲到 60K。这并不是他们乱花钱。在他们的管理逻辑里多生成必然有好结果就像买彩票多买几张中奖率更高。这条逻辑在采样阶段是成立的问题出在它只停留在采样阶段。1.2 11K方案的预算分配我们只有 11K。刚开始也想学他们批量生成结果一算账就清醒了按他们的做法一个需求就要吃掉几百块一个月做完三分之一需求预算就光了。所以我们做了一个非常反直觉的决定把候选数量砍到 5 到 10 个把省下来的预算全部投进一个循环里。预算变成三块一部分做种子生成一部分做评估器调用剩下的大头全部用来支付修改-再评估的迭代费用。简单说他们用预算购买广度和候选数量我们用预算购买深度和修正次数。这个差异直接决定了后面所有结果的走向。1.3 为什么多数人默认贵方案更稳筛选方案的优势在于可预期。它有清晰的时间线有明确的并行度出了问题容易解释。管理层看到的是我们给 50 个方案做了投票最后选出最好的那个这个叙事让人安心。精修方案的风险在于它的质量和循环设计强相关。评估器准不准、反馈信号好不好、停止条件合不合理任何一个环节出问题整个流程都会崩盘。它开发成本高第一次跑可能跑不通所以大多数人默认贵方案更稳。但这里藏着一个隐藏假设多次独立采样是最优策略。这个假设在生成方差高、且没有反馈机制时是成立的。可一旦你引入评估器和修改指令这个假设就不再成立——因为版本之间的质量不再是独立同分布而是沿着反馈单调上升的。预算多并不必然意味着赢结构决定了上限。2. ToolLoop 到底改了什么从漏斗式筛选到闭环式精修聊清楚了预算账接下来解释 ToolLoop 的本质。它不是什么神秘的新框架而是在 Agent 工作流社区里逐渐流行起来的一类设计模式让模型驻留在一个循环里循环体中调用工具获取反馈把反馈写回上下文再生成下一个版本。2.1 筛选流程的本质传统筛选流程的结构是漏斗型的。输入一个需求批量生成大量候选然后用规则或者模型打分把不合格的滤掉最后挑出最高的那个输出。这个过程本身没有问题它的数学本质是多次采样取最大值。只要候选数量够多大概率能捞到一个不错的。但它的致命弱点也在这里你生成的 100 个版本里除了最后被选中的那 1 个其余 99 个的信息全部被浪费了。更麻烦的是候选版本之间没有任何继承关系。第 50 个版本不会因为前 49 个版本的错误而变得更好它们是平行宇宙里的 50 次独立抽取。筛选只是在等概率事件里碰运气。2.2 精修循环怎么闭环ToolLoop 的结构则是环形的每一步输出都会回到循环里。先由生成器产出一个种子版本评估器对这个版本打分并列出问题模型带着当前版本修改建议再次生成。新版本进入评估器分数不达标就再来一轮直到分数收敛或超过阈值。这里的工具不一定是另一个大模型。在文案任务里工具可以是评分模型、风格检查器、关键词覆盖检测脚本在代码任务里工具可以是编译器、测试用例、静态检查工具。ToolLoop 这个名字本身就是两个关键词的拼接Tool工具调用和 Loop循环。关键区别在于每次生成都在使用上一轮的错误信息和修正指令。第 6 轮的版本不是第 1 轮的重试而是第 1 轮的超集是带着所有历史反馈生长出来的结果。2.3 把筛选换成精修这一句话里的三个隐藏改动这句话看起来简单实际操作里包含三个改动。第一输出单元从一批结果变成了一个可迭代的结果。筛选关注的是这批里哪个最好精修关注的是这个结果如何变得更好。单位变了管理指标也得跟着变。第二评估的角色从终点裁判变成了过程教练。筛选里的评估是用来淘汰的精修里的评估是用来指路的。裁判只需要给分数教练必须说出来你这里缺证据、那里逻辑跳跃、第三段建议重写。第三成本结构从一个不可控的天花板变成了一个可控的范围。筛选的成本随候选数线性增长而精修的成本是循环轮数乘以单轮成本有明确的停止条件可以封顶。只要你设置了最大轮数最坏情况是可以算出来的。3. 为什么精修能赢有效信息利用率的差距应该会有人问即使逻辑上说得通精修真的能比大规模筛选更强吗我们用一个模型来说明这个问题。3.1 筛选是在矮子里面拔高个假设单次生成的质量服从一个以 60 分为中心的正态分布最好的候选可能在 70 到 75 分之间。你生成 10 个候选、50 个候选本质上都是在反复抽取这个分布期望最大值会缓慢上升。但这里面有两个问题。第一收益递减非常明显。从 10 个涨到 50 个期望最大值的提升很有限而成本涨了 5 倍。第二候选之间相互独立生成过程中的错误不会自我修正。如果你某次生成的逻辑本身就是错的再来 100 次大概率还是同样类型的错。筛选的上限是单次生成分布的上沿而不是这个任务的最优解。你花了大把钱可能只是从 60 分走到了 70 分。3.2 精修是在同一份资产上做连续优化精修的逻辑完全不同。初版可能只有 50 分但评估器指出问题后模型改到 65 分再改到 75 分再改到 85 分。每一步消耗的 token 和筛选的一次生成差不多但收益在累加。它的数学直觉是每一轮修正都不是独立采样而是沿着一组决策梯度做局部搜索。评估器给出的建议相当于梯度信号修改过程相当于参数更新。它不是靠数量撞大运而是靠反馈逼近目标。成本曲线也不太一样。每轮循环的固定开销是可预估的一般到第 6 轮左右收益饱和再改下去分数不会明显上升。所以我们可以用 3 到 6 轮的成本得到一次高分结果。打个比方筛选像是在一个果园里反复摘果子摘完最熟的那个剩下的就浪费了。精修像是种一棵树不断施肥、修剪、调整光照让这棵树的产量超过整个果园。3.3 什么时候精修赢面最大精修不是在所有任务上都灵它有明确的条件。第一个条件是任务有可判定的质量标准。你至少能说清楚什么样的结果是好的。第二个条件是错误可以被定位和描述。如果评估器只能说不够好那循环就转不起来。第三个条件是模型对反馈能做出有效修正。这一条和模型能力有关能力越强的模型越能从建议中提取有效信息。文案改写、代码调优、结构化报告生成、方案设计这一类任务全都满足条件。反过来创意发散、命名头脑风暴、完全靠灵感的任务精修的优势就不大筛选或采样反而更合适。4. 手把手搭一条 ToolLoop 精修管线如果看到这里你准备在项目里试一下我直接把我们跑通的方案摊开来讲。这条管线我们用 Python 实现核心部分不到 100 行难点其实不在代码。4.1 先定评估器循环的方向盘评估器决定了整个循环的质量。最好的组合是一个便宜模型打分、再加一个确定性规则做兜底而不是一上来就用最强模型当评估器。我们当时把评估维度拆成了四类信息完整度、逻辑一致性、表达自然度、合规度。每一项打 0 到 10 分。注意只给总分没有用模型拿到7 分并不知道自己哪里有问题。评估器必须给出可执行的整改项例如第三段缺少最近三年的对比数据建议补充两条量化证据并在段尾加一句结论。这个细节是整个管线里最重要的。评估器不是用来淘汰的是用来指路的。它的输出越具体循环收敛越快。4.2 循环主体的代码骨架下面这段代码是我们最初版本的核心也是理解 ToolLoop 的最短路径def tool_loop(seed_prompt, evaluator, generator, max_rounds6, target_score85): current generator(seed_prompt) best_result, best_score current, -1 scores [] for step in range(max_rounds): result evaluator(current) total_score result[total] advice result[advice] scores.append(total_score) if total_score best_score: best_result, best_score current, total_score if total_score target_score: print(f达标第 {step 1} 轮) break current generator( seed_prompt \n当前版本:\n current \n修改建议:\n advice ) return best_result, scores这里有两个设计值得注意。第一个是始终返回 best_result 而不是最后一版。因为循环过程里某一轮可能改坏如果把最后版本直接交出去你连退路都没有。保留历史最高分版本至少不会比初版差。第二个是种子 prompt 一直被保留在上下文里。这样模型在修改时不会跑偏始终知道原始需求是什么。很多循环跑歪就是因为修改指令逐渐覆盖了初始目标。4.3 反馈信号的写法比想象中重要反馈信号写得好不好直接决定循环是向上收敛还是原地打转。反例是这样的整体一般请优化一下让它更有吸引力。模型接到这种指令基本靠猜它不知道往哪个方向改改完还是会被打低分循环陷入死循环。正例是这样的第一段信息密度偏低当前只有背景描述建议补充 2020 到 2024 年的用户增长数据并以一个对比结论收尾第三段存在逻辑跳跃建议补一句因果说明连接现状和建议之间的推导关系。反馈里的每一个条目都应该是位置问题修改方向。你可以把评估维度直接转化成问题清单模板这样每次输出的格式都稳定模型执行起来也不会迷惑。4.4 停止条件与成本护栏成本失控是精修方案最容易被攻击的点。设计护栏时有三个参数需要提前定好。第一个是最大轮数。我们一般设置 6 轮实测下来前 4 轮改善最明显第 5、6 轮只是微调。第二个是目标分数。达到阈值直接跳出不再多花一分钱。第三个是连续两轮分数不再上升的早停机制避免它在原地磨洋工。模型选型也可以分级。评估用小模型修改用中等模型关键需求才启用最强模型。很多人一上来就把最强模型塞进循环每轮烧掉大量 token成本精准爆炸。精修循环里真正吃钱的是迭代次数把单轮成本压下来整体预算才有可能控制在 11K 这个量级。5. 实测对比同一批需求下的质量与成本账光讲原理容易飘直接看我们当时拿 40 个真实需求跑的对比数据。两组方案处理完全相同的任务。5.1 评测方法与指标A 组模拟的是 60K 筛选方案每个需求生成 50 个候选用打分模型选最高分输出。B 组是我们的 11K 精修方案每个需求生成 5 个种子取一个进入循环最多精修 6 轮。打分方是三位外部人工评审不看方案标识从信息完整度、逻辑性、表达质量、贴合需求程度四个维度给终稿打分百分制。除此之外还统计了达标率分数大于 80 算达标以及返工率指交付后因质量问题被打回修改的比例。5.2 四条流水线的结果这个表格是我们当时周报里的核心内容。方案总成本平均分达标率返工率单需求耗时60K筛选约6万7265%30%12分钟11K精修约1.1万8192%8%8分钟一个小提醒这个对比不是严格的对照组因为生成模型并不完全相同。A 组用的是开源的通用模型批量采样B 组在循环里额外使用了更针对性的修正指令。但两组共享同一个需求池和同一个评分标准方向上足够说明问题。5.3 这份成绩单怎么读B 组平均分高并不是因为种子生成器更强而是因为终稿根本不是一个版本的产物。它是经过 5 到 6 轮反馈后收敛出来的结果每一轮都在吸收上一轮的错误并修正。初版也许只有 55 分但终稿稳定落在 80 到 88 分区间。返工率从 30% 降到 8% 是更值得关注的数字。人工审校本身是巨大的隐性成本筛选方案虽然只用高分的候选但高分候选和完美贴合需求之间仍有距离交付后依然要来回打磨。而精修方案的循环本质就是在交付之前完成打磨所以打回率自然低。这份成绩单读下来的结论是11K 胜出不是因为低配碰巧赢了高配而是流程结构本身更优。6. 踩过坑之后我对 ToolLoop 的使用建议最后讲讲那些真正跑过才会发现的坑。我按踩坑频率排个序每一条背后都是真金白银的教训。6.1 五个常见的翻车姿势第一个坑是评估器太弱反馈空泛。这是所有循环失败的最常见原因。模型拿到不够好请优化这种反馈只能瞎猜循环一万轮也白搭。评估器必须落到具体位置、具体问题、具体修改方向。第二个坑是没保存历史最高分版本。有一轮模型自作主张把一个原本不错的段落改得面目全非因为没有保留上一轮我们只能从初版重新跑白白浪费了四轮迭代。从那以后best_result 的保留就写进了所有代码。第三个坑是反馈上下文越堆越长。前期我们把每一轮的建议都累积进下一次 prompt很快 token 开销失控。后来改成只保留最新一轮建议或者把历史建议压缩成一张评分卡。第四个坑是把循环并行化。精修的核心是连续性上一轮的输出必须完整传递给下一轮。为了追求吞吐量强行并行等于拆掉了反馈链路最终结果和筛选没有本质区别。第五个坑是不知道什么时候停。没有停止条件的循环会越改越油语言越来越花哨反而偏离任务本身。目标分数和早停条件必须在项目启动前就定好。6.2 哪些任务不适合精修循环也不是所有任务都适合这套玩法。纯创意发散类任务比如起名字、策划脑洞、头脑风暴没有明确的标准答案评估器根本给不出有效梯度信号循环只会把内容往奇怪的方向拧。还有一种情况也不适合任务本身一次生成就能到 90 分或者需求不要求完美差不多就行。在这种情况下循环多花的每一分钱都是浪费。精修是给重要且可打磨的任务用的不是给所有任务加仪式感的。6.3 如果预算不是限制我还是会这么选现在可以回答标题里最尖锐的问题了如果有 60K 预算最优解是什么我的答案变了。如果预算充足我不会再把全部预算押在批量筛选上而是采用小规模筛选精修的组合。先筛出前 3 名种子然后对每个种子单独跑 ToolLoop 循环。这样既保留了候选多样性又能利用反馈机制逼近更高质量。60K 方案的问题不在预算多而在它把预算全花在了漏斗上没有一分钱花在让结果变好上。这套思路现在成了我做类似项目的默认框架。先问自己三件事任务有没有清晰的评价标准评估器能不能给出可执行的修改意见模型对反馈做出修正的效率如何三个都满足直接上 ToolLoop满足不了再去堆采样。最后说点个人体会。我以前也是多生成、多筛选的忠实用户总以为质量是采样数量堆出来的。直到那个预算只有 11K 的项目逼着我换思路才意识到反馈的价值被太多人低估了。现在遇到新任务我第一个问题不再是这个月能生成多少次而是这个任务的评估器能不能给出让模型可执行的修改意见。能就上 ToolLoop不能再去堆采样。这个判断比任何工具本身都值钱。