企业构建Agent的能力越来越强，但结果差异依然巨大。Neo4j生成式AI现场首席技术官Jesús Barrasa给出了一个解释：差别往往不在模型，而在于企业知识是如何被呈现给Agent的。 他的原话是，你必须让Agent不仅能访问你的数据，还能访问你的“含义”，访问你的企业知识。而这件事，恰恰经常没有被很好地捕获或表达。 Barrasa是在GraphSummit上与theCUBE Research的John Furrier对话时讲这番话的。两人讨论的核心是：一个共享的知识层，如何帮助Agent使用企业上下文、解释自己的答案，并在不同任务之间复用知识。 为单个应用做的工作，未必能带到下一个应用 随着企业扩大Agent的使用范围，一个熟悉的问题浮出水面：为某个应用做的工作，未必能带到下一个应用里去。Barrasa把这件事和早期的报表系统做了类比——那些系统产出的结果互相冲突。 他描述的过程是这样的：团队识别出一个单独的问题，然后把Agent需要的知识直接建在Agent自己身上，以提示词的形式、以技能的形式。接着呢？他们开始建第二个Agent，然后做一模一样的事情。用他的话说，这就是在重复七年前犯过的错误——那时候大家在不同的平台上建报表，拿到的是不一致的结果。 按照Barrasa的说法，知识层是对一个组织的数据资产、概念、政策和流程的、受治理的表示。它还能帮人检查一个Agent是怎么得出答案的——随着Agent从对话走向行动，这个需求正在变得越来越受关注。 他提到，这个知识层、这个把企业知识捕获下来当作Agent上下文引擎的思路，带来的不只是前面说的一致性，还带来了可解释性：这是我的数据来源，这些是我用来产出答案的元素。 别一上来就做全企业模型 知识图谱可以把数据与Agent解读数据所需的业务概念和关系连接起来。Barrasa的建议是，组织可以在多个应用之间逐步发展这套上下文，而不是一开始就尝试做一个覆盖全企业的模型。 他的路径很明确：从一个用例开始。当你建第二个用例时，要试着把它和第一个对齐。知识层就是这么建起来的——增量地建。识别用例、实现价值，然后在此基础上继续。他还提到一点：本体（ontology）的构建，是大语言模型可以显著加速的事情。 这意味着，共享知识层的投入产出比，可能要用比单个Agent结果更宽的尺度来衡量。Barrasa认为，组织还应该评估随着Agent越建越多，什么在发生变化。 他给出了两个衡量方向： 看第二个、第三个、第四个Agent的构建过程是不是越来越省力，因为知识被沉淀在了那一层里； 一个“负面指标”——漂移的代价。当两个Agent返回分歧的结果，或者以不同方式行动时，会发生什么？调和这些结果的成本是多少？ 这两个指标指向的是同一件事：Agent数量增长本身不构成能力增长，除非它们共享同一套对企业知识的理解。 特别