过去评价大模型，大家最关心的是参数规模、上下文长度和各种跑分。
但 2026 年 9 月 1 日发生的两件事，可能意味着 AI 模型的竞争规则正在变化：
- Anthropic 发布 Claude Fable 5.1，重点降低长链路 Agent 的缓存读取成本。
- OpenAI 确认 Astra 达到"Critical"网络安全能力级别，准备通过权限限制和额外监控控制风险。
一边在降低 Agent 的运行成本，另一边却在给 Agent 增加权限边界。
这说明下一阶段的竞争，可能不再只是"哪个模型更聪明"，而是：
谁能让 Agent 运行得更久、更便宜，同时不让它越权。
一、Claude Fable 5.1：Token单价没降，为什么总成本反而下降了？
Anthropic 发布 Claude Fable 5.1 后，最容易吸引眼球的是模型能力和基准测试。
但对于真正通过 API 构建 Agent 的开发者来说，更值得关注的是缓存读取价格。
根据 Anthropic 公布的信息，Claude Fable 5.1 的基础价格仍然是：
| 计费项目 | 价格 |
|---|---|
| 输入 Token | 10 美元/百万 Token |
| 输出 Token | 50 美元/百万 Token |
| 缓存读取 | 0.25 美元/百万 Token |
与 Fable 5 相比，缓存读取价格下降了 75%。
Anthropic 估算，这项变化可以让普通工作负载的总成本降低约 25%，让高度 Agent 化的工作负载成本最高降低约 45%。
需要注意，这些数据是 Anthropic 的估算，并不意味着每个项目都能固定节省 45%。
实际能节省多少，主要取决于缓存读取在总调用量中的占比。
二、为什么Agent比普通聊天更依赖缓存？
普通聊天通常是用户提出一个问题，模型生成一次回答。
Agent 的运行方式完全不同。
一个编程 Agent 在执行任务时，可能会不断进行以下循环：
- 读取系统提示词。
- 读取项目规则。
- 读取历史操作记录。
- 调用文件、终端或者搜索工具。
- 将工具结果重新提交给模型。
- 根据结果决定下一步操作。
- 重复整个过程。
如果一个 Agent 连续运行几十轮，相同的系统提示词、项目说明和历史上下文可能被重复读取很多次。
假设一个任务包含：
- 5 万 Token 的系统提示和项目上下文；
- 20 次模型调用；
- 每次都需要重新读取大部分公共上下文。
那么原始上下文的累计读取量可能接近：
50,000 × 20 = 1,000,000 Token
这还没有计算代码文件、工具结果和模型输出。
因此，长时间运行的 Agent 很容易出现一种情况：
用户以为费用主要花在模型生成答案上，实际上大量费用花在了反复读取相同上下文上。
Prompt Cache 的作用，就是让已经处理过的稳定前缀能够以更低的价格重复读取。
三、缓存降价会改变Agent的设计方式吗？
会，但不代表上下文越长越好。
缓存价格降低之后，开发者可能更愿意给 Agent 提供：
- 完整的项目规范；
- 较长的代码上下文；
- 多轮工具调用记录；
- Skills 和操作手册；
- 更丰富的业务知识库；
- 更长时间的任务状态。
但如果把所有内容都无差别塞进上下文，仍然可能造成三个问题。
- 首次缓存写入仍然有成本
缓存通常只有在后续重复命中时才能产生明显收益。
如果提示词每一轮都发生变化，缓存命中率就会下降。
- 无关内容会干扰模型判断
更长的上下文不等于更准确的结果。
大量历史日志、无关文件和重复规则，可能让模型忽略真正重要的信息。
- 缓存不能解决失控的工具循环
如果 Agent 因为错误判断不断调用同一个工具，即使每轮的缓存读取更便宜，累计费用仍然可能快速增加。
所以正确的优化方向不是单纯增加上下文，而是把上下文分成不同层级：
| 上下文类型 | 处理方式 |
|---|---|
| 系统规则、项目规范 | 保持稳定，优先缓存 |
| 当前任务目标 | 每个任务单独注入 |
| 最近工具结果 | 保留必要部分 |
| 历史日志 | 摘要后再放入上下文 |
| 大型代码文件 | 按需读取，不要一次全部提交 |
| 重复错误信息 | 去重后保留关键字段 |
四、另一边，OpenAI为什么开始给Astra"加锁"？
同一天，OpenAI 确认即将发布的 Astra 已达到其 Preparedness Framework 中的"Critical"网络安全能力级别。
按照 OpenAI 的描述，在具备适当工具和访问权限的情况下，Astra 可以：
- 发现此前未知的软件漏洞；
- 针对漏洞开发利用方式；
- 面向防护较强的系统执行复杂任务；
- 在没有人类逐步指导的情况下完成多阶段操作。
这是 OpenAI 第一次将自家模型划入这一能力等级。
因此，OpenAI 没有选择立即全面开放所有能力，而是计划：
- Astra 的普通版本将在后续开放；
- 最强的网络安全能力先提供给可信测试者；
- 对高风险账户采用更保守的行为边界；
- 增加跨对话监控和安全分类器；
- 对长时间运行的高风险任务实施暂停或终止。
这可能带来一个值得开发者提前关注的变化：
未来的模型调用不一定只会返回成功或失败，还可能因为权限、安全策略和任务类型被降级、暂停或者拒绝。
五、API开发者需要重新理解"模型可用性"
过去我们判断一个模型是否可用，通常只检查两个条件：
API 是否能连接？
账户余额是否充足？
但随着 Agent 能力增强，模型可用性正在变成一个多维问题：
Availability
├── Is the model online
├── Is the current region supported
├── Does the account have permission
├── Does the request trigger security policy
├── Is the context length exceeded
├── Are concurrency and rate limits reached
├── Is the current task allowed to call tools
└── Is there a fallback model
这意味着生产环境不能把全部业务绑定到一个模型名称上。
更稳妥的方式，是在应用层设计模型路由和失败回退机制。
六、一个简单的主模型与备用模型调用方案
下面以兼容 OpenAI SDK 的接口为例，实现一个简单的模型回退逻辑。
示例不调用尚未正式开放的 Astra，也不假设任何平台已经提供 Claude Fable 5.1。
from openai import OpenAI
from openai import (
APIConnectionError,
APITimeoutError,
RateLimitError,
)
client = OpenAI(
api_key="YOUR_API_KEY",
base_url="https://genvis.xyz/v1",
)
model_candidates = [
"gpt-5.6-sol",
"gpt-5.6-terra",
]
messages = [
{
"role": "system",
"content": (
"You are a code review assistant. "
"Prioritize checking security issues, concurrency issues, and exception handling."
),
},
{
"role": "user",
"content": "Review the following code for potential issues.",
},
]
retryable_errors = (
APIConnectionError,
APITimeoutError,
RateLimitError,
)
last_error = None
for model in model_candidates:
try:
response = client.chat.completions.create(
model=model,
messages=messages,
)
print(f"Model actually used: {model}")
print(response.choices[0].message.content)
break
except retryable_errors as error:
last_error = error
print(f"{model} temporarily unavailable, trying fallback model")
else:
raise RuntimeError("All candidate models failed") from last_error
这只是最基础的实现。
在真实生产环境中，还应当继续增加：
- 最大重试次数；
- 指数退避；
- 请求超时时间；
- 错误类型分类；
- 模型能力标签；
- 单次任务成本上限；
- Token 使用量记录；
- 安全拒绝与系统故障的区分；
- 熔断和恢复探测。
特别需要注意：安全策略拒绝通常不应该被当成普通网络错误无限重试，否则可能产生额外费用，甚至触发更严格的风控。
七、生产环境更适合"按任务选模型"
模型路由不应该只在主模型报错后才发生。
更合理的方案，是在请求发出之前，根据任务类型选择模型。
| 任务类型 | 推荐策略 |
|---|---|
| 简单分类、格式转换 | 优先低成本模型 |
| 长文总结、资料提取 | 选择长上下文模型 |
| 复杂编码和研究任务 | 使用高能力模型 |
| 高重复上下文任务 | 优先支持缓存的模型 |
| 高风险工具操作 | 使用权限受控的模型 |
| 实时交互 | 优先低延迟模型 |
| 非关键后台任务 | 允许排队或者降级 |
可以把模型理解为不同规格的计算资源，而不是越贵越好的固定答案。
真正成熟的 Agent 系统，追求的应该是：
任务成功率 × 响应稳定性 ÷ 实际调用成本
而不是单独追求某个基准测试的最高分。
八、下一阶段的竞争：便宜地运行，也安全地停止
Claude Fable 5.1 的缓存降价，解决的是"Agent 能不能持续运行"的经济问题。
OpenAI 对 Astra 增加限制，解决的是"Agent 什么时候必须停止"的控制问题。
两者看起来方向相反，实际上指向了同一个趋势：
模型正在从一次性回答问题的工具，变成能够长时间调用工具、修改环境和执行任务的系统。
当模型只负责生成一段文字时，失败的代价可能只是答案不准确。
当 Agent 可以操作代码、访问网络、调用业务接口时，开发者就必须同时考虑：
- 调用成本；
- 权限边界；
- 模型回退；
- 工具白名单；
- 操作审计；
- 人工确认；
- 异常中止；
- 数据隔离。
因此，未来真正有价值的 AI 基础设施，不只是提供一个模型接口。
它还需要帮助开发者解决模型切换、成本控制、可用性和安全边界问题。
总结
2026 年 9 月 1 日的两项更新，代表了 Agent 发展的两个关键方向：
- Anthropic 通过降低缓存读取价格，减少长链路 Agent 的运行成本。
- OpenAI 因 Astra 达到更高的网络安全能力级别，加强权限和监控。
- 模型竞争正在从参数和跑分，扩展到成本、路由、权限与可控性。
- 生产系统不应绑定单一模型，应当提前设计模型选择、失败回退和任务预算。
- 越是能够长期自主运行的 Agent，越需要明确什么时候可以继续、什么时候必须停止。
未来开发 AI 应用，重要的问题可能不再是：
哪个模型最强？
而是：
对当前任务来说，哪个模型在成本、能力、稳定性和安全性之间最合适？
