如何测量一个 Loop：从 Vibe 指标到过程指标 如何测量一个 Loop：从 Vibe 指标到过程指标

作者：James Xie

这是「Loop Engineering」系列的第二篇。

上一篇我们说：当前复杂 Agent 循环的可靠性，和企业级生产质量之间还隔着两到三个数量级。这一篇要解决下一个问题：你怎么知道自己 loop 的可靠性到底是多少？

答案不是”感觉还行”，而是一组可以被每周 review、被趋势追踪、被异常告警的过程指标。

第一章：为什么”感觉不错”是最危险的指标

大多数 Loop 在上线初期都给人一种错觉：它好像能跑。

你设计了一个自动化，每天早上 9 点让 Agent 去读 CI 失败、写修复建议、开 PR。第一周，它开了 3 个 PR，其中 1 个有用。你觉得”还不错，至少省了我手动看日志的时间”。第二周，它开了 5 个 PR，2 个有用。第三周，它开了 2 个 PR，0 个有用。

这时候你面临一个选择：继续跑，还是关掉它？

如果你只有”感觉还不错”这个指标，你大概率会继续跑。因为”偶尔有用”比”完全没用”好听，也因为关掉它意味着承认自己之前的投入白费了。这就是沉没成本陷阱在 Loop Engineering 里的表现。

但”偶尔有用”不是一个工程指标。它不能告诉你：

• 这个 loop 的真实成功率是多少？
• 每次成功背后的成本是多少？
• 失败的模式有没有规律？
• 它的质量是在提升还是在漂移？

更隐蔽的问题是：“感觉不错”往往只记录成功，忽略失败。 你会记得那个周五下午 Agent 自动修好了一个棘手 bug 的惊喜，但你会忘记它上周二 silently 改坏了一个配置，害你花了两小时回滚。

这种选择性记忆在无人值守 loop 里尤其危险。因为 loop 不会主动来告诉你”我今天搞砸了什么”。它只会继续跑，继续产出，继续在某些你注意不到的地方制造技术债。

制造业有一句话：“你无法管理你不能测量的东西。” 这句话对 Agentic 系统同样适用。Loop Engineering 要成熟，第一步就是把”感觉”换成”数字”。

不是因为你喜欢数字，而是因为没有数字，你就无法区分”正常的波动”和”真正的失控”。

第二章：Vibe 指标 vs 过程指标

在讨论具体指标之前，先区分两类测量。这个区分不是文字游戏，它决定了你后续所有的改进动作是盲目的还是有的放矢。

Vibe 指标是那些让你”感觉” loop 在工作的指标：

• “这周它开了 5 个 PR”
• “它看起来省了我一些时间”
• “有一次它真的解决了一个我没想到的问题”
• “用户反馈说还挺好用”

这些指标的共同特点是：它们是轶事，不是数据。它们不能比较、不能追踪、不能归因。一个 loop 可以连续三周给你讲三个精彩的成功故事，同时失败的次数在悄悄翻倍。你也可以连续三周都觉得”还不错”，然后第四周突然发现账单爆了。

Vibe 指标最大的问题是滞后性。等你”感觉”到不对的时候，问题通常已经积累了一段时间。你可能已经合并了十几个有问题的 PR，或者已经让 loop 在一个错误的方向上优化了几十轮。

过程指标则不同。它们描述的是 loop 运行的真实状态：

• 多少次运行真正完成了目标？
• 平均每次运行要花多少 token、多少时间？
• 失败是因为输入问题、流程问题，还是 Agent 本身的错误？
• 这些数字这周和上周相比，是变好还是变坏？

过程指标的价值不在于某一次的数值，而在于趋势和模式。它们让你从”这周好像还行”变成”我们的完成率从 68% 掉到了 52%，原因是 CI 日志格式变了，导致 triage skill 解析失败”。

后者才是可以采取行动的信息。

下面这张表总结了核心区别：

-loop Engineering 的成熟过程，本质上就是把左边那列，逐步替换成右边那列的过程。

第三章：一套可用的 Loop 健康指标

Digital Applied 在 2026 年 5 月发布了一套 10-KPI 面板，专门用于监控生产级 Agentic 流程。这不是唯一正确的答案，但它是一个极好的起点。

