Self-improving agent는 도대체 무엇을 개선하는가

지금 self-improving agent를 체계적으로 이해하려면, 추상적인 용어를 쫓기보다는 네 가지를 명확히 하는 것이 중요하다고 생각합니다.

1. 그것은 도대체 무엇을 "자기 개선"하는가?
2. 이 개선은 추론 시, 작업 간, 아니면 재훈련 시 발생하는가?
3. 무엇을 통해 자신이 정말 나아졌다고 판단하는가?
4. 어떤 방향이 이미 실현 가능하며, 어떤 방향은 아직 연구 프로토타입 단계에 머물러 있는가?

먼저 결론부터 말씀드리겠습니다. 오늘날의 self-improving agent는 공상 과학 소설에 나오는 "모델이 스스로 각성하여 무한히 재귀적으로 업그레이드되는" 것이 아닙니다. 더 정확한 표현은 에이전트 시스템이 자신의 실패, 궤적, 피드백 및 평가 결과를 다음 라운드의 더 나은 행동으로 전환하는 폐쇄 루프입니다.

이 폐쇄 루프는 가벼울 수도 있고, 무거울 수도 있습니다.

가벼운 것은 Reflexion, Self-Refine과 같은 방식입니다. 모델 매개변수를 변경하지 않고, 반성을 컨텍스트나 기억에 기록하는 것입니다. 무거운 것은 SEAL과 같은 방식입니다. 모델이 자체 훈련 데이터와 업데이트 지침을 생성하여 실제로 가중치를 변경하는 것입니다. 그 중간에 있는 것이 오늘날 가장 주목할 만한 계층입니다. 프롬프트, 도구, 워크플로, 코드를 변경하고 실행 가능한 평가로 검증하는 것입니다.

따라서 self-improving agent에서 가장 중요한 것은 "self"가 아니라 "improving"입니다. 평가, 회귀, 대조 실험 없이는 모델이 자신이 왜 잘했는지 반복해서 설명하게 할 뿐입니다.

먼저 정의: 그것은 하나의 개념이 아니다

많은 글에서 self-improving, self-evolving, self-adapting, recursive self-improvement를 혼용하여 사용합니다. 이는 문제를 매우 모호하게 만듭니다.

저는 이것을 엔지니어링 문제로 나누어 설명하고 싶습니다.

에이전트가 작업을 완료한 후, 피드백을 활용하여 자신의 구성 요소 중 일부를 수정하고, 후속 작업에서 안정적으로 개선될 수 있는가?

여기에는 세 가지 핵심 키워드가 있습니다.

첫째, 피드백. 피드백은 테스트, 컴파일러, 환경 보상, 인간의 의견, LLM-as-judge, 생산 로그에서 올 수 있으며, 에이전트 스스로 실패 궤적에 대한 반성에서 올 수도 있습니다.

둘째, 수정 대상. 컨텍스트, 기억, 프롬프트, 도구 설명, 워크플로, 코드, 훈련 데이터, 보상 모델, 심지어 모델 가중치까지 변경할 수 있습니다.

셋째, 안정적인 개선. 이것이 가장 어려운 부분입니다. 한 번의 작업에서 개선되는 것만으로는 충분하지 않으며, 과적합이 아니거나, 우연이 아니거나, 비용이 폭증하지 않거나, 안전 경계가 사라지지 않았음을 증명해야 합니다.

이 표를 통해 먼저 정신 모델을 구축할 수 있습니다.

이것이 제가 self-improving agent를 단순히 "모델이 사용할수록 똑똑해진다"고 이해하지 말라고 권하는 이유입니다. 진정으로 논의할 수 있는 것은 어떤 계층을 변경하는지, 피드백은 어디서 오는지, 변경 후 어떻게 검증하는지입니다.

1단계: 반성, 가중치 변경 없음

이동

초기 가장 대표적인 접근 방식은 모델이 실패 후 반성을 기록하고, 그 반성을 컨텍스트에 다시 넣는 것이었습니다.

Reflexion의 핵심 아이디어는 에이전트가 기울기 업데이트를 통해 학습하는 것이 아니라, 작업 피드백을 언어적 반성으로 전환하여 에피소드 기억에 저장하고, 다음에 유사한 작업을 만났을 때 이를 활용하는 것입니다. 그 의미는 특정 벤치마크 점수가 아니라, 전통적인 RL의 매개변수 업데이트에서 에이전트가 즉시 사용할 수 있는 언어 기억으로 "시행착오 학습"을 전환했다는 점입니다.

