最近在做AI對話App的項目原本以為所有工作量都會集中在模型調(diào)優(yōu)和對話體驗上真正動手才發(fā)現(xiàn)很多人第一步就卡在了“項目創(chuàng)建和運行”這里。倒不是說這一關(guān)有多難而是從空目錄到服務(wù)能本地跑起來的整個流程里藏著大量“默認你會但新手根本不知道”的細節(jié)技術(shù)棧怎么選、IDEA 2024怎么建Web項目、前端怎么用pnpm初始化、后端模型API怎么接、遇到報錯怎么定位……這篇文章就把我這次從零開始搭建并跑通AI對話App的完整過程寫下來適合正在準備做AI應(yīng)用開發(fā)、想搞懂項目創(chuàng)建到運行全流程的人參考。1. AI對話App的骨架設(shè)計先定形態(tài)再選技術(shù)棧1.1 你的App到底屬于哪一類做AI對話App之前先別急著打開IDE而是要回答一個問題你做的“App”是給用戶在瀏覽器里用的Web應(yīng)用是打包成安卓/iOS的手機客戶端還是偏向Agent自動化任務(wù)的工具型應(yīng)用這個問題的答案直接決定了項目創(chuàng)建方式。我這次的目標是一個功能完整的對話應(yīng)用用戶輸入問題后端調(diào)用大模型接口模型流式返回內(nèi)容前端實時展示。最常見、也最適合快速驗證的形態(tài)就是前后端分離的Web應(yīng)用——瀏覽器即App開發(fā)調(diào)試成本最低后續(xù)要轉(zhuǎn)成手機App也可以用同一套后端接口。技術(shù)棧選型上后端我用了Java 17 Spring Boot 3.x前端用Vue 3 Vite pnpm。沒有用更花哨的方案原因后面逐一說明。1.2 技術(shù)棧選型的真實理由后端選擇Spring Boot 3最重要的原因是生態(tài)成熟。Spring Boot自帶內(nèi)置Tomcat項目創(chuàng)建完成后不需要額外配置外部容器直接Run就能起服務(wù)這對“讓項目先跑起來”這個目標非常友好。IDEA 2024對Spring Boot的支持已經(jīng)很完善創(chuàng)建Web項目、運行、斷點調(diào)試都是點按操作不需要自己手搓一堆配置文件。Java本身的類型安全也讓大模型接口返回的數(shù)據(jù)結(jié)構(gòu)處理更可控——那些字段是String、那些是List、哪些可能為空編譯期就能發(fā)現(xiàn)一堆低級錯誤。前端選Vue 3 Vite是因為它足夠輕。Vite的冷啟動速度非?？旄耐甏a頁面秒級刷新開發(fā)體驗比老一代構(gòu)建工具好太多。pnpm則解決了node_modules體積大、依賴安裝慢的問題同一個項目用npm要裝一分鐘用pnpm可能十幾秒就完事而且磁盤占用只有npm一半不到。移動端后續(xù)如果要接Flutter也不影響——Flutter項目可以直接復用這個后端接口只是把UI層換成Dart代碼。提示技術(shù)棧沒有絕對的對錯核心是“能讓你最快跑起來并驗證想法”。團隊熟悉哪套用哪套不要為了追新而選擇一個沒人會的框架。1.3 運行環(huán)境清單項目能跑起來依賴以下運行環(huán)境建議提前確認環(huán)境版本要求用途JDK17及以上Spring Boot 3.x要求Java 17起步Maven3.6及以上后端依賴管理Node.js18及以上前端構(gòu)建工具鏈pnpm8及以上前端依賴安裝Redis5.0及以上會話上下文緩存可選但推薦大模型API Key任意兼容OpenAI協(xié)議的服務(wù)對話能力的來源這里特別說明一下Redis如果只是本地開發(fā)、單用戶調(diào)試可以先用內(nèi)存Map存會話不引入Redis。但如果目標是做出一個支持多會話的AI對話App建議從一開始就引入Redis。因為大模型對話需要攜帶上下文也就是把歷史消息一起傳給模型這些消息存在哪里、怎么和用戶Session關(guān)聯(lián)用Redis是教科書級的標準答案。2. 項目創(chuàng)建的真實操作IDEA 2024 Vite pnpm一個都不能少2.1 用IDEA 2024創(chuàng)建Spring Boot后端項目打開IDEA 2024選擇新建項目。這里要注意新版IDEA的創(chuàng)建向?qū)Ш团f版有區(qū)別項目類型要選Spring Boot而不是傳統(tǒng)的Java Web項目模板。Java版本選17構(gòu)建工具選MavenSpring Boot版本選3.2.x這類穩(wěn)定版本。依賴項勾選Spring Web、Spring Validation、Spring Data Redis、Lombok。創(chuàng)建完成后IDEA會自動生成標準的Maven項目結(jié)構(gòu)src/main/java、src/main/resources、pom.xml。第一個坑往往出現(xiàn)在這里——Maven依賴下載。由于網(wǎng)絡(luò)原因maven-central倉庫下載可能非常慢甚至失敗。解決方案是在Maven的settings.xml中配置阿里云鏡像之后pom.xml里的依賴基本秒下。第二個坑是IDEA本身沒有自動識別Maven項目導致右側(cè)Maven面板為空。遇到這種情況在pom.xml上右鍵選擇“Add as Maven Project”即可。對于IDEA運行Java Web項目的配置Spring Boot時代已經(jīng)不需要手動配置外部Tomcat了。spring-boot-starter-web依賴自帶內(nèi)嵌Tomcat直接運行src/main/java下的SpringBootApplication主類內(nèi)置容器就會啟動在8080端口。如果是老的Servlet項目才需要配置Artifacts和外部Tomcat這一點在新手群里經(jīng)常被混淆。2.2 用Vite和pnpm初始化前端項目前端項目創(chuàng)建有兩種方式一種是用IDEA自帶的前端項目向?qū)Я硪环N是用命令行。我習慣用命令行因為更通用換到任何環(huán)境都能復現(xiàn)pnpm create vite ai-chat-web -- --template vue執(zhí)行后會生成一個Vite Vue 3的項目骨架。進入目錄安裝依賴cd ai-chat-web pnpm install這里大概率會遇到熱詞里那條經(jīng)典報錯——“pnpm : 無法將“pnpm”項識別為 cmdlet、函數(shù)、腳本文件或可運行程序的名稱”。原因很簡單pnpm是用npm全局安裝的但安裝目錄沒有加入系統(tǒng)PATH。排查鏈路是這樣的先確認npm install -g pnpm是否成功再執(zhí)行npm config get prefix查看全局安裝路徑最后把該路徑加入系統(tǒng)環(huán)境變量Path重新打開終端pnpm -v就正常了。前端項目還要裝幾個必要的庫pnpm add axios element-plusaxios用來發(fā)HTTP請求element-plus提供對話列表、輸入框、消息氣泡等UI組件省去手寫組件的成本。UI組件的選擇不會影響項目能不能跑但能讓你把更多精力放在業(yè)務(wù)邏輯而非樣式上。2.3 初始化配置application.yml和.env應(yīng)該寫什么后端配置文件在src/main/resources/application.yml。最基本的配置如下server: port: 8080 spring: application: name: ai-chat-server data: redis: host: localhost port: 6379 ai: model: api-key: ${AI_API_KEY} base-url: https://api.example.com/v1 chat-model: deepseek-chat max-tokens: 2048 temperature: 0.7api-key用環(huán)境變量的方式注入而不是把真實Key寫死在配置文件里。這個習慣很重要因為項目一旦提交到Git倉庫然后推到公開平臺寫死在代碼里的Key就等于泄露了。base-url是模型API的服務(wù)地址兼容OpenAI協(xié)議的服務(wù)基本都長這樣只是域名不同。前端環(huán)境變量在項目根目錄創(chuàng)建.env文件VITE_API_BASE_URLhttp://localhost:8080前后端分離開發(fā)時前端頁面跑在5173端口后端接口跑在8080端口瀏覽器訪問前端頁面發(fā)請求到后端就存在跨域問題。所以開發(fā)階段更推薦的做法是在Vite配置里加代理讓前端請求/api開頭的路徑時自動轉(zhuǎn)發(fā)到后端這樣在代碼里只需要寫相對路徑。Vite的vite.config.js配置如下import { defineConfig } from vite; import vue from vitejs/plugin-vue; export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } });這套配置意味著前端頁面發(fā)起fetch(/api/chat/stream)時實際請求會被Vite開發(fā)服務(wù)器轉(zhuǎn)發(fā)到http://localhost:8080/api/chat/stream瀏覽器端不存在跨域問題后端也不需要額外開啟CORS。2.4 建立一次“無AI版”的聯(lián)調(diào)在接入模型API之前先讓前后端能通過一次最簡單的接口調(diào)用聯(lián)通。后端寫一個健康檢查接口RestController RequestMapping(/api/ping) public class PingController { GetMapping public MapString, String ping() { return Map.of(message, pong); } }前端在頁面里調(diào)用一次const res await fetch(/api/ping); const data await res.json(); console.log(data.message); // pong這一步驗證的是整個鏈路前端端口、代理轉(zhuǎn)發(fā)、后端啟動、端口監(jiān)聽、響應(yīng)序列化。如果這里通了說明項目創(chuàng)建和基礎(chǔ)運行沒有任何問題接下來的AI對話接入就純粹是業(yè)務(wù)邏輯了。我見過太多人一上來就直接寫對話接口結(jié)果前端怎么調(diào)都不通排查半天發(fā)現(xiàn)是代理沒配上浪費時間。3. 接入模型API是核心從HTTP請求到SSE流式的完整鏈路3.1 為什么走HTTP協(xié)議而不是官方SDK很多模型服務(wù)商都提供了官方SDK比如用Python的openai庫一行代碼就能調(diào)用模型。但我的建議是如果后端是Java直接走HTTP協(xié)議反而更可控。原因有三個第一減少項目依賴。SDK本質(zhì)上是把HTTP請求封裝了一層引入一個SDK就是引入一堆傳遞依賴一旦SDK版本更新引起沖突排查成本遠高于自己寫一個WebClient方法。第二Java生態(tài)下官方對大模型接口的封裝普遍一般錯誤信息經(jīng)過SDK透傳后往往丟失原始響應(yīng)體出了問題很難定位。第三直接走HTTP意味著可以方便地切換任何兼容OpenAI協(xié)議的模型服務(wù)只需要改配置里的base-url和model名稱代碼一行不用動。3.2 后端實現(xiàn)流式對話WebClient FluxAI對話最核心的體驗是“打字機效果”也就是模型生成內(nèi)容邊生成邊顯示。實現(xiàn)方式不是普通的一次性HTTP請求而是長連接流式傳輸技術(shù)術(shù)語叫SSEServer-Sent Events服務(wù)器推送事件。SSE協(xié)議非常簡單服務(wù)端按行返回數(shù)據(jù)每行格式是data: 內(nèi)容以空行分隔不同消息。Java后端用Spring WebFlux里的WebClient發(fā)起流式請求代碼結(jié)構(gòu)如下Service public class ChatServiceImpl implements ChatService { private final WebClient webClient; private final ModelProperties properties; public ChatServiceImpl(ModelProperties properties) { this.properties properties; this.webClient WebClient.builder() .baseUrl(properties.getBaseUrl()) .defaultHeader(HttpHeaders.AUTHORIZATION, Bearer properties.getApiKey()) .build(); } public FluxServerSentEventString stream(String sessionId, ListMessage messages) { return webClient.post() .uri(/chat/completions) .bodyValue(Map.of( model, properties.getChatModel(), messages, messages, stream, true, max_tokens, properties.getMaxTokens(), temperature, properties.getTemperature() )) .retrieve() .bodyToFlux(String.class) .mapNotNull(this::parseContent); } }這里有幾個關(guān)鍵決策要解釋。stream: true告訴模型服務(wù)端返回SSE格式的流。bodyToFlux(String.class)表示響應(yīng)體按字符串行讀取。每個String對象包含一行SSE數(shù)據(jù)需要從中解析出data:前綴后面的JSON再從JSON的choices[0].delta.content字段取出本次增量的文本。mapNotNull負責過濾掉心跳包這類無內(nèi)容的數(shù)據(jù)。我最初踩過的一個坑是超時配置。Spring WebClient默認的響應(yīng)超時對于流式接口來說太短了模型思考時間長一點就會斷開連接。解決方法是給WebClient設(shè)置讀取超時比如60秒甚至更長HttpClient httpClient HttpClient.create() .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 10000) .doOnConnected(conn - conn.addHandlerLast(new ReadTimeoutHandler(120))); SslContext sslContext SslContextBuilder.forClient().build(); WebClient webClient WebClient.builder() .clientConnector(new ReactorClientHttpConnector(httpClient, sslContext)) .build();3.3 前端解析流式返回ReadableStream逐字讀取前端拿到SSE流之后不能用普通的response.json()去解析而是要讀取response.body也就是ReadableStream。核心代碼如下const response await fetch(/api/chat/stream, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ sessionId, messages }) }); const reader response.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop() || ; for (const line of lines) { if (line.startsWith(data: )) { const payload line.slice(6); if (payload [DONE]) continue; const json JSON.parse(payload); const content json.choices[0]?.delta?.content || ; if (content) { appendMessage(content); // 追加到當前回答氣泡 } } } }buffer的作用非常關(guān)鍵。網(wǎng)絡(luò)傳輸是按字節(jié)包過來的一次reader.read()返回的數(shù)據(jù)不一定是完整的一行可能半行也可能多行。所以要把讀到的字節(jié)先追加到buffer里再按換行符切分最后一行沒有換行符的字節(jié)留在buffer里等待下一次讀取合并。這就是流式解析的經(jīng)典處理方式我一開始沒寫buffer結(jié)果模型輸出的內(nèi)容經(jīng)常被截斷成亂碼排查了很久才定位到是分幀拼接的問題。為什么選SSE而不是WebSocket這是很多人的疑問。AI對話本質(zhì)上是從服務(wù)端到客戶端單向的流式傳輸用戶發(fā)消息是一次獨立的POST請求服務(wù)端回傳是一路流。這種“一上多下”的模型用SSE天然合適實現(xiàn)簡單、自動支持HTTP重連、穿透代理容易。WebSocket是雙向全雙工功能更強但如果只是為了接收模型輸出用它屬于殺雞用牛刀還多引入一套連接管理的復雜度。3.4 上下文管理讓每輪對話“記得住”模型本身不記憶任何歷史對話所謂上下文就是每次請求都帶上之前的消息記錄。一個標準的消息結(jié)構(gòu)是這樣的[ {role: system, content: 你是一個友好的AI助手}, {role: user, content: 什么是AI}, {role: assistant, content: AI是人工智能的縮寫……}, {role: user, content: 它有什么用} ]后端收到新對話請求時根據(jù)sessionId從Redis取出歷史消息數(shù)組拼裝上新消息一起發(fā)給模型。模型返回的content再追加到歷史消息中存回Redis。這樣每一輪對話都攜帶全部歷史模型就能“記得”之前聊過什么。token長度的問題需要提前預防。對話越長歷史消息越多超出模型的上下文窗口就會報錯。我的處理方式是設(shè)定一個最大歷史長度比如只保留最近10輪對話超過時丟棄最舊的消息。這個策略在AI對話App開發(fā)里非常常見屬于在“記憶深度”和“token成本”之間尋找平衡點ListMessage trimmed new ArrayList(history); while (trimmed.size() MAX_MESSAGES) { trimmed.remove(1); // 保留第一條system消息移除舊的user/assistant消息 }4. 讓項目跑起來的細節(jié)啟動順序、代理轉(zhuǎn)發(fā)與第一次對話實測4.1 后端啟動步驟與配置檢查后端啟動步驟順序很重要。先啟動Redis如果本地裝了再啟動Spring Boot主類。如果Redis沒啟動Spring Data Redis的配置會自動重試連接項目啟動會拖時間甚至直接失敗。Redis是本地開發(fā)環(huán)境最容易忽略的外部依賴建議用Docker一條命令起docker run -d -p 6379:6379 --name redis redis:7-alpine啟動Spring Boot后看控制臺日志。出現(xiàn)Started AiChatServerApplication表示啟動成功Tomcat started on port 8080表示端口監(jiān)聽正常。如果端口被占用會報Port 8080 was already in use。處理方式有兩種改端口或者找到占用進程殺掉。Windows下查看端口占用netstat -ano | findstr 8080 taskkill /PID 進程號 /F這里有個經(jīng)驗Java項目的報錯信息一定要完整看完。很多人看到紅色日志就慌其實關(guān)鍵信息往往在最后幾行。比如APPLICATION FAILED TO START下面的Description和Action兩段直接告訴你哪里配置錯了、應(yīng)該怎么改照著做就行。4.2 前端啟動步驟與聯(lián)調(diào)檢查前端啟動只需要一條命令pnpm devVite默認把服務(wù)跑在http://localhost:5173。打開瀏覽器按F12打開開發(fā)者工具切到Network面板重新刷新頁面如果看到/api/ping請求返回200和{message:pong}說明代理配置成功。如果報錯優(yōu)先檢查vite.config.js的proxy配置確認target端口和實際后端端口一致。一個非常容易踩的坑是后端端口改了但前端代理沒同步改結(jié)果所有請求全部返回404。另一個坑是代理配置里的changeOrigin必須設(shè)為true否則后端拿到的Host頭是前端地址某些鑒權(quán)邏輯會出問題。4.3 第一次完整對話實測前后端聯(lián)通后把對話請求真正發(fā)出去。第一次實測建議不要畫太多UI就在頁面里寫一個最簡單的輸入框和按鈕點擊后調(diào)用3.3節(jié)那段fetch代碼。如果頁面上正常看到“打字機效果”的文字逐字出現(xiàn)恭喜你整個AI對話App的核心鏈路已經(jīng)完全跑通了。實測出現(xiàn)的攔路虎主要集中在三類第一類是401鑒權(quán)失敗?？刂婆_輸出Invalid authentication credentials八成是環(huán)境變量AI_API_KEY沒生效。IDEA里配置環(huán)境變量要在Run Configuration的Environment variables里填或者在啟動前用命令行export AI_API_KEYxxxx設(shè)置。直接在application.yml里寫死api-key: ${AI_API_KEY}但沒設(shè)環(huán)境變量啟動時會得到一個占位符字符串而不是真實Key。第二類是404。請求/api/chat/stream返回404先看Controller路徑和請求路徑是否完全一致再看produces MediaType.TEXT_EVENT_STREAM_VALUE有沒有寫對。還有一個隱蔽問題Spring Boot 3中如果Controller方法接收Flux返回值必須引入spring-boot-starter-webflux依賴否則不會按SSE處理。第三類是流式內(nèi)容不展示。接口能通但內(nèi)容是等全部生成完才一次性顯示。這種問題幾乎都是請求頭里少了Accept: text/event-stream或者前端用了response.json()而不是讀response.body。按下F12看響應(yīng)類型如果Content-Type是application/json而不是text/event-stream就說明后端SSE沒有生效。4.4 數(shù)據(jù)庫和Key的安全配置一個成熟的項目從一開始就應(yīng)該把敏感配置隔離。API Key不要出現(xiàn)在任何代碼文件里統(tǒng)一走環(huán)境變量。如果是在IDEA里調(diào)試可以在.env文件或IDEA的環(huán)境變量配置中維護如果是在服務(wù)器上跑Linux的export或systemd的EnvironmentFile都能實現(xiàn)同樣的效果。Redis如果部署在公網(wǎng)一定要設(shè)置密碼不要用默認端口無鑒權(quán)裸奔否則掃描工具會直接連上去刪庫。5. 運行期高頻報錯的排查鏈路從命令行到瀏覽器逐個擊破5.1 “無法將pnpm項識別為cmdlet”不只是環(huán)境變量這條報錯在Windows環(huán)境非常典型但原因不止一個。最常見的情況是pnpm沒經(jīng)過npm全局安裝。安裝命令npm install -g pnpm如果npm -v本身都報錯那是Node.js沒裝好需要去官網(wǎng)重新下載安裝包。如果npm正常但pnpm命令找不到那么執(zhí)行npm config get prefix把看到的路徑一般是C:\Users\你的用戶名\AppData\Roaming\npm加入系統(tǒng)PATH然后完全關(guān)閉并重新打開終端再執(zhí)行pnpm -v。更隱蔽的情況是用PowerShell執(zhí)行pnpm時報同一個錯但CMD里執(zhí)行卻正常。這是因為PowerShell和CMD讀取PATH的時機不同修改系統(tǒng)PATH后PowerShell需要以管理員身份重啟才生效。原理是PowerShell的$env:Path會在會話啟動時緩存一次舊會話里新加的路徑不會自動刷新。解決辦法就是新開終端這個坑不知道坑了多少人。5.2 “運行失敗請查看提示信息”先分清是哪一類問題開發(fā)過程中經(jīng)?？吹健斑\行 core 失敗請查看提示信息”這類模糊報錯。我的排查思路是分層定位先把問題歸到以下幾類報錯類型典型表現(xiàn)排查方向編譯錯誤紅字出現(xiàn)Compilation failure看具體報錯的Class和行號依賴錯誤找不到j(luò)ar包或模塊檢查Maven/Gradle倉庫配置端口沖突Port already in usenetstat查端口并結(jié)束進程配置錯誤Failed to bind properties看是哪個配置項綁定失敗運行時異常NullPointerException等看堆棧第一行的業(yè)務(wù)位置大部分“失敗”提示后面都會跟具體信息關(guān)鍵是訓練自己讀完整日志的能力。Java報錯堆棧從最底下往上讀第一個出現(xiàn)的at com.xxx是你自己代碼的位置上面那些at org.springframework基本都是框架內(nèi)部調(diào)用不用深究。找到自己代碼里的第一行問題基本就在那里。5.3 請求轉(zhuǎn)發(fā)失敗、CORS跨域、Key未配置的高頻問題這三個問題是前后端分離項目里最容易挨個遇到的。CORS跨域的表現(xiàn)是瀏覽器控制臺報Access to XMLHttpRequest at http://localhost:8080/... from origin http://localhost:5173 has been blocked by CORS policy。如果采用Vite代理前端請求都發(fā)到相對路徑就不會觸發(fā)跨域。如果確實需要前端直連后端地址比如后端部署在測試服務(wù)器上最省事的方式是后端加一個CORS配置類Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:5173) .allowedMethods(GET, POST, OPTIONS) .allowedHeaders(*); } }注意allowedOrigins不要寫成*否則在需要攜帶cookie的后續(xù)開發(fā)中會踩坑。Key未配置的報錯通常是401 Unauthorized或者Invalid API Key。我開發(fā)時習慣在啟動時打印一段日志顯示Key的前幾位和長度不打印完整Key方便快速確認環(huán)境變量是否加載成功。這個做法在排查環(huán)境差異時特別有效。5.4 換機器、換平臺后“程序無法運行”的真相熱詞里有一條很典型的報錯“程序claude.exe無法運行: 指定的可執(zhí)行文件不是此操作系統(tǒng)平臺的有效應(yīng)用程序”。這個現(xiàn)象解釋起來很簡單——下載了和當前操作系統(tǒng)不匹配的二進制文件比如在Windows 11上裝了Linux版本的程序或者在64位系統(tǒng)上執(zhí)行了32位程序。解決方式就是去官網(wǎng)重新下載對應(yīng)平臺的安裝包沒有別的捷徑。這類錯誤在AI相關(guān)工具上特別常見因為這些工具的官方下載頁通常同時提供Windows、macOS、Linux多個版本默認展示的可能是當前瀏覽器系統(tǒng)識別的版本但有人為了下載“推薦版”或“最新版”而手動選擇選錯了平臺就會觸發(fā)這條報錯。凡是遇到“不是有效應(yīng)用程序”的說法優(yōu)先檢查系統(tǒng)架構(gòu)x86、x64、ARM和操作系統(tǒng)類型是否正確。6. 從能運行到能交付Agent能力與移動端擴展6.1 什么是Agent開發(fā)讓對話App不只是聊天項目跑通了AI對話不再是“一問一答”的演示下一步就有兩個方向可以走一個是把App做得更像一個Agent另一個是把Web App打包成真正的移動端應(yīng)用。所謂Agent開發(fā)簡單理解就是讓模型不只輸出文本還能調(diào)用工具完成實際操作。比如用戶說“幫我查一下今天的天氣”模型不直接回答而是識別出這是一個查詢需求生成一個工具調(diào)用請求后端收到后調(diào)用天氣API把結(jié)果返回給模型模型再用自然語言把天氣情況表達出來。這個模式目前在行業(yè)里非常流行因為它讓AI從“聊天機器人”變成了“能辦事的助手”。最小實現(xiàn)路徑是給模型定義一組JSON格式的函數(shù)列表模型根據(jù)用戶輸入決定是否調(diào)用某個函數(shù)、參數(shù)是什么。后端在收到函數(shù)調(diào)用請求后真正執(zhí)行函數(shù)把執(zhí)行結(jié)果作為一條新的role: tool消息追加到上下文中再讓模型基于工具結(jié)果生成最終回復。這就是Agent開發(fā)最基礎(chǔ)的協(xié)議鏈路。6.2 移動端方向用Flutter復用同一套后端如果你真的需要把App上架到手機應(yīng)用商店不建議在Web端之外再寫一套邏輯而是用同一個后端前端換成Flutter。熱詞里“如何用Android Studio創(chuàng)建Flutter項目”操作路徑很清晰Android Studio里安裝Flutter插件New Project選擇Flutter填好包名用內(nèi)置模擬器直接跑。也可以用命令行的方式flutter create ai_chat_app創(chuàng)建出的Flutter項目中l(wèi)ib/main.dart是入口用http包或dio包訪問后端接口。由于是獨立App而不是瀏覽器頁面跨域概念不存在但需要注意網(wǎng)絡(luò)安全配置Android 9及以上默認禁止明文HTTP請求Debug環(huán)境需要允許cleartextTraffic才能訪問http://前綴的后端地址。這個坑很隱蔽項目能編譯、能啟動但請求后端一直失敗最后發(fā)現(xiàn)是系統(tǒng)網(wǎng)絡(luò)安全策略禁止了非HTTPS流量。6.3 本地模型部署的另一種選擇如果不想依賴在線API想要完全本地化運行模型可以關(guān)注低顯存運行模型的方案。核心思路是模型量化——把模型的權(quán)重精度從FP16降到INT4或INT8顯存占用能降低百分之七八十同時在推理引擎層面做優(yōu)化。目前比較成熟的方案是配合Ollama這類本地推理工具下載量化版本模型一行命令就能啟動一個兼容OpenAI協(xié)議的本地服務(wù)此時base-url直接指向http://localhost:11434/v1后端代碼完全不用改。本地模型部署需要注意兩點一是模型參數(shù)量要和顯卡顯存匹配比如8GB顯存跑7B量化模型已經(jīng)比較吃力14B以上的模型至少需要16GB二是推理速度受CPU內(nèi)存帶寬影響較大沒有獨顯的機器跑起來會很慢更適合做原型驗證而不是生產(chǎn)環(huán)境。項目從創(chuàng)建到運行的全流程走通之后我再回看這次實操最大的體會是工程上的問題90%都不是“智商的差距”而是“經(jīng)驗的有無”。那些讓人頭疼的報錯本質(zhì)都是環(huán)境變量、依賴版本、端口配置、網(wǎng)絡(luò)策略這幾個固定環(huán)節(jié)的排列組合。把這套排查思路變成肌肉記憶再做任何AI應(yīng)用項目創(chuàng)建和運行這一關(guān)基本不會再攔人了。最后補充一個小技巧每次項目跑通一個階段比如后端啟動成功、前端代理聯(lián)通、SSE流式返回正常都值得把這時的依賴清單、配置文件、啟動命令完整記錄到項目的README里。這樣下次換一臺電腦或者隔幾個月再看這個項目不用靠回憶照著文檔十分鐘就能重新跑起來。這個習慣幫我省下的時間遠比我寫文檔花掉的時間要多得多。