# Sansheng

> 三省（sansheng）——多 Agent 并行调研工坊。把 OpenRouter Fusion API 的"panel + judge + 综合"多模型协作思路映射到 Claude Code 原生 Agent tool。 名字典故：曾子"吾日三省吾身"（独立反思）+ 三省六部（多部独立议事综合决策），三 = 推荐的 sub-agent 数。 方法论：spawn N 个 sub-agent 从互补角度并行调研 → 主 agent 做 Judge 交叉评审（标共识/分歧/缺口/独特观点）→ 综合输出敢下判断的结论。 当用户需要做"开放性研究、对比、评审、选型、风险盘点、跨领域调研"时使用。最终产出一份带共识/分歧/缺口标记的综合判断，以及可立即落地的下一步。 触发词包括但不限于：研究下 X、对比 X 和 Y、评审这个方案、X 的选型建议、X 有哪些风险、分析下 X、调研一下 X、X 和 Y 哪个更适合 Z、帮我看看 X 怎么选、X 方案有什么坑、三省一下 X、让三省看看。 即使用户只是丢一个开放性问题"应该 A 还是 B"、或要"全面看一下 X"，只要任务有多个合理答案、需要多视角综合，都应该触发。 不要用于答案唯一的任务（bug 已定位、格式转换、单函数实现、删除冗余代码）；不要用于用户在线等结果的实时迭代场景（spawn + 综合至少要 1-2 分钟）；不要用于单页 web 查询能搞定的轻量问题。

- Skill: `dqt-bit/sansheng` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add dqt-bit/sansheng`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dqt-bit/sansheng/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: DQT-bit (https://skillmd.com/u/dqt-bit)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dqt-bit/sansheng

---


# 三省 | 多 Agent 并行调研工坊

> **工坊规矩**
> 「吾日三省吾身」——独立反思三遍胜过一遍想透。OpenRouter 在 DRACO benchmark 上把这事坐实了：Opus×3 + Opus judge 比 Opus 单跑高 **+6.7pp**，**提升的 3/4 来自"综合"环节本身，1/4 才来自模型多样性**。意味着 sub-agent 即便都是 Claude 家族也能拿大头收益。但 Judge 阶段如果只投票多数赢，就把最值钱的产物（少数派的"我不知道"）扔了。

参考：<https://openrouter.ai/blog/announcements/fusion-beats-frontier/>

## 接活：用户给的输入

用户通常给以下任意一种，足够明确就直接开始：

1. **一个开放问题**：「X 和 Y 哪个更适合 Z」/「X 选型」/「评审 X 方案」
2. **一个研究对象**：「研究下 X」/「全面看一下 X」
3. **一个隐性研究需求**：「帮我做 X 决定」（背后是需要先调研）

如果问题太窄（"修这个 bug"），停手，告诉用户这不适合 Fusion，用单 Opus 跑更划算。

## 班规总纲

- **拆角度异质 > 同质**。三个都拍"成本"等于没拆。如果实在想不出三个互补角度，**也好过单跑**——但写综合时明说"角度同质，多样性贡献弱"。
- **同条消息里发 3 个 Agent tool 调用**。串行 spawn 就是花三倍时间装样子。
- **每个 sub-agent prompt 自包含**。它看不到主对话，要的 context 一并给。
- **每个 sub-agent 都加硬约束**：「不要凭记忆瞎编，查不到就说"未找到"」、「输出 ≤ 500 字」、「不要给"看情况"的废话结论」、「必须加载 web-access skill」（如需联网）。
- **Judge 阶段保留少数派**。某个 sub-agent 老实说"查不到 / 无法验证"——这条**不能被另两个 agent 的笃定数字淹没**。这是 sub-agent 模式最值钱的产物。
- **综合输出敢下判断**。"看情况" / "需要更多信息" 是这个 skill 的最大失败模式。
- **不要把 Judge 偷偷做成 Vote**。Judge 的工作是对比、找空白、调和张力，不是数票。

## 第一步：拆角度（异质 > 同质）

针对用户问题，拆 3 个**互补**角度。常见模板：

| 任务类型 | 推荐角度 |
|---|---|
| 技术选型 | 任务质量 / 成本 / 实操集成 |
| 架构评审 | 性能 / 可维护性 / 演进风险 |
| 方案对比 | 优势面 / 劣势面 / 落地约束 |
| 调研类 | 一手来源 / 社区实践 / 已知陷阱 |
| 决策类 | 短期收益 / 长期影响 / 退出成本 |

## 第二步：并行 panel

```
Agent A (Explore):         角度 1（偏调研）
Agent B (Explore):         角度 2（偏调研）
Agent C (general-purpose): 角度 3（偏实操 / 需要更深的工具理解）
```

**每个 sub-agent prompt 必须包含**：

1. 明确的研究目标 + 完整背景（self-contained）
2. 硬约束：不编、查不到就说不到、≤ 500 字、敢下判断
3. 必须加载 `web-access` skill（如需一手来源）
4. 输出结构提示（建议小标题 + bullet）

## 第三步：Judge 阶段

三 agent 全部回来后，按这个清单交叉评审：

| 维度 | 怎么做 |
|------|--------|
| **共识** | 三家都点到的核心结论 → 这是可信的基线 |
| **分歧 / 张力** | 各家结论差异 → 标 ⚠️ 待核实项 |
| **关键缺口** | 谁老实说"查不到 / 无法验证" → **这条不能被淹没** |
| **独特观点** | 某 agent 单独发现的硬事实 / 反直觉点 |
| **潜在错误** | 凭印象写的数据 / 未引用一手来源的判断 |

## 第四步：综合输出

按这个顺序：

1. 一句话**敢下判断**的结论
2. 结构化对照表（决策维度 + 推荐）
3. 老实标注待核实项 + 它们对结论的影响
4. 可立即落地的下一步
5. （可选但建议）**元观察**：这次得到了什么单跑拿不到的东西

## 第五步：落 Obsidian 知识卡（默认开）

调研一散就废了。综合输出**完成后**，主 agent 额外**写一张 Obsidian 卡片**到用户的 vault，让今天的调研三个月后还能搜得到。

**默认 vault 路径**：`~/Documents/Obsidian/三省研究/`（用户可在主对话里改、或软链接到真 vault；不存在会自动建）。
**文件名**：`<YYYY-MM-DD>-<slug>.md`（slug 从 topic 取，中文按拼音可选，留 8-12 字）。

**卡片模板**（严格按这个结构生成，留好 `[[wikilink]]` 占位让用户在 Obsidian 里手连）：

```markdown
---
type: research
date: {YYYY-MM-DD}
topic: {一句话主题}
tags: [{领域}, {方法}, 三省调研]
sources:
  - {一手 URL 1}
  - {一手 URL 2}
