2026，架构新时代元年：模型即架构，工具即系统

从去年DeepSeek炸圈让我彻底掉进AI大坑到现在，再到过春节，就整整一年了，我试过让AI画图、做ppt、写书、写脚本，最终投入精力最大的还是自然语言编程，也就是离我的饭碗——企业架构最接近的应用方向，这部分工作粗略估计也占了我在AI投入精力的95%以上，使用过多个架构工具，也一路体验各类LLM，与各路大神交流，体验AI带给我的各种“惊喜”和“惊吓”，经过这一年的摸爬滚打，我对AI的信心可以说是与日俱增，毕竟，无论是多大的失误，我们都一起扛过来了，将一个从网页开始萌生的想法做成了我自己的架构思想实验室，搭建起一个基本的业务系统，叠加了AI助手和智能体平台，搭建了架构模块，并努力将本体论模式带入，尝试建立同时支持业务分析和架构分析的系统，这些都长在同一个项目中，也可以说是长在同一个系统中。

实践可以帮助我更深入地理解到底本体论好在哪里，能做什么，AI确实改变学习方式，我到目前为止都没有很系统地看过本体论及其建模方法，也没有很全面深入地了解palantir系统，只是以这个方向为目标，与LLM一起向前探索，在实践中了解图数据库的用法、语义图模型与企业架构模型的异同、实现方式如何逼近等等，这种瞎打乱撞的学习方式有其痛苦之处，但也很有趣，直到最近自己悟到了图数据库中一个很基本的查询算法，涟漪算法，才突然对这套东西豁然开朗了。

也许这就是AI时代的学习方式，实践出真知，知行合一。

回到今天文章的标题，是标题党，也不全是，更像是一年实践下来，对自己原工作领域的一个感悟性总结：企业架构在AI时代会怎么样，这也是我最初入AI坑的原因。未来会如何呢：

一、模型即架构，语义模型即企业架构

模型驱动的软件工程早就不是什么新鲜事儿了，只不过做模型是一个大多数人即讨厌又很难完全搞定的事情，不然也不会有那么多企业端开发缺少基本的模型，也不会即便有模型也是“千模千面”，说是画给别人看的，最终都成了画给自己看的，只有自己看，也只有自己看得懂。模型本来是用于理清思路的、用于沟通的、用于驱动开发的，结果成了自驱力的表现。

但是到了AI时代又不太一样了，不是讨厌建模吗，不是讨厌梳理规则吗，不是觉得无用吗，好，琢磨智能体设计、LLM效能提升的时候，开始不厌其烦的打磨提示词了，开始上下文工程，研究思维链，甚至研究结合会话的自学习，这不都是更细粒度的流程建模吗？就是我们之前舍不得时间，觉得不值得的东西，换个马甲，它又回来了。当然这次回归最大的不同是，反馈链的极致压缩，思维链、规则打磨完，效果立等可见，不用在像以前那样，等到测试版本、系统上线、天荒地老，才发现不对。

思维链、提示词，实际上就是比当年五级建模还要细的流程建模，而且还衍生出了工程化的变体——Spec这个流行货，Spec略像工艺，工艺是啥，本质上是IT给自己写的流程模型。

如果思维链、提示词可以类比流程模型，那本体论、语义图呢？在我这野生玩家来看，他们的核心是基于业务对象关系的数据获取方法，这是其底层，在用语义查询提供数据结果的同时，又提供数据组合后的语义来帮助分析数据。

语义是以往的关系型数据库一般不会去提供的内容，说是一般不会，是因为关系型数据库也能模拟图数据库的实现，只是通常不会干这事儿，存语义给谁用呢？语义不是系统用户自己该懂的吗？对啊，以前不需要系统真理解语义，因为不需要它那么聪明，而现在则是因为LLM太聪明了，为了让聪明人少干傻事儿，需要让他理解语义，这是时代性的改变导致的，傻子突然上天了，需要人帮一把。语义图并没有使AI更聪明，因为AI有没有因为语义图调整了参数和权重，语义图只是让AI分析问题采用的事实受到了严格的约束，不那么信口开河了。

