去年年底有个做仓储系统的朋友问我他们公司想上智能体开发手里是一个两个 Java 后端加一个写 Python 算法的配置问我这个组合够不够。我说够但前提是这几个人得能互相看懂对方的代码——这句话后来成了我做这门 AI 应用与智能体开发线下课的起因。你如果最近在招聘网站上翻过一轮会发现AI 应用开发工程师这个岗位描述已经变了不再是熟悉 Transformer 原理这种学术派要求而是能把模型接进现有业务系统、能搭出跑得起来的智能体、能处理数据闭环。翻译成人话就是企业要的不是研究员是把 AI 落地到业务里的那个人。这也是我为什么坚持把 Java 和 Python 放在同一门线下课里讲。市面上单讲 Python 调模型的课太多了听完你确实能让一段代码输出文字但回到公司你会发现你的业务系统是 Spring Boot 写的鉴权、事务、限流、日志全在 Java 那边模型跑在 Python 里怎么跟它对上话反过来只讲 Java 的课也不少可你连 Prompt 怎么改、向量检索的召回率为什么低都插不上手最后只能当个传话的。两条腿都得有才能在项目里站住。这门课定在 2026 年 6 月开班选的是一整段时间的集中线下形式不是那种晚上八点开直播、你一边吃饭一边听的回放课。原因很直接智能体开发的坑八成以上出在环境和依赖上这种东西录播讲一百遍都不如你坐在教室里旁边有人帮你把报错信息看一眼。下面我把这门课的设计思路、技术要点、实操环节和踩过的坑从头到尾拆一遍你对着看就知道自己该不该来以及来之前要准备到什么程度。1. 为什么 AI 应用开发要把 Java 和 Python 绑在一起学1.1 两个语言在真实项目里的分工边界先把这个分工说清楚因为它决定了你学的时候该往哪个方向使劲。Python 的位置在模型侧调用模型接口、写 Prompt 模板、做文本切分和向量化、跑数据处理脚本、做效果评测。这部分工作变化快、试错多、不需要太强的工程约束Python 的生态和写法天然适合快速迭代。Java 的位置在服务侧对外暴露接口、做身份校验和权限控制、管理数据库事务、做并发调度、接入公司现有的监控和日志体系。这部分工作要求的是稳、可观测、能扛量。我见过太多项目把这两块混着做结果就是 Python 脚本被直接当成线上服务跑没有连接池、没有超时控制、没有重试策略模型服务抖一下整个业务流程就卡死。反过来也有团队为了统一技术栈硬用 Java 去写所有数据清洗逻辑一个原本三十行 Python 能搞定的文本处理写了一百多行还不好维护。边界清楚各干各的活中间用 HTTP 或者消息队列对接这是最省心的做法。你在课上学到的第一个判断能力就是拿到一个需求先问自己这一步该放哪边。比如用户上传合同系统抽取关键条款并给出风险提示抽取和提示词构造放 Python文件上传、权限校验、结果落库、给前端返回放 Java。分清楚了后面所有代码都好写。1.2 只会一门语言的人会在哪个环节卡住我把这几年的观察整理成一张表你可以对号入座看看自己现在卡在哪一档。你的现状通常能独立完成的部分最容易卡住的地方只会 Python做过数据分析调模型、写 Prompt、跑向量检索 demo接口并发一上来就崩不知道怎么和现有业务系统对接不懂事务和幂等只会 Java后端经验三五年写接口、做鉴权、管数据库、扛并发改不了 Prompt读不懂检索逻辑模型输出格式一变就束手无策两门都会一点但都没做过 AI 项目能看懂两边代码不知道一个完整智能体该怎么分层出了问题定位不到是哪一层做过 AI demo没上过生产能跑通单条链路不知道怎么做评测、怎么控制成本和延迟、怎么处理失败重试这张表里第三档的人其实是最好教的因为他已经有全局视野缺的是项目结构和排查经验线下课集中几天就能补上。第一档和第二档的差距通常在三到五天的密集训练内能大幅缩小前提是课程里必须有两边对照着写的实操环节而不是上午讲 Java、下午讲 Python、两边老死不相往来。1.3 线下集中形式对这门技术组合的特别价值线上课最大的问题是环境黑箱。你本地 Python 是 3.9课程演示用的是 3.11某个库的 API 签名变了你照着敲就是报错然后在评论区等回复一来一回半天过去了学习节奏全断。Java 那边更麻烦JDK 版本、Maven 依赖冲突、Spring Boot 版本和某个 SDK 不兼容这些东西没有统一答案得看你的报错信息现场判断。线下课把这个问题压缩到几分钟。我在教室里最常做的事就是走到学员旁边看一眼终端说一句你这个是依赖版本锁死了把这段注释掉换另一个坐标试试。这种交互效率是任何录播都替代不了的。另外还有个隐性收益智能体开发目前没有标准答案同一个需求有五六种实现路径同学之间互相看代码、互相质疑方案这种碰撞在线上几乎不会发生。你一个人对着屏幕琢磨三天可能都不如同桌一句你为什么不把这块抽成一个工具函数来得有用。2. 智能体开发到底在开发什么2.1 从调一次模型到搭一个智能体的跨越很多人对智能体的理解停留在能对话的机器人这个理解会让你在项目里走偏。一次普通的模型调用是这样的你给它一段输入它给你一段输出结束。智能体不一样它是一个带循环的结构模型先想一步决定要不要用工具用了工具拿到结果再想一步可能还要再用一次工具直到它认为任务完成才给出最终答复。这个循环两个字是整个智能体开发的全部难点。循环意味着你要控制轮数上限否则模型可能一直绕圈子意味着你要处理中间状态的传递每一步的输出要能喂给下一步意味着你要做异常处理某一次工具调用失败了是重试、跳过还是终止意味着你要记录每一步的轨迹不然出了问题你根本不知道它在哪一步跑偏了。我在课上会用一个很土的比喻普通模型调用是你问一句它答一句智能体是你给它一个任务它自己列清单、自己跑腿、自己核对最后回来汇报。你要写的代码就是那个管着它的项目经理——定规则、控预算、看进度、兜底。理解了这个角色定位后面所有技术点都不会散。2.2 一个智能体的四个核心部件不管用什么框架一个能用的智能体基本都跑不出这四个部件我在课上会把它们一个一个拆开讲也会让你自己动手实现最简版本而不是直接调框架的封装。第一是规划。模型怎么把一个大任务拆成小步骤。最简单的方式是在系统提示里写清楚你需要按步骤思考并输出下一步动作复杂一点的会做任务分解和依赖排序。这一步的关键不是写得花哨而是输出格式必须机器可解析通常是结构化文本或 JSON你要在代码里做严格的格式校验解析失败就要触发重试。第二是记忆。短期记忆就是当前对话的上下文长期记忆是跨会话的知识一般存在向量库里。这里最常见的误区是把所有历史记录都塞进上下文结果 token 消耗爆炸、响应变慢、模型还被无关信息干扰。正确做法是做窗口管理和摘要压缩把久远的对话压成一段摘要只保留最近几轮原文。第三是工具。智能体能干的事全靠工具撑着。查数据库、调内部接口、算数、发消息每一个能力都要写成清晰的工具描述告诉模型这个工具是干什么的、要传什么参数、返回什么格式。工具描述写得含糊模型就会乱调或者不调这是新手最容易忽视的地方。第四是执行循环。也就是前面说的那个项目经理逻辑控制整个流程的推进、失败处理和终止条件。2.3 结合自建业务模型的智能体怎么搭有一类需求特别常见企业自己有一批业务数据或者自己部署了一个小模型想在上面搭智能体。这种场景和纯调外部模型不一样有几个地方要特别注意。数据权限是第一道坎。自建业务模型通常只能看到内部数据但智能体在规划的时候可能会想调用外部工具这时候你要在工具层做白名单控制哪些工具在这个场景下允许调用必须写死不能让模型自由发挥。第二道坎是内网环境很多企业的模型服务部署在内网外网访问不了你的开发环境、调试环境、生产环境网络策略都不一样这套东西在现场调试的时候最容易出问题也是线下课能帮你省时间的部分。第三道坎是效果兜底。自建模型的能力通常弱于通用大模型规划能力不足容易在循环里绕圈。我的经验是把复杂任务拆得更细用多个小智能体串起来每个只负责一件小事而不是让一个智能体包打天下。这种小步快跑的架构在自建模型上比单体智能体靠谱得多。3. Java 侧把 AI 能力接进企业系统的关键工程点3.1 用 Spring Boot 搭一个智能体服务网关Java 这边最核心的角色是网关。所有来自前端的请求先进 Java 服务由它做鉴权、限流、参数校验、会话管理再把真正需要模型处理的部分转发给后端。这样做的好处是模型相关的逻辑可以独立演进前端和业务系统不用跟着改。下面是我在课上会带着写的一段最小网关代码用的是 Spring 的流式返回因为智能体的输出通常是逐字吐出来的用普通接口会让用户干等十几秒。RestController RequestMapping(/agent) public class AgentGatewayController { Resource private AgentOrchestrator orchestrator; PostMapping(value /chat, produces MediaType.TEXT_EVENT_STREAM_VALUE) public SseEmitter chat(RequestBody ChatRequest request) { // 60 秒超时超时后前端会收到中断信号 SseEmitter emitter new SseEmitter(60_000L); // 会话 id 由前端传入没有则新建用于串联多轮上下文 String sessionId StringUtils.hasText(request.getSessionId()) ? request.getSessionId() : UUID.randomUUID().toString(); orchestrator.runAsync(sessionId, request.getQuery(), emitter); return emitter; } }这段代码看着简单但每一个细节都有讲究。超时时间设 60 秒是因为智能体可能要走好几轮工具调用设太短会误杀正常请求会话 id 由前端传入而不是后端生成是为了支持刷新页面后继续对话用异步执行而不是同步返回是因为流式输出必须在独立线程里推送同步会阻塞容器线程。注意SseEmitter 的超时时间和容器本身的连接超时是两回事两个都要配。我见过太多次学员只改了代码里的超时结果请求还是被前面的负载均衡掐断排查了半天。3.2 并发调度与线程等待的正确姿势智能体经常需要并行做几件事比如同时查三个数据源等结果都回来再一起喂给模型。Java 里做这件事的坑特别多最常见的错误是用了CompletableFuture但没传自定义线程池全部挤在默认的 ForkJoinPool 里量一上来就互相拖死。// 专门给模型调用准备的线程池核心数按实际并发量给别用默认的 private final ExecutorService modelExecutor new ThreadPoolExecutor( 8, 32, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(200), new ThreadFactoryBuilder().setNameFormat(agent-pool-%d).build(), new ThreadPoolExecutor.CallerRunsPolicy()); public ListString queryInParallel(ListString queries) { ListCompletableFutureString futures queries.stream() .map(q - CompletableFuture.supplyAsync(() - callTool(q), modelExecutor) .exceptionally(e - )) // 单个失败不影响整体 .collect(Collectors.toList()); // allOf 只保证全部完成不保证成功所以前面做了 exceptionally 兜底 CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join(); return futures.stream() .map(CompletableFuture::join) .filter(StringUtils::hasText) .collect(Collectors.toList()); }这段代码里有两个经验点值得单独说。一是线程池的拒绝策略选了CallerRunsPolicy意思是队列满了就让调用线程自己跑这样虽然会变慢但不会丢任务对智能体这种宁可慢也不能少的场景更合适。二是每个 future 都挂了exceptionally因为allOf在某个任务抛异常时会直接失败导致你拿不到其他已经成功的结果。工具调用本来就容易失败一个超时不该让整个回答作废。3.3 向量库和业务数据的对接方式Java 这边接向量库主要工作不是算法是数据同步。业务数据在 MySQL 里向量在向量库里两边怎么保持一致这是工程问题。我的做法通常是业务写操作走消息队列异步触发向量更新读操作直接查向量库拿 id再回表查详情。中间要处理的是删除和更新很多人只做了新增结果旧数据一直在检索出来全是过期信息。还有一种情况是热数据不进向量库直接在 Java 层做关键词检索冷数据才走向量召回。这样做的好处是响应快、成本低。判断标准很简单如果一个查询在业务表里用索引能秒出结果就别绕向量那一圈。向量检索解决的是语义相似问题不是替代数据库查询。4. Python 侧模型调用、数据处理与工具链4.1 环境搭建的三种方案和选择依据Python 环境这块我在课上会给出三种方案让学员根据自己的机器和习惯选。第一种是虚拟环境加 pip最轻量适合单人开发和课程练习。python -m venv .venv然后激活所有依赖装在这个目录里和系统 Python 隔离。缺点是依赖多了之后解析慢跨平台复现要靠 requirements.txt。第二种是 conda适合需要管理不同 Python 版本、或者要装一些带二进制依赖的科学计算库的场景。体积大但对新手友好装不上的包通常换 conda 源就能解决。第三种是容器适合团队协作和最终部署。开发阶段用前两种交付阶段一定要用容器不然你本地能跑、同事机器上跑不起来这种事会反复发生。依赖管理有个硬性建议所有版本号全部锁死不要用这种写法。模型相关的 SDK 更新频繁小版本之间 API 都可能变你今天写的代码下周重新装依赖就可能报错。锁定版本写清楚注释这是给自己省时间。4.2 模型调用的封装与流式输出调模型这件事本身不难难的是封装。直接在每个业务函数里写 HTTP 请求代码会迅速失控。我会在课上带大家写一个统一的调用层把所有模型交互收口到一处方便加日志、加重试、加超时、换供应商。import requests import time from typing import Iterator def call_model(prompt: str, system: str 你是业务助手, retries: int 2) - str: payload { model: MODEL_NAME, messages: [ {role: system, content: system}, {role: user, content: prompt}, ], stream: False, } for attempt in range(retries 1): try: resp requests.post( MODEL_ENDPOINT, headers{Authorization: fBearer {API_KEY}}, jsonpayload, timeout(5, 60), # 连接 5 秒读取 60 秒 ) resp.raise_for_status() return resp.json()[choices][0][message][content] except requests.Timeout: if attempt retries: raise time.sleep(1.5 * (attempt 1)) # 退避重试别原地猛冲这里我把连接超时和读取超时分开设了这是个非常实用的细节。连接超时短说明网络不通就快速失败读取超时长因为模型生成文字本来就慢。很多人只设一个总超时要么短了误杀要么长了卡死。流式输出稍微复杂一点核心是把响应按行读、按事件边界切、逐块推给前端。课上我会让大家自己实现一遍因为你只有亲手处理过被截断的半个 JSON才会明白为什么要在缓冲层做拼接。4.3 数据采集与清洗这一环为什么绕不开AI 应用的效果七成取决于数据质量这个比例我一点都不夸张。你 Prompt 写得再漂亮检索出来的资料是乱的、重复的、过期的输出就是垃圾。数据这块在课上会花不少时间重点讲三件事怎么从业务系统里把原始数据取出来、怎么切分成适合检索的片段、怎么去重和打标签。切分这个环节最容易出问题。按固定字数切会把一句话切断按段落切遇到超长段落又没法处理。我通常讲的是混合策略先按语义边界切超过上限再按标点切仍然超长才硬切。切完之后每一段都要带上来源、时间、类型这些元数据因为检索出来之后往往还要按这些字段过滤。还有一个常被忽略的点是数据更新。知识库不是建一次就完事业务数据每天都在变你得设计一套增量更新机制否则一个月后检索出来的全是老黄历。这套东西线上听一遍记不住必须现场跟着做一遍。5. 课程实操环节的三个项目拆解5.1 项目一工具调用型智能体第一个项目我设计得很简单就是让智能体能查数据、能算数、能按结果给建议。目标是让所有人先把最小闭环跑通定义工具、让模型选择工具、执行工具、把结果回填、生成最终回答。这个循环写通了智能体就算入门了。难点在于工具描述的设计。我会让学员先自己写一版然后互相对照着改。你会发现同样一个查询工具查询订单和根据订单号查询订单的当前状态和金额参数必须是完整订单号这两种描述模型的调用准确率差一大截。这种手感只能靠反复试讲不出来。Java 这边在这个项目里负责工具的实际执行和结果校验。Python 侧发出的工具调用请求Java 收到之后要校验参数合法性、查库、格式化返回。两边的接口约定要提前定好字段名、类型、错误码都不能含糊不然调起来就是一堆格式错。5.2 项目二带知识库检索的智能体第二个项目是 RAG 的完整链路。从原始文档进去经过切分、向量化、入库到查询时召回、重排、拼进 Prompt、生成回答。这条链路每个环节都能调也每个环节都能出错我会带大家一个个参数试过去。召回数量这个参数特别值得现场调。设 3 条可能漏信息设 20 条模型又被噪声干扰。我的经验是先设 8 到 10 条做粗排再用一个小的重排模型筛到 3 到 5 条喂给生成。这个过程在现场做你能直观看到同一句话在不同召回数量下的输出差异这种体感是看书得不到的。还有一个必讲的点是拒答。检索不到相关内容时智能体必须能说我没有找到相关信息而不是硬编一个答案。这个能力要在 Prompt 和代码两层都要做Prompt 里明确要求代码里检查召回分数阈值低于阈值直接走兜底回复不调模型。5.3 项目三多智能体协作第三个项目是综合演练把前面学的东西串起来。设计是一个主智能体负责理解需求并分派任务下面挂几个专项智能体分别负责查询、分析、生成报告。主智能体不直接干活只做调度和汇总。多智能体最麻烦的地方是状态传递和终止控制。子任务的结果怎么传回主流程、失败了怎么降级、整体轮数怎么限制这些都要写清楚。我在课上会故意留一个 bug让主智能体在某个条件下陷入循环然后带着大家一起看日志、定位问题、加终止条件。这种制造故障再修复的环节是线下课我能做而录播做不了的部分。6. 常见问题与排查技巧实录6.1 环境和依赖类问题这类问题占了实际调试时间的一半以上我整理了一张速查表基本能覆盖你在课程期间会遇到的大部分情况。现象大概率原因处理方式装了库但导入报找不到模块装到了系统 Python不是当前虚拟环境确认虚拟环境已激活用python -m pip install而不是裸 pip两个库互相冲突装一个另一个坏依赖版本不兼容锁定版本建新环境不要试图在旧环境里硬修Java 编译报找不到符号依赖没下载完或坐标写错清本地仓库重新拉检查坐标和版本号服务启动报端口占用上一个进程没退干净查端口对应进程杀掉或换端口本地跑得通换机器就报错环境变量没同步把所有配置外置成环境变量或配置文件写进文档注意不要在系统 Python 里装项目依赖这是新手最容易犯的错。一旦把系统环境弄脏后面所有环境问题都会变得难以定位。6.2 模型调用类问题超时和限流是两类高频问题。超时要分清楚是网络层超时还是模型生成慢前者缩短连接超时后者要么延长读取超时要么改成流式返回让用户先看到内容。限流则需要做退避重试而且必须是带随机抖动的退避固定间隔重试在并发场景下会形成新的峰值。输出格式不可解析也很常见。模型返回的 JSON 偶尔会多一个逗号、少一个引号或者前面带一段解释文字。我的做法是三层防护Prompt 里明确要求只输出 JSON解析前先用正则把代码块标记剥掉解析失败时把错误信息回传给模型让它重写一次。这三层加上成功率能到很高。还有一类问题是答案质量忽好忽坏。排查顺序是先看检索结果再看 Prompt 版本最后才怀疑模型。绝大多数情况问题出在前面两步模型本身反而是最稳的一环。6.3 工程与并发类问题接口响应慢但 CPU 不高一般是卡在等待上要么是模型调用慢要么是数据库慢用链路追踪看一眼就能定位。并发上去之后出现数据错乱基本是共享状态没做隔离会话相关的数据一定要按会话 id 分开存不要用类成员变量。内存缓慢增长最后崩溃通常是历史记录没清理。智能体的上下文会随着轮数不断变长如果不做窗口限制跑一天下来内存就吃满了。我的建议是在会话层就设一个硬上限超过轮数的历史直接摘要压缩别等到出问题再补。最后一个经验所有涉及模型调用的地方都要有降级方案。模型服务不可用时至少要让业务流程能给出一个明确的提示而不是整个页面转圈到超时。这个兜底逻辑花不了多少代码但能避免很多线上事故。7. 学习路线与时间安排建议7.1 前置基础要补到什么程度课程虽然是零基础可入但完全不准备会让你的学习效率打折。我给的建议很具体Java 方面你要能独立写出一个带数据库操作的 Spring Boot 接口知道什么是依赖注入、什么是事务、怎么用 Maven。不需要精通并发包但要知道线程池是干什么的。Python 方面你要能读写文件、处理字典和列表、写函数、用 requests 发请求。不需要会机器学习也不要求你懂深度学习框架。如果这两条你都不满足建议提前两到三周每天抽两个小时补一下把基础语法和常见库过一遍。这个投入很小但能让课堂上的时间真正花在智能体上而不是花在语法上。我见过一些学员因为基础不牢前两天全在补课后面的实操只能看着别人做很可惜。7.2 课程期间的节奏安排密集课程最怕的是听懂了但没动手。我的安排是每天上午讲原理和拆代码下午全部是动手时间晚上留一到两小时答疑和补做。下午的实操必须自己敲不许复制粘贴这个要求看着严但效果差别很大。你复制一段代码跑通了脑子里其实什么都没留下自己敲一遍报三次错那个知识点就记住了。每天结束前我会留一个今日卡点的环节每个人说出自己今天最卡的地方大家一起看。这一步的价值在于你遇到的问题往往也是别人的问题说出来之后解决效率高很多而且你会发现有些坑是通用的提前知道能省后面很多时间。7.3 课后怎么把学到的东西延续下去课程结束才是真正的开始。我建议回去之后立刻做一件事把课程里的第三个项目换成你自己业务里的一个真实场景重做一遍。不用做得完整能跑通链路就行。这个动作能帮你把课堂知识真正迁移到工作场景也能暴露你在真实数据上会遇到的新问题。另外行业里看 AI 应用公司的时候常用市销率也就是 PS 这个口径来估商业价值这个数字背后反映的其实是应用能不能规模化落地、能不能持续产生收入。对个人来说这个道理是一样的你手里的技术只有接到真实业务上产生可衡量的价值才算真正掌握。停留在 demo 阶段的能力市场不会给它定价。我个人在实际带课过程中的体会是学员之间的差距往往不在智商而在有没有把问题问出口。同样一个环境报错有人自己憋两个小时有人直接举手三分钟解决。集中线下这段时间最大的资源就是你周围坐着的人别浪费。最后再分享一个小技巧把你调试智能体过程中的每一次失败都记下来包括当时的输入、模型的输出、你的判断。攒够二三十条之后回头看你会发现自己踩的坑高度集中在几个类型上把这些类型解决了你的调试效率会有一个明显的台阶。这个记录习惯我从第一次做智能体项目保持到现在比任何教程都管用。