语义本体
统一术语和判断规则
各部门对“有效合同”的理解不同，怎么办？明确合同、附件、签署等概念及判断条件，检查用语和规则是否冲突。需要标准化表达时，可采用 RDF、OWL 等。
版本不一致，先暂停审查
条款审查和风险判断都需要依据同一套材料。系统在分配任务前，应先核对合同编号、正文、附件和版本；材料不齐或版本不一致，就先请经办人确认。
- 01
核对材料
确认合同编号、正文和附件版本，以及双方身份。
- 02
统一依据
让条款审查、风险判断和复核使用同一份材料清单。
- 03
按规则检查
缺少版本或来源页码时暂停处理；明确的检查条件由系统执行。
- 04
保留人工决定
重大责任、付款承诺和签署事项交由授权人员确认。
- 05
记录处理过程
保存材料版本、条款位置、判断依据、审批人和审查结果。
第 3 版和第 2 版是说明用的示例。实际项目应以企业送审材料为准。
根据问题选择方法
“本体”不是单一软件。它可以用来统一术语、梳理关系、规定业务动作，也可以限定智能体的行为。以下四种用法便于讨论项目需求，并非统一的行业分类。
知识图谱
理清对象之间的关系
一项风险涉及哪些合同、人员和单位？把已确认的对象及关系连起来，便于查询关联、查找证据。查询结果仍要核对来源。
运营本体
明确业务动作和状态
什么条件下可以审批、退回或写回系统？把办理状态、操作条件和人员权限写清楚，再与实际业务流程衔接。
智能体行为约束
限定智能体的处理范围
哪些事可自动办理，哪些必须由人批准？规定可调用的工具、必须提供的依据和人工确认事项，拦截越权或依据不足的操作。
已有 RAG 的企业可继续用它检索材料。涉及关系查询、规则判断或系统操作时，再补充相应定义。
平台提供工具，规则由业务确定
DesireCore 可管理资料、任务和审批过程。合同字段、指标口径和权限范围等内容，仍需由企业业务负责人参与确认。
AgentFS
管理业务资料和规则
将资料、规则和工作流程保存为可审阅的文件，记录版本变化。
项目需确定：字段含义、资料来源和版本要求
Memory / Knowledge
留存术语和历史经验
把已确认的术语、纠错记录和经验留在规定的使用范围内。
项目需确定：统一用语、对象关系和可信来源
Skills / Decision Trees
复用业务人员的判断方法
将办理规则、示例和判断步骤整理为可检查的能力。
项目需确定：规则责任人、特殊情况和测试材料
SOP / Workflow
安排办理和审批步骤
区分自动检查、灵活处理和人工确认，出现异常时暂停或转交。
项目需确定：暂停条件、审批节点和交付要求
Multi-Agent Runtime
按职责分工处理
分别完成提取、判断和复核，交接时附上所用材料和依据。
项目需确定：各角色职责和交接内容
Policy / Receipts
控制权限并记录结果
限制工具使用范围，保留人工批准和任务执行记录。
项目需确定：授权范围、风险标准和审计责任
选一项业务，先做试点
下列是可能适用的业务方向，不是 DesireCore 已完成的行业项目清单。能否使用，还要看企业现有数据、业务规则和审批要求。
先明确办理权限
企业智能体
划清自动办理和人工审批的范围，避免智能体越权操作。
先统一对象和来源
数据融合
同一客户在多个系统中名称不同，要先确定识别依据。
先统一指标口径
智能问数
查询收入等指标前，确认计算方法、统计期间和数据范围。
先核对设备和状态
数字孪生
明确设备编号、现场状态以及对应的业务处理动作。
先梳理工序关系
工业 AI
把设备、工序和质量记录对应起来，支持故障追查。
先理清服务依赖
可观测运维
将服务关系和告警记录对应起来，缩小排查范围。
先核实主体关系
金融风控
核对企业、股权和交易关系，保留风险判定依据。
GraphRAG 可用于查找关联资料
它能帮助沿对象关系检索材料，但查到关联不等于结论成立，还要核对关系含义和材料来源。
具体业务要核对什么
标书和工程图文章记录了具体工作过程，合同文档提供建模示例。每项业务都要分清系统处理的部分和人工负责的部分。
01
AI 标书写作
依据招标文件和企业材料准备投标文档，并保留每项响应的出处。
- 核对材料
- 招标条款、资格要求、评分点、企业证明材料
- 判断依据
- 逐条核对要求、资质、评分点和禁止使用的表述
- 处理步骤
- 整理要求、查找材料、起草章节、复核风险并生成文档
关键承诺、报价、资质和最终投标文件由责任人确认。
阅读官网实践02
工程图解析与设计校核
把多页工程图中的设备和连接关系整理出来，并标明出处。
- 核对材料
- 设备、管线、仪表、图页、位置和版本
- 判断依据
- 核对连接关系、编号和设计基准是否一致
- 处理步骤
- 识别图纸、检查差异、列出问题及对应位置
设计基准应先确认，结果由具备资质的工程师复核签发。
阅读官网实践03
合同审查与版本校验
确保正文、附件和审查意见使用同一套材料。
- 核对材料
- 合同、附件、条款、签约主体、版本和页码
- 判断依据
- 核对版本、附件是否齐全，以及风险和审批条件
- 处理步骤
- 确认送审材料、分工审查、补齐依据、复核并交付
法律判断、重大风险接受和签署仍由授权人员完成。
查看文档中的建模示例先试一项业务，再逐步推广
FDE 指贴近业务现场工作的工程人员。项目开始时，应与经办人一起核对材料、规则和审批责任，再用实际任务测试效果。这里说的是实施方式，不是 DesireCore 的独立产品。
- 01先问清楚
摸清现有流程
谁负责办理，哪里最容易出错？
选取真实任务，了解经办人、送审材料、使用系统、常见异常和当前耗时。
- 形成材料
- 流程和职责清单、问题清单、现状数据
- 核查依据
- 实际材料、系统记录、办理时间和错误样例
- 02先问清楚
明确对象和规则
这项工作要核对什么，按什么标准判断？
与业务人员确认对象、版本、关系、办理条件、例外情况和审批权限。
- 形成材料
- 对象说明、规则清单、权限和审批要求
- 核查依据
- 业务负责人确认记录、争议问题及处理意见
- 03先问清楚
配置并试运行
系统能处理到哪一步？
接入所需资料和工具，安排自动检查、人工确认及异常转交，用实际样例试运行。
- 形成材料
- 可试用流程、人员分工、结果模板
- 核查依据
- 执行记录、工具调用、审批记录和交付结果
- 04先问清楚
验收后逐步扩展
结果是否准确，工作量是否减少？
用已确认的案例检查质量、效率和风险。问题修正后，再扩大使用范围。
- 形成材料
- 验收结果、问题清单、后续改进计划
- 核查依据
- 通过率、人工接管情况、耗时和业务人员反馈
验收结果，也核查过程
业务人员能否复核结论，系统有没有越权操作，出错后能否查清原因，都应列入验收。
材料和依据
检查对象、版本和来源是否正确；结论应能找到对应的原始材料。
- 用语一致
- 材料齐全
- 出处可查
办理质量
用真实样例和特殊情况测试，比较系统结果与专业人员的复核意见。
- 样例通过率
- 人工复核差异
- 特殊情况
权限和审批
核对工具权限、人工审批节点、异常拦截和敏感信息处理。
- 授权范围
- 人工批准
- 异常拦截
运行情况
记录处理时间、费用、错误和人工接管情况，变更规则时保留版本。
- 处理记录
- 错误原因
- 版本变化
业务本体常见问题
把常见疑问说清楚
01企业业务本体是什么？
它是对一项业务中“有什么、彼此有什么关系、按什么规则处理、谁能决定”的明确约定。比如合同审查，要先说明合同与附件属于哪个版本，再规定哪些情况应暂停、哪些意见须由人确认。
02业务本体和知识图谱有什么区别？
知识图谱侧重记录对象之间的关系。业务本体还需要说明业务规则、办理状态和操作权限。项目需要查询复杂关系时，可以使用知识图谱，但不必把两者当作同一件事。
03已经能用 RAG 查资料，还需要本体吗？
RAG 能找相关材料，但不会自动判断材料是否属于同一版本，也不会替企业决定审批责任。遇到这类问题，应把版本、规则和权限另行明确。
04是否要一次建好全公司的业务本体？
不需要。先选一项具体业务，整理必需的对象和规则，用实际任务验证；有效后再逐步扩展。
05DesireCore 有独立的本体引擎吗？
本页介绍的是实施方法，不是独立本体引擎。DesireCore 用 AgentFS、知识、Skills、Workflow、多智能体协作和权限控制来管理相关资料与流程。具体功能以当前版本和项目方案为准。
06FDE 在项目中负责什么？
FDE 与业务人员一起核对流程、材料和规则，再把这些要求落实到系统配置和试运行中。能否扩大使用范围，要看实际测试结果。
查看实例和参考资料
产品文档和实践文章说明 DesireCore 的相关做法；外部资料用于解释本体方法，不代表产品合作或从属关系。
