1. 從“會回答”到“會執(zhí)行”的一步之遙前幾天有位朋友跑來問我一個問題他已經(jīng)把某大模型接到自己的業(yè)務(wù)里了提示詞也寫得挺規(guī)矩角色設(shè)定、輸出格式、少樣本示例全都有可讓這個聊天機器人去幫他查一下庫存、算一下補貨量、再更新一下內(nèi)部的進貨表它死活做不到最后還是得人工復(fù)制粘貼。這事我太熟了。過去一年大家喊的“提示詞工程”大多數(shù)時候是在解決“如何讓模型把話說對”——把答案寫得更規(guī)范、更像人話、更有條理。但到了真實工作流里光是“把話說對”遠遠不夠。你需要的是一個能拆解任務(wù)、按步驟調(diào)用系統(tǒng)、并對每一步結(jié)果負責的智能體。這就是標題里說的那句“執(zhí)行力升級”從GPT這類對話模型到能跑通流程的AI Agent中間真正變掉的不是模型的“智商”而是提示詞工程的設(shè)計方式。OpenCSG在做相關(guān)實踐時我們最常被問的問題其實就三個任務(wù)到底怎么拆工具到底怎么調(diào)安全邊界到底劃在哪這篇博客把這三件事一次講透送給正在把大模型從“聊天窗”往“干活系統(tǒng)”里搬的人。1.1 大家都在說的“提示詞工程”其實分兩個時代如果你拆開看提示詞工程這兩年其實經(jīng)歷了兩次完全不同的考卷。第一次考卷是“單向生成”模型接收到一段文字輸出一段文字任務(wù)邊界清晰評價標準是“答得對不對、好不好”。這時候的提示詞大量使用角色扮演、語氣限制、輸出模板本質(zhì)是在指導(dǎo)一個表達能力很強但沒有行動能力的文員寫報告。第二次考卷是“多輪執(zhí)行”模型接收目標自己規(guī)劃步驟選擇合適的工具觀察工具返回結(jié)果再決定下一步動作。這時候的提示詞不再是靜止的“臺詞腳本”而是一份動態(tài)的“任務(wù)說明書”它要能被同一個主循環(huán)反復(fù)讀取、更新、校驗。問題也隨之而來——說明書寫得太粗模型不知道從哪里下手寫得太細又很快燒光上下文額度。很多團隊把第一代經(jīng)驗直接搬到第二代結(jié)果就是朋友遇到的那種狀況模型在“說”的部分表現(xiàn)完美在“做”的部分完全拉胯。1.2 智能體不是一個產(chǎn)品形態(tài)而是一種執(zhí)行邏輯所以要理解從GPT到智能體的升級關(guān)鍵不是“換一個更聰明的模型”而是“換一套執(zhí)行框架”。GPT時代的提示詞工程對象是模型的輸出分布——怎么讓生成結(jié)果落在你想要的區(qū)間里。智能體時代的提示詞工程對象是“模型工具狀態(tài)”的閉環(huán)——模型負責決策工具負責落地狀態(tài)負責告訴模型“上一步到底發(fā)生了什么”。這個閉環(huán)通常包含三個組件記憶讓智能體知道上下文和歷史規(guī)劃讓智能體把大目標拆成小步驟執(zhí)行讓智能體通過調(diào)用外部工具真正改變系統(tǒng)狀態(tài)。提示詞在其中的作用是把這個閉環(huán)里的每一步都約束在可控范圍內(nèi)。說到底提示詞依然是靈魂只是它的工作方式從“寫一篇作文的要求”變成了“指揮一個團隊運行的流程文檔”。2. GPT的“高分作文”與智能體的“干活邏輯”差在哪你要想清楚一個事GPT本質(zhì)上是一個“靜態(tài)知識發(fā)生器”。它從訓(xùn)練數(shù)據(jù)里學到的世界是凝固的——你問它“今天天氣怎么樣”它能給你寫一篇關(guān)于天氣系統(tǒng)如何運作的千字科普但它不知道窗戶外面現(xiàn)在下沒下雨。因為訓(xùn)練數(shù)據(jù)停在某個時間點模型沒有實時傳感器。這不叫“蠢”這是架構(gòu)天生的邊界。大模型的強項是語言理解、知識檢索、邏輯推理、內(nèi)容生成它的弱項是所有涉及“當前狀態(tài)”和“物理世界動作”的環(huán)節(jié)。而智能體要干的事恰恰是補上這兩個缺口實時狀態(tài)的獲取以及對外部系統(tǒng)的影響。2.1 靜態(tài)知識與實時狀態(tài)之間的斷層舉個非常具體的例子。讓GPT直接回答“我們倉庫A類物料的庫存還剩多少”它會給你一段“倉庫管理需要注意……”的建議這不是它不配合而是它的訓(xùn)練數(shù)據(jù)里根本沒有你們公司的庫存表。你可以在提示詞里把庫存數(shù)字寫進去但它沒法保證數(shù)字是最新的更沒法在每次變化后自動更新自己。于是你想到了工具調(diào)用讓模型去查數(shù)據(jù)庫。這個思路完全正確但只是第一步。因為查完之后呢如果庫存低于安全閾值模型要不要自動生成采購申請采購申請走哪條審批流審批通過后要不要更新預(yù)測模型這一連串動作靠一次“問答”永遠答不完。這中間的斷層在于模型理解世界的單位是“事實和概念”業(yè)務(wù)系統(tǒng)運轉(zhuǎn)的單位是“事件和狀態(tài)變更”。提示詞工程要做的就是搭一座橋讓模型的理解能力能被拆成一系列事件把“理解”變成“動作”。2.2 模型缺的不是智商是記憶、規(guī)劃、執(zhí)行三塊拼圖所以你看那些跑起來的智能體項目背后幾乎都是同一類架構(gòu)一個規(guī)劃循環(huán)在反復(fù)運轉(zhuǎn)。第一步模型根據(jù)用戶目標生成一個計劃。第二步系統(tǒng)按計劃選擇一個工具模型抽取參數(shù)、發(fā)起調(diào)用。第三步工具執(zhí)行完返回結(jié)果模型觀察結(jié)果判斷計劃是否需要調(diào)整。第四步循環(huán)繼續(xù)直到目標達成或達到終止條件。這個循環(huán)里提示詞工程干的活不是“寫一段漂亮的話”而是設(shè)計三個東西怎么讓模型把計劃拆得足夠可執(zhí)行怎么讓工具列表對模型來說是“可理解、可選擇、可調(diào)用的”怎么確保這個循環(huán)在任何一步出錯時都能安全收住。我見過不少團隊在產(chǎn)品原型階段犯同一個錯誤他們把注意力全放在“選個聰明的模型”上結(jié)果模型推理能力強了但工具調(diào)用一塌糊涂。因為工具調(diào)用不是模型“順手就會”的它是工程問題是提示詞、接口、數(shù)據(jù)格式、錯誤處理合在一起的結(jié)果。3. 拆分步驟把“目標”翻譯成模型能逐步走完的走查單智能體時代的第一課是任務(wù)分解。別急著寫工具、調(diào)接口先把“目標”拆成“步驟”。拆得對不對直接決定后面的穩(wěn)定程度。這里的拆不是讓模型隨便想想“先做什么后做什么”而是要拆成一個帶依賴關(guān)系、可驗證、可回滾的任務(wù)序列。你可以把它理解成給新人寫的SOP不能寫“把項目搞定”要寫“先讀配置、再拉數(shù)據(jù)、再跑校驗、最后出報告每一步的輸出是什么卡住了找誰”。3.1 兩步拆分法目標樹 依賴關(guān)系我自己常用的方法分兩步。第一步先畫目標樹把最終目標往下拆直到每個葉節(jié)點都能對應(yīng)一個“動作 可驗證結(jié)果”。第二步做依賴分析哪些任務(wù)必須串行哪些可以并行哪些失敗了必須中止整個流程。舉個例子目標是“匯總本周各組項目狀態(tài)并發(fā)出周報郵件”。拆開以后大概是拉取各組進度數(shù)據(jù) - 匯總成統(tǒng)一格式 - 生成周報正文 - 調(diào)用郵件工具發(fā)送。這里面拉取數(shù)據(jù)和生成正文可以并行但生成正文依賴拉取結(jié)果發(fā)送又依賴生成完成。如果一個環(huán)節(jié)的數(shù)據(jù)源掛了你是繼續(xù)用緩存生成還是直接終止應(yīng)該提前定義好而不是讓模型臨場發(fā)揮。這種拆分最大的價值是“可觀測”。每一步的輸入輸出都是明確的你可以在任意一步插入檢查點確認數(shù)據(jù)沒有跑偏。3.2 什么時候算“拆到位”可驗證、可回退、可合并很多新手拆任務(wù)容易拆成兩個極端。拆太粗一個任務(wù)里還是塞了一堆動作模型的規(guī)劃能力反而成了瓶頸拆太細每一步都調(diào)用一次模型Token消耗和延遲雙雙爆炸。我自己的判斷標準有三條可驗證這步完成后有一個明確的結(jié)構(gòu)化結(jié)果來判斷成敗可回退這步出錯時能回到上一步不影響全局可合并相鄰步驟如果能共享同一個數(shù)據(jù)源且不存在外部副作用就應(yīng)該合成一步。拿“生成周報”來說“整理各組數(shù)據(jù)”和“按模板生成文字段落”可以分開但“生成文字段落”和“在本地臨時文件里存一份”就沒必要分。前者是決策步驟需要模型參與后者是純機械動作可以直接由代碼完成。智能體的每一步未必都要經(jīng)過大模型能在工程代碼里硬編碼的就別浪費模型的推理。3.3 與子任務(wù)配套的Prompt寫法任務(wù)拆完之后還要給每個子任務(wù)寫一段“獨立的小提示詞”。這段提示詞的職責很單一解釋這個子任務(wù)的目標、輸入數(shù)據(jù)的格式、輸出結(jié)果的預(yù)期結(jié)構(gòu)以及遇到異常情況時怎么辦。這跟傳統(tǒng)的“一段prompt走天下”完全不同。子任務(wù)提示詞不需要講背景故事不需要預(yù)設(shè)角色只需要說清楚“你手頭有什么、你要產(chǎn)出什么、什么情況下算失敗”。比如拉取數(shù)據(jù)那段提示詞只需要說明數(shù)據(jù)接口的路徑、鑒權(quán)方式、失敗重試次數(shù)以及返回JSON的寫入位置。段落越短越好因為上下文窗口終究有限把最重要的執(zhí)行信息放在最顯眼的位置模型理解的準確率才會高。我見過不少團隊把任務(wù)拆好了但給每個子任務(wù)配的提示詞還沿用“你是資深專家”那一套不僅沒用還浪費上下文。子任務(wù)提示詞是“操作指令”不是“角色設(shè)定”。4. 工具調(diào)用把大模型“對話能力”引到外部系統(tǒng)的工程細節(jié)任務(wù)拆好了接下來就是讓模型真正“使用工具”。工具調(diào)用的成熟方案現(xiàn)在很多主流的大模型API基本都支持Function Calling機制。其原理并不復(fù)雜你在請求里聲明一批“工具”每個工具包含名稱、功能描述和參數(shù)結(jié)構(gòu)模型根據(jù)對話上下文決定“要不要調(diào)用某個工具、參數(shù)填什么”系統(tǒng)收到調(diào)用指令后去執(zhí)行真實代碼再把結(jié)果回傳給模型。這套機制看似簡單但工程細節(jié)極其容易翻車尤其是工具描述本身的質(zhì)量問題。4.1 工具描述本身就是一種提示詞很多人沒意識到Function Calling里的“工具描述”本質(zhì)上就是一種提示詞。它是模型唯一能用來判斷“何時調(diào)用、調(diào)用哪個、參數(shù)怎么填”的依據(jù)。如果你把工具描述當成API文檔來寫全是準確但冷峻的技術(shù)術(shù)語模型經(jīng)常會在“該用哪個”上猶豫。比如你給兩個工具“查詢訂單信息”和“查詢退款信息”。模型面對用戶說“幫我看看我上個月那筆訂單”它很可能拿不準該查哪個于是隨便選一個結(jié)果數(shù)據(jù)對不上。如果你把描述寫成“當用戶提到訂單、購買記錄、物流等場景時使用”模型的選擇準確率會高很多。參數(shù)結(jié)構(gòu)也一樣。每個參數(shù)都要寫明含義、類型、取值范圍、是否必填能加默認值的加默認值。別把參數(shù)設(shè)計成“讓模型猜”模型不是特別擅長猜你的內(nèi)部字段命名習慣。4.2 一次工具調(diào)用的完整生命周期一個標準的工具調(diào)用生命周期長這樣模型輸出一個工具調(diào)用請求 - 系統(tǒng)校驗請求格式、檢查參數(shù)合法性 - 系統(tǒng)執(zhí)行真實工具函數(shù) - 拿到返回結(jié)果 - 將結(jié)果作為“觀察消息”重新塞回對話 - 模型根據(jù)結(jié)果繼續(xù)生成下一步。這里最核心的坑在“系統(tǒng)校驗”這一步。我建議所有工具調(diào)用都先做一次參數(shù)白名單校驗把不符合schema要求的請求直接攔截而不是貿(mào)然執(zhí)行。因為模型偶爾會生成一些“似是而非”的參數(shù)比如日期格式寫錯、枚舉值越界、字符串里混入多余字符。如果直接把這種參數(shù)丟給業(yè)務(wù)接口輕則報錯重則寫入臟數(shù)據(jù)。另外工具返回結(jié)果也要設(shè)計得適合模型閱讀。別把數(shù)據(jù)庫原始記錄整包丟回去字段一多模型很快暈掉。最好做一次“壓平”處理只保留當前任務(wù)需要的字段并格式化好枚舉值的中文含義讓模型一眼能看懂結(jié)果意味著什么。4.3 工具調(diào)用最容易翻車的三個地方第一個翻車點是工具名和描述里的“歧義”。“獲取用戶信息”和“獲取用戶詳情”字面上幾乎一樣模型根本分不清。解決辦法是給工具加場景前綴比如“CRM_獲取用戶核心資料”“訂單_查詢用戶近期訂單”讓工具名自帶分類信息。第二個翻車點是參數(shù)沖突。你有一個工具接收“日期范圍”比如start_date和end_date模型很可能把兩個參數(shù)的順序填反。這時候你可以在參數(shù)描述里寫清楚“開始日期不能晚于結(jié)束日期”并且在系統(tǒng)校驗階段加一個自動校正邏輯發(fā)現(xiàn)start_date比end_date晚就自動交換而不是直接報錯。第三個翻車點更隱蔽上下文污染。工具調(diào)用好幾次之后對話歷史里塞滿了觀察結(jié)果模型看到后面前面關(guān)鍵信息被沖淡。解決辦法是定期壓縮歷史保留用戶核心目標、最近兩輪的工具結(jié)果以及當前未完成的子任務(wù)狀態(tài)不需要把全部工具返回都堆在提示詞里。5. 安全邊界執(zhí)行力越強越要管住“最后一公里”智能體跟聊天機器人的本質(zhì)區(qū)別是它會“動作”。能動作就必然帶來風險。你讓聊天機器人胡說八道頂多是被用戶罵兩句你讓智能體誤刪數(shù)據(jù)、誤發(fā)郵件、誤轉(zhuǎn)賬那就是真事故了。所以安全邊界的核心原則是在智能體的執(zhí)行鏈路上防系統(tǒng)性風險而不是只防單點錯誤。5.1 最小權(quán)限與工具白名單我的第一個建議給智能體開放的工具集永遠走“最小權(quán)限”原則。能只讀的不要給寫權(quán)限能查當前組織數(shù)據(jù)的不要給全平臺數(shù)據(jù)查詢權(quán)限能返回匯總數(shù)據(jù)的不要給原始庫表接口。工具白名單設(shè)計同樣重要。不要把所有接口一股腦注冊成Function而是按場景劃分工具包。比如“查詢場景”只注冊三個只讀接口“執(zhí)行場景”單獨注冊一個帶審批鉤子的寫接口。模型每次可選的工具范圍是有限的這會直接減少誤選概率。有一個真實的教訓(xùn)某團隊把所有內(nèi)部系統(tǒng)的接口都注冊成了工具包括“刪除用戶”“修改訂單金額”這種高危接口。然后在測試時讓智能體去“模擬一次越權(quán)訪問”模型竟然真的調(diào)用了刪除接口雖然最后因為環(huán)境權(quán)限攔截住了但把運維嚇出一身冷汗。高危操作必須需要審批不能再靠“模型應(yīng)該知道不能做”。5.2 操作確認與人工閘門對高影響操作我強烈建議加一個“人工確認閘門”。具體做法是把工具分成兩級一級工具模型可以直接調(diào)用通常是只讀、低風險操作二級工具模型只能“申請調(diào)用”調(diào)用請求會進入一個待確認隊列真實執(zhí)行要等人工點了確認按鈕。這樣設(shè)計的理由很簡單模型對后果的感知是極其有限的。它能推理“刪除用戶是會傷害用戶的行為”但它理解不了“這個用戶關(guān)聯(lián)了一百條業(yè)務(wù)記錄、十張工單、五條審批流刪了會連鎖報錯”。人工確認閘門把這個理解成本轉(zhuǎn)移給了更靠譜的人。你可以在產(chǎn)品上做成彈窗形式智能體執(zhí)行到高危步驟時界面彈出“將執(zhí)行以下操作發(fā)送郵件給張三內(nèi)容為……”人工點“允許”或“拒絕”。實測下來這個設(shè)計不僅降低了事故率還明顯提升了用戶對智能體的信任感因為用戶覺得“它是我的助手不是我失控的代理”。5.3 提示注入與越權(quán)指令的防護思路提示注入是智能體特有的安全威脅。攻擊者把惡意指令藏在文本里比如商品評論、用戶輸入、文檔內(nèi)容讓模型去執(zhí)行不該執(zhí)行的操作。防注入沒法百分百做到但可以從三個層面降低風險。第一層是輸入側(cè)過濾對進入對話系統(tǒng)的外部文本做大模型安全分類識別明顯的惡意指令模式。第二層是工具側(cè)校驗就算模型被誘導(dǎo)工具調(diào)用層也要校驗參數(shù)是否越權(quán)高危操作必須有二次確認攻擊者沒法通過“語言引導(dǎo)”繞過工程權(quán)限。第三層是結(jié)果側(cè)審計所有工具調(diào)用留痕誰發(fā)起的調(diào)用、模型說了什么、返回了什么全部進日志。說白了安全邊界不能只依賴模型的“道德判斷”要在工程鏈路上設(shè)置硬閘門。語言模型可以被誘導(dǎo)但權(quán)限系統(tǒng)和人工審批流不會被一段prompt騙過去。6. 一個最小可復(fù)現(xiàn)的“跨系統(tǒng)執(zhí)行”示例講了這么多原理上點實戰(zhàn)。我選一個最常見的場景讓智能體根據(jù)郵件內(nèi)容去系統(tǒng)里查詢項目信息再生成一封周報回復(fù)并且在最終發(fā)送前要人工確認。整個示例盡可能簡單但足以覆蓋“任務(wù)拆解、工具調(diào)用、安全邊界”三個主題。6.1 場景設(shè)定與工具清單假設(shè)業(yè)務(wù)場景是這樣的用戶給智能體發(fā)一段原始郵件文本內(nèi)容是“請幫我看一下某項目的當前進度整理成進度摘要然后以郵件草稿的形式回復(fù)給我”。我給它注冊三個工具剛好對應(yīng)三級安全策略fetch_project_progress(project_id)只讀工具查詢項目進度供模型直接調(diào)用。generate_draft_email(project_id, summary, recipient)寫操作生成郵件草稿但不真正發(fā)送可供模型直接調(diào)用。send_email(draft_id, recipient)高危操作真正發(fā)送郵件必須經(jīng)過人工確認。工具描述我寫成下面這樣注意描述里的場景引導(dǎo)詞[ { name: fetch_project_progress, description: 當用戶詢問項目進度、交付狀態(tài)、里程碑完成情況時使用。返回項目各階段的最新進度、風險點和負責人。, parameters: { project_id: { type: string, description: 項目唯一標識 } } }, { name: generate_draft_email, description: 基于進度數(shù)據(jù)生成回復(fù)客戶或內(nèi)部團隊的郵件草稿。不發(fā)送僅保存草稿后返回草稿ID。, parameters: { project_id: { type: string, description: 項目標識 }, summary: { type: string, description: 郵件正文的核心摘要 }, recipient: { type: string, description: 收件人郵箱 } } }, { name: send_email, description: 最終發(fā)送指定郵件草稿。此操作不可逆執(zhí)行后郵件將真實發(fā)出。, parameters: { draft_id: { type: string, description: 要發(fā)送的草稿ID } } } ]注意看工具描述本身把“什么時候該用這個工具”的邏輯寫進去了不是干巴巴的接口文檔。模型看到“當用戶詢問項目進度……”就更容易把輸入文本匹配到第一個工具。6.2 主循環(huán)與安全閥代碼示意簡化版的主循環(huán)邏輯可以寫成這樣只展示核心過程每行都給了注釋def agent_loop(user_input, max_steps6, confirm_funcNone): messages [{role: user, content: user_input}] for step in range(max_steps): # 第一層讓模型決定下一步動作傳入工具定義 resp llm.call(messages, toolsTOOLS) msg resp.choices[0].message # 模型沒有發(fā)起工具調(diào)用說明任務(wù)可能已完成或需要提問 if not msg.tool_calls: return msg.content messages.append(msg.model_dump()) for call in msg.tool_calls: tool_name call.function.name args json.loads(call.function.arguments) # 第二層參數(shù)白名單校驗 if not validate_tool_params(tool_name, args): messages.append(gen_tool_error(tool_name, 參數(shù)校驗失敗)) continue # 第三層高危操作走人工確認閘門 if tool_name send_email: allow confirm_func(args) if not allow: messages.append(gen_tool_result(操作被用戶取消)) continue # 執(zhí)行真實工具 result exec_tool(tool_name, args) messages.append(gen_tool_result(tool_name, result)) raise RuntimeError(超過最大執(zhí)行步數(shù))這段代碼里的三層機制就是這部博文反復(fù)強調(diào)的模型負責決定但系統(tǒng)負責校驗、攔截和執(zhí)行。run到“send_email”時refuse允許就是靠confirm_func人工確認否則模型再聰明也不能把郵件發(fā)出去。6.3 實測驗證與常見失敗模式我把這個Demo跑過不下五十輪常見的幾個失敗模式非常有代表性。第一類是模型把項目ID填錯。用戶郵件里寫的內(nèi)容往往不是標準ID模型經(jīng)常把“RF-2024-15”這種編號里的數(shù)字提取錯。解決辦法是在參數(shù)校驗里加上“ID必須匹配正則 ^RF-\d{4}-\d{2}$”不匹配就反饋給模型重新提取。第二類是模型生成摘要時過度發(fā)揮。明明查詢結(jié)果只有三條更新它卻編出一些“預(yù)計下月完成”的推測。這種幻覺單靠工具調(diào)用鏈路攔不住需要在“生成摘要”的提示詞里加約束只能引用工具返回數(shù)據(jù)不得額外推斷。如果還是出現(xiàn)就再讓工具返回結(jié)果里帶上“更新時間戳”由系統(tǒng)校驗摘要里是否內(nèi)部一致。第三類最值得注意模型在這個任務(wù)里反復(fù)調(diào)用fetch_project_progress因為用戶原始郵件里提到了多個項目。模型可能分不清“主要詢問的是哪個”于是每個都查一遍。這本身沒壞處但會拖慢響應(yīng)。處理辦法是在提示詞里加一句“如果用戶未明確指定項目先詢問澄清不要批量查詢”讓模型學會停住。7. 我在實戰(zhàn)里踩過的幾個坑寫給正在搭建Agent的人最后分享幾個比較碎但很實用的心得基本都來自我在OpenCSG社區(qū)里看到的共性問題。7.1 “工具描述全是精確術(shù)語”并不好理解早期我給工具寫描述時喜歡用特別學究的說法“Call create_disputeAPI-3B發(fā)起售后爭議流程。”結(jié)果模型經(jīng)常不調(diào)用它因為用戶不會說“售后爭議流程”用戶只會說“我要退款”“這單有問題”“把錢退給我”。后來我把描述改成“當用戶對訂單不滿、要求退款、抱怨貨物有問題或提出售后相關(guān)訴求時可以調(diào)用本工具發(fā)起爭議處理流程。”模型的理解準確率立刻上來了。這就是“工具描述是用給模型看的不是用給文檔評審看的”含義。7.2 溫度參數(shù)不是越高越好調(diào)很多人調(diào)Agent時習慣把temperature調(diào)到比較高覺得“生成內(nèi)容更豐富”。但在工具調(diào)用場景這是大忌。溫度一旦調(diào)高模型輸出JSON時格式不穩(wěn)定的概率顯著增大參數(shù)值也會出現(xiàn)無意義的偏移。我目前的做法是涉及工具調(diào)用的推理環(huán)節(jié)temptature固定在0.1以內(nèi)只有“生成文案”這種創(chuàng)意型子任務(wù)才把溫度調(diào)到0.7以上。也就是同一個Agent內(nèi)不同子任務(wù)用不同的溫度參數(shù)而不是全局一套設(shè)置。7.3 先攔截動作再攔截輸出最后一條經(jīng)驗來自一次差點出事的事故。某個內(nèi)部工具可以刪除項目附件模型在生成回復(fù)時提到“用戶要求刪除附件已處理”。但實際上模型根本沒有調(diào)用刪除工具它只是在“輸出層面”編造了一個結(jié)果。幸好當時有動作審計日志一查發(fā)現(xiàn)沒有對應(yīng)調(diào)用記錄才沒讓用戶以為真的刪了。從此我養(yǎng)成了一個習慣所有輸出給用戶的結(jié)果必須能跟工具調(diào)用記錄一一對應(yīng)。模型可以說“已處理”但如果處理記錄里沒有動作那就說明它撒謊了。先攔住“動作”再去糾正“輸出”。這也是安全邊界的最后一環(huán)——審計追蹤。搭智能體跟搭傳統(tǒng)服務(wù)不一樣你要同時面對模型的創(chuàng)造性、系統(tǒng)狀態(tài)的復(fù)雜性、以及用戶預(yù)期的錯位。但只要把任務(wù)拆明白、把工具描述寫清楚再把安全邊界劃到執(zhí)行鏈路里這件事就會從一個“玩具”變成“生產(chǎn)力”。剩下的就是多跑幾輪讓異常樣本幫你打磨系統(tǒng)的每一個判斷分支。