[arXiv 2606.13317] SkillCAT: 대비 평가와 토폴로지 라우팅으로 에이전트 스킬을 진화시키기

SkillCAT: Contrastive Assessment and Topology-Aware Skill Self-Evolution for LLM Agents

https://arxiv.org/abs/2606.13317

Kunfeng Chen, Qihuang Zhong, Juhua Liu, Bo Du | Wuhan University, Nanyang Technological University | arXiv:2606.13317 | 2026년 6월

---

1. 서론: 에이전트 스킬은 길어질수록 더 똑똑해지는가

LLM 에이전트가 파일 시스템, 스프레드시트, 문서 이미지, 웹 도구를 다루기 시작하면 모델 가중치 안에 들어 있는 일반 지식만으로는 충분하지 않다. 실제 작업은 대개 도구 호출 순서, 실패를 피하는 규칙, 특정 파일 형식의 관례, 평가기가 원하는 출력 형식 같은 절차적 지식을 요구한다. 그래서 최근 에이전트 연구와 제품에서는 외부 문서 형태의 skill, memory, routine, instruction bundle을 실행 시점에 주입하는 방식이 널리 쓰인다. 이 논문이 다루는 질문은 그 스킬 문서를 사람이 계속 써야 하느냐를 넘어, 에이전트의 실행 궤적 자체에서 재사용 가능한 스킬을 어떻게 안정적으로 뽑아낼 수 있느냐에 가깝다.

기존의 skill self-evolution 계열 방법은 에이전트가 어떤 작업을 시도한 뒤 남긴 trajectory를 읽고, 그 경험을 skill patch로 변환한 다음, 기존 skill 문서에 병합하는 흐름을 따른다. Trace2Skill류 방법은 이 과정을 offline batch pipeline으로 만들어, 한 trajectory에서 하나의 patch를 만들고 Map-Reduce식 병합으로 더 큰 skill 문서를 만든다. 이 접근은 모델을 다시 학습하지 않아도 스킬을 개선할 수 있다는 점에서 매력적이다. 그러나 논문은 이 단순한 추출-병합 루프가 실제로는 세 가지 병목을 갖는다고 본다: 한 번의 실행만 보고 원인을 추정하는 single-trace bias, 검증되지 않은 patch가 전체 skill에 섞이는 unvalidated merging, 길어진 skill 전체를 추론 때 모두 넣는 context overload가 그것이다.

SkillCAT은 이 세 병목을 각각 별도의 모듈로 분리한다. 첫째, Contrastive Causal Extraction(CCE)은 같은 작업을 여러 random seed로 실행해 성공 trace와 실패 trace가 동시에 있는 경우를 찾고, 같은 입력에서 결과가 갈라진 첫 지점을 causal watershed로 잡는다. 둘째, Assessment-Augmented Evolution(AAE)은 candidate patch를 바로 병합하지 않고 source-task clone에서 다시 실행해, patch가 실패를 성공으로 바꾸거나 적어도 성공을 유지하는지 확인한다. 셋째, Topology-Aware Task Execution(TTE)은 완성된 skill을 노드화한 뒤 test-time task에 필요한 부분만 라우팅해 주입한다. 제목의 CAT은 이 Contrastive, Assessment, Topology 세 단어를 묶은 이름이다.

이 논문이 흥미로운 이유는 스킬을 단순히 더 좋은 prompt로 보지 않고, 증거 수집, 편집 검증, 실행 시점 라우팅의 세 단계 lifecycle로 다룬다는 점이다. 사람이 읽기 좋은 skill 문서를 만드는 문제와 에이전트가 실제로 잘 쓰는 skill 문서를 만드는 문제는 다르다. SkillCAT은 후자를 겨냥한다. 성공한 trace를 요약하면 그럴듯한 규칙은 많이 나오지만, 그 규칙이 실패를 고치는지, 다른 성공 사례를 망치지 않는지, 특정 작업에 필요한 규칙만 골라 쓸 수 있는지는 별개의 문제다. 논문은 이 별개 문제들을 하나의 pipeline 안에서 측정 가능한 결정으로 바꾸려 한다.

Figure 1: Trace2Skill-style 방법의 세 가지 한계와 SkillCAT의 대응 모듈.

Figure 1은 논문의 문제 설정을 가장 압축적으로 보여 준다. 왼쪽의 single-trace bias는 한 번의 성공 또는 실패 trajectory만으로 원인 규칙을 추출할 때 생기는 증거 부족을 가리킨다. 가운데 unvalidated merging은 patch가 실제 task outcome을 개선하는지 확인하지 않은 채 skill 문서에 합쳐지는 위험이다. 오른쪽 context overload는 skill이 커질수록 추론 때 불필요한 규칙까지 함께 들어가 모델의 주의를 분산시키는 현상이다. SkillCAT은 각각을 CCE, AAE, TTE로 분리해 처리한다.

결과적으로 SkillCAT은 SpreadsheetBench-Verified에서 Qwen3.5-35B-A3B author/user 조건의 Skill Deepening 성능을 55.50%까지 올리고, Trace2Skill +Combined의 29.67%보다 25.83 percentage point 높게 만든다. 전체 평균 기준으로는 matched baseline 대비 최대 40.40% 개선을 보고한다. WikiTableQuestions로 옮긴 out-of-distribution table generalization, DocVQA의 multimodal transfer, gemma-4-31B-it과 gpt-5.4-mini를 user model로 둔 cross-model reuse에서도 일정한 이득이 관찰된다. 단순한 벤치마크 점수보다 중요한 것은 ablation에서 AAE를 제거하면 성능이 Trace2Skill 기준 아래로 떨어진다는 점이다. 이 결과는 skill patch의 품질 관리가 장식에 머물지 않고 필수 안전장치임을 보여 준다.

2. 배경 및 관련 연구: 스킬 문서, trajectory, context routing의 접점

2.1 에이전트 스킬 문서의 역할

에이전트 skill은 모델이 실행 중 참고하는 외부 절차 지식이다. 논문은 structured instructions, tool-use rules, task experience처럼 런타임 context에 넣을 수 있는 문서를 모두 넓은 의미의 skill로 본다. 이런 skill은 ReAct-style harness에서 특히 중요하다. 모델이 어떤 도구를 언제 호출할지, 중간 파일을 어떤 형식으로 저장할지, 오류가 나면 어떤 fallback을 시도할지 같은 결정은 일반 언어 능력보다 환경별 절차 지식에 더 민감하기 때문이다. 사람이 직접 작성한 skill은 신뢰성이 높을 수 있지만, 작업 도메인이 늘어나면 작성과 유지보수 비용이 빠르게 커진다.

Voyager, Reflexion, Self-Refine류 흐름은 실행 경험을 다시 사용 가능한 지식으로 바꾸는 초기 감각을 보여 줬다. 이후 Trace2Skill은 각 trajectory에서 patch를 뽑아 offline으로 병합하는 방식을 제안했고, SkillCAT은 이 baseline을 직접 비교 대상으로 삼는다. 중요한 차이는 SkillCAT이 하나의 trajectory를 하나의 사실처럼 취급하지 않는다는 점이다. 같은 task를 여러 seed로 실행하면 성공과 실패가 함께 나오는 경우가 생기고, 이때 입력과 목표가 같으므로 결과 차이를 만든 action divergence를 더 좁혀 볼 수 있다. 논문은 이 contrastive evidence가 단일 trace 요약보다 스킬 편집에 더 적합하다고 본다.

2.2 기존 self-evolution 루프의 취약점

기존 self-evolution 루프는 대체로 다음 순서를 따른다. 첫째, 에이전트가 task를 수행하며 trajectory를 남긴다. 둘째, extractor가 trajectory를 읽고 candidate skill patch를 만든다. 셋째, merger가 여러 patch를 하나의 skill 문서로 합친다. 넷째, 다음 task에서 업데이트된 skill을 context에 넣는다. 이 구조는 단순하고 반복 실행하기 쉽지만, patch의 근거와 효과가 서로 분리되지 않는다는 문제가 있다. 성공 trajectory에서 나온 규칙이 정말 성공 원인이었는지, 실패 trajectory에서 나온 반성문이 실제 복구에 도움이 되는지, 여러 patch가 충돌할 때 어느 규칙을 우선해야 하는지 명확하지 않다.

