问题#

什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？

标准回答#

什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。因为 Agent 的上下文里得塞的东西太多了：System Prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型回复留空间。一次 Agent 运行可能跑几十轮，每一轮工具调用的结果都会追加到历史里，context 像滚雪球一样越来越大。这就是它成为 Agent 工程中最核心约束的原因：算力够，但是装不下那么多信息。一旦超出窗口，要么直接报错中断任务，要么被迫裁剪历史导致关键信息丢失，Agent 的行为就会变得不可预测。

扩展知识#

Context Window 里到底塞了什么要理解为什么 Context 这么容易爆，得先搞清楚一次 Agent 请求里到底塞了哪些内容。拿一个典型的编程 Agent 来说：System Prompt 通常就有 2000-5000 token，包含角色设定、行为约束、输出格式要求。工具定义也不小，每个工具的 JSON Schema 描述大概 200-500 token，注册 20 个工具就是 4000-10000 token。这两块是固定开销，每次请求都得带。真正吃 token 的是对话历史。Agent 每调一次工具，history 里就多两条消息：一条是 LLM 的 tool_call 请求，一条是工具的执行结果。如果工具返回的是一整个文件的内容，一条消息就可能占掉 3000-8000 token。跑 10 轮下来，对话历史轻松突破 50K token。OpenClaw 在src/agents/context.ts里把这些组成部分拆分得很清楚，按优先级管理每一块的空间占用。OpenClaw 的 Context Window 管理机制OpenClaw 通过多个来源确定窗口大小，优先级从高到低是：modelsConfig里用户显式指定的值 > 从模型注册表自动发现的值 > 默认的 128K token。同时可以用agents.defaults.contextTokens做全局上限截断。系统设了两道防线：1）硬下限CONTEXT_WINDOW_HARD_MIN_TOKENS = 16,000，低于这个值直接拒绝运行，因为 Agent 在这么小的窗口里基本没法正常工作2）软告警CONTEXT_WINDOW_WARN_BELOW_TOKENS = 32,000，低于这个值会警告用户可能影响效果当检测到 context overflow 时，OpenClaw 按优先级逐步处理：先尝试compaction，把早期的对话历史压缩成摘要再尝试截断过大的 tool result，比如一个文件读取返回了 5000 行，只保留头尾加摘要最后才报错建议用户/reset或换更大窗口的模型。这种渐进式降级比直接截断要优雅得多。主流的 Context 管理策略除了 OpenClaw 的做法，业界还有几种常见方案：1）滑动窗口：只保留最近 N 轮对话，早期的直接丢掉。实现最简单，但容易丢失任务关键信息，比如用户最初的需求描述2）摘要压缩：用一次额外的 LLM 调用把长对话压缩成一段摘要。效果好，但有额外的延迟和 token 成本，压缩过程本身也可能丢失细节3）分层存储：把不同类型的上下文分优先级，System Prompt 和最近 2 轮永远保留，中间的历史做摘要，工具返回的大文本做截断4）外部检索：把历史存到向量数据库，每轮只从里面检索最相关的片段填入 context。Retrieval-augmented 的思路，适合超长会话实际生产中一般是混合使用，不会只依赖单一策略。token 计算的坑token 数不等于字符数，也不等于词数，这中间有不少坑。英文文本平均 1 个 token 约等于 4 个字符，中文文本 1 个汉字通常会被切成 2-3 个 token。同样一段中文内容，token 开销比等长的英文内容高 2-3 倍。更麻烦的是，不同模型的 tokenizer 不一样。同一段文本在 GPT 和 Claude 里算出来的 token 数可能差 10%-20%。所以你不能简单地拿一个 tokenizer 算完就完了，得根据实际使用的模型来校准。OpenClaw 对此的做法是用各模型对应的 tokenizer 做精确计算，同时留出 10% 的安全余量，防止因为计算误差导致请求被截断。

面试官追问#

• 提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
• 回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
• 回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方 Agent 的上下文里塞了很多东西：System prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型留回复空间。一次Agent可能跑很多伦，每一轮的结果都追加到历史里，展开新页面打开2026-03-14 12:0300回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
  代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

