消灭Agent孤岛-AI时代新SOA架构体系-从业务系统蒸馏到本体驱动的语义编排

原创

人月聊IT

发布于 2026-10-16 08:07:30

420

大家好，我是人月聊IT。

今天继续聊在AI时代，企业的信息化和数字化究竟需要一个什么样的架构。对应传统单体时代大家都知道围绕ESB+BPEL的SOA架构思想。而到了AI时代，我核心观点是SOA架构思想仍然不过时，我们需要基于AI来构建一个新的AI时代的SOA架构体系。

一、问题起点：AI 很热，企业仍在制造新的信息孤岛

员工问一句：我的差旅住宿标准是多少？

这问题看着简单，答案却横跨两个系统。报销系统里存着住宿标准，但标准是按岗位职级和入职年限两维确定的，而这两个字段都在 HR 系统。AI 如果只会在自己的工具集里翻接口，最后往往回一句"请咨询 HR"。它答了，但什么都没解决。企业好不容易建起来的一点智能能力，被系统边界切成了一块新的孤岛。

传统信息化时代的 SOA 就是为了解这个结。做法是：从烟囱式应用里识别可复用的服务，注册进服务目录，上层用 ESB、BPM 做编排，新业务场景通过组合已有服务实现。目标从头到尾只有两条，让已有能力沉淀下来，让新场景靠组合复用完成，而不是再建一个烟囱。

今天企业做 Agent，很多做法把老问题换了个外壳。Dify、Coze、RAGFlow 这类工具确实把搭建门槛降下来了，但用起来的方式常常是：一个业务场景配一个工作流，人工拖节点、写提示词、写脚本、配工具。HR 的 Agent 接一遍 HR 系统，报销的 Agent 再接一遍报销系统，客服的 Agent 再接一遍订单系统。每个垂直智能体都能在演示里跑通，但它解决问题的能力沉淀不下来，别的场景用不上，跨场景也协同不起来。Agent 建得越多，系统之间的智能壁垒反而越厚。

转机出现在通用 Agent 的思路上。不再为每个场景手工定制垂直智能体，而是搭两层：下面一层是 Skills 技能包加 MCP 连接器组成的能力接入层，上面加通用意图识别和动态编排层，让 AI 自己规划执行路径。有新需求时，AI 理解意图、拆解任务、调度底层能力，现场组一条执行链出来。这恰好回到 SOA 的初衷：能力沉淀复用，场景动态组装。

所以问题不在 AI 不够强，而在企业没给 AI 备好可复用的能力底座，也没给 AI 一本看得懂的业务说明书。后面几节讲的就是这两件事：业务系统怎么蒸馏成能力，本体模型怎么成为语义底座，编排怎么从人工流程变成意图驱动。

二、不变的内核：SOA 思想在 AI 时代依然成立

SOA 的核心从来不是某个技术名词，而是两个目标：从遗留系统里识别和定义可复用能力；上层通过灵活组织与编排满足新场景，而不是新建烟囱。这两条今天依然成立。

用一句话概括：业务能力组件化，组件能力服务化，服务能力可编排化。这句话在单体、微服务、AI Agent 三个阶段都适用，差别只在实现形态，以及谁来识别、谁来编排。

单体时代，人识别 API，人用 ESB 和 BPM 编排；微服务时代，服务注册发现、API 网关、流程引擎把编排做成了基础设施；AI 时代，AI 参与蒸馏能力，AI 理解意图并动态编排。工具在变，复用与组合的逻辑没变。

真正变化的是主体。过去识别和定义能力靠人读代码、翻文档、访谈业务人员；编排靠 BPEL、BPMN 这类流程开发工具。流程一旦固化成模型，遇到新场景就得重新开发，响应慢、成本高，最后又长成一个新的烟囱。现在识别、定义、编排都可以由 AI 辅助完成，人退到审核、确认和治理的位置上。这不等于把人替换掉，而是把人从重复劳动里挪出来。

