作者：一位Android开发工程师 | 2026年5月31日
系列：第3天已掌握system prompt，本篇拆解多轮对话的底层原理
前言
前三天我学会了控制LLM的输出行为（temperature）、人格设定（system prompt）、输出格式（JSON/表格）。但这些都是"一问一答"——每次对话互不关联。
今天要解决的问题：怎么让LLM记住上一句说了什么？
核心认知：LLM本身没有记忆
如果你以为LLM自带记忆功能，那就想多了。LLM的"记忆"是一个假象——你只是把之前所有对话塞进messages数组，每次都发回去。
类比Android开发：就像RecyclerView加载更多数据时，不是在新的Adapter里加载，而是往同一个List里追加。messages数组同理。
实验一：多轮面试对话
把面试官的人设写进system prompt，然后模拟三轮面试对话：
messages=[{"role":"system","content":"你是Android面试官，考察Kotlin基础。"},]defchat(user_input):messages.append({"role":"user","content":user_input})response=client.chat.completions.create(model="turing/gpt-4o-mini",messages=messages,# ← 关键：每次都传整个数组)reply=response.choices[0].message.content messages.append({"role":"assistant","content":reply})returnreply注意这行messages=messages——每次请求都把全部历史发回去，而不是只发当前问题。
三轮对话结果
第1轮 你：val和var有什么区别？ 面试官：val是不可变的（类似Java的final），var是可变的... 第2轮 你：那刚才说的val变量，值真的永远不能变吗？ 面试官：引用不可变，但如果引用的是可变对象（如MutableList）， 对象的内容可以改变... ← 引用了第一轮的"val"，给出了更深入的解释 第3轮 你：再回到第一个问题，给我总结一下核心区别 面试官：val=不可变引用，var=可变引用... ← 回到了第一轮的内容第三轮能准确回到第一轮。不是什么魔法，是messages数组里存着完整对话历史。
代价
三轮对话下来，messages 数组涨到了7条：
[0] system: 你是Android面试官... [1] user: val和var有什么区别？ [2] assistant: val不可变，var可变... [3] user: 那刚才说的val变量... [4] assistant: 引用不可变，对象内容可以变... [5] user: 再回到第一个问题... [6] assistant: val=不可变引用...每条消息都占token。对话越长，每轮cost越高。
实验二：决定性实验——带历史vs不带历史
这个实验最能说明问题。先问一个基础问题，再追问一个模糊问题：
第一问：Kotlin的扩展函数是什么？ LLM：在不修改类源码的情况下添加新功能的特性... 追问：给我一个具体的例子 ← 只说"例子"，没说什么的例子方式A：不带历史
messages=[{"role":"user","content":"给我一个具体的例子"}]# 只发了追问本身结果：
LLM：请问您想要什么类型的具体例子呢？生活中的、科学实验的、 还是其他方面的？请提供更多信息...😵 LLM完全不知道你要什么例子——它没看到上一句"扩展函数"。
方式B：带历史
messages=[{"role":"user","content":"Kotlin的扩展函数是什么？"},{"role":"assistant","content":"扩展函数是..."},# 上一轮的完整回答{"role":"user","content":"给我一个具体的例子"},]结果：
LLM：为 List 添加一个扩展函数 sumBy... // Kotlin扩展函数代码示例✅ 它知道你要的是"扩展函数"的例子——因为历史里有上下文。
LLM"记忆"的真相
第1轮：messages 有 2 条 → token少，响应快 第3轮：messages 有 7 条 → token中等 第10轮：messages 有 21 条 → 开始慢 第20轮：messages 有 41 条 → 又慢又贵messages每轮增加user+assistant两条消息，线性增长。第20轮时相当于把前19轮的完整对话全部重新发给LLM——绝大部分token都浪费在重复传输历史消息上。
解决方案：记忆系统（后面会学）
成熟的Agent不会傻傻地把全部历史都发回去。有两种策略：
- 上下文窗口裁剪：只保留最近N轮对话，旧的丢掉
- 长期记忆：把旧对话压缩成摘要存入向量数据库，需要时检索
这就像Android的LruCache——内存有限，只保留最近最常用的，旧的存入磁盘。
今天的一句话总结
LLM没有记忆——它看起来记住了上下文，只是因为你把全部历史对话塞进messages数组每次发回去。对话越长越贵，需要记忆系统来优化。
阶段性总结
四天学完，一次完整LLM API调用的全部要素已经齐了：
response=client.chat.completions.create(model="...",# 第1天：模型选择messages=[# 第1天：消息数组{...},# 第3天：system人设/格式/约束{...},{...},# 第4天：历史对话（多轮记忆）],temperature=0.3,# 第2天：创造力控制max_tokens=250,# 第2天：长度限制)六个参数覆盖了单次API调用的全部要素。后面Agent、RAG、工具调用，都在这基础上扩展。
下一篇预告
第5天：Few-shot提示——给LLM看几个例子，让它模仿格式输出。Prompt Engineering的最后一个核心技巧。
本系列记录一位Android开发者转行AI Agent的完整学习过程，欢迎关注交流。