Self-Refine은 더 직접적입니다. 모델이 먼저 답변을 생성하고, 자신의 답변에 대한 피드백을 제공하며, 그 피드백을 기반으로 답변을 수정합니다. 이 패턴은 이제 많은 에이전트 프레임워크의 기본 모듈이 되었습니다. 먼저 수행하고, 검토하고, 수정하는 것입니다.

STaR은 훈련 데이터 경로를 따릅니다. 모델이 먼저 추론 과정을 생성하고, 잘못된 답변을 걸러내고, 올바른 답변으로 이어지는 근거(rationale)를 보존한 다음, 이 근거를 사용하여 모델을 훈련합니다. 이것은 완전한 에이전트는 아니지만, 많은 후속 self-improvement 방법에 중요한 영감을 주었습니다. 모델은 자신의 성공 궤적에서 훈련 신호를 추출할 수 있습니다.

이러한 방법의 장점은 간단하다는 것이고, 단점도 명확합니다. 반성이 곧 개선은 아닙니다. 모델은 그럴듯한 회고를 작성하는 데 능숙하지만, 외부 검증이 없으면 단순히 자신의 실수를 더 잘 설명하게 될 수도 있습니다.

따라서 반성형 에이전트의 경계는 명확합니다. 단기적인 행동 수정에 적합하며, 장기적인 능력 성장의 증명으로 사용하기에는 적합하지 않습니다.

2단계: 경험을 스킬 라이브러리로 전환

이동

Voyager는 제가 반드시 읽어야 할 논문 중 하나라고 생각합니다. 이 논문은 self-improving agent를 "답변 수정"에서 "기술 축적"으로 발전시켰습니다.

Voyager는 Minecraft 환경에서 세 가지 작업을 수행합니다.

1. 탐색 커리큘럼을 자동으로 생성합니다.
2. 성공적인 행동을 실행 가능한 코드 기술로 저장합니다.
3. 환경 피드백, 실행 오류 및 자체 검증에 따라 프로그램을 반복적으로 개선합니다.

여기서 가장 중요한 것은 Minecraft가 아니라 "기술 라이브러리"라는 구조입니다. 이는 에이전트의 개선이 단순히 다음 프롬프트가 길어지는 것이 아니라, 검색 가능하고, 조합 가능하며, 재사용 가능한 프로그램 자산으로 축적된다는 것을 의미합니다.

이는 실제 제품에 큰 영감을 줍니다. 많은 팀이 자가 진화 에이전트를 만들겠다고 말하지만, 실제 첫 단계는 모델을 훈련하는 것이 아니라, 에이전트가 매번 작업을 완료한 궤적을 세 가지 유형의 자산으로 정리하는 것입니다.

즉, 실용적인 self-improving agent는 먼저 작업 일지를 작성하는 엔지니어처럼 작동해야 하며, 매일 밤 몰래 자신을 훈련하는 모델처럼 작동해서는 안 됩니다.

3단계: 프롬프트 및 워크플로 자동 최적화

이동

2024년에서 2025년으로 넘어오면서 중요한 변화가 나타났습니다. 사람들은 에이전트가 "반성"하는 것에 만족하지 않고, 에이전트가 에이전트를 자동으로 설계하도록 하기 시작했습니다.

OPRO는 LLM을 최적화 도구로 사용하여, 모델이 과거 후보 해와 점수를 기반으로 다음 후보 배치를 제안하도록 합니다. 이 아이디어는 나중에 많은 프롬프트 최적화 도구에 계승되었습니다. 프롬프트를 수동으로 조정하지 않고, 작업, 데이터셋 및 지표를 정의하여 시스템이 더 나은 지시어를 검색하도록 하는 것입니다.

DSPy의 MIPROv2와 GEPA는 이 작업을 더 엔지니어링적으로 만들었습니다. 특히 GEPA는 단일 스칼라 점수만 보지 않고, 모델이 전체 실행 추적을 읽고, 자연어로 실패 원인을 진단한 다음, 프롬프트를 진화시키도록 강조합니다. 이 방향은 실제 에이전트에 매우 적합합니다. 왜냐하면 에이전트의 실패는 종종 "최종 답변이 틀렸다"는 단순한 문제가 아니라, 도구 선택 오류, 검색 오류, 계획 오류, 형식 오류, 중간 상태 오류 등 복합적인 문제이기 때문입니다.

