闲置智能体税：当用户在开会时，你的 AI 会话到底产生了多少成本

一名开发者在 9:00 打开 IDE 的 Copilot，在早会前问了三个问题，然后一直开会到 11:30。聊天面板仍然打开着，对话依然可以滚动查看。模型在两个半小时内没有生成一个 token。然而，这个无人问津的会话整个上午都在悄悄地产生费用。KV 缓存被占用。提示词缓存（Prompt cache）通过定期 ping 保持活跃。对话状态保存在热存储（hot store）中。追踪流水线每跳动一次心跳就写入一行记录。模型提供商预留了并发槽位。乘以一万个席位，这笔账单是真实存在的。

这就是“闲置智能体税”（idle agent tax）。它是你推理预算的一部分，用于支付用户并未使用的容量。由于大多数工程仪表盘是为无状态 API 构建的，因此它在仪表盘上是不可见的。一个请求进来，一个响应出去，容器关闭。搞定。智能体产品在两年前就打破了这一模型，而大多数团队尚未根据这一变化重新调整其架构的成本模型。

之所以现在这很重要，是因为长期会话带来的经济影响已经开始显现。GitHub 在今年春天宣布，Copilot 的溢价请求模式已不再可持续：一个简单的聊天问题与一个长达数小时的自主编码会话的计费方式完全相同，他们将在 6 月转向基于 token 的积分制度。Anthropic 在 3 月初悄悄将其默认提示词缓存的 TTL（生存时间）从一小时缩短至五分钟，下游团队报告称，缓存创建成本几乎在一夜之间飙升了 20–32%。可观测性供应商也发来邮件，称与传统请求流相比，LLM 追踪存储成本激增了 4–8 倍。每一个事件都指向同一个架构假设：即“会话”是一种免费的抽象。事实并非如此。

“闲置”到底意味着什么成本

当用户离开时，会话仍在消耗四种截然不同的资源，且每种资源的成本形态各异。

提示词缓存（Prompt cache）。 Anthropic、OpenAI 和 Google 都提供提示词缓存，可以在 TTL 窗口内的多次调用中重用预计算的键值张量（key-value tensors）。Claude 的默认 TTL 现在是 5 分钟；扩展 TTL 为 1 小时，且写入溢价为 2 倍。在 5 分钟档位中，每次缓存写入的成本是基础输入 token 的 1.25 倍，读取成本为 0.1 倍。只要你保持互动，读取占主导地位，成本计算非常划算。一旦用户闲置超过 TTL，下一条消息就必须再次支付全额的缓存写入费用——如果你的智能体系统提示词和工具 schema 达到 12k tokens，那这笔写入费用就不容忽视了。5 分钟的 TTL 意味着每一次喝咖啡休息都会变成团队需要买单的缓存未命中（cache-miss）事件。

推理平台上的 KV 缓存。 即使是自托管推理，闲置对话也会占用 GPU 内存。KV 缓存的大小与上下文长度和并发用户数成正比，它是推理集群中最先触及瓶颈的资源。像 SideQuest 和 KV-offload 管道等近期工作的出现，正是因为长上下文智能体会话消耗 GPU 内存的速度比任何其他工作负载都要快。当闲置会话一直驻留时，集群能够承担的并发解码任务就会减少；成本表现为你额外配置的容量，或是活跃用户的排队延迟。

并发槽位（Concurrency slot）。 大多数生产级 AI 产品都在具有频率限制（rate limits）和预留容量的供应商上运行。一个持有打开的 WebSocket、流式连接或逻辑对话锁的长期会话，即使在没有 token 流动时也会在配额中占用一个槽位。如果你从供应商那里购买了 200 个并发槽位，而你的用户群中开启了 1,400 个会话，你要么会拒绝活跃请求，要么得为预留并发（provisioned concurrency）付费以填补缺口。

可观测性记录（Observability tape）。 这是一个无声的杀手。AI 工作负载生成的遥测数据（telemetry）是传统服务的 10–50 倍。单次请求的追踪通常涵盖提示词文本、生成文本、工具调用、检索结果、评估分数、token 计数、延迟等——许多团队还会为每个活跃会话发送心跳以检测存活。来自将 LLM 可观测性添加到现有 Datadog 设置的团队的真实报告显示，账单增加了 40–200%。你的闲置会话每保持“存活”一分钟，就会写入约 2 KB 的追踪记录，而追踪数据的保留窗口通常以月为单位。

