陶玉印的博客

企业数据治理、数据仓库、数据质量、AI应用实践与研究

0%

发表于 分类于

第1篇｜从 ChatGPT 到 AI Agent：为什么软件开发进入新时代

AI Agent Engineering 系列（一）

副标题：为什么 AI Agent 不只是 ChatGPT，而是一场新的软件工程革命

适合读者

  • Java / Python 工程师
  • 软件架构师
  • AI 应用开发者
  • 数据工程师
  • 希望转型 AI Agent 工程师的开发人员

一、前言：软件开发，又一次站在了拐点

过去二十年，软件开发经历了几次重要的范式演进。

2005 年，我们讨论的是 MVC。

2012 年，我们讨论的是 REST API。

2016 年，我们讨论的是 微服务。

2020 年，我们讨论的是 云原生（Cloud Native）。

而今天，几乎所有技术大会、开源社区、互联网大厂和创业公司，都在讨论同一个词：

AI Agent。

很多开发者认为：

“Agent 不就是把 ChatGPT 接个 API 吗？”

也有人认为：

“Agent 就是 Dify、Coze、LangGraph 这些开发平台。”

甚至还有人觉得：

“Agent 就是把几个 Prompt 串起来。”

这些理解都不能算错，但都只停留在工具层。

如果把 AI Agent 看成一个聊天机器人，那么你看到的是树叶；如果把 AI Agent 放到软件发展的历史中，你会发现，它更像是一次新的软件开发范式。

这篇文章，我们不讨论任何框架，不写任何 Prompt，也不会调用任何 OpenAI API。

我们只回答一个问题：

为什么越来越多的人认为，软件开发正在进入 Agent 时代？

二、每一次软件革命，本质都是”抽象层”的升级

软件工程的发展，本质上是在不断提高抽象层级。

让开发者越来越少关注底层细节，而越来越关注业务目标。

例如最早写程序时，我们需要自己管理：

1
2
3
4
5
6
7
8
9
CPU

内存

寄存器

文件

网络

后来出现了高级语言。

程序员开始写：

1
2
3
if(order.isPaid()){
    shipment.create();
}

而不用关心汇编指令。

后来出现 MVC。

开发者开始关心：

1
2
3
4
5
Model

View

Controller

而不用再关心页面刷新。

后来出现 ORM。

SQL 变成：

1
userRepository.findById(id)

后来出现 Kubernetes。

部署变成：

1
replicas: 3

而不是自己管理服务器。

每一次革命，都意味着：

程序员需要写的代码越来越少，而表达的业务意图越来越多。

三、过去的软件，本质上是在描述”过程”

传统软件有一个共同特点。

程序员必须提前告诉计算机：

每一步应该怎么做。

例如：

用户下单。

程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
创建订单

↓

检查库存

↓

扣减库存

↓

支付

↓

生成物流

↓

发送短信

整个流程都是：

1
2
3
4
5
6
7
8
9
Input

↓

Code

↓

Output

程序本身就是流程。

如果业务变了。

程序必须修改。

例如：

增加优惠券。

增加积分。

增加满减。

全部需要重新写代码。

因为：

传统软件真正执行的是程序员写好的逻辑。

四、AI Agent，本质上是在描述”目标”

Agent 最大的变化是什么？

它不是描述过程。

而是描述：

目标（Goal）。

例如：

传统程序：

1
2
3
4
5
6
7
create_report()

calculate()

draw_chart()

send_email()

而 Agent：

1
2
3
请分析过去三个月销售下降原因，
生成报告，
并发送给销售总监。

这里没有告诉模型：

第一步做什么。

第二步做什么。

Agent 自己决定。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
理解任务

↓

拆解任务

↓

查询数据库

↓

调用Python分析

↓

生成图表

↓

写报告

↓

发送邮件

↓

结束

注意：

这里的流程。

不是程序员写出来的。

而是：

Agent 在运行过程中动态决定。

这是软件工程第一次：

让程序自己决定执行路径。

五、真正改变软件的，不是聊天，而是”决策能力”

很多人把 ChatGPT 理解成：

一个更聪明的搜索引擎。

实际上。

ChatGPT 最大价值不是回答问题。

而是：

Reasoning（推理）。

推理意味着：

模型可以：

理解目标。

分析问题。

制定计划。

不断修正。

直到完成目标。

于是：

软件开始拥有：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Planning

↓

Reasoning

↓

Action

↓

Observation

↓

Reflection

而不是：

1
2
3
4
5
6
7
if

else

switch

for

这意味着：

软件第一次拥有了：

自主决策能力。

