21 분 소요

0. Introduction

Paper link

Project page

Code link

Dataset collection

EvoArena를 “agent memory benchmark를 하나 더 만든 논문” 정도로 읽으면 핵심을 놓치기 쉽다. 이 논문이 실제로 겨냥하는 문제는 memory capacity보다 environment version을 따라가는 능력이다.

현재 agent benchmark의 대부분은 하나의 고정 snapshot을 전제로 한다. Terminal task의 path와 dependency는 그대로이고, repository의 API와 test도 고정되어 있으며, user preference도 한 번 주어지면 크게 바뀌지 않는다. 하지만 production environment에서는 이런 가정이 거의 유지되지 않는다.

  • CLI flag가 바뀐다.
  • Output path와 permission policy가 바뀐다.
  • Dependency와 runtime version이 올라간다.
  • Repository에 이전 milestone의 code change가 누적된다.
  • User preference가 상황과 시간에 따라 수정된다.
  • 이전 rule이 완전히 틀린 것이 아니라 특정 version에서는 여전히 유효할 수 있다.

이 setting에서 최신 memory 하나만 유지하는 방식은 위험하다. New observation이 old knowledge를 덮어쓰면, agent는 무엇이 바뀌었는지뿐 아니라 왜 바뀌었고 어느 scope에서 새 rule이 유효한지도 잃을 수 있다. 논문은 이를 state collapse에 가까운 failure로 본다.

EvoArena는 이 문제를 세 종류의 evolution chain으로 만든다.

  1. Terminal-Bench-Evo는 같은 terminal objective를 유지하면서 path, CLI, dependency, permission, validation rule을 단계적으로 바꾼다.
  2. SWE-Chain-Evo는 repository가 chronological milestone을 따라 누적 변화하는 상황을 만든다.
  3. PersonaMem-Evo는 긴 대화 안에서 user preference가 강화, 완화, 충돌, 대체되는 trajectory를 만든다.

그리고 EvoMem을 제안한다. EvoMem은 base memory를 버리지 않는다. 대신 memory가 revise, overwrite, reinterpret될 때 before state, after state, rationale, summary, evidence를 patch로 남긴다. Inference에서는 최신 memory를 기본으로 사용하되, version-specific question이나 conflict가 있을 때 relevant patch를 함께 retrieval한다.

한 줄 요약: EvoArena는 terminal workflow, software repository, user preference를 progressive version chain으로 구성해 LLM agent의 persistent environment evolution 대응 능력을 평가하고, EvoMem은 latest memory 옆에 append-only patch history를 두어 무엇이 왜 바뀌었는지를 retrievable evidence로 보존하는 memory wrapper다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같음.

  • Dynamic benchmark를 단순 task refresh가 아니라 같은 environment의 cumulative version history로 정의한다.
  • Latest-only memory가 만드는 overwrite failure를 명확한 system problem으로 제시한다.
  • Memory content보다 memory transition을 first-class data로 다룬다.
  • Isolated task accuracy뿐 아니라 evolution chain 전체의 reliability를 평가한다.
  • Terminal, coding, personalization에 같은 patch abstraction을 적용해 domain-independent interface를 보여준다.
  • Aggregate gain은 크지 않지만, chain-level consistency와 evidence preservation에서 왜 도움이 되는지 mechanism analysis를 제공한다.

이 논문은 더 큰 memory bank를 만드는 연구라기보다, agent memory를 mutable cache에서 versioned event history로 바꾸는 연구에 가깝다.

1. Problem Setting

1-1. Problem definition

EvoArena가 다루는 핵심 setting은 persistent environment evolution이다.

Environment version을 다음처럼 나타낼 수 있다.

\[\mathcal{E}^{(1)}, \mathcal{E}^{(2)}, \ldots, \mathcal{E}^{(T)}\]

각 version은 독립적인 random task가 아니다. 같은 high-level setting을 공유하면서 이전 change를 이어받는다.

\[\mathcal{E}^{(t)} = \mathrm{Update} \left( \mathcal{E}^{(t-1)}, \delta^{(t)} \right)\]

여기서 $\delta^{(t)}$는 path, interface, dependency, code, validation rule, preference처럼 현재 version에서 새로 적용된 change다.

Agent는 version $t$의 task를 풀 때 세 가지를 구분해야 한다.

  1. 새로 바뀐 것은 무엇인가.
  2. 이전 version에서 여전히 유효한 것은 무엇인가.
  3. 이전 behavior 중 더 이상 적용하면 안 되는 것은 무엇인가.

이 문제는 단순 continual learning과도 조금 다르다. Agent weight를 계속 fine-tuning하는 것이 아니라, 같은 agent가 interaction history와 memory를 사용해 current version에 맞게 행동해야 한다.

또한 environment는 episode 도중 무작위로 변하지 않는다. EvoArena의 terminal과 software task는 version별로 fixed episode를 제공한다. Dynamic하다는 뜻은 chronologically linked discrete releases가 존재한다는 뜻이다.

1-2. Static evaluation is insufficient

Static benchmark에서는 agent가 하나의 snapshot에 최적화되어도 높은 score를 얻을 수 있다.

