# KDNA：面向 AI Agent 领域判断的开放协议

*让专家判断变得显性、可移植、可验证、可组合、可复用*

**白皮书 v1.2 — 2026 年 5 月**   
**网站：** https://aikdna.com  
**GitHub：** https://github.com/aikdna/kdna

---

## 摘要

AI Agent 正在变得足够强大：它们可以理解语言、生成内容、调用工具、检索知识、操作软件，并执行多步骤任务。随着这种能力增长，一个更深层的问题变得越来越重要：不仅是 agent 能做什么，而是它应该如何判断什么值得做、什么应该被拒绝、哪些风险真正重要，以及在一个具体领域中，什么才算把事情做对。

今天，领域判断已经存在。它存在于专家习惯、团队惯例、提示词、风格指南、评分标准、检查清单、检索文档、工作流规则、测试、微调行为，以及工具特定策略之中。这些机制仍然有价值，也应该继续被使用。

但领域判断通常分散在这些机制里：一部分写在提示词中，一部分藏在文档里，一部分嵌入工作流，一部分内化在模型中，还有一部分只保留在资深实践者的大脑里。当 agent 出错时，我们很难检查到底是哪条判断规则缺失了、过时了、相互矛盾了，或者被忽略了。

KDNA 是一个用于表示领域判断的开放协议。它把塑造专家判断的原则、概念边界、误解模式、场景信号、推理链、风险边界和自检问题编码出来，使 AI Agent 可以加载，人类可以检查，工具可以验证。

KDNA 并不声称判断从未存在于 AI 系统中。它的贡献在于：判断现在需要拥有自己的可移植、可验证表示形式——一种可以被创作、审阅、验证、版本化、组合、分发，并随时间改进的领域包。

KDNA 的命名来自 **Knowledge DNA**。它并不把知识理解为一组静态内容，而是理解为一种可以被表达、继承和进化的判断结构。在生物系统中，DNA 不是生命体本身，也不是某个具体行为；它是一套底层编码，使稳定特征能够被保存、复制、表达，并在演化中发生变化。KDNA 借用这一隐喻：一个领域中最有价值的部分，往往不是孤立知识，而是专家反复使用的判断结构——他们如何划分概念、识别情境、权衡风险、坚持边界、形成审美、排除误解，并判断什么才算完成得好。KDNA 的目标，是让这种隐性的领域判断拥有一种可读、可验证、可组合、可传承的开放表示形式。

KDNA 规范是开放的，参考工具链以 Apache 2.0 发布，早期开放访问领域的公共注册表已经可用。KDNA 不替代提示词、知识库、Skills、MCP、工具、检索、评估、工作流或微调。它为这些机制提供一个更清晰的判断参照。

---

## 0. AI Agent 能力栈中缺失的一层

AI Agent 已经拥有几个主要能力层：

| 层级 | 它给 agent 带来什么 | 示例 |
|---|---|---|
| **模型层** | 通用语言、推理和生成能力 | LLM、多模态模型 |
| **知识层** | 访问外部事实、上下文、文档和记忆 | RAG、向量数据库、搜索、记忆 |
| **工具层** | 对外部系统采取行动的能力 | API、MCP、function calling、computer use |
| **流程层** | 组织任务和执行顺序的过程 | agent 框架、Skills、工作流、自动化 |
| **判断层** | 针对分类、取舍、风险、边界和输出质量的领域特定标准 | KDNA domains 和 clusters |

前四层让 agent 能够回答问题、检索信息、调用系统并执行任务。但在 agent 回答或行动之后，还有另一组问题仍然存在：

- 这个回答好吗？
- 这个决策可靠吗？
- 它使用了正确的标准吗？
- 它是否正确分类了当前任务？
- 它是否考虑了相关风险？
- 它是否越过了本应阻止它的边界？
- 它是否满足了这个领域自身关于“做对”的标准？

这些问题可以部分由模型回答。强大的 LLM 的确具备判断能力。KDNA 并不否认这一点。问题不是 LLM 会不会判断，而是它在使用谁的判断；这个判断是否可见；它是否可以被测试、版本化、组合和复用。

模型包含隐式判断。工作流可能包含嵌入式判断。Skill 可能包含程序性判断。提示词可能包含任务级判断。但当判断藏在权重里、散落在提示词中，或埋在执行流程里时，它就无法作为独立资产被治理。

KDNA 给这个缺失的层一个名字和一种结构：判断层。

---

## 1. 为什么领域判断需要一种格式

### 1.1 从能力到判断

AI Agent 正在从被动回答生成走向主动工作。它们可以写代码、编辑文档、调用 API、操作工具、总结研究并执行工作流。这种变化改变了核心问题。

在早期 AI 使用中，主要问题是：*模型能否生成一个有用答案？* 在 agentic AI 中，问题变成：*agent 如何决定什么值得做、什么应该避免、什么才算做对？*

一个 coding agent 也许能够修改文件、检查 diff、运行测试并调用 linter。但更难的问题是领域特定的：这个改动可以安全合入吗？它解决了根因，还是只是压住了表面症状？这条评论是有意义的 blocker，还是 review 噪音？

一个会议助手也许能够转录、总结并提取 action items。但更难的问题是判断性的：这次对话真的产生了决定，还是仍然只是讨论？责任被明确分配了吗，还是只是被暗示了？

一个写作助手也许能够生成流畅文本、修正语法并建议更有力的措辞。但更难的问题是编辑判断：问题出在语言、结构、论证、证据、读者框架，还是底层观点本身？

