阿甘的博客 | Arganzheng's Blog

Prompt 与上下文工程（07）：系列总结与通关自测

Prompt and Context Engineering: Series Recap and Final Self-Test

六篇正文回答了一个问题：模型这一步该看到什么、看多少、按什么顺序，以及怎样像管代码一样管它。第一篇解剖上下文的七层，第二篇讲 system prompt 里稳定的模式与不稳定的措辞，第三篇讲结构化输出的机制与 schema 设计，第四篇讲预算与卸载 → 清理 → 压缩的处理顺序，第五篇讲缓存与排列，第六篇讲版本、评测门禁、两个跨工具标准与上下文 vs 检索的决策。六篇合起来是《AI 应用工程师学习地图》第二层：把”模型看到什么”当作一个有预算、有顺序、有版本的工程对象。本文不讲新内容：一张总表与六段回顾，贯穿六篇的四条线，常见误区，然后是三段式通关自测——判断与计算、跨篇综合、面试题。各篇末尾的自测检验”这一篇读懂了没有”，这里检验”六篇能不能连起来用”。 ...

Posted by arganzheng | October 11, 2026

Prompt 与上下文工程（06）：prompt 当代码管——版本、评测、A/B，以及上下文 vs 检索

Prompts as Code: Versioning, Evals, A/B Testing, and Context vs Retrieval

前五篇讲了上下文的每一层怎么写、怎么约束、怎么压、怎么排。这一篇讲怎么管：prompt 改一个词就是一次发布——它改变模型的行为，可能让评测集里三条用例由对变错，可能让缓存前缀全部失效；模型升级是一次依赖升级——同样的 prompt 在新模型上遵循率不同（第二篇）。把 prompt 当文案管的团队会在某个周五下午改一句话直接上线，周一从用户投诉里发现回归。把 prompt 当代码管的团队有版本、有测试、有灰度、有回滚。本篇有三部分。工件与流程：prompt 放版本库还是注册表，怎么与模型版本绑定，改动要跑什么、怎么灰度、怎么回滚，A/B 怎么做。两个跨工具的 prompt 标准：AGENTS.md（2025 年 8 月发布的开放格式，六万多个开源项目采用，Lin...

Posted by arganzheng | October 11, 2026

Prompt 与上下文工程（05）：prompt caching 与上下文的排列

Prompt Caching and Context Layout

《模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段》算过缓存的账：命中读价 0.1×（Fable 5.1 0.025×、DeepSeek 0.02×），写入 1.25×，读一次就回本，多轮对话的二次增长被乘上 0.1。这一篇讲怎样让它命中——这是一个排列问题：缓存的是逐字节相同的前缀，所以上下文里每一段的位置、每一个字节是否稳定、每一次修改发生在哪，直接决定命中率。Manus 把 KV-cache 命中率列为”生产 agent 最重要的单一指标”，理由是它同时决定成本与 TTFT，而 agent 的输入输出比是 100 : 1——几乎全部成本都在可缓存的那一侧。前四篇讲的每一种上下文操作都与缓存有关：第一篇的分层决定断点放哪；第三篇的 sch...

Posted by arganzheng | October 10, 2026

Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办

Context Budgeting, Offloading and Compaction

第一篇算过：一个 agent 会话的上下文按每步几千 token 增长，50 步就能填满 200K 窗口，原始目标漂到窗口中间。这一篇讲怎么办。答案不是一个开关，是一条代价递增的处理顺序：先不让无关内容进来（卸载、隔离），再清掉已经没用的（清理），最后才用一次模型调用把历史摘要成一段（压缩）——压缩最贵、最有损，放在最后。这一篇的材料几乎全部来自公开的生产系统：Claude Code 在窗口约 83.5% 处 auto-compact、预留 33K、压缩后 CLAUDE.md 从磁盘重注入而按路径的规则丢失；Codex 先试”会话记忆压缩”不调模型、不够才调服务端的 /responses/compact 拿回一个加密 blob，触发点在轮前与循环边界两处；Lan...

Posted by arganzheng | October 9, 2026

Prompt 与上下文工程（03）：结构化输出——约束解码、schema 设计与失败修复

Structured Output: Constrained Decoding, Schema Design and Failure Repair

《模型作为组件（02）：API 契约（一）——消息、工具调用、结构化输出与流式，四家 API 的共同骨架》把结构化输出分成三个层次——提示、JSON 模式、schema 约束——并给了一句结论：schema 约束保证语法不保证语义。这一篇把那一句展开成一篇：约束解码在推理引擎里是怎样实现的、为什么它能给出”不可能生成不合法 JSON”这样的硬保证、为什么 strict 模式对 schema 有限制；然后是应用侧的两件事——schema 怎么设计才既可靠又不损害模型的推理（字段顺序就是生成顺序，拒答要有出口，枚举替代自由字符串），解析层怎么写才能处理 schema 保证不了的那一半（业务校验、修复重试、流式部分 JSON、截断）。结构化输出是应用工程里少见的”硬”...

