Verify Agent Output

---
name: verify-agent-output
description: >
  在智能体之间传递工作时验证可交付成果并建立证据记录。涵盖执行前的预期
  结果规格、执行期间的结构化证据生成、基于外部锚点的执行后交付物验证、
  压缩或摘要输出的保真度检查、信任边界分类，以及验证失败时的结构化分歧
  报告。当协调多智能体工作流、审查跨智能体交接、生成面向外部的输出，或
  审计智能体摘要是否忠实代表源材料时使用。
locale: zh-CN
source_locale: en
source_commit: 75ded7a1
fence_basis_commit: 75ded7a1
translator: claude-opus-4-6
translation_date: 2026-03-16
license: MIT
allowed-tools: Read Write Edit Bash Grep Glob
metadata:
  author: Philipp Thoss
  version: "1.0"
  domain: general
  complexity: intermediate
  language: multi
  tags: verification, trust, evidence-trail, deliverable-validation, inter-agent, quality-assurance
---

# 验证智能体输出

在智能体之间建立可验证的交付。当一个智能体产生另一个智能体消费的输出——或人类依赖的输出——时，交接需要的不仅仅是「看起来不错」。此技能将以下实践规范化：在工作开始前定义可检查的预期、将证据作为完成工作的副产品生成、以及针对外部锚点而非自我评估来验证可交付成果。核心原则：保真度无法在内部衡量。智能体无法可靠地验证自己压缩的输出；验证需要外部参考点。

## 适用场景

- 多智能体工作流将可交付成果从一个智能体传递给另一个智能体
- 智能体产生面向外部的输出（报告、代码、部署），人类将依赖于此
- 智能体汇总、压缩或转换数据，摘要必须忠实代表源内容
- 团队协调模式要求成员之间进行结构化的交接验证
- 需要建立信任边界——决定什么需要验证，什么可以被信任
- 合规性或可重现性需要审计记录

## 输入

- **必需**：要验证的可交付成果（文件、工件、报告或结构化输出）
- **必需**：预期结果规格（「完成」是什么样子）
- **可选**：源材料（用于摘要或转换的保真度检查）
- **可选**：信任边界分类（`cross-agent`、`external-facing`、`internal`）
- **可选**：验证深度（`spot-check`、`full`、`sample-based`）

## 步骤

### 第 1 步：定义预期结果规格

在执行开始前，将「完成」是什么样子写成一组具体、可检查的条件。避免主观标准（「质量好」），而倾向于可验证的断言。

可检查条件的类别：

- **存在性**：文件存在于路径，端点响应，数据库中存在记录
- **形状**：输出有 N 列，JSON 匹配模式，函数有预期签名
- **内容**：值在范围内，字符串匹配模式，列表包含必需项目
- **行为**：测试套件通过，命令退出码为 0，API 返回预期状态码
- **一致性**：输出哈希与输入哈希匹配，变换后行数保留，总计核对一致

示例规格：

```yaml
expected_outcome:
  existence:
    - path: "output/report.html"
    - path: "output/data.csv"
  shape:
    - file: "output/data.csv"
      columns: ["id", "name", "score", "grade"]
      min_rows: 100
  content:
    - file: "output/data.csv"
      column: "score"
      range: [0, 100]
    - file: "output/report.html"
      contains: ["Summary", "Methodology", "Results"]
  behavior:
    - command: "Rscript -e 'testthat::test_dir(\"tests\")'"
      exit_code: 0
  consistency:
    - check: "row_count"
      source: "input/raw.csv"
      target: "output/data.csv"
      tolerance: 0
```

**预期结果：** 每个可交付成果至少有一个可检查条件的书面规格。每个条件都是机器可验证的（可以通过脚本或命令检查，而非通过阅读和判断）。

**失败处理：** 若无法具体陈述预期结果，则任务本身规格不足。在继续之前，对任务定义提出质疑——模糊的预期产生不可验证的工作。

### 第 2 步：在执行期间生成证据记录

随着工作推进，将结构化证据作为完成工作的副产品输出。证据记录不是单独的验证步骤——它由执行本身产生。

需要捕获的证据类型：