当然，这里的”自主”不是无限制的智能，而是在开发者设定的目标、工具和约束范围内，自主规划完成任务的步骤。

六、AI Agent 与 ChatGPT，到底有什么区别？

很多人第一次接触 Agent 时，会觉得：

“不就是 ChatGPT 加几个 API 吗？”

实际上，两者关注的问题完全不同。

ChatGPT AI Agent
回答问题 完成任务
一次对话 持续执行
生成文本 调用工具
被动回答 主动规划
不保存业务状态 管理任务状态
不操作外部系统 操作真实世界

举一个简单例子。

用户说：

帮我订一张下周去上海的高铁票。

ChatGPT 会回答：

你可以登录 12306。

Agent 则可能：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
打开12306

↓

查询班次

↓

比较价格

↓

选择靠窗座位

↓

提交订单

↓

支付

↓

通知用户

两者最大的区别不是模型。

而是：

Agent 能够行动（Act）。

七、一个真正的 Agent，到底由什么组成？

很多框架喜欢画这样一张图：

1
2
3
4
5
6
7
8
9
User

↓

LLM

↓

Answer

这只是聊天机器人。

真正的 Agent 至少包含下面几个核心模块。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
                    User
                      │
                      ▼
               Goal Manager
                      │
        ┌─────────────┴─────────────┐
        ▼                           ▼
   Planner                    Memory
        │                           │
        ▼                           ▼
 Tool Router  ─────────────► Knowledge
        │
        ▼
  External Tools
(API、数据库、浏览器、代码、Shell)
        │
        ▼
 Observation
        │
        ▼
 Reflection
        │
        ▼
   Final Result

各模块职责如下：

模块 作用
Goal Manager 理解用户真正目标
Planner 将目标拆解为可执行任务
Memory 保存上下文和历史信息
Tool Router 选择合适工具完成任务
Observation 获取工具执行结果
Reflection 判断是否继续执行或调整方案

这也是后续整个系列会逐步展开的内容。

八、为什么说 Agent 是一种新的软件架构？

如果回顾过去二十年的软件架构，我们会发现一个规律：

MVC 解决了界面组织问题。

SOA 解决了系统集成问题。

微服务解决了系统拆分问题。

云原生解决了资源管理问题。

而 Agent 解决的是：

复杂任务如何动态完成。

传统程序：

程序员设计流程。

Agent：

程序员设计目标。

流程由 AI 决定。

因此：

未来的软件，很可能不再是：

1
功能（Function）

而是：

1
能力（Capability）

以前：

软件告诉用户：

我有这些菜单。

以后：

软件问用户：

你的目标是什么？

这是一个非常大的变化。

九、企业场景案例：为什么企业开始关注 Agent？

以一个制造企业的数据分析部门为例。

过去，如果销售总监想了解某产品销量下降原因，通常需要经历以下流程：

  1. 提出分析需求。
  2. 数据工程师编写 SQL。
  3. BI 工程师制作报表。
  4. 分析师撰写分析报告。
  5. 将结果发送给业务部门。

整个过程可能需要数小时甚至数天。

如果构建了企业级 Data Agent，流程会变成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
销售总监：
分析最近三个月华东区域产品A销量下降原因，
重点关注库存、渠道和价格变化。

↓

Agent 拆解任务

↓

查询数据仓库

↓

调用统计分析工具

↓

生成图表

↓

关联库存和价格数据

↓

输出分析结论

↓

形成 PPT 或 Word 报告

↓

发送给销售总监

需要强调的是，这里的 Agent 并不是替代数据仓库、BI 或分析师。它更像是一个能够协调模型、工具、知识和业务流程的智能执行层，让原本需要多个角色串联完成的工作，以更高效率完成。

这也是为什么越来越多的企业开始关注 Agent，但真正落地时，核心挑战往往不是模型，而是数据、工具、权限、流程和工程能力。

十、工程师需要重新学习什么？

如果未来的软件越来越多采用 Agent 架构，那么软件工程师需要补充的能力也会发生变化。

除了传统的软件设计能力之外，还需要理解：

  • LLM 如何理解和推理任务。
  • Prompt 如何像代码一样设计和维护。
  • Tool 如何安全、稳定地接入业务系统。
  • Memory 如何管理上下文和长期知识。
  • Workflow 如何组织复杂任务。
  • 多 Agent 如何协同完成大型业务流程。
  • 如何评估 Agent 的效果、成本和可靠性。

这并不意味着传统软件工程知识会失效。相反，分布式系统、架构设计、数据库、缓存、消息队列、权限、安全、监控等能力，在 Agent 系统中仍然是基础，只是需要与 AI 能力结合。

