연재 「프롬프트로 읽어내는 AI 에이전트」 제9회 (제7장).

실재하는 3가지 AI 에이전트 OSS를 실제 코드와 실제 프롬프트를 원전에서 인용하며 읽어내고,

최종적으로 「스스로 AI 에이전트를 만들 수 있는」 상태를 목표로 하는 연재입니다.

본 기사부터 제2부에 들어갑니다. 제1부까지의 읽는 법은 일단 잠시 접어두어 주세요.

이 장은 읽는 법이 달라집니다

제1장에서 제6.5장까지의 제1부를 통독해 온 독자에게는, 여기서 한 번 사고의 틀을 전환해야 합니다. 지금까지 읽어온 agent-zero와 Hermes는 모두 실행형 (Execution-type) 에이전트였습니다. LLM의 가중치 (Weights, 모델이 훈련 결과로서 내부에 가지고 있는 방대한 수치 파라미터. 제0장에서 정의)는 그대로 고정한 채, 추론 시 (Inference time) 에 「생각한다 → 도구를 사용한다 → 관찰한다」의 루프를 돌리며, 프롬프트와 도구 및 루프 설계의 궁리로 태스크를 해결하게 한다 ―― 이것이 제1부에서 구축한 골격입니다.

본 장부터 시작되는 제2부는 완전히 다른 세계입니다. 다루는 것은 Agent0 (aiming-lab/Agent0 @ 30e1882). Agent0는 제1부에서 읽었던 agent-zero / Hermes와 용도도, 결과물도, 읽는 법도 모두 다릅니다.

Agent0는 「사용하면 동작하는 애플리케이션」이 아닙니다.

Agent0가 중심에 두는 질문은 「주어진 태스크를 LLM과 툴로 어떻게 해결할 것인가」가 아니라, 「LLM의 가중치 그 자체를 어떻게 다시 써서 추론 능력을 끌어올릴 것인가」입니다. Agent0가 만들어내는 결과물은 동작하는 에이전트 제품이 아니라, 훈련된 가중치의 체크포인트 (Checkpoint)입니다.

제1부에서 몇 번이고 반복했던 「같은 단어가 다른 일을 하고 있다」라는 대사가 여기서 구체적인 형태를 띱니다. 제1부의 에이전트는 「LLM + 프롬프트 + 툴 + 루프」의 합성체였습니다. 제2부의 Agent0에서의 에이전트는, 강화학습 (Reinforcement Learning)의 주체 (행동을 취하고, 보상을 받으며, 자신의 파라미터를 업데이트하는 주체)입니다. 전자는 추론 시에 움직이고, 후자는 훈련 시 (Training time) 에 움직입니다.

이 패러다임 전환을 독자의 머릿속에서 완료시키는 것이 제7장의 임무입니다. 본 장에서는 다음 세 가지를 순차적으로 전달합니다.

• 제1부와 제2부에서 프롬프트가 담당하는 역할이 어떻게 변하는가
• 왜 「행동을 기술하는 것」이 아니라 「가중치를 학습시키는」 길을 선택하는가 ―― Agent0가 내세우는 동기
• 그 별도의 해법의 적용 조건 (어떤 태스크에서 성립하고, 어떤 태스크에서는 성립하지 않는가)

제8장에서는 Agent0의 핵심 ―― 출제자 역할 (Curriculum Agent)과 해답자 역할 (Executor Agent)의 공진화와 「프롬프트로 보상을 만드는」 사고방식 ―― 을, 제9장에서는 학습 알고리즘 (GRPO / ADPO)과 자기 라벨링 (Self-labeling) 메커니즘을 다룹니다. 본 장은 그 입구입니다.

제1부까지의 읽는 법을 의식적으로 리셋하기

제1부에서 읽어낸 실행형 에이전트의 심장부는 Reason → Act → Observe 루프였습니다 (제1장). 의사 코드 (Pseudo code)로 말하자면 다음과 같은 형태입니다.

