Prompt 与上下文工程：模型这一步该看到什么（总纲）

Prompt and Context Engineering: What the Model Should See at This Step

Posted by arganzheng | | 约 31 分钟 · 13.7k 字
AI LLM AI-Application Prompt Engineering Context Engineering Agent
地图 《AI 应用工程师学习地图》 第 2 / 7 个系列
  1. 模型作为组件
  2. Prompt 与上下文工程
  3. 检索与知识接入
  4. 工具、Agent 与 harness
  5. 评测、可观测与可追溯即将发布
  6. 生产化与运营即将发布
  7. 产品与体验即将发布

上一个系列：模型作为组件下一个系列：检索与知识接入

内容简介

《Prompt 与上下文工程：模型这一步该看到什么》是一组共六篇的系列文章，是《AI 应用工程师学习地图》第二层（L2）的正文。它接在 L1《模型作为组件》之后：L1 讲清了模型这个组件怎么失效、接口是什么、花多少钱；L2 讲你放进去的东西——模型在每一步看到的上下文由什么组成、怎么写、怎么约束它的输出、长了怎么办、怎么排列才能命中缓存、怎么像代码一样管理它。

“prompt 工程”这个词到 2026 年已经不够用。生产系统里模型每一步看到的不是一段 prompt，是一个由 system 指令、工具定义、技能说明、对话历史、检索结果、工具返回、记忆片段拼成的上下文，几万到几十万 token；一个 agent 任务平均要几十次模型调用，输入与输出 token 的比例接近 100 : 1（Manus 的公开数字）。决定每一步”模型看到什么、看多少、按什么顺序”，是一门有明确机制、有可测指标、有公开最佳实践的工程——Anthropic 把它叫 context engineering，定义是”在推理时为模型策划并维护最优 token 集合的一组策略”。本系列采用这个框架，但从应用工程师的角度写：每一项策略在 L1 的失效模式表上对付哪一条、在 L1 的账上换的是什么。

它回答的问题是：

模型这一步该看到什么、看多少、按什么顺序？怎么让输出可解析、可稳定？上下文长了怎么办？怎么排列才能让缓存命中？怎么像管代码一样管 prompt？1

答案分六篇。第一篇建立上下文的解剖：一次请求里模型看到的一切分几层、各占多少 token、各由谁维护，用 Claude Code 公开的”上下文窗口时间线”与 Manus 的数字做实例，并说明为什么”注意力预算”是有限的（《模型作为组件（01）：失效模式——非确定性、幻觉、上下文与越界，把「模型会出错」拆成七条可检测的性质》的有效上下文问题在这里变成一个设计约束）。第二篇讲 prompt 设计里稳定的部分——模式——与不稳定的部分——措辞：2026 年推理模型上哪些经典技巧（few-shot、”一步步想”）失效甚至有害，公开的 system prompt（Anthropic 发布的 claude.ai system prompt、Claude Code 的 system prompt 结构）长什么样，供应商的模型专属 prompting 指南在说什么。第三篇深入结构化输出：约束解码的机制（Outlines、XGrammar、llguidance 一类在 vLLM 里的实现，四家 API 的 strict 模式），schema 的设计模式（推理字段在前、拒答出口、枚举收窄），失败的修复与重试，流式部分 JSON。第四篇讲上下文预算与压缩——本系列最重要的一篇：给每一部分定配额，超了先卸载（Deep Agents 的 20K token 卸载规则、Manus 的”文件系统即上下文”）、再清理工具结果（Anthropic API 的 context editing）、再压缩（Claude Code 在约 83.5% 处的 auto-compact 与它保留什么、Codex 的两级压缩与服务端加密的 /responses/compact、Anthropic 服务端 compaction 的 150K 默认阈值），用子 agent 隔离探索性上下文，用 todo 文件”复述”目标防止漂移。第五篇讲 prompt caching 与上下文的排列：Anthropic 的显式断点怎么分层放、OpenAI 与 DeepSeek 的自动前缀缓存要什么条件、Gemini 的显式缓存对象与存储费；Manus 的三条规则——前缀稳定、只追加、确定性序列化——以及”屏蔽工具而不是删除工具”这类反直觉的做法；命中率作为生产 agent 的第一指标。第六篇讲 prompt 当代码管：放版本库还是 prompt 注册表（Langfuse 的版本与标签、OpenAI 在 Assistants API 关闭后的 Prompts 对象、promptfoo），与模型版本绑定，每次改动跑评测集，用标签做 A/B 与回滚；AGENTS.md 与 SKILL.md 这两个 2025–2026 年成为跨工具标准的 prompt 工件；最后回答”全放上下文、检索、还是 agentic retrieval”的决策，把话题交给 L3。