더 나아가면 ADAS와 AFlow가 있습니다.

ADAS는 Automated Design of Agentic Systems를 제안합니다. 메타 에이전트가 코드 공간에서 프롬프트, 도구 사용, 제어 흐름 및 조합 방식을 포함한 새로운 에이전트 설계를 발명하도록 하는 것입니다. AFlow는 에이전트 워크플로를 코드의 노드와 에지로 표현하고, 검색 방법을 사용하여 워크플로를 자동으로 수정하고 평가합니다.

이 방향의 핵심은 "모델이 멋진 프롬프트를 작성할 수 있는지"가 아니라, 에이전트의 구조 자체가 검색 가능하고, 평가 가능하며, 반복 가능한 객체가 된다는 것입니다.

이는 엔지니어링 실천에 매우 중요합니다. 왜냐하면 실제 에이전트의 병목 현상은 종종 단일 답변에 있는 것이 아니라 시스템 구조에 있기 때문입니다.

• 먼저 검색한 다음 계획해야 하는가?
• 도구 실패 후 재시도, 도구 교체, 아니면 사용자에게 문의해야 하는가?
• 다중 에이전트는 직렬로 협력하는가, 아니면 코디네이터가 할당하는가?
• 어떤 정보가 단기 컨텍스트에 들어가야 하고, 어떤 정보가 장기 기억에 들어가야 하는가?
• 언제 중단하고, 언제 계속 탐색해야 하는가?

과거에는 이러한 문제들을 사람이 설계했습니다. self-improving agent 연구는 이러한 문제들을 검색 문제로 전환하고 있습니다.

4단계: 자신의 코드 수정

이동

ADAS가 메타 에이전트가 에이전트를 설계하도록 하는 것이라면, A Self-Improving Coding Agent와 Darwin Godel Machine은 문자 그대로 "에이전트가 자신을 수정"하는 것에 더 가깝습니다.

A Self-Improving Coding Agent는 코딩 에이전트가 자신의 구현을 편집하고 SWE-bench Verified, LiveCodeBench 등의 작업에서 성능을 향상시키는 방법을 보여줍니다. DGM은 한 걸음 더 나아가 에이전트 아카이브를 유지하고, 기존 에이전트에서 샘플링한 다음, 파운데이션 모델이 새로운 변형을 생성하고, 벤치마크로 검증한 후 고품질 분기를 보존합니다.

DGM에서 가장 주목할 만한 점은 두 가지입니다.

첫째, 단일 경로 등반이 아니라 여러 진화 분기를 보존합니다. 이렇게 하면 특정 변경이 단기적으로는 효과적이지만 장기적으로 방향을 고정시키는 것을 피할 수 있습니다.

둘째, 개선하는 것은 하위 파운데이션 모델이 아니라 에이전트의 외부 구조입니다. 도구 편집, 컨텍스트 관리, 피어 리뷰 메커니즘, 패치 검증 등입니다. 다시 말해, "모델이 스스로 더 똑똑한 뇌를 훈련시킨다"는 것을 증명하는 것이 아니라, "고정된 모델 위에 에이전트 스캐폴딩이 여전히 크게 최적화될 수 있는 공간이 있다"는 것을 증명하는 것입니다.

이는 오늘날 제품 팀이 할 수 있는 일에 더 가깝습니다. 새로운 모델을 훈련할 수는 없지만, 에이전트가 샌드박스에서 PR을 생성하고, 테스트를 실행하고, 지표를 비교하고, 유효한 변경 사항을 보존한 다음, 사람이 검토하여 병합하도록 할 수 있습니다.

그러나 이 경로의 보안 문턱은 매우 높습니다. DGM 저장소에서도 모델이 생성한 코드를 실행하는 것은 위험하다고 명확히 경고합니다. 실제 시스템에는 샌드박스, 권한 경계, 리소스 제한, 테스트 세트 격리, 롤백 메커니즘 및 수동 승인이 있어야 합니다.

5단계: 모델이 자체 훈련 신호 생성

이동

모델 훈련에 더 가까운 또 다른 경로는 모델이 자체 데이터, 보상 또는 업데이트 지침 생성에 참여하도록 하는 것입니다.

Self-Rewarding Language Models는 LLM-as-a-judge를 사용하여 모델이 자신의 출력에 보상 신호를 제공하고, Iterative DPO를 통해 훈련합니다. 이 논문의 핵심 문제는 매우 야심적입니다. 미래에 모델이 인간 수준을 넘어서는 피드백이 필요하다면, 모델 스스로 피드백 품질을 점진적으로 향상시킬 수 있을까?

