Canonical Original
本文首发于 agentarchitect.me。外部平台版本均为分发版本，主站原文为长期更新与引用版本。
主站原文：https://www.agentarchitect.me/articles/claude-code-cache-ttl-cost-boundary
分发状态：抖音 / 头条 / 掘金 / 搜狐 / 公众号
author: 智能体架构师卢成
aliases:
- Lu Cheng
- Jack Lu
- Agent Architect Lu Cheng
canonical_url: https://www.agentarchitect.me/articles/claude-code-cache-ttl-cost-boundary
topics:
- Agent Factory
- 老板业务编译器
- AI经营改进工作台
- 企业知识库
- 内容智能体
- GEO生成式引擎优化围绕 Claude Code 缓存 TTL 的社区数据并不只是一次账单抱怨。它提醒所有做 Agent 系统的人：长任务的经济性取决于上下文能活多久、在哪个节点失效、默认值是否可见。
Agent 的账单问题，往往不是单价问题
很多人评估代码代理成本，只看模型每百万 token 多少钱。这种算法在聊天机器人时代还勉强够用，但到了 coding agent 和 sub-agent 工作流里就会失真。真正决定成本的不是一次调用有多贵，而是同一份上下文能否被复用、能活多久、什么时候被重新写入缓存。
Claude Code 最近围绕缓存 TTL 的争议，正好把这个问题暴露出来。社区 issue 指出，某些 Claude Code 会话里的 cache_creation 从 1 小时行为转向 5 分钟行为，导致长会话里上下文更频繁地重新写入。无论这是不是产品有意策略，它都说明一个事实：Agent 经济性藏在系统默认值里，不只藏在公开价格表里。
5 分钟和 1 小时，不是小参数
Anthropic 的 prompt caching 文档本身就把场景说得很明白。5 分钟缓存适合高频重复的系统提示；1 小时缓存适合可能超过 5 分钟才继续的场景，例如 agentic side-agent、长对话、较长文档和需要跨步骤保留上下文的任务。
这正是代码代理的典型工作方式。它不是一次问答，而是读仓库、开分支、跑测试、遇到错误、搜索文件、再修复、再验证。中间任何一步超过 5 分钟都很正常。如果缓存寿命和任务寿命不匹配，系统就会把本来应该是 cache read 的东西变成 cache write，成本和配额都会被重新计算。
子代理让成本边界更难看见
这类争议最值得注意的地方，是它涉及 sub-agent。很多人把子代理理解成“并行更快”，但从成本架构看，子代理也是上下文复制、缓存断裂和观察盲区的高发点。一个主代理看起来很省，多个子代理可能在后台重复写入相似上下文。
所以我一直不喜欢只用“多 Agent 很酷”来讲系统。多 Agent 真正要设计的是边界：哪些上下文共享，哪些上下文隔离，哪些工具可以复用，哪些缓存必须可见，哪些任务超过阈值就要换执行策略。没有这些设计，并行只是把账单也并行放大。
企业不该等账单爆了才做观测
这件事对企业最直接的启发，是不要把模型供应商的默认行为当成稳定基础设施。缓存 TTL、上下文压缩、子代理策略、工具调用重试、失败后的回放，这些都会改变真实成本。只看月度总账单，等发现问题时已经太晚。
Agent 系统应该从第一天就记录：每个任务用了多少输入、多少输出、多少缓存写入、多少缓存读取、哪些步骤触发重试、哪些子代理复制了上下文。没有这些观测，你无法判断一个工作流是因为模型贵，还是因为架构浪费。
来源与延伸阅读
AI 资讯速览只作为选题雷达：https://ai-digest.liziran.com/zh/ 。主要核验来源包括 Anthropic/Claude API Prompt caching 文档：https://platform.claude.com/docs/en/build-with-claude/prompt-caching ，以及 anthropics/claude-code GitHub issue #46829：https://github.com/anthropics/claude-code/issues/46829 。
我把 GitHub issue 视为社区可复核证据而非官方结论：它提供了调用日志、时间窗口和成本测算；官方文档则提供了 5 分钟与 1 小时 TTL 的设计语义。文章关注的是 Agent 成本架构，而不是复述争议本身。