换一个角度看，这三个阶段要解决的技术难点也在迁移。单体时代的难点在接口规范，微服务时代的难点在服务治理和分布式事务，AI 时代多了一层：能力要能被模型理解。模型不认识表名和字段，也不认识没有上下文的服务名，它需要的是带业务语义的能力描述，以及知道这些能力之间是什么关系。这层需求是过去 SOA 不必考虑的，也是新 SOA 必须解决的问题。

因此，AI 时代的新 SOA 不是推翻 SOA，而是让 SOA 那条"能力沉淀加动态编排"的主线，接上通用 Agent 的自主规划调度能力和 MCP、Skills 的标准化接入能力。

企业要建设的不是一批孤立 Agent，而是一套可复用、可组合、可治理的 AI 能力体系。只有这样，新需求来的时候才不用重复造轮子，AI 才能真正进到业务里，而不是停在演示环节。

三、能力接入：让每个业务系统成为可发现、可调用的能力节点

新 SOA 的第一步，是把每个业务系统变成 Skills 加 MCP 的能力接入点。不是把系统推倒重来，而是在原有系统之上，蒸馏出 AI 能理解、能调用的业务能力。

公众号上有篇文章提到的"业务系统蒸馏平台"就是这个思路：不修改源码，不逆向数据库，不绕过业务 API，把传统系统的能力蒸馏为 MCP 插件。系统还是那个系统，但对外多了一层 AI 可理解的能力接口。

为什么不能把 API 直接注册给大模型？因为 API 文档只说明接口路径、参数和返回值，它不写业务对象之间的关系、不写术语、不写流程状态、不写前置条件、不写权限约束、不写指标口径。裸 API 对 AI 来说，就是一堆没有语义的按钮。

结果就是：AI 即使能调用接口，也可能选错接口、理解错参数、调用顺序颠倒、越权执行，或者给不出可解释的结果。所以能力接入必须带业务语义，必须让 AI 知道这个能力在业务上意味着什么、什么条件下能用、用完会产生什么后果。

每个 MCP 能力都应该有业务含义的名称，比如"合同创建准备""报销标准查询"，而不是数据库表名加方法名。除了名称，还要标注前置条件、副作用、幂等性、权限要求、数据范围和责任人。这几项标注齐了，能力才谈得上被信任地组合。

这里有个容易被忽略的细节：能力的粒度。粒度太粗，一个接口干十件事，AI 无法在中间插入确认和校验；粒度太细，一次业务动作要调二十个原子接口，编排成本和失败概率都会上去。比较合适的做法是把"业务上完整、技术上收敛"的操作作为能力单元，比如"查询某员工适用的住宿标准"是一个能力，"新增住宿标准明细行"是另一个能力，两者不要混在一起。

这一步做完，业务系统就不再是孤立的烟囱，而是可发现、可调用、可治理的能力节点。它是新 SOA 的地基，也是通用 Agent 能自动编排的前提。没有这一步，动态编排就是空中楼阁。

四、业务系统蒸馏与能力萃取

能力接入说起来一句话，落到存量系统上却是一堆脏活。企业里跑着五年的 ERP、十年的财务系统、七八个不同厂商的业务平台，文档缺失、人员流动、字段命名随意。这一节说清楚蒸馏和萃取具体怎么做。

先说边界。蒸馏的前提是不动原系统：不改源码，不逆向数据库结构去重写数据层，也不绕过业务 API 直接读写表。这三条不是技术洁癖。改源码意味着无休止的回归测试和升级维护；绕过 API 直连数据库意味着业务规则、权限校验、事务控制全部被跳过，数据迟早出错。蒸馏要做的是在系统外面加一层解释，而不是进到系统里面动手术。

具体有三条蒸馏路径。

第一条是接口契约蒸馏。把系统已开放的 API、消息、文件接口梳理出来，形成接口目录。这一步产出的是接口模型：接口名、协议、入参出参、错误码、调用频率限制、认证方式。接口模型本身还不是能力，它只是能力的技术外壳。很多企业的服务目录做到这一步就停了，所以 AI 依然用不起来。

