1. Java 工程師轉(zhuǎn)型 AI Agent 的底層邏輯與路徑選擇1.1 為什么 Java 工程師轉(zhuǎn) AI Agent 有天然優(yōu)勢很多 Java 工程師一聽到“轉(zhuǎn)型 AI”就心里發(fā)怵覺得自己沒學(xué)過 Python、沒碰過 PyTorch、沒讀過 Transformer 論文是不是要從零開始我一開始也這么想但真正上手做了幾個 Agent 項目之后發(fā)現(xiàn)事情完全不是這樣。AI Agent 的本質(zhì)是什么說白了就是一個能“思考-行動-觀察-再思考”的循環(huán)系統(tǒng)。它需要調(diào)用大模型做推理需要調(diào)用工具去執(zhí)行任務(wù)需要管理對話記憶需要處理并發(fā)請求需要做權(quán)限控制需要記錄日志和監(jiān)控。你把這些拆開看哪一樣不是 Java 工程師天天在干的事大模型推理那一層確實 Python 生態(tài)更成熟但 Java 這邊現(xiàn)在有LangChain4j和Spring AI兩個框架已經(jīng)把最臟最累的活干完了。你要做的不是訓(xùn)練模型而是把模型能力編排進業(yè)務(wù)流程里。這恰恰是 Java 工程師最擅長的事情——寫業(yè)務(wù)邏輯、做系統(tǒng)集成、保證服務(wù)穩(wěn)定。我見過太多 Python 背景的算法同學(xué)模型調(diào)得飛起但一讓他做工程化落地就頭疼并發(fā)怎么扛事務(wù)怎么保證服務(wù)怎么治理這些恰恰是 Java 工程師的舒適區(qū)。所以轉(zhuǎn)型的關(guān)鍵不是補算法短板而是把已有的工程能力映射到 AI Agent 這個新場景里。1.2 轉(zhuǎn)型路徑的三種選擇與取舍從 Java 轉(zhuǎn) AI Agent市面上大概有三條路我按投入產(chǎn)出比排個序。第一條路是Spring AI 路線。如果你已經(jīng)在用 Spring Boot 做后端這是最順滑的。Spring AI 的 API 設(shè)計完全遵循 Spring 的編程習(xí)慣ChatClient、EmbeddingClient、VectorStore這些抽象接口用起來跟JdbcTemplate一樣自然。你不需要學(xué)新語言不需要換構(gòu)建工具Maven 加個依賴就能跑起來。缺點是 Spring AI 相對年輕某些高級 Agent 模式比如復(fù)雜的多 Agent 協(xié)作支持得還不夠細。第二條路是LangChain4j 路線。LangChain4j 是 Python LangChain 的 Java 移植版概念幾乎一一對應(yīng)ChatLanguageModel、EmbeddingModel、EmbeddingStore、AiServices。它的優(yōu)勢是 Agent 相關(guān)的抽象更完整比如ToolSpecification、hallucination檢測、RAG 的多路召回都有現(xiàn)成實現(xiàn)。如果你要做的是偏“智能體”而非“智能問答”的東西LangChain4j 的起點更高。第三條路是純手寫路線。不依賴任何框架直接用 HTTP 客戶端調(diào)大模型的 REST API自己實現(xiàn) ReAct 循環(huán)。這條路我不推薦新手走但如果你要深度定制 Agent 的行為邏輯或者要嵌入到已有的非 Spring 系統(tǒng)里手寫反而最靈活。我有個做期貨交易輔助工具的朋友就是純手寫因為他需要對每一次工具調(diào)用做極細粒度的風(fēng)控攔截框架的抽象反而礙事。我的建議是先用 Spring AI 跑通一個最小可用 Agent再用 LangChain4j 補 Agent 特有的能力。兩者并不沖突可以在同一個項目里共存。1.3 一個必須想清楚的問題你的 Agent 到底解決什么問題我見過太多人一上來就問“怎么搭建 AI Agent”但問他 Agent 要干什么答不上來。這是典型的拿著錘子找釘子。AI Agent 不是萬能藥。它適合的場景有明確特征任務(wù)步驟不固定、需要根據(jù)中間結(jié)果動態(tài)調(diào)整、涉及多個工具或數(shù)據(jù)源的編排。比如“幫我查一下上個月銷售額如果同比下降超過 10% 就發(fā)郵件給區(qū)域負責(zé)人并附上下降原因分析”——這種任務(wù)用傳統(tǒng) if-else 寫死也能做但一旦規(guī)則變了就要改代碼。Agent 的價值在于用自然語言描述任務(wù)由模型動態(tài)決定調(diào)用哪些工具、按什么順序調(diào)用。反過來如果你的任務(wù)是“每天凌晨把 A 表數(shù)據(jù)同步到 B 表”這種確定性極強的批處理用 Agent 就是殺雞用牛刀老老實實寫定時任務(wù)更穩(wěn)。所以轉(zhuǎn)型第一步不是學(xué)框架而是找到你業(yè)務(wù)里那個“規(guī)則經(jīng)常變、步驟不固定、需要跨系統(tǒng)協(xié)調(diào)”的場景。找到它你的轉(zhuǎn)型就有了錨點。2. 核心概念拆解ReAct、工具調(diào)用與記憶機制2.1 ReAct 模式Agent 的“思考-行動”循環(huán)到底怎么跑ReAct 是 Reasoning Acting 的縮寫是目前絕大多數(shù) AI Agent 的底層運行模式。它的核心思想特別樸素讓模型在每一步都先“想一想”該干什么然后“動手”去干干完看結(jié)果再想下一步。我用一個實際例子來說明。假設(shè)你讓 Agent 回答“北京今天適合穿什么衣服”。ReAct 循環(huán)是這樣的第一步模型思考我需要知道北京今天的天氣。于是它輸出一個“行動”——調(diào)用天氣查詢工具參數(shù)是城市北京。第二步系統(tǒng)執(zhí)行工具調(diào)用拿到結(jié)果“北京今天晴氣溫 5-15 度北風(fēng) 3 級”。第三步模型觀察這個結(jié)果繼續(xù)思考5-15 度偏涼需要穿外套。于是它輸出最終答案“建議穿薄羽絨服或風(fēng)衣內(nèi)搭長袖?！边@個循環(huán)在代碼里就是一個 while 循環(huán)直到模型輸出“最終答案”或者達到最大迭代次數(shù)。聽起來簡單但魔鬼在細節(jié)里。第一個細節(jié)是提示詞設(shè)計。你得在系統(tǒng)提示里明確告訴模型你有哪幾個工具可用、每個工具的參數(shù)格式是什么、什么時候該調(diào)用工具、什么時候該直接回答。這個提示詞寫得好不好直接決定 Agent 的智商。第二個細節(jié)是工具調(diào)用的解析。模型輸出的工具調(diào)用請求是自然語言或 JSON你需要解析成實際的函數(shù)調(diào)用。Spring AI 和 LangChain4j 都提供了Tool注解或ToolSpecification來簡化這個過程但底層邏輯你得清楚。第三個細節(jié)是循環(huán)終止條件。必須有最大迭代次數(shù)限制否則模型可能陷入死循環(huán)反復(fù)調(diào)用同一個工具。我一般設(shè) 5-8 次超過就強制返回當(dāng)前結(jié)果并記錄告警。2.2 工具調(diào)用Agent 的“手腳”怎么接工具調(diào)用是 Agent 從“聊天機器人”變成“能干活的智能體”的關(guān)鍵。沒有工具調(diào)用模型只能基于訓(xùn)練數(shù)據(jù)回答問題有了工具調(diào)用它就能查數(shù)據(jù)庫、調(diào) API、發(fā)郵件、操作文件。在 Spring AI 里定義一個工具非常簡單Component public class WeatherTools { Tool(description 查詢指定城市的實時天氣) public String getWeather(ToolParam(description 城市名稱) String city) { // 實際調(diào)用天氣 API return weatherApi.query(city); } }然后在構(gòu)建 ChatClient 時注冊這個工具ChatClient chatClient ChatClient.builder(chatModel) .defaultTools(new WeatherTools()) .build();LangChain4j 的做法類似用Tool注解標注方法然后在AiServices接口里聲明。但這里有幾個坑我必須提醒你。坑一工具描述寫得太簡略。模型是根據(jù)工具描述來決定要不要調(diào)用的。如果你只寫“查詢天氣”模型可能不知道什么時候該用。要寫清楚“當(dāng)用戶詢問某城市天氣、氣溫、是否適合出行時調(diào)用此工具”。坑二工具參數(shù)類型太復(fù)雜。模型對簡單類型String、int、boolean的解析準確率最高。如果你傳一個嵌套對象模型很容易生成格式錯誤的參數(shù)。我的經(jīng)驗是工具參數(shù)盡量扁平化復(fù)雜結(jié)構(gòu)拆成多個簡單參數(shù)?？尤ぞ邎?zhí)行沒有超時和熔斷。Agent 調(diào)用工具是自動的如果某個工具響應(yīng)很慢或者掛了整個 Agent 循環(huán)就會卡住。必須給每個工具調(diào)用加超時比如 3 秒和熔斷連續(xù)失敗 3 次就暫時禁用。2.3 記憶機制讓 Agent 記住上下文沒有記憶的 Agent 就像金魚每輪對話都從零開始。記憶機制解決的就是這個問題。記憶分兩種短期記憶和長期記憶。短期記憶就是當(dāng)前對話的歷史消息。Spring AI 的ChatMemory接口默認實現(xiàn)是InMemoryChatMemory把消息存在內(nèi)存里。但生產(chǎn)環(huán)境你不能用內(nèi)存因為服務(wù)重啟就丟了而且多實例部署時會話不共享。我一般用 Redis 做短期記憶存儲key 是會話 IDvalue 是消息列表設(shè)置 30 分鐘過期。長期記憶則是跨會話的知識。比如用戶上次說“我對花生過敏”這次點餐時 Agent 應(yīng)該記得。長期記憶通常用向量數(shù)據(jù)庫實現(xiàn)把重要信息 embedding 后存進去每次對話時檢索相關(guān)記憶注入提示詞。LangChain4j 在這方面提供了ChatMemoryStore和EmbeddingStore的組合方案Spring AI 也有VectorStore抽象。但我要說的是記憶不是越多越好。你把所有歷史消息都塞進提示詞token 消耗巨大不說還會稀釋當(dāng)前問題的注意力。我的做法是短期記憶保留最近 10 輪對話長期記憶只存用戶明確表達的偏好和事實檢索時取 top 3 相關(guān)記憶。3. 從零搭建一個可落地的 Java AI Agent3.1 環(huán)境準備與依賴選型我以 Spring Boot 3.x Spring AI 為例走一遍完整搭建流程。選 Spring AI 是因為它對 Java 工程師最友好而且和現(xiàn)有 Spring 生態(tài)無縫集成。首先JDK 版本至少 17推薦 21。Spring AI 用到了很多新特性JDK 17 是底線。Maven 依賴方面核心是這幾個dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0-M6/version /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-redis-store-spring-boot-starter/artifactId version1.0.0-M6/version /dependency如果你用的是國內(nèi)的大模型服務(wù)比如百煉、智譜把spring-ai-openai換成對應(yīng)的 starter 即可。Spring AI 的抽象層設(shè)計得很好換模型提供商只需要改配置代碼基本不動。配置文件里至少要配這些spring: ai: openai: api-key: ${AI_API_KEY} base-url: https://api.example.com chat: options: model: qwen-plus temperature: 0.7 max-tokens: 2000這里temperature設(shè) 0.7 是個經(jīng)驗值。做 Agent 任務(wù)時溫度太高會導(dǎo)致模型“胡思亂想”調(diào)用不該調(diào)的工具溫度太低又會讓它過于死板遇到稍微變化的任務(wù)就不知道變通。0.7 是我試下來比較平衡的值。3.2 定義 Agent 的工具集與系統(tǒng)提示詞工具集的設(shè)計直接決定 Agent 的能力邊界。我建議按“領(lǐng)域”來組織工具類每個類負責(zé)一組相關(guān)操作。比如做一個“運維助手 Agent”工具類可以這樣分ServerTools查服務(wù)器狀態(tài)、重啟服務(wù)、查日志DatabaseTools執(zhí)行查詢、查表結(jié)構(gòu)、查慢查詢AlertTools發(fā)告警、查告警歷史、靜默告警每個工具方法的描述要寫得像給新人看的操作手冊。我舉個例子Tool(description 根據(jù)服務(wù)名查詢該服務(wù)最近N分鐘的ERROR級別日志條數(shù)。 當(dāng)用戶詢問服務(wù)是否異常、有沒有報錯時使用此工具。 參數(shù)serviceName必須是已知的服務(wù)名minutes范圍1-1440) public int countErrorLogs( ToolParam(description 服務(wù)名稱如 order-service) String serviceName, ToolParam(description 查詢最近多少分鐘默認30) int minutes) { // 實現(xiàn)邏輯 }系統(tǒng)提示詞是 Agent 的“人格設(shè)定”。我一般包含這幾部分你是一個運維助手負責(zé)幫助工程師排查線上問題。 你可以使用以下工具查日志、查服務(wù)器狀態(tài)、查數(shù)據(jù)庫、發(fā)告警。 排查問題時先查日志確認錯誤類型再查服務(wù)器狀態(tài)確認資源是否正常最后給出結(jié)論。 如果工具返回結(jié)果不足以判斷可以繼續(xù)調(diào)用其他工具但最多調(diào)用 5 次。 不要編造工具沒有返回的信息。如果無法確定原因如實告知用戶。這段提示詞里“先查日志再查服務(wù)器”是給 Agent 的排查策略“最多 5 次”是防止死循環(huán)“不要編造”是抑制幻覺。每一條都是踩過坑之后加上的。3.3 實現(xiàn) ReAct 循環(huán)與工具調(diào)用編排Spring AI 從 1.0.0-M6 開始ChatClient已經(jīng)內(nèi)置了工具調(diào)用的自動編排。你只需要這樣寫String response chatClient.prompt() .user(order-service 最近半小時有沒有報錯) .tools(new ServerTools(), new DatabaseTools()) .call() .content();框架會自動處理“模型請求調(diào)用工具 - 執(zhí)行工具 - 把結(jié)果喂回模型 - 模型繼續(xù)推理”這個循環(huán)。但如果你想自定義循環(huán)邏輯比如加風(fēng)控攔截、加人工確認就需要手動實現(xiàn)。手動實現(xiàn)的骨架大概是這樣public String runAgent(String userInput, int maxIterations) { ListMessage messages new ArrayList(); messages.add(new SystemMessage(SYSTEM_PROMPT)); messages.add(new UserMessage(userInput)); for (int i 0; i maxIterations; i) { ChatResponse response chatModel.call(new Prompt(messages)); AssistantMessage assistantMessage response.getResult().getOutput(); if (assistantMessage.hasToolCalls()) { for (ToolCall toolCall : assistantMessage.getToolCalls()) { // 風(fēng)控攔截點 if (!riskChecker.allow(toolCall)) { messages.add(new ToolResponseMessage(操作被風(fēng)控攔截)); continue; } String result toolExecutor.execute(toolCall); messages.add(new ToolResponseMessage(result)); } } else { return assistantMessage.getContent(); } } return 達到最大迭代次數(shù)未能完成任務(wù); }這個骨架里riskChecker就是你的風(fēng)控入口。比如涉及“重啟服務(wù)”“刪除數(shù)據(jù)”這類高危操作可以在這里攔截轉(zhuǎn)人工確認。3.4 并發(fā)場景下的 Agent 穩(wěn)定性設(shè)計“AI Agent 怎么扛并發(fā)”是個高頻問題。我的答案是Agent 本身是無狀態(tài)的扛并發(fā)的關(guān)鍵在外部資源管理。Agent 的一次完整運行涉及三類資源大模型 API、工具背后的服務(wù)、記憶存儲。大模型 API 通常有 QPS 限制。你不能讓 1000 個請求同時打過去必須加限流。我用 Resilience4j 的RateLimiter做客戶端限流配置成和 API 提供方的限制一致。超出的請求排隊等待而不是直接失敗。工具背后的服務(wù)可能是數(shù)據(jù)庫、內(nèi)部 API。這些服務(wù)本身有連接池限制Agent 調(diào)用時要注意復(fù)用連接池不要每次調(diào)用都新建連接。另外工具調(diào)用要加超時我一般設(shè) 3 秒超過就返回“工具超時”讓模型決定是重試還是換方案。記憶存儲用 Redis 時要注意大 key 問題。對話歷史如果很長不要整個 list 一把梭可以按消息 ID 分片存儲或者只存最近 N 條。還有一個容易被忽略的點Agent 循環(huán)的耗時。一次 ReAct 循環(huán)可能調(diào)用 3-5 次大模型每次 2-5 秒總共就是 10-25 秒。如果你的接口是同步的用戶會等很久。我的做法是改成異步提交任務(wù)返回 taskId前端輪詢或走 SSE 推送結(jié)果。4. 實戰(zhàn)避坑與高頻問題排查4.1 模型“不聽話”的幾種典型表現(xiàn)與對策Agent 開發(fā)中最讓人抓狂的就是模型不按預(yù)期行事。我總結(jié)了幾種典型情況。情況一該調(diào)工具的時候不調(diào)直接編答案。比如問“今天天氣”模型不調(diào)天氣工具直接說“今天晴天”。這是幻覺的典型表現(xiàn)。對策是在系統(tǒng)提示里強調(diào)“涉及實時數(shù)據(jù)必須調(diào)用工具”同時在工具描述里寫清楚觸發(fā)條件。如果還不行可以在用戶輸入前加一個預(yù)處理步驟用規(guī)則或小模型判斷是否需要工具需要的話在提示詞里強制要求。情況二調(diào)了工具但參數(shù)傳錯。比如把“order-service”傳成“order_service”。對策是工具參數(shù)盡量用枚舉或白名單校驗在工具實現(xiàn)里做參數(shù)規(guī)范化。另外可以在提示詞里給出參數(shù)示例。情況三陷入循環(huán)反復(fù)調(diào)同一個工具。比如查日志沒查到就一直查。對策是設(shè)最大迭代次數(shù)同時在提示詞里加“如果連續(xù)兩次調(diào)用同一工具且結(jié)果相同應(yīng)停止并告知用戶”。情況四工具返回結(jié)果太長模型處理不了。比如查日志返回了 1000 行。對策是在工具實現(xiàn)里做截斷和摘要只返回關(guān)鍵信息。我一般限制工具返回不超過 2000 字符。4.2 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案Agent 不調(diào)用工具工具描述不清、提示詞未強調(diào)打印模型原始輸出看是否有 tool_calls完善工具描述提示詞加強制要求工具調(diào)用參數(shù)錯誤參數(shù)類型復(fù)雜、缺少示例查看工具調(diào)用日志中的參數(shù)扁平化參數(shù)提示詞加示例循環(huán)不終止無最大迭代限制、工具返回空統(tǒng)計迭代次數(shù)設(shè) maxIterations空結(jié)果時提示模型響應(yīng)時間過長同步調(diào)用、模型慢打點各階段耗時改異步加超時換更快的模型并發(fā)下報錯API 限流、連接池耗盡看限流和連接池指標客戶端限流擴大連接池記憶混亂歷史消息過多、多會話串?dāng)_檢查會話 ID 隔離限制歷史條數(shù)Redis 按會話隔離4.3 我踩過的三個印象最深的坑第一個坑工具方法拋異常導(dǎo)致整個 Agent 崩潰。早期我沒在工具執(zhí)行層加 try-catch某個工具拋了 NPE整個請求 500。后來我在toolExecutor里統(tǒng)一捕獲異常把異常信息作為工具返回結(jié)果喂回模型讓模型決定怎么辦。這樣即使工具掛了Agent 也能優(yōu)雅降級。第二個坑Redis 記憶沒有設(shè)過期時間。上線跑了一周Redis 內(nèi)存爆了。后來所有記憶 key 都加了 TTL短期記憶 30 分鐘長期記憶 7 天。另外做了內(nèi)存監(jiān)控告警。第三個坑提示詞里的工具列表和實際注冊的工具不一致。我改代碼加了個工具忘了更新提示詞結(jié)果模型不知道新工具存在一直用舊工具湊合。后來我把工具列表做成動態(tài)生成從注冊的工具里自動拼提示詞杜絕了不一致。4.4 從 Demo 到生產(chǎn)的最后一公里Demo 跑通只要一天但上線要做的還很多?？捎^測性每次 Agent 運行要記錄完整軌跡——用戶輸入、每輪模型輸出、工具調(diào)用參數(shù)和結(jié)果、最終答案、總耗時。這些日志是排查問題的唯一依據(jù)。我一般用結(jié)構(gòu)化日志方便后續(xù)分析。成本控制大模型調(diào)用是按 token 計費的。一個 Agent 任務(wù)可能消耗幾千 token。要做預(yù)算控制比如單次任務(wù) token 上限、單用戶日限額。另外緩存高頻問題的答案能省不少錢。安全防護Agent 能調(diào)工具就意味著它能產(chǎn)生副作用。必須做權(quán)限控制——哪些用戶能用哪些工具、高危操作要不要二次確認、工具調(diào)用要不要審計。我見過一個案例Agent 被誘導(dǎo)調(diào)用了刪除數(shù)據(jù)的工具幸好有審計日志才追回來?；叶劝l(fā)布新 Agent 上線先小流量灰度觀察成功率、耗時、成本指標沒問題再全量。別一上來就全量出了事回滾都來不及。5. 轉(zhuǎn)型路上的學(xué)習(xí)路線與資源取舍5.1 分階段學(xué)習(xí)路線我按自己的經(jīng)驗把 Java 工程師轉(zhuǎn) AI Agent 分成三個階段。第一階段1-2 周跑通最小閉環(huán)。目標是用 Spring AI 或 LangChain4j 做一個能調(diào)用 1-2 個工具的 Agent。重點理解 ChatClient、Tool、ChatMemory 這三個核心概念。這個階段不要追求功能多追求的是“跑通”。第二階段3-4 周補齊 Agent 特有知識。重點學(xué) ReAct 模式、RAG檢索增強生成、多路召回、向量數(shù)據(jù)庫。LangChain4j 的Easy RAG模塊是很好的入門材料。這個階段要動手做一個帶知識庫的問答 Agent。第三階段1-2 月工程化與生產(chǎn)化。重點學(xué)并發(fā)控制、可觀測性、成本優(yōu)化、安全防護。這個階段最好的學(xué)習(xí)材料是你自己的生產(chǎn)環(huán)境——把前兩個階段做的東西真正部署上去接受真實流量的考驗。5.2 資源取舍哪些該看哪些可以跳過網(wǎng)上 AI Agent 的資料鋪天蓋地但質(zhì)量參差不齊。我的篩選標準是優(yōu)先看官方文檔和源碼其次看有完整代碼的實戰(zhàn)教程最后才看概念科普。Spring AI 和 LangChain4j 的官方文檔質(zhì)量都很高而且有大量示例代碼。遇到不懂的類直接看源碼比看二手教程快得多。概念性的東西比如 Transformer 原理、注意力機制Java 工程師轉(zhuǎn)型做 Agent 開發(fā)其實不需要深究。你是用模型的人不是訓(xùn)模型的人。知道 token、temperature、context window 這些概念就夠了。至于 Python 生態(tài)的 LangChain、AutoGPT 這些可以了解其設(shè)計思想但不必深入代碼。Java 生態(tài)的對應(yīng)實現(xiàn)已經(jīng)足夠用了。5.3 一個容易被忽略的能力提示詞工程很多 Java 工程師覺得提示詞工程“不算技術(shù)”這是大錯特錯。在 Agent 開發(fā)里提示詞就是你的核心業(yè)務(wù)邏輯。同樣的模型、同樣的工具提示詞寫得好壞效果天差地別。我建議把提示詞當(dāng)代碼來管理版本控制、A/B 測試、效果評估。我一般會維護一個提示詞庫每個提示詞有版本號、適用場景、效果指標。改提示詞要走評審改完要跑回歸測試。提示詞寫作的核心原則就幾條指令明確、格式清晰、給示例、設(shè)邊界。別寫模棱兩可的話別讓模型猜你的意圖。6. 關(guān)于轉(zhuǎn)型這件事我最后想說的轉(zhuǎn)型不是把 Java 扔掉去學(xué) Python而是把 Java 的工程能力遷移到 AI Agent 這個新場景。你的并發(fā)經(jīng)驗、事務(wù)經(jīng)驗、服務(wù)治理經(jīng)驗在 Agent 生產(chǎn)化階段全是寶貝。缺的那塊拼圖——大模型交互、ReAct 循環(huán)、向量檢索——補起來并不難因為有 Spring AI 和 LangChain4j 這樣的框架幫你兜底。我自己的體會是前兩周最痛苦因為概念全是新的跑個 Demo 都能遇到一堆環(huán)境問題。但一旦跑通第一個閉環(huán)后面就是滾雪球。因為 Agent 開發(fā)的本質(zhì)還是軟件工程而軟件工程是你的主場。如果你現(xiàn)在還在觀望我的建議是今天就去建一個 Spring Boot 項目加一個 Spring AI 依賴寫一個能查天氣的 Agent。不用想太多先跑起來。跑起來之后你自然知道下一步該學(xué)什么。