[arXiv 2606.24855] OpenThoughts-Agent: 에이전트 모델을 위한 데이터 레시피

OpenThoughts-Agent: Data Recipes for Agentic Models

https://arxiv.org/abs/2606.24855

Negin Raoof, Richard Zhuang, Marianna Nezhurina, Etash Guha, Atula Tejaswi, Ryan Marten, Alex Dimakis, Benjamin Feuer, Ludwig Schmidt et al. | UC Berkeley, Stanford University, JSC, LAION, Oumi.AI, UT Austin 등 | arXiv:2606.24855 | 2026년 6월

---

OpenThoughts-Agent는 “에이전트 모델을 잘 만들려면 어떤 데이터를 어떤 순서로 골라야 하는가”를 정면으로 다루는 논문이다. 최근의 공개 에이전트 연구는 SWE-Bench, Terminal-Bench, browser/GUI task처럼 특정 벤치마크의 점수를 끌어올리는 데 집중해 왔지만, 여러 종류의 도구 사용 과제를 동시에 견디는 범용 agentic model을 만들기 위한 데이터 레시피는 공개 문헌에 거의 남지 않았다. 이 논문은 그 빈칸을 SFT 데이터 파이프라인, 100회 이상의 ablation, 100K 규모 최종 데이터셋, 32B/8B 모델 실험으로 채우려는 시도다.

핵심 결과는 단순한 “더 큰 데이터가 더 좋다”가 아니다. 저자들은 task source, source mixing, task augmentation, task filtering, teacher model, rollout filtering이라는 여섯 단계를 분리해 보고, 각 단계가 SWE-Bench Verified, OpenThoughts-TBLite, Terminal-Bench 2.0 같은 agentic benchmark에 미치는 영향을 측정한다. 그 위에서 100K OpenThoughts-Agent-v2 데이터를 만들고 Qwen3-32B를 fine-tune한 OpenThinkerAgent-32B가 일곱 개 에이전트 벤치마크 평균 44.8%를 기록했다고 보고한다.

이 논문이 흥미로운 이유는 agent 연구에서 자주 빠지는 “데이터 생산 공정”을 실험 대상 자체로 끌어올린다는 점이다. Shepherd 리뷰에서 보았던 실행 trace와 replay 기판, ExpRL 리뷰에서 보았던 탐색 보상, Agent Premature Commitment 메모에서 본 조기 확신 문제는 모두 에이전트의 행동 궤적을 어떻게 남기고 학습시키느냐와 연결된다. OpenThoughts-Agent는 그 흐름을 “어떤 trajectory가 학습 데이터로 가치 있는가”라는 더 실무적인 질문으로 바꾼다.

1. 서론: 범용 에이전트 학습에서 데이터 레시피가 비어 있던 자리

LLM 에이전트는 이제 단순 질의응답 시스템보다 훨씬 넓은 역할을 맡는다. 코드 저장소를 수정하고, 터미널 명령을 실행하고, API 문서를 읽고, 테스트 실패를 따라가며, 필요하면 여러 번 도구 호출을 반복한다. 이 능력은 모델의 사전학습 규모만으로 결정되지 않는다. 같은 base model이라도 어떤 task description을 주고, 어떤 teacher trajectory를 모으고, 어떤 실패 trace를 걸러내고, 어떤 benchmark 조합으로 검증하느냐에 따라 agentic behavior가 크게 바뀐다.

그런데 공개 모델 논문에서 training data는 여전히 압축적으로만 설명되는 경우가 많다. 모델 구조, optimizer, context length, inference harness는 비교적 자세히 나오지만, 실제 post-training data가 어떤 출처에서 왔고 어떤 기준으로 버려졌으며 어떤 teacher가 어떤 경로를 만들었는지는 “혼합 데이터”나 “도구 사용 데이터”라는 이름 아래 묻힌다. OpenThoughts-Agent는 이 부분을 논문 본문으로 끌어올린다. 저자들은 state-of-the-art 점수 자체보다, 그 점수를 낳은 데이터 결정들을 실험 가능한 변수로 만들고 공개하려 한다.

논문의 문제의식은 공개 생태계에서 특히 중요하다. SWE-Smith, SERA, Nemotron-Terminal, OpenSWE 같은 기존 공개 노력은 유용하지만, 대체로 한 벤치마크나 좁은 환경에 맞춰 설계되었다. SWE-Bench만 잘하는 데이터는 repository editing에는 강해도 terminal command planning에는 약할 수 있고, Terminal-Bench 중심 데이터는 shell state와 tool invocation에는 익숙하지만 multi-file software engineering에는 덜 맞을 수 있다. 저자들은 이런 benchmark specialization을 벗어나기 위해 다양한 task source를 섞고, source별 장단점을 ablation으로 분리한다.

이 접근은 기존 OpenThoughts reasoning data 연구의 연장선에 있다. 다만 reasoning benchmark의 풀이 trace와 agentic benchmark의 실행 trace는 요구 조건이 다르다. 에이전트 데이터는 답안 한 줄보다 긴 상태 변화와 도구 결과를 포함하고, trace가 길수록 비용과 오류 가능성도 커진다. 따라서 task description 자체의 품질, teacher model의 행동 습관, timeout과 subagent 사용 여부, 최소 turn 수 같은 세부 조건이 학습 신호의 성격을 바꾼다. OpenThoughts-Agent는 이런 조건을 “데이터 레시피”라는 이름으로 하나씩 고정하고 흔든다.

가장 먼저 볼 포인트는 논문이 모델 아키텍처보다 데이터 조립 규칙을 전면에 둔다는 점이다. OpenThinkerAgent-32B는 Qwen3-32B를 기반으로 한 SFT 모델이고, 8B 실험에서는 SFT 위에 RL을 결합한다. 새 Transformer block이나 새로운 inference algorithm이 등장하는 논문은 아니지만, agent 분야에서는 오히려 이런 데이터 중심 논문이 실무 영향력이 클 수 있다. 실제 agent product나 연구 프로젝트에서 가장 먼저 부딪히는 병목은 “좋은 trajectory를 얼마나 안정적으로 만들고 재사용할 수 있는가”이기 때문이다.

Figure 1: OpenThoughts-Agent-SFT 데이터 규모별 성능 비교

Figure 1은 OpenThoughts-Agent SFT 데이터가 데이터 크기 증가에 따라 SWE-Bench Verified와 Terminal-Bench 2.0에서 어떻게 이동하는지 보여 준다. 중요한 점은 같은 100K scale에서도 단순히 공개 agent dataset을 더 크게 쓰는 것보다, task source와 filtering을 거친 레시피가 일관되게 높은 곡선을 만든다는 것이다. SERA처럼 특정 harness와 강하게 맞물린 데이터는 일부 구간에서 비교가 까다롭지만, 저자들은 동일 base family 안에서 compute-controlled 비교를 통해 데이터 품질의 차이를 부각한다.

이 그림은 논문 전체의 압축판이다. 데이터 스케일이 커질수록 좋은 source selection의 효과가 사라지기보다 오히려 남는다. 따라서 저자들이 뒤에서 수행하는 95개 task generation strategy ranking, top-N mixing, teacher ablation, rollout filtering은 단순한 부록성 실험이 아니다. 최종 100K 데이터셋의 성능을 설명하는 원인 후보를 분해하기 위한 본문 실험이다.

2. 배경 및 관련 연구: 단일 벤치마크 최적화에서 데이터 공정 공개로

2.1 공개 에이전트 데이터의 좁은 초점

공개 agent training 데이터의 대표 흐름은 특정 환경을 안정적으로 재현하는 데서 출발했다. SWE-Smith는 software issue resolution을 합성하고, SERA는 repository-level verification을 효율화하며, Nemotron-Terminal은 terminal interaction 중심의 corpus를 만든다. 이런 접근은 각각 분명한 가치를 갖지만, 한 환경의 관찰 양식과 평가 harness에 특화되기 쉽다. 예를 들어 SWE-Bench는 commit, patch, test라는 구조가 선명한 반면 Terminal-Bench는 shell state와 command sequencing이 더 직접적이다. 두 환경에서 좋은 trajectory가 요구하는 탐색 깊이와 실수 복구 방식은 다르다.

