BKN：专为 Agent 上下文而生的业务本体描述语言
在 AI 原生时代，软件的重心正在发生变化。以前开发系统，核心是实现功能；现在做 Agent，核心正在转向上下文（Context）。
一个 Agent 在复杂业务里能不能长期稳定运行，不仅看模型，更看它拿到的上下文质量。Anthropic 在描述 Context Engineering 时提到，当 Agent 处理多轮推理和长任务时，治理的重点已经不再是单条 Prompt，而是整个推理过程中进入窗口的信息集合。OpenAI 也在指南里把系统拆为模型、工具、记忆和编排，强调能力是各部分配合出的结果。
说白了，Agent 时代真正稀缺的是让模型「读懂业务」的能力。而 BKN（Business Knowledge Network） 就是在这个背景下开发出来的。
一、什么是 BKN 语言：它包含什么，以及它如何工作？
BKN 是一种面向业务知识网络的 Markdown 领域建模语言，也可以理解为专为 Agent 上下文设计的业务本体描述语言。它不关注底层数据在哪里，而是关注业务领域本身如何被建模、组织和表达。这是 KWeaver Core 项目的创新点之一。
BKN 文件的目标不是定义数据格式，也不是再写一份给人读的业务文档，而是把原本分散在数据库、接口、流程、规则和人脑经验里的业务知识，整理成一套 Agent 可以直接读取、理解、调用和约束的语义结构，作为整个 Agent 数据层面的 Source of Truth（唯一事实来源）。
BKN 的核心概念很简单：
- Object：业务对象（比如订单、供应商、Pod、Node）
- Relation：对象之间的关系（比如归属、依赖、来源于）
- Action：围绕对象可以执行的动作，并可绑定工具或 MCP
- Risk：与动作或对象相关的执行风险、约束和边界
以及对象与底层数据源之间的语义映射。
直白点说，BKN 就在回答这样几个问题：业务里到底有什么？对象之间是什么关系？系统围绕它们可以做什么？哪些动作需要受到约束？这些业务概念最终如何落到底层数据和工具上？
从组织方式上看，BKN 通常不是一个孤立文件，而是一组结构化内容共同组成的知识网络。通常包含面向 Agent 的 SKILL.md、作为知识网络根定义的 network.bkn，以及按类型拆分的 .bkn 文件树。
在 Agent 使用的时候，BKN 不会一次性把所有知识塞给模型，而是先把业务组织成一张可逐步展开的网。Agent 运行时首先面对的是一个整理过的语义空间的索引，再根据任务需要去读取相关的对象、关系和边界条件。这和 Claude SKILL 的设计逻辑一样，实现了对于业务知识的「渐进式」披露。
二、从 Context Engineering 到 Harness Engineering：BKN 在其中扮演什么角色？
随着 Agent 走向多轮推理和长任务，工程重点变了。Anthropic 认为 Context Engineering 的重点是筛选和维护窗口信息。但在复杂业务里，这还不够。
真实的 Agent 面对的是一堆乱麻：工具说明、历史状态、中间结果，还有各种隐含的潜规则。这就是为什么 Harness Engineering（驾驭工程） 成了当下 Agent 领域的热门话题——它的核心不再是「把信息塞进模型」，而是如何把上下文、工具和规则整合成一个受控的系统。
BKN 实际上就是为这种治理提供了「语义抓手」。它通过两个层面的语义化，实现了 Agent 的 Harness：
- 数据语义化：把业务拆成对象、关系和逻辑映射。这样 Agent 拿到的不再是「原始素材」，而是结构清晰的业务逻辑。
- 行动语义化：BKN 里不只定义「是什么」，还定义了「能做什么」。它把动作边界和风险红线直接封装在语义里，让 Agent 在运行的时候能够安全、可靠地执行操作。
这样一来，上下文就不再是给模型看的一段参考资料，而是变成了真正能驱动 Agent 理解、决策并受控执行的业务底座。
三、为什么采用 Markdown 作为载体？
在当前的 Agent 生态里，越来越多的能力说明和行为规则都在用 Markdown 组织。
这不是因为 Markdown 本身有多高级，而是因为它恰好落在一个很合适的位置上：它不像底层数据格式那么生硬，也不像纯自然语言那样没边界；它既适合人维护，也适合模型读取。Anthropic 对 SKILL 的设计、OpenAI 对 AGENTS.md 的设计、还有 OpenClaw 对于 SOUL.md 和 MEMORY.md 的设计，其实都印证了这一点。
BKN 采用 Markdown 也是出于同样的考虑。它要表达的不是单纯的配置，而是一种既面向业务专家、又面向 Agent 的语义结构。此外，Markdown 还有一个很实际的好处：显著减少上下文长度。很多时候，真正影响效果的是知识能否以一种更紧凑的方式进入上下文，减少模型的消费压力。
四、为什么说 BKN 是一种「本体」描述语言？
BKN 的核心概念是 Object、Relation、Action、Risk 这样一组元素：
- Object 回答的是：这个业务里有什么
- Relation 回答的是：这些东西如何彼此连接
- Action 回答的是：围绕这些对象可以做什么
- Risk 回答的是：这些动作在哪些边界内才成立
这和 Palantir Ontology 有相通之处。Palantir 官方将 Ontology 定义为组织的运营层（operational layer），强调它位于数字资产之上，把资产映射到现实世界中的对象、属性和动作。不过 BKN 还增加了一类风险对象，显式地约束了 Agent 的行为，这又是 BKN 的一个创新之处。
BKN 的「本体」特征，主要体现在三个层面：
- 概念稳定：数据库表和接口总在变，但「订单」「供应商」这类业务概念通常更稳定。
- 结构化关系：本体不是词典，而是语义网络。对象、动作、风险之间的关系如果没有理清楚，Agent 就很难形成稳定的业务理解，只能依赖关键词去猜。
- 可执行语义：传统本体偏静态，而 BKN 明显更贴近 Agent 场景。它不仅回答「是什么」，也回答「能做什么、什么时候能做、怎么控风险」。这使它能直接进入执行链条。
五、BKN 是如何构建的？
在以往的经验中，本体的构建是相当复杂的，既需要业务专家的经验，也需要开发工程师的配合。有了 BKN 之后，事情变得简单很多。既然 BKN 是为 Agent 设计的，那最好的构建方式就是：用 Agent 生成 BKN。
在 KWeaver 项目里，我们并不是手写所有的 .bkn 文件，也不需要用户来进行 BKN 的配置，而是通过一个叫 BKN-Creator 的 Skill 来自动化这个过程。它的逻辑不是简单的文本翻译，而是引导 Agent 像业务专家一样去完成知识的沉淀。
具体到操作上，这个构建过程通常被拆解为三个动作：
-
从需求和数据中萃取对象（Object & Relation）
用户可以根据实际的需求编写说明文档，同时丢给 BKN-Creator 一堆数据库 Schema 或者 API 定义，它会去识别那些真正有业务意义的实体。比如它会发现「供应商」和「合同」不只是两张表，它们之间存在着某种关联，从而在network.bkn里把这种关系定义出来，并生成相应的对象类和关系类。 -
给对象绑定行动（Action）
这时候，原本孤立的行动会被挂载到具体的对象上。比如「重启」不再是一个冷冰冰的 API，而是属于 Pod 这个对象的一个专属动作。这种绑定让 Agent 看到对象时，就能够理解可以对这些对象进行什么样的操作。 -
注入风险控制（Risk）
这也是极为关键的一步。在生成 BKN 的过程中，我们会让 Agent 根据用户的需求来识别每个行动的风险。比如执行「批量删除」前必须检查什么状态。这些约束会直接写进.bkn文件，变成 Agent 思考时的硬边界。BKN 在执行时，会被约束在这个边界内。
通过这种方式，BKN 的构建就不再是一个繁琐的文档工程。你只需要提供原始素材，Agent 就能按照这套规范，把零散的信息组装成一个它自己能读懂、能执行的业务认知底座。
六、实战效果：BKN 让 Agent 更接近业务思维
当任务从「简单查询」走向「复杂分析」和「业务判断」时，BKN 的价值会越来越明显。
我们做过一组测试，共 24 个与供应链相关的业务问题。在相同模型前提下对比：
- 纯 SQL 方案：靠生成 SQL 查数据，通过率约 79.2%。
- BKN 方案：映射业务规则后再处理，通过率提升至 95.8%。
同时，这 24 题的客户端 Token 消耗从约 500K 降到 292K，调用次数也从 56 次降到 45 次。
结果说明，BKN 让 Agent 不再总盯着底层表结构，而是更多围绕业务对象、关系和规则思考。当然，BKN 不是为了替代 SQL。SQL 擅长精确查询和直接聚合，BKN 的意义是把 SQL、Python、工具调用这些能力，放进一个更贴近业务语义的框架里使用。
结语
BKN 本质上是一种面向 Agent 的业务语义组织方式。它基于 Markdown，但不止于文档；它描述对象、关系、行动和风险，既能被业务专家理解，也能被 Agent 读取和消费。
如果说 Agent 时代的核心问题是「如何让模型在复杂业务中持续做对事」，那么答案往往不只是追求更强的模型，而是通过更好的上下文工程，把业务语义、工具和执行规则理清楚。BKN 的价值就在于帮助我们把业务世界整理好，让这些知识不只是存在，而是真的能被 Agent 理解、被系统使用，也能被团队持续维护。
更多内容，欢迎访问我们的开源项目：