SkillCAT은 이 문제를 evidence extraction, patch validation, test-time deployment의 세 결정으로 다시 쪼갠다. 추출 단계에서는 같은 task의 성공/실패 pair를 사용해 원인 후보를 더 좁힌다. 검증 단계에서는 patch를 source-task clone에서 재실행해 outcome transition을 본다. 배포 단계에서는 전체 skill을 무조건 넣지 않고, skill 문서 내부 구조를 topology로 컴파일해 필요한 node만 선택한다. 이 분해 덕분에 각 모듈은 ablation으로 따로 측정될 수 있고, 실패가 어느 단계에서 생겼는지도 해석하기 쉬워진다.

기존 병목	문제의 원인	SkillCAT 대응	검증 신호
Single-Trace Bias	한 trajectory만으로 성공 또는 실패 원인을 추정	CCE가 same-task success/failure pair를 비교	seed 수 sweep과 w/o CCE ablation
Unvalidated Merging	patch를 source task에서 다시 확인하지 않음	AAE가 replay score로 patch를 thresholding	w/o AAE 성능 하락과 score calibration
Context Overload	커진 skill 전체를 inference prompt에 주입	TTE가 skill topology에서 task-relevant node만 선택	router budget별 성능과 token reduction

2.3 이전 위키 흐름과의 연결

이 논문은 기존 위키에서 다룬 Agent Skills 개념과 직접 이어진다. 그 페이지는 스킬을 instructions, references, scripts가 묶인 재사용 workflow 포맷으로 보며, description과 trigger contract가 호출 정확도를 좌우한다고 정리했다. SkillCAT은 그보다 한 단계 아래에서, 스킬 본문을 어떻게 업데이트해야 하는지를 다룬다. 즉 사람이 스킬 description을 잘 쓰는 문제와, 에이전트 trajectory에서 새 규칙을 뽑아 skill corpus를 진화시키는 문제를 연결한다.

또한 Agent Skill Repair Loop와도 맞닿아 있다. repair loop는 같은 설명을 두 번 반복하게 된 순간을 스킬 수정 신호로 본다. SkillCAT의 AAE는 이 운영 감각을 자동화된 실험 프로토콜로 옮긴 형태에 가깝다. patch가 좋아 보인다는 언어적 판단만으로 끝내지 않고, source-task clone에서 실제 outcome transition을 확인하기 때문이다. Skill-Conditioned Privileged Guidance 페이지와 비교하면, SkillCAT은 학습 중 teacher branch에 skill context를 주는 방식과 달리 모델 가중치 수정 없이 외부 skill 문서를 증거 기반으로 관리하는 방식이라는 차이가 있다.

3. 방법론: CCE, AAE, TTE로 나누는 스킬 생명주기

3.1 문제 정의와 전체 파이프라인

논문은 evolution task 집합을 $\mathcal{X}=\{x_1,\ldots,x_N\}$, random seed 집합을 $\mathcal{Z}=\{z_1,\ldots,z_K\}$로 둔다. base skill $S_0$가 있을 때 task $x_i$를 seed $z$로 실행하면 trajectory $\tau_{i,z}$와 evaluator outcome $y_{i,z}\in\{0,1\}$가 나온다. 여기서 outcome은 이론적 reward 대신 official evaluator가 판정한 성공/실패다. Skill self-evolution의 입력은 $S_0$와 multi-seed trace collection $\mathcal{T}$이고, 출력은 개선된 skill $S^*$와 각 test-time task에 맞춰 조립되는 routed skill $S_c$다.

이 정의에서 중요한 부분은 목표가 단순히 더 긴 skill 문서를 쓰는 데 그치지 않는다는 점이다. 논문은 unseen task 성능을 올리는 동시에, task마다 context에 주입되는 skill content의 양을 제한해야 한다고 둔다. 따라서 pipeline은 세 질문에 답해야 한다. 어떤 trajectory evidence를 믿을 것인가, 어떤 patch를 global skill에 넣을 것인가, test-time에는 어느 skill node를 불러올 것인가. CCE, AAE, TTE는 각각 이 질문 하나씩을 맡는다.

Figure 2: CCE, AAE, TTE로 이어지는 SkillCAT 전체 파이프라인.

Figure 2는 SkillCAT이 offline evolution과 online execution을 분리한다는 점을 보여 준다. CCE와 AAE는 skill을 학습하는 오프라인 단계에서 동작하며, multi-seed trajectory에서 contrastive record를 만들고 candidate patch를 검증한 뒤 tiered merge로 skill을 갱신한다. TTE는 갱신된 skill을 section-level topology로 컴파일해 두었다가, 실제 task context가 들어오면 LLM router와 deterministic expansion으로 관련 node를 고른다. 그림의 흐름은 skill 문서가 생성물인 동시에 런타임 검색 대상이라는 이중 역할을 명확히 한다.

3.2 Contrastive Causal Extraction: 같은 task 안에서 성공과 실패를 맞붙이기

CCE는 같은 task에 대해 여러 seed로 실행한 trajectory 중 성공 집합 $\mathcal{T}_i^+$와 실패 집합 $\mathcal{T}_i^-$가 모두 존재할 때 contrastive pair $(\tau_i^+,\tau_i^-)$를 만든다. 이 pair는 입력 task, 도구 환경, evaluator가 동일하므로, task 난이도 차이나 데이터 차이가 결과 차이로 오해될 위험을 줄인다. 논문은 성공 trace와 실패 trace의 action sequence가 처음으로 달라지는 지점 $w_i$를 causal watershed로 부르고, 그 주변 evidence에서 candidate experience record $r_i=E(\tau_i^+,\tau_i^-,w_i)$를 추출한다.

이 설계는 trajectory 전체를 요약하는 방식과 다르다. 전체 trace summarization은 긴 실행 로그에서 눈에 띄는 사실을 많이 모을 수 있지만, 어떤 사실이 outcome 차이를 만든 원인 후보인지 분리하기 어렵다. CCE는 처음 달라진 action 근처를 보며, 성공 쪽이 어떤 판단을 했고 실패 쪽이 어떤 선택을 했는지 비교한다. 예를 들어 스프레드시트 task에서 성공 trace가 날짜 열을 먼저 정규화하고 실패 trace가 곧바로 aggregation을 실행했다면, patch는 “날짜-like 열을 계산 전에 canonical format으로 맞춰라” 같은 skill-editable lesson으로 좁혀질 수 있다.

모든 seed가 성공하거나 모두 실패하면 엄격한 success/failure pair가 생기지 않는다. 논문은 fallback이 켜져 있으면 single-trace extractor $E_1$을 사용하고, 그렇지 않으면 해당 task를 건너뛴다. 이 fallback은 현실적인 타협이다. 완전한 contrastive evidence만 허용하면 쉬운 task와 어려운 task가 모두 누락될 수 있고, 반대로 fallback을 너무 많이 쓰면 CCE의 장점이 약해진다. 실험에서 seed 수를 1, 3, 5, 7, 9로 바꿔 본 이유도 이 균형 때문이다.

3.3 Assessment-Augmented Evolution: patch를 병합하기 전에 다시 실행하기

AAE는 candidate patch를 곧바로 global skill에 넣지 않는다. 각 patch $p_j$에 대해 해당 evidence와 연결된 source-task clone set $\mathcal{X}_j$를 만들고, patch를 임시 skill처럼 적용한 뒤 replay outcome을 측정한다. baseline outcome을 $y_j$, replay outcome을 $\hat{y}_j$로 두면, AAE score는 네 가지 transition에 따라 정해진다. 실패가 성공으로 바뀌는 $(0,1)$은 3.0, 성공이 유지되는 $(1,1)$은 2.0, 실패가 그대로인 $(0,0)$은 1.0, 성공이 실패로 바뀌는 $(1,0)$은 0.0이다.

논문은 threshold를 $\theta=2.0$으로 둔다. 따라서 선택되는 patch 집합 $\mathcal{P}_\theta=\{p_j:a_j\geq\theta\}$에는 실패를 고치거나 기존 성공을 보존하는 patch만 들어간다. 특히 CCE pair에서 나온 patch는 성공 쪽 trajectory를 baseline state로 삼아 보수적으로 평가한다. replay가 성공하면 success-to-success로 받아들이고, replay가 실패하면 success-to-failure로 버린다. 이 규칙은 contrastive evidence가 그럴듯하더라도 이미 관찰된 성공 동작을 망치는 patch라면 skill corpus에 넣지 않겠다는 선언이다.