OpenThoughts-Agent의 배경에는 이런 불균형이 있다. 저자들은 agentic model이 실제로 쓸모 있으려면 software engineering, terminal use, tool calling, healthcare, finance, general assistant task를 폭넓게 견뎌야 한다고 본다. 그래서 평가도 일곱 개 benchmark 평균을 사용하고, 개발 과정의 ablation은 SWE-Bench Verified-100, OT-TBLite, Terminal-Bench 2.0을 중심으로 진행한다. 이 조합은 코딩 능력, 터미널 조작, broad tool-use 성향을 동시에 보는 최소 세트로 쓰인다.

2.2 데이터 큐레이션을 모델 성능의 독립 변수로 다루기

논문이 기여하는 방식은 데이터셋 공개만이 아니다. 더 중요한 것은 데이터셋을 만드는 선택지를 실험 가능한 독립 변수로 만든다는 점이다. task source를 어디서 가져올지, source를 몇 개까지 섞을지, task description을 LLM으로 더 어렵게 만들지, teacher model을 무엇으로 둘지, rollout 중 어떤 trace를 버릴지 같은 결정은 보통 내부 경험칙으로 처리된다. 저자들은 이 결정을 100개 이상의 controlled ablation으로 바꾸고, downstream benchmark 변화를 표로 공개한다.

이 관점은 최근 agent evaluation 논의와도 맞닿아 있다. 이전에 리뷰한 Shepherd는 agent 실행을 typed trace로 남기고 fork/replay할 수 있어야 학습과 감독이 쉬워진다고 주장했다. Agent premature commitment 메모는 최종 정답만 보는 평가로는 조기 확신 같은 실패를 잡기 어렵다고 보았다. OpenThoughts-Agent는 그 다음 단계의 질문을 던진다. trace를 볼 수 있다면, 그중 어떤 trace를 SFT 데이터로 남기는 것이 모델의 일반화에 도움이 되는가. 이 질문은 데이터 공정의 품질 관리 문제이면서 동시에 agent behavior를 설계하는 문제다.

2.3 SFT와 RL의 역할 분리

저자들은 본문 대부분을 SFT data pipeline에 할애하지만, 8B scale에서는 agentic RL도 별도로 살핀다. 이 구분은 중요하다. SFT는 teacher trajectory를 imitation 형태로 밀어 넣는 단계이고, RL은 environment feedback이나 verifier reward를 따라 정책을 조정하는 단계다. 두 단계는 서로 독립적이지 않다. 어떤 SFT checkpoint에서 출발하느냐에 따라 RL이 탐색을 키울 수도, 불필요한 loop를 줄일 수도 있다. 논문은 8B 실험에서 “undertrained SFT가 RL을 더 잘 받는다”는 관찰을 제시하며, 순수 RL이나 순수 distillation보다 SFT+RL 조합이 나은 경우를 보여 준다.

이 지점은 ExpRL과 연결된다. ExpRL은 reasoning mid-training에서 reference solution을 직접 모방시키기보다 탐색 행동을 보상하려는 흐름이었다. OpenThoughts-Agent의 RL 분석도 탐색의 양면성을 보여 준다. pymethods2test source에서는 더 많은 thinking, tool call, self-correction이 성능 향상으로 이어지지만, 너무 길어지면 reward collapse가 나타난다. 반대로 llm-verifier-freelancer source에서는 RL이 trace를 더 compact하게 만든다. 따라서 agentic RL은 단일한 “더 탐색하라” 신호에 그치지 않고 데이터 source의 난이도와 reward ceiling에 따라 다른 행동 변화를 낳는다.

3. 방법론: 여섯 단계 SFT 파이프라인과 100K 데이터셋

3.1 전체 파이프라인 구조

OpenThoughts-Agent의 SFT pipeline은 여섯 단계로 구성된다. 첫째, task description을 만들 source를 고른다. 둘째, top source들을 어떤 비율로 섞을지 정한다. 셋째, task description을 LLM으로 변형하거나 보강할지 시험한다. 넷째, task 자체를 filtering한다. 다섯째, agent rollout을 생성할 teacher model을 고른다. 여섯째, 생성된 rollout 중 어떤 trace를 학습 데이터로 유지할지 결정한다. 논문은 이 과정을 독립적으로 ablate해 어떤 단계가 실제 downstream 성능을 크게 흔드는지 보여 준다.

이 구조가 좋은 이유는 데이터셋 구축 과정을 “한 번에 만든 corpus”로 보지 않기 때문이다. agentic data는 task description과 response trajectory의 결합이다. 좋은 task라도 teacher가 무의미한 loop를 돌면 학습 신호가 나빠지고, 좋은 teacher라도 task source가 단일 benchmark에 치우치면 일반화가 흔들린다. 또한 긴 trace는 정보가 많지만 token budget을 많이 쓰고, 짧은 trace는 효율적이지만 장기 의사결정 패턴을 덜 보여 준다. 여섯 단계 분해는 이런 trade-off를 분리해 관찰하게 해 준다.

Figure 2: OpenThoughts-Agent의 여섯 단계 SFT 데이터 파이프라인

Figure 2는 논문의 중심 도식이다. task source에서 출발해 mixing, augmentation, filtering, teacher rollout, rollout filtering으로 이어지는 순서가 명확하다. 각 단계가 독립 실험으로 이어지기 때문에, 최종 점수를 한 덩어리로 해석하지 않고 “어떤 선택이 얼마만큼 기여했는가”를 추적할 수 있다. 특히 agent 데이터에서는 task와 trajectory가 분리되지 않기 때문에, 이 도식은 데이터셋 설명서이자 실험 설계표 역할을 동시에 한다.

3.2 task source와 source mixing

가장 큰 효과는 task generation strategy에서 나온다. 저자들은 synthetic issue-resolution task, human-written computer-use question, StackExchange 기반 task, repository scaffold, benchmark-derived task 등 95개 전략을 ablate한다. 결과적으로 SWE-Smith, StackExchange SuperUser, StackExchange Tezos, IssueTasks 같은 source가 상위권에 놓인다. 흥미로운 점은 각 source가 잘하는 benchmark가 다르다는 것이다. SWE-Smith는 SWE-Bench 쪽을 강하게 밀고, SuperUser나 Tezos 계열은 Terminal-Bench에 더 도움이 된다. 따라서 단일 top source를 크게 키우는 전략은 평균 성능에서 약점을 남긴다.

source mixing 실험은 이 관찰을 수치로 뒷받침한다. 논문은 top-N source를 골라 각 source에서 $10{,}000/N$개 task를 샘플링하는 방식으로 top 1, 2, 4, 8, 16, 32 조합을 비교한다. random shuffle within task 기준 top-4는 raw average 18.19를 얻고, top-1은 SWE-Bench Verified에서는 높지만 Terminal-Bench 2.0에서 낮아 평균이 16.65에 머문다. 즉 범용 agentic model의 데이터는 가장 강한 단일 source를 많이 넣는 방식보다, 상위 source 몇 개를 균형 있게 섞는 방식이 안정적이다.

Rank	Mixing Strategy	SWE-Bench Verified (100)	OT-TBLite	Terminal-Bench 2.0	Raw Avg	Normalized
1	Top 4	29.33 ± 1.63	17.00 ± 1.71	8.24 ± 1.24	18.19	+0.49
2	Top 2	29.00 ± 1.60	18.12 ± 1.72	7.12 ± 1.06	18.08	+0.48
3	Top 8	28.00 ± 1.70	15.86 ± 1.70	8.61 ± 1.24	17.49	+0.19
6	Top 1	30.67 ± 1.67	14.80 ± 1.40	4.49 ± 0.84	16.65	-0.57

이 표는 “전문화된 데이터의 최고점”과 “범용 agent 평균”이 다를 수 있음을 보여 준다. Top 1은 SWE-Bench Verified에서는 가장 높지만, Terminal-Bench가 4.49로 낮아진다. 반면 Top 4는 각 benchmark에서 극단적인 최고점은 아니어도 평균이 가장 좋다. 실제 서비스형 에이전트를 만들 때도 이 패턴은 중요하다. 특정 데모 task에서만 강한 데이터보다, 실패 양상이 다른 source를 섞어 tool-use habit을 분산시키는 쪽이 운영 안정성에 유리할 수 있다.

3.3 task augmentation과 filtering

