最近有一篇海外評論文章的標題很值得琢磨“Europeans Are About to Find Out How Entrenched AI Is in Their Daily Lives”翻譯過來就是“歐洲人即將發(fā)現(xiàn) AI 在他們的日常生活中已經(jīng)有多根深蒂固”。這篇報道討論的并不是某個新工具突然爆火而是一個更耐人尋味的現(xiàn)象當社會開始系統(tǒng)性地審視 AI 的使用邊界時人們才發(fā)現(xiàn)很多環(huán)節(jié)早就不是傳統(tǒng)規(guī)則代碼在運行了。你刷到的商品推薦、收到的客服回復、遞上去的貸款申請、通過初篩的簡歷背后可能都有模型在參與判斷。這件事對開發(fā)者來說不是一條社會新聞而是一個工程信號AI 正在從“顯式產(chǎn)品”變成所有軟件默認的基礎設施。過去我們討論的是“要不要用 AI”現(xiàn)在要討論的是“AI 已經(jīng)悄悄跑到了哪里我們有沒有能力把它管好”。這篇文章不打算談宏大敘事。我想借一個開源的 AI Agent 模擬項目——my_ai_townAI 小鎮(zhèn)把 AI 滲透日常背后的技術形態(tài)、工程鏈路和驗證方式講清楚。落點是作為開發(fā)者如何從“會調(diào)用模型接口”進階到“能搭建、部署、調(diào)試一個帶 Agent、帶工具調(diào)用、帶日志追蹤的真實 AI 應用”。1. 這篇文章真正要解決的問題先回答一個最直觀的問題普通人真的“不知道” AI 已經(jīng)融入日常嗎其實不是。人們知道 ChatGPT 的存在也知道很多 App 里有智能推薦但這種感知通常是“點狀”的我用的時候知道它是 AI我不用的地方就沒概念。真正的變化發(fā)生在“默認狀態(tài)”。當你打開一個電商平臺首頁推薦是模型排好序的你聯(lián)系在線客服第一層回復大概率是生成式模型或者檢索模型給出的你在一個內(nèi)容平臺發(fā)的稿子先過一遍機審再決定是否進入人工審核池。這些場景不會彈出“本頁面由 AI 提供”的窗口但它們確確實實是 AI 在跑。對開發(fā)者而言這個事實帶來了三個層面的問題正是本文要解決的第一存量系統(tǒng)里已經(jīng)藏了大量 AI 能力但往往沒有統(tǒng)一的接入標準。它們可能是幾個團隊分別接入的、用了不同廠商的模型接口日志格式不統(tǒng)一評估口徑也不一致。這種“技術債”一旦遇到監(jiān)管要求或者線上故障會非常被動。第二新項目從一開始就要按“AI 原生應用”設計而不是先做傳統(tǒng)功能再臨時接模型。所謂 AI 原生不是界面上加一個聊天框而是從數(shù)據(jù)流、權限模型、異常處理到發(fā)布流程都為概率性輸出設計。第三過去“模型跑通就完工”的思路行不通了。AI 應用上線之后還要考慮延遲、成本、幻覺、人工兜底、灰度回滾。這些工程問題比模型本身更決定一個 AI 功能能不能長期活在用戶的日常里。一句話總結AI 的“根深蒂固”不是產(chǎn)品體驗問題而是軟件工程問題。本文從判斷趨勢出發(fā)最終落到一套可以實際操作的工程方法。2. 基礎概念與核心原理大模型、AI Agent 與應用架構在動手之前先把三個高頻概念理清楚大模型、AI Agent、AI 應用。很多討論混亂就是因為這三個詞被混用了。大模型是“能力底座”指的是具備語言理解、生成、推理能力的神經(jīng)網(wǎng)絡模型比如常見的 GPT 系列、Claude、開源 Llama 系列等。它本身不解決問題只是給上層提供能力。你可以把它理解成一個“能力很強的實習生”什么都能說一點但沒見過你的業(yè)務數(shù)據(jù)也不會主動查數(shù)據(jù)庫。AI Agent 是“帶著目標和工具的計劃執(zhí)行者”。它不只回答問題而是把一個任務拆成多步?jīng)Q定調(diào)用哪些工具觀察工具返回結果再決定下一步怎么做。識別一個系統(tǒng)是不是 Agent關鍵看它有沒有“感知-決策-執(zhí)行-反饋”的循環(huán)。一旦模型輸出被接上工具執(zhí)行并且結果會再次進入模型決策這就是一個 Agent 的最簡形態(tài)。AI 應用是“用戶可見的完整產(chǎn)品”。它包含模型、Agent 邏輯、業(yè)務數(shù)據(jù)、權限控制、前端界面、日志監(jiān)控、評估機制。用戶不會直接感知模型和 Agent只感知應用完成得好不好。這三者的關系是AI 應用是大樓Agent 是樓里的業(yè)務流程大模型是底層算力引擎。再看傳統(tǒng)軟件架構與 AI 應用架構的差異。傳統(tǒng)軟件的每個功能都是確定性代碼輸入 1邏輯判斷輸出 1結果可以復算異常有明確代碼路徑。AI 應用則完全不同我用一張表格對比維度傳統(tǒng)軟件AI 應用輸出確定性結果概率性結果同一輸入可能不同輸出異常異常?？梢娪泄潭ㄌ幚砺窂侥Ｐ涂赡懿话醇s定輸出需要解析和糾錯狀態(tài)數(shù)據(jù)庫存儲業(yè)務狀態(tài)Agent 需要額外管理“記憶”否則上下文丟失成本主要是服務器和存儲按 token 計費模型調(diào)用本身是持續(xù)成本監(jiān)控錯誤碼和日志即可定位需要記錄 prompt、模型輸出、工具執(zhí)行鏈路交付驗證單元測試覆蓋業(yè)務邏輯需要評測集 線上指標 人工抽檢組合理解這個表格是后續(xù)排查問題和做工程化的基礎。很多開發(fā)者把 AI 應用當傳統(tǒng)軟件寫結果遇到模型輸出格式變了、調(diào)用超時、幻覺內(nèi)容直接展示給用戶就開始手足無措。其實這些不是 bug而是 AI 應用的默認屬性需要從架構上接受并治理。3. 為什么“AI 小鎮(zhèn)”是一個很好的觀察窗口在講工程實踐之前先介紹一個很適合用來觀察“AI 如何融入日常”的開源項目my_ai_town也叫 AI 小鎮(zhèn)。從項目公開信息看這是一個可以在本地運行的 AI Agent 模擬項目提供了 Mac 和 Windows 版本。它把多個 AI 角色放進一個小鎮(zhèn)環(huán)境中讓它們像真實居民一樣進行日?；顒?、交流互動、執(zhí)行任務。你可以理解為它是一個“縮小版的社會仿真器”里面跑的不是傳統(tǒng) NPC 腳本而是由大模型驅(qū)動的 Agent。這個項目的價值在于它把“AI 嵌入日?！睆囊粋€抽象討論變成了一個可觀察的系統(tǒng)。你打開界面能看到不同的 Agent 在不同時間執(zhí)行不同類型的行為它們之間可能有協(xié)作也可能有沖突同一個任務因為模型上下文不同可能走出完全不同的結果。對開發(fā)者來說AI 小鎮(zhèn)是很好的學習樣本。它至少展示了三個關鍵工程點第一Agent 調(diào)度問題。多個 Agent 同時存在時誰在什么時間觸發(fā)什么行為這是調(diào)度層要解決的問題。現(xiàn)實中的客服系統(tǒng)、風控系統(tǒng)同樣需要決定“什么時候調(diào)用哪個模型”。第二記憶問題。Agent 要完成任務不能只靠用戶說的這一句話還要帶上歷史對話、業(yè)務規(guī)則、環(huán)境狀態(tài)。這些信息怎么組裝進一次模型調(diào)用會直接影響輸出質(zhì)量。第三成本與并發(fā)問題。一個 Agent 跑一天會消耗很多次模型調(diào)用AI 小鎮(zhèn)里的開銷是可感知的。真實系統(tǒng)里這類開銷會直接變成云賬單。當然AI 小鎮(zhèn)是一個研究和學習項目不是生產(chǎn)級系統(tǒng)。它的目標不是處理真實用戶請求也不承擔高并發(fā)訪問它的運行結果也只是“模擬”不能用來推斷真實世界中某個具體事件一定會怎么發(fā)生。把這個邊界劃清楚你再看它的代碼和運行日志才能學到位。4. 環(huán)境準備與部署先把 AI 小鎮(zhèn)跑起來理解了概念接下來動手。這里以 AI 小鎮(zhèn)為例演示一個開源 AI Agent 項目的通用搭建流程。由于項目持續(xù)更新具體依賴版本和啟動命令以項目官方 README 為準下面給的是通用思路。環(huán)境要求通常包括Python 3.10 及以上如果項目提供的是預編譯客戶端可以跳過 Python 環(huán)境Git用于克隆代碼一個可用的大模型 API Key比如 OpenAI 等平臺的密鑰第一步克隆項目代碼。git clone https://github.com/mewamew/my_ai_town.git cd my_ai_town第二步創(chuàng)建獨立的 Python 虛擬環(huán)境。這一步強烈建議不要跳過因為 AI 項目往往依賴大量第三方庫直接裝在全局環(huán)境容易和系統(tǒng)自帶 Python 沖突。python -m venv .venv # macOS / Linux source .venv/bin/activate # Windows PowerShell .venv\Scripts\Activate.ps1虛擬環(huán)境激活后安裝依賴。如果項目根目錄有 requirements.txt 或 pyproject.toml可以用以下方式安裝pip install -r requirements.txt第三步配置模型環(huán)境變量。大多數(shù) AI 項目不會把 API Key 寫死在代碼里而是通過環(huán)境變量或 .env 文件讀取。創(chuàng)建一個 .env 文件寫入類似下面的內(nèi)容# 文件路徑項目根目錄/.env示例 # 實際變量名以項目 README 為準 OPENAI_API_KEYsk-xxx AI_TOWN_PORT3000注意不同項目讀取環(huán)境變量的方式不同有的用 pydantic-settings有的用 python-dotenv變量名很可能不一樣。最穩(wěn)妥的做法是先看 README 里的 Configuration 或 Environment Variables 部分照抄官方變量名。第四步啟動項目。如果項目提供預編譯客戶端可以直接從項目首頁下載對應系統(tǒng)的版本如果是源碼方式啟動命令通常寫在 README 里常見是python main.py啟動成功之后你會在終端看到日志輸出或者在瀏覽器里打開本地地址看到小鎮(zhèn)界面。這里真正容易踩坑的地方是依賴版本沖突和缺失系統(tǒng)庫。如果pip install報錯優(yōu)先看錯誤信息里是哪個包編譯失敗再決定是升級 Python 小版本還是安裝該包的系統(tǒng)依賴。5. 從“能跑”到“能干活”一個最小 AI 應用落地鏈路AI 小鎮(zhèn)跑起來之后你會發(fā)現(xiàn)“觀察 Agent 運行”和“自己寫一個 Agent 應用”之間還有不少距離。這一節(jié)不直接拆 AI 小鎮(zhèn)內(nèi)部代碼而是給出一套通用的 AI Agent 工程骨架包含三層模型調(diào)用層、Agent 工具調(diào)用層、可觀測性層。理解了這套骨架再回去看 AI 小鎮(zhèn)或者任何開源 Agent 項目都會容易很多。5.1 模型調(diào)用層先做一個統(tǒng)一模型客戶端開發(fā) AI 應用的第一步不是喊“接一個 Agent”而是先封裝模型調(diào)用。這樣做的原因是你的應用可能在不同場景調(diào)用不同模型統(tǒng)一封裝后后續(xù)替換模型、增加重試、增加 token 統(tǒng)計都很方便。# 文件路徑src/llm_client.py from openai import OpenAI client OpenAI() def chat( prompt: str, system: str , model: str gpt-4o-mini, temperature: float 0.3, ) - str: messages [] if system: messages.append({role: system, content: system}) messages.append({role: user, content: prompt}) resp client.chat.completions.create( modelmodel, messagesmessages, temperaturetemperature, ) return resp.choices[0].message.content這里有幾個設計點值得注意。system prompt 單獨傳參便于后續(xù)把系統(tǒng)角色和用戶問題分離temperature 默認調(diào)成 0.3對大多數(shù)工程化場景來說輸出穩(wěn)定性比創(chuàng)造性更重要model 參數(shù)允許每個業(yè)務場景指定自己的模型這就是“模型分級”的雛形。實際項目中你還可以在這個封裝里加上超時控制、重試機制、token 計數(shù)和敏感詞過濾。這些統(tǒng)一寫在調(diào)用層比散落在業(yè)務代碼里好維護得多。5.2 Agent 工具調(diào)用層讓模型能“動手”只封裝模型調(diào)用應用還是“會聊天”。要讓 AI 真正進入日常業(yè)務流程必須讓模型能夠調(diào)用工具。下面是一個極簡的 Agent 實現(xiàn)模型輸出一段約定格式代碼解析這段格式執(zhí)行對應工具再把結果交回模型生成最終答案。# 文件路徑src/agent.py import re from llm_client import chat # 工具注冊表名稱 - 函數(shù) TOOLS { calculator: lambda expr: str(eval(expr)), get_weather: lambda city: f{city} 當前天氣晴26℃示例數(shù)據(jù), } SYSTEM_PROMPT 你是一個日常助手。你需要使用工具回答用戶問題。 如果用戶需要計算使用 calculator。 如果用戶詢問天氣使用 get_weather。 工具調(diào)用格式必須嚴格遵循 Action: 工具名 Action Input: 參數(shù) .strip() def run_agent(user_input: str) - str: response chat( user_input, systemSYSTEM_PROMPT, ) # 解析模型輸出中的工具調(diào)用 action_match re.search(rAction:\s*(.), response) input_match re.search(rAction Input:\s*(.), response) if action_match and input_match: tool_name action_match.group(1).strip() tool_arg input_match.group(1).strip() if tool_name in TOOLS: tool_result TOOLS[tool_name](tool_arg) final_prompt ( f用戶的問題是{user_input}\n f工具返回的結果是{tool_result}\n 請把這個結果整理成一句自然的中文回答。 ) return chat(final_prompt) return response if __name__ __main__: print(run_agent(幫我計算 23*45 等于多少))這個例子把 Agent 的核心循環(huán)展示得很直接生成、解析、執(zhí)行、再生成。這個循環(huán)看起來簡單但實際項目里有很多坑。模型可能不按約定輸出“Action: 工具名”可能漏掉參數(shù)可能調(diào)用了不存在的工具也可能直接編造結果而不是調(diào)用工具。這些都需要在生產(chǎn)級代碼里做約束和糾錯。這里特別要提醒一點示例里的eval只用于本地演示。真實生產(chǎn)環(huán)境絕不能直接用 eval 執(zhí)行模型生成的表達式這等于把任意代碼執(zhí)行權限交給一個概率系統(tǒng)非常危險。要用計算功能可以改用 Python 的ast.literal_eval配合安全運算或者干脆用專門的計算庫。5.3 可觀測性層給每次調(diào)用做追蹤AI 應用最容易出現(xiàn)的問題就是“結果不對但不知道是哪一步不對”。是模型理解錯了工具執(zhí)行壞了還是最終生成時格式錯了要回答這個問題必須給 Agent 的每一步調(diào)用打日志。# 文件路徑src/trace_logger.py import json import time from functools import wraps def trace_step(step_name: str): def decorator(func): wraps(func) def wrapper(*args, **kwargs): start time.time() log { step: step_name, args: str(args)[:500], status: success, } try: result func(*args, **kwargs) log[result] str(result)[:500] except Exception as e: log[status] error log[error] str(e) raise finally: log[cost_ms] round((time.time() - start) * 1000, 2) print(json.dumps(log, ensure_asciiFalse)) return result return wrapper return decorator生產(chǎn)系統(tǒng)里print(json.dumps(...))會替換成發(fā)送到統(tǒng)一日志平臺方便按 requestId 聚合鏈路。但核心思路是一樣的記錄發(fā)生在哪一步、輸入是什么、輸出是什么、耗時多少、是否報錯。你可以在 5.2 的run_agent函數(shù)上直接加裝飾器# src/agent.py 后半部分 from trace_logger import trace_step trace_step(agent.run_agent) def run_agent_with_trace(user_input: str) - str: return run_agent(user_input) if __name__ __main__: print(run_agent_with_trace(幫我計算 23*45 等于多少))運行后終端會先輸出一行結構化日志再輸出最終的回答。這個日志就是后續(xù)排查問題、分析成本、評估質(zhì)量的第一手數(shù)據(jù)。6. 運行結果與效果驗證不能只跑通還要證明“可用”很多開發(fā)者在 AI 項目上的驗收標準是“能啟動界面不報錯”這對傳統(tǒng)軟件勉強夠用對 AI 應用遠遠不夠。AI 應用是概率系統(tǒng)同樣的功能這次好用下次可能就不好用。所以驗證必須分層進行。先看 AI 小鎮(zhèn)這類項目的驗收。啟動成功后應該關注以下幾點終端日志是否持續(xù)出現(xiàn) Agent 行為記錄而不是只輸出一條啟動信息后卡住。小鎮(zhèn)內(nèi)的 Agent 是否能隨機或按計劃產(chǎn)生動作是否在多個角色之間產(chǎn)生交互。API Key 配置是否有效如果 Key 無效啟動階段可能不出錯但一旦 Agent 開始調(diào)用模型就會報 401。再看我們上一節(jié)的 Agent 示例。運行python src/agent.py預期會看到類似下面的輸出{step: agent.run_agent, args: (幫我計算 23*45 等于多少,), status: success, cost_ms: 312.45} 最終回答23 × 45 1035。日志說明 Agent 鏈路被調(diào)用并成功返回。如果最終回答的數(shù)值不對但日志顯示工具已經(jīng)執(zhí)行了那問題可能出在最終生成階段而不是工具階段如果日志里根本沒有工具執(zhí)行記錄則說明模型沒有按格式調(diào)用工具。對于生產(chǎn)級 AI 應用驗證維度更復雜可以用下面這張表做參考驗證維度關注問題常用手段功能正確性模型輸出是否符合業(yè)務要求離線評測集、專家抽檢工具調(diào)用準確性Agent 是否選對工具、傳對參數(shù)日志回放、工具調(diào)用埋點幻覺控制輸出是否包含沒有依據(jù)的內(nèi)容人工抽檢、引用溯源、風險詞過濾延遲用戶等待時間是否可接受每次調(diào)用耗時統(tǒng)計成本單次請求模型費用是否超預算token 計數(shù)、按業(yè)務線分攤兜底能力模型失敗時是否有降級方案異常鏈路測試、故障注入如果驗證發(fā)現(xiàn)結果不對第一步不是調(diào) prompt而是先分清問題發(fā)生在哪一層模型層、Agent 邏輯層、工具層還是數(shù)據(jù)層。日志在這里就是最重要的線索。7. 常見問題與排查思路AI 應用開發(fā)中下面這些問題出現(xiàn)頻率最高。我把它們整理成一張排查表方便你遇到問題時照著查。問題現(xiàn)象可能原因排查方式解決方案模型 API 返回 401/403API Key 無效、額度不足或沒有模型訪問權限查看調(diào)用層錯誤信息檢查環(huán)境變量是否加載確認 Key 正確檢查賬戶權限和額度項目啟動時報依賴沖突Python 版本不匹配、某個包版本過新或過舊查看 pip install 錯誤棧運行 pip check按 README 指定 Python 版本必要時用 requirements.txt 固定版本Agent 沒有調(diào)用工具prompt 未明確工具格式或模型輸出格式不匹配解析邏輯打印模型原始輸出對比正則是否匹配調(diào)整 system prompt增強格式示例必要時使用結構化輸出模型輸出了編造內(nèi)容模型幻覺、上下文信息不足或 prompt 引導不夠檢查輸入信息是否完整對關鍵引用做校驗強制要求“不知道就說不知道”高風險場景加入人工審核響應延遲明顯偏高模型過大、prompt 太長、頻繁重試查看日志中的 cost_ms 和 token 數(shù)改用小模型、壓縮 prompt、增加緩存、設置合理超時用戶隱私數(shù)據(jù)出現(xiàn)在日志或 prompt日志記錄了完整入?yún)⒒蛘{(diào)用了不該訪問的數(shù)據(jù)源檢查 logging 配置和 Agent 工具權限日志字段脫敏工具層限制數(shù)據(jù)訪問范圍多 Agent 并發(fā)時報狀態(tài)不一致共享變量、數(shù)據(jù)庫并發(fā)控制缺失查看并發(fā)日志檢查寫入邏輯引入鎖、事務或按 Agent 隔離存儲成本增長超出預期單次請求 token 過多、失敗后無謂重試統(tǒng)計 token 消耗和重試次數(shù)設置 token 上限、限制重試次數(shù)、模型分層路由這八個問題覆蓋了從環(huán)境到運行、從質(zhì)量到成本的主要故障點。遇到問題不要急著改 prompt先按表里的“排查方式”定位問題層次再改對應環(huán)節(jié)。8. AI 工程化最佳實踐讓 AI 真正“隱形”又“可靠”AI 要真正融入日常最終形態(tài)應該是“隱形的”用戶不用關心背后有沒有模型系統(tǒng)卻能穩(wěn)定地提供服務。要做到這一點靠的不是模型選得有多新而是工程細節(jié)有沒有做好。下面這六條是我認為最值得在開發(fā)前就確定下來的工程約束。第一模型分級設計。不要所有請求都用同一個最強模型。簡單分類任務用輕量模型復雜推理和生成用強模型既能控成本又能降延遲。在封裝層把 model 作為參數(shù)傳入就是為這個做準備。第二最小權限原則。Agent 能訪問哪些數(shù)據(jù)、能調(diào)用哪些工具必須按業(yè)務需要最小化配置。給 Agent 一個萬能數(shù)據(jù)庫查詢權限看起來方便實際等于把一個概率系統(tǒng)接入了你的核心數(shù)據(jù)風險極高。每次工具調(diào)用前都應檢查授權。第三數(shù)據(jù)安全與脫敏。用戶手機號、身份證號、地址等敏感信息不應進入 prompt更不應寫進日志。這個要求要和日志框架同時設計而不是等上線后再補。日志里該打碼的打碼該截斷的截斷。第四全鏈路可觀測性。每次模型調(diào)用、工具執(zhí)行、token 消耗、耗時、錯誤狀態(tài)都要留痕。生產(chǎn)環(huán)境建議用統(tǒng)一日志平臺按 requestId 串聯(lián)整條 Agent 鏈路。沒有可觀測性AI 應用就像蒙著眼開車。第五灰度與回滾。prompt 和模型的改動也應該像代碼一樣走發(fā)布流程。新版 prompt 先切小流量觀察關鍵指標后再放量發(fā)現(xiàn)問題能一鍵切回舊版本。模型能力變化是動態(tài)的不能默認“今天調(diào)好了就永遠調(diào)好”。第六人工兜底與安全邊界。高風險場景金融、醫(yī)療、法律等必須有人工審核環(huán)節(jié)。生產(chǎn)代碼里絕對不能用 eval 執(zhí)行模型生成的代碼外部工具調(diào)用要加白名單、限流和審計。AI 可以提高效率但不要把最終決策權完全交給概率輸出。這六條不是額外負擔而是 AI 應用能從 demo 走向生產(chǎn)的基本條件。你可以在 AI 小鎮(zhèn)上練習前四條至少在項目里把日志和工具隔離做好后兩條則需要在正式項目里逐步建立。9. 結論與后續(xù)學習方向“歐洲人即將發(fā)現(xiàn) AI 已經(jīng)融入日?！边@件事?lián)Q個角度看其實是所有開發(fā)者的提醒AI 不再是獨立的實驗項目而是軟件系統(tǒng)的默認組成部分。誰先學會把模型做成穩(wěn)定、可觀測、可控制的工程系統(tǒng)誰就在接下來的開發(fā)中占先。這篇文章從 AI 滲透的技術表現(xiàn)講起說到大模型、AI Agent、AI 應用三者的區(qū)別用 AI 小鎮(zhèn)作為觀察樣本最后給出了一套從模型封裝到工具調(diào)用、再到日志追蹤的最小工程骨架。核心想法很簡單模型只是能力Agent 只是流程日志、評估、權限、兜底才是讓 AI 應用長期可用的關鍵。如果你想接著深入建議按三條線走一是把 AI 小鎮(zhèn)跑起來認真看 Agent 的運行日志理解調(diào)度和記憶是怎么組織的二是基于本文的最小 Agent 代碼自己動手加上一個真實工具比如查數(shù)據(jù)庫或調(diào)內(nèi)部接口感受工具調(diào)用的完整鏈路三是建立一套最簡單的評測集用幾十條典型問題跑一遍記錄每次輸出開始用數(shù)據(jù)而不是感覺來改進 AI 應用。AI 滲透日常的趨勢不會停下來隨之而來的工程化需求只會越來越大。希望這篇文章能成為你從“調(diào)用模型”走向“構建可靠 AI 應用”的一步。