按照我之前的学习习惯，在具体到一个模块时先明确其在整体中的定位，所以要先有整体，然后逐步深入到大的业务方向，最后再到自己负责的模块，这样比较好融会贯通，所以整体分为三篇

• 第一篇： 主要学习未来企业在 AI 时代背景下一些开发模式的变化；企业业务能力的开发方向，更具体的是未来产研的精力会更多的投入到哪里，也就是人才的流动方向、研发资源的流动方向，我们以后的关注重点在哪儿。AI 时代产研大趋势 + 架构变革 + 人力流向（全局视野）
• 第二篇： 在正式学习 CMDB 之前，先要了解其在整个企业信息化体系中的一个定位，即整个企业信息化体系要包含哪些模块和能力，以及CMDB 和 CSDM 在其中发挥什么作用。 企业整体信息化大盘 → 锚定 CMDB/CSDM 定位（找准自身位置）
• 第三篇： 深入到 CMDB 、 CSDM去了解其中的核心逻辑和核心实践。 深耕 CMDB、CSDM 核心原理与落地（专精学习）

接下来是第一篇，关于AI时代下我们的开发模式的变化以及企业业务开发模式的分层架构逻辑

一 传统业务平台/中台开发模式

旧时代（AI普及之前）的企业内部业务平台/中台的分层架构，没有AI、没有Agent编排、没有模型服务层，我们一般是三层架构：

层级	角色	核心能力与内容	主要实现/抽象形式	主要工作角色/人员类型
用户交互层	前端界面	提供表单、列表、报表、审批操作等图形化界面，用户通过点击、填写、提交等方式完成业务操作	Web页面、移动端App、桌面客户端（React/Vue/Angular等）	一线业务人员（使用者）
业务应用层	前后端服务	实现业务规则、流程编排、数据校验、API接口、定时任务、消息处理等核心逻辑	前后端服务（Java/Go/PHP/Python）、微服务、消息队列、工作流引擎	前后端开发、架构师、业务研发
基础设施层	运行环境与数据存储	提供计算、存储、网络、数据库、缓存、消息中间件等底层资源，支持应用的运行和数据持久化	物理服务器、虚拟机、容器（Docker）、云主机、关系型数据库（MySQL/Oracle）、NoSQL（Redis/ES）、负载均衡、DNS	运维工程师、DBA、基础设施工程师

• 用户交互层：一线业务人员只能使用，无法修改
• 业务应用层：所有业务规则、流程、API均由前后端研发人员手工编写，没有Agent编排或低代码生成。
• 基础设施层：包含了计算、存储、网络以及数据库、缓存等数据层组件，由运维和DBA负责。

没有任何AI相关元素（无大模型、无Agent、无智能编排、无自然语言交互）

二 AI时代下新业务开发模式

1 AI时代下新的开发层级划分

AI时代的企业技术基座，相较于旧时代的分层模式，主要发生了四个关键变化：

1. 新增模型服务层：这一层与具体业务无关，提供大语言模型的训练、微调、推理、RAG等运行环境，是AI能力的源头。

2. 业务应用层转型业务能力层：将企业的核心业务能力（如文档处理、审批规则、价格计算）封装为原子化、可被AI Agent理解调用的API。原有的业务逻辑层只需完成能力原子化改造，无需再做前端页面或交互，只暴露能力接口，让上层Agent或用户自由编排。真正的页面交互和业务入口，让业务的使用者自己通过业务轻应用层定义。

3. 新增Agent管理调度层：核心作用是**“管理智能体行为”。负责Agent的编排、协同、身份认证、权限、审计、成本追踪**等治理工作。它是企业AI中枢的核心

4. 新增轻应用层：核心作用是用自然语言生成表单、报表、审批流、数据看板，将数据的呈现形式和组织形式主权交还给用户。

基于以上变化，新的分层模式如下(从上到下)：

层级划分	角色	核心能力与内容	主要实现/抽象形式	主要工作角色/人员类型
用户交互层	对话式界面	自然语言交互、多模态输入、任务发起与结果展示	聊天机器人、企业门户、IM集成（钉钉/飞书/微信）	一线业务人员（直接使用，无需技术背景）
业务轻应用层	业务轻应用快速生成	用自然语言生成表单、报表、审批流、数据看板	低代码应用	低代码应用搭建者、实施类研发（轻研发，偏配置与组装）、部分一线业务人员
Agent管理层	Agent编排与治理	身份认证、权限控制、多Agent协同、审计、成本追踪、策略执行	低代码平台、AI应用生成器（秒搭、轻流）、企业自建管理平台	核心研发 / 平台架构师（重研发，构建控制平面）
业务能力层	业务能力服务化	将文档处理、图形识别、审批规则、价格计算等业务能力封装为安全、可调用的原子服务，构建为Agent	API网关、函数即服务（FaaS）、企业内部服务网格	后端 / 平台研发（原有服务接口化，暴露为能力）
模型服务层	大模型服务	基础大模型、微调模型、RAG引擎、向量数据库	模型API（OpenAI、智谱、百川）、开源模型部署	算法工程师 / 模型工程师（训练、微调、部署）
基础设施层	计算、存储、网络	物理/虚拟服务器、云主机、存储桶、网络设备、容器运行时	云厂商（AWS、阿里云、腾讯云）、私有云、本地数据中心	运维工程师 / 基础设施工程师（硬件、网络、云资源）