sub_agents:
  - {Agent A 角度}
  - {Agent B 角度}
  - {Agent C 角度}
---

# {主题}

> 一句话判断：{综合输出的那句话}

## 共识
- {三家都点到的核心结论}

## 分歧 ⚠️
- {差异 + 待核实项}

## 缺口（少数派的"我不知道"）
- {谁说了"查不到/无法验证"——这条不能被淹没}

## 独特发现
- {某 agent 单独发现的硬事实 / 反直觉点}

## 下一步
- [ ] {可立即落地的动作 1}
- [ ] {可立即落地的动作 2}

## 元观察
{这次得到了什么单跑拿不到的东西}

## 相关
[[{相关概念 1}]] [[{相关概念 2}]]
```

**硬约束**：
- frontmatter 字段必须齐全（type/date/topic/tags/sources/sub_agents）——Obsidian Dataview 靠这些
- sources 只放**真的查过的一手 URL**，没查过就留空数组 `sources: []`，**不要为了好看编 URL**（同班规"少数派的我不知道"原则）
- `[[相关]]` 占位用方括号，让用户自己在 vault 里连——自动猜的双链质量差，反而污染图谱
- 文件已存在就在文件名后加 `-v2` 别覆盖（同 topic 多次研究是常态）

**告诉用户卡片在哪**：综合输出末尾加一行：
> 📝 已落 Obsidian 知识卡：`<vault path>/<filename>.md`（在 Obsidian 里搜 `topic` 或 tag 找到它）

## 已知陷阱

- ❌ Sub-agent 拿到主对话的隐式上下文 → spawn 时务必给完整自包含 prompt
- ❌ 串行 spawn（三次单独消息）→ 总耗时变三倍，并行收益归零
- ❌ Judge 阶段简单"投票多数赢" → 丢掉少数派的不确定结论
- ❌ 三个 sub-agent 角度同质（都是"成本"）→ 多样性贡献为零
- ❌ Sub-agent prompt 用"搜索"动词 → 把它锚定到 WebSearch，对反爬站点失效（参考 web-access skill 的论述）
- ❌ 综合输出"看情况" → 等于没综合
- ❌ 用户明显是"实时迭代"场景却强上 Fusion → 用户在等，1-2 分钟 spawn 时间会让他离开
- ❌ Obsidian 卡片硬编"相关 [[X]]"自动双链 → 自动猜的链接质量差污染图谱，留空让用户手连
- ❌ Obsidian 卡片 sources 凑数填假 URL → 同班规"少数派的我不知道"原则，没查过的就留空数组

## 实测案例

完整案例见 [`examples/openrouter-fusion-research.md`](./examples/openrouter-fusion-research.md)——会话里现场跑过一次"OpenRouter Fusion API 在 Claude Code 工作流里何时值得用"，Agent B 老实说"OpenRouter API 返回 Fusion 价格 -1，无法估算"——这条被保留进最终结论，验证了"少数派的'我不知道'是最贵的信号"。

## 一句话出师证书

> Fusion 不是把同一个问题问三遍，是从三个互补视角各看一眼，**然后保留少数派的"我不知道"**。如果你的综合输出是"看情况"，你没在做 Fusion，你只是浪费了三倍 token。

---

发现日期：2026-06-16 · 打磨日期：2026-06-17（按鲁班 Skill v1.0 思路）