我把它重新组织成四个层次，方便你根据 loop 的成熟度逐步引入。不是一上来就用全部 10 个，而是像剥洋葱一样，从外到内。

第一层：完成度指标

Completion rate（完成率）

这是最基本的指标：有多少比例的 loop 运行最终进入了”成功完成”状态。

• 定义：成功完成的运行次数 / 总运行次数
• 生产级目标：> 90%
• 早期 loop 可接受：60%–80%
• 失败模式：loop 超时、达到最大迭代次数、验证未通过、人为中断

completion rate 低本身不是问题，问题是不知道为什么低。一个完成率 60% 的 loop，如果 80% 的失败都是”输入数据格式不对”，那问题不在 Agent，而在数据管道。如果 80% 的失败都是”Agent 选择了错误工具”，那问题在工具描述或 Harness 设计。

Stage abandonment（阶段放弃率）

这个指标回答：loop 在哪个阶段最容易中断？

假设你的 loop 有 4 个阶段：读取 CI 日志 → 定位问题 → 生成修复 → 运行测试。如果 80% 的放弃发生在”运行测试”阶段，说明生成的修复质量很差；如果 80% 放弃在”读取 CI 日志”阶段，说明输入数据有问题。

这个指标的价值在于定位瓶颈。没有它，你会漫无目的地改 prompt；有了它，你知道该去改数据 schema、工具描述，还是验证条件。

第二层：效率指标

Retry depth（重试深度）

定义：每个逻辑步骤平均重试多少次。

• 目标：<= 3 次
• 信号：重试次数持续上升，说明 Agent 在兜圈子，或者验证条件不清晰

比如 Agent 反复调用 read_file 读同一个文件，说明它可能忘了之前读过的内容；反复调用 run_test 但测试一直不过，说明它陷入了”改一点、测不过、再改一点”的循环。高 retry depth 通常意味着上下文管理或验证设计有问题。

Cost per success（每次成功的成本）

定义：总 token 成本 / 成功完成的运行次数。

这是最重要的经济指标。一个每次成功花 $5 的 loop，和一个每次成功花 $0.5 的 loop，是完全不同的业务。

注意分母是”成功次数”，不是”总运行次数”。一个失败 5 次才成功 1 次的 loop，单次运行成本可能只有 $0.30，但 cost per success 其实是 $1.80。只看单次成本会严重低估真实开销。

Time-to-completion（完成时间分位值）

定义：P50 / P90 / P95 完成时间。

平均完成时间 30 秒不代表没有 30 分钟的异常运行。Agentic 系统特别容易出现长尾：一个正常 run 30 秒，一个失控 run 30 分钟。只看平均值，你会错过那些真正烧钱、真正影响用户体验的异常。

第三层：人工依赖指标

Human-in-the-loop frequency（人工介入频率）

定义：每 100 次运行中，有多少次需要人类决策。

• 低风险 loop（如文档整理、报告生成）：目标 < 5%
• 中风险 loop（如代码修复、内容审核）：目标 5%–20%
• 高风险 loop（如资金操作、医疗诊断）：目标可以更高，但必须明确介入点

这个指标的关键不是越低越好，而是可预测。如果人工介入率从 5% 突然涨到 25%，说明 loop 的能力边界被突破了，或者输入分布发生了变化。

Escalation rate（升级率）

定义：loop 无法处理、需要转交人类的任务比例。

和 HITL frequency 不同，升级率关注的是 loop 主动”投降”的情况。持续高升级率说明两件事之一：要么 loop 的 scope 定得太宽，很多任务本来就不该交给它；要么 loop 的能力还不够，需要更好的工具或验证。

第四层：质量漂移指标

Eval-fail rate（评估失败率）

定义：loop 产出被独立评估层拒绝的比例。

这是最早期的质量下滑信号。如果 eval-fail rate 从 5% 涨到 15%，即使 completion rate 还正常，也说明产出质量在下降。可能的原因：模型版本更新、训练数据分布变化、或者 evaluator 标准太松/太紧。

Drift signals（漂移信号）

定义：输出分布、工具调用模式、错误类型的变化。

比如 Agent 以前 80% 的情况下会调用 read_file，现在 80% 的情况下调用 search_code。这种工具调用分布的漂移，可能意味着输入数据的结构变了，或者 Agent 的推理路径发生了改变。Drift 不一定代表坏事，但必须被监控。

