文档 / architecture / pipeline

5 层流水线

一轮 Skill Wiki 严格分五层。三层是协议（v1 已冻结），两层可插拔（由领域定义）。

流水线

逐层细看

L1 · 意图分类（plugin）

输入自由文本 brief。输出 IntentObject。形状由领域定义 —— Skill Wiki 只规定 L1 必须产出一个下游可读的可序列化对象。

// Example (security domain)
interface SecurityIntentObject {
  task_type: "threat-model" | "compliance-check" | "code-review";
  target_surface: "api-endpoint" | "auth-flow" | "data-pipeline";
  severity_threshold: "low" | "medium" | "high" | "critical";
  required_frameworks: string[];
  ambiguity_flags: string[];
}

L2 · 检索（protocol）

输入 IntentObject + corpus index。输出排序后的原子集合。 参考实现用 6 轴排序：kind 匹配、tag 匹配、边的中心性、投影适配度成本、persona 亲和度、validator 质量。 协议本身只规定 L2 返回带解释的 atom id 有序列表。

L3 · 组合（protocol）

输入排序后的原子 + 各自的 contract。输出"已契约化的集合" —— contract 解析过的原子（must-include 拉进来、must-avoid 过滤掉、conditional 对照 IntentObject 计算）。 每个原子的投影层级也在这一步根据预算决定。

L4 · 生成（agent）

L4 就是 agent 自己。在已契约化的原子集合 + 加载好的投影下，agent 生成最终产物。 Skill Wiki 不规定 agent 怎么生成 —— 只规定它生成时上下文里有什么。

L5 · 验证（plugin）

输入生成产物 + corpus 规则。输出裁决。形状由领域定义： HTML 结构校验、JSON-schema 校验、对散文跑 regex、用 LLM judge 对照打分卡 —— 都是合法的 L5 实现。 失败会暴露修复指令；最多两轮重试，再失败就硬抛错。

为什么叫 "L5" 不叫 "L4"？

L1、L2、L3 名字上都是编译期校验器（parser → semantic → cross-atom）。 L4 是 agent。L5 是运行时输出校验器。命名一致 —— 每个 L 前缀都是"第 N 层校验"。 生成本身没有 L 编号。

哪些冻结、哪些自由