企业业务本体与AI落地

它太容易把文章带进术语。对象、关系、状态、规则、动作、权限，挨个解释一遍，再画一张很完整的架构图，看着什么都有，业务人员读完还是不知道明天该改哪一步。

我真正开始关心本体，是因为 DesireCore 里的一次合同审查复盘。

主合同已经换成了新版本，附件还留在上一版。负责读条款的 Agent 没有读错，负责识别风险的 Agent 也确实按照拿到的内容执行了规则。最后的报告甚至挺完整。问题出在更前面：几个 Agent 口中的“这份合同”，根本不是同一个东西。

这件事比模型漏掉一个条款更麻烦。单个 Agent 的输出都说得通，放回整条业务链里却是错的。

先别急着怪模型

我们最早的修法是在提示词里加一句：“开始审查前，请严格确认文档版本和附件完整性。”

有用，但没有维持多久。

下一次的情况稍微变了一点。两份合同正文没有差异，附件编号换了，原来的检查就没有拦住。于是我们继续往提示词里补：检查主文档版本、附件编号、页码范围、签署状态、我方角色、适用法域……规则越写越长，真正出问题时仍然要翻聊天记录，确认每个 Agent 当时到底读到了什么。

我后来意识到，我们一直在用提示词修一个业务数据问题。

“合同”不能只是一段被塞进上下文的文字。它要有自己的编号、版本、状态和附件范围。条款属于哪一版，风险结论引用哪一页，法务确认的是哪次审查，也要跟着这个对象走。

这就是我现在理解的业务本体。说得简单一点，就是先让系统知道自己在处理什么，再谈怎么处理。

在 DesireCore 的合同审查流程里，我们先冻结输入。主合同、附件清单、页码范围、角色和法域任何一项对不上，任务先停住。后面的 Agent 不会拿到一份“可能不完整但先审着看”的材料。

这个改动没让模型变聪明，却挡住了一类很难在报告末尾补救的错误。

在 DesireCore 里，本体先是几份能看懂的文件

说实话，我不想一上来就要求项目组学习 OWL、RDF 和一套新的建模工具。很多项目还没证明这件事值得做，先背上一层技术债没有意义。

DesireCore 已经有 AgentFS。智能体的原则、记忆、Skill、Workflow 和工具配置本来就是文件，可以审阅，可以做 Diff，也能回滚。业务本体的第一版完全可以用同样的办法保存。

比如合同审查项目里，我会先放这几类内容：

resources/business-ontology/
├── contract.yaml       # 当前合同、版本、状态和来源
├── relations.yaml      # 合同、附件、条款、主体之间的关系
├── rules.md            # 企业规则、法域规则和例外
├── actions.yaml        # 可以执行的动作及前置条件
└── test-cases/         # 曾经出错的样本

这个目录只是项目约定，不是 DesireCore 强制的格式。小项目甚至不必拆成这么多文件。能把版本、来源和负责人写清楚，比目录漂不漂亮重要。

AgentFS 也不等于本体引擎。文件放进去以后，如果 Workflow 从来不读，规则失败也不会阻断动作，它仍然只是一份资料。我们会在任务开始时加载与当前对象有关的那一小部分，审查完成后把用过的版本写进回执。

我很喜欢文件还有一个原因：业务人员能看。

“销售额是否含税”“这条规则由谁确认”“附件缺失时能不能继续”都不应该藏在一段只有模型看过的系统提示里。它们被改动时，需要有人看到差异。改错了，也要能退回去。

多 Agent 拆得越开，交接越要硬

单个 Agent 做合同审查，最明显的问题是它既读、又判、又检查自己的答案。拆成多个角色以后，复核会好一些，但也多了交接出错的机会。

DesireCore 在智能体之间传递的是结构化任务交接，不会简单复制整段历史对话。我们会在交接里固定几项内容：

审查对象：contract-v3
附件集合：attachments-v3
已确认：我方为买方，适用中国法
待确认：附件二缺少签署页
本次任务：提取付款与解除条款
输出要求：条款号、页码、原文、判断状态

输入治理 Agent 先把对象和版本管住。条款 Agent 只做结构化提取，风险 Agent 根据规则给出判断，复核 Agent 使用独立上下文检查前面的结果。最后再由报告 Agent 整理成交付物。

职责不需要拆得特别细。合同短、风险也低时，一个 Agent 加一次独立复核就够了。为了体现“多 Agent”而创建十几个角色，只会让交接单比合同还长。

同样的做法也用在标书和工程图里。

标书中的对象不是一篇长文，而是招标条款、评分点、企业材料和响应章节。读标 Agent 找到一条评分要求后，要把它和证据材料连起来，写作 Agent 才能继续。没有材料就标记待补，不能写一句“公司拥有丰富经验”把空位盖过去。

工程图更明显。图页、坐标、设备、管线和跨页连接都要有身份。识别 Agent 给出候选，拓扑 Agent 恢复关系，校核 Agent 对照冻结后的设计资料检查。图纸版本换了，旧结论就不能继续沿用。

这些项目让我改变了对多 Agent 的看法。角色数量没那么重要，交接时有没有把对象说清楚，重要得多。

该停的时候，Agent 要真的停下来

只让 Agent “注意风险”，通常不够。

模型很擅长把不完整的信息整理成一段顺畅文字。这在写摘要时是优点，到了合同、标书和工程校核里，有时反而危险。附件少了一份，它可能一边提示证据不足，一边继续给出完整结论。人看到一份格式齐全的报告，很容易忽略前面那句保留意见。

DesireCore 的 Workflow 里，我会把步骤分开处理。