예를 들어 terminal agent가 다음 strategy를 기억한다고 하자.

Build the artifact in /workspace/output and deploy from main.

다음 release에서 output path가 /workspace/dist로 바뀌고 protected branch policy 때문에 release branch를 사용해야 할 수 있다. Latest memory만 다음처럼 바꾸면 current task는 풀 수 있다.

Build the artifact in /workspace/dist and deploy from release.

하지만 이 update는 다음 정보를 지운다.

  • 이전 version에서는 /workspace/output이 맞았다.
  • Branch change는 policy update 때문이었다.
  • 다른 organization에서는 여전히 main을 사용할 수 있다.
  • Rollback이 발생하면 old strategy가 다시 필요할 수 있다.

Static task 하나만 보면 최신 rule만 있으면 충분하다. Evolution chain에서는 transition context가 필요하다.

1-3. State collapse in latest-only memory

일반적인 memory update는 다음과 같이 쓸 수 있다.

\[M_t = U(M_{t-1}, x_t)\]
  • $M_{t-1}$: 이전 memory
  • $x_t$: 새 observation or feedback
  • $U$: memory update function
  • $M_t$: consolidated latest memory

New information이 old information을 안전하게 supersede한다면 이 구조는 효율적이다. 하지만 version-dependent knowledge에서는 overwrite가 loss를 만든다.

예를 들어 다음 두 statement는 단순 conflict가 아니다.

  • Version 1: use API v1 with field user_id
  • Version 2: use API v2 with field account_id

Version 2가 최신이라는 사실만 저장하면 API v1 compatibility task를 처리하기 어렵다. 두 state와 transition reason을 함께 저장해야 한다.

EvoArena가 지적하는 failure는 memory가 짧아서가 아니라, consolidation이 history를 제거하는 방식으로 설계되어 있다는 점이다.

1-4. Dynamic benchmark and persistent evolution are different

Recent dynamic benchmark는 fresh task, asynchronous event, generated variant를 사용한다. 이는 static benchmark contamination과 realism 문제를 줄인다.

하지만 다음 두 setting은 다르다.

Task refresh

  • 새 issue가 들어온다.
  • 새 web page가 등장한다.
  • 새 task sample을 평가한다.
  • 이전 task와 direct version relation이 없어도 된다.

Persistent evolution

  • 같은 workflow가 release마다 바뀐다.
  • 같은 repository state가 milestone을 따라 누적된다.
  • 같은 user의 preference가 시간에 따라 바뀐다.
  • 과거 evidence와 current rule 사이 relation을 이해해야 한다.

EvoArena는 두 번째를 평가 대상으로 분리한다.

2. Core Idea

2-1. Main contribution

논문의 contribution은 benchmark와 memory method 두 축으로 나뉜다.

1) EvoArena

EvoArena는 environment evolution을 세 domain으로 구현한다.

Subset What evolves Base agent Core capability
Terminal-Bench-Evo Path, CLI, dependency, permission, validation Terminus 2 Workflow version adaptation
SWE-Chain-Evo Accumulated repository state and milestones OpenHands New change plus regression avoidance
PersonaMem-Evo Long-horizon implicit user preferences A-Mem Temporal preference reasoning

2) EvoMem

EvoMem은 existing memory updater 위에 patch recording and retrieval을 추가한다.

  • Latest memory는 current consolidated state를 제공한다.
  • Patch history는 overwritten state and update rationale을 보존한다.
  • Query가 temporal, conflicting, version-specific할 때 relevant patch를 가져온다.
  • Base agent architecture를 완전히 교체하지 않는다.

2-2. Design intuition

EvoMem의 핵심 직관은 git에 가깝다.

Git repository에서 latest file만 보면 현재 code는 알 수 있다. 하지만 bug가 언제 들어왔는지, 어떤 requirement 때문에 line이 바뀌었는지, 이전 behavior를 rollback할 수 있는지는 commit history가 있어야 알 수 있다.

Agent memory도 마찬가지다.

  • Latest memory는 current working tree다.
  • Patch는 commit diff다.
  • Rationale은 commit message다.
  • Evidence는 issue, test failure, user interaction, environment snapshot이다.
  • Retrieval은 relevant history search다.

이때 모든 observation을 patch로 저장하지 않는다. Purely additive information은 base memory에 남기고, 기존 memory를 revise, overwrite, reinterpret하는 non-additive update만 patch로 만든다.

이 선택은 patch history의 signal density를 높이려는 것이다.

2-3. Memory evolution as evidence

EvoMem은 update 전후 memory 차이를 계산한다.

\[\Delta_t = \mathrm{Diff} \left( M_{t-1}, M_t \right)\]

Non-additive update가 감지되면 patch를 만든다.

\[p_t = \left( \tau_t, C_t^{-}, C_t^{+}, r_t, z_t, e_t \right)\]

각 field는 다음 의미를 가진다.

Field Meaning
$\tau_t$ Turn, session, timestamp 같은 temporal metadata
$C_t^{-}$ Update 전 affected memory content
$C_t^{+}$ Update 후 affected memory content
$r_t$ 왜 update했는지에 대한 rationale
$z_t$ Change의 concise semantic summary
$e_t$ Triggering interaction, task feedback, snapshot 같은 evidence

