34岁Java后端转Agent，踩坑一年真心话

原创于 2026-09-20 16:03:23 发布 · 24 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

翻电脑的时候翻出去年写的转型便签，一晃，转 Agent 开发整整一年了。

去年我 34 岁，做了 8 年 Java 后端，中间也写过两年 Go。工作说不上差，收入也稳，但那种慌是一天天攒起来的——尤其是大模型突然爆火之后，总抱着老技术栈混日子，迟早要被甩在后面。

纠结了小半年，还是咬咬牙转了 Agent。现在回头看，弯路真没少走，索性都记下来，说不定跟我当年一样纠结的后端兄弟，能少踩两个坑。

最开始，我把学习方向完全搞反了。

总觉得转 AI 嘛，就得从根上学起。先啃 Python，又去补机器学习、深度学习，连论文都硬啃了好几篇。那时候还挺自我感动，觉得基础打牢了总没错。

错是没错，但对我没用。

我在本地跑了三个月的分类模型，最后发现自己连"给团队文档做个能问答的小助手"都搭不出来。那些知识告诉我模型是怎么被造出来的，没告诉我模型该怎么被我用。

这是我踩的第一个坑，也是最大的一个：我把"学 AI"和"用 AI 做东西"当成了同一件事。

01 前三个月，我学反了方向

我那时候的一天大概是这样的：早上看一小时机器学习课程，中午啃 Transformer 论文，晚上推反向传播的公式。笔记本写了 47 页，没敢发朋友圈，但心里觉得自己挺刻苦。

转折在第四个月。我想给自己做个"Java 报错自动定位"的小工具，打开编辑器愣住了——

我知道注意力机制怎么算，但我不知道一份 8000 字的文档该怎么切分；
我知道梯度下降原理，但我不知道让模型调工具时，参数该怎么写它才不乱调；
我甚至不确定，这个需求到底该上 RAG，还是直接塞进上下文。

后来我问一个已经在做 Agent 的朋友，他一句话把我问住了：

“你是要当算法工程师，还是要拿模型做东西？”

我说做东西。他说：“那你学反了。做应用的人，模型是别人递给你的一台发动机，你要造的是车，不是重新发明发动机。”

那天我把那 47 页笔记合上了。不是它们没用，是它们排错了队。对我这种 8 年后端、目标是应用开发的人来说，顺序应该是反过来的：

我花三个月学的	我其实该先学的
反向传播 / 损失函数	API 视角看一次调用：temperature、max_tokens、stream 各管什么
Transformer 论文	Prompt 当接口设计（输入格式、输出 JSON schema）
手写分类模型	Function Calling，工具 schema 怎么写
深度学习数学	RAG：切分 / Embedding / 召回 / 重排
模型结构	编排 + 工程化：超时、重试、降级、成本、日志

一句话：先学"怎么用"，再回头补"为什么"。 反过来的代价，我付了三个月。

02 第二个坑：跑通框架，我以为自己会了

方向掰正之后，我很快跑通了 LangChain 的 demo，一个能问答、能调工具的 Agent，屏幕上跑起来的那一刻是真爽。

然后我飘了，开始投简历。

第一批投了十几家，全军覆没。仅有的一个面试，面试官问了三句：

“向量库挂了，你的服务怎么兜底？”
“检索回来一堆不相关的，你怎么定位是切分的问题、Embedding 的问题，还是重排的问题？”
“用户提问了，但新知识还没建索引，怎么办？”

我一句没答上来。因为 demo 里这些情况都没发生过——demo 是给自己看的，从来不会崩。

真正把我打醒的，是我自己项目里一个卡了两天的 bug：模型老是不调我给的工具，或者乱调。我查了整整两天，最后发现原因蠢到想抽自己——工具的 schema 里，我没写 description。

# 我写的（模型凭什么知道什么时候该调它）
{
    "name": "query_order",
    "parameters": {"order_id": {"type": "string"}}
}

# 该写的
{
    "name": "query_order",
    "description": "根据用户提供的订单号查询订单状态和物流信息。"
                   "仅当用户明确提到订单号或要求查询订单时使用，不要用于查询商品信息。",
    "parameters": {
        "order_id": {
            "type": "string",
            "description": "订单号，16 位数字，例如 2026071912345678"
        }
    }
}