task description을 LLM으로 더 어렵게 만들거나 constraint를 추가하는 augmentation은 직관적으로 좋아 보인다. 하지만 논문에서는 대부분의 augmentation이 original task description을 그대로 쓰는 baseline을 안정적으로 넘지 못한다. Constrain, Harden, Mixed, Trace hints 같은 전략은 일부 benchmark에서 오르지만 전체 평균에서는 noise 범위에 머무른다. 저자들은 이 결과를 task surface form을 복잡하게 만드는 것만으로는 agent 학습 신호가 좋아지지 않는다는 증거로 해석한다.

반대로 filtering은 효과가 더 선명하다. GPT-5가 문제를 풀 때 긴 response를 필요로 하는 task를 고르는 response-length filter가 random baseline보다 평균 약 3 percentage point를 끌어올린다. 이 신호는 task가 너무 쉬워 금방 끝나는지, 또는 충분한 reasoning과 tool-use를 요구하는지에 대한 proxy로 쓰인다. 물론 response length가 완벽한 난이도 지표는 아니지만, agent SFT에서는 긴 문제 해결 경로가 나올 여지가 있는 task가 더 가치 있는 supervision을 제공할 가능성이 크다.

Filtering Strategy	SWE-Bench Verified (100)	OT-TBLite	Terminal-Bench 2.0	Raw Avg	해석
Response Length (GPT-5, longest)	22.67 ± 1.53	19.51 ± 1.72	10.11 ± 1.35	17.43	긴 풀이가 필요한 task를 우선 선택
Response Length (GPT-5, shortest)	21.33 ± 1.67	16.91 ± 1.65	9.74 ± 1.24	15.99	짧은 풀이 task도 일부 효과는 있으나 평균 낮음
AskLLM	20.67 ± 1.63	15.87 ± 1.52	10.86 ± 1.18	15.80	LLM 품질 판단만으로는 제한적
Random baseline	19.67 ± 1.70	14.77 ± 1.36	7.87 ± 1.35	14.10	무작위 선택 기준선

이 결과를 적용할 때 조심할 점도 있다. response length filter가 agentic quality를 직접 측정하는 것은 아니다. 긴 답이 필요한 task가 복잡한 state tracking을 요구할 가능성이 높다는 경험적 상관을 이용한다. 따라서 실무에서는 길이 지표만 쓰기보다, task가 실제 environment interaction을 유발하는지, verification signal이 명확한지, 실패했을 때 학습 가능한 correction trace가 남는지까지 함께 봐야 한다. 그래도 논문은 단순한 자동 필터가 random sampling보다 훨씬 낫다는 실용적 출발점을 제공한다.

3.4 teacher model과 rollout filtering

teacher model ablation은 더 직관을 흔든다. 가장 강한 benchmark model이 항상 가장 좋은 teacher는 아니었다. GPT-5.3-Codex는 자체 성능이 강하지만, 이 실험에서는 GLM 4.7 AWQ보다 Terminal-Bench 2.0 기준 약 5 percentage point 낮은 teacher로 나타난다. 저자들은 teacher가 정답률만 높은지보다, 학생 모델이 모방하기에 적절한 trace distribution을 만드는지가 더 중요하다고 본다. 너무 압축적이거나 특정 harness에 맞춘 trace는 downstream SFT에 덜 유리할 수 있다.

Teacher Model	SWE-Bench Verified (100)	OT-TBLite	Terminal-Bench 2.0	Raw Avg	Normalized
GLM 4.7 (Quantized)	28.00 ± 1.76	17.86 ± 1.60	8.61 ± 1.40	18.16	+0.73
Kimi K2.5	33.33 ± 1.83	14.19 ± 1.51	8.24 ± 1.06	18.59	+0.66
GLM 5	33.00 ± 1.60	14.30 ± 1.78	7.50 ± 1.18	18.27	+0.66
GPT-5.3-Codex	21.67 ± 1.33	10.42 ± 1.55	3.75 ± 0.99	11.94	-1.47

rollout filtering에서는 timeout 제거, subagent trace 제거, 최소 turn 수 필터가 비교된다. 가장 강한 결과는 min turns $\geq 5$ 필터다. 이 필터는 SWE-Bench Verified (100) 29.00, OT-TBLite 19.10, Terminal-Bench 2.0 11.61을 기록해 세 benchmark 모두에서 가장 높다. 저자들은 token budget을 맞춘 control에서도 이 효과가 유지된다고 보고한다. 즉 긴 trace의 이득은 단순히 더 많은 token을 학습했기 때문으로만 설명되지 않고, 여러 turn에 걸친 관찰-행동-수정 패턴이 supervision으로 남기 때문이라는 해석이 가능하다.

Trajectory Filter	SWE-Bench Verified (100)	OT-TBLite	Terminal-Bench 2.0	Raw Avg	요지
Min turns $\geq 5$	29.00 ± 1.56	19.10 ± 1.57	11.61 ± 1.30	19.90	여러 turn의 문제 해결 trace를 유지
Filter timeouts	26.67 ± 1.70	18.03 ± 1.60	10.49 ± 1.18	18.39	명백한 실패 trace 제거
Filter subagent traces	23.00 ± 1.63	17.31 ± 1.58	10.86 ± 1.35	17.06	복잡한 delegated trace를 제외

이 대목은 에이전트 학습 데이터의 품질 기준을 바꾼다. 일반 instruction tuning에서는 짧고 정돈된 답변이 선호될 수 있지만, agentic SFT에서는 적절한 길이의 시행착오가 학습 신호가 된다. 모델이 파일을 읽고, 가설을 세우고, 테스트를 돌리고, 실패 원인을 다시 좁히는 과정을 보여 주는 trace가 필요하다. timeout처럼 끝없이 도는 trace는 해롭지만, 여러 turn이 있다는 사실 자체는 agent behavior의 핵심 구조를 보존한다.

4. 실험 설정: benchmark suite, base model, compute 조건

4.1 데이터셋 및 벤치마크

논문은 개발 단계와 최종 평가 단계를 구분한다. pipeline ablation의 중심에는 SWE-Bench Verified-100, OpenThoughts-TBLite, Terminal-Bench 2.0이 있다. 이 세 benchmark는 실험 비용을 통제하면서 source choice와 filtering의 방향성을 보기 위한 proxy 역할을 한다. 최종 32B 결과에서는 SWE-Bench Verified, Terminal-Bench 2.0, Aider-Polyglot, BFCL-Parity, MedAgentBench, GAIA-127, FinanceAgent-Terminal까지 총 일곱 개 benchmark 평균을 사용한다. core task와 OOD task를 함께 넣어 특정 개발 benchmark에만 맞춘 데이터인지 확인하려는 설계다.

SWE-Bench Verified는 GitHub issue 해결 능력을, Terminal-Bench 2.0은 터미널 환경에서의 절차적 명령 실행과 상태 추적을, BFCL-Parity는 tool calling을, FinanceAgent-Terminal과 MedAgentBench는 도메인형 agent task를 본다. Aider-Polyglot은 다언어 코딩 수정 능력에 가깝고, GAIA-127은 일반 assistant형 복합 추론과 도구 사용을 포함한다. 이 조합은 완벽하다고 보기는 어렵지만, agentic model이 한 가지 harness에 과적합되지 않았는지 보기에는 충분히 넓다.

4.2 구현 세부사항

32B SFT 실험은 Qwen/Qwen3-32B에서 출발하고, qwen3 thinking chat template을 사용한다. 공통 optimizer는 AdamW, learning rate $4 imes10^{-5}$, cosine schedule, warmup ratio 0.1, global batch size 96, sequence cutoff 32,768 tokens, BF16 weights, DeepSpeed ZeRO-3 조합이다. hardware는 JUPITER Booster의 24 nodes, 각 node 4개 GH200으로 보고된다. 데이터 scale이 3.16K와 10K일 때는 7 epochs, 31.6K와 100K일 때는 5 epochs를 사용한다.

8B 실험도 Qwen3-8B 계열에서 출발하지만, chat template은 qwen3_nothink를 사용하고 전 scale에서 7 epochs를 유지한다. 8B SFT 이후 RL 실험은 24개 A100 80GB GPU에서 RLOO 방식으로 수행된다. RL hero run은 약 46시간 wall-clock을 사용하고, batch size 64 prompt, prompt당 8 sample, 총 512 trajectory per update 구조를 갖는다. 이처럼 논문은 데이터 실험이지만 compute 조건과 sequence length도 꽤 상세히 공개한다.

