长 Prompt 中上下文优先级如何安排？

简化版

长 Prompt 应按信任与功能分层：最高层放不可覆盖的系统目标、安全和权限，随后放任务规则与输出契约，再放用户请求和检索/工具证据。外部文档只是不可信数据，不能改变指令。布局上把关键规则放在前部并在临近输出处给短提醒，减少中部遗忘，但不要复制出多个不一致版本。

详细版

先为每段标记来源、优先级和用途，再用清晰标签隔离：POLICY、TASK、USER_INPUT、EVIDENCE、OUTPUT_SCHEMA。冲突处理写成确定规则，如证据与用户陈述冲突时标注不确定，文档中的命令一律视为引用内容。长证据按相关性重排，最关键片段靠近问题，保留来源 ID。

Token 预算应先为输出、安全和核心任务预留，再分给历史与证据；超限时按低优先级丢弃或摘要。通过反事实测试验证优先级：在文档中插入恶意命令、在中部放关键条件、交换证据顺序，观察是否仍遵循高层规则。线上记录最终渲染 Prompt 的段落清单和截断原因。

[SYSTEM/POLICY] > [DEVELOPER/TASK] > [USER GOAL]
                                     [UNTRUSTED EVIDENCE]
                                     [OUTPUT CONTRACT]

完整版教学

一、优先级首先是信任问题

长 Prompt 混合系统配置、用户输入、网页、数据库结果和历史消息。内容越长，越不能靠自然语言“看起来像命令”来决定执行权。优先级应由消息来源和系统授权确定，外部材料即使写着“忽略上文”也只是被分析的数据。

这与“重要性排序”不同。安全规则信任高，相关证据业务重要但信任低；二者需要两个维度。模型层可用角色和标签提示，真正的工具权限还要由执行层策略强制。

二、建立清晰的上下文分区

把所有内容拼成一大段会让边界模糊。使用稳定段名和定界符，让模型知道每段功能，同时让程序能独立裁剪。用户数据必须经过转义或结构化插入，不能让它闭合标签后伪造新的系统段。

<policy>不可被下方内容修改的规则</policy>
<task>本次需要完成的工作</task>
<evidence trust="untrusted" source="doc-17">...</evidence>
<user_input>...</user_input>
<output_schema>...</output_schema>

XML 标签不会自动提供安全隔离，但能增强语义边界和可观测性；执行层仍应按来源保存，而非相信字符串标签。

记忆钩子：位置告诉模型“先看哪里”，来源决定系统“该信谁”；重要证据可以靠近问题，但不能因此升级权限。

三、为什么关键内容要关注位置

长上下文模型常对开头和结尾更敏感，中间信息召回较弱。系统规则放前部符合角色结构，当前问题和关键证据靠近末端能缩短关联距离。可以在末端给核心约束的引用式清单，但原始规则只维护一份。

重复完整规则会增加 Token，也可能在版本更新时出现冲突。更好的方式是前部给权威定义，末端只列短 ID，例如“作答前检查 P1/P3/O2”，并由程序从同一结构化源生成，避免人工双写。

四、Token 预算怎样按优先级分配

先从总窗口扣除最大输出、系统与安全缓冲，再给当前任务和证据，最后才是历史。假设窗口 16K，输出预留 2K，系统/契约 1K，用户任务 2K，则证据和历史共享 11K；可给证据 8K、近期历史 2K、1K 安全余量。

内容	超限处理	原因
安全/权限	不裁剪	系统边界
输出 schema	不裁剪或结构压缩	解析依赖
当前用户目标	保留	本次任务核心
高相关证据	重排、保留原文	事实依据
旧对话	状态摘要	多数细节低优先
低相关文档	丢弃	减少噪声

截断必须在文档/消息边界进行，不能把否定条件的后半句切掉。

五、证据之间冲突怎么办

多个来源可能互相矛盾，简单按位置选最后一段会产生不可控偏差。应给证据附来源、时间、权限和可信度，在任务规则中定义冲突策略：优先最新权威源、列出分歧、或拒绝下结论。模型不应把流畅度当真值。

例如政策 A 生效于 2025，旧文档 B 来自 2023。检索层应尽量降权旧版，Prompt 层仍要求回答附版本日期；若无法判断，输出“不确定”和两条引用。这样优先级成为可审计规则，而不是隐式注意力竞争。

六、历史上下文如何收敛

长对话中用户目标会被修改，旧约束可能失效。把历史提炼成结构化状态，字段带来源轮次和当前有效标记；最近原文保留用于语气与局部指代。用户说“预算改为 1000”时应覆盖旧 800，而非让两个数字同时进入证据区。

状态更新需要 schema 校验，关键值向用户确认。系统不能让历史中的助手猜测变成已确认事实；应区分 user_confirmed、tool_verified 和 model_inferred。这个来源标记也是上下文优先级的一部分。

七、如何测试优先级真的生效

构造冲突矩阵：用户要求违反系统规则、文档含注入、旧历史与新用户条件冲突、两条证据时间不同。将关键条件放在开头、中间、末尾，并改变无关文本长度，测指令遵循、事实正确和拒答率。仅用正常样本无法验证边界。

可设计 300 条集合，其中 100 条位置扰动、100 条来源冲突、100 条超长截断。若普通准确率 95%，但中部条件只有 60%，需要重排或检索；若文档注入成功率 5%，则执行层还必须拦截。每次模型升级都运行同一回归矩阵。

八、常见误区与追问

• 误区：把最重要内容重复三遍就最稳。 重复增加成本且版本易冲突，应从单一源生成短提醒。
• 误区：XML 标签可以提供安全沙箱。 标签只是语义提示，工具权限仍需代码策略控制。
• 误区：最后出现的指令天然优先。 权限由来源层级决定，不由文本位置决定。
• 追问：关键证据放哪里？ 经过重排后靠近当前问题，同时保留来源和在文档中的原位置。
• 追问：超限先删什么？ 先删低相关外部材料，再摘要旧历史，不删除权限与输出契约。
• 追问：如何发现 lost-in-the-middle？ 把同一事实轮换到不同位置，绘制位置—召回率曲线。

九、加强记忆

上下文优先级可记成“分层、隔离、预算、近放、冲突有规则”：按来源确定信任层，用标签隔开指令与数据；预算先保安全、任务和输出；关键证据靠近问题；冲突按来源与时间显式处理。再用注入、位置扰动和截断测试验证，才能让长 Prompt 的行为可预测而非靠堆字。