Patch history는 append-only collection으로 유지된다.

\[\mathcal{P}_{1:t} = \left\{ p_1, p_2, \ldots, p_t \right\}\]

이 구조에서 memory는 두 층으로 나뉜다.

  1. Current state: $M_t$
  2. Evolution trace: $\mathcal{P}_{1:t}$

Current state만으로 충분한 query에는 patch를 사용하지 않아도 된다. Historical compatibility, conflict, rollback, temporal reasoning이 필요한 query에서 patch가 추가 evidence가 된다.

2-4. Patch-augmented retrieval

Inference에서 base memory retrieval은 그대로 유지한다.

\[c_{\mathrm{mem}} = R_{\mathrm{mem}} \left( q, M_T \right)\]

Patch retriever는 query와 relevant한 update history를 찾는다.

\[\mathcal{P}_q = R_{\mathrm{patch}} \left( q, \mathcal{P}_{1:T} \right)\]

Final context는 두 result를 합친다.

\[c(q) = \mathrm{Concat} \left( c_{\mathrm{mem}}, \mathcal{P}_q \right)\]

이 설계는 latest memory를 historical log로 대체하지 않는다. Latest state를 main path로 유지하고 patch를 exception-aware context로 추가한다.

3. Architecture / Method

3-1. Overview

Item Description
Goal Persistent environment evolution에서 agent reliability 평가 and 개선
Benchmark axis Terminal workflow, software repository, user preference
Main metric Step accuracy plus chain accuracy
Memory method Append-only non-additive update patches
Base memory Existing agent-specific memory updater 유지
Retrieval Latest memory plus query-relevant patches
Main failure Stale behavior reuse and overwritten valid state
Main claim Change history가 chain consistency and evidence capture 개선

3-2. Terminal-Bench-Evo

Terminal-Bench-Evo는 same high-level terminal objective를 version chain으로 확장한다.

Example objective는 유지되지만 operational constraint가 바뀐다.

  • Deployment mechanism
  • Input or output path
  • CLI flag
  • Runtime and dependency
  • Workspace layout
  • Permission
  • Branch policy
  • Validation rule

Construction은 다음 단계로 진행된다.

  1. Original task를 structured workflow state로 분석한다.
  2. Mutable component에 realistic evolution plan을 만든다.
  3. Version $t-1$의 realized environment를 상속해 version $t$를 만든다.
  4. Instruction, container, file, reference solution, test를 같이 수정한다.
  5. Oracle solution으로 executability and consistency를 확인한다.
  6. Invalid version을 repair or remove한다.

중요한 점은 각 version이 독립 실행 가능한 fixed environment라는 것이다. Episode 도중 path나 dependency가 갑자기 바뀌는 것은 아니다.

Current paper statistics는 다음과 같다.

Statistic Value
Original tasks and chains 89
Constructed evolved versions 356
Invalid versions removed 4
Final evolved versions 352
Total instances including initial 441
Mean chain length 4.96
Chain length range 4-5

Change category는 I/O or protocol이 49.1%로 가장 크다. 그 다음은 workspace, module, staging 13.4%, CLI or API 10.5%, dependency and toolchain 8.0%, semantic or policy or evaluation rule 4.6%다.

Terminal metrics

Step accuracy는 versioned task별 success average다.

\[\mathrm{StepAcc} = \frac{1}{N} \sum_{i=1}^{N} \mathbf{1} \left[ \mathrm{solve}(v_i) \right]\]

Chain accuracy는 chain의 모든 version을 풀어야 success다.

\[\mathrm{ChainAcc}_{terminal} = \frac{1}{|\mathcal{C}|} \sum_{C \in \mathcal{C}} \prod_{v \in C} \mathbf{1} \left[ \mathrm{solve}(v) \right]\]

한 version만 실패해도 해당 chain은 실패다. 이는 production workflow에서 release별 reliability를 더 엄격하게 반영한다.

3-3. SWE-Chain-Evo

SWE-Chain-Evo에서는 codebase 자체가 environment다.

Repository의 chronological commit window에서 coherent milestone을 만든다.

  • Feature addition
  • Bug fix
  • API adjustment
  • Dependency migration
  • Refactoring
  • Test-backed maintenance

각 milestone은 pre-milestone repository snapshot과 natural-language requirement를 제공한다. Agent가 patch를 만들면 Fail-to-Pass and Pass-to-Pass test로 평가한다.

Oracle-state progression

이 benchmark의 중요한 design은 다음 state를 agent patch로 만들지 않는다는 점이다.

  1. Agent patch를 current milestone에서 평가한다.
  2. 다음 milestone environment는 reference patch를 적용해 만든다.
  3. Agent가 이전 step에서 실패해도 next repository state는 canonical history를 따른다.

이 방식은 earlier agent error가 later task를 오염시키는 effect를 제거한다. 따라서 평가 대상은 current accumulated codebase에 대한 adaptation이다.

Real deployment에서는 agent의 실제 patch가 다음 state가 되므로 error compounding이 더 심할 수 있다. 이 점은 limitation이다.

Current paper statistics는 다음과 같다.

