上下文窗口与 Agent 预算

上下文窗口决定单次请求里模型真正能同时看到多少 token。

prompt 为什么容易比你想象中更长

很多时候你以为自己只发了一句请求，实际上请求里还包括：

• system prompt
• 历史消息
• 工具定义
• JSON schema
• 检索结果
• 文件内容
• 模型先前输出

什么是上下文窗口

上下文窗口就是模型这次请求里“能一起看到的 token 总量上限”。

它通常包含：

• system prompt
• 用户问题
• 历史对话
• 检索片段
• 工具返回结果
• 模型当前已经生成的内容

上下文越长越好吗

不一定。

• 更长上下文可以塞更多资料
• 但延迟更高、成本更高、噪音也更容易混进来

很多场景里，更好的检索与更干净的 prompt，比“盲目塞满上下文”更有效。

Agentic Engineering 里，多少 token 最有效

如果是单轮问答，“能塞进去”常常就已经够用了。
但在 agent 任务里，后面还会继续增长：

• 工具定义
• 检索结果
• 中间推理
• 工具返回
• evaluator / retry
• 最终输出

一个常用经验法则

• 单轮总结 / 单轮问答：输入工作集尽量控制在上下文窗口的 70%-75% 以内
• 带检索的工作流：更稳的是 60%-70%
• 多工具、多轮 agent：常常建议控制在 50%-60%

为什么不要轻易顶满 100%

1. 你得给输出留空间
2. 你得给工具返回留空间
3. 上下文太满时，噪音会迅速变多
4. 长任务更容易出现“中间信息被淹没”

一个更实用的预算方法

不要问：

这个模型是 128K，我能不能塞 128K？

更应该问：

128K
= system + tools + history + retrieval + current task + reserved output + retry headroom

例如对 128K 窗口：

• 普通单轮任务，输入最好控制在 90K 左右以内
• 带检索和工具的 agent，更稳妥的是控制在 64K-80K
• 如果工具输出不可控，甚至应该压到 50K-60K

token 最后怎样影响延迟和成本

• 输入 token 越多，prefill 越慢
• 输出 token 越多，decode 越慢
• 工具调用越多，总时延越长

结论

• agent 系统里最重要的不是把窗口塞满，而是管理好 工作集 和 余量
• 75% 是经验上限，不是数学定律
• 上下文管理做得好，效果、延迟和成本都会一起改善