desirecore · yi-ge · Aug 23, 2026 · Aug 23, 2026
diff --git a/docs/03-use-cases/03-solutions/03-enterprise-coordination.md b/docs/03-use-cases/03-solutions/03-enterprise-coordination.md
@@ -110,6 +110,24 @@ DesireCore: 收到紧急任务，正在调整资源优先级...
         预计 5 分钟内首次回复客户。
 ```
 
+## 先建立共享业务语境
+
+多 Agent 协同不能只依赖每个成员各自理解一段提示词。进入真实企业流程前，团队应先对关键业务概念形成一致定义：
+
+| 本体维度 | 企业协同中的示例 |
+|---|---|
+| 对象 | 产品、发布计划、协议、预算、客户投诉、交付物 |
+| 关系 | 任务负责人、前后依赖、材料来源、决策影响范围 |
+| 规则 | 合规要求、预算阈值、截止时间、优先级与升级条件 |
+| 动作 | 委派、暂停、提交审批、发布、通知与系统回写 |
+| 治理 | 谁可以查看或修改、哪些动作需要人闸门、怎样保留回执 |
+
+可以使用 [企业业务本体](/concepts/business-ontology) 方法，把这些语义、规则和动作边界组织进 AgentFS、Skills、Workflow 与 Policy。这样，法律顾问、财务助手和产品经理讨论“发布”“风险”或“完成”时，指向的是同一组对象、状态和验收标准。
+
+:::note
+业务本体是协同实施方法，不会自动授予任何 Agent 新权限。每个成员仍受自己的[智能体权限边界](/concepts/agent-permission-boundary)、工具授权、人闸门与审计规则约束。
+:::
+
 ## 核心能力
 
 ### 任务编排

diff --git a/docs/04-concepts/13-business-ontology.md b/docs/04-concepts/13-business-ontology.md
@@ -0,0 +1,223 @@
+---
+title: 企业业务本体与 AI 落地
+description: 理解业务本体如何统一对象、关系、规则、动作与权限，并与 AgentFS、Skills、Workflow、多 Agent 和治理能力结合
+keywords: [企业本体, 业务本体, 本体驱动 AI, FDE, 知识图谱, RAG, AI 落地]
+sidebar_position: 13
+last-reviewed: 2026-08-23
+---
+
+# 企业业务本体与 AI 落地
+
+企业 AI 面临的核心问题，通常不是“模型不知道某个术语”，而是模型缺少一套稳定的业务语境：它不知道当前处理的是哪个对象、对象处于什么状态、哪些规则适用、能够调用什么动作，以及什么时候必须交给人确认。
+
+**企业业务本体（Enterprise Business Ontology）**把对象、关系、规则、动作和权限组织成共同模型，让人和智能体能够围绕同一个业务世界理解、判断和协作。
+
+:::info 能力边界
+本页介绍的是**业务本体驱动的实施方法**。DesireCore 通过 AgentFS、记忆与知识图谱、Skills、Workflow、多 Agent、Hook / Policy、审批和回执承接相关资产与执行，但不把这些能力描述为一个独立、封闭的“本体引擎”。具体数据连接、自动化动作和企业治理能力以当前版本、授权范围与正式项目方案为准。
+:::
+
+## 本体不是术语表
+
+术语表只能解释“这个词是什么意思”；面向 AI 落地的业务本体还要回答四类问题：
+
+| 组成 | 要回答的问题 | 示例 |
+|---|---|---|
+| **对象与状态** | 业务世界里有什么？现在处于什么状态？ | 设备 A、合同 v3、待审批订单 |
+| **关系与证据** | 对象怎样关联？结论从哪里来？ | 负责人、上下游依赖、引用标准、来源页码 |
+| **规则与逻辑** | 应该怎样判断？哪些约束必须满足？ | 审批阈值、校核规则、决策树、计算逻辑 |
+| **动作与治理** | 允许做什么？由谁确认？如何记录？ | 生成报告、提交复核、写回系统、人闸门 |
+
+可以把它简化为一句话：
+
+> 语义负责理解，逻辑负责判断，动作负责执行，权限与证据负责可信。
+
+## 从数据到行动的闭环
+
+业务本体位于数据、知识与执行之间。它不替换企业现有的数据库、ERP、CRM、文档库或专业系统，而是让这些系统中的信息能够被统一解释，并在授权范围内连接到实际业务动作。
+
+```mermaid
+flowchart LR
+    A[业务资料与实时数据<br/>文档 · 表格 · 系统 · 事件] --> B[业务本体语境<br/>对象 · 关系 · 规则 · 动作 · 权限]
+    B --> C[人 + Agent 团队<br/>理解 · 计划 · 分工 · 复核]
+    C --> D[Workflow 与业务动作<br/>工具调用 · 审批 · 交付 · 回写]
+    D --> E[结果、回执与反馈<br/>证据 · 异常 · 人工意见 · 指标]
+    E -. 经验回流 .-> B
+```
+
+这个闭环包含两个重要约束：
+
+1. **本体必须连接真实来源。** 对象状态、规则与证据需要能够回到具体数据、文档版本或业务系统。
+2. **动作必须受治理。** 理解某个对象不等于获得修改它的权限；执行仍受工具授权、文件范围、策略、人闸门与审计约束。
+
+## 本体、知识图谱与 RAG 的区别
+
+这三类能力可以组合，但不应混为一谈。
+
+| 能力 | 核心问题 | 典型输出 | 单独使用时的边界 |
+|---|---|---|---|
+| **RAG / 语义检索** | 哪些材料与当前问题相关？ | 文档片段、引用、摘要 | 能找到信息，但不天然理解完整业务状态或允许的动作 |
+| **知识图谱** | 哪些实体存在，它们怎样连接？ | 实体、关系、路径、来源 | 能表达关系，但不必然包含流程、权限和执行语义 |
+| **业务本体** | 业务世界如何定义、判断并行动？ | 对象、关系、规则、动作、权限 | 需要与真实数据、系统和一线流程共同维护 |
+| **Agent Workflow** | 怎样围绕目标完成一组任务？ | 计划、工具调用、交付物、回执 | 没有共享语义时，跨系统理解与治理容易碎片化 |
+
+组合后的职责是：
+
+- RAG 提供相关材料；
+- 知识图谱提供实体关系和来源；
+- 业务本体提供稳定语义、规则和动作边界；
+- Agent 围绕目标进行规划、协作与执行。
+
+## DesireCore 能力如何承接本体方法
+
+DesireCore 不要求把本体资产放进一个额外的黑盒系统，而是让它们落在已有、可检查的能力中。
+
+| DesireCore 能力 | 在本体实施中的作用 | 可检查的资产或证据 |
+|---|---|---|
+| [AgentFS](./agentfs) | 保存身份、规则、资料、Skills、Workflow、版本与回执 | 文件、目录、Git 版本、来源信息 |
+| 记忆与知识图谱 | 连接业务术语、对象关系、用户纠正和任务经验 | 记忆条目、作用域、关系、来源 |
+| Skills / 决策树 | 承载专家规则、示例、判断路径和验收标准 | `SKILL.md`、脚本、规则与测试材料 |
+| Workflow | 组合确定性步骤、Agent 判断、工具调用和异常处理 | 节点配置、执行记录、重试与回放 |
+| 多 Agent Runtime | 让研究、执行、复核等角色共享语义并分工 | 委派记录、成员输出、合并与复核结果 |
+| Hook / Policy / Human Gate | 限制高风险动作和系统回写 | 策略命中、审批、拒绝与临时授权 |
+| [回执系统](./receipt-system) | 记录本体驱动任务使用了什么信息、规则与动作 | 输入输出、工具调用、证据和异常记录 |
+
+:::warning 不要把方法写成不存在的产品能力
+当项目只使用文件、记忆、Skill 和 Workflow 来组织业务语境时，应准确描述这些资产如何组合。只有在实际实现了专门的数据模型、编辑器、查询接口或运行时之后，才能进一步声称提供对应的“本体平台”能力。
+:::
+
+## FDE 式落地：从最小可用本体开始
+
+FDE（Forward Deployed Engineer，前线部署工程师）式方法强调进入真实业务现场，与一线专家共同建模、集成和验证。它不要求先建设一个覆盖全公司的“大而全本体”，而是从一条价值明确的业务链开始。
+
+### 1. 贴近业务现场
+
+**核心问题：** 谁在什么条件下做出什么决定？
+
+- 跟随一条真实任务，而不是只访谈理想流程；
+- 盘点角色、输入、输出、系统、异常路径和风险边界；
+- 记录当前耗时、错误类型、人工接管和业务结果。
+
+**阶段输出：** 业务链地图、责任主体、输入输出、基线指标。
+
+### 2. 建立最小可用本体
+
+**核心问题：** 完成这条业务链必须理解哪些概念？
+
+- 定义关键对象、关系和状态；
+- 收集专家规则、优先级、例外和验收标准；
+- 列出允许的动作、权限条件和证据要求。
+
+**阶段输出：** 对象词典、关系图、规则清单、动作与权限表。
+
+### 3. 组装 Agent 工作闭环
+
+**核心问题：** 怎样让共享语义进入真实执行？
+
+- 将资料、规则和角色边界组织到 AgentFS；
+- 用 Skills、决策树和 Workflow 承载判断与步骤；
+- 接入必要工具，并设置人闸门、异常处理和回写边界；
+- 明确各 Agent 的职责、交接和复核关系。
+
+**阶段输出：** 可运行场景、角色分工、审批点、交付模板。
+
+### 4. 评测、上线与持续迭代
+
+**核心问题：** 怎样证明有效，并安全扩大自动化范围？
+
+- 使用真实测试集、边界案例和失败分类；
+- 检查对象识别、规则判断、交付质量与专业复核差异；
+- 观察权限命中、人工接管、成本、时延和业务结果；
+- 通过回放、回执和版本对比更新本体资产。
+
+**阶段输出：** 验收报告、评测基线、运行看板、迭代计划。
+
+## 场景建模示例
+
+### AI 标书写作
+
+| 维度 | 示例 |
+|---|---|
+| 对象 | 招标条款、资格要求、评分点、企业材料、章节、风险项 |
+| 关系 | 评分点对应章节、资格要求引用企业材料、结论引用来源页码 |
+| 规则 | 响应完整性、资格匹配、格式要求、禁用表述 |
+| 动作 | 拆解要求、匹配证据、并行撰写、风险复核、Word 交付 |
+| 人工边界 | 关键承诺、报价、资质和最终投标文件由责任人确认 |
+
+### 工程图解析与设计校核
+
+| 维度 | 示例 |
+|---|---|
+| 对象 | 设备、管线、仪表、回路、图页、坐标、版本、校核规则 |
+| 关系 | 拓扑连接、回路归属、跨页引用、对象与证据位置 |
+| 规则 | 编号一致性、拓扑检查、专业规则、冻结基线 |
+| 动作 | 识别、关联、差异检查、形成问题清单和证据定位 |
+| 人工边界 | 设计基准须先冻结，结果由具备资质的工程师复核签发 |
+
+### 合同审查与履约跟踪
+
+| 维度 | 示例 |
+|---|---|
+| 对象 | 合同、条款、主体、义务、期限、金额、风险、审批记录 |
+| 关系 | 主体承担义务、条款引用法规、风险关联审批人 |
+| 规则 | 企业模板、法规要求、金额阈值、缺失与冲突条款 |
+| 动作 | 逐条审查、证据引用、风险分级、提交审批、生成报告 |
+| 人工边界 | 法律判断、重大风险接受和签署由授权人员完成 |
+
+## 治理与验收清单
+
+上线前，不应只检查模型“回答得像不像”。至少需要覆盖以下四类证据：
+
+### 语义与证据
+
+- [ ] 对象、关系和状态定义得到业务专家确认
+- [ ] 同名异义、字段冲突和版本差异有处理规则
+- [ ] 关键结论能够定位到来源、版本、页码或坐标
+
+### 任务与质量
+
+- [ ] 测试集包含正常案例、边界案例和反例
+- [ ] 交付格式、业务规则和专业要求可自动或人工校验
+- [ ] AI 结果与专业人员复核差异被记录和分类
+
+### 动作与权限
+
+- [ ] 工具、文件、数据和系统回写遵循最小权限
+- [ ] 高风险动作进入 [Human Gate](./step-types)
+- [ ] 危险操作能够被策略拒绝，敏感信息能够被限制或脱敏
+
+### 运行与改进
+
+- [ ] 每次任务保留回执、异常和人工接管记录
+- [ ] 监控通过率、失败率、成本、时延和业务结果
+- [ ] 本体、Skill 和 Workflow 的更新经过版本与评测控制
+
+## 常见误区
+
+### “有一个知识库，就已经有业务本体”
+
+知识库提供材料，不一定定义对象状态、业务规则和可执行动作。判断是否形成业务本体，要看人和 Agent 能否基于同一语义进行判断和受治理执行。
+
+### “本体越大越完整越好”
+
+没有真实工作流验证的大型模型很容易过时。更可靠的做法是围绕一个业务目标构建最小本体，形成反馈闭环后再扩展。
+
+### “有本体以后，Agent 可以自动决定一切”
+
+本体能让决策上下文更清楚，但不会自动消除风险、专业责任和权限限制。工程、法律、财务等高风险结论仍需要相应资质和授权人员确认。
+
+## 行业参考
+
+- [W3C OWL 2 Overview](https://www.w3.org/TR/owl2-overview/)：本体语言、类、属性、个体和关系的标准化基础。
+- [Palantir Ontology Overview](https://www.palantir.com/docs/foundry/ontology/overview)：对象、关系、动作、函数与治理连接到运营工作流的公开说明。
+- [Palantir AI FDE Overview](https://www.palantir.com/docs/foundry/ai-fde/overview)：通过自然语言参与数据集成、本体编辑、函数、治理与验证的公开工作方式。
+
+外部资料用于解释行业方法，不代表 DesireCore 与资料发布方存在产品从属关系。
+
+## 相关文档
+
+- [AgentFS 文件系统](./agentfs)
+- [智能任务编排](./task-orchestration)
+- [智能体权限边界](./agent-permission-boundary)
+- [固化步骤、灵活步骤与人闸门](./step-types)
+- [回执系统](./receipt-system)
+- [企业服务协同](/use-cases/solutions/enterprise-coordination)
diff --git a/docs/04-concepts/index.md b/docs/04-concepts/index.md
@@ -29,6 +29,7 @@ DesireCore 围绕"培养并托管数字同伴"这一核心理念，构建了一
 | [智能任务编排](./task-orchestration) | 自动拆解任务、匹配最佳智能体的"项目经理" | 想理解任务分配机制 |
 | [Auto Dream](./auto-dream) | 无损遗忘，在压缩中保留价值 | 想理解记忆整合机制 |
 | [智能体权限边界](./agent-permission-boundary) | 谁动手就按谁的权限算，越权责任在执行方 | 想理解多同伴协作时的权限归属 |
+| [企业业务本体](./business-ontology) | 用对象、关系、规则、动作与权限连接业务语义和 AI 执行 | 想理解本体、RAG、知识图谱与 FDE 式落地 |
 
 ## 阅读建议
 
@@ -40,3 +41,5 @@ DesireCore 围绕"培养并托管数字同伴"这一核心理念，构建了一
 4. 最后根据兴趣阅读其他概念
 
 如果你是技术背景用户，可以直接跳到 **AgentFS 文件系统** 和 **回执系统**，这两个概念最能体现 DesireCore 的技术创新。
+
+如果你负责企业 AI 或行业方案落地，建议继续阅读 **[企业业务本体](./business-ontology)**，理解如何从一条真实业务链建立共享语义、动作边界和验收证据。
diff --git a/docs/05-more/03-glossary.md b/docs/05-more/03-glossary.md
@@ -25,6 +25,9 @@ Automatic Speech Recognition 的缩写，将语音转换为文字的技术。Des
 
 ## B
 
+### Business Ontology（企业业务本体）
+将企业中的对象、关系、规则、动作和权限组织成共享业务语境的方法，使人和 Agent 能够基于同一含义进行判断与受治理执行。DesireCore 通过 AgentFS、记忆与知识图谱、Skills、Workflow、多 Agent、Policy 和回执承接相关资产；详见[企业业务本体与 AI 落地](../04-concepts/13-business-ontology.md)。
+
 ### BYOK（Bring Your Own Key）
 "自带钥匙"模式。用户使用自己的 AI 供应商 API Key，DesireCore 不做中间代理，费用直接由供应商向用户结算。
 
@@ -69,6 +72,9 @@ DesireCore 的核心交互范式。不是"我问你答"，而是"我教你做"
 
 ## F
 
+### FDE（Forward Deployed Engineer）
+前线部署工程师。进入真实业务现场，与一线专家共同识别决策、建立最小可用本体、连接数据与工具，并通过业务测试和运行证据持续迭代。FDE 是一种交付角色与工作方式，不是 DesireCore 的独立产品模块。
+
 ### Feedback（反馈）
 用户对智能体执行结果的评价和纠正。正面反馈强化行为，负面反馈触发调整，是智能体进化的重要信号。
 
@@ -107,6 +113,9 @@ DesireCore 的核心交互范式。不是"我问你答"，而是"我教你做"
 
 ## R
 
+### RAG（Retrieval-Augmented Generation，检索增强生成）
+先从知识源检索与当前问题相关的材料，再将其作为上下文提供给生成模型的方法。RAG 擅长提供资料与引用，但不天然定义完整业务状态、规则优先级、可执行动作和权限边界。
+
 ### Receipt（回执）
 智能体完成任务后生成的详细记录，包含输入输出摘要、工具调用清单、检索轨迹、步骤类型统计等信息。是"可信委派"的证据链。
 

diff --git a/docs/index.md b/docs/index.md
@@ -81,6 +81,7 @@ keywords: [DesireCore, 用户手册, AI 智能体, 委派式交互, Agent OS]
 - [配置 API Key](./getting-started/configure-api-key) — 连接 AI 服务的第一步
 - [教会智能体](./user-guide/teaching/delegation-interaction) — DesireCore 最核心的能力
 - [智能任务编排](./concepts/task-orchestration) — 自动拆解任务、匹配最佳智能体
+- [企业业务本体](./concepts/business-ontology) — 连接对象、规则、动作、权限与 FDE 式 AI 落地
 - [GUI 桌面自动化](./user-guide/capabilities/computer-use) — 让智能体操控电脑和手机
 - [超级文书](./user-guide/super-document/overview) — 像 Code Review 一样协作写文档
 - [快捷键速查](./more/keyboard-shortcuts) — 提升操作效率

diff --git a/...in-content-docs/current/03-use-cases/03-solutions/03-enterprise-coordination.md b/...in-content-docs/current/03-use-cases/03-solutions/03-enterprise-coordination.md
@@ -98,6 +98,24 @@ DesireCore: Received emergency task, adjusting resource priority...
         Expected first response to customer within 5 minutes.
 ```
 