将这四项成本相加，除以你的活跃用户比例，对于任何用户整天保持会话开启的产品来说，每个会话的经济模型都会开始变得令人不安。

无状态 API 配置是错误的思维模型

大多数工程团队对 AI 功能定价的方式沿用了他们对 REST 端点使用的老套路：单次调用的 token 成本乘以调用量，再加上一些余量。该模型假设工作负载是突发性的，且在请求之间成本归零。这是每一个“缩容至零”（scale to zero）的无服务器（serverless）宣传中所包含的假设。

智能体会话在三个方面打破了这一假设：

1. 状态是有重量的。 一个开启的对话持有下一次调用将重用的上下文。销毁它是浪费的；保持它的“温度”是让下一次响应感觉快速的原因。你的架构现在的任务是提供“保温”服务，这是一种持续产生成本的商品，而不是按请求计费的。
2. 活跃度是有形态的。 用户交互的速率并不均匀。在单个会话中，一名开发者可能在 10 分钟内发送 30 条消息，然后静默 90 分钟，最后再回来。每个会话的成本曲线是双峰式的：大部分时间闲置，偶尔有突发流量。固定费率的配置模型在闲置时支付过多，在突发时支付不足。
3. 无状态逃生舱口存在泄漏。 框架会告诉你“将会话状态外部化到 S3 并在每个请求上重建”，这样智能体本身就能保持无状态。这对于应用层有效——但提示词缓存、KV 缓存以及供应商的并发预留都处于代码的下游，它们并不关心你的序列化方案。你的应用程序可以是无状态的，但你的 token 账单是完全有状态的。

解决方案是停止假装会话是免费的，并开始将其视为一种分层的、具有时间感知能力的资源——就像数据库处理热存储与冷存储的方式一样。

休眠模式与唤醒延迟的权衡

正在形成的标准模式是将热-温-冷（hot-warm-cold）分层应用于对话状态，而精确了解每一层的成本以及每次转换触发的时机是非常值得的。

热层（Hot tier） 将会话保持在进程内：KV 缓存常驻、Prompt 缓存预热、对话在内存中、追踪（tracing）实时。每分钟的成本很高；下一条消息的感知延迟很低（如果缓存做得好，首字延迟（TTFT）低于 100 毫秒）。这是会话在活跃交互期间以及之后的一段短宽限期内存放的地方。

温层（Warm tier） 丢弃进程内状态，但保留廉价且可重建的层：对话历史序列化到类似 Redis 的快速键值存储中，Provider 端的 Prompt 缓存保持活跃，可观测性从心跳模式切换为事件驱动。每分钟的成本下降一个数量级。唤醒延迟有所上升 —— 通常在几百毫秒左右，因为你在重新加载（rehydrating）上下文，但不需要支付完整的缓存未命中（cache miss）代价。

冷层（Cold tier） 是长尾归档：对话序列化到 S3 或同类存储，Prompt 缓存已过期，没有活跃的并发预留，可观测性汇总为批量聚合。成本几乎仅为存储费用。唤醒延迟长达数秒，因为下一条消息必须从头开始重新填充 Prompt 缓存，并重建智能体（agent）依赖的所有瞬态。

跨层级推送的正确生存时间（TTL）取决于产品，但计算逻辑很简单：你将热转温的界限定在对于平均用户而言，维持热层的边际成本超过冷唤醒边际成本的那个点。对于一个用户在开会后会返回使用的编程助手，经验答案通常是：空闲 5–10 分钟执行热转温，空闲 30–60 分钟执行温转冷。对于午饭后继续工作的客服智能体，这些界限会进一步向后推，因为午休情况主导了成本模型。

