這兩年AI 相關(guān)的討論已經(jīng)從“能不能取代程序員”變成了“AI Agent 什么時(shí)候接管整個(gè)研發(fā)流程”。很多團(tuán)隊(duì)真的開(kāi)始把代碼審查、任務(wù)拆解甚至一部分發(fā)布決策交給大模型來(lái)完成。但我觀察到一個(gè)更真實(shí)的趨勢(shì)越是深入工程落地越會(huì)發(fā)現(xiàn)當(dāng)前的 AI 系統(tǒng)并沒(méi)有宣傳中那么稱職。它們不是無(wú)所不能的“AI 霸主”更像一個(gè)知識(shí)面很廣、響應(yīng)速度極快、但經(jīng)常把細(xì)節(jié)搞錯(cuò)的初級(jí)協(xié)作者。它可以在你寫(xiě)代碼時(shí)給出高質(zhì)量的補(bǔ)全卻會(huì)在你要求它維護(hù)一個(gè)復(fù)雜狀態(tài)機(jī)時(shí)悄悄丟掉一個(gè)關(guān)鍵分支它可以流暢地解釋分布式事務(wù)卻可能在同一個(gè)上下文里兩次說(shuō)出互相矛盾的結(jié)論。這個(gè)反差值得每個(gè)技術(shù)人認(rèn)真對(duì)待。本文會(huì)從大模型的能力邊界、Agent 的執(zhí)行穩(wěn)定性、AI 編程助手的工程表現(xiàn)三個(gè)角度拆解“AI 沒(méi)那么全能”背后的技術(shù)原因并給出一套可以在項(xiàng)目中落地的可靠性方案。讀完你會(huì)清楚當(dāng)前階段應(yīng)該把 AI 放在流程的哪個(gè)位置哪些環(huán)節(jié)必須保留人工校驗(yàn)以及如何用代碼層面的校驗(yàn)、降級(jí)、日志等手段把一個(gè)“能力不錯(cuò)但不太可靠”的 AI 系統(tǒng)安全地接入生產(chǎn)鏈路。1. 先拋結(jié)論為什么 AI 還不能當(dāng)“統(tǒng)治者”很多人在評(píng)估 AI 時(shí)容易把“內(nèi)容生成能力”等同于“通用判斷能力”。這是當(dāng)前最大的誤解。大模型最擅長(zhǎng)的是文本生成、代碼補(bǔ)全、信息歸納、自然語(yǔ)言交互它并不擅長(zhǎng)精確約束、長(zhǎng)鏈路狀態(tài)管理、可靠推理和實(shí)時(shí)事實(shí)校驗(yàn)。把后者當(dāng)成前者的自然延伸是很多 AI 項(xiàng)目翻車的根源。從實(shí)際工程現(xiàn)象看問(wèn)題集中在三類生成類任務(wù)表現(xiàn)驚艷。寫(xiě)周報(bào)、寫(xiě)營(yíng)銷文案、做 PPT 大綱、生成單元測(cè)試這些任務(wù)容錯(cuò)率高輸出不需要嚴(yán)格符合外部狀態(tài)AI 的表現(xiàn)遠(yuǎn)超預(yù)期。約束類任務(wù)表現(xiàn)不穩(wěn)定。比如“訂單金額必須精確到分”“狀態(tài)機(jī)不允許從 A 直接跳到 C”“刪除操作必須附帶審批記錄”這類任務(wù)要求輸出滿足強(qiáng)約束而大模型沒(méi)有內(nèi)置約束求解機(jī)制經(jīng)常生成“看起來(lái)合理”但不符合規(guī)則的答案。長(zhǎng)鏈路任務(wù)容易累積錯(cuò)誤。單個(gè)步驟的出錯(cuò)概率如果是 1%一個(gè) 20 步的 Agent 流程理想情況下整體成功率只剩 82% 左右。如果單步出錯(cuò)概率是 5%20 步之后成功率不到 36%。這就是為什么 Agent 在演示視頻里很流暢落地時(shí)卻頻繁中途卡死或跑偏。所以我的核心判斷是AI 的真正價(jià)值在于“快速生成高質(zhì)量草稿”而不是“直接做出最終決策”。把它當(dāng)統(tǒng)治者你會(huì)不斷遇到失控把它當(dāng)執(zhí)行者你會(huì)得到一個(gè)效率極高的助手。后面所有章節(jié)都是在解釋這個(gè)判斷背后的技術(shù)原因以及怎么把“受監(jiān)管的執(zhí)行者”落到代碼里。2. 大模型的能力邊界幻覺(jué)、上下文與不穩(wěn)定推理這一節(jié)講清楚三個(gè)核心概念它們是理解“AI 為什么不稱職”的基礎(chǔ)。2.1 AI 幻覺(jué)模型在“編”不是在“查”AI 幻覺(jué)是指模型生成了看似合理、實(shí)則錯(cuò)誤的內(nèi)容。工程中常見(jiàn)的表現(xiàn)有編造不存在的函數(shù)名、虛構(gòu)第三方庫(kù)的版本、給出錯(cuò)誤的 API 參數(shù)、把 A 框架的用法安到 B 框架身上。產(chǎn)生幻覺(jué)的根本原因是大模型本質(zhì)上是一個(gè)“根據(jù)上下文預(yù)測(cè)下一個(gè) Token”的概率模型而不是一個(gè)“查詢數(shù)據(jù)庫(kù)再返回結(jié)果”的確定性系統(tǒng)。它沒(méi)有內(nèi)建的事實(shí)校驗(yàn)機(jī)制所有輸出都來(lái)自訓(xùn)練數(shù)據(jù)中學(xué)到的模式。當(dāng)訓(xùn)練數(shù)據(jù)里沒(méi)有正確答案或者問(wèn)題超出了知識(shí)覆蓋范圍時(shí)它就會(huì)用最“像真話”的方式補(bǔ)全。這帶來(lái)的工程啟示非常明確凡是模型輸出會(huì)被后續(xù)程序當(dāng)作事實(shí)依據(jù)的環(huán)節(jié)都必須增加獨(dú)立的校驗(yàn)層。比如讓它生成一段 SQL你要先確認(rèn)表名和字段真實(shí)存在讓它調(diào)用一個(gè)函數(shù)你要先檢查函數(shù)名在白名單里讓它返回一個(gè) JSON你要先用 Schema 校驗(yàn)。2.2 上下文窗口不是越大越可靠現(xiàn)在的模型動(dòng)不動(dòng)就支持 128K、1M Token 的上下文很多人誤以為“模型記得住我所有的要求”。實(shí)際上長(zhǎng)上下文的有效注意力是衰減的。大量實(shí)驗(yàn)和工程反饋都表明關(guān)鍵信息放在上下文開(kāi)頭和結(jié)尾通常比埋在中間更容易被模型正確利用當(dāng)對(duì)話輪次變多、中間夾雜大量代碼片段時(shí)模型經(jīng)常會(huì)遺忘最早期的約束條件。工程中的典型場(chǎng)景是開(kāi)發(fā)者在對(duì)話第一輪說(shuō)“這個(gè)接口必須做冪等重復(fù)請(qǐng)求不能重復(fù)扣款”到第十輪要求改功能時(shí)模型已經(jīng)開(kāi)始生成不包含冪等判斷的代碼。這不是模型“故意的”而是長(zhǎng)上下文里關(guān)鍵約束被稀釋了。應(yīng)對(duì)方式有兩個(gè)方向一是把不可妥協(xié)的硬性約束放進(jìn) System Prompt并且每次請(qǐng)求都重新發(fā)送二是做上下文壓縮把已經(jīng)討論過(guò)的內(nèi)容提煉成結(jié)構(gòu)化摘要而不是把全部歷史都塞進(jìn)模型。2.3 推理不穩(wěn)定同一道題換個(gè)問(wèn)法答案就變傳統(tǒng)軟件的最大優(yōu)勢(shì)是確定性同一個(gè)輸入程序幾乎總是給出同一個(gè)輸出。大模型沒(méi)有這個(gè)性質(zhì)。溫度調(diào)成 0 只能降低隨機(jī)性不能消除不穩(wěn)定性同一個(gè) Prompt 多次調(diào)用結(jié)果仍然會(huì)有差異。更麻煩的是復(fù)雜推理任務(wù)對(duì)措辭高度敏感換個(gè)說(shuō)法可能就從“正確結(jié)論”變成“錯(cuò)誤結(jié)論”。這意味著凡是需要嚴(yán)格邏輯推導(dǎo)的環(huán)節(jié)都不能完全依賴模型的一次輸出。正確的實(shí)踐是讓模型給出思路然后用程序去驗(yàn)證結(jié)果或者用多次采樣 投票的方式提高穩(wěn)定性而不是盲目相信單次輸出。對(duì)比一下傳統(tǒng)代碼和模型輸出的本質(zhì)差異維度傳統(tǒng)代碼大模型輸出確定性高同輸入同輸出低存在隨機(jī)性事實(shí)校驗(yàn)邏輯由開(kāi)發(fā)者控制無(wú)內(nèi)建校驗(yàn)靠訓(xùn)練模式可調(diào)試性逐步斷點(diǎn)定位難復(fù)現(xiàn)需記錄完整上下文強(qiáng)約束支持語(yǔ)言與框架保證需要外部校驗(yàn)層3. Agent 為什么容易中途“失控”如果說(shuō)大模型是“不太可靠的生成器”那 Agent 就是“把不可靠生成器循環(huán)調(diào)用多次”的執(zhí)行框架。Agent 由大模型驅(qū)動(dòng)自主規(guī)劃任務(wù)步驟并調(diào)用外部工具完成目標(biāo)。聽(tīng)起來(lái)很美但工程落地時(shí)經(jīng)常暴露出幾個(gè)典型問(wèn)題。第一個(gè)問(wèn)題是任務(wù)拆解漂移。模型在最開(kāi)始給出的計(jì)劃是合理的但隨著執(zhí)行推進(jìn)它會(huì)基于前一步的結(jié)果繼續(xù)推理。一旦某一步生成了錯(cuò)誤結(jié)論后面所有步驟都會(huì)基于這個(gè)錯(cuò)誤繼續(xù)運(yùn)行而且模型往往不會(huì)主動(dòng)回頭糾正因?yàn)樗诙躺舷挛睦镆呀?jīng)“忘記”最初的完整目標(biāo)了。第二個(gè)問(wèn)題是工具調(diào)用不穩(wěn)定。Agent 的價(jià)值在于能調(diào)用 API、執(zhí)行命令、操作數(shù)據(jù)庫(kù)。但模型生成工具參數(shù)時(shí)經(jīng)常出現(xiàn)字段名拼錯(cuò)、類型不對(duì)、缺少必填項(xiàng)等問(wèn)題。更危險(xiǎn)的是它可能在工具執(zhí)行失敗后反復(fù)重試同一個(gè)錯(cuò)誤參數(shù)造成重復(fù)調(diào)用。如果這個(gè)工具是“發(fā)送短信”“扣減庫(kù)存”“推送發(fā)布”重復(fù)調(diào)用就是生產(chǎn)事故。第三個(gè)問(wèn)題是循環(huán)和死胡同。模型有時(shí)會(huì)陷入“執(zhí)行工具 - 發(fā)現(xiàn)失敗 - 換個(gè)說(shuō)法再執(zhí)行”的循環(huán)直到耗盡 Token 或達(dá)到步數(shù)上限。沒(méi)有設(shè)置 step limit 的 Agent在無(wú)人值守時(shí)可能連續(xù)運(yùn)行數(shù)小時(shí)消耗大量費(fèi)用卻什么問(wèn)題都沒(méi)解決。Agent 和普通代碼的差異在于普通代碼的流程是開(kāi)發(fā)者寫(xiě)死的每一步都是確定的Agent 的流程是模型實(shí)時(shí)生成的每一步都有出錯(cuò)概率而且錯(cuò)誤會(huì)隨步數(shù)累積。這就是為什么 Agent 只適合“可驗(yàn)證、可回滾、低風(fēng)險(xiǎn)”的任務(wù)。工程上的應(yīng)對(duì)手段包括用狀態(tài)機(jī)限制 Agent 的可達(dá)狀態(tài)而不是讓它自由發(fā)揮用工具白名單限制它能調(diào)用的能力設(shè)置最大步數(shù)和超時(shí)時(shí)間給敏感操作增加人工審批點(diǎn)把 Agent 放入沙箱環(huán)境讓它只擁有最小權(quán)限。4. AI 編程助手在真實(shí)項(xiàng)目中的表現(xiàn)與坑AI 編程是普通開(kāi)發(fā)者接觸最多的一類 AI 工具也是“看起來(lái)很強(qiáng)、落地時(shí)問(wèn)題最多”的領(lǐng)域。像 Cursor、GitHub Copilot、JetBrains AI Assistant以及各種基于大模型的代碼插件確實(shí)能顯著提升編碼效率但它們并不能保證代碼質(zhì)量。從真實(shí)工程反饋來(lái)看編程助手擅長(zhǎng)的事情是生成樣板代碼、寫(xiě)單元測(cè)試、解釋陌生代碼、完成單文件內(nèi)的補(bǔ)全。它不擅長(zhǎng)的事情也很明顯跨文件依賴?yán)斫獠蛔恪４笮晚?xiàng)目里改動(dòng)一個(gè)函數(shù)會(huì)影響到調(diào)用它的十幾個(gè)模塊。AI 編程工具通常只分析局部上下文給出的“重構(gòu)方案”可能破壞了其他模塊的調(diào)用契約。對(duì)私有 API 和內(nèi)部框架理解不夠。它從公開(kāi)代碼里學(xué)到的模式不一定適配你們團(tuán)隊(duì)的內(nèi)部框架。當(dāng)你要求它生成一段基于內(nèi)部組件庫(kù)的代碼時(shí)它很可能生成一個(gè)“根本不存在”的組件名。會(huì)編造依賴版本。讓它寫(xiě)一段“使用 XX 框架最新版”的代碼它可能給出一個(gè)不存在的版本號(hào)或已經(jīng)廢棄的 API。這在導(dǎo)入依賴時(shí)很容易暴露。單測(cè)通過(guò)不代表集成通過(guò)。AI 生成的單元測(cè)試往往會(huì)順著實(shí)現(xiàn)寫(xiě)測(cè)試的是“代碼現(xiàn)在做的事”而不是“代碼應(yīng)該做的事”。重構(gòu)場(chǎng)景下這種測(cè)試的守護(hù)價(jià)值很低。更值得警惕的是安全性。模型生成的代碼經(jīng)常出現(xiàn)把密鑰寫(xiě)進(jìn)配置、日志打印敏感字段、對(duì)用戶輸入缺少校驗(yàn)、使用存在已知漏洞的舊函數(shù)。這些代碼看起來(lái)邏輯完整但在生產(chǎn)環(huán)境中就是事故隱患。所以我的建議是AI 編程助手適合承擔(dān)“產(chǎn)出初稿”的角色不適合承擔(dān)“代碼把關(guān)”的角色。團(tuán)隊(duì)在代碼評(píng)審時(shí)要把 AI 生成的代碼和人類代碼同等對(duì)待甚至更應(yīng)該關(guān)注 AI 生成部分。重點(diǎn)檢查權(quán)限校驗(yàn)、金額精度、時(shí)區(qū)處理、路徑拼接、依賴版本、異常處理這幾個(gè)高風(fēng)險(xiǎn)點(diǎn)。5. AI 工程化的第一步把模型輸出當(dāng)作不可信輸入聊完問(wèn)題接下來(lái)進(jìn)入可落地的部分。AI 工程化和傳統(tǒng)后端開(kāi)發(fā)最大的區(qū)別是傳統(tǒng)后端把用戶輸入當(dāng)不可信輸入做各種校驗(yàn)AI 工程化必須再增加一層——把大模型的輸出也當(dāng)作不可信輸入。很多團(tuán)隊(duì)接大模型 API 時(shí)只做了最基本的事情把 Prompt 發(fā)出去拿到字符串直接解析使用。結(jié)果模型一旦返回非預(yù)期格式程序崩潰或者更糟——返回了一個(gè)格式正確但內(nèi)容危險(xiǎn)的指令被程序直接執(zhí)行。一個(gè)可靠的大模型接入鏈路至少應(yīng)該包含四層校驗(yàn)校驗(yàn)層級(jí)校驗(yàn)內(nèi)容典型手段格式校驗(yàn)JSON 是否能解析、字段是否完整JSON Schema、Pydantic語(yǔ)義校驗(yàn)枚舉值、范圍、白名單代碼判斷、正則、枚舉表業(yè)務(wù)校驗(yàn)金額、權(quán)限、狀態(tài)遷移是否合法業(yè)務(wù)規(guī)則引擎、查庫(kù)確認(rèn)安全校驗(yàn)是否包含惡意指令、越權(quán)工具調(diào)用工具白名單、參數(shù)過(guò)濾、審批流這樣做的核心邏輯是把大模型當(dāng)成一個(gè)“外部服務(wù)”這個(gè)服務(wù)可能返回任何內(nèi)容。程序要能處理“輸出不合法”的情況而不是假設(shè)它一定正確。6. 完整示例本地部署大模型并加上校驗(yàn)與降級(jí)這一節(jié)用一個(gè)最小示例把上面的思路落地為代碼。示例選用本地部署的 Ollama 服務(wù)因?yàn)樗诒镜剡\(yùn)行不涉及云端 API 費(fèi)用和網(wǎng)絡(luò)問(wèn)題適合用來(lái)理解完整鏈路。生產(chǎn)環(huán)境換成 OpenAI、通義千問(wèn)、文心一言等云端 SDK思路完全一致。6.1 環(huán)境準(zhǔn)備建議環(huán)境如下Python 3.9 及以上版本。已安裝 Ollama并拉取一個(gè)可用模型。Python 依賴requests、jsonschema。安裝 Ollama 的命令以官方文檔為準(zhǔn)常規(guī) Linux 環(huán)境可以使用官方安裝腳本。安裝完成后拉取一個(gè)適合本地運(yùn)行的模型ollama pull qwen2.5:7b模型名稱請(qǐng)以實(shí)際拉取到的版本為準(zhǔn)不同硬件的顯存容量會(huì)影響可選模型大小。接下來(lái)安裝 Python 依賴pip install requests jsonschema啟動(dòng) Ollama 服務(wù)。默認(rèn)情況下服務(wù)會(huì)監(jiān)聽(tīng) 11434 端口?？梢杂孟旅娴拿畲_認(rèn)服務(wù)是否正常curl http://localhost:11434/api/tags如果返回包含模型列表的 JSON就說(shuō)明服務(wù)已經(jīng)就緒。6.2 調(diào)用本地模型生成 JSON下面這段代碼封裝了一個(gè)函數(shù)向 Ollama 發(fā)送請(qǐng)求要求模型只返回 JSON 格式的結(jié)果。# 文件路徑ai_gateway.py import json import requests OLLAMA_URL http://localhost:11434/api/generate MODEL_NAME qwen2.5:7b def generate_json(prompt: str, model: str MODEL_NAME) - str: 調(diào)用本地模型強(qiáng)制返回 JSON 字符串。 payload { model: model, prompt: prompt, stream: False, format: json, } resp requests.post(OLLAMA_URL, jsonpayload, timeout120) resp.raise_for_status() data resp.json() return data[response]這里的關(guān)鍵點(diǎn)是format: json它要求模型盡量按 JSON 結(jié)構(gòu)輸出。但注意這只是一個(gè)引導(dǎo)不能保證輸出一定符合你的業(yè)務(wù)字段約束所以下一節(jié)要加校驗(yàn)。6.3 用 JSON Schema 做格式校驗(yàn)即使模型返回了 JSON字段也可能缺失、類型可能不對(duì)。我們用jsonschema庫(kù)做一次強(qiáng)約束校驗(yàn)。# 文件路徑ai_gateway.py繼續(xù)追加 from jsonschema import validate, ValidationError OUTPUT_SCHEMA { type: object, properties: { action: { type: string, enum: [query, create, update, delete] }, table: { type: string, enum: [users, orders, products] }, filters: { type: object, properties: { user_id: {type: integer, minimum: 1} } } }, required: [action, table], additionalProperties: False } def parse_and_validate(raw: str) - dict: 解析模型輸出并執(zhí)行 schema 校驗(yàn)。 try: data json.loads(raw) except json.JSONDecodeError as e: raise ValueError(f模型輸出不是合法 JSON: {e}) try: validate(instancedata, schemaOUTPUT_SCHEMA) except ValidationError as e: raise ValueError(f模型輸出不符合業(yè)務(wù)約束: {e.message}) return data這個(gè) Schema 約定模型必須返回action和table兩個(gè)字段action只能是四個(gè)枚舉值之一table只能是三個(gè)表名之一并且不允許出現(xiàn)額外的字段。如果模型返回了類似{action: drop, table: users}的內(nèi)容校驗(yàn)會(huì)直接失敗因?yàn)閐rop不在枚舉里。這可能救你一次。6.4 工具調(diào)用白名單校驗(yàn)真正要小心的是讓模型決定“調(diào)用什么工具”。這里提供一個(gè)工具白名單機(jī)制模型只能請(qǐng)求調(diào)用白名單內(nèi)的函數(shù)且參數(shù)必須通過(guò)校驗(yàn)。# 文件路徑ai_gateway.py繼續(xù)追加 ALLOWED_TOOLS { query_user: {user_id: {type: integer, minimum: 1}}, create_order: {product_id: {type: integer}, quantity: {type: integer, minimum: 1}}, get_product: {product_id: {type: integer}}, } class ToolNotAllowedError(Exception): 工具不在白名單內(nèi)時(shí)拋出。 def safe_tool_call(tool_name: str, args: dict) - None: 在真正執(zhí)行工具前做安全校驗(yàn)。 if tool_name not in ALLOWED_TOOLS: raise ToolNotAllowedError(f調(diào)用未授權(quán)的工具: {tool_name}) tool_schema { type: object, properties: ALLOWED_TOOLS[tool_name], required: list(ALLOWED_TOOLS[tool_name].keys()), additionalProperties: False, } try: validate(instanceargs, schematool_schema) except ValidationError as e: raise ValueError(f工具參數(shù)校驗(yàn)失敗: {e.message}) # 到這里才允許執(zhí)行真實(shí)工具邏輯 # 實(shí)際項(xiàng)目中這里再調(diào)用具體業(yè)務(wù)函數(shù)把工具名和參數(shù)做成白名單 Schema 校驗(yàn)可以有效防止模型調(diào)用未授權(quán)能力也能避免參數(shù)缺失造成的意外執(zhí)行。6.5 超時(shí)、重試與降級(jí)處理真實(shí)生產(chǎn)環(huán)境必須考慮模型服務(wù)不可用、返回超時(shí)、校驗(yàn)失敗等情況。下面這段代碼演示了如何把上面的模塊組合起來(lái)并設(shè)置降級(jí)策略。# 文件路徑ai_gateway.py繼續(xù)追加 import time import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) FALLBACK_RESULT {action: query, table: users, filters: {}} def run_task_with_safety(prompt: str, max_retries: int 2) - dict: 執(zhí)行一次帶安全校驗(yàn)和降級(jí)的模型調(diào)用。 for attempt in range(max_retries 1): try: logger.info(開(kāi)始調(diào)用模型第 %s 次嘗試, attempt 1) raw generate_json(prompt) logger.debug(模型原始輸出: %s, raw) result parse_and_validate(raw) logger.info(模型輸出通過(guò)校驗(yàn)結(jié)果: %s, result) if tool in result: safe_tool_call(result[tool], result.get(args, {})) return result except Exception as e: logger.warning(第 %s 次嘗試失敗: %s, attempt 1, e) if attempt max_retries: time.sleep(2 * (attempt 1)) logger.error(模型調(diào)用多次失敗返回降級(jí)結(jié)果) return FALLBACK_RESULT這里的降級(jí)不是萬(wàn)能藥。如果業(yè)務(wù)是“查詢商品信息”降級(jí)到空結(jié)果可以接受如果業(yè)務(wù)是“刪除訂單”絕不能降級(jí)成“刪除第一個(gè)訂單”。降級(jí)策略必須根據(jù)業(yè)務(wù)風(fēng)險(xiǎn)設(shè)計(jì)。6.6 運(yùn)行與驗(yàn)證方式寫(xiě)一個(gè)簡(jiǎn)單入口驗(yàn)證整個(gè)鏈路# 文件路徑run_demo.py from ai_gateway import run_task_with_safety prompt ( 請(qǐng)把下面的用戶意圖轉(zhuǎn)換為 JSON 操作指令 查詢用戶 ID 為 1001 的訂單列表。 只返回 JSON不要解釋。 ) result run_task_with_safety(prompt) print(result)運(yùn)行命令python run_demo.py預(yù)期結(jié)果是得到{action: query, table: orders, filters: {user_id: 1001}}這類結(jié)構(gòu)化輸出。如果模型返回了不合法內(nèi)容程序會(huì)進(jìn)入重試和降級(jí)分支并輸出降級(jí)結(jié)果。需要特別說(shuō)明模型輸出是概率性的每次運(yùn)行結(jié)果可能不同。如果模型一直返回不符合 Schema 的內(nèi)容先檢查模型能力是否太弱、Prompt 是否說(shuō)清楚了以及溫度參數(shù)是否過(guò)高。7. AI 應(yīng)用接入的常見(jiàn)問(wèn)題與排查思路問(wèn)題現(xiàn)象可能原因排查方式解決方案模型返回內(nèi)容不是合法 JSONPrompt 未明確要求、模型能力不足、溫度過(guò)高查看原始響應(yīng)日志調(diào)低 temperature、使用 format 參數(shù)、增加解析重試JSON 可解析但業(yè)務(wù)字段缺失Schema 約束未被模型理解檢查模型原始輸出與 Schema 差異在 Prompt 中給出示例輸出補(bǔ)充 required 字段說(shuō)明工具被重復(fù)調(diào)用多次缺少執(zhí)行狀態(tài)記錄查看工具調(diào)用日志增加 step limit、冪等鍵、狀態(tài)持久化記錄已執(zhí)行工具長(zhǎng)對(duì)話后模型遺忘早期約束上下文過(guò)長(zhǎng)關(guān)鍵信息被稀釋檢查 Prompt 歷史長(zhǎng)度使用摘要裁剪歷史把硬約束固定在 System PromptAgent 陷入循環(huán)錯(cuò)誤結(jié)果導(dǎo)致重復(fù)重試查看執(zhí)行軌跡和 Token 消耗設(shè)置最大步數(shù)、超時(shí)時(shí)間失敗后切換到人工處理AI 生成代碼集成測(cè)試失敗只驗(yàn)證了局部邏輯跑一次完整構(gòu)建與集成測(cè)試代碼評(píng)審重點(diǎn)關(guān)注跨文件調(diào)用和依賴兼容性排查時(shí)有一個(gè)通用原則不要只看最終結(jié)果要保留完整的請(qǐng)求與原始輸出日志。沒(méi)有日志你很難判斷問(wèn)題是模型幻覺(jué)、上下文丟失、參數(shù)錯(cuò)誤還是工具本身出了問(wèn)題。8. AI 工程落地的最佳實(shí)踐與安全建議如果要在團(tuán)隊(duì)里把 AI 能力穩(wěn)定落地下面這些實(shí)踐建議可以直接參考。第一給 AI 分配最小權(quán)限。無(wú)論是 Agent 還是編程助手只給它完成當(dāng)前任務(wù)所需的最小權(quán)限。工具能提供“查詢”接口就不要給它“刪除”接口能提供沙箱環(huán)境就不要讓它直連生產(chǎn)庫(kù)。權(quán)限越大出問(wèn)題時(shí)的影響范圍越大。第二高危操作必須有人工審批。涉及資金、刪除、發(fā)布、權(quán)限變更、用戶隱私數(shù)據(jù)導(dǎo)出的操作AI 只能生成“待審批請(qǐng)求”不能直接執(zhí)行。這一步可以用人工審批流來(lái)實(shí)現(xiàn)雖然降低了一點(diǎn)效率但能擋住絕大多數(shù)嚴(yán)重事故。第三建立完整的可觀測(cè)性。每次模型調(diào)用至少記錄請(qǐng)求時(shí)間、Prompt、模型名稱、采樣參數(shù)、原始輸出、校驗(yàn)結(jié)果、耗時(shí)、Token 消耗、最終執(zhí)行結(jié)果。有了這些日志才能事后復(fù)盤(pán)“為什么它這次做錯(cuò)了”。第四建立回歸評(píng)測(cè)集。不要靠“今天用著還行”來(lái)判斷系統(tǒng)質(zhì)量。挑一批有代表性的任務(wù)做成回歸數(shù)據(jù)集每次換模型、調(diào)參數(shù)后都跑一遍。評(píng)測(cè)集至少覆蓋正常輸入、邊界輸入、惡意輸入、長(zhǎng)上下文輸入。把“手感”變成“指標(biāo)”是 AI 工程化和 AI Demo 最大的區(qū)別。第五模型升級(jí)要灰度。大模型更新后能力會(huì)變化有時(shí)候是變強(qiáng)有時(shí)候是某個(gè)任務(wù)變差。不要直接在全局切新版本先在一部分流量上灰度對(duì)比評(píng)測(cè)結(jié)果再?zèng)Q定是否全量。云端模型 API 的版本變化也可能影響輸出所以要做好供應(yīng)商版本管理。第六防止 Prompt 注入。如果你的 AI 系統(tǒng)會(huì)處理用戶輸入要警惕用戶通過(guò)精心構(gòu)造的文本誘導(dǎo)模型執(zhí)行危險(xiǎn)操作。工具白名單、參數(shù) Schema 校驗(yàn)、敏感操作審批是對(duì)抗 Prompt 注入最重要的工程防線。不要指望模型自己能“抵抗”把安全邊界放到代碼里。9. 總結(jié)把 AI 放在“受監(jiān)管的執(zhí)行位”回到標(biāo)題為什么說(shuō)當(dāng)前的 AI 是“Not so competent AI overlords”因?yàn)樗葲](méi)有多智能體協(xié)作的完美穩(wěn)定性也沒(méi)有精確執(zhí)行命令的確定性。它擅長(zhǎng)生成和啟發(fā)但還不能承擔(dān)最終決策和全權(quán)執(zhí)行。正確的使用方式是把大模型當(dāng)作“一個(gè)能力不錯(cuò)但需要監(jiān)管的執(zhí)行者”。它適合生成初稿、補(bǔ)全信息、整理摘要、快速原型不適合直接掌握生產(chǎn)庫(kù)權(quán)限、直接調(diào)用高危工具、直接決定業(yè)務(wù)結(jié)果。在它前面要有清晰的約束和 Prompt 設(shè)計(jì)在它后面要有 JSON Schema、工具白名單、業(yè)務(wù)規(guī)則校驗(yàn)、日志審計(jì)和人工審批。這篇文章給出的核心方法只有一句話把大模型的輸出當(dāng)作不可信輸入來(lái)處理。如果你正在開(kāi)發(fā) AI Agent、接入大模型 API或者把 AI 編程助手引入團(tuán)隊(duì)建議先把這個(gè)原則落到代碼里再談?wù)摗癆I 能力邊界”和“智能體自主性”。建議收藏備用。下次當(dāng)你準(zhǔn)備把一個(gè) AI Agent 部署到生產(chǎn)環(huán)境時(shí)先問(wèn)自己三個(gè)問(wèn)題模型輸出如果亂來(lái)程序會(huì)崩嗎工具調(diào)用如果越權(quán)誰(shuí)能攔住關(guān)鍵決策如果出錯(cuò)日志查得到嗎這三個(gè)問(wèn)題都有明確答案后再讓它上線。