+## Establish shared business context first
+
+Multi-agent coordination cannot rely only on each member interpreting a separate prompt. Before entering a real enterprise process, the team should share explicit definitions for critical business concepts:
+
+| Ontology dimension | Enterprise-coordination example |
+|---|---|
+| Objects | Product, release plan, agreement, budget, complaint, deliverable |
+| Links | Owner, task dependency, material source, decision impact |
+| Rules | Compliance, budget threshold, deadline, priority, escalation |
+| Actions | Delegate, pause, submit approval, release, notify, write back |
+| Governance | Who can read or change, which actions need Human Gates, how receipts are retained |
+
+Use the [Enterprise Business Ontology](/concepts/business-ontology) method to organize these semantics, rules, and action boundaries across AgentFS, Skills, Workflows, and Policies. Legal, finance, and product agents then use the same objects, state, and acceptance criteria when they discuss “release,” “risk,” or “done.”
+
+:::note
+A business ontology is an implementation method; it does not grant new permissions to any agent. Every member remains governed by its own [Agent Permission Boundary](/concepts/agent-permission-boundary), tool grants, Human Gates, and audit policy.
+:::
+
 ## Core Capabilities
 
 ### Task Orchestration
@@ -150,4 +168,4 @@ A trackable multi-agent collaboration workflow: tasks are decomposed, delegated,
 - When describing requirements, state the overall goal (e.g., "release new product"), deadline, existing materials and non-negotiable constraints
 - For projects with clear deadlines, inform time constraints from the start—the scheduler will prioritize tasks on the critical path
 - Regularly check progress summaries and promptly respond to items requiring your decision to avoid blocking other agents' subsequent work
-:::
+:::