一个常见的实现错误是将 Prompt 缓存的 TTL 视为唯一的调节按钮。Provider 的 TTL 决定了 缓存 状态，但它并不决定 你的 层级转换。那些不断向 Prompt 缓存发送保活（keep-warm）ping 以延长其默认 TTL 寿命的团队，本质上是在租用热层的延期 —— 他们应该根据热层成本线来衡量这笔 ping 预算，而不是将其视为杂项流量。

在需要之前构建空闲成本计量表

让这种机制在团队中落地的纪律是：将空闲成本与活跃成本放在同一个仪表盘上。我见过的大多数成本仪表盘都是按功能、模型或客户等级对支出进行分组 —— 但它们没有将“用于服务活跃轮次的 token”、“用于保持会话预热的 token”以及“空闲期间的存储和预留成本”区分开来。这三者的变动规律不同，应对的修复方案也不同。

一个有用且暴露出空闲成本的面板应包括：

• 每个会话的存活分钟数分布，按层级（热/温/冷）切片。
• 归因于空闲会话 TTL 过期的缓存写入事件，需与真实上下文变化触发的缓存写入分开。
• 并发预留利用率：在你支付的插槽中，上一个间隔内服务 token 数为零的比例是多少。
• 专门归因于空闲会话的可观测性成本 —— 心跳追踪、存活指标、保留开销 —— 与活跃轮次的追踪对比。

这个面板能让财务合作伙伴提出正确的问题。当仪表盘可以显示“平均会话时长增长了 22%，但交互密度下降了 9%，因此你在保持空闲会话预热上的花费超过了服务对话轮次的花费”时，“为什么上个月账单增加了 18%？”这类问题就能得到更好的回答。这个答案指向的是休眠策略的调整，而不是 Prompt 的重写。

该面板还能捕捉到 Provider 悄无声息的回归（regressions）。在 3 月份注意到 Anthropic TTL 变化的团队，正是那些仪表盘显示空闲会话上缓存写入事件激增的团队。没有这个面板的团队只看到账单上涨，并假设是流量增长了。

降温会话的用户体验（UX）契约

最后一部分是产品端。如果你实施了层级转换，你的用户在长时间空闲后的第一条消息上，偶尔会遇到数秒的唤醒延迟。他们不会理解原因。他们会提交 Bug。正确的做法是让“降温”状态可见 —— 在唤醒轮次显示一个细微的“会话已恢复”指示器，或者当用户重新聚焦到标签页时进行轻量级预热 —— 这样用户就能将延迟与原因联系起来。

同样重要的一点：在转入冷层时，不要悄悄重置会话记忆。用户会对他们的智能体“记得”什么建立心理模型。如果你的冷层为了保持存储廉价而压缩或截断对话历史，智能体的表现记忆将以用户无法预测的方式退化。这是一种信任倒退，其代价远比你节省的存储空间昂贵。要么在冷存储中保留完整历史记录，要么将截断行为变成可见的产品行为（“我们总结了这次对话以保持速度 —— 完整历史在这里”）。

能够处理好这一点的团队，通常是已经发布过一款因记忆边界导致 UX 灾难的产品的团队。还没经历过的团队也会以同样的方式发现这一点：一位客户投诉升级，你追踪对话，发现智能体忘记了一个关键事实，因为它在昨天下午 4 点跨越了层级边界。

会话是具有空闲成本曲线的有状态资源

这一架构层面的认知虽小，却起着承重墙般的作用：在智能体产品中，每一个会话都是一个具有空闲成本曲线的资源。如果团队仍像提供无状态 API 那样进行定价和资源配置，就是在为用户并未使用的容量支付费用。解决办法并非消除长效会话——这些会话本身就是产品，它们让 IDE 编程助手在两次会议之间保持可用，让客服智能体在午休之后能无缝衔接。真正的解决办法是承认会话是有“重量”的，量化这种重量，并根据用户注意力的起伏，设计出能让会话在不同成本层级间迁移的转换机制。

在 2026 年，做到这一点的团队将能够提供极具竞争力的长效会话用户体验，而无需在用户每次喝咖啡休息时眼睁睁看着利润率缩减。而那些没能做到这一点的团队将不断发现，其成本增长已与使用量增长脱钩——他们最后才会明白，那些无法解释的账单，其实全是为“什么都没发生”而支付的。