你的Agent也会老化：部署系统的Agent生命周期工程

提出Agent老化四机制与AgingBench基准，诊断长期部署AI Agent的可靠性退化

前置知识

Agent Harness

Agent harness是AI Agent的完整系统架构，包括语言模型、记忆写入或存储或检索或利用、工具、提示词、工作空间和维护程序等组件。即使模型权重冻结，Agent的有效状态也会随着记忆压缩、历史累积、事实修订和日常维护而不断变化。可靠性评估必须考虑整个harness，而不仅仅是模型本身。

本文核心假设是Agent可靠性是harness的生命周期属性而非模型快照属性，理解harness架构对于理解老化机制和诊断修复点至关重要。

Temporal Dependency DAG

时序依赖有向无环图用于编码跨会话的任务结构。包含三种结构：版本链追踪事实替代，依赖边连接需要多会话综合的探针，干扰对注入跨域的可混淆实体。每个探针携带通过FactGraph的目标答案，使得评分可以定位到特定结构而非崩溃为单一召回数字。

没有这种结构，评估无法区分失败是反映信息丢失、检索混淆还是过时更新。这是将老化分解为四种可诊断机制的基础。

Counterfactual Probes

反事实探针通过替换记忆管道的上游组件来实现组件级归因。P1是基线条件，使用Agent自己的写入和检索。P2用oracle检索器替换Agent检索但保持Agent写入的存储不变。P3同时用oracle上下文替换写入和检索。P3剩余的任何错误都可归因于utilization。差异Acc_P3减Acc_P2捕获写入误差，Acc_P2减Acc_P1捕获读取误差。

这使得老化诊断从Agent记错了升级为具体的修复目标：写入阶段、检索阶段或利用阶段。相同的表面症状可能对应完全不同的根本原因。

Compaction Policy

压缩策略是记忆系统在写入时决定保存什么内容、丢弃什么内容的策略。实验测试了两种端点：careful显式保留所有美元金额、日期、人名、技术约束和lossy最多300字关注最重要点。在相同模型下，这一单一参数选择产生了约4.5倍的半衰期差异。

压缩策略是write-before-query屏障的具体实现：写入时必须决定保留什么，但哪些事实重要取决于尚未到达的未来查询。这是compression老化的根源。

研究动机

现有的Agent评估仍然像评估freshly initialized模型一样，但长期部署的Agent面临一个基本的系统问题：部署后Agent能保持可靠多久？即使模型权重冻结，Agent的有效状态仍在持续变化：压缩交互历史会丢弃未来相关的细节，从增长的存储中检索时累积的相似记忆会挤出目标事实，事实更新后派生状态没有正确更新，常规维护如flush或recompaction会触发性能回归。例如，药物剂量从50mg美托洛尔每日两次变成每日药物，John Smith被混淆为John Smyth，取消的高级计划仍被视为有效，周二循环日程在维护后消失。这些表面可靠的Agent可能在内部精度已经严重退化，而基于违反率的监控无法检测到这种无声的精度下降。

本文的目标是本文的目标是建立Agent Lifespan Engineering框架，回答三个关键问题：部署的Agent能保持可靠多久？可靠性如何退化：通过压缩、干扰、修订还是维护？修复应该针对哪里：写入、检索、利用还是记忆生命周期？为此引入AgingBench基准，不仅测量Agent是否退化，还测量如何退化以及修复应该针对哪里。

与已有工作不同的是，现有记忆基准开始研究长上下文和多会话记忆，显示Agent性能会随上下文增长而退化。但这仍然主要将可靠性视为端到端分数：给定当前会话，Agent回答正确与否？对于长期运行的Agent，这不够。部署的Agent跨越多个会话序列操作，评估其可靠性需要理解不仅性能是否退化，而且退化的方式和位置。本文的独特切入角度是将agent老化组织为四种可诊断机制，并使用时序依赖DAG和反事实探针将退化定位到记忆管道的具体组件，而非仅仅给出一个记忆分数。

核心方法