随着 agent 能力增长，判断不是变得不重要，而是变得更重要。

### 1.2 判断已经存在，但它是碎片化的

领域判断并不缺席。专家已经在使用它。团队已经在依赖它。AI 系统也已经通过许多既有机制近似了它的一部分：system prompts、风格指南、代码审查标准、合规政策、内部 playbook、检查清单、评估套件、微调行为、工具特定验证器和人工审查。

这些机制有用。KDNA 不反对它们。

问题在于，判断散落在它们之中。一条原则可能存在于提示词里。一个概念边界可能写在风格指南里。一种失败模式可能只有资深 reviewer 知道。一项检查可能被实现成工具逻辑。一种偏好的推理模式可能从未被写下来。当 agent 出错时，很难检查是哪条规则缺失、过时、冲突或被忽略。

这不只是一个提示词问题。这是一个表示问题。

### 1.3 表示问题

如果领域判断只存在于提示词中，它往往脆弱且任务绑定。一个好提示词可能在一次会话中有效，但很难被验证、版本化、复用，并跨系统组合。

如果判断只存在于文档中，agent 也许能检索到文档，却不一定能稳定应用其中的关键区分。文档可以包含原则，但文档本身不会区分哪些是公理、哪些是案例，哪些是风险边界、哪些是背景解释，哪些是必需自检、哪些只是可选建议。

如果判断只存在于模型权重中，它可能强大，但不透明。行为很难被检查，很难被精确更新，很难归因到某条具体原则，也很难跨模型迁移。

如果判断只存在于工作流和 Skills 里，它就会和特定执行路径绑定。它可能很好地指导某个流程，但很难独立测试、组合、授权或复用。

如果判断只存在于人的脑子里，它就容易流失。专家离开时，判断也随之离开。团队扩大时，判断变得不一致。

KDNA 通过把领域判断视为一等工件来解决这个问题：它是一种可以被写下、审阅、验证、版本化、分发、加载、组合和改进的东西。

### 1.4 KDNA 增加了什么

KDNA 并不声称现有方法是错误的。它主张的是：随着 agent 变得更主动，这些方法会受益于一种可移植的判断表示。

提示词定义当前任务。知识库提供信息。Skills 封装过程。工作流组织步骤。MCP 连接工具和上下文。微调塑造模型行为。评估衡量表现。KDNA 表示领域判断，指导 agent 如何使用这些能力。

KDNA 在精神上接近规则文件、评分标准、风格指南和结构化提示词。它的贡献并不是“原则从未被写下过”。它的贡献是：KDNA 为领域判断定义了一种通用开放的包格式、验证规则、加载语义、组合模型和质量治理路径。

---

## 2. 起源：从一本书到一种判断协议

KDNA 的早期原型，来自一个非常具体的创作实践。张零作为《极简沟通》的作者，最初并不是要设计一个协议，而是试图把这本书背后的底层逻辑结构化：哪些原则是真正不可动摇的，哪些概念边界不能被混淆，哪些表达看似合理却会把沟通带向误区，哪些问题必须在输出前自检。

在这个过程中，一个更大的问题逐渐显现出来：一本书可以记录知识，课程可以传授方法，提示词可以描述任务，但一个专家长期积累下来的判断标准——他如何分类问题、如何识别误解、如何保留边界、如何权衡风险、如何判断什么才算做对——并没有一个稳定的承载形式。

《极简沟通》的结构化过程让这个问题变得具体。目标不再只是让 AI “知道”这本书讲了什么，而是让 AI 能够加载这套判断结构，在面对具体沟通、表达和内容问题时，尽可能按照这套标准进行区分、取舍和自检。

KDNA 正是在这个过程中形成的。它从一个作者对自身知识体系的结构化，扩展为一个更通用的问题：如何把专家、团队和组织中原本隐性的领域判断，编码成 AI Agent 可以加载、人类可以检查、工具可以验证、多个系统可以组合的开放格式。

因此，KDNA 不是从抽象的协议设计开始的。它来自一个真实的判断提取过程，并逐渐被推广为一种开放的判断协议。

---

## 3. 判断由什么构成

### 2.1 判断的定义

判断，是一个领域特定过程：它分类当前情境，应用价值和边界，权衡风险，选择响应框架，并验证输出是否满足该领域的标准。

更简单地说：

> 判断就是知道当前属于什么情况，什么最重要，什么不能做，以及什么才算一个好的回应。

判断不是单条规则。它是原则、区分、价值、风险、案例、信号和自检之间的结构化互动。

### 2.2 领域判断的 13 个要素

KDNA domain 的设计目标，是编码可重复出现的判断模式。下面这些要素描述了领域判断通常由什么构成，以及 KDNA 在哪里承载它们。

