Agent循环里，上下文是怎么涨起来的
用户只回了一句“还是没声”
比特严选的用户来问：
我上周买的AirPods Pro左耳突然没声音了，放回充电盒也没用，你帮我看看是不是坏了，要是修不好我想退。
Agent查了订单和故障排查资料，让用户先做一步检查。用户操作后，只回了一句：
还是没声。
要接着处理，模型得知道他在检查哪副耳机、刚才试过什么，还得记得最初那个“修不好想退”的要求。只把“还是没声”发过去，信息显然不够。
所以，后端再次调用模型时，会把前面的必要内容一起带上。这些随请求交给模型的信息，就是咱们要讨论的上下文。
聊天继续，工具继续查，带过去的内容也会越来越多。有些还要用，有些已经用完，还有些被用户的新决定推翻了。记忆系统要处理的，就是这些信息怎么留、怎么省，以及换一个会话后还要带上什么。
模型这一次到底能看见什么
用户最新发来的消息，只是模型输入的一部分。在Ragent里，一次请求通常还会带上业务规则、工具说明和之前的处理记录。
先把内容列出来，沿用刚才的耳机咨询：
| 发给模型的内容 | 在这个例子里是什么 | 用来做什么 |
|---|---|---|
| 人设与行为规则 | 你是比特严选助手，业务数据要查询，不确定的信息要追问 | 告诉模型该怎样处理问题 |
| 本次可用的工具声明 | 查订单、查知识库等工具的名称、用途和参数 | 告诉模型能调用什么 |
| 用户消息和助手回复 | 最初的故障描述、给过的排查建议、最新的“还是没声” | 把前后对话接起来 |
| 已发生的工具调用与结果 | 查询订单时传了什么参数、查到了什么；检索返回了哪些排查说明 | 告诉模型已经做过什么、拿到了什么信息 |
| 模型返回的推理内容（视接口要求而定） | 查订单前的分析、读到查询结果后的判断 | 在接口要求时，一起发回，让模型继续处理 |
| 历史摘要（如果有） | 早期聊过的目标、试过的办法和还没解决的事 | 用较短的文字保留早期进度 |
| 用户长期记忆（如果有） | 用户此前表达过的稳定偏好，例如更喜欢头戴式耳机 | 在新会话里也能参考用户的偏好 |
图里的调用参数，用来控制这次生成的方式，例如输出长度。它们也是请求的一部分，但不属于需要保存的聊天内容。
1. 工具说明和工具结果，要分开看
工具说明相当于一份使用说明：这个工具能查什么，要传什么参数。它让模型知道有路可查，却没有提前给出查询答案。
工具结果则是查完以后拿回来的内容。比如query_order的声明说明它能查订单；调用后返回的商品、订单状态，才是这次查询得到的信息。
一个工具还没用过，它的声明就已经在输入里了。工具用过之后，模型发出的调用请求和工具返回的结果，也会被加入后续上下文，占用输入空间。
知识库也通过这个方式进入上下文。Ragent的search_knowledge调用原有的RAG链路，把根据资料整理出的答案交给Agent。按需加载的技能手册，正文同样通过工具结果进入。
2. 模型收到的历史，不只有聊天窗口里的对话
比如查完订单，用户可能只看到一句“订单已签收”。但下一次调用模型时，程序还会带上：刚才调用了哪个工具、查询了哪个订单，以及工具返回的订单详情。这些内容不一定完整展示在聊天窗口里，却会一起发给模型。
如果没查到订单，“未找到订单”这个结果也会留下。模型看到它，就知道上一次查询没有成功，需要核对订单号或换个办法。把失败结果删掉，模型就可能用同样的参数再查一遍。
有些模型接口还会返回推理内容。如果接口要求后续请求带上这部分内容，程序也要一并发送。
判断上下文有多长，不能只看聊天窗口里有多少字。一次工具查询就可能加入一大段内容，即使助手最后只回复了一句话。
3. 存过的信息，需要取出来才能用
订单在数据库里，得查出来交给模型；偏好已经存成长期记忆，也得读取后放进请求。存储负责留住信息，上下文负责把这次要用的信息交给模型。
用户只问了一次，上下文也会增长
1. 回复用户之前，模型已经被调用了几次
还是前面耳机没声音的例子。假设这次要先查订单，再查故障排查资料，最后给用户建议。这个过程要调用三次模型。
调用工具前，模型可能先分析要查什么；拿到结果后，也可能再分析下一步怎么办。有些模型接口会返回这些推理内容，并要求后续请求把它们一起发回。
第一次调用，模型读到用户的问题，分析后决定先查订单。程序收到推理内容和查询请求，再调用工具去查订单。
订单查到了，还得交给模型看，才能决定下一步。于是程序发起第二次调用：把用户的问题、刚才返回的推理内容、查询请求和订单详情一起发过去。模型看过订单后，继续分析，再返回新的推理内容和查询故障排查资料的请求。
资料查回来后，程序发起第三次调用：在前面这些内容后面，再加上第二次返回的推理内容、查资料的请求和排查说明。模型继续分析，最后给用户一步操作建议。
到这里，用户还没有发第二句话。上下文里却已经多了查询请求、工具结果，以及需要再次发送的推理内容。如果每次返回的推理内容都很长，即使工具只查回几行数据，后续请求也可能明显变长。
是否需要再次发送推理内容，要看具体接口。例如，按 DeepSeek当前的思考模式文档，请求带有工具声明时，后续请求需要回传历史推理内容。
下一章讲解工具裁剪时，会详细介绍DeepSeek在工具调用中的思考机制。
