1. 為什么明明用了大模型結果還是像在“猜”你要什么我第一次上手做 AI Agent 的時候最大的挫敗感不是模型能力不夠而是我壓根說不明白話。我問它“幫我分析一下這個需求”它給我寫了兩千字的代碼架構我說“寫得簡單點”它又給我改成了十條 bullet point。反復拉鋸幾輪之后我意識到問題不在模型而在提示詞本身——提示詞不是“問問題”而是“描述你想要的完整工作方式”。很多剛接觸大模型的朋友會有個直覺AI 不是跟人聊天嗎那我像跟同事說話一樣說需求不就行了這個直覺一半對一半錯。對的是它確實能聽懂自然語言錯的是大模型對模糊容忍度極低。你給了它一個模糊目標它就會用概率最高的方式瞎猜——而概率最高的方式往往是“最平庸的泛化回答”不是你要的那個具體結果。1.1 先理解提示詞進入模型后發(fā)生了什么從技術底子上看大模型本質上是一個“基于上下文的概率預測器”。當你把一串提示詞輸進去它做的事情是把文字切分成 token然后逐個預測下一個 token 最可能是什么。這個過程跟人理解語言完全是兩回事——人理解的是“意圖”模型計算的是“統(tǒng)計上的延續(xù)”。這就解釋了為什么同一個提示詞在不同模型上結果天差地別因為不同模型的訓練數(shù)據(jù)、參數(shù)規(guī)模和指令遵循能力不一樣。強一點的模型比如 Claude、GPT 系列的中高端版本對“少寫廢話”這種相對抽象的指令執(zhí)行得比較好弱一點的模型就需要你把規(guī)則掰開揉碎寫清楚“降低輸出長度每節(jié)不超過 100 字不要使用列表”這種顆粒度。有個曾經(jīng)很火的梗叫“鵜鶘騎自行車”——是一張測試多模態(tài)模型的圖片很多模型看不出鵜鶘是怎么騎的。這種“看不見”和“聽不懂”是一個道理它沒有建立“把圖片里每個對象和動詞關聯(lián)起來”的指令鏈條所以只能憑常見組合猜。提示詞工程在文本場景里要做的事情也類似用足夠精確的表述把模型的猜測空間壓到最小。1.2 常見的“聽不懂”場景背后是同一個原因我在實際項目里總結過模型“聽不懂”基本逃不開四類情況目標含糊只說“幫我處理一下數(shù)據(jù)”沒說處理成什么樣、按照什么維度、產出什么格式。背景缺失沒交代這個結果給誰用、用在什么場景、有沒有歷史約束模型只能按通用方式處理。約束遺漏沒說不許用什么技術棧、不需要什么內容、避開哪些坑它就會給你填一堆它覺得“加分”的料。格式?jīng)]約定沒說輸出 JSON 還是表格還是純文本它就按心情混合輸出下游解析直接炸掉。這四類問題跟模型參數(shù)規(guī)模其實關系不大純粹是提示詞沒有給到足夠的信息密度。就好比你讓實習生去整理一份行業(yè)報告只丟給他一句“整理一下”他肯定交回來一份你不想看的東西——不是他笨是任務描述根本沒達到“可執(zhí)行”的標準。所以“讓大模型真正聽懂你說話”這個系列的主題不是教你怎么“把話說的更好聽”而是教你怎么把一個模糊需求翻譯成一個精確的任務規(guī)格說明。這個翻譯能力就是提示工程的核心能力。2. 把提示詞拆開看六要素寫出不翻車的提示詞我早期寫提示詞非常隨緣想到什么寫什么。后來被現(xiàn)實教育了幾次比如讓 AI 生成的代碼直接帶 bug 進生產、讓 AI 寫的文案被合規(guī)打回三次才開始認真整理一套結構化的寫法?，F(xiàn)在我基本會把一條正式提示詞拆成六個要素角色、任務、上下文、約束、示例、輸出格式。這套東西說起來很簡單但真正每條都用上、用好效果完全是兩個量級。下面逐個拆開說。2.1 角色、任務、上下文先把“人設”立住角色Role不是花活。“你現(xiàn)在是一個資深 Python 后端工程師”這句話最大的作用不是讓模型“代入”而是激活它在訓練數(shù)據(jù)里學到的相關領域知識分布。它學過海量的 Python 代碼和架構討論但你不提角色它可能按“通用寫作助手”的模式來組織語言。一個簡單測試同樣的技術問題用不用角色后綴輸出的術語顆粒度完全不同。任務Task是整條提示詞的心臟。這里最容易犯的錯是把任務寫成“目標”而不是“動作”。比如失敗寫法“分析這段代碼”成功寫法“指出這段代碼中所有可能導致并發(fā)問題的地方按嚴重程度排序并針對每一項給出具體修改建議”區(qū)別在哪里后者有明確的檢查方向并發(fā)問題、有排序要求嚴重程度、有產出物修改建議。模型不需要猜你要什么只需要照著做。上下文Context是很多人忽略但最能拉開效果差距的。一個項目里你要告訴模型這個代碼服務的業(yè)務是電商訂單還是算法訓練數(shù)據(jù)量級是多少服務于內部還是外部用戶。同樣一句“查詢超時怎么優(yōu)化”有上下文時它會往索引、連接池、緩存方向寫沒上下文時它可能從硬件配置開始講起對你來說全是廢話。2.2 輸出格式、約束與示例把驗收標準說清楚輸出格式Format這件事在 AI Agent 場景里尤其重要——因為 Agent 的下游往往不是人而是代碼。如果模型輸出 Markdown 而你的解析器只認 JSON那后面全部白搭。所以我在所有工程化提示詞里都會寫一條“你必須輸出 JSON不要包含任何解釋性文字”之類的話并且用代碼塊或示例來鎖定結構。約束Constraint是提示詞的“紅線”。比如“不要調用外部 API”“不解釋代碼只給出修改后的完整函數(shù)”“不要使用第三方依賴庫”。約束放得越具體模型越不容易在邊界上來回試探。但它有個副作用——約束多了會擠占上下文空間也可能會讓模型變得過度保守。所以約束要有優(yōu)先級一條提示詞里最好不超過五條強約束其余用示例來暗示。示例Example是最強的約束。一切抽象描述都不如一個具體的輸入輸出對照模板。想讓模型按格式輸出你給一個“輸入…輸出…”的例子比寫一百字“請嚴格遵循以下格式”都管用。很多成熟的 prompt 模版就是靠 two-shot / three-shot給兩到三個示例來穩(wěn)定模型輸出的。2.3 一個對比案例要素全乎和要素缺位的差距我拿自己實際調過的場景做一個對照。當時要做的是一個工單分類 Agent輸入是用戶提交的文本工單輸出是分類結果、緊急程度和處理建議。第一版提示詞是這樣請分析下面的工單并給出處理建議 {工單內容}這種提示詞不是不能用而是輸出質量極不穩(wěn)定分類類別它自己定緊急程度有時候高有時候低處理建議有時候給三行有時候給三頁而且偶爾會夾帶私貨“這道工單可轉人工處理”這種流程話。后來我按六要素重寫角色你是電商平臺的工單分類專員熟悉退換貨、物流、支付、賬號安全四類業(yè)務。 任務判斷工單所屬類別、緊急程度高/中/低并給出不超過50字的處理建議。如果信息不足輸出需補充信息。 上下文工單來自C端用戶分類結果會進入自動響應系統(tǒng)緊急程度高的工單會觸發(fā)人工介入。 約束 - 只輸出JSON不要輸出任何其他文字 - 分類只能是退換貨/物流/支付/賬號安全/其他 - 緊急程度判斷標準涉及資金安全或無法登錄為高涉及時效承諾為中其余為低 輸出格式 {category: ..., urgency: ..., suggestion: ...} 示例 輸入我上周買的手機到現(xiàn)在沒發(fā)貨客服也沒回應 輸出{category: 物流, urgency: 中, suggestion: 核查發(fā)貨超時原因優(yōu)先發(fā)送物流異常通知并承諾處理時限}改動之后效果立竿見影解析成功率從大概七成漲到接近滿分而且模型基本不會再冒出來格式外的內容。這段對比也是我在文章里最想傳遞的一個觀點——提示詞不是寫給人看的是寫給模型看的“需求規(guī)格說明書”你把每個環(huán)節(jié)講得多細它就執(zhí)行得有多準。3. 提示工程進階讓模型“想清楚”再回答六要素解決的是“說得清楚”的問題但很多時候需求說清楚了模型給出的結果還是浮于表面。比如你讓它“寫一個用戶登錄接口”它確實寫了個接口但沒有異常處理、沒有日志、沒有防刷——它是在“直接給答案”而不是“先想一遍再給答案”。這時候需要用一些進階技巧讓模型輸出的深度從“表面正確”走向“真正可用”。3.1 思維鏈不玄乎就是把做題過程寫出來思維鏈Chain-of-ThoughtCoT在論文里的定義很學術但在實操中就是一句話在要求模型給最終結果之前先讓它把思考過程和中間步驟寫出來。這個原理也不復雜——模型在生成最終答案前會先走一段“思維過程”如果你允許它顯式地寫出來它的每一步推理會更有依據(jù)而不是直接跳到結論。比如做 count 類題目你直接問“下面這句話里有幾個 a”模型經(jīng)常數(shù)錯。但你讓它“先列出每個單詞再逐個檢查字母”正確率會有明顯提升。Agent 場景里更典型的是“規(guī)劃型任務”“用戶想買一臺性價比高的游戲本預算6000”。如果直接給答案它可能推薦熱門機型如果讓它“先拆解用戶需求再篩參數(shù)再對比競品最后給推薦”答案的層次完全不同。實操上CoT 有兩種注入方式。一種是在提示詞里顯式寫“請一步一步思考并在最終答案前輸出你的推理過程”另一種是用 few-shot 示例在示例里展示“步驟1、步驟2、結論”的結構。后者更隱蔽但穩(wěn)定性更好尤其當你用的模型比較弱、顯式要求容易觸發(fā)額外瞎編的時候。注意CoT 不是所有場景都必須上。如果任務是“翻譯一句話”“做文本分類”你讓它多想幾步反而會拖慢速度、浪費 token甚至因為“多想”而偏離標準答案。把 CoT 用在邏輯推理、方案設計、代碼生成這類復雜任務上收益才最大。3.2 Few-shot 示例比“你要專業(yè)一點”有效得多很多人調提示詞喜歡加形容詞“請專業(yè)地回答”“請詳細一些”“請嚴謹一點”。這些詞不是沒用但作用非常有限——它只是改變了模型的“語氣分布”沒有改變模型對任務結構的理解。相比之下給樣例few-shot的效果要扎實得多。因為你實際上是在做“隱式約束”模型會模仿你給的例子的結構、詳略程度、語氣、甚至格式。我見過一個很夸張的例子有人讓 LLM 寫英文郵件加了五個正式商務郵件樣例后模型的輸出措辭直接從中性偏文本風格變成了地道的商務風比寫“use formal tone”管用太多了。Few-shot 的使用也有技巧示例數(shù)量不是越多越好。兩到三個高質量樣例通常就夠了太多會占用上下文且增加成本。示例要覆蓋“邊界情況”不要全給“典型示例”。比如分類任務中給一個模棱兩可的例子和它的處理方式比給三個明顯類別的例子更能提升判斷穩(wěn)定性。示例的格式必須跟期望輸出的格式完全一致不然模型會按示例里的隱含格式輸出反而破壞了你設定的 JSON 結構。3.3 溫度、top_p、top_k、max_tokens參數(shù)跟提示詞是搭檔有一段時間我只盯提示詞完全忽略推理參數(shù)。后來才發(fā)現(xiàn)參數(shù)和提示詞是配套的——同一個提示詞把溫度從 0.7 調到 0.2輸出的穩(wěn)定性和可預測性完全不一樣。我把幾個關鍵參數(shù)按 Agent 開發(fā)視角整理成了一張速查表參數(shù)作用Agent 場景推薦值說明temperature控制隨機性越高越發(fā)散0~0.3需要穩(wěn)定輸出的工具調用、分類、提取越低調越好top_p核采樣替代或配合 temperature0.8~0.9跟 temperature 不要同時大改二選一調節(jié)即可max_tokens限制輸出最大長度按需設置建議設長一點防止長結果被截斷成本可控stop停止符按輸出格式設置輸出 JSON 時可設結束標記方便解析這里最容易踩的坑是為了“更有創(chuàng)造性”把溫度拉很高結果 Agent 開始不聽指令甚至會自己編字段名、編錯誤格式。Agent 的核心訴求是“穩(wěn)定執(zhí)行”不是“妙語連珠”。所以除非你在做文案生成、創(chuàng)意類任務否則溫度控制得越低越好。我還養(yǎng)成了一個習慣改提示詞和改參數(shù)兩條路分開調。如果輸出風格不對先改參數(shù)如果輸出內容不對先改提示詞?；熘淖钪旅隽藛栴}根本定位不到是哪個變量導致的。4. 面向 AI Agent 的提示詞設計這事比單輪對話更講究單獨寫一條好提示詞和給 AI Agent 寫提示詞完全不是一個量級的問題。Agent 場景里模型要自主做決定、調用工具、承擔多輪上下文還要從錯誤里恢復。這就提示詞工程提出了更高要求——每一輪對話里的提示詞都像給一個“帶工具的實習生”下指令說得不到位它會拿斧頭削鉛筆。這個系列叫“AI Agent 學習之路”所以這篇要重點把 Agent 相關提示詞設計的特殊之處拆清楚。4.1 系統(tǒng)提示詞與任務提示詞的分工很多人一開始寫 Agent 會把所有內容塞進一條 system prompt包括“你是誰”“你要做什么”“工具怎么用”“輸出什么格式”“遇到錯誤怎么辦”全堆在一塊。這樣做不是不行但效果通常不好——因為上下文一長模型的注意力就會被稀釋越靠后的內容越容易被淡忘。我更推薦的做法是三層分工系統(tǒng)提示詞System Prompt負責“身份 規(guī)則 工具定義”這一層是長期穩(wěn)定的告訴模型它是誰、有哪些工具可用、行為邊界是什么。任務提示詞Task Prompt負責“本輪目標”每一輪的具體任務描述比如“用戶想查詢訂單狀態(tài)請先調用 get_order_info 工具”。上下文管理Context負責“歷史信息與狀態(tài)”把之前的對話摘要、當前狀態(tài)、中間結果喂給模型讓它能接上上下文。這樣分開之后的好處是改任務需求不用動系統(tǒng)提示詞改工具調用規(guī)則不用動每輪的 prompt整個 Agent 更好維護。而且大部分 Agent 框架LangChain、LangGraph、Spring AI 等都支持分開設置 system 和 user 消息攔的不是技術是思路。4.2 工具調用把“動作”描述成模型能理解的結構Agent 比單輪對話多出來的核心是工具調用。這時候提示詞設計的一個關鍵問題是怎么讓模型知道“什么時候該調用哪個工具參數(shù)怎么填”。如果你只是把函數(shù)的說明貼在提示詞里讓模型“看著用”它大概率會在不該調的時候調、該調的時候不調。更穩(wěn)定的做法是顯式的工具描述結構。我在 LangChain 這類框架里寫工具時除了 function name / description / parameters 之外還會在 description 里補上“觸發(fā)條件”和“忌諱調用條件”。比如tool def get_order_status(order_id: str) - str: 查詢訂單當前物流狀態(tài)。僅當用戶明確詢問訂單/物流/發(fā)貨進度時調用。 觸發(fā)條件 - 用戶提供了訂單號或詢問“我的訂單到哪了” - 用戶提到“發(fā)貨”“物流”“配送”關鍵詞 不要使用此工具的場景 - 用戶只是問“怎么退貨”應調用 return_policy 工具 - 用戶沒有提供訂單號先詢問訂單號 ...這種描述的效果是模型會先做“意圖匹配”再決定調不調用而不是看到關鍵詞就去調。這大幅減少了“錯誤工具調用”這種 Agent 場景里最常見的翻車點。4.3 上下文工程Agent 對話里最容易被忽略的坑提示詞不是只有你寫的那幾行字——對模型來說每一輪對話累積的歷史消息、工具返回的結果、系統(tǒng)預設全都是“隱式提示詞”。這就是為什么很多人發(fā)現(xiàn) Agent 在對話中間開始“失憶”或者輸出偏差不是模型壞了是上下文污染了。我在實際開發(fā)中最常遇到的三類問題歷史消息過長導致注意力漂移對話進行到二三十輪早期信息早就被“稀釋”光了模型只能記住最后幾條消息。解決方案是定期做摘要壓縮把歷史對話濃縮成幾條關鍵事實再塞回去。工具返回的原始數(shù)據(jù)污染指令遵循工具返回一大段 JSON 之后模型的注意力會被這些結構化數(shù)據(jù)帶走反而忽略了“下一步應該做什么”。解決方案是在工具返回前或返回后添加一段“基于以上結果你需要做什么”的指令性文本。用戶的隨意表達帶偏 Agent 方向用戶中途插一句“其實我就是想看看”就可能讓 Agent 偏離原任務。這時候 system prompt 里要有“任務邊界聲明”無論用戶怎么說你的目標是 X如果用戶請求偏離目標請婉拒并重新引導。這就是圈子里經(jīng)常討論的“提示詞工程與上下文工程”的差異——提示詞工程解決“怎么說清楚”上下文工程解決“怎么讓模型持續(xù)保持對目標的聚焦”。做 Agent 光有前者遠遠不夠。4.4 系統(tǒng)提示詞與 Skill/Agent 的區(qū)別別在提示詞里塞代碼我之前看到很多人困惑“系統(tǒng)提示詞工程和 Skill 機制有什么區(qū)別”。簡單說系統(tǒng)提示詞是給模型讀的“說明書”Skill在很多 Agent 框架里指可復用的能力模塊是一段可以動態(tài)插入提示詞里的“專家級文本模塊”。這兩者核心區(qū)別在于靜態(tài)與動態(tài)。系統(tǒng)提示詞是常駐的不管用戶問什么模型都要看到它——適合放身份、安全規(guī)則、核心約束。Skill 類能力模塊則不是常駐的而是按需加載的用戶一問到“幫我寫 Python 代碼”框架才把“Python 專家 Skill”的提示詞動態(tài)注入到當前上下文里。這樣做的好處是省 token、不干擾無關任務、也不容易讓模型“角色混亂”。所以我的建議是不要把什么都塞進 system prompt盡量把領域知識拆成可按需調用的 Skill 模塊。這在 Agent 框架里對應的是 prompt selector / skill loader 這類機制。你越早建立這種模塊化思維后面打量產級 Agent 越輕松。5. 調試提示詞的實戰(zhàn)過程從“答不對”到“穩(wěn)定可用”提示詞看起來是個創(chuàng)作工作實際上是一個工程調試過程。我見過很多人寫提示詞一遍過然后跑一次不行就開始全盤推翻重寫最后越調越亂。我自己早期也這樣后來摸索出一套相對可控的調試方法分享給大家。5.1 先定位是理解錯、執(zhí)行錯還是格式錯當模型輸出不滿足預期時第一步不是改提示詞而是判斷錯在哪一層。我把問題分成三類理解錯模型壓根沒搞懂任務輸出內容答非所問或者方向偏了。執(zhí)行錯模型懂了任務但步驟執(zhí)行得不對比如漏掉了某個條件、沒用上上下文信息。格式錯內容對但輸出格式與下游不兼容比如沒按 JSON 輸出、多了解釋文字。定位方法很簡單把模型輸出和你期望輸出放在一起逐條對照看偏差是出現(xiàn)在“該做什么”還是“該怎么做”還是“該輸出成什么樣”。定位之后再做針對性修改不要一條提示詞從頭改到尾。5.2 拆變量一次只改一個條件提示詞調試最大的坑是“變量混動”。比如你同時改了任務描述、加了示例、又換了溫度參數(shù)結果輸出變好了——你根本不知道是哪個改動起了作用。下次遇到類似問題你無法復現(xiàn)成功經(jīng)驗。正確做法是像做實驗一樣一次只改一個條件其他全部鎖定。比如先保持提示詞不變只把 temperature 從 0.7 調到 0.1觀察穩(wěn)定性變化再保持參數(shù)不變加一個示例觀察格式遵循度。每一步都有明確變量才能形成可復現(xiàn)的調優(yōu)結論。我實際做的時候還會保留一個提示詞版本管理表記錄每次改動的版本號、改動內容、測試結果。Agent 項目跑久了你會感謝這個習慣——否則三個月后你根本想不起來現(xiàn)在這版提示詞是怎么演化來的。5.3 回歸測試提示詞的“用例”意識提示詞也值得寫測試用例。我在 Agent 項目里會維護一組固定的評測輸入每組輸入配上期望輸出斷言可以是解析結果的檢查規(guī)則也可以人工判斷標準每次調整提示詞后都拿這組用例跑一遍回歸。這個習慣救過我很多次——有時候改動會讓 A 場景變好卻悄悄破壞了 B 場景的穩(wěn)定性。用例的覆蓋要比你想的更全面至少包括常規(guī)情況正常需求期望模型按標準流程處理。邊界情況用戶輸入極端簡短、信息不全、類型混亂。禁忌情況用戶試圖讓 Agent 偏離任務目標、跨邊界操作。工具異常工具返回錯誤或空數(shù)據(jù)模型能否合理處理。5.4 常見問題速查表我把實際開發(fā)中最常遇到的幾種提示詞問題整理成一個速查表方便大家直接對照問題現(xiàn)象最可能原因建議手段模型輸出格式飄忽不定未鎖格式或示例缺失在提示詞末尾追加“只輸出 JSON”并按示例鎖結構模型不調用工具工具描述里沒有觸發(fā)條件在工具 description 里寫觸發(fā)條件和不調用的場景多輪對話后失憶上下文太長、信息稀釋定期做對話摘要壓縮關鍵事實前置模型過度發(fā)揮、編造事實CoT 引導過度或約束不足加“只基于提供上下文回答”的強約束調低溫度輸出內容泛化成套話角色和上下文缺失補充角色設定和具體業(yè)務背景解析失敗率高輸出里夾帶解釋字符用 stop 參數(shù)、強制格式、few-shot 模板固化輸出這套速查表不替代調試流程但能幫你快速定位問題的大方向省掉很多盲目試錯。6. 當提示詞撐不住的時候把工程升級成流程提示詞不是萬能的。我見過太多項目在提示詞上死磕到最后一地雞毛——為了一個穩(wěn)定的輸出結果反復堆提示詞內容、堆示例、堆約束最后提示詞長得像一篇論文成本高、維護難還經(jīng)常因為一個小改動引發(fā)連鎖反應。做 Agent 到這個階段需要換個思路把提示詞的一部分職責“卸載”到工程框架里。6.1 識別提示詞的邊界哪些問題適合靠提示詞解決哪些該用代碼解決我的劃分標準很簡單內容層面的事情語氣、角度、詳略、信息組織交給提示詞。流程層面的事情分支判斷、狀態(tài)管理、重試機制、數(shù)據(jù)校驗交給代碼而不是試圖用提示詞“說服”模型永遠不犯錯。舉個例子Agent 的工具調用返回一個 JSON里面有個字段可能缺失。你可以在提示詞里寫“如果字段缺失請這樣處理”來碰運氣但更穩(wěn)妥的做法是在代碼層做字段校驗——缺失就觸發(fā)重試或走兜底邏輯。提示詞負責“生成”,代碼負責“兜底”這個分工應該是 Agent 架構設計的基礎認知。6.2 標準化的下一步提示詞模板 工作流當你的 Agent 從“一個好玩的東西”變成“一個要穩(wěn)定上線的服務”時我特別推薦把核心提示詞做成模板和版本化管理。具體操作上把提示詞中容易變化的部分比如用戶輸入、工具返回結果替換成模板變量再用一個統(tǒng)一的渲染函數(shù)來生成實際請求。這樣提示詞的改動不再散落在代碼里而是集中在專門的 prompt 目錄下做 diff、回滾、審查都方便。再進一步如果你用的框架支持 LangGraph 這類圖狀編排可以把復雜 Agent 拆成“流程節(jié)點 節(jié)點內提示詞”的結構。比如“意圖識別節(jié)點 → 信息收集節(jié)點 → 方案生成節(jié)點 → 復核節(jié)點”每個節(jié)點一個專職提示詞比一個全能的巨型提示詞要可靠得多。這就是為什么現(xiàn)在圈子里都在聊“從提示詞工程到 Agent 工程”的升級——單一的提示詞只是 Agent 的一塊磚流程編排能力才是承重墻。6.3 給 AI Agent 學習之路的銜接建議這是 AI Agent 學習之路系列的第二篇如果你想繼續(xù)深入我的個人建議是把提示詞掌握到“能穩(wěn)定解決單點任務”的程度后趕緊往三個方向進階——一是理解 Agent 框架內部是怎么把提示詞、工具、記憶組合起來的二是學會用 LangGraph 這類編排工具做一個需要多步驟決策的真實 Agent三是開始關注上下文工程和評估體系這才是 Agent 能不能落地到業(yè)務里的分水嶺。不要沉迷于“調一個超神提示詞”的體驗那會讓你誤以為提示詞就是 Agent 的一切。等你看過真實業(yè)務中那些復雜的用戶輸入、混亂的工具返回、以及模型時不時的不確定性你會明白提示詞是對模型的“第一層約束”工程架構是“第二層約束”兩者配合才能做出真正耐用的 Agent。我在實踐中最大的體會是好提示詞不是寫出來的是“改出來的”。沒有任何人第一版就能寫出完美的提示詞但你只要建立結構化的寫法、有方法地調試、敢把不穩(wěn)定的部分交給工程兜底這條路其實比大多數(shù)人想象得更快。下一篇我會繼續(xù)往 Agent 框架走把 LangChain 和 LangGraph 里提示詞如何與工具、記憶、流程真正串起來這件事講透——到時候你會發(fā)現(xiàn)提示詞工程積累下的這套“寫清楚、拆變量、做回歸”的習慣幾乎是后面所有 Agent 開發(fā)動作的地基。