AgingBench是一个纵向基准测试框架，用于测量Agent老化。首先将老化机制分为四类：compression aging写入时压缩丢弃未来相关细节、interference aging累积的相似记忆挤出目标事实、revision aging更改或派生的状态没有正确更新、maintenance aging生命周期事件如flush或recompaction触发回归。然后使用程序化生成器生成具有temporal dependency DAG的任务流，DAG编码版本链、依赖边、干扰对和累加器。评估通过会话循环进行，每会话读取压缩记忆、回答任务和探针、压缩新历史为下一状态。结果形成aging曲线，计算半衰期、衰减斜率和危险代理。最后使用P1、P2、P3反事实探针进行组件级诊断，将误差归因到写入、检索或利用阶段。

核心创新是将长期部署的Agent可靠性问题建模为可诊断的老化机制，而非单一记忆分数。传统基准给出端到端正确率，导致相同的表面症状Agent错了都得到相同的通用处方给它更多记忆。但实际上正确的修复可能完全不同：写入时保留精确值、改进可混淆条目间的检索、强制模型使用检索的上下文、显式更新派生状态或在维护后运行回归检查。AgingBench通过机制级指标和反事实探针产生诊断概况，指出修复应该针对记忆管道的哪个阶段，实现从Agent错了到在X阶段修复的转变。

方法步骤详情

方法步骤包含：场景生成，每个场景由程序化生成器支持，给定目标会话数和随机种子，产生完整任务流、事实注册表和时序依赖DAG。老化压力可配置：依赖密度、事实更新率、链深度、可混淆对数量可以独立变化。会话循环评估，对于N个会话的运行，在每会话t读取压缩记忆M_t，回答会话任务和探针，获得场景特定准确率分数s_t。会话交互历史H_t被压缩为下一状态M_{t加1}等于U括号M_t、H_t、theta，其中U是记忆策略的压缩函数，theta是参数。生命周期事件注入，在指定维护会话t等于k，注入生命周期事件e_k扰乱M_k或theta如recompaction、历史flush、预算减少，实现受控测量。aging曲线计算，分数序列m括号t等于s_0到s_N是aging曲线，计算半衰期t_1比2、衰减斜率OLS拟合和危险代理每会话失败概率。机制级评分，每个指标绑定到特定DAG结构，因此绑定到特定老化机制。压缩指标测量gold关键词是否在记忆或响应中存活；干扰指标测量存在可混淆替代时是否检索正确实体；修订指标检查Agent是否引用事实的当前版本；维护指标比较生命周期事件前后的性能窗口。反事实诊断，使用P1基线、P2 oracle检索、P3 oracle上下文三个探针形成阶梯。P3残留误差1减Acc_P3捕获utilization误差，反映revision aging签名；写入误差Acc_P3减Acc_P2捕获写入时信息欠指定的compression aging签名；读取误差Acc_P2减Acc_P1捕获oracle检索恢复的干扰aging签名。

技术新颖性

技术新颖性体现在三个方面：四机制分类法，首次将长期部署Agent的可靠性退化系统性地分解为compression、interference、revision、maintenance四种机制，每个机制绑定到特定的部署压力和记忆管道阶段，使得同一表面错误可以有不同的修复路径。时序依赖DAG，首次将版本链、依赖边、干扰对和累加器集成到程序化生成的任务结构中，使得评分可以机制特定而非崩溃为单一召回数字。反事实诊断探针，首次使用P1、P2、P3阶梯对记忆管道进行组件级归因，产生指向候选阶段的诊断概况，而非仅仅端到端排名。这使得AgingBench不仅用于排名Agent，还用于指示改进应该针对写入时间保存、检索、利用还是生命周期处理。

**Figure 2**: AgingBench evaluation pipeline

**Figure 3**: Temporal dependency DAG and programmatic pressure control

**Figure 9**: Pressure control experiments on gpt-4o-mini

实验结果