| 判断要素 | 它回答什么问题 | KDNA 承载位置 |
|---|---|---|
| **世界观** | 这个领域默认世界如何运作 | `KDNA_Core.json` |
| **价值观** | 什么比什么更重要 | `KDNA_Core.json`, `KDNA_Patterns.json` |
| **目的** | 这套判断服务于什么 | `meta`, `KDNA_Core.json` |
| **角色** | 谁在判断，承担什么责任 | `KDNA_Core.json` |
| **知识假设** | 哪些背景知识会影响判断 | `KDNA_Core.json`, `KDNA_Cases.json` |
| **本体** | 哪些区分不能被混淆 | `KDNA_Core.json` |
| **分类** | 当前属于哪类情况 | `KDNA_Scenarios.json` |
| **品味 / 审美** | 什么算好、差、优雅、粗糙、可信或嘈杂 | `KDNA_Patterns.json`, `KDNA_Cases.json` |
| **边界** | 哪些事即使看似有效也不能做 | `KDNA_Patterns.json`, `KDNA_Core.json` |
| **风险模型** | 哪些错误代价最大 | `KDNA_Patterns.json`, `KDNA_Scenarios.json` |
| **上下文信号** | 何时应该激活这套判断 | `KDNA_Scenarios.json` |
| **经验** | 过去案例、失败模式和反例 | `KDNA_Cases.json`, `KDNA_Patterns.json` |
| **评估** | 如何测试判断质量 | `evals/`, `KDNA_Evolution.json` |

这就是为什么 KDNA 不只是提示词模板。提示词通常给出一条任务指令。KDNA domain 建模的是一类任务背后反复出现的判断结构。

### 2.3 KDNA 能形式化什么，不能形式化什么

KDNA 不声称能够穷尽人类判断。它提供一种结构，用来逼近可重复出现的判断模式：原则、区分、信号、边界、风险、案例和评估。

有些判断仍然是隐性的、情境性的、感知性的，并且最终仍由人类负责。KDNA 最适合那些具备重复标准、稳定区分、已知失败模式、明确风险边界和可审查输出的领域。

KDNA 不应被用来假装所有判断都能被还原为规则。它应该被用来保存和应用那些可重复、可传授、可审阅、可测试的判断部分。

---

## 4. KDNA 是什么

### 3.1 定义

KDNA 是一个开放的、基于文件的协议，用来把领域判断编码为结构化、可验证的包。一个 KDNA domain 是一个目录，包含少量标准 JSON 文件。这些文件共同描述在某个特定领域中指导判断的原则、概念、边界、误解、场景、推理模式、风险模型、示例和自检。

一个 domain 并不试图存储所有信息。它也不试图替代专家。它捕捉的是专家在判断时反复使用的结构：

- 当前属于哪类情况；
- 什么最重要；
- 什么应该被拒绝；
- 哪些区分必须被保留；
- 哪些错误经常发生；
- 哪些信号应该改变策略；
- 应该遵循哪条推理路径；
- 哪些风险应该阻断或警告；
- 在输出最终结果前必须检查什么。

KDNA 的设计是紧凑的。一个有用的 domain 可能只包含两个文件。更丰富的 domain 最多包含六个文件。目标不是体量，而是清晰性、特异性、可验证性和可复用性。

### 3.2 KDNA 编码什么

**公理（Axioms）** —— 不可侵犯的判断锚点。不是励志句。它们是 agent 推理时必须保持成立的原则。示例：*一个 bug fix 应该处理根因，而不是只压制可见症状。*

**本体（Ontology）** —— 核心概念及其边界。一个概念是什么、不是什么，以及哪些区分不能被混淆。示例：*除非责任、承诺和下一步行动被充分明确，否则一次讨论还不是一个决定。*

**框架（Frameworks）** —— 带有触发条件、步骤和预期输出的决策程序。

**立场（Stances）** —— 默认倾向。领域在具体任务开始前，倾向于偏好或拒绝什么。示例：*优先选择具体张力，而不是装饰性形容词。*

**判断角色（Judgment role）** —— agent 在应用该领域时应承担的角色。示例：*作为结构性写作诊断者，而不是语言润色者。*

**术语（Terminology）** —— 带有操作性定义的标准术语，以及带有具体替代表达的禁止术语。禁止术语不是禁忌。它们是信号，提示某个词可能把 agent 推向错误分类或错误心智模型。

**误解（Misunderstandings）** —— 常见错误理解，以及对应的正确理解和必须保留的关键区分。它们帮助 agent 检测输出是否正在滑入已知错误模式。

**审美偏好（Aesthetic preferences）** —— 这个领域认为什么是好、差、优雅、嘈杂、操控性、可信、泛化或精确。品味不被当成神秘感，而是通过偏好、示例、反例和自检来编码。

**边界（Boundaries）** —— 哪些事情即使看起来有效，也不能做。

**风险模型（Risk model）** —— 哪些错误代价最高，什么时候应该警告，什么时候必须阻止。

**自检（Self-checks）** —— agent 在完成输出前必须回答的 yes/no 问题。它们必须可验证，而不是含糊的。示例：*这个建议是否指出了取舍，而不是只呈现好处？*

**场景信号（Scenario signals）** —— 可观察的输入模式，会改变 agent 的回应方式。

**推理链（Reasoning chains）** —— 从前提到结论再到实践后果的结构化路径，包括取舍、证据要求和不确定性处理。

**能力阶段和演化（Capability stages and evolution）** —— 领域如何随时间改进的定义，包括已改变的判断、废弃的假设、新的失败模式和评估结果。

### 3.3 六个标准文件

一个 KDNA domain 是一个小写 snake_case 命名的目录，或等价的 scoped package 名称。一个完整 domain 最多包含六个标准文件：

