面经策

（OpenClaw 前置知识）什么是 Agent 的 Context Window？为什么它是 Agent 工程中最核心的约束之一？ ​

  • 标签：AI、OpenClaw、大模型应用开发、AI应用开发、Agent开发

🏛 业务架构师 ​

Context Window（上下文窗口）是模型单次推理能处理的 token 上限（输入+输出共享），是 Agent 工程的"工作内存"。说它是最核心的约束，因为它同时卡住四件事：

  1. 能力边界：窗口装不下的信息，模型"不知道"——Agent 能处理的任务复杂度被窗口尺寸直接限定；
  2. 成本：token 按量计费，上下文越长越贵，且多数厂商对长输入按梯度加价，Agent 多轮循环下上下文滚雪球，费用随之失控；
  3. 性能：注意力计算开销随长度增长，超长上下文推理延迟显著上升、首字变慢；
  4. 效果：即使百万窗口，"迷失在中间"效应仍在——中部信息的利用率低，塞满≠用好。

Agent 工程因此围绕窗口做管理：检索注入只放相关内容（RAG）、历史裁剪与摘要压缩、工具结果截断、Compaction（超限前整体压缩）——Context Engineering 已成 2026 年的核心工程学科。

业务视角：窗口是 Agent 的"经营资源"，像门店面积一样要精打细算——每一 token 都应该为完成任务付租金。我在设计 Agent 时会先画"上下文预算表"（系统提示 X、工具描述 Y、历史 Z、检索内容 W），超预算就裁剪，这个习惯能同时控住成本和效果。

🏗 系统架构师 ​

Context Window = 模型一次推理能处理的 token 上限（输入+输出共享预算），它是 Agent 工程最核心的约束，因为Agent 的一切状态都活在这个窗口里：

为什么是最核心约束（四个放大效应）：

  • 状态膨胀快：Agent 的上下文 = System Prompt（数 K）+ 对话历史（随轮次线性涨）+ 工具定义（每个几百 token）+ 工具结果（一个文件/搜索结果就可能几十 K）+ RAG 片段——单任务跑到 50K~200K token 是常态，比聊天应用快一个数量级；
  • 成本的硬分母：每步循环都是一次全量上下文计费——30 步的 Agent 任务，上下文重复计费 30 次（Prompt Cache 能缓解，但动态内容缓存不命中）；
  • 性能的延迟项：prefill 时间与上下文长度正相关，长上下文让每步循环都变慢，乘上循环次数就是分钟级延迟；
  • 效果的衰减项：lost-in-the-middle——窗口塞满≠都记住，关键信息淹没后决策质量下降，死循环和"失忆"常源于此。

工程应对：窗口预算管理（给各类内容定份额：System 10% / 历史 40% / 工具结果 30% / 检索 20%）、滚动摘要、工具结果压缩、Compaction 机制、长尾内容外置到记忆库按需检索。一句话：Agent 架构设计的本质，是在有限窗口这个"工作内存"上做内存管理。

💻 全栈开发专家 ​

Context Window（上下文窗口）是模型单次推理能处理的 token 总上限（system prompt + 历史 + 检索内容 + 工具结果 + 生成都算在内）。

为什么它是 Agent 工程最核心的约束，四个原因：

  1. 硬容量：超限直接报错或静默截断（截掉的可能正是 system prompt 里的安全规则——事故级）；
  2. 成本主变量：Agent 每轮都携带全部历史，token 消耗随步数平方级增长（N 步任务，累计输入 ≈ N²/2 × 平均消息长），10 步任务轻松烧掉几十万 token；
  3. 质量反噬：即使窗口够大，「lost in the middle」效应真实存在——中段信息召回率下降、指令服从度稀释，上下文越满模型越「健忘」；
  4. 决定架构：要不要外置记忆、工具结果怎么压缩、对话多久做一次 compaction、多 Agent 怎么分工隔离上下文——全是围绕这个约束的设计。

工程预算表（我的实践）：把窗口当预算管理，128k 窗口典型分配：system 5%、任务描述 5%、最近对话 30%、工具结果 40%、检索知识 15%、余量 5%。每一类设上限，超了先压缩/落盘引用。Agent 系统的上下文管理做好了，成本和稳定性至少改善一半——这就是「上下文工程」被称为 2026 核心技能的原因。