#DeepSeek、Qwen、GLM 都在卷 Coding，Java 开发者真正应该学什么？

最近如果你一直关注 AI 编程，会有一种很明显的感觉：

Coding 这条赛道突然越来越挤了。

DeepSeek 在卷 Coding 和 Agent，Qwen Code 在快速补齐 CLI、IDE、MCP、Subagent、Skills、Extensions，GLM 也在继续强化 Coding 能力。

8 月 13 日，DeepSeek V4 Pro 正式上线，官方直接把"Agent 能力大幅提升"作为重点，并原生支持 Responses API，可以配置到 Codex 中使用。citeturn0news21turn0news54

Qwen Code 最近更新得更快，不仅支持多个模型 Provider，还已经有 JetBrains ACP 集成、Code Review、Extensions，甚至提供实验性的 Agent Arena，可以让多个 AI 同时处理一个任务再比较结果。citeturn0news26turn0news31turn0news33turn0news37

智谱最新发布的 GLM-5.3，同样把 Coding 作为重点能力。citeturn0news17

于是一个很现实的问题来了：

Java 开发者到底还要不要学 AI？如果要学，真正应该学什么？

我自己的答案是：

要学。

但如果现在还把"学习 AI 编程"理解成学习怎么调用一个大模型 API，已经有点晚了。

一、先别急着押注哪个模型

现在经常能看到类似讨论：

DeepSeek 和 Claude Code 谁更适合写代码？

或者：

Qwen Code 能不能替代 Codex？

再或者：

GLM Coding 到底怎么样？

这些问题当然可以研究。

但对于一个 Java 开发者来说，我认为它们并不是最重要的问题。

因为今天你可能觉得：

复制代码

Claude > DeepSeek > Qwen

几个月以后完全可能变成另外一个排序。

模型会不断更新，价格会不断变化，Coding Agent 也会不断变化。

如果你的能力最终变成：

"我特别会使用某一个 AI Coding 工具。"

那么这个优势其实并不牢固。

真正应该建立的是：

无论模型怎么变化，我都知道怎么把 AI 接进真实的软件系统。

这才是 Java 开发者真正应该建立的能力。

二、第一层：先学会用 Coding Agent，而不是只用 AI 补全代码

以前我们使用 AI 编程，很多时候是：

复制代码

写一个 UserController

AI 给你：

kotlin 复制代码

@RestController
public class UserController {
}

然后复制进去。

这其实还是：

AI Code Completion

现在 Coding Agent 已经完全不是这个思路了。

它开始可以：

复制代码

读取项目
↓
理解需求
↓
分析代码
↓
制定修改计划
↓
修改多个文件
↓
执行测试
↓
发现错误
↓
继续修改
↓
提交结果

这才是 Agent。

所以 Java 开发者第一件应该学习的事情，其实不是换语言，而是改变自己的开发方式。

比如以前一个需求：

给订单系统增加订单取消功能。

你可能直接让 AI：

帮我写订单取消接口。

现在更合理的方法是先把任务拆清楚：

复制代码

需求
↓
Issue
↓
Plan
↓
Implementation
↓
Test
↓
Review
↓
PR

然后让 Coding Agent参与其中。

也就是说：

未来程序员真正重要的能力，会越来越偏向"定义任务"和"验收结果"。

三、第二层：学会给 Agent 提供项目上下文

很多人第一次使用 Codex、Claude Code 或 Qwen Code 时，会觉得：

怎么 AI 老是改错？

一个很重要的原因是：

AI 根本不知道你的项目规则。

例如你的 Java 项目可能规定：

Controller 不能直接调用 Mapper；
DTO 和 Entity 必须分离；
所有接口必须统一 Result；
数据库禁止物理删除；
SQL 必须兼容某个数据库；
新功能必须增加单元测试。

这些东西模型天然不知道。

所以现在越来越重要的一种工程能力叫：

Agent Context Engineering

例如在项目里维护：

复制代码

AGENTS.md

docs/
├── architecture.md
├── database.md
├── conventions.md
└── security.md

把架构、规范、测试方式、禁止事项写清楚。

以后你给 Agent 的任务就不再是：

帮我开发这个功能。

而是：

阅读 AGENTS.md 和 architecture.md，根据 Issue #38 完成功能，禁止修改 authentication 模块，完成后执行测试并检查数据库兼容性。

AI 编程质量会明显不一样。

四、第三层：Java 开发者应该重点学习 Tool Calling

