---
title: "別再把 SOP 直接丟給 AI Agent：用 RFC 2119（MUST/SHOULD/MAY）精確控制 Agent 行為"
description: "把人類 SOP 直接塞給 LLM，Agent 常常一次跑對、三次翻車。這篇示範用 RFC 2119 的 MUST、SHOULD、MAY 改寫 System Prompt 與 Agent Skill，劃清硬性約束、強烈建議與自主裁量，並附三個落地原則。"
url: https://stephen.taipei/articles/rfc-2119-prompt-engineering-agent
author: "Stephen Chuang"
date: 2026-10-08T13:18:28+08:00
tags: [ai-agents]
lang: zh-TW
---

# 別再把 SOP 直接丟給 AI Agent：用 RFC 2119（MUST/SHOULD/MAY）精確控制 Agent 行為

很多團隊在做 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）一目了然：

```markdown
## 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。