第二条是数据结构蒸馏。读取数据库元数据，把表、字段、主外键、视图梳理出来，推导出候选的对象模型和数据映射关系：订单主表对应"订单"这个聚合根，明细表对应子实体，外键对应对象关联，状态字段的取值范围对应状态枚举。这里要强调一点，从表结构只能推出结构，推不出业务含义。字段名叫 col_01、flag、type1 的情况太常见了。所以推导结果必须标注来源和置信度，低置信度的项交业务人员确认，确认之前不能当作正式业务语义用。

第三条是界面与行为逆向蒸馏。这一条最容易被跳过，但对能力萃取往往最有价值。一个跑了十年的系统，最完整的业务知识其实藏在界面里：哪些字段必填、哪些操作有前置条件、点这个按钮之后哪些数据会变、哪几步操作必须按顺序来。用渐进式探索的方式让 AI 分析源代码和界面，可以逆向出行为模型、规则模型、场景模型和界面模型，再顺着"界面操作到对象、到规则、到数据库"的调用链，把端到端的业务场景串起来。这条链一旦建成，AI 拿到的就不只是"有哪些接口"，而是"业务是怎么跑的"。

三条路径的产物合起来，才是完整的蒸馏结果：接口模型、对象模型、映射模型、行为模型、规则模型、场景模型，加上权限关系。这些产物不是文档，而是能被程序读取和校验的结构化模型文件。

接下来是能力萃取。蒸馏解决的是"系统能力可见"，萃取解决的是"能力可用"。一个系统可能开放了三百个接口，但对 AI 来说真正需要暴露的可能只有三十个。萃取要做四件事。

一是语义化。把接口按业务动作重新命名和归类，补上业务含义、适用场景和结果解释。二是最小暴露。查询能力和修改能力分开授权，能查客户不等于能改客户，能调用接口不等于能用接口的全部参数范围。三是补全约束。把前置条件、权限要求、数据范围、副作用、是否需要人工确认，写进能力元数据。四是可治理。给每个能力指定责任人、所属系统、变更影响范围，接口升级时能定位到受影响的场景。

萃取的产物通常有三种形态：直接被 Agent 调用的 MCP 工具，可被多个场景复用的 Skills 技能包，以及沉淀回本体模型的能力片段。三种形态共享同一套语义定义，所以同一个能力在 Agent 编排里、在技能包里、在本体图谱里指的是一回事，不会出现三套口径。

最后提醒一个现实问题：蒸馏不是一次性项目。系统会升级、字段会改、口径会变、权限会调整。所以映射关系和能力元数据本身就是需要版本管理的资产，要有测试、有变更记录、有影响分析。把它当成一次性交付物，半年后就会失效。

五、语义底座：用本体让 AI 理解业务为什么这样运转

能力接入解决了"能调用什么"，但 AI 还得知道"为什么这样调用、依赖关系是什么、边界在哪里"。这就要靠本体模型。没有语义，能力再多，也只是一堆散落的零件。

本体模型沉淀业务对象、业务主体、业务行为、业务规则、业务事件、业务场景，以及它们之间的关系。它告诉 AI：企业里有什么、谁能做、能做什么、发生了什么、为什么发生、影响是什么。这份东西是机器可理解的企业业务说明书。

回到报销那个例子。报销系统的接口只有"岗位职级加入职年限"这个组合能确定额度，而这两项信息在 HR 系统。没有本体，AI 不知道这条依赖关系，只能让用户自己去问 HR。有了本体，AI 就知道：要查差旅住宿标准，得先取岗位职级和入职年限，再调报销系统计算额度。过去人写在 BPEL 里的编排逻辑，现在可以由 AI 理解意图后现场生成。

在我自己的实践里，这套模型从最早的对象、行为、规则三模型起步，逐步扩到十一大模型：M1 对象模型、M2 行为模型、M3 规则模型、ME 事件模型、M4 场景模型、M5 主体模型、M6 异常补偿模型、M7 质量约束模型，再加上 MM 对象与数据表映射模型、MU 界面模型、MI 接口模型。分层也清楚：底层是 MM 映射，往上是 M1 领域对象、行为与规则、事件与场景、主体与权限，再往上是 MI 集成边界，最上面是 MU 交互入口。

