大模型 API 核心概念笔记

读《深入理解 AI Agent:设计原理与工程实践》随记


1. 模型是无状态的

核心结论:模型无状态,上下文靠框架维护。

模型每次被调用,都是"全新的"------它不记得上一次对话说了什么。就像一个失忆症患者,每次见面都得重新自我介绍。

因此,Agent 框架必须每次都把完整的对话历史打包发给模型

多轮对话示例

第一轮调用:

css 复制代码
messages: [
  { "role": "system",    "content": "你是一个编程助手" },
  { "role": "user",      "content": "你好,你是谁?" }
]

第二轮调用(必须带上历史):

css 复制代码
messages: [
  { "role": "system",    "content": "你是一个编程助手" },
  { "role": "user",      "content": "你好,你是谁?" },
  { "role": "assistant", "content": "我是编程助手,有什么可以帮你?" },
  { "role": "user",      "content": "帮我写个冒泡排序" }
]

如果只发最后一条,模型完全不知道前面聊了什么,上下文全丢了。


2. 消息的四种角色

角色 谁写的 作用
system 开发者 定义模型的"人设"和行为规则,通常只有一条,放在最前面
user 用户 用户的输入和请求
assistant 模型(上一轮) 模型之前的回答,拼回去让它"记住"自己说过什么
tool Agent 框架 工具执行完的结果,通过 tool_call_id 与对应请求关联

3. 模型 vs Agent 框架

模型只动嘴,框架负责动手。

  • 模型(LLM) :只负责"想"------读消息、推理、输出文字或工具调用请求。它本身什么也不执行。
  • Agent 框架:围绕模型跑的代码,负责维护 messages 列表、真正执行工具、把结果塞回 messages、决定是否再次调用模型。

4. 工具调用的完整流程(ReAct 循环的 API 实现)

以"Vancouver 现在天气怎么样?"为例:

复制代码
第一次调用
  用户提问 → 发给模型
  模型返回:我需要调用 get_weather 和 get_current_time(并行)

Agent 框架执行两个工具,拿到结果

第二次调用
  把工具结果追加到 messages → 再发给模型
  模型读到结果 → 直接回答用户

模型返回工具调用时,contentnull,实际指令在 tool_calls 字段里:

python 复制代码
{
  "role": "assistant",
  "content": null,
  "tool_calls": [
    {
      "id": "call_abc123",
      "function": {
        "name": "get_current_time",
        "arguments": "{"timezone": "America/Vancouver"}"
      }
    }
  ]
}

这个"请求 → 工具调用 → 执行 → 送回结果 → 再请求"的循环,就是 ReAct 循环(Reason → Act → Observe)在 API 层面的具体实现。


5. API 返回格式:为什么是 choices

API 返回的顶层是 choices 数组,因为支持 n=3 这样的参数,让模型一次生成多个候选回答供你挑选。

实际开发中 99% 的情况都是 n=1(默认),直接取 choices[0].message 即可。

包一层数组是为了格式统一------不管要 1 个还是 N 个回复,调用方的处理代码不需要做特殊判断。


6. KV Cache 与首 Token 延迟(TTFT)

首 Token(TTFT)

TTFT = Time To First Token,即从发出请求到第一个字出现的等待时间。

名字虽然带 token,说的是时间,是衡量响应速度的延迟指标。

KV Cache

模型处理每个 token 时,会产生 Key 和 Value 两种中间计算结果。

  • 没有 KV Cache:每次调用都从头重新计算所有 token,包括 system prompt 和历史对话------慢。
  • 有 KV Cache:把算过的 K、V 缓存起来,下次复用,只计算新增的 token------快。

两者关系

messages 中已存在的 token(system prompt、历史对话)→ 直接读 KV Cache,跳过计算。

新增的 token(新的用户输入)→ 实时计算。

实际效果:

  • 第一次请求慢(冷启动,无缓存)
  • 后续请求快(命中缓存,复用已有计算)
  • 对话轮次越多,KV Cache 命中比例越高,TTFT 反而越稳定

这也是为什么 system prompt 要放在 messages 最前面------它永远不变,最容易被缓存复用。


笔记整理自《深入理解 AI Agent:设计原理与工程实践》(李博杰)阅读过程中的理解与讨论。

相关推荐
hrrrrxeeeee1 小时前
业务岗简历 AI 加分指南:CAIE、国考证书搭配量化案例写法
人工智能
yingyuecom1 小时前
Hi,导演:AI视频创作正在从“模型调用”走向“生产工作流”
大数据·人工智能
雨晨源码(同名B站)1 小时前
基于深度学习YoloV11农业病害虫害检测系统 智慧农业信息化综合管理平台 (附源码+lw文档+ppt)
数据库·人工智能·深度学习·yolo·信息可视化
weixin_446260852 小时前
列表式交叉编码器微调 vs 智能体指令优化大模型重排器:医保医疗流程重排序系统性研究
人工智能
liuyunshengsir2 小时前
从 TVM 到 TileLang:一文读懂深度学习编译器为什么走向 Tile 化
人工智能·深度学习·tvm·tilelang
海天一色y2 小时前
GSPO:重新定义大语言模型的强化学习训练范式
人工智能·机器学习·语言模型
云和数据.ChenGuang2 小时前
fastapi项目拆分实战数据模型
java·服务器·数据库·人工智能·深度学习·fastapi·强化学习
watersink3 小时前
机器学习HMM
人工智能·机器学习