系列的组织原则：每一项上下文策略都是在 L1 的失效模式与账之间做交换。压缩用一次推理的成本换有效上下文；缓存用前缀的稳定性换 90% 的输入折价；结构化输出用 schema 的约束换解析的确定性；few-shot 用 token 换遵循率。六篇的每一篇都把新引入的手段记回 L1 的两张表。

缩写

本系列的 10 个缩写（展开）
缩写全称一句话解释
A/B A/B testing 把流量随机分给两个版本，比较指标
AES Advanced Encryption Standard 对称加密标准，Codex 用它加密压缩结果
CFG context-free grammar 上下文无关文法，能表达递归的嵌套结构
CoT chain-of-thought 让模型先写出推理步骤再回答
FSM finite-state machine 有限状态机，每个状态对应一组允许的 token
JSONL JSON Lines 每行一个 JSON 对象的文本格式
MCP Model Context Protocol 给模型接工具和数据源的开放协议
RAG retrieval-augmented generation 先检索资料，再让模型据此回答
TTFT time to first token 首 token 延迟，从发请求到收到第一个 token
TTL time to live 缓存条目的存活时间，过期就失效

为什么写这个系列？

“写好 prompt”已经不是问题的主体

2023 年的 AI 应用工程有一大半是在措辞上做实验：加一句”你是一个专家”、加几个例子、加”一步步想”。2026 年，这些技巧的收益大部分被模型吸收了——推理模型自己会想，指令遵循强到”说清楚就行”，而且供应商的 prompting 指南开始告诉你不要做什么（对推理模型不要再加 CoT 指令，不要过度 few-shot）。措辞的边际收益在下降，同时另一件事的成本在上升：一个 agent 的上下文每一步都在增长，几十步之后原始任务漂到窗口中间、工具返回占了 90% 的 token、缓存因为一个时间戳而全部失效。Anthropic 在 2025 年 9 月的工程博客里把这个转变说得很直接：”构建 LLM 应用越来越不是找对措辞，而是回答’什么样的上下文配置最可能产生想要的行为’。”

机制已经公开，而且相当具体

这是写这个系列的好时机：几个最成熟的 agent 产品把自己的上下文策略公开了，带着数字。Claude Code 的文档有一条交互式时间线，展示一个会话从启动到压缩每一步进了什么、花了多少；它的 auto-compact 在窗口约 83.5% 处触发（预留 33K 给摘要），压缩后 CLAUDE.md 与自动记忆从磁盘重新注入、按路径作用的规则丢失。Codex 的压缩先查会话记忆能否替代摘要、不能才调服务端的 /responses/compact 得到一个只有 OpenAI 能解密的 blob，触发点在轮前与循环边界两处。Manus 公开了四次重写 agent 框架得到的六条经验，第一条是”KV-cache 命中率是生产 agent 最重要的单一指标”。LangChain 的 Deep Agents 公开了卸载阈值：工具返回超过 20,000 token 写文件并留 10 行预览，上下文过 85% 时把旧的写入调用截成指针。Anthropic 的 API 把三种机制做成了一等功能：服务端 compaction（默认 150K 触发）、context editing（清理旧工具结果）、memory tool。这些不再是各家的秘密，是可以对照着讲的公开工程。

现有材料的断层

  • prompt 工程教程停在措辞层面，多数写于推理模型之前，其中一部分建议在 2026 年的模型上是反效果的；
  • 供应商的 prompting 指南是模型专属的（GPT-5 的 prompting guide、Claude Sonnet 5 的 prompting 页），互相不通用，也不讲上下文管理；
  • agent 框架文档把压缩、卸载、缓存断点做成几个参数，不解释阈值为什么是那个数、不同策略怎么组合、什么时候互斥；
  • 工程博客（Anthropic、Manus、Claude Code 文档、Codex 的分析文章）各讲自己的系统，没有人把它们放在一张表上比较，也没有人把它们接回”这在对付哪条失效、在账上换什么”。

本系列想填补的是从”会写 system prompt”到”能为一个几十步的 agent 设计上下文策略、解释它每一步的 token 从哪来、命中率为什么是这个数、压缩后丢了什么”之间的那段路。