AAE의 merge는 점수 tier별로 진행된다. 선택된 patch를 score tier로 묶고, 낮은 tier에서 높은 tier로 순차 병합해 최종 skill $S^*$를 만든다. 병합 연산 자체는 Trace2Skill의 skill-editing procedure를 재사용하지만, 무엇을 넣을지와 어떤 순서로 넣을지가 바뀐다. 이 때문에 AAE는 별도의 모델 학습이나 reward model을 요구하지 않는다. 비용은 source-task replay에서 발생하지만, 그 대가로 harmful patch가 global skill에 들어가는 경로를 줄인다.

Outcome transition	AAE score	해석	선택 여부($\theta=2.0$)
Failure → Success	3.0	source task 실패를 직접 복구한 가장 강한 증거	선택
Success → Success	2.0	기존 성공을 망치지 않는 보존 증거	선택
Failure → Failure	1.0	문제를 고치지 못했으므로 global merge에는 약함	제외
Success → Failure	0.0	성공 동작을 깨뜨린 harmful patch	제외

3.4 Topology-Aware Task Execution: 커진 skill을 모두 넣지 않기

TTE는 final skill $S^*$를 추론 때 그대로 통째로 넣지 않는다. 오프라인 compiler가 Markdown hierarchy를 읽어 level-1 content를 항상 켜지는 core skill $S_\circ$로 두고, level-2 section을 routable node set $\mathcal{V}$로 만든다. 각 node는 원문 body $B_v$와 함께 title, keywords, summary, dependency 같은 routing metadata를 갖는다. metadata들의 요약이 topology summary $\Sigma$가 되고, router는 이 압축된 summary만 보고 관련 node를 고른다.

test-time task context $c$가 들어오면 LLM router $\rho(c,\Sigma;k)$가 최대 $k$개의 primary node를 선택한다. 이 raw selection은 runtime validation을 거친 뒤 dependency expansion, deterministic recall, foundational-node injection을 통해 최종 node set $\mathcal{V}_c$가 된다. routed skill은 $S_c=S_\circ\oplus\bigoplus_{v\in\mathcal{V}_c}B_v$처럼 core와 선택 node body를 이어 붙인 문자열이다. TTE는 skill 문장을 다시 생성하지 않으므로 AAE가 만든 규칙을 보존하고, 어떤 규칙을 보여 줄지만 제어한다.

이 부분은 RAG retrieval과 비슷해 보이지만, 논문은 skill 문서의 topology를 명시적으로 활용한다. 일반 embedding retrieval은 task query와 section text의 유사도만 볼 수 있지만, TTE는 section이 어떤 capability node인지, 어떤 dependency를 갖는지, foundational node를 함께 넣어야 하는지를 runtime rule로 처리한다. 이 차이는 context reduction만이 아니라 skill corpus 내부의 구조적 안정성과 관련된다. 잘못된 node만 고르면 성능이 떨어질 수 있으므로, 논문은 LLM graph router와 embedding router를 비교해 budget별 trade-off를 따로 보고한다.

4. 실험 설정: 스프레드시트, 표 질의, 문서 VQA로 보는 검증 범위

4.1 데이터셋 및 벤치마크

주요 벤치마크는 SpreadsheetBench-Verified다. 논문은 Trace2Skill 설정을 따라 400개 샘플을 200개 evolution sample과 200개 held-out test sample로 나누고, test sample은 skill evolution에 사용하지 않는다. primary metric인 Vrf는 held-out split에서의 accuracy다. full SpreadsheetBench에서는 Soft와 Hard를 함께 보고한다. Soft는 sub-problem pass rate이고, Hard는 모든 sub-problem을 맞히는 stricter metric이다. 스프레드시트 task는 도구 호출, 셀 범위 해석, 데이터 정규화, multi-step 계산이 섞여 있으므로 skill 문서의 절차 지식이 잘 드러나는 도메인이다.

out-of-distribution generalization은 WikiTableQuestions(WikiTQ)로 평가한다. WikiTQ 입력과 expected output을 spreadsheet format으로 변환해 같은 xlsx skill을 사용할 수 있게 만든다. 이 설정은 SkillCAT이 단지 SpreadsheetBench train-like task에 과적합한 문장을 만든 것인지, 아니면 table reasoning과 spreadsheet operation에 재사용 가능한 skill을 만들었는지 보는 장치다. multimodal transfer는 DocVQA validation split으로 본다. 첫 2,700개 question-image pair를 evolution에 쓰고, 남은 2,649개를 평가에 사용하며, 지표는 ANLS와 ANLS 0.5 이상 기준 Acc다.

4.2 비교 방법과 모델

비교 대상은 No Skill, Human-Written, Parametric, Trace2Skill +Combined, Trace2Skill +Error다. Human-Written은 Anthropic의 official xlsx skill이고, Parametric은 prompt-generated xlsx-basic skill이다. 논문은 두 가지 setting을 구분한다. Skill Deepening은 이미 사람이 쓴 xlsx skill에서 시작해 더 깊게 개선하는 설정이고, Skill Creation은 약한 xlsx-basic skill에서 시작해 skill을 새로 만들어 가는 설정이다. 이 구분은 실제 운영에서도 중요하다. 이미 좋은 운영 문서가 있는 팀과, 아직 초안 수준의 rule만 있는 팀은 skill self-evolution에서 기대할 수 있는 이득과 위험이 다르다.

main experiment의 matched author/user model은 Qwen3.5-35B-A3B와 Qwen3.5-122B-A10B다. cross-model analysis에서는 Qwen으로 만든 Deepening skill을 gemma-4-31B-it과 gpt-5.4-mini user에게 재사용한다. 이 설정은 skill 문서가 특정 author model의 문체나 reasoning habit에만 맞는지, 다른 model family가 읽어도 도움이 되는지 확인한다. 모델 가중치를 바꾸지 않는 training-free 방법이라면 이런 reuse 가능성은 특히 중요하다. skill이 진짜 절차 지식이라면, 작성 모델이 달라도 일정 수준의 transfer가 가능해야 한다.

4.3 구현 세부사항

모든 agent는 ReAct-style harness에서 실행되며 filesystem과 spreadsheet tools를 사용한다. CCE는 evolution task마다 5개 trajectory seed를 샘플링하고, 128개 parallel inference worker로 success/failure evidence를 수집한다. AAE는 candidate patch를 source-task clone에서 평가하고, $a_j\geq2.0$인 patch만 hierarchical merge에 넘긴다. 최종 TTE 설정은 prompt-based llm_graph_router와 $top\_k=7$을 사용하며, runtime node validation, dependency expansion, foundational-node injection을 수행한다. 논문은 router가 단순 token 절감 장치를 넘어 skill node selection의 품질을 좌우하는 test-time module이라고 본다.

항목	논문 설정	해석 포인트
SpreadsheetBench-Verified	400 samples = 200 evolution + 200 held-out test	skill evolution과 평가를 분리해 overfit 위험을 낮춤
WikiTableQuestions	spreadsheet format으로 변환해 같은 xlsx skill 사용	table reasoning의 OOD 전이를 확인
DocVQA	2,700 evolution, 2,649 evaluation, ANLS/Acc 보고	문서 이미지 질의로 multimodal skill transfer를 확인
CCE budget	5 trajectory seeds, 128 parallel inference workers	evidence 다양성과 sampling cost의 균형
AAE threshold	$a_j\geq2.0$	실패 복구 또는 성공 보존 patch만 병합
TTE router	llm_graph_router, $top\_k=7$	성능을 유지하면서 context를 줄이는 선택

구현 측면에서 SkillCAT의 비용은 주로 두 군데서 발생한다. CCE는 multi-seed trajectory collection이 필요하고, AAE는 patch replay를 요구한다. 대신 모델을 fine-tune하지 않으며, final inference에서는 TTE가 context 길이를 줄인다. 따라서 전체 cost profile은 “offline evidence/replay 비용을 더 내고 online prompt 비용과 harmful patch 위험을 낮추는” 구조다. 실제 배포 관점에서는 skill corpus를 자주 업데이트하는지, task당 inference volume이 큰지, replay 가능한 evaluator가 있는지가 도입 가능성을 좌우한다.

