저희 Princeton SWE-bench 팀에서 약 100줄 코드로 SWE-bench에서 좋은 성과를 내는 에이전트를 만들었음, 관심 있으면 한 번 살펴보면 좋겠음 mini-swe-agent
진짜로 꽤 간단한 구조임에 놀람, 이런 정보를 공유해줘서 고마움
전체 코드는 사실 이 프롬프트들로 돌아감 에이전트 기본 프롬프트 소스코드
Your task: {{task}}. Please reply
with a single shell command in
triple backticks.
To finish, the first line of the
output of the shell command must be
'COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT'.
에이전트 샘플 프롬프트 중 “1. 코드베이스에서 관련 파일 찾기 및 읽기 2. 이슈 재현 스크립트 만들기 3. 이슈 수정 4. 스크립트로 수정 확인 5. 엣지 케이스 테스트” 부분이 유용함
나도 디버깅 루프에서 이런 식의 프롬프트를 유사하게 사용함
“코드베이스 분석 후 원인 후보를 리스트업하고, 가능성 높은 순으로 랭크하고, 스크립트나 디버그 로깅으로 가설을 검증” 방식이 나만의 문제 해결 루틴에 큰 도움이 됨
문제가 하나의 파일에 자족적으로 있을 때 LLM을 이용해 수정하는 것은 매우 쉬움
그러나 일반적인 코드베이스에서는 파일과 맥락이 여기저기 흩어져 있어서, 개발자의 구조화된 설계 의도와 조직화에 맞춰 파악하기가 쉽지 않음
멋진 시도에 박수를 보냄, 다만 아쉬운 점은 도구가 많지 않다는 것임
대부분의 코드는 에이전트 프레임워크에 해당되고 SWE만을 위한 특화 코드는 생각보다 많지 않음
나도 재미로 SWE 에이전트를 만들어봤으니 autocode도 참고해보면 좋겠음
고맙다는 의미에서 참고 자료에 추가함
Thorsten Ball이 작성한 매우 유사한 “에이전트 빌드 방법 가이드”가 AmpCode How To Guide에도 존재함
전반적으로 Amp도 꽤 흥미로움
이제는 더 이상 비밀스러운 서비스가 아니지만, 에이전트 코딩 관련 도구가 계속 공개되는 것이 반가움
앞으로 다양한 소프트웨어에서 이러한 에이전트 모델이 기본적으로 포함될 것이라 생각함
이게 훨씬 보기 좋아서 고마움을 느낌
저자 본인이 Amp에서 근무한다는 내용도 언급됨
Ghuntley 또한 Amp에서 일함
그림 한 장이 보통 1000단어의 가치라는데, 이 자료에선 그림들의 가치가 99.6% 할인된 느낌임
이게 뭔지 궁금함
컨퍼런스 워크숍용 슬라이드 자료임
텍스트는 실제 발표에서의 워딩을 딕테이션한 것임
혹시 누군가가 툴 활용 방식에 대해 확인해줄 수 있는지 궁금함
Claude, ChatGPT 등에서 API로 "툴"을 제공하며 툴 호출 요청이 들어오면 응답자로서 툴을 실제로 실행하고 결과를 다시 전달하는 형태로 이해하고 있음
근데 실제로 모델은 엄밀히 말해 문자 기반이니, API에서 어떻게 모델 응답을 여러 구조로 바꾸는지 궁금함
분명히 파인튜닝 과정에서 특정 툴 호출을 특수한 블록 형태로 넣은 예제를 통해 모델이 이해하고, Claude/ChatGPT 서버에서 그걸 해석한다는 과정이 있었을 거라 추정함
이와 관련해 문서나 내부적으로 쓰는 특수 토큰에 대한 정보가 있는지, 또 유저 입력이 이 “의미 담당” 토큰을 악용하지 못하게 어떻게 막는지 궁금함
Anthropic에서 공개한 구현 문서가 있음 Anthropic Tool Use Documentation
여기서 모델은 사실 “텍스트”가 아니라 토큰 단위로 동작함을 명확히 알 수 있음
컴파일러가 소스코드를 파싱해서 키워드, 괄호, 구조 등 “토큰” 시퀀스를 만든다는 점과 비슷함
출력물에는 실제 단어와 함께 메타데이터도 포함될 수 있음
개념적으로는 맞게 이해했음
오직 LLM과의 진짜 인터페이스는 “토큰” 뿐이고, 제어와 데이터 채널이 분리되어 있지 않음
모델 API 계층에서 툴 호출용 인스트럭션 및 사용 가능한 툴 목록을 프롬프트에 삽입, 각각에 대한 설명도 같이 제공
툴 호출이 필요할 때 모델은 응답에 특수 블록(특수 토큰 포함, 툴 이름 및 파라미터 명시)을 삽입하면, API 계층이 이를 추출해 JSON 형태로 변환함
툴 실행 결과도 특수 토큰으로 인코딩되어 삽입
사용자 입력에서 자체적으로 이런 토큰을 주입하지 못하도록 API 계층이 막고 있음
최신(SoTA) 모델들은 툴 호출에 대해 상당한 파인튜닝이 이루어졌음, 범용 툴 호출/특정 툴 케이스(예: Claude Sonnet 모델이 Claude Code 툴에 특화)에 대한 파인튜닝 모두 포함
모든 게 잘 작동하는 게 신기할 정도임, 툴 호출에선 파인튜닝이 정말 핵심적인 역할임
파인튜닝 없이도 동작은 가능하지만, 성공률이 크게 떨어짐
“툴 호출이 필요한 예시를 특수한 블록으로 반환하는 방식으로 파인튜닝했다”는 추측은 맞다고 생각함
답을 잘 모를 때나 지시를 받으면 툴 호출 포맷으로 응답하도록 학습됨
포맷을 따르는 툴 호출 예시(포맷 자체)와 일부 도구에 특화된 학습 둘 다 진행됨
예를 들어 gpt-oss는 아무리 언급이 없어도 검색 도구를 쓰려는 경향
Anthropic 문서엔 친숙한 도구(예: text_editor, bash) 목록도 따로 있고, 이 도구들은 사용법에 대한 깊은 의미까지 따로 학습됐을 확률이 높음
실제론 구조가 꽤 깨지기 쉽고, “특수 토큰이나 토큰 시퀀스”라는 낮은 수준의 신호를 통해 이뤄짐
“토큰을 계속 루프에 던지면 에이전트가 생긴다”는 말에 “토큰”을 “돈”으로 바꿔서 보면 현실적인 풍자가 느껴짐
결국 돈을 계속 태우면 에이전트가 생긴다는 셈임
토큰이 전부 돈이라고 말하긴 어렵다고 생각함
로컬 모델들도 계속 좋아지고 있음
아직까지는 최고의 결과를 내려면 토큰(=돈)이 필요하지만 미래에는 달라질 가능성이 높음
이렇게 이미지만 가득하면 너무 읽기 힘들어짐
스크롤 시뮬레이터를 보는 것 같은 느낌임
bash 툴 말고 굳이 다른 툴이 왜 필요한지 궁금함
파일 목록조회라든지, 레포 찾기 및 탐색, 파일 내용 편집 같은 건 bash만으로도 다 할 수 있지 않나
아니면 위의 mini-swe-agent 예시에서 보여주는 케이스인지 궁금함
기술적으로 봤을 때 bash 하나만으로도 충분히 다양한 작업이 가능하고, 실제로 그렇게 성공한 경험도 있음
흥미로운 점은 도구를 제한할수록 에이전트가 더 창의적으로 접근한다는 점임
하지만 학습된 다양한 도구를 제공하면, 모델이 각 도구의 사용법을 이미 잘 알고 있어서 토큰 사용량도 효율적이고 전반적으로 성공률도 높아짐
Bash만 쓸 경우 bashism이나 인수 처리, 공백 처리 같은 부분에서 자주 헤매는 문제도 있음
별도의 도구를 쓰는 게 bash 하나에 몰아넣는 것보다 훨씬 단순함
만약 모든 것을 bash로 처리하면, 무조건 안전하게 실행 가능한 명령어(예: 파일 목록)는 바로 실행하고, 그 외 위험한 명령은 사용자 승인 받는 체계를 별도로 구현해야 함
파일 목록조회를 별도 툴로 제공하면 프로젝트 디렉터리 외부 파일 노출도 막을 수 있음
사실상 bash 툴과 Edit 툴만으로 코딩 에이전트 작동은 충분히 가능함 (Edit는 필수까진 아니지만 비효율성 커짐)
다만 코드 검색 같은 부분에서 어려울 수 있음
예를 들어 ripgrep을 bash에서 쓰게 프롬프트를 조정하는 식으로 커버도 가능할 듯함
왜 IDE가 필요한가? 쉘에서 모든 걸 할 수 있음에도 왜 굳이 쓰는가?
UI(인터페이스)란 건 바로 그 순간 필요한 정보와 액션을 제공해주는 역할임
왜 bash 툴 외에 다른 게 들어갔냐는 질문에는 처음엔 최소한의 도구만 주고 시작해서, 나중에 bash를 추가해도 되는 거라는 점 때문일 것 같음
“에이전트 만드는 법”을 장황히 설명하기보단, 에이전트가 실제로 만든 프로젝트를 보여주길 바라는 마음임
직접 에이전트를 만들어서 HN에 “Show HN”으로 공유해주면 너무 좋겠음
Oracle, Agent, high safety, low safety라는 축이 뭘 의미하는지 설명 가능한 사람 있는지 질문함
Hacker News 의견
저희 Princeton SWE-bench 팀에서 약 100줄 코드로 SWE-bench에서 좋은 성과를 내는 에이전트를 만들었음, 관심 있으면 한 번 살펴보면 좋겠음 mini-swe-agent
진짜로 꽤 간단한 구조임에 놀람, 이런 정보를 공유해줘서 고마움
전체 코드는 사실 이 프롬프트들로 돌아감 에이전트 기본 프롬프트 소스코드
에이전트 샘플 프롬프트 중 “1. 코드베이스에서 관련 파일 찾기 및 읽기 2. 이슈 재현 스크립트 만들기 3. 이슈 수정 4. 스크립트로 수정 확인 5. 엣지 케이스 테스트” 부분이 유용함
나도 디버깅 루프에서 이런 식의 프롬프트를 유사하게 사용함
“코드베이스 분석 후 원인 후보를 리스트업하고, 가능성 높은 순으로 랭크하고, 스크립트나 디버그 로깅으로 가설을 검증” 방식이 나만의 문제 해결 루틴에 큰 도움이 됨
문제가 하나의 파일에 자족적으로 있을 때 LLM을 이용해 수정하는 것은 매우 쉬움
그러나 일반적인 코드베이스에서는 파일과 맥락이 여기저기 흩어져 있어서, 개발자의 구조화된 설계 의도와 조직화에 맞춰 파악하기가 쉽지 않음
멋진 시도에 박수를 보냄, 다만 아쉬운 점은 도구가 많지 않다는 것임
대부분의 코드는 에이전트 프레임워크에 해당되고 SWE만을 위한 특화 코드는 생각보다 많지 않음
나도 재미로 SWE 에이전트를 만들어봤으니 autocode도 참고해보면 좋겠음
고맙다는 의미에서 참고 자료에 추가함
Thorsten Ball이 작성한 매우 유사한 “에이전트 빌드 방법 가이드”가 AmpCode How To Guide에도 존재함
전반적으로 Amp도 꽤 흥미로움
이제는 더 이상 비밀스러운 서비스가 아니지만, 에이전트 코딩 관련 도구가 계속 공개되는 것이 반가움
앞으로 다양한 소프트웨어에서 이러한 에이전트 모델이 기본적으로 포함될 것이라 생각함
이게 훨씬 보기 좋아서 고마움을 느낌
저자 본인이 Amp에서 근무한다는 내용도 언급됨
Ghuntley 또한 Amp에서 일함
그림 한 장이 보통 1000단어의 가치라는데, 이 자료에선 그림들의 가치가 99.6% 할인된 느낌임
이게 뭔지 궁금함
텍스트는 실제 발표에서의 워딩을 딕테이션한 것임
혹시 누군가가 툴 활용 방식에 대해 확인해줄 수 있는지 궁금함
Claude, ChatGPT 등에서 API로 "툴"을 제공하며 툴 호출 요청이 들어오면 응답자로서 툴을 실제로 실행하고 결과를 다시 전달하는 형태로 이해하고 있음
근데 실제로 모델은 엄밀히 말해 문자 기반이니, API에서 어떻게 모델 응답을 여러 구조로 바꾸는지 궁금함
분명히 파인튜닝 과정에서 특정 툴 호출을 특수한 블록 형태로 넣은 예제를 통해 모델이 이해하고, Claude/ChatGPT 서버에서 그걸 해석한다는 과정이 있었을 거라 추정함
이와 관련해 문서나 내부적으로 쓰는 특수 토큰에 대한 정보가 있는지, 또 유저 입력이 이 “의미 담당” 토큰을 악용하지 못하게 어떻게 막는지 궁금함
Anthropic에서 공개한 구현 문서가 있음
Anthropic Tool Use Documentation
여기서 모델은 사실 “텍스트”가 아니라 토큰 단위로 동작함을 명확히 알 수 있음
컴파일러가 소스코드를 파싱해서 키워드, 괄호, 구조 등 “토큰” 시퀀스를 만든다는 점과 비슷함
출력물에는 실제 단어와 함께 메타데이터도 포함될 수 있음
개념적으로는 맞게 이해했음
오직 LLM과의 진짜 인터페이스는 “토큰” 뿐이고, 제어와 데이터 채널이 분리되어 있지 않음
모델 API 계층에서 툴 호출용 인스트럭션 및 사용 가능한 툴 목록을 프롬프트에 삽입, 각각에 대한 설명도 같이 제공
툴 호출이 필요할 때 모델은 응답에 특수 블록(특수 토큰 포함, 툴 이름 및 파라미터 명시)을 삽입하면, API 계층이 이를 추출해 JSON 형태로 변환함
툴 실행 결과도 특수 토큰으로 인코딩되어 삽입
사용자 입력에서 자체적으로 이런 토큰을 주입하지 못하도록 API 계층이 막고 있음
최신(SoTA) 모델들은 툴 호출에 대해 상당한 파인튜닝이 이루어졌음, 범용 툴 호출/특정 툴 케이스(예: Claude Sonnet 모델이 Claude Code 툴에 특화)에 대한 파인튜닝 모두 포함
모든 게 잘 작동하는 게 신기할 정도임, 툴 호출에선 파인튜닝이 정말 핵심적인 역할임
파인튜닝 없이도 동작은 가능하지만, 성공률이 크게 떨어짐
“툴 호출이 필요한 예시를 특수한 블록으로 반환하는 방식으로 파인튜닝했다”는 추측은 맞다고 생각함
답을 잘 모를 때나 지시를 받으면 툴 호출 포맷으로 응답하도록 학습됨
포맷을 따르는 툴 호출 예시(포맷 자체)와 일부 도구에 특화된 학습 둘 다 진행됨
예를 들어 gpt-oss는 아무리 언급이 없어도 검색 도구를 쓰려는 경향
Anthropic 문서엔 친숙한 도구(예: text_editor, bash) 목록도 따로 있고, 이 도구들은 사용법에 대한 깊은 의미까지 따로 학습됐을 확률이 높음
실제론 구조가 꽤 깨지기 쉽고, “특수 토큰이나 토큰 시퀀스”라는 낮은 수준의 신호를 통해 이뤄짐
“토큰을 계속 루프에 던지면 에이전트가 생긴다”는 말에 “토큰”을 “돈”으로 바꿔서 보면 현실적인 풍자가 느껴짐
결국 돈을 계속 태우면 에이전트가 생긴다는 셈임
로컬 모델들도 계속 좋아지고 있음
아직까지는 최고의 결과를 내려면 토큰(=돈)이 필요하지만 미래에는 달라질 가능성이 높음
이렇게 이미지만 가득하면 너무 읽기 힘들어짐
스크롤 시뮬레이터를 보는 것 같은 느낌임
bash 툴 말고 굳이 다른 툴이 왜 필요한지 궁금함
파일 목록조회라든지, 레포 찾기 및 탐색, 파일 내용 편집 같은 건 bash만으로도 다 할 수 있지 않나
아니면 위의 mini-swe-agent 예시에서 보여주는 케이스인지 궁금함
기술적으로 봤을 때 bash 하나만으로도 충분히 다양한 작업이 가능하고, 실제로 그렇게 성공한 경험도 있음
흥미로운 점은 도구를 제한할수록 에이전트가 더 창의적으로 접근한다는 점임
하지만 학습된 다양한 도구를 제공하면, 모델이 각 도구의 사용법을 이미 잘 알고 있어서 토큰 사용량도 효율적이고 전반적으로 성공률도 높아짐
Bash만 쓸 경우 bashism이나 인수 처리, 공백 처리 같은 부분에서 자주 헤매는 문제도 있음
별도의 도구를 쓰는 게 bash 하나에 몰아넣는 것보다 훨씬 단순함
만약 모든 것을 bash로 처리하면, 무조건 안전하게 실행 가능한 명령어(예: 파일 목록)는 바로 실행하고, 그 외 위험한 명령은 사용자 승인 받는 체계를 별도로 구현해야 함
파일 목록조회를 별도 툴로 제공하면 프로젝트 디렉터리 외부 파일 노출도 막을 수 있음
사실상 bash 툴과 Edit 툴만으로 코딩 에이전트 작동은 충분히 가능함 (Edit는 필수까진 아니지만 비효율성 커짐)
다만 코드 검색 같은 부분에서 어려울 수 있음
예를 들어 ripgrep을 bash에서 쓰게 프롬프트를 조정하는 식으로 커버도 가능할 듯함
왜 IDE가 필요한가? 쉘에서 모든 걸 할 수 있음에도 왜 굳이 쓰는가?
UI(인터페이스)란 건 바로 그 순간 필요한 정보와 액션을 제공해주는 역할임
왜 bash 툴 외에 다른 게 들어갔냐는 질문에는 처음엔 최소한의 도구만 주고 시작해서, 나중에 bash를 추가해도 되는 거라는 점 때문일 것 같음
“에이전트 만드는 법”을 장황히 설명하기보단, 에이전트가 실제로 만든 프로젝트를 보여주길 바라는 마음임
Oracle, Agent, high safety, low safety라는 축이 뭘 의미하는지 설명 가능한 사람 있는지 질문함
edge와 chrome의 온디바이스 모델(phi4-mini, gemini nano)로 직접 시도해봤는데, 모델 크기에 비해 꽤 잘 동작해서 놀람
how to build an agent on device 실험 사례