这十一类模型不是画着好看的图。它们要能被程序读取、校验、执行，否则支撑不了能力萃取和自动编排。举个具体的作用：MU 界面模型定义了一条完整调用链，从界面元素到行为调用，到规则校验，到对象操作，最后落到数据库表。这条链在正向开发时用来生成代码，在逆向蒸馏时用来还原业务场景，在 AI 编排时用来判断"这一步做完下一步该做什么"。同一份模型，三种用法。

还要区分企业级本体和领域本体。企业级本体说明"企业怎么运转"，包含组织、主体、权限、主数据、跨领域流程；领域本体说明"这块业务怎么做"，比如合同履约、销售回款、库存周转。把两者一起作为上下文喂给通用 Agent，业务问题的理解准确度和场景识别准确度会明显提升，选错能力和越权调用的风险也会下降。

需要澄清一个常见误解：本体不是文档问答，也不是把知识库堆到一起。文档是给人读的，本体是给机器用的。判断标准很简单，如果一个所谓的"本体"没法被程序读出来做校验和推理，它大概率只是一份结构化文档。

六、整体架构：Harness 底座、本体模型驱动、场景语义编排

把前面几节的零件装起来，就是一套完整的架构。整体分五层，自下而上是 Harness 技术底座、本体模型层、能力与引擎层、场景语义编排层、用户与生态接入层。横向还有两条贯穿线：一条是安全、权限与审计，一条是版本、血缘与追溯。

最下面是 Harness 技术底座。它是整套架构的骨骼，负责那些所有上层能力都要用、但谁也不该各写一遍的共性机制：上下文管理与裁剪、记忆存储与检索、会话与状态管理、多智能体协同调度、语义与意图识别、失败重试与降级、安全管控与可观测性。为什么这些要单独抽一层？举两个例子就清楚了。

第一个例子是 AI 辅助建模的一致性。同一份需求文档交给大模型转本体模型，今天转一版、明天再转一版，结果往往对不齐——对象一样但属性命名不同，或者同一个规则被拆成两条。要解决这个问题，靠的不是提示词写得再漂亮一点，而是底座提供精准的语义识别、转换过程的一致性与交叉校验机制。这类机制是工程能力，不属于任何单个业务引擎。

第二个例子是数据量超限。做经营分析时拉出来的明细动辄上万行，加上本体语义一起投喂给大模型，很容易超过上下文窗口。退一步说，即使没超，做到后半段模型也会开始偷懒，幻觉明显变多。简单地压缩语义，分析结果基本没法用。比较现实的做法是分段处理、分段推理，中间结果落到记忆里，最后由聚合环节汇总校验。这类上下文管理和记忆机制，同样属于底座。

往上一层是本体模型层，也就是整条链路的语义中心。它保存十一大模型文件、版本和索引，向上为应用生成、数据分析、能力编排、AI 推理提供统一的语义定义。这一层有两个要求。第一，模型必须能被机器读取和校验，不能只存成图文档。第二，必须支持影响分析：删掉合同金额这个属性，要能立刻列出受影响的行为、规则、报表、接口、映射、Agent 和场景，而不是等线上报错才发现。

第三层是能力与引擎层，分左右两个集群。右侧是蒸馏出来的外部能力：由存量系统萃取而来的 MCP 工具和 Skills 技能包，它们通过本体能力网关被统一纳管、鉴权和审计。左侧是平台自有的处理引擎，职责单一、边界清楚，主要包括：需求引擎把模糊想法变成结构化需求；本体模型引擎生成和维护模型并做一致性检查；应用生成引擎按模型生成可运行应用；数据连接引擎维护对象到表的映射并受控取数；数据分析引擎把业务问题转成逻辑查询计划；AI 分析推理引擎组织本体上下文和数据事实调大模型做归因；规则引擎和事件引擎负责运行时判断与事件分发；报表引擎负责呈现；存储与制品引擎保存资产和血缘；大模型网关统一做模型路由、脱敏、成本统计和降级。