Context Window 里到底塞了什么OpenClaw 的 Context Window 管理机制主流的 Context 管理策略token 计算的坑

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

答案#

如何实现 AI 多轮对话功能？如何解决对话记忆持久化问题？如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈什么是结构化输出？Spring AI 是怎么实现结构化输出的？什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？什么是 Spring AI 框架？它有哪些核心特性？上次浏览：2026-03-18 18:41:27什么是 AI Agent？它和直接调用大模型 API 做一次问答有什么本质区别？请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？OpenClaw 是什么？它要解决什么问题？它的核心能力有哪些？上次浏览：2026-03-16 15:12:52OpenClaw 的核心组件有哪些？请描述它们之间的关系上次浏览：2026-03-16 15:15:2813223. 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。因为 Agent 的上下文里得塞的东西太多了：System Prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型回复留空间。一次 Agent 运行可能跑几十轮，每一轮工具调用的结果都会追加到历史里，context 像滚雪球一样越来越大。这就是它成为 Agent 工程中最核心约束的原因：算力够，但是装不下那么多信息。一旦超出窗口，要么直接报错中断任务，要么被迫裁剪历史导致关键信息丢失，Agent 的行为就会变得不可预测。

Context Window 里到底塞了什么要理解为什么 Context 这么容易爆，得先搞清楚一次 Agent 请求里到底塞了哪些内容。拿一个典型的编程 Agent 来说：System Prompt 通常就有 2000-5000 token，包含角色设定、行为约束、输出格式要求。工具定义也不小，每个工具的 JSON Schema 描述大概 200-500 token，注册 20 个工具就是 4000-10000 token。这两块是固定开销，每次请求都得带。真正吃 token 的是对话历史。Agent 每调一次工具，history 里就多两条消息：一条是 LLM 的 tool_call 请求，一条是工具的执行结果。如果工具返回的是一整个文件的内容，一条消息就可能占掉 3000-8000 token。跑 10 轮下来，对话历史轻松突破 50K token。OpenClaw 在src/agents/context.ts里把这些组成部分拆分得很清楚，按优先级管理每一块的空间占用。OpenClaw 的 Context Window 管理机制OpenClaw 通过多个来源确定窗口大小，优先级从高到低是：modelsConfig里用户显式指定的值 > 从模型注册表自动发现的值 > 默认的 128K token。同时可以用agents.defaults.contextTokens做全局上限截断。系统设了两道防线：1）硬下限CONTEXT_WINDOW_HARD_MIN_TOKENS = 16,000，低于这个值直接拒绝运行，因为 Agent 在这么小的窗口里基本没法正常工作2）软告警CONTEXT_WINDOW_WARN_BELOW_TOKENS = 32,000，低于这个值会警告用户可能影响效果当检测到 context overflow 时，OpenClaw 按优先级逐步处理：先尝试compaction，把早期的对话历史压缩成摘要再尝试截断过大的 tool result，比如一个文件读取返回了 5000 行，只保留头尾加摘要最后才报错建议用户/reset或换更大窗口的模型。这种渐进式降级比直接截断要优雅得多。主流的 Context 管理策略除了 OpenClaw 的做法，业界还有几种常见方案：1）滑动窗口：只保留最近 N 轮对话，早期的直接丢掉。实现最简单，但容易丢失任务关键信息，比如用户最初的需求描述2）摘要压缩：用一次额外的 LLM 调用把长对话压缩成一段摘要。效果好，但有额外的延迟和 token 成本，压缩过程本身也可能丢失细节3）分层存储：把不同类型的上下文分优先级，System Prompt 和最近 2 轮永远保留，中间的历史做摘要，工具返回的大文本做截断4）外部检索：把历史存到向量数据库，每轮只从里面检索最相关的片段填入 context。Retrieval-augmented 的思路，适合超长会话实际生产中一般是混合使用，不会只依赖单一策略。token 计算的坑token 数不等于字符数，也不等于词数，这中间有不少坑。英文文本平均 1 个 token 约等于 4 个字符，中文文本 1 个汉字通常会被切成 2-3 个 token。同样一段中文内容，token 开销比等长的英文内容高 2-3 倍。更麻烦的是，不同模型的 tokenizer 不一样。同一段文本在 GPT 和 Claude 里算出来的 token 数可能差 10%-20%。所以你不能简单地拿一个 tokenizer 算完就完了，得根据实际使用的模型来校准。OpenClaw 对此的做法是用各模型对应的 tokenizer 做精确计算，同时留出 10% 的安全余量，防止因为计算误差导致请求被截断。