适合哪些读者？

读完 L1、准备做第一个上下文超过一屏的应用的工程师

你知道模型会失效、知道 token 怎么计费；现在要决定 system prompt 写什么、检索结果放哪、历史留几轮。本系列给你一张预算表与一套排列规则。

已经在做 agent、被上下文问题困扰的工程师

任务跑到第 30 步开始忘目标、账单里 90% 是重复传输的工具返回、缓存命中率只有 20%——第四、五篇直接对付这些。

想读懂 Claude Code / Codex / Manus 上下文策略的开发者

第一、四、五篇用它们公开的机制与数字做主线实例，并放在一张表上比较。

平台工程师

要为团队提供 prompt 注册表、评测门禁、缓存监控——第六篇讲这些工件与流程。

系列的整体主线

六篇的主题与建立的东西
篇 主题 建立的东西 对付 L1 的哪条失效 在 L1 的账上换什么
1 上下文的解剖 一次请求的分层与 token 构成；注意力预算 上下文标称 ≠ 有效 建立预算的基线
2 prompt 设计
  • 稳定的模式 vs 不稳定的措辞
  • 2026 年的失效技巧
  • 公开 system prompt 的结构
 指令遵循与 prompt 敏感 token 换遵循率
3 结构化输出
  • 约束解码机制
  • schema 设计模式
  • 修复与重试
 指令遵循（格式）、幻觉（拒答出口） schema 的 token 换解析确定性
4 预算与压缩
  • 配额表
  • 卸载 → 清理 → 压缩的顺序
  • 子 agent 隔离
  • 复述
 上下文标称 ≠ 有效；越界（目标漂移） 一次推理的成本换有效上下文
5 缓存与排列
  • 前缀分层
  • 三条规则
  • 屏蔽而非删除
  • 命中率指标
 —（纯账） 前缀稳定性换 90% 输入折价与 TTFT
6 prompt 当代码管
  • 版本、标签、评测门禁、A/B
  • AGENTS.md / SKILL.md
  • 上下文 vs 检索的决策
 供应商变更、prompt 敏感 评测成本换回归保护

三条贯穿的线：

  • 上下文是有限资源，不是桶。 注意力对 token 是 \(n^2\) 的两两关系，每加一个 token 都在消耗一份有限的”注意力预算”；《模型作为组件（01）：失效模式——非确定性、幻觉、上下文与越界，把「模型会出错」拆成七条可检测的性质》的 Context Rot 数据是这个约束的实证。所以每一篇的问题都是”这一段值不值得占这份预算”。
  • 顺序即成本。 稳定的放前面、动态的放后面，这一条同时决定缓存命中率（第五篇）、压缩后什么能存活（第四篇）、模型对指令的注意（第一篇的位置效应）。
  • prompt 是代码。 有版本、有测试、有发布流程、有回滚；改一个词就是一次发布，模型升级就是一次依赖升级。

章节结构与分章导读

1. 上下文的解剖：一次请求里模型看到的一切

核心问题：模型在这一步看到的上下文由哪几层组成？各占多少 token、由谁维护、什么时候变？为什么”注意力预算”是有限的？2

从一个具体实例开始：Claude Code 一个会话在你敲第一个字之前上下文里已经有什么（system prompt、CLAUDE.md、自动记忆——上限 200 行或 25 KB、MCP 工具名、技能描述），每读一个文件加多少，按路径作用的规则何时加载，子 agent 怎样把大段读取隔离在自己的窗口里，压缩时每一类内容的命运。然后抽象成七层：系统指令、工具与技能定义、长期记忆、对话历史、检索结果、工具返回、当前输入——每层的维护者不同（开发者、平台、用户、运行时），变化频率不同（决定第五篇的缓存分层），可压缩性不同（决定第四篇的策略）。最后是预算的物理基础：注意力的 \(n^2\) 与 Context Rot 的实证，以及 Manus 的两个数字——一个任务约 50 次工具调用、输入输出 100 : 1——为什么意味着”不管理的上下文必然让目标漂到窗口中间”。

2. prompt 设计：稳定的模式与不稳定的措辞

核心问题：哪些 prompt 技巧在 2026 年的模型上仍然有效、哪些已经失效甚至有害？公开的 system prompt 长什么样？为什么 prompt 要当代码不当文案？3

