企业业务本体与AI落地
内容提要
本文探讨企业业务本体在AI落地中的实践，强调先明确处理对象再谈方法。通过DesireCore合同审查案例，指出多Agent协作需固定对象、版本和交接内容，用文件保存本体，固化规则阻断错误，回执记录证据。建议从历史任务起步，测试缺件场景，避免过度建模，聚焦跨系统、规则多的高风险工作。
延伸解读
提示词修不了业务数据问题
文章指出，当多个Agent处理同一份合同时，如果对象、版本和附件范围没有明确，即使每个Agent的输出都正确，整条业务链仍可能出错。作者强调，用提示词不断补充检查规则，不如先冻结输入，确保所有Agent处理的是同一个对象。这提醒我们，在AI落地中，业务数据的规范化和一致性比模型能力更关键。
本体文件化：让业务人员看得懂
作者建议用简单的文件（如YAML、Markdown）来保存业务本体，而不是一开始就引入OWL、RDF等复杂建模工具。这样业务人员能直接查看和审阅规则，改动时能看到差异，出错时能回滚。这种轻量级做法降低了技术门槛，更利于项目落地，也避免了过度建模带来的技术债。
多Agent协作的关键在交接
文章强调，多Agent拆得越细，交接出错的机会越多。在DesireCore中，交接时固定审查对象、附件集合、已确认事项、待确认事项、任务和输出要求，能有效减少错误。作者认为角色数量不重要，重要的是交接时是否把对象说清楚。这提示我们在设计多Agent系统时，应注重交接的规范性和明确性。
该停就停：固化步骤阻断错误
作者指出，模型擅长把不完整信息整理成流畅文字，这在摘要中是优点，但在合同审查等场景中可能掩盖问题。因此，DesireCore将版本一致性、字段完整性等检查用固化步骤处理，不满足条件直接阻断，并设置Human Gate控制高风险动作。这种设计避免了模型“一边交卷一边盖章”的风险，确保业务正确性。
Q&A
企业业务本体在AI落地中指的是什么？
企业业务本体在AI落地中指的是先让系统明确知道自己正在处理什么对象（如合同、标书、工程图），包括对象的编号、版本、状态、附件范围等，再谈如何处理。它强调用文件保存对象、关系、规则和动作，并固化规则以阻断错误。
DesireCore合同审查案例中，多Agent协作出现的主要问题是什么？
主要问题是多个Agent口中的“这份合同”不是同一个东西，例如主合同已更新但附件仍为旧版，导致单个Agent输出正常但整体业务链错误。这属于业务数据问题，而非模型能力问题。
在DesireCore中，业务本体是如何用文件形式保存的？
DesireCore利用AgentFS文件系统，将业务本体保存为可审阅、可Diff、可回滚的文件，例如contract.yaml（合同信息）、relations.yaml（关系）、rules.md（规则）、actions.yaml（动作）和test-cases（测试样本）。这些文件是项目约定，非强制格式。
多Agent协作时，交接应该固定哪些内容？
交接时应固定审查对象（如合同版本）、附件集合、已确认信息（如角色、适用法域）、待确认事项、本次任务和输出要求。这样能确保每个Agent处理的是同一对象，减少交接错误。
在DesireCore中，如何确保Agent在必要时停下来？
通过Workflow将步骤分开：模型负责条款理解等灵活部分，固化步骤检查版本一致性、字段完整性、权限等，不满足条件则阻断。高风险动作（如修改合同）需进入Human Gate，且权限按执行方计算，防止越权。
DesireCore的回执系统有什么作用？
回执系统记录任务输入、工具调用、检索轨迹、步骤类型、风险和回滚点，并包含使用的对象版本、规则版本和证据位置。它用于追溯具体问题，如审的是哪版合同、用了哪套规则、证据在哪，以及规则变化后的回放和差异分析。
启动业务本体项目时，建议从哪些步骤开始？
建议从以下步骤开始：找一条发生过返工或争议的历史任务，整理输入和结果；写下最少的一组对象和版本，明确负责人；将提取、判断、复核分开，交接时只传确认的事实；对修改文件等动作加权限和Human Gate；故意制造缺文件、错版本等测试，检查回执能否说明停止原因。
哪些类型的任务适合用业务本体和复杂Agent流程？
适合跨系统、规则多、出错后麻烦且需要追责和证据的工作，如合同审查、招投标和工程校核。低风险草稿、简单查询等任务用普通Skill或Workflow即可，不必过度建模。