# 실행형 에이전트의 심장부 (제1장에서 독자가 쓸 수 있게 된 골격)
history = [SYSTEM_PROMPT, user_input]
for _ in range(MAX_ITERATIONS):
...

이 루프 안에서 LLM의 가중치는 단 1비트도 움직이지 않습니다. 똑똑함의 원천은 시스템 프롬프트 (제2장), 툴의 정의와 제시 (제3장), 영속 메모리 (제4장), 서브 에이전트와 kanban을 통한 분업 (제5장), 그리고 자기 개선과 샌드박스 (제6장) 및 외부 접속 (제6.5장)이었습니다. 이것들은 모두 모델의 외부를 설계하는 행위입니다. 제6장에서 확인했듯이, 실행형의 「자기 개선」조차도 가중치 업데이트가 아니라, 시스템 프롬프트에 실리는 텍스트 (메모리 · 스킬 · 행동 규칙)의 교체에 머무릅니다.

「실행형의 자기 개선은 모델의 가중치가 아니라 외부 텍스트 (메모리 · 스킬 · 행동 규칙)의 교체. 가중치는 1비트도 움직이지 않는다.」

―― 본 연재 제7회 (제6장) 요약으로부터

제7장부터는 이 동일한 「자기 개선」 「진화」라는 단어가, 모델의 가중치를 직접 다시 쓰는 근본적으로 다른 메커니즘을 가리키게 됩니다.

프롬프트의 역할이 변한다

실행형에서의 프롬프트의 역할을 제6장까지 한 문장으로 압축하면 다음과 같았습니다.

• 제1부의 프롬프트: 추론(Inference) 시 LLM에 전달하는 지시문. 인격·행동 규범·도구 목록·응답 계약을 정의하며, 고정된 가중치(Weights)의 "사용법"을 그 자리에서 구성한다.

제2부의 Agent0에서 프롬프트가 담당하는 역할은 여기서 벗어납니다.

제2부의 프롬프트: 훈련(Training) 시 각 롤아웃(Rollout, 모델이 LLM을 한 번 호출하여 출력을 생성하는 단위)에서 입력으로 주어지는 문맥이며, 그 출력에 **보상을 측정하기 위한 포맷 계약(Format Contract)**을 심어두는 장치. 학습 대상은 출력 그 자체가 아니라, 그 출력을 만들어내는 모델의 가중치(Weights).

실례를 Agent0 내부에서 하나만 미리 살펴보겠습니다. Agent0의 커리큘럼 에이전트(Curriculum Agent, 출제 역할)가 "수학 문제 1개를 만든다"는 훈련을 받을 때, 주어지는 시스템 프롬프트는 다음과 같은 형태를 띱니다.

