演示永远成功的 AI Agent，为什么上线就出错？本体论做执行前校验

核心洞察

这篇文章最戳我的地方是它点破了一个大家心知肚明但很少明说的事：agent 演示之所以永远成功，是因为演示里根本没有真实世界的约束。作者提出的方案不新鲜，本体论一种形式化的、机器可读的领域知识表示，定义了领域中存在的概念、属性及其关系，可用于约束和验证AI智能体的行为。这东西在语义网圈子里存在二十多年了，但他把它放在 agent 动作执行前当校验层这个思路，确实比写更长的 prompt 靠谱得多。我唯一存疑的是落地成本，建模一个业务域到底要花多少人天，文中没给答案。

核心结论

1. Agent 演示之所以永远成功，是因为演示环境中不存在真实世界的业务约束，上线后才会暴露退款给未送达订单、退款金额超过订单总额、给无下属的“经理”批报销等失败。

2. 写更长的系统提示词只是“建议”，当提示词涨到四千个 token 时，关键规则要与另外四十条争夺模型注意力；本体论则是对业务域中什么可以存在、如何关联的正式且机器可读的声明，可机械校验、毫秒级完成。

3. 核心模式是“模型负责提议，本体论负责裁决”：agent 将动作作为结构化数据提出，由 pySHACL一个Python实现的SHACL验证器，用于检查RDF数据是否符合SHACL形状。 等校验器对照 SHACLShapes Constraint Language，W3C标准，用于定义和验证RDF图数据的形状约束，可表达业务规则。 shapes 检查，通过则执行，不通过则将具体校验报告（哪个 shape、哪个字段、人写的提示信息）回传给 agent 供其纠正或升级人工。

4. 一份本体论产物可同时承担三份工作：生成 agent 的工具描述和实体定义（几百个 token 而非几千个）、作为声明式且可在 git 中版本化的确定性护栏、以及将每次拒绝转化为带标签的失败样本用于评测。

5. 落地成本真实存在——需要有人建模业务域，但建议从单个高风险 agent 动作（如退款、删记录、对外发邮件）开始，为其写三个 shape，在工具调用前接入校验器并记录一周拒绝情况。

没人演示的那种失败

agent 的演示永远顺利。客户要求退款，agent 调对了工具，钱就退出去了。然后上线了，一周后它给一个根本没送达的订单退了款。或者退款金额比订单金额还大。或者给一个手下没有任何人的“经理”批了报销。

这些都不是推理出了问题。模型的推理没毛病。它只是基于一个在你的业务里根本不成立的前提在行动，因为系统里没有任何东西告诉它什么才是成立的。

prompt 是建议，本体论是定义

常见的修法是写更长的系统提示词：退款金额不得超过订单总额；只给已送达的订单退款。这有用，直到提示词涨到四千个 token，你在意的那条规则要跟另外四十条争夺模型的注意力。prompt 本质上是建议。模型大部分时候会听。

本体论是另一种东西。它是对你的业务域里什么东西可以存在、彼此怎么关联的正式且机器可读的声明：一个订单恰好对应一个客户，一笔退款恰好指向一个订单，一个经理至少有一个直接下属。它不请求模型好好表现。它定义了模型被允许在其中行动的世界，而且可以机械校验，每次都是，毫秒级完成。

模式很简单：模型负责提议，本体论负责裁决。agent 在怎么理解请求上保持灵活。它失去的，是做出违背业务域规则的动作的自由。

一条你能读懂的护栏

这件事的 W3C 标准叫 SHACL。下面这条退款规则写成一个 shape 长这样：

ex:RefundShape a sh:NodeShape ;
    sh:targetClass ex:Refund ;
    sh:property [
        sh:path ex:forOrder ;
        sh:class ex:DeliveredOrder ;
        sh:minCount 1 ; sh:maxCount 1 ;
        sh:message "退款必须指向恰好一个已送达订单。" ] ;
    sh:property [
        sh:path ex:amount ;
        sh:datatype xsd:decimal ;
        sh:minExclusive 0 ] .