Statistic Value
Repositories 12
Evolution chains 50
Unique milestones 145
Chain-step instances 493
Mean chain length 9.86
Median chain length 10
Chain length range 5-15
Go instances 404
Python instances 89
Mean Fail-to-Pass tests 7.13
Mean Pass-to-Pass tests 25.85

SWE chain metric

SWE-Chain-Evo의 chain metric은 terminal exact-chain metric과 다르다.

Chain beginning부터 consecutive success가 어디까지 이어지는지를 측정한다. 첫 failure 뒤의 milestone은 chain reliability 계산에서 사실상 중단점이 된다.

\[\mathrm{ChainAcc}_{swe}(C) = \frac{ \mathrm{ConsecutiveSolvedPrefix}(C) }{ |C| }\]

즉 모든 step을 성공한 chain count만 세는 exact match가 아니라 prefix survival ratio에 가깝다. Paper table caption의 일반 설명과 subset-specific definition이 다르게 읽힐 수 있으므로 publish 전 원문 version을 다시 확인할 필요가 있다.

3-4. PersonaMem-Evo

PersonaMem-Evo는 preference evolution을 long conversation history로 만든다.

Preference는 직접 profile field로만 주어지지 않는다. User request, wording, repeated behavior, constraint, advice context 안에서 implicit하게 드러난다.

Preference trajectory example은 다음과 같다.

  1. Intense hiking을 선호한다.
  2. Injury 이후 hiking을 피한다.
  3. Recovery 이후 light trail walk를 선호한다.

Agent는 latest preference만 찾는 것이 아니라 condition과 trajectory를 이해해야 한다.

Question type은 네 가지다.

Question type Required reasoning Count
Single-pattern transfer 한 preference를 new setting에 적용 130
Multi-pattern synthesis 분산된 여러 signal을 조합 129
Temporal trajectory preference change sequence 추적 129
Conflict resolution competing preference priority 판단 117

Dataset statistics는 다음과 같다.

Statistic Value
Persona-level conversations 10
Preference chains 313
Total questions 505
Questions per persona 50.5
Median messages per history 597
Median history length 174.7K tokens
Easy, medium, hard 120, 186, 199

Temporal trajectory question은 2-10개의 source preference를 사용하며 median 6, mean 6.2다.

Dual-blind filtering

Question은 four-way multiple choice로 구성된다. Distractor에는 stereotype-consistent answer, semantically related option, outdated preference state가 들어갈 수 있다.

다음 shortcut이 가능하면 question을 제거한다.

  • Persona profile만 보고 맞힐 수 있다.
  • Interaction history 없이 맞힐 수 있다.

이 filtering은 general stereotype보다 actual conversation memory를 사용하게 만들려는 장치다.

Persona chain metric

Step accuracy는 question별 MCQ accuracy다. Chain accuracy는 같은 preference evolution chain에 속한 모든 question을 맞혀야 success다.

3-5. EvoMem across agents

EvoMem은 하나의 fixed memory schema를 강제하지 않는다.

Agent Base memory Patch content
Terminus 2 Prior terminal trajectory에서 distill한 strategy Path, dependency, interface, test change
OpenHands File, symbol, constraint, execution outcome Superseded implementation and failure cause
A-Mem Semantic note and relation graph Note or relation before and after update
Memento-Skill Global TIP.md skill memory Task-specific correction and triggering failure

각 integration은 세 항목을 정의한다.

  1. Base memory state가 무엇인가.
  2. 어떤 non-additive update가 patch trigger인가.
  3. Patch history에서 무엇을 어떻게 retrieval하는가.

이 interface가 EvoMem의 generality다.

4. Training / Data / Recipe

4-1. No new foundation model training

EvoArena는 new backbone을 pretrain하는 논문이 아니다.

  • Benchmark construction
  • Agent-memory wrapper
  • Retrieval and prompt integration
  • Multi-model evaluation
  • Mechanism analysis

가 중심이다.

따라서 성능 변화는 parameter update보다 external memory structure and context construction에서 나온다.

4-2. Benchmark construction recipe

Terminal-Bench-Evo

  1. Original task objective and environment를 구조화한다.
  2. Mutable component taxonomy를 만든다.
  3. Agent-assisted candidate update를 생성한다.
  4. Human inspection으로 semantic plausibility를 확인한다.
  5. Instruction, environment, tests, reference solution을 함께 materialize한다.
  6. Oracle execution으로 solvability를 확인한다.
  7. Version inheritance and chain consistency를 검사한다.

SWE-Chain-Evo

  1. Active and testable repository를 고른다.
  2. Continuous commit window를 추출한다.
  3. Related commit을 coherent milestone로 group한다.
  4. Formatting and incidental change를 제거한다.
  5. Pre-milestone context에서 task description을 만든다.
  6. Docker environment and F2P, P2P test를 구성한다.
  7. Chronological order로 chain을 assemble한다.
  8. Reference patch로 next state를 진행한다.

PersonaMem-Evo

  1. Seed persona를 structured profile로 확장한다.
  2. Preference inventory를 clean and categorize한다.
  3. Implicit preference interaction을 생성한다.
  4. Preference update trajectory를 만든다.
  5. Transfer, synthesis, conflict, temporal question을 생성한다.
  6. Persona-only and no-context shortcut을 filter한다.
  7. Balanced answer option and metadata를 저장한다.