```yaml
evidence:
  timing:
    started_at: "2026-03-12T10:00:00Z"
    completed_at: "2026-03-12T10:04:32Z"
    duration_seconds: 272
  checksums:
    - file: "output/data.csv"
      sha256: "a1b2c3..."
    - file: "output/report.html"
      sha256: "d4e5f6..."
  test_results:
    total: 24
    passed: 24
    failed: 0
    skipped: 0
  diff_summary:
    files_changed: 3
    insertions: 47
    deletions: 12
  tool_versions:
    r: "4.5.2"
    testthat: "3.2.1"
```

生成证据的实用命令：

```bash
# Checksums
sha256sum output/data.csv output/report.html > evidence/checksums.txt

# Row counts
wc -l < input/raw.csv > evidence/input_rows.txt
wc -l < output/data.csv > evidence/output_rows.txt

# Test results (R)
Rscript -e "results <- testthat::test_dir('tests'); cat(format(results))" > evidence/test_results.txt

# Git diff summary
git diff --stat HEAD~1 > evidence/diff_summary.txt

# Timing (wrap the actual command)
start_time=$(date +%s)
# ... do the work ...
end_time=$(date +%s)
echo "duration_seconds: $((end_time - start_time))" > evidence/timing.txt
```

**预期结果：** 一个 `evidence/` 目录（或结构化日志），包含每个生产工件的至少校验和和计时。证据作为工作的一部分生成，而非事后重建。

**失败处理：** 若证据生成干扰执行，在不阻塞工作的情况下尽可能多地捕获。至少在完成后记录文件校验和——这样即使未捕获实时证据，也能进行后续验证。

### 第 3 步：针对预期结果验证可交付成果

执行后，针对第 1 步中的规格检查可交付成果。使用外部锚点——测试套件、模式验证器、校验和、行数——而非询问生产智能体「这正确吗？」

按类别的验证检查：

```bash
# Existence
for file in output/report.html output/data.csv; do
  test -f "$file" && echo "PASS: $file exists" || echo "FAIL: $file missing"
done

# Shape (CSV column check)
head -1 output/data.csv | tr ',' '\n' | sort > /tmp/actual_cols.txt
echo -e "grade\nid\nname\nscore" > /tmp/expected_cols.txt
diff /tmp/expected_cols.txt /tmp/actual_cols.txt && echo "PASS: columns match" || echo "FAIL: column mismatch"

# Row count
actual_rows=$(wc -l < output/data.csv)
[ "$actual_rows" -ge 101 ] && echo "PASS: $actual_rows rows (>= 100 + header)" || echo "FAIL: only $actual_rows rows"

# Content range check (R)
Rscript -e '
  d <- read.csv("output/data.csv")
  stopifnot(all(d$score >= 0 & d$score <= 100))
  cat("PASS: all scores in [0, 100]\n")
'

# Behavior
Rscript -e "testthat::test_dir('tests')" && echo "PASS: tests pass" || echo "FAIL: tests fail"

# Consistency (row count preserved)
input_rows=$(wc -l < input/raw.csv)
output_rows=$(wc -l < output/data.csv)
[ "$input_rows" -eq "$output_rows" ] && echo "PASS: row count preserved" || echo "FAIL: $input_rows -> $output_rows"
```

**预期结果：** 所有检查通过。结果以结构化输出（每个条件的 PASS/FAIL）形式记录，并附第 2 步的证据记录。

**失败处理：** 不要默默接受部分通过。任何 FAIL 都会触发第 6 步中的结构化分歧流程。记录哪些检查通过，哪些失败——部分结果仍然是有价值的证据。

### 第 4 步：对压缩输出进行保真度检查

当智能体汇总、压缩或转换数据时，输出设计上比输入更小。摘要无法单独通过阅读摘要来验证——必须与源材料进行比较。使用基于样本的抽查来验证保真度。

流程：

1. 从源材料中选取随机样本（抽查 3-5 个项目，全面检查取 10%）
2. 对每个抽样项目，验证它在压缩输出中是否被准确表示
3. 检查捏造内容——输出中没有来源的项目