SEAL: Self-Adapting Language Models는 한 걸음 더 나아가 모델이 self-edit를 생성하도록 합니다. 이 self-edit는 합성 훈련 데이터, 정보 재작성 방식, 하이퍼파라미터 최적화, 심지어 데이터 증강 및 기울기 업데이트 도구 호출까지 포함할 수 있습니다. 모델은 하위 작업 성능을 보상으로 사용하여 더 효과적인 self-edit를 생성하는 방법을 학습합니다.

또한 Self-Improving LLM Agents at Test-Time와 같은 test-time self-improvement도 있습니다. 모델이 먼저 불확실한 샘플을 식별하고, 이 샘플을 중심으로 유사한 훈련 예시를 생성하며, 가벼운 임시 매개변수 업데이트를 수행한 다음, 원래 매개변수를 복원합니다. 이 방향은 "학습"을 추론 현장으로 가져온다는 점에서 매우 흥미롭습니다.

그러나 가중치 업데이트에 가까워질수록 더욱 신중해야 합니다.

모델 가중치가 잘못된 데이터, 자체 평가 편향 또는 악의적인 입력으로 오염되면 문제는 더 이상 특정 답변이 틀린 것이 아니라 시스템 자체가 변한 것이기 때문입니다. 일반적인 제품 팀에게는 장기 기억, 프롬프트 최적화, 워크플로 검색 및 샌드박스 코드 개선이 온라인에서 자체 가중치를 변경하는 것보다 더 현실적입니다.

생산 실천에 가장 가까운 AlphaEvolve

이동

self-improving agent의 생산 형태를 보려면 AlphaEvolve가 현재 가장 연구할 가치가 있는 사례 중 하나입니다.

AlphaEvolve의 핵심 구조는 매우 단순합니다.

후보 프로그램 생성
실행 및 점수 매기기
고득점 프로그램을 데이터베이스에 저장
데이터베이스를 기반으로 계속 샘플링 및 변이
반복

이것이 대단한 점은 "모델이 생각하게 하는 것"이 아니라, 작업 선택이 자동 평가에 매우 적합하다는 것입니다. 알고리즘, 스케줄링, 하드웨어 회로, 행렬 곱셈, GPU 커널. 후보 프로그램이 실행 가능하고, 검증 가능하며, 점수를 매길 수 있다면 에이전트는 대규모 탐색을 할 수 있습니다.

Google DeepMind가 공개한 실제 사례도 매우 구체적입니다. AlphaEvolve가 발견한 스케줄링 휴리스틱은 이미 Google 데이터 센터에서 사용되어 전 세계 컴퓨팅 자원의 평균 0.7%를 지속적으로 회수하고 있습니다. 또한 TPU 회로 단순화, Gemini 훈련 관련 커널 최적화, 수학 및 알고리즘 발견에도 사용되었습니다.

이는 self-improving agent에 대한 매우 중요한 현실적 판단을 제공합니다.

가장 먼저 실현될 자기 개선은 "무엇이든 할 수 있는" 범용 비서가 아니라, 평가가 명확하고, 피드백이 저렴하며, 오류 롤백이 가능한 좁은 영역에서 나타날 것입니다.

코드, 알고리즘, 컴파일러 최적화, 데이터 처리 파이프라인, 테스트 생성, 검색 순위, 고객 서비스 라우팅, 내부 운영 프로세스 등은 개방형 채팅보다 자기 개선에 더 적합합니다.

진정한 분수령은 평가(eval)

self-improving agent를 연구하면 결국 평가로 돌아오게 됩니다.

OpenAI의 에이전트 평가 문서는 이 문제를 매우 엔지니어링적으로 설명합니다. 에이전트 워크플로의 평가는 추적(traces), 평가자(graders), 데이터셋(datasets) 및 평가 실행(eval runs)을 봐야 합니다. 즉, 최종 답변뿐만 아니라 전체 궤적을 봐야 합니다. 모델 호출, 도구 호출, 핸드오프, 가드레일, 라우팅, 실패 지점 등입니다.

이는 self-improving agent와 완전히 일치합니다. 에이전트가 자신을 개선하려면 먼저 자신이 어디가 잘못되었는지 알아야 하기 때문입니다.

최소한의 자기 개선 폐쇄 루프는 다음과 같아야 합니다.

