第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 | CPU |
后来出现了高级语言。
程序员开始写:
1 | if(order.isPaid()){ |
而不用关心汇编指令。
后来出现 MVC。
开发者开始关心:
1 | Model |
而不用再关心页面刷新。
后来出现 ORM。
SQL 变成:
1 | userRepository.findById(id) |
后来出现 Kubernetes。
部署变成:
1 | replicas: 3 |
而不是自己管理服务器。
每一次革命,都意味着:
程序员需要写的代码越来越少,而表达的业务意图越来越多。
三、过去的软件,本质上是在描述”过程”
传统软件有一个共同特点。
程序员必须提前告诉计算机:
每一步应该怎么做。
例如:
用户下单。
程序:
1 | 创建订单 |
整个流程都是:
1 | Input |
程序本身就是流程。
如果业务变了。
程序必须修改。
例如:
增加优惠券。
增加积分。
增加满减。
全部需要重新写代码。
因为:
传统软件真正执行的是程序员写好的逻辑。
四、AI Agent,本质上是在描述”目标”
Agent 最大的变化是什么?
它不是描述过程。
而是描述:
目标(Goal)。
例如:
传统程序:
1 | create_report() |
而 Agent:
1 | 请分析过去三个月销售下降原因, |
这里没有告诉模型:
第一步做什么。
第二步做什么。
Agent 自己决定。
例如:
1 | 理解任务 |
注意:
这里的流程。
不是程序员写出来的。
而是:
Agent 在运行过程中动态决定。
这是软件工程第一次:
让程序自己决定执行路径。
五、真正改变软件的,不是聊天,而是”决策能力”
很多人把 ChatGPT 理解成:
一个更聪明的搜索引擎。
实际上。
ChatGPT 最大价值不是回答问题。
而是:
Reasoning(推理)。
推理意味着:
模型可以:
理解目标。
分析问题。
制定计划。
不断修正。
直到完成目标。
于是:
软件开始拥有:
1 | Planning |
而不是:
1 | if |
这意味着:
软件第一次拥有了:
自主决策能力。
当然,这里的”自主”不是无限制的智能,而是在开发者设定的目标、工具和约束范围内,自主规划完成任务的步骤。
六、AI Agent 与 ChatGPT,到底有什么区别?
很多人第一次接触 Agent 时,会觉得:
“不就是 ChatGPT 加几个 API 吗?”
实际上,两者关注的问题完全不同。
| ChatGPT | AI Agent |
|---|---|
| 回答问题 | 完成任务 |
| 一次对话 | 持续执行 |
| 生成文本 | 调用工具 |
| 被动回答 | 主动规划 |
| 不保存业务状态 | 管理任务状态 |
| 不操作外部系统 | 操作真实世界 |
举一个简单例子。
用户说:
帮我订一张下周去上海的高铁票。
ChatGPT 会回答:
你可以登录 12306。
Agent 则可能:
1 | 打开12306 |
两者最大的区别不是模型。
而是:
Agent 能够行动(Act)。
七、一个真正的 Agent,到底由什么组成?
很多框架喜欢画这样一张图:
1 | User |
这只是聊天机器人。
真正的 Agent 至少包含下面几个核心模块。
1 | User |
各模块职责如下:
| 模块 | 作用 |
|---|---|
| Goal Manager | 理解用户真正目标 |
| Planner | 将目标拆解为可执行任务 |
| Memory | 保存上下文和历史信息 |
| Tool Router | 选择合适工具完成任务 |
| Observation | 获取工具执行结果 |
| Reflection | 判断是否继续执行或调整方案 |
这也是后续整个系列会逐步展开的内容。
八、为什么说 Agent 是一种新的软件架构?
如果回顾过去二十年的软件架构,我们会发现一个规律:
MVC 解决了界面组织问题。
SOA 解决了系统集成问题。
微服务解决了系统拆分问题。
云原生解决了资源管理问题。
而 Agent 解决的是:
复杂任务如何动态完成。
传统程序:
程序员设计流程。
Agent:
程序员设计目标。
流程由 AI 决定。
因此:
未来的软件,很可能不再是:
1 | 功能(Function) |
而是:
1 | 能力(Capability) |
以前:
软件告诉用户:
我有这些菜单。
以后:
软件问用户:
你的目标是什么?
这是一个非常大的变化。
九、企业场景案例:为什么企业开始关注 Agent?
以一个制造企业的数据分析部门为例。
过去,如果销售总监想了解某产品销量下降原因,通常需要经历以下流程:
- 提出分析需求。
- 数据工程师编写 SQL。
- BI 工程师制作报表。
- 分析师撰写分析报告。
- 将结果发送给业务部门。
整个过程可能需要数小时甚至数天。
如果构建了企业级 Data Agent,流程会变成:
1 | 销售总监: |
需要强调的是,这里的 Agent 并不是替代数据仓库、BI 或分析师。它更像是一个能够协调模型、工具、知识和业务流程的智能执行层,让原本需要多个角色串联完成的工作,以更高效率完成。
这也是为什么越来越多的企业开始关注 Agent,但真正落地时,核心挑战往往不是模型,而是数据、工具、权限、流程和工程能力。
十、工程师需要重新学习什么?
如果未来的软件越来越多采用 Agent 架构,那么软件工程师需要补充的能力也会发生变化。
除了传统的软件设计能力之外,还需要理解:
- LLM 如何理解和推理任务。
- Prompt 如何像代码一样设计和维护。
- Tool 如何安全、稳定地接入业务系统。
- Memory 如何管理上下文和长期知识。
- Workflow 如何组织复杂任务。
- 多 Agent 如何协同完成大型业务流程。
- 如何评估 Agent 的效果、成本和可靠性。
这并不意味着传统软件工程知识会失效。相反,分布式系统、架构设计、数据库、缓存、消息队列、权限、安全、监控等能力,在 Agent 系统中仍然是基础,只是需要与 AI 能力结合。
总结
很多人认为 AI Agent 的出现,只是多了一种新的 AI 开发框架。
但站在软件发展的历史中,它更像是一次新的软件工程范式演进。
过去的软件:
程序员决定执行过程。
未来越来越多的软件:
程序员定义目标,Agent 动态规划执行路径。
这并不意味着传统软件会消失,而是意味着未来的软件将更多地由确定性程序与基于大模型的智能决策共同组成。
这,就是 AI Agent 与传统软件最大的不同,也是我们开启《AI Agent Engineering》系列的起点。