Prompt 与上下文工程：OpenAI、Anthropic 的方法，版本发布与优化实验

一次回答变差，原因可能是指令含糊，也可能是检索资料过期、历史冲突、工具定义重叠，或模型版本改变。Prompt 是指令设计；上下文工程是管理模型在某一轮实际收到的全部信息。 生产优化需要同时管理内容、预算、权限和版本。

本文依据截至 2026-10-11 的官方资料与原始研究。厂商建议有模型和任务边界；后文的发布流程与实验矩阵是工程推导，不是官方规定的统一流程。

OpenAI：明确目标、固定版本，按模型类型调整方法

OpenAI Prompt engineering^[1]强调指令层级、清楚的输入组织、模型快照与评测；当前文档也建议把生产 prompt 纳入应用代码，以代码审查、类型化输入、测试与正常发布流程管理。不要把旧版教程中的平台 prompt 对象当作永远稳定的接口。

Reasoning best practices^[2]对推理模型建议目标明确、约束直接，并避免机械要求“逐步展示思考”。工程上更有用的输出契约是：结论、可核对证据、计算结果、前提和不确定项。可解释输出与披露完整内部推理不是一回事。

因此，同一个 prompt 模板不能不加验证地迁移到所有模型。新模型可能需要更少示例，也可能在工具、格式或拒绝行为上发生变化；固定模型版本只减少漂移，不能保证每次输出完全相同。

Anthropic：优化每一轮的信息选择

Effective context engineering^[3]把系统指令、工具、外部资料和历史都纳入上下文管理，讨论按需读取、压缩、笔记与分工。它的共同目标是让当前决策看到高价值信息，而不是把可获得的资料全部塞入窗口。

“按需读取”可以是先提供文件路径、来源 ID 或摘要，需要时再取原文。这会减少无关 token，也可能增加工具轮次与等待。已知短资料可预加载；探索范围大且不可预测时按需检索更合理。选择应由任务成功率和延迟一起验证。

研究边界：长窗口不等于稳定利用所有位置

Lost in the Middle^[4]在其多文档问答与键值检索实验中观察到信息位置影响表现：相关信息位于中间时，部分被测模型更容易失误。它提供了“容量与有效利用不同”的证据，但不能证明所有当代模型在任何任务上都有同样程度的位置偏差。

可复现实验比口号更有用：在同一任务中保持证据内容与长度近似不变，只改变关键证据的位置；再比较不同干扰量、模型和上下文长度。若发现特定任务退化，可优化证据排序与压缩，而不是直接宣布“中间不能放信息”。

工程推导：把一次上下文构建写成可审查的流水线

图 1 · 上半部分管理这一轮看见什么，下半部分管理哪些版本可以上线。两者共享证据与配置版本。

一次上下文构建可以按以下顺序实现：

1. 确定任务和身份：建立租户、角色、目标、权限与预算；这些来自可信应用状态。
2. 筛选候选信息：从授权知识库、历史与工具结果中召回，保留来源 ID、版本与时间。
3. 去重和解决冲突：合并重复段落；新旧规范冲突时保留生效范围，不让模型自行猜版本。
4. 分配预算：为输出与必要推理预留空间；给证据、历史和工具定义分别设预算。
5. 组装输入：区分开发者指令、用户请求与外部资料；保留引用定位和截断说明。
6. 记录构建依据：保存配置 ID、选中的来源 ID、计数和删减原因；敏感正文按必要性留存。

外部页面或工具结果中的命令属于待分析数据，不应提升为系统指令。权限判断在读取与执行侧完成；“请不要泄露”不能代替真实授权过滤。

一个通用模板可以这样写，字段是应用约定而非某家 API 的完整请求：

任务：依据授权资料回答具体问题，必要时请求补充信息。
成功条件：关键结论有可解析的来源 ID；缺证据时明确标记。
限制：工具仅在列出的用途与权限内使用；高影响动作需审批。
输入区：用户请求、资料片段、已确认的工具结果分别标识。
输出区：结论、支持证据、适用前提、不确定项。

预算与记忆：删减要知道丢掉了什么

输入预算不是简单地“窗口大小减去用户输入”。工具定义、检索片段、历史、图片和输出上限都可能参与；不同 API 的计数与推理 token 语义不同，需要按厂商契约计算。详见token 预算与核算。

历史压缩优先保留未完成目标、关键约束、已确认事实、待决问题和来源指针。工具大结果可放受控存储，再提供可回读引用；压缩后的摘要不是业务事实的唯一存储。

OpenAI SDK Sessions^[5]提供跨运行的对话历史管理。它可以帮助恢复会话，但业务审批、工具副作用和长期记忆的权限仍需各自的契约。原始记录与压缩摘要的关系，以及删除传播，见上下文与记忆管理。

版本管理：发布的是一组行为配置

以下是本文建议的配置清单示例，不是已上线系统的版本数据：

{
  "release_id": "agent-release-2026-10-11-r3",
  "prompt_revision": "prompt-r8",
  "model_snapshot": "pinned-provider-model-version",
  "tool_schema_revision": "tools-r4",
  "retrieval_revision": "index-r12",
  "policy_revision": "policy-r6",
  "eval_dataset_revision": "eval-r9"
}

版本号对应可恢复的内容或配置快照，不能只有字符串却找不到历史。原始文档删改、embedding 模型变更、工具参数与权限策略变化，都可能影响同一个 prompt 的结果；单独回滚 prompt 往往恢复不了旧行为。

应用可将这些配置写进 Git 或受控配置仓库，以不可变 release_id 加路由指针发布。模型快照不可用时，需要定义替代策略并重新评测，不能承诺永远重放完全相同的输出。

从离线到灰度：每一阶段解决一个问题

先用锁定评测集比较候选版本的逐样本正确性、引用、拒绝与费用，再用保留集检查泛化。只改善开发集平均分，不足以通过发布门槛。

影子验证可把授权输入发送给候选版本并比较，但其写入工具应使用隔离环境或只读替代；真正执行两遍外部动作会改变业务。线上灰度按用户或租户稳定分组，避免一次任务的不同步骤突然换配置。比例由流量和风险决定，不能把某个固定百分比当作行业规范。

进入灰度前写明回滚条件和观察窗口：严重权限错误立即停止；关键任务成功率、错误率、p95 与每任务成本分别判断。回滚切换新任务使用的配置，已执行的外部动作需要对账或补偿；长任务可继续旧版本或从明确迁移点恢复，不能靠切一个全局变量保证安全。

如何优化：一张可检验的实验矩阵

每个实验保留模型与资料版本、任务分组、运行次数、逐任务结果和费用口径。改善比例必须有原始计数与不确定性说明；没有实测时只能写待验证假设。生产流程由观测与交付篇继续展开。

参考资料