| 文件 | 编码内容 | 是否必需 |
|---|---|:---:|
| `KDNA_Core.json` | 公理、本体、框架、核心结构、立场、世界观、判断角色、价值排序 | 是 |
| `KDNA_Patterns.json` | 术语、误解、自检、边界、风险模型、审美偏好、反例 | 是 |
| `KDNA_Scenarios.json` | 场景信号、分类规则、风险等级、预期判断变化 | 否 |
| `KDNA_Cases.json` | 展示判断如何发生的具体案例、好/坏回应、判断路径 | 否 |
| `KDNA_Reasoning.json` | 推理链、取舍、冲突解决、证据要求、不确定性处理 | 否 |
| `KDNA_Evolution.json` | 能力阶段、度量、判断变化、已知限制、评估历史 | 否 |

最小有效 domain 包含 `KDNA_Core.json` 和 `KDNA_Patterns.json`。每个文件都包含必需的 `meta` 对象，其中包括 `version`、`domain`、`created`、`purpose` 和 `load_condition`。标准文件会根据公开 JSON Schema 进行验证。

canonical 形式是一个 JSON 文件目录——源码优先、透明、可版本控制。为了分发，工具链可以把 domain 打包成 `.kdna` 容器。

### 3.4 为什么文件格式重要

与模型、agent 框架或平台相比，文件格式看起来可能很朴素。但格式重要，因为它让事物变得可移植。

文档之所以可移植，是因为有文档格式。包之所以可复用，是因为生态中有包格式。API 之所以能互操作，是因为有接口描述。配置之所以可管理，是因为行为可以从代码中分离出来。

KDNA 把这个逻辑应用到领域判断上。就像配置文件把环境特定行为从应用代码中分离出来，KDNA 把领域判断从临时提示词、agent 实现和平台特定工作流中分离出来。它给判断一个可以安放的地方。

### 3.5 KDNA 不是什么

| KDNA 不是 | 原因 |
|---|---|
| **不是提示词库** | 提示词是任务级的。KDNA 是领域级的、版本化的，并为验证和组合而结构化。 |
| **不是知识库** | 知识库存储信息。KDNA 编码判断约束、概念区分、风险边界和自检。 |
| **不是工作流引擎** | 工作流定义步骤。KDNA 定义跨步骤的判断。 |
| **不是 Skill 包** | Skills 编码可重复过程。KDNA 编码可重复判断标准。Skills 执行，KDNA 判断。 |
| **不是微调模型** | 微调把行为内化进模型权重。KDNA 保持选定判断原则的显性和可审计。 |
| **不是 agent 框架** | KDNA 是协议和包格式，不是 agent。任何框架都可以实现加载。 |
| **不保证正确性** | KDNA 提供显性参照。质量取决于被编码的判断、评估证据和负责任的使用。 |

---

## 5. KDNA 如何工作

### 4.1 验证

KDNA domains 可以在多个层级被验证：

- **结构 lint** —— 必需文件存在、字段已填写、ID 唯一、自检可用 yes/no 回答、跨文件引用有效，并标记含糊公理或不可执行自检。
- **Schema 验证** —— 字段符合 JSON Schema 类型，数组包含必需项，跨文件引用一致。
- **判断验证** —— governance 字段存在，边界已声明，风险模型存在，自检具体。
- **质量评估** —— 基于标注测试用例进行 benchmark 评分，衡量 agent 输出是否遵循领域原则并避免已知失败模式。

前两个层级高度可自动化。第三个层级部分可自动化。第四个层级取决于评估设计、benchmark 质量和人工审查。

Schema 合规不等于质量。一个 domain 可以结构有效，但判断很弱。KDNA 区分结构有效性和判断质量。

### 4.2 加载

当 agent 加载一个 KDNA domain 时，loader 会读取并验证 domain 文件，使用标准模板把它们渲染成结构化上下文块，并在运行时提供给 agent。

渲染后的上下文保留 domain 结构，作为彼此区分的命名段落：

- domain 目的；
- 判断角色；
- 公理；
- 本体；
- 框架；
- 术语；
- 误解；
- 风险边界；
- 自检；
- 相关场景信号。

多个 domains 可以同时加载。每个 domain 都贡献一个独立判断参照。

### 4.3 Verify 与 Evals

一个 domain 不应仅仅因为它是有效 JSON 就被信任。KDNA 鼓励 domain 包含评估用例，用来测试预期判断是否真的出现在 agent 行为中。

一个标准评估用例可以包含：

```json
{
  "id": "eval-001",
  "domain": "@aikdna/writing",
  "input": "Help me improve this post.",
  "expected_classification": "structural_writing_diagnosis",
  "expected_axioms": ["writing_ax_structural_problem"],
  "expected_misunderstandings_avoided": ["more_detail_equals_more_evidence"],
  "expected_banned_terms_avoided": ["polish the language"],
  "output_rubric": "The output should diagnose the structural writing problem before suggesting language changes.",
  "pass": true,
  "evidence": "The agent explicitly classified the issue as structural and avoided direct language polishing."
}
```

评估结果可以进入质量徽章、注册表元数据、benchmark 报告和 Compare Mode 证据。

### 4.4 Judgment Trace 与 Judgment Delta

KDNA 应该让判断可检查，而不只是隐性影响输出。

**Judgment Trace** 记录一次 KDNA 引导回应中发生了什么：

- 哪些 domains 被加载；
- 哪些场景信号被检测到；
- 哪些公理被触发；
- 哪些误解被避免；
- 哪些禁止术语或风险模式被检测到；
- 哪些自检通过或失败；
- domains 之间出现了哪些冲突；
- 哪条组合策略解决或暴露了冲突。

**Judgment Delta** 比较有无 KDNA 时的推理路径差异：

