01
对象与状态
表示真实业务中的人、设备、项目、订单、合同、指标和文档，以及它们当前所处的状态。
设备 A合同 v3待审批订单
本体不是术语表，而是业务对象与行动规则的共同模型
只有知识、没有动作，AI 仍停留在问答；只有动作、没有语义，自动化很难理解业务状态。业务本体把“这是什么、彼此怎样关联、适用什么规则、允许做什么”放进同一个模型。
BUSINESS ONTOLOGY
一套可用于人和 Agent 协作的业务语境
从订单、设备、合同和文档，到责任关系、专业规则、审批动作与权限边界，每个概念都能指向来源、当前状态和允许的操作。
02
关系与证据
说明责任、依赖、上下游、版本、引用和来源，使结论能够回到原始材料与业务上下文。
负责人引用标准来源页码
03
规则与逻辑
承载专家规则、决策树、SOP、算法、模型和约束条件，定义怎样判断与怎样处理。
校核规则审批阈值计算逻辑
04
动作与治理
定义可被人或 Agent 调用的检索、生成、审批、通知、执行和回写，并附带权限与审计。
提交复核生成报告写回系统
语义负责“理解”，逻辑负责“判断”，动作负责“执行”，权限与证据负责“可信”。四者一起，才是面向 AI 落地的业务本体。
本体、知识图谱与 RAG 解决的是不同层次的问题
三者可以组合，但不应混为一谈。RAG 提供相关材料，知识图谱组织实体关系，业务本体进一步明确业务含义、规则、可执行动作和治理边界。
| 能力 | 核心问题 | 典型输出 | 单独使用时的边界 |
|---|---|---|---|
| RAG / 语义检索 | 哪些材料与当前问题相关？ | 文档片段、引用、摘要 | 能找到信息，但不天然理解完整业务状态或允许的动作 |
| 知识图谱 | 哪些实体存在，它们怎样连接？ | 实体、关系、路径、来源 | 能表达关系，但不必然包含流程、权限和执行语义 |
| 业务本体 | 业务世界如何定义、判断并行动？ | 对象、关系、规则、动作、权限 | 需要与真实数据、系统和一线流程共同维护 |
| Agent 工作流 | 如何围绕目标完成一组任务？ | 计划、工具调用、交付物、回执 | 没有本体约束时，跨系统语义和治理容易碎片化 |
组合方式：RAG 提供材料，知识图谱提供关系，本体提供业务语义和动作边界，Agent 负责在目标驱动下计划、协作与执行。
不另建一座概念孤岛，而是把本体方法落到可管理资产
DesireCore 当前能力分别承接本体落地中的资产、知识、逻辑、执行、协作与治理。这里描述的是组合方式，不宣称存在独立封闭的“本体引擎”。
AgentFS
保存可检查的业务资产
组织身份、规则、记忆、资料、Skills、Workflow、版本与回执，使本体相关资产可查看、迁移和维护。
Memory / Knowledge Graph
连接长期知识与关系
沉淀业务术语、对象关系、用户纠正与任务经验，并保留作用域和来源。
Skills / Decision Trees
承载专家规则与判断方法
把规则、示例、判断路径和验收标准转化为可复用、可版本化的能力。
SOP / Workflow
把业务动作编排成稳定链路
组合确定性步骤、Agent 判断、工具调用、异常处理与人工确认。
Multi-Agent Runtime
让不同角色共享语义并分工
研究、撰写、校核和交付角色围绕同一对象与证据边界并行协作。
Hook / Policy / Receipts
限制动作并形成责任证据
通过权限、策略、审批、拦截、运行记录和回执控制真实业务操作。
从一条真实业务链开始，而不是先建设大而全的概念体系
FDE（Forward Deployed Engineer，前线部署工程师）式方法强调进入业务现场，与一线专家共同建模、集成和验证。每一步都要产生可复核输出，而不是只留下概念文档。
- 01核心问题
贴近业务现场
谁在什么条件下做出什么决定？
访谈角色，跟随真实任务，盘点数据来源、现有系统、异常路径、风险边界和交付目标。
- 阶段输出
- 业务链地图、角色与责任、输入输出、基线指标
- 验收证据
- 样例任务、源材料、系统截图、当前耗时与错误类型
- 02核心问题
建立最小可用本体
完成这一条业务链必须理解哪些概念？
定义关键对象、关系、状态、规则、动作、权限和证据要求，优先覆盖高价值决策。
- 阶段输出
- 对象词典、关系图、规则清单、动作与权限表
- 验收证据
- 专家确认、术语冲突记录、规则边界与缺失项
- 03核心问题
组装 Agent 工作闭环
怎样让语义进入真实执行？
连接 AgentFS、Skills、工具、Workflow 与 Human Gate，配置异常处理和系统回写边界。
- 阶段输出
- 可运行场景、角色分工、审批点、交付模板
- 验收证据
- 执行轨迹、工具调用、审批记录、交付物与回执
- 04核心问题
评测、上线与持续迭代
怎样证明有效并安全扩大范围？
建立测试集、业务指标和失败分类；通过回放、人工复核与版本对比逐步扩大自动化范围。
- 阶段输出
- 验收报告、评测基线、运行看板、迭代计划
- 验收证据
- 通过率、异常率、人工接管、成本、时延与业务结果
同一套方法，在不同业务中形成不同本体
本体必须服务具体决策与动作。下面的场景展示如何从对象和规则推进到可复核交付，不将 AI 输出等同于专业签发。
01
AI 标书写作
从招标要求与企业材料生成可追溯、可复核的投标文档。
- 关键对象
- 招标条款、资格要求、评分点、企业材料、章节、风险项
- 规则与逻辑
- 响应完整性、资格匹配、评分映射、格式与禁用表述
- 业务动作
- 拆解要求、匹配证据、并行撰写、风险复核、Word 交付
关键承诺、报价、资质与最终投标文件由责任人确认。
查看相关实践02
工程图解析与设计校核
把多页工程图转化为带位置、版本和来源的结构化事实。
- 关键对象
- 设备、管线、仪表、回路、图页、坐标、版本、校核规则
- 规则与逻辑
- 拓扑关系、编号一致性、规则检查与冻结基线
- 业务动作
- 识别、关联、差异检查、形成问题清单与证据定位
设计基准须先冻结，结果由具备资质的工程师复核签发。
查看相关实践03
合同审查与履约跟踪
让条款风险、责任主体与履约动作保持一致。
- 关键对象
- 合同、条款、主体、义务、期限、金额、风险、审批记录
- 规则与逻辑
- 企业模板、法规要求、金额阈值、缺失条款与冲突规则
- 业务动作
- 逐条审查、证据引用、风险分级、提交审批、生成报告
法律判断、重大风险接受和签署仍由授权人员完成。
查看相关实践可信落地，不只检查答案，还要检查上下文、动作与责任链
面向真实业务的验收需要同时覆盖语义正确性、任务质量、执行安全和持续运行。模型输出只是其中一项。
语义与证据
对象是否识别正确，关系和状态是否完整，结论能否回到来源、版本与坐标。
- 术语一致性
- 来源覆盖率
- 证据可定位
任务与质量
使用真实测试集和边界案例验证规则、交付格式、专业要求与人工复核结果。
- 测试集通过率
- 专业复核差异
- 边界案例
动作与权限
检查最小权限、审批点、危险操作拦截、系统回写和敏感数据处理。
- 权限命中
- Human Gate
- 拦截与脱敏
运行与改进
持续观察成本、时延、异常、人工接管和业务结果，并通过版本管理控制变化。
- 执行回执
- 失败分类
- 版本对比
业务本体常见问题
从概念边界到落地方式的简明回答
01业务本体与知识图谱是一回事吗？
不是。知识图谱主要表达实体、属性和关系；业务本体还需要定义业务语义、状态、规则、可执行动作和权限边界。知识图谱可以成为业务本体的重要组成部分。
02已经有 RAG，为什么还需要本体？
RAG 擅长找到相关材料，但不天然知道完整业务状态、责任关系、规则优先级和允许执行的动作。本体为检索结果补充稳定业务语境，并让 Agent 在明确边界内判断和执行。
03建设本体是否意味着先做一场大型数据治理项目？
不建议。更可行的路径是选择一条价值明确的业务链，建立最小可用本体，在真实任务中验证，再逐步扩展对象、规则和动作。
04DesireCore 是否提供独立的本体引擎？
本页描述的是本体驱动的实施方法。DesireCore 通过 AgentFS、记忆与知识图谱、Skills、Workflow、多 Agent 和治理能力承接相关资产与执行；具体能力范围以当前版本和项目方案为准。
05FDE 在本体与 AI 项目中负责什么？
FDE 连接一线业务与工程实现：识别真实决策和边界，建立最小本体，接入数据与工具，组装工作流，并用业务测试与运行证据持续迭代。
从形式化语义，到面向业务动作的运营本体
页面采用行业公开资料中的共同原则，并结合 DesireCore 已有能力形成独立的产品表达。外部资料用于解释方法，不代表产品从属关系。