4-3. Patch recording policy

Patch를 모든 observation에 만들면 history가 빠르게 커진다. EvoMem은 non-additive update에 집중한다.

Patch-worthy update

  • Existing strategy revised
  • User preference superseded
  • Tool interface changed
  • Earlier assumption invalidated
  • Skill file rewritten
  • Prior implementation abandoned after failure

Base-memory-only update

  • Completely new independent fact
  • New task unrelated to existing state
  • Additive context that does not revise prior memory

실제 production에서는 이 classification 자체가 어렵다. “새 정보”와 “기존 belief revision”의 경계가 model judgment에 의존할 수 있다.

4-4. Current public PersonaMem recipe

Public repository의 PersonaMem-Evo implementation은 현재 다음 setting을 예시로 제공한다.

Parameter Current example
Latest-memory retrieval top-k 10
Patch retrieval top-k 3
Minimum patch similarity 0.4
Patch usage always
Context size 32k

이 값은 PersonaMem-Evo 공개 implementation의 current run setting이다. Terminal and software domain에 그대로 적용하는 universal hyperparameter로 보면 안 된다.

Repository는 release가 progressive하다고 명시한다. Top-level README 기준으로 PersonaMem experiment folder는 runnable instruction을 제공하지만 Terminal-Bench-Evo and SWE-Chain-Evo folder는 release status를 별도로 확인해야 한다.

4-5. Retrieval and context engineering

Patch retrieval에는 세 가지 trade-off가 있다.

Recall

Relevant historical transition을 놓치면 latest-only memory와 크게 다르지 않다.

Precision

Irrelevant old patch를 넣으면 stale behavior를 다시 활성화할 수 있다.

Context cost

Patch가 많을수록 token use and attention noise가 증가한다.

따라서 production retrieval은 semantic similarity만으로 충분하지 않을 수 있다.

Recommended metadata는 다음과 같다.

  • Environment ID
  • Version range
  • Validity scope
  • Superseded-by patch
  • Rollback relation
  • Confidence
  • Evidence type
  • Last verified timestamp
  • Security or privacy label

4-6. Engineering notes

  1. Base memory와 patch log를 분리
    • Current state query는 fast path로 처리한다.
    • Temporal or conflict query만 patch path를 사용한다.
  2. Patch는 append-only로 기록
    • Old state를 destructive delete하지 않는다.
    • Privacy deletion은 별도 tombstone and purge policy로 처리한다.
  3. Before and after를 모두 저장
    • Diff summary만 있으면 old state를 복원하기 어렵다.
  4. Rationale and evidence를 분리
    • Model explanation과 actual trigger evidence를 같은 field로 섞지 않는다.
  5. Version scope를 명시
    • “New rule”이 모든 tenant and version에 적용된다고 가정하지 않는다.
  6. Retrieval result를 latest state보다 우선하지 않게 함
    • Historical patch는 context이지 unconditional command가 아니다.
  7. Patch poisoning을 방어
    • Untrusted tool output or prompt injection이 persistent patch가 되지 않게 approval gate를 둔다.
  8. Memory compaction을 설계
    • Similar patches를 merge하더라도 original evidence pointer는 유지한다.
  9. Chain evaluation을 production regression으로 사용
    • Latest version task뿐 아니라 historical compatibility suite를 함께 돌린다.

5. Evaluation

5-1. Main setup

EvoArena는 domain에 맞는 base agent를 사용한다.

Benchmark Agent
Terminal-Bench-Evo Terminus 2
SWE-Chain-Evo OpenHands
PersonaMem-Evo A-Mem
GAIA Memento-Skill
LoCoMo A-Mem

여러 closed and open backbone을 비교한다. Current paper table에는 GPT-5.5, Gemini-3.1-Pro, Kimi-K2.6, Deepseek-V4-Pro, GLM-5.1, MiniMax-M2.7, Qwen3.6-27B, Gemma4-31B 등이 포함된다.

2026-08-26 발행 전 model name and exact version은 원문 최신 revision에서 다시 확인할 필요가 있다.

5-2. Current agents struggle with evolution

EvoArena 세 subset의 base step average는 다음과 같다.

Benchmark Base step accuracy Base chain accuracy
Terminal-Bench-Evo 43.6% 21.5%
SWE-Chain-Evo 27.9% 10.0%
PersonaMem-Evo 47.3% 40.0%

세 step average를 평균하면 약 39.6%다. Abstract가 강조하는 current agent average도 이 값이다.

Chain score가 step score보다 낮다는 점이 중요하다. Isolated version을 일부 잘 푸는 것과 release history 전체에서 reliable한 것은 다르다.

특히 SWE-Chain-Evo의 average chain score는 10.0%다. Repository evolution이 길어질수록 한 번도 끊기지 않고 consecutive milestone을 처리하는 능력이 약하다는 뜻이다.

5-3. EvoMem main results

Current result table 기준 average는 다음과 같다.

