Agent 與結構化輸出提示詞實戰

現在的 LLM 很會聊。OpenAI、Anthropic 這類模型，已經能吃下 128k、200k，甚至 1M tokens 的上下文。聽起來很猛，但真的上線後，你會發現它們一樣會亂跑。

說白了，提示詞工程到了生產環境，就不是作文比賽。它更像控制系統。你要管推理、記憶、輸出格式，還要管 agent 會不會自己繞圈圈。

這篇主題很對味。Codefinity 的文章把重點講清楚了。難的不是把 prompt 寫長，而是讓它撐得住工具呼叫、長歷史紀錄，還有機器對機器交接。

Prompt 不是文案，是介面契約

很多團隊一開始都會犯同一個錯。把 prompt 當成「再多講一點」就會變好。實際上，prompt 比較像 API 規格。它定義角色、邊界、輸出形狀，還有出錯時怎麼收斂。

你在 notebook 裡測得很順，不代表進到產品還能活。聊天紀錄一長，指令就被淹掉。工具回傳一亂，模型就開始瞎補。JSON 格式看起來像樣，解析時卻整包炸掉。

講白了，這不是模型不聰明。是你沒有把失敗模式先想好。做 LLM 系統，prompt 要先想成合約，再想成指令。

• 長上下文會稀釋指令權重
• 推理需要明確流程，不是空話
• 結構化輸出要有 schema
• Agent 要有停止條件

這裡的核心思路很實用。你要先定義輸入，再定義輸出。中間要有錯誤處理。這很像寫後端 API，只是呼叫方變成模型。

如果你做過資料管線，就會懂這種痛。上游一個欄位歪掉，下游整串報錯。Prompt 也是一樣。你不把邊界寫清楚，模型就會用自己的方式補洞。

推理要有骨架，不能只靠感覺

推理提示詞最常被提到的，就是 chain-of-thought。2022 年那篇 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models 很有名。它證明一件事。模型在多步驟任務上，先想再答，通常比較穩。

但「Let's think step by step」不是萬靈丹。這句話對簡單算術有用。可是一到產品環境，就太鬆了。你不能只叫模型想清楚，還要告訴它怎麼想、想完怎麼收、哪些內容不能直接吐給使用者。

所以實務上會分成幾種做法。零樣本 CoT、少樣本 CoT、scratchpad 分離、self-consistency。它們不是互斥，而是不同風險等級的工具。

“Let’s think step by step.” — Chain-of-Thought Prompting Elicits Reasoning in Large Language Models

這句話紅，不是因為它神奇。是因為它很直白。它把模型從直接回答，拉到先分解問題。可是如果你把思考過程原封不動丟給使用者，常常會出現自我打架，或是把半成品答案直接吐出來。

Self-consistency 就更像工程手法。你不是只問一次，而是抽 3 到 5 次。再看哪個答案出現最多。成本會上升，但在高風險任務上，這筆錢通常比錯答案便宜。

• 零樣本 CoT 常用「一步一步想」當觸發詞
• 少樣本 CoT 會放範例，通常更穩
• scratchpad 可把推理和最終輸出分開
• self-consistency 常抽 3 到 5 次

我覺得這裡最重要的，不是技巧名稱。是你要知道任務風險。算帳、分類、資料抽取、客服回覆，對推理的要求都不同。不要用同一種 prompt 打天下。

如果任務錯一次就很痛，像金流、法務、醫療摘要，那就別省。多做一步驗證。多跑一次 sampling。這種成本，通常比事後補救低很多。

長上下文很大，不代表很穩

現在很多模型都能吃超長上下文。可是容量大，不等於記得牢。研究常提到「lost in the middle」效應。意思是模型對開頭和結尾比較敏感，中間那段容易被忽略。

這件事很煩。因為很多團隊以為塞進 100k tokens 就萬事 OK。其實不是。你只是把問題從「放不下」變成「放進去卻看不見」。

所以 prompt 排版很重要。關鍵指令不要只放最前面。最好在結尾再重複一次。段落標記也很有用。模型需要清楚知道，哪些是規則，哪些是資料，哪些是當前任務。

另一個實用招式是漸進摘要。不要每輪都把整段對話重塞。把已完成的內容壓成摘要，只保留最近幾輪完整歷史。這樣比較省 Token，也比較不會把模型搞混。

還有一個老問題，現在還是很常見：prompt injection。你從文件、網頁、工具回傳抓到的內容，可能藏了指令。模型如果沒被明確提醒，就可能把那些內容當成你的要求。

• 關鍵指令要在開頭和結尾都出現
• 文件和工具輸出要用明確分隔符
• 歷史紀錄要做 rolling summary
• 外部內容要標成資料，不是指令

這裡很像資安問題。你不能假設外部資料是乾淨的。尤其是 RAG、agent、browser tool 這些場景，模型看到的每段文字都可能是風險點。