条款理解、候选关系和说明文字可以交给模型。版本一致性、字段完整性、权限和审批条件则用固化步骤检查。主合同和附件版本对不上，直接阻断；条款有结论却没有页码，退回补证据；涉及付款、重大责任或最终签署，进入 Human Gate。

“写出修改建议”和“修改原合同”也是两件事。前者可以生成草稿，后者会改变文件，需要看实际执行这个动作的 Agent 有没有写权限。DesireCore 按执行方自己的权限计算，委派任务不能帮另一个 Agent 扩权。

我不想让模型一边交卷，一边给自己盖一个“已合规”的章。

高风险动作多停一次，确实会慢。但合同发出去以后再发现版本错了，慢的就不止这一次确认。

回执不是任务结束时的一张小票

刚开始做 Agent 流程时，我觉得有日志就够了。出问题以后查调用记录，看看哪一步报错。

后来发现，命令成功不代表业务正确。某个 Agent 顺利读完文件、调用规则、生成报告，每一步都可能是成功状态，输入对象却从一开始就错了。

DesireCore 的回执会保留任务输入、工具调用、检索轨迹、步骤类型、风险和回滚点。接入业务本体以后，我们还会把本次使用的对象版本、规则版本和证据位置写进去。

这样再看一条风险结论时，可以回答几个很具体的问题：

• 它审的是哪一版合同；
• 用了哪一套规则；
• 证据在什么位置；
• 哪个 Agent 做了实际操作；
• 中间有没有经过人工确认。

如果回答不了这些问题，回执再长也只是运行日志。

规则后来发生变化，可以拿历史任务重新回放。我们不会因为新版本得出了不同结论就马上替换旧规则，先看差异来自哪里。也许旧规则确实漏了，也可能新规则误拦了正常情况。

有一次纠正很典型：附件版本不一致时，系统必须中止审查。它不该只留在那次对话里。复核人员确认以后，这条约束会变成 AgentFS 中的规则修改，经过 Diff 再生效。下一次遇到同类输入，系统不需要重新踩坑。

这部分才是“可培养 Agent”在企业项目里的实际价值。模型会换，业务吃过的亏最好别跟着一起清空。

业务本体不会从会议室里长出来

我见过最容易把本体项目做重的方法，是先收集全公司的术语、表结构和流程，准备建一个完整模型，再选择第一个应用场景。

通常会卡很久。

哪个系统是权威来源，两个部门可能就要讨论几周。范围继续扩大，最初想解决的问题反而看不见了。

我们现在更愿意从一条已经跑过的业务链开始。找一份完成过的合同审查，把当时的主合同、附件、最终报告和人工修改放在一起。让 DesireCore 重新跑一遍，再由法务逐条指出哪里判断对了，哪里误报，哪里应该停却没有停。

第一版只收合同、版本、附件、条款、风险和审批。够用就行。

标书项目可以从响应矩阵开始，不必先整理企业全部知识；工程图项目先选一套有明确设计资料和复核结果的图纸，也不要直接吞掉整个资料库。等一条链能重复跑，错误有地方回写，再扩到相邻对象。

测试时我会故意拿掉一份附件，换掉一个版本，给 Agent 一个越权动作。正常样本跑通只能说明演示没坏。输入不够时能不能拒绝，往往更能看出流程有没有做实。

还有一个不太技术的问题：得有人签字。

销售额到底含不含税，合同附件冲突时信哪一版，某条风险能不能接受，都要有业务负责人。长期没人确认的规则，我宁可先留成“未知”，也不让模型替组织做决定。

DesireCore 在这里做了什么

写到这里，DesireCore 和业务本体的关系其实已经很清楚了。

AgentFS 留住对象、规则和项目中学到的经验；多 Agent 把提取、判断和复核拆给不同角色；Workflow 决定哪些步骤可以灵活处理，哪些条件过不了就要停；Tool 和 MCP 连接真实系统；权限与 Human Gate 管住有副作用的动作；回执把当时发生的事情带回来。

这些能力组合起来，可以承接业务本体的实施。我们没有必要把它宣传成一个能自动理解所有企业数据的“万能本体引擎”。数据仍然要接，规则仍然要确认，Agent 的边界也要一条条测试。

有些任务不值得这样做。写一篇低风险草稿、查一张表、跑几个条件明确的步骤，一个 Skill 或普通 Workflow 已经足够。业务变化很快又没人维护时，本体文件只会多出一份过期得更隐蔽的资料。

真正适合的，是那些跨系统、规则多、出错以后麻烦，而且需要追到具体责任和证据的工作。合同、招投标和工程校核都属于这一类，所以我们才会在这些场景里投入。

我现在会先做这几步

如果要在 DesireCore 里启动一个新的业务本体项目，我不会先开一场术语会。通常从下面几件事开始：

1. 找一条发生过返工或争议的历史任务，把输入、人工结果和复盘材料放齐；
2. 写下这条链里最少的一组对象和版本，明确谁负责确认；
3. 把提取、判断、复核分开，交接时只传经过确认的事实和待办；
4. 给会修改文件、回写系统或对外发送的动作加上权限和 Human Gate；
5. 故意制造一次缺文件、错版本和越权，再检查回执能不能说明它为什么停下。

这几步做完，项目到底需不需要知识图谱、规则引擎或更正式的本体语言，通常会比一开始清楚得多。

我现在更关心的也不再是“我们有没有一套本体”。我会直接去看一次任务：几个 Agent 处理的是不是同一个对象；规则错了能不能找到；该停的地方有没有停；人改过以后，下次还会不会再犯。

这些问题有答案，业务本体才算真的进了 DesireCore。

参考资料