Incident frequency（事故频率）

定义：由 loop 引发或参与的生产事故数。

这是最终的可靠性背书。无论前面 9 个指标多漂亮，事故频率才是老板、用户、监管真正关心的。一个 completion rate 99%、但每月引发一次 P0 事故的 loop，不如一个 completion rate 85%、但零事故的 loop。

把这 10 个指标放在一起，你就有了一个基本完整的 Loop 健康面板。

第四章：从指标到控制图

收集指标只是第一步。真正有价值的是控制图（Control Chart）。

制造业的控制图思想很简单：你画一条中心线（过程的平均水平），再画上控制上限和下限。当数据点超出控制限，或者连续多个点落在同一侧，就说明过程可能失控了。

一个简单的控制图例子

对 Loop Engineering 来说，控制图可以长这样：

控制图的好处是：它把”异常”从”感觉”变成”规则”。你不需要每次 review 都重新判断”这个算不算差”，你只需要看数据有没有突破控制限。

普通原因 vs 特殊原因

更重要的是，控制图区分了两种变化：

普通原因变异：过程本身的正常波动，不值得大惊小怪。

比如 completion rate 这周 75%，下周 73%，再下周 77%。只要在控制限内，这就是正常波动。你不需要为此开会，也不需要改 prompt。

特殊原因变异：由某个具体事件引起的异常，需要调查。

比如 completion rate 突然从 75% 掉到 55%，并且连续三天都低于控制下限。这说明有某个特殊事件发生了：可能是 CI 日志格式变了，可能是模型版本更新了，可能是某个依赖服务挂了。

没有控制图，你每次指标波动都会 panic。有了控制图，你只会对真正的失控信号反应。

控制限怎么算

最简单的算法：

• 中心线 = 过去两周的平均值
• 上控制限 = 中心线 + 1.5 × 标准差
• 下控制限 = 中心线 - 1.5 × 标准差

你不需要精确到统计学教科书的标准。早期 loop 的数据量不大，用”中心线 ± 10%–15%“作为粗糙控制限也可以。关键是要有控制限这个概念，而不是每次都凭感觉判断。

控制图告诉你的三类故事

故事一：过程稳定，没有失控 所有点都在控制限内，围绕中心线随机波动。这时候不要瞎优化，继续监控即可。

故事二：过程失控，需要调查 有点突破控制限，或者连续 7 个点都在中心线同一侧。这时候要暂停新功能开发，先找根因。

故事三：过程在持续改善 连续多个点都在中心线以上（对 completion rate 是好事），或者中心线明显上移。这时候可以重新设定基线，把改进固化下来。

控制图的本质不是让你看数字，而是让你看过程是否在控制之内。

第五章：如何建立你的第一个 Loop 面板

你不需要一天之内把这 10 个指标全部上线。大多数团队死在”想把面板做完美”这一步。更好的做法是：先让三个指标跑起来，再逐步扩展。

第一步：选 3 个核心指标

不要从最难的开始。选三个能回答最基本问题的指标：

• Completion rate：这个 loop 能不能完成它该做的事？
• Retry depth：它完成的时候，是不是在兜圈子？
• Cost per success：它完成一件事，要花多少钱？

这三个指标之所以优先，是因为它们不依赖复杂的评估层。completion rate 看最终状态，retry depth 看 trace 里的步骤数，cost per success 看 token 账单。即使你的 loop 还没有独立的 evaluator，这三个数也能算出来。

一个常见错误是选太多指标。我见过有人一上来就监控 8 个指标，结果两周后根本不看 dashboard。指标的数量必须和你能采取的行动数量匹配。3 个指标 + 3 个对应动作，比 10 个指标 + 0 个动作有用一百倍。

第二步：跑两周，建立基线

基线不是目标，基线是你当前真实水平的快照。

让 loop 在没有人为干预的情况下跑两周。记录每一次运行的：

• 开始和结束时间
• 最终状态（完成 / 超时 / 最大迭代 / 人工介入）
• 总 token 消耗
• 每个步骤的工具名和重试次数
• 失败时的错误类型

这两周不要试图优化。你的任务是观察，不是改进。很多人会忍不住在基线期就修东西，这会污染基线。忍住。

两周后，你会得到一组数字。比如：

• completion rate: 62%
• retry depth: 2.8
• cost per success: $2.40