Posted by arganzheng | October 8, 2026

Prompt 与上下文工程（02）：prompt 设计——稳定的模式与不稳定的措辞

Prompt Design: Stable Patterns, Unstable Wording

上一篇把上下文分成七层，第一层——系统指令——是传统意义上”prompt 工程”的对象。这一篇专讲它，但换一个角度：把 prompt 里稳定的部分与不稳定的部分分开。稳定的是模式：明确角色与任务、把规则写成可检验的条款、用结构分区、说明工具何时用、给出输出格式。不稳定的是措辞：具体的句子、例子、语气——它们随模型变，供应商为每个新模型发一份 prompting 指南就是证据；《模型作为组件（01）：失效模式——非确定性、幻觉、上下文与越界，把「模型会出错」拆成七条可检测的性质》把”prompt 敏感”列为七条失效模式之一，讲的就是这个不稳定。 2026 年还有一件事让这个区分更重要：主力模型都是推理模型（《模型作为组件（03）：API 契约（二）——推理模型：th...

Posted by arganzheng | October 7, 2026

Prompt 与上下文工程（01）：上下文的解剖——一次请求里模型看到的一切

Anatomy of the Context Window: Everything the Model Sees in One Request

《模型作为组件（01）：失效模式——非确定性、幻觉、上下文与越界，把「模型会出错」拆成七条可检测的性质》讲过：模型能可靠利用的上下文远小于它标称的长度，而且长上下文按 token 计费、线性拖慢 TTFT。这一篇从另一头看同一个问题：一次请求里模型到底看到了什么。多数工程师第一次把发给模型的完整请求体打印出来时都会吃惊——用户那句 20 个字的问题外面裹着两万 token 的 system prompt、工具定义、历史、检索结果与工具返回，而其中一半是上一步某个工具返回的原始 JSON。要管理上下文，先要能解剖它。本篇建立一个七层模型：每层是什么、由谁维护、多大、变化多快、能不能压缩——后面五篇的每一种策略（预算、压缩、缓存、版本）都是对某几层的操作。实例用两个...

Posted by arganzheng | October 6, 2026

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

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

内容简介《Prompt 与上下文工程：模型这一步该看到什么》是一组共六篇的系列文章，是《AI 应用工程师学习地图》第二层（L2）的正文。它接在 L1《模型作为组件》之后：L1 讲清了模型这个组件怎么失效、接口是什么、花多少钱；L2 讲你放进去的东西——模型在每一步看到的上下文由什么组成、怎么写、怎么约束它的输出、长了怎么办、怎么排列才能命中缓存、怎么像代码一样管理它。 “prompt 工程”这个词到 2026 年已经不够用。生产系统里模型每一步看到的不是一段 prompt，是一个由 system 指令、工具定义、技能说明、对话历史、检索结果、工具返回、记忆片段拼成的上下文，几万到几十万 token；一个 agent 任务平均要几十次模型调用，输入与输出 tok...

Posted by arganzheng | October 5, 2026

模型作为组件（07）：系列总结与通关自测

The Model as a Component: Series Recap and Final Self-Test

六篇正文回答了一个问题：把大模型当作系统里的一个组件，它的规格书是什么。第一篇写它的失效模式，第二、三篇写它的接口（含推理模型的新维度），第四篇算它的账，第五篇讲怎么在几十个候选里选，第六篇讲调用它的客户端要处理什么。六篇合起来，是《AI 应用工程师学习地图》第一层的全部内容——组件观：模型是一个非确定性、会编造、按 token 计费、有上下文上限、供应商会换掉的组件，后面六层的每一种工程手段都是对它某一条性质的应对。本文不讲新内容，做三件事：把六篇压成一张表与六段回顾，把贯穿六篇的几条线拎出来，然后给一套三段式的通关自测——判断与计算、跨篇综合、面试题。各篇末尾的自测检验的是”这一篇读懂了没有”，这里检验的是”六篇能不能连起来用”。读完这六篇，你应该...

Posted by arganzheng | October 4, 2026

模型作为组件（06）：客户端工程——重试、超时、幂等、限流与流式解析

Client Engineering for LLM APIs: Retries, Timeouts, Idempotency, Rate Limits and Stream Parsing

前五篇讲的是组件本身：它怎么坏、接口是什么、花多少钱、怎么选。这一篇讲你这一侧——调用它的客户端。调用模型 API 与调用任何不稳定的第三方服务有大半是相同的：会超时、会 429、会 5xx，要重试、要退避、要熔断。不同的是失败的种类更多——上下文超限、内容过滤、工具调用格式错、推理超预算、流式中途断开——而且每一次重试都要再花一次钱，一次重试可能是几美分也可能是几美元（一个 300K 输入的请求）。后端工程师写过的每一个 HTTP 客户端的经验在这里都有效，但要加三条模型 API 特有的纪律：发请求之前数 token（超限的 400 是可以避免的失败）；流式响应的失败只能重发不能续传（并接受已生成 token 的费用）；重试策略要区分”再试一次可能成功”与”再...