实验在7个场景、14个模型、多种记忆策略、runner-controlled和autonomous agent框架上进行了约400次运行，跨越8到200会话。核心发现：老化是多维的，没有单一模型在所有机制上占优。Table 3显示没有一行在跨机制中一致占优，在一个机制下领先的方法在另一个机制下往往平均或最差。部署时模型选择取决于目标设置中哪种失败机制最相关，而非单一的更好记忆概念。行为合规性和事实准确性可以独立退化。在S2上，显式约束违反率在整个会话范围内保持接近零，但约束精度下降。Agent继续产生遵循预期对话模式的响应，即使底层值通过压缩丢失。老化难以检测：基于违反的监控显示变化很少，而事实正确性恶化。检测需要机制级探针测试事实召回，以暴露行为和不确定性监控都错过的漂移。修订老化是表征性问题，而非性能问题。S2累加器误差列显示没有随着更大模型一致改进，改变记忆策略也没有可靠减少跨Tier-1行的误差。失败似乎来自如何表示和更新累积状态，而不仅仅是记忆容量。可靠的派生值跟踪可能需要显式状态维护或定期重新计算，而非仅依赖更大模型或更好压缩。当Agent管理自己的记忆时，write-read差距持续存在。Table 3中所有Tier-2配置，workspace保真度超过下游召回。Claude Code变体差距较小，OpenHands较大，但所有测试配置中差距持续。工具日志显示Agent在探针时间确实重新访问工作空间文件，但正确响应始终涉及比错误响应更多的检索活动。失败不是由缺失写入或缺失重读引起，而是在答案生成前检索信息不足。相同干预在不同单元有相反迹象。careful对lossy对比仅在压缩敏感单元分离；在干扰敏感单元没有差异，在修订单元甚至可能反向。这表明需要每单元归因，基准输出是诊断图而非排名。

**Table 1**: Scenario design and mechanism coverage

**Table 2**: Diagnostic Probes on Memory Pipeline

**Table 3**: Multi-dimensional aging diagnostic matrix

**Table 4**: Evaluation benchmark landscape

**Table 9**: Mechanism-level findings, supporting evidence, and practical implications

**Figure 4**: Overall downward trend of aging measured by headline metrics within each scenario

**Figure 6**: Aging diagnostic profiles across different models and scenarios under our attribution

查看结构化数据

任务	指标	本文	基线	提升
S1 Research Literature	keyword_m keyword survival	GPT-4o with careful compaction: 7.6 half-life sessions, 0.43 precision	GPT-4o with lossy compaction: infinity half-life floor effect, 0.43 precision	careful compaction延长半衰期但precision相同，显示模型利用保留内容的能力阈值
S2 Lifestyle Assistant	constraint_precision	GPT-4o with lossy: 0.43; Qwen3-8B with careful: 0.80	Qwen3-8B with lossy: 0.53	careful prompt将Qwen3-8B precision从0.53提升至0.80，但GPT-4o无改善
S2 accumulator error	mean error	GPT-4o: 227; DeepSeek-7B: 211	Typed-state overlay intervention reduces error by 25-47%	显式状态维护比更大模型或更好压缩更有效
S6 Naturalistic recall	lag recall	GPT-4o lag 1: 0.54; lag 8-10: 0.20	Gemma-4 lag 1: 0.50; lag 8-10: 0.03	召回率随会话间隙单调下降，暴露时间距离轴
S7 Self-Planning	pytest	Sonnet-4.6: 0.82; Opus-4.7: 0.67	GPT-4o-mini: 0.10	旗舰模型Opus-4.7在代码质量上落后于Sonnet-4.6，尽管检索指标竞争

局限与改进

本文承认的局限性包括：生成器不声称捕获真实用户行为的完整分布。这是一种受控老化压力与自然分布的权衡：老化在嘈杂生产跟踪中可能难以测量，因为纵向信号与其他所有东西纠缠，所以合成但机制忠实的生成器提供受控测量表面。反事实诊断作为配对控制下的反事实诊断处理，而非精确的加法因果分解。我们不声称唯一因果识别。当加法记账需要探针单调性且单元格违反它时，我们将单元格报告为诊断异常而非W、R、U幅度。实验使用压缩策略而非更高级记忆架构如向量检索、图记忆、双过程设计以保持损失瓶颈为单一受控参数。这些更高级架构如何随部署老化是自然的下一步。开放前沿是将此词汇锚定到生产部署遥测，以验证在真实用户时间尺度上，此处表征的机制期望很大程度上尺度不变在数周部署中是否复合。

