LLM 에이전트를 typed tools, DAG, 메모리, critic으로 감싸는 '어드밴스드 하니스' 구축기, HN서 실용성 논쟁
- Data4Science 블로그가 기본 에이전트 루프를 프로덕션급으로 업그레이드하는 방법을 다룸: Pydantic 기반 typed tools, 실행 순서를 정하는 plan DAG, 컨텍스트 관리를 위한 tiered memory, 결과 검증용 verification hierarchy, 비용 관리용 multi-dimensional budgeting을 조합함
- 도시 비교 에이전트를 예시로 씀: 3개 도시 요청 시 인구/타임존/요약 조회가 병렬 가능한 9개 tool call로 분해되고, 최종 리포트는 모든 조회가 끝나야 생성되는 구조로 순수 순차 실행이 아님을 보여줌
- 프롬프트 하나가 모든 걸 하는 문제를 해결하려고 역할을 Planner, Worker, Critic 셋으로 분리함
- LLM 호출을 벤더에 종속되지 않게 만드려고 LLMProvider 베이스 클래스와 결정론적 응답을 주는 MockProvider를 구현해 재현 가능한 테스트를 지원함
- HN 댓글에서는 이런 하니스/스킬/메모리 시스템이 실전에서 별 효과 없다는 회의론과, 컨텍스트 보호 및 가드레일 역할로 여전히 유효하다는 반론이 갈리고, 벤치마크 부재를 지적하는 목소리도 나옴
Hacker News 의견들
에이전트 하니스, 스킬, 메모리 시스템 이런 거 다 실전에서는 쓸모없더라. 다들 자기가 뭔가 발견한 줄 알지만 이미 다 해본 거임
동의함. LLM을 도구로 계속 제약하려는 시도인데 엣지 케이스가 너무 많아서 신뢰성이 안 나옴. 언젠간 다시 엔지니어링으로 돌아가고 vibes는 버릴 거라 봄
이 글에 나온 예시(population, timezone 조회하고 요약 만드는 거) 자체가 오버엔지니어링임. 그냥 promise chain에 토큰 값 비싼 거 추가한 수준. 근데 이런 토이 예제로 개념 배우고 일반화하는 게 중요한 거임. 서브에이전트 쓰는 진짜 이유는 병렬성보다 컨텍스트 보호임. 컨텍스트 윈도우가 커도 attention 문제랑 망각 현상 때문에 좁게 집중시키는 게 낫음
틀렸음. 이런 거 실제로 수백만 명이 쓰고 있음
결국 이 모든 게 하는 일은 컨텍스트 관리를 자기 방식대로 해결하는 것과 가드레일 추가하는 거임
이거 다 그냥 연금술 같은 거임. 파이라이트에서 금 만들려는 거랑 똑같음
완전 쓸모없다고는 안 봄. 커뮤니티 차원에서 계속 발전하고 있고 나중에 Anthropic 같은 상업 서비스에 통합됨. 오픈소스로 하니까 투명하고 로컬 오픈모델로도 쓸 수 있는 거 아님
그럼 스킬, 하니스, 메모리 시스템 안 쓰면 뭘 쓰라는 거임?
plan을 그래프로 짜는 것보다 LLM한테 REPL 루프 주고 도구들을 함수로 넣어주는 걸 더 선호함. 그러면 LLM이 DAG에 갇히지 않고 루프 돌거나 조기 종료하는 코드를 직접 짤 수 있음
좋은 글이네, 저장해둠
나도 커스텀 하니스 만들고 있는데 루프 지원 구현하고 싶고, x번 반복하고 플래닝은 y번 반복하는 식으로 동적으로 만들 프레임워크도 고민 중임
hierarchical skill, meta harness, trace/trajectory 표현, 에이전트 벤치마크 논문들 찾아보고, Anthropic 블로그나 Claude Code/PI/Hermes 작동 방식, 에이전트 세션/포킹/훅부터 보면 좋음
이거 실제로 문제 해결력을 개선한다는 벤치마크 있음? 하니스 엔지니어링 해본 경험상 멋있어 보이는 아이디어가 emergent effect 때문에 오히려 성능 깎아먹는 경우 많음. 좀 의심스러움
메모리 모델이 궁금한데 이 글 보면 그냥 벡터DB라고만 하고 working memory나 procedural memory 얘기는 하나도 없음. advanced라기엔 실망스러움
Terrence Tao 팀이 수학 증명용으로 만든 하니스도 있는데 구조를 아는 사람이 있으면 평가해줬으면 함
그건 실제로 증명하는 게 아니라 그냥 이어붙이는 거임. 진짜 증명은 사람이나 LEAN이 해야 함. AI가 증명을 만든 게 아니라 증명의 시뮬라크라만 본 적 있음
깃허브 저장소도 같이 올려둠(DataForScience/LLMs)
좋은 튜토리얼이긴 한데, 요즘 진짜 어려운 문제는 시스템에 LLM을 어디 넣을지가 아니라 어디에 안 넣을지임. 결과 검증이 점점 더 중요해지는 것 같은데 이거 어떻게 생각함?
제목이랑 인트로랑 다르게 이건 advanced agent harness가 아니라 그냥 워크플로우 빌더/러너임. 글쓴이도 대부분 케이스에서 작동한다고 증명한 건 아니라고 밝혔고, DAG는 좋아 보이지만 LLM이 태스크를 너무 세분화해서 큰 그림을 놓치게 만들 수 있음. 강제 JSON 구조가 GPT 같은 모델의 IQ를 깎아먹는 느낌도 있음. 이거 Claude Code 이전 시대에 사람들이 agent 만들던 방식이랑 비슷함. orchestrator는 그냥 소프트웨어 루프고 LLM 프롬프트가 planner/worker 유연성을 제한하는 거임
나도 비슷한 거 만들어봤는데 내 방식은 critic이 각 단계마다 다음 단계로 넘어가기 전에 승인해야 하는 구조임. issue, plan, PR 같은 산출물 단위로 단계를 나누고 DAG로 전이를 정의함. 곧 오픈소스 하려는데 다들 비슷한 거 만들고 있는 듯