深入理解Agent开发
更新: 10/11/2026 字数: 0 字 时长: 0 分钟
上下文工程
上下文是Agent的眼睛，它包含着Agent能够使用的所有信息，所有的外界信息必须载入到上下文中才可以被Agent使用
官方API的上下文可以分为以下几种：
- 系统提示词: 开发者编写，会被放置在上下文的最顶部，常常会用来定义Agent的行为规则，约束条件等内容，在训练的影响下会被视为最高的优先级
- 用户消息: 用户输入的内容
- 工具调用: 调用工具的结果，tool类消息的回复顺序往往和Agent发起的工具调用的顺序一致，且Tool类消息往往出现在模型回复后
- 模型回复: 模型的回复
目前所有的Agent，上下文都是将整个对话中的这四类消息全部发送给AI，而上下文工程就是对这四类消息处理
ReAct与思维链
目前主流的AI回复方式是用户发起一次消息，AI进入思考，然后针对用户提出的要求发起一次或多次工具调用请求，接着根据返回的工具内容再次进入思考，判断是否要发起其他的工具请求或者退出思考直接返回给用户最终结果
这种形式来自22年的两篇经典论文ReAct和Chain-of-Thought，在早年些年（23年左右），这些功能往往需要智能体实现，而现在已经被LLM内化了
Token
Token是大模型理解上下文的最小单位，大模型理解文本是逐个Token理解的，文本会先被划分为Token，然后再输入给大模型，虽然有四个英文字母一个Token或者一个中文汉字1~1.5个Token的近似计算方式，但实际上Token的划分也是通过学习得来的，并非是机械的划分，而是根据一个词汇的常用度进行划分，一般越长出现的单词越容易被划分为一个完整的Token，比如“你好”就常常被划分为1个Token
Loop
Agent的核心是一个死循环，这个循环又被叫做Loop，最小的实现方式就是根据当前不同的api返回消息处理不同的事情，比如大模型返回的结果中出现了工具调用，Agent就去调用工具，然后返回结果给大模型，接着等待大模型的下一步指令，当大模型返回了所有的文本，则退出循环
KVCache 和 Prompt Cache
KVCache 是理解上下文工程时需要了解的一个基础概念。这里不过多展开底层数学原理，而是用一种形象化的方式进行概述。
大语言模型通常采用自回归的方式生成文本：模型根据已有上下文预测下一个 Token，而新生成的 Token 又会成为后续预测的上下文。
在 Transformer 架构中，注意力机制需要利用此前 Token 的信息来计算当前 Token 的表示。如果每生成一个新 Token，都重新计算此前所有 Token 在各层注意力机制中对应的 Key 和 Value，就会产生大量重复计算。
KVCache 正是为了解决这个问题而存在的。它会缓存此前 Token 在相关注意力层中计算得到的 Key 和 Value 张量。当模型继续生成下一个 Token 时，就可以复用这些缓存的状态，而不必重新计算所有历史 Token 对应的 K、V。
这大幅减少了自回归生成过程中的重复计算，提高了推理效率。
不过，KVCache 通常只在一次推理过程中发挥作用。如果我们在下一次 API 请求中再次提交相同的系统提示词、工具定义和历史上下文，服务端是否还需要重新处理这些内容，就取决于它是否支持跨请求的缓存复用。
Prompt Cache 就是这类机制在 API 服务中的一种应用。服务商可以保存先前处理过的公共前缀对应的 KV 状态，在后续请求满足匹配条件时复用这些状态，避免重复处理相同的前置上下文。
由于缓存命中能够减少重复计算，许多 API 服务商会对缓存读取的输入 Token 提供更低的价格。不过，具体的折扣、缓存写入费用、最小缓存长度和有效期都取决于服务商及所使用的模型。
那么，如何提高 Prompt Cache 的命中率呢？
根据其核心机制，缓存复用通常依赖于请求中完全一致的前缀。如果两个请求的前置上下文一致，而差异只出现在后续部分，就有机会复用共同前缀的缓存；反之，如果前面某部分发生变化，该位置之后的内容通常就无法继续与原缓存匹配。
因此，在构建 Agent 的上下文时，我们应尽可能保持高复用价值的前置上下文稳定，将频繁变化的用户信息、任务参数和其他动态内容放在后面，并尽量通过追加消息而非重写历史来维护对话。
保持前缀稳定，是上下文工程中优化 Prompt Cache 命中率的一项重要实践。 但它不是上下文工程的全部目标：上下文的相关性、信息质量、Token 消耗及缓存策略同样重要。