跳转至

Santa Method

多代理对抗性验证框架。制作清单,双重检查。如果有问题,就修正到变好为止。

核心洞察:评审自己输出的单个代理,会与产生该输出的代理共享相同的偏见、知识缺口和系统性错误。两名没有共享上下文的独立评审者可以消除这种故障模式。

启动时机

在以下情况下调用此技能: - 输出将被发布、部署或提供给最终用户 - 需要应用合规、监管或品牌约束 - 代码在没有人工审查的情况下部署到生产环境 - 内容准确性重要(技术文档、教育资料、面向客户的文案) - 大规模批量生成,其中抽查可能遗漏系统性模式 - 幻觉风险较高(声明、统计数据、API 引用、法律语言)

不要用于内部草稿、探索性研究,或存在确定性验证的情况(对这些使用构建/测试/Lint 流水线)。

架构

┌─────────────┐
│  GENERATOR   │  フェーズ1: リストを作る
│  (Agent A)   │  成果物を生成する
└──────┬───────┘
       │ output
       ▼
┌──────────────────────────────┐
│     DUAL INDEPENDENT REVIEW   │  フェーズ2: 二度確認する
│                                │
│  ┌───────────┐ ┌───────────┐  │  2つのエージェント、同じルーブリック、
│  │ Reviewer B │ │ Reviewer C │  │  共有コンテキストなし
│  └─────┬─────┘ └─────┬─────┘  │
│        │              │        │
└────────┼──────────────┼────────┘
         │              │
         ▼              ▼
┌──────────────────────────────┐
│        VERDICT GATE           │  フェーズ3: 良いか悪いか
│                                │
│  B passes AND C passes → NICE  │  両方が合格する必要がある。
│  Otherwise → NAUGHTY           │  例外なし。
└──────┬──────────────┬─────────┘
       │              │
    NICE           NAUGHTY
       │              │
       ▼              ▼
   [ SHIP ]    ┌─────────────┐
               │  FIX CYCLE   │  フェーズ4: 良くなるまで修正
               │              │
               │ iteration++  │  全フラグを収集する。
               │ if i > MAX:  │  全問題を修正する。
               │   escalate   │  両レビュアーを再実行する。
               │ else:        │  収束するまでループ。
               │   goto Ph.2  │
               └──────────────┘

阶段详情

阶段 1:制作清单(生成)

执行主要任务。常规生成工作流没有变化。Santa Method 是生成后的验证层,而不是生成策略。

# ジェネレーターは通常通り実行される
output = generate(task_spec)

阶段 2:双重检查(独立双重评审)

并行启动两个评审代理。关键不变条件:

  1. 上下文隔离 — 任一评审者都不查看对方的评估
  2. 相同评分标准 — 两者接收相同的评估标准
  3. 相同输入 — 两者接收原始规格和生成的输出
  4. 结构化输出 — 每个返回类型化判定,而不是散文
REVIEWER_PROMPT = """
あなたは独立した品質レビュアーです。この出力に対する他のレビューは見ていません。

## タスク仕様
{task_spec}

## レビュー対象の出力
{output}

## 評価ルーブリック
{rubric}

## 指示
各ルーブリック基準に対して出力を評価してください。それぞれに対して:
- PASS: 基準が完全に満たされ、問題なし
- FAIL: 特定の問題が見つかった(正確な問題を引用)

評価を構造化JSONとして返してください:
{
  "verdict": "PASS" | "FAIL",
  "checks": [
    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
  ],
  "critical_issues": ["..."],   // 修正が必要なブロッカー
  "suggestions": ["..."]         // ブロックしない改善提案
}

厳格に評価してください。あなたの仕事は問題を見つけることであり、承認することではありません。
"""
# レビュアーを並列で起動(Claude Code サブエージェント)
review_b = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer B")
review_c = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer C")

# 両方が同時に実行される — 互いに見えない

评分标准设计

评分标准是最重要的输入。模糊的评分标准会产生模糊的评审。每个标准都需要客观的通过/失败条件。

标准 合格条件 失败信号
事实准确性 所有声明均可从源材料或常识中验证 编造的统计数据、错误的版本号、不存在的 API
无幻觉 没有编造的实体、引用、URL、引用 链接到不存在的页面、无出处的引用
完整性 规格中的所有要求均被覆盖 缺失章节、跳过的边缘情况、覆盖不完整
合规性 通过所有项目特定约束 使用禁用词、语气违规、不符合监管要求
内部一致性 输出内部无矛盾 章节 A 说 X,章节 B 说非 X
技术准确性 代码可编译/运行,算法健全 语法错误、逻辑 bug、错误的复杂度声明

领域特定的评分标准扩展

内容/营销: - 品牌声音一致性 - 满足 SEO 要求(关键词密度、元标签、结构) - 未误用竞争对手商标 - CTA 存在且链接正确

代码: - 类型安全(无 any 泄漏、适当的 null 处理) - 错误处理覆盖 - 安全性(代码中无密钥、输入验证、防注入) - 新路径的测试覆盖

合规性重要时(受监管、法律、财务): - 无结果保证或无依据声明 - 存在必要的免责声明 - 仅使用已批准术语 - 适合管辖区域的措辞

阶段 3:好或坏判定(Verdict Gate)

def santa_verdict(review_b, review_c):
    """両方のレビュアーが合格する必要がある。部分的な評価なし。"""
    if review_b.verdict == "PASS" and review_c.verdict == "PASS":
        return "NICE"  # 出荷する

    # 両方のレビュアーのフラグをマージし、重複を排除
    all_issues = dedupe(review_b.critical_issues + review_c.critical_issues)
    all_suggestions = dedupe(review_b.suggestions + review_c.suggestions)

    return "NAUGHTY", all_issues, all_suggestions

