verify:判定权属于 Runtime

verify 表达式把"验证"从模型手里拿回来:check 收集证据, pass when 由 Runtime 求值,结论不可被 Agent 伪造。

基本形式

let result = verify {
  check highlights = agent(assistant) {
    task "Extract the week's key achievements"
    expect HighlightList
  }
  check risks = agent(assistant) {
    task "Aggregate every blocker into the risk list"
    expect RiskList
  }
  pass when highlights.items.any and risks.items.any
}

require result.passed else fail "report must surface highlights and risks"

结果类型是内建的 Verification<{highlights, risks}>:

{ passed: bool, failed: bool, checks: { highlights: HighlightList, risks: RiskList } }

只有三个成员:.passed / .failed(bool)与 .checks(所有 check 的结果对象)。

两条作用域规则

check 的初始化表达式在外层作用域求值——看不见 check 名自身, 但能读 stage 依赖、let 变量、input
pass when 在 verify 作用域求值——可见全部 check 名

check 名在 verify 内唯一(duplicate-check)。

check 可以是任意表达式

check 不必是 agent 调用——确定性表达式同样可以作为 check:

let audit = verify {
  check one_per_day  = unique(posts[*].day)        // 纯确定性:语言内建
  check brand_voice  = agent(strategist) { /*...*/ expect VoiceCheck }
  pass when one_per_day and brand_voice.ok
}

混合两类 check 是常见模式:确定性断言(唯一性、计数、交集)由语言直接算, 判断性检查(内容质量)交给 agent——但合取的最终判定永远在 pass when。

并行 check 组

verify 内可以嵌一个 parallel 组,组内 check 并发执行; 多个顶层项按序执行。checks 结果对象是所有组的扁平合并:

let gate = verify {
  parallel {
    check coverage = agent(moderator) { task "..." expect CoverageCheck timeout 2m }
    check edge     = agent(moderator) { task "..." expect EdgeCheck timeout 3m }
  }
  pass when coverage.ok and edge.ok
}

为什么 expect Verification 被禁止

expect 的类型必须是 Agent 能生产的 Schema;Verification 被明确排除(expect-invalid-type)。这条规则封死了一条作弊路径: 让 agent 直接返回"验证通过"。在 Agent Flow 里,agent 最多能返回证据 (如 TestReport{passed: bool}),而 workflow 级的"通过"结论 (verification.passed)只能由 pass when 表达式计算出来。

注意区分:agent 返回的 TestReport.passed 是证据字段(模型说测试过了), verify 结果的 .passed 是运行时判定(pass when 算出来的)。把前者接进后者是正当用法:

let result = verify {
  check tests = agent(tester) { task "Run the test suite" expect TestReport }
  pass when tests.passed          // Runtime 拿证据字段做合取
}

典型模式

闸门(gate)

require quality.passed else fail "screening gate failed"

verify 本身不抛错;用 require 把它变成硬闸门,失败抛 WorkflowAssertionError 并产生 require.failed 事件。

分流(不闸门,只影响走向)

if gate.passed {
  emit progress { doc: input.doc_path, gate: "passed" }
} else {
  emit progress { doc: input.doc_path, gate: "blocked" }
}
let verdict = agent(styler) {
  input { evidence: evidence, passed: gate.passed }   // 判定结果喂给下一步
  expect text
}

Verification 的值跨界

gate.passed、gate.checks.blockers.items 都是普通值,可以进入 agent 的 input、emit progress 载荷与返回对象——运行时判定的结论在 workflow 里自由流动,只是来源永远唯一。

下一步

作用域与可见性 —— 各结构的作用域链
limits 与能力

基本形式​

两条作用域规则​

check 可以是任意表达式​

并行 check 组​

为什么 expect Verification 被禁止​

典型模式​

闸门(gate)​

分流(不闸门,只影响走向)​

Verification 的值跨界​

下一步​