文章
别再把 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。