• 提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
• 回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
• 回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方 Agent 的上下文里塞了很多东西：System prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型留回复空间。一次Agent可能跑很多伦，每一轮的结果都追加到历史里，展开新页面打开2026-03-14 12:0300回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
  代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

Context Window 里到底塞了什么OpenClaw 的 Context Window 管理机制主流的 Context 管理策略token 计算的坑

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

来源: 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？.mhtml

关键点#

• 什么是 Agent 的 Context Window？#

• 为什么它是 Agent 工程中最核心的约束之一？

• 问题#

什么是 Agent 的 Context Window？

• 为什么它是 Agent 工程中最核心的约束之一？
• NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。

备注#

• 本文已做格式统一与噪声清理，保留原始语义。

• 问题#

什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？

• 标准回答#

• 问题#

什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。因为 Agent 的上下文里得塞的东西太多了：System Prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型回复留空间。一次 Agent 运行可能跑几十轮，每一轮工具调用的结果都会追加到历史里，context 像滚雪球一样越来越大。这就是它成为 Agent 工程中最核心约束的原因：算力够，但是装不下那么多信息。一旦超出窗口，要么直接报错中断任务，要么被迫裁剪历史导致关键信息丢失，Agent 的行为就会变得不可预测。

Context Window 里到底塞了什么要理解为什么 Context 这么容易爆，得先搞清楚一次 Agent 请求里到底塞了哪些内容。拿一个典型的编程 Agent 来说：System Prompt 通常就有 2000-5000 token，包含角色设定、行为约束、输出格式要求。工具定义也不小，每个工具的 JSON Schema 描述大概 200-500 token，注册 20 个工具就是 4000-10000 token。这两块是固定开销，每次请求都得带。真正吃 token 的是对话历史。Agent 每调一次工具，history 里就多两条消息：一条是 LLM 的 tool_call 请求，一条是工具的执行结果。如果工具返回的是一整个文件的内容，一条消息就可能占掉 3000-8000 token。跑 10 轮下来，对话历史轻松突破 50K token。OpenClaw 在src/agents/context.ts里把这些组成部分拆分得很清楚，按优先级管理每一块的空间占用。OpenClaw 的 Context Window 管理机制OpenClaw 通过多个来源确定窗口大小，优先级从高到低是：modelsConfig里用户显式指定的值 > 从模型注册表自动发现的值 > 默认的 128K token。同时可以用agents.defaults.contextTokens做全局上限截断。系统设了两道防线：1）硬下限CONTEXT_WINDOW_HARD_MIN_TOKENS = 16,000，低于这个值直接拒绝运行，因为 Agent 在这么小的窗口里基本没法正常工作2）软告警CONTEXT_WINDOW_WARN_BELOW_TOKENS = 32,000，低于这个值会警告用户可能影响效果当检测到 context overflow 时，OpenClaw 按优先级逐步处理：先尝试compaction，把早期的对话历史压缩成摘要再尝试截断过大的 tool result，比如一个文件读取返回了 5000 行，只保留头尾加摘要最后才报错建议用户/reset或换更大窗口的模型。这种渐进式降级比直接截断要优雅得多。主流的 Context 管理策略除了 OpenClaw 的做法，业界还有几种常见方案：1）滑动窗口：只保留最近 N 轮对话，早期的直接丢掉。实现最简单，但容易丢失任务关键信息，比如用户最初的需求描述2）摘要压缩：用一次额外的 LLM 调用把长对话压缩成一段摘要。效果好，但有额外的延迟和 token 成本，压缩过程本身也可能丢失细节3）分层存储：把不同类型的上下文分优先级，System Prompt 和最近 2 轮永远保留，中间的历史做摘要，工具返回的大文本做截断4）外部检索：把历史存到向量数据库，每轮只从里面检索最相关的片段填入 context。Retrieval-augmented 的思路，适合超长会话实际生产中一般是混合使用，不会只依赖单一策略。token 计算的坑token 数不等于字符数，也不等于词数，这中间有不少坑。英文文本平均 1 个 token 约等于 4 个字符，中文文本 1 个汉字通常会被切成 2-3 个 token。同样一段中文内容，token 开销比等长的英文内容高 2-3 倍。更麻烦的是，不同模型的 tokenizer 不一样。同一段文本在 GPT 和 Claude 里算出来的 token 数可能差 10%-20%。所以你不能简单地拿一个 tokenizer 算完就完了，得根据实际使用的模型来校准。OpenClaw 对此的做法是用各模型对应的 tokenizer 做精确计算，同时留出 10% 的安全余量，防止因为计算误差导致请求被截断。