“金额不能超过订单总额”这条规则再多写几行，作为同一个 shape 里的 SPARQL一种用于查询RDF图数据库的标准查询语言和协议，支持从知识图谱中检索和操作数据。 约束。注意这里谁能审阅这段东西。一个永远不会读你 Python 代码的合规专员，能读懂“退款必须指向恰好一个已送达订单”，然后告诉你这条对不对。

把环闭上

护栏卡在 agent 的决策和副作用之间：

1. agent 把动作作为结构化数据提出来（JSON-LDA lightweight Linked Data format for structuring data in JSON, recommended by Google for Schema.org implementation. 能干净地映射到图）。
2. pySHACL 这类校验器拿它对照 shapes 检查。不调模型，不烧 token。
3. 通过就执行。
4. 不通过就把校验报告作为工具结果回传给 agent：哪个 shape 没过，哪个字段，附上人写的提示信息。

最后一步很关键。“动作被拒绝”教不会 agent 任何东西。“退款必须指向恰好一个已送达订单；订单 8812 当前状态是已发货”才给了它可以推理的材料。实践中它要么自己纠正，要么升级给人工，这恰好就是你希望 prompt 能做到的行为。

过了演示阶段之后它能给你什么

一份产物干三份活，而这三份活团队通常是分开做的：

• 上下文。 用来校验动作的同一份本体论，可以生成 agent 的工具描述和实体定义。模型看到的业务域就是它真实的样子，几百个 token 而不是几千个。
• 护栏。 规则是声明式的、确定性的、在 git 里版本化的。改一条规则是一个经过评审的 diff，而不是谁周五随手改的 prompt。
• 评测。 每一次拒绝都是一个带标签的失败样本：shape、字段、时间戳。在测试集上按 shape 统计违规次数，你就精确知道 agent 在哪儿误解了你的业务域，而不是去读一个 LLM 裁判打出的十分制六分。

代价是真实的。得有人去建模这个业务域，这是慢工细活。但这些知识本来就存在于你的数据库 schema、你的政策文档、你资深员工的脑子里。本体论是这些东西不再靠口口相传的地方。

从哪儿开始

别一上来就建模整个企业。挑一个 agent 动作，那种一旦出错最疼的——退款、删记录、对外发邮件。给它写三个 shape。把校验器放在那一个工具调用前面，把每一笔拒绝记录一周。

你很快会知道两件事：你的 agent 有多少次差点做了你的业务域禁止的事，以及这些情况里有多少你的 prompt 其实早就“处理”过了。

---

Frank Coyle 博士在加州大学伯克利分校信息学院教授生成式 AI 和大语言模型，此前在南方卫理公会大学教了 32 年计算机科学。他早年在埃默里大学受训于神经解剖学和神经生理学，之后转向计算机科学。他在 AIE Code Summit 上做了题为“本体论作为护栏”的演讲。

常见问题（FAQ）

为什么AI智能体在演示里总是成功，上线后却会犯业务逻辑错误？

演示环境缺少真实业务约束，模型推理本身没问题，但它基于业务中不成立的前提行动。系统里没有东西告诉它什么才成立，于是会出现给未送达订单退款、退款超额等错误。

用本体论做护栏和写更长的prompt有什么区别？

prompt本质是建议，模型大部分时候会听，但规则一多就争夺注意力。本体论是机器可读的正式声明，定义业务域里什么可以存在、如何关联，可机械校验，毫秒级完成，不依赖模型自觉。

想给智能体加本体论护栏，应该从哪里开始落地？

别一上来建模整个企业。挑一个出错最疼的agent动作，比如退款、删记录或对外发邮件，给它写三个SHACL shape，把校验器放在该工具调用前，记录一周拒绝情况，就能看出风险规模。