第四层是场景语义编排层，也是 AI 时代新 SOA 最关键的差异所在。它包含意图解析器、场景配方库、能力注册表、计划生成器、执行器和状态管理器。用户的业务目标进来，先由意图解析器转成结构化任务，再在场景配方库里找可复用的交付模板，结合能力注册表判断每步由谁执行，生成一份带依赖关系的执行计划，交给执行器跑，状态管理器记录全过程并输出链路标识用于追溯。

最上面是用户与生态接入层。业务用户、分析人员、架构师从统一入口进来；外部 Agent 和第三方系统通过 MCP 或 REST 网关调用平台能力。加上横向的安全权限审计线和版本血缘追溯线，整个架构就闭合了。

这张图上有个容易看漏的设计：本体模型层在中间，底座在它下面，编排在它上面。这个位置不是画图习惯，而是职责要求。往下的底座保证模型生成和运行稳定，往上的编排靠模型的语义做决策。中间这层一旦失守，上面编排得再花哨也组不出正确的链路。

七、动态编排：从写死流程到意图驱动的语义编排

传统 SOA 的编排靠人。人分析流程、定义规则、用 BPM 或 BPEL 开发流程，流程固化成模型后上线。这种方式的毛病是：一旦业务变化，就要重新开发流程，响应慢、成本高，改到最后又是一堆流程孤岛。

AI时代的核心变化是编排主体从人换成通用 Agent。用户只表达业务目标，AI 负责意图识别、规划、任务拆解、能力发现、调度和结果汇聚。人不再写死流程，而是审核关键判断。

比如用户说"帮我确定差旅住宿标准"。AI 识别意图后，发现要先调 HR 能力取岗位职级和入职年限，再调报销能力算标准，然后按依赖顺序执行，最后返回结果，必要时请用户确认。整个过程没有预先画好的流程图，路径是当场组出来的。

但动态编排不能完全自由。大模型规划有不确定性，今天规划对了明天可能就漏一步。所以要有约束：本体约束调用范围，能力图谱约束可选项，规则校验拦住明显错误，人工确认卡住高风险节点，失败补偿兜住异常。关键流程配预定义的约束条件，形成混合编排，灵活性和可控性各让一步。

落到机制上，有六件事必须做。

一是配方优先、AI 补充。平台先匹配成熟的场景配方——把销售下滑归因、合同履约分析这类跑通过多次的交付流程沉淀成模板，固定引擎序列和可变参数，大模型只做意图匹配和参数填充。找不到匹配配方时，才让 AI 在能力注册表和依赖规则范围内生成候选计划，而且计划要先通过机器校验，再由人确认。跑成功并评审过的计划，沉淀为新配方。

二是结构化计划与依赖图。执行计划由节点和依赖关系组成，节点引用具体能力版本，输入输出通过资产标识传递。计划要支持串行、并行、条件分支、人工任务、重试和子计划，但单次计划内部不能有依赖环。计划生成后先做静态检查：输入输出类型对不对、前置资产在不在、模型依赖满不满足、权限够不够、预算超没超、有没有危险操作。检查通过才允许启动。

三是运行时上下文管理。引擎之间传递的不是一份越滚越长的聊天记录，而是明确版本的结构化资产，由上下文构建器按当前步骤生成最小输入。这条规则看起来是工程细节，实际决定了系统能不能长期稳定运行。

四是检查点与恢复。每个重要阶段完成后落检查点。引擎失败、平台重启或用户暂停后，从最近的检查点恢复。已完成且输入未变的节点不重复执行；上游资产变了，靠依赖图判断哪些节点失效需要重跑。

五是异常分类与补偿。输入缺失、模型校验失败、连接失败、权限拒绝、资源超限、AI 输出不合格、构建失败、外部服务不可用，这些异常要分开处理，分别对应补充输入、自动修复、重试、切换模型、回退版本、跳过或转人工。补偿不等于把结果删掉，失败运行留下的资产要保留作为排查证据，正式资产是否回退由版本和发布策略决定。

六是人工门禁。企业特有规则、指标口径、低置信度映射、权限变更、写操作能力和生产发布，默认设置人工门禁。项目可以按风险等级调整门禁严格程度，但不允许单次 AI 规划自行取消安全门禁。