独立分析的弱点

独立分析的弱点包括：压缩老化的write-before-query屏障，压缩策略在写入时必须决定保留什么，但哪些事实重要取决于尚未到达的未来查询。这是一个结构性限制，给Agent更多上下文可能无法解决。改进方向：发展更好的保留预测模型，学习历史上被查询的事实模式；或者使用层级记忆，将低频细节保存在长期存储中。修订老化的表征鸿沟，派生值如运行总计、累积计数和版本化约束在添加上下文或扩展模型无法关闭差距的机制中失败，表明文本记忆可能是必须通过增量更新的状态的错误抽象。改进方向：引入typed state overlay如本文D.2节所示，在文本记忆旁边维护此类变量的JSON边车；或者将此类状态提升为Agent的显式第一类操作，而非嵌入文本总结中。Agent自管理下的retrieval不足，Tier-2显示workspace保真度超过下游召回，Agent确实重读但检索不足。改进方向：实现轻量级retrieval-budget控制器如本文D.3节所示，当per-session指标下降阈值时触发纠正动作；或者在系统提示中强制更强的重读指令如D.5节显示recall提升23%。维护老化的回归，生命周期事件如flush、recompaction或schema迁移可能触发突然的post-event回归。改进方向：在维护事件后自动运行回归检查；或者实现迁移原语，显式跟踪哪些schema或存储后端事实需要版本化。

未来方向

未来研究方向包括：更复杂记忆架构的老化，向量检索、图记忆、双过程设计、分层缓存等如何随部署老化？AgingBench的组件级诊断可以应用于这些架构以测量它们在四种机制上的表现。生产遥测验证，将AgingBench的机制级词汇锚定到生产部署遥测，以验证在真实用户时间尺度上数周、数月这些机制是否复合。这需要将benchmark信号与生产监控信号对齐。系统运行时控制，将老化建模为运行时控制问题，Agent持续决定写入什么、压缩什么、检索什么、何时recompact或flush。AgingBench可以作为运行时控制研究的闭环评估测试台，更广泛地跨场景和触发器设计。更广泛的场景覆盖，扩展场景集以捕获当前7个场景未覆盖的部署机制，例如基于SWE-bench-Aging的S8表明可以基于现有社区基准而不丢失四机制表面。跨模型族的机制特定优化，基于诊断概况，为特定老化机制设计专门的优化策略，例如compression-heavy场景的保留预测，revision-heavy场景的typed state，interference-heavy场景的改进检索算法。成本效益权衡，更大的上下文、更好的压缩、更频繁的维护检查都有成本。研究每种机制的成本效益曲线，以指导生产中的资源分配决策。

复现评估

复现评估：开源情况，AgingBench代码和场景生成器开源，支持种子可重现的任务流生成。所有实验使用确定性的种子随机化。数据，所有场景由程序化生成器支持，不需要人工标注。每个探针携带通过FactGraph的目标答案，评分基于关键词匹配或pytest，无需LLM-as-judge。算力，完整Table 3复现大约需要单H100一个GPU天加上约25美元API花费；在4-GPU节点上，本地部分并行化到8小时内。轻量子集S1、S2、S7在10会话乘3种子乘1个Haiku类模型覆盖四机制诊断，成本低于5美元且每次运行约半小时，适合作为部署前的诊断检查。难度，Tier-1实验需要配置模型和记忆策略，运行脚本自动执行会话循环、探针注入、指标计算和aging曲线生成。Tier-2实验需要agent version pinning、no-side-effects模式、显式persistent instruction文件控制、workspace-scoped工具访问和per-block workspace状态diffing，以控制生产agent的不可见状态源。附录F提供了详细的实现细节、配置参数和成本或运行时足迹。

你的Agent也会老化：部署系统的Agent生命周期工程 Your Agents Are Aging Too: Agent Lifespan Engineering for Deployed Systems