加上 description 之后，调用准确率肉眼可见地上去了。

我干了 8 年接口开发，太知道字段注释有多重要了，结果到了模型这儿，我把它当成"能读懂我心思的人"。

Prompt 不是话术，是接口文档。你给模型的每一句描述，都是在定义调用契约。

03 第三个坑：demo 跑得欢，上线全完蛋

demo 阶段我最常说的话是"跑通了"。上线第一周，我被现实按在地上摩擦。

第一件事：超时。 模型那次响应慢了，30 多秒没吐一个字，前端就是个转圈，用户以为崩了。而我整个链路里，没有任何超时、没有重试、没有降级——因为 demo 里它一直很快。

后来我把后端那套老手艺原样搬了过来：缓存兜底 → 小模型兜底 → 预设话术兜底，三级降级。这是我在 Java 里写了无数遍的东西，我居然在 AI 项目里忘了。

第二件事：成本。 上线第一天，我看着计费后台的数字愣了半天——比我预想的高出一个数量级。原因是上下文无脑全量塞、重试没做幂等、一次问答里模型被调了 7 次。

第三件事：我改不动它。 最可怕的是这个。我改了一版 prompt，感觉"好像好了点"，但又说不清好在哪。因为我压根没有评估集——没有 20 个真实问题、没有"答对答错"的标准，全靠手感。

调 prompt 和调 bug 是同一件事：先能复现，再能定位，最后才动手。 这三步我在 Java 里做了 8 年，到了 AI 项目里，我居然靠玄学。

后来我给自己定了条规矩：每次改 prompt，先跑一遍那 20 个问题，数字说话。第一版我只答对了 8 个，第二版 13 个，第三版 17 个——数字往上走的那几个月，我才第一次觉得自己真的在做事，而不是在许愿。

04 第四个坑：八年经验，被我自己写成"零基础转行"

这是我最后悔的一个坑，也是最容易改的一个。

我最早的简历是这么写的：“8 年 Java 后端开发经验，现转型 AI 方向，自学 LangChain、RAG、Agent 开发。”

翻译过来就是：我以前那八年不算数了，请当我是应届生。

后来我把它整个重写了一遍，没有加任何新东西，只是把旧东西换了个说法：

我原来写在简历上的	换个说法
负责微服务拆分与治理	多工具编排与调用链路治理经验
JVM 调优、接口性能优化	有成本意识（Token 成本 ≈ 单次调用开销）
线上事故复盘、灰度回滚	效果回归与兜底方案设计经验
单元测试与回归体系	评估集设计与效果回归
8 年 Java + 2 年 Go	工程化落地能力，能把 demo 推上线

内容一点没变，但面试官听到的东西完全不一样了。

简历上最有价值的一行，往往不是你新学了什么，是你把旧东西翻译成了什么。

05 一年下来，我真正学会的就三件事

第一件：把模型当成"会抽风的第三方接口"。

它会超时、会返回格式不对的内容、会一本正经地胡说。你对接任何一个不靠谱的第三方服务时做的那些事——超时、重试、熔断、兜底、打日志——在这儿一件都少不了。

想通这一点之后，我突然不慌了：这不就是我干了八年的活吗。

第二件：写 Java 是写确定性，写 Agent 是定边界。

以前我写代码，输入 A 一定得到 B。现在不一样了，你给的是边界和目标，执行过程交给模型。所以工作的重心从"把逻辑写对"变成了"把边界划清楚、把错了怎么办想明白"。

这也是我觉得后端转 Agent 最大的优势：我们早就被线上事故教育过"任何依赖都会挂"，而这条经验，恰恰是纯 AI 背景的人最缺的。

第三件：效果调不出来时，先分层再动手。

模型层：prompt 是不是有歧义、示例是不是不够、temperature 是不是太高；
检索层：切分是不是碎了、Embedding 选得对不对、要不要重排；
工具层：schema 描述清楚了吗、参数类型对不对、工具是不是太多了。

每次我瞎猜着改，都改得更糟；每次我分层查日志，都能查出来。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。