• 提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
• 回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
• 回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方 Agent 的上下文里塞了很多东西：System prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型留回复空间。一次Agent可能跑很多伦，每一轮的结果都追加到历史里，展开新页面打开2026-03-14 12:0300回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
  代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

Context Window 里到底塞了什么OpenClaw 的 Context Window 管理机制主流的 Context 管理策略token 计算的坑

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

如何实现 AI 多轮对话功能？如何解决对话记忆持久化问题？如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈什么是结构化输出？Spring AI 是怎么实现结构化输出的？什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？什么是 Spring AI 框架？它有哪些核心特性？上次浏览：2026-03-18 18:41:27什么是 AI Agent？它和直接调用大模型 API 做一次问答有什么本质区别？请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？OpenClaw 是什么？它要解决什么问题？它的核心能力有哪些？上次浏览：2026-03-16 15:12:52OpenClaw 的核心组件有哪些？请描述它们之间的关系上次浏览：2026-03-16 15:15:2813223. 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。因为 Agent 的上下文里得塞的东西太多了：System Prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型回复留空间。一次 Agent 运行可能跑几十轮，每一轮工具调用的结果都会追加到历史里，context 像滚雪球一样越来越大。这就是它成为 Agent 工程中最核心约束的原因：算力够，但是装不下那么多信息。一旦超出窗口，要么直接报错中断任务，要么被迫裁剪历史导致关键信息丢失，Agent 的行为就会变得不可预测。