5. 주요 실험 결과: SkillCAT은 어디서 얼마나 좋아지는가

5.1 SpreadsheetBench와 WikiTQ 메인 결과

Table 1의 핵심은 Qwen3.5-35B-A3B 조건에서 가장 선명하다. Skill Deepening에서 Human-Written은 Vrf 9.67%, Trace2Skill +Combined는 29.67%이고, SkillCAT은 55.50%를 기록한다. Soft는 13.03%에서 18.80%를 거쳐 39.02%로 올라가고, Hard는 3.37%에서 5.73%를 거쳐 20.61%가 된다. WikiTQ에서는 Human-Written 9.02%, Trace2Skill 51.22%, SkillCAT 81.55%다. 평균은 8.77%에서 26.36%를 거쳐 49.17%로 올라간다. 단순 held-out accuracy와 OOD table generalization에서도 큰 차이가 난다.

Skill Creation에서도 차이가 크다. Qwen3.5-35B-A3B에서 Parametric은 평균 14.47%, Trace2Skill은 20.34%, SkillCAT은 46.52%다. Vrf만 보면 Parametric 20.17%, Trace2Skill 20.00%, SkillCAT 54.50%로, Trace2Skill은 거의 개선하지 못하지만 SkillCAT은 34.33 point를 얻는다. Qwen3.5-122B-A10B에서도 비슷한 흐름이 나온다. Deepening에서는 Trace2Skill이 Vrf 69.83%로 SkillCAT 69.50%보다 0.33 point 높지만, Soft, Hard, WikiTQ, 평균에서는 SkillCAT이 앞선다. Creation에서는 Parametric 26.17% Vrf에서 SkillCAT 64.50%로 올라간다.

Author/User	Setting	Method	Vrf	Soft	Hard	WikiTQ	Avg
Qwen3.5-35B-A3B	Deepening	Human-Written	9.67	13.03	3.37	9.02	8.77
Qwen3.5-35B-A3B	Deepening	Trace2Skill +Comb.	29.67	18.80	5.73	51.22	26.36
Qwen3.5-35B-A3B	Deepening	SkillCAT	55.50	39.02	20.61	81.55	49.17
Qwen3.5-35B-A3B	Creation	Parametric	20.17	13.70	3.87	20.14	14.47
Qwen3.5-35B-A3B	Creation	SkillCAT	54.50	39.35	19.41	72.82	46.52
Qwen3.5-122B-A10B	Deepening	Trace2Skill +Comb.	69.83	47.17	29.53	79.24	56.44
Qwen3.5-122B-A10B	Deepening	SkillCAT	69.50	47.42	31.91	84.47	58.32

이 표에서 특히 눈에 띄는 부분은 Hard metric이다. 스프레드시트 작업에서 Hard는 모든 sub-problem을 통과해야 하므로, skill이 일부 절차만 개선해서는 크게 오르기 어렵다. Qwen3.5-35B-A3B Deepening에서 Hard가 5.73에서 20.61로 오른 것은 patch가 단순 힌트 수준을 넘어 multi-step 계산 과정의 실패를 줄였다는 신호로 볼 수 있다. WikiTQ의 큰 상승은 skill이 특정 benchmark 문장에만 맞춘 수준을 넘어 table-to-spreadsheet 변환 이후에도 적용 가능한 절차 규칙을 담았음을 시사한다.

5.2 Cross-model reuse 결과

cross-model block은 evolved skill이 작성 모델 밖에서도 읽히는지 확인한다. Qwen3.5-35B-A3B가 작성한 Deepening skill을 gemma-4-31B-it에게 주면 Vrf가 Human-Written 39.00%에서 SkillCAT 61.00%로 오른다. 같은 skill을 gpt-5.4-mini에게 주면 31.00%에서 37.00%로 오른다. Qwen3.5-122B-A10B가 작성한 skill은 gemma-4-31B-it에서 70.50% Vrf를 기록하고, gpt-5.4-mini에서는 32.50%다. 이득의 크기는 user model마다 다르지만, skill이 특정 author model의 private reasoning shortcut만 담았다는 쪽보다 더 넓은 방향의 근거를 제공한다.

Skill author	User model	Baseline	Baseline Vrf	SkillCAT Vrf	Avg
Qwen3.5-35B-A3B	gemma-4-31B-it	Human-Written	39.00	61.00	53.23
Qwen3.5-35B-A3B	gpt-5.4-mini	Human-Written	31.00	37.00	33.52
Qwen3.5-122B-A10B	gemma-4-31B-it	Human-Written	39.00	70.50	55.88
Qwen3.5-122B-A10B	gpt-5.4-mini	Human-Written	31.00	32.50	33.06

다만 cross-model reuse 결과는 SkillCAT이 모든 모델에 같은 폭으로 이득을 준다는 주장은 아니다. gemma-4-31B-it에서는 큰 폭의 Vrf 상승이 나오지만, gpt-5.4-mini에서는 개선 폭이 작다. 이는 skill 문서가 task-specific procedure를 담더라도 user model의 tool-use 안정성, instruction following, spreadsheet operation 이해도에 따라 효과가 제한될 수 있음을 뜻한다. 운영적으로는 skill library를 하나만 만들고 끝내기보다, user model별로 routing budget, node granularity, patch wording을 점검할 필요가 있다.

5.3 DocVQA multimodal transfer

Figure 3: DocVQA에서 SkillCAT, Trace2Skill, No Skill을 비교한 multimodal evaluation.

Figure 3은 Qwen3.5-35B-A3B가 작성한 skill을 두 user model에 적용한 DocVQA 결과다. SkillCAT Full은 Qwen3.5-35B-A3B user에서 ANLS 0.9159와 Acc 93.3%를 얻고, Qwen3.5-122B-A10B user에서도 ANLS 0.7200과 Acc 79.0%를 기록한다. 반대로 Trace2Skill +Error는 Qwen3.5-35B-A3B에서 No Skill보다 낮은 0.6223 ANLS로 떨어진다. 이 그림은 검증 없는 오류 patch가 다른 도메인으로 전이될 때 실제 성능을 해칠 수 있음을 보여 준다.

User model	비교점	ANLS	Acc	논문 해석
Qwen3.5-35B-A3B	No Skill baseline	0.6843	75.2%	SkillCAT 대비 낮은 기준점
Qwen3.5-35B-A3B	SkillCAT Full	0.9159	93.3%	ANLS +0.2316, Acc +18.1
Qwen3.5-35B-A3B	Trace2Skill +Error	0.6223	논문 Figure 참조	No Skill보다 낮아 harmful patch 위험을 시사
Qwen3.5-122B-A10B	No Skill baseline	0.6424	71.2%	SkillCAT 대비 낮은 기준점
Qwen3.5-122B-A10B	SkillCAT Full	0.7200	79.0%	ANLS +0.0776, Acc +7.8

DocVQA 결과는 SkillCAT이 스프레드시트 전용 트릭을 넘어선 절차 지식을 학습했다는 보조 증거다. 문서 이미지를 읽는 multimodal setting에서도 skill patch가 도움이 되려면, “어떤 정보를 먼저 찾고, 어떤 중간 값을 확인하고, 어떤 답변 형식으로 정리할지” 같은 절차가 다른 입력 modality에도 적용되어야 한다. 동시에 Trace2Skill +Error의 하락은 skill self-evolution에서 bad-case diagnosis를 제대로 관리하지 않으면, skill 문서가 모델에게 잘못된 행동 습관을 가르칠 수 있음을 경고한다.

6. 추가 분석 및 Ablation Study: 세 모듈은 각각 무엇을 막는가

6.1 모듈 제거 실험

ablation은 Qwen3.5-35B-A3B Skill Deepening 조건에서 진행된다. 기준 Trace2Skill +Combined는 29.67% Vrf이고, SkillCAT Full은 55.50%다. CCE를 제거하면 32.50%로 떨어진다. 이는 same-task contrastive evidence 없이 patch를 만들면 Trace2Skill보다는 약간 낫지만, full pipeline의 큰 이득은 사라진다는 뜻이다. AAE를 제거하면 26.00%로 기준보다 낮아진다. 이 결과가 논문의 가장 중요한 안전 신호다. 검증 없이 contrastive patch를 병합하면 오히려 해로운 규칙이 skill에 들어갈 수 있다. TTE를 제거하면 46.50%로, 좋은 skill을 만들었더라도 test-time context selection이 성능을 추가로 끌어올린다는 것을 보여 준다.