先分层：模式（角色与任务的明确陈述、把规则写成可检验的条款、用结构标记分区、给出输出格式、说明工具何时用）是稳定的；措辞（具体的句子、例子的选择、语气）是不稳定的——换模型要重调，供应商为每个新模型发 prompting 指南就是证据。然后逐条审视经典技巧：few-shot 在推理模型上何时仍有用（格式与风格）、何时有害（Manus 的经验：模型会模仿例子的模式陷入重复，要引入结构化的变化）；”一步步想”对推理模型是冗余的，OpenAI 与 Anthropic 都建议去掉；负面指令为什么低效、正面替代怎么写；对推理模型的 effort 与 prompt 的关系。用公开材料做实例：Anthropic 发布的 claude.ai 各版本 system prompt（它的结构、它怎样处理知识截止与拒答）、Claude Code system prompt 的分区（语气、工具使用政策、安全约束）、OpenAI 的 GPT-5 prompting guide 里”agentic eagerness”与”tool preamble”两个概念。最后是边界：prompt injection 不是 prompt 设计能解决的（L6）。

3. 结构化输出：约束解码、schema 设计与失败修复

核心问题：约束解码在推理引擎里是怎么实现的？为什么 strict 模式对 schema 有限制？schema 该怎么设计才既可靠又不损害推理？解析失败了怎么修？4

《模型作为组件（02）：API 契约（一）——消息、工具调用、结构化输出与流式，四家 API 的共同骨架》讲了结构化输出的三个层次与”保证语法不保证语义”。这一篇深入：约束解码把 JSON schema 编译成状态机（正则 / 上下文无关文法），每一步采样时把不合法 token 的概率置零——Outlines、XGrammar、llguidance 一类库在 vLLM 与 SGLang 里的实现，四家 API 的 strict 模式为什么要求 additionalProperties: false、所有字段 required、不支持部分 schema 特性（编译成本与状态空间），首次使用一个 schema 的编译延迟与缓存。schema 设计模式：推理字段排在结论前（字段顺序即生成顺序）、显式的拒答 / 不确定出口、枚举替代自由字符串、避免深层可选嵌套、数组长度上限；”直接输出严格格式损害推理”的证据与推理模型对它的缓解。解析层：Pydantic / zod / instructor 一类的角色，业务校验，失败的修复（把校验错误放回上下文重试一次），流式部分 JSON 的增量解析，stop_reason 为 max_tokens 时的处理。格式遵循率作为独立指标。

4. 上下文预算与压缩：给每一部分定配额，超了怎么办

核心问题：怎样给上下文的每一层定 token 配额？超了先做什么、再做什么？压缩会丢什么、怎么知道丢了什么？子 agent 与 todo 文件各解决什么？5

预算表：system 与工具定义、记忆、历史、检索、工具返回、预留给输出的余量（Claude Code 预留约 33K，即窗口的 16.5%）各占多少，按任务类型给三档参考。然后是一条处理顺序，代价从低到高：（1）不让它进来——卸载：Deep Agents 的规则是工具返回超过 20,000 token 就写到文件系统、上下文里只留路径加前 10 行预览；Manus 的”文件系统即上下文”——可恢复的压缩（保留 URL、保留路径，内容随时能再读）；（2）清理——Anthropic API 的 context editing 按策略清掉旧的工具返回（clear_tool_uses），Deep Agents 在 85% 时把旧的写入调用截成指针；（3）压缩——用一次模型调用把历史摘要成一段：Claude Code 在约 83.5% 处 auto-compact，压缩后 system prompt 不变、根目录 CLAUDE.md 与自动记忆从磁盘重注入、按路径的规则与子目录 CLAUDE.md 丢失；Codex 先试”会话记忆压缩”（用已结构化的任务状态替代摘要，多数情况不调模型），不够再调 /responses/compact 得到加密 blob，触发点在轮前与循环边界；Anthropic 服务端 compaction 默认 150K 触发（最低 50K），可替换默认的摘要 prompt；DeepSeek Harness 的 SDK 把压缩策略做成可显式配置的”语义检查点”。（4）隔离——子 agent 在自己的窗口里做探索，只把摘要带回。（5）复述——Manus 的 todo.md：把目标写在上下文末尾并不断更新，对抗”目标漂到中间”。压缩与推理状态的关系（《模型作为组件（03）：API 契约（二）——推理模型：thinking、effort 与跨轮的推理状态》：只能在思考链结束处做），以及怎么评测压缩——用”压缩前后模型能否回答同一组问题”探测什么存活了。一张表比较五个系统的阈值与策略。

