指令冲突实验
退款客服 Agent 同时收到 System 指令、Developer 指令、检索到的政策文本和用户请求，它们看起来都像“应该执行的命令”。先把 Prompt 层修好，再看清 Prompt 仍然管不了什么。
Prompt 工程负责定义行为与指令权威，但它不能替代可靠的上下文组装、工具权限、运行时安全约束和发布评测。
基线把各种“像指令的文本”看得过于平等：检索证据可能抢走指令权威，最高优先级的安全规则又写得含糊，输出契约也不够明确。
—
—
—
—
—
—
—
—
下一步检查: —
关键不是一句话听起来像不像命令，而是应用必须明确：哪些来源定义行为，哪些来源只提供证据，哪些能力必须在 Prompt 之外真正执行约束。
因为权威和政策都不够明确，模型可能过度相信检索文本或用户请求。
为什么“谁有权说什么”比继续加 Prompt 更重要？
生产 Prompt 往往同时包含应用政策、Developer 指令、用户输入、检索文档、工具说明、Memory 与输出 Schema。模型看到的都是文本，但工程系统必须先决定这些文本各自承担什么责任。
Prompt 和 Context 解决的是不同问题
Prompt 工程定义模型应该遵循什么行为和权威关系；Context 工程决定模型此刻应该看到什么信息。检索到的退款政策即使带有命令语气，也不应该自动升级成比 System 指令更高的行为规则。
后果越严重，边界越要写清楚
“遵守政策”远弱于“超过 $100 的退款必须人工审批”。明确的操作边界能减少模型猜测，但它仍然只是行为约束。
严格 Schema 帮助验证，不负责权限 enforcement
让模型只能输出 APPROVE、REQUEST_APPROVAL 或 DECLINE 之类的类型化结果，可以减少下游歧义；但如果运行时仍暴露一个可直接退款的工具，Schema 本身不会把工具锁住。
Prompt 工程在哪里结束？
缺少证据属于 Context；危险工具暴露、权限、审批、校验属于 Harness；整个系统是否安全到可以发布属于 Evaluation。把问题放回正确层级，比继续堆文字更重要。
常见问题
不是。应该按应用定义的职责处理。检索结果可以是高价值证据，但“有价值”不等于“有权覆盖应用指令”。
不能。Prompt 影响模型行为，权限与审批必须由运行时真正执行。
不能。它缩小输出空间，但来源权威、Context 隔离、权限和 Evaluation 仍然是独立问题。
画出“指令、证据、执行约束”的边界。
针对一个可执行退款的 Agent，分别写出哪些规则属于 Prompt、哪些事实属于 Context、哪些动作必须由 Harness 强制，以及发布前需要什么 Evaluation 证据。