생산 또는 테스트 궤적
  ↓
실패 원인 분석: 도구 오류, 검색 오류, 계획 오류, 형식 오류, 권한 오류, 중지 시점 오류
  ↓
후보 변경 사항 생성: prompt / workflow / tool schema / memory rule / code patch
  ↓
오프라인 평가: 고정 데이터셋 + 회귀 세트 + 비용 및 지연 시간
  ↓
샌드박스 검증: 실제 도구 사용, 단 권한 제한
  ↓
수동 검토 또는 자동 그레이스케일 배포
  ↓
버전 관리 자산에 기록

이러한 시스템이 없으면 소위 자기 개선은 "실패 사례를 프롬프트에 다시 주입하는 것"으로 변질되기 쉽습니다. 단기적으로는 개선되는 것처럼 보이지만, 장기적으로는 세 가지 문제가 발생할 수 있습니다.

1. 최근 실패에 대한 과적합: 오늘은 A를 고쳤지만, 내일은 B를 망가뜨립니다.
2. 보상 속임수: 에이전트가 실제 문제를 해결하는 대신 평가자를 만족시키는 방법을 학습합니다.
3. 경계 표류: 작업을 완료하기 위해 몰래 권한을 확장하고, 확인을 건너뛰고, 불확실성을 숨깁니다.

따라서 저는 평가를 self-improving agent의 기반으로 보며, 부속 도구가 아니라고 생각합니다.

보안 문제는 나중에 생각할 문제가 아니다

자기 개선을 강조할수록 보안을 나중에 생각해서는 안 됩니다.

Anthropic이 2026년 2월에 발표한 Measuring AI agent autonomy in practice에서는 두 가지 주목할 만한 추세를 언급합니다. Claude Code의 가장 긴 자율 작업 시간이 몇 달 동안 크게 증가했으며, 숙련된 사용자는 자동 승인을 더 자주 사용하지만, 과정에서 중단하는 경우도 더 많다는 것입니다. 이는 실제 세계의 에이전트가 단순히 "완전 자동"으로 가는 것이 아니라, "더 긴 시간 자율 작업 + 인간이 중요한 순간에 개입"하는 방향으로 나아가고 있음을 보여줍니다.

self-improving agent에게 이 관찰은 매우 중요합니다.

자신을 수정할 수 있는 에이전트는 "성공률 향상"이라는 목표만 가져서는 안 되며, 동시에 다음과 같은 제약 조건을 최적화해야 합니다.

심지어 저는 진정으로 성숙한 self-improving agent 제품은 "완전 자율"을 홍보하지 않을 것이라고 생각합니다. 대신 "감독 가능한 자율"을 홍보할 것입니다. 시스템이 스스로 문제를 발견하고, 개선을 제안하며, 대부분의 검증을 완료하지만, 핵심 권한과 장기 상태는 인간 또는 조직 정책에 의해 제어됩니다.

직접 만들려면 어디서부터 시작해야 하는가

만약 제가 오늘날 실제 제품에서 self-improving agent를 만든다면, 모델 훈련부터 시작하지 않을 것입니다. 다섯 단계로 진행할 것입니다.

1단계: 궤적을 완전하게 기록

모든 에이전트 실행의 입력, 컨텍스트 버전, 프롬프트 버전, 도구 스키마, 도구 호출, 반환 결과, 오류, 최종 출력, 사용자 피드백 및 수동 수정을 기록합니다. 궤적이 없으면 학습 자료도 없습니다.

2단계: 고정된 평가 세트 구축

실제 실패 사례에서 샘플링하여 일상적인 개발로 쉽게 오염되지 않는 평가 세트를 만듭니다. 최소한 세 가지 유형으로 나눕니다.

3단계: 먼저 프롬프트 및 도구 설명 최적화

이것은 가장 비용이 적게 들고 위험이 가장 낮은 단계입니다. GEPA, DSPy, OPRO와 같은 접근 방식을 사용하거나, 간단한 후보 프롬프트 검색을 먼저 수행할 수 있습니다. 핵심은 모든 후보가 동일한 평가 세트를 실행해야 하며, 육안으로 판단해서는 안 된다는 것입니다.

4단계: 워크플로 최적화

