讨论中的主张
厂商们正在描述能够运行数年的 agent，其定价随活动量灵活浮动。这种表述很吸引人：按用量付费，空闲时缩减规模。但一个运行一年的 agent 并不是一次漫长的聊天会话。它是一个有生命周期的有状态服务，其成本曲线与云和模型提供商目前暴露的按 token 计费模式完全不同。
将营销话术与工程现实区分开来，需要问一个简单的问题：在长时间跨度上，究竟什么在持续累积？答案主要不是推理 token。而是持久状态、周期性唤醒，以及当一次运行超出其最初一小时所设定的假设时不断累积的修复工作。
持久记忆与向量索引
一个跨月记忆的 agent 会累积记忆条目、embedding 和索引结构，这些随历史规模而非流量增长。一个在短运行中重建成本低廉的向量索引，当它承载一年的观察数据时，就变成了存储和计算负担。重新 embedding 是隐藏成本：更换 embedding 模型、调整分块方式或修复漂移，往往意味着为整个历史重新计算向量。该操作的规模与已存储历史成正比，而非与当前请求量成正比。
情景日志、工具调用记录和决策记录同样如此。追加成本低廉，但迁移、修剪或重建索引则代价高昂。一年下来，最主要的成本项往往是维护那些很少被读取但必须保持一致的状态。
唤醒与重新规划
一个每小时唤醒一次却无事可做的 agent，仍然要支付上下文组装的成本。心跳路径每次调用的成本或许很低，但并非免费：它要加载近期状态、检查条件，并决定是否升级处理。如果唤醒路径与 deliberation 路径共享同一个上下文窗口，那么每次空操作唤醒都要为不产生任何状态变化的 token 付费。
重新规划是另一项经常性成本。长时间运行会遇到环境变化、凭证过期和目标偏移。每次重新规划都需要从记忆中重建工作集，这意味着检索、排序和 prompt 组装。重新规划的频率取决于环境的不稳定程度，而非 agent 的繁忙程度。
工具重试与对账
长时间运行会累积部分失败。一次 API 调用成功了但响应丢失，一次写入落库了两次，一个下游系统在运行中途更改了 schema。在一年时间里，这些并非罕见事件；它们是分布式系统的正常背景发生率。成本在于对账：检测分歧、判定哪个状态是权威的，并加以修复。
对账工作量往往随集成工具数量和运行时长呈超线性增长，因为每新增一个集成都会带来新的故障模式和新的修复路径。短运行可以忽略其中大部分。而一年的运行不能。
将廉价的心跳路径与昂贵的 deliberation 路径分离
心跳应当是一个小型、确定性的检查，按计划运行，除非满足条件，否则不调用大模型。Deliberation 应当是一条独立路径，拥有自己的预算，由明确信号触发。这种分离是控制空闲成本最有效的方式，因为它防止空操作唤醒消耗 deliberation 级别的上下文。
一个具体机制：心跳读取一份紧凑的状态摘要（几 KB），并评估一组规则。如果没有规则触发，它就写入一个时间戳然后退出。只有当某条规则触发时，agent 才组装完整工作集并调用模型。代价是延迟：心跳无法做出细致决策，因此某些条件会被遗漏，直到下一个 deliberation 周期。对大多数长时跨度目标而言这是可接受的，但并非对所有目标都如此。
限制每次唤醒的上下文，只将增量提升进工作集
长时间运行会诱使团队将整个历史传入每次调用。这是让成本随运行时长而非活动量增长的最快方式。相反，应限制工作集大小，只提升增量：新观察、变化的工具输出，以及自上次 deliberation 以来的明确决策。其余内容留在冷存储中，按需检索。
代价是检索质量。受限的工作集可能遗漏全历史 prompt 本会包含的相关上下文
Server rack closeup
一个没有终态的 agent 就是一份订阅。每个长时跨度运行都应有明确的终止条件：一个可标记为完成的目标、一个截止期限，或一个使运行停止的失败阈值。没有终止条件，agent 就会无限期地继续唤醒、重新规划和累积状态，成本曲线也会反映这一点。
终止条件也让定价变得清晰可读。有明确终点的运行可以按已完成目标定价。没有终点的运行只能按时间定价，而这恰恰是长时跨度 agent 使其变得昂贵的模式。
应当监测什么
每个已完成目标的成本，而非每个 token 的成本。Token 成本是输入；目标是输出。监测目标使得比较不同运行、以及检测某次运行是否正漂移向无限期维护成为可能。
空闲与活跃之比，以及未产生任何状态变化的唤醒占比。这两个指标能揭示心跳路径。高空闲活跃比未必是坏事，但如果大量唤醒未产生状态变化却仍消耗 deliberation 级别的上下文，那就是路径未分离的明确信号。
每月一次的修剪任务，移除不再被任何决策引用的记忆条目。从未被读取的记忆是只有成本没有收益的存储，而且会因增加噪声而降低检索质量。修剪任务应保持保守：仅当没有任何决策记录引用某条目时才移除它，并保留一个 tombstone，使移除可审计。
这里的代价是召回率。修剪可能移除未来决策本会认为有用的上下文。缓解办法是按引用修剪，而非按时间修剪，并保留 tombstone，使检索遗漏可以追溯到一次有意的移除，而非无声的丢失。
定价会发生什么变化
如果主要成本是空闲状态、存储和重新规划，那么仅随活动量灵活浮动的定价就会对长运行收费不足，对短运行收费过高。更诚实的模型应跟随运行生命周期：建立状态的成本、维护状态的经常性成本，以及终止和对账的成本。基于活动量的定价可以叠加在其上，但不能取而代之。
工程上的含义是，长时跨度 agent 应当像任何有状态服务一样以同样的纪律来设计：明确的生命周期、有界的工作集、分离的热路径与冷路径，以及衡量目标而非输入的监测。这正是让一年期运行变得清晰可读的原因，也是让弹性定价变得有意义而非装饰性的原因。
封面照片：panumas nikhomkhai / Pexels。