企业谈平台依赖，通常先想到数据能不能导出、代码能不能迁移。但当 Ontology、Agent 和 AI Coding 进入核心流程后，更难带走的往往不是文件，而是企业已经沉淀在平台里的对象定义、关系规则、工作流和判断习惯。本篇想追问一个更深的问题：当平台越来越懂业务，企业是否还保留着重新解释和修改自身业务的能力？
侯君璠，AI架构陪跑师，清华大学工程管理硕士（MEM），企业架构研究会发起人，国内大型央企单位技术总监、解决方案专家。20余年工作经验，曾任美国某大型科技公司-M中国区首席架构师，国内某大型险资技术总监、某大型科技咨询公司副总裁。深耕于企业架构、人工智能研究与落地方案，以及先进工程项目管理和企业数字化转型等领域。
一家大公司请外部供应商建设了一套统一的 Ontology 和 Agent 平台。系统上线之后，各个部门的数据就被集中了起来：客户的资料、合同的信息、设备的情况、风险事件等等，都可以被随时查阅到；Agent可以产生分析的结果，而AI Coding则可以在短时间内就产生新的应用程序或者新的流程。项目进行得很顺利。 几年之后，公司的经营模式发生了变化。管理层认为：“核心客户”的定义需要改变，原来的合作关系不能继续使用老的“供应商”模式。 经过一番探讨之后才知道，修改起来要比想象中的困难很多：哪些应用程序仍然使用着原来的定义呢？哪些关系是由平台自动建立起来的呢？修改Ontology会对报表、Agent和业务流程产生什么样的影响呢？当初为什么要用这种建模的方式呢？ 系统是企业自己的，数据也还留在企业但理解和修改这套系统的能力，却逐渐转移到了平台和厂商手中。 最深层次的平台依赖，并非代码、数据存储等技术层面的东西，而是一整套企业的运作方式。 【企业架构研究会在每个月都会发布智能架构和本体论研究的研究报告，并且构建不同的社群，如有希望获取的，希望进群一起研讨的，请留言：“进群并获取资料”，同时添加文章最下方的联系人，我们恭候各位到来，希望与各位有识之士一同研讨中国的企业IT产业和技术发展的方向，有需要进群或者联系我们一起学习的，请联系money_god1984】
一、平台中的定义将会逐渐成为企业默认的定义
在本体和agent引入企业的时候，特别是在项目刚开始的时候，Ontology 被看作是技术性的任务：业务人员提供概念、技术团队进行数据映射、平台厂商负责实施。 但是由于越来越多的报表、Agent、流程都开始依靠它了，这些定义也就不再只是技术的定义了。 客户的定义直接决定了客户的人数以及归属关系；风险关系怎样建立，决定了调查的对象是谁；订单完成如何解释，会影响到收入、绩效以及售后服务；设备故障如何划分，会影响停机与维修时间表。这些定义会逐渐参与企业的实际决策：谁可以获得资源、风险由谁来承担、先解决哪个问题、哪些行为被认为是正常的。 如果公司一直用平台模板或者厂商配置的话，那么这些技术定义就会逐渐成为组织上默认的业务定义。过了很长时间之后，“人们已经不关心企业是怎么看待客户了”，而会直接接受“系统里的客户就是这样被定义出来的”。 因此平台不只是一种业务工具。它也成为了企业的定义者之一。 二、过分依靠自动化会使企业解释的能力逐渐减弱 成熟的系统平台可以做很多事情：清理数据、核对信息、建立联系、进行计算、得出结论、提出建议。 从短期来看这是好事，就是效率问提升。但是如果整个组织都依靠外部的分析工具的话，且不做知识底座和资产储备的话，一些重要的专业知识可能会慢慢流失： 原来的数据口径负责人已经离职了，完整的定义很可能就没有人去维护了；熟悉业务关系的分析师也逐渐习惯直接相信平台给出的结果；架构师知道如何配置系统，但是却说不出配置背后是什么样的业务逻辑；新人学习的是“怎么按按钮”，而不知道对象、规则是怎么来的。 这并不是某位员工出现了问题。组织的知识也发生了变化，过去分散在人、制度和团队讨论中的知识，现在越来越多地沉淀进平台配置、厂商方案和自动化规则里。。 几年之后，当企业想要对结果提出质疑或者改变定义的时候才意识到：平台为组织做了很多事情的同时也也在不知不觉中削弱了组织原本应该保留的解释能力。。 三、AI Coding 越快，越要警惕对专用平台的依赖加深 AI Coding 降低了应用程序开发的成本。业务人员提出需求后，平台就可以很快地生成出应用程序、规则和自动化的流程，使企业能够迅速地响应市场变化。 随着生成的速度越来越快，平台里的应用也更容易迅速增加。如果所有的应用都是依靠厂商自己定义的Ontology、接口、规则语言以及运行环境来实现的话，那么代码越多，退出的成本就会越高。 传统意义上的平台被锁定了，常见表现是数据难迁移、代码难移植。到了Agent的时代之后，就更加牢固了，因为业务对象的定义很难被还原出来，对象之间的联系也不可能全部导出，Agent的工作流程依靠于某个特定的环境上，并且之前所有的判断依据都没有单独保留下来，在没有了平台的情况下这些内容也无法被利用。 企业的数字化能力越来越多了，但是没有了平台的话，这些能力能不能存活就不知道了。 AI 编程提高了工作效率。但如果没有独立的业务语义和清晰的技术边界控制和留存，就会使企业更加依赖某一个平台，这从某种意义来说是一种灾难。 四、数据在企业手里，不等于控制权也在企业手里 谈到数据主权，企业通常会关注的是：数据在哪里、谁可以查看、能否下载、是否满足安全标准等。这些都是很重要的事情。 但是数据文件属于企业的，并不意味着解释数据的能力也归于企业。 客户的信息、合同以及交易都在公司服务器上保存着。但是以下问题只能由平台来解答：哪些记录属于同一个人？什么样的关系才算是重要的呢？风险标签是如何形成的？哪些系统的规则发生了改变？ 如果说不上这些的话，企业的手头也就只有业务原料了。把原料转化为企业的实力这一步已经不在自己的控制之下了。 因此Agent时代的数据主权不单指的是“数据归谁所有”，还要问：谁来决定数据代表什么？“哪一个人能够解释系统做出判断的原因？”“如何改变这个判断的标准呢？” 五、问题不是要不要用厂商持续服务，而是企业还能不能自己定义关键领域 大公司不可能所有的项目都自己来做。使用成熟的产品、成熟的方法和经验才是实际且合理的做法。 真正意义上的分界点就是一些问题：公司还能够自主地更改重要的定义吗？企业在业务发生变化的时候，它知道自己会影响到哪些地方吗？当结果与经验相矛盾的时候，企业是否会去反思现有的规则呢？厂商停止提供服务之后，其核心的能力还存在吗？平台不适宜的时候，所积累的知识能带去吗？ 如果这些问题只能由厂商来解答的话，那么企业把工作外包出去的就不仅仅是指软件实施了，还包括对企业业务的理解和改变自身的工作方式的能力。 软件可以购买，实施服务也可以购买。外部分布式平台可以帮助企业迅速地建立起自己的数据、本体和智能体能力。 但是有一项工作不可以被外包出去，那就是企业自身的认知能力。 最深的平台依赖，并不只在数据存在哪里、代码使用什么语言，而在于：客户怎样定义？哪些关系具有业务意义？为什么相信这样的判断？规则改变之后会发生什么？ 当这些问题只能由平台来回答的时候，企业所失去的就不仅仅只是技术自主权了，而是在自己业务领域重新定义、调整和发展自己的权利也被剥夺了。 企业架构研究会由清华MEM同学联合发起，旨在推动企业架构认知和理念在国内的提升，逐步培养和构建顶层规划能力，用企业架构指导企业做好顶层规划，以使用新质生产力应用和发展要求企业架构研究会，专注企业科技架构研究，输出科技领域深度干货，拆解行业风口真相，拒绝浮躁，只讲落地。 有需要进群或者联系我们一起学习的，请联系money_god1984 关注我们，后续持续分享技术实战干货，想领取更多智能化架构建设 的相关资料，参加更多的线上线下的技术论坛，请私信或留言“获取资料”已获得我们的联系方式。
声明：本文核心文字内容由本人亲自撰写，图片由模型生成
夜雨聆风
