阿甘的博客 | Arganzheng's Blog

置顶致读者的一封信

这里写什么、怎么读、怎么告诉我哪里不对

你好，欢迎来到这里。这封信讲三件事：这里写什么、读的时候有哪些顺手的小功能、怎么告诉我哪里写得不对。这封信本身就是演示场地，下面提到的功能都可以直接在这里试，随便划、随便点，不会弄坏什么。一、这里写什么主要是技术，近两年集中在 AI 工程。内容按三张学习地图组织——AI 算法工程师、AI-Infra 工程师、AI 应用工程师——地图下面是三十多个系列，比如《大模型推理系统揭秘》《GPU Kernel 工程》《通信与互联》。每个系列有总纲、正文和一篇总结自测；文章开头告诉你它是第几篇，文末有整个系列的目录。导航栏的 Series 是全部系列的树。更早的文章（2009 年起）是 Java、数据库、搜索、大数据。技术之外，Life 是生活类的文章，Mome...

Posted by arganzheng | August 3, 2026

置顶AI 全栈学习地图：造模型、跑模型、用模型的三张图

One System, Three Roles — an Overview of the Three AI Learning Roadmaps

内容简介这个博客的技术文章围绕三张学习地图组织：《AI 算法工程师学习地图》、《AI-Infra 工程师学习地图》、《AI 应用工程师学习地图》。每张地图把一个方向的知识分层，说明每层回答什么问题、按什么顺序学、哪些已经写成了系列。本文是三张地图之上的一页总览，回答的是三张地图各自不回答的问题：为什么是三张而不是一张？三张地图之间怎么分工、在哪里交汇？一个人该从哪一张进入，读到哪里该换到另一张？1 三张地图对应的是同一个系统里的三种角色。一个大模型从数据到用户手里，要被造出来（预训练、后训练、评测）、被跑起来（引擎、集群、平台）、被用起来（检索、工具、编排、产品）。三件事用同一批名词——Python、PyTorch、Transformer、KV c...

Posted by arganzheng | January 1, 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

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

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

L1 第二篇把结构化输出分成三个层次——提示、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 指南就是证据；L1 第一篇把”prompt 敏感”列为七条失效模式之一，讲的就是这个不稳定。 2026 年还有一件事让这个区分更重要：主力模型都是推理模型（L1 第三篇），2023 年的一批经典技巧在它们身上失效甚至有害。”一步步想”对一个默认会思考的模型是冗余的；大量 few-shot 会让 agent ...

Posted by arganzheng | October 7, 2026

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

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

L1 第一篇讲过：模型能可靠利用的上下文远小于它标称的长度，而且长上下文按 token 计费、线性拖慢 TTFT。这一篇从另一头看同一个问题：一次请求里模型到底看到了什么。多数工程师第一次把发给模型的完整请求体打印出来时都会吃惊——用户那句 20 个字的问题外面裹着两万 token 的 system prompt、工具定义、历史、检索结果与工具返回，而其中一半是上一步某个工具返回的原始 JSON。要管理上下文，先要能解剖它。本篇建立一个七层模型：每层是什么、由谁维护、多大、变化多快、能不能压缩——后面五篇的每一种策略（预算、压缩、缓存、版本）都是对某几层的操作。实例用两个公开材料：Claude Code 文档里的”上下文窗口时间线”（一个会话从启动到压缩每一步进...

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 的费用）；重试策略要区分”再试一次可能成功”与”再...