항목	32B SFT 설정	8B SFT / RL 설정
Base model	Qwen/Qwen3-32B	Qwen/Qwen3-8B 또는 distilled 8B checkpoint
학습 방식	SFT 중심, 최종 OpenThinkerAgent-32B	SFT + RLOO 기반 agentic RL
Sequence cutoff	32,768 tokens	32,768 tokens, 일부 long-context variant 131,072
주요 hardware	24 nodes, JUPITER Booster, GH200	RL hero run: 24×A100 80GB
데이터 규모	3.16K, 10K, 31.6K, 100K	1K부터 100K SFT scale 및 5K RL source

실험 설정에서 눈에 띄는 것은 저자들이 data scale과 compute를 분리하려 애쓴다는 점이다. 예를 들어 min-turn filtering의 이득이 단순히 더 많은 token 수 때문인지 확인하기 위해 matched token budget control을 둔다. 또한 SERA처럼 자체 harness가 평가와 데이터 생성에 모두 관여하는 경우, SWE-agent와 Terminus-2 harness를 함께 보고해 비교가 한쪽으로만 기울지 않게 한다. 공개 데이터 논문에서 이런 비교 조건 명시는 후속 연구자가 같은 레시피를 재현하거나 반박하는 데 중요하다.

4.3 베이스라인

32B 최종 비교에는 Nemotron-Terminal-32B, SWE-Lego-Qwen3-32B, SERA-32B, SA-SWE-32B, DeepSWE-Preview, Qwen3-32B가 포함된다. 모두 Qwen3-32B family 또는 그 이전 base 조건에서 비교된다. 8B 비교에는 Nemotron-Terminal-8B, SWE-Lego-Qwen3-8B, Endless-Terminal-OpenThinker-8B, OpenThinker-Agent-v1, SERA-8B, Qwen3-8B 등이 포함된다. 저자들은 각 모델을 Terminus-2와 원래 harness 양쪽에서 평가하고, 모델별 최대 accuracy를 보고한다.

이 보고 방식에는 장단점이 있다. 장점은 모델이 특정 harness에서만 낮게 보이는 문제를 줄이고, 기존 모델의 best-known operating point를 비교한다는 것이다. 단점은 각 모델의 평가 조건이 완전히 동일한 single harness로 고정되지는 않는다는 점이다. 논문은 이 문제를 보완하기 위해 standard error와 appendix table을 제공하지만, 독자는 숫자를 “절대 순위”라기보다 공개 agent model family 안에서 OpenThoughts-Agent 데이터가 경쟁력 있는 위치에 있음을 보여 주는 근거로 읽는 편이 안전하다.

5. 주요 실험 결과: 32B SFT와 8B SFT+RL이 보여 준 데이터 효과

5.1 32B 최종 모델의 benchmark 성능

최종 32B 모델인 OpenThinkerAgent-32B는 일곱 개 benchmark 평균 44.8%를 기록한다. 비교 대상 중 가장 강한 open-data agentic model로 제시된 Nemotron-Terminal-32B의 평균은 40.9%이고, Qwen3-32B base는 22.8%다. core benchmark에서도 OpenThinkerAgent-32B는 SWE-Bench Verified 54.0, Terminal-Bench 2.0 26.2를 기록해 Nemotron-Terminal-32B의 41.9, 25.1을 넘는다. 특히 Terminal-Bench에서의 차이는 1.1 point로 작지만, SWE-Bench Verified에서는 12.1 point 차이가 난다.

Benchmark	OpenThinkerAgent-32B	Nemotron-Terminal-32B	SWE-Lego-Qwen3-32B	SERA-32B	Qwen3-32B
Average (7 benchmarks)	44.8	40.9	34.7	28.1	22.8
SWE-Bench Verified	54.0	41.9	51.0	49.4	29.1
Terminal-Bench 2.0	26.2	25.1	16.1	9.7	7.5
Aider-Polyglot	32.4	24.9	30.1	26.7	28.9
BFCL-Parity	85.9	69.1	81.0	69.1	68.3
FinanceAgent-Terminal	44.0	40.7	15.3	17.3	9.3

이 표에서 중요한 것은 OpenThinkerAgent-32B가 모든 row에서 압도적으로 1등이라는 이야기가 아니다. MedAgentBench에서는 Nemotron-Terminal-32B가 62.6으로 더 높고, SWE-Lego도 SWE-Bench Verified에서 51.0으로 꽤 근접한다. 그러나 평균을 보면 OpenThoughts-Agent 데이터셋이 core와 OOD를 동시에 끌어올리는 쪽으로 작동한다. 단일 벤치마크 specialty보다 source mix와 filtering을 거친 broad agentic SFT가 전체 평균에서 강하다는 논문의 주장이 이 표에 모인다.

또 한 가지는 train size 비교다. OpenThinkerAgent-32B는 100K training set을 사용하고, Nemotron-Terminal-32B는 264K로 표시된다. 더 많은 데이터가 항상 더 강한 성능을 보장하지 않는다는 점이 여기서 드러난다. 물론 데이터의 token 수, trajectory 길이, teacher quality, benchmark overlap 가능성까지 모두 통제한 완전한 비교는 아니지만, 적어도 공개된 숫자만 보면 100K 규모에서도 source와 filtering이 잘 설계되면 더 큰 corpus를 넘을 수 있다.

5.2 scaling: upsampling plateau와 synthetic task augmentation

데이터 규모를 키우는 방법은 여러 가지다. 같은 task description에서 rollout을 더 많이 만들 수도 있고, 원래 source에서 더 많은 task를 가져올 수도 있으며, 새로운 source를 추가하거나 synthetic augmentation으로 task surface를 늘릴 수도 있다. 논문은 먼저 같은 task description에서 rollout을 늘리는 simple upsampling을 시험한다. 결과적으로 31.6K에서 100K로 갈 때 SWE-Bench Verified-100과 Terminal-Bench 2.0 변화가 표준오차 범위에 가까워 plateau가 나타난다. 저자들은 task-description diversity가 병목이라고 본다.

그래서 Tezos subset을 synthetic task augmentation으로 확장한다. Tezos는 unique task description이 997개로 적기 때문에, 저자들은 instruction rewriting 전략을 활용해 distinct surface form을 약 902개에서 21K 이상으로 늘리고, GPT-5 response-length signal을 hard filter로 고정하지 않고 upsampling weight로 사용한다. 이 방식은 단순 rollout upsampling보다 scale이 커질수록 낫게 나타난다. 즉 agentic SFT에서 “같은 문제를 여러 번 풀게 하기”보다 “실질적으로 다양한 task description을 보게 하기”가 더 중요하다는 해석이 가능하다.

Figure 3: 동일 task rollout upsampling과 synthetic task augmentation의 scaling 비교

Figure 3은 이 논문의 scaling 메시지를 가장 직접적으로 보여 준다. 같은 10K base에서 출발해 additional rollout만 늘리는 방법은 일정 규모 이후 성능이 눌리지만, synthetic task augmentation은 세 benchmark에서 더 꾸준히 오른다. 이 결과는 데이터량을 token 수로만 보는 관점에 제동을 건다. agent model에서는 trajectory 개수보다 task description의 다양성과 문제 표면의 변형 폭이 실제 일반화에 더 직접적으로 연결될 수 있다.

5.3 100K 최종 SFT 데이터 구성

최종 SFT dataset은 top-4 source mix, task filtering, teacher selection, rollout filtering을 거쳐 100K agentic traces로 구성된다. 저자들은 source diversity를 더 넓히는 top-8, top-16도 시험했지만, 100K scale에서는 top-4를 넘는 source 추가가 항상 이득을 주지 않는다고 보고한다. top-8은 일부 benchmark에서 top-4보다 높지만, top-16은 세 benchmark 모두에서 떨어진다. 이 결과는 “다양성은 많을수록 좋다”보다, 품질과 domain fit을 유지할 수 있는 범위의 다양성이 중요하다는 뜻으로 읽힌다.

