文章
別再把 SOP 直接丟給 AI Agent：用 RFC 2119（MUST/SHOULD/MAY）精確控制 Agent 行為
把人類 SOP 直接塞給 LLM，Agent 常常一次跑對、三次翻車。這篇示範用 RFC 2119 的 MUST、SHOULD、MAY 改寫 System Prompt 與 Agent Skill，劃清硬性約束、強烈建議與自主裁量，並附三個落地原則。
· 3 分鐘閱讀
很多團隊在做 Agent 落地時，最常踩的坑就是把整份 Word/Notion 的「人類 SOP」直接塞給 LLM，期待它能自動搞定。結果往往像買彩券：一次跑對、三次翻車。
問題不在模型能力不夠，而是人類 SOP 隱含大量「默會知識（Tacit Knowledge）」。人腦會自動判斷「金額小於 500 元不用簽核」、「這步遇到報錯可以先略過」；但對 LLM 來說，非結構化的文字沒有強弱邊界，它只能自由發揮。
要讓 Agent 行為具備確定性，第一步不是換更大的模型，而是引入網路協定規格的經典標準：RFC 2119 語意分級。
先講結論：只把合規、資安與核心 Schema 標成 MUST，其餘邊界交給 SHOULD 與 MAY；高風險節點則交給人工審核。
為什麼是 RFC 2119？#
在撰寫 System Prompt、Agent Skill 或 Workflow Rule 時，模糊的「請注意」、「最好能」、「盡量」對模型來說毫無邊界約束力。改用明確的動詞層級，能強制劃清決策界線。
MUST / REQUIRED：硬性約束，零妥協#
- 語意：絕對不可跳過、無例外條件。
- 適用場景：資料驗證、安全性檢查、Schema 輸出規範、高風險攔截。
- 範例：「在調用發票 API 前，
MUST 先驗證員工編號是否存在；若回傳為空，MUST 立即中斷執行。」
SHOULD / RECOMMENDED：強烈建議，但允許合理偏離#
- 語意：除非有非常充分的上下文理由，否則必須遵守；若偏離，Agent 必須交代推理依據。
- 適用場景：演算法策略挑選、分類偏好、重試邏輯。
- 範例：「針對客戶諮詢類 Ticket，
SHOULD 優先指派給第一線客服；但若涉及金流爭議，允許改派財務審核組。」
MAY / OPTIONAL：自主選配，完全裁量#
- 語意：模型可依據當前上下文資源或 token 預算自行決定是否執行。
- 適用場景：補充說明、延伸思考建議、可選的日誌格式。
- 範例：「在產生處理摘要時，
MAY 附加 1～2 個類似案件的歷史參考 Ticket ID。」
落地實踐三原則#
1. 拒絕滿篇 MUST，保留 Reasoning 空間#
把所有規則都寫成 MUST，等於把 LLM 當成 Deterministic Compiler 來用，容易引發規則互衝或 Context 膨脹後的邏輯死鎖。只將「合規、資安、核心 Schema」標記為 MUST，其餘邊界交付 SHOULD。
2. 搭配結構化 Markdown 區塊#
將 Prompt 拆解為下面四個區塊，讓語意強度的作用域（Scope）一目了然：
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. 高風險節點綁定 Human-in-the-loop#
當條件觸發關鍵 MUST 邊界（如單筆金額 > $5,000、Admin 權限異動）時，Agent 的唯一 MUST 行為就是「暫停管線，等待人工審核按 OK」，而非替人類代作決策。
結論：從 Demo 玩具走向 Production-Ready#
把 Agent 當成一條工業生產線，而非單一全能的「打雜超人」。透過 RFC 2119 建立行為契約，你的 Agent 才能真正從 Demo 玩具，走向生產級的 Production-Ready。