这些数字可能比你预期的低。这很正常。事实上，如果基线很漂亮，说明你的 loop 要么太简单，要么指标没量对。

第三步：设控制限，不要设目标

这是最难的一步，因为人的直觉是设目标。

不要设”完成率必须 95%“这种目标。如果基线是 62%，95% 只会让你沮丧。更好的做法是设控制限：

• 中心线 = 基线（62%）
• 下控制限 = 基线 - 10% = 52%（不可接受的退化）
• 上控制限 = 基线 + 15% = 77%（显著的改善）

控制限的意义是：告诉你什么时候该紧张，什么时候不需要紧张。

如果完成率从 62% 掉到 58%，不要 panic，这是正常波动。如果掉到 48%，连续三天，那就是失控信号，需要调查。

同样，如果完成率稳定在 70% 以上连续两周，说明你的改进有效，可以重新设定中心线。

控制限让你从”追求完美”变成”管理变异”。这是 Six Sigma 的核心思想。

第四步：每周 review，每月回顾

建立一个固定的 review 节奏：

每周 review（15 分钟）：

• 看控制图，有没有突破控制限？
• 失败模式有没有变化？
• 有没有新的异常类型出现？

每月回顾（1 小时）：

• 中心线有没有上移？
• 成本趋势是下降还是上升？
• 过去一个月做的改进，哪些有效，哪些无效？
• 下个月优先改什么？

这个节奏和制造业的 SPC 完全一样。区别只是，制造业监控的是零件尺寸，你监控的是 Agent 行为。

一个实用的技巧：把每周 review 的笔记写在一个固定文件里，比如 loop_metrics_2026_week25.md。三个月后，你会有一组宝贵的过程数据，告诉你这个 loop 是怎么从 62% 爬到 80% 的。

第六章：指标的常见陷阱

指标本身不会骗人，但人对指标的解读会骗人。下面是五个最常见的陷阱。

陷阱一：只监控成功，不监控失败

完成率 90% 看起来不错。但如果那 10% 的失败全部是”删了不该删的文件”或”覆盖了生产配置”，这个 loop 就是定时炸弹。

正确的做法是：每次失败都要分类。建立一个简单的失败类型标签：

• 输入错误（数据格式变了、API 返回异常）
• 流程错误（死循环、超时、工具选择错误）
• Agent 错误（幻觉、上下文丢失、错误理解了目标）
• 验证错误（产出通过了 loop，但没通过外部验证）

如果 60% 的失败是”输入错误”，问题在 Data Sigma；如果是”Agent 错误”，问题在 Prompt 或 Harness；如果是”验证错误”，问题在 Done Criteria。没有分类，你永远不知道劲该往哪使。

陷阱二：指标太多，行动太少

10 个指标都收集了，但没人看，没人行动，那它们只是 dashboard 上的装饰。

指标的数量必须和你能采取的行动数量匹配。如果你只有时间每周处理 2 个问题，那就只监控 2 个最关键的指标。多出来的指标只会制造焦虑。

一个判断标准：如果一个指标连续三周出现异常，但你没有任何行动计划，说明这个指标不该出现在你的面板上。

陷阱三：用平均值掩盖长尾

平均完成时间 30 秒，但 P95 是 30 分钟。如果只监控平均值，你会错过那些真正烧钱、真正影响用户体验的异常运行。

Agentic 系统的成本结构特别容易出现长尾。一个正常 run 花 $0.10，但一个失控 run 可能花 $50。只看平均值，你会觉得”每次 $0.50，很便宜”。但那个 $50 的异常 run 可能每周出现一次，把你的真实成本拉高 10 倍。

所以必须监控分位值：P50 看典型情况，P90 看异常，P95 看灾难。

陷阱四：把指标当成鞭子

指标是用来改进过程的，不是用来追责的。如果团队害怕指标，他们就会开始粉饰指标。

这在 Agentic 系统里尤其危险。因为你可以很容易地让 Agent 自己给自己打高分：把 evaluator prompt 调宽松一点，eval-fail rate 立刻下降；把成功标准定模糊一点，completion rate 立刻上升。数字好看了，系统并没有变好。

解决方法是：指标要和具体的工程动作挂钩。completion rate 上升了，是因为你加了输入校验，还是因为你把”成功”的定义改宽松了？必须能回答这个问题。

