# KDNA 元认知

> [English](./meta-cognition.md) · 参见：[评估框架](./evaluation.zh.md)

Agent 应该如何思考"使用 KDNA"这件事——何时用、何时不用、如何处理冲突、如何组合领域。

这是判断层自身的判断层。

## 1. 第一个问题：该不该用 KDNA？

加载任何 KDNA 之前，Agent 应该自问：**"领域判断会改变这里的推理路径，还是只是增加开销？"**

### 应该用 KDNA

| 条件 | 例子 |
|---|---|
| 任务需要诊断，而非仅检索信息 | "这个销售页为什么转化率低？" |
| 领域有非显而易见的判断模式 | 区分价格异议和确定性缺失 |
| 用户的问题框架可能包含领域特定误解 | "员工不执行 → 积极性问题" |
| 输出质量依赖术语精确性 | 法律、医疗、安全领域 |
| Agent 不加载 KDNA 就只能给泛泛的常识回答 | "让老人更积极参与" ← 没有诊断障碍 |

### 不该用 KDNA

| 条件 | 例子 |
|---|---|
| 纯机械任务 | 格式化 JSON、提取邮箱、翻译文本 |
| 领域判断对任何正常人都显而易见 | "2+2 等于几？" |
| 时间敏感的实时操作 | 数据处理流水线 |
| 加载 KDNA 不会改变推理路径 | 公理太模糊，有无 KDNA 回答一样 |
| 用户明确要求通用而非专业回答 | "给我标准教科书答案" |

### KDNA 谦逊原则

> **KDNA 塑造判断。它不替代事实、不凌驾用户意图、不弥补信息缺失。**

如果 KDNA 公理与用户提供的具体证据冲突，证据优先。如果用户明确拒绝 KDNA 的判断框架，尊重用户的选择。KDNA 是透镜，不是教条。

## 2. 单领域 vs 多领域

### 一个领域够用

大多数任务只需要一个主导领域。Agent 应该：
1. 从用户目标中识别首要领域。
2. 加载该领域的 Core + Patterns。
3. 仅在任务触发加载条件时才加载可选文件。
4. 在该领域的框架内作答。

### 何时加载多个领域

- 用户任务横跨两个不同判断领域（如"审查这段销售文案"同时涉及销售和写作）
- 一个领域提供主透镜，另一个领域提供约束
- 多个领域处理同一问题的不同层次

### 组合规则

1. **一个主导，其余辅助。** 选一个主领域。其他领域提供约束、边界或校验——而非竞争性答案。
2. **暴露冲突，不要揉合。** 如果领域 A 说"价格异议是确定性缺失"，领域 B 说"价格异议是价值表达失败"，告诉用户："领域 A 将此解读为确定性问题。领域 B 视为沟通质量问题。哪种视角在这里更适用？"
3. **不要取平均。** 把两个领域的立场混合成中间路线答案会产生一摊浆糊。选一个框架，用另一个做质量检查。
4. **检查术语重叠。** 如果两个领域对同一术语有不同定义，在输出中选择一个定义，并标注歧义。

## 3. 冲突仲裁

当两个 KDNA 领域给出矛盾指导时：

### 裁决顺序

1. **用户意图优先于领域偏好。** 用户明确选择某个框架时，采用它。
2. **精确领域优先于宽泛领域。** 为具体问题构建的领域优于仅略有关联的领域。
3. **证据优先于公理。** 用户提供的事实与领域公理矛盾时，事实胜出。
4. **边界声明生效。** 如果领域 A 明确说"不涵盖 X"，而任务恰是关于 X，领域 A 自行出局。

### 何时拒绝 KDNA 指导

- 领域公理被当前案例中具体、可验证的证据所推翻。
- 领域术语反而让用户困惑。
- 领域的自查项无法在当前任务中被满足。
- 领域标记为 `deprecated` 或 `draft` 且错误判断的风险较高。

## 4. 领域选择启发法

### 按用户语言

- 如果用户用中文提问且该领域存在中文 KDNA，优先加载中文版而非英文版。
- 如果只有英文 KDNA 但用户是中文使用者，加载英文 KDNA 但在输出中翻译推理过程。

### 按任务类型

| 任务类型 | 领域选择优先级 |
|---|---|
| 诊断/审查/批评 | 加载公理定义诊断框架的领域 |
| 创作/生成 | 加载框架定义创作结构的领域 |
| 决策/选择 | 加载立场定义评估标准的领域 |
| 学习/成长 | 加载 Evolution 模型定义成长路径的领域 |

### 按领域成熟度

多个领域匹配时，优先选：
1. `stable` — 生产可用，质量已知
2. `experimental` — 可用但仍在演进
3. `draft` — 仅在无更好选择时使用，并提醒用户
4. `deprecated` — 仅在用户明确要求时使用

## 5. KDNA 加载边界

### 不为子任务加载 KDNA

用户问销售问题，Agent 需要查一个定义——查定义不需要 KDNA。只有主判断任务需要。

### 不"以防万一"预加载领域

加载未使用的 KDNA 浪费上下文。等到任务需要领域判断时再加载相关领域。

### 不为 Agent 内部操作加载 KDNA

工具选择、代码执行、文件 I/O——这些是机械操作。KDNA 用于面向用户的判断，不是 Agent 的管道。

## 6. 当 KDNA 反而让事情更糟

KDNA 在以下情况下可能降低输出质量：

- **过拟合。** Agent 强行把领域框架套在不匹配的情境上。例如：将"价格异议是确定性缺失"应用于真的买不起的客户。
- **术语僵化。** Agent 坚持使用用户不理解的领域术语。
- **虚假诊断。** Agent "检测"到一个不存在的误解，因为领域的误解列表过于激进。
- **过早闭合。** Agent 一旦找到领域模式匹配就停止思考，忽略了案例的独特性。

### 元自查

在最终确定任何 KDNA 塑造的回答之前，Agent 应该问：

1. "如果把所有领域特定术语去掉，这个回答还有意义吗？"
2. "是我在把情境塞进 KDNA，还是用 KDNA 适配情境？"
3. "有没有一个更简单、正确的回答，根本不需要这个领域？"

如果（3）的答案是"有"，选更简单的回答。