如果你有做過客服知識庫或內部搜尋，就知道這坑很深。資料來源越多，錯誤注入的機會越高。Prompt 不是保護罩，但它至少能把邊界畫清楚。

結構化輸出是合約，不是願望

很多人會直接跟模型說「請回 JSON」。然後就開始祈禱。這種做法很危險。因為 downstream 系統要的是可解析物件，不是「看起來像 JSON」的文字。

比較好的方法，是 schema-first。先告訴模型欄位名稱、型別、允許值、空值規則，再讓它生成。這樣模型比較不會自己加欄位，也比較不會跑去寫散文。

工具也越來越成熟。像 Outlines、Instructor，都在做受限生成。OpenAI Structured Outputs 也把這件事往 API 層推進。這些做法的共同目標很簡單：不要等輸出錯了才補救，而是直接減少錯輸出的機會。

對抽取流程來說，這差很多。你只要遇到一次壞掉的 JSON，整批 ingestion 就可能卡住。那不是「小 bug」。那是排程、重試、告警一起炸。

還有一個常被忽略的點，是空值處理。模型很愛亂猜。當欄位不知道時，請明說用 null。不要叫它硬填。猜錯的資料，比空值更難清。

• Schema-first 先定欄位，再做生成
• 受限生成能降低 parse failure
• 未知值用 null 比亂猜安全
• 複雜巢狀結構可分階段生成

如果要比競品思路，差別也很明顯。純 prompt 派靠文字約束。框架派靠 wrapper 和 validator。API 原生方案則把格式約束下沉到模型介面。後兩者通常更穩，但也更綁平台。

所以選法很現實。你如果在乎可攜性，就多用 schema 與後處理。你如果在乎成功率，就看平台原生支援到什麼程度。沒有哪個方案永遠最好，只有哪個比較適合你的風險。

Agent 需要邊界，也需要停損

Agent prompt 跟單輪 prompt 差很多。單輪只要回答一次。Agent 則要面對工具呼叫、部分失敗、目標變動，還有重試循環。這種場景下，prompt 不只是說明書，還是操作規則。

系統 prompt 最好先定義三件事。角色是什麼。可以用哪些工具。什麼情況下要停。少了這些，agent 很容易一直重試同一個壞步驟。你看 log 會很想罵人。

如果你用過 LangChain 或 LlamaIndex，大概懂我在說什麼。工具鏈一長，錯誤就會開始連鎖。沒有 termination logic，agent 會像卡住的客服，永遠說「我再試一次」。

比較合理的做法，是定義 done 的條件，限制 retry 次數，還有明確要求每一步只拿目前需要的資料。這樣 agent 才不會為了看起來很忙，亂抓一堆不相關資訊。

你可以把常見 prompt 類型分開看。這樣比較不會混用。

• 單輪 prompt：追求一次輸出
• 推理 prompt：追求多步驗證
• Agent prompt：追求工具操作與停止
• 結構化輸出 prompt：追求可解析格式

這個分類很實際。因為很多失敗，不是模型太差，而是你把不同任務混成同一種 prompt。叫它既要推理、又要聊天、又要吐 JSON、還要自己收尾。這種要求，連人都會當機。

所以我會建議，先把任務拆乾淨。每一類 prompt 都有自己的目標。不要幻想一份萬用 prompt 可以通吃所有場景。

背後其實是整個產品設計問題

Prompt engineering 會變難，不是因為大家突然不會寫字。是因為 LLM 已經進到產品核心。以前你只要做 demo。現在你要面對資料品質、成本、延遲、解析失敗，還有安全問題。

這也解釋了為什麼很多團隊最後會走向流程化。先做分類，再做抽取，再做驗證，再做回寫。每一段都要有清楚的輸入和輸出。這種設計，看起來很土，但通常更穩。

本地模型也會遇到同樣問題。像 vLLM 這類推理服務，把吞吐量和部署彈性拉高了，但 prompt 的規格感一樣不能少。模型換了，工程問題還在。

如果你是開發者，我覺得現在最值得做的，不是再追新 prompt 技巧。是回頭檢查你現有系統。你的 prompt 有沒有明確角色？有沒有輸出 schema？有沒有 stop rule？有沒有把外部資料當成不可信內容？

很多時候，答案會很尷尬。因為真正脆弱的地方，往往不是模型，而是你沒寫清楚的那幾行字。

先把一個高價值 prompt 修好

如果只能做一件事，我會先審一個高價值 prompt。看它有沒有推理結構，有沒有上下文策略，有沒有輸出合約，也有沒有停損條件。少一項，都可能在上線後放大成事故。

我也會建議團隊，把 prompt 當成版本化資產管理。別只丟在前端字串裡。要能 review，要能測試，要能回滾。這樣才像工程，不像賭博。

接下來幾個月，真正拉開差距的，應該不是誰會寫更長的 prompt。而是誰能把 prompt、schema、工具呼叫和驗證流程串成一套穩定系統。你如果現在還在手動祈禱 JSON 不會壞，老實說，是時候補課了。