---

各层之间的关系如下：

2 新工作模式下产研流动

重点体现：原有后台研发人员分流、新增Agent管理层与模型服务层、业务人员能力拓展。

以下是更新后的表格和详细说明：

群体	变化趋势	详细说明
一线业务人员	能力拓展，向下可独立构建应用	原本只是各类后台应用的使用者（登录、点菜单、填表单）。在AI加持下，部分有能力的业务人员可以下沉到业务应用层（原SaaS生成层），通过自然语言或可视化拖拽，自主搭建轻应用（表单、报表、审批流、看板等），无需等待研发排期。
原有后台研发人员	分流：部分上浮，部分保留，部分下沉	AI辅助下，大量重复性的CRUD开发、前端页面编写不再需要人力。上浮：转向业务轻应用层，辅助业务人员生成低代码应用，或担任AI生成结果的校验、配置角色（偏实施）。保留：留在业务能力层（CaaS），但要求升级——必须掌握领域驱动设计（DDD）、原子能力拆分、API治理等技能，需要深入理解业务模型、事务一致性、高可用设计，并且会配合上层Agent封装。不再写简单接口。下沉：极少数核心研发可能涉及Agent管理层或模型服务层的底层框架开发。
Agent管理层（新增）	全新岗位，需求增长	负责构建和维护企业的AI中枢：包括Agent注册发现、多Agent协同编排、统一身份认证、权限控制、审计日志、成本追踪、策略执行。需要熟悉工作流引擎、分布式协调、安全策略等，同时要理解大模型调用和Agent通信协议。这一层之前完全不存在。
模型服务层（新增）	全新岗位，门槛较高	负责大模型的选型、部署、微调、RAG引擎搭建、向量数据库管理、提示词工程、模型性能优化等。需要具备算法基础、工程化能力，以及一定的业务理解（如何将大模型能力融入企业场景）。这一层也是之前没有的，岗位需求在增长。
基础设施工程师	基本不变	运维和DBA仍然负责服务器、容器、数据库、网络等底层资源。但随着AI引入，可能需要支持GPU算力调度、向量数据库运维等新技能，整体岗位数量稳定。

总结来看可以大致分为这三个变化：

• 一线业务人员 能力向下拓展，部分可自主生成应用。
• 普通CRUD研发 被分流：上浮做轻应用辅助，留下做原子能力（需升级），极少数下沉做底层框架。
• 新增Agent管理层 + 模型服务层 成为核心研发的新主战场，替代了旧时代部分业务逻辑层的职能。

整体人才结构从“橄榄型”向两端（业务+AI基础）扩大、中间层（纯CRUD）收缩演变，这主要是因为在AI加持下，我们可以实现业务能力原子化（CaaS），交互入口民主化（用户自定义）

---

3 新工作模式下业务落地场景对比

举几个新旧业务落地场景的对比：

业务场景	旧时代处理方式	AI时代融合处理方式
商户资质信息查询	登录内部商户平台，手动检索页面查询	对话入口下发指令，商户Agent自动调用中台API调取数据返回
跨系统业务数据同步	多系统分别登录，人工导出导入流转数据	AI Agent编排多类内外Agent，全自动完成跨系统数据同步流转
全新业务审批流程搭建	研发团队全流程开发测试，上线周期长达数周	业务人员低代码可视化搭建，数小时内完成流程落地启用

三 企业业务平台/中台Agent化路径

明确整体架构后，我们再来看其中最大的变化，也就是原有的业务平台业务中台怎么转换为可被使用的能力或者Agent。首先从交互的角度回到基础的定义，什么是平台，什么是中台：

• 平台：人 ↔ 系统界面。人直接操作商户平台的后台页面。
• 中台：系统 ↔ 系统API。商户中台只暴露能力，人不再直接操作它。
• Agent：人 ↔ Agent ↔ 系统。人跟Agent对话，Agent再去调用中台/能力。商户系统彻底不跟人交互了，它只跟机器（Agent或大模型）交互。

一句话：从平台到中台到Agent，本质是“交互对象的迁移”——人的操作对象从系统界面，变成了智能体。

---

1 起点：业务平台（带UI的完整系统）

以商户平台为例说明：公司原有多个商户系统相互割裂，数据模型不统一，新业务接入慢、资损频发。为此，团队从0到1构建了统一的商户平台。

此时的形态：完整的业务平台，包含前端界面 + 后端逻辑 + 数据存储。用户是运营人员、CA审核人员，他们登录平台、点菜单、填表单，与系统界面直接交互。