Condition	CCE	AAE	TTE	Vrf	핵심 해석
Trace2Skill +Comb.	✗	✗	✗	29.67	기준 baseline
SkillCAT Full	✓	✓	✓	55.50	세 모듈 결합의 최종 성능
w/o CCE	✗	✓	✓	32.50	단일 trace evidence의 한계
w/o AAE	✓	✗	✓	26.00	검증 없는 patch가 harmful해질 수 있음
w/o TTE	✓	✓	✗	46.50	좋은 skill도 routing이 없으면 context 비용과 간섭이 남음
Only CCE	✓	✗	✗	39.00	좋은 evidence만으로도 일부 개선
Only AAE	✗	✓	✗	34.00	검증만으로도 noise를 줄이나 evidence 품질이 제한
Only TTE	✗	✗	✓	27.50	routing만으로는 낮은 품질 skill을 보완하기 어려움

Only CCE가 39.00%, Only AAE가 34.00%, Only TTE가 27.50%라는 점도 중요하다. CCE와 AAE는 각각 일부 이득을 만들지만, routing만 켠다고 낮은 품질의 skill corpus가 좋아지지는 않는다. 반대로 w/o TTE가 46.50%로 꽤 높다는 것은 evidence extraction과 validation이 성능의 주된 기반임을 말한다. TTE는 나쁜 skill을 구원하는 장치라기보다, 이미 좋아진 skill을 task에 맞춰 덜 방해받게 쓰는 장치다.

6.2 CCE evidence budget

Figure 4: CCE seed 수에 따른 held-out Vrf와 sampling time.

Figure 4는 seed 수를 늘릴수록 항상 좋아지지는 않는다는 점을 보여 준다. 한 seed에서는 Vrf 32.50%이고 sampling time은 22분 56초다. 다섯 seed에서는 55.50%로 가장 높지만, 일곱 seed와 아홉 seed에서는 각각 46.00%, 41.50%로 내려간다. 동시에 시간 비용은 seed 수와 함께 증가해 아홉 seed에서 4시간 41분 49초까지 늘어난다. 논문은 이 sweep을 바탕으로 다섯 seed를 accuracy-cost trade-off가 가장 좋은 설정으로 사용한다.

이 결과는 CCE의 contrastive evidence가 “많을수록 좋다”보다 “적절히 다양해야 한다”에 가깝다는 점을 시사한다. seed가 너무 적으면 성공/실패 pair를 만들 기회가 부족하고, seed가 너무 많으면 noisy divergence나 task-specific accident가 더 많이 들어올 수 있다. 또한 sampling 시간이 길어지면 offline evolution 주기가 느려진다. 따라서 실무 적용에서는 fixed seed count 하나를 모든 도메인에 적용하기보다, mixed-outcome task 비율과 patch replay 비용을 함께 측정해 budget을 조절하는 편이 합리적이다.

6.3 AAE score calibration

Figure 5: AAE assessment score bucket별 downstream Vrf와 Trace2Skill 기준선.

Figure 5는 197개 candidate patch를 replay outcome transition bucket으로 나누고, 각 bucket만 사용했을 때의 Vrf를 비교한다. failure-to-success patch는 51.00%로 Trace2Skill 기준 29.67%보다 21.33 point 높고, success-to-success는 41.00%로 11.33 point 높다. failure-to-failure는 32.00%로 약한 개선에 그치며, success-to-failure는 23.50%로 기준보다 6.17 point 낮다. AAE score 순서가 downstream 성능 순서와 단조롭게 맞아, replay transition이 단순 sanity check를 넘어 유용한 품질 신호임을 보여 준다.

이 calibration은 SkillCAT에서 AAE가 왜 hard gate인지 설명한다. patch 문장만 보면 failure-to-failure와 success-to-failure도 설득력 있어 보일 수 있다. 실패 로그에서 나온 반성문은 특히 사람이 읽기에 그럴듯하다. 그러나 replay가 성공을 깨뜨리거나 실패를 고치지 못한다면 global skill에 넣을 이유가 약하다. 논문은 language-level plausibility보다 evaluator-backed outcome transition을 우선시하고, 이 선택이 DocVQA에서 Trace2Skill +Error가 보인 하락을 피하는 데도 연결된다고 해석한다.

6.4 TTE routing efficiency

Figure 6: TTE router별 Vrf와 context reduction 비교.

Figure 6은 full skill loading without TTE의 Vrf 46.50%를 dashed line으로 두고, router와 budget을 바꿨을 때 성능과 context reduction을 비교한다. embedding retrieval은 $top\_k=3$에서 57.00%로 peak를 보이고, 논문이 선택한 LLM graph router는 $top\_k=7$에서 55.50%와 41.6% context reduction을 동시에 달성한다. 논문은 별도 embedding model 없이 topology dependency를 활용할 수 있고, 성능도 경쟁적인 LLM graph router를 최종 설정으로 채택한다.

분석 축	관찰값	논문이 내리는 의미
CCE seed budget	1 seed 32.50%, 5 seeds 55.50%, 7 seeds 46.00%, 9 seeds 41.50%	다섯 seed가 정확도와 sampling cost의 균형점
AAE calibration	failure→success 51.00%, success→success 41.00%, failure→failure 32.00%, success→failure 23.50%	replay outcome transition이 downstream patch utility와 정렬
TTE routing	LLM graph router top_k=7: 55.50% Vrf, 41.6% context reduction	전체 skill을 싣지 않고도 성능을 유지하거나 개선

TTE 결과에서 눈여겨볼 점은 context reduction과 성능이 trade-off만 이루지 않는다는 점이다. 관련 없는 skill node를 빼면 prompt가 짧아지고, 모델이 충돌하거나 불필요한 규칙에 주의를 빼앗길 가능성도 줄어든다. 따라서 routing은 비용 최적화인 동시에 instruction interference를 줄이는 품질 제어로 읽을 수 있다. 다만 router가 선택한 node가 잘못되면 필요한 규칙을 잃을 수 있으므로, topology summary와 dependency expansion의 품질은 실제 배포에서 계속 점검해야 한다.

3.5 Algorithm 1을 실행 단위로 풀어 읽기

Algorithm 1은 SkillCAT을 세 stage의 선언으로만 제시하지 않고, 실제 loop가 어디서 비용을 쓰는지 드러낸다. Stage 1에서는 각 evolution task $x_i$마다 모든 seed $z\in\mathcal{Z}$를 실행해 $\mathcal{T}_i$를 만든다. 여기서 mixed outcome이 관찰되면 성공 trace와 실패 trace 하나씩을 골라 action divergence $w_i$를 찾고, extractor $E$가 record를 쓴다. 이 기록은 단순 로그 요약을 넘어 patch로 바뀔 수 있는 failure cause, local evidence, editable lesson을 담는 중간 산출물이다. 따라서 CCE의 품질은 trajectory 수와 extractor가 watershed 주변 문맥을 얼마나 잘 잘라 내는지에 좌우된다.

Stage 2는 record set $\mathcal{R}$을 patch set $\{p_j\}_{j=1}^M$로 바꾼 뒤, 각 patch를 독립 hypothesis처럼 다룬다. 여기서 핵심은 patch가 global merge 전에 temporary skill로 격리된다는 점이다. 격리된 patch는 source-task clone에서 baseline outcome과 replay outcome을 만든다. 이 replay가 있기 때문에 patch selection은 language-model judge의 선호 대신 실제 evaluator transition에 기반한다. 그 다음에야 $\mathcal{P}_\theta$가 만들어지고, tiered merge가 낮은 score tier부터 높은 score tier로 진행된다. 이 순서는 고득점 patch가 마지막 병합 단계에서 더 강한 우선권을 갖도록 설계된 것으로 읽을 수 있다.

Stage 3는 앞의 두 stage와 달리 online loop다. final skill을 topology로 compile하는 일은 offline에 가깝지만, task context $c$가 들어올 때마다 router가 $\widetilde{\mathcal{V}}_c$를 고르고 runtime expansion이 $\mathcal{V}_c$를 확정한다. 이때 LLM router의 출력은 그대로 신뢰되지 않는다. node identifier 검증, dependency expansion, deterministic recall이 뒤따른다. 이런 보정은 에이전트 시스템에서 자주 필요한 패턴이다. LLM에게 선택을 맡기되, 선택 가능한 표면과 최종 조립 규칙은 deterministic layer가 통제한다. SkillCAT이 training-free임에도 안정성을 주장할 수 있는 이유는 이 경계가 비교적 명확하기 때문이다.

