同一周里，甲骨文在年报里承认AI让员工数下降，一年减了约3万人；DeepSeek放出约150个岗位，全部是服务端和Agent弹性计算，没有一个研究岗。这不是一冷一热两家公司，是同一份化验单上的两个指标。
目录
- 先把数字摆出来：3万 和 150
- 再补三组数据，看清楚挤压的是哪一层
- 后端手里的牌，比你以为的好
- 一个能跑起来的最小Agent（Go版）
- 简历怎么把老项目翻译成AI语言
- 三种最常见的错误姿势
- 一周能做完的落地清单
1. 先把数字摆出来：3万 和 150
甲骨文2025年报里那句话写得很直接：AI技术的应用已导致并将继续导致员工人数减少。一年下来，减了大概3万人。
同一周，DeepSeek放了约150个岗位出来。全看下来，没有一个研究岗，全是资深服务端开发、Agent弹性计算这类。
一个在砍，一个在招。
如果只看单个公司，这是两家公司各自的命运。放在一起看，是同一件事：能被AI批量接管的编码工作在被压缩，暂时离不开人的那部分在被抬价。
2. 再补三组数据，看清楚挤压的是哪一层
单看两个数字容易想岔，我把最近能查到的三组数据摆上来：
- 谷歌内部新增代码里AI生成占比到了75%，两年前是15%。
- 美国22到25岁初级开发的就业人数，从2022年底峰值到2025年中跌了接近20%。
- 脉脉2026年7月的AI人才流动报告：新发AI岗位里应用开发类占60.97%，模型训练基建类只有24.55%。
第三组最值得看。市场缺的不是训模型的人，是能把模型塞进业务系统里跑起来的人。
同一份报告点了一个岗位叫FDE（前沿部署工程师），同比涨了1522%。做的事是把训练好的模型接进生产环境、重设计工作流、把Agent部署到客户环境里，还要验证真跑出结果。
瓶颈已经从"能不能训出来"变成了"能不能用起来、扛不扛得住真实流量"。这一步恰恰是后端的主场。
3. 后端手里的牌，比你以为的好
很多后端一听转AI就头疼，觉得要从零学一门语言。这个判断不成立。
Agent应用开发真正要的东西，后端干了几年基本都有：
| Agent应用开发的要求 | 你的老本行 | 真正要补的 |
|---|---|---|
| 服务端稳定性和并发 | 本来就会 | 无 |
| 和外部系统对接 | 接口调用天天写 | 无 |
| 把一个模糊需求拆成可执行流程 | 需求拆解就是日常 | 无 |
| 日志、监控、回滚 | 本来就会 | 无 |
| RAG检索链路 | 接触过搜索和索引 | 向量库、切片策略、召回调优 |
| Agent编排和多轮会话 | 接触过工作流 | LangGraph / Eino 的用法 |
| Prompt和上下文管理 | 没有直接对应 | 结构化提示词、上下文裁剪 |
前面几行全是存量资产，真正要从零补的只有最后三行。
我写过一本书叫《企业级高并发Agent实战》，主题就是这个：不是教你调一个对话接口，而是怎么用Go加Python把一个Agent做成扛得住高并发、能接真实业务、能上线的系统。写书那阵最深的感受是，难的地方从来不在模型，在工程。
4. 一个能跑起来的最小Agent（Go版）
别一上来就搞多Agent编排。先把手弄脏，跑通单Agent加工具调用的闭环，这是最值钱的一步。
下面是一个用 Go 写的、带工具调用的最小闭环骨架：
go
package main
import (
"context"
"encoding/json"
"fmt"
"log"
"time"
)
// Tool 描述一个可被模型调用的工具
type Tool struct {
Name string `json:"name"`
Description string `json:"description"`
Parameters map[string]string `json:"parameters"`
Handler func(ctx context.Context, args map[string]any) (string, error)
}
// Agent 最小可用闭环：接收目标 -> 决定是否用工具 -> 执行 -> 汇总
type Agent struct {
Tools map[string]Tool
MaxStep int
}
func (a *Agent) Run(ctx context.Context, goal string) (string, error) {
messages := []string{goal}
for step := 0; step < a.MaxStep; step++ {
// 1. 让模型决定这一步要不要调工具（实际场景替换为真实 LLM 调用）
decision, err := a.decide(ctx, messages)
if err != nil {
return "", err
}
if decision.ToolName == "" {
return decision.FinalAnswer, nil
}
// 2. 拿到工具并执行
tool, ok := a.Tools[decision.ToolName]
if !ok {
return "", fmt.Errorf("未知工具: %s", decision.ToolName)
}
ctxT, cancel := context.WithTimeout(ctx, 5*time.Second)
result, err := tool.Handler(ctxT, decision.Args)
cancel()
if err != nil {
// 工具失败不要把错误直接丢给模型，包装成可理解的观察结果
result = fmt.Sprintf("工具执行失败: %v", err)
}
// 3. 把观察结果塞回上下文，进入下一轮
messages = append(messages, fmt.Sprintf("调用 %s 得到：%s", decision.ToolName, result))
}
return "", fmt.Errorf("超过最大步数仍未收敛")
}
type decision struct {
ToolName string `json:"tool_name"`
Args map[string]any `json:"args"`
FinalAnswer string `json:"final_answer"`
}
func (a *Agent) decide(ctx context.Context, messages []string) (*decision, error) {
// 演示用：真实实现里这里是一次带 JSON Schema 的结构化输出调用
// 关键点是「必须让返回结构化」，别让模型自由发挥再正则去抠
return &decision{
ToolName: "query_order",
Args: map[string]any{"order_id": "SO20260928001"},
FinalAnswer: "",
}, nil
}
func main() {
agent := &Agent{MaxStep: 5, Tools: map[string]Tool{
"query_order": {
Name: "query_order",
Description: "按订单号查询订单状态",
Parameters: map[string]string{"order_id": "string"},
Handler: func(ctx context.Context, args map[string]any) (string, error) {
// 换成你真实的数据库或RPC调用
_ = json.NewEncoder(log.Writer()).Encode(args)
return "订单 SO20260928001：已支付，待发货", nil
},
},
}}
answer, err := agent.Run(context.Background(), "帮我查一下订单 SO20260928001 的状态")
if err != nil {
log.Fatal(err)
}
fmt.Println("最终答复:", answer)
}这段代码里有三个点是面试被问得最多的：
一是循环要设上限。不设上限的Agent在真实环境里会因为模型反复纠结烧掉大量token，MaxStep 是必须有的保险。
二是工具要带超时。LLM决定调工具、工具再去查数据库，链路上任何一环卡住都会拖垮整个请求，context.WithTimeout 不能省。
三是工具失败要包装成观察结果回给模型，而不是直接返回error。让模型知道"这次调用没成功"，它才有机会换条路重试，这才是闭环和单纯调用的区别。
跑通这个之后，再往上加RAG、再加多Agent，每一步你都知道底下发生了什么。
5. 简历怎么把老项目翻译成AI语言
同样的项目，换一种说法，在系统筛选里就是两个结果。
改之前是这样写的：
负责订单系统接口开发与数据库优化，通过索引和缓存优化将QPS提升到8000。
改之后：
基于Go设计订单中心对外服务层，统一封装下游9个业务系统接口并完成数据闭环；设计多级缓存与降级策略保障大促期间稳定；输出全链路日志与埋点指标，支撑线上问题5分钟内定位。
内容一句没变，但从"我在写接口"变成了"我在做系统集成和稳定性"。
如果再加上第4节那个能跑的Agent，加上踩过的坑，面试官追问到第三层你还答得上来。这个差别很大。
6. 三种最常见的错误姿势
第一种，一焦虑就报班。钱花出去了，简历一行没变。根本原因是要先有一个自己从头做到底的东西，课解决不了手生的问题。
第二种，觉得"我是写CRUD的，AI跟我没关系"。等到部门把后端岗砍了才发现来不及。
第三种，只学调捐赠开源的Demo，跑通就以为会了。Demo和生产之间的距离，是一整个工程体系：并发、超时、重试、幂等、可观测、灰度回滚。面试官一问就露。
7. 一周能做完的落地清单
不用请长假，一周足够把地基打出来：
- 第1天：跑通上面那个最小Agent，用你自己业务里的一个真实接口当工具。
- 第2到3天：把你们系统的文档或知识库接进来，做一次真的RAG检索，重点调切片和召回。
- 第4天：加
MaxStep、超时、失败重试这三样，让自己的Agent真的不容易崩。 - 第5天：把这个项目写进简历，用第5节的方法翻译一遍。
- 第6到7天：找人对着简历追问三轮，答不住的地方就是下一周的题。
资料包我整理在个人站上，包含后端转AI的能力清单、练手项目骨架和简历模板，地址 wangzhongyang.com
写了这么多年代码，最大的体会是：行业每隔几年就会重排一次序，被重排的人不一定是最弱的，往往是没察觉排序规则变了的那批。这次的规则变化写在甲骨文年报和DeepSeek的JD里，字都认识，看不看得懂是另一回事。
你现在卡在哪一步？是缺一个能跑的项目，还是简历翻译不过来，评论区说说，我挑典型的单独写一篇。