모델은 멈춰 있어도 에이전트는 계속 배울 수 있다

기존의 질문: 파라미터를 바꾸면서 어떻게 잊지 않을 것인가

전통적인 continual learning은 sequential task나 data stream을 따라 model parameters, representations, architectures를 업데이트하면서 catastrophic forgetting을 줄이는 문제로 정식화돼 왔다. representation-based, architecture-based, optimization-based, regularization-based, replay-based 접근이 그 대표적 해법이다.

이 관점에서는 학습된 상태가 대체로 모델 내부에 있다. 새 task가 들어오면 gradient, module, representation, replay buffer를 조절해 old task performance를 보호한다. 저자들은 이것을 model-centric continual learning이라고 부른다.

현대 에이전트는 모델 밖에 더 많은 상태를 갖는다

agentic AI가 등장하면서 실행은 foundation model 하나로 설명되지 않는다. raw instruction을 구조화하는 interface, 과거 상호작용을 저장하는 memory, 외부 tool과 내부 skill을 설명하는 capability registry, 어떤 memory와 tool을 언제 쓸지 정하는 router 또는 workflow controller가 model 주변에 놓인다.

ReAct는 reasoning과 action을 연결했고, Toolformer·MRKL·HuggingGPT는 외부 capability를 호출하는 방식을 확장했다. MemGPT·Reflexion·Voyager는 경험, reflection, executable skill을 지속 상태로 남겼다. DSPy와 최근 harness optimization 연구는 prompt, declarative program, workflow까지 실행 피드백으로 고친다.

이제 “학습”은 모델 파라미터의 변화만 뜻하지 않는다. prompt 한 줄, retrieval rule 하나, skill definition 하나가 이후 수백 개 interaction의 행동을 바꿀 수 있다.

모델을 한 번도 fine-tune하지 않았는데도 어제 되던 일이 오늘 안 될 수 있다

이 논문의 가장 중요한 개념은 harness-level forgetting이다. memory update가 예전 query에서 다른 evidence를 불러올 수 있고, skill revision이 tool call 형식을 바꿀 수 있으며, routing edit가 previously successful workflow를 다른 경로로 보내버릴 수 있다. foundation model은 그대로인데 correct answer, valid tool call, successful action trajectory가 실패로 바뀐다.

Figure 1은 바로 이 learning-object shift를 시각화한다. model-centric CL이 \(\theta_1\to\theta_2\to\theta_3\)의 parameter trajectory를 다룬다면, HCL은 frozen model 주변에서 harness state가 candidate 생성과 validation을 거쳐 진화하는 trajectory를 다룬다.

Frozen model \(F_\theta\), evolving harness \(H_n\)

interaction step \(n\)에서 foundation model \(F_\theta\)는 고정돼 있고 deployed harness \(H_n\)만 바뀐다. raw interaction \(u_n\)은 instruction, observation, multimodal input일 수 있다. harness는 이를 structured interaction \(i_n\)으로 바꾸고, 관련 memory와 capability를 선택해 execution context \(z_n\)을 만든다. model과 runtime은 \(z_n\)을 실행해 outcome \(y_n\)을 만들고 post-execution feedback \(f_n\)을 받는다.

Optimizer는 현재 harness와 이 interaction evidence를 보고 candidate를 제안한다.

하지만 candidate는 바로 배포되지 않는다. commitment decision \(G_n\in\{0,1\}\)을 통과해야 한다.

문제를 잘 푸는 일은 문제를 정확히 구조화하는 데서 시작한다

Task Interface는 raw input을 available input \(x_n\), goal \(g_n\), constraint \(k_n\)으로 구조화한다.

constraint에는 output format, legal tool use, environment restriction이 들어갈 수 있다. HCL에서 interface 자체가 versioned되는 이유는 parsing rule이나 task template의 작은 변화가 downstream router가 보는 문제정의를 바꾸기 때문이다.

기억은 사례와 추상화의 두 층으로 나뉜다