这六条做完，企业才敢把跨系统任务交给 AI。让 AI 在明确边界内像经验丰富的调度员一样组合底层能力，比让它自由发挥更接近生产可用。

八、治理边界：让企业敢把跨系统任务交给 AI

AI 能做事，不等于企业敢让 AI 做事。自动化负责效率，人仍然对权利、歧义和正式结论负责。治理体系是新 SOA 能不能落地的关键。

先要把四个概念分清楚：能发现、能使用、能访问、能代表。市场可见不等于发布方授权，发布方授权不等于系统所有者许可，系统所有者许可不等于用户本人授权。这四级之间没有自动传递关系，每一步都要有明确边界和记录。

跨系统动态编排尤其需要身份、权限、审计和确认。谁发起、代表谁、依据什么、调了哪些能力、返回了什么、有没有越权、有没有留痕，全都要可追溯。做不到这一点，AI 越能干，企业越不敢用。

写操作要格外谨慎，建议采用两阶段调用：先准备，校验参数、权限和业务条件，返回影响范围和确认摘要；再提交，带上确认令牌和幂等键执行正式写入，防止确认之后参数被替换。同时，原业务系统仍然要负责最终的权限校验、事务处理和核心业务规则，平台不能因为 Agent 已经判断过就跳过原系统校验。

数据权限的执行位置也要明确。行级权限必须在取数那一刻生效，由数据连接环节根据主体模型和调用者身份注入过滤条件，而不是先把全部数据拉出来再在前端隐藏。平台管理、项目资产、能力调用、数据访问、发布这五类权限要分开，能配置引擎不代表能看所有项目数据，能编辑模型不代表能连生产库，能调查询工具不代表能调写操作。

审计记录要覆盖全过程：用户的原始请求、模型选择的能力、加载的资源、工具参数摘要、确认记录、接口请求响应摘要、耗时、结果、错误和版本。这些记录不是负担，它是信任的基础，也是出问题时唯一能定位原因的证据。

九、落地路径：从一个小闭环开始

这套架构不适合一次建全。比较稳妥的路线是分四步走。

第一阶段做"本体建模到智能分析"的最小闭环，核心是本体模型引擎、数据连接引擎、AI 分析推理引擎和存储引擎。选一个对象清楚、数据源可连、问题明确的场景，比如合同履约分析或销售回款风险分析。目标不是做得多，而是验证一件事：带上本体的分析是不是真的比直接把表丢给大模型更可靠。这一阶段要跑通对象建模、数据映射、受控取数、分析报告生成和结果追溯。

第二阶段补"需求到应用生成"的闭环，加入需求引擎和应用生成引擎，支持从一句话需求到需求文档、从需求文档到本体模型、从本体模型到可运行应用。生成范围先控制在单体应用、标准增删改查、主从表单、简单状态机和固定报表，不急着做微服务和复杂流程。

第三阶段做业务系统蒸馏与能力萃取。选两三个已经被本体验证过的存量系统，按接口契约、数据结构、界面行为三条路径做蒸馏，萃取出一批能力节点，注册进能力注册表，用 MCP 方式暴露给 Agent 试用。同时开始积累场景配方库。

第四阶段建场景语义编排和开放能力，引入编排引擎、本体能力网关、大模型网关和治理能力，支持跨系统事件、自动化流程、外部 Agent 调用、模型路由和成本管控。到这一步，平台才从一个内部工具变成组织级的能力底座。

每一阶段都有几条边界要守住。模型不能只停在图文档，必须能被程序读取和校验。AI 不能绕过业务确认，审批规则、权限范围、金额口径、父子对象处理策略必须由业务确认，平台越自动越要留住关键确认点。不要一上来追求全自动生成复杂系统。数据映射和能力元数据要当成资产做版本管理。AI 分析结果要带依据、带来源、带口径说明，区分事实、推断和建议，经营决策保留人工复核。

最后一条也是最重要的：编排准确率是这套架构当前最大的挑战，重点应该放在积累场景配方和优化意图匹配上，而不是每次从零让大模型推导计划。配方库厚不厚，直接决定这套系统在真实业务里的稳定性。