总结

很多人认为 AI Agent 的出现，只是多了一种新的 AI 开发框架。

但站在软件发展的历史中，它更像是一次新的软件工程范式演进。

过去的软件：

程序员决定执行过程。

未来越来越多的软件：

程序员定义目标，Agent 动态规划执行路径。

这并不意味着传统软件会消失，而是意味着未来的软件将更多地由确定性程序与基于大模型的智能决策共同组成。

这，就是 AI Agent 与传统软件最大的不同，也是我们开启《AI Agent Engineering》系列的起点。

发表于

在和一些年轻的数据工程师交流时，我发现一个有趣的现象。

很多人每天都在开发ODS、DWD、DWS、ADS。

熟悉Hive、Spark、Flink、ClickHouse。

却很少认真思考过一个问题：

为什么企业需要数据仓库？

尤其是在AI快速发展的今天。

越来越多的人开始提出类似的问题：

  • 有了湖仓一体，还需要数据仓库吗？
  • 有了ChatBI，还需要数据仓库吗？
  • Agent能够自动生成SQL，还需要数据仓库吗？

在回答这些问题之前，我们需要先回到数据仓库诞生的那个时代。

因为只有理解它为什么出现，才能理解它为什么至今仍然存在。

企业最早并没有数据仓库

今天很多企业的数据架构看起来似乎理所当然：

1
ERP → 数据仓库 → BI → 报表

但实际上，大多数企业最初并没有数据仓库。

在信息化建设初期，企业通常只有几个核心业务系统：

  • ERP
  • 财务系统
  • CRM
  • HR系统

当管理层需要数据时，往往直接从业务系统查询。

例如：

销售总监问：

“本月销售额是多少？”

技术人员登录ERP数据库。

执行一条SQL。

得到结果。

似乎没有任何问题。

因为那时：

  • 数据量不大
  • 系统数量不多
  • 分析需求简单

业务系统同时承担：

  • 交易处理
  • 数据存储
  • 数据分析

三种职责。

但随着企业规模扩大，问题开始逐渐暴露。

第一个问题：业务系统不是为分析而设计的

ERP最重要的任务是什么？

是保证订单能够正常流转。

CRM最重要的任务是什么？

是保证客户管理流程正常运行。

MES最重要的任务是什么？

是保证生产过程可控。

这些系统有一个共同特点：

它们都属于OLTP系统（联机事务处理系统）。

其核心目标是：

  • 快速写入
  • 快速更新
  • 高并发事务

而数据分析恰恰相反。

分析系统更关注：

  • 大量历史数据
  • 多表关联计算
  • 聚合统计分析

例如：

业务系统可能需要快速保存一笔订单。

而分析系统则希望统计：

过去三年各区域产品销售趋势。

这是两种完全不同的工作模式。

如果直接在ERP上执行复杂分析：

轻则查询缓慢。

重则影响业务运行。

因此：

业务系统适合处理交易，不适合处理分析。

这是数据仓库存在的第一个原因。

第二个问题：企业的数据是分散的

很多企业管理层都喜欢问这样的问题：

“哪个客户最赚钱？”

看起来很简单。

但实际计算往往涉及多个系统：

销售额来自CRM。

成本来自ERP。

回款来自财务系统。

物流费用来自供应链系统。

如果没有统一的数据平台。

每次分析都需要跨系统取数。

不仅效率低。

而且很容易出现口径不一致的问题。

例如：

销售部门说客户A贡献利润500万元。

财务部门说只有350万元。

双方都认为自己正确。

问题出在哪里？

不是数据错了。

而是计算逻辑不同。

企业真正需要的不是更多数据。

而是统一的数据语言。

这正是数据仓库解决的核心问题之一。

第三个问题：业务系统只关心现在

业务系统关注的是当前状态。

例如ERP中的库存表。

今天库存100件。

明天库存80件。

后天库存120件。

ERP只需要记录当前库存。

但管理层更关心：

  • 库存变化趋势
  • 历史库存水平
  • 周转率变化

这些分析都需要历史数据。

而历史数据往往不会长期保存在业务系统中。

于是企业开始把业务数据持续同步出来。

形成历史快照。

构建分析主题。

这也是数据仓库的重要价值。

它不仅存储数据。

更保存企业经营过程中的历史记忆。

第四个问题：企业需要统一指标

很多企业都有一个经典现象。

开会时讨论同一个指标。

不同部门拿出不同数字。

例如：

“上个月销售额是多少？”

销售部门：

1.2亿元。

财务部门：

1.05亿元。

运营部门：

1.1亿元。