陷阱五：忽视指标之间的相关性

单独看每个指标可能都正常，但放在一起就暴露问题。

比如：completion rate 稳定在 85%，cost per success 在下降，retry depth 也在下降。看起来一切向好？但如果 human-in-the-loop frequency 从 5% 涨到 25%，说明 loop 在把难处理的案例都甩给人。它没有变聪明，只是变会推卸责任了。

所以 review 的时候不要只看单个指标的曲线，要看指标之间的关系。一个健康的 loop，应该是完成率上升、成本稳定或下降、人工介入率稳定或下降的组合。

第七章：一个最小可运行的测量脚本

你不需要昂贵的 observability 平台才能开始。下面是一个最小化的 measurement hook，用伪代码表示：

def run_loop(task):
    trace = {
        "trace_id": uuid(),
        "start_time": now(),
        "task": task,
        "steps": [],
        "total_tokens": 0,
        "status": "running"
    }

    try:
        # loop.iterate(task) 封装了一次 agent 调用：模型接收状态、选择工具/回答、
        # 执行工具、更新状态，直到任务完成或异常退出。这里只暴露测量面。
        for step in loop.iterate(task):
            trace["steps"].append({
                "step_id": step.id,
                "tool": step.tool_name,
                "tokens": step.token_usage,
                "duration_ms": step.duration,
                "result": step.result_summary
            })
            trace["total_tokens"] += step.token_usage

        trace["status"] = "completed"
        trace["passed_eval"] = evaluator.check(trace)

    except TimeoutError:
        trace["status"] = "timeout"
    except MaxIterationError:
        trace["status"] = "max_iterations"
    except HumanIntervention:
        trace["status"] = "human_escalated"

    trace["end_time"] = now()
    trace["cost"] = estimate_cost(trace["total_tokens"])

    metrics.record(trace)
    return trace

这个脚本的核心不是复杂，而是每一帧都被记录。只要你有了 trace，所有过程指标都可以从 trace 里计算出来。

从 trace 算指标

假设你跑了一周，收集了 100 条 trace。下面是三个核心指标的计算方法：

Completion rate

completed = sum(1 for t in traces if t["status"] == "completed" and t["passed_eval"])
completion_rate = completed / len(traces)

注意：我这里的”完成”不仅要求 loop 正常退出，还要求通过独立评估。这一点很重要。如果你让 loop 自己判断自己是否完成，completion rate 会虚高。

Retry depth

retry_depths = []
for t in traces:
    tool_calls = [s["tool"] for s in t["steps"]]
    from collections import Counter
    repeats = sum(c - 1 for c in Counter(tool_calls).values() if c > 1)
    retry_depths.append(repeats / max(len(tool_calls), 1))

avg_retry_depth = sum(retry_depths) / len(retry_depths)

这个算法很粗糙，但它能给你一个信号：Agent 是不是在反复调用同一个工具。更精细的做法是按”逻辑步骤”分组，看每个目标步骤重试了多少次。

Cost per success

successful_traces = [t for t in traces if t["status"] == "completed" and t["passed_eval"]]
total_cost = sum(t["cost"] for t in traces)
cost_per_success = total_cost / max(len(successful_traces), 1)

注意分母是”成功次数”，不是”总运行次数”。一个失败 5 次才成功 1 次的 loop，和一次就成功的 loop，即使单次成本相同，真实成本也差 5 倍。

trace 的存储和查询

你不需要复杂的数据库。一个 JSONL 文件就够：

loop_traces_2026-06-18.jsonl

每行一条 trace。需要分析时，用 Python 读进来，跑上面的脚本。等数据量大了，再考虑迁移到专门的 observability 平台。

一个实用的做法：每天生成一个文件，文件名带日期。这样你可以按周、按月聚合，也可以单独拉出某一天的异常运行做根因分析。

先让 trace 存在，再让 dashboard 漂亮

很多人反过来了：先花时间搭漂亮的 dashboard，再想办法收集数据。结果是 dashboard 空着，loop 已经失控两周。

正确的顺序是：

1. 先在 loop 里加 measurement hook，让 trace 被记录下来
2. 写一个简单的脚本，每周从 trace 里算三个指标
3. 把三个指标画成时间序列图
4. 等这个流程跑顺了，再考虑更复杂的可视化