Algorithm 1의 실행 관점에서 보면 SkillCAT은 세 종류의 cache를 필요로 한다. 첫째, trajectory cache는 seed별 실행 로그와 outcome을 보존해야 한다. 둘째, replay cache는 patch별 source-task clone 결과와 score를 남겨야 한다. 셋째, topology cache는 node body와 metadata, dependency expansion 결과를 관리해야 한다. 논문은 benchmark 실험 위주로 설명하지만, 실제 시스템에서는 이 cache들이 audit trail이 된다. 어떤 skill node가 왜 들어왔는지, 어느 task에서 검증됐는지, 어떤 router 선택으로 prompt에 들어갔는지 추적할 수 있어야 나중에 실패를 다시 SkillCAT loop 안으로 돌려보낼 수 있다.

4.4 평가 프로토콜에서 봐야 할 세부 지점

SpreadsheetBench 결과를 읽을 때 Vrf, Soft, Hard를 따로 보는 이유는 세 지표가 다른 실패 층위를 가리키기 때문이다. Vrf는 held-out verified split에서 최종 정답을 맞혔는지 보는 지표다. Soft는 full benchmark에서 sub-problem 단위 통과율을 보므로, 에이전트가 중간 계산 일부를 맞혔지만 끝까지 조립하지 못한 경우에도 신호가 남는다. Hard는 모든 sub-problem을 통과해야 올라가므로, 장기 작업에서 작은 절차 오류가 누적되는 문제를 더 엄격하게 잡는다. SkillCAT이 Soft와 Hard를 동시에 올린다는 점은 patch가 단일 출력 형식 보정을 넘어 실행 과정 전반에 영향을 줬다는 해석을 가능하게 한다.

Skill Deepening과 Skill Creation의 차이도 결과 해석에 중요하다. Deepening은 이미 품질이 어느 정도 있는 Human-Written xlsx skill을 출발점으로 삼는다. 여기서의 개선은 기존 규칙에 새로운 예외 처리와 실행 요령을 더하는 성격이 강하다. Creation은 weaker Parametric xlsx-basic skill에서 시작하므로, 더 기본적인 절차를 학습해야 한다. Qwen3.5-35B-A3B Creation에서 Trace2Skill이 Vrf를 거의 올리지 못하고 SkillCAT이 54.50%까지 올라간 결과는, 약한 initial skill일수록 단일 trace 병합보다 검증된 patch selection의 차이가 커질 수 있음을 보여 준다.

WikiTQ 전환은 spreadsheet operation 자체와 table question answering이 어느 정도 공통 절차를 공유하는지 보는 장치다. WikiTQ 입력은 원래 일반 table QA 형식이지만, 논문은 이를 spreadsheet format으로 바꿔 같은 xlsx skill을 적용한다. 이 설정에서 SkillCAT이 높은 성능을 보인다면 skill 문서가 “SpreadsheetBench의 특정 셀 패턴”에만 맞춰진 수준을 넘어, 표를 파일로 열고 필요한 열을 찾고 값 변환을 수행하고 답을 검증하는 일반 절차를 담았다는 쪽으로 해석할 수 있다. 반대로 WikiTQ가 낮았다면 benchmark-specific overfitting 가능성이 커졌을 것이다.

DocVQA는 또 다른 의미의 stress test다. 문서 이미지는 OCR, 시각적 위치, 질문-근거 연결이 섞인다. spreadsheet skill과 완전히 같은 도메인은 아니지만, 문서에서 필요한 정보를 단계적으로 찾고 중간 결과를 확인하는 skill은 여전히 도움을 줄 수 있다. 여기서 SkillCAT Full이 No Skill보다 높고 Trace2Skill +Error가 낮아지는 패턴은, 좋은 patch는 modality가 바뀌어도 절차 지식으로 전이될 수 있지만, 잘못된 patch는 더 넓은 환경에서 손상을 키울 수 있다는 점을 보여 준다. 이 결과는 AAE의 replay 기반 filtering이 단지 spreadsheet 내부 성능을 위한 장치가 아님을 보강한다.

5.4 수치 결과를 운영 기준으로 번역하기

SkillCAT의 40.40% 평균 개선은 headline으로 읽기 쉽지만, 운영 기준으로는 몇 가지 질문으로 나눠야 한다. 첫째, 어떤 skill starting point에서 이득이 큰가. Creation setting의 큰 폭 개선은 약한 skill을 가진 조직에 유용할 수 있지만, Human-Written skill이 이미 강한 도메인에서는 이득이 줄어들 수 있다. 둘째, 어떤 user model에서 skill reuse가 잘 되는가. gemma-4-31B-it은 큰 폭으로 오르지만 gpt-5.4-mini의 개선은 작다. 셋째, token reduction이 latency와 비용을 얼마나 줄이는가. TTE는 41.6% context reduction을 보고하지만, router 호출과 dependency expansion 비용까지 합친 end-to-end cost는 별도로 계산해야 한다.

또 하나의 운영 기준은 regression risk다. w/o AAE가 26.00%로 Trace2Skill 기준보다 낮아진다는 사실은, 스킬 자동 진화가 기본적으로 위험한 업데이트 경로라는 뜻이다. 사람이 보기에는 patch가 더 상세하고 친절해 보여도, 실제 executor에게는 잘못된 우선순위나 과도한 예외 처리가 될 수 있다. 따라서 SkillCAT의 성능 이득을 재현하려면 CCE만 구현해서는 부족하다. candidate patch가 기존 성공을 망치지 않는지 보는 regression suite가 필요하고, success-to-failure 사례는 skill 문서에 병합하지 말고 별도 triage queue에 남기는 편이 안전하다.

실제 제품 에이전트에 적용한다면, Vrf 하나에 대응하는 지표를 여러 층으로 나눌 수 있다. 최종 task success, user correction count, tool error rate, repeated instruction count, context token budget, manual rollback count가 모두 skill update의 품질 신호가 된다. AAE score의 네 transition을 이 다중 지표로 확장하면 patch별로 “정답률은 높였지만 tool error를 늘린 규칙”, “latency를 줄였지만 user correction을 늘린 규칙”을 구분할 수 있다. 논문은 binary evaluator로 깔끔하게 시작하지만, 운영 적용은 이런 다목적 평가표로 확장될 때 더 강해진다.

6.5 로그와 provenance를 이용한 운영 진단

SkillCAT을 장기 운영한다면 세 모듈의 로그를 서로 연결해야 한다. CCE 로그에는 task id, seed, success/failure pair, watershed step, extractor가 인용한 local evidence가 남아야 한다. AAE 로그에는 patch id, source-task clone id, baseline outcome, replay outcome, score, threshold 통과 여부가 남아야 한다. TTE 로그에는 task context summary, router가 선택한 primary node, expansion으로 추가된 dependency node, 최종 prompt token count가 남아야 한다. 이 세 로그가 이어져야 “이 task에서 왜 이 skill 문장이 들어갔는가”라는 질문에 답할 수 있다.

provenance가 없으면 skill self-evolution은 금방 black box가 된다. 어떤 문장이 여러 patch merge를 거쳐 final skill에 들어갔는지 알 수 없고, 실패가 발생했을 때 해당 문장을 제거해야 하는지, router가 잘못 골랐는지, evaluator가 바뀐 것인지 분리하기 어렵다. 반대로 provenance가 있으면 rollback도 node 단위로 할 수 있다. 특정 evaluator version에서 success-to-failure가 반복되는 node를 deprecate하고, 관련 task cluster만 재실행한 뒤, TTE summary에서 해당 node를 낮은 priority로 바꾸는 운영이 가능해진다. SkillCAT의 논문 버전은 이 부분을 자세히 다루지 않지만, 세 모듈 구조는 provenance 연결에 잘 맞는다.