Raw Memory는 task input \(u_n\), response/action trajectory \(y_n\), feedback \(f_n\)을 저장한다. storage를 bounded하게 유지하기 위해 task마다 고정 개수의 interaction을 arrival order로 보존한다. 성공한 행동뿐 아니라 failure evidence도 남아, 예전 solution을 재사용하거나 같은 오류를 반복하지 않는 데 쓰인다.

Abstract Memory는 LLM이 Raw Memory를 요약해 recurring pattern을 scoped guidance로 바꾼다. output convention, reliable reasoning pattern, common error 같은 형태다. Raw Memory가 replay와 recovery의 구체적 증거라면, Abstract Memory는 cross-task transfer를 위한 일반화된 기억이다.

경험은 기억에서 끝나지 않고 호출 가능한 skill이 된다

Outer capability는 API, retrieval service, perception model, calculator, environment action처럼 외부 runtime이 제공하는 기능이다. 각 항목은 function, input/output, invocation protocol, availability condition, known limitation을 가진다.

Inner capability는 Abstract Memory에서 더 추상화된 reusable skill이다. 입력, 출력, 실행 단계, 적용 범위를 명시하는 절차로 바뀌기 때문에 agent가 과거 경험을 “기억”하는 것을 넘어 “다시 실행 가능한 능력”으로 재사용할 수 있다.

좋은 부품을 갖고 있어도 언제 무엇을 쓸지 틀리면 에이전트는 실패한다

Router는 structured interaction을 보고 relevant memory와 capability를 고르고 execution workflow를 구성한다.

Memory와 Capability Map이 계속 바뀌면 어떤 경험과 skill이 현재 task에 적절한지도 달라진다. 그래서 routing prompt, selection criteria, workflow template도 함께 학습대상이 된다.

feedback을 보고 어느 component를 고칠지 먼저 진단한다

interaction feedback은 성공과 실패를 알려주지만 harness를 어떻게 바꿔야 하는지 직접 말해주지는 않는다. Continual Optimizer는 deployed harness와 execution evidence를 foundation model에 제공하고 어떤 component가 문제였는지 분석하게 한다.

수정 대상은 interface prompt/parsing rule, memory record/summary, capability skill, router selection/workflow rule이 될 수 있다. 여러 component를 고쳐야 할 때는 predefined order로 하나씩 처리하고, 각 component에서 최대 \(K\)개의 alternatives를 순차적으로 제안한다. 선택된 component만 candidate에 교체하고 나머지는 고정한 채 평가하며, 통과한 alternative 중 가장 높은 점수를 다음 component 수정의 기반으로 사용한다.

현재 task에서 실제로 좋아졌는가

current validation set \(V_n\)에서 harness performance를 \(P(H,V_n)\)라고 두면 candidate improvement는 다음과 같다.

candidate는 \(\Delta_n\ge\delta_n\)을 만족해야 한다. task에 따라 \(P\)는 answer accuracy, tool-use success, environment completion이 될 수 있다.

새로 좋아진 만큼 예전 행동이 무너졌는지 센다

Evaluator는 과거 task의 compact anchor set \(A_n\)을 별도로 유지한다. anchor는 raw input과 success criterion을 담고 있으며 candidate generation에는 공개되지 않는다. 같은 input과 execution condition에서 current harness와 candidate를 다시 실행해 과거 성공이 유지되는지 본다.

historical loss \(D_n\)은 current harness가 성공했던 anchor가 candidate에서 실패로 바뀐 경우만 센다.

candidate는 \(D_n\le B_n\)을 만족해야 한다. \(B_n=0\)이면 현재 해결 중인 모든 anchor를 보존해야 한다. 반대로 \(B_n=\infty\)면 historical regression이 current improvement gate를 막지 않는다.

성능이 좋아도 artifact가 깨지거나 tool policy를 위반하면 배포하지 않는다

validity checks는 syntax, output schema, legal tool use, task constraint, environment consistency를 다룬다. 각 check \(\ell\)에 대해 candidate가 조건을 만족하면 \(v_{n,\ell}(\widetilde{H}_{n+1})=1\)이다.