特征：人 ↔ 系统界面。界面是用户的唯一入口。

---

2 演化第一步：业务中台（剥离UI，暴露API）

随着业务发展，越来越多其他系统（风控、审批、数据报表）需要访问商户数据。如果每个系统都直接连接数据库，会导致耦合混乱、逻辑重复。

于是，商户平台开始中台化：

• 剥离用户交互界面：运营后台依然存在，但商户的核心能力被封装成API
• 对外暴露原子能力：queryMerchant、updateQualification、submitAudit等
• 独立治理：通过API网关统一鉴权、限流、审计

此时的形态：商户中台。它不再是一个单纯的后台系统，而是一个可复用的能力层，服务于多个上层业务。人不再直接操作中台，而是由其他系统通过API调用。

特征：系统 ↔ 系统API。人的操作对象转移到上层系统（或仍保留原平台界面，但中台本身无界面）。

---

3 演化第二步：CaaS（原子能力进一步拆分）

在商户中台的基础上，进一步将API拆解为更细粒度的原子服务，以支持更灵活的组合：

原有API（粗粒度）	拆解后的原子能力（CaaS）
submitAudit(merchantId, auditData)	validateQualification()、createAuditTask()、notifyApprover()
getMerchantFullInfo(merchantId)	getBasicInfo()、getContactList()、getQualificationStatus()

这些原子能力可以被上层应用自由编排，也可以被AI Agent调用。这一层仍然是系统与系统之间的交互，人依然不直接面对。

CaaS（能力即服务）层：业务中台暴露的细粒度API集合，是可调用的业务原子能力。

---

4 演化第三步：商户Agent（智能体封装）

在CaaS层之上，增加一层智能体——商户Agent。它不再要求调用方精确指定接口和参数，而是通过自然语言对话完成复杂任务。

此时的核心变化：商户系统（中台+CaaS）彻底不跟人交互了，它只跟Agent交互。人的对话对象是Agent，Agent再去调用底层能力。

商户Agent的能力增量：

能力	CaaS原子API	商户Agent
调用方式	代码/REST调用	自然语言对话
意图理解	无，需精确指定接口	自动理解“查一下XX商户的资质” → 调用相关能力
多步编排	需上层自行组合	自动分解任务（查ID→查资质→判断过期）
主动通知	不支持	主动提醒：“商户A资质3天后到期”
上下文记忆	无	记住对话中的商户ID和历史操作
交互对象	系统（开发者/其他服务）	人

特征：人 ↔ Agent ↔ 系统。人的操作对象从系统界面变成了智能体，底层商户系统只与Agent交互。

---

5 演化全路径图

这里的原子能力我理解就是skill

---

6 总结：平台、中台、CaaS、Agent的关系

形态	核心特征	交互方式	复用性	智能化程度	交互对象
业务平台	完整UI+业务逻辑+数据	人机界面	低	无	人 ↔ 系统界面
业务中台	剥离UI，暴露粗粒度API	API调用	中	无	系统 ↔ 系统
CaaS层	细粒度原子能力API	API调用	高	无	系统 ↔ 系统
业务Agent	CaaS + 意图理解 + 编排 + 对话	自然语言	高	有	人 ↔ Agent ↔ 系统

一句话总结：商户平台从“带UI的业务平台”起步，通过剥离界面、暴露API变成业务中台，再通过拆解细粒度能力形成CaaS层，最终封装为商户Agent，让用户通过自然语言对话完成复杂任务。每一次演化，本质上是“交互对象的迁移”——从人直接操作界面，到系统调用API，再到人通过Agent与系统对话。商户系统最终只与机器（Agent）交互，不再面向人。

总结一下

在我看来，AI时代企业业务架构正从传统三层架构，逐步升级为六层全新技术架构，整个演进过程不仅新增了Agent编排治理、大模型服务两大核心层级，还推动业务能力走向原子化拆解，同时把业务交互从传统固定页面操作，升级为更灵活的自然语言对话模式。这种架构变革也直接带动了团队人员结构与工作模式转变，一线业务人员能够自主搭建轻量化业务应用，传统后台研发人员出现明显职业分流，行业也顺势催生了智能体治理、模型工程等全新技术岗位，整体人才结构随之发生明显调整。而从业务系统自身发展来看，也走完了从业务平台人机直连操作，到业务中台系统间API调用，再到CaaS精细化原子能力拆分，最终形成人通过智能体调度底层能力的完整演进链路，其本质就是业务交互对象的持续迁移与数字化能力的层层下沉。对于我们原有业务后端开发人员而言，尽量不要偏向轻量化应用搭建这类偏上浮的工作，更建议主动向下深耕，一方面深耕领域建模、夯实原有业务能力层功底，另一方面主动切入Agent开发与智能体调度相关工作，稳住自身技术核心竞争力，顺应技术发展趋势完成能力升级