Context Window 里到底塞了什么要理解为什么 Context 这么容易爆，得先搞清楚一次 Agent 请求里到底塞了哪些内容。拿一个典型的编程 Agent 来说：System Prompt 通常就有 2000-5000 token，包含角色设定、行为约束、输出格式要求。工具定义也不小，每个工具的 JSON Schema 描述大概 200-500 token，注册 20 个工具就是 4000-10000 token。这两块是固定开销，每次请求都得带。真正吃 token 的是对话历史。Agent 每调一次工具，history 里就多两条消息：一条是 LLM 的 tool_call 请求，一条是工具的执行结果。如果工具返回的是一整个文件的内容，一条消息就可能占掉 3000-8000 token。跑 10 轮下来，对话历史轻松突破 50K token。OpenClaw 在src/agents/context.ts里把这些组成部分拆分得很清楚，按优先级管理每一块的空间占用。OpenClaw 的 Context Window 管理机制OpenClaw 通过多个来源确定窗口大小，优先级从高到低是：modelsConfig里用户显式指定的值 > 从模型注册表自动发现的值 > 默认的 128K token。同时可以用agents.defaults.contextTokens做全局上限截断。系统设了两道防线：1）硬下限CONTEXT_WINDOW_HARD_MIN_TOKENS = 16,000，低于这个值直接拒绝运行，因为 Agent 在这么小的窗口里基本没法正常工作2）软告警CONTEXT_WINDOW_WARN_BELOW_TOKENS = 32,000，低于这个值会警告用户可能影响效果当检测到 context overflow 时，OpenClaw 按优先级逐步处理：先尝试compaction，把早期的对话历史压缩成摘要再尝试截断过大的 tool result，比如一个文件读取返回了 5000 行，只保留头尾加摘要最后才报错建议用户/reset或换更大窗口的模型。这种渐进式降级比直接截断要优雅得多。主流的 Context 管理策略除了 OpenClaw 的做法，业界还有几种常见方案：1）滑动窗口：只保留最近 N 轮对话，早期的直接丢掉。实现最简单，但容易丢失任务关键信息，比如用户最初的需求描述2）摘要压缩：用一次额外的 LLM 调用把长对话压缩成一段摘要。效果好，但有额外的延迟和 token 成本，压缩过程本身也可能丢失细节3）分层存储：把不同类型的上下文分优先级，System Prompt 和最近 2 轮永远保留，中间的历史做摘要，工具返回的大文本做截断4）外部检索：把历史存到向量数据库，每轮只从里面检索最相关的片段填入 context。Retrieval-augmented 的思路，适合超长会话实际生产中一般是混合使用，不会只依赖单一策略。token 计算的坑token 数不等于字符数，也不等于词数，这中间有不少坑。英文文本平均 1 个 token 约等于 4 个字符，中文文本 1 个汉字通常会被切成 2-3 个 token。同样一段中文内容，token 开销比等长的英文内容高 2-3 倍。更麻烦的是，不同模型的 tokenizer 不一样。同一段文本在 GPT 和 Claude 里算出来的 token 数可能差 10%-20%。所以你不能简单地拿一个 tokenizer 算完就完了，得根据实际使用的模型来校准。OpenClaw 对此的做法是用各模型对应的 tokenizer 做精确计算，同时留出 10% 的安全余量，防止因为计算误差导致请求被截断。

• 提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
• 回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
• 回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方 Agent 的上下文里塞了很多东西：System prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型留回复空间。一次Agent可能跑很多伦，每一轮的结果都追加到历史里，展开新页面打开2026-03-14 12:0300回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
  代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

Context Window 里到底塞了什么OpenClaw 的 Context Window 管理机制主流的 Context 管理策略token 计算的坑

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

来源: 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？.mhtml

• 什么是 Agent 的 Context Window？#

• • 为什么它是 Agent 工程中最核心的约束之一？

• • 问题#

什么是 Agent 的 Context Window？

• 本文已做格式统一与噪声清理，保留原始语义。
• 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？

• 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？#

• 13223. 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。因为 Agent 的上下文里得塞的东西太多了：System Prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型回复留空间。一次 Agent 运行可能跑几十轮，每一轮工具调用的结果都会追加到历史里，context 像滚雪球一样越来越大。这就是它成为 Agent 工程中最核心约束的原因：算力够，但是装不下那么多信息。一旦超出窗口，要么直接报错中断任务，要么被迫裁剪历史导致关键信息丢失，Agent 的行为就会变得不可预测。

