组织、顺序与信任分区
本节目标
将策略、任务、状态、证据与输出合同分区，并通过稳定顺序降低混淆与缓存失效。
一个推荐的逻辑布局
不同 API 的角色和内容块形式不一，但可维持以下逻辑顺序：
- 稳定策略：任务职责、安全边界、工具使用规则。
- 输出合同：schema、允许的拒绝状态和引用规则。
- 少量稳定示例：只保留已证明有帮助的例子。
- 结构化任务状态：目标、已完成步骤、未决问题、用户确认。
- 带来源证据：每段有 ID、信任级别和日期。
- 当前输入：本轮问题或事件。
稳定、重复的前缀放前面，动态内容放后面，通常也更利于某些供应商的前缀缓存。Google 当前长上下文指南还建议在长材料之后放查询，但这属于特定模型系列的建议，不是跨模型定律；应通过位置评测确认。工具定义本身也占上下文，工具很多时应按需发现或只加载当前步骤需要的 schema。
分区示例
<policy>……由应用维护的规则……</policy>
<state>{"goal":"比较两项政策","open_questions":["适用地区"]}</state>
<sources>
<source id="policy-A" trust="official" date="2026-04-01">……</source>
<source id="forum-B" trust="unverified">……</source>
</sources>
<user_request>……当前请求……</user_request>标签帮助模型理解，但真正的权限边界仍在应用层。forum-B 不能因为出现在 <sources> 中就获得调用工具、改写策略或访问秘密的能力。
顺序与冲突
长文本中的信息位置可能影响表现。对关键约束可在稳定策略和最终核对清单中简洁重申，但不要复制多份略有不同的规则。来源冲突时，在元数据中标记版本与优先级，并要求输出说明冲突；程序可根据业务规则预先淘汰失效版本。
缓存是性能机制，不是上下文选择机制。以 OpenAI 当前文档为例，缓存匹配基于重复前缀；把动态字段插到前缀中间会破坏后续匹配。即使命中缓存，这些 token 仍属于模型可见上下文，缓存也不会修复过期、越权或冲突信息。
常见错误
- 将当前日期、用户输入等动态内容放入可缓存前缀，导致命中率低或复用错误。
- 先放大量证据，任务问题埋在中间且不清楚。
- 同一事实在对话历史、摘要和结构化状态中出现三种版本。
- 为节省 token 删除来源 ID，导致回答不可审计。
练习与自测
把一段混合了系统规则、用户问题、网页正文和 JSON 输出要求的提示拆成六个分区。为每段标注所有者、可信度、更新频率和最大长度。自测：某网页尝试更改输出 schema 时，哪一层会拒绝？
掌握检查
- 我能把策略、合同、示例、状态、证据和当前输入分开，并标注所有者。
- 不可信证据无法借助标签或消息位置获得改写策略、调用工具的权限。
- 稳定前缀与动态后缀的布局有缓存和位置评测证据，而不是凭感觉复制模板。
- 工具定义和工具结果都进入预算；不需要的工具不会全部常驻窗口。
- 冲突来源保留版本与优先级，程序不会让模型静默猜一个。
下一步
进入 对话历史、状态与记忆，管理跨轮次变化。
参考资料
- OpenAI：Prompt caching（访问于 2026-07-21）
- Anthropic：Effective context engineering for AI agents（访问于 2026-07-21）
- Anthropic：Manage tool context（访问于 2026-07-21）
- Google：Long context（访问于 2026-07-21）