이 관점에서 TTE는 단순 routing module보다 policy enforcement layer에 가깝다. router가 어떤 node를 고를 수 있는지, dependency가 어떻게 확장되는지, foundational node가 언제 강제로 포함되는지 모두 prompt policy다. skill node마다 “최근 replay 통과”, “특정 모델 family에서만 유효”, “human review 필요”, “deprecated” 같은 상태가 붙으면 TTE는 task relevance와 safety status를 함께 고려할 수 있다. 이런 확장은 논문의 숫자를 바로 높이는 기법이라기보다, SkillCAT을 실제 조직의 agent skill repository에 붙일 때 필요한 관리 계층이다.

7. 한계점 및 향후 연구 방향: evaluator가 있는 도메인에서 시작하는 방법의 경계

7.1 source-task replay가 가능한 환경에 대한 의존

SkillCAT의 가장 큰 전제는 source-task replay와 official evaluator가 존재한다는 점이다. SpreadsheetBench와 DocVQA처럼 입력, 도구, 정답 또는 평가 함수가 정리된 환경에서는 patch를 다시 실행하고 outcome transition을 측정할 수 있다. 그러나 실제 업무 에이전트는 평가가 더 모호하다. 고객 응대, 코드 리뷰, 장기 research, 사내 문서 정리처럼 성공 기준이 부분적으로 사람 판단에 의존하는 작업에서는 $y_j$와 $\hat{y}_j$를 binary로 안정화하기 어렵다. 이 경우 AAE의 hard threshold는 그대로 적용하기보다, 사람 검수, unit test, rubric judge, delayed feedback을 섞은 multi-signal assessment로 확장해야 한다.

또한 source-task clone은 patch가 나온 작업과 유사한 환경을 다시 제공해야 한다. 파일 상태, tool version, hidden evaluator, random seed가 바뀌면 replay outcome의 의미가 흔들린다. 논문은 benchmark setting에서 이를 통제하지만, 운영 환경에서는 artifact snapshot과 tool state capture가 필요하다. patch 검증이 중요하다는 메시지는 강하지만, 그 검증을 재현 가능하게 만드는 infra는 별도 과제다. SkillCAT을 실제 product agent에 붙이려면 trajectory logging과 environment replay, permission boundary, 개인정보 제거, evaluator versioning이 함께 설계되어야 한다.

7.2 multi-seed contrast가 모든 실패 원인을 설명하지는 못함

CCE는 같은 task의 성공/실패 pair를 비교하기 때문에 증거의 초점을 좁힌다. 그러나 첫 action divergence가 항상 진짜 원인이라고 보장되지는 않는다. 두 trace가 초반에 다른 순서로 파일을 열었지만 결과 차이는 후반 formula construction에서 생겼을 수도 있다. 반대로 성공 trace와 실패 trace가 초반에는 같다가, tool response의 작은 차이 때문에 후반에 갈라질 수도 있다. 논문은 causal watershed라는 표현을 쓰지만, 실제로는 관찰된 action sequence에서 첫 의미 있는 divergence를 heuristic하게 찾는 방식이다. 따라서 CCE evidence는 causal proof라기보다 patch extraction을 위한 strong candidate로 보는 편이 더 정확하다.

seed 수 sweep에서 다섯 seed 이후 성능이 내려가는 현상도 더 분석할 여지가 있다. 더 많은 seed가 noisy pair를 늘렸는지, extractor가 다양한 failure mode를 하나의 patch 공간에 제대로 통합하지 못했는지, source-task replay가 충분히 filter하지 못한 patch가 많아졌는지 분리해 볼 필요가 있다. 이 지점은 향후 연구에서 pair selection policy, uncertainty-aware extraction, diverse-failure clustering으로 확장될 수 있다. 단순히 seed 수를 늘리는 대신 mixed-outcome task의 정보량을 평가해 pair를 선택하면 offline cost를 줄이면서 evidence 품질을 높일 수 있다.

7.3 스킬 문서의 충돌과 오래된 규칙 문제

SkillCAT은 AAE로 patch를 검증하고 TTE로 필요한 node만 불러오지만, 장기 운영에서 skill corpus가 오래 쌓일 때 생기는 stale rule 문제는 별도로 남는다. 어떤 tool API가 바뀌거나 evaluator가 개정되면 과거에는 success-to-success였던 patch가 더 이상 맞지 않을 수 있다. topology routing은 관련 node만 고르더라도, 그 node 안의 규칙이 낡았다면 오히려 위험해진다. 논문은 offline evolution pipeline을 제시하지만, published skill corpus의 lifecycle management, deprecation, contradiction handling, versioned rollback까지 깊게 다루지는 않는다.

이 한계는 기존 위키의 Agent Skill Repair Loop와 연결된다. 같은 지시를 반복하게 되는 순간과 함께, 같은 skill이 반복해서 실패를 만드는 순간도 repair signal이어야 한다. SkillCAT식 AAE를 장기 운영에 붙인다면 새 patch만 평가하는 데 그치지 않고, 기존 node의 replay health를 주기적으로 검사해야 한다. TTE topology에 node-level freshness, last validated evaluator version, known contradiction 같은 metadata가 들어가면 routing 단계에서도 오래된 규칙을 낮게 평가할 수 있다.

7.4 후속 연구로 남는 evaluator 설계와 node 단위 회귀 테스트

후속 연구에서 가장 먼저 보고 싶은 것은 evaluator 설계의 일반화다. SkillCAT은 binary outcome으로 patch를 평가하지만, 실제 agent skill은 보통 정답률 하나로 품질이 끝나지 않는다. 스프레드시트 task에서도 정답은 맞혔지만 불필요하게 많은 파일을 생성하거나, tool call을 과도하게 반복하거나, 특정 형식의 입력에서만 운 좋게 맞는 경우가 있을 수 있다. 이런 patch를 success-to-success로 모두 받아들이면 skill 문서가 점차 비대해지고, TTE가 관련 node를 골라도 node 내부의 절차가 장황해질 수 있다. 따라서 AAE score를 task success, operation count, intermediate validation, output format stability로 나눈다면 patch 품질을 더 세밀하게 통제할 수 있다.

두 번째 후속 축은 node 단위 회귀 테스트다. 현재 논문은 patch replay와 final skill 성능을 보여 주지만, skill node가 topology에 들어간 뒤 시간이 지나며 어떤 task cluster에서 계속 유효한지까지는 깊게 분석하지 않는다. 운영 환경에서는 각 node에 작은 regression set을 붙이고, node body가 바뀔 때마다 해당 set만 빠르게 재실행하는 방식이 필요하다. CCE가 만든 record와 AAE가 남긴 source-task clone은 이 regression set의 출발점이 될 수 있다. 이렇게 하면 skill repository의 변경이 코드 저장소의 pull request처럼 테스트되고, TTE router는 검증된 node만 우선 선택할 수 있다.

세 번째 축은 conflict-aware merge다. AAE는 harmful patch를 filter하지만, 두 patch가 각각 source task에서는 통과하면서 서로 충돌할 가능성은 남는다. 예를 들어 한 patch는 날짜 열을 먼저 정규화하라고 하고, 다른 patch는 원본 형식을 보존한 채 문자열 비교를 하라고 할 수 있다. 둘 다 특정 source task에서는 맞았더라도 동시에 들어가면 executor가 어느 규칙을 우선할지 모호해진다. hierarchical tiered merge가 일부 우선순위를 제공하지만, 충돌 관계를 명시적으로 탐지하고 node dependency나 exclusion edge로 표현하면 TTE 단계에서 더 안전하게 조립할 수 있다.

마지막으로, user model별 skill readability도 별도 평가가 필요하다. cross-model 결과에서 gemma와 gpt-5.4-mini의 이득 폭이 다른 것은 skill 문서가 모든 모델에게 같은 방식으로 읽히지 않는다는 신호다. 어떤 모델은 구체적 tool instruction을 잘 따르고, 어떤 모델은 긴 예외 목록에서 핵심을 잃을 수 있다. 같은 skill node를 더 짧은 checklist 버전, reasoning-rich 버전, tool-call template 버전으로 변환해 user model별로 A/B 테스트하면 TTE가 단순 node selection을 넘어 node rendering까지 조절할 수 있다. SkillCAT의 구조는 이런 rendering layer를 붙이기 좋은 기반을 제공한다.