Context Window 里到底塞了什么要理解为什么 Context 这么容易爆，得先搞清楚一次 Agent 请求里到底塞了哪些内容。拿一个典型的编程 Agent 来说：System Prompt 通常就有 2000-5000 token，包含角色设定、行为约束、输出格式要求。工具定义也不小，每个工具的 JSON Schema 描述大概 200-500 token，注册 20 个工具就是 4000-10000 token。这两块是固定开销，每次请求都得带。真正吃 token 的是对话历史。Agent 每调一次工具，history 里就多两条消息：一条是 LLM 的 tool_call 请求，一条是工具的执行结果。如果工具返回的是一整个文件的内容，一条消息就可能占掉 3000-8000 token。跑 10 轮下来，对话历史轻松突破 50K token。OpenClaw 在src/agents/context.ts里把这些组成部分拆分得很清楚，按优先级管理每一块的空间占用。OpenClaw 的 Context Window 管理机制OpenClaw 通过多个来源确定窗口大小，优先级从高到低是：modelsConfig里用户显式指定的值 > 从模型注册表自动发现的值 > 默认的 128K token。同时可以用agents.defaults.contextTokens做全局上限截断。系统设了两道防线：1）硬下限CONTEXT_WINDOW_HARD_MIN_TOKENS = 16,000，低于这个值直接拒绝运行，因为 Agent 在这么小的窗口里基本没法正常工作2）软告警CONTEXT_WINDOW_WARN_BELOW_TOKENS = 32,000，低于这个值会警告用户可能影响效果当检测到 context overflow 时，OpenClaw 按优先级逐步处理：先尝试compaction，把早期的对话历史压缩成摘要再尝试截断过大的 tool result，比如一个文件读取返回了 5000 行，只保留头尾加摘要最后才报错建议用户/reset或换更大窗口的模型。这种渐进式降级比直接截断要优雅得多。主流的 Context 管理策略除了 OpenClaw 的做法，业界还有几种常见方案：1）滑动窗口：只保留最近 N 轮对话，早期的直接丢掉。实现最简单，但容易丢失任务关键信息，比如用户最初的需求描述2）摘要压缩：用一次额外的 LLM 调用把长对话压缩成一段摘要。效果好，但有额外的延迟和 token 成本，压缩过程本身也可能丢失细节3）分层存储：把不同类型的上下文分优先级，System Prompt 和最近 2 轮永远保留，中间的历史做摘要，工具返回的大文本做截断4）外部检索：把历史存到向量数据库，每轮只从里面检索最相关的片段填入 context。Retrieval-augmented 的思路，适合超长会话实际生产中一般是混合使用，不会只依赖单一策略。token 计算的坑token 数不等于字符数，也不等于词数，这中间有不少坑。英文文本平均 1 个 token 约等于 4 个字符，中文文本 1 个汉字通常会被切成 2-3 个 token。同样一段中文内容，token 开销比等长的英文内容高 2-3 倍。更麻烦的是，不同模型的 tokenizer 不一样。同一段文本在 GPT 和 Claude 里算出来的 token 数可能差 10%-20%。所以你不能简单地拿一个 tokenizer 算完就完了，得根据实际使用的模型来校准。OpenClaw 对此的做法是用各模型对应的 tokenizer 做精确计算，同时留出 10% 的安全余量，防止因为计算误差导致请求被截断。

• 提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
• 回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
• 回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方- Agent 的上下文里塞了很多东西：System prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型留回复空间。一次Agent可能跑很多伦，每一轮的结果都追加到历史里，展开新页面打开2026-03-14 12:0300回复添加回答编辑预览请输入回答内容…（支持使用 Markdown ）xMarkdown 语法一级标题# 标题二级标题## 标题三级标题### 标题粗体粗体文本斜体斜体文本引用> 引用文本链接链接描述图片
  代码代码代码块编程语言↵无序列表- 项目有序列表1. 项目分割线---删除线~~文本~~任务列表- [ ] 待办事项行内公式$公式$块级公式$$↵公式↵$$Mermaid图表mermaid快捷键粗体Ctrl-B斜体Ctrl-I链接Ctrl-K图片Shift-Ctrl-I代码Shift-Ctrl-K代码块Shift-Ctrl-C无序列表Shift-Ctrl-U有序列表Shift-Ctrl-O目录字数:0行数:1回到顶部提交目录

Context Window 里到底塞了什么OpenClaw 的 Context Window 管理机制主流的 Context 管理策略token 计算的坑