```text
同一模型。同一输入。

没有 KDNA：
  把请求当作语言润色。

加载 writing.kdna：
  分类：结构性写作诊断
  触发公理：写作问题通常是结构问题，而不是语言层问题
  避免误解：更多细节等于更好的证据
  避免术语：polish the language
  自检：5/5 通过
```

Judgment Delta 很重要，因为 KDNA 应该通过可观察的判断变化被评估，而不是通过宣称被评估。

---

## 6. 组合、集群与判断系统

### 5.1 为什么组合重要

真实判断往往是多领域的。一个任务可能同时涉及技术正确性、战略判断、受众理解、法律谨慎、品牌声音、安全边界和产品取舍。

如果把这些标准合并进一个巨大 prompt，结果会变得脆弱。来源会被抹平。冲突会消失。token 预算会爆炸。agent 无法解释哪个 domain 塑造了哪部分判断。

KDNA 允许 domains 保持彼此独立，同时被共同加载。目标不是拼接指令，而是对独立判断参照进行保留来源的组合。

### 5.2 三个层级

KDNA 组合可以理解为三个层级：

| 层级 | 定义 | 示例 |
|---|---|---|
| **判断原子（Judgment Atom）** | 单个 KDNA domain | `writing`, `code_review`, `agent_safety` |
| **判断集群（Judgment Cluster）** | 一组带有组合策略的 domains | `content_creation_cluster`, `product_launch_cluster` |
| **判断系统（Judgment System）** | 带有治理机制的组织级判断架构 | 企业产品、品牌、合规和安全体系 |

Cluster 不是 domains 文件夹。它是一套组合策略：加载什么、何时加载、如何保留来源归属、如何暴露冲突，以及如何评估组合后的判断。

### 5.3 组合策略

KDNA clusters 可以支持多种组合策略：

- **固定组合（Fixed）** —— 始终加载一组定义好的 domains。
- **基于信号（Signal-based）** —— 根据输入中的触发信号加载 domains。
- **分阶段（Staged）** —— 在工作流的不同阶段加载不同 domains。
- **覆盖层（Overlay）** —— 使用一个主 domain，并叠加始终约束它的治理 domains。
- **用户确认（User-confirmed）** —— 推荐 domains，并由人类批准或调整判断栈。

### 5.4 Cluster 类型

KDNA clusters 可以服务于不同目的：

- **横向集群** 组合某种广泛能力所需的 domains，例如内容创作。
- **垂直集群** 支撑某个业务流程，例如产品发布判断。
- **治理集群** 在其他 domains 之上提供安全、合规、法律、隐私或品牌边界。

### 5.5 冲突暴露

Domain 冲突不是失败。它是真实判断的一部分。

一个品牌 domain 可能鼓励情绪强度，而一个合规 domain 要求保守措辞。一个增长 domain 可能推动紧迫感，而一个信任 domain 拒绝虚假确定性。一个代码审查 domain 可能偏好严格阻断，而一个产品速度 domain 可能容忍受控风险。

KDNA 的原则是：

> 当 domains 发生冲突时，runtime 应暴露冲突，而不是静默解决；除非组合策略明确规定了优先级。

这是 KDNA 组合与大型 prompt 拼接之间的区别之一。

### 5.6 来源归属与 Judgment Graphs

当多个 domains 被组合时，KDNA 应保留来源归属。被渲染的公理、误解、禁止术语或自检，都应能追溯到其来源 domain。

在更大规模下，domains 会形成判断图谱：

- 一个 domain 可能依赖另一个 domain；
- 一个 domain 可能约束另一个 domain；
- 一个 domain 可能在高风险场景下覆盖另一个 domain；
- 一个 domain 可能为另一个 domain 提供表达标准；
- 一个 domain 可能评估另一个 domain 的输出。

这使 KDNA 不仅适合个人专家 domain，也适合组织级判断系统。

### 5.7 加载配置与 Token 预算

加载过多 domains 可能会稀释判断，而不是改善判断。KDNA clusters 应支持选择性加载：

| 加载配置 | 加载内容 | 目的 |
|---|---|---|
| **Index** | manifest 和触发信号 | Domain 选择 |
| **Compact** | 最高问题、核心公理、风险模型、自检 | 轻量引导 |
| **Scenario** | 相关场景和框架 | 任务特定判断 |
| **Full** | 全部六个标准文件 | 高相关或高风险任务 |

被更好地选择的 KDNA，比更多的 KDNA 更好。

---

## 7. KDNA 的位置

KDNA 最容易通过与既有 agent 组件的关系来理解：

| 组件 | 主要作用 | 它通常不标准化什么 |
|---|---|---|
| **LLM** | 通用推理、语言、生成 | 可检查、可编辑、由领域拥有的判断标准 |
| **提示词** | 定义当前任务或行为 | 作为版本化工件的可复用领域判断 |
| **知识库 / RAG** | 提供信息和参考 | 结构化判断约束、自检和风险边界 |
| **Skills** | 封装可重复过程 | 用于接受或拒绝结果的独立领域原则 |
| **工作流** | 组织执行顺序 | 能在该工作流之外复用的判断 |
| **MCP / API** | 把 agents 连接到工具和数据 | 领域特定评估原则 |
| **微调** | 内化行为模式 | 可检查且可精确编辑的判断规则 |
| **评估套件** | 衡量表现 | 被衡量的可移植判断包 |
| **KDNA** | 表示领域判断 | 它不执行任务，也不替代模型能力 |

KDNA 不是这些组件的竞争者。它是它们的补充。