说到这里，就会聊到跟我的工作直接相关的事情了，palantir搞的本体论实践是以业务分析为主的，能不能用在架构分析上呢？答案是肯定的，至少Servicenow是在用语义图方式存储架构信息的，因为语义图扩展更新更容易，且可以与数据源有一定的分离，不必非要数据搬家。据说palantir、Servicenow要开打了，我倒是觉得没准儿他们最终会打出一个超级架构工具来，为啥呢，一个是信息分析龙头要往工作流打，必然会碰到架构问题；一个本就是架构工具龙头，要守住自己阵地，打着打着可能就打到架构这块了，而且刚才我也说了，Servicenow是在用语义图方式存储架构信息的，palantir又是从本体角度解读万物的，本就会有产生交集的可能。

除了看神仙打架，我自己的判断是什么呢？通过我自己的实践，“一套”语义图是有能力同时支持业务分析和架构分析的，因为架构分析覆盖的是节点和边的全集，业务分析需要的只是其中的子集，当然，从建模和是否数据搬家的角度看，对于业务分析而言不算数据搬家的，对于架构而言可能就算是数据搬家了，这些细节不在本文讨论了，我自己就是通过开发在给自己的想法做证明，在努力探索我刚才说的这些。

完整的语义图会覆盖企业知识、系统设计、系统实现的全部节点和边，从中也可以自然看到聚类关系，从这个角度讲，“模型即架构”，语义模型即企业架构，人机协同的一个重要任务就是讨论LLM的理解是否正确，而这个沟通的背后就是语义关系是否正确，是否是我们想要的语义关系，这个语义模型又像一张巨大的蜘蛛网，可以覆盖到企业的全部业务和IT。

至于这个模型，要想想，一定要由人来全部操刀建立吗？结果可以验证逻辑，而动手不必非得是人，虽然模型专家建模效率可能会高，至少我自己的实操中我还没亲自动手建过本体论模型，也没深入读过相关建模规范，是LLM和编程工具代劳的，最终通过数据库中的存储内容和查询结果验证，当然，我的实验系统太简单了，也许没法遇到真正的困难。

通过实践我倒是自己理解了语义图是干什么的，记录数据的基本位置和数据组合后的含义，就是怎么找到数据，找的数据在说什么，这就是最朴素的知识表达范式。等于是给LLM一个可靠的事实，再让LLM不会太跑火车，所以，从可靠性上来讲，语义图是需要有不依赖LLM的独立事实生成能力，以保证事实的可靠性，而这一点也会需要一个相对“重型”的基础设施。

这个就是我疑惑的点了，是不是一定会持续需要呢？随着基础模型的进步，会不会是一个“薄”的语义层也会够用呢？一个“薄”的语义层从逻辑上来讲也足够承担“模型即架构”的职能，毕竟，语义层的核心职责就是这个。palantir的成功实践是从AI还远不好用的时期积累起来的，正好撞到一个AI即好用又不够稳定的时期，之后会遇到一个能保证基本的稳定再加上好用的时期，这个时期，可能“薄”语义层也够用了，而这个时期的到来也不会太晚。到了最后又稳定又好用的时期，真的就只是一个更“薄”的语义层就够了，应该不再需要记录数据位置了，只需要确定基本语义，保证AI能够融入企业自身的特殊环境就够了。

所以，企业架构以后的工作是什么，就是持续与AI构建和管理这一个“薄”的语义层，当它可以很“薄”的时候，也就更容易构建了，而且，根本不需要完全由人来构建，毕竟我们的制度、流程、文档、系统中都散落着大量的模型基础，只是缺少进一步的串联，这个过程可以由AI与人共同完成，palantir是在AI不太行的时代成长起来的，所以，它的经验，有些地方是可以随着AI的发展加以改良的。这个“薄”的语义层一但建立，图数据库灵活扩展的能力也可以很容易地通过正反两向的持续维护，也没有所谓的保鲜问题和架构属于静态描述还是动态的问题。

语义图模型的诞生是否意味着“重”企业架构时代的结束，至少目前不是，通过刚才思维链、提示词的介绍可以看到，某种程度上来讲，反倒更“重”了，只是很多人也许不会觉得那些属于企业架构而已。但今后真的不应该是“重”企业架构时代了，因为不再是单纯的为了人人沟通、为了填补工具的不足才进行重手工劳动的建模了，是为了人机沟通、是通过智能化工具让工具更加智能化的建模了。