Benchmark Step Base Step +EvoMem Delta Chain Base Chain +EvoMem Delta
Terminal-Bench-Evo 43.6% 46.0% +2.4 21.5% 27.6% +6.1
SWE-Chain-Evo 27.9% 28.3% +0.4 10.0% 12.1% +2.1
PersonaMem-Evo 47.3% 49.0% +1.7 40.0% 43.2% +3.2

세 subset의 rounded step gain average는 약 +1.5 point다. Abstract의 main claim과 일치한다.

Chain gain은 step gain보다 대체로 크다. Abstract는 overall chain-level improvement를 +3.7 point로 보고한다. Rounded subset delta를 단순 평균하면 약 +3.8 point가 되므로 exact unrounded aggregation을 확인해야 한다.

결과를 과장해서 읽을 필요는 없다.

  • Step gain은 modest하다.
  • 모든 model and subset에서 개선되는 것은 아니다.
  • Chain reliability에서 signal이 더 크다.
  • Patch availability보다 patch uptake가 중요하다.

5-4. Standard benchmark transfer

Current main table은 GAIA and LoCoMo에서도 improvement를 보고한다.

Benchmark Base +EvoMem Table delta
GAIA 65.8% 72.3% +6.5
LoCoMo 39.7% 43.0% +3.3

다만 abstract에는 GAIA +6.1, LoCoMo +4.8로 적혀 있다. Main table and abstract 사이 수치가 다르므로 최종 post에서는 current arXiv revision을 다시 확인해야 한다.

이 discrepancy는 Verification Notes에 남겨두는 것이 안전하다.

5-5. Non-uniform gains

EvoMem은 average로 개선되지만 모든 setting에서 positive하지 않다.

SWE-Chain-Evo step regression examples

  • Gemini-3.1-Pro: 20.5 -> 18.1, -2.4
  • Kimi-K2.6: 30.2 -> 27.6, -2.6

PersonaMem-Evo regression example

  • GLM-5.1 step: 50.4 -> 47.5, -2.9
  • GLM-5.1 chain: 42.5 -> 38.9, -3.7

Persona question-type regression

  • Conflict resolution: 29.5 -> 28.6
  • Single-pattern transfer: 46.2 -> 44.4

Patch history는 evidence availability를 높이지만 final reasoning을 자동으로 해결하지 않는다. Irrelevant patch, conflicting state, retrieval noise가 오히려 performance를 낮출 수 있다.

5-6. Terminal mechanism analysis

논문은 patch가 단순히 context에 존재하는 것보다 실제 reasoning and command에 반영될 때 gain이 커지는지 본다.

Condition Weaker gain Stronger gain
No patch example vs patch example retrieved +3.1 +6.5
Low vs high evolved-requirement coverage +2.1 +5.3
No patch uptake vs patch uptake +2.6 +8.3
No command-level uptake vs command-level uptake +3.1 +6.2

가장 큰 차이는 patch uptake다.

이 결과의 의미는 EvoMem이 “더 많은 context”라서 좋아지는 것이 아니라는 점이다. Agent가 patch에서 old procedure의 reusable part와 changed requirement를 분리해 action에 반영해야 한다.

다만 이 analysis는 observational이다. Successful trajectory가 patch term을 더 많이 사용하는 것인지, patch use가 success를 causally 만든 것인지는 완전히 분리되지 않는다.

5-7. Software regression analysis

SWE-Chain-Evo에서는 new milestone을 해결하면서 previous behavior를 깨뜨리는지 본다.

Pass-to-Pass failure rate average는 다음처럼 감소한다.

\[9.09\% \rightarrow 6.32\%\]

Backbone별 result는 다음과 같다.

Model Base P2P failure +EvoMem Reduction
Qwen3.6-27B 9.01% 6.73% 2.28
Kimi-K2.6 7.14% 3.33% 3.81
Gemini-3.1-Pro 11.11% 8.89% 2.22

Step accuracy gain이 작아도 regression reduction은 의미가 있다. EvoMem이 prior milestone의 constraint and failure evidence를 보존해 backward compatibility에 도움을 줄 수 있다는 signal이다.

5-8. Preference evidence analysis

PersonaMem-Evo에서 EvoMem은 temporal trajectory and multi-pattern synthesis에 가장 큰 gain을 보인다.

Question type Base +EvoMem Delta
Conflict resolution 29.5% 28.6% -0.9
Single-pattern transfer 46.2% 44.4% -1.8
Multi-pattern synthesis 38.8% 44.0% +5.2
Temporal trajectory 46.6% 51.7% about +5.1
Overall 40.5% 42.5% +2.0

Temporal and multi-pattern question은 dispersed evidence and intermediate state가 중요하다. Latest-only summary가 놓치기 쉬운 영역이다.

Memory evidence capture도 개선된다.

Metric Base +EvoMem Delta
Clause-level capture 89.4% 90.3% +0.9
Row-level complete capture 72.5% 74.9% +2.4

Row-level gain이 더 크다는 것은 individual fact 하나보다 answer에 필요한 evidence set 전체를 함께 보존하는 데 patch가 도움이 된다는 뜻이다.

5-9. Efficiency and accuracy

논문은 total token usage와 accuracy도 비교한다. 결론은 simple하다.