5. prompt caching 与上下文的排列

核心问题：四家的缓存各要什么条件？断点怎么分层放？为什么”屏蔽工具”比”删除工具”好？命中率低于多少要查什么？6

《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》算了缓存的账（读 0.1×、写 1.25×、读一次回本）。这一篇讲怎样让它命中。机制回顾：缓存的是前缀的 KV，逐字节相同才命中，顺序 tools → system → messages。四家的条件：Anthropic 显式 cache_control（最多 4 个断点、20 块回看、5 分钟 / 1 小时 TTL）或顶层自动；OpenAI 自动（1,024 起、128 倍数、GPT-5.6 起断点在最近一条可缓存消息末尾）；Gemini 隐式加显式缓存对象（按小时存储费，适合长文档反复问答）；DeepSeek 自动磁盘缓存（64 token 粒度）。分层放断点：静态（system、工具定义）→ 半静态（few-shot、用户画像）→ 动态（历史）→ 当前轮，各放一个断点，变化频率低的在前。Manus 的三条规则：前缀稳定（一个时间戳毁掉全部）、只追加（不修改历史、序列化要确定性——JSON 键序一变就失效）、显式标断点。反直觉的一条：动态增删工具会破坏前缀，Manus 的做法是保留全部工具定义、用 logits 屏蔽（自托管）或 tool_choice 约束（API）控制可用性；OpenAI / Anthropic 的 tool search 是另一条路——定义按需加载，代价是它们本身不在前缀里。命中率的监控与排查表：低于 50% 查动态内容、查历史修改、查间隔超 TTL、查工具集变化。与压缩的配合：压缩必然失效一次，之后以短前缀重建。

6. prompt 当代码管：版本、评测、A/B，以及上下文 vs 检索

核心问题：prompt 放版本库还是注册表？怎么与模型版本绑定？改一个词要跑什么？AGENTS.md 与 SKILL.md 是什么、怎么写？什么时候全放上下文、什么时候检索？7

工件：prompt 在版本库里（与代码同步发布、代码审查、diff 可见）还是在注册表里（Langfuse 的不可变版本加可移动标签——production / staging / prod-a，运行时按标签取，改 prompt 不用重新部署；OpenAI 在 Assistants API 关闭后把 Assistants 的”指令 + 工具”束改成只能在控制台创建的 Prompts 对象并建议把 id 放进源码）；两种做法的取舍与混合。流程：每个 prompt 版本绑定模型版本与参数（effort、max_tokens）；改动即发布——跑评测集（《模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期》的评测集，L5 的方法）、看格式遵循率与任务指标、灰度、可回滚；A/B 用标签随机分流并把 trace 绑到版本。两个跨工具的 prompt 工件：AGENTS.md（2025 年 8 月发布的开放格式，六万多个开源项目采用，2025 年 11 月起由 Linux 基金会下的 Agentic AI Foundation 管理——项目的常驻指令：结构、命令、硬规则）与 SKILL.md（Anthropic 2025 年 10 月发布、12 月开放为标准，name ≤ 64 字符、description ≤ 1,024 字符，四十多个客户端支持，.agents/skills/ 成为中立目录——按需加载的技能，只有描述常驻、正文用到时才进上下文，这正是第四章”渐进披露”的实例）；它们的写法与陷阱（Claude Code 读 CLAUDE.md 不原生读 AGENTS.md、路径不统一）。最后的决策表：全放上下文（小而稳定的资料 + 缓存）、流水线检索（大语料、高并发问答）、agentic retrieval（复杂任务、模型自己决定查什么）——按语料大小、变化频率、查询类型、缓存后的成本四个维度选，交给 L3。

7. 系列总结与通关自测

一张总表回顾六篇各自回答的问题与必记的数字，逐篇的核心结论与常见误解，贯穿全系列的几条线，然后是三段自测——判断与计算、跨篇综合、面试题——加一份”读过 / 掌握 / 能教人”的判据。

贯穿全系列的实践线

本系列不设配套实验。每篇末尾有一节实践建议：