세 조건은 hard admissibility gate로 결합된다.

여러 candidate가 gate를 통과하면 current performance, validity, historical retention을 합친 composite score로 순위를 정해 최고 candidate를 commit한다. tie는 random하게 깨고, 아무 candidate도 통과하지 못하면 \(H_n\)을 그대로 유지한다.

replay, representation, architecture, regularization 원리를 harness mechanism으로 옮긴다

저자들은 HCL이 전통 CL 기법의 일대일 구현은 아니라고 선을 긋지만 대응관계는 분명하다. Raw Memory는 replay의 concrete examples를 보존하고, Abstract Memory와 Capability Map은 reusable abstraction과 skill을 만든다. Router는 modular routines를 선택·조합하며, Optimizer와 Evaluator는 historical information을 사용해 update trajectory를 제약한다.

차이는 이 모든 기능이 한 model-update algorithm의 변형이 아니라 하나의 evolving agent infrastructure 안에서 acquisition-retention objective로 조정된다는 데 있다.

stage가 끝날 때마다 지금까지 본 모든 task를 다시 평가한다

task \(D_s\)를 학습한 뒤의 deployed harness를 \(H^{(s)}\)라고 두고, stage \(s\)에서 현재 및 과거 task \(j\le s\)를 모두 평가한다.

current validation과 historical anchors는 commitment decision에만 쓰이고 final test set과는 분리된다. 즉 candidate selection용 데이터와 reporting용 데이터가 겹치지 않는다.

최종 성능과 과거 task의 하락을 동시에 본다

Avg는 전체 stream이 끝난 뒤의 평균 성능이고, Fgt는 old task가 과거 최고점에서 최종 시점까지 얼마나 떨어졌는지를 평균한 값이다. Zero-shot이나 Static Harness는 sequential update를 하지 않으므로 forgetting을 표기하지 않는다.

Stability-HCL과 Plasticity-HCL의 차이는 historical-loss tolerance 하나다

같은 foundation model, 같은 task order, 같은 candidate generator를 사용하고 \(B_n\)만 바꾸기 때문에 두 profile의 차이는 stability-plasticity operating point를 직접 보여준다.

부록의 성공 기준은 “유지해야 할 행동”을 task별로 구체화한다

historical-loss counting은 비대칭적이다. 예컨대 RefCOCO anchor의 IoU가 0.68에서 0.41로 떨어지면 성공→실패 경계를 넘었으므로 loss 1개를 추가한다. 다른 anchor가 좋아졌다고 이 손실을 상쇄하지 않는다.

모델 family와 scale을 바꿔 특정 backbone에만 맞는 현상인지 확인한다

Static Harness는 15개에서 멈추고 HCL은 50-task curriculum을 끝낸다

Minecraft 실험은 collection, crafting, mining, tool use, placement, smelting, dependent multi-step task를 포함하는 50-task curriculum이다. feedback은 Experience Memory에 들어가 skill과 workflow를 수정하는 근거가 되고, previously validated skill tests가 historical anchors로 유지된다.

Figure 3의 두 그래프는 단순 completion뿐 아니라 later multi-step task에서 repeated diagnosis, crafting, recovery action이 줄어드는 경향을 보여준다. 다만 부록은 Minecraft retention이 full task replay가 아니라 retained skill test 수준이라는 점을 명시한다. 이 실험은 skill-level retention을 보여주며 모든 completed task를 update마다 체계적으로 재검증한 것은 아니다.

anchor를 모두 지켜도 unseen historical test behavior까지 보장할 수는 없다

\(b=0\)인데 textual sweep final forgetting이 0.39인 이유는 모순이 아니다. gate는 finite anchor set을 보호하지만 forgetting은 별도의 historical test cases에서 측정한다. anchor가 history 전체를 완벽히 대표하지 못하면 현재 성공 중인 모든 anchor를 보존해도 다른 old case에서 regression이 생길 수 있다.