Source Mix (100K, 32B)	SWE-Bench Verified-100	OT-TBLite	Terminal-Bench 2.0	해석
Top-4	45.33 ± 1.73	36.90 ± 1.82	21.72 ± 1.54	최종 레시피의 기본 source mix
Top-8	49.00 ± 1.45	38.87 ± 2.09	22.85 ± 1.30	일부 수치는 높지만 일관된 압도는 아님
Top-16	40.33 ± 1.41	33.14 ± 2.01	20.60 ± 1.67	넓힌 source가 오히려 성능 저하

이 결과는 데이터 큐레이션의 실무 감각과도 맞는다. source를 넓히면 domain coverage는 올라가지만, low-quality task, harness mismatch, verification이 약한 trace가 섞일 위험도 커진다. 특히 agentic task는 환경 상태와 평가 스크립트가 함께 맞아야 하므로, “다양한 자연어 문제”만 늘린다고 좋은 데이터가 되지 않는다. 논문은 top-4가 SWE-Smith, StackExchange SuperUser, StackExchange Tezos, IssueTasks처럼 서로 다른 강점을 가진 source로 구성되었다는 점을 강조한다.

Figure 4: OpenThoughts-Agent 최종 SFT 데이터셋의 source 흐름과 필터링

Figure 4의 Sankey 도식은 최종 100K trace가 어떤 source와 filtering 경로를 거쳐 만들어졌는지 보여 준다. 논문을 읽을 때 이 그림은 source별 양적 비중보다 “필터링된 궤적이 어떤 공정의 산물인가”를 확인하는 용도로 중요하다. agent data는 단순 문서 말뭉치와 달리 각 예시가 환경 interaction을 포함하므로, 최종 dataset card는 source, teacher, trace filter가 함께 기록되어야 재사용 가능성이 높아진다.

5.4 8B scale에서의 SFT와 RL 결합

8B scale에서는 SFT만으로도 base Qwen3-8B보다 큰 개선을 얻지만, RL을 결합한 OT-Agent-ColdSFT+RL-8B가 평균 27.9로 가장 높다. 흥미로운 점은 100K SFT-8B가 평균 27.4로 거의 비슷하게 강하고, 10K SFT-8B는 24.3에 머문다는 점이다. RL은 모든 출발점에 똑같이 작동하지 않는다. 논문은 undertrained SFT checkpoint가 RL을 통해 더 큰 이득을 얻는다고 설명한다. 너무 약한 base는 agentic RL signal을 제대로 이용하지 못하고, 이미 충분히 distill된 모델은 RL이 줄 수 있는 행동 변화가 제한될 수 있다.

Model / Recipe	Train Size	Method	Average	SWE-Bench Verified	Terminal-Bench 2.0	FinanceAgent-Terminal
OT-Agent-ColdSFT+RL-8B	10K + 5K	SFT + RL	27.9	31.9	13.5	22.7
OT-Agent-SFT-8B (100K)	100K	SFT	27.4	38.9	10.9	17.3
Nemotron-Terminal-8B	264K	SFT	26.0	22.1	13.1	11.3
OT-Agent-SFT-8B (10K)	10K	SFT	24.3	22.7	7.9	14.7
Qwen3-8B	N/A	Base	10.2	13.2	2.2	1.3

이 표는 SFT와 RL의 역할을 더 정교하게 나눈다. 100K SFT는 SWE-Bench Verified에서 38.9로 가장 높지만, RL 결합 모델은 Terminal-Bench 2.0과 FinanceAgent-Terminal에서 강하다. 즉 RL은 특정 benchmark의 patch generation 정확도보다, agent가 환경 안에서 시도하고 수정하는 방식에 영향을 준다. 서비스형 agent에서는 이런 차이가 중요하다. 단일 commit 성공률이 조금 낮더라도 terminal task나 finance workflow에서 더 안정적인 실행이 필요할 수 있기 때문이다.

Figure 5: 8B scale에서 OpenThoughts-Agent 데이터 레시피의 scaling

Figure 5는 8B scale에서도 OpenThoughts-Agent 데이터가 Nemotron-Terminal-Corpus baseline과 base Qwen3-8B보다 큰 scale 구간에서 앞서는 모습을 보여 준다. 작은 scale에서는 benchmark별 편차가 남지만, 100K에 가까워질수록 데이터 레시피의 효과가 더 분명해진다. 이 그림은 32B 결과가 단순히 큰 모델 덕분으로만 보기 어렵고, 작은 모델 regime에서도 source/filtering 조합이 작동한다는 보조 증거로 읽을 수 있다.

6. 추가 분석 및 Ablation Study: 어떤 선택이 실제로 agent behavior를 바꾸는가

6.1 task source ranking의 뾰족한 효과

95개 task generation strategy ranking에서 상위 source들은 서로 다른 benchmark를 밀어 올린다. SWE-Smith는 SWE-Bench Verified (100) 32.33으로 가장 강하지만 Terminal-Bench 2.0은 6.37이다. StackExchange SuperUser는 SWE-Bench 쪽은 13.33으로 낮지만 Terminal-Bench 2.0은 10.86으로 높다. StackExchange Tezos도 Terminal-Bench 쪽에 도움이 되고, IssueTasks는 SWE-Bench와 평균 사이에서 균형을 만든다. 이 “spiky improvement”가 top-4 mixing을 정당화한다.

이 관찰은 데이터 selection을 benchmark 평균 최적화 문제로 바꾼다. source마다 latent skill coverage가 다르면, 단일 ranking의 1위만 고르는 것은 평균 최적화가 아니다. 코딩 repository, infrastructure Q&A, blockchain/Tezos operational task, issue resolution은 모두 tool-use를 요구하지만 실패 양상이 다르다. 모델이 다양한 실패 양상에 노출될수록, 특정 harness의 prompt convention에만 맞춘 행동보다 범용적인 diagnose-act-verify loop를 배울 가능성이 커진다.

6.2 augmentation이 실패한 이유

task augmentation이 기대만큼 작동하지 않은 이유는 두 가지로 볼 수 있다. 첫째, task description을 어렵게 쓰거나 constraint를 추가해도 underlying environment가 달라지지 않으면 agent가 배워야 할 실제 행동은 크게 변하지 않는다. 둘째, LLM이 만든 augmented task는 요구사항이 더 길어지면서 ambiguity나 artificial constraint를 늘릴 수 있다. 그러면 teacher rollout은 더 복잡해 보이지만, downstream benchmark에 필요한 tool-use skill과는 거리가 생긴다.

논문이 augmentation을 완전히 부정하는 것은 아니다. synthetic task augmentation은 scale-up 단계에서 효과를 보인다. 차이는 augmentation의 위치다. 개별 task를 “더 어렵게” 만드는 intervention은 noise가 컸지만, source diversity bottleneck을 풀기 위해 Tezos의 surface form을 넓히는 방식은 유용했다. 즉 augmentation은 품질을 올리는 만능 도구라기보다, 특정 source의 unique task 부족을 보완하는 수단으로 더 잘 작동한다.

6.3 teacher model이 학생에게 남기는 trace distribution

teacher ablation에서 GPT-5.3-Codex가 낮게 나온 것은 성능 좋은 모델을 teacher로 쓰면 된다는 직관을 깨뜨린다. SFT는 teacher의 정답 여부를 넘어, 문제를 어떻게 분해하고 어떤 순서로 tool을 부르며 어디서 멈추는지까지 모방한다. 강한 teacher가 너무 짧은 경로로 풀거나, 학생이 재현하기 어려운 implicit reasoning에 의존하거나, 특정 evaluator에 최적화된 형식을 사용하면 학생 모델에는 덜 유용한 supervision이 될 수 있다.

이 결과는 model distillation의 일반 교훈과 닿아 있다. teacher가 높은 capability를 갖는 것과 teachability가 높은 것은 다르다. OpenThoughts-Agent는 이 차이를 agentic data에서 보여 준다. GLM 4.7 AWQ는 benchmark 최강 모델은 아니지만, downstream agent SFT에는 더 적절한 trace distribution을 만들었다. 실무적으로는 teacher를 고를 때 raw benchmark score만 보지 말고, trace 길이, tool error recovery, self-correction, termination behavior까지 sample audit해야 한다는 뜻이다.

6.4 min-turn filter와 multi-turn supervision

