大模型 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:设计原理与工程实践》(李博杰)阅读过程中的理解与讨论。

相关推荐
漂流瓶jz5 小时前
【AI】大模型本地部署与量化:Ollama、transformers、llama.cpp实践
人工智能·llm·ai编程
飞哥数智坊6 小时前
AI时代,我们到底该学什么、用什么,为什么还没提效?
人工智能
飞哥数智坊6 小时前
GPT 做架构,国内模型写代码:这条 AI 开发路线能跑通吗?
人工智能·ai编程
AI_AGENT_DEV_AI7 小时前
AI 智能体的开发与上线
人工智能
VL——MOESR7 小时前
【具身智能】VLA论文阅读随笔
论文阅读·人工智能·机器学习·具身智能·vla
OCR_133716212757 小时前
从模板匹配到AI泛化识别:文本抽取如何重构护照阅读器落地生态
人工智能·重构
大唐荣华7 小时前
从OpenAI关停Sora看世界模型、AI视频与国内具身智能赛道路线分化
人工智能·openai·sora·内容生成
DevOps老兵7 小时前
AI Infra实战02:GPU监控实战,用DCGM+Prometheus+Grafana看清每一张卡
人工智能·grafana·prometheus·ai infra·gpu监控·dcgm
旧日之血_Hayter7 小时前
Antigravity 工作流的实践记录
人工智能
dozenyaoyida7 小时前
AI与大模型新闻日报 | 2026-09-01
人工智能·ai·大模型·新闻