이런 확장을 모두 합치면 SkillCAT은 한 번 실행하고 끝나는 논문 알고리즘보다, agent skill repository를 운영하는 지속적 시스템에 가까워진다. CCE는 실패와 성공의 차이를 기록하고, AAE는 변경 후보의 회귀 위험을 측정하며, TTE는 현재 task와 현재 model에 맞는 검증된 지식을 꺼낸다. 스킬을 점점 많이 쌓는 것보다 중요한 것은 각 스킬 조각이 어떤 증거에서 왔고, 언제 마지막으로 통과했고, 어떤 조건에서 쓰이면 안 되는지를 함께 남기는 것이다. 이 방향으로 가야 skill self-evolution이 자동 문서 생성을 넘어 신뢰 가능한 agent 운영 체계가 된다.

8. 내 해석: patch 품질보다 더 중요한 것은 검증 가능한 스킬 운영 표면

나는 이 논문에서 가장 설득력 있는 부분이 CCE보다 AAE에 있다고 본다. CCE의 same-task contrast는 좋은 evidence extraction 아이디어지만, 실제 운영에서는 성공/실패 pair가 충분히 나오지 않거나 causal watershed가 모호할 수 있다. 반면 AAE는 더 일반적인 원칙을 준다. 어떤 방식으로 patch를 만들었든, global skill에 넣기 전에 source-task clone에서 outcome transition을 확인해야 한다는 원칙이다. 이 원칙은 사람이 직접 쓴 스킬에도 적용된다. 그럴듯한 운영 규칙을 추가했는데 기존 성공 사례를 깨뜨린다면, 그 규칙은 좋은 문장이더라도 좋은 skill update가 아니다.

다만 약점도 여기서 생긴다. 논문은 evaluator가 있는 benchmark에서 AAE의 효과를 강하게 보여 주지만, evaluator가 불완전하거나 task clone이 실제 업무 상태를 충분히 복원하지 못할 때 patch score가 얼마나 믿을 만한지는 아직 열려 있다. 특히 spreadsheet task는 answer accuracy가 비교적 명확하지만, coding agent나 research agent의 skill은 “시간을 줄였는가”, “근거를 누락하지 않았는가”, “사용자 선호를 덜 반복하게 만들었는가”처럼 더 복합적인 목적을 가진다. 내가 이 실험을 확장한다면 AAE score를 binary outcome transition 하나로 두기보다, task success, tool-call count, human correction count, rollback need, context length를 함께 보는 multi-objective replay table을 먼저 만들 것 같다.

이전에 정리한 Agent Skills와 Skill Trigger Contract 관점에서 보면, SkillCAT은 skill 본문을 어떻게 잘 쓰느냐보다 skill update가 언제 허용되는지를 다룬다. description이 흐리면 skill이 잘못 호출되고, patch가 검증되지 않으면 skill이 호출될수록 손상이 누적된다. 두 문제는 서로 다른 층위지만 실제 운영에서는 동시에 나타난다. 새 patch가 들어가면 description과 trigger도 함께 바뀌어야 할 수 있고, TTE router가 node summary를 읽기 때문에 summary 품질 역시 성능에 직접 영향을 준다. 따라서 SkillCAT을 단순히 논문 속 자동 스킬 생성기로 보기보다, skill repository에 들어가는 pull request를 테스트하고 라우팅하는 CI/CD pipeline으로 읽는 편이 더 생산적이다.

후속 제안은 TTE topology에 검증 provenance를 붙이는 것이다. 각 node가 어떤 trajectory pair에서 나왔는지, AAE에서 어떤 source-task replay를 통과했는지, 마지막으로 어떤 evaluator version에서 검증됐는지 metadata로 남긴다면 router는 관련성과 신뢰도도 함께 볼 수 있다. 예를 들어 오래된 node라도 최근 replay health가 높으면 유지하고, 관련성은 높지만 success-to-failure 위험이 관찰된 node는 사람 검수나 shadow mode로 돌릴 수 있다. 이런 provenance-aware routing은 SkillCAT의 세 모듈을 더 단단히 연결한다. CCE의 evidence, AAE의 outcome transition, TTE의 node selection이 각각 따로 저장되는 로그에 머물지 않고 하나의 운영 그래프로 이어질 수 있기 때문이다.

요약하면 이 논문은 스킬을 모델 바깥의 정적 문서로 두지 않고, 실행 증거와 회귀 테스트와 라우팅 정책이 함께 관리하는 동적 자산으로 취급한다. 이 관점이 유지될 때 CCE의 contrast, AAE의 replay, TTE의 topology가 서로 분리된 기법을 넘어 하나의 품질 관리 루프로 읽힌다.

9. 결론: 스킬 진화는 생성보다 검증과 라우팅이 중요한 문제다

SkillCAT은 LLM 에이전트의 skill self-evolution을 training-free하게 개선하는 프레임워크다. 논문은 기존 Trace2Skill-style pipeline의 한계를 single-trace bias, unvalidated merging, context overload로 정리하고, 이를 CCE, AAE, TTE로 각각 대응한다. CCE는 same-task success/failure pair에서 causal watershed 근처의 evidence를 뽑고, AAE는 candidate patch를 source-task clone에서 replay해 threshold 이상인 patch만 merge하며, TTE는 final skill을 topology로 컴파일해 task-relevant node만 inference context에 주입한다.

실험은 이 분해가 단순한 구조적 설명에 그치지 않음을 보여 준다. SpreadsheetBench-Verified에서 SkillCAT은 Qwen3.5-35B-A3B Deepening 조건 Vrf 55.50%를 기록해 Trace2Skill +Combined보다 25.83 point 높고, Skill Creation에서도 Parametric 기준을 크게 넘어선다. WikiTQ에서는 OOD table generalization이 확인되고, DocVQA에서는 multimodal transfer에서도 SkillCAT Full이 가장 좋은 결과를 보인다. cross-model setting에서는 gemma-4-31B-it과 gpt-5.4-mini가 Qwen이 작성한 skill에서 서로 다른 폭의 이득을 얻는다. ablation은 AAE 제거가 기준보다 낮은 26.00%로 떨어진다는 점을 통해 patch validation의 중요성을 뚜렷하게 보여 준다.

이 논문을 실무 관점에서 읽으면, 스킬 자동화의 핵심은 더 많은 문장을 생성하는 능력이 아니다. 실행 로그에서 어떤 evidence를 뽑을지, 새 규칙이 기존 성공을 깨뜨리지 않는지, 커진 skill 중 어느 부분을 task에 보여 줄지 결정하는 운영 표면이 더 중요하다. SkillCAT은 이 운영 표면을 benchmark 안에서 측정 가능한 형태로 만든다. 남은 과제는 evaluator가 없는 실제 업무 환경에서 replay와 provenance를 어떻게 설계할지, 오래된 skill node를 어떻게 retire할지, user model별로 router와 node granularity를 어떻게 조정할지다.

10. 요약 정리

• SkillCAT은 LLM 에이전트의 실행 trajectory를 재사용 가능한 skill 문서로 바꾸는 skill self-evolution 문제를 다룬다.
• 논문은 기존 Trace2Skill-style 방법의 병목을 single-trace bias, unvalidated merging, context overload 세 가지로 정리한다.
• CCE는 같은 task의 success/failure trajectory pair를 비교해 outcome 차이를 만든 action divergence 근처의 evidence를 추출한다.
• AAE는 candidate patch를 source-task clone에서 replay하고, failure-to-success 또는 success-to-success patch만 threshold를 통과시킨다.
• TTE는 완성된 skill을 topology로 컴파일한 뒤, test-time task에 필요한 node만 routing해 context overload를 줄인다.
• Qwen3.5-35B-A3B Skill Deepening에서 SkillCAT은 SpreadsheetBench-Verified Vrf 55.50%를 기록해 Trace2Skill +Combined의 29.67%보다 크게 높다.
• DocVQA에서는 SkillCAT Full이 ANLS 0.9159와 0.7200을 기록하고, Trace2Skill +Error는 일부 조건에서 No Skill보다 낮아져 검증 없는 patch의 위험을 드러낸다.
• Ablation에서 AAE 제거가 26.00%로 떨어지는 결과는 patch validation이 선택 기능을 넘어 skill evolution의 안전장치임을 보여 준다.
• 실제 운영 적용에는 evaluator 재현성, source-task clone 관리, stale skill node 검출, provenance-aware routing 같은 추가 장치가 필요하다.