min turns $\geq 5$ 필터는 이 논문의 가장 실용적인 규칙 중 하나다. agentic trace가 너무 짧으면 task가 쉬웠거나 teacher가 충분한 environment interaction을 남기지 않았을 수 있다. 반대로 너무 긴 trace는 timeout이나 loop를 포함할 수 있다. 저자들이 사용한 필터는 짧은 trace를 제거하되, timeout이나 subagent trace 제거보다 더 강한 평균 성능을 낸다. 이는 agent 모델이 실제로 배워야 하는 것이 단일 action보다 multi-turn loop라는 점을 강조한다.

matched token budget control에서도 min-turn filtering이 random subsample보다 좋다는 결과는 특히 중요하다. 더 긴 trace를 고르면 token 수가 늘어나므로 성능 개선이 단순 compute 증가 때문일 수 있다. 저자들은 약 145M token으로 맞춘 비교에서 min-turn filtered subset이 SWE-Bench Verified-100과 Terminal-Bench 2.0에서 여전히 앞선다고 보고한다. 이 control은 multi-turn 구조 자체가 정보량을 갖는다는 해석을 강화한다.

6.5 RL source ablation과 행동 변화

RL 실험에서는 source별 차이가 7.6 point raw average 범위로 나타난다. pymethods2test가 가장 강하고, r2egym, nemotron-code-oracle, llm-verifier-freelancer가 뒤따른다. pymethods2test는 competitive programming 문제를 single-function Python contract와 unittest suite로 재구성한 source다. multi-file repository navigation은 없지만, dynamic programming, string matching, combinatorics, grid construction 같은 문제 해결 패턴을 명확한 test feedback과 함께 제공한다. 이 source는 cold-start model에게 compact explore-patch-submit policy를 학습시키기 좋다.

RL Data Source	SWE-Bench Verified (100)	OT-TBLite	Terminal-Bench 2.0	Raw Avg	Normalized
pymethods2test	35.67 ± 1.83	16.02 ± 1.58	13.48 ± 1.50	21.72	+1.73
r2egym	28.67 ± 1.67	16.84 ± 1.64	6.74 ± 1.45	17.42	+0.50
nemotron-code-oracle	25.00 ± 1.86	16.78 ± 1.67	6.74 ± 1.24	16.17	+0.22
llm-verifier-freelancer	22.33 ± 1.53	14.87 ± 1.27	8.61 ± 1.35	15.27	-0.24
nl2bash	21.00 ± 1.49	14.51 ± 1.44	6.74 ± 1.12	14.08	-0.70

여기서 source effect는 SFT source effect보다 작지만, run-to-run variance보다는 크다. 저자들은 RL source가 정책의 행동 압력을 바꾼다고 분석한다. pymethods2test는 reward ceiling이 중간 수준이고 포화되지 않아 더 많이 탐색하고 수정하게 만든다. llm-verifier-freelancer는 반대로 불필요한 looping을 줄이며 compact하게 만든다. 같은 RLOO algorithm이라도 source가 다르면 “좋은 행동”의 방향이 달라지는 셈이다.

Figure 6: pymethods2test hero RL run의 reward 상승과 collapse

Figure 6은 pymethods2test hero run에서 reward가 약 0.51 부근까지 오르다가 후반에 약 0.13으로 무너지는 패턴을 보여 준다. 저자들은 이를 reward hacking보다 과도한 exploration pressure로 해석한다. tool call과 thinking이 늘어 처음에는 held-out SWE-Bench reward를 올리지만, 끝까지 밀면 timeout과 과잉 탐색이 증가한다. 이 그림은 agentic RL에서 checkpoint selection과 early stopping이 성능만큼 중요한 운영 변수임을 보여 준다.

Figure 7: llm-verifier-freelancer RL run의 단조적 reward 상승

Figure 7은 같은 RL pipeline이 llm-verifier-freelancer source에서는 전혀 다른 행동 변화를 만든다는 대조군이다. reward가 더 매끄럽게 오르고 collapse가 보이지 않으며, 정책은 turn 수와 think token을 줄이는 compact 방향으로 이동한다. 따라서 agentic RL의 핵심 질문은 algorithm 하나 선택에 그치지 않고, source가 어떤 행동 압력을 만드는지 읽는 것이다. OpenThoughts-Agent는 이 점을 reward curve와 trace-level behavior 지표로 함께 보여 준다.

Figure 8: hero run의 시간 구간별 행동 지표 변화

Figure 8은 reward, error rate, parse error, premature stop, tool call, self-correction, think token 같은 지표가 시간에 따라 어떻게 움직이는지 묶어 보여 준다. 후반부에는 평균 대화 길이와 내부 reasoning이 크게 증가하는 반면 productive tool use는 줄고 timeout이 늘어난다. 이 패널은 단순 score curve만으로는 보이지 않는 정책 행동의 질적 변화를 드러내며, agent training에서 trajectory telemetry가 필수라는 점을 다시 확인시킨다.

6.6 데이터 레시피를 운영 파이프라인으로 읽는 방법

논문을 실제 데이터 구축 절차로 옮기면, 여섯 단계는 각각 별도 dashboard 지표가 된다. task source coverage는 source별 domain, environment, verifier 종류를 기록하고, source mixing은 benchmark 평균만 보지 않고 source가 만드는 실패 유형을 함께 추적해야 한다. task filtering은 response length 같은 proxy에서 출발하되, verification 가능성, side-effect 위험, task ambiguity를 함께 보아야 한다. teacher selection은 raw score보다 trace distribution audit로 결정하고, rollout filtering은 timeout 제거와 최소 turn 수 외에 recovery pattern을 반영해야 한다.

특히 agentic data에서는 trace schema가 품질 관리의 중심이 된다. 하나의 예시는 자연어 instruction, environment snapshot, tool call sequence, observation, intermediate reasoning, final answer, verifier result를 포함한다. 이 중 어느 하나가 빠지면 후속 연구자가 같은 trace를 재평가하거나 다른 model family에 다시 학습시키기 어렵다. OpenThoughts-Agent가 공개한 pipeline은 source와 실험 데이터를 함께 내놓는다는 점에서 좋지만, 앞으로는 각 trace가 어떤 environment version과 어떤 verifier commit에서 만들어졌는지까지 더 세밀하게 남기는 방향이 필요하다.

이런 관점에서 min-turn filtering은 단순한 길이 필터 이상의 의미가 있다. 다섯 turn 이상이라는 조건은 agent가 최소한 관찰, 계획, 실행, 검증, 수정의 일부 loop를 경험했다는 약한 보증으로 작동한다. 하지만 실제 운영에서는 turn 수만으로 충분하지 않다. 동일한 다섯 turn이라도 하나는 실패 후 재시도를 거쳐 성공한 trace이고, 다른 하나는 같은 명령을 반복하다가 우연히 통과한 trace일 수 있다. 따라서 다음 세대 레시피는 recovery-aware filtering, verification-aware sampling, side-effect-aware labeling으로 더 세분화될 가능성이 높다.

teacher model을 고르는 문제도 같은 방식으로 확장된다. 논문은 GLM 4.7 AWQ가 GPT-5.3-Codex보다 좋은 teacher가 될 수 있음을 보였지만, 왜 그런 trace가 학생에게 더 잘 맞는지는 더 많은 telemetry가 필요하다. 예를 들어 teacher가 실패를 얼마나 빨리 인정하는지, tool error 뒤 argument를 어떻게 수정하는지, 불확실한 상태에서 추가 파일을 읽는지, test failure를 patch hypothesis로 연결하는지 같은 지표를 뽑을 수 있다. 그러면 teacher selection은 benchmark leaderboard 선택을 넘어 teaching behavior selection 문제가 된다.

또한 이 논문은 데이터와 평가의 경계가 agent 연구에서 얼마나 흐려질 수 있는지도 보여 준다. SERA처럼 특정 harness가 데이터 생성과 평가 양쪽에 걸쳐 있으면, 모델이 실제 skill을 배웠는지 harness convention을 익혔는지 분리하기 어렵다. OpenThoughts-Agent는 Terminus-2와 원래 harness를 함께 보고하는 방식으로 이를 완화하지만, 더 근본적인 방법은 cross-harness evaluation, held-out environment family, trace provenance audit를 표준화하는 것이다. agent 데이터셋이 커질수록 benchmark contamination은 문자열 중복보다 environment와 verifier 중복의 문제로 바뀐다.