More tokens do not reliably mean better agent performance.

Longer trajectory와 more retrieved memory는 capability proxy가 아니다. Patch memory도 retrieval budget을 늘릴 수 있으므로 accuracy and token cost를 함께 측정해야 한다.

5-10. What really matters in the experiments

1) Chain metric is more deployment-relevant

Production user는 five release 중 four release를 성공한 agent보다 모든 release에서 predictable한 agent를 원할 수 있다. Average step score만으로는 intermittent failure를 숨길 수 있다.

2) Memory history helps most when state is revised

EvoMem은 purely additive knowledge task보다 overwritten state, temporal trajectory, regression avoidance에서 의미가 크다.

3) Retrieval alone is insufficient

Patch를 가져온 뒤 reasoning and action에 반영해야 한다. Retrieval metric과 task success 사이 interface가 중요하다.

4) Evidence preservation and reasoning are separate bottlenecks

Persona conflict resolution이 악화된 결과는 evidence가 있어도 priority inference가 약할 수 있음을 보여준다.

5) Average gain hides model-specific harm

Memory module을 universal add-on처럼 켜기보다 backbone and domain별 validation이 필요하다.

6. Limitations

  1. Evolution is discrete, not within-episode continuous
    • 각 version episode는 fixed environment다.
    • Production에서 tool or policy가 실행 중 바뀌는 asynchronous drift는 다루지 않는다.
  2. Terminal evolution is partly synthetic
    • Update는 realistic taxonomy and oracle validation을 사용하지만 naturally occurring release log만으로 구성된 것은 아니다.
    • Agent-assisted construction bias가 있을 수 있다.
  3. SWE next state uses reference patch
    • Agent의 실제 prior patch가 next repository state가 되지 않는다.
    • Real deployment의 error compounding and repair debt를 제거한 setting이다.
  4. SWE chain metric definition is unusual
    • Consecutive solved prefix ratio를 chain accuracy라고 부른다.
    • Terminal and Persona의 all-or-nothing chain metric과 직접 비교하기 어렵다.
  5. Persona data is synthetic and small in persona count
    • 10 persona conversation에 505 question을 구성한다.
    • Real user preference change, ambiguity, consent를 충분히 대표하지 못할 수 있다.
  6. MCQ format limits personalization realism
    • Real assistant는 free-form recommendation and action을 해야 한다.
    • Balanced option accuracy가 user satisfaction을 직접 대변하지 않는다.
  7. EvoMem gains are modest and non-uniform
    • EvoArena average step gain은 약 +1.5 point다.
    • 일부 backbone and question type에서는 regression이 발생한다.
  8. Mechanism analysis is observational
    • Patch uptake와 success correlation이 causal intervention으로 완전히 검증된 것은 아니다.
  9. Patch trigger quality is a new bottleneck
    • Non-additive update를 잘못 감지하면 important history를 놓치거나 unnecessary patch를 만든다.
  10. Patch retrieval can revive stale behavior
    • Similarity가 높다는 이유만으로 old rule을 가져오면 current version에 맞지 않을 수 있다.
    • Version scope and validity metadata가 필요하다.
  11. Append-only history grows indefinitely
    • Storage, indexing, context cost, duplicate patch 문제가 생긴다.
    • Compaction policy가 필요하다.
  12. Privacy deletion conflicts with append-only memory
    • User가 old preference 삭제를 요청해도 patch history에 남을 수 있다.
    • Right-to-delete and audit requirement 사이 정책이 필요하다.
  13. Persistent poisoning risk
    • Prompt injection or malicious tool feedback가 patch로 저장되면 future session까지 영향을 줄 수 있다.
  14. Rationale can be post-hoc
    • Model-generated reason이 actual causal explanation과 다를 수 있다.
    • Trigger evidence와 explanation을 분리해서 저장해야 한다.
  15. Benchmark averages mix different agents and metrics
    • Terminus, OpenHands, A-Mem은 interaction loop and memory schema가 다르다.
    • Cross-domain average는 method generality를 보여주지만 exact comparability는 제한적이다.
  16. Paper text and table have numerical discrepancies
    • GAIA and LoCoMo improvement가 abstract와 main table에서 다르다.
    • 일부 subset delta도 prose and rounded table이 다르게 보인다.
  17. Public release is progressive
    • Repository top-level README는 일부 experiment folder가 순차 공개된다고 명시한다.
    • Code, dataset, license completeness를 publish 전에 다시 확인해야 한다.
  18. Current model names may change
    • 2026-08-26 발행 전 model version, API behavior, evaluation checkpoint를 재검증해야 한다.

7. My Take

7-1. Why this matters for my work

이 논문의 가장 중요한 메시지는 “memory를 더 많이 저장하자”가 아니다.

Agent memory는 state store가 아니라 state transition log여야 할 수 있다.

Production system에서 current config만 저장하면 현재 behavior는 재현할 수 있다. 그러나 incident analysis, rollback, tenant-specific policy, compatibility, audit에는 change history가 필요하다.

이는 software engineering에서 이미 익숙한 pattern이다.

  • Git commit history
  • Database event sourcing
  • Schema migration log
  • Configuration revision
  • Feature flag history
  • Model registry
  • Experiment lineage

