什么是 Agent 的上下文窗口？为什么它是 Agent 工程中最核心的约束？
- 标签：AI、大模型、Agent
🏛 业务架构师
Context Window 是模型单次推理能处理的 token 上限（输入+输出共享额度），主流模型 2026 年在 128K~1M 级。它是最核心的约束，因为同时卡住四件事：
- 能力边界：窗口外的信息模型"不知道"——长文档、长历史、大代码库的任务范围被窗口限定，Agent 能承接的任务复杂度与之直接挂钩；
- 成本：按 token 计费且长输入梯度加价，Agent 多轮循环中上下文滚雪球——窗口管理就是成本管理；
- 性能：注意力计算随长度增长，超长输入的首 token 延迟明显上升，体验受损；
- 效果：即便窗口够大，"lost in the middle"效应使中部信息利用率低——塞满不等于用好。
对应的工程手段：RAG 只注入相关内容、历史裁剪与摘要、工具结果限幅、Compaction、外置状态按需检索——Context Engineering 已成独立学科。
业务视角：我把上下文窗口当"门店面积"管理——每个 token 都付租金（计费），所以要画"上下文预算表"：System Prompt、工具描述、历史、检索内容各占多少配额，超了就裁。窗口越大越要精打细算，因为"能塞"和"该塞"是两回事——预算表思维是 Agent 成本可控的第一道防线，比换更便宜的模型更根本。
🏗 系统架构师
Context Window = 模型单次推理能处理的 token 上限（输入+输出共享预算），是 Agent 工程的核心约束——因为 Agent 的全部运行时状态（目标、历史、工具结果）都活在窗口里，它就是 Agent 的"工作内存"。
为什么是最核心约束（四个机制）：
- 状态膨胀的乘性：Agent 上下文 = System Prompt（数 K）+ 工具定义（每个数百 token，几十个工具上万）+ 对话历史（线性涨）+ 工具结果（单次可达数十 K）——单任务 50K~200K 是常态，比聊天应用膨胀快一个数量级；
- 成本的重复计费：循环每步全量上下文重新计费，N 步任务成本乘 N（Prompt Cache 缓解动态部分无效）；
- 延迟的线性项：prefill 时间随上下文长度增长，长上下文 × 循环次数 = 分钟级延迟；
- 效果的衰减：lost-in-the-middle——窗口能装 ≠ 都记住，超长上下文中关键信息定位能力下降，"失忆"与死循环常见于此。
限制的工程应对：预算分配（给每类内容定份额）、滚动摘要、Compaction、工具结果外置分页加载、长尾知识转 RAG 按需检索、记忆库分层。
一句话总结：Agent 架构设计的本质是在有限窗口上做内存管理——谁把上下文工程做好，谁的 Agent 就能跑更复杂的任务、花更少的钱。
💻 全栈开发专家
上下文窗口是模型单次推理的 token 总预算（system+历史+检索+工具结果+生成都算）。为什么是 Agent 工程最核心的约束：
- 硬上限：超限直接报错或静默截断——截断可能砍掉 system prompt 的安全规则，事故级隐患；
- 成本引擎：Agent 每轮携带全部历史，token 消耗随步数近似平方增长（N 步任务累计输入 ≈ N²/2×平均消息长度）。10 步任务轻松几十万 token，成本比单次问答高两个量级；
- 质量反噬（比超限更隐蔽）：「lost in the middle」——长上下文中段的信息召回率显著下降、指令服从度被稀释。窗口没爆 ≠ 没问题，塞满 128k 的 Agent 经常「忘了」第 3 步的决定；
- 架构决定因素：记忆是否外置、工具结果怎么裁剪、何时压缩、子 Agent 怎么隔离上下文、多 Agent 何时分叉——全是围绕这个约束的设计。可以说 Agent 架构 = 上下文预算分配方案。
我的预算管理实践（128k 窗口示例）：system 5%、任务目标 5%、最近对话 30%、工具结果 40%、检索知识 15%、余量 5%；每类设硬上限，超限按优先级压缩；工具大结果摘要+落盘引用；旧对话滚动摘要。效果：同样的模型，做好上下文管理的 Agent 任务成功率高、成本低——这也是「上下文工程」成为 2026 核心技能的原因。