measurement 的最大敌人不是技术难度，而是”等我把工具链完善了再开始”。开始得越早，你犯的错误就越便宜。

第八章：测量之后是什么

测量不会让你的 loop 变得更好。它只会告诉你 loop 现在有多差，以及差在哪里。

这是很多人漏掉的一步。他们搭了 dashboard，画了控制图，每周开会 review 指标，然后继续凭感觉改 prompt。指标变成了表演，而不是决策依据。

测量之后的动作，才是 Loop Engineering 真正的开始。

从指标到诊断

每个异常指标背后都应该有一个假设。下面是常见指标异常和它们可能指向的根因：

注意这张表的关键词是”可能”。指标不会直接告诉你答案，它只告诉你该去哪里找答案。 最后的根因，永远要靠 trace 抽样、失败案例复盘和针对性实验来确认。

优先修什么

你不可能同时修所有问题。资源有限的时候，按两个维度排序：

1. 影响面：这个问题导致多少 trace 失败或变贵？
2. 修复成本：改 prompt、加工具、调流程、改 schema，哪个最快验证？

把问题放在这两个轴上，你会得到四个象限：

• 高影响、低成本：先修。通常是 prompt 优化、工具描述改写、加缓存。
• 高影响、高成本：排进 roadmap，需要设计改动。
• 低影响、低成本：顺手修，但不专门立项。
• 低影响、高成本：别碰。

制造业里这叫帕累托改进：80% 的损失往往来自 20% 的 defect 模式。你的第一个目标不是消灭所有失败，而是找到那 20%。

一次改进的最小闭环

测量之后的标准动作应该是这样的：

1. 发现信号：控制图显示完成率连续 5 天低于控制下限。
2. 形成假设：可能是上周上线的新工具描述导致 agent 误用。
3. 抽样验证：抽取 30 条失败 trace，数有多少条和该工具相关。
4. 小规模实验：回退工具描述，在 10% 的流量上跑 A/B。
5. 看指标说话：如果实验组完成率回升，全量发布；如果没有，回到第 2 步。
6. 记录知识：把这次根因和修复写进 runbook，下次同样信号出现时直接查。

这个闭环和制造业的 DMAIC（Define, Measure, Analyze, Improve, Control）没有本质区别。区别只在于制造业改的是机器参数，你改的是 prompt 和 harness。

不要测量一切

最后要提醒一个陷阱：测量是有成本的。每加一个指标，就要花时间去采集、存储、review、解释。如果你加了 20 个指标但只根据其中 3 个行动，那另外 17 个就是噪音。

定期做一件简单的事情：打开你的 dashboard，问自己——

“如果这个指标连续三天异常，我会采取什么具体行动？”

如果答不上来，删掉它。

测量不是目的，改进才是。 dashboard 上的数字只有变成代码改动、流程改动或设计改动，才值得被画出来。

下一篇我们会进入改进层：怎么把 Loop 从 1 Sigma 推到 4 Sigma。核心不是换模型，而是任务分解、独立验证、共识冗余和人工接管点的设计。

第九章：结语

Loop Engineering 不是玄学。它和制造业的质量管理一样，可以被测量、被控制、被改进。

你从三个指标开始：完成率、重试深度、每次成功成本。你跑两周建立基线。你画控制图，找失控信号。你根据数据改进 Harness，而不是根据感觉改 prompt。

这个过程不酷。它很无聊。但无聊的指标，恰恰是无人值守 loop 能活下去的前提。

不要让 vibe 决定你的 loop 是否继续运行。让数字决定。

金句卡片

• “你无法管理你不能测量的东西。”
• “Vibe 指标是轶事，过程指标是数据。”
• “控制图区分了普通原因变异和特殊原因变异。”
• “指标的数量应该和你能采取的行动数量匹配。”
• “不要让 vibe 决定你的 loop 是否继续运行。让数字决定。“

参考来源

• Digital Applied, “Agentic Workflow Completion Metrics: Pipeline Health 2026”, 2026-05-12
• Corvair.ai, “Six Sigma for Agentic AI”, 2026
• Lyzr.ai, “Six Sigma (6σ) Agent”, 2026-04-21
• James Xie, “Loop Engineering 的本质：Agentic AI 的六西格玛缺口”, 2026-06-18