这是我认为接下来非常重要的一项能力。

一个模型如果只能：

输入文字 → 输出文字

本质上仍然只是 Chat。

真正的 Agent 一定需要调用外部能力。

例如：

复制代码

Agent
 ↓
查询数据库
 ↓
调用企业API
 ↓
读取文件
 ↓
搜索知识库
 ↓
发送消息
 ↓
创建任务

这些能力背后的核心就是：

Tool Calling。

Spring AI 已经提供比较完整的 Tool Calling 抽象，可以通过 @Tool 或 ToolCallback 将 Java 方法暴露给模型，而且实际 Tool 的执行仍然由应用程序控制，而不是模型直接获得系统 API 权限。citeturn0search1

例如：

typescript 复制代码

@Tool(description = "查询订单信息")
public Order getOrder(String orderNo) {
    return orderService.getOrder(orderNo);
}

模型负责判断：

我现在需要查询订单。

Java 系统负责真正执行：

scss 复制代码

getOrder()

这一下就把 Java 开发者原来的优势重新带回来了。

因为企业真正有价值的东西本来就在：

复制代码

数据库
API
业务系统
权限
工作流

而这些恰恰是 Java 开发者熟悉的领域。

五、第四层：MCP 值得学，但不要只会写 Demo

Tool Calling 再往前一步，就是最近非常火的 MCP。

MCP 解决的是：

如何用统一协议让 AI 应用发现并调用外部工具和资源。

Spring 本身也是 MCP Java 生态的重要参与者，Spring AI 已经提供 MCP Client、Server、Boot Starter 和注解支持。citeturn0search0turn0search2

所以对于 Java 开发者来说，现在学习 MCP 的门槛其实已经不算高。

但这里有一个很容易踩的坑：

不要学完以后只会做：

arduino 复制代码

天气 MCP Server

然后：

scss 复制代码

AI
↓
getWeather()
↓
郑州 28℃

Demo 做一遍理解协议就够了。

真正值得研究的是：

arduino 复制代码

MCP Server
↓
Tool Discovery
↓
Authentication
↓
Authorization
↓
Policy
↓
Execution
↓
Audit

因为企业真正担心的是：

Agent 能调用什么？

而不是：

Agent 会不会调用工具？

六、第五层：Agent 的权限和安全会越来越重要

假设未来公司的 Coding Agent 可以：

复制代码

读取 GitHub
修改代码
执行 Shell
查询数据库
调用 Jenkins
发布服务

那么问题来了：

AI 能不能直接删除数据库？

显然不能。

所以以后 Agent 系统一定需要类似这样的权限体系：

复制代码

READ
自动允许
WRITE
根据权限执行
HIGH_RISK
人工审批
DESTRUCTIVE
默认拒绝

比如：

sql 复制代码

查询订单
→ ALLOW
修改订单
→ APPROVAL
执行生产SQL
→ HIGH_RISK
DROP DATABASE
→ DENY

我认为这一层未来会成为企业 Agent 很重要的基础设施。

而这恰恰也是传统后端开发者比较熟悉的领域：

RBAC、鉴权、审计、审批、日志、风控。

所以 Java 开发者不应该因为 Python 在 AI 领域流行，就觉得自己的经验全部过时了。

恰恰相反。

Agent 真正进入企业之后，很多问题最终又回到了传统软件工程。

七、第六层：学会做 Agent Observability

还有一个很容易被忽略的问题。

Agent 出错以后怎么办？

普通接口调用很好理解：

vbscript 复制代码

Request
↓
Service
↓
Database
↓
Response

但是 Agent 可能是：

css 复制代码

用户任务
↓
Planner
↓
模型
↓
Tool A
↓
模型
↓
Tool B
↓
Sub Agent
↓
模型
↓
最终结果

一个任务可能跑几分钟，甚至更久。

这时候传统的一条 application log 已经很难解释问题。

所以需要记录：

arduino 复制代码

Task
↓
Trace
↓
Event

例如：

复制代码

TASK_STARTED
MODEL_CALL
TOOL_CALL
TOOL_RESULT
MODEL_CALL
APPROVAL_REQUESTED
APPROVAL_GRANTED
TASK_COMPLETED

最终你应该能够回答：

Agent 为什么做这个决定？
调用了哪个模型？
调用了哪个 Tool？
哪一步失败了？
整个任务花了多少钱？

这就是：

Agent Observability。

