大概从去年开始陆续有好几个做了多年Java后端的朋友问我同一个问题现在大模型应用这么火像Agent开发这种岗位动不动就挂在招聘首页我Java功底还不错想转过去还来得及吗我的回答一直很坚定来得及而且Java背景干这行反而是优势。这不是安慰。我见过太多从Java转型Agent开发的人前三个月确实是要补不少新知识但补完之后原有工程能力几乎全部能复用上。Agent开发本质上不是一个全新的编程范式而是把大模型当作一个“不太稳定的协作者”嵌进你已有的技术体系里。你需要的不是丢掉Java去学Python而是搞懂大模型的行为规律、调用方式和编排方法。这篇文章我会把“从Java到Agent开发”这件事拆成一条可执行的3个月路线第一个月补什么、第二个月练什么、第三个月做什么以及每个阶段要避开的坑。我尽量用Java开发者能听懂的语言来讲不光讲概念还会给你一个能跑通的最小Agent示例以及我实际开发中踩过的几个典型问题。适合那些工作1到5年、想往大模型应用方向靠的Java工程师也适合刚入门想找方向的后端新人。1. 3个月转型路线为什么90天是合理周期1.1 转型前必须想清楚的三个问题很多人一听到“转行”就焦虑总觉得自己要从零开始。但Agent开发不是让你从零学一门编程语言而是让你学会“怎么跟大模型打交道”和“怎么把模型接进系统”。带着Java几年的积累来做这件事你要想清楚的第一个问题就是我不是转行我是扩展技能边界。第二个问题是要明确目标岗位到底需要什么。搜索一下Agent开发相关的职位描述你会发现高频要求大概是这几类熟悉大模型API调用理解提示词工程做过RAG或者工具调用具备工程化落地能力了解Agent框架。你会发现传统的Java技能Spring Boot、并发编程、分布式系统、数据库设计全都还在需求列表里只是额外叠加了大模型相关的知识。第三个问题是时间预期。市面上很多“7天学会大模型开发”的课程我只能说看看就好。Agent开发的难点不在于“调用API”这一步而在于你能否理解模型输出的不确定性能否设计出稳定可靠的系统来容纳这种不确定性。这需要时间沉淀。3个月是一个比较合理的周期足够你建立完整认知又不至于拖到失去动力。1.2 三阶段时间轴地基、核心、实战我习惯把90天拆成三份每份30天分别对应“地基期”“核心期”“实战期”。阶段时间核心任务输出成果地基期第1个月补大模型基础概念熟悉API调用方式至少跑通3种不同的模型调用场景核心期第2个月掌握提示词工程、工具调用、记忆管理完成一个带Function Calling的Demo实战期第3个月综合编排一个业务Agent考虑稳定性和评估上线一个可Demo的完整Agent服务地基期最容易犯的错是把时间浪费在“调参”上。温度、Top-P、Max Tokens这些参数花半天了解就够了别泡在里面。第一周你只需要搞明白Token是什么、上下文窗口意味着什么、Embedding能干什么然后用代码去调用一次大模型的接口哪怕只是让它帮你写一段Java代码都算入门了。核心期的重点是用一个真实的小场景把Agent的核心链路打通。很多教程会带你做一个“聊天机器人”但我建议做“能调工具的助手”比如让模型根据用户指令查询数据库并返回结果。这个阶段你会在实践中真正理解为什么要结构化输出为什么模型会“一本正经地胡说八道”为什么同一个Prompt喂两次结果不一样。实战期则是把一个相对完整的业务Agent落地。你可以选择做客服工单分类、知识库问答、数据分析助手等场景。这个阶段的核心不是“让它能跑”而是“让它稳定地跑”你会接触到评估、兜底、日志、监控这些工程化议题。2. Java开发者做Agent开发的先天优势与思维切换2.1 你的工程化功底在AI时代没有白费很多Java开发者会有一个错觉大模型开发是不是必须要用Python我的答案是工具链上Python确实有些优势但工程化落地上Java一点都不虚。你想象一下一个Agent服务要接入订单系统、调用库存接口、查询用户信息、把结果通过消息队列推给下游这些活哪个不是Java后端的老本行我做过的一个实际项目就是在一个典型的Java微服务架构里嵌入Agent能力。服务通过HTTP暴露接口内部用大模型做意图理解再通过Spring管理的Bean去调用一系列已有的业务方法最后把结果结构化返回给前端。整个过程完全复用了我已有的Spring Boot、Maven、日志、监控体系。反而是团队里一个只会Python的新人在接入公司统一配置中心、链路追踪、权限体系的时候花了不少时间。大模型应用大部分都是“大模型业务系统”的组合大模型负责理解、生成、决策业务系统负责稳定落地。Java开发者最擅长的恰恰是后半部分。你的类型安全、事务管理、依赖注入、单元测试能力在Agent系统的工程化环节里都是硬通货。很多Agent项目死不是死在模型选型上而是死在调用超时没人处理、并发一高就崩、出错后没有兜底这些基础问题上而这些正好是Java工程师的日常。2.2 从确定性编程到概率性编程最难的思维转变Java开发者写代码有一个天然的习惯追求确定性。方法传进去什么参数返回什么结果运行一千次都一样。但大模型不是这样同一个Prompt调用两次返回结果可能不一样甚至格式都可能变。这是转型期最让人难受的一点也是最需要主动适应的一点。我管这个叫“概率性编程”。你不能用Assert.assertEquals去测模型输出但你可以用“输出里是否包含指定字段”“JSON是否可解析”这类约束去校验。你也不能指望模型永远给你合法JSON所以解析的时候必须容错。你更不能假设模型“理解了”你的指令所以Prompt要写得像伺候一位理解力尚可但偶尔走神的新同事。这套思维切换的具体落地原则有三条。第一条永远假设模型会出错所有关键输出都要加校验和兜底逻辑。第二条能交给代码处理的确定性逻辑就不要交给模型模型只做它擅长的事比如意图理解、内容生成、信息抽取。第三条用“结构化约束”代替“口头要求”比如让模型必须返回JSON不要返回任何解释然后在代码里做二次解析。这个思维转过来之后你会发现自己写Agent代码的姿势和那些“调一下API就完事”的人完全不一样。你能设计出容错机制你能在模型输出不合规时做重试和降级你能把大模型从一个玩具变成一个生产力工具。这些能力恰恰是企业里真正需要的。3. Agent开发的地基大模型核心概念与选型3.1 你真正需要掌握的五个概念第1个月的地基期不需要你学什么“注意力机制”或者“Transformer架构”那是搞模型训练的人要啃的东西。你作为应用开发者真正要搞懂的是以下五件事。Token是模型计费和处理文本的基本单位。一句中文大概对应一到两个TokenToken越多计费越贵响应也越慢。你写Prompt的时候要有Token意识别把几千字的文档一股脑塞进上下文那既费钱又可能超出模型限制。上下文窗口指的是模型一次能处理的最大Token数。它就像JVM内存超过就报错所以你要学会“控制上下文大小”。长对话里只保留最近几轮、把历史记录做摘要压缩都是围绕这个限制做文章。Embedding是“文本转成向量”的技术也是RAG检索增强生成的基础。你可以简单理解为Embedding能把语义相近的文本变成空间里距离相近的向量。做知识库问答时你的核心操作就是先把文档切成小块转成向量存起来用户提问时再找出最相关的几块喂给模型。结构化输出是Agent开发里最实用的功能。几乎所有主流模型都支持通过JSON Schema约束输出格式你可以要求模型“只返回JSON包含status和message两个字段”然后直接在Java代码里解析。这是让模型输出“可编程”的关键手段。温度Temperature是控制模型随机性的参数。做代码生成、数据抽取这类确定性任务温度调低到0.1甚至0做文案创作、头脑风暴温度可以调到0.7以上。这是唯一一个值得你花时间调的核心参数其他参数了解即可。3.2 Java技术栈选型Spring AI还是LangChain4jJava生态里做Agent开发目前主流选择是Spring AI和LangChain4j这两个框架也可以完全手写。我三个方案都用过给你说下我的真实感受。Spring AI最大的优势是跟Spring Boot深度集成。如果你本来就在用Spring Boot开发那么这个框架的自动配置会让你非常顺滑你只需要在配置文件里写上模型平台的Key注入一个ChatClient就能发起对话。它还提供了结构化输出、RAG、Function Calling的封装概念清晰文档也比较完整。缺点是框架还在快速迭代期部分API在不同版本之间有变化升级要留意兼容性。LangChain4j是Python版LangChain的Java移植。它的优势是组件更全比如Memory、RAG、Tool这些模块都做得比较细生态里有大量现成的集成。如果你参考的教程或开源项目大多是LangChain系那用LangChain4j会更好对照。缺点同样是版本迭代快而且API设计风格总体上贴近Python习惯部分接口跟Java开发者的直觉不太一样。手写方案是“不依赖框架自己用HTTP调模型接口自己维护对话上下文和工具调用循环”。它的优点是完全可控、代码逻辑透明适合学习原理缺点是样板代码多要做嵌入、RAG、记忆这些高级功能时工作量明显大。我的建议是如果你本身就是Spring Boot用户直接选Spring AI学习成本最低如果心里没底可以先用几天时间手写一个最小的Agent循环理解原理之后再用框架提炼代码。我自己带过的某位同事就是从手写开始理解透了之后再切框架遇到问题定位速度快很多。4. Agent四大核心组件逐一拆解实操篇4.1 模型接入Java里如何封装一个LLM客户端整个Agent系统里大模型相当于“大脑”你的Java服务相当于“身体”。大脑负责思考和决策身体负责执行和落地。第一步就是把大脑接进来。现在国内外的模型服务商基本都提供了OpenAI兼容风格的HTTP接口也就是一个POST请求带上模型名和消息数组就能拿到补全结果。Java里最简单的接入方式是用Spring RestClient或者OkHttp发POST请求把请求体和响应体都映射成Java Record。一个小建议模型调用的重试和超时一定不能省。我在实际开发里见过太多Agent服务因为上游模型响应慢导致整个接口超时。推荐策略是连接超时控制在5秒以内读取超时控制在60秒左右大模型长文本生成确实慢重试最多2次并且用指数退避。还有一个容易被忽略的细节模型平台有QPS限制并发量大的时候要加本地限流否则会被限流反而更慢。另一个核心封装点是“消息类型”。OpenAI兼容接口里每条消息有rolesystem、user、assistant和content。你的Java类应该定义成统一的ChatMessage结构再用List去维护整个会话历史。很多初学者没弄明白这个模型把多轮对话当成“每次只传最新一句”结果模型完全没有上下文记忆。记住你发给模型的不是一个单次请求而是一段完整对话历史。4.2 提示词工程让模型按照你的要求输出结构提示词工程本质上是“怎么跟大模型沟通”。这里不需要什么花哨的咒语核心就四个原则明确角色、说清任务、给出格式要求、提供示例。你在Java里会定义一个系统提示词System Prompt它相当于“岗位说明书”告诉模型它是谁、负责什么、有什么边界。我推荐的写法是先写角色定位再写职责范围再写输出格式要求最后加一句“如果无法回答请直接说明”。这样的提示词虽然长但能显著减少模型“乱发挥”的概率。对于Agent场景比写得好更重要的是一定要做结构化输出。你要让模型输出一段JSON就用JSON Schema或者直接给出一个模板。很多模型服务商都支持一个叫Response Format的参数设置为JSON Mode之后模型会尽量保证输出是合法JSON。我建议不管支不支持这个参数都在提示词末尾明确写一句“请直接输出JSON不要任何解释性文字”。还有一个小技巧叫“Few-Shot”就是给模型看一两个输入输出的例子。让模型模仿例子比让它理解抽象规则容易得多。比如你做工单分类就给两个标注好的例子“【网络无法访问】-网络故障”“【登录页面报错500】-服务端异常”。模型看到之后分类准确率会明显上升。4.3 工具调用Function Calling是Agent的灵魂Agent和普通聊天机器人最大的区别就是Agent能调用工具。模型本身不联网、不知道你的库里有数据但它能根据你的意图告诉你“需要调用某个函数”由你的代码去执行再把执行结果给回模型模型最终组织成给用户的回答。工具调用的标准流程是这样的第一步你给模型声明一批可用的工具每个工具包括名称、描述、入参JSON Schema。第二步模型在生成回复时可能返回一个tool_calls对象里面包含工具名和参数。第三步你的代码解析这个对象执行对应的方法拿到真实结果。第四步把模型回复和工具执行结果一起追加到消息列表再次调用模型。第五步模型会基于工具结果生成最终回复。这个循环是所有Agent系统的心脏写成Java伪代码大致长这样ListChatMessage messages new ArrayList(); messages.add(systemMessage(你是订单助手可以查询订单状态。)); messages.add(userMessage(帮我查一下订单A1001的状态)); while (true) { ChatResponse response llmClient.chat(messages, toolSchemas); messages.add(response.message()); // 模型回复入栈 ListToolCall calls response.toolCalls(); if (calls.isEmpty()) { // 模型没有请求工具说明已经有最终答案 return response.content(); } for (ToolCall call : calls) { Object result toolExecutor.execute(call.name(), call.arguments()); // 工具结果也要入栈 messages.add(toolMessage(call.id(), result)); } }注意入栈顺序非常重要。模型先说的那句话、工具执行的结果、以及哪个工具被调用了都必须按顺序追加到会话里模型才有能力理解“工具干完了活现在该形成结论了”。很多新手在这个循环里漏掉中间某一步结果模型直接“失忆”。工具描述怎么写也很有讲究。模型是靠你的描述来决定调哪个工具的所以描述要具体。比如“查询订单状态”就不如“根据订单号查询订单当前状态返回状态码、物流信息、预计送达时间订单号是必填参数”效果好。描述越清楚模型调用错误的概率越低这一点我实测下来感触极深。4.4 记忆管理上下文窗口不是无限大的Agent的对话往往不止一轮。用户的第二个问题可能依赖第一轮的答案比如“那发货地址是什么”。这就涉及记忆管理。大部分Agent系统里记忆分两层短期记忆就是消息列表本身长期记忆则依赖把关键信息抽取出来存进数据库或者向量库下次对话时再检索回来。Java开发者通常很容易理解这套逻辑短期记忆类似一个会话缓存长期记忆类似一个持久化存储。你要做的就是在两者之间做同步。每轮对话结束后提取用户的核心偏好、实体信息比如订单号、收货人存入一个结构化存储新对话开始时先按用户ID把相关记忆加载回来拼进系统提示词。同时要控制短期记忆的大小。模型上下文窗口有限你不可能无限追加消息。两个常用的手段第一是滑动窗口只保留最近N轮对话第二是摘要压缩把超过窗口的老对话用模型总结成一段摘要放在最前面。第一个实现简单但可能会丢细节第二个效果好但会增加一次额外模型调用。根据我的经验业务型Agent优先用滑动窗口知识密集型任务用摘要压缩。5. 完整实操一个订单查询助手Agent从0到15.1 项目结构与依赖配置这个Demo的目标是做一个“订单查询助手”。用户用自然语言问订单状态Agent自己判断该调哪个工具调用后返回结果给你。我会用一个Spring Boot项目不依赖任何Agent框架纯手写核心循环这样你能看到完整的原理。工程目录结构如下agent-demo src/main/java/com/example/agentdemo AgentApplication.java llm/ChatClient.java llm/ChatModels.java tools/OrderToolService.java tools/ToolSchema.java agent/AgentOrchestrator.java web/AgentController.java src/main/resources/application.yml pom.xmlpom.xml里只需要引入spring-boot-starter-web和spring-boot-starter-webflux用于WebClient调用模型接口加上jackson解析JSON就够了。我不引入重型Agent框架这样每一步都清晰可见。配置文件中保存模型平台的接口地址、API Key和模型名注意Key一定不要写死在代码里用环境变量注入llm: base-url: ${LLM_BASE_URL:https://api.your-provider.example} api-key: ${LLM_API_KEY:} model: ${LLM_MODEL:your-model-name} temperature: 0.1给模型定义一个Record能产出一个“当前这个模型固定输出的文本描述”。5.2 定义工具方法与Schema工具层我定义一个订单服务模拟查询真实数据库。这里我们假设订单表里有个状态字段可能是“已支付”“已发货”“已签收”这些值Service public class OrderToolService { public String queryOrderStatus(String orderId) { // 模拟DB查询实际项目里这里可以是MyBatis/JPA调用 MapString, String orders Map.of( A1001, 已发货, A1002, 已签收, A1003, 已支付 ); String status orders.getOrDefault(orderId, 订单号不存在); return 订单 orderId 当前状态为 status 。; } public String updateOrderRemark(String orderId, String remark) { // 模拟DB更新 return 订单 orderId 备注已更新为 remark; } }Agent需要把这个Java方法“告诉”模型让模型知道有这个工具存在。于是你要构造一个工具描述对象包含名称、描述和参数Schema最终转成JSON传给模型。我用一个公共方法统一构建public record ToolSchema(String type, String function) { public static String queryOrderStatusSchema() { return { type: function, function: { name: queryOrderStatus, description: 根据订单号查询订单当前状态订单号必填, parameters: { type: object, properties: { orderId: { type: string, description: 订单编号例如 A1001 } }, required: [orderId] } } } ; } public static String updateOrderRemarkSchema() { return { type: function, function: { name: updateOrderRemark, description: 为指定订单添加一条备注信息订单号必填备注内容必填, parameters: { type: object, properties: { orderId: { type: string, description: 订单编号 }, remark: { type: string, description: 备注内容 } }, required: [orderId, remark] } } } ; } }这里有一个我反复强调的要点描述里一定要把参数必填性写清楚模型选择工具靠的就是这些描述。如果你在描述里写“查询订单”模型可能就会把用户的任何问题都往这个工具上套。5.3 编排Agent主循环接下来是整个Demo的心脏AgentOrchestrator。它做的事情就是维护消息列表、调用模型、发现工具调用则执行、把结果返回给模型直到模型回复最终内容。下面这段代码是核心骨架Component public class AgentOrchestrator { private final ChatClient chatClient; private final OrderToolService orderToolService; public String execute(String userMessage) { // 1. 组装系统提示词和工具列表 String systemPrompt 你是一个订单查询助手。 你的任务是帮助用户查询订单状态、更新订单备注。 当用户询问与订单相关的问题时选择合适的工具处理。 如果用户的问题与订单无关请礼貌地说明你只能处理订单相关事务。 所有回答请使用简洁中文。 ; ListMapString, Object tools List.of( JsonUtils.parseObject(ToolSchema.queryOrderStatusSchema()), JsonUtils.parseObject(ToolSchema.updateOrderRemarkSchema()) ); ListMapString, Object messages new ArrayList(); messages.add(message(system, systemPrompt)); messages.add(message(user, userMessage)); for (int round 0; round 5; round) { // 2. 调用模型 MapString, Object response chatClient.chat(messages, tools); // 3. 将模型输出追加到消息列表 MapString, Object assistantMessage response.get(message); messages.add(assistantMessage); // 4. 检查模型是否请求调用工具 ListMapString, Object toolCalls (ListMapString, Object) assistantMessage.get(tool_calls); if (toolCalls null || toolCalls.isEmpty()) { // 模型没有调用任何工具说明已生成最终答案 return (String) assistantMessage.get(content); } // 5. 遍历tool_calls执行对应工具 for (MapString, Object toolCall : toolCalls) { String functionName (String) ((MapString, Object) toolCall.get(function)).get(name); String arguments (String) ((MapString, Object) toolCall.get(function)).get(arguments); MapString, Object args JsonUtils.parseObject(arguments); Object result; if (queryOrderStatus.equals(functionName)) { result orderToolService.queryOrderStatus((String) args.get(orderId)); } else if (updateOrderRemark.equals(functionName)) { result orderToolService.updateOrderRemark((String) args.get(orderId), (String) args.get(remark)); } else { result 未知工具; } // 6. 工具执行结果也要追加到消息列表roletool String toolCallId (String) toolCall.get(id); messages.add(messageWithTool(toolCallId, functionName, String.valueOf(result))); } } return 抱歉本轮对话处理轮次过多已自动终止。; } }这个循环里信息量很大我拆开讲几个关键点。模型回复里带tool_calls的时候content往往为空或只有一句话这是正常的此时不能把它当最终答案。工具执行结果的消息需要关联toolCallId这样模型才能知道“这个结果是对应刚才哪个调用”。循环次数不可能是无限的加一个上限可以防止模型陷入死循环。5.4 模型调用封装与日志解读最后看一下ChatClient里最核心的调用方法我用Spring WebClient发POST请求请求体里把messages、tools、temperature一起带上Service public class ChatClient { private final WebClient webClient; Value(${llm.base-url}) private String baseUrl; Value(${llm.api-key}) private String apiKey; Value(${llm.model}) private String model; Value(${llm.temperature}) private double temperature; public MapString, Object chat(ListMapString, Object messages, ListMapString, Object tools) { MapString, Object body new HashMap(); body.put(model, model); body.put(messages, messages); body.put(tools, tools); body.put(temperature, temperature); return webClient.post() .uri(baseUrl /v1/chat/completions) .header(Authorization, Bearer apiKey) .bodyValue(body) .retrieve() .bodyToMono(Map.class) .block(); } }当你运行这个Demo输入“帮我查一下订单A1001的状态”你会在日志里看到一段清晰的Agent决策过程第一次调用模型模型返回一个tool_calls调用queryOrderStatus工具参数是A1001。你的代码拿到工具结果“订单A1001当前状态为已发货”把它追加回消息列表。第二次调用模型模型看到工具结果后生成最终回复“您订单A1001的状态是已发货”。关键日志大概是下面这种感觉[Agent Round 1] model - tool_calls: queryOrderStatus({orderId:A1001}) [Tool Executor] queryOrderStatus result: 订单A1001当前状态为已发货。 [Agent Round 2] model - final: 您的订单A1001目前已经发货了。这一套流程跑通之后你其实已经掌握了Agent最核心的能力让模型理解人类指令、让模型调用你的Java方法、让模型基于真实数据回答用户。后面不管换成什么框架核心逻辑都逃不出这个循环。6. 常见问题与排查技巧实录6.1 问题速查表我在实际开发和带人过程中收集了一些Agent开发里高频出现的问题。整理成一张速查表可以帮你少走很多弯路。问题现象可能原因排查方向模型不调用工具直接给答案工具描述不够清晰或用户意图不在工具范围内检查工具描述补充更多触发条件示例工具参数解析报错模型生成的JSON参数里多了字段或类型不对在提示词中写明必填字段和字段格式增加解析容错多轮对话后模型“失忆”消息列表没有完整回传或上下文被截断检查每轮是否有把assistant回复和tool结果入栈回答内容偏离事实模型基于猜测而非工具结果回答在系统提示词中强调“请严格基于工具返回数据回答”响应特别慢上下文太长、模型太大、多次调用模型压缩上下文、换快模型、把确定性逻辑移到代码侧同一问题两次答案不同温度参数过高把temperature调到0.1或直接设为0接口频繁报限流并发超过平台QPS限制在Java侧增加本地限流或连接池复用JSON解析偶尔报错模型输出里混入了Markdown标记或解释文字开启JSON Mode或对内容做清洗再解析6.2 我踩过的三个坑第一个坑是轻信模型的“自我修正能力”。在一次项目里我发现Agent偶尔会把订单状态回答得和数据库不一致查了半天发现原因很乌龙我虽然调用了工具但把工具结果返回给模型之后系统提示词里没有强调“必须以工具结果为准”。于是模型就开始“自由发挥”把“已发货”答成了“已签收”。从那之后我的所有系统提示词里都会加一句“请严格按照工具返回的真实数据作答不要猜测”。第二个坑是上下文爆掉。有段时间我做知识库问答把检索到的所有相关文档都塞进上下文结果用户问了一两次之后提示“超出最大Token限制”。后来我换成“先粗筛再精排”的策略把检索结果控制在3到5段每段不超过500字问题就消失了。记住不是所有检索到的内容都值得喂给模型喂得多反而会干扰判断。第三个坑是忽视工具调用的兜底逻辑。有一次模型返回了一个合法的工具调用名但参数里orderId是null代码直接空指针异常。后来我发现模型在用户没给订单号时可能会把所有参数都设为null或者乱填一个占位符。解决方案是在工具执行前做参数校验如果必填参数缺失就返回一个“参数缺失请向用户追问订单号”的结果给模型让模型去反问用户。这一步把很多体验问题直接消掉了。结尾转型路上的一点个人体会这三个月的路线图写到这里核心内容基本都覆盖了。我个人比较深的体会是Java开发者转Agent开发真正难的从来不是技术而是心态。你需要在“模型输出不可控”这个前提下依然保持工程师对系统稳定性的执念。不要因为模型偶尔抽风就否定整个方向也不要因为模型一次表现惊艳就觉得万事大吉。你要做的是把不可控的部分圈定在最小范围然后用工程手段把可控的部分做到极致。如果你正走在这条路上我建议你从今天就开始做一件小事把你手头最熟悉的一个业务场景试着用大模型加上一次工具调用去实现它。不用管效果好不好跑通循环你就赢了一半。三个月后再回头看你会发现自己已经站在了一个完全不同的技术视野里。