为什么必须双方都通过:如果只有一位评审者检测到问题,那么该问题是真实存在的。另一位评审者的盲点,正是 Santa Method 试图消除的故障模式。

阶段 4:修正直到变好(收敛循环)

MAX_ITERATIONS = 3

for iteration in range(MAX_ITERATIONS):
    verdict, issues, suggestions = santa_verdict(review_b, review_c)

    if verdict == "NICE":
        log_santa_result(output, iteration, "passed")
        return ship(output)

    # すべての重大な問題を修正する(提案はオプション)
    output = fix_agent.execute(
        output=output,
        issues=issues,
        instruction="フラグが立てられた問題のみを修正してください。リファクタリングや未要求の変更は行わないでください。"
    )

    # 修正した出力で両方のレビュアーを再実行する(新しいエージェント、前のラウンドの記憶なし)
    review_b = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
    review_c = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))

# イテレーション回数を超えた — エスカレート
log_santa_result(output, MAX_ITERATIONS, "escalated")
escalate_to_human(output, issues)

重要:每个评审轮次都使用全新代理。评审者不得保留上一轮的记忆,因为先前上下文会产生锚定偏差。

实现模式

子代理提供真正的上下文隔离。每个评审者都是没有共享状态的独立进程。

# Claude Code セッションでエージェントツールを使用してレビュアーを起動する
# 速度のために両エージェントを並列で実行する
# エージェントツール呼び出しの擬似コード
reviewer_b = Agent(
    description="Santa Review B",
    prompt=f"この出力の品質をレビューしてください...\n\nルーブリック:\n{rubric}\n\n出力:\n{output}"
)
reviewer_c = Agent(
    description="Santa Review C",
    prompt=f"この出力の品質をレビューしてください...\n\nルーブリック:\n{rubric}\n\n出力:\n{output}"
)

模式 B:顺序内联(回退)

如果无法使用子代理,则通过显式上下文重置来模拟隔离:

  1. 生成输出
  2. 新上下文:“你是评审者 1。仅针对此评分标准进行评估。找出问题。”
  3. 逐字记录发现
  4. 完全清除上下文
  5. 新上下文:“你是评审者 2。仅针对此评分标准进行评估。找出问题。”
  6. 比较两次评审,修正并重复

子代理模式严格更优——内联模拟存在评审者之间上下文泄漏的风险。

模式 C:批量采样

对于大规模批次(100 件以上),对所有项目应用完整 Santa 在成本上不现实。使用分层抽样:

  1. 在随机样本上运行 Santa(批次的 10 到 15%,最少 5 件)
  2. 按类型对失败进行分类(幻觉、合规性、完整性等)
  3. 如果出现系统性模式,对整个批次应用针对性修复
  4. 对修复后的批次重新采样并重新验证
  5. 持续进行,直到干净样本通过
import random

def santa_batch(items, rubric, sample_rate=0.15):
    sample = random.sample(items, max(5, int(len(items) * sample_rate)))

    for item in sample:
        result = santa_full(item, rubric)
        if result.verdict == "NAUGHTY":
            pattern = classify_failure(result.issues)
            items = batch_fix(items, pattern)  # パターンに一致する全アイテムを修正
            return santa_batch(items, rubric)   # 再サンプリング

    return items  # クリーンなサンプル → バッチを出荷

故障模式与缓解措施

故障模式 症状 缓解措施
无限循环 审查者在修复后继续发现新问题 最大迭代上限(3 次)。升级处理。
橡皮图章式批准 两位审查者都通过所有内容 对抗性提示:“你的工作是发现问题,而不是批准。”
主观漂移 审查者将风格偏好而非错误标记出来 仅包含客观通过/失败标准的严格评分标准
修复导致回归 修复问题 A 引发问题 B 每轮使用新的审查者检测回归
审查者共识偏差 两位审查者都漏掉同样的问题 通过独立性缓解但无法消除。对重要输出添加第三位审查者或人工抽查
成本爆炸 对大规模输出迭代次数过多 批量采样模式。每个验证循环的预算上限。

与其他技能集成

技能 关系
Verification Loop 用于确定性检查(构建、Lint、测试)。Santa 用于语义检查(准确性、幻觉)。先运行验证循环,然后运行 Santa。
Eval Harness Santa Method 的结果反映到 Eval 指标中。在整个 Santa 运行中跟踪 pass@k,以衡量生成器随时间的质量。
Continuous Learning v2 Santa 的发现成为本能。在相同标准下反复失败 → 学习到的行为以避开模式。
Strategic Compact 在压缩前运行 Santa。避免在验证过程中丢失审查上下文。

指标

为了测量 Santa Method 的效果,我们跟踪以下指标:

  • 首次通过率: 第 1 轮通过 Santa 的输出百分比(目标:>70%)
  • 平均收敛迭代次数: 达到 NICE 所需的平均轮数(目标:<1.5)
  • 问题分类: 失败类型的分布(幻觉 vs 完整性 vs 合规性)
  • 审查者一致性: 两位审查者都标记的问题 vs 仅一方标记的百分比(低一致性 = 需要改进评分标准)
  • 逃逸率: Santa 本应检测到但在交付后才发现的问题(目标:0)

成本分析

Santa Method 每个验证循环的成本约为单个生成 token 成本的 2 到 3 倍。对于大多数高风险输出,这是划算的:

Santa のコスト = (生成トークン) + 2×(ラウンドあたりのレビュートークン) × (平均ラウンド数)
Santa を使わないコスト = (評判の損害) + (修正の労力) + (信頼の侵食)

批量操作中,通过采样模式,可以在检测 >90% 系统性问题的同时,将成本降低到完整验证的约 15 到 20%。

本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 ev/ECC