提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？热门面试题目榜更多说说 Java 中 HashMap 的原理？9130Java 中的序列化和反序列化是什么？6255MySQL 索引的最左前缀匹配原则是什么？5662Java 中 ConcurrentHashMap 1.7 和 1.8 之间有哪些区别？5067Java 中有哪些集合类？请简单介绍4854MySQL 的索引类型有哪些？4845详细描述一条 SQL 语句在 MySQL 中的执行过程。4218什么是 RAG？RAG 的主要流程是什么？4151MySQL 的存储引擎有哪些？它们之间有什么区别？4092数据库的脏读、不可重复读和幻读分别是什么？3900推荐教程更多AI 超级智能体亿级流量点赞系统教程智能协同云图库项目教程预览用户交流一起刷题学习、求职交流、反馈建议、获取更新通知面试鸭《用户协议》《隐私政策》友情链接编程导航老鱼简历代码小抄剪切助手联系我们商务合作站长：程序员鱼皮关注我们扫码关注面试鸭公众号

• 如何实现 AI 多轮对话功能？如何解决对话记忆持久化问题？如果一个GPU集群的LLM处理能力为1000tokens/s，那1000个用户同时并发访问，响应给每个用户的性能只有1 token/s吗？怎么分析性能瓶颈什么是结构化输出？Spring AI 是怎么实现结构化输出的？什么是 Re-Reading？如何基于 Spring AI 实现 Re-Reading Advisor？什么是 Spring AI 框架？它有哪些核心特性？上次浏览：2026-03-18 18:41:27什么是 AI Agent？它和直接调用大模型 API 做一次问答有什么本质区别？请解释 Tool Calling（工具调用）的完整链路：工具是怎么定义的、LLM 怎么调用它、结果怎么回传?System Prompt 在 Agent 系统中承载了哪些职责？如果 System Prompt 越来越长，你会怎么处理？什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？解释「短期记忆」和「长期记忆」在 Agent 系统中的区别，分别适合怎么存储和检索？OpenClaw 是什么？它要解决什么问题？它的核心能力有哪些？上次浏览：2026-03-16 15:12:52OpenClaw 的核心组件有哪些？请描述它们之间的关系上次浏览：2026-03-16 15:15:2813223. 什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？NEW简单AIOpenClaw大模型应用开发AI应用开发Agent开发标记分享2244面试问答Context Window 就是 LLM 单次请求能处理的最大 token 数（token 是模型处理文本的最小单位，英文大约 1 token ≈ 4 个字符，中文 1 个汉字通常 2-3 个 token），决定了你能”喂”给模型多少信息。因为 Agent 的上下文里得塞的东西太多了：System Prompt、工具定义列表、完整对话历史、每次工具调用的入参和返回结果，还得给模型回复留空间。一次 Agent 运行可能跑几十轮，每一轮工具调用的结果都会追加到历史里，context 像滚雪球一样越来越大。这就是它成为 Agent 工程中最核心约束的原因：算力够，但是装不下那么多信息。一旦超出窗口，要么直接报错中断任务，要么被迫裁剪历史导致关键信息丢失，Agent 的行为就会变得不可预测。