이 지점은 HCL의 가장 현실적인 한계를 드러낸다. retention evaluation 자체가 sampling problem이다. 모든 과거 interaction을 매 update마다 replay할 수 없다면 어떤 anchor를 저장하고 어떤 behavior를 보호할지가 새 연구문제가 된다.

무엇이 persistent state이고 무엇이 evaluation-only인지 경계를 명확히 한다

부록 Table 7은 execution과 evaluation 사이의 정보 경계를 명시한다. Task Interface, Raw/Abstract Memory, Capability Map, Adaptive Router는 deployed harness의 persistent contents이고 candidate generator가 수정할 수 있다. 반면 interaction representation \(i_n\), execution context \(z_n\), outcome \(y_n\)은 transient다.

가장 중요한 경계는 Anchor Set \(A_n\)이다. anchor는 Evaluator만 사용하며 execution과 candidate generation에는 보이지 않는다. task가 끝날 때 업데이트된 뒤 다음 candidate-generation/evaluation 구간에서는 고정된다. candidate가 anchors를 보고 그 테스트에 맞춰 과적합하는 것을 줄이려는 설계다.

main profile과 budget sweep은 gate threshold가 다르다

부록 Table 8에 따르면 main Stability/Plasticity profile에서는 discrete metric 기준 최소 1개 validation case 개선 또는 designated continuous score의 strict improvement가 필요하고 invalid outcome을 만들면 안 된다. 반면 independent textual budget sweep은 80 validation cases에서 최소 2개 정답 증가, format compliance 90% 이상, syntax/tool/environment violation 0을 요구한다.

ALFWorld는 final 134 official evaluation episodes를 사용하고, Minecraft는 cumulative completion, recovery events, validated skill changes를 본다. Minecraft는 \(B_n=0\)을 retained skill tests에 적용하므로 full task-level retention보다 skill-level retention에 가깝다. 이 차이를 섞어서 해석하면 안 된다.

frozen model 주변의 harness evolution만으로 capability accumulation과 regression control이 가능하다

논문이 직접 보여주는 것은 세 가지다. 첫째, parameter update 없이도 harness state를 진화시켜 reasoning, multimodal, interactive task에서 capability를 누적할 수 있다. 둘째, 같은 과정에서 harness-level forgetting이 실제로 측정된다. 셋째, historical-loss tolerance를 통해 stability와 plasticity의 operating point를 조절할 수 있다.

특히 ALFWorld, textual reasoning, multimodal perception에서 HCL이 대응 baseline보다 높은 final average를 보이고, Minecraft에서는 50-task progression과 낮은 action redundancy를 보여준다. 그러나 가장 중요한 결과는 “더 많이 바꾸면 더 좋아진다”가 아니라 retention-aware update gate가 최종 trajectory의 질을 바꾼다는 점이다.

retention check가 비싸지고 harness가 오래 살수록 새로운 문제가 커진다

결론은 세 가지 unresolved challenge를 남긴다. efficient retention evaluation, harness-content consolidation, longer interaction streams이다. anchor를 늘리면 retention coverage는 좋아지지만 매 candidate마다 replay cost가 커진다. memory와 skill이 계속 추가되면 redundancy와 contradiction을 정리해야 한다. task stream이 길어질수록 version lineage와 rollback, compatibility, anchor sampling 문제가 더 어려워진다.

모델을 다시 훈련하지 않는 self-improvement가 본격적인 연구대상이 된다

HCL을 AGI의 증거라고 부를 수는 없다. 이 논문은 bounded benchmark와 controlled environment에서 harness evolution을 평가한 연구다. 다만 중요한 방향은 분명하다. modern agent의 능력은 foundation model weight만으로 결정되지 않고, model 주변에서 누적되는 memory, tools, skills, interfaces, routing policies의 조직방식에도 크게 의존한다.

따라서 agent self-improvement를 연구하려면 “더 좋은 model checkpoint를 만드는가?”뿐 아니라 “실제 deployed system이 경험을 통해 어떤 persistent artifacts를 만들고, 그 변경을 어떻게 검증하고, 무엇을 기억하며, 언제 rollback하는가?”를 함께 물어야 한다.