提示词告诉 agent 现在做什么。Skill 告诉它如何执行一个过程。工作流组织步骤。MCP 把它连接到工具。知识库提供参考材料。微调塑造行为。评估衡量结果。KDNA 为 agent 提供一个结构化领域判断参照，用来决定什么重要、什么要拒绝、在特定领域里什么算好。

工作流可以包含判断，但不能独立治理判断。当判断被嵌入工作流中时，它很难被测试、版本化、组合、授权，或跨 agent 复用。KDNA 把重复出现的判断抽取为一个独立资产层。

---

## 8. 为什么显性领域判断重要

### 7.1 可检查性

当判断藏在提示词、模型行为、工作流或未文档化的专家习惯里时，它很难被检查。KDNA 让判断变得可读。人类可以打开一个 domain 并询问：这些原则正确吗？概念边界清楚吗？自检具体吗？风险边界合适吗？

agent 的输出仍然可能需要审查，但指导它的判断参照不再是不可见的。

### 7.2 可移植性

一个提示词可能在一个工具里有效，在另一个工具里失效。一个团队惯例可能存在于一个部门，却不存在于另一个部门。一个微调行为可能绑定在一个模型上。KDNA 让领域判断可移植：它可以存储在仓库中，被打包成 domain，通过工具安装，被不同 agents 加载，并随时间版本化。

### 7.3 可验证性

非结构化判断很难检查。KDNA 引入多个验证层级：schema 验证、结构 lint、跨文件一致性、governance 检查、自检质量规则、基于 benchmark 的评估、人工审查和版本历史。

这不会让判断自动正确。但它让判断可以被审阅。一个 domain 可以被比较、改进，并基于证据获得质量徽章。

### 7.4 可组合性

真实工作是多领域的。单个任务可能涉及技术准确性、战略判断、受众理解、法律谨慎和品牌声音。如果所有内容都被合并成一个 prompt，结果会变得脆弱。KDNA 允许 domains 保持独立并共同加载，每个 domain 都贡献独立判断参照。

### 7.5 继承性

组织常常低估自己的专业性到底存在于哪里。它存在于资深人员反复作出的判断中：他们首先注意到什么，立即拒绝什么，会考虑哪些取舍，已经学会避免哪些错误。

当这些人离开时，这些判断也大多随之离开。KDNA 不能完整保存一个人的专业能力——没有任何格式可以。但它可以保存重复出现的判断原则、概念边界、失败模式和自检。这已经足以让专家判断更容易被传授、审阅，并被 AI Agent 使用。

### 7.6 治理性

随着 agent 变得更主动，组织需要治理的不仅是工具和数据访问，还包括用来分类情境、做出取舍、阻断风险行动和评估输出的标准。

KDNA 为把判断作为一个显性层进行治理提供路径：它可以被创作、审阅、版本化、评估和审计。

---

## 9. 公共、私有与企业 Domains

KDNA 支持几种使用模式。

### 8.1 开放参考 Domains

开放参考 domains 通过注册表公开共享，并附带明确内容许可。它们是参考实现、学习资源、社区维护的判断包，以及高质量创作范例。

### 8.2 创作者 Domains

一位受尊敬的编辑可以发布一个写作判断 domain。一位资深工程师可以发布一个代码审查 domain。一位产品负责人可以发布一个优先级判断 domain。

这些不是模板。它们是结构化判断包，承载创作者的原则、区分、风险边界和自检。随着注册表和评估系统成熟，高质量 domains 可以积累声誉。

### 8.3 企业私有 Domains

组织持有大量自己很少意识到的判断资产：

- 资深工程师如何审查架构；
- 合规团队如何解释风险；
- 产品团队如何排序取舍；
- 品牌团队如何决定哪些语言能保留信任；
- 客服团队如何分类客户状态；
- 管理层如何区分讨论和决定。

私有 KDNA domains 允许组织把这些专业能力编码成一种格式，使 AI Agent 可以加载，人类可以审阅。这不是自动化专家能力，而是保存、分发和运营专家能力。

### 8.4 企业判断系统

在企业规模下，最有价值的工件可能不是单个 domain，而是一组 domains 构成的 cluster 或 system：

- 产品判断；
- 法律风险；
- 安全审查；
- 品牌声音；
- 客户沟通；
- 定价政策；
- 升级边界；
- 合规标准。

长期企业场景不只是私有提示词库。它是一套内部判断系统：一组受治理的 domains、组合策略、质量徽章、审计轨迹和审查周期。

---

## 10. 质量治理

一个 KDNA domain 不应仅仅因为通过 schema 验证就被视为高质量。质量需要证据。

KDNA 区分几个层级的质量治理：

### 9.1 结构收录

一个 domain 可以在结构上被收录，如果它：

- 通过 schema 验证；
- 具备必需文件；
- 拥有唯一 ID；
- 有 README；
- 声明 license 和作者；
- 没有明显结构错误。

### 9.2 判断收录

一个 domain 应展示判断实质：

- 清晰的 core insight；
- 至少两条有意义的公理；
- 明确的本体或概念边界；
- 至少两个误解或失败模式；
- 明确的边界或风险规则；
- 具体的 yes/no 自检。

### 9.3 评估收录

一个 domain 应包含评估用例。一个最低官方门槛可以要求至少 3 个 evals。更强的 domains 应包含更多。

评估不只测试输出质量，也应测试：

