我以前看 Ontology，脑子里想的其实还是数据结构。
无非是把企业里的客户、产品、市场、营销活动这些东西定义出来，再把字段和关系接好。比普通 schema 多一层语义，方便系统知道“这个东西是什么”“它和那个东西有什么关系”。
后来我发现，如果只是这样理解，还是太浅了。
真正让我重新看 Ontology，是因为 Agent 的路径开始不再由人提前写好。
如果给 Agent 的是一个明确任务，比如“分析这份客户反馈”，问题其实没那么复杂。任务边界已经有人定好了，它只是去完成。
但如果给的是一个业务目标，比如“把某个市场的有效销售线索提高 30%”，情况就完全不一样了。这个目标没有告诉 Agent 应该先研究市场、先看 CRM、先重新做人群细分，还是先检查过去的营销活动。它要自己判断现在的问题在哪里，再决定下一步做什么。做了一段时间以后，新数据进来，它还可能发现前面的判断不对，重新换一个方向。
以前的软件，很多时候是人先把业务拆成流程，系统再沿着流程执行。A 没完成就进不了 B，因为代码里根本没有这条路。Agent 开始自己规划以后，这种保证就没那么直接了，你很难提前把它所有可能的路径都写出来。
当然，也可以继续加 Workflow，把每一种情况都变成分支。但如果最后还是把所有路径写死，Agent 本质上又回到了流程引擎。
所以我现在更关心的是另一个问题：
如果路径不再完整地由人定义，那还有什么应该提前定义？
这里 Ontology 就开始变得重要。
一个围绕增长目标工作的 Agent，当然需要 CRM、研究报告、销售记录、历史营销活动、产品信息这些数据，但这些数据本身还不够。
它还得知道哪个营销活动面向哪类人群，这个人群为什么会被选出来，这次实验在验证什么假设，什么指标可以说明这个假设成立，这个假设最后又和哪个业务目标有关。
如果这些关系没有被明确表示出来，系统接再多数据，本质上也只是让 Agent 看到更多信息。
比如：
营销活动 → 面向 → 细分人群
实验 → 验证 → 假设
指标 → 衡量 → 实验
假设 → 对应 → 业务目标这也是为什么 Graph 经常和 Ontology 一起出现。企业里的很多上下文本来就不是一张表的问题，而是关系的问题。
一份营销活动报告本身只是一个文档。对 Agent 真正有意义的是：这次活动是为谁做的，为什么做，在验证什么，结果怎么样，以及它和当前业务目标之间是什么关系。
但只到这里还不够。
Agent 不只是读取这个世界，它还会改变这个世界。
它会提出新的假设，创建新的实验，修改营销活动，调整预算，也会根据新的证据推翻之前的判断。
所以除了对象和关系，还要定义状态和动作。
比如一个假设可能有这些状态：
待验证
验证中
已验证
已推翻一个实验也可能有：
待批准
运行中
已结束
无效然后系统还要知道哪些状态之间可以转换，以及什么动作会触发这些变化。
比如：
start_experiment()
update_hypothesis_status()
increase_budget()
invalidate_hypothesis()这里重要的不是函数名字，而是这些动作发生以后，业务状态会被改变。
如果 Agent 想把一个假设从“验证中”改成“已验证”，系统要知道这个变化是不是允许的。
是不是已经有足够证据？
实验有没有跑完？
观察周期够不够？
证据来源是不是符合要求？
这些都可以被提前定义。
到这里，Ontology 就已经不只是“知识怎么组织”了，它开始直接影响 Agent 运行时什么可以发生。
Guardrail 也会自然接进来。
比如我规定：
一个假设没有足够证据，就不能进入“已验证”状态。
这句话当然可以写在 Prompt 里，但如果这件事情真的重要，我不会希望最后靠模型自己记得。系统可以直接在状态变化的时候检查：
证据不足
→ 不允许进入“已验证”预算调整也是一样：
预算增加超过 20%
且没有审批
→ 拒绝执行这里其实没有什么特别新的 AI 技术。普通代码、权限系统、规则、策略、状态机都可以做。
Agent 出现以后，这些东西反而又重要起来了，因为 Agent 会自己决定下一步做什么，但系统还是可以明确规定哪些状态允许出现，哪些动作允许执行。
再往后，事情会复杂一点。
假设一个 Agent 可以调用几十个工具，一个目标持续几周甚至几个月，中间不断产生新的对象，也不断修改状态。
这时候你给每个动作单独加检查，不代表整个系统就一定没有问题。
比如有一条规则：
没有足够证据，假设不能进入“已验证”。
Agent 可能从来没有直接违反这条规则，但它可能走出这样一条路径：
生成一个洞察
→ 根据洞察修改人群定义
→ 创建一个新实验
→ 读取实验中间指标
→ 把中间指标登记成新的证据
→ 假设进入“已验证”如果每一步单独看都合法，局部检查可能全部通过。
但最后这个结果仍然可能违反另一个更高层的规则：
实验没有完成完整观察周期之前，不能用来验证这个假设。
这时候问题已经不是“这一条 if 写对了吗”，而是：
有没有任何一条系统允许的执行路径，最后会进入一个不应该出现的状态？
这就是形式化验证开始有意义的地方。
形式化方法通常会先定义一些无论系统怎么执行都必须成立的条件，比如：
Hypothesis.status = 已验证
→ 必须存在满足要求的 Evidence或者：
BudgetIncrease > 20%
→ 必须存在 Approval这些条件一般叫 invariant，不变量。
然后再去检查系统里的状态和动作可以怎样组合，是否存在一条路径会破坏这些不变量。Model Checking 做的就是这类事情：把状态和状态变化建出来，再去找有没有一条路径最终走到不允许出现的状态。
普通测试更像是在问：
我想到的这些情况有没有问题？
形式化验证更接近：
有没有一种我没想到的执行方式，也能把系统带到错误状态？
当然，大部分 Agent 系统没有必要一上来就用 TLA+、Alloy 或 theorem prover。很多规则写代码就够了。
但当系统里的状态、动作和组合路径越来越多以后，形式化方法会开始有价值，因为它处理的已经不是单个动作，而是整个状态空间。
我以前有个说法是，Ontology 的边界就是形式化验证的边界。
严格说，这句话不够准确。形式化验证不只是需要 Ontology，还需要把状态变化、动作和约束一起定义出来。
但这个方向我还是认同。
一个东西如果没有被明确表示出来，系统就很难严格检查它。你能把业务里的对象、关系、状态、动作和约束定义到什么程度，后面才有可能验证到什么程度。
这里还有一件事我觉得挺有意思。
过去几年大家一直在看大模型，很多更早的东西很少被提了。Symbolic AI、知识表示、Formal Methods，甚至 Model Checking，听起来都有点“老”。
但 Agent 真开始执行事情以后，它们又重新有用了。
不是因为 LLM 最后不行，也不是因为专家系统又赢了。它们做的事情本来就不一样。
LLM 适合处理那些很难提前写死的部分：现在的问题是什么，应该先做什么，有没有新的假设，原来的方向还要不要继续。
而有些事情其实没必要再让模型判断。
什么对象存在，什么关系成立，什么状态可以进入，什么动作需要审批，哪些条件必须满足，这些都可以提前定义。
我现在再看 Ontology，大概会把它放在这个位置。
它不是替 Agent 决定路径，而是在路径不固定以后，把 Agent 要运行的环境定义清楚。以前软件里的很多确定性来自流程本身，现在路径开始由 Agent 动态生成，系统就得把其中一部分确定性放到对象、状态、动作和约束上。