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 是生成后的验证层,而不是生成策略。
阶段 2:双重检查(独立双重评审)¶
并行启动两个评审代理。关键不变条件:
- 上下文隔离 — 任一评审者都不查看对方的评估
- 相同评分标准 — 两者接收相同的评估标准
- 相同输入 — 两者接收原始规格和生成的输出
- 结构化输出 — 每个返回类型化判定,而不是散文
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)
重要:每个评审轮次都使用全新代理。评审者不得保留上一轮的记忆,因为先前上下文会产生锚定偏差。
实现模式¶
模式 A: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。仅针对此评分标准进行评估。找出问题。”
- 比较两次评审,修正并重复
子代理模式严格更优——内联模拟存在评审者之间上下文泄漏的风险。
模式 C:批量采样¶
对于大规模批次(100 件以上),对所有项目应用完整 Santa 在成本上不现实。使用分层抽样:
- 在随机样本上运行 Santa(批次的 10 到 15%,最少 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