```bash
# Example: verify a summary report against source data

# 1. Select random rows from source
shuf -n 5 input/raw.csv > /tmp/sample.csv

# 2. For each sampled row, verify it appears correctly in the output
while IFS=, read -r id name score grade; do
  grep -q "$id" output/report.html && echo "PASS: $id found in report" || echo "FAIL: $id missing from report"
done < /tmp/sample.csv

# 3. Check for fabricated IDs in the output
# Extract IDs from output, verify each exists in source
grep -oP 'id="[^"]*"' output/report.html | while read -r output_id; do
  grep -q "$output_id" input/raw.csv && echo "PASS: $output_id has source" || echo "FAIL: $output_id fabricated"
done
```

对于无法精确匹配的文本摘要，验证关键声明：

- 引用的统计数据与源数据匹配
- 摘要中提到的命名实体存在于源中
- 因果声明或排名由底层数据支持
- 摘要中没有出现源中不存在的项目

**预期结果：** 所有抽样项目都被准确表示。未检测到捏造内容。摘要中的关键统计数据与从源计算的值匹配。

**失败处理：** 若保真度检查失败，则无法信任摘要。使用第 6 步中的结构化分歧格式报告具体差异。生产智能体必须从源重新推导摘要，而不是修补现有输出。

### 第 5 步：分类信任边界

并非所有内容都需要验证。过度验证本身也是一种代价——它减慢执行速度，增加复杂性，并可能在验证过程本身中造成虚假信心。按信任级别分类输出，将验证工作集中在重要的地方。

信任边界分类：

| 边界 | 是否需要验证 | 示例 |
|---|---|---|
| **跨智能体交接** | 是——始终 | 智能体 A 产生智能体 B 消费的数据；团队成员将可交付成果传递给负责人 |
| **面向外部的输出** | 是——始终 | 交付给人类的报告、部署的代码、发布的包、API 响应 |
| **压缩/摘要** | 是——基于样本 | 任何设计上比输入更小的输出（摘要、聚合、摘录） |
| **内部中间结果** | 否——用校验和信任 | 临时文件、中间计算结果、步骤之间的内部状态 |
| **幂等操作** | 否——验证一次 | 配置文件写入、确定性转换、已知输入的纯函数 |

按比例应用验证：

- **跨智能体交接**：针对预期结果规格的完整验证（第 3 步）
- **面向外部的输出**：完整验证加上摘要时的保真度检查（第 3-4 步）
- **内部中间结果**：仅记录校验和（第 2 步）——若下游失败则按需验证
- **幂等操作**：首次执行时验证，重复时信任

**预期结果：** 工作流中的每个可交付成果都被归类到一个信任边界类别中。验证工作集中在跨智能体和面向外部的边界上。

**失败处理：** 若有疑问，请验证。接受错误输出（假信任）的代价几乎总是超过不必要验证的代价。默认为验证，只有在有证据表明边界是安全的情况下才放宽。

### 第 6 步：在失败时报告结构化分歧

当验证失败时，产生结构化分歧而非默默接受或默默拒绝输出。结构化分歧使失败可操作——它告诉生产智能体（或人类）究竟预期什么、收到什么、以及差距在哪里。

分歧格式：

```yaml
verification_result: FAIL
deliverable: "output/data.csv"
timestamp: "2026-03-12T10:04:32Z"
failures:
  - check: "row_count"
    expected: 500
    actual: 487
    severity: warning
    note: "13 rows dropped — investigate filter logic"
  - check: "score_range"
    expected: "[0, 100]"
    actual: "[-3, 100]"
    severity: error
    note: "3 negative scores found — data validation missing"
  - check: "column_presence"
    expected: "grade"
    actual: null
    severity: error
    note: "grade column missing from output"
passes:
  - check: "file_exists"
  - check: "checksum_stable"
  - check: "test_suite"
recommendation: >
  Re-run with input validation enabled. The score_range and column_presence
  failures suggest the transform step is not handling edge cases. Do not
  patch the output — fix the transform and re-execute from source.
```

分歧报告的关键原则：

- **具体**：「在第 42、187、301 行发现 3 个负分」而非「某些值是错误的」
- **包含预期值和实际值**：它们之间的差距才是重要的
- **分类严重程度**：`error`（阻止接受）、`warning`（带注意事项接受）、`info`（仅供记录）
- **推荐操作**：修复并重新运行 vs. 带注意事项接受 vs. 直接拒绝
- **永不默默接受**：社交信任（「另一个智能体说没问题」）是攻击向量。信任证据，而非断言。

