阿甘的博客 | Arganzheng's Blog

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

Posted by arganzheng | October 4, 2026

模型作为组件（05）：选型——榜单的失真、自己的评测集与供应商的弃用周期

Model Selection Beyond Leaderboards: Your Own Evals, Open vs Closed, Routing and Deprecation Cycles

2026 年 9 月，一个应用工程师面对的候选清单大致是：OpenAI 四个在售的主力模型（GPT-6 Astra、GPT-5.6 Sol / Terra / Luna），Anthropic 四个（Fable 5.1、Opus 5、Sonnet 5、Haiku 4.5），Google 三到四个（3.8 Flash、3.1 Pro、3.5 Flash-Lite），DeepSeek 一个（V4.1 Flash，开放权重），加上 Qwen、Llama、gpt-oss 等开源系列与它们在各云上的托管版本。二十几个模型，价格跨三个量级（第四篇），能力在不同任务上排序不同，每个季度换一代。多数团队的选法是看榜单：Chatbot Arena 第几、某个 benchmark 多...

Posted by arganzheng | October 3, 2026

模型作为组件（04）：成本与延迟的账——一次调用花多少钱、慢在哪一段

The Token Cost and Latency Ledger for LLM Applications

前三篇讲了组件怎么坏、接口长什么样。这一篇算账：一次调用花多少钱、慢在哪一段。这是应用工程师最容易忽略、又最先被账单教育的一层——demo 阶段每天几美元，上线后每天几千美元，而且账单上只有一个数字，看不出钱花在了 system prompt 的重复传输、还是推理模型的思考、还是那个把整份 PDF 塞进上下文的功能。账有两本。成本：四种输入价（未缓存、缓存命中、缓存写入、长上下文加价）加一种输出价（含思考 token），批处理与峰谷的折价，多轮对话不做缓存时的二次增长。延迟：首 token 延迟分解为排队、prefill、思考三段，逐 token 速度由 decode 的内存带宽决定，总时长由输出长度主导——这些只需要 Infra 地图 09 系列前两篇的结论，...

Posted by arganzheng | October 2, 2026

模型作为组件（03）：API 契约（二）——推理模型：thinking、effort 与跨轮的推理状态

The LLM API Contract, Part 2: Reasoning Models — Thinking, Effort and Cross-turn State

到 2026 年，四家的主力模型都是推理模型：GPT-6 Astra 与 GPT-5.6 有 reasoning.effort，Claude 5 系列默认开启 adaptive thinking，Gemini 3.x 有 thinking_level，DeepSeek V4.1 Flash 默认 thinking mode。”推理模型”不再是一个选项，是默认。这给上一篇的契约加了一个维度：模型在给出可见输出之前会先生成一段不可见或半可见的思考，这段思考要花钱（按输出价计费）、要花时间（发生在首 token 之前）、是状态（下一轮要原样送回，否则模型”忘了自己刚才怎么想的”），并且它的多少由一个叫 effort 的参数控制。这一维度带来四个后果，每个都能让一个从非...

Posted by arganzheng | October 1, 2026

模型作为组件（02）：API 契约（一）——消息、工具调用、结构化输出与流式，四家 API 的共同骨架

The LLM API Contract, Part 1: Messages, Tool Calls, Structured Output and Streaming

第一篇讲了组件怎么坏。这一篇讲组件的接口——你和它之间的协议。2026 年，OpenAI、Anthropic、Google、DeepSeek 四家的模型 API 已经收敛成一套共同骨架：一个消息列表进去，一个消息出来；消息可以携带工具调用与工具结果；输出可以被 schema 约束；响应可以流式返回；对话状态可以放在客户端也可以放在服务端。学会这套骨架，换供应商只是改字段名；不学，每换一家都要重新踩一遍坑。但文档不会告诉你三件事。第一，工具调用是一个协议而不是一个功能：模型返回的是”我想调用 X”，执行、配对、把结果送回、决定何时停止，全在你这一侧，出错的地方也全在你这一侧。第二，结构化输出的”严格模式”保证的是语法不是语义：一个符合 schema 的 JSON ...

Posted by arganzheng | September 30, 2026

模型作为组件（01）：失效模式——非确定性、幻觉、上下文与越界，把「模型会出错」拆成七条可检测的性质

Failure Modes of LLMs as Components: Nondeterminism, Hallucination, Context and Overreach

后端工程师接一个新组件，第一件事是读它的失效模式：数据库会死锁、会有脏读，消息队列会重复投递、会乱序，下游服务会超时、会返回 5xx。知道了这些，才知道在自己这一侧该做什么——加重试、做幂等、设超时。大模型这个组件也有一份失效模式清单，只是没有人替你写在文档里。本篇写它。清单上有七条：非确定性（同一输入两次调用结果不同，temperature = 0 也不例外）、幻觉（自信地编造事实、引用、政策）、指令遵循不稳与 prompt 敏感（同样的要求换个说法结果不同，换个模型要重调）、上下文长度的标称与有效之差（标称 1M，有效可能只有几十 K）、知识截止（它不知道最近几个月的事，也不知道今天是几号）、供应商侧的变更（模型名不变，模型换了），以及当组件能执行动作时出现...

Posted by arganzheng | September 29, 2026

模型作为组件：契约、失效模式与选型（总纲）

The Model as a Component: Contract, Failure Modes and Selection

内容简介《模型作为组件：契约、失效模式与选型》是一组共六篇的系列文章，是《AI 应用工程师学习地图》第一层（L1）的正文。它面向有后端工程基础、准备在模型 API 之上做产品的工程师，回答一个看起来简单的问题：当你把一个大模型当作系统里的一个组件时，这个组件的规格书是什么？后端工程师熟悉的组件都有规格书。数据库有隔离级别与一致性保证，消息队列有投递语义（至多一次、至少一次），HTTP 服务有状态码与幂等性约定。这些规格书告诉你组件在什么条件下做什么、怎么失败、失败了你该怎么办。大模型 API 没有这样一份文档——供应商的 API 文档告诉你字段怎么填，不告诉你同一个输入两次调用为什么返回不同的东西、它什么时候会自信地编造、你在第 300K 个 token 放...

Posted by arganzheng | September 28, 2026

Arganzheng's Blog