数据部门：

1.15亿元。

每个人都能解释自己的计算逻辑。

但最终没人知道哪个数字才是正确的。

问题本质上不是数据问题。

而是指标问题。

数据仓库建设过程中。

企业第一次开始系统化思考：

  • 什么是销售额？
  • 什么是利润？
  • 什么是客户数？
  • 什么是新增用户？

通过统一口径。

企业建立起共同的数据语言。

从某种意义上说：

数据仓库最大的价值不是存储数据，而是统一认知。

数据仓库真正解决了什么？

如果把前面的问题总结一下。

数据仓库解决的并不是简单的数据存储问题。

而是四个核心问题：

第一：

让业务系统专注交易处理。

第二：

打通企业数据孤岛。

第三：

沉淀历史数据资产。

第四：

统一企业指标体系。

因此。

数据仓库的本质不是一个数据库。

而是一套数据组织方法。

是一种让企业能够理解自身经营状况的基础设施。

AI时代，数据仓库为什么依然重要？

最近两年。

很多人开始讨论：

ChatBI。

Data Agent。

自然语言问数。

智能分析。

似乎未来不再需要数据仓库。

但实际上。

这些新技术恰恰更加依赖数据仓库。

我们可以思考一个简单问题：

如果企业内部存在三个版本的销售额。

Agent应该相信谁？

如果客户名称在不同系统中不一致。

Agent应该分析哪个客户？

如果历史数据缺失。

Agent如何完成趋势分析？

如果数据质量存在问题。

Agent如何保证回答正确？

答案很简单。

Agent不会自动创造事实。

Agent只能利用已有事实。

而数据仓库正是企业事实的组织者。

过去：

数据仓库服务BI。

未来：

数据仓库服务Agent。

它的角色会变化。

但其核心价值不会消失。

数据仓库最大的价值，其实是降低沟通成本

很多人认为数据仓库的价值在于技术。

我越来越觉得不是。

数据仓库最大的价值其实是：

降低组织沟通成本。

当企业拥有统一的数据口径时：

销售和财务不再争论数字。

业务和技术不再争论规则。

管理层不再争论结果。

大家能够把精力放在真正重要的问题上：

为什么会这样？

应该怎么办？

而不是：

数字到底哪个对？

从这个角度看。

数据仓库从来不是技术项目。

而是企业管理能力建设的一部分。

写在最后

过去二十年。

数据仓库之所以能够成为企业数据体系的核心。

并不是因为它拥有最先进的技术。

而是因为它解决了企业最本质的问题：

让企业能够用统一的语言理解自己的经营状况。

AI不会改变这一点。

ChatBI不会改变这一点。

Data Agent也不会改变这一点。

未来发生变化的。

只是数据被消费的方式。

而不会是数据被组织的逻辑。

下一篇文章，我们继续讨论另一个关键问题：

BI为什么成为企业数据消费的主流模式？

发表于 更新于

过去二十年，企业数据领域发生过很多变化。

数据库、数据仓库、大数据平台、数据治理、BI、数据中台、湖仓一体、ChatBI、Data Agent……

新概念层出不穷，新技术不断涌现。

但如果站在更高的视角来看，这二十年的变化，本质上是在解决同一个问题：

如何更快、更准确地获得答案。

今天很多人在讨论AI、Agent、ChatBI。

有人说数据仓库会消失，有人说BI将被取代，还有人认为未来根本不需要数据开发工程师。

这些观点听起来很有冲击力，但如果不了解企业数据体系的发展历程，就很容易得出片面的结论。

因此，在讨论AI会带来什么变化之前，我们不妨先回顾一下企业数据开发范式过去二十年的演进历程。

第一阶段：数据库时代——直接从业务系统取数

大约在2000年前后，大多数企业的信息化建设刚刚起步。

企业中的核心系统主要是：

  • ERP
  • 财务系统
  • 进销存系统
  • 人事系统

那时的数据分析需求并不复杂。

业务人员提出问题：

“这个月销售额是多少？”

技术人员登录数据库，写一条SQL。

很快就能得到结果。

那时的数据开发范式可以简单概括为：

1
业务系统 = 数据源 = 分析系统

所有分析工作直接基于业务数据库完成。

这种模式在企业规模较小时运行良好。

但随着企业发展，问题逐渐出现。

例如：

  • ERP关注交易处理
  • 财务系统关注账务处理
  • CRM关注客户管理

每个系统的数据标准不同。

每个系统的数据口径不同。

每个系统都只关注自身业务。

当企业希望回答：

“某客户的销售额、利润和回款情况如何？”

