如何把 Loop 从 1 Sigma 推到 4 Sigma
作者：James Xie
这是「Loop Engineering」系列的第三篇，也是最后一篇。
你的 loop 完成率只有 30%。团队的第一反应是：“换更强的模型。”
一周后，GPT-5 上线了。完成率变成 35%。
问题不在模型。问题在你把一整个复杂任务塞进了一次黑盒调用，然后期待它不出错。制造业不会这样干——他们会把工序拆开、加质检点、留返工通道、设人工抽检。Agentic AI 也该这样。
这篇讲四个把 loop 从 1 Sigma 推到 4 Sigma 的工程杠杆：任务分解、独立验证、共识冗余、人工接管。
第一章：为什么换模型不是答案
先算一笔账。
假设你的 loop 有 10 个串联步骤，每步用当前模型准确率 90%。整体成功率是多少？
0.9^10 = 34.9%。
你把每步准确率提到 95%——这已经需要显著更好的模型或 prompt。整体成功率变成 0.95^10 = 59.9%。
看起来不错，但离”无人值守”还差得远。如果你的任务需要 20 个步骤，95% 每步也只有 0.95^20 = 35.8%。
这就是串联系统的残酷之处：局部的小幅提升，会被步骤数稀释成全局的微不足道。
换模型是战术，不是战略。它能让你的 loop 从 30% 提到 45%，但很难从 45% 提到 90%。真正跨越数量级的改进，来自改变 loop 的结构。
制造业里早就知道这个道理。你不可能靠买一台更精密的机床，把一条手工装配线的缺陷率从 10% 降到 0.1%。你要做的是：拆分工序、加质检、留返工、标准化输入、训练工人。这些不是更先进的机器，是更好的系统设计。
Loop Engineering 也一样。
贯穿案例：一个客服退款审核 loop
为了把四个杠杆讲具体，下面我们用一个真实会遇到的 loop 做主线案例：
自动退款审核系统。
用户提交退款申请后，agent 需要：
- 核验订单存在且状态允许退款
- 检查退货物流是否已签收
- 核对退款金额是否在订单金额范围内
- 评估用户提供的退款理由是否合理
- 做出批准/拒绝/要求补充材料的决定
- 生成给用户的回复文案
这个 loop 一开始是一条 6 步长链，每步准确率约 88%。整体完成率只有 0.88^6 ≈ 46%，连 2σ 都不到。人工兜底成本很高。
下面我们会用四个杠杆，一步步把它推到 4σ。
第二章：杠杆一 任务分解
任务分解不是把 prompt 写长一点，也不是让 agent “分步骤思考”。它是把一个大目标拆成多个可独立验证的小目标，每个小目标失败时可以单独重试，而不是让整段 loop 从头再来。
串联 vs 并联 vs 树状
最差的结构是单条长链：A → B → C → D → E。一步错，全盘错。
好一点的是树状结构：
用户需求
/ | \
子任务1 子任务2 子任务3
| | |
验证1 验证2 验证3
\ | /
合并输出每个子任务独立运行、独立验证。如果子任务 2 失败，你只需要重跑子任务 2，而不是整个 loop。
更好的结构是带依赖图的工作流：有些步骤可以并行，有些必须串行，有些可以回退到上一步修正。
分解到底能带来多少提升
光说”分解好”不够，要算清楚好多少。
假设一个任务需要完成 10 个逻辑步骤，每步准确率 90%：
- 单链整体成功率：
0.9^10 = 34.9%
现在把它拆成 5 个独立子任务，每个子任务包含 2 个步骤。每个子任务成功率是 0.9^2 = 81%。但每个子任务后面加一个验证器，验证器准确率 95%，验证通过才进入下一步。那么每个子任务的有效通过率是：
- 子任务本身成功 + 验证器通过：
0.81 × 0.95 = 77% - 子任务失败但验证器 catch 住（触发重试）：
0.19 × 0.95 = 18% - 子任务失败且验证器也漏掉（真正漏网）：
0.19 × 0.05 = 0.95%
如果每个子任务最多重试 2 次，那么单个子任务最终漏网率降到 0.95%^3 ≈ 0.000086%，基本可忽略。即使不算重试，5 个子任务串起来的整体成功率也从 35% 提升到 0.77^5 ≈ 27%——看起来还低了？
问题出在哪里：验证器会误判。验证器把很多本可以过的子任务也打回了。所以分解的收益不是免费的，它取决于验证器的质量。一个好的验证器要足够敏感（能抓住错误），又不能太敏感（不错杀正确输出）。
这就是为什么规则验证器比模型验证器更受欢迎：它们误判率低、成本低、行为稳定。
分解的边界在哪里
不是越细越好。分解到每个子任务满足三个条件即可：
- 单一职责：一个子任务只解决一个明确问题
- 可验证：有独立的通过/失败标准
- 可重试：失败后可以单独重跑，不依赖前面所有步骤
比如一个 “写周报” 的 loop：
- 坏分解：“先收集数据，再分析，再写结论”（每一步都太大，失败标准模糊）
- 好分解：“拉取本周工单 → 按类别统计数量 → 识别 top 3 问题 → 生成标题 → 生成正文 → 生成图表”（每一步可验证）
一个实用的分解原则
问自己：“如果这一步失败了，我最小需要回退到哪里？”
如果答案是”从头开始”，说明这一步还可以再拆。
另一个判断标准是：“这一步的输出，能不能被下一个步骤独立消费？” 如果子任务 A 的输出需要配合 A 自己的内部状态才能被 B 理解，说明 A 和 B 的边界还没切干净。
退款审核 loop 的分解
回到我们的案例。最初的 6 步长链是：
订单核验 → 物流检查 → 金额核对 → 理由评估 → 生成决定 → 生成回复问题很明显：
- “理由评估” 很模糊，什么样的理由算”合理”没有客观标准
- “生成决定” 依赖前面所有步骤，前面错一个，决定就错
- “生成回复” 只是文案工作，不应该和决策逻辑串在同一条链上
分解后变成：
[程序] 订单核验 ──┐
├→ [程序] 金额核对 → [Agent] 退款意图识别 → [Agent] 决策生成
[程序] 物流检查 ──┘ ↓
[Agent] 回复生成（独立，可并行）关键变化：
- “理由评估” 被改成了更具体的 “退款意图识别”——不是判断理由是否”合理”，而是判断用户是否明确表达了退款请求，以及是否提供了必要证据
- 订单核验、物流检查、金额核对这些有明确外部事实的，用程序调用 API / 查数据库，不用 agent
- 退款意图识别、决策生成、回复生成这些需要语义理解的，才用 agent
- 订单核验和物流检查可以并行执行
- 金额核对依赖订单核验的结果
- 决策生成只依赖前面三个验证过的结果
- 回复生成和决策解耦，决策错了不影响回复模板，回复模板错了不影响决策
程序节点和 agent 节点要混着用
一个常见的误解是：agentic loop 就是所有步骤都交给 agent。这是错的。
能写成程序的，不要交给 agent。
- 查订单状态 → 程序调用订单 API
- 查物流签收 → 程序调用物流 API
- 比较退款金额和订单金额 → 程序做数值比较
- 判断用户留言里的退款意图 → agent
- 写一封语气合适的回复 → agent
- 评估一个灰色地带的决策 → agent
程序节点的好处是：确定、快速、便宜、可解释。agent 节点的好处是：能处理模糊性、能综合上下文、能生成自然语言。
一个好的 loop 架构，是确定性程序节点和弹性 agent 节点的混合。不是 agent 取代程序，而是 agent 做程序做不了的事。
分解本身不会提升每步的准确率，但它让错误可以被局部捕获和局部修复，而不是一路传导到最后。
第三章：杠杆二 独立验证
Agent 说”我完成了”，不等于真的完成了。
但独立验证的真正价值，不只是”找错误”。它是 loop 工程里最重要的一条设计原则：如果你写不出验证器，你就不应该把这个子任务交给 agent。
验证器才是规格说明书
在传统软件里，你写函数，再写单元测试。函数是”怎么做”，测试是”什么算对”。
在 agentic 软件里，prompt 和工具是”怎么做”，验证器是”什么算对”。但很多人搞反了：他们花 80% 时间打磨 prompt，只花 5% 时间想验证。结果 loop 能跑，但没人知道它跑对了没有。
一个好的验证器，本质上是在回答三个问题：
- 输出格式对吗？（语法层）
- 输出意思对吗？（语义层）
- 输出解决了用户的真实问题吗？（语用层）
三层验证，三层成本
语法层最便宜，也最有确定性。它检查 JSON 是否合法、字段是否齐全、数值是否在范围、字符串长度是否超限。所有能写成规则的东西，都应该写成规则。规则不会疲劳，不会被上下文带偏，也不会因为”今天模型心情不一样”而改变判断。
语义层需要模型。比如判断一段摘要是否覆盖了原文要点，判断分类标签是否符合上下文，判断生成的 SQL 是否匹配用户意图。这层的问题是：验证器自己也可能错。它不是绝对真理，而是概率判断。
语用层最难。它问的不是”输出看起来对不对”，而是”这个输出放到真实世界里能不能产生预期结果”。代码能不能跑通？退款后用户会不会满意？邮件发出去会不会引发投诉？这层验证往往只能事后做，或者靠人工抽样。
一个成熟 loop 的设计，应该是：语法层全覆盖，语义层采样覆盖，语用层事后审计。
为什么自我验证不可信
不是 agent 不诚实，是同一个认知过程不能同时当运动员和裁判员。
agent 生成答案时，它在做一个”最大化连贯性”的计算。让它立刻检查自己的答案，它用的还是那套连贯性计算。它只会觉得自己的输出挺连贯的。错误的答案如果编得圆，自我验证就会通过。
独立验证需要正交计算：用不同的输入、不同的标准、不同的路径去判断同一个输出。规则验证器用代码路径，模型验证器用不同的 prompt 视角，外部验证器用事实数据。只有判断路径和生成路径足够不同，验证才有意义。
验证驱动的任务分解
这一点最关键，也最容易被忽略。
你应该这样分解任务：不是按”步骤”分解，而是按”可验证单元”分解。
如果一个子任务的验证器很难写，说明这个子任务要么太大，要么太模糊。比如：
- “分析数据并给出结论”——验证器没法写，因为”好结论”没有客观标准
- “列出本周销售额前三名”——验证器很好写，和销售数据库对一下就行
- “判断用户情绪”——验证器难写，因为情绪标签主观
- “识别用户是否明确表达了退款意图”——验证器可以写，因为有明确的信号词和上下文规则
任务分解的终点，不是”够小”，而是”够可验证”。
验证器也会错
很多人忘了这一点。他们觉得”加了验证器就安全了”，但验证器自己也有准确率。
假设你的主 agent 每步准确率 90%，验证器准确率 95%。看起来验证器比主 agent 还可靠，但如果它们犯的错误是相关的——比如都容易被某种模糊输入误导——那漏网率就不是 10% × 5% = 0.5%，而是可能高得多。
这就是为什么语法层验证更值得信赖：它和主 agent 的认知路径完全不同。模型验证器和主 agent 共用类似的训练数据，错误相关性更高。
退款审核 loop 的验证器设计
看看我们的案例里，每个节点适合什么验证器：
订单核验（程序节点）
- 这个节点本身就不该用 agent。程序直接调用订单系统 API，拿到
order_id、order_status、refund_eligible。 - 验证器就是 API 返回本身。如果 API 报错或返回空，直接标记失败。
- 语用层：抽查 5% 的通过案例，人工确认订单状态无误
物流检查（程序节点）
- 程序调用物流 API，拿到
logistics_status。 - 枚举值必须是 [“未签收”, “已签收”, “运输中”, “异常”] 之一，否则打回重试。
- 物流状态是外部事实，不需要模型判断。
金额核对（程序节点）
- 程序比较
refund_amount和max_refund_amount。 - 验证规则：
refund_amount和max_refund_amount必须是数字，且refund_amount <= max_refund_amount。 - 对金额接近上限的案例人工复核。
退款意图识别（agent 节点）
- 语法层：输出必须是分类标签，如 [“明确退款”, “询问政策”, “需要补充材料”, “非退款请求”]
- 语义层：模型验证器检查 agent 是否误读了用户意图。比如用户说”这个能退吗”，agent 标成”明确退款”，验证器应该打回
- 这是整个 loop 里最需要模型验证的地方
决策生成（agent 节点 + 规则兜底）
- 语法层：输出必须是 [“批准”, “拒绝”, “要求补充材料”, “转人工”] 之一
- 语义层：规则检查高风险组合。例如：批准退款但物流未签收 → 打回
- 语用层：最终决策和后续用户满意度/投诉率关联，事后审计
回复生成（agent 节点）
- 语法层：回复不能为空，不能包含敏感词
- 语义层：模型验证器检查语气是否合适、是否准确反映了决策结果
- 语用层：用户是否再次追问？是否投诉？这是最好的语用验证
看到没有？程序节点不需要昂贵的模型验证。订单、物流、金额这些有外部事实的，程序 + 规则就够了。agent 和模型验证只用在语义模糊的地方。这是成本控制的精髓。
一个最小验证器接口
class Verifier:
def check(self, task, output, context=None) -> Verdict:
"""
passed: bool
score: float (0-1)
reason: str
action: "continue" | "retry" | "escalate"
"""
pass
class SyntaxVerifier(Verifier):
"""语法层：规则确定，成本最低"""
def check(self, task, output, context=None):
errors = []
if not isinstance(output, dict):
errors.append("输出必须是 JSON")
if "summary" not in output:
errors.append("缺少 summary 字段")
if len(output.get("summary", "")) > 500:
errors.append("summary 超过 500 字")
if errors:
return Verdict(passed=False, score=0, reason="; ".join(errors), action="retry")
return Verdict(passed=True, score=1.0, reason="语法检查通过", action="continue")
class SemanticVerifier(Verifier):
"""语义层：模型判断，成本较高，可能误判"""
def check(self, task, output, context=None):
prompt = f"""
任务：{task.description}
成功标准：{task.criteria}
实际输出：{output}
请判断输出是否满足成功标准。回答格式：PASS 或 FAIL，并附理由。
"""
response = llm.call(prompt)
passed = response.strip().startswith("PASS")
return Verdict(
passed=passed,
score=1.0 if passed else 0.0,
reason=response,
action="continue" if passed else "escalate"
)
class PragmaticVerifier(Verifier):
"""语用层：事后审计，通常依赖外部结果或人工抽样"""
def check(self, task, output, context=None):
# 例如：生成的 SQL 是否真的返回了正确结果
result = run_sql(output["sql"])
expected = context.get("expected_result")
passed = result == expected
return Verdict(
passed=passed,
score=1.0 if passed else 0.0,
reason=f"SQL 执行结果匹配：{passed}",
action="continue" if passed else "escalate"
)验证设计的几条铁律
- 验证器不是可选项，是子任务的定义本身。 写不出验证器的子任务，不应该被自动化。
- 验证路径必须和生成路径正交。 自我反思不是独立验证。
- 能用规则的，绝不用模型。 规则便宜、确定、可维护。
- 验证点要在每个子任务后，不要只在最后。 晚期发现错误，纠正成本指数级上升。
- 验证器自己也要有指标。 记录验证器的漏检率和误杀率，否则你不知道它是不是在假装工作。
最核心的一条：验证不是为了证明 agent 做对了，而是为了在 agent 做错时，尽快、尽量便宜地把它拦住。
第四章：杠杆三 共识冗余
有时候，一个 agent 的判断不够可靠，但多个 agent 达成一致时，可信度会显著上升。
这就是共识冗余：对同一个子任务，用多个独立路径求解，然后看它们是否同意。
什么时候共识有用
共识冗余最适合两类任务：
- 答案空间有限：分类、判断、选择、提取
- 错误代价高：代码生成、医疗建议、财务计算、安全决策
反过来，共识冗余对创意类、开放性任务帮助不大。让三个 agent 各写一首诗然后投票，没有多大意义。
共识的代价
共识不是免费的。三路径并行意味着三倍的 token 成本和延迟。所以要用在刀刃上：
- 只在关键子任务上用共识
- 只在验证器不确定时用共识
- 用不同角度设计不同 agent，而不是简单复制同一个 prompt
比如一个文档分类任务：
- Agent A：从标题和第一段判断
- Agent B：从关键词列表判断
- Agent C：从全文语义判断
三个不同角度的一致，比三个相同角度的复制更可信。
退款审核 loop 的共识冗余
在我们的案例里，不是每个子任务都值得加共识。只有退款意图识别和决策生成两个高风险节点需要考虑。
退款意图识别用三路径共识：
- Agent A：只看用户原始留言，判断意图
- Agent B：只看用户上传的图片/凭证（如果有），判断意图
- Agent C：结合历史订单和退款政策，判断意图
为什么需要三个角度？因为用户留言可能含糊。比如：
“这个裤子质量不太好，想换一条。”
Agent A 可能标成”换货”，Agent B 看到图片里的破损标成”退款”，Agent C 根据政策判断”换货或退款均可”。三个结果不一致时，直接转人工。一致时，才进入下一步。
决策生成用两路径共识就够了：
- Agent A：基于规则和先例判断
- Agent B：基于用户价值和风险评估判断
如果 A 说”批准”，B 说”拒绝”，说明这个案例处于灰色地带，转人工。如果一致，自动执行。
注意：订单核验、物流检查、金额核对这些有外部事实的，不需要共识。外部事实本身就是比任何 agent 都权威的”第三方”。共识只用于没有唯一正确答案、但错误代价高的判断节点。
共识什么时候会失效
共识不是万能药。以下几种情况，加 agent 数量没用：
1. 所有 agent 共享同一个偏见
三个 agent 都用同一个基础模型、同一个训练数据、同一个 prompt 模板，只是 temperature 不同——这不叫冗余，这叫同一个错误犯三遍。
真正的冗余需要多样性：不同模型、不同 prompt 角度、不同工具链、甚至不同任务分解方式。多样性才是共识有效的前提。
2. 答案空间被污染
如果所有 agent 都倾向于选择第一个出现的选项，或者都被 prompt 里的例子带偏，投票只会放大这个偏差。
3. 问题本身没有正确答案
“这篇文章写得怎么样”这类主观问题，三个 agent 达成一致不代表它们对了，只代表它们相似。
4. 错误代价低到不值得
对低风险的分类任务，共识带来的准确率提升可能抵不上增加的成本。不要为了技术酷而加冗余。
共识不是投票那么简单
多数投票只是最基础的形式。更高级的做法是：
- 加权共识：给更可靠的 agent 更高权重
- 辩论式共识：让不同 agent 互相质疑，直到收敛
- 级联共识：先让便宜模型快速筛选，再让贵模型处理边界案例
但无论你用哪种，核心原则不变：不要让单一模型成为单点故障，也不要让多个模型共享同一个故障点。
第五章：杠杆四 人工接管点
再完美的 loop 也不可能 100% 无人值守。真正成熟的系统不是”不需要人”，而是”知道什么时候该把人拉进来”。
人工接管点是 loop 的保险丝。
什么时候接管
不是所有情况都值得接管。接管太频繁，系统失去自动化意义；接管太少，系统会在危险场景下独自犯错。
合理的接管触发条件：
- 置信度低于阈值：模型输出概率分布平坦，或验证器分歧大
- 涉及高风险操作：删除数据、修改配置、对外发送、资金操作
- 首次遇到新场景：训练数据里没有覆盖过的输入模式
- 连续失败：同一子任务重试超过 N 次仍未通过
- 指标失控：过程指标超过历史控制限
接管的设计
好的接管不是弹一个告警就算完。它要给人足够上下文。
假设你在做一个”自动退款审核”的 loop。当它触发接管时，界面应该呈现：
[接管请求] 订单 #20250618001
触发原因：
- 退款金额 ￥8,500 超过自动审批阈值 ￥5,000
- 验证器 A（规则）：通过
- 验证器 B（模型）：低置信度（0.42），认为"理由描述含糊"
已执行步骤：
1. ✓ 核验订单存在且已发货
2. ✓ 检查退货物流已签收
3. ✓ 核对商品价格在历史范围内
4. ⚠ 评估退款理由（置信度低）
建议操作：
[批准退款] [拒绝退款] [要求补充材料] [转人工深度审核]
风险提示：
- 批准：该用户近 30 天有 3 次退款记录，可能存在薅羊毛风险
- 拒绝：用户已提供签收凭证，无理由拒绝可能引发投诉对比一个糟糕的接管界面：
[告警] Agent 在处理订单 #20250618001 时遇到问题，请检查。后者把全部调查负担推给人，等于没有自动化。
好的接管设计应该包含五个要素：
- 触发原因：为什么现在需要人
- 执行历史：loop 已经做了什么、做到哪一步
- 关键证据：做决策需要看的原始信息
- 建议选项：系统推荐的几种处理方式
- 风险提示：每个选项可能的副作用
接管后的闭环
每次接管都应该被记录和分析：
- 为什么会触发？
- 人做了什么决定？
- 这个决定是否可以被自动化？
如果同一类接管反复发生，说明你的 loop 在这个边界上有设计缺陷。要么改进任务分解，要么改进验证器，要么把这个场景纳入自动处理逻辑。
人工接管不是失败，它是你获取训练数据的来源。
第六章：从 1σ 到 4σ 的路线图
知道了四个杠杆，下一步是怎么落地。不要试图一次性跳到 4σ。
先定义每个 Sigma 水平对应什么完成率：
| Sigma 等级 | 每百万次缺陷数 | 完成率 | 意味着什么 |
|---|---|---|---|
| 1σ | 691,462 | 30.85% | 基本不可用，需要人全程盯着 |
| 2σ | 308,538 | 69.15% | 能跑，但每 3-4 次就失败一次 |
| 3σ | 66,807 | 93.32% | 可用，但大规模运行下失败仍频繁 |
| 4σ | 6,210 | 99.38% | 接近无人值守，失败是例外 |
| 5σ | 233 | 99.98% | 高度自动化，需要严格流程 |
| 6σ | 3.4 | 99.99966% | 航空航天级，成本极高 |
这些数字是理想化的，实际 loop 的失败分布不会 perfectly 正态。但它们给你一个锚点：如果你的 loop 完成率只有 70%，你是在 2σ；如果你想无人值守，至少要接近 4σ。
1σ → 2σ：先把测量做出来
在 1σ 阶段，你可能连完成率都没有稳定统计。团队里每个人对”成功”的定义都不一样。第一件事不是改结构，而是像第二篇讲的那样：搭 dashboard、跑基线、收集 trace。
典型动作：
- 定义任务成功标准（并且写下来）
- 部署 measurement hook
- 跑 100 条 trace 看失败模式
- 画出最常用的工具调用路径
- 区分”agent 报错”、“agent 完成但结果错”、“结果对但格式错”
这个阶段的目标不是提升，而是看清楚现状。很多团队以为自己在 3σ，实际测量完发现只有 1.5σ。
2σ → 3σ：堵住最大的洞
到了 2σ，你有了数据。现在用帕累托原则，找到导致 80% 失败的 20% 根因，集中火力修复。
典型动作：
- 加固输入 schema 和数据清洗
- 改写最容易被误用的工具描述
- 在关键子任务加规则验证器
- 设置 timeout 和 max iteration 防止无限循环
- 给常见失败模式写专门的 recovery 路径
这个阶段是”低垂果实”阶段。通常不需要改 loop 结构，只要修最明显的 bug，就能从 70% 提到 90% 以上。
3σ → 4σ：结构化改进
3σ 以后，单点优化边际递减。你再怎么优化 prompt，完成率可能也只能从 93% 提到 95%。要跨越到 4σ，必须改变 loop 结构。
典型动作：
- 把长链拆成树状/图状工作流
- 在每个子任务后加规则验证器
- 在重要节点加独立模型验证器
- 对高风险步骤引入共识冗余
- 设计合理的人工接管点
- 建立失败案例库和 runbook
这个阶段成本明显上升。每提升 1 个百分点，可能需要前面阶段 5 倍的努力。
4σ 以上：值得吗
4σ 意味着 99.38% 的成功率。能不能到 5σ、6σ，取决于三件事：
- 任务边界是否足够清晰：如果任务本身模糊，连人都不知道什么叫”对”，模型不可能稳定做到 6σ
- 是否有足够的高质量验证数据：没有大量标注过的正负样本，验证器就是摆设
- 失败的代价是否值得投入成本：6σ 的成本可能是 4σ 的 10 倍
不是所有 loop 都需要 6σ。一个内部数据分析助手，3σ 可能就够了。一个自动处理客户退款的核心系统，4σ 是底线。一个控制工业设备的 loop，才需要考虑 5σ 以上。
追求 Sigma 之前，先定义清楚你需要的可靠性等级。
第七章：成本与收益的博弈
提高 Sigma 是有成本的。你要算清楚这笔账。
成本在哪里
- 分解成本：更多子任务意味着更多代码、更多验证器、更多维护
- 验证成本：独立模型验证器每次调用都要 token
- 冗余成本：多路径共识直接乘以 N
- 人工成本：接管点把人拉进来，人的时间最贵
- 延迟成本：更多步骤、更多验证、更多共识，响应时间变长
收益在哪里
- 失败成本降低：减少人工兜底、减少客户投诉、减少数据错误
- 可扩展性提升：可靠性够了，才能放大运行规模
- 信任积累：团队敢把更多任务交给 loop
算一笔具体的账
假设你有一个客服工单分类 loop：
- 每月处理 10,000 张工单
- 当前完成率 85%，即每月 1,500 张失败
- 每次失败需要人工重新分类，平均成本 3 元（人工时间）
- 每月失败总成本：
1,500 × 3 = 4,500 元
现在你考虑加一个独立模型验证器，预计能把完成率从 85% 提到 92%。也就是每月失败从 1,500 张降到 800 张，减少 700 张。
- 每月节省失败成本：
700 × 3 = 2,100 元 - 验证器调用成本：每次验证 0.02 元，10,000 张工单，每月额外成本
10,000 × 0.02 = 200 元 - 开发和维护成本摊到每月：约 500 元
- 净收益：
2,100 - 200 - 500 = 1,400 元/月
这个改进值得做。
但同样是这个 loop，如果你考虑引入三路径共识冗余来把完成率从 92% 提到 95%：
- 每月多处理对：300 张
- 每月节省失败成本：
300 × 3 = 900 元 - 共识冗余成本：每张工单多调用两次模型，每次 0.02 元，每月额外
10,000 × 2 × 0.02 = 400 元 - 开发和维护成本摊到每月：约 800 元
- 净收益：
900 - 400 - 800 = -300 元/月
这个改进不值得做，至少在当前规模下不值得。只有当工单量放大 5 倍，或者每次失败成本上升到 15 元以上时，共识冗余才划算。
一个简单的决策框架
对每一个改进动作，问自己：
“这个改动能让 loop 少失败多少次？每次失败我付出多少成本？这个改动本身要付出多少成本？”
如果改进成本 > 失败成本 × 预期减少次数，暂时不要做这个改进。
这不是让你偷工减料，而是让你避免过度工程。4σ 很好，但如果 3σ 已经满足业务需求，把资源花在别的地方可能更划算。
Sigma 目标不是越高越好，是和业务成本匹配才好。
第八章：退款审核 loop 的 1σ→4σ 改造实录
理论讲完了。下面我们完整走一遍退款审核 loop 的改造过程，把前面的四个杠杆串起来。
起点：1.5σ
改造前：
- 结构：6 步长链，一步错全盘错
- 月处理量：5,000 单
- 完成率：46%（约 2,700 单失败或异常退出）
- 失败成本：每单人工复核平均 8 元
- 月失败成本：
2,700 × 8 = 21,600 元 - 团队状态：3 个人全职复核，每天加班
最大的失败模式：
- 35% 的失败是输入数据格式不统一（不同渠道的订单字段不一样）
- 28% 的失败是 agent 在”理由评估”步骤卡死（标准模糊）
- 18% 的失败是超时（链太长，某一步卡住）
- 12% 的失败是最终决策和回复文案不一致
第一阶段：1.5σ → 2.2σ
动作：
- 统一输入 schema，加数据清洗层
- 把 timeout 从 30 秒调到 60 秒
- 给”理由评估”加明确的分类标准
- 部署 measurement hook，开始稳定记录指标
结果：
- 完成率从 46% 提升到 72%
- 月失败单数从 2,700 降到 1,400
- 月失败成本从 21,600 元降到 11,200 元
- 投入：1 个工程师 2 周
这一阶段没有改模型，没有加复杂验证。就是修最明显、最便宜的问题。帕累托原则。
第二阶段：2.2σ → 3.1σ
动作：
- 把 6 步长链拆成可验证子任务
- 订单核验、物流检查、金额核对从 agent 改成程序节点：直接调用 API、查数据库、做数值比较
- 退款意图识别改用更具体的分类标签
- 回复生成和决策生成解耦
结果：
- 完成率从 72% 提升到 93.5%
- 月失败单数从 1,400 降到 325
- 月失败成本从 11,200 元降到 2,600 元
- 额外成本：规则验证器开发 + 运行，约 800 元/月
- 净节省：约 7,800 元/月
关键变化：失败不再意味着整单重做。70% 的失败可以在单个子任务内被 catch 并重试，只有 30% 需要人工介入。
第三阶段：3.1σ → 4.0σ
动作：
- 对退款意图识别加三路径共识
- 对决策生成加两路径共识
- 对高风险组合加规则拦截
- 设计人工接管点（金额异常、共识不一致、连续失败）
- 建立失败案例库，定期 review
结果：
- 完成率从 93.5% 提升到 97.2%
- 月失败单数从 325 降到 140
- 月失败成本从 2,600 元降到 1,120 元
- 额外成本：共识冗余 + 接管界面开发维护，约 2,500 元/月
- 净效果：失败成本降低 1,480 元/月，但加上新增成本后，净节省约 -1,000 元/月
注意：这一阶段从纯成本角度看，略有亏损。但它把 loop 从”需要 3 个人盯着”变成了”1 个人抽查”。人工成本结构变了，只是没完全体现在失败成本里。
第四阶段：4.0σ 以上
如果业务需要继续提升到 4.5σ 或 5σ，下一步动作：
- 扩大训练数据，优化语义验证器
- 对历史失败案例做根因分析，固化成规则
- 把人工接管决定反馈给模型，做 few-shot 学习
- 对物流、金额等外部依赖加缓存和降级策略
这些动作成本更高，只有当失败代价继续上升（比如合规罚款、品牌风险）时才值得做。
改造的关键教训
- 前两个 sigma 最便宜。从 46% 到 93%，主要靠测量、修洞、分解、规则验证。这部分 ROI 最高。
- 后两个 sigma 最贵。从 93% 到 97%，需要共识、接管、持续迭代。这部分收益主要体现在风险降低，不只是直接成本。
- 不要为了 4σ 而 4σ。如果业务只需要 90% 完成率，停在 3σ 是理性的。
- 人工不会消失，但工作变了。人不再做重复复核，而是做边界决策、根因分析、规则更新。
第九章：四个最常见的反模式
知道四个杠杆不等于能用好。下面是我在实际项目里见过最多的反模式。
反模式一：用 consensus 掩盖设计缺陷
团队发现某个子任务准确率只有 60%，不想花时间分析为什么，直接上了五路径共识。准确率提到 85%，成本变成 5 倍。
问题是：那 40% 的失败有系统性的原因。可能是工具描述不清，可能是输入格式不稳定，可能是任务边界模糊。共识把失败压下去了，但没有消除根因。一旦流量变大，少数派正确的概率会让错误漏出来。
正确做法：先用测量找到失败模式，修好最明显的根因，再考虑对剩余不确定部分加共识。
反模式二：验证器和生成器用同一个 prompt
有些团队”为了验证”，把主 agent 的输出又喂给同一个模型，问”这个对吗”。这和让小学生自己检查自己的作业没有区别。
独立验证的关键是独立：不同的输入视角、不同的判断标准、不同的模型实例。如果验证器只是生成器的回声，它不会发现生成器没发现的错误。
反模式三：人工接管变成永久兜底
设计了一个接管点，但三个月后 30% 的任务都流到了人工。团队以为这是”安全”，实际上是 loop 没有真正自动化。
健康的接管率应该随时间下降。如果某个接管原因反复出现，要把它变成自动处理逻辑或前置验证。接管是过渡机制，不是最终状态。
反模式四：为了分解而分解
把任务拆成 20 个子任务，每个子任务只有一行 prompt，子任务之间的编排代码比业务逻辑还复杂。结果 bug 不出在模型上，出在编排上。
分解的粒度不是越细越好。过细的分解会带来：
- 编排复杂度爆炸
- 子任务间上下文丢失
- 验证点太多，开发维护成本剧增
- 整体延迟不可接受
判断标准：如果拆分后的代码量和调试难度超过你节省的失败成本，说明拆过头了。
第十章：结语
Loop Engineering 三部曲到这里结束。
第一篇讲了一个基本事实：Agentic AI 的瓶颈不是模型不够强，而是多步骤系统的缺陷率会被串联放大。
第二篇讲了一套测量方法：用过程指标代替 vibe，用控制图代替直觉。
第三篇讲了四个改进杠杆：任务分解、独立验证、共识冗余、人工接管。
把它们串起来，就是一条从”能跑”到”敢跑”到”不用人跑”的路径：
- 先测量，知道问题在哪里
- 再分解，把大任务变成可验证的小任务
- 加验证，让错误在源头被抓住
- 上冗余，对关键判断做多路径确认
- 设接管，让 loop 在不确定时优雅降级
这条路径不依赖某一个大模型 breakthrough。它依赖的是工程纪律。
金句卡片
- “换模型是战术，改结构才是战略。”
- “Agent 说自己完成了，不等于真的完成了。”
- “共识不是投票，而是让不同角度互相校验。”
- “人工接管不是失败，是获取训练数据的来源。”
- “不是所有 loop 都需要 6σ，先定义你需要的可靠性等级。“
参考来源
- James Xie, “Loop Engineering 的本质：Agentic AI 的六西格玛缺口”, 2026-06-18
- James Xie, “如何测量一个 Loop：从 Vibe 指标到过程指标”, 2026-06-18
- Lyzr.ai, “Six Sigma (6σ) Agent”, 2026-04-21
- Corvair.ai, “Six Sigma for Agentic AI”, 2026