本体层比堆 Prompt 更能让 Agent 变薄

最近几个月，我翻资料时踩到同一个说法两次，两次都愣了一下：agent 规模化的瓶颈不在生成能力，卡在每个 agent 都要自己搞清楚去哪儿找数据、这份数据靠不靠谱。做企业记忆的创业者这么讲，做图数据库的公司也这么讲，两边不约而同用了同一个词，substrate，衬底。这场十分钟的分享，是后一种视角给出的工程版本。

分享来自 AI Engineer World’s Fair 2026 主舞台第四天（我们这个系列内部把这天记作 Day 3），讲者是 Neo4j 创始人兼 CEO Emil Eifrem。官方排期只给了 10 分钟（10:20-10:30am），是当天 18 场分享里唯一的 10 分钟档，其余基本都是 20 分钟。这场归在 Graphs 分会场，标题是《Thinner Agents on a Smarter Substrate: The Ontology-based Semantic Layer》。

原视频：https://www.youtube.com/watch?v=I2cbIws9j10（约 01:39:26 开始）

一个开账户 agent，放大到企业规模会碰上什么

Eifrem 用一个例子开场：假设你在一家大银行，要写一个 agent 自动化开户流程。这个 agent 拆开看是两块。一块是业务逻辑，理解意图、做计划、执行、循环；另一块是数据源，agent 要完成任务，得先接上对的数据。开户要验证身份，那就接车管所（DMV）的登记数据和护照核验服务这两个数据源。接上以后，这个 agent 跑得很好。

问题出在”再来一个 agent”。同一个组织里，别的团队也在写结构相似的 agent，每次都要重新从头找数据在哪。初创公司大概率只有一个 Postgres 数据库，这事不难。企业级环境里数据分布在上百个数据库，还有 Snowflake、Databricks，外加一堆 S3 桶，找数据本身就是一项工程。

找到数据源只是第一步，企业里同一份信息常有好几个副本。接下来还要判断这是不是对的版本、能不能信、有没有权限访问，这几件事没有捷径，只能一个个查。更麻烦的是维护。数据接入逻辑写死在每个 agent 的代码和 prompt 里。上游一旦有改动，所有相关 agent 都要手动重新接线，直接违反”不要重复自己”（DRY）这条软件工程的老规矩。最后一条问题最隐蔽：agent 之间没有共享学习渠道。今天这个 agent 学到什么数据源好用，这份经验没地方存，明天它醒来还是从零开始，别的 agent 更是完全学不到。

Eifrem 提前挡了一个显而易见的反驳。”用 Markdown 文件和 skill 不就解决了？”他的回答是部分解决，不是全部解决。他引了一句一周前 swyx 在 Latent Space 播客上说的话：你们得学会自己的数据库，不能光靠 Markdown 文件 vibe code。这句话放在这个场合格外应景。前一场”How Anthropic Builds: Lessons from Labs”正是 Mike Krieger 和 swyx 主讲，两场排在一起，10:00-10:20 和 10:20-10:30，中间只隔了几十秒。

三层语义层，把认知结构化进图里

Neo4j 过去六到九个月一直在给几个大客户解决这个问题，包括一家财富 20 强的全球银行、一家湾区的大型科技平台公司、一家头部金融科技公司。他们看到的模式是：让更薄的 agent 跑在更聪明的共享衬底上，这个衬底分三层。

第一层是面向业务的本体。本体听起来玄乎，核心概念其实很朴素：组织里有哪些关键概念，它们怎么关联。银行场景里就是客户、账户、借记卡、支票、交易这些东西，用组织里所有人都听得懂的名字表达。客户有个名字，不写成数据库字段名 f_name，写成业务人员都读得懂的”名字”。

第二层是技术本体，记录企业里所有数据源和数据资产的元信息：14 个 Oracle 数据库、15 个 Neo4j 数据库、Snowflake、Databricks、一堆 S3 桶，它们分别在哪、schema 长什么样。两层之间还有一张映射表，业务本体里客户的”名字”，对应技术本体里 Oracle 某张表的 f_name 字段。这张映射表才是整套方案要解决的核心问题。业务概念和物理存储之间那层翻译，以前靠每个开发者手动记。现在结构化进图里，查一次就能复用，不用每写一个新 agent 就翻一遍文档。

第三层是运行时信号。agent 在图上走一步、执行一次操作，都会留下痕迹：尝试了什么，成不成功，当时的上下文是什么。这些执行轨迹汇总成一个分数，反过来影响下一次决策。举个例子，某个 agent 在验证身份这一步，历史上用车管所数据源的成功率一直更高。同样场景下它下次就会优先选车管所，而不是护照核验。

回到开账户这个例子，Eifrem 展示的图里既有业务概念（支票、账户、信用记录），也有一个流程节点。这个 agent 被设计成要按规定流程走，流程本身也编码进了本体。图上有个”合规检查”节点，切到技术本体那一侧，能看到完成这项检查需要先核实一个政府颁发的身份证件。这家机构里刚好有两个数据源能做这件事。agent 执行到这一步，照着图走，两条路都能试，试完把结果记下来，喂给下一次决策。

三层放在一起，Eifrem 认为可以同时解决前面提到的四个问题。数据源发现变得容易，可信度由人工标注和执行轨迹共同验证。业务意图到数据源的映射只存一份，改一处全局生效。agent 有了自我学习的渠道，不止单个 agent 内部学习，跨 agent 之间也能共享经验。

这十分钟，摆在当天什么位置

这场分享官方只排了 10 分钟，是当天篇幅最短的一场。前一场是”How Anthropic Builds: Lessons from Labs”，Mike Krieger 和 swyx 主讲；紧接着的下一场叫”Tokens Should Have Jobs”，来自 Anthropic 的 Caitlyn Lesse 和 Angela Jiang。这两场加上当天大多数分享，归类都是 Harness Engineering，讨论的是怎么给 agent 搭执行层的脚手架。Eifrem 这场归在 Graphs 分会场，是当天少数几个从数据和知识表示层切入的分享。

这个位置有意思的地方在于，同一天稍晚还有 Michael Grinich 的”Auth for Agents: Unblock Autonomous AI with auth.md”，讲权限层怎么给 agent 放权。再往后是 Kay Malcolm 的”No Memory, No Harness: Why the Database Is the Last Line of Defense”，讲数据库作为最后一道防线。三场摆在一起看，正好是同一个大问题的三个切面：执行层管 agent 怎么做事，权限层管 agent 能做什么，Eifrem 这场管 agent 怎么知道数据在哪、该信谁。

延伸：substrate 这个词，两个不相关的信源都在用

延伸一点我自己的判断。Eifrem 这场用了”thin agents on a smarter shared substrate”这个说法。几个月前我读到过一篇讲企业 AI 记忆的文章，作者是 Sentra 的创始人，这家创业公司做的正是 agent 记忆。他的核心论点是，企业记忆需要 semantics（事实是什么）加 ontology（对谁意味着什么），同一份底层事实之上要能架多个视角。他们把底层叫 substrate，视角层叫 lens。一个做图数据库，一个做 agent 记忆，隔着几个月各自独立提出几乎同一套词汇。这不太像巧合，更像是同一批人正从不同方向重新发现同一件事：”agent 规模化必须有一层共享语义”。

工程上我留一个提醒给自己：Eifrem 讲的是上百个数据库规模的企业该怎么办，我们大多数人手上顶多一两个 Postgres，这套投入现在铺开大概率不值，先把 agent 跑起来更划算。等哪天团队里第二个、第三个人开始重新造轮子接数据源了，再回头建这层共享本体也不迟。