32B SFT 결과를 해석할 때도 benchmark average와 capability profile을 분리해야 한다. 평균 44.8%는 강력한 요약 지표지만, 실제 채택 결정에서는 SWE-Bench, Terminal-Bench, BFCL, FinanceAgent가 모두 같은 가중치를 갖지 않는다. 금융 workflow에 배포할 모델이라면 FinanceAgent-Terminal의 44.0이 중요하고, coding assistant라면 SWE-Bench Verified 54.0과 Aider-Polyglot 32.4가 더 중요하다. 이 논문은 평균을 통해 broad data recipe의 가치를 보여 주지만, 운영자는 자신의 task distribution에 맞춰 source mix를 다시 최적화해야 한다.

RL 분석에서 가장 배울 만한 점은 reward curve와 behavior telemetry를 함께 봐야 한다는 것이다. pymethods2test hero run은 초반에는 더 많은 thinking과 tool call이 도움이 되지만, 후반에는 timeout이 늘며 collapse한다. 단일 reward scalar만 보면 어느 checkpoint가 왜 위험해지는지 알기 어렵다. Figure 8처럼 turn 수, assistant message length, self-correction, tool error, premature stop을 같이 보면 policy가 문제 해결을 깊게 하는지, 또는 생산적 도구 사용을 잃고 내부 reasoning으로 도피하는지 구분할 수 있다.

이 지점은 agent observability와도 연결된다. 학습 중 telemetry를 모으지 않으면, 나중에 모델이 왜 특정 task에서 실패하는지 설명하기 어렵다. Shepherd가 실행 trace를 fork/replay 가능한 기판으로 만들자는 아이디어였다면, OpenThoughts-Agent의 RL 분석은 그런 trace가 학습 중 policy drift를 감지하는 계측 장치가 될 수 있음을 보여 준다. 장기적으로는 training pipeline이 evaluation harness와 분리된 별도 trajectory analytics layer를 가져야 한다.

마지막으로, 공개 레시피의 가장 큰 장점은 후속 연구자가 작은 변형을 실험할 수 있게 만든다는 점이다. 예를 들어 top-4 source mix에 GUI benchmark source를 하나 추가하거나, min-turn filter 대신 verification-repair filter를 넣거나, GLM teacher와 다른 teacher를 source별로 다르게 배치하는 실험을 설계할 수 있다. 논문이 모든 답을 주지는 않지만, data ablation template을 남긴다. 공개 agent 연구에서는 이 템플릿 자체가 모델 checkpoint 못지않게 중요한 산출물이다.

7. 한계점 및 향후 연구 방향: 공개 레시피가 남긴 검증 과제

첫 번째 한계는 RL 분석이 8B scale에 머문다는 점이다. 논문은 compute 제약 때문에 32B regime에서 같은 RL recipe가 전이되는지 확인하지 못했다고 밝힌다. 8B에서 pymethods2test가 강한 source였고 SFT+RL 조합이 평균을 끌어올렸지만, 32B에서는 base capability, teacher trace 흡수 방식, exploration budget, timeout behavior가 다를 수 있다. 특히 큰 모델은 더 긴 context와 더 안정적인 tool use를 갖기 때문에 같은 reward가 더 compact한 policy를 만들 수도 있다.

두 번째 한계는 base model ablation이 없다는 점이다. SFT 실험은 Qwen3 family에서 출발한다. 따라서 OpenThoughts-Agent 데이터가 Llama, DeepSeek, GLM, Mistral 계열에서 같은 상대 이득을 보이는지 알 수 없다. 데이터 레시피가 정말 범용인지 보려면 base model의 pretraining mixture, chat template, tool-use prior, long-context behavior가 다른 모델군으로 옮겨도 source/filtering conclusion이 유지되는지 확인해야 한다.

세 번째 한계는 dataset scale의 상한이다. 가장 큰 SFT set은 100K trajectory다. 논문은 100K에서 좋은 성능과 scaling property를 보였지만, million-scale trajectory regime에서는 source diversity bottleneck, synthetic augmentation 품질, teacher cost, contamination risk가 다시 바뀔 수 있다. 특히 같은 source를 대량 확장할 때 verification script와 benchmark distribution이 겹치면 점수는 오르지만 일반화가 덜 오르는 상황이 생길 수 있다.

네 번째 한계는 benchmark suite의 대표성이다. 일곱 benchmark는 넓지만, 여전히 agentic task 전체를 대표하지 않는다. GUI agent, web browsing, multi-agent collaboration, security-sensitive operations, long-running enterprise workflow, memory-augmented personal assistant는 평가 범위 밖에 가깝다. 최근 리뷰한 VISUALSKILL이나 MobileGym 계열과 비교하면, OpenThoughts-Agent는 terminal/code/tool benchmark에 더 무게가 있다. 따라서 컴퓨터 사용 전반으로 확장하려면 시각 관찰, 브라우저 상태, 사용자 개입, 장기 memory ledger를 포함한 데이터 source가 추가되어야 한다.

향후 연구 방향은 크게 세 가지다. 첫째, SFT pipeline의 각 단계가 다른 base model과 다른 harness에서도 유지되는지 보는 cross-family replication이 필요하다. 둘째, RL source가 행동을 “탐색 확대” 또는 “trace compacting”으로 밀어내는 조건을 이론적·실험적으로 분리해야 한다. 셋째, 공개 데이터셋에 trace telemetry schema를 붙여서 turn 수, tool error, verification retry, premature stop, timeout 같은 지표를 재사용 가능하게 만들어야 한다. 이 세 가지가 붙으면 OpenThoughts-Agent는 단일 dataset보다 agent training data science의 출발점에 가까워진다.

한계점에서 추가로 보아야 할 축은 data contamination이다. 저자들은 open data와 benchmark를 폭넓게 다루지만, agent task에서는 전통적인 문장 중복보다 더 복잡한 누수가 생긴다. 동일한 repository, 동일한 test harness, 동일한 shell puzzle family가 task description만 바뀐 채 학습과 평가 양쪽에 존재할 수 있다. 이 경우 모델은 추상적인 문제 해결 능력을 배운 것처럼 보이지만, 실제로는 environment convention과 verifier pattern을 익혔을 수 있다. 후속 연구에서는 benchmark item의 문자열 중복뿐 아니라 repository lineage, dependency graph, unit test motif, command template까지 묶은 environment-level deduplication이 필요하다.

또 다른 과제는 cost-aware training이다. 논문은 24×GH200, 24×A100 같은 대규모 compute 조건을 꽤 투명하게 제시하지만, downstream 사용자가 같은 pipeline을 그대로 재현하기는 쉽지 않다. 따라서 공개 레시피가 더 넓게 쓰이려면 source ranking과 filtering 결론이 작은 compute budget에서도 유지되는지 확인해야 한다. 예를 들어 1K, 3.16K, 10K scale에서 어떤 source가 가장 비용 대비 효율적인지, teacher model을 더 저렴한 모델로 바꿨을 때 어떤 filtering이 보완 역할을 하는지, trace 길이를 줄이면 어떤 benchmark가 먼저 무너지는지 같은 분석이 필요하다.

마지막으로 human-in-the-loop evaluation이 빠져 있다. agentic model은 자동 verifier가 있는 과제에서 빠르게 발전하지만, 실제 업무에서는 verifier가 불완전한 경우가 많다. 모델이 patch를 만들었지만 유지보수성이 떨어지거나, shell command가 성공했지만 보안 정책을 어겼거나, finance workflow가 결과적으로 맞아도 설명 책임을 충족하지 못하는 경우가 있다. OpenThoughts-Agent의 레시피에 human audit sample을 일부 섞고, 그 audit 결과를 task source와 rollout filter의 선택 기준으로 되돌리는 실험을 붙이면 benchmark 평균과 운영 신뢰도 사이의 간극을 더 잘 줄일 수 있다.