二、工具即系统，架构工具即业务系统

理解了“语义模型即企业架构”，特别是刚才说的工具问题后，才更容易理解“工具即系统”，架构工具即业务系统这个想法了。

对于人而言，由于专业分工的不同，天然会有“做系统”和“用系统”的边界，但是AI有吗？AI不就是自己写代码给自己用吗？过去这一年里，我们从最初AI写脚本给自己用，到做MCP，再到做Skills，说白了，不都是AI一边“做系统”一边“用系统”吗？我们这么做的目的就是为了AI执行更快、更稳定，不要浪费token老去回忆自己某处成功是怎么做的，也不用老是担心AI做事成天出幺蛾子。

再扩展一些看，我们研究基于智能体的AI应用形态，不就是打算让AI接手我们的业务系统吗？AI怎么学会用系统的，不就是先了解了系统的功能和架构吗？加上我们给他的语义层，让他好像真了解了我们的业务一样。我们的研究说到底是在琢磨怎么让AI做系统给AI用，遗留系统的功能保留是为了稳定性，是我们还不相信AI其实还可以做的更好，因为有些系统我们自己怎么鼓捣出来的，自己都说不清了，也不敢考虑是不是交给AI来重搞一遍。

但是随着模型的发展和应用的普及，开发成本的直线下降，旧的系统迟早会被替换的，如果AI的记忆力获得极大提升，现在都在讲“永久记忆”了，那么他自己做的系统显然自己更好管理，这一点跟人也类似。就像我之前公众号文章说的，采用AI是为了让他充分释放生产力，还是让他当垃圾管理员呢？一个自己都不敢碰、不敢去升级的系统，还谈什么生命力呢？

人类系统的复杂是因为人类的复杂，不是因为事情本该复杂，当大量的流程中，AI的协助力甚至主导力在增强的时候，系统是该简单还是复杂呢？还是系统本就该简单才对呢？想想区块链、想想大饼，就知道支付系统也可以简单到什么程度。

企业架构中难以解决的问题多数不是系统问题而是人的问题，人跟人会去争能力是否可以复用，但是人跟机器争能力是否可以复用是不是有点“傻”呢，因为机器根本就不会跟你争，如果语义可靠，机器可以判断的准，也可以按照你的要求不那么准。如果语义可靠，我们还非要自己在海量能力中进行复用判断，也是有点没活儿找活儿，或者就算是为了定期给语义做个校准吧。

我一直认为ERP是个很伟大的产品，但只是曾经，放在今天看，产品的路子都该改了，只需要通用AI工具，无需通用业务系统，业务系统是可以由AI工具去进行适配的，AI工具就像一个3D打印机。这个模式倒是很像我在《聚合架构》一书中最后描绘的行业级标准化，行业级标准化无法由人来实现，但却可以通过AI工具轻易实现基础模块的标准化，虽然是通过抄作业实现的，这就是3D打印机的能力，抄了再改也容易。

如果说AI自己做系统给自己用，可以说AI自己就是个架构工具，架构工具也是以AI为核心、以语义图为驱动运转的，我觉得未来不是数据驱动，或者说至少不是过去大数据意义上的数据驱动，是语义驱动，数据并非越多越好，而是与问题越相关越好，与该有的知识越贴近越好，抛开探索性领域不谈，大多数业务领域，这个说法是适用的。以前是总盼着发现新模式，这个在C端这种总想影响消费者心态的领域也许适用，但是对B端这种经常要追求确定性过程结果的领域就不完全适用了。

所以，有效组织数据进行分析一直是B端数据分析的核心话题，数据仓库的发展历史一直是在这么努力的吧。而有效组织数据的方法呢？语义肯定可以是其中的一种啊。结合前文分析的，语义模型即企业架构，业务分析和架构分析、架构设计可以基于同一套语义基础进行，那么，以AI为核心的架构工具也就是直通设计、实现、业务处理的了。架构工具和业务系统会完全融合到一起，也就是逻辑一体化了。

好了，罗里吧嗦讲了一堆，今日份的思考就到这儿，一路前行，AI相伴。