就需要跨多个系统进行关联分析。

此时，数据库时代开始暴露出局限性。

企业需要一种新的数据组织方式。

数据仓库由此诞生。

第二阶段：数据仓库时代——让数据形成统一语言

从2005年前后开始，越来越多企业开始建设数据仓库。

数据仓库的核心思想并不复杂：

把分散在各业务系统中的数据统一汇集起来。

通过清洗、转换、整合。

形成统一的数据资产。

此时，企业数据架构开始演变为：

1
业务系统 → 数据集成 → 数据仓库 → 数据应用

对于很多企业而言，这是一次巨大的进步。

数据仓库解决了几个关键问题：

第一，统一数据口径。

同一个指标不再出现多个版本。

第二，沉淀历史数据。

业务系统可能只保留当前状态。

数据仓库可以保留完整历史轨迹。

第三，提高分析效率。

复杂分析不再直接访问业务数据库。

第四，实现跨系统分析。

企业第一次能够从全局视角看待经营数据。

也正是在这一时期，维度建模、星型模型、事实表、维度表等概念开始广泛普及。

很多企业的数据团队开始形成：

  • ETL开发工程师
  • 数据仓库工程师
  • BI工程师

等专业岗位。

数据开发开始进入工程化时代。

第三阶段：BI时代——从数据到决策

如果说数据仓库解决的是“数据从哪里来”的问题。

那么BI解决的是：

“数据如何被使用”的问题。

从2010年以后，越来越多企业开始建设：

  • 经营驾驶舱
  • 管理看板
  • KPI体系
  • 数据分析平台

FineBI、Tableau、Power BI等产品快速发展。

企业开始尝试用数据驱动决策。

此时的数据开发范式变成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
业务系统

↓

数据仓库

↓

OLAP

↓

BI

↓

决策分析

这也是很多企业今天仍然在采用的主流架构。

这一模式极大提升了企业的数据使用效率。

但与此同时，一个新的问题开始出现。

所有答案都需要提前准备。

  • 业务提出需求。
  • 数据团队开发ETL。
  • 开发指标。
  • 开发报表。
  • 测试上线。

最终才能看到结果。

很多企业都经历过这样的场景：

业务部门提出一个分析需求。

排期两周。

开发一周。

测试三天。

上线一天。

最后花费近一个月时间。

而业务真正关心的问题，可能只需要一个答案。

问题并不在于技术。

而在于这种模式本质上属于：

先开发答案，再提出问题。

这也为下一轮变革埋下伏笔。

第四阶段：AI时代——从开发答案到生成答案

2022年以后，大模型开始快速发展。

ChatGPT、Claude、DeepSeek等产品让自然语言交互成为现实。

与此同时，企业数据领域也开始出现新的变化。

ChatBI开始流行。

智能问数开始普及。

企业知识库快速增长。

Data Agent不断涌现。

过去的数据分析过程通常是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
提出问题

↓

提交需求

↓

开发模型

↓

开发报表

↓

获得答案

而今天越来越多企业开始尝试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
提出问题

↓

Agent理解问题

↓

自动检索数据

↓

自动生成SQL

↓

自动分析

↓

获得答案

两种模式最大的区别在于：

过去是开发答案。

现在是生成答案。

这是企业数据开发范式过去二十年来最重要的一次变化。

AI会取代数据仓库吗？

这是最近两年被问得最多的问题之一。

我的观点很明确：

不会，至少在可预见的未来不会。

因为AI解决的是答案生成问题，而数据仓库解决的是数据组织问题。两者并不是替代关系。

Agent越强，越依赖高质量的数据基础。

ChatBI越智能，越需要统一的数据口径。

企业知识库越丰富，越需要高质量的数据治理。

未来消失的不会是数据仓库，而是数据仓库作为最终消费终端的角色。

它会逐渐退居幕后，成为Agent的数据底座。

下一代企业数据体系正在形成

回顾过去二十年。

企业数据体系经历了四次重要演进：

数据库时代：

解决数据存储问题。

数据仓库时代：

解决数据整合问题。

BI时代：

解决数据消费问题。

AI时代：

解决答案生成问题。

每一次演进，都不是推翻上一代体系。

而是在上一代基础上的能力扩展。

因此，我并不认为AI会终结企业数据体系。

AI正在推动企业数据体系进入一个新的阶段。

未来五年。

真正值得关注的问题不是：

“数据仓库会不会消失？”

而是：

“企业如何构建能够支撑Agent的数据体系？”

这也是本专栏接下来希望持续探讨的话题。

下一篇，我们将从一个最基础的问题开始：

为什么企业需要数据仓库？