很多人看到 “1M context window” 的第一反应是：越大越好。对 Agent 来说，上下文越长，理论上能记住更多历史、读更多文件、处理更复杂任务。
但在真实账号和不同模型服务里，上下文窗口不是一个可以随便拉满的数字。
NousResearch/hermes-agent issue #3577 里，一个 Claude Pro 用户遇到的问题就很典型：Hermes 默认按 1M 上下文使用模型，但 Claude Pro 账号实际只允许 200K。短任务看起来没问题，一旦对话或文件长度超过 Pro 账号限制，就会突然撞墙。
更重要的是，评论里很快发现：这不是 Claude Pro 单点问题，GPT 模型、本地 Ollama / OpenAI-compatible 模型也可能被错误地报成更大的 context window。
这类 bug 最麻烦的地方：前期一切正常
它不像 API Key 错误，一上来就 401。
也不像依赖安装失败，启动阶段就崩。
上下文窗口配置错，往往会表现得很“温柔”：
短对话：正常
小文件：正常
普通问答：正常
长上下文任务：突然超限所以用户很容易误判为：
- 模型临时抽风；
- provider 限流；
- 文件太大；
- prompt 写得不对；
- Agent 历史太脏。
但根因可能只是：Hermes 以为你有 1M，实际上你的账号/模型只给 200K。
issue #3577 的核心：Claude Pro 不是 Enterprise
原始报告很短，但点很准：
Hermes defaults to 1M context window with no option to choose 200K.
Claude Pro doesn't allow a context window bigger than 200K.
Works fine until the limit is exceeded.用户期望：
默认使用 200K context window实际情况：
默认使用 1M问题不是 Claude 模型完全不可用，而是 Hermes 没有把订阅层级差异纳入上下文窗口选择。
Claude Pro、Team、Enterprise、不同 API 入口、不同模型版本之间，上下文能力并不总是同一个数字。Agent 如果只按模型名硬编码最大值，就容易踩坑。
后续讨论：GPT 和 Ollama 也有类似问题
评论里有人补充：
This also happens to GPT models, like 5.4. It defaults to 1M and I can't change it to the 200k context window.还有本地 Ollama 用户反馈：
Using Gemma4:26b with 128K context, reported as 256K in terminal.这说明问题范围比 “Claude Pro 1M/200K” 更大。
真正的问题是：Hermes 需要一个可靠机制来确定“当前这个 provider + model + account + deployment 实际可用的上下文窗口”。
而不是简单认为：
模型理论最大窗口 = 当前用户可用窗口为什么硬编码 context window 很危险？
硬编码上下文窗口有三个典型风险。
1. 账号层级不同
同一个模型名，在不同账号或产品层级下可能有不同限制。
例如：
- Pro 用户：200K；
- Enterprise 或特殊 API：更高；
- 第三方聚合服务：可能做了转发或限制；
- 本地部署：取决于启动参数和硬件。
如果 Hermes 不知道用户实际层级，就不能安全默认到最大值。
2. Provider 命名不统一
OpenAI-compatible provider、OpenRouter、DeepAI API 中转站、本地 Ollama、vLLM、LiteLLM 等都会暴露模型名。
但模型名并不总能告诉你真实上下文能力。
例如同一个 “Gemma / GPT / Claude” 名称，可能对应不同 quant、不同后端、不同 max tokens 配置。
3. 超限往往发生在任务后半段
上下文过大不是一开始报错，而是在 Agent 已经读了很多历史、工具输出、文件内容之后才失败。
这会浪费：
- 时间；
- token；
- API 调用；
- 用户耐心；
- 任务状态。
更好的设计：让用户能显式设置 max_context_window
评论里提到的方向是：增加模型级别配置，例如：
models:
anthropic/claude-sonnet-4:
max_context_window: 200000或者按 provider/model 做覆盖：
model_overrides:
claude-pro-sonnet:
provider: anthropic
max_context_window: 200000
local-gemma4-26b:
provider: ollama
max_context_window: 128000关键不是具体字段名，而是能力：
> 用户必须能把“理论最大窗口”压到“当前账号真实可用窗口”。
这比让 Agent 盲目相信模型数据库更可靠。
自动查询 server 可以吗？
理想状态下，Hermes 可以向 provider 查询当前模型能力。
但现实里很难统一：
- 有些 provider 不返回上下文窗口；
- 有些 OpenAI-compatible 服务返回字段不标准；
- 本地 Ollama 的运行参数可能比模型卡片更重要；
- 第三方中转站可能暴露的是聚合模型名；
- 同一模型不同账号 tier 能力不同。
所以自动查询是长期方向，短期更稳的是：
自动识别 + 用户可覆盖也就是：能查就查，查不到或不可信时允许用户配置上限。
排查：如何判断自己是不是 context window 设大了
如果你遇到长任务后半段突然失败，可以按下面查。
1. 看失败发生的时机
如果短对话没问题，长文件/长历史后才失败，优先怀疑上下文窗口或 token budget。
2. 对照账号真实限制
确认你用的是：
- Claude Pro 还是 API / Enterprise；
- OpenAI 官方还是 OpenAI-compatible 中转；
- 本地模型实际启动参数；
- provider 控制台标注的上下文上限。
3. 看 Hermes 显示或日志中的 context window
如果 Hermes 显示 1M，但你的账号只支持 200K，就需要降上限。
4. 找可配置入口
优先寻找：
max_context_window
context_window
model override
provider override如果版本暂不支持，只能升级、切模型或减少上下文输入。
和 DeepAI API 中转站的关系
DeepAI API 中转站提供统一的 OpenAI-compatible API 入口：
Base URL: https://api.deepai.wang/v1
API Key: 你的 DeepAI Key
Model: 以 DeepAI 控制台为准如果你通过 DeepAI 调用多种模型，也要注意：上下文窗口应以 DeepAI 控制台和上游实际能力为准，而不是只看 Hermes 内置模型名。
更稳的做法是：
- 在 DeepAI 控制台确认模型实际上下文；
- 在 Hermes 中设置对应 model override；
- 对长文件任务保留安全余量；
- 不要把所有模型都默认当成 1M。
DeepAI 能帮你统一 API 入口，但不能替 Hermes 自动知道每个账号、每个模型、每个本地部署的真实 context window。
给 Agent 用户的实用建议
如果你经常做长上下文任务，我建议这样配置和使用：
1. 不要盲信 1M； 2. 先确认账号/模型真实上限； 3. 给 Hermes 设置保守的 max context； 4. 长文件任务先做分块摘要； 5. 保留 10%-20% 输出余量； 6. 本地模型按实际启动参数配置，而不是按模型宣传页配置； 7. OpenAI-compatible 中转服务以控制台说明为准。
这比等任务跑到一半再超限更省钱。
FAQ
1M context window 不是更好吗？
只有在你的账号和 provider 真支持时才更好。否则它只是一个会导致超限的错误假设。
Claude Pro 为什么不能直接用 1M？
不同订阅层级有不同上下文限制。Claude Pro 常见限制是 200K，不能按更高 tier 的能力默认配置。
GPT / Ollama 也会受影响吗？
会。评论里已有 GPT 和本地 Ollama 用户反馈类似“显示窗口大于实际可用窗口”的问题。
最好的修复是什么？
支持模型级 max_context_window override，并在可能时从 provider 查询真实能力。
DeepAI API 中转站能避免这个问题吗？
DeepAI 可以统一 API 入口，但上下文上限仍要以 DeepAI 控制台和上游模型实际能力为准。Hermes 仍需要正确配置 context window。
总结
#3577 的教训很简单：
上下文窗口不是越大越好，而是越准确越好。对 Agent 来说，1M 不是一个安全默认值。Claude Pro 用户可能只有 200K，本地 Ollama 模型可能只有 128K，OpenAI-compatible provider 也可能有自己的限制。
真正可靠的做法，是让 Hermes 支持模型级上下文上限配置，并允许用户把理论最大值压到账号实际可用值。