[AI 轉型] Java後端轉AI Agent，先搞懂系統本質差異

 [AI 轉型] Java後端轉AI Agent，先搞懂系統本質差異

摘要 : Agent不是聊天介面，而是半確定性的任務執行系統，後端轉型先理解邊界與架構。

內容:

如果你是 Java 後端工程師，最近想轉向 AI Agent，很可能會有一種感受：學了不少東西，像是 Spring AI、LangChain、向量檢索、LangGraph、RAG、Prompt Engineering，但回頭一看，距離真正做出一個可上線的 Agent 還是很遠。

問題往往不在於學得不夠多，而是起點選錯了。很多人一開始就急著學框架、寫 Prompt、搭工作流，但這些解決的其實只是「怎麼做」。真正更重要的，是先想清楚「你要做的東西，本質上和傳統後端系統有什麼不同」。

過去做後端，本質上是在構建一個確定性系統。請求進來之後，參數是什麼、進哪個 Controller、調哪個 Service、回什麼結果，大多數都已經預先定義好。輸入明確、流程明確、輸出明確，這就是傳統後端最熟悉、也最穩定的模式。

但 Agent 面對的通常不是標準化請求，而是一個模糊任務。使用者可能說：「幫我整理一下這批客戶反饋」、「幫我分析最近業績為什麼下滑」、「幫我找出報表中的異常」。這不是傳統 API 參數，而是把一個任務交給系統去完成。

因此，Agent 更像是一個任務執行系統。它要先理解目標，再判斷需要什麼資訊、是否要查資料、是否要呼叫工具、是否要拆步驟執行，最後再組織結果輸出。與傳統後端最大的差異在於：以前流程主要由程式碼寫死，現在流程中有一部分要由模型依據上下文動態判斷。

到了 Agent 場景，傳統後端的三個確定性都被打破了。第一，輸入不再確定，因為使用者講的是自然語言，常常不完整、也不精確。第二，流程不再完全確定，系統可能要檢索、呼叫工具、追問、重試，甚至依據中間結果改變執行路徑。第三，輸出也不再完全穩定，因為模型生成內容每次都可能有細微差異。

這也是 Agent 最核心的一個概念：半確定性系統。所謂半確定性，不是放任系統不受控，而是把一部分交給模型負責理解與生成，把另一部分交給工程系統負責約束與兜底。模型負責靈活，工程負責穩定；模型可以有變化，但系統不能失控。

所以，後端工程師在 AI 時代的價值，絕對不只是會呼叫模型 API，而是能把大模型這種天然不穩定的能力，接到穩定的業務系統中。像是權限控制、工具調用、失敗重試、日誌追蹤、結果評估，這些都不是模型自動幫你處理的，而是標準的工程問題。

很多人以為 AI 應用就是做一個聊天框，後端呼叫一次模型 API，再把答案回傳給前端。這頂多只能算是最小 Demo。真正要上線時，你會面對的是：使用者是誰、能看哪些資料、能用哪些工具、執行過程能不能審計、結果出錯能不能追溯、模型或版本升級後效果有沒有下降。當這些問題出現，Agent 其實就重新回到了後端工程師最熟悉的戰場。

如果把 Agent 抽象化來看，通常離不開四個核心要素。

第一是目標，也就是使用者到底想完成什麼任務。  

第二是上下文，也就是系統能拿到哪些業務資訊、歷史資料與知識。  

第三是工具，也就是系統可調用的 API、資料庫、搜尋與計算能力。  

第四是約束，包括權限、風控、成本、審計與評估，哪些事情絕對不能失控。

有了這個結構之後，再看各種 Agent 場景就會清楚很多。客服 Agent 是圍繞客戶問題調用知識庫和工單系統；辦公 Agent 是圍繞文件、日程、郵件做任務編排；研發 Agent 則是圍繞程式碼、測試、部署做工具調用。本質都一樣：理解目標、取得上下文、調用工具，並守住業務邊界。

如果是後端工程師想練習這套能力，一個很適合的真實場景是「智慧問數」，也可以理解為經營數據分析 Agent。因為老闆、營運、財務、銷售主管，幾乎每天都在問資料：收入為什麼漲了？利潤為什麼掉了？哪個區域異常？現金流壓力來自哪裡？

例如，當使用者問「上個月經營利潤為什麼下滑？」這句話背後絕對不是單純生成一條 SQL 就能解決的事。系統需要先理解利潤的計算口徑，再分析收入、成本、費用的變化，還要依照區域、產品、客戶類型去拆解，找出真正的異常來源。最後輸出的，也不應只是一張查詢表，而應該包含結果表、趨勢圖、關鍵原因，以及可追溯的分析過程。

這也說明了一件事：企業級智慧問數，不等於 Text-to-SQL。網路上很多 Demo 看起來很酷，像是使用者提問後，模型直接產出 SQL 並執行。但在企業裡這其實很危險，因為真實資料環境裡會有指標口徑、欄位歧義、權限邊界、查詢成本與結果解釋等問題。只會生成 SQL，根本不足以支撐企業級需求。

真正的企業級問數 Agent，要做的是把自然語言問題，轉化成一個受控的資料分析任務。模型可以負責理解問題、拆解思路、生成候選查詢；但指標口徑、權限校驗、SQL 安全、執行限制、審計日誌、結果評估，都必須由工程系統來兜底。這就是所謂的「上層靈活、下層穩定」。

為了更容易理解，可以把這個場景拆成三層。

第一層是模型判斷層，負責理解使用者問題、判斷意圖、拆解分析步驟，並生成候選查詢與說明。  

第二層是任務編排層，負責檢索指標口徑、選擇資料來源、判斷是否需要追問，並組織查詢、校驗、執行與彙總。  

第三層是業務治理層，負責指標定義、行列權限、SQL 安全、查詢超時、審計日誌，以及效果回歸與評估。

這個場景特別適合後端工程師入門 Agent，因為它不是單純聊天，也不是炫技 Demo。它同時包含模型理解、工具調用、業務口徑、權限安全、結果輸出、可追溯與可評估等完整問題，而且經營分析、財務分析、銷售分析，也確實是企業願意買單的真實需求。

所以這篇內容真正想強調的，不是哪個框架最好，而是先建立一個正確判斷：Agent 不是普通介面，而是半確定性的任務執行系統。後端工程師要學的，也不是放棄原本的工程能力，而是把資料庫、權限、任務、日誌、穩定性這些老本行，接到大模型時代的新系統裡。

在真正開始選框架、選技術棧之前，應該先把系統邊界與架構想清楚。只有先理解使用者是誰、輸入是什麼、輸出是什麼、邊界在哪裡，才不會一開始就把方向走偏。