Context Window 里到底塞了什么要理解为什么 Context 这么容易爆，得先搞清楚一次 Agent 请求里到底塞了哪些内容。拿一个典型的编程 Agent 来说：System Prompt 通常就有 2000-5000 token，包含角色设定、行为约束、输出格式要求。工具定义也不小，每个工具的 JSON Schema 描述大概 200-500 token，注册 20 个工具就是 4000-10000 token。这两块是固定开销，每次请求都得带。真正吃 token 的是对话历史。Agent 每调一次工具，history 里就多两条消息：一条是 LLM 的 tool_call 请求，一条是工具的执行结果。如果工具返回的是一整个文件的内容，一条消息就可能占掉 3000-8000 token。跑 10 轮下来，对话历史轻松突破 50K token。OpenClaw 在src/agents/context.ts里把这些组成部分拆分得很清楚，按优先级管理每一块的空间占用。OpenClaw 的 Context Window 管理机制OpenClaw 通过多个来源确定窗口大小，优先级从高到低是：modelsConfig里用户显式指定的值 > 从模型注册表自动发现的值 > 默认的 128K token。同时可以用agents.defaults.contextTokens做全局上限截断。系统设了两道防线：1）硬下限CONTEXT_WINDOW_HARD_MIN_TOKENS = 16,000，低于这个值直接拒绝运行，因为 Agent 在这么小的窗口里基本没法正常工作2）软告警CONTEXT_WINDOW_WARN_BELOW_TOKENS = 32,000，低于这个值会警告用户可能影响效果当检测到 context overflow 时，OpenClaw 按优先级逐步处理：先尝试compaction，把早期的对话历史压缩成摘要再尝试截断过大的 tool result，比如一个文件读取返回了 5000 行，只保留头尾加摘要最后才报错建议用户/reset或换更大窗口的模型。这种渐进式降级比直接截断要优雅得多。主流的 Context 管理策略除了 OpenClaw 的做法，业界还有几种常见方案：1）滑动窗口：只保留最近 N 轮对话，早期的直接丢掉。实现最简单，但容易丢失任务关键信息，比如用户最初的需求描述2）摘要压缩：用一次额外的 LLM 调用把长对话压缩成一段摘要。效果好，但有额外的延迟和 token 成本，压缩过程本身也可能丢失细节3）分层存储：把不同类型的上下文分优先级，System Prompt 和最近 2 轮永远保留，中间的历史做摘要，工具返回的大文本做截断4）外部检索：把历史存到向量数据库，每轮只从里面检索最相关的片段填入 context。Retrieval-augmented 的思路，适合超长会话实际生产中一般是混合使用，不会只依赖单一策略。token 计算的坑token 数不等于字符数，也不等于词数，这中间有不少坑。英文文本平均 1 个 token 约等于 4 个字符，中文文本 1 个汉字通常会被切成 2-3 个 token。同样一段中文内容，token 开销比等长的英文内容高 2-3 倍。更麻烦的是，不同模型的 tokenizer 不一样。同一段文本在 GPT 和 Claude 里算出来的 token 数可能差 10%-20%。所以你不能简单地拿一个 tokenizer 算完就完了，得根据实际使用的模型来校准。OpenClaw 对此的做法是用各模型对应的 tokenizer 做精确计算，同时留出 10% 的安全余量，防止因为计算误差导致请求被截断。

• 提问：如果你要实现一个 compaction 机制，把历史对话压缩成摘要，你会怎么设计这个摘要的格式？哪些信息一定不能丢？回答：摘要至少得保留三类信息：用户的原始任务目标、已经完成了哪些关键步骤、当前的执行状态和中间产物。比如 Agent 正在调试一个 bug，摘要得写清楚”用户报告了 NPE 异常，已经定位到是 UserService 第 87 行空指针，尝试了加 null check 但测试仍然失败”。格式上建议用结构化文本，把这三类信息分块标注，方便 LLM 快速抓到重点。最忌讳的是丢了任务目标，那 Agent 压缩完就不知道自己在干嘛了。- 提问：不同模型的 Context Window 差异很大，你在做 Agent 产品的时候怎么处理这种兼容性问题？
• 回答：核心思路是做自适应。在 Agent 启动时先查模型注册表拿到窗口大小，然后动态计算固定开销占多少、留给对话历史的空间有多少。如果用户选了个 8K 窗口的小模型，就得更激进地做压缩，甚至限制可注册的工具数量。OpenClaw 的做法是设了硬下限 16K token，低于这个值直接拒绝运行，因为再怎么压缩也保证不了质量。上层可以给用户一个推荐清单，标明每个模型适合跑什么复杂度的任务。- 提问：工具返回结果特别大的时候，比如读了一个 1 万行的日志文件，你怎么处理？
• 回答：直接全塞进 context 肯定不行，1 万行日志可能就 30K-50K token，一次就把窗口吃大半。处理的思路是按需截断加智能提取。最简单的是设一个 tool result 的 token 上限，超了就保留头尾各几百行加一个”中间省略 N 行”的标记。更聪明的做法是在截断前先让 LLM 做一轮 relevance extraction（相关性提取），只留跟当前任务相关的内容。OpenClaw 在 context-window-guard 里就有类似的处理，优先截断大的 tool result，因为这部分最”胖”也最容易压缩。作者：Yes面试鸭官方
• 本文已做格式统一与噪声清理，保留原始语义。