八、第七层：不要忽略 Token 和成本

以前开发普通 Java 系统，我们通常不会思考：

Controller 调一次多少钱？

AI 不一样。

每一次：

sql 复制代码

Model Call

背后都有真实成本。

于是未来开发 Agent，除了传统指标：

javascript 复制代码

QPS
CPU
Memory
Latency
Error Rate

还会增加：

arduino 复制代码

Input Token
Output Token
Model Cost
Cost / Task
Cost / Successful Task

甚至不同模型之间需要自动选择。

比如：

复制代码

简单任务
→ 低成本模型
复杂Coding
→ 强模型
后台批处理
→ 低价模型
实时交互
→ 低延迟模型

所以未来模型路由可能不再只是：

ini 复制代码

if model == xxx

而是：

复制代码

Cost
×
Quality
×
Latency
×
Availability

这其实已经开始变成一个新的工程领域。

九、那 Spring AI 到底值不值得学？

我的答案是：

值得。

但不要把目标定成：

学会 Spring AI API。

Spring AI 当前已经覆盖 Model API、ChatClient、Tool Calling、Advisor、Vector Store、MCP 等能力，并且目标本身就是让 Spring 开发者利用熟悉的编程模型构建 AI 应用。citeturn0search3turn0search4

所以更合理的学习方式应该是：

复制代码

Spring AI
↓
Tool Calling
↓
MCP
↓
Agent Workflow
↓
Observability
↓
Security
↓
Cost
↓
Production

最终做出来一个：

真正能运行的 Java Agent。

而不是再写一个：

bash 复制代码

POST /chat

调用大模型返回一句话。

这种 Demo 现在已经很难形成竞争力。

十、Java 开发者真正的优势是什么？

我现在越来越觉得：

AI 时代 Java 开发者真正应该做的，并不是和 Python 开发者竞争：

谁更会训练模型。

而应该发挥自己的优势：

复制代码

Spring Boot
微服务
数据库
Redis
MQ
权限
工作流
分布式系统
可观测
DevOps
企业系统

然后在上面增加：

复制代码

LLM
Agent
Tool Calling
MCP
Coding Agent

最终能力变成：

AI + Software Engineering

而不是：

Prompt Engineering

这两者的职业壁垒完全不是一个等级。

十一、如果现在重新规划学习路线，我会这样排

如果是一个已经有几年 Java 开发经验的程序员，我建议：

第一阶段：AI Coding

先真正使用：

css 复制代码

Codex
Claude Code
Qwen Code

让 AI 开始参与真实项目，而不是只问代码问题。

第二阶段：Spring AI

重点学习：

复制代码

ChatClient
Model API
Structured Output
Tool Calling
Advisor

第三阶段：MCP

学习：

arduino 复制代码

MCP Client
MCP Server
Tool Discovery
Resource
Transport

Spring AI 已经有比较完整的 Java/MCP 支持，因此完全可以沿着原有 Spring 技术栈继续深入。citeturn0search0turn0search2

第四阶段：Agent

自己实现一个真实任务：

vbnet 复制代码

Goal
↓
Plan
↓
Tool
↓
Result
↓
Continue / Stop

不要先追求 Multi-Agent。

先把一个 Agent 做稳定。

第五阶段：工程化

开始解决：

复制代码

Trace
Retry
Timeout
Fallback
Cost
Security
Approval
Evaluation

到了这一层，你才真正开始和"只会调用大模型 API"的开发者拉开差距。

十二、最后

DeepSeek、Qwen、GLM 继续卷 Coding，我认为对于 Java 开发者其实是一件好事。

因为模型越来越强以后：

写代码本身会越来越便宜。

但与此同时：

如何让 AI 安全地访问企业系统？
如何管理几十个 Agent？
如何控制 Token 成本？
如何知道 Agent 为什么失败？
如何管理 MCP Tool 权限？
如何判断一个 Agent 到底有没有创造价值？

这些问题反而会越来越重要。

所以我现在并不太担心：

"AI 会不会让 Java 没用了？"

我更关心的是另一个问题：

当 AI 真正进入企业软件之后，你还是一个只会 CRUD 的 Java 开发者，还是已经能够设计和治理 Agent 系统的 AI 工程师？

这可能才是未来几年真正拉开差距的地方。

参考资料

如果你也是 Java 开发者，你现在最想补的是 AI Coding、Spring AI、MCP，还是 Agent 工程化？

欢迎在评论区交流。