就着 Agent，再谈语义层

我之前写过一篇[《就着本体论，再谈语义层》，试图跳出概念本身，来讲一讲对语义建模的一点看法。但我发现由于那篇文章本身就是被“本论论”、“语义层”这些概念所束缚的，所以并不能独立地表达我的想法，因此我想借这篇文章来相对独立地分享一些我的思考和看法，希望能够对客户对行业有帮助。

以终为始，在 Agent 的框架里明确语义层的定位和价值

最近大家关注和讨论“本体论”和“语义层”，更多是被 AI 的热度带动，最主要的出发点是如何让 Agent 在企业落地。因此我想先从 Agent 作为企业数字员工这一价值出发，看看 Agent 的体系构成和语义层在其中的定位和价值。

我们先试着思考一个问题“一个工作 5 年的老员工，跟一个刚上岗的新员工有什么区别？”，是老员工变得更聪明了，效率更高了，还是更懂事了？

我认为老员工相比新员工的主要差别可以概括成以下 5 点：

• 更懂业务，老员工更了解业务，清楚企业的产品，知道业务概念，能够听得懂内部术语，明白数据口径，……

• 更有经验，老员工会有业务直觉，知道哪些地方会更容易出事，知道业务波动背后的可能原因会有哪些，遇到问题解决问题的效率会更高，……

• 更会协作，老员工会融入组织，知道决策链，遇到事情该找哪个部门，该找谁拍板，该走什么样内部系统，该走什么样的流程，……

• 会有记忆，老员工天然会拥有“组织记忆”，知道同事的工作偏好，了解公司的历史沿袭和关键事件，记得某个决策和它的业务影响，……

• 会有价值观，老员工理解组织边界，会更有纪律性，知道哪些事情可以做，哪些事情不能做，红线在哪里，灰度在哪里，会养成群体认同的工作习惯，……

企业落到 Agent 上，自然也是同一个判断标准，要求 Agent 要像老员工一样可以独立完成工作，这个对应关系如下：

可以发现这样的分析和映射并没有突破一个典型的 Agent 框架，而这也正是我恰恰想要表达的：

• 语义层的本质并不是“数据翻译官”，而是企业自己的“世界模型”，它的核心价值是让人与人、人与 Agent、Agent 与 Agent 之间能够在企业统一的业务语境下协同工作。

• 语义层本身不具备行动能力，需要跟 Skills 、Tools 和其他 Agent 模块一起才能具备完成工作的能力。

衍生出来，可以推导出的几个判断：

• 业务系统会提供 API、CLI 和 MCP 协议，以及它们的操作语义，这些会被封装成不同的 Tools。因此如何操作业务系统的知识大概率不需要在语义层管理。

• 如何使用 Tools，是在具体的业务场景里才能被定义的，而这个具体的业务场景的最佳实践大概率是需要被蒸馏成 Skill 的，因此关于场景的最佳实践和如何使用 Tools 的知识也不需要沉淀到语义层。

• 如何正确地使用 Skills 和 Tools，这是交给 Agent 动态规划的，这部分知识，语义层也做不到提前固化，因为但凡能固化的，可以参看上一条，已经被 Skill 化了。

这是从 Agent 视角来推导语义层里会没有什么，那么语义层里应该有什么？从语义层的视角，Agent 的挑战又在哪里？

实践出真知，看语义如何分层，又如何与 Agent 协同进化。

从语义建模的视角，通常企业语义可以分成不同层次，以下是一个四层分层模型：

• 第一层是数据语义：表、字段、关系、主键、口径说明、业务术语映射。它解决的是“数据是什么意思”。

• 第二层是指标语义：指标定义、统计周期、业务限定、维度、衍生计算、权限、血缘、复用和服务化。它解决的是“业务如何一致地衡量”。

• 第三层是对象语义：客户、订单、设备、门店、商品、合同、人员等业务对象及其关系。它解决的是“企业如何描述真实世界”。

• 第四层是行动语义：在某个对象状态下，谁可以执行什么动作，触发什么流程，写回哪个系统，如何审计和回滚。它解决的是“企业如何被改变”。

从四层语义模型出发，Aloudata CAN 基于实体和维度建模的方法，主要覆盖的是第一层、第二层和第三层的一部分。Palantir 的“本体论”（ Ontology ）主要覆盖的是第三层和第四层，它的 Foundry 平台通过数据工程的方法来获取数据和指标，算是覆盖了第一层和第二层。

结合上文，这里产生了两个冲突点：

• Agent 框架下的语义层没有第四层的行动语义，这层行动语义主要是通过封装业务系统提供的 API、CLI 形成 Tools 和 Skills 实现的，这种实现方法能否满足企业级 Agent 的要求？

• Palantir “本体论”的最大优势是在第四层行动语义上，而这种实现第四层行动语义的方法跟上文的 Agent 框架有冲突，“本体论”是实现企业级 Agent 的必要条件吗？

Palantir 的“本体论”诞生在前 AI 时代，那个时代没有 LLM，没有 Agent，系统的用户是人类，主要是 Palantir 自己的 FDE。“本体论”的核心价值是为 FDE 现场实施提供平台能力配套。

Palantir 的 FDE 一方面整理和定义第三层和第四层的语义模型，另一方面又以 Logic 的方式封装业务逻辑，并最后完成业务场景的工程化确定性交付。

到这里，我们又会面临两个问题：

如果把 Agent 类比成 FDE，完成业务场景的确定性交付又该如何实现？

我们现在正处于 AI 时代，AI 能力在快速提升，Agent 架构实践日新月异，这里面至少存在两个新的价值变量：

• 通过 Tools 和 Skills 的结合，可以快速完成业务系统操作指令的封装。这种打通业务流的方式比传统定制化开发的方法灵活度更好、效率更高、成本更低。

• Agent 具备任务动态规划能力，与 Tools 和 Skills 的结合，会带来解决业务问题的涌现能力，而这才是 Agent 作为数字员工该有的样子，才能最大化地释放 AI 价值。

那么，Agent 的价值履约是否一定必须依赖“本体论”这种重平台、重建模、重实施的方法才可以实现？这种依赖会不会极大地限制了 AI 在企业的普及率？

如果消除模型幻觉的方法不是助力大模型，而是“阉割”大模型的能力，这种方法本身会不会被大模型进化和新的 Agent 实践吞噬掉？

当“本体论”与“AI 原生论”冲突的时候，我们又将如何平衡和抉择呢？

我必须承认，Agent 进入企业实际业务场景的过程会产生哪些挑战，比如 Agent 在任务推理时如何保证操作的确定性，是将架构目标放在如何保证一次做对上（依赖强的行动语义），还是放在 Skills 和 Tools 操作的幂等性上，还是两者要兼顾，我们并没有先验知识，更说不好哪天我们突破了语义自动建模，现有的重建模方式变得不再是问题了呢。

此外，现实中，企业内部有大量场景并不会要求回写业务数据，比如数据分析场景，需要回写数据的部分场景存在灰度空间，比如调补货场景。在这些场景上，Agent 上岗更容易，企业是否可以先行先试呢。

在不确定性的世界中寻找确定性，有一点是确定的，那就是“认知要从实践中来”。在这个认知以周以月迭代的时代，我们更加需要避免“本本主义”，要保持独立思考，清楚意识到认知要从实践中来，只能实践、认识、再实践、再认识才是 AI 时代企业语义层最务实的进化方式。

说不定 Palantir 自己就在 AIP 的实践中也在完成“本体论”的进化呢？！

知易行难，Aloudata 实践：语义层的难，难在哪里？

Aloudata CAN 作为国内领先的语义层产品，获得了很多行业头部客户的认可，比如麦当劳中国、平安证券、名创优品、顺丰、Lululemon 等。这批客户都深度认同语义层的价值，从而几乎 100%都有过尝试自研指标管理平台，其中有 20% 的客户尝试重度自研过“管研用”一体化的指标平台。

那么客户为什么会放弃自研而选择我们呢？

首要的原因是自研的指标平台用不起来

每家企业都会有指标口径管理的需求，为此研发指标管理平台。但因为只能做数据口径的登记维护，无法自动生成指标代码和灵活维度分析，导致业务没有动力使用，技术无法持续口径保鲜，自然就荒废用不起来。

不难发现，语义层建设一开始就要坚持“以用促治”，边用边治。

其次的原因是自研的指标平台用起来后，遇上了技术难题，自研变得不可控，外采的确定性更高

我们拿最容易理解的电商场景举个例子说明一下这个问题。

在电商业务场景下，企业通常会对商品、门店、订单、会员、物流、库存等做运营管理：

• 为了评估和优化运营效率和质量，会有相关的业务指标，比如商品数、门店数、订单笔数、订单金额等指标；

• 为了反应这些指标在时间维度上的变化，会有当日、当周、当月、当季、当年等时间衍生指标；

• 为了反应业务运营动作在关键指标上的变化，评估运营效果，会做复杂的运营分析。比如统计当月新增会员在当月、未来 3 个月的订单量，这就涉及指标与指标之间的关联、叠加计算，背后是跨多个对象主体的连续计算，比如类似这种统计分析：过去三个月连续每月订单金额超过 2000 元的会员所购买的前十个商品，以及这些商品在过去三个月在不同渠道的订单金额和同比增长率。

• 随着更多业务场景和业务人员的使用，对平台稳定性和查询性能提出要求，比如我们有客户一天的指标平台的查询调用量超过 500 万次。

如果语义平台一开始就没有为这种业务深度使用做好架构设计、技术预演和团队储备，那么自然就会在业务使用的过程中遇到无法响应业务需求的情况，造成“吃力不讨好”的局面。

而一个好的语义平台，需要满足以下 3 点：

• 凡数皆能定（管）：能够支持上述任意复杂对象关系和任意复杂业务运营指标的定义；

• 能定就能跑（研）：能够支持上述定义在任意数据量下的复杂计算，比如千亿级别的订单跟上亿级别的会员之间的关联计算；

• 能定就能查（用）：需要提供 API/CLI，支持下游 BI 工具、业务系统、Agents 对接语义平台，实现语义一致的灵活查询。

在真实的企业环境里，要实现上述 3 点，通常会带来这些衍生要求，而这些衍生要求往往在起初会被忽视：

• 需要能够复用企业现有的计算存储资源，这就需要语义引擎能够适配企业内不同的数据库，语义引擎要能够自动将复杂的指标定义翻译成性能良好的不同数据库的查询语句。

• 需要能够支持多引擎的混合计算，将一个复杂的大数据量的指标计算按需拆解成多段的连续计算，并分配不同的计算段给不同的引擎来执行，以达到性能、成本、时效的最佳平衡，而这个最佳平衡不仅需要尽可能地在上百上千万的指标计算里找到全局最优，也需要在某些特殊的场景下只为某个或某些指标计算提供特殊的计算通道，比如给管理层看的报表要优先保证计算优先级。

• 需要能够支持计算的多集群路由，为了满足不同场景的高可用要求，需要能够将计算资源分组，并支持计算的自动路由和切换。

• 需要能够实时监控和预警系统运行情况，当出现系统问题的时候，可以主动告警、自动恢复等。

• ……

要实现上述语义平台的能力，通常需要这个团队具备：

• 在 DW 和 BI 领域长时间工作过，非常熟悉数据分析场景里的各种细节；

• 处理过单表至少千亿级数据量下的复杂查询的性能优化问题；

• 并在过往工作中实际研究和应用过数据虚假化和数据语义化等相关技术，至少在这些方向上掉进过“坑”里、“井”里至少 3-5 次，并每次都能爬出来；

• 需要把这帮人聚在一起，将他们超过十年的经验和思考，安安心心地花上 3 年的时间写出上百万的代码；

• 并找到愿意相信他们的天使客户，陪着他们每周发布一个版本的方式，连续工作 12 个月逐步把系统打磨好，完成全量数据的上线和切换。

• 然后再将这个过程复制到第 2 个、第 3 个客户上，以便可以覆盖更多的数据库类型和业务场景，以达到企业级软件的品质要求。这个“产能爬坡”的过程，通常需要通关至少 10 个以上的大客户才可以完成。

• ……

很荣幸（成就感很强），也很不幸（过程太苦了），Aloudata 就是这样的团队，我们遇到了足够多对的客户，陪我们走过了“产能爬坡”的过程，……（此处省略 1000 字）。

今天，我们处在“AI 刚进入企业”的早期阶段，

有人相信前人实践，有人相信前沿方向；

有人强调 workflow 的确定性，有人强调 Agent 的自主性；

有人相信后发先至，有人相信先发制人；

……。

今天，行业开始认同语义层作为“企业世界模型”的价值，但对语义层的边界、与 Agent 的协同方案等没有标准答案。

今天，我跟大家分享我对语义层、本体论和 Agent 的思考，我已经有自己的判断，期待我们实践之后再跟大家分享我们的新认知。