Loop Engine 技能构建报告
从零到一的编排引擎设计全过程——需求碰撞、概念演化、执行幻觉防御、质量验证
2026.06.19作者：秋水澄清
这个技能不是为了解决一个具体的分析问题而生的。它的起点是一个观察：comprehensive-analysis 将三个子技能串成流水线的模式是可以通用的——如果把它从"财务分析三件套"中抽离出来，能不能造一个编排引擎，让用户任意组合 skill、自定义步骤、设门禁、加循环，形成端到端闭环？
于是有了 loop-engine。下面是这个技能从第一版草稿到双 Agent 设计审查的全部过程。
01 需求阶段
起点：一句话需求
最初的请求只有一句："帮我设计一个技能，专门做 loop 编排工作，可以组合不同的 skill，可以端到端闭环。"
四个关键问题
为了把这句话变成可执行的 spec，拆成了四个逐次收敛的问题：
- 触发场景 — 什么情况下用户会激活这个技能？
→ "当用户说：设计一个循环，设计一个loop，设计一个循环工程，或编排一组任务等"
- 编排粒度 — 组合的是整 skill 级、步骤级、还是混合？
→ "C) 混合"
- 闭环定义 — 端到端闭环包括自动校验、失败处理、汇总报告？
→ "全部"
- 与 comprehensive-analysis 的关系 — 是通用化版本还是独立框架？
→ "A) 通用编排器"
设计原则的逐次收敛
整个过程中一系列设计决策在对话中反复碰撞，最终收敛为 11 项核心原则。每条原则都不是一次到位的——有的是用户直接提出的，有的是我犯错后被用户纠正的，有的是在对抗检查中才暴露的。
原则 1 用户提出
三种执行模式
串行 / 并行 / 混合，用户显式选择
收敛过程：初版用 deponds_on 数组隐式推断并行，被用户否决："不对，应该是同时支持两种模式，有的loop可能是串行，有的可能可以并行，得选。"改为显式 mode 字段。
原则 2 用户提出
内外双层循环
retry（原地重试）+ loop（回退改进）
收敛过程：我问"什么时候需要回到某一点repeat"，举了质量回退、收敛式循环、分页获取等场景。用户抽象出 retry 和 loop 的区别，我说"retry是内循环，loop是外循环"，用户确认："可以这么理解"。
原则 3 用户提出
目标驱动闭环
目标 / 约束 / 验收 三要素
收敛过程：用户提出"定义什么是好的结果，具体展开可能是：目标，约束，验收方法"。我将其整合到循环终止逻辑中——目标达成是最高优先级的终止条件。
原则 4 AI建议
终止优先级链
目标达成 > max_iterations > timeout > 用户打断
收敛过程：设计审查中双 Agent 指出两处 max_iterations 含义不明。修复时明确了优先级：目标达成优先于次数上限，次数上限优先于超时，超时优先于用户打断。
原则 5 用户提出
模型决策 + 硬约束兜底
防执行幻觉第一道防线
收敛过程：用户说要"尽量给模型视情景需要自主决策"但同时"要注意模型的作弊（即执行幻觉）"。我提出了分层策略——模型决定做什么，但次数上限由执行引擎校验不可突破。
原则 6 AI建议
门禁独立 agent
主流程不自判质量
收敛过程：防幻觉纪律之一。用户对执行幻觉的担忧直接催生了"门禁校验必须走独立 subagent，不得由主流程模型自判"这条纪律。设计审查时又补充了 gate 自身失败的处理。
原则 7 用户提出
三种数据模式
overwrite / accumulate / ask
收敛过程：我问循环时数据覆盖还是累计，用户直接给出答案："数据覆盖还是累计，分三种：覆盖，累计，询问（用户）"。设计审查后补充了首次执行行为定义。
原则 8 踩坑后补
四种失败策略
retry / abort / skip / pause
收敛过程：设计审查指出多个示例缺 on_failure 声明、无默认值说明。修复时补充了未声明的默认行为，并标注了 skip 策略的数据依赖风险。
原则 9 踩坑后补
通用性约束
不绑定任何领域 skill
收敛过程：第一版所有示例用了 comprehensive-analysis 的 skill 名，测试时 agent 也跟着用。用户发现后直接骂："跟comprehensive-analysis没有关系！！"，"不要修了，删除，重来！"重写后所有示例改用抽象占位符。
原则 10 用户提出
用户定义 + AI 澄清
追问原则，不替用户做假设
收敛过程：用户说"允许用户补充定义，AI帮助澄清需求"。我将其转化为具体的追问原则——如果用户没说执行模式必须追问、提到"优化"主动建议加目标、通用动词不默认为特定 skill。
原则 11 AI建议
执行轨迹可审计
每阶段输出、每次 gate、每次循环均写文件
收敛过程：防幻觉纪律之一。双 Agent 设计审查进一步指出"数据传递机制缺失"，补充了完整的 phase 间数据传输规则和审计日志规范。
02 构建历程
从第一版到最终版，经历了五轮迭代，每次都有一个关键转折。
-
2026.06.19 15:00 · 轮次 1
初版草案 — 串行依赖图模型。第一版用依赖图隐式推断执行顺序（depends_on: [] 算并行，有依赖算串行）。用户看了说不行："应该是显式选择模式，不是隐式推断。"
-
2026.06.19 16:00 · 轮次 2
显式三模式 + 循环定义 — 改为用户选择 sequential / parallel / mixed。加了显式的 loops 定义（from / back_to / trigger / break / max_iterations）。同时讨论了 retry 和 loop 的区别——"retry 是内循环，loop 是外循环"这个类比就是此时定下来的。
-
2026.06.19 17:00 · 轮次 3
目标/约束/验收 + 防幻觉纪律 — 用户提出"定义什么是好结果——目标、约束、验收方法"和"模型自主决策但防执行幻觉"。防幻觉四条纪律在这个轮次写入了 SKILL.md。
-
2026.06.19 19:00 · 轮次 4
第一次测试 + 发现问题 — 写完了草案，跑了三个测试用例（串行+循环、并行、混合+目标驱动）。测试结果显示：三个 agent 都正确解析了需求并输出了 YAML 配置，但都将特定领域 skill（financial-fraud-detector、two-agents-check 等）硬编码到了示例中——"通用编排引擎设计了一个严重的问题：示例里全是财务分析的 skill 名。"
-
2026.06.19 21:00 · 轮次 5
重构 + 双 Agent 设计审查 — 删掉重来，所有示例改用抽象占位符。然后用 two-agents-check-who-is-lying 对 SKILL.md 做了独立设计审查。两个 agent 各自给出了审查报告，交叉裁决后总分 66/100，列出了 3 个 P0、5 个 P1、若干 P2 问题并逐一修复。
03 关键转折与决策
转折一：从隐式依赖到显式模式
第一版用 deponds_on 数组隐式推断并行：空依赖的 phase 自动并行跑。用户否决了——"有的 loop 可能是串行，有的可能可以并行，得选。"改为用户在设计流水线时显式声明 mode: sequential / parallel / mixed。
转折二：从领域绑定到通用
这是过程中代价最大的一次错误。第一版草案里的示例全用了用户之前项目中的 skill（financial-fraud-detector、web-access），导致 agent 在测试时也默认用这些 skill。"通用编排引擎里写了特定领域 skill 名"这个错误直到测试用例跑完后才发现。最终方案是所有示例都用抽象占位符，并在 SKILL.md 中加入通用性约束章节。
转折三：防执行幻觉系统的演化
从最初的一条"不要作弊"到最终的四条纪律体系，关键洞察来自用户："让模型视情景需要自主决策，但要注意模型的执行幻觉。"最终的博弈方案是分层策略——模型决定策略，硬约束做兜底；独立 agent 做门禁校验来验证"做了没有"。
转折四：循环终止优先级
设计过程中曾忽略了"为什么停止循环"的完整闭环。用户提醒后补上了四级终止优先级链（目标达成 > max_iterations > timeout > 用户打断），并为两级 max_iterations（loop 级 vs goal 级）做了明确区分。
04 双 Agent 设计审查
最终版 SKILL.md 完成后，使用 two-agents-check-who-is-lying 做了独立设计审查。两个 agent 背对背各自检查，然后交叉裁决。
双 Agent 发现的 8 个关键问题
| 优先级 | 问题 | 修复 |
|---|
| P0 | 示例硬编码特定 skill 名 | 全部替换为抽象占位符 |
| P0 | 执行机制缺失关键细节，不可执行 | 编写完整执行算法+数据传递机制 |
| P0 | 硬约束无强制执行机制 | 新增约束校验时机章节 |
| P1 | "第三步：执行"标题层级错误 | H2 降为 H3 |
| P1 | 三种模式缺独立文字定义 | 每种模式增加执行规则文字说明 |
| P1 | 数据传递机制缺失 | 定义完整传递规则 |
| P1 | 执行图漏了 max_iterations 检查 | 分三个时机补充检查逻辑 |
| P1 | retry 同一词含义过载 | 新增三重含义说明段落 |
双 Agent 可信度判断：双方均未出现"全部正确"的笼统断言，均提供了具体行号和有追溯力的证据。Agent A（自评 67）和 Agent B（自评 62）分数方向一致，属诚实信号。
05 经验教训
教训一：通用就不能举领域例子
最大的错误来自好意——为了让示例"看起来真实"，用了 comprehensive-analysis 里的 skill 名。结果是 agent 在测试时也跟着用这些领域 skill，完全背离了通用的初衷。通用技能的示例必须用抽象占位符，每一个具体的 skill 名都可能把模型带偏。
教训二：设计审查必须独立 agent，主流程模型会漏自己的错
我自己反复读了三遍 SKILL.md，没发现示例硬编码 skill 名的问题。但两个独立 agent 在背对背检查中一眼就抓出来了——而且 Agent A 和 Agent B 都独立发现了。主流程模型对自己的输出有确认偏误，独立审查不可替代。
教训三：从"模型说做"到"模型做了"之间的鸿沟
"模型决定策略、硬约束做兜底"这个原则看起来简单，但真正写进执行逻辑时才意识到难度：谁在运行时校验 max_iterations 不超标？谁检查 timeout？依赖 LLM 的自觉性就是没有强制执行。最终版不得不做了分层处理——模型做"是否循环、回到哪、怎么调参数"的策略判断，但次数上限由执行引擎在校验时机中检查，模型不可突破。
教训四："端到端闭环"不是全部设计完才开始用的
这个技能从需求解释到最终版共五轮迭代，每轮都有一个关键决策（模式选择、循环定义、防幻觉、通用性、可执行性）。如果等到"设计完"再测试，就不会发现通用性问题——正是因为第三轮就跑了三个测试用例，才在早期捕获了领域绑定的错误。端到端闭环也适用于设计过程本身。
06 最终产物
最终版 loop-engine SKILL.md 包含 ~320 行，覆盖：核心理念、三种执行模式（含文字定义和图解）、工作流程（需求解析→配置定义→执行→汇总报告）、阶段类型、内外循环机制、循环终止优先级、三种数据模式、数据传递规则、四种失败策略、门禁说明、防幻觉四条纪律、完整执行算法、约束校验机制。
所有领域的 skill 名均已替换为通用占位符。示例中的 check: "gate-skill" 和 method: "verification-skill" 由用户在实际使用中替换为具体的 skill 名。
设计审查后的 P0+P1 修复全部通过验证（12/12），最终版本已可用。