프롬프트가 어느 정도 최적화되면 문제는 일반적으로 프로세스에서 드러납니다. 예를 들어, 검색 위치가 잘못되었거나, 도구 실패 후 복구 전략이 없거나, 에이전트가 너무 일찍 또는 너무 늦게 중단되는 경우입니다. 이때 AFlow/ADAS와 같은 접근 방식을 도입하여 워크플로를 수정 가능한 객체로 표현하고 오프라인 검색을 수행할 수 있습니다.

5단계: 에이전트가 코드 변경을 생성하도록 하되, 반드시 PR 프로세스를 거치도록 함

이것은 DGM/SICA에 가장 가까운 단계입니다. 에이전트가 코드 패치를 제안할 수 있지만, 패치는 일반적인 엔지니어링 변경과 마찬가지로 테스트, 검토, 권한 제한 및 그레이스케일 배포를 거쳐야 합니다. 생산 시스템을 직접 변경하도록 해서는 안 됩니다.

온라인에서 가중치를 변경하는 것은 대부분의 팀이 지금 당장 시도해서는 안 된다고 생각합니다. 매우 성숙한 데이터 거버넌스, 평가 시스템, 모델 훈련 능력 및 롤백 메커니즘이 갖춰져 있지 않다면, 이로 인한 운영 복잡성이 이점보다 훨씬 클 것입니다.

논문 읽기 경로

self-improving agent를 막연하게 검색하면 용어에 압도되기 쉽습니다. 다음 경로로 읽는 것을 추천합니다.

1. Self-Refine 및 Reflexion: 가장 가벼운 반성 폐쇄 루프를 이해합니다.
2. STaR 및 Self-Rewarding Language Models: 자체 생성 훈련 신호를 이해합니다.
3. Voyager: 스킬 라이브러리와 개방형 환경에서의 지속적인 축적을 이해합니다.
4. OPRO, GEPA, TextGrad: 자연어 피드백이 프롬프트, 코드 및 시스템 구성 요소를 어떻게 최적화하는지 이해합니다.
5. ADAS 및 AFlow: 에이전트 워크플로가 어떻게 자동으로 설계되는지 이해합니다.
6. A Self-Improving Coding Agent 및 DGM: 에이전트가 자신의 구현을 어떻게 수정하는지 이해합니다.
7. SEAL 및 Self-Improving LLM Agents at Test-Time: 가중치 업데이트 및 test-time adaptation을 이해합니다.
8. AlphaEvolve: 생산 가치에 가장 가까운 진화적 코딩 에이전트를 이해합니다.
9. A Survey of Self-Evolving Agents: 마지막으로 개요를 읽고 개념을 완전한 분류에 다시 배치합니다.

나의 판단

Self-improving agent는 AGI 서사로 오해되기 쉽습니다. 모델이 스스로를 수정하고 능력이 기하급수적으로 증가한다는 것입니다.

그러나 현재 논문과 실제 사례를 보면, 더 신뢰할 수 있는 판단은 다음과 같습니다.

self-improving agent의 단기적 가치는 모델 훈련을 대체하는 것이 아니라, 에이전트 엔지니어링을 수동 튜닝에서 평가 기반의 자동 최적화로 발전시키는 것입니다.

그 핵심 자산은 "더 똑똑한 모델"이 아니라, 폐쇄 루프를 형성할 수 있는 시스템입니다.

• 실제 작업 궤적이 있습니다.
• 실행 가능한 평가가 있습니다.
• 버전 관리 가능한 프롬프트, 워크플로, 도구, 메모리 및 코드가 있습니다.
• 후보 변경 사항을 자동으로 생성하는 메커니즘이 있습니다.
• 보안 경계, 회귀 테스트 및 수동 승인이 있습니다.

이것은 "재귀적 자기 진화"만큼 자극적이지는 않지만, 더 중요합니다. 왜냐하면 에이전트를 일회성 데모에서 장기적으로 유지 관리할 수 있는 시스템으로 전환하기 때문입니다.

미래에 에이전트가 정말로 계속 강해진다면, 아마도 신비로운 순간부터 시작되는 것이 아니라, 이러한 매우 엔지니어링적인 폐쇄 루프부터 시작될 것입니다. 모든 실패는 기록되고, 모든 변경은 평가되며, 모든 유효한 경험은 고정되고, 모든 경계 초과 시도는 차단됩니다.

진정한 self-improving agent는 "나는 반성했다"고 말할 수 있는 에이전트가 아닙니다.

그것은 "이번 변경으로 시스템이 실제로 개선되었고, 경계를 침범하지 않았다"는 것을 증명할 수 있는 에이전트여야 합니다.