各篇实践建议的内容
篇 实践建议的内容
1 打印你的应用一次典型请求的完整上下文，按七层标出 token 数，画出预算饼图
2 把 system prompt 的每条规则改写成可检验的条款，删掉对推理模型冗余的 CoT 指令，为每条规则写一个评测用例
3 给每个结构化输出的 schema 加拒答出口与推理字段，测格式遵循率与业务校验通过率
4 为你的 agent 定卸载阈值、清理策略与压缩触发点，用”压缩前后问同一组问题”测存活率
5 审计前缀：找出动态内容、非确定性序列化、工具集变动；把命中率上仪表盘，目标 > 70%
6 把 prompt 从代码里挪到有版本的位置，与模型版本绑定，接上评测门禁；给项目写一份 AGENTS.md

前置要求与说明

前置要求

  • L1《模型作为组件》六篇——本系列大量引用它的失效模式表、契约细节与成本公式，不重复推导；
  • 调过任何一家的 API，写过至少一个 system prompt。

版本与事实基线

以 2026 年 9 月的公开材料为准：

本系列的版本与事实基线
来源 内容
Anthropic
  • 《Effective context engineering for AI agents》（2025-09）
  • API 的 compaction / context editing / memory tool 文档
  • claude.ai 各版本的公开 system prompt
  • Claude Code 文档的上下文窗口时间线与 auto-compact 参数
  • Agent Skills 规范（agentskills.io，2025-12 开放）
OpenAI
  • GPT-5 prompting guide
  • Responses API 的 Prompts 对象与 Assistants 迁移指南（2026-08-26 关闭）
  • /v1/responses/compact 的公开分析
Codex CLI 开源仓库中压缩策略的公开分析（2026-03 / 04）
Manus 《Context Engineering for AI Agents: Lessons from Building Manus》（2025-07）
LangChain Deep Agents 公开的卸载与截断阈值
DeepSeek Harness v0.1 developer preview（2026-08-13）的 SDK 文档中的压缩配置
AGENTS.md 开放格式（2025-08）与 Agentic AI Foundation（2025-11）
研究
  • Lost in the Middle、Context Rot、NoLiMa（L1 已引）
  • Let Me Speak Freely?（2024）
  • Outlines / XGrammar / llguidance 的论文与实现

各家的阈值与默认值会变，文中引用时标注来源与日期；读者应以自己读到本文时的文档为准。价格沿用 《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》的 2026 年 9 月价目。

章节目录

  1. 上下文的解剖：一次请求里模型看到的一切
  2. prompt 设计：稳定的模式与不稳定的措辞
  3. 结构化输出：约束解码、schema 设计与失败修复
  4. 上下文预算与压缩：给每一部分定配额，超了怎么办
  5. prompt caching 与上下文的排列
  6. prompt 当代码管：版本、评测、A/B，以及上下文 vs 检索
  7. 系列总结与通关自测

最终目标

读完本系列，面对一个要放进模型的上下文，读者应该能够：

读完系列后应能回答的追问
追问 答案来自
这一步模型看到的几万 token 是什么构成的？哪一层最大？ 第一篇
这条 prompt 技巧在 2026 年的推理模型上还有用吗？ 第二篇
这个 schema 会把拒答伪装成答案吗？推理字段放对了吗？ 第三篇
工具返回 50K token，该卸载、清理还是压缩？压缩后 CLAUDE.md 还在吗？ 第四篇
命中率 30%，是哪一层在破坏前缀？ 第五篇
改了 system prompt 的一个词，上线前要做什么？ 第六篇
这份资料该全放、检索还是让 agent 自己查？ 第六篇 → L3

