用 loop-builder 把一个真实形状的任务装配成自治 loop,走完 SKILL.md 的全部交付物(Ring -1 结论 → 三角色实例化 → 验收标准表 → ach 绑定 → 阈值)。 案例本身平凡,方法才是重点。
"这个月度报表脚本要跑 40 分钟,经常整晚挂着人工盯。把它优化到 5 分钟以内, 结果数字不许变。"
三问:
- 会重复吗? 是——优化是多轮尝试(profile → 改一处 → 重测),没人能一步到位。
- 验收能否客观定义? 能——运行时长可测量,"数字不许变"可转成输出对比断言。
- 会跑偏 / 空转吗? 是,而且是典型形态:优化任务极易陷入"换一个库再试试"的 同层打转,或为提速悄悄牺牲正确性(主次倒置)。
三个都"是" → 值得 loop 化。(反例:如果这脚本一年只跑一次、40 分钟无人在意, 第三问不成立,直接人肉改一次就好——loop-builder 应当说"不值得"并退出。)
| 角色 | 本例实例 | 关键纪律 |
|---|---|---|
| 验收+新目标 Agent | 独立子代理 A | 持有验收表;执行自报"完成"时独立重跑计时 + 输出比对;不参与优化 |
| Loop Agent(执行) | 子代理 B | 每轮:profile → 单一最小改动 → 重测 → 归类(①~⑥)→ 证据落 ach |
| 监管 Agent | 独立子代理 C | 只读 ach 轨迹;判收敛;可叫停;不给优化出主意 |
两两独立,不共用同一个上下文——执行不能自评,验收不能给自己放水, 监管不旁观就看不清打转。
从种子清单(软件类:性能 / 正确 / 可维护 / 可靠)裁剪,每条 = { 可独立验证的事实, 必要性, 防住哪个失败 }:
| 维度 | 判据(程度) | 必要性 | 防住什么 |
|---|---|---|---|
| 性能 | 标准输入下端到端 ≤ 5 分钟(梯度型:目标 5,可接受下限 8) | P0 | 任务的存在理由 |
| 正确 | 三组历史输入,输出与基线逐单元格一致(pass/fail) | P0 | 为提速改坏数字 |
| 可靠 | 连续 3 次运行时长方差 < 20%(稳定类:连跑确认) | P1 | 偶然快一次就交差 |
| 可维护 | 改动集中在脚本仓库内,不引入新的常驻服务 | P2 | 优化变成基建工程 |
红线(不进可牺牲验收表):不得修改源数据;不得改动报表消费方的接口。 这样"提速 vs 正确"就不是两个打架的 P0——正确是验收 P0,提速是推进目标, 源数据是红线,天然可排序。
开局先调起 ach 建状态根(如 ach init report-speedup):Charter(目标 + 上表 +
红线 + 预算)落 current-goal / confirmed-constraints;每轮的归类、证据
(profile 数据、计时、diff 结果)落尝试 ledger;叫停与重定向的理由落
decisions。真实字段名以 ach 实际输出为准,不另造存储。
| 参数 | 取值 | 理由 |
|---|---|---|
| K(连续空转跳闸) | 3 | 单轮成本中等(一次重测约 40 分钟内),不必取最小值 2 |
| W(验收距离窗口) | 5 | 比 K 略长,平滑"一轮变慢一轮变快"的抖动 |
| 预算主单位 | 轮数,上限 15 | 时间成本主要是重测,轮数最能代表消耗 |
| 稳定类连跑 | 3 次 | 对应"可靠"维度的方差判据 |
第 6~8 轮,执行 Agent 每轮都换了新方向(换 CSV 解析库 → 改分块大小 → 再换 另一个解析库),自报归类都是"①前进,耗时略降"。监管 Agent 读 ledger 发现: 三轮共享同一个已被第 4 轮 profile 否决的根假设("瓶颈在解析"——实测瓶颈 在跨表 join),验收距离(剩余 32 分钟 → 31 分钟)在 W=5 窗口内基本不减。 命中"同层打转"+"验收距离不减"两个信号 → 叫停,令执行交现状给验收 Agent 重定向:下一轮 Charter 把"优先处理 join 阶段"写入。没有独立监管,这个 loop 会体面地空转掉全部预算——每一轮看起来都很努力。
第 11 轮执行自测 P0 全绿 → 上交验收 Agent:独立重跑计时 4 分 20 秒,三组 历史输入输出比对一致,连跑 3 次方差 12%。P2(不引入常驻服务)满足;交付 声明中无需牺牲声明。验收 Agent 裁定完成,ach 状态根按其收尾流程封存。