本文是一位后端程序员从Java转向学习AI Agent的心得。作者分享了使用Cursor、Claudecode等AI编码工具的体验，以及初次使用时遇到的挑战，如幻觉问题和参数错误。文章深入分析了AI生成代码的特点，强调验证的重要性，并提出了“回到定义”的学习方法。最后，作者通过Python示例展示了Agent的基本框架和循环控制，对比了Java和Agent工程的思维模式差异，鼓励后端开发者积极学习新事物，发挥自身工程优势转型AI领域。
跳出舒适圈，总是一件不太容易的事情。作为一个老后端，习惯了Java的严丝合缝和确定性，再切换到AI Agent的略带跳跃、充满随机性的世界，就像重拳手一拳打在棉花上的感觉，那种无法完全掌控全局的挫败感，总会让人有点抓狂。尤其当本人是一个在工程实践中，极度追求熵最小化、追求逻辑收敛之美的人。
为什么还是要去学agent呢？大概是：拥抱变化 + 对新事物的极度好奇。2024年开始，自己陆续接触了一些prompt的知识，并很早就在日常使用ChatGPT、豆包。2025开始，我开始接触cursor、Claudecode这些AI编码工具，并很快爱上了指挥AI干活的感觉。
本文主要介绍下：对agent编码工具的感触 + 入门agent时做的东西。
- 对agent编码工具的感悟
2025年开始在自己电脑上用cursor，自己鼓捣些springboot项目。发现一些很坑的地方：
（1）第一次用 Cursor：代码能跑，我就以为改对了。
我让 Cursor 给商品列表加一个分页功能。它很快改完了，接口正常返回，页面也能翻页，我觉得这效率确实高。
但调试的时候发现，它顺手重构了查询逻辑，把原来默认带着的“只查询当前租户”条件弄丢了。
分页做出来了，数据隔离也被一起“优化”掉了。
（2）第一次让 Agent 调 API：它猜对了意思，却填错了参数。
我的提示词核心意思是：“帮我查一下昨天退款失败的订单。”
Agent 正确选择了订单查询接口，参数也生成得像模像样：日期是昨天，状态是
FAILED。接口返回空列表，它回答：“昨天没有退款失败的订单。”
但我们系统的
FAILED表示支付失败。退款失败要查的是另一个字段：refundStatus=FAIL。HTTP 200，JSON 合法，整条链路没有报错，业务答案却错了。
如果说问题2，有一部分是因为我自己的提示词给的不够清晰而产生的锅。那么问题1，就完全不能忍了。你能容忍同事新增一个功能，而把原来的“破水管”改坏嘛。
这是典型的幻觉问题，即：模型生成了一个看起来合理的答案，却没有充分依据来保证它正确。
对于我们常用的问答、代码生成的场景来说，大模型的核心是一个基于概率的文本生成器（当然，它的能力不止于此）。我们可以从2个层面来理解：
（1）模型学到的是大量规律，知识没有以精确数据库的形式保存。
当你问某个框架如何开启重试时，它可能组合出一个符合命名习惯的方法：
.findAllForPageList(pageable);
这个名字很合理，甚至配套解释也很通顺，但对应版本里可能根本没有它。
模型可以根据规律推断答案，但语言和代码形式上的合理性，不足以证明某个方法真实存在。如果没有查文档、读取依赖或编译验证，错误就可能保留下来。
第二，完成当前任务，需要的上下文可能并不完整。
回到“加分页却丢掉租户条件”的例子。模型可能主要看到了：
// 原代码
return orderRepository.findByTenantId(tenantId);
它为了增加分页，改成：
// 修改后
return orderRepository.findAllForPageList(pageable);
新代码满足了分页要求，也能通过编译。
但是：用户明确提出的要求：增加分页.
而原系统已经存在的要求：只能查询当前租户的数据
而原系统的要求，可能散落在其他代码、团队规范，甚至开发者脑子里。模型可能没有获取到，也可能在重写过程中没有保留。
即使相关代码进入了上下文，模型仍可能遗漏约束。
看到一个条件，不等于能在每次修改中可靠地维护这个条件。
所以，对后端开发者来说，AI 生成的是一个需要验证的实现方案。方案写得完整、解释得流畅，并不代表业务正确性已经得到证明。虽然，现在AI编程工具的【记忆功能】、【上下文工程】越来越强大，也会在修改当前代码之前进行单元测试、验证，但开发者作为【最终把关】的那个终审人，还是要心存敬畏，为最终代码提交负责。常怀敬畏之心，这是作为一个开发者应该遵守的非常重要的“道”。
至于编写skill、设置memory这些技巧，更多是“术”，这些会在以后的文章中逐步讲到。
入门agent的实践
1概述
怎么学习一个新东西呢？上高中的时候，教数学的H老师，在讲证明题的时候，经常说的一句话是“回到定义”，这句话深刻影响了多年后我的学习模式：通过若干概念/术语的学习，像拼积木一样，搭建一个整体的「思维框架」。这就是我的MetaData。
Agent的框架是这样的：Agent = LLM（决策）+ 工具（行动）+ 记忆（状态）+ 循环（控制流）。里面的名词我就不逐一解释了，有不懂的自行检索即可。
- 2实践举例
这里，我想去展示一下【工具】+【循环】，所以用下面的例子进行说明。代码是Python，习惯Java的同学可能需要跳出一下“舒适圈”，毕竟现在Agent工程用Python的更多。
背景是：查询转账的金额、处理状态。 前置准备：python -m pip install openaiexport DEEPSEEK_API_KEY='你的 DeepSeek API Key' python scripts/bank_agent_loop_demo.py这里提供三个工具：| 工具 | 输入 | 返回内容 |
|---|---|---|
query_summary | 流水号 | 金额、处理状态 |
query_record | 流水号 | 进度查询编号 |
query_progress | 进度查询编号 | 金额、处理状态 |
模型有两条查找【金额、处理状态】的路径：路径 A：
模型 → query_summary → 模型回答
共 2 轮模型调用
路径 B：
模型 → query_record → 模型 → query_progress → 模型回答
共 3 轮模型调用
选择哪条路径由模型决定；程序负责执行、反馈和控制上限。 两条路径使用一致的虚构数据，金额和状态应该保持一致。下面是脚本中循环部分的核心逻辑摘录：
# 外层：Agent 循环，最多请求模型 5 轮for round_no in range(1, 6): print(f"第 {round_no} 轮：请求模型") response = client.chat.completions.create( model=model, messages=messages, tools=TOOLS, temperature=1.0, max_tokens=512, extra_body={"thinking": {"type": "disabled"}}, ) message = response.choices[0].message messages.append(message.model_dump(exclude_none=True)) # 模型不再调用工具：尝试结束任务 if not message.tool_calls: if not has_status: raise RuntimeError("尚未查到状态，模型提前结束") return message.content # 内层：执行本轮模型请求的工具 for call in message.tool_calls: name = call.function.name arguments = json.loads(call.function.arguments) function, _, _ = SPECS[name] result = function(arguments) has_status = has_status or bool(result.get("status")) # 关键：把执行结果加入上下文 messages.append({ "role": "tool", "tool_call_id": call.id, "content": json.dumps(result, ensure_ascii=False), }) # 进入下一轮，模型将看到刚才的工具结果 raise RuntimeError("达到 5 轮上限，任务未完成")实验时，发现会走两条不同的路径：实验 1：第1轮 → query_summary第2轮 → 最终回答 实验 2：第1轮 → query_record第2轮 → query_progress第3轮 → 最终回答Agent 的循环，是每次执行完工具后，都把结果交回模型，重新决定下一步。它可能直接查汇总，也可能先查记录、再查进度。 开发者需要同时处理两件事：允许模型在可行路径中选择，以及用程序明确规定执行边界。例如，编号必须来自查询结果、没有拿到状态就不能算完成、循环超过上限必须停止。其中，【执行边界】就是我们在后端开发中经常要考虑的异常场景，这属于【工程能力】的一部分，在Agent开发中是可以复用的。 自己的感受是：以Springboot为代表的Java项目，作为一种高度追求健壮性的工程，每一个不确定性的容忍度很低，要么在各种if分支中cover住，要么在异常捕获中进行try-catch。以抚养小孩进行类比，像是一种“圈养”模式，条条框框很多。而Agent工程，更多是只在整体层面进行兜底，允许模型发散，对不确定性接受度很高，像是一种“散养”模式。- 总结
软件工程的发展总是日新月异，IT这个行业对快速学习新事物、接受新事物的能力要求都很高，这也是这个行业的魅力之一。从一种思维模式切换到另一种思维模式，需要我们带着探索、求变的精神去积极尝试。另一方面，工程落地能力，仍然是Java、Go这些后端开发的优势，这方面的能力是harness工程的重要体现。所以，传统开发的转型是有自身优势的。至于语言的切换，是最不值得一提的东西。和思维模式、框架的重塑相比，这算什么难事呢。如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包：
- ✅ 从零到一的 AI 学习路径图
- ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
- ✅ 百度/阿里专家闭门录播课
- ✅ 大模型当下最新行业报告
- ✅ 真实大厂面试真题
- ✅ 2026 最新岗位需求图谱
所有资料 ⚡️ ，朋友们如果有需要《AI大模型入门+进阶学习资源包》，下方扫码获取~
① 全套AI大模型应用开发视频教程
（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）
② 大模型系统化学习路线
作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！
③ 大模型学习书籍&文档
学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
④ AI大模型最新行业报告
2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
⑤ 大模型项目实战&配套源码
学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。
⑥ 大模型大厂面试真题
面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
以上资料如何领取？
为什么大家都在学大模型？
最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！
不出1年，“有AI项目经验”将成为投递简历的门槛。
风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！
这些资料真的有用吗？
这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