这就是 L2 要建立的能力：把”模型看到什么”当作一个有预算、有顺序、有版本的工程对象来设计，而不是一段文案。

  1. 六篇各答一问。看什么、多少、什么顺序：上下文分七层（系统指令、工具定义、长期记忆、对话历史、检索结果、工具返回、当前输入），各有维护者、变化频率与 token 配额，注意力预算有限（第一篇）。可解析、可稳定：prompt 的模式稳定、措辞不稳定，推理模型上 few-shot 与「一步步想」要重新审视（第二篇）；结构化输出靠约束解码（schema 编译成状态机屏蔽非法 token），schema 设计让推理字段在前、留拒答出口，解析失败把错误放回去修一次（第三篇）。上下文长了：先卸载（工具返回 > 20K token 写文件只留路径）、再清理（旧工具返回）、再压缩（Claude Code 在 83.5% 处 auto-compact），子 agent 隔离、todo 文件复述（第四篇）。缓存命中：前缀稳定、只追加、工具屏蔽不删除，静态 → 半静态 → 动态分层放断点，命中率低先查时间戳与序列化（第五篇）。像代码一样管：版本库或注册表 + 与模型版本绑定 + 改一个词就跑评测集，AGENTS.md / SKILL.md 是跨工具的 prompt 工件，全放上下文还是检索按体量与变化频率定（第六篇）。 ↩

  2. 七层：系统指令、工具与技能定义、长期记忆、对话历史、检索结果、工具返回、当前输入。各占多少以 Claude Code 为实例：敲第一个字之前已有 system prompt、CLAUDE.md、自动记忆（上限 200 行 / 25 KB）、MCP 工具名与技能描述——通常上万 token；每读一个文件按文件大小加，按路径作用的规则在进入目录时加载，子 agent 把大段读取隔离在自己的窗口。维护者不同：系统指令与工具定义由开发者 / 平台维护、记忆由用户与运行时、历史与工具返回由运行时逐轮追加、检索结果由检索层；变化频率从几乎不变（system、工具）到每轮都变（当前输入、工具返回）——这决定缓存怎么分层，可压缩性决定超预算时先动谁。注意力预算有限的物理基础：attention 的 \(n^2\) 代价与 Context Rot 的实证（有效上下文远小于标称），加上 Manus 的两个数字——一个任务约 50 次工具调用、输入输出 100 : 1——不管理的上下文必然让目标漂出窗口。 ↩

  3. 仍有效的是模式：角色与任务的明确陈述、把规则写成可检验条款、用结构标记分区、给出输出格式、说明工具何时用；失效或有害的：「一步步想」对推理模型是冗余（OpenAI 与 Anthropic 都建议去掉），few-shot 只在格式与风格上有用、在推理模型上会让模型模仿例子的模式陷入重复（Manus 的经验：要引入结构化变化），负面指令低效要换成正面替代，威胁 / 奖励式的措辞无效。公开的 system prompt 长什么样：Anthropic 发布的 claude.ai system prompt 按分区组织（身份与语气、知识截止与拒答的处理、格式规则、安全条款），Claude Code 的 system prompt 分区为语气、工具使用政策、安全、环境信息——都是结构化条款而不是一段文案。prompt 要当代码不当文案，是因为它决定系统行为、换模型要重调、一个词的改动能让格式遵循率变化几个点——所以要进版本库、做 diff、绑定模型版本、每次改动跑评测集（第六篇）。 ↩

  4. 实现：把 JSON schema 编译成状态机（正则或上下文无关文法），每一步采样时按当前状态把不合法 token 的 logits 置为 −∞——Outlines、XGrammar、llguidance 在 vLLM / SGLang 里的 logits processor 就是这样做的；首次使用一个 schema 有编译延迟，之后缓存。strict 模式对 schema 有限制（additionalProperties: false、所有字段 required、不支持部分特性如复杂 anyOf / 递归 / 格式约束），因为状态空间与编译成本要可控、且每个 token 的掩码要能快速算出。schema 设计：推理字段排在结论字段之前（字段顺序即生成顺序，让模型先想再答）、显式的拒答 / 不确定出口、枚举替代自由字符串、避免深层可选嵌套、数组长度上限；「直接输出严格格式损害推理」有证据，推理模型的 thinking 阶段缓解了它。解析失败的修复：Pydantic / zod / instructor 做结构与业务校验，失败时把校验错误放回上下文重试一次（不是盲目重试），仍失败走降级路径并记录为 bad case。 ↩

  5. 配额：按任务类型给 system 与工具定义、记忆、历史、检索、工具返回各一个上限，并预留输出余量（Claude Code 预留约 33K，即窗口的 16.5%），三档参考随任务复杂度调整。超了按代价从低到高处理：（1）卸载——不让它进来：工具返回超过 20,000 token 就写到文件系统、上下文只留路径加前 10 行预览（Deep Agents 的规则）、「文件系统即上下文」的可恢复压缩（保留 URL 与路径）；（2）清理——按策略清掉旧工具返回（Anthropic 的 clear_tool_uses，Deep Agents 在 85% 时把旧写入调用截成指针）；（3）压缩——用一次模型调用把历史摘要成一段（Claude Code 在约 83.5% 处 auto-compact，压缩后 system prompt 不变、CLAUDE.md 与自动记忆从磁盘重注入）。压缩会丢的：中间推理、被覆盖的决定、细节数字、文件的精确内容；知道丢了什么靠压缩前后的 diff 日志、把关键事实写进文件而不是只留在历史里、以及评测集里的长任务用例。子 agent 解决隔离（大段读取在自己的窗口、只回结果），todo 文件解决复述（把目标与进度反复写回上下文末尾，对抗目标漂移）。 ↩

  6. 条件：Anthropic 显式 cache_control（最多 4 个断点、20 块回看、5 分钟 / 1 小时 TTL）或顶层自动；OpenAI 自动（1,024 token 起、128 的倍数，GPT-5.6 起断点在最近一条可缓存消息末尾）；Gemini 隐式缓存加显式缓存对象（按小时收存储费，适合长文档反复问答）；DeepSeek 自动磁盘缓存（64 token 粒度）。共同前提：缓存的是前缀的 KV，逐字节相同才命中，顺序 tools → system → messages。断点分层：静态（system、工具定义）→ 半静态（few-shot、用户画像）→ 动态（历史）→ 当前轮，变化频率低的在前、各放一个断点。「屏蔽工具」比「删除工具」好，是因为工具定义在前缀最前面，删一个工具就改变了前缀、之后全部失配；用 logits 屏蔽或在 system 里声明不可用则前缀不变、缓存照常命中。命中率低于预期（如 < 70%）要查：前缀里有没有时间戳 / 请求 id 一类每次都变的东西、序列化是否确定（JSON 键序）、历史是否被修改而不是只追加、断点是否放在会变的内容之后、TTL 是否过期（调用间隔 > 5 分钟）。 ↩

  7. 版本库：与代码同步发布、代码审查、diff 可见，适合 prompt 与代码耦合紧的场景；注册表（Langfuse 的不可变版本 + 可移动标签 production / staging，运行时按标签取，改 prompt 不用重新部署）适合非工程角色频繁调整、多环境切换；OpenAI 的 Prompts 对象是托管版注册表。常见做法是混合：源码里放 id / 标签，内容在注册表，CI 把两边对齐。与模型绑定：每个 prompt 版本记录模型快照、effort、max_tokens 等参数，换任一项都算新版本。改一个词要跑：评测集（格式遵循率与任务指标）、成本与延迟对比、灰度与可回滚；A/B 用标签随机分流并把 trace 绑到版本。AGENTS.md：2025 年 8 月发布的开放格式、Linux 基金会下 Agentic AI Foundation 管理——项目的常驻指令（结构、构建 / 测试命令、约定、禁忌），写成可检验的条款、短、按目录分层；SKILL.md：按需加载的技能说明（何时用、怎么用、示例），正文只放触发条件与步骤，细节放附属文件。全放上下文 vs 检索：材料总量稳定在几万 token 以内且每次都要用 → 全放（配合缓存）；体量大、只用一小部分、经常变 → 检索 / 工具按需取。 ↩