Agent memory도 같은 방향으로 갈 가능성이 크다.

7-2. Memory as event sourcing

Latest-only memory는 materialized view로 볼 수 있다. Patch history는 event log다.

\[M_t = \mathrm{Fold} \left( M_0, p_1, p_2, \ldots, p_t \right)\]

이 관점에서 중요한 것은 patch를 prompt text로만 저장하는 것이 아니다. Structured event schema가 필요하다.

Recommended patch schema는 다음과 같다.

Field Production purpose
Memory key 어떤 state가 바뀌었는가
Before and after Diff and rollback
Valid from and valid to Temporal scope
Environment version Release compatibility
Tenant or user scope Context boundary
Trigger evidence Grounding
Rationale Human-readable explanation
Confidence Retrieval weighting
Supersedes Conflict graph
Security label Injection and privacy control
Reviewer Approval and audit
Tombstone Deletion and retention policy

7-3. Reuse potential

1) Coding agent

  • API migration history
  • File move
  • Test expectation change
  • Deprecated implementation
  • Previous regression cause
  • Repository-specific convention

Coding agent가 current repository만 읽더라도 old failure and fix rationale는 patch memory에서 가져올 수 있다.

2) DevOps and terminal agent

  • Deployment path change
  • Credential and permission policy
  • Runtime migration
  • CLI flag change
  • Rollback procedure
  • Environment-specific exception

Runbook을 하나의 latest document로 계속 덮어쓰기보다 revision patch를 유지하는 방식과 잘 맞는다.

3) Enterprise workflow agent

  • Approval rule
  • Form schema
  • Data retention policy
  • Role permission
  • Vendor API
  • Regional compliance

New policy가 old policy를 완전히 대체하지 않고 region, date, customer tier별로 다를 수 있다. Scope-aware patch가 중요하다.

4) Personalized assistant

  • Temporary preference
  • Medical or injury constraint
  • Travel context
  • Household member distinction
  • Preference recovery
  • User-requested deletion

Personalization에서는 old preference를 기억하는 것과 잊어야 하는 것을 구분해야 한다. EvoMem idea를 그대로 쓰기보다 privacy-aware patch lifecycle이 필요하다.

5) Research agent

  • Hypothesis revision
  • Dataset version
  • Failed experiment
  • Metric definition change
  • Reviewer feedback
  • Claim update

Final conclusion만 저장하면 왜 방향이 바뀌었는지 잃는다. Experiment trace and rationale를 patch로 남기면 reproducibility에 도움이 된다.

7-4. Production architecture

실제 system에서는 다음 layer가 필요하다.

1) Change detector

  • Base memory update 전후 semantic diff
  • High-impact key change detection
  • Version or scope extraction
  • Additive vs non-additive classification

2) Patch validator

  • Trigger evidence 존재 여부
  • Source trust
  • Conflict with policy
  • Prompt injection scan
  • Human approval requirement

3) Patch store

  • Append-only record
  • Vector index
  • Structured filter
  • Supersession graph
  • Retention and deletion

4) Retrieval router

Query를 먼저 분류한다.

  • Current-state query
  • Historical query
  • Compatibility query
  • Conflict query
  • Rollback query

Current-state query에는 latest memory만 쓰고, 나머지에 patch retrieval을 켜면 cost and noise를 줄일 수 있다.

5) Resolution policy

Multiple patch가 conflict할 때 priority를 정한다.

\[\mathrm{Score}(p, q) = \alpha s_{\mathrm{semantic}} + \beta s_{\mathrm{version}} + \gamma s_{\mathrm{scope}} + \eta s_{\mathrm{evidence}} - \lambda s_{\mathrm{staleness}}\]

Weight는 domain별로 달라야 한다. Security policy에서는 newest approved patch가 중요하고, rollback analysis에서는 old version exact match가 중요하다.

6) Regression harness

Memory update가 들어올 때 다음을 함께 평가한다.

  • Current version success
  • Previous version compatibility
  • Stale behavior suppression
  • Patch retrieval precision
  • Token overhead
  • Privacy deletion compliance

7-5. Follow-up papers

  • Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
  • A-Mem: Agentic Memory for LLM Agents
  • Memento-Skill: Skill Memory for Tool-Use Agents
  • PersonaMem-v2: Personalized Intelligence from Implicit User Memory
  • GAIA2: Dynamic and Asynchronous Agent Evaluation
  • Terminal-Bench
  • SWE-bench-Live
  • HorizonBench
  • TaskMem: Task-Focused Memorization for Multimodal Agents

8. Summary

  • EvoArena는 같은 environment가 version chain을 따라 바뀌는 persistent evolution을 평가한다.
  • Terminal workflow, repository milestone, user preference의 세 domain을 포함한다.
  • EvoMem은 latest memory를 유지하면서 non-additive update를 append-only patch로 기록한다.
  • Average step gain은 modest하지만 chain reliability, software regression, temporal evidence capture에서 stronger signal을 보인다.
  • Production agent memory에는 content retrieval뿐 아니라 version, rationale, scope, evidence, deletion policy가 필요하다.

댓글남기기

참고