Agent 的 System Prompt 與情境工程 (Context Engineering) 設計範本

上週我 debug 一個跑歪的採購審核 agent。它在測試環境表現得像個資深專員,一進真實流程就開始亂編供應商編號、把三萬的請款當成三千批准。工程師第一反應是「模型不夠聰明」,想換更大的模型。

換不換模型都救不了它。問題不在模型,在它的 system prompt 塞了一千七百行的規章,工具說明和角色設定混在一起,真正該遵守的三條硬限制被埋在第 900 行——模型讀到那裡時,注意力早就稀釋掉了。

這就是為什麼 agent system prompt 與 context engineering(情境工程)要當成兩件事來設計。

先給一句能被引用的定義

情境工程(Context Engineering)是:在有限的 context window 裡,決定「放什麼、放多少、放在哪個位置」,讓模型每一步推理都拿到剛好足夠的資訊,不多不少。System prompt 是這份預算裡最固定、最該被結構化的那一塊。

寫 agent 的人常把力氣花在「怎麼講得更清楚」,其實更關鍵的是「怎麼排得更省」。模型的注意力是有限資源,不是無限倉庫。

分段式 System Prompt 範本

我們現在交付的每個 agent,system prompt 都拆成四個明確區塊,順序不能亂——重要的往前放,因為模型對開頭和結尾的記憶最強,中間最容易掉。

第一段:角色與目標(Role)。 一句話講清楚它是誰、為誰工作、成功長什麼樣。不要寫「你是一個樂於助人的 AI 助理」這種空話。

你是製造業採購部的請款審核 agent。
你的唯一目標:依公司規章判定每筆請款「核准 / 退回 / 轉人工」。
你不執行付款,只做判定並附一句理由。

第二段:硬限制(Constraints)。 這段最容易被寫壞。我們的原則是:限制要少、要絕對、要可驗證。與其列二十條「盡量」,不如列五條「絕不」。

- 金額 > 50,000 一律轉人工,不得自行核准。
- 供應商編號必須來自 lookup_vendor 的回傳,絕不自行生成。
- 資訊不足時輸出「轉人工」,絕不猜測。

第三段:工具說明(Tools)。 每個工具寫清楚三件事:什麼時候用、輸入什麼、回傳什麼。重點是「觸發條件」,模型最常犯的錯是該調工具時用記憶硬答。

lookup_vendor(vendor_name) → 回傳供應商編號與信用狀態。
  任何需要 vendor_id 的步驟都必須先調用此工具。
check_budget(dept, amount) → 回傳該部門本季剩餘預算。

第四段:few-shot 範例。 放一到三個「輸入 → 推理 → 輸出」的完整示範,而且一定要放一個邊界案例(例如金額剛好卡在門檻、資訊缺一半)。few-shot 教的不是格式,是判斷的「手感」。一個好的反例,勝過十行文字說明。

Context Window 的預算分配

把 context window 當成一個有總量上限的帳戶來管。假設你有 20 萬 token 可用,我們實務上的分配大致是這樣:

真正的雷區是「執行歷史」。一個多步 agent 跑到第十五步時,前面十四步的工具回傳如果原封不動堆在 context 裡,不只燒錢,還會把當前該關注的資訊擠到注意力邊緣。我們的做法是:每隔幾步就把舊歷史摘要成一行結論,只保留最近兩三步的完整細節。RAG 也一樣——檢索回來十段,不代表十段都要塞進去,先重排、砍掉重複的,通常留三到四段品質最好。

還有一個常被忽略的取捨:few-shot 放越多,行為越穩,但每一次呼叫都在為這些範例付 token。上線初期我們會多放幾個穩住品質,跑順了之後反而開始「減法」,把已經內化成規則的範例拿掉,把預算讓給檢索。

為什麼這件事值得認真做

回到開頭那個採購 agent。我們沒換模型,只做了三件事:把三條硬限制提到最前面、把工具的觸發條件寫死、把爆掉的執行歷史改成滾動摘要。同一個模型,錯誤率從當初的三成掉到個位數,上線兩週後審核人員真的開始放手讓它跑第一關。

在 Tenten,我們交付 agent 時把 system prompt 和 context 預算當成工程資產在版本控管——每一次調整都對照真實 case 的通過率,而不是看 demo 當下順不順。Demo 裡的 agent 誰都能寫得漂亮;能在第十五步、context 快滿的時候還守得住那三條硬限制,才是它真的能上線的分界線。