- 分类准确率；
- 公理触发准确率；
- 误解避免率；
- 禁止术语或风险模式避免率；
- 自检通过率；
- 相对 baseline 的 judgment delta。

### 9.4 徽章晋级

质量徽章应基于证据，而不是被手动分配为装饰。

一种可能的徽章路径：

| 徽章 | 证据 |
|---|---|
| `untested` | 结构有效，但没有有意义的 eval set |
| `tested` | 至少 10 个 evals，且结果可复现 |
| `validated` | 至少 30 个 evals，且 benchmark 表现强 |
| `expert_reviewed` | 经合格外部专家审查 |
| `production_ready` | 真实世界使用证据、维护中的版本历史和监控 |

质量治理是必要的，因为一个结构化 domain 仍然可能编码浅薄、过时或有害的判断。

---

## 11. 经济愿景

### 10.1 判断作为可复用资产

互联网让信息变得丰富。AI 让生成变得丰富。但判断仍然稀缺——不是因为判断无法表达，而是因为它通常没有被结构化为可复用资产。

一个 KDNA domain 可以编码一个人、团队或社区如何在某个领域内判断。如果它有用，就可以跨任务、agents、团队和组织被复用。这让领域判断具备了一些知识产权的属性：作者身份、版本、审查、许可、归属、声誉，以及随时间改进的能力。

### 10.2 创作者 Domains

一位受尊敬的编辑可以发布一个写作判断 domain。一位资深工程师可以发布一个代码审查 domain。一位产品负责人可以发布一个优先级判断 domain。一位沟通专家可以发布一个关系诊断 domain。一位安全专家可以发布一个 agent safety domain。

这些不是通用模板。它们是结构化判断包，承载创作者的原则、区分、风险边界、示例和自检。

如果 domains 在真实工作流中证明有用，那么创建经过验证、经过良好审查的 domains 的创作者，可能会在自己的作品体系中获得可累积的价值。

### 10.3 企业私有 Domains

组织的判断资产通常以分散形式存在：review comments、风格指南、decision memos、onboarding documents、升级政策、合规笔记，以及资深人员的习惯。

私有 KDNA domains 允许组织把这些判断资产编码成一种可以被 AI Agent 加载、被人类审阅的格式。

最重要的企业价值可能来自判断连续性：保存并分发那些否则会保持隐性、不一致，或依赖少数资深个人的标准。

### 10.4 长期演化

1. **格式层** —— 领域判断的标准化编码。
2. **验证层** —— 评估用例、benchmark 结果、审查流程、质量徽章。
3. **发现层** —— 注册表、分面浏览、domain 预览、依赖发现。
4. **组合层** —— Clusters、组合策略、判断图谱、冲突暴露。
5. **市场层** —— 授权、归属、收入分成、创作者声誉。
6. **资产层** —— 认知和判断资产成为一种被承认的可复用知识产权类别。

KDNA 目前处在格式层和验证层，并在发现和组合上进行早期工作。我们不把 KDNA 描述为金融工具。

---

## 12. 超越软件 Agent

KDNA 最初最适用于软件 agents：写作助手、coding agents、研究 agents、会议助手、工作流 agents 和领域特定 AI copilots。

但随着 AI 系统变得更加具身化——操作电脑、机器、机器人、车辆、实验室、工厂或物理环境——糟糕判断的代价会升高。

感知、规划、工具和控制系统是必要的，但还不够。具身 agents 还需要明确的判断边界：

- 什么时候不要行动；
- 什么时候请求确认；
- 哪些风险会阻断行动；
- 哪些取舍需要升级给人类；
- 哪些领域标准支配安全执行；
- 哪些输出需要人类审阅。

KDNA 不是机器人控制系统。它不替代感知、规划、安全控制器、仿真、形式化验证或人类监督。它提供的是一个可移植判断参照，供更高层 agents 在决定是否行动、如何行动时使用。

当 AI 从文本生成走向在世界中行动时，显性的判断参照不是变得不重要，而是变得更重要。

---

## 13. 限制与风险

一个严肃协议必须定义自己的边界。

### 12.1 不是所有专业能力都能被完全形式化

有些判断高度隐性，依赖感知、情境、时机、情绪敏感度、具身实践或多年经验。KDNA 最适合那些有重复原则、稳定概念边界、已知失败模式和可审查输出标准的领域。

### 12.2 捕捉判断可能扭曲判断

编码判断可能会过度简化判断。一个写得不好的 domain 可能保存的是专家能力的漫画化版本，而不是专家能力本身。作者必须避免把活的判断还原成僵硬口号。

### 12.3 显性判断可能变得僵化

一个写得不好的 domain 可能过度约束 agent，拒绝有用变化，或保存过时假设。Domains 需要版本化、审查、反馈和演化。

### 12.4 Schema 有效不等于质量

一个 domain 可以通过验证，但仍然很差：原则含糊、区分浅薄、自检无力、缺少边界，或示例糟糕。工具检查结构。质量需要专家审查和真实使用评估。

### 12.5 结构化 Domains 可能制造虚假权威

一个 domain 可能因为结构化而显得权威。KDNA 必须区分结构和权威。质量徽章和注册表信任应基于证据。

### 12.6 上下文限制很重要

加载太多 domains 可能稀释判断，而不是改善判断。Clusters 必须有选择性。被更好选择的 KDNA，比更多 KDNA 更好。

### 12.7 Domains 可能冲突