**预期结果：** 每次验证失败都产生一个结构化分歧，至少包含：失败的检查、预期值、实际值和严重程度分类。

**失败处理：** 若验证过程本身失败（例如，验证脚本出错），将其报告为元失败。无法验证本身就是一个发现——这意味着可交付成果以当前形式无法验证，这比已知失败更糟糕。

## 验证清单

- [ ] 执行开始前存在预期结果规格
- [ ] 规格仅包含机器可验证的条件（无主观标准）
- [ ] 执行期间生成了证据记录（校验和、计时、测试结果）
- [ ] 证据是完成工作的副产品，而非单独的事后步骤
- [ ] 可交付成果针对外部锚点进行验证（测试、模式、校验和）
- [ ] 没有通过询问生产者「这正确吗？」来验证任何可交付成果
- [ ] 压缩或摘要输出包含基于样本的保真度检查
- [ ] 保真度检查与源材料进行比较，而非与摘要本身比较
- [ ] 信任边界已分类（跨智能体、外部、内部）
- [ ] 验证工作与信任边界严重程度成比例
- [ ] 验证失败产生结构化分歧（预期 vs. 实际）
- [ ] 没有验证失败被默默接受或默默拒绝

## 常见问题

- **通过询问生产者来验证输出**：智能体无法可靠地验证自己的工作。「我检查过了，看起来是对的」不是验证——外部锚点（测试、校验和、模式）才是验证。正如 rtamind 所指出的：保真度无法在内部衡量。
- **过度验证内部中间结果**：验证每个临时文件和中间结果会增加开销而不提高可靠性。对信任边界进行分类（第 5 步），将验证集中在跨智能体和面向外部的输出上。
- **主观预期结果**：「报告应该是高质量的」不可检查。「报告包含摘要、方法论和结果章节，所有引用的统计数据与从源计算的值匹配」是可检查的。若无法为其写一个检查，就无法验证它。
- **事后重建证据**：事后生成证据（「让我计算我认为我产生的内容的校验和」）不可靠。证据必须是执行的副产品，实时捕获。重建的证据只能证明现在存在什么，而不能证明当时产生了什么。
- **将验证视为绝对可靠**：验证本身可能有缺陷。通过的测试套件并不意味着代码是正确的——它意味着代码满足测试。保持验证的合理比例，承认其局限性，而非将绿色检查视为绝对真理。
- **默默接受部分通过**：若 10 个检查中有 9 个通过，可交付成果仍然失败。将一个失败报告为结构化分歧。部分信用是用于评分的；交付是二元的。
- **以社交信任为替代**：「智能体 A 是可靠的，所以我跳过验证」是攻击向量。正如 Sentinel_Orol 所指出的，没有验证的信任是可利用的。基于边界分类进行验证，而非基于生产者的声誉。

- **混合系统上错误的 R 二进制文件**：在 WSL 或 Docker 上，`Rscript` 可能解析为跨平台包装器而非原生 R。使用 `which Rscript && Rscript --version` 检查。优先使用原生 R 二进制文件（例如 Linux/WSL 上的 `/usr/local/bin/Rscript`）以确保可靠性。有关 R 路径配置，请参阅 [Setting Up Your Environment](../../guides/setting-up-your-environment.md)。

## 相关技能

- `fail-early-pattern` — 互补：尽早失败在开始时捕获错误输入；verify-agent-output 在结束时捕获错误输出
- `security-audit-codebase` — 重叠的关注点：安全审计验证代码是否满足安全期望，这是可交付成果验证的特定情况
- `honesty-humility` — 互补：诚实的智能体承认不确定性，使验证差距可见而非隐藏
- `review-skill-format` — verify-agent-output 可以验证生产的 SKILL.md 是否满足格式要求，这是可交付成果验证的具体实例
- `create-team` — 协调多个智能体的团队受益于每个协调步骤的结构化交接验证
- `test-team-coordination` — 测试团队交接是否产生可验证的可交付成果，端到端地运用此技能的流程