{
"role": "system",
"content": (
...

―― Agent0/curriculum_train/verl/utils/dataset.py

@ 30e1882

, L170-186 (훈련 시 롤아웃용 시스템 프롬프트. 동일한 문구는 데이터 큐레이션(Data Curation)용 Agent0/curriculum_train/question_generate/question_generate.py @ 30e1882, L62-74에도 존재하며, 훈련 후의 문제 생성 배치(Batch)에서 재사용됨)

실행형의 "당신은 agent zero autonomous json ai agent" (제2장에서 본 역할 정의)와 표면적으로는 비슷합니다. 하지만 그 역할이 다릅니다. <question>...</question>과 \boxed{final_answer}라는 출력 계약이, 후속 단계의 "이 출력을 채점하는 보상 함수(Reward Function)"와 맞물리기 위해 배치되어 있다는 것이 제2부 프롬프트의 해석 방식입니다. 실제 채점 측은 별도의 파일에서 출력을

<question>

과 \boxed{}

로 정규 표현식(Regular Expression) 추출하여, 다른 정답 역할 모델에게 풀게 하여 스코어를 산출하고 이를 보상으로 변환합니다.

questions = re.findall(r"<question>(.*?)</question>", predicts[i], re.DOTALL)
answers = extract_boxed_content(predicts[i])
if questions and answers:
...

―― Agent0/curriculum_train/examples/reward_function/curriculum_reward.py

@ 30e1882

, L132-143

프롬프트에 적힌 <question> 태그와 \boxed{}가 그대로 보상 함수의 re.findall(r"<question>(.*?)</question>", ...)와 extract_boxed_content(...)를 통해 추출된다 ―― 이것이 "프롬프트로 보상을 만든다"의 가장 소박한 발현입니다. 제1부의 "응답 계약" (agent-zero의 tool_name JSON 등)이 루프의 디스패치(Dispatch)에 사용되는 것과 달리, 제2부의 "응답 계약"은 보상의 자동 채점에 사용됩니다. 같은 "계약"이라는 단어가 서로 다른 일을 하고 있는 것입니다.

자세한 내용은 제8장에서 다룹니다. 본 장에서는 이 사례를 "프롬프트가 담당하는 역할이 변한다"는 증거로 머릿속에 담아두시기 바랍니다.

Agent0를 "실행 에이전트"로 읽지 않기 위해서

제0장에서 예고한 대로, 제2부를 읽을 때 가장 큰 함정은 agent-zero와 Agent0의 이름이 혼동하기 쉽다는 점입니다. agent-zero (하이픈 포함, agent0ai/agent-zero)는 실행형·범용이며, Agent0 (숫자 0, aiming-lab/Agent0)는 학습형·연구용입니다. 본 장 이후로 Agent0라고 쓸 때는 항상 후자를 지칭합니다.

덧붙여, Agent0의 리포지토리 내부에도 Executor Agent라는 이름의 역할이 등장합니다. 이것은 제1부에서 말하는 "실행 에이전트"와는 별개의 것입니다. Agent0의 Executor Agent는 훈련의 소재로서 등장하는 모델 ―― 출제 역할이 만든 문제를 풀려고 시도하는 정답 역할 ―― 이며, 사용자가 대화하며 사용하는 제품이 아닙니다. Agent0의 README가 서두에서 밝히고 있는 바와 같습니다.

Agent0는 인간이 큐레이션한 데이터에 의존하지 않고, 처음부터 고성능 에이전트를 진화시키는 완전 자율 프레임워크입니다. 이는 과제를 제안하는 Curriculum Agent(커리큘럼 에이전트)와 도구를 사용하여 과제를 해결하는 Executor Agent(실행 에이전트) 사이의 공생적 경쟁(symbiotic competition)을 채택하여, 자기 강화적인 개선 사이클을 구동합니다.――

Agent0/README.md

@30e1882

, L9

evolves high-performing agents

―― 핵심은 **진화시킨다(evolve)**는 점입니다. "작동하는 에이전트를 제공하는" 것이 아니라, "고성능 에이전트(=모델)를 진화시키는" 프레임워크입니다. symbiotic competition(공생적 경쟁)이라는 용어 또한, 제1부의 서브 에이전트 호출이나 kanban 위임과는 울림이 다릅니다. 제5장에서 보았던 "부모가 자식을 호출한다"거나 "태스크를 카드로 분해한다"는 것은 단일 세션 내에서의 분업이었지만, Agent0의 공생적 경쟁은 훈련 회차마다 양측을 강력하게 만들어가는 장기적인 반복입니다.

제1부의 읽기 방식을 완전히 접어두고, 지금부터는 다음 세 가지 단어에 주목하여 읽어주시기 바랍니다.

• 가중치 (weights) ―― 움직임의 대상. 실행형에서는 고정되지만, 학습형에서는 업데이트 대상입니다.
• 보상 (reward) ―― 무엇을 "좋은 행동"으로 간주할 것인가에 대한 수치 신호. 실행형에는 등장하지 않는 개념입니다.
• 롤아웃 (rollout) ―― 모델이 1회의 추론으로 생성한 출력 샘플. 훈련의 최소 단위입니다.

왜 "행동을 작성"하는 것이 아니라 "가중치를 학습"시키는가

여기서부터가 본 장의 핵심입니다. 실행형은 잘 작동합니다. 제1부에서 조립한 최소 에이전트도 외부 도구를 추가하면 상당한 업무를 수행합니다. 그럼에도 불구하고 Agent0는 왜 "가중치를 학습시키는" 길을 선택할까요? Agent0 스스로가 내세우는 Key Features(주요 특징)가 그 동기를 말해주고 있습니다.

## 🔥 Key Features
* **Zero Data:** Eliminates dependency on external data or human annotations.
* **Co-Evolution:** Establishes a competition where the curriculum agent creates increasingly difficult tasks and the executor agent learns to solve them.
...

―― Agent0/README.md

@ 30e1882

, L11-15

세 가지 특징이 곧 세 가지 동기입니다. 차례대로 풀어보겠습니다.

동기 ① ―― 제로 데이터로 학습을 시작하기 (Zero Data)

실행형 에이전트의 똑똑함의 원천은 제1부에서 반복해서 보았듯이 "프롬프트·도구·루프의 설계"였습니다. 그 프롬프트에 적는 지식·지시·규범은 인간이 작성합니다. "너는 autonomous json ai agent다" (agent-zero), "never claim success from timeout partial output" (agent-zero 안전 규범), "Write memories as declarative facts, not instructions to yourself." (Hermes) ―― 이 모든 것이 인간의 설계 판단입니다.

학습형으로 전환할 때의 첫 번째 관문은 그 데이터를 어디에서 가져올 것인가입니다. 지도 미세 조정(Supervised Fine-tuning)이라면 문제와 모범 답안의 쌍이, 선호도 학습(Preference Learning)이라면 비교 쌍의 선호 데이터가, 강화학습(RL)이라면 보상을 계산할 근거가 필요합니다. 이것들은 대부분의 경우 인간이 라벨링한 데이터에 의존합니다.

Agent0의 Zero Data는 그러한 의존성을 제거하는 것을 목표로 합니다 ―― Eliminates dependency on external data or human annotations.

（외부 데이터나 인간의 주석에 대한 의존을 제거한다). 인간이 만든 문제집에 의존하지 않고, 훈련 데이터 그 자체를 에이전트 스스로가 만들게 하는 것이 Agent0의 첫 번째 동기입니다. 구현상으로는 출제자(Curriculum Agent)가 문제를 생성하고, 풀이자인(Executor Agent)이 이를 풀려고 시도하며, 두자의 상호작용 자체가 훈련 데이터가 됩니다. 이에 대해서는 제8장에서 상세히 다룹니다.

이는 실행형(Execution-based)의 "프롬프트를 설계하는" 접근 방식으로는 원리적으로 도달할 수 없는 영역입니다. 실행형 에이전트가 "자신의 행동을 개선할" 때 다시 쓰는 것은 외부 텍스트(제6장)였지만, 그 외부 텍스트를 쓰는 방법 그 자체는 인간이 결정해 왔습니다. Agent0는 "텍스트를 쓰는 방법"보다 더 깊은 층 ―― 모델의 내부 표현(Internal Representation) ―― 에 손을 댐으로써, 인간의 주석 없는 자기 개선을 목표로 합니다.

동기 ② ―― 공진화로 난이도를 계속해서 높임 (Co-Evolution)

두 번째 Key Feature는 Co-Evolution (공진화)입니다. 설명은 한 줄뿐이지만, 설계 판단의 무게가 여기에 응축되어 있습니다.

Establishes a competition where the curriculum agent creates increasingly difficult tasks and the executor agent learns to solve them.

――

Agent0/README.md

@30e1882

, L14

increasingly difficult tasks (점점 더 어려워지는 과제)가 핵심입니다. 실행형 에이전트를 똑똑하게 만들기 위한 노력의 대부분은, "더 좋은 프롬프트를 작성하기", "더 좋은 도구를 늘리기", "더 좋은 기억층(Memory Layer)을 설계하기"와 같이, 인간이 다음에 던질 과제를 선택하는 형태를 취합니다. 여기에는 필연적으로 천장이 존재하며, 인간의 상상력의 한계가 학습의 한계가 됩니다.

Agent0의 공진화는 그 천장을 두 모델의 상호작용을 통해 동적으로 계속 높이는 것을 목표로 합니다. 출제자는 "풀이자가 겨우 풀 수 있을지 없을지의" 경계에 있는 문제를 만들도록 유도되고, 풀이자는 그것을 풀기 위해 단련됩니다. 풀이자가 강해지면 출제자는 난이도를 높이고, 출제자가 난이도를 높이면 풀이자는 더욱 단련되는 ―― 서로를 끌어올리는 자기 강화의 순환(self-reinforcing cycle of improvement., README L9)입니다.

여기서 중요한 점은, 공진화가 성립하기 위해서는 두 에이전트의 가중치(Weights)가 모두 업데이트되어야 한다는 전제가 깔려 있다는 것입니다. 실행형 프레임워크에서 "두 에이전트를 대결시키는 것"은 물론 가능하지만, 두자의 가중치가 고정되어 있다면 그들의 능력은 그 순간의 "똑똑함"을 넘어서지 못합니다. 공진화의 경로를 통해 난이도의 천장을 계속 높이려면, 두 모델을 강화학습(Reinforcement Learning)으로 업데이트해 나가야 합니다. 이것이 Agent0가 "학습형"을 선택한 두 번째 동기입니다.

동기 ③ ―― 도구 사용 훈련 자체를 통합 (Tool Integration)

세 번째 Key Feature는 Tool Integration입니다.

Integrates external tools (e.g., code interpreter) to enhance problem-solving and pressure the curriculum agent to generate complex, tool-aware tasks.

――

Agent0/README.md

@30e1882

, L15

실행형 에이전트도 도구를 사용합니다(제3장). 차이점은 Agent0에서는 도구를 사용하는 것 자체를 훈련의 평가 대상에 포함시킨다는 점입니다. 풀이자는 문제를 풀 때 외부 도구(예: code interpreter = 코드 실행기)를 호출할 수 있습니다. 출제자는 "도구를 사용하지 않으면 풀 수 없는" 문제를 만들도록 유도되며(pressure the curriculum agent to generate complex, tool-aware tasks), 풀이자는 "도구를 능숙하게 사용하는 방책(Policy)"을 배웁니다. 구현상으로는 훈련 스크립트 train_qwen3_4b_adpo.sh의 enable_agent=True (Agent0/executor_train/examples/train/math_tir/train_qwen3_4b_adpo.sh @ 30e1882

, L17)은 롤아웃(rollout) 중의 각 단계에서 툴 서버(tool server)로의 질의를 허용하는 설정으로, tool_type "python_code"인 Python 실행 서버가 훈련 이면에서 구동됩니다 (동일 L55).

제1부의 에이전트가 "주어진 툴을 잘 사용하도록 지시하는 것"이 프롬프트 설계였다면, 제2부의 Agent0은 "툴을 잘 사용하는 방책을 모델의 가중치(weight)에 새겨넣는 것"이 훈련입니다. 동일한 "툴 통합 (Tool Integration)"이라는 용어가 추론 시의 사용 계약(제3장)과 훈련 시의 능력 획득 대상(제7장)이라는 두 가지를 가리키게 됩니다.

3. 동기의 종합 ―― 왜 가중치 업데이트인가

세 가지 동기를 나열해 보면 공통된 입장이 보입니다.

• 인간이 준비한 데이터의 상한을 넘으려면, 데이터 생성 자체를 자동화해야 한다 (Zero Data).
• "다음 과제"가 동적으로 계속해서 높아지려면, 양 당사자의 능력이 계속해서 향상되어야 한다 (Co-Evolution).
• 툴을 사용하는 능력을 프롬프트가 아닌 능력 그 자체로서 높이려면, 그 경험을 통해 가중치를 업데이트해야 한다 (Tool Integration).

이 세 가지를 하나로 묶는 논리는 이것입니다 ―― 모델 능력의 천장을 외부 설계만으로 넘어서기는 어렵다. 그러므로 가중치 그 자체를 다시 쓴다. Agent0이 "행동을 기술"하는 것이 아니라 "가중치를 학습"하는 길을 선택하는 이유는 여기에 집약됩니다.

적용 조건 ―― 이 별해(別解)는 언제 성립하는가

단, 이 별해에는 전제 조건이 있습니다. 제1부의 실행형 에이전트의 대안으로서 "일단 학습형이 더 우월하다"라고 읽어서는 안 됩니다. 학습형이 성립하기 위해서는 최소한 다음과 같은 조건이 필요합니다.

조건 ① 자동 채점이 가능한 문제 도메인일 것

강화학습 (RL)의 핵심은 **보상 (reward)**입니다. 에이전트가 행동한 후, "그 행동이 얼마나 좋았는지"를 수치로 반환하지 않으면 가중치를 업데이트하는 방향을 결정할 수 없습니다. Agent0이 내세우는 성과의 영역은 README에 명시되어 있습니다.

Empirically, Agent 0 substantially boosts reasoning capabilities on the Qwen3-8B-Base model:

+18% improvement on Mathematical Reasoning benchmarks.
+24% improvement on General Reasoning benchmarks.
――

Agent0/README.md

@30e1882

, L19-22

Mathematical Reasoning과 General Reasoning ―― **수학적 추론 (Mathematical Reasoning)**과 일반 추론 (General Reasoning) 벤치마크 군입니다. 왜 이 영역일까요? 답은 "자동 채점이 비교적 용이하기" 때문입니다. 수학 문제는 최종 답변을 \boxed{}로 요구하면, 문자열 일치나 수치의 동치성을 통해 accuracy_reward를 계산할 수 있습니다 ―― 실제로 Agent0은 그렇게 하고 있습니다.

def format_reward(predict: str) -> float:
    pattern = re.compile(r"<think>.*</think>.*\\boxed\{.*\}.*", re.DOTALL)
    format_match = re.fullmatch(pattern, predict)
    ...

―― Agent0/curriculum_train/examples/reward_function/curriculum_reward.py

@ 30e1882

, L107-115

format_reward는 "<think>...</think>와 \boxed{...}의 구조를 지켰는가"를, accuracy_reward는 "\boxed{} 안의 내용이 정답과 일치하는가"를 각각 정규 표현식과 문자열 비교만으로 1.0 / 0.0의 수치로 떨어뜨리고 있습니다. 이것이 "자동 채점"의 정체입니다.

이 방식이 효과를 발휘하는 것은 정답을 형식적으로 판정할 수 있는 영역 ―― 수학, 코드, 형식 언어 문제 ―― 에 한정됩니다. 예를 들어 "고객에게 메일을 써서 계약을 따낸다", "논문의 요지를 작성한다", "상사에게 혼나지 않도록 상담한다"와 같은 태스크는 출력의 좋고 나쁨을 수치로 자동 채점하는 메커니즘을 만드는 것 자체가 어렵습니다. Agent0의 접근법은 우선 여기서 적용 영역을 좁힙니다.

제1부의 실행형 에이전트 (Execution-type Agent)는 인간이 그 자리에서 피드백을 줄 수 있기 때문에 (또는 자동 채점이 불가능한 도메인이라도 "실행"하고 "관측"하는 것까지는 가능하기 때문에), 더 넓은 태스크에 적용할 수 있습니다. 학습형 (Learning-type)은 자동 채점이라는 "좁지만" 강력한 특성을 가진 도메인에 집중하기 때문에, 공진화 (Co-evolution)와 가중치 업데이트 (Weight update)가 순환될 수 있는 것입니다.

조건 ② 계산 자원과 훈련 인프라를 준비할 수 있을 것

실행형 에이전트는 노트북과 API 키만 있으면 구동할 수 있습니다 (제1~6.5장의 최소 구현은 모두 이를 상정합니다). 학습형은 그렇지 않습니다. Agent0의 train_qwen3_4b_adpo.sh를 다시 한번 살펴보세요.

n_gpus_per_node=8
n_nodes=1
n=16
...

―― Agent0/executor_train/examples/train/math_tir/train_qwen3_4b_adpo.sh @ 30e1882, L7-11

n_gpus_per_node=8 (1개 노드에 GPU 8장). 이것이 Executor Agent를 훈련하기 위한 최소 스케일입니다. 여기에 더해 rollout_mode='async' (동일 L44)로 비동기적으로 대량의 롤아웃 (Rollout)을 실행하고, actor_rollout_ref.rollout.n=$n (동일 L116, n=16)으로 1개 프롬프트당 16개의 샘플을 생성하며, batch_size=128의 배치 (Batch)로 업데이트합니다. 출제 역할 (Curriculum) 측의 훈련 스크립트 또한 4개의 GPU를 점유합니다 (Agent0/curriculum_train/scripts/curriculum_train.sh @ 30e1882, L20 "CUDA_VISIBLE_DEVICES=0,1,2,3", L29 "trainer.n_gpus_per_node=4").

실행형의 "pip install 해서 구동하기", "Docker 샌드박스 (Sandbox) 구축하기"와는 요구되는 계산 자원의 오더 (Order)가 다릅니다. Agent0의 퀵스타트 (Quickstart)는 전용 conda 환경을 2개 만들고 (curriculum / executor), 별도로 SandboxFusion 기반의 코드 샌드박스를 구축하며 (Agent0/README.md @ 30e1882, L55 "We deployed four sandbox services"는 4개 병렬 실행을 예시), STORAGE_PATH를 확보하여 학습의 체크포인트 (Checkpoints)를 저장하면서 반복합니다. 개인 개발자 한 명이 가진 노트북으로 "잠깐 돌려보는" 스케일이 아닙니다.

This step will be relatively slow due to limitations such as rollout and concurrency restrictions of the sandbox service.
(이 단계는 롤아웃이나 샌드박스 서비스의 병행성 제한 등의 이유로 비교적 느립니다, Agent0/README.md @ 30e1882, L78)라고 README 자체에서도 명시하고 있듯이, 학습형은 계산과 시간을 투입하는 것을 전제로 하는 접근법입니다.

조건 ③ 베이스 모델 (Base Model)이 "닿을 수 있는 범위"에 있을 것

Agent0가 훈련의 기점으로 선택하는 모델은 README에 명시되어 있습니다.

# Initialize first iteration with base model bash scripts/curriculum_train.sh Qwen/Qwen3-4B-Base Qwen/Qwen3-4B-Base qwen3_4b_curriculum_v1

―― Agent0/README.md @ 30e1882, L93-94

Qwen3-4B-Base (40억 파라미터)로 초기화하며, Results 섹션은 Qwen3-8B-Base (80억 파라미터)에서의 개선 (+18% / +24%)을 보고하고 있습니다 (동일 L19-22). 폐쇄형 소형~중형 오픈 웨이트 (Open-weight) 모델이 훈련 대상이며, API를 통한 프로프라이어터리 (Proprietary) 모델 (Claude나 GPT 등)은 대상에서 제외됩니다. 가중치를 수정하기 위해서는 가중치 그 자체에 접근할 수 있어야 하므로, 이는 원리적인 제약입니다.

실행형 에이전트(Execution-type Agent)는 API를 통한 프로프라이어터리 모델(Proprietary Model)에서도 문제없이 작동하지만, 학습형 에이전트(Learning-type Agent)는 가중치(Weights)에 접근할 권한이 있는 모델 ―― 대부분의 경우 오픈 웨이트(Open-weights) 기반 모델 ―― 이 전제 조건이 됩니다. 수중에 있는 Claude나 GPT를 Agent0로 "진화"시키는 것은 불가능합니다.

요약 ―― 별도의 해법은 "대체재"가 아니다

3가지 조건을 나열해 보면, 제1부의 실행형 에이전트와 제2부의 학습형 에이전트가 서로 경합하는 대체안이 아님을 알 수 있습니다.