이 논문을 재현하려는 팀은 먼저 작은 ablation matrix부터 만드는 편이 현실적이다. 예를 들어 source 세 개, teacher 두 개, rollout filter 세 개만 조합해도 18개 실험이 생긴다. 여기서 각 실험의 최종 점수만 저장하면 다음 반복에서 무엇을 바꿔야 할지 알기 어렵다. source별 성공률, trace length distribution, tool error rate, verification retry count를 함께 남기면, 작은 budget에서도 OpenThoughts-Agent식 데이터 과학을 재현할 수 있다. 그런 로그가 쌓이면 100K 규모 확장 전에 어떤 source를 버리고 어떤 source를 더 키울지 훨씬 명확해진다.

8. 내 해석: 데이터 레시피는 공개됐지만, 운영 안전성의 축은 아직 덜 보인다

나는 이 논문의 가장 큰 장점을 “에이전트 학습 데이터의 공정표를 공개했다”는 데서 본다. 모델 성능 숫자도 중요하지만, task source를 95개로 펼쳐 ranking하고, top-N mixing과 filtering, teacher, rollout filter를 차례로 흔든 구성 자체가 더 가치 있다. Shepherd가 agent 실행 trace를 학습 가능한 객체로 만들자는 쪽이었다면, OpenThoughts-Agent는 그 trace 중 어떤 것을 SFT 데이터로 남길지에 답하려는 쪽이다. 또 ExpRL이 reasoning RL에서 탐색 행동을 키우는 보상을 다뤘다면, 이 논문은 agentic RL에서 source가 탐색을 키우기도 하고 줄이기도 한다는 사실을 더 구체적인 telemetry로 보여 준다.

다만 내가 걸리는 약점은 운영 실패 비용이 benchmark 평균 속에 너무 쉽게 섞인다는 점이다. 논문은 timeout, tool error, reward collapse, premature stop을 일부 분석하지만, 최종 32B 평가표는 여전히 accuracy 평균 중심이다. 실제 agent product에서는 한 번의 잘못된 shell command, 잘못된 금융 workflow, 의료 task의 잘못된 도구 호출이 평균 점수보다 더 중요할 수 있다. 특히 OpenThinkerAgent-32B가 broad benchmark 평균에서 강하다는 사실만으로, 고위험 workflow에서 안전한 trace distribution을 갖는다고 결론내리기는 어렵다. 이 논문의 데이터 레시피는 능력 향상에는 설득력이 있지만, 실패 비용을 반영한 data selection 기준은 아직 약하다.

내가 이 연구를 확장한다면, 다음 단계로 risk-weighted trajectory filtering을 붙여 보고 싶다. 현재 min-turn filter는 multi-turn supervision을 잘 보존하지만, 모든 긴 trace가 같은 가치를 갖지는 않는다. 예를 들어 tool error를 낸 뒤 즉시 복구한 trace, 잘못된 가설을 오래 붙잡다가 검증으로 되돌린 trace, 위험한 command를 실행하기 전에 dry-run이나 confirmation step을 넣은 trace는 서로 다른 안전 신호를 담는다. Agent Premature Commitment에서 본 조기 확신 문제와 연결하면, 단순 최소 turn 수 대신 “가설 고정 이후 반증 슬롯이 있었는가”, “검증 실패 후 계획을 수정했는가”, “side-effect 있는 action 전에 evidence를 충분히 모았는가” 같은 필터를 만들 수 있다.

또 하나의 확장은 benchmark별 성공률보다 trace provenance와 human audit 위치를 dataset metadata로 붙이는 것이다. OpenThoughts-Agent는 공개 데이터셋과 pipeline을 내놓았지만, 어떤 trace가 사람 검수에 더 적합한지, 어떤 trace가 자동 verifier만으로 충분한지, 어떤 trace가 운영 중 replay 가능한지까지는 깊게 다루지 않는다. 내가 장기 agent 플랫폼에 이 레시피를 쓴다면, 학습 데이터 각 예시에 environment snapshot, verifier 종류, side-effect class, recoverability tag, human approval need를 붙이고, SFT/RL 단계에서 이런 tag가 행동에 어떤 영향을 주는지 따로 ablate할 것 같다. 그러면 능력 데이터 레시피가 안전·운영 데이터 레시피로 확장된다.

9. 결론: agentic model의 성능은 데이터 공정의 함수다

OpenThoughts-Agent는 agentic model 연구에서 자주 흐릿하게 처리되던 training data 공정을 논문 본문으로 끌어올린다. task source, mixing, augmentation, filtering, teacher, rollout filtering을 분리하고, 100회 이상의 ablation으로 각 선택의 효과를 보여 준다. 최종적으로 100K OpenThoughts-Agent-v2 데이터로 fine-tune한 OpenThinkerAgent-32B가 일곱 benchmark 평균 44.8%를 기록하고, strongest existing open-data 32B agentic model로 제시된 Nemotron-Terminal-32B를 평균 3.9 point 앞선다는 결과를 제시한다.

이 논문의 실용적 메시지는 세 가지로 압축된다. 첫째, task source 선택이 매우 크다. 둘째, source diversity는 필요하지만 무작정 넓히면 품질이 떨어질 수 있다. 셋째, agentic trace는 길이와 행동 구조가 중요하며, min-turn filtering처럼 단순한 규칙도 downstream 성능을 크게 바꾼다. 이 메시지는 연구실 benchmark와 실제 agent data pipeline 모두에 바로 옮겨갈 수 있다. 좋은 agent 모델을 만들려면 모델 크기와 RL algorithm만 보는 수준을 넘어, task description과 trajectory가 어떤 행동 습관을 주입하는지 계속 측정해야 한다.

논문은 동시에 조심할 점도 남긴다. RL 결과는 8B scale에 제한되어 있고, base model family도 Qwen3 중심이며, benchmark 평균이 운영 실패 비용을 충분히 반영하지는 않는다. 그럼에도 공개 데이터셋, pipeline, experimental data, model release를 통해 후속 연구가 재현 가능한 출발점을 얻는다는 점에서 의미가 크다. agentic AI가 점점 더 실제 업무 환경으로 들어가는 상황에서, “데이터 레시피”를 공개 가능한 과학으로 만드는 작업은 모델 아키텍처 개선만큼 중요해지고 있다.

10. 요약 정리: OpenThoughts-Agent가 남긴 핵심 포인트

• OpenThoughts-Agent는 범용 agentic model을 위한 SFT 데이터 레시피를 공개하고, task source부터 rollout filtering까지 여섯 단계를 ablation한 논문이다.
• 최종 OpenThinkerAgent-32B는 일곱 개 agent benchmark 평균 44.8%를 기록해 Nemotron-Terminal-32B의 40.9%보다 3.9 percentage point 높다고 보고된다.
• 95개 task generation strategy ranking에서 source 선택 효과가 매우 컸고, SWE-Smith, StackExchange SuperUser, StackExchange Tezos, IssueTasks가 최종 top-4 mix의 핵심 source가 된다.
• Top-1 source만 크게 쓰면 특정 benchmark에는 강하지만 평균 성능이 흔들리고, Top-4 또는 Top-8 수준의 균형 있는 mixing이 더 안정적인 agentic behavior를 만든다.
• task description augmentation은 대체로 original baseline을 안정적으로 넘지 못했지만, source diversity 병목을 풀기 위한 synthetic task augmentation은 scale-up 단계에서 효과를 보였다.
• teacher model은 raw benchmark score가 높다고 반드시 좋은 teacher가 되지는 않았고, GLM 4.7 AWQ가 GPT-5.3-Codex보다 downstream SFT teacher로 더 유리하게 나타났다.
• rollout filtering에서는 min turns $\geq 5$ 규칙이 timeout 제거나 subagent trace 제거보다 강했고, matched token budget control에서도 multi-turn supervision의 이득이 유지됐다.
• 8B RL 실험은 source가 정책 행동을 다르게 만든다는 점을 보여 준다. pymethods2test는 탐색을 키우다 collapse 위험을 만들고, llm-verifier-freelancer는 trace를 compact하게 만든다.
• 이전에 본 Shepherd, ExpRL, Agent Premature Commitment 흐름과 연결하면, 이 논문은 agent trace를 어떻게 남기고 어떤 trace를 학습 데이터로 선택할지에 대한 실용적 답안으로 읽힌다.
• 남은 과제는 32B 이상에서의 RL 전이, Qwen3 외 base model replication, 운영 실패 비용을 반영한 risk-weighted trajectory filtering, trace provenance metadata 확장이다.