这篇对你有用？
地图 《AI 应用工程师学习地图》 第 2 / 7 个系列
  1. 模型作为组件
  2. Prompt 与上下文工程
  3. 检索与知识接入
  4. 工具、Agent 与 harness
  5. 评测、可观测与可追溯即将发布
  6. 生产化与运营即将发布
  7. 产品与体验即将发布

上一个系列：模型作为组件下一个系列：检索与知识接入

本文由 arganzheng 创作，采用 CC BY 4.0 许可协议。在保留原文作者、署名以及完整原文链接（https://arganzheng.life/prompt-and-context-engineering.html）的前提下，欢迎各种形式的转载、翻译或商业引用。

LINKED FROM 被 1 篇文章引用

YOU MIGHT ALSO LIKE

COMMENTS

评论存放在 GitHub Discussions， 用 GitHub 账号登录即可发表，支持 Markdown。 想针对正文某句话说？选中那段文字，点浮出的「评论」即可划线评论；觉得哪里写错了，发表时勾上「同时提交 Issue」。 有人回复你时 GitHub 会按你的通知设置发邮件，不用守在这里。

OUTLINE

    没有匹配的标题

    应用地图2 / 7
    1. 模型作为组件
    2. Prompt 与上下文工程
    3. 检索与知识接入
    4. 工具、Agent 与 harness
    5. 评测、可观测与可追溯即将发布
    6. 生产化与运营即将发布
    7. 产品与体验即将发布
    ×