一个品牌 domain 可能鼓励情绪强度，而一个合规 domain 要求保守措辞。KDNA 应暴露这些冲突，而不是隐藏它们。冲突报告是负责任判断组合的一部分。

### 12.8 KDNA 不替代责任

即使使用 KDNA，人类仍然要对高风险决策负责。KDNA 改善可检查性。它不消除责任。

---

## 14. 当前状态

KDNA 仍处于早期，但若干组件已经存在。

### 13.1 开放协议

- 协议规范：SPEC v1.0-rc。
- 六个标准 domain 文件。
- 用于验证的 JSON Schemas。
- 开放 domains 公共注册表。
- 质量徽章和评估元数据正在形成。

### 13.2 参考工具链

- `@aikdna/kdna-core`：用于加载、验证、lint、渲染和组合 domains 的纯逻辑库。
- `@aikdna/kdna-cli` CLI：命令行工具，支持 setup、validate、verify、install、load、match、compare、diff、pack、unpack、registry、identity 和 cluster 相关工作流。
- Python SDK：程序化集成。
- Swift core package：面向 macOS 和 iOS 客户端的原生 Swift 实现。
- VS Code extension：验证、预览和 domain authoring 支持。
- Agent skills：面向 agent 环境的 loader patterns。

具体版本号应以已发布的 version matrix 和包注册表为准，因为工具链正在演进。

### 13.3 参考 Domains

公共注册表可能为了透明性保留实验性或 yanked entries，但官方默认安装面是一个聚焦的参考集合：

- kdna_authoring；
- agent_safety；
- prompt_diagnosis；
- code_review；
- writing；

这组参考集合覆盖创作、安全、提示诊断、代码评审和写作判断，用来证明 KDNA 的安装、验证和加载流程。其他 domains 暂不作为默认官方安装资产。有些是参考示例，有些仍处于实验状态，质量应根据 eval 证据、专家审查和使用结果判断。

### 13.4 参考 GUI 客户端

a KDNA-compatible client 是一个正在形成的参考 GUI 客户端，用来让 KDNA 在对话中变得可见。它的职责不是定义协议真理。SPEC 和参考 core implementation 定义协议。a KDNA-compatible client 展示判断如何被加载、比较、追踪，并对用户可见。

Compare Mode 尤其重要：同一输入，同一模型，无 KDNA 与有 KDNA 对比，展示 judgment delta。

---

## 15. 路线图

KDNA 下一阶段的目标不是尽可能增加 domains 数量，而是从 domain assets 走向完整 judgment protocol。

### Phase 1：协议地基

- 在 SPEC 中加入正式 Judgment Model 章节。
- 定义判断的 13 个要素及其文件承载位置。
- 分阶段升级 schemas：
  - Core + Patterns；
  - Scenarios + Cases；
  - Reasoning + Evolution + manifest / version matrix。
- 统一 `status`、`quality_badge` 和 `access` 字段。

### Phase 2：参考 Domains

- 先强化官方参考 domains：
  - kdna_authoring；
  - agent_safety；
  - prompt_diagnosis；
  - code_review；
  - writing；
- 确保每个都有完整六文件包。
- 每个 domain 至少添加 10 个 evals。
- 让 `kdna verify --judgment` 和 `kdna compare` 产生有意义证据。
- 用参考 domains 验证协议是可执行的，而不仅是概念性的。

### Phase 3：组合与 Clusters

- 把 cluster 概念加入 SPEC：
  - Judgment Atom；
  - Judgment Cluster；
  - Judgment System。
- 定义 cluster schema 和 composition policy schema。
- 定义加载配置和 token 预算策略。
- 在真实需求足以证明必要性之前，推迟完整工程实现。

### Phase 4：开发者与公众体验

- 简化 README。
- 为 domain creators 发布 Judgment Anatomy 指南。
- 在网站加入 Judgment Delta 示例。
- 将 registry policy 从收录规则升级为质量治理。
- 改进面向 agent developers、domain creators 和 evaluators 的 onboarding。

---

## 结论

AI Agent 正在变得更强大、更互联，也更主动。这种进步不会让人类判断变得不重要。它让人类判断的表示变得更重要。

人类知识已经通过书籍、文档、代码、数据库和搜索被数字化。人类流程已经通过工作流、自动化、CI/CD 系统和 agent 框架被数字化。但人类判断——那些隐性的、多维的、由经验塑造的标准，那些专家用来分类情境、权衡风险、拒绝坏模式、保留边界并决定什么算好的能力——还没有一种标准、可移植的表示形式。

KDNA 解决的是这个表示问题。它给领域判断一个开放协议：一种可以被创作、验证、加载、追踪、组合、版本化、共享和改进的协议。

KDNA 不替代模型、提示词、知识库、Skills、工作流、工具、检索、评估或微调。它为它们提供一个更清晰的判断参照。

这个项目仍处于早期。格式和工具链已经存在。下一步挑战是通过高质量 domains、benchmark 证据、Compare Mode 和真实使用来证明：显性领域判断可以以可衡量、可检查、可重复的方式改善 agent 行为。

如果这件事成立，AI 能力栈将不只拥有模型、工具、知识和工作流。它还将拥有判断层。

---

*KDNA 是一个 Apache 2.0 许可下的开源项目。规范、schemas 和参考工具链均以该许可发布。各个 domains 可能携带自己的内容许可。*

*网站：https://aikdna.com*  
*GitHub：https://github.com/aikdna/kdna*  
*npm：@aikdna/kdna-cli, @aikdna/kdna-core*
